[U-Boot] [PATCH 1/4] x86: Refactor PIRQ routing support

Simon Glass sjg at chromium.org
Sat May 23 18:36:40 CEST 2015


Hi Bin,

On 23 May 2015 at 10:22, Bin Meng <bmeng.cn at gmail.com> wrote:
> Hi Simon,
>
> On Thu, May 21, 2015 at 1:45 AM, Simon Glass <sjg at chromium.org> wrote:
>> Hi Bin,
>>
>> On 20 May 2015 at 01:55, Bin Meng <bmeng.cn at gmail.com> wrote:
>>> PIRQ routing is pretty much common in Intel chipset. It has several
>>> PIRQ links (normally 8) and corresponding registers (either in PCI
>>> configuration space or memory-mapped IBASE) to configure the legacy
>>> 8259 IRQ vector mapping. Refactor current Queensbay PIRQ routing
>>> support using device tree and move it to a common place, so that we
>>> can easily add PIRQ routing support on a new platform.
>>>
>>> Signed-off-by: Bin Meng <bmeng.cn at gmail.com>
>>> ---
>>>
>>>  arch/x86/cpu/Makefile                            |   2 +-
>>>  arch/x86/cpu/irq.c                               | 221 +++++++++++++++++++++
>>>  arch/x86/cpu/queensbay/Makefile                  |   2 +-
>>>  arch/x86/cpu/queensbay/irq.c                     | 242 -----------------------
>>>  arch/x86/cpu/queensbay/tnc.c                     |  39 +++-
>>>  arch/x86/dts/crownbay.dts                        |  54 +++++
>>>  arch/x86/include/asm/arch-queensbay/irq.h        |  55 ------
>>>  arch/x86/include/asm/irq.h                       | 105 ++++++++++
>>>  include/dt-bindings/interrupt-router/intel-irq.h |  29 +++
>>>  include/fdtdec.h                                 |   1 +
>>>  lib/fdtdec.c                                     |   1 +
>>>  11 files changed, 451 insertions(+), 300 deletions(-)
>>>  create mode 100644 arch/x86/cpu/irq.c
>>>  delete mode 100644 arch/x86/cpu/queensbay/irq.c
>>>  delete mode 100644 arch/x86/include/asm/arch-queensbay/irq.h
>>>  create mode 100644 arch/x86/include/asm/irq.h
>>>  create mode 100644 include/dt-bindings/interrupt-router/intel-irq.h
>>
>> Great to see this! Nit below.
>>
>> [snip]
>>
>>> diff --git a/arch/x86/include/asm/irq.h b/arch/x86/include/asm/irq.h
>>> new file mode 100644
>>> index 0000000..a7ad462
>>> --- /dev/null
>>> +++ b/arch/x86/include/asm/irq.h
>>> @@ -0,0 +1,105 @@
>>> +/*
>>> + * Copyright (C) 2015, Bin Meng <bmeng.cn at gmail.com>
>>> + *
>>> + * SPDX-License-Identifier:    GPL-2.0+
>>> + */
>>> +
>>> +#ifndef _ARCH_IRQ_H_
>>> +#define _ARCH_IRQ_H_
>>> +
>>> +enum pci_int_pin {
>>> +       INTX,
>>> +       INTA,
>>> +       INTB,
>>> +       INTC,
>>> +       INTD
>>> +};
>>> +
>>> +enum pirq_pin {
>>> +       PIRQA,
>>> +       PIRQB,
>>> +       PIRQC,
>>> +       PIRQD,
>>> +       PIRQE,
>>> +       PIRQF,
>>> +       PIRQG,
>>> +       PIRQH
>>> +};
>>> +
>>> +/**
>>> + * Intel interrupt router configuration mechanism
>>> + *
>>> + * There are two known ways of Intel interrupt router configuration mechanism
>>> + * so far. On most cases, the IRQ routing configuraiton is controlled by PCI
>>> + * configuraiton registers on the legacy bridge, normally PCI BDF(0, 31, 0).
>>> + * On some newer platforms like BayTrail and Braswell, the IRQ routing is now
>>> + * in the IBASE register block where IBASE is memory-mapped.
>>> + */
>>> +enum pirq_config {
>>> +       PIRQ_VIA_PCI,
>>> +       PIRQ_VIA_IBASE
>>> +};
>>> +
>>> +/**
>>> + * Intel interrupt router control block
>>> + *
>>> + * Its members' value will be filled in based on device tree's input.
>>> + *
>>> + * @config:    PIRQ_VIA_PCI or PIRQ_VIA_IBASE
>>> + * @link_base: link value base number
>>> + * @irq_mask:  IRQ mask reprenting the 16 IRQs in 8259, bit N is 1 means
>>> + *             IRQ N is available to be routed
>>> + * @lb_bdf:    irq router's PCI bus/device/function number encoding
>>> + * @ibase:     IBASE register block base address
>>> + */
>>> +struct irq_router {
>>> +       int config;
>>> +       u32 link_base;
>>> +       u16 irq_mask;
>>> +       u32 bdf;
>>> +       u32 ibase;
>>> +};
>>> +
>>> +struct pirq_routing {
>>> +       int bdf;
>>> +       int pin;
>>> +       int pirq;
>>> +};
>>> +
>>> +/* PIRQ link number and value conversion */
>>> +#define LINK_V2N(link, base)   (link - base)
>>> +#define LINK_N2V(link, base)   (link + base)
>>> +
>>> +#define PIRQ_BITMAP            0xdef8
>>> +
>>> +struct irq_info;
>>> +
>>> +/**
>>> + * board_fill_irq_info() - Board-specific irq_info fill routine
>>> + *
>>> + * This fills the irq_info table for any board-specific add-in cards.
>>> + *
>>> + * @slot:      pointer to the struct irq_info that is to be filled in
>>> + * @return:    number of entries were written to the struct irq_info
>>> + */
>>> +int board_fill_irq_info(struct irq_info *slot);
>>> +
>>> +/**
>>> + * cpu_irq_init() - Initialize CPU IRQ routing
>>> + *
>>> + * This initializes some platform-specific registers related to IRQ routing,
>>> + * like configuring internal PCI devices to use which PCI interrupt pin,
>>> + * and which PCI interrupt pin is mapped to which PIRQ line. Note on some
>>> + * platforms, such IRQ routing might be hard-coded thus cannot configure.
>>> + */
>>> +void cpu_irq_init(void);
>>> +
>>> +/**
>>> + * pirq_init() - Initialize platform PIRQ routing
>>> + *
>>> + * This initializes the PIRQ routing on the platform and configures all PCI
>>> + * devices' interrupt line register to a working IRQ number on the 8259 PIC.
>>> + */
>>> +void pirq_init(void);
>>> +
>>> +#endif /* _ARCH_IRQ_H_ */
>>> diff --git a/include/dt-bindings/interrupt-router/intel-irq.h b/include/dt-bindings/interrupt-router/intel-irq.h
>>> new file mode 100644
>>> index 0000000..41077ef
>>> --- /dev/null
>>> +++ b/include/dt-bindings/interrupt-router/intel-irq.h
>>> @@ -0,0 +1,29 @@
>>> +/*
>>> + * Copyright (C) 2015, Bin Meng <bmeng.cn at gmail.com>
>>> + *
>>> + * SPDX-License-Identifier:    GPL-2.0+
>>> + */
>>> +
>>> +#ifndef _DT_BINDINGS_INTEL_IRQ_H_
>>> +#define _DT_BINDINGS_INTEL_IRQ_H_
>>> +
>>> +/* PCI interrupt pin */
>>> +#define INTA                   1
>>> +#define INTB                   2
>>> +#define INTC                   3
>>> +#define INTD                   4
>>> +
>>> +/* PIRQs */
>>> +#define PIRQA                  0
>>> +#define PIRQB                  1
>>> +#define PIRQC                  2
>>> +#define PIRQD                  3
>>> +#define PIRQE                  4
>>> +#define PIRQF                  5
>>> +#define PIRQG                  6
>>> +#define PIRQH                  7
>>
>> Can these go in a common file or can this file be included by the
>> other file? Really want to avoid duplicate code.
>
> I think we can have the defines here in
> include/dt-bindings/interrupt-router/intel-irq.h and have
> arch/x86/include/asm/irq.h to include
> include/dt-bindings/interrupt-router/intel-irq.h. Would that be OK?

