Bug fixes for 2.6.20

Bug fixes for 2.6.20

[Paul Mackerras]

If anyone has a patch that they need to have in 2.6.20 in order to fix
a bug or make some existing code compile, please let me know.  I
already have a patch from Michal Ostrowski, two patches from Ben
H. and a set from Stephen Rothwell in my queue.  I don't know what's
needed for any of the embedded boards, though.

Paul.

[PATCH] Probe Efika platform before CHRP.

[David Woodhouse]

The Efika matches chrp_probe() too, so put its own probe first to make
sure we get it right in a multiplatform build.

Signed-off-by: David Woodhouse <dwmw2@infradead.org>

--- linux-2.6.19.ppc/arch/powerpc/platforms/Makefile~	2006-12-17 14:55:49.000000000 +0000
+++ linux-2.6.19.ppc/arch/powerpc/platforms/Makefile	2006-12-17 17:16:52.000000000 +0000
@@ -5,9 +5,9 @@ ifeq ($(CONFIG_PPC64),y)
 obj-$(CONFIG_PPC_PMAC)		+= powermac/
 endif
 endif
+obj-$(CONFIG_PPC_MPC52xx)	+= 52xx/
 obj-$(CONFIG_PPC_CHRP)		+= chrp/
 obj-$(CONFIG_4xx)		+= 4xx/
-obj-$(CONFIG_PPC_MPC52xx)	+= 52xx/
 obj-$(CONFIG_PPC_83xx)		+= 83xx/
 obj-$(CONFIG_PPC_85xx)		+= 85xx/
 obj-$(CONFIG_PPC_86xx)		+= 86xx/

-- 
dwmw2

Re: [PATCH] Probe Efika platform before CHRP.

[Benjamin Herrenschmidt]

On Tue, 2006-12-19 at 09:54 +0000, David Woodhouse wrote:
> The Efika matches chrp_probe() too, so put its own probe first to make
> sure we get it right in a multiplatform build.

Hrm... I told them to remove that from their device-tree ... dammit !

> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
> 
> --- linux-2.6.19.ppc/arch/powerpc/platforms/Makefile~	2006-12-17 14:55:49.000000000 +0000
> +++ linux-2.6.19.ppc/arch/powerpc/platforms/Makefile	2006-12-17 17:16:52.000000000 +0000
> @@ -5,9 +5,9 @@ ifeq ($(CONFIG_PPC64),y)
>  obj-$(CONFIG_PPC_PMAC)		+= powermac/
>  endif
>  endif
> +obj-$(CONFIG_PPC_MPC52xx)	+= 52xx/
>  obj-$(CONFIG_PPC_CHRP)		+= chrp/
>  obj-$(CONFIG_4xx)		+= 4xx/
> -obj-$(CONFIG_PPC_MPC52xx)	+= 52xx/
>  obj-$(CONFIG_PPC_83xx)		+= 83xx/
>  obj-$(CONFIG_PPC_85xx)		+= 85xx/
>  obj-$(CONFIG_PPC_86xx)		+= 86xx/
> 

Re: [PATCH] Probe Efika platform before CHRP.

[Sylvain Munaut]

Benjamin Herrenschmidt wrote:
> On Tue, 2006-12-19 at 09:54 +0000, David Woodhouse wrote:
>   
>> The Efika matches chrp_probe() too, so put its own probe first to make
>> sure we get it right in a multiplatform build.
>>     
>
> Hrm... I told them to remove that from their device-tree ... dammit !
>   
Yes, I told them to do some other changes to their device-tree, but no
luck so far.

I think I'll end up with a bunch of device-tree fix in the efika probe
function. (Either
that, or force the user to have a nvramrc for the firmware that makes
the appropriate
changes, but that's kindof an hassle for the user)

That won't solve the problem with chrp though.
I've seen that pseries will also match chrp. And in the pseries probe
function,
the Cell blades are explicitely 'refused'.

Maybe instead of putting 52xx first, it would be "better" to put chrp
and pseries
last as they seem more "generic". So that anything that match before
that has
priority.


    Sylvain


>> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
>>
>> --- linux-2.6.19.ppc/arch/powerpc/platforms/Makefile~	2006-12-17 14:55:49.000000000 +0000
>> +++ linux-2.6.19.ppc/arch/powerpc/platforms/Makefile	2006-12-17 17:16:52.000000000 +0000
>> @@ -5,9 +5,9 @@ ifeq ($(CONFIG_PPC64),y)
>>  obj-$(CONFIG_PPC_PMAC)		+= powermac/
>>  endif
>>  endif
>> +obj-$(CONFIG_PPC_MPC52xx)	+= 52xx/
>>  obj-$(CONFIG_PPC_CHRP)		+= chrp/
>>  obj-$(CONFIG_4xx)		+= 4xx/
>> -obj-$(CONFIG_PPC_MPC52xx)	+= 52xx/
>>  obj-$(CONFIG_PPC_83xx)		+= 83xx/
>>  obj-$(CONFIG_PPC_85xx)		+= 85xx/
>>  obj-$(CONFIG_PPC_86xx)		+= 86xx/
>>
>>     
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>   

Re: [PATCH] Probe Efika platform before CHRP.

[David Woodhouse]

On Tue, 2006-12-19 at 12:55 +0100, Sylvain Munaut wrote:
> Benjamin Herrenschmidt wrote:
> > On Tue, 2006-12-19 at 09:54 +0000, David Woodhouse wrote:
> >   
> >> The Efika matches chrp_probe() too, so put its own probe first to make
> >> sure we get it right in a multiplatform build.
> >>     
> >
> > Hrm... I told them to remove that from their device-tree ... dammit !
>
> Yes, I told them to do some other changes to their device-tree, but no
> luck so far.

OK, let's drop the patch and assume the device-tree will be fixed
shortly. In the meantime, users should be able to work around it by
hacking the device-tree from the OF prompt -- which we currently have to
do for other things in the Efika device-tree anyway.

I'm happy enough for Fedora to require the fixed firmware, certainly. 

-- 
dwmw2

Re: [PATCH] Probe Efika platform before CHRP.

[Grant Likely]

On 12/19/06, David Woodhouse <dwmw2@infradead.org> wrote:
> On Tue, 2006-12-19 at 12:55 +0100, Sylvain Munaut wrote:
> > Benjamin Herrenschmidt wrote:
> > > Hrm... I told them to remove that from their device-tree ... dammit !
> >
> > Yes, I told them to do some other changes to their device-tree, but no
> > luck so far.
>
> OK, let's drop the patch and assume the device-tree will be fixed
> shortly. In the meantime, users should be able to work around it by
> hacking the device-tree from the OF prompt -- which we currently have to
> do for other things in the Efika device-tree anyway.

This will do for the time being; but I'm not expecting any changes to
be made to the firmware  (however, Sven is making the attempt).  In
the long term, I think we are going to have to live with either OF
fixups; or preventing CHRP from matching the efika and adding other
fixups in the Efika's probe function.  I like Sylvain's suggestion of
moving CHRP and pseries down in the link order; but then again, I'm
neither a CHRP or pseries user.  :)

Cheers,
g.

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

Re: [PATCH] Probe Efika platform before CHRP.

[Benjamin Herrenschmidt]

> OK, let's drop the patch and assume the device-tree will be fixed
> shortly. 

No, keep the patch for now. I'm afraid they aren't willing to fix their
device-tree.

> In the meantime, users should be able to work around it by
> hacking the device-tree from the OF prompt -- which we currently have to
> do for other things in the Efika device-tree anyway.
> 
> I'm happy enough for Fedora to require the fixed firmware, certainly. 
> 

Re: [PATCH] Probe Efika platform before CHRP.

[Sylvain Munaut]

Benjamin Herrenschmidt wrote:
>> OK, let's drop the patch and assume the device-tree will be fixed
>> shortly. 
>>     
>
> No, keep the patch for now. I'm afraid they aren't willing to fix their
> device-tree.
>   
Ok,
but please, put a comment near it would be nice if we remember why we
put it there.


Sylvain
>   
>> In the meantime, users should be able to work around it by
>> hacking the device-tree from the OF prompt -- which we currently have to
>> do for other things in the Efika device-tree anyway.
>>
>> I'm happy enough for Fedora to require the fixed firmware, certainly. 
>>
>>     
>
>   

Re: [PATCH] Probe Efika platform before CHRP.

[David Woodhouse]

On Wed, 2006-12-20 at 06:58 +1100, Benjamin Herrenschmidt wrote:
> > OK, let's drop the patch and assume the device-tree will be fixed
> > shortly. 
> 
> No, keep the patch for now. I'm afraid they aren't willing to fix their
> device-tree.

They need to fix their firmware anyway, because it's screwed in other
ways too -- they have an off-by-one error in their handling of partition
numbers, so when yaboot tries to read a partition table it actually gets
the first sector of the first partition, and it all goes downhill from
there. That one was even _fixed_ in the Pegasos firmware last year, but
it's come back in Efika -- and we _can't_ work around it in the kernel.

For Fedora, we're just going to wait for the fixed firmware; we can't
sensibly support it as-is.

-- 
dwmw2

Re: [PATCH] Probe Efika platform before CHRP.

[Benjamin Herrenschmidt]

On Tue, 2007-01-02 at 21:29 +0000, David Woodhouse wrote:
> On Wed, 2006-12-20 at 06:58 +1100, Benjamin Herrenschmidt wrote:
> > > OK, let's drop the patch and assume the device-tree will be fixed
> > > shortly. 
> > 
> > No, keep the patch for now. I'm afraid they aren't willing to fix their
> > device-tree.
> 
> They need to fix their firmware anyway, because it's screwed in other
> ways too -- they have an off-by-one error in their handling of partition
> numbers, so when yaboot tries to read a partition table it actually gets
> the first sector of the first partition, and it all goes downhill from
> there. That one was even _fixed_ in the Pegasos firmware last year, but
> it's come back in Efika -- and we _can't_ work around it in the kernel.
> 
> For Fedora, we're just going to wait for the fixed firmware; we can't
> sensibly support it as-is.

Ok. Well, Nicolas Det have unfortunately repeately said "we won't fix
the firmware" so it's bloody annoying but if you can apply that sort of
pressure on from a distro, that's good.

I've been very annoyed from the beginning with the refusal to discuss
the content of the device-tree publically before it was too late, the
firmware "in production" and "not fixable" (Nicolas words).

Ben.
 

Re: [PATCH] Probe Efika platform before CHRP.

[David Woodhouse]

On Wed, 2007-01-03 at 08:37 +1100, Benjamin Herrenschmidt wrote:
> Ok. Well, Nicolas Det have unfortunately repeately said "we won't fix
> the firmware"

Really? Why on earth not? We're talking about simple and obvious fixes,
and we have no reason to keep it broken for "compatibility", surely?

-- 
dwmw2

Re: [PATCH] Probe Efika platform before CHRP.

[Grant Likely]

