2009-02-20 04:33:19     driver-user space communication

Document created by Aaronwu Employee on Aug 14, 2013
Version 1Show Document
  • View in full screen mode

2009-02-20 04:33:19     driver-user space communication

Izhar Eyal (ISRAEL)

Message: 69685   

 

Hi,

 

We are writing a kernel driver that receives microphone audio data.

 

This is the way we thought about do this:

 

Every time the user-space thread wants new mic data it will call read() and will be stuck there until data is available

 

Once the data is available PF5 pin is going from 0 to 1. we thought of making an interrupt for that GPIO and within the interrupt handler set up a DMA transfer from external memory to SDRAM. Once a DMA_complete interrupt is generated we will release the read() and the user-space thread can continue.

 

What do you think would be the most efficient way to write this, in terms of latency? is the above any good?

 

One more question:

 

We would like the user space to call read() with the address of the audiobuffer as input. the read will put user-space thread into sleep and inside the driver when interrupt is received the int_handler will read the data into the user-space buffer and wake up the user thread.

 

Question: is it possible to transfer only pointers somehow between driver and user-space instead of using copy_to_user() if we know that the buffer is only accessed from those two places and the user thread is put to sleep?

 

Obviously there should be an efficient way other than memcpy, right?

QuoteReplyEditDelete

 

 

2009-02-20 10:28:23     Re: driver-user space communication

Mike Frysinger (UNITED STATES)

Message: 69700   

 

if you want to write a codec driver, then the recommended method is to use the ALSA SOC framework rather than inventing your own

 

you could create a mmap() function to pass the pointer from the kernel to userspace, but that would only be 1 buffer, and it'd be up to you to figure out where in the stream the buffer is

 

while this is a no-mmu system and you could just trust the buffer coming to you from userspace, the copying is used to prevent bugs: if the driver is writing directly to a userspace buffer and that userspace app crashes, what then ?  what if a new process starts up and that address in memory is replaced by executable code ?

QuoteReplyEditDelete

 

 

2009-02-24 08:01:42     Re: driver-user space communication

Izhar Eyal (ISRAEL)

Message: 69809   

 

Mike,thank you for the reply,

 

regarding the mmap(), can you please explain more, what kind of mapping am I doing? mapping of the flip?

 

regarding what you've mentioned, I agree that passing a pointer can create bugs, definitely on mmu systems. but I'm sure that a simple method can be made in which to do the following:

 

1. allocate a buffer (memory section) in userspace

 

2. lock that buffer so that it is not touched by OS.

 

3. send the address of that buffer to the kernel driver

 

4. in the driver: translate the buffer address from virtual to physical (this will allow support for mmu based systems)

 

5. use that buffer securely.

 

Isn't there any mechanism in uCLinux to do this?

 

 

 

Also, I looked at bfin_sport.c, it seems that it is configuring the DMA address as "buf" which is the address given by the read() function from user-space. does the DMA do copy_to_user() internally?

QuoteReplyEditDelete

 

 

2009-02-24 08:34:04     Re: driver-user space communication

Phil Wilshire (UNITED STATES)

Message: 69810   

 

Hi Izhar,

 

I am jumping in on this discussion please forgive.

 

In the noMMU world we do not have the "problems" that exist in the MMU world.

 

We have no virtual memory mapping but we may have memory protection and cache buffer "problems".

 

What I tend to do for this sort of system is use the kernel to create the input buffer(s).

 

You can also choose to have them in a non cached memory region. (see the max_mem kernel option)

 

The mmap function will then simply give the user space process the address of the kernel memory area.

 

Each transfer can then be placed in the "next" input buffer.

 

You can use the read() call to wait for the next data transfer to take place and then simply return

 

the kernel buffer offset and transfer data size. This will avoid the copy to user for the transfer data.

 

You can also use unlocked_ioctl calls to wait for the transfer and get details of the data buffers.

 

If you want the driver to always monitor the PF irq and always capture the next buffer you will have to

 

provide some sort of circular buffer system in the kernel and make this work from interrupts without

 

having the user space issue a read first.

 

The user space application can then wait for the next buffer as already described.

 

So to answer your questions.

 

1/ noMMU mmap simply gives you a kernel buffer address.

 

2/ dma copy does not perform any copy_to_user, it simply copies data into SRDAM bypassing any cache.

 

NOTE that IF the SDRAM dma copy target is IN a cached section of SDRAM you should invalidate the

 

cached area AFTER the dma has completed. The bfin_sport driver is a little incorrect in that it

 

invalidates this area BEFORE the DMA has completed. You may never see the bug but it is there.

 

Hope this helps

 

regards

 

   Phil Wilshire

 

 

 

 

 

 

QuoteReplyEditDelete

 

 

2009-02-24 09:45:45     Re: driver-user space communication

Mike Frysinger (UNITED STATES)

Message: 69815   

 

you cannot lock a buffer from userspace.  the kernel started your userspace app and does all the resource management for it, so it knows fully well when your app dies, what resources exactly it can release.

 

mmap() is a specific file operation ... just grep the char driver subdir for exampless

QuoteReplyEditDelete

 

 

2009-02-24 10:35:35     Re: driver-user space communication

Izhar Eyal (ISRAEL)

Message: 69818   

 

Hi Phil, Mike,

 

Thank you both for the detailed reply, now I understand this a whole lot better

 

In our case we would like to do DMA (mostly from CPLD into SDRAM), and maybe from CPLD to L1 memory (when doing Speex audio compression to be more efficient).

 

Would it be wise to turn off caching for some memory regions? or would it be preferable to do cache invalidate?

 

as I understand caching on/off is configured in linux-2.6.x/include/asm-blackfin/cplbtab.h ,right?

QuoteReplyEditDelete

 

 

2009-02-24 10:51:50     Re: driver-user space communication

Mike Frysinger (UNITED STATES)

Message: 69822   

 

do not touch caching attributes in the kernel.  if you want coherent memory, then use the dma alloc coherent functions.  otherwise you get cached memory which means you must do proper cache management on the memory.

Attachments

    Outcomes