Using serial driver 16550A in poll mode without interrupt connected

Using serial driver 16550A in poll mode without interrupt connected

[Michal Simek]

Hi,

we have internal discussion around serial drivers and their usage without interrupts
in polling mode. It is on FPGA with Microblaze/PPC/ARM and
it is easy for us to have serial IP without IRQ connected to the interrupt controller.

Driver is probed with no IRQ (NO_IRQ = -1 on Microblaze)
83e00000.serial: ttyS0 at MMIO 0x83e01003 (irq = -1) is a 16550A

writing any data to ttyS0 return -1.
Is there any reason no to use driver in poll mode especially for user applications
not for consoles.

Is it possible to use serial driver without IRQ - or blocking IRQ, etc.?

Currently we care about uart16550 and uarlite.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian

Re: Using serial driver 16550A in poll mode without interrupt connected

[Alan Cox]

> Driver is probed with no IRQ (NO_IRQ = -1 on Microblaze)
> 83e00000.serial: ttyS0 at MMIO 0x83e01003 (irq = -1) is a 16550A

Zero means no IRQ. NO_IRQ is a legacy internal thing for the old IDE code
so not something other code should be using. Setting the IRQ to -1 is
bogus and will confuse the rest of the kernel.

> Is it possible to use serial driver without IRQ - or blocking IRQ, etc.?

Within limits - it kills your power management and data rates because of
the continual polling.

Alan

Re: Using serial driver 16550A in poll mode without interrupt connected

[Ted Ts'o]

On Wed, Oct 12, 2011 at 02:51:53PM +0100, Alan Cox wrote:
> > Driver is probed with no IRQ (NO_IRQ = -1 on Microblaze)
> > 83e00000.serial: ttyS0 at MMIO 0x83e01003 (irq = -1) is a 16550A
> 
> Zero means no IRQ. NO_IRQ is a legacy internal thing for the old IDE code
> so not something other code should be using. Setting the IRQ to -1 is
> bogus and will confuse the rest of the kernel.
> 
> > Is it possible to use serial driver without IRQ - or blocking IRQ, etc.?
> 
> Within limits - it kills your power management and data rates because of
> the continual polling.

It was something that I implemented years ago primarily for crappy
hardware that didn't get interrupts right.  It's not something which
where I would advise anyone to intentionally design hardware to use.

If you have really deep FIFO's (i.e., a kilobyte or more), and you're
primarily interested in throughput, not latency, and/or you are trying
to support tens or hundreds of serial ports for some kind of modem
pool, there is a place for a polled implementation.  See the Comtrol
Rockport for an example of hardware and with a linux driver that will
handle this.  It's basically a "NAPI for serial ports" sort of
approach to minimize the overhead of potentially hundreds of thousands
of interrupts per second if you are driving large numbers of ports
(and at that point, power management is the least of your concerns
:-).  But you need special hardware to do this, not a random 16550A
with a pathetically small 16 byte FIFO.

						- Ted

Re: Using serial driver 16550A in poll mode without interrupt connected

[Michal Simek]

Alan Cox wrote:
>> Driver is probed with no IRQ (NO_IRQ = -1 on Microblaze)
>> 83e00000.serial: ttyS0 at MMIO 0x83e01003 (irq = -1) is a 16550A
> 
> Zero means no IRQ. NO_IRQ is a legacy internal thing for the old IDE code
> so not something other code should be using. Setting the IRQ to -1 is
> bogus and will confuse the rest of the kernel.

It is on my list. There are still some archs (ARM, etc) which still use it.

> 
>> Is it possible to use serial driver without IRQ - or blocking IRQ, etc.?
> 
> Within limits - it kills your power management and data rates because of
> the continual polling.

Microblaze does nothing with power management and data rates is no problem -
it could exchange some data to check actual status or so.

We just need to make a decision about generating compatible properties for
serial IPs without IRQ. Our BSP which generate dts from Xilinx tools is able
to check if IRQ is connected and based on that do any action - show error/warning/ignore.

If compatible string is not in DTS driver for this IP is not probed.
If you are saying that Linux serial drivers are not prepared for polling because of any reason
we will handle that in BSP.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian

Re: Using serial driver 16550A in poll mode without interrupt connected

[Michal Simek]

Ted Ts'o wrote:
> On Wed, Oct 12, 2011 at 02:51:53PM +0100, Alan Cox wrote:
>>> Driver is probed with no IRQ (NO_IRQ = -1 on Microblaze)
>>> 83e00000.serial: ttyS0 at MMIO 0x83e01003 (irq = -1) is a 16550A
>> Zero means no IRQ. NO_IRQ is a legacy internal thing for the old IDE code
>> so not something other code should be using. Setting the IRQ to -1 is
>> bogus and will confuse the rest of the kernel.
>>
>>> Is it possible to use serial driver without IRQ - or blocking IRQ, etc.?
>> Within limits - it kills your power management and data rates because of
>> the continual polling.
> 
> It was something that I implemented years ago primarily for crappy
> hardware that didn't get interrupts right.  It's not something which
> where I would advise anyone to intentionally design hardware to use.

It shouldn't be crappy hardware in our case because in FPGA you can connect it yourself.
It is pretty easy to connect IRQ and choose interrupt number.

> 
> If you have really deep FIFO's (i.e., a kilobyte or more), and you're
> primarily interested in throughput, not latency, and/or you are trying
> to support tens or hundreds of serial ports for some kind of modem
> pool, there is a place for a polled implementation. 

I don't personally care about throughput or latency or even how deep FIFO is.
It could be several bytes - just send command and receive status or so.
Or if this need large fifo - you can just add it to your hw design.

For example our interrupt controller supports up to 32 interrupt lines.
If someone decides to use more that 32 serial IPs(include some lines for timer, etc)
we don't have support for IRQ cascades and for getting status over serial line will
be easier to use polling. As you write below there should be a lot of interrupts too.

See the Comtrol
> Rockport for an example of hardware and with a linux driver that will
> handle this.  It's basically a "NAPI for serial ports" sort of
> approach to minimize the overhead of potentially hundreds of thousands
> of interrupts per second if you are driving large numbers of ports
> (and at that point, power management is the least of your concerns
> :-).  But you need special hardware to do this, not a random 16550A
> with a pathetically small 16 byte FIFO.

Can you point me to that files? Is it in the mainline kernel?

Thanks,
Michal


-- 
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian