Driver for SPI-based 8250 serial port

Driver for SPI-based 8250 serial port

[Arnout Vandecappelle]

[Please CC me, I'm not on the list]

  Hi,

  I need a driver for the Exar's XR20M1280 SPI-based serial port.  It's a
16C950 compatible serial port, it just performs the register accesses over
an SPI (or I2C) bus rather than memory-mapped.

  As far as I can determine, no driver for such a device exists yet.  So I'll
develop one.

  A few questions before I start:

- I guess I should preferably write it as generically as possible, even though
I can test it on only one device?

- Should I add a UPIO_SPI to the global I/O types, or should I override the
serial_in/serial_out functions in struct plat_serial8250_port?

- I guess there should be a 8250_spi file that registers the platform
device?

- I guess it doesn't make sense to try autoconfig_irq for such a device?
The IRQ is typically a gpio which the platform code has to configure as an IRQ.

- I'm not sure how to set the uartclk. The XR20M1280's BRG is derived from a
24MHz clock, but other devices or other boards may have different values.
Should it be part of platform data?  Should I define a new platform data struct
for that?

  Any other suggestions are also welcome.

  Regards,
  Arnout

-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

Re: Driver for SPI-based 8250 serial port

[Alan Cox]

> - I guess I should preferably write it as generically as possible, even though
> I can test it on only one device?

There is a balance between making it generic and getting it done and
useful. I would say it is more important to make it possible for someone
else to make it also handle their hardware than attempt to guess what is
needed. Make it possible, but don't do the work.

> - Should I add a UPIO_SPI to the global I/O types, or should I override the
> serial_in/serial_out functions in struct plat_serial8250_port?

I am not sure you'll make the 8250 driver handle the device because I
suspect a lot of the serial_in/serial_out calls occur with interrupts
disabled on the assumption that they are basically atomic fast operations.

> - I guess there should be a 8250_spi file that registers the platform
> device?

Probably, but also allowing people to create those platform devices in
their architecture code or via firmware.

> - I guess it doesn't make sense to try autoconfig_irq for such a device?
> The IRQ is typically a gpio which the platform code has to configure as an IRQ.

Agreed. autoconfigure IRQ really only applies for PC ISA bus type
devices. Most sane architectures know the IRQ to use.

> - I'm not sure how to set the uartclk. The XR20M1280's BRG is derived from a
> 24MHz clock, but other devices or other boards may have different values.
> Should it be part of platform data?  Should I define a new platform data struct
> for that?

platform data would be my guess.

>   Any other suggestions are also welcome.

Take a look at the locking assumptions of 8250.c. If they make it hard to
do the spi driver that way then I would suggest doing a small, clean
platform driver specifically for 16C950 over SPI. Pass the device type
(even if only 950 is supported), baud rate in via the platform struct.
That way others can tackle extending it for different devices as they
need.

Architecturally I think that will be what is needed - you end up wanting
a threaded IRQ handler and other major design differences the moment your
register writes are asynchronous and slow. You may well find that the
uart layer isn't a help either and it's best to go straight from the
tty/tty_port helpers.

Alan

Re: Driver for SPI-based 8250 serial port

[Arnout Vandecappelle]

On 09/05/12 15:12, Alan Cox wrote:
>> >  - Should I add a UPIO_SPI to the global I/O types, or should I override the
>> >  serial_in/serial_out functions in struct plat_serial8250_port?
> I am not sure you'll make the 8250 driver handle the device because I
> suspect a lot of the serial_in/serial_out calls occur with interrupts
> disabled on the assumption that they are basically atomic fast operations.

  Argh, that's right.

  So it will be a completely new driver then.  Using the tty layer directly seems
to be a good suggestion: it looks like the uart layer (like the 8250 driver) is
carrying a lot of cruft for supporting all those quirks in the different devices.

  ifx6x60 looks like a good source of inspiration.


  Regards,
  Arnout
-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F