Re: [GIT PULL] On-demand device probing

2015-10-26 Thread Tomeu Vizoso 
On 26 October 2015 at 11:51, Michael Turquette  wrote:
> Quoting Rafael J. Wysocki (2015-10-25 06:54:39)
>> On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown  wrote:
>> > On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote:
>> >
>> >> Well, I'm not quite sure why exactly everyone is so focused on probing 
>> >> here.
>> >
>> > Probe deferral is really noisy even if it's working fine on a given
>> > system so it's constantly being highlighted to people in a way that
>> > other issues aren't if you're not directly having problems.
>> >
>> > There's also the understanding people had that the order things get
>> > bound changes the ordering for some of the other cases (perhaps it's a
>> > good idea to do that, it seems likely to be sensible?).
>>
>> But it really doesn't do that.  Also making it do so doesn't help much
>> in the cases where things can happen asynchronously (system
>> suspend/resume, runtime PM).
>>
>> If, instead, there was a way to specify a functional dependency at the
>> device registration time, it might be used to change the order of
>> everything relevant, including probe.  That should help to reduce the
>> noise you're referring to.
>
> Taking it a step further, if functional dependencies were understood at
> link-time then we could optimize link order as well. There are probably
> lots of optimizations if we only made the effort to understand these
> dependencies earlier.
>
> Constructing the device/resource dependency graph before the device ever
> boots sounds interesting to me.

Alexander Holler has been looking at that for some time already.

Regards,

Tomeu

> Regards,
> Mike
>
>>
>> If the dependency could only be discovered at the probe time, the
>> order of things might be changed in response to letting the driver
>> core know about it rather than "just in case", which should be more
>> efficient.
>>
>> Thanks,
>> Rafael
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] On-demand device probing

2015-10-23 Thread Tomeu Vizoso 
On 10/22/2015 09:26 PM, Greg Kroah-Hartman wrote:
> On Thu, Oct 22, 2015 at 11:53:31AM -0700, Frank Rowand wrote:
>> On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote:
>>> <oops, sent too early...>
>>>
>>> On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:
>>>> But that's moot currently because Greg believes that the time spent
>>>> probing devices at boot time could be reduced enough so that the order
>>>> in which devices are probed becomes irrelevant. IME that would have to
>>>> be under 200ms so that the user doesn't notice and that's unicorn-far
>>>> from any bootlog I have ever seen.
>>>
>>> But as no one has actually produced a bootlog, how do you know that?
>>> Where exactly is your time being spent?  What driver is causing long
>>> delays?  Why is the long-delay-drivers not being done in their own
>>> thread?  And most importantly, why are you ignoring the work that people
>>> did back in 2008 to solve the issue on other hardware platforms?
>>>
>>>> Given that downstreams are already carrying as many hacks as they
>>>> could think of to speed total boot up, I think this is effectively
>>>> telling them to go away.
>>>
>>> No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to
>>> solve-the-random-issue-i'm-having type patch by putting random calls in
>>> semi-random subsystems all over the kernel.
>>>
>>> And when I ask for real data, you respond with the fact that you aren't
>>> trying to speed up boot time here at all, so what am I supposed to think
>>
>> I also had the understanding that this patch series was about improving
>> boot time.  But I was kindly corrected that the behavior change was
>> getting the panel displaying stuff at an earlier point in the boot sequence,
>> _not_ completing the entire boot faster. 
>>
>> The claim for the current series, in patch 0 in v7 is:
>>
>>With this series I get the kernel to output to the panel in 0.5s,
>>instead of 2.8s.
>>
>> Just to get side-tracked, one other approach at ordering to reduce
>> deferrals reported a modest boot time reduction for four boards and a
>> very slight boot time increase for one other board.) The report of boot
>> times with that approach was in:
>>
>>   http://article.gmane.org/gmane.linux.drivers.devicetree/133010
>>
>> from Alexander Holler.
>>
>> I have not searched further to see if there is more data of boot time
>> reductions from any of the other attempts to change driver binding
>> order to move dependencies before use of a resource.  But whether
>> there is a performance improvement or not, there continues to be
>> a stream of developers creatively impacting the binding order for
>> their specific driver(s) or board.  So it seems that maybe there
>> is an underlying problem, or we don't have adequate documentation
>> explaining how to avoid a need to order bindings, or the
>> documentation exists and is not being read.
>>
>> I have been defaulting to the position that has been asserted by
>> the device tree maintainters, that probe deferrals work just fine
>> for at least the majority of cases (and is the message I have been
>> sharing in my conference presentations about device tree).  But I
>> suspect that there is at least a small minority of cases that are not
>> well served by probe deferral.  (Not to be read as an endorsement of
>> this specific patch series, just a generic observation.)
> 
> I agree, there might be some small numbers that this is a problem for,
> and if so, great, show us the boot logs where things are taking up all
> of the time, and we can work on resolving those issues.
> 
> But without hard numbers / details, this all is just random hand-waving,
> and I don't like making core kernel changes on that basis.  And no one
> else should ever want us to do that either.

Hi,

have found the board in which Stéphane had the original issue on
(exynos5250-snow), and I'm attaching the bootlog of
next-20151013+exynos_defconfig with initcall_debug and DEBUG in dd.c.

As can be seen, 145b.dp-controller is tried reasonably early (at
0.25s), but is deferred and only retried at 0.9s, with the display
finally coming up at 1.35s.

But I'm not sure what's the point in discussing this further if you have
already said that it's fine if downstreams have to change the probing
order by moving files around in the makefiles and by fiddling with
initcall levels.

To give a better understanding of what's going on here, I wasn't
involved in the bringup of this board, but was tasked

Re: [GIT PULL] On-demand device probing

2015-10-22 Thread Tomeu Vizoso 
On 22 October 2015 at 02:54, Rafael J. Wysocki <r...@rjwysocki.net> wrote:
> On Tuesday, October 20, 2015 06:21:55 PM Tomeu Vizoso wrote:
>> On 20 October 2015 at 18:04, Alan Stern <st...@rowland.harvard.edu> wrote:
>> > On Tue, 20 Oct 2015, Mark Brown wrote:
>> >
>> >> On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote:
>> >>
>> >> > Furthermore, that applies only to devices that use synchronous suspend.
>> >> > Async suspend is becoming common, and there the only restrictions are
>> >> > parent-child relations plus whatever explicit requirements that drivers
>> >> > impose by calling device_pm_wait_for_dev().
>> >>
>> >> Hrm, this is the first I'd noticed that feature though I see the initial
>> >> commit dates from January.
>> >
>> > Async suspend and device_pm_wait_for_dev() were added in January 2010,
>> > not 2015!
>> >
>> >>  It looks like most of the users are PCs at
>> >> the minute but we should be using it more widely for embedded things,
>> >> there's definitely some cases I'm aware of where it will allow us to
>> >> remove some open coding.
>> >>
>> >> It does seem like we want to be feeding dependency information we
>> >> discover for probing way into the suspend dependencies...
>> >
>> > Rafael has been thinking about a way to do this systematically.
>> > Nothing concrete has emerged yet.
>>
>> This iteration of the series would make this quite easy, as
>> dependencies are calculated before probes are attempted:
>>
>> https://lkml.org/lkml/2015/6/17/311
>
> Well, if you know how to represent "links" between devices, the mechanism
> introduced here doesn't really add much value, because in that case the
> core knows what the dependencies are in the first place and can only
> defer the probes that have to be deferred.

By "here" you mean what you are proposing for ordering device
suspends, or on-demand probing?

If you meant that probing on-demand is unneeded if we already have
dependency information, I agree with you and that's why I only pushed
forward on-demand, as the approach linked above introduced some
duplication when inferring the dependencies. Maybe that could be
avoided without too much refactoring.

In any case, Thierry mentioned the other day in #tegra that one could
also collect dependency information as a follow up to the on-demand
series by calling device_depend() or such instead of
of_device_probe().

Regards,

Tomeu

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

Re: [GIT PULL] On-demand device probing

