Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1246406 > unrolled thread

[GIT PULL] On-demand device probing

Back to article view | Back to linux.kernel

Contents

  [GIT PULL] On-demand device probing Tomeu Vizoso <tomeu.vizoso@collabora.com> - 2015-10-14 10:40 +0200
    Re: [GIT PULL] On-demand device probing Mark Brown <broonie@kernel.org> - 2015-10-14 11:30 +0200
      [GIT PULL] On-demand device probing Tomeu Vizoso <tomeu.vizoso@collabora.com> - 2015-10-15 13:50 +0200
        Re: [GIT PULL] On-demand device probing Olof Johansson <olof@lixom.net> - 2015-10-16 23:30 +0200
          Re: [GIT PULL] On-demand device probing Rob Herring <robh+dt@kernel.org> - 2015-10-17 17:30 +0200
    Re: [GIT PULL] On-demand device probing Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2015-10-17 09:00 +0200
      Re: [GIT PULL] On-demand device probing Rob Herring <robh+dt@kernel.org> - 2015-10-17 17:10 +0200
        Re: [GIT PULL] On-demand device probing Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2015-10-17 17:50 +0200
          Re: [GIT PULL] On-demand device probing Rob Herring <robh+dt@kernel.org> - 2015-10-17 18:30 +0200
            Re: [GIT PULL] On-demand device probing Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2015-10-17 19:00 +0200
              Re: [GIT PULL] On-demand device probing Rob Clark <robdclark@gmail.com> - 2015-10-17 20:00 +0200
                Re: [GIT PULL] On-demand device probing Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2015-10-17 20:30 +0200
                  Re: [GIT PULL] On-demand device probing Rob Clark <robdclark@gmail.com> - 2015-10-17 20:50 +0200
                    Re: [GIT PULL] On-demand device probing Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2015-10-17 21:00 +0200
                      Re: [GIT PULL] On-demand device probing Rob Clark <robdclark@gmail.com> - 2015-10-17 21:40 +0200
                        Re: [GIT PULL] On-demand device probing Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2015-10-17 22:30 +0200
                    Re: [GIT PULL] On-demand device probing Noralf Trønnes <noralf@tronnes.org> - 2015-10-17 21:10 +0200
                      Re: [GIT PULL] On-demand device probing Rob Clark <robdclark@gmail.com> - 2015-10-17 21:50 +0200

#1246406 — [GIT PULL] On-demand device probing

Hi Rob,

here is the pull request you asked for, with no changes from the version
that I posted last to the list.

The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f:

Linux 4.3-rc1 (2015-09-12 16:35:56 -0700)

are available in the git repository at:

git+ssh://git.collabora.co.uk/git/user/tomeu/linux.git
on-demand-probes-for-next

for you to fetch changes up to 587402133fe433759d2d535e5d92ead87fd7f615:

of/platform: Defer probes of registered devices (2015-10-14 10:08:23 +0200)

----------------------------------------------------------------
Tomeu Vizoso (20):
driver core: handle -EPROBE_DEFER from bus_type.match()
ARM: amba: Move reading of periphid to amba_match()
of/platform: Point to struct device from device node
of: add function to allow probing a device from a OF node
gpio: Probe GPIO drivers on demand
pinctrl: Probe pinctrl devices on demand
regulator: core: Probe regulators on demand
drm: Probe panels on demand
drm/tegra: Probe dpaux devices on demand
i2c: core: Probe i2c adapters and devices on demand
pwm: Probe PWM chip devices on demand
backlight: Probe backlight devices on demand
usb: phy: Probe phy devices on demand
clk: Probe clk providers on demand
pinctrl: Probe pinctrl devices on demand
phy: core: Probe phy providers on demand
dma: of: Probe DMA controllers on demand
power-supply: Probe power supplies on demand
driver core: Allow deferring probes until late init
of/platform: Defer probes of registered devices

drivers/amba/bus.c | 88
++++++++++++++++++++++++++++++++++++++++++++++------------------------------------------
drivers/base/Kconfig | 18 ++++++++++++++++++
drivers/base/dd.c | 30 ++++++++++++++++++++++++++++--
drivers/clk/clk.c | 3 +++
drivers/dma/of-dma.c | 3 +++
drivers/gpio/gpiolib-of.c | 5 +++++
drivers/gpu/drm/drm_panel.c | 3 +++
drivers/gpu/drm/tegra/dpaux.c | 3 +++
drivers/i2c/i2c-core.c | 4 ++++
drivers/of/device.c | 61
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
drivers/of/platform.c | 30 ++++++++++++++++++------------
drivers/phy/phy-core.c | 3 +++
drivers/pinctrl/devicetree.c | 3 +++
drivers/power/power_supply_core.c | 3 +++
drivers/pwm/core.c | 3 +++
drivers/regulator/core.c | 2 ++
drivers/usb/phy/phy.c | 3 +++
drivers/video/backlight/backlight.c | 3 +++
include/linux/device.h | 4 +++-
include/linux/of.h | 1 +
include/linux/of_device.h | 3 +++
21 files changed, 219 insertions(+), 57 deletions(-)


Thanks,

Tomeu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1246453

[Multipart message — attachments visible in raw view] — view raw

On Wed, Oct 14, 2015 at 10:34:00AM +0200, Tomeu Vizoso wrote:

> git+ssh://git.collabora.co.uk/git/user/tomeu/linux.git
> on-demand-probes-for-next

In don't think that's the URL you intended to use (also everything looks
word wrapped here)?

[toc] | [prev] | [next] | [standalone]

#1247722

Hi,

this second pull request replaces the last references to device_initcall_sync with late_initcall, as noticed by Frank Rowand.

Also fixes the url of the git repo and the wrapping, as suggested by Mark Brown.

Thanks,

Tomeu

The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f:

  Linux 4.3-rc1 (2015-09-12 16:35:56 -0700)

are available in the git repository at:

  git://git.collabora.com/git/user/tomeu/linux.git on-demand-probes-for-next

