Re: [RFC PATCH 0/2] serial: 8250_dw: IO space + polling mode support

From: John Garry
Date: Mon Feb 26 2018 - 04:34:19 EST


On 23/02/2018 17:31, Andy Shevchenko wrote:
On Fri, 2018-02-23 at 11:02 +0000, John Garry wrote:
On 23/02/2018 10:30, Andy Shevchenko wrote:
On Fri, 2018-02-23 at 02:42 +0800, John Garry wrote:
There is a requirement

Where?


Hi Andy,

We require it for a development board for our hip06 platform.

Okay, and this particular platform uses Synopsys IP?

As I see this uart is really a virtual 8250, so HW details like apb clocks and the like are hidden, so may not be relevant.

However I will check with the BMC team to know the specific details.


for supporting an 8250-compatible UART with
the following profile/features:
- platform device
- polling mode (i.e. no interrupt support)
- ACPI FW

Elaborate this one, please.

So we need to define our own HID here, and cannot use PNP compatible
CID
(like PNP0501) as we cannot use the 8250 PNP driver.

Why not? What are the impediments?


To support the host controller for this device, we will create an MFD, i.e. platform device, per slave device.

This is related to the Hisi LPC ACPI support, where we would create
an
MFD (i.e. platform device) for the UART.

Why you can't do properly in ACPI?

- IO port iotype
- 16550-compatible

For OF, we have 8250_of.c, and for PNP device we have 8250_pnp.c
drivers. However there does not seem to any driver satisfying
the above requirements. So this RFC is to find opinion on
modifying the Synopsys DW 8250_dw.c driver to support these
generic features.

Synopsys 8250 is a particular case of platform drivers. It doesn't
satisfy "8250-compatible UART" requirement.

Right, but I wanted to try to use the generic parts of the driver to
support this UART to save writing yet another driver.

It's still odd. Why this one, why not 8250_foo_bar to touch instead?


Agreed, it's odd. I choose as 8250_dw.c as it has ACPI support already. And I recognise the hw from popularity. No stronger reasons than that.

Thanks,
John