* Re: [PATCH v15 1/2] dt-binding: i2c: add bus-supply property
From: Wolfram Sang @ 2020-05-22 14:59 UTC (permalink / raw)
To: Bibby Hsieh
Cc: Bartosz Golaszewski, linux-i2c, tfiga, drinkcat, srv_heupstream,
robh+dt, mark.rutland, devicetree, Rafael J . Wysocki
In-Reply-To: <20200519084800.GG1094@ninjato>
[-- Attachment #1: Type: text/plain, Size: 470 bytes --]
On Tue, May 19, 2020 at 10:48:00AM +0200, Wolfram Sang wrote:
> On Tue, May 19, 2020 at 03:27:28PM +0800, Bibby Hsieh wrote:
> > In some platforms, they disable the power-supply of i2c due
> > to power consumption reduction. This patch add bus-supply property.
> >
> > Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
> > Acked-by: Rob Herring <robh@kernel.org>
>
> Applied to for-next, thanks!
Reverted because of regression reports in linux-next.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: iio: imu: bmi160: convert txt format to yaml
From: Daniel Baluta @ 2020-05-22 14:59 UTC (permalink / raw)
To: Jonathan Albrieux
Cc: Jonathan Cameron, Jonathan Cameron, linux-kernel,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Hartmut Knaack, Lars-Peter Clausen,
open list:IIO SUBSYSTEM AND DRIVERS, Peter Meerwald-Stadler,
Rob Herring
In-Reply-To: <20200522142633.GA21655@ict14-OptiPlex-980>
On 22.05.2020 17:26, Jonathan Albrieux wrote:
> On Fri, May 22, 2020 at 01:47:21PM +0300, Daniel Baluta wrote:
>>>>>>> +
>>>>>>> +maintainers:
>>>>>>> + - can't find a mantainer, author is Daniel Baluta <daniel.baluta@intel.com>
>>>>>> Daniel is still active in the kernel, just not at Intel any more. +CC
>>>>> Oh ok thank you! Daniel are you still maintaining this driver?
>> I can do reviews if requested but I'm not actively maintaining this driver.
>> If anyone wants
>>
>> to take this over, will be more than happy.
>>
>>
>> Other than that we can add my gmail address: Daniel Baluta
>> <daniel.baluta@gmail.com>
>>
>>
>>
> Well if you'd like to review this patch I'd really appreciate :-)
> Forgive me for not having understood your answer regarding the maintainer
> field, can I add you to this binding as maintainer or are you saying to
> not add you? Thank you and sorry for the repeated question,
>
>
OK, so I think would be better not to add me as a maintainer because
this would set some expecation from people, and I most likely won't
have time to met them.
Can you instead add the linux-iio mailing list as a maintainer, not sure
if this is a common practice though.
^ permalink raw reply
* Re: [PATCH v4 3/8] spi: stm32: Add 'SPI_SIMPLEX_RX', 'SPI_3WIRE_RX' support for stm32f4
From: dillon min @ 2020-05-22 14:57 UTC (permalink / raw)
To: Mark Brown
Cc: Rob Herring, p.zabel, Maxime Coquelin,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Alexandre Torgue, thierry.reding, Sam Ravnborg, Dave Airlie,
Daniel Vetter, Michael Turquette, Stephen Boyd, Linux ARM,
linux-kernel, linux-spi, linux-stm32, open list:DRM PANEL DRIVERS,
linux-clk
In-Reply-To: <20200522113634.GE5801@sirena.org.uk>
hi Mark,
Thanks for reviewing.
On Fri, May 22, 2020 at 7:36 PM Mark Brown <broonie@kernel.org> wrote:
>
> On Mon, May 18, 2020 at 07:09:20PM +0800, dillon.minfei@gmail.com wrote:
>
> > 2, use stm32 spi's "In full-duplex (BIDIMODE=0 and RXONLY=0)", as tx_buf is
> > null, we must add dummy data sent out before read data.
> > so, add stm32f4_spi_tx_dummy() to handle this situation.
>
> There are flags SPI_CONTROLLER_MUST_TX and SPI_CONTROLLER_MUST_RX flags
> that the driver can set if it needs to, no need to open code this in the
> driver.
Yes, after check SPI_CONTROLLER_MUST_TX in drivers/spi/spi.c , it's
indeed to meet
this situation, i will try it and sumbmit a new patch.
thanks.
best regards
Dillon
^ permalink raw reply
* [PATCH AUTOSEL 5.4 05/32] ARM: dts: rockchip: swap clock-names of gpu nodes
From: Sasha Levin @ 2020-05-22 14:50 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Johan Jonker, Heiko Stuebner, Sasha Levin, linux-arm-kernel,
linux-rockchip, devicetree
In-Reply-To: <20200522145044.434677-1-sashal@kernel.org>
From: Johan Jonker <jbx6244@gmail.com>
[ Upstream commit b14f3898d2c25a9b47a61fb879d0b1f3af92c59b ]
Dts files with Rockchip 'gpu' nodes were manually verified.
In order to automate this process arm,mali-utgard.txt
has been converted to yaml. In the new setup dtbs_check with
arm,mali-utgard.yaml expects clock-names values
in the same order, so fix that.
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Link: https://lore.kernel.org/r/20200425192500.1808-1-jbx6244@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm/boot/dts/rk3036.dtsi | 2 +-
arch/arm/boot/dts/rk322x.dtsi | 2 +-
arch/arm/boot/dts/rk3xxx.dtsi | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/rk3036.dtsi b/arch/arm/boot/dts/rk3036.dtsi
index c776321b2cc4..d282a7b638d8 100644
--- a/arch/arm/boot/dts/rk3036.dtsi
+++ b/arch/arm/boot/dts/rk3036.dtsi
@@ -128,7 +128,7 @@
assigned-clocks = <&cru SCLK_GPU>;
assigned-clock-rates = <100000000>;
clocks = <&cru SCLK_GPU>, <&cru SCLK_GPU>;
- clock-names = "core", "bus";
+ clock-names = "bus", "core";
resets = <&cru SRST_GPU>;
status = "disabled";
};
diff --git a/arch/arm/boot/dts/rk322x.dtsi b/arch/arm/boot/dts/rk322x.dtsi
index 340ed6ccb08f..c60784f3aa75 100644
--- a/arch/arm/boot/dts/rk322x.dtsi
+++ b/arch/arm/boot/dts/rk322x.dtsi
@@ -561,7 +561,7 @@
"pp1",
"ppmmu1";
clocks = <&cru ACLK_GPU>, <&cru ACLK_GPU>;
- clock-names = "core", "bus";
+ clock-names = "bus", "core";
resets = <&cru SRST_GPU_A>;
status = "disabled";
};
diff --git a/arch/arm/boot/dts/rk3xxx.dtsi b/arch/arm/boot/dts/rk3xxx.dtsi
index 97307a405e60..bce0b05ef7bf 100644
--- a/arch/arm/boot/dts/rk3xxx.dtsi
+++ b/arch/arm/boot/dts/rk3xxx.dtsi
@@ -84,7 +84,7 @@
compatible = "arm,mali-400";
reg = <0x10090000 0x10000>;
clocks = <&cru ACLK_GPU>, <&cru ACLK_GPU>;
- clock-names = "core", "bus";
+ clock-names = "bus", "core";
assigned-clocks = <&cru ACLK_GPU>;
assigned-clock-rates = <100000000>;
resets = <&cru SRST_GPU>;
--
2.25.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 04/32] arm64: dts: rockchip: swap interrupts interrupt-names rk3399 gpu node
From: Sasha Levin @ 2020-05-22 14:50 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Johan Jonker, Heiko Stuebner, Sasha Levin, devicetree,
linux-arm-kernel, linux-rockchip
In-Reply-To: <20200522145044.434677-1-sashal@kernel.org>
From: Johan Jonker <jbx6244@gmail.com>
[ Upstream commit c604fd810bda667bdc20b2c041917baa7803e0fb ]
Dts files with Rockchip rk3399 'gpu' nodes were manually verified.
In order to automate this process arm,mali-midgard.txt
has been converted to yaml. In the new setup dtbs_check with
arm,mali-midgard.yaml expects interrupts and interrupt-names values
in the same order. Fix this for rk3399.
make ARCH=arm64 dtbs_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/gpu/
arm,mali-midgard.yaml
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Link: https://lore.kernel.org/r/20200425143837.18706-1-jbx6244@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index cd97016b7c18..c5d8d1c58291 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1881,10 +1881,10 @@
gpu: gpu@ff9a0000 {
compatible = "rockchip,rk3399-mali", "arm,mali-t860";
reg = <0x0 0xff9a0000 0x0 0x10000>;
- interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH 0>,
- <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH 0>,
- <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH 0>;
- interrupt-names = "gpu", "job", "mmu";
+ interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH 0>;
+ interrupt-names = "job", "mmu", "gpu";
clocks = <&cru ACLK_GPU>;
power-domains = <&power RK3399_PD_GPU>;
status = "disabled";
--
2.25.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 06/32] ARM: dts: rockchip: fix pinctrl sub nodename for spi in rk322x.dtsi
From: Sasha Levin @ 2020-05-22 14:50 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Johan Jonker, Heiko Stuebner, Sasha Levin, linux-arm-kernel,
linux-rockchip, devicetree
In-Reply-To: <20200522145044.434677-1-sashal@kernel.org>
From: Johan Jonker <jbx6244@gmail.com>
[ Upstream commit 855bdca1781c79eb661f89c8944c4a719ce720e8 ]
A test with the command below gives these errors:
arch/arm/boot/dts/rk3229-evb.dt.yaml: spi-0:
'#address-cells' is a required property
arch/arm/boot/dts/rk3229-evb.dt.yaml: spi-1:
'#address-cells' is a required property
arch/arm/boot/dts/rk3229-xms6.dt.yaml: spi-0:
'#address-cells' is a required property
arch/arm/boot/dts/rk3229-xms6.dt.yaml: spi-1:
'#address-cells' is a required property
The $nodename pattern for spi nodes is
"^spi(@.*|-[0-9a-f])*$". To prevent warnings rename
'spi-0' and 'spi-1' pinctrl sub nodenames to
'spi0' and 'spi1' in 'rk322x.dtsi'.
make ARCH=arm dtbs_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/spi/spi-controller.yaml
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Link: https://lore.kernel.org/r/20200424123923.8192-1-jbx6244@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm/boot/dts/rk322x.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/rk322x.dtsi b/arch/arm/boot/dts/rk322x.dtsi
index c60784f3aa75..6bb78b19c555 100644
--- a/arch/arm/boot/dts/rk322x.dtsi
+++ b/arch/arm/boot/dts/rk322x.dtsi
@@ -1033,7 +1033,7 @@
};
};
- spi-0 {
+ spi0 {
spi0_clk: spi0-clk {
rockchip,pins = <0 RK_PB1 2 &pcfg_pull_up>;
};
@@ -1051,7 +1051,7 @@
};
};
- spi-1 {
+ spi1 {
spi1_clk: spi1-clk {
rockchip,pins = <0 RK_PC7 2 &pcfg_pull_up>;
};
--
2.25.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 01/19] ARM: dts: rockchip: fix phy nodename for rk3228-evb
From: Sasha Levin @ 2020-05-22 14:51 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Johan Jonker, Heiko Stuebner, Sasha Levin, linux-arm-kernel,
linux-rockchip, devicetree
From: Johan Jonker <jbx6244@gmail.com>
[ Upstream commit 287e0d538fcec2f6e8eb1e565bf0749f3b90186d ]
A test with the command below gives for example this error:
arch/arm/boot/dts/rk3228-evb.dt.yaml: phy@0:
'#phy-cells' is a required property
The phy nodename is normally used by a phy-handle.
This node is however compatible with
"ethernet-phy-id1234.d400", "ethernet-phy-ieee802.3-c22"
which is just been added to 'ethernet-phy.yaml'.
So change nodename to 'ethernet-phy' for which '#phy-cells'
is not a required property
make ARCH=arm dtbs_check
DT_SCHEMA_FILES=~/.local/lib/python3.5/site-packages/dtschema/schemas/
phy/phy-provider.yaml
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20200416170321.4216-1-jbx6244@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm/boot/dts/rk3228-evb.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/rk3228-evb.dts b/arch/arm/boot/dts/rk3228-evb.dts
index 5670b33fd1bd..aed879db6c15 100644
--- a/arch/arm/boot/dts/rk3228-evb.dts
+++ b/arch/arm/boot/dts/rk3228-evb.dts
@@ -46,7 +46,7 @@
#address-cells = <1>;
#size-cells = <0>;
- phy: phy@0 {
+ phy: ethernet-phy@0 {
compatible = "ethernet-phy-id1234.d400", "ethernet-phy-ieee802.3-c22";
reg = <0>;
clocks = <&cru SCLK_MAC_PHY>;
--
2.25.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 03/19] arm64: dts: rockchip: swap interrupts interrupt-names rk3399 gpu node
From: Sasha Levin @ 2020-05-22 14:51 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Johan Jonker, Heiko Stuebner, Sasha Levin, devicetree,
linux-arm-kernel, linux-rockchip
In-Reply-To: <20200522145120.434921-1-sashal@kernel.org>
From: Johan Jonker <jbx6244@gmail.com>
[ Upstream commit c604fd810bda667bdc20b2c041917baa7803e0fb ]
Dts files with Rockchip rk3399 'gpu' nodes were manually verified.
In order to automate this process arm,mali-midgard.txt
has been converted to yaml. In the new setup dtbs_check with
arm,mali-midgard.yaml expects interrupts and interrupt-names values
in the same order. Fix this for rk3399.
make ARCH=arm64 dtbs_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/gpu/
arm,mali-midgard.yaml
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Link: https://lore.kernel.org/r/20200425143837.18706-1-jbx6244@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 451f00a631c4..f14e8c5c41ac 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1817,10 +1817,10 @@
gpu: gpu@ff9a0000 {
compatible = "rockchip,rk3399-mali", "arm,mali-t860";
reg = <0x0 0xff9a0000 0x0 0x10000>;
- interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH 0>,
- <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH 0>,
- <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH 0>;
- interrupt-names = "gpu", "job", "mmu";
+ interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH 0>;
+ interrupt-names = "job", "mmu", "gpu";
clocks = <&cru ACLK_GPU>;
power-domains = <&power RK3399_PD_GPU>;
status = "disabled";
--
2.25.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 05/19] ARM: dts: rockchip: fix pinctrl sub nodename for spi in rk322x.dtsi
From: Sasha Levin @ 2020-05-22 14:51 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Johan Jonker, Heiko Stuebner, Sasha Levin, linux-arm-kernel,
linux-rockchip, devicetree
In-Reply-To: <20200522145120.434921-1-sashal@kernel.org>
From: Johan Jonker <jbx6244@gmail.com>
[ Upstream commit 855bdca1781c79eb661f89c8944c4a719ce720e8 ]
A test with the command below gives these errors:
arch/arm/boot/dts/rk3229-evb.dt.yaml: spi-0:
'#address-cells' is a required property
arch/arm/boot/dts/rk3229-evb.dt.yaml: spi-1:
'#address-cells' is a required property
arch/arm/boot/dts/rk3229-xms6.dt.yaml: spi-0:
'#address-cells' is a required property
arch/arm/boot/dts/rk3229-xms6.dt.yaml: spi-1:
'#address-cells' is a required property
The $nodename pattern for spi nodes is
"^spi(@.*|-[0-9a-f])*$". To prevent warnings rename
'spi-0' and 'spi-1' pinctrl sub nodenames to
'spi0' and 'spi1' in 'rk322x.dtsi'.
make ARCH=arm dtbs_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/spi/spi-controller.yaml
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Link: https://lore.kernel.org/r/20200424123923.8192-1-jbx6244@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm/boot/dts/rk322x.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/rk322x.dtsi b/arch/arm/boot/dts/rk322x.dtsi
index bada942ef38d..2aa74267ae51 100644
--- a/arch/arm/boot/dts/rk322x.dtsi
+++ b/arch/arm/boot/dts/rk322x.dtsi
@@ -944,7 +944,7 @@
};
};
- spi-0 {
+ spi0 {
spi0_clk: spi0-clk {
rockchip,pins = <0 9 RK_FUNC_2 &pcfg_pull_up>;
};
@@ -962,7 +962,7 @@
};
};
- spi-1 {
+ spi1 {
spi1_clk: spi1-clk {
rockchip,pins = <0 23 RK_FUNC_2 &pcfg_pull_up>;
};
--
2.25.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 04/19] ARM: dts: rockchip: swap clock-names of gpu nodes
From: Sasha Levin @ 2020-05-22 14:51 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Johan Jonker, Heiko Stuebner, Sasha Levin, linux-arm-kernel,
linux-rockchip, devicetree
In-Reply-To: <20200522145120.434921-1-sashal@kernel.org>
From: Johan Jonker <jbx6244@gmail.com>
[ Upstream commit b14f3898d2c25a9b47a61fb879d0b1f3af92c59b ]
Dts files with Rockchip 'gpu' nodes were manually verified.
In order to automate this process arm,mali-utgard.txt
has been converted to yaml. In the new setup dtbs_check with
arm,mali-utgard.yaml expects clock-names values
in the same order, so fix that.
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Link: https://lore.kernel.org/r/20200425192500.1808-1-jbx6244@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm/boot/dts/rk3036.dtsi | 2 +-
arch/arm/boot/dts/rk322x.dtsi | 2 +-
arch/arm/boot/dts/rk3xxx.dtsi | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/rk3036.dtsi b/arch/arm/boot/dts/rk3036.dtsi
index d560fc4051c5..db612271371b 100644
--- a/arch/arm/boot/dts/rk3036.dtsi
+++ b/arch/arm/boot/dts/rk3036.dtsi
@@ -128,7 +128,7 @@
assigned-clocks = <&cru SCLK_GPU>;
assigned-clock-rates = <100000000>;
clocks = <&cru SCLK_GPU>, <&cru SCLK_GPU>;
- clock-names = "core", "bus";
+ clock-names = "bus", "core";
resets = <&cru SRST_GPU>;
status = "disabled";
};
diff --git a/arch/arm/boot/dts/rk322x.dtsi b/arch/arm/boot/dts/rk322x.dtsi
index cd8f2a3b0e91..bada942ef38d 100644
--- a/arch/arm/boot/dts/rk322x.dtsi
+++ b/arch/arm/boot/dts/rk322x.dtsi
@@ -539,7 +539,7 @@
"pp1",
"ppmmu1";
clocks = <&cru ACLK_GPU>, <&cru ACLK_GPU>;
- clock-names = "core", "bus";
+ clock-names = "bus", "core";
resets = <&cru SRST_GPU_A>;
status = "disabled";
};
diff --git a/arch/arm/boot/dts/rk3xxx.dtsi b/arch/arm/boot/dts/rk3xxx.dtsi
index d752dc611fd7..86a0d98d28ff 100644
--- a/arch/arm/boot/dts/rk3xxx.dtsi
+++ b/arch/arm/boot/dts/rk3xxx.dtsi
@@ -84,7 +84,7 @@
compatible = "arm,mali-400";
reg = <0x10090000 0x10000>;
clocks = <&cru ACLK_GPU>, <&cru ACLK_GPU>;
- clock-names = "core", "bus";
+ clock-names = "bus", "core";
assigned-clocks = <&cru ACLK_GPU>;
assigned-clock-rates = <100000000>;
resets = <&cru SRST_GPU>;
--
2.25.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.14 01/13] ARM: dts: rockchip: fix phy nodename for rk3228-evb
From: Sasha Levin @ 2020-05-22 14:51 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Johan Jonker, Heiko Stuebner, Sasha Levin, linux-arm-kernel,
linux-rockchip, devicetree
From: Johan Jonker <jbx6244@gmail.com>
[ Upstream commit 287e0d538fcec2f6e8eb1e565bf0749f3b90186d ]
A test with the command below gives for example this error:
arch/arm/boot/dts/rk3228-evb.dt.yaml: phy@0:
'#phy-cells' is a required property
The phy nodename is normally used by a phy-handle.
This node is however compatible with
"ethernet-phy-id1234.d400", "ethernet-phy-ieee802.3-c22"
which is just been added to 'ethernet-phy.yaml'.
So change nodename to 'ethernet-phy' for which '#phy-cells'
is not a required property
make ARCH=arm dtbs_check
DT_SCHEMA_FILES=~/.local/lib/python3.5/site-packages/dtschema/schemas/
phy/phy-provider.yaml
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20200416170321.4216-1-jbx6244@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm/boot/dts/rk3228-evb.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/rk3228-evb.dts b/arch/arm/boot/dts/rk3228-evb.dts
index 1be9daacc4f9..b69c842d8306 100644
--- a/arch/arm/boot/dts/rk3228-evb.dts
+++ b/arch/arm/boot/dts/rk3228-evb.dts
@@ -84,7 +84,7 @@
#address-cells = <1>;
#size-cells = <0>;
- phy: phy@0 {
+ phy: ethernet-phy@0 {
compatible = "ethernet-phy-id1234.d400", "ethernet-phy-ieee802.3-c22";
reg = <0>;
clocks = <&cru SCLK_MAC_PHY>;
--
2.25.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.14 02/13] arm64: dts: rockchip: swap interrupts interrupt-names rk3399 gpu node
From: Sasha Levin @ 2020-05-22 14:51 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Johan Jonker, Heiko Stuebner, Sasha Levin, devicetree,
linux-arm-kernel, linux-rockchip
In-Reply-To: <20200522145142.435086-1-sashal@kernel.org>
From: Johan Jonker <jbx6244@gmail.com>
[ Upstream commit c604fd810bda667bdc20b2c041917baa7803e0fb ]
Dts files with Rockchip rk3399 'gpu' nodes were manually verified.
In order to automate this process arm,mali-midgard.txt
has been converted to yaml. In the new setup dtbs_check with
arm,mali-midgard.yaml expects interrupts and interrupt-names values
in the same order. Fix this for rk3399.
make ARCH=arm64 dtbs_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/gpu/
arm,mali-midgard.yaml
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Link: https://lore.kernel.org/r/20200425143837.18706-1-jbx6244@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index ff8df7fd44a7..b63d9653ff55 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1691,10 +1691,10 @@
gpu: gpu@ff9a0000 {
compatible = "rockchip,rk3399-mali", "arm,mali-t860";
reg = <0x0 0xff9a0000 0x0 0x10000>;
- interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH 0>,
- <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH 0>,
- <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH 0>;
- interrupt-names = "gpu", "job", "mmu";
+ interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH 0>;
+ interrupt-names = "job", "mmu", "gpu";
clocks = <&cru ACLK_GPU>;
power-domains = <&power RK3399_PD_GPU>;
status = "disabled";
--
2.25.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.14 03/13] ARM: dts: rockchip: fix pinctrl sub nodename for spi in rk322x.dtsi
From: Sasha Levin @ 2020-05-22 14:51 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Johan Jonker, Heiko Stuebner, Sasha Levin, linux-arm-kernel,
linux-rockchip, devicetree
In-Reply-To: <20200522145142.435086-1-sashal@kernel.org>
From: Johan Jonker <jbx6244@gmail.com>
[ Upstream commit 855bdca1781c79eb661f89c8944c4a719ce720e8 ]
A test with the command below gives these errors:
arch/arm/boot/dts/rk3229-evb.dt.yaml: spi-0:
'#address-cells' is a required property
arch/arm/boot/dts/rk3229-evb.dt.yaml: spi-1:
'#address-cells' is a required property
arch/arm/boot/dts/rk3229-xms6.dt.yaml: spi-0:
'#address-cells' is a required property
arch/arm/boot/dts/rk3229-xms6.dt.yaml: spi-1:
'#address-cells' is a required property
The $nodename pattern for spi nodes is
"^spi(@.*|-[0-9a-f])*$". To prevent warnings rename
'spi-0' and 'spi-1' pinctrl sub nodenames to
'spi0' and 'spi1' in 'rk322x.dtsi'.
make ARCH=arm dtbs_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/spi/spi-controller.yaml
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Link: https://lore.kernel.org/r/20200424123923.8192-1-jbx6244@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm/boot/dts/rk322x.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/rk322x.dtsi b/arch/arm/boot/dts/rk322x.dtsi
index f59f7cc62be6..0c60dbc4b46a 100644
--- a/arch/arm/boot/dts/rk322x.dtsi
+++ b/arch/arm/boot/dts/rk322x.dtsi
@@ -950,7 +950,7 @@
};
};
- spi-0 {
+ spi0 {
spi0_clk: spi0-clk {
rockchip,pins = <0 9 RK_FUNC_2 &pcfg_pull_up>;
};
@@ -968,7 +968,7 @@
};
};
- spi-1 {
+ spi1 {
spi1_clk: spi1-clk {
rockchip,pins = <0 23 RK_FUNC_2 &pcfg_pull_up>;
};
--
2.25.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 02/19] arm64: dts: rockchip: fix status for &gmac2phy in rk3328-evb.dts
From: Sasha Levin @ 2020-05-22 14:51 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Johan Jonker, Heiko Stuebner, Sasha Levin, devicetree,
linux-arm-kernel, linux-rockchip
In-Reply-To: <20200522145120.434921-1-sashal@kernel.org>
From: Johan Jonker <jbx6244@gmail.com>
[ Upstream commit c617ed88502d0b05149e7f32f3b3fd8a0663f7e2 ]
The status was removed of the '&gmac2phy' node with the apply
of a patch long time ago, so fix status for '&gmac2phy'
in 'rk3328-evb.dts'.
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Link: https://lore.kernel.org/r/20200425122345.12902-2-jbx6244@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm64/boot/dts/rockchip/rk3328-evb.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3328-evb.dts b/arch/arm64/boot/dts/rockchip/rk3328-evb.dts
index 212dd8159da9..d89f3451ace5 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-evb.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-evb.dts
@@ -86,7 +86,7 @@
assigned-clock-rate = <50000000>;
assigned-clocks = <&cru SCLK_MAC2PHY>;
assigned-clock-parents = <&cru SCLK_MAC2PHY_SRC>;
-
+ status = "okay";
};
&i2c1 {
--
2.25.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 03/32] arm64: dts: rockchip: fix status for &gmac2phy in rk3328-evb.dts
From: Sasha Levin @ 2020-05-22 14:50 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Johan Jonker, Heiko Stuebner, Sasha Levin, devicetree,
linux-arm-kernel, linux-rockchip
In-Reply-To: <20200522145044.434677-1-sashal@kernel.org>
From: Johan Jonker <jbx6244@gmail.com>
[ Upstream commit c617ed88502d0b05149e7f32f3b3fd8a0663f7e2 ]
The status was removed of the '&gmac2phy' node with the apply
of a patch long time ago, so fix status for '&gmac2phy'
in 'rk3328-evb.dts'.
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Link: https://lore.kernel.org/r/20200425122345.12902-2-jbx6244@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm64/boot/dts/rockchip/rk3328-evb.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3328-evb.dts b/arch/arm64/boot/dts/rockchip/rk3328-evb.dts
index 6abc6f4a86cf..05265b38cc02 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-evb.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-evb.dts
@@ -86,7 +86,7 @@
assigned-clock-rate = <50000000>;
assigned-clocks = <&cru SCLK_MAC2PHY>;
assigned-clock-parents = <&cru SCLK_MAC2PHY_SRC>;
-
+ status = "okay";
};
&i2c1 {
--
2.25.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 02/32] ARM: dts: rockchip: fix phy nodename for rk3229-xms6
From: Sasha Levin @ 2020-05-22 14:50 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Johan Jonker, Heiko Stuebner, Sasha Levin, linux-arm-kernel,
linux-rockchip, devicetree
In-Reply-To: <20200522145044.434677-1-sashal@kernel.org>
From: Johan Jonker <jbx6244@gmail.com>
[ Upstream commit 621c8d0c233e260232278a4cfd3380caa3c1da29 ]
A test with the command below gives for example this error:
arch/arm/boot/dts/rk3229-xms6.dt.yaml: phy@0:
'#phy-cells' is a required property
The phy nodename is normally used by a phy-handle.
This node is however compatible with
"ethernet-phy-id1234.d400", "ethernet-phy-ieee802.3-c22"
which is just been added to 'ethernet-phy.yaml'.
So change nodename to 'ethernet-phy' for which '#phy-cells'
is not a required property
make ARCH=arm dtbs_check
DT_SCHEMA_FILES=~/.local/lib/python3.5/site-packages/dtschema/schemas/
phy/phy-provider.yaml
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20200416170321.4216-2-jbx6244@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm/boot/dts/rk3229-xms6.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/rk3229-xms6.dts b/arch/arm/boot/dts/rk3229-xms6.dts
index 679fc2b00e5a..933ef69da32a 100644
--- a/arch/arm/boot/dts/rk3229-xms6.dts
+++ b/arch/arm/boot/dts/rk3229-xms6.dts
@@ -150,7 +150,7 @@
#address-cells = <1>;
#size-cells = <0>;
- phy: phy@0 {
+ phy: ethernet-phy@0 {
compatible = "ethernet-phy-id1234.d400",
"ethernet-phy-ieee802.3-c22";
reg = <0>;
--
2.25.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 01/32] ARM: dts: rockchip: fix phy nodename for rk3228-evb
From: Sasha Levin @ 2020-05-22 14:50 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Johan Jonker, Heiko Stuebner, Sasha Levin, linux-arm-kernel,
linux-rockchip, devicetree
From: Johan Jonker <jbx6244@gmail.com>
[ Upstream commit 287e0d538fcec2f6e8eb1e565bf0749f3b90186d ]
A test with the command below gives for example this error:
arch/arm/boot/dts/rk3228-evb.dt.yaml: phy@0:
'#phy-cells' is a required property
The phy nodename is normally used by a phy-handle.
This node is however compatible with
"ethernet-phy-id1234.d400", "ethernet-phy-ieee802.3-c22"
which is just been added to 'ethernet-phy.yaml'.
So change nodename to 'ethernet-phy' for which '#phy-cells'
is not a required property
make ARCH=arm dtbs_check
DT_SCHEMA_FILES=~/.local/lib/python3.5/site-packages/dtschema/schemas/
phy/phy-provider.yaml
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20200416170321.4216-1-jbx6244@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm/boot/dts/rk3228-evb.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/rk3228-evb.dts b/arch/arm/boot/dts/rk3228-evb.dts
index 5670b33fd1bd..aed879db6c15 100644
--- a/arch/arm/boot/dts/rk3228-evb.dts
+++ b/arch/arm/boot/dts/rk3228-evb.dts
@@ -46,7 +46,7 @@
#address-cells = <1>;
#size-cells = <0>;
- phy: phy@0 {
+ phy: ethernet-phy@0 {
compatible = "ethernet-phy-id1234.d400", "ethernet-phy-ieee802.3-c22";
reg = <0>;
clocks = <&cru SCLK_MAC_PHY>;
--
2.25.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.6 11/41] ARM: dts: omap4-droid4: Fix occasional lost wakeirq for uart1
From: Sasha Levin @ 2020-05-22 14:49 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Tony Lindgren, maemo-leste, Merlijn Wajer, Pavel Machek,
Sebastian Reichel, Sasha Levin, devicetree, linux-arm-kernel
In-Reply-To: <20200522144959.434379-1-sashal@kernel.org>
From: Tony Lindgren <tony@atomide.com>
[ Upstream commit 738b150ecefbffb6e55cfa8a3b66a844f777d8fb ]
Looks like using the UART CTS pin does not always trigger for a wake-up
when the SoC is idle.
This is probably because the modem first uses gpio_149 to signal the SoC
that data will be sent, and the CTS will only get used later when the
data transfer is starting.
Let's fix the issue by configuring the gpio_149 pad as the wakeirq for
UART. We have gpio_149 managed by the USB PHY for powering up the right
USB mode, and after that, the gpio gets recycled as the modem wake-up
pin. If needeed, the USB PHY can also later on be configured to use
gpio_149 pad as the wakeirq as a shared irq.
Let's also configure the missing properties for uart-has-rtscts and
current-speed for the modem port while at it. We already configure the
hardware flow control pins with uart1_pins pinctrl setting.
Cc: maemo-leste@lists.dyne.org
Cc: Merlijn Wajer <merlijn@wizzup.org>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm/boot/dts/motorola-mapphone-common.dtsi | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/motorola-mapphone-common.dtsi b/arch/arm/boot/dts/motorola-mapphone-common.dtsi
index 01ea9a1e2c86..06fbffa81636 100644
--- a/arch/arm/boot/dts/motorola-mapphone-common.dtsi
+++ b/arch/arm/boot/dts/motorola-mapphone-common.dtsi
@@ -723,14 +723,18 @@
};
/*
- * As uart1 is wired to mdm6600 with rts and cts, we can use the cts pin for
- * uart1 wakeirq.
+ * The uart1 port is wired to mdm6600 with rts and cts. The modem uses gpio_149
+ * for wake-up events for both the USB PHY and the UART. We can use gpio_149
+ * pad as the shared wakeirq for the UART rather than the RX or CTS pad as we
+ * have gpio_149 trigger before the UART transfer starts.
*/
&uart1 {
pinctrl-names = "default";
pinctrl-0 = <&uart1_pins>;
interrupts-extended = <&wakeupgen GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH
- &omap4_pmx_core 0xfc>;
+ &omap4_pmx_core 0x110>;
+ uart-has-rtscts;
+ current-speed = <115200>;
};
&uart3 {
--
2.25.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.6 03/41] ARM: dts: rockchip: fix phy nodename for rk3229-xms6
From: Sasha Levin @ 2020-05-22 14:49 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Johan Jonker, Heiko Stuebner, Sasha Levin, linux-arm-kernel,
linux-rockchip, devicetree
In-Reply-To: <20200522144959.434379-1-sashal@kernel.org>
From: Johan Jonker <jbx6244@gmail.com>
[ Upstream commit 621c8d0c233e260232278a4cfd3380caa3c1da29 ]
A test with the command below gives for example this error:
arch/arm/boot/dts/rk3229-xms6.dt.yaml: phy@0:
'#phy-cells' is a required property
The phy nodename is normally used by a phy-handle.
This node is however compatible with
"ethernet-phy-id1234.d400", "ethernet-phy-ieee802.3-c22"
which is just been added to 'ethernet-phy.yaml'.
So change nodename to 'ethernet-phy' for which '#phy-cells'
is not a required property
make ARCH=arm dtbs_check
DT_SCHEMA_FILES=~/.local/lib/python3.5/site-packages/dtschema/schemas/
phy/phy-provider.yaml
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20200416170321.4216-2-jbx6244@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm/boot/dts/rk3229-xms6.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/rk3229-xms6.dts b/arch/arm/boot/dts/rk3229-xms6.dts
index 679fc2b00e5a..933ef69da32a 100644
--- a/arch/arm/boot/dts/rk3229-xms6.dts
+++ b/arch/arm/boot/dts/rk3229-xms6.dts
@@ -150,7 +150,7 @@
#address-cells = <1>;
#size-cells = <0>;
- phy: phy@0 {
+ phy: ethernet-phy@0 {
compatible = "ethernet-phy-id1234.d400",
"ethernet-phy-ieee802.3-c22";
reg = <0>;
--
2.25.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.6 01/41] arm64: dts: qcom: db820c: fix audio configuration
From: Sasha Levin @ 2020-05-22 14:49 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Srinivas Kandagatla, Vinod Koul, Bjorn Andersson, Sasha Levin,
devicetree, linux-arm-kernel
From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
[ Upstream commit 7710f80ecd9c74544a22557ab581cf603e713f51 ]
After patch f864edff110d ("ASoC: qdsp6: q6routing: remove default routing")
and 9b60441692d9 ("ASoC: qdsp6: q6asm-dai: only enable dais from device tree")
asm dais and routing needs to be properly specified at device tree level.
This patch fixes this.
Tested-by: Vinod Koul <vkoul@kernel.org>
Reviewed-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://lore.kernel.org/r/20200422101922.8894-1-srinivas.kandagatla@linaro.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi | 19 ++++++++++++++++++-
arch/arm64/boot/dts/qcom/msm8996.dtsi | 2 ++
2 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi b/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
index a85b85d85a5f..3c7c9b52623c 100644
--- a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
+++ b/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
@@ -908,10 +908,27 @@
status = "okay";
};
+&q6asmdai {
+ dai@0 {
+ reg = <0>;
+ };
+
+ dai@1 {
+ reg = <1>;
+ };
+
+ dai@2 {
+ reg = <2>;
+ };
+};
+
&sound {
compatible = "qcom,apq8096-sndcard";
model = "DB820c";
- audio-routing = "RX_BIAS", "MCLK";
+ audio-routing = "RX_BIAS", "MCLK",
+ "MM_DL1", "MultiMedia1 Playback",
+ "MM_DL2", "MultiMedia2 Playback",
+ "MultiMedia3 Capture", "MM_UL3";
mm1-dai-link {
link-name = "MultiMedia1";
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index 7ae082ea14ea..f925a6c7d293 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -2053,6 +2053,8 @@
reg = <APR_SVC_ASM>;
q6asmdai: dais {
compatible = "qcom,q6asm-dais";
+ #address-cells = <1>;
+ #size-cells = <0>;
#sound-dai-cells = <1>;
iommus = <&lpass_q6_smmu 1>;
};
--
2.25.1
^ permalink raw reply related
* Re: [PATCH 16/17] dt-bindings: watchdog: renesas,wdt: Document r8a7742 support
From: Guenter Roeck @ 2020-05-22 14:47 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Geert Uytterhoeven, Jens Axboe, Rob Herring, Wolfram Sang,
Ulf Hansson, Sergei Shtylyov, David S. Miller, Wim Van Sebroeck,
linux-ide, devicetree, linux-kernel, linux-i2c, linux-mmc, netdev,
linux-renesas-soc, linux-watchdog, Prabhakar
In-Reply-To: <1589555337-5498-17-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Fri, May 15, 2020 at 04:08:56PM +0100, Lad Prabhakar wrote:
> RZ/G1H (R8A7742) watchdog implementation is compatible with R-Car Gen2,
> therefore add relevant documentation.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
> ---
> Documentation/devicetree/bindings/watchdog/renesas,wdt.txt | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/watchdog/renesas,wdt.txt b/Documentation/devicetree/bindings/watchdog/renesas,wdt.txt
> index 79b3c62..e42fd30 100644
> --- a/Documentation/devicetree/bindings/watchdog/renesas,wdt.txt
> +++ b/Documentation/devicetree/bindings/watchdog/renesas,wdt.txt
> @@ -5,6 +5,7 @@ Required properties:
> fallback compatible string when compatible with the generic
> version.
> Examples with soctypes are:
> + - "renesas,r8a7742-wdt" (RZ/G1H)
> - "renesas,r8a7743-wdt" (RZ/G1M)
> - "renesas,r8a7744-wdt" (RZ/G1N)
> - "renesas,r8a7745-wdt" (RZ/G1E)
^ permalink raw reply
* Re: [PATCH v12 2/3] i2c: npcm7xx: Add Nuvoton NPCM I2C controller driver
From: Wolfram Sang @ 2020-05-22 14:45 UTC (permalink / raw)
To: Tali Perry
Cc: ofery, brendanhiggins, avifishman70, tmaimon77, kfting, venture,
yuenn, benjaminfair, robh+dt, andriy.shevchenko, linux-arm-kernel,
linux-i2c, openbmc, devicetree, linux-kernel
In-Reply-To: <20200521110910.45518-3-tali.perry1@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 13108 bytes --]
On Thu, May 21, 2020 at 02:09:09PM +0300, Tali Perry wrote:
> Add Nuvoton NPCM BMC I2C controller driver.
>
> Signed-off-by: Tali Perry <tali.perry1@gmail.com>
This is a very complex driver, so I can really comment only about high
level things. Thank you very much for keeping at it!
My code checkers say:
CHECKPATCH:
CHECK: usleep_range is preferred over udelay; see Documentation/timers/timers-howto.rst
#1210: FILE: drivers/i2c/busses/i2c-npcm7xx.c:1161:
+ udelay(200);
(a few of them)
GCC:
CC drivers/i2c/busses/i2c-npcm7xx.o
drivers/i2c/busses/i2c-npcm7xx.c: In function ‘npcm_i2c_reset’:
drivers/i2c/busses/i2c-npcm7xx.c:521:5: warning: variable ‘i2cctl2’ set but not used [-Wunused-but-set-variable]
> +/* Status of one I2C module */
> +struct npcm_i2c {
> + struct i2c_adapter adap;
> + struct device *dev;
> + unsigned char __iomem *reg;
> + spinlock_t lock; /* IRQ synchronization */
> + struct completion cmd_complete;
> + int irq;
> + int cmd_err;
> + struct i2c_msg *msgs;
> + int msgs_num;
> + int num;
> + u32 apb_clk;
> + struct i2c_bus_recovery_info rinfo;
> + enum i2c_state state;
> + enum i2c_oper operation;
> + enum i2c_mode master_or_slave;
> + enum i2c_state_ind stop_ind;
> + u8 dest_addr;
> + u8 *rd_buf;
> + u16 rd_size;
> + u16 rd_ind;
> + u8 *wr_buf;
> + u16 wr_size;
> + u16 wr_ind;
> + bool fifo_use;
> + u16 PEC_mask; /* PEC bit mask per slave address */
> + bool PEC_use;
> + bool read_block_use;
> + u8 int_cnt;
What is this for? It is written to but never read.
> + u32 clk_period_us;
Not used? Seems this struct could need some cleaning up.
> + unsigned long int_time_stamp;
> + unsigned long bus_freq; /* in kHz */
> + u32 xmits;
> +#ifdef CONFIG_DEBUG_FS
> + struct dentry *debugfs; /* debugfs device directory */
> + u64 ber_cnt;
> + u64 rec_succ_cnt;
> + u64 rec_fail_cnt;
> + u64 nack_cnt;
> + u64 timeout_cnt;
> +#endif
> +};
> +
...
> +static inline u16 npcm_i2c_get_index(struct npcm_i2c *bus)
> +{
> + if (bus->operation == I2C_READ_OPER)
> + return bus->rd_ind;
> + if (bus->operation == I2C_WRITE_OPER)
> + return bus->wr_ind;
> + return 0;
I2C_NO_OPER?
...
> +/* recovery using bit banging functionality of the module */
> +static int npcm_i2c_recovery_init(struct i2c_adapter *_adap)
> +{
> + struct npcm_i2c *bus = container_of(_adap, struct npcm_i2c, adap);
> + struct i2c_bus_recovery_info *rinfo = &bus->rinfo;
> +
> + rinfo->recover_bus = npcm_i2c_recovery_tgclk;
> + rinfo->prepare_recovery = NULL;
> + rinfo->unprepare_recovery = NULL;
> + rinfo->set_scl = NULL;
> + rinfo->set_sda = NULL;
'bus' is kzalloced, so no need for these NULLs.
What I wonder more, though, is if you can't populate {set|get}_{scl|sda}
and use the internal i2c_generic_scl_recovery()? Are there any issues
with it?
> +
> + dev_dbg(bus->dev, "init i2c recovery using TGCLK\n");
There is no error path here, so I think this message is not useful.
Means also this function could be 'void'.
> +
> + rinfo->get_scl = npcm_i2c_get_SCL;
> + rinfo->get_sda = npcm_i2c_get_SDA;
Not needed when you have a custom function.
> +
> + _adap->bus_recovery_info = rinfo;
> +
> + return 0;
> +}
> +
...
> +static int npcm_i2c_master_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs,
> + int num)
> +{
> + struct npcm_i2c *bus = container_of(adap, struct npcm_i2c, adap);
> + struct i2c_msg *msg0, *msg1;
> + unsigned long time_left, flags;
> + u16 nwrite, nread;
> + u8 *write_data, *read_data;
> + u8 slave_addr;
> + int timeout;
> + int ret = 0;
> + bool read_block = false;
> + bool read_PEC = false;
> + u8 bus_busy;
> + unsigned long timeout_usec;
> +
> + if (bus->state == I2C_DISABLE) {
> + dev_err(bus->dev, "I2C%d module is disabled", bus->num);
> + return -EINVAL;
> + }
> +
> + if (num > 2 || num < 1) {
> + dev_err(bus->dev, "I2C cmd not supported num of msgs=%d", num);
> + return -EINVAL;
> + }
Since you have an 'i2c_adapter_quirks' struct filled, the core will
I2C check that for you.
> +
> + msg0 = &msgs[0];
> + slave_addr = msg0->addr;
> + if (msg0->flags & I2C_M_RD) { /* read */
> + if (num == 2) {
> + dev_err(bus->dev, "num=2 but 1st msg rd instead of wr");
> + return -EINVAL;
Ditto.
> + }
> + nwrite = 0;
> + write_data = NULL;
> + read_data = msg0->buf;
> + if (msg0->flags & I2C_M_RECV_LEN) {
> + nread = 1;
> + read_block = true;
> + if (msg0->flags & I2C_CLIENT_PEC)
> + read_PEC = true;
> + } else {
> + nread = msg0->len;
> + }
> + } else { /* write */
> + nwrite = msg0->len;
> + write_data = msg0->buf;
> + nread = 0;
> + read_data = NULL;
> + if (num == 2) {
> + msg1 = &msgs[1];
> + read_data = msg1->buf;
> + if (slave_addr != msg1->addr) {
> + dev_err(bus->dev,
> + "SA==%02x but msg1->addr==%02x\n",
> + slave_addr, msg1->addr);
> + return -EINVAL;
Ditto.
> + }
> + if ((msg1->flags & I2C_M_RD) == 0) {
> + dev_err(bus->dev,
> + "num = 2 but both msg are write.\n");
> + return -EINVAL;
> + }
Ditto.
> + if (msg1->flags & I2C_M_RECV_LEN) {
> + nread = 1;
> + read_block = true;
> + if (msg1->flags & I2C_CLIENT_PEC)
> + read_PEC = true;
> + } else {
> + nread = msg1->len;
> + read_block = false;
> + }
> + }
> + }
> +
> + /* Adaptive TimeOut: astimated time in usec + 100% margin */
> + timeout_usec = (2 * 10000 / bus->bus_freq) * (2 + nread + nwrite);
> + timeout = max(msecs_to_jiffies(35), usecs_to_jiffies(timeout_usec));
> + if (nwrite >= 32 * 1024 || nread >= 32 * 1024) {
> + dev_err(bus->dev, "i2c%d buffer too big\n", bus->num);
> + return -EINVAL;
> + }
Ditto.
> +
> + time_left = jiffies + msecs_to_jiffies(DEFAULT_STALL_COUNT) + 1;
> + do {
> + /*
> + * we must clear slave address immediately when the bus is not
> + * busy, so we spinlock it, but we don't keep the lock for the
> + * entire while since it is too long.
> + */
> + spin_lock_irqsave(&bus->lock, flags);
> + bus_busy = ioread8(bus->reg + NPCM_I2CCST) & NPCM_I2CCST_BB;
> + spin_unlock_irqrestore(&bus->lock, flags);
> +
> + } while (time_is_after_jiffies(time_left) && bus_busy);
> +
> + if (bus_busy) {
> + iowrite8(NPCM_I2CCST_BB, bus->reg + NPCM_I2CCST);
> + npcm_i2c_reset(bus);
> + i2c_recover_bus(adap);
> + return -EAGAIN;
> + }
> +
> + npcm_i2c_init_params(bus);
> + bus->dest_addr = slave_addr;
> + bus->msgs = msgs;
> + bus->msgs_num = num;
> + bus->cmd_err = 0;
> + bus->read_block_use = read_block;
> +
> + reinit_completion(&bus->cmd_complete);
> + if (!npcm_i2c_master_start_xmit(bus, slave_addr, nwrite, nread,
> + write_data, read_data, read_PEC,
> + read_block))
> + ret = -EBUSY;
> +
> + if (ret != -EBUSY) {
> + time_left = wait_for_completion_timeout(&bus->cmd_complete,
> + timeout);
> +
> + if (time_left == 0) {
> +#ifdef CONFIG_DEBUG_FS
> + if (bus->timeout_cnt == ULLONG_MAX) {
> + dev_dbg(bus->dev,
> + "timeout_cnt reach max, reset to 0");
> + bus->timeout_cnt = 0;
> + }
> + bus->timeout_cnt++;
> +#endif
> + if (bus->master_or_slave == I2C_MASTER) {
> + i2c_recover_bus(adap);
> + bus->cmd_err = -EIO;
> + bus->state = I2C_IDLE;
> + }
> + }
> + }
> + ret = bus->cmd_err;
> +
> + /* if there was BER, check if need to recover the bus: */
> + if (bus->cmd_err == -EAGAIN)
> + ret = i2c_recover_bus(adap);
> +
> + return bus->cmd_err;
> +}
> +
> +static u32 npcm_i2c_functionality(struct i2c_adapter *adap)
> +{
> + return I2C_FUNC_I2C |
> + I2C_FUNC_SMBUS_EMUL |
> + I2C_FUNC_SMBUS_BLOCK_DATA |
> + I2C_FUNC_SMBUS_PEC |
> + I2C_FUNC_SLAVE;
> +}
> +
> +static const struct i2c_adapter_quirks npcm_i2c_quirks = {
> + .max_read_len = 32768,
> + .max_write_len = 32768,
These limits are for simple reads/writes with num_msgs == 1. If you have
limits also for num_msgs == 2, then you also need to fill
'max_comb_1st_msg_len' and 'max_comb_2nd_msg_len'. (Because for some HW
these are different values then)
> + .max_num_msgs = 2,
You can drop this because I2C_AQ_COMB_WRITE_THEN_READ implies it.
> + .flags = I2C_AQ_COMB_WRITE_THEN_READ,
> +};
> +
> +static const struct i2c_algorithm npcm_i2c_algo = {
> + .master_xfer = npcm_i2c_master_xfer,
> + .functionality = npcm_i2c_functionality,
> +};
> +
> +#ifdef CONFIG_DEBUG_FS
> +/* i2c debugfs directory: used to keep health monitor of i2c devices */
> +static struct dentry *npcm_i2c_debugfs_dir;
> +
> +static void i2c_init_debugfs(struct platform_device *pdev, struct npcm_i2c *bus)
> +{
> + struct dentry *d;
> +
> + if (!npcm_i2c_debugfs_dir)
> + return;
> +
> + d = debugfs_create_dir(dev_name(&pdev->dev), npcm_i2c_debugfs_dir);
> + if (IS_ERR_OR_NULL(d))
> + return;
> +
> + debugfs_create_u64("ber_cnt", 0444, d, &bus->ber_cnt);
> + debugfs_create_u64("nack_cnt", 0444, d, &bus->nack_cnt);
> + debugfs_create_u64("rec_succ_cnt", 0444, d, &bus->rec_succ_cnt);
> + debugfs_create_u64("rec_fail_cnt", 0444, d, &bus->rec_fail_cnt);
> + debugfs_create_u64("timeout_cnt", 0444, d, &bus->timeout_cnt);
> +
> + bus->debugfs = d;
> +}
> +#else
> +static void i2c_init_debugfs(struct platform_device *pdev, struct npcm_i2c *bus)
> +{
> +}
> +#endif
> +
> +static int npcm_i2c_probe_bus(struct platform_device *pdev)
> +{
> + struct npcm_i2c *bus;
> + struct i2c_adapter *adap;
> + struct clk *i2c_clk;
> + static struct regmap *gcr_regmap;
> + static struct regmap *clk_regmap;
> + int ret;
> + int num;
> +
> + bus = devm_kzalloc(&pdev->dev, sizeof(*bus), GFP_KERNEL);
> + if (!bus)
> + return -ENOMEM;
> +
> + bus->dev = &pdev->dev;
> +
> + num = of_alias_get_id(pdev->dev.of_node, "i2c");
> + bus->num = num;
Why not assigning it directly and save the 'num' variable?
> + /* core clk must be acquired to calculate module timing settings */
> + i2c_clk = devm_clk_get(&pdev->dev, NULL);
> + if (IS_ERR(i2c_clk))
> + return PTR_ERR(i2c_clk);
> + bus->apb_clk = clk_get_rate(i2c_clk);
> +
> + gcr_regmap = syscon_regmap_lookup_by_compatible("nuvoton,npcm750-gcr");
> + if (IS_ERR(gcr_regmap))
> + return IS_ERR(gcr_regmap);
> + regmap_write(gcr_regmap, NPCM_I2CSEGCTL, NPCM_I2CSEGCTL_INIT_VAL);
> +
> + clk_regmap = syscon_regmap_lookup_by_compatible("nuvoton,npcm750-clk");
> + if (IS_ERR(clk_regmap))
> + return IS_ERR(clk_regmap);
> +
> + bus->reg = devm_platform_ioremap_resource(pdev, 0);
> + if (IS_ERR(bus->reg))
> + return PTR_ERR((bus)->reg);
> +
> + spin_lock_init(&bus->lock);
> + init_completion(&bus->cmd_complete);
> +
> + adap = &bus->adap;
> + adap->owner = THIS_MODULE;
> + adap->class = I2C_CLASS_HWMON | I2C_CLASS_SPD | I2C_CLIENT_SLAVE;
Since you have a DT compatible, you won't need classes. Just drop them.
> + adap->retries = 3;
> + adap->timeout = HZ;
> + adap->algo = &npcm_i2c_algo;
> + adap->quirks = &npcm_i2c_quirks;
> + adap->algo_data = bus;
> + adap->dev.parent = &pdev->dev;
> + adap->dev.of_node = pdev->dev.of_node;
> + adap->nr = pdev->id;
> +
> + bus->irq = platform_get_irq(pdev, 0);
> + if (bus->irq < 0)
> + return bus->irq;
> +
> + ret = devm_request_irq(bus->dev, bus->irq, npcm_i2c_bus_irq, 0,
> + dev_name(bus->dev), bus);
> + if (ret)
> + return ret;
> +
> + ret = __npcm_i2c_init(bus, pdev);
> + if (ret)
> + return ret;
> +
> + ret = npcm_i2c_recovery_init(adap);
> + if (ret)
> + return ret;
> +
> + i2c_set_adapdata(adap, bus);
> +
> + snprintf(bus->adap.name, sizeof(bus->adap.name), "Nuvoton i2c");
Maybe you want to add something more specific in case you have multiple
instances of this driver at runtime.
> + ret = i2c_add_numbered_adapter(&bus->adap);
> + if (ret) {
> + dev_err(&pdev->dev, "failed to add numbered adapter %d\n", ret);
The I2C core will print warnings for you.
> + return ret;
> + }
> + platform_set_drvdata(pdev, bus);
> +
> + i2c_init_debugfs(pdev, bus);
> + return 0;
> +}
> +
...
> +#ifdef CONFIG_DEBUG_FS
> +static int __init npcm_i2c_init(void)
> +{
> + struct dentry *dir;
> +
> + dir = debugfs_create_dir("i2c", NULL);
Okay, the GPIO fault injector could also need such a directory. I will
add this to the core. And then send an incremental patch for your
driver.
> + if (IS_ERR_OR_NULL(dir))
> + return 0;
> +
> + npcm_i2c_debugfs_dir = dir;
> + return 0;
> +}
> +
> +static void __exit npcm_i2c_exit(void)
> +{
> + debugfs_remove_recursive(npcm_i2c_debugfs_dir);
> +}
> +
> +module_init(npcm_i2c_init);
> +module_exit(npcm_i2c_exit);
> +#endif
> +
> +MODULE_AUTHOR("Avi Fishman <avi.fishman@gmail.com>");
> +MODULE_AUTHOR("Tali Perry <tali.perry@nuvoton.com>");
> +MODULE_AUTHOR("Tyrone Ting <kfting@nuvoton.com>");
> +MODULE_DESCRIPTION("Nuvoton I2C Bus Driver");
> +MODULE_LICENSE("GPL v2");
> +MODULE_VERSION("0.1.3");
> +
> --
> 2.22.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v4 01/16] spi: dw: Add Tx/Rx finish wait methods to the MID DMA
From: Andy Shevchenko @ 2020-05-22 14:36 UTC (permalink / raw)
To: Serge Semin
Cc: Mark Brown, Linus Walleij, Vinod Koul, Feng Tang, Grant Likely,
Alan Cox, Georgy Vlasov, Ramil Zaripov, Alexey Malahov,
Thomas Bogendoerfer, Paul Burton, Ralf Baechle, Arnd Bergmann,
Rob Herring, linux-mips, devicetree, Wan Ahmad Zainie,
Thomas Gleixner, Jarkko Nikula, wuxu.wu, Clement Leger,
Linus Walleij, linux-spi, linux-kernel
In-Reply-To: <20200522140025.bmd6bhpjjk5msvsm@mobilestation>
On Fri, May 22, 2020 at 05:00:25PM +0300, Serge Semin wrote:
> On Fri, May 22, 2020 at 04:27:43PM +0300, Serge Semin wrote:
> > On Fri, May 22, 2020 at 02:10:13PM +0100, Mark Brown wrote:
> > > On Fri, May 22, 2020 at 03:44:06PM +0300, Serge Semin wrote:
> > > > On Fri, May 22, 2020 at 03:34:27PM +0300, Andy Shevchenko wrote:
...
> > > > > > Realistically it seems unlikely that the clock will be even as slow as
> > > > > > double digit kHz though, and if we do I'd not be surprised to see other
> > > > > > problems kicking in. It's definitely good to handle such things if we
> > > > > > can but so long as everything is OK for realistic use cases I'm not sure
> > > > > > it should be a blocker.
> > >
> > > > As I see it the only way to fix the problem for any use-case is to move the
> > > > busy-wait loop out from the tasklet's callback, add a completion variable to the
> > > > DW SPI data and wait for all the DMA transfers completion in the
> > > > dw_spi_dma_transfer() method. Then execute both busy-wait loops (there we can
> > > > use spi_delay_exec() since it's a work-thread) and call
> > > > spi_finalize_current_transfer() after it. What do you think?
> > >
> > > I'm concerned that this will add latency for the common case to handle a
> > > potential issue for unrealistically slow buses but yeah, if it's an
> > > issue kicking up to task context is how you'd handle it.
> >
> > I am not that worried about the latency (most likely it'll be the same as
> > before), but I am mostly concerned regarding a most likely need to re-implement
> > a local version spi_transfer_wait(). We can't afford wait for the completion
> > indefinitely here, so the wait_for_completion_timeout() should be used, for which
> > I would have to calculate a decent timeout based on the transfer capabilities,
> > etc. So basically it would mean to partly copy the spi_transfer_wait() to this
> > module.(
>
> I'd also wait for Andy's suggestion regarding this, since he's been worried
> about the delay length in the first place. So he may come up with a better
> solution in this regard.
The completion approach sounds quite heavy to me.
Since we haven't got any report for such an issue, I prefer as simplest as
possible approach.
If we add might_sleep() wouldn't it be basically reimplementation of the
spi_delay_exec() again?
And second question, do you experience this warning on your system?
My point is: let's warn and see if anybody comes with a bug report. We will
solve an issue when it appears.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 09/12] dt-bindings: arm: fsl: Add msi-map device-tree binding for fsl-mc bus
From: Robin Murphy @ 2020-05-22 14:34 UTC (permalink / raw)
To: Rob Herring, Diana Craciun OSS
Cc: devicetree, Hanjun Guo, Marc Zyngier, Will Deacon, PCI,
Sudeep Holla, Rafael J. Wysocki, Linux IOMMU, linux-acpi,
Makarand Pawagi, Catalin Marinas, Bjorn Helgaas,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CAL_JsqKf+cq9Nhs+M8ihC-Ls24YH-WEofW8H4kkFPWMhZw=unA@mail.gmail.com>
On 2020-05-22 15:08, Rob Herring wrote:
> On Fri, May 22, 2020 at 3:57 AM Diana Craciun OSS
> <diana.craciun@oss.nxp.com> wrote:
>>
>> On 5/22/2020 12:42 PM, Robin Murphy wrote:
>>> On 2020-05-22 00:10, Rob Herring wrote:
>>>> On Thu, May 21, 2020 at 7:00 AM Lorenzo Pieralisi
>>>> <lorenzo.pieralisi@arm.com> wrote:
>>>>>
>>>>> From: Laurentiu Tudor <laurentiu.tudor@nxp.com>
>>>>>
>>>>> The existing bindings cannot be used to specify the relationship
>>>>> between fsl-mc devices and GIC ITSes.
>>>>>
>>>>> Add a generic binding for mapping fsl-mc devices to GIC ITSes, using
>>>>> msi-map property.
>>>>>
>>>>> Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
>>>>> Cc: Rob Herring <robh+dt@kernel.org>
>>>>> ---
>>>>> .../devicetree/bindings/misc/fsl,qoriq-mc.txt | 30
>>>>> +++++++++++++++++--
>>>>> 1 file changed, 27 insertions(+), 3 deletions(-)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
>>>>> b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
>>>>> index 9134e9bcca56..b0813b2d0493 100644
>>>>> --- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
>>>>> +++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
>>>>> @@ -18,9 +18,9 @@ same hardware "isolation context" and a 10-bit
>>>>> value called an ICID
>>>>> the requester.
>>>>>
>>>>> The generic 'iommus' property is insufficient to describe the
>>>>> relationship
>>>>> -between ICIDs and IOMMUs, so an iommu-map property is used to define
>>>>> -the set of possible ICIDs under a root DPRC and how they map to
>>>>> -an IOMMU.
>>>>> +between ICIDs and IOMMUs, so the iommu-map and msi-map properties
>>>>> are used
>>>>> +to define the set of possible ICIDs under a root DPRC and how they
>>>>> map to
>>>>> +an IOMMU and a GIC ITS respectively.
>>>>>
>>>>> For generic IOMMU bindings, see
>>>>> Documentation/devicetree/bindings/iommu/iommu.txt.
>>>>> @@ -28,6 +28,9 @@ Documentation/devicetree/bindings/iommu/iommu.txt.
>>>>> For arm-smmu binding, see:
>>>>> Documentation/devicetree/bindings/iommu/arm,smmu.yaml.
>>>>>
>>>>> +For GICv3 and GIC ITS bindings, see:
>>>>> +Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml.
>>>>>
>>>>> +
>>>>> Required properties:
>>>>>
>>>>> - compatible
>>>>> @@ -119,6 +122,15 @@ Optional properties:
>>>>> associated with the listed IOMMU, with the iommu-specifier
>>>>> (i - icid-base + iommu-base).
>>>>>
>>>>> +- msi-map: Maps an ICID to a GIC ITS and associated iommu-specifier
>>>>> + data.
>>>>> +
>>>>> + The property is an arbitrary number of tuples of
>>>>> + (icid-base,iommu,iommu-base,length).
>>>>
>>>> I'm confused because the example has GIC ITS phandle, not an IOMMU.
>>>>
>>>> What is an iommu-base?
>>>
>>> Right, I was already halfway through writing a reply to say that all
>>> the copy-pasted "iommu" references here should be using the
>>> terminology from the pci-msi.txt binding instead.
>>
>> Right, will change it.
>>
>>>
>>>>> +
>>>>> + Any ICID in the interval [icid-base, icid-base + length) is
>>>>> + associated with the listed GIC ITS, with the iommu-specifier
>>>>> + (i - icid-base + iommu-base).
>>>>> Example:
>>>>>
>>>>> smmu: iommu@5000000 {
>>>>> @@ -128,6 +140,16 @@ Example:
>>>>> ...
>>>>> };
>>>>>
>>>>> + gic: interrupt-controller@6000000 {
>>>>> + compatible = "arm,gic-v3";
>>>>> + ...
>>>>> + its: gic-its@6020000 {
>>>>> + compatible = "arm,gic-v3-its";
>>>>> + msi-controller;
>>>>> + ...
>>>>> + };
>>>>> + };
>>>>> +
>>>>> fsl_mc: fsl-mc@80c000000 {
>>>>> compatible = "fsl,qoriq-mc";
>>>>> reg = <0x00000008 0x0c000000 0 0x40>, /* MC
>>>>> portal base */
>>>>> @@ -135,6 +157,8 @@ Example:
>>>>> msi-parent = <&its>;
>>>
>>> Side note: is it right to keep msi-parent here? It rather implies that
>>> the MC itself has a 'native' Device ID rather than an ICID, which I
>>> believe is not strictly true. Plus it's extra-confusing that it
>>> doesn't specify an ID either way, since that makes it look like the
>>> legacy PCI case that gets treated implicitly as an identity msi-map,
>>> which makes no sense at all to combine with an actual msi-map.
>>
>> Before adding msi-map, the fsl-mc code assumed that ICID and streamID
>> are equal and used msi-parent just to get the reference to the ITS node.
>> Removing msi-parent will break the backward compatibility of the already
>> existing systems. Maybe we should mention that this is legacy and not to
>> be used for newer device trees.
>
> If ids are 1:1, then the DT should use msi-parent. If there is
> remapping, then use msi-map. A given system should use one or the
> other. I suppose if some ids are 1:1 and the msi-map was added to add
> additional support for ids not 1:1, then you could end up with both.
> That's fine in dts files, but examples should reflect the 'right' way.
Is that defined anywhere? The generic MSI binding just has some weaselly
wording about buses:
"When #msi-cells is non-zero, busses with an msi-parent will require
additional properties to describe the relationship between devices on
the bus and the set of MSIs they can potentially generate."
which appears at odds with its own definition of msi-parent as including
an msi-specifier (or at best very unclear about what value that
specifier should take in this case).
The PCI MSI binding goes even further and specifically reserves
msi-parent for cases where there is no sideband data. As far as I'm
aware, the fact that the ITS driver implements a bodge for the "empty
msi-parent even though #msi-cells > 0" case is merely a compatibility
thing for old DTs from before this was really thought through, not an
officially-specified behaviour.
Robin.
^ permalink raw reply
* Re: [PATCH 09/15] device core: Add ability to handle multiple dma offsets
From: Jim Quinlan @ 2020-05-22 14:31 UTC (permalink / raw)
To: Nicolas Saenz Julienne
Cc: Rob Herring, Frank Rowand, Christoph Hellwig, Marek Szyprowski,
Robin Murphy, Greg Kroah-Hartman, Suzuki K Poulose,
Saravana Kannan, Heikki Krogerus, Rafael J. Wysocki, Dan Williams,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE, open list,
open list:DMA MAPPING HELPERS
In-Reply-To: <2aa6f276085319a5af7a96b3d7bdd0501641a7d7.camel@suse.de>
Hi Nicolas,
On Wed, May 20, 2020 at 7:28 AM Nicolas Saenz Julienne
<nsaenzjulienne@suse.de> wrote:
>
> Hi Jim,
> thanks for having a go at this! My two cents.
>
> On Tue, 2020-05-19 at 16:34 -0400, Jim Quinlan wrote:
> > The device variable 'dma_pfn_offset' is used to do a single
> > linear map between cpu addrs and dma addrs. The variable
> > 'dma_map' is added to struct device to point to an array
> > of multiple offsets which is required for some devices.
> >
> > Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
> > ---
>
> [...]
>
> > --- a/include/linux/device.h
> > +++ b/include/linux/device.h
> > @@ -493,6 +493,8 @@ struct dev_links_info {
> > * @bus_dma_limit: Limit of an upstream bridge or bus which imposes a smaller
> > * DMA limit than the device itself supports.
> > * @dma_pfn_offset: offset of DMA memory range relatively of RAM
> > + * @dma_map: Like dma_pfn_offset but used when there are multiple
> > + * pfn offsets for multiple dma-ranges.
> > * @dma_parms: A low level driver may set these to teach IOMMU code
> > about
> > * segment limitations.
> > * @dma_pools: Dma pools (if dma'ble device).
> > @@ -578,7 +580,12 @@ struct device {
> > allocations such descriptors. */
> > u64 bus_dma_limit; /* upstream dma constraint */
> > unsigned long dma_pfn_offset;
> > -
> > +#ifdef CONFIG_DMA_PFN_OFFSET_MAP
> > + const void *dma_offset_map; /* Like dma_pfn_offset, but for
> > + * the unlikely case of multiple
> > + * offsets. If non-null, dma_pfn_offset
> > + * will be 0. */
>
> I get a bad feeling about separating the DMA offset handling into two distinct
> variables. Albeit generally frowned upon, there is a fair amount of trickery
> around dev->dma_pfn_offset all over the kernel. usb_alloc_dev() comes to mind
> for example. And this obviously doesn't play well with it.
The trickery should only be present when
CONFIG_DMA_PFN_OFFSET_MAP=y**. Otherwise it does no harm. Also, I
feel that if dev-dma_pfn_offset is valid then so is
dev->dma_pfn_offset_map -- they both use the same mechanism in the
same places. I am merely
extending something that has been in Linux for a long time..
Further, I could have had dma_pfn_offset_map subsume dma_pfn_offset
but I wanted to leave it alone since folks would complain that it
would go from an addition to an if-clause and an inline function. But
if I did go that way there would only be one mechanism that would
cover both cases.
> I feel a potential
> solution to multiple DMA ranges should completely integrate with the current
> device DMA handling code, without special cases, on top of that, be transparent
> to the user.
Having dma_pfn_offset_map subsume dma_pfn_offset would integrate the
current code too. And I am not sure what you mean by being
"transparent to the user" -- the writer of the PCIe endpoint driver is
going to do some DMA calls and they have no idea if this mechanism is
in play or not.
>
> In more concrete terms, I'd repackage dev->bus_dma_limit and
> dev->dma_pfn_offset into a list/array of DMA range structures
This is sort of what I am doing except I defined my own structure.
Using the of_range structure would require one to do the same extra
calculations over and over for a DMA call; this is why I defined my
structure that has all of the needed precomputed variables.
> and adapt/create
> the relevant getter/setter functions so as for DMA users not to have to worry
> about the specifics of a device's DMA constraints.
I'm not sure I understand where these getter/setter functions would
exist or what they would do.
> editing dev->dma_pfn_offset, you'd be passing a DMA range structure to the
> device core, and let it take the relevant decisions on how to handle it
How and where would the device core operate for these getter/setters?
In how many places in the code? The way I see it, any solution has to
adjust the value when doing dma2phys and phys2dma conversions, and the
most efficient place to do that is in the two DMA header files (the
second one is for ARM).
> internally (overwrite, add a new entry, merge them, etc...).
I'm concerned that this would be overkill; I am just trying to get a
driver upstream for some baroque PCIe RC HW I'm not sure if we should
set up something elaborate when the demand is not there.
I'll be posting a v2. ChrisophH has sent me some personal feedback
which I am incorporating; so feel free to discuss your ideas with him
as well because I really want consensus on any large changes in
direction.
Thanks,
Jim
** CONFIG_DMA_OF_PFN_OFFSET_MAP=y only occurs when building for
ARCH_BRCMSTB. However, ARCH_BRCMSTB is set by the ARM64 defconfig and
the ARM multi_v7_defconfig, so it would be activated for those
defconfigs. This may(a) get us kicked out of those defconfigs or
(b) we may have to keep DMA_OF_PFN_OFFSET_MAP off in those defconfigs
and only turn it on solely for Broadcom STB Linux.
>
> Easier said than done. :)
>
> Regards,
> Nicolas
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox