Re: [PATCH] clk: vc5: Add suspend/resume support
Hi Marek,
On Wednesday, 5 December 2018 14:29:22 EET Marek Vasut wrote:
> On 12/05/2018 06:21 AM, Laurent Pinchart wrote:
> > On Wednesday, 5 December 2018 01:48:01 EET Marek Vasut wrote:
> >> On 12/04/2018 09:52 PM, Stephen Boyd wrote:
> >>> Quoting Marek Vasut (2018-12-04 10:27:21)
> >>>
> >>>> diff --git a/drivers/clk/clk-versaclock5.c
> >>>> b/drivers/clk/clk-versaclock5.c
> >>>> index decffb3826ec..ac90fb36af1a 100644
> >>>> --- a/drivers/clk/clk-versaclock5.c
> >>>> +++ b/drivers/clk/clk-versaclock5.c
> >>>> @@ -906,6 +906,39 @@ static int vc5_remove(struct i2c_client *client)
> >>>> return 0;
> >>>> }
> >>>>
> >>>> +#ifdef CONFIG_PM_SLEEP
> >>>> +static int vc5_suspend(struct device *dev)
> >>>
> >>> Please mark as __maybe_unused and drop the #ifdef CONFIG_PM_SLEEP
> >>>
> >>>> +{
> >>>> + struct vc5_driver_data *vc5 = dev_get_drvdata(dev);
> >>>> + int ret;
> >>>> +
> >>>> + ret = regcache_sync(vc5->regmap);
> >>>> + if (ret != 0) {
> >>>> + dev_err(dev, "Failed to save register map: %d\n", ret);
> >>>> + return ret;
> >>>
> >>> Do we need to block suspend if we can't save the register map away? Or
> >>> can we just throw up our hands and not restore on resume?
> >>
> >> Some hardware will fail on resume, so I'd say -- yes ?
> >
> > But why do you need to sync on suspend in the first place ? What could
> > cause the map to be dirty at this stage, and require syncing before
> > suspend, that couldn't work with the sync be delayed to resume time ?
>
> Possibly a configuration coming from eg. bootloader time , or some other
> configuration not done by Linux.
I still don't get it. As far as I know, regcache_sync() will write the content
of the regmap to the hardware, not the other way around. You call it at resume
time, so the hardware should be programmed properly, regardless of what the
boot loader or the firmware does when resuming.
Could you please explain why this is needed at suspend time ?
--
Regards,
Laurent Pinchart
Re: [PATCH 1/2] ARM: dts: stout: Convert to new LVDS DT bindings
Hi Marek,
On Wednesday, 5 December 2018 03:10:18 EET Marek Vasut wrote:
> On 12/03/2018 11:48 PM, Laurent Pinchart wrote:
> > On Tuesday, 4 December 2018 00:24:32 EET Marek Vasut wrote:
> >> On 12/03/2018 10:48 PM, Laurent Pinchart wrote:
> >>> On Monday, 3 December 2018 17:12:41 EET Geert Uytterhoeven wrote:
> >>>> As of commit 6d2ca85279becdff ("dt-bindings: display: renesas:
> >>>> Deprecate LVDS support in the DU bindings"), the internal LVDS encoder
> >>>> has DT bindings separate from the DU. The Lager device tree was ported
> >>>> over to the new model, but the Stout device tree was forgotten.
> >>>>
> >>>> Fixes: 15a1ff30d8f9bd83 ("ARM: dts: r8a7790: Convert to new LVDS DT
> >>>> bindings") Signed-off-by: Geert Uytterhoeven
> >>>> ---
> >>>> Compile-tested only.
> >>>
> >>> I can't test the patch either but it looks fine to me.
> >>>
> >>> Reviewed-by: Laurent Pinchart
> >>>
> >>> I assume you will send this directly to Simon, so I don't plan to take
> >>> the patch in my tree.
> >>
> >> I have a Stout if you need me to test something.
> >
> > Could you test HDMI output ? We just need to ensure that everything is
> > probed correctly, so display anything on the HDMI output will do.
>
> Sure, can you push me a branch somewhere, so I don't have to hunt down
> patches ?
Only this patch should be needed. You can get it from https://
patchwork.kernel.org/patch/10709781/ and apply it on top of v4.19. Please
don't use v4.20-rc is there's one missing regression fix there (it has been
merged in the media tree and should make it to the final release).
--
Regards,
Laurent Pinchart
Re: [PATCH] clk: vc5: Add suspend/resume support
Hi Marek,
On Wednesday, 5 December 2018 01:48:01 EET Marek Vasut wrote:
> On 12/04/2018 09:52 PM, Stephen Boyd wrote:
> > Quoting Marek Vasut (2018-12-04 10:27:21)
> >
> >> diff --git a/drivers/clk/clk-versaclock5.c
> >> b/drivers/clk/clk-versaclock5.c
> >> index decffb3826ec..ac90fb36af1a 100644
> >> --- a/drivers/clk/clk-versaclock5.c
> >> +++ b/drivers/clk/clk-versaclock5.c
> >> @@ -906,6 +906,39 @@ static int vc5_remove(struct i2c_client *client)
> >>
> >> return 0;
> >>
> >> }
> >>
> >> +#ifdef CONFIG_PM_SLEEP
> >> +static int vc5_suspend(struct device *dev)
> >
> > Please mark as __maybe_unused and drop the #ifdef CONFIG_PM_SLEEP
> >
> >> +{
> >> + struct vc5_driver_data *vc5 = dev_get_drvdata(dev);
> >> + int ret;
> >> +
> >> + ret = regcache_sync(vc5->regmap);
> >> + if (ret != 0) {
> >> + dev_err(dev, "Failed to save register map: %d\n", ret);
> >> + return ret;
> >
> > Do we need to block suspend if we can't save the register map away? Or
> > can we just throw up our hands and not restore on resume?
>
> Some hardware will fail on resume, so I'd say -- yes ?
But why do you need to sync on suspend in the first place ? What could cause
the map to be dirty at this stage, and require syncing before suspend, that
couldn't work with the sync be delayed to resume time ?
> The rest is fixed.
>
> >> + }
> >> + regcache_cache_only(vc5->regmap, true);
> >> + regcache_mark_dirty(vc5->regmap);
> >> +
> >> + return 0;
> >> +}
> >> +
> >> +static int vc5_resume(struct device *dev)
> >> +{
> >> + struct vc5_driver_data *vc5 = dev_get_drvdata(dev);
> >> + int ret;
> >> +
> >> + regcache_cache_only(vc5->regmap, false);
> >> + ret = regcache_sync(vc5->regmap);
> >> + if (ret != 0) {
> >> + dev_err(dev, "Failed to restore register map: %d\n",
> >> ret);
> >> + return ret;
> >> + }
> >
> > Simplify to
> >
> > if (ret)
> >
> > dev_err()
> >
> > retun ret;
> >
> >> +
> >> + return 0;
> >> +}
> >> +#endif
> >> +
> >>
> >> static const struct vc5_chip_info idt_5p49v5923_info = {
> >>
> >> .model = IDT_VC5_5P49V5923,
> >> .clk_fod_cnt = 2,
--
Regards,
Laurent Pinchart
Re: [PATCH 1/2] ARM: dts: stout: Convert to new LVDS DT bindings
Hi Marek,
On Tuesday, 4 December 2018 00:24:32 EET Marek Vasut wrote:
> On 12/03/2018 10:48 PM, Laurent Pinchart wrote:
> > On Monday, 3 December 2018 17:12:41 EET Geert Uytterhoeven wrote:
> >> As of commit 6d2ca85279becdff ("dt-bindings: display: renesas: Deprecate
> >> LVDS support in the DU bindings"), the internal LVDS encoder has DT
> >> bindings separate from the DU. The Lager device tree was ported over to
> >> the new model, but the Stout device tree was forgotten.
> >>
> >> Fixes: 15a1ff30d8f9bd83 ("ARM: dts: r8a7790: Convert to new LVDS DT
> >> bindings") Signed-off-by: Geert Uytterhoeven
> >> ---
> >> Compile-tested only.
> >
> > I can't test the patch either but it looks fine to me.
> >
> > Reviewed-by: Laurent Pinchart
> >
> > I assume you will send this directly to Simon, so I don't plan to take the
> > patch in my tree.
>
> I have a Stout if you need me to test something.
Could you test HDMI output ? We just need to ensure that everything is probed
correctly, so display anything on the HDMI output will do.
--
Regards,
Laurent Pinchart
Re: [PATCH 2/2] arm64: dts: renesas: r8a7796: salvator-xs: Convert to new LVDS DT bindings
Hi Geert,
Thank you for the patch.
On Monday, 3 December 2018 17:12:42 EET Geert Uytterhoeven wrote:
> As of commit 6d2ca85279becdff ("dt-bindings: display: renesas: Deprecate
> LVDS support in the DU bindings"), the internal LVDS encoder has DT
> bindings separate from the DU. The device trees for all R-Car H3 and
> M3-W development boards were ported over to the new model, but
> Salvator-XS boards equipped with an R-Car M3-W SoC were forgotten.
>
> Fixes: 58e8ed2ee9abe718 ("arm64: dts: renesas: Convert to new LVDS DT
> bindings") Signed-off-by: Geert Uytterhoeven
> ---
> Compile-tested only.
I can't test the patch either but it looks fine to me.
Reviewed-by: Laurent Pinchart
I assume you will send this directly to Simon, so I don't plan to take the
patch in my tree.
> ---
> arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dts | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dts
> b/arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dts index
> 8860be65342e4f38..31f12059355ee02b 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dts
> @@ -29,11 +29,10 @@
> clocks = < CPG_MOD 724>,
>< CPG_MOD 723>,
>< CPG_MOD 722>,
> - < CPG_MOD 727>,
>< 1>,
><_clk>,
>< 2>;
> - clock-names = "du.0", "du.1", "du.2", "lvds.0",
> + clock-names = "du.0", "du.1", "du.2",
> "dclkin.0", "dclkin.1", "dclkin.2";
> };
--
Regards,
Laurent Pinchart
Re: [PATCH 1/2] ARM: dts: stout: Convert to new LVDS DT bindings
Hi Geert,
Thank you for the patch.
On Monday, 3 December 2018 17:12:41 EET Geert Uytterhoeven wrote:
> As of commit 6d2ca85279becdff ("dt-bindings: display: renesas: Deprecate
> LVDS support in the DU bindings"), the internal LVDS encoder has DT
> bindings separate from the DU. The Lager device tree was ported over to
> the new model, but the Stout device tree was forgotten.
>
> Fixes: 15a1ff30d8f9bd83 ("ARM: dts: r8a7790: Convert to new LVDS DT
> bindings") Signed-off-by: Geert Uytterhoeven
> ---
> Compile-tested only.
I can't test the patch either but it looks fine to me.
Reviewed-by: Laurent Pinchart
I assume you will send this directly to Simon, so I don't plan to take the
patch in my tree.
> ---
> arch/arm/boot/dts/r8a7790-stout.dts | 15 ---
> 1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/boot/dts/r8a7790-stout.dts
> b/arch/arm/boot/dts/r8a7790-stout.dts index
> 629da4cee1b971d6..7a7d3b84d1a6b21d 100644
> --- a/arch/arm/boot/dts/r8a7790-stout.dts
> +++ b/arch/arm/boot/dts/r8a7790-stout.dts
> @@ -94,9 +94,8 @@
> status = "okay";
>
> clocks = < CPG_MOD 724>, < CPG_MOD 723>, < CPG_MOD 722>,
> - < CPG_MOD 726>, < CPG_MOD 725>,
><_clk>;
> - clock-names = "du.0", "du.1", "du.2", "lvds.0", "lvds.1", "dclkin.0";
> + clock-names = "du.0", "du.1", "du.2", "dclkin.0";
>
> ports {
> port@0 {
> @@ -104,11 +103,21 @@
> remote-endpoint = <_in>;
> };
> };
> + };
> +};
> +
> + {
> + ports {
> port@1 {
> lvds_connector0: endpoint {
> };
> };
> - port@2 {
> + };
> +};
> +
> + {
> + ports {
> + port@1 {
> lvds_connector1: endpoint {
> };
> };
--
Regards,
Laurent Pinchart
Re: Issue with enabling VSP source on rcar gen2 koelsch board
Hi Biju, On Thursday, 29 November 2018 10:39:00 EET Biju Das wrote: > > Subject: Re: Issue with enabling VSP source on rcar gen2 koelsch board > > On Wednesday, 28 November 2018 15:20:58 EET Biju Das wrote: > >> Hi all, > >> > >> On the past, I have tested vsp source on rcar gen2 koelsch board, > >> using the patches series below(Apart from the below patch series, I > >> have enabled "CONFIG_DRM_RCAR_VSP=y") > >> https://git.linuxtv.org/pinchartl/media.git/log/?h=drm/du/panels > >> > >> 1) [HACK] ARM: shmobile: r8a7791: Link the VSP1 and DU > >> 2) [HACK] v4l: vsp1: Disable UAPI for VSP1D > >> 3) [HACK] drm: rcar-du: Enable VSP source support for R8A7791 > >> > >> But on the latest renesas-dev branch looks like it is broken > > > > That doesn't surprise me too much as I don't actively maintain that code. > > > > For my information, what are your use cases ? Do you think this approach > > should be pursued and patches merged upstream ? The amount of work will > > be quite high though, given that it introduces a new userspace API, we > > will have to publish an open-source implementation in an X.org or Wayland > > driver. > > Basically as part of RZ-G1/M VSP upstreaming(Linux 4.15 kernel) ,previously > I have executed the below test cases > > 1) vsp test suite:- based on the instruction present on > "http://git.ideasonboard.com/renesas/vsp-tests.git; > > 2) vspd testing:- based on the instruction present on > "https://git.linuxtv.org/pinchartl/media.git/log/?h=drm/du/panels; > > Both the test cases were working fine with 4.15 kernel. > > Now as part of RZ/G1N vsp upstreaming, I rebased to latest branch from > renesas-dev , and executed the same test case > > Only test cases in vsp test suite is working. the vspd test case is broken. Could you please post the tests output and log ? > So I am wondering how do we expose the r-car gen2 SoC feature "VSPD" to > the end user? Isn't the VSPD already exposed to the user as a V4L2 device on Gen2 ? -- Regards, Laurent Pinchart
Re: [PATCH 00/13] clk: renesas: Miscellaneous fixes
Hi Geert, On Thursday, 29 November 2018 12:49:55 EET Geert Uytterhoeven wrote: > Hi Mike, Stephen, Laurent, Kieran, > > This patch series contains several fixes for the Renesas Clock drivers > and DT bindings, and a small simplification: > - Removal of non-existent clocks, > - Addition of the CPEX clocks, which can be used a source for a timer > (CMT1), > - Correction of DU parent clocks. > Most of these have been found by skimming the Hardware Manual Errata. > > This has been boot-tested on Salvator-X(S) (R-Car H3, M3-W, M3-N), Eagle > (R-Car V3M), and Draak (R-Car D3), except for the DU parts. > Testing of the DU on R-Car D3 and E3 would be appreciated, as the DU > driver may have a workaround for the incorrect parent clock rates. As explained in my review of 09/13, I believe the DU clock patches to both be correct and have no effect for D3 and E3. No action is needed on the DU side, there is no workaround for the incorrect frequency. > I intend to queue this in clk-renesas-for-v4.21. > > Thanks! > > Geert Uytterhoeven (12): > dt-bindings: clock: r8a7795: Remove CSIREF clock > dt-bindings: clock: r8a7796: Remove CSIREF clock > clk: renesas: r8a774a1: Add CPEX clock > clk: renesas: r8a7795: Add CPEX clock > clk: renesas: r8a7796: Add CPEX clock > clk: renesas: r8a77965: Add CPEX clock > clk: renesas: r8a77970: Add CPEX clock > clk: renesas: r8a77995: Correct parent clock of DU > clk: renesas: r8a77995: Remove non-existent VIN5-7 module clocks > clk: renesas: r8a77995: Remove non-existent SSP clocks > clk: renesas: r8a77995: Add missing CPEX clock > clk: renesas: r8a77995: Simplify PLL3 multiplier/divider > > Takeshi Kihara (1): > clk: renesas: r8a77990: Correct parent clock of DU > > drivers/clk/renesas/r8a774a1-cpg-mssr.c | 1 + > drivers/clk/renesas/r8a7795-cpg-mssr.c| 1 + > drivers/clk/renesas/r8a7796-cpg-mssr.c| 1 + > drivers/clk/renesas/r8a77965-cpg-mssr.c | 1 + > drivers/clk/renesas/r8a77970-cpg-mssr.c | 1 + > drivers/clk/renesas/r8a77990-cpg-mssr.c | 4 ++-- > drivers/clk/renesas/r8a77995-cpg-mssr.c | 15 ++- > include/dt-bindings/clock/r8a7795-cpg-mssr.h | 2 +- > include/dt-bindings/clock/r8a7796-cpg-mssr.h | 2 +- > include/dt-bindings/clock/r8a77995-cpg-mssr.h | 5 +++-- > 10 files changed, 18 insertions(+), 15 deletions(-) -- Regards, Laurent Pinchart
Re: [PATCH 09/13] clk: renesas: r8a77995: Correct parent clock of DU
Hi Geert,
Thank you for the patch.
On Thursday, 29 November 2018 12:50:04 EET Geert Uytterhoeven wrote:
> According to the R-Car Gen3 Hardware Manual Rev 1.00, the parent clock
> of the DU module clocks on R-Car D3 is S1D1.
>
> Fixes: d71e851d82c6cfe5 ("clk: renesas: cpg-mssr: Add R8A77995 support")
> Signed-off-by: Geert Uytterhoeven
Reviewed-by: Laurent Pinchart
The patch has no effect on the DU operation as the rcar-du driver hardcodes a
different clock source for the dot clock. However, after hacking the driver to
hardcode usage of this clock, operation off the LVDS output is improved. I
thus believe this change to be correct in addition to not having any effect
with the current mainline code :-)
Tested-by: Laurent Pinchart
> ---
> drivers/clk/renesas/r8a77995-cpg-mssr.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/clk/renesas/r8a77995-cpg-mssr.c
> b/drivers/clk/renesas/r8a77995-cpg-mssr.c index
> 47e60e3dbe05ff18..ad95dc225e9c039a 100644
> --- a/drivers/clk/renesas/r8a77995-cpg-mssr.c
> +++ b/drivers/clk/renesas/r8a77995-cpg-mssr.c
> @@ -146,8 +146,8 @@ static const struct mssr_mod_clk r8a77995_mod_clks[]
> __initconst = { DEF_MOD("vspbs", 627, R8A77995_CLK_S0D1),
> DEF_MOD("ehci0", 703, R8A77995_CLK_S3D2),
> DEF_MOD("hsusb", 704, R8A77995_CLK_S3D2),
> - DEF_MOD("du1", 723, R8A77995_CLK_S2D1),
> - DEF_MOD("du0", 724, R8A77995_CLK_S2D1),
> + DEF_MOD("du1", 723, R8A77995_CLK_S1D1),
> + DEF_MOD("du0", 724, R8A77995_CLK_S1D1),
> DEF_MOD("lvds", 727, R8A77995_CLK_S2D1),
> DEF_MOD("vin7", 804, R8A77995_CLK_S1D2),
> DEF_MOD("vin6", 805, R8A77995_CLK_S1D2),
--
Regards,
Laurent Pinchart
Re: [PATCH 08/13] clk: renesas: r8a77990: Correct parent clock of DU
Hi Geert,
Thank you for the patch.
On Thursday, 29 November 2018 12:50:03 EET Geert Uytterhoeven wrote:
> From: Takeshi Kihara
>
> According to the R-Car Gen3 Hardware Manual Rev 1.00, the parent clock
> of the DU module clocks on R-Car E3 is S1D1.
>
> Signed-off-by: Takeshi Kihara
> Fixes: 3570a2af473789c5 ("clk: renesas: cpg-mssr: Add support for R-Car E3")
> Signed-off-by: Geert Uytterhoeven
Reviewed-by: Laurent Pinchart
> ---
> drivers/clk/renesas/r8a77990-cpg-mssr.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/clk/renesas/r8a77990-cpg-mssr.c
> b/drivers/clk/renesas/r8a77990-cpg-mssr.c index
> 9eb80180eea0b1a6..9a278c75c918cfa8 100644
> --- a/drivers/clk/renesas/r8a77990-cpg-mssr.c
> +++ b/drivers/clk/renesas/r8a77990-cpg-mssr.c
> @@ -183,8 +183,8 @@ static const struct mssr_mod_clk r8a77990_mod_clks[]
> __initconst = { DEF_MOD("ehci0", 703, R8A77990_CLK_S3D4),
> DEF_MOD("hsusb", 704, R8A77990_CLK_S3D4),
> DEF_MOD("csi40", 716, R8A77990_CLK_CSI0),
> - DEF_MOD("du1", 723, R8A77990_CLK_S2D1),
> - DEF_MOD("du0", 724, R8A77990_CLK_S2D1),
> + DEF_MOD("du1", 723, R8A77990_CLK_S1D1),
> + DEF_MOD("du0", 724, R8A77990_CLK_S1D1),
> DEF_MOD("lvds", 727, R8A77990_CLK_S2D1),
>
> DEF_MOD("vin5", 806, R8A77990_CLK_S1D2),
--
Regards,
Laurent Pinchart
Re: Issue with enabling VSP source on rcar gen2 koelsch board
Hi Biju, On Wednesday, 28 November 2018 15:20:58 EET Biju Das wrote: > Hi all, > > On the past, I have tested vsp source on rcar gen2 koelsch board, using the > patches series below(Apart from the below patch series, I have enabled > "CONFIG_DRM_RCAR_VSP=y") > https://git.linuxtv.org/pinchartl/media.git/log/?h=drm/du/panels > > 1) [HACK] ARM: shmobile: r8a7791: Link the VSP1 and DU > 2) [HACK] v4l: vsp1: Disable UAPI for VSP1D > 3) [HACK] drm: rcar-du: Enable VSP source support for R8A7791 > > But on the latest renesas-dev branch looks like it is broken That doesn't surprise me too much as I don't actively maintain that code. For my information, what are your use cases ? Do you think this approach should be pursued and patches merged upstream ? The amount of work will be quite high though, given that it introduces a new userspace API, we will have to publish an open-source implementation in an X.org or Wayland driver. > The issue is kernel doesn't boot, if I connect display panel. Looks like it > is hanging in register_framebuffer. > > [5.344412] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > [5.364250] [drm] No driver support for vblank timestamp query. > > Have any one noticed this issue? This usually means that the kernel crashes with the console lock taken, preventing the oops from being printed. As a debugging hack you can comment out the locking calls in console_lock(), console_trylock() and console_unlock() (kernel/printk/printk.c). -- Regards, Laurent Pinchart
Re: [PATCH] drm: rcar-du: Re-update the DSYSR register value for start/stop
Hello Hoan, On Tuesday, 23 October 2018 04:01:19 EET Hoan wrote: > On 2018/10/22 20:23, Laurent Pinchart wrote: > > On Monday, 22 October 2018 09:30:54 EEST Nguyen An Hoan wrote: > >> From: Hoan Nguyen An > >> > >> From previous commit 0521ccb "drm: rcar-du: Cache DSYSR value to ensure > >> > >> known initial value" > > > > What exact commit are you referring to ? The mainline commit that has this > > subject is 9144adc5e5a99577bce0d4ee2ca3615f53b9d296. > > Seems I have cited the wrong Commit-ID、it is > > 9144adc5e5a99577bce0d4ee2ca3615f53b9d296 > drm: rcar-du: Cache DSYSR value to ensure known initial value > > >> We only need to update DSYSR0, DSYSR2 for start/stop. > >> So using rgrp-> mmio_offset is enough, the change back from rcar_du_crtc > >> ->rcar_du_group -> rcar_du_crtc leading to mmio addresses for DSYSR may > >> be different. > > > > Is this fixing an actual problem ? If you look at the code, the line > > > > struct rcar_du_crtc *rcrtc = >dev->crtcs[rgrp->index * 2]; > > > > makes sure that we select DU0 or DU2 only, so the register write > > > > rcar_du_crtc_dsysr_clr_set(rcrtc, DSYSR_DRES | DSYSR_DEN, > >start ? DSYSR_DEN : DSYSR_DRES); > > > > should only access DSYSR0 and DSYSR2. > > This seems I think to fix the rcar-du problem with M3N-r8a77965, > > With M3N-R8a77965 we have DU0, DU1, DU3 > So, when Laurent-san divide objetcs into rcar_du_group, rcar_du_crtc. > > DU0, DU1 -> du_group[0] rgrp-> mmio_offset = DU0_REG_OFFSET > DU3->du_group[1] and rgrp-> mmio_offset = DU2_REG_OFFSET, but > rcrtc->mmio_offset=DU3_REG_OFFSET (with M3N) > > M3N-R8a77965 not have DU2, So after the command: > > struct rcar_du_crtc *rcrtc = >dev->crtcs[rgrp->index * 2]; > > So in fact, with M3N we are updating DSYSR3 (In this my TC, this > reference to start/stop DU3-RGB) > > This will not affect H3, since the H3 lines always have enough DU0, > DU1,DU2,DU3. You're absolutely right. I'm sorry for introducing the bug in the first place, and for failing to understand your patch. I would however prefer a different fix, as switching back to rcar_du_group_write() defeats the purpose of the "drm: rcar-du: Cache DSYSR value to ensure known initial value" patch. I will submit a patch and CC you. -- Regards, Laurent Pinchart
Re: [PATCH] drm: rcar-du: fix probe error when DRM_RCAR_DW_HDMI disabled
Hello Hoan,
Thank you for the patch.
On Friday, 21 September 2018 14:49:03 EET Nguyen An Hoan wrote:
> From: Hoan Nguyen An
>
> Skip return EPROBE_DEFER when DRM_RCAR_DW_HDMI is disabled in case HDMI
> initialize. At this time, the rcar-du driver not be able to successfully
> initialize if disable DRM_RCAR_DW_HDMI (rcar_du_probe return error),
> so can not use other features such as RGB Analog, this patch to fix.
>
> Signed-off-by: Hoan Nguyen An
> ---
> drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c index f9c933d..4dbc508 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> @@ -66,8 +66,15 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
> /* Locate the DRM bridge from the encoder DT node. */
> bridge = of_drm_find_bridge(enc_node);
> if (!bridge) {
> +#if IS_ENABLED(CONFIG_DRM_RCAR_DW_HDMI)
> ret = -EPROBE_DEFER;
> goto done;
> +#else
> + if (output == RCAR_DU_OUTPUT_HDMI0 ||
> + output == RCAR_DU_OUTPUT_HDMI1)
> + ret = 0;
> + goto done;
> +#endif
The dw-hdmi driver could be compiled out of tree, I don't think is the right
fix. If the HDMI output should be disabled on a particular system, the
corresponding DT node should be marked as disable, and no change to the DU
driver is needed. Otherwise the necessary drivers should be present.
In the long term we should implement support for registration of additional
encoders at runtime, but that's way down the road.
> }
>
> ret = drm_encoder_init(rcdu->ddev, encoder, _funcs,
--
Regards,
Laurent Pinchart
Re: HDMI doesn't work on ULCB board
Hi Morimoto-san, On Monday, 12 November 2018 05:09:13 EET Kuninori Morimoto wrote: > Hi Laurent > > >> I noticed Salvator can't boot if .config has CONFIG_COMMON_CLK_VC5. > >> This means, Salvator and ULCB can't use same binary so far for me > >> (= all modules are =y on .config). > >> I'm using previous attached .config + your patch + CONFIG_COMMON_CLK_VC5 > > (snip) > > > I'm afraid I can't reproduce this. I checked out > > renesas-drivers-2018-10-09- v4.19-rc7, applied the fix I've submitted, > > took your configuration, enabled CONFIG_COMMON_CLK_VC5, and my > > Salvator-XS H3 boots fine. > > I'm deeply sorry, it was my fault. > I'm using ES1.x board, but I used XS dtb I've done worse mistakes, and many times, so I can't blame you :-) I'm glad it works now. -- Regards, Laurent Pinchart
Re: HDMI doesn't work on ULCB board
Hi Morimoto-san, On Friday, 9 November 2018 04:23:36 EET Kuninori Morimoto wrote: > Hi Laurent > > >>> I tried to reproduce the problem, starting with drm-next which seems > >>> to work fine, moving to renesas-drivers-2018-10-09-v4.19-rc7 which > >>> also didn't exhibit any issue. I then used your kernel configuration, > >>> and got a WARN_ON \o/ > >> > >> Investigations revealed that you're missing the CONFIG_COMMON_CLK_VC5=y > >> option in your kernel configuration. It also revealed a bug in the > >> error handling code of the DU driver, for which I have just sent > >> "[PATCH] drm: rcar-du: Fix external clock error checks". > > > > Thanks !! > > I tried your posted patch, and it solved Oops issue, > > and CONFIG_COMMON_CLK_VC5 solved HDMI outputs !! > > Hmm... > > I noticed Salvator can't boot if .config has CONFIG_COMMON_CLK_VC5. > This means, Salvator and ULCB can't use same binary so far for me > (= all modules are =y on .config). > I'm using previous attached .config + your patch + CONFIG_COMMON_CLK_VC5 > > Kernel will stop here on Salvator > > - > > rcar-fcp fe9af000.fcp: ignoring dependency for device, assuming no driver > rcar-fcp fe9bf000.fcp: ignoring dependency for device, assuming no driver > rcar-fcp fea27000.fcp: ignoring dependency for device, assuming no driver > rcar-fcp fea2f000.fcp: ignoring dependency for device, assuming no driver > rcar-fcp fea37000.fcp: ignoring dependency for device, assuming no driver > [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > [drm] No driver support for vblank timestamp query. > > ** stop here ** I'm afraid I can't reproduce this. I checked out renesas-drivers-2018-10-09- v4.19-rc7, applied the fix I've submitted, took your configuration, enabled CONFIG_COMMON_CLK_VC5, and my Salvator-XS H3 boots fine. -- Regards, Laurent Pinchart
Re: [PATCH v2] arm64: dts: renesas: r8a77990: Fix VIN endpoint numbering
Hi Simon,
On Tuesday, 6 November 2018 16:00:35 EET Simon Horman wrote:
> On Mon, Nov 05, 2018 at 02:12:43PM +0100, Jacopo Mondi wrote:
> > The VIN driver bindings dictates fixed numbering for VIN endpoints
> > connected to CSI-2 endpoints, even when a single endpoint exists.
> >
> > Without proper endpoint numbering the VIN driver fails to probe.
> >
> > Based on a patch in BSP from Koji Matsuoka
> >
> > Fixes: ec70407ae7d7 ("arm64: dts: renesas: r8a77990: Add VIN and CSI-2
> > device nodes") Signed-off-by: Koji Matsuoka
> >
> > Signed-off-by: Takeshi Kihara
> > Signed-off-by: Jacopo Mondi
> > Reviewed-by: Laurent Pinchart
>
> Thanks,
>
> This looks fine to me but I will wait to see if there are other reviews
> before applying.
>
> Reviewed-by: Simon Horman
I think you can go ahead and apply it.
--
Regards,
Laurent Pinchart
Re: HDMI doesn't work on ULCB board
Hi Morimoto-san, On Tuesday, 6 November 2018 16:30:35 EET Laurent Pinchart wrote: > On Thursday, 18 October 2018 05:12:14 EET Kuninori Morimoto wrote: > > Hi Vladimir, Laurent > > > > I'm testing ULCB board, and I noticed that HDMI doen't work on it. > > > > - Sometimes kernel panic happen (I lost log, but it said "get crc" > > > > something error), - Often, kernel doesn't boot with below log if I > > connected HDMI cable when booting > > > > - Monitor say "No signal" if I connected cable *after* booting > > > > I'm using Geert's renesas-drivers-2018-10-09-v4.19-rc7 branch. > > It seems salvator HDMI is working correctly on it. > > I attached my .config > > I tried to reproduce the problem, starting with drm-next which seems to work > fine, moving to renesas-drivers-2018-10-09-v4.19-rc7 which also didn't > exhibit any issue. I then used your kernel configuration, and got a WARN_ON > \o/ Investigations revealed that you're missing the CONFIG_COMMON_CLK_VC5=y option in your kernel configuration. It also revealed a bug in the error handling code of the DU driver, for which I have just sent "[PATCH] drm: rcar-du: Fix external clock error checks". -- Regards, Laurent Pinchart
Re: HDMI doesn't work on ULCB board
Hi Morimoto-san, On Thursday, 18 October 2018 05:12:14 EET Kuninori Morimoto wrote: > Hi Vladimir, Laurent > > I'm testing ULCB board, and I noticed that HDMI doen't work on it. > > - Sometimes kernel panic happen (I lost log, but it said "get crc" > something error), - Often, kernel doesn't boot with below log if I > connected HDMI cable when booting > - Monitor say "No signal" if I connected cable *after* booting > > I'm using Geert's renesas-drivers-2018-10-09-v4.19-rc7 branch. > It seems salvator HDMI is working correctly on it. > I attached my .config I tried to reproduce the problem, starting with drm-next which seems to work fine, moving to renesas-drivers-2018-10-09-v4.19-rc7 which also didn't exhibit any issue. I then used your kernel configuration, and got a WARN_ON \o/ [1.805110] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [1.811758] [drm] No driver support for vblank timestamp query. [1.878688] WARNING: CPU: 1 PID: 62 at /home/laurent/src/iob/renesas/linux/ drivers/gpu/drm/rcar-du/rcar_du_crtc.c:229 rcar_du_crtc_get+0x604/0x628 [1.878712] CPU: 1 PID: 62 Comm: kworker/1:1 Not tainted 4.19.0-rc7 #2820 [1.878716] Hardware name: Renesas H3ULCB Kingfisher board based on r8a7795 ES2.0+ (DT) [1.878725] Workqueue: events deferred_probe_work_func [1.878734] pstate: 0005 (nzcv daif -PAN -UAO) [1.878739] pc : rcar_du_crtc_get+0x604/0x628 [1.878743] lr : rcar_du_crtc_get+0xa8/0x628 [1.878747] sp : 0a12b330 [1.878750] x29: 0a12b330 x28: [1.878759] x27: 0004 x26: 8006f90fc000 [1.878768] x25: 8006f9de3ad8 x24: 0001 [1.878776] x23: 0001 x22: 06590fa0 [1.878784] x21: 8006f9026818 x20: 08a6e000 [1.878792] x19: 8006f9610770 x18: 1ef4 [1.878799] x17: x16: 8006faee5900 [1.878807] x15: 1eeb x14: 096a9000 [1.878815] x13: 1ef6 x12: 1eeb [1.878823] x11: 8006faee60e0 x10: 08ab5000 [1.878831] x9 : 098ad000 x8 : 8006faee5900 [1.878839] x7 : 08b1a000 x6 : 08b1a308 [1.878847] x5 : 0002 x4 : 0006 [1.878855] x3 : 087d7670 x2 : 8006f9610018 [1.878862] x1 : x0 : 8006f9611cf0 [1.878871] Call trace: [1.878876] rcar_du_crtc_get+0x604/0x628 [1.878880] rcar_du_crtc_atomic_begin+0x2c/0x60 [1.878890] drm_atomic_helper_commit_planes+0x84/0x218 [1.878895] rcar_du_atomic_commit_tail+0x38/0x70 [1.878900] commit_tail+0x4c/0x80 [1.878904] drm_atomic_helper_commit+0xfc/0x178 [1.878911] drm_atomic_commit+0x54/0x60 [1.878918] restore_fbdev_mode_atomic+0x180/0x1f0 [1.878922] restore_fbdev_mode+0x58/0x198 [1.878927] drm_fb_helper_restore_fbdev_mode_unlocked+0x80/0xd8 [1.878932] drm_fb_helper_set_par+0x34/0x68 [1.878939] fbcon_init+0x504/0x558 [1.878945] visual_init+0xa0/0xf0 [1.878950] do_bind_con_driver+0x160/0x338 [1.878955] do_take_over_console+0x128/0x1a8 [1.878959] do_fbcon_takeover+0x80/0x108 [1.878964] fbcon_event_notify+0x9ac/0x9d8 [1.878971] notifier_call_chain+0x5c/0x98 [1.878975] __blocking_notifier_call_chain+0x58/0xa0 [1.878979] blocking_notifier_call_chain+0x3c/0x50 [1.878983] fb_notifier_call_chain+0x30/0x40 [1.878987] register_framebuffer+0x288/0x330 [1.878992] __drm_fb_helper_initial_config_and_unlock+0x24c/0x410 [1.878996] drm_fb_helper_fbdev_setup+0xf0/0x210 [1.879000] drm_fbdev_cma_init+0xa4/0xf0 [1.879005] rcar_du_modeset_init+0x3b4/0x570 [1.879009] rcar_du_probe+0x134/0x210 [1.879016] platform_drv_probe+0x58/0xb8 [1.879020] really_probe+0x20c/0x2a0 [1.879024] driver_probe_device+0x60/0x108 [1.879028] __device_attach_driver+0x9c/0xe0 [1.879031] bus_for_each_drv+0x80/0xe0 [1.879035] __device_attach+0xf0/0x150 [1.879039] device_initial_probe+0x24/0x30 [1.879042] bus_probe_device+0xa0/0xa8 [1.879046] deferred_probe_work_func+0x78/0xb0 [1.879052] process_one_work+0x2c4/0x6c0 [1.879055] worker_thread+0x244/0x438 [1.879060] kthread+0x100/0x130 [1.879067] ret_from_fork+0x10/0x1c [1.879070] irq event stamp: 42150 [1.879080] hardirqs last enabled at (42149): [] _raw_spin_unlock_irqrestore+0x7c/0x88 [1.879086] hardirqs last disabled at (42150): [] do_debug_exception+0x17c/0x1b8 [1.879090] softirqs last enabled at (41936): [] __do_softirq+0x46c/0x51c [1.879097] softirqs last disabled at (41915): [] irq_exit+0x12c/0x138 [1.879100] ---[ end trace ec07bda5b9bd7ef1 ]--- I'm now investigating it. -- Regards, Laurent Pinchart
Re: [PATCH] arm64: dts: renesas: r8a77990: Fix VIN endpoint numbering
Hi Jacopo,
Thank you for the patch.
On Monday, 5 November 2018 13:49:21 EET Jacopo Mondi wrote:
> The VIN driver bindings dictates fixed numbering for VIN endpoints connected
> to CSI-2 endpoints, even when a single endpoint exists.
>
> Without proper endpoint numbering the VIN driver fails to probe.
>
> Fixes: ec70407ae7d7 ("arm64: dts: renesas: r8a77990: Add VIN and CSI-2
> device nodes") Signed-off-by: Koji Matsuoka
> Signed-off-by: Takeshi Kihara
> Signed-off-by: Jacopo Mondi
Reviewed-by: Laurent Pinchart
> ---
> arch/arm64/boot/dts/renesas/r8a77990.dtsi | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> b/arch/arm64/boot/dts/renesas/r8a77990.dtsi index 9509dc0..97f7e0c 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> @@ -747,7 +747,8 @@
> port@1 {
> reg = <1>;
>
> - vin4csi40: endpoint {
> + vin4csi40: endpoint@2 {
> + reg = <2>;
> remote-endpoint= <>;
> };
> };
> @@ -771,7 +772,8 @@
> port@1 {
> reg = <1>;
>
> - vin5csi40: endpoint {
> + vin5csi40: endpoint@2 {
> + reg = <2>;
> remote-endpoint= <>;
> };
> };
> --
> 2.7.4
--
Regards,
Laurent Pinchart
Re: [PATCH v2 6/8] arm64: dts: r8a77990: Add VIN and CSI-2 device nodes
Hi Jacopo,
On Tuesday, 30 October 2018 12:14:31 EET jacopo mondi wrote:
> On Mon, Sep 10, 2018 at 05:12:30PM +0300, Laurent Pinchart wrote:
> > On Wednesday, 5 September 2018 18:29:43 EEST Jacopo Mondi wrote:
> >> From: Koji Matsuoka
> >>
> >> Add device nodes for VIN4, VIN5 and CSI40 to R-Car E3 R8A77990 device
> >> tree.
> >>
> >> Signed-off-by: Koji Matsuoka
> >> Signed-off-by: Takeshi Kihara
> >> Signed-off-by: Jacopo Mondi
> >> ---
> >>
> >> arch/arm64/boot/dts/renesas/r8a77990.dtsi | 79
> >> 1 file changed, 79 insertions(+)
> >>
> >> diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> >> b/arch/arm64/boot/dts/renesas/r8a77990.dtsi index ae89260..0ae7bbe
> >> 100644
> >> --- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> >> +++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> >> @@ -337,6 +337,85 @@
> >>
> >>status = "disabled";
> >>
> >>};
> >>
> >> + csi40: csi2@feaa {
> >
> > I believe Simon would like to keep the nodes sorted by address
> >
> >> + compatible = "renesas,r8a77990-csi2",
> >> "renesas,rcar-gen3-csi2";
> >> + reg = <0 0xfeaa 0 0x1>;
> >
> > 0x1 seems pretty large to me.
>
> It seems to me that all Gen3 SoC have this lenght specified
>
> $git grep -A 10 'csi[2|4][0|1]: csi' arch/arm64/boot/dts/renesas/ | grep reg
> arch/arm64/boot/dts/renesas/r8a7795.dtsi-reg = <0 0xfea8 0 0x1>;
> arch/arm64/boot/dts/renesas/r8a7795.dtsi-reg = <0 0xfeaa 0 0x1>;
> arch/arm64/boot/dts/renesas/r8a7795.dtsi-reg = <0 0xfeab 0 0x1>;
> arch/arm64/boot/dts/renesas/r8a7796.dtsi-reg = <0 0xfea8 0 0x1>;
> arch/arm64/boot/dts/renesas/r8a7796.dtsi-reg = <0 0xfeaa 0 0x1>;
> arch/arm64/boot/dts/renesas/r8a77965.dtsi- reg = <0 0xfea8 0 0x1>;
> arch/arm64/boot/dts/renesas/r8a77965.dtsi- reg = <0 0xfeaa 0 0x1>;
> arch/arm64/boot/dts/renesas/r8a77970.dtsi- reg = <0 0xfeaa 0 0x1>;
> arch/arm64/boot/dts/renesas/r8a77980.dtsi- reg = <0 0xfeaa 0 0x1>;
> arch/arm64/boot/dts/renesas/r8a77980.dtsi- reg = <0 0xfeab 0 0x1>;
> arch/arm64/boot/dts/renesas/r8a77990.dtsi- reg = <0 0xfeaa 0 0x1>;
>
> Am I missing something?
Cargo-cult programming ? :-) This will likely not hurt, but such a large
memory area is not required, and we'll save a bit of memory if we reduce the
mapping from 64kB to 4kB (or less)
> > Apart from that,
>
> I will include the upporting of the following patch to fix the VIN
> endpoint numbering in forthcoming v3:
> https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/commit
> /?id=1b1b73f7558d867d72e198901b84bec1e6ef1405
>
> As this has already been applied to simon's tree.
>
> > Reviewed-by: Laurent Pinchart
> >
> >> + interrupts = ;
> >> + clocks = < CPG_MOD 716>;
> >> + power-domains = < R8A77990_PD_ALWAYS_ON>;
> >> + resets = < 716>;
> >> + status = "disabled";
> >> +
> >> + ports {
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> +
> >> + port@1 {
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> +
> >> + reg = <1>;
> >> +
> >> + csi40vin4: endpoint@0 {
> >> + reg = <0>;
> >> + remote-endpoint = <>;
> >> + };
> >> + csi40vin5: endpoint@1 {
> >> + reg = <1>;
> >> + remote-endpoint = <>;
> >> + };
> >> + };
> >> + };
> >> + };
> >> +
> >> + vin4: video@e6ef4000 {
> >> + compatible = "renesas,vin-r8a77990";
> >> +
Re: [PATCH] drm: rcar-du: Re-update the DSYSR register value for start/stop
Hello Hoan,
Thank you for the patch.
On Monday, 22 October 2018 09:30:54 EEST Nguyen An Hoan wrote:
> From: Hoan Nguyen An
>
> From previous commit 0521ccb "drm: rcar-du: Cache DSYSR value to ensure
> known initial value"
What exact commit are you referring to ? The mainline commit that has this
subject is 9144adc5e5a99577bce0d4ee2ca3615f53b9d296.
> We only need to update DSYSR0, DSYSR2 for start/stop.
> So using rgrp-> mmio_offset is enough, the change back from rcar_du_crtc ->
> rcar_du_group -> rcar_du_crtc leading to mmio addresses for DSYSR may be
> different.
Is this fixing an actual problem ? If you look at the code, the line
struct rcar_du_crtc *rcrtc = >dev->crtcs[rgrp->index * 2];
makes sure that we select DU0 or DU2 only, so the register write
rcar_du_crtc_dsysr_clr_set(rcrtc, DSYSR_DRES | DSYSR_DEN,
start ? DSYSR_DEN : DSYSR_DRES);
should only access DSYSR0 and DSYSR2.
> Signed-off-by: Hoan Nguyen An
> ---
> drivers/gpu/drm/rcar-du/rcar_du_group.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_group.c
> b/drivers/gpu/drm/rcar-du/rcar_du_group.c index d85f0a1..a5f7eed 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_group.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_group.c
> @@ -202,10 +202,9 @@ void rcar_du_group_put(struct rcar_du_group *rgrp)
>
> static void __rcar_du_group_start_stop(struct rcar_du_group *rgrp, bool
> start) {
> - struct rcar_du_crtc *rcrtc = >dev->crtcs[rgrp->index * 2];
> -
> - rcar_du_crtc_dsysr_clr_set(rcrtc, DSYSR_DRES | DSYSR_DEN,
> -start ? DSYSR_DEN : DSYSR_DRES);
> + rcar_du_group_write(rgrp, DSYSR,
> + (rcar_du_group_read(rgrp, DSYSR) & ~(DSYSR_DRES |
> DSYSR_DEN)) |
> + (start ? DSYSR_DEN : DSYSR_DRES));
> }
>
> void rcar_du_group_start_stop(struct rcar_du_group *rgrp, bool start)
--
Regards,
Laurent Pinchart
Re: HDMI doesn't work on ULCB board
Hi Morimoto-san, On Thursday, 18 October 2018 05:12:14 EEST Kuninori Morimoto wrote: > Hi Vladimir, Laurent > > I'm testing ULCB board, and I noticed that HDMI doen't work on it. Which ULCB board is this ? > - Sometimes kernel panic happen (I lost log, but it said "get crc" > something error), - Often, kernel doesn't boot with below log if I > connected HDMI cable when booting > - Monitor say "No signal" if I connected cable *after* booting > > I'm using Geert's renesas-drivers-2018-10-09-v4.19-rc7 branch. > It seems salvator HDMI is working correctly on it. > I attached my .config > > -- kernel log - > ... > [1.728010] renesas_irqc e61c.interrupt-controller: driving 6 irqs > [1.739166] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > [1.745851] [drm] No driver support for vblank timestamp query. > [1.787533] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > [1.794226] [drm] No driver support for vblank timestamp query. > [1.821091] rcar-dmac e670.dma-controller: ignoring dependency for > device, assuming no driver > [1.835807] rcar-dmac e730.dma-controller: ignoring dependency for > device, assuming no driver > [1.850397] rcar-dmac e731.dma-controller: ignoring dependency for > device, assuming no driver > [1.864799] rcar-dmac ec70.dma-controller: ignoring dependency for > device, assuming no driver > [1.879168] rcar-dmac ec72.dma-controller: ignoring dependency for > device, assuming no driver > [1.894102] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > [1.900788] [drm] No driver support for vblank timestamp query. > [1.907851] ravb e680.ethernet: ignoring dependency for device, > assuming no driver > [1.917038] libphy: ravb_mii: probed > [1.922342] ravb e680.ethernet eth0: Base address at 0xe680, > 2e:09:0a:00:83:2b, IRQ 116. > [1.931494] rcar-fcp fe95.fcp: ignoring dependency for device, > assuming no driver > [1.939736] rcar-fcp fe951000.fcp: ignoring dependency for device, > assuming no driver > [1.947894] rcar-fcp fe96f000.fcp: ignoring dependency for device, > assuming no driver > [1.956044] rcar-fcp fe92f000.fcp: ignoring dependency for device, > assuming no driver > [1.964206] rcar-fcp fe9af000.fcp: ignoring dependency for device, > assuming no driver > [1.972359] rcar-fcp fe9bf000.fcp: ignoring dependency for device, > assuming no driver > [1.980517] rcar-fcp fea27000.fcp: ignoring dependency for device, > assuming no driver > [1.988669] rcar-fcp fea2f000.fcp: ignoring dependency for device, > assuming no driver > [1.996825] rcar-fcp fea37000.fcp: ignoring dependency for device, > assuming no driver > [2.040729] rcar_sound ec50.sound: probed > [2.045763] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > [2.052441] [drm] No driver support for vblank timestamp query. > /* here kernel stop */ I will have a look. -- Regards, Laurent Pinchart
Re: [PATCH] ARM: dts: r8a779[01]: Disable unconnected LVDS encoders
Hello,
On Wednesday, 17 October 2018 20:48:01 EEST Laurent Pinchart wrote:
> The LVDS0 encoder on Koelsh and Porter, and the LVDS1 encoder on Lager,
> are enabled in DT but have no device connected to their output. This
> result in spurious messages being printed to the kernel log such as
>
> rcar-du feb0.display: no connector for encoder /soc/lvds@feb9,
> skipping
>
> Fix it by disabling the encoders.
>
> Fixes: 15a1ff30d8f9 ("ARM: dts: r8a7790: Convert to new LVDS DT bindings")
> Fixes: e5c3f4707f39 ("ARM: dts: r8a7791: Convert to new LVDS DT bindings")
> Reported-by: Simon Horman
This should have read
Reported-by: Geert Uytterhoeven
Sorry for the mistake, I had read the e-mail thread containing the report
incorrectly. Simon, could you fix this when applying to your tree, or should I
send a v2 ?
> Signed-off-by: Laurent Pinchart
> ---
> arch/arm/boot/dts/r8a7790-lager.dts | 2 --
> arch/arm/boot/dts/r8a7791-koelsch.dts | 2 --
> arch/arm/boot/dts/r8a7791-porter.dts | 2 --
> 3 files changed, 6 deletions(-)
>
> diff --git a/arch/arm/boot/dts/r8a7790-lager.dts
> b/arch/arm/boot/dts/r8a7790-lager.dts index 50312e752e2f..7b9508e83d46
> 100644
> --- a/arch/arm/boot/dts/r8a7790-lager.dts
> +++ b/arch/arm/boot/dts/r8a7790-lager.dts
> @@ -489,8 +489,6 @@
> };
>
> {
> - status = "okay";
> -
> ports {
> port@1 {
> lvds_connector: endpoint {
> diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts
> b/arch/arm/boot/dts/r8a7791-koelsch.dts index ce22db01fbba..e6580aa0cea3
> 100644
> --- a/arch/arm/boot/dts/r8a7791-koelsch.dts
> +++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
> @@ -479,8 +479,6 @@
> };
>
> {
> - status = "okay";
> -
> ports {
> port@1 {
> lvds_connector: endpoint {
> diff --git a/arch/arm/boot/dts/r8a7791-porter.dts
> b/arch/arm/boot/dts/r8a7791-porter.dts index f02036e5de01..fefdf8238bbe
> 100644
> --- a/arch/arm/boot/dts/r8a7791-porter.dts
> +++ b/arch/arm/boot/dts/r8a7791-porter.dts
> @@ -482,8 +482,6 @@
> };
>
> {
> - status = "okay";
> -
> ports {
> port@1 {
> lvds_connector: endpoint {
--
Regards,
Laurent Pinchart
[PATCH] ARM: dts: r8a779[01]: Disable unconnected LVDS encoders
The LVDS0 encoder on Koelsh and Porter, and the LVDS1 encoder on Lager,
are enabled in DT but have no device connected to their output. This
result in spurious messages being printed to the kernel log such as
rcar-du feb0.display: no connector for encoder /soc/lvds@feb9, skipping
Fix it by disabling the encoders.
Fixes: 15a1ff30d8f9 ("ARM: dts: r8a7790: Convert to new LVDS DT bindings")
Fixes: e5c3f4707f39 ("ARM: dts: r8a7791: Convert to new LVDS DT bindings")
Reported-by: Simon Horman
Signed-off-by: Laurent Pinchart
---
arch/arm/boot/dts/r8a7790-lager.dts | 2 --
arch/arm/boot/dts/r8a7791-koelsch.dts | 2 --
arch/arm/boot/dts/r8a7791-porter.dts | 2 --
3 files changed, 6 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7790-lager.dts
b/arch/arm/boot/dts/r8a7790-lager.dts
index 50312e752e2f..7b9508e83d46 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -489,8 +489,6 @@
};
{
- status = "okay";
-
ports {
port@1 {
lvds_connector: endpoint {
diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts
b/arch/arm/boot/dts/r8a7791-koelsch.dts
index ce22db01fbba..e6580aa0cea3 100644
--- a/arch/arm/boot/dts/r8a7791-koelsch.dts
+++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
@@ -479,8 +479,6 @@
};
{
- status = "okay";
-
ports {
port@1 {
lvds_connector: endpoint {
diff --git a/arch/arm/boot/dts/r8a7791-porter.dts
b/arch/arm/boot/dts/r8a7791-porter.dts
index f02036e5de01..fefdf8238bbe 100644
--- a/arch/arm/boot/dts/r8a7791-porter.dts
+++ b/arch/arm/boot/dts/r8a7791-porter.dts
@@ -482,8 +482,6 @@
};
{
- status = "okay";
-
ports {
port@1 {
lvds_connector: endpoint {
--
Regards,
Laurent Pinchart
[PATCH] MAINTAINERS: Remove Laurent Pinchart as Renesas pinctrl maintainer
Geert Uytterhoeven has long taken over and I'm not involved anymore with the Renesas pinctrl driver. Remove myself from the maintainers list. Signed-off-by: Laurent Pinchart --- MAINTAINERS | 1 - 1 file changed, 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 69373eb328d4..f9d00cc05202 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -11515,7 +11515,6 @@ F: Documentation/devicetree/bindings/pinctrl/qcom,*.txt F: drivers/pinctrl/qcom/ PIN CONTROLLER - RENESAS -M: Laurent Pinchart M: Geert Uytterhoeven L: linux-renesas-soc@vger.kernel.org T: git git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git sh-pfc -- Regards, Laurent Pinchart
Re: [PATCH] drm/rcar-du: Convert drm_atomic_helper_suspend/resume()
Hi Daniel,
On Monday, 1 October 2018 09:52:20 EEST Daniel Vetter wrote:
> On Fri, Sep 28, 2018 at 06:30:35PM +0300, Laurent Pinchart wrote:
> > On Friday, 28 September 2018 18:05:18 EEST Laurent Pinchart wrote:
> > > On Thursday, 27 September 2018 09:34:18 EEST Souptick Joarder wrote:
> > > > On Tue, Sep 18, 2018 at 10:05 PM Souptick Joarder wrote:
> > > >> convert drm_atomic_helper_suspend/resume() to use
> > > >> drm_mode_config_helper_suspend/resume().
> > > >>
> > > >> remove suspend_state field from the rcar_du_device
> > > >> structure as it is no more required.
> > > >>
> > > >> With this conversion, also drm_fbdev_cma_set_suspend_unlocked()
> > > >> will left with no consumer. So this function can be removed.
> > > >>
> > > >> Signed-off-by: Souptick Joarder
> > > >
> > > > Laurent, any comment on this patch ??
> > >
> > > Sorry for the delay, and thanks for pinging me.
> > >
> > > Reviewed-by: Laurent Pinchart
> > >
> > > Should I apply this to my tree or do you plan to merge it through
> > > drm-misc
> > > as it touches drm_fb_cma_helper.c ?
> >
> > I just realized that the same patch got supplied by Noralf Trønnes nearly
> > a
> > year ago, and was later superseded by
> > https://patchwork.freedesktop.org/patch/247861/. I think we should thus
> > apply Noralf's patches instead (once he sends v4 out).
>
> I don't think Noralf is still actively working on this, he's busy with the
> fbdev emulation stuff. Probably better if you pick up one of the existing
> ones, than waiting another year or so :-)
Isn't https://patchwork.freedesktop.org/patch/247861/ part of the fbdev
emulation stuff ? That patch series is from less than a month ago, so I
thought it was actively developed.
Let's ask him. Noralf, any comment ? :-)
> > > >> ---
> > > >>
> > > >> drivers/gpu/drm/drm_fb_cma_helper.c | 18 --
> > > >> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 21 ++---
> > > >> drivers/gpu/drm/rcar-du/rcar_du_drv.h | 1 -
> > > >> include/drm/drm_fb_cma_helper.h | 2 --
> > > >> 4 files changed, 2 insertions(+), 40 deletions(-)
> > > >>
> > > >> diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
> > > >> b/drivers/gpu/drm/drm_fb_cma_helper.c index 47e0e2f..96efc88 100644
> > > >> --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> > > >> +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> > > >> @@ -224,21 +224,3 @@ void drm_fbdev_cma_hotplug_event(struct
> > > >> drm_fbdev_cma *fbdev_cma)
> > > >>
> > > >> drm_fb_helper_hotplug_event(_cma->fb_helper);
> > > >>
> > > >> }
> > > >> EXPORT_SYMBOL_GPL(drm_fbdev_cma_hotplug_event);
> > > >>
> > > >> -
> > > >> -/**
> > > >> - * drm_fbdev_cma_set_suspend_unlocked - wrapper around
> > > >> - *
> > > >> drm_fb_helper_set_suspend_unlocked
> > > >> - * @fbdev_cma: The drm_fbdev_cma struct, may be NULL
> > > >> - * @state: desired state, zero to resume, non-zero to suspend
> > > >> - *
> > > >> - * Calls drm_fb_helper_set_suspend, which is a wrapper around
> > > >> - * fb_set_suspend implemented by fbdev core.
> > > >> - */
> > > >> -void drm_fbdev_cma_set_suspend_unlocked(struct drm_fbdev_cma
> > > >> *fbdev_cma,
> > > >> - bool state)
> > > >> -{
> > > >> - if (fbdev_cma)
> > > >> -
> > > >> drm_fb_helper_set_suspend_unlocked(_cma->fb_helper,
> > > >> - state);
> > > >> -}
> > > >> -EXPORT_SYMBOL(drm_fbdev_cma_set_suspend_unlocked);
> > > >> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> > > >> b/drivers/gpu/drm/rcar-du/rcar_du_drv.c index 02aee6c..288220f 100644
> > > >> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> > > >> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> > > >> @@ -357,32 +357,15 @@ static void rcar_du_lastclose(struct drm_device
> > > >> *dev)
> > > >>
> > > >> static int rcar_du_pm_suspend(struct devi
[PATCH v3 1/4] arm64: dts: renesas: r8a77990: Add display output support
The R8A77990 (E3) platform has one RGB output and two LVDS outputs
connected to the DU. Add the DT nodes for the DU, LVDS encoders and
supporting VSP and FCP.
Signed-off-by: Laurent Pinchart
Tested-by: Jacopo Mondi
---
Changes since v2:
- Fixed VSPI clock index
---
arch/arm64/boot/dts/renesas/r8a77990.dtsi | 167 ++
1 file changed, 167 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
index 0c726ea5d315..9509dc05665f 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
@@ -843,6 +843,82 @@
resets = < 408>;
};
+ vspb0: vsp@fe96 {
+ compatible = "renesas,vsp2";
+ reg = <0 0xfe96 0 0x8000>;
+ interrupts = ;
+ clocks = < CPG_MOD 626>;
+ power-domains = < R8A77990_PD_ALWAYS_ON>;
+ resets = < 626>;
+ renesas,fcp = <>;
+ };
+
+ fcpvb0: fcp@fe96f000 {
+ compatible = "renesas,fcpv";
+ reg = <0 0xfe96f000 0 0x200>;
+ clocks = < CPG_MOD 607>;
+ power-domains = < R8A77990_PD_ALWAYS_ON>;
+ resets = < 607>;
+ iommus = <_vp0 5>;
+ };
+
+ vspi0: vsp@fe9a {
+ compatible = "renesas,vsp2";
+ reg = <0 0xfe9a 0 0x8000>;
+ interrupts = ;
+ clocks = < CPG_MOD 631>;
+ power-domains = < R8A77990_PD_ALWAYS_ON>;
+ resets = < 631>;
+ renesas,fcp = <>;
+ };
+
+ fcpvi0: fcp@fe9af000 {
+ compatible = "renesas,fcpv";
+ reg = <0 0xfe9af000 0 0x200>;
+ clocks = < CPG_MOD 611>;
+ power-domains = < R8A77990_PD_ALWAYS_ON>;
+ resets = < 611>;
+ iommus = <_vp0 8>;
+ };
+
+ vspd0: vsp@fea2 {
+ compatible = "renesas,vsp2";
+ reg = <0 0xfea2 0 0x7000>;
+ interrupts = ;
+ clocks = < CPG_MOD 623>;
+ power-domains = < R8A77990_PD_ALWAYS_ON>;
+ resets = < 623>;
+ renesas,fcp = <>;
+ };
+
+ fcpvd0: fcp@fea27000 {
+ compatible = "renesas,fcpv";
+ reg = <0 0xfea27000 0 0x200>;
+ clocks = < CPG_MOD 603>;
+ power-domains = < R8A77990_PD_ALWAYS_ON>;
+ resets = < 603>;
+ iommus = <_vi0 8>;
+ };
+
+ vspd1: vsp@fea28000 {
+ compatible = "renesas,vsp2";
+ reg = <0 0xfea28000 0 0x7000>;
+ interrupts = ;
+ clocks = < CPG_MOD 622>;
+ power-domains = < R8A77990_PD_ALWAYS_ON>;
+ resets = < 622>;
+ renesas,fcp = <>;
+ };
+
+ fcpvd1: fcp@fea2f000 {
+ compatible = "renesas,fcpv";
+ reg = <0 0xfea2f000 0 0x200>;
+ clocks = < CPG_MOD 602>;
+ power-domains = < R8A77990_PD_ALWAYS_ON>;
+ resets = < 602>;
+ iommus = <_vi0 9>;
+ };
+
csi40: csi2@feaa {
compatible = "renesas,r8a77990-csi2",
"renesas,rcar-gen3-csi2";
reg = <0 0xfeaa 0 0x1>;
@@ -874,6 +950,97 @@
};
};
+ du: display@feb0 {
+ compatible = "renesas,du-r8a77990";
+ reg = <0 0xfeb0 0 0x8>;
+ interrupts = ,
+;
+ clocks = < CPG_MOD 724>,
+< CPG_MOD 723>;
+ clock-names = "du.0", "du.1";
+ vsps = < 0 0>;
+ status = "disabled";
+
+ ports {
+
[PATCH v3 4/4] arm64: dts: renesas: r8a77995: draak: Enable HDMI display output
From: Ulrich Hecht
Adds LVDS decoder, HDMI encoder and connector for the Draak board.
The LVDS0 and LVDS1 encoders can use the DU_DOTCLKIN0, DU_DOTCLKIN1 and
EXTAL externals clocks. Two of them are provided to the SoC on the Draak
board, hook them up in DT.
Signed-off-by: Ulrich Hecht
Signed-off-by: Laurent Pinchart
Tested-by: Jacopo Mondi
---
arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 98 +-
1 file changed, 97 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
index e39b73005381..2405eaad0296 100644
--- a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
@@ -2,7 +2,7 @@
/*
* Device Tree Source for the Draak board
*
- * Copyright (C) 2016 Renesas Electronics Corp.
+ * Copyright (C) 2016-2018 Renesas Electronics Corp.
* Copyright (C) 2017 Glider bvba
*/
@@ -45,6 +45,41 @@
};
};
+ hdmi-out {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con_out: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+ };
+
+ lvds-decoder {
+ compatible = "thine,thc63lvd1024";
+ vcc-supply = <_3p3v>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ thc63lvd1024_in: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+ thc63lvd1024_out: endpoint {
+ remote-endpoint = <_in>;
+ };
+ };
+ };
+ };
+
memory@4800 {
device_type = "memory";
/* first 128MB is reserved for secure area. */
@@ -190,6 +225,43 @@
};
+ hdmi-encoder@39 {
+ compatible = "adi,adv7511w";
+ reg = <0x39>, <0x3f>, <0x38>, <0x3c>;
+ reg-names = "main", "edid", "packet", "cec";
+ interrupt-parent = <>;
+ interrupts = <28 IRQ_TYPE_LEVEL_LOW>;
+
+ /* Depends on LVDS */
+ max-clock = <13500>;
+ min-vrefresh = <50>;
+
+ adi,input-depth = <8>;
+ adi,input-colorspace = "rgb";
+ adi,input-clock = "1x";
+ adi,input-style = <1>;
+ adi,input-justification = "evenly";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ adv7511_in: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ adv7511_out: endpoint {
+ remote-endpoint = <_con_out>;
+ };
+ };
+ };
+ };
+
hdmi-decoder@4c {
compatible = "adi,adv7612";
reg = <0x4c>;
@@ -240,6 +312,30 @@
status = "okay";
};
+ {
+ status = "okay";
+
+ clocks = < CPG_MOD 727>,
+<_clk>,
+<_clk>;
+ clock-names = "fck", "dclkin.0", "extal";
+
+ ports {
+ port@1 {
+ lvds0_out: endpoint {
+ remote-endpoint = <_in>;
+ };
+ };
+ };
+};
+
+ {
+ clocks = < CPG_MOD 727>,
+<_clk>,
+<_clk>;
+ clock-names = "fck", "dclkin.0", "extal";
+};
+
{
status = "okay";
};
--
Regards,
Laurent Pinchart
[PATCH v3 2/4] arm64: dts: renesas: r8a77995: Add LVDS support
From: Kieran Bingham
The r8a77995 D3 platform has 2 LVDS channels connected to the DU.
Signed-off-by: Kieran Bingham
[uli: moved lvds* into the soc node, added PM domains, resets]
Signed-off-by: Ulrich Hecht
Reviewed-by: Laurent Pinchart
Tested-by: Jacopo Mondi
---
arch/arm64/boot/dts/renesas/r8a77995.dtsi | 56 +++
1 file changed, 56 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
index 89a04a4496fd..214f4954b321 100644
--- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
@@ -972,12 +972,68 @@
port@1 {
reg = <1>;
du_out_lvds0: endpoint {
+ remote-endpoint = <_in>;
};
};
port@2 {
reg = <2>;
du_out_lvds1: endpoint {
+ remote-endpoint = <_in>;
+ };
+ };
+ };
+ };
+
+ lvds0: lvds-encoder@feb9 {
+ compatible = "renesas,r8a77995-lvds";
+ reg = <0 0xfeb9 0 0x20>;
+ clocks = < CPG_MOD 727>;
+ power-domains = < R8A77995_PD_ALWAYS_ON>;
+ resets = < 727>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ lvds0_in: endpoint {
+ remote-endpoint =
<_out_lvds0>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ lvds0_out: endpoint {
+ };
+ };
+ };
+ };
+
+ lvds1: lvds-encoder@feb90100 {
+ compatible = "renesas,r8a77995-lvds";
+ reg = <0 0xfeb90100 0 0x20>;
+ clocks = < CPG_MOD 727>;
+ power-domains = < R8A77995_PD_ALWAYS_ON>;
+ resets = < 726>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ lvds1_in: endpoint {
+ remote-endpoint =
<_out_lvds1>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ lvds1_out: endpoint {
};
};
};
--
Regards,
Laurent Pinchart
[PATCH v3 0/4] R-Car D3/E3 display DT enablement
Hello, The patches in this series enable display support for the D3 and E3 SoCs, on the Draak and Ebisu boards respectively. They were previously part of the "[PATCH v2 00/16] R-Car D3/E3 display support (with LVDS PLL)" series, and have been split out now that the DT bindings have been accepted andon their way to v4.20 through the DRM tree, along with the code changes. Compared to v2, the VSPI MSTP clock index has been fixed, and the patches rebased on top of Simon's latest devel branch. Simon, could you please consider this as an update for v4.20 ? Kieran Bingham (1): arm64: dts: renesas: r8a77995: Add LVDS support Laurent Pinchart (2): arm64: dts: renesas: r8a77990: Add display output support arm64: dts: renesas: r8a77990: ebisu: Enable VGA and HDMI outputs Ulrich Hecht (1): arm64: dts: renesas: r8a77995: draak: Enable HDMI display output arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts | 162 arch/arm64/boot/dts/renesas/r8a77990.dtsi | 167 + arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 98 ++- arch/arm64/boot/dts/renesas/r8a77995.dtsi | 56 + 4 files changed, 482 insertions(+), 1 deletion(-) -- Regards, Laurent Pinchart
[PATCH v3 3/4] arm64: dts: renesas: r8a77990: ebisu: Enable VGA and HDMI outputs
Add the LVDS decoder, HDMI encoder, VGA encoder and HDMI and VGA
connectors, and wire up the display-related nodes with clocks, pinmux
and regulators.
The LVDS0 and LVDS1 encoders can use the DU_DOTCLKIN0, DU_DOTCLKIN1 and
EXTAL externals clocks. Two of them are provided to the SoC on the Ebisu
board, hook them up in DT.
Signed-off-by: Laurent Pinchart
Tested-by: Jacopo Mondi
---
arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts | 162 +
1 file changed, 162 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
index fd60079169f6..f342dd85b152 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
@@ -51,6 +51,88 @@
};
};
};
+
+ hdmi-out {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con_out: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+ };
+
+ lvds-decoder {
+ compatible = "thine,thc63lvd1024";
+ vcc-supply = <_3p3v>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ thc63lvd1024_in: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+ thc63lvd1024_out: endpoint {
+ remote-endpoint = <_in>;
+ };
+ };
+ };
+ };
+
+ vga {
+ compatible = "vga-connector";
+
+ port {
+ vga_in: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+ };
+
+ vga-encoder {
+ compatible = "adi,adv7123";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ adv7123_in: endpoint {
+ remote-endpoint = <_out_rgb>;
+ };
+ };
+ port@1 {
+ reg = <1>;
+ adv7123_out: endpoint {
+ remote-endpoint = <_in>;
+ };
+ };
+ };
+ };
+
+ reg_3p3v: regulator1 {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-3.3V";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ x13_clk: x13 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <7425>;
+ };
};
{
@@ -86,6 +168,25 @@
};
};
+ {
+ pinctrl-0 = <_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ clocks = < CPG_MOD 724>,
+< CPG_MOD 723>,
+<_clk>;
+ clock-names = "du.0", "du.1", "dclkin.0";
+
+ ports {
+ port@0 {
+ endpoint {
+ remote-endpoint = <_in>;
+ };
+ };
+ };
+};
+
{
status = "okay";
};
@@ -97,6 +198,38 @@
{
status = "okay";
+ hdmi-encoder@39 {
+ compatible = "adi,adv7511w";
+ reg = <0x39>;
+ interrupt-parent = <>;
+ interrupts = <1 IRQ_TYPE_LEVEL_LOW>;
+
+ adi,input-depth = <8>;
+ adi,input-colorspace = "rgb";
+ adi,input-clock = "1x";
+ adi,input-style = <1>;
+ adi,input-justification = "evenly";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
[PATCH] pinctrl: sh-pfc: r8a77990: Add PWM pins, groups and functions
The R8A77990 (E3) SoC has 7 PWM outputs, add pins, groups and functions
for all of them.
Signed-off-by: Laurent Pinchart
---
drivers/pinctrl/sh-pfc/pfc-r8a77990.c | 180 ++
1 file changed, 180 insertions(+)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
index bb9c943e2b37..eca3e678544f 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
@@ -1595,6 +1595,126 @@ static const unsigned int i2c7_b_mux[] = {
SCL7_B_MARK, SDA7_B_MARK,
};
+/* - PWM0
*/
+static const unsigned int pwm0_a_pins[] = {
+ /* PWM */
+ RCAR_GP_PIN(2, 22),
+};
+static const unsigned int pwm0_a_mux[] = {
+ PWM0_A_MARK,
+};
+static const unsigned int pwm0_b_pins[] = {
+ /* PWM */
+ RCAR_GP_PIN(6, 3),
+};
+static const unsigned int pwm0_b_mux[] = {
+ PWM0_B_MARK,
+};
+/* - PWM1
*/
+static const unsigned int pwm1_a_pins[] = {
+ /* PWM */
+ RCAR_GP_PIN(2, 23),
+};
+static const unsigned int pwm1_a_mux[] = {
+ PWM1_A_MARK,
+};
+static const unsigned int pwm1_b_pins[] = {
+ /* PWM */
+ RCAR_GP_PIN(6, 4),
+};
+static const unsigned int pwm1_b_mux[] = {
+ PWM1_B_MARK,
+};
+/* - PWM2
*/
+static const unsigned int pwm2_a_pins[] = {
+ /* PWM */
+ RCAR_GP_PIN(1, 0),
+};
+static const unsigned int pwm2_a_mux[] = {
+ PWM2_A_MARK,
+};
+static const unsigned int pwm2_b_pins[] = {
+ /* PWM */
+ RCAR_GP_PIN(1, 4),
+};
+static const unsigned int pwm2_b_mux[] = {
+ PWM2_B_MARK,
+};
+static const unsigned int pwm2_c_pins[] = {
+ /* PWM */
+ RCAR_GP_PIN(6, 5),
+};
+static const unsigned int pwm2_c_mux[] = {
+ PWM2_C_MARK,
+};
+/* - PWM3
*/
+static const unsigned int pwm3_a_pins[] = {
+ /* PWM */
+ RCAR_GP_PIN(1, 1),
+};
+static const unsigned int pwm3_a_mux[] = {
+ PWM3_A_MARK,
+};
+static const unsigned int pwm3_b_pins[] = {
+ /* PWM */
+ RCAR_GP_PIN(2, 5),
+};
+static const unsigned int pwm3_b_mux[] = {
+ PWM3_B_MARK,
+};
+static const unsigned int pwm3_c_pins[] = {
+ /* PWM */
+ RCAR_GP_PIN(6, 6),
+};
+static const unsigned int pwm3_c_mux[] = {
+ PWM3_C_MARK,
+};
+/* - PWM4
*/
+static const unsigned int pwm4_a_pins[] = {
+ /* PWM */
+ RCAR_GP_PIN(1, 3),
+};
+static const unsigned int pwm4_a_mux[] = {
+ PWM4_A_MARK,
+};
+static const unsigned int pwm4_b_pins[] = {
+ /* PWM */
+ RCAR_GP_PIN(6, 7),
+};
+static const unsigned int pwm4_b_mux[] = {
+ PWM4_B_MARK,
+};
+/* - PWM5
*/
+static const unsigned int pwm5_a_pins[] = {
+ /* PWM */
+ RCAR_GP_PIN(2, 24),
+};
+static const unsigned int pwm5_a_mux[] = {
+ PWM5_A_MARK,
+};
+static const unsigned int pwm5_b_pins[] = {
+ /* PWM */
+ RCAR_GP_PIN(6, 10),
+};
+static const unsigned int pwm5_b_mux[] = {
+ PWM5_B_MARK,
+};
+/* - PWM6
*/
+static const unsigned int pwm6_a_pins[] = {
+ /* PWM */
+ RCAR_GP_PIN(2, 25),
+};
+static const unsigned int pwm6_a_mux[] = {
+ PWM6_A_MARK,
+};
+static const unsigned int pwm6_b_pins[] = {
+ /* PWM */
+ RCAR_GP_PIN(6, 11),
+};
+static const unsigned int pwm6_b_mux[] = {
+ PWM6_B_MARK,
+};
+
/* - SCIF0 --
*/
static const unsigned int scif0_data_a_pins[] = {
/* RX, TX */
@@ -1951,6 +2071,22 @@ static const struct sh_pfc_pin_group pinmux_groups[] = {
SH_PFC_PIN_GROUP(i2c6_b),
SH_PFC_PIN_GROUP(i2c7_a),
SH_PFC_PIN_GROUP(i2c7_b),
+ SH_PFC_PIN_GROUP(pwm0_a),
+ SH_PFC_PIN_GROUP(pwm0_b),
+ SH_PFC_PIN_GROUP(pwm1_a),
+ SH_PFC_PIN_GROUP(pwm1_b),
+ SH_PFC_PIN_GROUP(pwm2_a),
+ SH_PFC_PIN_GROUP(pwm2_b),
+ SH_PFC_PIN_GROUP(pwm2_c),
+ SH_PFC_PIN_GROUP(pwm3_a),
+ SH_PFC_PIN_GROUP(pwm3_b),
+ SH_PFC_PIN_GROUP(pwm3_c),
+ SH_PFC_PIN_GROUP(pwm4_a),
+ SH_PFC_PIN_GROUP(pwm4_b),
+ SH_PFC_PIN_GROUP(pwm5_a),
+ SH_PFC_PIN_GROUP(pwm5_b),
+ SH_PFC_PIN_GROUP(pwm6_a),
+ SH_PFC_PIN_GROUP(pwm6_b),
SH_PFC_PIN_GROUP(scif0_data_a),
SH_PFC_PIN_GROUP(scif0_clk_a),
SH_PFC_PIN_GROUP(scif0_ctrl_a),
@@ -2043,6 +2179,43 @@ static const char * const i2c7_groups[] = {
"i2c7_b",
};
+static const char * const pwm0_groups[] = {
+ "pwm0_a",
+ "pwm0_b",
+};
+
+static
Re: [PATCH/RFT v2 0/8] arm64: dts: renesas: Ebisu: Add HDMI and CVBS input
name="adv748x 4-0070 afe" +hdminame="adv748x 4-0070 hdmi" +txaname="adv748x 4-0070 txa" +txbname="adv748x 4-0070 txb" + ;; +esac fi diff --git a/yavta-hdmi b/yavta-hdmi index 2e3b625978fe..7f9e10b42d94 100755 --- a/yavta-hdmi +++ b/yavta-hdmi @@ -36,6 +36,7 @@ case $vc in 4) vinname=$vinname4 dev=/dev/$vin4 +csipad=1 ;; *) echo "Unkown VC '$vc'" > This series should then be applied on top of the just sent: > [PATCH v2 0/5] media: adv748x: Allow probe with a single output endpoint > To allow the adv7482 to probe with a single output port enabled. > > This series, based on v4.19-rc2 with adv748x series on top, is available at: > git://jmondi.org/linux ebisu/linus-master/hdmi_cvbs_v2 > > Thanks >j > > Jacopo Mondi (6): > media: dt-bindings: rcar-vin: Add R8A77990 support > media: rcar-vin: Add support for R-Car R8A77990 > media: dt-bindings: rcar-csi2: Add R8A77990 > media: rcar-csi2: Add R8A77990 support > pinctrl: sh-pfc: r8a77990: Add VIN pins, groups and functions > arm64: dts: renesas: ebisu: Add HDMI and CVBS input > > Koji Matsuoka (1): > arm64: dts: r8a77990: Add VIN and CSI-2 device nodes > > Takeshi Kihara (1): > arm64: dts: r8a77990: Add I2C device nodes > > .../devicetree/bindings/media/rcar_vin.txt | 1 + > .../bindings/media/renesas,rcar-csi2.txt | 1 + > arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts | 86 +++ > arch/arm64/boot/dts/renesas/r8a77990.dtsi | 202 + > drivers/media/platform/rcar-vin/rcar-core.c| 20 ++ > drivers/media/platform/rcar-vin/rcar-csi2.c| 9 + > drivers/pinctrl/sh-pfc/pfc-r8a77990.c | 250 ++ > 7 files changed, 569 insertions(+) -- Regards, Laurent Pinchart
Re: [PATCH v2 6/8] arm64: dts: r8a77990: Add VIN and CSI-2 device nodes
Hi Jacopo,
On Monday, 10 September 2018 17:12:30 EEST Laurent Pinchart wrote:
> Hi Jacopo,
>
> Thank you for the patch.
>
> On Wednesday, 5 September 2018 18:29:43 EEST Jacopo Mondi wrote:
> > From: Koji Matsuoka
> >
> > Add device nodes for VIN4, VIN5 and CSI40 to R-Car E3 R8A77990 device
> > tree.
> >
> > Signed-off-by: Koji Matsuoka
> > Signed-off-by: Takeshi Kihara
> > Signed-off-by: Jacopo Mondi
> > ---
> >
> > arch/arm64/boot/dts/renesas/r8a77990.dtsi | 79 ++
> > 1 file changed, 79 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> > b/arch/arm64/boot/dts/renesas/r8a77990.dtsi index ae89260..0ae7bbe 100644
> > --- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> > +++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> > @@ -337,6 +337,85 @@
> >
> > status = "disabled";
> >
> > };
> >
> > + csi40: csi2@feaa {
>
> I believe Simon would like to keep the nodes sorted by address
>
> > + compatible = "renesas,r8a77990-csi2",
> > "renesas,rcar-gen3-csi2";
> > + reg = <0 0xfeaa 0 0x1>;
>
> 0x1 seems pretty large to me.
>
> Apart from that,
>
> Reviewed-by: Laurent Pinchart
>
> > + interrupts = ;
> > + clocks = < CPG_MOD 716>;
> > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > + resets = < 716>;
> > + status = "disabled";
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port@1 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + reg = <1>;
> > +
> > + csi40vin4: endpoint@0 {
> > + reg = <0>;
> > + remote-endpoint = <>;
> > + };
> > + csi40vin5: endpoint@1 {
> > + reg = <1>;
> > + remote-endpoint = <>;
> > + };
> > + };
> > + };
> > + };
> > +
> > + vin4: video@e6ef4000 {
> > + compatible = "renesas,vin-r8a77990";
> > + reg = <0 0xe6ef4000 0 0x1000>;
> > + interrupts = ;
> > + clocks = < CPG_MOD 807>;
> > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > + resets = < 807>;
> > + renesas,id = <4>;
> > + status = "disabled";
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port@1 {
> > + reg = <1>;
> > +
> > + vin4csi40: endpoint {
> > + remote-endpoint= <>;
I've just realized that this endpoint has to be numbered, otherwise MC links
won't be created.
> > + };
> > + };
> > + };
> > + };
> > +
> > + vin5: video@e6ef5000 {
> > + compatible = "renesas,vin-r8a77990";
> > + reg = <0 0xe6ef5000 0 0x1000>;
> > + interrupts = ;
> > + clocks = < CPG_MOD 806>;
> > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > + resets = < 806>;
> > + renesas,id = <5>;
> > + status = "disabled";
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port@1 {
> > + reg = <1>;
> > +
> > + vin5csi40: endpoint {
> > + remote-endpoint= <>;
Same here.
> > + };
> > + };
> > + };
> > + };
> > +
> >
> > scif2: serial@e6e88000 {
> >
> > compatible = "renesas,scif-r8a77990",
> >
> > "renesas,rcar-gen3-scif", "renesas,scif";
--
Regards,
Laurent Pinchart
Re: [GIT PULL FOR renesas-drivers] D3 and E3 HDMI output support
Hi Geert,
Simon, there's a question for your below.
On Monday, 17 September 2018 10:53:33 EEST Geert Uytterhoeven wrote:
> On Sat, Sep 15, 2018 at 4:44 PM Laurent Pinchart wrote:
> > The following changes since commit
6e1637c91742570ff873433ed27227933b792af4:
> > drm: rcar-du: Remove packed VYUY support (2018-09-15 17:28:34 +0300)
> >
> > are available in the Git repository at:
> > git://linuxtv.org/pinchartl/media.git for/renesas-drivers
> >
> > for you to fetch changes up to d7e0cb47e1d06d3033812281fe98528d1713ec16:
> > Merge tag 'drm-du-dt-lvds-pll-v1-20180915' into for/renesas-drivers
> >
> > (2018-09-15 17:38:05 +0300)
> >
> > Please note that the for/renesas-drivers branch is a merge of a code and a
> > DT branch (available under the drm-du-lvds-pll-v1-20180915 and
> > drm-du-dt-lvds- pll-v1-20180915 tags respectively). Those two branches
> > have different bases (drm-next from Dave's tree and devel from Simon's
> > tree respectively), I've thus edited the diffstat below manually.
>
> Thanks for your pull request!
>
> This causes merge conflicts with next-20180913 in
>
> arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> arch/arm64/boot/dts/renesas/r8a77990.dtsi
> arch/arm64/boot/dts/renesas/r8a77995-draak.dts
What would be a better base than Simon's devel branch for DT patches ?
> and with Kieran's du/2018q3 in
>
> drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> drivers/gpu/drm/rcar-du/rcar_du_drv.h
> drivers/gpu/drm/rcar-du/rcar_lvds.c
>
> While the DT conflicts may not be unavoidedable, please coordinate with
> Kieran for the rcar-du conflicts.
Apart from the topmost patch ("drm: rcar-du: Revert "drm: rcar-du: Use
__drm_atomic_helper_plane_reset instead of copying the logic"") which Kieran's
added due the last minute discovery of a 4.19-rc regression, Kieran's branch
is identical in content with the base of my pull request. The commit IDs are
not the same though, as I've since then rebased my tree to prepare it for
upstream, but only one commit message has changed, without touching the code
itself.
git seems not to be doing a great job here. If you merge my drm/du/next branch
into Kieran's du/2018q3 branch, and then merge my for/renesas-drivers branch,
it will all merge cleanly (drm/du/next is included in for/renesas-drivers).
However, merging for/renesas-drivers results in merge conflicts.
--
Regards,
Laurent Pinchart
Re: [PATCH v2 13/16] arm64: dts: renesas: r8a77990: Add display output support
Hi Simon,
On Monday, 17 September 2018 11:47:15 EEST Laurent Pinchart wrote:
> On Monday, 17 September 2018 11:14:20 EEST Simon Horman wrote:
> > On Mon, Sep 17, 2018 at 09:50:55AM +0200, Simon Horman wrote:
> > > On Fri, Sep 14, 2018 at 12:10:43PM +0300, Laurent Pinchart wrote:
> > > > The R8A77990 (E3) platform has one RGB output and two LVDS outputs
> > > > connected to the DU. Add the DT nodes for the DU, LVDS encoders and
> > > > supporting VSP and FCP.
> > > >
> > > > Signed-off-by: Laurent Pinchart
> > > >
> > > > Tested-by: Jacopo Mondi
> > > > ---
> > > >
> > > > arch/arm64/boot/dts/renesas/r8a77990.dtsi | 167
> > > > +++
> > > > 1 file changed, 167 insertions(+)
> > > >
> > > > diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> > > > b/arch/arm64/boot/dts/renesas/r8a77990.dtsi index
> > > > abb14af76c0e..600074ca3ee5 100644
> > > > --- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> > > > +++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> > > > @@ -537,6 +537,173 @@
> > > >
> > > > resets = < 408>;
> > > >
> > > > };
> > >
> > > These nodes should be placed after the gic to preserve the sorting
> > > of nodes by bus address and then IP block.
> > >
> > > > + vspb0: vsp@fe96 {
> > > > + compatible = "renesas,vsp2";
> > > > + reg = <0 0xfe96 0 0x8000>;
> > > > + interrupts = ;
> > > > + clocks = < CPG_MOD 626>;
> > > > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > > > + resets = < 626>;
> > > > + renesas,fcp = <>;
> > > > + };
> > > > +
> > > > + fcpvb0: fcp@fe96f000 {
> > > > + compatible = "renesas,fcpv";
> > > > + reg = <0 0xfe96f000 0 0x200>;
> > > > + clocks = < CPG_MOD 607>;
> > > > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > > > + resets = < 607>;
> > > > + iommus = <_vp0 5>;
> > > > + };
> > > > +
> > > > + vspi0: vsp@fe9a {
> > > > + compatible = "renesas,vsp2";
> > > > + reg = <0 0xfe9a 0 0x8000>;
> > > > + interrupts = ;
> > > > + clocks = < CPG_MOD 622>;
> > >
> > > R-Car Series, 3rd Generation, v1.00, Table Table 8A.21 indicates
> > > that this clock should be < CPG_MOD 631>. The clock above is
> > > (according to my reading of the documentation) correctly
> > > used for vspd1 below.
> > >
> > > > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > > > + resets = < 631>;
> > > > + renesas,fcp = <>;
> > > > + };
> > > > +
> > > > + fcpvi0: fcp@fe9af000 {
> > > > + compatible = "renesas,fcpv";
> > > > + reg = <0 0xfe9af000 0 0x200>;
> > > > + clocks = < CPG_MOD 611>;
> > > > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > > > + resets = < 611>;
> > > > + iommus = <_vp0 8>;
> > > > + };
> > > > +
> > > > + vspd0: vsp@fea2 {
> > > > + compatible = "renesas,vsp2";
> > > > + reg = <0 0xfea2 0 0x7000>;
> > > > + interrupts = ;
> > > > + clocks = < CPG_MOD 623>;
> > > > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > > > + resets = < 623>;
> > > > + renesas,fcp = <>;
> > > > +
[GIT PULL FOR renesas-drivers] D3 and E3 HDMI output support
Hi Geert, The following changes since commit 6e1637c91742570ff873433ed27227933b792af4: drm: rcar-du: Remove packed VYUY support (2018-09-15 17:28:34 +0300) are available in the Git repository at: git://linuxtv.org/pinchartl/media.git for/renesas-drivers for you to fetch changes up to d7e0cb47e1d06d3033812281fe98528d1713ec16: Merge tag 'drm-du-dt-lvds-pll-v1-20180915' into for/renesas-drivers (2018-09-15 17:38:05 +0300) Please note that the for/renesas-drivers branch is a merge of a code and a DT branch (available under the drm-du-lvds-pll-v1-20180915 and drm-du-dt-lvds- pll-v1-20180915 tags respectively). Those two branches have different bases (drm-next from Dave's tree and devel from Simon's tree respectively), I've thus edited the diffstat below manually. Kieran Bingham (1): arm64: dts: renesas: r8a77995: Add LVDS support Laurent Pinchart (14): arm64: dts: renesas: r8a77990: Add display output support arm64: dts: renesas: r8a77990: ebisu: Enable VGA and HDMI outputs pinctrl: sh-pfc: r8a77990: Add DU pins, groups and function dt-bindings: display: renesas: du: Document r8a77990 bindings dt-bindings: display: renesas: lvds: Document r8a77990 bindings dt-bindings: display: renesas: lvds: Add EXTAL and DU_DOTCLKIN clocks drm: bridge: thc63: Restrict modes based on hardware operating frequency drm: rcar-du: lvds: D3/E3 support drm: rcar-du: Perform the initial CRTC setup from rcar_du_crtc_get() drm: rcar-du: Use LVDS PLL clock as dot clock when possible drm: rcar-du: Enable configurable DPAD0 routing on Gen3 drm: rcar-du: Cache DSYSR value to ensure known initial value drm: rcar-du: Don't use TV sync mode when not supported by the hardware Merge tag 'drm-du-dt-lvds-pll-v1-20180915' into for/renesas-drivers Ulrich Hecht (2): arm64: dts: renesas: r8a77995: draak: Enable HDMI display output drm: rcar-du: Add r8a77990 and r8a77995 device support Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt | 13 Documentation/devicetree/bindings/display/renesas,du.txt |2 arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts| 166 arch/arm64/boot/dts/renesas/r8a77990.dtsi | 167 arch/arm64/boot/dts/renesas/r8a77995-draak.dts| 98 ++ arch/arm64/boot/dts/renesas/r8a77995.dtsi | 56 + drivers/gpu/drm/bridge/thc63lvd1024.c | 18 drivers/gpu/drm/rcar-du/rcar_du_crtc.c| 136 ++- drivers/gpu/drm/rcar-du/rcar_du_crtc.h|5 drivers/gpu/drm/rcar-du/rcar_du_drv.c | 63 + drivers/gpu/drm/rcar-du/rcar_du_drv.h |3 drivers/gpu/drm/rcar-du/rcar_du_group.c | 88 +- drivers/gpu/drm/rcar-du/rcar_du_kms.c | 12 drivers/gpu/drm/rcar-du/rcar_lvds.c | 355 +++- drivers/gpu/drm/rcar-du/rcar_lvds_regs.h | 43 + drivers/pinctrl/sh-pfc/pfc-r8a77990.c | 110 +++ 16 files changed, 1187 insertions(+), 148 deletions(-) -- Regards, Laurent Pinchart
Re: [PATCH v2 8/8] arm64: dts: renesas: ebisu: Add HDMI and CVBS input
Hi Jacopo,
Thank you for the patch.
On Wednesday, 5 September 2018 18:29:45 EEST Jacopo Mondi wrote:
> Add HDMI and CVBS inputs device nodes to R-Car E3 Ebisu board.
>
> Both HDMI and CVBS inputs are connected to an ADV7482 video decoder hooked
> to the SoC CSI-2 receiver port.
>
> Signed-off-by: Jacopo Mondi
Reviewed-by: Laurent Pinchart
> ---
> arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts | 86 +++
> 1 file changed, 86 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
> b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts index 2bc3a48..d2faf3e
> 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
> @@ -28,6 +28,29 @@
> /* first 128MB is reserved for secure area. */
> reg = <0x0 0x4800 0x0 0x3800>;
> };
> +
> + cvbs-in {
> + compatible = "composite-video-connector";
> + label = "CVBS IN";
> +
> + port {
> + cvbs_con: endpoint {
> + remote-endpoint = <_ain7>;
> + };
> + };
> + };
> +
> + hdmi-in {
> + compatible = "hdmi-connector";
> + label = "HDMI IN";
> + type = "a";
> +
> + port {
> + hdmi_in_con: endpoint {
> + remote-endpoint = <_hdmi>;
> + };
> + };
> + };
> };
>
> {
> @@ -47,6 +70,22 @@
> };
> };
>
> + {
> + status = "okay";
> +
> + ports {
> + port@0 {
> + reg = <0>;
> +
> + csi40_in: endpoint {
> + clock-lanes = <0>;
> + data-lanes = <1 2>;
> + remote-endpoint = <_txa>;
> + };
> + };
> + };
> +};
> +
> {
> status = "okay";
> };
> @@ -55,6 +94,49 @@
> clock-frequency = <4800>;
> };
>
> + {
> + status = "okay";
> +
> + video-receiver@70 {
> + compatible = "adi,adv7482";
> + reg = <0x70>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + interrupt-parent = <>;
> + interrupt-names = "intrq1", "intrq2";
> + interrupts = <7 IRQ_TYPE_LEVEL_LOW>,
> + <17 IRQ_TYPE_LEVEL_LOW>;
> +
> + port@7 {
> + reg = <7>;
> +
> + adv7482_ain7: endpoint {
> + remote-endpoint = <_con>;
> + };
> + };
> +
> + port@8 {
> + reg = <8>;
> +
> + adv7482_hdmi: endpoint {
> + remote-endpoint = <_in_con>;
> + };
> + };
> +
> + port@a {
> + reg = <0xa>;
> +
> + adv7482_txa: endpoint {
> + clock-lanes = <0>;
> + data-lanes = <1 2>;
> + remote-endpoint = <_in>;
> + };
> + };
> + };
> +};
> +
> {
> status = "okay";
> };
> @@ -94,6 +176,10 @@
> status = "okay";
> };
>
> + {
> + status = "okay";
> +};
> +
> {
> pinctrl-0 = <_pins>;
> pinctrl-names = "default";
--
Regards,
Laurent Pinchart
Re: [PATCH v2 6/8] arm64: dts: r8a77990: Add VIN and CSI-2 device nodes
Hi Jacopo,
Thank you for the patch.
On Wednesday, 5 September 2018 18:29:43 EEST Jacopo Mondi wrote:
> From: Koji Matsuoka
>
> Add device nodes for VIN4, VIN5 and CSI40 to R-Car E3 R8A77990 device tree.
>
> Signed-off-by: Koji Matsuoka
> Signed-off-by: Takeshi Kihara
> Signed-off-by: Jacopo Mondi
> ---
> arch/arm64/boot/dts/renesas/r8a77990.dtsi | 79
> 1 file changed, 79 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> b/arch/arm64/boot/dts/renesas/r8a77990.dtsi index ae89260..0ae7bbe 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> @@ -337,6 +337,85 @@
> status = "disabled";
> };
>
> + csi40: csi2@feaa {
I believe Simon would like to keep the nodes sorted by address
> + compatible = "renesas,r8a77990-csi2",
> "renesas,rcar-gen3-csi2";
> + reg = <0 0xfeaa 0 0x1>;
0x1 seems pretty large to me.
Apart from that,
Reviewed-by: Laurent Pinchart
> + interrupts = ;
> + clocks = < CPG_MOD 716>;
> + power-domains = < R8A77990_PD_ALWAYS_ON>;
> + resets = < 716>;
> + status = "disabled";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + reg = <1>;
> +
> + csi40vin4: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <>;
> + };
> + csi40vin5: endpoint@1 {
> + reg = <1>;
> + remote-endpoint = <>;
> + };
> + };
> + };
> + };
> +
> + vin4: video@e6ef4000 {
> + compatible = "renesas,vin-r8a77990";
> + reg = <0 0xe6ef4000 0 0x1000>;
> + interrupts = ;
> + clocks = < CPG_MOD 807>;
> + power-domains = < R8A77990_PD_ALWAYS_ON>;
> + resets = < 807>;
> + renesas,id = <4>;
> + status = "disabled";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@1 {
> + reg = <1>;
> +
> + vin4csi40: endpoint {
> + remote-endpoint= <>;
> + };
> + };
> + };
> + };
> +
> + vin5: video@e6ef5000 {
> + compatible = "renesas,vin-r8a77990";
> + reg = <0 0xe6ef5000 0 0x1000>;
> + interrupts = ;
> + clocks = < CPG_MOD 806>;
> + power-domains = < R8A77990_PD_ALWAYS_ON>;
> + resets = < 806>;
> + renesas,id = <5>;
> + status = "disabled";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@1 {
> + reg = <1>;
> +
> + vin5csi40: endpoint {
> + remote-endpoint= <>;
> + };
> + };
> + };
> + };
> +
> scif2: serial@e6e88000 {
> compatible = "renesas,scif-r8a77990",
>"renesas,rcar-gen3-scif", "renesas,scif";
--
Regards,
Laurent Pinchart
Re: [PATCH v2 4/8] media: rcar-csi2: Add R8A77990 support
Hi Jacopo,
Thank you for the patch.
On Wednesday, 5 September 2018 18:29:41 EEST Jacopo Mondi wrote:
> Add support for R-Car E3 R8A77965 to R-Car CSI-2 driver.
> Based on the experimental patch from Magnus Damm.
>
> Signed-off-by: Jacopo Mondi
Reviewed-by: Laurent Pinchart
> ---
> drivers/media/platform/rcar-vin/rcar-csi2.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-csi2.c
> b/drivers/media/platform/rcar-vin/rcar-csi2.c index dc5ae80..f82b668 100644
> --- a/drivers/media/platform/rcar-vin/rcar-csi2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-csi2.c
> @@ -959,6 +959,11 @@ static const struct rcar_csi2_info
> rcar_csi2_info_r8a77970 = { .confirm_start = rcsi2_confirm_start_v3m_e3,
> };
>
> +static const struct rcar_csi2_info rcar_csi2_info_r8a77990 = {
> + .init_phtw = rcsi2_init_phtw_v3m_e3,
> + .confirm_start = rcsi2_confirm_start_v3m_e3,
> +};
> +
> static const struct of_device_id rcar_csi2_of_table[] = {
> {
> .compatible = "renesas,r8a7795-csi2",
> @@ -976,6 +981,10 @@ static const struct of_device_id rcar_csi2_of_table[] =
> { .compatible = "renesas,r8a77970-csi2",
> .data = _csi2_info_r8a77970,
> },
> + {
> + .compatible = "renesas,r8a77990-csi2",
> + .data = _csi2_info_r8a77990,
> + },
> { /* sentinel */ },
> };
> MODULE_DEVICE_TABLE(of, rcar_csi2_of_table);
--
Regards,
Laurent Pinchart
Re: [PATCH v2 3/8] media: dt-bindings: rcar-csi2: Add R8A77990
Hi Jacopo, Thank you for the patch. On Wednesday, 5 September 2018 18:29:40 EEST Jacopo Mondi wrote: > Add compatible string for R-Car E3 R8A77990 to the list of supported SoCs. > > Signed-off-by: Jacopo Mondi > Reviewed-by: Rob Herring Reviewed-by: Laurent Pinchart > --- > Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt > b/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt index > 2d385b6..2824489 100644 > --- a/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt > +++ b/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt > @@ -12,6 +12,7 @@ Mandatory properties > - "renesas,r8a7796-csi2" for the R8A7796 device. > - "renesas,r8a77965-csi2" for the R8A77965 device. > - "renesas,r8a77970-csi2" for the R8A77970 device. > + - "renesas,r8a77990-csi2" for the R8A77990 device. > > - reg: the register base and size for the device registers > - interrupts: the interrupt for the device -- Regards, Laurent Pinchart
Re: [PATCH v2 2/8] media: rcar-vin: Add support for R-Car R8A77990
Hi Jacopo,
Thank you for the patch.
On Wednesday, 5 September 2018 18:29:39 EEST Jacopo Mondi wrote:
> Add R-Car E3 R8A77990 SoC to the rcar-vin supported ones.
> Based on the experimental patch from Magnus Damm.
>
> Signed-off-by: Jacopo Mondi
Reviewed-by: Laurent Pinchart
> ---
> drivers/media/platform/rcar-vin/rcar-core.c | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
> b/drivers/media/platform/rcar-vin/rcar-core.c index ce09799..d443c09 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -1085,6 +1085,22 @@ static const struct rvin_info rcar_info_r8a77970 = {
> .routes = rcar_info_r8a77970_routes,
> };
>
> +static const struct rvin_group_route rcar_info_r8a77990_routes[] = {
> + { .csi = RVIN_CSI40, .channel = 0, .vin = 4, .mask = BIT(0) | BIT(3) },
> + { .csi = RVIN_CSI40, .channel = 0, .vin = 5, .mask = BIT(2) },
> + { .csi = RVIN_CSI40, .channel = 1, .vin = 4, .mask = BIT(2) },
> + { .csi = RVIN_CSI40, .channel = 1, .vin = 5, .mask = BIT(1) | BIT(3) },
> + { /* Sentinel */ }
> +};
> +
> +static const struct rvin_info rcar_info_r8a77990 = {
> + .model = RCAR_GEN3,
> + .use_mc = true,
> + .max_width = 4096,
> + .max_height = 4096,
> + .routes = rcar_info_r8a77990_routes,
> +};
> +
> static const struct rvin_group_route rcar_info_r8a77995_routes[] = {
> { /* Sentinel */ }
> };
> @@ -1143,6 +1159,10 @@ static const struct of_device_id rvin_of_id_table[] =
> { .data = _info_r8a77970,
> },
> {
> + .compatible = "renesas,vin-r8a77990",
> + .data = _info_r8a77990,
> + },
> + {
> .compatible = "renesas,vin-r8a77995",
> .data = _info_r8a77995,
> },
--
Regards,
Laurent Pinchart
Re: [PATCH v2 1/8] media: dt-bindings: rcar-vin: Add R8A77990 support
Hi Jacopo, Thank you for the patch. On Wednesday, 5 September 2018 18:29:38 EEST Jacopo Mondi wrote: > Add compatible string for R-Car E3 R8A77990 to the list of SoCs supported by > rcar-vin driver. > > Signed-off-by: Jacopo Mondi > Reviewed-by: Rob Herring Reviewed-by: Laurent Pinchart > --- > Documentation/devicetree/bindings/media/rcar_vin.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt > b/Documentation/devicetree/bindings/media/rcar_vin.txt index > 2f42005..dfd6058 100644 > --- a/Documentation/devicetree/bindings/media/rcar_vin.txt > +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt > @@ -23,6 +23,7 @@ on Gen3 platforms to a CSI-2 receiver. > - "renesas,vin-r8a7796" for the R8A7796 device > - "renesas,vin-r8a77965" for the R8A77965 device > - "renesas,vin-r8a77970" for the R8A77970 device > + - "renesas,vin-r8a77990" for the R8A77990 device > - "renesas,vin-r8a77995" for the R8A77995 device > - "renesas,rcar-gen2-vin" for a generic R-Car Gen2 or RZ/G1 compatible > device. -- Regards, Laurent Pinchart
Re: [PATCH] arm64: dts: renesas: salvator-common: Add GPIO keys support
Hello, On Thursday, 6 September 2018 12:42:32 EEST Simon Horman wrote: > On Thu, Aug 23, 2018 at 11:58:54AM +0200, Geert Uytterhoeven wrote: > > On Sun, Aug 19, 2018 at 9:44 PM Laurent Pinchart wrote: > >> The Salvator-X and XS boards have a 4 lines DIP switch and 3 push > >> buttons connected to SoC GPIOs, meant to be used as general-purpose test > >> keys. Add a corresponding node in DT, mapping (semi-randomly) the DIP > >> switch to keys 1-4 and the push buttons to keys A-C. > >> > >> Signed-off-by: Laurent Pinchart > >> > > > > Given GP6_1[123] are not just wired to the 3 push buttons, but also to 3 > > LEDs, I wonder if we shouldn't postpone that part until Linux can handle > > GPIOs connected to both? > > Laurent, any thoughts on that? Right now the GPIOs are not wired in DT, and we're thus without a way to interface to both LEDs and push buttons. While I agree that an ideal solution would be to support both, I think that moving from nothing to support for push buttons would be a step forward already. -- Regards, Laurent Pinchart
Re: [PATCH v2 7/8] arm64: dts: r8a77990: Add I2C device nodes
Hi Jacopo,
Thank you for the patch.
On Wednesday, 5 September 2018 18:29:44 EEST Jacopo Mondi wrote:
> From: Takeshi Kihara
>
> Add device nodes for I2C ch[0-7] to R-Car E3 R8A77990 device tree.
>
> Signed-off-by: Takeshi Kihara
> Signed-off-by: Jacopo Mondi
> Reviewed-by: Geert Uytterhoeven
> Tested-by: Geert Uytterhoeven
Reviewed-by: Laurent Pinchart
Tested-by: Laurent Pinchart
Simon, could you take this in your tree for v4.20 without waiting for the
whole series to be ready ?
> ---
> arch/arm64/boot/dts/renesas/r8a77990.dtsi | 123 +++
> 1 file changed, 123 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> b/arch/arm64/boot/dts/renesas/r8a77990.dtsi index 0ae7bbe..a1badfe 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> @@ -14,6 +14,17 @@
> #address-cells = <2>;
> #size-cells = <2>;
>
> + aliases {
> + i2c0 =
> + i2c1 =
> + i2c2 =
> + i2c3 =
> + i2c4 =
> + i2c5 =
> + i2c6 =
> + i2c7 =
> + };
> +
> cpus {
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -185,6 +196,118 @@
> resets = < 906>;
> };
>
> + i2c0: i2c@e650 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "renesas,i2c-r8a77990",
> + "renesas,rcar-gen3-i2c";
> + reg = <0 0xe650 0 0x40>;
> + interrupts = ;
> + clocks = < CPG_MOD 931>;
> + power-domains = < R8A77990_PD_ALWAYS_ON>;
> + resets = < 931>;
> + i2c-scl-internal-delay-ns = <110>;
> + status = "disabled";
> + };
> +
> + i2c1: i2c@e6508000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "renesas,i2c-r8a77990",
> + "renesas,rcar-gen3-i2c";
> + reg = <0 0xe6508000 0 0x40>;
> + interrupts = ;
> + clocks = < CPG_MOD 930>;
> + power-domains = < R8A77990_PD_ALWAYS_ON>;
> + resets = < 930>;
> + i2c-scl-internal-delay-ns = <6>;
> + status = "disabled";
> + };
> +
> + i2c2: i2c@e651 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "renesas,i2c-r8a77990",
> + "renesas,rcar-gen3-i2c";
> + reg = <0 0xe651 0 0x40>;
> + interrupts = ;
> + clocks = < CPG_MOD 929>;
> + power-domains = < R8A77990_PD_ALWAYS_ON>;
> + resets = < 929>;
> + i2c-scl-internal-delay-ns = <6>;
> + status = "disabled";
> + };
> +
> + i2c3: i2c@e66d {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "renesas,i2c-r8a77990",
> + "renesas,rcar-gen3-i2c";
> + reg = <0 0xe66d 0 0x40>;
> + interrupts = ;
> + clocks = < CPG_MOD 928>;
> + power-domains = < R8A77990_PD_ALWAYS_ON>;
> + resets = < 928>;
> + i2c-scl-internal-delay-ns = <110>;
> + status = "disabled";
> + };
> +
> + i2c4: i2c@e66d8000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "renesas,i2c-r8a77990",
> + "renesas,rcar-gen3-i2c";
> + reg = <0 0xe66d8000 0 0x40>;
> + interrupts = ;
> + clocks = < CPG_MOD 927>;
> + power-domains = < R8A77990_PD_ALWAYS_ON>;
> + resets =
Re: vsps and channel indices (was: Re: [PATCH v3 1/2] arm64: dts: renesas: r8a77980: add FCPVD/VSPD/DU/LVDS support)
Hi Geert,
On Tuesday, 28 August 2018 15:10:52 EEST Geert Uytterhoeven wrote:
> Hi Sergei, Laurent, Kieran,
>
> On Wed, Jun 13, 2018 at 10:11 PM Sergei Shtylyov wrote:
> > Describe the interconnected FCPVD0, VSPD0, DU, and LVDS0 devices in the
> > R8A77980 device tree...
> >
> > Based on the original (and large) patch by Vladimir Barinov.
> >
> > Signed-off-by: Vladimir Barinov
> > Signed-off-by: Sergei Shtylyov
> > Reviewed-by: Laurent Pinchart
> >
> > --- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
> > +++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
> >
> > + du: display@feb0 {
> > + compatible = "renesas,du-r8a77980",
> > +"renesas,du-r8a77970";
> > + reg = <0 0xfeb0 0 0x8>;
> > + interrupts = ;
> > + clocks = < CPG_MOD 724>;
> > + clock-names = "du.0";
> > + power-domains = < R8A77980_PD_ALWAYS_ON>;
> > + resets = < 724>;
> > + vsps = <>;
>
> According to the bindings, the vsps property should also contain a
> channel index.
>
> Laurent added the indices to r8a7795.dtsi, but r8a7795-es.dtsi overrides
> that with a version without the indices.
> Kieran included the indices when adding DU support for r8a77965 and
> r8a77995.
>
> r8a7796.dtsi, r8a77970.dtsi, and r8a77980.dtsi lack the indices.
>
> Commit fd57d77f9c649cf9 ("dt-bindings: display: rcar-du: Add a VSP channel
> index to the vsps DT property") says a backwards-compatibility mode can be
> implemented, but I fail to see how this can work, as rcar_du_vsps_init()
> will just return an error, which is propagated.
>
> What am I missing?
We're missing a DT validator :-/
The vsps property shoould indeed contain indices. However, rcar_du_vsps_init()
implements a backward-compatibility mode by checking the length of the
property:
cells = of_property_count_u32_elems(np, "vsps") / rcdu->num_crtcs - 1;
and using that as an argument to of_parse_phandle_with_fixed_args().
--
Regards,
Laurent Pinchart
[PATCH v2] pinctrl: sh-pfc: r8a77990: Add DU pins, groups and function
This patch adds DU pins, groups and function for the R8A77990 (E3) SoC.
Signed-off-by: Laurent Pinchart
---
Changes since v1:
- Add DU_CLKIN0
---
drivers/pinctrl/sh-pfc/pfc-r8a77990.c | 110 ++
1 file changed, 110 insertions(+)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
index b81c807ac54d..bb9c943e2b37 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
@@ -1371,6 +1371,94 @@ static const unsigned int avb_avtp_capture_a_mux[] = {
AVB_AVTP_CAPTURE_A_MARK,
};
+/* - DU -
*/
+static const unsigned int du_rgb666_pins[] = {
+ /* R[7:2], G[7:2], B[7:2] */
+ RCAR_GP_PIN(0, 8), RCAR_GP_PIN(0, 6), RCAR_GP_PIN(0, 5),
+ RCAR_GP_PIN(0, 3), RCAR_GP_PIN(0, 2), RCAR_GP_PIN(0, 0),
+ RCAR_GP_PIN(1, 9), RCAR_GP_PIN(1, 12), RCAR_GP_PIN(1, 10),
+ RCAR_GP_PIN(1, 4), RCAR_GP_PIN(0, 15), RCAR_GP_PIN(0, 11),
+ RCAR_GP_PIN(0, 1), RCAR_GP_PIN(1, 17), RCAR_GP_PIN(1, 16),
+ RCAR_GP_PIN(1, 15), RCAR_GP_PIN(1, 14), RCAR_GP_PIN(1, 13),
+};
+static const unsigned int du_rgb666_mux[] = {
+ DU_DR7_MARK, DU_DR6_MARK, DU_DR5_MARK, DU_DR4_MARK,
+ DU_DR3_MARK, DU_DR2_MARK,
+ DU_DG7_MARK, DU_DG6_MARK, DU_DG5_MARK, DU_DG4_MARK,
+ DU_DG3_MARK, DU_DG2_MARK,
+ DU_DB7_MARK, DU_DB6_MARK, DU_DB5_MARK, DU_DB4_MARK,
+ DU_DB3_MARK, DU_DB2_MARK,
+};
+static const unsigned int du_rgb888_pins[] = {
+ /* R[7:0], G[7:0], B[7:0] */
+ RCAR_GP_PIN(0, 8), RCAR_GP_PIN(0, 6), RCAR_GP_PIN(0, 5),
+ RCAR_GP_PIN(0, 3), RCAR_GP_PIN(0, 2), RCAR_GP_PIN(0, 0),
+ RCAR_GP_PIN(1, 22), RCAR_GP_PIN(1, 21),
+ RCAR_GP_PIN(1, 9), RCAR_GP_PIN(1, 12), RCAR_GP_PIN(1, 10),
+ RCAR_GP_PIN(1, 4), RCAR_GP_PIN(0, 15), RCAR_GP_PIN(0, 11),
+ RCAR_GP_PIN(0, 10), RCAR_GP_PIN(0, 9),
+ RCAR_GP_PIN(0, 1), RCAR_GP_PIN(1, 17), RCAR_GP_PIN(1, 16),
+ RCAR_GP_PIN(1, 15), RCAR_GP_PIN(1, 14), RCAR_GP_PIN(1, 13),
+ RCAR_GP_PIN(1, 19), RCAR_GP_PIN(1, 18),
+};
+static const unsigned int du_rgb888_mux[] = {
+ DU_DR7_MARK, DU_DR6_MARK, DU_DR5_MARK, DU_DR4_MARK,
+ DU_DR3_MARK, DU_DR2_MARK, DU_DR1_MARK, DU_DR0_MARK,
+ DU_DG7_MARK, DU_DG6_MARK, DU_DG5_MARK, DU_DG4_MARK,
+ DU_DG3_MARK, DU_DG2_MARK, DU_DG1_MARK, DU_DG0_MARK,
+ DU_DB7_MARK, DU_DB6_MARK, DU_DB5_MARK, DU_DB4_MARK,
+ DU_DB3_MARK, DU_DB2_MARK, DU_DB1_MARK, DU_DB0_MARK,
+};
+static const unsigned int du_clk_in_0_pins[] = {
+ /* CLKIN0 */
+ RCAR_GP_PIN(0, 16),
+};
+static const unsigned int du_clk_in_0_mux[] = {
+ DU_DOTCLKIN0_MARK
+};
+static const unsigned int du_clk_in_1_pins[] = {
+ /* CLKIN1 */
+ RCAR_GP_PIN(1, 1),
+};
+static const unsigned int du_clk_in_1_mux[] = {
+ DU_DOTCLKIN1_MARK
+};
+static const unsigned int du_clk_out_0_pins[] = {
+ /* CLKOUT */
+ RCAR_GP_PIN(1, 3),
+};
+static const unsigned int du_clk_out_0_mux[] = {
+ DU_DOTCLKOUT0_MARK
+};
+static const unsigned int du_sync_pins[] = {
+ /* VSYNC, HSYNC */
+ RCAR_GP_PIN(1, 11), RCAR_GP_PIN(1, 8),
+};
+static const unsigned int du_sync_mux[] = {
+ DU_VSYNC_MARK, DU_HSYNC_MARK
+};
+static const unsigned int du_disp_cde_pins[] = {
+ /* DISP_CDE */
+ RCAR_GP_PIN(1, 1),
+};
+static const unsigned int du_disp_cde_mux[] = {
+ DU_DISP_CDE_MARK,
+};
+static const unsigned int du_cde_pins[] = {
+ /* CDE */
+ RCAR_GP_PIN(1, 0),
+};
+static const unsigned int du_cde_mux[] = {
+ DU_CDE_MARK,
+};
+static const unsigned int du_disp_pins[] = {
+ /* DISP */
+ RCAR_GP_PIN(1, 2),
+};
+static const unsigned int du_disp_mux[] = {
+ DU_DISP_MARK,
+};
+
/* - I2C
*/
static const unsigned int i2c1_a_pins[] = {
/* SCL, SDA */
@@ -1839,6 +1927,15 @@ static const struct sh_pfc_pin_group pinmux_groups[] = {
SH_PFC_PIN_GROUP(avb_avtp_pps),
SH_PFC_PIN_GROUP(avb_avtp_match_a),
SH_PFC_PIN_GROUP(avb_avtp_capture_a),
+ SH_PFC_PIN_GROUP(du_rgb666),
+ SH_PFC_PIN_GROUP(du_rgb888),
+ SH_PFC_PIN_GROUP(du_clk_in_0),
+ SH_PFC_PIN_GROUP(du_clk_in_1),
+ SH_PFC_PIN_GROUP(du_clk_out_0),
+ SH_PFC_PIN_GROUP(du_sync),
+ SH_PFC_PIN_GROUP(du_disp_cde),
+ SH_PFC_PIN_GROUP(du_cde),
+ SH_PFC_PIN_GROUP(du_disp),
SH_PFC_PIN_GROUP(i2c1_a),
SH_PFC_PIN_GROUP(i2c1_b),
SH_PFC_PIN_GROUP(i2c1_c),
@@ -1901,6 +1998,18 @@ static const char * const avb_groups[] = {
"avb_avtp_capture_a",
};
+static const char * const du_groups[] = {
+ "du_rgb666",
+ "du_rgb888",
+ "du_clk_in_0",
+ "du_clk_in_1",
+ "du_clk_out_0",
+ "du_sync",
+ "
Re: [PATCH] pinctrl: sh-pfc: r8a77990: Add DU pins, groups and function
Hi Geert,
On Tuesday, 28 August 2018 11:41:00 EEST Geert Uytterhoeven wrote:
> On Thu, Aug 23, 2018 at 9:09 AM Laurent Pinchart wrote:
> > This patch adds DU pins, groups and function for the R8A77990 (E3) SoC.
> >
> > Signed-off-by: Laurent Pinchart
> >
>
> Thanks for your patch!
>
> > --- a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
> > +++ b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
> > @@ -1371,6 +1371,87 @@ static const unsigned int avb_avtp_capture_a_mux[]
> > = {>
> > AVB_AVTP_CAPTURE_A_MARK,
> >
> > };
> >
> > +/* - DU
> > - */
> > +static const unsigned int du_rgb666_pins[] = {
> > + /* R[7:2], G[7:2], B[7:2] */
> > + RCAR_GP_PIN(0, 8), RCAR_GP_PIN(0, 6), RCAR_GP_PIN(0, 5),
> > + RCAR_GP_PIN(0, 3), RCAR_GP_PIN(0, 2), RCAR_GP_PIN(0, 0),
> > + RCAR_GP_PIN(1, 9), RCAR_GP_PIN(1, 12), RCAR_GP_PIN(1, 10),
> > + RCAR_GP_PIN(1, 4), RCAR_GP_PIN(0, 15), RCAR_GP_PIN(0, 11),
> > + RCAR_GP_PIN(0, 1), RCAR_GP_PIN(1, 17), RCAR_GP_PIN(1, 16),
> > + RCAR_GP_PIN(1, 15), RCAR_GP_PIN(1, 14), RCAR_GP_PIN(1, 13),
> > +};
> > +static const unsigned int du_rgb666_mux[] = {
> > + DU_DR7_MARK, DU_DR6_MARK, DU_DR5_MARK, DU_DR4_MARK,
> > + DU_DR3_MARK, DU_DR2_MARK,
> > + DU_DG7_MARK, DU_DG6_MARK, DU_DG5_MARK, DU_DG4_MARK,
> > + DU_DG3_MARK, DU_DG2_MARK,
> > + DU_DB7_MARK, DU_DB6_MARK, DU_DB5_MARK, DU_DB4_MARK,
> > + DU_DB3_MARK, DU_DB2_MARK,
> > +};
> > +static const unsigned int du_rgb888_pins[] = {
> > + /* R[7:0], G[7:0], B[7:0] */
> > + RCAR_GP_PIN(0, 8), RCAR_GP_PIN(0, 6), RCAR_GP_PIN(0, 5),
> > + RCAR_GP_PIN(0, 3), RCAR_GP_PIN(0, 2), RCAR_GP_PIN(0, 0),
> > + RCAR_GP_PIN(1, 22), RCAR_GP_PIN(1, 21),
> > + RCAR_GP_PIN(1, 9), RCAR_GP_PIN(1, 12), RCAR_GP_PIN(1, 10),
> > + RCAR_GP_PIN(1, 4), RCAR_GP_PIN(0, 15), RCAR_GP_PIN(0, 11),
> > + RCAR_GP_PIN(0, 10), RCAR_GP_PIN(0, 9),
> > + RCAR_GP_PIN(0, 1), RCAR_GP_PIN(1, 17), RCAR_GP_PIN(1, 16),
> > + RCAR_GP_PIN(1, 15), RCAR_GP_PIN(1, 14), RCAR_GP_PIN(1, 13),
> > + RCAR_GP_PIN(1, 19), RCAR_GP_PIN(1, 18),
> > +};
> > +static const unsigned int du_rgb888_mux[] = {
> > + DU_DR7_MARK, DU_DR6_MARK, DU_DR5_MARK, DU_DR4_MARK,
> > + DU_DR3_MARK, DU_DR2_MARK, DU_DR1_MARK, DU_DR0_MARK,
> > + DU_DG7_MARK, DU_DG6_MARK, DU_DG5_MARK, DU_DG4_MARK,
> > + DU_DG3_MARK, DU_DG2_MARK, DU_DG1_MARK, DU_DG0_MARK,
> > + DU_DB7_MARK, DU_DB6_MARK, DU_DB5_MARK, DU_DB4_MARK,
> > + DU_DB3_MARK, DU_DB2_MARK, DU_DB1_MARK, DU_DB0_MARK,
> > +};
> > +static const unsigned int du_clk_in_1_pins[] = {
> > + /* CLKIN */
> > + RCAR_GP_PIN(1, 1),
> > +};
> > +static const unsigned int du_clk_in_1_mux[] = {
> > + DU_DOTCLKIN1_MARK
> > +};
>
> Missing du_clk_in_0 (GP0_16)?
Indeed. v2 is on its way.
--
Regards,
Laurent Pinchart
Re: [RFT 0/8] arm64: dts: renesas: Ebisu: Add HDMI and CVBS input
Hi Niklas, On Monday, 27 August 2018 16:23:45 EEST Niklas Söderlund wrote: > On 2018-08-27 11:49:56 +0200, Jacopo Mondi wrote: > > On Sat, Aug 25, 2018 at 03:18:06PM +0200, jacopo mondi wrote: > >> On Sat, Aug 25, 2018 at 08:37:15AM +0200, Niklas Söderlund wrote: > >>> On 2018-08-25 02:54:44 +0300, Laurent Pinchart wrote: > >>>> On Monday, 20 August 2018 13:16:34 EEST Jacopo Mondi wrote: > >>>>> Hello renesas list, > >>>>> > >>>>> this series add supports for the HDMI and CVBS input to R-Car > >>>>> E3 R8A77990 Ebisu board. > >>>>> > >>>>> It's an RFT, as I don't have an Ebisu to test with :( > >>>>> > >>>>> The series adds supports for the following items: > >>>>> > >>>>> - PFC: add VIN groups and functions > >>>>> - R-Car VIN and R-Car CSI-2: add support for R8A77990 > >>>>> - R8A77990: Add I2C, VIN and CSI-2 nodes > >>>>> - Ebisu: describe HDMI and CVBS inputs > >>>>> > >>>>> Each patch, when relevant reports difference between the upported > >>>>> BSP patch and the proposed one. > >>>>> > >>>>> I know Laurent should receive an Ebisu sooner or later, maybe we > >>>>> can sync for testing :) > >>>> > >>>> I've given the series a first test, and I think a bit more work is > >>>> needed :-) > >>>> > >>>> [1.455533] adv748x 0-0070: Endpoint > >>>> /soc/i2c@e650/video-receiver@70/ port@7/endpoint on port 7 > >>>> [1.464683] adv748x 0-0070: Endpoint > >>>> /soc/i2c@e650/video-receiver@70/ port@8/endpoint on port 8 > >>>> [1.473728] adv748x 0-0070: Endpoint > >>>> /soc/i2c@e650/video-receiver@70/ port@a/endpoint on port 10 > >>>> [1.484835] adv748x 0-0070: chip found @ 0xe0 revision 2143 > >>>> [1.639470] adv748x 0-0070: No endpoint found for txb > >>>> [1.644653] adv748x 0-0070: Failed to probe TXB > >>> > >>> I fear this is a design choice in the adv748x driver. Currently the > >>> driver requires both of its two CSI-2 transmitters to be > >>> connected/used else probe fails. Furthermore the HDMI capture is always > >>> routed to TXA while the analog capture is always routed to TXB. > >>> > >>> Now that we have a board where only TXA is connected but both HDMI and > >>> analog captures are used maybe it's time to do some more work on v4l2 > >>> and the adv748x driver ;-P What's missing: > >>> > >>> - Probe should be OK with either TXA or TXB connected and not bail if > >>> not both are used. > >> > >> I have three patches for this I hope to share as soon as I'll be able > >> to do some more testing > >> > >>> - The media_device_ops or at least the .link_notify() callback of that > >>> struct must be changed so not one driver in the media graph is > >>> responsible for all links. In this case rcar-vin provides the > >>> callback and rcar-vin should not judge which links between the > >>> adv748x subdevices are OK to enable/disable. Currently the links > >>> between the adv748x subdevices are immutably enabled to avoid this > >>> particular problem. > >> > >> Uh, I didn't get this :/ Care to elaborate more? > > > > I'm thinking if it is not enough to just provide a .link_setup() > > callback to the (enabled) csi-2 sink pads of the adv748x and handle > > routing between the afe/hdmi sources and that sink, without the vin's > > registered link_notify playing any role in that. > > That is my point, the v4l2 framework needs work to allow all drivers to > provide a .link_setup() callback. And this as you describe will conflict > with the current solution where there is only one possible such > callback. So in addition to being able to have multiple such callbacks > the current drivers implementing one would need to be updated to ignore > links which it do not care about. Isn't this already possible ? We have a single top-level .link_notify() operation at the media device level, but also .link_setup() operations for each entity. > In our case the .link_setup() in rcar-vin should not care about the > links between the adv748x internal subdevice. Of course the other way > around is also true, the .link_setup() in adv748x should
Re: [PATCH 1/2] arm64: dts: r8a77965: add FDP1 device nodes
Hi Simon, On Monday, 27 August 2018 15:57:05 EEST Simon Horman wrote: > On Fri, Aug 24, 2018 at 11:45:52AM +0300, Laurent Pinchart wrote: > > On Friday, 24 August 2018 07:52:28 EEST Nguyen An Hoan wrote: > > > From: Hoan Nguyen An > > > > You're missing a commit message. I agree that for simple patches like this > > one the subject line often contains enough information, but adding a > > commit message is still a good practice that we try to enforce through > > the kernel. For instance, looking at git history for r8a7796, you could > > use > > > > "The r8a77965 has a single FDP1 instance." > > > > > Signed-off-by: Hoan Nguyen An > > > > Apart from that, > > > > Reviewed-by: Laurent Pinchart > > > > Simon, could you update the commit message when taking this patch in your > > tree, to avoid the need for a v2 ? > > Yes, can do. > > Can I confirm that it is safe, from a regression point of view, > to apply this patch without patch 2/2? As far as I know it is safe, yes. -- Regards, Laurent Pinchart
Re: [RFT 0/8] arm64: dts: renesas: Ebisu: Add HDMI and CVBS input
Hi Jacopo, On Monday, 20 August 2018 13:16:34 EEST Jacopo Mondi wrote: > Hello renesas list, >this series add supports for the HDMI and CVBS input to R-Car E3 R8A77990 > Ebisu board. > > It's an RFT, as I don't have an Ebisu to test with :( > > The series adds supports for the following items: > > - PFC: add VIN groups and functions > - R-Car VIN and R-Car CSI-2: add support for R8A77990 > - R8A77990: Add I2C, VIN and CSI-2 nodes > - Ebisu: describe HDMI and CVBS inputs > > Each patch, when relevant reports difference between the upported BSP patch > and the proposed one. > > I know Laurent should receive an Ebisu sooner or later, maybe we can sync > for testing :) I've given the series a first test, and I think a bit more work is needed :-) [1.455533] adv748x 0-0070: Endpoint /soc/i2c@e650/video-receiver@70/ port@7/endpoint on port 7 [1.464683] adv748x 0-0070: Endpoint /soc/i2c@e650/video-receiver@70/ port@8/endpoint on port 8 [1.473728] adv748x 0-0070: Endpoint /soc/i2c@e650/video-receiver@70/ port@a/endpoint on port 10 [1.484835] adv748x 0-0070: chip found @ 0xe0 revision 2143 [1.639470] adv748x 0-0070: No endpoint found for txb [1.644653] adv748x 0-0070: Failed to probe TXB > PS: the list of upported patches will be sent separately. > > Jacopo Mondi (5): > media: dt-bindings: media: rcar-vin: Add R8A77990 support > media: rcar-vin: Add support for R-Car R8A77990 > dt-bindings: media: rcar-csi2: Add R8A77990 > media: rcar-csi2: Add R8A77990 support > arm64: dts: renesas: ebisu: Add HDMI and CVBS input > > Koji Matsuoka (1): > arm64: dts: r8a77990: Add VIN and CSI-2 device nodes > > Takeshi Kihara (2): > pinctrl: sh-pfc: r8a77990: Add VIN pins, groups and functions > arm64: dts: r8a77990: Add I2C device nodes > > .../devicetree/bindings/media/rcar_vin.txt | 1 + > .../bindings/media/renesas,rcar-csi2.txt | 1 + > arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts | 86 > arch/arm64/boot/dts/renesas/r8a77990.dtsi | 202 + > drivers/media/platform/rcar-vin/rcar-core.c| 20 + > drivers/media/platform/rcar-vin/rcar-csi2.c| 9 + > drivers/pinctrl/sh-pfc/pfc-r8a77990.c | 504 ++ > 7 files changed, 823 insertions(+) -- Regards, Laurent Pinchart
Re: [PATCH 2/2] clk: renesas: r8a77965: Add FDP clock
Hello Nguyen An,
Thank you for the patch.
On Friday, 24 August 2018 07:52:29 EEST Nguyen An Hoan wrote:
> From: Hoan Nguyen An
Here too a commit message would be nice.
> Signed-off-by: Hoan Nguyen An
> ---
> drivers/clk/renesas/r8a77965-cpg-mssr.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/clk/renesas/r8a77965-cpg-mssr.c
> b/drivers/clk/renesas/r8a77965-cpg-mssr.c index 312f9fe..d0847dc 100644
> --- a/drivers/clk/renesas/r8a77965-cpg-mssr.c
> +++ b/drivers/clk/renesas/r8a77965-cpg-mssr.c
> @@ -112,6 +112,7 @@ static const struct cpg_core_clk r8a77965_core_clks[]
> __initconst = { };
>
> static const struct mssr_mod_clk r8a77965_mod_clks[] __initconst = {
> + DEF_MOD("fdp0", 119,R8A77965_CLK_S0D1),
I haven't found information in the datasheet to confirm whether the parent
clock is correct. As it doesn't matter too much given that the parent clock
doesn't need to be controlled, and the FDP driver doesn't care about the clock
frequency, we can start with this without any problem.
Reviewed-by: Laurent Pinchart
> DEF_MOD("scif5",202,R8A77965_CLK_S3D4),
> DEF_MOD("scif4",203,R8A77965_CLK_S3D4),
> DEF_MOD("scif3",204,R8A77965_CLK_S3D4),
--
Regards,
Laurent Pinchart
Re: [PATCH 1/2] arm64: dts: r8a77965: add FDP1 device nodes
Hello Nguyen An,
Thank you for the patch.
On Friday, 24 August 2018 07:52:28 EEST Nguyen An Hoan wrote:
> From: Hoan Nguyen An
You're missing a commit message. I agree that for simple patches like this one
the subject line often contains enough information, but adding a commit
message is still a good practice that we try to enforce through the kernel.
For instance, looking at git history for r8a7796, you could use
"The r8a77965 has a single FDP1 instance."
> Signed-off-by: Hoan Nguyen An
Apart from that,
Reviewed-by: Laurent Pinchart
Simon, could you update the commit message when taking this patch in your
tree, to avoid the need for a v2 ?
> ---
> arch/arm64/boot/dts/renesas/r8a77965.dtsi | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
> b/arch/arm64/boot/dts/renesas/r8a77965.dtsi index 9c4f405..bef519f 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
> @@ -1578,6 +1578,16 @@
> status = "disabled";
> };
>
> + fdp1@fe94 {
> + compatible = "renesas,fdp1";
> + reg = <0 0xfe94 0 0x2400>;
> + interrupts = ;
> + clocks = < CPG_MOD 119>;
> + power-domains = < R8A77965_PD_A3VP>;
> + resets = < 119>;
> + renesas,fcp = <>;
> + };
> +
> fcpf0: fcp@fe950000 {
> compatible = "renesas,fcpf";
> reg = <0 0xfe95 0 0x200>;
--
Regards,
Laurent Pinchart
[PATCH] pinctrl: sh-pfc: r8a77990: Add DU pins, groups and function
This patch adds DU pins, groups and function for the R8A77990 (E3) SoC.
Signed-off-by: Laurent Pinchart
---
drivers/pinctrl/sh-pfc/pfc-r8a77990.c | 101 ++
1 file changed, 101 insertions(+)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
index b81c807ac54d..00769ec9635e 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
@@ -1371,6 +1371,87 @@ static const unsigned int avb_avtp_capture_a_mux[] = {
AVB_AVTP_CAPTURE_A_MARK,
};
+/* - DU -
*/
+static const unsigned int du_rgb666_pins[] = {
+ /* R[7:2], G[7:2], B[7:2] */
+ RCAR_GP_PIN(0, 8), RCAR_GP_PIN(0, 6), RCAR_GP_PIN(0, 5),
+ RCAR_GP_PIN(0, 3), RCAR_GP_PIN(0, 2), RCAR_GP_PIN(0, 0),
+ RCAR_GP_PIN(1, 9), RCAR_GP_PIN(1, 12), RCAR_GP_PIN(1, 10),
+ RCAR_GP_PIN(1, 4), RCAR_GP_PIN(0, 15), RCAR_GP_PIN(0, 11),
+ RCAR_GP_PIN(0, 1), RCAR_GP_PIN(1, 17), RCAR_GP_PIN(1, 16),
+ RCAR_GP_PIN(1, 15), RCAR_GP_PIN(1, 14), RCAR_GP_PIN(1, 13),
+};
+static const unsigned int du_rgb666_mux[] = {
+ DU_DR7_MARK, DU_DR6_MARK, DU_DR5_MARK, DU_DR4_MARK,
+ DU_DR3_MARK, DU_DR2_MARK,
+ DU_DG7_MARK, DU_DG6_MARK, DU_DG5_MARK, DU_DG4_MARK,
+ DU_DG3_MARK, DU_DG2_MARK,
+ DU_DB7_MARK, DU_DB6_MARK, DU_DB5_MARK, DU_DB4_MARK,
+ DU_DB3_MARK, DU_DB2_MARK,
+};
+static const unsigned int du_rgb888_pins[] = {
+ /* R[7:0], G[7:0], B[7:0] */
+ RCAR_GP_PIN(0, 8), RCAR_GP_PIN(0, 6), RCAR_GP_PIN(0, 5),
+ RCAR_GP_PIN(0, 3), RCAR_GP_PIN(0, 2), RCAR_GP_PIN(0, 0),
+ RCAR_GP_PIN(1, 22), RCAR_GP_PIN(1, 21),
+ RCAR_GP_PIN(1, 9), RCAR_GP_PIN(1, 12), RCAR_GP_PIN(1, 10),
+ RCAR_GP_PIN(1, 4), RCAR_GP_PIN(0, 15), RCAR_GP_PIN(0, 11),
+ RCAR_GP_PIN(0, 10), RCAR_GP_PIN(0, 9),
+ RCAR_GP_PIN(0, 1), RCAR_GP_PIN(1, 17), RCAR_GP_PIN(1, 16),
+ RCAR_GP_PIN(1, 15), RCAR_GP_PIN(1, 14), RCAR_GP_PIN(1, 13),
+ RCAR_GP_PIN(1, 19), RCAR_GP_PIN(1, 18),
+};
+static const unsigned int du_rgb888_mux[] = {
+ DU_DR7_MARK, DU_DR6_MARK, DU_DR5_MARK, DU_DR4_MARK,
+ DU_DR3_MARK, DU_DR2_MARK, DU_DR1_MARK, DU_DR0_MARK,
+ DU_DG7_MARK, DU_DG6_MARK, DU_DG5_MARK, DU_DG4_MARK,
+ DU_DG3_MARK, DU_DG2_MARK, DU_DG1_MARK, DU_DG0_MARK,
+ DU_DB7_MARK, DU_DB6_MARK, DU_DB5_MARK, DU_DB4_MARK,
+ DU_DB3_MARK, DU_DB2_MARK, DU_DB1_MARK, DU_DB0_MARK,
+};
+static const unsigned int du_clk_in_1_pins[] = {
+ /* CLKIN */
+ RCAR_GP_PIN(1, 1),
+};
+static const unsigned int du_clk_in_1_mux[] = {
+ DU_DOTCLKIN1_MARK
+};
+static const unsigned int du_clk_out_0_pins[] = {
+ /* CLKOUT */
+ RCAR_GP_PIN(1, 3),
+};
+static const unsigned int du_clk_out_0_mux[] = {
+ DU_DOTCLKOUT0_MARK
+};
+static const unsigned int du_sync_pins[] = {
+ /* VSYNC, HSYNC */
+ RCAR_GP_PIN(1, 11), RCAR_GP_PIN(1, 8),
+};
+static const unsigned int du_sync_mux[] = {
+ DU_VSYNC_MARK, DU_HSYNC_MARK
+};
+static const unsigned int du_disp_cde_pins[] = {
+ /* DISP_CDE */
+ RCAR_GP_PIN(1, 1),
+};
+static const unsigned int du_disp_cde_mux[] = {
+ DU_DISP_CDE_MARK,
+};
+static const unsigned int du_cde_pins[] = {
+ /* CDE */
+ RCAR_GP_PIN(1, 0),
+};
+static const unsigned int du_cde_mux[] = {
+ DU_CDE_MARK,
+};
+static const unsigned int du_disp_pins[] = {
+ /* DISP */
+ RCAR_GP_PIN(1, 2),
+};
+static const unsigned int du_disp_mux[] = {
+ DU_DISP_MARK,
+};
+
/* - I2C
*/
static const unsigned int i2c1_a_pins[] = {
/* SCL, SDA */
@@ -1839,6 +1920,14 @@ static const struct sh_pfc_pin_group pinmux_groups[] = {
SH_PFC_PIN_GROUP(avb_avtp_pps),
SH_PFC_PIN_GROUP(avb_avtp_match_a),
SH_PFC_PIN_GROUP(avb_avtp_capture_a),
+ SH_PFC_PIN_GROUP(du_rgb666),
+ SH_PFC_PIN_GROUP(du_rgb888),
+ SH_PFC_PIN_GROUP(du_clk_in_1),
+ SH_PFC_PIN_GROUP(du_clk_out_0),
+ SH_PFC_PIN_GROUP(du_sync),
+ SH_PFC_PIN_GROUP(du_disp_cde),
+ SH_PFC_PIN_GROUP(du_cde),
+ SH_PFC_PIN_GROUP(du_disp),
SH_PFC_PIN_GROUP(i2c1_a),
SH_PFC_PIN_GROUP(i2c1_b),
SH_PFC_PIN_GROUP(i2c1_c),
@@ -1901,6 +1990,17 @@ static const char * const avb_groups[] = {
"avb_avtp_capture_a",
};
+static const char * const du_groups[] = {
+ "du_rgb666",
+ "du_rgb888",
+ "du_clk_in_1",
+ "du_clk_out_0",
+ "du_sync",
+ "du_disp_cde",
+ "du_cde",
+ "du_disp",
+};
+
static const char * const i2c1_groups[] = {
"i2c1_a",
"i2c1_b",
@@ -1998,6 +2098,7 @@ static const char * const usb30_groups[] = {
static const struct sh_pfc_function
Re: [RFC/RTF] drm: rcar-du: lvds: Handle LVDS interface reset
Hello Jacopo,
Thank you for the patch.
On Wednesday, 1 August 2018 17:26:36 EEST Jacopo Mondi wrote:
> The processor manual prescribes to clear reset of LVDS interface in CPG/MSSR
> module before display on, and to assert the same reset line at display off
> time, to have the module resuming in a known state.
>
> The module is said to be in "standby state" at initialization time, and this
> requires, according to section 37.3.7 of the manual, to de-assert the reset
> to have it functional.
>
> Based on the original patch from
> Koji Matsuoka
>
> Signed-off-by: Jacopo Mondi
>
> ---
> This patch upports commit:
> https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/commit
> / ?id=23b62b82a5a705d28ddac1d973ee98e6f51d54ea
>
> Even without this patch the LVDS interface has been succesfully tested on
> V3M/Eagle boards, and this makes me wonder on the real need for reset to
> be handled by the driver.
>
> I've been able to 'test' the reset assertion/deassertion on Draak, whose
> LVDS interface is not yet being enabled due to missing LVDS PLL support. If
> someone with a V3M/Eagle could test this to make sure this doesn't break
> anything, we can then discuss on the real need for this patch to be
> mainlined.
>
> Also, a series of patches to add reset to R8A7795/R8A7796/R8A77965 LVDS
> device nodes will be upported if this patch is considered useful.
I think we can upstream DT changes regardless of whether we merge this patch,
as the reset lines exist, so it makes sense to have them in DT.
> For the interested ones (Laurent, Geert) reset de-assertion at display on
> time takes in average a hundreds of micro seconds.
Not very long, but still, if not need, I'd rather avoid it.
My understanding is that resetting the LVDS encoder is recommended "just in
case" something goes wrong, but isn't needed in the general case. The question
is thus in my opinion whether something can go wrong if we otherwise handle
the LVDS controller according to the recommended procedure.
> drivers/gpu/drm/rcar-du/rcar_lvds.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> b/drivers/gpu/drm/rcar-du/rcar_lvds.c index 20e8c34..acf4238 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include
> @@ -53,6 +54,7 @@ struct rcar_lvds {
>
> void __iomem *mmio;
> struct clk *clock;
> + struct reset_control *rst;
> bool enabled;
>
> struct drm_display_mode display_mode;
> @@ -175,6 +177,12 @@ static void rcar_lvds_enable(struct drm_bridge *bridge)
> if (ret < 0)
> return;
>
> + ret = reset_control_deassert(lvds->rst);
> + if (ret < 0) {
> + clk_disable_unprepare(lvds->clock);
> + return;
> + }
> +
> /*
>* Hardcode the channels and control signals routing for now.
>*
> @@ -265,6 +273,7 @@ static void rcar_lvds_disable(struct drm_bridge *bridge)
> rcar_lvds_write(lvds, LVDCR0, 0);
> rcar_lvds_write(lvds, LVDCR1, 0);
>
> + reset_control_assert(lvds->rst);
> clk_disable_unprepare(lvds->clock);
>
> lvds->enabled = false;
> @@ -481,6 +490,12 @@ static int rcar_lvds_probe(struct platform_device
> *pdev) return PTR_ERR(lvds->clock);
> }
>
> + lvds->rst = devm_reset_control_get_optional_exclusive(>dev, NULL);
> + if (IS_ERR(lvds->rst)) {
> + dev_err(>dev, "failed to get reset\n");
> + return PTR_ERR(lvds->rst);
> + }
> +
> drm_bridge_add(>bridge);
>
> return 0;
--
Regards,
Laurent Pinchart
Re: [PATCH 2/3] drm: rcar-du: Rename var to a more precise name
Hi Jacopo,
Thank you for the patch.
On Monday, 30 July 2018 20:20:13 EEST Jacopo Mondi wrote:
> Rename the 'value' variable, only used to for writing to DMSR register to a
> more precise 'dmsr' name.
>
> Signed-off-by: Laurent Pinchart
> Signed-off-by: Jacopo Mondi
I think this simple change can be squashed with patch 1/3.
> ---
> drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c index 6d55cec..4d7907c 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> @@ -208,7 +208,7 @@ static void rcar_du_crtc_set_display_timing(struct
> rcar_du_crtc *rcrtc) const struct drm_display_mode *mode =
> >crtc.state->adjusted_mode; struct rcar_du_device *rcdu =
> rcrtc->group->dev;
> unsigned long mode_clock = mode->clock * 1000;
> - u32 value;
> + u32 dsmr;
> u32 escr;
>
> if (rcdu->info->dpll_ch & (1 << rcrtc->index)) {
> @@ -299,11 +299,11 @@ static void rcar_du_crtc_set_display_timing(struct
> rcar_du_crtc *rcrtc) rcar_du_group_write(rcrtc->group, rcrtc->index % 2 ?
> OTAR2 : OTAR, 0);
>
> /* Signal polarities */
> - value = ((mode->flags & DRM_MODE_FLAG_PVSYNC) ? DSMR_VSL : 0)
> - | ((mode->flags & DRM_MODE_FLAG_PHSYNC) ? DSMR_HSL : 0)
> - | ((mode->flags & DRM_MODE_FLAG_INTERLACE) ? DSMR_ODEV : 0)
> - | DSMR_DIPM_DISP | DSMR_CSPM;
> - rcar_du_crtc_write(rcrtc, DSMR, value);
> + dsmr = ((mode->flags & DRM_MODE_FLAG_PVSYNC) ? DSMR_VSL : 0)
> +| ((mode->flags & DRM_MODE_FLAG_PHSYNC) ? DSMR_HSL : 0)
> +| ((mode->flags & DRM_MODE_FLAG_INTERLACE) ? DSMR_ODEV : 0)
> +| DSMR_DIPM_DISP | DSMR_CSPM;
> + rcar_du_crtc_write(rcrtc, DSMR, dsmr);
>
> /* Display timings */
> rcar_du_crtc_write(rcrtc, HDSR, mode->htotal - mode->hsync_start - 19);
--
Regards,
Laurent Pinchart
[PATCH] arm64: dts: renesas: salvator-common: Add GPIO keys support
The Salvator-X and XS boards have a 4 lines DIP switch and 3 push
buttons connected to SoC GPIOs, meant to be used as general-purpose test
keys. Add a corresponding node in DT, mapping (semi-randomly) the DIP
switch to keys 1-4 and the push buttons to keys A-C.
Signed-off-by: Laurent Pinchart
---
arch/arm64/boot/dts/renesas/salvator-common.dtsi | 63
1 file changed, 63 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/salvator-common.dtsi
b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
index 7d3d866a0063..77d626baa9f3 100644
--- a/arch/arm64/boot/dts/renesas/salvator-common.dtsi
+++ b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
@@ -29,6 +29,7 @@
*/
#include
+#include
/ {
aliases {
@@ -86,6 +87,63 @@
};
};
+ keys {
+ compatible = "gpio-keys";
+
+ pinctrl-0 = <_pins>;
+ pinctrl-names = "default";
+
+ key-1 {
+ gpios = < 17 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ label = "SW4-1";
+ wakeup-source;
+ debounce-interval = <20>;
+ };
+ key-2 {
+ gpios = < 20 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ label = "SW4-2";
+ wakeup-source;
+ debounce-interval = <20>;
+ };
+ key-3 {
+ gpios = < 22 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ label = "SW4-3";
+ wakeup-source;
+ debounce-interval = <20>;
+ };
+ key-4 {
+ gpios = < 23 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ label = "SW4-4";
+ wakeup-source;
+ debounce-interval = <20>;
+ };
+ key-a {
+ gpios = < 11 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ label = "TSW0";
+ wakeup-source;
+ debounce-interval = <20>;
+ };
+ key-b {
+ gpios = < 12 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ label = "TSW1";
+ wakeup-source;
+ debounce-interval = <20>;
+ };
+ key-c {
+ gpios = < 13 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ label = "TSW2";
+ wakeup-source;
+ debounce-interval = <20>;
+ };
+ };
+
reg_1p8v: regulator0 {
compatible = "regulator-fixed";
regulator-name = "fixed-1.8V";
@@ -567,6 +625,11 @@
function = "intc_ex";
};
+ keys_pins: keys {
+ pins = "GP_5_17", "GP_5_20", "GP_5_22";
+ bias-pull-up;
+ };
+
pwm1_pins: pwm1 {
groups = "pwm1_a";
function = "pwm1";
--
Regards,
Laurent Pinchart
Re: [PATCH v3 2/2] arm64: dts: renesas: condor/v3hsk: add DU/LVDS/HDMI support
out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + adv7511_out: endpoint {
> + remote-endpoint = <_con>;
> + };
> + };
> + };
> + };
> +};
> +
> + {
> + status = "okay";
> +
> + ports {
> + port@1 {
> + lvds0_out: endpoint {
> + remote-endpoint = <_in>;
> + };
> + };
> + };
> };
>
> {
> Index: renesas/arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts
> ===
> --- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts
> +++ renesas/arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts
> @@ -27,6 +27,63 @@
> /* first 128MB is reserved for secure area. */
> reg = <0 0x4800 0 0x7800>;
> };
> +
> + hdmi-out {
> + compatible = "hdmi-connector";
> + type = "a";
> +
> + port {
> + hdmi_con: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> + };
> +
> + lvds-decoder {
> + compatible = "thine,thc63lvd1024";
> + vcc-supply = <_d5>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + thc63lvd1024_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> +
> + port@2 {
> + reg = <2>;
> + thc63lvd1024_out: endpoint {
> + remote-endpoint = <_in>;
> + };
> + };
> + };
> + };
> +
> + vcc1v8_d4: regulator-0 {
> + compatible = "regulator-fixed";
> + regulator-name = "VCC1V8_D4";
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <180>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + vcc3v3_d5: regulator-1 {
> + compatible = "regulator-fixed";
> + regulator-name = "VCC3V3_D5";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +};
> +
> + {
> + status = "okay";
No dot clock for the DU ?
Apart from that,
Reviewed-by: Laurent Pinchart
> };
>
> _clk {
> @@ -53,6 +110,64 @@
> };
> };
>
> + {
> + status = "okay";
> +
> + ports {
> + port@1 {
> + lvds0_out: endpoint {
> + remote-endpoint = <_in>;
> + };
> + };
> + };
> +};
> +
> + {
> + pinctrl-0 = <_pins>;
> + pinctrl-names = "default";
> +
> + status = "okay";
> + clock-frequency = <40>;
> +
> + hdmi@39 {
> + compatible = "adi,adv7511w";
> + #sound-dai-cells = <0>;
> + reg = <0x39>;
> + interrupt-parent = <>;
> + interrupts = <20 IRQ_TYPE_LEVEL_LOW>;
> + avdd-supply = <_d4>;
> + dvdd-supply = <_d4>;
> + pvdd-supply = <_d4>;
> + bgvdd-supply = <_d4>;
> + dvdd-3v-supply = <_d5>;
> +
> + adi,input-depth = <8>;
> + adi,input-colorspace = "rgb";
> + adi,input-clock = "1x";
> + adi,input-style = <1>;
> + adi,input-justification = "evenly";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + adv7511_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + adv7511_out: endpoint {
> + remote-endpoint = <_con>;
> + };
> + };
> + };
> + };
> +};
> +
> {
> gether_pins: gether {
> groups = "gether_mdio_a", "gether_rgmii",
> @@ -60,6 +175,11 @@
> function = "gether";
> };
>
> + i2c0_pins: i2c0 {
> + groups = "i2c0";
> + function = "i2c0";
> + };
> +
> scif0_pins: scif0 {
> groups = "scif0_data";
> function = "scif0";
--
Regards,
Laurent Pinchart
Re: [V2]Fix RCAR-V3H SoC wrong IPSR9/10 registers
Hi Adnan, On Thursday, 9 August 2018 11:10:43 EEST Adnan Ali wrote: > Hi All, > > Please review this V2 patch. This patch belongs to branch from elinux.org > for V3H condor. As requested in a review of v1, could you please send patches inline instead of as attachments ? They can't be reviewed without the reviewer having to manually paste the patch in the e-mail and add quote characters. -- Regards, Laurent Pinchart
Re: [PATCH 02/14] dt-bindings: arm: don't embed SoC name into the ULCB boards' compatible
Hi Morimoto-san, On Tuesday, 7 August 2018 11:18:11 EEST Kuninori Morimoto wrote: > Hi Eugeniu, again > > > Yeah, it is true "so far". I think there is no problem on current kernel. > > But, unfortunately we need to keep compatibility for old/new DT > > (= actually, I don't like this DT rule. It is 100% "shackles for the > > legs") > > Thus, my big concern is that, in the future, > > "if" we added "renesas,ulcb" compatible driver/soc, > > both h3/m3 ulcb will use it. > > Then, if "h3" can work/boot by using same "m3" settings, it is no problem > > for me (= "works but limited" is also OK, of course. > > > > This means "matched to more generic compatible") > > "renesas,ulcb" is very generic naming. > Not only h3/m3, if we had v3/e3/d3 etc ulcb, Furthermore, "ulcb" is an unofficial term, the boards are named "starter kit" (SK). Using internal names in code or device tree sources is a normal practice and is fine with me, but I'm a bit bothered by the fact that the H3/M3 boards are called ULCB in DT, while the V3 board are called SK. I wonder if we should unify that or if it's too late. > and if we had such compatible driver/soc, it needs to match to all ulcb. > In reality, maybe we don't create such compatible driver, though. > But, I don't know, I can follow to maintainer opinion. -- Regards, Laurent Pinchart
Re: [PATCH/RFC 0/4] sh-sci : Do not derive regshift from regsize
On Monday, 6 August 2018 17:37:45 EEST Laurent Pinchart wrote:
> On Monday, 6 August 2018 17:07:51 EEST Geert Uytterhoeven wrote:
> > Hi all,
> >
> > This RFC patch series was sparked by noticing that commit 2d4dd0da45401c7a
>
> Where can that commit be found ?
I found it in -next, sorry for the noise.
> > ("serial: sh-sci: Allow for compressed SCIF address") broke earlycon
> > support on most Renesas ARM SoCs using SCIF ports, and by the fragility of
>
> > deriving regshift from the register block size (which may be rounded up):
>
> Why should it be rounded up ?
>
> > 1. The first patch is an old patch from Sato-san, which I never really
> > understood. But it turned out to be a dependency for patch 2.
> > 2. Patch 2 makes sure regshift is initialized when using earlycon,
> > unbreaking the serial console on e.g. R-Car Gen2 and Gen3.
> > 3. Patch 3 reverts the patch that started deriving regshift from the
> > register block size, and that removed the plat_sci_port.regshift
> > field. Which is a field I needed again in patch 4.
> > 4. Patch 4 removes the remaining regshift derivations on DT platforms.
> > (5. I didn't bother writing patch 5, which involves adding .regshift
> > initializations to all SH board files that need it.)
> >
> > However, I'm not happy with the end result, so please DO NOT apply this!
> > As I spent almost a full day on this, and would still like to know the
> > story about "sh-sci: Use a separate sci_port for earlycon", I decided to
> > post it anyway.
> >
> > As earlycon will be broken in v4.19-rc1 on RZ/A1, RZ/G, and R-Car,
> > assuming
> >
> > no other actions are taken, an alternative solution would be to:
> > 1. Revert commit 7acece71a517cad8 ("serial: sh-sci: Remove
> > SCIx_RZ_SCIFA_REGTYPE"),
> > 2. Revert commit 2d4dd0da45401c7a ("serial: sh-sci: Allow for compressed
> > SCIF address") alternative,
> > 3. Add an OF_EARLYCON_DECLARE() for RZ/A2, to fix earlycon on RZ/A2.
> >
> > What do you think?
> > Thanks for your comments!
> >
> > P.S. Apparently SCIx_SH4_SCIF_REGTYPE and SCIx_SH2_SCIF_FIFODATA_REGTYPE
> >
> > are identical?
> >
> > Geert Uytterhoeven (3):
> > [RFC] sh-sci: Take into account regshift to fix earlycon breakage
> > [RFC] Revert "serial: sh-sci: Compute the regshift value for SCI
> > ports"
> > [RFC] sh-sci: Derive regshift value from DT compatible value
> >
> > Yoshinori Sato (1):
> > [RFC] sh-sci: Use a separate sci_port for earlycon
> >
> > arch/sh/kernel/cpu/sh3/setup-sh770x.c | 1 +
> > arch/sh/kernel/cpu/sh4/setup-sh7750.c | 3 +-
> > arch/sh/kernel/cpu/sh4/setup-sh7760.c | 10 +---
> > drivers/tty/serial/sh-sci.c | 68 +--
> > include/linux/serial_sci.h| 1 +
> > 5 files changed, 49 insertions(+), 34 deletions(-)
--
Regards,
Laurent Pinchart
Re: [PATCH/RFC 3/4] Revert "serial: sh-sci: Compute the regshift value for SCI ports"
Hi Geert, On Monday, 6 August 2018 17:34:34 EEST Geert Uytterhoeven wrote: > On Mon, Aug 6, 2018 at 4:16 PM Laurent Pinchart wrote: > > On Monday, 6 August 2018 17:07:54 EEST Geert Uytterhoeven wrote: > >> This reverts commit dfc80387aefb78161f83732804c6d01c89c24595. > >> > >> Deriving the proper regshift value from the register block size is > >> fragile, as it may have been rounded up. > >> > >> Furthermore we will need plat_sci_port.regshift again. > > > > Won't this break bisection ? Shouldn't you squash patches 3 and 4 together > > ? > > > > Does this mechanism break anything on non-DT platforms ? If not I'd rather > > keep it for them, and only use compat strings for DT platforms, to > > avoiding adding back a platform data field. > > Actually I think the original commit broke SCI on H8/300, as regshift should > be zero on that platform. > But that was not discovered until recently. So there are still people booting H3/800 ? :-) Could we still keep the mechanism for SH and fix H8/300 with special handling somewhere ? -- Regards, Laurent Pinchart
Re: [PATCH/RFC 0/4] sh-sci : Do not derive regshift from regsize
Hi Geert,
On Monday, 6 August 2018 17:07:51 EEST Geert Uytterhoeven wrote:
> Hi all,
>
> This RFC patch series was sparked by noticing that commit 2d4dd0da45401c7a
Where can that commit be found ?
> ("serial: sh-sci: Allow for compressed SCIF address") broke earlycon
> support on most Renesas ARM SoCs using SCIF ports, and by the fragility of
> deriving regshift from the register block size (which may be rounded up):
Why should it be rounded up ?
> 1. The first patch is an old patch from Sato-san, which I never really
> understood. But it turned out to be a dependency for patch 2.
> 2. Patch 2 makes sure regshift is initialized when using earlycon,
> unbreaking the serial console on e.g. R-Car Gen2 and Gen3.
> 3. Patch 3 reverts the patch that started deriving regshift from the
> register block size, and that removed the plat_sci_port.regshift
> field. Which is a field I needed again in patch 4.
> 4. Patch 4 removes the remaining regshift derivations on DT platforms.
> (5. I didn't bother writing patch 5, which involves adding .regshift
> initializations to all SH board files that need it.)
>
> However, I'm not happy with the end result, so please DO NOT apply this!
> As I spent almost a full day on this, and would still like to know the
> story about "sh-sci: Use a separate sci_port for earlycon", I decided to
> post it anyway.
>
> As earlycon will be broken in v4.19-rc1 on RZ/A1, RZ/G, and R-Car, assuming
> no other actions are taken, an alternative solution would be to:
> 1. Revert commit 7acece71a517cad8 ("serial: sh-sci: Remove
> SCIx_RZ_SCIFA_REGTYPE"),
> 2. Revert commit 2d4dd0da45401c7a ("serial: sh-sci: Allow for compressed
> SCIF address") alternative,
> 3. Add an OF_EARLYCON_DECLARE() for RZ/A2, to fix earlycon on RZ/A2.
>
> What do you think?
> Thanks for your comments!
>
> P.S. Apparently SCIx_SH4_SCIF_REGTYPE and SCIx_SH2_SCIF_FIFODATA_REGTYPE
> are identical?
>
> Geert Uytterhoeven (3):
> [RFC] sh-sci: Take into account regshift to fix earlycon breakage
> [RFC] Revert "serial: sh-sci: Compute the regshift value for SCI
> ports"
> [RFC] sh-sci: Derive regshift value from DT compatible value
>
> Yoshinori Sato (1):
> [RFC] sh-sci: Use a separate sci_port for earlycon
>
> arch/sh/kernel/cpu/sh3/setup-sh770x.c | 1 +
> arch/sh/kernel/cpu/sh4/setup-sh7750.c | 3 +-
> arch/sh/kernel/cpu/sh4/setup-sh7760.c | 10 +---
> drivers/tty/serial/sh-sci.c | 68 +--
> include/linux/serial_sci.h| 1 +
> 5 files changed, 49 insertions(+), 34 deletions(-)
--
Regards,
Laurent Pinchart
Re: [PATCH/RFC 3/4] Revert "serial: sh-sci: Compute the regshift value for SCI ports"
Hi Geert,
Thank you for the patch.
On Monday, 6 August 2018 17:07:54 EEST Geert Uytterhoeven wrote:
> This reverts commit dfc80387aefb78161f83732804c6d01c89c24595.
>
> Deriving the proper regshift value from the register block size is
> fragile, as it may have been rounded up.
>
> Furthermore we will need plat_sci_port.regshift again.
Won't this break bisection ? Shouldn't you squash patches 3 and 4 together ?
Does this mechanism break anything on non-DT platforms ? If not I'd rather
keep it for them, and only use compat strings for DT platforms, to avoiding
adding back a platform data field.
> Signed-off-by: Geert Uytterhoeven
> ---
> arch/sh/kernel/cpu/sh3/setup-sh770x.c | 1 +
> arch/sh/kernel/cpu/sh4/setup-sh7750.c | 3 ++-
> arch/sh/kernel/cpu/sh4/setup-sh7760.c | 10 ++
> drivers/tty/serial/sh-sci.c | 8 +---
> include/linux/serial_sci.h| 1 +
> 5 files changed, 7 insertions(+), 16 deletions(-)
>
> diff --git a/arch/sh/kernel/cpu/sh3/setup-sh770x.c
> b/arch/sh/kernel/cpu/sh3/setup-sh770x.c index
> 59a88611df55ac8f..592cd9ab30c4272f 100644
> --- a/arch/sh/kernel/cpu/sh3/setup-sh770x.c
> +++ b/arch/sh/kernel/cpu/sh3/setup-sh770x.c
> @@ -111,6 +111,7 @@ static struct platform_device rtc_device = {
> static struct plat_sci_port scif0_platform_data = {
> .type = PORT_SCI,
> .ops= _sci_port_ops,
> + .regshift = 1,
> };
>
> static struct resource scif0_resources[] = {
> diff --git a/arch/sh/kernel/cpu/sh4/setup-sh7750.c
> b/arch/sh/kernel/cpu/sh4/setup-sh7750.c index
> 57d30689204d03b9..d98a55416306baef 100644
> --- a/arch/sh/kernel/cpu/sh4/setup-sh7750.c
> +++ b/arch/sh/kernel/cpu/sh4/setup-sh7750.c
> @@ -39,10 +39,11 @@ static struct platform_device rtc_device = {
>
> static struct plat_sci_port sci_platform_data = {
> .type = PORT_SCI,
> + .regshift = 2,
> };
>
> static struct resource sci_resources[] = {
> - DEFINE_RES_MEM(0xffe0, 0x20),
> + DEFINE_RES_MEM(0xffe0, 0x100),
> DEFINE_RES_IRQ(evt2irq(0x4e0)),
> };
>
> diff --git a/arch/sh/kernel/cpu/sh4/setup-sh7760.c
> b/arch/sh/kernel/cpu/sh4/setup-sh7760.c index
> e51fe1734e1368e8..0c0cdfc69dcc3e33 100644
> --- a/arch/sh/kernel/cpu/sh4/setup-sh7760.c
> +++ b/arch/sh/kernel/cpu/sh4/setup-sh7760.c
> @@ -200,18 +200,12 @@ static struct platform_device scif2_device = {
> };
>
> static struct plat_sci_port scif3_platform_data = {
> - /*
> - * This is actually a SIM card module serial port, based on an SCI with
> - * additional registers. The sh-sci driver doesn't support the SIM port
> - * type, declare it as a SCI. Don't declare the additional registers in
> - * the memory resource or the driver will compute an incorrect regshift
> - * value.
> - */
> .type = PORT_SCI,
> + .regshift = 2,
> };
>
> static struct resource scif3_resources[] = {
> - DEFINE_RES_MEM(0xfe48, 0x10),
> + DEFINE_RES_MEM(0xfe48, 0x100),
> DEFINE_RES_IRQ(evt2irq(0xc00)),
> DEFINE_RES_IRQ(evt2irq(0xc20)),
> DEFINE_RES_IRQ(evt2irq(0xc40)),
> diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
> index caf4422d9e2e59e4..955c057dff6e8c78 100644
> --- a/drivers/tty/serial/sh-sci.c
> +++ b/drivers/tty/serial/sh-sci.c
> @@ -2895,15 +2895,9 @@ static int sci_init_single(struct platform_device
> *dev,
>
> port->type = p->type;
> port->flags = UPF_FIXED_PORT | UPF_BOOT_AUTOCONF | p->flags;
> + port->regshift = p->regshift;
> port->fifosize = sci_port->params->fifosize;
>
> - if (port->type == PORT_SCI) {
> - if (sci_port->reg_size >= 0x20)
> - port->regshift = 2;
> - else
> - port->regshift = 1;
> - }
> -
> if (regtype == SCIx_SH4_SCIF_REGTYPE)
> if (sci_port->reg_size >= 0x20)
> port->regshift = 1;
> diff --git a/include/linux/serial_sci.h b/include/linux/serial_sci.h
> index c0e795d95477daea..eebb12fc473f49a2 100644
> --- a/include/linux/serial_sci.h
> +++ b/include/linux/serial_sci.h
> @@ -57,6 +57,7 @@ struct plat_sci_port {
> /*
>* Platform overrides if necessary, defaults otherwise.
>*/
> + unsigned char regshift;
> unsigned char regtype;
>
> struct plat_sci_port_ops*ops;
--
Regards,
Laurent Pinchart
Re: [PATCH 04/14] arm64: dts: renesas: r8a7795-es1: ulcb-kf: Use "renesas,ulcb" compatible
Hi Kieran,
On Monday, 6 August 2018 13:49:59 EEST Kieran Bingham wrote:
> On 06/08/18 11:45, Kieran Bingham wrote:
> > On 06/08/18 11:42, Laurent Pinchart wrote:
> >> On Sunday, 5 August 2018 02:11:04 EEST Eugeniu Rosca wrote:
> >>> Following the recent change in dt-bindings [1], switch from
> >>> "renesas,h3ulcb" to "renesas,ulcb" compatible string.
> >>>
> >>> [1] Documentation/devicetree/bindings/arm/shmobile.txt
> >>>
> >>> Signed-off-by: Eugeniu Rosca
> >>> ---
> >>>
> >>> arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb-kf.dts | 2 +-
> >>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb-kf.dts
> >>> b/arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb-kf.dts index
> >>> 06deb67c36c8..7a5b1dc64090 100644
> >>> --- a/arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb-kf.dts
> >>> +++ b/arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb-kf.dts
> >>> @@ -14,6 +14,6 @@
> >>>
> >>> / {
> >>> model = "Renesas H3ULCB Kingfisher board based on r8a7795 ES1.x";
> >>>
> >>> - compatible = "shimafuji,kingfisher", "renesas,h3ulcb",
> >>> + compatible = "shimafuji,kingfisher", "renesas,ulcb",
> >>>"renesas,r8a7795";
> >>
> >> This is unrelated to your patch, but due to the reason explained in my
> >> review of 02/14, I think "shimafuji,kingfisher" should include the SoC
> >> name.
> >>
> >> This brings up the topic of how to describe boards that are made of an
> >> SoC "module" board plugged into an expansion "motherboard".
> >
> > Isn't it the point that the shimafuji board is agnostic to the SoC on
> > the ULCB?
> >
> > I presume the Kingfisher board is just the expansion board which would
> > be identical regardless of if it was put on an H3 ULCB, or an M3 ULCB?
>
> In fact possibly the interesting point is that the kingfisher as an
> expansion board is surely an 'overlay', rather than the board itself ?
In a way it's both. From an SoC point of view, the KingFisher board can be
seen as an expansion board. From a system point of view, it's a KingFisher
system.
If you built a car around an H3 ULCB, would you consider that to be an H3 with
a car extension, or a car with an H3 inside ? :-)
> >>> };
--
Regards,
Laurent Pinchart
Re: [PATCH 04/14] arm64: dts: renesas: r8a7795-es1: ulcb-kf: Use "renesas,ulcb" compatible
Hi Eugeniu,
Thank you for the patch.
On Sunday, 5 August 2018 02:11:04 EEST Eugeniu Rosca wrote:
> Following the recent change in dt-bindings [1], switch from
> "renesas,h3ulcb" to "renesas,ulcb" compatible string.
>
> [1] Documentation/devicetree/bindings/arm/shmobile.txt
>
> Signed-off-by: Eugeniu Rosca
> ---
> arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb-kf.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb-kf.dts
> b/arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb-kf.dts index
> 06deb67c36c8..7a5b1dc64090 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb-kf.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb-kf.dts
> @@ -14,6 +14,6 @@
>
> / {
> model = "Renesas H3ULCB Kingfisher board based on r8a7795 ES1.x";
> - compatible = "shimafuji,kingfisher", "renesas,h3ulcb",
> + compatible = "shimafuji,kingfisher", "renesas,ulcb",
>"renesas,r8a7795";
This is unrelated to your patch, but due to the reason explained in my review
of 02/14, I think "shimafuji,kingfisher" should include the SoC name.
This brings up the topic of how to describe boards that are made of an SoC
"module" board plugged into an expansion "motherboard".
> };
--
Regards,
Laurent Pinchart
Re: [PATCH 02/14] dt-bindings: arm: don't embed SoC name into the ULCB boards' compatible
Hi Eugeniu, Thank you for the patch. On Sunday, 5 August 2018 02:11:02 EEST Eugeniu Rosca wrote: > In the context of M3N-ULCB (RTP0RC77965SKBX010SA00) board bring-up, it's > rather pointless to add a new "renesas,m3nulcb" compatible string. Any > SoC-level differences between the two variants of ULCB (M3 and M3-N) > should be successfully covered by making use of existing > "renesas,r8a7796" and "renesas,r8a77965" compatibles. > > Prior to adding M3-N Starter Kit to the list, rename: > - "renesas,h3ulcb" => "renesas,ulcb" > - "renesas,m3ulcb" => "renesas,ulcb" This bothers me more than the naming convention in patch 01/14, as this change would completely hide differences between the H3 and M3-N versions of the ULCB. Compatible strings are listed in a decreasing order of specificity, and having "renesas,ulcb" as the most-specific compatible string means that the two boards are supposed to be identical, while they are not. > Relevant DTS changes come in separate per-DTS commits. > > Signed-off-by: Eugeniu Rosca > --- > Documentation/devicetree/bindings/arm/shmobile.txt | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt > b/Documentation/devicetree/bindings/arm/shmobile.txt index > d8cf740132c6..f391dba10574 100644 > --- a/Documentation/devicetree/bindings/arm/shmobile.txt > +++ b/Documentation/devicetree/bindings/arm/shmobile.txt > @@ -81,7 +81,7 @@ Boards: > compatible = "renesas,gose", "renesas,r8a7793" >- H3ULCB (R-Car Starter Kit Premier, RTP0RC7795SKBX0010SA00 (H3 ES1.1)) > H3ULCB (R-Car Starter Kit Premier, RTP0RC77951SKBX010SA00 (H3 ES2.0)) > -compatible = "renesas,h3ulcb", "renesas,r8a7795" > +compatible = "renesas,ulcb", "renesas,r8a7795" >- Henninger > compatible = "renesas,henninger", "renesas,r8a7791" >- iWave Systems RZ/G1C Single Board Computer (iW-RainboW-G23S) > @@ -105,7 +105,7 @@ Boards: >- Lager (RTP0RC7790SEB00010S) > compatible = "renesas,lager", "renesas,r8a7790" >- M3ULCB (R-Car Starter Kit Pro, RTP0RC7796SKBX0010SA09 (M3 ES1.0)) > -compatible = "renesas,m3ulcb", "renesas,r8a7796" > +compatible = "renesas,ulcb", "renesas,r8a7796" >- Marzen (R0P7779A00010S) > compatible = "renesas,marzen", "renesas,r8a7779" >- Porter (M2-LCDP) -- Regards, Laurent Pinchart
Re: [PATCH 01/14] arm64: dts: renesas: Cut redundant in *-ulcb*.dts
.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb-kf.dts
> @@ -9,7 +9,7 @@
> * kind, whether express or implied.
> */
>
> -#include "r8a7795-es1-h3ulcb.dts"
> +#include "r8a7795-es1-ulcb.dts"
> #include "ulcb-kf.dtsi"
>
> / {
> diff --git a/arch/arm64/boot/dts/renesas/r8a7795-es1-h3ulcb.dts
> b/arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb.dts similarity index 100%
> rename from arch/arm64/boot/dts/renesas/r8a7795-es1-h3ulcb.dts
> rename to arch/arm64/boot/dts/renesas/r8a7795-es1-ulcb.dts
> diff --git a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb-kf.dts
> b/arch/arm64/boot/dts/renesas/r8a7795-ulcb-kf.dts similarity index 94%
> rename from arch/arm64/boot/dts/renesas/r8a7795-h3ulcb-kf.dts
> rename to arch/arm64/boot/dts/renesas/r8a7795-ulcb-kf.dts
> index 4403227c0f97..70a0c5332d54 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb-kf.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a7795-ulcb-kf.dts
> @@ -9,7 +9,7 @@
> * kind, whether express or implied.
> */
>
> -#include "r8a7795-h3ulcb.dts"
> +#include "r8a7795-ulcb.dts"
> #include "ulcb-kf.dtsi"
>
> / {
> diff --git a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
> b/arch/arm64/boot/dts/renesas/r8a7795-ulcb.dts similarity index 100%
> rename from arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
> rename to arch/arm64/boot/dts/renesas/r8a7795-ulcb.dts
> diff --git a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dts
> b/arch/arm64/boot/dts/renesas/r8a7796-ulcb-kf.dts similarity index 94%
> rename from arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dts
> rename to arch/arm64/boot/dts/renesas/r8a7796-ulcb-kf.dts
> index de2390f009e7..faa32c28eef7 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a7796-ulcb-kf.dts
> @@ -9,7 +9,7 @@
> * kind, whether express or implied.
> */
>
> -#include "r8a7796-m3ulcb.dts"
> +#include "r8a7796-ulcb.dts"
> #include "ulcb-kf.dtsi"
>
> / {
> diff --git a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
> b/arch/arm64/boot/dts/renesas/r8a7796-ulcb.dts similarity index 100%
> rename from arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
> rename to arch/arm64/boot/dts/renesas/r8a7796-ulcb.dts
--
Regards,
Laurent Pinchart
Re: [GIT/RFC PULL LTSI-4.14] Renesas SoCs and Drivers to v4.17
Hi Geert,
On Tuesday, 31 July 2018 16:48:48 EEST Geert Uytterhoeven wrote:
> On Wed, Jul 11, 2018 at 11:16 PM Laurent Pinchart wrote:
> > On Thursday, 5 July 2018 13:55:00 EEST Geert Uytterhoeven wrote:
> >> On Thu, Jun 14, 2018 at 1:36 PM Simon Horman wrote:
> >>> This series is comprised of backports to v4.14 of the following
> >
> >>> components from their standard as of v4.16 to that of v4.17:
> > [snip]
> >
> >> I subjected it to the same testing I do for each renesas-drivers
> >> release.
> >
> >> Regressions from v4.14.48:
> > [snip]
> >
> >> - Koelsch, Salvator-X (R-Car M3-W), Salvator-XS (R-Car H3 ES2.0):
> >> +rcar-du feb0.display: no connector for encoder
> >>
> >> /soc/lvds@feb9, skipping
> >>
> >> Laurent: do you know what's missing?
> >
> > That message is printed when no connector node is linked in DT through OF
> > graph to the encoder DT node output port. That's expected in this case as
> > we have an LVDS encoder, but not connected panel. However,
> > rcar_du_encoders_init_one() should return before printing that message due
> > to
> >
> > if (!of_device_is_available(entity)) {
> > dev_dbg(rcdu->dev,
> > "connected entity %pOF is disabled, skipping\n",
> > entity);
> > return -ENODEV;
> > }
> >
> > as the LVDS encoder nodes in DT should be disabled.
>
> The LVDS encoder nodes were enabled in the following commits:
> - e5c3f4707f3956a2 ("ARM: dts: r8a7791: Convert to new LVDS DT bindings"),
> for Koelsch and Porter, but none of them has a connected panel?
> - 15a1ff30d8f9bd83 ("ARM: dts: r8a7790: Convert to new LVDS DT bindings"),
> for both LVDS instances on Lager, but the second one doesn't have a panel
> connected?
>
> edb0c3affe5214a2 ("ARM: dts: r8a7793: Convert to new LVDS DT bindings")
> for Gose did it right, though.
You're right, disabling the LVDS encoders there would make sense. I'll submit
a patch to fix that.
--
Regards,
Laurent Pinchart
Re: [PATCH] dmaengine: rcar-dmac: Make rcar_dmac_of_xlate() more robust
Hi Geert,
Thank you for the patch.
On Friday, 27 July 2018 11:44:47 EEST Geert Uytterhoeven wrote:
> Add an upper bound check for the MID/RID value passed from DT via the
> DMA spec.
>
> This avoids writing to reserved bits in the DMARS registers in case of
> an out-of-range value in DT.
Is this really useful ? In the normal case, when information in DT is correct,
this will just add overhead. What do we really want to guard against ? If we
merge this change, how much further do we need to go ? What other values
provided in DT, such as reg addresses, do we need to validate them too ?
Functionally speaking this change does no harm, but it increases the kernel
size, add overhead at runtime, and only addresses a very limited range of
invalid DT issues.
> Suggested-by: Renesas BSP team via Yoshihiro Shimoda
> Signed-off-by: Geert Uytterhoeven
>
> ---
> drivers/dma/sh/rcar-dmac.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
> index 72572320208dbb9a..73cf1053bed90244 100644
> --- a/drivers/dma/sh/rcar-dmac.c
> +++ b/drivers/dma/sh/rcar-dmac.c
> @@ -1644,8 +1644,11 @@ static struct dma_chan *rcar_dmac_of_xlate(struct
> of_phandle_args *dma_spec, struct dma_chan *chan;
> dma_cap_mask_t mask;
>
> - if (dma_spec->args_count != 1)
> + if (dma_spec->args_count != 1 || dma_spec->args[0] > 0xff) {
> + pr_info("%s: invalid MID/RID 0x%x... for %pOF\n", __func__,
> + dma_spec->args[0], dma_spec->np);
> return NULL;
> + }
>
> /* Only slave DMA channels can be allocated via DT */
> dma_cap_zero(mask);
--
Regards,
Laurent Pinchart
Re: [PATCH v5 0/2] R-Car DU: Convert DT to new DU and LVDS bindings
Hi Simon, On Wednesday, 6 June 2018 11:44:22 EEST Simon Horman wrote: > On Tue, Jun 05, 2018 at 12:51:04PM +0300, Laurent Pinchart wrote: > > Hello, > > > > This small patch series contains the last two remaining patches from > > "[PATCH v4 00/16] R-Car DU: Convert LVDS code to bridge driver". Apart > > from the individual SoC patches being squashed together as requested by > > the ARM-SoC maintainers there's nothing special here. > > Hi, > > This looks fine to me but I will wait to see if there are other reviews > before applying. > > Reviewed-by: Simon Horman No other review, is it time to apply it ? Too late for v4.19 I assume ? :-( -- Regards, Laurent Pinchart
Re: [PATCH] iommu/ipmmu-vmsa: Clarify supported platforms
Hi Geert, Thank you for the patch. On Wednesday, 25 July 2018 16:10:29 EEST Geert Uytterhoeven wrote: > The Renesas IPMMU-VMSA driver supports not just R-Car H2 and M2 SoCs, > but also other R-Car Gen2 and R-Car Gen3 SoCs. > > Drop a superfluous "Renesas" while at it. > > Signed-off-by: Geert Uytterhoeven Reviewed-by: Laurent Pinchart > --- > drivers/iommu/Kconfig | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig > index 568ae81b0e99b67b..c69dc0b29b5df37f 100644 > --- a/drivers/iommu/Kconfig > +++ b/drivers/iommu/Kconfig > @@ -306,8 +306,8 @@ config IPMMU_VMSA > select IOMMU_IO_PGTABLE_LPAE > select ARM_DMA_USE_IOMMU > help > - Support for the Renesas VMSA-compatible IPMMU Renesas found in the > - R-Mobile APE6 and R-Car H2/M2 SoCs. > + Support for the Renesas VMSA-compatible IPMMU found in the R-Mobile > + APE6, R-Car Gen2, and R-Car Gen3 SoCs. > > If unsure, say N. -- Regards, Laurent Pinchart
Re: [GIT/RFC PULL LTSI-4.14] Renesas SoCs and Drivers to v4.17
Hi Geert,
On Thursday, 5 July 2018 13:55:00 EEST Geert Uytterhoeven wrote:
> On Thu, Jun 14, 2018 at 1:36 PM Simon Horman wrote:
> > This series is comprised of backports to v4.14 of the following
> > components from their standard as of v4.16 to that of v4.17:
[snip]
> I subjected it to the same testing I do for each renesas-drivers release.
>
> Regressions from v4.14.48:
[snip]
> - Koelsch, Salvator-X (R-Car M3-W), Salvator-XS (R-Car H3 ES2.0):
>
> +rcar-du feb0.display: no connector for encoder
> /soc/lvds@feb9, skipping
>
> Laurent: do you know what's missing?
That message is printed when no connector node is linked in DT through OF
graph to the encoder DT node output port. That's expected in this case as we
have an LVDS encoder, but not connected panel. However,
rcar_du_encoders_init_one() should return before printing that message due to
if (!of_device_is_available(entity)) {
dev_dbg(rcdu->dev,
"connected entity %pOF is disabled, skipping\n",
entity);
return -ENODEV;
}
as the LVDS encoder nodes in DT should be disabled.
--
Regards,
Laurent Pinchart
Re: [PATCH v2] dmaengine: rcar-dmac: convert to SPDX identifiers
Hi Morimoto-san, Thank you for the patch. On Wednesday, 4 July 2018 03:34:10 EEST Kuninori Morimoto wrote: > From: Kuninori Morimoto > > This patch is using C++ comment style for SPDX line only, > because driver author want it. > > Signed-off-by: Kuninori Morimoto Reviewed-by: Laurent Pinchart > --- > I posted this because I don't know which style was OK. > Please pick-up best side patch > > v1 -> v2 > > - used // for SPDX line only > > drivers/dma/sh/rcar-dmac.c | 5 + > 1 file changed, 1 insertion(+), 4 deletions(-) > > diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c > index 79d14af..ebd160d 100644 > --- a/drivers/dma/sh/rcar-dmac.c > +++ b/drivers/dma/sh/rcar-dmac.c > @@ -1,13 +1,10 @@ > +// SPDX-License-Identifier: GPL-2.0 > /* > * Renesas R-Car Gen2 DMA Controller Driver > * > * Copyright (C) 2014 Renesas Electronics Inc. > * > * Author: Laurent Pinchart > - * > - * This is free software; you can redistribute it and/or modify > - * it under the terms of version 2 of the GNU General Public License as > - * published by the Free Software Foundation. > */ > > #include -- Regards, Laurent Pinchart
Re: [PATCH] dmaengine: rcar-dmac: convert to SPDX identifiers
Hi Vinod, On Tuesday, 3 July 2018 09:20:08 EEST Vinod wrote: > On 03-07-18, 08:49, Laurent Pinchart wrote: > > Hi Morimoto-san, > > > > Thank you for the patch. > > > > On Tuesday, 3 July 2018 03:29:59 EEST Kuninori Morimoto wrote: > > > From: Kuninori Morimoto > > > > A commit message would be nice :-) > > > > > Signed-off-by: Kuninori Morimoto > > > --- > > > > > > drivers/dma/sh/rcar-dmac.c | 18 +++--- > > > 1 file changed, 7 insertions(+), 11 deletions(-) > > > > > > diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c > > > index 79d14af..322e57b 100644 > > > --- a/drivers/dma/sh/rcar-dmac.c > > > +++ b/drivers/dma/sh/rcar-dmac.c > > > @@ -1,14 +1,10 @@ > > > -/* > > > - * Renesas R-Car Gen2 DMA Controller Driver > > > - * > > > - * Copyright (C) 2014 Renesas Electronics Inc. > > > - * > > > - * Author: Laurent Pinchart > > > - * > > > - * This is free software; you can redistribute it and/or modify > > > - * it under the terms of version 2 of the GNU General Public License as > > > - * published by the Free Software Foundation. > > > - */ > > > +// SPDX-License-Identifier: GPL-2.0 > > > +// > > > +// Renesas R-Car Gen2 DMA Controller Driver > > > +// > > > +// Copyright (C) 2014 Renesas Electronics Inc. > > > +// > > > +// Author: Laurent Pinchart > > > > I think the preferred comment style, accordingly to what other drivers do, > > is > > > > // SPDX-License-Identifier: GPL-2.0 > > /* > > > > * Renesas R-Car Gen2 DMA Controller Driver > > * > > * Copyright (C) 2014 Renesas Electronics Inc. > > * > > * Author: Laurent Pinchart > > */ > > And Linus said this https://lkml.org/lkml/2017/11/25/133 > > So lets keep C99 style as Morimoto-San proposed. > > And high time, this should be documented :) As mentioned before, while I certainly prefer the traditional C-style comments, I ultimately let driver authors decide. What matters most in my opinion is consistency, mixing styles in the same driver just makes the code harder to read. What matters in the end is how easy reading the code will be, and until the majority of kernel developers get used to the C++ comment style, no matter what Linus' personal preference is, // will be an annoyance. -- Regards, Laurent Pinchart
Re: [PATCH] dmaengine: rcar-dmac: convert to SPDX identifiers
Hi Morimoto-san, Thank you for the patch. On Tuesday, 3 July 2018 03:29:59 EEST Kuninori Morimoto wrote: > From: Kuninori Morimoto A commit message would be nice :-) > Signed-off-by: Kuninori Morimoto > --- > drivers/dma/sh/rcar-dmac.c | 18 +++--- > 1 file changed, 7 insertions(+), 11 deletions(-) > > diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c > index 79d14af..322e57b 100644 > --- a/drivers/dma/sh/rcar-dmac.c > +++ b/drivers/dma/sh/rcar-dmac.c > @@ -1,14 +1,10 @@ > -/* > - * Renesas R-Car Gen2 DMA Controller Driver > - * > - * Copyright (C) 2014 Renesas Electronics Inc. > - * > - * Author: Laurent Pinchart > - * > - * This is free software; you can redistribute it and/or modify > - * it under the terms of version 2 of the GNU General Public License as > - * published by the Free Software Foundation. > - */ > +// SPDX-License-Identifier: GPL-2.0 > +// > +// Renesas R-Car Gen2 DMA Controller Driver > +// > +// Copyright (C) 2014 Renesas Electronics Inc. > +// > +// Author: Laurent Pinchart I think the preferred comment style, accordingly to what other drivers do, is // SPDX-License-Identifier: GPL-2.0 /* * Renesas R-Car Gen2 DMA Controller Driver * * Copyright (C) 2014 Renesas Electronics Inc. * * Author: Laurent Pinchart */ Apart from that, Reviewed-by: Laurent Pinchart > #include > #include -- Regards, Laurent Pinchart
Re: [PATCH] dmaengine: rcar-dmac: clear channel register when error
Hi Morimoto-san,
Thank you for the patch.
On Monday, 2 July 2018 04:07:17 EEST Kuninori Morimoto wrote:
> From: Kuninori Morimoto
>
> We need to clear channel register in error case as recovery.
> The channel is already stopped in such case, thus we don't need to call
> rcar_dmac_chan_halt() before clearing.
>
> rcar_dmac_chan_halt() will clear register and confirm DE bit.
> But it will be failed because channel is already stopped in error case.
> In other words, we shouldn't call it then.
>
> // This patch started to use C++ style comment out
> // because it is recent Linus request
I fear this will generate lots of frustration :-/ While I strongly prefer the
traditional C style, I'm fine leaving the choice to driver authors. However, I
think that mixing different styles in the same file only hinders readability.
Would you like to convert the whole file ? ;-)
> Reported-by: Hiroki Negishi
> Signed-off-by: Kuninori Morimoto
> Reviewed-by: Hiroki Negishi
> ---
> drivers/dma/sh/rcar-dmac.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
> index 279c930..35d7a16 100644
> --- a/drivers/dma/sh/rcar-dmac.c
> +++ b/drivers/dma/sh/rcar-dmac.c
> @@ -1525,7 +1525,13 @@ static irqreturn_t rcar_dmac_isr_channel(int irq,
> void *dev)
>
> chcr = rcar_dmac_chan_read(chan, RCAR_DMACHCR);
> if (chcr & RCAR_DMACHCR_CAE) {
> - rcar_dmac_chan_halt(chan);
> + struct rcar_dmac *dmac =
> dev_get_drvdata(chan->chan.device->dev);
This could be simplified with
struct rcar_dmac *dmac = to_rcar_dmac(chan->chan.device);
> +
> + // We don't need to call rcar_dmac_chan_halt()
> + // because channel is already stopped in error case.
> + // We need to clear register and check DE bit as recovery.
Is it also a request from Linus to wrap text much before the 80 characters
limit ? :-)
> + rcar_dmac_write(dmac, RCAR_DMACHCLR, 1 << chan->index);
> + rcar_dmac_chcr_de_barrier(chan);
> reinit = true;
> goto spin_lock_end;
> }
--
Regards,
Laurent Pinchart
[PROTO] [VIRTIO] [PATCH 1/2] Add virtio gpu device specification.
cking for the resource.
+
+\item[VIRTIO_GPU_CMD_RESOURCE_ATTACH_BACKING] Assign backing pages to
+ a resource. Request data is \field{struct
+virtio_gpu_resource_attach_backing}, followed by \field{struct
+virtio_gpu_mem_entry} entries. Response type is
+ VIRTIO_GPU_RESP_OK_NODATA.
+
+\begin{lstlisting}
+struct virtio_gpu_resource_attach_backing {
+struct virtio_gpu_ctrl_hdr hdr;
+le32 resource_id;
+le32 nr_entries;
+};
+
+struct virtio_gpu_mem_entry {
+le64 addr;
+le32 length;
+le32 padding;
+};
+\end{lstlisting}
+
+This assign an array of guest pages as the backing store for a
+resource. These pages are then used for the transfer operations for
+that resource from that point on.
+
+\item[VIRTIO_GPU_CMD_RESOURCE_DETACH_BACKING] Detach backing pages
+ from a resource. Request data is \field{struct
+virtio_gpu_resource_detach_backing}. Response type is
+ VIRTIO_GPU_RESP_OK_NODATA.
+
+\begin{lstlisting}
+struct virtio_gpu_resource_detach_backing {
+struct virtio_gpu_ctrl_hdr hdr;
+le32 resource_id;
+le32 padding;
+};
+\end{lstlisting}
+
+This detaches any backing pages from a resource, to be used in case of
+guest swapping or object destruction.
+
+\end{description}
+
+\subsubsection{Device Operation: cursorq}\label{sec:Device Types / GPU Device
/ Device Operation / Device Operation: cursorq}
+
+Both cursorq commands use the same command struct.
+
+\begin{lstlisting}
+struct virtio_gpu_cursor_pos {
+le32 scanout_id;
+le32 x;
+le32 y;
+le32 padding;
+};
+
+struct virtio_gpu_update_cursor {
+struct virtio_gpu_ctrl_hdr hdr;
+struct virtio_gpu_cursor_pos pos;
+le32 resource_id;
+le32 hot_x;
+le32 hot_y;
+le32 padding;
+};
+\end{lstlisting}
+
+\begin{description}
+
+\item[VIRTIO_GPU_CMD_UPDATE_CURSOR]
+Update cursor.
+Request data is \field{struct virtio_gpu_update_cursor}.
+Response type is VIRTIO_GPU_RESP_OK_NODATA.
+
+Full cursor update. Cursor will be loaded from the specified
+\field{resource_id} and will be moved to \field{pos}. The driver must
+transfer the cursor into the resource beforehand (using control queue
+commands) and make sure the commands to fill the resource are actually
+processed (using fencing).
+
+\item[VIRTIO_GPU_CMD_MOVE_CURSOR]
+Move cursor.
+Request data is \field{struct virtio_gpu_update_cursor}.
+Response type is VIRTIO_GPU_RESP_OK_NODATA.
+
+Move cursor to the place specified in \field{pos}. The other fields
+are not used and will be ignored by the device.
+
+\end{description}
+
+\subsection{VGA Compatibility}\label{sec:Device Types / GPU Device / VGA
Compatibility}
+
+Applies to Virtio Over PCI only. The GPU device can come with and
+without VGA compatibility. The PCI class should be DISPLAY_VGA if VGA
+compatibility is present and DISPLAY_OTHER otherwise.
+
+VGA compatibility: PCI region 0 has the linear framebuffer, standard
+vga registers are present. Configuring a scanout
+(VIRTIO_GPU_CMD_SET_SCANOUT) switches the device from vga
+compatibility mode into native virtio mode. A reset switches it back
+into vga compatibility mode.
+
+Note: qemu implementation also provides bochs dispi interface io ports
+and mmio bar at pci region 1 and is therefore fully compatible with
+the qemu stdvga (see
\href{http://git.qemu-project.org/?p=qemu.git;a=blob;f=docs/specs/standard-vga.txt;hb=HEAD}{docs/specs/standard-vga.txt}
in the qemu source tree).
--
Regards,
Laurent Pinchart
[PROTO] [VIRTIO] [PATCH 2/2] virtio-gpu: Support host-allocated backing storage
The virtio-gpu protocol is based on opaque host resources backed by
guest-allocated memory. This requires transferring data from guest
framebuffers to host display device buffers.
When the host supports VIRGL, the GPU is used for both 2D and 3D
rendering, in which case the memory transfer can take the form of a DMA
operation without incurring significant costs. However, when VIRGL
support isn't available, 2D transfers require a CPU memory copy for
every page flip. Display is slowed down to an unusable state.
To solve this problem, extend the virtio-gpu protocol with the ability
for the host to allocate resource backing storage and map it to the
guest. The allocated memory can then be used directly by the host-side
display device, removing the need for memory copy operations.
Signed-off-by: Laurent Pinchart
---
virtio-gpu.tex | 48
1 file changed, 48 insertions(+)
diff --git a/virtio-gpu.tex b/virtio-gpu.tex
index 34cf493bbcd1..22546cc1748f 100644
--- a/virtio-gpu.tex
+++ b/virtio-gpu.tex
@@ -34,6 +34,7 @@ control queue.
\begin{description}
\item[VIRTIO_GPU_F_VIRGL (0)] virgl 3D mode is supported.
+\item[VIRTIO_GPU_F_HOST_ALLOC (1)] buffer allocation by the host is supported.
\end{description}
\subsection{Device configuration layout}\label{sec:Device Types / GPU Device /
Device configuration layout}
@@ -90,6 +91,11 @@ height and format along with an identifier. The guest must
then attach
backing store to the resources in order for DMA transfers to
work. This is like a GART in a real GPU.
+Additionally, when the VIRTIO_GPU_F_HOST_ALLOC feature is present, the guest
+can request the host to allocate backing store for resources on its behalf, in
+which case the allocated resources can be accessed by both the host and the
+guest without any need for DMA transfers.
+
\subsubsection{Device Operation: Create a framebuffer and configure scanout}
\begin{itemize*}
@@ -120,6 +126,18 @@ using VIRTIO_GPU_CMD_SET_SCANOUT and
VIRTIO_GPU_CMD_RESOURCE_FLUSH,
and update the invisible framebuffer using
VIRTIO_GPU_CMD_TRANSFER_SEND_2D.
+\subsubsection{Device Operation: Create a framebuffer from host-allocated
memory}
+
+\begin{itemize*}
+\item Create a host resource using VIRTIO_GPU_CMD_RESOURCE_CREATE_2D. This
+ step is identical to the guest-allocated backing store case.
+\item Request the host to allocate the backing storage for the resource just
+ created, using VIRTIO_GPU_CMD_RESOURCE_ALLOC_BACKING. The host will map the
+ memory to the guest and will return the memory address.
+\item Use VIRTIO_GPU_CMD_SET_SCANOUT, VIRTIO_GPU_CMD_TRANSFER_SEND_2D and
+ VIRTIO_GPU_CMD_RESOURCE_FLUSH as for guest-allocated memory.
+\end{itemize*}
+
\subsubsection{Device Operation: Multihead setup}
In case two or more displays are present there are different ways to
@@ -171,6 +189,7 @@ enum virtio_gpu_ctrl_type {
VIRTIO_GPU_CMD_TRANSFER_TO_HOST_2D,
VIRTIO_GPU_CMD_RESOURCE_ATTACH_BACKING,
VIRTIO_GPU_CMD_RESOURCE_DETACH_BACKING,
+VIRTIO_GPU_CMD_RESOURCE_ALLOC_BACKING,
/* cursor commands */
VIRTIO_GPU_CMD_UPDATE_CURSOR = 0x0300,
@@ -179,6 +198,7 @@ enum virtio_gpu_ctrl_type {
/* success responses */
VIRTIO_GPU_RESP_OK_NODATA = 0x1100,
VIRTIO_GPU_RESP_OK_DISPLAY_INFO,
+VIRTIO_GPU_RESP_OK_ALLOC_BACKING,
/* error responses */
VIRTIO_GPU_RESP_ERR_UNSPEC = 0x1200,
@@ -417,6 +437,34 @@ struct virtio_gpu_resource_detach_backing {
This detaches any backing pages from a resource, to be used in case of
guest swapping or object destruction.
+\item[VIRTIO_GPU_CMD_RESOURCE_ALLOC_BACKING] Request the host to allocate
+ backing pages for a resource. Request data is \field{struct
+virtio_gpu_resource_alloc_backing}. Response type is
+VIRTIO_GPU_RESP_OK_ALLOC_BACKING, response data is \field{struct
+virtio_gpu_resp_resource_alloc_backing}.
+
+\begin{lstlisting}
+struct virtio_gpu_resource_alloc_backing {
+struct virtio_gpu_ctrl_hdr hdr;
+le32 resource_id;
+le32 padding;
+};
+
+struct virtio_gpu_resp_resource_alloc_backing {
+struct virtio_gpu_ctrl_hdr hdr;
+le64 addr;
+};
+\end{lstlisting}
+
+This allocates backing store memory for a resource on the host, and maps the
+memory physically contiguous to the guest. The host returns the guest memory
+address in the \field{addr} field. If memory can't be allocated, the response
+is VIRTIO_GPU_RESP_ERR_OUT_OF_MEMORY with no data.
+
+When the backing store is detached from the resource with
+VIRTIO_GPU_CMD_RESOURCE_DETACH_BACKING, the memory is freed and unmapped from
+the guest.
+
\end{description}
\subsubsection{Device Operation: cursorq}\label{sec:Device Types / GPU Device
/ Device Operation / Device Operation: cursorq}
--
Regards,
Laurent Pinchart
Re: [PATCH] arm64: dts: renesas: Fix VSPD registers range
Hi Sergei,
(CC'ing Olof)
On Friday, 8 June 2018 19:41:01 EEST Sergei Shtylyov wrote:
> On 06/08/2018 03:21 PM, Laurent Pinchart wrote:
> > The VSPD and FCPVD nodes have overlapping register ranges, as the FCPVD
> > devices are mapped in the memory range usually used by the VSP LUT and
> > CLU, which are not present in the VSPD. Fix this by shortening the VSPD
> > registers range to 0x5000.
> >
> > Fixes: 9f8573e38a0b ("arm64: dts: renesas: r8a7795: Add VSP instances")
> > Fixes: 291e0c4994d0 ("arm64: dts: r8a7795: Add support for R-Car H3
> > ES2.0")
> > Fixes: f06ffdfbdd90 ("arm64: dts: r8a7796: Add VSP instances")
> > Fixes: b4f92030d5d3 ("arm64: dts: renesas: r8a77970: add VSPD support")
> > Fixes: 295952a183d3 ("arm64: dts: renesas: r8a77995: add VSP instances")
> > Fixes: 85cb3229218a ("arm64: dts: renesas: r8a77965: Add VSP instances")
>
> That'd be a nightmare for the -stable maintainers -- all those commits
> were made in the different time, so constant rejects are warranted.
>
> > Reported-by: Simon Horman
> > Reported-by: Geert Uytterhoeven
> > Signed-off-by: Laurent Pinchart
> >
> > ---
> > Changes since v1:
> >
> > - Fix H3, M3-W and M3-N in addition to V3H and D3
> > - Don't touch the VSPBS instance of D3 as there's no overlap
> > - Squash all patches together
>
> Don't think that was a good idea in this case. Other opinions?
We have been requested ([1]) to try and group the DT changes, hence this
change. No clear rule has been set, and this might be a case where a split is
better. Olof, what would you prefer ?
[1] https://www.spinics.net/lists/arm-kernel/msg657208.html
--
Regards,
Laurent Pinchart
Re: [PATCH v2 0/5] Add R8A77980/Condor/V3HSK LVDS/HDMI support
Hi Sergei, On Thursday, 7 June 2018 23:17:03 EEST Sergei Shtylyov wrote: > Hello! > > Here's the set of 5 patches against Simon Horman's 'renesas.git' repo's > 'renesas-devel-20180604-v4.17' tag. We're adding the R8A77980 FCPVD/VSPD/ > DU/LVDS device nodes and then describing the LVDS decoder and HDMI encoder > connected to the LVDS output. These patches depend on the Thine THC63LVD1024 > driver and the R8A77980 LVDS support patch in order to work, and R8A77980 > GPIO DT patches in order to apply/compile... > > [1/5] arm64: dts: renesas: r8a77980: add FCPVD support > [2/5] arm64: dts: renesas: r8a77980: add VSPD support > [3/5] arm64: dts: renesas: r8a77980: add DU support > [4/5] arm64: dts: renesas: r8a77980: add LVDS support Based on the recent request of the ARM SoC maintainers to avoid a plethora of small patches, I think you can squash 1/5 to 4/5 all together. > [5/5] arm64: dts: renesas: condor/v3hsk: add DU/LVDS/HDMI support -- Regards, Laurent Pinchart
Re: [PATCH v2 4/5] arm64: dts: renesas: r8a77980: add LVDS support
Hi Sergei,
Thank you for the patch.
On Thursday, 7 June 2018 23:23:06 EEST Sergei Shtylyov wrote:
> Define the generic R8A77980 part of the LVDS device node.
>
> Signed-off-by: Sergei Shtylyov
Reviewed-by: Laurent Pinchart
> ---
> arch/arm64/boot/dts/renesas/r8a77980.dtsi | 29 ++
> 1 file changed, 29 insertions(+)
>
> Index: renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
> ===
> --- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
> +++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
> @@ -696,6 +696,35 @@
> port@1 {
> reg = <1>;
> du_out_lvds0: endpoint {
> + remote-endpoint = <_in>;
> + };
> + };
> + };
> + };
> +
> + lvds0: lvds-encoder@feb9 {
> + compatible = "renesas,r8a77980-lvds";
> + reg = <0 0xfeb9 0 0x14>;
> + clocks = < CPG_MOD 727>;
> + power-domains = < R8A77980_PD_ALWAYS_ON>;
> + resets = < 727>;
> + status = "disabled";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + lvds0_in: endpoint {
> + remote-endpoint =
> + <_out_lvds0>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + lvds0_out: endpoint {
> };
> };
> };
--
Regards,
Laurent Pinchart
Re: [PATCH v2 1/5] arm64: dts: renesas: r8a77980: add FCPVD support
Hi Sergei,
Thank you for the patch.
On Thursday, 7 June 2018 23:19:31 EEST Sergei Shtylyov wrote:
> Describe FCPVD0 in the R8A77980 device tree; it will be used by VSPD0 in
> the next patch...
>
> Based on the original (and large) patch by Vladimir Barinov.
>
> Signed-off-by: Vladimir Barinov
> Signed-off-by: Sergei Shtylyov
Reviewed-by: Laurent Pinchart
> ---
> arch/arm64/boot/dts/renesas/r8a77980.dtsi |8
> 1 file changed, 8 insertions(+)
>
> Index: renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
> ===
> --- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
> +++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
> @@ -653,6 +653,14 @@
> resets = < 408>;
> };
>
> + fcpvd0: fcp@fea27000 {
> + compatible = "renesas,fcpv";
> + reg = <0 0xfea27000 0 0x200>;
> + clocks = < CPG_MOD 603>;
> + power-domains = < R8A77980_PD_ALWAYS_ON>;
> + resets = < 603>;
> + };
> +
> prr: chipid@fff00044 {
> compatible = "renesas,prr";
> reg = <0 0xfff00044 0 4>;
--
Regards,
Laurent Pinchart
Re: [PATCH v2 3/5] arm64: dts: renesas: r8a77980: add DU support
Hi Sergei,
Thank you for the patch.
On Thursday, 7 June 2018 23:21:38 EEST Sergei Shtylyov wrote:
> Define the generic R8A77980 part of the DU device node.
>
> Based on the original (and large) patch by Vladimir Barinov.
>
> Signed-off-by: Vladimir Barinov
> Signed-off-by: Sergei Shtylyov
Reviewed-by: Laurent Pinchart
> ---
> arch/arm64/boot/dts/renesas/r8a77980.dtsi | 30 ++
> 1 file changed, 30 insertions(+)
>
> Index: renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
> ===
> --- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
> +++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
> @@ -671,6 +671,36 @@
> resets = < 603>;
> };
>
> + du: display@feb0 {
> + compatible = "renesas,du-r8a77980",
> + "renesas,du-r8a77970";
> + reg = <0 0xfeb0 0 0x8>;
> + interrupts = ;
> + clocks = < CPG_MOD 724>;
> + clock-names = "du.0";
> + power-domains = < R8A77980_PD_ALWAYS_ON>;
> + resets = < 724>;
> + vsps = <>;
> + status = "disabled";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + du_out_rgb: endpoint {
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + du_out_lvds0: endpoint {
> + };
> + };
> + };
> + };
> +
> prr: chipid@fff00044 {
> compatible = "renesas,prr";
> reg = <0 0xfff00044 0 4>;
--
Regards,
Laurent Pinchart
Re: [PATCH v2 2/5] arm64: dts: renesas: r8a77980: add VSPD support
Hello Simon,
On Friday, 8 June 2018 16:54:56 EEST Simon Horman wrote:
> [CC Laurent, Geert]
>
> On Thu, Jun 07, 2018 at 11:20:47PM +0300, Sergei Shtylyov wrote:
> > Describe VSPD0 in the R8A77980 device tree; it will be used by DU in
> > the next patch...
> >
> > Based on the original (and large) patch by Vladimir Barinov.
> >
> > Signed-off-by: Vladimir Barinov
> > Signed-off-by: Sergei Shtylyov
> >
> > ---
> >
> > arch/arm64/boot/dts/renesas/r8a77980.dtsi | 10 ++
> > 1 file changed, 10 insertions(+)
> >
> > Index: renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
> > ===
> > --- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
> > +++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
> > @@ -653,6 +653,16 @@
> > resets = < 408>;
> > };
> >
> > + vspd0: vsp@fea2 {
> > + compatible = "renesas,vsp2";
> > + reg = <0 0xfea2 0 0x4000>;
>
> As per "[PATCH] arm64: dts: renesas: Fix VSPD registers range"
> I think the width of the range should be 0x5000.
I agree with that.
> > + interrupts = ;
> > + clocks = < CPG_MOD 623>;
> > + power-domains = < R8A77980_PD_ALWAYS_ON>;
> > + resets = < 623>;
> > + renesas,fcp = <>;
> > + };
> > +
> > fcpvd0: fcp@fea27000 {
> > compatible = "renesas,fcpv";
> > reg = <0 0xfea27000 0 0x200>;
--
Regards,
Laurent Pinchart
Re: [PATCH 2/2] arm64: dts: renesas: r8a77995: Fix VSP registers range
Hi Geert,
On Friday, 8 June 2018 14:53:28 EEST Geert Uytterhoeven wrote:
> On Fri, Jun 8, 2018 at 1:18 PM Laurent Pinchart wrote:
> > The R8A77995 VSP and FCP nodes have overlapping register ranges, as the
> > SoC integrates the FCP devices in the memory range usually used by the
> > VSP LUT and CLUT, which are not present. Fix this by shortening the VSP
> > registers range to 0x5000.
>
> According to datasheet rev. 1.00, the CLUT is present on R-Car D3, the
> LUT is not.
That was a typo, the commit message should have mentioned CLU, not CLUT. I've
sent a v2 that fixes this and covers the H3 and M3* SoCs.
> > Fixes: 295952a183d3 ("arm64: dts: renesas: r8a77995: add VSP instances")
> > Reported-by: Simon Horman
> > Reported-by: Geert Uytterhoeven
> > Signed-off-by: Laurent Pinchart
> >
>
> Apart from my comment above:
> Reviewed-by: Geert Uytterhoeven
--
Regards,
Laurent Pinchart
[PATCH] arm64: dts: renesas: Fix VSPD registers range
The VSPD and FCPVD nodes have overlapping register ranges, as the FCPVD
devices are mapped in the memory range usually used by the VSP LUT and
CLU, which are not present in the VSPD. Fix this by shortening the VSPD
registers range to 0x5000.
Fixes: 9f8573e38a0b ("arm64: dts: renesas: r8a7795: Add VSP instances")
Fixes: 291e0c4994d0 ("arm64: dts: r8a7795: Add support for R-Car H3 ES2.0")
Fixes: f06ffdfbdd90 ("arm64: dts: r8a7796: Add VSP instances")
Fixes: b4f92030d5d3 ("arm64: dts: renesas: r8a77970: add VSPD support")
Fixes: 295952a183d3 ("arm64: dts: renesas: r8a77995: add VSP instances")
Fixes: 85cb3229218a ("arm64: dts: renesas: r8a77965: Add VSP instances")
Reported-by: Simon Horman
Reported-by: Geert Uytterhoeven
Signed-off-by: Laurent Pinchart
---
Changes since v1:
- Fix H3, M3-W and M3-N in addition to V3H and D3
- Don't touch the VSPBS instance of D3 as there's no overlap
- Squash all patches together
---
arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi | 2 +-
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 6 +++---
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 6 +++---
arch/arm64/boot/dts/renesas/r8a77965.dtsi| 4 ++--
arch/arm64/boot/dts/renesas/r8a77970.dtsi| 2 +-
arch/arm64/boot/dts/renesas/r8a77995.dtsi| 4 ++--
6 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi
b/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi
index e19dcd6cb767..0a42b016f257 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi
@@ -80,7 +80,7 @@
vspd3: vsp@fea38000 {
compatible = "renesas,vsp2";
- reg = <0 0xfea38000 0 0x8000>;
+ reg = <0 0xfea38000 0 0x5000>;
interrupts = ;
clocks = < CPG_MOD 620>;
power-domains = < R8A7795_PD_ALWAYS_ON>;
diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 9b154ff33e67..6803c0075d51 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -2539,7 +2539,7 @@
vspd0: vsp@fea2 {
compatible = "renesas,vsp2";
- reg = <0 0xfea2 0 0x8000>;
+ reg = <0 0xfea2 0 0x5000>;
interrupts = ;
clocks = < CPG_MOD 623>;
power-domains = < R8A7795_PD_ALWAYS_ON>;
@@ -2550,7 +2550,7 @@
vspd1: vsp@fea28000 {
compatible = "renesas,vsp2";
- reg = <0 0xfea28000 0 0x8000>;
+ reg = <0 0xfea28000 0 0x5000>;
interrupts = ;
clocks = < CPG_MOD 622>;
power-domains = < R8A7795_PD_ALWAYS_ON>;
@@ -2561,7 +2561,7 @@
vspd2: vsp@fea3 {
compatible = "renesas,vsp2";
- reg = <0 0xfea3 0 0x8000>;
+ reg = <0 0xfea3 0 0x5000>;
interrupts = ;
clocks = < CPG_MOD 621>;
power-domains = < R8A7795_PD_ALWAYS_ON>;
diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 3ca3f56110fe..636090ce3ee8 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -2256,7 +2256,7 @@
vspd0: vsp@fea2 {
compatible = "renesas,vsp2";
- reg = <0 0xfea2 0 0x8000>;
+ reg = <0 0xfea2 0 0x5000>;
interrupts = ;
clocks = < CPG_MOD 623>;
power-domains = < R8A7796_PD_ALWAYS_ON>;
@@ -2267,7 +2267,7 @@
vspd1: vsp@fea28000 {
compatible = "renesas,vsp2";
- reg = <0 0xfea28000 0 0x8000>;
+ reg = <0 0xfea28000 0 0x5000>;
interrupts = ;
clocks = < CPG_MOD 622>;
power-domains = < R8A7796_PD_ALWAYS_ON>;
@@ -2278,7 +2278,7 @@
vspd2: vsp@fea3 {
compatible = "renesas,vsp2";
- reg = <0 0xfea3 0 0x8000>;
+ reg = <0 0xfea3 0 0x5000>;
interrupts = ;
clocks = < CPG_MOD 621>;
power-domains = < R8A7796_PD_ALWAYS_ON>;
diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
b/arch/arm64/boot/dts/renesas
[PATCH 1/2] arm64: dts: renesas: r8a77970: Fix VSP registers range
The R8A77970 VSP and FCP nodes have overlapping register ranges, as the
SoC integrates the FCP devices in the memory range usually used by the
VSP LUT and CLUT, which are not present. Fix this by shortening the VSP
registers range to 0x5000.
Fixes: b4f92030d5d3 ("arm64: dts: renesas: r8a77970: add VSPD support")
Reported-by: Simon Horman
Reported-by: Geert Uytterhoeven
Signed-off-by: Laurent Pinchart
---
arch/arm64/boot/dts/renesas/r8a77970.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a77970.dtsi
b/arch/arm64/boot/dts/renesas/r8a77970.dtsi
index 98a2317a16c4..89dc4e343b7c 100644
--- a/arch/arm64/boot/dts/renesas/r8a77970.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77970.dtsi
@@ -776,7 +776,7 @@
vspd0: vsp@fea2 {
compatible = "renesas,vsp2";
- reg = <0 0xfea2 0 0x8000>;
+ reg = <0 0xfea2 0 0x5000>;
interrupts = ;
clocks = < CPG_MOD 623>;
power-domains = < R8A77970_PD_ALWAYS_ON>;
--
Regards,
Laurent Pinchart
[PATCH 2/2] arm64: dts: renesas: r8a77995: Fix VSP registers range
The R8A77995 VSP and FCP nodes have overlapping register ranges, as the
SoC integrates the FCP devices in the memory range usually used by the
VSP LUT and CLUT, which are not present. Fix this by shortening the VSP
registers range to 0x5000.
Fixes: 295952a183d3 ("arm64: dts: renesas: r8a77995: add VSP instances")
Reported-by: Simon Horman
Reported-by: Geert Uytterhoeven
Signed-off-by: Laurent Pinchart
---
arch/arm64/boot/dts/renesas/r8a77995.dtsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
index eb23c85c561b..49ca64285092 100644
--- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
@@ -704,7 +704,7 @@
vspbs: vsp@fe96 {
compatible = "renesas,vsp2";
- reg = <0 0xfe96 0 0x8000>;
+ reg = <0 0xfe96 0 0x5000>;
interrupts = ;
clocks = < CPG_MOD 627>;
power-domains = < R8A77995_PD_ALWAYS_ON>;
@@ -714,7 +714,7 @@
vspd0: vsp@fea2 {
compatible = "renesas,vsp2";
- reg = <0 0xfea2 0 0x8000>;
+ reg = <0 0xfea2 0 0x5000>;
interrupts = ;
clocks = < CPG_MOD 623>;
power-domains = < R8A77995_PD_ALWAYS_ON>;
@@ -724,7 +724,7 @@
vspd1: vsp@fea28000 {
compatible = "renesas,vsp2";
- reg = <0 0xfea28000 0 0x8000>;
+ reg = <0 0xfea28000 0 0x5000>;
interrupts = ;
clocks = < CPG_MOD 622>;
power-domains = < R8A77995_PD_ALWAYS_ON>;
--
Regards,
Laurent Pinchart
[PATCH v5 0/2] R-Car DU: Convert DT to new DU and LVDS bindings
Hello, This small patch series contains the last two remaining patches from "[PATCH v4 00/16] R-Car DU: Convert LVDS code to bridge driver". Apart from the individual SoC patches being squashed together as requested by the ARM-SoC maintainers there's nothing special here. Laurent Pinchart (2): ARM: dts: rcar-gen2: Convert to new DU DT bindings arm64: dts: renesas: Convert to new LVDS DT bindings arch/arm/boot/dts/r8a7792.dtsi | 1 - arch/arm/boot/dts/r8a7794.dtsi | 1 - .../boot/dts/renesas/r8a7795-es1-salvator-x.dts| 3 +- arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts | 3 +- arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 3 +- .../arm64/boot/dts/renesas/r8a7795-salvator-xs.dts | 3 +- arch/arm64/boot/dts/renesas/r8a7795.dtsi | 36 ++ arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts | 3 +- arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts | 3 +- arch/arm64/boot/dts/renesas/r8a7796.dtsi | 36 ++ 10 files changed, 66 insertions(+), 26 deletions(-) -- Regards, Laurent Pinchart
Re: [PATCH v4 00/16] R-Car DU: Convert LVDS code to bridge driver
Hi Simon,
On Monday, 28 May 2018 12:39:17 EEST Simon Horman wrote:
> On Fri, May 25, 2018 at 01:23:53PM +0300, Laurent Pinchart wrote:
> > On Friday, 25 May 2018 13:13:20 EEST Simon Horman wrote:
> >> On Thu, May 24, 2018 at 11:00:52AM +0300, Laurent Pinchart wrote:
> >>> On Wednesday, 21 February 2018 18:39:25 EEST Simon Horman wrote:
> >>>> On Wed, Feb 21, 2018 at 01:10:30AM +0200, Laurent Pinchart wrote:
> >
> > [snip]
> >
> >>>>> Laurent Pinchart (11):
> >>>>> dt-bindings: display: renesas: Add R-Car LVDS encoder DT bindings
> >>>>> dt-bindings: display: renesas: Deprecate LVDS support in the DU
> >>>>> bindings
> >>>>> drm: rcar-du: Fix legacy DT to create LVDS encoder nodes
> >>>>> drm: rcar-du: Convert LVDS encoder code to bridge driver
> >>>>> ARM: dts: r8a7790: Convert to new LVDS DT bindings
> >>>>> ARM: dts: r8a7791: Convert to new LVDS DT bindings
> >>>>> ARM: dts: r8a7792: Convert to new DU DT bindings
> >>>>> ARM: dts: r8a7793: Convert to new LVDS DT bindings
> >>>>> ARM: dts: r8a7794: Convert to new DU DT bindings
> >>>>> arm64: dts: renesas: r8a7795: Convert to new LVDS DT bindings
> >>>>> arm64: dts: renesas: r8a7796: Convert to new LVDS DT bindings
> >>>>
> >>>> I have marked the dts patches above as deferred as they depend
> >>>> on the driver changes not to cause a regression. Please repost them
> >>>> or otherwise ping me once the driver dependencies are present in an
> >>>> rc release.
> >>>
> >>> The driver changes have made it to v4.17-rc1. Is it too late for v4.18
> >>> ?
> >>
> >> Unfortunately it is. Shall I apply them for v4.19?
> >
> > Please do.
>
> Hi Laurent,
>
> I'm sorry to have to ask this, but in the light of Olof Johansson's recent
> comments in ("Re: [GIT PULL] Renesas ARM64 Based SoC DT Updates for v4.18")
> please consider squashing the DTS patches and reposting.
It's about time we stopped trying to game the kernel patch statistics :-)
Before I repost, has there been a consensus on the new rule ? And how are we
expected to proceed from now on ?
--
Regards,
Laurent Pinchart
Re: [RFC PATCH v2 1/2] drm: Add generic colorkey properties
On Saturday, 26 May 2018 19:16:54 EEST Laurent Pinchart wrote:
> Hi Dimitri,
And sorry for the spelling mistake :-/
> Thank you for the patch.
>
> I'll review this in details, but as this patch is based on the "[PATCH/RFC
> 1/4] drm: Add colorkey properties" patch I've submitted, please retain the
> authorship, both in the Signed-off-by line, and in the patch author in git.
>
> On Saturday, 26 May 2018 18:56:22 EEST Dmitry Osipenko wrote:
> > Color keying is the action of replacing pixels matching a given color
> > (or range of colors) with transparent pixels in an overlay when
> > performing blitting. Depending on the hardware capabilities, the
> > matching pixel can either become fully transparent or gain adjustment
> > of the pixels component values.
> >
> > Color keying is found in a large number of devices whose capabilities
> > often differ, but they still have enough common features in range to
> > standardize color key properties. This commit adds nine generic DRM plane
> > properties related to the color keying to cover various HW capabilities.
> >
> > This patch is based on the initial work done by Laurent Pinchart, most of
> > credits for this patch goes to him.
> >
> > Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
> > ---
> >
> > drivers/gpu/drm/drm_atomic.c | 36 ++
> > drivers/gpu/drm/drm_blend.c | 229 +++
> > include/drm/drm_blend.h | 3 +
> > include/drm/drm_plane.h | 77
> > 4 files changed, 345 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 895741e9cd7d..5b808cb68654 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -799,6 +799,24 @@ static int drm_atomic_plane_set_property(struct
> > drm_plane *plane, state->rotation = val;
> >
> > } else if (property == plane->zpos_property) {
> >
> > state->zpos = val;
> >
> > + } else if (property == plane->colorkey.mode_property) {
> > + state->colorkey.mode = val;
> > + } else if (property == plane->colorkey.min_property) {
> > + state->colorkey.min = val;
> > + } else if (property == plane->colorkey.max_property) {
> > + state->colorkey.max = val;
> > + } else if (property == plane->colorkey.format_property) {
> > + state->colorkey.format = val;
> > + } else if (property == plane->colorkey.mask_property) {
> > + state->colorkey.mask = val;
> > + } else if (property == plane->colorkey.inverted_match_property) {
> > + state->colorkey.inverted_match = val;
> > + } else if (property == plane->colorkey.replacement_mask_property) {
> > + state->colorkey.replacement_mask = val;
> > + } else if (property == plane->colorkey.replacement_value_property) {
> > + state->colorkey.replacement_value = val;
> > + } else if (property == plane->colorkey.replacement_format_property) {
> > + state->colorkey.replacement_format = val;
> >
> > } else if (property == plane->color_encoding_property) {
> >
> > state->color_encoding = val;
> >
> > } else if (property == plane->color_range_property) {
> >
> > @@ -864,6 +882,24 @@ drm_atomic_plane_get_property(struct drm_plane
> > *plane,
> >
> > *val = state->rotation;
> >
> > } else if (property == plane->zpos_property) {
> >
> > *val = state->zpos;
> >
> > + } else if (property == plane->colorkey.mode_property) {
> > + *val = state->colorkey.mode;
> > + } else if (property == plane->colorkey.min_property) {
> > + *val = state->colorkey.min;
> > + } else if (property == plane->colorkey.max_property) {
> > + *val = state->colorkey.max;
> > + } else if (property == plane->colorkey.format_property) {
> > + *val = state->colorkey.format;
> > + } else if (property == plane->colorkey.mask_property) {
> > + *val = state->colorkey.mask;
> > + } else if (property == plane->colorkey.inverted_match_property) {
> > + *val = state->colorkey.inverted_match;
> > + } else if (property == plane->colorkey.replacement_mask_property) {
> > + *val = state->colorkey.replacement_mask;
> > + } else if (property == plane->colorkey.r
Re: [RFC PATCH v2 1/2] drm: Add generic colorkey properties
Hi Dimitri,
Thank you for the patch.
I'll review this in details, but as this patch is based on the "[PATCH/RFC
1/4] drm: Add colorkey properties" patch I've submitted, please retain the
authorship, both in the Signed-off-by line, and in the patch author in git.
On Saturday, 26 May 2018 18:56:22 EEST Dmitry Osipenko wrote:
> Color keying is the action of replacing pixels matching a given color
> (or range of colors) with transparent pixels in an overlay when
> performing blitting. Depending on the hardware capabilities, the
> matching pixel can either become fully transparent or gain adjustment
> of the pixels component values.
>
> Color keying is found in a large number of devices whose capabilities
> often differ, but they still have enough common features in range to
> standardize color key properties. This commit adds nine generic DRM plane
> properties related to the color keying to cover various HW capabilities.
>
> This patch is based on the initial work done by Laurent Pinchart, most of
> credits for this patch goes to him.
>
> Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
> ---
> drivers/gpu/drm/drm_atomic.c | 36 ++
> drivers/gpu/drm/drm_blend.c | 229 +++
> include/drm/drm_blend.h | 3 +
> include/drm/drm_plane.h | 77
> 4 files changed, 345 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 895741e9cd7d..5b808cb68654 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -799,6 +799,24 @@ static int drm_atomic_plane_set_property(struct
> drm_plane *plane, state->rotation = val;
> } else if (property == plane->zpos_property) {
> state->zpos = val;
> + } else if (property == plane->colorkey.mode_property) {
> + state->colorkey.mode = val;
> + } else if (property == plane->colorkey.min_property) {
> + state->colorkey.min = val;
> + } else if (property == plane->colorkey.max_property) {
> + state->colorkey.max = val;
> + } else if (property == plane->colorkey.format_property) {
> + state->colorkey.format = val;
> + } else if (property == plane->colorkey.mask_property) {
> + state->colorkey.mask = val;
> + } else if (property == plane->colorkey.inverted_match_property) {
> + state->colorkey.inverted_match = val;
> + } else if (property == plane->colorkey.replacement_mask_property) {
> + state->colorkey.replacement_mask = val;
> + } else if (property == plane->colorkey.replacement_value_property) {
> + state->colorkey.replacement_value = val;
> + } else if (property == plane->colorkey.replacement_format_property) {
> + state->colorkey.replacement_format = val;
> } else if (property == plane->color_encoding_property) {
> state->color_encoding = val;
> } else if (property == plane->color_range_property) {
> @@ -864,6 +882,24 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
> *val = state->rotation;
> } else if (property == plane->zpos_property) {
> *val = state->zpos;
> + } else if (property == plane->colorkey.mode_property) {
> + *val = state->colorkey.mode;
> + } else if (property == plane->colorkey.min_property) {
> + *val = state->colorkey.min;
> + } else if (property == plane->colorkey.max_property) {
> + *val = state->colorkey.max;
> + } else if (property == plane->colorkey.format_property) {
> + *val = state->colorkey.format;
> + } else if (property == plane->colorkey.mask_property) {
> + *val = state->colorkey.mask;
> + } else if (property == plane->colorkey.inverted_match_property) {
> + *val = state->colorkey.inverted_match;
> + } else if (property == plane->colorkey.replacement_mask_property) {
> + *val = state->colorkey.replacement_mask;
> + } else if (property == plane->colorkey.replacement_value_property) {
> + *val = state->colorkey.replacement_value;
> + } else if (property == plane->colorkey.replacement_format_property) {
> + *val = state->colorkey.replacement_format;
> } else if (property == plane->color_encoding_property) {
> *val = state->color_encoding;
> } else if (property == plane->color_range_property) {
> diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> index a16a74d7e15e..05e5632ce375 100644
> --- a/drivers/gpu/d
Re: [PATCH 4/8] drm/rcar-du: fix merge conflict for state->alpha
Hi Arnd,
Thank you for the patch.
On Friday, 25 May 2018 18:50:11 EEST Arnd Bergmann wrote:
> The "alpha" struct member was removed in one commit but another user
> added in another, leading to a build failure:
>
> drivers/gpu/drm/rcar-du/rcar_du_vsp.c: In function
> 'rcar_du_vsp_plane_atomic_duplicate_state':
> drivers/gpu/drm/rcar-du/rcar_du_vsp.c:325:6: error: 'struct
> rcar_du_vsp_plane_state' has no member named 'alpha' copy->alpha =
> to_rcar_vsp_plane_state(plane->state)->alpha;
>
> This fixes up the merge by using the correct member.
>
> Fixes: 75a07f399cd4 ("drm: rcar-du: Zero-out sg_tables when duplicating
> plane state") Fixes: 301a9b8d5456 ("drm/rcar-du: Convert to the new generic
> alpha property") Signed-off-by: Arnd Bergmann <a...@arndb.de>
I have posted the same fix a week ago, see https://patchwork.freedesktop.org/
patch/msgid/20180515174752.28954-1-laurent.pinchart+rene...@ideasonboard.com.
The patch is in Dave's master branch in commit
315852b422972e6ebb1dfddaadada09e46a2681a.
> ---
> drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c index 4a98470626d5..d9232e749b6d
> 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> @@ -322,7 +322,7 @@ rcar_du_vsp_plane_atomic_duplicate_state(struct
> drm_plane *plane) return NULL;
>
> __drm_atomic_helper_plane_duplicate_state(plane, >state);
> - copy->alpha = to_rcar_vsp_plane_state(plane->state)->alpha;
> + copy->state.alpha = plane->state->alpha;
>
> return >state;
> }
--
Regards,
Laurent Pinchart
Re: [PATCH v4 00/16] R-Car DU: Convert LVDS code to bridge driver
Hi Simon, On Friday, 25 May 2018 13:13:20 EEST Simon Horman wrote: > On Thu, May 24, 2018 at 11:00:52AM +0300, Laurent Pinchart wrote: > > On Wednesday, 21 February 2018 18:39:25 EEST Simon Horman wrote: > >> On Wed, Feb 21, 2018 at 01:10:30AM +0200, Laurent Pinchart wrote: [snip] > >>> Laurent Pinchart (11): > >>> dt-bindings: display: renesas: Add R-Car LVDS encoder DT bindings > >>> dt-bindings: display: renesas: Deprecate LVDS support in the DU > >>> bindings > >>> drm: rcar-du: Fix legacy DT to create LVDS encoder nodes > >>> drm: rcar-du: Convert LVDS encoder code to bridge driver > >>> ARM: dts: r8a7790: Convert to new LVDS DT bindings > >>> ARM: dts: r8a7791: Convert to new LVDS DT bindings > >>> ARM: dts: r8a7792: Convert to new DU DT bindings > >>> ARM: dts: r8a7793: Convert to new LVDS DT bindings > >>> ARM: dts: r8a7794: Convert to new DU DT bindings > >>> arm64: dts: renesas: r8a7795: Convert to new LVDS DT bindings > >>> arm64: dts: renesas: r8a7796: Convert to new LVDS DT bindings > >> > >> I have marked the dts patches above as deferred as they depend > >> on the driver changes not to cause a regression. Please repost them > >> or otherwise ping me once the driver dependencies are present in an rc > >> release. > > > > The driver changes have made it to v4.17-rc1. Is it too late for v4.18 ? > > Unfortunately it is. Shall I apply them for v4.19? Please do. > >> I am assuming that the other patches in this series are not targeted > >> at the renesas tree. > > > > That's correct. > > > >>> Pantelis Antoniou (5): > >>> of: dynamic: Add __of_node_dupv() > >>> of: changesets: Introduce changeset helper methods > >>> of: changeset: Add of_changeset_node_move method > >>> of: unittest: changeset helpers > >>> i2c: demux: Use changeset helpers for clarity > >> > >> ... -- Regards, Laurent Pinchart
[PATCH] v4l: vsp1: Fix YCbCr planar formats pitch calculation
From: Koji Matsuoka <koji.matsuoka...@renesas.com> YCbCr planar formats can have different pitch values for the luma and chroma planes. This isn't taken into account in the driver. Fix it. Based on a BSP patch from Koji Matsuoka <koji.matsuoka...@renesas.com>. Signed-off-by: Koji Matsuoka <koji.matsuoka...@renesas.com> Signed-off-by: Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.com> --- drivers/media/platform/vsp1/vsp1_drm.c | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/drivers/media/platform/vsp1/vsp1_drm.c b/drivers/media/platform/vsp1/vsp1_drm.c index edb35a5c57ea..917f60f553fc 100644 --- a/drivers/media/platform/vsp1/vsp1_drm.c +++ b/drivers/media/platform/vsp1/vsp1_drm.c @@ -771,6 +771,7 @@ int vsp1_du_atomic_update(struct device *dev, unsigned int pipe_index, struct vsp1_device *vsp1 = dev_get_drvdata(dev); struct vsp1_drm_pipeline *drm_pipe = >drm->pipe[pipe_index]; const struct vsp1_format_info *fmtinfo; + unsigned int chroma_hsub; struct vsp1_rwpf *rpf; if (rpf_index >= vsp1->info->rpf_count) @@ -811,10 +812,18 @@ int vsp1_du_atomic_update(struct device *dev, unsigned int pipe_index, return -EINVAL; } + /* +* Only formats with three planes can affect the chroma planes pitch. +* All formats with two planes have a horizontal subsampling value of 2, +* but combine U and V in a single chroma plane, which thus results in +* the luma plane and chroma plane having the same pitch. +*/ + chroma_hsub = (fmtinfo->planes == 3) ? fmtinfo->hsub : 1; + rpf->fmtinfo = fmtinfo; rpf->format.num_planes = fmtinfo->planes; rpf->format.plane_fmt[0].bytesperline = cfg->pitch; - rpf->format.plane_fmt[1].bytesperline = cfg->pitch; + rpf->format.plane_fmt[1].bytesperline = cfg->pitch / chroma_hsub; rpf->alpha = cfg->alpha; rpf->mem.addr[0] = cfg->mem[0]; -- Regards, Laurent Pinchart
[PATCH] v4l: vsp1: Update LIF buffer thresholds
The LIF module has a data buffer to accommodate clock rate differences
between the DU and the VSP. Several programmable threshold values
control DU start of frame notification by the VSP and VSP clock
stop/resume. The R-Car Gen2 and Gen3 datasheets recommend values for the
different SoCs. Update the driver to use the recommended values for
optimal operation.
Based on a BSP patch from Koji Matsuoka <koji.matsuoka...@renesas.com>,
with Gen2 and V3H/V3M updates.
Signed-off-by: Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.com>
---
drivers/media/platform/vsp1/vsp1_lif.c | 29 +
1 file changed, 25 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/vsp1/vsp1_lif.c
b/drivers/media/platform/vsp1/vsp1_lif.c
index 0cb63244b21a..d313fa19eecb 100644
--- a/drivers/media/platform/vsp1/vsp1_lif.c
+++ b/drivers/media/platform/vsp1/vsp1_lif.c
@@ -88,14 +88,35 @@ static void lif_configure_stream(struct vsp1_entity *entity,
{
const struct v4l2_mbus_framefmt *format;
struct vsp1_lif *lif = to_lif(>subdev);
- unsigned int hbth = 1300;
- unsigned int obth = 400;
- unsigned int lbth = 200;
+ unsigned int hbth;
+ unsigned int obth;
+ unsigned int lbth;
format = vsp1_entity_get_pad_format(>entity, lif->entity.config,
LIF_PAD_SOURCE);
- obth = min(obth, (format->width + 1) / 2 * format->height - 4);
+ switch (entity->vsp1->version & VI6_IP_VERSION_SOC_MASK) {
+ case VI6_IP_VERSION_MODEL_VSPD_GEN2:
+ case VI6_IP_VERSION_MODEL_VSPD_V2H:
+ hbth = 1536;
+ obth = min(128, (format->width + 1) / 2 * format->height - 4);
+ lbth = 1520;
+ break;
+
+ case VI6_IP_VERSION_MODEL_VSPDL_GEN3:
+ case VI6_IP_VERSION_MODEL_VSPD_V3:
+ hbth = 0;
+ obth = 1500;
+ lbth = 0;
+ break;
+
+ case VI6_IP_VERSION_MODEL_VSPD_GEN3:
+ default:
+ hbth = 0;
+ obth = 3000;
+ lbth = 0;
+ break;
+ }
vsp1_lif_write(lif, dlb, VI6_LIF_CSBTH,
(hbth << VI6_LIF_CSBTH_HBTH_SHIFT) |
--
Regards,
Laurent Pinchart
Re: [PATCH v4 10/11] media: vsp1: Support Interlaced display pipelines
ivers/media/platform/vsp1/vsp1_rwpf.h index 70742ecf766f..8d6e42f27908
> 100644
> --- a/drivers/media/platform/vsp1/vsp1_rwpf.h
> +++ b/drivers/media/platform/vsp1/vsp1_rwpf.h
> @@ -42,6 +42,7 @@ struct vsp1_rwpf {
> struct v4l2_pix_format_mplane format;
> const struct vsp1_format_info *fmtinfo;
> unsigned int brx_input;
> + bool interlaced;
Shouldn't this be stored in the pipeline instead ? Interlacing is a property
of the whole pipeline, not of each input individually.
> unsigned int alpha;
>
> diff --git a/include/media/vsp1.h b/include/media/vsp1.h
> index 678c24de1ac6..c10883f30980 100644
> --- a/include/media/vsp1.h
> +++ b/include/media/vsp1.h
> @@ -50,6 +50,7 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int
> pipe_index,
> * @dst: destination rectangle on the display (integer coordinates)
> * @alpha: alpha value (0: fully transparent, 255: fully opaque)
> * @zpos: Z position of the plane (from 0 to number of planes minus 1)
> + * @interlaced: true for interlaced pipelines
> */
> struct vsp1_du_atomic_config {
> u32 pixelformat;
> @@ -59,6 +60,7 @@ struct vsp1_du_atomic_config {
> struct v4l2_rect dst;
> unsigned int alpha;
> unsigned int zpos;
> + bool interlaced;
For the same reason shouldn't the interlaced flag be moved to
vsp1_du_lif_config ?
> };
>
> /**
--
Regards,
Laurent Pinchart
Re: [PATCH v4 09/11] media: vsp1: Provide support for extended command pools
pool);
> + vsp1_dl_ext_cmd_pool_destroy(dlm->autofld_cmds);
> +}
> +
> +struct vsp1_dl_ext_cmd *vsp1_dlm_get_autofld_cmd(struct vsp1_dl_list *dl)
> +{
> + struct vsp1_dl_manager *dlm = dl->dlm;
> + struct vsp1_dl_ext_cmd *cmd;
> +
> + if (dl->pre_cmd)
> + return dl->pre_cmd;
> +
> + cmd = vsp1_dl_ext_cmd_get(dlm->autofld_cmds);
> + if (cmd)
> + dl->pre_cmd = cmd;
> +
> + return cmd;
You can write it in a simpler way.
dl->pre_cmd = vsp1_dl_ext_cmd_get(dlm->autofld_cmds);
return dl->pre_cmd;
> }
> diff --git a/drivers/media/platform/vsp1/vsp1_dl.h
> b/drivers/media/platform/vsp1/vsp1_dl.h index aa5f4adc6617..d9621207b093
> 100644
> --- a/drivers/media/platform/vsp1/vsp1_dl.h
> +++ b/drivers/media/platform/vsp1/vsp1_dl.h
> @@ -22,6 +22,7 @@ struct vsp1_dl_manager;
>
> /**
> * struct vsp1_dl_ext_cmd - Extended Display command
> + * @pool: pool to which this command belongs
> * @free: entry in the pool of free commands list
> * @cmd_opcode: command type opcode
> * @flags: flags used by the command
> @@ -33,6 +34,7 @@ struct vsp1_dl_manager;
> * @data_size: size of the @data_dma memory in bytes
> */
> struct vsp1_dl_ext_cmd {
> + struct vsp1_dl_cmd_pool *pool;
> struct list_head free;
>
> u8 cmd_opcode;
> @@ -55,6 +57,7 @@ struct vsp1_dl_manager *vsp1_dlm_create(struct vsp1_device
> *vsp1, void vsp1_dlm_destroy(struct vsp1_dl_manager *dlm);
> void vsp1_dlm_reset(struct vsp1_dl_manager *dlm);
> unsigned int vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm);
> +struct vsp1_dl_ext_cmd *vsp1_dlm_get_autofld_cmd(struct vsp1_dl_list *dl);
Should this be named vsp1_dl_get_autofld_cmd() as it operates on a dl ? I also
think that you should move it down to group it with the dl functions.
> struct vsp1_dl_list *vsp1_dl_list_get(struct vsp1_dl_manager *dlm);
> void vsp1_dl_list_put(struct vsp1_dl_list *dl);
--
Regards,
Laurent Pinchart
Re: [PATCH v4 11/11] drm: rcar-du: Support interlaced video output through vsp1
Hi Kieran, Thank you for the patch. On Thursday, 3 May 2018 16:36:22 EEST Kieran Bingham wrote: > Use the newly exposed VSP1 interface to enable interlaced frame support > through the VSP1 lif pipelines. s/lif/LIF/ > > Signed-off-by: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com> > --- > drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 1 + > drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 3 +++ > 2 files changed, 4 insertions(+) > > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c > b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c index d71d709fe3d9..206532959ec9 > 100644 > --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c > +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c > @@ -289,6 +289,7 @@ static void rcar_du_crtc_set_display_timing(struct > rcar_du_crtc *rcrtc) /* Signal polarities */ > value = ((mode->flags & DRM_MODE_FLAG_PVSYNC) ? DSMR_VSL : 0) > | ((mode->flags & DRM_MODE_FLAG_PHSYNC) ? DSMR_HSL : 0) > + | ((mode->flags & DRM_MODE_FLAG_INTERLACE) ? DSMR_ODEV : 0) How will this affect Gen2 ? Could you document what this change does in the commit message ? > | DSMR_DIPM_DISP | DSMR_CSPM; > > rcar_du_crtc_write(rcrtc, DSMR, value); > > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c > b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c index af7822a66dee..c7b37232ee91 > 100644 > --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c > +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c > @@ -186,6 +186,9 @@ static void rcar_du_vsp_plane_setup(struct > rcar_du_vsp_plane *plane) }; > unsigned int i; > > + cfg.interlaced = !!(plane->plane.state->crtc->mode.flags > + & DRM_MODE_FLAG_INTERLACE); > + > cfg.src.left = state->state.src.x1 >> 16; > cfg.src.top = state->state.src.y1 >> 16; > cfg.src.width = drm_rect_width(>state.src) >> 16; -- Regards, Laurent Pinchart
