[U-Boot] [PATCH v2] serial: ns16550: Add RX interrupt buffer support

Stefan Roese
2017-07-17T11:18:51Z

Hi Bin,

On 17.07.2017 11:43, Stefan Roese wrote:
> On 17.07.2017 11:26, Bin Meng wrote:
>
> <snip>
>
>>>>> + }
>>>>> +#endif
>>>>> +
>>>>> return 0;
>>>>> }
>>>>>
>>>>> @@ -459,6 +559,15 @@ int ns16550_serial_ofdata_to_platdata(struct
>>>>> udevice
>>>>> *dev)
>>>>> if (port_type == PORT_JZ4780)
>>>>> plat->fcr |= UART_FCR_UME;
>>>>>
>>>>> +#if CONFIG_IS_ENABLED(SERIAL_IRQ_BUFFER)
>>>>> + plat->irq = fdtdec_get_int(gd->fdt_blob, dev_of_offset(dev),
>>>>> + "interrupts", 0);
>>>>
>>>>
>>>> Should we handle NS16550 on the PCI bus? If not, better put a comment
>>>> here.
>>>
>>>
>>> Actually I'm also using this RX IRQ buffer for the HS-UART on BayTrail
>>> connected via PCI (pciuart0: uart at 1e,3). I've added the interrupt
>>> property to the DT for this to work for now. I'll check, if I can read
>>> the interrupt from the PCI config space instead.
>>>
>>
>> Yes, the interrupt line register is programmed with the value of its
>> interrupt vector in irq_router_probe(). But you should wait for the
>> IRQ device to be probed before NS16550.
>
> I'm currently working on this and this dependency with the PCI interrupt
> assignment is problematic. The serial driver is (intentionally) probed
> earlier and the PCI interrupts are still unassigned at that stage.
>
> I currently have no real good idea on how to solve this. We could
> add a new "probe_late() / probe_irqs_enabled()" DM function for such
> cases, but this seems overly complex and adds new bloat to the DM
> infrastructure.
>
> Do you have some other (simpler) ideas on how to solve this?

Another idea would be, to write the PCI interrupt vectors earlier
in the boot stage, before the serial driver is probed. The interrupts
don't need to be enabled for this.

What do you think of this idea?

Thanks,
Stefan