2015-10-22 Thread Tomeu Vizoso 
On 21 October 2015 at 23:50, Frank Rowand <frowand.l...@gmail.com> wrote:
> On 10/21/2015 2:12 PM, Rob Herring wrote:
>> On Wed, Oct 21, 2015 at 1:18 PM, Frank Rowand <frowand.l...@gmail.com> wrote:
>>> On 10/21/2015 9:27 AM, Mark Brown wrote:
>>>> On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote:
>>>>> On 10/19/2015 5:34 AM, Tomeu Vizoso wrote:
>>>>
>>>>>> To be clear, I was saying that this series should NOT affect total
>>>>>> boot times much.
>>>>
>>>>> I'm confused.  If I understood correctly, improving boot time was
>>>>> the key justification for accepting this patch set.  For example,
>>>>> from "[PATCH v7 0/20] On-demand device probing":
>>>>>
>>>>>I have a problem with the panel on my Tegra Chromebook taking longer
>>>>>than expected to be ready during boot (Stéphane Marchesin reported what
>>>>>is basically the same issue in [0]), and have looked into ordered
>>>>>probing as a better way of solving this than moving nodes around in the
>>>>>DT or playing with initcall levels and linking order.
>>>>>
>>>>>...
>>>>>
>>>>>With this series I get the kernel to output to the panel in 0.5s,
>>>>>instead of 2.8s.
>>>>
>>>> Overall boot time and time to get some individual built in component up
>>>> and running aren't the same thing - what this'll do is get things up
>>>> more in the link order of the leaf consumers rather than deferring those
>>>> leaf consumers when their dependencies aren't ready yet.
>>>
>>> Thanks!  I read too much into what was being improved.
>>>
>>> So this patch series, which on other merits may be a good idea, is as
>>> a by product solving a specific ordering issue, moving successful panel
>>> initialization to an earlier point in the boot sequence, if I now
>>> understand more correctly.
>>>
>>> In that context, this seems like yet another ad hoc way of causing the
>>> probe order to change in a way to solves one specific issue?  Could
>>> it just as likely move the boot order of some other driver on some
>>> other board later, to the detriment of somebody else?
>>
>> Time to display on is important for many products. Having the console
>> up as early as possible is another case. CAN bus is another. This is a
>> real problem that is not just bad drivers.
>
> Yes, I agree.
>
> What I am seeing is that there continues to be a need for the ability
> to explicitly order at least some driver initialization (at some
> granularity), despite the push back against explicit ordering that
> has been present in the past.

The important point that I have struggled to explain is that right now
for downstreams to influence the order in which devices are probed,
they have to carry a substantial amount of patches that cannot be ever
upstreamed. This fiddling with initcall levels and link order means
changing files that are very frequently changing, increasing the
amount of work when rebasing and increasing the probability of
regressions after a rebase.

This just adds up to other shortcomings of mainline and ends up with
the net result of vendors getting stuck with 3.4 kernels on SoCs that
start production in 2015. Another consequence is that vendors don't
have a chance to upstream their stuff even if they cared. The
overarching goal of the project I'm in is to reduce those shortcomings
that downstreams have to workaround, to facilitate their involvement
upstream.

With this series, the order in which devices are probed becomes the
order in which they were registered, which is the order in which the
devices appear in the FW description of the hw or in the board files
(much more predictable, which makes for a more robust process). For DT
and board files, which cover a good part of the consumer devices
shipped today with Linux, the downstream could just change the order
of device nodes and get their display or whatever to probe before any
other devices.

And even if downstream's hw has a SoC .dtsi that exists in mainline,
they could add a step to their build process that automatically
reorders the nodes to avoid carrying changes to that DT fragment.

But that's moot currently because Greg believes that the time spent
probing devices at boot time could be reduced enough so that the order
in which devices are probed becomes irrelevant. IME that would have to
be under 200ms so that the user doesn't notice and that's unicorn-far
from any bootlog I have ever seen.

Given that downstreams are already carrying

Re: [GIT PULL] On-demand device probing

2015-10-20 Thread Tomeu Vizoso 
On 20 October 2015 at 18:04, Alan Stern  wrote:
> On Tue, 20 Oct 2015, Mark Brown wrote:
>
>> On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote:
>>
>> > Furthermore, that applies only to devices that use synchronous suspend.
>> > Async suspend is becoming common, and there the only restrictions are
>> > parent-child relations plus whatever explicit requirements that drivers
>> > impose by calling device_pm_wait_for_dev().
>>
>> Hrm, this is the first I'd noticed that feature though I see the initial
>> commit dates from January.
>
> Async suspend and device_pm_wait_for_dev() were added in January 2010,
> not 2015!
>
>>  It looks like most of the users are PCs at
>> the minute but we should be using it more widely for embedded things,
>> there's definitely some cases I'm aware of where it will allow us to
>> remove some open coding.
>>
>> It does seem like we want to be feeding dependency information we
>> discover for probing way into the suspend dependencies...
>
> Rafael has been thinking about a way to do this systematically.
> Nothing concrete has emerged yet.

This iteration of the series would make this quite easy, as
dependencies are calculated before probes are attempted:

https://lkml.org/lkml/2015/6/17/311

Regards,

Tomeu

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

Re: [GIT PULL] On-demand device probing

2015-10-19 Thread Tomeu Vizoso 
On 18 October 2015 at 21:53, Mark Brown  wrote:
> On Sun, Oct 18, 2015 at 12:37:57PM -0700, Greg Kroah-Hartman wrote:
>> On Sun, Oct 18, 2015 at 08:29:31PM +0100, Mark Brown wrote:
>> > On Fri, Oct 16, 2015 at 11:57:50PM -0700, Greg Kroah-Hartman wrote:
>
>> > > 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.
>
>> > This isn't bus specific, I'm not sure what makes you say that?
>
>> You are making it bus-specific by putting these calls all over the tree
>> in different bus subsystems semi-randomly for all I can determine.
>
> Do you mean firmware rather than bus here?  I think that's the confusion
> I have...

Hi all,

hope you don't mind I summarize the points taken instead of replying
to the individual emails. I tried to address all the concerns that
have been raised again in the cover letter, but I guess I did a bad
job at explaining myself, so here's another (more in-depth) go at it.

1) About the sprinkling of calls, everybody agreed it's a bad smell
from the start, but the intention is to modify the behaviour of the
already-DT-specific part of each subsystem without duplicating code.

A way to avoid the sprinkling would be to move the storage and lookup
of resources to the core (using classes and their list of devices to
replace the likes of __of_usb_find_phy). I also like Mark's idea of
calling of_device_probe from of_parse_phandle, which would be much
less invasive but I'm not sure if it would be right to call that
function in all the current cases in which of_parse_phandle is called.

2) About the goal of the series, what matters to my employer is that
once a device defers its probe it's only going to be reprobed in
late_initcall, after all the devices have been tentatively probed
once. In the practice this means that devices get probed in a
dependency order in which first go devices without dependencies then
go up the tree until the leave devices (which tend to be the ones with
effects visible to the user).

This series changes to another dependency order in which when a leaf
node gets probed, it recursively "pulls" its dependencies. This way we
stop massively delaying the probing of the display devices and vendors
can stop carrying sizeable hacks in their trees which just further
reduce the incentive to upstream.

The above is what funds this work, but in my personal opinion the
biggest advantage of this work is that it makes development on
embedded platforms more efficient because right now we don't have a
way of telling if a device deferred its probe because of an ordering
issue, or because there's a problem. If a device is available and has
a compatible driver, but it cannot be probed because a dependency
isn't going to be available, that's an error and is going to cause
real-world problems unless the device is redundant. Currently we say
nothing because with deferred probe the probe callbacks are also part
of the mechanism that determines the dependency order. I have wasted
countless hours hunting for the reason why a device didn't probe and I
have heard the same several times from others.

Having a specific switch for enabling deferred probe logging sounds
good, but there's going to be hundreds of spurious messages about
deferred probes that were just deferrals and only one of them is going
to be the actual error in which a device failed to find a dependency.

3) Regarding total boot time, I don't expect this series to make much
of a difference because though we would save a lot of matching and
querying for resources, that's little time compared with how long we
wait for hardware to react during probing. Async probing is more
likely to help with drivers that take a long time to probe.

4) About the breakage we have seen, that's not caused so far by
probing devices on-demand but by delaying probes until all built-in
drivers have been registered. The latter isn't strictly needed for
on-demand probing but without it most of the benefits are lost because
probes of dependencies are going to be deferred because the drivers
aren't there yet. We could avoid that by registering drivers also
on-demand but we would need to make the matching information available
beforehand, which is a massive change in itself. This should speed up
boot some, and also cause leaf devices to be up earlier.

One more thing about the breakage we have seen so far is that it's
generally caused by implicit dependencies and hunting those is
probably the second biggest timesink of the linux embedded developer
after failed probes. We depend on hacks such as link order, node order
in the DT, initcall gerrymandering and a blind hope in things that
started some time ago to have finished by now. And those implicit
dependencies are often left completely undocumented. This is really
fragile and breaks often when changing something unrelated such as
when adding another revision of a board

Re: [GIT PULL] On-demand device probing

2015-10-19 Thread Tomeu Vizoso 
On 19 October 2015 at 15:18, Russell King - ARM Linux
<li...@arm.linux.org.uk> wrote:
> On Mon, Oct 19, 2015 at 02:34:22PM +0200, Tomeu Vizoso wrote:
>> ... If a device is available and has
>> a compatible driver, but it cannot be probed because a dependency
>> isn't going to be available, that's an error and is going to cause
>> real-world problems unless the device is redundant. Currently we say
>> nothing because with deferred probe the probe callbacks are also part
>> of the mechanism that determines the dependency order.
>
> So what if device X depends on device Y, and we have a driver for
> device Y built-in to the kernel, but the driver for device X is a
> module?
>
> I don't see this being solvable in the way you describe above - it's
> going to identify X as being unable to be satisfied, and report it as
> an error - but it's not an error at all.

It's going to probe Y at late_initcall, then probe X when its driver
is registered. No deferred probes nor messages about it.

But if you meant to write the opposite case (X built-in and Y in a
module), then I have to ask you in what situation that would make
sense.

>> Having a specific switch for enabling deferred probe logging sounds
>> good, but there's going to be hundreds of spurious messages about
>> deferred probes that were just deferrals and only one of them is going
>> to be the actual error in which a device failed to find a dependency.
>
> Why would there be?  Sounds like something's very wrong there.

Sorry about that, I have checked that only now and I "only" get 39
deferred probe messages on exynos5250-snow.

> You should only get deferred probes for devices which are declared to
> be present, but their resources have not yet been satisfied.  It
> doesn't change anything if you have a kernel with lots of device drivers
> or just the device drivers you need - the device drivers you don't need
> do not contribute to the deferred probing in any way.

I don't think that the number of registered drivers affects the number
of probes that get deferred (but I'm not sure why you mention that).

> So, really, after boot and all appropriate modules have been loaded,
> you should end up with no deferred probes.  Are you saying that you
> still have "hundreds" at that point?  If you do, that sounds like
> there's something very wrong.

I was talking about messages if we log each -EPROBE_DEFER, not devices
that remain to be probed. The point being that right now we don't have
a way to know if we are deferring because the dependency will be
around later, or if we have a problem and the dependency isn't going
to be there at all.

If we had a way to enable printing the cause of each -EPROBE_DEFER,
right now that would print 39 messages of this board that are only due
to ordering. The actual issue would be printed in exactly the same way
somewhere in the middle.

>> 3) Regarding total boot time, I don't expect this series to make much
>> of a difference because though we would save a lot of matching and
>> querying for resources, that's little time compared with how long we
>> wait for hardware to react during probing. Async probing is more
>> likely to help with drivers that take a long time to probe.
>
> For me, on my fastest ARM board, though running serial console:
>
> [2.293468] VFS: Mounted root (ext4 filesystem) on device 179:1.
>
> There's a couple of delays in there, but they're not down to deferred
> probing.  The biggest one is serial console startup (due to the time
> it takes to write out the initial kernel messages):
>
> [0.289962] f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq = 23, base_baud 
> = 15625000) is a 16550A
> [0.944124] console [ttyS0] enabled
>
> and DSA switch initialisation:
>
> [1.530655] libphy: dsa slave smi: probed
> [2.034426] dsa dsa@0 lan6 (uninitialized): attached PHY at address 0 
> [Generic PHY]
>
> I'm not sure what causes that, but at a guess it's having to talk to the
> DSA switch over the MDIO bus via several layers of indirect accesses.
> Of course, serial console adds to the boot time significantly anyway,
> especially at the "standard" kernel logging level.

Yes, I don't think it makes any sense to measure boot times with the
serial console on, because it's not comparable to production and
because printing an additional line during boot affects significantly
the times.

To be clear, I was saying that this series should NOT affect total
boot times much.

>> One more thing about the breakage we have seen so far is that it's
>> generally caused by implicit dependencies and hunting those is
>> probably the second biggest timesink of the linux embedded developer
>> after failed probes.
>
> ... which is general

Re: [GIT PULL] On-demand device probing

2015-10-19 Thread Tomeu Vizoso 
On 19 October 2015 at 16:30, Russell King - ARM Linux
<li...@arm.linux.org.uk> wrote:
> On Mon, Oct 19, 2015 at 04:10:56PM +0200, Tomeu Vizoso wrote:
>> On 19 October 2015 at 15:18, Russell King - ARM Linux
>> <li...@arm.linux.org.uk> wrote:
>> > On Mon, Oct 19, 2015 at 02:34:22PM +0200, Tomeu Vizoso wrote:
>> >> ... If a device is available and has
>> >> a compatible driver, but it cannot be probed because a dependency
>> >> isn't going to be available, that's an error and is going to cause
>> >> real-world problems unless the device is redundant. Currently we say
>> >> nothing because with deferred probe the probe callbacks are also part
>> >> of the mechanism that determines the dependency order.
>> >
>> > So what if device X depends on device Y, and we have a driver for
>> > device Y built-in to the kernel, but the driver for device X is a
>> > module?
>> >
>> > I don't see this being solvable in the way you describe above - it's
>> > going to identify X as being unable to be satisfied, and report it as
>> > an error - but it's not an error at all.
>>
>> It's going to probe Y at late_initcall, then probe X when its driver
>> is registered. No deferred probes nor messages about it.
>>
>> But if you meant to write the opposite case (X built-in and Y in a
>> module), then I have to ask you in what situation that would make
>> sense.
>
> I did mean the opposite way around.  It may not make sense if you're
> targetting a single platform, but it may make sense in a single zImage
> kernel.
>
> Consider something like a single zImage kernel that is built with
> everything built-in to be able to boot and mount rootfs without
> initramfs support on both platform A and platform B.  Both platforms
> share some hardware (eg, an I2C GPIO expander) which is built as a
> module.  It is a resource provider.  Platform B contains a driver
> which is required to boot on platform A, but not platform B (so the
> kernel has to have that driver built-in.)  On platform B, there is
> a dependency to the I2C GPIO expander device.

I see, in this situation the person trying to find out why some device
hadn't probed would enable debug logging of failed probes and would
see one spurious message if there was a deferred probe because of the
module.

>> >> Having a specific switch for enabling deferred probe logging sounds
>> >> good, but there's going to be hundreds of spurious messages about
>> >> deferred probes that were just deferrals and only one of them is going
>> >> to be the actual error in which a device failed to find a dependency.
>> >
>> > Why would there be?  Sounds like something's very wrong there.
>>
>> Sorry about that, I have checked that only now and I "only" get 39
>> deferred probe messages on exynos5250-snow.
>
> I typically see one or two, maybe five maximum on the platforms I have
> here, but normally zero.

Hmm, I have given a look at our lava farm and have seen 2 dozens as
common (with multi_v7).

>> > So, really, after boot and all appropriate modules have been loaded,
>> > you should end up with no deferred probes.  Are you saying that you
>> > still have "hundreds" at that point?  If you do, that sounds like
>> > there's something very wrong.
>>
>> I was talking about messages if we log each -EPROBE_DEFER, not devices
>> that remain to be probed. The point being that right now we don't have
>> a way to know if we are deferring because the dependency will be
>> around later, or if we have a problem and the dependency isn't going
>> to be there at all.
>
> What's the difference between a dependency which isn't around because
> the driver is not built into the kernel but is available as a module,
> and a dependency that isn't around because the module hasn't been
> loaded yet?
>
> How do you distinguish between those two scenarios?  In the former
> scenario, the device will eventually come up when udev loads the
> module.  In the latter case, it's a persistent failing case.

Agreed, but it's something that doesn't happen often and that's why
such messages would be at the debug level instead of being warns or
errors.

>> Agreed, with the note from above on why it would be better to only
>> print such a message only when the -EPROBE_DEFER is likely to be a
>> problem.
>
> ... and my argument is that there's _no way_ to know for certain which
> deferred probes will be a problem, and which won't.  The only way to
> definitely know that is if you disable kernel modules, and require
> all drivers to be built int

[GIT PULL] On-demand device probing

2015-10-15 Thread Tomeu Vizoso 
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-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL] On-demand device probing

2015-10-14 Thread Tomeu Vizoso 
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-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 0/22] On-demand device probing

2015-09-09 Thread Tomeu Vizoso 
On 9 September 2015 at 03:33, Rob Herring <r...@kernel.org> wrote:
> On 09/08/2015 02:30 AM, Tomeu Vizoso wrote:
>> On 7 September 2015 at 22:50, Rob Herring <robherri...@gmail.com> wrote:
>>> On Mon, Sep 7, 2015 at 7:23 AM, Tomeu Vizoso <tomeu.viz...@collabora.com> 
>>> wrote:
>>>> Hello,
>>>>
>>>> I have a problem with the panel on my Tegra Chromebook taking longer
>>>> than expected to be ready during boot (Stéphane Marchesin reported what
>>>> is basically the same issue in [0]), and have looked into ordered
>>>> probing as a better way of solving this than moving nodes around in the
>>>> DT or playing with initcall levels and linking order.
>>>>
>>>> While reading the thread [1] that Alexander Holler started with his
>>>> series to make probing order deterministic, it occurred to me that it
>>>> should be possible to achieve the same by probing devices as they are
>>>> referenced by other devices.
>>>>
>>>> This basically reuses the information that is already implicit in the
>>>> probe() implementations, saving us from refactoring existing drivers or
>>>> adding information to DTBs.
>>>>
>>>> During review of v1 of this series Linus Walleij suggested that it
>>>> should be the device driver core to make sure that dependencies are
>>>> ready before probing a device. I gave this idea a try [2] but Mark Brown
>>>> pointed out to the logic duplication between the resource acquisition
>>>> and dependency discovery code paths (though I think it's fairly minor).
>>>>
>>>> To address that code duplication I experimented with Arnd's devm_probe
>>>> [3] concept of having drivers declare their dependencies instead of
>>>> acquiring them during probe, and while it worked [4], I don't think we
>>>> end up winning anything when compared to just probing devices on-demand
>>>> from resource getters.
>>>>
>>>> One remaining objection is to the "sprinkling" of calls to
>>>> of_device_probe() in the resource getters of each subsystem, but I think
>>>> it's the right thing to do given that the storage of resources is
>>>> currently subsystem-specific.
>>>>
>>>> We could avoid the above by moving resource storage into the core, but I
>>>> don't think there's a compelling case for that.
>>>>
>>>> I have tested this on boards with Tegra, iMX.6, Exynos, Rockchip and
>>>> OMAP SoCs, and these patches were enough to eliminate all the deferred
>>>> probes (except one in PandaBoard because omap_dma_system doesn't have a
>>>> firmware node as of yet).
>>>>
>>>> Have submitted a branch [5] with only these patches on top of thursday's
>>>> linux-next to kernelci.org and I don't see any issues that could be
>>>> caused by them. For some reason it currently has more passes than the
>>>> version of -next it's based on!
>>>>
>>>> With this series I get the kernel to output to the panel in 0.5s,
>>>> instead of 2.8s.
>>>>
>>>> Regards,
>>>>
>>>> Tomeu
>>>>
>>>> [0] http://lists.freedesktop.org/archives/dri-devel/2014-August/066527.html
>>>>
>>>> [1] https://lkml.org/lkml/2014/5/12/452
>>>>
>>>> [2] https://lkml.org/lkml/2015/6/17/305
>>>>
>>>> [3] http://article.gmane.org/gmane.linux.ports.arm.kernel/277689
>>>>
>>>> [4] https://lkml.org/lkml/2015/7/21/441a
>>>>
>>>> [5] 
>>>> https://git.collabora.com/cgit/user/tomeu/linux.git/log/?h=on-demand-probes-v6
>>>>
>>>> [6] 
>>>> http://kernelci.org/boot/all/job/collabora/kernel/v4.2-11902-g25d80c927f8b/
>>>>
>>>> [7] http://kernelci.org/boot/all/job/next/kernel/next-20150903/
>>>>
>>>> Changes in v4:
>>>> - Added bus.pre_probe callback so the probes of Primecell devices can be
>>>>   deferred if their device IDs cannot be yet read because of the clock
>>>>   driver not having probed when they are registered. Maybe this goes
>>>>   overboard and the matching information should be in the DT if there is
>>>>   one.
>>>
>>> Seems overboard to me or at least a separate problem.
>>
>> It's a separate problem but this was preventing the series from
>> working on a few boards.
>
>

Re: [PATCH v4 0/22] On-demand device probing

2015-09-08 Thread Tomeu Vizoso 
On 7 September 2015 at 22:50, Rob Herring <robherri...@gmail.com> wrote:
> On Mon, Sep 7, 2015 at 7:23 AM, Tomeu Vizoso <tomeu.viz...@collabora.com> 
> wrote:
>> Hello,
>>
>> I have a problem with the panel on my Tegra Chromebook taking longer
>> than expected to be ready during boot (Stéphane Marchesin reported what
>> is basically the same issue in [0]), and have looked into ordered
>> probing as a better way of solving this than moving nodes around in the
>> DT or playing with initcall levels and linking order.
>>
>> While reading the thread [1] that Alexander Holler started with his
>> series to make probing order deterministic, it occurred to me that it
>> should be possible to achieve the same by probing devices as they are
>> referenced by other devices.
>>
>> This basically reuses the information that is already implicit in the
>> probe() implementations, saving us from refactoring existing drivers or
>> adding information to DTBs.
>>
>> During review of v1 of this series Linus Walleij suggested that it
>> should be the device driver core to make sure that dependencies are
>> ready before probing a device. I gave this idea a try [2] but Mark Brown
>> pointed out to the logic duplication between the resource acquisition
>> and dependency discovery code paths (though I think it's fairly minor).
>>
>> To address that code duplication I experimented with Arnd's devm_probe
>> [3] concept of having drivers declare their dependencies instead of
>> acquiring them during probe, and while it worked [4], I don't think we
>> end up winning anything when compared to just probing devices on-demand
>> from resource getters.
>>
>> One remaining objection is to the "sprinkling" of calls to
>> of_device_probe() in the resource getters of each subsystem, but I think
>> it's the right thing to do given that the storage of resources is
>> currently subsystem-specific.
>>
>> We could avoid the above by moving resource storage into the core, but I
>> don't think there's a compelling case for that.
>>
>> I have tested this on boards with Tegra, iMX.6, Exynos, Rockchip and
>> OMAP SoCs, and these patches were enough to eliminate all the deferred
>> probes (except one in PandaBoard because omap_dma_system doesn't have a
>> firmware node as of yet).
>>
>> Have submitted a branch [5] with only these patches on top of thursday's
>> linux-next to kernelci.org and I don't see any issues that could be
>> caused by them. For some reason it currently has more passes than the
>> version of -next it's based on!
>>
>> With this series I get the kernel to output to the panel in 0.5s,
>> instead of 2.8s.
>>
>> Regards,
>>
>> Tomeu
>>
>> [0] http://lists.freedesktop.org/archives/dri-devel/2014-August/066527.html
>>
>> [1] https://lkml.org/lkml/2014/5/12/452
>>
>> [2] https://lkml.org/lkml/2015/6/17/305
>>
>> [3] http://article.gmane.org/gmane.linux.ports.arm.kernel/277689
>>
>> [4] https://lkml.org/lkml/2015/7/21/441a
>>
>> [5] 
>> https://git.collabora.com/cgit/user/tomeu/linux.git/log/?h=on-demand-probes-v6
>>
>> [6] 
>> http://kernelci.org/boot/all/job/collabora/kernel/v4.2-11902-g25d80c927f8b/
>>
>> [7] http://kernelci.org/boot/all/job/next/kernel/next-20150903/
>>
>> Changes in v4:
>> - Added bus.pre_probe callback so the probes of Primecell devices can be
>>   deferred if their device IDs cannot be yet read because of the clock
>>   driver not having probed when they are registered. Maybe this goes
>>   overboard and the matching information should be in the DT if there is
>>   one.
>
> Seems overboard to me or at least a separate problem.

It's a separate problem but this was preventing the series from
working on a few boards.

> Most clocks have
> to be setup before the driver model simply because timers depend on
> clocks usually.

Yes, but in this case the apb clocks for the primecell devices are
implemented in a normal platform driver (vexpress_osc_driver), instead
of using CLK_OF_DECLARE.

Regards,

Tomeu

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

[PATCH v4 11/22] i2c: core: Probe i2c adapters and devices on demand

2015-09-07 Thread Tomeu Vizoso 
When looking up an i2c adapter or device through its OF node, probe it
if it hasn't already.

The goal is to reduce deferred probes to a minimum, as it makes it very
cumbersome to find out why a device failed to probe, and can introduce
very big delays in when a critical device is probed.

Signed-off-by: Tomeu Vizoso <tomeu.viz...@collabora.com>
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/i2c/i2c-core.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 5f89f1e3c2f2..02da3acbbd35 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -1413,6 +1413,8 @@ struct i2c_client *of_find_i2c_device_by_node(struct 
device_node *node)
struct device *dev;
struct i2c_client *client;
 
+   of_device_probe(node);
+
dev = bus_find_device(_bus_type, NULL, node, of_dev_node_match);
if (!dev)
return NULL;
@@ -1431,6 +1433,8 @@ struct i2c_adapter *of_find_i2c_adapter_by_node(struct 
device_node *node)
struct device *dev;
struct i2c_adapter *adapter;
 
+   of_device_probe(node);
+
dev = bus_find_device(_bus_type, NULL, node, of_dev_node_match);
if (!dev)
return NULL;
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 0/22] On-demand device probing

2015-09-07 Thread Tomeu Vizoso 
Hello,

I have a problem with the panel on my Tegra Chromebook taking longer
than expected to be ready during boot (Stéphane Marchesin reported what
is basically the same issue in [0]), and have looked into ordered
probing as a better way of solving this than moving nodes around in the
DT or playing with initcall levels and linking order.

While reading the thread [1] that Alexander Holler started with his
series to make probing order deterministic, it occurred to me that it
should be possible to achieve the same by probing devices as they are
referenced by other devices.

This basically reuses the information that is already implicit in the
probe() implementations, saving us from refactoring existing drivers or
adding information to DTBs.

During review of v1 of this series Linus Walleij suggested that it
should be the device driver core to make sure that dependencies are
ready before probing a device. I gave this idea a try [2] but Mark Brown
pointed out to the logic duplication between the resource acquisition
and dependency discovery code paths (though I think it's fairly minor).

To address that code duplication I experimented with Arnd's devm_probe
[3] concept of having drivers declare their dependencies instead of
acquiring them during probe, and while it worked [4], I don't think we
end up winning anything when compared to just probing devices on-demand
from resource getters.

One remaining objection is to the "sprinkling" of calls to
of_device_probe() in the resource getters of each subsystem, but I think
it's the right thing to do given that the storage of resources is
currently subsystem-specific.

We could avoid the above by moving resource storage into the core, but I
don't think there's a compelling case for that.

I have tested this on boards with Tegra, iMX.6, Exynos, Rockchip and
OMAP SoCs, and these patches were enough to eliminate all the deferred
probes (except one in PandaBoard because omap_dma_system doesn't have a
firmware node as of yet).

Have submitted a branch [5] with only these patches on top of thursday's
linux-next to kernelci.org and I don't see any issues that could be
caused by them. For some reason it currently has more passes than the
version of -next it's based on!

With this series I get the kernel to output to the panel in 0.5s,
instead of 2.8s.

Regards,

Tomeu

[0] http://lists.freedesktop.org/archives/dri-devel/2014-August/066527.html

[1] https://lkml.org/lkml/2014/5/12/452

[2] https://lkml.org/lkml/2015/6/17/305

[3] http://article.gmane.org/gmane.linux.ports.arm.kernel/277689

[4] https://lkml.org/lkml/2015/7/21/441a

[5] 
https://git.collabora.com/cgit/user/tomeu/linux.git/log/?h=on-demand-probes-v6

[6] http://kernelci.org/boot/all/job/collabora/kernel/v4.2-11902-g25d80c927f8b/

[7] http://kernelci.org/boot/all/job/next/kernel/next-20150903/

Changes in v4:
- Added bus.pre_probe callback so the probes of Primecell devices can be
  deferred if their device IDs cannot be yet read because of the clock
  driver not having probed when they are registered. Maybe this goes
  overboard and the matching information should be in the DT if there is
  one.
- Rename of_platform_probe to of_device_probe
- Use device_node.device instead of device_node.platform_dev
- Take a reference to the regulator's device to prevent dangling
  pointers
- Add Kconfig DELAY_DEVICE_PROBES to allow disabling delayed probing in
  machines with initcalls that depend on devices probing at a given time.
- Start processing deferred probes in device_initcall_sync
- Also defer probes of AMBA devices registered from the DT as they can
  also request resources.

Changes in v3:
- Set and use device_node.platform_dev instead of reversing the logic to
  find the platform device that encloses a device node.
- Drop the fwnode API to probe firmware nodes and add OF-only API for
  now. I think this same scheme could be used for machines with ACPI,
  but I haven't been able to find one that had to defer its probes because
  of the device probe order.
- Avoid unlocking the regulator device's mutex if we don't have a device

Changes in v2:
- Acquire regulator device lock before returning from regulator_dev_lookup()

Tomeu Vizoso (22):
  driver core: Add pre_probe callback to bus_type
  ARM: amba: Move reading of periphid to pre_probe()
  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
  gpio: Probe pinctrl devices on demand
  regulator: core: Reduce critical area in _regulator_get
  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 de

Re: [PATCH v2 13/22] i2c: core: Probe i2c master devices on demand

2015-08-09 Thread Tomeu Vizoso 
On 9 August 2015 at 14:34, Wolfram Sang w...@the-dreams.de wrote:
 On Tue, Jul 28, 2015 at 03:19:44PM +0200, Tomeu Vizoso wrote:
 When looking up an i2c master through its firmware node, probe it if it
 hasn't already.

 The goal is to reduce deferred probes to a minimum, as it makes it very
 cumbersome to find out why a device failed to probe, and can introduce
 very big delays in when a critical device is probed.

 Signed-off-by: Tomeu Vizoso tomeu.viz...@collabora.com

 What is the status of this series?

See here for a summary:

http://lkml.kernel.org/g/1438870315-18689-1-git-send-email-tomeu.viz...@collabora.com

 The boot time reduction sounds great.

Note that this should not reduce total boot time substantially, as the
time wasted due to superfluous probe deferrals is really small when
compared to the time spent in delays due to hardware constraints. If
you want to reduce total boot time, async probing may be helpful in
some scenarios.

Regards,

Tomeu

 ---

 Changes in v2: None

  drivers/i2c/i2c-core.c | 2 ++
  1 file changed, 2 insertions(+)

 diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
 index e6d4935161e4..5520b413e3db 100644
 --- a/drivers/i2c/i2c-core.c
 +++ b/drivers/i2c/i2c-core.c
 @@ -1353,6 +1353,8 @@ struct i2c_adapter *of_find_i2c_adapter_by_node(struct 
 device_node *node)
  {
   struct device *dev;

 + fwnode_ensure_device(node-fwnode);

 TBH, the function name doesn't tell me a lot. It ensures what?

 +
   dev = bus_find_device(i2c_bus_type, NULL, node,
of_dev_node_match);
   if (!dev)
 --
 2.4.3

--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 02/10] i2c: core: Have clients point to their firmware nodes

2015-08-06 Thread Tomeu Vizoso 
On 31 July 2015 at 12:36, Wolfram Sang w...@the-dreams.de wrote:
 On Tue, Jun 30, 2015 at 04:55:00PM +0200, Tomeu Vizoso wrote:
 This is needed by platform-independent code that needs to do something
 with devices based on the data provided by the firmware.

 Signed-off-by: Tomeu Vizoso tomeu.viz...@collabora.com

 Dunno the status of this series, but the i2c change is trivial enough.
 So in case, the rest is accepted:

 Acked-by: Wolfram Sang w...@the-dreams.de

Currently my series is moving away from fwnode because the current
approach is very much dependent on the firmware, but I think this fix
is worth in its own because someone else will find this problem sooner
or later.

Regards,

Tomeu
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 13/22] i2c: core: Probe i2c master devices on demand

2015-07-28 Thread Tomeu Vizoso 
When looking up an i2c master through its firmware node, probe it if it
hasn't already.

The goal is to reduce deferred probes to a minimum, as it makes it very
cumbersome to find out why a device failed to probe, and can introduce
very big delays in when a critical device is probed.

Signed-off-by: Tomeu Vizoso tomeu.viz...@collabora.com
---

Changes in v2: None

 drivers/i2c/i2c-core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index e6d4935161e4..5520b413e3db 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -1353,6 +1353,8 @@ struct i2c_adapter *of_find_i2c_adapter_by_node(struct 
device_node *node)
 {
struct device *dev;
 
+   fwnode_ensure_device(node-fwnode);
+
dev = bus_find_device(i2c_bus_type, NULL, node,
 of_dev_node_match);
if (!dev)
-- 
2.4.3

--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 0/22] On-demand device probing

2015-07-28 Thread Tomeu Vizoso 
Hello,

I have a problem with the panel on my Tegra Chromebook taking longer
than expected to be ready during boot (Stéphane Marchesin reported what
is basically the same issue in [0]), and have looked into ordered
probing as a better way of solving this than moving nodes around in the
DT or playing with initcall levels and linking order.

While reading the thread [1] that Alexander Holler started with his
series to make probing order deterministic, it occurred to me that it
should be possible to achieve the same by probing devices as they are
referenced by other devices.

This basically reuses the information that is already implicit in the
probe() implementations, saving us from refactoring existing drivers or
adding information to DTBs.

During review of v1 of this series Linus Walleij suggested that it
should be the device driver core to make sure that dependencies are
ready before probing a device. I gave this idea a try [2] but Mark Brown
pointed out to the logic duplication between the resource acquisition
and dependency discovery code paths (though I think it's fairly minor).

To address that code duplication I experimented with Arnd's devm_probe
[3] concept of having drivers declare their dependencies instead of
acquiring them during probe, and while it worked [4], I don't think we
end up winning anything when compared to just probing devices on-demand
from resource getters.

One remaining objection is to the sprinkling of calls to
fwnode_ensure_device() in the resource getters of each subsystem, but I
think it's the right thing to do given that the storage of resources is
currently subsystem-specific.

We could avoid the above by moving resource storage into the core, but I
don't think there's a compelling case for that.

I have tested this on boards with Tegra, iMX.6, Exynos and OMAP SoCs,
and these patches were enough to eliminate all the deferred probes
(except one in PandaBoard because omap_dma_system doesn't have a
firmware node as of yet).

With this series I get the kernel to output to the panel in 0.5s,
instead of 2.8s.

Regards,

Tomeu

[0] http://lists.freedesktop.org/archives/dri-devel/2014-August/066527.html

[1] https://lkml.org/lkml/2014/5/12/452

[2] https://lkml.org/lkml/2015/6/17/305

[3] http://article.gmane.org/gmane.linux.ports.arm.kernel/277689

[4] https://lkml.org/lkml/2015/7/21/441

Changes in v2:
- Move delay to platform.c
- Use set_primary_fwnode()
- Use of_node_full_name()
- Move the logic for finding a platform device from its firmware node to
  of/platform.c as it's not needed for ACPI nodes.
- Add acpi_dev_get_device()
- Add fwnode_ensure_device() so the mechanism for probing devices on
  demand is independent of the firmware format.
- Acquire regulator device lock before returning from regulator_dev_lookup()

Tomeu Vizoso (22):
  platform: delay device-driver matches until late_initcall
  of/platform: Set fwnode field for new devices
  device property: add fwnode_get_name()
  of/platform: add of_platform_device_find()
  ACPI: add acpi_dev_get_device()
  device property: add fwnode_ensure_device()
  gpio: Probe GPIO drivers on demand
  gpio: Probe pinctrl devices on demand
  regulator: core: Reduce critical area in _regulator_get
  regulator: core: Probe regulators on demand
  drm: Probe panels on demand
  drm/tegra: Probe dpaux devices on demand
  i2c: core: Probe i2c master 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
  ASoC: core: Probe components on demand

 drivers/base/platform.c | 28 +++
 drivers/base/property.c | 73 +++
 drivers/clk/clk.c   |  3 ++
 drivers/dma/of-dma.c|  2 +
 drivers/gpio/gpiolib-of.c   |  4 ++
 drivers/gpu/drm/drm_panel.c |  2 +
 drivers/gpu/drm/tegra/dpaux.c   |  2 +
 drivers/i2c/i2c-core.c  |  2 +
 drivers/of/platform.c   | 61 +++
 drivers/phy/phy-core.c  |  2 +
 drivers/pinctrl/devicetree.c|  1 +
 drivers/power/power_supply_core.c   |  2 +
 drivers/pwm/core.c  |  2 +
 drivers/regulator/core.c| 99 +
 drivers/usb/phy/phy.c   |  2 +
 drivers/video/backlight/backlight.c |  2 +
 include/linux/acpi.h| 10 
 include/linux/of_platform.h |  1 +
 include/linux/property.h|  4 ++
 sound/soc/soc-core.c|  6 ++-
 20 files changed, 264 insertions(+), 44 deletions(-)

-- 
2.4.3

--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org

[PATCH v1 02/10] i2c: core: Have clients point to their firmware nodes

2015-06-30 Thread Tomeu Vizoso 
This is needed by platform-independent code that needs to do something
with devices based on the data provided by the firmware.

Signed-off-by: Tomeu Vizoso tomeu.viz...@collabora.com
---

 drivers/i2c/i2c-core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 069a41f..707850a 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -1295,6 +1295,7 @@ static struct i2c_client *of_i2c_register_device(struct 
i2c_adapter *adap,
}
 
info.of_node = of_node_get(node);
+   info.fwnode = info.of_node ? info.of_node-fwnode : NULL;
info.archdata = dev_ad;
 
if (of_get_property(node, wakeup-source, NULL))
-- 
2.4.1

--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v1 0/10] Fixes and API additions for firmware nodes

2015-06-30 Thread Tomeu Vizoso 
Hi,

this series makes it possible to extract device dependencies from firmware data
with fwnode, thus not depending on the particular format of that data.

The first patches are about making sure that we can reach the fwnode
handle of the firmware data associated with a given device, and the rest
add API that makes dependency extraction possible.

Thanks,

Tomeu


Tomeu Vizoso (10):
  of/platform: Set fwnode field for new devices
  i2c: core: Have clients point to their firmware nodes
  mfd: Have child devices point to their firmware nodes
  device property: add fwnode_get_parent()
  device property: add fwnode_get_name()
  ACPI / scan: Add acpi_dev_get_next_child()
  device property: Add fwnode_get_next_child_node()
  device property: add fwnode_is_compatible()
  device: property: add fwnode_driver_match_device()
  core: platform: use fwnode_driver_match_device()

 drivers/acpi/scan.c  |  5 +--
 drivers/base/platform.c  |  8 +---
 drivers/base/property.c  | 95 
 drivers/i2c/i2c-core.c   |  1 +
 drivers/mfd/mfd-core.c   |  1 +
 drivers/of/platform.c|  1 +
 include/acpi/acpi_bus.h  |  5 +++
 include/linux/acpi.h | 22 ++-
 include/linux/property.h | 17 +
 9 files changed, 136 insertions(+), 19 deletions(-)

-- 
2.4.1

--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/21] On-demand device registration

