[U-Boot] [PATCH 14/15] RFC: x86: minnowmax: Add interrupt routing setup

[Bin Meng]

Hi Simon,

On Wed, Jul 29, 2015 at 8:48 AM, Simon Glass <sjg at chromium.org> wrote:
> Hi Bin,
>
> On 28 July 2015 at 18:46, Bin Meng <bmeng.cn at gmail.com> wrote:
>> Hi Simon,
>>
>> On Wed, Jul 29, 2015 at 8:42 AM, Simon Glass <sjg at chromium.org> wrote:
>>> Hi Bin,
>>>
>>> On 28 July 2015 at 18:40, Bin Meng <bmeng.cn at gmail.com> wrote:
>>>> Hi Simon,
>>>>
>>>> On Tue, Jul 28, 2015 at 7:58 PM, Simon Glass <sjg at chromium.org> wrote:
>>>>> Hi Bin,
>>>>>
>>>>> On 28 July 2015 at 01:50, Bin Meng <bmeng.cn at gmail.com> wrote:
>>>>>>
>>>>>> Hi Simon,
>>>>>>
>>>>>> On Tue, Jul 28, 2015 at 5:47 AM, Simon Glass <sjg at chromium.org> wrote:
>>>>>> > At present minnowmax does not correct set up PCI interrupts. This should be
>>>>>> > done in U-Boot so that devices work correctly in Linux.
>>>>>> >
>>>>>> > Note: This code needs to make use of the recent pirq_routing work. It does
>>>>>> > not seem to support all the required features, so this RFC will hopefully
>>>>>>
>>>>>> What features are missing in the existing PIRQ codes? When I did the
>>>>>> PIRQ support, I checked both TunnelCreek and BayTrail chipset
>>>>>> datasheet, and found the only difference seems to be the pci
>>>>>> configuration space vs. memory-mapped IBASE where the pci irq routing
>>>>>> registers reside.
>>>>>
>>>>> I see that each PCI device can be assigned four routes, making up a
>>>>> 16-bit register. But the code I see in pirq_assign_req() only assigns
>>>>> a single one, using a byte register.
>>>>>
>>>>
>>>> No, the pci irq routing register is still a 8-bit register on
>>>> BayTrail, where pirq_assign_irq() programs. The 16-bit register you
>>>> mentioned should be done in the platform codes. See
>>>> arch/x86/cpu/queensbay/tnc.c::cpu_irq_init(). By the way actually we
>>>> can leave those register programmed as they have the optimized default
>>>> values for all pci devices after power up, unless we intentionally
>>>> want to change them.
>>>
>>> What do you mean by 'leave those register programmed'?
>>>
>>
>> I mean their default value is normally OK, like INTA maps PIRQA, INTB
>> maps PIRQB, INTC maps PIRQC and INTD maps PIRQD.
>
> OK, so drop writing to the pirq registers?

You might need check if BayTrail FSP does any programming on these
registers. On Intel Crown Bay, I checked those values are the same
values as documented in the TunnelCreek datasheet.

> Should I program the 16-bit registers? If so, I will need to extend
> the device tree binding, won't I?

When I did the device tree binding changes, I did not convert these
registers to use device tree, because their offsets, not like the
routing registers as programmed in pirq_assign_irq(), is really
platform specific thing and does not seem to have a good formula to
calculate its offset (it varies from platform to platform). I
previously wanted to create some device bindings like below, but I
think they are really ugly so I did not go that way:

irq-router at 1f,0 {
    reg = <0x0000f800 0 0 0 0>;
    compatible = "intel,irq-router";
......
    dev0-intx-offset = <0x2040>;
    dev0-intx-value = <PIRQA PIRQB PIRQC PIRQD>;
    dev2-intx-offset = <0x2048>;
    dev2-intx-value = <PIRQA PIRQB PIRQC PIRQD>;
    dev4-intx-offset = <0x2060>;
    dev4-intx-value = <PIRQA PIRQB PIRQC PIRQD>;
    dev26-intx-offset = <0x20a0>;
    dev26-intx-value = <PIRQA PIRQB PIRQC PIRQD>;
    dev31-intx-offset = <0x20c0>;
    dev31-intx-value = <PIRQA PIRQB PIRQC PIRQD>;
......

Sorry I cannot find a better way to describe this in device tree, so I
chose to implement directly in the cpu_irq_init() to program these
registers.

>
> Sorry my understanding is limited on this - and I'd like to use your
> generic code if possible.
>

Yes, let's try to use the existing codes. If needed, we can have some
patches to support new platforms.

Regards,
Bin