mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
To: Saravana Kannan <saravanak@google.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
	<devicetree@vger.kernel.org>,
	Frank Rowand <frowand.list@gmail.com>,
	Rob Herring <robh+dt@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/4] of: property: fw_devlink misc fixes
Date: Thu, 16 Apr 2020 13:02:59 +0200	[thread overview]
Message-ID: <69b79028764dcdfc9f550a5f95752afb491005f0.camel@suse.de> (raw)
In-Reply-To: <CAGETcx-=E-6sg=B2Rr+V51eCxiBjNWPnOvvq6K=o9Sr-qLDvOg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1531 bytes --]

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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2020-04-16 11:07 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-15 15:05 Nicolas Saenz Julienne
2020-04-15 15:05 ` [PATCH 1/4] of: property: Fix create device links for all child-supplier dependencies Nicolas Saenz Julienne
2020-04-15 18:20   ` Saravana Kannan
2020-04-15 18:22   ` Saravana Kannan
2020-04-16 11:32     ` Nicolas Saenz Julienne
2020-04-15 15:05 ` [PATCH 2/4] of: property: Do not link to disabled devices Nicolas Saenz Julienne
2020-04-15 18:30   ` Saravana Kannan
2020-04-16 11:37     ` Nicolas Saenz Julienne
2020-04-16 20:56       ` Saravana Kannan
2020-04-15 15:05 ` [PATCH 3/4] of: property: Move of_link_to_phandle() Nicolas Saenz Julienne
2020-04-15 15:05 ` [PATCH 4/4] of: property: Avoid linking devices with circular dependencies Nicolas Saenz Julienne
2020-04-15 18:52   ` Saravana Kannan
2020-04-16 16:01     ` Nicolas Saenz Julienne
2020-04-16 20:57       ` Saravana Kannan
2020-04-16 20:58       ` [PATCH v1] of: property: Don't retry device_link_add() upon failure Saravana Kannan
2020-04-17 16:50         ` Nicolas Saenz Julienne
2020-04-17 18:16         ` Rob Herring
2020-04-17 20:30           ` Saravana Kannan
2020-04-28 17:11         ` Rob Herring
2020-04-15 18:17 ` [PATCH 0/4] of: property: fw_devlink misc fixes Saravana Kannan
2020-04-16 11:02   ` Nicolas Saenz Julienne [this message]
2020-04-16 20:56     ` Saravana Kannan

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=69b79028764dcdfc9f550a5f95752afb491005f0.camel@suse.de \
    --to=nsaenzjulienne@suse.de \
    --cc=devicetree@vger.kernel.org \
    --cc=frowand.list@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=saravanak@google.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®