2015-06-22 Thread Tomeu Vizoso 
On 28 May 2015 at 06:33, Rob Herring robherri...@gmail.com wrote:
 On Mon, May 25, 2015 at 9:53 AM, Tomeu Vizoso
 tomeu.viz...@collabora.com wrote:
 Hello,

 I have a problem with the panel on my Tegra Chromebook taking longer than
 expected to be ready during boot (Stéphane Marchesin reported what is
 basically the same issue in [0]), and have looked into ordered probing as a
 better way of solving this than moving nodes around in the DT or playing with
 initcall levels.

 While reading the thread [1] that Alexander Holler started with his series to
 make probing order deterministic, it occurred to me that it should be 
 possible
 to achieve the same by registering devices as they are referenced by other
 devices.

 I like the concept and novel approach.

 This basically reuses the information that is already implicit in the probe()
 implementations, saving us from refactoring existing drivers or adding
 information to DTBs.

 Something I'm not completely happy with is that I have had to move the call 
 to
 of_platform_populate after all platform drivers have been registered.
 Otherwise I don't see how I could register drivers on demand as we don't have
 yet each driver's compatible strings.

 Yeah, this is the opposite of what we'd really like.

Can you elaborate on the reasons why we would like to have devices
registered before built-in drivers finish registering, even if we
don't probe them yet?

 Ideally, we would
 have a solution that works for modules too. However, we're no worse
 off. We pretty much build-in dependencies to avoid module ordering
 problems.

