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