for you to fetch changes up to c074fef5d36e1c27dfdf7474e23c01a1b044ff98:

  of/platform: Defer probes of registered devices (2015-10-15 13:25:47 +0200)

----------------------------------------------------------------
Tomeu Vizoso (20):
      driver core: handle -EPROBE_DEFER from bus_type.match()
      ARM: amba: Move reading of periphid to amba_match()
      of/platform: Point to struct device from device node
      of: add function to allow probing a device from a OF node
      gpio: Probe GPIO drivers on demand
      pinctrl: Probe pinctrl devices on demand
      regulator: core: Probe regulators on demand
      drm: Probe panels on demand
      drm/tegra: Probe dpaux devices on demand
      i2c: core: Probe i2c adapters and devices on demand
      pwm: Probe PWM chip devices on demand
      backlight: Probe backlight devices on demand
      usb: phy: Probe phy devices on demand
      clk: Probe clk providers on demand
      pinctrl: Probe pinctrl devices on demand
      phy: core: Probe phy providers on demand
      dma: of: Probe DMA controllers on demand
      power-supply: Probe power supplies on demand
      driver core: Allow deferring probes until late init
      of/platform: Defer probes of registered devices

 drivers/amba/bus.c                  | 88 +++++++++++++++++++------------------
 drivers/base/Kconfig                | 18 ++++++++
 drivers/base/dd.c                   | 30 ++++++++++++-
 drivers/clk/clk.c                   |  3 ++
 drivers/dma/of-dma.c                |  3 ++
 drivers/gpio/gpiolib-of.c           |  5 +++
 drivers/gpu/drm/drm_panel.c         |  3 ++
 drivers/gpu/drm/tegra/dpaux.c       |  3 ++
 drivers/i2c/i2c-core.c              |  4 ++
 drivers/of/device.c                 | 61 +++++++++++++++++++++++++
 drivers/of/platform.c               | 30 ++++++++-----
 drivers/phy/phy-core.c              |  3 ++
 drivers/pinctrl/devicetree.c        |  3 ++
 drivers/power/power_supply_core.c   |  3 ++
 drivers/pwm/core.c                  |  3 ++
 drivers/regulator/core.c            |  2 +
 drivers/usb/phy/phy.c               |  3 ++
 drivers/video/backlight/backlight.c |  3 ++
 include/linux/device.h              |  4 +-
 include/linux/of.h                  |  1 +
 include/linux/of_device.h           |  3 ++
 21 files changed, 219 insertions(+), 57 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1249157

Hi,

I've bisected boot failures in next-20151016 down to patches in this branch:

On Thu, Oct 15, 2015 at 4:42 AM, Tomeu Vizoso
<tomeu.vizoso@collabora.com> wrote:
> Tomeu Vizoso (20):
>       driver core: handle -EPROBE_DEFER from bus_type.match()

The machine it happened on was OMAP5UEVM:

http://arm-soc.lixom.net/bootlogs/next/next-20151016/omap5uevm-arm-omap2plus_defconfig.html

But I've also seen it on tegra2, that one bisected down to:

>      regulator: core: Probe regulators on demand

http://arm-soc.lixom.net/bootlogs/next/next-20151016/seaboard-arm-multi_v7_defconfig.html



-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1249339

On Fri, Oct 16, 2015 at 4:23 PM, Olof Johansson <olof@lixom.net> wrote:
> Hi,
>
> I've bisected boot failures in next-20151016 down to patches in this branch:
>
> On Thu, Oct 15, 2015 at 4:42 AM, Tomeu Vizoso
> <tomeu.vizoso@collabora.com> wrote:
>> Tomeu Vizoso (20):
>>       driver core: handle -EPROBE_DEFER from bus_type.match()
>
> The machine it happened on was OMAP5UEVM:
>
> http://arm-soc.lixom.net/bootlogs/next/next-20151016/omap5uevm-arm-omap2plus_defconfig.html

So this one is because the MMC node numbering changed. I don't know
how to fix that other than with aliases, but that doesn't solve
backwards compatibility.


> But I've also seen it on tegra2, that one bisected down to:
>
>>      regulator: core: Probe regulators on demand
>
> http://arm-soc.lixom.net/bootlogs/next/next-20151016/seaboard-arm-multi_v7_defconfig.html

This one you need a rootwait I think. The MMC scanning is not
guaranteed to be done before the rootfs mounting AFAIK. There may be
other problems, but we can't see them since it panics.

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1249278

On Wed, Oct 14, 2015 at 10:34:00AM +0200, Tomeu Vizoso wrote:
> Hi Rob,
> 
> here is the pull request you asked for, with no changes from the version
> that I posted last to the list.
> 
> The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f:
> 
> Linux 4.3-rc1 (2015-09-12 16:35:56 -0700)
> 
> are available in the git repository at:
> 
> git+ssh://git.collabora.co.uk/git/user/tomeu/linux.git
> on-demand-probes-for-next

That's not a signed tag :(

Anyway, I REALLY don't like this series (sorry for the delay in
reviewing them, normally I trust Rob's judgement...)

I can't see adding calls like this all over the tree just to solve a
bus-specific problem, you are adding of_* calls where they aren't
needed, or wanted, at all.

What is the root-problem of your delay in device probing?  I read your
last patch series and I can't seem to figure out what the issue is that
this is solving in any "better" way from the existing deferred probing.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1249337

On Sat, Oct 17, 2015 at 1:57 AM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Wed, Oct 14, 2015 at 10:34:00AM +0200, Tomeu Vizoso wrote:
>> Hi Rob,
>>
>> here is the pull request you asked for, with no changes from the version
>> that I posted last to the list.
>>
>> The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f:
>>
>> Linux 4.3-rc1 (2015-09-12 16:35:56 -0700)
>>
>> are available in the git repository at:
>>
>> git+ssh://git.collabora.co.uk/git/user/tomeu/linux.git
>> on-demand-probes-for-next
>
> That's not a signed tag :(
>
> Anyway, I REALLY don't like this series (sorry for the delay in
> reviewing them, normally I trust Rob's judgement...)

We've seen a lot of attempts here. This is really the best solution so
far in that it is simple, uses existing data from DT, and was low risk
for breaking platforms (at least I thought it would be). Anyway,
getting more exposure is why I've put it into -next.

> I can't see adding calls like this all over the tree just to solve a
> bus-specific problem, you are adding of_* calls where they aren't
> needed, or wanted, at all.

I think Linus W, Mark B, and I all said a similar thing initially in
that dependencies should be handled in the driver core. We went down
the path of making this not firmware (aka bus) specific and an earlier
version had just that (with fwnode_* calls). That turned out to be
pointless as the calling locations were almost always in DT specific
code anyway. If you notice, the calls are next to other DT specific
calls generally (usually a "get"). So yes, I'd prefer not to have to
touch every subsystem, but we had to do that anyway to add DT support.

We've generally split the DT code into the core (in drivers/of) and
the binding specific (in subsystems). Extracting dependency
information the DT is going to require binding specific knowledge, so
subsystem changes are probably unavoidable.

The alternative is we put binding specific knowledge into the core DT
code to parse dependencies.

> What is the root-problem of your delay in device probing?  I read your
> last patch series and I can't seem to figure out what the issue is that
> this is solving in any "better" way from the existing deferred probing.

It saves 2 seconds in the boot time as re-probing takes time. That
alone seems compelling to me.

Another downside to deferred probing is you have to touch every driver
and subsystem to support it. This contains the problem to the
subsystems.

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1249340

On Sat, Oct 17, 2015 at 10:04:55AM -0500, Rob Herring wrote:
> On Sat, Oct 17, 2015 at 1:57 AM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > On Wed, Oct 14, 2015 at 10:34:00AM +0200, Tomeu Vizoso wrote:
> >> Hi Rob,
> >>
> >> here is the pull request you asked for, with no changes from the version
> >> that I posted last to the list.
> >>
> >> The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f:
> >>
> >> Linux 4.3-rc1 (2015-09-12 16:35:56 -0700)
> >>
> >> are available in the git repository at:
> >>
> >> git+ssh://git.collabora.co.uk/git/user/tomeu/linux.git
> >> on-demand-probes-for-next
> >
> > That's not a signed tag :(
> >
> > Anyway, I REALLY don't like this series (sorry for the delay in
> > reviewing them, normally I trust Rob's judgement...)
> 
> We've seen a lot of attempts here. This is really the best solution so
> far in that it is simple, uses existing data from DT, and was low risk
> for breaking platforms (at least I thought it would be). Anyway,
> getting more exposure is why I've put it into -next.

Exposure is good, now we know it breaks some builds, which was useful :)

> > I can't see adding calls like this all over the tree just to solve a
> > bus-specific problem, you are adding of_* calls where they aren't
> > needed, or wanted, at all.
> 
> I think Linus W, Mark B, and I all said a similar thing initially in
> that dependencies should be handled in the driver core. We went down
> the path of making this not firmware (aka bus) specific and an earlier
> version had just that (with fwnode_* calls). That turned out to be
> pointless as the calling locations were almost always in DT specific
> code anyway. If you notice, the calls are next to other DT specific
> calls generally (usually a "get"). So yes, I'd prefer not to have to
> touch every subsystem, but we had to do that anyway to add DT support.

If they are "next" to a call like that, why not put it in that call?  I
really object to having to "sprinkle" this all over the kernel, for no
obvious reason why that is happening at all (look at the USB patch for
one such example.)

> We've generally split the DT code into the core (in drivers/of) and
> the binding specific (in subsystems). Extracting dependency
> information the DT is going to require binding specific knowledge, so
> subsystem changes are probably unavoidable.
> 
> The alternative is we put binding specific knowledge into the core DT
> code to parse dependencies.
> 
> > What is the root-problem of your delay in device probing?  I read your
> > last patch series and I can't seem to figure out what the issue is that
> > this is solving in any "better" way from the existing deferred probing.
> 
> It saves 2 seconds in the boot time as re-probing takes time. That
> alone seems compelling to me.

2 seconds is _forever_, and really seems like some other driver is
sleeping and causing this problem.  What does the bootlog time-chart say
is really causing this long delay?  There's no way we are stuck in some
sort of logic loop for that long (i.e. having to walk the list of
devices somehow.)  This sounds like a driver-specific problem that is
being worked around by having to touch all subsystems, which isn't nice.

Hint, we didn't have to do this type of thing to solve boot delays on
x86 when we had hardware that was slow to initialize, why should DT be
special?  :)

> Another downside to deferred probing is you have to touch every driver
> and subsystem to support it. This contains the problem to the
> subsystems.

But we have deferred probing already, only those drivers that need/want
it have to do anything, why create yet-another model here?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1249355

On Sat, Oct 17, 2015 at 10:47 AM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Sat, Oct 17, 2015 at 10:04:55AM -0500, Rob Herring wrote:
>> On Sat, Oct 17, 2015 at 1:57 AM, Greg Kroah-Hartman
>> <gregkh@linuxfoundation.org> wrote:
>> > On Wed, Oct 14, 2015 at 10:34:00AM +0200, Tomeu Vizoso wrote:
>> >> Hi Rob,
>> >>
>> >> here is the pull request you asked for, with no changes from the version
>> >> that I posted last to the list.
>> >>
>> >> The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f:
>> >>
>> >> Linux 4.3-rc1 (2015-09-12 16:35:56 -0700)
>> >>
>> >> are available in the git repository at:
>> >>
>> >> git+ssh://git.collabora.co.uk/git/user/tomeu/linux.git
>> >> on-demand-probes-for-next
>> >
>> > That's not a signed tag :(
>> >
>> > Anyway, I REALLY don't like this series (sorry for the delay in
>> > reviewing them, normally I trust Rob's judgement...)
>>
>> We've seen a lot of attempts here. This is really the best solution so
>> far in that it is simple, uses existing data from DT, and was low risk
>> for breaking platforms (at least I thought it would be). Anyway,
>> getting more exposure is why I've put it into -next.
>
> Exposure is good, now we know it breaks some builds, which was useful :)

