aboutsummaryrefslogtreecommitdiffstats
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2020-03-04riscv: Force flat memory model with no-mmuDamien Le Moal1-0/+1
Compilation errors trigger if ARCH_SPARSEMEM_ENABLE is enabled for a nommu kernel. Since the sparsemem model does not make sense anyway for the nommu case, do not allow selecting this option to always use the flatmem model. Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> Reviewed-by: Anup Patel <anup@brainfault.org> Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2020-03-04ARM: dts: mediatek: add mt7629 pwm supportSam Shih1-0/+14
This adds pwm support for MT7629. Signed-off-by: Sam Shih <sam.shih@mediatek.com> Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
2020-03-04Merge tag 'socfpga_defconfig_fix_for_v5.6' of git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux into arm/fixesOlof Johansson1-0/+1
ARM: socfpga_defconfig: add back DEBUGFS - Add back DEBUG_FS for socfpga_defconfig * tag 'socfpga_defconfig_fix_for_v5.6' of git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux: ARM: socfpga_defconfig: Add back DEBUG_FS Link: https://lore.kernel.org/r/20200304101917.1243-1-dinguyen@kernel.org Signed-off-by: Olof Johansson <olof@lixom.net>
2020-03-04ARM: OMAP: replace setup_irq() by request_irq()afzal mohammed4-29/+15
request_irq() is preferred over setup_irq(). Invocations of setup_irq() occur after memory allocators are ready. Per tglx[1], setup_irq() existed in olden days when allocators were not ready by the time early interrupts were initialized. Hence replace setup_irq() by request_irq(). [1] https://lkml.kernel.org/r/alpine.DEB.2.20.1710191609480.1971@nanos Signed-off-by: afzal mohammed <afzal.mohd.ma@gmail.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-03-04ARM: dts: dra7: Add PRU-ICSS interconnect target-module nodesSuman Anna5-1/+54
The AM57xx family of SoCs contains two identical PRU-ICSS instances that have a very unique SYSC register. The IPs do not have any PRCM reset lines unlike those on AM33xx/AM437x SoCs. Add the PRUSS interconnect target-module nodes with all the required properties. Each of the PRUSS devices themselves shall be added as child nodes to the corresponding interconnect node in the future. The PRU-ICSS instances are only available on AM57xx family of SoCs and are not supported on DRA7xx family of SoCs in general, so the target module nodes are added in a separate dtsi file. This new dtsi file is included in all the AM57xx SoC dtsi files, so the nodes are automatically inherited and enabled on all AM57xx boards. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-03-04ARM: dts: AM4372: Add the PRU-ICSS interconnect target-module nodeSuman Anna1-0/+22
The AM437x family of SoCs contains two dissimilar PRU-ICSS instances, but leverage a common reset line and SYSCFG from the larger PRU-ICSS1 instance. This SYSC register has also very unique bit-fields. Both the IPs require the PRCM reset to be deasserted to be able to access any registers. Add a common PRUSS interconnect target-module with all the required properties. The PRUSS devices themselves shall be added as child nodes to this interconnect node in the future. The PRU-ICSS instances are not supported on AM4372 SoC though in the AM437x family, so the target module node should be disabled in any derivative board files that use this SoC. Signed-off-by: Suman Anna <s-anna@ti.com> Reviewed-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-03-04ARM: dts: AM33xx-l4: Update PRUSS interconnect target-module nodeSuman Anna1-3/+18
The PRU-ICSS present on some AM33xx SoCs has a very unique SYSC register. The IP also uses a hard-reset line, and requires this PRCM reset to be deasserted to be able to access any registers. Update the existing PRUSS interconnect target-module with all the required properties. The PRUSS device itself shall be added as a child node to this interconnect node in the future. PRU-ICSS is not supported on AM3351/AM3352/AM3354 SoCs though in the AM33xx family, so the target module node should be disabled in derivative board files that use any of these SoCs. Signed-off-by: Suman Anna <s-anna@ti.com> Reviewed-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-03-04Merge branch 'omap-for-v5.7/accelerators' into omap-for-v5.7/ti-sysc-drop-pdataTony Lindgren7-190/+0
2020-03-04ARM: OMAP2+: Drop legacy platform data for am437x DSSTony Lindgren2-103/+0
We can now probe devices with ti-sysc interconnect driver and dts data. Let's drop the related platform data and custom ti,hwmods dts property. As we're just dropping data, and the early platform data init is based on the custom ti,hwmods property, we want to drop both the platform data and ti,hwmods property in a single patch. Cc: Jyri Sarha <jsarha@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-03-04ARM: OMAP2+: Drop legacy platform data for dra7 DSSTony Lindgren2-165/+0
We can now probe devices with ti-sysc interconnect driver and dts data. Let's drop the related platform data and custom ti,hwmods dts property. As we're just dropping data, and the early platform data init is based on the custom ti,hwmods property, we want to drop both the platform data and ti,hwmods property in a single patch. Cc: Jyri Sarha <jsarha@ti.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-03-04ARM: OMAP2+: Drop legacy platform data for omap5 DSSTony Lindgren2-290/+0
We can now probe devices with ti-sysc interconnect driver and dts data. Let's drop the related platform data and custom ti,hwmods dts property. As we're just dropping data, and the early platform data init is based on the custom ti,hwmods property, we want to drop both the platform data and ti,hwmods property in a single patch. Cc: Jyri Sarha <jsarha@ti.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-03-04ARM: OMAP2+: Drop legacy platform data for omap4 dssTony Lindgren2-406/+0
We can now probe devices with ti-sysc interconnect driver and dts data. Let's drop the related platform data and custom ti,hwmods dts property. As we're just dropping data, and the early platform data init is based on the custom ti,hwmods property, we want to drop both the platform data and ti,hwmods property in a single patch. Cc: Jyri Sarha <jsarha@ti.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Sebastian Reichel <sre@kernel.org> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-03-04ARM: dts: Configure interconnect target module for am437x rfbiTony Lindgren1-6/+24
We can now probe devices with device tree only configuration using ti-sysc interconnect target module driver. Let's configure the module and drop "ti,hwmods" peroperty as this module is a child node of dispc and has no dependencies to to legacy platform data. Cc: Jyri Sarha <jsarha@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-03-04ARM: dts: Configure interconnect target module for am437x dispcTony Lindgren1-6/+30
We can now probe devices with device tree only configuration using ti-sysc interconnect target module driver. Let's configure the module, but keep the legacy "ti,hwmods" peroperty until the child devices are probing with ti-sysc interconnect driver. Note that we also fix a harmless typo for the node name, it's dispc@400, not dispc@4000. Cc: Jyri Sarha <jsarha@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-03-04ARM: dts: Move am437x dss to the interconnect target module in l4Tony Lindgren2-32/+35
On am437x, the display subsystem (DSS) is on l4. We already have the interconnect target module for it, so let's just move dss there. To do that, we need to adjust the module addresses for the ranges, and use the ranges already added earlier based on reading the l4 interconnect instance AP registers. Cc: Jyri Sarha <jsarha@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-03-04ARM: dts: Configure interconnect target module for dra7 hdmiTony Lindgren1-15/+32
We can now probe devices with device tree only configuration using ti-sysc interconnect target module driver. Let's configure the module and drop "ti,hwmods" peroperty as this module is a child node of dispc and has no dependencies to to legacy platform data. Cc: Jyri Sarha <jsarha@ti.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-03-04ARM: dts: Configure interconnect target module for dra7 dispcTony Lindgren1-8/+32
We can now probe devices with device tree only configuration using ti-sysc interconnect target module driver. Let's configure the module, but keep the legacy "ti,hwmods" peroperty until the child devices are probing with ti-sysc interconnect driver. Cc: Jyri Sarha <jsarha@ti.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-03-04ARM: dts: Configure interconnect target module for dra7 dssTony Lindgren3-41/+57
We can now probe devices with device tree only configuration using ti-sysc interconnect target module driver. Let's configure the module, but keep the legacy "ti,hwmods" peroperty until the child devices are probing with ti-sysc interconnect driver. Initially let's just update the top level dss node to probe with ti-sysc interconnect target module driver. The child nodes are still children of dispc, only the node indentation changes for them now along with using the reg range provided by top level dss. Cc: Jyri Sarha <jsarha@ti.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-03-04ARM: dts: Configure interconnect target module for omap5 hdmiTony Lindgren1-14/+31
We can now probe devices with device tree only configuration using ti-sysc interconnect target module driver. Let's configure the module and drop "ti,hwmods" peroperty as this module is a child node of dispc and has no dependencies to to legacy platform data. Cc: Jyri Sarha <jsarha@ti.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-03-04ARM: dts: Configure interconnect target module for omap5 dsi2Tony Lindgren1-12/+29
We can now probe devices with device tree only configuration using ti-sysc interconnect target module driver. Let's configure the module and drop "ti,hwmods" peroperty as this module is a child node of dispc and has no dependencies to to legacy platform data. Cc: Jyri Sarha <jsarha@ti.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-03-04ARM: dts: Configure interconnect target module for omap5 dsi1Tony Lindgren1-12/+29
We can now probe devices with device tree only configuration using ti-sysc interconnect target module driver. Let's configure the module and drop "ti,hwmods" peroperty as this module is a child node of dispc and has no dependencies to to legacy platform data. Cc: Jyri Sarha <jsarha@ti.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-03-04ARM: dts: Configure interconnect target module for omap5 rfbiTony Lindgren1-7/+25
We can now probe devices with device tree only configuration using ti-sysc interconnect target module driver. Let's configure the module and drop "ti,hwmods" peroperty as this module is a child node of dispc and has no dependencies to to legacy platform data. Cc: Jyri Sarha <jsarha@ti.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-03-04ARM: dts: Configure interconnect target module for omap5 dispcTony Lindgren1-4/+28
We can now probe devices with device tree only configuration using ti-sysc interconnect target module driver. Let's configure the module, but keep the legacy "ti,hwmods" peroperty until the child devices are probing with ti-sysc interconnect driver. Cc: Jyri Sarha <jsarha@ti.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-03-04ARM: dts: Configure interconnect target module for omap5 dssTony Lindgren1-62/+78
We can now probe devices with device tree only configuration using ti-sysc interconnect target module driver. Let's configure the module, but keep the legacy "ti,hwmods" peroperty until the child devices are probing with ti-sysc interconnect driver. Initially let's just update the top level dss node to probe with ti-sysc interconnect target module driver. The child nodes are still children of dispc, only the node indentation changes for them now along with using the reg range provided by top level dss. Cc: Jyri Sarha <jsarha@ti.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-03-04ARM: dts: Configure interconnect target module for omap4 hdmiTony Lindgren1-14/+33
We can now probe devices with device tree only configuration using ti-sysc interconnect target module driver. Let's configure the module and drop "ti,hwmods" peroperty as this module is a child node of dispc and has no dependencies to to legacy platform data. Note that we must disable smart idle modes for HDMI audio like we've done with the legacy platform data. And HDMI needs both hdmi clock and dss clock to operate. Cc: Jyri Sarha <jsarha@ti.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Sebastian Reichel <sre@kernel.org> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-03-04ARM: dts: Configure interconnect target module for omap4 dsi2Tony Lindgren1-12/+30
We can now probe devices with device tree only configuration using ti-sysc interconnect target module driver. Let's configure the module and drop "ti,hwmods" peroperty as this module is a child node of dispc and has no dependencies to to legacy platform data. Cc: Jyri Sarha <jsarha@ti.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Sebastian Reichel <sre@kernel.org> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-03-04ARM: dts: Configure interconnect target module for omap4 dsi1Tony Lindgren1-12/+30
We can now probe devices with device tree only configuration using ti-sysc interconnect target module driver. Let's configure the module and drop "ti,hwmods" peroperty as this module is a child node of dispc and has no dependencies to to legacy platform data. Cc: Jyri Sarha <jsarha@ti.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Sebastian Reichel <sre@kernel.org> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-03-04ARM: dts: Configure interconnect target module for omap4 vencTony Lindgren1-7/+17
We can now probe devices with device tree only configuration using ti-sysc interconnect target module driver. Let's configure the module and drop "ti,hwmods" peroperty as this module is a child node of dispc and has no dependencies to to legacy platform data. We must now also configure sys_clk for reset to complete, the top level module only keeps optional clocks enabled for it's own reset. Cc: Jyri Sarha <jsarha@ti.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Sebastian Reichel <sre@kernel.org> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-03-04ARM: dts: Configure interconnect target module for omap4 rfbiTony Lindgren1-7/+25
We can now probe devices with device tree only configuration using ti-sysc interconnect target module driver. Let's configure the module and drop "ti,hwmods" peroperty as this module is a child node of dispc and has no dependencies to to legacy platform data. We must now also configure sys_clk for reset to complete, the top level module only keeps optional clocks enabled for it's own reset. Cc: Jyri Sarha <jsarha@ti.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Sebastian Reichel <sre@kernel.org> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-03-04ARM: dts: Configure interconnect target module for omap4 dispcTony Lindgren1-6/+31
We can now probe devices with device tree only configuration using ti-sysc interconnect target module driver. Let's configure the module, but keep the legacy "ti,hwmods" peroperty until the child devices are probing with ti-sysc interconnect driver. We must now also configure sys_clk for reset to complete, the top level module only keeps optional clocks enabled for it's own reset. Cc: Jyri Sarha <jsarha@ti.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Sebastian Reichel <sre@kernel.org> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-03-04ARM: dts: Configure interconnect target module for omap4 dssTony Lindgren2-70/+91
We can now probe devices with device tree only configuration using ti-sysc interconnect target module driver. Let's configure the module, but keep the legacy "ti,hwmods" peroperty until the child devices are probing with ti-sysc interconnect driver. The display subsystem (DSS) is in a 16MB interconnect target module mapped to l4 and l3 buses. We are only using the l3 port as recommended by the TRM. So there is no need to configure l4 ranges like we've done for l4 ABE instance for example. Initially let's just update the top level dss node to probe with ti-sysc interconnect target module driver. The child nodes are still children of dispc, only the node indentation changes for them now along with using the reg range provided by top level dss. Let's also add add a note about using only the l3 access without l4 as noted in the TRM. Cc: Jyri Sarha <jsarha@ti.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Sebastian Reichel <sre@kernel.org> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-03-04arm64: remove gratuitious/stray .ltorg stanzasRemi Denis-Courmont2-3/+0
There are no applicable literals above them. Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Remi Denis-Courmont <remi.denis.courmont@huawei.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2020-03-04arm64/mm: Enable memory hot removeAnshuman Khandual3-9/+374
The arch code for hot-remove must tear down portions of the linear map and vmemmap corresponding to memory being removed. In both cases the page tables mapping these regions must be freed, and when sparse vmemmap is in use the memory backing the vmemmap must also be freed. This patch adds unmap_hotplug_range() and free_empty_tables() helpers which can be used to tear down either region and calls it from vmemmap_free() and ___remove_pgd_mapping(). The free_mapped argument determines whether the backing memory will be freed. It makes two distinct passes over the kernel page table. In the first pass with unmap_hotplug_range() it unmaps, invalidates applicable TLB cache and frees backing memory if required (vmemmap) for each mapped leaf entry. In the second pass with free_empty_tables() it looks for empty page table sections whose page table page can be unmapped, TLB invalidated and freed. While freeing intermediate level page table pages bail out if any of its entries are still valid. This can happen for partially filled kernel page table either from a previously attempted failed memory hot add or while removing an address range which does not span the entire page table page range. The vmemmap region may share levels of table with the vmalloc region. There can be conflicts between hot remove freeing page table pages with a concurrent vmalloc() walking the kernel page table. This conflict can not just be solved by taking the init_mm ptl because of existing locking scheme in vmalloc(). So free_empty_tables() implements a floor and ceiling method which is borrowed from user page table tear with free_pgd_range() which skips freeing page table pages if intermediate address range is not aligned or maximum floor-ceiling might not own the entire page table page. Boot memory on arm64 cannot be removed. Hence this registers a new memory hotplug notifier which prevents boot memory offlining and it's removal. While here update arch_add_memory() to handle __add_pages() failures by just unmapping recently added kernel linear mapping. Now enable memory hot remove on arm64 platforms by default with ARCH_ENABLE_MEMORY_HOTREMOVE. This implementation is overall inspired from kernel page table tear down procedure on X86 architecture and user page table tear down method. [Mike and Catalin added P4D page table level support] Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2020-03-04arm64/mm: Hold memory hotplug lock while walking for kernel page table dumpAnshuman Khandual1-0/+4
The arm64 page table dump code can race with concurrent modification of the kernel page tables. When a leaf entries are modified concurrently, the dump code may log stale or inconsistent information for a VA range, but this is otherwise not harmful. When intermediate levels of table are freed, the dump code will continue to use memory which has been freed and potentially reallocated for another purpose. In such cases, the dump code may dereference bogus addresses, leading to a number of potential problems. Intermediate levels of table may by freed during memory hot-remove, which will be enabled by a subsequent patch. To avoid racing with this, take the memory hotplug lock when walking the kernel page table. Acked-by: David Hildenbrand <david@redhat.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2020-03-04ARM/arm64: dts: Rename SMB bus to just busLinus Walleij14-14/+14
Discussing the YAML validation schema with the DT maintainers it came out that a bus named "smb@80000000" is not really accepted, and the schema was written to name the static memory bus just "bus@80000000". This change is necessary for the schema to kick in and validate these device trees, else the schema gets ignored. Cc: Rob Herring <robh+dt@kernel.org> Acked-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-03-04ARM: dts: RealView: Fix the name of the SoC nodeLinus Walleij1-1/+1
Drop the surplus @0 on the soc node making the devicetree conform strictly to the schema. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-03-04ARM: dts: Versatile: Use syscon as node name for IB2Linus Walleij1-1/+1
The IB2 syscon should not have any funny names, just call it syscon@ as per the convention so the schema will apply properly. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-03-04ARM: dts: integratorap: Remove top level dma-rangesRob Herring1-1/+0
'dma-ranges' at the top level doesn't make sense. 'dma-ranges' implies there is a parent bus node with '#address-cells' and '#size-cells' which is impossible here. Likely this translation needs to be moved down to sub-nodes that need it. Cc: Linus Walleij <linus.walleij@linaro.org> Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-03-04powerpc/numa: Remove late request for home node associativitySrikar Dronamraju3-18/+0
With commit ("powerpc/numa: Early request for home node associativity"), commit 2ea626306810 ("powerpc/topology: Get topology for shared processors at boot") which was requesting home node associativity becomes redundant. Hence remove the late request for home node associativity. Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com> Reported-by: Abdul Haleem <abdhalee@linux.vnet.ibm.com> Reviewed-by: Nathan Lynch <nathanl@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20200129135301.24739-6-srikar@linux.vnet.ibm.com
2020-03-04powerpc/numa: Early request for home node associativitySrikar Dronamraju1-1/+40
Currently the kernel detects if its running on a shared lpar platform and requests home node associativity before the scheduler sched_domains are setup. However between the time NUMA setup is initialized and the request for home node associativity, workqueue initializes its per node cpumask. The per node workqueue possible cpumask may turn invalid after home node associativity resulting in weird situations like workqueue possible cpumask being a subset of workqueue online cpumask. This can be fixed by requesting home node associativity earlier just before NUMA setup. However at the NUMA setup time, kernel may not be in a position to detect if its running on a shared lpar platform. So request for home node associativity and if the request fails, fallback on the device tree property. Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com> Reported-by: Abdul Haleem <abdhalee@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20200129135301.24739-5-srikar@linux.vnet.ibm.com
2020-03-04powerpc/numa: Use cpu node map of first sibling threadSrikar Dronamraju1-2/+20
All the sibling threads of a core have to be part of the same node. To ensure that all the sibling threads map to the same node, always lookup/update the cpu-to-node map of the first thread in the core. Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com> Reported-by: Abdul Haleem <abdhalee@linux.vnet.ibm.com> Reviewed-by: Nathan Lynch <nathanl@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20200129135301.24739-4-srikar@linux.vnet.ibm.com
2020-03-04powerpc/numa: Handle extra hcall_vphn error casesSrikar Dronamraju1-9/+16
Currently code handles H_FUNCTION, H_SUCCESS, H_HARDWARE return codes. However hcall_vphn can return other return codes. Now it also handles H_PARAMETER return code. Also the rest return codes are handled under the default case. Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com> Reported-by: Abdul Haleem <abdhalee@linux.vnet.ibm.com> Reviewed-by: Nathan Lynch <nathanl@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20200129135301.24739-3-srikar@linux.vnet.ibm.com
2020-03-04powerpc/vphn: Check for error from hcall_vphnSrikar Dronamraju1-1/+2
There is no value in unpacking associativity, if H_HOME_NODE_ASSOCIATIVITY hcall has returned an error. Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com> Reported-by: Abdul Haleem <abdhalee@linux.vnet.ibm.com> Reviewed-by: Nathan Lynch <nathanl@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20200129135301.24739-2-srikar@linux.vnet.ibm.com
2020-03-04powerpc/smp: Use nid as fallback for package_idSrikar Dronamraju2-3/+33
package_id is to match cores that are part of the same chip. On PowerNV machines, package_id defaults to chip_id. However ibm,chip_id property is not present in device-tree of PowerVM LPARs. Hence lscpu output shows one core per socket and multiple cores. To overcome this, use nid as the package_id on PowerVM LPARs. Before the patch: Architecture: ppc64le Byte Order: Little Endian CPU(s): 128 On-line CPU(s) list: 0-127 Thread(s) per core: 8 Core(s) per socket: 1 <---------------------- Socket(s): 16 <---------------------- NUMA node(s): 2 Model: 2.2 (pvr 004e 0202) Model name: POWER9 (architected), altivec supported Hypervisor vendor: pHyp Virtualization type: para L1d cache: 32K L1i cache: 32K L2 cache: 512K L3 cache: 10240K NUMA node0 CPU(s): 0-63 NUMA node1 CPU(s): 64-127 # # cat /sys/devices/system/cpu/cpu0/topology/physical_package_id -1 After the patch: Architecture: ppc64le Byte Order: Little Endian CPU(s): 128 On-line CPU(s) list: 0-127 Thread(s) per core: 8 <--------------------- Core(s) per socket: 8 <--------------------- Socket(s): 2 NUMA node(s): 2 Model: 2.2 (pvr 004e 0202) Model name: POWER9 (architected), altivec supported Hypervisor vendor: pHyp Virtualization type: para L1d cache: 32K L1i cache: 32K L2 cache: 512K L3 cache: 10240K NUMA node0 CPU(s): 0-63 NUMA node1 CPU(s): 64-127 # # cat /sys/devices/system/cpu/cpu0/topology/physical_package_id 0 Now lscpu output is more in line with the system configuration. Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com> [mpe: Use pkg_id instead of ppid, tweak change log and comment] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20200129135121.24617-1-srikar@linux.vnet.ibm.com
2020-03-04powerpc/irq: Use current_stack_pointer in do_IRQ()Christophe Leroy1-1/+1
Until commit 7306e83ccf5c ("powerpc: Don't use CURRENT_THREAD_INFO to find the stack"), the current stack base address was obtained by calling current_thread_info(). That inline function was simply masking out the value of r1. In that commit, it was changed to using current_stack_pointer() (since renamed current_stack_frame()), which is a heavier function as it is an outline assembly function which cannot be inlined and which reads the content of the stack at 0(r1). Convert to using current_stack_pointer for geting r1 and masking out its value to obtain the base address of the stack pointer as before. Fixes: 7306e83ccf5c ("powerpc: Don't use CURRENT_THREAD_INFO to find the stack") Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20200220115141.2707-5-mpe@ellerman.id.au
2020-03-04powerpc/irq: use IS_ENABLED() in check_stack_overflow()Christophe Leroy1-2/+3
Instead of #ifdef, use IS_ENABLED(CONFIG_DEBUG_STACKOVERFLOW). This enable GCC to check for code validity even when the option is not selected. Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20200220115141.2707-4-mpe@ellerman.id.au
2020-03-04powerpc/irq: Use current_stack_pointer in check_stack_overflow()Christophe Leroy1-1/+1
The purpose of check_stack_overflow() is to verify that the stack has not overflowed. To really know whether the stack pointer is still within boundaries, the check must be done directly on the value of r1. So use current_stack_pointer, which returns the current value of r1, rather than current_stack_frame() which causes a frame to be created and then returns that value. Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20200220115141.2707-3-mpe@ellerman.id.au
2020-03-04powerpc: Add current_stack_pointer as a register globalChristophe Leroy1-0/+2
current_stack_frame() doesn't return the stack pointer, but the caller's stack frame. See commit bfe9a2cfe91a ("powerpc: Reimplement __get_SP() as a function not a define") and commit acf620ecf56c ("powerpc: Rename __get_SP() to current_stack_pointer()") for details. In some cases this is overkill or incorrect, as it doesn't return the current value of r1. So add a current_stack_pointer register global to get the value of r1 directly. Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> [mpe: Split out of other patch, tweak change log] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20200220115141.2707-2-mpe@ellerman.id.au
2020-03-04powerpc: Rename current_stack_pointer() to current_stack_frame()Michael Ellerman6-10/+10
current_stack_pointer(), which was called __get_SP(), used to just return the value in r1. But that caused problems in some cases, so it was turned into a function in commit bfe9a2cfe91a ("powerpc: Reimplement __get_SP() as a function not a define"). Because it's a function in a separate compilation unit to all its callers, it has the effect of causing a stack frame to be created, and then returns the address of that frame. This is good in some cases like those described in the above commit, but in other cases it's overkill, we just need to know what stack page we're on. On some other arches current_stack_pointer is just a register global giving the stack pointer, and we'd like to do that too. So rename our current_stack_pointer() to current_stack_frame() to make that possible. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Reviewed-by: Christophe Leroy <christophe.leroy@c-s.fr> Link: https://lore.kernel.org/r/20200220115141.2707-1-mpe@ellerman.id.au
2020-03-04powerpc/kernel/sysfs: Add new config option PMU_SYSFS to enable PMU SPRs sysfs file creationKajol Jain2-0/+12
Many of the performance monitoring unit (PMU) SPRs are exposed in the sysfs. This may not be a desirable since "perf" API is the primary interface to program PMU and collect counter data in the system. But that said, we cant remove these sysfs files since we dont whether anyone/anything is using them. So the patch adds a new CONFIG option 'CONFIG_PMU_SYSFS' (user selectable) to be used in sysfs file creation for PMU SPRs. New option by default is disabled, but can be enabled if user needs it. Tested this patch behaviour in powernv and pseries machines. Patch is also tested for pmac32_defconfig. Signed-off-by: Kajol Jain <kjain@linux.ibm.com> Tested-by: Nageswara R Sastry <nasastry@in.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20200214080606.26872-2-kjain@linux.ibm.com