Re: fw_devlinks preventing a panel driver from probing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Dmitry,

On 27/09/2024 11:35, Dmitry Baryshkov wrote:
On Fri, 27 Sept 2024 at 08:41, Tomi Valkeinen
<tomi.valkeinen@xxxxxxxxxxxxxxxx> wrote:

On 27/09/2024 02:26, Dmitry Baryshkov wrote:
On Thu, Sep 26, 2024 at 02:52:35PM GMT, Tomi Valkeinen wrote:
Hi,

On 21/09/2024 23:15, Dmitry Baryshkov wrote:
On Mon, Sep 16, 2024 at 02:51:57PM GMT, Tomi Valkeinen wrote:
Hi,

We have an issue where two devices have dependencies to each other,
according to drivers/base/core.c's fw_devlinks, and this prevents them from
probing. I've been adding debugging to the core.c, but so far I don't quite
grasp the issue, so I thought to ask. Maybe someone can instantly say that
this just won't work...

Well, just 2c from my side. I consider that fw_devlink adds devlinks for
of-graph nodes to be a bug. It doesn't know about the actual direction
of dependencies between corresponding devices or about the actual
relationship between drivers. It results in a loop which is then broken
in some way. Sometimes this works. Sometimes it doesn't. Sometimes this
hides actual dependencies between devices. I tried reverting offending
parts of devlink, but this attempt failed.

I was also wondering about this. The of-graphs are always two-way links, so
the system must always mark them as a cycle. But perhaps there are other
benefits in the devlinks than dependency handling?

If I understand the fw_devlink code correctly, in a normal case the links
formed with media graphs are marked as a cycle (FWLINK_FLAG_CYCLE), and then
ignored as far as probing goes.

What we see here is that when using a single-link OLDI panel, the panel
driver's probe never gets called, as it depends on the OLDI, and the link
between the panel and the OLDI is not a cycle.

I think in your case you should be able to fix the issue by using the
FWNODE_FLAG_NOT_DEVICE, which is intented to be used in such cases. You

How would I go using FWNODE_FLAG_NOT_DEVICE? Won't this only make a
difference if the flag is there at early stage when the linux devices are
being created? I think it's too late if I set the flag when the dss driver
is being probed.

I think you have the NOT_DEVICE case as the DSS device corresponds to
the parent of your OLDI nodes. There is no device which corresponds to
the oldi@0 / oldi@1 device nodes (which contain corresponding port
nodes).

Do you mean that I should already see FWNODE_FLAG_NOT_DEVICE set in the
fwnode?

No, I think you should set it for you DSS links. If I understand
correctly, this should prevent fwdevlink from waiting on the OLDI to
materialize as a device.
Note: my understanding is based on a quick roaming through the code
some time ago.

Ok. Well, I did experiment with that, but I didn't figure out how to use it. Afaics, even if I set FWNODE_FLAG_NOT_DEVICE to the oldi nodes (just as an experiment I also set it to all the nodes from dss to oldi) in the DSS driver's probe, it doesn't help: the panel driver still doesn't probe.

I also wonder whether it would work reliably even if it did work. First the panel driver is prevented from probing as the oldi dependency is not present. Then the DSS driver probes, sets the above flag, but then it fails to probe as the panel is missing. At this point something should trigger the probing of the panel driver again, and I wonder if there's anything to trigger it.

 Tomi




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux