Re: [PATCH v2 4/8] arm64: dts: r8a7796: salvator-x: Add panel backlight support
On Mon, May 15, 2017 at 09:50:39AM +0300, Laurent Pinchart wrote:
> Hi Simon,
>
> On Monday 15 May 2017 07:48:11 Simon Horman wrote:
> > On Sat, May 13, 2017 at 09:56:12PM +0300, Laurent Pinchart wrote:
> > > Hi Simon,
> > >
> > > I'm afraid you added nodes in the wrong places when applying the patch to
> > > salvator-x.dtsi :-( Please see below.
> > >
> > > On Thursday 27 Apr 2017 17:43:56 Laurent Pinchart wrote:
> > >> Hi Ulrich,
> > >>
> > >> Thank you for the patch.
> > >>
> > >> On Thursday 27 Apr 2017 16:37:39 Ulrich Hecht wrote:
> > >>> The panel backlight is controlled through a GPIO and a PWM channel.
> > >>>
> > >>> Signed-off-by: Ulrich Hecht
> > >>
> > >> Reviewed-by: Laurent Pinchart
> > >>
> > >>> ---
> > >>>
> > >>> arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts | 22 +
> > >>> 1 file changed, 22 insertions(+)
> > >>>
> > >>> diff --git a/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
> > >>> b/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts index
> > >>> 14d9e51..abda84c
> > >>> 100644
> > >>> --- a/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
> > >>> +++ b/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
> > >>> @@ -133,6 +133,11 @@
> > >>> function = "i2c2";
> > >>> };
> > >>>
> > >>> + pwm1_pins: pwm {
> > >>> + groups = "pwm1_a";
> > >>> + function = "pwm1";
> > >>> + };
> > >>> +
> > >
> > > This is alphabetically ordered here and isn't anymore in your devel
> > > branch.
> >
> > Thanks, I will move it from between scif_clk_pins and sdhi0_pins to
> > between i2c2_pins and scif1_pins.
> >
> > >>> sdhi0_pins: sd0 {
> > >>> groups = "sdhi0_data4", "sdhi0_ctrl";
> > >>> function = "sdhi0";
> > >>> @@ -183,6 +188,16 @@
> > >>> interrupt-parent = <&gpio2>;
> > >>> interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
> > >>> };
> > >>> +
> > >>> + backlight: backlight {
> > >>> + compatible = "pwm-backlight";
> > >>> + pwms = <&pwm1 0 5>;
> > >>> +
> > >>> + brightness-levels = <256 128 64 16 8 4 0>;
> > >>> + default-brightness-level = <6>;
> > >>> +
> > >>> + enable-gpios = <&gpio6 7 GPIO_ACTIVE_HIGH>;
> > >>> + };
> > >
> > > The backlight node needs to be added as a child of the root node, while
> > > you've added it to the DU node in your devel branch.
> >
> > Thanks. I have moved it to between audio_clkout and reg_1p8v in
> > the root node.
> >
> > >>> };
> > >>>
> > >>> &extal_clk {
> > >>> @@ -235,6 +250,13 @@
> > >>> status = "okay";
> > >>> };
> > >>>
> > >>> +&pwm1 {
> > >>> + pinctrl-0 = <&pwm1_pins>;
> > >>> + pinctrl-names = "default";
> > >>> +
> > >>> + status = "okay";
> > >>> +};
> > >>> +
> > >
> > > This is alphabetically ordered here and isn't anymore in your devel
> > > branch.
> >
> > Thanks, I have moved it from between rcar_sound and scif1 to
> > between pfc and rcar_sound.
> >
> > > Can you rebase your devel branch to fix this ?
> >
> > Sure. I have the following in my local tree which I plan to push
> > a later today.
>
> That looks good to me, thank you !
Thanks for checking.
Re: [PATCH/RFT renesas-devel] arm64: dts: ulcb: Set drive-strength for ravb pins
On Fri, May 12, 2017 at 04:39:03PM +0200, Geert Uytterhoeven wrote:
> Hi Simon,
>
> On Tue, May 2, 2017 at 12:30 PM, Simon Horman
> wrote:
> > The EthernetAVB should not depend on the bootloader to setup correct
> > drive-strength values. Values for drive-strength where found by
> > examining the registers after the bootloader has configured the
> > registers and successfully used the EthernetAVB.
> >
> > Based on:
> > * commit 7d73a4da2681 ("arm64: dts: r8a7795: salvator-x: Set drive-strength
> > for ravb pins")
> > * commit 4903987033be ("arm64: dts: r8a7796: salvator-x: Set drive-strength
> > for ravb pins")
> >
> > Cc: Geert Uytterhoeven
> > Cc: Niklas Söderlund
> > Signed-off-by: Simon Horman
>
> Reviewed-by: Geert Uytterhoeven
>
> > * Compile tested only due to lack of hardware access
>
> So how did you examine the registers? ;-)
You got me there: copy-paste gone wrong.
> Hence I examined the registers myself:
> - H3ULCB has the same register settings as Salvator-X with H3 ES1.0
> - M3ULCB has the same register settings as Salvator-X with M3-W ES1.0
> or H3 ES2.0.
That was my assumption, which is what I should have written.
But as you have checked - thanks for that - I will leave the changelog
as-is and queue up the patch.
Re: [PATCH v5 0/6] R-Car H3 HDMI output DT integration
On Mon, May 15, 2017 at 08:52:56AM +0200, Simon Horman wrote: > On Sun, May 14, 2017 at 02:16:12AM +0300, Laurent Pinchart wrote: > > Hello, > > > > This patch series contains all the DT changes needed to integrate HDMI > > output > > support for the H3 Salvator-X board. > > > > The patches have been rebased on top of a merge of Simon's latest devel > > branch > > and v4.12-rc1, and have taken Geert's comments into account. For > > convenience, > > they are available from > > > > git://linuxtv.org/pinchartl/media.git drm-next-dt-v5-20170513 > > > > Simon, this still depends on driver changes that were merged by Linus for > > v4.12-rc1 (the checkpatch warnings related to unknown compatible strings > > will > > then be gone). Again, please only apply these patches after you merge > > v4.12-rc1 in your tree. > > Thanks. Now that v4.12-rc1 has been released I have rebased by > arm64-dt-for-v4.13 branch on top of it. I plan to merge that into both > renesas-next and renesas-devel, and push later today. I somehow forgot to say that I have queued up these patches in the arm64-dt-for-v4.13 branch.
Re: [PATCH v5 0/6] R-Car H3 HDMI output DT integration
On Sun, May 14, 2017 at 02:16:12AM +0300, Laurent Pinchart wrote: > Hello, > > This patch series contains all the DT changes needed to integrate HDMI output > support for the H3 Salvator-X board. > > The patches have been rebased on top of a merge of Simon's latest devel branch > and v4.12-rc1, and have taken Geert's comments into account. For convenience, > they are available from > > git://linuxtv.org/pinchartl/media.git drm-next-dt-v5-20170513 > > Simon, this still depends on driver changes that were merged by Linus for > v4.12-rc1 (the checkpatch warnings related to unknown compatible strings will > then be gone). Again, please only apply these patches after you merge > v4.12-rc1 in your tree. Thanks. Now that v4.12-rc1 has been released I have rebased by arm64-dt-for-v4.13 branch on top of it. I plan to merge that into both renesas-next and renesas-devel, and push later today.
Re: [PATCH v2 4/8] arm64: dts: r8a7796: salvator-x: Add panel backlight support
Hi Simon,
On Monday 15 May 2017 07:48:11 Simon Horman wrote:
> On Sat, May 13, 2017 at 09:56:12PM +0300, Laurent Pinchart wrote:
> > Hi Simon,
> >
> > I'm afraid you added nodes in the wrong places when applying the patch to
> > salvator-x.dtsi :-( Please see below.
> >
> > On Thursday 27 Apr 2017 17:43:56 Laurent Pinchart wrote:
> >> Hi Ulrich,
> >>
> >> Thank you for the patch.
> >>
> >> On Thursday 27 Apr 2017 16:37:39 Ulrich Hecht wrote:
> >>> The panel backlight is controlled through a GPIO and a PWM channel.
> >>>
> >>> Signed-off-by: Ulrich Hecht
> >>
> >> Reviewed-by: Laurent Pinchart
> >>
> >>> ---
> >>>
> >>> arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts | 22 +
> >>> 1 file changed, 22 insertions(+)
> >>>
> >>> diff --git a/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
> >>> b/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts index
> >>> 14d9e51..abda84c
> >>> 100644
> >>> --- a/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
> >>> +++ b/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
> >>> @@ -133,6 +133,11 @@
> >>> function = "i2c2";
> >>> };
> >>>
> >>> + pwm1_pins: pwm {
> >>> + groups = "pwm1_a";
> >>> + function = "pwm1";
> >>> + };
> >>> +
> >
> > This is alphabetically ordered here and isn't anymore in your devel
> > branch.
>
> Thanks, I will move it from between scif_clk_pins and sdhi0_pins to
> between i2c2_pins and scif1_pins.
>
> >>> sdhi0_pins: sd0 {
> >>> groups = "sdhi0_data4", "sdhi0_ctrl";
> >>> function = "sdhi0";
> >>> @@ -183,6 +188,16 @@
> >>> interrupt-parent = <&gpio2>;
> >>> interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
> >>> };
> >>> +
> >>> + backlight: backlight {
> >>> + compatible = "pwm-backlight";
> >>> + pwms = <&pwm1 0 5>;
> >>> +
> >>> + brightness-levels = <256 128 64 16 8 4 0>;
> >>> + default-brightness-level = <6>;
> >>> +
> >>> + enable-gpios = <&gpio6 7 GPIO_ACTIVE_HIGH>;
> >>> + };
> >
> > The backlight node needs to be added as a child of the root node, while
> > you've added it to the DU node in your devel branch.
>
> Thanks. I have moved it to between audio_clkout and reg_1p8v in
> the root node.
>
> >>> };
> >>>
> >>> &extal_clk {
> >>> @@ -235,6 +250,13 @@
> >>> status = "okay";
> >>> };
> >>>
> >>> +&pwm1 {
> >>> + pinctrl-0 = <&pwm1_pins>;
> >>> + pinctrl-names = "default";
> >>> +
> >>> + status = "okay";
> >>> +};
> >>> +
> >
> > This is alphabetically ordered here and isn't anymore in your devel
> > branch.
>
> Thanks, I have moved it from between rcar_sound and scif1 to
> between pfc and rcar_sound.
>
> > Can you rebase your devel branch to fix this ?
>
> Sure. I have the following in my local tree which I plan to push
> a later today.
That looks good to me, thank you !
> From: Laurent Pinchart
>
> [PATCH] arm64: dts: salvator-x: Add panel backlight support
>
> The panel backlight is controlled through a GPIO and a PWM channel.
>
> Signed-off-by: Laurent Pinchart
> [simon: apply to salvator-x.dtsi instead of r8a7795-salvator-x.dts]
> Signed-off-by: Simon Horman
> ---
> arch/arm64/boot/dts/renesas/salvator-x.dtsi | 22 ++
> 1 file changed, 22 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/salvator-x.dtsi
> b/arch/arm64/boot/dts/renesas/salvator-x.dtsi index
> d5eb022d247c..7240bcd75918 100644
> --- a/arch/arm64/boot/dts/renesas/salvator-x.dtsi
> +++ b/arch/arm64/boot/dts/renesas/salvator-x.dtsi
> @@ -58,6 +58,16 @@
> clock-frequency = <11289600>;
> };
>
> + backlight: backlight {
> + compatible = "pwm-backlight";
> + pwms = <&pwm1 0 5>;
> +
> + brightness-levels = <256 128 64 16 8 4 0>;
> + default-brightness-level = <6>;
> +
> + enable-gpios = <&gpio6 7 GPIO_ACTIVE_HIGH>;
> + };
> +
> reg_1p8v: regulator0 {
> compatible = "regulator-fixed";
> regulator-name = "fixed-1.8V";
> @@ -358,6 +368,11 @@
> function = "i2c2";
> };
>
> + pwm1_pins: pwm {
> + groups = "pwm1_a";
> + function = "pwm1";
> + };
> +
> scif1_pins: scif1 {
> groups = "scif1_data_a", "scif1_ctrl";
> function = "scif1";
> @@ -443,6 +458,13 @@
> };
> };
>
> +&pwm1 {
> + pinctrl-0 = <&pwm1_pins>;
> + pinctrl-names = "default";
> +
> + status = "okay";
> +};
> +
> &rcar_sound {
> pinctrl-0 = <&sound_pins &sound_clk_pins>;
> pinctrl-names = "default";
--
Regards,
Laurent Pinchart
Re: [PATCH v2 05/10] arm64: renesas: r8a7796: add Sound SSI PIO support
On Fri, May 12, 2017 at 11:43:39AM +0200, Geert Uytterhoeven wrote:
> Hi Morimoto-san, Simon,
>
> On Fri, May 12, 2017 at 2:14 AM, Kuninori Morimoto
> wrote:
> > --- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> > +++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> > @@ -1259,7 +1259,42 @@
> > };
> >
> > rcar_sound: sound@ec50 {
>
> [...]
>
> > + power-domains = <&cpg>;
>
> power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
>
> (by comparing r8a779[66].dtsi).
>
> Simon: As you have already applied this, can you please fix it up in your
> tree?
Sure, I have squashed the batch below into the relevant patch in my local
tree which I plan to push later today.
Morimoto-san,
FYI, I did a s/renesas/dts/ in the subject of the patches in this series.
On Mon, May 15, 2017 at 01:01:23AM +, Kuninori Morimoto wrote:
>
> From: Kuninori Morimoto
>
> commit a32681b13157f("arm64: dts: r8a7796: add Sound SSI PIO support")
> added R-Car sound, but it used old style power-domains.
> This patch tidyup it.
>
> Signed-off-by: Kuninori Morimoto
> ---
> arch/arm64/boot/dts/renesas/r8a7796.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> index f815532..f21c5ce 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> @@ -1323,7 +1323,7 @@
> "ctu.1", "ctu.0",
> "dvc.0", "dvc.1",
> "clk_a", "clk_b", "clk_c", "clk_i";
> - power-domains = <&cpg>;
> + power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
> status = "disabled";
>
> rcar_sound,dvc {
The patch I now have queued-up is as follows:
From: Kuninori Morimoto
arm64: dts: r8a7796: add Sound SSI PIO support
Signed-off-by: Kuninori Morimoto
Signed-off-by: Simon Horman
---
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 64 +++-
1 file changed, 62 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 0a76a1c53082..5c6e54a1e27a 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -1165,7 +1165,42 @@
};
rcar_sound: sound@ec50 {
- /* placeholder */
+ /*
+* #sound-dai-cells is required
+*
+* Single DAI : #sound-dai-cells = <0>; <&rcar_sound>;
+* Multi DAI : #sound-dai-cells = <1>; <&rcar_sound N>;
+*/
+ /*
+* #clock-cells is required for audio_clkout0/1/2/3
+*
+* clkout : #clock-cells = <0>; <&rcar_sound>;
+* clkout0/1/2/3: #clock-cells = <1>; <&rcar_sound N>;
+*/
+ compatible = "renesas,rcar_sound-r8a7796",
"renesas,rcar_sound-gen3";
+ reg = <0 0xec50 0 0x1000>, /* SCU */
+ <0 0xec5a 0 0x100>, /* ADG */
+ <0 0xec54 0 0x1000>, /* SSIU */
+ <0 0xec541000 0 0x280>, /* SSI */
+ <0 0xec74 0 0x200>; /* Audio DMAC peri
peri*/
+ reg-names = "scu", "adg", "ssiu", "ssi", "audmapp";
+
+ clocks = <&cpg CPG_MOD 1005>,
+<&cpg CPG_MOD 1006>, <&cpg CPG_MOD 1007>,
+<&cpg CPG_MOD 1008>, <&cpg CPG_MOD 1009>,
+<&cpg CPG_MOD 1010>, <&cpg CPG_MOD 1011>,
+<&cpg CPG_MOD 1012>, <&cpg CPG_MOD 1013>,
+<&cpg CPG_MOD 1014>, <&cpg CPG_MOD 1015>,
+<&audio_clk_a>, <&audio_clk_b>,
+<&audio_clk_c>,
+<&cpg CPG_CORE R8A7796_CLK_S0D4>;
+ clock-names = "ssi-all",
+ "ssi.9", "ssi.8", "ssi.7", "ssi.6",
+ "ssi.5", "ssi.4", "ssi.3", "ssi.2",
+ "ssi.1", "ssi.0",
+ "clk_a", "clk_b", "clk_c", "clk_i";
+ power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
+ status = "disabled";
rcar_sound,dvc {
dvc0: dvc-0 {
@@ -1184,9 +1219,34 @@
rcar_sound,ssi {
ssi0: ssi-0 {
+ interrupts = ;
Re: [PATCH v2 4/8] arm64: dts: r8a7796: salvator-x: Add panel backlight support
On Sat, May 13, 2017 at 09:56:12PM +0300, Laurent Pinchart wrote:
> Hi Simon,
>
> I'm afraid you added nodes in the wrong places when applying the patch to
> salvator-x.dtsi :-( Please see below.
>
> On Thursday 27 Apr 2017 17:43:56 Laurent Pinchart wrote:
> > Hi Ulrich,
> >
> > Thank you for the patch.
> >
> > On Thursday 27 Apr 2017 16:37:39 Ulrich Hecht wrote:
> > > The panel backlight is controlled through a GPIO and a PWM channel.
> > >
> > > Signed-off-by: Ulrich Hecht
> >
> > Reviewed-by: Laurent Pinchart
> >
> > > ---
> > >
> > > arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts | 22
> > > 1 file changed, 22 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
> > > b/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts index
> > > 14d9e51..abda84c
> > > 100644
> > > --- a/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
> > > +++ b/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
> > > @@ -133,6 +133,11 @@
> > > function = "i2c2";
> > > };
> > >
> > > + pwm1_pins: pwm {
> > > + groups = "pwm1_a";
> > > + function = "pwm1";
> > > + };
> > > +
>
> This is alphabetically ordered here and isn't anymore in your devel branch.
Thanks, I will move it from between scif_clk_pins and sdhi0_pins to
between i2c2_pins and scif1_pins.
> > > sdhi0_pins: sd0 {
> > > groups = "sdhi0_data4", "sdhi0_ctrl";
> > > function = "sdhi0";
> > > @@ -183,6 +188,16 @@
> > > interrupt-parent = <&gpio2>;
> > > interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
> > > };
> > > +
> > > + backlight: backlight {
> > > + compatible = "pwm-backlight";
> > > + pwms = <&pwm1 0 5>;
> > > +
> > > + brightness-levels = <256 128 64 16 8 4 0>;
> > > + default-brightness-level = <6>;
> > > +
> > > + enable-gpios = <&gpio6 7 GPIO_ACTIVE_HIGH>;
> > > + };
>
> The backlight node needs to be added as a child of the root node, while
> you've
> added it to the DU node in your devel branch.
Thanks. I have moved it to between audio_clkout and reg_1p8v in
the root node.
> > > };
> > >
> > > &extal_clk {
> > > @@ -235,6 +250,13 @@
> > > status = "okay";
> > > };
> > >
> > > +&pwm1 {
> > > + pinctrl-0 = <&pwm1_pins>;
> > > + pinctrl-names = "default";
> > > +
> > > + status = "okay";
> > > +};
> > > +
>
> This is alphabetically ordered here and isn't anymore in your devel branch.
Thanks, I have moved it from between rcar_sound and scif1 to
between pfc and rcar_sound.
> Can you rebase your devel branch to fix this ?
Sure. I have the following in my local tree which I plan to push
a later today.
From: Laurent Pinchart
[PATCH] arm64: dts: salvator-x: Add panel backlight support
The panel backlight is controlled through a GPIO and a PWM channel.
Signed-off-by: Laurent Pinchart
[simon: apply to salvator-x.dtsi instead of r8a7795-salvator-x.dts]
Signed-off-by: Simon Horman
---
arch/arm64/boot/dts/renesas/salvator-x.dtsi | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/salvator-x.dtsi
b/arch/arm64/boot/dts/renesas/salvator-x.dtsi
index d5eb022d247c..7240bcd75918 100644
--- a/arch/arm64/boot/dts/renesas/salvator-x.dtsi
+++ b/arch/arm64/boot/dts/renesas/salvator-x.dtsi
@@ -58,6 +58,16 @@
clock-frequency = <11289600>;
};
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pwm1 0 5>;
+
+ brightness-levels = <256 128 64 16 8 4 0>;
+ default-brightness-level = <6>;
+
+ enable-gpios = <&gpio6 7 GPIO_ACTIVE_HIGH>;
+ };
+
reg_1p8v: regulator0 {
compatible = "regulator-fixed";
regulator-name = "fixed-1.8V";
@@ -358,6 +368,11 @@
function = "i2c2";
};
+ pwm1_pins: pwm {
+ groups = "pwm1_a";
+ function = "pwm1";
+ };
+
scif1_pins: scif1 {
groups = "scif1_data_a", "scif1_ctrl";
function = "scif1";
@@ -443,6 +458,13 @@
};
};
+&pwm1 {
+ pinctrl-0 = <&pwm1_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
+
&rcar_sound {
pinctrl-0 = <&sound_pins &sound_clk_pins>;
pinctrl-names = "default";
--
2.1.4
Re: [PATCH v2 0/8] r8a7795/6 Salvator-X PWM enablement
On Fri, May 12, 2017 at 01:00:34PM +0300, Laurent Pinchart wrote: > Hi Simon, > > On Friday 12 May 2017 11:16:39 Simon Horman wrote: > > On Thu, Apr 27, 2017 at 04:37:35PM +0200, Ulrich Hecht wrote: > > > Hi! > > > > > > Here's the revised series enabling PWMs on r8a7795 and r8a7796 Salvator-X > > > boards. > > > > > > This revision addresses the issues found by Geert and adds Laurent's > > > backlight support patch, including a version for r8a7796. > > > > > > CU > > > Uli > > > > > > Changes since v1: > > > - PWM clock is S0D12, not S3D4 > > > - dts: fix register lengths, add resets > > > - only enable one set of pins for each PWM > > > - add backlight support > > > > > > Laurent Pinchart (1): > > > arm64: dts: r8a7795: salvator-x: Add panel backlight support > > > > > > Ryo Kodama (2): > > > clk: renesas: r8a7796: add PWM clock > > > arm64: dts: r8a7796-salvator-x: Add PWM device support > > > > > > Takeshi Kihara (3): > > > pinctrl: sh-pfc: r8a7796: Add PWM pins, groups and functions > > > arm64: dts: r8a7796: Add PWM device nodes > > > arm64: dts: r8a7795-salvator-x: Enable PWM2 > > > > I did not notice any regressions on salvator-x/r8a7796 after applying up > > the dts patches without the clk and pinctrl patches. So I have queued up > > the dts patches as follows: > > > > * arm64: dts: r8a7796: Add PWM device nodes > > -> applied > > > > * arm64: dts: r8a7795: salvator-x: Add panel backlight support > > * arm64: dts: r8a7795-salvator-x: Enable PWM2 > > I've asked Ulrich for a clarification on this patch as I'm not sure it's > needed, but he hasn't answered yet. Could we delay merging it until the > situation is clarified ? Sure, I will drop the "Enable PWM2" patch. > All other patches in this series should be fine. > > > -> applied to salvator-x.dtsi instead of r8a7796-salvator-x.dts > > > > * arm64: dts: r8a7796: salvator-x: Add panel backlight support > > * arm64: dts: r8a7796-salvator-x: Add PWM device support > > -> not applied as they would be the same changes as those above > > applied to salvator-x.dtsi > > > > > Ulrich Hecht (2): > > > arm64: dts: r8a7796: salvator-x: Add panel backlight support > > > dt-bindings: pwm: Add R-Car M3-W device tree bindings > > > > I took the liberty of reposting the dt-bindings patch with an updated To/Cc > > list. > > > > > .../devicetree/bindings/pwm/renesas,pwm-rcar.txt | 1 + > > > arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 34 + > > > arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts | 35 + > > > arch/arm64/boot/dts/renesas/r8a7796.dtsi | 70 ++ > > > drivers/clk/renesas/r8a7796-cpg-mssr.c | 1 + > > > drivers/pinctrl/sh-pfc/pfc-r8a7796.c | 153 > > > 6 files changed, 294 insertions(+) > > -- > Regards, > > Laurent Pinchart >
Re: [PATCH v3 1/3] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0
On Fri, May 12, 2017 at 11:49:24AM +0200, Geert Uytterhoeven wrote:
> Hi Simon,
>
> On Fri, May 12, 2017 at 9:32 AM, Simon Horman wrote:
> > On Thu, May 11, 2017 at 05:42:27PM +0200, Geert Uytterhoeven wrote:
> >> On Thu, May 11, 2017 at 4:53 PM, Simon Horman wrote:
> >> > On Thu, May 11, 2017 at 01:58:52PM +0200, Geert Uytterhoeven wrote:
> >> >> Update r8a7795.dtsi so it corresponds to R-Car H3 ES2.0 or later:
> >> >> - The following devices no longer exist on ES2.0, and are thus
> >> >> removed:
> >> >> fcpf2, fcpvd3, fcpvi2, fdp1-2, usb3-if1, vspd3, vspi2.
> >> >> - The DU <-> VSPD topology is different on ES2.0, hence remove the
> >> >> "compatible" and "vsps" properties from the DU node until the driver
> >> >> can handle this.
> >> >>
> >> >> Move support for the ES1.x revision of the R-Car H3 SoC into a
> >> >> separate file. To avoid duplication, r8a7795-es1.dtsi includes
> >> >> r8a7795.dtsi, add adds/removes/overrides device nodes and properties
> >> >> where needed.
> >> >
> >> > I think the above should be re-worded given your explanation below the
> >> > scissors that no deletion or overriding occurs.
> >>
> >> I wanted to document clearly what needs to be done in the generic case...
> >> I agree no removal or override is done right now.
> >>
> >> If you prefer it that way, I can reword it.
> >
> > I think I would prefer that.
> >
> >> >> Switch r8a7795-salvator-x.dts and r8a7795-h3ulcb.dts from r8a7795.dtsi
> >> >> to r8a7795-es1.dtsi to preserve compatibility.
> >> >>
> >> >> Signed-off-by: Geert Uytterhoeven
> >> >> ---
> >> >> While currently r8a7795-es1.dtsi only adds device nodes, removal of
> >> >> devices nodes and properties can be implemented using the /delete-node/
> >> >> and /delete-property/ keywords, as shown below:
> >> >>
> >> >> &soc {
> >> >> /delete-node/ @;
> >> >> };
> >> >>
> >> >> & {
> >> >> /delete-property/ ;
> >> >> };
> >> >
> >> > I would be interested to also see an example of an override and
> >> > for the examples to be included in the changelog itself.
> >>
> >> You mean above the scissors? ;-)
> >
> > Yes, that is what I meant.
> >
> >> Currently we don't have any devices or properties in DT that need removals
> >> or overrides. Note that I did test those.
> >>
> >> If we add the "vsps" property to the DU node for ES2.0, we can have an
> >> override for it now. But we've plenty of experience with letting .dts
> >> override properties in .dtsi.
> >
> > Ok, point taken.
> >
> >> For node deletion, we'll have to wait until someone enables the extra USB
> >> channels on ES2.0.
> >>
> >> For property deletion, I don't have an actual example in mind, but I wanted
> >> to be sure that worked in case we ever need it.
> >
> > I appreciate you taking the time to test deletion.
> > I think its worth documenting above the scissors.
>
> Will update in v4. I''l have to rebase anyway.
Great, thanks!
[PATCH][RESEND] ASoC: rsnd: add missing clocks/clock-names on Document
From: Kuninori Morimoto Signed-off-by: Kuninori Morimoto --- Documentation/devicetree/bindings/sound/renesas,rsnd.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt index 3332910..13cb21d5 100644 --- a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt +++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt @@ -368,6 +368,10 @@ Required properties: see below for detail. - #sound-dai-cells : it must be 0 if your system is using single DAI it must be 1 if your system is using multi DAI +- clocks : References to SSI/SRC/MIX/CTU/DVC/AUDIO_CLK clocks. +- clock-names : List of necessary clock names. + "ssi-all", "ssi.X", "src.X", "mix.X", "ctu.X", + "dvc.X", "clk_a", "clk_b", "clk_c", "clk_i" Optional properties: - #clock-cells : it must be 0 if your system has audio_clkout -- 1.9.1
[PATCH] ASoC: rsnd: tidyup Sampling rate convert example on Document
From: Kuninori Morimoto
"renesas,rsrc-card" is exchanged to "simple-scu-card".
Let's update Document
Signed-off-by: Kuninori Morimoto
---
.../devicetree/bindings/sound/renesas,rsnd.txt | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
index 15a7316..3332910 100644
--- a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
+++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
@@ -83,11 +83,11 @@ SRC can convert [xx]Hz to [yy]Hz. Then, it has below 2 modes
** Asynchronous mode
--
-You need to use "renesas,rsrc-card" sound card for it.
+You need to use "simple-scu-audio-card" sound card for it.
example)
sound {
- compatible = "renesas,rsrc-card";
+ compatible = "simple-scu-audio-card";
...
/*
* SRC Asynchronous mode setting
@@ -97,12 +97,12 @@ example)
* Inputed 48kHz data will be converted to
* system specified Hz
*/
- convert-rate = <48000>;
+ simple-audio-card,convert-rate = <48000>;
...
- cpu {
+ simple-audio-card,cpu {
sound-dai = <&rcar_sound>;
};
- codec {
+ simple-audio-card,codec {
...
};
};
@@ -141,23 +141,23 @@ For more detail information, see below
${LINUX}/sound/soc/sh/rcar/ctu.c
- comment of header
-You need to use "renesas,rsrc-card" sound card for it.
+You need to use "simple-scu-audio-card" sound card for it.
example)
sound {
- compatible = "renesas,rsrc-card";
+ compatible = "simple-scu-audio-card";
...
/*
* CTU setting
* All input data will be converted to 2ch
* as output data
*/
- convert-channels = <2>;
+ simple-audio-card,convert-channels = <2>;
...
- cpu {
+ simple-audio-card,cpu {
sound-dai = <&rcar_sound>;
};
- codec {
+ simple-audio-card,codec {
...
};
};
@@ -190,22 +190,22 @@ and these sounds will be merged by MIX.
aplay -D plughw:0,0 .wav &
aplay -D plughw:0,1 .wav
-You need to use "renesas,rsrc-card" sound card for it.
+You need to use "simple-scu-audio-card" sound card for it.
Ex)
[MEM] -> [SRC1] -> [CTU02] -+-> [MIX0] -> [DVC0] -> [SSI0]
|
[MEM] -> [SRC2] -> [CTU03] -+
sound {
- compatible = "renesas,rsrc-card";
+ compatible = "simple-scu-audio-card";
...
- cpu@0 {
+ simple-audio-card,cpu@0 {
sound-dai = <&rcar_sound 0>;
};
- cpu@1 {
+ simple-audio-card,cpu@1 {
sound-dai = <&rcar_sound 1>;
};
- codec {
+ simple-audio-card,codec {
...
};
};
--
1.9.1
[PATCH] ASoC: rsnd: remove error pointer for adg->clkout[i]
From: Kuninori Morimoto
commit d7f298197a22f11b38059f257842dac7c30a564c
("ASoC: rcar: fixup of_clk_add_provider() usage for multi clkout")
added adg->clkout[i] = ERR_PTR(-ENOENT),
but, adg->clkout[i] are assumed NULL or clk pointer.
This patch fix it.
Signed-off-by: Kuninori Morimoto
---
sound/soc/sh/rcar/adg.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/sound/soc/sh/rcar/adg.c b/sound/soc/sh/rcar/adg.c
index cb4eab0..36bece8 100644
--- a/sound/soc/sh/rcar/adg.c
+++ b/sound/soc/sh/rcar/adg.c
@@ -556,7 +556,6 @@ static void rsnd_adg_get_clkout(struct rsnd_priv *priv,
clk = clk_register_fixed_rate(dev, clkout_name[i],
parent_clk_name, 0,
req_rate[0]);
- adg->clkout[i] = ERR_PTR(-ENOENT);
if (!IS_ERR(clk))
adg->clkout[i] = clk;
}
--
1.9.1
[PATCH] ASoC: rsnd: clkout-lr-asynchronous is AUDIO_CLKOUT related property
From: Kuninori Morimoto
clkout-lr-asynchronous is AUDIO_CLKOUT related property, thus, it
should be handled by rsnd_adg_get_clkout().
Signed-off-by: Kuninori Morimoto
---
sound/soc/sh/rcar/adg.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/sound/soc/sh/rcar/adg.c b/sound/soc/sh/rcar/adg.c
index 66203d1..cb4eab0 100644
--- a/sound/soc/sh/rcar/adg.c
+++ b/sound/soc/sh/rcar/adg.c
@@ -480,6 +480,9 @@ static void rsnd_adg_get_clkout(struct rsnd_priv *priv,
if (req_rate[0] % 48000 == 0)
adg->flags = AUDIO_OUT_48;
+ if (of_get_property(np, "clkout-lr-asynchronous", NULL))
+ adg->flags = LRCLK_ASYNC;
+
/*
* This driver is assuming that AUDIO_CLKA/AUDIO_CLKB/AUDIO_CLKC
* have 44.1kHz or 48kHz base clocks for now.
@@ -578,7 +581,6 @@ int rsnd_adg_probe(struct rsnd_priv *priv)
{
struct rsnd_adg *adg;
struct device *dev = rsnd_priv_to_dev(priv);
- struct device_node *np = dev->of_node;
int ret;
adg = devm_kzalloc(dev, sizeof(*adg), GFP_KERNEL);
@@ -595,9 +597,6 @@ int rsnd_adg_probe(struct rsnd_priv *priv)
rsnd_adg_get_clkin(priv, adg);
rsnd_adg_get_clkout(priv, adg);
- if (of_get_property(np, "clkout-lr-asynchronous", NULL))
- adg->flags = LRCLK_ASYNC;
-
priv->adg = adg;
rsnd_adg_clk_enable(priv);
--
1.9.1
[PATCH] ASoC: rsnd: remove mismatch explain comment from src.c
From: Kuninori Morimoto
Before, src.c cares SRC and SSIU, but now SSIU is cared by ssiu.c by
commit c7f69ab5364d ("ASoC: rsnd: use mod base common method on SSIU").
This patch removes mismatched explanation for SRC/SSIU from src.c
Signed-off-by: Kuninori Morimoto
---
sound/soc/sh/rcar/src.c | 14 --
1 file changed, 14 deletions(-)
diff --git a/sound/soc/sh/rcar/src.c b/sound/soc/sh/rcar/src.c
index a8ab26d..e4bde0c 100644
--- a/sound/soc/sh/rcar/src.c
+++ b/sound/soc/sh/rcar/src.c
@@ -51,20 +51,6 @@ struct rsnd_src {
*
*/
-/*
- * src.c is caring...
- *
- * Gen1
- *
- * [mem] -> [SRU] -> [SSI]
- *||
- *
- * Gen2
- *
- * [mem] -> [SRC] -> [SSIU] -> [SSI]
- *|-|
- */
-
static void rsnd_src_activation(struct rsnd_mod *mod)
{
rsnd_mod_write(mod, SRC_SWRSR, 0);
--
1.9.1
[PATCH v2][RESEND] ASoC: rsnd: control kctrl items acceptance anytime/runtime
From: Kuninori Morimoto
Current SRC/DVC/CTU adds kctrl for each device,
and SRC can adjust its sampling rate during playback,
thus, this feature should be enabled only *during* playback.
This patch controls it more clearly
Signed-off-by: Kuninori Morimoto
---
sound/soc/sh/rcar/core.c | 17 +
sound/soc/sh/rcar/ctu.c | 6 ++
sound/soc/sh/rcar/dvc.c | 5 +
sound/soc/sh/rcar/rsnd.h | 16 ++--
sound/soc/sh/rcar/src.c | 2 ++
5 files changed, 40 insertions(+), 6 deletions(-)
diff --git a/sound/soc/sh/rcar/core.c b/sound/soc/sh/rcar/core.c
index 1744015..d3c9078 100644
--- a/sound/soc/sh/rcar/core.c
+++ b/sound/soc/sh/rcar/core.c
@@ -982,6 +982,9 @@ static int rsnd_kctrl_put(struct snd_kcontrol *kctrl,
struct rsnd_kctrl_cfg *cfg = kcontrol_to_cfg(kctrl);
int i, change = 0;
+ if (!cfg->accept(cfg->io))
+ return 0;
+
for (i = 0; i < cfg->size; i++) {
if (cfg->texts) {
change |= (uc->value.enumerated.item[i] != cfg->val[i]);
@@ -998,6 +1001,18 @@ static int rsnd_kctrl_put(struct snd_kcontrol *kctrl,
return change;
}
+int rsnd_kctrl_accept_anytime(struct rsnd_dai_stream *io)
+{
+ return 1;
+}
+
+int rsnd_kctrl_accept_runtime(struct rsnd_dai_stream *io)
+{
+ struct snd_pcm_runtime *runtime = rsnd_io_to_runtime(io);
+
+ return !!runtime;
+}
+
struct rsnd_kctrl_cfg *rsnd_kctrl_init_m(struct rsnd_kctrl_cfg_m *cfg)
{
cfg->cfg.val = cfg->val;
@@ -1016,6 +1031,7 @@ int rsnd_kctrl_new(struct rsnd_mod *mod,
struct rsnd_dai_stream *io,
struct snd_soc_pcm_runtime *rtd,
const unsigned char *name,
+ int (*accept)(struct rsnd_dai_stream *io),
void (*update)(struct rsnd_dai_stream *io,
struct rsnd_mod *mod),
struct rsnd_kctrl_cfg *cfg,
@@ -1050,6 +1066,7 @@ int rsnd_kctrl_new(struct rsnd_mod *mod,
cfg->texts = texts;
cfg->max= max;
cfg->size = size;
+ cfg->accept = accept;
cfg->update = update;
cfg->card = card;
cfg->kctrl = kctrl;
diff --git a/sound/soc/sh/rcar/ctu.c b/sound/soc/sh/rcar/ctu.c
index 9dcc1f9..4ba8f2f 100644
--- a/sound/soc/sh/rcar/ctu.c
+++ b/sound/soc/sh/rcar/ctu.c
@@ -279,12 +279,14 @@ static int rsnd_ctu_pcm_new(struct rsnd_mod *mod,
/* CTU Pass */
ret = rsnd_kctrl_new_m(mod, io, rtd, "CTU Pass",
+ rsnd_kctrl_accept_anytime,
NULL,
&ctu->pass, RSND_MAX_CHANNELS,
0xC);
/* ROW0 */
ret = rsnd_kctrl_new_m(mod, io, rtd, "CTU SV0",
+ rsnd_kctrl_accept_anytime,
NULL,
&ctu->sv0, RSND_MAX_CHANNELS,
0x00FF);
@@ -293,6 +295,7 @@ static int rsnd_ctu_pcm_new(struct rsnd_mod *mod,
/* ROW1 */
ret = rsnd_kctrl_new_m(mod, io, rtd, "CTU SV1",
+ rsnd_kctrl_accept_anytime,
NULL,
&ctu->sv1, RSND_MAX_CHANNELS,
0x00FF);
@@ -301,6 +304,7 @@ static int rsnd_ctu_pcm_new(struct rsnd_mod *mod,
/* ROW2 */
ret = rsnd_kctrl_new_m(mod, io, rtd, "CTU SV2",
+ rsnd_kctrl_accept_anytime,
NULL,
&ctu->sv2, RSND_MAX_CHANNELS,
0x00FF);
@@ -309,6 +313,7 @@ static int rsnd_ctu_pcm_new(struct rsnd_mod *mod,
/* ROW3 */
ret = rsnd_kctrl_new_m(mod, io, rtd, "CTU SV3",
+ rsnd_kctrl_accept_anytime,
NULL,
&ctu->sv3, RSND_MAX_CHANNELS,
0x00FF);
@@ -317,6 +322,7 @@ static int rsnd_ctu_pcm_new(struct rsnd_mod *mod,
/* Reset */
ret = rsnd_kctrl_new_s(mod, io, rtd, "CTU Reset",
+ rsnd_kctrl_accept_anytime,
rsnd_ctu_value_reset,
&ctu->reset, 1);
diff --git a/sound/soc/sh/rcar/dvc.c b/sound/soc/sh/rcar/dvc.c
index 463de83..75af6e7 100644
--- a/sound/soc/sh/rcar/dvc.c
+++ b/sound/soc/sh/rcar/dvc.c
@@ -257,6 +257,7 @@ static int rsnd_dvc_pcm_new(struct rsnd_mod *mod,
ret = rsnd_kctrl_new_m(mod, io, rtd,
is_play ?
"DVC Out Playback Volume" : "DVC In Capture Volume",
+ rsnd_kctrl_accept_anytime,
rsnd_dvc_volume_update,
&dvc->volume, slots,
0x0080 - 1);
@@ -267,6 +268,7 @@ static int rsnd_dvc_pcm_new(struct r
[PATCH] ASoC: rsnd: remove un-used OUF_SRCO/I macro
From: Kuninori Morimoto Signed-off-by: Kuninori Morimoto --- sound/soc/sh/rcar/src.c | 4 1 file changed, 4 deletions(-) diff --git a/sound/soc/sh/rcar/src.c b/sound/soc/sh/rcar/src.c index 20b5b2e..a8ab26d 100644 --- a/sound/soc/sh/rcar/src.c +++ b/sound/soc/sh/rcar/src.c @@ -12,10 +12,6 @@ #define SRC_NAME "src" -/* SRCx_STATUS */ -#define OUF_SRCO ((1 << 12) | (1 << 13)) -#define OUF_SRCI ((1 << 9) | (1 << 8)) - /* SCU_SYSTEM_STATUS0/1 */ #define OUF_SRC(id)((1 << (id + 16)) | (1 << id)) -- 1.9.1
[PATCH] arm64: dts: r8a7796: tidyup power-domains for R-Car Sound
From: Kuninori Morimoto
commit a32681b13157f("arm64: dts: r8a7796: add Sound SSI PIO support")
added R-Car sound, but it used old style power-domains.
This patch tidyup it.
Signed-off-by: Kuninori Morimoto
---
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index f815532..f21c5ce 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -1323,7 +1323,7 @@
"ctu.1", "ctu.0",
"dvc.0", "dvc.1",
"clk_a", "clk_b", "clk_c", "clk_i";
- power-domains = <&cpg>;
+ power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
status = "disabled";
rcar_sound,dvc {
--
1.9.1
Re: [PATCH v2 02/10] pinctrl: sh-pfc: r8a7796: add Audio SSI pin support
Hi Geert
> > +static const unsigned int ssi34_ctrl_pins[] = {
> > + /* SCK, WS */
> > + RCAR_GP_PIN(6, 5), RCAR_GP_PIN(6, 6),
> > +};
> > +static const unsigned int ssi34_ctrl_mux[] = {
> > + SSI_SCK34_MARK, SSI_WS34_MARK,
> > +};
>
> I'm a bit confused by this group: in the R-Car M3 Pin Function Rev. 0.54
> sheet, these are named SCK349 resp. WS349. According to the history, the
> change from {SCK,WS}34 to {SCK,WS}349 was made at the same time as the
> change from {SCK,WS}0129 to {SCK,WS}01239.
> However, the former change is not reflected in the PFC section of the
> Hardware User's Manual.
>
> So which is correct: {SCK,WS}34 or {SCK,WS}349?
>
> Can you please enlighten me?
It seems
SSI_SCK 0129 -> 01239 was happen on v0.51 timing,
SSI_SCK 34 -> 349 was happen on v0.54 timing.
r8a7795 is still using old (= 34) naming now.
I can adjust it both r8a7795/6.
Do you want to v3 patch for r8a7796 ?
or incremental patch is OK with r8a7795 ?
Best regards
---
Kuninori Morimoto
Re: [PATCH 0/6] R-Car DU: Fix IOMMU operation when connected to VSP
Hi Magnus, On Wednesday 07 Sep 2016 17:01:06 Magnus Damm wrote: > Hi Laurent, > > Thanks for your help with this. Good to see that the DU driver is > getting closer to work with the IPMMU hardware! Please see below for > some feedback from me. > > On Fri, Aug 19, 2016 at 5:39 PM, Laurent Pinchart wrote: > > Hello, > > > > This patch series fixes the rcar-du-drm driver to support VSP plane > > sources with an IOMMU. It is available for convenience at > > > > git://linuxtv.org/pinchartl/media.git iommu/devel/du > > > > On R-Car Gen3 the DU has no direct memory access but sources planes > > through VSP instances. When an IOMMU is inserted between the VSP and > > memory, the DU framebuffers need to be DMA mapped using the VSP device, > > not the DU device as currently done. The same situation can also be > > reproduced on Gen2 hardware by linking the VSP to the DU in DT [1], > > effectively disabling direct memory access by the DU. > > > > The situation is made quite complex by the fact that different planes can > > be connected to different DU instances, and thus served by different > > IOMMUs (or, in practice on existing hardware, by the same IOMMU but > > through different micro-TLBs). We thus can't allocate and map buffers to > > the right device in a single dma_alloc_wc() operation as done in the DRM > > CMA GEM helpers. > > > > However, on such setups, the DU DT node doesn't reference IOMMUs as the DU > > does not perform any direct memory access. We can thus keep the GEM object > > allocation unchanged, and the DMA addresses that we receive in the DU > > driver will be physical addresses. Those buffers then need to be mapped > > to the VSP device when they are associated with planes. Fortunately the > > atomic framework provides two plane helper operations, .prepare_fb() and > > .cleanup_fb() that we can use for this purpose. > > > > The reality is slightly more complex than this on Gen3, as an FCP device > > instance sits between VSP instances and memory. It is the FCP devices that > > are connected to the IOMMUs, and buffer mapping thus need to be performed > > using the FCP devices. This isn't required on Gen2 as the platforms don't > > have any FCPs. > > > > Patches 1/6 and 2/6 unconstify the state argument to the .prepare_fb() and > > .cleanup_fb() operations, to allow storing the mapped buffer addresses in > > the state. Patches 3/6 and 4/6 then extend the rcar-fcp driver API to > > expose the FCP struct device. Patch 5/6 extends the vsp1 driver API to > > allow mapping a scatter-gather list to the VSP, with the implementation > > using the FCP devices instead when available. Patch 6/6 then use the vsp1 > > mapping API in the rcar-du-drm driver to map and unmap buffers when > > needed. > > > > The series has been tested on Gen2 (Lager) only as the Gen3 IOMMU is known > > to be broken. > > Slight clarification, the R-Car Gen3 family as a whole does not have > broken IPMMU hardware. Early R-Car H3 revisions do require some errata > handling though, but M3-W and later ES versions and MP of H3 will be > fine. Given the early R-Car H3 errata I agree it makes sense to > develop and test this series on R-Car Gen2 though. > > > A possible improvement is to modify the GEM object allocation mechanism to > > use non-contiguous memory when the DU driver detects that all the VSP > > instances it is connected to use an IOMMU (possibly through FCP devices). > > > > An issue has been noticed with synchronization between page flip and VSP > > operation. Buffers get unmapped (and possibly freed) before the VSP is > > done reading them. The problem isn't new, but is much more noticeable with > > IOMMU support enabled as any hardware access to unmapped memory generates > > an IOMMU page fault immediately. > > > > The series unfortunately contain a dependency between DRM and V4L2 > > patches, complicating upstream merge. As there's no urgency to merge patch > > 6/6 due to the IOMMU being broken on Gen3 at the moment, I propose merging > > patches 1/6-2/6 and 3/6-5/6 independently for the next kernel release. > > > > I would particularly appreciate feedback on the APIs introduced by patches > > 4/6 and 5/6. > > The code in general looks fine to me. The APIs introduced by patches > 4/6 and 5/6 seem quite straightforward. Is there something I can do to > help with those? > > > [1] > > https://www.mail-archive.com/linux-renesas-soc@vger.kernel.org/msg06589.h > > tml > > Laurent Pinchart (6): > > drm: Don't implement empty prepare_fb()/cleanup_fb() > > drm: Unconstify state argument to prepare_fb()/cleanup_fb() > > v4l: rcar-fcp: Don't get/put module reference > > v4l: rcar-fcp: Add an API to retrieve the FCP device > > v4l: vsp1: Add API to map and unmap DRM buffers through the VSP > > drm: rcar-du: Map memory through the VSP device > > > > drivers/gpu/drm/arc/arcpgu_crtc.c | 2 - > > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 4 +- > > drivers/gpu/drm/fsl-dc
Re: [PATCH] iio: adc: max9611: Fix attribute measure unit
On 09/05/17 12:53, Geert Uytterhoeven wrote:
Hi Jacopo,
On Tue, May 9, 2017 at 9:57 AM, Jacopo Mondi wrote:
The power and current "shunt-resistor" attribute's 'show' function
displays the resistor value in milli-Ohms, while the ABI description
specifies it should be displayed in Ohms. Fix it.
Reported-by: Geert Uytterhoeven
Signed-off-by: Jacopo Mondi
# cat /sys/bus/iio/devices/iio:device*/in_*_shunt_resistor
0.005000
0.005000
0.005000
0.005000
#
$ grep shunt-resistor -- arch/arm64/boot/dts/renesas/salvator-x.dtsi
shunt-resistor-micro-ohms = <5000>;
shunt-resistor-micro-ohms = <5000>;
$
Tested-by: Geert Uytterhoeven
Applied to the fixes-togreg branch of iio.git.
Thanks,
Jonathan
---
drivers/iio/adc/max9611.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/iio/adc/max9611.c b/drivers/iio/adc/max9611.c
index ec82106..4580ebd 100644
--- a/drivers/iio/adc/max9611.c
+++ b/drivers/iio/adc/max9611.c
@@ -438,10 +438,10 @@ static ssize_t max9611_shunt_resistor_show(struct device
*dev,
struct max9611_dev *max9611 = iio_priv(dev_to_iio_dev(dev));
unsigned int i, r;
- i = max9611->shunt_resistor_uohm / 1000;
- r = max9611->shunt_resistor_uohm % 1000;
+ i = max9611->shunt_resistor_uohm / 100;
+ r = max9611->shunt_resistor_uohm % 100;
- return sprintf(buf, "%u.%03u\n", i, r);
+ return sprintf(buf, "%u.%06u\n", i, r);
}
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] dmaengine: rcar-dmac: wait for ISR to finish before freeing resources
On Fri, May 12, 2017 at 02:49:38PM +0200, Niklas Söderlund wrote: > On 2017-04-07 14:33:47 +0300, Laurent Pinchart wrote: > > Hi Geert, > > > > On Wednesday 05 Apr 2017 12:40:11 Geert Uytterhoeven wrote: > > > On Wed, Apr 5, 2017 at 11:14 AM, Niklas Söderlund wrote: > > > > On 2017-04-05 08:55:31 +0530, Vinod Koul wrote: > > > >> On Thu, Mar 30, 2017 at 09:38:39AM +0200, Niklas Söderlund wrote: > > > >>> On 2017-03-29 15:30:42 +0200, Niklas Söderlund wrote: > > > On 2017-03-29 14:31:33 +0200, Geert Uytterhoeven wrote: > > > > On Wed, Mar 29, 2017 at 12:40 AM, Niklas Söderlund wrote: > > > >> This fixes a race condition where the channel resources could be > > > >> freed before the ISR had finished running resulting in a NULL > > > >> pointer reference from the ISR. > > > >> > > > >> [ 167.148934] Unable to handle kernel NULL pointer dereference > > > >> at virtual address > > > >> [ 167.157051] pgd = 80003c641000 > > > >> [ 167.160449] [] *pgd=7c507003, > > > >> *pud=7c4ff003, *pmd= > > > >> [ 167.168719] Internal error: Oops: 9646 [#1] PREEMPT SMP > > > >> [ 167.174289] Modules linked in: > > > >> [ 167.177348] CPU: 3 PID: 10547 Comm: dma_ioctl Not tainted > > > >> 4.11.0-rc1-1-g8d92afddc2f6633a #73 > > > >> [ 167.186131] Hardware name: Renesas Salvator-X board based on > > > >> r8a7795 (DT) > > > >> [ 167.192917] task: 80003a411a00 task.stack: 80003bcd4000 > > > >> [ 167.198850] PC is at rcar_dmac_chan_prep_sg+0xe0/0x400 > > > >> [ 167.203985] LR is at rcar_dmac_chan_prep_sg+0x48/0x400 > > > > > > > > Do you have a test case to trigger this? > > > > > > Yes I have a testcase, it's rather complex and involves both a kernel > > > module and a userspaces application to stress the rcar-dmac. I'm > > > checking if I can share this publicly or not, please hold :-) > > > >>> > > > >>> I have now received feedback that I'm unfortunately not allowed to > > > >>> share the test case :-( > > > >>> > > > >>> The big picture in how to trigger this problem is that you start a DMA > > > >>> transfer like this: > > > >>> > > > >>> struct dma_async_tx_descriptor *tx = ...; > > > >>> > > > >>> ... > > > >>> > > > >>> tx->tx_submit(tx); > > > >>> > > > >>> And then you directly call dma_release_channel() on this channel > > > >>> without making sure the completion callback ran or anything. Now if > > > >>> you > > > >>> are unlucky the ISR have not finished running for the DMA when > > > >>> dma_release_channel() starts to clean up resources. The > > > >>> synchronisation > > > >>> point in the dma_release_channel() call path fixes this. > > > >> > > > >> Well the API expectation would be you abort the txn before calling > > > >> release. So the expected order should be: > > > >> > > > >> dmaengine_terminate_all(); > > > >> dma_release_channel(); > > > > > > > > Agree this is the correct way and in this case patch 3/3 in this series > > > > could be dropped. Then device_synchronize() would added to rcar-dmac, > > > > dmaengine_terminate_all() would turn of the IRQ and > > > > dma_release_channel() would ensure that device_synchronize() is called > > > > prior to calling rcar-dmac device_free_chan_resources(). > > > > > > > >> Terminate should then stop the channel, ie abort the pending > > > >> descriptors.. > > > > > > > > However for reasons unknown to me the rcar-dmac > > > > device_free_chan_resources() implementation implements logic to turn of > > > > IRQs before it frees the resources. And it's because of this patch 3/3 > > > > is needed so that it can be sure no ISR is running before it frees > > > > resources. > > > > > > > > I don't know how to best proceed here. I agree it feels a bit odd that > > > > device_free_chan_resources() is dealing with the IRQs as such things > > > > should be done before it's called. But on the other hand that code has > > > > been part of the driver since it was added upstream. I feel a bit > > > > uncomfortable just removing that part from the > > > > device_free_chan_resources() since the driver have been in use with it > > > > for such a long time. > > > > > > > > How would you prefer I try and resolve this? > > > > > > Perhaps Laurent knows why it was implemented this way? > > > > That was nearly 3 years ago, and I can hardly remember reasons related to > > code > > I wrote 3 months ago :-) > > > > I might just have been overcautious, guarding against conditions that > > should > > not happen if the caller behaves correctly. The situation might have > > changed > > since the driver was written. It might also be just a case of cargo-cult > > programming, as the shdma_free_chan_resources() has very similar code. > > Since the driver today have this behavior would it not be best to first > make sure it functions as expected and then as a second step see if we > can r
Re: [PATCH v5 6/6] ARM: shmobile: dts: Switch to panel-lvds bindings for Mitsubishi panels
On Sun, May 14, 2017 at 1:16 AM, Laurent Pinchart
wrote:
> The aa104xd12 and aa121td01 panels are LVDS panels, not DPI panels.
> Use the correct DT bindings.
>
> Signed-off-by: Laurent Pinchart
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v5 5/6] arm64: dts: renesas: r8a7795-salvator-x: Enable HDMI outputs
On Sun, May 14, 2017 at 1:16 AM, Laurent Pinchart
wrote:
> From: Koji Matsuoka
>
> Enable the HDMI encoders for the H3 Salvator-X board. The number of
> encoders varies between the H3 and M3-W SoCs, so they can't be enabled
> in the common salvator-x.dtsi file.
>
> Signed-off-by: Koji Matsuoka
> Signed-off-by: Ulrich Hecht
> Signed-off-by: Laurent Pinchart
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v5 4/6] arm64: dts: renesas: r8a7795-salvator-x: Add DU external dot clocks
On Sun, May 14, 2017 at 1:16 AM, Laurent Pinchart
wrote:
> The DU1 and DU2 external dot clocks are provided by the fixed frequency
> clock generators X21 and X22, while the DU0 and DU3 clocks are provided
> by the programmable Versaclock5 clock generator.
>
> Signed-off-by: Laurent Pinchart
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v5 3/6] arm64: dts: renesas: salvator-x: Add HDMI output connectors
On Sun, May 14, 2017 at 1:16 AM, Laurent Pinchart
wrote:
> The Salvator-X board has two HDMI output connectors. Add them to the
> common salvator-x.dtsi.
>
> Signed-off-by: Laurent Pinchart
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v5 2/6] arm64: dts: renesas: salvator-x: Add DU external dot clock sources
On Sun, May 14, 2017 at 1:16 AM, Laurent Pinchart
wrote:
> The DU1 and DU2 external dot clocks are fixed frequency clock generators
> running at 33MHz, while the DU0 and DU3 external dot clocks are
> generated by an I2C-controlled programmable clock generator.
>
> All those clock generators are available on both the H3 and M3-W
> Salvator-X boards. Add them to the salvator-x.dtsi file.
>
> Signed-off-by: Laurent Pinchart
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v5 1/6] arm64: dts: renesas: r8a7795: Add HDMI encoder support
On Sun, May 14, 2017 at 1:16 AM, Laurent Pinchart
wrote:
> From: Ulrich Hecht
>
> Add DT nodes for the two HDMI encoders in disabled state.
>
> Based on work by Koji Matsuoka.
>
> Signed-off-by: Ulrich Hecht
> Signed-off-by: Laurent Pinchart
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
