[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGETcx_AHV8CDzRQ-y3xNRcT_QTi2ise1YwO7mw=u85g6O1uYQ@mail.gmail.com>
Date: Thu, 16 Apr 2020 13:56:29 -0700
From: Saravana Kannan <saravanak@...gle.com>
To: Nicolas Saenz Julienne <nsaenzjulienne@...e.de>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@...r.kernel.org>,
Frank Rowand <frowand.list@...il.com>,
Rob Herring <robh+dt@...nel.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/4] of: property: fw_devlink misc fixes
On Thu, Apr 16, 2020 at 4:03 AM Nicolas Saenz Julienne
<nsaenzjulienne@...e.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@...e.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
Powered by blists - more mailing lists