What to set uart_port->irq to for polled driver?

What to set uart_port->irq to for polled driver?

[Grant Edwards]

For a polled serial driver that doesn't use interrupts, to what should
the "irq" field in the uart_port structure be set?  Should it be 0?
Should it be the unused IRQ associated with the PCI card slot in which
the board is found?

-- 
Grant Edwards               grant.b.edwards        Yow! MERYL STREEP is my
                                  at               obstetrician!
                              gmail.com            

Re: What to set uart_port->irq to for polled driver?

[Peter Hurley]

On Wed, 2013-02-13 at 15:24 +0000, Grant Edwards wrote:
> For a polled serial driver that doesn't use interrupts, to what should
> the "irq" field in the uart_port structure be set?  Should it be 0?
> Should it be the unused IRQ associated with the PCI card slot in which
> the board is found?

Doesn't look supported, but adding the support doesn't look difficult.
At the very least, a patch is required so that on port shutdown, the
core doesn't synchronize_irq().

Regards,
Peter Hurley

Re: What to set uart_port->irq to for polled driver?

[Grant Edwards]

On 2013-02-28, Peter Hurley <peter@hurleysoftware.com> wrote:
> On Wed, 2013-02-13 at 15:24 +0000, Grant Edwards wrote:
>> For a polled serial driver that doesn't use interrupts, to what should
>> the "irq" field in the uart_port structure be set?  Should it be 0?
>> Should it be the unused IRQ associated with the PCI card slot in which
>> the board is found?
>
> Doesn't look supported, but adding the support doesn't look difficult.
> At the very least, a patch is required so that on port shutdown, the
> core doesn't synchronize_irq().

Does the call ty synchronize_irq() do any harm? AFAICT, it will just
cause a short delay if handling of that IRQ is in-progress.

I currently set the "irq" field to the IRQ number that would be used
by the board if I did choose to enable interrupts. That seems to work
fine (with rather limited testing).

-- 
Grant Edwards               grant.b.edwards        Yow! We just joined the
                                  at               civil hair patrol!
                              gmail.com            

Re: What to set uart_port->irq to for polled driver?

[Peter Hurley]

On Thu, 2013-02-28 at 18:43 +0000, Grant Edwards wrote:
> On 2013-02-28, Peter Hurley <peter@hurleysoftware.com> wrote:
> > On Wed, 2013-02-13 at 15:24 +0000, Grant Edwards wrote:
> >> For a polled serial driver that doesn't use interrupts, to what should
> >> the "irq" field in the uart_port structure be set?  Should it be 0?
> >> Should it be the unused IRQ associated with the PCI card slot in which
> >> the board is found?
> >
> > Doesn't look supported, but adding the support doesn't look difficult.
> > At the very least, a patch is required so that on port shutdown, the
> > core doesn't synchronize_irq().
> 
> Does the call ty synchronize_irq() do any harm? AFAICT, it will just
> cause a short delay if handling of that IRQ is in-progress.
> 
> I currently set the "irq" field to the IRQ number that would be used
> by the board if I did choose to enable interrupts. That seems to work
> fine (with rather limited testing).

AFAICT, it's probably ok; but it might not be. Certainly more robust to
just add a UPF_POLLING flag and skip the synchronize_irq().

Is this an in-tree driver?

Regards,
Peter Hurley

Re: What to set uart_port->irq to for polled driver?

[Grant Edwards]

On 2013-02-28, Peter Hurley <peter@hurleysoftware.com> wrote:
> On Thu, 2013-02-28 at 18:43 +0000, Grant Edwards wrote:
>> On 2013-02-28, Peter Hurley <peter@hurleysoftware.com> wrote:
>>> On Wed, 2013-02-13 at 15:24 +0000, Grant Edwards wrote:
>>>> For a polled serial driver that doesn't use interrupts, to what should
>>>> the "irq" field in the uart_port structure be set?  Should it be 0?
>>>> Should it be the unused IRQ associated with the PCI card slot in which
>>>> the board is found?
>>>
>>> Doesn't look supported, but adding the support doesn't look
>>> difficult. At the very least, a patch is required so that on port
>>> shutdown, the core doesn't synchronize_irq().
>> 
>> Does the call ty synchronize_irq() do any harm? AFAICT, it will just
>> cause a short delay if handling of that IRQ is in-progress.
>> 
>> I currently set the "irq" field to the IRQ number that would be used
>> by the board if I did choose to enable interrupts. That seems to work
>> fine (with rather limited testing).
>
> AFAICT, it's probably ok; but it might not be. Certainly more robust
> to just add a UPF_POLLING flag and skip the synchronize_irq().
>
> Is this an in-tree driver?

No.

One of my polled mode drivers is an enhanced version of the new rp2
serial driver.  It's currently in beta test.  I posted a snapshot of
that one to this list last week, but it hasn't been submitted as a git
patch yet.

The other is a rewrite of the rocket driver -- it's still under
development.  I'd be happy to submit it for inclusion in the tree when
it's done.

-- 
Grant Edwards               grant.b.edwards        Yow! Give them RADAR-GUIDED
                                  at               SKEE-BALL LANES and
                              gmail.com            VELVEETA BURRITOS!!