Driver for SPI-based 8250 serial port
[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
Signature · 6 lines
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
Quoted 2 lines
- 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.
Quoted 2 lines
- Should I add a
UPIO_SPIto the global I/O types, or should I override the serial_in/serial_out functions in structplat_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.
Quoted 2 lines
- 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.
Quoted 2 lines
- I guess it doesn't make sense to try
autoconfig_irqfor 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.
Quoted 4 lines
- 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.
Quoted 1 line
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
Quoted 5 lines · Alan Cox
Quoted 2 lines
Quoted 2 lines
- Should I add a
UPIO_SPIto the global I/O types, or should I override the serial_in/serial_out functions in structplat_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
Signature · 6 lines
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