[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: serial based driver

On Wed, 6 Mar 2002, John Bindby wrote:
> As I see it I have three major possibilities, with different advantages:
> 1) Completely new kernel driver using a new character device like 
> /dev/protocol.
> 2) Modify the current serial driver with extra functionality, somewhat like 
> the RS485 modification.
> 3) Write another layer above the serial driver.

If you don't need the tty functionality and need good control of latencies, 
alternative 1 is simple. Beware of pitfalls regarding your protocol though, 
things we've already solved in the tty serial driver but you might run into, 
like you want fast turnaround on small commands that are too small to 
trigger a DMA flush by themselves.. stuff like that.

For bulk throughput there's no problem doing your own driver, or if you have 
the energy to add flushing by timers to your own driver if you have a 
latency problem for small datachunks.

> The third alternative is by far the most flexible and easiest way of doing 
> things, but concerning control and optimization it's pretty bad.

Drawbacks are mostly that you need to battle the tty API to know what is 
happening. For normal serial-port speeds, optimization should not really be 
an issue here though.

> Im going for the first option, but feels uncertain about a couple of things:
> * Enable / disable the serial driver for the port I'm going to use ? (Some 
> registers will probably have to be initilized)

See in arch/cris/kernel/head.S, the various CONFIG_ options are used there 
to enable the desired hardware in the Etrax chip. If you add your own 
CONFIG_MY_SERIAL instead of CONFIG_ETRAX_SERIAL_PORT0 (or whatever its 
called), you need to include your CONFIG option in head.S to make it enable 
the serial port anyway.

Otherwise you can do this in your driver startup, by using R_GEN_CONFIG and 
r_gen_config_shadow (see other drivers) but sometimes the hardware might 
behave badly when changing it when it's in use. 

> * What about IRQ and address area of the specific UARTS ?

Nothing about it. Just request the appropriate DMA IRQ and use the 
associated DMA channels for the serial port. 

> Pizza ? ;)

I'm in