Re: [PATCH 2/5] drm/tidss: Set bus_format correctly from bridge/connector

2020-10-29 Thread Laurent Pinchart
Hi Nikhil,

Thank you for the patch.

On Fri, Oct 16, 2020 at 04:09:14PM +0530, Nikhil Devshatwar wrote:
> When there is a chain of bridges attached to the encoder,
> the bus_format should be ideally set from the input format of the
> first bridge in the chain.
> 
> Use the bridge state to get the negotiated bus_format.
> If the bridge does not support format negotiation, error out
> and fail.
> 
> Signed-off-by: Nikhil Devshatwar 
> ---
>  drivers/gpu/drm/tidss/tidss_encoder.c | 16 +++-
>  1 file changed, 11 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/tidss/tidss_encoder.c 
> b/drivers/gpu/drm/tidss/tidss_encoder.c
> index e278a9c89476..ae7f134754b7 100644
> --- a/drivers/gpu/drm/tidss/tidss_encoder.c
> +++ b/drivers/gpu/drm/tidss/tidss_encoder.c
> @@ -22,6 +22,7 @@ static int tidss_encoder_atomic_check(struct drm_encoder 
> *encoder,
>   struct drm_device *ddev = encoder->dev;
>   struct tidss_crtc_state *tcrtc_state = to_tidss_crtc_state(crtc_state);
>   struct drm_display_info *di = _state->connector->display_info;
> + struct drm_bridge_state *bstate;
>   struct drm_bridge *bridge;
>   bool bus_flags_set = false;
>  
> @@ -41,14 +42,19 @@ static int tidss_encoder_atomic_check(struct drm_encoder 
> *encoder,
>   break;
>   }
>  
> - if (!di->bus_formats || di->num_bus_formats == 0)  {
> - dev_err(ddev->dev, "%s: No bus_formats in connected display\n",
> - __func__);
> + /* Copy the bus_format from the input_bus_format of first bridge */
> + bridge = drm_bridge_chain_get_first_bridge(encoder);
> + bstate = drm_atomic_get_new_bridge_state(crtc_state->state, bridge);
> + if (bstate)
> + tcrtc_state->bus_format = bstate->input_bus_cfg.format;
> +
> + if (tcrtc_state->bus_format == 0 ||
> + tcrtc_state->bus_format == MEDIA_BUS_FMT_FIXED) {
> +
> + dev_err(ddev->dev, "Bridge connected to the encoder did not 
> specify media bus format\n");
>   return -EINVAL;
>   }
>  
> - // XXX any cleaner way to set bus format and flags?
> - tcrtc_state->bus_format = di->bus_formats[0];
>   if (!bus_flags_set)
>   tcrtc_state->bus_flags = di->bus_flags;

Shouldn't the flags also be retrieved from the bridge state ?

>  

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 1/5] drm/tidss: Move to newer connector model

2020-10-29 Thread Laurent Pinchart
Hi Nikhil,

Thank you for the patch.

On Fri, Oct 16, 2020 at 04:09:13PM +0530, Nikhil Devshatwar wrote:
> To be able to support connector operations across multiple
> bridges, it is recommended that the connector should be
> created by the SoC driver instead of the bridges.
> 
> Modify the tidss modesetting initialization sequence to
> create the connector and attach bridges with flag
> DRM_BRIDGE_ATTACH_NO_CONNECTOR
> 
> Signed-off-by: Nikhil Devshatwar 
> ---
>  drivers/gpu/drm/tidss/tidss_drv.h |  3 +++
>  drivers/gpu/drm/tidss/tidss_kms.c | 15 ++-
>  2 files changed, 17 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/tidss/tidss_drv.h 
> b/drivers/gpu/drm/tidss/tidss_drv.h
> index 7de4bba52e6f..cfbf85a4d92b 100644
> --- a/drivers/gpu/drm/tidss/tidss_drv.h
> +++ b/drivers/gpu/drm/tidss/tidss_drv.h
> @@ -27,6 +27,9 @@ struct tidss_device {
>   unsigned int num_planes;
>   struct drm_plane *planes[TIDSS_MAX_PLANES];
>  
> + unsigned int num_connectors;
> + struct drm_connector *connectors[TIDSS_MAX_PORTS];
> +
>   spinlock_t wait_lock;   /* protects the irq masks */
>   dispc_irq_t irq_mask;   /* enabled irqs in addition to wait_list */
>  };
> diff --git a/drivers/gpu/drm/tidss/tidss_kms.c 
> b/drivers/gpu/drm/tidss/tidss_kms.c
> index 09485c7f0d6f..51c24b4a6a21 100644
> --- a/drivers/gpu/drm/tidss/tidss_kms.c
> +++ b/drivers/gpu/drm/tidss/tidss_kms.c
> @@ -7,6 +7,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -192,6 +193,7 @@ static int tidss_dispc_modeset_init(struct tidss_device 
> *tidss)
>   for (i = 0; i < num_pipes; ++i) {
>   struct tidss_plane *tplane;
>   struct tidss_crtc *tcrtc;
> + struct drm_connector *connector;
>   struct drm_encoder *enc;
>   u32 hw_plane_id = feat->vid_order[tidss->num_planes];
>   int ret;
> @@ -222,11 +224,22 @@ static int tidss_dispc_modeset_init(struct tidss_device 
> *tidss)
>   return PTR_ERR(enc);
>   }
>  
> - ret = drm_bridge_attach(enc, pipes[i].bridge, NULL, 0);
> + ret = drm_bridge_attach(enc, pipes[i].bridge, NULL,
> + DRM_BRIDGE_ATTACH_NO_CONNECTOR);
>   if (ret) {
>   dev_err(tidss->dev, "bridge attach failed: %d\n", ret);
>   return ret;
>   }
> +
> + connector = drm_bridge_connector_init(>ddev, enc);
> + if (IS_ERR(connector)) {
> + dev_err(tidss->dev, "bridge_connector create failed\n");
> + return PTR_ERR(connector);
> + }
> +
> + tidss->connectors[tidss->num_connectors++] = connector;
> +
> + drm_connector_attach_encoder(connector, enc);

Apart from the issue reported by Tomi, the patch looks goood to me. Fix
this fixed, and the series reordered to move this to the end,

Reviewed-by: Laurent Pinchart 

>   }
>  
>   /* create overlay planes of the leftover planes */

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 3/5] drm: bridge: Propagate the bus flags from bridge->timings

2020-10-29 Thread Laurent Pinchart
Hello,

On Wed, Oct 28, 2020 at 08:04:53PM +0530, Nikhil Devshatwar wrote:
> On 14:31-20201021, Tomi Valkeinen wrote:
> > On 16/10/2020 13:39, Nikhil Devshatwar wrote:
> > > When the next bridge does not specify any bus flags, use the
> > > bridge->timings->input_bus_flags as fallback when propagating
> > > bus flags from next bridge to current bridge.
> > > 
> > > Signed-off-by: Nikhil Devshatwar 
> > > ---
> > >  drivers/gpu/drm/drm_bridge.c | 7 +++
> > >  1 file changed, 7 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> > > index 64f0effb52ac..8353723323ab 100644
> > > --- a/drivers/gpu/drm/drm_bridge.c
> > > +++ b/drivers/gpu/drm/drm_bridge.c
> > > @@ -975,6 +975,13 @@ drm_atomic_bridge_propagate_bus_flags(struct 
> > > drm_bridge *bridge,
> > >* duplicate the "dummy propagation" logic.
> > >*/
> > >   bridge_state->input_bus_cfg.flags = output_flags;
> > > +
> > > + /*
> > > +  * Use the bridge->timings->input_bus_flags as fallback if the next 
> > > bridge
> > > +  * does not specify the flags
> > > +  */
> > > + if (!bridge_state->input_bus_cfg.flags)
> > > + bridge_state->input_bus_cfg.flags = 
> > > bridge->timings->input_bus_flags;
> > 
> > According to docs, timings can be NULL.

Correct.

> > And, hmm... It's too easy to get confused with these, but... If the bridge 
> > defines timings, and
> > timings->input_bus_flags != 0, should we always pick that, even if we got 
> > something via
> > output_flags? Logic being, if this bridge defines timings->input_bus_flags, 
> > it probably wants that
> > to be used regardless whether we got something from the next bridge.

timings->input_bus_flags is an API that predates format and flags
propagation along the pipeline. I would assume that drivers that
implement propagation should do so in a way that prioritize that API,
and either not report flags in the timings (in which case giving
priority to one or another wouldn't make a difference as both would
never be provided together), or would report flags in the timings as a
best effort fallback for display controller drivers that would look at
them exclusively without supporting the new API. I would thus think that
the flags obtained through format negotiation should be prioritized.

> Got it, the flags from timings if present should be prioritized rather
> than treating them as fallback.

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 5/5] drm/bridge: mhdp8564: Support format negotiation

2020-10-29 Thread Laurent Pinchart
Hi Nikhil,

Thank you for the patch.

On Fri, Oct 16, 2020 at 04:09:17PM +0530, Nikhil Devshatwar wrote:
> With new connector model, mhdp bridge will not create the connector and
> SoC driver will rely on format negotiation to setup the encoder format.
> 
> Support format negotiations hooks in the drm_bridge_funcs.
> Support a single format for input.
> 
> Signed-off-by: Nikhil Devshatwar 
> ---
>  .../drm/bridge/cadence/cdns-mhdp8546-core.c   | 29 +++
>  1 file changed, 29 insertions(+)
> 
> diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c 
> b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> index d0c65610ebb5..230f6e28f82f 100644
> --- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> +++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> @@ -2078,6 +2078,34 @@ cdns_mhdp_bridge_atomic_reset(struct drm_bridge 
> *bridge)
>   return _mhdp_state->base;
>  }
>  
> +static u32 *cdns_mhdp_get_input_bus_fmts(struct drm_bridge *bridge,
> +   struct drm_bridge_state *bridge_state,
> +   struct drm_crtc_state *crtc_state,
> +   struct drm_connector_state *conn_state,
> +   u32 output_fmt,
> +   unsigned int *num_input_fmts)
> +{
> + u32 *input_fmts;
> + u32 default_bus_format = MEDIA_BUS_FMT_RGB121212_1X36;

Display port supports quite a few different formats. See my reply to
4/5, except it's worse in the DP case :-) Especially given that multiple
displays need to be taken into account. I'm afraid we need to decide how
to map media bus formats to different DP use cases, possibly adding new
bus formats as part of this exercise, and then revisit this patch.

> +
> + *num_input_fmts = 0;
> +
> + /*
> +  * This bridge does not support media_bus_format conversion
> +  * Propagate only if supported
> +  */
> + if (output_fmt != default_bus_format && output_fmt != 
> MEDIA_BUS_FMT_FIXED)
> + return NULL;
> +
> + input_fmts = kzalloc(sizeof(*input_fmts), GFP_KERNEL);
> + if (!input_fmts)
> + return NULL;
> +
> + *num_input_fmts = 1;
> + input_fmts[0] = default_bus_format;
> + return input_fmts;
> +}
> +
>  static int cdns_mhdp_atomic_check(struct drm_bridge *bridge,
> struct drm_bridge_state *bridge_state,
> struct drm_crtc_state *crtc_state,
> @@ -2142,6 +2170,7 @@ static const struct drm_bridge_funcs 
> cdns_mhdp_bridge_funcs = {
>   .atomic_duplicate_state = cdns_mhdp_bridge_atomic_duplicate_state,
>   .atomic_destroy_state = cdns_mhdp_bridge_atomic_destroy_state,
>   .atomic_reset = cdns_mhdp_bridge_atomic_reset,
> + .atomic_get_input_bus_fmts = cdns_mhdp_get_input_bus_fmts,
>   .detect = cdns_mhdp_bridge_detect,
>   .get_edid = cdns_mhdp_bridge_get_edid,
>   .hpd_enable = cdns_mhdp_bridge_hpd_enable,

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 4/5] drm/bridge: tfp410: Support format negotiation

2020-10-29 Thread Laurent Pinchart
Hi Nikhil,

Thank you for the patch.

On Fri, Oct 16, 2020 at 04:09:16PM +0530, Nikhil Devshatwar wrote:
> With new connector model, tfp410 will not create the connector and
> SoC driver will rely on format negotiation to setup the encoder format.
> 
> Support format negotiations hooks in the drm_bridge_funcs.
> Use helper functions for state management.
> Support one of the two RGB formats as selected from DT bindings.
> 
> Signed-off-by: Nikhil Devshatwar 
> ---
>  drivers/gpu/drm/bridge/ti-tfp410.c | 32 ++
>  1 file changed, 32 insertions(+)
> 
> diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c 
> b/drivers/gpu/drm/bridge/ti-tfp410.c
> index ba3fa2a9b8a4..b65e48e080c7 100644
> --- a/drivers/gpu/drm/bridge/ti-tfp410.c
> +++ b/drivers/gpu/drm/bridge/ti-tfp410.c
> @@ -204,12 +204,44 @@ static enum drm_mode_status tfp410_mode_valid(struct 
> drm_bridge *bridge,
>   return MODE_OK;
>  }
>  
> +static u32 *tfp410_get_input_bus_fmts(struct drm_bridge *bridge,
> +   struct drm_bridge_state *bridge_state,
> +   struct drm_crtc_state *crtc_state,
> +   struct drm_connector_state *conn_state,
> +   u32 output_fmt,
> +   unsigned int *num_input_fmts)
> +{
> + struct tfp410 *dvi = drm_bridge_to_tfp410(bridge);
> + u32 *input_fmts;
> +
> + *num_input_fmts = 0;
> +
> + /*
> +  * This bridge does not support media_bus_format conversion
> +  * Propagate only if supported
> +  */
> + if (output_fmt != dvi->bus_format && output_fmt != MEDIA_BUS_FMT_FIXED)
> + return NULL;

On the output side, DVI transmits RGB24 data over three TMDS links (plus
one link for the clock). There's no media bus format that specifically
describe this, but among the possible values for dvi->bus_format
(MEDIA_BUS_FMT_RGB888_2X12_LE and MEDIA_BUS_FMT_RGB888_1X24),
MEDIA_BUS_FMT_RGB888_2X12_LE doesn't make any sense to describe the
output. We probably would need to introduce a specific media bus format
if we wanted to describe this accurately
(MEDIA_BUS_FMT_RGB888_DVI_SINGLE ?), which seems a bit overkill to
support single link DVI. If we take dual link DVI into account, more bit
depths are supported, as well as faster rates by transmitting to RGB888
pixels per clock, so more codes would be needed.

With support for single-link DVI only, we could decide, subsystem-wide,
to always use MEDIA_BUS_FMT_FIXED for DVI. We could also decide to
additional accept MEDIA_BUS_FMT_RGB888_1X24 to describe single-link DVI,
as a convention.

If the goal of the above check is to make the format negotiation fail
when the desired output format can't be supported by the TFP410, then I
would use

if (output_fmt != dvi->MEDIA_BUS_FMT_RGB888_1X24 &&
output_fmt != MEDIA_BUS_FMT_FIXED)
return NULL;

or simply

if (output_fmt != MEDIA_BUS_FMT_FIXED)
return NULL;

depending on what convention we enforce in the subsystem for DVI media
bus formats. I however wonder if this is needed at all, are there cases
where the output could support multiple bus formats and the tfp410
driver would need to make sure that only the 24-bit single link DVI gets
selected ? I suppose there are if we consider dual link DVI, but the DVI
connector driver (drivers/gpu/drm/bridge/display-connector.c) doesn't
report bus formats anyway.

> +
> + input_fmts = kzalloc(sizeof(*input_fmts), GFP_KERNEL);
> + if (!input_fmts)
> + return NULL;
> +
> + *num_input_fmts = 1;
> + input_fmts[0] = dvi->bus_format;
> + return input_fmts;
> +}
> +
>  static const struct drm_bridge_funcs tfp410_bridge_funcs = {
>   .attach = tfp410_attach,
>   .detach = tfp410_detach,
>   .enable = tfp410_enable,
>   .disable= tfp410_disable,
>   .mode_valid = tfp410_mode_valid,
> + .atomic_reset = drm_atomic_helper_bridge_reset,
> + .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
> + .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
> + .atomic_get_input_bus_fmts = tfp410_get_input_bus_fmts,
>  };
>  
>  static const struct drm_bridge_timings tfp410_default_timings = {

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drivers/video: Fix -Wstringop-truncation in hdmi.c

2020-10-21 Thread Laurent Pinchart
Hi Thomas,

Thank you for the patch.

On Wed, Oct 21, 2020 at 02:12:41PM +0200, Thomas Zimmermann wrote:
> Trying to copy into the string fields with strncpy() gives a warning from
> gcc. Both fields are part of a packed HDMI header and do not require a
> terminating \0 character.
> 
> ../drivers/video/hdmi.c: In function 'hdmi_spd_infoframe_init':
> ../drivers/video/hdmi.c:230:2: warning: 'strncpy' specified bound 8 equals 
> destination size [-Wstringop-truncation]
>   230 |  strncpy(frame->vendor, vendor, sizeof(frame->vendor));
>   |  ^
> ../drivers/video/hdmi.c:231:2: warning: 'strncpy' specified bound 16 equals 
> destination size [-Wstringop-truncation]
>   231 |  strncpy(frame->product, product, sizeof(frame->product));
>   |  ^~~~
> 
> Just use memcpy() instead.
> 
> Signed-off-by: Thomas Zimmermann 
> ---
>  drivers/video/hdmi.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> index b7a1d6fae90d..1e4cb63d0d11 100644
> --- a/drivers/video/hdmi.c
> +++ b/drivers/video/hdmi.c
> @@ -221,14 +221,18 @@ EXPORT_SYMBOL(hdmi_avi_infoframe_pack);
>  int hdmi_spd_infoframe_init(struct hdmi_spd_infoframe *frame,
>   const char *vendor, const char *product)
>  {
> + size_t len;
> +
>   memset(frame, 0, sizeof(*frame));
>  
>   frame->type = HDMI_INFOFRAME_TYPE_SPD;
>   frame->version = 1;
>   frame->length = HDMI_SPD_INFOFRAME_SIZE;
>  
> - strncpy(frame->vendor, vendor, sizeof(frame->vendor));
> - strncpy(frame->product, product, sizeof(frame->product));
> + len = strlen(vendor);
> + memcpy(frame->vendor, vendor, min(len, sizeof(frame->vendor)));
> + len = strlen(product);
> + memcpy(frame->product, product, min(len, sizeof(frame->product)));

As this seems to be a legitimate use of strncpy(), isn't there a way to
silence the warning without requiring this additional runtime complexity
?

>  
>   return 0;
>  }

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [RFC][PATCH] drm/bridge: lvds-codec: Add support for pixel data sampling edge select

2020-10-18 Thread Laurent Pinchart
Hi Marek,

Thank you for the patch.

On Sat, Oct 03, 2020 at 01:08:23AM +0200, Marek Vasut wrote:
> The OnSemi FIN3385 Parallel-to-LVDS encoder has a dedicated input line to
> select input pixel data sampling edge. Add DT property "pixelclk-active",
> same as the one used by display timings, and configure bus flags based on
> this DT property.

The feature looks good to me. I however wonder if we shouldn't use the
standard pclk-sample endpoint property (documented in [1]) instead of a
custom properly.

The DT bindings for the lvds-codec should be updated accordingly. And
the property should only be taken into account when operating in encoder
mode, as for decoder mode there's no polarity for the sampling of LVDS
signals, as you've explained in a reply to Sam.

[1] Documentation/devicetree/bindings/media/video-interfaces.txt

> Signed-off-by: Marek Vasut 
> Cc: Alexandre Torgue 
> Cc: Andrzej Hajda 
> Cc: Antonio Borneo 
> Cc: Benjamin Gaignard 
> Cc: Biju Das 
> Cc: Laurent Pinchart 
> Cc: Maxime Coquelin 
> Cc: Philippe Cornu 
> Cc: Sam Ravnborg 
> Cc: Vincent Abriou 
> Cc: Yannick Fertre 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-st...@st-md-mailman.stormreply.com
> To: dri-devel@lists.freedesktop.org
> ---
>  drivers/gpu/drm/bridge/lvds-codec.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/gpu/drm/bridge/lvds-codec.c 
> b/drivers/gpu/drm/bridge/lvds-codec.c
> index f52ccffc1bd1..bc941d4fb5b9 100644
> --- a/drivers/gpu/drm/bridge/lvds-codec.c
> +++ b/drivers/gpu/drm/bridge/lvds-codec.c
> @@ -19,6 +19,7 @@ struct lvds_codec {
>   struct device *dev;
>   struct drm_bridge bridge;
>   struct drm_bridge *panel_bridge;
> + struct drm_bridge_timings timings;
>   struct regulator *vcc;
>   struct gpio_desc *powerdown_gpio;
>   u32 connector_type;
> @@ -80,6 +81,7 @@ static int lvds_codec_probe(struct platform_device *pdev)
>   struct device_node *panel_node;
>   struct drm_panel *panel;
>   struct lvds_codec *lvds_codec;
> + u32 val;
>   int ret;
>  
>   lvds_codec = devm_kzalloc(dev, sizeof(*lvds_codec), GFP_KERNEL);
> @@ -124,6 +126,12 @@ static int lvds_codec_probe(struct platform_device *pdev)
>   if (IS_ERR(lvds_codec->panel_bridge))
>   return PTR_ERR(lvds_codec->panel_bridge);
>  
> + if (!of_property_read_u32(dev->of_node, "pixelclk-active", )) {
> + lvds_codec->timings.input_bus_flags = val ?
> + DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE :
> + DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE;
> + }
> +
>   /*
>* The panel_bridge bridge is attached to the panel's of_node,
>* but we need a bridge attached to our of_node for our user
> @@ -131,6 +139,7 @@ static int lvds_codec_probe(struct platform_device *pdev)
>*/
>   lvds_codec->bridge.of_node = dev->of_node;
>   lvds_codec->bridge.funcs = 
> + lvds_codec->bridge.timings = _codec->timings;
>   drm_bridge_add(_codec->bridge);
>  
>   platform_set_drvdata(pdev, lvds_codec);

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 3/7] dt-bindings: display: mxsfb: Add a bus-width endpoint property

2020-10-12 Thread Laurent Pinchart
Hi Marek,

On Sat, Oct 10, 2020 at 10:47:05AM +0200, Marek Vasut wrote:
> On 10/10/20 1:58 AM, Laurent Pinchart wrote:
> > Hi Marek,
> 
> Hi,
> 
> > On Wed, Oct 07, 2020 at 10:40:26AM +0200, Marek Vasut wrote:
> >> On 10/7/20 3:24 AM, Laurent Pinchart wrote:
> >>
> >> [...]
> >>
> >>> +  bus-width:
> >>> +enum: [16, 18, 24]
> >>> +description: |
> >>> +  The output bus width. This value overrides the 
> >>> configuration
> >>> +  derived from the connected device (encoder or panel). It 
> >>> should
> >>> +  only be specified when PCB routing of the data signals 
> >>> require a
> >>> +  different bus width on the LCDIF and the connected device. 
> >>> For
> >>> +  instance, when a 18-bit RGB panel has its R[5:0], G[5:0] 
> >>> and
> >>> +  B[5:0] signals connected to LCD_DATA[7:2], LCD_DATA[15:10] 
> >>> and
> >>> +  LCD_DATA[23:18] instead of LCD_DATA[5:0], LCD_DATA[11:6] 
> >>> and
> >>> +  LCD_DATA[17:12], bus-width should be set to 24.
> >>
> >> The iMX6 IPUv3 uses interface-pix-fmt which is a bit more flexible, but
> >> I'm not sure whether it's the right way to go about this, see:
> >> Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt
> > 
> > I think specifying the bus with is better. It's a standard property, but
> > more than that, a given bus width can carry different formats. For
> > instance, a 24-bus could carry RGB666 data (with dithering for the
> > LSBs).
> 
> I think that's exactly what the interface-pix-fmt was trying to solve
> for the IPUv3, there you could have e.g. both RGB666 and LVDS666 , which
> were different.

My point is that the driver should support multiple formats that can be
carried over a given bus width, with the actual format to be used
queried from the sink (usually a panel) instead of being hardcoded in
DT.

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 0/2] drm: mxsfb: Primary plane format fix and enhancement

2020-10-12 Thread Laurent Pinchart
Hello,

This small patch series fixes format switching for the primary plane,
and adds support for the RGB888 format. There's not much else to tell,
please see individual patches for details.

Laurent Pinchart (2):
  drm: mxsfb: Fix format changes for primary plane
  drm: mxsfb: Add RGB888 support on the primary plane

 drivers/gpu/drm/mxsfb/mxsfb_drv.c |  5 +
 drivers/gpu/drm/mxsfb/mxsfb_kms.c | 29 +
 2 files changed, 30 insertions(+), 4 deletions(-)

-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 1/2] drm: mxsfb: Fix format changes for primary plane

2020-10-12 Thread Laurent Pinchart
The primary plane's format is configured in registers that have no
shadow support for live updates. They require the display to be fully
reconfigured in order to be updated. Force a mode set when the primary
plane format changes to ensure this.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/mxsfb/mxsfb_kms.c | 22 ++
 1 file changed, 18 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c 
b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
index 6d512f346918..7a69d9f3a875 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
@@ -407,14 +407,28 @@ static int mxsfb_plane_atomic_check(struct drm_plane 
*plane,
 {
struct mxsfb_drm_private *mxsfb = to_mxsfb_drm_private(plane->dev);
struct drm_crtc_state *crtc_state;
+   int ret;
 
crtc_state = drm_atomic_get_new_crtc_state(plane_state->state,
   >crtc);
 
-   return drm_atomic_helper_check_plane_state(plane_state, crtc_state,
-  DRM_PLANE_HELPER_NO_SCALING,
-  DRM_PLANE_HELPER_NO_SCALING,
-  false, true);
+   ret = drm_atomic_helper_check_plane_state(plane_state, crtc_state,
+ DRM_PLANE_HELPER_NO_SCALING,
+ DRM_PLANE_HELPER_NO_SCALING,
+ false, true);
+   if (ret < 0)
+   return ret;
+
+   /*
+* Changing the primary plane format requires stopping the display
+* controller first. Force a full mode set to do so.
+*/
+   if (plane == mxsfb->crtc.primary &&
+   plane_state->visible && plane->state->visible &&
+   plane_state->fb->format != plane->state->fb->format)
+   crtc_state->mode_changed = true;
+
+   return 0;
 }
 
 static void mxsfb_plane_primary_atomic_update(struct drm_plane *plane,
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 2/2] drm: mxsfb: Add RGB888 support on the primary plane

2020-10-12 Thread Laurent Pinchart
The primary plane can support the packed 24-bit RGB888 format. Enable
it.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/mxsfb/mxsfb_drv.c | 5 +
 drivers/gpu/drm/mxsfb/mxsfb_kms.c | 7 +++
 2 files changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c 
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index d52cf8a506a5..5ec10f0f6508 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -97,6 +97,11 @@ mxsfb_fb_create(struct drm_device *dev, struct drm_file 
*file_priv,
return ERR_PTR(-EINVAL);
}
 
+   if (info->cpp[0] == 3 && mode_cmd->width % 4) {
+   dev_dbg(dev->dev, "24-bit RGB format requires a width aligned 
to 4\n");
+   return ERR_PTR(-EINVAL);
+   }
+
return drm_gem_fb_create(dev, file_priv, mode_cmd);
 }
 
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c 
b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
index 7a69d9f3a875..7a0d6bc58be0 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
@@ -75,6 +75,12 @@ static void mxsfb_set_formats(struct mxsfb_drm_private 
*mxsfb)
ctrl |= CTRL_WORD_LENGTH_16;
ctrl1 |= CTRL1_SET_BYTE_PACKAGING(0xf);
break;
+   case DRM_FORMAT_RGB888:
+   dev_dbg(drm->dev, "Setting up RGB888 mode\n");
+   ctrl |= CTRL_WORD_LENGTH_24;
+   /* Enable pixel packing, 4 pixels in 3 bytes. */
+   ctrl1 |= CTRL1_SET_BYTE_PACKAGING(0xf);
+   break;
case DRM_FORMAT_XRGB:
dev_dbg(drm->dev, "Setting up XRGB mode\n");
ctrl |= CTRL_WORD_LENGTH_24;
@@ -523,6 +529,7 @@ static const struct drm_plane_funcs mxsfb_plane_funcs = {
 
 static const uint32_t mxsfb_primary_plane_formats[] = {
DRM_FORMAT_RGB565,
+   DRM_FORMAT_RGB888,
    DRM_FORMAT_XRGB,
 };
 
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v3 2/2] drm/tilcdc: Remove tilcdc_crtc_max_width(), use private data

2020-10-11 Thread Laurent Pinchart
Hi Jyri,

Thank you for the patch.

On Sat, Oct 10, 2020 at 08:00:59PM +0300, Jyri Sarha wrote:
> We already have a private data member for maximum display width so
> let's use it and get rid of the redundant tilcdc_crtc_max_width().
> 
> The LCDC version probing is moved to before reading the device tree
> properties so that the version information is available when private
> data maximum width is initialized, if "max-width" property is not
> found.
> 
> Signed-off-by: Jyri Sarha 
> Reviewed-by: Tomi Valkeinen 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 16 +---
>  drivers/gpu/drm/tilcdc/tilcdc_drv.c  | 38 +++-
>  drivers/gpu/drm/tilcdc/tilcdc_drv.h  |  7 ++---
>  3 files changed, 26 insertions(+), 35 deletions(-)
> 
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
> b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> index 0fd3dafe6404..da2ab2aa3577 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> @@ -754,20 +754,6 @@ static const struct drm_crtc_funcs tilcdc_crtc_funcs = {
>   .disable_vblank = tilcdc_crtc_disable_vblank,
>  };
>  
> -int tilcdc_crtc_max_width(struct drm_crtc *crtc)
> -{
> - struct drm_device *dev = crtc->dev;
> - struct tilcdc_drm_private *priv = dev->dev_private;
> - int max_width = 0;
> -
> - if (priv->rev == 1)
> - max_width = 1024;
> - else if (priv->rev == 2)
> - max_width = 2048;
> -
> - return max_width;
> -}
> -
>  static enum drm_mode_status
>  tilcdc_crtc_mode_valid(struct drm_crtc *crtc,
>  const struct drm_display_mode *mode)
> @@ -780,7 +766,7 @@ tilcdc_crtc_mode_valid(struct drm_crtc *crtc,
>* check to see if the width is within the range that
>* the LCD Controller physically supports
>*/
> - if (mode->hdisplay > tilcdc_crtc_max_width(crtc))
> + if (mode->hdisplay > priv->max_width)
>   return MODE_VIRTUAL_X;
>  
>   /* width must be multiple of 16 */
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
> b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> index 4f5fc3e87383..c5f82e693f1a 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> @@ -105,7 +105,7 @@ static void modeset_init(struct drm_device *dev)
>  
>   dev->mode_config.min_width = 0;
>   dev->mode_config.min_height = 0;
> - dev->mode_config.max_width = tilcdc_crtc_max_width(priv->crtc);
> + dev->mode_config.max_width = priv->max_width;
>   dev->mode_config.max_height = 2048;
>   dev->mode_config.funcs = _config_funcs;
>  }
> @@ -218,22 +218,6 @@ static int tilcdc_init(struct drm_driver *ddrv, struct 
> device *dev)
>   goto init_failed;
>   }
>  
> - if (of_property_read_u32(node, "max-bandwidth", >max_bandwidth))
> - priv->max_bandwidth = TILCDC_DEFAULT_MAX_BANDWIDTH;
> -
> - DBG("Maximum Bandwidth Value %d", priv->max_bandwidth);
> -
> - if (of_property_read_u32(node, "max-width", >max_width))
> - priv->max_width = TILCDC_DEFAULT_MAX_WIDTH;
> -
> - DBG("Maximum Horizontal Pixel Width Value %dpixels", priv->max_width);
> -
> - if (of_property_read_u32(node, "max-pixelclock",
> - >max_pixelclock))
> - priv->max_pixelclock = TILCDC_DEFAULT_MAX_PIXELCLOCK;
> -
> - DBG("Maximum Pixel Clock Value %dKHz", priv->max_pixelclock);
> -
>   pm_runtime_enable(dev);
>  
>   /* Determine LCD IP Version */
> @@ -287,6 +271,26 @@ static int tilcdc_init(struct drm_driver *ddrv, struct 
> device *dev)
>   }
>   }
>  
> + if (of_property_read_u32(node, "max-bandwidth", >max_bandwidth))
> + priv->max_bandwidth = TILCDC_DEFAULT_MAX_BANDWIDTH;
> +
> + DBG("Maximum Bandwidth Value %d", priv->max_bandwidth);
> +
> + if (of_property_read_u32(node, "max-width", >max_width)) {
> + if (priv->rev == 1)
> + priv->max_width = TILCDC_DEFAULT_MAX_WIDTH_V1;
> + else
> + priv->max_width = TILCDC_DEFAULT_MAX_WIDTH_V2;
> + }
> +
> + DBG("Maximum Horizontal Pixel Width Value %dpixels", priv->max_width);
> +
> + if (of_property_read_u32(node, "max-pixelclock",
> +  >max_pixelclock))
> + priv->max_pixelclock = TILCDC_DEFAULT_MAX_PIXELCL

