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éph
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 [
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
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 d
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 possibl
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
scop
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
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'v
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,
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 de
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 a
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 r
On 06/11/2015 10:15 AM, Linus Walleij wrote:
> 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
>>>
>>>
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
Am 10.06.2015 um 14:23 schrieb Andrzej Hajda:
> 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
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
Am 10.06.2015 um 09:30 schrieb Linus Walleij:
> 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
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 chan
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 (d
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.
Unf
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.Strashko at 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
On 06/04/2015 11:39 AM, Tomeu Vizoso wrote:
> On 3 June 2015 at 21:57, Grygorii.Strashko at linaro.org
> wrote:
>> On 05/28/2015 07:33 AM, Rob Herring wrote:
>>> On Mon, May 25, 2015 at 9:53 AM, Tomeu Vizoso >> collabora.com> wrote:
I have a problem with the panel on my Tegra Chromebook takin
On 3 June 2015 at 21:57, Grygorii.Strashko at 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 > collabora.com> wrote:
>>> I have a problem with the panel on my Tegra Chromebook taking longer than
>>> expected to be ready
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 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
> bett
Am 02.06.2015 um 10:48 schrieb Linus Walleij:
> 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 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
> bette
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 playi
35 matches
Mail list logo