Now that I've looked at them, they are somewhat questionable failures.
They do show the fragile nature of probe ordering and the implicit
dependencies we have.

>> > I can't see adding calls like this all over the tree just to solve a
>> > bus-specific problem, you are adding of_* calls where they aren't
>> > needed, or wanted, at all.
>>
>> I think Linus W, Mark B, and I all said a similar thing initially in
>> that dependencies should be handled in the driver core. We went down
>> the path of making this not firmware (aka bus) specific and an earlier
>> version had just that (with fwnode_* calls). That turned out to be
>> pointless as the calling locations were almost always in DT specific
>> code anyway. If you notice, the calls are next to other DT specific
>> calls generally (usually a "get"). So yes, I'd prefer not to have to
>> touch every subsystem, but we had to do that anyway to add DT support.
>
> If they are "next" to a call like that, why not put it in that call?  I
> really object to having to "sprinkle" this all over the kernel, for no
> obvious reason why that is happening at all (look at the USB patch for
> one such example.)

Looking at it again, they are in DT specific code already. The USB one
is in devm_usb_get_phy_by_node() which is a DT specific call.

>> We've generally split the DT code into the core (in drivers/of) and
>> the binding specific (in subsystems). Extracting dependency
>> information the DT is going to require binding specific knowledge, so
>> subsystem changes are probably unavoidable.
>>
>> The alternative is we put binding specific knowledge into the core DT
>> code to parse dependencies.
>>
>> > What is the root-problem of your delay in device probing?  I read your
>> > last patch series and I can't seem to figure out what the issue is that
>> > this is solving in any "better" way from the existing deferred probing.
>>
>> It saves 2 seconds in the boot time as re-probing takes time. That
>> alone seems compelling to me.
>
> 2 seconds is _forever_, and really seems like some other driver is
> sleeping and causing this problem.  What does the bootlog time-chart say
> is really causing this long delay?  There's no way we are stuck in some
> sort of logic loop for that long (i.e. having to walk the list of
> devices somehow.)  This sounds like a driver-specific problem that is
> being worked around by having to touch all subsystems, which isn't nice.

I don't think it is one driver as the improvement is seen on multiple
platforms. I'll let Tomeu comment further on where the time was spent.

> Hint, we didn't have to do this type of thing to solve boot delays on
> x86 when we had hardware that was slow to initialize, why should DT be
> special?  :)

x86 did not need deferred probe either (though we probably can find
some initcall ordering hacks). This is an embedded problem, not a DT
problem.

I'm guessing the time is a matter of probing and undoing the probes
rather than slow h/w. We could maybe improve things by making sure
drivers move what they defer on to the beginning of probe, but that
seems like a horrible, fragile hack.

>> Another downside to deferred probing is you have to touch every driver
>> and subsystem to support it. This contains the problem to the
>> subsystems.
>
> But we have deferred probing already, only those drivers that need/want
> it have to do anything, why create yet-another model here?

Yes, the only ones needing it are drivers dependent on clocks, gpio,
regulators, pwm, pin-ctrl, dma, etc. That's not a small number. This
is a side benefit and wouldn't take this series for that reason alone.

I've used the deferred probing is good enough argument myself on
previous attempts. The boot time improvements convinced me it is not
good enough except for simple cases.

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1249361

On Sat, Oct 17, 2015 at 11:28:29AM -0500, Rob Herring wrote:
> On Sat, Oct 17, 2015 at 10:47 AM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > On Sat, Oct 17, 2015 at 10:04:55AM -0500, Rob Herring wrote:
> >> On Sat, Oct 17, 2015 at 1:57 AM, Greg Kroah-Hartman
> >> <gregkh@linuxfoundation.org> wrote:
> >> > On Wed, Oct 14, 2015 at 10:34:00AM +0200, Tomeu Vizoso wrote:
> >> >> Hi Rob,
> >> >>
> >> >> here is the pull request you asked for, with no changes from the version
> >> >> that I posted last to the list.
> >> >>
> >> >> The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f:
> >> >>
> >> >> Linux 4.3-rc1 (2015-09-12 16:35:56 -0700)
> >> >>
> >> >> are available in the git repository at:
> >> >>
> >> >> git+ssh://git.collabora.co.uk/git/user/tomeu/linux.git
> >> >> on-demand-probes-for-next
> >> >
> >> > That's not a signed tag :(
> >> >
> >> > Anyway, I REALLY don't like this series (sorry for the delay in
> >> > reviewing them, normally I trust Rob's judgement...)
> >>
> >> We've seen a lot of attempts here. This is really the best solution so
> >> far in that it is simple, uses existing data from DT, and was low risk
> >> for breaking platforms (at least I thought it would be). Anyway,
> >> getting more exposure is why I've put it into -next.
> >
> > Exposure is good, now we know it breaks some builds, which was useful :)
> 
> Now that I've looked at them, they are somewhat questionable failures.
> They do show the fragile nature of probe ordering and the implicit
> dependencies we have.
> 
> >> > I can't see adding calls like this all over the tree just to solve a
> >> > bus-specific problem, you are adding of_* calls where they aren't
> >> > needed, or wanted, at all.
> >>
> >> I think Linus W, Mark B, and I all said a similar thing initially in
> >> that dependencies should be handled in the driver core. We went down
> >> the path of making this not firmware (aka bus) specific and an earlier
> >> version had just that (with fwnode_* calls). That turned out to be
> >> pointless as the calling locations were almost always in DT specific
> >> code anyway. If you notice, the calls are next to other DT specific
> >> calls generally (usually a "get"). So yes, I'd prefer not to have to
> >> touch every subsystem, but we had to do that anyway to add DT support.
> >
> > If they are "next" to a call like that, why not put it in that call?  I
> > really object to having to "sprinkle" this all over the kernel, for no
> > obvious reason why that is happening at all (look at the USB patch for
> > one such example.)
> 
> Looking at it again, they are in DT specific code already. The USB one
> is in devm_usb_get_phy_by_node() which is a DT specific call.

But that's not very obvious, right?  Especially given that you now have
to add a new .h file, which implies that suddenly this file is now
touching a new subsystem.

> >> We've generally split the DT code into the core (in drivers/of) and
> >> the binding specific (in subsystems). Extracting dependency
> >> information the DT is going to require binding specific knowledge, so
> >> subsystem changes are probably unavoidable.
> >>
> >> The alternative is we put binding specific knowledge into the core DT
> >> code to parse dependencies.
> >>
> >> > What is the root-problem of your delay in device probing?  I read your
> >> > last patch series and I can't seem to figure out what the issue is that
> >> > this is solving in any "better" way from the existing deferred probing.
> >>
> >> It saves 2 seconds in the boot time as re-probing takes time. That
> >> alone seems compelling to me.
> >
> > 2 seconds is _forever_, and really seems like some other driver is
> > sleeping and causing this problem.  What does the bootlog time-chart say
> > is really causing this long delay?  There's no way we are stuck in some
> > sort of logic loop for that long (i.e. having to walk the list of
> > devices somehow.)  This sounds like a driver-specific problem that is
> > being worked around by having to touch all subsystems, which isn't nice.
> 
> I don't think it is one driver as the improvement is seen on multiple
> platforms. I'll let Tomeu comment further on where the time was spent.

That would be good to know, as 2 seconds is forever (my whole machine
boots to a gnome login faster than that.)

> > Hint, we didn't have to do this type of thing to solve boot delays on
> > x86 when we had hardware that was slow to initialize, why should DT be
> > special?  :)
> 
> x86 did not need deferred probe either (though we probably can find
> some initcall ordering hacks). This is an embedded problem, not a DT
> problem.

x86 is embedded :)

> I'm guessing the time is a matter of probing and undoing the probes
> rather than slow h/w. We could maybe improve things by making sure
> drivers move what they defer on to the beginning of probe, but that
> seems like a horrible, fragile hack.

How can calling probe and failing cause 2 seconds?  How many different
probe calls are failing here?  Again, a boot log graph would be great to
see as it will show the root cause, not just guessing at this.

> >> Another downside to deferred probing is you have to touch every driver
> >> and subsystem to support it. This contains the problem to the
> >> subsystems.
> >
> > But we have deferred probing already, only those drivers that need/want
> > it have to do anything, why create yet-another model here?
> 
> Yes, the only ones needing it are drivers dependent on clocks, gpio,
> regulators, pwm, pin-ctrl, dma, etc. That's not a small number. This
> is a side benefit and wouldn't take this series for that reason alone.
> 
> I've used the deferred probing is good enough argument myself on
> previous attempts. The boot time improvements convinced me it is not
> good enough except for simple cases.

Then let's fix deferred probing to do it "correctly", let's not add
yet-another-way-to-probe instead please, as we will be forever
sprinkling these calls around subsystems in a cargo-cult-like manner for
forever.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1249406

On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>> I'm guessing the time is a matter of probing and undoing the probes
>> rather than slow h/w. We could maybe improve things by making sure
>> drivers move what they defer on to the beginning of probe, but that
>> seems like a horrible, fragile hack.
>
> How can calling probe and failing cause 2 seconds?  How many different
> probe calls are failing here?  Again, a boot log graph would be great to
> see as it will show the root cause, not just guessing at this.


just fwiw, but when you have a driver that depends on several other
drivers (which in turn depend on other drivers and so on), the amount
of probe-defer we end up seeing is pretty comical.  Yeah, there
probably is some room to optimize by juggling around order drivers do
things in probe.  But that doesn't solve the fundamental problem with
the current state, about probe order having no clue about
dependencies..

BR,
-R
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1249407

On Sat, Oct 17, 2015 at 01:54:43PM -0400, Rob Clark wrote:
> On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >> I'm guessing the time is a matter of probing and undoing the probes
> >> rather than slow h/w. We could maybe improve things by making sure
> >> drivers move what they defer on to the beginning of probe, but that
> >> seems like a horrible, fragile hack.
> >
> > How can calling probe and failing cause 2 seconds?  How many different
> > probe calls are failing here?  Again, a boot log graph would be great to
> > see as it will show the root cause, not just guessing at this.
> 
> 
> just fwiw, but when you have a driver that depends on several other
> drivers (which in turn depend on other drivers and so on), the amount
> of probe-defer we end up seeing is pretty comical.  Yeah, there
> probably is some room to optimize by juggling around order drivers do
> things in probe.  But that doesn't solve the fundamental problem with
> the current state, about probe order having no clue about
> dependencies..

I can imagine it is a lot of iterations, but how long does it really
take?  How many different devices are involved that it takes multiple
loops in order to finally work out the correct order?  Where is the time
delays here, just calling probe() and having it instantly return
shouldn't take all that long.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1249417

On Sat, Oct 17, 2015 at 2:27 PM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Sat, Oct 17, 2015 at 01:54:43PM -0400, Rob Clark wrote:
>> On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman
>> <gregkh@linuxfoundation.org> wrote:
>> >> I'm guessing the time is a matter of probing and undoing the probes
>> >> rather than slow h/w. We could maybe improve things by making sure
>> >> drivers move what they defer on to the beginning of probe, but that
>> >> seems like a horrible, fragile hack.
>> >
>> > How can calling probe and failing cause 2 seconds?  How many different
>> > probe calls are failing here?  Again, a boot log graph would be great to
>> > see as it will show the root cause, not just guessing at this.
>>
>>
>> just fwiw, but when you have a driver that depends on several other
>> drivers (which in turn depend on other drivers and so on), the amount
>> of probe-defer we end up seeing is pretty comical.  Yeah, there
>> probably is some room to optimize by juggling around order drivers do
>> things in probe.  But that doesn't solve the fundamental problem with
>> the current state, about probe order having no clue about
>> dependencies..
>
> I can imagine it is a lot of iterations, but how long does it really
> take?  How many different devices are involved that it takes multiple
> loops in order to finally work out the correct order?  Where is the time
> delays here, just calling probe() and having it instantly return
> shouldn't take all that long.

offhand, I think the dependencies go at *least* three levels deep..
I'd say, from memory, I see drm/msm taking at least 5 or 6 tries to
get all the way through requesting it's various different
regulators/clks/gpios.  I hadn't really paid attention to how many
tries the drivers I depend on go through.  (Of those, I take clks from
two different clk drivers (which have dependency on a 3rd clk driver),
and regulators and gpio's come from at least two places, which in turn
have dependencies on clks, etc.)  I don't have really good hard
numbers handy (since my observations of this are w/ console over uart
which effects timings, and so I see it taking much longer than 2sec)..
but the 2sec figure that Tomeu mentioned seemed pretty plausible to
me.

I can try to get better #'s... I should have my kernel hat on at least
some of the time next week.. but the 2sec figure didn't seem
unrealistic to me.

Just as an aside, the amount of probe-defer adds quite a lot of noise
when you are trying to debug why some driver doesn't probe
successfully.  Which itself would be a nice reason to do something
more clever..

BR,
-R


> thanks,
>
> greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1249422

On Sat, Oct 17, 2015 at 02:45:34PM -0400, Rob Clark wrote:
> On Sat, Oct 17, 2015 at 2:27 PM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > On Sat, Oct 17, 2015 at 01:54:43PM -0400, Rob Clark wrote:
> >> On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman
> >> <gregkh@linuxfoundation.org> wrote:
> >> >> I'm guessing the time is a matter of probing and undoing the probes
> >> >> rather than slow h/w. We could maybe improve things by making sure
> >> >> drivers move what they defer on to the beginning of probe, but that
> >> >> seems like a horrible, fragile hack.
> >> >
> >> > How can calling probe and failing cause 2 seconds?  How many different
> >> > probe calls are failing here?  Again, a boot log graph would be great to
> >> > see as it will show the root cause, not just guessing at this.
> >>
> >>
> >> just fwiw, but when you have a driver that depends on several other
> >> drivers (which in turn depend on other drivers and so on), the amount
> >> of probe-defer we end up seeing is pretty comical.  Yeah, there
> >> probably is some room to optimize by juggling around order drivers do
> >> things in probe.  But that doesn't solve the fundamental problem with
> >> the current state, about probe order having no clue about
> >> dependencies..
> >
> > I can imagine it is a lot of iterations, but how long does it really
> > take?  How many different devices are involved that it takes multiple
> > loops in order to finally work out the correct order?  Where is the time
> > delays here, just calling probe() and having it instantly return
> > shouldn't take all that long.
> 
> offhand, I think the dependencies go at *least* three levels deep..
> I'd say, from memory, I see drm/msm taking at least 5 or 6 tries to
> get all the way through requesting it's various different
> regulators/clks/gpios.

And how long does that really take?  Numbers please :)

> I hadn't really paid attention to how many
> tries the drivers I depend on go through.  (Of those, I take clks from
> two different clk drivers (which have dependency on a 3rd clk driver),
> and regulators and gpio's come from at least two places, which in turn
> have dependencies on clks, etc.)  I don't have really good hard
> numbers handy (since my observations of this are w/ console over uart
> which effects timings, and so I see it taking much longer than 2sec)..
> but the 2sec figure that Tomeu mentioned seemed pretty plausible to
> me.
> 
> I can try to get better #'s... I should have my kernel hat on at least
> some of the time next week.. but the 2sec figure didn't seem
> unrealistic to me.

Based on the time it takes a modern laptop to boot, 2 seconds is
forever, there has to be something else going on here other than just
calling probe() a bunch of times.  Please use the tools we have to
determine this before trying to change the driver core.

> Just as an aside, the amount of probe-defer adds quite a lot of noise
> when you are trying to debug why some driver doesn't probe
> successfully.  Which itself would be a nice reason to do something
> more clever..

People seem to not like the noise, so let's turn off those messages,
that should speed things up :)

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1249436

On Sat, Oct 17, 2015 at 2:59 PM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Sat, Oct 17, 2015 at 02:45:34PM -0400, Rob Clark wrote:
>> On Sat, Oct 17, 2015 at 2:27 PM, Greg Kroah-Hartman
>> <gregkh@linuxfoundation.org> wrote:
>> > On Sat, Oct 17, 2015 at 01:54:43PM -0400, Rob Clark wrote:
>> >> On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman
>> >> <gregkh@linuxfoundation.org> wrote:
>> >> >> I'm guessing the time is a matter of probing and undoing the probes
>> >> >> rather than slow h/w. We could maybe improve things by making sure
>> >> >> drivers move what they defer on to the beginning of probe, but that
>> >> >> seems like a horrible, fragile hack.
>> >> >
>> >> > How can calling probe and failing cause 2 seconds?  How many different
>> >> > probe calls are failing here?  Again, a boot log graph would be great to
>> >> > see as it will show the root cause, not just guessing at this.
>> >>
>> >>
>> >> just fwiw, but when you have a driver that depends on several other
>> >> drivers (which in turn depend on other drivers and so on), the amount
>> >> of probe-defer we end up seeing is pretty comical.  Yeah, there
>> >> probably is some room to optimize by juggling around order drivers do
>> >> things in probe.  But that doesn't solve the fundamental problem with
>> >> the current state, about probe order having no clue about
>> >> dependencies..
>> >
>> > I can imagine it is a lot of iterations, but how long does it really
>> > take?  How many different devices are involved that it takes multiple
>> > loops in order to finally work out the correct order?  Where is the time
>> > delays here, just calling probe() and having it instantly return
>> > shouldn't take all that long.
>>
>> offhand, I think the dependencies go at *least* three levels deep..
>> I'd say, from memory, I see drm/msm taking at least 5 or 6 tries to
>> get all the way through requesting it's various different
>> regulators/clks/gpios.
>
> And how long does that really take?  Numbers please :)
>
>> I hadn't really paid attention to how many
>> tries the drivers I depend on go through.  (Of those, I take clks from
>> two different clk drivers (which have dependency on a 3rd clk driver),
>> and regulators and gpio's come from at least two places, which in turn
>> have dependencies on clks, etc.)  I don't have really good hard
>> numbers handy (since my observations of this are w/ console over uart
>> which effects timings, and so I see it taking much longer than 2sec)..
>> but the 2sec figure that Tomeu mentioned seemed pretty plausible to
>> me.
>>
>> I can try to get better #'s... I should have my kernel hat on at least
>> some of the time next week.. but the 2sec figure didn't seem
>> unrealistic to me.
>
> Based on the time it takes a modern laptop to boot, 2 seconds is
> forever, there has to be something else going on here other than just
> calling probe() a bunch of times.  Please use the tools we have to
> determine this before trying to change the driver core.

yes, I am aware of the tools.. although so far I spend most of my time
just trying to get things working in the first place ;-)

All I was trying to point out was that Tomeu's figures didn't really
seem unrealistic.  I mean, given that the average SoC driver probably
depends on at least one clock and at least one regulator, having to
probe each driver at least twice seems plausible.  And that having a
noticeable effect on boot time doesn't seem surprising.  I'm not sure
that saying 'modern laptop can boot in 2sec' adds much to the
discussion since I don't think you have quite so much interdependency
between devices vs random probe order.  I have seen arm devices boot
to UI in similar times, but that was pre-devicetree days.

I expect Tomeu has some better number.. if not I can collect some.

>> Just as an aside, the amount of probe-defer adds quite a lot of noise
>> when you are trying to debug why some driver doesn't probe
>> successfully.  Which itself would be a nice reason to do something
>> more clever..
>
> People seem to not like the noise, so let's turn off those messages,
> that should speed things up :)

heh, except for when you are trying to debug what is missing
preventing the driver you depend on from probing ;-)

BR,
-R
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1249444

On Sat, Oct 17, 2015 at 03:39:20PM -0400, Rob Clark wrote:
> On Sat, Oct 17, 2015 at 2:59 PM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > On Sat, Oct 17, 2015 at 02:45:34PM -0400, Rob Clark wrote:
> >> On Sat, Oct 17, 2015 at 2:27 PM, Greg Kroah-Hartman
> >> <gregkh@linuxfoundation.org> wrote:
> >> > On Sat, Oct 17, 2015 at 01:54:43PM -0400, Rob Clark wrote:
> >> >> On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman
> >> >> <gregkh@linuxfoundation.org> wrote:
> >> >> >> I'm guessing the time is a matter of probing and undoing the probes
> >> >> >> rather than slow h/w. We could maybe improve things by making sure
> >> >> >> drivers move what they defer on to the beginning of probe, but that
> >> >> >> seems like a horrible, fragile hack.
> >> >> >
> >> >> > How can calling probe and failing cause 2 seconds?  How many different
> >> >> > probe calls are failing here?  Again, a boot log graph would be great to
> >> >> > see as it will show the root cause, not just guessing at this.
> >> >>
> >> >>
> >> >> just fwiw, but when you have a driver that depends on several other
> >> >> drivers (which in turn depend on other drivers and so on), the amount
> >> >> of probe-defer we end up seeing is pretty comical.  Yeah, there
> >> >> probably is some room to optimize by juggling around order drivers do
> >> >> things in probe.  But that doesn't solve the fundamental problem with
> >> >> the current state, about probe order having no clue about
> >> >> dependencies..
> >> >
> >> > I can imagine it is a lot of iterations, but how long does it really
> >> > take?  How many different devices are involved that it takes multiple
> >> > loops in order to finally work out the correct order?  Where is the time
> >> > delays here, just calling probe() and having it instantly return
> >> > shouldn't take all that long.
> >>
> >> offhand, I think the dependencies go at *least* three levels deep..
> >> I'd say, from memory, I see drm/msm taking at least 5 or 6 tries to
> >> get all the way through requesting it's various different
> >> regulators/clks/gpios.
> >
> > And how long does that really take?  Numbers please :)
> >
> >> I hadn't really paid attention to how many
> >> tries the drivers I depend on go through.  (Of those, I take clks from
> >> two different clk drivers (which have dependency on a 3rd clk driver),
> >> and regulators and gpio's come from at least two places, which in turn
> >> have dependencies on clks, etc.)  I don't have really good hard
> >> numbers handy (since my observations of this are w/ console over uart
> >> which effects timings, and so I see it taking much longer than 2sec)..
> >> but the 2sec figure that Tomeu mentioned seemed pretty plausible to
> >> me.
> >>
> >> I can try to get better #'s... I should have my kernel hat on at least
> >> some of the time next week.. but the 2sec figure didn't seem
> >> unrealistic to me.
> >
> > Based on the time it takes a modern laptop to boot, 2 seconds is
> > forever, there has to be something else going on here other than just
> > calling probe() a bunch of times.  Please use the tools we have to
> > determine this before trying to change the driver core.
> 
> yes, I am aware of the tools.. although so far I spend most of my time
> just trying to get things working in the first place ;-)

And that's where most people stop, if you want to make it fast, you have
to put in more effort, sorry.  Don't expect the driver core to work
around driver bugs for you.

> All I was trying to point out was that Tomeu's figures didn't really
> seem unrealistic.  I mean, given that the average SoC driver probably
> depends on at least one clock and at least one regulator, having to
> probe each driver at least twice seems plausible.  And that having a
> noticeable effect on boot time doesn't seem surprising.  I'm not sure
> that saying 'modern laptop can boot in 2sec' adds much to the
> discussion since I don't think you have quite so much interdependency
> between devices vs random probe order.  I have seen arm devices boot
> to UI in similar times, but that was pre-devicetree days.

2 extra probes add a second to the boot time?  Those sound like really
broken drivers to me :)

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1249424

Den 17.10.2015 20:45, skrev Rob Clark:
> On Sat, Oct 17, 2015 at 2:27 PM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
>> On Sat, Oct 17, 2015 at 01:54:43PM -0400, Rob Clark wrote:
>>> On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman
>>> <gregkh@linuxfoundation.org> wrote:
>>>>> I'm guessing the time is a matter of probing and undoing the probes
>>>>> rather than slow h/w. We could maybe improve things by making sure
>>>>> drivers move what they defer on to the beginning of probe, but that
>>>>> seems like a horrible, fragile hack.
>>>> How can calling probe and failing cause 2 seconds?  How many different
>>>> probe calls are failing here?  Again, a boot log graph would be great to
>>>> see as it will show the root cause, not just guessing at this.
>>>
>>> just fwiw, but when you have a driver that depends on several other
>>> drivers (which in turn depend on other drivers and so on), the amount
>>> of probe-defer we end up seeing is pretty comical.  Yeah, there
>>> probably is some room to optimize by juggling around order drivers do
>>> things in probe.  But that doesn't solve the fundamental problem with
>>> the current state, about probe order having no clue about
>>> dependencies..
>> I can imagine it is a lot of iterations, but how long does it really
>> take?  How many different devices are involved that it takes multiple
>> loops in order to finally work out the correct order?  Where is the time
>> delays here, just calling probe() and having it instantly return
>> shouldn't take all that long.
> offhand, I think the dependencies go at *least* three levels deep..
> I'd say, from memory, I see drm/msm taking at least 5 or 6 tries to
> get all the way through requesting it's various different
> regulators/clks/gpios.  I hadn't really paid attention to how many
> tries the drivers I depend on go through.  (Of those, I take clks from
> two different clk drivers (which have dependency on a 3rd clk driver),
> and regulators and gpio's come from at least two places, which in turn
> have dependencies on clks, etc.)  I don't have really good hard
> numbers handy (since my observations of this are w/ console over uart
> which effects timings, and so I see it taking much longer than 2sec)..
> but the 2sec figure that Tomeu mentioned seemed pretty plausible to
> me.
>
> I can try to get better #'s... I should have my kernel hat on at least
> some of the time next week.. but the 2sec figure didn't seem
> unrealistic to me.

Are you saying that the total boot time is increased by 2 sec due to
deferred probing, or that display initialization is happening 2 sec
after it's first try?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1249439

On Sat, Oct 17, 2015 at 3:04 PM, Noralf Trønnes <noralf@tronnes.org> wrote:
>
> Den 17.10.2015 20:45, skrev Rob Clark:
>>
>> On Sat, Oct 17, 2015 at 2:27 PM, Greg Kroah-Hartman
>> <gregkh@linuxfoundation.org> wrote:
>>>
>>> On Sat, Oct 17, 2015 at 01:54:43PM -0400, Rob Clark wrote:
>>>>
>>>> On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman
>>>> <gregkh@linuxfoundation.org> wrote:
>>>>>>
>>>>>> I'm guessing the time is a matter of probing and undoing the probes
>>>>>> rather than slow h/w. We could maybe improve things by making sure
>>>>>> drivers move what they defer on to the beginning of probe, but that
>>>>>> seems like a horrible, fragile hack.
>>>>>
>>>>> How can calling probe and failing cause 2 seconds?  How many different
>>>>> probe calls are failing here?  Again, a boot log graph would be great
>>>>> to
>>>>> see as it will show the root cause, not just guessing at this.
>>>>
>>>>
>>>> just fwiw, but when you have a driver that depends on several other
>>>> drivers (which in turn depend on other drivers and so on), the amount
>>>> of probe-defer we end up seeing is pretty comical.  Yeah, there
>>>> probably is some room to optimize by juggling around order drivers do
>>>> things in probe.  But that doesn't solve the fundamental problem with
>>>> the current state, about probe order having no clue about
>>>> dependencies..
>>>
>>> I can imagine it is a lot of iterations, but how long does it really
>>> take?  How many different devices are involved that it takes multiple
>>> loops in order to finally work out the correct order?  Where is the time
>>> delays here, just calling probe() and having it instantly return
>>> shouldn't take all that long.
>>
>> offhand, I think the dependencies go at *least* three levels deep..
>> I'd say, from memory, I see drm/msm taking at least 5 or 6 tries to
>> get all the way through requesting it's various different
>> regulators/clks/gpios.  I hadn't really paid attention to how many
>> tries the drivers I depend on go through.  (Of those, I take clks from
>> two different clk drivers (which have dependency on a 3rd clk driver),
>> and regulators and gpio's come from at least two places, which in turn
>> have dependencies on clks, etc.)  I don't have really good hard
>> numbers handy (since my observations of this are w/ console over uart
>> which effects timings, and so I see it taking much longer than 2sec)..
>> but the 2sec figure that Tomeu mentioned seemed pretty plausible to
>> me.
>>
>> I can try to get better #'s... I should have my kernel hat on at least
>> some of the time next week.. but the 2sec figure didn't seem
>> unrealistic to me.
>
>
> Are you saying that the total boot time is increased by 2 sec due to
> deferred probing, or that display initialization is happening 2 sec
> after it's first try?
>

The 2sec figure was from Tomeu, but I guess display should be probed
in first pass through list of devices (and ofc deferring the first
time), I'll say "probably both"..

BR,
-R
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web