On 1/2/07, David Woodhouse <dwmw2@infradead.org> wrote:
> On Wed, 2007-01-03 at 08:37 +1100, Benjamin Herrenschmidt wrote:
> > Ok. Well, Nicolas Det have unfortunately repeately said "we won't fix
> > the firmware"
>
> Really? Why on earth not? We're talking about simple and obvious fixes,
> and we have no reason to keep it broken for "compatibility", surely?

Really don't know, especially considering that the firmware did get
changed during the whole process to modify the irq mapping format.

Cheers,
g.

Re: [PATCH] Probe Efika platform before CHRP.

[Grant Likely]

On 1/6/07, Matt Sealey <matt@genesi-usa.com> wrote:
>
> One basic problem is we're talking about changing Efika to adapt to the
> definitions, whims and determinations of the *Linux* community.

As opposed to the Linux community being asked to adapt to the
definitions, whims and determinations of a single corporate entity?
:-)

>
> What if NetBSD, FreeBSD, QNX and WindRiver disagree with you guys?

I'm pretty sure that Linux is the only OS which is requiring a device
tree for booting for new ports, and I'm also pretty sure that the
Efika is the only 52xx board with open firmware on it.  If I'm right
about this; then for the vast majority of 52xx boards, a device tree
is only needed if it is booting Linux, and therefore it is up to the
Linux community to define what it needs to look like.  It also makes
the Efika the exception, not the rule (as it's the only board which
will pass the device tree to non-Linux OSes)

> Who do we change for?
>
> You might understand, we all think you're being just a TAD unreasonable
> on this matter.

I'm not trying to say "Change Dammit!".  I'm trying to say, "This is
what I think it should look like; where should it go from here".  So
far I feel like I've been told: "we've done it this way, deal with it"

> Surely Linux should detect all available and present nodes, compatibility
> flags and so on, and not simply tell vendors to "shape up your firmware
> because we refuse to make Linux support anything we did not define and
> impose on you"?

Early on when we were trying to draft a standard for 52xx device trees
(mpc52xx-device-tree-bindings.txt), bplan refused to disclose what the
Efika device tree layout looked like.  In the absence of any input
from bplan, a draft 52xx device tree spec was written.  Mostly, the
draft spec followed the conventions already established for other
powerpc SoC devices (see booting-without-of.txt; and Yes, I realize
that the Efika has real-of; but I'm just referring to the naming
convention portions of that document).

Reference:
http://www2.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/powerpc/mpc52xx-device-tree-bindings.txt;h=d077d764f82b0ce73148063e694f842e7ab00ff9;hb=HEAD

At a later date, Nicolas made the statement that the firmware was set
and there would be not changes to the device tree, so I better just
copy what was done on the Efika.

I do not object to changing the definitions or what we are requesting
for the device tree layout.  I do object to being told, "we did it
this way, so just copy it" after refusing to discuss any kind of
device tree layout standard for the 52xx parts.  As someone who is not
getting paid to do this work, it does not particularly motivate me to
want to help you out.

> Specifically for the "sound" and "ac97" discrepency, the "sound" device
> type has some special implications for Open Firmware firmwares. It's
> set to ac97 as it is NOT an OF or CHRP standard "sound" node and should
> NOT be found as such in my personal opinion.

For the record; this has already been addressed:

http://patchwork.ozlabs.org/linuxppc/patch?id=8842

'ac97' was wrong, it should have been 'sound'

I do *NOT* want to claim that the proposed mpc52xx device tree binding
is correct or final.  My motivation is to see a consistent, well
thought out device tree specification for all 52xx boards before too
many vendors produce device trees that are utterly incompatible with
one another (due to inconsistent naming).

> Would you mind giving me a list of exactly WHAT you think is wrong (the
> patch doesn't define what is broken, it only blindly throws in the fixes
> with no explanation of why in comments or documentation..) and why we
> should fix it, and I can go through it with you, since I understand Nico is
> not up to discussing the matter being very busy and all :D

There are two issues here:

1. consistent mpc52xx soc device naming so that the appropriate
compatible device driver can be selected; two different 52xx devices
exist at the moment, and the Efika seems to report them as the wrong
one (ie. 5200 instead of 5200b).  Plus there are rumblings from
Freescale to be bringing out more 52xx devices.  These are the issues
that mpc52xx-device-tree-bindings.txt was written to address; and that
document also contains the rational for the naming convention.  As it
stands right now, Sylvain's patch provides a workaround for these
concerns, so the differences between the draft spec and the Efika are
contained within a single source file.

Once again, I am not opposed to changing the draft; the goal of the
document is to encourage consistency in board designs.

2. Dwmw2 says that reading the HD has an off-by-one showstopper bug
which prevents Linux from reading the partition table (and that it is
the same bug that was on the pegasos, but is now fixed).

I have not confirmed this issues as I don't have a working HD on my
Efika.  However, dwmw2 has stated that he cannot support the Efika in
Fedora until this issue is resolved.

Cheers,
g.

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

Re: [PATCH] Probe Efika platform before CHRP.

[David Woodhouse]

On Sat, 2007-01-06 at 15:23 -0700, Grant Likely wrote:
> 2. Dwmw2 says that reading the HD has an off-by-one showstopper bug
> which prevents Linux from reading the partition table (and that it is
> the same bug that was on the pegasos, but is now fixed).

It's an off-by-one in partition table numbering. When we ask for
"hd:0" (the whole disk) we get "hd:1", and so on. It screws yaboot's
partition table scan, because when it asks for the first sector of the
disk it's given the first sector of the first partition.

Something very similar to this already got fixed on Pegasos after I
reported it -- and I didn't think it was _particularly_ far-fetched for
me to expect the Efika firmware to be adapted to the "definitions, whims
and determinations" of the CHRP specification too.

> I have not confirmed this issues as I don't have a working HD on my
> Efika.  However, dwmw2 has stated that he cannot support the Efika in
> Fedora until this issue is resolved. 

"Cannot" is a strong word when you're talking about software -- and is
almost always untrue. I think what I said was "can't sensibly", which
makes a lot more sense.

I've got a locally-hacked yaboot which works around it enough to boot my
system, but I'm not going to get far if I suggest that we ship a
different copy of the boot loader just for Efika "because it's speshul".
Especially when the bug was known so long ago.

I think the workaround on Pegasos was to use Amiga partitions, and to
hack (perhaps even unintentionally) the Amiga partition code in yaboot
to compensate for the brokenness. So the Amiga partition code probably
won't work on CHRP-compatible machines, while the rest of the partition
code won't work on Efika/oldPegasos. I baulked at the idea of continuing
this hack by using Amiga partitions on Efika too, and preferred to put
the thing back on the shelf and wait for it to be fixed -- especially as
I'm away for the rest of the month anyway.

-- 
dwmw2

Re: [PATCH] Probe Efika platform before CHRP.

[Grant Likely]

On 1/6/07, David Woodhouse <dwmw2@infradead.org> wrote:
> On Sat, 2007-01-06 at 15:23 -0700, Grant Likely wrote:
> > ... he cannot support the Efika in Fedora until this issue is resolved.
>
> "Cannot" is a strong word when you're talking about software -- and is
> almost always untrue. I think what I said was "can't sensibly", which
> makes a lot more sense.

Heh, sorry.  I should know better.  :)

g.

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

Re: [PATCH] Probe Efika platform before CHRP.

[Sylvain Munaut]

>> What if NetBSD, FreeBSD, QNX and WindRiver disagree with you guys?
Note that the "compatible" modification we ask could simply be to add
the one
we require at the start of your compatible list, so linux will work and
the os using
the efika original will work as well.

>> Specifically for the "sound" and "ac97" discrepency, the "sound" device
>> type has some special implications for Open Firmware firmwares. It's
>> set to ac97 as it is NOT an OF or CHRP standard "sound" node and should
>> NOT be found as such in my personal opinion.
This "sound" <> "ac97" thing is not fixed in the patch I posted recently nor
in the nvramrc I sent to gentoo before that. The only visible thing was a
a small comment buried in a very experimental driver.
As soon as nicolas told me "sound" was the standard, I said OK so be it.

But for example the "memory" type you give to the SRAM node is imho
wrong. Because memory seems to be the standard type for "real" memory,
the one that's gonna be used for the system ...

> There are two issues here:
I'd say you can even split a little more :

 * Compatible / Type of nodes :
   We need a naming schema that's coherent across nodes and will allow to
   support coherently different boards. Your naming scheme just doesn't
   provide that. The one proposed by Grant does. Now it's possible you can
   find even better and we're open to suggestion.

 * Missing bits :
  - The interrupts property of the ac97 node are just not there. This
interrupt
     exist, it's hw and you can't just decide the driver can do without
it ...

 * Bugs : I see three,
  -  The one dwmv2 mentionned
  -  I noticed the compatible properties had double \0 at the end instead
     of single ones.
  -  Incorrect init of the PSC2 for AC97 and in the tree since the "gpio"
     node is not present, the address for port config is not found in the
     device tree. The current work around is a ugly hardcoded stuff in
     the driver itself that will never be merged upstream.


Regards,

     Sylvain


PS: In the end, a long nvramrc will do the trick ... so I don't care
much for me,
I'll always know what I need to put in it.

Re: [PATCH] Probe Efika platform before CHRP.

[Raquel Velasco and Bill Buck]

Hi Syvain, Ben, and the others here on this list...

In the next 45-60 days we will offer new firmware for the EFIKA (and  
the Pegasos/ODW).  We will define a new hardware specification  
outside of CHRP.  In the meanwhile and afterwards, feel free to  
proceed as you determine best.  We appreciate the support we have  
received in the past and the effort made more recently on the EFIKA.

The long term objective for Genesi is to provide a low cost, low  
power, highly reliable computing platform that can be flexibly  
applied to many uses.  We hope to be selling the EFIKA at $99 by  
April (and sooner if possible).  The 5200B is to be followed by  
another SoC with integrated graphic support at the same price (for  
the SoC).  The new firmware will be inexorably linked to this new SoC  
in form and function.  The EFIKA is a development platform that  
targets the system we will offer with the new SoC.  We expect to be  
shipping the next version of the EFIKA before the end of 2007.  The  
first diagram shown in the link that follows (the second image is  
what we hope for after that):

http://bbrv.blogspot.com/2006/10/wanting-what-you-have.html

Thanks again.  Happy New Year. :)

Best regards,
R&B


On Jan 6, 2007, at 8:55 PM, Sylvain Munaut wrote:

