Re: [PATCH 4/4] drm: rcar-du: Add support for R8A779H0
Hi Geert
On Thu, Jun 20, 2024 at 02:48:49PM GMT, Geert Uytterhoeven wrote:
> Hi Laurent, Jacopo,
>
> On Wed, Jun 19, 2024 at 9:46 PM Laurent Pinchart
> wrote:
> > On Wed, Jun 19, 2024 at 12:22:18PM +0200, Jacopo Mondi wrote:
> > > Add support for R-Car R8A779H0 V4M which has similar characteristics
> > > as the already supported R-Car V4H R8A779G0, but with a single output
> > > channel.
> > >
> > > Signed-off-by: Jacopo Mondi
>
> > > --- a/drivers/gpu/drm/renesas/rcar-du/rcar_du_group.c
> > > +++ b/drivers/gpu/drm/renesas/rcar-du/rcar_du_group.c
> > > @@ -185,11 +187,16 @@ static void rcar_du_group_setup(struct
> > > rcar_du_group *rgrp)
> > > dorcr |= DORCR_PG1T | DORCR_DK1S | DORCR_PG1D_DS1;
> > > rcar_du_group_write(rgrp, DORCR, dorcr);
> > >
> > > - /* 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);
> > > + /*
> > > + * Apply planes to CRTCs association, skip for V4M which has a
> > > single
> > > + * channel.
> >
> > " and doesn't implement the DPTSR register."
> >
> > I'm pretty sure writing it is still harmless, but...
> >
> > > + */
> > > + if (rcdu->info->gen < 4 || rgrp->num_crtcs > 1) {
>
> Looking at the R-Car Gen3 docs, this check seems to be wrong, and the
> lack of a check might have been an issue before?
Not sure I got from your comment what part is wrong.
Reading below it seems you're suggesting that writes to DPTSR should
be skipped for some Gen3 boards as well ?
>
> Seems like the register (per pair) is only present if the second CRTC
> of a CRTC pair is present, so R-Car V3M and V3H (single CRTC) do not
> have DPTSR at all, and M3-W (triple CRTC) does not have it on the
> second pair. M3-N does have both, as it lacks the first CRTC of
> second pair, but does have the second CRTC of the second pair.
>
/o\
So far however, all Gen3 SoCs you mentioned seem to work with DPTSR
being written and the BSP [1] only actually skips it for V4M.
What would you suggesting in this case ? Addressing gen3 as well ?
That's something that would require testing on all the above boards
thought.
Thanks
j
[1]
https://github.com/renesas-rcar/linux-bsp/commit/f2fc3314dab2052240653c1a31ba3d7c7190038e#diff-8bce6f4032dc891042e2561163754f49723ac119ae63df2425cc3487b432ee1cR206
> > > + mutex_lock(&rgrp->lock);
> > > + rcar_du_group_write(rgrp, DPTSR, (rgrp->dptsr_planes << 16)
> > > |
> > > + rgrp->dptsr_planes);
> > > + mutex_unlock(&rgrp->lock);
> > > + }
> > > }
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
Re: [PATCH 3/4] drm: rcar-mipi-dsi: Add support for R8A779H0
Hi Krzysztof On Wed, Jun 19, 2024 at 01:07:24PM GMT, Krzysztof Kozlowski wrote: > On 19/06/2024 12:22, Jacopo Mondi wrote: > > Add support for R-Car R8A779H0 V4M which has the same characteristics > > of the already supported R-Car V4H R8A779G0. > > > > Signed-off-by: Jacopo Mondi > > > > Please run scripts/checkpatch.pl and fix reported warnings. Then please > run `scripts/checkpatch.pl --strict` and (probably) fix more warnings. > Some warnings can be ignored, especially from --strict run, but the code > here looks like it needs a fix. Feel free to get in touch if the warning > is not clear. > The only report I got was WARNING: DT binding docs and includes should be a separate patch. See: Documentation/devicetree/bindings/submitting-patches.rst which for such trivial addition seems overkill, and I presume the patch will go through geert or drm anyway The other thing I got CHECK: Prefer using the BIT macro #30: FILE: drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi_regs.h:144: makes sense, but the rest of the file already uses (1 << x) so I kept it that way for consistency (honestly I would have changed all defines to use BIT() but that would make upporting from BSP quite more tedious). Is there any other warning I have missed ? > Bindings are separate patches. > > > Please use scripts/get_maintainers.pl to get a list of necessary people > and lists to CC. It might happen, that command when run on an older > kernel, gives you outdated entries. Therefore please be sure you base > your patches on recent Linux kernel. > > Tools like b4 or scripts/get_maintainer.pl provide you proper list of > people, so fix your workflow. Tools might also fail if you work on some > ancient tree (don't, instead use mainline), work on fork of kernel > (don't, instead use mainline) or you ignore some maintainers (really > don't). Just use b4 and everything should be fine, although remember > about `b4 prep --auto-to-cc` if you added new patches to the patchset. > > You missed at least devicetree list (maybe more), so this won't be > tested by automated tooling. Performing review on untested code might be > a waste of time, thus I will skip this patch entirely till you follow > the process allowing the patch to be tested. > > Please kindly resend and include all necessary To/Cc entries. > > > Best regards, > Krzysztof >
[PATCH 2/4] drm: ti-sn65dsi86: Check bridge connection failure
From: Phong Hoang
Add a check to the register access function when attaching a bridge
device.
Signed-off-by: Phong Hoang
Signed-off-by: Jacopo Mondi
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index 84698a0b27a8..b7df53577987 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -696,6 +696,7 @@ static struct ti_sn65dsi86 *bridge_to_ti_sn65dsi86(struct
drm_bridge *bridge)
static int ti_sn_attach_host(struct auxiliary_device *adev, struct
ti_sn65dsi86 *pdata)
{
+ int ret;
int val;
struct mipi_dsi_host *host;
struct mipi_dsi_device *dsi;
@@ -720,8 +721,11 @@ static int ti_sn_attach_host(struct auxiliary_device
*adev, struct ti_sn65dsi86
/* check if continuous dsi clock is required or not */
pm_runtime_get_sync(dev);
- regmap_read(pdata->regmap, SN_DPPLL_SRC_REG, &val);
+ ret = regmap_read(pdata->regmap, SN_DPPLL_SRC_REG, &val);
pm_runtime_put_autosuspend(dev);
+ if (ret)
+ return ret;
+
if (!(val & DPPLL_CLK_SRC_DSICLK))
dsi->mode_flags |= MIPI_DSI_CLOCK_NON_CONTINUOUS;
--
2.45.2
[PATCH 3/4] drm: rcar-mipi-dsi: Add support for R8A779H0
Add support for R-Car R8A779H0 V4M which has the same characteristics
of the already supported R-Car V4H R8A779G0.
Signed-off-by: Jacopo Mondi
---
BSP patch:
https://github.com/renesas-rcar/linux-bsp/commit/61b876a8fa2c5d0f8049ecf29f24e3dd73ba9f8b
---
.../devicetree/bindings/display/bridge/renesas,dsi-csi2-tx.yaml | 1 +
drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c | 1 +
2 files changed, 2 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/bridge/renesas,dsi-csi2-tx.yaml
b/Documentation/devicetree/bindings/display/bridge/renesas,dsi-csi2-tx.yaml
index d33026f85e19..c167795c63f6 100644
--- a/Documentation/devicetree/bindings/display/bridge/renesas,dsi-csi2-tx.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/renesas,dsi-csi2-tx.yaml
@@ -19,6 +19,7 @@ properties:
enum:
- renesas,r8a779a0-dsi-csi2-tx# for V3U
- renesas,r8a779g0-dsi-csi2-tx# for V4H
+ - renesas,r8a779h0-dsi-csi2-tx# for V4M
reg:
maxItems: 1
diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c
b/drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c
index 2dba7c5ffd2c..d5800ef14a2f 100644
--- a/drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c
+++ b/drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c
@@ -1081,6 +1081,7 @@ static const struct rcar_mipi_dsi_device_info v4h_data = {
static const struct of_device_id rcar_mipi_dsi_of_table[] = {
{ .compatible = "renesas,r8a779a0-dsi-csi2-tx", .data = &v3u_data },
{ .compatible = "renesas,r8a779g0-dsi-csi2-tx", .data = &v4h_data },
+ { .compatible = "renesas,r8a779h0-dsi-csi2-tx", .data = &v4h_data },
{ }
};
--
2.45.2
[PATCH 4/4] drm: rcar-du: Add support for R8A779H0
Add support for R-Car R8A779H0 V4M which has similar characteristics
as the already supported R-Car V4H R8A779G0, but with a single output
channel.
Signed-off-by: Jacopo Mondi
---
BSP patch
https://github.com/renesas-rcar/linux-bsp/commit/f2fc3314dab2052240653c1a31ba3d7c7190038e
---
---
.../bindings/display/renesas,du.yaml | 1 +
drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c | 18 ++
.../gpu/drm/renesas/rcar-du/rcar_du_group.c| 17 -
3 files changed, 31 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/renesas,du.yaml
b/Documentation/devicetree/bindings/display/renesas,du.yaml
index c5b9e6812bce..d369953f16f7 100644
--- a/Documentation/devicetree/bindings/display/renesas,du.yaml
+++ b/Documentation/devicetree/bindings/display/renesas,du.yaml
@@ -41,6 +41,7 @@ properties:
- renesas,du-r8a77995 # for R-Car D3 compatible DU
- renesas,du-r8a779a0 # for R-Car V3U compatible DU
- renesas,du-r8a779g0 # for R-Car V4H compatible DU
+ - renesas,du-r8a779h0 # for R-Car V4M compatible DU
reg:
maxItems: 1
diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c
b/drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c
index dee530e4c8b2..a1d174b0b00b 100644
--- a/drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c
@@ -545,6 +545,23 @@ static const struct rcar_du_device_info
rcar_du_r8a779g0_info = {
.dsi_clk_mask = BIT(1) | BIT(0),
};
+static const struct rcar_du_device_info rcar_du_r8a779h0_info = {
+ .gen = 4,
+ .features = RCAR_DU_FEATURE_CRTC_IRQ
+ | RCAR_DU_FEATURE_VSP1_SOURCE
+ | RCAR_DU_FEATURE_NO_BLENDING,
+ .channels_mask = BIT(0),
+ .routes = {
+ /* R8A779H0 has a single MIPI DSI output. */
+ [RCAR_DU_OUTPUT_DSI0] = {
+ .possible_crtcs = BIT(0),
+ .port = 0,
+ },
+ },
+ .num_rpf = 5,
+ .dsi_clk_mask = BIT(0),
+};
+
static const struct of_device_id rcar_du_of_table[] = {
{ .compatible = "renesas,du-r8a7742", .data = &rcar_du_r8a7790_info },
{ .compatible = "renesas,du-r8a7743", .data = &rzg1_du_r8a7743_info },
@@ -571,6 +588,7 @@ static const struct of_device_id rcar_du_of_table[] = {
{ .compatible = "renesas,du-r8a77995", .data = &rcar_du_r8a7799x_info },
{ .compatible = "renesas,du-r8a779a0", .data = &rcar_du_r8a779a0_info },
{ .compatible = "renesas,du-r8a779g0", .data = &rcar_du_r8a779g0_info },
+ { .compatible = "renesas,du-r8a779h0", .data = &rcar_du_r8a779h0_info },
{ }
};
diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_du_group.c
b/drivers/gpu/drm/renesas/rcar-du/rcar_du_group.c
index 2ccd2581f544..361e1d01b817 100644
--- a/drivers/gpu/drm/renesas/rcar-du/rcar_du_group.c
+++ b/drivers/gpu/drm/renesas/rcar-du/rcar_du_group.c
@@ -111,6 +111,8 @@ static void rcar_du_group_setup_didsr(struct rcar_du_group
*rgrp)
/*
* On Gen3 dot clocks are setup through per-group registers,
* only available when the group has two channels.
+*
+* R-Car V4M (R8A779H0) has only one channel, index is == 0.
*/
rcrtc = &rcdu->crtcs[rgrp->index * 2];
num_crtcs = rgrp->num_crtcs;
@@ -185,11 +187,16 @@ static void rcar_du_group_setup(struct rcar_du_group
*rgrp)
dorcr |= DORCR_PG1T | DORCR_DK1S | DORCR_PG1D_DS1;
rcar_du_group_write(rgrp, DORCR, dorcr);
- /* 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);
+ /*
+* Apply planes to CRTCs association, skip for V4M which has a single
+* channel.
+*/
+ if (rcdu->info->gen < 4 || rgrp->num_crtcs > 1) {
+ mutex_lock(&rgrp->lock);
+ rcar_du_group_write(rgrp, DPTSR, (rgrp->dptsr_planes << 16) |
+ rgrp->dptsr_planes);
+ mutex_unlock(&rgrp->lock);
+ }
}
/*
--
2.45.2
[PATCH 1/4] drm: rcar-mipi-dsi: Fix CLOCKSET1_LOCK definition
From: Takeshi Kihara Version 0.51 of the Renesas R-Car Gen4 TRM reports bit 16 of the CLOCKSET1 register of the DSI transmitter module to be a reserved field. Fix this by correcting the CLOCKSET1_LOCK definition to match the TRM and remove the CLOCKSET1_LOCK_PHY definition, as the register is simply called "lock" in the datasheet. Signed-off-by: Takeshi Kihara Signed-off-by: Jacopo Mondi --- drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi_regs.h | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi_regs.h b/drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi_regs.h index f8114d11f2d1..1bf9c4717d5a 100644 --- a/drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi_regs.h +++ b/drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi_regs.h @@ -141,8 +141,7 @@ #define PHYSETUP_RSTZ (1 << 0) #define CLOCKSET1 0x101c -#define CLOCKSET1_LOCK_PHY (1 << 17) -#define CLOCKSET1_LOCK (1 << 16) +#define CLOCKSET1_LOCK (1 << 17) #define CLOCKSET1_CLKSEL (1 << 8) #define CLOCKSET1_CLKINSEL_EXTAL (0 << 2) #define CLOCKSET1_CLKINSEL_DIG (1 << 2) -- 2.45.2
[PATCH 0/4] drm: rcar-du: Add support for R8A779H0
This series upports from Renesas BSP at revision rcar-5.2.0.rc18 the initial display support for the V4M SoC (R8A779H0). The series includes two small bugfixes and then adds support for the V4M SoC to the R-Car DU module and R-Car DSI encoder. Compile-tested only as I don't have a Gray Hawk board available yet. Once the board will be available, DTS integration will follow. Jacopo Mondi (2): drm: rcar-mipi-dsi: Add support for R8A779H0 drm: rcar-du: Add support for R8A779H0 Phong Hoang (1): drm: ti-sn65dsi86: Check bridge connection failure Takeshi Kihara (1): drm: rcar-mipi-dsi: Fix CLOCKSET1_LOCK definition .../display/bridge/renesas,dsi-csi2-tx.yaml| 1 + .../bindings/display/renesas,du.yaml | 1 + drivers/gpu/drm/bridge/ti-sn65dsi86.c | 6 +- drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c | 18 ++ .../gpu/drm/renesas/rcar-du/rcar_du_group.c| 17 - .../gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c| 1 + .../drm/renesas/rcar-du/rcar_mipi_dsi_regs.h | 3 +-- 7 files changed, 39 insertions(+), 8 deletions(-) -- 2.45.2
Re: [PATCH] drm/fourcc: Add RGB161616 and BGR161616 formats
Hello
which tree should this patch be collected from now that it has
been reviewed ?
On Mon, Feb 26, 2024 at 02:25:43PM GMT, Jacopo Mondi wrote:
> Add FourCC definitions for the 48-bit RGB/BGR formats to the
> DRM/KMS uapi.
>
> The format will be used by the Raspberry Pi PiSP Back End,
> supported by a V4L2 driver in kernel space and by libcamera in
> userspace, which uses the DRM FourCC identifiers.
>
> Signed-off-by: Jacopo Mondi
> ---
> drivers/gpu/drm/drm_fourcc.c | 8
> include/uapi/drm/drm_fourcc.h | 4
> 2 files changed, 12 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index 193cf8ed7912..908f20b96fd5 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -210,6 +210,14 @@ const struct drm_format_info *__drm_format_info(u32
> format)
> { .format = DRM_FORMAT_ABGR2101010, .depth = 30,
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true
> },
> { .format = DRM_FORMAT_RGBA1010102, .depth = 30,
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true
> },
> { .format = DRM_FORMAT_BGRA1010102, .depth = 30,
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true
> },
> + { .format = DRM_FORMAT_RGB161616, .depth = 0,
> + .num_planes = 1, .char_per_block = { 6, 0, 0 },
> + .block_w = { 1, 0, 0 }, .block_h = { 1, 0, 0 },
> + .hsub = 1, .vsub = 1, .has_alpha = false },
> + { .format = DRM_FORMAT_BGR161616, .depth = 0,
> + .num_planes = 1, .char_per_block = { 6, 0, 0 },
> + .block_w = { 1, 0, 0 }, .block_h = { 1, 0, 0 },
> + .hsub = 1, .vsub = 1, .has_alpha = false },
> { .format = DRM_FORMAT_ARGB,.depth = 32,
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true
> },
> { .format = DRM_FORMAT_ABGR,.depth = 32,
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true
> },
> { .format = DRM_FORMAT_RGBA,.depth = 32,
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true
> },
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 84d502e42961..00db00083175 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -210,6 +210,10 @@ extern "C" {
> #define DRM_FORMAT_RGBA1010102 fourcc_code('R', 'A', '3', '0') /*
> [31:0] R:G:B:A 10:10:10:2 little endian */
> #define DRM_FORMAT_BGRA1010102 fourcc_code('B', 'A', '3', '0') /*
> [31:0] B:G:R:A 10:10:10:2 little endian */
>
> +/* 48 bpp RGB */
> +#define DRM_FORMAT_RGB161616 fourcc_code('R', 'G', '4', '8') /* [47:0] R:G:B
> 16:16:16 little endian */
> +#define DRM_FORMAT_BGR161616 fourcc_code('B', 'G', '4', '8') /* [47:0] B:G:R
> 16:16:16 little endian */
> +
> /* 64 bpp RGB */
> #define DRM_FORMAT_XRGB16161616 fourcc_code('X', 'R', '4', '8') /*
> [63:0] x:R:G:B 16:16:16:16 little endian */
> #define DRM_FORMAT_XBGR16161616 fourcc_code('X', 'B', '4', '8') /*
> [63:0] x:B:G:R 16:16:16:16 little endian */
> --
> 2.43.0
>
Re: [PATCH 0/2] drm/fourcc.h: Add libcamera to Open Source Waiver
Hello gentle nudge for *) libcamera: are we ok being listed here ? *) DRM/KMS: is it ok splitting the list of projects in the way I've done ? Thanks j On Wed, Feb 28, 2024 at 11:22:42AM +0100, Jacopo Mondi wrote: > As suggested by Sima, add libcamera to the list of projects to which the > Open Source Waiver notice applies. > > To maintain the paragraph readable, make a list out of the projects to which > such notice applies. > > Jacopo Mondi (2): > drm/fourcc.h: List of Open Source Waiver projects > drm/fourcc.h: Add libcamera to Open Source Waiver > > include/uapi/drm/drm_fourcc.h | 12 +--- > 1 file changed, 9 insertions(+), 3 deletions(-) > > -- > 2.43.2 >
Re: [RFC] drm/fourcc: Add RPI modifiers
Hi Laurent On Tue, Feb 27, 2024 at 03:08:27PM +0200, Laurent Pinchart wrote: > On Mon, Feb 26, 2024 at 04:46:24PM +0100, Daniel Vetter wrote: > > On Mon, 26 Feb 2024 at 16:39, Jacopo Mondi wrote: > > > > > > Add modifiers for the Raspberry Pi PiSP compressed formats. > > > > > > The compressed formats are documented at: > > > Documentation/userspace-api/media/v4l/pixfmt-pisp-comp-rggb.rst > > > > > > and in the PiSP datasheet: > > > https://datasheets.raspberrypi.com/camera/raspberry-pi-image-signal-processor-specification.pdf > > > > > > Signed-off-by: Jacopo Mondi > > > --- > > > > > > Background: > > > --- > > > > > > The Raspberry Pi PiSP camera subsystem is on its way to upstream through > > > the > > > Video4Linux2 subsystem: > > > https://patchwork.linuxtv.org/project/linux-media/list/?series=12310 > > > > > > The PiSP camera system is composed by a "Front End" and a "Back End". > > > The FrontEnd part is a MIPI CSI-2 receiver that store frames to memory and > > > produce statistics, and the BackEnd is a memory-to-memory ISP that > > > converts > > > images in a format usable by application. > > > > > > The "FrontEnd" is capable of encoding RAW Bayer images as received by the > > > image sensor in a 'compressed' format defined by Raspberry Pi and fully > > > documented in the PiSP manual: > > > https://datasheets.raspberrypi.com/camera/raspberry-pi-image-signal-processor-specification.pdf > > > > > > The compression scheme is documented in the in-review patch series for > > > the BE > > > support at: > > > https://patchwork.linuxtv.org/project/linux-media/patch/20240223163012.300763-7-jacopo.mo...@ideasonboard.com/ > > > > > > The "BackEnd" is capable of consuming images in the compressed format and > > > optionally user application might want to inspect those images for > > > debugging > > > purposes. > > > > > > Why a DRM modifier > > > -- > > > > > > The PiSP support is entirely implemented in libcamera, with the support > > > of an > > > hw-specific library called 'libpisp'. > > > > > > libcamera uses the fourcc codes defined by DRM to define its formats: > > > https://git.libcamera.org/libcamera/libcamera.git/tree/src/libcamera/formats.yaml > > > > > > And to define a new libcamera format for the Raspberry Pi compressed ones > > > we > > > need to associate the above proposed modifiers with a RAW Bayer format > > > identifier. > > > > > > In example: > > > > > > - RGGB16_PISP_COMP1: > > > fourcc: DRM_FORMAT_SRGGB16 > > An "interesting" issue here is that these formats currently live in > libcamera only, we haven't merged them in DRM "yet". This may be a > prerequisite ? > Ah right! I didn't notice! I think there are two issues at play here, one to be clarified by the DRM maintainers, the other more technically involved with the definition of the Bayer formats themselves. - Does DRM want RAW Bayer formats to be listed here, as these are not typically 'graphic' formats. What's the DRM maintainers opinion here ? - The RAW Bayer pattern ordering: we have realized that the idea of defining RAW Bayer formats by encoding the components ordering in V4L2 was, in retrospective, a bad idea. The reason is that any change in the Bayer order along the capture pipeline (usually due to flip) requires reconfiguration of the formats along the whole pipeline, requiring a start/stop of the capture operations. For this reason, we have multiple times discussed the idea of only conveying the bit depth in the format definition and to communicate the components ordering with other out-of-band mechanism, that will likely be used to negotiate between the image sensor and the CSI-2 receiver. With DRM the ideal would be something like DRM_FORMAT_RAW8 | FORMAT_MODIFIER_SBGGR DRM_FORMAT_RAW8 | FORMAT_MODIFIER_SGBRG ... DRM_FORMAT_RAW10 | FORMAT_MODIFIER_SBGGR DRM_FORMAT_RAW10 | FORMAT_MODIFIER_SGBRG ... This however prevents to use additional modifiers to convey, in example, packaging (ie MIPI CSI-2) or compressions (like done here for PISP_COMP1) as, as far as I understand it, multiple modifiers cannot be applied to a format. However, as I understand the argument of not repeating the V4L2 mistakes here, the DRM formats are aimed
[PATCH 2/2] drm/fourcc.h: Add libcamera to Open Source Waiver
The libcamera (www.libcamera.org) project uses the drm/fourcc.h header
to define its own image formats. Albeit libcamera aims for fully open
source driver and userspace software stacks, it is licensed with the
'GNU L-GPL' license which allows closed source application to link
against the library.
Add libcamera to the list projects to which the 'Open Source User
Waiver' notice applies.
Signed-off-by: Jacopo Mondi
---
include/uapi/drm/drm_fourcc.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 4e6df826946a..beef743ac818 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -97,6 +97,7 @@ extern "C" {
*
* - GL
* - Vulkan extensions
+ * - libcamera
*
* and other standards, and hence used both by open source and closed source
* driver stacks, the usual requirement for an upstream in-kernel or open
source
--
2.43.2
[PATCH 1/2] drm/fourcc.h: List of Open Source Waiver projects
The drm/fourcc.h header includes an 'Open Source User Waiver' section
that lists projects using the header in potentially closed source
software stacks.
To prepare to expand the number of projects to which such waiver notice
applies, make it a list to maintain the paragraph readable.
Signed-off-by: Jacopo Mondi
---
include/uapi/drm/drm_fourcc.h | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 84d502e42961..4e6df826946a 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -93,9 +93,14 @@ extern "C" {
* ---
*
* Because this is the authoritative source for pixel formats and modifiers
- * referenced by GL, Vulkan extensions and other standards and hence used both
- * by open source and closed source driver stacks, the usual requirement for an
- * upstream in-kernel or open source userspace user does not apply.
+ * referenced by the following projects:
+ *
+ * - GL
+ * - Vulkan extensions
+ *
+ * and other standards, and hence used both by open source and closed source
+ * driver stacks, the usual requirement for an upstream in-kernel or open
source
+ * userspace user does not apply.
*
* To ensure, as much as feasible, compatibility across stacks and avoid
* confusion with incompatible enumerations stakeholders for all relevant
driver
--
2.43.2
[PATCH 0/2] drm/fourcc.h: Add libcamera to Open Source Waiver
As suggested by Sima, add libcamera to the list of projects to which the Open Source Waiver notice applies. To maintain the paragraph readable, make a list out of the projects to which such notice applies. Jacopo Mondi (2): drm/fourcc.h: List of Open Source Waiver projects drm/fourcc.h: Add libcamera to Open Source Waiver include/uapi/drm/drm_fourcc.h | 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-) -- 2.43.2
Re: [RFC] drm/fourcc: Add RPI modifiers
Hi Sima On Mon, Feb 26, 2024 at 04:46:24PM +0100, Daniel Vetter wrote: > On Mon, 26 Feb 2024 at 16:39, Jacopo Mondi > wrote: > > > > Add modifiers for the Raspberry Pi PiSP compressed formats. > > > > The compressed formats are documented at: > > Documentation/userspace-api/media/v4l/pixfmt-pisp-comp-rggb.rst > > > > and in the PiSP datasheet: > > https://datasheets.raspberrypi.com/camera/raspberry-pi-image-signal-processor-specification.pdf > > > > Signed-off-by: Jacopo Mondi > > --- > > > > Background: > > --- > > > > The Raspberry Pi PiSP camera subsystem is on its way to upstream through the > > Video4Linux2 subsystem: > > https://patchwork.linuxtv.org/project/linux-media/list/?series=12310 > > > > The PiSP camera system is composed by a "Front End" and a "Back End". > > The FrontEnd part is a MIPI CSI-2 receiver that store frames to memory and > > produce statistics, and the BackEnd is a memory-to-memory ISP that converts > > images in a format usable by application. > > > > The "FrontEnd" is capable of encoding RAW Bayer images as received by the > > image sensor in a 'compressed' format defined by Raspberry Pi and fully > > documented in the PiSP manual: > > https://datasheets.raspberrypi.com/camera/raspberry-pi-image-signal-processor-specification.pdf > > > > The compression scheme is documented in the in-review patch series for the > > BE > > support at: > > https://patchwork.linuxtv.org/project/linux-media/patch/20240223163012.300763-7-jacopo.mo...@ideasonboard.com/ > > > > The "BackEnd" is capable of consuming images in the compressed format and > > optionally user application might want to inspect those images for debugging > > purposes. > > > > Why a DRM modifier > > -- > > > > The PiSP support is entirely implemented in libcamera, with the support of > > an > > hw-specific library called 'libpisp'. > > > > libcamera uses the fourcc codes defined by DRM to define its formats: > > https://git.libcamera.org/libcamera/libcamera.git/tree/src/libcamera/formats.yaml > > > > And to define a new libcamera format for the Raspberry Pi compressed ones we > > need to associate the above proposed modifiers with a RAW Bayer format > > identifier. > > > > In example: > > > > - RGGB16_PISP_COMP1: > > fourcc: DRM_FORMAT_SRGGB16 > > mod: PISP_FORMAT_MOD_COMPRESS_MODE1 > > - GRBG16_PISP_COMP1: > > fourcc: DRM_FORMAT_SGRBG16 > > mod: PISP_FORMAT_MOD_COMPRESS_MODE1 > > - GBRG16_PISP_COMP1: > > fourcc: DRM_FORMAT_SGBRG16 > > mod: PISP_FORMAT_MOD_COMPRESS_MODE1 > > - BGGR16_PISP_COMP1: > > fourcc: DRM_FORMAT_SBGGR16 > > mod: PISP_FORMAT_MOD_COMPRESS_MODE1 > > - MONO_PISP_COMP1: > > fourcc: DRM_FORMAT_R16 > > mod: PISP_FORMAT_MOD_COMPRESS_MODE1 > > > > See > > https://patchwork.libcamera.org/patch/19503/ > > > > Would if be acceptable for DRM to include the above proposed modifiers for > > the > > purpose of defining the above presented libcamera formats ? There will be no > > graphic format associated with these modifiers as their purpose it not > > displaying images but rather exchange them between the components of the > > camera subsystem (and possibly be inspected by specialized test > > applications). > > Yeah I think libcamera using drm-fourcc formats and modifiers is > absolutely ok, and has my ack in principle. And for these users we're > ok with merging modifiers that the kernel doesn't use. > Great! > I think it would be really good to formalize this by adding libcamera > to the officially listed users in the "Open Source User Waiver" > section in the drm_fourcc.h docs: > > https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#open-source-user-waiver > > You might want to convert that into a list, it could get a bit > confusing. Then we can get that patch properly acked (by kernel and > libcamera folks) to record the community consensus. > I see your point, but I wonder if libcamera actually need to be part of this list; we want in-kernel upstream driver and open-source userspace components. We allow binary 3A modules to be loaded by the library, but I'm not sure they will ever need to modify the DRM 4cc list. Anyway, with other libcamera people ack, I can certainly do so! > For the rpi modifiers themselves: They need to be properly documented, > least to exclude a screw-up like with the r
[RFC] drm/fourcc: Add RPI modifiers
Add modifiers for the Raspberry Pi PiSP compressed formats.
The compressed formats are documented at:
Documentation/userspace-api/media/v4l/pixfmt-pisp-comp-rggb.rst
and in the PiSP datasheet:
https://datasheets.raspberrypi.com/camera/raspberry-pi-image-signal-processor-specification.pdf
Signed-off-by: Jacopo Mondi
---
Background:
---
The Raspberry Pi PiSP camera subsystem is on its way to upstream through the
Video4Linux2 subsystem:
https://patchwork.linuxtv.org/project/linux-media/list/?series=12310
The PiSP camera system is composed by a "Front End" and a "Back End".
The FrontEnd part is a MIPI CSI-2 receiver that store frames to memory and
produce statistics, and the BackEnd is a memory-to-memory ISP that converts
images in a format usable by application.
The "FrontEnd" is capable of encoding RAW Bayer images as received by the
image sensor in a 'compressed' format defined by Raspberry Pi and fully
documented in the PiSP manual:
https://datasheets.raspberrypi.com/camera/raspberry-pi-image-signal-processor-specification.pdf
The compression scheme is documented in the in-review patch series for the BE
support at:
https://patchwork.linuxtv.org/project/linux-media/patch/20240223163012.300763-7-jacopo.mo...@ideasonboard.com/
The "BackEnd" is capable of consuming images in the compressed format and
optionally user application might want to inspect those images for debugging
purposes.
Why a DRM modifier
--
The PiSP support is entirely implemented in libcamera, with the support of an
hw-specific library called 'libpisp'.
libcamera uses the fourcc codes defined by DRM to define its formats:
https://git.libcamera.org/libcamera/libcamera.git/tree/src/libcamera/formats.yaml
And to define a new libcamera format for the Raspberry Pi compressed ones we
need to associate the above proposed modifiers with a RAW Bayer format
identifier.
In example:
- RGGB16_PISP_COMP1:
fourcc: DRM_FORMAT_SRGGB16
mod: PISP_FORMAT_MOD_COMPRESS_MODE1
- GRBG16_PISP_COMP1:
fourcc: DRM_FORMAT_SGRBG16
mod: PISP_FORMAT_MOD_COMPRESS_MODE1
- GBRG16_PISP_COMP1:
fourcc: DRM_FORMAT_SGBRG16
mod: PISP_FORMAT_MOD_COMPRESS_MODE1
- BGGR16_PISP_COMP1:
fourcc: DRM_FORMAT_SBGGR16
mod: PISP_FORMAT_MOD_COMPRESS_MODE1
- MONO_PISP_COMP1:
fourcc: DRM_FORMAT_R16
mod: PISP_FORMAT_MOD_COMPRESS_MODE1
See
https://patchwork.libcamera.org/patch/19503/
Would if be acceptable for DRM to include the above proposed modifiers for the
purpose of defining the above presented libcamera formats ? There will be no
graphic format associated with these modifiers as their purpose it not
displaying images but rather exchange them between the components of the
camera subsystem (and possibly be inspected by specialized test applications).
---
include/uapi/drm/drm_fourcc.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 00db00083175..09b182a959ad 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -425,6 +425,7 @@ extern "C" {
#define DRM_FORMAT_MOD_VENDOR_ARM 0x08
#define DRM_FORMAT_MOD_VENDOR_ALLWINNER 0x09
#define DRM_FORMAT_MOD_VENDOR_AMLOGIC 0x0a
+#define DRM_FORMAT_MOD_VENDOR_RPI 0x0b
/* add more to the end as needed */
@@ -1568,6 +1569,10 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64 modifier)
#define AMD_FMT_MOD_CLEAR(field) \
(~((__u64)AMD_FMT_MOD_##field##_MASK << AMD_FMT_MOD_##field##_SHIFT))
+/* RPI (Raspberry Pi) modifiers */
+#define PISP_FORMAT_MOD_COMPRESS_MODE1 fourcc_mod_code(RPI, 1)
+#define PISP_FORMAT_MOD_COMPRESS_MODE2 fourcc_mod_code(RPI, 2)
+
#if defined(__cplusplus)
}
#endif
--
2.43.0
[PATCH] drm/fourcc: Add RGB161616 and BGR161616 formats
Add FourCC definitions for the 48-bit RGB/BGR formats to the
DRM/KMS uapi.
The format will be used by the Raspberry Pi PiSP Back End,
supported by a V4L2 driver in kernel space and by libcamera in
userspace, which uses the DRM FourCC identifiers.
Signed-off-by: Jacopo Mondi
---
drivers/gpu/drm/drm_fourcc.c | 8
include/uapi/drm/drm_fourcc.h | 4
2 files changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 193cf8ed7912..908f20b96fd5 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -210,6 +210,14 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_ABGR2101010, .depth = 30,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
{ .format = DRM_FORMAT_RGBA1010102, .depth = 30,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
{ .format = DRM_FORMAT_BGRA1010102, .depth = 30,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
+ { .format = DRM_FORMAT_RGB161616, .depth = 0,
+ .num_planes = 1, .char_per_block = { 6, 0, 0 },
+ .block_w = { 1, 0, 0 }, .block_h = { 1, 0, 0 },
+ .hsub = 1, .vsub = 1, .has_alpha = false },
+ { .format = DRM_FORMAT_BGR161616, .depth = 0,
+ .num_planes = 1, .char_per_block = { 6, 0, 0 },
+ .block_w = { 1, 0, 0 }, .block_h = { 1, 0, 0 },
+ .hsub = 1, .vsub = 1, .has_alpha = false },
{ .format = DRM_FORMAT_ARGB,.depth = 32,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
{ .format = DRM_FORMAT_ABGR,.depth = 32,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
{ .format = DRM_FORMAT_RGBA,.depth = 32,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 84d502e42961..00db00083175 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -210,6 +210,10 @@ extern "C" {
#define DRM_FORMAT_RGBA1010102 fourcc_code('R', 'A', '3', '0') /* [31:0]
R:G:B:A 10:10:10:2 little endian */
#define DRM_FORMAT_BGRA1010102 fourcc_code('B', 'A', '3', '0') /* [31:0]
B:G:R:A 10:10:10:2 little endian */
+/* 48 bpp RGB */
+#define DRM_FORMAT_RGB161616 fourcc_code('R', 'G', '4', '8') /* [47:0] R:G:B
16:16:16 little endian */
+#define DRM_FORMAT_BGR161616 fourcc_code('B', 'G', '4', '8') /* [47:0] B:G:R
16:16:16 little endian */
+
/* 64 bpp RGB */
#define DRM_FORMAT_XRGB16161616fourcc_code('X', 'R', '4', '8') /*
[63:0] x:R:G:B 16:16:16:16 little endian */
#define DRM_FORMAT_XBGR16161616fourcc_code('X', 'B', '4', '8') /*
[63:0] x:B:G:R 16:16:16:16 little endian */
--
2.43.0
Re: [PATCH v12 3/4] drm: renesas: Add RZ/G2L DU Support
Hi Biju On Wed, Nov 15, 2023 at 12:36:55PM +, Biju Das wrote: > Hi Jacopo Mondi, > > Thanks for the feedback. > > > Subject: Re: [PATCH v12 3/4] drm: renesas: Add RZ/G2L DU Support > > > > Hi Biju > > > > the series does not apply on v6.3. What is the base for the series ? > > > > On Thu, Nov 02, 2023 at 03:07:43PM +, Biju Das wrote: > > > The LCD controller is composed of Frame Compression Processor (FCPVD), > > > Video Signal Processor (VSPD), and Display Unit (DU). > > > > > > It has DPI/DSI interfaces and supports a maximum resolution of 1080p > > > along with 2 RPFs to support the blending of two picture layers and > > > raster operations (ROPs). > > > > > > The DU module is connected to VSPD. Add RZ/G2L DU support for RZ/G2L > > > alike SoCs. > > > > > > Signed-off-by: Biju Das > > > --- > > > Ref: > > > > > > v11->v12: > > > * Replaced rzg2l_du_write() with writel(). > > > v10->v11: > > > * Replaced CONFIG_DRM_RCAR_VSP->CONFIG_VIDEO_RENESAS_VSP1 for building > > > rzg2l_du_vsp driver. > > > * Dropped "rzg2l_du_regs.h" instead the relevant definitions defined in > > > .c file. > > > * Dropped setting ditr5 based on latest HW manual 1.3.0/1.4.0 > > > * Updated the comment for auto clear. > > > * Replaced writel()->rzg2l_du_write() in rzg2l_du_start_stop(). > > > * Dropped CRC related functions as it does not have DISCOM. > > > * Replaced the variable possible_crtcs->possible_outputs in > > > struct rzg2l_du_output_routing. > > > * Updated DMA_BIT_MASK from 40->32. > > > * Dropped unneeded struct drm_bridge from rzg2l_du_drv.h. > > > * Dropped colour keying support as it doesn't have planes. > > > * Added only RGB formats in rzg2l_du_format_infos. > > > * Dropped chroma planes from rzg2l_du_fb_create(). > > > * Updated the comment for max_pitch in rzg2l_du_fb_create(). > > > * Dropped possible_crtcs check in rzg2l_du_encoders_init(). > > > * Dropped additional empty line from struct rzg2l_du_device. > > > v9->v10: > > > * Dropped ARM64 dependency from Kconfig. > > > * Sorted the configs alphabetically in Kconfig. > > > * Dropped DRM_RCAR_VSP config option and make DRM_RZG2L_DU depend on > > >VIDEO_RENESAS_VSP1. > > > * On rzg2l_du_crtc_set_display_timing() replaced the setting of parent > > >clk rate with dclk rate. > > > * Added rzg2l_du_write() wrapper function. > > > * Updated the comment atomic_begin->atomic_flush. > > > * Dropped .atomic_check and .atomic_begin callback > > > * Renamed __rzg2l_du_crtc_plane_atomic_check- > > >__rzg2l_du_vsp_plane_atomic > > >_check and moved it to rzg2l_du_vsp.c > > > * Added struct clk in rzg2l_du_crtc.h > > > * Dropped the variables mmio_offset,index,vblank_lock,vblank_wait, > > >vblank_count from struct rzg2l_du_crtc. > > > * Replaced the macro to_rzg2l_crtc with static inline functions. > > > * Dropped the unneeded header files clk.h, io.h, mm.h, pm.h, slab.h, > > >wait.h and drm_managed.h from rzg2l_du_drv.c. > > > * Replaced DRM_INFO->drm_info > > > * Dropped the callbacks prime_handle_to_fd, prime_fd_to_handle and > > >gem_prime_mmap. > > > * Replaced the callback remove->remove_new. > > > * Dropped header file wait.h and added forward declarations struct clk > > and > > >rzg2l_du_device from rzg2l_du_drv.h. > > > * Dropped the dsi and dpad0_source variables from struct > > rzg2l_du_device. > > > * Replaced the macro to_rzg2l_encoder with static inline functions. > > > * Dropped header files dma-buf.h and wait.h from rzg2l_du_kms.c. > > > * Dropped struct sg_table and added the scatterlist.h header file in > > >rzg2l_du_vsp.h > > > * Added container_of.h header file, forward declarations struct device > > and > > >struct rzg2l_du_device in rzg2l_du_vsp.h. > > > v8->v9: > > > * Dropped reset_control_assert() from error patch for > > rzg2l_du_crtc_get() as > > >suggested by Philipp Zabel. > > > v7->v8: > > > * Dropped RCar du lib and created RZ/G2L DU DRM driver by creating > > rz_du folder. > > > * Updated KConfig and Makefile. > > > v6->v7: > > > * Split DU lib and RZ/G2L du driver as separate patch series as > > >DU support added to more platforms b
Re: [PATCH v12 3/4] drm: renesas: Add RZ/G2L DU Support
Hi Biju
the series does not apply on v6.3. What is the base for the series ?
On Thu, Nov 02, 2023 at 03:07:43PM +, Biju Das wrote:
> The LCD controller is composed of Frame Compression Processor (FCPVD),
> Video Signal Processor (VSPD), and Display Unit (DU).
>
> It has DPI/DSI interfaces and supports a maximum resolution of 1080p
> along with 2 RPFs to support the blending of two picture layers and
> raster operations (ROPs).
>
> The DU module is connected to VSPD. Add RZ/G2L DU support for RZ/G2L
> alike SoCs.
>
> Signed-off-by: Biju Das
> ---
> Ref:
>
> https://lore.kernel.org/linux-renesas-soc/os0pr01mb5922717e4ccfe07f3c25fbc986...@os0pr01mb5922.jpnprd01.prod.outlook.com/#t
> v11->v12:
> * Replaced rzg2l_du_write() with writel().
> v10->v11:
> * Replaced CONFIG_DRM_RCAR_VSP->CONFIG_VIDEO_RENESAS_VSP1 for building
> rzg2l_du_vsp driver.
> * Dropped "rzg2l_du_regs.h" instead the relevant definitions defined in
> .c file.
> * Dropped setting ditr5 based on latest HW manual 1.3.0/1.4.0
> * Updated the comment for auto clear.
> * Replaced writel()->rzg2l_du_write() in rzg2l_du_start_stop().
> * Dropped CRC related functions as it does not have DISCOM.
> * Replaced the variable possible_crtcs->possible_outputs in
> struct rzg2l_du_output_routing.
> * Updated DMA_BIT_MASK from 40->32.
> * Dropped unneeded struct drm_bridge from rzg2l_du_drv.h.
> * Dropped colour keying support as it doesn't have planes.
> * Added only RGB formats in rzg2l_du_format_infos.
> * Dropped chroma planes from rzg2l_du_fb_create().
> * Updated the comment for max_pitch in rzg2l_du_fb_create().
> * Dropped possible_crtcs check in rzg2l_du_encoders_init().
> * Dropped additional empty line from struct rzg2l_du_device.
> v9->v10:
> * Dropped ARM64 dependency from Kconfig.
> * Sorted the configs alphabetically in Kconfig.
> * Dropped DRM_RCAR_VSP config option and make DRM_RZG2L_DU depend on
>VIDEO_RENESAS_VSP1.
> * On rzg2l_du_crtc_set_display_timing() replaced the setting of parent
>clk rate with dclk rate.
> * Added rzg2l_du_write() wrapper function.
> * Updated the comment atomic_begin->atomic_flush.
> * Dropped .atomic_check and .atomic_begin callback
> * Renamed __rzg2l_du_crtc_plane_atomic_check->__rzg2l_du_vsp_plane_atomic
>_check and moved it to rzg2l_du_vsp.c
> * Added struct clk in rzg2l_du_crtc.h
> * Dropped the variables mmio_offset,index,vblank_lock,vblank_wait,
>vblank_count from struct rzg2l_du_crtc.
> * Replaced the macro to_rzg2l_crtc with static inline functions.
> * Dropped the unneeded header files clk.h, io.h, mm.h, pm.h, slab.h,
>wait.h and drm_managed.h from rzg2l_du_drv.c.
> * Replaced DRM_INFO->drm_info
> * Dropped the callbacks prime_handle_to_fd, prime_fd_to_handle and
>gem_prime_mmap.
> * Replaced the callback remove->remove_new.
> * Dropped header file wait.h and added forward declarations struct clk and
>rzg2l_du_device from rzg2l_du_drv.h.
> * Dropped the dsi and dpad0_source variables from struct rzg2l_du_device.
> * Replaced the macro to_rzg2l_encoder with static inline functions.
> * Dropped header files dma-buf.h and wait.h from rzg2l_du_kms.c.
> * Dropped struct sg_table and added the scatterlist.h header file in
>rzg2l_du_vsp.h
> * Added container_of.h header file, forward declarations struct device and
>struct rzg2l_du_device in rzg2l_du_vsp.h.
> v8->v9:
> * Dropped reset_control_assert() from error patch for rzg2l_du_crtc_get() as
>suggested by Philipp Zabel.
> v7->v8:
> * Dropped RCar du lib and created RZ/G2L DU DRM driver by creating rz_du
> folder.
> * Updated KConfig and Makefile.
> v6->v7:
> * Split DU lib and RZ/G2L du driver as separate patch series as
>DU support added to more platforms based on RZ/G2L alike SoCs.
> * Rebased to latest drm-tip.
> * Added patch #2 for binding support for RZ/V2L DU
> * Added patch #4 for driver support for RZ/V2L DU
> * Added patch #5 for SoC DTSI support for RZ/G2L DU
> * Added patch #6 for SoC DTSI support for RZ/V2L DU
> * Added patch #7 for Enabling DU on SMARC EVK based on RZ/{G2L,V2L} SoCs.
> * Added patch #8 for Enabling DU on SMARC EVK based on RZ/G2LC SoC.
> ---
> drivers/gpu/drm/renesas/Kconfig | 1 +
> drivers/gpu/drm/renesas/Makefile | 1 +
> drivers/gpu/drm/renesas/rz-du/Kconfig | 12 +
> drivers/gpu/drm/renesas/rz-du/Makefile| 8 +
> drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c | 435
> drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.h | 89
> drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c | 176 +++
> drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h | 78 +++
> .../gpu/drm/renesas/rz-du/rzg2l_du_encoder.c | 72 +++
> .../gpu/drm/renesas/rz-du/rzg2l_du_encoder.h | 32 ++
> drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c | 441
> drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.h | 43 ++
> drivers/gpu/drm/renesas/rz-du/rzg2l_du_vsp.c | 469 ++
> dri
Re: [PATCH v10 3/4] drm: renesas: Add RZ/G2L DU Support
Hi Biju
On Mon, Sep 18, 2023 at 08:09:58AM +, Biju Das wrote:
> Hi Jacopo Mondi,
>
> Looks like you are happy with my response for V10. I will send V11 soon.
Sorry for the late reply..
See below, I only see two "controversial" points
>
> Cheers,
> Biju
>
> > -Original Message-
> > From: Biju Das
> > Sent: Friday, September 8, 2023 2:24 PM
> > Subject: RE: [PATCH v10 3/4] drm: renesas: Add RZ/G2L DU Support
> >
[snip]
> > >
> > > > +
> > > > + ditr0 = (DU_DITR0_DEMD_HIGH
> > >
> > > I see most registers definition in rzg2l_du_regs.h being only used by
> > > the crtc driver (some of them are not even used). Why a separate
> > > header file ?
> >
> > For consistency I added header file similar to R-Car. Please let me know
> > this to be added in .c ?
> >
I would say up to you, as R-Car does the same. In general, if a symbol
doesn't need to be exported to any other file, it could very well live
in the .c file.
> > >
> > > > + | ((mode->flags & DRM_MODE_FLAG_PVSYNC) ? DU_DITR0_VSPOL
> > > > : 0)
> > > > + | ((mode->flags & DRM_MODE_FLAG_PHSYNC) ? DU_DITR0_HSPOL :
[snip]
> > > -
> > > > + * Format helpers
> > > > + */
> > > > +
> > > > +static const struct rzg2l_du_format_info rzg2l_du_format_infos[] = {
> > > > + {
> > > > + .fourcc = DRM_FORMAT_RGB565,
> > > > + .v4l2 = V4L2_PIX_FMT_RGB565,
> > > > + .bpp = 16,
> > > > + .planes = 1,
> > > > + .hsub = 1,
> > > > + }, {
> > > > + .fourcc = DRM_FORMAT_ARGB1555,
> > > > + .v4l2 = V4L2_PIX_FMT_ARGB555,
> > > > + .bpp = 16,
> > > > + .planes = 1,
> > > > + .hsub = 1,
> > > > + }, {
> > > > + .fourcc = DRM_FORMAT_XRGB1555,
> > > > + .v4l2 = V4L2_PIX_FMT_XRGB555,
> > > > + .bpp = 16,
> > > > + .planes = 1,
> > > > + }, {
> > > > + .fourcc = DRM_FORMAT_XRGB,
> > > > + .v4l2 = V4L2_PIX_FMT_XBGR32,
> > > > + .bpp = 32,
> > > > + .planes = 1,
> > > > + .hsub = 1,
> > > > + }, {
> > > > + .fourcc = DRM_FORMAT_ARGB,
> > > > + .v4l2 = V4L2_PIX_FMT_ABGR32,
> > > > + .bpp = 32,
> > > > + .planes = 1,
> > > > + .hsub = 1,
> > > > + }, {
> > > > + .fourcc = DRM_FORMAT_UYVY,
> > > > + .v4l2 = V4L2_PIX_FMT_UYVY,
> > > > + .bpp = 16,
> > > > + .planes = 1,
> > > > + .hsub = 2,
> > > > + }, {
> > > > + .fourcc = DRM_FORMAT_YUYV,
> > > > + .v4l2 = V4L2_PIX_FMT_YUYV,
> > > > + .bpp = 16,
> > > > + .planes = 1,
> > > > + .hsub = 2,
> > > > + }, {
> > > > + .fourcc = DRM_FORMAT_NV12,
> > > > + .v4l2 = V4L2_PIX_FMT_NV12M,
> > > > + .bpp = 12,
> > > > + .planes = 2,
> > > > + .hsub = 2,
> > > > + }, {
> > > > + .fourcc = DRM_FORMAT_NV21,
> > > > + .v4l2 = V4L2_PIX_FMT_NV21M,
> > > > + .bpp = 12,
> > > > + .planes = 2,
> > > > + .hsub = 2,
> > > > + }, {
> > > > + .fourcc = DRM_FORMAT_NV16,
> > > > + .v4l2 = V4L2_PIX_FMT_NV16M,
> > > > + .bpp = 16,
> > > > + .planes = 2,
> > > > + .hsub = 2,
> > > > + },
> > > > + {
> > > > + .fourcc = DRM_FORMAT_RGB332,
> > > > + .v4l2 = V4L2_PIX_FMT_RGB332,
> > > > + .bpp = 8,
> > > > + .planes = 1,
> > > > + .hsub = 1,
> > > > + }, {
> > > > + .fourcc = DR
Re: [PATCH v10 3/4] drm: renesas: Add RZ/G2L DU Support
Hi Biju
On Tue, Jul 04, 2023 at 10:04:46AM +0100, Biju Das wrote:
> The LCD controller is composed of Frame Compression Processor (FCPVD),
> Video Signal Processor (VSPD), and Display Unit (DU).
>
> It has DPI/DSI interfaces and supports a maximum resolution of 1080p
> along with 2 RPFs to support the blending of two picture layers and
> raster operations (ROPs).
>
> The DU module is connected to VSPD. Add RZ/G2L DU support for RZ/G2L
> alike SoCs.
>
> Signed-off-by: Biju Das
> ---
> Ref:
>
> https://lore.kernel.org/linux-renesas-soc/os0pr01mb5922717e4ccfe07f3c25fbc986...@os0pr01mb5922.jpnprd01.prod.outlook.com/#t
> v9->v10:
> * Dropped ARM64 dependency from Kconfig.
> * Sorted the configs alphabetically in Kconfig.
> * Dropped DRM_RCAR_VSP config option and make DRM_RZG2L_DU depend on
>VIDEO_RENESAS_VSP1.
> * On rzg2l_du_crtc_set_display_timing() replaced the setting of parent
>clk rate with dclk rate.
> * Added rzg2l_du_write() wrapper function.
> * Updated the comment atomic_begin->atomic_flush.
> * Dropped .atomic_check and .atomic_begin callback
> * Renamed __rzg2l_du_crtc_plane_atomic_check->__rzg2l_du_vsp_plane_atomic
>_check and moved it to rzg2l_du_vsp.c
> * Added struct clk in rzg2l_du_crtc.h
> * Dropped the variables mmio_offset,index,vblank_lock,vblank_wait,
>vblank_count from struct rzg2l_du_crtc.
> * Replaced the macro to_rzg2l_crtc with static inline functions.
> * Dropped the unneeded header files clk.h, io.h, mm.h, pm.h, slab.h,
>wait.h and drm_managed.h from rzg2l_du_drv.c.
> * Replaced DRM_INFO->drm_info
> * Dropped the callbacks prime_handle_to_fd, prime_fd_to_handle and
>gem_prime_mmap.
> * Replaced the callback remove->remove_new.
> * Dropped header file wait.h and added forward declarations struct clk and
>rzg2l_du_device from rzg2l_du_drv.h.
> * Dropped the dsi and dpad0_source variables from struct rzg2l_du_device.
> * Replaced the macro to_rzg2l_encoder with static inline functions.
> * Dropped header files dma-buf.h and wait.h from rzg2l_du_kms.c.
> * Dropped struct sg_table and added the scatterlist.h header file in
>rzg2l_du_vsp.h
> * Added container_of.h header file, forward declarations struct device and
>struct rzg2l_du_device in rzg2l_du_vsp.h.
> v8->v9:
> * Dropped reset_control_assert() from error patch for rzg2l_du_crtc_get() as
>suggested by Philipp Zabel.
> v7->v8:
> * Dropped RCar du lib and created RZ/G2L DU DRM driver by creating rz_du
> folder.
> * Updated KConfig and Makefile.
> v6->v7:
> * Split DU lib and RZ/G2L du driver as separate patch series as
>DU support added to more platforms based on RZ/G2L alike SoCs.
> * Rebased to latest drm-tip.
> * Added patch #2 for binding support for RZ/V2L DU
> * Added patch #4 for driver support for RZ/V2L DU
> * Added patch #5 for SoC DTSI support for RZ/G2L DU
> * Added patch #6 for SoC DTSI support for RZ/V2L DU
> * Added patch #7 for Enabling DU on SMARC EVK based on RZ/{G2L,V2L} SoCs.
> * Added patch #8 for Enabling DU on SMARC EVK based on RZ/G2LC SoC.
> ---
> drivers/gpu/drm/renesas/Kconfig | 1 +
> drivers/gpu/drm/renesas/Makefile | 1 +
> drivers/gpu/drm/renesas/rz-du/Kconfig | 12 +
> drivers/gpu/drm/renesas/rz-du/Makefile| 8 +
> drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c | 599 ++
> drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.h | 92 +++
> drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c | 180 +
> drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h | 84 ++
> .../gpu/drm/renesas/rz-du/rzg2l_du_encoder.c | 109 +++
> .../gpu/drm/renesas/rz-du/rzg2l_du_encoder.h | 32 +
> drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c | 741 ++
> drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.h | 43 +
> drivers/gpu/drm/renesas/rz-du/rzg2l_du_regs.h | 67 ++
> drivers/gpu/drm/renesas/rz-du/rzg2l_du_vsp.c | 469 +++
> drivers/gpu/drm/renesas/rz-du/rzg2l_du_vsp.h | 97 +++
> 15 files changed, 2535 insertions(+)
> create mode 100644 drivers/gpu/drm/renesas/rz-du/Kconfig
> create mode 100644 drivers/gpu/drm/renesas/rz-du/Makefile
> create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
> create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.h
> create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c
> create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h
> create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_encoder.c
> create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_encoder.h
> create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c
> create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.h
> create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_regs.h
> create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_vsp.c
> create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_vsp.h
>
> diff --git a/drivers/gpu/drm/renesas/Kconfig b/drivers/gpu/drm/renesas/Kconfig
> index 3777dad17f8
[RFC 6/9] drm: rcar-du: cmm: Refactor LUT configuration
From: Laurent Pinchart
To prepare for CLU support, expend the CMM API exposed to the DU driver
to separate the LUT table pointer from the LUT update decision. This
will be required, as we will need to update the LUT and CLU
independently.
Signed-off-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
Signed-off-by: Jacopo Mondi
---
drivers/gpu/drm/rcar-du/rcar_cmm.c | 60 --
drivers/gpu/drm/rcar-du/rcar_cmm.h | 19 +---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 22 +++---
3 files changed, 55 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_cmm.c
b/drivers/gpu/drm/rcar-du/rcar_cmm.c
index e2a67dda4658..df768a9afb72 100644
--- a/drivers/gpu/drm/rcar-du/rcar_cmm.c
+++ b/drivers/gpu/drm/rcar-du/rcar_cmm.c
@@ -42,23 +42,33 @@ static inline void rcar_cmm_write(struct rcar_cmm *rcmm,
u32 reg, u32 data)
iowrite32(data, rcmm->base + reg);
}
-/*
- * rcar_cmm_lut_write() - Scale the DRM LUT table entries to hardware precision
- * and write to the CMM registers
- * @rcmm: Pointer to the CMM device
- * @drm_lut: Pointer to the DRM LUT table
- */
-static void rcar_cmm_lut_write(struct rcar_cmm *rcmm,
- const struct drm_color_lut *drm_lut)
+static void rcar_cmm_lut_configure(struct rcar_cmm *rcmm,
+ const struct drm_color_lut *table)
{
- unsigned int i;
+ bool enable = !!table;
+
+ if (rcmm->lut.enabled != enable) {
+ rcar_cmm_write(rcmm, CM2_LUT_CTRL,
+ enable ? CM2_LUT_CTRL_LUT_EN : 0);
+ rcmm->lut.enabled = enable;
+ }
- for (i = 0; i < CM2_LUT_SIZE; ++i) {
- u32 entry = drm_color_lut_extract(drm_lut[i].red, 8) << 16
- | drm_color_lut_extract(drm_lut[i].green, 8) << 8
- | drm_color_lut_extract(drm_lut[i].blue, 8);
+ if (table) {
+ unsigned int i;
- rcar_cmm_write(rcmm, CM2_LUT_TBL(i), entry);
+ /*
+* Scale the DRM LUT table entries to the hardware precision
+* and program it.
+*/
+ for (i = 0; i < CM2_LUT_SIZE; ++i) {
+ const struct drm_color_lut *lut = &table[i];
+
+ u32 entry = drm_color_lut_extract(lut->red, 8) << 16
+ | drm_color_lut_extract(lut->green, 8) << 8
+ | drm_color_lut_extract(lut->blue, 8);
+
+ rcar_cmm_write(rcmm, CM2_LUT_TBL(i), entry);
+ }
}
}
@@ -83,23 +93,8 @@ int rcar_cmm_setup(struct platform_device *pdev,
{
struct rcar_cmm *rcmm = platform_get_drvdata(pdev);
- /* Disable LUT if no table is provided. */
- if (!config->lut.table) {
- if (rcmm->lut.enabled) {
- rcar_cmm_write(rcmm, CM2_LUT_CTRL, 0);
- rcmm->lut.enabled = false;
- }
-
- return 0;
- }
-
- /* Enable LUT and program the new gamma table values. */
- if (!rcmm->lut.enabled) {
- rcar_cmm_write(rcmm, CM2_LUT_CTRL, CM2_LUT_CTRL_LUT_EN);
- rcmm->lut.enabled = true;
- }
-
- rcar_cmm_lut_write(rcmm, config->lut.table);
+ if (config->lut.update)
+ rcar_cmm_lut_configure(rcmm, config->lut.table);
return 0;
}
@@ -144,8 +139,7 @@ void rcar_cmm_disable(struct platform_device *pdev)
{
struct rcar_cmm *rcmm = platform_get_drvdata(pdev);
- rcar_cmm_write(rcmm, CM2_LUT_CTRL, 0);
- rcmm->lut.enabled = false;
+ rcar_cmm_lut_configure(rcmm, NULL);
pm_runtime_put(&pdev->dev);
}
diff --git a/drivers/gpu/drm/rcar-du/rcar_cmm.h
b/drivers/gpu/drm/rcar-du/rcar_cmm.h
index 628072acc98b..375a3b9c3db3 100644
--- a/drivers/gpu/drm/rcar-du/rcar_cmm.h
+++ b/drivers/gpu/drm/rcar-du/rcar_cmm.h
@@ -13,16 +13,23 @@
struct drm_color_lut;
struct platform_device;
+/**
+ * struct rcar_cmm_table_config - CMM LUT configuration
+ * @update: When true, update the LUT configuration.
+ * @table: Table data. The LUT is enabled if non-NULL, and disabled
+ * otherwise. The value is ignored if @update is false.
+ */
+struct rcar_cmm_table_config {
+ bool update;
+ struct drm_color_lut *table;
+};
+
/**
* struct rcar_cmm_config - CMM configuration
- *
- * @lut: 1D-LUT configuration
- * @lut.table: 1D-LUT table entries. Disable LUT operations when NULL
+ * @lut: 1D-LUT configuration
*/
struct rcar_cmm_config {
- struct {
- struct drm_color_lut *table;
- } lut;
+ struct rcar_cmm_table_config lut;
};
#if IS_ENABLED(CONFIG_DRM_RCAR_CMM)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.
[RFC 8/9] drm: rcar-du: kms: Configure the CLU
From: Kieran Bingham
Link the DRM 3D-CLU configuration to the CMM setup configuration.
Signed-off-by: Kieran Bingham
Signed-off-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
Signed-off-by: Jacopo Mondi
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 23 ++-
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index a2d477dc5a51..895a23161f7b 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -521,19 +521,23 @@ static int rcar_du_cmm_check(struct drm_crtc *crtc,
struct drm_crtc_state *state)
{
struct drm_property_blob *drm_lut = state->gamma_lut;
+ struct drm_property_blob *drm_clu = state->lut3d;
struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
struct device *dev = rcrtc->dev->dev;
- if (!drm_lut)
- return 0;
-
- /* We only accept fully populated LUT tables. */
- if (drm_color_lut_size(drm_lut) != CM2_LUT_SIZE) {
+ /* We only accept fully populated LUTs. */
+ if (drm_lut && drm_color_lut_size(drm_lut) != CM2_LUT_SIZE) {
dev_err(dev, "invalid gamma lut size: %zu bytes\n",
drm_lut->length);
return -EINVAL;
}
+ if (drm_clu && drm_color_lut_size(drm_clu) != CM2_CLU_SIZE) {
+ dev_err(dev, "invalid cubic lut size: %zu bytes\n",
+ drm_clu->length);
+ return -EINVAL;
+ }
+
return 0;
}
@@ -555,6 +559,15 @@ static void rcar_du_cmm_setup(struct rcar_du_crtc *rcrtc,
? new_state->gamma_lut->data : NULL;
}
+ if (!old_state ||
+ !old_state->lut3d != !new_state->lut3d ||
+ (old_state->lut3d && new_state->lut3d &&
+old_state->lut3d->base.id != new_state->lut3d->base.id)) {
+ cmm_config.clu.update = true;
+ cmm_config.clu.table = new_state->lut3d
+? new_state->lut3d->data : NULL;
+ }
+
rcar_cmm_setup(rcrtc->cmm, &cmm_config);
}
--
2.40.1
[RFC 7/9] drm: rcar-du: cmm: Provide 3D-CLU support
From: Kieran Bingham
The CMM module provides a three-dimensional cubic look up table that
converts three-color-component data into desired three color components
by use of a lookup table.
While the 1D-LUT can only control each of three color components
separately, the 3D-CLU can be used for specific color adjustment.
Signed-off-by: Kieran Bingham
Signed-off-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
Signed-off-by: Jacopo Mondi
---
drivers/gpu/drm/rcar-du/rcar_cmm.c | 71 +-
drivers/gpu/drm/rcar-du/rcar_cmm.h | 11 +++--
2 files changed, 76 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_cmm.c
b/drivers/gpu/drm/rcar-du/rcar_cmm.c
index df768a9afb72..defedfaf8f56 100644
--- a/drivers/gpu/drm/rcar-du/rcar_cmm.c
+++ b/drivers/gpu/drm/rcar-du/rcar_cmm.c
@@ -17,9 +17,18 @@
#define CM2_LUT_CTRL 0x
#define CM2_LUT_CTRL_LUT_ENBIT(0)
+
+#define CM2_CLU_CTRL 0x0100
+#define CM2_CLU_CTRL_CLU_ENBIT(0)
+#define CM2_CLU_CTRL_MVS BIT(24)
+#define CM2_CLU_CTRL_AAI BIT(28)
+
#define CM2_LUT_TBL_BASE 0x0600
#define CM2_LUT_TBL(__i) (CM2_LUT_TBL_BASE + (__i) * 4)
+#define CM2_CLU_ADDR 0x0a00
+#define CM2_CLU_DATA 0x0a04
+
struct rcar_cmm {
void __iomem *base;
@@ -30,6 +39,10 @@ struct rcar_cmm {
struct {
bool enabled;
} lut;
+
+ struct {
+ bool enabled;
+ } clu;
};
static inline int rcar_cmm_read(struct rcar_cmm *rcmm, u32 reg)
@@ -72,13 +85,63 @@ static void rcar_cmm_lut_configure(struct rcar_cmm *rcmm,
}
}
+static void rcar_cmm_clu_program(struct rcar_cmm *rcmm,
+const struct drm_color_lut *table)
+{
+ unsigned int i;
+
+ /* Utilise CM2_CLU_CTRL_AAI (auto-increment). */
+ rcar_cmm_write(rcmm, CM2_CLU_ADDR, 0);
+
+ for (i = 0; i < CM2_CLU_SIZE; ++i) {
+ const struct drm_color_lut *lut = &table[i];
+
+ u32 entry = drm_color_lut_extract(lut->red, 8) << 16
+ | drm_color_lut_extract(lut->green, 8) << 8
+ | drm_color_lut_extract(lut->blue, 8);
+
+ rcar_cmm_write(rcmm, CM2_CLU_DATA, entry);
+ }
+}
+
+static void rcar_cmm_clu_configure(struct rcar_cmm *rcmm,
+ const struct drm_color_lut *table)
+{
+ static const u32 clu_ctrl = CM2_CLU_CTRL_AAI | CM2_CLU_CTRL_MVS
+ | CM2_CLU_CTRL_CLU_EN;
+ bool enable = !!table;
+
+ if (rcmm->clu.enabled != enable) {
+ /*
+* This is the first run of the CLU. We need to program
+* the CLU data before enabling the peripheral.
+*/
+ if (enable) {
+ rcar_cmm_write(rcmm, CM2_CLU_CTRL, CM2_CLU_CTRL_AAI);
+ rcar_cmm_clu_program(rcmm, table);
+ }
+
+ rcar_cmm_write(rcmm, CM2_CLU_CTRL, enable ? clu_ctrl : 0);
+ rcmm->clu.enabled = enable;
+
+ return;
+ }
+
+ /*
+* CLU already enabled, but the 3D LUT has been updated; re-program
+* the data table with the new values.
+*/
+ if (table)
+ rcar_cmm_clu_program(rcmm, table);
+}
+
/*
* rcar_cmm_setup() - Configure the CMM unit
* @pdev: The platform device associated with the CMM instance
* @config: The CMM unit configuration
*
- * Configure the CMM unit with the given configuration. Currently enabling,
- * disabling and programming of the 1-D LUT unit is supported.
+ * Configure the CMM unit with the given configuration, handling both the
+ * 1-D LUT and the 3-D CLU.
*
* As rcar_cmm_setup() accesses the CMM registers the unit should be powered
* and its functional clock enabled. To guarantee this, before any call to
@@ -96,6 +159,9 @@ int rcar_cmm_setup(struct platform_device *pdev,
if (config->lut.update)
rcar_cmm_lut_configure(rcmm, config->lut.table);
+ if (config->clu.update)
+ rcar_cmm_clu_configure(rcmm, config->clu.table);
+
return 0;
}
EXPORT_SYMBOL_GPL(rcar_cmm_setup);
@@ -140,6 +206,7 @@ void rcar_cmm_disable(struct platform_device *pdev)
struct rcar_cmm *rcmm = platform_get_drvdata(pdev);
rcar_cmm_lut_configure(rcmm, NULL);
+ rcar_cmm_clu_configure(rcmm, NULL);
pm_runtime_put(&pdev->dev);
}
diff --git a/drivers/gpu/drm/rcar-du/rcar_cmm.h
b/drivers/gpu/drm/rcar-du/rcar_cmm.h
index 375a3b9c3db3..277b9e4d9cc4 100644
--- a/drivers/gpu/drm/rcar-du/rcar_cmm.h
+++ b/drivers/gpu/drm/rcar-du/rcar_cmm.h
@@ -9,14 +9,15 @@
#define __RCAR_CMM_H__
#define CM2_LUT_SIZE 256
+#define CM2_CLU_SIZE (17 * 17 * 17)
struct drm_color_lut;
struct platform_device;
/**
- * struct rcar_cmm_table_
[RFC 9/9] drm: rcar-du: crtc: Enable 3D LUT
Enable the 3D LUT in rcar_du_crtc by first creating a property for
the supported 3d lut modes and by calling the drm_crtc_enable_lut3d()
helper.
Signed-off-by: Jacopo Mondi
---
drivers/gpu/drm/rcar-du/rcar_cmm.h | 14 ++
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 23 +--
2 files changed, 35 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_cmm.h
b/drivers/gpu/drm/rcar-du/rcar_cmm.h
index 277b9e4d9cc4..eed9e480a96f 100644
--- a/drivers/gpu/drm/rcar-du/rcar_cmm.h
+++ b/drivers/gpu/drm/rcar-du/rcar_cmm.h
@@ -8,6 +8,8 @@
#ifndef __RCAR_CMM_H__
#define __RCAR_CMM_H__
+#include
+
#define CM2_LUT_SIZE 256
#define CM2_CLU_SIZE (17 * 17 * 17)
@@ -43,6 +45,16 @@ void rcar_cmm_disable(struct platform_device *pdev);
int rcar_cmm_setup(struct platform_device *pdev,
const struct rcar_cmm_config *config);
+
+static const struct drm_mode_lut3d_mode rcar_cmm_3dlut_modes[] = {
+ {
+ .lut_size = 17,
+ .lut_stride = {17, 17, 17},
+ .bit_depth = 8,
+ .color_format = DRM_FORMAT_XRGB16161616,
+ .flags = 0,
+ },
+};
#else
static inline int rcar_cmm_init(struct platform_device *pdev)
{
@@ -63,6 +75,8 @@ static inline int rcar_cmm_setup(struct platform_device *pdev,
{
return 0;
}
+
+static const struct drm_mode_lut3d_mode rcar_cmm_3dlut_modes[] = { };
#endif /* IS_ENABLED(CONFIG_DRM_RCAR_CMM) */
#endif /* __RCAR_CMM_H__ */
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 895a23161f7b..126083d226d2 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -571,6 +571,24 @@ static void rcar_du_cmm_setup(struct rcar_du_crtc *rcrtc,
rcar_cmm_setup(rcrtc->cmm, &cmm_config);
}
+static int rcar_du_cmm_enable_color_mgmt(struct rcar_du_crtc *rcrtc)
+{
+ struct drm_crtc *crtc = &rcrtc->crtc;
+ int ret;
+
+ drm_mode_crtc_set_gamma_size(crtc, CM2_LUT_SIZE);
+ drm_crtc_enable_color_mgmt(crtc, 0, false, CM2_LUT_SIZE);
+
+ ret = drm_crtc_create_lut3d_mode_property(crtc, rcar_cmm_3dlut_modes,
+
ARRAY_SIZE(rcar_cmm_3dlut_modes));
+ if (ret)
+ return ret;
+
+ drm_crtc_enable_lut3d(crtc, 0);
+
+ return 0;
+}
+
/*
-
* Start/Stop and Suspend/Resume
*/
@@ -1355,8 +1373,9 @@ int rcar_du_crtc_create(struct rcar_du_group *rgrp,
unsigned int swindex,
rcrtc->cmm = rcdu->cmms[swindex];
rgrp->cmms_mask |= BIT(hwindex % 2);
- drm_mode_crtc_set_gamma_size(crtc, CM2_LUT_SIZE);
- drm_crtc_enable_color_mgmt(crtc, 0, false, CM2_LUT_SIZE);
+ ret = rcar_du_cmm_enable_color_mgmt(rcrtc);
+ if (ret)
+ return ret;
}
drm_crtc_helper_add(crtc, &crtc_helper_funcs);
--
2.40.1
[RFC 5/9] drm/drm_color_mgmt: add function to attach 3D LUT props
From: Melissa Wen
If the driver supports user 3D LUT then it calls a drm function to
attach 3D LUT related properties according to HW caps.
Signed-off-by: Melissa Wen
---
drivers/gpu/drm/drm_color_mgmt.c | 35
include/drm/drm_color_mgmt.h | 3 +++
2 files changed, 38 insertions(+)
diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index 6ce48007cdd4..06503f693ecd 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -269,6 +269,41 @@ int drm_crtc_create_lut3d_mode_property(struct drm_crtc
*crtc,
}
EXPORT_SYMBOL(drm_crtc_create_lut3d_mode_property);
+/**
+ * drm_crtc_enable_lut3d - enable 3D LUT properties
+ * @crtc: DRM CRTC
+ * @shaper_lut_size: the size of shaper lut
+ *
+ * This function lets the driver enable the 3D LUT color correction property
+ * on a CRTC. This includes 3D LUT and also a shaper LUT, if set. The shaper
+ * LUT property is only attached if its size is not 0 and 3D LUT is set, being
+ * therefore optional.
+ */
+void drm_crtc_enable_lut3d(struct drm_crtc *crtc,
+ uint shaper_lut_size)
+{
+ struct drm_device *dev = crtc->dev;
+ struct drm_mode_config *config = &dev->mode_config;
+
+ if (!config->lut3d_mode_property)
+ return;
+
+ drm_object_attach_property(&crtc->base,
+ config->lut3d_property, 0);
+ drm_object_attach_property(&crtc->base,
+ config->lut3d_mode_property, 0);
+
+ if (!shaper_lut_size)
+ return;
+
+ drm_object_attach_property(&crtc->base,
+ config->shaper_lut_property, 0);
+ drm_object_attach_property(&crtc->base,
+ config->shaper_lut_size_property,
+ shaper_lut_size);
+}
+EXPORT_SYMBOL(drm_crtc_enable_lut3d);
+
/**
* drm_mode_crtc_set_gamma_size - set the gamma table size
* @crtc: CRTC to set the gamma table size for
diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
index af9305925572..db2026dc825e 100644
--- a/include/drm/drm_color_mgmt.h
+++ b/include/drm/drm_color_mgmt.h
@@ -63,6 +63,9 @@ int drm_crtc_create_lut3d_mode_property(struct drm_crtc *crtc,
const struct drm_mode_lut3d_mode
modes[],
unsigned int num_modes);
+void drm_crtc_enable_lut3d(struct drm_crtc *crtc,
+ uint shaper_lut_size);
+
int drm_mode_crtc_set_gamma_size(struct drm_crtc *crtc,
int gamma_size);
--
2.40.1
[RFC 4/9] drm/drm_color_mgmt: add function to create 3D LUT modes supported
From: Melissa Wen
DRM color function to create modes for lut3d mode property from an array
of drm_color_lut3d_mode modes supported by the HW and advertise to
userspace. Userspace can get the description of a specific mode in the
enum list from its blob data.
Signed-off-by: Melissa Wen
---
drivers/gpu/drm/drm_color_mgmt.c | 43 +++-
include/drm/drm_color_mgmt.h | 4 +++
2 files changed, 46 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index f92633b3b67e..6ce48007cdd4 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -104,7 +104,7 @@
* LUT3D property. A mode specifies size, stride, bit depth and color
* format and depends on the underlying hardware). If drivers support
* multiple 3D LUT modes, they should be declared in a array of
- * drm_color_lut3d_mode and they will be advertised as an enum.
+ * drm_mode_lut3d_mode and they will be advertised as an enum.
*
* “GAMMA_LUT”:
* Blob property to set the gamma lookup table (LUT) mapping pixel data
@@ -228,6 +228,47 @@ void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
}
EXPORT_SYMBOL(drm_crtc_enable_color_mgmt);
+int drm_crtc_create_lut3d_mode_property(struct drm_crtc *crtc,
+ const struct drm_mode_lut3d_mode
modes[],
+ unsigned int num_modes)
+{
+ struct drm_device *dev = crtc->dev;
+ struct drm_property_blob *blob;
+ struct drm_property *prop;
+ char *name;
+ int ret;
+
+ if (dev->mode_config.lut3d_mode_property)
+ return 0;
+
+ prop = drm_property_create(dev, DRM_MODE_PROP_ENUM, "LUT3D_MODE",
num_modes);
+ if (!prop)
+ return -EINVAL;
+
+ for (int i = 0; i < num_modes; i++) {
+ blob = drm_property_create_blob(dev, sizeof(modes[i]),
&modes[i]);
+ if (IS_ERR(blob))
+ return PTR_ERR(blob);
+
+ name = kasprintf(GFP_KERNEL, "lut3d_%d_%dbit",
+modes[i].lut_size, modes[i].bit_depth);
+ if (!name)
+ return -ENOMEM;
+
+ ret = drm_property_add_enum(prop, blob->base.id, name);
+ if (ret) {
+ drm_property_blob_put(blob);
+ kfree(name);
+ return ret;
+ }
+ kfree(name);
+ }
+ dev->mode_config.lut3d_mode_property = prop;
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_crtc_create_lut3d_mode_property);
+
/**
* drm_mode_crtc_set_gamma_size - set the gamma table size
* @crtc: CRTC to set the gamma table size for
diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
index 81c298488b0c..af9305925572 100644
--- a/include/drm/drm_color_mgmt.h
+++ b/include/drm/drm_color_mgmt.h
@@ -59,6 +59,10 @@ void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
bool has_ctm,
uint gamma_lut_size);
+int drm_crtc_create_lut3d_mode_property(struct drm_crtc *crtc,
+ const struct drm_mode_lut3d_mode
modes[],
+ unsigned int num_modes);
+
int drm_mode_crtc_set_gamma_size(struct drm_crtc *crtc,
int gamma_size);
--
2.40.1
[RFC 2/9] drm/drm_color_mgmt: add shaper LUT to color mgmt properties
From: Melissa Wen
Shaper LUT is used to shape the content after blending, i.e.,
de-linearize or normalize space before applying a 3D LUT color
correction. In the next patch, we add 3D LUT property to DRM color
management after this shaper LUT and before the current gamma LUT.
Signed-off-by: Melissa Wen
---
drivers/gpu/drm/drm_atomic_state_helper.c | 4
drivers/gpu/drm/drm_atomic_uapi.c | 10 ++
drivers/gpu/drm/drm_color_mgmt.c | 18 ++
drivers/gpu/drm/drm_fb_helper.c | 3 +++
drivers/gpu/drm/drm_mode_config.c | 14 ++
include/drm/drm_crtc.h| 14 --
include/drm/drm_mode_config.h | 12
include/drm/drm_mode_object.h | 2 +-
8 files changed, 74 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c
b/drivers/gpu/drm/drm_atomic_state_helper.c
index 784e63d70a42..b75dcf2aa881 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -141,8 +141,11 @@ void __drm_atomic_helper_crtc_duplicate_state(struct
drm_crtc *crtc,
drm_property_blob_get(state->degamma_lut);
if (state->ctm)
drm_property_blob_get(state->ctm);
+ if (state->shaper_lut)
+ drm_property_blob_get(state->shaper_lut);
if (state->gamma_lut)
drm_property_blob_get(state->gamma_lut);
+
state->mode_changed = false;
state->active_changed = false;
state->planes_changed = false;
@@ -214,6 +217,7 @@ void __drm_atomic_helper_crtc_destroy_state(struct
drm_crtc_state *state)
drm_property_blob_put(state->mode_blob);
drm_property_blob_put(state->degamma_lut);
drm_property_blob_put(state->ctm);
+ drm_property_blob_put(state->shaper_lut);
drm_property_blob_put(state->gamma_lut);
}
EXPORT_SYMBOL(__drm_atomic_helper_crtc_destroy_state);
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index d867e7f9f2cd..d006e4934ba2 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -430,6 +430,14 @@ static int drm_atomic_crtc_set_property(struct drm_crtc
*crtc,
&replaced);
state->color_mgmt_changed |= replaced;
return ret;
+ } else if (property == config->shaper_lut_property) {
+ ret = drm_atomic_replace_property_blob_from_id(dev,
+ &state->shaper_lut,
+ val,
+ -1, sizeof(struct drm_color_lut),
+ &replaced);
+ state->color_mgmt_changed |= replaced;
+ return ret;
} else if (property == config->gamma_lut_property) {
ret = drm_atomic_replace_property_blob_from_id(dev,
&state->gamma_lut,
@@ -481,6 +489,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
*val = (state->degamma_lut) ? state->degamma_lut->base.id : 0;
else if (property == config->ctm_property)
*val = (state->ctm) ? state->ctm->base.id : 0;
+ else if (property == config->shaper_lut_property)
+ *val = (state->shaper_lut) ? state->shaper_lut->base.id : 0;
else if (property == config->gamma_lut_property)
*val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
else if (property == config->prop_out_fence_ptr)
diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index d021497841b8..cf6a998b4298 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -69,6 +69,24 @@
* boot-up state too. Drivers can access the blob for the color conversion
* matrix through &drm_crtc_state.ctm.
*
+ * “SHAPER_LUT”:
+ * Blob property to set the shaper lut shaping pixel data after the color
+ * transformation matrix and before applying 3D Lookup Table (3D LUT). It
+ * can be used to delinearize content to get an effective 3D LUT mapping.
+ * The data is interpreted as an array of &struct drm_color_lut elements.
+ *
+ * Setting this to NULL (blob property value set to 0) means the output
+ * color is identical to the input color. This is generally the driver
+ * boot-up state too. Drivers can access this blob through
+ * &drm_crtc_state.gamma_lut.
+ *
+ * “SHAPER_LUT_SIZE”:
+ * Unsigned range property to give the size of the shaper lookup table to
+ * be set on the SHAPER_LUT property (the size depends on the underlying
+ * hardware). If drivers support multiple LUT sizes then they should
+ * publish the largest size, and sub-sample smaller sized LUTs
+ * appropriately.
+ *
* “GAMMA_LUT”:
* Blob property to set the gamma lookup table (LUT) mapping
[RFC 3/9] drm/drm_color_mgmt: add 3D LUT props to DRM color mgmt
From: Melissa Wen
Add 3D LUT for gammar correction using a 3D lookup table. The position
in the color correction pipeline where 3D LUT is applied depends on hw
design, being after CTM or gamma. If just after CTM, a shaper lut must
be set to shape the content for a non-linear space. That details should
be handled by the driver according to its color capabilities.
--
v3:
- refactor CRTC 3D LUT API to use Alex Hung proposal for planes
Signed-off-by: Melissa Wen
---
drivers/gpu/drm/drm_atomic_state_helper.c | 3 +++
drivers/gpu/drm/drm_atomic_uapi.c | 14 ++
drivers/gpu/drm/drm_color_mgmt.c | 19 +++
drivers/gpu/drm/drm_fb_helper.c | 2 ++
drivers/gpu/drm/drm_mode_config.c | 7 +++
include/drm/drm_crtc.h| 20 +++-
include/drm/drm_mode_config.h | 13 +
include/drm/drm_mode_object.h | 2 +-
8 files changed, 78 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c
b/drivers/gpu/drm/drm_atomic_state_helper.c
index b75dcf2aa881..0d5ceb5c654c 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -143,6 +143,8 @@ void __drm_atomic_helper_crtc_duplicate_state(struct
drm_crtc *crtc,
drm_property_blob_get(state->ctm);
if (state->shaper_lut)
drm_property_blob_get(state->shaper_lut);
+ if (state->lut3d)
+ drm_property_blob_get(state->lut3d);
if (state->gamma_lut)
drm_property_blob_get(state->gamma_lut);
@@ -218,6 +220,7 @@ void __drm_atomic_helper_crtc_destroy_state(struct
drm_crtc_state *state)
drm_property_blob_put(state->degamma_lut);
drm_property_blob_put(state->ctm);
drm_property_blob_put(state->shaper_lut);
+ drm_property_blob_put(state->lut3d);
drm_property_blob_put(state->gamma_lut);
}
EXPORT_SYMBOL(__drm_atomic_helper_crtc_destroy_state);
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index d006e4934ba2..1f02022e45b3 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -438,6 +438,16 @@ static int drm_atomic_crtc_set_property(struct drm_crtc
*crtc,
&replaced);
state->color_mgmt_changed |= replaced;
return ret;
+ } else if (property == config->lut3d_property) {
+ ret = drm_atomic_replace_property_blob_from_id(dev,
+ &state->lut3d,
+ val,
+ -1, sizeof(struct drm_color_lut),
+ &replaced);
+ state->color_mgmt_changed |= replaced;
+ return ret;
+ } else if (property == config->lut3d_mode_property) {
+ state->lut3d_mode = val;
} else if (property == config->gamma_lut_property) {
ret = drm_atomic_replace_property_blob_from_id(dev,
&state->gamma_lut,
@@ -491,6 +501,10 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
*val = (state->ctm) ? state->ctm->base.id : 0;
else if (property == config->shaper_lut_property)
*val = (state->shaper_lut) ? state->shaper_lut->base.id : 0;
+ else if (property == config->lut3d_property)
+ *val = (state->lut3d) ? state->lut3d->base.id : 0;
+ else if (property == config->lut3d_mode_property)
+ *val = state->lut3d_mode;
else if (property == config->gamma_lut_property)
*val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
else if (property == config->prop_out_fence_ptr)
diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index cf6a998b4298..f92633b3b67e 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -87,6 +87,25 @@
* publish the largest size, and sub-sample smaller sized LUTs
* appropriately.
*
+ * “LUT3D”:
+ * Blob property to set the 3D LUT mapping pixel data after the color
+ * transformation matrix and before gamma 1D lut correction. The
+ * data is interpreted as an array of &struct drm_color_lut elements.
+ * Hardware might choose not to use the full precision of the LUT
+ * elements.
+ *
+ * Setting this to NULL (blob property value set to 0) means a the output
+ * color is identical to the input color. This is generally the driver
+ * boot-up state too. Drivers can access this blob through
+ * &drm_crtc_state.gamma_lut.
+ *
+ * “LUT3D_MODE”:
+ * Enum property to give the mode of the 3D lookup table to be set on the
+ * LUT3D property. A mode specifies size, stride, bit depth and color
+ * format and depends on the underlying hardware). If drivers support
+ *
[RFC 1/9] drm: Add 3D LUT mode and its attributes
From: Alex Hung
A struct is defined for 3D LUT modes to be supported by hardware.
The elements includes lut_size, lut_stride, bit_depth, color_format
and flags.
Note: A patchset "IGT tests for pre-blending 3D LUT interfaces" for this
proposal is sent to IGT mailing list.
Signed-off-by: Alex Hung
---
include/uapi/drm/drm_mode.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 43691058d28f..3b40694259c7 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -854,6 +854,23 @@ struct drm_color_lut {
__u16 reserved;
};
+/*
+ * struct drm_mode_lut3d_mode - 3D LUT mode information.
+ * @lut_size: number of valid points on every dimension of 3D LUT.
+ * @lut_stride: number of points on every dimension of 3D LUT.
+ * @bit_depth: number of bits of RGB. If color_mode defines entries with higher
+ * bit_depth the least significant bits will be truncated.
+ * @color_format: fourcc values, ex. DRM_FORMAT_XRGB16161616 or
DRM_FORMAT_XBGR16161616.
+ * @flags: flags for hardware-sepcific features
+ */
+struct drm_mode_lut3d_mode {
+ __u16 lut_size;
+ __u16 lut_stride[3];
+ __u16 bit_depth;
+ __u32 color_format;
+ __u32 flags;
+};
+
/**
* struct hdr_metadata_infoframe - HDR Metadata Infoframe Data.
*
--
2.40.1
[RFC 0/9] drm: rcar-du: cmm: Enable 3D LUT support
Hello, this series is based on the RFC sent by Melssa Wen: "[RFC PATCH v2 00/18] Add DRM CRTC 3D LUT interface" https://lore.kernel.org/dri-devel/20230109143846.1966301-1-m...@igalia.com/ that introduces CRTC properties to control 3D LUT operations. The R-Car DU peripheral has a post-blending color management pipeline (CMM) composed by (in order of processing) a 3D LUT a 1D LUT and a Color conversion unit. The CMM driver already supported operating the 1D LUT, this series add support for the cubic LUT (named CLU). I've been made aware by Melissa and Pekka that the focus of upstream for color management properties is now on the definition of the "Plane color pipeline" properties https://lore.kernel.org/dri-devel/QMers3awXvNCQlyhWdTtsPwkp5ie9bze_hD5nAccFW7a_RXlWjYB7MoUW_8CKLT2bSQwIXVi5H6VULYIxCdgvryZoAoJnC5lZgyK1QWn488=@emersion.fr/ Unfortunately the model there proposed doesn't match the R-Car DU hardware which has color management at the post-blending level and not per plane (I've cc-ed all the receivers of that series, just in case). The user-space interface has been validated with dedicated unit tests for the R-Car DU test suite (kms-test) which are available at: https://git.sr.ht/~jmondi_/kms-test The series validates the usage of the HW interface in the hope of re-starting discussions and interests in the definition of CRTC color management properties. Thanks j Alex Hung (1): drm: Add 3D LUT mode and its attributes Jacopo Mondi (1): drm: rcar-du: crtc: Enable 3D LUT Kieran Bingham (2): drm: rcar-du: cmm: Provide 3D-CLU support drm: rcar-du: kms: Configure the CLU Laurent Pinchart (1): drm: rcar-du: cmm: Refactor LUT configuration Melissa Wen (4): drm/drm_color_mgmt: add shaper LUT to color mgmt properties drm/drm_color_mgmt: add 3D LUT props to DRM color mgmt drm/drm_color_mgmt: add function to create 3D LUT modes supported drm/drm_color_mgmt: add function to attach 3D LUT props drivers/gpu/drm/drm_atomic_state_helper.c | 7 ++ drivers/gpu/drm/drm_atomic_uapi.c | 24 drivers/gpu/drm/drm_color_mgmt.c | 113 +++ drivers/gpu/drm/drm_fb_helper.c | 5 + drivers/gpu/drm/drm_mode_config.c | 21 drivers/gpu/drm/rcar-du/rcar_cmm.c| 127 -- drivers/gpu/drm/rcar-du/rcar_cmm.h| 36 +- drivers/gpu/drm/rcar-du/rcar_du_crtc.c| 68 +--- include/drm/drm_color_mgmt.h | 7 ++ include/drm/drm_crtc.h| 32 +- include/drm/drm_mode_config.h | 25 + include/drm/drm_mode_object.h | 2 +- include/uapi/drm/drm_mode.h | 17 +++ 13 files changed, 428 insertions(+), 56 deletions(-) -- 2.40.1
Re: [RFC PATCH v2 00/18] Add DRM CRTC 3D LUT interface
Hi Pekka thanks for the reply On Thu, Jun 15, 2023 at 10:14:05AM +0300, Pekka Paalanen wrote: > On Tue, 13 Jun 2023 17:43:55 +0200 > Jacopo Mondi wrote: > > > Hello > > > >I'm completing the support for 3D LUT on R-Car DU peripheral > > and I have used this series as a base. > > > > I'm wondering, since quite some time has passed without any update if > > this series is still a thing and it makes any sense for me to try to > > bring it forward. > > > > I'm asking as I've noticed: > > "[PATCH 00/36] drm/amd/display: add AMD driver-specific properties for > > color mgmt" > > > > which seems to supersede this proposal with driver-specific > > properties. > > > > I asked Melissa privately but I wasn't able to get an hold of her, so > > if anyone has any clue feel free to reply :) > > Hi, > > since no-one else replied, I'll point you to the thread starting at > https://lists.freedesktop.org/archives/dri-devel/2023-May/403173.html Yes, Melissa pointed me to that series privately yesterday. However, and here I might be missing something, per-plane properties do not apply well to the HW pipeline I'm looking at. The R-Car DU has a 1D LUT and a 3D LUT at the CRTC level (I guess 'post blending' is the right term here) ? A per-plane property doesn't seem to match how the HW work, but please feel free to correct me as this is all rather new to me and I might be overlooking something. My plan at the moment would have been to base my work on Melissa's RFC and re-send to prop discussions, unless it is certainly a dead-end and I have missed how to properly use per-plane properties on our HW. Thank you! > and continuing to June. That is the plan of getting a common UAPI for > these things. > > > Thanks, > pq > > > > > > Thanks > > j > > > > On Mon, Jan 09, 2023 at 01:38:28PM -0100, Melissa Wen wrote: > > > Hi, > > > > > > After collecting comments in different places, here is a second version > > > of the work on adding DRM CRTC 3D LUT support to the current DRM color > > > mgmt interface. In comparison to previous proposals [1][2][3], here we > > > add 3D LUT before gamma 1D LUT, but also a shaper 1D LUT before 3D LUT, > > > that means the following DRM CRTC color correction pipeline: > > > > > > Blend -> Degamma 1D LUT -> CTM -> Shaper 1D LUT -> 3D LUT -> Gamma 1D LUT > > > > > > and we also add a DRM CRTC LUT3D_MODE property, based on Alex Hung > > > proposal for pre-blending 3D LUT [4] (Thanks!), instead of just a > > > LUT3D_SIZE, that allows userspace to use different supported settings of > > > 3D LUT, fitting VA-API and new color API better. In this sense, I > > > adjusted the pre-blending proposal for post-blending usage. > > > > > > Patches 1-6 targets the addition of shaper LUT and 3D LUT properties to > > > the current DRM CRTC color mgmt pipeline. Patch 6 can be considered an > > > extra/optional patch to define a default value for LUT3D_MODE, inspired > > > by what we do for the plane blend mode property (pre-multiplied). > > > > > > Patches 7-18 targets AMD display code to enable shaper and 3D LUT usage > > > on DCN 301 (our HW case). Patches 7-9 performs code cleanups on current > > > AMD DM colors code, patch 10 updates AMD stream in case of user 3D LUT > > > changes, patch 11/12 rework AMD MPC 3D LUT resource handling by context > > > for DCN 301 (easily extendible to other DCN families). Finally, from > > > 13-18, we wire up SHAPER LUT, LUT3D and LUT3D MODE to AMD display > > > driver, exposing modes supported by HW and programming user shaper and > > > 3D LUT accordingly. > > > > > > Our target userspace is Gamescope/SteamOS. > > > > > > Basic IGT tests were based on [5][6] and are available here (in-progress): > > > https://gitlab.freedesktop.org/mwen/igt-gpu-tools/-/commits/crtc-lut3d-api > > > > > > [1] > > > https://lore.kernel.org/all/20201221015730.28333-1-laurent.pinchart+rene...@ideasonboard.com/ > > > [2] > > > https://github.com/vsyrjala/linux/commit/4d28e8ddf2a076f30f9e5bdc17cbb4656fe23e69 > > > [3] > > > https://lore.kernel.org/amd-gfx/20220619223104.667413-1-m...@igalia.com/ > > > [4] > > > https://lore.kernel.org/dri-devel/20221004211451.1475215-1-alex.h...@amd.com/ > > > [5] https://patchwork.freedesktop.org/series/90165/ > > > [6] https://patchwork.freedesktop.org/series/109402/ > > > [VA
Re: [RFC PATCH v2 00/18] Add DRM CRTC 3D LUT interface
Hello I'm completing the support for 3D LUT on R-Car DU peripheral and I have used this series as a base. I'm wondering, since quite some time has passed without any update if this series is still a thing and it makes any sense for me to try to bring it forward. I'm asking as I've noticed: "[PATCH 00/36] drm/amd/display: add AMD driver-specific properties for color mgmt" which seems to supersede this proposal with driver-specific properties. I asked Melissa privately but I wasn't able to get an hold of her, so if anyone has any clue feel free to reply :) Thanks j On Mon, Jan 09, 2023 at 01:38:28PM -0100, Melissa Wen wrote: > Hi, > > After collecting comments in different places, here is a second version > of the work on adding DRM CRTC 3D LUT support to the current DRM color > mgmt interface. In comparison to previous proposals [1][2][3], here we > add 3D LUT before gamma 1D LUT, but also a shaper 1D LUT before 3D LUT, > that means the following DRM CRTC color correction pipeline: > > Blend -> Degamma 1D LUT -> CTM -> Shaper 1D LUT -> 3D LUT -> Gamma 1D LUT > > and we also add a DRM CRTC LUT3D_MODE property, based on Alex Hung > proposal for pre-blending 3D LUT [4] (Thanks!), instead of just a > LUT3D_SIZE, that allows userspace to use different supported settings of > 3D LUT, fitting VA-API and new color API better. In this sense, I > adjusted the pre-blending proposal for post-blending usage. > > Patches 1-6 targets the addition of shaper LUT and 3D LUT properties to > the current DRM CRTC color mgmt pipeline. Patch 6 can be considered an > extra/optional patch to define a default value for LUT3D_MODE, inspired > by what we do for the plane blend mode property (pre-multiplied). > > Patches 7-18 targets AMD display code to enable shaper and 3D LUT usage > on DCN 301 (our HW case). Patches 7-9 performs code cleanups on current > AMD DM colors code, patch 10 updates AMD stream in case of user 3D LUT > changes, patch 11/12 rework AMD MPC 3D LUT resource handling by context > for DCN 301 (easily extendible to other DCN families). Finally, from > 13-18, we wire up SHAPER LUT, LUT3D and LUT3D MODE to AMD display > driver, exposing modes supported by HW and programming user shaper and > 3D LUT accordingly. > > Our target userspace is Gamescope/SteamOS. > > Basic IGT tests were based on [5][6] and are available here (in-progress): > https://gitlab.freedesktop.org/mwen/igt-gpu-tools/-/commits/crtc-lut3d-api > > [1] > https://lore.kernel.org/all/20201221015730.28333-1-laurent.pinchart+rene...@ideasonboard.com/ > [2] > https://github.com/vsyrjala/linux/commit/4d28e8ddf2a076f30f9e5bdc17cbb4656fe23e69 > [3] https://lore.kernel.org/amd-gfx/20220619223104.667413-1-m...@igalia.com/ > [4] > https://lore.kernel.org/dri-devel/20221004211451.1475215-1-alex.h...@amd.com/ > [5] https://patchwork.freedesktop.org/series/90165/ > [6] https://patchwork.freedesktop.org/series/109402/ > [VA_API] > http://intel.github.io/libva/structVAProcFilterParameterBuffer3DLUT.html > [KMS_pipe_API] https://gitlab.freedesktop.org/pq/color-and-hdr/-/issues/11 > > Let me know your thoughts. > > Thanks, > > Melissa > > Alex Hung (2): > drm: Add 3D LUT mode and its attributes > drm/amd/display: Define 3D LUT struct for HDR planes > > Melissa Wen (16): > drm/drm_color_mgmt: add shaper LUT to color mgmt properties > drm/drm_color_mgmt: add 3D LUT props to DRM color mgmt > drm/drm_color_mgmt: add function to create 3D LUT modes supported > drm/drm_color_mgmt: add function to attach 3D LUT props > drm/drm_color_mgmt: set first lut3d mode as default > drm/amd/display: remove unused regamma condition > drm/amd/display: add comments to describe DM crtc color mgmt behavior > drm/amd/display: encapsulate atomic regamma operation > drm/amd/display: update lut3d and shaper lut to stream > drm/amd/display: handle MPC 3D LUT resources for a given context > drm/amd/display: acquire/release 3D LUT resources for ctx on DCN301 > drm/amd/display: expand array of supported 3D LUT modes > drm/amd/display: enable 3D-LUT DRM properties if supported > drm/amd/display: add user 3D LUT support to the amdgpu_dm color > pipeline > drm/amd/display: decouple steps to reuse in shaper LUT support > drm/amd/display: add user shaper LUT support to amdgpu_dm color > pipeline > > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 6 + > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 3 + > .../amd/display/amdgpu_dm/amdgpu_dm_color.c | 370 -- > .../amd/display/amdgpu_dm/amdgpu_dm_crtc.c| 2 + > drivers/gpu/drm/amd/display/dc/core/dc.c | 49 ++- > drivers/gpu/drm/amd/display/dc/dc.h | 8 + > .../amd/display/dc/dcn301/dcn301_resource.c | 47 ++- > .../amd/display/modules/color/color_gamma.h | 43 ++ > drivers/gpu/drm/drm_atomic_state_helper.c | 7 + > drivers/gpu/drm/drm_atomic_uapi.c | 24 ++ > drivers/gpu/drm/drm_color_mgmt.c | 127 ++ > d
Re: [PATCH v3 1/6] dt-bindings: media: Add macros for video interface bus types
Hi Laurent On Thu, Jun 16, 2022 at 01:14:05AM +0300, Laurent Pinchart wrote: > Add a new dt-bindings/media/video-interfaces.h header that defines > macros corresponding to the bus types from media/video-interfaces.yaml. > This allows avoiding hardcoded constants in device tree sources. > > Signed-off-by: Laurent Pinchart Just putting a tag here as we have more flags to add here (in example the device orientation) Reviewed-by: Jacopo Mondi > --- > Changes since v2: > > - Go back to PARALLEL > > Changes since v1: > > - Dual-license under GPL-2.0-only or MIT > - Rename PARALLEL TO BT601 > --- > include/dt-bindings/media/video-interfaces.h | 16 > 1 file changed, 16 insertions(+) > create mode 100644 include/dt-bindings/media/video-interfaces.h > > diff --git a/include/dt-bindings/media/video-interfaces.h > b/include/dt-bindings/media/video-interfaces.h > new file mode 100644 > index ..68ac4e05e37f > --- /dev/null > +++ b/include/dt-bindings/media/video-interfaces.h > @@ -0,0 +1,16 @@ > +/* SPDX-License-Identifier: (GPL-2.0-only OR MIT) */ > +/* > + * Copyright (C) 2022 Laurent Pinchart > + */ > + > +#ifndef __DT_BINDINGS_MEDIA_VIDEO_INTERFACES_H__ > +#define __DT_BINDINGS_MEDIA_VIDEO_INTERFACES_H__ > + > +#define MEDIA_BUS_TYPE_CSI2_CPHY 1 > +#define MEDIA_BUS_TYPE_CSI1 2 > +#define MEDIA_BUS_TYPE_CCP2 3 > +#define MEDIA_BUS_TYPE_CSI2_DPHY 4 > +#define MEDIA_BUS_TYPE_PARALLEL 5 > +#define MEDIA_BUS_TYPE_BT656 6 > + > +#endif /* __DT_BINDINGS_MEDIA_VIDEO_INTERFACES_H__ */ > -- > Regards, > > Laurent Pinchart >
Re: [PATCH v2 1/4] drm: rcar-du: lvds: Convert to DRM panel bridge helper
Hi Laurent,
On Wed, Dec 16, 2020 at 03:49:24PM +0200, Laurent Pinchart wrote:
> Hi Jacopo,
>
> > > + if (lvds->panel) {
> > > + lvds->next_bridge = devm_drm_panel_bridge_add(lvds->dev,
> > > + lvds->panel);
> >
> > Reading the devm_drm_panel_bridge_add() function documentation:
> >
> > * devm_drm_panel_bridge_add - Creates a managed &drm_bridge and
> > &drm_connector
> >
> > Doesn't this conflict with the drm_bridge_connector_init() called by
> > the encoder in [4/4] ?
>
> It would, if the documentation was right :-) The function only creates a
> bridge. A connector will only be created when the bridge is attached
> without DRM_BRIDGE_ATTACH_NO_CONNECTOR.
Well, reading it again, it is kind of implied that if NO_CONNECTOR is
given to the bridge, no connector will be registered at all.
>
> Would you like to send a patch to fix the documentation ?
>
> > > + if (IS_ERR_OR_NULL(lvds->next_bridge)) {
> > > + ret = -EINVAL;
> > > + goto done;
> > > + }
> > > + }
> > > +
> > > if (lvds->info->quirks & RCAR_LVDS_QUIRK_DUAL_LINK)
> > > ret = rcar_lvds_parse_dt_companion(lvds);
> > >
>
> --
> Regards,
>
> Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: rcar-du: Fix leak of CMM platform device reference
Hi Laurent
On Wed, Dec 16, 2020 at 04:24:11PM +0200, Laurent Pinchart wrote:
> Hi Jacopo,
>
> On Wed, Dec 16, 2020 at 03:16:28PM +0100, Jacopo Mondi wrote:
> > On Wed, Dec 16, 2020 at 04:08:36PM +0200, Laurent Pinchart wrote:
> > > The device references acquired by of_find_device_by_node() are not
> > > released by the driver. Fix this by registering a cleanup action.
> > >
> > > Fixes: 8de707aeb452 ("drm: rcar-du: kms: Initialize CMM instances")
> > > Signed-off-by: Laurent Pinchart
> > >
> > > ---
> > > Changes since v1:
> > >
> > > - Only set rcdu->cmms[] if the CMM config option is enabled
> > > - Use platform_device_put()
> > > ---
> > > drivers/gpu/drm/rcar-du/rcar_du_kms.c | 22 +++---
> > > 1 file changed, 19 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > > b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > > index 92dfa3d4c011..fdb8a0d127ad 100644
> > > --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > > +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > > @@ -14,6 +14,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > > #include
> > > #include
> > >
> > > @@ -726,8 +727,12 @@ static int rcar_du_cmm_init(struct rcar_du_device
> > > *rcdu)
> > >* disabled: return 0 and let the DU continue probing.
> > >*/
> > > ret = rcar_cmm_init(pdev);
> > > - if (ret)
> > > + if (ret) {
> > > + platform_device_put(pdev);
> > > return ret == -ENODEV ? 0 : ret;
> > > + }
> > > +
> > > + rcdu->cmms[i] = pdev;
> > >
> > > /*
> > >* Enforce suspend/resume ordering by making the CMM a provider
> >
> > Sorry but don't we have an error path here below too, and if it fails
> > -EINVAL is returned and the whole modeset_init() bails out without
> > having put the platform device.
>
> There's an error path below, but in that case rcdu->cmms[i] will be set
> and the cleanup action will take care of it.
>
Right, the helper is registered before the init() function eventually
bails out. Sorry for being unnecessarily picky.
Reviewed-by: Jacopo Mondi
Thanks
j
> > > @@ -739,13 +744,20 @@ static int rcar_du_cmm_init(struct rcar_du_device
> > > *rcdu)
> > > "Failed to create device link to CMM%u\n", i);
> > > return -EINVAL;
> > > }
> > > -
> > > - rcdu->cmms[i] = pdev;
> > > }
> > >
> > > return 0;
> > > }
> > >
> > > +static void rcar_du_modeset_cleanup(struct drm_device *dev, void *res)
> > > +{
> > > + struct rcar_du_device *rcdu = to_rcar_du_device(dev);
> > > + unsigned int i;
> > > +
> > > + for (i = 0; i < ARRAY_SIZE(rcdu->cmms); ++i)
> > > + platform_device_put(rcdu->cmms[i]);
> > > +}
> > > +
> > > int rcar_du_modeset_init(struct rcar_du_device *rcdu)
> > > {
> > > static const unsigned int mmio_offsets[] = {
> > > @@ -766,6 +778,10 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu)
> > > if (ret)
> > > return ret;
> > >
> > > + ret = drmm_add_action(&rcdu->ddev, rcar_du_modeset_cleanup, NULL);
> > > + if (ret)
> > > + return ret;
> > > +
> > > dev->mode_config.min_width = 0;
> > > dev->mode_config.min_height = 0;
> > > dev->mode_config.normalize_zpos = true;
>
> --
> Regards,
>
> Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: rcar-du: Fix leak of CMM platform device reference
Hi Laurent,
On Wed, Dec 16, 2020 at 04:08:36PM +0200, Laurent Pinchart wrote:
> The device references acquired by of_find_device_by_node() are not
> released by the driver. Fix this by registering a cleanup action.
>
> Fixes: 8de707aeb452 ("drm: rcar-du: kms: Initialize CMM instances")
> Signed-off-by: Laurent Pinchart
> ---
> Changes since v1:
>
> - Only set rcdu->cmms[] if the CMM config option is enabled
> - Use platform_device_put()
> ---
> drivers/gpu/drm/rcar-du/rcar_du_kms.c | 22 +++---
> 1 file changed, 19 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> index 92dfa3d4c011..fdb8a0d127ad 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -726,8 +727,12 @@ static int rcar_du_cmm_init(struct rcar_du_device *rcdu)
>* disabled: return 0 and let the DU continue probing.
>*/
> ret = rcar_cmm_init(pdev);
> - if (ret)
> + if (ret) {
> + platform_device_put(pdev);
> return ret == -ENODEV ? 0 : ret;
> + }
> +
> + rcdu->cmms[i] = pdev;
>
> /*
>* Enforce suspend/resume ordering by making the CMM a provider
Sorry but don't we have an error path here below too, and if it fails
-EINVAL is returned and the whole modeset_init() bails out without
having put the platform device.
> @@ -739,13 +744,20 @@ static int rcar_du_cmm_init(struct rcar_du_device *rcdu)
> "Failed to create device link to CMM%u\n", i);
> return -EINVAL;
> }
> -
> - rcdu->cmms[i] = pdev;
> }
>
> return 0;
> }
>
> +static void rcar_du_modeset_cleanup(struct drm_device *dev, void *res)
> +{
> + struct rcar_du_device *rcdu = to_rcar_du_device(dev);
> + unsigned int i;
> +
> + for (i = 0; i < ARRAY_SIZE(rcdu->cmms); ++i)
> + platform_device_put(rcdu->cmms[i]);
> +}
> +
> int rcar_du_modeset_init(struct rcar_du_device *rcdu)
> {
> static const unsigned int mmio_offsets[] = {
> @@ -766,6 +778,10 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu)
> if (ret)
> return ret;
>
> + ret = drmm_add_action(&rcdu->ddev, rcar_du_modeset_cleanup, NULL);
> + if (ret)
> + return ret;
> +
> dev->mode_config.min_width = 0;
> dev->mode_config.min_height = 0;
> dev->mode_config.normalize_zpos = true;
> --
> Regards,
>
> Laurent Pinchart
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dt-bindings: display: bridge: renesas, lvds: RZ/G2E needs renesas,companion too
Hi Laurent, Fabrizio On Wed, Dec 16, 2020 at 12:59:27AM +0200, Laurent Pinchart wrote: > From: Fabrizio Castro > > Document RZ/G2E support for property renesas,companion. > > Signed-off-by: Fabrizio Castro > Reviewed-by: Laurent Pinchart > Signed-off-by: Laurent Pinchart Reviewed-by: Jacopo Mondi Thanks j > --- > Changes since v1: > > - Slight reword of SoC list in description > --- > .../devicetree/bindings/display/bridge/renesas,lvds.yaml| 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git > a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml > b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml > index e5b163951b91..7eddcdb666dc 100644 > --- a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml > +++ b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml > @@ -83,9 +83,9 @@ properties: > $ref: /schemas/types.yaml#/definitions/phandle > description: >phandle to the companion LVDS encoder. This property is mandatory > - for the first LVDS encoder on D3 and E3 SoCs, and shall point to > - the second encoder to be used as a companion in dual-link mode. It > - shall not be set for any other LVDS encoder. > + for the first LVDS encoder on R-Car D3 and E3, and RZ/G2E SoCs, and > shall > + point to the second encoder to be used as a companion in dual-link > mode. > + It shall not be set for any other LVDS encoder. > > required: >- compatible > -- > Regards, > > Laurent Pinchart > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: rcar-du: Fix leak of CMM platform device reference
Hi Laurent,
I wonder if 'leaked' is correct in subject. It probably is,
un-balanced ref-counting will prevent the device from being released.
It should however happen only at system tear-down, doesn't it ?
On Wed, Dec 16, 2020 at 03:22:18AM +0200, Laurent Pinchart wrote:
> The device references acquired by of_find_device_by_node() are not
> released by the driver. Fix this by registering a cleanup action.
>
> Fixes: 8de707aeb452 ("drm: rcar-du: kms: Initialize CMM instances")
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/rcar-du/rcar_du_kms.c | 20 ++--
> 1 file changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> index 92dfa3d4c011..7070f3c9b529 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -721,6 +722,8 @@ static int rcar_du_cmm_init(struct rcar_du_device *rcdu)
>
> of_node_put(cmm);
>
> + rcdu->cmms[i] = pdev;
> +
In the unfortunate event that the cmm intialization fails here below,
rcdu->cmms[i] will stay assigned, causing the rcar_du_crtc_create()
function which is called just after rcar_du_cmm_init() to access a
non-valid cmm instance.
I would either reset the rcdu->cmms[i] field to NULL in the below error
paths, or maintain the cmms[i] = pdev assignement at the end of the
function and put_device(pdev->dev) in the error paths.
Thanks
j
> /*
>* -ENODEV is used to report that the CMM config option is
>* disabled: return 0 and let the DU continue probing.
> @@ -739,13 +742,22 @@ static int rcar_du_cmm_init(struct rcar_du_device *rcdu)
> "Failed to create device link to CMM%u\n", i);
> return -EINVAL;
> }
> -
> - rcdu->cmms[i] = pdev;
> }
>
> return 0;
> }
>
> +static void rcar_du_modeset_cleanup(struct drm_device *dev, void *res)
> +{
> + struct rcar_du_device *rcdu = to_rcar_du_device(dev);
> + unsigned int i;
> +
> + for (i = 0; i < ARRAY_SIZE(rcdu->cmms); ++i) {
> + if (rcdu->cmms[i])
> + put_device(&rcdu->cmms[i]->dev);
> + }
> +}
> +
> int rcar_du_modeset_init(struct rcar_du_device *rcdu)
> {
> static const unsigned int mmio_offsets[] = {
> @@ -766,6 +778,10 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu)
> if (ret)
> return ret;
>
> + ret = drmm_add_action(&rcdu->ddev, rcar_du_modeset_cleanup, NULL);
> + if (ret)
> + return ret;
> +
> dev->mode_config.min_width = 0;
> dev->mode_config.min_height = 0;
> dev->mode_config.normalize_zpos = true;
> --
> Regards,
>
> Laurent Pinchart
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/4] drm: rcar-du: lvds: Convert to DRM panel bridge helper
Hi Laurent,
On Wed, Dec 16, 2020 at 02:50:18AM +0200, Laurent Pinchart wrote:
> Replace the manual panel handling with usage of the DRM panel bridge
> helper. This simplifies the driver, and brings support for
> DRM_BRIDGE_ATTACH_NO_CONNECTOR as an added bonus.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/rcar-du/rcar_lvds.c | 120 +++-
> 1 file changed, 12 insertions(+), 108 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> index 70dbbe44bb23..1b360e06658c 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> @@ -63,7 +63,6 @@ struct rcar_lvds {
> struct drm_bridge bridge;
>
> struct drm_bridge *next_bridge;
> - struct drm_connector connector;
> struct drm_panel *panel;
>
> void __iomem *mmio;
> @@ -80,73 +79,11 @@ struct rcar_lvds {
> #define bridge_to_rcar_lvds(b) \
> container_of(b, struct rcar_lvds, bridge)
>
> -#define connector_to_rcar_lvds(c) \
> - container_of(c, struct rcar_lvds, connector)
> -
> static void rcar_lvds_write(struct rcar_lvds *lvds, u32 reg, u32 data)
> {
> iowrite32(data, lvds->mmio + reg);
> }
>
> -/*
> -
> - * Connector & Panel
> - */
> -
> -static int rcar_lvds_connector_get_modes(struct drm_connector *connector)
> -{
> - struct rcar_lvds *lvds = connector_to_rcar_lvds(connector);
> -
> - return drm_panel_get_modes(lvds->panel, connector);
> -}
> -
> -static int rcar_lvds_connector_atomic_check(struct drm_connector *connector,
> - struct drm_atomic_state *state)
> -{
> - struct rcar_lvds *lvds = connector_to_rcar_lvds(connector);
> - const struct drm_display_mode *panel_mode;
> - struct drm_connector_state *conn_state;
> - struct drm_crtc_state *crtc_state;
> -
> - conn_state = drm_atomic_get_new_connector_state(state, connector);
> - if (!conn_state->crtc)
> - return 0;
> -
> - if (list_empty(&connector->modes)) {
> - dev_dbg(lvds->dev, "connector: empty modes list\n");
> - return -EINVAL;
> - }
> -
> - panel_mode = list_first_entry(&connector->modes,
> - struct drm_display_mode, head);
> -
> - /* We're not allowed to modify the resolution. */
> - crtc_state = drm_atomic_get_crtc_state(state, conn_state->crtc);
> - if (IS_ERR(crtc_state))
> - return PTR_ERR(crtc_state);
> -
> - if (crtc_state->mode.hdisplay != panel_mode->hdisplay ||
> - crtc_state->mode.vdisplay != panel_mode->vdisplay)
> - return -EINVAL;
> -
> - /* The flat panel mode is fixed, just copy it to the adjusted mode. */
> - drm_mode_copy(&crtc_state->adjusted_mode, panel_mode);
> -
> - return 0;
> -}
> -
> -static const struct drm_connector_helper_funcs rcar_lvds_conn_helper_funcs =
> {
> - .get_modes = rcar_lvds_connector_get_modes,
> - .atomic_check = rcar_lvds_connector_atomic_check,
> -};
> -
> -static const struct drm_connector_funcs rcar_lvds_conn_funcs = {
> - .reset = drm_atomic_helper_connector_reset,
> - .fill_modes = drm_helper_probe_single_connector_modes,
> - .destroy = drm_connector_cleanup,
> - .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
> - .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
> -};
> -
> /*
> -
> * PLL Setup
> */
> @@ -583,11 +520,6 @@ static void __rcar_lvds_atomic_enable(struct drm_bridge
> *bridge,
> /* Turn the output on. */
> lvdcr0 |= LVDCR0_LVRES;
> rcar_lvds_write(lvds, LVDCR0, lvdcr0);
> -
> - if (lvds->panel) {
> - drm_panel_prepare(lvds->panel);
> - drm_panel_enable(lvds->panel);
> - }
> }
>
> static void rcar_lvds_atomic_enable(struct drm_bridge *bridge,
> @@ -609,11 +541,6 @@ static void rcar_lvds_atomic_disable(struct drm_bridge
> *bridge,
> {
> struct rcar_lvds *lvds = bridge_to_rcar_lvds(bridge);
>
> - if (lvds->panel) {
> - drm_panel_disable(lvds->panel);
> - drm_panel_unprepare(lvds->panel);
> - }
> -
> rcar_lvds_write(lvds, LVDCR0, 0);
> rcar_lvds_write(lvds, LVDCR1, 0);
> rcar_lvds_write(lvds, LVDPLLCR, 0);
> @@ -648,45 +575,13 @@ static int rcar_lvds_attach(struct drm_bridge *bridge,
> enum drm_bridge_attach_flags flags)
> {
> struct rcar_lvds *lvds = bridge_to_rcar_lvds(bridge);
> - struct drm_connector *connector = &lvds->connector;
> - struct drm_encoder *encoder = bridge->encoder;
> - int ret;
>
> - /* If we have a next bridge just attach it. */
> - if (lvds->next_bridge)
> - return drm_bridge_attach(bridge->encoder, lvds->next_bridge,
> -
Re: [PATCH v2 4/4] drm: rcar-du: Use drm_bridge_connector_init() helper
Hi Laurent,
On Wed, Dec 16, 2020 at 02:50:21AM +0200, Laurent Pinchart wrote:
> Use the drm_bridge_connector_init() helper to create a drm_connector for
> each output, instead of relying on the bridge drivers doing so. Attach
> the bridges with the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag to instruct
> them not to create a connector.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 25 ++-
> 1 file changed, 20 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> index ba8c6038cd63..10a66091391a 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> @@ -11,6 +11,7 @@
> #include
>
> #include
> +#include
> #include
> #include
> #include
> @@ -61,6 +62,7 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
>struct device_node *enc_node)
> {
> struct rcar_du_encoder *renc;
> + struct drm_connector *connector;
> struct drm_bridge *bridge;
> int ret;
>
> @@ -122,9 +124,22 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
> if (ret)
> return ret;
>
> - /*
> - * Attach the bridge to the encoder. The bridge will create the
> - * connector.
> - */
> - return drm_bridge_attach(&renc->base, bridge, NULL, 0);
> + /* Attach the bridge to the encoder. */
> + ret = drm_bridge_attach(&renc->base, bridge, NULL,
> + DRM_BRIDGE_ATTACH_NO_CONNECTOR);
> + if (ret) {
> + dev_err(rcdu->dev, "failed to attach bridge for output %u\n",
> + output);
> + return ret;
> + }
> +
> + /* Create the connector for the chain of bridges. */
> + connector = drm_bridge_connector_init(&rcdu->ddev, &renc->base);
> + if (IS_ERR(connector)) {
> + dev_err(rcdu->dev,
> + "failed to created connector for output %u\n", output);
> + return PTR_ERR(connector);
> + }
> +
> + return drm_connector_attach_encoder(connector, &renc->base);
Looks good
Reviewed-by: Jacopo Mondi
I'm trying to figure out how deferred probe of a panel directly
connected to the lvds encoder work. I assume there's no risk of
creating the connector before the panel is probed, or this is not an
issue.
> }
> --
> Regards,
>
> Laurent Pinchart
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: rcar-du: fix reference leak in rcar_cmm_enable
Hello Qinglang,
On Fri, Nov 27, 2020 at 05:44:44PM +0800, Qinglang Miao wrote:
> pm_runtime_get_sync will increment pm usage counter even it
> failed. Forgetting to putting operation will result in a
> reference leak here.
>
> A new function pm_runtime_resume_and_get is introduced in
> [0] to keep usage counter balanced. So We fix the reference
> leak by replacing it with new funtion.
>
> [0] dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with
> usage counter")
I -think- you can break this line. Anyway, maintainers can fix when
applying if they feel to.
>
> Fixes: e08e934d6c28 ("drm: rcar-du: Add support for CMM")
> Reported-by: Hulk Robot
> Signed-off-by: Qinglang Miao
Seems fair!
Acked-by: Jacopo Mondi
Thanks
j
> ---
> drivers/gpu/drm/rcar-du/rcar_cmm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_cmm.c
> b/drivers/gpu/drm/rcar-du/rcar_cmm.c
> index c578095b0..382d53f8a 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_cmm.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_cmm.c
> @@ -122,7 +122,7 @@ int rcar_cmm_enable(struct platform_device *pdev)
> {
> int ret;
>
> - ret = pm_runtime_get_sync(&pdev->dev);
> + ret = pm_runtime_resume_and_get(&pdev->dev);
> if (ret < 0)
> return ret;
>
> --
> 2.23.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/9] drm: rcar-du: Use DRM-managed allocation for VSP planes
Hi Laurent,
On Mon, Dec 14, 2020 at 10:52:03PM +0200, Laurent Pinchart wrote:
> devm_kcalloc() is the wrong API to allocate planes, as the lifetime of
> the planes is tied to the DRM device, not the device to driver
> binding. drmm_kcalloc() isn't a good option either, as it would result
> in the planes being freed before being unregistered during the managed
> cleanup of the DRM objects. Use a plain kcalloc(), and cleanup the
> planes and free the memory in the existing rcar_du_vsp_cleanup()
> handler.
>
> Signed-off-by: Laurent Pinchart
> Reviewed-by: Kieran Bingham
Reviewed-by: Jacopo Mondi
Thanks
j
> ---
> drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 22 +-
> 1 file changed, 17 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> index 4dcb1bfbe201..78a886651d9f 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> @@ -21,6 +21,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include
> @@ -344,6 +345,15 @@ static const struct drm_plane_funcs
> rcar_du_vsp_plane_funcs = {
> static void rcar_du_vsp_cleanup(struct drm_device *dev, void *res)
> {
> struct rcar_du_vsp *vsp = res;
> + unsigned int i;
> +
> + for (i = 0; i < vsp->num_planes; ++i) {
> + struct rcar_du_vsp_plane *plane = &vsp->planes[i];
> +
> + drm_plane_cleanup(&plane->plane);
> + }
> +
> + kfree(vsp->planes);
>
> put_device(vsp->vsp);
> }
> @@ -354,6 +364,7 @@ int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct
> device_node *np,
> struct rcar_du_device *rcdu = vsp->dev;
> struct platform_device *pdev;
> unsigned int num_crtcs = hweight32(crtcs);
> + unsigned int num_planes;
> unsigned int i;
> int ret;
>
> @@ -376,14 +387,13 @@ int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct
> device_node *np,
> * The VSP2D (Gen3) has 5 RPFs, but the VSP1D (Gen2) is limited to
> * 4 RPFs.
> */
> - vsp->num_planes = rcdu->info->gen >= 3 ? 5 : 4;
> + num_planes = rcdu->info->gen >= 3 ? 5 : 4;
>
> - vsp->planes = devm_kcalloc(rcdu->dev, vsp->num_planes,
> -sizeof(*vsp->planes), GFP_KERNEL);
> + vsp->planes = kcalloc(num_planes, sizeof(*vsp->planes), GFP_KERNEL);
> if (!vsp->planes)
> return -ENOMEM;
>
> - for (i = 0; i < vsp->num_planes; ++i) {
> + for (i = 0; i < num_planes; ++i) {
> enum drm_plane_type type = i < num_crtcs
>? DRM_PLANE_TYPE_PRIMARY
>: DRM_PLANE_TYPE_OVERLAY;
> @@ -409,8 +419,10 @@ int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct
> device_node *np,
> } else {
> drm_plane_create_alpha_property(&plane->plane);
> drm_plane_create_zpos_property(&plane->plane, 1, 1,
> -vsp->num_planes - 1);
> +num_planes - 1);
> }
> +
> + vsp->num_planes++;
> }
>
> return 0;
> --
> Regards,
>
> Laurent Pinchart
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 5/9] drm: rcar-du: Use DRM-managed allocation for encoders
Hi Laurent,
On Mon, Dec 14, 2020 at 10:52:04PM +0200, Laurent Pinchart wrote:
> devm_kzalloc() is the wrong API to allocate encoders, as the lifetime of
> the encoders is tied to the DRM device, not the device to driver
> binding. drmm_kzalloc() isn't a good option either, as it would result
> in the encoder being freed before being unregistered during the managed
> cleanup of the DRM objects. Use a plain kzalloc(), and register a drmm
> action to cleanup the encoder.
>
> Signed-off-by: Laurent Pinchart
Reviewed-by: Jacopo Mondi
Thanks
j
> ---
> drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 47 ++-
> 1 file changed, 29 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> index e4bac47caf16..55a0ecf45ebb 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> @@ -8,12 +8,13 @@
> */
>
> #include
> +#include
>
> #include
> #include
> +#include
> #include
> #include
> -#include
>
> #include "rcar_du_drv.h"
> #include "rcar_du_encoder.h"
> @@ -44,6 +45,17 @@ static unsigned int rcar_du_encoder_count_ports(struct
> device_node *node)
> return num_ports;
> }
>
> +static const struct drm_encoder_funcs rcar_du_encoder_funcs = {
> +};
> +
> +static void rcar_du_encoder_release(struct drm_device *dev, void *res)
> +{
> + struct rcar_du_encoder *renc = res;
> +
> + drm_encoder_cleanup(&renc->base);
> + kfree(renc);
> +}
> +
> int rcar_du_encoder_init(struct rcar_du_device *rcdu,
>enum rcar_du_output output,
>struct device_node *enc_node)
> @@ -53,7 +65,7 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
> struct drm_bridge *bridge;
> int ret;
>
> - renc = devm_kzalloc(rcdu->dev, sizeof(*renc), GFP_KERNEL);
> + renc = kzalloc(sizeof(*renc), GFP_KERNEL);
> if (renc == NULL)
> return -ENOMEM;
>
> @@ -75,20 +87,20 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
>
> if (IS_ERR(panel)) {
> ret = PTR_ERR(panel);
> - goto done;
> + goto error;
> }
>
> bridge = devm_drm_panel_bridge_add_typed(rcdu->dev, panel,
>
> DRM_MODE_CONNECTOR_DPI);
> if (IS_ERR(bridge)) {
> ret = PTR_ERR(bridge);
> - goto done;
> + goto error;
> }
> } else {
> bridge = of_drm_find_bridge(enc_node);
> if (!bridge) {
> ret = -EPROBE_DEFER;
> - goto done;
> + goto error;
> }
>
> if (output == RCAR_DU_OUTPUT_LVDS0 ||
> @@ -103,28 +115,27 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
> if (rcdu->info->gen >= 3 && output == RCAR_DU_OUTPUT_LVDS1) {
> if (rcar_lvds_dual_link(bridge)) {
> ret = -ENOLINK;
> - goto done;
> + goto error;
> }
> }
>
> - ret = drm_simple_encoder_init(rcdu->ddev, encoder,
> - DRM_MODE_ENCODER_NONE);
> + ret = drm_encoder_init(rcdu->ddev, encoder, &rcar_du_encoder_funcs,
> +DRM_MODE_ENCODER_NONE, NULL);
> if (ret < 0)
> - goto done;
> + goto error;
> +
> + ret = drmm_add_action_or_reset(rcdu->ddev, rcar_du_encoder_release,
> +renc);
> + if (ret)
> + return ret;
>
> /*
>* Attach the bridge to the encoder. The bridge will create the
>* connector.
>*/
> - ret = drm_bridge_attach(encoder, bridge, NULL, 0);
> - if (ret) {
> - drm_encoder_cleanup(encoder);
> - return ret;
> - }
> -
> -done:
> - if (ret < 0)
> - devm_kfree(rcdu->dev, renc);
> + return drm_bridge_attach(encoder, bridge, NULL, 0);
>
> +error:
> + kfree(renc);
> return ret;
> }
> --
> Regards,
>
> Laurent Pinchart
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 9/9] drm: rcar-du: Drop local encoder variable
Hi Laurent,
On Sat, Dec 05, 2020 at 12:01:39AM +0200, Laurent Pinchart wrote:
> The local encoder variable is an alias for &renc->base, and is only use
> twice. It doesn't help much, drop it, along with the
> rcar_encoder_to_drm_encoder() macro that is then unused.
>
> Signed-off-by: Laurent Pinchart
Reviewed-by: Jacopo Mondi
Thanks
j
> ---
> drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 6 ++
> drivers/gpu/drm/rcar-du/rcar_du_encoder.h | 2 --
> 2 files changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> index 49c0b27e2f5a..9a565bd3380d 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> @@ -61,7 +61,6 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
>struct device_node *enc_node)
> {
> struct rcar_du_encoder *renc;
> - struct drm_encoder *encoder;
> struct drm_bridge *bridge;
> int ret;
>
> @@ -108,12 +107,11 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
>
> rcdu->encoders[output] = renc;
> renc->output = output;
> - encoder = rcar_encoder_to_drm_encoder(renc);
>
> dev_dbg(rcdu->dev, "initializing encoder %pOF for output %u\n",
> enc_node, output);
>
> - ret = drm_encoder_init(&rcdu->ddev, encoder, &rcar_du_encoder_funcs,
> + ret = drm_encoder_init(&rcdu->ddev, &renc->base, &rcar_du_encoder_funcs,
> DRM_MODE_ENCODER_NONE, NULL);
> if (ret < 0)
> goto error;
> @@ -127,7 +125,7 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
>* Attach the bridge to the encoder. The bridge will create the
>* connector.
>*/
> - return drm_bridge_attach(encoder, bridge, NULL, 0);
> + return drm_bridge_attach(&renc->base, bridge, NULL, 0);
>
> error:
> kfree(renc);
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
> b/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
> index df9be4524301..73560563fb31 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
> @@ -22,8 +22,6 @@ struct rcar_du_encoder {
> #define to_rcar_encoder(e) \
> container_of(e, struct rcar_du_encoder, base)
>
> -#define rcar_encoder_to_drm_encoder(e) (&(e)->base)
> -
> int rcar_du_encoder_init(struct rcar_du_device *rcdu,
>enum rcar_du_output output,
>struct device_node *enc_node);
> --
> Regards,
>
> Laurent Pinchart
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 8/9] drm: rcar-du: Skip encoder allocation for LVDS1 in dual-link mode
Hi Laurent,
On Sat, Dec 05, 2020 at 12:01:38AM +0200, Laurent Pinchart wrote:
> The rcar-du driver skips registration of the encoder for the LVDS1
> output when LVDS is used in dual-link mode, as the LVDS0 and LVDS1 links
> are bundled and handled through the LVDS0 output. It however still
> allocates the encoder and immediately destroys it, which is pointless.
> Skip allocation of the encoder altogether in that case.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 51 ++-
> 1 file changed, 22 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> index e4f35a88d00f..49c0b27e2f5a 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> @@ -65,17 +65,6 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
> struct drm_bridge *bridge;
> int ret;
>
> - renc = kzalloc(sizeof(*renc), GFP_KERNEL);
> - if (renc == NULL)
> - return -ENOMEM;
> -
> - rcdu->encoders[output] = renc;
> - renc->output = output;
> - encoder = rcar_encoder_to_drm_encoder(renc);
> -
> - dev_dbg(rcdu->dev, "initializing encoder %pOF for output %u\n",
> - enc_node, output);
> -
> /*
>* Locate the DRM bridge from the DT node. For the DPAD outputs, if the
>* DT node has a single port, assume that it describes a panel and
> @@ -86,23 +75,17 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
> rcar_du_encoder_count_ports(enc_node) == 1) {
> struct drm_panel *panel = of_drm_find_panel(enc_node);
>
> - if (IS_ERR(panel)) {
> - ret = PTR_ERR(panel);
> - goto error;
> - }
> + if (IS_ERR(panel))
> + return PTR_ERR(panel);
>
> bridge = devm_drm_panel_bridge_add_typed(rcdu->dev, panel,
>
> DRM_MODE_CONNECTOR_DPI);
> - if (IS_ERR(bridge)) {
> - ret = PTR_ERR(bridge);
> - goto error;
> - }
> + if (IS_ERR(bridge))
> + return PTR_ERR(bridge);
> } else {
> bridge = of_drm_find_bridge(enc_node);
> - if (!bridge) {
> - ret = -EPROBE_DEFER;
> - goto error;
> - }
> + if (!bridge)
> + return -EPROBE_DEFER;
>
> if (output == RCAR_DU_OUTPUT_LVDS0 ||
> output == RCAR_DU_OUTPUT_LVDS1)
> @@ -110,16 +93,26 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
> }
>
> /*
> - * On Gen3 skip the LVDS1 output if the LVDS1 encoder is used as a
> - * companion for LVDS0 in dual-link mode.
> + * Create and initialize the encoder. On Gen3 skip the LVDS1 output if
> + * the LVDS1 encoder is used as a companion for LVDS0 in dual-link
> + * mode.
Oh, here's the answer to my question on 1/9, I should have not looked
at DTS but to the driver
>*/
> if (rcdu->info->gen >= 3 && output == RCAR_DU_OUTPUT_LVDS1) {
> - if (rcar_lvds_dual_link(bridge)) {
> - ret = -ENOLINK;
> - goto error;
> - }
> + if (rcar_lvds_dual_link(bridge))
> + return -ENOLINK;
> }
>
> + renc = kzalloc(sizeof(*renc), GFP_KERNEL);
> + if (renc == NULL)
> + return -ENOMEM;
> +
> + rcdu->encoders[output] = renc;
> + renc->output = output;
> + encoder = rcar_encoder_to_drm_encoder(renc);
> +
> + dev_dbg(rcdu->dev, "initializing encoder %pOF for output %u\n",
> + enc_node, output);
> +
> ret = drm_encoder_init(&rcdu->ddev, encoder, &rcar_du_encoder_funcs,
> DRM_MODE_ENCODER_NONE, NULL);
> if (ret < 0)
Do you have any other caller of the 'done:' label left apart from the
one after this last line ? In case you don't you can call devm_kfree()
here
With or without this addressed:
Reviewed-by: Jacopo Mondi
> --
> Regards,
>
> Laurent Pinchart
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 7/9] drm: rcar-du: Replace dev_private with container_of
Hi Laurent,
On Sat, Dec 05, 2020 at 12:01:37AM +0200, Laurent Pinchart wrote:
> Now that drm_device is embedded in rcar_du_device, we can use
> container_of to get the rcar_du_device pointer from the drm_device,
> instead of using the drm_device.dev_private field.
>
> Signed-off-by: Laurent Pinchart
De gustibus non est disputandum
Reviewed-by: Jacopo Mondi
Thanks
j
> ---
> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 2 --
> drivers/gpu/drm/rcar-du/rcar_du_drv.h | 5 +
> drivers/gpu/drm/rcar-du/rcar_du_kms.c | 8
> drivers/gpu/drm/rcar-du/rcar_du_plane.c | 2 +-
> 4 files changed, 10 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> index 4ab99ac49891..d6a8b7899952 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> @@ -587,8 +587,6 @@ static int rcar_du_probe(struct platform_device *pdev)
> return PTR_ERR(rcdu->mmio);
>
> /* DRM/KMS objects */
> - rcdu->ddev.dev_private = rcdu;
> -
> ret = rcar_du_modeset_init(rcdu);
> if (ret < 0) {
> if (ret != -EPROBE_DEFER)
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> index e5b6f456357e..98d6bac3f2fa 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> @@ -102,6 +102,11 @@ struct rcar_du_device {
> unsigned int vspd1_sink;
> };
>
> +static inline struct rcar_du_device *to_rcar_du_device(struct drm_device
> *dev)
> +{
> + return container_of(dev, struct rcar_du_device, ddev);
> +}
> +
> static inline bool rcar_du_has(struct rcar_du_device *rcdu,
> unsigned int feature)
> {
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> index 57bb0dc22807..d6b71a9361ca 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> @@ -327,7 +327,7 @@ const struct rcar_du_format_info *rcar_du_format_info(u32
> fourcc)
> int rcar_du_dumb_create(struct drm_file *file, struct drm_device *dev,
> struct drm_mode_create_dumb *args)
> {
> - struct rcar_du_device *rcdu = dev->dev_private;
> + struct rcar_du_device *rcdu = to_rcar_du_device(dev);
> unsigned int min_pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
> unsigned int align;
>
> @@ -349,7 +349,7 @@ static struct drm_framebuffer *
> rcar_du_fb_create(struct drm_device *dev, struct drm_file *file_priv,
> const struct drm_mode_fb_cmd2 *mode_cmd)
> {
> - struct rcar_du_device *rcdu = dev->dev_private;
> + struct rcar_du_device *rcdu = to_rcar_du_device(dev);
> const struct rcar_du_format_info *format;
> unsigned int chroma_pitch;
> unsigned int max_pitch;
> @@ -421,7 +421,7 @@ rcar_du_fb_create(struct drm_device *dev, struct drm_file
> *file_priv,
> static int rcar_du_atomic_check(struct drm_device *dev,
> struct drm_atomic_state *state)
> {
> - struct rcar_du_device *rcdu = dev->dev_private;
> + struct rcar_du_device *rcdu = to_rcar_du_device(dev);
> int ret;
>
> ret = drm_atomic_helper_check(dev, state);
> @@ -437,7 +437,7 @@ static int rcar_du_atomic_check(struct drm_device *dev,
> static void rcar_du_atomic_commit_tail(struct drm_atomic_state *old_state)
> {
> struct drm_device *dev = old_state->dev;
> - struct rcar_du_device *rcdu = dev->dev_private;
> + struct rcar_du_device *rcdu = to_rcar_du_device(dev);
> struct drm_crtc_state *crtc_state;
> struct drm_crtc *crtc;
> unsigned int i;
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> index 5f69ff4502c1..02e5f11f38eb 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> @@ -128,7 +128,7 @@ static int rcar_du_plane_hwalloc(struct rcar_du_plane
> *plane,
> int rcar_du_atomic_check_planes(struct drm_device *dev,
> struct drm_atomic_state *state)
> {
> - struct rcar_du_device *rcdu = dev->dev_private;
> + struct rcar_du_device *rcdu = to_rcar_du_device(dev);
> unsigned int group_freed_planes[RCAR_DU_MAX_GROUPS] = { 0, };
> unsigned int group_free_planes[RCAR_DU_MAX_GROUPS] = { 0, };
> bool needs_realloc = false;
> --
> Regards,
>
> Laurent Pinchart
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/9] drm: rcar-du: Embed drm_device in rcar_du_device
Hi Laurent,
On Sat, Dec 05, 2020 at 12:01:36AM +0200, Laurent Pinchart wrote:
> Embedding drm_device in rcar_du_device allows usage of the DRM managed
> API to allocate both structures in one go, simplifying error handling.
>
> Signed-off-by: Laurent Pinchart
Looks good to me (re-sorting the headers rcar_du_drv without
mentioning it too).
Reviewed-by: Jacopo Mondi
> ---
> drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 2 +-
> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 33 +
> drivers/gpu/drm/rcar-du/rcar_du_drv.h | 5 ++--
> drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 4 +--
> drivers/gpu/drm/rcar-du/rcar_du_kms.c | 4 +--
> drivers/gpu/drm/rcar-du/rcar_du_plane.c | 6 ++--
> drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 6 ++--
> drivers/gpu/drm/rcar-du/rcar_du_writeback.c | 2 +-
> 8 files changed, 29 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> index e23b9c7b4afe..9a099c0fe1d4 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> @@ -1251,7 +1251,7 @@ int rcar_du_crtc_create(struct rcar_du_group *rgrp,
> unsigned int swindex,
> else
> primary = &rgrp->planes[swindex % 2].plane;
>
> - ret = drm_crtc_init_with_planes(rcdu->ddev, crtc, primary, NULL,
> + ret = drm_crtc_init_with_planes(&rcdu->ddev, crtc, primary, NULL,
> rcdu->info->gen <= 2 ?
> &crtc_funcs_gen2 : &crtc_funcs_gen3,
> NULL);
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> index 1490ec182646..4ab99ac49891 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> @@ -18,10 +18,11 @@
> #include
>
> #include
> +#include
> #include
> #include
> -#include
> #include
> +#include
> #include
>
> #include "rcar_du_drv.h"
> @@ -529,14 +530,14 @@ static int rcar_du_pm_suspend(struct device *dev)
> {
> struct rcar_du_device *rcdu = dev_get_drvdata(dev);
>
> - return drm_mode_config_helper_suspend(rcdu->ddev);
> + return drm_mode_config_helper_suspend(&rcdu->ddev);
> }
>
> static int rcar_du_pm_resume(struct device *dev)
> {
> struct rcar_du_device *rcdu = dev_get_drvdata(dev);
>
> - return drm_mode_config_helper_resume(rcdu->ddev);
> + return drm_mode_config_helper_resume(&rcdu->ddev);
> }
> #endif
>
> @@ -551,7 +552,7 @@ static const struct dev_pm_ops rcar_du_pm_ops = {
> static int rcar_du_remove(struct platform_device *pdev)
> {
> struct rcar_du_device *rcdu = platform_get_drvdata(pdev);
> - struct drm_device *ddev = rcdu->ddev;
> + struct drm_device *ddev = &rcdu->ddev;
>
> drm_dev_unregister(ddev);
>
> @@ -565,14 +566,14 @@ static int rcar_du_remove(struct platform_device *pdev)
> static int rcar_du_probe(struct platform_device *pdev)
> {
> struct rcar_du_device *rcdu;
> - struct drm_device *ddev;
> struct resource *mem;
> int ret;
>
> /* Allocate and initialize the R-Car device structure. */
> - rcdu = devm_kzalloc(&pdev->dev, sizeof(*rcdu), GFP_KERNEL);
> - if (rcdu == NULL)
> - return -ENOMEM;
> + rcdu = devm_drm_dev_alloc(&pdev->dev, &rcar_du_driver,
> + struct rcar_du_device, ddev);
> + if (IS_ERR(rcdu))
> + return PTR_ERR(rcdu);
>
> rcdu->dev = &pdev->dev;
> rcdu->info = of_device_get_match_data(rcdu->dev);
> @@ -586,12 +587,7 @@ static int rcar_du_probe(struct platform_device *pdev)
> return PTR_ERR(rcdu->mmio);
>
> /* DRM/KMS objects */
> - ddev = drm_dev_alloc(&rcar_du_driver, &pdev->dev);
> - if (IS_ERR(ddev))
> - return PTR_ERR(ddev);
> -
> - rcdu->ddev = ddev;
> - ddev->dev_private = rcdu;
> + rcdu->ddev.dev_private = rcdu;
>
> ret = rcar_du_modeset_init(rcdu);
> if (ret < 0) {
> @@ -601,25 +597,24 @@ static int rcar_du_probe(struct platform_device *pdev)
> goto error;
> }
>
> - ddev->irq_enabled = 1;
> + rcdu->ddev.irq_enabled = 1;
>
> /*
>* Register the DRM device with the core and the connectors with
>* sysfs.
>*/
> - ret = drm_dev_register(ddev, 0);
> + ret = drm_dev_register(&rcdu->ddev, 0);
>
Re: [PATCH 5/9] drm: rcar-du: Use DRM-managed allocation for encoders
Hi Laurent,
On Sat, Dec 05, 2020 at 12:01:35AM +0200, Laurent Pinchart wrote:
> devm_kzalloc() is the wrong API to allocate encoders, as the lifetime of
> the encoders is tied to the DRM device, not the device to driver
> binding. drmm_kzalloc() isn't a good option either, as it would result
> in the encoder being freed before being unregistered during the managed
> cleanup of the DRM objects. Use a plain kzalloc(), and register a drmm
> action to cleanup the encoder.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 47 ++-
> 1 file changed, 29 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> index 0edce24f2053..7c491ff72cd2 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> @@ -8,12 +8,13 @@
> */
>
> #include
> +#include
>
> #include
> #include
> +#include
> #include
> #include
> -#include
>
> #include "rcar_du_drv.h"
> #include "rcar_du_encoder.h"
> @@ -44,6 +45,17 @@ static unsigned int rcar_du_encoder_count_ports(struct
> device_node *node)
> return num_ports;
> }
>
> +static const struct drm_encoder_funcs rcar_du_encoder_funcs = {
> +};
> +
> +static void rcar_du_encoder_release(struct drm_device *dev, void *res)
> +{
> + struct rcar_du_encoder *renc = res;
> +
> + drm_encoder_cleanup(&renc->base);
> + kfree(renc);
> +}
> +
> int rcar_du_encoder_init(struct rcar_du_device *rcdu,
>enum rcar_du_output output,
>struct device_node *enc_node)
> @@ -53,7 +65,7 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
> struct drm_bridge *bridge;
> int ret;
>
> - renc = devm_kzalloc(rcdu->dev, sizeof(*renc), GFP_KERNEL);
> + renc = kzalloc(sizeof(*renc), GFP_KERNEL);
> if (renc == NULL)
> return -ENOMEM;
>
> @@ -76,20 +88,20 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
>
> if (IS_ERR(panel)) {
> ret = PTR_ERR(panel);
> - goto done;
> + goto error;
> }
>
> bridge = devm_drm_panel_bridge_add_typed(rcdu->dev, panel,
>
> DRM_MODE_CONNECTOR_DPI);
> if (IS_ERR(bridge)) {
> ret = PTR_ERR(bridge);
> - goto done;
> + goto error;
> }
> } else {
> bridge = of_drm_find_bridge(enc_node);
> if (!bridge) {
> ret = -EPROBE_DEFER;
> - goto done;
> + goto error;
> }
>
> if (output == RCAR_DU_OUTPUT_LVDS0 ||
> @@ -104,28 +116,27 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
> if (rcdu->info->gen >= 3 && output == RCAR_DU_OUTPUT_LVDS1) {
> if (rcar_lvds_dual_link(bridge)) {
> ret = -ENOLINK;
> - goto done;
> + goto error;
> }
> }
>
> - ret = drm_simple_encoder_init(rcdu->ddev, encoder,
> - DRM_MODE_ENCODER_NONE);
> + ret = drm_encoder_init(rcdu->ddev, encoder, &rcar_du_encoder_funcs,
> +DRM_MODE_ENCODER_NONE, NULL);
I might have missed the reason for this.
Why add an action later instead of making rcar_du_encoder_release part
of rcar_du_encoder_funcs ?
Thanks
j
> if (ret < 0)
> - goto done;
> + goto error;
> +
> + ret = drmm_add_action_or_reset(rcdu->ddev, rcar_du_encoder_release,
> +renc);
> + if (ret)
> + return ret;
>
> /*
>* Attach the bridge to the encoder. The bridge will create the
>* connector.
>*/
> - ret = drm_bridge_attach(encoder, bridge, NULL, 0);
> - if (ret) {
> - drm_encoder_cleanup(encoder);
> - return ret;
> - }
> -
> -done:
> - if (ret < 0)
> - devm_kfree(rcdu->dev, renc);
> + return drm_bridge_attach(encoder, bridge, NULL, 0);
>
> +error:
> + kfree(renc);
> return ret;
> }
> --
> Regards,
>
> Laurent Pinchart
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/9] drm: rcar-du: Drop unneeded encoder cleanup in error path
Hi Laurent,
On Sat, Dec 05, 2020 at 12:01:33AM +0200, Laurent Pinchart wrote:
> The encoder->name field can never be non-null in the error path, as that
> can only be possible after a successful call to
> drm_simple_encoder_init(). Drop the cleanup.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> index 2d40da98144b..0edce24f2053 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> @@ -124,11 +124,8 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
> }
>
> done:
> - if (ret < 0) {
> - if (encoder->name)
> - encoder->funcs->destroy(encoder);
This is probably worth a Fixes tag, as accessing encoder->func if
drm_simple_encoder_init() has not completed might lead to a NULL
pointer dereference.
Apart from this, patch looks good
Reviewed-by: Jacopo Mondi
Thanks
j
> + if (ret < 0)
> devm_kfree(rcdu->dev, renc);
> - }
>
> return ret;
> }
> --
> Regards,
>
> Laurent Pinchart
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/9] drm: rcar-du: Fix crash when using LVDS1 clock for CRTC
Hi Laurent,
On Sat, Dec 05, 2020 at 12:01:31AM +0200, Laurent Pinchart wrote:
> On D3 and E3 platforms, the LVDS encoder includes a PLL that can
> generate a clock for the corresponding CRTC, used even when the CRTC
> output to a non-LVDS port. This mechanism is supported by the driver,
> but the implementation is broken in dual-link LVDS mode. In that case,
> the LVDS1 drm_encoder is skipped, which causes a crash when trying to
> access its bridge later on.
Looking at a dts example with both lvds encoders and RGB output
enabled, I might have missed why the LVDS1 encoder is skipped.
>
> Fix this by storing bridge pointers internally instead of retrieving
> them from the encoder.
>
> Signed-off-by: Laurent Pinchart
The patch itself looks good!
Reviewed-by: Jacopo Mondi
Thanks
j
> ---
> drivers/gpu/drm/rcar-du/rcar_du_crtc.c| 10 ++
> drivers/gpu/drm/rcar-du/rcar_du_drv.h | 3 +++
> drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 4
> 3 files changed, 9 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> index b5fb941e0f53..e23b9c7b4afe 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> @@ -730,13 +730,10 @@ static void rcar_du_crtc_atomic_enable(struct drm_crtc
> *crtc,
>*/
> if (rcdu->info->lvds_clk_mask & BIT(rcrtc->index) &&
> rstate->outputs == BIT(RCAR_DU_OUTPUT_DPAD0)) {
> - struct rcar_du_encoder *encoder =
> - rcdu->encoders[RCAR_DU_OUTPUT_LVDS0 + rcrtc->index];
> + struct drm_bridge *bridge = rcdu->lvds[rcrtc->index];
> const struct drm_display_mode *mode =
> &crtc->state->adjusted_mode;
> - struct drm_bridge *bridge;
>
> - bridge = drm_bridge_chain_get_first_bridge(&encoder->base);
> rcar_lvds_clk_enable(bridge, mode->clock * 1000);
> }
>
> @@ -764,15 +761,12 @@ static void rcar_du_crtc_atomic_disable(struct drm_crtc
> *crtc,
>
> if (rcdu->info->lvds_clk_mask & BIT(rcrtc->index) &&
> rstate->outputs == BIT(RCAR_DU_OUTPUT_DPAD0)) {
> - struct rcar_du_encoder *encoder =
> - rcdu->encoders[RCAR_DU_OUTPUT_LVDS0 + rcrtc->index];
> - struct drm_bridge *bridge;
> + struct drm_bridge *bridge = rcdu->lvds[rcrtc->index];
>
> /*
>* Disable the LVDS clock output, see
>* rcar_du_crtc_atomic_enable().
>*/
> - bridge = drm_bridge_chain_get_first_bridge(&encoder->base);
> rcar_lvds_clk_disable(bridge);
> }
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> index 61504c54e2ec..71732fc5df8f 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> @@ -20,6 +20,7 @@
>
> struct clk;
> struct device;
> +struct drm_bridge;
> struct drm_device;
> struct drm_property;
> struct rcar_du_device;
> @@ -71,6 +72,7 @@ struct rcar_du_device_info {
> #define RCAR_DU_MAX_CRTCS4
> #define RCAR_DU_MAX_GROUPS DIV_ROUND_UP(RCAR_DU_MAX_CRTCS, 2)
> #define RCAR_DU_MAX_VSPS 4
> +#define RCAR_DU_MAX_LVDS 2
>
> struct rcar_du_device {
> struct device *dev;
> @@ -88,6 +90,7 @@ struct rcar_du_device {
> struct rcar_du_group groups[RCAR_DU_MAX_GROUPS];
> struct platform_device *cmms[RCAR_DU_MAX_CRTCS];
> struct rcar_du_vsp vsps[RCAR_DU_MAX_VSPS];
> + struct drm_bridge *lvds[RCAR_DU_MAX_LVDS];
>
> struct {
> struct drm_property *colorkey;
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> index b0335da0c161..2d40da98144b 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> @@ -91,6 +91,10 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
> ret = -EPROBE_DEFER;
> goto done;
> }
> +
> + if (output == RCAR_DU_OUTPUT_LVDS0 ||
> + output == RCAR_DU_OUTPUT_LVDS1)
> + rcdu->lvds[output - RCAR_DU_OUTPUT_LVDS0] = bridge;
> }
>
> /*
> --
> Regards,
>
> Laurent Pinchart
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/9] drm: rcar-du: Release vsp device reference in all error paths
Hi Laurent, On Sat, Dec 05, 2020 at 12:01:32AM +0200, Laurent Pinchart wrote: > Use drmm_add_action_or_reset() instead of drmm_add_action() to ensure > the vsp device reference is released in case the function call fails. > > Signed-off-by: Laurent Pinchart Just in case... better safe than sorry Reviewed-by: Jacopo Mondi > --- > 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 f6a69aa116e6..4dcb1bfbe201 100644 > --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c > +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c > @@ -364,7 +364,7 @@ int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct > device_node *np, > > vsp->vsp = &pdev->dev; > > - ret = drmm_add_action(rcdu->ddev, rcar_du_vsp_cleanup, vsp); > + ret = drmm_add_action_or_reset(rcdu->ddev, rcar_du_vsp_cleanup, vsp); > if (ret < 0) > return ret; > > -- > Regards, > > Laurent Pinchart > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 0/8] drm: rcar-du: Add Color Management Module (CMM)
Hello Eugeniu, On Mon, Jun 15, 2020 at 04:17:23PM +0200, Eugeniu Rosca wrote: > Hi Jacopo, > > On Fri, Jun 12, 2020 at 05:12:09PM +0200, Jacopo Mondi wrote: > > On Mon, Jun 08, 2020 at 11:44:32AM +0200, Eugeniu Rosca wrote: > > > FWIW, I seem to hit pre-existing issues in vanilla rcar-du, > > > while unplugging HDMI cable during a cyclic suspend-resume: > > > > > > HW: H3 ES2.0 Salvator-X > > > SW: renesas-drivers-2020-06-02-v5.7 > > > .config: renesas_defconfig +CONFIG_PM_DEBUG +CONFIG_PM_ADVANCED_DEBUG > > > Use-case: > > > > > > 8<- > > > $ cat s2ram.sh > > > modprobe i2c-dev > > > echo 9 > /proc/sys/kernel/printk > > > i2cset -f -y 7 0x30 0x20 0x0F > > > > According to > > https://elinux.org/R-Car/Boards/Salvator-X#Suspend-to-RAM > > this is not needed anymore > > Good to know. Thanks for the useful remark. > > > > echo 0 > /sys/module/suspend/parameters/pm_test_delay > > > echo core > /sys/power/pm_test > > > echo deep > /sys/power/mem_sleep > > > echo 1 > /sys/power/pm_debug_messages > > > echo 0 > /sys/power/pm_print_times > > > echo mem > /sys/power/state > > > > > > $ while true; do sh s2ram.sh ; done > > > $ # unplug HDMI cable several times > > > > I tried unplugging an plugging the cable while the system was > > suspended and after resume but I was not able to reproduce anything. > > Your comment sounds like you suspended the system once and resumed it > afterwards, while my description mentions "cyclic" :), meaning: > > $ while true; do sh s2ram.sh; done > $ # connect-disconnect the hdmi display a couple of times > $ # NOTE: to avoid this manual step, I am thinking of a USB-controlled > HDMI switcher long-term > > > > > Could you provide more precise instructions on how to reproduce this ? > > I.e. when to disconnect the cable to trigger the below error. > > See above :) > > BTW, using renesas-drivers-2020-06-02-v5.7 as base and performing the > use-case just described, I got today (with minimal effort): > > [ 459.321733] Enabling non-boot CPUs ... > [ 459.331132] Detected PIPT I-cache on CPU1 > [ 459.331189] CPU1: Booted secondary processor 0x01 [0x411fd073] > [ 459.332312] CPU1 is up > [ 459.345635] Detected PIPT I-cache on CPU2 > [ 459.345671] CPU2: Booted secondary processor 0x02 [0x411fd073] > [ 459.346624] CPU2 is up > [ 459.359912] Detected PIPT I-cache on CPU3 > [ 459.359942] CPU3: Booted secondary processor 0x03 [0x411fd073] > [ 459.360918] CPU3 is up > [ 459.374183] Detected VIPT I-cache on CPU4 > [ 459.374252] CPU4: Booted secondary processor 0x000100 [0x410fd034] > [ 459.375875] cpufreq: cpufreq_online: CPU4: Running at unlisted freq: > 119 KHz > [ 459.394204] cpufreq: cpufreq_online: CPU4: Unlisted initial frequency > changed to: 120 KHz > [ 459.403879] CPU4 is up > [ 459.406469] Detected VIPT I-cache on CPU5 > [ 459.406519] CPU5: Booted secondary processor 0x000101 [0x410fd034] > [ 459.408520] CPU5 is up > [ 459.421762] Detected VIPT I-cache on CPU6 > [ 459.421810] CPU6: Booted secondary processor 0x000102 [0x410fd034] > [ 459.423831] CPU6 is up > [ 459.437114] Detected VIPT I-cache on CPU7 > [ 459.437164] CPU7: Booted secondary processor 0x000103 [0x410fd034] > [ 459.439258] CPU7 is up > [ 459.456217] PM: noirq resume of devices complete after 3.878 msecs > [ 459.471529] PM: early resume of devices complete after 8.590 msecs > [ 469.726906] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* > [CRTC:76:crtc-3] flip_done timed out I've been able to reproduce this same issue, but I see that errors in drm_atomic_helper_wait_for_dependencies always follow a first failure in drm_atomic_helper_wait_for_flip_done Looking at the log what I see is that [ 160.488762] PM: late suspend of devices complete after 10.509 msecs [ 171.235584] [drm:drm_atomic_helper_wait_for_flip_done] *ERROR* [CRTC:75:crtc-1] flip_done timed out The 10 second elapsed there matches the timout in drm_atomic_helper_wait_for_flip_done and it seems the issue is related to the first atomic commit after resume not being able to succesfully receive a flip_done event, possibly as the HDMI connector has been disconnected while the system was suspending or suspended and the DRM state was not updated. Can you confirm you see the same failure sequence ? Thanks j ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 0/8] drm: rcar-du: Add Color Management Module (CMM)
Hi Eugeniu,
On Tue, Jun 09, 2020 at 04:29:59PM +0200, Eugeniu Rosca wrote:
> Hi Laurent,
>
> On Sun, Jun 07, 2020 at 05:41:58AM +0300, Laurent Pinchart wrote:
> > Note that the CMM driver is controlled by the DU driver. As the DU
> > driver will reenable the display during resume, it will call
> > rcar_du_cmm_setup() at resume time, which will reprogram the CMM. There
> > should thus be no need for manual suspend/resume handling in the CMM as
> > far as I can tell, but we need to ensure that the CMM is suspended
> > before and resumed after the DU. I believe this could be implemented
> > using device links.
>
> Based on below quote [*] from Jacopo's commit [**], isn't the device
> link relationship already in place?
Yes, it's in place already.
I added pm_ops to cmm just to be able to printout when suspend/resume
happens and the sequence is what comment [*] reports
[ 222.909002] rcar_du_pm_suspend:505
[ 223.145497] rcar_cmm_pm_suspend:193
[ 223.208053] rcar_cmm_pm_resume:200
[ 223.460094] rcar_du_pm_resume:513
However, Laurent mentioned that in his comment here that he expects
the opposite sequence to happen (CMM to suspend before and resume after
DU).
I still think what is implemented is correct:
- CMM is suspended after DU: when CMM is suspended, DU is not feeding
it with data
- CMM is resumed before: once DU restart operations CMM is ready to
receive data.
Laurent, what do you think ?
Thanks
j
>
> [*] Quote from commit [**]
>Enforce the probe and suspend/resume ordering of DU and CMM by
>creating a stateless device link between the two.
>
> [**]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8de707aeb45241
> ("drm: rcar-du: kms: Initialize CMM instances")
>
> --
> Best regards,
> Eugeniu Rosca
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 0/8] drm: rcar-du: Add Color Management Module (CMM)
Hi Eugeniu On Mon, Jun 08, 2020 at 11:44:32AM +0200, Eugeniu Rosca wrote: > Hello, > > Many thanks for your comments and involvement. > > On Sun, Jun 07, 2020 at 05:41:58AM +0300, Laurent Pinchart wrote: > > On Fri, Jun 05, 2020 at 03:53:15PM +0200, Jacopo Mondi wrote: > > > On Fri, Jun 05, 2020 at 03:41:24PM +0200, Eugeniu Rosca wrote: > > > > On Fri, Jun 05, 2020 at 03:29:00PM +0200, Jacopo Mondi wrote: > > > >> On Wed, May 27, 2020 at 09:15:55AM +0200, Eugeniu Rosca wrote: > > > >>> Could you kindly share the cross compilation steps for your kmsxx > > > >>> fork? > > > >> > > > >> I usually build it on the target :) > > > > > > > > Interesting approach. With ARM getting more and more potent, why not? :) > > > > > > For 'small' utilities like kmsxx it's doable > > > > > > >>> Just out of curiosity, have you ever tried to pull the display's HDMI > > > >>> cable while reading from CM2_LUT_TBL? > > > >> > > > >> Ahem, not really :) Did I get you right, you mean disconnecting the > > > >> HDMI cable from the board ? > > > > > > > > Right. > > > > > > So, no, I have not tried. Do you see any intersting failure with the > > > mainline version ? > > > > Jacopo, would you be able to give this a try ? > > FWIW, I seem to hit pre-existing issues in vanilla rcar-du, > while unplugging HDMI cable during a cyclic suspend-resume: > > HW: H3 ES2.0 Salvator-X > SW: renesas-drivers-2020-06-02-v5.7 > .config: renesas_defconfig +CONFIG_PM_DEBUG +CONFIG_PM_ADVANCED_DEBUG > Use-case: > > 8<- > $ cat s2ram.sh > modprobe i2c-dev > echo 9 > /proc/sys/kernel/printk > i2cset -f -y 7 0x30 0x20 0x0F According to https://elinux.org/R-Car/Boards/Salvator-X#Suspend-to-RAM this is not needed anymore > echo 0 > /sys/module/suspend/parameters/pm_test_delay > echo core > /sys/power/pm_test > echo deep > /sys/power/mem_sleep > echo 1 > /sys/power/pm_debug_messages > echo 0 > /sys/power/pm_print_times > echo mem > /sys/power/state > > $ while true; do sh s2ram.sh ; done > $ # unplug HDMI cable several times I tried unplugging an plugging the cable while the system was suspended and after resume but I was not able to reproduce anything. Could you provide more precise instructions on how to reproduce this ? I.e. when to disconnect the cable to trigger the below error. Thanks j > > [ 55.568051] PM: noirq resume of devices complete after 3.862 msecs > [ 55.583253] PM: early resume of devices complete after 8.496 msecs > [ 65.757023] [drm:drm_atomic_helper_wait_for_flip_done] *ERROR* > [CRTC:74:crtc-1] flip_done timed out > [ 75.996123] [drm:drm_atomic_helper_wait_for_flip_done] *ERROR* > [CRTC:74:crtc-1] flip_done timed out > [ 86.236112] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* > [CRTC:74:crtc-1] flip_done timed out > [ 96.476111] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* > [CONNECTOR:80:HDMI-A-1] flip_done timed out > [ 106.716109] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* > [PLANE:45:plane-5] flip_done timed out > [ 116.956111] [drm:drm_atomic_helper_wait_for_flip_done] *ERROR* > [CRTC:74:crtc-1] flip_done timed out > [ 127.196112] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* > [CRTC:74:crtc-1] flip_done timed out > [ 137.436116] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* > [CONNECTOR:80:HDMI-A-1] flip_done timed out > [ 147.676111] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* > [PLANE:45:plane-5] flip_done timed out > [ 157.916110] [drm:drm_atomic_helper_wait_for_flip_done] *ERROR* > [CRTC:74:crtc-1] flip_done timed out > 8<- > > This looks to be unrelated to the CMM lockup I initially reported. > > JYI, graphics pipelines in production R-Car3 targets are significantly > more complex (involving binding/unbinding serializer ICs at runtime > during non-trivial shutdown/suspend/resume sequences), as opposed > to the relatively straightforward VGA/HDMI outputs present on the > reference targets. So, my hope is that Renesas community can take > HDMI hot plugging seriously and make it a regular test-case during > rcar-du patch review, since this is a precondition for the R-Car3 > platform and products to succeed as a whole. > > BTW, if you happen to know an affordable programmable HDMI switcher > which can do the hot-plugging job in an automated test environment, > please let me know. > > > > > > >>> At least with the out-of-tree CMM implem
Re: [PATCH v5 0/8] drm: rcar-du: Add Color Management Module (CMM)
Hi Eugeniu On Fri, Jun 05, 2020 at 03:41:24PM +0200, Eugeniu Rosca wrote: > Hi Jacopo, > > On Fri, Jun 05, 2020 at 03:29:00PM +0200, Jacopo Mondi wrote: > > On Wed, May 27, 2020 at 09:15:55AM +0200, Eugeniu Rosca wrote: > > > Could you kindly share the cross compilation steps for your kmsxx fork? > > > > I usually build it on the target :) > > Interesting approach. With ARM getting more and more potent, why not? :) > For 'small' utilities like kmsxx it's doable > > > > > Just out of curiosity, have you ever tried to pull the display's HDMI > > > cable while reading from CM2_LUT_TBL? > > > > Ahem, not really :) Did I get you right, you mean disconnecting the > > HDMI cable from the board ? > > Right. > So, no, I have not tried. Do you see any intersting failure with the mainline version ? > > > > > > At least with the out-of-tree CMM implementation [*], this sends the > > > R-Car3 reference targets into an unrecoverable freeze, with no lockup > > > reported by the kernel (i.e. looks like an serious HW issue). > > > > > > > > > > > CMM functionalities are retained between suspend/resume cycles (tested > > > > with > > > > suspend-to-idle) without requiring a re-programming of the LUT tables. > > > > > > Hmm. Is this backed up by any statement in the HW User's manual? > > > This comes in contrast with the original Renesas CMM implementation [**] > > > which does make use of suspend (where the freeze actually happens). > > > > > > Can we infer, based on your statement, that we could also get rid of > > > the suspend callback in [**]? > > > > As Geert (thanks) explained what I've tested with is suspend-to-idle, > > which retains the state of the LUT tables (and I assume other > > not-yet-implemented CMM features, like CLU). I recall the out-of-tree > > driver has suspend/resume routines but I never really tested that. > > I see. JFYI, there is a flaw in the suspend handling in the out-of-tree > CMM patch [*], which renders the SoC unresponsive on HDMI hotplug. The > fix is currently under review. Hopefully it will make its way to [*] > in the nearest future. Just to keep in mind for the moment when CMM > s2ram will become a mainline feature. Thanks, let's keep this in mind. Next week I'll run a few tests again with s2ram and will get back to you. Thanks j > > > > > > > [*] https://github.com/renesas-rcar/du_cmm > > > [**] > > > https://github.com/renesas-rcar/du_cmm/blob/c393ed49834bdbc/meta-rcar-gen3/recipes-kernel/linux/linux-renesas/0001-drm-rcar-du-Add-DU-CMM-support.patch#L1912 > > -- > Best regards, > Eugeniu Rosca ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 0/8] drm: rcar-du: Add Color Management Module (CMM)
Hello Eugeniu, sorry for the late reply On Wed, May 27, 2020 at 09:15:55AM +0200, Eugeniu Rosca wrote: > Hi Jacopo, > > On Tue, Oct 15, 2019 at 12:46:13PM +0200, Jacopo Mondi wrote: > 8<--- > > > * Testing > > I have tested by injecting a color inversion LUT table and > > enabling/disabling it > > every 50 displayed frames: > > https://jmondi.org/cgit/kmsxx/log/?h=gamma_lut > > Could you kindly share the cross compilation steps for your kmsxx fork? > I usually build it on the target :) > Just out of curiosity, have you ever tried to pull the display's HDMI > cable while reading from CM2_LUT_TBL? Ahem, not really :) Did I get you right, you mean disconnecting the HDMI cable from the board ? > > At least with the out-of-tree CMM implementation [*], this sends the > R-Car3 reference targets into an unrecoverable freeze, with no lockup > reported by the kernel (i.e. looks like an serious HW issue). > > > > > CMM functionalities are retained between suspend/resume cycles (tested with > > suspend-to-idle) without requiring a re-programming of the LUT tables. > > Hmm. Is this backed up by any statement in the HW User's manual? > This comes in contrast with the original Renesas CMM implementation [**] > which does make use of suspend (where the freeze actually happens). > > Can we infer, based on your statement, that we could also get rid of > the suspend callback in [**]? As Geert (thanks) explained what I've tested with is suspend-to-idle, which retains the state of the LUT tables (and I assume other not-yet-implemented CMM features, like CLU). I recall the out-of-tree driver has suspend/resume routines but I never really tested that. Thanks j > > [*] https://github.com/renesas-rcar/du_cmm > [**] > https://github.com/renesas-rcar/du_cmm/blob/c393ed49834bdbc/meta-rcar-gen3/recipes-kernel/linux/linux-renesas/0001-drm-rcar-du-Add-DU-CMM-support.patch#L1912 > > -- > Best regards, > Eugeniu Rosca ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/4] dt-bindings: display: bridge: thc63lvd1024: Document dual-output mode
Hi Laurent, On Thu, May 14, 2020 at 02:21:27AM +0300, Laurent Pinchart wrote: > The DT binding support both dual-input and dual-output mode, but only > dual-input is documented. Document dual-output mode. > > Suggested-by: Jacopo Mondi > Signed-off-by: Laurent Pinchart Thanks Acked-by: Jacopo Mondi > --- > .../display/bridge/thine,thc63lvd1024.yaml | 16 +++- > 1 file changed, 11 insertions(+), 5 deletions(-) > > diff --git > a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.yaml > b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.yaml > index 469ac4a34273..fedd3460d6f6 100644 > --- a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.yaml > +++ b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.yaml > @@ -30,11 +30,17 @@ properties: >This device has four video ports. Their connections are modeled using > the >OF graph bindings specified in > Documentation/devicetree/bindings/graph.txt. > > - The device can operate in single-link mode or dual-link mode. In > - single-link mode, all pixels are received on port@0, and port@1 shall > not > - contain any endpoint. In dual-link mode, even-numbered pixels are > - received on port@0 and odd-numbered pixels on port@1, and both port@0 > and > - port@1 shall contain endpoints. > + The device can operate in single or dual input and output modes. > + > + When operating in single input mode, all pixels are received on port@0, > + and port@1 shall not contain any endpoint. In dual input mode, > + even-numbered pixels are received on port@0 and odd-numbered pixels on > + port@1, and both port@0 and port@1 shall contain endpoints. > + > + When operating in single output mode all pixels are output from the > first > + CMOS/TTL port and port@3 shall not contain any endpoint. In dual output > + mode pixels are output from both CMOS/TTL ports and both port@2 and > + port@3 shall contain endpoints. > > properties: >'#address-cells': > -- > Regards, > > Laurent Pinchart > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] drm/rcar-du: Fix return value check in rcar_du_cmm_init()
Hello Wei,
On Tue, Apr 28, 2020 at 02:17:16PM +, Wei Yongjun wrote:
> In case of error, the function of_parse_phandle()/of_find_device_by_node()
> returns NULL pointer not ERR_PTR(). The IS_ERR() test in the return value
> check should be replaced with NULL test
>
> Fixes: 8de707aeb452 ("drm: rcar-du: kms: Initialize CMM instances")
> Signed-off-by: Wei Yongjun
Correct indeed! Also -ENODEV seems appropriate to me as return value.
Thanks!
Acked-by: Jacopo Mondi
> ---
> drivers/gpu/drm/rcar-du/rcar_du_kms.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> index 482329102f19..0da711d9b2f8 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> @@ -650,10 +650,10 @@ static int rcar_du_cmm_init(struct rcar_du_device *rcdu)
> int ret;
>
> cmm = of_parse_phandle(np, "renesas,cmms", i);
> - if (IS_ERR(cmm)) {
> + if (!cmm) {
> dev_err(rcdu->dev,
> "Failed to parse 'renesas,cmms' property\n");
> - return PTR_ERR(cmm);
> + return -ENODEV;
> }
>
> if (!of_device_is_available(cmm)) {
> @@ -663,10 +663,10 @@ static int rcar_du_cmm_init(struct rcar_du_device *rcdu)
> }
>
> pdev = of_find_device_by_node(cmm);
> - if (IS_ERR(pdev)) {
> + if (!pdev) {
> dev_err(rcdu->dev, "No device found for CMM%u\n", i);
> of_node_put(cmm);
> - return PTR_ERR(pdev);
> + return -ENODEV;
> }
>
> of_node_put(cmm);
>
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] dt-bindings: display: bridge: thc63lvd1024: Convert binding to YAML
Hi Laurent,
On Mon, Apr 06, 2020 at 02:23:17AM +0300, Laurent Pinchart wrote:
> Convert the Thine THC63LVD1024 text binding to YAML.
>
> Signed-off-by: Laurent Pinchart
> ---
> .../display/bridge/thine,thc63lvd1024.txt | 66 --
> .../display/bridge/thine,thc63lvd1024.yaml| 121 ++
> 2 files changed, 121 insertions(+), 66 deletions(-)
> delete mode 100644
> Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> deleted file mode 100644
> index d17d1e5820d7..
> --- a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> +++ /dev/null
> @@ -1,66 +0,0 @@
> -Thine Electronics THC63LVD1024 LVDS decoder
>
> -
> -The THC63LVD1024 is a dual link LVDS receiver designed to convert LVDS
> streams
> -to parallel data outputs. The chip supports single/dual input/output modes,
> -handling up to two LVDS input streams and up to two digital CMOS/TTL outputs.
> -
> -Single or dual operation mode, output data mapping and DDR output modes are
> -configured through input signals and the chip does not expose any control
> bus.
> -
> -Required properties:
> -- compatible: Shall be "thine,thc63lvd1024"
> -- vcc-supply: Power supply for TTL output, TTL CLOCKOUT signal, LVDS input,
> - PPL and digital circuitry
> -
> -Optional properties:
> -- powerdown-gpios: Power down GPIO signal, pin name "/PDWN". Active low
> -- oe-gpios: Output enable GPIO signal, pin name "OE". Active high
> -
> -The THC63LVD1024 video port connections are modeled according
> -to OF graph bindings specified by Documentation/devicetree/bindings/graph.txt
> -
> -Required video port nodes:
> -- port@0: First LVDS input port
> -- port@2: First digital CMOS/TTL parallel output
> -
> -Optional video port nodes:
> -- port@1: Second LVDS input port
> -- port@3: Second digital CMOS/TTL parallel output
> -
> -The device can operate in single-link mode or dual-link mode. In single-link
> -mode, all pixels are received on port@0, and port@1 shall not contain any
> -endpoint. In dual-link mode, even-numbered pixels are received on port@0 and
> -odd-numbered pixels on port@1, and both port@0 and port@1 shall contain
> -endpoints.
> -
> -Example:
> -
> -
> - thc63lvd1024: lvds-decoder {
> - compatible = "thine,thc63lvd1024";
> -
> - vcc-supply = <®_lvds_vcc>;
> - powerdown-gpios = <&gpio4 15 GPIO_ACTIVE_LOW>;
> -
> - ports {
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - port@0 {
> - reg = <0>;
> -
> - lvds_dec_in_0: endpoint {
> - remote-endpoint = <&lvds_out>;
> - };
> - };
> -
> - port@2{
> - reg = <2>;
> -
> - lvds_dec_out_2: endpoint {
> - remote-endpoint = <&adv7511_in>;
> - };
> - };
> - };
> - };
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.yaml
> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.yaml
> new file mode 100644
> index ..469ac4a34273
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.yaml
> @@ -0,0 +1,121 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/thine,thc63lvd1024.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Thine Electronics THC63LVD1024 LVDS Decoder
> +
> +maintainers:
> + - Jacopo Mondi
Ack
> + - Laurent Pinchart
> +
> +description: |
> + The THC63LVD1024 is a dual link LVDS receiver designed to convert LVDS
> + streams to parallel data outputs. The chip supports single/dual
> input/output
> + modes, handling up to two LVDS input streams and up to two digital CMOS/TTL
> + outputs.
> +
> + Single or dual operation mode, output data mapping and DDR output modes are
> + configured through input signals and the chip does no
[PATCH v7 3/7] drm: rcar-du: Add support for CMM
Add a driver for the R-Car Display Unit Color Correction Module.
In most of Gen3 SoCs, each DU output channel is provided with a CMM unit
to perform image enhancement and color correction.
Add support for CMM through a driver that supports configuration of
the 1-dimensional LUT table. More advanced CMM features will be
implemented on top of this initial one.
Reviewed-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
Signed-off-by: Jacopo Mondi
---
v6 -> v7
- Expand rcar_cmm_setup() function documentation to detail its relationship
with rcar_cmm_enable() and their call order precedence.
- Kconfig update: Make DRM_RCAR_CMM a tristate option and 'imply' it from the
RCAR_DU one. This guarantees that if DU is built as a module CMM can only be
built as a module as well. At the same time, if DU is built-in, CMM can
be built-in only.
---
drivers/gpu/drm/rcar-du/Kconfig| 8 ++
drivers/gpu/drm/rcar-du/Makefile | 1 +
drivers/gpu/drm/rcar-du/rcar_cmm.c | 217 +
drivers/gpu/drm/rcar-du/rcar_cmm.h | 58
4 files changed, 284 insertions(+)
create mode 100644 drivers/gpu/drm/rcar-du/rcar_cmm.c
create mode 100644 drivers/gpu/drm/rcar-du/rcar_cmm.h
diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
index 1529849e217e..6ed7a4f3c44e 100644
--- a/drivers/gpu/drm/rcar-du/Kconfig
+++ b/drivers/gpu/drm/rcar-du/Kconfig
@@ -5,6 +5,7 @@ config DRM_RCAR_DU
depends on ARM || ARM64
depends on ARCH_RENESAS || COMPILE_TEST
imply DRM_RCAR_LVDS
+ imply DRM_RCAR_CMM
select DRM_KMS_HELPER
select DRM_KMS_CMA_HELPER
select DRM_GEM_CMA_HELPER
@@ -13,6 +14,13 @@ config DRM_RCAR_DU
Choose this option if you have an R-Car chipset.
If M is selected the module will be called rcar-du-drm.
+config DRM_RCAR_CMM
+ tristate "R-Car DU Color Management Module (CMM) Support"
+ depends on DRM && OF
+ depends on DRM_RCAR_DU
+ help
+ Enable support for R-Car Color Management Module (CMM).
+
config DRM_RCAR_DW_HDMI
tristate "R-Car DU Gen3 HDMI Encoder Support"
depends on DRM && OF
diff --git a/drivers/gpu/drm/rcar-du/Makefile b/drivers/gpu/drm/rcar-du/Makefile
index 6c2ed9c46467..4d1187ccc3e5 100644
--- a/drivers/gpu/drm/rcar-du/Makefile
+++ b/drivers/gpu/drm/rcar-du/Makefile
@@ -15,6 +15,7 @@ rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS) += rcar_du_of.o \
rcar-du-drm-$(CONFIG_DRM_RCAR_VSP) += rcar_du_vsp.o
rcar-du-drm-$(CONFIG_DRM_RCAR_WRITEBACK) += rcar_du_writeback.o
+obj-$(CONFIG_DRM_RCAR_CMM) += rcar_cmm.o
obj-$(CONFIG_DRM_RCAR_DU) += rcar-du-drm.o
obj-$(CONFIG_DRM_RCAR_DW_HDMI) += rcar_dw_hdmi.o
obj-$(CONFIG_DRM_RCAR_LVDS)+= rcar_lvds.o
diff --git a/drivers/gpu/drm/rcar-du/rcar_cmm.c
b/drivers/gpu/drm/rcar-du/rcar_cmm.c
new file mode 100644
index ..c578095b09a5
--- /dev/null
+++ b/drivers/gpu/drm/rcar-du/rcar_cmm.c
@@ -0,0 +1,217 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * rcar_cmm.c -- R-Car Display Unit Color Management Module
+ *
+ * Copyright (C) 2019 Jacopo Mondi
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "rcar_cmm.h"
+
+#define CM2_LUT_CTRL 0x
+#define CM2_LUT_CTRL_LUT_ENBIT(0)
+#define CM2_LUT_TBL_BASE 0x0600
+#define CM2_LUT_TBL(__i) (CM2_LUT_TBL_BASE + (__i) * 4)
+
+struct rcar_cmm {
+ void __iomem *base;
+
+ /*
+* @lut:1D-LUT state
+* @lut.enabled:1D-LUT enabled flag
+*/
+ struct {
+ bool enabled;
+ } lut;
+};
+
+static inline int rcar_cmm_read(struct rcar_cmm *rcmm, u32 reg)
+{
+ return ioread32(rcmm->base + reg);
+}
+
+static inline void rcar_cmm_write(struct rcar_cmm *rcmm, u32 reg, u32 data)
+{
+ iowrite32(data, rcmm->base + reg);
+}
+
+/*
+ * rcar_cmm_lut_write() - Scale the DRM LUT table entries to hardware precision
+ * and write to the CMM registers
+ * @rcmm: Pointer to the CMM device
+ * @drm_lut: Pointer to the DRM LUT table
+ */
+static void rcar_cmm_lut_write(struct rcar_cmm *rcmm,
+ const struct drm_color_lut *drm_lut)
+{
+ unsigned int i;
+
+ for (i = 0; i < CM2_LUT_SIZE; ++i) {
+ u32 entry = drm_color_lut_extract(drm_lut[i].red, 8) << 16
+ | drm_color_lut_extract(drm_lut[i].green, 8) << 8
+ | drm_color_lut_extract(drm_lut[i].blue, 8);
+
+ rcar_cmm_write(rcmm, CM2_LUT_TBL(i), entry);
+ }
+}
+
+/*
+ * rcar_cmm_setup() - Configure the CMM unit
+ * @pdev: The platform device associated with the CMM instance
+ * @config: The CMM unit configuration
+ *
+ * Configure the CMM unit with the given configuration. Currently enabling,
+ * disabling and programming of the 1
[PATCH v7 6/7] drm: rcar-du: crtc: Register GAMMA_LUT properties
Enable the GAMMA_LUT KMS property using the framework helpers to
register the property and set the associated gamma table maximum size.
Reviewed-by: Kieran Bingham
Reviewed-by: Ulrich Hecht
Reviewed-by: Laurent Pinchart
Signed-off-by: Jacopo Mondi
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 4
1 file 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 3f0f16946f42..e12ce9c8923b 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -1136,6 +1136,7 @@ static const struct drm_crtc_funcs crtc_funcs_gen3 = {
.set_crc_source = rcar_du_crtc_set_crc_source,
.verify_crc_source = rcar_du_crtc_verify_crc_source,
.get_crc_sources = rcar_du_crtc_get_crc_sources,
+ .gamma_set = drm_atomic_helper_legacy_gamma_set,
};
/*
-
@@ -1259,6 +1260,9 @@ int rcar_du_crtc_create(struct rcar_du_group *rgrp,
unsigned int swindex,
if (rcdu->cmms[swindex]) {
rcrtc->cmm = rcdu->cmms[swindex];
rgrp->cmms_mask |= BIT(hwindex % 2);
+
+ drm_mode_crtc_set_gamma_size(crtc, CM2_LUT_SIZE);
+ drm_crtc_enable_color_mgmt(crtc, 0, false, CM2_LUT_SIZE);
}
drm_crtc_helper_add(crtc, &crtc_helper_funcs);
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 7/7] drm: rcar-du: kms: Expand comment in vsps parsing routine
Expand comment in the 'vsps' parsing routine to specify the LIF channel index defaults to 0 in case the second cell of the property is not specified to remain compatible with older DT bindings. Reviewed-by: Kieran Bingham Reviewed-by: Laurent Pinchart Signed-off-by: Jacopo Mondi --- drivers/gpu/drm/rcar-du/rcar_du_kms.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c b/drivers/gpu/drm/rcar-du/rcar_du_kms.c index 7c9fb5860e54..186422ac552b 100644 --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c @@ -587,7 +587,11 @@ static int rcar_du_vsps_init(struct rcar_du_device *rcdu) vsps[j].crtcs_mask |= BIT(i); - /* Store the VSP pointer and pipe index in the CRTC. */ + /* +* Store the VSP pointer and pipe index in the CRTC. If the +* second cell of the 'vsps' specifier isn't present, default +* to 0 to remain compatible with older DT bindings. +*/ rcdu->crtcs[i].vsp = &rcdu->vsps[j]; rcdu->crtcs[i].vsp_pipe = cells >= 1 ? args.args[0] : 0; } -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 2/7] dt-bindings: display, renesas, du: Document cmms property
Document the newly added 'cmms' property which accepts a list of phandle
and channel index pairs that point to the CMM units available for each
Display Unit output video channel.
Reviewed-by: Rob Herring
Reviewed-by: Kieran Bingham
Reviewed-by: Laurent Pinchart
Signed-off-by: Jacopo Mondi
---
Documentation/devicetree/bindings/display/renesas,du.txt | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/renesas,du.txt
b/Documentation/devicetree/bindings/display/renesas,du.txt
index c97dfacad281..3d9809b486b6 100644
--- a/Documentation/devicetree/bindings/display/renesas,du.txt
+++ b/Documentation/devicetree/bindings/display/renesas,du.txt
@@ -45,6 +45,10 @@ Required Properties:
instance that serves the DU channel, and the channel index identifies the
LIF instance in that VSP.
+ - renesas,cmms: A list of phandles to the CMM instances present in the SoC,
+one for each available DU channel. The property shall not be specified for
+SoCs that do not provide any CMM (such as V3M and V3H).
+
Required nodes:
The connections to the DU output video ports are modeled using the OF graph
@@ -91,6 +95,7 @@ Example: R8A7795 (R-Car H3) ES2.0 DU
<&cpg CPG_MOD 721>;
clock-names = "du.0", "du.1", "du.2", "du.3";
vsps = <&vspd0 0>, <&vspd1 0>, <&vspd2 0>, <&vspd0 1>;
+ renesas,cmms = <&cmm0>, <&cmm1>, <&cmm2>, <&cmm3>;
ports {
#address-cells = <1>;
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 1/7] dt-bindings: display: renesas, cmm: Add R-Car CMM documentation
Add device tree bindings documentation for the Renesas R-Car Display
Unit Color Management Module.
CMM is the image enhancement module available on each R-Car DU video
channel on R-Car Gen2 and Gen3 SoCs (V3H and V3M excluded).
Reviewed-by: Rob Herring
Reviewed-by: Kieran Bingham
Reviewed-by: Laurent Pinchart
Signed-off-by: Jacopo Mondi
---
.../bindings/display/renesas,cmm.yaml | 67 +++
1 file changed, 67 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/renesas,cmm.yaml
diff --git a/Documentation/devicetree/bindings/display/renesas,cmm.yaml
b/Documentation/devicetree/bindings/display/renesas,cmm.yaml
new file mode 100644
index ..a57037b9e9ba
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/renesas,cmm.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: GPL-2.0-only
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/renesas,cmm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas R-Car Color Management Module (CMM)
+
+maintainers:
+ - Laurent Pinchart
+ - Kieran Bingham
+ - Jacopo Mondi
+
+description: |+
+ Renesas R-Car color management module connected to R-Car DU video channels.
+ It provides image enhancement functions such as 1-D look-up tables (LUT),
+ 3-D look-up tables (CLU), 1D-histogram generation (HGO), and color
+ space conversion (CSC).
+
+properties:
+ compatible:
+oneOf:
+ - items:
+- enum:
+ - renesas,r8a7795-cmm
+ - renesas,r8a7796-cmm
+ - renesas,r8a77965-cmm
+ - renesas,r8a77990-cmm
+ - renesas,r8a77995-cmm
+- const: renesas,rcar-gen3-cmm
+ - items:
+- const: renesas,rcar-gen2-cmm
+
+ reg:
+maxItems: 1
+
+ clocks:
+maxItems: 1
+
+ resets:
+maxItems: 1
+
+ power-domains:
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - resets
+ - power-domains
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+
+cmm0: cmm@fea4 {
+ compatible = "renesas,r8a7796-cmm",
+ "renesas,rcar-gen3-cmm";
+ reg = <0 0xfea4 0 0x1000>;
+ power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
+ clocks = <&cpg CPG_MOD 711>;
+ resets = <&cpg 711>;
+};
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 5/7] drm: rcar-du: crtc: Control CMM operations
Implement CMM handling in the crtc begin and enable atomic callbacks,
and enable CMM unit through the Display Extensional Functions
register at group setup time.
Reviewed-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
Signed-off-by: Jacopo Mondi
---
v6 -> v7
- Drop check for CMM in rcar_du_cmm_check as if the gamma_table property is
available, a CMM unit for this CRTC was registered
- Add TODO note to investigate how the activation order of CMM and CRTC
impact on the first displayed fram
---
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 61 +
drivers/gpu/drm/rcar-du/rcar_du_group.c | 10
drivers/gpu/drm/rcar-du/rcar_du_regs.h | 5 ++
3 files changed, 76 insertions(+)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 23f1d6cc1719..3f0f16946f42 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -21,6 +21,7 @@
#include
#include
+#include "rcar_cmm.h"
#include "rcar_du_crtc.h"
#include "rcar_du_drv.h"
#include "rcar_du_encoder.h"
@@ -474,6 +475,45 @@ static void rcar_du_crtc_wait_page_flip(struct
rcar_du_crtc *rcrtc)
rcar_du_crtc_finish_page_flip(rcrtc);
}
+/*
-
+ * Color Management Module (CMM)
+ */
+
+static int rcar_du_cmm_check(struct drm_crtc *crtc,
+struct drm_crtc_state *state)
+{
+ struct drm_property_blob *drm_lut = state->gamma_lut;
+ struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
+ struct device *dev = rcrtc->dev->dev;
+
+ if (!drm_lut)
+ return 0;
+
+ /* We only accept fully populated LUT tables. */
+ if (drm_color_lut_size(drm_lut) != CM2_LUT_SIZE) {
+ dev_err(dev, "invalid gamma lut size: %lu bytes\n",
+ drm_lut->length);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static void rcar_du_cmm_setup(struct drm_crtc *crtc)
+{
+ struct drm_property_blob *drm_lut = crtc->state->gamma_lut;
+ struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
+ struct rcar_cmm_config cmm_config = {};
+
+ if (!rcrtc->cmm)
+ return;
+
+ if (drm_lut)
+ cmm_config.lut.table = (struct drm_color_lut *)drm_lut->data;
+
+ rcar_cmm_setup(rcrtc->cmm, &cmm_config);
+}
+
/*
-
* Start/Stop and Suspend/Resume
*/
@@ -619,6 +659,9 @@ static void rcar_du_crtc_stop(struct rcar_du_crtc *rcrtc)
if (rcar_du_has(rcrtc->dev, RCAR_DU_FEATURE_VSP1_SOURCE))
rcar_du_vsp_disable(rcrtc);
+ if (rcrtc->cmm)
+ rcar_cmm_disable(rcrtc->cmm);
+
/*
* Select switch sync mode. This stops display operation and configures
* the HSYNC and VSYNC signals as inputs.
@@ -642,6 +685,11 @@ static int rcar_du_crtc_atomic_check(struct drm_crtc *crtc,
{
struct rcar_du_crtc_state *rstate = to_rcar_crtc_state(state);
struct drm_encoder *encoder;
+ int ret;
+
+ ret = rcar_du_cmm_check(crtc, state);
+ if (ret)
+ return ret;
/* Store the routes from the CRTC output to the DU outputs. */
rstate->outputs = 0;
@@ -667,6 +715,8 @@ static void rcar_du_crtc_atomic_enable(struct drm_crtc
*crtc,
struct rcar_du_crtc_state *rstate = to_rcar_crtc_state(crtc->state);
struct rcar_du_device *rcdu = rcrtc->dev;
+ if (rcrtc->cmm)
+ rcar_cmm_enable(rcrtc->cmm);
rcar_du_crtc_get(rcrtc);
/*
@@ -686,6 +736,13 @@ static void rcar_du_crtc_atomic_enable(struct drm_crtc
*crtc,
}
rcar_du_crtc_start(rcrtc);
+
+ /*
+* TODO: The chip manual indicates that CMM tables should be written
+* after the DU channel has been activated. Investigate the impact
+* of this restriction on the first displayed frame.
+*/
+ rcar_du_cmm_setup(crtc);
}
static void rcar_du_crtc_atomic_disable(struct drm_crtc *crtc,
@@ -739,6 +796,10 @@ static void rcar_du_crtc_atomic_begin(struct drm_crtc
*crtc,
*/
rcar_du_crtc_get(rcrtc);
+ /* If the active state changed, we let .atomic_enable handle CMM. */
+ if (crtc->state->color_mgmt_changed && !crtc->state->active_changed)
+ rcar_du_cmm_setup(crtc);
+
if (rcar_du_has(rcrtc->dev, RCAR_DU_FEATURE_VSP1_SOURCE))
rcar_du_vsp_atomic_begin(rcrtc);
}
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_group.c
b/drivers/gpu/drm/rcar-du/rcar_du_group.c
index 9eee47969e77..88a783ceb3e9 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_group.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_group.c
@@ -135,6 +135,7 @@ static void rc
[PATCH v7 4/7] drm: rcar-du: kms: Initialize CMM instances
Implement device tree parsing to collect the available CMM instances
described by the 'renesas,cmms' property. Associate CMMs with CRTCs and
store a mask of active CMMs in the DU group for later enablement.
Enforce the probe and suspend/resume ordering of DU and CMM by creating
a stateless device link between the two.
Reviewed-by: Kieran Bingham
Reviewed-by: Laurent Pinchart
Signed-off-by: Jacopo Mondi
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 6 ++
drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 2 +
drivers/gpu/drm/rcar-du/rcar_du_drv.h | 2 +
drivers/gpu/drm/rcar-du/rcar_du_group.h | 2 +
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 76 +
5 files changed, 88 insertions(+)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 2da46e3dc4ae..23f1d6cc1719 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -1194,6 +1194,12 @@ int rcar_du_crtc_create(struct rcar_du_group *rgrp,
unsigned int swindex,
if (ret < 0)
return ret;
+ /* CMM might be disabled for this CRTC. */
+ if (rcdu->cmms[swindex]) {
+ rcrtc->cmm = rcdu->cmms[swindex];
+ rgrp->cmms_mask |= BIT(hwindex % 2);
+ }
+
drm_crtc_helper_add(crtc, &crtc_helper_funcs);
/* Start with vertical blanking interrupt reporting disabled. */
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
index 3b7fc668996f..5f2940c42225 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
@@ -39,6 +39,7 @@ struct rcar_du_vsp;
* @vblank_wait: wait queue used to signal vertical blanking
* @vblank_count: number of vertical blanking interrupts to wait for
* @group: CRTC group this CRTC belongs to
+ * @cmm: CMM associated with this CRTC
* @vsp: VSP feeding video to this CRTC
* @vsp_pipe: index of the VSP pipeline feeding video to this CRTC
* @writeback: the writeback connector
@@ -64,6 +65,7 @@ struct rcar_du_crtc {
unsigned int vblank_count;
struct rcar_du_group *group;
+ struct platform_device *cmm;
struct rcar_du_vsp *vsp;
unsigned int vsp_pipe;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
index 1327cd0df90a..61504c54e2ec 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
@@ -13,6 +13,7 @@
#include
#include
+#include "rcar_cmm.h"
#include "rcar_du_crtc.h"
#include "rcar_du_group.h"
#include "rcar_du_vsp.h"
@@ -85,6 +86,7 @@ struct rcar_du_device {
struct rcar_du_encoder *encoders[RCAR_DU_OUTPUT_MAX];
struct rcar_du_group groups[RCAR_DU_MAX_GROUPS];
+ struct platform_device *cmms[RCAR_DU_MAX_CRTCS];
struct rcar_du_vsp vsps[RCAR_DU_MAX_VSPS];
struct {
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_group.h
b/drivers/gpu/drm/rcar-du/rcar_du_group.h
index 87950c1f6a52..e9906609c635 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_group.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_group.h
@@ -22,6 +22,7 @@ struct rcar_du_device;
* @mmio_offset: registers offset in the device memory map
* @index: group index
* @channels_mask: bitmask of populated DU channels in this group
+ * @cmms_mask: bitmask of available CMMs in this group
* @num_crtcs: number of CRTCs in this group (1 or 2)
* @use_count: number of users of the group (rcar_du_group_(get|put))
* @used_crtcs: number of CRTCs currently in use
@@ -37,6 +38,7 @@ struct rcar_du_group {
unsigned int index;
unsigned int channels_mask;
+ unsigned int cmms_mask;
unsigned int num_crtcs;
unsigned int use_count;
unsigned int used_crtcs;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 2dc9caee8767..7c9fb5860e54 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -17,7 +17,9 @@
#include
#include
+#include
#include
+#include
#include
#include "rcar_du_crtc.h"
@@ -614,6 +616,75 @@ static int rcar_du_vsps_init(struct rcar_du_device *rcdu)
return ret;
}
+static int rcar_du_cmm_init(struct rcar_du_device *rcdu)
+{
+ const struct device_node *np = rcdu->dev->of_node;
+ unsigned int i;
+ int cells;
+
+ cells = of_property_count_u32_elems(np, "renesas,cmms");
+ if (cells == -EINVAL)
+ return 0;
+
+ if (cells > rcdu->num_crtcs) {
+ dev_err(rcdu->dev,
+ "Invalid number of entries in 'renesas,cmms'\n");
+ return -EINVAL;
+ }
+
+ for (i = 0; i < cells; ++i) {
+ struct platform_device *pdev;
+ struct device_link *link;
+
[PATCH v7 0/7] drm: rcar-du: Add Color Management Module (CMM)
An additional round for cmm to fix the KConfig issue reported by Dave spotted while collecting Laurent's pull request for the v5.5 merge window, which we've now missed. I could have sent a 6.2 version of the single 3/7 patch, but given I already sent a 6.1 for this same one, I assumed a single series would have been easier to collect, considering we're anyway late for this merge window. The DTS patches have been collected by Geert already. Thanks j Detailed v1->v5 change log https://lkml.org/lkml/2019/10/15/337 v6->v7 - Include the two updates for 3/7 and 5/7 I've sent as v6.1 against the v6 series - Make the DRM_RCAR_CMM symbol a tristate and make it implied by DRM_RCAR_DU to prevent having DU built-in and CMM has a module, which causes linkage errors due to unresolved symbols. Jacopo Mondi (7): dt-bindings: display: renesas,cmm: Add R-Car CMM documentation dt-bindings: display, renesas,du: Document cmms property drm: rcar-du: Add support for CMM drm: rcar-du: kms: Initialize CMM instances drm: rcar-du: crtc: Control CMM operations drm: rcar-du: crtc: Register GAMMA_LUT properties drm: rcar-du: kms: Expand comment in vsps parsing routine .../bindings/display/renesas,cmm.yaml | 67 ++ .../bindings/display/renesas,du.txt | 5 + drivers/gpu/drm/rcar-du/Kconfig | 8 + drivers/gpu/drm/rcar-du/Makefile | 1 + drivers/gpu/drm/rcar-du/rcar_cmm.c| 212 ++ drivers/gpu/drm/rcar-du/rcar_cmm.h| 58 + drivers/gpu/drm/rcar-du/rcar_du_crtc.c| 65 ++ drivers/gpu/drm/rcar-du/rcar_du_crtc.h| 2 + drivers/gpu/drm/rcar-du/rcar_du_drv.h | 2 + drivers/gpu/drm/rcar-du/rcar_du_group.c | 10 + drivers/gpu/drm/rcar-du/rcar_du_group.h | 2 + drivers/gpu/drm/rcar-du/rcar_du_kms.c | 82 ++- drivers/gpu/drm/rcar-du/rcar_du_regs.h| 5 + 13 files changed, 518 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/display/renesas,cmm.yaml create mode 100644 drivers/gpu/drm/rcar-du/rcar_cmm.c create mode 100644 drivers/gpu/drm/rcar-du/rcar_cmm.h -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 0/8] drm: rcar-du: Add Color Management Module (CMM)
Hello, On Mon, Nov 11, 2019 at 11:21:28AM +, Kalakodima Venkata Rajesh (RBEI/ECF3) wrote: > Hi Jacopo, > > Please find comments below. > > Best regards, > > Rajesh Kv > RBEI/ECF3 > > > -Original Message- > > From: linux-kernel-ow...@vger.kernel.org > ow...@vger.kernel.org> On Behalf Of Jacopo Mondi > > Sent: Tuesday, October 15, 2019 4:16 PM > > To: laurent.pinch...@ideasonboard.com; > > kieran.bingham+rene...@ideasonboard.com; ge...@linux-m68k.org; > > ho...@verge.net.au; uli+rene...@fpond.eu; Kalakodima Venkata Rajesh > > (RBEI/ECF3) > > Cc: Jacopo Mondi ; airl...@linux.ie; > > dan...@ffwll.ch; koji.matsuoka...@renesas.com; mur...@ksk.co.jp; Harsha > > Manjula Mallikarjun (RBEI/ECF3) ; > > ezequ...@collabora.com; seanp...@chromium.org; linux-renesas- > > s...@vger.kernel.org; dri-devel@lists.freedesktop.org; linux- > > ker...@vger.kernel.org > > Subject: [PATCH v5 0/8] drm: rcar-du: Add Color Management Module (CMM) > > > > References: > > A reference to the v1 cover letter, with some background on the CMM is > > available here: > > https://lkml.org/lkml/2019/6/6/583 > > v2: > > https://lore.kernel.org/linux-renesas-soc/20190706140746.29132-10- > > jacopo+rene...@jmondi.org/ > > v3: > > https://lore.kernel.org/linux-renesas-soc/20190825135154.11488-1- > > jacopo+rene...@jmondi.org/ > > v4: > > https://lore.kernel.org/linux-renesas-soc/20190906135436.10622-1- > > jacopo+rene...@jmondi.org/ > > > > Again, quite a consistent changelog, mostly due to the developments happened > > on Ezequiel's VOP unit following Sean's advices. > > > > I here implemented the same, and moved the CMM handling to the crtc being > > and enable callbacks. As a result the overall implementation results quite > > a lot > > simplified, mostly on the CMM driver side. > > > > I have dropped tags and acks on the CMM driver and CMM enablement patches > > in DU crtc driver because of the number of changes. > > > > A more detailed change log: > > > > - Rebased on renesas-devel-2019-10-07-v5.4-rc4 > > > > * Bindings/DT > > - Included Rob's comments on the yaml file license and the use of 'OneOf' > > in the compatible property description > > - Use the bracketed style suggested by Kieran for the 'renesas,cmm' property > > introduced in patch 2 > > - Re-order the properties in the SoC DTS files as suggested by Kieran > > > > * CMM/DU > > - As anticipated, moved CMM management to the crtc from the atomic commit > > tail > > helper where it was implemented in v4 > > This allow to correctly support resume/suspend and proper ordering of the > > CMM > > enable and setup operations (enable -before- setup) > > - As a consequence the CMM driver is greatly simplified by removing the need > > to cache the LUT table entries provided to cmm_setup() and later re-apply > > them at enable time. > > - Better support handling of disabled CMM config option by returning -ENODEV > > at cmm_init() time as suggested by Kieran. > > > > * Testing > > I have tested by injecting a color inversion LUT table and > > enabling/disabling it > > every 50 displayed frames: > > https://jmondi.org/cgit/kmsxx/log/?h=gamma_lut > > > > CMM functionalities are retained between suspend/resume cycles (tested with > > suspend-to-idle) without requiring a re-programming of the LUT tables. > > > > Testing with real world use cases might be beneficial. Rajesh are you still > > interested in giving this series a spin > > I have tested version v3 of CMM module with a demo application based on libdrm > library. I could successfully test setting of Gamma LUT. \o/ If you want to, please send your Tested-by tag, so that it can be collected, as CMM support will be collected for the v5.6 merge window, as we had a small issue that prevented v6 from being part of the v5.5 one. > > Next step is to test on full featured graphics stack i.e. involving Weston > and OpenGL. > Weston can set Gamma. I have to stop this work for a while due to other high > prio activities. > I plan to resume soon. > Thanks for testing and please keep us posted! Thanks j > > > > Laurent, Kieran, could we fast-track review of this and hopefully try to > > have it > > merged for v5.5 ? > > > > Thanks Ezequiel for having suggested me this solution. > > > > Thanks > >j > > > > Jacopo Mondi (8): > > dt-bindings: display: renesas,cmm: Add R-Car CMM documentation &
Re: [PATCH v3 2/7] drm/bridge: Repurpose lvds-encoder.c
Hi Laurent, On Fri, Nov 08, 2019 at 01:06:58PM +0200, Laurent Pinchart wrote: > Hello Jacopo, > > On Fri, Nov 08, 2019 at 10:39:27AM +0100, Jacopo Mondi wrote: > > On Fri, Nov 08, 2019 at 09:22:56AM +, Fabrizio Castro wrote: > > > On 07 November 2019 20:35 Laurent Pinchart wrote: > > > > On Thu, Nov 07, 2019 at 08:10:58PM +, Fabrizio Castro wrote: > > > > > lvds-encoder.c implementation is also suitable for LVDS decoders, > > > > > not just LVDS encoders. > > > > > Instead of creating a new driver for addressing support for > > > > > transparent LVDS decoders, repurpose lvds-encoder.c for the greater > > > > > good. > > > > > > > > > > Signed-off-by: Fabrizio Castro > > > > > > > > > > --- > > > > > v2->v3: > > > > > * No change > > > > > v1->v2: > > > > > * No change > > > > > --- > > > > > drivers/gpu/drm/bridge/Kconfig| 8 +- > > > > > drivers/gpu/drm/bridge/Makefile | 2 +- > > > > > drivers/gpu/drm/bridge/lvds-codec.c | 131 > > > > > > > > > > drivers/gpu/drm/bridge/lvds-encoder.c | 155 > > > > > -- > > > > > 4 files changed, 136 insertions(+), 160 deletions(-) > > > > > > > > It would help if you added the -M1 option to git-format-patch to detect > > > > the rename, the result would be easier to review. > > > > > > Will do, thank you for the hint > > > > > > > > create mode 100644 drivers/gpu/drm/bridge/lvds-codec.c > > > > > delete mode 100644 drivers/gpu/drm/bridge/lvds-encoder.c > > > > > > > > > > diff --git a/drivers/gpu/drm/bridge/Kconfig > > > > > b/drivers/gpu/drm/bridge/Kconfig > > > > > index 3436297..9e75ca4e 100644 > > > > > --- a/drivers/gpu/drm/bridge/Kconfig > > > > > +++ b/drivers/gpu/drm/bridge/Kconfig > > > > > @@ -45,14 +45,14 @@ config DRM_DUMB_VGA_DAC > > > > > Support for non-programmable RGB to VGA DAC bridges, such as > > > > > ADI > > > > > ADV7123, TI THS8134 and THS8135 or passive resistor ladder > > > > > DACs. > > > > > > > > > > -config DRM_LVDS_ENCODER > > > > > - tristate "Transparent parallel to LVDS encoder support" > > > > > +config DRM_LVDS_CODEC > > > > > + tristate "Transparent LVDS encoders and decoders support" > > > > > depends on OF > > > > > select DRM_KMS_HELPER > > > > > select DRM_PANEL_BRIDGE > > > > > help > > > > > - Support for transparent parallel to LVDS encoders that don't > > > > > require > > > > > - any configuration. > > > > > + Support for transparent LVDS encoders and LVDS decoders that > > > > > don't > > > > > + require any configuration. > > > > > > > > > > config DRM_MEGACHIPS_STDP_GE_B850V3_FW > > > > > tristate "MegaChips stdp4028-ge-b850v3-fw and > > > > > stdp2690-ge-b850v3-fw" > > > > > diff --git a/drivers/gpu/drm/bridge/Makefile > > > > > b/drivers/gpu/drm/bridge/Makefile > > > > > index 4934fcf..8a9178a 100644 > > > > > --- a/drivers/gpu/drm/bridge/Makefile > > > > > +++ b/drivers/gpu/drm/bridge/Makefile > > > > > @@ -2,7 +2,7 @@ > > > > > obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o > > > > > obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o > > > > > obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o > > > > > -obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o > > > > > +obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o > > > > > obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) += > > > > > megachips-stdp-ge-b850v3-fw.o > > > > > obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o > > > > > obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o > > > > > diff --git a/drivers/gpu/drm/bridge/lvds-codec.c > > > > > b/drivers/gpu/drm/bridge/lvds-codec.c > > > > > new file mode 100644 > > > > > index 000..d57a8eb > > > > > --
Re: [PATCH v3 2/7] drm/bridge: Repurpose lvds-encoder.c
Hello,
On Fri, Nov 08, 2019 at 09:22:56AM +, Fabrizio Castro wrote:
> Hello Laurent,
>
> Thank you for your feedback!
>
> > From: devicetree-ow...@vger.kernel.org
> > On Behalf Of Laurent Pinchart
> > Sent: 07 November 2019 20:35
> > Subject: Re: [PATCH v3 2/7] drm/bridge: Repurpose lvds-encoder.c
> >
> > Hi Fabrizio,
> >
> > Thank you for the patch.
> >
> > On Thu, Nov 07, 2019 at 08:10:58PM +, Fabrizio Castro wrote:
> > > lvds-encoder.c implementation is also suitable for LVDS decoders,
> > > not just LVDS encoders.
> > > Instead of creating a new driver for addressing support for
> > > transparent LVDS decoders, repurpose lvds-encoder.c for the greater
> > > good.
> > >
> > > Signed-off-by: Fabrizio Castro
> > >
> > > ---
> > > v2->v3:
> > > * No change
> > > v1->v2:
> > > * No change
> > > ---
> > > drivers/gpu/drm/bridge/Kconfig| 8 +-
> > > drivers/gpu/drm/bridge/Makefile | 2 +-
> > > drivers/gpu/drm/bridge/lvds-codec.c | 131
> > > drivers/gpu/drm/bridge/lvds-encoder.c | 155
> > > --
> > > 4 files changed, 136 insertions(+), 160 deletions(-)
> >
> > It would help if you added the -M1 option to git-format-patch to detect
> > the rename, the result would be easier to review.
>
> Will do, thank you for the hint
>
> >
> > > create mode 100644 drivers/gpu/drm/bridge/lvds-codec.c
> > > delete mode 100644 drivers/gpu/drm/bridge/lvds-encoder.c
> > >
> > > diff --git a/drivers/gpu/drm/bridge/Kconfig
> > > b/drivers/gpu/drm/bridge/Kconfig
> > > index 3436297..9e75ca4e 100644
> > > --- a/drivers/gpu/drm/bridge/Kconfig
> > > +++ b/drivers/gpu/drm/bridge/Kconfig
> > > @@ -45,14 +45,14 @@ config DRM_DUMB_VGA_DAC
> > > Support for non-programmable RGB to VGA DAC bridges, such as ADI
> > > ADV7123, TI THS8134 and THS8135 or passive resistor ladder DACs.
> > >
> > > -config DRM_LVDS_ENCODER
> > > - tristate "Transparent parallel to LVDS encoder support"
> > > +config DRM_LVDS_CODEC
> > > + tristate "Transparent LVDS encoders and decoders support"
> > > depends on OF
> > > select DRM_KMS_HELPER
> > > select DRM_PANEL_BRIDGE
> > > help
> > > - Support for transparent parallel to LVDS encoders that don't require
> > > - any configuration.
> > > + Support for transparent LVDS encoders and LVDS decoders that don't
> > > + require any configuration.
> > >
> > > config DRM_MEGACHIPS_STDP_GE_B850V3_FW
> > > tristate "MegaChips stdp4028-ge-b850v3-fw and stdp2690-ge-b850v3-fw"
> > > diff --git a/drivers/gpu/drm/bridge/Makefile
> > > b/drivers/gpu/drm/bridge/Makefile
> > > index 4934fcf..8a9178a 100644
> > > --- a/drivers/gpu/drm/bridge/Makefile
> > > +++ b/drivers/gpu/drm/bridge/Makefile
> > > @@ -2,7 +2,7 @@
> > > obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
> > > obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
> > > obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
> > > -obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o
> > > +obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
> > > obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) +=
> > > megachips-stdp-ge-b850v3-fw.o
> > > obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
> > > obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
> > > diff --git a/drivers/gpu/drm/bridge/lvds-codec.c
> > > b/drivers/gpu/drm/bridge/lvds-codec.c
> > > new file mode 100644
> > > index 000..d57a8eb
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/bridge/lvds-codec.c
> > > @@ -0,0 +1,131 @@
> > > +// SPDX-License-Identifier: GPL-2.0-or-later
> > > +/*
> > > + * Copyright (C) 2019 Renesas Electronics Corporation
> > > + * Copyright (C) 2016 Laurent Pinchart
> > >
> > > + */
> > > +
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +
> > > +#include
> > > +#include
> > > +
> > > +struct lvds_codec {
> > > + struct drm_bridge bridge;
> > > + struct drm_bridge *panel_bridge;
> > > + struct gpio_desc *powerdown_gpio;
> > > +};
> > > +
> > > +static int lvds_codec_attach(struct drm_bridge *bridge)
> > > +{
> > > + struct lvds_codec *lvds_codec = container_of(bridge,
> > > + struct lvds_codec, bridge);
> > > +
> > > + return drm_bridge_attach(bridge->encoder, lvds_codec->panel_bridge,
> > > + bridge);
> > > +}
> > > +
> > > +static void lvds_codec_enable(struct drm_bridge *bridge)
> > > +{
> > > + struct lvds_codec *lvds_codec = container_of(bridge,
> > > + struct lvds_codec, bridge);
> > > +
> > > + if (lvds_codec->powerdown_gpio)
> > > + gpiod_set_value_cansleep(lvds_codec->powerdown_gpio, 0);
> > > +}
> > > +
> > > +static void lvds_codec_disable(struct drm_bridge *bridge)
> > > +{
> > > + struct lvds_codec *lvds_codec = container_of(bridge,
> > > + struct lvds_codec, bridge);
> > > +
> > > + if (lvds_codec->powerdown_gpio)
> > > +
Re: [PATCH v2 1/4] drm/bridge: Repurpose lvds-encoder.c
Hi Fabrizio,
On Thu, Nov 07, 2019 at 08:02:25PM +, Fabrizio Castro wrote:
> Hi Jacopo,
>
> Thank you for your feedback!
>
> > From: Jacopo Mondi
> > Sent: 07 November 2019 18:19
> > Subject: Re: [PATCH v2 1/4] drm/bridge: Repurpose lvds-encoder.c
> >
> > Hi Fabrizio,
> > thanks for the patch.
> >
> > On Mon, Nov 04, 2019 at 04:58:00PM +, Fabrizio Castro wrote:
> > > lvds-encoder.c implementation is also suitable for LVDS decoders,
> > > not just LVDS encoders.
> > > Instead of creating a new driver for addressing support for
> > > transparent LVDS decoders, repurpose lvds-encoder.c for the greater
> > > good.
> > >
> > > Signed-off-by: Fabrizio Castro
> > >
> > > ---
> > > v1->v2:
> > > * No change
> > > ---
> > > drivers/gpu/drm/bridge/Kconfig| 8 +-
> > > drivers/gpu/drm/bridge/Makefile | 2 +-
> > > drivers/gpu/drm/bridge/lvds-codec.c | 169
> > > ++
> > > drivers/gpu/drm/bridge/lvds-encoder.c | 155
> > > ---
> > > 4 files changed, 174 insertions(+), 160 deletions(-)
> > > create mode 100644 drivers/gpu/drm/bridge/lvds-codec.c
> > > delete mode 100644 drivers/gpu/drm/bridge/lvds-encoder.c
> > >
> > > diff --git a/drivers/gpu/drm/bridge/Kconfig
> > > b/drivers/gpu/drm/bridge/Kconfig
> > > index 3436297..9e75ca4e 100644
> > > --- a/drivers/gpu/drm/bridge/Kconfig
> > > +++ b/drivers/gpu/drm/bridge/Kconfig
> > > @@ -45,14 +45,14 @@ config DRM_DUMB_VGA_DAC
> > > Support for non-programmable RGB to VGA DAC bridges, such as ADI
> > > ADV7123, TI THS8134 and THS8135 or passive resistor ladder DACs.
> > >
> > > -config DRM_LVDS_ENCODER
> > > - tristate "Transparent parallel to LVDS encoder support"
> > > +config DRM_LVDS_CODEC
> > > + tristate "Transparent LVDS encoders and decoders support"
> > > depends on OF
> > > select DRM_KMS_HELPER
> > > select DRM_PANEL_BRIDGE
> > > help
> > > - Support for transparent parallel to LVDS encoders that don't require
> > > - any configuration.
> > > + Support for transparent LVDS encoders and LVDS decoders that don't
> > > + require any configuration.
> > >
> > > config DRM_MEGACHIPS_STDP_GE_B850V3_FW
> > > tristate "MegaChips stdp4028-ge-b850v3-fw and stdp2690-ge-b850v3-fw"
> > > diff --git a/drivers/gpu/drm/bridge/Makefile
> > > b/drivers/gpu/drm/bridge/Makefile
> > > index 4934fcf..8a9178a 100644
> > > --- a/drivers/gpu/drm/bridge/Makefile
> > > +++ b/drivers/gpu/drm/bridge/Makefile
> > > @@ -2,7 +2,7 @@
> > > obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
> > > obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
> > > obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
> > > -obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o
> > > +obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
> > > obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) +=
> > > megachips-stdp-ge-b850v3-fw.o
> > > obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
> > > obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
> > > diff --git a/drivers/gpu/drm/bridge/lvds-codec.c
> > > b/drivers/gpu/drm/bridge/lvds-codec.c
> > > new file mode 100644
> > > index 000..8a1979c
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/bridge/lvds-codec.c
> > > @@ -0,0 +1,169 @@
> > > +// SPDX-License-Identifier: GPL-2.0-or-later
> > > +/*
> > > + * Copyright (C) 2016 Laurent Pinchart
> > >
> > > + */
> > > +
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +
> > > +#include
> > > +#include
> > > +
> > > +struct lvds_codec {
> > > + struct drm_bridge bridge;
> > > + struct drm_bridge *panel_bridge;
> > > + struct gpio_desc *powerdown_gpio;
> > > + u32 connector_type;
> > > +};
> > > +
> > > +static int lvds_codec_attach(struct drm_bridge *bridge)
> > > +{
> > > + struct lvds_codec *lvds_codec = container_of(bridge,
> > > + struct lvds_codec,
> > > + bridge);
> > >
Re: [PATCH v2 1/4] drm/bridge: Repurpose lvds-encoder.c
Hi Fabrizio,
thanks for the patch.
On Mon, Nov 04, 2019 at 04:58:00PM +, Fabrizio Castro wrote:
> lvds-encoder.c implementation is also suitable for LVDS decoders,
> not just LVDS encoders.
> Instead of creating a new driver for addressing support for
> transparent LVDS decoders, repurpose lvds-encoder.c for the greater
> good.
>
> Signed-off-by: Fabrizio Castro
>
> ---
> v1->v2:
> * No change
> ---
> drivers/gpu/drm/bridge/Kconfig| 8 +-
> drivers/gpu/drm/bridge/Makefile | 2 +-
> drivers/gpu/drm/bridge/lvds-codec.c | 169
> ++
> drivers/gpu/drm/bridge/lvds-encoder.c | 155 ---
> 4 files changed, 174 insertions(+), 160 deletions(-)
> create mode 100644 drivers/gpu/drm/bridge/lvds-codec.c
> delete mode 100644 drivers/gpu/drm/bridge/lvds-encoder.c
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 3436297..9e75ca4e 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -45,14 +45,14 @@ config DRM_DUMB_VGA_DAC
> Support for non-programmable RGB to VGA DAC bridges, such as ADI
> ADV7123, TI THS8134 and THS8135 or passive resistor ladder DACs.
>
> -config DRM_LVDS_ENCODER
> - tristate "Transparent parallel to LVDS encoder support"
> +config DRM_LVDS_CODEC
> + tristate "Transparent LVDS encoders and decoders support"
> depends on OF
> select DRM_KMS_HELPER
> select DRM_PANEL_BRIDGE
> help
> - Support for transparent parallel to LVDS encoders that don't require
> - any configuration.
> + Support for transparent LVDS encoders and LVDS decoders that don't
> + require any configuration.
>
> config DRM_MEGACHIPS_STDP_GE_B850V3_FW
> tristate "MegaChips stdp4028-ge-b850v3-fw and stdp2690-ge-b850v3-fw"
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index 4934fcf..8a9178a 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -2,7 +2,7 @@
> obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
> obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
> obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
> -obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o
> +obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
> obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) +=
> megachips-stdp-ge-b850v3-fw.o
> obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
> obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
> diff --git a/drivers/gpu/drm/bridge/lvds-codec.c
> b/drivers/gpu/drm/bridge/lvds-codec.c
> new file mode 100644
> index 000..8a1979c
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/lvds-codec.c
> @@ -0,0 +1,169 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (C) 2016 Laurent Pinchart
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +struct lvds_codec {
> + struct drm_bridge bridge;
> + struct drm_bridge *panel_bridge;
> + struct gpio_desc *powerdown_gpio;
> + u32 connector_type;
> +};
> +
> +static int lvds_codec_attach(struct drm_bridge *bridge)
> +{
> + struct lvds_codec *lvds_codec = container_of(bridge,
> + struct lvds_codec,
> + bridge);
> +
Weird indentation. Align to open ( to match the rest of the driver's
style.
> + return drm_bridge_attach(bridge->encoder, lvds_codec->panel_bridge,
> + bridge);
> +}
> +
> +static void lvds_codec_enable(struct drm_bridge *bridge)
> +{
> + struct lvds_codec *lvds_codec = container_of(bridge,
> + struct lvds_codec,
> + bridge);
> +
Here too
> + if (lvds_codec->powerdown_gpio)
> + gpiod_set_value_cansleep(lvds_codec->powerdown_gpio, 0);
> +}
> +
> +static void lvds_codec_disable(struct drm_bridge *bridge)
> +{
> + struct lvds_codec *lvds_codec = container_of(bridge,
> + struct lvds_codec,
> + bridge);
> +
> + if (lvds_codec->powerdown_gpio)
> + gpiod_set_value_cansleep(lvds_codec->powerdown_gpio, 1);
> +}
> +
> +static struct drm_bridge_funcs funcs = {
> + .attach = lvds_codec_attach,
> + .enable = lvds_codec_enable,
> + .disable = lvds_codec_disable,
> +};
> +
> +static int lvds_codec_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct device_node *port;
> + struct device_node *endpoint;
> + struct device_node *panel_node;
> + struct drm_panel *panel;
> + struct lvds_codec *lvds_codec;
> +
> + lvds_codec = devm_kzalloc(dev, sizeof(*lvds_codec), GFP_KERNEL);
> + if (!lvds_codec)
> +
Re: [GIT PULL FOR v5.5 - 2nd try] R-Car DU CMM support
Hi Laurent, On Wed, Nov 06, 2019 at 02:56:53PM +0200, Laurent Pinchart wrote: > Hi Jacopo, > > On Wed, Nov 06, 2019 at 02:52:25PM +0200, Laurent Pinchart wrote: > > On Wed, Nov 06, 2019 at 11:46:28AM +0100, Jacopo Mondi wrote: > > > On Wed, Nov 06, 2019 at 12:02:05PM +0200, Laurent Pinchart wrote: > > > > On Wed, Nov 06, 2019 at 12:00:59PM +0200, Laurent Pinchart wrote: > > > > > On Wed, Nov 06, 2019 at 01:40:13PM +1000, Dave Airlie wrote: > > > > > > On Wed, 6 Nov 2019 at 05:56, Dave Airlie wrote: > > > > > > > On Wed, 6 Nov 2019 at 05:49, Laurent Pinchart wrote: > > > > > > > > > > > > > > > > Hi Dave, > > > > > > > > > > > > > > > > Has this pull request fallen through the cracks ? > > > > > > > > > > > > > > It fell down a different crack than usual, it made it from > > > > > > > patchwork > > > > > > > onto my hard drive, but then I didn't execute the pull. > > > > > > > > > > > > > > I've pulled it down, thanks for reminder. > > > > > > > > > > > > Now it failed as I mentioned on irc. > > > > > > > > > > > > I think the new kconfig option needs to be a tristate, otherwise > > > > > > setting it to Y and having rcar-du as M fails to link > > > > > > > > > > Sorry about that :-S Both I and the 0-day bot failed to catch it. > > > > > Jacopo, could you please have a look ? I'm afraid this likely mean a > > > > > new > > > > > version of the series, and thus missing the merge window, as we're > > > > > already at -rc6. > > > > > > I managed to reproduce it by setting DRM=m. > > > RCAR_CMM stays indeed =y as it's a bool. Simply setting it to tristate > > > is enough to have it set to =m when DRM=m. > > > > > > Could this be changed when applying the series ? > > > > > > diff --git a/drivers/gpu/drm/rcar-du/Kconfig > > > b/drivers/gpu/drm/rcar-du/Kconfig > > > index 539d232790d1..e6607b5c8bb3 100644 > > > --- a/drivers/gpu/drm/rcar-du/Kconfig > > > +++ b/drivers/gpu/drm/rcar-du/Kconfig > > > @@ -14,7 +14,7 @@ config DRM_RCAR_DU > > > If M is selected the module will be called rcar-du-drm. > > > > > > config DRM_RCAR_CMM > > > - bool "R-Car DU Color Management Module (CMM) Support" > > > + tristate "R-Car DU Color Management Module (CMM) Support" > > > depends on DRM && OF > > > depends on DRM_RCAR_DU > > > help > > > > This looks reasonable to me. I'll let Dave decide if he wants to apply > > this change himself, or if I should send a new pull request for v5.6. > > Actually this won't work. With DRM_RCAR_DU=y and DRM_RCAR_CMM=m you'll > have a link failure. > You're right.. Actually just changing the RCAR_CMM option to tristate won't be enough. Adding "imply DRM_RCAR_CMM" to the DU option instead makes it impossible to select CMM=m when DU=y and viceversa, so it should be enough. > Let's fix this properly for v5.6. Could you please propose a fix that > will work with all combinations of DRM, DRM_RCAR_DU and DRM_RCAR_CMM ? Can I send a v6.1 version of the CMM patch only, or would you prefer a v7 ? we're anyway late for 5.5 I presume Thanks j > > -- > Regards, > > Laurent Pinchart signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL FOR v5.5 - 2nd try] R-Car DU CMM support
Hi Laurent, Dave, On Wed, Nov 06, 2019 at 12:02:05PM +0200, Laurent Pinchart wrote: > This time with Jacopo correctly CC'ed. > > On Wed, Nov 06, 2019 at 12:00:59PM +0200, Laurent Pinchart wrote: > > Hi Dave, > > > > (CC'ing Jacopo) > > > > On Wed, Nov 06, 2019 at 01:40:13PM +1000, Dave Airlie wrote: > > > On Wed, 6 Nov 2019 at 05:56, Dave Airlie wrote: > > > > On Wed, 6 Nov 2019 at 05:49, Laurent Pinchart wrote: > > > > > > > > > > Hi Dave, > > > > > > > > > > Has this pull request fallen through the cracks ? > > > > > > > > It fell down a different crack than usual, it made it from patchwork > > > > onto my hard drive, but then I didn't execute the pull. > > > > > > > > I've pulled it down, thanks for reminder. > > > > > > Now it failed as I mentioned on irc. > > > > > > I think the new kconfig option needs to be a tristate, otherwise > > > setting it to Y and having rcar-du as M fails to link > > > > Sorry about that :-S Both I and the 0-day bot failed to catch it. > > Jacopo, could you please have a look ? I'm afraid this likely mean a new > > version of the series, and thus missing the merge window, as we're > > already at -rc6. I managed to reproduce it by setting DRM=m. RCAR_CMM stays indeed =y as it's a bool. Simply setting it to tristate is enough to have it set to =m when DRM=m. Could this be changed when applying the series ? diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig index 539d232790d1..e6607b5c8bb3 100644 --- a/drivers/gpu/drm/rcar-du/Kconfig +++ b/drivers/gpu/drm/rcar-du/Kconfig @@ -14,7 +14,7 @@ config DRM_RCAR_DU If M is selected the module will be called rcar-du-drm. config DRM_RCAR_CMM - bool "R-Car DU Color Management Module (CMM) Support" + tristate "R-Car DU Color Management Module (CMM) Support" depends on DRM && OF depends on DRM_RCAR_DU help Thanks j > > -- > Regards, > > Laurent Pinchart signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 0/9] backlight: gpio: simplify the driver
Hello,
as promised...
On Fri, Nov 01, 2019 at 08:58:03AM +, Lee Jones wrote:
> On Thu, 24 Oct 2019, Jacopo Mondi wrote:
>
> > Hello,
> >
> > On Thu, Oct 24, 2019 at 07:47:26AM +0100, Lee Jones wrote:
> > > On Wed, 23 Oct 2019, Daniel Thompson wrote:
> > >
> > > > On Tue, Oct 22, 2019 at 11:29:54AM +0200, Bartosz Golaszewski wrote:
> > > > > wt., 22 paź 2019 o 10:36 Bartosz Golaszewski
> > > > > napisał(a):
> > > > > >
> > > > > > From: Bartosz Golaszewski
> > > > > >
> > > > > > While working on my other series related to gpio-backlight[1] I
> > > > > > noticed
> > > > > > that we could simplify the driver if we made the only user of
> > > > > > platform
> > > > > > data use GPIO lookups and device properties. This series tries to do
> > > > > > that.
> > > > > >
> > > > > > First two patches contain minor fixes. Third patch makes the driver
> > > > > > explicitly drive the GPIO line. Fourth patch adds all necessary data
> > > > > > structures to ecovec24. Patch 5/9 unifies much of the code for both
> > > > > > pdata and non-pdata cases. Patches 6-7/9 remove unused platform data
> > > > > > fields. Last two patches contain additional improvements for the
> > > > > > GPIO
> > > > > > backlight driver while we're already modifying it.
> > > > > >
> > > > > > I don't have access to this HW but hopefully this works. Only
> > > > > > compile
> > > > > > tested.
> > > > > >
> > > > > > [1] https://lkml.org/lkml/2019/6/25/900
> > > > > >
> > > > > > v1 -> v2:
> > > > > > - rebased on top of v5.3-rc1 and adjusted to the recent changes
> > > > > > from Andy
> > > > > > - added additional two patches with minor improvements
> > > > > >
> > > > > > v2 -> v3:
> > > > > > - in patch 7/7: used initializers to set values for pdata and dev
> > > > > > local vars
> > > > > >
> > > > > > v3 -> v4:
> > > > > > - rebased on top of v5.4-rc1
> > > > > > - removed changes that are no longer relevant after commit
> > > > > > ec665b756e6f
> > > > > > ("backlight: gpio-backlight: Correct initial power state
> > > > > > handling")
> > > > > > - added patch 7/7
> > > > > >
> > > > > > v4 -> v5:
> > > > > > - in patch 7/7: added a comment replacing the name of the function
> > > > > > being
> > > > > > pulled into probe()
> > > > > >
> > > > > > v5 -> v6:
> > > > > > - added a patch making the driver explicitly set the direction of
> > > > > > the GPIO
> > > > > > to output
> > > > > > - added a patch removing a redundant newline
> > > > > >
> > > > > > v6 -> v7:
> > > > > > - renamed the function calculating the new GPIO value for status
> > > > > > update
> > > > > > - collected more tags
> > > > > >
> > > > > > Bartosz Golaszewski (9):
> > > > > > backlight: gpio: remove unneeded include
> > > > > > backlight: gpio: remove stray newline
> > > > > > backlight: gpio: explicitly set the direction of the GPIO
> > > > > > sh: ecovec24: add additional properties to the backlight device
> > > > > > backlight: gpio: simplify the platform data handling
> > > > > > sh: ecovec24: don't set unused fields in platform data
> > > > > > backlight: gpio: remove unused fields from platform data
> > > > > > backlight: gpio: use a helper variable for &pdev->dev
> > > > > > backlight: gpio: pull gpio_backlight_initial_power_state() into
> > > > > > probe
> > > > > >
> > > > > > arch/sh/boards/mach-ecovec24/setup.c | 33 +++--
> > > > > > drivers/video/backlight/gpio_backlight.c | 128
> > > > > > +++
> > > > > > include/linux/platform_data/gpio_backlight.h | 3 -
> > > > > > 3 files changed, 69 insertions(+), 95 deletions(-)
> > > > > >
> > > > > >
> > > > >
> > > > > Lee, Daniel, Jingoo,
> > > > >
> > > > > Jacopo is travelling until November 1st and won't be able to test this
> > > > > again before this date. Do you think you can pick it up and in case
> > > > > anything's broken on SH, we can fix it after v5.5-rc1, so that it
> > > > > doesn't miss another merge window?
> > >
> > > November 1st (-rc6) will be fine.
> > >
> > > I'd rather apply it late-tested than early-non-tested.
> > >
> > > Hopefully Jacopo can prioritise testing this on Thursday or Friday,
> > > since Monday will be -rc7 which is really cutting it fine.
> >
> > I'll do my best, I'll get home Friday late afternoon :)
>
> Welcome home!
>
> Just a little reminder in your inbox. TIA. :)
For the ecovec part:
Tested-by: Jacopo Mondi
Thanks
j
>
> --
> Lee Jones [李琼斯]
> Linaro Services Technical Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 0/9] backlight: gpio: simplify the driver
Hello,
On Thu, Oct 24, 2019 at 07:47:26AM +0100, Lee Jones wrote:
> On Wed, 23 Oct 2019, Daniel Thompson wrote:
>
> > On Tue, Oct 22, 2019 at 11:29:54AM +0200, Bartosz Golaszewski wrote:
> > > wt., 22 paź 2019 o 10:36 Bartosz Golaszewski napisał(a):
> > > >
> > > > From: Bartosz Golaszewski
> > > >
> > > > While working on my other series related to gpio-backlight[1] I noticed
> > > > that we could simplify the driver if we made the only user of platform
> > > > data use GPIO lookups and device properties. This series tries to do
> > > > that.
> > > >
> > > > First two patches contain minor fixes. Third patch makes the driver
> > > > explicitly drive the GPIO line. Fourth patch adds all necessary data
> > > > structures to ecovec24. Patch 5/9 unifies much of the code for both
> > > > pdata and non-pdata cases. Patches 6-7/9 remove unused platform data
> > > > fields. Last two patches contain additional improvements for the GPIO
> > > > backlight driver while we're already modifying it.
> > > >
> > > > I don't have access to this HW but hopefully this works. Only compile
> > > > tested.
> > > >
> > > > [1] https://lkml.org/lkml/2019/6/25/900
> > > >
> > > > v1 -> v2:
> > > > - rebased on top of v5.3-rc1 and adjusted to the recent changes from
> > > > Andy
> > > > - added additional two patches with minor improvements
> > > >
> > > > v2 -> v3:
> > > > - in patch 7/7: used initializers to set values for pdata and dev local
> > > > vars
> > > >
> > > > v3 -> v4:
> > > > - rebased on top of v5.4-rc1
> > > > - removed changes that are no longer relevant after commit ec665b756e6f
> > > > ("backlight: gpio-backlight: Correct initial power state handling")
> > > > - added patch 7/7
> > > >
> > > > v4 -> v5:
> > > > - in patch 7/7: added a comment replacing the name of the function being
> > > > pulled into probe()
> > > >
> > > > v5 -> v6:
> > > > - added a patch making the driver explicitly set the direction of the
> > > > GPIO
> > > > to output
> > > > - added a patch removing a redundant newline
> > > >
> > > > v6 -> v7:
> > > > - renamed the function calculating the new GPIO value for status update
> > > > - collected more tags
> > > >
> > > > Bartosz Golaszewski (9):
> > > > backlight: gpio: remove unneeded include
> > > > backlight: gpio: remove stray newline
> > > > backlight: gpio: explicitly set the direction of the GPIO
> > > > sh: ecovec24: add additional properties to the backlight device
> > > > backlight: gpio: simplify the platform data handling
> > > > sh: ecovec24: don't set unused fields in platform data
> > > > backlight: gpio: remove unused fields from platform data
> > > > backlight: gpio: use a helper variable for &pdev->dev
> > > > backlight: gpio: pull gpio_backlight_initial_power_state() into probe
> > > >
> > > > arch/sh/boards/mach-ecovec24/setup.c | 33 +++--
> > > > drivers/video/backlight/gpio_backlight.c | 128 +++
> > > > include/linux/platform_data/gpio_backlight.h | 3 -
> > > > 3 files changed, 69 insertions(+), 95 deletions(-)
> > > >
> > > >
> > >
> > > Lee, Daniel, Jingoo,
> > >
> > > Jacopo is travelling until November 1st and won't be able to test this
> > > again before this date. Do you think you can pick it up and in case
> > > anything's broken on SH, we can fix it after v5.5-rc1, so that it
> > > doesn't miss another merge window?
>
> November 1st (-rc6) will be fine.
>
> I'd rather apply it late-tested than early-non-tested.
>
> Hopefully Jacopo can prioritise testing this on Thursday or Friday,
> since Monday will be -rc7 which is really cutting it fine.
I'll do my best, I'll get home Friday late afternoon :)
>
> > Outside of holidays and other emergencies Lee usually collects up the
> > patches for backlight. I'm not sure when he plans to close things for
> > v5.5.
>
> In special cases such as these I can remain flexible.
>
> --
> Lee Jones [李琼斯]
> Linaro Services Technical Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 0/7] backlight: gpio: simplify the driver
Hi,
On Thu, Oct 17, 2019 at 08:25:50AM +0100, Lee Jones wrote:
> On Wed, 16 Oct 2019, Jacopo Mondi wrote:
>
> > Hi, sorry for not having replied earlier
> >
> > On Wed, Oct 16, 2019 at 02:56:57PM +0200, Linus Walleij wrote:
> > > On Mon, Oct 14, 2019 at 10:12 AM Lee Jones wrote:
> > >
> > > > > arch/sh/boards/mach-ecovec24/setup.c | 33 --
> > > >
> > > > I guess we're just waiting for the SH Acks now?
> > >
> > > The one maintainer with this board is probably overloaded.
> > >
> > > I would say just apply it, it can't hold back the entire series.
> >
> > I've been able to resurect the Ecovec, and I've also been given a copy
> > of its schematics file a few weeks ago.
> >
> > It's in my TODO list to test this series but I didn't manage to find
> > time. If I pinky promise I get back to you before end of the week,
> > could you wait for me ? :)
Finally had some time to spend on this.
As I've reported to Bartosz, this version does not work on Ecovec out
of the box, as the GPIO line connected to the backlight needs to be
configured to work in output mode before registering the backlight
device.
With this simple change:
$ git diff
diff --git a/arch/sh/boards/mach-ecovec24/setup.c
b/arch/sh/boards/mach-ecovec24/setup.c
index dd427bac5cde..eec6e805c3ed 100644
--- a/arch/sh/boards/mach-ecovec24/setup.c
+++ b/arch/sh/boards/mach-ecovec24/setup.c
@@ -1473,6 +1473,7 @@ static int __init arch_setup(void)
#endif
#endif
+ gpio_direction_output(GPIO_PTR1, 1);
gpiod_add_lookup_table(&gpio_backlight_lookup);
gpio_backlight_device = platform_device_register_full(
&gpio_backlight_device_info);
I can now control the gpio through the backlight interface.
So please add this bit on top of next iteration and add my:
Tested-by: Jacopo Mondi
Thanks and sorry for the long time it took!
>
> Yes, no problem.
>
> --
> Lee Jones [李琼斯]
> Linaro Services Technical Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
signature.asc
Description: PGP signature
[PATCH v6.1 5/8] drm: rcar-du: crtc: Control CMM operations
Implement CMM handling in the crtc begin and enable atomic callbacks,
and enable CMM unit through the Display Extensional Functions
register at group setup time.
Reviewed-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
Signed-off-by: Jacopo Mondi
---
v6 -> v6.1
- Drop check for CMM in rcar_du_cmm_check as if the gamma_table property is
available, a CMM unit for this CRTC was registered
- Add TODO note to investigate how the activation order of CMM and CRTC
impact on the first displayed fram
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 61 +
drivers/gpu/drm/rcar-du/rcar_du_group.c | 10
drivers/gpu/drm/rcar-du/rcar_du_regs.h | 5 ++
3 files changed, 76 insertions(+)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 23f1d6cc1719..3f0f16946f42 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -21,6 +21,7 @@
#include
#include
+#include "rcar_cmm.h"
#include "rcar_du_crtc.h"
#include "rcar_du_drv.h"
#include "rcar_du_encoder.h"
@@ -474,6 +475,45 @@ static void rcar_du_crtc_wait_page_flip(struct
rcar_du_crtc *rcrtc)
rcar_du_crtc_finish_page_flip(rcrtc);
}
+/*
-
+ * Color Management Module (CMM)
+ */
+
+static int rcar_du_cmm_check(struct drm_crtc *crtc,
+struct drm_crtc_state *state)
+{
+ struct drm_property_blob *drm_lut = state->gamma_lut;
+ struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
+ struct device *dev = rcrtc->dev->dev;
+
+ if (!drm_lut)
+ return 0;
+
+ /* We only accept fully populated LUT tables. */
+ if (drm_color_lut_size(drm_lut) != CM2_LUT_SIZE) {
+ dev_err(dev, "invalid gamma lut size: %lu bytes\n",
+ drm_lut->length);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static void rcar_du_cmm_setup(struct drm_crtc *crtc)
+{
+ struct drm_property_blob *drm_lut = crtc->state->gamma_lut;
+ struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
+ struct rcar_cmm_config cmm_config = {};
+
+ if (!rcrtc->cmm)
+ return;
+
+ if (drm_lut)
+ cmm_config.lut.table = (struct drm_color_lut *)drm_lut->data;
+
+ rcar_cmm_setup(rcrtc->cmm, &cmm_config);
+}
+
/*
-
* Start/Stop and Suspend/Resume
*/
@@ -619,6 +659,9 @@ static void rcar_du_crtc_stop(struct rcar_du_crtc *rcrtc)
if (rcar_du_has(rcrtc->dev, RCAR_DU_FEATURE_VSP1_SOURCE))
rcar_du_vsp_disable(rcrtc);
+ if (rcrtc->cmm)
+ rcar_cmm_disable(rcrtc->cmm);
+
/*
* Select switch sync mode. This stops display operation and configures
* the HSYNC and VSYNC signals as inputs.
@@ -642,6 +685,11 @@ static int rcar_du_crtc_atomic_check(struct drm_crtc *crtc,
{
struct rcar_du_crtc_state *rstate = to_rcar_crtc_state(state);
struct drm_encoder *encoder;
+ int ret;
+
+ ret = rcar_du_cmm_check(crtc, state);
+ if (ret)
+ return ret;
/* Store the routes from the CRTC output to the DU outputs. */
rstate->outputs = 0;
@@ -667,6 +715,8 @@ static void rcar_du_crtc_atomic_enable(struct drm_crtc
*crtc,
struct rcar_du_crtc_state *rstate = to_rcar_crtc_state(crtc->state);
struct rcar_du_device *rcdu = rcrtc->dev;
+ if (rcrtc->cmm)
+ rcar_cmm_enable(rcrtc->cmm);
rcar_du_crtc_get(rcrtc);
/*
@@ -686,6 +736,13 @@ static void rcar_du_crtc_atomic_enable(struct drm_crtc
*crtc,
}
rcar_du_crtc_start(rcrtc);
+
+ /*
+* TODO: The chip manual indicates that CMM tables should be written
+* after the DU channel has been activated. Investigate the impact
+* of this restriction on the first displayed frame.
+*/
+ rcar_du_cmm_setup(crtc);
}
static void rcar_du_crtc_atomic_disable(struct drm_crtc *crtc,
@@ -739,6 +796,10 @@ static void rcar_du_crtc_atomic_begin(struct drm_crtc
*crtc,
*/
rcar_du_crtc_get(rcrtc);
+ /* If the active state changed, we let .atomic_enable handle CMM. */
+ if (crtc->state->color_mgmt_changed && !crtc->state->active_changed)
+ rcar_du_cmm_setup(crtc);
+
if (rcar_du_has(rcrtc->dev, RCAR_DU_FEATURE_VSP1_SOURCE))
rcar_du_vsp_atomic_begin(rcrtc);
}
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_group.c
b/drivers/gpu/drm/rcar-du/rcar_du_group.c
index 9eee47969e77..88a783ceb3e9 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_group.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_group.c
@@ -135,6 +135,7 @@ static void rcar_du_group_setup_did
[PATCH 6.1 3/8] drm: rcar-du: Add support for CMM
Add a driver for the R-Car Display Unit Color Correction Module.
In most of Gen3 SoCs, each DU output channel is provided with a CMM unit
to perform image enhancement and color correction.
Add support for CMM through a driver that supports configuration of
the 1-dimensional LUT table. More advanced CMM features will be
implemented on top of this initial one.
Reviewed-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
Signed-off-by: Jacopo Mondi
---
v6 -> v6.1
- Expand rcar_cmm_setup() function documentation to detail its relationship
with rcar_cmm_enable() and their call order precedence.
---
drivers/gpu/drm/rcar-du/Kconfig| 7 +
drivers/gpu/drm/rcar-du/Makefile | 1 +
drivers/gpu/drm/rcar-du/rcar_cmm.c | 217 +
drivers/gpu/drm/rcar-du/rcar_cmm.h | 58
4 files changed, 283 insertions(+)
create mode 100644 drivers/gpu/drm/rcar-du/rcar_cmm.c
create mode 100644 drivers/gpu/drm/rcar-du/rcar_cmm.h
diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
index 1529849e217e..539d232790d1 100644
--- a/drivers/gpu/drm/rcar-du/Kconfig
+++ b/drivers/gpu/drm/rcar-du/Kconfig
@@ -13,6 +13,13 @@ config DRM_RCAR_DU
Choose this option if you have an R-Car chipset.
If M is selected the module will be called rcar-du-drm.
+config DRM_RCAR_CMM
+ bool "R-Car DU Color Management Module (CMM) Support"
+ depends on DRM && OF
+ depends on DRM_RCAR_DU
+ help
+ Enable support for R-Car Color Management Module (CMM).
+
config DRM_RCAR_DW_HDMI
tristate "R-Car DU Gen3 HDMI Encoder Support"
depends on DRM && OF
diff --git a/drivers/gpu/drm/rcar-du/Makefile b/drivers/gpu/drm/rcar-du/Makefile
index 6c2ed9c46467..4d1187ccc3e5 100644
--- a/drivers/gpu/drm/rcar-du/Makefile
+++ b/drivers/gpu/drm/rcar-du/Makefile
@@ -15,6 +15,7 @@ rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS) += rcar_du_of.o \
rcar-du-drm-$(CONFIG_DRM_RCAR_VSP) += rcar_du_vsp.o
rcar-du-drm-$(CONFIG_DRM_RCAR_WRITEBACK) += rcar_du_writeback.o
+obj-$(CONFIG_DRM_RCAR_CMM) += rcar_cmm.o
obj-$(CONFIG_DRM_RCAR_DU) += rcar-du-drm.o
obj-$(CONFIG_DRM_RCAR_DW_HDMI) += rcar_dw_hdmi.o
obj-$(CONFIG_DRM_RCAR_LVDS)+= rcar_lvds.o
diff --git a/drivers/gpu/drm/rcar-du/rcar_cmm.c
b/drivers/gpu/drm/rcar-du/rcar_cmm.c
new file mode 100644
index ..952316eb202b
--- /dev/null
+++ b/drivers/gpu/drm/rcar-du/rcar_cmm.c
@@ -0,0 +1,217 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * rcar_cmm.c -- R-Car Display Unit Color Management Module
+ *
+ * Copyright (C) 2019 Jacopo Mondi
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "rcar_cmm.h"
+
+#define CM2_LUT_CTRL 0x
+#define CM2_LUT_CTRL_LUT_ENBIT(0)
+#define CM2_LUT_TBL_BASE 0x0600
+#define CM2_LUT_TBL(__i) (CM2_LUT_TBL_BASE + (__i) * 4)
+
+struct rcar_cmm {
+ void __iomem *base;
+
+ /*
+* @lut:1D-LUT state
+* @lut.enabled:1D-LUT enabled flag
+*/
+ struct {
+ bool enabled;
+ } lut;
+};
+
+static inline int rcar_cmm_read(struct rcar_cmm *rcmm, u32 reg)
+{
+ return ioread32(rcmm->base + reg);
+}
+
+static inline void rcar_cmm_write(struct rcar_cmm *rcmm, u32 reg, u32 data)
+{
+ iowrite32(data, rcmm->base + reg);
+}
+
+/*
+ * rcar_cmm_lut_write() - Scale the DRM LUT table entries to hardware precision
+ * and write to the CMM registers
+ * @rcmm: Pointer to the CMM device
+ * @drm_lut: Pointer to the DRM LUT table
+ */
+static void rcar_cmm_lut_write(struct rcar_cmm *rcmm,
+ const struct drm_color_lut *drm_lut)
+{
+ unsigned int i;
+
+ for (i = 0; i < CM2_LUT_SIZE; ++i) {
+ u32 entry = drm_color_lut_extract(drm_lut[i].red, 8) << 16
+ | drm_color_lut_extract(drm_lut[i].green, 8) << 8
+ | drm_color_lut_extract(drm_lut[i].blue, 8);
+
+ rcar_cmm_write(rcmm, CM2_LUT_TBL(i), entry);
+ }
+}
+
+/*
+ * rcar_cmm_setup() - Configure the CMM unit
+ * @pdev: The platform device associated with the CMM instance
+ * @config: The CMM unit configuration
+ *
+ * Configure the CMM unit with the given configuration. Currently enabling,
+ * disabling and programming of the 1-D LUT unit is supported.
+ *
+ * As rcar_cmm_setup() accesses the CMM registers the unit should be powered
+ * and its functional clock enabled. To guarantee this, before any call to
+ * this function is made, the CMM unit has to be enabled by calling
+ * rcar_cmm_enable() first.
+ *
+ * TODO: Add support for LUT double buffer operations to avoid updating the
+ * LUT table entries while a frame is being displayed.
+ */
+int rcar_cmm_setup(struct platform_device *pdev,
+ const struct rcar_cmm_config
Re: [PATCH v6 3/8] drm: rcar-du: Add support for CMM
Hi Laurent,
On Wed, Oct 16, 2019 at 04:45:26PM +0300, Laurent Pinchart wrote:
> Hi Jacopo,
>
> Thank you for the patch.
>
> On Wed, Oct 16, 2019 at 10:55:43AM +0200, Jacopo Mondi wrote:
> > Add a driver for the R-Car Display Unit Color Correction Module.
> >
> > In most of Gen3 SoCs, each DU output channel is provided with a CMM unit
> > to perform image enhancement and color correction.
> >
> > Add support for CMM through a driver that supports configuration of
> > the 1-dimensional LUT table. More advanced CMM features will be
> > implemented on top of this initial one.
> >
> > Reviewed-by: Laurent Pinchart
> > Reviewed-by: Kieran Bingham
> > Signed-off-by: Jacopo Mondi
> > ---
> > drivers/gpu/drm/rcar-du/Kconfig| 7 +
> > drivers/gpu/drm/rcar-du/Makefile | 1 +
> > drivers/gpu/drm/rcar-du/rcar_cmm.c | 212 +
> > drivers/gpu/drm/rcar-du/rcar_cmm.h | 58
> > 4 files changed, 278 insertions(+)
> > create mode 100644 drivers/gpu/drm/rcar-du/rcar_cmm.c
> > create mode 100644 drivers/gpu/drm/rcar-du/rcar_cmm.h
> >
> > diff --git a/drivers/gpu/drm/rcar-du/Kconfig
> > b/drivers/gpu/drm/rcar-du/Kconfig
> > index 1529849e217e..539d232790d1 100644
> > --- a/drivers/gpu/drm/rcar-du/Kconfig
> > +++ b/drivers/gpu/drm/rcar-du/Kconfig
> > @@ -13,6 +13,13 @@ config DRM_RCAR_DU
> > Choose this option if you have an R-Car chipset.
> > If M is selected the module will be called rcar-du-drm.
> >
> > +config DRM_RCAR_CMM
> > + bool "R-Car DU Color Management Module (CMM) Support"
> > + depends on DRM && OF
> > + depends on DRM_RCAR_DU
> > + help
> > + Enable support for R-Car Color Management Module (CMM).
> > +
> > config DRM_RCAR_DW_HDMI
> > tristate "R-Car DU Gen3 HDMI Encoder Support"
> > depends on DRM && OF
> > diff --git a/drivers/gpu/drm/rcar-du/Makefile
> > b/drivers/gpu/drm/rcar-du/Makefile
> > index 6c2ed9c46467..4d1187ccc3e5 100644
> > --- a/drivers/gpu/drm/rcar-du/Makefile
> > +++ b/drivers/gpu/drm/rcar-du/Makefile
> > @@ -15,6 +15,7 @@ rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS) += rcar_du_of.o
> > \
> > rcar-du-drm-$(CONFIG_DRM_RCAR_VSP) += rcar_du_vsp.o
> > rcar-du-drm-$(CONFIG_DRM_RCAR_WRITEBACK) += rcar_du_writeback.o
> >
> > +obj-$(CONFIG_DRM_RCAR_CMM) += rcar_cmm.o
> > obj-$(CONFIG_DRM_RCAR_DU) += rcar-du-drm.o
> > obj-$(CONFIG_DRM_RCAR_DW_HDMI) += rcar_dw_hdmi.o
> > obj-$(CONFIG_DRM_RCAR_LVDS)+= rcar_lvds.o
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_cmm.c
> > b/drivers/gpu/drm/rcar-du/rcar_cmm.c
> > new file mode 100644
> > index ..4170626208cf
> > --- /dev/null
> > +++ b/drivers/gpu/drm/rcar-du/rcar_cmm.c
> > @@ -0,0 +1,212 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * rcar_cmm.c -- R-Car Display Unit Color Management Module
> > + *
> > + * Copyright (C) 2019 Jacopo Mondi
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +
> > +#include "rcar_cmm.h"
> > +
> > +#define CM2_LUT_CTRL 0x
> > +#define CM2_LUT_CTRL_LUT_ENBIT(0)
> > +#define CM2_LUT_TBL_BASE 0x0600
> > +#define CM2_LUT_TBL(__i) (CM2_LUT_TBL_BASE + (__i) * 4)
> > +
> > +struct rcar_cmm {
> > + void __iomem *base;
> > +
> > + /*
> > +* @lut:1D-LUT state
> > +* @lut.enabled:1D-LUT enabled flag
> > +*/
> > + struct {
> > + bool enabled;
> > + } lut;
> > +};
> > +
> > +static inline int rcar_cmm_read(struct rcar_cmm *rcmm, u32 reg)
> > +{
> > + return ioread32(rcmm->base + reg);
> > +}
> > +
> > +static inline void rcar_cmm_write(struct rcar_cmm *rcmm, u32 reg, u32 data)
> > +{
> > + iowrite32(data, rcmm->base + reg);
> > +}
> > +
> > +/*
> > + * rcar_cmm_lut_write() - Scale the DRM LUT table entries to hardware
> > precision
> > + * and write to the CMM registers
> > + * @rcmm: Pointer to the CMM device
> > + * @drm_lut: Pointer to the DRM LUT table
> > + */
> > +static void rcar_cmm_lut_write(struct rcar_cmm *rcmm,
> > + const struct drm_color_lut *drm_lut)
> > +{
> > + unsigned int i;
> > +
> > + for (i = 0; i <
Re: [PATCH v5 0/7] backlight: gpio: simplify the driver
Hi, sorry for not having replied earlier On Wed, Oct 16, 2019 at 02:56:57PM +0200, Linus Walleij wrote: > On Mon, Oct 14, 2019 at 10:12 AM Lee Jones wrote: > > > > arch/sh/boards/mach-ecovec24/setup.c | 33 -- > > > > I guess we're just waiting for the SH Acks now? > > The one maintainer with this board is probably overloaded. > > I would say just apply it, it can't hold back the entire series. I've been able to resurect the Ecovec, and I've also been given a copy of its schematics file a few weeks ago. It's in my TODO list to test this series but I didn't manage to find time. If I pinky promise I get back to you before end of the week, could you wait for me ? :) Thanks and sorry again! > > Yours, > Linus Walleij signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 5/8] drm: rcar-du: crtc: Control CMM operations
Implement CMM handling in the crtc begin and enable atomic callbacks,
and enable CMM unit through the Display Extensional Functions
register at group setup time.
Reviewed-by: Kieran Bingham
Signed-off-by: Jacopo Mondi
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 55 +
drivers/gpu/drm/rcar-du/rcar_du_group.c | 10 +
drivers/gpu/drm/rcar-du/rcar_du_regs.h | 5 +++
3 files changed, 70 insertions(+)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 23f1d6cc1719..d7ad491577f3 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -21,6 +21,7 @@
#include
#include
+#include "rcar_cmm.h"
#include "rcar_du_crtc.h"
#include "rcar_du_drv.h"
#include "rcar_du_encoder.h"
@@ -474,6 +475,45 @@ static void rcar_du_crtc_wait_page_flip(struct
rcar_du_crtc *rcrtc)
rcar_du_crtc_finish_page_flip(rcrtc);
}
+/*
-
+ * Color Management Module (CMM)
+ */
+
+static int rcar_du_cmm_check(struct drm_crtc *crtc,
+struct drm_crtc_state *state)
+{
+ struct drm_property_blob *drm_lut = state->gamma_lut;
+ struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
+ struct device *dev = rcrtc->dev->dev;
+
+ if (!rcrtc->cmm || !drm_lut)
+ return 0;
+
+ /* We only accept fully populated LUT tables. */
+ if (drm_color_lut_size(drm_lut) != CM2_LUT_SIZE) {
+ dev_err(dev, "invalid gamma lut size: %lu bytes\n",
+ drm_lut->length);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static void rcar_du_cmm_setup(struct drm_crtc *crtc)
+{
+ struct drm_property_blob *drm_lut = crtc->state->gamma_lut;
+ struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
+ struct rcar_cmm_config cmm_config = {};
+
+ if (!rcrtc->cmm)
+ return;
+
+ if (drm_lut)
+ cmm_config.lut.table = (struct drm_color_lut *)drm_lut->data;
+
+ rcar_cmm_setup(rcrtc->cmm, &cmm_config);
+}
+
/*
-
* Start/Stop and Suspend/Resume
*/
@@ -619,6 +659,9 @@ static void rcar_du_crtc_stop(struct rcar_du_crtc *rcrtc)
if (rcar_du_has(rcrtc->dev, RCAR_DU_FEATURE_VSP1_SOURCE))
rcar_du_vsp_disable(rcrtc);
+ if (rcrtc->cmm)
+ rcar_cmm_disable(rcrtc->cmm);
+
/*
* Select switch sync mode. This stops display operation and configures
* the HSYNC and VSYNC signals as inputs.
@@ -642,6 +685,11 @@ static int rcar_du_crtc_atomic_check(struct drm_crtc *crtc,
{
struct rcar_du_crtc_state *rstate = to_rcar_crtc_state(state);
struct drm_encoder *encoder;
+ int ret;
+
+ ret = rcar_du_cmm_check(crtc, state);
+ if (ret)
+ return ret;
/* Store the routes from the CRTC output to the DU outputs. */
rstate->outputs = 0;
@@ -667,6 +715,8 @@ static void rcar_du_crtc_atomic_enable(struct drm_crtc
*crtc,
struct rcar_du_crtc_state *rstate = to_rcar_crtc_state(crtc->state);
struct rcar_du_device *rcdu = rcrtc->dev;
+ if (rcrtc->cmm)
+ rcar_cmm_enable(rcrtc->cmm);
rcar_du_crtc_get(rcrtc);
/*
@@ -686,6 +736,7 @@ static void rcar_du_crtc_atomic_enable(struct drm_crtc
*crtc,
}
rcar_du_crtc_start(rcrtc);
+ rcar_du_cmm_setup(crtc);
}
static void rcar_du_crtc_atomic_disable(struct drm_crtc *crtc,
@@ -739,6 +790,10 @@ static void rcar_du_crtc_atomic_begin(struct drm_crtc
*crtc,
*/
rcar_du_crtc_get(rcrtc);
+ /* If the active state changed, we let .atomic_enable handle CMM. */
+ if (crtc->state->color_mgmt_changed && !crtc->state->active_changed)
+ rcar_du_cmm_setup(crtc);
+
if (rcar_du_has(rcrtc->dev, RCAR_DU_FEATURE_VSP1_SOURCE))
rcar_du_vsp_atomic_begin(rcrtc);
}
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_group.c
b/drivers/gpu/drm/rcar-du/rcar_du_group.c
index 9eee47969e77..88a783ceb3e9 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_group.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_group.c
@@ -135,6 +135,7 @@ static void rcar_du_group_setup_didsr(struct rcar_du_group
*rgrp)
static void rcar_du_group_setup(struct rcar_du_group *rgrp)
{
struct rcar_du_device *rcdu = rgrp->dev;
+ u32 defr7 = DEFR7_CODE;
/* Enable extended features */
rcar_du_group_write(rgrp, DEFR, DEFR_CODE | DEFR_DEFE);
@@ -147,6 +148,15 @@ static void rcar_du_group_setup(struct rcar_du_group *rgrp)
rcar_du_group_setup_pins(rgrp);
+ /*
+* TODO: Handle routing of the DU output to CMM dynamically, as we
+
[PATCH v6 6/8] drm: rcar-du: crtc: Register GAMMA_LUT properties
Enable the GAMMA_LUT KMS property using the framework helpers to
register the property and set the associated gamma table maximum size.
Reviewed-by: Kieran Bingham
Reviewed-by: Ulrich Hecht
Reviewed-by: Laurent Pinchart
Signed-off-by: Jacopo Mondi
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 4
1 file 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 d7ad491577f3..a0a512b81aed 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -1130,6 +1130,7 @@ static const struct drm_crtc_funcs crtc_funcs_gen3 = {
.set_crc_source = rcar_du_crtc_set_crc_source,
.verify_crc_source = rcar_du_crtc_verify_crc_source,
.get_crc_sources = rcar_du_crtc_get_crc_sources,
+ .gamma_set = drm_atomic_helper_legacy_gamma_set,
};
/*
-
@@ -1253,6 +1254,9 @@ int rcar_du_crtc_create(struct rcar_du_group *rgrp,
unsigned int swindex,
if (rcdu->cmms[swindex]) {
rcrtc->cmm = rcdu->cmms[swindex];
rgrp->cmms_mask |= BIT(hwindex % 2);
+
+ drm_mode_crtc_set_gamma_size(crtc, CM2_LUT_SIZE);
+ drm_crtc_enable_color_mgmt(crtc, 0, false, CM2_LUT_SIZE);
}
drm_crtc_helper_add(crtc, &crtc_helper_funcs);
--
2.23.0
[PATCH v6 1/8] dt-bindings: display: renesas,cmm: Add R-Car CMM documentation
Add device tree bindings documentation for the Renesas R-Car Display
Unit Color Management Module.
CMM is the image enhancement module available on each R-Car DU video
channel on R-Car Gen2 and Gen3 SoCs (V3H and V3M excluded).
Reviewed-by: Kieran Bingham
Reviewed-by: Laurent Pinchart
Signed-off-by: Jacopo Mondi
---
.../bindings/display/renesas,cmm.yaml | 67 +++
1 file changed, 67 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/renesas,cmm.yaml
diff --git a/Documentation/devicetree/bindings/display/renesas,cmm.yaml
b/Documentation/devicetree/bindings/display/renesas,cmm.yaml
new file mode 100644
index ..a57037b9e9ba
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/renesas,cmm.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: GPL-2.0-only
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/renesas,cmm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas R-Car Color Management Module (CMM)
+
+maintainers:
+ - Laurent Pinchart
+ - Kieran Bingham
+ - Jacopo Mondi
+
+description: |+
+ Renesas R-Car color management module connected to R-Car DU video channels.
+ It provides image enhancement functions such as 1-D look-up tables (LUT),
+ 3-D look-up tables (CLU), 1D-histogram generation (HGO), and color
+ space conversion (CSC).
+
+properties:
+ compatible:
+oneOf:
+ - items:
+- enum:
+ - renesas,r8a7795-cmm
+ - renesas,r8a7796-cmm
+ - renesas,r8a77965-cmm
+ - renesas,r8a77990-cmm
+ - renesas,r8a77995-cmm
+- const: renesas,rcar-gen3-cmm
+ - items:
+- const: renesas,rcar-gen2-cmm
+
+ reg:
+maxItems: 1
+
+ clocks:
+maxItems: 1
+
+ resets:
+maxItems: 1
+
+ power-domains:
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - resets
+ - power-domains
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+
+cmm0: cmm@fea4 {
+ compatible = "renesas,r8a7796-cmm",
+ "renesas,rcar-gen3-cmm";
+ reg = <0 0xfea4 0 0x1000>;
+ power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
+ clocks = <&cpg CPG_MOD 711>;
+ resets = <&cpg 711>;
+};
--
2.23.0
[PATCH v6 8/8] drm: rcar-du: kms: Expand comment in vsps parsing routine
Expand comment in the 'vsps' parsing routine to specify the LIF channel index defaults to 0 in case the second cell of the property is not specified to remain compatible with older DT bindings. Reviewed-by: Kieran Bingham Reviewed-by: Laurent Pinchart Signed-off-by: Jacopo Mondi --- drivers/gpu/drm/rcar-du/rcar_du_kms.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c b/drivers/gpu/drm/rcar-du/rcar_du_kms.c index 7c9fb5860e54..186422ac552b 100644 --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c @@ -587,7 +587,11 @@ static int rcar_du_vsps_init(struct rcar_du_device *rcdu) vsps[j].crtcs_mask |= BIT(i); - /* Store the VSP pointer and pipe index in the CRTC. */ + /* +* Store the VSP pointer and pipe index in the CRTC. If the +* second cell of the 'vsps' specifier isn't present, default +* to 0 to remain compatible with older DT bindings. +*/ rcdu->crtcs[i].vsp = &rcdu->vsps[j]; rcdu->crtcs[i].vsp_pipe = cells >= 1 ? args.args[0] : 0; } -- 2.23.0
[PATCH v6 4/8] drm: rcar-du: kms: Initialize CMM instances
Implement device tree parsing to collect the available CMM instances
described by the 'renesas,cmms' property. Associate CMMs with CRTCs and
store a mask of active CMMs in the DU group for later enablement.
Enforce the probe and suspend/resume ordering of DU and CMM by creating
a stateless device link between the two.
Reviewed-by: Kieran Bingham
Reviewed-by: Laurent Pinchart
Signed-off-by: Jacopo Mondi
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 6 ++
drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 2 +
drivers/gpu/drm/rcar-du/rcar_du_drv.h | 2 +
drivers/gpu/drm/rcar-du/rcar_du_group.h | 2 +
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 76 +
5 files changed, 88 insertions(+)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 2da46e3dc4ae..23f1d6cc1719 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -1194,6 +1194,12 @@ int rcar_du_crtc_create(struct rcar_du_group *rgrp,
unsigned int swindex,
if (ret < 0)
return ret;
+ /* CMM might be disabled for this CRTC. */
+ if (rcdu->cmms[swindex]) {
+ rcrtc->cmm = rcdu->cmms[swindex];
+ rgrp->cmms_mask |= BIT(hwindex % 2);
+ }
+
drm_crtc_helper_add(crtc, &crtc_helper_funcs);
/* Start with vertical blanking interrupt reporting disabled. */
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
index 3b7fc668996f..5f2940c42225 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
@@ -39,6 +39,7 @@ struct rcar_du_vsp;
* @vblank_wait: wait queue used to signal vertical blanking
* @vblank_count: number of vertical blanking interrupts to wait for
* @group: CRTC group this CRTC belongs to
+ * @cmm: CMM associated with this CRTC
* @vsp: VSP feeding video to this CRTC
* @vsp_pipe: index of the VSP pipeline feeding video to this CRTC
* @writeback: the writeback connector
@@ -64,6 +65,7 @@ struct rcar_du_crtc {
unsigned int vblank_count;
struct rcar_du_group *group;
+ struct platform_device *cmm;
struct rcar_du_vsp *vsp;
unsigned int vsp_pipe;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
index 1327cd0df90a..61504c54e2ec 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
@@ -13,6 +13,7 @@
#include
#include
+#include "rcar_cmm.h"
#include "rcar_du_crtc.h"
#include "rcar_du_group.h"
#include "rcar_du_vsp.h"
@@ -85,6 +86,7 @@ struct rcar_du_device {
struct rcar_du_encoder *encoders[RCAR_DU_OUTPUT_MAX];
struct rcar_du_group groups[RCAR_DU_MAX_GROUPS];
+ struct platform_device *cmms[RCAR_DU_MAX_CRTCS];
struct rcar_du_vsp vsps[RCAR_DU_MAX_VSPS];
struct {
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_group.h
b/drivers/gpu/drm/rcar-du/rcar_du_group.h
index 87950c1f6a52..e9906609c635 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_group.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_group.h
@@ -22,6 +22,7 @@ struct rcar_du_device;
* @mmio_offset: registers offset in the device memory map
* @index: group index
* @channels_mask: bitmask of populated DU channels in this group
+ * @cmms_mask: bitmask of available CMMs in this group
* @num_crtcs: number of CRTCs in this group (1 or 2)
* @use_count: number of users of the group (rcar_du_group_(get|put))
* @used_crtcs: number of CRTCs currently in use
@@ -37,6 +38,7 @@ struct rcar_du_group {
unsigned int index;
unsigned int channels_mask;
+ unsigned int cmms_mask;
unsigned int num_crtcs;
unsigned int use_count;
unsigned int used_crtcs;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 2dc9caee8767..7c9fb5860e54 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -17,7 +17,9 @@
#include
#include
+#include
#include
+#include
#include
#include "rcar_du_crtc.h"
@@ -614,6 +616,75 @@ static int rcar_du_vsps_init(struct rcar_du_device *rcdu)
return ret;
}
+static int rcar_du_cmm_init(struct rcar_du_device *rcdu)
+{
+ const struct device_node *np = rcdu->dev->of_node;
+ unsigned int i;
+ int cells;
+
+ cells = of_property_count_u32_elems(np, "renesas,cmms");
+ if (cells == -EINVAL)
+ return 0;
+
+ if (cells > rcdu->num_crtcs) {
+ dev_err(rcdu->dev,
+ "Invalid number of entries in 'renesas,cmms'\n");
+ return -EINVAL;
+ }
+
+ for (i = 0; i < cells; ++i) {
+ struct platform_device *pdev;
+ struct device_link *link;
+
[PATCH v6 2/8] dt-bindings: display, renesas,du: Document cmms property
Document the newly added 'cmms' property which accepts a list of phandle
and channel index pairs that point to the CMM units available for each
Display Unit output video channel.
Reviewed-by: Rob Herring
Reviewed-by: Kieran Bingham
Reviewed-by: Laurent Pinchart
Signed-off-by: Jacopo Mondi
---
Documentation/devicetree/bindings/display/renesas,du.txt | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/renesas,du.txt
b/Documentation/devicetree/bindings/display/renesas,du.txt
index c97dfacad281..3d9809b486b6 100644
--- a/Documentation/devicetree/bindings/display/renesas,du.txt
+++ b/Documentation/devicetree/bindings/display/renesas,du.txt
@@ -45,6 +45,10 @@ Required Properties:
instance that serves the DU channel, and the channel index identifies the
LIF instance in that VSP.
+ - renesas,cmms: A list of phandles to the CMM instances present in the SoC,
+one for each available DU channel. The property shall not be specified for
+SoCs that do not provide any CMM (such as V3M and V3H).
+
Required nodes:
The connections to the DU output video ports are modeled using the OF graph
@@ -91,6 +95,7 @@ Example: R8A7795 (R-Car H3) ES2.0 DU
<&cpg CPG_MOD 721>;
clock-names = "du.0", "du.1", "du.2", "du.3";
vsps = <&vspd0 0>, <&vspd1 0>, <&vspd2 0>, <&vspd0 1>;
+ renesas,cmms = <&cmm0>, <&cmm1>, <&cmm2>, <&cmm3>;
ports {
#address-cells = <1>;
--
2.23.0
[PATCH v6 7/8] arm64: dts: renesas: Add CMM units to Gen3 SoCs
Add CMM units to Renesas R-Car Gen3 SoC that support it, and reference them
from the Display Unit they are connected to.
Sort the 'vsps', 'renesas,cmm' and 'status' properties in the DU unit
consistently in all the involved DTS.
Reviewed-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
Signed-off-by: Jacopo Mondi
---
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 39 +++
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 31 +-
arch/arm64/boot/dts/renesas/r8a77965.dtsi | 31 +-
arch/arm64/boot/dts/renesas/r8a77990.dtsi | 21
arch/arm64/boot/dts/renesas/r8a77995.dtsi | 21
5 files changed, 141 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 6675462f7585..e16757af8c27 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -2939,6 +2939,42 @@
iommus = <&ipmmu_vi1 10>;
};
+ cmm0: cmm@fea4 {
+ compatible = "renesas,r8a7795-cmm",
+"renesas,rcar-gen3-cmm";
+ reg = <0 0xfea4 0 0x1000>;
+ power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
+ clocks = <&cpg CPG_MOD 711>;
+ resets = <&cpg 711>;
+ };
+
+ cmm1: cmm@fea5 {
+ compatible = "renesas,r8a7795-cmm",
+"renesas,rcar-gen3-cmm";
+ reg = <0 0xfea5 0 0x1000>;
+ power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
+ clocks = <&cpg CPG_MOD 710>;
+ resets = <&cpg 710>;
+ };
+
+ cmm2: cmm@fea6 {
+ compatible = "renesas,r8a7795-cmm",
+"renesas,rcar-gen3-cmm";
+ reg = <0 0xfea6 0 0x1000>;
+ power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
+ clocks = <&cpg CPG_MOD 709>;
+ resets = <&cpg 709>;
+ };
+
+ cmm3: cmm@fea7 {
+ compatible = "renesas,r8a7795-cmm",
+"renesas,rcar-gen3-cmm";
+ reg = <0 0xfea7 0 0x1000>;
+ power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
+ clocks = <&cpg CPG_MOD 708>;
+ resets = <&cpg 708>;
+ };
+
csi20: csi2@fea8 {
compatible = "renesas,r8a7795-csi2";
reg = <0 0xfea8 0 0x1>;
@@ -3142,7 +3178,10 @@
<&cpg CPG_MOD 722>,
<&cpg CPG_MOD 721>;
clock-names = "du.0", "du.1", "du.2", "du.3";
+
+ renesas,cmms = <&cmm0>, <&cmm1>, <&cmm2>, <&cmm3>;
vsps = <&vspd0 0>, <&vspd1 0>, <&vspd2 0>, <&vspd0 1>;
+
status = "disabled";
ports {
diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 822c96601d3c..597c47f3f994 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -2641,6 +2641,33 @@
renesas,fcp = <&fcpvi0>;
};
+ cmm0: cmm@fea4 {
+ compatible = "renesas,r8a7796-cmm",
+"renesas,rcar-gen3-cmm";
+ reg = <0 0xfea4 0 0x1000>;
+ power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
+ clocks = <&cpg CPG_MOD 711>;
+ resets = <&cpg 711>;
+ };
+
+ cmm1: cmm@fea5 {
+ compatible = "renesas,r8a7796-cmm",
+"renesas,rcar-gen3-cmm";
+ reg = <0 0xfea5 0 0x1000>;
+ power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
+ clocks = <&cpg CPG_MOD 710>;
+ resets = <&cpg 710>;
+ };
+
+ cmm2: cmm@fea6 {
+ compatible = &qu
[PATCH v6 3/8] drm: rcar-du: Add support for CMM
Add a driver for the R-Car Display Unit Color Correction Module.
In most of Gen3 SoCs, each DU output channel is provided with a CMM unit
to perform image enhancement and color correction.
Add support for CMM through a driver that supports configuration of
the 1-dimensional LUT table. More advanced CMM features will be
implemented on top of this initial one.
Reviewed-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
Signed-off-by: Jacopo Mondi
---
drivers/gpu/drm/rcar-du/Kconfig| 7 +
drivers/gpu/drm/rcar-du/Makefile | 1 +
drivers/gpu/drm/rcar-du/rcar_cmm.c | 212 +
drivers/gpu/drm/rcar-du/rcar_cmm.h | 58
4 files changed, 278 insertions(+)
create mode 100644 drivers/gpu/drm/rcar-du/rcar_cmm.c
create mode 100644 drivers/gpu/drm/rcar-du/rcar_cmm.h
diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
index 1529849e217e..539d232790d1 100644
--- a/drivers/gpu/drm/rcar-du/Kconfig
+++ b/drivers/gpu/drm/rcar-du/Kconfig
@@ -13,6 +13,13 @@ config DRM_RCAR_DU
Choose this option if you have an R-Car chipset.
If M is selected the module will be called rcar-du-drm.
+config DRM_RCAR_CMM
+ bool "R-Car DU Color Management Module (CMM) Support"
+ depends on DRM && OF
+ depends on DRM_RCAR_DU
+ help
+ Enable support for R-Car Color Management Module (CMM).
+
config DRM_RCAR_DW_HDMI
tristate "R-Car DU Gen3 HDMI Encoder Support"
depends on DRM && OF
diff --git a/drivers/gpu/drm/rcar-du/Makefile b/drivers/gpu/drm/rcar-du/Makefile
index 6c2ed9c46467..4d1187ccc3e5 100644
--- a/drivers/gpu/drm/rcar-du/Makefile
+++ b/drivers/gpu/drm/rcar-du/Makefile
@@ -15,6 +15,7 @@ rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS) += rcar_du_of.o \
rcar-du-drm-$(CONFIG_DRM_RCAR_VSP) += rcar_du_vsp.o
rcar-du-drm-$(CONFIG_DRM_RCAR_WRITEBACK) += rcar_du_writeback.o
+obj-$(CONFIG_DRM_RCAR_CMM) += rcar_cmm.o
obj-$(CONFIG_DRM_RCAR_DU) += rcar-du-drm.o
obj-$(CONFIG_DRM_RCAR_DW_HDMI) += rcar_dw_hdmi.o
obj-$(CONFIG_DRM_RCAR_LVDS)+= rcar_lvds.o
diff --git a/drivers/gpu/drm/rcar-du/rcar_cmm.c
b/drivers/gpu/drm/rcar-du/rcar_cmm.c
new file mode 100644
index ..4170626208cf
--- /dev/null
+++ b/drivers/gpu/drm/rcar-du/rcar_cmm.c
@@ -0,0 +1,212 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * rcar_cmm.c -- R-Car Display Unit Color Management Module
+ *
+ * Copyright (C) 2019 Jacopo Mondi
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "rcar_cmm.h"
+
+#define CM2_LUT_CTRL 0x
+#define CM2_LUT_CTRL_LUT_ENBIT(0)
+#define CM2_LUT_TBL_BASE 0x0600
+#define CM2_LUT_TBL(__i) (CM2_LUT_TBL_BASE + (__i) * 4)
+
+struct rcar_cmm {
+ void __iomem *base;
+
+ /*
+* @lut:1D-LUT state
+* @lut.enabled:1D-LUT enabled flag
+*/
+ struct {
+ bool enabled;
+ } lut;
+};
+
+static inline int rcar_cmm_read(struct rcar_cmm *rcmm, u32 reg)
+{
+ return ioread32(rcmm->base + reg);
+}
+
+static inline void rcar_cmm_write(struct rcar_cmm *rcmm, u32 reg, u32 data)
+{
+ iowrite32(data, rcmm->base + reg);
+}
+
+/*
+ * rcar_cmm_lut_write() - Scale the DRM LUT table entries to hardware precision
+ * and write to the CMM registers
+ * @rcmm: Pointer to the CMM device
+ * @drm_lut: Pointer to the DRM LUT table
+ */
+static void rcar_cmm_lut_write(struct rcar_cmm *rcmm,
+ const struct drm_color_lut *drm_lut)
+{
+ unsigned int i;
+
+ for (i = 0; i < CM2_LUT_SIZE; ++i) {
+ u32 entry = drm_color_lut_extract(drm_lut[i].red, 8) << 16
+ | drm_color_lut_extract(drm_lut[i].green, 8) << 8
+ | drm_color_lut_extract(drm_lut[i].blue, 8);
+
+ rcar_cmm_write(rcmm, CM2_LUT_TBL(i), entry);
+ }
+}
+
+/*
+ * rcar_cmm_setup() - Configure the CMM unit
+ * @pdev: The platform device associated with the CMM instance
+ * @config: The CMM unit configuration
+ *
+ * Configure the CMM unit with the given configuration. Currently enabling,
+ * disabling and programming of the 1-D LUT unit is supported.
+ *
+ * TODO: Add support for LUT double buffer operations to avoid updating the
+ * LUT table entries while a frame is being displayed.
+ */
+int rcar_cmm_setup(struct platform_device *pdev,
+ const struct rcar_cmm_config *config)
+{
+ struct rcar_cmm *rcmm = platform_get_drvdata(pdev);
+
+ /* Disable LUT if no table is provided. */
+ if (!config->lut.table) {
+ if (rcmm->lut.enabled) {
+ rcar_cmm_write(rcmm, CM2_LUT_CTRL, 0);
+ rcmm->lut.enabled = false;
+ }
+
+ return 0;
+ }
+
+ /* Enable L
[PATCH v6 0/8] drm: rcar-du: Add Color Management Module (CMM)
Minimal increment to the CMM series, this time should really be the last one. Just missing Rob's ack on [1/8] and Laurent's one on [5/8]. Changelog is minimal: CMM - Remove the cmm_config.enable flag. The cmm_config.table field validity is used to enable/disable the LUT operations - Expand comments as suggested by Laurent CRTC - use drm_color_lut_size() to check the LUT table size - Inline calls to rcar_cmm_enable()/disable() - Add TODO entries as suggested by Laurent For the record, the full series changelog is available at: https://paste.debian.net/1107427/ v5 from yesterday with informations on testing is available at: https://lkml.org/lkml/2019/10/15/337 Geert will you collect for DTS patches for the next release? I assume the DU changes go through Laurent instead ? Thanks j Jacopo Mondi (8): dt-bindings: display: renesas,cmm: Add R-Car CMM documentation dt-bindings: display, renesas,du: Document cmms property drm: rcar-du: Add support for CMM drm: rcar-du: kms: Initialize CMM instances drm: rcar-du: crtc: Control CMM operations drm: rcar-du: crtc: Register GAMMA_LUT properties arm64: dts: renesas: Add CMM units to Gen3 SoCs drm: rcar-du: kms: Expand comment in vsps parsing routine .../bindings/display/renesas,cmm.yaml | 67 ++ .../bindings/display/renesas,du.txt | 5 + arch/arm64/boot/dts/renesas/r8a7795.dtsi | 39 arch/arm64/boot/dts/renesas/r8a7796.dtsi | 31 ++- arch/arm64/boot/dts/renesas/r8a77965.dtsi | 31 ++- arch/arm64/boot/dts/renesas/r8a77990.dtsi | 21 ++ arch/arm64/boot/dts/renesas/r8a77995.dtsi | 21 ++ drivers/gpu/drm/rcar-du/Kconfig | 7 + drivers/gpu/drm/rcar-du/Makefile | 1 + drivers/gpu/drm/rcar-du/rcar_cmm.c| 212 ++ drivers/gpu/drm/rcar-du/rcar_cmm.h| 58 + drivers/gpu/drm/rcar-du/rcar_du_crtc.c| 65 ++ drivers/gpu/drm/rcar-du/rcar_du_crtc.h| 2 + drivers/gpu/drm/rcar-du/rcar_du_drv.h | 2 + drivers/gpu/drm/rcar-du/rcar_du_group.c | 10 + drivers/gpu/drm/rcar-du/rcar_du_group.h | 2 + drivers/gpu/drm/rcar-du/rcar_du_kms.c | 82 ++- drivers/gpu/drm/rcar-du/rcar_du_regs.h| 5 + 18 files changed, 658 insertions(+), 3 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/renesas,cmm.yaml create mode 100644 drivers/gpu/drm/rcar-du/rcar_cmm.c create mode 100644 drivers/gpu/drm/rcar-du/rcar_cmm.h -- 2.23.0
Re: [PATCH v5 5/8] drm: rcar-du: crtc: Control CMM operations
Hi Laurent,
On Tue, Oct 15, 2019 at 08:54:22PM +0300, Laurent Pinchart wrote:
> Hi Jacopo,
>
> Thank you for the patch.
>
> On Tue, Oct 15, 2019 at 03:37:52PM +0200, Jacopo Mondi wrote:
> > On Tue, Oct 15, 2019 at 02:15:35PM +0100, Kieran Bingham wrote:
> > > On 15/10/2019 11:46, Jacopo Mondi wrote:
> > > > Implement CMM handling in the crtc begin and enable atomic callbacks,
> > > > and enable CMM unit through the Display Extensional Functions
> > >
> > > Extensional ?
> > >
> > > Perhaps this should just be Display Extension Functions?
> > > Wow - that's actually what they call it in the data-sheet.
> > >
> > > > register at group setup time.
> > >
> > > Only a trivial extra blank line below that I can find... so
> > >
> > > Reviewed-by: Kieran Bingham
> > >
> > > > Signed-off-by: Jacopo Mondi
> > > > ---
> > > > drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 79 +
> > > > drivers/gpu/drm/rcar-du/rcar_du_group.c | 5 ++
> > > > drivers/gpu/drm/rcar-du/rcar_du_regs.h | 5 ++
> > > > 3 files changed, 89 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> > > > b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> > > > index 23f1d6cc1719..4bc50a3f4a00 100644
> > > > --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> > > > +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> > > > @@ -21,6 +21,7 @@
> > > > #include
> > > > #include
> > > >
> > > > +#include "rcar_cmm.h"
> > > > #include "rcar_du_crtc.h"
> > > > #include "rcar_du_drv.h"
> > > > #include "rcar_du_encoder.h"
> > > > @@ -474,6 +475,70 @@ static void rcar_du_crtc_wait_page_flip(struct
> > > > rcar_du_crtc *rcrtc)
> > > > rcar_du_crtc_finish_page_flip(rcrtc);
> > > > }
> > > >
> > > > +/*
> > > > -
> > > > + * Color Management Module (CMM)
> > > > + */
>
> Missing blank line.
>
> > > > +static int rcar_du_cmm_enable(struct drm_crtc *crtc)
> > > > +{
> > > > + struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
> > > > +
> > > > + if (!rcrtc->cmm)
> > > > + return 0;
> > > > +
> > > > + return rcar_cmm_enable(rcrtc->cmm);
> > > > +}
> > > > +
> > > > +static void rcar_du_cmm_disable(struct drm_crtc *crtc)
> > > > +{
> > > > + struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
> > > > +
> > > > + if (!rcrtc->cmm)
> > > > + return;
> > > > +
> > > > + rcar_cmm_disable(rcrtc->cmm);
> > > > +}
>
> I think I would have inlined those two functions in their only call site
> as
>
> if (rcrtc->cmm)
> rcar_cmm_enable(rcrtc->cmm);
>
> but that's up to you.
>
Mmm, I preferred to avoid if() in the caller, but as this is a small
increment to an existing big driver, I'll go for the most consistent
way
> > > > +
> > > > +static int rcar_du_cmm_check(struct drm_crtc *crtc,
> > > > +struct drm_crtc_state *state)
> > > > +{
> > > > + struct drm_property_blob *drm_lut = state->gamma_lut;
> > > > + struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
> > > > + struct device *dev = rcrtc->dev->dev;
> > > > +
> > > > + if (!rcrtc->cmm || !drm_lut)
> > > > + return 0;
> > > > +
> > > > + /* We only accept fully populated LUT tables. */
> > > > + if (CM2_LUT_SIZE * sizeof(struct drm_color_lut) !=
> > > > + drm_lut->length) {
>
> How about
>
> if (drm_color_lut_size(drm_lut) != CM2_LUT_SIZE)
>
> ?
>
Better :)
> > > > + dev_err(dev, "invalid gamma lut size: %lu bytes\n",
> > > > + drm_lut->length);
> > > > + return -EINVAL;
> > > > + }
> > > > +
> > > > + return 0;
> > > > +}
> > > > +
> > > > +static void rcar_du_cmm_setup(struct drm_crtc *crtc)
> > &
Re: [PATCH v5 5/8] drm: rcar-du: crtc: Control CMM operations
Hi Kieran,
On Tue, Oct 15, 2019 at 02:15:35PM +0100, Kieran Bingham wrote:
> Hi Jacopo,
>
> On 15/10/2019 11:46, Jacopo Mondi wrote:
> > Implement CMM handling in the crtc begin and enable atomic callbacks,
> > and enable CMM unit through the Display Extensional Functions
>
> Extensional ?
>
> Perhaps this should just be Display Extension Functions?
> Wow - that's actually what they call it in the data-sheet.
>
> > register at group setup time.
> >
>
> Only a trivial extra blank line below that I can find... so
>
> Reviewed-by: Kieran Bingham
>
> > Signed-off-by: Jacopo Mondi
> > ---
> > drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 79 +
> > drivers/gpu/drm/rcar-du/rcar_du_group.c | 5 ++
> > drivers/gpu/drm/rcar-du/rcar_du_regs.h | 5 ++
> > 3 files changed, 89 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> > index 23f1d6cc1719..4bc50a3f4a00 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> > @@ -21,6 +21,7 @@
> > #include
> > #include
> >
> > +#include "rcar_cmm.h"
> > #include "rcar_du_crtc.h"
> > #include "rcar_du_drv.h"
> > #include "rcar_du_encoder.h"
> > @@ -474,6 +475,70 @@ static void rcar_du_crtc_wait_page_flip(struct
> > rcar_du_crtc *rcrtc)
> > rcar_du_crtc_finish_page_flip(rcrtc);
> > }
> >
> > +/*
> > -
> > + * Color Management Module (CMM)
> > + */
> > +static int rcar_du_cmm_enable(struct drm_crtc *crtc)
> > +{
> > + struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
> > +
> > + if (!rcrtc->cmm)
> > + return 0;
> > +
> > + return rcar_cmm_enable(rcrtc->cmm);
> > +}
> > +
> > +static void rcar_du_cmm_disable(struct drm_crtc *crtc)
> > +{
> > + struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
> > +
> > + if (!rcrtc->cmm)
> > + return;
> > +
> > + rcar_cmm_disable(rcrtc->cmm);
> > +}
> > +
> > +static int rcar_du_cmm_check(struct drm_crtc *crtc,
> > +struct drm_crtc_state *state)
> > +{
> > + struct drm_property_blob *drm_lut = state->gamma_lut;
> > + struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
> > + struct device *dev = rcrtc->dev->dev;
> > +
> > + if (!rcrtc->cmm || !drm_lut)
> > + return 0;
> > +
> > + /* We only accept fully populated LUT tables. */
> > + if (CM2_LUT_SIZE * sizeof(struct drm_color_lut) !=
> > + drm_lut->length) {
> > + dev_err(dev, "invalid gamma lut size: %lu bytes\n",
> > + drm_lut->length);
> > + return -EINVAL;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static void rcar_du_cmm_setup(struct drm_crtc *crtc)
> > +{
> > + struct drm_property_blob *drm_lut = crtc->state->gamma_lut;
> > + struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
> > + struct rcar_cmm_config cmm_config = {};
> > +
> > + if (!rcrtc->cmm)
> > + return;
> > +
> > + if (drm_lut) {
> > + cmm_config.lut.enable = true;
> > + cmm_config.lut.table = (struct drm_color_lut *)drm_lut->data;
> > +
> > + } else {
> > + cmm_config.lut.enable = false;
> > + }
> > +
> > + rcar_cmm_setup(rcrtc->cmm, &cmm_config);
> > +}
> > +
> > /*
> > -
> > * Start/Stop and Suspend/Resume
> > */
> > @@ -619,6 +684,8 @@ static void rcar_du_crtc_stop(struct rcar_du_crtc
> > *rcrtc)
> > if (rcar_du_has(rcrtc->dev, RCAR_DU_FEATURE_VSP1_SOURCE))
> > rcar_du_vsp_disable(rcrtc);
> >
> > + rcar_du_cmm_disable(crtc);
> > +
> > /*
> > * Select switch sync mode. This stops display operation and configures
> > * the HSYNC and VSYNC signals as inputs.
> > @@ -631,6 +698,7 @@ static void rcar_du_crtc_stop(struct rcar_du_crtc
> > *rcrtc)
> >DSYSR_TVM_SWITCH);
> >
> > rcar_du_group_start_stop(rcrtc->group, false);
> > +
>
> Extra blank line...
>
Thanks for spotting this. I'm quite sure I run checkpatch (I ju
Re: [PATCH v5 3/8] drm: rcar-du: Add support for CMM
Hi Kieran, thanks for review
On Tue, Oct 15, 2019 at 12:53:55PM +0100, Kieran Bingham wrote:
> Hi Jacopo,
>
> On 15/10/2019 11:46, Jacopo Mondi wrote:
> > Add a driver for the R-Car Display Unit Color Correction Module.
> >
> > In most of Gen3 SoCs, each DU output channel is provided with a CMM unit
> > to perform image enhancement and color correction.
> >
> > Add support for CMM through a driver that supports configuration of
> > the 1-dimensional LUT table. More advanced CMM features will be
> > implemented on top of this initial one.
> >
>
> This is looking good to me.
>
> I have patches which start to add CLU on top of this, which refactor
> things slightly - but I don't think that refactoring needs to be in this
> series, and this version is independent and looks good ... thus:
>
> Reviewed-by: Kieran Bingham
>
>
> > Signed-off-by: Jacopo Mondi
> > ---
> > drivers/gpu/drm/rcar-du/Kconfig| 7 +
> > drivers/gpu/drm/rcar-du/Makefile | 1 +
> > drivers/gpu/drm/rcar-du/rcar_cmm.c | 198 +
> > drivers/gpu/drm/rcar-du/rcar_cmm.h | 60 +
> > 4 files changed, 266 insertions(+)
> > create mode 100644 drivers/gpu/drm/rcar-du/rcar_cmm.c
> > create mode 100644 drivers/gpu/drm/rcar-du/rcar_cmm.h
> >
> > diff --git a/drivers/gpu/drm/rcar-du/Kconfig
> > b/drivers/gpu/drm/rcar-du/Kconfig
> > index 1529849e217e..539d232790d1 100644
> > --- a/drivers/gpu/drm/rcar-du/Kconfig
> > +++ b/drivers/gpu/drm/rcar-du/Kconfig
> > @@ -13,6 +13,13 @@ config DRM_RCAR_DU
> > Choose this option if you have an R-Car chipset.
> > If M is selected the module will be called rcar-du-drm.
> >
> > +config DRM_RCAR_CMM
> > + bool "R-Car DU Color Management Module (CMM) Support"
> > + depends on DRM && OF
> > + depends on DRM_RCAR_DU
>
>
> DRM_RCAR_DU already depends on both DRM && OF, so I wonder if those are
> needed to be specified explicitly.
>
> Doesn't hurt of course, but I see DRM_RCAR_DW_HDMI does the same, and so
> does DRM_RCAR_LVDS, so I don't think you need to remove it.
>
I did the same as it is done for HDMI and LVDS here. The extra
dependencies could be dropped yes, I chose to be consistent.
> > + help
> > + Enable support for R-Car Color Management Module (CMM).
> > +
> > config DRM_RCAR_DW_HDMI
> > tristate "R-Car DU Gen3 HDMI Encoder Support"
> > depends on DRM && OF
> > diff --git a/drivers/gpu/drm/rcar-du/Makefile
> > b/drivers/gpu/drm/rcar-du/Makefile
> > index 6c2ed9c46467..4d1187ccc3e5 100644
> > --- a/drivers/gpu/drm/rcar-du/Makefile
> > +++ b/drivers/gpu/drm/rcar-du/Makefile
> > @@ -15,6 +15,7 @@ rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS) += rcar_du_of.o
> > \
> > rcar-du-drm-$(CONFIG_DRM_RCAR_VSP) += rcar_du_vsp.o
> > rcar-du-drm-$(CONFIG_DRM_RCAR_WRITEBACK) += rcar_du_writeback.o
> >
> > +obj-$(CONFIG_DRM_RCAR_CMM) += rcar_cmm.o
> > obj-$(CONFIG_DRM_RCAR_DU) += rcar-du-drm.o
> > obj-$(CONFIG_DRM_RCAR_DW_HDMI) += rcar_dw_hdmi.o
> > obj-$(CONFIG_DRM_RCAR_LVDS)+= rcar_lvds.o
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_cmm.c
> > b/drivers/gpu/drm/rcar-du/rcar_cmm.c
> > new file mode 100644
> > index ..9675a8587dee
> > --- /dev/null
> > +++ b/drivers/gpu/drm/rcar-du/rcar_cmm.c
> > @@ -0,0 +1,198 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * rcar_cmm.c -- R-Car Display Unit Color Management Module
> > + *
> > + * Copyright (C) 2019 Jacopo Mondi
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +
> > +#include "rcar_cmm.h"
> > +
> > +#define CM2_LUT_CTRL 0x
> > +#define CM2_LUT_CTRL_LUT_ENBIT(0)
> > +#define CM2_LUT_TBL_BASE 0x0600
> > +#define CM2_LUT_TBL(__i) (CM2_LUT_TBL_BASE + (__i) * 4)
> > +
> > +struct rcar_cmm {
> > + void __iomem *base;
> > +
> > + /*
> > +* @lut:1D-LUT status
> > +* @lut.enabled:1D-LUT enabled flag
> > +*/
> > + struct {
> > + bool enabled;
> > + } lut;
>
> This used to be a more complex structure in an earlier version storing a
> cached version of the table. Now that the cached entry is removed, does
> this need to be such a complex structure rather than just say, a bool
> lut_enabled?
>
>
[PATCH v5 8/8] drm: rcar-du: kms: Expand comment in vsps parsing routine
Expand comment in the 'vsps' parsing routine to specify the LIF channel index defaults to 0 in case the second cell of the property is not specified to remain compatible with older DT bindings. Reviewed-by: Laurent Pinchart Signed-off-by: Jacopo Mondi --- drivers/gpu/drm/rcar-du/rcar_du_kms.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c b/drivers/gpu/drm/rcar-du/rcar_du_kms.c index 7c9fb5860e54..186422ac552b 100644 --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c @@ -587,7 +587,11 @@ static int rcar_du_vsps_init(struct rcar_du_device *rcdu) vsps[j].crtcs_mask |= BIT(i); - /* Store the VSP pointer and pipe index in the CRTC. */ + /* +* Store the VSP pointer and pipe index in the CRTC. If the +* second cell of the 'vsps' specifier isn't present, default +* to 0 to remain compatible with older DT bindings. +*/ rcdu->crtcs[i].vsp = &rcdu->vsps[j]; rcdu->crtcs[i].vsp_pipe = cells >= 1 ? args.args[0] : 0; } -- 2.23.0
[PATCH v5 7/8] arm64: dts: renesas: Add CMM units to Gen3 SoCs
Add CMM units to Renesas R-Car Gen3 SoC that support it, and reference them
from the Display Unit they are connected to.
Sort the 'vsps', 'renesas,cmm' and 'status' properties in the DU unit
consistently in all the involved DTS.
Signed-off-by: Jacopo Mondi
---
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 39 +++
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 31 +-
arch/arm64/boot/dts/renesas/r8a77965.dtsi | 31 +-
arch/arm64/boot/dts/renesas/r8a77990.dtsi | 21
arch/arm64/boot/dts/renesas/r8a77995.dtsi | 21
5 files changed, 141 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 6675462f7585..e16757af8c27 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -2939,6 +2939,42 @@
iommus = <&ipmmu_vi1 10>;
};
+ cmm0: cmm@fea4 {
+ compatible = "renesas,r8a7795-cmm",
+"renesas,rcar-gen3-cmm";
+ reg = <0 0xfea4 0 0x1000>;
+ power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
+ clocks = <&cpg CPG_MOD 711>;
+ resets = <&cpg 711>;
+ };
+
+ cmm1: cmm@fea5 {
+ compatible = "renesas,r8a7795-cmm",
+"renesas,rcar-gen3-cmm";
+ reg = <0 0xfea5 0 0x1000>;
+ power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
+ clocks = <&cpg CPG_MOD 710>;
+ resets = <&cpg 710>;
+ };
+
+ cmm2: cmm@fea6 {
+ compatible = "renesas,r8a7795-cmm",
+"renesas,rcar-gen3-cmm";
+ reg = <0 0xfea6 0 0x1000>;
+ power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
+ clocks = <&cpg CPG_MOD 709>;
+ resets = <&cpg 709>;
+ };
+
+ cmm3: cmm@fea7 {
+ compatible = "renesas,r8a7795-cmm",
+"renesas,rcar-gen3-cmm";
+ reg = <0 0xfea7 0 0x1000>;
+ power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
+ clocks = <&cpg CPG_MOD 708>;
+ resets = <&cpg 708>;
+ };
+
csi20: csi2@fea8 {
compatible = "renesas,r8a7795-csi2";
reg = <0 0xfea8 0 0x1>;
@@ -3142,7 +3178,10 @@
<&cpg CPG_MOD 722>,
<&cpg CPG_MOD 721>;
clock-names = "du.0", "du.1", "du.2", "du.3";
+
+ renesas,cmms = <&cmm0>, <&cmm1>, <&cmm2>, <&cmm3>;
vsps = <&vspd0 0>, <&vspd1 0>, <&vspd2 0>, <&vspd0 1>;
+
status = "disabled";
ports {
diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 822c96601d3c..597c47f3f994 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -2641,6 +2641,33 @@
renesas,fcp = <&fcpvi0>;
};
+ cmm0: cmm@fea4 {
+ compatible = "renesas,r8a7796-cmm",
+"renesas,rcar-gen3-cmm";
+ reg = <0 0xfea4 0 0x1000>;
+ power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
+ clocks = <&cpg CPG_MOD 711>;
+ resets = <&cpg 711>;
+ };
+
+ cmm1: cmm@fea5 {
+ compatible = "renesas,r8a7796-cmm",
+"renesas,rcar-gen3-cmm";
+ reg = <0 0xfea5 0 0x1000>;
+ power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
+ clocks = <&cpg CPG_MOD 710>;
+ resets = <&cpg 710>;
+ };
+
+ cmm2: cmm@fea6 {
+ compatible = "renesas,r8a7796-cmm",
+
[PATCH v5 3/8] drm: rcar-du: Add support for CMM
Add a driver for the R-Car Display Unit Color Correction Module.
In most of Gen3 SoCs, each DU output channel is provided with a CMM unit
to perform image enhancement and color correction.
Add support for CMM through a driver that supports configuration of
the 1-dimensional LUT table. More advanced CMM features will be
implemented on top of this initial one.
Signed-off-by: Jacopo Mondi
---
drivers/gpu/drm/rcar-du/Kconfig| 7 +
drivers/gpu/drm/rcar-du/Makefile | 1 +
drivers/gpu/drm/rcar-du/rcar_cmm.c | 198 +
drivers/gpu/drm/rcar-du/rcar_cmm.h | 60 +
4 files changed, 266 insertions(+)
create mode 100644 drivers/gpu/drm/rcar-du/rcar_cmm.c
create mode 100644 drivers/gpu/drm/rcar-du/rcar_cmm.h
diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
index 1529849e217e..539d232790d1 100644
--- a/drivers/gpu/drm/rcar-du/Kconfig
+++ b/drivers/gpu/drm/rcar-du/Kconfig
@@ -13,6 +13,13 @@ config DRM_RCAR_DU
Choose this option if you have an R-Car chipset.
If M is selected the module will be called rcar-du-drm.
+config DRM_RCAR_CMM
+ bool "R-Car DU Color Management Module (CMM) Support"
+ depends on DRM && OF
+ depends on DRM_RCAR_DU
+ help
+ Enable support for R-Car Color Management Module (CMM).
+
config DRM_RCAR_DW_HDMI
tristate "R-Car DU Gen3 HDMI Encoder Support"
depends on DRM && OF
diff --git a/drivers/gpu/drm/rcar-du/Makefile b/drivers/gpu/drm/rcar-du/Makefile
index 6c2ed9c46467..4d1187ccc3e5 100644
--- a/drivers/gpu/drm/rcar-du/Makefile
+++ b/drivers/gpu/drm/rcar-du/Makefile
@@ -15,6 +15,7 @@ rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS) += rcar_du_of.o \
rcar-du-drm-$(CONFIG_DRM_RCAR_VSP) += rcar_du_vsp.o
rcar-du-drm-$(CONFIG_DRM_RCAR_WRITEBACK) += rcar_du_writeback.o
+obj-$(CONFIG_DRM_RCAR_CMM) += rcar_cmm.o
obj-$(CONFIG_DRM_RCAR_DU) += rcar-du-drm.o
obj-$(CONFIG_DRM_RCAR_DW_HDMI) += rcar_dw_hdmi.o
obj-$(CONFIG_DRM_RCAR_LVDS)+= rcar_lvds.o
diff --git a/drivers/gpu/drm/rcar-du/rcar_cmm.c
b/drivers/gpu/drm/rcar-du/rcar_cmm.c
new file mode 100644
index ..9675a8587dee
--- /dev/null
+++ b/drivers/gpu/drm/rcar-du/rcar_cmm.c
@@ -0,0 +1,198 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * rcar_cmm.c -- R-Car Display Unit Color Management Module
+ *
+ * Copyright (C) 2019 Jacopo Mondi
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "rcar_cmm.h"
+
+#define CM2_LUT_CTRL 0x
+#define CM2_LUT_CTRL_LUT_ENBIT(0)
+#define CM2_LUT_TBL_BASE 0x0600
+#define CM2_LUT_TBL(__i) (CM2_LUT_TBL_BASE + (__i) * 4)
+
+struct rcar_cmm {
+ void __iomem *base;
+
+ /*
+* @lut:1D-LUT status
+* @lut.enabled:1D-LUT enabled flag
+*/
+ struct {
+ bool enabled;
+ } lut;
+};
+
+static inline int rcar_cmm_read(struct rcar_cmm *rcmm, u32 reg)
+{
+ return ioread32(rcmm->base + reg);
+}
+
+static inline void rcar_cmm_write(struct rcar_cmm *rcmm, u32 reg, u32 data)
+{
+ iowrite32(data, rcmm->base + reg);
+}
+
+/*
+ * rcar_cmm_lut_write() - Scale the DRM LUT table entries to hardware precision
+ * and write to the CMM registers.
+ * @rcmm: Pointer to the CMM device
+ * @drm_lut: Pointer to the DRM LUT table
+ */
+static void rcar_cmm_lut_write(struct rcar_cmm *rcmm,
+ const struct drm_color_lut *drm_lut)
+{
+ unsigned int i;
+
+ for (i = 0; i < CM2_LUT_SIZE; ++i) {
+ u32 entry = drm_color_lut_extract(drm_lut[i].red, 8) << 16
+ | drm_color_lut_extract(drm_lut[i].green, 8) << 8
+ | drm_color_lut_extract(drm_lut[i].blue, 8);
+
+ rcar_cmm_write(rcmm, CM2_LUT_TBL(i), entry);
+ }
+}
+
+/*
+ * rcar_cmm_setup() - Configure the CMM unit.
+ * @pdev: The platform device associated with the CMM instance
+ * @config: The CMM unit configuration
+ *
+ * Configure the CMM unit with the given configuration. Currently enabling,
+ * disabling and programming of the 1-D LUT unit is supported.
+ */
+int rcar_cmm_setup(struct platform_device *pdev,
+ const struct rcar_cmm_config *config)
+{
+ struct rcar_cmm *rcmm = platform_get_drvdata(pdev);
+
+ /* Disable LUT if requested. */
+ if (!config->lut.enable) {
+ if (rcmm->lut.enabled) {
+ rcar_cmm_write(rcmm, CM2_LUT_CTRL, 0);
+ rcmm->lut.enabled = false;
+ }
+
+ return 0;
+ }
+
+ /* Enable LUT and program the new gamma table values. */
+ if (!rcmm->lut.enabled) {
+ rcar_cmm_write(rcmm, CM2_LUT_CTRL, CM2_LUT_CTRL_LUT_EN);
+ rcmm->lut.enabled = true;
+
[PATCH v5 4/8] drm: rcar-du: kms: Initialize CMM instances
Implement device tree parsing to collect the available CMM instances
described by the 'renesas,cmms' property. Associate CMMs with CRTCs and
store a mask of active CMMs in the DU group for later enablement.
Enforce the probe and suspend/resume ordering of DU and CMM by creating
a stateless device link between the two.
Reviewed-by: Kieran Bingham
Reviewed-by: Laurent Pinchart
Signed-off-by: Jacopo Mondi
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 6 ++
drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 2 +
drivers/gpu/drm/rcar-du/rcar_du_drv.h | 2 +
drivers/gpu/drm/rcar-du/rcar_du_group.h | 2 +
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 76 +
5 files changed, 88 insertions(+)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 2da46e3dc4ae..23f1d6cc1719 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -1194,6 +1194,12 @@ int rcar_du_crtc_create(struct rcar_du_group *rgrp,
unsigned int swindex,
if (ret < 0)
return ret;
+ /* CMM might be disabled for this CRTC. */
+ if (rcdu->cmms[swindex]) {
+ rcrtc->cmm = rcdu->cmms[swindex];
+ rgrp->cmms_mask |= BIT(hwindex % 2);
+ }
+
drm_crtc_helper_add(crtc, &crtc_helper_funcs);
/* Start with vertical blanking interrupt reporting disabled. */
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
index 3b7fc668996f..5f2940c42225 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
@@ -39,6 +39,7 @@ struct rcar_du_vsp;
* @vblank_wait: wait queue used to signal vertical blanking
* @vblank_count: number of vertical blanking interrupts to wait for
* @group: CRTC group this CRTC belongs to
+ * @cmm: CMM associated with this CRTC
* @vsp: VSP feeding video to this CRTC
* @vsp_pipe: index of the VSP pipeline feeding video to this CRTC
* @writeback: the writeback connector
@@ -64,6 +65,7 @@ struct rcar_du_crtc {
unsigned int vblank_count;
struct rcar_du_group *group;
+ struct platform_device *cmm;
struct rcar_du_vsp *vsp;
unsigned int vsp_pipe;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
index 1327cd0df90a..61504c54e2ec 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
@@ -13,6 +13,7 @@
#include
#include
+#include "rcar_cmm.h"
#include "rcar_du_crtc.h"
#include "rcar_du_group.h"
#include "rcar_du_vsp.h"
@@ -85,6 +86,7 @@ struct rcar_du_device {
struct rcar_du_encoder *encoders[RCAR_DU_OUTPUT_MAX];
struct rcar_du_group groups[RCAR_DU_MAX_GROUPS];
+ struct platform_device *cmms[RCAR_DU_MAX_CRTCS];
struct rcar_du_vsp vsps[RCAR_DU_MAX_VSPS];
struct {
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_group.h
b/drivers/gpu/drm/rcar-du/rcar_du_group.h
index 87950c1f6a52..e9906609c635 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_group.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_group.h
@@ -22,6 +22,7 @@ struct rcar_du_device;
* @mmio_offset: registers offset in the device memory map
* @index: group index
* @channels_mask: bitmask of populated DU channels in this group
+ * @cmms_mask: bitmask of available CMMs in this group
* @num_crtcs: number of CRTCs in this group (1 or 2)
* @use_count: number of users of the group (rcar_du_group_(get|put))
* @used_crtcs: number of CRTCs currently in use
@@ -37,6 +38,7 @@ struct rcar_du_group {
unsigned int index;
unsigned int channels_mask;
+ unsigned int cmms_mask;
unsigned int num_crtcs;
unsigned int use_count;
unsigned int used_crtcs;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 2dc9caee8767..7c9fb5860e54 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -17,7 +17,9 @@
#include
#include
+#include
#include
+#include
#include
#include "rcar_du_crtc.h"
@@ -614,6 +616,75 @@ static int rcar_du_vsps_init(struct rcar_du_device *rcdu)
return ret;
}
+static int rcar_du_cmm_init(struct rcar_du_device *rcdu)
+{
+ const struct device_node *np = rcdu->dev->of_node;
+ unsigned int i;
+ int cells;
+
+ cells = of_property_count_u32_elems(np, "renesas,cmms");
+ if (cells == -EINVAL)
+ return 0;
+
+ if (cells > rcdu->num_crtcs) {
+ dev_err(rcdu->dev,
+ "Invalid number of entries in 'renesas,cmms'\n");
+ return -EINVAL;
+ }
+
+ for (i = 0; i < cells; ++i) {
+ struct platform_device *pdev;
+ struct device_link *link;
+
[PATCH v5 5/8] drm: rcar-du: crtc: Control CMM operations
Implement CMM handling in the crtc begin and enable atomic callbacks,
and enable CMM unit through the Display Extensional Functions
register at group setup time.
Signed-off-by: Jacopo Mondi
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 79 +
drivers/gpu/drm/rcar-du/rcar_du_group.c | 5 ++
drivers/gpu/drm/rcar-du/rcar_du_regs.h | 5 ++
3 files changed, 89 insertions(+)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 23f1d6cc1719..4bc50a3f4a00 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -21,6 +21,7 @@
#include
#include
+#include "rcar_cmm.h"
#include "rcar_du_crtc.h"
#include "rcar_du_drv.h"
#include "rcar_du_encoder.h"
@@ -474,6 +475,70 @@ static void rcar_du_crtc_wait_page_flip(struct
rcar_du_crtc *rcrtc)
rcar_du_crtc_finish_page_flip(rcrtc);
}
+/*
-
+ * Color Management Module (CMM)
+ */
+static int rcar_du_cmm_enable(struct drm_crtc *crtc)
+{
+ struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
+
+ if (!rcrtc->cmm)
+ return 0;
+
+ return rcar_cmm_enable(rcrtc->cmm);
+}
+
+static void rcar_du_cmm_disable(struct drm_crtc *crtc)
+{
+ struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
+
+ if (!rcrtc->cmm)
+ return;
+
+ rcar_cmm_disable(rcrtc->cmm);
+}
+
+static int rcar_du_cmm_check(struct drm_crtc *crtc,
+struct drm_crtc_state *state)
+{
+ struct drm_property_blob *drm_lut = state->gamma_lut;
+ struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
+ struct device *dev = rcrtc->dev->dev;
+
+ if (!rcrtc->cmm || !drm_lut)
+ return 0;
+
+ /* We only accept fully populated LUT tables. */
+ if (CM2_LUT_SIZE * sizeof(struct drm_color_lut) !=
+ drm_lut->length) {
+ dev_err(dev, "invalid gamma lut size: %lu bytes\n",
+ drm_lut->length);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static void rcar_du_cmm_setup(struct drm_crtc *crtc)
+{
+ struct drm_property_blob *drm_lut = crtc->state->gamma_lut;
+ struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
+ struct rcar_cmm_config cmm_config = {};
+
+ if (!rcrtc->cmm)
+ return;
+
+ if (drm_lut) {
+ cmm_config.lut.enable = true;
+ cmm_config.lut.table = (struct drm_color_lut *)drm_lut->data;
+
+ } else {
+ cmm_config.lut.enable = false;
+ }
+
+ rcar_cmm_setup(rcrtc->cmm, &cmm_config);
+}
+
/*
-
* Start/Stop and Suspend/Resume
*/
@@ -619,6 +684,8 @@ static void rcar_du_crtc_stop(struct rcar_du_crtc *rcrtc)
if (rcar_du_has(rcrtc->dev, RCAR_DU_FEATURE_VSP1_SOURCE))
rcar_du_vsp_disable(rcrtc);
+ rcar_du_cmm_disable(crtc);
+
/*
* Select switch sync mode. This stops display operation and configures
* the HSYNC and VSYNC signals as inputs.
@@ -631,6 +698,7 @@ static void rcar_du_crtc_stop(struct rcar_du_crtc *rcrtc)
DSYSR_TVM_SWITCH);
rcar_du_group_start_stop(rcrtc->group, false);
+
}
/*
-
@@ -642,6 +710,11 @@ static int rcar_du_crtc_atomic_check(struct drm_crtc *crtc,
{
struct rcar_du_crtc_state *rstate = to_rcar_crtc_state(state);
struct drm_encoder *encoder;
+ int ret;
+
+ ret = rcar_du_cmm_check(crtc, state);
+ if (ret)
+ return ret;
/* Store the routes from the CRTC output to the DU outputs. */
rstate->outputs = 0;
@@ -667,6 +740,7 @@ static void rcar_du_crtc_atomic_enable(struct drm_crtc
*crtc,
struct rcar_du_crtc_state *rstate = to_rcar_crtc_state(crtc->state);
struct rcar_du_device *rcdu = rcrtc->dev;
+ rcar_du_cmm_enable(crtc);
rcar_du_crtc_get(rcrtc);
/*
@@ -686,6 +760,7 @@ static void rcar_du_crtc_atomic_enable(struct drm_crtc
*crtc,
}
rcar_du_crtc_start(rcrtc);
+ rcar_du_cmm_setup(crtc);
}
static void rcar_du_crtc_atomic_disable(struct drm_crtc *crtc,
@@ -739,6 +814,10 @@ static void rcar_du_crtc_atomic_begin(struct drm_crtc
*crtc,
*/
rcar_du_crtc_get(rcrtc);
+ /* If the active state changed, we let .atomic_enable handle CMM. */
+ if (crtc->state->color_mgmt_changed && !crtc->state->active_changed)
+ rcar_du_cmm_setup(crtc);
+
if (rcar_du_has(rcrtc->dev, RCAR_DU_FEATURE_VSP1_SOURCE))
rcar_du_vsp_atomic_begin(rcrtc);
}
diff
[PATCH v5 6/8] drm: rcar-du: crtc: Register GAMMA_LUT properties
Enable the GAMMA_LUT KMS property using the framework helpers to
register the property and set the associated gamma table maximum size.
Reviewed-by: Kieran Bingham
Reviewed-by: Ulrich Hecht
Reviewed-by: Laurent Pinchart
Signed-off-by: Jacopo Mondi
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 4
1 file 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 4bc50a3f4a00..603f9f716721 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -1154,6 +1154,7 @@ static const struct drm_crtc_funcs crtc_funcs_gen3 = {
.set_crc_source = rcar_du_crtc_set_crc_source,
.verify_crc_source = rcar_du_crtc_verify_crc_source,
.get_crc_sources = rcar_du_crtc_get_crc_sources,
+ .gamma_set = drm_atomic_helper_legacy_gamma_set,
};
/*
-
@@ -1277,6 +1278,9 @@ int rcar_du_crtc_create(struct rcar_du_group *rgrp,
unsigned int swindex,
if (rcdu->cmms[swindex]) {
rcrtc->cmm = rcdu->cmms[swindex];
rgrp->cmms_mask |= BIT(hwindex % 2);
+
+ drm_mode_crtc_set_gamma_size(crtc, CM2_LUT_SIZE);
+ drm_crtc_enable_color_mgmt(crtc, 0, false, CM2_LUT_SIZE);
}
drm_crtc_helper_add(crtc, &crtc_helper_funcs);
--
2.23.0
[PATCH v5 2/8] dt-bindings: display, renesas,du: Document cmms property
Document the newly added 'cmms' property which accepts a list of phandle
and channel index pairs that point to the CMM units available for each
Display Unit output video channel.
Reviewed-by: Rob Herring
Reviewed-by: Kieran Bingham
Reviewed-by: Laurent Pinchart
Signed-off-by: Jacopo Mondi
---
Documentation/devicetree/bindings/display/renesas,du.txt | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/renesas,du.txt
b/Documentation/devicetree/bindings/display/renesas,du.txt
index c97dfacad281..3d9809b486b6 100644
--- a/Documentation/devicetree/bindings/display/renesas,du.txt
+++ b/Documentation/devicetree/bindings/display/renesas,du.txt
@@ -45,6 +45,10 @@ Required Properties:
instance that serves the DU channel, and the channel index identifies the
LIF instance in that VSP.
+ - renesas,cmms: A list of phandles to the CMM instances present in the SoC,
+one for each available DU channel. The property shall not be specified for
+SoCs that do not provide any CMM (such as V3M and V3H).
+
Required nodes:
The connections to the DU output video ports are modeled using the OF graph
@@ -91,6 +95,7 @@ Example: R8A7795 (R-Car H3) ES2.0 DU
<&cpg CPG_MOD 721>;
clock-names = "du.0", "du.1", "du.2", "du.3";
vsps = <&vspd0 0>, <&vspd1 0>, <&vspd2 0>, <&vspd0 1>;
+ renesas,cmms = <&cmm0>, <&cmm1>, <&cmm2>, <&cmm3>;
ports {
#address-cells = <1>;
--
2.23.0
