mbox series

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

Message ID 1519324923-196857-1-git-send-email-john.garry@huawei.com
Headers show
Series serial: 8250_dw: IO space + polling mode support | expand

Message

John Garry Feb. 22, 2018, 6:42 p.m. UTC 
There is a requirement for supporting an 8250-compatible UART with
the following profile/features:
- platform device
- polling mode (i.e. no interrupt support)
- ACPI FW
- 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.

With patch 2/2, we're relaxing the interrupt support requirement.
As I mentioned in the commit log, the 8250_of.c driver seems to
ignore the dt bindings, and I do the same.

John Garry (2):
  serial: 8250_dw: add IO space support
  serial: 8250_dw: support polling mode

 drivers/tty/serial/8250/8250_dw.c | 32 +++++++++++++++++++++-----------
 1 file changed, 21 insertions(+), 11 deletions(-)

-- 
1.9.1

Comments

Andy Shevchenko Feb. 26, 2018, 9:53 a.m. UTC | #1 
On Mon, 2018-02-26 at 09:33 +0000, John Garry wrote:
> 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:


> > > 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.


Good to know.

> 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.


There is no answer here...

> > > 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?


No answer here either.

Sorry, but with this level of communication it's no go for the series.

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
John Garry Feb. 26, 2018, 3:07 p.m. UTC | #2 
On 26/02/2018 15:02, Andy Shevchenko wrote:
> On Mon, 2018-02-26 at 13:15 +0000, John Garry wrote:

>> On 26/02/2018 12:27, Andy Shevchenko wrote:

>>> On Mon, 2018-02-26 at 14:21 +0200, Andy Shevchenko wrote:

>>>> On Mon, 2018-02-26 at 11:56 +0000, John Garry wrote:

>>>

>>>

>>>>>    Device (LPC0.CON0) {

>>>>>      Name (_HID, "HISI1031")

>>>>>      // Name (_CID, "PNP0501") // cannot support PNP

>>>

>>>

>>> One more question. What is the problem with this CID? Do you have a

>>> race

>>> condition in enumeration?

>>>

>>

>> Hi Andy,

>>

>> Not sure if race condition exactly. I tried enabling this CID and a

>> pnp

>> device is created in pnpacpi_add_device_handler(), while we have

>> already

>> marked the corresponding acpi_device to skip enumeration in ACPI scan

>> handler (by flagging it as a serial bus slave).

>

> Is that code already in upstream?


No, not yet.

>

> If no, please, Cc next version to me and possible Mika.


Of course. I should be sending it later today.

>

All the best,
John