[PATCH 1/2] drm/panel: Add and fill drm_panel type field

[Laurent Pinchart]

Hi Nicolas,

On Fri, Aug 23, 2019 at 07:30:07AM +0000, Nicolas.Ferre at microchip.com wrote:
> On 23/08/2019 at 03:40, Laurent Pinchart wrote:
> > Add a type field to the drm_panel structure to report the panel type,
> > using DRM_MODE_CONNECTOR_* macros (the values that make sense are LVDS,
> > eDP, DSI and DPI). This will be used to initialise the corresponding
> > connector type.
> 
> With Microchip/Atmel driver, we mainly (only) use the "Unknown" type of 
> connector because our hardware simply uses RGB wires in parallel.

That's called DPI (Display Pixel Interface, sometimes also referred to
as Display Parallel Interface) :-)

> Should we move to another connector type (maybe now that it's created 
> and it was not, back when we chose the "Unknown" one)?

I think DRM_MODE_CONNECTOR_DPI would be best, yes.

> What would be the consequences if we move (silently?) to another type 
> and particularly on the command line argument like the ones we currently 
> use: "Unknown-1:800x480-16"?

That will be nasty to handle :-( As much as I'd love to ignore that
issue, I don't think we can. At the same time it shouldn't prevent us
from moving forward and exposing the real connector type. One option
could be to keep the extra type argument to drm_panel_bridge_add() to
force the connector type, and add another variant of the function that
would derive it automatically from the panel type. Drivers could then
decide to switch to the new variant on a case-by-case basis. Still, that
won't solve your issue, as I'm not sure how you would be able to decide
which variant to call if we want newer systems to expose the right panel
type while keeping backward compatibility.

Another option would be to hack the command line argument parsing to
convert Unknown-* to a panel type when there's no connector with an
unknown type, but that seems fragile.

Any other proposal ? :-)

> > Update all panel drivers to fill the new field.
> > 
> > Signed-off-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>

-- 
Regards,

Laurent Pinchart