[PATCH] drm: support gpu aliases defined in DT data

[Tomi Valkeinen]

On 06/03/2019 03:41, Laurent Pinchart wrote:
> Hi Tomi,
> 
> On Fri, Jan 18, 2019 at 10:29:33AM +0200, Tomi Valkeinen wrote:
>> On 18/01/19 00:04, Rob Herring wrote:
>>
>>> Mesa/libdrm already has lots of code to open the correct devices and
>>> not care about minor numbers. What's the problem here?
>>
>> Well, maybe the problem is that I don't know how to do this =).
>>
>> So, if we have multiple DRM devices, how does one manage those?
>> Iterating over them and looking for kms-capable ones is easy enough. But
>> if there are multiple kms-capable ones, how should the userspace choose
>> between those?
>>
>> I see that udev creates /dev/dri/by-path/ links to the cards, should the
>> userspace use those to have a persistent link to the card? E.g. first
>> time the app is ran, it'll collect all the kms-capable cards, and store
>> the by-path names somewhere, and in subsequent runs it will instead use
>> the by-path names to keep the order the same.
>>
>> If I have a product with two display controllers, and one of them has
>> the main display connected, how does my custom app know which card to
>> use? Hardcoding the by-path in the app?
> 
> I think it depends on how you define "main display". We have a similar
> problem with cameras where a system such as a phone or tablet with a
> front camera and a back camera has no good way to convey the role of
> each camera all the way to applications. The information belongs to
> system firmware in my opinion (and thus DT in this case), but probably
> not in the form of aliases. It would make sense to tag connector and
> panels with some kind of role (such as main display, various kind of
> auxiliary displays, ...), parse that information in drivers, and report
> it to userspace (ideally through standard APIs).

I agree. I did have "label" in the omapdrm-style panels and connectors,
but that's not used anywhere.

But this patch is not really about what you describe above, The target
was really just to have card0 to be a modesetting card, making simple
apps that use card0 for display working. So, obviously a work-around or
even a hack, but solves the issue without changing the userspace.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki