es1371.o sound module on a IBM 405 walnut platform

es1371.o sound module on a IBM 405 walnut platform

[Ralph Blach]

I am trying to get an es1371. sound module working on an IBM405 walunt
developement kit.  8 bit sound works ok
but 16 bit sound sounds like noise.  Will this driver have to be made
endian aware?

Thanks in advance



--
Ralph "Chip" Blach
KF4WBK
Chapel Hill, North Carolina


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: es1371.o sound module on a IBM 405 walnut platform

[Dan Malek]

Ralph Blach wrote:

> ... Will this driver have to be made
> endian aware?

Probably.  I've had a couple of the ES boards running in Walnut, I
don't remember the details now.  The board was confiscated for
other more urgent work, so someday I hope to get back to it.


	-- Dan

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: es1371.o sound module on a IBM 405 walnut platform

[Ralph Blach]

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

Dan,

Well it does.  And I recomend a new kernel interface, and Dan, I KNOW
YOU WILL not like THE VERY IDEA,
by here it is.

I beleive that a kmalloc_little_endian and a kmalloc_nocache should be
added to the port.
The ability to allocate a little endian memory would by defaut handle
conversion in a seamless and quick manner.
copy_from_user and copy_to_use would then do the bit to little endian
conversions.

By the same token, an interface to allocate noncached memory would be
spiffy.  I would also assist in the porting of device drivers that need
lots of little non cached spaces like scsi and USB drivers.



Chip


The 405gp has the ability

Dan Malek wrote:
>
> Ralph Blach wrote:
>
> > ... Will this driver have to be made
> > endian aware?
>
> Probably.  I've had a couple of the ES boards running in Walnut, I
> don't remember the details now.  The board was confiscated for
> other more urgent work, so someday I hope to get back to it.
>
>         -- Dan
>

[-- Attachment #2: Card for Ralph Blach --]
[-- Type: text/x-vcard, Size: 247 bytes --]

begin:vcard
n:Blach;Ralph
tel;work:919-543-1207
x-mozilla-html:TRUE
url:www.ibm.com
org:IBM MicroElectronics
adr:;;3039 Cornwallis		;RTP;NC;27709;USA
version:2.1
email;internet:rcblach@raleigh.ibm.com
x-mozilla-cpt:;15936
fn:Ralph Blach
end:vcard

Re: es1371.o sound module on a IBM 405 walnut platform

[Dan Malek]

Ralph Blach wrote:

> Well it does.  And I recomend a new kernel interface, and Dan, I KNOW
> YOU WILL not like THE VERY IDEA,
> by here it is.

You are right, I won't :-).  Here is why.  First of all, all Linux
ports understand how to manage the little-endian PCI interface.  We
don't want help from hardware swapping bytes in the lanes because it
just complicates software with special case functions and actually
introduces more overhead instead of removing it like the design you
thought would work.  Second, I have worked with hardware like this
in the past, and have painfully learned you simply can't arbitrarily
swap the bytes in the lanes.  If you have data structures you are
trying to share, the data has to be swapped based upon the size of
the object.  The hardware has no clue what you are trying to access
and will screw it up.  Just believe me, I've been there.

> copy_from_user and copy_to_use would then do the bit to little endian
> conversions.

Nope, the sound drivers already know how to do this if necessary.

> By the same token, an interface to allocate noncached memory would be
> spiffy.

That's already been done for the 8xx and 4xx ports in the kernel
trees.


	-- Dan

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: es1371.o sound module on a IBM 405 walnut platform

[Ralph Blach]

Dan Malek wrote:

> Ralph Blach wrote:
>
> > Well it does.  And I recomend a new kernel interface, and Dan, I KNOW
> > YOU WILL not like THE VERY IDEA,
> > by here it is.
>
>
>
>
> > By the same token, an interface to allocate noncached memory would be
> > spiffy.
>
> That's already been done for the 8xx and 4xx ports in the kernel
> trees.
>
>         -- Dan

Yes it has, only for non cached pages.  But what propose is a new
interface like kmalloc_noncache, and kfree_noncache.

This would allow one to allocate noncached buffers for usb and SCSI work.


--
Ralph "Chip" Blach
KF4WBK
Chapel Hill, North Carolina


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: es1371.o sound module on a IBM 405 walnut platform

[Dan Malek]

Ralph Blach wrote:

> This would allow one to allocate noncached buffers for usb and SCSI work.

Ummmm....I added those at the request of the people doing the usb
work.  If they aren't correct or sufficient, the usb wouldn't be
working on the 4xx or 8xx processors.


	-- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/