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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
