Re: commproc.c

[Dan Malek <dan@netx4.com>]

Steve Calfee wrote:

> I have been working on doing a 823 USB driver.


I find it interesting there is a sudden interest in the 8xx USB
interface.......

I recently hired someone to do this work for a customer.  We have
slave working fine, and host mostly works (some hubs give us fits).
The goal is an isochronous connection for some device to stream
data over a variety of communication links (it's an 850).

We still have a little distance to cover.  If someone needs this
for a product and wants to invest in speeding up the develpment,
let me know.  Once it is more useful I suppose it will find its
way into the source tree.

> m8xx_cpm_dpalloc(uint size)

> This is a primitive routine to allocate CPM memory. It allocates size bytes
> of CPM memory. Even a good citizen that lives by the CPM imposed
> constraints of alignment


I had some pretty bad hacks for ATM interfaces due to its alignment
restrictions, and have since added a second parameter to define alignment.
I have played with masks and byte counts, one will win.  This will
be in an upcoming patch.


> .... We also need a m8xx_cpm_free() function to give back CPM
> memory when we are done.


For lack of a better thought, I have resurrected the old *NIX resource
map allocator.  Seems to work.



> .... I agree that it is a rare use,

It's not only rare, but I don't see any use for it.


> .... but if I want to
> backtrace the interrupted stack from my interrupt routine for profiling...


You have to explain this one to me.  I don't understand how passing
the register set pointer has any effect on this operation.

Show me you need it and we can add it as a parameter.  There aren't
that many places to change the code.  I just didn't need it, and due
to your rant about interrupt overhead why add something not needed?


	-- Dan

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