- 06 Oct, 2016 40 commits
-
-
Paul Burton authored
Introduce a "generic" platform, which aims to be board-agnostic by making use of device trees passed by the boot protocol defined in the MIPS UHI (Universal Hosting Interface) specification. Provision is made for supporting boards which use a legacy boot protocol that can't be changed, but adding support for such boards or any others is left to followon patches. Right now the built kernels expect to be loaded to 0x80100000, ie. in kseg0. This is fine for the vast majority of MIPS platforms, but nevertheless it would be good to remove this limitation in the future by mapping the kernel via the TLB such that it can be loaded anywhere & map itself appropriately. Configuration is handled by dynamically generating configs using scripts/kconfig/merge_config.sh, somewhat similar to the way powerpc makes use of it. This allows for variations upon the configuration, eg. differing architecture revisions or subsets of driver support for differing boards, to be handled without having a large number of defconfig files. Signed-off-by:
Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/14353/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org>
-
Paul Burton authored
Add support for generating kernel images in the Flattened Image Tree (.itb) format as supported by U-Boot. This format is essentially a Flattened Device Tree binary containing images (kernels, DTBs, ramdisks) and configurations which link those images together. The big advantages of FIT images over the uImage format are: - We can include FDTs in the kernel image in a way that the bootloader can extract it & manipulate it before providing it to the kernel. Thus we can ship FDTs as part of the kernel giving us the advantages of being able to develop & maintain the DT within the kernel tree, but also have the benefits of the bootloader being able to manipulate the FDT. Example uses for this would be to inject the kernel command line into the chosen node, or to fill in the correct memory size. - We can include multiple configurations in a single kernel image. This means that a single FIT image can, given appropriate bootloaders, be booted on different boards with the bootloader selecting an appropriate configuration & providing the correct FDT to the kernel. - We can support a multitude of hashes over the data. Signed-off-by: -
Paul Burton authored
On MIPS64 we define the default CAC_BASE as one of the xkphys regions of the virtual address space. Since the CCA is encoded in bits 61:59 of xkphys addresses, fixing CAC_BASE to any particular one prevents us from dynamically changing the CCA as we do for MIPS32 where CAC_BASE is placed within kseg0. In order to make the kernel more generic, drop the current kludge that gives CAC_BASE CCA=3 if CONFIG_DMA_NONCOHERENT is selected (disregarding CONFIG_DMA_MAYBE_COHERENT) & CCA=5 (which is not standardised by the architecture) otherwise. Instead read Config.K0 and generate the appropriate offset into xkphys, presuming that either the bootloader or early kernel code will have configured Config.K0 appropriately. This seems like the best option for a generic implementation. The ip27 spaces.h is adjusted to set its former value of CAC_BASE, since it's the only user of CAC_BASE from assembly (in its smp_slave_setup macro). This allows the generic case to focus solely on C code without breaking ip27. Signed-off-by:
-
Paul Burton authored
If a bus error occurs on a system with a MIPS Coherence Manager (CM) then the CM may hold useful diagnostic information. Printing this out has so far been left up to boards, with the requirement that they register a board_be_handler function & call mips_cm_error_decode() from there. In order to avoid boards other than Malta needing to duplicate this code, call mips_cm_error_decode() automatically if the board registers no board_be_handler, and remove the Malta implementation of that. This patch results in no functional change, but removes a further piece of platform-specific code. Signed-off-by:
-
Paul Burton authored
On some MIPS systems, a subset of devices may have DMA coherent with CPU caches. For example in systems including a MIPS I/O Coherence Unit (IOCU), some devices may be connected to that IOCU whilst others are not. Prior to this patch, we have a plat_device_is_coherent() function but no implementation which does anything besides return a global true or false, optionally chosen at runtime. For devices such as those described above this is insufficient. Fix this by tracking DMA coherence on a per-device basis with a dma_coherent field in struct dev_archdata. Setting this from arch_setup_dma_ops() takes care of devices which set the dma-coherent property via device tree, and any PCI devices beneath a bridge described in DT, automatically. Signed-off-by:
-
Paul Burton authored
There are no cases where plat_device_is_coherent() will return zero whilst hw_coherentio is non-zero, and acting any differently in such a case doesn't make much sense - if a device is non-coherent with the CPU caches then access to memory "coherent" with DMA must be uncached. Clean up the nonsensical case. Signed-off-by:
-
Paul Burton authored
The coherentio variable has previously been used as a boolean value, indicating whether the user specified that coherent I/O should be enabled or disabled. It failed to take into account the case where the user does not specify any preference, in which case it makes sense that we should default to coherent I/O if the hardware supports it (hw_coherentio is non-zero). Introduce an enum to clarify the 3 different values of coherentio & use it throughout the code, modifying plat_device_is_coherent() & r4k_cache_init() to take into account the default case. Signed-off-by:
-
Paul Burton authored
Introduce support for PCI drivers using only functionality provided generically by the PCI subsystem, by adding the minimum arch-provided functions required. The driver this has been developed for & tested with the xilinx-pcie on a MIPS Boston development board. Signed-off-by:
-
Paul Burton authored
Introduce 2 Kconfig symbols, CONFIG_PCI_DRIVERS_GENERIC & CONFIG_PCI_DRIVERS_LEGACY, which indicate whether the system should be built to for PCI drivers using the MIPS-specific struct pci_controller API (hereafter "legacy" drivers) or more generic drivers using only functionality provided by the PCI core (hereafter "generic" drivers). The Kconfig entries are created such that platforms have to select CONFIG_PCI_DRIVERS_GENERIC if they wish to use it - that is, the default is CONFIG_PCI_DRIVERS_LEGACY so that existing platforms need no modification. The functions declared in pci.h are rearranged with those provided only by pci-legacy.c being guarded by an #ifdef CONFIG_PCI_DRIVERS_LEGACY to ensure they are only used in configurations where they are implemented. Signed-off-by:
-
Paul Burton authored
Split out the parts of pci.c that are used by existing systems with MIPS-style PCI drivers but that will not be used by systems with more generic PCI drivers such as pcie-xilinx. This is done in preparation for allowing configurations where the code moved to pci-legacy.c is not built. Signed-off-by:
-
Paul Burton authored
The MIPS implementation of pcibios_assign_all_busses trivially returns 1. Implement it as a static function in asm/pci.h such that the compiler can inline it & optimise out never-taken paths. Signed-off-by:
-
Paul Burton authored
In preparation for allowing configurations in which pcibios_init is not included, make pcibios_set_cache_line_size an initcall. arch_initcall is used such that it runs before the pcibios_init subsys_initcall for platforms that continue to use it. Signed-off-by:
-
Paul Burton authored
Introduce support for CONFIG_PCI_DOMAINS_GENERIC, allowing for platforms to make use of generic PCI domains instead of the MIPS-specific implementation. The set_pci_need_domain_info function is introduced to abstract away the removed need_domain_info field in struct pci_controller, and pcibios_scanbus is adjusted to use the pci_domain_nr accessor instead of directly accessing the index field. Signed-off-by:
-
Paul Burton authored
Rather than open-coding a linked list implementation, make use of the one in linux/list.h. Signed-off-by:
-
Marcin Nowakowski authored
Current instruction decoder for uprobe/kprobe handler only handles branches with delay slots. For compact branches the behaviour is rather unpredictable - and depending on the encoding of a compact branch instruction may result in one (or more) of: - executing an instruction that follows a branch which wasn't in a delay slot and shouldn't have been executed - incorrectly emulating a branch leading to a jump to a wrong location - unexpected branching out of the single-stepped code and never reaching the breakpoint that should terminate the probe handler Results of these actions are generally unpredictable, but can end up with a probed application or kernel crash, so disable placing probes on compact branches until they are handled properly. Signed-off-by:
Marcin Nowakowski <marcin.nowakowski@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/14336/Signed-off-by:
-
Marcin Nowakowski authored
Currently both kprobes and uprobes code have definitions of the insn_has_delay_slot method. Move it to a separate header as an inline method that each probe-specific method can later use. No functional change intended, although the methods slightly varied in the constraints they set for the methods - the uprobes one was chosen as it is slightly more specific when filtering opcode fields. Signed-off-by:
-
Jaedon Shin authored
Use appended DTB when available. Signed-off-by:
Jaedon Shin <jaedon.shin@gmail.com> Cc: Kevin Cernekee <cernekee@gmail.com> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/14337/Signed-off-by:
-
Jaedon Shin authored
Changes node names of the interrupt-controller device nodes to interrupt-controller instead of label strings. Signed-off-by:
-
Jaedon Shin authored
Adds NAND device nodes to BCM7xxx MIPS based SoCs. Signed-off-by:
-
Jaedon Shin authored
Adds SDHCI device nodes to BCM7xxx MIPS based SoCs. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Cc: Jonas Gorski <jonas.gorski@gmail.com> Cc: Kevin Cernekee <cernekee@gmail.com> Cc: Rob Herring <robh+dt@kernel.org> Cc: MIPS Mailing List <linux-mips@linux-mips.org> Cc: devicetree@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/14002/Signed-off-by:
-
Jaedon Shin authored
Adds GPIO device nodes to BCM7xxx MIPS based SoCs. Signed-off-by:
-
Jaedon Shin authored
Adds PWM device nodes to BCM7xxx MIPS based SoCs. Signed-off-by:
-
Paul Burton authored
The arch code will hang the machine with an infinite loop if the board doesn't provide an impelementation of halt - let it, rather than duplicating it. Signed-off-by:
-
Paul Burton authored
Make use of the generic syscon-reboot driver to reboot the Malta board, reducing the amount of platform code it requires. Signed-off-by:
-
Paul Burton authored
Add the DT nodes required to probe the CFI compatible parallel monitor flash found on the Malta development board, and remove the platform code that was previously doing it. Delete the now-empty malta-platform.c file. Adjust the Malta defconfigs that enable MTD & the pflash/CFI driver to enable CONFIG_MTD_PHYSMAP_OF rather than CONFIG_MTD_PHYSMAP in order to preserve their behaviour. Signed-off-by:
-
Paul Burton authored
Add the DT node required to probe the RTC, and remove the platform code that was previously doing it. Signed-off-by:
-
Paul Burton authored
Since commit 44a7185c ("of/platform: Add common method to populate default bus") the Malta publish_devices initcall has essentially been a no-op. Remove it. Signed-off-by:
-
Paul Burton authored
Since commit 44a7185c ("of/platform: Add common method to populate default bus") platforms calling of_platform_bus_probe from an initcall is either a rather unsafe race with of_platform_default_populate_init or a no-op. The MIPS Malta board needs to probe devices under an ISA bus, which we do support in the of_busses array but until now haven't included in of_default_bus_match_table. Add an "isa" entry to of_default_bus_match_table such that we can just accept use of of_platform_default_populate_init & remove the Malta-specific match table in a later patch. Signed-off-by:
Rob Herring <robh@kernel.org> Cc: Frank Rowand <frowand.list@gmail.com> Cc: linux-mips@linux-mips.org Cc: devicetree@vger.kernel.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/14275/Signed-off-by:
-
Paul Burton authored
Probe the CPU, GIC & i8259 interrupt controllers present in the Malta system using device tree. This enables interrupts to be provided to devices using device tree as they are moved over to being probed using it. Since Malta is very configurable it's unknown whether a GIC will be present at compile time. In order to support both cases the malta_dt_shim code is added in order to detect whether a GIC is present, adjusting the DT to route interrupts correctly and nop out the GIC node if no GIC is found. Signed-off-by:
-
Paul Burton authored
Malta boards can have more than 256MB DDR available, but we have previously only made use of up to 256MB (ie. the DDR accessible via kseg0) by default, without the user manually specifying mem= kernel parameters. This patch causes all available DDR, as reported by the bootloader via the ememsize or memsize environment variables or optionally on the command line, to be used when possible without the user needing to manually provide the memory ranges. Malta now has 2 subtly different memory maps which have to be taken into account when setting this up. The original memory map (referred to by the code as v1) has up to 2GB of DDR aliased in both the upper & lower halves of the 32 bit physical address space, with a 256MB I/O region obscuring 0x10000000-0x1fffffff only in the lower alias. The revised v2 memory map is flat with up to 4GB DDR starting from 0x0, and the I/O region obscures 256MB of DDR which becomes inacessible. The memory map in use is indicated by a register provided by the rocit2 system controller, which is checked in order to set up the kernels memory ranges accordingly. Signed-off-by:
-
Paul Burton authored
Set the PCI_BAR0 register in all configurations such that PCI devices can perform DMA to all of the bottom 2GB of the physical address space. This is imperfect if we make use of the legacy Malta memory map, but it is an improvement on the inconsistent values setup before. Signed-off-by:
-
Paul Burton authored
The i8259A_irq_pending function is unused. Remove the dead code. Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/14271/Signed-off-by:
-
Paul Burton authored
The default i8259 polling function (i8259_irq) is nicely generic but is fairly costly. Platforms often provide an alternative means of polling for an i8259 interrupt, and when using the i8259 without device tree have typically just chained its parent interrupt to their own handler function. In order to allow for platform-specific polling functions to be used in cases where the driver is probed via device tree, provide an i8259_set_poll function that accepts a pointer to an alternative poll function that will override the default. Signed-off-by:
-
Paul Burton authored
Mapping the parent IRQ will use a virq number which may conflict with the hardcoded I8259A_IRQ_BASE..I8259A_IRQ_BASE+15 range that the i8259 driver expects to be free. If this occurs then we'll hit errors when adding the i8259 IRQ domain, since one of its virq numbers will already be in use. Avoid this by adding the i8259 domain before mapping the parent IRQ, such that the i8259 virq numbers become used before the parent interrupt controller gets a chance to use any of them. Signed-off-by:
-
Paul Burton authored
The SEAD3 board defines a custom implementation of read_persistent_clock which does exactly the same dummy operation as the generic weak version. Remove the not really implemented custom version. Signed-off-by:
-
Paul Burton authored
Probe the img-ascii-lcd driver using device tree in order to display a message on the SEAD3 board's LCD display, and remove the platform code that was formerly performing this function. This removes more platform code and moves SEAD3 further towards being entirely DT-based. Signed-off-by:
-
Paul Burton authored
Add a driver for simple ASCII LCD displays found on the MIPS Boston, Malta & SEAD3 development boards. The Boston display is an independent memory mapped device with a simple memory mapped 8 byte register space containing the 8 ASCII characters to display. The Malta display is exposed as part of the Malta board registers, and provides 8 registers each of which corresponds to one of the ASCII characters to display. The SEAD3 display is slightly more complex, exposing an interface to an S6A0069 LCD controller via registers provided by the boards CPLD. However although the displays differ in their register interface, we require similar functionality on each board so abstracting away the differences within a single driver allows us to share a significant amount of code & ensure consistent behaviour. The driver displays the Linux kernel version as the default message, but allows the message to be changed via a character device. Messages longer then the number of characters that the display can show will scroll. This provides different behaviour to the existing LCD display code for the MIPS Malta or MIPS SEAD3 platforms in the following ways: - The default string to display is not "LINUX ON MALTA" or "LINUX ON SEAD3" but "Linux" followed by the version number of the kernel (UTS_RELEASE). - Since that string tends to be significantly longer it scrolls twice as fast, moving every 500ms rather than every 1s. - The LCD won't be updated until the driver is probed, so it doesn't provide the early "LINUX" string. Signed-off-by: -
Paul Burton authored
Add documentation for a devicetree binding for the simple ASCII LCD displays found on development boards such as the MIPS Boston, MIPS Malta & MIPS SEAD3 from Imagination Technologies. Signed-off-by:
-
Paul Burton authored
The SEAD3 board no longer uses the cobalt_lcdfb driver, so remove the SEAD3-specific code from it. Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Ondrej Zary <linux@rainbow-software.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Robert Jarzmik <robert.jarzmik@free.fr> Cc: Maciej W. Rozycki <macro@linux-mips.org> Cc: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com> Cc: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Simon Horman <horms+renesas@verge.net.au> Cc: linux-mips@linux-mips.org Cc: linux-fbdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/14060/Signed-off-by:
-
Paul Burton authored
The 2 line * 16 character LCD display on the SEAD3 board has no real use as a framebuffer device. It's far too small to produce any meaningful output if used as the kernel console, SEAD3 is a development board that will essentially always have a far more useful UART connection & the code in sead3-display.c will overwrite whatever's on the display every second anyway. Remove this unused code. Signed-off-by:
-
