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

From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: devicetree@vger.kernel.org,
	Maxime Ripard <maxime.ripard@bootlin.com>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	David Airlie <airlied@linux.ie>, Sean Paul <sean@poorly.run>
Subject: Re: [PATCH] drm: support gpu aliases defined in DT data
Date: Wed, 6 Mar 2019 03:41:24 +0200	[thread overview]
Message-ID: <20190306014124.GC30262@pendragon.ideasonboard.com> (raw)
In-Reply-To: <e5513293-416c-f4aa-a6ab-7c4e762753ed@ti.com>

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

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

-- 
Regards,

Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel