Hi,

I would like to write a Linux kernel device driver that uses a serial port to talk to a speech codec chip with serial interface.
I do not want to implement a device driver in userland since I consider it to be more clean and flexible to have the driver in kernel space.
So far I found out that there seem to be two possibilities to talk to a device over serial port from kernel space:

One is to write a "line discipline" driver similar to the SLIP or PPP drivers.
The catch is that usually such drivers do not create a separate (i.e. character-) device which I would like to have for my speech codec.
Instead, in userland code the serial device (i.e. /dev/ttySn) needs to be opened and a special IOCTL needs to be issued, so that the default N_TTY terminal line discipline is changed to my own line discipline.
Among the source code for the SLIP and PPP drivers, I also found the article at http://www.linux-mag.com/id/1891 useful (login can be found on http://www.bugmenot.com).

The other possibility is to use the serio abstraction layer from the input layer which usually creates a separate character device on top of an existing serial device (i.e. /dev/ttySn).
While a speech codec is definitely not an input device, it seems to be an easy way for writing a serial speech codec driver.
So far I did not find any documentation on how to use serio, although the code at linux/drivers/input/serio seems useful.

I'm not sure if other suitable solutions exist as well, but if you know one, please tell me ;)

• What do you think is the best choice for my application ?
  
• So far I think using serio would be the better choice since it seems to be easy and small, right ?
  
• Is using serio for a non-input device that bad ? What would be the consequences ?
  
• What other options are there to write a kernel device driver that talks over a serial line ?

Update:

Another possibility seems to be to write a tty driver as described rather extensively in Oreilly's Linux Driver Development 3rd edition, chapter 18 book.
So far I have not read through it, but it seems like a tty driver directly accesses a serial port.
This is also visible on this site: http://www.linux.it/~rubini/docs/serial/serial.html
Maybe writing a tty driver would be the proper way ?
On the one side it is responsible for the creation of the character device and on the other side it is not tied to an improper layer (like it is the case with serio and the input layer).

cheers,
knosses

Writing a tty driver is what you do if you want to implement a
tty device -- a driver that creates a /dev/ttyXXX device that
implements the normal serial-port functionality. Is that what
you want?

You haven't described what sort of a "device" you want. What
is it's API going to be? Do you want a character device? An
audio device for use by ALSA? A block device?

[Since your problem is a general linux question and has nothing
in particular to do with Atmel parts, this probably isn't the
best place to be asking the question.]

Hi,



No, this is not what I want.
I want to create a device driver for the speech codec.
And since the speech codec is attached to the controller over a serial port, my device driver needs to be able to send and receive data over the serial port.



I would like to create a character device.
If one reads from the character device, the compressed speech samples (if there are any) should come out of the driver.
On the other side one should be able to write compressed speech samples to the character device.
For speech codec configuration I would like to use ioctls (e.g. to set up the speech codec bit rate).

The other end of the speech codec is a PCM interface where uncompressed PCM speech samples will go in and out.
These PCM samples will be transfered over a high speed SPI bus.
From a driver perspective this will be done in a separate ALSA driver which should not be part of the UART related discussion here.
The ALSA driver is used to create a "virtual" soundcard like interface with an audio source and sink.

To get the picture one needs to consider both interfaces (SPI for PCM and UART for compressed speech data and control):
If PCM speech samples are written to the speech codec by means of the ALSA driver, the chip will compress those speech samples.
The compressed speech packets will then appear on the serial port where they can be read by the speech codec character device driver.
Consecutively, a userland application will receive the compressed speech samples by reading from the mentioned character device.

The other way works vice versa: A userland application writes compressed speech samples to the speech codec character device.
The character device driver will transfer the compressed speech samples to the chip which in turn will decompress them.
Finally the decompressed speech samples will be available on the ALSA device.




I already posted to the linux-embedded mailing list, but so far I did not receive a lot of answers.
Maybe I should post to the high volume linux kernel mailing list as well ?

Where would be the best place for these kind of questions ?

cheers,
knossos

Hello, I have the same problem You mentioned. I have custom device attached to UART and would like to implement own driver. I would like to implement 'line discipline' (to send and receive complete packets from device and send them to userspace without fragmentation) and also would like to have it's own character device in /dev/mydev so when someone opens that device /dev/ttyS0 gets disconnected from UART and my driver interacts with it using my line discipline. Also there are other lines connected to the device (reset etc. so I would like to control them using gpio).

The other question is, I would like to use USART in synchronous mode, but haven't found any support for it in linux. Would it be possible to change the driver, add custom ioctl so it can change to synchronous mode and use this only from my custom device driver?

Any advice would be appreciated, e.g. Your solution to the codec problem. Thank You very much

karel

Hi there

Maybe I'm missing something, but I see no reason why there has to be a "device driver" for the "codec". Why not use the existing tty device driver for the USART and the raw mode of the existing line discipline? Implement the "codec" as userspace routines. Document the API and convert the routines to a library. There's absolutely no need to touch the kernel since your "custom device" is off board and is (remotely) attached through the USART. The devices that are onboard that you want to use already have Linux device drivers. The resource that the kernel can control is the onboard USART, not the offboard "custom device" which could be disconnected or attached to another port.

Regards

Hi blue_z,

there is no codec (it was mentioned from previous post). My device is wireless communication device (ieee 802.15.4) and I would like to create driver which would abstract peculiarities of this device from user space application (gateway to internet, probably implemented in java) as this is only prototype and things might change (device will be connected using SPI on custom board etc.) so I would like to have one and the same /dev/mydev0 no matter what is under and user space application will not know about.

if it sounds unreasonable please correct me.

other thing is I (might) need to interact wit the device using gpio and don't want to do that from userspace (different CPU, different mapping etc., just change the driver and it works) and I probably want to change the usart low level driver to synchromode.

please if You know some useful (and simple enough) example of implementation of custom line discipline and tty driver let me know.. I'm going through the sources of slip and ircomm but I feel a little bit lost right now.

regards

k.

Hi there

> there is no codec (it was mentioned from previous post)

Sorry, my bad; I was misled by the "same problem".

> My device is wireless communication device (ieee 802.15.4)

I have developed an application that uses a vendor's 802.15.4 API in userspace. The radio module is attached to one of the at91sam's USARTs. No kernel changes were made for this device other than a hack for generating a nonstandard baud rate.

> device will be connected using SPI

Reads like the surface mount version of the XBee module.

For an SPI connection, then yes, you would have to write a new device driver. But if I was doing the development, then this char driver would just emulate a tty so that existing kernel interfaces could be reused. Any GPIO pins used to connect to XBee I/O (e.g. A/D conversion) would all be handled by a separate driver (that could be shared with the USART version).

For an example of userspace versus kernel space, consider the development of the Reliable Datagram Sockets, RDS. Originally this extension protocol to UDP was all in userspace. The functionality was moved to kernel space to improve robustness under heavy loads. I doubt that the 802.15.4 device will ever stress a system as much as an Ethernet device can. So you would have to come up with another rationale to prefer kernel space over userspace.

There's also some business and GPL considerations. Doesn't seem like you are doing development in a clean room: you've been studying the device drivers and line discipline source code. Any kernel code you consequently develop would probably fall under the GPL.

One tricky problem of doing interfaces in userspace is designing and implementing the processing layers, code structure and modularity. There is some extra work involved to maintain data encapsulation and interface integrity. The flexibility and convenience of userspace cuts both ways.

Regards