x86: Add new Intel LPSS Uart driver

[manu]

Summary

Intel LPSS (Low Power Sub System) is a generic IP that can contain
either an I2C, SPI or UART controller.
They all share some common registers to help with frequency, dma etc ...
Add support for the UART part.
The PCI IDS for the Apollo and Gemini Lake were previously added to the
uart_bus_pci driver but even if they are detected they cannot be used with
just this and needs more glue.

Fixes: eaf00819bc ("Add support for Gemini Lake LPSS UARTs.")
Fixes: 8f1562430f ("Add Apollo Lake SIO/LPSS UARTs PCI IDs")

Sponsored by: Beckhoff Automation GmbH & Co. KG

[manu]

So there is two things that I'd like to fix before commiting this :

• I would like dev/intel/lpss.c to be a driver and the uart_lpss a subclassed one but I don't know how to deal with the different softc (as a uart driver needs a uart softc as the first member of the softc and same thing with a subclassed driver).
• I can't seems to be able to have a getty running on those uart, not sure why but I can connect to some arm board correctly. Is there anything else that a uart driver needs so getty is happy ?

[manu]

Adding @kib as you commited the two commits that this "fixes".

[kib]

Does this diff miss some sys/modules/ updates?

[manu]

In D33033#746010, @kib wrote:

Does this diff miss some sys/modules/ updates?

Yeah I haven't done a module yet.

[val_packett.cool]

sys/dev/intel/lpss.h

36

Uh, this is only 0x200 on Sunrise Point (and some later ones too I think). See D29249 (yeah, would be nice to use this in there). It's 0x800 on Lynx Point, 0x400 on Braswell and Bay Trail.

[manu]

sys/dev/intel/lpss.h

36

Mhm, there might be something that I missed in the linux driver then, will have another look tomorrow.

[val_packett.cool]

sys/dev/intel/lpss.h

36

The linux driver structure is rather confusing. They don't have a proper centralized place for this, these base offsets are all over the place:

• SPI driver https://github.com/torvalds/linux/blob/ee1703cda8dc777e937dec172da55beaf1a74919/drivers/spi/spi-pxa2xx.c#L100-L170
• ACPI LPSS something ?? https://github.com/torvalds/linux/blob/ee1703cda8dc777e937dec172da55beaf1a74919/drivers/acpi/acpi_lpss.c#L240-L313
• this 8250 UART driver only has a BYT (Bay Trail) one ?? but it's 0x800 which contradicts what the above drivers say about BYT ?? https://github.com/torvalds/linux/blob/ee1703cda8dc777e937dec172da55beaf1a74919/drivers/tty/serial/8250/8250_lpss.c#L39

[manu]

sys/dev/intel/lpss.h

36

Yeah any mfd driver in linux is near to impossible to follow fully :)
But now I see what needs to be done here, thanks.

[manu]

sys/dev/intel/lpss.h

36

So I've look at most of the docs for the PCH and starting at Serie 100 (which goes with skylake) those registers are always at 0x200 (Named "Additional Registers" in the datasheet) and that's starting from this generation that the intel-lpss driver is used in Linux.
I don't plan to work on < skylake as I don't have hardware so intel lpss will also be for >= skylake for us.

[val_packett.cool]

sys/dev/intel/lpss.h

36

Broadwell/LynxPoint is the only device I have for testing the Apple SPI input, I need LPSS on Broadwell, I have it working in D29249

[jlduran]

I have been using a memory-mapped console (Apollo Lake E3950) by adding to /boot/loader.conf.d/console.conf:

hw.uart.console="mm:0xfea10000,rs:2"

Obviously, I prefer the direction this is heading to. I might be able to test on that platform.

[saper_saper.info]

I have tried to apply the new UART code to my device, which I think is Intel Skylake platform:

none1@pci0:0:30:0:	class=0x118000 rev=0x21 hdr=0x00 vendor=0x8086 device=0x9d27 subvendor=0x8086 subdevice=0x7270

but after adding new PCI IDs to this driver it unfortunately hangs on boot

sys/dev/uart/uart_dev_lpss_pci.c

203

In 2025, we should remove uart_devclass parameter removed in 9e4e7bcaef3fcaab66cdecd08b1664ac92cc9a6b

[seuros]

@manu thanks for the work here, do you plan to resume this driver effort ? I ran into the same hang on boot that @saper_saper.info reported, and on top of that I see a crash at runtime after a few minutes.

I have built a working driver against 16-CURRENT. the UART interface changes that Marcin commented about are necessary for it to work.

If you don’t have time or access to hardware to continue, I’m happy if we close this diff and reopen a fresh one with the updated code for current heads.

[saper_saper.info]

In D33033#1254865, @guest-seuros wrote:

I have built a working driver against 16-CURRENT. the UART interface changes that Marcin commented about are necessary for it to work.

You probably needed to remove the extra parameter to make it compile, but how did you manage to boot your system with it?

What are the PCI vendor/device IDs of your controller?