linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
* SPI driver for m8xx
@ 2002-03-12  4:03 Jeremy Rosen
  2002-03-12  9:28 ` Dan Malek
  0 siblings, 1 reply; 3+ messages in thread
From: Jeremy Rosen @ 2002-03-12  4:03 UTC (permalink / raw)
  To: linuxppc-embedded


Hello everybody

a quick question while the subject of SPI driver is in the air

I am trying to reimplement the driver for the SPI based on the driver
from David Boppuri and Prashant Patel,
and their is a thing I don't understand...

for the TX and RX buffer, they use memory they get for
m8xx_cpm_hostalloc... why ?
Does it have something to do with the MMU ?
I would like to avoid doing that, is their a way to use normal ( kernel
space) memory ?

Thanks

Jeremy

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: SPI driver for m8xx
  2002-03-12  4:03 SPI driver for m8xx Jeremy Rosen
@ 2002-03-12  9:28 ` Dan Malek
  0 siblings, 0 replies; 3+ messages in thread
From: Dan Malek @ 2002-03-12  9:28 UTC (permalink / raw)
  To: Jeremy Rosen; +Cc: linuxppc-embedded


Jeremy Rosen wrote:

> for the TX and RX buffer, they use memory they get for
> m8xx_cpm_hostalloc... why ?

It's convenient for small, uncached buffer space.  Don't be allocating
large (more than 32-64 bytes) out of this space, as there is only a
page or two shared among all CPM devices.  This is normally used for
things like SCC/SMC UART "FIFOs".

> Does it have something to do with the MMU ?

No, but with caches.

> I would like to avoid doing that, is their a way to use normal ( kernel
> space) memory ?

An alternate and proper approach is to use consistent_alloc().  This will
allocate page size memory, aligned on page boundaries, with cache disabled.
You must use the virtual/physical addresses returned from this function
and keep track of them in the driver.  The virt_to_* or __va/__pa() macros
won't work.

A third approach is to allocate kernel memory either with kmalloc() or
getpages().  This is not cache coherent with CPM DMA, so you need to
call the cache flush/invalidate functions to manage this space.

All of these have advantages and disadvantages you need to trade off in
your design.


	-- Dan


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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* RE: SPI driver for m8xx
@ 2002-03-12 15:54 Navin Boppuri
  0 siblings, 0 replies; 3+ messages in thread
From: Navin Boppuri @ 2002-03-12 15:54 UTC (permalink / raw)
  To: Jeremy Rosen, linuxppc-embedded


Hello Jeremy,

The crappy driver you have is something I whipped up a long time back. It is a skeleton driver which does SPI transfer successfully. I dont have any includes and all the defines are in numbers, which can be a pain to understand. I hope to clean up all the crap and put out a clean driver soon.

About the m8xx_cpm_hostalloc, I have no clue why I used it either. I lifted it for an old i2c driver by Dan. I am looking at the routine in an old commproc.c file and see some comments on the top. It looks like one page of buffer is reserved for things like UART fifo's etc. I dont think you really need to use it.

I'll put the driver in this mailing list once I have it all ready and clean.

Navin.

-----Original Message-----
From: Jeremy Rosen [mailto:Jeremy.Rosen@au.thalesgroup.com]
Sent: Monday, March 11, 2002 10:03 PM
To: linuxppc-embedded@lists.linuxppc.org
Subject: SPI driver for m8xx



Hello everybody

a quick question while the subject of SPI driver is in the air

I am trying to reimplement the driver for the SPI based on the driver
from David Boppuri and Prashant Patel,
and their is a thing I don't understand...

for the TX and RX buffer, they use memory they get for
m8xx_cpm_hostalloc... why ?
Does it have something to do with the MMU ?
I would like to avoid doing that, is their a way to use normal ( kernel
space) memory ?

Thanks

Jeremy


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

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2002-03-12 15:54 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-03-12  4:03 SPI driver for m8xx Jeremy Rosen
2002-03-12  9:28 ` Dan Malek
  -- strict thread matches above, loose matches on Subject: below --
2002-03-12 15:54 Navin Boppuri

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).