[RFC 0/7] drm/omap: Module parameter for display order configuration

[Laurent Pinchart]

Hi Peter,

On Monday, 4 September 2017 13:03:36 EEST Peter Ujfalusi wrote:

I should drop dates when I reply to such old e-mails...

> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> On 2017-09-01 14:36, Laurent Pinchart wrote:
> >> We have boards with LCD panel and HDMI for example and in DT the LCD is
> >> set as display0, but in certain useage scenarios it is desired to have
> >> the HDMI as the 'main' display instead of the LCD.
> > 
> > One could argue that the DT should then be updated. The device tree is a
> > description of the whole system, not just the board. If a board is
> > integrated in a system that makes HDMI the primary display, it would make
> > sense for DT to reflect that.
> 
> Yes, in case when the device is prepared for a use case this can be done
> with recompiling the DT, but when you have a device which uses the LCD
> as primary display by design and move that to connect it to a HDMI
> TV/monitor and want to use it there for a prolonged time, you might not
> want to set up a development environment just to recompile the DT. In
> this case you just add the kernel parameter and be done with the
> adaptation to the new use case.

One could also argue that in that case it would be better to handle that in 
userspace, as it would be more user-friendly than having to change the kernel 
command line.

(What, does it show that I'm trying to push features out of the kernel ? :-))

> >> The first 6 patch of the series is doing some generic clean up and
> >> prepares the code so the display ordering is going to be easy to add.
> > 
> > This will conflict with the work I'm doing on merging the omapdrm and
> > omapdss driver, so I'm a bit reluctant to merge this first :-/
> 
> Understand. I will update the patches based on the comments and roll it
> in my wip branch for now and going to send v1 when the omapdrm is
> ompadss is merged?

I'll reply to the v2 of your patch series to address this.

> > In particular, with the two drivers merged, couldn't we implement this
> > module parameter without moving the display sorting from omapdss to
> > omapdrm ?
> 
> If they are merged, then we will only have omapdss ;)
> 
> I wanted to have all sorting in one place so it is going to be easier to
> locate them and since they are in one place it might make easier to
> merge the the omapdss to omapdrm. Or not.
> 
> >> ---
> >> 
> >> Peter Ujfalusi (7):
> >>   drm/omap: Use devm_kzalloc() to allocate omap_drm_private
> >>   drm/omap: Allocate drm_device earlier and unref it as last step
> >>   drm/omap: Manage the usable omap_dss_device list within
> >>   
> >>     omap_drm_private
> >>   
> >>   drm/omap: Separate the dssdevs array setup from the connect function
> >>   drm/omap: Do dss_device (display) ordering in omap_drv.c
> >>   drm/omap: dss: Remove display ordering from dss/display.c
> >>   drm/omap: Add kernel parameter to specify the desired display order
> >>  
> >>  drivers/gpu/drm/omapdrm/dss/display.c |  15 +--
> >>  drivers/gpu/drm/omapdrm/dss/omapdss.h |   3 -
> >>  drivers/gpu/drm/omapdrm/omap_drv.c    | 244 +++++++++++++++++++---------
> >>  drivers/gpu/drm/omapdrm/omap_drv.h    |   3 +
> >>  4 files changed, 183 insertions(+), 82 deletions(-)

-- 
Regards,

Laurent Pinchart