Nod, I haven't looked yet at requesting modules on-demand, but I guess
it should be doable. Modules that have dependencies described in the
firmware should get them probed automatically already though.

 Perhaps we need to make the probing on-demand rather than simply on
 device-driver match occurring.

I'm afraid that too much old code depends on that. For example, Rafael
pointed out to the PNP subsystem, which registers a driver that will
probe devices with the EISA ID PNP0c02 to reserve memory regions for
devices that will be probed later.

http://lxr.free-electrons.com/source/drivers/pnp/system.c

My understanding is that probing of PNP0c02 devices must happen before
the actual devices that depend on those regions are probed, so if we
decoupled the probing from the driver/device registration, we would be
breaking that assumption.

 For machs that don't move of_platform_populate() to a later point, these
 patches shouldn't cause any problems but it's not guaranteed that we'll avoid
 all the deferred probes as some drivers may not be registered yet.

 Ideally, of_platform_populate is not explicitly called by each
 platform. So I think we need to make this work for the default case.

The problem is that some platforms will need fixing because some
initcalls assume that some devices will have been registered already,
or even probed. I think removing those assumptions shouldn't be
problematic because I haven't had much trouble with this on the four
platforms I have tested with, but I cannot test every board that is
supported upstream.

I can ask though the KernelCI folks to boot my branch in all their
boards and make sure that those work when of_platform_populate is
called in late_initcall.

