"lseek/write char driver" versus "usermode iomem access"

"lseek/write char driver" versus "usermode iomem access"

[Josef Angermeier]

Hello,

besides adapting linux to my custom board, i now have to write a driver 
for a special device. This device mainly consists of an up to 512 bytes 
big IO memory. Because performance matters alot, i wonder if i shall 
write a simple char driver offering a write/lseek-interface to access 
this memory or if i shall do something new to me, mapping the IO-memory 
to the userspace, so that the user-program can directly access the 
device memory. Can anyone tell me how performance probably differs 
between those two design.

Thanks, you probably save me alot of time to tryout!

Josef

Re: "lseek/write char driver" versus "usermode iomem access"

[David Hawkins]

> besides adapting linux to my custom board, i now have to write a driver 
> for a special device. This device mainly consists of an up to 512 bytes 
> big IO memory. Because performance matters alot, i wonder if i shall 
> write a simple char driver offering a write/lseek-interface to access 
> this memory or if i shall do something new to me, mapping the IO-memory 
> to the userspace, so that the user-program can directly access the 
> device memory. Can anyone tell me how performance probably differs 
> between those two design.
> 
> Thanks, you probably save me alot of time to tryout!

Hi Josef,

Here's a couple of comments that may help:

lseek()/read()/write():

   - read and write need to use copy_to_user and copy_from_user
     commands to copy bytes from the registers into the user-space
     buffer.

mmap()

   - maps pages directly, so avoids the overhead of the copy_xx_user
     calls.

So, if you have a set of control *registers* that you want to
manipulate, then mmap would be recommended.

However, this 512-bytes of memory is just that, *memory*, and the
requirement is to move it off the device as fast as possible,
then you probably want to create a device that has a linked
list of 512-byte buffers internally, and use a DMA channel
to move data from the device into the buffer. Then the
'read' function of the driver would consume the contents of
the buffer.

So, as always, things are application dependent. If you
could describe things in more detail, I can help make
more suggestions and supply you with code.

Regards,
Dave