Am 28.08.2014 11:23, schrieb Catalin Marinas:
On Thu, Aug 28, 2014 at 07:50:36AM +0100, Alexander Holler wrote:
And I wonder how the ACPI world solves that problem. My guess would be
hardcoded stuff in the firmware-blob (BIOS), just like it happened with
board files, but I've never seen BIOS c
On Thu, Aug 28, 2014 at 07:50:36AM +0100, Alexander Holler wrote:
> Am 27.08.2014 18:37, schrieb Stephen Warren:
> > Of course, there are probably cases where we could/should add some more
> > phandles/... and likewise cases where we shouldn't. That's why detailed
> > research is needed.
>
> Just
Am 27.08.2014 18:37, schrieb Stephen Warren:
Of course, there are probably cases where we could/should add some more
phandles/... and likewise cases where we shouldn't. That's why detailed
research is needed.
Just because I'm curious, I wonder how this research does or shoud look
like.
Defe
Am 27.08.2014 19:52, schrieb Catalin Marinas:
Irrespective though, a new kernel needs to work against an old DT,
I fully agree. But we shouldn't really extend the "old DT" statement to
a new ARMv8 SoC ;).
Or any new v7 SoC. And even poor users of current ARM HW do want use
their HW. And the
On Wed, Aug 27, 2014 at 05:37:58PM +0100, Stephen Warren wrote:
> On 08/27/2014 10:30 AM, Alexander Holler wrote:
> > Am 27.08.2014 18:22, schrieb Stephen Warren:
> >> On 08/27/2014 08:44 AM, Catalin Marinas wrote:
> >
> >>> It's not just optimisation but an important feature for new arm64 SoCs.
>
Am 27.08.2014 18:37, schrieb Stephen Warren:
On 08/27/2014 10:30 AM, Alexander Holler wrote:
Am 27.08.2014 18:22, schrieb Stephen Warren:
On 08/27/2014 08:44 AM, Catalin Marinas wrote:
It's not just optimisation but an important feature for new arm64 SoCs.
Given some Tegra discussions recent
On 08/27/2014 10:30 AM, Alexander Holler wrote:
Am 27.08.2014 18:22, schrieb Stephen Warren:
On 08/27/2014 08:44 AM, Catalin Marinas wrote:
It's not just optimisation but an important feature for new arm64 SoCs.
Given some Tegra discussions recently, in many cases the machine_desc
use on arm
Am 27.08.2014 18:22, schrieb Stephen Warren:
On 08/27/2014 08:44 AM, Catalin Marinas wrote:
It's not just optimisation but an important feature for new arm64 SoCs.
Given some Tegra discussions recently, in many cases the machine_desc
use on arm is primarily to initialise devices in the right o
On 08/27/2014 08:44 AM, Catalin Marinas wrote:
On Wed, Aug 27, 2014 at 11:34:32AM +0100, Grant Likely wrote:
On Tue, 26 Aug 2014 11:11:07 +0100, Mark Rutland wrote:
On Tue, Aug 26, 2014 at 10:42:04AM +0100, Alexander Holler wrote:
Am 26.08.2014 10:49, schrieb Thierry Reding:
On Tue, Aug 26,
On Wed, Aug 27, 2014 at 11:34:32AM +0100, Grant Likely wrote:
> On Tue, 26 Aug 2014 11:11:07 +0100, Mark Rutland wrote:
> > On Tue, Aug 26, 2014 at 10:42:04AM +0100, Alexander Holler wrote:
> > > Am 26.08.2014 10:49, schrieb Thierry Reding:
> > > > On Tue, Aug 26, 2014 at 09:42:08AM +0100, Grant L
On Tue, 26 Aug 2014 11:11:07 +0100, Mark Rutland wrote:
> On Tue, Aug 26, 2014 at 10:42:04AM +0100, Alexander Holler wrote:
> > Am 26.08.2014 10:49, schrieb Thierry Reding:
> > > On Tue, Aug 26, 2014 at 09:42:08AM +0100, Grant Likely wrote:
> > >> On Mon, 25 Aug 2014 15:37:16 +0200, Thierry Reding
Am 27.08.2014 09:16, schrieb Alexander Holler:
Why should I? I've posted patches along with a lot of comments and
explanations, and e.g. you are just talking that it should be made like
my patches already did. And others do talk too like my patches and the
accompanying comments from me which exp
Am 26.08.2014 15:58, schrieb Jon Loeliger:
I think we need to do the complete topsort *before* we attempt
to do any probing. So three steps:
1) Graph Construction
Add a new "emit dependencies" function to driver bindings.
Iterate over known devices or nodes in the DT in any
On Tue, Aug 26, 2014 at 08:58:34AM -0500, Jon Loeliger wrote:
> > >>
> > >> Drivers don't provide that information (dependencies) in any usable way.
> > >> And
> > >> as you said yourself, it's already contained in phandles. So what we are
> > >> discussing here about? The proposal to use phandles
> >>
> >> Drivers don't provide that information (dependencies) in any usable way.
> >> And
> >> as you said yourself, it's already contained in phandles. So what we are
> >> discussing here about? The proposal to use phandles for that is already on
> >> the table since several month. ;)
> >>
> >>
Am 26.08.2014 13:47, schrieb Thierry Reding:
On Tue, Aug 26, 2014 at 01:23:54PM +0200, Alexander Holler wrote:
Am 26.08.2014 13:08, schrieb Thierry Reding:
On Tue, Aug 26, 2014 at 12:44:35PM +0200, Alexander Holler wrote:
Am 26.08.2014 12:25, schrieb Thierry Reding:
On Tue, Aug 26, 2014 at 11
On Tue, Aug 26, 2014 at 01:23:54PM +0200, Alexander Holler wrote:
> Am 26.08.2014 13:08, schrieb Thierry Reding:
> >On Tue, Aug 26, 2014 at 12:44:35PM +0200, Alexander Holler wrote:
> >>Am 26.08.2014 12:25, schrieb Thierry Reding:
> >>>On Tue, Aug 26, 2014 at 11:42:04AM +0200, Alexander Holler wrot
Am 26.08.2014 13:08, schrieb Thierry Reding:
On Tue, Aug 26, 2014 at 12:44:35PM +0200, Alexander Holler wrote:
Am 26.08.2014 12:25, schrieb Thierry Reding:
On Tue, Aug 26, 2014 at 11:42:04AM +0200, Alexander Holler wrote:
You need either the type information in the DTB (that's why I've add t
On Tue, Aug 26, 2014 at 12:44:35PM +0200, Alexander Holler wrote:
> Am 26.08.2014 12:25, schrieb Thierry Reding:
> >On Tue, Aug 26, 2014 at 11:42:04AM +0200, Alexander Holler wrote:
>
> >>You need either the type information in the DTB (that's why I've add those
> >>"dependencies" to identify phan
Am 26.08.2014 12:44, schrieb Alexander Holler:
Am 26.08.2014 12:25, schrieb Thierry Reding:
On Tue, Aug 26, 2014 at 11:42:04AM +0200, Alexander Holler wrote:
You need either the type information in the DTB (that's why I've add
those
"dependencies" to identify phandles), or you need to know ev
Am 26.08.2014 12:25, schrieb Thierry Reding:
On Tue, Aug 26, 2014 at 11:42:04AM +0200, Alexander Holler wrote:
You need either the type information in the DTB (that's why I've add those
"dependencies" to identify phandles), or you need to know every binding (at
"dependency-resolve-time" to ide
On Tue, Aug 26, 2014 at 11:42:04AM +0200, Alexander Holler wrote:
> Am 26.08.2014 10:49, schrieb Thierry Reding:
> >On Tue, Aug 26, 2014 at 09:42:08AM +0100, Grant Likely wrote:
> >>On Mon, 25 Aug 2014 15:37:16 +0200, Thierry Reding
> >> wrote:
> >[...]
> >>>There are somewhat standardized binding
On Tue, Aug 26, 2014 at 11:11:07AM +0100, Mark Rutland wrote:
> On Tue, Aug 26, 2014 at 10:42:04AM +0100, Alexander Holler wrote:
> > Am 26.08.2014 10:49, schrieb Thierry Reding:
> > > On Tue, Aug 26, 2014 at 09:42:08AM +0100, Grant Likely wrote:
> > >> On Mon, 25 Aug 2014 15:37:16 +0200, Thierry R
Am 26.08.2014 10:51, schrieb Grant Likely:
Getting the dependency tree I think is only half the problem. The other
have is how to get the driver model to actually order probing using that
list. That problem is hard because the order drivers are probed is
currently determined by the interaction o
On Tue, Aug 26, 2014 at 10:42:04AM +0100, Alexander Holler wrote:
> Am 26.08.2014 10:49, schrieb Thierry Reding:
> > On Tue, Aug 26, 2014 at 09:42:08AM +0100, Grant Likely wrote:
> >> On Mon, 25 Aug 2014 15:37:16 +0200, Thierry Reding
> >> wrote:
> > [...]
> >>> There are somewhat standardized bi
Am 26.08.2014 10:51, schrieb Grant Likely:
On Mon, 25 Aug 2014 08:08:59 -0500, Jon Loeliger wrote:
Anyway, instead of going back and forth between "deferred probe is good"
and "deferred probe is bad", how about we do something useful now and
concentrate on how to make use of the information
On Mon, Aug 25, 2014 at 10:39:32AM +0100, Thierry Reding wrote:
> On Fri, Aug 22, 2014 at 02:19:19PM +0100, Mark Rutland wrote:
> > On Thu, Aug 21, 2014 at 08:19:00PM +0100, Alexander Holler wrote:
> > > Am 21.08.2014 16:02, schrieb Thierry Reding:
> > >
> > > > Anyway, those are all fairly standa
Am 26.08.2014 10:49, schrieb Thierry Reding:
On Tue, Aug 26, 2014 at 09:42:08AM +0100, Grant Likely wrote:
On Mon, 25 Aug 2014 15:37:16 +0200, Thierry Reding
wrote:
[...]
There are somewhat standardized bindings for the above and especially
for bindings of the type that clocks implement this
On Mon, 25 Aug 2014 08:08:59 -0500, Jon Loeliger wrote:
> >
>
> > Anyway, instead of going back and forth between "deferred probe is good"
> > and "deferred probe is bad", how about we do something useful now and
> > concentrate on how to make use of the information we have in DT with the
> > go
On Tue, Aug 26, 2014 at 09:42:08AM +0100, Grant Likely wrote:
> On Mon, 25 Aug 2014 15:37:16 +0200, Thierry Reding
> wrote:
[...]
> > There are somewhat standardized bindings for the above and especially
> > for bindings of the type that clocks implement this is trivial. We can
> > simply iterate
On Mon, 25 Aug 2014 15:37:16 +0200, Thierry Reding
wrote:
> On Mon, Aug 25, 2014 at 08:08:59AM -0500, Jon Loeliger wrote:
> > >
> >
> > > Anyway, instead of going back and forth between "deferred probe is good"
> > > and "deferred probe is bad", how about we do something useful now and
> > > co
Am 25.08.2014 15:08, schrieb Jon Loeliger:
Anyway, instead of going back and forth between "deferred probe is good"
and "deferred probe is bad", how about we do something useful now and
concentrate on how to make use of the information we have in DT with the
goal to reduce the number of cases
On Mon, Aug 25, 2014 at 09:13:59AM -0500, Jon Loeliger wrote:
> >
> >
> > > I believe some of the issues that need to be resolved are:
> > >
> > > 1) What constitutes a dependency?
> > > 2) How is that dependency expressed?
> > > 3) How do we add missing dependencies?
> > > 4) Bac
>
>
> > I believe some of the issues that need to be resolved are:
> >
> > 1) What constitutes a dependency?
> > 2) How is that dependency expressed?
> > 3) How do we add missing dependencies?
> > 4) Backward compatability problems.
> >
> > There are other questions, of course. I
On Mon, Aug 25, 2014 at 08:08:59AM -0500, Jon Loeliger wrote:
> >
>
> > Anyway, instead of going back and forth between "deferred probe is good"
> > and "deferred probe is bad", how about we do something useful now and
> > concentrate on how to make use of the information we have in DT with the
>
>
> Anyway, instead of going back and forth between "deferred probe is good"
> and "deferred probe is bad", how about we do something useful now and
> concentrate on how to make use of the information we have in DT with the
> goal to reduce the number of cases where deferred probing is required?
On Fri, Aug 22, 2014 at 02:19:19PM +0100, Mark Rutland wrote:
> On Thu, Aug 21, 2014 at 08:19:00PM +0100, Alexander Holler wrote:
> > Am 21.08.2014 16:02, schrieb Thierry Reding:
> >
> > > Anyway, those are all fairly standard reasons for where deferred probe
> > > triggers, and since I do like de
Am 22.08.2014 15:19, schrieb Mark Rutland:
On Thu, Aug 21, 2014 at 08:19:00PM +0100, Alexander Holler wrote:
Am 21.08.2014 16:02, schrieb Thierry Reding:
Anyway, those are all fairly standard reasons for where deferred probe
triggers, and since I do like deferred probe for it's simplicity and
On Thu, Aug 21, 2014 at 08:19:00PM +0100, Alexander Holler wrote:
> Am 21.08.2014 16:02, schrieb Thierry Reding:
>
> > Anyway, those are all fairly standard reasons for where deferred probe
> > triggers, and since I do like deferred probe for it's simplicity and
> > reliability I'd rather not try
Am 21.08.2014 16:02, schrieb Thierry Reding:
Anyway, those are all fairly standard reasons for where deferred probe
triggers, and since I do like deferred probe for it's simplicity and
reliability I'd rather not try to work around it if boot time is all
that people are concerned about.
It's ne
On Wed, May 14, 2014 at 03:19:14PM +0100, Grant Likely wrote:
> On Mon, 12 May 2014 18:47:51 +0200, Alexander Holler
> wrote:
> >
> > Hello,
> >
> > if I would have to describe the Linux kernels init system (before userspace
> > starts), it would be like:
> > Unknown functions with almost unkno
Am 14.05.2014 21:24, schrieb Alexander Holler:
> Am 14.05.2014 21:06, schrieb Rob Herring:
>> I still have not seen an example of A depends on B, deferred probe
>> fails because of ? and here is the code for A that works around the
>> problem.
>>
>>> Anyway, this feature is totally independ of the
Am 14.05.2014 21:06, schrieb Rob Herring:
> On Wed, May 14, 2014 at 12:45 PM, Alexander Holler
> wrote:
>> Am 14.05.2014 19:30, schrieb Rob Herring:
>>
>>> On Wed, May 14, 2014 at 11:23 AM, Alexander Holler
>>> wrote:
Am 14.05.2014 18:05, schrieb Grant Likely:
> On Wed, May 14
Am 14.05.2014 21:06, schrieb Rob Herring:
On Wed, May 14, 2014 at 12:45 PM, Alexander Holler wrote:
Am 14.05.2014 19:30, schrieb Rob Herring:
On Wed, May 14, 2014 at 11:23 AM, Alexander Holler
wrote:
Am 14.05.2014 18:05, schrieb Grant Likely:
On Wed, May 14, 2014 at 4:02 PM, Alexander Ho
Am 14.05.2014 20:16, schrieb Alexander Holler:
Am 14.05.2014 19:53, schrieb Alexander Holler:
Am 14.05.2014 19:45, schrieb Alexander Holler:
One of the biggest problem of the deferred probe stuff is the problem
how to identify real problems if everything ends up with a deferred
probe when an e
On Wed, May 14, 2014 at 12:45 PM, Alexander Holler wrote:
> Am 14.05.2014 19:30, schrieb Rob Herring:
>
>> On Wed, May 14, 2014 at 11:23 AM, Alexander Holler
>> wrote:
>>>
>>> Am 14.05.2014 18:05, schrieb Grant Likely:
>>>
On Wed, May 14, 2014 at 4:02 PM, Alexander Holler
wrote:
>
Am 14.05.2014 19:53, schrieb Alexander Holler:
Am 14.05.2014 19:45, schrieb Alexander Holler:
One of the biggest problem of the deferred probe stuff is the problem
how to identify real problems if everything ends up with a deferred
probe when an error occurs? That means if you display an error
Am 14.05.2014 19:45, schrieb Alexander Holler:
One of the biggest problem of the deferred probe stuff is the problem
how to identify real problems if everything ends up with a deferred
probe when an error occurs? That means if you display an error whenever
something is deferred, the log becomes
Am 14.05.2014 19:30, schrieb Rob Herring:
On Wed, May 14, 2014 at 11:23 AM, Alexander Holler wrote:
Am 14.05.2014 18:05, schrieb Grant Likely:
On Wed, May 14, 2014 at 4:02 PM, Alexander Holler
wrote:
Am 14.05.2014 16:19, schrieb Grant Likely:
Rather than a dtb schema change, for the mos
On Wed, May 14, 2014 at 11:23 AM, Alexander Holler wrote:
> Am 14.05.2014 18:05, schrieb Grant Likely:
>
>> On Wed, May 14, 2014 at 4:02 PM, Alexander Holler
>> wrote:
>>>
>>> Am 14.05.2014 16:19, schrieb Grant Likely:
>>>
>>>
Rather than a dtb schema change, for the most common properties (
Am 14.05.2014 18:05, schrieb Grant Likely:
On Wed, May 14, 2014 at 4:02 PM, Alexander Holler wrote:
Am 14.05.2014 16:19, schrieb Grant Likely:
Rather than a dtb schema change, for the most common properties (irqs,
clocks, gpios), we could extract dependencies at boot time. I don't like
the i
On Wed, May 14, 2014 at 4:02 PM, Alexander Holler wrote:
> Am 14.05.2014 16:19, schrieb Grant Likely:
>
>
>> Rather than a dtb schema change, for the most common properties (irqs,
>> clocks, gpios), we could extract dependencies at boot time. I don't like
>> the idea of adding a separate depends-o
Am 14.05.2014 16:19, schrieb Grant Likely:
Rather than a dtb schema change, for the most common properties (irqs,
clocks, gpios), we could extract dependencies at boot time. I don't like
the idea of adding a separate depends-on property because it is very
easy to get it out of sync with the actu
On Mon, 12 May 2014 18:47:51 +0200, Alexander Holler
wrote:
>
> Hello,
>
> if I would have to describe the Linux kernels init system (before userspace
> starts), it would be like:
> Unknown functions with almost unknown functionality are called in an almost
> random order.
>
> That reminded me
Hello,
if I would have to describe the Linux kernels init system (before userspace
starts), it would be like:
Unknown functions with almost unknown functionality are called in an almost
random order.
That reminded me that a kernel-maintainer once said to me:
"We should aim to make things synchro
55 matches
Mail list logo