http://kernelci.org/boot/all/job/next/kernel/next-20150619/

 I have tested this on boards with Tegra, iMX.6 and Exynos SoCs, and these
 patches were enough to eliminate all the deferred probes.

 With this series I get the kernel to output to the panel in 0.5s, instead of 
 2.8s.

 That's certainly compelling.

Have to say that those numbers are with the serial console enabled
(without, it's 0.5s vs 1.5s), but on machines that take longer to boot
we should see bigger gains because we won't be sending devices to the
end of the queue when their probe is deferred.

Regards,

Tomeu

 Rob


 Regards,

 Tomeu

 [0] http://lists.freedesktop.org/archives/dri-devel/2014-August/066527.html

 [1] https://lkml.org/lkml/2014/5/12/452

 Tomeu Vizoso (21):
   regulator: core: Reduce critical area in _regulator_get
   ARM: tegra: Add gpio-ranges property
   ARM: tegra: Register drivers before devices
   ARM: EXYNOS: Register drivers before devices
   ARM i.MX6q: Register drivers before devices
   of/platform: Add of_platform_device_ensure()
   of/platform: Ensure device registration on lookup
   gpio: Probe GPIO drivers on demand
   gpio: 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 master 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

Re: [PATCH 00/21] On-demand device registration

2015-06-11 Thread Tomeu Vizoso 
On 06/11/2015 12:17 PM, Alexander Holler wrote:
 Am 11.06.2015 um 10:12 schrieb Linus Walleij:
 On Wed, Jun 10, 2015 at 10:28 AM, Alexander Holler hol...@ahsoftware.de 
 wrote:
 Am 10.06.2015 um 09:30 schrieb Linus Walleij:

 i2c host comes out, probes the regulator driver, regulator driver
 probes and then the regulator_get() call returns.

 This requires instrumentation on anything providing a resource
 to another driver like those I mentioned and a lot of overhead
 infrastructure, but I think it's the right approach. However I don't
 know if I would ever be able to pull that off myself, I know talk
 is cheap and I should show the code instead.

 You would end up with the same problem of deadlocks as currently, and you
 would still need something ugly like the defered probe brutforce to avoid
 them.

 Sorry I don't get that. Care to elaborate on why?
 
 Because loading/initializing on demand doesn't give you any solved order 
 of drivers to initialize. And it can't because it has no idea about the 
 requirements of other drivers.

So, this is only about ordering device probing. All built-in drivers
have already registered themselves by when we start probing.

 The reason why it might work better in 
 the case of the tegra is that it might give you another initialization 
 order than the one which is currently choosen, which, by luck, might be 
 a better one.

Note that this series was also tested on iMX.6, Exynos and OMAP4.

 But maybe I missed something, I haven't looked at the patches at all. 

It's a really small patchset :)

  19 files changed, 130 insertions(+), 45 deletions(-)

Thanks,

Tomeu

 But just loading on demand, can't magically give you a working order of 
 drivers to initialize. E.g. how do you choose the first driver to 
 initialize?
 
 Regards,
 
 Alexander Holler
 

--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/21] On-demand device registration

2015-06-10 Thread Tomeu Vizoso 
On 10 June 2015 at 09:30, Linus Walleij linus.wall...@linaro.org wrote:
 On Tue, Jun 2, 2015 at 12:14 PM, Tomeu Vizoso
 tomeu.viz...@collabora.com wrote:
 On 2 June 2015 at 10:48, Linus Walleij linus.wall...@linaro.org wrote:

 This is what systemd is doing in userspace for starting services:
 ask for your dependencies and wait for them if they are not
 there. So drivers ask for resources and wait for them. It also
 needs to be abstract, so for example we need to be able to
 hang on regulator_get() until the driver is up and providing that
 regulator, and as long as everything is in slowpath it should
 be OK. (And vice versa mutatis mutandis for clk, gpio, pin
 control, interrupts (!) and DMA channels for example.)

 I understood above that you propose probing devices in order, but now
 you mention that resource getters would block until the dependency is
 fulfilled which confuses me because if we are probing in order then
 all dependencies would be fulfilled before the device in question gets
 probed.

 Sorry, the problem space is a bit convoluted so the answers
 get a bit convoluted. Maybe I'm thinking aloud and altering the course
 of my thoughts as I type...

 I guess there can be explicit dependencies for resources like this
 patch does, but another way would be for all resource fetch functions
 to be instrumented, so that you do not block until you try to take
 a resource that is not yet there, e.g.:

 regulator_get(...) - not available, so:
 - identify target regulator provider - this will need instrumentation
 - probe it

 It then turns out the regulator driver is on the i2c bus, so we
 need to probe the i2c driver:
 - identify target i2c host for the regulator driver - this will need
   instrumentation
 - probe the i2c host driver

 i2c host comes out, probes the regulator driver, regulator driver
 probes and then the regulator_get() call returns.

Hmm, if I understand correctly what you say, this is exactly what this
particular series does:

regulator_get - of_platform_device_ensure - probe() on the platform
device that encloses the requested device node (i2c host) - i2c slave
gets probed and the regulator registered - regulator_get returns the
requested resource

The downside I'm currently looking at is that an explicit dependency
graph would be useful to have for other purposes. For example to print
a neat warning when a dependency cannot be fulfilled. Or to refuse to
unbind a device which other devices depend on, or to automatically
unbind the devices that depend on it, or to print a warning if a
device is hotplugged off and other devices depend on it.

 This requires instrumentation on anything providing a resource
 to another driver like those I mentioned and a lot of overhead
 infrastructure, but I think it's the right approach. However I don't
 know if I would ever be able to pull that off myself, I know talk
 is cheap and I should show the code instead.

Yeah, if you can give it a second look and say if it matches what you
wrote above, it would be very much appreciated.

 Deepest respect for your efforts!

Thanks!

Tomeu

 Yours,
 Linus Walleij
 ___
 dri-devel mailing list
 dri-de...@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/21] On-demand device registration

2015-06-04 Thread Tomeu Vizoso 
On 3 June 2015 at 21:57, grygorii.stras...@linaro.org
grygorii.stras...@linaro.org wrote:
 Hi Tomeu,

 On 05/28/2015 07:33 AM, Rob Herring wrote:
 On Mon, May 25, 2015 at 9:53 AM, Tomeu Vizoso tomeu.viz...@collabora.com 
 wrote:
 I have a problem with the panel on my Tegra Chromebook taking longer than
 expected to be ready during boot (Stéphane Marchesin reported what is
 basically the same issue in [0]), and have looked into ordered probing as a
 better way of solving this than moving nodes around in the DT or playing 
 with
 initcall levels.

 While reading the thread [1] that Alexander Holler started with his series 
 to
 make probing order deterministic, it occurred to me that it should be 
 possible
 to achieve the same by registering devices as they are referenced by other
 devices.

 I like the concept and novel approach.

 This basically reuses the information that is already implicit in the 
 probe()
 implementations, saving us from refactoring existing drivers or adding
 information to DTBs.

 Something I'm not completely happy with is that I have had to move the call 
 to
 of_platform_populate after all platform drivers have been registered.
 Otherwise I don't see how I could register drivers on demand as we don't 
 have
 yet each driver's compatible strings.

 Yeah, this is the opposite of what we'd really like. Ideally, we would
 have a solution that works for modules too. However, we're no worse
 off. We pretty much build-in dependencies to avoid module ordering
 problems.

 Perhaps we need to make the probing on-demand rather than simply on
 device-driver match occurring.

 For machs that don't move of_platform_populate() to a later point, these
 patches shouldn't cause any problems but it's not guaranteed that we'll 
 avoid
 all the deferred probes as some drivers may not be registered yet.

 Ideally, of_platform_populate is not explicitly called by each
 platform. So I think we need to make this work for the default case.

 I have tested this on boards with Tegra, iMX.6 and Exynos SoCs, and these
 patches were enough to eliminate all the deferred probes.

 With this series I get the kernel to output to the panel in 0.5s, instead 
 of 2.8s.

 That's certainly compelling.

 I've found your idea about moving device registration later during System boot
 very interesting so I've decided to try it on dra7-evem (TI) :).
 It's good to know time during Kernel boot when we can assume that all drivers 
 are
 ready for probing, so there are more ways to control probing order.

