drm: Stable identification of connectors?

drm: Stable identification of connectors?

[Albert, Joerg (TT-U)]

[-- Attachment #1: Type: text/plain, Size: 2069 bytes --]

Hi,


I’m pretty new to DRM/DRI and wonder if there is a way to have a stable identification of connectors across changes in the Linux kernel and/or in the devicetree?

Our hardware contains an iMX8QM with two displays, each one connected to a MIPI-DSI channel. We use kernel 6.1.38.
In the output of “modetest -c” the connectors are called LVDS-1 and LVDS-2. These names are built in modetest.c from connector_type and connector_type_id.

connector_type_id is set in the kernel in drivers/gpu/drm/drm_connector.c in __drm_connector_init():


       connector<https://elixir.bootlin.com/linux/latest/C/ident/connector>->connector_type_id<https://elixir.bootlin.com/linux/latest/C/ident/connector_type_id> =

              ida_alloc_min<https://elixir.bootlin.com/linux/latest/C/ident/ida_alloc_min>(connector_ida<https://elixir.bootlin.com/linux/latest/C/ident/connector_ida>, 1, GFP_KERNEL<https://elixir.bootlin.com/linux/latest/C/ident/GFP_KERNEL>);

Seems to me that this number depends on initialization order only. Is there any other way to identify a connector?

If not, will the type_id be stable as long as we don’t change the kernel version and the device tree?


Best Regards,
Joerg Albert






+491747384960


We move the world for the better through technology and engineering.

www.iav.com<https://www.iav.com> | Facebook<https://www.facebook.com/insideiav> | Instagram<https://www.instagram.com/inside_iav/> | LinkedIn<https://www.linkedin.com/company/iav-gmbh> | Xing<https://www.xing.com/companies/iav> | YouTube<https://www.youtube.com/user/IAVchannel>

IAV GmbH Ingenieurgesellschaft Auto und Verkehr; Sitz/Registered Office: Berlin; Registergericht/Registration Court: Amtsgericht Charlottenburg (Berlin); Registernummer/Company Registration Number: HRB 21 280 B; Geschäftsführer/Managing Directors: Joerg Astalosch, Martin Mahlke, Dr. Uwe Horn; Vorsitzender des Aufsichtsrates/Chairman of the Supervisory Board: Dr. Nikolai Ardey
Datenschutzhinweise/Privacy Policy<https://www.iav.com/datenschutz>


[-- Attachment #2: Type: text/html, Size: 11819 bytes --]

Re: drm: Stable identification of connectors?

[Pekka Paalanen]

[-- Attachment #1: Type: text/plain, Size: 3001 bytes --]

On Fri, 26 Jan 2024 10:30:10 +0000
"Albert, Joerg (TT-U)" <Joerg.Albert@iav.de> wrote:

> Hi,
> 
> 
> I’m pretty new to DRM/DRI and wonder if there is a way to have a
> stable identification of connectors across changes in the Linux
> kernel and/or in the devicetree?
> 
> Our hardware contains an iMX8QM with two displays, each one connected
> to a MIPI-DSI channel. We use kernel 6.1.38. In the output of
> “modetest -c” the connectors are called LVDS-1 and LVDS-2. These
> names are built in modetest.c from connector_type and
> connector_type_id.
> 
> connector_type_id is set in the kernel in
> drivers/gpu/drm/drm_connector.c in __drm_connector_init():
> 
> 
>        connector<https://elixir.bootlin.com/linux/latest/C/ident/connector>->connector_type_id<https://elixir.bootlin.com/linux/latest/C/ident/connector_type_id>
> =
> 
>               ida_alloc_min<https://elixir.bootlin.com/linux/latest/C/ident/ida_alloc_min>(connector_ida<https://elixir.bootlin.com/linux/latest/C/ident/connector_ida>,
> 1,
> GFP_KERNEL<https://elixir.bootlin.com/linux/latest/C/ident/GFP_KERNEL>);
> 
> Seems to me that this number depends on initialization order only. Is
> there any other way to identify a connector?
> 
> If not, will the type_id be stable as long as we don’t change the
> kernel version and the device tree?

Hi,

the question of persistent connector and DRM device names (paths) comes
up every once in a while. Here is one take:
https://lists.freedesktop.org/archives/dri-devel/2019-June/221902.html

Yes, connector_type_id numbering depends on driver and connector
initialization order. Usually it has been a problem only for systems
with multiple display driver instances racing to initialize their
connectors.

One idea was to use the connector index in the KMS resources array UAPI
as a persistent device-private id. This does not work for MST and other
dynamically appearing and disappearing connectors though, and ISTR it
had some other problem too. It could be stable as long as a driver
registers its permanent connectors always in the same order.

There is the connector "PATH" property, but so far that only exists on
MST connectors, and I recall some doubts whether the current
implementation of even that was truly persistent.

In general, I believe the persistent naming of connectors is an
unsolved problem. Persistent naming of DRM devices at least has a
tentative solution as "device path", by e.g. PCI topology. I think that
breaks down if you happen to have multiple platform DRM KMS devices.

To me it seems some kind of "hardware path" would be the only truly
persistent device and connector naming scheme, assuming the hardware
remains the same.

I'd guess many desktops circumvent the problem by not identifying
connectors but displays based on their EDID serial number or hash.
Naturally that does not work always, either, EDID can lack a serial, be
identical, or not exist.


Thanks,
pq

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: drm: Stable identification of connectors?

[Dave Stevenson]

[-- Attachment #1: Type: text/plain, Size: 3897 bytes --]

Hi Joerg

On Fri, 26 Jan 2024 at 10:45, Albert, Joerg (TT-U) <Joerg.Albert@iav.de>
wrote:

> Hi,
>
>
>
> I’m pretty new to DRM/DRI and wonder if there is a way to have a stable
> identification of connectors across changes in the Linux kernel and/or in
> the devicetree?
>
>
>
> Our hardware contains an iMX8QM with two displays, each one connected to a
> MIPI-DSI channel. We use kernel 6.1.38.
>
> In the output of “modetest -c” the connectors are called LVDS-1 and
> LVDS-2. These names are built in modetest.c from connector_type and
> connector_type_id.
>
>
>
> connector_type_id is set in the kernel in drivers/gpu/drm/drm_connector.c
> in __drm_connector_init():
>
>
>
>        *connector* <https://elixir.bootlin.com/linux/latest/C/ident/connector>->*connector_type_id* <https://elixir.bootlin.com/linux/latest/C/ident/connector_type_id> =
>
>               *ida_alloc_min* <https://elixir.bootlin.com/linux/latest/C/ident/ida_alloc_min>(*connector_ida* <https://elixir.bootlin.com/linux/latest/C/ident/connector_ida>, 1, *GFP_KERNEL* <https://elixir.bootlin.com/linux/latest/C/ident/GFP_KERNEL>);
>
>
>
> Seems to me that this number depends on initialization order only. Is
> there any other way to identify a connector?
>
>
>
> If not, will the type_id be stable as long as we don’t change the kernel
> version and the device tree?
>

My understanding is it all depends on initialisation order, and that isn't
guaranteed.

Raspberry Pi 5 has a similar issue that it has two independent DRM driver
instances each initialising a DSI connector. Which one gets assigned DSI-1
vs DSI-2 is down to probe order, and can change between boots.
You also have the situation that a panel connected to the second connector
is referred to as DSI-1 if nothing is connected to the first, but it'll
probably bump up to DSI-2 should you later configure a panel on the first
connector. Any configuration within a window manager based on display ID is
therefore near useless if there is any change to the system.

It's the same situation if you have more than one SPI display using the
mipi-dbi-spi or tinyDRM drivers - ordering of display to SPI-x IDs is down
to probe order, so near random.

I haven't attempted to upstream this yet, but on our tree [1] I've adopted
the same approach as the I2C and SPI subsystems take where a DT alias can
be used to set the desired connector ID. Devices with no alias get assigned
IDs above the last assigned alias.

Seeing as you've raised the same issue, it'd be interesting to know the
view of the maintainers as to whether my solution is acceptable. There's no
point in trying to upstream it if it's going to be immediately shot down.

Thanks.
  Dave

[1]
https://github.com/raspberrypi/linux/commit/3aa1f2477545ea6298bc6f2d7ffae68f090af9b8
and fixup
https://github.com/raspberrypi/linux/commit/f429fc1a072d4bb35e622a1012a5a52914eba4e3


>
> Best Regards,
>
> Joerg Albert
>
>
>
>
>
>
>
>
>
>
>
>
> +491747384960
>
>
>
>
> We move the world for the better through technology and engineering.
>
> www.iav.com | Facebook <https://www.facebook.com/insideiav> | Instagram
> <https://www.instagram.com/inside_iav/> | LinkedIn
> <https://www.linkedin.com/company/iav-gmbh> | Xing
> <https://www.xing.com/companies/iav> | YouTube
> <https://www.youtube.com/user/IAVchannel>
>
> IAV GmbH Ingenieurgesellschaft Auto und Verkehr; Sitz/Registered Office:
> Berlin; Registergericht/Registration Court: Amtsgericht Charlottenburg
> (Berlin); Registernummer/Company Registration Number: HRB 21 280 B;
> Geschäftsführer/Managing Directors: Joerg Astalosch, Martin Mahlke, Dr. Uwe
> Horn; Vorsitzender des Aufsichtsrates/Chairman of the Supervisory Board:
> Dr. Nikolai Ardey
> Datenschutzhinweise/Privacy Policy <https://www.iav.com/datenschutz>
>
>
>

[-- Attachment #2: Type: text/html, Size: 11946 bytes --]

Re: drm: Stable identification of connectors?

[Pekka Paalanen]

[-- Attachment #1: Type: text/plain, Size: 2190 bytes --]

On Fri, 26 Jan 2024 14:18:36 +0000
Dave Stevenson <dave.stevenson@raspberrypi.com> wrote:

> Raspberry Pi 5 has a similar issue that it has two independent DRM driver
> instances each initialising a DSI connector. Which one gets assigned DSI-1
> vs DSI-2 is down to probe order, and can change between boots.
> You also have the situation that a panel connected to the second connector
> is referred to as DSI-1 if nothing is connected to the first, but it'll
> probably bump up to DSI-2 should you later configure a panel on the first
> connector. Any configuration within a window manager based on display ID is
> therefore near useless if there is any change to the system.
> 
> It's the same situation if you have more than one SPI display using the
> mipi-dbi-spi or tinyDRM drivers - ordering of display to SPI-x IDs is down
> to probe order, so near random.
> 
> I haven't attempted to upstream this yet, but on our tree [1] I've adopted
> the same approach as the I2C and SPI subsystems take where a DT alias can
> be used to set the desired connector ID. Devices with no alias get assigned
> IDs above the last assigned alias.

Hi Dave,

how does the DT make sure that the alias is always assigned to the same
physical connector?

Is there some persistent, permanent, stable hardware path that the DT
is keying off of?

How about finding a consensus on exposing such hardware paths in the
first place so that there is no need to set aliases in DT. That could
also help systems that don't use DT in the first place.

I think Ville had a serious attempt in
https://lists.freedesktop.org/archives/dri-devel/2019-June/221902.html
but I guess people were not interested?


Thanks,
pq

> Seeing as you've raised the same issue, it'd be interesting to know the
> view of the maintainers as to whether my solution is acceptable. There's no
> point in trying to upstream it if it's going to be immediately shot down.
> 
> Thanks.
>   Dave
> 
> [1]
> https://github.com/raspberrypi/linux/commit/3aa1f2477545ea6298bc6f2d7ffae68f090af9b8
> and fixup
> https://github.com/raspberrypi/linux/commit/f429fc1a072d4bb35e622a1012a5a52914eba4e3
> 

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]