[RFC 0/7] drm/omap: Module parameter for display order configuration
laurent.pinchart at ideasonboard.com
Fri May 25 20:09:23 UTC 2018
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
(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(-)
More information about the dri-devel