Thanks, though right now I'm following Rob's suggestion and only delay
probing, not registration. The patch is really simple (applies on
linux-next, with async probing):

diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 8da8e07..7e6b1e1 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -407,6 +407,11 @@ int driver_probe_device(struct device_driver
*drv, struct device *dev)
if (!device_is_registered(dev))
return -ENODEV;

+   if (!driver_deferred_probe_enable) {
+   driver_deferred_probe_add(dev);
+   return 0;
+   }
+
pr_debug(bus: '%s': %s: matched device %s with driver %s\n,
 drv-bus-name, __func__, dev_name(dev), drv-name);

@@ -585,7 +590,7 @@ EXPORT_SYMBOL_GPL(device_attach);

 void device_initial_probe(struct device *dev)
 {
-   __device_attach(dev, true);
+   __device_attach(dev, driver_deferred_probe_enable);
 }

 static int __driver_attach(struct device *dev, void *data)

 Pls, Note here that TI OMAP2+ mach is not pure DT mach - it's combination of
 DT and not DT devices/drivers.

 Ok. So What was done...

 LKML Linux 4.1-rc3 (a simple case)
 1) use your patches 3/4 as reference (only these two patches :)
 2) move of_platform_populate later at device_initcall_sync time
 Boot time reduction ~0.4 sec

I'm a bit surprised at such a big improvement. May I ask how you are
measuring it?

 TI Android Kernel 3.14 (NOT a simple case)
 1) use your patches 3/4 as reference (only these two patches :)
 2) move of_platform_populate later at device_initcall_sync time
 3) make it to boot (not sure I've fixed all issues, but those which
break the System boot):
  - split non-DT and DT devices registration in platform code;
  - keep non-DT devices registration from .init_machine() [arch_initcall]
  - move DT-devices registration at device_initcall_sync time
  - fix drivers which use platform_driver_probe().
Note. Now there are at about ~190 occurrences of this macro in Kernel.
  - re-order few devices in DT (4 devices)
  - fix one driver which uses of_find_device_by_node() wrongly
Note. This API is used some times with assumption that
requested dev has been probed already.
 Boot time reduction ~0.3 sec. Probing of some devices are still deferred.

I got no deferred probes on a pandaboard with just these changes:

https://git.collabora.com/cgit/user/tomeu/linux.git/commit/?id=1586c6f50b3d3c65dc219a3cdc3327d798cabca6

Re: [PATCH 00/21] On-demand device registration

2015-06-02 Thread Tomeu Vizoso 
On 2 June 2015 at 10:48, Linus Walleij linus.wall...@linaro.org wrote:
 On Mon, May 25, 2015 at 4:53 PM, Tomeu Vizoso
 tomeu.viz...@collabora.com wrote:

 have looked into ordered probing as a
 better way of solving this than moving nodes around in the DT or playing with
 initcall levels.

 While reading the thread [1] that Alexander Holler started with his series to
 make probing order deterministic, it occurred to me that it should be 
 possible
 to achieve the same by registering devices as they are referenced by other
 devices.

 This is pretty cool, but a too local solution to a global problem.

 Deferred probe and initcall reordering, silly as they may seem,
 does not require you to use device tree.

 The real solution, which I think I pointed out already when we
 added deferred probe, is to put dependency graphs in the drivers

By this you mean something like what Thierry suggested here?

http://article.gmane.org/gmane.linux.kernel/1774623

 and have the kernel device driver core percolate dependecies by
 walking the graph on probing driver, removing driver (usually the
 inverse use case), [runtime] suspend and [runtime] resumeing
 a driver. Possibly the dependencies will even be different
 depending on use case.

 This is what systemd is doing in userspace for starting services:
 ask for your dependencies and wait for them if they are not
 there. So drivers ask for resources and wait for them. It also
 needs to be abstract, so for example we need to be able to
 hang on regulator_get() until the driver is up and providing that
 regulator, and as long as everything is in slowpath it should
 be OK. (And vice versa mutatis mutandis for clk, gpio, pin
 control, interrupts (!) and DMA channels for example.)

I understood above that you propose probing devices in order, but now
you mention that resource getters would block until the dependency is
fulfilled which confuses me because if we are probing in order then
all dependencies would be fulfilled before the device in question gets
probed.

 So if this should be solved it should be solved in an abstract way
 in the device driver core available for all, then have calls calling
 out to DT, ACPI, possibly even PCI or USB (as these
 enumerate devices themselves) to obtain a certain
 dependency.

Yeah, I was planning looking into this now that I got it working with
async probing.

Thanks,

Tomeu

 Yours,
 Linus Walleij
 ___
 dri-devel mailing list
 dri-de...@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 00/21] On-demand device registration

2015-05-25 Thread Tomeu Vizoso 
Hello,

I have a problem with the panel on my Tegra Chromebook taking longer than
expected to be ready during boot (Stéphane Marchesin reported what is
basically the same issue in [0]), and have looked into ordered probing as a
better way of solving this than moving nodes around in the DT or playing with
initcall levels.

While reading the thread [1] that Alexander Holler started with his series to
make probing order deterministic, it occurred to me that it should be possible
to achieve the same by registering devices as they are referenced by other
devices.

This basically reuses the information that is already implicit in the probe()
implementations, saving us from refactoring existing drivers or adding
information to DTBs.

Something I'm not completely happy with is that I have had to move the call to
of_platform_populate after all platform drivers have been registered.
Otherwise I don't see how I could register drivers on demand as we don't have
yet each driver's compatible strings.

For machs that don't move of_platform_populate() to a later point, these
patches shouldn't cause any problems but it's not guaranteed that we'll avoid
all the deferred probes as some drivers may not be registered yet.

I have tested this on boards with Tegra, iMX.6 and Exynos SoCs, and these
patches were enough to eliminate all the deferred probes.

With this series I get the kernel to output to the panel in 0.5s, instead of 
2.8s.

Regards,

Tomeu

[0] http://lists.freedesktop.org/archives/dri-devel/2014-August/066527.html

[1] https://lkml.org/lkml/2014/5/12/452

Tomeu Vizoso (21):
  regulator: core: Reduce critical area in _regulator_get
  ARM: tegra: Add gpio-ranges property
  ARM: tegra: Register drivers before devices
  ARM: EXYNOS: Register drivers before devices
  ARM i.MX6q: Register drivers before devices
  of/platform: Add of_platform_device_ensure()
  of/platform: Ensure device registration on lookup
  gpio: Probe GPIO drivers on demand
  gpio: 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 master 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

 arch/arm/boot/dts/tegra124.dtsi |  1 +
 arch/arm/mach-exynos/exynos.c   |  4 +--
 arch/arm/mach-imx/mach-imx6q.c  | 12 -
 arch/arm/mach-tegra/tegra.c | 21 ++-
 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  |  3 +++
 drivers/of/platform.c   | 53 +
 drivers/phy/phy-core.c  |  3 +++
 drivers/pinctrl/devicetree.c|  2 ++
 drivers/power/power_supply_core.c   |  3 +++
 drivers/pwm/core.c  |  3 +++
 drivers/regulator/core.c| 45 +++
 drivers/usb/phy/phy.c   |  3 +++
 drivers/video/backlight/backlight.c |  3 +++
 include/linux/of_platform.h |  2 ++
 19 files changed, 130 insertions(+), 45 deletions(-)

-- 
2.4.1

--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 13/21] i2c: core: Probe i2c master devices on demand

2015-05-25 Thread Tomeu Vizoso 
When looking up an i2c master through its DT node, ensure that the
corresponding device has been registered.

Signed-off-by: Tomeu Vizoso tomeu.viz...@collabora.com
---
 drivers/i2c/i2c-core.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 987c124..8c9352e 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -40,6 +40,7 @@
 #include linux/of.h
 #include linux/of_device.h
 #include linux/of_irq.h
+#include linux/of_platform.h
 #include linux/clk/clk-conf.h
 #include linux/completion.h
 #include linux/hardirq.h
@@ -1339,6 +1340,8 @@ struct i2c_adapter *of_find_i2c_adapter_by_node(struct 
device_node *node)
 {
struct device *dev;
 
+   of_platform_device_ensure(node);
+
dev = bus_find_device(i2c_bus_type, NULL, node,
 of_dev_node_match);
if (!dev)
-- 
2.4.1

--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html