use of fsl, in lite5200b.dts in git current

use of fsl, in lite5200b.dts in git current

[Jon Smirl]

Sometimes the fsl prefix is being used and sometimes it isn't. Look at
the two compatible strings. Which way is it going to be? Is
fsl,has-wdt right?

                mpc5200_pic: pic@500 {
                        // 5200 interrupts are encoded into two levels;
                        interrupt-controller;
                        #interrupt-cells = <3>;
                        device_type = "interrupt-controller";
                        compatible = "mpc5200b-pic","mpc5200-pic";
                        reg = <500 80>;
                };

                gpt@600 {       // General Purpose Timer
                        compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
                        cell-index = <0>;
                        reg = <600 10>;
                        interrupts = <1 9 0>;
                        interrupt-parent = <&mpc5200_pic>;
                        fsl,has-wdt;
                };
                rtc@800 {       // Real time clock
                        compatible = "mpc5200b-rtc","mpc5200-rtc";
                        device_type = "rtc";
                        reg = <800 100>;
                        interrupts = <1 5 0 1 6 0>;
                        interrupt-parent = <&mpc5200_pic>;
                };



-- 
Jon Smirl
jonsmirl@gmail.com

Re: use of fsl, in lite5200b.dts in git current

[Matt Sealey]

Jon Smirl wrote:
> Sometimes the fsl prefix is being used and sometimes it isn't. Look at
> the two compatible strings. Which way is it going to be? Is
> fsl,has-wdt right?

fsl,has-wdt is right, at least since someone changed it.

-- 
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations

Re: use of fsl, in lite5200b.dts in git current

[Jon Smirl]

On 11/7/07, Matt Sealey <matt@genesi-usa.com> wrote:
> Jon Smirl wrote:
> > Sometimes the fsl prefix is being used and sometimes it isn't. Look at
> > the two compatible strings. Which way is it going to be? Is
> > fsl,has-wdt right?
>
> fsl,has-wdt is right, at least since someone changed it.

What's the story with compatible?
I would think the gdt entries are wrong.

               gpt@600 {       // General Purpose Timer
                       compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";

code in drivers/watchdog/mpc5200_wdt.c would need to be changed to.

drivers/watchdog/mpc5200_wdt.c: { .compatible = "fsl,mpc5200-gpt", },

-- 
Jon Smirl
jonsmirl@gmail.com

Re: use of fsl, in lite5200b.dts in git current

[Jon Smirl]

I'm not in favor of all these fsl prefixes. These chip families do get
sold. What would we have done with intel,pxa320 all over the place
when they sold it to marvell? mass changes to marvell,pxa320?

The mpc/pxa parts numbers don't get changes when chip families get sold.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: use of fsl, in lite5200b.dts in git current

[Matt Sealey]

Jon Smirl wrote:
> I'm not in favor of all these fsl prefixes. These chip families do get
> sold. What would we have done with intel,pxa320 all over the place
> when they sold it to marvell? mass changes to marvell,pxa320?

That's the idea, and there'd be a compatible entry for intel,pxa320.

Actually the spec says you should use the stock ticker (IBM, FSL, INTC,
JAVA, MRVL) if they have one and if not, the company name in lower case.

Freescale are a funny one because they used to have a stock ticker as
MOT and then FSL but now they're privately owned, so it's gonna have to
be lower case :]

It's just to seperate out the fact that sometimes you get chips with
very similar or identical names, or to mark out vendor-specific
functionality. fsl,has-wdt differs from has-wdt ideally because
Freescale watchdog timers aren't the same as other watchdog timers -
the term is pretty pliable, Freescale's GPT on the MPC52xx isn't
always a watchdog (it can be a normal, non-watchdog timer too..)

> The mpc/pxa parts numbers don't get changes when chip families get sold.

There is a case that between selling chips, some of them get updated
or bugfixed, and you can tell which one you have by the name.

There has to be some standardisation on the first implementation of
the device tree for the chip, otherwise the chopping and changing
gets rather tedious.

I'm sure you can see why we don't release firmware updates every time
some Linux guy changes some lousy, hacky tree definition for yet another
6 times a year, until it finally stabilises and the product is usually
discontinued anyway :D

However in the current situation it just means you need to flash new
FDT blobs to your U-Boots which are more clean, and keep your kernel
in sync, because Linux only handles what it currently thinks is the
standard.

The real loser is the real Open Firmware implementation, but nobody
seems to think about that, the device trees on OF devices get more
cluttered..

-- 
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations

Re: use of fsl, in lite5200b.dts in git current

[Jon Smirl]

On 11/7/07, Matt Sealey <matt@genesi-usa.com> wrote:
> Jon Smirl wrote:
> > I'm not in favor of all these fsl prefixes. These chip families do get
> > sold. What would we have done with intel,pxa320 all over the place
> > when they sold it to marvell? mass changes to marvell,pxa320?
>
> That's the idea, and there'd be a compatible entry for intel,pxa320.

The vendor part really isn't needed and it is going to be a source of
trouble. The vendors are smart enough not to create two chips with the
same part number. Adding a vendor qualifier complicates things
needlessly.

>
> Actually the spec says you should use the stock ticker (IBM, FSL, INTC,
> JAVA, MRVL) if they have one and if not, the company name in lower case.
>
> Freescale are a funny one because they used to have a stock ticker as
> MOT and then FSL but now they're privately owned, so it's gonna have to
> be lower case :]

Another example of how these vendor prefixes can change. The chip
numbers are never going to change. Just use them and drop these vendor
prefixes.


> It's just to separate out the fact that sometimes you get chips with
> very similar or identical names, or to mark out vendor-specific

You don't get chips with identical names. If they had identical names
you couldn't order them from a distributor. Similar yes, identical no.

> functionality. fsl,has-wdt differs from has-wdt ideally because

This one I can buy, but it should be fsl-has-wdt. Drop the vendor prefixes.

> Freescale watchdog timers aren't the same as other watchdog timers -
> the term is pretty pliable, Freescale's GPT on the MPC52xx isn't
> always a watchdog (it can be a normal, non-watchdog timer too..)
>
> > The mpc/pxa parts numbers don't get changes when chip families get sold.
>
> There is a case that between selling chips, some of them get updated
> or bug fixed, and you can tell which one you have by the name.

You can always tell which one you have. The vendors add suffixes to
the part numbers so that you can identify the steppings.

>
> There has to be some standardization on the first implementation of
> the device tree for the chip, otherwise the chopping and changing
> gets rather tedious.
>
> I'm sure you can see why we don't release firmware updates every time
> some Linux guy changes some lousy, hacky tree definition for yet another
> 6 times a year, until it finally stabilizes and the product is usually
> discontinued anyway :D

That's life in the Linux world, no backwards binary compatibility. I'm
in favor of the model since we can fix things until with get the right
instead of piling hacks upon hacks trying to keep ancient, broken
interfaces working (I used to work on the Windows kernel. it is major
ugly).

> However in the current situation it just means you need to flash new
> FDT blobs to your U-Boots which are more clean, and keep your kernel
> in sync, because Linux only handles what it currently thinks is the
> standard.
>
> The real loser is the real Open Firmware implementation, but nobody
> seems to think about that, the device trees on OF devices get more
> cluttered.

Open Firmware lost when it initially came out closed source and people
charged for it. uBoot/redboot/etc took the market because they were
open and free. If Open Firmware had been a free implementation from
day one things would have ended up differently.


-- 
Jon Smirl
jonsmirl@gmail.com

Re: use of fsl, in lite5200b.dts in git current

[Grant Likely]

On 11/7/07, Matt Sealey <matt@genesi-usa.com> wrote:
> Jon Smirl wrote:
> > I'm not in favor of all these fsl prefixes. These chip families do get
> > sold. What would we have done with intel,pxa320 all over the place
> > when they sold it to marvell? mass changes to marvell,pxa320?
>
> That's the idea, and there'd be a compatible entry for intel,pxa320.
>
> Actually the spec says you should use the stock ticker (IBM, FSL, INTC,
> JAVA, MRVL) if they have one and if not, the company name in lower case.
>
> Freescale are a funny one because they used to have a stock ticker as
> MOT and then FSL but now they're privately owned, so it's gonna have to
> be lower case :]

And really, this doesn't even matter.  So what if 'mot,' --> 'fsl,'
--> 'freescale,'?  Even if an older name is used, it is still
unambiguous and therefore a useful property.

Besides, If you're designing a device tree for a board, and Linux or
some other OS already has support for a similar board, it would be
madness to use property values different from what the OS already uses
just to make the values "more correct".

ie. even if Marvell sells the pxa255 for then next 5 years, it is
still correct to call it an "intel,pxa255".

> It's just to seperate out the fact that sometimes you get chips with
> very similar or identical names, or to mark out vendor-specific
> functionality. fsl,has-wdt differs from has-wdt ideally because
> Freescale watchdog timers aren't the same as other watchdog timers -
> the term is pretty pliable, Freescale's GPT on the MPC52xx isn't
> always a watchdog (it can be a normal, non-watchdog timer too..)
>
> > The mpc/pxa parts numbers don't get changes when chip families get sold.
>
> There is a case that between selling chips, some of them get updated
> or bugfixed, and you can tell which one you have by the name.
>
> There has to be some standardisation on the first implementation of
> the device tree for the chip, otherwise the chopping and changing
> gets rather tedious.
>
> I'm sure you can see why we don't release firmware updates every time
> some Linux guy changes some lousy, hacky tree definition for yet another
> 6 times a year, until it finally stabilises and the product is usually
> discontinued anyway :D

Oh come on; I've hardly changed the mpc5200 bindings at all since we
last talked about them...  :-P   (Totally joking, see comment and
eating-of-crow below).

>
> However in the current situation it just means you need to flash new
> FDT blobs to your U-Boots which are more clean, and keep your kernel
> in sync, because Linux only handles what it currently thinks is the
> standard.
>
> The real loser is the real Open Firmware implementation, but nobody
> seems to think about that, the device trees on OF devices get more
> cluttered..

Not quite true; I personally am now quite loath to changing
conventions without maintaining compatibility with the old.  I also
tend to make the assumption that upgrading the kernel should not
always require a device tree upgrade also.

In other words:
Changing conventions to better match the OF guidelines: possibly a
good thing, especially if it results in more clarity.
 --- but ---
Breaking boards with trees that follow older conventions: Bad!

This is probably a good time for me to apologize for the pain that
I've caused in the past on this issue.  My stance in the past on
designing mpc5200 device trees was wrong headed on a couple of points.
 First, insisting that the Efika device tree should exactly match what
was currently in vogue was wrong.  Second, assuming that it was even
possible to define a 'perfect' and 'exact' mpc5200 device tree binding
was pure hubris.

So, I'm sorry and I apologize.  Experience has taught me better over
the past year.

I'm now of the opinion that device trees are *never* perfect, and
that's not even the point.  The point is that a device tree should
uniquely and unambiguously describe the platform.  If the device tree
isn't quite unambiguous in one aspect, other aspects of the tree will
provide enough information to work around what is lacking.  Every
device driver may have a current-as-of-now idea on what those
properties should look like, but that should not cause platforms with
device trees which differ from that to be punted as unsupportable.

I do not think that means that vendors can put whatever they want into
a device tree without regard to current conventions (at the time of
designing their tree).  Doing so generally causes friction with the
folks who are writing software for it (and I'm not directing this
comment at bPlan either).  But I do think that changing conventions
must always be done with care and without breaking earlier users;
either by modifying the tree at platform setup time or retaining
compatibility with the old property name.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

Re: use of fsl, in lite5200b.dts in git current

[Scott Wood]

Jon Smirl wrote:
> On 11/7/07, Matt Sealey <matt@genesi-usa.com> wrote:
>> Jon Smirl wrote:
>>> I'm not in favor of all these fsl prefixes. These chip families
>>> do get sold. What would we have done with intel,pxa320 all over
>>> the place when they sold it to marvell? mass changes to
>>> marvell,pxa320?
>> That's the idea, and there'd be a compatible entry for
>> intel,pxa320.
> 
> The vendor part really isn't needed and it is going to be a source of
>  trouble. The vendors are smart enough not to create two chips with
> the same part number. Adding a vendor qualifier complicates things 
> needlessly.

I think you may be placing too much faith in the vendors.
Is a 7400 a Freescale powerpc chip, or a quad 2-input NAND gate? :-)

If you want to argue that the "MPC" part differentiates them, that's
just a less readable and more obsolete vendor prefix.

And not all compatible entries are part numbers; many are descriptions
of programming interfaces (such as cpm2 or gianfar).  I'm not inclined
to bet that there will never be a conflict in such a namespace.

>> Actually the spec says you should use the stock ticker (IBM, FSL,
>> INTC, JAVA, MRVL) if they have one and if not, the company name in
>> lower case.
>> 
>> Freescale are a funny one because they used to have a stock ticker
>> as MOT and then FSL but now they're privately owned, so it's gonna
>> have to be lower case :]

Well, technically the recommended prefix is an OUI number, and those are
less likely to change due to corporate shuffling, but they suck from a
readability perspective.

> Another example of how these vendor prefixes can change. The chip 
> numbers are never going to change. Just use them and drop these
> vendor prefixes.

No. :-)

>> functionality. fsl,has-wdt differs from has-wdt ideally because
> 
> This one I can buy, but it should be fsl-has-wdt. Drop the vendor
> prefixes.

How is fsl-has-wdt any better, other than it obscures namespace issues?

Vendor prefixes on properties are useful in that it might not mean
exactly the same thing as a similar property that gets standardized
later on.

> That's life in the Linux world, no backwards binary compatibility.

There's a huge difference between compatibility of kernel interfaces and
compatibility of interfaces between the kernel and something else --
whether it be userspace or firmware.

-Scott

Re: use of fsl, in lite5200b.dts in git current

[Jon Smirl]

On 11/8/07, Scott Wood <scottwood@freescale.com> wrote:
> Jon Smirl wrote:
> > On 11/7/07, Matt Sealey <matt@genesi-usa.com> wrote:
> >> Jon Smirl wrote:
> >>> I'm not in favor of all these fsl prefixes. These chip families
> >>> do get sold. What would we have done with intel,pxa320 all over
> >>> the place when they sold it to marvell? mass changes to
> >>> marvell,pxa320?
> >> That's the idea, and there'd be a compatible entry for
> >> intel,pxa320.
> >
> > The vendor part really isn't needed and it is going to be a source of
> >  trouble. The vendors are smart enough not to create two chips with
> > the same part number. Adding a vendor qualifier complicates things
> > needlessly.
>
> I think you may be placing too much faith in the vendors.
> Is a 7400 a Freescale powerpc chip, or a quad 2-input NAND gate? :-)

There has to be more to the part number for the Freescale powerpc chip
than just 7400.
7400 is a shorthand name, it is not an orderable part number.

> If you want to argue that the "MPC" part differentiates them, that's
> just a less readable and more obsolete vendor prefix.

The MPC is what is printed on the chip. fsl is not printed there. MPC
is part of the orderable part number.


>
> And not all compatible entries are part numbers; many are descriptions
> of programming interfaces (such as cpm2 or gianfar).  I'm not inclined
> to bet that there will never be a conflict in such a namespace.
>
> >> Actually the spec says you should use the stock ticker (IBM, FSL,
> >> INTC, JAVA, MRVL) if they have one and if not, the company name in
> >> lower case.
> >>
> >> Freescale are a funny one because they used to have a stock ticker
> >> as MOT and then FSL but now they're privately owned, so it's gonna
> >> have to be lower case :]
>
> Well, technically the recommended prefix is an OUI number, and those are
> less likely to change due to corporate shuffling, but they suck from a
> readability perspective.
>
> > Another example of how these vendor prefixes can change. The chip
> > numbers are never going to change. Just use them and drop these
> > vendor prefixes.
>
> No. :-)
>
> >> functionality. fsl,has-wdt differs from has-wdt ideally because
> >
> > This one I can buy, but it should be fsl-has-wdt. Drop the vendor
> > prefixes.
>
> How is fsl-has-wdt any better, other than it obscures namespace issues?
>
> Vendor prefixes on properties are useful in that it might not mean
> exactly the same thing as a similar property that gets standardized
> later on.
>
> > That's life in the Linux world, no backwards binary compatibility.
>
> There's a huge difference between compatibility of kernel interfaces and
> compatibility of interfaces between the kernel and something else --
> whether it be userspace or firmware.
>
> -Scott
>
>


-- 
Jon Smirl
jonsmirl@gmail.com

Re: use of fsl, in lite5200b.dts in git current

[Matt Sealey]

Jon Smirl wrote:
> On 11/8/07, Scott Wood <scottwood@freescale.com> wrote:
>
>> I think you may be placing too much faith in the vendors.
>> Is a 7400 a Freescale powerpc chip, or a quad 2-input NAND gate? :-)
> 
> There has to be more to the part number for the Freescale powerpc chip
> than just 7400. 7400 is a shorthand name, it is not an orderable part number.

The orderable part numbers add 3 or 4 characters to the front and about
8 after. There is a difference between MPC7400 and PPC7400, and the
low voltage versions, and the different clock speeds. Orderable part
number for a recent G4 might be PPC7448B1333NL - this is a ridiculous
amount of specificity in a device tree, and it also does not match the
datasheet (MPC7448 is the name of the chip).

What people usually do is use what's in the datasheet.

>> If you want to argue that the "MPC" part differentiates them, that's
>> just a less readable and more obsolete vendor prefix.
> 
> The MPC is what is printed on the chip. fsl is not printed there. MPC
> is part of the orderable part number.

Not all of them *ahem* :)

Like I said, trust the datasheet, not the number on the chip.

>> Vendor prefixes on properties are useful in that it might not mean
>> exactly the same thing as a similar property that gets standardized
>> later on.
>>
>>> That's life in the Linux world, no backwards binary compatibility.
>> There's a huge difference between compatibility of kernel interfaces and
>> compatibility of interfaces between the kernel and something else --
>> whether it be userspace or firmware.

Indeed, so.. at some point we should all sit down and hammer out the
major issues in describing something like the MPC5121E because right
now Genesi has a vested interest in that. Thanks Grant for your
discussion on it, I agree of course :)

One thing we don't want to go through again is the complaints we got
because we named the chip node "/builtin" rather than "/soc". My fixup
script is still handling that mess because you guys refused to
accept it (and some drivers were coded to map from the MBAR contained
in device_type soc's reg property rather than find a real device).

If we could all agree on how it should be mapped out, with an example
tree which shows *every damn thing available* so platform developers
can pick and choose and OF developers can use it as a reference, it
would make a much happier process.

And then we can fix up the Efika to fit some definition of the new
MPC5200 tree too.

By the way while I was poking around the tree today I noticed that
there is a PCI errata fixup handled by a Kconfig in there. Why? Surely
this is something you check the PVR/SVR for and switch on that for
a runtime solution, and not trick users with the possibility of
forgetting to enable some obscure "PCI errata fix" configuration
item? (CONFIG_PPC_MPC5200_BUGFIX)

-- 
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations

Re: use of fsl, in lite5200b.dts in git current

[Jon Loeliger]

Matt Sealey wrote:

> The orderable part numbers add 3 or 4 characters to the front and about
> 8 after. There is a difference between MPC7400 and PPC7400, and the
> low voltage versions, and the different clock speeds. Orderable part
> number for a recent G4 might be PPC7448B1333NL -

Yeah, part, stepping, variant, speed, etc.

> this is a ridiculous
> amount of specificity in a device tree, 

Except that some of that information _is_ specified
elsewhere in other properties.  Speed, for example.

> and it also does not match the
> datasheet (MPC7448 is the name of the chip).

Because the data sheets are _soooo_ reliable. :-)



> Indeed, so.. at some point we should all sit down and hammer out the
> major issues in describing something like the MPC5121E because right
> now Genesi has a vested interest in that.

You understand that _that_ is being worked on as we, er, speak?


> If we could all agree on how it should be mapped out, with an example
> tree which shows *every damn thing available* so platform developers
> can pick and choose and OF developers can use it as a reference, it
> would make a much happier process.

Right.  It's being nailed down, but it is a slow, community process...

> And then we can fix up the Efika to fit some definition of the new
> MPC5200 tree too.

*gasp*

> By the way while I was poking around the tree today I noticed that
> there is a PCI errata fixup handled by a Kconfig in there. Why?

Happens occasionally.  And other places as well.

> Surely
> this is something you check the PVR/SVR for and switch on that for
> a runtime solution, 

That's not always fine-grained enough to base a decision on it.

> and not trick users with the possibility of
> forgetting to enable some obscure "PCI errata fix" configuration
> item? (CONFIG_PPC_MPC5200_BUGFIX)

It should be in the defconfig. :-)

jdl

Re: use of fsl, in lite5200b.dts in git current

[Jon Smirl]

On 11/8/07, Matt Sealey <matt@genesi-usa.com> wrote:
> Jon Smirl wrote:
> > On 11/8/07, Scott Wood <scottwood@freescale.com> wrote:
> >
> >> I think you may be placing too much faith in the vendors.
> >> Is a 7400 a Freescale powerpc chip, or a quad 2-input NAND gate? :-)
> >
> > There has to be more to the part number for the Freescale powerpc chip
> > than just 7400. 7400 is a shorthand name, it is not an orderable part number.
>
> The orderable part numbers add 3 or 4 characters to the front and about
> 8 after. There is a difference between MPC7400 and PPC7400, and the
> low voltage versions, and the different clock speeds. Orderable part
> number for a recent G4 might be PPC7448B1333NL - this is a ridiculous
> amount of specificity in a device tree, and it also does not match the
> datasheet (MPC7448 is the name of the chip).
>
> What people usually do is use what's in the datasheet.

Data sheet part number is fine, you don't need all that specificity.
The point is that the data sheet part number is sufficient, there is
no need for a vendor prefix. And these vendor prefixes can and do end
up being wrong when the chips families get sold. The datasheet part
numbers are maintained when a product line is sold.


>
> >> If you want to argue that the "MPC" part differentiates them, that's
> >> just a less readable and more obsolete vendor prefix.
> >
> > The MPC is what is printed on the chip. fsl is not printed there. MPC
> > is part of the orderable part number.
>
> Not all of them *ahem* :)
>
> Like I said, trust the datasheet, not the number on the chip.
>
> >> Vendor prefixes on properties are useful in that it might not mean
> >> exactly the same thing as a similar property that gets standardized
> >> later on.
> >>
> >>> That's life in the Linux world, no backwards binary compatibility.
> >> There's a huge difference between compatibility of kernel interfaces and
> >> compatibility of interfaces between the kernel and something else --
> >> whether it be userspace or firmware.
>
> Indeed, so.. at some point we should all sit down and hammer out the
> major issues in describing something like the MPC5121E because right
> now Genesi has a vested interest in that. Thanks Grant for your
> discussion on it, I agree of course :)
>
> One thing we don't want to go through again is the complaints we got
> because we named the chip node "/builtin" rather than "/soc". My fixup
> script is still handling that mess because you guys refused to
> accept it (and some drivers were coded to map from the MBAR contained
> in device_type soc's reg property rather than find a real device).
>
> If we could all agree on how it should be mapped out, with an example
> tree which shows *every damn thing available* so platform developers
> can pick and choose and OF developers can use it as a reference, it
> would make a much happier process.
>
> And then we can fix up the Efika to fit some definition of the new
> MPC5200 tree too.
>
> By the way while I was poking around the tree today I noticed that
> there is a PCI errata fixup handled by a Kconfig in there. Why? Surely
> this is something you check the PVR/SVR for and switch on that for
> a runtime solution, and not trick users with the possibility of
> forgetting to enable some obscure "PCI errata fix" configuration
> item? (CONFIG_PPC_MPC5200_BUGFIX)
>
> --
> Matt Sealey <matt@genesi-usa.com>
> Genesi, Manager, Developer Relations
>


-- 
Jon Smirl
jonsmirl@gmail.com

Re: use of fsl, in lite5200b.dts in git current

[Jon Smirl]

No one has answered this yet. It makes no sense at all to mix use of
the vendor prefix on some compatible entries and not on others. The
syntax of compatible entries needs to be consistent.

On 11/7/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> On 11/7/07, Matt Sealey <matt@genesi-usa.com> wrote:
> > Jon Smirl wrote:
> > > Sometimes the fsl prefix is being used and sometimes it isn't. Look at
> > > the two compatible strings. Which way is it going to be? Is
> > > fsl,has-wdt right?
> >
> > fsl,has-wdt is right, at least since someone changed it.
>
> What's the story with compatible?
> I would think the gdt entries are wrong.
>
>                gpt@600 {       // General Purpose Timer
>                        compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
>
> code in drivers/watchdog/mpc5200_wdt.c would need to be changed to.
>
> drivers/watchdog/mpc5200_wdt.c: { .compatible = "fsl,mpc5200-gpt", },
>
> --
> Jon Smirl
> jonsmirl@gmail.com
>


-- 
Jon Smirl
jonsmirl@gmail.com

Re: use of fsl, in lite5200b.dts in git current

[Scott Wood]

Jon Smirl wrote:
> No one has answered this yet. It makes no sense at all to mix use of
> the vendor prefix on some compatible entries and not on others. The
> syntax of compatible entries needs to be consistent.

Right, the vendor prefix should always be used.  Not all of the existing 
trees are perfect, however, so sometimes the code needs to stay 
compatible, especially when the device tree is difficult to change.

-Scott

Re: use of fsl, in lite5200b.dts in git current

[Grant Likely]

On 11/8/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> No one has answered this yet. It makes no sense at all to mix use of
> the vendor prefix on some compatible entries and not on others. The
> syntax of compatible entries needs to be consistent.

The 5200 binding is poorly done on this point.  I've got a patch that
adds the 'fsl,' prefix so that future 5200 device trees are consistent
with the recommended practices (while not breaking older boards of
course)

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

Re: use of fsl, in lite5200b.dts in git current

[Jon Smirl]

On 11/8/07, Scott Wood <scottwood@freescale.com> wrote:
> Jon Smirl wrote:
> > No one has answered this yet. It makes no sense at all to mix use of
> > the vendor prefix on some compatible entries and not on others. The
> > syntax of compatible entries needs to be consistent.
>
> Right, the vendor prefix should always be used.  Not all of the existing
> trees are perfect, however, so sometimes the code needs to stay
> compatible, especially when the device tree is difficult to change.

A bunch of patches are going to have to go into the kernel. Code
expecting tree attributes without vendor prefixes is all over the
kernel. All of the dts file need to be patched up, etc.

As far as I know the only dts using vendor prefixes in the compatible
attributes is 5200lite one for the gpt entries. Everything else will
need to be changed.


>
> -Scott
>


-- 
Jon Smirl
jonsmirl@gmail.com

Re: use of fsl, in lite5200b.dts in git current

[Scott Wood]

Jon Smirl wrote:
> On 11/8/07, Scott Wood <scottwood@freescale.com> wrote:
>> Jon Smirl wrote:
>>> No one has answered this yet. It makes no sense at all to mix use of
>>> the vendor prefix on some compatible entries and not on others. The
>>> syntax of compatible entries needs to be consistent.
>> Right, the vendor prefix should always be used.  Not all of the existing
>> trees are perfect, however, so sometimes the code needs to stay
>> compatible, especially when the device tree is difficult to change.
> 
> A bunch of patches are going to have to go into the kernel. Code
> expecting tree attributes without vendor prefixes is all over the
> kernel.

It's just nonstandard properties that need it, not all of them.

> All of the dts file need to be patched up, etc.

I don't think *all* the dts files have problems...

> As far as I know the only dts using vendor prefixes in the compatible
> attributes is 5200lite one for the gpt entries. Everything else will
> need to be changed.

Look a little harder.  Many of the Freescale boards/devices do it right 
-- and yes, we need to fix the ones that don't.

-Scott

Re: use of fsl, in lite5200b.dts in git current

[Jon Smirl]

On 11/8/07, Scott Wood <scottwood@freescale.com> wrote:
> > As far as I know the only dts using vendor prefixes in the compatible
> > attributes is 5200lite one for the gpt entries. Everything else will
> > need to be changed.
>
> Look a little harder.  Many of the Freescale boards/devices do it right
> -- and yes, we need to fix the ones that don't.

I see that there are quite a few with the ibm prefix. But by
eyeballing grep output it looks like several hundred attributes need
to be fixed. Code referencing these will need to be fixed too.

If lite5200 hadn't mixed half prefixed and half not prefixed I never
would have started looking at this.

Let's make up our minds in the lite5200 dts so that I can sync up my
development hardware.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: use of fsl, in lite5200b.dts in git current

[Scott Wood]

Jon Smirl wrote:
> On 11/8/07, Scott Wood <scottwood@freescale.com> wrote:
>>> As far as I know the only dts using vendor prefixes in the compatible
>>> attributes is 5200lite one for the gpt entries. Everything else will
>>> need to be changed.
>> Look a little harder.  Many of the Freescale boards/devices do it right
>> -- and yes, we need to fix the ones that don't.
> 
> I see that there are quite a few with the ibm prefix. But by
> eyeballing grep output it looks like several hundred attributes need
> to be fixed. Code referencing these will need to be fixed too.

Several hundred?  I don't think there are several hundred unique 
property names or compatible entries in arch/powerpc/boot/dts *total*, 
much less that need fixing.  The main ones in fsl-land that I can think 
of are gianfar, i2c, talitos, QE, USB, tsi108, watchdog, SPI, and IPIC.

CPM1 and CPM2 devices, PCI, 85xx memory/cache controllers, and 85xx 
global utilities have the prefix.

For the most part, we've been adding prefixes whenever we have any other 
reason to touch the binding.

> If lite5200 hadn't mixed half prefixed and half not prefixed I never
> would have started looking at this.
> 
> Let's make up our minds in the lite5200 dts so that I can sync up my
> development hardware.

Patches are welcome. :-)

-Scott

Re: use of fsl, in lite5200b.dts in git current

[Jon Smirl]

On 11/8/07, Scott Wood <scottwood@freescale.com> wrote:
> Jon Smirl wrote:
> > On 11/8/07, Scott Wood <scottwood@freescale.com> wrote:
> >>> As far as I know the only dts using vendor prefixes in the compatible
> >>> attributes is 5200lite one for the gpt entries. Everything else will
> >>> need to be changed.
> >> Look a little harder.  Many of the Freescale boards/devices do it right
> >> -- and yes, we need to fix the ones that don't.
> >
> > I see that there are quite a few with the ibm prefix. But by
> > eyeballing grep output it looks like several hundred attributes need
> > to be fixed. Code referencing these will need to be fixed too.
>
> Several hundred?  I don't think there are several hundred unique
> property names or compatible entries in arch/powerpc/boot/dts *total*,

There are 601 'compatible' attributes in the directory.

> much less that need fixing.  The main ones in fsl-land that I can think
> of are gianfar, i2c, talitos, QE, USB, tsi108, watchdog, SPI, and IPIC.
>
> CPM1 and CPM2 devices, PCI, 85xx memory/cache controllers, and 85xx
> global utilities have the prefix.
>
> For the most part, we've been adding prefixes whenever we have any other
> reason to touch the binding.
>
> > If lite5200 hadn't mixed half prefixed and half not prefixed I never
> > would have started looking at this.
> >
> > Let's make up our minds in the lite5200 dts so that I can sync up my
> > development hardware.
>
> Patches are welcome. :-)
>
> -Scott
>