Re: [PATCH RESEND v3 1/6] drm/of: Change the prototype of drm_of_lvds_get_dual_link_pixel_order

2020-10-11 Thread Laurent Pinchart
  int endpoint1_id,
> +   const struct device_node *dev2,
> +   int port2_id,
> +   int endpoint2_id);
>  #else
>  static inline uint32_t drm_of_crtc_port_mask(struct drm_device *dev,
> struct device_node *port)
> @@ -93,8 +97,12 @@ static inline int drm_of_find_panel_or_bridge(const struct 
> device_node *np,
>  }
>  
>  static inline int
> -drm_of_lvds_get_dual_link_pixel_order(const struct device_node *port1,
> -   const struct device_node *port2)
> +drm_of_lvds_get_dual_link_pixel_order(const struct device_node *dev1,
> +   int port1_id,
> +   int endpoint1_id,
> +   const struct device_node *dev2,
> +   int port2_id,
> +   int endpoint2_id)
>  {
>   return -EINVAL;
>  }

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] ARM: davinci_all_defconfig: Add CONFIG_DRM_DISPLAY_CONNECTOR=m

2020-10-10 Thread Laurent Pinchart
Hi Jyri,

Thank you for the patch.

On Sat, Oct 10, 2020 at 07:08:50PM +0300, Jyri Sarha wrote:
> Current dumb-vga-dac driver requires CONFIG_DRM_DISPLAY_CONNECTOR
> for it to work.
> 
> Signed-off-by: Jyri Sarha 

Reviewed-by: Laurent Pinchart 

> ---
> An alternative would be selecting CONFIG_DRM_DISPLAY_CONNECTOR from all
> bridges requiring DRM connector.
> 
>  arch/arm/configs/davinci_all_defconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/configs/davinci_all_defconfig 
> b/arch/arm/configs/davinci_all_defconfig
> index e849367c0566..28471757c129 100644
> --- a/arch/arm/configs/davinci_all_defconfig
> +++ b/arch/arm/configs/davinci_all_defconfig
> @@ -160,6 +160,7 @@ CONFIG_DRM=m
>  CONFIG_DRM_TILCDC=m
>  CONFIG_DRM_SIMPLE_BRIDGE=m
>  CONFIG_DRM_TINYDRM=m
> +CONFIG_DRM_DISPLAY_CONNECTOR=m
>  CONFIG_TINYDRM_ST7586=m
>  CONFIG_FB=y
>  CONFIG_FIRMWARE_EDID=y

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 09/17] mm: Add unsafe_follow_pfn

2020-10-10 Thread Laurent Pinchart
Hi Tomasz,

On Sat, Oct 10, 2020 at 07:22:48PM +0200, Tomasz Figa wrote:
> On Fri, Oct 9, 2020 at 7:52 PM Daniel Vetter  wrote:
> > On Fri, Oct 9, 2020 at 2:48 PM Jason Gunthorpe  wrote:
> > > On Fri, Oct 09, 2020 at 02:37:23PM +0200, Mauro Carvalho Chehab wrote:
> > >
> > > > I'm not a mm/ expert, but, from what I understood from Daniel's patch
> > > > description is that this is unsafe *only if*  __GFP_MOVABLE is used.
> > >
> > > No, it is unconditionally unsafe. The CMA movable mappings are
> > > specific VMAs that will have bad issues here, but there are other
> > > types too.
> > >
> > > The only way to do something at a VMA level is to have a list of OK
> > > VMAs, eg because they were creatd via a special mmap helper from the
> > > media subsystem.
> > >
> > > > Well, no drivers inside the media subsystem uses such flag, although
> > > > they may rely on some infrastructure that could be using it behind
> > > > the bars.
> > >
> > > It doesn't matter, nothing prevents the user from calling media APIs
> > > on mmaps it gets from other subsystems.
> >
> > I think a good first step would be to disable userptr of non struct
> > page backed storage going forward for any new hw support. Even on
> > existing drivers. dma-buf sharing has been around for long enough now
> > that this shouldn't be a problem. Unfortunately right now this doesn't
> > seem to exist, so the entire problem keeps getting perpetuated.
> >
> > > > If this is the case, the proper fix seems to have a GFP_NOT_MOVABLE
> > > > flag that it would be denying the core mm code to set __GFP_MOVABLE.
> > >
> > > We can't tell from the VMA these kinds of details..
> > >
> > > It has to go the other direction, evey mmap that might be used as a
> > > userptr here has to be found and the VMA specially created to allow
> > > its use. At least that is a kernel only change, but will need people
> > > with the HW to do this work.
> >
> > I think the only reasonable way to keep this working is:
> > - add a struct dma_buf *vma_tryget_dma_buf(struct vm_area_struct *vma);
> > - add dma-buf export support to fbdev and v4l
> 
> I assume you mean V4L2 and not the obsolete V4L that is emulated in
> the userspace by libv4l. If so, every video device that uses videobuf2
> gets DMA-buf export for free and there is nothing needed to enable it.
> 
> We probably still have a few legacy drivers using videobuf (non-2),
> but IMHO those should be safe to put behind some disabled-by-default
> Kconfig symbol or even completely drop, as the legacy framework has
> been deprecated for many years already.

There's 8 drivers left, and they support a very large number of devices.
I expect unhappy users distros stop shipping them. On the other hand,
videobuf has been deprecated for a lng time, so there has been
plenty of time to convert the remaining drivers to videobuf2. If nobody
can do it, then we'll have to drop support for these devices given the
security issues.

We have moved media drivers to staging in the past when there wasn't
enough maintenance effort, we could do so here too.

> > - roll this out everywhere we still need it.
> >
> > Realistically this just isn't going to happen. And anything else just
> > reimplements half of dma-buf, which is kinda pointless (you need
> > minimally refcounting and some way to get at a promise of a permanent
> > sg list for dma. Plus probably the vmap for kernel cpu access.
> >
> > > > Please let address the issue on this way, instead of broken an
> > > > userspace API that it is there since 1991.
> > >
> > > It has happened before :( It took 4 years for RDMA to undo the uAPI
> > > breakage caused by a security fix for something that was a 15 years
> > > old bug.
> >
> > Yeah we have a bunch of these on the drm side too. Some of them are
> > really just "you have to upgrade userspace", and there's no real fix
> > for the security nightmare without that.
> 
> I think we need to phase out such userspace indeed. The Kconfig symbol
> allows enabling the unsafe functionality for anyone who still needs
> it, so I think it's not entirely a breakage.

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 09/17] mm: Add unsafe_follow_pfn

2020-10-10 Thread Laurent Pinchart
Hi Daniel,

On Fri, Oct 09, 2020 at 07:52:05PM +0200, Daniel Vetter wrote:
> On Fri, Oct 9, 2020 at 2:48 PM Jason Gunthorpe  wrote:
> > On Fri, Oct 09, 2020 at 02:37:23PM +0200, Mauro Carvalho Chehab wrote:
> >
> > > I'm not a mm/ expert, but, from what I understood from Daniel's patch
> > > description is that this is unsafe *only if*  __GFP_MOVABLE is used.
> >
> > No, it is unconditionally unsafe. The CMA movable mappings are
> > specific VMAs that will have bad issues here, but there are other
> > types too.
> >
> > The only way to do something at a VMA level is to have a list of OK
> > VMAs, eg because they were creatd via a special mmap helper from the
> > media subsystem.
> >
> > > Well, no drivers inside the media subsystem uses such flag, although
> > > they may rely on some infrastructure that could be using it behind
> > > the bars.
> >
> > It doesn't matter, nothing prevents the user from calling media APIs
> > on mmaps it gets from other subsystems.
> 
> I think a good first step would be to disable userptr of non struct
> page backed storage going forward for any new hw support. Even on
> existing drivers. dma-buf sharing has been around for long enough now
> that this shouldn't be a problem. Unfortunately right now this doesn't
> seem to exist, so the entire problem keeps getting perpetuated.

On the V4L2 side, I think we should disable USERPTR for any new driver,
period. That's what I've been recommended when reviewing patches for
several years already. It's a deprecated API, it should be phased out,
which starts by not allowing any new use case.

> > > If this is the case, the proper fix seems to have a GFP_NOT_MOVABLE
> > > flag that it would be denying the core mm code to set __GFP_MOVABLE.
> >
> > We can't tell from the VMA these kinds of details..
> >
> > It has to go the other direction, evey mmap that might be used as a
> > userptr here has to be found and the VMA specially created to allow
> > its use. At least that is a kernel only change, but will need people
> > with the HW to do this work.
> 
> I think the only reasonable way to keep this working is:
> - add a struct dma_buf *vma_tryget_dma_buf(struct vm_area_struct *vma);
> - add dma-buf export support to fbdev and v4l
> - roll this out everywhere we still need it.
> 
> Realistically this just isn't going to happen. And anything else just
> reimplements half of dma-buf, which is kinda pointless (you need
> minimally refcounting and some way to get at a promise of a permanent
> sg list for dma. Plus probably the vmap for kernel cpu access.
> 
> > > Please let address the issue on this way, instead of broken an
> > > userspace API that it is there since 1991.
> >
> > It has happened before :( It took 4 years for RDMA to undo the uAPI
> > breakage caused by a security fix for something that was a 15 years
> > old bug.
> 
> Yeah we have a bunch of these on the drm side too. Some of them are
> really just "you have to upgrade userspace", and there's no real fix
> for the security nightmare without that.

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 8/7] dt-bindings: display: mxsfb: Add compatible for i.MX8MM

2020-10-09 Thread Laurent Pinchart
From: Marek Vasut 

NXP's i.MX8MM has an LCDIF as well.

Signed-off-by: Marek Vasut 
Reviewed-by: Laurent Pinchart 
Signed-off-by: Laurent Pinchart 
---
Changes since v1:

- Rebased on top of the YAML conversion
---
 Documentation/devicetree/bindings/display/fsl,lcdif.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml 
b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
index 404bd516b7f5..c1690ae7 100644
--- a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
+++ b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
@@ -26,6 +26,7 @@ properties:
 - fsl,imx6sll-lcdif
 - fsl,imx6ul-lcdif
 - fsl,imx7d-lcdif
+- fsl,imx8mm-lcdif
 - fsl,imx8mq-lcdif
 - const: fsl,imx6sx-lcdif
 
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 3/7] dt-bindings: display: mxsfb: Add a bus-width endpoint property

2020-10-09 Thread Laurent Pinchart
Hi Marek,

On Wed, Oct 07, 2020 at 10:40:26AM +0200, Marek Vasut wrote:
> On 10/7/20 3:24 AM, Laurent Pinchart wrote:
> 
> [...]
> 
> > +  bus-width:
> > +enum: [16, 18, 24]
> > +description: |
> > +  The output bus width. This value overrides the configuration
> > +  derived from the connected device (encoder or panel). It 
> > should
> > +  only be specified when PCB routing of the data signals 
> > require a
> > +  different bus width on the LCDIF and the connected device. 
> > For
> > +  instance, when a 18-bit RGB panel has its R[5:0], G[5:0] and
> > +  B[5:0] signals connected to LCD_DATA[7:2], LCD_DATA[15:10] 
> > and
> > +  LCD_DATA[23:18] instead of LCD_DATA[5:0], LCD_DATA[11:6] and
> > +  LCD_DATA[17:12], bus-width should be set to 24.
> 
> The iMX6 IPUv3 uses interface-pix-fmt which is a bit more flexible, but
> I'm not sure whether it's the right way to go about this, see:
> Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt

I think specifying the bus with is better. It's a standard property, but
more than that, a given bus width can carry different formats. For
instance, a 24-bus could carry RGB666 data (with dithering for the
LSBs).

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 1/7] dt-bindings: display: mxsfb: Convert binding to YAML

2020-10-09 Thread Laurent Pinchart
Hi Rob,

On Wed, Oct 07, 2020 at 11:00:20AM -0500, Rob Herring wrote:
> On Wed, Oct 07, 2020 at 04:24:32AM +0300, Laurent Pinchart wrote:
> > Convert the mxsfb binding to YAML. The deprecated binding is dropped, as
> > neither the DT sources nor the driver support it anymore. The converted
> > binding is named fsl,lcdif.yaml to match the usual bindings naming
> > scheme.
> > 
> > The compatible strings are messy, and DT sources use different kinds of
> > combination of documented and undocumented values. Keep it simple for
> > now, and update the example to make it valid. Aligning the binding with
> > the existing DT sources will be performed separately.
> > 
> > Signed-off-by: Laurent Pinchart 
> > Reviewed-by: Sam Ravnborg 
> > --
> > Changes since v1:
> > 
> > - Drop unneeded quotes in string
> > - Replace minItems with maxItems in conditional check
> > - Add blank line before ...
> > - Squash the rename in this commit
> > ---
> >  .../bindings/display/fsl,lcdif.yaml   | 116 ++
> >  .../devicetree/bindings/display/mxsfb.txt |  87 -
> >  MAINTAINERS   |   2 +-
> >  3 files changed, 117 insertions(+), 88 deletions(-)
> >  create mode 100644 Documentation/devicetree/bindings/display/fsl,lcdif.yaml
> >  delete mode 100644 Documentation/devicetree/bindings/display/mxsfb.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml 
> > b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
> > new file mode 100644
> > index ..063bb8c58114
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
> > @@ -0,0 +1,116 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/fsl,lcdif.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Freescale/NXP i.MX LCD Interface (LCDIF)
> > +
> > +maintainers:
> > +  - Marek Vasut 
> > +  - Stefan Agner 
> > +
> > +description: |
> > +  (e)LCDIF display controller found in the Freescale/NXP i.MX SoCs.
> > +
> > +properties:
> > +  compatible:
> > +enum:
> > +  - fsl,imx23-lcdif
> > +  - fsl,imx28-lcdif
> > +  - fsl,imx6sx-lcdif
> > +  - fsl,imx8mq-lcdif
> > +
> > +  reg:
> > +maxItems: 1
> > +
> > +  clocks:
> > +items:
> > +  - description: Pixel clock
> > +  - description: Bus clock
> > +  - description: Display AXI clock
> > +minItems: 1
> > +
> > +  clock-names:
> > +items:
> > +  - const: pix
> > +  - const: axi
> > +  - const: disp_axi
> > +minItems: 1
> > +
> > +  interrupts:
> > +maxItems: 1
> > +
> > +  port:
> > +description: The LCDIF output port
> > +type: object
> > +
> > +properties:
> > +  endpoint:
> 
> What happened on the graph binding schema work?

Still on my todo list, I hope to switch back to that task in the not too
distant future.

> I started a meta-schema for it BTW.

Nice :-) Is it available in a public tree ?

> You can drop all the endpoint parts. With that,
> 
> Reviewed-by: Rob Herring 
> 
> > +type: object
> > +
> > +properties:
> > +  remote-endpoint:
> > +$ref: /schemas/types.yaml#/definitions/phandle
> > +
> > +required:
> > +  - remote-endpoint
> > +
> > +additionalProperties: false
> > +
> > +additionalProperties: false
> > +
> > +required:
> > +  - compatible
> > +  - reg
> > +  - clocks
> > +  - interrupts
> > +  - port
> > +
> > +additionalProperties: false
> > +
> > +allOf:
> > +  - if:
> > +  properties:
> > +compatible:
> > +  contains:
> > +const: fsl,imx6sx-lcdif
> > +then:
> > +  properties:
> > +clocks:
> > +  minItems: 2
> > +  maxItems: 3
> > +clock-names:
> > +  minItems: 2
> > +  maxItems: 3
> > +  required:
> > +- clock-names
> > +else:
> > +  properties:
> > +clocks:
> > +  maxItems: 1
> > +clock-names:
> > +  maxItems: 1
> > +
> > +examples:
> > +  - |
> > +#include 
> > +#in

Re: [PATCH v2 1/7] dt-bindings: display: mxsfb: Convert binding to YAML

2020-10-07 Thread Laurent Pinchart
Hi Marek,

On Wed, Oct 07, 2020 at 10:55:24AM +0200, Marek Vasut wrote:
> On 10/7/20 10:43 AM, Lucas Stach wrote:
> > On Mi, 2020-10-07 at 10:32 +0200, Marek Vasut wrote:
> >> On 10/7/20 3:24 AM, Laurent Pinchart wrote:
> >> [...]
> >>> +properties:
> >>> +  compatible:
> >>> +enum:
> >>> +  - fsl,imx23-lcdif
> >>> +  - fsl,imx28-lcdif
> >>> +  - fsl,imx6sx-lcdif
> >>> +  - fsl,imx8mq-lcdif
> >>
> >> There is no fsl,imx8mq-lcdif in drivers/gpu/drm/mxsfb/mxsfb_drv.c,
> >> so the DT must specify compatible = "fsl,imx8mq-lcdif",
> >> "fsl,imx28-lcdif" (since imx28 is the oldest SoC with LCDIF V4).
> >>
> >> Should the compatible be added to drivers/gpu/drm/mxsfb/mxsfb_drv.c or
> >> dropped from the YAML file or neither ?
> > 
> > Neither. As far as we know the block is compatible, so the DT should
> > claim that it's compatible to "fsl,imx28-lcdif". However we don't know
> > if there are any surprises, so we add the SoC specific compatible to be
> > able to change the driver matching later without changing the DT if the
> > need arises. For the DT validation to pass the SoC specific compatible 
> > needs to be documented, even if it currently unused by the driver.
> 
> What in that binding says you should specify compatible =
> "fsl,imx8mq-lcdif", "fsl,imx28-lcdif"; and not e.g. "fsl,imx8mq-lcdif",
> "fsl,imx23-lcdif" or simply "fsl,imx8mq-lcdif" ?

Nothing, until the next patch :-) This patch only handles the YAML
conversion but doesn't fix issues.

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 1/7] dt-bindings: display: mxsfb: Convert binding to YAML

2020-10-06 Thread Laurent Pinchart
Convert the mxsfb binding to YAML. The deprecated binding is dropped, as
neither the DT sources nor the driver support it anymore. The converted
binding is named fsl,lcdif.yaml to match the usual bindings naming
scheme.

The compatible strings are messy, and DT sources use different kinds of
combination of documented and undocumented values. Keep it simple for
now, and update the example to make it valid. Aligning the binding with
the existing DT sources will be performed separately.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Sam Ravnborg 
--
Changes since v1:

- Drop unneeded quotes in string
- Replace minItems with maxItems in conditional check
- Add blank line before ...
- Squash the rename in this commit
---
 .../bindings/display/fsl,lcdif.yaml   | 116 ++
 .../devicetree/bindings/display/mxsfb.txt |  87 -
 MAINTAINERS   |   2 +-
 3 files changed, 117 insertions(+), 88 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/display/fsl,lcdif.yaml
 delete mode 100644 Documentation/devicetree/bindings/display/mxsfb.txt

diff --git a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml 
b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
new file mode 100644
index ..063bb8c58114
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
@@ -0,0 +1,116 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/fsl,lcdif.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale/NXP i.MX LCD Interface (LCDIF)
+
+maintainers:
+  - Marek Vasut 
+  - Stefan Agner 
+
+description: |
+  (e)LCDIF display controller found in the Freescale/NXP i.MX SoCs.
+
+properties:
+  compatible:
+enum:
+  - fsl,imx23-lcdif
+  - fsl,imx28-lcdif
+  - fsl,imx6sx-lcdif
+  - fsl,imx8mq-lcdif
+
+  reg:
+maxItems: 1
+
+  clocks:
+items:
+  - description: Pixel clock
+  - description: Bus clock
+  - description: Display AXI clock
+minItems: 1
+
+  clock-names:
+items:
+  - const: pix
+  - const: axi
+  - const: disp_axi
+minItems: 1
+
+  interrupts:
+maxItems: 1
+
+  port:
+description: The LCDIF output port
+type: object
+
+properties:
+  endpoint:
+type: object
+
+properties:
+  remote-endpoint:
+$ref: /schemas/types.yaml#/definitions/phandle
+
+required:
+  - remote-endpoint
+
+additionalProperties: false
+
+additionalProperties: false
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - interrupts
+  - port
+
+additionalProperties: false
+
+allOf:
+  - if:
+  properties:
+compatible:
+  contains:
+const: fsl,imx6sx-lcdif
+then:
+  properties:
+clocks:
+  minItems: 2
+  maxItems: 3
+clock-names:
+  minItems: 2
+  maxItems: 3
+  required:
+- clock-names
+else:
+  properties:
+clocks:
+  maxItems: 1
+clock-names:
+  maxItems: 1
+
+examples:
+  - |
+#include 
+#include 
+
+display-controller@222 {
+compatible = "fsl,imx6sx-lcdif";
+reg = <0x0222 0x4000>;
+interrupts = ;
+clocks = < IMX6SX_CLK_LCDIF1_PIX>,
+ < IMX6SX_CLK_LCDIF_APB>,
+ < IMX6SX_CLK_DISPLAY_AXI>;
+clock-names = "pix", "axi", "disp_axi";
+
+port {
+endpoint {
+remote-endpoint = <_in>;
+};
+};
+};
+
+...
diff --git a/Documentation/devicetree/bindings/display/mxsfb.txt 
b/Documentation/devicetree/bindings/display/mxsfb.txt
deleted file mode 100644
index c985871c46b3..
--- a/Documentation/devicetree/bindings/display/mxsfb.txt
+++ /dev/null
@@ -1,87 +0,0 @@
-* Freescale MXS LCD Interface (LCDIF)
-
-New bindings:
-=
-Required properties:
-- compatible:  Should be "fsl,imx23-lcdif" for i.MX23.
-   Should be "fsl,imx28-lcdif" for i.MX28.
-   Should be "fsl,imx6sx-lcdif" for i.MX6SX.
-   Should be "fsl,imx8mq-lcdif" for i.MX8MQ.
-- reg: Address and length of the register set for LCDIF
-- interrupts:  Should contain LCDIF interrupt
-- clocks:  A list of phandle + clock-specifier pairs, one for each
-   entry in 'clock-names'.
-- clock-names: A list of clock names. For MXSFB it should contain:
-- "pix" for the LCDIF block clock
-- (MX6SX-only) "axi", "disp_axi" for the bus interface clock
-
-Required sub-nodes:
-  - port: The connection to an encoder chip.
-
-Example:
-
-   lcdif1: display-controller@222 {
-   compatible = "fsl,imx6sx-lcdi

[PATCH v2 6/7] ARM: dts: imx: Remove unneeded LCDIF disp_axi clock

2020-10-06 Thread Laurent Pinchart
The LCDIF disp_axi clock is not mandatory in the DT binding and not
required by the driver. Remove it when it points to a dummy clock.

Signed-off-by: Laurent Pinchart 
Acked-by: Sam Ravnborg 
---
 arch/arm/boot/dts/imx6sl.dtsi  | 5 ++---
 arch/arm/boot/dts/imx6sll.dtsi | 5 ++---
 arch/arm/boot/dts/imx6ul.dtsi  | 5 ++---
 3 files changed, 6 insertions(+), 9 deletions(-)

diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index 1e506ffbcecc..27d8061e06af 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -773,9 +773,8 @@ lcdif: lcdif@20f8000 {
reg = <0x020f8000 0x4000>;
interrupts = <0 39 IRQ_TYPE_LEVEL_HIGH>;
clocks = < IMX6SL_CLK_LCDIF_PIX>,
-< IMX6SL_CLK_LCDIF_AXI>,
-< IMX6SL_CLK_DUMMY>;
-   clock-names = "pix", "axi", "disp_axi";
+< IMX6SL_CLK_LCDIF_AXI>;
+   clock-names = "pix", "axi";
status = "disabled";
power-domains = <_disp>;
};
diff --git a/arch/arm/boot/dts/imx6sll.dtsi b/arch/arm/boot/dts/imx6sll.dtsi
index 81137ba427a1..80c7ef5af435 100644
--- a/arch/arm/boot/dts/imx6sll.dtsi
+++ b/arch/arm/boot/dts/imx6sll.dtsi
@@ -648,9 +648,8 @@ lcdif: lcd-controller@20f8000 {
reg = <0x020f8000 0x4000>;
interrupts = ;
clocks = < IMX6SLL_CLK_LCDIF_PIX>,
-< IMX6SLL_CLK_LCDIF_APB>,
-< IMX6SLL_CLK_DUMMY>;
-   clock-names = "pix", "axi", "disp_axi";
+< IMX6SLL_CLK_LCDIF_APB>;
+   clock-names = "pix", "axi";
status = "disabled";
};
 
diff --git a/arch/arm/boot/dts/imx6ul.dtsi b/arch/arm/boot/dts/imx6ul.dtsi
index 776493923474..6ecdbf9f63c6 100644
--- a/arch/arm/boot/dts/imx6ul.dtsi
+++ b/arch/arm/boot/dts/imx6ul.dtsi
@@ -1007,9 +1007,8 @@ lcdif: lcdif@21c8000 {
reg = <0x021c8000 0x4000>;
interrupts = ;
clocks = < IMX6UL_CLK_LCDIF_PIX>,
-< IMX6UL_CLK_LCDIF_APB>,
-< IMX6UL_CLK_DUMMY>;
-   clock-names = "pix", "axi", "disp_axi";
+< IMX6UL_CLK_LCDIF_APB>;
+   clock-names = "pix", "axi";
status = "disabled";
};
 
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 7/7] drm: mxsfb: Add support for the bus-width DT property

