>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
_______________________________________________
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
