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

Peter Ujfalusi peter.ujfalusi at ti.com
Mon Sep 4 10:03:36 UTC 2017


Hi Laurent,


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.

>> 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?

> 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(-)
> 

- Péter



More information about the dri-devel mailing list