2020-10-06 Thread Laurent Pinchart
A new bus-width DT property has been introduced in the bindings to allow
overriding the bus width. Support it.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/mxsfb/mxsfb_drv.c | 26 ++
 drivers/gpu/drm/mxsfb/mxsfb_drv.h |  2 ++
 drivers/gpu/drm/mxsfb/mxsfb_kms.c |  8 ++--
 3 files changed, 34 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c 
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index 35122aef037b..d52cf8a506a5 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -114,10 +114,36 @@ static int mxsfb_attach_bridge(struct mxsfb_drm_private 
*mxsfb)
 {
struct drm_device *drm = mxsfb->drm;
struct drm_connector_list_iter iter;
+   struct device_node *ep;
struct drm_panel *panel;
struct drm_bridge *bridge;
+   u32 bus_width = 0;
int ret;
 
+   ep = of_graph_get_endpoint_by_regs(drm->dev->of_node, 0, 0);
+   if (!ep)
+   return -ENODEV;
+
+   of_property_read_u32(ep, "bus-width", _width);
+   of_node_put(ep);
+
+   switch (bus_width) {
+   case 16:
+   mxsfb->bus_format = MEDIA_BUS_FMT_RGB565_1X16;
+   break;
+   case 18:
+   mxsfb->bus_format = MEDIA_BUS_FMT_RGB666_1X18;
+   break;
+   case 24:
+   mxsfb->bus_format = MEDIA_BUS_FMT_RGB888_1X24;
+   break;
+   case 0:
+   break;
+   default:
+   DRM_DEV_ERROR(drm->dev, "Invalid bus-width %u", bus_width);
+   return -ENODEV;
+   }
+
ret = drm_of_find_panel_or_bridge(drm->dev->of_node, 0, 0, ,
  );
if (ret)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.h 
b/drivers/gpu/drm/mxsfb/mxsfb_drv.h
index 399d23e91ed1..c4f7a8a0c891 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.h
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.h
@@ -32,6 +32,8 @@ struct mxsfb_drm_private {
struct clk  *clk_axi;
struct clk  *clk_disp_axi;
 
+   u32 bus_format;
+
struct drm_device   *drm;
struct {
struct drm_planeprimary;
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c 
b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
index b721b8b262ce..6d512f346918 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
@@ -50,11 +50,15 @@ static void mxsfb_set_formats(struct mxsfb_drm_private 
*mxsfb)
 {
struct drm_device *drm = mxsfb->drm;
const u32 format = mxsfb->crtc.primary->state->fb->format->format;
-   u32 bus_format = MEDIA_BUS_FMT_RGB888_1X24;
+   u32 bus_format;
u32 ctrl, ctrl1;
 
-   if (mxsfb->connector->display_info.num_bus_formats)
+   if (mxsfb->bus_format)
+   bus_format = mxsfb->bus_format;
+   else if (mxsfb->connector->display_info.num_bus_formats)
bus_format = mxsfb->connector->display_info.bus_formats[0];
+   else
+   bus_format = MEDIA_BUS_FMT_RGB888_1X24;
 
DRM_DEV_DEBUG_DRIVER(drm->dev, "Using bus_format: 0x%08X\n",
 bus_format);
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 4/7] ARM: dts: imx: Fix LCDIF compatible strings

2020-10-06 Thread Laurent Pinchart
The LCDIF in the i.MX6 SoCs has additional features compared to the
i.MX28. Replace the fsl,imx28-lcdif fallback compatible string with
fsl,imx6sx-lcdif to reflect that.

Signed-off-by: Laurent Pinchart 
Acked-by: Sam Ravnborg 
---
 arch/arm/boot/dts/imx6sl.dtsi  | 2 +-
 arch/arm/boot/dts/imx6sll.dtsi | 2 +-
 arch/arm/boot/dts/imx6sx.dtsi  | 4 ++--
 arch/arm/boot/dts/imx6ul.dtsi  | 2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index 1c7180f28539..1e506ffbcecc 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -769,7 +769,7 @@ epdc: epdc@20f4000 {
};
 
lcdif: lcdif@20f8000 {
-   compatible = "fsl,imx6sl-lcdif", 
"fsl,imx28-lcdif";
+   compatible = "fsl,imx6sl-lcdif", 
"fsl,imx6sx-lcdif";
reg = <0x020f8000 0x4000>;
interrupts = <0 39 IRQ_TYPE_LEVEL_HIGH>;
clocks = < IMX6SL_CLK_LCDIF_PIX>,
diff --git a/arch/arm/boot/dts/imx6sll.dtsi b/arch/arm/boot/dts/imx6sll.dtsi
index fb5d3bc50c6b..81137ba427a1 100644
--- a/arch/arm/boot/dts/imx6sll.dtsi
+++ b/arch/arm/boot/dts/imx6sll.dtsi
@@ -644,7 +644,7 @@ pxp: pxp@20f {
};
 
lcdif: lcd-controller@20f8000 {
-   compatible = "fsl,imx6sll-lcdif", 
"fsl,imx28-lcdif";
+   compatible = "fsl,imx6sll-lcdif", 
"fsl,imx6sx-lcdif";
reg = <0x020f8000 0x4000>;
interrupts = ;
clocks = < IMX6SLL_CLK_LCDIF_PIX>,
diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
index b480dfa9e251..1f2b1c56757b 100644
--- a/arch/arm/boot/dts/imx6sx.dtsi
+++ b/arch/arm/boot/dts/imx6sx.dtsi
@@ -1261,7 +1261,7 @@ csi2: csi@221c000 {
};
 
lcdif1: lcdif@222 {
-   compatible = "fsl,imx6sx-lcdif", 
"fsl,imx28-lcdif";
+   compatible = "fsl,imx6sx-lcdif";
reg = <0x0222 0x4000>;
interrupts = ;
clocks = < IMX6SX_CLK_LCDIF1_PIX>,
@@ -1273,7 +1273,7 @@ lcdif1: lcdif@222 {
};
 
lcdif2: lcdif@2224000 {
-   compatible = "fsl,imx6sx-lcdif", 
"fsl,imx28-lcdif";
+   compatible = "fsl,imx6sx-lcdif";
reg = <0x02224000 0x4000>;
interrupts = ;
clocks = < IMX6SX_CLK_LCDIF2_PIX>,
diff --git a/arch/arm/boot/dts/imx6ul.dtsi b/arch/arm/boot/dts/imx6ul.dtsi
index 2b088f210331..776493923474 100644
--- a/arch/arm/boot/dts/imx6ul.dtsi
+++ b/arch/arm/boot/dts/imx6ul.dtsi
@@ -1003,7 +1003,7 @@ csi: csi@21c4000 {
};
 
lcdif: lcdif@21c8000 {
-   compatible = "fsl,imx6ul-lcdif", 
"fsl,imx28-lcdif";
+   compatible = "fsl,imx6ul-lcdif", 
"fsl,imx6sx-lcdif";
reg = <0x021c8000 0x4000>;
interrupts = ;
clocks = < IMX6UL_CLK_LCDIF_PIX>,
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 5/7] arm64: dts: imx8mq: Fix LCDIF compatible strings

2020-10-06 Thread Laurent Pinchart
The LCDIF in the i.MX8 SoCs has additional features compared to the
i.MX28. Replace the fsl,imx28-lcdif fallback compatible string with
fsl,imx6sx-lcdif to reflect that.

Signed-off-by: Laurent Pinchart 
Acked-by: Sam Ravnborg 
---
 arch/arm64/boot/dts/freescale/imx8mq.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi 
b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
index 561fa792fe5a..5c7f4c0de7ca 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
@@ -509,7 +509,7 @@ sdma2: sdma@302c {
};
 
lcdif: lcd-controller@3032 {
-   compatible = "fsl,imx8mq-lcdif", 
"fsl,imx28-lcdif";
+   compatible = "fsl,imx8mq-lcdif", 
"fsl,imx6sx-lcdif";
reg = <0x3032 0x1>;
interrupts = ;
clocks = < IMX8MQ_CLK_LCDIF_PIXEL>;
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 3/7] dt-bindings: display: mxsfb: Add a bus-width endpoint property

2020-10-06 Thread Laurent Pinchart
When the PCB routes the display data signals in an unconventional way,
the output bus width may differ from the bus width of the connected
panel or encoder. For instance, when a 18-bit RGB panel has its R[5:0],
G[5:0] and B[5:0] signals connected to LCD_DATA[7:2], LCD_DATA[15:10]
and LCD_DATA[23:18], the output bus width is 24 instead of 18 when the
signals are routed to LCD_DATA[5:0], LCD_DATA[11:6] and LCD_DATA[17:12].

Add a bus-width property to describe this data routing.

Signed-off-by: Laurent Pinchart 
---
Changes since v1:

- Fix property name in binding
---
 .../devicetree/bindings/display/fsl,lcdif.yaml   | 12 
 1 file changed, 12 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml 
b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
index 404bd516b7f5..14b6103a9bd1 100644
--- a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
+++ b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
@@ -58,6 +58,18 @@ properties:
 type: object
 
 properties:
+  bus-width:
+enum: [16, 18, 24]
+description: |
+  The output bus width. This value overrides the configuration
+  derived from the connected device (encoder or panel). It should
+  only be specified when PCB routing of the data signals require a
+  different bus width on the LCDIF and the connected device. For
+  instance, when a 18-bit RGB panel has its R[5:0], G[5:0] and
+  B[5:0] signals connected to LCD_DATA[7:2], LCD_DATA[15:10] and
+  LCD_DATA[23:18] instead of LCD_DATA[5:0], LCD_DATA[11:6] and
+  LCD_DATA[17:12], bus-width should be set to 24.
+
   remote-endpoint:
 $ref: /schemas/types.yaml#/definitions/phandle
 
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 0/7] drm: mxsfb: Allow overriding bus width

2020-10-06 Thread Laurent Pinchart
Hello,

This patch series adds support to the mxsfb driver for bus width
override. The need came from a hardware platform where a 18-bpp panel
had the R[5:0], G[5:0] and B[5:0] signals connected to LCD_DATA[7:2],
LCD_DATA[15:10] and LCD_DATA[23:18] instead of LCD_DATA[5:0],
LCD_DATA[11:6] and LCD_DATA[17:12]. The bus width, automatically
configured to 18 by querying the panel, is incorrect in this case, and
needs to be set to 24.

To solve this issue, a new bus-width DT property is added to the mxsfb
DT binding. Patch 1/7 first converts the binding to YAML, with a fix for
the compatible string values in 2/7. Patch 3/7 then adds the new
property.

Patches 4/7 to 5/7 then fix the DT sources to match the LCDIF bindings,
as I noticed during the conversion that the compatible strings were
badly managed (see patch 2/7 for a longer explanation). Patch 6/7 drops
an unused clock from DT sources.

Patch 7/7 finally adds support for the bus-width property to the mxsfb
driver.

Changes compared to v1 are minor and are listed in individual patches.

Laurent Pinchart (7):
  dt-bindings: display: mxsfb: Convert binding to YAML
  dt-bindings: display: mxsfb: Add and fix compatible strings
  dt-bindings: display: mxsfb: Add a bus-width endpoint property
  ARM: dts: imx: Fix LCDIF compatible strings
  arm64: dts: imx8mq: Fix LCDIF compatible strings
  ARM: dts: imx: Remove unneeded LCDIF disp_axi clock
  drm: mxsfb: Add support for the bus-width DT property

 .../bindings/display/fsl,lcdif.yaml   | 136 ++
 .../devicetree/bindings/display/mxsfb.txt |  87 ---
 MAINTAINERS   |   2 +-
 arch/arm/boot/dts/imx6sl.dtsi |   7 +-
 arch/arm/boot/dts/imx6sll.dtsi|   7 +-
 arch/arm/boot/dts/imx6sx.dtsi |   4 +-
 arch/arm/boot/dts/imx6ul.dtsi |   7 +-
 arch/arm64/boot/dts/freescale/imx8mq.dtsi |   2 +-
 drivers/gpu/drm/mxsfb/mxsfb_drv.c |  26 
 drivers/gpu/drm/mxsfb/mxsfb_drv.h |   2 +
 drivers/gpu/drm/mxsfb/mxsfb_kms.c |   8 +-
 11 files changed, 183 insertions(+), 105 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/display/fsl,lcdif.yaml
 delete mode 100644 Documentation/devicetree/bindings/display/mxsfb.txt

-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 2/7] dt-bindings: display: mxsfb: Add and fix compatible strings

2020-10-06 Thread Laurent Pinchart
Additional compatible strings have been added in DT source for the
i.MX6SL, i.MX6SLL, i.MX6UL and i.MX7D without updating the bindings.
Most of the upstream DT sources use the fsl,imx28-lcdif compatible
string, which mostly predates the realization that the LCDIF in the
i.MX6 and newer SoCs have extra features compared to the i.MX28.

Update the bindings to add the missing compatible strings, with the
correct fallback values. This fails to validate some of the upstream DT
sources. Instead of adding the incorrect compatible fallback to the
binding, the sources should be updated separately.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Sam Ravnborg 
---
Changes since v1:

- Fix indentation under enum
---
 .../devicetree/bindings/display/fsl,lcdif.yaml | 18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml 
b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
index 063bb8c58114..404bd516b7f5 100644
--- a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
+++ b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
@@ -15,11 +15,19 @@ description: |
 
 properties:
   compatible:
-enum:
-  - fsl,imx23-lcdif
-  - fsl,imx28-lcdif
-  - fsl,imx6sx-lcdif
-  - fsl,imx8mq-lcdif
+oneOf:
+  - enum:
+  - fsl,imx23-lcdif
+  - fsl,imx28-lcdif
+  - fsl,imx6sx-lcdif
+  - items:
+- enum:
+- fsl,imx6sl-lcdif
+- fsl,imx6sll-lcdif
+- fsl,imx6ul-lcdif
+- fsl,imx7d-lcdif
+- fsl,imx8mq-lcdif
+- const: fsl,imx6sx-lcdif
 
   reg:
 maxItems: 1
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 2/8] dt-bindings: display: mxsfb: Add and fix compatible strings

2020-10-06 Thread Laurent Pinchart
Hi Stefan,

On Mon, Aug 24, 2020 at 04:19:23PM +0200, Stefan Agner wrote:
> On 2020-08-24 01:26, Laurent Pinchart wrote:
> > On Fri, Aug 21, 2020 at 04:53:56PM +0200, Stefan Agner wrote:
> >> On 2020-08-13 03:29, Laurent Pinchart wrote:
> >> > Additional compatible strings have been added in DT source for the
> >> > i.MX6SL, i.MX6SLL, i.MX6UL and i.MX7D without updating the bindings.
> >> > Most of the upstream DT sources use the fsl,imx28-lcdif compatible
> >> > string, which mostly predates the realization that the LCDIF in the
> >> > i.MX6 and newer SoCs have extra features compared to the i.MX28.
> >>
> >> Agreed, we should add fsl,imx6sx-lcdif for those devices.
> >>
> >> But shouldn't we also keep fsl,imx28-lcdif? From what I can tell, the
> >> devices can be driven by a driver only supporting fsl,imx28-lcdif
> >> semantics, right?
> > 
> > Isn't it kept by this patch ?
> > 
> >> > Update the bindings to add the missing compatible strings, with the
> >> > correct fallback values. This fails to validate some of the upstream DT
> >> > sources. Instead of adding the incorrect compatible fallback to the
> >> > binding, the sources should be updated separately.
> >> >
> >> > Signed-off-by: Laurent Pinchart 
> >> > ---
> >> >  .../devicetree/bindings/display/mxsfb.yaml | 18 +-
> >> >  1 file changed, 13 insertions(+), 5 deletions(-)
> >> >
> >> > diff --git a/Documentation/devicetree/bindings/display/mxsfb.yaml
> >> > b/Documentation/devicetree/bindings/display/mxsfb.yaml
> >> > index 202381ec5bb7..ec6533b1d4a3 100644
> >> > --- a/Documentation/devicetree/bindings/display/mxsfb.yaml
> >> > +++ b/Documentation/devicetree/bindings/display/mxsfb.yaml
> >> > @@ -15,11 +15,19 @@ description: |
> >> >
> >> >  properties:
> >> >compatible:
> >> > -enum:
> >> > -  - fsl,imx23-lcdif
> >> > -  - fsl,imx28-lcdif
> >> > -  - fsl,imx6sx-lcdif
> >> > -  - fsl,imx8mq-lcdif
> >> > +oneOf:
> >> > +  - enum:
> >> > +  - fsl,imx23-lcdif
> >> > +  - fsl,imx28-lcdif
> > 
> > Here -^
> > 
> > The binding now support any of "fsl,imx23-lcdif", "fsl,imx28-lcdif" or
> > "fsl,imx6sx-lcdif" alone, or "fsl,imx6sx-lcdif" with another
> > device-specific compatible string. The driver supports the three base
> > compatible strings, for V3, V4 and V6 of the IP core.
> 
> The binding yes, but I mean the device descriptions in the device tree.
> 
> Since the device can be driven by a older kernel which only knows about
> the fsl,imx28-lcdif compatible string, we could keep that compatible.

I don't think we need to care about forward-compatibility. If one
updates the device tree, it's expected that the kernel should be updated
accordingly. The bindings should in my opinion document the current
recommended device tree properties, drivers have to ensure backward
compatibility with older DT, but the other way around shouldn't be
required.

> From what I can tell, we can add both safely, e.g.
> 
> compatible = "fsl,imx6sx-lcdif", "fsl,imx28-lcdif"
> 
> From how I read the description this now replaces "fsl,imx28-lcdif" with
> "fsl,imx6sx-lcdif" for the devices supporting the additional features,
> e.g.:
> 
> --- a/arch/arm/boot/dts/imx6sl.dtsi
> +++ b/arch/arm/boot/dts/imx6sl.dtsi
> @@ -769,7 +769,7 @@ epdc: epdc@20f4000 {
>  };
>  
>  lcdif: lcdif@20f8000 {
> -        compatible = "fsl,imx6sl-lcdif", "fsl,imx28-lcdif";
> +compatible = "fsl,imx6sl-lcdif", "fsl,imx6sx-lcdif";
>  reg = <0x020f8000 0x4000>;
>  interrupts = <0 39 IRQ_TYPE_LEVEL_HIGH>;
>  clocks = < IMX6SL_CLK_LCDIF_PIX>,
> 
> >> > +  - fsl,imx6sx-lcdif
> >> > +  - items:
> >> > +- enum:
> >> > +  - fsl,imx6sl-lcdif
> >> > +  - fsl,imx6sll-lcdif
> >> > +  - fsl,imx6ul-lcdif
> >> > +  - fsl,imx7d-lcdif
> >> > +  - fsl,imx8mq-lcdif
> >> > +- const: fsl,imx6sx-lcdif
> >> >
> >> >reg:
> >> >  maxItems: 1

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] dt-bindings: mxsfb: Add compatible for i.MX8MM

2020-10-06 Thread Laurent Pinchart
Hi Marek,

On Wed, Oct 07, 2020 at 12:38:50AM +0200, Marek Vasut wrote:
> On 10/6/20 11:15 PM, Rob Herring wrote:
> > On Sun, 04 Oct 2020 00:48:01 +0200, Marek Vasut wrote:
> >> NXP's i.MX8MM has an LCDIF as well.
> >>
> >> Signed-off-by: Marek Vasut 
> >> Cc: Fabio Estevam 
> >> Cc: Guido Günther 
> >> Cc: Lucas Stach 
> >> Cc: NXP Linux Team 
> >> Cc: Rob Herring 
> >> Cc: Shawn Guo 
> >> ---
> >>  Documentation/devicetree/bindings/display/mxsfb.txt | 1 +
> >>  1 file changed, 1 insertion(+)
> >>
> > 
> > Acked-by: Rob Herring 
> > 
> > Though Laurent posted converting this to schema...
> 
> Do you want me to rebase this on top of it or the other way around ?

Would it be OK if I rebased this on top of the conversion, and included
it in the v2 of the mxsfb series ?

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2] ARM: dts: r8a7742-iwg21d-q7: Add LCD support

2020-09-27 Thread Laurent Pinchart
Hi Prabhakar,

On Sun, Sep 27, 2020 at 02:01:50PM +0100, Lad, Prabhakar wrote:
> On Mon, Aug 24, 2020 at 1:48 AM Laurent Pinchart wrote:
> > On Thu, Aug 13, 2020 at 03:00:41PM +0100, Lad Prabhakar wrote:
> > > The iwg21d comes with a 7" capacitive touch screen, therefore
> > > add support for it.
> > >
> > > Signed-off-by: Lad Prabhakar 
> > > Reviewed-by: Marian-Cristian Rotariu 
> > > 
> >
> > Everything seems to match the schematics :-)
> >
> > Reviewed-by: Laurent Pinchart 
> >
> > > ---
> > > v1->v2
> > > * This patch is part of series [1] (rest of the patches have be accepted
> > >   by Geert [2]).
> > > * Added regulator for lvds
> > > * Added reset pin for touchpanel
> > > * This patch is based on series [3]
> > >
> > > [1] https://patchwork.kernel.org/project/linux-renesas-soc/list/
> > > ?series=330277
> > > [2] https://git.kernel.org/pub/scm/linux/kernel/git/geert/
> > > renesas-devel.git/log/?h=renesas-arm-dt-for-v5.10
> > > [3] https://patchwork.kernel.org/project/linux-renesas-soc/list/
> > > ?series=330957
> > > ---
> > >  arch/arm/boot/dts/r8a7742-iwg21d-q7.dts | 99 +
> > >  1 file changed, 99 insertions(+)
>
> Would you be queueing this patch along with DRM driver patches for v5.10 ?

No, I expect Geert to do so, DT patches go through his tree. I handle
the drivers and DT bindings.

> > > diff --git a/arch/arm/boot/dts/r8a7742-iwg21d-q7.dts 
> > > b/arch/arm/boot/dts/r8a7742-iwg21d-q7.dts
> > > index b3461a61a4bf..9bf4fbd9c736 100644
> > > --- a/arch/arm/boot/dts/r8a7742-iwg21d-q7.dts
> > > +++ b/arch/arm/boot/dts/r8a7742-iwg21d-q7.dts
> > > @@ -30,6 +30,7 @@
> > >
> > >  /dts-v1/;
> > >  #include "r8a7742-iwg21m.dtsi"
> > > +#include 
> > >
> > >  / {
> > >   model = "iWave Systems RainboW-G21D-Qseven board based on RZ/G1H";
> > > @@ -52,6 +53,51 @@
> > >   clock-frequency = <2600>;
> > >   };
> > >
> > > + lcd_backlight: backlight {
> > > + compatible = "pwm-backlight";
> > > + pwms = < 2 500 0>;
> > > + brightness-levels = <0 4 8 16 32 64 128 255>;
> > > + pinctrl-0 = <_pins>;
> > > + pinctrl-names = "default";
> > > + default-brightness-level = <7>;
> > > + enable-gpios = < 11 GPIO_ACTIVE_HIGH>;
> > > + };
> > > +
> > > + lvds-receiver {
> > > + compatible = "ti,ds90cf384a", "lvds-decoder";
> > > + vcc-supply = <_3v3_tft1>;
> > > +
> > > + ports {
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > +
> > > + port@0 {
> > > + reg = <0>;
> > > + lvds_receiver_in: endpoint {
> > > + remote-endpoint = <_out>;
> > > + };
> > > + };
> > > + port@1 {
> > > + reg = <1>;
> > > + lvds_receiver_out: endpoint {
> > > + remote-endpoint = <_in>;
> > > + };
> > > + };
> > > + };
> > > + };
> > > +
> > > + panel {
> > > + compatible = "edt,etm0700g0dh6";
> > > + backlight = <_backlight>;
> > > + power-supply = <_3v3_tft1>;
> > > +
> > > + port {
> > > + panel_in: endpoint {
> > > + remote-endpoint = <_receiver_out>;
> > > + };
> > > + };
> > > + };
> > > +
> > >   reg_1p5v: 1p5v {
> > >   compatible = "regulator-fixed";
> > >   regulator-name = "1P5V";
> > > @@ -75,6 +121,17 @@
> > >   };
> > >   };
> > >
> > > + vcc_3v3_tft1: regulator-panel {
> > > + 

Re: [PATCH] drm: bridge: cdns-mhdp8546: fix compile warning

2020-09-25 Thread Laurent Pinchart
On Fri, Sep 25, 2020 at 03:05:52PM +0300, Tomi Valkeinen wrote:
> On 25/09/2020 15:00, Laurent Pinchart wrote:
> > On Fri, Sep 25, 2020 at 10:36:44AM +0300, Tomi Valkeinen wrote:
> >> On 24/09/2020 14:48, Laurent Pinchart wrote:
> >>> Hi Tomi,
> >>>
> >>> Thank you for the patch.
> >>>
> >>> On Wed, Sep 23, 2020 at 11:30:57AM +0300, Tomi Valkeinen wrote:
> >>>> On x64 we get:
> >>>>
> >>>> drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c:751:10: warning: 
> >>>> conversion from 'long unsigned int' to 'unsigned int' changes value from 
> >>>> '18446744073709551613' to '4294967293' [-Woverflow]
> >>>>
> >>>> The registers are 32 bit, so fix by casting to u32.
> >>>
> >>> I wonder if we need a BIT32 macro... This is a common issue, it would be
> >>> nice to handle it in the macros that define register fields.
> >>
> >> That's probably a good idea. I think
> >>
> >> #define BIT32(nr) (1u << (nr))
> >>
> >> should work correct on all archs. Although I'm not quite sure if nr should 
> >> be cast to u32, but in my
> >> tests a u64 nr doesn't cause type promotion to u64.
> > 
> > I don't think we need to support nr values larger than 2^32-1 ;-)
> 
> That's true, but we might have:
> 
> u64 nr = 1;
> BIT32(nr)
> 
> Afaics, we don't need to cast nr to u32, but maybe that's still the safe 
> thing to do.
> 
> >> Anyway, I'd like to merge this fix as it is to get rid of the warning for 
> >> the merge window.
> > 
> > Sounds good to me.
> 
> Was that a reviewed-by? =)

Acked-by: Laurent Pinchart 

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm: bridge: cdns-mhdp8546: fix compile warning

2020-09-25 Thread Laurent Pinchart
On Fri, Sep 25, 2020 at 10:36:44AM +0300, Tomi Valkeinen wrote:
> On 24/09/2020 14:48, Laurent Pinchart wrote:
> > Hi Tomi,
> > 
> > Thank you for the patch.
> > 
> > On Wed, Sep 23, 2020 at 11:30:57AM +0300, Tomi Valkeinen wrote:
> >> On x64 we get:
> >>
> >> drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c:751:10: warning: 
> >> conversion from 'long unsigned int' to 'unsigned int' changes value from 
> >> '18446744073709551613' to '4294967293' [-Woverflow]
> >>
> >> The registers are 32 bit, so fix by casting to u32.
> > 
> > I wonder if we need a BIT32 macro... This is a common issue, it would be
> > nice to handle it in the macros that define register fields.
> 
> That's probably a good idea. I think
> 
> #define BIT32(nr) (1u << (nr))
> 
> should work correct on all archs. Although I'm not quite sure if nr should be 
> cast to u32, but in my
> tests a u64 nr doesn't cause type promotion to u64.

I don't think we need to support nr values larger than 2^32-1 ;-)

> Anyway, I'd like to merge this fix as it is to get rid of the warning for the 
> merge window.

Sounds good to me.

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm: bridge: cdns-mhdp8546: fix compile warning

2020-09-24 Thread Laurent Pinchart
Hi Tomi,

Thank you for the patch.

On Wed, Sep 23, 2020 at 11:30:57AM +0300, Tomi Valkeinen wrote:
> On x64 we get:
> 
> drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c:751:10: warning: 
> conversion from 'long unsigned int' to 'unsigned int' changes value from 
> '18446744073709551613' to '4294967293' [-Woverflow]
> 
> The registers are 32 bit, so fix by casting to u32.

I wonder if we need a BIT32 macro... This is a common issue, it would be
nice to handle it in the macros that define register fields.

> Fixes: fb43aa0acdfd ("drm: bridge: Add support for Cadence MHDP8546 DPI/DP 
> bridge")
> Signed-off-by: Tomi Valkeinen 
> ---
>  drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c 
> b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> index 621ebdbff8a3..d0c65610ebb5 100644
> --- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> +++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> @@ -748,7 +748,7 @@ static int cdns_mhdp_fw_activate(const struct firmware 
> *fw,
>* bridge should already be detached.
>*/
>   if (mhdp->bridge_attached)
> - writel(~CDNS_APB_INT_MASK_SW_EVENT_INT,
> + writel(~(u32)CDNS_APB_INT_MASK_SW_EVENT_INT,
>  mhdp->regs + CDNS_APB_INT_MASK);
>  
>   spin_unlock(>start_lock);
> @@ -1689,7 +1689,7 @@ static int cdns_mhdp_attach(struct drm_bridge *bridge,
>  
>   /* Enable SW event interrupts */
>   if (hw_ready)
> - writel(~CDNS_APB_INT_MASK_SW_EVENT_INT,
> + writel(~(u32)CDNS_APB_INT_MASK_SW_EVENT_INT,
>  mhdp->regs + CDNS_APB_INT_MASK);
>  
>   return 0;
> @@ -2122,7 +2122,7 @@ static void cdns_mhdp_bridge_hpd_enable(struct 
> drm_bridge *bridge)
>  
>   /* Enable SW event interrupts */
>   if (mhdp->bridge_attached)
> - writel(~CDNS_APB_INT_MASK_SW_EVENT_INT,
> + writel(~(u32)CDNS_APB_INT_MASK_SW_EVENT_INT,
>  mhdp->regs + CDNS_APB_INT_MASK);
>  }
>  

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [GIT PULL FOR v5.10 - v3] R-Car display drivers miscellaneous changes

2020-09-22 Thread Laurent Pinchart
On Tue, Sep 22, 2020 at 02:15:26PM +0300, Laurent Pinchart wrote:
> Hi Dave and Daniel,
> 
> Still because the original pull request hasn't been pulled yet, here's
> an updated version that fixes one small issue. I had initially fixed it
> in a separate patch to be merged in the fixes branch for v5.10, but
> realized the offending commit wasn't in -next yet.
> 
> Is there still time to get this merged in v5.10 ? The originally pull
> request was sent two weeks ago and seems to have fallen through the
> cracks.
> 
> The following changes since commit 818280d5adf1d80e78f95821815148abe9407e14:
> 
>   Merge v5.9-rc5 into drm-next (2020-09-14 17:19:11 +0200)
> 
> are available in the Git repository at:
> 
>   git://linuxtv.org/pinchartl/media.git

Modelled after the "my dog ate my homework", something ate the tag name
:-) It should read du-next-20200922 (which corresponds to the commit ID
just below).

> for you to fetch changes up to 2a32dbdc2c7db5463483fa01fb220fd1b770c6bc:
> 
>   drm: rcar-du: Put reference to VSP device (2020-09-22 14:10:05 +0300)
> 
> 
> Biju Das (2):
>   dt-bindings: display: bridge: lvds-codec: Document power-supply property
>   drm/bridge: lvds-codec: Add support for regulator
> 
> Kuninori Morimoto (4):
>   dt-bindings: display: renesas: du: Document the r8a77961 bindings
>   dt-bindings: display: renesas: dw-hdmi: Tidyup example compatible
>   dt-bindings: display: renesas: dw-hdmi: Add R8A77961 support
>   drm: rcar-du: Add r8a77961 support
> 
> Lad Prabhakar (5):
>   dt-bindings: display: renesas,du: Document the r8a7742 bindings
>   drm: rcar-du: Add r8a7742 support
>   dt-bindings: display: renesas,lvds: Document r8a7742 bindings
>   drm: rcar-du: lvds: Add r8a7742 support
>   drm: rcar-du: Update description for DRM_RCAR_DW_HDMI Kconfig entry
> 
> Laurent Pinchart (3):
>   drm: rcar-du: Fix pitch handling for fully planar YUV formats
>   drm: rcar-du: Fix crash when enabling a non-visible plane
>   drm: rcar-du: Put reference to VSP device
> 
> Marian-Cristian Rotariu (5):
>   dt-bindings: display: renesas,du: Document r8a774e1 bindings
>   drm: rcar-du: Add support for R8A774E1 SoC
>   dt-bindings: display: renesas,lvds: Document r8a774e1 bindings
>   dt-bindings: display: renesas,dw-hdmi: Add r8a774e1 support
>   drm: rcar-du: lvds: Add support for R8A774E1 SoC
> 
> Qian Cai (1):
>   drm: rcar-du: Make DRM_RCAR_WRITEBACK depends on DRM_RCAR_DU
> 
>  .../bindings/display/bridge/lvds-codec.yaml|  3 ++
>  .../bindings/display/bridge/renesas,dw-hdmi.txt|  4 +-
>  .../bindings/display/bridge/renesas,lvds.yaml  |  2 +
>  .../devicetree/bindings/display/renesas,du.txt |  6 +++
>  drivers/gpu/drm/bridge/lvds-codec.c| 29 
>  drivers/gpu/drm/rcar-du/Kconfig|  5 +-
>  drivers/gpu/drm/rcar-du/rcar_du_drv.c  | 37 ++-
>  drivers/gpu/drm/rcar-du/rcar_du_kms.c  | 54 
> +-
>  drivers/gpu/drm/rcar-du/rcar_du_kms.h  |  1 +
>  drivers/gpu/drm/rcar-du/rcar_du_vsp.c  | 14 +-
>  drivers/gpu/drm/rcar-du/rcar_lvds.c|  2 +
>  11 files changed, 149 insertions(+), 8 deletions(-)

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[GIT PULL FOR v5.10 - v3] R-Car display drivers miscellaneous changes

2020-09-22 Thread Laurent Pinchart
Hi Dave and Daniel,

Still because the original pull request hasn't been pulled yet, here's
an updated version that fixes one small issue. I had initially fixed it
in a separate patch to be merged in the fixes branch for v5.10, but
realized the offending commit wasn't in -next yet.

Is there still time to get this merged in v5.10 ? The originally pull
request was sent two weeks ago and seems to have fallen through the
cracks.

The following changes since commit 818280d5adf1d80e78f95821815148abe9407e14:

  Merge v5.9-rc5 into drm-next (2020-09-14 17:19:11 +0200)

are available in the Git repository at:

  git://linuxtv.org/pinchartl/media.git

for you to fetch changes up to 2a32dbdc2c7db5463483fa01fb220fd1b770c6bc:

  drm: rcar-du: Put reference to VSP device (2020-09-22 14:10:05 +0300)


Biju Das (2):
  dt-bindings: display: bridge: lvds-codec: Document power-supply property
  drm/bridge: lvds-codec: Add support for regulator

Kuninori Morimoto (4):
  dt-bindings: display: renesas: du: Document the r8a77961 bindings
  dt-bindings: display: renesas: dw-hdmi: Tidyup example compatible
  dt-bindings: display: renesas: dw-hdmi: Add R8A77961 support
  drm: rcar-du: Add r8a77961 support

Lad Prabhakar (5):
  dt-bindings: display: renesas,du: Document the r8a7742 bindings
  drm: rcar-du: Add r8a7742 support
  dt-bindings: display: renesas,lvds: Document r8a7742 bindings
  drm: rcar-du: lvds: Add r8a7742 support
  drm: rcar-du: Update description for DRM_RCAR_DW_HDMI Kconfig entry

Laurent Pinchart (3):
  drm: rcar-du: Fix pitch handling for fully planar YUV formats
  drm: rcar-du: Fix crash when enabling a non-visible plane
  drm: rcar-du: Put reference to VSP device

Marian-Cristian Rotariu (5):
  dt-bindings: display: renesas,du: Document r8a774e1 bindings
  drm: rcar-du: Add support for R8A774E1 SoC
  dt-bindings: display: renesas,lvds: Document r8a774e1 bindings
  dt-bindings: display: renesas,dw-hdmi: Add r8a774e1 support
  drm: rcar-du: lvds: Add support for R8A774E1 SoC

Qian Cai (1):
  drm: rcar-du: Make DRM_RCAR_WRITEBACK depends on DRM_RCAR_DU

 .../bindings/display/bridge/lvds-codec.yaml|  3 ++
 .../bindings/display/bridge/renesas,dw-hdmi.txt|  4 +-
 .../bindings/display/bridge/renesas,lvds.yaml  |  2 +
 .../devicetree/bindings/display/renesas,du.txt |  6 +++
 drivers/gpu/drm/bridge/lvds-codec.c| 29 
 drivers/gpu/drm/rcar-du/Kconfig|  5 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.c  | 37 ++-
 drivers/gpu/drm/rcar-du/rcar_du_kms.c  | 54 +-
 drivers/gpu/drm/rcar-du/rcar_du_kms.h  |  1 +
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c  | 14 +-
 drivers/gpu/drm/rcar-du/rcar_lvds.c|  2 +
 11 files changed, 149 insertions(+), 8 deletions(-)

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v3] drm/bridge: lvds-codec: Add support for regulator

2020-09-22 Thread Laurent Pinchart
From: Biju Das 

Add the support for enabling optional regulator that may be used as VCC
source.

Signed-off-by: Biju Das 
Reviewed-by: Laurent Pinchart 
[Replaced 'error' variable with 'ret']
[Renamed regulator from 'vcc' to 'power']
Signed-off-by: Laurent Pinchart 
---
Changes since v2:

- Use the correct regulator name
---
 drivers/gpu/drm/bridge/lvds-codec.c | 29 +
 1 file changed, 29 insertions(+)

diff --git a/drivers/gpu/drm/bridge/lvds-codec.c 
b/drivers/gpu/drm/bridge/lvds-codec.c
index f19d9f7a5db2..f52ccffc1bd1 100644
--- a/drivers/gpu/drm/bridge/lvds-codec.c
+++ b/drivers/gpu/drm/bridge/lvds-codec.c
@@ -10,13 +10,16 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
 
 struct lvds_codec {
+   struct device *dev;
struct drm_bridge bridge;
struct drm_bridge *panel_bridge;
+   struct regulator *vcc;
struct gpio_desc *powerdown_gpio;
u32 connector_type;
 };
@@ -38,6 +41,14 @@ static int lvds_codec_attach(struct drm_bridge *bridge,
 static void lvds_codec_enable(struct drm_bridge *bridge)
 {
struct lvds_codec *lvds_codec = to_lvds_codec(bridge);
+   int ret;
+
+   ret = regulator_enable(lvds_codec->vcc);
+   if (ret) {
+   dev_err(lvds_codec->dev,
+   "Failed to enable regulator \"vcc\": %d\n", ret);
+   return;
+   }
 
if (lvds_codec->powerdown_gpio)
gpiod_set_value_cansleep(lvds_codec->powerdown_gpio, 0);
@@ -46,9 +57,15 @@ static void lvds_codec_enable(struct drm_bridge *bridge)
 static void lvds_codec_disable(struct drm_bridge *bridge)
 {
struct lvds_codec *lvds_codec = to_lvds_codec(bridge);
+   int ret;
 
if (lvds_codec->powerdown_gpio)
gpiod_set_value_cansleep(lvds_codec->powerdown_gpio, 1);
+
+   ret = regulator_disable(lvds_codec->vcc);
+   if (ret)
+   dev_err(lvds_codec->dev,
+   "Failed to disable regulator \"vcc\": %d\n", ret);
 }
 
 static const struct drm_bridge_funcs funcs = {
@@ -63,12 +80,24 @@ static int lvds_codec_probe(struct platform_device *pdev)
struct device_node *panel_node;
struct drm_panel *panel;
struct lvds_codec *lvds_codec;
+   int ret;
 
lvds_codec = devm_kzalloc(dev, sizeof(*lvds_codec), GFP_KERNEL);
if (!lvds_codec)
return -ENOMEM;
 
+   lvds_codec->dev = >dev;
lvds_codec->connector_type = (uintptr_t)of_device_get_match_data(dev);
+
+   lvds_codec->vcc = devm_regulator_get(lvds_codec->dev, "power");
+   if (IS_ERR(lvds_codec->vcc)) {
+   ret = PTR_ERR(lvds_codec->vcc);
+   if (ret != -EPROBE_DEFER)
+   dev_err(lvds_codec->dev,
+   "Unable to get \"vcc\" supply: %d\n", ret);
+   return ret;
+   }
+
lvds_codec->powerdown_gpio = devm_gpiod_get_optional(dev, "powerdown",
     GPIOD_OUT_HIGH);
if (IS_ERR(lvds_codec->powerdown_gpio))
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v3 1/2] dt-bindings: display: ti,am65x-dss: add missing properties to dt-schema

2020-09-17 Thread Laurent Pinchart
Hi Tomi,

Thank you for the patch.

On Wed, Sep 16, 2020 at 04:10:08PM +0300, Tomi Valkeinen wrote:
> Add assigned-clocks, assigned-clock-parents and dma-coherent optional
> properties.
> 
> Signed-off-by: Tomi Valkeinen 
> Reviewed-by: Rob Herring 
> ---
>  .../devicetree/bindings/display/ti/ti,am65x-dss.yaml  | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml 
> b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
> index 4f9185462ed3..4dc30738ee57 100644
> --- a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
> +++ b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
> @@ -55,6 +55,14 @@ properties:
>- const: vp1
>- const: vp2
>  
> +  assigned-clocks:
> +minItems: 1
> +maxItems: 3
> +
> +  assigned-clock-parents:
> +minItems: 1
> +maxItems: 3
> +

Those properties can occur in any node that has clocks. Do we need to
specify them explicitly in every schema ?

>interrupts:
>  maxItems: 1
>  
> @@ -62,6 +70,9 @@ properties:
>  maxItems: 1
>  description: phandle to the associated power domain
>  
> +  dma-coherent:
> +type: boolean
> +
>ports:
>  type: object
>  description:

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[GIT PULL FOR v5.10 - v2] R-Car display drivers miscellaneous changes

2020-09-16 Thread Laurent Pinchart
Hi Dave and Daniel,

As the original pull request hasn't been pulled yet, here's an updated
version that collects more acks and rb's, and includes an additional
patch.

The following changes since commit 818280d5adf1d80e78f95821815148abe9407e14:

  Merge v5.9-rc5 into drm-next (2020-09-14 17:19:11 +0200)

are available in the Git repository at:

  git://linuxtv.org/pinchartl/media.git tags/du-next-20200917

for you to fetch changes up to ab00111864ee2c9742f6627c5ca1019730c0eedd:

  drm: rcar-du: Put reference to VSP device (2020-09-17 03:42:17 +0300)


Miscellaneous R-Car display driver changes:

- R8A7742, R8A774E1 and R8A77961 support
- Fixes for pitch of YUV planar formats, non-visible plane handling and
  VSP device reference count
- Kconfig fix to avoid displaying disabled options in .config


Biju Das (2):
  dt-bindings: display: bridge: lvds-codec: Document power-supply property
  drm/bridge: lvds-codec: Add support for regulator

Kuninori Morimoto (4):
  dt-bindings: display: renesas: du: Document the r8a77961 bindings
  dt-bindings: display: renesas: dw-hdmi: Tidyup example compatible
  dt-bindings: display: renesas: dw-hdmi: Add R8A77961 support
  drm: rcar-du: Add r8a77961 support

Lad Prabhakar (5):
  dt-bindings: display: renesas,du: Document the r8a7742 bindings
  drm: rcar-du: Add r8a7742 support
  dt-bindings: display: renesas,lvds: Document r8a7742 bindings
  drm: rcar-du: lvds: Add r8a7742 support
  drm: rcar-du: Update description for DRM_RCAR_DW_HDMI Kconfig entry

Laurent Pinchart (3):
  drm: rcar-du: Fix pitch handling for fully planar YUV formats
  drm: rcar-du: Fix crash when enabling a non-visible plane
  drm: rcar-du: Put reference to VSP device

Marian-Cristian Rotariu (5):
  dt-bindings: display: renesas,du: Document r8a774e1 bindings
  drm: rcar-du: Add support for R8A774E1 SoC
  dt-bindings: display: renesas,lvds: Document r8a774e1 bindings
  dt-bindings: display: renesas,dw-hdmi: Add r8a774e1 support
  drm: rcar-du: lvds: Add support for R8A774E1 SoC

Qian Cai (1):
  drm: rcar-du: Make DRM_RCAR_WRITEBACK depends on DRM_RCAR_DU

 .../bindings/display/bridge/lvds-codec.yaml|  3 ++
 .../bindings/display/bridge/renesas,dw-hdmi.txt|  4 +-
 .../bindings/display/bridge/renesas,lvds.yaml  |  2 +
 .../devicetree/bindings/display/renesas,du.txt |  6 +++
 drivers/gpu/drm/bridge/lvds-codec.c| 29 
 drivers/gpu/drm/rcar-du/Kconfig|  5 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.c  | 37 ++-
 drivers/gpu/drm/rcar-du/rcar_du_kms.c  | 54 +-
 drivers/gpu/drm/rcar-du/rcar_du_kms.h  |  1 +
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c  | 14 +-
 drivers/gpu/drm/rcar-du/rcar_lvds.c|  2 +
 11 files changed, 149 insertions(+), 8 deletions(-)

-- 
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: Put reference to VSP device

2020-09-16 Thread Laurent Pinchart
Hi Kieran,

On Wed, Sep 16, 2020 at 11:26:36AM +0100, Kieran Bingham wrote:
> On 16/09/2020 00:38, Laurent Pinchart wrote:
> > The reference to the VSP device acquired with of_find_device_by_node()
> > in rcar_du_vsp_init() is never released. Fix it with a drmm action,
> > which gets run both in the probe error path and in the remove path.
> > 
> > Fixes: 6d62ef3ac30b ("drm: rcar-du: Expose the VSP1 compositor through KMS 
> > planes")
> > Reported-by: Yu Kuai 
> > Signed-off-by: Laurent Pinchart 
> 
> Looks nice and clean!
> 
> Reviewed-by: Kieran Bingham 
> 
> > ---
> >  drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 12 
> >  1 file changed, 12 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c 
> > b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> > index f1a81c9b184d..fa09b3ae8b9d 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> > @@ -13,6 +13,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  
> > @@ -341,6 +342,13 @@ static const struct drm_plane_funcs 
> > rcar_du_vsp_plane_funcs = {
> > .atomic_destroy_state = rcar_du_vsp_plane_atomic_destroy_state,
> >  };
> >  
> > +static void rcar_du_vsp_cleanup(struct drm_device *dev, void *res)
> > +{
> > +   struct rcar_du_vsp *vsp = res;
> > +
> > +   put_device(vsp->vsp);
> 
> Ugh the asymmetry of the put_device is a bit annoying, because it's not
> initially clear that the of_find_device_by_node() call 'gets' a reference.
> 
> (Or at least not until you find:
>   https://lore.kernel.org/patchwork/patch/731284/)
> 
> It is stated in the commit message though so that's fine, and although I
> thought perhaps a comment here might be useful to declare that it
> releases the reference taken by of_find_device_by_node(), I'm not sure
> it even adds that much value ... so either way.

I think that the fact that drmm_add_action() is called right after
of_find_device_by_node() makes this explicit enough.

> > +}
> > +
> >  int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct device_node *np,
> >  unsigned int crtcs)
> >  {
> > @@ -357,6 +365,10 @@ int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct 
> > device_node *np,
> >  
> > vsp->vsp = >dev;
> >  
> > +   ret = drmm_add_action(rcdu->ddev, rcar_du_vsp_cleanup, vsp);
> > +   if (ret < 0)
> > +   return ret;
> > +
> > ret = vsp1_du_init(vsp->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] dt-bindings: dp-connector: add binding for DisplayPort connector

2020-09-16 Thread Laurent Pinchart
Hi Tomi,

Thank you for the patch.

On Wed, Sep 16, 2020 at 05:44:40PM +0300, Tomi Valkeinen wrote:
> Add binding for DisplayPort connector. A few notes:
> 
> * Similar to hdmi-connector, it has hpd-gpios as an optional property,
>   as the HPD could also be handled by, e.g., the DP bridge.
> 
> * dp-pwr-supply, which provides 3.3V on DP_PWR pin, is optional, as it
>   is not strictly required: standard DP cables do not even have the pin
>   connected.
> 
> * No property for the connector type. Full size and mini connectors are
>   identical except for the connector size and form, so I believe there
>   is no need to include the type in the bindings.

It could be useful to present information about the connector to
userspace. For instance, a GUI could show a picture of the connector
that the user should plug a cable in. This can also be added later, but
I think it would be useful to have it from the start.

> * No eDP. There's really no "eDP connector", as it's always a custom
>   made connection between the DP and the DP panel. So possibly there is
>   no need for edp-connector binding, but even if there is, I don't want
>   to guess what it could look like, and could it be part of the
>   dp-connector binding.

Agreed.

> * No DP++. I'm not familiar with DP++, but I think it's all handled by
>   the DP bridge, and does not need any new properties to the dp-connector.

I'm not familiar with this either.

> Signed-off-by: Tomi Valkeinen 

Possibly with a type property added,

Reviewed-by: Laurent Pinchart 

> ---
>  .../display/connector/dp-connector.yaml   | 48 +++
>  1 file changed, 48 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/connector/dp-connector.yaml
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/connector/dp-connector.yaml 
> b/Documentation/devicetree/bindings/display/connector/dp-connector.yaml
> new file mode 100644
> index ..983be1fe43f0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/connector/dp-connector.yaml
> @@ -0,0 +1,48 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/connector/dp-connector.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: DisplayPort Connector
> +
> +maintainers:
> +  - Tomi Valkeinen 
> +
> +properties:
> +  compatible:
> +const: dp-connector
> +
> +  label: true
> +
> +  hpd-gpios:
> +description: A GPIO line connected to HPD
> +maxItems: 1
> +
> +  dp-pwr-supply:
> +description: Power supply for the DP_PWR pin
> +maxItems: 1
> +
> +  port:
> +description: Connection to controller providing DP signals
> +
> +required:
> +  - compatible
> +  - port
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +connector {
> +compatible = "dp-connector";
> +label = "dp0";
> +
> +port {
> +dp_connector_in: endpoint {
> +remote-endpoint = <_out>;
> +};
> +};
> +};
> +
> +...

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] drm: rcar-du: Put reference to VSP device

2020-09-15 Thread Laurent Pinchart
The reference to the VSP device acquired with of_find_device_by_node()
in rcar_du_vsp_init() is never released. Fix it with a drmm action,
which gets run both in the probe error path and in the remove path.

Fixes: 6d62ef3ac30b ("drm: rcar-du: Expose the VSP1 compositor through KMS 
planes")
Reported-by: Yu Kuai 
Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c 
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index f1a81c9b184d..fa09b3ae8b9d 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -341,6 +342,13 @@ static const struct drm_plane_funcs 
rcar_du_vsp_plane_funcs = {
.atomic_destroy_state = rcar_du_vsp_plane_atomic_destroy_state,
 };
 
+static void rcar_du_vsp_cleanup(struct drm_device *dev, void *res)
+{
+   struct rcar_du_vsp *vsp = res;
+
+   put_device(vsp->vsp);
+}
+
 int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct device_node *np,
 unsigned int crtcs)
 {
@@ -357,6 +365,10 @@ int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct 
device_node *np,
 
vsp->vsp = >dev;
 
+   ret = drmm_add_action(rcdu->ddev, rcar_du_vsp_cleanup, vsp);
+   if (ret < 0)
+   return ret;
+
ret = vsp1_du_init(vsp->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] drm: rcar-du: add missing put_device() call in rcar_du_vsp_init()

2020-09-15 Thread Laurent Pinchart
Hi Yu,

Thank you for the patch.

On Thu, Sep 10, 2020 at 09:23:54PM +0800, Yu Kuai wrote:
> if of_find_device_by_node() succeed, rcar_du_vsp_init() doesn't have
> a corresponding put_device(). Thus add a jump target to fix the exception
> handling for this function implementation.
> 
> Fixes: 6d62ef3ac30b ("drm: rcar-du: Expose the VSP1 compositor through KMS 
> planes")
> Signed-off-by: Yu Kuai 
> ---
>  drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 19 +--
>  1 file changed, 13 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c 
> b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> index f1a81c9b184d..172ee3f3b21c 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> @@ -352,14 +352,16 @@ int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct 
> device_node *np,
>  
>   /* Find the VSP device and initialize it. */
>   pdev = of_find_device_by_node(np);
> - if (!pdev)
> - return -ENXIO;
> + if (!pdev) {
> + ret = -ENXIO;
> + goto put_device;
> + }

This change isn't needed, and will actually cause a crash, as pdev is
NULL.

>  
>   vsp->vsp = >dev;
>  
>   ret = vsp1_du_init(vsp->vsp);
>   if (ret < 0)
> - return ret;
> + goto put_device;
>  
>/*
> * The VSP2D (Gen3) has 5 RPFs, but the VSP1D (Gen2) is limited to
> @@ -369,8 +371,10 @@ int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct 
> device_node *np,
>  
>   vsp->planes = devm_kcalloc(rcdu->dev, vsp->num_planes,
>  sizeof(*vsp->planes), GFP_KERNEL);
> - if (!vsp->planes)
> - return -ENOMEM;
> + if (!vsp->planes) {
> + ret = -ENOMEM;
> + goto put_device;
> + }
>  
>   for (i = 0; i < vsp->num_planes; ++i) {
>   enum drm_plane_type type = i < num_crtcs
> @@ -387,7 +391,7 @@ int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct 
> device_node *np,
>  ARRAY_SIZE(rcar_du_vsp_formats),
>  NULL, type, NULL);
>   if (ret < 0)
> - return ret;
> + goto put_device;
>  
>   drm_plane_helper_add(>plane,
>_du_vsp_plane_helper_funcs);
> @@ -403,4 +407,7 @@ int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct 
> device_node *np,
>   }
>  
>   return 0;

I would add a blank line here.

> +put_device:

And maybe name the label "error" ?

> + put_device(>dev);
> + return ret;
>  }

We need more than this, we also need to call put_device() when the
driver is unloaded. The way to handle cleanup in DRM is through
drmm_add_action() nowadays, and I think we could thus simply replace the
change above with a cleanup action that is run both in the error path
and at driver remove.

I'll post a proposal in a reply to this e-mail.

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [RFC PATCH 1/3] drm: use flags instead of boolean in plane check

2020-09-15 Thread Laurent Pinchart
amp; plane->type != DRM_PLANE_TYPE_CURSOR)
>   return -EINVAL;
>  
>   return 0;
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> index 312ed0881a99..d58088ab44a4 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> @@ -453,7 +453,7 @@ int vmw_du_primary_plane_atomic_check(struct drm_plane 
> *plane,
>   ret = drm_atomic_helper_check_plane_state(state, crtc_state,
> DRM_PLANE_HELPER_NO_SCALING,
> DRM_PLANE_HELPER_NO_SCALING,
> -   false, true);
> +   
> DRM_PLANE_CAN_UPDATE_DISABLED);
>  
>   if (!ret && new_fb) {
>   struct drm_crtc *crtc = state->crtc;
> @@ -494,7 +494,7 @@ int vmw_du_cursor_plane_atomic_check(struct drm_plane 
> *plane,
>   ret = drm_atomic_helper_check_plane_state(new_state, crtc_state,
> DRM_PLANE_HELPER_NO_SCALING,
> 

Re: [PATCH] drm: Kconfig: Update description for DRM_RCAR_DW_HDMI config

2020-09-15 Thread Laurent Pinchart
Hi Prabhakar,

Thank you for the patch.

On Fri, Sep 11, 2020 at 11:07:41AM +0100, Lad Prabhakar wrote:
> rcar_dw_hdmi driver is also used on Renesas RZ/G2 SoC's, update the
> same to reflect the description for DRM_RCAR_DW_HDMI config.

I'm not sure what you mean by "the same" here. I'd propose

The rcar_dw_hdmi driver is also used on Renesas RZ/G2 SoCs. Update the
Kconfig entry description to reflect this.

Reviewed-by: Laurent Pinchart 

If you're fine with that, there's no need to resubmit the patch.

> Signed-off-by: Lad Prabhakar 
> Reviewed-by: Chris Paterson 
> ---
>  drivers/gpu/drm/rcar-du/Kconfig | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
> index f65d1489dc50..bd8b43fb9753 100644
> --- a/drivers/gpu/drm/rcar-du/Kconfig
> +++ b/drivers/gpu/drm/rcar-du/Kconfig
> @@ -22,11 +22,11 @@ config DRM_RCAR_CMM
> Enable support for R-Car Color Management Module (CMM).
>  
>  config DRM_RCAR_DW_HDMI
> - tristate "R-Car DU Gen3 HDMI Encoder Support"
> + tristate "R-Car Gen3 and RZ/G2 DU HDMI Encoder Support"
>   depends on DRM && OF
>   select DRM_DW_HDMI
>   help
> -   Enable support for R-Car Gen3 internal HDMI encoder.
> +   Enable support for R-Car Gen3 or RZ/G2 internal HDMI encoder.
>  
>  config DRM_RCAR_LVDS
>   tristate "R-Car DU LVDS Encoder Support"

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [GIT PULL FOR v5.10] R-Car display drivers miscellaneous changes

2020-09-15 Thread Laurent Pinchart
Hello,

Is there anything blocking this ?

On Tue, Sep 08, 2020 at 07:03:36PM +0300, Laurent Pinchart wrote:
> Hi Dave and Daniel,
> 
> The following changes since commit ce5c207c6b8dd9cdeaeeb2345b8a69335c0d98bf:
> 
>   Merge tag 'v5.9-rc4' into drm-next (2020-09-08 14:41:40 +1000)
> 
> are available in the Git repository at:
> 
>   git://linuxtv.org/pinchartl/media.git tags/du-next-20200908
> 
> for you to fetch changes up to 2a7d2463be82554578185dbb61caa01aaf504156:
> 
>   drm: rcar-du: Fix crash when enabling a non-visible plane (2020-09-08 
> 18:55:04 +0300)
> 
> 
> Miscellaneous R-Car display driver changes:
> 
> - R8A7742, R8A774E1 and R8A77961 support
> - Fixes for pitch of YUV planar foamts and non-visible plane handling
> - Kconfig fix to avoid displaying disabled options in .config
> 
> 
> Biju Das (2):
>   dt-bindings: display: bridge: lvds-codec: Document power-supply property
>   drm/bridge: lvds-codec: Add support for regulator
> 
> Kuninori Morimoto (4):
>   dt-bindings: display: renesas: du: Document the r8a77961 bindings
>   dt-bindings: display: renesas: dw-hdmi: Tidyup example compatible
>   dt-bindings: display: renesas: dw-hdmi: Add R8A77961 support
>   drm: rcar-du: Add r8a77961 support
> 
> Lad Prabhakar (4):
>   dt-bindings: display: renesas,du: Document the r8a7742 bindings
>   drm: rcar-du: Add r8a7742 support
>   dt-bindings: display: renesas,lvds: Document r8a7742 bindings
>   drm: rcar-du: lvds: Add r8a7742 support
> 
> Laurent Pinchart (2):
>   drm: rcar-du: Fix pitch handling for fully planar YUV formats
>   drm: rcar-du: Fix crash when enabling a non-visible plane
> 
> Marian-Cristian Rotariu (5):
>   dt-bindings: display: renesas,du: Document r8a774e1 bindings
>   drm: rcar-du: Add support for R8A774E1 SoC
>   dt-bindings: display: renesas,lvds: Document r8a774e1 bindings
>   dt-bindings: display: renesas,dw-hdmi: Add r8a774e1 support
>   drm: rcar-du: lvds: Add support for R8A774E1 SoC
> 
> Qian Cai (1):
>   drm: rcar-du: Make DRM_RCAR_WRITEBACK depends on DRM_RCAR_DU
> 
>  .../bindings/display/bridge/lvds-codec.yaml |  3 ++
>  .../bindings/display/bridge/renesas,dw-hdmi.txt |  4 +-
>  .../bindings/display/bridge/renesas,lvds.yaml   |  2 +
>  .../devicetree/bindings/display/renesas,du.txt  |  6 +++
>  drivers/gpu/drm/bridge/lvds-codec.c | 29 ++
>  drivers/gpu/drm/rcar-du/Kconfig |  1 +
>  drivers/gpu/drm/rcar-du/rcar_du_drv.c   | 37 -
>  drivers/gpu/drm/rcar-du/rcar_du_kms.c   | 54 ++-
>  drivers/gpu/drm/rcar-du/rcar_du_kms.h   |  1 +
>  drivers/gpu/drm/rcar-du/rcar_du_vsp.c   |  2 +-
>  drivers/gpu/drm/rcar-du/rcar_lvds.c |  2 +
>  11 files changed, 135 insertions(+), 6 deletions(-)
> 

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 20/21] drm/xlnx: Initialize DRM driver instance with CMA helper macro

2020-09-15 Thread Laurent Pinchart
Hi Thomas,

Thank you for the patch.

On Tue, Sep 15, 2020 at 04:59:57PM +0200, Thomas Zimmermann wrote:
> The xlnx driver uses CMA helpers with default callback functions.
> Initialize the driver structure with the rsp CMA helper macro. The
> driver is being converted to use GEM object functions as part of
> this change.
> 
> Two callbacks, .dumb_destroy and .gem_prime_import, were initialized
> to their default implementations, so they are just kept empty now.
> 
> v2:
>   * initialize with DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE (Laurent)
> 
> Signed-off-by: Thomas Zimmermann 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 14 +-
>  1 file changed, 1 insertion(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_dpsub.c 
> b/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
> index 8e69303aad3f..f3ffc3703a0e 100644
> --- a/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
> +++ b/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
> @@ -80,19 +80,7 @@ static struct drm_driver zynqmp_dpsub_drm_driver = {
>   .driver_features= DRIVER_MODESET | DRIVER_GEM |
> DRIVER_ATOMIC,
>  
> - .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> - .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> - .gem_prime_export   = drm_gem_prime_export,
> - .gem_prime_import   = drm_gem_prime_import,
> - .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
> - .gem_prime_import_sg_table  = drm_gem_cma_prime_import_sg_table,
> - .gem_prime_vmap = drm_gem_cma_prime_vmap,
> - .gem_prime_vunmap   = drm_gem_cma_prime_vunmap,
> - .gem_prime_mmap = drm_gem_cma_prime_mmap,
> - .gem_free_object_unlocked   = drm_gem_cma_free_object,
> - .gem_vm_ops = _gem_cma_vm_ops,
> - .dumb_create= zynqmp_dpsub_dumb_create,
> - .dumb_destroy   = drm_gem_dumb_destroy,
> + DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE(zynqmp_dpsub_dumb_create),
>  
>   .fops   = _dpsub_drm_fops,
>  

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2] drm/panel: samsung: make vint_table static

2020-09-15 Thread Laurent Pinchart
Hi Jason,

Thank you for the patch.

On Tue, Sep 15, 2020 at 11:56:32AM +0800, Jason Yan wrote:
> This eliminates the following sparse warning:
> 
> drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c:217:15: warning: symbol
> 'vint_table' was not declared. Should it be static?

The commit message should mention that it also make the table const. I'd
write "drm/panel: samsung: Make vint_table static const" in the subject
line, and add here

"While at it, make the table const as it is never modified."

With those changes,

Reviewed-by: Laurent Pinchart 

> Reported-by: Hulk Robot 
> Signed-off-by: Jason Yan 
> ---
>  drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c 
> b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
> index 1d1c79a18613..0ab1b7ec84cd 100644
> --- a/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
> +++ b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
> @@ -214,7 +214,7 @@ static const u8 
> gamma_tbl[S6E3HA2_NUM_GAMMA_STEPS][S6E3HA2_GAMMA_CMD_CNT] = {
> 0x00, 0x00 }
>  };
>  
> -unsigned char vint_table[S6E3HA2_VINT_STATUS_MAX] = {
> +static const unsigned char vint_table[S6E3HA2_VINT_STATUS_MAX] = {
>   0x18, 0x19, 0x1a, 0x1b, 0x1c,
>   0x1d, 0x1e, 0x1f, 0x20, 0x21
>  };

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/panel: samsung: make vint_table static

2020-09-14 Thread Laurent Pinchart
Hi Jason,

Thank you for the patch.

On Sat, Sep 12, 2020 at 11:38:17AM +0800, Jason Yan wrote:
> This eliminates the following sparse warning:
> 
> drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c:217:15: warning: symbol
> 'vint_table' was not declared. Should it be static?
> 
> Reported-by: Hulk Robot 
> Signed-off-by: Jason Yan 
> ---
>  drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c 
> b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
> index 1d1c79a18613..b3f5797c23e0 100644
> --- a/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
> +++ b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
> @@ -214,7 +214,7 @@ static const u8 
> gamma_tbl[S6E3HA2_NUM_GAMMA_STEPS][S6E3HA2_GAMMA_CMD_CNT] = {
> 0x00, 0x00 }
>  };
>  
> -unsigned char vint_table[S6E3HA2_VINT_STATUS_MAX] = {
> +static unsigned char vint_table[S6E3HA2_VINT_STATUS_MAX] = {

Shouldn't it be const, while at it ?

>   0x18, 0x19, 0x1a, 0x1b, 0x1c,
>   0x1d, 0x1e, 0x1f, 0x20, 0x21
>  };

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 2/2] drm/tilcdc: Remove tilcdc_crtc_max_width(), use private data

2020-09-14 Thread Laurent Pinchart
; diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.h 
> b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
> index 18815e75ca4f..76adf87fec4e 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
> @@ -28,8 +28,10 @@ struct drm_plane;
>  
>  /* Defaulting to pixel clock defined on AM335x */
>  #define TILCDC_DEFAULT_MAX_PIXELCLOCK  126000
> -/* Defaulting to max width as defined on AM335x */
> -#define TILCDC_DEFAULT_MAX_WIDTH  2048
> +/* Maximum width as defined on AM335x */
> +#define TILCDC_DEFAULT_MAX_WIDTH_V2  2048
> +/* ... and for V1 LCDC: */
> +#define TILCDC_DEFAULT_MAX_WIDTH_V1  1024

Nitpicking, I'd define V1 before V2 :-)

Reviewed-by: Laurent Pinchart 

>  /*
>   * This may need some tweaking, but want to allow at least 1280x1024@60
>   * with optimized DDR & EMIF settings tweaked 1920x1080@24 appears to
> @@ -158,7 +160,6 @@ void tilcdc_crtc_set_panel_info(struct drm_crtc *crtc,
>   const struct tilcdc_panel_info *info);
>  void tilcdc_crtc_set_simulate_vesa_sync(struct drm_crtc *crtc,
>   bool simulate_vesa_sync);
> -int tilcdc_crtc_max_width(struct drm_crtc *crtc);
>  void tilcdc_crtc_shutdown(struct drm_crtc *crtc);
>  int tilcdc_crtc_update_fb(struct drm_crtc *crtc,
>   struct drm_framebuffer *fb,

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 1/2] drm/tilcdc: Do not keep vblank interrupts enabled all the time

2020-09-14 Thread Laurent Pinchart
Hi Jyri,

Thank you for the patch.

On Mon, Sep 14, 2020 at 11:34:49AM +0300, Jyri Sarha wrote:
> END_OF_FRAME interrupts have been enabled all the time since the
> beginning of this driver. It is about time to add this feature.
> 
> Signed-off-by: Jyri Sarha 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 36 +---
>  1 file changed, 33 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
> b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> index 1856962411c7..29f263e1975a 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> @@ -147,12 +147,9 @@ static void tilcdc_crtc_enable_irqs(struct drm_device 
> *dev)
>   tilcdc_set(dev, LCDC_RASTER_CTRL_REG,
>   LCDC_V1_SYNC_LOST_INT_ENA | LCDC_V1_FRAME_DONE_INT_ENA |
>   LCDC_V1_UNDERFLOW_INT_ENA);
> - tilcdc_set(dev, LCDC_DMA_CTRL_REG,
> - LCDC_V1_END_OF_FRAME_INT_ENA);
>   } else {
>   tilcdc_write(dev, LCDC_INT_ENABLE_SET_REG,
>   LCDC_V2_UNDERFLOW_INT_ENA |
> - LCDC_V2_END_OF_FRAME0_INT_ENA |
>   LCDC_FRAME_DONE | LCDC_SYNC_LOST);
>   }
>  }
> @@ -678,11 +675,44 @@ static int tilcdc_crtc_atomic_check(struct drm_crtc 
> *crtc,
>  
>  static int tilcdc_crtc_enable_vblank(struct drm_crtc *crtc)
>  {
> + struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
> + struct drm_device *dev = crtc->dev;
> + struct tilcdc_drm_private *priv = dev->dev_private;
> + unsigned long flags;
> +
> + spin_lock_irqsave(_crtc->irq_lock, flags);
> +
> + tilcdc_clear_irqstatus(dev, LCDC_END_OF_FRAME0);
> +
> + if (priv->rev == 1)
> + tilcdc_set(dev, LCDC_DMA_CTRL_REG,
> +LCDC_V1_END_OF_FRAME_INT_ENA);
> + else
> + tilcdc_set(dev, LCDC_INT_ENABLE_SET_REG,
> +LCDC_V2_END_OF_FRAME0_INT_ENA);
> +
> + spin_unlock_irqrestore(_crtc->irq_lock, flags);
> +
>   return 0;
>  }
>  
>  static void tilcdc_crtc_disable_vblank(struct drm_crtc *crtc)
>  {
> + struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
> + struct drm_device *dev = crtc->dev;
> + struct tilcdc_drm_private *priv = dev->dev_private;
> + unsigned long flags;
> +
> + spin_lock_irqsave(_crtc->irq_lock, flags);
> +
> + if (priv->rev == 1)
> + tilcdc_clear(dev, LCDC_DMA_CTRL_REG,
> +  LCDC_V1_END_OF_FRAME_INT_ENA);
> + else
> + tilcdc_clear(dev, LCDC_INT_ENABLE_SET_REG,
> +  LCDC_V2_END_OF_FRAME0_INT_ENA);
> +
> + spin_unlock_irqrestore(_crtc->irq_lock, flags);
>  }
>  
>  static void tilcdc_crtc_reset(struct drm_crtc *crtc)

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 07/10] arm64: dts: renesas: r8a77961: Add DU device nodes

2020-09-10 Thread Laurent Pinchart
Hi Morimoto-san,

On Fri, Sep 11, 2020 at 08:20:56AM +0900, Kuninori Morimoto wrote:
> > > From: Kuninori Morimoto 
> > >
> > > This patch adds DU device nodes for R-Car M3-W+ (r8a77961) SoC.
> > > This patch was tested on R-Car M3-W+ Salvator-XS board.
> > >
> > > Signed-off-by: Kuninori Morimoto 
> > > ---
>
> (snip)
>
> > > du: display@feb0 {
> > > +   compatible = "renesas,du-r8a77961";
> > > reg = <0 0xfeb0 0 0x7>;
> > > -   /* placeholder */
> > > +   interrupts = ,
> > > +,
> > > +;
> > > +   clocks = < CPG_MOD 724>, < CPG_MOD 723>,
> > > +< CPG_MOD 722>;
> > > +   clock-names = "du.0", "du.1", "du.2";
> > > +   resets = < 724>, < 722>;
> > > +   reset-names = "du.0", "du.2";
> > > +
> > > +   renesas,vsps = < 0>, < 0>, < 0>;
> > > +   status = "disabled";
> > 
> > Do you want support for CMMs?
> 
> I'm not sure how it works.
> Thus I dropped such features from initial support.
> 
> I hope Laurent or Kieran will support it
> when he received physical board.

I'll be happy to do so :-)

> Some comment for iommu.
> 
> Thank you for your help !!

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: per-plane LUTs and CSCs?

2020-09-10 Thread Laurent Pinchart
Hi Vitaly,

On Thu, Sep 10, 2020 at 01:09:03PM -0400, Vitaly Prosyak wrote:
> On 2020-09-10 6:56 a.m., Laurent Pinchart wrote:
> > On Thu, Sep 10, 2020 at 01:28:03PM +0300, Pekka Paalanen wrote:
> >> On Thu, 10 Sep 2020 12:30:09 +0300 Laurentiu Palcu wrote:
> >>> On Thu, Sep 10, 2020 at 11:50:26AM +0300, Pekka Paalanen wrote:
> >>>> On Thu, 10 Sep 2020 09:52:26 +0200 Daniel Vetter wrote:
> >>>>> On Thu, Sep 10, 2020 at 10:25:43AM +0300, Pekka Paalanen wrote:
> >>>>>> On Wed, 9 Sep 2020 13:57:28 +0300 Laurentiu Palcu wrote:
> >>>>>>  
> >>>>>>> Hi all,
> >>>>>>>
> >>>>>>> I was wondering whether you could give me an advise on how to proceed 
> >>>>>>> further
> >>>>>>> with the following issue as I'm preparing to upstream the next set of 
> >>>>>>> patches
> >>>>>>> for the iMX8MQ display controller(DCSS). The display controller has 3 
> >>>>>>> planes,
> >>>>>>> each with 2 CSCs and one degamma LUT. The CSCs are in front and after 
> >>>>>>> the LUT
> >>>>>>> respectively. Then the output from those 3 pipes is blended together 
> >>>>>>> and then
> >>>>>>> gamma correction is applied using a linear-to-nonlinear LUT and 
> >>>>>>> another CSC, if
> >>>>>>> needed.
> >>>>
> >>>> Hi,
> >>>>
> >>>> hmm, so FB -> CSC -> LUT -> CSC -> blending?
> >>>>
> >>>> Is it then
> >>>>  blending -> LUT -> CSC -> encoder
> >>>> or
> >>>>  blending -> CSC -> LUT -> encoder?
> >>>
> >>> The DCSS pipeline topology is this:
> >>>
> >>> FB1->CSC_A->LUT->CSC_B-\
> >>> FB2->CSC_A->LUT->CSC_B-|-blender->LUT->CSC_O->encoder
> >>> FB3->CSC_A->LUT->CSC_B-/
> >>>
> >>> Basically, CSC_A is used to convert to a common colorspace if needed
> >>> (YUV->RGB) as well as to perform pixel range conversions: limited->full.
> >>> CSC_B is for gamut conversions(like 709->2020). The CSC_O is used to
> >>> convert to the colorspace used by the output (like RGB->YUV).
> >>
> >> I didn't realize that it would be correct to do RGB-YUV conversion in
> >> non-linear space, but yeah, that's what most software do too I guess.
> >>
> >>>> Are all these LUTs per-channel 1D LUTs or something else?
> >>>
> >>> LUTs are 3D, per pixel component.
> >>
> >> Sorry, which one?
> >>
> >> An example of a 3D LUT is 32x32x32 entries with each entry being a
> >> triplet, while a 1D LUT could be 1024 entries with each entry being a
> >> scalar. 1D LUTs are used per-channel so you need three of them, 3D LUTs
> >> you need just one for the color value triplet mapping.
> >>
> >> A 3D LUT can express much more than a 4x4 CTM. A 1D LUT cannot do the
> >> channel mixing that a CTM can.
> >>
> >> So if you truly have 3D LUTs everywhere, I wonder why the CSC matrix
> >> blocks exist...
> >
> > Possibly because the 3D LUT uses interpolation (it's a 17x17x17 LUT in
> > R-Car), having a separate CSC can give more precision (as well as
> > allowing the two problems to be decoupled, at a relatively low hardware
> > cost).
> 
> If you put nonlinear signal to 3DLUT then your
> precision would be improved.
> How many bits each color value has in 3DLUT ?

The whole display pipeline uses 8 bits per component.

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: per-plane LUTs and CSCs?

2020-09-10 Thread Laurent Pinchart
Hi Pekka,

On Thu, Sep 10, 2020 at 01:28:03PM +0300, Pekka Paalanen wrote:
> On Thu, 10 Sep 2020 12:30:09 +0300 Laurentiu Palcu wrote:
> > On Thu, Sep 10, 2020 at 11:50:26AM +0300, Pekka Paalanen wrote:
> > > On Thu, 10 Sep 2020 09:52:26 +0200 Daniel Vetter wrote:
> > > > On Thu, Sep 10, 2020 at 10:25:43AM +0300, Pekka Paalanen wrote:  
> > > > > On Wed, 9 Sep 2020 13:57:28 +0300 Laurentiu Palcu wrote:
> > > > > 
> > > > > > Hi all,
> > > > > > 
> > > > > > I was wondering whether you could give me an advise on how to 
> > > > > > proceed further
> > > > > > with the following issue as I'm preparing to upstream the next set 
> > > > > > of patches
> > > > > > for the iMX8MQ display controller(DCSS). The display controller has 
> > > > > > 3 planes,
> > > > > > each with 2 CSCs and one degamma LUT. The CSCs are in front and 
> > > > > > after the LUT
> > > > > > respectively. Then the output from those 3 pipes is blended 
> > > > > > together and then
> > > > > > gamma correction is applied using a linear-to-nonlinear LUT and 
> > > > > > another CSC, if
> > > > > > needed.  
> > > 
> > > Hi,
> > > 
> > > hmm, so FB -> CSC -> LUT -> CSC -> blending?
> > > 
> > > Is it then
> > >   blending -> LUT -> CSC -> encoder
> > > or
> > >   blending -> CSC -> LUT -> encoder?  
> > 
> > The DCSS pipeline topology is this:
> > 
> > FB1->CSC_A->LUT->CSC_B-\
> > FB2->CSC_A->LUT->CSC_B-|-blender->LUT->CSC_O->encoder
> > FB3->CSC_A->LUT->CSC_B-/
> > 
> > Basically, CSC_A is used to convert to a common colorspace if needed
> > (YUV->RGB) as well as to perform pixel range conversions: limited->full.
> > CSC_B is for gamut conversions(like 709->2020). The CSC_O is used to
> > convert to the colorspace used by the output (like RGB->YUV).
> 
> I didn't realize that it would be correct to do RGB-YUV conversion in
> non-linear space, but yeah, that's what most software do too I guess.
> 
> > > 
> > > Are all these LUTs per-channel 1D LUTs or something else?  
> > 
> > LUTs are 3D, per pixel component.
> 
> Sorry, which one?
> 
> An example of a 3D LUT is 32x32x32 entries with each entry being a
> triplet, while a 1D LUT could be 1024 entries with each entry being a
> scalar. 1D LUTs are used per-channel so you need three of them, 3D LUTs
> you need just one for the color value triplet mapping.
> 
> A 3D LUT can express much more than a 4x4 CTM. A 1D LUT cannot do the
> channel mixing that a CTM can.
> 
> So if you truly have 3D LUTs everywhere, I wonder why the CSC matrix
> blocks exist...

Possibly because the 3D LUT uses interpolation (it's a 17x17x17 LUT in
R-Car), having a separate CSC can give more precision (as well as
allowing the two problems to be decoupled, at a relatively low hardware
cost).

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: per-plane LUTs and CSCs?

2020-09-10 Thread Laurent Pinchart
Hi Pekka,

On Thu, Sep 10, 2020 at 11:50:26AM +0300, Pekka Paalanen wrote:
> On Thu, 10 Sep 2020 09:52:26 +0200 Daniel Vetter wrote:
> 
> > On Thu, Sep 10, 2020 at 10:25:43AM +0300, Pekka Paalanen wrote:
> > > On Wed, 9 Sep 2020 13:57:28 +0300 Laurentiu Palcu wrote:
> > >   
> > > > Hi all,
> > > > 
> > > > I was wondering whether you could give me an advise on how to proceed 
> > > > further
> > > > with the following issue as I'm preparing to upstream the next set of 
> > > > patches
> > > > for the iMX8MQ display controller(DCSS). The display controller has 3 
> > > > planes,
> > > > each with 2 CSCs and one degamma LUT. The CSCs are in front and after 
> > > > the LUT
> > > > respectively. Then the output from those 3 pipes is blended together 
> > > > and then
> > > > gamma correction is applied using a linear-to-nonlinear LUT and another 
> > > > CSC, if
> > > > needed.
> 
> Hi,
> 
> hmm, so FB -> CSC -> LUT -> CSC -> blending?
> 
> Is it then
>   blending -> LUT -> CSC -> encoder
> or
>   blending -> CSC -> LUT -> encoder?
> 
> Are all these LUTs per-channel 1D LUTs or something else?

If we want to define the color pipeline, we need to also take into
account 3D LUTs that use the full R,G,B value as an index in a 3D table.
In practice the table is decimated of course, otherwise it would take
too much space. The R-Car DU supports this feature in the output path:

blending -> CSC -> 3D-LUT -> LUT -> encoder

> What ever the KMS UAPI for these is going to be looking like, it
> obviously needs to define all this. So I'm guessing we need to define
> the abstract color pipeline of KMS in general that includes everything
> any driver might want to expose. Then each driver picks the blocks in
> the pipeline it wants to expose and the other blocks are assumed to be
> "identity transform".
> 
> Without such general abstract color pipeline defined and documented it
> is very unlikely IMO for generic userspace to make use of the driver
> features.
> 
> All blocks must also default to identity transform. A block
> unimplemented by a driver is the same as a block not used or understood
> by a KMS client.
> 
> Userspace that does not understand all the blocks will need to use the
> "harmless default values". This then ties in with what I've discussed
> with danvet before: when you are VT-switching from one KMS client to
> another, how do you reset the full KMS state (including blocks you
> don't understand) to the same state you had before. The other KMS
> client may have messed them up while you were gone.
> 
> All this default value talk is to ensure that the abstract KMS color
> pipeline can be extended without breaking existing userspace.
> 
> ...
> 
> > > > So, how should I continue with this one? Any pointers?  
> > > 
> > > Hi,
> > > 
> > > I can't help you, but I can say that we are currently in the process of
> > > designing a color management and HDR extension for Wayland, and I'm
> > > sure in the long term I would like to use per-plane color space
> > > transformation features of KMS in Weston eventually.
> > > 
> > > IOW, one more userspace that is going to be taking advantage of such
> > > features as long as they are not too driver-specific.  
> > 
> > Personally I think best to wait for userspace to come up with color
> > manager protocols, that should give us a much clearer idea of what the
> > kernel interface should look like. Since hw is pretty special in this
> > area, I expect we'll have to do a bunch of impendendance mismatching in
> > the kernel anyway.
> 
> Speaking of that, where should we scream if we feel like we are missing
> KMS properties to get the best out of color management and HDR in
> Weston, assuming we're not kernel devs?
> 
> Who to Cc?

You can CC me for Renesas. I'm not necessarily the most knowledgeable
person on this topic, but I can at least dispatch to developers who
could help.

> We currently have intel and AMD hardware at hand if that makes any
> difference.

-- 
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 pitch handling for fully planar YUV formats

2020-09-09 Thread Laurent Pinchart
Hi Kieran,

On Wed, Sep 09, 2020 at 05:06:01PM +0100, Kieran Bingham wrote:
> On 09/09/2020 13:08, Ville Syrjälä wrote:
> > On Tue, Sep 08, 2020 at 05:05:48PM +0100, Kieran Bingham wrote:
> >> On 08/09/2020 16:52, Laurent Pinchart wrote:
> >>> On Tue, Sep 08, 2020 at 04:42:58PM +0100, Kieran Bingham wrote:
> >>>> On 06/08/2020 03:26, Laurent Pinchart wrote:
> >>>>> When creating a frame buffer, the driver verifies that the pitches for
> >>>>> the chroma planes match the luma plane. This is done incorrectly for
> >>>>> fully planar YUV formats, without taking horizontal subsampling into
> >>>>> account. Fix it.
> >>>>>
> >>>>> Signed-off-by: Laurent Pinchart 
> >>>>> 
> >>>>> ---
> > 
> >>>>> }, {
> >>>>> .fourcc = DRM_FORMAT_YVU444,
> >>>>> .v4l2 = V4L2_PIX_FMT_YVU444M,
> >>>>> .bpp = 24,
> >>>>> .planes = 3,
> >>>>> +   .hsub = 1,
> >>>>> },
> >>>>>  };
> >>>>>  
> >>>>
> >>>> I wonder when we can have a global/generic set of format tables so that
> >>>> all of this isn't duplicated on a per-driver basis.
> >>>
> >>> Note that this table also contains register values, so at least that
> >>> part will need to be kept. For the rest, do you mean a 4CC library that
> >>
> >> Yes, the driver specific mappings of course need to be driver specific.
> >>
> >>> would be shared between DRM/KMS and V4L2 ? That's a great idea. Too bad
> >>> it has been shot down when patches were submitted :-S
> >>
> >>  /o\ ... It just seems like so much data replication that must be used
> >> by many drivers.
> >>
> >> Even without mapping the DRM/V4L2 fourccs - even a common table in each
> >> subsystem would be beneficial wouldn't it?
> >>
> >> I mean - RCar-DU isn't the only device that needs to know how many
> >> planes DRM_FORMAT_YUV422 has, or what horizontal subsampling it uses?
> >>
> >> Anyway, that's not an issue with this patch, it just seems glaring to me
> >> that these entries are common across all hardware that use them ...
> >>
> >> (the bpp/planes/subsampling of course, not the hardware specific 
> >> registers).
> > 
> > See drm_format_info() & co.
> 
> Aha perfect, That's what I was looking for.
> I'm glad to see that's common (at least for the DRM parts).
> 
> The question is - why aren't we using it in RCar-DU.
> 
> Laurent, would you see any issue in obtaining the struct drm_format_info
> rather than re-encoding all the data in these tables?
> 
> And if not - would you prefer to convert on top of this patch, or
> preceding this patch?
> 
> Or simply prefer to keep the existing tables ?
> 
> Given that this fixes a bug - I'd say getting this patch in now is
> probably best.

I'd apply refactoring on top, if desired. You would have to keep the
existing table for the mapping to V4L2 (although this could be moved to
drm_format_info if desired), as well as for the register value. And that
would then lead to a double lookup operation. That's the part that
bothers me the most.

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/bridge/tc358775: Fixes bus formats read

2020-09-08 Thread Laurent Pinchart
Hi Vinay,

On Tue, Sep 08, 2020 at 11:22:48PM +0530, Vinay Simha B N wrote:
> laurent,
> 
> Please review or give some feedback.

I'm sorry, I have very little time these days :-( Maybe Neil can provide
feedback ?

> On Tue, Aug 25, 2020 at 7:57 PM Vinay Simha B N  wrote:
> 
> > laurent,
> >
> > Please review or give some feedback.
> >
> > On Thu, Aug 13, 2020 at 9:09 PM Vinay Simha B N 
> > wrote:
> > >
> > > laurent,
> > >
> > > The code sequence was a problem. *num_inputs_fmts =
> > > ARRAY_SIZE(tc_lvds_in_bus_fmts); should come first and then allocate
> > > the kcalloc.
> > >
> > > input_fmts = kcalloc(*num_input_fmts, ARRAY_SIZE(tc_lvds_in_bus_fmts),
> > >  GFP_KERNEL);
> > > ..
> > > for (i = 0; i < ARRAY_SIZE(tc_lvds_in_bus_fmts); ++i)
> > > input_fmts[i] = tc_lvds_in_bus_fmts[i];
> > >
> > > *num_inputs_fmts = ARRAY_SIZE(tc_lvds_in_bus_fmts);
> > >
> > > So, internally in the drm pipeline get set the input format based on
> > > the output formats?
> > >
> > > On Wed, Aug 12, 2020 at 10:45 PM Vinay Simha B N 
> > wrote:
> > > >
> > > > laurent,
> > > >
> > > > if i add the .atomic_get_input_bus_fmts =
> > > > tc_bridge_get_input_bus_fmts, with the implementation suggested,
> > > > system does not boot fully, the reason is, we capture all the
> > > > supported input formats, but not sure where to set the final input
> > > > format. Please suggest.
> > > >
> > > > for (i = 0; i < ARRAY_SIZE(tc_lvds_in_bus_fmts); ++i)
> > > > input_fmts[i] = tc_lvds_in_bus_fmts[i];
> > > >
> > > > *num_input_fmts = ARRAY_SIZE(tc_lvds_in_bus_fmts);
> > > >
> > > > On Wed, Aug 12, 2020 at 8:25 PM Vinay Simha B N 
> > wrote:
> > > > >
> > > > > laurent,
> > > > >
> > > > > Video data input format :  RGB666 loosely packed 24 bits per pixel
> > > > > Can we use MEDIA_BUS_FMT_RGB666_1X24_CPADHI? There was no information
> > > > > wrt CPADHI or for loosely packed
> > > > >
> > > > > static const u32 tc_lvds_in_bus_fmts[] = {
> > > > > MEDIA_BUS_FMT_RGB565_1X16,
> > > > > MEDIA_BUS_FMT_RGB666_1X18,
> > > > > MEDIA_BUS_FMT_RGB666_1X24_CPADHI,
> > > > > MEDIA_BUS_FMT_RBG888_1X24,
> > > > > };
> > > > >
> > > > > for (i = 0; i < ARRAY_SIZE(tc_lvds_in_bus_fmts); ++i)
> > > > > input_fmts[i] = tc_lvds_in_bus_fmts[i];
> > > > > >> This will have all the available input formats, but finally which
> > video data input format chosen?
> > > > > Since dsi->format = MIPI_DSI_FMT_RGB888 is used does it chooses
> > > > > MEDIA_BUS_FMT_RBG888_1X24 by the drm pipeline
> > > > >
> > > > > On Wed, Aug 12, 2020 at 6:48 PM Laurent Pinchart
> > > > >  wrote:
> > > > > >
> > > > > > Hi Vinay,
> > > > > >
> > > > > > On Wed, Aug 12, 2020 at 06:07:52PM +0530, Vinay Simha B N wrote:
> > > > > > > On Wed, Aug 12, 2020 at 3:24 PM Laurent Pinchart wrote:
> > > > > > > > On Wed, Aug 12, 2020 at 12:55:50PM +0530, Vinay Simha BN wrote:
> > > > > > > > > - bus formats read from
> > drm_bridge_state.output_bus_cfg.format
> > > > > > > > >   and .atomic_get_input_bus_fmts() instead of connector
> > > > > > > > >
> > > > > > > > > Signed-off-by: Vinay Simha BN 
> > > > > > > > >
> > > > > > > > > ---
> > > > > > > > >  v1:
> > > > > > > > >  * Laurent Pinchart review comments incorporated
> > > > > > > > >drm_bridge_state.output_bus_cfg.format
> > > > > > > > >instead of connector
> > > > > > > > > ---
> > > > > > > > >  drivers/gpu/drm/bridge/tc358775.c | 76
> > ++-
> > > > > > > > >  1 file changed, 59 insertions(+), 17 deletions(-)
> > > > > > > > >
> > > > > > > > > diff --git a/drivers/gpu/drm/bridge/

[GIT PULL FOR v5.10] R-Car display drivers miscellaneous changes

2020-09-08 Thread Laurent Pinchart
Hi Dave and Daniel,

The following changes since commit ce5c207c6b8dd9cdeaeeb2345b8a69335c0d98bf:

  Merge tag 'v5.9-rc4' into drm-next (2020-09-08 14:41:40 +1000)

are available in the Git repository at:

  git://linuxtv.org/pinchartl/media.git tags/du-next-20200908

for you to fetch changes up to 2a7d2463be82554578185dbb61caa01aaf504156:

  drm: rcar-du: Fix crash when enabling a non-visible plane (2020-09-08 
18:55:04 +0300)


Miscellaneous R-Car display driver changes:

- R8A7742, R8A774E1 and R8A77961 support
- Fixes for pitch of YUV planar foamts and non-visible plane handling
- Kconfig fix to avoid displaying disabled options in .config


Biju Das (2):
  dt-bindings: display: bridge: lvds-codec: Document power-supply property
  drm/bridge: lvds-codec: Add support for regulator

Kuninori Morimoto (4):
  dt-bindings: display: renesas: du: Document the r8a77961 bindings
  dt-bindings: display: renesas: dw-hdmi: Tidyup example compatible
  dt-bindings: display: renesas: dw-hdmi: Add R8A77961 support
  drm: rcar-du: Add r8a77961 support

Lad Prabhakar (4):
  dt-bindings: display: renesas,du: Document the r8a7742 bindings
  drm: rcar-du: Add r8a7742 support
  dt-bindings: display: renesas,lvds: Document r8a7742 bindings
  drm: rcar-du: lvds: Add r8a7742 support

Laurent Pinchart (2):
  drm: rcar-du: Fix pitch handling for fully planar YUV formats
  drm: rcar-du: Fix crash when enabling a non-visible plane

Marian-Cristian Rotariu (5):
  dt-bindings: display: renesas,du: Document r8a774e1 bindings
  drm: rcar-du: Add support for R8A774E1 SoC
  dt-bindings: display: renesas,lvds: Document r8a774e1 bindings
  dt-bindings: display: renesas,dw-hdmi: Add r8a774e1 support
  drm: rcar-du: lvds: Add support for R8A774E1 SoC

Qian Cai (1):
  drm: rcar-du: Make DRM_RCAR_WRITEBACK depends on DRM_RCAR_DU

 .../bindings/display/bridge/lvds-codec.yaml |  3 ++
 .../bindings/display/bridge/renesas,dw-hdmi.txt |  4 +-
 .../bindings/display/bridge/renesas,lvds.yaml   |  2 +
 .../devicetree/bindings/display/renesas,du.txt  |  6 +++
 drivers/gpu/drm/bridge/lvds-codec.c | 29 ++
 drivers/gpu/drm/rcar-du/Kconfig |  1 +
 drivers/gpu/drm/rcar-du/rcar_du_drv.c   | 37 -
 drivers/gpu/drm/rcar-du/rcar_du_kms.c   | 54 ++-
 drivers/gpu/drm/rcar-du/rcar_du_kms.h   |  1 +
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c   |  2 +-
 drivers/gpu/drm/rcar-du/rcar_lvds.c |  2 +
 11 files changed, 135 insertions(+), 6 deletions(-)

-- 
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 pitch handling for fully planar YUV formats

2020-09-08 Thread Laurent Pinchart
Hi Kieran,

On Tue, Sep 08, 2020 at 04:42:58PM +0100, Kieran Bingham wrote:
> On 06/08/2020 03:26, Laurent Pinchart wrote:
> > When creating a frame buffer, the driver verifies that the pitches for
> > the chroma planes match the luma plane. This is done incorrectly for
> > fully planar YUV formats, without taking horizontal subsampling into
> > account. Fix it.
> > 
> > Signed-off-by: Laurent Pinchart 
> > ---
> >  drivers/gpu/drm/rcar-du/rcar_du_kms.c | 52 ++-
> >  drivers/gpu/drm/rcar-du/rcar_du_kms.h |  1 +
> >  2 files changed, 52 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 482329102f19..2fda3734a57e 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > @@ -40,6 +40,7 @@ static const struct rcar_du_format_info 
> > rcar_du_format_infos[] = {
> > .v4l2 = V4L2_PIX_FMT_RGB565,
> > .bpp = 16,
> > .planes = 1,
> > +   .hsub = 1,
> > .pnmr = PnMR_SPIM_TP | PnMR_DDDF_16BPP,
> > .edf = PnDDCR4_EDF_NONE,
> > }, {
> > @@ -47,6 +48,7 @@ static const struct rcar_du_format_info 
> > rcar_du_format_infos[] = {
> > .v4l2 = V4L2_PIX_FMT_ARGB555,
> > .bpp = 16,
> > .planes = 1,
> > +   .hsub = 1,
> > .pnmr = PnMR_SPIM_ALP | PnMR_DDDF_ARGB,
> > .edf = PnDDCR4_EDF_NONE,
> > }, {
> > @@ -61,6 +63,7 @@ static const struct rcar_du_format_info 
> > rcar_du_format_infos[] = {
> > .v4l2 = V4L2_PIX_FMT_XBGR32,
> > .bpp = 32,
> > .planes = 1,
> > +   .hsub = 1,
> > .pnmr = PnMR_SPIM_TP | PnMR_DDDF_16BPP,
> > .edf = PnDDCR4_EDF_RGB888,
> > }, {
> > @@ -68,6 +71,7 @@ static const struct rcar_du_format_info 
> > rcar_du_format_infos[] = {
> > .v4l2 = V4L2_PIX_FMT_ABGR32,
> > .bpp = 32,
> > .planes = 1,
> > +   .hsub = 1,
> > .pnmr = PnMR_SPIM_ALP | PnMR_DDDF_16BPP,
> > .edf = PnDDCR4_EDF_ARGB,
> > }, {
> > @@ -75,6 +79,7 @@ static const struct rcar_du_format_info 
> > rcar_du_format_infos[] = {
> > .v4l2 = V4L2_PIX_FMT_UYVY,
> > .bpp = 16,
> > .planes = 1,
> > +   .hsub = 2,
> > .pnmr = PnMR_SPIM_TP_OFF | PnMR_DDDF_YC,
> > .edf = PnDDCR4_EDF_NONE,
> > }, {
> > @@ -82,6 +87,7 @@ static const struct rcar_du_format_info 
> > rcar_du_format_infos[] = {
> > .v4l2 = V4L2_PIX_FMT_YUYV,
> > .bpp = 16,
> > .planes = 1,
> > +   .hsub = 2,
> > .pnmr = PnMR_SPIM_TP_OFF | PnMR_DDDF_YC,
> > .edf = PnDDCR4_EDF_NONE,
> > }, {
> > @@ -89,6 +95,7 @@ static const struct rcar_du_format_info 
> > rcar_du_format_infos[] = {
> > .v4l2 = V4L2_PIX_FMT_NV12M,
> > .bpp = 12,
> > .planes = 2,
> > +   .hsub = 2,
> > .pnmr = PnMR_SPIM_TP_OFF | PnMR_DDDF_YC,
> > .edf = PnDDCR4_EDF_NONE,
> > }, {
> > @@ -96,6 +103,7 @@ static const struct rcar_du_format_info 
> > rcar_du_format_infos[] = {
> > .v4l2 = V4L2_PIX_FMT_NV21M,
> > .bpp = 12,
> > .planes = 2,
> > +   .hsub = 2,
> > .pnmr = PnMR_SPIM_TP_OFF | PnMR_DDDF_YC,
> > .edf = PnDDCR4_EDF_NONE,
> > }, {
> > @@ -103,6 +111,7 @@ static const struct rcar_du_format_info 
> > rcar_du_format_infos[] = {
> > .v4l2 = V4L2_PIX_FMT_NV16M,
> > .bpp = 16,
> > .planes = 2,
> > +   .hsub = 2,
> > .pnmr = PnMR_SPIM_TP_OFF | PnMR_DDDF_YC,
> > .edf = PnDDCR4_EDF_NONE,
> > },
> > @@ -115,156 +124,187 @@ static const struct rcar_du_format_info 
> > rcar_du_format_infos[] = {
> > .v4l2 = V4L2_PIX_FMT_RGB332,
> > .bpp = 8,
> > .planes = 1,
> > +   .hsub = 1,
> > }, {
> > .fourcc = DRM_FORMAT_ARGB,
> > .v4l2 = V4L2_PIX_FMT_ARGB444,
> > .bpp = 16,
> > .planes = 1,
> > +   .hsub = 1,
> > }, {
> > .fourcc = DRM_FORMAT_XRGB

Re: [PATCH v2 02/10] dt-bindings: display: renesas: dw-hdmi: tidyup example compatible.

2020-09-08 Thread Laurent Pinchart
On Tue, Sep 08, 2020 at 05:43:25PM +0300, Laurent Pinchart wrote:
> Hi Kieran,
> 
> On Tue, Sep 08, 2020 at 03:18:20PM +0100, Kieran Bingham wrote:
> > On 08/09/2020 01:34, Kuninori Morimoto wrote:
> > > From: Kuninori Morimoto 
> > > 
> > > required is "renesas,r8a7795-hdmi", instead of "renesas,r8a7795-dw-hdmi"
> > 
> > Hrm, technically the driver will currently only match on :
> >   "renesas,rcar-gen3-hdmi"
> > 
> > But I see how the '-dw-' has probably snuck in from other devices, and
> > is inappropriate.
> > 
> > Perhaps this should be more clear that it matches on the generic compatible:
> > renesas,rcar-gen3-hdmi
> > 
> > (or a combination of both?)
> >
> > > Signed-off-by: Kuninori Morimoto 
> > 
> > But if the generic isn't required, then this patch alone does fix what I
> > would call an error, so ...
> 
> You're right, the generic compatible string should be required. I'll
> update this patch accordingly, and will address the bindings as part of
> the conversion to YAML.

Proposed new commit:

commit cc487cbb06d841ca76efade63201a41bd04f6015
Author: Kuninori Morimoto 
Date:   Tue Sep 8 09:34:11 2020 +0900

dt-bindings: display: renesas: dw-hdmi: Tidyup example compatible

The DT example erronously uses the "renesas,r8a7795-dw-hdmi", when the
    correct value is "renesas,r8a7795-hdmi". It is furthermore missing the
generic "renesas,rcar-gen3-hdmi" compatible string. Fix it.

Signed-off-by: Kuninori Morimoto 
Reviewed-by: Laurent Pinchart 
Reviewed-by: Kieran Bingham 
[Add "renesas,rcar-gen3-hdmi" and rework commit message]
Signed-off-by: Laurent Pinchart 

diff --git 
a/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt 
b/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
index f275997ab947..9c56c5169a88 100644
--- a/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
+++ b/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
@@ -43,7 +43,7 @@ Optional properties:
 Example:

hdmi0: hdmi@fead {
-   compatible = "renesas,r8a7795-dw-hdmi";
+   compatible = "renesas,r8a7795-hdmi", "renesas,rcar-gen3-hdmi";
reg = <0 0xfead 0 0x1>;
interrupts = <0 389 IRQ_TYPE_LEVEL_HIGH>;
clocks = < CPG_CORE R8A7795_CLK_S0D4>, < CPG_MOD 729>;

> > Reviewed-by: Kieran Bingham 
> > 
> > We could always make this more clear when converting to YAML.
> >
> > > ---
> > >  .../devicetree/bindings/display/bridge/renesas,dw-hdmi.txt  | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git 
> > > a/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt 
> > > b/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
> > > index 819f3e31013c..e6526ab485d0 100644
> > > --- a/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
> > > +++ b/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
> > > @@ -42,7 +42,7 @@ Optional properties:
> > >  Example:
> > >  
> > >   hdmi0: hdmi@fead {
> > > - compatible = "renesas,r8a7795-dw-hdmi";
> > > + compatible = "renesas,r8a7795-hdmi";
> > >   reg = <0 0xfead 0 0x1>;
> > >   interrupts = <0 389 IRQ_TYPE_LEVEL_HIGH>;
> > >   clocks = < CPG_CORE R8A7795_CLK_S0D4>, < CPG_MOD 729>;

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 02/10] dt-bindings: display: renesas: dw-hdmi: tidyup example compatible.

2020-09-08 Thread Laurent Pinchart
Hi Kieran,

On Tue, Sep 08, 2020 at 03:18:20PM +0100, Kieran Bingham wrote:
> On 08/09/2020 01:34, Kuninori Morimoto wrote:
> > From: Kuninori Morimoto 
> > 
> > required is "renesas,r8a7795-hdmi", instead of "renesas,r8a7795-dw-hdmi"
> 
> Hrm, technically the driver will currently only match on :
>   "renesas,rcar-gen3-hdmi"
> 
> But I see how the '-dw-' has probably snuck in from other devices, and
> is inappropriate.
> 
> Perhaps this should be more clear that it matches on the generic compatible:
>   renesas,rcar-gen3-hdmi
> 
> (or a combination of both?)
>
> > Signed-off-by: Kuninori Morimoto 
> 
> But if the generic isn't required, then this patch alone does fix what I
> would call an error, so ...

You're right, the generic compatible string should be required. I'll
update this patch accordingly, and will address the bindings as part of
the conversion to YAML.

> Reviewed-by: Kieran Bingham 
> 
> We could always make this more clear when converting to YAML.
>
> > ---
> >  .../devicetree/bindings/display/bridge/renesas,dw-hdmi.txt  | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git 
> > a/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt 
> > b/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
> > index 819f3e31013c..e6526ab485d0 100644
> > --- a/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
> > +++ b/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
> > @@ -42,7 +42,7 @@ Optional properties:
> >  Example:
> >  
> > hdmi0: hdmi@fead {
> > -   compatible = "renesas,r8a7795-dw-hdmi";
> > +   compatible = "renesas,r8a7795-hdmi";
> > reg = <0 0xfead 0 0x1>;
> > interrupts = <0 389 IRQ_TYPE_LEVEL_HIGH>;
> > clocks = < CPG_CORE R8A7795_CLK_S0D4>, < CPG_MOD 729>;
> > 

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2] drm: mxsfb: check framebuffer pitch

2020-09-08 Thread Laurent Pinchart
Hi Stefan,

Thank you for the patch.

On Tue, Sep 08, 2020 at 02:55:58PM +0200, Stefan Agner wrote:
> The lcdif IP does not support a framebuffer pitch (stride) other than
> framebuffer width. Check for equality and reject the framebuffer
> otherwise.
> 
> This prevents a distorted picture when using 640x800 and running the
> Mesa graphics stack. Mesa tires to use a cache aligned stride, which

Still s/tires/tries/ :-)

> leads at that particular resolution to width != stride. Currently
> Mesa has no fallback behavior, but rejecting this configuration allows
> userspace to handle the issue correctly.
> 
> Signed-off-by: Stefan Agner 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/mxsfb/mxsfb_drv.c | 21 -
>  1 file changed, 20 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c 
> b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> index 8c549c3931af..fa6798d21029 100644
> --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> @@ -21,6 +21,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -81,8 +82,26 @@ void mxsfb_disable_axi_clk(struct mxsfb_drm_private *mxsfb)
>   clk_disable_unprepare(mxsfb->clk_axi);
>  }
>  
> +static struct drm_framebuffer *
> +mxsfb_fb_create(struct drm_device *dev, struct drm_file *file_priv,
> +   const struct drm_mode_fb_cmd2 *mode_cmd)
> +{
> + const struct drm_format_info *info;
> +
> + info = drm_get_format_info(dev, mode_cmd);
> + if (!info)
> + return ERR_PTR(-EINVAL);
> +
> + if (mode_cmd->width * info->cpp[0] != mode_cmd->pitches[0]) {
> + dev_dbg(dev->dev, "Invalid pitch: fb width must match pitch\n");
> + return ERR_PTR(-EINVAL);
> + }
> +
> + return drm_gem_fb_create(dev, file_priv, mode_cmd);
> +}
> +
>  static const struct drm_mode_config_funcs mxsfb_mode_config_funcs = {
> - .fb_create  = drm_gem_fb_create,
> + .fb_create  = mxsfb_fb_create,
>   .atomic_check   = drm_atomic_helper_check,
>   .atomic_commit  = drm_atomic_helper_commit,
>  };

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm: mxsfb: check framebuffer pitch

2020-09-08 Thread Laurent Pinchart
On Tue, Sep 08, 2020 at 02:29:02PM +0200, Daniel Vetter wrote:
> On Tue, Sep 8, 2020 at 2:07 PM Stefan Agner  wrote:
> > On 2020-09-08 10:48, Daniel Vetter wrote:
> >> On Tue, Sep 08, 2020 at 11:18:25AM +0300, Tomi Valkeinen wrote:
> >>> On 08/09/2020 10:55, Stefan Agner wrote:
> >>>> On 2020-09-07 20:18, Daniel Vetter wrote:
> >>>>> On Mon, Sep 07, 2020 at 07:17:12PM +0300, Laurent Pinchart wrote:
> >>>>>> Hi Stefan,
> >>>>>>
> >>>>>> Thank you for the patch.
> >>>>>>
> >>>>>> On Mon, Sep 07, 2020 at 06:03:43PM +0200, Stefan Agner wrote:
> >>>>>>> The lcdif IP does not support a framebuffer pitch (stride) other than
> >>>>>>> the CRTC width. Check for equality and reject the state otherwise.
> >>>>>>>
> >>>>>>> This prevents a distorted picture when using 640x800 and running the
> >>>>>>> Mesa graphics stack. Mesa tires to use a cache aligned stride, which
> >>>>>>
> >>>>>> s/tires/tries/
> >>>>>>
> >>>>>>> leads at that particular resolution to width != stride. Currently
> >>>>>>> Mesa has no fallback behavior, but rejecting this configuration allows
> >>>>>>> userspace to handle the issue correctly.
> >>>>>>
> >>>>>> I'm increasingly impressed by how featureful this IP core is :-)
> >>>>>>
> >>>>>>> Signed-off-by: Stefan Agner 
> >>>>>>> ---
> >>>>>>>  drivers/gpu/drm/mxsfb/mxsfb_kms.c | 22 ++
> >>>>>>>  1 file changed, 18 insertions(+), 4 deletions(-)
> >>>>>>>
> >>>>>>> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c 
> >>>>>>> b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> >>>>>>> index b721b8b262ce..79aa14027f91 100644
> >>>>>>> --- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> >>>>>>> +++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> >>>>>>> @@ -403,14 +403,28 @@ static int mxsfb_plane_atomic_check(struct 
> >>>>>>> drm_plane *plane,
> >>>>>>>  {
> >>>>>>> struct mxsfb_drm_private *mxsfb = 
> >>>>>>> to_mxsfb_drm_private(plane->dev);
> >>>>>>> struct drm_crtc_state *crtc_state;
> >>>>>>> +   unsigned int pitch;
> >>>>>>> +   int ret;
> >>>>>>>
> >>>>>>> crtc_state = drm_atomic_get_new_crtc_state(plane_state->state,
> >>>>>>>>crtc);
> >>>>>>>
> >>>>>>> -   return drm_atomic_helper_check_plane_state(plane_state, 
> >>>>>>> crtc_state,
> >>>>>>> -  
> >>>>>>> DRM_PLANE_HELPER_NO_SCALING,
> >>>>>>> -  
> >>>>>>> DRM_PLANE_HELPER_NO_SCALING,
> >>>>>>> -  false, true);
> >>>>>>> +   ret = drm_atomic_helper_check_plane_state(plane_state, 
> >>>>>>> crtc_state,
> >>>>>>> + 
> >>>>>>> DRM_PLANE_HELPER_NO_SCALING,
> >>>>>>> + 
> >>>>>>> DRM_PLANE_HELPER_NO_SCALING,
> >>>>>>> + false, true);
> >>>>>>> +   if (ret || !plane_state->visible)
> >>>>>>
> >>>>>> Would it be more explict to check for !plane_state->fb ? Otherwise I'll
> >>>>>> have to verify that !fb always implies !visible :-)
> >>>>>>
> >>>>>>> +   return ret;
> >>>>>>> +
> >>>>>>> +   pitch = crtc_state->mode.hdisplay *
> >>>>>>> +   plane_state->fb->format->cpp[0];
> >>>>>>
> >>>>>> This holds on a single line.
> >>>>>>
> >&g

Re: [PATCH] drm: mxsfb: check framebuffer pitch

2020-09-08 Thread Laurent Pinchart
On Tue, Sep 08, 2020 at 10:48:55AM +0200, Daniel Vetter wrote:
> On Tue, Sep 08, 2020 at 11:18:25AM +0300, Tomi Valkeinen wrote:
> > On 08/09/2020 10:55, Stefan Agner wrote:
> > > On 2020-09-07 20:18, Daniel Vetter wrote:
> > >> On Mon, Sep 07, 2020 at 07:17:12PM +0300, Laurent Pinchart wrote:
> > >>> Hi Stefan,
> > >>>
> > >>> Thank you for the patch.
> > >>>
> > >>> On Mon, Sep 07, 2020 at 06:03:43PM +0200, Stefan Agner wrote:
> > >>>> The lcdif IP does not support a framebuffer pitch (stride) other than
> > >>>> the CRTC width. Check for equality and reject the state otherwise.
> > >>>>
> > >>>> This prevents a distorted picture when using 640x800 and running the
> > >>>> Mesa graphics stack. Mesa tires to use a cache aligned stride, which
> > >>>
> > >>> s/tires/tries/
> > >>>
> > >>>> leads at that particular resolution to width != stride. Currently
> > >>>> Mesa has no fallback behavior, but rejecting this configuration allows
> > >>>> userspace to handle the issue correctly.
> > >>>
> > >>> I'm increasingly impressed by how featureful this IP core is :-)
> > >>>
> > >>>> Signed-off-by: Stefan Agner 
> > >>>> ---
> > >>>>  drivers/gpu/drm/mxsfb/mxsfb_kms.c | 22 ++
> > >>>>  1 file changed, 18 insertions(+), 4 deletions(-)
> > >>>>
> > >>>> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c 
> > >>>> b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> > >>>> index b721b8b262ce..79aa14027f91 100644
> > >>>> --- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> > >>>> +++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> > >>>> @@ -403,14 +403,28 @@ static int mxsfb_plane_atomic_check(struct 
> > >>>> drm_plane *plane,
> > >>>>  {
> > >>>>struct mxsfb_drm_private *mxsfb = 
> > >>>> to_mxsfb_drm_private(plane->dev);
> > >>>>struct drm_crtc_state *crtc_state;
> > >>>> +  unsigned int pitch;
> > >>>> +  int ret;
> > >>>>
> > >>>>crtc_state = drm_atomic_get_new_crtc_state(plane_state->state,
> > >>>>   >crtc);
> > >>>>
> > >>>> -  return drm_atomic_helper_check_plane_state(plane_state, 
> > >>>> crtc_state,
> > >>>> - 
> > >>>> DRM_PLANE_HELPER_NO_SCALING,
> > >>>> - 
> > >>>> DRM_PLANE_HELPER_NO_SCALING,
> > >>>> - false, true);
> > >>>> +  ret = drm_atomic_helper_check_plane_state(plane_state, 
> > >>>> crtc_state,
> > >>>> +
> > >>>> DRM_PLANE_HELPER_NO_SCALING,
> > >>>> +
> > >>>> DRM_PLANE_HELPER_NO_SCALING,
> > >>>> +false, true);
> > >>>> +  if (ret || !plane_state->visible)
> > >>>
> > >>> Would it be more explict to check for !plane_state->fb ? Otherwise I'll
> > >>> have to verify that !fb always implies !visible :-)
> > >>>
> > >>>> +  return ret;
> > >>>> +
> > >>>> +  pitch = crtc_state->mode.hdisplay *
> > >>>> +  plane_state->fb->format->cpp[0];
> > >>>
> > >>> This holds on a single line.
> > >>>
> > >>>> +  if (plane_state->fb->pitches[0] != pitch) {
> > >>>> +  dev_err(plane->dev->dev,
> > >>>> +  "Invalid pitch: fb and crtc widths must be the 
> > >>>> same");
> > >>>
> > >>> I'd turn this into a dev_dbg(), printing error messages to the kernel
> > >>> log in response to user-triggered conditions is a bit too verbose and
> > >>> could flood the log.
> > >>>
> > >>> Wouldn't it be best to catch this issue when creating the framebuffer ?
> > >>
> > >> Yeah this should be verified at addfb time. We try to validate as early 
> > >> as
> > >> possible.
> > > 
> > > Sounds sensible. From what I can tell fb_create is the proper callback
> > > to implement this at addfb time. Will give this a try.
> > > 
> > > FWIW, I got the idea from drivers/gpu/drm/tilcdc/tilcdc_plane.c. Maybe
> > > should be moved to addfb there too?
> > 
> > But you don't know the crtc width when creating the framebuffer.
> 
> Hm right this is a different check. What we could check in fb_create for
> both is that the logical fb size matches exactly the pitch. That's not
> sufficient criteria, but it will at least catch some of them already.
> 
> But yeah we'd need both here.

Correct. At addfb time we can check the pitch, and at atomic check time
we should check that the plane spans the whole CRTC.

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 10/10] arm64: dts: renesas: r8a77961-salvator-xs: add HDMI Sound support

2020-09-08 Thread Laurent Pinchart
Hi Morimoto-san,

On Tue, Sep 08, 2020 at 03:33:29PM +0900, Kuninori Morimoto wrote:
> 
> Hi Laurent
> 
> Thank you for your review
> 
> > > From: Kuninori Morimoto 
> > > 
> > > This patch enables HDMI Sound on R-Car M3-W+ Salvator-XS board.
> > > 
> > > This reverts commit b997613fad58a03588f0f64a3d86db6c5bd76dd2.
> > 
> > Which tree can this commit be found in ?
> 
> Grr, I forgot to remove it from git-log.
> will fix in v3

No worries :-)

I've applied patch 01 to 04 to my tree and plan to send a pull request
later today. Could you just let me know if you're fine with the small
modification to the commit message proposed in 04/10 ?

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 10/10] arm64: dts: renesas: r8a77961-salvator-xs: add HDMI Sound support

2020-09-08 Thread Laurent Pinchart
Hi Morimoto-san,

Thank you for the patch.

On Tue, Sep 08, 2020 at 09:35:25AM +0900, Kuninori Morimoto wrote:
> From: Kuninori Morimoto 
> 
> This patch enables HDMI Sound on R-Car M3-W+ Salvator-XS board.
> 
> This reverts commit b997613fad58a03588f0f64a3d86db6c5bd76dd2.

Which tree can this commit be found in ?

> Signed-off-by: Kuninori Morimoto 
> ---
>  .../boot/dts/renesas/r8a77961-salvator-xs.dts | 29 +++
>  1 file changed, 29 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/renesas/r8a77961-salvator-xs.dts 
> b/arch/arm64/boot/dts/renesas/r8a77961-salvator-xs.dts
> index ca21a702db54..1e7603365106 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77961-salvator-xs.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a77961-salvator-xs.dts
> @@ -51,9 +51,38 @@ rcar_dw_hdmi0_out: endpoint {
>   remote-endpoint = <_con>;
>   };
>   };
> + port@2 {
> + reg = <2>;
> + dw_hdmi0_snd_in: endpoint {
> + remote-endpoint = <_endpoint1>;
> + };
> + };
>   };
>  };
>  
>  _con {
>   remote-endpoint = <_dw_hdmi0_out>;
>  };
> +
> +_sound {
> + ports {
> + /* rsnd_port0 is on salvator-common */
> + rsnd_port1: port@1 {
> + reg = <1>;
> + rsnd_endpoint1: endpoint {
> + remote-endpoint = <_hdmi0_snd_in>;
> +
> + dai-format = "i2s";
> + bitclock-master = <_endpoint1>;
> + frame-master = <_endpoint1>;
> +
> + playback = <>;
> + };
> + };
> + };
> +};
> +
> +_card {
> + dais = <_port0 /* ak4613 */
> + _port1>;   /* HDMI0  */
> +};

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 09/10] arm64: dts: renesas: r8a77961-salvator-xs: add HDMI Display support

2020-09-08 Thread Laurent Pinchart
Hi Morimoto-san,

Thank you for the patch.

On Tue, Sep 08, 2020 at 09:35:20AM +0900, Kuninori Morimoto wrote:
> From: Kuninori Morimoto 
> 
> This patch enables HDMI Display on R-Car M3-W+ Salvator-XS board.
> 
> Signed-off-by: Kuninori Morimoto 

Reviewed-by: Laurent Pinchart 

> ---
>  .../boot/dts/renesas/r8a77961-salvator-xs.dts | 28 +++
>  1 file changed, 28 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/renesas/r8a77961-salvator-xs.dts 
> b/arch/arm64/boot/dts/renesas/r8a77961-salvator-xs.dts
> index 2ffc7e31dd58..ca21a702db54 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77961-salvator-xs.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a77961-salvator-xs.dts
> @@ -29,3 +29,31 @@ memory@6 {
>   reg = <0x6 0x 0x1 0x>;
>   };
>  };
> +
> + {
> + clocks = < CPG_MOD 724>,
> +  < CPG_MOD 723>,
> +  < CPG_MOD 722>,
> +  < 1>,
> +  <_clk>,
> +  < 2>;
> + clock-names = "du.0", "du.1", "du.2",
> +   "dclkin.0", "dclkin.1", "dclkin.2";
> +};
> +
> + {
> + status = "okay";
> +
> + ports {
> + port@1 {
> + reg = <1>;
> + rcar_dw_hdmi0_out: endpoint {
> + remote-endpoint = <_con>;
> + };
> + };
> + };
> +};
> +
> +_con {
> + remote-endpoint = <_dw_hdmi0_out>;
> +};

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 08/10] arm64: dts: renesas: r8a77961: Add HDMI device nodes

2020-09-08 Thread Laurent Pinchart
Hi Morimoto-san,

Thank you for the patch.

On Tue, Sep 08, 2020 at 09:35:15AM +0900, Kuninori Morimoto wrote:
> 
> From: Kuninori Morimoto 
> 
> This patch adds HDMI device nodes for R-Car M3-W+ (r8a77961) SoC.
> This patch was tested on R-Car M3-W+ Salvator-XS board.
> 
> Signed-off-by: Kuninori Morimoto 

Reviewed-by: Laurent Pinchart 

> ---
>  arch/arm64/boot/dts/renesas/r8a77961.dtsi | 12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/renesas/r8a77961.dtsi 
> b/arch/arm64/boot/dts/renesas/r8a77961.dtsi
> index c7fabd9e875b..7f21491f6436 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77961.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a77961.dtsi
> @@ -2145,14 +2145,23 @@ port@1 {
>   };
>  
>   hdmi0: hdmi@fead {
> + compatible = "renesas,r8a77961-hdmi", 
> "renesas,rcar-gen3-hdmi";
>   reg = <0 0xfead 0 0x1>;
> - /* placeholder */
> + interrupts = ;
> + clocks = < CPG_MOD 729>, < CPG_CORE 
> R8A77961_CLK_HDMI>;
> + clock-names = "iahb", "isfr";
> + power-domains = < R8A77961_PD_ALWAYS_ON>;
> + resets = < 729>;
> + status = "disabled";
>  
>   ports {
>   #address-cells = <1>;
>   #size-cells = <0>;
>   port@0 {
>   reg = <0>;
> + dw_hdmi0_in: endpoint {
> + remote-endpoint = 
> <_out_hdmi0>;
> + };
>   };
>   port@1 {
>   reg = <1>;
> @@ -2191,6 +2200,7 @@ du_out_rgb: endpoint {
>   port@1 {
>   reg = <1>;
>       du_out_hdmi0: endpoint {
> + remote-endpoint = 
> <_hdmi0_in>;
>   };
>   };
>   port@2 {

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 07/10] arm64: dts: renesas: r8a77961: Add DU device nodes

2020-09-08 Thread Laurent Pinchart
Hi Morimoto-san,

Thank you for the patch.

On Tue, Sep 08, 2020 at 09:35:10AM +0900, Kuninori Morimoto wrote:
> 
> From: Kuninori Morimoto 
> 
> This patch adds DU device nodes for R-Car M3-W+ (r8a77961) SoC.
> This patch was tested on R-Car M3-W+ Salvator-XS board.
> 
> Signed-off-by: Kuninori Morimoto 

Reviewed-by: Laurent Pinchart 

> ---
>  arch/arm64/boot/dts/renesas/r8a77961.dtsi | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/renesas/r8a77961.dtsi 
> b/arch/arm64/boot/dts/renesas/r8a77961.dtsi
> index 423808b6cd58..c7fabd9e875b 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77961.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a77961.dtsi
> @@ -2165,8 +2165,19 @@ port@2 {
>   };
>  
>   du: display@feb0 {
> + compatible = "renesas,du-r8a77961";
>   reg = <0 0xfeb0 0 0x7>;
> - /* placeholder */
> + interrupts = ,
> +  ,
> +  ;
> + clocks = < CPG_MOD 724>, < CPG_MOD 723>,
> +  < CPG_MOD 722>;
> + clock-names = "du.0", "du.1", "du.2";
> + resets = < 724>, < 722>;
> + reset-names = "du.0", "du.2";
> +
> +     renesas,vsps = < 0>, < 0>, < 0>;
> + status = "disabled";
>  
>   ports {
>   #address-cells = <1>;

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 06/10] arm64: dts: renesas: r8a77961: Add VSP device nodes

2020-09-08 Thread Laurent Pinchart
Hi Morimoto-san,

On Tue, Sep 08, 2020 at 09:34:59AM +0900, Kuninori Morimoto wrote:
> 
> From: Kuninori Morimoto 
> 
> This patch adds VSP device nodes for R-Car M3-W+ (r8a77961) SoC.
> This patch was tested on R-Car M3-W+ Salvator-XS board.
> 
> Signed-off-by: Kuninori Morimoto 

Reviewed-by: Laurent Pinchart 

> ---
>  arch/arm64/boot/dts/renesas/r8a77961.dtsi | 55 +++
>  1 file changed, 55 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/renesas/r8a77961.dtsi 
> b/arch/arm64/boot/dts/renesas/r8a77961.dtsi
> index fe0db11b9cb9..423808b6cd58 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77961.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a77961.dtsi
> @@ -2012,6 +2012,17 @@ fcpf0: fcp@fe95 {
>   resets = < 615>;
>   };
>  
> + vspb: vsp@fe96 {
> + compatible = "renesas,vsp2";
> + reg = <0 0xfe96 0 0x8000>;
> + interrupts = ;
> + clocks = < CPG_MOD 626>;
> + power-domains = < R8A77961_PD_A3VC>;
> + resets = < 626>;
> +
> + renesas,fcp = <>;
> + };
> +
>   fcpvb0: fcp@fe96f000 {
>   compatible = "renesas,fcpv";
>   reg = <0 0xfe96f000 0 0x200>;
> @@ -2020,6 +2031,17 @@ fcpvb0: fcp@fe96f000 {
>   resets = < 607>;
>   };
>  
> + vspi0: vsp@fe9a {
> + compatible = "renesas,vsp2";
> + reg = <0 0xfe9a 0 0x8000>;
> + interrupts = ;
> + clocks = < CPG_MOD 631>;
> + power-domains = < R8A77961_PD_A3VC>;
> + resets = < 631>;
> +
> + renesas,fcp = <>;
> + };
> +
>   fcpvi0: fcp@fe9af000 {
>   compatible = "renesas,fcpv";
>   reg = <0 0xfe9af000 0 0x200>;
> @@ -2029,6 +2051,17 @@ fcpvi0: fcp@fe9af000 {
>   iommus = <_vc0 19>;
>   };
>  
> + vspd0: vsp@fea2 {
> + compatible = "renesas,vsp2";
> + reg = <0 0xfea2 0 0x5000>;
> + interrupts = ;
> + clocks = < CPG_MOD 623>;
> + power-domains = < R8A77961_PD_ALWAYS_ON>;
> + resets = < 623>;
> +
> + renesas,fcp = <>;
> + };
> +
>   fcpvd0: fcp@fea27000 {
>   compatible = "renesas,fcpv";
>   reg = <0 0xfea27000 0 0x200>;
> @@ -2038,6 +2071,17 @@ fcpvd0: fcp@fea27000 {
>   iommus = <_vi0 8>;
>   };
>  
> + vspd1: vsp@fea28000 {
> + compatible = "renesas,vsp2";
> + reg = <0 0xfea28000 0 0x5000>;
> + interrupts = ;
> + clocks = < CPG_MOD 622>;
> + power-domains = < R8A77961_PD_ALWAYS_ON>;
> + resets = < 622>;
> +
> + renesas,fcp = <>;
> + };
> +
>   fcpvd1: fcp@fea2f000 {
>   compatible = "renesas,fcpv";
>   reg = <0 0xfea2f000 0 0x200>;
> @@ -2047,6 +2091,17 @@ fcpvd1: fcp@fea2f000 {
>   iommus = <_vi0 9>;
>   };
>  
> + vspd2: vsp@fea3 {
> +     compatible = "renesas,vsp2";
> + reg = <0 0xfea3 0 0x5000>;
> + interrupts = ;
> + clocks = < CPG_MOD 621>;
> + power-domains = < R8A77961_PD_ALWAYS_ON>;
> + resets = < 621>;
> +
> + renesas,fcp = <>;
> + };
> +
>   fcpvd2: fcp@fea37000 {
>   compatible = "renesas,fcpv";
>   reg = <0 0xfea37000 0 0x200>;

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 05/10] arm64: dts: renesas: r8a77961: Add FCP device nodes

2020-09-07 Thread Laurent Pinchart
Hi Morimoto-san,

Thank you for the patch.

On Tue, Sep 08, 2020 at 09:34:50AM +0900, Kuninori Morimoto wrote:
> 
> From: Kuninori Morimoto 
> 
> This patch adds FCP device nodes for R-Car M3-W+ (r8a77961) SoC.
> This patch was tested on R-Car M3-W+ Salvator-XS board.
> 
> Signed-off-by: Kuninori Morimoto 

Reviewed-by: Laurent Pinchart 

> ---
>  arch/arm64/boot/dts/renesas/r8a77961.dtsi | 52 +++
>  1 file changed, 52 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/renesas/r8a77961.dtsi 
> b/arch/arm64/boot/dts/renesas/r8a77961.dtsi
> index 0abfea0b27be..fe0db11b9cb9 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77961.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a77961.dtsi
> @@ -2004,6 +2004,58 @@ pciec1: pcie@ee80 {
>   status = "disabled";
>   };
>  
> + fcpf0: fcp@fe95 {
> + compatible = "renesas,fcpf";
> + reg = <0 0xfe95 0 0x200>;
> + clocks = < CPG_MOD 615>;
> + power-domains = < R8A77961_PD_A3VC>;
> + resets = < 615>;
> + };
> +
> + fcpvb0: fcp@fe96f000 {
> + compatible = "renesas,fcpv";
> + reg = <0 0xfe96f000 0 0x200>;
> + clocks = < CPG_MOD 607>;
> + power-domains = < R8A77961_PD_A3VC>;
> + resets = < 607>;
> + };
> +
> + fcpvi0: fcp@fe9af000 {
> + compatible = "renesas,fcpv";
> + reg = <0 0xfe9af000 0 0x200>;
> + clocks = < CPG_MOD 611>;
> + power-domains = < R8A77961_PD_A3VC>;
> + resets = < 611>;
> + iommus = <_vc0 19>;
> + };
> +
> + fcpvd0: fcp@fea27000 {
> + compatible = "renesas,fcpv";
> + reg = <0 0xfea27000 0 0x200>;
> + clocks = < CPG_MOD 603>;
> + power-domains = < R8A77961_PD_ALWAYS_ON>;
> + resets = < 603>;
> + iommus = <_vi0 8>;
> + };
> +
> + fcpvd1: fcp@fea2f000 {
> + compatible = "renesas,fcpv";
> + reg = <0 0xfea2f000 0 0x200>;
> + clocks = < CPG_MOD 602>;
> + power-domains = < R8A77961_PD_ALWAYS_ON>;
> + resets = < 602>;
> + iommus = <_vi0 9>;
> + };
> +
> + fcpvd2: fcp@fea37000 {
> + compatible = "renesas,fcpv";
> + reg = <0 0xfea37000 0 0x200>;
> + clocks = < CPG_MOD 601>;
> + power-domains = < R8A77961_PD_ALWAYS_ON>;
> + resets = < 601>;
> + iommus = <_vi0 10>;
> + };
> +
>   csi20: csi2@fea8 {
>   reg = <0 0xfea8 0 0x1>;
>   /* placeholder */

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 04/10] drm: rcar-du: Add r8a77961 support

2020-09-07 Thread Laurent Pinchart
Hi Morimoto-san,

Thank you for the patch.

On Tue, Sep 08, 2020 at 09:34:32AM +0900, Kuninori Morimoto wrote:
> 
> From: Kuninori Morimoto 
> 
> This patch adds R-Car M3-W+ (R8A77961) support which has
> compatible to R-Car M3-W (R8A77960).

Maybe "... is compatible with the ..." ?

> Signed-off-by: Kuninori Morimoto 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/rcar-du/rcar_du_drv.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c 
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> index f53b0ec71085..64533cbdbef0 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> @@ -458,6 +458,7 @@ static const struct of_device_id rcar_du_of_table[] = {
>   { .compatible = "renesas,du-r8a7794", .data = _du_r8a7794_info },
>   { .compatible = "renesas,du-r8a7795", .data = _du_r8a7795_info },
>   { .compatible = "renesas,du-r8a7796", .data = _du_r8a7796_info },
> + { .compatible = "renesas,du-r8a77961", .data = _du_r8a7796_info },
>   { .compatible = "renesas,du-r8a77965", .data = _du_r8a77965_info },
>   { .compatible = "renesas,du-r8a77970", .data = _du_r8a77970_info },
>   { .compatible = "renesas,du-r8a77980", .data = _du_r8a77970_info },

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 03/10] dt-bindings: display: renesas: dw-hdmi: Add R8A77961 support

2020-09-07 Thread Laurent Pinchart
Hi Morimoto-san,

Thank you for the patch.

On Tue, Sep 08, 2020 at 09:34:17AM +0900, Kuninori Morimoto wrote:
> From: Kuninori Morimoto 
> 
> This patch adds R-Car M3-W+ (R8A77961) SoC bindings.
> 
> Signed-off-by: Kuninori Morimoto 
> Reviewed-by: Geert Uytterhoeven 

Reviewed-by: Laurent Pinchart 

> ---
>  .../devicetree/bindings/display/bridge/renesas,dw-hdmi.txt   | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt 
> b/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
> index e6526ab485d0..2086f4514911 100644
> --- a/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
> +++ b/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
> @@ -16,6 +16,7 @@ Required properties:
>- "renesas,r8a774b1-hdmi" for R8A774B1 (RZ/G2N) compatible HDMI TX
>- "renesas,r8a7795-hdmi" for R8A7795 (R-Car H3) compatible HDMI TX
>- "renesas,r8a7796-hdmi" for R8A7796 (R-Car M3-W) compatible HDMI TX
> +  - "renesas,r8a77961-hdmi" for R8A77961 (R-Car M3-W+) compatible HDMI TX
>- "renesas,r8a77965-hdmi" for R8A77965 (R-Car M3-N) compatible HDMI TX
>- "renesas,rcar-gen3-hdmi" for the generic R-Car Gen3 and RZ/G2 compatible
>HDMI TX

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 02/10] dt-bindings: display: renesas: dw-hdmi: tidyup example compatible.

2020-09-07 Thread Laurent Pinchart
Hi Morimoto-san,

Thank you for the patch.

On Tue, Sep 08, 2020 at 09:34:11AM +0900, Kuninori Morimoto wrote:
> From: Kuninori Morimoto 
> 
> required is "renesas,r8a7795-hdmi", instead of "renesas,r8a7795-dw-hdmi"
> 
> Signed-off-by: Kuninori Morimoto 

Reviewed-by: Laurent Pinchart 

> ---
>  .../devicetree/bindings/display/bridge/renesas,dw-hdmi.txt  | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt 
> b/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
> index 819f3e31013c..e6526ab485d0 100644
> --- a/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
> +++ b/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
> @@ -42,7 +42,7 @@ Optional properties:
>  Example:
>  
>   hdmi0: hdmi@fead {
> - compatible = "renesas,r8a7795-dw-hdmi";
> + compatible = "renesas,r8a7795-hdmi";
>   reg = <0 0xfead 0 0x1>;
>   interrupts = <0 389 IRQ_TYPE_LEVEL_HIGH>;
>   clocks = < CPG_CORE R8A7795_CLK_S0D4>, < CPG_MOD 729>;

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 01/10] dt-bindings: display: renesas: du: Document the r8a77961 bindings

2020-09-07 Thread Laurent Pinchart
Hi Morimoto-san,

Thank you for the patch.

On Tue, Sep 08, 2020 at 09:34:04AM +0900, Kuninori Morimoto wrote:
> From: Kuninori Morimoto 
> 
> Document the R-Car M3-W+ (R8A77961) SoC in the R-Car DU bindings.
> 
> Signed-off-by: Kuninori Morimoto 

Reviewed-by: Laurent Pinchart 

> ---
>  Documentation/devicetree/bindings/display/renesas,du.txt | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/display/renesas,du.txt 
> b/Documentation/devicetree/bindings/display/renesas,du.txt
> index 51cd4d162770..317c9dd2d57c 100644
> --- a/Documentation/devicetree/bindings/display/renesas,du.txt
> +++ b/Documentation/devicetree/bindings/display/renesas,du.txt
> @@ -18,6 +18,7 @@ Required Properties:
>  - "renesas,du-r8a7794" for R8A7794 (R-Car E2) compatible DU
>  - "renesas,du-r8a7795" for R8A7795 (R-Car H3) compatible DU
>  - "renesas,du-r8a7796" for R8A7796 (R-Car M3-W) compatible DU
> +- "renesas,du-r8a77961" for R8A77961 (R-Car M3-W+) compatible DU
>  - "renesas,du-r8a77965" for R8A77965 (R-Car M3-N) compatible DU
>  - "renesas,du-r8a77970" for R8A77970 (R-Car V3M) compatible DU
>  - "renesas,du-r8a77980" for R8A77980 (R-Car V3H) compatible DU
> @@ -83,6 +84,7 @@ corresponding to each DU output.
>   R8A7794 (R-Car E2) DPAD 0 DPAD 1 -  -
>   R8A7795 (R-Car H3) DPAD 0 HDMI 0 HDMI 1 LVDS 0
>   R8A7796 (R-Car M3-W)   DPAD 0 HDMI 0 LVDS 0 -
> + R8A77961 (R-Car M3-W+) DPAD 0 HDMI 0 LVDS 0 -
>   R8A77965 (R-Car M3-N)  DPAD 0 HDMI 0 LVDS 0 -
>   R8A77970 (R-Car V3M)   DPAD 0 LVDS 0 -  -
>   R8A77980 (R-Car V3H)   DPAD 0 LVDS 0 -  -

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [RFC] Experimental DMA-BUF Device Heaps

2020-09-07 Thread Laurent Pinchart
buf;
> > +
> > +   buf->dmabuf = dma_buf_export(_info);
> > +   if (IS_ERR(buf->dmabuf)) {
> > +   dev_err(buf->dev, "failed to export dmabuf\n");
> > +   return PTR_ERR(buf->dmabuf);
> > +   }
> > +
> > +   ret = dma_buf_fd(buf->dmabuf, fd_flags);
> > +   if (ret < 0) {
> > +   dev_err(buf->dev, "failed to get dmabuf fd: %d\n", ret);
> > +   return ret;
> > +   }
> > +
> > +   return ret;
> > +}
> > +
> > +static const struct dma_heap_ops dev_heap_ops = {
> > +   .allocate = dev_heap_allocate,
> > +};
> > +
> > +void dev_dma_heap_add(struct device *dev)
> > +{
> > +   struct dma_heap_export_info exp_info;
> > +
> > +   exp_info.name = dev_name(dev);
> > +   exp_info.ops = _heap_ops;
> > +   exp_info.priv = dev;
> > +
> > +   dev->heap = dma_heap_add(_info);
> > +}
> > +EXPORT_SYMBOL(dev_dma_heap_add);
> > diff --git a/include/linux/device.h b/include/linux/device.h
> > index ca18da4768e3..1fae95d55ea1 100644
> > --- a/include/linux/device.h
> > +++ b/include/linux/device.h
> > @@ -45,6 +45,7 @@ struct iommu_ops;
> >  struct iommu_group;
> >  struct dev_pin_info;
> >  struct dev_iommu;
> > +struct dma_heap;
> >  
> >  /**
> >   * struct subsys_interface - interfaces to device functions
> > @@ -597,6 +598,10 @@ struct device {
> > struct iommu_group  *iommu_group;
> > struct dev_iommu*iommu;
> >  
> > +#ifdef CONFIG_DMABUF_HEAPS_DEVICES
> > +   struct dma_heap *heap;
> > +#endif
> > +
> > booloffline_disabled:1;
> > booloffline:1;
> > boolof_node_reused:1;
> > diff --git a/include/linux/dma-heap.h b/include/linux/dma-heap.h
> > index 454e354d1ffb..dcf7cca2f487 100644
> > --- a/include/linux/dma-heap.h
> > +++ b/include/linux/dma-heap.h
> > @@ -56,4 +56,10 @@ void *dma_heap_get_drvdata(struct dma_heap *heap);
> >   */
> >  struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info);
> >  
> > +#ifdef CONFIG_DMABUF_HEAPS_DEVICES
> > +void dev_dma_heap_add(struct device *dev);
> > +#else
> > +static inline void dev_dma_heap_add(struct device *dev) {}
> > +#endif
> > +
> >  #endif /* _DMA_HEAPS_H */

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm: mxsfb: check framebuffer pitch

2020-09-07 Thread Laurent Pinchart
Hi Stefan,

Thank you for the patch.

On Mon, Sep 07, 2020 at 06:03:43PM +0200, Stefan Agner wrote:
> The lcdif IP does not support a framebuffer pitch (stride) other than
> the CRTC width. Check for equality and reject the state otherwise.
> 
> This prevents a distorted picture when using 640x800 and running the
> Mesa graphics stack. Mesa tires to use a cache aligned stride, which

s/tires/tries/

> leads at that particular resolution to width != stride. Currently
> Mesa has no fallback behavior, but rejecting this configuration allows
> userspace to handle the issue correctly.

I'm increasingly impressed by how featureful this IP core is :-)

> Signed-off-by: Stefan Agner 
> ---
>  drivers/gpu/drm/mxsfb/mxsfb_kms.c | 22 ++
>  1 file changed, 18 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c 
> b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> index b721b8b262ce..79aa14027f91 100644
> --- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> +++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> @@ -403,14 +403,28 @@ static int mxsfb_plane_atomic_check(struct drm_plane 
> *plane,
>  {
>   struct mxsfb_drm_private *mxsfb = to_mxsfb_drm_private(plane->dev);
>   struct drm_crtc_state *crtc_state;
> + unsigned int pitch;
> + int ret;
>  
>   crtc_state = drm_atomic_get_new_crtc_state(plane_state->state,
>  >crtc);
>  
> - return drm_atomic_helper_check_plane_state(plane_state, crtc_state,
> -DRM_PLANE_HELPER_NO_SCALING,
> -DRM_PLANE_HELPER_NO_SCALING,
> -false, true);
> + ret = drm_atomic_helper_check_plane_state(plane_state, crtc_state,
> +   DRM_PLANE_HELPER_NO_SCALING,
> +   DRM_PLANE_HELPER_NO_SCALING,
> +   false, true);
> + if (ret || !plane_state->visible)

Would it be more explict to check for !plane_state->fb ? Otherwise I'll
have to verify that !fb always implies !visible :-)

> + return ret;
> +
> + pitch = crtc_state->mode.hdisplay *
> + plane_state->fb->format->cpp[0];

This holds on a single line.

> + if (plane_state->fb->pitches[0] != pitch) {
> + dev_err(plane->dev->dev,
> + "Invalid pitch: fb and crtc widths must be the same");

I'd turn this into a dev_dbg(), printing error messages to the kernel
log in response to user-triggered conditions is a bit too verbose and
could flood the log.

Wouldn't it be best to catch this issue when creating the framebuffer ?

> + return -EINVAL;
> + }
> +
> + return 0;
>  }
>  
>  static void mxsfb_plane_primary_atomic_update(struct drm_plane *plane,

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [GIT PULL FOR v5.9] Fix Kconfig dependency issue with DMAENGINES selection

2020-09-05 Thread Laurent Pinchart
With Dave and Daniel on the recipients' list this time.

On Sat, Sep 05, 2020 at 08:27:51PM +0300, Laurent Pinchart wrote:
> Hi Dave and Daniel,
> 
> This small pull request fixes a Kconfig dependency issue introduced in
> v5.9-rc1. Among the three patches required to fix the issue, the ASoC
> fix has been merged in Linus' tree already. I haven't been able to get
> the RapidIO patch reviewed by the subsystem maintainers, so I've
> included it here as it's a dependency for the DRM patch.
> 
> The following changes since commit f75aef392f869018f78cfedf3c320a6b3fcfda6b:
> 
>   Linux 5.9-rc3 (2020-08-30 16:01:54 -0700)
> 
> are available in the Git repository at:
> 
>   git://linuxtv.org/pinchartl/media.git tags/drm-xlnx-dpsub-fixes-20200905
> 
> for you to fetch changes up to 3e8b2403545efd46c6347002e27eae4708205fd4:
> 
>   drm: xlnx: dpsub: Fix DMADEVICES Kconfig dependency (2020-09-05 19:52:54 
> +0300)
> 
> 
> Kconfig fixes for DRM_ZYNQMP_DPSUB DMA engine dependency
> 
> 
> Laurent Pinchart (2):
>   rapidio: Replace 'select' DMAENGINES 'with depends on'
>   drm: xlnx: dpsub: Fix DMADEVICES Kconfig dependency
> 
>  drivers/gpu/drm/xlnx/Kconfig | 1 +
>  drivers/rapidio/Kconfig  | 2 +-
>  2 files changed, 2 insertions(+), 1 deletion(-)
> 

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[GIT PULL FOR v5.9] Fix Kconfig dependency issue with DMAENGINES selection

2020-09-05 Thread Laurent Pinchart
Hi Dave and Daniel,

This small pull request fixes a Kconfig dependency issue introduced in
v5.9-rc1. Among the three patches required to fix the issue, the ASoC
fix has been merged in Linus' tree already. I haven't been able to get
the RapidIO patch reviewed by the subsystem maintainers, so I've
included it here as it's a dependency for the DRM patch.

The following changes since commit f75aef392f869018f78cfedf3c320a6b3fcfda6b:

  Linux 5.9-rc3 (2020-08-30 16:01:54 -0700)

are available in the Git repository at:

  git://linuxtv.org/pinchartl/media.git tags/drm-xlnx-dpsub-fixes-20200905

for you to fetch changes up to 3e8b2403545efd46c6347002e27eae4708205fd4:

  drm: xlnx: dpsub: Fix DMADEVICES Kconfig dependency (2020-09-05 19:52:54 
+0300)


Kconfig fixes for DRM_ZYNQMP_DPSUB DMA engine dependency


Laurent Pinchart (2):
  rapidio: Replace 'select' DMAENGINES 'with depends on'
  drm: xlnx: dpsub: Fix DMADEVICES Kconfig dependency

 drivers/gpu/drm/xlnx/Kconfig | 1 +
 drivers/rapidio/Kconfig  | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 4/5] dt-bindings: display/bridge: nwl-dsi: Document fsl,clock-drop-level property

2020-09-05 Thread Laurent Pinchart
Hi Robert,

Thank you for the patch.

On Fri, Aug 28, 2020 at 02:13:31PM +0300, Robert Chiras (OSS) wrote:
> From: Robert Chiras 
> 
> Add documentation for a new property: 'fsl,clock-drop-level'.
> 
> Signed-off-by: Robert Chiras 
> ---
>  Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml 
> b/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
> index 8b5741b..b415f4e 100644
> --- a/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
> @@ -143,6 +143,10 @@ properties:
>  
>  additionalProperties: false
>  
> +  clock-drop-level:
> +description:
> +  Specifies the level at wich the crtc_clock should be dropped
> +

There's no "crtc_clock" defined in the bindings. As DT bindings
shouldn't be tied to a particular driver implementation, could you
document this property without referring to concepts specific to the
driver ? I think the documentation should also be extended, looking at
this patch I have no idea what this does and how to compute the value
that should be set.

>  patternProperties:
>"^panel@[0-9]+$":
>  type: object

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v9 2/3] drm: bridge: Add support for Cadence MHDP8546 DPI/DP bridge

2020-09-03 Thread Laurent Pinchart
bandwidth_ok() should take display_fmt or bpp as a parameter, as 
> currently it digs that up
> from the current state.
> 
> Probably cdns_mhdp_validate_mode_params() would be better if it doesn't write 
> the result to the
> state, but returns the values. That way it could also be used to verify if 
> suitable settings can be
> found, without changing the state.

This use case is actually a very good example of proper usage of the
atomic state :-) .atomic_check() has to perform computations to verify
the atomic commit, and storing the results in the commit's state
prevents duplicating the same calculation at .atomic_commit() time.

> The are two issues I see with some testing, which are probably related.
> 
> The first one is that if I run kmstest with a new mode, I see tu-size & co 
> being calculated. But the
> calculation happens before link training, which doesn't make sense. So I 
> think what's done here is
> that atomic_check causes tu-size calculations, then atomic_enable does link 
> training and enables the
> video.
> 
> The second happens when my monitor fails with the first CR after power-on, 
> and the driver drops
> number-of-lanes to 2. It goes like this:
> 
> The driver is loaded. Based on EDID, fbdev is created with 1920x1200. Link 
> training is done, which
> has the CR issue, and because of that the actual mode that we get is 
> 1280x960. I get a proper
> picture here, so far so good.
> 
> Then if I run kmstest, it only allows 1280x960 as the link doesn't support 
> higher modes (that's ok).
> It the does link training and gets a 4 lane link, and enables 1280x960. But 
> the picture is not ok.
> 
> If I then exit kmstest, it goes back to fbdev, but now that picture is broken 
> also.
> 
> Running kmstest again gives me 1920x1200 (as the link has been 4 lane now), 
> and the picture is fine.
> 
> I think the above suggests that the driver is not properly updating all the 
> registers based on the
> new mode and link. I tried adding cdns_mhdp_validate_mode_params() call to
> cdns_mhdp_atomic_enable(), so that tu-size etc will be calculated, but that 
> did not fix the problem.

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 01/16] drm/encoder: remove obsolete documentation of bridge

2020-09-03 Thread Laurent Pinchart
Hi Michael,

Thank you for the patch.

On Thu, Sep 03, 2020 at 06:57:02PM +0200, Michael Tretter wrote:
> In commit 05193dc38197 ("drm/bridge: Make the bridge chain a
> double-linked list") the bridge has been removed and replaced by a
> private field. Remove the leftover documentation of the removed field.
> 
> Signed-off-by: Michael Tretter 

Reviewed-by: Laurent Pinchart 

> ---
>  include/drm/drm_encoder.h | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/include/drm/drm_encoder.h b/include/drm/drm_encoder.h
> index a60f5f1555ac..5dfa5f7a80a7 100644
> --- a/include/drm/drm_encoder.h
> +++ b/include/drm/drm_encoder.h
> @@ -89,7 +89,6 @@ struct drm_encoder_funcs {
>   * @head: list management
>   * @base: base KMS object
>   * @name: human readable name, can be overwritten by the driver
> - * @bridge: bridge associated to the encoder
>   * @funcs: control functions
>   * @helper_private: mid-layer private data
>   *

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v4 04/15] drm/bridge: tc358764: add drm_panel_bridge support

2020-09-03 Thread Laurent Pinchart
Hi Andrzej,

On Thu, Sep 03, 2020 at 11:40:58AM +0200, Andrzej Hajda wrote:
> On 26.07.2020 22:33, Sam Ravnborg wrote:
> > Prepare the tc358764 bridge driver for use in a chained setup by
> > replacing direct use of drm_panel with drm_panel_bridge support.
> >
> > The bridge panel will use the connector type reported by the panel,
> > where the connector for this driver hardcodes DRM_MODE_CONNECTOR_LVDS.
> >
> > The tc358764 did not any additional info the the connector so the
> > connector creation is passed to the bridge panel driver.
> >
> > v3:
> >- Merge with patch to make connector creation optional to avoid
> >  creating two connectors (Laurent)
> >- Pass connector creation to bridge panel, as this bridge driver
> >  did not add any extra info to the connector.
> >- Set bridge.type to DRM_MODE_CONNECTOR_LVDS.
> >
> > v2:
> >- Use PTR_ERR_OR_ZERO() (kbuild test robot)
> >
> > Signed-off-by: Sam Ravnborg 
> > Cc: Laurent Pinchart 
> > Cc: kbuild test robot 
> > Cc: Andrzej Hajda 
> > Cc: Neil Armstrong 
> > Cc: Jonas Karlman 
> > Cc: Jernej Skrabec 
> > ---
> >   drivers/gpu/drm/bridge/tc358764.c | 107 +-
> >   1 file changed, 16 insertions(+), 91 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/tc358764.c 
> > b/drivers/gpu/drm/bridge/tc358764.c
> > index a277739fab58..fdde4cfdc724 100644
> > --- a/drivers/gpu/drm/bridge/tc358764.c
> > +++ b/drivers/gpu/drm/bridge/tc358764.c
> > @@ -153,10 +153,9 @@ static const char * const tc358764_supplies[] = {
> >   struct tc358764 {
> > struct device *dev;
> > struct drm_bridge bridge;
> > -   struct drm_connector connector;
> > struct regulator_bulk_data supplies[ARRAY_SIZE(tc358764_supplies)];
> > struct gpio_desc *gpio_reset;
> > -   struct drm_panel *panel;
> > +   struct drm_bridge *panel_bridge;
> > int error;
> >   };
> >   
> > @@ -210,12 +209,6 @@ static inline struct tc358764 
> > *bridge_to_tc358764(struct drm_bridge *bridge)
> > return container_of(bridge, struct tc358764, bridge);
> >   }
> >   
> > -static inline
> > -struct tc358764 *connector_to_tc358764(struct drm_connector *connector)
> > -{
> > -   return container_of(connector, struct tc358764, connector);
> > -}
> > -
> >   static int tc358764_init(struct tc358764 *ctx)
> >   {
> > u32 v = 0;
> > @@ -278,43 +271,11 @@ static void tc358764_reset(struct tc358764 *ctx)
> > usleep_range(1000, 2000);
> >   }
> >   
> > -static int tc358764_get_modes(struct drm_connector *connector)
> > -{
> > -   struct tc358764 *ctx = connector_to_tc358764(connector);
> > -
> > -   return drm_panel_get_modes(ctx->panel, connector);
> > -}
> > -
> > -static const
> > -struct drm_connector_helper_funcs tc358764_connector_helper_funcs = {
> > -   .get_modes = tc358764_get_modes,
> > -};
> > -
> > -static const struct drm_connector_funcs tc358764_connector_funcs = {
> > -   .fill_modes = drm_helper_probe_single_connector_modes,
> > -   .destroy = drm_connector_cleanup,
> > -   .reset = drm_atomic_helper_connector_reset,
> > -   .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
> > -   .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
> > -};
> > -
> > -static void tc358764_disable(struct drm_bridge *bridge)
> > -{
> > -   struct tc358764 *ctx = bridge_to_tc358764(bridge);
> > -   int ret = drm_panel_disable(bridge_to_tc358764(bridge)->panel);
> > -
> > -   if (ret < 0)
> > -   dev_err(ctx->dev, "error disabling panel (%d)\n", ret);
> > -}
> > -
> >   static void tc358764_post_disable(struct drm_bridge *bridge)
> >   {
> > struct tc358764 *ctx = bridge_to_tc358764(bridge);
> > int ret;
> >   
> > -   ret = drm_panel_unprepare(ctx->panel);
> > -   if (ret < 0)
> > -   dev_err(ctx->dev, "error unpreparing panel (%d)\n", ret);
> 
> 
> Using this bridge_panel thing you reverse order of hw 
> initialization/de-initialization, this is incorrect.
> 
> For example:
> 
> - panel_unprepare should be called before tc35* turn off,
> 
> - panel_prepare should be called after tc35* on.
> 
> This is why I avoid the whole "bridge chaining" - it enforces ridiculous 
> order of initialization.
> 
> 
> > tc358764_reset(ctx);
> > usleep_range(1, 15000)

Re: [PATCH v2 1/4] drm/of: Change the prototype of drm_of_lvds_get_dual_link_pixel_order

2020-09-01 Thread Laurent Pinchart
Hi Maxime,

On Tue, Sep 01, 2020 at 03:23:40PM +0200, Maxime Ripard wrote:
> On Mon, Aug 31, 2020 at 11:28:52PM +0300, Laurent Pinchart wrote:
> > On Thu, Jul 30, 2020 at 11:35:01AM +0200, Maxime Ripard wrote:
> > > The drm_of_lvds_get_dual_link_pixel_order() function took so far the
> > > device_node of the two ports used together to make up a dual-link LVDS
> > > output.
> > > 
> > > This assumes that a binding would use an entire port for the LVDS output.
> > > However, some bindings have used endpoints instead and thus we need to
> > > operate at the endpoint level. Change slightly the arguments to allow 
> > > that.
> > 
> > Is this still needed ? Unless I'm mistaken, the Allwinner platform now
> > uses two TCON instances for the two links, so there are two ports.
> 
> Yes, and no.
> 
> The two TCONs indeed have each a port of their own, so we do have two
> ports indeed. However, what we don't have is a port entirely dedicated
> to the LVDS output.
> 
> Our binding uses a single port for all its output (RGB, LVDS or TV/HDMI
> controllers) with different endpoints.

Good point. Then let's keep this patch :-) We can't fix existing
bindings, but for the future, let's model separate display outputs as
ports, not endpoints.

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 1/3] dt-bindings: display: bridge: lvds-codec: Document vcc-supply property

2020-09-01 Thread Laurent Pinchart
Hi Rob,

On Mon, Aug 24, 2020 at 05:04:58PM -0600, Rob Herring wrote:
> On Mon, Aug 10, 2020 at 04:22:17PM +0100, Biju Das wrote:
> > Document optional vcc-supply property that may be used as VCC source.
> > 
> > Signed-off-by: Biju Das 
> > ---
> > New patch Ref: Ref:https://patchwork.kernel.org/patch/11705819/
> > ---
> >  .../devicetree/bindings/display/bridge/lvds-codec.yaml | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git 
> > a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml 
> > b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
> > index 68951d56ebba..3248be31eceb 100644
> > --- a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
> > +++ b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
> > @@ -79,6 +79,9 @@ properties:
> >The GPIO used to control the power down line of this device.
> >  maxItems: 1
> >  
> > +  vcc-supply:
> > +maxItems: 1
> 
> Probably should be 'power-supply' to align with the 'simple' panels. 
> That's also to signify there's only 1 supply. Using 'vcc' would 
> encourage adding 'vdd-supply', 'vddio-supply', etc. A second supply I'll 
> NAK because at that point it's not a simple bridge with no configuration 
> (it's arguably already there).

Fully agreed.

Do I get your Ab or Rb line with s/vcc/power/ and the commit message
updated to

dt-bindings: display: bridge: lvds-codec: Document power-supply property

    Document optional power-supply property that may be used to specify the
regulator powering up the device.

?

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 1/3] dt-bindings: display: bridge: lvds-codec: Document vcc-supply property

2020-09-01 Thread Laurent Pinchart
Hello,

On Wed, Aug 26, 2020 at 06:58:50AM +, Biju Das wrote:
> > Subject: Re: [PATCH v2 1/3] dt-bindings: display: bridge: lvds-codec:
> > Document vcc-supply property
> >
> > On Mon, Aug 10, 2020 at 04:22:17PM +0100, Biju Das wrote:
> > > Document optional vcc-supply property that may be used as VCC source.
> > >
> > > Signed-off-by: Biju Das 
> > > ---
> > > New patch Ref: Ref:https://patchwork.kernel.org/patch/11705819/
> > > ---
> > >  .../devicetree/bindings/display/bridge/lvds-codec.yaml | 3 +++
> > >  1 file changed, 3 insertions(+)
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
> > > b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
> > > index 68951d56ebba..3248be31eceb 100644
> > > --- a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
> > > +++ b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
> > > @@ -79,6 +79,9 @@ properties:
> > >The GPIO used to control the power down line of this device.
> > >  maxItems: 1
> > >
> > > +  vcc-supply:
> > > +maxItems: 1
> >
> > Probably should be 'power-supply' to align with the 'simple' panels.
> > That's also to signify there's only 1 supply. Using 'vcc' would encourage
> > adding 'vdd-supply', 'vddio-supply', etc. A second supply I'll NAK because 
> > at
> > that point it's not a simple bridge with no configuration (it's arguably 
> > already
> > there).
> 
> Yes, I am ok with 'power-supply', since LVDS CODEC driver is  generic
> and also to align with terminology used in generic 'simple' panels.
> 
> In our case this Receiver converts LVDS signals to RGB signals and fed
> this signal to simple panel.
> On the receiver part, We need to supply  power to TTL output,  PLL and
> LVDS input. It all derived from the single power source.
> 
> Laurent, Please share you opinion on this.

Acked-by: Laurent Pinchart 

That is, I think it's a good idea to rename it, and I agree with Rob
about not adding a second supply.

I've applied the modified patch to my tree, and will send a pull request
this week.

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 3/4] drm/sun4i: tcon: Support the LVDS Dual-Link on the A20

2020-08-31 Thread Laurent Pinchart
Hi Maxime,

Thank you for the patch.

On Thu, Jul 30, 2020 at 11:35:03AM +0200, Maxime Ripard wrote:
> The A20 can use its second TCON as the secondary LVDS link in a dual-link
> setup, with the TCON0 being the main link. Extend a bit the parsing code to
> leverage the DRM dual-link code, register only the LVDS output on the
> primary TCON, and add the needed bits to setup the TCON properly.
> 
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/gpu/drm/sun4i/sun4i_tcon.c | 36 +++-
>  drivers/gpu/drm/sun4i/sun4i_tcon.h |  4 +++-
>  2 files changed, 40 insertions(+)
> 
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
> b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index d03ad75f9900..ed2abf6eb18b 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -487,6 +487,9 @@ static void sun4i_tcon0_mode_set_lvds(struct sun4i_tcon 
> *tcon,
>   else
>   reg |= SUN4I_TCON0_LVDS_IF_DATA_POL_NORMAL;
>  
> + if (tcon->lvds_dual_link)
> + reg |= SUN4I_TCON0_LVDS_IF_DUAL_LINK;
> +
>   if (sun4i_tcon_get_pixel_depth(encoder) == 24)
>   reg |= SUN4I_TCON0_LVDS_IF_BITWIDTH_24BITS;
>   else
> @@ -896,6 +899,16 @@ static int sun4i_tcon_register_panel(struct drm_device 
> *drm,
>   return sun4i_rgb_init(drm, tcon);
>  
>   /*
> +  * Only the TCON0 will be relevant for the LVDS output, so if
> +  * our ID is something else, let's prevent our TCON from
> +  * registering its own LVDS output
> +  */
> + if (tcon->id) {
> + dev_info(dev, "Secondary TCON, disabling panel output");

This may worry the user unnecessarily. I'd make it a debug message, or
drop it completely, and like reword it a bit as pointed out by Chen-Yu.

> + return 0;
> + }
> +
> + /*
>* This can only be made optional since we've had DT
>* nodes without the LVDS reset properties.
>*
> @@ -941,6 +954,28 @@ static int sun4i_tcon_register_panel(struct drm_device 
> *drm,
>   return -ENODEV;
>   }
>  
> + /*
> +  * If we don't have a second TCON, we will never be able to do
> +  * dual-link LVDS, so we don't have much more to do.
> +  */
> + companion = of_parse_phandle(dev->of_node, "allwinner,lvds-companion", 
> 0);

Should there be a patch to add this property to the DT bindings ?

> + if (!companion)
> + return 0;
> +
> + /*
> +  * Let's do a sanity check on the dual-link setup to make sure
> +  * everything is properly described.
> +  */
> + ret = drm_of_lvds_get_dual_link_pixel_order(dev->of_node, 1, 0,
> + companion, 1, 0);
> + if (ret < 0) {
> + dev_err(dev, "Invalid Dual-Link Configuration.\n");
> + return ret;
> + }
> +
> + dev_info(dev, "Primary TCON, enabling LVDS Dual-Link");
> + tcon->lvds_dual_link = true;
> +
>   return sun4i_lvds_init(drm, tcon);
>  }
>  
> @@ -1500,6 +1535,7 @@ static const struct sun4i_tcon_quirks 
> sun7i_a20_tcon0_quirks = {
>  };
>  
>  static const struct sun4i_tcon_quirks sun7i_a20_quirks = {
> + .supports_lvds  = true,

Should this be split to a separate patch, or at least mentioned in the
commit message ?

>   .has_channel_0  = true,
>   .has_channel_1  = true,
>   .dclk_min_div   = 4,
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h 
> b/drivers/gpu/drm/sun4i/sun4i_tcon.h
> index cfbf4e6c1679..51c4e09cdd13 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
> @@ -98,6 +98,7 @@
>  
>  #define SUN4I_TCON0_LVDS_IF_REG  0x84
>  #define SUN4I_TCON0_LVDS_IF_EN   BIT(31)
> +#define SUN4I_TCON0_LVDS_IF_DUAL_LINKBIT(30)
>  #define SUN4I_TCON0_LVDS_IF_BITWIDTH_MASKBIT(26)
>  #define SUN4I_TCON0_LVDS_IF_BITWIDTH_18BITS  (1 << 26)
>  #define SUN4I_TCON0_LVDS_IF_BITWIDTH_24BITS      (0 << 26)
> @@ -274,6 +275,9 @@ struct sun4i_tcon {
>   /* Associated crtc */
>   struct sun4i_crtc   *crtc;
>  
> + /* Is the LVDS link a dual-channel link? */
> + boollvds_dual_link;
> +
>   int id;
>  
>   /* TCON list management */

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 2/4] drm/sun4i: tcon: Refactor the LVDS and panel probing

2020-08-31 Thread Laurent Pinchart
Hi Maxime,

Thank you for the patch.

On Thu, Jul 30, 2020 at 11:35:02AM +0200, Maxime Ripard wrote:
> The current code to parse the DT, deal with the older device trees, and
> register either the RGB or LVDS output has so far grown organically into
> the bind function and has become quite hard to extend properly.
> 
> Let's move it into a single function that grabs all the resources it needs
> and registers the proper panel output.
> 
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/gpu/drm/sun4i/sun4i_tcon.c | 139 +++---
>  1 file changed, 70 insertions(+), 69 deletions(-)
> 
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
> b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index 2a5a9903c4c6..d03ad75f9900 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -875,6 +875,75 @@ static int sun4i_tcon_init_regmap(struct device *dev,
>   return 0;
>  }
>  
> +static int sun4i_tcon_register_panel(struct drm_device *drm,
> +  struct sun4i_tcon *tcon)
> +{
> + struct device_node *companion;
> + struct device_node *remote;
> + struct device *dev = tcon->dev;
> + bool has_lvds_alt;
> + bool has_lvds_rst;
> + int ret;
> +
> + /*
> +  * If we have an LVDS panel connected to the TCON, we should
> +  * just probe the LVDS connector. Otherwise, let's just register
> +  * an RGB panel.
> +  */
> + remote = of_graph_get_remote_node(dev->of_node, 1, 0);
> + if (!tcon->quirks->supports_lvds ||
> + !of_device_is_compatible(remote, "panel-lvds"))

This isn't very nice :-S Not a candidate for a fix in this patch, but
something that should be addressed in the future. As Chen-Yu mentioned,
there are LVDS panels supported by the panel-simple driver.

> + return sun4i_rgb_init(drm, tcon);
> +
> + /*
> +  * This can only be made optional since we've had DT
> +  * nodes without the LVDS reset properties.
> +  *
> +  * If the property is missing, just disable LVDS, and
> +  * print a warning.
> +  */
> + tcon->lvds_rst = devm_reset_control_get_optional(dev, "lvds");
> + if (IS_ERR(tcon->lvds_rst)) {
> + dev_err(dev, "Couldn't get our reset line\n");
> + return PTR_ERR(tcon->lvds_rst);
> + } else if (tcon->lvds_rst) {
> + has_lvds_rst = true;
> + reset_control_reset(tcon->lvds_rst);
> + } else {
> + has_lvds_rst = false;
> + }
> +
> + /*
> +  * This can only be made optional since we've had DT
> +  * nodes without the LVDS reset properties.

Shouldn't this mention clock, not reset ?

> +  *
> +  * If the property is missing, just disable LVDS, and
> +  * print a warning.
> +  */
> + if (tcon->quirks->has_lvds_alt) {
> + tcon->lvds_pll = devm_clk_get(dev, "lvds-alt");
> + if (IS_ERR(tcon->lvds_pll)) {
> + if (PTR_ERR(tcon->lvds_pll) == -ENOENT) {
> + has_lvds_alt = false;
> + } else {
> + dev_err(dev, "Couldn't get the LVDS PLL\n");
> + return PTR_ERR(tcon->lvds_pll);
> + }
> + } else {
> + has_lvds_alt = true;
> + }
> + }
> +
> + if (!has_lvds_rst ||
> + (tcon->quirks->has_lvds_alt && !has_lvds_alt)) {
> + dev_warn(dev, "Missing LVDS properties, Please upgrade your 
> DT\n");
> + dev_warn(dev, "LVDS output disabled\n");

Would it make sense to move this to the has_lvds_rst = false and
has_lvds_alt = false code sections about ? You could then print which
property is missing.

Reviewed-by: Laurent Pinchart 

> + return -ENODEV;
> + }
> +
> + return sun4i_lvds_init(drm, tcon);
> +}
> +
>  /*
>   * On SoCs with the old display pipeline design (Display Engine 1.0),
>   * the TCON is always tied to just one backend. Hence we can traverse
> @@ -1122,10 +1191,8 @@ static int sun4i_tcon_bind(struct device *dev, struct 
> device *master,
>   struct drm_device *drm = data;
>   struct sun4i_drv *drv = drm->dev_private;
>   struct sunxi_engine *engine;
> - struct device_node *remote;
>   struct sun4i_tcon *tcon;
>   struct reset_control *edp_rstc;
> - bool has_lvds_rst, has_lvds_alt, can_lvds;
>   int ret;
>  
>   engine = sun4i_tcon_find_engine(drv, dev->of_node);
&

Re: [PATCH v2 1/4] drm/of: Change the prototype of drm_of_lvds_get_dual_link_pixel_order

2020-08-31 Thread Laurent Pinchart
2 @@ static inline int drm_of_find_panel_or_bridge(const struct 
> device_node *np,
>  }
>  
>  static inline int
> -drm_of_lvds_get_dual_link_pixel_order(const struct device_node *port1,
> -   const struct device_node *port2)
> +drm_of_lvds_get_dual_link_pixel_order(const struct device_node *dev1,
> +   int port1_id,
> +   int endpoint1_id,
> +   const struct device_node *dev2,
> +   int port2_id,
> +   int endpoint2_id)
>  {
>   return -EINVAL;
>  }

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v9 2/3] drm: bridge: Add support for Cadence MHDP8546 DPI/DP bridge

2020-08-31 Thread Laurent Pinchart
Hi Swapnil,

Thank you for the patch.

On Mon, Aug 31, 2020 at 10:23:34AM +0200, Swapnil Jakhade wrote:
> Add a new DRM bridge driver for Cadence MHDP8546 DPTX IP used in TI J721E
> SoC. MHDP DPTX IP is the component that complies with VESA DisplayPort (DP)
> and embedded Display Port (eDP) standards. It integrates uCPU running the
> embedded Firmware (FW) interfaced over APB interface.
> 
> Basically, it takes a DPI stream as input and outputs it encoded in DP
> format. Currently, it supports only SST mode.
> 
> Co-developed-by: Tomi Valkeinen 
> Signed-off-by: Tomi Valkeinen 
> Co-developed-by: Jyri Sarha 
> Signed-off-by: Jyri Sarha 
> Signed-off-by: Quentin Schulz 
> Signed-off-by: Yuti Amonkar 
> Signed-off-by: Swapnil Jakhade 
> ---
>  drivers/gpu/drm/bridge/Kconfig|2 +
>  drivers/gpu/drm/bridge/Makefile   |1 +
>  drivers/gpu/drm/bridge/cadence/Kconfig|   11 +
>  drivers/gpu/drm/bridge/cadence/Makefile   |3 +
>  .../drm/bridge/cadence/cdns-mhdp8546-core.c   | 2548 +
>  .../drm/bridge/cadence/cdns-mhdp8546-core.h   |  402 +++
>  6 files changed, 2967 insertions(+)
>  create mode 100644 drivers/gpu/drm/bridge/cadence/Kconfig
>  create mode 100644 drivers/gpu/drm/bridge/cadence/Makefile
>  create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
>  create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.h
> 
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 3e11af4e9f63..ef91646441b1 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -241,6 +241,8 @@ source "drivers/gpu/drm/bridge/analogix/Kconfig"
>  
>  source "drivers/gpu/drm/bridge/adv7511/Kconfig"
>  
> +source "drivers/gpu/drm/bridge/cadence/Kconfig"
> +
>  source "drivers/gpu/drm/bridge/synopsys/Kconfig"
>  
>  endmenu
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index c589a6a7cbe1..2b3aff104e46 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -25,4 +25,5 @@ obj-$(CONFIG_DRM_TI_TPD12S015) += ti-tpd12s015.o
>  obj-$(CONFIG_DRM_NWL_MIPI_DSI) += nwl-dsi.o
>  
>  obj-y += analogix/
> +obj-y += cadence/
>  obj-y += synopsys/
> diff --git a/drivers/gpu/drm/bridge/cadence/Kconfig 
> b/drivers/gpu/drm/bridge/cadence/Kconfig
> new file mode 100644
> index ..f49d77eb7814
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/cadence/Kconfig
> @@ -0,0 +1,11 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +config DRM_CDNS_MHDP8546
> + tristate "Cadence DPI/DP bridge"
> + select DRM_KMS_HELPER
> + select DRM_PANEL_BRIDGE
> + depends on OF
> + help
> +   Support Cadence DPI to DP bridge. This is an internal
> +   bridge and is meant to be directly embedded in a SoC.
> +   It takes a DPI stream as input and outputs it encoded
> +   in DP format.
> diff --git a/drivers/gpu/drm/bridge/cadence/Makefile 
> b/drivers/gpu/drm/bridge/cadence/Makefile
> new file mode 100644
> index ..676739cdf5e6
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/cadence/Makefile
> @@ -0,0 +1,3 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +obj-$(CONFIG_DRM_CDNS_MHDP8546) += cdns-mhdp8546.o
> +cdns-mhdp8546-y := cdns-mhdp8546-core.o
> diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c 
> b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> new file mode 100644
> index ..14be6f370d6e
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> @@ -0,0 +1,2548 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Cadence MHDP8546 DP bridge driver.
> + *
> + * Copyright (C) 2020 Cadence Design Systems, Inc.
> + *
> + * Authors: Quentin Schulz 
> + *  Swapnil Jakhade 
> + *  Yuti Amonkar 
> + *  Tomi Valkeinen 
> + *  Jyri Sarha 
> + *
> + * TODO:
> + * - Implement optimized mailbox communication using mailbox interrupts
> + * - Add support for power management
> + * - Add support for features like audio, MST and fast link training
> + * - Implement request_fw_cancel to handle HW_STATE
> + * - Fix asynchronous loading of firmware implementation
> + * - Add DRM helper function for cdns_mhdp_lower_link_rate
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#include "cdns-mhdp8546-core.h"
> +
> +static int cdns_mhdp_mailbox_read(struct cdns_mhdp_device *mhdp)
> +{
> + int ret, empty;
> +
> + WARN_ON(!mutex_is_locked(>mbox_mutex));
> +
> + ret = readx_poll_timeout(readl, mhdp->regs + CDNS_MAILBOX_EMPTY,
> +  empty, !empty, MAILBOX_RETRY_US,
> +  

Re: [RFC] Experimental DMA-BUF Device Heaps

2020-08-31 Thread Laurent Pinchart
Hi James,

On Sun, Aug 23, 2020 at 03:53:50PM -0700, James Jones wrote:
> On 8/23/20 1:46 PM, Laurent Pinchart wrote:
> > On Sun, Aug 23, 2020 at 01:04:43PM -0700, James Jones wrote:
> >> On 8/20/20 1:15 AM, Ezequiel Garcia wrote:
> >>> On Mon, 2020-08-17 at 20:49 -0700, James Jones wrote:
> >>>> On 8/17/20 8:18 AM, Brian Starkey wrote:
> >>>>> On Sun, Aug 16, 2020 at 02:22:46PM -0300, Ezequiel Garcia wrote:
> >>>>>> This heap is basically a wrapper around DMA-API dma_alloc_attrs,
> >>>>>> which will allocate memory suitable for the given device.
> >>>>>>
> >>>>>> The implementation is mostly a port of the Contiguous Videobuf2
> >>>>>> memory allocator (see videobuf2/videobuf2-dma-contig.c)
> >>>>>> over to the DMA-BUF Heap interface.
> >>>>>>
> >>>>>> The intention of this allocator is to provide applications
> >>>>>> with a more system-agnostic API: the only thing the application
> >>>>>> needs to know is which device to get the buffer for.
> >>>>>>
> >>>>>> Whether the buffer is backed by CMA, IOMMU or a DMA Pool
> >>>>>> is unknown to the application.
> >>>>>>
> >>>>>> I'm not really expecting this patch to be correct or even
> >>>>>> a good idea, but just submitting it to start a discussion on DMA-BUF
> >>>>>> heap discovery and negotiation.
> >>>>>>
> >>>>>
> >>>>> My initial reaction is that I thought dmabuf heaps are meant for use
> >>>>> to allocate buffers for sharing across devices, which doesn't fit very
> >>>>> well with having per-device heaps.
> >>>>>
> >>>>> For single-device allocations, would using the buffer allocation
> >>>>> functionality of that device's native API be better in most
> >>>>> cases? (Some other possibly relevant discussion at [1])
> >>>>>
> >>>>> I can see that this can save some boilerplate for devices that want
> >>>>> to expose private chunks of memory, but might it also lead to 100
> >>>>> aliases for the system's generic coherent memory pool?
> >>>>>
> >>>>> I wonder if a set of helpers to allow devices to expose whatever they
> >>>>> want with minimal effort would be better.
> >>>>
> >>>> I'm rather interested on where this goes, as I was toying with using
> >>>> some sort of heap ID as a basis for a "device-local" constraint in the
> >>>> memory constraints proposals Simon and I will be discussing at XDC this
> >>>> year.  It would be rather elegant if there was one type of heap ID used
> >>>> universally throughout the kernel that could provide a unique handle for
> >>>> the shared system memory heap(s), as well as accelerator-local heaps on
> >>>> fancy NICs, GPUs, NN accelerators, capture devices, etc. so apps could
> >>>> negotiate a location among themselves.  This patch seems to be a step
> >>>> towards that in a way, but I agree it would be counterproductive if a
> >>>> bunch of devices that were using the same underlying system memory ended
> >>>> up each getting their own heap ID just because they used some SW
> >>>> framework that worked that way.
> >>>>
> >>>> Would appreciate it if you could send along a pointer to your BoF if it
> >>>> happens!
> >>>
> >>> Here is it:
> >>>
> >>> https://linuxplumbersconf.org/event/7/contributions/818/
> >>>
> >>> It would be great to see you there and discuss this,
> >>> given I was hoping we could talk about how to meet a
> >>> userspace allocator library expectations as well.
> >>
> >> Thanks!  I hadn't registered for LPC and it looks like it's sold out,
> >> but I'll try to watch the live stream.
> >>
> >> This is very interesting, in that it looks like we're both trying to
> >> solve roughly the same set of problems but approaching it from different
> >> angles.  From what I gather, your approach is that a "heap" encompasses
> >> all the allocation constraints a device may have.
> >>
> >> The approach Simon Ser and I are tossing around so far is somewhat
> >> differe

Re: 答复: [PATCH v2 6/6] drm/panel: Add Ilitek ILI9341 DBI panel driver

2020-08-30 Thread Laurent Pinchart
Hi Paul,

On Sun, Aug 30, 2020 at 06:48:12PM +0200, Paul Cercueil wrote:
> Le dim. 30 août 2020 à 16:36, 何小龙 (Leon He) a écrit :
> >>  +struct ili9341 {
> >>  +   struct drm_panel panel;
> >>  +   struct mipi_dsi_device *dsi;
> >>  +   const struct ili9341_pdata *pdata;
> >>  +
> >>  +   struct gpio_desc*reset_gpiod;
> >>  +   u32 rotation;
> >>  +};
> >>  +
> > 
> > Hi Paul, you put the mipi_dsi_device inside the struct. I think it 
> > maybe not
> > a good idea. That means the panel has a MIPI-DSI interface but it 
> > doesn't
> > have actually.
> > 
> >>  +static int ili9341_probe(struct mipi_dsi_device *dsi)
> >>  +{
> >>  +   struct device *dev = >dev;
> >>  +   struct ili9341 *priv;
> >>  +   int ret;
> >>  +
> >>  +   /* See comment for mipi_dbi_spi_init() */
> >>  +   if (!dev->coherent_dma_mask) {
> >>  +   ret = dma_coerce_mask_and_coherent(dev, 
> >> DMA_BIT_MASK(32));
> >>  +   if (ret) {
> >>  +   dev_warn(dev, "Failed to set dma mask 
> >> %d\n", ret);
> >>  +   return ret;
> >>  +   }
> >>  +   }
> >>  +
> >>  +   priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> >>  +   if (!priv)
> >>  +   return -ENOMEM;
> >>  +
> >>  +   mipi_dsi_set_drvdata(dsi, priv);
> >>  +   priv->dsi = dsi;
> >>  +
> >>  +   device_property_read_u32(dev, "rotation", >rotation);
> >>  +
> >>  +   priv->pdata = device_get_match_data(dev);
> >>  +   if (!priv->pdata)
> >>  +   return -EINVAL;
> >>  +
> >>  +   drm_panel_init(>panel, dev, _funcs,
> >>  +  DRM_MODE_CONNECTOR_DPI);
> >>  +
> >>  +   priv->reset_gpiod = devm_gpiod_get(dev, "reset", 
> >> GPIOD_OUT_HIGH);
> >>  +   if (IS_ERR(priv->reset_gpiod)) {
> >>  +   dev_err(dev, "Couldn't get our reset GPIO\n");
> >>  +   return PTR_ERR(priv->reset_gpiod);
> >>  +   }
> >>  +
> >>  +   ret = drm_panel_of_backlight(>panel);
> >>  +   if (ret < 0) {
> >>  +   if (ret != -EPROBE_DEFER)
> >>  +   dev_err(dev, "Failed to get backlight 
> >> handle\n");
> >>  +   return ret;
> >>  +   }
> >>  +
> >>  +   drm_panel_add(>panel);
> >>  +
> >>  +   dsi->bus_type = priv->pdata->bus_type;
> >>  +   dsi->lanes = priv->pdata->lanes;
> >>  +   dsi->format = MIPI_DSI_FMT_RGB565;
> >>  +
> >>  +   ret = mipi_dsi_attach(dsi);
> >>  +   if (ret) {
> >>  +   dev_err(dev, "Failed to attach DSI panel\n");
> >>  +   goto err_panel_remove;
> >>  +   }
> >>  +
> >>  +   ret = mipi_dsi_maybe_register_tiny_driver(dsi);
> >>  +   if (ret) {
> >>  +   dev_err(dev, "Failed to init TinyDRM driver\n");
> >>  +   goto err_mipi_dsi_detach;
> >>  +   }
> >>  +
> >>  +   return 0;
> >>  +
> >>  +err_mipi_dsi_detach:
> >>  +   mipi_dsi_detach(dsi);
> >>  +err_panel_remove:
> >>  +   drm_panel_remove(>panel);
> >>  +   return ret;
> >>  +}
> >>  +
> >>  +static int ili9341_remove(struct mipi_dsi_device *dsi)
> >>  +{
> >>  +   struct ili9341 *priv = mipi_dsi_get_drvdata(dsi);
> >>  +
> >>  +   mipi_dsi_detach(dsi);
> >>  +   drm_panel_remove(>panel);
> >>  +
> >>  +   drm_panel_disable(>panel);
> >>  +   drm_panel_unprepare(>panel);
> >>  +
> >>  +   return 0;
> >>  +}
> >>  +
> >>  +static const struct ili9341_pdata yx240qv29_pdata = {
> >>  +   .mode = { DRM_SIMPLE_MODE(240, 320, 37, 49) },
> >>  +   .width_mm = 0, // TODO
> >>  +   .height_mm = 0, // TODO
> >>  +   .bus_type = MIPI_DCS_BUS_TYPE_DBI_SPI_C3,
> >>  +   .lanes = 1,
> >>  +};
> >>  +
> >>  +static const struct of_device_id ili9341_of_match[] = {
> >>  +   { .compa

Re: [PATCH v1 2/2] drm: bridge: add support for lontium LT9611UXC bridge

2020-08-28 Thread Laurent Pinchart
On Fri, Aug 28, 2020 at 05:33:00PM +0300, Laurent Pinchart wrote:
> On Fri, Aug 28, 2020 at 07:48:48PM +0530, Vinod Koul wrote:
> > On 28-08-20, 15:04, Dmitry Baryshkov wrote:
> > 
> > > +#define EDID_BLOCK_SIZE  128
> > > +#define EDID_NUM_BLOCKS 2
> > 
> > tab or space either one, not both ;)
> > 
> > > +static struct mipi_dsi_device *lt9611uxc_attach_dsi(struct lt9611uxc 
> > > *lt9611uxc,
> > > +  struct device_node *dsi_node)
> > 
> > Please align this with open parenthesis of preceding line (checkpatch
> > with --strict option will check this)
> > 
> > > +static int lt9611uxc_bridge_attach(struct drm_bridge *bridge,
> > > + enum drm_bridge_attach_flags flags)
> > > +{
> > > + struct lt9611uxc *lt9611uxc = bridge_to_lt9611uxc(bridge);
> > > + int ret;
> > > +
> > > + if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)) {
> > > + dev_err(lt9611uxc->dev, "Fix bridge driver to make connector 
> > > optional!");
> > 
> > Can we support both modes as I have done in lt9611, that way once the
> > conversion is done we can drop the init part and support conversion.
> 
> I was going to mention that :-) New drivers should support the
> DRM_BRIDGE_ATTACH_NO_CONNECTOR flag.

Please ignore this comment, I just realized that the driver supports
DRM_BRIDGE_ATTACH_NO_CONNECTOR, it's the !DRM_BRIDGE_ATTACH_NO_CONNECTOR
case that is not supported, and that's totally fine.

> > I have patch for msm driver to set DRM_BRIDGE_ATTACH_NO_CONNECTOR, you
> > can use that to test
> > 
> > > +static int lt9611uxc_hdmi_hw_params(struct device *dev, void *data,
> > > +  struct hdmi_codec_daifmt *fmt,
> > > +      struct hdmi_codec_params *hparms)
> > > +{
> > > + /*
> > > +  * LT9611UXC will automatically detect rate and sample size, so no need
> > > +  * to setup anything here.
> > > +  */
> > > + return 0;
> > > +}
> > 
> > Do we need dummy function?

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v1 2/2] drm: bridge: add support for lontium LT9611UXC bridge

2020-08-28 Thread Laurent Pinchart
On Fri, Aug 28, 2020 at 07:48:48PM +0530, Vinod Koul wrote:
> On 28-08-20, 15:04, Dmitry Baryshkov wrote:
> 
> > +#define EDID_BLOCK_SIZE128
> > +#define EDID_NUM_BLOCKS 2
> 
> tab or space either one, not both ;)
> 
> > +static struct mipi_dsi_device *lt9611uxc_attach_dsi(struct lt9611uxc 
> > *lt9611uxc,
> > +struct device_node *dsi_node)
> 
> Please align this with open parenthesis of preceding line (checkpatch
> with --strict option will check this)
> 
> > +static int lt9611uxc_bridge_attach(struct drm_bridge *bridge,
> > +   enum drm_bridge_attach_flags flags)
> > +{
> > +   struct lt9611uxc *lt9611uxc = bridge_to_lt9611uxc(bridge);
> > +   int ret;
> > +
> > +   if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)) {
> > +   dev_err(lt9611uxc->dev, "Fix bridge driver to make connector 
> > optional!");
> 
> Can we support both modes as I have done in lt9611, that way once the
> conversion is done we can drop the init part and support conversion.

I was going to mention that :-) New drivers should support the
DRM_BRIDGE_ATTACH_NO_CONNECTOR flag.

> I have patch for msm driver to set DRM_BRIDGE_ATTACH_NO_CONNECTOR, you
> can use that to test
> 
> > +static int lt9611uxc_hdmi_hw_params(struct device *dev, void *data,
> > +struct hdmi_codec_daifmt *fmt,
> > +struct hdmi_codec_params *hparms)
> > +{
> > +   /*
> > +* LT9611UXC will automatically detect rate and sample size, so no need
> > +* to setup anything here.
> > +*/
> > +   return 0;
> > +}
> 
> Do we need dummy function?

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/tidss: Add prepare_fb to the plane helper funcs

2020-08-26 Thread Laurent Pinchart
Hi Gowtham,

Thank you for the patch.

On Wed, Aug 26, 2020 at 04:44:09PM +0300, Tomi Valkeinen wrote:
> From: Gowtham Tammana 
> 
> drm_gem_fb_prepare_fb() extracts fence and attaches to plane state.
> The fence info is needed if implicit fencing is used. Add this as
> prepare_fb function pointer to plane helper funcs.
> 
> Signed-off-by: Gowtham Tammana 
> Signed-off-by: Tomi Valkeinen 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/tidss/tidss_plane.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/tidss/tidss_plane.c 
> b/drivers/gpu/drm/tidss/tidss_plane.c
> index 43e72d0b2d84..35067ae674ea 100644
> --- a/drivers/gpu/drm/tidss/tidss_plane.c
> +++ b/drivers/gpu/drm/tidss/tidss_plane.c
> @@ -10,6 +10,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "tidss_crtc.h"
>  #include "tidss_dispc.h"
> @@ -150,6 +151,7 @@ static void drm_plane_destroy(struct drm_plane *plane)
>  }
>  
>  static const struct drm_plane_helper_funcs tidss_plane_helper_funcs = {
> + .prepare_fb = drm_gem_fb_prepare_fb,
>   .atomic_check = tidss_plane_atomic_check,
>   .atomic_update = tidss_plane_atomic_update,
>   .atomic_disable = tidss_plane_atomic_disable,

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/bridge: tc358767: fix EDID memory leak

2020-08-26 Thread Laurent Pinchart
Hi Tomi,

Thank you for the patch.

On Wed, Aug 26, 2020 at 04:40:17PM +0300, Tomi Valkeinen wrote:
> The current EDID allocated with drm_get_edid() is freed when the driver
> gets a new EDID, but it is not freed when the driver is removed, causing
> a leak.
> 
> Free the EDID (if any) on driver remove.
> 
> Signed-off-by: Tomi Valkeinen 
> ---
>  drivers/gpu/drm/bridge/tc358767.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/bridge/tc358767.c 
> b/drivers/gpu/drm/bridge/tc358767.c
> index c2777b226c75..dbb18a86beaf 100644
> --- a/drivers/gpu/drm/bridge/tc358767.c
> +++ b/drivers/gpu/drm/bridge/tc358767.c
> @@ -1695,6 +1695,8 @@ static int tc_remove(struct i2c_client *client)
>   drm_bridge_remove(>bridge);
>   drm_dp_aux_unregister(>aux);
>  
> + kfree(tc->edid);
> +

tc->edid is gone in drm-misc-next, problem solved already :-)

>   return 0;
>  }

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 00/49] DRM driver for Hikey 970

2020-08-25 Thread Laurent Pinchart
Hi Mauro,

On Tue, Aug 25, 2020 at 01:30:25PM +0200, Mauro Carvalho Chehab wrote:
> Em Tue, 25 Aug 2020 05:29:29 +1000
> Dave Airlie  escreveu:
> 
> > On Thu, 20 Aug 2020 at 20:02, Laurent Pinchart
> >  wrote:
> > >
> > > Hi Mauro,
> > >
> > > On Thu, Aug 20, 2020 at 09:03:26AM +0200, Mauro Carvalho Chehab wrote:  
> > > > Em Wed, 19 Aug 2020 12:52:06 -0700 John Stultz escreveu:  
> > > > > On Wed, Aug 19, 2020 at 8:31 AM Laurent Pinchart wrote:  
> > > > > > On Wed, Aug 19, 2020 at 05:21:20PM +0200, Sam Ravnborg wrote:  
> > > > > > > On Wed, Aug 19, 2020 at 01:45:28PM +0200, Mauro Carvalho Chehab 
> > > > > > > wrote:  
> > > > > > > > This patch series port the out-of-tree driver for Hikey 970 
> > > > > > > > (which
> > > > > > > > should also support Hikey 960) from the official 96boards tree:
> > > > > > > >
> > > > > > > >https://github.com/96boards-hikey/linux/tree/hikey970-v4.9
> > > > > > > >
> > > > > > > > Based on his history, this driver seems to be originally written
> > > > > > > > for Kernel 4.4, and was later ported to Kernel 4.9. The original
> > > > > > > > driver used to depend on ION (from Kernel 4.4) and had its own
> > > > > > > > implementation for FB dev API.
> > > > > > > >
> > > > > > > > As I need to preserve the original history (with has patches 
> > > > > > > > from
> > > > > > > > both HiSilicon and from Linaro),  I'm starting from the original
> > > > > > > > patch applied there. The remaining patches are incremental,
> > > > > > > > and port this driver to work with upstream Kernel.
> > > > > > > >  
> > > > > ...  
> > > > > > > > - Due to legal reasons, I need to preserve the authorship of
> > > > > > > >   each one responsbile for each patch. So, I need to start from
> > > > > > > >   the original patch from Kernel 4.4;  
> > > > > ...  
> > > > > > > I do acknowledge you need to preserve history and all -
> > > > > > > but this patchset is not easy to review.  
> > > > > >
> > > > > > Why do we need to preserve history ? Adding relevant Signed-off-by 
> > > > > > and
> > > > > > Co-developed-by should be enough, shouldn't it ? Having a public 
> > > > > > branch
> > > > > > that contains the history is useful if anyone is interested, but I 
> > > > > > don't
> > > > > > think it's required in mainline.  
> > > > >
> > > > > Yea. I concur with Laurent here. I'm not sure what legal reasoning you
> > > > > have on this but preserving the "absolute" history here is actively
> > > > > detrimental for review and understanding of the patch set.
> > > > >
> > > > > Preserving Authorship, Signed-off-by lines and adding Co-developed-by
> > > > > lines should be sufficient to provide both atribution credit and DCO
> > > > > history.  
> > > >
> > > > I'm not convinced that, from legal standpoint, folding things would
> > > > be enough. See, there are at least 3 legal systems involved here
> > > > among the different patch authors:
> > > >
> > > >   - civil law;
> > > >   - common law;
> > > >   - customary law + common law.
> > > >
> > > > Merging stuff altogether from different law systems can be problematic,
> > > > and trying to discuss this with experienced IP property lawyers will
> > > > for sure take a lot of time and efforts. I also bet that different
> > > > lawyers will have different opinions, because laws are subject to
> > > > interpretation. With that matter I'm not aware of any court rules
> > > > with regards to folded patches. So, it sounds to me that folding
> > > > patches is something that has yet to be proofed in courts around
> > > > the globe.
> > > >
> > > > At least for US legal system, it sounds that the Country of
> > > > origin of a patch is relevant, as they have a concept of
> > > > "national technology" that can be subject

Re: [PATCH v8 2/3] drm: bridge: Add support for Cadence MHDP DPI/DP bridge

2020-08-23 Thread Laurent Pinchart
Hi Tomi,

On Fri, Aug 14, 2020 at 12:29:35PM +0300, Tomi Valkeinen wrote:
> On 11/08/2020 05:36, Laurent Pinchart wrote:
> 
> >> +static int cdns_mhdp_mailbox_write(struct cdns_mhdp_device *mhdp, u8 val)
> >> +{
> >> +  int ret, full;
> >> +
> >> +  WARN_ON(!mutex_is_locked(>mbox_mutex));
> >> +
> >> +  ret = readx_poll_timeout(readl, mhdp->regs + CDNS_MAILBOX_FULL,
> >> +   full, !full, MAILBOX_RETRY_US,
> >> +   MAILBOX_TIMEOUT_US);
> >> +  if (ret < 0)
> >> +  return ret;
> >> +
> >> +  writel(val, mhdp->regs + CDNS_MAILBOX_TX_DATA);
> >> +
> >> +  return 0;
> >> +}
> > 
> > As commented previously, I think there's room for optimization here. Two
> > options that I think should be investigated are using the mailbox
> > interrupts, and only polling for the first byte of the message
> > (depending on whether the firmware implementation can guarantee that
> > when the first byte is available, the rest of the message will be
> > immediately available too). This can be done on top of this patch
> > though.
> 
> I made some tests on this.
> 
> I cannot see mailbox_write ever looping, mailbox is never full. So in this 
> case the
> readx_poll_timeout() call is there just for safety to catch the cases where 
> something has gone
> totally wrong or perhaps once in a while the mbox can be full for a tiny 
> moment. But we always do
> need to check CDNS_MAILBOX_FULL before each write to CDNS_MAILBOX_TX_DATA, so 
> we can as well use
> readx_poll_timeout for that to catch the odd cases (afaics, there's no real 
> overhead if the exit
> condition is true immediately).
> 
> mailbox_read polls sometimes. Most often it does not poll, as the data is 
> ready in the mbox, and in
> these cases the situation is the same as for mailbox_write.
> 
> The cases where it does poll are related to things where the fw has to wait 
> for something. The
> longest poll waits seemed to be EDID read (16 ms wait) and adjusting LT (1.7 
> ms wait). And afaics,
> when the first byte of the received message is there, the rest of the bytes 
> will be available
> without wait.
> 
> For mailbox_write and for most mailbox_reads I think using interrupts makes 
> no sense, as the
> overhead would be big.
> 
> For those few long read operations, interrupts would make sense. I guess a 
> simple way to handle this
> would be to add a new function, wait_for_mbox_data() or such, which would use 
> the interrupts to wait
> for mbox not empty. This function could be used in selected functions (edid, 
> LT) after
> cdns_mhdp_mailbox_send().
> 
> Although I think it's not that bad currently, MAILBOX_RETRY_US is 1ms, so 
> it's quite lazy polling,
> so perhaps this can be considered TODO optimization.

I'm fine with TODO optimization.

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v8 2/3] drm: bridge: Add support for Cadence MHDP DPI/DP bridge

2020-08-23 Thread Laurent Pinchart
Hi Tomi,

On Fri, Aug 14, 2020 at 11:22:09AM +0300, Tomi Valkeinen wrote:
> On 11/08/2020 05:36, Laurent Pinchart wrote:
> 
> >> +static int cdns_mhdp_connector_init(struct cdns_mhdp_device *mhdp)
> >> +{
> >> +  u32 bus_format = MEDIA_BUS_FMT_RGB121212_1X36;
> >> +  struct drm_connector *conn = >connector;
> >> +  struct drm_bridge *bridge = >bridge;
> >> +  int ret;
> >> +
> >> +  if (!bridge->encoder) {
> >> +  DRM_ERROR("Parent encoder object not found");
> >> +  return -ENODEV;
> >> +  }
> >> +
> >> +  conn->polled = DRM_CONNECTOR_POLL_HPD;
> >> +
> >> +  ret = drm_connector_init(bridge->dev, conn, _mhdp_conn_funcs,
> >> +   DRM_MODE_CONNECTOR_DisplayPort);
> >> +  if (ret) {
> >> +  DRM_ERROR("Failed to initialize connector with drm\n");
> >> +  return ret;
> >> +  }
> >> +
> >> +  drm_connector_helper_add(conn, _mhdp_conn_helper_funcs);
> >> +
> >> +  ret = drm_display_info_set_bus_formats(>display_info,
> >> + _format, 1);
> >> +  if (ret)
> >> +  return ret;
> >> +
> >> +  conn->display_info.bus_flags = DRM_BUS_FLAG_DE_HIGH;
> > 
> > Aren't these supposed to be retrieved from the display ? Why do we need
> > to override them here ?
> 
> DE_HIGH is meant for the display controller. I think this should be in 
> bridge->timings->input_bus_flags
> 
> >> +static int cdns_mhdp_atomic_check(struct drm_bridge *bridge,
> >> +struct drm_bridge_state *bridge_state,
> >> +struct drm_crtc_state *crtc_state,
> >> +struct drm_connector_state *conn_state)
> >> +{
> >> +  struct cdns_mhdp_device *mhdp = bridge_to_mhdp(bridge);
> >> +  const struct drm_display_mode *mode = _state->adjusted_mode;
> >> +  int ret;
> >> +
> >> +  if (!mhdp->plugged)
> >> +  return 0;
> >> +
> >> +  mutex_lock(>link_mutex);
> >> +
> >> +  if (!mhdp->link_up) {
> >> +  ret = cdns_mhdp_link_up(mhdp);
> >> +  if (ret < 0)
> >> +  goto err_check;
> >> +  }
> > 
> > atomic_check isn't supposed to access the hardware. Is there a reason
> > this is needed ?
> 
> We have been going back and forth with this. The basic problem is that
> to understand which videomodes can be used, you need to do link
> training to see the bandwidth available.
> 
> I'm not sure if we strictly need to do LT in atomic check, though...
> It would then pass modes that can't be used, but perhaps that's not a
> big issue.
> 
> I think the main point with doing LT in certain places is to filter
> the list of video modes passed to userspace, as we can't pass the
> modes from EDID directly without filtering them based on the link
> bandwidth.

I've discussed this on #dri-devel with Daniel a week or two ago. His
advice was to drop LT from atomic check, relying on DPCD (DisplayPort
Configuration Data) instead. If LT then fails to negotiate a high-enough
bandwidth for the mode when enabling the output, the link-status
property should be set to bad, and userspace should retry. I think
you've seen the discussion, I can provide a log if needed.

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2] ARM: dts: r8a7742-iwg21d-q7: Add LCD support

2020-08-23 Thread Laurent Pinchart
Hi Prabhakar,

Thank you for the patch.

On Thu, Aug 13, 2020 at 03:00:41PM +0100, Lad Prabhakar wrote:
> The iwg21d comes with a 7" capacitive touch screen, therefore
> add support for it.
> 
> Signed-off-by: Lad Prabhakar 
> Reviewed-by: Marian-Cristian Rotariu 
> 

Everything seems to match the schematics :-)

Reviewed-by: Laurent Pinchart 

> ---
> v1->v2
> * This patch is part of series [1] (rest of the patches have be accepted
>   by Geert [2]).
> * Added regulator for lvds
> * Added reset pin for touchpanel
> * This patch is based on series [3]
> 
> [1] https://patchwork.kernel.org/project/linux-renesas-soc/list/
> ?series=330277
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/geert/
> renesas-devel.git/log/?h=renesas-arm-dt-for-v5.10
> [3] https://patchwork.kernel.org/project/linux-renesas-soc/list/
> ?series=330957
> ---
>  arch/arm/boot/dts/r8a7742-iwg21d-q7.dts | 99 +
>  1 file changed, 99 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/r8a7742-iwg21d-q7.dts 
> b/arch/arm/boot/dts/r8a7742-iwg21d-q7.dts
> index b3461a61a4bf..9bf4fbd9c736 100644
> --- a/arch/arm/boot/dts/r8a7742-iwg21d-q7.dts
> +++ b/arch/arm/boot/dts/r8a7742-iwg21d-q7.dts
> @@ -30,6 +30,7 @@
>  
>  /dts-v1/;
>  #include "r8a7742-iwg21m.dtsi"
> +#include 
>  
>  / {
>   model = "iWave Systems RainboW-G21D-Qseven board based on RZ/G1H";
> @@ -52,6 +53,51 @@
>   clock-frequency = <2600>;
>   };
>  
> + lcd_backlight: backlight {
> + compatible = "pwm-backlight";
> + pwms = < 2 500 0>;
> + brightness-levels = <0 4 8 16 32 64 128 255>;
> + pinctrl-0 = <_pins>;
> + pinctrl-names = "default";
> + default-brightness-level = <7>;
> + enable-gpios = < 11 GPIO_ACTIVE_HIGH>;
> + };
> +
> + lvds-receiver {
> + compatible = "ti,ds90cf384a", "lvds-decoder";
> + vcc-supply = <_3v3_tft1>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + lvds_receiver_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> + port@1 {
> + reg = <1>;
> + lvds_receiver_out: endpoint {
> + remote-endpoint = <_in>;
> + };
> + };
> + };
> + };
> +
> + panel {
> + compatible = "edt,etm0700g0dh6";
> + backlight = <_backlight>;
> + power-supply = <_3v3_tft1>;
> +
> + port {
> + panel_in: endpoint {
> + remote-endpoint = <_receiver_out>;
> + };
> + };
> + };
> +
>   reg_1p5v: 1p5v {
>   compatible = "regulator-fixed";
>   regulator-name = "1P5V";
> @@ -75,6 +121,17 @@
>   };
>   };
>  
> + vcc_3v3_tft1: regulator-panel {
> + compatible = "regulator-fixed";
> +
> + regulator-name = "vcc-3v3-tft1";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + enable-active-high;
> + startup-delay-us = <500>;
> + gpio = < 28 GPIO_ACTIVE_HIGH>;
> + };
> +
>   vcc_sdhi2: regulator-vcc-sdhi2 {
>   compatible = "regulator-fixed";
>  
> @@ -129,12 +186,34 @@
>   VDDIO-supply = <_3p3v>;
>   VDDD-supply = <_1p5v>;
>   };
> +
> + touch: touchpanel@38 {
> + compatible = "edt,edt-ft5406";
> + reg = <0x38>;
> + interrupt-parent = <>;
> + interrupts = <24 IRQ_TYPE_EDGE_FALLING>;
> + /* GP1_29 is also shared with audio codec reset pin */
> + reset-gpios = < 29 GPIO_ACTIVE_LOW>;
> + vcc-supply = <_3v3_tft1>;
> + };
>  };
>  
>   {
>   status = "okay";
>  };
>  
> + {
> + status = "okay";
> +};
> +
> + {
> + t

  1   2   3   4   5   6   7   8   9   10   >