Hard to follow who is pointing what to where and why so it's simply getting
in the way of the time code renovation.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
This has not been any serious user of this ill conceived thing since the
original invention in like '95.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
It was getting a little big, ugly and a primary source for merge conflicts.
Also the old method was a bit too forgiving in that the workaround did
default to off, so now there is an explicit #error forcing platform
maintainers to think if they should enable a workaround for a particular
platform.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Add LED support to the WGT634U machine. It uses the new gpio-led
driver and a platform driver for the pin definitions.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Add GPIO support to the BCM47XX platform. It will be used by a GPIO
LED driver.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Add CFE support to the BCM47XX code. That includes querying CFE environment
variables as well as using CFE to print messages before the serial port is
initialized (early printk).
Signed-off-by: Aurelien Jarno <aurel32@farad.aurel32.net>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Move the platform independent part of the CFE code to arch/mips/fw/cfe from
arch/mips/sibyte/cfe.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
It may not be perfect yet but the SB1 code is badly borken and has
horrible performance issues.
Downside: This seriously breaks support for pass 1 parts of the BCM1250
where indexed cacheops don't work quite reliable but I seem to be the
last one on the planet with a pass 1 part anyway.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Match the R4000 semantics for the initial state of interrupt/kernel
status register flags for the R3000 in kernel_thread().
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
This style will be consitent with all other arch's - soon.
In addition:
- Moved a few labels inside brackets for the sections they specify
to prevent that linker alignmnet made them point before the section start
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
o Move i8259 function declarations to include/asm-mips/i8259.h
o Make i8259.c functions static where possible.
Signed-off-by: Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Note that the BCM4710 does not support the wait instruction, this
is not a mistake in the code.
It originally comes from the OpenWrt patches.
Cc: Michael Buesch <mb@bu3sch.de>
Cc: Felix Fietkau <nbd@openwrt.org>
Cc: Florian Schirmer <jolt@tuxbox.org>
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
This patch renames it for 3 reasons:
- "CONFIG" pattern is used by Kconfig. Now this macro is
no more defined by Kconfig but by Kbuild itself make this
clear by translating "CONFIG" into "KBUILD".
- "ELF32" word is improper because it is irrelevant to ELF
format and it makes confusion with CONFIG_BOOT_ELF32. So
translate it with SYM32.
- Add "64BIT" part to make clear that this macro implies a
64 bits kernel.
Signed-off-by: Franck Bui-Huu <fbuihuu@gmail.com>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
We do not rely on user anymore to setup this config correctly.
Instead we make our choice depending on the load address.
If we want to force Kbuild to use ELF64 format whatever
the load address we can still do:
$ make BUILD_ELF32=no
Signed-off-by: Franck Bui-Huu <fbuihuu@gmail.com>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
This patch removes '-mno-explicit-relocs' usage when
CONFIG_BUILD_ELF64 is set since this option was only required
with the old hack to truncate addresses at the assembly level
where "-mabi=64 -Wa,-mabi=32" was used.
This should yield a small code size improvement for inline
assembly, where the R constraint is used.
The idea is coming from Maciej <macro@linux-mips.org>.
Signed-off-by: Franck Bui-Huu <fbuihuu@gmail.com>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Use ->set_pio_mode method to program PIO modes in ide_set_xfer_rate()
(the only place which used ->speedproc to program PIO modes) and remove
handling of PIO modes from all ->speedproc implementations.
v2:
* Fix pmac_ide_tune_chipset() comment.
There should be no functionality changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
* Return failure in ->speedproc method for unsupported/invalid transfer
modes passed from user-space (fixes theoretical OOPS in ali_tune_pio()
and/or setting random PIO timings on host controller + disabling UDMA
bit + setting unsupported/invalid transfer mode on the device).
* Don't disable UDMA bit when programming PIO modes.
* Add FIXME about DMA timings never being set.
* Bump driver version.
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
* Remember to select PIO data transfer (with IORDY monitored) in sil_tune_pio()
(->set_pio_mode method) so the controller is always programmed correctly for
PIO transfers (this is important if DMA is not going to be used).
* Don't set DMA/UDMA timings for PIO modes in siimage_tune_chipset().
* Bump driver version.
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
There is no need to do it in cs5520_tune_chipset() (->speedproc method)
since it is correctly handled by cs5520_dma_on() (->ide_dma_on method).
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
ide_config_drive_speed() called by sc1200_set_xfer_mode() already gives
a meaningful warning message in case of failure.
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