>
>>> What if NetBSD, FreeBSD, QNX and WindRiver disagree with you guys?
> Note that the "compatible" modification we ask could simply be to add
> the one
> we require at the start of your compatible list, so linux will work  
> and
> the os using
> the efika original will work as well.
>
>>> Specifically for the "sound" and "ac97" discrepency, the "sound"  
>>> device
>>> type has some special implications for Open Firmware firmwares. It's
>>> set to ac97 as it is NOT an OF or CHRP standard "sound" node and  
>>> should
>>> NOT be found as such in my personal opinion.
> This "sound" <> "ac97" thing is not fixed in the patch I posted  
> recently nor
> in the nvramrc I sent to gentoo before that. The only visible thing  
> was a
> a small comment buried in a very experimental driver.
> As soon as nicolas told me "sound" was the standard, I said OK so  
> be it.
>
> But for example the "memory" type you give to the SRAM node is imho
> wrong. Because memory seems to be the standard type for "real" memory,
> the one that's gonna be used for the system ...
>
>> There are two issues here:
> I'd say you can even split a little more :
>
>  * Compatible / Type of nodes :
>    We need a naming schema that's coherent across nodes and will  
> allow to
>    support coherently different boards. Your naming scheme just  
> doesn't
>    provide that. The one proposed by Grant does. Now it's possible  
> you can
>    find even better and we're open to suggestion.
>
>  * Missing bits :
>   - The interrupts property of the ac97 node are just not there. This
> interrupt
>      exist, it's hw and you can't just decide the driver can do  
> without
> it ...
>
>  * Bugs : I see three,
>   -  The one dwmv2 mentionned
>   -  I noticed the compatible properties had double \0 at the end  
> instead
>      of single ones.
>   -  Incorrect init of the PSC2 for AC97 and in the tree since the  
> "gpio"
>      node is not present, the address for port config is not found  
> in the
>      device tree. The current work around is a ugly hardcoded stuff in
>      the driver itself that will never be merged upstream.
>
>
> Regards,
>
>      Sylvain
>
>
> PS: In the end, a long nvramrc will do the trick ... so I don't care
> much for me,
> I'll always know what I need to put in it.
>

Re: [PATCH] Probe Efika platform before CHRP.

[David Woodhouse]

On Sun, 2007-01-07 at 03:11 -0600, Raquel Velasco and Bill Buck wrote:
> In the next 45-60 days we will offer new firmware for the EFIKA (and  
> the Pegasos/ODW). 

Was hoping to see this before the Fedora 7 release... ?

-- 
dwmw2

Re: [PATCH] Probe Efika platform before CHRP.

[Raquel Velasco and Bill Buck]

Absolutely everything will happen in April...


On Mar 31, 2007, at 8:15 AM, David Woodhouse wrote:

> On Sun, 2007-01-07 at 03:11 -0600, Raquel Velasco and Bill Buck wrote:
>> In the next 45-60 days we will offer new firmware for the EFIKA (and
>> the Pegasos/ODW).
>
> Was hoping to see this before the Fedora 7 release... ?
>
> -- 
> dwmw2
>

Raquel and Bill
http://bbrv.blogspot.com

Re: [PATCH] Probe Efika platform before CHRP.

[David Woodhouse]

On Sat, 2007-03-31 at 08:18 -0500, Raquel Velasco and Bill Buck wrote:
> April...

OK, that should work for us. I've dusted off my Efika and made sure the
Fedora kernel is in reasonable shape for it, but we really do need the
partition handling sorted before it's going to be installable by normal
people. Please let me know as soon as you've got a prerelease which I
can try out.

-- 
dwmw2

Re: [PATCH] Probe Efika platform before CHRP.

[Olaf Hering]

On Sat, Mar 31, Raquel Velasco and Bill Buck wrote:

> Absolutely everything will happen in April...

Which year? 2007 or 2010?


> On Mar 31, 2007, at 8:15 AM, David Woodhouse wrote:
> 
> > On Sun, 2007-01-07 at 03:11 -0600, Raquel Velasco and Bill Buck wrote:
> >> In the next 45-60 days we will offer new firmware for the EFIKA (and
> >> the Pegasos/ODW).
> >
> > Was hoping to see this before the Fedora 7 release... ?

Re: [PATCH] Probe Efika platform before CHRP.

[Raquel Velasco and Bill Buck]

It is coming - Freescale is involved and this adds time to the  
release, but it is all for good reason.

Best regards,
R&B

On May 9, 2007, at 7:42 AM, Olaf Hering wrote:

> On Sat, Mar 31, Raquel Velasco and Bill Buck wrote:
>
>> Absolutely everything will happen in April...
>
> Which year? 2007 or 2010?
>
>
>> On Mar 31, 2007, at 8:15 AM, David Woodhouse wrote:
>>
>>> On Sun, 2007-01-07 at 03:11 -0600, Raquel Velasco and Bill Buck  
>>> wrote:
>>>> In the next 45-60 days we will offer new firmware for the EFIKA  
>>>> (and
>>>> the Pegasos/ODW).
>>>
>>> Was hoping to see this before the Fedora 7 release... ?
>

Raquel and Bill
http://bbrv.blogspot.com

Re: [PATCH] Probe Efika platform before CHRP.

[Matt Sealey]

Grant Likely wrote:
> On 1/6/07, Matt Sealey <matt@genesi-usa.com> wrote:
>>
>> One basic problem is we're talking about changing Efika to adapt to the
>> definitions, whims and determinations of the *Linux* community.
> 
> As opposed to the Linux community being asked to adapt to the
> definitions, whims and determinations of a single corporate entity?
> :-)
> 
>>
>> What if NetBSD, FreeBSD, QNX and WindRiver disagree with you guys?
> 
> I'm pretty sure that Linux is the only OS which is requiring a device
> tree for booting for new ports

NetBSD, FreeBSD will support the device tree for enumeration and the
ports in progress already do, and they also keep the Client Interface
open so they have a much better environment to work from than the
Linux "cache" of the device tree. If the OF device is there and there
is no driver in the OS, at least somehow (slowly) it could be used.

> Efika is the only 52xx board with open firmware on it.

Yes you're right.

At least from my point of view (I don't speak for Nico or Gerald here),
here is my discussion on the subject.

#1: As the only Open Firmware platform on this chip, what *we* do matters
here, we DO have to offer some stability in operating system support
and that means once we fix a device tree it needs to stay fairly similar,
which is exactly why we feel justified defining the tree standard for it :D

We do have to work with a lot more operating systems and vendors than
just Linux, and a "booting without Open Firmware" standard which proves
to solve the lack of device tree in U-Boot and other firmwares by making
more work for firmware and Linux kernel porting harder, is not really
something we are too concerned about. We hope we offer something a little
better than "recompile your device tree file, embed it into the kernel,
hope UBoot is the correct version, or recompile it, and flash and hope for
the best". What we offer here is fairly unique; both in that we seem to be
the only guys offering Open Firmware (especially a C-based one, OpenBIOS
is 90% Forth which is a terrible lock-in), and on the MPC5200 (or PowerPC
in general).

We also recognise OF and the device tree is flawed in some areas, RTAS
isn't the best thing in the world (but it is totally misused in Linux,
in places) so we are not BLIND to the need for change, we just think a
few compatibility names and node device_type changes are not really where
the real problems are.

#2: Personally I think naming device compatibility after the chip they are in
is a ridiculous lock-in, also. You may end up with a device_type of
ethernet, and compatibility flags for 100 SoC chip numbers. This is
fairly stupid.

Isn't the e300 PVR and e300 SVR, or any other device identifier on the
chip, a much better differentiator for drivers, than a named compatibility
flag? These are present in the device tree (/cpu node?) no? I can't boot
mine currently I blew up my power supply unfortunately.

I happen to know the next Freescale device won't be called 52xx so we're
talking about adding another compatibility naming to it like 51xx or 55xx
or 5xxx and changing everyone's firmware and Linux device trees again.

Or you could switch based on the processor! Cleaner, simpler, and doesn't
need each device to have a specially unique name, only a vague "class"
without some specific model number in it. If it's an SoC.. this is what
the SVR is for!

#3: While the above is basically a case for an SoC node (device parent
would have the SVR in it), this does not scale generically or flexibly
to non-SoC platforms where devices are nevertheless highly integrated.

AMD's new processors with integrated CPU and memory controller, will not
be classed as SoC's - how would you class them, really? Just a CPU with
some devices builtin (aha!) I would say. With the Pegasos, we have the
CPU, and the Marvell chip has Ethernet (not on PCI) and SRAM (also just
mapped in as memory) but it is not an SoC.

We just don't want to clutter up the root node with devices, otherwise
it would basically be more of a device shrubbery. The e300 SVR is also
defined in the manual (as is the e500 equivalent, and e200 equivalent)
as a CPU core feature, not a SoC-device feature, so this kind of
differentiation and numbering belongs in the CPU node.

~

Those are MY problems with the device tree specification you have with
"Booting Without Open Firmware". I am sure the other guys have other
things to say.

As for real bugs in the firmware; we definitely have 3 or 4 I have
noticed, be it the serial port not being changable baud rate from
the firmware itself (" /builtin/serial:38400" io doesn't set the
baud rate), AC97 is not configured (Sylvain hacked it though) even
though we have a node that specifies it, disk numbering is DEFINITELY
off (some facepalms going on at the office I think) even though we
definitely already have a fix for it, among a lot of other niggly
little things like the IrDA port (not set up, but I really think
PSC6 should be configurable from a firmware variable because it is
very multipurpose)

I would expect that it is so much easier, even if it does not strike
you as too "clean", to forget about naming compatibility nodes here,
and concentrate on the real showstoppers. I would consider the AC97
PSC not being set up, the IrDA PSC not being set up, the disk
numbering and any problems we're having with USB devices (argh) to
be real showstoppers.

We are working on a new firmware which will provide a lot of new
functionality in the coming month or two. I am not sure anything that
is merely based on principles or cleanliness of Linux code, to be changed.
I know it's not nice to look at your own code and see a bunch of hacks
for some hardware in there, but Linux and other OS are littered with these
already, you cannot avoid a bug or two, or a discrepency in something
else, and considering there are more important things in the design,
and in life in general, maybe it is best just to use what you've got
to work with (which is, unfortunately, what we gave you on the initial
board..)?


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

Re: [PATCH] Probe Efika platform before CHRP.

[Segher Boessenkool]

> (especially a C-based one, OpenBIOS
> is 90% Forth which is a terrible lock-in)

> Isn't the e300 PVR and e300 SVR, or any other device identifier on the
> chip, a much better differentiator for drivers, than a named 
> compatibility
> flag?

Only 7 days into the new year, and already we get some great
entries for best-joke-of-2007!  Too bad they're factually
incorrect.


Segher

Re: [PATCH] Probe Efika platform before CHRP.

[Matt Sealey]

Why is it so funny? I'd love to be enlightened rather than just plain
insulted about it.

I don't think any of that can be taken into account by simply giving things
*names* and then having a 3-week discussion and committee hearing about how
someone gave it a DIFFERENT name. It is even more strange to me, that nobody
HAS a standard name for the devices on the MPC5200B, yet we are arguing
about what would look nicer in the Linux source code?

Small example:

mpc5200b-fec, mpc5200-fec, mpc52xx-fec doesn't tell you anything, and
then with the 5500 or 5120 or something, you then have worked out you
named your original devices wrong, and now need to make it compatible
with those? Do you switch features on and off based on a string comparison?
What if a certain chip revision has a bug you need to work around (there
are plenty in the original MPC5200!), is that meant to be encoded in the
"compatible" property too, somehow? Or would you check the SVR too? If
you would check that, why not use this as the basis of the support for
that driver? For a PCI device, you are given basically a 32-bit UID for
each device, which is attached to a unique domain, host, bus, device
and function number. You manage well here without giving it names.

An Intel processor might return a string for CPUID - mine says it's a
"Intel(R) Pentium(R) M 1.70GHz". That string is absolutely useless in
determining it's compatibility. It's just a name. It may as well say
"Fight Famine In Rwanda" for all the good it does.

I think there are better ways and better places to encode certain
properties of the system as a whole (as the system is a lot more than
just that single chip) than having a bunch of strings in a property
which claim that it is compatible with something else, strictly defined
naming conventions and so on across chip ranges. Although we are talking
here mostly about two boards with the same chip basically - Lite5200
and Efika, there may be more boards with similar hardware supported,
extra hardware supported, new chips which look very much like the 5200
but have slightly different or bugfixed operation (and here is my point)
which I do not think you can encode in names and compatibile names.

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

Segher Boessenkool wrote:
>> (especially a C-based one, OpenBIOS
>> is 90% Forth which is a terrible lock-in)
> 
>> Isn't the e300 PVR and e300 SVR, or any other device identifier on the
>> chip, a much better differentiator for drivers, than a named 
>> compatibility
>> flag?
> 
> Only 7 days into the new year, and already we get some great
> entries for best-joke-of-2007!  Too bad they're factually
> incorrect.
> 
> 
> Segher
> 

Re: [PATCH] Probe Efika platform before CHRP.

[Benjamin Herrenschmidt]

On Sun, 2007-01-07 at 22:10 +0000, Matt Sealey wrote:

> mpc5200b-fec, mpc5200-fec, mpc52xx-fec doesn't tell you anything.

It does. It tells you exactly what you need. It tells you that you are
dealing, from the more precise to the more generic:

 - It's the implementation of the FEC cell in the mpc5200b
 - It's the implementation of the FEC cell in an mpc5200
 - it's the implementation of the FEC cell in a mpc52xx family chip

In addition, it really only tells you that it's compatible with those.
If we were to have 5500 or 5120, we could just say they are compatible
with mpc52xx. It doesn't matter, it's an arbitrary name chosen to
represent this cell because it wasn't given us a better name by the
constructor. The coutner example is IBM EMAC which has a proper name ...
EMAC :-). "FEC" is too generic, freescale calls "FEC" anything that
looks remotely like an ethernet controller, so we needed somethign more
precise.

>  and
> then with the 5500 or 5120 or something, you then have worked out you
> named your original devices wrong, and now need to make it compatible
> with those?

If they are compatible, they are compatible. In which case, there is
nothing wrong in having:

mpc5500-fec\0mpc52xx-fec in the "compatible" property. A bit clumsy
maybe but not wrong.

>  Do you switch features on and off based on a string comparison?

Yes, when the string is well defined. An example is the processor types
passed down via AT_PLATFORM to glibc and/or gcc. A string is much better
than a number, because at least, it's somewhat self-explanatory.

> What if a certain chip revision has a bug you need to work around (there
> are plenty in the original MPC5200!), is that meant to be encoded in the
> "compatible" property too, somehow?

Yes, it should tell you precisely what chip you are talking about,
again, from the more specific to the more generic. Of course, it's good
to have a more complete information there, thus a "model" property will
do no harm (could contain a part number if it's in the SoC bus), that
sort of thing in case there is some ambiguity that wasn't foreseen when
defining the initial binding, but most of the time, it can be avoided.

>  Or would you check the SVR too?

Best to avoid. Beside, SVR is completely specific to a given vendor.

>  If
> you would check that, why not use this as the basis of the support for
> that driver? 

Because the SVR represent the whole chip, every single part/cell in it.
We are specifically interested about a specific cell. In many cases,
they aren't any significant differences between implementations that
would require driver changes for every SVR out there.

Or take the case I gave in another email of Axon. the 4xx coreconnect
bits start to be used on non-4xx CPUs as part of a southbridge.... if we
had used some SVR-like thingy or even a PVR, suddenly, our entire
identification scheme stops working because those exact same cells are
no longer tied to a given CPU at all, they are in a south bridge !

> For a PCI device, you are given basically a 32-bit UID for
> each device, which is attached to a unique domain, host, bus, device
> and function number. You manage well here without giving it names.
> 
> An Intel processor might return a string for CPUID - mine says it's a
> "Intel(R) Pentium(R) M 1.70GHz". That string is absolutely useless in
> determining it's compatibility. It's just a name. It may as well say
> "Fight Famine In Rwanda" for all the good it does.

We don't care, we do care however what family of processor it is, which
version of the instruction set it adheres to, and that -is- generally
expressed by a string. In addition, we have implementation specific
"features" that don't necessarily need to be represented in there. And
in case we have to deal with a really specific bug, we -also- want
things like part number or mask revision etc...  But we don't use that
all the time, only for specific quirks.
 
> I think there are better ways and better places to encode certain
> properties of the system as a whole (as the system is a lot more than
> just that single chip) than having a bunch of strings in a property
> which claim that it is compatible with something else, strictly defined
> naming conventions and so on across chip ranges. Although we are talking
> here mostly about two boards with the same chip basically - Lite5200
> and Efika, there may be more boards with similar hardware supported,
> extra hardware supported, new chips which look very much like the 5200
> but have slightly different or bugfixed operation (and here is my point)
> which I do not think you can encode in names and compatibile names.

You logic escapes me.

Ben.

Re: [PATCH] Probe Efika platform before CHRP.

[Sylvain Munaut]

The very fact of matching device to driver by their
"name/type/compatible" list
is just the way it's done/specified in OF. Unless I'm deeply mistaken
(could always
happen, nobody's perfect heh) ...

The mpc5200b-psc-i2s and mpc5200-psc-i2s are in fact different device
... they
have different register set (compare both datasheet, you'll notice small
difference).
They just happen to be handled by the same driver and that driver
handles those
difference internally because they're small ...

So back to ethernet since you seem to like it ;) If fsl produce a new
chip (let's call
it mpc5321) , either it has _exactly_ the same interface (not a single
difference),
they you could call it mpc52xx in your device tree. Sure it looks weird but
sorry we can't predict the future and draft things for chips that don't
exist yet ...
If it's different, (even slighty, like it handles frame >2048 for
example), then
just give it a new name and add it as supported by the same driver. If
that's the
5321 entry that matched, then allow frames >2048.

>From what I've saw, if they can't even keep the same register set
between two
revision of the same controller, I doubt they will between chips. The I2C
controller is a good example, it's almost all the same between several
fsl chip,
except for the clocking selection. So as I see it, the I2C driver would have
several "compatible" match, for each different variation of the core. How
you name those instance is not really important as long as there is no
possible
conflicts.


You're proposing (if I understood correctly), that we first match the device
to a driver by using the normal name/type/compatible list but with very
broad names like "fsl-ethernet", then look at the SVR to know if it's in
fact
this driver we need to load (two fsl chip could have completly different
ethernet
cores) and also using SVR decide what "quirk" we need to apply.
Note I'm not even commenting yet, I first need to be sure of what you're
saying,
but the SVR thing will already not work if you're not in a SoC context ...


Regards,

    Sylvain


Matt Sealey wrote:
> Why is it so funny? I'd love to be enlightened rather than just plain
> insulted about it.
>
> I don't think any of that can be taken into account by simply giving things
> *names* and then having a 3-week discussion and committee hearing about how
> someone gave it a DIFFERENT name. It is even more strange to me, that nobody
> HAS a standard name for the devices on the MPC5200B, yet we are arguing
> about what would look nicer in the Linux source code?
>
> Small example:
>
> mpc5200b-fec, mpc5200-fec, mpc52xx-fec doesn't tell you anything, and
> then with the 5500 or 5120 or something, you then have worked out you
> named your original devices wrong, and now need to make it compatible
> with those? Do you switch features on and off based on a string comparison?
> What if a certain chip revision has a bug you need to work around (there
> are plenty in the original MPC5200!), is that meant to be encoded in the
> "compatible" property too, somehow? Or would you check the SVR too? If
> you would check that, why not use this as the basis of the support for
> that driver? For a PCI device, you are given basically a 32-bit UID for
> each device, which is attached to a unique domain, host, bus, device
> and function number. You manage well here without giving it names.
>
> An Intel processor might return a string for CPUID - mine says it's a
> "Intel(R) Pentium(R) M 1.70GHz". That string is absolutely useless in
> determining it's compatibility. It's just a name. It may as well say
> "Fight Famine In Rwanda" for all the good it does.
>
> I think there are better ways and better places to encode certain
> properties of the system as a whole (as the system is a lot more than
> just that single chip) than having a bunch of strings in a property
> which claim that it is compatible with something else, strictly defined
> naming conventions and so on across chip ranges. Although we are talking
> here mostly about two boards with the same chip basically - Lite5200
> and Efika, there may be more boards with similar hardware supported,
> extra hardware supported, new chips which look very much like the 5200
> but have slightly different or bugfixed operation (and here is my point)
> which I do not think you can encode in names and compatibile names.
>
>   

Re: [PATCH] Probe Efika platform before CHRP.

[Segher Boessenkool]

> The very fact of matching device to driver by their
> "name/type/compatible" list
> is just the way it's done/specified in OF. Unless I'm deeply mistaken

No, you're perfectly right.

> So back to ethernet since you seem to like it ;) If fsl produce a new
> chip (let's call
> it mpc5321) , either it has _exactly_ the same interface (not a single
> difference),
> they you could call it mpc52xx in your device tree.

No, it should be "compatible" = "mpc5321\0mpc52xx", since even
if it *supposedly* works identically, there always could be bugs.
The actual device version is a huge thing to leave out of the
device tree no matter what.

Linux would find it via "mpc52xx", if it has no reason to treat
mpc5321 specially, sure.  The device tree should still express
that information though; it shows information about the hardware
to whoever wants to use it (e.g., Linux), it does not *directly*
tell Linux how to handle the hardware.  This is a good thing.

> If it's different, (even slighty, like it handles frame >2048 for
> example), then
> just give it a new name and add it as supported by the same driver. If
> that's the
> 5321 entry that matched, then allow frames >2048.

Yeah.


Segher

Re: [PATCH] Probe Efika platform before CHRP.

[Matt Sealey]

Sylvain Munaut wrote:
> 
> You're proposing (if I understood correctly), that we first match the device
> to a driver by using the normal name/type/compatible list but with very
> broad names like "fsl-ethernet", then look at the SVR to know if it's in
> fact this driver we need to load (two fsl chip could have completly different
> ethernet cores) and also using SVR decide what "quirk" we need to apply.

Yes, to a degree. I understand that between MPC5200 and MPC5200B some things
did change quite a lot; register places, definitions and so on, even whole
ways of supporting a device. I think making a name distinction here and trying
to tie it down to some "model number convention" really loses it's shine.

Like Ben said, it's clumsy. Not wrong, but clumsy. I would say the same about
the difference between "ac97" and "sound" - it IS a clumsy naming convention
and it was contended here, but who really cares as long as the device is detected?
Personally I think "sound" is wrong, and ac97 more accurately defines the
device (I forget who's side I am on now with that!) according to the OF
precedents.

For a PCI device, you do have unique idenitifiers and they are also all present
in the device tree for easy scanning (RTAS also provides this) and picking up.
Linux is already full of lists of arrays of data in order to attach a device
driver to a certain device ID - even with names and compatible nodes, the ethernet
and audio and so on drivers for the Efika and Lite5200 have potentially large
lists of properties they must check for to determine if the device is correct
(one each for mpc5200, mpc5200b, mpc52xx, any compatible future chips will have
to list every one of these in their compatible property to 'be correct'..)

So, giving it some other name is no problem at all. Just add the name into the
list. You can never get rid of the list, and adding entries.. well.. it may
look clumsy, but it is not wrong! Especially if you're the first to name it.
Linux should, I am saying, match against what the firmware provides, not
vice-versa. I don't think it's logical for firmware vendors to keep changing
names or maintain these huge lists... just because of a philosophical difference
on 2 lines of code in Linux? Especially when the other OS guys have not made
any fuss..

> Note I'm not even commenting yet, I first need to be sure of what you're
> saying, but the SVR thing will already not work if you're not in a SoC context ...

Yes, I do think that there needs to be a lot less chip naming in there, and some
other way of identifying chipset features. I agree with Ben there is some issue
when SoC components drop out into other chips, but this fully melds in with my own
and bplan's insistance that the "SoC" node idea sucks.

The firmware device tree describes a platform, be that a single board of multiple
revisions, or even a range of boards. To place all SoC devices in the
root node, we considered clumsy at bplan, so they invented "builtin" instead. This
works also for the Pegasos, where rightly there is no SoC. It works for every
other board we ported the firmware too under contract to do so (every G4 Freescale
board since the 7447, every Marvell dev board, the AMCC "Yosemite"..). It really
doesn't matter where you place it, or what you call it in the end, as long as
somehow you can determine what kind of device you are looking for.

device_type = "ethernet", well, then it's ethernet. Which kind? Well, it's the
kind that can only be available on that particular combination of hardware. If
it is an MPC5200B chip or an MPC5200 chip, you can determine exactly which one
it is. If it is an MPC8349E or an MPC82xx or something, it may be different,
but in general you can determine the exact device you have much easier (one
register comparison..) than running through a null-terminated string list,
doing comparisons against another list, and you get a wealth of information
out of that single 32-bit register value of the SVR that you would not from
a simple name. This is where it differs from PCI devices which you can have
10 of them in the same box and need to work out which one came from where, and
what esoteric combination the user will use. The device tree is simply there
to inform you what is present and what is configured (especially in the case
when a unit can be configured as multiple devices and may be dangerous to
reconfigure) and on an SoC or even a northbridge or southbridge which
implements "non PCI" devices, you have plenty of options for determining
exactly what is in them (/builtin/ethernet@1 on Pegasos is the Marvell
controller, even though we use a chip with 2 ethernet controllers in it,
only one works - there is no PHY card for the other. However rather
scarily the option of 1 or 2 ethernet ports in Linux is defined by a
kernel config flag... so much for the device tree..)

I am sure there are other things that can be checked and verified against, although
there will also be stupid things like.. the only example I can think of is that
the MPC7447 and MPC7457 G4 chips have identical PVRs so you can't tell if there
are L3 tags or not (or if there is any L3 at the end of it) without some loopy
proprietary hardware logic or other system controller feature to inform you. That's
not much fun if your CPU board is removable for example :D

Giving it an esoteric device name string, and listing all it's compatible
hardware in the firmware tree? Considering Linux maintains it's own little
list it checks AGAINST, I see no reason to even name it. It just seems
like a waste of time and space where some other heuristic would be a little
more specific or more foolproof. If the same driver supports multiple devices,
it will check the device to see if it fits with it's list of devices it
supports. Like a PCI device driver has a list of compatible vendor/device/function/id
inside it. Not just for quirks but just for detection. The compatible property
I think is just being misused in the device tree and it's creating more code
and more lists and more firmware work to support it.

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



> 
> 
> Regards,
> 
>     Sylvain
> 
> 
> Matt Sealey wrote:
>> Why is it so funny? I'd love to be enlightened rather than just plain
>> insulted about it.
>>
>> I don't think any of that can be taken into account by simply giving things
>> *names* and then having a 3-week discussion and committee hearing about how
>> someone gave it a DIFFERENT name. It is even more strange to me, that nobody
>> HAS a standard name for the devices on the MPC5200B, yet we are arguing
>> about what would look nicer in the Linux source code?
>>
>> Small example:
>>
>> mpc5200b-fec, mpc5200-fec, mpc52xx-fec doesn't tell you anything, and
>> then with the 5500 or 5120 or something, you then have worked out you
>> named your original devices wrong, and now need to make it compatible
>> with those? Do you switch features on and off based on a string comparison?
>> What if a certain chip revision has a bug you need to work around (there
>> are plenty in the original MPC5200!), is that meant to be encoded in the
>> "compatible" property too, somehow? Or would you check the SVR too? If
>> you would check that, why not use this as the basis of the support for
>> that driver? For a PCI device, you are given basically a 32-bit UID for
>> each device, which is attached to a unique domain, host, bus, device
>> and function number. You manage well here without giving it names.
>>
>> An Intel processor might return a string for CPUID - mine says it's a
>> "Intel(R) Pentium(R) M 1.70GHz". That string is absolutely useless in
>> determining it's compatibility. It's just a name. It may as well say
>> "Fight Famine In Rwanda" for all the good it does.
>>
>> I think there are better ways and better places to encode certain
>> properties of the system as a whole (as the system is a lot more than
>> just that single chip) than having a bunch of strings in a property
>> which claim that it is compatible with something else, strictly defined
>> naming conventions and so on across chip ranges. Although we are talking
>> here mostly about two boards with the same chip basically - Lite5200
>> and Efika, there may be more boards with similar hardware supported,
>> extra hardware supported, new chips which look very much like the 5200
>> but have slightly different or bugfixed operation (and here is my point)
>> which I do not think you can encode in names and compatibile names.
>>
>>   
> 

Re: [PATCH] Probe Efika platform before CHRP.

[Sylvain Munaut]

Matt Sealey wrote:
> So, giving it some other name is no problem at all. Just add the name
> into the
> list. You can never get rid of the list, and adding entries.. well..
> it may
> look clumsy, but it is not wrong! Especially if you're the first to
> name it.
> Linux should, I am saying, match against what the firmware provides, not
> vice-versa. I don't think it's logical for firmware vendors to keep
> changing
> names or maintain these huge lists... 
For devices themselves (like serial, fec, ...), if there was only issues
there,
I must admit I'd consider just adding the other "compatible" property (look
at the current mpc52xx_uart.c driver, it has an entry only for the efika).
BUT :
 - I'd really prefer to have it with the standard name, we're early
enough to
   change it and I love consistency ;)
 - The "other" name must _not_ conflict with the official one (and here
   that's not the case, mpc5200-ata would trigger activation of 5200 errata
   correction for ATA ... )
 - You will anyway release an update so _why_ not change that, I haven't
   heard so far a single good reason why not ...
 - For more "system" parts (like bestcomm/sram/pic), there it's a lot more
   annoying and I just want the received dt to exactly fit.

Since some changes couldn't be handled by just adding en entry to the
of_match
table (chrp type, missing irqs, sram type, ...) , I needed fixups anyway
so I
implemented all the fixups I'd like to see and deal with it in a single
place,
so at the end I have things exactly like for other 52xx boards ...

> just because of a philosophical difference
> on 2 lines of code in Linux? Especially when the other OS guys have
> not made
> any fuss..
But did the other OS support other 52xx board ? (question, I really
don't know)

If it only needed another "compatible" entry in the driver list of a
couple of
driver, and that there was no way the fw could ever change, I think we would
have (reluctantly ;) done it, but the problem is both deeper and the vendor
(you ;) have the clear opportunity to fix it better.


    Sylvain

Re: [PATCH] Probe Efika platform before CHRP.

[Benjamin Herrenschmidt]

> device_type = "ethernet", well, then it's ethernet. Which kind? Well, it's the
> kind that can only be available on that particular combination of hardware. If
> it is an MPC5200B chip or an MPC5200 chip, you can determine exactly which one
> it is. If it is an MPC8349E or an MPC82xx or something, it may be different,
> but in general you can determine the exact device you have much easier (one
> register comparison..) than running through a null-terminated string list,
> doing comparisons against another list, and you get a wealth of information
> out of that single 32-bit register value of the SVR that you would not from
> a simple name. This is where it differs from PCI devices which you can have
> 10 of them in the same box and need to work out which one came from where, and
> what esoteric combination the user will use. The device tree is simply there
> to inform you what is present and what is configured (especially in the case
> when a unit can be configured as multiple devices and may be dangerous to
> reconfigure) and on an SoC or even a northbridge or southbridge which
> implements "non PCI" devices, you have plenty of options for determining
> exactly what is in them (/builtin/ethernet@1 on Pegasos is the Marvell
> controller, even though we use a chip with 2 ethernet controllers in it,
> only one works - there is no PHY card for the other. However rather
> scarily the option of 1 or 2 ethernet ports in Linux is defined by a
> kernel config flag... so much for the device tree..)

I don't know where to begin to explain how wrong I think you are ...

To simplify, let's say that a device should be represented by a device
node that is pretty much self contained. There should be no need to go
look at anything else (processor node, SVR register, whatever). You
should be able to uniquely identify every device in the system based on
a few properties, and OpenFirmware provides precisely a mecanism to do
so.

This mecanism, is the "compatible" property.

If you look closely at the OF PCI binding (since PCI is one of your
examples), you'll notice that while pciDDDD,VVVV (device,vendor) is at
the beginning of the compatible list, pciCCCC (class) follows.

Again, same logic as explained earlier: you define your device from the
more specific to the more generic.

In many cases, a device programming interface is generic (for example,
the UHCI, OHCI and EHCI USB host controller drivers, on PCI, match based
on the class, not the vendor/device IDs. They only use the later for
identifying a handful a chips that need erratas/quirks, they do NOT have
and do not need a complete list of all the vendor/device ID combinations
for those types of controllers).

That sort of class level matching is also widely used for USB devices.

Thus, the driver -choses- at what level it wants to detect supported
devices, based on that, -and- can still explicitely look at the more
"precise" indentification when it needs to single out a given
revision/version of a piece of hardware.

So this mecanism is great and isn't actually that clumsy at all. What
might eventually be clumsy is purely the naming choice when the vendor
doesn't provide something nice/unique enough for a given part. For
example, in order to properly identify the 52xx "fec" ethernet part,
since we don't have a nice/unique codename for it, we use mpc52xx-fec.
it's good enough and it's our convention.

For PCI devices, the compatible property is defined to be a fairly long
list, which can contain vid/did pairs (and multiple ones as one device
cna be made HW compatible with another one) but goes down to class based
matching which is more useful for well defined programming interfaces.

Strings are perfect, much better than numbers, as long as we properly
define the content of the string.

Ben.

Re: [PATCH] Probe Efika platform before CHRP.

[Matt Sealey]

Segher Boessenkool wrote:
>> (especially a C-based one, OpenBIOS
>> is 90% Forth which is a terrible lock-in)

Re: [PATCH] Probe Efika platform before CHRP.

[Matt Sealey]

Segher Boessenkool wrote:
>> (especially a C-based one, OpenBIOS
>> is 90% Forth which is a terrible lock-in)

^^^^^^^

> Only 7 days into the new year, and already we get some great
> entries for best-joke-of-2007!  Too bad they're factually
> incorrect.

I'll correct that then, FirmWorks (as used on OLPC) is 90% Forth, and
I think there is a shortage of Forth coders compared to driver-writing
low-level firmware coders who can do C or C++ or any other language
for that matter, I think it makes it commercially unusable if you want
any kind of turnaround on device support.

OpenBIOS is maybe 30% Forth supplementing a fairly C-based implementation
but it is still too much Forth. It also relies on a boot loading stage
previous to it (no abstraction!) like UBoot or a PC BIOS to start with,
so commercially without some work, it's fairly useless.

Either way, without talking about CodeGen's source release (not
commercially usable, and debatably not GPL-compatible either) we're
the only company doing Open Firmware for PowerPC devices, with the
turnaround time we have (talk to Marvell if you like) and offering
the kind of feature support (x86 emulator) we plant on top on request
(Linux BSP including working 3D drivers just to prove the firmware
works and the emulator is setting up any card they desire correctly).

