83xx immap_qe.h -> SIR type def error?

[Russell McGuire]

Kumar,

Yes in the main memeory map they are just listed as 1K RAM blocks.
However, in the UM Section 36.6.1 <pg 36-12 or pg 1728 in the PDF>. 

It gives the breakout for the RAM, which clearly indicates 16 bit fields.
<Here is a short clip from Figure 36-8>
 
Access: Read/Write
0 1 2 3 4 5 6 7 10 11 13 14 15
MCC SWTR SSEL 1 SSEL 2 SSEL 3 SSEL 4 SGS CSEL CNT BYT LST 
Figure 36-8. SI RAM Entry for UCC

Honest, mistake as if I were writing the header file I'd not have time to
ready all 2000+ pages of the UM. We find these only as somebody goes in an
tries to use them. 
And I am guessing not a lot of customers use the SI block.

-Russ
> -----Original Message-----
> From: Kumar Gala [mailto:galak at kernel.crashing.org]
> Sent: Friday, February 01, 2008 6:56 AM
> To: rmcguire at videopresence.com
> Cc: linuxppc-embedded at ozlabs.org
> Subject: Re: 83xx immap_qe.h -> SIR type def error?
> 
> 
> On Feb 1, 2008, at 5:47 AM, Russell McGuire wrote:
> 
> > All Freescale,
> >
> > Not sure if this is the place to post this, but I have run across
> > what I
> > consider to be a possible type error in the immap_qe.h file, for the
> > asm/powerpc branch.
> >
> > In the file immap_qe.h
> >
> > /* SI Routing Tables */
> > struct sir {
> > 	u8  tx[0x400];
> > 	u8  rx[0x400];
> > 	u8  res0[0x800];
> > }
> >
> > Shouldn't these types be defined as __be16 ?
> >
> > According to the Freescale manual this is a 16 bit field, not an 8-bit
> > field.
> >
> > Spent an hour trying to figure out why I couldn't fill this field
> > out with
> > upper 8 bits last night.
> >
> > Thoughts?
> 
> I'm guessing it was done this way since they are just looked as base
> offsets.  Where in the UM do you see anything about them being 16-bit
> quantities?  (I'm really know little about this).
> 
> - k