Hello again,
On Fri, Mar 22, 2024 at 06:53:57PM -0700, Saravana Kannan wrote:
> Hmmm.... cycle detection should work here and not enforce probe
> ordering. I'd appreciate help with debugging that. Let me look at it
> on Monday. Can you enabled all the debug logs in drivers/base/core.c
> and tell me what cycle detection is telling about these nodes?
Hmm. It's not saying anything more than what I've already sent.
I think this is because /sound/multi isn't a device, it's just a
subnode used in audio-graph-card2.
Removing the multi { } section and using direct graph connections
'fixes' this.
I think this might be because usually in a graph each node containing
ports is a device, such as a display panel, a bridge, an LCD
controller. These kind of form a dependency chain.
In this case all the ports in multi act as a way to glue multiple
ports together for the audio-graph-card2.
Does that help?
> But the better fix would be to use the new "post-init-providers"
> property. See below.
>
> >
> > / {
> > ...
> >
> >
> > test_codec {
> > compatible = "test-codec";
> > prefix = "Test codec";
> > #sound-dai-cells = <0>;
>
> post-init-provider = <&multi>;
>
> Right now there's a cyclic dependency between test_codec and multi and
> this tells the kernel that test codec needs to probe first.
>
> Similar additions to the other nodes blocked on multi.
>
> Thanks,
> Saravana
John.
