| Message ID | 20200415150550.28156-1-nsaenzjulienne@suse.de |
|---|---|
| Headers | show |
| Series | of: property: fw_devlink misc fixes | expand |
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. > device probe dependencies, I tried to get the board to boot with > fw_devlink=on. As of today's linux-next the board won't boot with that > option. I tried to address the underlying issues. I'll review the patches. Apologies in advance if my explanations aren't thorough. A bit swamped right now. -Saravana
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 :). 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. - See if we can use all this information to fine-tune initrd generation on smaller arm devices with limited i/o speeds. Do you have any plans in moving the default behavior to fw_devlink=on? If so what is blocking us? 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. > > device probe dependencies, I tried to get the board to boot with > > fw_devlink=on. As of today's linux-next the board won't boot with that > > option. I tried to address the underlying issues. > > I'll review the patches. Apologies in advance if my explanations > aren't thorough. A bit swamped right now. They were pretty clear! Thanks, Nicolas
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
As I'm interested in using this feature to fine-tune Raspberry Pi 4's device probe dependencies, I tried to get the board to boot with fw_devlink=on. As of today's linux-next the board won't boot with that option. I tried to address the underlying issues. --- Nicolas Saenz Julienne (4): of: property: Fix create device links for all child-supplier dependencies of: property: Do not link to disabled devices of: property: Move of_link_to_phandle() of: property: Avoid linking devices with circular dependencies drivers/of/property.c | 190 +++++++++++++++++++++++++++--------------- 1 file changed, 124 insertions(+), 66 deletions(-)