Re: hdsp on big-endian

Re: hdsp on big-endian

[Takashi Iwai]

Hi Paul,

i converted b_swap's to cpu_to_xxx and xxx_to_cpu macros, and during
that, found that the following part may not work correctly on BE.

static inline unsigned long long hdsp_read64 (hdsp_t *hdsp, int reg)
{
	unsigned long long val;
	val = hdsp_read(hdsp, reg);
	val = (val<<32)|hdsp_read(hdsp, reg + 4);

	return le64_to_cpu(val);
}

since hdsp_read returns the already converted 32bit word, the
resultant 64bit word will be flipped again badly.
i think we don't need here any endian conversion here.
could you confirm this?


ciao,

Takashi

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

Re: Re: hdsp on big-endian

[Paul Davis]

>Hi Paul,
>
>i converted b_swap's to cpu_to_xxx and xxx_to_cpu macros, and during
>that, found that the following part may not work correctly on BE.
>
>static inline unsigned long long hdsp_read64 (hdsp_t *hdsp, int reg)
>{
>	unsigned long long val;
>	val = hdsp_read(hdsp, reg);
>	val = (val<<32)|hdsp_read(hdsp, reg + 4);
>
>	return le64_to_cpu(val);
>}
>
>since hdsp_read returns the already converted 32bit word, the
>resultant 64bit word will be flipped again badly.
>i think we don't need here any endian conversion here.
>could you confirm this?

thats correct. its not significant yet, because i am still not quite
sure "where" the RMS meters (the only 64 bit registers) actually live.

the one other area of this that i am not sure about is the area where
we write the firmware. perhaps someone can help me out, since
endianness always fries my mind. that firmware is
stored/declared/defined as a char array. its written as a series of 32
bit words. the char array was taken from the OS X driver (i.e. for a
big-endian system). The OS X driver explicitly did *not* byteswap the
data when it wrote it. I assumed, therefore, that I should byteswap it
on an LE system. That didn't work - I just went back to writing it
with swapping, and the firmware download worked. The question now
arises: what to do on a BE system? its probably just my lousy
programming skills in this area, but i would have thought that:

    char c[4] = { 0xfe, 0xed, 0xfa, 0xce };
    int  i  = *((int *) c);

would give different results on BE and LE systems ...

--p

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

Re: Re: hdsp on big-endian

[Takashi Iwai]

At Tue, 21 May 2002 13:22:39 -0400,
Paul Davis wrote:
> 
> >Hi Paul,
> >
> >i converted b_swap's to cpu_to_xxx and xxx_to_cpu macros, and during
> >that, found that the following part may not work correctly on BE.
> >
> >static inline unsigned long long hdsp_read64 (hdsp_t *hdsp, int reg)
> >{
> >	unsigned long long val;
> >	val = hdsp_read(hdsp, reg);
> >	val = (val<<32)|hdsp_read(hdsp, reg + 4);
> >
> >	return le64_to_cpu(val);
> >}
> >
> >since hdsp_read returns the already converted 32bit word, the
> >resultant 64bit word will be flipped again badly.
> >i think we don't need here any endian conversion here.
> >could you confirm this?
> 
> thats correct. its not significant yet, because i am still not quite
> sure "where" the RMS meters (the only 64 bit registers) actually live.
> 
> the one other area of this that i am not sure about is the area where
> we write the firmware. perhaps someone can help me out, since
> endianness always fries my mind. that firmware is
> stored/declared/defined as a char array. its written as a series of 32
> bit words. the char array was taken from the OS X driver (i.e. for a
> big-endian system). The OS X driver explicitly did *not* byteswap the
> data when it wrote it. I assumed, therefore, that I should byteswap it
> on an LE system. That didn't work - I just went back to writing it
> with swapping, and the firmware download worked. The question now
> arises: what to do on a BE system? its probably just my lousy
> programming skills in this area, but i would have thought that:
> 
>     char c[4] = { 0xfe, 0xed, 0xfa, 0xce };
>     int  i  = *((int *) c);
> 
> would give different results on BE and LE systems ...

yes, that would make definitely difference between BE and LE.
(well, MacOS X is designed only for mac, not for pc :)

anyway...  after looking at the hdsp code again, i found that these
endian conversions are not necessary at all!
IIRC, readX/writeX already convert the endianess in itself.  thus, the
driver doesn't have to do anything in the access functions.
(i'm not 100% sure about this - please correct me if it's wrong.) 

of course, if the data is stored in bytes as above, then the bytes
must be swapped explicitly.  instead, we can use simply u32 arrays
for the firmware data itself, so that the values can be passed without
conversion.


Takashi

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

Re: Re: hdsp on big-endian

[Paul Davis]

>anyway...  after looking at the hdsp code again, i found that these
>endian conversions are not necessary at all!
>IIRC, readX/writeX already convert the endianess in itself.  thus, the

absolutely not. readl/writel on most architectures translate to:

	   *addr = val;

>driver doesn't have to do anything in the access functions.
>(i'm not 100% sure about this - please correct me if it's wrong.) 

you're wrong, at least partly :)

the problem is that the HDSP's registers are all little endian. only
audio data is byteswapped by the hardware (if requested). so a BE
system that wants to write 0xfeedface to the HDSP needs to byteswap it
before writing it. Consider:

    LE: wants to write 0xfeedface, memory pattern: [fe][ed][fa][ce]
	      delivers 0xfeedface when using writel
    BE: wants to write 0xfeedface, memory pattern: [ce][fa][ed][fe]
	      thus must swap the bytes before writing them

>of course, if the data is stored in bytes as above, then the bytes
>must be swapped explicitly.  instead, we can use simply u32 arrays
>for the firmware data itself, so that the values can be passed without
>conversion.

right, and therein lies my confusion. Here's what I thought:

PPC (BE) system:
    
    data stored in char array
    not swapped when written to hardware

    => data in char array is laid out for a BE system.

I think I know see the mistake. The point is that the data is in a
char array and therefore is already correctly ordered for any-endian
system. the only thing that would go wrong is if you checked the 32
bit value of any part of the firmware on a BE system: you'd see the
wrong value. But its laid out in the char array the same way it is in
the HDSP memory, and thus it doesn't need swapping on any
architecture, just delivered as-is.

--p




_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

Re: Re: hdsp on big-endian

[Takashi Iwai]

At Wed, 22 May 2002 08:25:23 -0400,
Paul Davis wrote:
> 
> >anyway...  after looking at the hdsp code again, i found that these
> >endian conversions are not necessary at all!
> >IIRC, readX/writeX already convert the endianess in itself.  thus, the
> 
> absolutely not. readl/writel on most architectures translate to:
> 
> 	   *addr = val;
> 

really?  for example, ppc uses in_le32() for readl(), which implies
byte swapping.


Takashi

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

Re: Re: hdsp on big-endian

[Paul Davis]

>> >anyway...  after looking at the hdsp code again, i found that these
>> >endian conversions are not necessary at all!
>> >IIRC, readX/writeX already convert the endianess in itself.  thus, the
>> 
>> absolutely not. readl/writel on most architectures translate to:
>> 
>> 	   *addr = val;
>> 
>
>really?  for example, ppc uses in_le32() for readl(), which implies
>byte swapping.

what does CONFIG_APUS do? thats the conditional on which in_le32 is
used or not. AFAIK, readl is not supposed to have
endian-characteristics, but if true, that would make the non-APUS ppc
version totally wrong.

on x86:

#define __io_virt(x) ((void *)(x))
#define readl(addr) (*(volatile unsigned int *) __io_virt(addr))
#define writel(b,addr) (*(volatile unsigned int *) __io_virt(addr) = (b))

--p

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

Re: Re: hdsp on big-endian

[Takashi Iwai]

At Wed, 22 May 2002 09:29:57 -0400,
Paul Davis wrote:
> 
> >> >anyway...  after looking at the hdsp code again, i found that these
> >> >endian conversions are not necessary at all!
> >> >IIRC, readX/writeX already convert the endianess in itself.  thus, the
> >> 
> >> absolutely not. readl/writel on most architectures translate to:
> >> 
> >> 	   *addr = val;
> >> 
> >
> >really?  for example, ppc uses in_le32() for readl(), which implies
> >byte swapping.
> 
> what does CONFIG_APUS do? thats the conditional on which in_le32 is
> used or not. AFAIK, readl is not supposed to have
> endian-characteristics, but if true, that would make the non-APUS ppc
> version totally wrong.