-- 
Jon Smirl
jonsmirl@gmail.com

Re: use of fsl, in lite5200b.dts in git current

[Scott Wood]

Jon Smirl wrote:
> On 11/8/07, Scott Wood <scottwood@freescale.com> wrote:
>> Several hundred?  I don't think there are several hundred unique
>> property names or compatible entries in arch/powerpc/boot/dts *total*,
> 
> There are 601 'compatible' attributes in the directory.

I said "unique".  And there do appear to be a couple hundred of those, 
though if I omit those containing vendor prefixes, it drops to under a 
hundred.  A big chunk of *those* are 5200-related. :-)

-Scott

Re: use of fsl, in lite5200b.dts in git current

[Matt Sealey]

Jon Loeliger wrote:
> Matt Sealey wrote:
> 
>> this is a ridiculous
>> amount of specificity in a device tree, 
> 
> Except that some of that information _is_ specified elsewhere in other properties.  Speed, for example.

Which is fine..

>> and it also does not match the
>> datasheet (MPC7448 is the name of the chip).
> 
> Because the data sheets are _soooo_ reliable. :-)

Be careful or I'll start looking for the datasheets with your name on it :)

>> Indeed, so.. at some point we should all sit down and hammer out the
>> major issues in describing something like the MPC5121E because right
>> now Genesi has a vested interest in that.
> 
> You understand that _that_ is being worked on as we, er, speak?

Yeah I've seen it, recognise your name from the top of the device tree
definition, and I must say, it's not the most ideal...

>> If we could all agree on how it should be mapped out, with an example
>> tree which shows *every damn thing available* so platform developers
>> can pick and choose and OF developers can use it as a reference, it
>> would make a much happier process.
> 
> Right.  It's being nailed down, but it is a slow, community process...

Why? Freescale's chip, open standards, just design it right, and tell
the community they should be conforming with it.

The slow community process would have had the Efika come out this
month instead of this time last year if we had waited to fix the
device tree to "the right way to do it".

The device tree, hardware description in general, is down to the
silicon vendor and ODM, and should provide description of the
hardware which allows any driver (not just the ones in the BSP)
to get enough information from the tree where necessary.

I don't see that in the MPC5200 tree and I still don't see it in
the examples of the MPC5121E tree.

I also note the few users of the MPC5121E that there are outside
of Freescale, aren't involved (ahem) in this process unless they
join these mailing lists. You can't discuss anything on here with
that chip, it's locked down by NDA, release date tenuous, feature
state tenuous.. documentation is in draft/preliminary and nobody
else has it.

>> By the way while I was poking around the tree today I noticed that
>> there is a PCI errata fixup handled by a Kconfig in there. Why?
> 
> Happens occasionally.  And other places as well.
> 
>> Surely
>> this is something you check the PVR/SVR for and switch on that for
>> a runtime solution, 
> 
> That's not always fine-grained enough to base a decision on it.

It is in this case isn't it? The errata states that it only appears
on that particular revision.

>> and not trick users with the possibility of
>> forgetting to enable some obscure "PCI errata fix" configuration
>> item? (CONFIG_PPC_MPC5200_BUGFIX)
> 
> It should be in the defconfig. :-)

It shouldn't be a configuration option at all in my opinion :)

You either fix the bug or you don't, if you have to fix it in a
generic, multi-chip (5200/5200B) API like the PCI stuff, it
should be handled on a if/else basis. There's practically no benefit
to having it as a configuration option and being able to compile
it out, in fact.. it rather makes the whole presence of the fix
more complicated (to support 5200 and 5200B you need to compile
in the fix, and that means 5200B chips are implementing it when
they don't need to - and you need to recompile to fix it).

-- 
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations