On 1/12/2018 4:13 AM, Laurent Pinchart wrote:
Add support for the R-Car V3M (R8A77970) SoC to the DU driver (this SoC has only 1 display port). Note that there are some differences with the other R-Car gen3 SoCs in the LVDS encoder part, e.g. LVDPLLCR has the same layout as on the R-Car gen2 SoCs...
Signed-off-by: Sergei Shtylyov sergei.shtylyov@cogentembedded.com
Could you please rebase this series on top of the LVDS rework posted as "[PATCH 00/10] R-Car DU: Convert LVDS code to bridge driver" (https:// www.spinics.net/lists/dri-devel/msg161931.html) ? It should make it easier to implement support for V3M. Please then split the DU and LVDS drivers changes in two patches.
Documentation/devicetree/bindings/display/renesas,du.txt | 1
Please split the DT bindings changes to a separate patch.
I don't like putting a one-line chnage into a separate bindings patch...
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 23 +++++++++++ drivers/gpu/drm/rcar-du/rcar_du_drv.h | 1 drivers/gpu/drm/rcar-du/rcar_du_group.c | 10 +++--- drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 20 +++++++---- 5 files changed, 45 insertions(+), 10 deletions(-)
Index: linux/Documentation/devicetree/bindings/display/renesas,du.txt
--- linux.orig/Documentation/devicetree/bindings/display/renesas,du.txt +++ linux/Documentation/devicetree/bindings/display/renesas,du.txt @@ -13,6 +13,7 @@ Required Properties: - "renesas,du-r8a7794" for R8A7794 (R-Car E2) compatible DU - "renesas,du-r8a7795" for R8A7795 (R-Car H3) compatible DU - "renesas,du-r8a7796" for R8A7796 (R-Car M3-W) compatible DU
"renesas,du-r8a77970" for R8A77970 (R-Car V3M) compatible DU
reg: A list of base address and length of each memory resource, one for
each entry in the reg-names property.
You also need to update the ports table further down in this file.
... but this one seems to justify dpoing it that way. :-)
Index: linux/drivers/gpu/drm/rcar-du/rcar_du_drv.c
--- linux.orig/drivers/gpu/drm/rcar-du/rcar_du_drv.c +++ linux/drivers/gpu/drm/rcar-du/rcar_du_drv.c @@ -258,6 +258,28 @@ static const struct rcar_du_device_info .dpll_ch = BIT(1), };
+static const struct rcar_du_device_info rcar_du_r8a77970_info = {
- .gen = 3,
- .model = R8A77970,
- .features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK
| RCAR_DU_FEATURE_EXT_CTRL_REGS| RCAR_DU_FEATURE_VSP1_SOURCE,- .num_crtcs = 1,
- .routes = {
/* R8A77970 has one RGB output and one LVDS output. */[RCAR_DU_OUTPUT_DPAD0] = {.possible_crtcs = BIT(0),.port = 1,},[RCAR_DU_OUTPUT_LVDS0] = {.possible_crtcs = BIT(0),.port = 0,},All the other SoCs have DPAD0 as port 0. Unless there's a specific need for a different implementation with V3M I'd keep the same order.
I'll look into this..
- },
- .num_lvds = 1,
- .dpll_ch = BIT(1),
This doesn't seem to be correct, there's no DPLL in V3M.
Indeed, thanks!
[...]
Index: linux/drivers/gpu/drm/rcar-du/rcar_du_group.c
--- linux.orig/drivers/gpu/drm/rcar-du/rcar_du_group.c +++ linux/drivers/gpu/drm/rcar-du/rcar_du_group.c @@ -133,10 +133,12 @@ static void rcar_du_group_setup(struct r rcar_du_group_write(rgrp, DORCR, DORCR_PG1D_DS1 | DORCR_DPRS);
/* Apply planes to CRTCs association. */
- mutex_lock(&rgrp->lock);
- rcar_du_group_write(rgrp, DPTSR, (rgrp->dptsr_planes << 16) |
rgrp->dptsr_planes);- mutex_unlock(&rgrp->lock);
- if (rcdu->info->num_crtcs > 1) {
mutex_lock(&rgrp->lock);rcar_du_group_write(rgrp, DPTSR, (rgrp->dptsr_planes << 16) |rgrp->dptsr_planes);mutex_unlock(&rgrp->lock);- }
Shouldn't you skip writing to the DPTSR register if there's a single DPTSR in the group ? That would then apply to M3-W as well, which doesn't have the DPTSR2 register. I'd split this change to a separate patch.
OK, I guess you know this stuff better -- I didn't know DPTSR2 is used at all... :-)
[...]
Index: linux/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
--- linux.orig/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c +++ linux/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
[...]
@@ -177,14 +185,14 @@ int rcar_du_lvdsenc_enable(struct rcar_d void rcar_du_lvdsenc_atomic_check(struct rcar_du_lvdsenc *lvds, struct drm_display_mode *mode) {
- struct rcar_du_device *rcdu = lvds->dev;
const struct rcar_du_device_info *info = lvds->dev->info;
/*
- The internal LVDS encoder has a restricted clock frequency operating
* range (30MHz to 150MHz on Gen2, 25.175MHz to 148.5MHz on Gen3). Clamp* the clock accordingly.
* range (30MHz to 150MHz on Gen2 and R-Car V3M, 25.175MHz to 148.5MHz* on Gen3). Clamp the clock accordingly.
- if (rcdu->info->gen < 3)
- if (info->gen < 3 || info->model == R8A77970) mode->clock = clamp(mode->clock, 30000, 150000);
According to the datasheet the frequency range for V3M is the same as for the H3 and M3 SoCs.
Indeed! I thought it's determined by the LVDPLLCR layout but it's not...
The range seems to have changed starting in datasheet version 0.52. I would fix the range in a separate patch first.
Yes.
If you want I can send patches to fix this issue
Yes, please. You clearly know about DU more than me. :-)
and the previous one, or you can write them and include them in v2. Let me know what you'd prefer.
else mode->clock = clamp(mode->clock, 25175, 148500);
The lower bound documented on gen3 is 31 MHz indeed...
MBR, Sergei