BUG() can be a noop if CONFIG_BUG is not selected,
leading to the following build problem on a randconfig:
arch/mips/bcm63xx/cpu.c: In function 'detect_cpu_clock':
arch/mips/bcm63xx/cpu.c:254:1: error: control reaches end of
non-void function [-Werror=return-type]
We fix this problem by replacing BUG() with panic() since it's
best to handle the case of an unknown board instead of silently
returning a random clock frequency.
Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Acked-by: Steven J. Hill <Steven.Hill@imgtec.com>
Acked-by: Jonas Gorski <jogo@openwrt.org>
Signed-off-by: John Crispin <blogic@openwrt.org>
Patchwork: http://patchwork.linux-mips.org/patch/5932/
The Broadcom BCM3368 Cable Modem SoC is extremely similar to the
existing BCM63xx DSL SoCs, in particular BCM6358, therefore little effort
in the existing code base is required to get it supported. This patch adds
support for the following on-chip peripherals:
- two UARTS
- GPIO
- Ethernet
- SPI
- PCI
- NOR Flash
The most noticeable difference with 3368 is that it has its peripheral
register at 0xfff8_0000 we check that separately in ioremap.h. Since
3368 is identical to 6358 for its clock and reset bits, we use them
verbatim.
Signed-off-by: Florian Fainelli <florian@openwrt.org>
Cc: linux-mips@linux-mips.org
Cc: cernekee@gmail.com
Cc: jogo@openwrt.org
Patchwork: https://patchwork.linux-mips.org/patch/5499/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Instead of trying to use a correlation of cpu prid and chip id and
hoping they will always be unique, use the cpu prid to determine the
chip id register location and just read out the chip id.
Signed-off-by: Jonas Gorski <jogo@openwrt.org>
Patchwork: http://patchwork.linux-mips.org/patch/5008/
Acked-by: John Crispin <blogic@openwrt.org>
BMIPS processor cores are used in 50+ different chipsets spread across
5+ product lines. In many cases the chipsets do not share the same
peripheral register layouts, the same register blocks, the same
interrupt controllers, the same memory maps, or much of anything else.
But, across radically different SoCs that share nothing more than the
same BMIPS CPU, a few things are still mostly constant:
SMP operations
Access to performance counters
DMA cache coherency quirks
Cache and memory bus configuration
So, it makes sense to treat each BMIPS processor type as a generic
"building block," rather than tying it to a specific SoC. This makes it
easier to support a large number of BMIPS-based chipsets without
unnecessary duplication of code, and provides the infrastructure needed
to support BMIPS-proprietary features.
Signed-off-by: Kevin Cernekee <cernekee@gmail.com>
Cc: mbizon@freebox.fr
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Tested-by: Florian Fainelli <ffainelli@freebox.fr>
Patchwork: https://patchwork.linux-mips.org/patch/1706/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org
For consistency with other BCM63xx SoC set the CPU name to "Broadcom
BCM6338" when actually running on that system.
Signed-off-by: Florian Fainelli <florian@openwrt.org>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
