On Mon, Jun 22, 2015 at 10:23 AM, Tomeu Vizoso
wrote:
> On 28 May 2015 at 06:33, Rob Herring wrote:
>> On Mon, May 25, 2015 at 9:53 AM, Tomeu Vizoso
>> wrote:
>>> Hello,
>>>
>>> I have a problem with the panel on my Tegra Chromebook taking longer than
>>> expected to be ready during boot (Stépha
On 28 May 2015 at 06:33, Rob Herring wrote:
> On Mon, May 25, 2015 at 9:53 AM, Tomeu Vizoso
> 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
Am 15.06.2015 um 10:58 schrieb Linus Walleij:
On Sat, Jun 13, 2015 at 8:27 PM, Alexander Holler wrote:
And because you've said that "problem space is a bit convoluted" and I
disagree, here's a summary from my point of view:
1. All the necessary information (dependencies between drivers) alrea
On Sat, Jun 13, 2015 at 8:27 PM, Alexander Holler wrote:
> And because you've said that "problem space is a bit convoluted" and I
> disagree, here's a summary from my point of view:
>
> 1. All the necessary information (dependencies between drivers) already
> exists at compile time. The set of de
Am 12.06.2015 um 13:36 schrieb Alexander Holler:
Am 12.06.2015 um 13:19 schrieb Alexander Holler:
Am 12.06.2015 um 09:25 schrieb Linus Walleij:
On Thu, Jun 11, 2015 at 6:40 PM, Alexander Holler
wrote:
Am 11.06.2015 um 14:30 schrieb Linus Walleij:
Certainly it is possible to create deadlock
Am 12.06.2015 um 13:19 schrieb Alexander Holler:
Am 12.06.2015 um 09:25 schrieb Linus Walleij:
On Thu, Jun 11, 2015 at 6:40 PM, Alexander Holler
wrote:
Am 11.06.2015 um 14:30 schrieb Linus Walleij:
Certainly it is possible to create deadlocks in this scenario, but the
scope is not to create
Am 12.06.2015 um 09:25 schrieb Linus Walleij:
On Thu, Jun 11, 2015 at 6:40 PM, Alexander Holler wrote:
Am 11.06.2015 um 14:30 schrieb Linus Walleij:
Certainly it is possible to create deadlocks in this scenario, but the
scope is not to create an ubreakable system.
IAnd what happens if you
On Thu, Jun 11, 2015 at 6:40 PM, Alexander Holler wrote:
> Am 11.06.2015 um 14:30 schrieb Linus Walleij:
>> Certainly it is possible to create deadlocks in this scenario, but the
>> scope is not to create an ubreakable system.
>
> IAnd what happens if you run into a deadlock? Do you print "you've
Am 11.06.2015 um 14:30 schrieb Linus Walleij:
On Thu, Jun 11, 2015 at 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
wrote:
You would end up with the same problem of deadlocks as currently, and you
would st
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
>> wrote:
>>> Am 10.06.2015 um 09:30 schrieb Linus Walleij:
>>
i2c host comes out, probes the regulator driver, regulator driver
probes a
On Thu, Jun 11, 2015 at 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
>> wrote:
>>> You would end up with the same problem of deadlocks as currently, and you
>>> would still need something ugly like the def
Am 11.06.2015 um 13:24 schrieb Alexander Holler:
> Am 11.06.2015 um 12:17 schrieb Alexander Holler:
>> Am 11.06.2015 um 10:12 schrieb Linus Walleij:
>>> On Wed, Jun 10, 2015 at 10:28 AM, Alexander Holler
>>> wrote:
Am 10.06.2015 um 09:30 schrieb Linus Walleij:
>>>
> i2c host comes out, pr
Am 11.06.2015 um 12:17 schrieb Alexander Holler:
Am 11.06.2015 um 10:12 schrieb Linus Walleij:
On Wed, Jun 10, 2015 at 10:28 AM, Alexander Holler
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 regula
Am 11.06.2015 um 10:12 schrieb Linus Walleij:
On Wed, Jun 10, 2015 at 10:28 AM, Alexander Holler 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 instrumenta
On Wed, Jun 10, 2015 at 12:19 PM, Tomeu Vizoso
wrote:
> On 10 June 2015 at 09:30, Linus Walleij wrote:
>> 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
On Wed, Jun 10, 2015 at 10:28 AM, Alexander Holler 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
On 06/10/2015 12:19 PM, Tomeu Vizoso wrote:
> On 10 June 2015 at 09:30, Linus Walleij wrote:
>> On Tue, Jun 2, 2015 at 12:14 PM, Tomeu Vizoso
>> wrote:
>>> On 2 June 2015 at 10:48, Linus Walleij wrote:
>>
This is what systemd is doing in userspace for starting services:
ask for your de
On 10 June 2015 at 09:30, Linus Walleij wrote:
> On Tue, Jun 2, 2015 at 12:14 PM, Tomeu Vizoso
> wrote:
>> On 2 June 2015 at 10:48, Linus Walleij wrote:
>
>>> This is what systemd is doing in userspace for starting services:
>>> ask for your dependencies and wait for them if they are not
>>> the
On Tue, Jun 2, 2015 at 12:14 PM, Tomeu Vizoso
wrote:
> On 2 June 2015 at 10:48, Linus Walleij 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 al
Am 08.06.2015 um 20:14 schrieb Alexander Holler:
Am 08.06.2015 um 14:26 schrieb Enrico Weigelt, metux IT consult:
Am 04.06.2015 um 22:39 schrieb Alexander Holler:
> As it seems to have been forgotten or overread, I've mentioned in my
series of patches last year that, with a few changes, it's
Am 08.06.2015 um 14:26 schrieb Enrico Weigelt, metux IT consult:
Am 04.06.2015 um 22:39 schrieb Alexander Holler:
> As it seems to have been forgotten or overread, I've mentioned in my
series of patches last year that, with a few changes, it's possible to
let the algorithm I've used (dfs) to s
Am 04.06.2015 um 22:39 schrieb Alexander Holler:
> As it seems to have been forgotten or overread, I've mentioned in my
series of patches last year that, with a few changes, it's possible to
let the algorithm I've used (dfs) to spit out all drivers which can be
initialized in parallel.
Unfortu
Am 03.06.2015 um 23:12 schrieb Rob Clark:
> On Mon, May 25, 2015 at 10:53 AM, Tomeu Vizoso
> 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])
Am 03.06.2015 um 21:57 schrieb grygorii.stras...@linaro.org:
...
> So few comments from above:
> - registering devices later during the System boot may improve boot time.
> But resolving of all deferred probes may NOT improve boot time ;)
> Have you seen smth like this?
If someone is out fo
On 06/04/2015 11:39 AM, Tomeu Vizoso wrote:
> On 3 June 2015 at 21:57, grygorii.stras...@linaro.org
> wrote:
>> On 05/28/2015 07:33 AM, Rob Herring wrote:
>>> On Mon, May 25, 2015 at 9:53 AM, Tomeu Vizoso
>>> wrote:
I have a problem with the panel on my Tegra Chromebook taking longer than
>
On 3 June 2015 at 21:57, 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
>> wrote:
>>> I have a problem with the panel on my Tegra Chromebook taking longer than
>>> expected to be ready during boot (S
On Mon, May 25, 2015 at 10:53 AM, Tomeu Vizoso
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
> bette
Hi Tomeu,
On 05/28/2015 07:33 AM, Rob Herring wrote:
> On Mon, May 25, 2015 at 9:53 AM, Tomeu Vizoso
> 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]),
On 2 June 2015 at 10:48, Linus Walleij wrote:
> On Mon, May 25, 2015 at 4:53 PM, Tomeu Vizoso
> 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
On Mon, May 25, 2015 at 4:53 PM, Tomeu Vizoso
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 de
On Mon, May 25, 2015 at 9:53 AM, Tomeu Vizoso
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
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 playin
32 matches
Mail list logo
