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
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 L
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
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 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 wi
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 Linu
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 regu
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
order nor does it (re)solve
dependencies (besides directly from one driver to another, but that
isn't enough), nor does it solve the problem of identifying drivers (the
other end of such an instrumented on-demand-initialization-call). So all
it would be is some fancy on-demand initialization without having solved
any problem.
Sorry if that sounds hard. Maybe I miss something. But I don't see any
currently existing problem the above described solution would solve,
besides beeing something different (which shouldn't be the goal).
Alexander Holler
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. So what would you win with that instrumentation?
Alexander Holler
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
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
&g
;> 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
>>
init got started. Besides that the
würgaround of defered init (which, btw. leads devs to supress error
messages, which is especially bad if you are searching a problem) isn't
needed anymore if you have a list of dependecies (however you get it,
I've used DT because the dependencies already are all there).
Regards,
Alexander Holler
entify (at least most)
drivers. I've already posted a patch for that around a year ago and now
Tomeu did almost the same.
However one wants to make a deterministic order to load drivers, there
will be always the need to know which drivers one has to sort.
Regards,
Alexander Holler
Am 27.05.2015 um 19:35 schrieb Russell King - ARM Linux:
> On Wed, May 27, 2015 at 02:45:48PM +0200, Alexander Holler wrote:
>> Hello,
>>
>> I've just build and booted the Etnaviv driver as module with Kernel 4.0.4.
>
> You may wish to try using my patch set
400 7e868e14 000186d0 76e9440c 600e0010 01c09d8c 3136315b
203a5d39
[<7f05d4f0>] (etnaviv_buffer_init [etnaviv]) from [<0001>] (0x1)
Code: eb4c93a7 e28dd014 e8bd8030 e5903050 (e5932058)
---[ end trace e3e10844e84f28b4 ]---
I've tried it two times, both ended with the same oops. So it seems to
be reproducible (here).
I haven't had a deeper look at the source, but after a quick look I
assume a fix isn't that hard.
Regards,
Alexander Holler
17 matches
Mail list logo