Maybe IBM's PAPR firmware will be great when it arrives sometime in
2008, and put us out of business, but until then I stand by that :D

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

Re: [PATCH] Probe Efika platform before CHRP.

[Segher Boessenkool]

>>> (especially a C-based one, OpenBIOS
>>> is 90% Forth which is a terrible lock-in)
>
> ^^^^^^^
> I'll correct that then, FirmWorks (as used on OLPC) is 90% Forth,

Much more than 90%, heh.

> and
> I think there is a shortage of Forth coders compared to driver-writing
> low-level firmware coders who can do C or C++ or any other language
> for that matter, I think it makes it commercially unusable if you want
> any kind of turnaround on device support.

> OpenBIOS is maybe 30% Forth supplementing a fairly C-based 
> implementation
> but it is still too much Forth.

I really am not going to argue with you about this; you obviously
have no experience at all with this stuff, what you're saying is
based on preconceptions and nothing more.

> It also relies on a boot loading stage
> previous to it (no abstraction!) like UBoot or a PC BIOS to start with,
> so commercially without some work, it's fairly useless.

It is made to work with LinuxBIOS, instead.  Please research your
statements.

> Either way, without talking about CodeGen's source release (not
> commercially usable, and debatably not GPL-compatible either) we're
> the only company doing Open Firmware for PowerPC devices,

Same comment.

[advertisement snipped here]

It's great you feel so nice about the feature set of your
product, but I fail to see what that has to do with your
attacks on technical sound ways to do technical stuff.


Anyway, let me explain some very basic things.  PowerPC Linux
uses an Open Firmware-style device tree to communicate things
(mostly what hardware is there) from the firmware or the
boot loader to the kernel.  You cannot change this.  If you
really refuse to play within the rules of the game, feel free
to create and maintain your own fork of the kernel tree.


Segher

Re: [PATCH] Probe Efika platform before CHRP.

[Benjamin Herrenschmidt]

> NetBSD, FreeBSD will support the device tree for enumeration and the
> ports in progress already do, and they also keep the Client Interface
> open so they have a much better environment to work from than the
> Linux "cache" of the device tree. If the OF device is there and there
> is no driver in the OS, at least somehow (slowly) it could be used.

The idea that keeping OF alive is a "much better environment" to work
from is at best an illusion.
 
> #1: As the only Open Firmware platform on this chip, what *we* do matters
> here, we DO have to offer some stability in operating system support
> and that means once we fix a device tree it needs to stay fairly similar,
> which is exactly why we feel justified defining the tree standard for it :D

And that's why we feel justified asking you to change it for the very
reason that you did this "definition" behind closed doors, repeately
refusing to discuss it publically with the other parties involved in
porting linux to the 52xx

> We do have to work with a lot more operating systems and vendors than
> just Linux, and a "booting without Open Firmware" standard which proves
> to solve the lack of device tree in U-Boot and other firmwares by making
> more work for firmware and Linux kernel porting harder, is not really
> something we are too concerned about.

If that's what you think it is, then you are full of sh*t. Sorry, but
I'm getting really badly pissed off by your attitude and that of bPlan.
There is a limit to the amount of arrogance I can cope with.

>  We hope we offer something a little
> better than "recompile your device tree file, embed it into the kernel,
> hope UBoot is the correct version, or recompile it, and flash and hope for
> the best". What we offer here is fairly unique; both in that we seem to be
> the only guys offering Open Firmware (especially a C-based one, OpenBIOS
> is 90% Forth which is a terrible lock-in), and on the MPC5200 (or PowerPC
> in general).

Can we cut on the marketing filler a bit here and get back to useful
points ?

> We also recognise OF and the device tree is flawed in some areas, RTAS
> isn't the best thing in the world (but it is totally misused in Linux,
> in places) so we are not BLIND to the need for change, we just think a
> few compatibility names and node device_type changes are not really where
> the real problems are.

It's where most of the problems that matter in pratice are. As for
"runtime abstraction of hardware", I agree, RTAS sucks. As SMM BIOS
sucks. As ACPI tables suck. As keeping OF alive suck badly too. In fact,
there isn't a single attempt at doing that sort of thing that has not
resulted in creating more problems than it solves, except maybe in some
very limited circumstances where the firmware and the OS have been very
closely tailored to each other.

In fact, history so far proves that it's a bad idea. It sounds good at
first, but when you get down to the details, it doesn't work out.

Get away with it, nothing works as well as a good HW description &
documentation and proper drivers for it. 
 
> #2: Personally I think naming device compatibility after the chip they are in
> is a ridiculous lock-in, also. You may end up with a device_type of
> ethernet, and compatibility flags for 100 SoC chip numbers. This is
> fairly stupid.

That isn't the rule. The rule for compatible is to name after the
functional cell used. However, if it happens that this cell is very
specific to a familiy of SOCs (which is common), then go for it. The
rule is also that "compatible" is a list from the most specific to the
most generic. Thus it _ALSO_ shall contain a name specific to a given
implementation in order to allow the driver to differenciate them in
order to work around the always present implementation specific errata.

> Isn't the e300 PVR and e300 SVR, or any other device identifier on the
> chip, a much better differentiator for drivers, than a named compatibility
> flag? These are present in the device tree (/cpu node?) no? I can't boot
> mine currently I blew up my power supply unfortunately.

The PVR of the core is probably the worst possible choice there :-) If
there's one thing that really doesn't matter much as far as device
identification is concerned, it's what core is used on the die.

> I happen to know the next Freescale device won't be called 52xx so we're
> talking about adding another compatibility naming to it like 51xx or 55xx
> or 5xxx and changing everyone's firmware and Linux device trees again.

Why ? Who cares what they call the next one ? Once we have a defined
binding that properly identify those parts. If their next chip has an
FEC that is actually compatible with the 52xx-fec, then it should
contain that in the compatible property, whatever the marketing name at
the time is. We pick a name that defines a programming interface. It
could be anything. It could be the codename of the cell of we knew it.
52xx-fec is as good as anything else, as long as we _agree_ what
convention we want to use and keep consistent accross devices. It's an
arbitrary choice.

> Or you could switch based on the processor! Cleaner, simpler, and doesn't
> need each device to have a specially unique name, only a vague "class"
> without some specific model number in it. If it's an SoC.. this is what
> the SVR is for!

And totally bogus.

> #3: While the above is basically a case for an SoC node (device parent
> would have the SVR in it), this does not scale generically or flexibly
> to non-SoC platforms where devices are nevertheless highly integrated.

? I don't understand your sentence.

> AMD's new processors with integrated CPU and memory controller, will not
> be classed as SoC's - how would you class them, really? Just a CPU with
> some devices builtin (aha!) I would say. With the Pegasos, we have the
> CPU, and the Marvell chip has Ethernet (not on PCI) and SRAM (also just
> mapped in as memory) but it is not an SoC.

Who cares ? I don't personally think the word "SoC" is indeed very good
as, as you pointed out, things can be implemented in different ways with
the same parts. However, again, it's just arbitrary naming conventions
to represent the specific set of IP blocks those drivers we are writing
for.

Take a very good example here: 4xx and cell.... The 4xx processors use
the IBM CoreConnect library of parts for their on-chip devices (EMAC
ethernet, MAL, PLB5, PLB4, OPB busses, etc...). They are technically
SoCs. However, we now have this southbridge for the Cell processor which
happens to ... contain a PLB5 and all ther other bits & pieces. In fact,
it also contains a 405 so it could be considered a SoC... or not :-) The
point is:

IT DOES NOT MATTER !

It's all a naming convention. We call plb5 ... plb5 heh ! The emac will
have a compatible property with something like "emac-axon\0emac4\0emac".
That is, from the more specific to the more generic: The axon
implementation of emac, which is an emac4 cell which is an emac familiy
of ethernet cores. This is a convention. Once decided (there will be a
public discussion, unless nobody disagrees with my proposal there), if
tomorrow, a version of AMD64 is released with an EMAC in it and x86
folks want an OF-like device-tree (which is something that might be
happening sooner than expected), it will hopefully follow that
convention.

And this has nothing to do with booting without OF. In fact, we should
split that document between what is indeed booting without OF (the
format of the flattened device-tree that can be provided by zImage or
uboot if you don't have a real OF) from what is in practice OF bindings
for a variety of chips out there.  

> We just don't want to clutter up the root node with devices, otherwise
> it would basically be more of a device shrubbery. The e300 SVR is also
> defined in the manual (as is the e500 equivalent, and e200 equivalent)
> as a CPU core feature, not a SoC-device feature, so this kind of
> differentiation and numbering belongs in the CPU node.

If there is something that does NOT belong in the CPU nodes, it's
anything related to the on chip devices. Bang bang... try again.

> ~
> 
> Those are MY problems with the device tree specification you have with
> "Booting Without Open Firmware". I am sure the other guys have other
> things to say.

You don't seem to understand it much though.

Ben.

Re: [PATCH] Probe Efika platform before CHRP.

[David Woodhouse]

On Sun, 2007-01-07 at 20:09 +0000, Matt Sealey wrote:
> I would expect that it is so much easier, even if it does not strike
> you as too "clean", to forget about naming compatibility nodes here,
> and concentrate on the real showstoppers. I would consider the AC97
> PSC not being set up, the IrDA PSC not being set up, the disk
> numbering and any problems we're having with USB devices (argh) to
> be real showstoppers. 

I'm inclined to agree. What I said was "since they have showstopper bugs
to fix, we might as well let them fix the less important device-tree
stuff at the same time."

Please can we have a firmware with the important stuff fixed, and
preferably the simple and uncontentious device-tree fixes too; like
perhaps no longer pretending to be CHRP?

The other device-tree stuff you're arguing about is less important,
because it isn't _that_ hard to fix it up in prom_init() -- although it
would have been nice if the debate had happened when people were trying
to put the spec together in the first place, rather than only now.

-- 
dwmw2

Re: [PATCH] Probe Efika platform before CHRP.

[Matt Sealey]

David Woodhouse wrote:
> On Sun, 2007-01-07 at 20:09 +0000, Matt Sealey wrote:
>> I would expect that it is so much easier, even if it does not strike
>> you as too "clean", to forget about naming compatibility nodes here,
>> and concentrate on the real showstoppers. I would consider the AC97
>> PSC not being set up, the IrDA PSC not being set up, the disk
>> numbering and any problems we're having with USB devices (argh) to
>> be real showstoppers. 
> 
> I'm inclined to agree. What I said was "since they have showstopper bugs
> to fix, we might as well let them fix the less important device-tree
> stuff at the same time."

The problem is that the firmware development and testing cycle is pretty
intensive; if we change any string in the code, if it is publically
present then it needs to be passed through a set of tests to make sure
it is working. If it means collaborating with Linux developers it means
sending out firmware updates, getting results back.. just for changing
one string to another.

When it doesn't make any difference at all ("sram" and "memory" and
"ac97" to "sound", the difference between mpc5200-blah and mpc5200b-blah
and a couple of stray null characters) I feel there's no point whatsoever
in doing it when it entails that much work.

In the Pegasos 1.2 firmware we definitely had some stupid spelling
mistakes (one RTAS token at LEAST was wrong :) but since nobody ever
used them, they were never really fixed. The CPU node presented l3
cache data for the 7447 even though we never made a 7457 card and
could differentiate between them at the point that firmware was out.

But nobody cares. It doesn't make a single bit of functional difference
where the thing is fixed if it IS needed though. It may be cleaner in
the firmware, but what I saw here is Sylvain saying that these fixes
will "never be accepted in the mainline" because they should be fixed
in firmware. We can't fix the 1.3 firmware, it's already on the
first production batch, end of story. No committee or discussion does
anything to change that. We can and will fix as much as is relevant
in the next one but if we can't.. does that mean Linux is intentionally
crippling itself?

I don't care if it makes the platform look full of bugs as long as
Linux runs on it. I am concerned when a real hardware bug is marked
as a platform bug (Via IDE IRQ quirk for Pegasos is a good example,
this is a Via chipset bug, not a PowerPC or Pegasos-specific thing)
but these are really just platform bugs, that we would like to see
code fixed up for it. If it means MPC5200 drivers have Efika fixes
in it, then *sorry* but I am thinking of people who want to use
PowerPC Linux here.

I really want to give the customers the choice; because sometime soon
we may have NetBSD, FreeBSD, QNX, whatever else on the board, and
we could be saying "well, these OS's all work fine, Linux does too
up to a point, but they have crippled it" because it would be the truth.

> Please can we have a firmware with the important stuff fixed, and
> preferably the simple and uncontentious device-tree fixes too; like
> perhaps no longer pretending to be CHRP?

That should be most definitely fixed in February. We like CHRP for what it
is but the reality of it is that it's so weakly defined in Linux and not
used at all in any other OS, there is no point to it. RTAS is totally
misused in places. We have a solution for it.. maybe a little contentious
but at least it will not be presenting our systems as a standard they
may only half-be (Pegasos was VERY CHRP besides the interrupt controller,
Efika is about as CHRP as my grandmother's handbag).

> The other device-tree stuff you're arguing about is less important,
> because it isn't _that_ hard to fix it up in prom_init() -- although it
> would have been nice if the debate had happened when people were trying
> to put the spec together in the first place, rather than only now.

We had the final firmware pretty much completed and in a no-minor-tweaks
phase before any spec was ever considered on this mailing list, which is
the whole problem. Being a little pioneering about it means we fell afoul
of the guys who think everything should be discussed to death before doing
it. Efika was already delayed 6 months because of errata and RoHS problems,
and we just don't have the time in any case to sit here and discuss a
million minor things when the number of boards in production was a big fat
zero, or now that boards are out in the field and need support.

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

Re: [PATCH] Probe Efika platform before CHRP.

[Sylvain Munaut]

Ok, let's try to at least be a little productive:

Could you tell us at least what in that list will be taken care of,
what you might consider and what you really will never change
while you're standing ;)

Her we go :

1) What I think should absolutely be fixed : (non compliancy
with the ieee1275 document are marked as bug) :
 - PSC init (for PSC2 and PSC6 you said as well): Theses
   are obviously bugs, no argument there.
 - Missing IRQ for the sound node : Again, this is obviously
   missing, the interrupt does exists and it should be in the
   dt, whether or not you think the driver will use it or not.
 - Partition numbering problem (again, an obvious bug)
 - Double \0 : This one is a bug (just confirmed it re-reading
   the specs) Altough I must admit the kernel just won't care
   it's nevertheless a bug and should be
 - "chrp" type : If I understood correctly your previous mail
   you're ok with it.
 - "memory" type of the SRAM: I quote the 1275.pdf, section
   3.7.6 : "In this context, 'memory' refers to traditional
   RAM, suitable for temporary storage of data". I think we
   can agree sram is not conventionnal RAM. You're free (and
   should) still use the reg and available property but not
   the type ram. I must also say that the current fixup I
   implemented doesn't really work because this can only be
   fixed too late ... (node already processed and added as
   normal memory).

2) What I'd really like to see fixed (but that I can't mark as
'bugs' as obviously as the other)
 - The compatible properties of system node (like sram,
   bestcomm and pic) should at least include the mpc52xx-...
   strings as defined in the 'linux' bindings. Better than
   include, be exacty what has been defined but include would
   "do the trick".



3) 'real' Device compatible names : Those can be handled in
the driver, eventually differentiating from other using the
name ... (Although the ata node is really boring because it
_perfectly_ match the defined binding of the 5200 ATA ...)

Without (1), we would need a nvramrc (to fix very early stuff),
and since it's needed, might as well fix everything in nvramrc.
With only (1), we will still need a fixup, but that could
be done in efika_fixup in prom_init.c, since we need fixup
there, we will probably do everything there.
With (1) & (2) the efika will boot, just some driver won't
work so we need to add some more entry in their of_match
but that's acceptable.

> When it doesn't make any difference at all ("sram" and "memory" and
> "ac97" to "sound", the difference between mpc5200-blah and mpc5200b-blah
> and a couple of stray null characters) I feel there's no point whatsoever
> in doing it when it entails that much work.
Well, you're gonna need to change _some_ strings at least (if
not, I'm just loosing my time here ...) I can hardly believe
changing a string to another is that hard, especially if it's
to comply to the specification you claim to be compatible with ;p

(and 'ac97' should be 'sound' as it is now, certainly don't go
change it ;)

> We can't fix the 1.3 firmware, it's already on the
> first production batch, end of story. 
You mean the new firmware can't be flashed to the old boards ?



    Sylvain


PS: I know there are already fixup but ... my mistake I keep
dreaming of a world when things do get fixed without hacks ;-)

Re: [PATCH] Probe Efika platform before CHRP.

[Sylvain Munaut]

Sylvain Munaut wrote:
> 2) What I'd really like to see fixed (but that I can't mark as
> 'bugs' as obviously as the other)
>  - The compatible properties of system node (like sram,
>    bestcomm and pic) should at least include the mpc52xx-...
>    strings as defined in the 'linux' bindings. Better than
>    include, be exacty what has been defined but include would
>    "do the trick".
>   
Forgot something here :

The "bestcomm" node should have all the interrupts for all task
in it's interrupts property instead of a non existent IRQ.
Currently it does have <2 0 3> which doesn't really exists (it's the
casaded interrupt IIRC, this is from memory, no time to check
that now).
And it should have <3 0 0> <3 1 0> .... <3 15 0>.
Because those are really bestcomm interrupt and I think they
do belong there.

I know I can find thos in your "bestcomm-txtask bestcomm-rxtask"
nodes for preloaded tasks and it's good they are there.
But what if I want to use DMA for PSC6 where you didn't
load anytask ... I can find some free ram in the sram node, some
non-used tasks id but I got nowhere to find the interrupt ...
So I'd like to have them there as well ...


    Sylvain

Re: [PATCH] Probe Efika platform before CHRP.

[Matt Sealey]

This will definitely change in the next firmware from the discussion I've
had with Gerald.

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

Sylvain Munaut wrote:
> Sylvain Munaut wrote:
>> 2) What I'd really like to see fixed (but that I can't mark as
>> 'bugs' as obviously as the other)
>>  - The compatible properties of system node (like sram,
>>    bestcomm and pic) should at least include the mpc52xx-...
>>    strings as defined in the 'linux' bindings. Better than
>>    include, be exacty what has been defined but include would
>>    "do the trick".
>>   
> Forgot something here :
> 
> The "bestcomm" node should have all the interrupts for all task
> in it's interrupts property instead of a non existent IRQ.
> Currently it does have <2 0 3> which doesn't really exists (it's the
> casaded interrupt IIRC, this is from memory, no time to check
> that now).
> And it should have <3 0 0> <3 1 0> .... <3 15 0>.
> Because those are really bestcomm interrupt and I think they
> do belong there.
> 
> I know I can find thos in your "bestcomm-txtask bestcomm-rxtask"
> nodes for preloaded tasks and it's good they are there.
> But what if I want to use DMA for PSC6 where you didn't
> load anytask ... I can find some free ram in the sram node, some
> non-used tasks id but I got nowhere to find the interrupt ...
> So I'd like to have them there as well ...
> 
> 
>     Sylvain
> 

Re: [PATCH] Probe Efika platform before CHRP.

[Sylvain Munaut]

Sylvain Munaut wrote:
> 1) What I think should absolutely be fixed : (non compliancy
> with the ieee1275 document are marked as bug) :
>  - PSC init (for PSC2 and PSC6 you said as well): Theses
>    are obviously bugs, no argument there.
>  - Missing IRQ for the sound node : Again, this is obviously
>    missing, the interrupt does exists and it should be in the
>    dt, whether or not you think the driver will use it or not.
>  - Partition numbering problem (again, an obvious bug)
>  - Double \0 : This one is a bug (just confirmed it re-reading
>    the specs) Altough I must admit the kernel just won't care
>    it's nevertheless a bug and should be
>  - "chrp" type : If I understood correctly your previous mail
>    you're ok with it.
>  - "memory" type of the SRAM: I quote the 1275.pdf, section
>    3.7.6 : "In this context, 'memory' refers to traditional
>    RAM, suitable for temporary storage of data". I think we
>    can agree sram is not conventionnal RAM. You're free (and
>    should) still use the reg and available property but not
>    the type ram. I must also say that the current fixup I
>    implemented doesn't really work because this can only be
>    fixed too late ... (node already processed and added as
>    normal memory).
>   
Oops, forgot something here as well :
 Check for typo, for example "#interuppt-cells" vs "#interrupt-cells"


    Sylvain

Re: [PATCH] Probe Efika platform before CHRP.

[Matt Sealey]

Sylvain Munaut wrote:
>>   
> Oops, forgot something here as well :
>  Check for typo, for example "#interuppt-cells" vs "#interrupt-cells"

See what I mean?

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

Re: [PATCH] Probe Efika platform before CHRP.

[Matt Sealey]

Sylvain Munaut wrote:
> Ok, let's try to at least be a little productive:
> 
>> We can't fix the 1.3 firmware, it's already on the
>> first production batch, end of story. 
 >
> You mean the new firmware can't be flashed to the old boards ?

I mean we don't have the new firmware out and there is two months
of Linux usage to go before it will be.. at least.. granted we will
be having this discussion of what will need to be changed or not
at that time, yet again, because of some other changes we make.

However, changing a string IS a big deal when it needs to be tested
and quality assured for a commercial release. If it makes no
difference at all, it is a lot easier and less time consuming simply
not to change it :D

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

Re: [PATCH] Probe Efika platform before CHRP.

[Sylvain Munaut]

Matt Sealey wrote:
> I mean we don't have the new firmware out and there is two months
> of Linux usage to go before it will be.. at least.. granted we will
> be having this discussion of what will need to be changed or not
> at that time, yet again, because of some other changes we make.
Or maybe you could tell us now what you're planning to
change/add ...

If not, that will be exactly the same thing, if for whatever
reason we need more infos in the device tree and that's not
currently specified, we'll define some binding for what's
missing that will end up being incompatible with what you did
during 2 month in secret and in the mean time the whole driver/support
code will have been written based on what has been discussed in
public ...


> This will definitely change in the next firmware from the discussion I've
> had with Gerald.

Could you be a little more precise about what you're planning
on 'fixing' from the list I posted ? (like point 1, 2 but not 3.
Or 1a, 1b 2a & 2b ...) ...


    Sylvain

[PATCH] powerpc export rtas_set_slot_reset()

[Linas Vepstas]

Hi Paul,
A patch that provides an export for a bug being worked on the
IPR evice driver.

--linas

Export the symbol for the PCI slot reset function; this
will allow it to be called from a module. 

Signed-off-by: Linas Vepstas <linas@austin.ibm.com>

----
 arch/powerpc/platforms/pseries/eeh.c |    1 +
 1 file changed, 1 insertion(+)

Index: linux-2.6.19-git7/arch/powerpc/platforms/pseries/eeh.c
===================================================================
--- linux-2.6.19-git7.orig/arch/powerpc/platforms/pseries/eeh.c	2006-12-14 14:41:48.000000000 -0600
+++ linux-2.6.19-git7/arch/powerpc/platforms/pseries/eeh.c	2006-12-15 12:01:28.000000000 -0600
@@ -626,6 +626,7 @@ int rtas_set_slot_reset(struct pci_dn *p
 
 	return rc;
 }
+EXPORT_SYMBOL_GPL(rtas_set_slot_reset);
 
 /* ------------------------------------------------------- */
 /** Save and restore of PCI BARs

Re: [PATCH] powerpc export rtas_set_slot_reset()

[Brian King]

[-- Attachment #1: Type: text/plain, Size: 356 bytes --]

Linas Vepstas wrote:
> Hi Paul,
> A patch that provides an export for a bug being worked on the
> IPR evice driver.

This is not the API that I tested with... Here is the patch I
was using in my test. This is not ready to apply as we are
still working issues with various hardware...

Brian


-- 
Brian King
eServer Storage I/O
IBM Linux Technology Center

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: powerpc_slot_reset_api.patch --]
[-- Type: text/x-patch; name="powerpc_slot_reset_api.patch", Size: 2627 bytes --]


The following patch adds a generic API to assert and deassert
PCI reset to a device on a pSeries machine. This is needed to
solve an issue with a new ipr PCI-E adapter which causes EEH
errors when running BIST. The only way to reset this adapter
without causing an EEH error is to use PCI reset.

Signed-off-by: Brian King <brking@us.ibm.com>
---

 linux-2.6-bjking1/arch/powerpc/platforms/pseries/eeh.c |   42 +++++++++++++++++
 linux-2.6-bjking1/include/asm-powerpc/ppc-pci.h        |    3 +
 2 files changed, 45 insertions(+)

diff -puN arch/powerpc/platforms/pseries/eeh.c~powerpc_slot_reset_api arch/powerpc/platforms/pseries/eeh.c
--- linux-2.6/arch/powerpc/platforms/pseries/eeh.c~powerpc_slot_reset_api	2006-12-18 15:58:56.000000000 -0600
+++ linux-2.6-bjking1/arch/powerpc/platforms/pseries/eeh.c	2006-12-18 15:58:57.000000000 -0600
@@ -591,6 +591,48 @@ static void __rtas_set_slot_reset(struct
 	msleep (PCI_BUS_SETTLE_TIME_MSEC);
 }
 
+/**
+ * pci_set_slot_reset - Assert PCI reset to the PCI slot
+ * @dev:	pci device struct
+ *
+ * After asserting PCI reset, the caller should wait for
+ * 100 milliseconds or longer.
+ *
+ * Return value:
+ * 	0 if success
+ **/
+int pci_set_slot_reset(struct pci_dev *dev)
+{
+	struct device_node *dn = pci_device_to_OF_node(dev);
+	struct pci_dn *pdn = PCI_DN(dn);
+
+	rtas_pci_slot_reset(pdn, 1);
+	return 0;
+}
+EXPORT_SYMBOL_GPL(pci_set_slot_reset);
+
+/**
+ * pci_clear_slot_reset - Clear PCI reset to the PCI slot
+ * @dev:	pci device struct
+ *
+ * After clearing PCI reset, the caller should wait 1.8 seconds
+ * or longer for the bus to stabilize and the device to come
+ * ready.
+ *
+ * Return value:
+ * 	0 if success
+ **/
+int pci_clear_slot_reset(struct pci_dev *dev)
+{
+	struct device_node *dn = pci_device_to_OF_node(dev);
+	struct pci_dn *pdn = PCI_DN(dn);
+
+	eeh_clear_slot (pdn->node, EEH_MODE_ISOLATED);
+	rtas_pci_slot_reset (pdn, 0);
+	return 0;
+}
+EXPORT_SYMBOL_GPL(pci_clear_slot_reset);
+
 int rtas_set_slot_reset(struct pci_dn *pdn)
 {
 	int i, rc;
diff -puN include/asm-powerpc/ppc-pci.h~powerpc_slot_reset_api include/asm-powerpc/ppc-pci.h
--- linux-2.6/include/asm-powerpc/ppc-pci.h~powerpc_slot_reset_api	2006-12-18 15:58:56.000000000 -0600
+++ linux-2.6-bjking1/include/asm-powerpc/ppc-pci.h	2006-12-18 15:58:57.000000000 -0600
@@ -124,6 +124,9 @@ void eeh_clear_slot (struct device_node 
 /* Find the associated "Partiationable Endpoint" PE */
 struct device_node * find_device_pe(struct device_node *dn);
 
+int pci_set_slot_reset(struct pci_dev *dev);
+int pci_clear_slot_reset(struct pci_dev *dev);
+
 #endif
 
 #endif /* __KERNEL__ */
_

[PATCH] powerpc fixup error message

[Linas Vepstas]

Paul,
Please apply this somewhat trite patch; it did come up in conversations.

Heads up:
I'm debugging a more serious problem for power4, concerning
multi-function adapters & eeh recovery, and would like to get that 
patch in if/when I get it figured out and fixed.

--linas


Clarify error message re EEH permanent failure.

Signed-off-by: Linas Vepstas <linas@austin.ibm.com>

----
 arch/powerpc/platforms/pseries/eeh_driver.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Index: linux-2.6.19-git7/arch/powerpc/platforms/pseries/eeh_driver.c
===================================================================
--- linux-2.6.19-git7.orig/arch/powerpc/platforms/pseries/eeh_driver.c	2006-12-15 17:29:10.000000000 -0600
+++ linux-2.6.19-git7/arch/powerpc/platforms/pseries/eeh_driver.c	2006-12-15 17:35:27.000000000 -0600
@@ -446,7 +446,8 @@ excess_failures:
 	 */
 	printk(KERN_ERR
 	   "EEH: PCI device at location=%s driver=%s pci addr=%s \n"
-		"has failed %d times and has been permanently disabled. \n"
+		"has failed %d times in the last hour "
+		"and has been permanently disabled. \n"
 		"Please try reseating this device or replacing it.\n",
 		location, drv_str, pci_str, frozen_pdn->eeh_freeze_count);
 	goto perm_error;

[PATCH] powerpc initialize pci device channel state.

[Linas Vepstas]

Paul,
This patch is critical. Even if the last few looked to be 
of low importance, this one is not.

--linas

Initialize the pci device pci channel state. This is critical 
for having the pci_channel_offline() routine (in pci.h) to 
function correctly.

Signed-off-by: Linas Vepstas <linas@austin.ibm.com>

----
 arch/powerpc/kernel/pci_64.c |    1 +
 1 file changed, 1 insertion(+)

Index: linux-2.6.19-git7/arch/powerpc/kernel/pci_64.c
===================================================================
--- linux-2.6.19-git7.orig/arch/powerpc/kernel/pci_64.c	2006-12-19 13:50:53.000000000 -0600
+++ linux-2.6.19-git7/arch/powerpc/kernel/pci_64.c	2006-12-19 13:53:29.000000000 -0600
@@ -360,6 +360,7 @@ struct pci_dev *of_create_pci_dev(struct
 	DBG("    class: 0x%x\n", dev->class);
 
 	dev->current_state = 4;		/* unknown power state */
+	dev->error_state = pci_channel_io_normal;
 
 	if (!strcmp(type, "pci") || !strcmp(type, "pciex")) {
 		/* a PCI-PCI bridge */