Johan Hovold [Mon, 27 Mar 2023 12:29:48 +0000 (14:29 +0200)]
arm64: dts: qcom: sc8280xp-pmics: fix pon compatible and registers
The pmk8280 PMIC PON peripheral is gen3 and uses two sets of registers;
hlos and pbs.
This specifically fixes the following error message during boot when the
pbs registers are not defined:
PON_PBS address missing, can't read HW debounce time
Note that this also enables the spurious interrupt workaround introduced
by commit 0b65118e6ba3 ("Input: pm8941-pwrkey - add software key press
debouncing support") (which may or may not be needed).
Johan Hovold [Mon, 27 Mar 2023 12:32:43 +0000 (14:32 +0200)]
arm64: dts: qcom: sc8280xp-x13s: drop bogus 'input-enable'
The sc8280xp pin controller does not have a way to enable or disable the
input buffer so drop the unnecessary 'input-enable' property which is
about to be deprecated.
Krzysztof Kozlowski [Fri, 24 Mar 2023 20:22:44 +0000 (21:22 +0100)]
arm64: dts: qcom: sdm630: move DSI opp-table into DSI node
The soc node is supposed to have only device nodes with MMIO addresses,
so move the DSI OPP into the DSI controller node to fix:
sda660-inforce-ifc6560.dtb: soc: opp-table-dsi: {'compatible': ['operating-points-v2'], ... should not be valid under {'type': 'object'}
From schema: dtschema/schemas/simple-bus.yaml
Krzysztof Kozlowski [Fri, 24 Mar 2023 20:22:43 +0000 (21:22 +0100)]
arm64: dts: qcom: msm8996-xiaomi: drop simple-bus from clocks
'clocks' node is not a bus, but just a placeholder for clocks:
msm8996-xiaomi-gemini.dtb: clocks: $nodename:0: 'clocks' does not match '^([a-z][a-z0-9\\-]+-bus|bus|localbus|soc|axi|ahb|apb)(@.+)?$'
From schema: dtschema/schemas/simple-bus.yaml
msm8996-xiaomi-gemini.dtb: clocks: xo-board: {'compatible': ['fixed-clock'], '#clock-cells': [[0]], ...
From schema: dtschema/schemas/simple-bus.yaml
Krzysztof Kozlowski [Fri, 24 Mar 2023 20:22:42 +0000 (21:22 +0100)]
arm64: dts: qcom: msm8994-msft-lumia: drop simple-bus from clocks
'clocks' node is not a bus, but just a placeholder for clocks:
msm8992-msft-lumia-octagon-talkman.dtb: clocks: $nodename:0: 'clocks' does not match '^([a-z][a-z0-9\\-]+-bus|bus|localbus|soc|axi|ahb|apb)(@.+)?$'
From schema: dtschema/schemas/simple-bus.yaml
msm8992-msft-lumia-octagon-talkman.dtb: clocks: xo-board: {'compatible': ['fixed-clock'], '#clock-cells': [[0]], ...
From schema: dtschema/schemas/simple-bus.yaml
Krzysztof Kozlowski [Fri, 24 Mar 2023 20:22:41 +0000 (21:22 +0100)]
arm64: dts: qcom: apq8096-db820c: drop simple-bus from clocks
'clocks' node is not a bus, but just a placeholder for clocks:
apq8096-db820c.dtb: clocks: $nodename:0: 'clocks' does not match '^([a-z][a-z0-9\\-]+-bus|bus|localbus|soc|axi|ahb|apb)(@.+)?$'
From schema: dtschema/schemas/simple-bus.yaml
apq8096-db820c.dtb: clocks: xo-board: {'compatible': ['fixed-clock'], '#clock-cells': [[0]], ...
From schema: dtschema/schemas/simple-bus.yaml
Enable both touchpad nodes in the devictree and let the HID driver
determine which one is actually populated (by attempting to read from
each i2c address).
Ideally this would not be needed and the boot firmware should instead
enable only the node for the populated touchpad, but this is unlikely to
ever be realised for the X13s.
Note that the pin configuration must currently be moved to the parent
i2c-bus node even though only one of these nodes will ever be
successfully probed on a specific device (e.g. to allow them to be
probed in parallel).
sc7280-herobrine-evoker-lte.dtb: codec@1a: 'DBVDD-supply' is a required property
sc7280-herobrine-evoker-lte.dtb: codec@1a: 'LDO1-IN-supply' is a required property
In sc7180-trogdor.dtsi they come from the same regulator, so let's
assume intention was the same here.
Downstream DTS uses 16 mA drive strength for the WCD9385 audio codec
RESET_N reset pin. It also pulls the pin down in shutdown mode, thus it
is more like a shutdown pin, not a reset. Use the same settings here
for HDK8450 and keep the WCD9385 by default in powered off (so pin as
low). Align the name of pin configuration node with other pins in the
DTS.
Krzysztof Kozlowski [Wed, 8 Mar 2023 14:27:12 +0000 (15:27 +0100)]
arm64: dts: qcom: sm8450-hdk: use recommended drive strength for speaker SD_N
Downstream DTS (and sc8280xp-lenovo-thinkpad-x13s with the same
speakers) uses 16 mA drive strength for the WSA8835 speaker SD_N
reset/shutdown pin. Use the same for HDK8450, as it is seem the
recommended value.
Krzysztof Kozlowski [Sun, 5 Mar 2023 15:43:08 +0000 (16:43 +0100)]
arm64: dts: qcom: pm660: align thermal node names with bindings
Bindings expect thermal node names to end with '-thermal', so fix pm660
and pm660l:
sda660-inforce-ifc6560.dtb: thermal-zones: 'pm660', 'pm660l' do not match any of the regexes: '^[a-zA-Z][a-zA-Z0-9\\-]{1,12}-thermal$', 'pinctrl-[0-9]+'
Krzysztof Kozlowski [Sat, 4 Mar 2023 13:03:15 +0000 (14:03 +0100)]
arm64: dts: qcom: sm8350-microsoft-surface: fix USB dual-role mode property
The "dr_mode" is a property of USB DWC3 node, not the Qualcomm wrapper
one:
sm8350-microsoft-surface-duo2.dtb: usb@a6f8800: 'dr_mode' does not match any of the regexes: '^usb@[0-9a-f]+$', 'pinctrl-[0-9]+'
Fixes: c16160cfa565 ("arm64: dts: qcom: add minimal DTS for Microsoft Surface Duo 2") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230304130315.51595-2-krzysztof.kozlowski@linaro.org
Krzysztof Kozlowski [Sat, 4 Mar 2023 13:03:14 +0000 (14:03 +0100)]
arm64: dts: qcom: sm8250-xiaomi-elish: fix USB maximum speed property
Fix typo in USB DWC3 node maximum speed property.
Fixes: a41b617530bf ("arm64: dts: qcom: sm8250: Add device tree for Xiaomi Mi Pad 5 Pro") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230304130315.51595-1-krzysztof.kozlowski@linaro.org
Normally the 'pinctrl' properties of a SDHC controller and the
chip detect pin settings are dependent on the type of the slots
(for e.g uSD card slot), regulators and GPIO(s) available on the
board(s).
So, move the same from the sm6115 dtsi file to the respective
board file(s).
Bhupesh Sharma [Tue, 14 Mar 2023 08:36:33 +0000 (14:06 +0530)]
arm64: dts: qcom: sm6115: Move USB node's 'maximum-speed' and 'dr_mode' properties to dts
Normally the 'maximum-speed' and 'dr_mode' properties
of a USB controller + port is dependent on the type of
the ports, regulators and mode change interrupt routing
available on the board(s).
So, move the same from the sm6115 dtsi file to respective
board file(s).
Bhupesh Sharma [Tue, 14 Mar 2023 08:36:32 +0000 (14:06 +0530)]
arm64: dts: qcom: sm6115: Cleanup USB node's label
There is only one USB controller present on SM6115 / SM4250
Qualcomm SoC, so drop the numbering used with USB node's label
names in the dtsi and the related sm4250-oneplus-billie2.dts.
Douglas Anderson [Thu, 2 Mar 2023 21:11:07 +0000 (13:11 -0800)]
arm64: dts: qcom: sc7180: Delete mrbland
The mrbland board was never actually produced and there has been no
activity around the board for quite some time. It seems highly
unlikely to magically get revived. There should be nobody in need of
these device trees, so let's delete them. If somehow the project
resurrects itself then we can re-add support, perhaps just for -rev1+.
Douglas Anderson [Thu, 2 Mar 2023 21:11:06 +0000 (13:11 -0800)]
arm64: dts: qcom: sc7180: Delete lazor-rev0
lazor-rev0 was a pile of parts. While I kept the pile of parts for
lazor running on my desk for longer than I usually do, those days are
still long past. Let's finally delete support for lazor-rev0.
Douglas Anderson [Thu, 2 Mar 2023 21:11:05 +0000 (13:11 -0800)]
arm64: dts: qcom: sc7180: Delete kingoftown-rev0
The earliest kingoftown that I could find in my pile of boards was
-rev2 and even that revision looks pretty rough (plastics on the case
are very unfinished). Though I don't actually have details about how
many -rev0 devices were produced, I can't imagine anyone still using
one. Let's delete support.
Douglas Anderson [Thu, 2 Mar 2023 21:11:04 +0000 (13:11 -0800)]
arm64: dts: qcom: sc7180: Delete wormdingler-rev0
The earliest wormdingler I could find in my pile of hardware is
-rev1. I believe that -rev0 boards were just distributed as a pile of
components with no case. At this point I can't imagine anyone needing
to make wormdingler-rev0 work, so let's delete support for it.
Adam Skladowski [Thu, 2 Mar 2023 12:30:49 +0000 (13:30 +0100)]
arm64: dts: qcom: msm8976: Add and provide xo clk to rpmcc
In order for consumers of RPMCC XO clock to probe successfully
their parent needs to be feed with reference clock to obtain proper rate,
add fixed xo-board clock and supply it to rpmcc to make consumers happy.
Frequency setting is left per board basis just like on other recent trees.
Manivannan Sadhasivam [Tue, 28 Feb 2023 16:47:49 +0000 (22:17 +0530)]
arm64: dts: qcom: sm8350: Fix the PCI I/O port range
For 1MiB of the I/O region, the I/O ports of the legacy PCI devices are
located in the range of 0x0 to 0x100000. Hence, fix the bogus PCI addresses
(0x60200000, 0x40200000) specified in the ranges property for I/O region.
While at it, let's use the missing 0x prefix for the addresses.
Manivannan Sadhasivam [Tue, 28 Feb 2023 16:47:48 +0000 (22:17 +0530)]
arm64: dts: qcom: sm8450: Fix the PCI I/O port range
For 1MiB of the I/O region, the I/O ports of the legacy PCI devices are
located in the range of 0x0 to 0x100000. Hence, fix the bogus PCI addresses
(0x60200000, 0x40200000) specified in the ranges property for I/O region.
While at it, let's use the missing 0x prefix for the addresses.
Manivannan Sadhasivam [Tue, 28 Feb 2023 16:47:47 +0000 (22:17 +0530)]
arm64: dts: qcom: sm8150: Fix the PCI I/O port range
For 1MiB of the I/O region, the I/O ports of the legacy PCI devices are
located in the range of 0x0 to 0x100000. Hence, fix the bogus PCI addresses
(0x60200000, 0x40200000) specified in the ranges property for I/O region.
While at it, let's use the missing 0x prefix for the addresses.
Manivannan Sadhasivam [Tue, 28 Feb 2023 16:47:46 +0000 (22:17 +0530)]
arm64: dts: qcom: sc8280xp: Fix the PCI I/O port range
For 1MiB of the I/O region, the I/O ports of the legacy PCI devices are
located in the range of 0x0 to 0x100000. Hence, fix the bogus PCI addresses
(0x30200000, 0x32200000, 0x34200000, 0x38200000, 0x3c200000) specified in
the ranges property for I/O region.
Manivannan Sadhasivam [Tue, 28 Feb 2023 16:47:44 +0000 (22:17 +0530)]
arm64: dts: qcom: sm8250: Fix the PCI I/O port range
For 1MiB of the I/O region, the I/O ports of the legacy PCI devices are
located in the range of 0x0 to 0x100000. Hence, fix the bogus PCI addresses
(0x60200000, 0x40200000, 0x64200000) specified in the ranges property for
I/O region.
While at it, let's use the missing 0x prefix for the addresses.
Manivannan Sadhasivam [Tue, 28 Feb 2023 16:47:43 +0000 (22:17 +0530)]
arm64: dts: qcom: msm8996: Fix the PCI I/O port range
For 1MiB of the I/O region, the I/O ports of the legacy PCI devices are
located in the range of 0x0 to 0x100000. Hence, fix the bogus PCI addresses
(0x0c200000, 0x0d200000, 0x0e200000) specified in the ranges property for
I/O region.
Manivannan Sadhasivam [Tue, 28 Feb 2023 16:47:42 +0000 (22:17 +0530)]
arm64: dts: qcom: ipq6018: Fix the PCI I/O port range
For 64KiB of the I/O region, the I/O ports of the legacy PCI devices are
located in the range of 0x0 to 0x10000. Hence, fix the bogus PCI address
(0x20200000) specified in the ranges property for I/O region.
While at it, let's use the missing 0x prefix for the addresses.
Manivannan Sadhasivam [Tue, 28 Feb 2023 16:47:41 +0000 (22:17 +0530)]
arm64: dts: qcom: ipq8074: Fix the PCI I/O port range
For 64KiB of the I/O region, the I/O ports of the legacy PCI devices are
located in the range of 0x0 to 0x10000. Hence, fix the bogus PCI addresses
(0x10200000, 0x20200000) specified in the ranges property for I/O region.
While at it, let's use the missing 0x prefix for the addresses and align
them in a single line.
Manivannan Sadhasivam [Tue, 28 Feb 2023 16:47:40 +0000 (22:17 +0530)]
arm64: dts: qcom: sm8550: Fix the PCI I/O port range
For 1MiB of the I/O region, the I/O ports of the legacy PCI devices are
located in the range of 0x0 to 0x100000. Hence, fix the bogus PCI addresses
(0x60200000, 0x40200000) specified in the ranges property for I/O region.
While at it, let's use the missing 0x prefix for the addresses.
Manivannan Sadhasivam [Tue, 28 Feb 2023 16:47:39 +0000 (22:17 +0530)]
arm64: dts: qcom: sc7280: Fix the PCI I/O port range
For 1MiB of the I/O region, the I/O ports of the legacy PCI devices are
located in the range of 0x0 to 0x100000. Hence, fix the bogus PCI address
(0x40200000) specified in the ranges property for I/O region.
Manivannan Sadhasivam [Tue, 28 Feb 2023 16:47:38 +0000 (22:17 +0530)]
arm64: dts: qcom: msm8998: Fix the PCI I/O port range
For 1MiB of the I/O region, the I/O ports of the legacy PCI devices are
located in the range of 0x0 to 0x100000. Hence, fix the bogus PCI address
(0x1b200000) specified in the ranges property for I/O region.
Manivannan Sadhasivam [Tue, 28 Feb 2023 16:47:37 +0000 (22:17 +0530)]
arm64: dts: qcom: sdm845: Fix the PCI I/O port range
For 1MiB of the I/O region, the I/O ports of the legacy PCI devices are
located in the range of 0x0 to 0x100000. Hence, fix the bogus PCI addresses
(0x60200000, 0x40200000) specified in the ranges property for I/O region.
While at it, let's use the missing 0x prefix for the addresses.
Vincent Guittot [Fri, 6 Jan 2023 16:46:18 +0000 (17:46 +0100)]
arm64: dts: qcom: sdm845: correct dynamic power coefficients
While stressing EAS on my dragonboard RB3, I have noticed that LITTLE cores
where never selected as the most energy efficient CPU whatever the
utilization level of waking task.
energy model framework uses its cost field to estimate the energy with
the formula:
nrg = cost of the selected OPP * utilization / CPU's max capacity
which ends up selecting the CPU with lowest cost / max capacity ration
as long as the utilization fits in the OPP's capacity.
If we compare the cost of a little OPP with similar capacity of a big OPP
like :
OPP(kHz) OPP capacity cost max capacity cost/max capacity
LITTLE 1766400 407 351114 407 863
big 1056000 408 520267 1024 508
This can be interpreted as the LITTLE core consumes 70% more than big core
for the same compute capacity.
According to [1], LITTLE consumes 10% less than big core for Coremark
benchmark at those OPPs. If we consider that everything else stays
unchanged, the dynamic-power-coefficient of LITTLE core should be
only 53% of the current value: 290 * 53% = 154
Set the dynamic-power-coefficient of CPU0-3 to 154 to fix the energy model.
Krzysztof Kozlowski [Wed, 8 Mar 2023 12:59:06 +0000 (13:59 +0100)]
arm64: dts: qcom: msm8996-oneplus: do not enable incomplete nodes
status=okay should appear in final place where all required properties
are provided, because that makes the code the easiest to read. Move the
status from common OnePlus DTSI to board DTS. No functional changes.
projects / users / jedix / linux-maple.git / log