On Fri, Oct 04, 2024 at 02:52:24PM +0300, Tomi Valkeinen wrote: > Hi Dmitry, > > On 27/09/2024 11:35, Dmitry Baryshkov wrote: > > On Fri, 27 Sept 2024 at 08:41, Tomi Valkeinen > > <tomi.valkei...@ideasonboard.com> 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.
My thought was that the flag should be set before panel / DSS drivers being probed. -- With best wishes Dmitry
