From: Saravana Kannan <email@example.com> To: "Jernej Škrabec" <firstname.lastname@example.org> Cc: email@example.com, Android Kernel Team <firstname.lastname@example.org>, email@example.com Subject: Re: Re: Issue with fw_devlink=on on 5.14 Date: Thu, 16 Sep 2021 19:55:22 -0700 [thread overview] Message-ID: <CAGETcx-_sNJ1Z-8Bmqh+awi-2xnQQLjnJf+Zncj23ByDmJYDJQ@mail.gmail.com> (raw) In-Reply-To: <33995494.1UIDBzYVPQ@kista> On Wed, Sep 15, 2021 at 11:59 AM Jernej Škrabec <firstname.lastname@example.org> wrote: > > /cc email@example.com > > Dne sreda, 15. september 2021 ob 20:36:11 CEST je Saravana Kannan napisal(a): > > On Wed, Sep 15, 2021 at 11:23 AM Saravana Kannan <firstname.lastname@example.org> > wrote: > > > > > > On Wed, Sep 15, 2021 at 11:07 AM Jernej Škrabec > > > <email@example.com> wrote: > > > > > > > > Hi Saravana! > > > > > > > > I noticed that in kernel 5.14, at least on Allwinner H3, deinterlace > driver > > > > doesn't load anymore if fw_devlink is set to on. If I set it to off, > driver > > > > loads and works without problems. If I remove interconnects property in > DT > > > > node and use driver hack instead, it also loads and work ok. > > > > > > > > For reference, I speak about this node: > > > > https://elixir.bootlin.com/linux/v5.14/source/arch/arm/boot/dts/sun8i-h3.dtsi#L153 > > > > Oh the dts file please. Not dtsi. I need the full picture of dependencies. > > I just dumped DTB from the board I use for testing this: > http://ix.io/3yZB I was basically asking for this: arch/arm/boot/dts/sun8i-h3-orangepi-plus2e.dts > > > > > -Saravana > > > > > > > > > > Do you have any clue why it doesn't work? > > > > > > Kinda busy today and I'll take a close look later, but if you delete > > > "interconnect" but it works, then it seems like you have no driver for > > > your "mbus" interconnect? Is that expected? > > Ah, you're completely right. There is no MBUS driver (yet), since current > purpose of that node is to determine DMA memory offsets and for that you don't > need a driver. Can you explain more how you get the DMA memory offsets in the code from this node? You might be able to add status="disabled" to the mbus node and this would go away as fw_devlink doesn't cause a consumer to wait on a disabled supplier. See more below -- you have a bunch of options. > > There is already WIP driver for it, though: > https://github.com/crust-firmware/linux/commit/ > db34316a0194dbf0fcb8eba677ef11085a06a340 > > > > > > > If you have a driver, then make it use the proper driver model (probe > > > a platform device). > > > > > > If you don't have a driver for it, I'm assuming you have > > > CONFIG_MODULES enabled. Otherwise, fw_devlink=on is smart enough to > > > know not to block on devices that'll never be probed. > > Correct, modules are enabled. > > > > > > > If you do need CONFIG_MODULES enabled, then use > > > deferred_probe_timeout=xxx so that fw_devlink doesn't wait for more > > > modules to be loaded past xxx seconds. > > It's not what I want, but more that we broke default configuration and > CONFIG_MODULES=y should really work. Well, fw_devlink=on can't tell if you don't have a driver or if you are going to load it soon (since you have CONFIG_MODULES enabled). So if it's a board you are actively bringing up, one of the other options below might be good to use. > Is there any other way to fix this besides > providing dummy MBUS driver? I doubt it would be accepted for backporting. You could use fw_devlink=permissive in the kernel commandline, but it will disable a bunch of benefits of fw_devlink=on (no pointless deferred probes, no suspend/resume ordering based on dependencies listed in DT, etc). Another option would be to use deferred_probe_timeout=1 in the kernel commandline, and this will cause this to be unblocked 1 second after late_initcall() and you'll get the benefit of fw_devlink=on for all the devices that have a driver registered by then (and some more devices too -- see commit text of d46f3e3ed5276e756caf40f760d4902d15c12dcb). -Saravana > > > > > > > Also I like to look up emails on lore, so when emailing me about > > > fw_devlink (or any Linux stuff in general I suppose), it'd be nice if > > > you can cc LKML. > > Noted. > > Best regards, > Jernej > > > > > > > Thanks, > > > Saravana > > > >
next prev parent reply other threads:[~2021-09-17 2:56 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-09-15 18:07 Jernej Škrabec 2021-09-15 18:23 ` Saravana Kannan 2021-09-15 18:36 ` Saravana Kannan 2021-09-15 18:59 ` Jernej Škrabec 2021-09-17 2:55 ` Saravana Kannan [this message] 2021-09-17 4:32 ` Jernej Škrabec 2021-09-17 15:48 ` Maxime Ripard
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAGETcx-_sNJ1Z-8Bmqh+awi-2xnQQLjnJf+Zncj23ByDmJYDJQ@mail.gmail.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: Re: Issue with fw_devlink=on on 5.14' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).