CONFIG_APUS is for amiga.  it's not set usually.
i have no idea about APUS, but it looks like the BE interface.

basically PCI bus is accessed as LE.  that's why in_le32 is used
there.  we can access to io without considration of endianess as long
as using readX/writeX.  (for direct access, you can use __raw_readX()
macros.)


> on x86:
> 
> #define __io_virt(x) ((void *)(x))
> #define readl(addr) (*(volatile unsigned int *) __io_virt(addr))
> #define writel(b,addr) (*(volatile unsigned int *) __io_virt(addr) = (b))

yep, on LE architectures, no conversion is necessary.


Takashi

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

Re: Re: hdsp on big-endian

[Paul Davis]

>basically PCI bus is accessed as LE.  that's why in_le32 is used

OK, well apparently on OS X, either RME didn't use standard macros for
this (most likely), or there are no standard macros for this.

>there.  we can access to io without considration of endianess as long
>as using readX/writeX.

Sounds like it, yes. Very nice.

--p

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

Re: Re: hdsp on big-endian

[Takashi Iwai]

At Wed, 22 May 2002 09:56:28 -0400,
Paul Davis wrote:
> 
> >basically PCI bus is accessed as LE.  that's why in_le32 is used
> 
> OK, well apparently on OS X, either RME didn't use standard macros for
> this (most likely), or there are no standard macros for this.
> 
> >there.  we can access to io without considration of endianess as long
> >as using readX/writeX.
> 
> Sounds like it, yes. Very nice.

ok, then we can erase stuffs cpu_to_xxx and vice versa.
but still one thing is not certain.  what does the following (in
snd_hdsp_initialize_firmware) set?

	#ifdef SNDRV_BIG_ENDIAN
		hdsp_write(hdsp, HDSP_jtagReg, HDSP_BIGENDIAN_MODE);
	#endif

does it switch the access to big-endian?  if yes, then we need
cpu_to_xxx things there (to revert the conversion in readX/writeX), or
use __raw_readX/writeX for access.

well, anyway a tester with ppc machine is wanted to confirm this...


Takashi

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

Re: Re: hdsp on big-endian

[Paul Davis]

>but still one thing is not certain.  what does the following (in
>snd_hdsp_initialize_firmware) set?
>
>	#ifdef SNDRV_BIG_ENDIAN
>		hdsp_write(hdsp, HDSP_jtagReg, HDSP_BIGENDIAN_MODE);
>	#endif
>
>does it switch the access to big-endian?  if yes, then we need
>cpu_to_xxx things there (to revert the conversion in readX/writeX), or
>use __raw_readX/writeX for access.

No, this switches *only* the byte order of audio data. The registers
are always little endian. 

--p

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

Re: Re: hdsp on big-endian

[Takashi Iwai]

At Thu, 23 May 2002 10:20:38 -0400,
Paul Davis wrote:
> 
> >but still one thing is not certain.  what does the following (in
> >snd_hdsp_initialize_firmware) set?
> >
> >	#ifdef SNDRV_BIG_ENDIAN
> >		hdsp_write(hdsp, HDSP_jtagReg, HDSP_BIGENDIAN_MODE);
> >	#endif
> >
> >does it switch the access to big-endian?  if yes, then we need
> >cpu_to_xxx things there (to revert the conversion in readX/writeX), or
> >use __raw_readX/writeX for access.
> 
> No, this switches *only* the byte order of audio data. The registers
> are always little endian. 

ok.  now i removed all cpu_to_xxx and xxx_to_cpu from hdsp.c.
the firmware data is reformatted using u32 arrays, in order to avoid
endian conversion on BE machines.  (remember that writel itsels does
conversion on ppc.)
also, converting from char * to int * might be invalid on some
architectures due to alignment problem...

anyway this should work on i386 well.  please revert cvs version if
you have any problems.


Takashi

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm