Date:	Fri, 6 May 2016 16:43:18 +0200
From:	Thierry Reding <thierry.reding@...il.com>
To:	Noralf Trønnes <noralf@...nnes.org>
Cc:	treding@...dia.com, linux-kernel@...r.kernel.org,
	dri-devel@...ts.freedesktop.org, Daniel Vetter <daniel@...ll.ch>
Subject: Re: [PATCH 4/4] drm/panel: Add helper for simple panel connector

On Fri, May 06, 2016 at 04:34:08PM +0200, Noralf Trønnes wrote:
> 
> Den 06.05.2016 16:15, skrev Thierry Reding:
> > On Fri, May 06, 2016 at 04:08:16PM +0200, Daniel Vetter wrote:
> > > On Fri, May 06, 2016 at 04:03:47PM +0200, Thierry Reding wrote:
> > > > On Thu, May 05, 2016 at 03:24:34PM +0200, Noralf Trønnes wrote:
> > > > > Add function to create a simple connector for a panel.
> > > > I'm not sure I see the usefulness of this. Typically you'd attach a
> > > > panel to an encoder/connector, in which case you already have the
> > > > connector.
> > > > 
> > > > Perhaps it would become more obvious why we need this if you posted
> > > > patches that show where this is used?
> > > The other helpers give you a simple drm pipeline with plane, crtc &
> > > encoder all baked into on drm_simple_pipeline structure. The only thing
> > > variable you have to hook up to that is the drm_connector. And I think for
> > > dead-simple panels avoiding the basic boilerplate in that does indeed make
> > > some sense.
> > Avoiding boilerplate is good, but I have a difficult time envisioning
> > how you might want to use this. At the same time I'm asking myself how
> > we know that this helper is any good if we haven't seen it used anywhere
> > and actually see the boilerplate go away.
> 
> I pulled out the patches from the tinydrm patchset that would go
> into drm core and helpers. I'm not very good at juggling many patches
> around in various version and getting it right.
> I'm doing development in the downstream Raspberry Pi repo
> on 4.5 to get all the pi drivers, and then apply it on linux-next...
> 
> This is the tinydrm patch that will use it:
> https://lists.freedesktop.org/archives/dri-devel/2016-April/104502.html
> 
> Extract:
> +int tinydrm_display_pipe_init(struct tinydrm_device *tdev,
> +                  const uint32_t *formats, unsigned int format_count)
> +{
> +    struct drm_device *dev = tdev->base;
> +    struct drm_connector *connector;
> +    int ret;
> +
> +    connector = drm_simple_kms_panel_connector_create(dev, &tdev->panel,
> +                        DRM_MODE_CONNECTOR_VIRTUAL);
> +    if (IS_ERR(connector))
> +        return PTR_ERR(connector);
> +
> +    ret = drm_simple_display_pipe_init(dev, &tdev->pipe,
> +                &tinydrm_display_pipe_funcs,
> +                formats, format_count,
> +                connector);
> +
> +    return ret;
> +}
> +EXPORT_SYMBOL(tinydrm_display_pipe_init);
> 
> drm_simple_kms_panel_connector_create() changed name when Daniel
> suggested it be moved to drm_panel.c or drm_panel_helper.c.

Okay, that gives me a better understanding of where things are headed.
That said, why would these devices even need to deal with drm_panel in
the first place? Sounds to me like they are devices on some sort of
control bus that you talk to directly. And they will represent
essentially the panel with its built-in display controller.

drm_panel on the other hand was designed as an interface between display
controllers and panels, with the goal to let any display controller talk
to any panel.

While I'm sure you can support these types of simple panels using the
drm_panel infrastructure I'm not sure it's necessary, since your driver
will always talk to the panel directly, and hence the code to deal with
the panel specifics could be part of the display pipe functions.

Thierry

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)

Powered by blists - more mailing lists