Messages in this thread | | | From | Saravana Kannan <> | Date | Thu, 16 Apr 2020 13:56:29 -0700 | Subject | Re: [PATCH 0/4] of: property: fw_devlink misc fixes |
| |
On Thu, Apr 16, 2020 at 4:03 AM Nicolas Saenz Julienne <nsaenzjulienne@suse.de> wrote: > > On Wed, 2020-04-15 at 11:17 -0700, Saravana Kannan wrote: > > On Wed, Apr 15, 2020 at 8:06 AM Nicolas Saenz Julienne > > <nsaenzjulienne@suse.de> wrote: > > > As I'm interested in using this feature to fine-tune Raspberry Pi 4's > > > > You've made my day! Finally another user outside of Android. :) If > > this does improve the boot time, I'd be super interested to see the > > numbers. > > Actually making the boot time faster isn't my main objective just a nice > possible side-effect. I'll give you some numbers nonetheless :).
Thanks!
> I have two things in mind: > - Exploring if fw_devlink=on can help us solve a rather convoluted device > initialization depency we're seeing in RPi4. It could potentially prevent us > from adding nasty platform specific driver code.
I hope it does! I've also noticed that fw_devlink avoids the need for ugly hacks in drivers and side steps poorly written error handling in drivers.
> - See if we can use all this information to fine-tune initrd generation on > smaller arm devices with limited i/o speeds.
That's pretty cool. I have no idea how fw_devlink helps here, but I'm glad it does :)
> Do you have any plans in moving the default behavior to fw_devlink=on? If so > what is blocking us?
That's my eventual goal. The main reasons it hasn't been done yet are: 1. Cases like yours where there might be fake cycles. 2. Cases of DT with bad choice of properties. Say, something like "nr-gpios" would cause error spew in the logs (not a functional error). 3. Whatever other unknown reasons this might cause boot up issues.
I'm starting with trying to turn on fw_devlink=permissive so that driver developers can stop playing chicken with initcall levels. Then work towards setting fw_devlink=on (going to be a long road).
> Also do you think it'd be reasonable to add a DT binding to set the desired > fw_devlink level? Something like a 'linux,fw_devlink' property under the > /chosen node.
I don't mind that, but not sure if DT maintainers are okay with it. But if we do have that, I'd still want the kernel command line to override it.
Thanks, Saravana
| |