Yes that sounds reasonable.

>
>>> +
>>> +/* PCI bdf encoding */
>>> +#define PCI_BDF(b, d, f)       ((b) << 16 | (d) << 11 | (f) << 8)
>>> +
>>> +#endif /* _DT_BINDINGS_INTEL_IRQ_H_ */
>>> diff --git a/include/fdtdec.h b/include/fdtdec.h
>>> index 6590470..dc1c85b 100644
>>> --- a/include/fdtdec.h
>>> +++ b/include/fdtdec.h
>>> @@ -177,6 +177,7 @@ enum fdt_compat_id {
>>>         COMPAT_INTEL_QRK_MRC,           /* Intel Quark MRC */
>>>         COMPAT_SOCIONEXT_XHCI,          /* Socionext UniPhier xHCI */
>>>         COMPAT_INTEL_PCH,               /* Intel PCH */
>>> +       COMPAT_INTEL_IRQ_ROUTER,        /* Intel Interrupt Router */
>>>
>>>         COMPAT_COUNT,
>>>  };
>>> diff --git a/lib/fdtdec.c b/lib/fdtdec.c
>>> index 80b897a..22d1e39 100644
>>> --- a/lib/fdtdec.c
>>> +++ b/lib/fdtdec.c
>>> @@ -76,6 +76,7 @@ static const char * const compat_names[COMPAT_COUNT] = {
>>>         COMPAT(INTEL_QRK_MRC, "intel,quark-mrc"),
>>>         COMPAT(SOCIONEXT_XHCI, "socionext,uniphier-xhci"),
>>>         COMPAT(COMPAT_INTEL_PCH, "intel,bd82x6x"),
>>> +       COMPAT(COMPAT_INTEL_IRQ_ROUTER, "intel,irq-router"),
>>>  };
>>>
>>>  const char *fdtdec_get_compatible(enum fdt_compat_id id)
>>> --
>>> 1.8.2.1
>>>
>>
>> Do you think (later) this might be a target to move to driver model?
>>
>
> Maybe, if we want to support more chipset's IRQ router. But I guess
> that might not be the case since we may only support Intel processors
> in U-Boot?

Not sure. I don't have any x86 AMD devices so it won't come from
me...but in generate we are trying to deprecate this compat table as
things move to driver model. It services mainly as a list of things to
fix.

Regards,
Simon


More information about the U-Boot mailing list