On Wed, Jul 11, 2007 at 12:55:31PM -0500, Josh Boyer wrote:
> On Wed, 2007-07-11 at 19:49 +0200, Segher Boessenkool wrote:
> > > + UIC0: interrupt-controller0 {
> >
> > Why not just "interrupt-controller"?
>
> Copy/paste error from Ebony DTS, which has multiple UICs. Will fix.
>
> >
> > > +
>> Yes indeed. The problem with your suggested "obvious way"
>
> I said it was obvious, not obviously correct. :-)
I know :-)
>> is that you wouldn't get a unit address included if your
>> interrupt-map points (for some entry) at your device tree
>> parent, either. Not all that hypothetical.
>
Segher Boessenkool wrote:
> Yes indeed. The problem with your suggested "obvious way"
I said it was obvious, not obviously correct. :-)
> is that you wouldn't get a unit address included if your
> interrupt-map points (for some entry) at your device tree
> parent, either. Not all that hypotheti
>> See above. Besides, as I said, default values are crap. And no,
>> it's not
>> obvious which nodes define a physical address space or not, at
>> least not
>> for a generic parser.
>
> The obvious way (which indeed isn't what the suggested algorithm
> does --
> but the suggested algorithm d
>> Yes, I shouldn't say "defaulted" -- a unit interrupt specifier
>> simply has no unit address part, in an interrupt domain that
>> doesn't correspond to a "normal" bus. But saying it like this
>> is a little bit inexact, and it uses more words.
>>
>>> which is why I tend to prefer having it
>>>
> It could lead someone to the erroneous conclusion that an #address-cells
> other than zero in an interrupt controller that is not a device parent is
> in any way a sane or supported thing to do.
I fail why anyone would ever want to do it though :-)
> It could lead people to write code that doe
On Wed, Jul 18, 2007 at 07:25:57AM +1000, Benjamin Herrenschmidt wrote:
> > > which is why I tend to prefer having it
> > > explicitely in the interrupt controller node :-)
> >
> > Which is simply incorrect.
>
> It's absolutely not. Please, stop that moronic pin-head behaviour and
> find me a sin
> Yes, I shouldn't say "defaulted" -- a unit interrupt specifier
> simply has no unit address part, in an interrupt domain that
> doesn't correspond to a "normal" bus. But saying it like this
> is a little bit inexact, and it uses more words.
>
> > which is why I tend to prefer having it
> > exp
> Right. See, there are people like me that don't know what the
> default values
> are/should be. Having them explicitly listed, even if it's
> redundant, serves
> as a good learning aid.
_Only_ if it's redundant. Not if it has a meaning different
from having the property not there at all.
> + #address-cells = <0>;
> + #size-cells = <0>;
No need for these.
>>>
>>> Isn't a good practice to put #address-cells in interrupt controller
>>> nodes?
>>
>> It is not.
>
> Well, that's debatable... but yes, a strict reading of the spec would
> say that you shou
On Tue, Jul 17, 2007 at 07:47:26AM +1000, Benjamin Herrenschmidt wrote:
> > That "typical practice" is inspired by the need to explicitly
> > put #address-cells and #size-cells into the device tree if you
> > want Linux to properly parse the device tree, even if the default
> > values would work pe
On Mon, 2007-07-16 at 17:18 -0500, Scott Wood wrote:
>
> OK... but if you're doing a pure IRQ number conversion, the only useful
> #address-cells would be zero, which makes it a reasonable default IMHO
> (unlike the arbitrary 2 for regular traversal).
It does make a reasonable default. The thi
Benjamin Herrenschmidt wrote:
> No, interrupt maps are useful in devices with no children in some corner
> cases. Remember that a map doesnt need to use the address part of the
> source specifier, thus it can be used to do a pure domain->domain
> conversion of the irq numbers, what sort of thing. T
> > I would personally be inclined to define that whatever spec we come up
> > with always require #address-cells/#size-cells for any node that can
> > have either device children or interrupt children, and ban default
> > values alltogether.
>
> Did you really mean #size-cells here? Shouldn't i
On Mon, 2007-07-16 at 16:55 -0500, Scott Wood wrote:
> Benjamin Herrenschmidt wrote:
> > I would personally be inclined to define that whatever spec we come up
> > with always require #address-cells/#size-cells for any node that can
> > have either device children or interrupt children, and ban def
[snip]
> There is no child device node, but there are child interrupt
> nodes, and
> since the interrupt-tree uses #address/size-cells, it does make some
> sense to specify them.
>
> Yes, there is a default value when absent, but the simple
> fact that the
> default is different depending if yo
Benjamin Herrenschmidt wrote:
> I would personally be inclined to define that whatever spec we come up
> with always require #address-cells/#size-cells for any node that can
> have either device children or interrupt children, and ban default
> values alltogether.
When is #size-cells used in the i
On Mon, 2007-07-16 at 16:34 +0200, Segher Boessenkool wrote:
> >>> + #address-cells = <0>;
> >>> + #size-cells = <0>;
> >>
> >> No need for these.
> >
> > Isn't a good practice to put #address-cells in interrupt controller
> > nodes?
>
> It is not.
Well, that's debatable... but ye
>>> + #address-cells = <0>;
>>> + #size-cells = <0>;
>>
>> No need for these.
>
> Isn't a good practice to put #address-cells in interrupt controller
> nodes?
It is not.
> If the device tree has an interrupt map defined the interrupt
> parent 'unit interrupt specifier' has to
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> On Behalf Of Segher Boessenkool
> Sent: Wednesday, July 11, 2007 12:50 PM
> To: Josh Boyer
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: [RFC][PATCH 6/8] Walnut DTS
>
> >
>>> + plb {
>>> + ranges;
>>
>> Please make the valid address ranges explicit here.
>
> Meaning what exactly? I thought just specifying "ranges;" simply said
> "the addresses from this node don't have any translation from the
> parent
> node" (or something like that).
Just list the
On Wed, 2007-07-11 at 19:49 +0200, Segher Boessenkool wrote:
> > + UIC0: interrupt-controller0 {
>
> Why not just "interrupt-controller"?
Copy/paste error from Ebony DTS, which has multiple UICs. Will fix.
>
> > + #address-cells = <0>;
> > + #size-cells = <0>;
>
> No nee
> + UIC0: interrupt-controller0 {
Why not just "interrupt-controller"?
> + #address-cells = <0>;
> + #size-cells = <0>;
No need for these.
>
> + plb {
> + ranges;
Please make the valid address ranges explicit here.
> + SDRAM0: memory-cont
On Wed, 2007-07-11 at 16:26 +0200, Stefan Roese wrote:
> On Wednesday 11 July 2007, Josh Boyer wrote:
> > + PowerPC,[EMAIL PROTECTED] {
> > + device_type = "cpu";
> > + reg = <0>;
> > + clock-frequency = ; /* Filled in by zImage */
> >
On Wednesday 11 July 2007, Josh Boyer wrote:
> + PowerPC,[EMAIL PROTECTED] {
> + device_type = "cpu";
> + reg = <0>;
> + clock-frequency = ; /* Filled in by zImage */
> + timebase-frequency = <0>; /* Filled
25 matches
Mail list logo
