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

[Emil Velikov]

Hi Tomi,

On Fri, 18 Jan 2019 at 08:29, Tomi Valkeinen <tomi.valkeinen at ti.com> 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?
>
> If udev/systemd is not available, how does the userspace do this? I
> tried to see if one can get enough information from the card device with
> ioctls to figure these things out, but I didn't figure this out. Should
> the drmGetBusid() return something for platform devices too? Maybe I've
> got something missing from the display driver, and drmGetBusid() should
> return something similar as what is in the by-path name.
>
Have you looked at the libdrm drmDevice2 (yes use the second version) API?
It provides various information about the different devices, yet if
it's missing anything do send us a patch ;-)

It was introduced explicitly w/o depending on udev/systemd, since they
are not always available.
On the topic of drmGetBusid() - I would stay away from it, since it's
more or less a legacy artefact.

HTH
Emil