linux-toradex.git/drivers/gpu/drm/rcar-du, branch master

drm: Place Renesas drivers in a separate dir

2023-05-29T13:41:03+00:00

Create vendor specific renesas directory and move renesas drivers
to that directory.

Signed-off-by: Biju Das 
Acked-by: Kieran Bingham 
Reviewed-by: Laurent Pinchart 
Signed-off-by: Laurent Pinchart

drm: rcar-du: remove R-Car H3 ES1.* workarounds

2023-05-29T13:26:29+00:00

R-Car H3 ES1.* was only available to an internal development group and
needed a lot of quirks and workarounds. These become a maintenance
burden now, so our development group decided to remove upstream support
for this SoC and prevent booting it. Public users only have ES2 onwards.

Signed-off-by: Wolfram Sang 
Reviewed-by: Kieran Bingham 
Reviewed-by: Laurent Pinchart 
Signed-off-by: Laurent Pinchart

drm: rcar-du: Fix a NULL vs IS_ERR() bug

2023-03-25T20:38:10+00:00

The drmm_encoder_alloc() function returns error pointers.  It never
returns NULL.  Fix the check accordingly.

Fixes: 7a1adbd23990 ("drm: rcar-du: Use drmm_encoder_alloc() to manage encoder")
Signed-off-by: Dan Carpenter 
Reviewed-by: Kieran Bingham 
Reviewed-by: Laurent Pinchart 
Signed-off-by: Laurent Pinchart

drm: rcar-du: Write correct values in DORCR reserved fields

2023-03-25T20:38:10+00:00

The DORCR register controls the routing of clocks and data between DU
channels within a group. For groups that contain a single channel,
there's no routing option to control, and some fields of the register
are then reserved. On Gen2 those reserved fields are documented as
required to be set to 0, while on Gen3 and newer the PG1T, DK1S and PG1D
reserved fields must be set to 1.

The DU driver initializes the DORCR register in rcar_du_group_setup(),
where it ignores the PG1T, DK1S and PG1D, and then configures those
fields to the correct value in rcar_du_group_set_routing(). This hasn't
been shown to cause any issue, but prevents certifying that the driver
complies with the documentation in safety-critical use cases.

As there is no reasonable change that the documentation will be updated
to clarify that those reserved fields can be written to 0 temporarily
before starting the hardware, make sure that the registers are always
set to valid values.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Tomi Valkeinen

drm: rcar-du: Rename DORCR fields to make them 0-based

2023-03-25T20:38:10+00:00

The DORCR fields were documented in the R-Car H1 datasheet with 1-based
named, and then got renamed to 0-based in Gen2. The 0-based names are
used for Gen3 and Gen4, making H1 an outlier. Rename the field macros to
make them 0-based, in order to increase readability of the code when
comparing it with the documentation.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Tomi Valkeinen

drm: rcar-du: Disable alpha blending for DU planes used with VSP

2023-03-25T20:38:10+00:00

When the input to a DU channel comes from a VSP, the DU doesn't perform
any blending operation. Select XRGB8888 instead of ARGB8888 to ensure
that the corresponding registers don't get written with invalid values.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Tomi Valkeinen

drm: rcar-du: Don't write unimplemented ESCR and OTAR registers on Gen3

2023-03-25T20:38:10+00:00

The ESCR and OTAR registers are not present in all DU channels on Gen3
SoCs. ESCR only exists in channels that can be routed to an LVDS or
DPAD, and OTAR in channels that can be routed to a DPAD. Skip writing
those registers for other channels. This replaces the DU gen check, as
Gen4 doesn't have LVDS or DPAD outputs.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Tomi Valkeinen

drm: rcar-du: lvds: Fix LVDS PLL disable on D3/E3

2023-03-25T20:38:09+00:00

On R-Car D3 and E3, the LVDS encoder provides the dot (pixel) clock to
the DU, regardless of whether the LVDS output is used or not. When using
the DPAD (RGB) output, the DU driver thus enables and disables the LVDS
PLL manually, while when using the LVDS output, it lets the LVDS bridge
driver handle the PLL configuration internally as part of the atomic
enable and disable operations.

This causes an issue when using the LVDS output. As bridges are disabled
before CRTCs, the current implementation violates the enable/disable
sequences documented in the hardware datasheet, which requires the dot
clock to be enabled before the CRTC is started and disabled after it
gets stopped.

Fix the problem by enabling/disabling the LVDS PLL manually from the DU
regardless of which output is used, and skipping the PLL handling in the
LVDS bridge atomic enable and disable operations.

This is however not enough. Disabling the LVDS encoder while leaving the
PLL on still results in a vertical blanking wait timeout when disabling
the DU. Investigation showed that the culprit is the LVEN bit. For an
unclear reason, clearing the bit when disabling the LVDS encoder blocks
vertical blanking interrupts. We thus have to delay disabling the whole
LVDS encoder, not just disabling the PLL, until the DU is disabled.

We could split the LVDS disable sequence by clearing the LVRES bit in
the LVDS bridge atomic disable handler, and delaying the rest of the
operations, in order to disable the LVDS output at bridge atomic disable
time, before stopping the CRTC. This would make the code more complex,
without a clear benefit, so keep the implementation simple(r).

Signed-off-by: Laurent Pinchart 
Reviewed-by: Tomi Valkeinen

drm: rcar-du: lvds: Move LVDS enable code to separate code section

2023-03-25T20:38:09+00:00

To prepare for a rework of the LVDS disable code, which will need to be
called from rcar_lvds_pclk_disable(), move the LVDS enable code,
currently stored in the __rcar_lvds_atomic_enable() function, to a
separate code section separate from bridge operations. It will be then
extended with the LVDS disable code.

As part of this rework the __rcar_lvds_atomic_enable() function is
renamed to rcar_lvds_enable() to more clearly indicate its purpose.

No functional change intended.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Geert Uytterhoeven 
Reviewed-by: Tomi Valkeinen

drm: rcar-du: lvds: Call function directly instead of through pointer

2023-03-25T20:38:09+00:00

When disabling the companion bridge in rcar_lvds_atomic_disable(),
there's no need to go through the bridge's operations to call
.atomic_disable(). Call rcar_lvds_atomic_disable() on the companion
directly.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Tomi Valkeinen