address-permutation = <0 1 3 2 4 5 7 6 e f d c a b 9 8>;
>
>>> Yes, I was contemplating something like that.
>
>> Let's not define this until we need it though :-)
>
>Let's ot even think of it,
It is good to think about it, for the simple reason that it
validates whether the current desig
Segher Boessenkool wrote:
>>>address-permutation = <0 1 3 2 4 5 7 6 e f d c a b 9 8>;
>>Yes, I was contemplating something like that.
> Let's not define this until we need it though :-)
Let's ot even think of it, since this will end up in a "catch all" driver,
and yet this may be not enoug
Hello.
I'm having sort of vacation, mostly away from computer, hence my belated
reply...
David Gibson wrote:
>Can you describe some of the options for *not* direct mapped flash
>chips - I can't reasonably come up with a way of describing the
>distinction when I've never seen NOR
> Why is "ranges" conceptually wrong?
The flash partitions aren't separate devices sitting on a
"flash bus", they are "sub-devices" of their parent.
>>>
>>> Well, yes, but nonetheless the partitions show up as part of the
>>> overall physical address space. How do you encode tha
On Thu, Aug 09, 2007 at 10:00:47PM +0200, Segher Boessenkool wrote:
> >> For the JEDEC chips, we need a "vendor-id" and "device-id"
> >> property at least (or similar names -- whatever is general
> >> practice for this); both are a single byte, encoded as with
> >> encode-int.
> >
> > Ok... should
On Thu, Aug 09, 2007 at 09:53:41PM +0200, Segher Boessenkool wrote:
> I haven't heard or thought of anything better either. Using
> "ranges"
> is conceptually wrong, even ignoring the technical problems that
> come
> with it.
> >>>
> >>> Why is "ranges" conceptually wron
>> For the JEDEC chips, we need a "vendor-id" and "device-id"
>> property at least (or similar names -- whatever is general
>> practice for this); both are a single byte, encoded as with
>> encode-int.
>
> Ok... should those really be separate properties, or should that go in
> compatible, i.e. som
I haven't heard or thought of anything better either. Using
"ranges"
is conceptually wrong, even ignoring the technical problems that
come
with it.
>>>
>>> Why is "ranges" conceptually wrong?
>>
>> The flash partitions aren't separate devices sitting on a
>> "flash bus",
On Tue, Aug 07, 2007 at 06:33:01PM +0200, Segher Boessenkool wrote:
> > Yeah, better names please -- if possible, something that someone
> > without knowledge of this SoC will understand what it is.
>
> I think the names are probably ok - I'm assuming they're in keeping
> wit
On Tue, Aug 07, 2007 at 06:51:04PM +0200, Segher Boessenkool wrote:
> >> address-permutation = <0 1 3 2 4 5 7 6 e f d c a b 9 8>;
> >
> > Yes, I was contemplating something like that.
>
> Let's not define this until we need it though :-)
Indeed.
> >> I haven't heard or thought of anything better
On Tue, Aug 07, 2007 at 06:58:20PM +0200, Segher Boessenkool wrote:
> >> Most characters are allowed in the unit-address... The following
> >> is just fine: "[EMAIL PROTECTED]". ISA uses letters to
> >> distinguish between its different address spaces, for example.
> >
> > Yeah, I should probably
On Tue, Aug 07, 2007 at 06:43:35PM +0200, Segher Boessenkool wrote:
> >>> Aha! Ok, now I understand the sorts of situations you're talking
> >>> about. By "not direct mapped", I thought you were talking about some
> >>> kind of access via address/data registers on some indirect bus
> >>> controll
>> It would be possible, I guess, to define a 'swizzled-ranges' property
>> or something which allows child devices to be embedded in the parent's
>> address range in a not-direct way. However, the swizzling on the
>> flash bank is really a property of the flash bank, not of the parent
>> bus - re
>> Most characters are allowed in the unit-address... The following
>> is just fine: "[EMAIL PROTECTED]". ISA uses letters to
>> distinguish between its different address spaces, for example.
>
> Yeah, I should probably make dtc a bit more flexible about accepting
> that, too. At present, it onl
>> address-permutation = <0 1 3 2 4 5 7 6 e f d c a b 9 8>;
>
> Yes, I was contemplating something like that.
Let's not define this until we need it though :-)
>> I haven't heard or thought of anything better either. Using "ranges"
>> is conceptually wrong, even ignoring the technical problems t
>>> Aha! Ok, now I understand the sorts of situations you're talking
>>> about. By "not direct mapped", I thought you were talking about some
>>> kind of access via address/data registers on some indirect bus
>>> controller, rather than weird variations on endianness and
>>> bit-swizzling.
>>
>>
> Yeah, better names please -- if possible, something that someone
> without knowledge of this SoC will understand what it is.
I think the names are probably ok - I'm assuming they're in keeping
with the convention I've used of using the same names /
abbreviations
On Tue, Aug 07, 2007 at 01:28:06PM +1000, David Gibson wrote:
> It would be possible, I guess, to define a 'swizzled-ranges' property
> or something which allows child devices to be embedded in the parent's
> address range in a not-direct way. However, the swizzling on the
> flash bank is really a
On Mon, Aug 06, 2007 at 10:15:39PM +0200, Segher Boessenkool wrote:
> >>> + UIC0: interrupt-controller0 {
> >>> + compatible = "ibm,uic-440gp","ibm,uic";
> >>
> >> The first compatible entry should always be the precise model, so in
> >> this case "ibm,uic-440epx". If it is (supposed to be
On Mon, Aug 06, 2007 at 10:54:33PM +0200, Segher Boessenkool wrote:
> > Aha! Ok, now I understand the sorts of situations you're talking
> > about. By "not direct mapped", I thought you were talking about some
> > kind of access via address/data registers on some indirect bus
> > controller, rath
On Mon, Aug 06, 2007 at 10:35:57PM +0200, Segher Boessenkool wrote:
> >> To be honest, I'm not sure that describing the mapping is really the
> >> job of the compatible property. That the flash is mapped into the
> >> address space is kind of implicit in the way the reg interacts with
> >> the par
On Mon, Aug 06, 2007 at 09:59:24PM +0200, Segher Boessenkool wrote:
> >>> Yeah, better names please -- if possible, something that someone
> >>> without knowledge of this SoC will understand what it is.
> >>
> >> I think the names are probably ok - I'm assuming they're in keeping
> >> with the conv
On Mon, Aug 06, 2007 at 10:20:01PM +0200, Segher Boessenkool wrote:
> >>> + - compatible : should contain the specific model of flash
> >>> chip(s) used
> >>> + followed by either "cfi-flash" or "jedec-flash"
> >>
> >> This "compatible" prop (and the node in whole) doesn't say a
> >>
On Tue, Aug 07, 2007 at 08:15:23AM +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2007-08-06 at 22:37 +0400, Sergei Shtylyov wrote:
> >
> > Actually, checking for the presence of all possible perverted
> > mapping
> > props doesn't seem a good idea -- it's simpler to check for the
> > presenc
On Mon, Aug 06, 2007 at 10:37:14PM +0400, Sergei Shtylyov wrote:
> Hello.
[snip]
> >>>Can you describe some of the options for *not* direct mapped flash
> >>>chips - I can't reasonably come up with a way of describing the
> >>>distinction when I've never seen NOR flash other than direct mapped.
>
>> Actually, checking for the presence of all possible perverted
>> mapping
>> props doesn't seem a good idea -- it's simpler to check for the
>> presence of
>> one prop (like "direct-mapped" I was thinking about, or maybe
>> "simple-map").
>
> Or more simply... if it's not a direct mapping, it
On Mon, 2007-08-06 at 22:37 +0400, Sergei Shtylyov wrote:
>
> Actually, checking for the presence of all possible perverted
> mapping
> props doesn't seem a good idea -- it's simpler to check for the
> presence of
> one prop (like "direct-mapped" I was thinking about, or maybe
> "simple-map"
>> "bit-swizzling" or something which can be defined to describe some odd
>> connections. If absent we'd default to direct mapping. Segher, is
>> that idea going to cause you to scream?
>
> Actually, checking for the presence of all possible perverted
> mapping
> props doesn't seem a good id
>>> + - compatible : should contain the specific model of flash
>>> chip(s) used
>>> + followed by either "cfi-flash" or "jedec-flash"
>>
>> Duh, have nearly forgotten to complain about "-flash" suffix.
>> Isn't it
>> superfluous?
>
> For CFI, I guess so. But don't JEDEC standardi
> Aha! Ok, now I understand the sorts of situations you're talking
> about. By "not direct mapped", I thought you were talking about some
> kind of access via address/data registers on some indirect bus
> controller, rather than weird variations on endianness and
> bit-swizzling.
>
> Hrm.. this i
>> + - compatible : should contain the specific model of flash
>> chip(s) used
>> + followed by either "cfi-flash" or "jedec-flash"
>
>Duh, have nearly forgotten to complain about "-flash" suffix.
> Isn't it superfluous?
No, it describes what kind of thing this is. "cfi" and "jed
>> To be honest, I'm not sure that describing the mapping is really the
>> job of the compatible property. That the flash is mapped into the
>> address space is kind of implicit in the way the reg interacts with
>> the parents' ranges property.
>
> Ah, I keep forgetting about implied 1:1 paren
>>> + - compatible : should contain the specific model of flash
>>> chip(s) used
>>> + followed by either "cfi-flash" or "jedec-flash"
>>
>> This "compatible" prop (and the node in whole) doesn't say a
>> thing about how the flash is mapped into the CPU address space. I
>> strongly
>>> + UIC0: interrupt-controller0 {
>>> + compatible = "ibm,uic-440gp","ibm,uic";
>>
>> The first compatible entry should always be the precise model, so in
>> this case "ibm,uic-440epx". If it is (supposed to be) identical to
>> the UIC in the 440GP, it can also have an "ibm,uic-440gp
>> + - compatible : should contain the specific model of flash
>> chip(s) used
>> + followed by either "cfi-flash" or "jedec-flash"
>
>This "compatible" prop (and the node in whole) doesn't say a thing
> about how the flash is mapped into the CPU address space.
...and it shouldn't.
>>> Yeah, better names please -- if possible, something that someone
>>> without knowledge of this SoC will understand what it is.
>>
>> I think the names are probably ok - I'm assuming they're in keeping
>> with the convention I've used of using the same names / abbreviations
>> as in the CPU user
Hello.
David Gibson wrote:
>Index: working-2.6/Documentation/powerpc/booting-without-of.txt
>===
>--- working-2.6.orig/Documentation/powerpc/booting-without-of.txt
>2007-07-30 17:07:14.0 +1000
>+++ worki
On Fri, Aug 03, 2007 at 08:29:07PM +0400, Sergei Shtylyov wrote:
> David Gibson wrote:
>
> > Duh, forgot to attach the actual patch. Here it is:
>
> > Index: working-2.6/Documentation/powerpc/booting-without-of.txt
> > ===
> > --- w
On Fri, Aug 03, 2007 at 07:47:43PM +0400, Sergei Shtylyov wrote:
> Hello.
>
> David Gibson wrote:
>
> >>>Index: working-2.6/Documentation/powerpc/booting-without-of.txt
> >>>===
> >>>--- working-2.6.orig/Documentation/powerpc/booting
David Gibson wrote:
> Duh, forgot to attach the actual patch. Here it is:
> Index: working-2.6/Documentation/powerpc/booting-without-of.txt
> ===
> --- working-2.6.orig/Documentation/powerpc/booting-without-of.txt
> 2007-07-30
Hello.
David Gibson wrote:
>>>Index: working-2.6/Documentation/powerpc/booting-without-of.txt
>>>===
>>>--- working-2.6.orig/Documentation/powerpc/booting-without-of.txt
>>>2007-07-30 17:07:14.0 +1000
>>>+++ working-2.6/D
On Thu, Aug 02, 2007 at 07:23:00PM +0400, Sergei Shtylyov wrote:
> Hello.
>
> David Gibson wrote:
>
> >>Also mine. I've been home sick the last couple of days, but by way of
> >>a sharper prod, see my draft work below. It patches both
> >>booting-without-of.txt with a revised binding, and imple
On Thu, Aug 02, 2007 at 03:18:33PM -0500, Josh Boyer wrote:
> On Wed, 1 Aug 2007 15:47:51 +1000
> David Gibson <[EMAIL PROTECTED]> wrote:
> >
> > Duh, forgot to attach the actual patch. Here it is:
>
> So, no signed-off-by. Intentional, as it's for comments only?
Pretty much.
> Also, could yo
On Wed, 1 Aug 2007 15:47:51 +1000
David Gibson <[EMAIL PROTECTED]> wrote:
>
> Duh, forgot to attach the actual patch. Here it is:
So, no signed-off-by. Intentional, as it's for comments only?
Also, could you break this out into a separate thread when you do
submit it please? Will make a few p
On Wed, 1 Aug 2007 15:04:22 +1000
David Gibson <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 01, 2007 at 06:57:33AM +0200, Segher Boessenkool wrote:
> > >> +UIC0: interrupt-controller0 {
> > >> +compatible = "ibm,uic-440gp","ibm,uic";
> > >
> > > The first compatible entry shoul
On Wed, 1 Aug 2007 12:08:36 +1000
David Gibson <[EMAIL PROTECTED]> wrote:
> On Mon, Jul 30, 2007 at 07:06:48PM +0400, Valentine Barshak wrote:
> > AMCC Sequoia board DTS
> >
> > Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]>
> > ---
> > arch/powerpc/boot/dts/sequoia.dts | 292
> >
Hello.
David Gibson wrote:
>>Also mine. I've been home sick the last couple of days, but by way of
>>a sharper prod, see my draft work below. It patches both
>>booting-without-of.txt with a revised binding, and implements it in
>>the physmap_of driver (which needs renaming, but that's another
>
On Wed, Aug 01, 2007 at 06:13:04PM +0400, Valentine Barshak wrote:
> David Gibson wrote:
> > On Mon, Jul 30, 2007 at 07:06:48PM +0400, Valentine Barshak wrote:
[snip]
> >> + SDR0: sdr {
> >
> > What is the SDR?
>
> SDR are System Device Control Registers (chip ID, pin function and stuff).
> They
David Gibson wrote:
> On Mon, Jul 30, 2007 at 07:06:48PM +0400, Valentine Barshak wrote:
>> AMCC Sequoia board DTS
>>
>> Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]>
>> ---
>> arch/powerpc/boot/dts/sequoia.dts | 292
>> ++
>> 1 files changed, 292 inser
On Wed, Aug 01, 2007 at 03:04:22PM +1000, David Gibson wrote:
> On Wed, Aug 01, 2007 at 06:57:33AM +0200, Segher Boessenkool wrote:
> > >> +UIC0: interrupt-controller0 {
> > >> +compatible = "ibm,uic-440gp","ibm,uic";
> > >
> > > The first compatible entry should always be t
On Wed, Aug 01, 2007 at 06:57:33AM +0200, Segher Boessenkool wrote:
> >> + UIC0: interrupt-controller0 {
> >> + compatible = "ibm,uic-440gp","ibm,uic";
> >
> > The first compatible entry should always be the precise model, so in
> > this case "ibm,uic-440epx".
>
> This isn't really _requ
>> +UIC0: interrupt-controller0 {
>> +compatible = "ibm,uic-440gp","ibm,uic";
>
> The first compatible entry should always be the precise model, so in
> this case "ibm,uic-440epx".
This isn't really _required_, but it is a very good idea in
almost all cases (the exception is for ve
On Mon, Jul 30, 2007 at 07:06:48PM +0400, Valentine Barshak wrote:
> AMCC Sequoia board DTS
>
> Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]>
> ---
> arch/powerpc/boot/dts/sequoia.dts | 292
> ++
> 1 files changed, 292 insertions(+)
>
> diff -ruN linu
AMCC Sequoia board DTS
Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/sequoia.dts | 292 ++
1 files changed, 292 insertions(+)
diff -ruN linux.orig/arch/powerpc/boot/dts/sequoia.dts
linux/arch/powerpc/boot/dts/sequoia.dts
---
54 matches
Mail list logo
