summaryrefslogtreecommitdiffstats
path: root/arch/arm64/boot/dts/arm/juno-base.dtsi
Commit message (Collapse)AuthorAgeFilesLines
* arm64: dts: juno: Enable GPURobin Murphy2024-06-201-1/+0
| | | | | | | | | | | | Both Mali-T620 and Juno's HDLCD are now supported by upstream Mesa in recent distros, so there's little reason not to enable the GPU by default. At the very least it should offer a little extra CI coverage for Panfrost probing and wiggling SCMI. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Acked-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://lore.kernel.org/r/07e45a015ff8934c4571617c8e8e90205e430eb6.1718811097.git.robin.murphy@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* arm64: dts: juno: fix thermal zone node namesKrzysztof Kozlowski2024-03-251-2/+2
| | | | | | | | | | | | | | | Linux kernel uses thermal zone node name during registering thermal zones and has a hard-coded limit of 20 characters, including terminating NUL byte. Exceeding the limit will cause failure to configure thermal zone. Reported-by: Rob Herring <robh@kernel.org> Closes: https://lore.kernel.org/all/CAL_JsqKogbT_4DPd1n94xqeHaU_J8ve5K09WOyVsRX3jxxUW3w@mail.gmail.com/ Fixes: fb4d25d7a33f ("arm64: dts: juno: Align thermal zone names with bindings") Reviewed-by: Rob Herring <robh@kernel.org> Acked-by: Sudeep Holla <sudeep.holla@arm.com> Link: https://lore.kernel.org/r/20240103142051.111717-2-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
* arm64: dts: juno: Align thermal zone names with bindingsKrzysztof Kozlowski2023-12-121-6/+6
| | | | | | | | | | | | | | | Thermal bindings require thermal zone node names to match certain patterns: | juno.dtb: thermal-zones: 'big-cluster', 'gpu0', 'gpu1', | 'little-cluster', 'pmic', 'soc' | do not match any of the regexes: | '^[a-zA-Z][a-zA-Z0-9\\-]{1,12}-thermal$', 'pinctrl-[0-9]+' Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://lore.kernel.org/r/20231209171612.250868-1-krzysztof.kozlowski@linaro.org Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* arm64: dts: juno: Add thermal critical trip pointsCristian Marussi2022-11-011-0/+14
| | | | | | | | | | | | | | | | | When thermnal zones are defined, trip points definitions are mandatory. Define a couple of critical trip points for monitoring of existing PMIC and SOC thermal zones. This was lost between txt to yaml conversion and was re-enforced recently via the commit 8c596324232d ("dt-bindings: thermal: Fix missing required property") Cc: Rob Herring <robh+dt@kernel.org> Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org> Cc: devicetree@vger.kernel.org Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Fixes: f7b636a8d83c ("arm64: dts: juno: add thermal zones for scpi sensors") Link: https://lore.kernel.org/r/20221028140833.280091-8-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* arm64: dts: juno: Add missing MHU secure-irqJassi Brar2022-08-151-1/+2
| | | | | | | | | | | The MHU secure interrupt exists physically but is missing in the DT node. Specify the interrupt in DT node to fix a warning on Arm Juno board: mhu@2b1f0000: interrupts: [[0, 36, 4], [0, 35, 4]] is too short Link: https://lore.kernel.org/r/20220801141005.599258-1-jassisinghbrar@gmail.com Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* arm64: dts: arm: adjust whitespace around '='Krzysztof Kozlowski2022-06-141-22/+22
| | | | | | | | | | | Fix whitespace coding style: use single space instead of tabs or multiple spaces around '=' sign in property assignment. No functional changes (same DTB). Link: https://lore.kernel.org/r/20220526204350.832361-1-krzysztof.kozlowski@linaro.org Acked-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* arm64: dts: juno: Drop useless 'dma-channels/requests' propertiesKrzysztof Kozlowski2022-04-301-2/+0
| | | | | | | | | | | | | | | | | The pl330 DMA controller provides number of DMA channels and requests through its registers, so duplicating this information (with a chance of mistakes) in DTS is pointless. Additionally the DTS used always wrong property names which causes DT schema check failures - the bindings documented 'dma-channels' and 'dma-requests' properties without leading hash sign. Another reason is that the number of requests also does not seem right (should be 8). Link: https://lore.kernel.org/r/20220430121902.59895-5-krzysztof.kozlowski@linaro.org Reported-by: Rob Herring <robh@kernel.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* arm64: dts: juno: add CTI entries to device treeMike Leach2022-04-141-4/+158
| | | | | | | | | | Add Coresight Cross Trigger Interface(CTI) entries to the device tree for all the Juno variants. Link: https://lore.kernel.org/r/20220413214925.30359-1-mike.leach@linaro.org Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Mike Leach <mike.leach@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* Merge tag 'dt64-cleanup-5.18' of ↵Arnd Bergmann2022-03-081-1/+1
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux into arm/dt Minor cleanup of ARM64 DTS for v5.18 The DT schema expects DMA controller nodes to follow certain node naming and having dma-cells property. Adjust the DTS files to pass DT schema checks. * tag 'dt64-cleanup-5.18' of git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux: arm64: dts: lg: align pl330 node name with dtschema arm64: dts: lg: add dma-cells to pl330 node arm64: dts: juno: align pl330 node name with dtschema Link: https://lore.kernel.org/r/20220307173614.157884-1-krzysztof.kozlowski@canonical.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
| * arm64: dts: juno: align pl330 node name with dtschemaKrzysztof Kozlowski2022-03-021-1/+1
| | | | | | | | | | | | | | | | | | Fixes dtbs_check warning: dma@7ff00000: $nodename:0: 'dma@7ff00000' does not match '^dma-controller(@.*)?$' Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Link: https://lore.kernel.org/r/20220129175621.299254-1-krzysztof.kozlowski@canonical.com
* | arm64: dts: juno: Remove GICv2m dma-rangeRobin Murphy2022-01-261-2/+1
|/ | | | | | | | | | | | | | | | | | | | | Although it is painstakingly honest to describe all 3 PCI windows in "dma-ranges", it misses the the subtle distinction that the window for the GICv2m range is normally programmed for Device memory attributes rather than Normal Cacheable like the DRAM windows. Since MMU-401 only offers stage 2 translation, this means that when the PCI SMMU is enabled, accesses through that IPA range unexpectedly lose coherency if mapped as cacheable at the SMMU, due to the attribute combining rules. Since an extra 256KB is neither here nor there when we still have 10GB worth of usable address space, rather than attempting to describe and cope with this detail let's just remove the offending range. If the SMMU is not used then it makes no difference anyway. Link: https://lore.kernel.org/r/856c3f7192c6c3ce545ba67462f2ce9c86ed6b0c.1643046936.git.robin.murphy@arm.com Fixes: 4ac4d146cb63 ("arm64: dts: juno: Describe PCI dma-ranges") Reported-by: Anders Roxell <anders.roxell@linaro.org> Acked-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* arm: dts: vexpress: Fix addressing issues with 'motherboard-bus' nodesRob Herring2021-09-171-10/+0
| | | | | | | | | | | | | | | | | | | The 'motherboard-bus' node in Arm Ltd boards fails schema checks as 'simple-bus' child nodes must have a unit-address. The 'ranges' handling is also wrong (or at least strange) as the mapping of SMC chip selects should be in the 'arm,vexpress,v2m-p1' node rather than a generic 'simple-bus' node. Either there's 1 too many levels of 'simple-bus' nodes or 'ranges' should be moved down a level. The latter change is more simple, so let's do that. As the 'ranges' value doesn't vary for a given motherboard instance, we can move 'ranges' into the motherboard dtsi files. Link: https://lore.kernel.org/r/20210819184239.1192395-6-robh@kernel.org Cc: Andre Przywara <andre.przywara@arm.com> Cc: Sudeep Holla <sudeep.holla@arm.com> Cc: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* arm64: dts: arm: drop unused interrupt-names in MHUKrzysztof Kozlowski2021-09-141-2/+0
| | | | | | | | | | | | The arm,mhu bindings and driver do not define interrupt-names, so drop the property to fix warnings: arch/arm64/boot/dts/arm/juno-r2.dt.yaml: mhu@2b1f0000: 'interrupt-names' does not match any of the regexes: 'pinctrl-[0-9]+' Link: https://lore.kernel.org/r/20210820081733.83976-3-krzysztof.kozlowski@canonical.com Acked-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* arm64: dts: juno: Update SCPI nodes as per the YAML schemaSudeep Holla2021-06-091-3/+3
| | | | | | | | | The SCPI YAML schema expects standard node names for clocks and power domain controllers. Fix those as per the schema for Juno platforms. Link: https://lore.kernel.org/r/20210608145133.2088631-1-sudeep.holla@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* arm64: dts: juno: Enable more SMMUsRobin Murphy2021-03-151-1/+0
| | | | | | | | | | | | | | | Now that PCI inbound window restrictions are handled generically between the of_pci resource parsing and the IOMMU layer, and described in the Juno DT, we can finally enable the PCIe SMMU without the risk of DMA mappings inadvertently allocating unusable addresses. Similarly, the relevant support for IOMMU mappings for peripheral transfers has been hooked up in the pl330 driver for ages, so we can happily enable the DMA SMMU without that breaking anything either. Link: https://lore.kernel.org/r/a730070d718cb119f77c8ca1782a0d4189bfb3e7.1614965598.git.robin.murphy@arm.com Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* arm64: dts: juno: Describe PCI dma-rangesRobin Murphy2021-03-151-0/+4
| | | | | | | | | | | | | The PLDA root complex on Juno relies on an address-based lookup table to generate AXI attributes for inbound PCI transactions, and as such will not pass any transaction not matching any programmed address range. The standard firmware configuration programs 3 entries covering the GICv2m MSI doorbell and the 2 DRAM regions, so add a "dma-ranges" property to describe those usable inbound windows. Link: https://lore.kernel.org/r/720d0a9a42e33148fcac45cd39a727093a32bf32.1614965598.git.robin.murphy@arm.com Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* arm64: dts: juno: Fix SCPI shared mem node nameAndre Przywara2020-05-181-2/+2
| | | | | | | | | | | The SRAM DT binding requires child nodes to use a certain node name scheme. Change the naming from scp-shmem to scp-sram to comply with that. Link: https://lore.kernel.org/r/20200513103016.130417-19-andre.przywara@arm.com Signed-off-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* arm64: dts: juno: Fix GPU interrupt orderAndre Przywara2020-05-181-4/+4
| | | | | | | | | | The Mali binding insists on the GPU interrupts to be in ordered as: job, mmu, gpu. Sort the GPU interrupts and interrupt-names properties accordingly. Link: https://lore.kernel.org/r/20200513103016.130417-17-andre.przywara@arm.com Signed-off-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* arm64: dts: fvp/juno: Fix bus node namesAndre Przywara2020-05-181-1/+1
| | | | | | | | | | | | | | | Most Arm Ltd. boards are employing a layered bus structure, to map the hardware design (SoC, motherboard, IOFPGA) and structure the DTs. The "simple-bus" nodes only allow a limited set of node names. Switch to use *-bus to be binding compliant. This relies on a pending dt-schema.git fix for now: https://github.com/devicetree-org/dt-schema/pull/38 Link: https://lore.kernel.org/r/20200513103016.130417-16-andre.przywara@arm.com Signed-off-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* arm64: dts: fvp/juno: Fix serial node namesAndre Przywara2020-05-181-1/+1
| | | | | | | | | | | | The UARTs for all Arm Ltd. boards were using "uart" as their node name stub. Replace that with the required "serial" string, to comply with the PL011 DT binding. Link: https://lore.kernel.org/r/20200513103016.130417-14-andre.przywara@arm.com Signed-off-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* arm64: dts: juno: Use proper DT node name for USBAndre Przywara2020-05-181-2/+2
| | | | | | | | | | The EHCI/OCHI DT binding requires to use "usb" as the node name stub. Replace the existing name with "usb" to comply with the binding. Link: https://lore.kernel.org/r/20200513103016.130417-13-andre.przywara@arm.com Signed-off-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* arm64: dts: juno: Fix GIC child nodesAndre Przywara2020-05-171-25/+25
| | | | | | | | | | | | | | | The GIC DT nodes for the Juno boards were not fully compliant with the DT binding, which has certain expectations about child nodes and their size and address cells values. Use smaller #address-cells and #size-cells values, as the binding requests, and adjust the reg properties accordingly. This requires adjusting the interrupt nexus nodes as well, as one field of the interrupt-map property depends on the GIC's address-size. Link: https://lore.kernel.org/r/20200513103016.130417-10-andre.przywara@arm.com Signed-off-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* arm64: dts: juno: Fix mem-timerAndre Przywara2020-05-171-4/+4
| | | | | | | | | | | | | The Juno's mem-timer DT node was not fully compliant with the DT binding, which has certain expectation about child nodes and their size and address cells values. Use a cell size of 1, as the binding requests, and spell out the ranges property to be binding compliant. Link: https://lore.kernel.org/r/20200513103016.130417-8-andre.przywara@arm.com Signed-off-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* ARM/arm64: dts: Rename SMB bus to just busLinus Walleij2020-03-041-1/+1
| | | | | | | | | | | | | | 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>
* Revert "arm64: dts: juno: add dma-ranges property"Sudeep Holla2019-11-281-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 193d00a2b35ee3353813b4006a18131122087205. Commit 951d48855d86 ("of: Make of_dma_get_range() work on bus nodes") reworked the logic such that of_dma_get_range() works correctly starting from a bus node containing "dma-ranges". Since on Juno we don't have a SoC level bus node and "dma-ranges" is present only in the root node, we get the following error: OF: translation of DMA address(0) to CPU address failed node(/sram@2e000000) OF: translation of DMA address(0) to CPU address failed node(/uart@7ff80000) ... OF: translation of DMA address(0) to CPU address failed node(/mhu@2b1f0000) OF: translation of DMA address(0) to CPU address failed node(/iommu@2b600000) OF: translation of DMA address(0) to CPU address failed node(/iommu@2b600000) OF: translation of DMA address(0) to CPU address failed node(/iommu@2b600000) So let's fix it by dropping the "dma-ranges" property for now. This should be fine since it doesn't represent any kind of device-visible restriction; it was only there for completeness, and we've since given in to the assumption that missing "dma-ranges" implies a 1:1 mapping anyway. We can add it later with a proper SoC bus node and moving all the devices that belong there along with the "dma-ranges" if required. Fixes: 193d00a2b35e ("arm64: dts: juno: add dma-ranges property") Cc: Rob Herring <robh+dt@kernel.org> Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* arm64: dts: juno: add GPU subsystemRobin Murphy2019-10-211-0/+27
| | | | | | | | | | | | | | | | Since we now have bindings for Mali Midgard GPUs, let's use them to describe Juno's GPU subsystem, if only because we can. Juno sports a Mali-T624 integrated behind an MMU-400 (as a gesture towards virtualisation), in their own dedicated power domain with DVFS controlled by the SCP. CC: Liviu Dudau <liviu.dudau@arm.com> CC: Sudeep Holla <sudeep.holla@arm.com> CC: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Acked-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* arm64: dts: juno: update coresight DT bindingsLeo Yan2019-05-281-3/+3
| | | | | | | | | | | | | | | | CoreSight DT bindings have been updated, thus the old compatible strings are obsolete and the drivers will report warning if DTS uses these obsolete strings. This patch switches to the new bindings for CoreSight dynamic funnel, so can dismiss warning during initialisation. Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Acked-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Leo Yan <leo.yan@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* arm64: dts: juno/fast models: sort couple of device nodesSudeep Holla2019-01-291-35/+35
| | | | | | | Sort the couple device nodes with unit addresses which are out of order. Acked-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* arm64: dts: juno/fast models: using GIC macros instead of hardcoded valuesSudeep Holla2019-01-291-19/+19
| | | | | | | | | | | | | | There are macros that exist to indicate the GIC specific flags and custom cell values as per the GIC DT bindings. It's used in most of the places in these DTS files but not all. To maintain consistency, lets use the macros at all the places. Since DTC doesn't even warn is any cells are missing, it's very hard to debug if that's the case. Changing to use macros avoids missing cells/ columns. Acked-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* arm64: dts: juno: Enable coresight tmc scatter gather in ETRSuzuki K Poulose2018-09-111-0/+1
| | | | | | | | | | | | | | | | | | We do not enable scatter-gather mode in the TMC-ETR by default to prevent malfunctioning of systems where the ETR may not be properly connected to the memory subsystem to allow for simultaneous READ/WRITE transactions when used in SG mode. Instead we whitelist the platforms where we know that it is safe to use the mode. All revisions of Juno have a proper ETR connection and hence white list them. Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Cc: Mike Leach <mike.leach@linaro.org> Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Lorenzo Pierlisi <lorenzo.pieralisi@arm.com> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* arm64: dts: juno: Update entries to match latest coresight bindingsSuzuki K Poulose2018-09-101-79/+82
| | | | | | | | | | | Switch to updated coresight bindings for Juno platforms. Cc: Liviu Dudau <liviu.dudau@arm.com> Acked-by: Liviu Dudau <liviu.dudau@arm.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> [sudeep.holla: minor modifications to patch title] Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* arm64: dts: juno/rtsm: re-structure motherboard includesSudeep Holla2018-05-101-2/+1
| | | | | | | | | | | | | | | | | It is a bit unorthodox to just include a file in the middle of a another DTS file, it breaks the pattern from other device trees and also makes it really hard to reference things across the files with phandles. Restructure the include for the Juno/RTSM motherboards to happen at the top of the file, reference the target nodes directly, and indent the motherboard .dtsi files to reflect their actual depth in the hierarchy. This is a purely syntactic change that result in the same DTB files from the DTS/DTSI files. This is based on similar patch from Linus Walleij for ARM Vexpress platforms. Acked-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* arm64: dts: juno: replace '_' with '-' in node namesSudeep Holla2018-05-101-2/+2
| | | | | | | | | | | | | | | | | The latest DTC throws warnings for character '_' in the node names. Warning (node_name_chars_strict): /thermal-zones/big_cluster: Character '_' not recommended in node name Warning (node_name_chars_strict): /thermal-zones/little_cluster: Character '_' not recommended in node name Warning (node_name_chars_strict): /smb@8000000/motherboard/gpio_keys: Character '_' not recommended in node name Warning (node_name_chars_strict): /pmu_a57: Character '_' not recommended in node name Warning (node_name_chars_strict): /pmu_a53: Character '_' not recommended in node name The general recommendation is to use character '-' for all the node names. This patch fixes the warnings following the recommendation. Acked-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* arm64: dts: juno: fix OF graph endpoint node namesRob Herring2018-05-091-4/+4
| | | | | | | | | | | | | | | OF graph endpoint node names should be 'endpoint'. Fix the following warnings found by dtc: Warning (graph_endpoint): /hdlcd@7ff50000/port/hdlcd1-endpoint: graph endpont node nameshould be 'endpoint' Warning (graph_endpoint): /hdlcd@7ff60000/port/hdlcd0-endpoint: graph endpont node nameshould be 'endpoint' Warning (graph_endpoint): /i2c@7ffa0000/hdmi-transmitter@70/port/tda998x-0-endpoint: graph endpont node name should be 'endpoint' Warning (graph_endpoint): /i2c@7ffa0000/hdmi-transmitter@71/port/tda998x-1-endpoint: graph endpont node name should be 'endpoint' Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* arm64: dts: juno: fix size of GICv2m MSI framesSudeep Holla2018-02-281-4/+4
| | | | | | | | | | | | | | | | | | Currently the size of GICv2m MSI frames are listed as 4kB while the Juno TRM specifies 64kB for each of these MSI frames. Though the devices connected themselves might just use the first 4kB, to be consistent with the general practice of 64kB boundary alignment to all the devices, let's keep the size as 64kB. This might also help in avoiding any surprise when passing the device to a VM. This patch increases the size of each GICv2m MSI frames from 4kB to 64kB as per the specification. Cc: Liviu Dudau <liviu.dudau@arm.com> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Reviewed-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* arm64: dts: juno: Describe the full GICv2m regionRobin Murphy2018-02-261-0/+19
| | | | | | | | | | | Juno's GICv2m implementation consists of four frames providing 32 interrupts each. Since it is possible to plug in enough PCIe endpoints to consume more than 32 MSIs, and the driver already has a bodge to handle multiple frames, let's expose the other three as well. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* License cleanup: add SPDX GPL-2.0 license identifier to files with no licenseGreg Kroah-Hartman2017-11-021-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license. By default all files without license information are under the default license of the kernel, which is GPL version 2. Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne. How this work was done: Patches were generated and checked against linux-4.14-rc6 for a subset of the use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information, Further patches will be generated in subsequent months to fix up cases where non-standard license headers were used, and references to license had to be inferred by heuristics based on keywords. The analysis to determine which SPDX License Identifier to be applied to a file was done in a spreadsheet of side by side results from of the output of two independent scanners (ScanCode & Windriver) producing SPDX tag:value files created by Philippe Ombredanne. Philippe prepared the base worksheet, and did an initial spot review of a few 1000 files. The 4.13 kernel was the starting point of the analysis with 60,537 files assessed. Kate Stewart did a file by file comparison of the scanner results in the spreadsheet to determine which SPDX license identifier(s) to be applied to the file. She confirmed any determination that was not immediately clear with lawyers working with the Linux Foundation. Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines). All documentation files were explicitly excluded. The following heuristics were used to determine which SPDX license identifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time. In total, over 70 hours of logged manual review was done on the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation. Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related. Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files. In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier. Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified. These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches. Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* arm64: dts: juno: replace underscores with hyphen in device node namesSudeep Holla2017-08-021-6/+6
| | | | | | | | | Since underscores('_') are not allowed in the device tree nodes names, replace all of them with hyphen('-') in device node names. Note that underscores are however allowed in labels. Reported-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* arm64: dts: juno: Use the new coresight replicator stringSuzuki K. Poulose2017-08-021-1/+1
| | | | | | | | | | Use the new compatible for ATB programmable replicator in Juno. Cc: Mike Leach <mike.leach@linaro.org> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Acked-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* arm64: dts: juno: enable some SMMUsRobin Murphy2017-05-191-4/+0
| | | | | | | | | | | | | | | | | | The IOMMU-backed DMA API support has now been in place for a while and proven stable, so there's no real need to keep most of Juno's SMMUs disabled. The USB, HDLCDs, and CoreSight ETR all just need to map RAM buffers for DMA - enabling their SMMUs obviates CPU bounce buffering for USB's streaming DMA to the upper memory bank, and lets the other two allocate their relatively large coherent buffers without pressuring CMA. Some more software work is still needed for the DMA-330 and PCIe before those can accommodate SMMU translation correctly in all cases, so we leave those alone for now. Tested-by: Liviu Dudau <Liviu.Dudau@arm.com> [only HDLCD] Acked-by: Liviu Dudau <Liviu.Dudau@arm.com> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* arm64: dts: juno: add coresight CPU debug nodesSuzuki K Poulose2017-05-191-0/+54
| | | | | | | | | | | | | Add Coresight CPU debug nodes for Juno r0, r1 & r2. The CPU debug areas are mapped at the same address for all revisions, like the ETM, even though the CPUs have changed from r1 to r2. Cc: Leo Yan <leo.yan@linaro.org> Cc: Mathieu Poirier <mathieu.porier@linaro.org> Cc: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> [arranged nodes in ascending order with respect to register addresses] Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* arm64: dts: juno: fix few unit address format warningsSudeep Holla2017-04-191-1/+1
| | | | | | | | | | | | | | | This patch fixes the following set of warnings on juno. smb@08000000 unit name should not have leading 0s sysctl@020000 simple-bus unit address format error, expected "20000" apbregs@010000 simple-bus unit address format error, expected "10000" mmci@050000 simple-bus unit address format error, expected "50000" kmi@060000 simple-bus unit address format error, expected "60000" kmi@070000 simple-bus unit address format error, expected "70000" wdt@0f0000 simple-bus unit address format error, expected "f0000" Acked-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* arm64: dts: juno: fix PCI bus dtc warningsRob Herring2017-03-311-1/+1
| | | | | | | | | dtc recently added PCI bus checks. Fix these warnings. Signed-off-by: Rob Herring <robh@kernel.org> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* arm64: dts: juno: update definition for programmable replicatorMike Leach2017-02-211-6/+7
| | | | | | | | | | | | | | | | | Juno platforms have a programmable replicator splitting the trace output to TPIU and ETR. Currently this is not being programmed as it is being treated as a none-programmable replicator - which is the default operational mode for these devices. The TPIU in the system is enabled by default, and this combination is causing back-pressure in the trace system resulting in overflows at the source. Replaces the existing definition with one that defines the programmable replicator, using the "qcom,coresight-replicator1x" driver that provides the correct functionality for CoreSight programmable replicators. Reviewed-and-Tested-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Mike Leach <mike.leach@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* arm64: dts: juno: add ETR SMMU power domainRobin Murphy2017-01-181-0/+1
| | | | | | | | | | | | | | It is not at all clear from the documentation, but straightforward to determine in practice, that the ETR SMMU is actually in the DEBUGSYS power domain. Add that to the DT so that anyone brave enough to enable said SMMU doesn't experience a system lockup on boot, especially a sneaky one which goes away as soon as you connect an external debugger to have a look at where it's stuck (thus powering up DEBUGSYS by other means and allowing it to make progress again before actually halting...) Acked-by: Liviu Dudau <Liviu.Dudau@arm.com> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* arm64: dts: juno: add dma-ranges propertyRobin Murphy2017-01-181-0/+1
| | | | | | | | | | | The interconnects around Juno have a 40-bit address width, and DMA masters have no restrictions beyond their own individual limitations. Describe this to ensure that DT-based DMA masks get set up correctly for all devices capable of 40-bit addressing. Acked-by: Liviu Dudau <Liviu.Dudau@arm.com> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* arm64: dts: juno: add missing CoreSight STM componentMike Leach2017-01-181-0/+15
| | | | | | | | | | | | | | | This patch adds the missing CoreSight STM component definition to the device tree of all the juno variants(r0,r1,r2) STM component is connected to different funnels depending on Juno platform variant. Reviewed-and-tested-by: Mathieu Poirier <mathieu.poirier@linaro.org> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Mike Leach <mike.leach@linaro.org> [sudeep.holla@arm.com: minor changelog update and reorganising the STM node back into juno-base.dtsi to avoid duplication] Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* arm64: dts: juno: refactor CoreSight support on Juno r0Sudeep Holla2017-01-181-10/+10
| | | | | | | | | | | | | Currently the Coresight components are supported only on Juno r0 variant. In preparation to add support to Juno r1/r2 variants, this patch refactors the existing coresight device nodes so that r1/r2 support can be added easily. It also cleans up some of the device node names which were previously named so as they were confused as the labels rather than the node names. Reviewed-and-tested-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* arm64: dts: juno: remove dtsi nesting inside tree structureSudeep Holla2017-01-181-2/+4
| | | | | | | | | | | Currently juno-clock.dtsi and juno-base.dtsi are nested badly inside the device tree structure. It's generally good practice to ensure that individual dtsi stand by themselves at the top of the file. This patch removes the nesting of the above mentioned dtsi files and makes them independent. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* Merge tag 'armsoc-dt64' of ↵Linus Torvalds2016-12-151-0/+80
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc Pull ARM 64-bit DT updates from Arnd Bergmann: "A couple of interesting new SoC platforms are now supported, these are the respective DTS sources: - Samsung Exynos5433 mobile phone platform, including an (almost) fully supported phone reference board. - Hisilicon Hip07 server platform and D05 board, the latest iteration of their product line, now with 64 Cortex-A72 cores across two sockets. - Allwinner A64 SoC, the first 64-bit chip from their "sunxi" product line, used in Android tablets and ultra-cheap development boards - NXP LS1046A Communication processor, improving on the earlier LS1043A with faster CPU cores - Qualcomm MSM8992 (Snapdragon 808) and MSM8994 (Snapdragon 810) mobile phone SoCs - Early support for the Nvidia Tegra Tegra186 SoC - Amlogic S905D is a minor variant of their existing Android consumer product line - Rockchip PX5 automotive platform, a close relative of their popular rk3368 Android tablet chips Aside from the respective evaluation platforms for the above chips, there are only a few consumer devices and boards added this time: - Huawei Nexus 6P (Angler) mobile phone - LG Nexus 5x (Bullhead) mobile phone - Nexbox A1 and A95X Android TV boxes - Pine64 development board based on Allwinner A64 - Globalscale Marvell ESPRESSOBin community board based on Armada 3700 - Renesas "R-Car Starter Kit Pro" (M3ULCB) low-cost automotive board For the existing platforms, we get bug fixes and new peripheral support for Juno, Renesas, Uniphier, Amlogic, Samsung, Broadcom, Rockchip, Berlin, and ZTE" * tag 'armsoc-dt64' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (168 commits) arm64: dts: fix build errors from missing dependencies ARM64: dts: meson-gxbb: add SCPI pre-1.0 compatible ARM64: dts: meson-gxl: Add support for Nexbox A95X ARM64: dts: meson-gxm: Add support for the Nexbox A1 ARM: dts: artpec: add pcie support arm64: dts: berlin4ct-dmp: add missing unit name to /memory node arm64: dts: berlin4ct-stb: add missing unit name to /memory node arm64: dts: berlin4ct: add missing unit name to /soc node arm64: dts: qcom: msm8916: Add ddr support to sdhc1 arm64: dts: exynos: Enable HS400 mode for eMMC for TM2 ARM: dts: Add xo to sdhc clock node on qcom platforms ARM64: dts: Add support for Meson GXM dt-bindings: add rockchip RK1108 Evaluation board arm64: dts: NS2: Add PCI PHYs arm64: dts: NS2: enable sdio1 arm64: dts: exynos: Add the mshc_2 node for supporting T-Flash arm64: tegra: Add NVIDIA P2771 board support arm64: tegra: Enable PSCI on P3310 arm64: tegra: Add NVIDIA P3310 processor module support arm64: tegra: Add GPIO controllers on Tegra186 ...
generated by cgit v1.2.3 (git 2.25.1) at 2024-10-11 07:52:07 +0000