Re: [PATCH 2/2] irqchip: add TS-4800 interrupt controller

[Marc Zyngier]

On Fri, 18 Dec 2015 14:39:19 -0500
Damien Riegel  wrote:

> This commit adds support for the TS-4800 interrupt controller. This
> controller is instantiated in a companion FPGA, and multiplex interrupts
> for other FPGA IPs.
> 
> As this component is external to the SoC, the SoC might need to reserve
> pins, so this controller is implemented as a platform driver and doesn't
> use the IRQCHIP_DECLARE construct.
> 
> Signed-off-by: Damien Riegel 
> ---
>  drivers/irqchip/Kconfig  |   6 ++
>  drivers/irqchip/Makefile |   1 +
>  drivers/irqchip/irq-ts4800.c | 156 
> +++
>  3 files changed, 163 insertions(+)
>  create mode 100644 drivers/irqchip/irq-ts4800.c
> 
> diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
> index 27b52c8..e734772 100644
> --- a/drivers/irqchip/Kconfig
> +++ b/drivers/irqchip/Kconfig
> @@ -137,6 +137,12 @@ config TB10X_IRQC
>   select IRQ_DOMAIN
>   select GENERIC_IRQ_CHIP
>  
> +config TS4800_IRQ
> + tristate "TS-4800 IRQ controller"
> + select IRQ_DOMAIN
> + help
> +   Support for the TS-4800 FPGA IRQ controller
> +
>  config VERSATILE_FPGA_IRQ
>   bool
>   select IRQ_DOMAIN
> diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
> index bb3048f..ca9de01 100644
> --- a/drivers/irqchip/Makefile
> +++ b/drivers/irqchip/Makefile
> @@ -39,6 +39,7 @@ obj-$(CONFIG_ARCH_NSPIRE)   += irq-zevio.o
>  obj-$(CONFIG_ARCH_VT8500)+= irq-vt8500.o
>  obj-$(CONFIG_ST_IRQCHIP) += irq-st.o
>  obj-$(CONFIG_TB10X_IRQC) += irq-tb10x.o
> +obj-$(CONFIG_TS4800_IRQ) += irq-ts4800.o
>  obj-$(CONFIG_XTENSA) += irq-xtensa-pic.o
>  obj-$(CONFIG_XTENSA_MX)  += irq-xtensa-mx.o
>  obj-$(CONFIG_IRQ_CROSSBAR)   += irq-crossbar.o
> diff --git a/drivers/irqchip/irq-ts4800.c b/drivers/irqchip/irq-ts4800.c
> new file mode 100644
> index 000..f5a4d5b
> --- /dev/null
> +++ b/drivers/irqchip/irq-ts4800.c
> @@ -0,0 +1,156 @@
> +/*
> + * Multiplexed-IRQs driver for TS-4800's FPGA
> + *
> + * Copyright (c) 2015 - Savoir-faire Linux
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define IRQ_MASK0x4
> +#define IRQ_STATUS  0x8
> +
> +struct ts4800_irq_data {
> + void __iomem*base;
> + struct irq_domain   *domain;
> + struct irq_chip irq_chip;
> +};
> +
> +static void ts4800_irq_mask(struct irq_data *d)
> +{
> + struct ts4800_irq_data *data = irq_data_get_irq_chip_data(d);
> + u16 mask = 1 << d->hwirq;
> + u16 reg = readw(data->base + IRQ_MASK);
> +
> + writew(reg | mask, data->base + IRQ_MASK);
> +}
> +
> +static void ts4800_irq_unmask(struct irq_data *d)
> +{
> + struct ts4800_irq_data *data = irq_data_get_irq_chip_data(d);
> + u16 mask = 1 << d->hwirq;
> + u16 reg = readw(data->base + IRQ_MASK);
> +
> + writew(reg & ~mask, data->base + IRQ_MASK);
> +}
> +
> +static int ts4800_irqdomain_map(struct irq_domain *d, unsigned int irq,
> + irq_hw_number_t hwirq)
> +{
> + struct ts4800_irq_data *data = d->host_data;
> +
> + irq_set_chip_and_handler(irq, &data->irq_chip, handle_simple_irq);
> + irq_set_chip_data(irq, data);
> + irq_set_noprobe(irq);
> +
> + return 0;
> +}
> +
> +struct irq_domain_ops ts4800_ic_ops = {
> + .map = ts4800_irqdomain_map,
> + .xlate = irq_domain_xlate_onecell,
> +};
> +
> +static void ts4800_ic_chained_handle_irq(struct irq_desc *desc)
> +{
> + struct ts4800_irq_data *data = irq_desc_get_handler_data(desc);
> + u16 status = readw(data->base + IRQ_STATUS);
> +
> + if (unlikely(status == 0)) {
> + handle_bad_irq(desc);
> + return;
> + }
> +
> + do {
> + unsigned int bit = __ffs(status);
> + int irq = irq_find_mapping(data->domain, bit);
> +
> + status &= ~(1 << bit);
> + generic_handle_irq(irq);
> + } while (status);
> +}

Please use chained_irq_{enter,exit} to wrap this, or this will never
work when combined with a primary irqchip that uses a fasteoi handling
method.

Thanks,

M.
-- 
Without deviation from the norm, progress is not possible.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM64: ZynqMP: DT: Fix GIC's 'reg' property

[Marc Zyngier]

On 16/12/15 09:01, Sören Brinkmann wrote:
> On Tue, 2015-12-15 at 04:01PM +0100, Michal Simek wrote:
>> Hi,
>>
>> On 15.12.2015 10:14, Sören Brinkmann wrote:
>>> On Mon, 2015-12-14 at 05:01PM +, Marc Zyngier wrote:
>>>> Mark,
>>>>
>>>> On 14/12/15 16:46, Mark Rutland wrote:
>>>>> On Mon, Dec 14, 2015 at 08:31:40AM -0800, Soren Brinkmann wrote:
>>>>>> Signed-off-by: Soren Brinkmann 
>>>>>> ---
>>>>>>  arch/arm64/boot/dts/xilinx/zynqmp.dtsi | 6 +++---
>>>>>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>>>>>
>>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi 
>>>>>> b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
>>>>>> index 857eda5c7217..b5d1facadf16 100644
>>>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
>>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
>>>>>> @@ -80,10 +80,10 @@
>>>>>>  gic: interrupt-controller@f901 {
>>>>>>  compatible = "arm,gic-400", 
>>>>>> "arm,cortex-a15-gic";
>>>>>>  #interrupt-cells = <3>;
>>>>>> -reg = <0x0 0xf901 0x1>,
>>>>>> -  <0x0 0xf902f000 0x2000>,
>>>>>> +reg = <0x0 0xf901 0x1000>,
>>>>>> +  <0x0 0xf902 0x2>,
>>>>>><0x0 0xf904 0x2>,
>>>>>> -  <0x0 0xf906f000 0x2000>;
>>>>>> +  <0x0 0xf906 0x2>;
>>>>>
>>>>> I'm confused. These sizes don't look right for GIC-400. Is this a custom
>>>>> GIC?
>>>>
>>>> Probably an implementation that obey the SBSA requirement of aliasing
>>>> the first 4kB of the CPU interface on a 64kB page, and the second one on
>>>> the following 64kB page. See the APM system for an example of such a
>>>> thing. I'm more concerned about the GICH region (3rd one), which has no
>>>> reason to be bigger than 4kB.
>>>
>>> Xilinx didn't publish the memory map yet (at least I didn't see it in the
>>> public docs), so, let me give some excerpts:
>>>
>>> GICD:
>>> GICD_CTLR   0xF901  32  rw  0x  Distributor 
>>> Control Register
>>> ...
>>> GICD_CIDR3  0xF9010FFC  32  ro  0x00B1  Component ID3 
>>> Register
>>>
>>> GICC:
>>> GICC_CTLR   0xF902  32  rw  0x  CPU Interface 
>>> Control Register
>>> ...
>>> GICC_DIR0xF903  32  wo  x   Deactivate Interrupt 
>>> Register
>>>
>>> GICH:
>>> GICH_HCR0xF904  32  rw  0x  Hypervisor 
>>> Control Register
>>> ...
>>> GICH_LR3_Alias7 0xF9050F0C  32  rw  0x  List 
>>> Register 3
>>>
>>> GICV:
>>> GICV_CTLR   0xF906  32  rw  0x  Virtual Machine 
>>> Control Register
>>> ...
>>> GICV_DIR0xF907  32  wo  x   VM Deactivate Interrupt 
>>> Register
>>>
>>>
>>> Regarding the GICH area, it looks like it starts at 0xF904 and the
>>> alias blocks to access the other processor interfaces start at
>>> 0xF905.
>>>
>>>>
>>>>> Did this ever work wit hteh old offsets and sizes?
>>>>
>>>> It probably dies when trying to use EOImode==1.
>>>
>>> Without knowing what parts we really exercise, yes, the system comes up
>>> fine so far, but I recently found Linux boot hanging on QEMU and it
>>> seemed to be related to time not progressing (fast enough).
>>> I found a different DT using the values proposed here and that fixed the
>>> hang for me.
>>
>> We have discussed this here before with Rob
>> https://lkml.org/lkml/2015/2/24/371
>>
>> Not sure if there is any fix. It is probably just broken QEMU not DTS
>> description in mainline.
> 
> Do I understand this correctly?: The GIC IP has more configurable
> addresses than the DT binding/driver allow. Thus far people have worked
> around this by specifying some funky address in DT relying on the IP
> aliasing some addresses?

No. The *platform* messes with the GIC addressing, resulting in funky
decoding that everybody else has to deal with.

M.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/4] arm64: dts: Foundation model: increase GICC region to allow EOImode=1

[Marc Zyngier]

On 15/12/15 13:36, Andre Przywara wrote:
> The Foundation model GIC mapping is wrong, as the GICC region should
> be 8kB instead of 4kB (the model implements the GICv2 architecture).
> This defect prevents the driver from switching to EOImode==1.
> 
> Signed-off-by: Andre Przywara 

Reviewed-by: Marc Zyngier 

M.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM64: ZynqMP: DT: Fix GIC's 'reg' property

[Marc Zyngier]

Mark,

On 14/12/15 16:46, Mark Rutland wrote:
> On Mon, Dec 14, 2015 at 08:31:40AM -0800, Soren Brinkmann wrote:
>> Signed-off-by: Soren Brinkmann 
>> ---
>>  arch/arm64/boot/dts/xilinx/zynqmp.dtsi | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi 
>> b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
>> index 857eda5c7217..b5d1facadf16 100644
>> --- a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
>> @@ -80,10 +80,10 @@
>>  gic: interrupt-controller@f901 {
>>  compatible = "arm,gic-400", "arm,cortex-a15-gic";
>>  #interrupt-cells = <3>;
>> -reg = <0x0 0xf901 0x1>,
>> -  <0x0 0xf902f000 0x2000>,
>> +reg = <0x0 0xf901 0x1000>,
>> +  <0x0 0xf902 0x2>,
>><0x0 0xf904 0x2>,
>> -  <0x0 0xf906f000 0x2000>;
>> +  <0x0 0xf906 0x2>;
> 
> I'm confused. These sizes don't look right for GIC-400. Is this a custom
> GIC?

Probably an implementation that obey the SBSA requirement of aliasing
the first 4kB of the CPU interface on a 64kB page, and the second one on
the following 64kB page. See the APM system for an example of such a
thing. I'm more concerned about the GICH region (3rd one), which has no
reason to be bigger than 4kB.

> Did this ever work wit hteh old offsets and sizes?

It probably dies when trying to use EOImode==1.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v11] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller

[Marc Zyngier]

On 10/12/15 20:18, Bjorn Helgaas wrote:
> [+cc Marc for irq_dispose_mapping() question]

 +  }
 +  } while (status);
 +
 +  return retval;

 +  for (i = 0; i < 4; i++) {
 +  irq = irq_find_mapping(pcie->legacy_irq_domain, i + 1);
 +  if (irq > 0)
 +  irq_dispose_mapping(irq);
 +  }
 +  if (pcie->legacy_irq_domain)
 +  irq_domain_remove(pcie->legacy_irq_domain);
>>>
>>> Something seems wrong here.  I don't know when irq_dispose_mapping() is
>>> required, but it's not used consistently in drivers/pci, and it should be.
>>> Currently, only pci-tegra.c, pcie-xilinx.c, and this new driver use it.  
>>> Tegra uses
>>> it only for MSIs, and Xilinx seems to use it for both MSIs and INTx.  What's
>>> right?
>> Its not related to MSI or INTx, its related to domain, for freeing irq 
>> descriptor associated with irq.
> 
> So are you saying that other drivers in drivers/pci/host should be
> using irq_dispose_mapping(), but they aren't?
> 
> Marc, can you chime in here?

This indeed looks like be a bug in most drivers. Having a mapping left
when freeing the domain has a couple of side effects:
- We leak virtual interrupt numbers
- If the domain is backed by a radix tree, we leak the tree as well (but
irq_domain_remove will shout if that's the case).

So I think using irq_dispose_mapping is the right thing to do, and that
we should fix the other drivers (and maybe provide a convenient helper
to that effect).

I'll try to come up with something.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/4] arm64: dts: split Foundation model dts to put the GIC separately

[Marc Zyngier]

On 13/10/15 10:37, Andre Przywara wrote:
> The ARMv8 Foundation model can be run with a GICv2 or a GICv3.
> To prepare for the GICv3 version of the .dts without code duplication,
> move most of the nodes of the existing DT (except the GIC) into an
> include file and just keep that include statement and the GIC node in
> the current foundation-v8.dts.
> 
> Signed-off-by: Andre Przywara 

Acked-by: Marc Zyngier 

M.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/4] arm64: dts: add .dts for GICv3 Foundation model

[Marc Zyngier]

On 13/10/15 10:37, Andre Przywara wrote:
> The ARMv8 Foundation model sports a command line parameter to use
> a GICv3 emulation instead of the default GICv2 interrupt controller.
> Add a new .dts file which reuses most of the definitions of the
> existing model while just adding the required properties for the
> GICv3 node.
> This allows the public Foundation model to run with a GICv3.
> 
> Signed-off-by: Andre Przywara 
> ---
>  arch/arm64/boot/dts/arm/Makefile|  2 +-
>  arch/arm64/boot/dts/arm/foundation-v8-gicv3.dts | 30 
> +
>  2 files changed, 31 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm64/boot/dts/arm/foundation-v8-gicv3.dts
> 
> diff --git a/arch/arm64/boot/dts/arm/Makefile 
> b/arch/arm64/boot/dts/arm/Makefile
> index bb3c072..46d342d 100644
> --- a/arch/arm64/boot/dts/arm/Makefile
> +++ b/arch/arm64/boot/dts/arm/Makefile
> @@ -1,4 +1,4 @@
> -dtb-$(CONFIG_ARCH_VEXPRESS) += foundation-v8.dtb
> +dtb-$(CONFIG_ARCH_VEXPRESS) += foundation-v8.dtb foundation-v8-gicv3.dtb
>  dtb-$(CONFIG_ARCH_VEXPRESS) += juno.dtb juno-r1.dtb
>  dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb
>  dtb-$(CONFIG_ARCH_VEXPRESS) += vexpress-v2f-1xv7-ca53x2.dtb
> diff --git a/arch/arm64/boot/dts/arm/foundation-v8-gicv3.dts 
> b/arch/arm64/boot/dts/arm/foundation-v8-gicv3.dts
> new file mode 100644
> index 000..ecdbe98
> --- /dev/null
> +++ b/arch/arm64/boot/dts/arm/foundation-v8-gicv3.dts
> @@ -0,0 +1,30 @@
> +/*
> + * ARM Ltd.
> + *
> + * ARMv8 Foundation model DTS (GICv3 configuration)
> + */
> +
> +#include "foundation-v8.dtsi"
> +
> +/ {
> + gic: interrupt-controller@2f00 {
> + compatible = "arm,gic-v3";
> + #interrupt-cells = <3>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> + interrupt-controller;
> + reg =   <0x0 0x2f00 0x0 0x1>,
> + <0x0 0x2f10 0x0 0x20>,
> + <0x0 0x2c00 0x0 0x2000>,
> + <0x0 0x2c01 0x0 0x2000>,
> + <0x0 0x2c02f000 0x0 0x2000>;
> + interrupts = <1 9 0xf04>;

You can remove the 'f' from the GIC maintenance interrupt - this doesn't
mean anything on GICv3.

> +
> + its: its@2f02 {
> + compatible = "arm,gic-v3-its";
> + msi-controller;
> + reg = <0x0 0x2f02 0x0 0x2>;
> + };
> + };
> +};
> 

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/4] arm64: dts: Foundation model: increate GICC region to allow EOImode=1

[Marc Zyngier]

Hey Andre,

On 13/10/15 10:37, Andre Przywara wrote:
> Recent commits made the GIC driver use EOImode=1 for all GICs
> that advertise the proper GICC region size.
> To let the model benefit from the blessings of that mode, increase
> the GICC region to its actual size of 8K.
> 
> Signed-off-by: Andre Przywara 

The patch looks good, but the commit log is slightly confusing. Apart
from the typo in the title ("increate"), it would be better to say
something like:

"The Foundation model GIC mapping is wrong, as the GICC region should be
8kB instead of 4kB (the model implements the GICv2 architecture). This
defect prevents the driver from switching to EOImode==1."

Or something similar.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/4] arm64: dts: prepare foundation-v8.dts to cope with GICv3

[Marc Zyngier]

On 13/10/15 10:37, Andre Przywara wrote:
> To prepare the ARM foundation model to support GICv3, we adjust
> the #address-cells property of the current GICv2 node to be
> compatible with the two cells required for GICv3 later.
> 
> Signed-off-by: Andre Przywara 

Acked-by: Marc Zyngier 

M.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v11] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller

[Marc Zyngier]

On 29/11/15 12:03, Bharat Kumar Gogada wrote:
> Adding PCIe Root Port driver for Xilinx PCIe NWL bridge IP.
> 
> Signed-off-by: Bharat Kumar Gogada 
> Signed-off-by: Ravi Kiran Gummaluri 
> Acked-by: Rob Herring 

I don't have much to add to this, so FWIW:

Reviewed-by: Marc Zyngier 

M.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 02/11] MIPS: bmips: Add bcm6345-l2-timer interrupt controller

[Marc Zyngier]

On 01/12/15 13:02, Simon Arlott wrote:
> Add the BCM6345/BCM6318 timer as an interrupt controller so that it can be
> used by the watchdog to warn that its timer will expire soon.
> 
> Support for clocksource/clockevents is not implemented as the timer
> interrupt is not per CPU (except on the BCM6318) and the MIPS clock is
> better. This could be added later if required without changing the device
> tree binding.
> 
> Signed-off-by: Simon Arlott 
> ---
>  drivers/irqchip/Kconfig|   5 +
>  drivers/irqchip/Makefile   |   1 +
>  drivers/irqchip/irq-bcm6345-l2-timer.c | 386 
> +
>  3 files changed, 392 insertions(+)
>  create mode 100644 drivers/irqchip/irq-bcm6345-l2-timer.c

I'm not sure how useful it is to have a bunch of timers that are just
turned off, but from an irqchip PoV:

Acked-by: Marc Zyngier 

M.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 4/6] pinctrl: meson: Enable GPIO IRQs

[Marc Zyngier]

On 02/12/15 11:37, Carlo Caione wrote:
> On Wed, Dec 2, 2015 at 10:03 AM, Marc Zyngier  wrote:
>> On 01/12/15 19:41, Carlo Caione wrote:
>>> On Tue, Dec 1, 2015 at 8:16 PM, Marc Zyngier  wrote:
>>>> On 01/12/15 16:24, Carlo Caione wrote:
>>>>> From: Carlo Caione 
> 
> [...]
> 
>>> In v2 I had the set of fwspec to track number and trigger type of the
>>> IRQ, so it was straightforward. With this patch I have moved away from
>>> that solution (as you suggested) and I'm using the 'amlogic,irqs-gpio'
>>> parameter to track down the IRQ numbers (but not the trigger type).
>>> It's the same solution we have in drivers/irqchip/irq-crossbar.c where
>>> the trigger type is hardcoded in allocate_gic_irq().
>>> If I need to save both the IRQ and the trigger type at this point I
>>> wonder if it's better to go back to the set of fwspec or convert the
>>> fwspec to of_phandle_args and save that.
>>
>> No. This should come from the interrupt specifier you are getting from
>> the device. You should never make up that information.
>>
>> Your amlogic,irqs-gpio property gives you a list of downstream
>> interrupts. The device connected to your pinctrl HW provides you with
>> the upstream interrupt number (which you will map to one of your
>> downstream IRQ) and crucially the trigger type. Please look at how the
>> TI cross bar works (again).
> 
> Ok, this definitely makes sense and I'm going to fix it in the next
> revision, thanks for the explanation. Still I fail to see how the TI
> cross bar driver is actually doing what you are suggesting here. If
> I'm correctly reading the code here
> http://lxr.free-electrons.com/source/drivers/irqchip/irq-crossbar.c#L101
> the driver is hardcoding the trigger type for the downstream IRQ to be
> passed to the GIC code. But probably I'm missing something obvious.

Damn. No, you're right. I'll fix that. Thanks for the heads up, and
apologies for the shouting! ;-)

>>>>> +static int meson_gpio_to_irq(struct gpio_chip *chip, unsigned offset)
>>>>> +{
>>>>> + struct meson_domain *domain = to_meson_domain(chip);
>>>>> + struct meson_pinctrl *pc = domain->pinctrl;
>>>>> + struct meson_bank *bank;
>>>>> + struct irq_fwspec irq_data;
>>>>> + unsigned int hwirq, irq;
>>>>> +
>>>>> + hwirq = domain->data->pin_base + offset;
>>>>> +
>>>>> + if (meson_get_bank(domain, hwirq, &bank))
>>>>> + return -ENXIO;
>>>>> +
>>>>> + irq_data.param_count = 2;
>>>>> + irq_data.param[0] = hwirq;
>>>>> +
>>>>> + /* dummy. It will be changed later in meson_irq_set_type */
>>>>> + irq_data.param[1] = IRQ_TYPE_EDGE_RISING;
>>>>
>>>> Blah. Worse than I though... How do you end-up here? Why can't you
>>>> obtain the corresponding of_phandle_args instead of making things up?
>>>
>>> because I do not have a of_phandle. This is basically the .to_irq hook
>>> of the gpio_chip. This code is being called programmatically from the
>>> gpiolib. No DTS/OF involved here.
>>>
>>>> This looks mad. Do you really need this?
>>>
>>> Well, I'm open to any suggestion on how improve this mess.
>>
>> The question to answer is: in what circumstances do you have to convert
>> a GPIO into an IRQ at runtime? The only case should be "when you
>> discover a device having an interrupt pointing to your pinctrl". And in
>> this case, you have all the information to reconfigure the HW and assign
>> the interrupt.
>>
>> I really don't get why you want or need to involve gpiolib in this.
> 
> Again probably I'm missing something (and Linus probably could help
> here) but the only place I see the .to_irq hook (that is
> meson_gpio_to_irq() in the driver code) being called is from
> gpiod_to_irq() function in the gpiolib code.
> 
> One practical case in which that code path is involved is when (for
> example) I have something like 'cd-gpios = <&gpio GPIOX 0>;' for the
> card detection IRQ in the MMC node and in this case I fail to see an
> easy way to get the trigger type without touching the MMC / gpiolib
> code (any idea?).
> This function is not called at all when in the DTS I explicitly have
> the interrupt specifier defined using the 'interrupts = <...>'
> property and in that case I have all the information I need to map the
> downstream IRQ.

I do think that the moment you want to describe an interrupt (and have
the HW that can trigger one), you should end up describing this as a
real interrupt, and not as a "shake this pin" kind of thing.

The former gives you strong guarantees as to how this is going to be
processed, while the later looks like a hack to paper over missing
functionalities in past kernels...

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 4/6] pinctrl: meson: Enable GPIO IRQs

[Marc Zyngier]

On 01/12/15 19:41, Carlo Caione wrote:
> On Tue, Dec 1, 2015 at 8:16 PM, Marc Zyngier  wrote:
>> On 01/12/15 16:24, Carlo Caione wrote:
>>> From: Carlo Caione 
> 
>>> +static int meson_irq_domain_alloc(struct irq_domain *domain, unsigned int 
>>> irq,
>>> +   unsigned int nr_irqs, void *arg)
>>> +{
>>> + struct meson_pinctrl *pc = domain->host_data;
>>> + struct irq_fwspec *irq_data = arg;
>>> + struct irq_fwspec gic_data;
>>> + irq_hw_number_t hwirq;
>>> + int index, ret, i;
>>> +
>>> + if (irq_data->param_count != 2)
>>> + return -EINVAL;
>>> +
>>> + hwirq = irq_data->param[0];
>>> + dev_dbg(pc->dev, "%s irq %d, nr %d, hwirq %lu\n",
>>> + __func__, irq, nr_irqs, hwirq);
>>> +
>>> + for (i = 0; i < nr_irqs; i++) {
>>> + index = meson_map_gic_irq(domain, hwirq + i);
>>> + if (index < 0)
>>> + return index;
>>> +
>>> + irq_domain_set_hwirq_and_chip(domain, irq + i,
>>> +   hwirq + i,
>>> +   &meson_irq_chip,
>>> +   pc);
>>> +
>>> + gic_data.param_count = 3;
>>> + gic_data.fwnode = domain->parent->fwnode;
>>> + gic_data.param[0] = 0; /* SPI */
>>> + gic_data.param[1] = pc->gic_irqs[index];
>>> + gic_data.param[1] = IRQ_TYPE_EDGE_RISING;
> 
> Oh, this should be gic_data.param[2]. Just noticed.
> 
>> That feels quite wrong. Hardcoding the trigger like this and hoping for
>> a set_type to set it right at a later time is just asking for trouble.
>> Why can't you use the trigger type that has been provided by the
>> interrupt descriptor?
> 
> In v2 I had the set of fwspec to track number and trigger type of the
> IRQ, so it was straightforward. With this patch I have moved away from
> that solution (as you suggested) and I'm using the 'amlogic,irqs-gpio'
> parameter to track down the IRQ numbers (but not the trigger type).
> It's the same solution we have in drivers/irqchip/irq-crossbar.c where
> the trigger type is hardcoded in allocate_gic_irq().
> If I need to save both the IRQ and the trigger type at this point I
> wonder if it's better to go back to the set of fwspec or convert the
> fwspec to of_phandle_args and save that.

No. This should come from the interrupt specifier you are getting from
the device. You should never make up that information.

Your amlogic,irqs-gpio property gives you a list of downstream
interrupts. The device connected to your pinctrl HW provides you with
the upstream interrupt number (which you will map to one of your
downstream IRQ) and crucially the trigger type. Please look at how the
TI cross bar works (again).

>>> +static int meson_gpio_to_irq(struct gpio_chip *chip, unsigned offset)
>>> +{
>>> + struct meson_domain *domain = to_meson_domain(chip);
>>> + struct meson_pinctrl *pc = domain->pinctrl;
>>> + struct meson_bank *bank;
>>> + struct irq_fwspec irq_data;
>>> + unsigned int hwirq, irq;
>>> +
>>> + hwirq = domain->data->pin_base + offset;
>>> +
>>> + if (meson_get_bank(domain, hwirq, &bank))
>>> + return -ENXIO;
>>> +
>>> + irq_data.param_count = 2;
>>> + irq_data.param[0] = hwirq;
>>> +
>>> + /* dummy. It will be changed later in meson_irq_set_type */
>>> + irq_data.param[1] = IRQ_TYPE_EDGE_RISING;
>>
>> Blah. Worse than I though... How do you end-up here? Why can't you
>> obtain the corresponding of_phandle_args instead of making things up?
> 
> because I do not have a of_phandle. This is basically the .to_irq hook
> of the gpio_chip. This code is being called programmatically from the
> gpiolib. No DTS/OF involved here.
> 
>> This looks mad. Do you really need this?
> 
> Well, I'm open to any suggestion on how improve this mess.

The question to answer is: in what circumstances do you have to convert
a GPIO into an IRQ at runtime? The only case should be "when you
discover a device having an interrupt pointing to your pinctrl". And in
this case, you have all the information to reconfigure the HW and assign
the interrupt.

I really don't get why you want or need to involve gpiolib in this.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 4/6] pinctrl: meson: Enable GPIO IRQs

[Marc Zyngier]

On 01/12/15 16:24, Carlo Caione wrote:
> From: Carlo Caione 
> 
> On Meson8 and Meson8b SoCs there are 8 independent filtered GPIO
> interrupt modules that can be programmed to use any of the GPIOs in the
> chip as an interrupt source.
> 
> For each GPIO IRQ we have:
> 
> GPIOs --> [mux]--> [polarity]--> [filter]--> [edge select]--> GIC
> 
> The eight GPIO interrupts respond to mask/unmask/clear/etc.. just like
> any other interrupt in the chip. The difference for the GPIO interrupts
> is that they can be filtered and conditioned.
> 
> This patch adds support for the external GPIOs interrupts and enables
> them for Meson8 and Meson8b SoCs.
> 
> Signed-off-by: Carlo Caione 
> Signed-off-by: Beniamino Galvani 
> ---
>  drivers/pinctrl/Kconfig|   1 +
>  drivers/pinctrl/meson/Makefile |   2 +-
>  drivers/pinctrl/meson/irqchip-gpio-meson.c | 321 
> +
>  drivers/pinctrl/meson/pinctrl-meson.c  |  30 +++
>  drivers/pinctrl/meson/pinctrl-meson.h  |  15 ++
>  5 files changed, 368 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/pinctrl/meson/irqchip-gpio-meson.c
> 

[...]

> +static int meson_irq_domain_alloc(struct irq_domain *domain, unsigned int 
> irq,
> +   unsigned int nr_irqs, void *arg)
> +{
> + struct meson_pinctrl *pc = domain->host_data;
> + struct irq_fwspec *irq_data = arg;
> + struct irq_fwspec gic_data;
> + irq_hw_number_t hwirq;
> + int index, ret, i;
> +
> + if (irq_data->param_count != 2)
> + return -EINVAL;
> +
> + hwirq = irq_data->param[0];
> + dev_dbg(pc->dev, "%s irq %d, nr %d, hwirq %lu\n",
> + __func__, irq, nr_irqs, hwirq);
> +
> + for (i = 0; i < nr_irqs; i++) {
> + index = meson_map_gic_irq(domain, hwirq + i);
> + if (index < 0)
> + return index;
> +
> + irq_domain_set_hwirq_and_chip(domain, irq + i,
> +   hwirq + i,
> +   &meson_irq_chip,
> +   pc);
> +
> + gic_data.param_count = 3;
> + gic_data.fwnode = domain->parent->fwnode;
> + gic_data.param[0] = 0; /* SPI */
> + gic_data.param[1] = pc->gic_irqs[index];
> + gic_data.param[1] = IRQ_TYPE_EDGE_RISING;

That feels quite wrong. Hardcoding the trigger like this and hoping for
a set_type to set it right at a later time is just asking for trouble.
Why can't you use the trigger type that has been provided by the
interrupt descriptor?

> +
> + ret = irq_domain_alloc_irqs_parent(domain, irq + i, nr_irqs,
> +&gic_data);
> + }
> +
> + return 0;
> +}
> +
> +static void meson_irq_domain_free(struct irq_domain *domain, unsigned int 
> irq,
> +   unsigned int nr_irqs)
> +{
> + struct meson_pinctrl *pc = domain->host_data;
> + struct irq_data *irq_data;
> + int index, i;
> +
> + spin_lock(&pc->lock);
> + for (i = 0; i < nr_irqs; i++) {
> + irq_data = irq_domain_get_irq_data(domain, irq + i);
> + index = meson_get_gic_irq(pc, irq_data->hwirq);
> + if (index < 0)
> + continue;
> + pc->irq_map[index] = IRQ_FREE;
> + }
> + spin_unlock(&pc->lock);
> +
> + irq_domain_free_irqs_parent(domain, irq, nr_irqs);
> +}
> +
> +static int meson_irq_domain_translate(struct irq_domain *d,
> +   struct irq_fwspec *fwspec,
> +   unsigned long *hwirq,
> +   unsigned int *type)
> +{
> + if (is_of_node(fwspec->fwnode)) {
> + if (fwspec->param_count != 2)
> + return -EINVAL;
> +
> + *hwirq = fwspec->param[0];
> + *type = fwspec->param[1];
> +
> + return 0;
> + }
> +
> + return -EINVAL;
> +}
> +
> +static struct irq_domain_ops meson_irq_domain_ops = {
> + .alloc  = meson_irq_domain_alloc,
> + .free   = meson_irq_domain_free,
> + .translate  = meson_irq_domain_translate,
> +};
> +
> +int meson_gpio_irq_init(struct meson_pinctrl *pc)
> +{
> + struct device_node *node = pc->dev->of_node;
> + struct device_node *parent_node;
> + struct irq_domain *parent_domain;
> + const __be32 *irqs;
> + int i, size;
> +
> + parent_node = of_irq_find_parent(node);
> + if (!parent_node) {
> + dev_err(pc->dev, "can't find parent interrupt controller\n");
> + return -EINVAL;
> + }
> +
> + parent_domain = irq_find_host(parent_node);
> + if (!parent_domain) {
> + dev_err(pc->dev, "can't find parent IRQ domain\n");
> + return -EINVAL;
> + }
> +
> + pc->reg_irq = meson_map_resource(pc, node, "irq");
> + 

Re: [PATCH v10] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller

[Marc Zyngier]

On 27/11/15 15:02, Bharat Kumar Gogada wrote:
> Adding PCIe Root Port driver for Xilinx PCIe NWL bridge IP.
> 
> Signed-off-by: Bharat Kumar Gogada 
> Signed-off-by: Ravi Kiran Gummaluri 
> Acked-by: Rob Herring 
> ---
> Changes for v10:
> -> Changed MSI address to PCIe controller base.
> -> Removed nwl_check_hwirq function, instead using bitmap_find_next_zero_area
>API to do the same.
> ---
>  .../devicetree/bindings/pci/xilinx-nwl-pcie.txt|   68 ++
>  drivers/pci/host/Kconfig   |   10 +
>  drivers/pci/host/Makefile  |1 +
>  drivers/pci/host/pcie-xilinx-nwl.c | 1068 
> 
>  4 files changed, 1147 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
>  create mode 100644 drivers/pci/host/pcie-xilinx-nwl.c
> 
> diff --git a/drivers/pci/host/pcie-xilinx-nwl.c 
> b/drivers/pci/host/pcie-xilinx-nwl.c
> new file mode 100644
> index 000..d070344
> --- /dev/null
> +++ b/drivers/pci/host/pcie-xilinx-nwl.c

[...]

> +#define MSI_ADDRESS  0xFD48
> +

Really? Why do you bother having DT support then? You might as well
hardcode everything, while you're at it.

/me felling depressed now.

> +struct nwl_msi { /* MSI information */
> + struct irq_domain *msi_domain;
> + unsigned long *bitmap;
> + struct irq_domain *dev_domain;
> + struct mutex lock;  /* protect bitmap variable */
> + int irq_msi0;
> + int irq_msi1;
> +};
> +
> +struct nwl_pcie {
> + struct device *dev;
> + void __iomem *breg_base;
> + void __iomem *pcireg_base;
> + void __iomem *ecam_base;
> + u32 phys_breg_base; /* Physical Bridge Register Base */
> + u32 phys_pcie_reg_base; /* Physical PCIe Controller Base */
> + u32 phys_ecam_base; /* Physical Configuration Base */

All these u32 should be phys_addr_t. Not all the world is 32bit,
fortunately.

> + u32 breg_size;
> + u32 pcie_reg_size;
> + u32 ecam_size;
> + int irq_intx;
> + int irq_misc;
> + u32 ecam_value;
> + u8 last_busno;
> + u8 root_busno;
> + u8 link_up;
> + struct nwl_msi msi;
> + struct irq_domain *legacy_irq_domain;
> +};

[...]

> +static void nwl_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
> +{
> + phys_addr_t msi_addr = MSI_ADDRESS;

Fix this.

> +
> + msg->address_lo = lower_32_bits(msi_addr);
> + msg->address_hi = upper_32_bits(msi_addr);
> + msg->data = data->hwirq;
> +}

[...]

> +static int nwl_pcie_bridge_init(struct nwl_pcie *pcie)
> +{
> + struct platform_device *pdev = to_platform_device(pcie->dev);
> + u32 breg_val, ecam_val, first_busno = 0;
> + int err;
> + int check_link_up = 0;
> +
> + /* Check for BREG present bit */
> + breg_val = nwl_bridge_readl(pcie, E_BREG_CAPABILITIES) & BREG_PRESENT;
> + if (!breg_val) {
> + dev_err(pcie->dev, "BREG is not present\n");
> + return breg_val;
> + }
> + /* Write bridge_off to breg base */
> + nwl_bridge_writel(pcie, (u32)(pcie->phys_breg_base),
> +   E_BREG_BASE_LO);
> +

I love the casting of a u32 to a u32. You have to program E_BREG_BASE_HI
as well, once you've fixed the data type.

> + /* Enable BREG */
> + nwl_bridge_writel(pcie, ~BREG_ENABLE_FORCE & BREG_ENABLE,
> +   E_BREG_CONTROL);
> +
> + /* Disable DMA channel registers */
> + nwl_bridge_writel(pcie, nwl_bridge_readl(pcie, BRCFG_PCIE_RX0) |
> +   CFG_DMA_REG_BAR, BRCFG_PCIE_RX0);
> +
> + /* Enable the bridge config interrupt */
> + nwl_bridge_writel(pcie, nwl_bridge_readl(pcie, BRCFG_INTERRUPT) |
> +   BRCFG_INTERRUPT_MASK, BRCFG_INTERRUPT);
> + /* Enable Ingress subtractive decode translation */
> + nwl_bridge_writel(pcie, SET_ISUB_CONTROL, I_ISUB_CONTROL);
> +
> + /* Enable msg filtering details */
> + nwl_bridge_writel(pcie, CFG_ENABLE_MSG_FILTER_MASK,
> +   BRCFG_PCIE_RX_MSG_FILTER);
> + do {
> + err = nwl_pcie_link_up(pcie, PHY_RDY_LINKUP);
> + if (err != 1) {
> + check_link_up++;
> + if (check_link_up > LINKUP_ITER_CHECK)
> + return -ENODEV;
> + mdelay(1000);
> + }
> + } while (!err);
> +
> + /* Check for ECAM present bit */
> + ecam_val = nwl_bridge_readl(pcie, E_ECAM_CAPABILITIES) & E_ECAM_PRESENT;
> + if (!ecam_val) {
> + dev_err(pcie->dev, "ECAM is not present\n");
> + return ecam_val;
> + }
> +
> + /* Enable ECAM */
> + nwl_bridge_writel(pcie, nwl_bridge_readl(pcie, E_ECAM_CONTROL) |
> +   E_ECAM_CR_ENABLE, E_ECAM_CONTROL);
> + /* Write ecam_value on ecam_control */
> + nwl_bridge_writel(pcie, nwl_bridge_readl

Re: [PATCH v2 2/5] irqdomain: introduce irq_of_phandle_args_to_fwspec

[Marc Zyngier]

On Mon, 23 Nov 2015 11:16:53 +0100
Carlo Caione  wrote:

> From: Carlo Caione 
> 
> Export of_phandle_args_to_fwspec with a new compliant name.
> 
> Signed-off-by: Carlo Caione 
> ---
>  include/linux/of_irq.h | 2 ++
>  kernel/irq/irqdomain.c | 5 +++--
>  2 files changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/of_irq.h b/include/linux/of_irq.h
> index 6f879c6..66bd92e 100644
> --- a/include/linux/of_irq.h
> +++ b/include/linux/of_irq.h
> @@ -34,6 +34,8 @@ static inline int of_irq_parse_oldworld(struct device_node 
> *device, int index,
>  extern int of_irq_parse_raw(const __be32 *addr, struct of_phandle_args 
> *out_irq);
>  extern int of_irq_parse_one(struct device_node *device, int index,
> struct of_phandle_args *out_irq);
> +extern void irq_of_phandle_args_to_fwspec(struct of_phandle_args *irq_data,
> +   struct irq_fwspec *fwspec);
>  extern unsigned int irq_create_of_mapping(struct of_phandle_args *irq_data);
>  extern int of_irq_to_resource(struct device_node *dev, int index,
> struct resource *r);
> diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
> index 22aa961..b2ff223 100644
> --- a/kernel/irq/irqdomain.c
> +++ b/kernel/irq/irqdomain.c
> @@ -554,7 +554,7 @@ static int irq_domain_translate(struct irq_domain *d,
>   return 0;
>  }
>  
> -static void of_phandle_args_to_fwspec(struct of_phandle_args *irq_data,
> +void irq_of_phandle_args_to_fwspec(struct of_phandle_args *irq_data,
> struct irq_fwspec *fwspec)
>  {
>   int i;
> @@ -565,6 +565,7 @@ static void of_phandle_args_to_fwspec(struct 
> of_phandle_args *irq_data,
>   for (i = 0; i < irq_data->args_count; i++)
>   fwspec->param[i] = irq_data->args[i];
>  }
> +EXPORT_SYMBOL_GPL(irq_of_phandle_args_to_fwspec);
>  
>  unsigned int irq_create_fwspec_mapping(struct irq_fwspec *fwspec)
>  {
> @@ -618,7 +619,7 @@ unsigned int irq_create_of_mapping(struct of_phandle_args 
> *irq_data)
>  {
>   struct irq_fwspec fwspec;
>  
> - of_phandle_args_to_fwspec(irq_data, &fwspec);
> + irq_of_phandle_args_to_fwspec(irq_data, &fwspec);
>   return irq_create_fwspec_mapping(&fwspec);
>  }
>  EXPORT_SYMBOL_GPL(irq_create_of_mapping);

Given what I've said earlier about keeping fwspec structures around,
you can probably discard that patch.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-meson] Re: [PATCH v2 3/5] pinctrl: meson: enable GPIO IRQs

[Marc Zyngier]

On Tue, 24 Nov 2015 10:04:50 +0100
Carlo Caione  wrote:

> On Tue, Nov 24, 2015 at 9:28 AM, Marc Zyngier  wrote:
> > On Mon, 23 Nov 2015 11:16:54 +0100
> > Carlo Caione  wrote:
> >
> >> From: Carlo Caione 
> >>
> >> On Meson8 and Meson8b SoCs there are 8 independent filtered GPIO
> >> interrupt modules that can be programmed to use any of the GPIOs in the
> >> chip as an interrupt source.
> >>
> >> For each GPIO IRQ we have:
> >>
> >> GPIOs --> [mux]--> [polarity]--> [filter]--> [edge select]--> GIC
> >>
> >> The eight GPIO interrupts respond to mask/unmask/clear/etc.. just like
> >> any other interrupt in the chip. The difference for the GPIO interrupts
> >> is that they can be filtered and conditioned.
> >>
> >> This patch adds support for the external GPIOs interrupts and enables
> >> them for Meson8 and Meson8b SoCs.
> >>
> >> Signed-off-by: Carlo Caione 
> >> Signed-off-by: Beniamino Galvani 
> >>
> >> ---
> >
> > [...]
> >
> >> + for (i = 0; i < pc->num_gic_irqs; i++) {
> >> + struct of_phandle_args oirq;
> >> +
> >> + of_irq_parse_one(node, i, &oirq);
> >> + irq_of_phandle_args_to_fwspec(&oirq, &pc->gic_irqs[i]);
> >> +
> >> + pc->irq_map[i] = IRQ_FREE;
> >> + }
> >
> > The whole thing feels weird. Why do you need to keep a set of fwspecs?
> 
> We only have 8 IRQs on the GIC side that we can use for the GPIOs. The
> set of fwspec is used to track these IRQs.
> At probe time we read from the DTS how many and which IRQs are
> reserved on the GIC for the GPIOs. Every time a GPIO IRQ is installed,
> we use one of these IRQ lines.

That doesn't answer my question. Having the raw IRQ numbers, why not.
Storing a whole fwspec (16 u32 + 1 int + 1 pointer) seems completely
overkill.

> > All you need is a range of interrupts that would be conveniently
> > represented by a bitmap (assuming your interrupts space is a mostly
> > contiguous range).
> 
> I could do that but it feels to me like we end up hiding from the DTS
> some information that naturally should be in there: a pinctrl device
> that is using 8 interrupt lines of its interrupt controller. IMO this
> is not a special case that requires some special treatment.

Well, it is also arguable that these interrupts are not the pinctrl's,
but those of the device that actually uses them (or we'd be describing
interrupts in all interrupt controller bindings, which doesn't make any
sense).

See for example the TI crossbar, which has similar functionalities. I'm
not going to take a hard line here, but the argument you have so far
doesn't seem to hold much water for me. Or there is something obvious
that I have missed, which is entirely possible.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller

[Marc Zyngier]

On Wed, 25 Nov 2015 14:23:29 +0530
Amit Tomer  wrote:

> Sorry to intervene but just trying to learn from your comments.
> 
>  > You have plenty, and that's the whole of your device space. *All of it*. So
> >   just take the base address of your PCIe controller, and be done with
> >   it.
> 
> but isn't few of PCIe controller's registers itself are mapped
> here(base address). So, how can we use this address for MSI?

You can, because the PCIe controller never writes to itself. If it
writes to that base address, then it *is* the MSI doorbell and the
bridge will hopefully do the right thing.

> Or you said from base address of PCIe controller, find an offset that
> can be used as MSI address?

That works as well. Given the description of the HW we've been given,
any address will do, as long as it is behind the PCIe RC.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller

[Marc Zyngier]

On Wed, 25 Nov 2015 05:40:49 +
Bharat Kumar Gogada  wrote:

> > On Thu, 19 Nov 2015 11:05:23 +0530
> > Bharat Kumar Gogada  wrote:
> > 
> > > Adding PCIe Root Port driver for Xilinx PCIe NWL bridge IP.
> > >
> > > Signed-off-by: Bharat Kumar Gogada 
> > > Signed-off-by: Ravi Kiran Gummaluri 
> > > Acked-by: Rob Herring 
> > > ---
> > > +
> > > +#define MSI_ADDRESS  0xDEED
> > 
> > How did you pick this value? What if it intersect with some actual RAM?
> > What if a device actually does DMA to that location?
> > 
> > Wouldn't it make sense to actually pick a real *device* address (hint:
> > your MSI controller itself) for this purpose, as the device will never DMA
> > there?
> >
> > 
> We have already mentioned in previous patch discussion, we don't have
> any device address on our SOC for MSI, that's the reason we are
> allocating a page for MSI in RAM. Since our memory write is consumed
> by bridge and doesn't write to memory, you suggested to use some
> random address,  so using some random address.

This is becoming painful.

- "write is consumed by bridge and doesn't write to memory": So why are
  you using something that has a chance of actually being memory??? Are
  you in the business of corrupting unsuspecting data?

- "we don't have any device address on our SOC for MSI": You have
  plenty, and that's the whole of your device space. *All of it*. So
  just take the base address of your PCIe controller, and be done with
  it. Or your UART. Anything that cannot be DMA'ed to from a PCIe
  device, and that is downstream of your PCIe bridge.

M.
-- 
Jazz is not dead. It just smells funny.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller

[Marc Zyngier]

On Thu, 19 Nov 2015 11:05:23 +0530
Bharat Kumar Gogada  wrote:

> Adding PCIe Root Port driver for Xilinx PCIe NWL bridge IP.
> 
> Signed-off-by: Bharat Kumar Gogada 
> Signed-off-by: Ravi Kiran Gummaluri 
> Acked-by: Rob Herring 
> ---
> Changes for v9:
> - Modified logic in nwl_irq_domain_alloc to check availabilty of contiguous
> hw irq for multi MSI.
> - Removed allocation of page for MSI address, using dummy address.
> ---
>  .../devicetree/bindings/pci/xilinx-nwl-pcie.txt|   68 ++
>  drivers/pci/host/Kconfig   |   10 +
>  drivers/pci/host/Makefile  |1 +
>  drivers/pci/host/pcie-xilinx-nwl.c | 1100 
> 
>  4 files changed, 1179 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
>  create mode 100644 drivers/pci/host/pcie-xilinx-nwl.c
> 
> diff --git a/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt 
> b/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
> new file mode 100644
> index 000..3b2a9ad
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
> @@ -0,0 +1,68 @@
> +* Xilinx NWL PCIe Root Port Bridge DT description
> +
> +Required properties:
> +- compatible: Should contain "xlnx,nwl-pcie-2.11"
> +- #address-cells: Address representation for root ports, set to <3>
> +- #size-cells: Size representation for root ports, set to <2>
> +- #interrupt-cells: specifies the number of cells needed to encode an
> + interrupt source. The value must be 1.
> +- reg: Should contain Bridge, PCIe Controller registers location,
> + configuration sapce, and length
> +- reg-names: Must include the following entries:
> + "breg": bridge registers
> + "pcireg": PCIe controller registers
> + "cfg": configuration space region
> +- device_type: must be "pci"
> +- interrupts: Should contain NWL PCIe interrupt
> +- interrupt-names: Must include the following entries:
> + "msi1, msi0": interrupt asserted when msi is received
> + "intx": interrupt that is asserted when an legacy interrupt is received
> + "misc": interrupt asserted when miscellaneous is received
> +- interrupt-map-mask and interrupt-map: standard PCI properties to define the
> + mapping of the PCI interface to interrupt numbers.
> +- ranges: ranges for the PCI memory regions (I/O space region is not
> + supported by hardware)
> + Please refer to the standard PCI bus binding document for a more
> + detailed explanation
> +- msi-controller: indicates that this is MSI controller node
> +- msi-parent:  MSI parent of the root complex itself
> +- legacy-interrupt-controller: Interrupt controller device node for Legacy 
> interrupts
> + - interrupt-controller: identifies the node as an interrupt controller
> + - #interrupt-cells: should be set to 1
> + - #address-cells: specifies the number of cells needed to encode an
> + address. The value must be 0.
> +
> +
> +Example:
> +
> +
> +nwl_pcie: pcie@fd0e {
> + #address-cells = <3>;
> + #size-cells = <2>;
> + compatible = "xlnx,nwl-pcie-2.11";
> + #interrupt-cells = <1>;
> + msi-controller;
> + device_type = "pci";
> + interrupt-parent = <&gic>;
> + interrupts = <0 114 4>, <0 115 4>, <0 116 4>, <0 117 4>, <0 118 4>;
> + interrupt-names = "msi0", "msi1", "intx", "dummy", "misc";
> + interrupt-map-mask = <0x0 0x0 0x0 0x7>;
> + interrupt-map = <0x0 0x0 0x0 0x1 &pcie_intc 0x1>,
> + <0x0 0x0 0x0 0x2 &pcie_intc 0x2>,
> + <0x0 0x0 0x0 0x3 &pcie_intc 0x3>,
> + <0x0 0x0 0x0 0x4 &pcie_intc 0x4>;
> +
> + msi-parent = <&nwl_pcie>;
> + reg = <0x0 0xfd0e 0x1000>,
> +   <0x0 0xfd48 0x1000>,
> +   <0x0 0xe000 0x100>;
> + reg-names = "breg", "pcireg", "cfg";
> + ranges = <0x0200 0x 0xe100 0x 0xe100 0 
> 0x0f00>;
> +
> + pcie_intc: legacy-interrupt-controller {
> + interrupt-controller;
> + #address-cells = <0>;
> + #interrupt-cells = <1>;
> + };
> +
> +};
> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> index d5e58ba..24cbcba 100644
> --- a/drivers/pci/host/Kconfig
> +++ b/drivers/pci/host/Kconfig
> @@ -15,6 +15,16 @@ config PCI_MVEBU
>   depends on ARCH_MVEBU || ARCH_DOVE
>   depends on OF
>  
> +config PCIE_XILINX_NWL
> + bool "NWL PCIe Core"
> + depends on ARCH_ZYNQMP
> + select PCI_MSI_IRQ_DOMAIN if PCI_MSI
> + help
> +  Say 'Y' here if you want kernel to support for Xilinx
> +  NWL PCIe controller. The controller can act as Root Port
> +  or End Point. The current option selection will only
> +  support root port enabling.
> +
>  config PCIE_DW
>   bool
>  
> diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
> index 140d66f..6a56df7 100644
> --- a/drivers/pci/host/Mak

Re: [PATCH v2 3/5] pinctrl: meson: enable GPIO IRQs

[Marc Zyngier]

On Mon, 23 Nov 2015 11:16:54 +0100
Carlo Caione  wrote:

> From: Carlo Caione 
> 
> On Meson8 and Meson8b SoCs there are 8 independent filtered GPIO
> interrupt modules that can be programmed to use any of the GPIOs in the
> chip as an interrupt source.
> 
> For each GPIO IRQ we have:
> 
> GPIOs --> [mux]--> [polarity]--> [filter]--> [edge select]--> GIC
> 
> The eight GPIO interrupts respond to mask/unmask/clear/etc.. just like
> any other interrupt in the chip. The difference for the GPIO interrupts
> is that they can be filtered and conditioned.
> 
> This patch adds support for the external GPIOs interrupts and enables
> them for Meson8 and Meson8b SoCs.
> 
> Signed-off-by: Carlo Caione 
> Signed-off-by: Beniamino Galvani 
> 
> ---

[...]

> + for (i = 0; i < pc->num_gic_irqs; i++) {
> + struct of_phandle_args oirq;
> +
> + of_irq_parse_one(node, i, &oirq);
> + irq_of_phandle_args_to_fwspec(&oirq, &pc->gic_irqs[i]);
> +
> + pc->irq_map[i] = IRQ_FREE;
> + }

The whole thing feels weird. Why do you need to keep a set of fwspecs?
All you need is a range of interrupts that would be conveniently
represented by a bitmap (assuming your interrupts space is a mostly
contiguous range).

Overall, this patch is quite hard to review. Can you please split the
GPIO management from the irqchip side?

Thanks,

M.
-- 
Jazz is not dead. It just smells funny.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 03/10] dt-bindings: interrupt-controllers: add description of SIC1 and SIC2

[Marc Zyngier]

On 20/11/15 17:52, Vladimir Zapolskiy wrote:
> Hi Rob,
> 
> On 20.11.2015 18:58, Rob Herring wrote:
>> On Fri, Nov 20, 2015 at 03:28:38AM +0200, Vladimir Zapolskiy wrote:
>>> NXP LPC32xx has three interrupt controllers, namely root Main
>>> Interrupt Controller (MIC) and two supplementary Sub Interrupt
>>> Controllers (SIC1 and SIC2), four interrupt outputs from SIC1 and SIC2
>>> are connected to MIC.
>>>
>>> Also the change describes two additional optional properties:
>>> * interrupt-controller-name - human readable name of an interrupt
>>>   controller,
>>
>> Why? compatible is human readable. If you don't like that, then put the 
>> string in the driver.
> 
> in runtime I'd like to differentiate various IRQ chips by name. Here for
> example I have one compatible "*-sic" and two actual IRQ chips SIC1 and
> SIC2. If I read /proc/interrupts or /sys/kernel/debug/irq_domain_mapping
> I would prefer to visualize interrupts from SIC1 and SIC2.
> 
> I understand that this property is not hardware specific, but there are
> plenty of similar properties like "label" etc. Probably renaming of the
> property may help?

You can always generate the name based on the probing order or the address.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 08/10] irqchip: add LPC32xx interrupt controller driver

[Marc Zyngier]

On 20/11/15 01:28, Vladimir Zapolskiy wrote:
> The change adds improved support of NXP LPC32xx MIC, SIC1 and SIC2
> interrupt controllers.
> 
> This is a list of new features in comparison to the legacy driver:
> * irq types are taken from device tree settings, no more need to
>   hardcode them,
> * old driver is based on irq_domain_add_legacy, which causes problems
>   with handling MIC hardware interrupt 0 produced by SIC1,
> * there is one driver for MIC, SIC1 and SIC2, no more need to handle
>   them separately, e.g. have two separate handlers for SIC1 and SIC2,
> * the driver does not have any dependencies on hardcoded register
>   offsets,
> * the driver is much simpler for comprehension and more maintainable,
> * SPARSE_IRQS option is supported.
> 
> The change disables compilation of a legacy driver found at
> arch/arm/mach-lpc32xx/irq.c, the file will be removed in a separate
> commit.
> 
> Signed-off-by: Vladimir Zapolskiy 
> ---
>  arch/arm/Kconfig|   2 +
>  arch/arm/mach-lpc32xx/Makefile  |   2 +-
>  arch/arm/mach-lpc32xx/phy3250.c |   1 -
>  drivers/irqchip/Makefile|   1 +
>  drivers/irqchip/irq-lpc32xx.c   | 227 
> 
>  5 files changed, 231 insertions(+), 2 deletions(-)
>  create mode 100644 drivers/irqchip/irq-lpc32xx.c
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 5cc11f1..1f2c03f 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -597,6 +597,8 @@ config ARCH_LPC32XX
>   select CPU_ARM926T
>   select GENERIC_CLOCKEVENTS
>   select HAVE_IDE
> + select MULTI_IRQ_HANDLER
> + select SPARSE_IRQ
>   select USE_OF
>   help
> Support for the NXP LPC32XX family of processors
> diff --git a/arch/arm/mach-lpc32xx/Makefile b/arch/arm/mach-lpc32xx/Makefile
> index b1023c0..2a28f645 100644
> --- a/arch/arm/mach-lpc32xx/Makefile
> +++ b/arch/arm/mach-lpc32xx/Makefile
> @@ -2,6 +2,6 @@
>  # Makefile for the linux kernel.
>  #
>  
> -obj-y:= irq.o common.o serial.o
> +obj-y:= common.o serial.o
>  obj-y+= pm.o suspend.o wakeup.o
>  obj-y+= phy3250.o
> diff --git a/arch/arm/mach-lpc32xx/phy3250.c b/arch/arm/mach-lpc32xx/phy3250.c
> index 60f3392..92e8574 100644
> --- a/arch/arm/mach-lpc32xx/phy3250.c
> +++ b/arch/arm/mach-lpc32xx/phy3250.c
> @@ -259,7 +259,6 @@ static const char *const lpc32xx_dt_compat[] __initconst 
> = {
>  DT_MACHINE_START(LPC32XX_DT, "LPC32XX SoC (Flattened Device Tree)")
>   .atag_offset= 0x100,
>   .map_io = lpc32xx_map_io,
> - .init_irq   = lpc32xx_init_irq,
>   .init_machine   = lpc3250_machine_init,
>   .dt_compat  = lpc32xx_dt_compat,
>   .restart= lpc23xx_restart,
> diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
> index 177f78f..21008a6 100644
> --- a/drivers/irqchip/Makefile
> +++ b/drivers/irqchip/Makefile
> @@ -4,6 +4,7 @@ obj-$(CONFIG_ARCH_BCM2835)+= irq-bcm2835.o
>  obj-$(CONFIG_ARCH_BCM2835)   += irq-bcm2836.o
>  obj-$(CONFIG_ARCH_EXYNOS)+= exynos-combiner.o
>  obj-$(CONFIG_ARCH_HIP04) += irq-hip04.o
> +obj-$(CONFIG_ARCH_LPC32XX)   += irq-lpc32xx.o
>  obj-$(CONFIG_ARCH_MMP)   += irq-mmp.o
>  obj-$(CONFIG_ARCH_MVEBU) += irq-armada-370-xp.o
>  obj-$(CONFIG_IRQ_MXS)+= irq-mxs.o
> diff --git a/drivers/irqchip/irq-lpc32xx.c b/drivers/irqchip/irq-lpc32xx.c
> new file mode 100644
> index 000..fcf281b
> --- /dev/null
> +++ b/drivers/irqchip/irq-lpc32xx.c
> @@ -0,0 +1,227 @@
> +/*
> + * Copyright 2015 Vladimir Zapolskiy 
> + *
> + * The code contained herein is licensed under the GNU General Public
> + * License. You may obtain a copy of the GNU General Public License
> + * Version 2 or later at the following locations:
> + *
> + * http://www.opensource.org/licenses/gpl-license.html
> + * http://www.gnu.org/copyleft/gpl.html
> + */
> +
> +#define pr_fmt(fmt) "%s: " fmt, __func__
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define LPC32XX_INTC_MASK0x00
> +#define LPC32XX_INTC_RAW 0x04
> +#define LPC32XX_INTC_STAT0x08
> +#define LPC32XX_INTC_POL 0x0C
> +#define LPC32XX_INTC_TYPE0x10
> +#define LPC32XX_INTC_FIQ 0x14
> +
> +#define IRQS_PER_CONTROLLER  32
> +
> +struct lpc32xx_irq_chip {
> + void __iomem *base;
> + struct irq_domain *domain;
> + struct irq_chip chip;
> +};
> +
> +static struct lpc32xx_irq_chip *lpc32xx_mic_data;
> +
> +static inline u32 lpc32xx_ic_read(struct irq_domain *id, u32 reg)
> +{
> + struct lpc32xx_irq_chip *ic = (struct lpc32xx_irq_chip *)id->host_data;

Nit: No need for a cast.

Also, it is a bit weird to use the domain as the anchor for your
chip-specific data. You end up following two pointers to get to it in
most cases (irq_data -> domain -> chip), which could

Re: [PATCH 2/2] irqchip: add support for Sigma Designs SMP86xx interrupt controller

[Marc Zyngier]

On 19/11/15 18:33, Mans Rullgard wrote:
> This adds support for the secondary interrupt controller used in Sigma
> Designs SMP86xx and SMP87xx chips.
> 
> Signed-off-by: Mans Rullgard 
> ---
>  drivers/irqchip/Kconfig  |   5 +
>  drivers/irqchip/Makefile |   1 +
>  drivers/irqchip/irq-tangox.c | 232 
> +++
>  3 files changed, 238 insertions(+)
>  create mode 100644 drivers/irqchip/irq-tangox.c
> 
> diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
> index 4d7294e..baf3345 100644
> --- a/drivers/irqchip/Kconfig
> +++ b/drivers/irqchip/Kconfig
> @@ -193,3 +193,8 @@ config IRQ_MXS
>   def_bool y if MACH_ASM9260 || ARCH_MXS
>   select IRQ_DOMAIN
>   select STMP_DEVICE
> +
> +config TANGOX_IRQ
> + bool
> + select IRQ_DOMAIN
> + select GENERIC_IRQ_CHIP
> diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
> index 177f78f..763715c 100644
> --- a/drivers/irqchip/Makefile
> +++ b/drivers/irqchip/Makefile
> @@ -55,3 +55,4 @@ obj-$(CONFIG_RENESAS_H8S_INTC)  += 
> irq-renesas-h8s.o
>  obj-$(CONFIG_ARCH_SA1100)+= irq-sa11x0.o
>  obj-$(CONFIG_INGENIC_IRQ)+= irq-ingenic.o
>  obj-$(CONFIG_IMX_GPCV2)  += irq-imx-gpcv2.o
> +obj-$(CONFIG_TANGOX_IRQ) += irq-tangox.o
> diff --git a/drivers/irqchip/irq-tangox.c b/drivers/irqchip/irq-tangox.c
> new file mode 100644
> index 000..630e2b5
> --- /dev/null
> +++ b/drivers/irqchip/irq-tangox.c
> @@ -0,0 +1,232 @@
> +/*
> + * Copyright (C) 2014 Mans Rullgard 
> + *
> + * This program is free software; you can redistribute  it and/or modify it
> + * under  the terms of  the GNU General  Public License as published by the
> + * Free Software Foundation;  either version 2 of the  License, or (at your
> + * option) any later version.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define IRQ0_CTL_BASE0x
> +#define IRQ1_CTL_BASE0x0100
> +#define EDGE_CTL_BASE0x0200
> +#define IRQ2_CTL_BASE0x0300
> +
> +#define IRQ_CTL_HI   0x18
> +#define EDGE_CTL_HI  0x20
> +
> +#define IRQ_STATUS   0x00
> +#define IRQ_RAWSTAT  0x04
> +#define IRQ_EN_SET   0x08
> +#define IRQ_EN_CLR   0x0c
> +#define IRQ_SOFT_SET 0x10
> +#define IRQ_SOFT_CLR 0x14
> +
> +#define EDGE_STATUS  0x00
> +#define EDGE_RAWSTAT 0x04
> +#define EDGE_CFG_RISE0x08
> +#define EDGE_CFG_FALL0x0c
> +#define EDGE_CFG_RISE_SET0x10
> +#define EDGE_CFG_RISE_CLR0x14
> +#define EDGE_CFG_FALL_SET0x18
> +#define EDGE_CFG_FALL_CLR0x1c
> +
> +struct tangox_irq_chip {
> + void __iomem *base;
> + unsigned long ctl;
> +};
> +
> +static inline u32 intc_readl(struct tangox_irq_chip *chip, int reg)
> +{
> + return readl_relaxed(chip->base + reg);
> +}
> +
> +static inline void intc_writel(struct tangox_irq_chip *chip, int reg, u32 
> val)
> +{
> + writel_relaxed(val, chip->base + reg);
> +}
> +
> +static void tangox_dispatch_irqs(struct irq_domain *dom, unsigned int status,
> +  int base)
> +{
> + unsigned int hwirq;
> + unsigned int virq;
> +
> + while (status) {
> + hwirq = __ffs(status);
> + virq = irq_find_mapping(dom, base + hwirq);

You may want to check virq in case you get interrupts from unexpected
sources (unlikely, but still).

> + generic_handle_irq(virq);
> + status &= ~BIT(hwirq);
> + }
> +}
> +
> +static void tangox_irq_handler(struct irq_desc *desc)
> +{
> + struct irq_domain *dom = irq_desc_get_handler_data(desc);
> + struct irq_chip *host_chip = irq_desc_get_chip(desc);
> + struct tangox_irq_chip *chip = dom->host_data;
> + unsigned int status_lo, status_hi;
> +
> + chained_irq_enter(host_chip, desc);
> +
> + status_lo = intc_readl(chip, chip->ctl + IRQ_STATUS);
> + status_hi = intc_readl(chip, chip->ctl + IRQ_CTL_HI + IRQ_STATUS);
> +
> + tangox_dispatch_irqs(dom, status_lo, 0);
> + tangox_dispatch_irqs(dom, status_hi, 32);
> +
> + chained_irq_exit(host_chip, desc);
> +}
> +
> +static int tangox_irq_set_type(struct irq_data *d, unsigned int flow_type)
> +{
> + struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
> + struct tangox_irq_chip *chip = gc->domain->host_data;
> + struct irq_chip_regs *regs = &gc->chip_types[0].regs;
> +
> + switch (flow_type & IRQ_TYPE_SENSE_MASK) {
> + case IRQ_TYPE_EDGE_RISING:
> + intc_writel(chip, regs->type + EDGE_CFG_RISE_SET, d->mask);
> + intc_writel(chip, regs->type + EDGE_CFG_FALL_CLR, d->mask);
> + break;
> +
> + case IRQ_TYPE_EDGE_FALLING:
> + intc_writel(chip, regs->type + EDGE_CFG_RISE_CLR, d->mask);
> + intc_write

Re: [PATCH v8] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller

[Marc Zyngier]

On 17/11/15 13:27, Bharat Kumar Gogada wrote:
>>
>> On Tue, 17 Nov 2015 04:59:39 +
>> Bharat Kumar Gogada  wrote:
>>
>>>> On 11/16/2015 7:14 AM, Marc Zyngier wrote:
>>>>> On 11/11/15 06:33, Bharat Kumar Gogada wrote:
>>>>>> Adding PCIe Root Port driver for Xilinx PCIe NWL bridge IP.
>>>>>>
>>>>>> Signed-off-by: Bharat Kumar Gogada 
>>>>>> Signed-off-by: Ravi Kiran Gummaluri 
>>>>>> ---
>>>>>> Added logic to allocate contiguous hwirq in nwl_irq_domain_alloc
>>>> function.
>>>>>> Moved MSI functionality to separate functions.
>>>>>> Changed error return values.
>>>>>> ---
>>>>>>   .../devicetree/bindings/pci/xilinx-nwl-pcie.txt|   68 ++
>>>>>>   drivers/pci/host/Kconfig   |   16 +-
>>>>>>   drivers/pci/host/Makefile  |1 +
>>>>>>   drivers/pci/host/pcie-xilinx-nwl.c | 1062
>>>> 
>>>>>>   4 files changed, 1144 insertions(+), 3 deletions(-)
>>>>>>   create mode 100644
>>>>>> Documentation/devicetree/bindings/pci/xilinx-nwl-
>>>> pcie.txt
>>>>>>   create mode 100644 drivers/pci/host/pcie-xilinx-nwl.c
>>>>>>
>>>>>
>>>>> [...]
>>>>>
>>>>>> +static int nwl_pcie_enable_msi(struct nwl_pcie *pcie, struct
>>>>>> +pci_bus
>>>>>> +*bus) {
>>>>>> +struct platform_device *pdev = to_platform_device(pcie-
>>> dev);
>>>>>> +struct nwl_msi *msi = &pcie->msi;
>>>>>> +unsigned long base;
>>>>>> +int ret;
>>>>>> +
>>>>>> +mutex_init(&msi->lock);
>>>>>> +
>>>>>> +/* Check for msii_present bit */
>>>>>> +ret = nwl_bridge_readl(pcie, I_MSII_CAPABILITIES) &
>> MSII_PRESENT;
>>>>>> +if (!ret) {
>>>>>> +dev_err(pcie->dev, "MSI not present\n");
>>>>>> +ret = -EIO;
>>>>>> +goto err;
>>>>>> +}
>>>>>> +
>>>>>> +/* Enable MSII */
>>>>>> +nwl_bridge_writel(pcie, nwl_bridge_readl(pcie,
>> I_MSII_CONTROL) |
>>>>>> +  MSII_ENABLE, I_MSII_CONTROL);
>>>>>> +
>>>>>> +/* Enable MSII status */
>>>>>> +nwl_bridge_writel(pcie, nwl_bridge_readl(pcie,
>> I_MSII_CONTROL) |
>>>>>> +  MSII_STATUS_ENABLE, I_MSII_CONTROL);
>>>>>> +
>>>>>> +/* setup AFI/FPCI range */
>>>>>> +msi->pages = __get_free_pages(GFP_KERNEL, 0);
>>>>>> +base = virt_to_phys((void *)msi->pages);
>>>>>> +nwl_bridge_writel(pcie, lower_32_bits(base),
>> I_MSII_BASE_LO);
>>>>>> +nwl_bridge_writel(pcie, upper_32_bits(base),
>> I_MSII_BASE_HI);
>>>>>
>>>>> BTW, you still haven't answered my question as to why you need to
>>>>> waste a page of memory here, and why putting a device address
>>>>> doesn't
>>>> work.
>>>>>
>>>>> As this is (to the best of my knowledge) the only driver doing so,
>>>>> I'd really like you to explain the rational behind this.
>>>>
>>>> Might not be the only driver doing so after I start sending out
>>>> patches for the iProc MSI support (soon), :)
>>>>
>>>> I'm not sure how it works for the Xilinx NWL controller, which
>>>> Bharat should be able to help to explain. But for the iProc MSI
>>>> controller, there's no device I/O memory reserved for MSI posted writes
>> in the ASIC.
>>>> Therefore one needs to reserve host memory for these writes.
>>>>>
>>>
>>> Our SoC doesn't reserve any memory for MSI, hence we need to assign a
>>> memory space for it out of RAM.
>>
>> Question to both of you: Does the write make it to memory? Or is it sampled
>> by the bridge and dropped?
>>
> No, write will not do any modification in memory, it is consumed by bridge.

Then you do not need to allocate memory at all. Use whatever memory you
already have. CC-ing Robin, as this may have interaction with the SMMU.

> 
>> What happens if you replace the page in RAM with a dummy address?
> What do you mean by dummy address ?

Any random (and suitably aligned) address. 0x0deadbeef000 for example.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller

[Marc Zyngier]

On Tue, 17 Nov 2015 04:59:39 +
Bharat Kumar Gogada  wrote:

> > On 11/16/2015 7:14 AM, Marc Zyngier wrote:
> > > On 11/11/15 06:33, Bharat Kumar Gogada wrote:
> > >> Adding PCIe Root Port driver for Xilinx PCIe NWL bridge IP.
> > >>
> > >> Signed-off-by: Bharat Kumar Gogada 
> > >> Signed-off-by: Ravi Kiran Gummaluri 
> > >> ---
> > >> Added logic to allocate contiguous hwirq in nwl_irq_domain_alloc
> > function.
> > >> Moved MSI functionality to separate functions.
> > >> Changed error return values.
> > >> ---
> > >>   .../devicetree/bindings/pci/xilinx-nwl-pcie.txt|   68 ++
> > >>   drivers/pci/host/Kconfig   |   16 +-
> > >>   drivers/pci/host/Makefile  |1 +
> > >>   drivers/pci/host/pcie-xilinx-nwl.c | 1062
> > 
> > >>   4 files changed, 1144 insertions(+), 3 deletions(-)
> > >>   create mode 100644 Documentation/devicetree/bindings/pci/xilinx-nwl-
> > pcie.txt
> > >>   create mode 100644 drivers/pci/host/pcie-xilinx-nwl.c
> > >>
> > >
> > > [...]
> > >
> > >> +static int nwl_pcie_enable_msi(struct nwl_pcie *pcie, struct pci_bus
> > >> +*bus) {
> > >> +struct platform_device *pdev = to_platform_device(pcie->dev);
> > >> +struct nwl_msi *msi = &pcie->msi;
> > >> +unsigned long base;
> > >> +int ret;
> > >> +
> > >> +mutex_init(&msi->lock);
> > >> +
> > >> +/* Check for msii_present bit */
> > >> +ret = nwl_bridge_readl(pcie, I_MSII_CAPABILITIES) & 
> > >> MSII_PRESENT;
> > >> +if (!ret) {
> > >> +dev_err(pcie->dev, "MSI not present\n");
> > >> +ret = -EIO;
> > >> +goto err;
> > >> +}
> > >> +
> > >> +/* Enable MSII */
> > >> +nwl_bridge_writel(pcie, nwl_bridge_readl(pcie, I_MSII_CONTROL) |
> > >> +  MSII_ENABLE, I_MSII_CONTROL);
> > >> +
> > >> +/* Enable MSII status */
> > >> +nwl_bridge_writel(pcie, nwl_bridge_readl(pcie, I_MSII_CONTROL) |
> > >> +  MSII_STATUS_ENABLE, I_MSII_CONTROL);
> > >> +
> > >> +/* setup AFI/FPCI range */
> > >> +msi->pages = __get_free_pages(GFP_KERNEL, 0);
> > >> +base = virt_to_phys((void *)msi->pages);
> > >> +nwl_bridge_writel(pcie, lower_32_bits(base), I_MSII_BASE_LO);
> > >> +nwl_bridge_writel(pcie, upper_32_bits(base), I_MSII_BASE_HI);
> > >
> > > BTW, you still haven't answered my question as to why you need to
> > > waste a page of memory here, and why putting a device address doesn't
> > work.
> > >
> > > As this is (to the best of my knowledge) the only driver doing so, I'd
> > > really like you to explain the rational behind this.
> > 
> > Might not be the only driver doing so after I start sending out patches for 
> > the
> > iProc MSI support (soon), :)
> > 
> > I'm not sure how it works for the Xilinx NWL controller, which Bharat should
> > be able to help to explain. But for the iProc MSI controller, there's no 
> > device
> > I/O memory reserved for MSI posted writes in the ASIC.
> > Therefore one needs to reserve host memory for these writes.
> > >
> 
> Our SoC doesn't reserve any memory for MSI, hence we need to assign a
> memory space for it out of RAM.

Question to both of you: Does the write make it to memory? Or is it
sampled by the bridge and dropped?

What happens if you replace the page in RAM with a dummy address?

Thanks,

M.
-- 
Jazz is not dead. It just smells funny.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller

[Marc Zyngier]

On 11/11/15 06:33, Bharat Kumar Gogada wrote:
> Adding PCIe Root Port driver for Xilinx PCIe NWL bridge IP.
> 
> Signed-off-by: Bharat Kumar Gogada 
> Signed-off-by: Ravi Kiran Gummaluri 
> ---
> Added logic to allocate contiguous hwirq in nwl_irq_domain_alloc function.
> Moved MSI functionality to separate functions.
> Changed error return values.
> ---
>  .../devicetree/bindings/pci/xilinx-nwl-pcie.txt|   68 ++
>  drivers/pci/host/Kconfig   |   16 +-
>  drivers/pci/host/Makefile  |1 +
>  drivers/pci/host/pcie-xilinx-nwl.c | 1062 
> 
>  4 files changed, 1144 insertions(+), 3 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
>  create mode 100644 drivers/pci/host/pcie-xilinx-nwl.c
> 

[...]

> +static int nwl_pcie_enable_msi(struct nwl_pcie *pcie, struct pci_bus *bus)
> +{
> + struct platform_device *pdev = to_platform_device(pcie->dev);
> + struct nwl_msi *msi = &pcie->msi;
> + unsigned long base;
> + int ret;
> +
> + mutex_init(&msi->lock);
> +
> + /* Check for msii_present bit */
> + ret = nwl_bridge_readl(pcie, I_MSII_CAPABILITIES) & MSII_PRESENT;
> + if (!ret) {
> + dev_err(pcie->dev, "MSI not present\n");
> + ret = -EIO;
> + goto err;
> + }
> +
> + /* Enable MSII */
> + nwl_bridge_writel(pcie, nwl_bridge_readl(pcie, I_MSII_CONTROL) |
> +   MSII_ENABLE, I_MSII_CONTROL);
> +
> + /* Enable MSII status */
> + nwl_bridge_writel(pcie, nwl_bridge_readl(pcie, I_MSII_CONTROL) |
> +   MSII_STATUS_ENABLE, I_MSII_CONTROL);
> +
> + /* setup AFI/FPCI range */
> + msi->pages = __get_free_pages(GFP_KERNEL, 0);
> + base = virt_to_phys((void *)msi->pages);
> + nwl_bridge_writel(pcie, lower_32_bits(base), I_MSII_BASE_LO);
> + nwl_bridge_writel(pcie, upper_32_bits(base), I_MSII_BASE_HI);

BTW, you still haven't answered my question as to why you need to waste
a page of memory here, and why putting a device address doesn't work.

As this is (to the best of my knowledge) the only driver doing so, I'd
really like you to explain the rational behind this.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller

[Marc Zyngier]

On Wed, 11 Nov 2015 12:03:39 +0530
Bharat Kumar Gogada  wrote:

> Adding PCIe Root Port driver for Xilinx PCIe NWL bridge IP.
> 
> Signed-off-by: Bharat Kumar Gogada 
> Signed-off-by: Ravi Kiran Gummaluri 
> ---
> Added logic to allocate contiguous hwirq in nwl_irq_domain_alloc function.
> Moved MSI functionality to separate functions.
> Changed error return values.
> ---
>  .../devicetree/bindings/pci/xilinx-nwl-pcie.txt|   68 ++
>  drivers/pci/host/Kconfig   |   16 +-
>  drivers/pci/host/Makefile  |1 +
>  drivers/pci/host/pcie-xilinx-nwl.c | 1062 
> 
>  4 files changed, 1144 insertions(+), 3 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
>  create mode 100644 drivers/pci/host/pcie-xilinx-nwl.c
> 
> diff --git a/drivers/pci/host/pcie-xilinx-nwl.c 
> b/drivers/pci/host/pcie-xilinx-nwl.c
> new file mode 100644
> index 000..8bc509c
> --- /dev/null
> +++ b/drivers/pci/host/pcie-xilinx-nwl.c

[...]

> +static struct msi_domain_info nwl_msi_domain_info = {
> + .flags = (MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS |
> +   MSI_FLAG_MULTI_PCI_MSI),

Given that you claim to support multi-MSI...

[...]

> +static int nwl_irq_domain_alloc(struct irq_domain *domain, unsigned int virq,
> + unsigned int nr_irqs, void *args)
> +{
> + struct nwl_pcie *pcie = domain->host_data;
> + struct nwl_msi *msi = &pcie->msi;
> + unsigned long bit;
> + int i;
> +
> + mutex_lock(&msi->lock);
> + for (i = 0; i < nr_irqs; i++) {
> + bit = find_first_zero_bit(msi->used, INT_PCI_MSI_NR);
> + if (bit < INT_PCI_MSI_NR)
> + set_bit(bit, msi->used);
> + else
> + bit = -ENOSPC;
> +
> + if (bit < 0) {
> + mutex_unlock(&msi->lock);
> + return bit;
> + }
> +
> + irq_domain_set_info(domain, virq, bit, &nwl_irq_chip,
> + domain->host_data, handle_simple_irq,
> + NULL, NULL);
> + virq = virq + 1;
> + }

I really don't see how this allocator guarantees that all hwirqs are
contiguous. I already mentioned this when reviewing v7, and you still
haven't got it right. So either you allocate *contiguous* hwirqs in an
atomic fashion, or you drop support for multi-MSI.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller

[Marc Zyngier]

On 04/11/15 12:30, Bharat Kumar Gogada wrote:
>>
 Also, you still lack support for MSI-X (which would come for free...).
>>>
>>> We don't support MSI-X in root port mode.
>>
>> I don't believe you. If you support single MSI, you support MSI-X (because
>> that's mostly a property of the endpoint).
> 
> In our architecture specification MSI-X is unsupported for Root Port.

I still can't believe it, but in the end, that's your own problem.

> + .chip = &nwl_msi_irq_chip,
> +};
> +#endif
> +
> +
> + /* setup AFI/FPCI range */
> + msi->pages = __get_free_pages(GFP_KERNEL, 0);
> + base = virt_to_phys((void *)msi->pages);
> + nwl_bridge_writel(pcie, lower_32_bits(base), I_MSII_BASE_LO);
> + nwl_bridge_writel(pcie, upper_32_bits(base), I_MSII_BASE_HI);

 I just read this, and I'm puzzled. Actually, puzzled is an
 understatement. Why on Earth do you need to give RAM to your MSI
>> HW?
 This should be a device, not RAM. By the look of it, this could be
 absolutely anything. Are you sure you have to supply RAM here?

>>> This is required in our hardware, so that bridge identifies incoming MWr as
>> MSI.
>>
>> I'm asking why this has to be RAM. What is the actual requirement?
> 
> We are allocating RAM for MSI (which is expected) and assigning this address 
> to msi->pages
> this is what EP MSI capability will be programmed with.
> For the bridge to detect an incoming MWr from EP as MSI, hardware needs to 
> know MSI address
> so the same address is programmed in the hardware register for comparison 
> purpose.
> It is the actual requirement from hardware.

I understand that you need to provide an address for the bridge to
match. I'm asking why this has to be RAM as opposed to any other device
address. This seems to be a unique requirement (nobody else does that),
and I'd like to understand why there is this requirement.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller

[Marc Zyngier]

On 04/11/15 07:54, Bharat Kumar Gogada wrote:
>>> Without #ifdefs if we compile driver for legacy, MSI structures will not be
>> available and we get compile time error.
>>
>> Sorry for nitpicking but at least can we use elegant version of #ifdefs 
>> .i.e. #if
>> IS_ENABLED() here ?
>>
> Since IS_ENABLED() is checked at runtime, compile time error would come for 
> legacy.

You're seriously misguided. IS_ENABLED() is specifically designed *not*
to be checked at runtime, but instead to use the compiler optimization
phase to get rid of code sections at compile time.

M.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller

[Marc Zyngier]

On 04/11/15 06:38, Bharat Kumar Gogada wrote:
>>> +static struct msi_domain_info nwl_msi_domain_info = {
>>> +   .flags = (MSI_FLAG_USE_DEF_DOM_OPS |
>> MSI_FLAG_USE_DEF_CHIP_OPS |
>>> + MSI_FLAG_MULTI_PCI_MSI),
>>
>> If you're supporting multi-MSI, how do you ensure that all hwirqs are
>> contiguous as required by the spec? Clearly, your allocator doesn't provide
>> this guarantee.
>>
> Oh ok, then how can we know if one EP is requesting for multiple irq's, 
> because in pci_enable_msi_range,
>  it does do while loop according to msi_capability_init return value 
> which in turn requests for multiple irq's. Is there any way to find out when 
> single EP requesting for multiple MSI?

Please read what I've written: hwirqs *must* be contiguous for
multi-MSI. If the device requests 4 MSIs, they *must* be in the [x,x+3]
range. Your allocator only allocates one interrupt at time (ignoring the
nr_irqs parameter).

You shouldn't try to find what the device does, that's irrelevant at
that level.

>> Also, you still lack support for MSI-X (which would come for free...).
> 
> We don't support MSI-X in root port mode.

I don't believe you. If you support single MSI, you support MSI-X
(because that's mostly a property of the endpoint).

>>> +   .chip = &nwl_msi_irq_chip,
>>> +};
>>> +#endif
>>> +
>>> +   irq_domain_remove(pcie->legacy_irq_domain);
>>> +
>>> +#ifdef CONFIG_PCI_MSI
>>> +   irq_set_chained_handler_and_data(msi->irq_msi0, NULL, NULL);
>>> +   irq_set_chained_handler_and_data(msi->irq_msi1, NULL, NULL);
>>> +
>>> +   irq_domain_remove(msi->msi_domain);
>>> +   irq_domain_remove(msi->dev_domain);
>>> +#endif
>>> +
>>> +}
>>
>> Remove these #ifdefs. You can test the validity of these fields before 
>> calling
>> the various functions. You can also move this to a separate function.
> 
> Without #ifdefs if we compile driver for legacy, MSI structures will not be 
> available and we get compile time error.

Legacy? Legacy interrupts? The msi structure is still there, you've
embedded it in your pcie structure. Let me spell it out for you:

static void nwl_msi_free_domain(struct nwl_pcie *pcie)
{
struct nwl_msi *msi = &pcie->msi;

if (msi->irq_msi0)
irq_set_chained_handler_and_data(msi->irq_msi0, NULL, NULL);
if (msi->irq_msi1)
irq_set_chained_handler_and_data(msi->irq_msi1, NULL, NULL);

if (msi->msi_domain)
irq_domain_remove(msi->msi_domain);
if (msi->dev_domain)
irq_domain_remove(msi->dev_domain);
}

static void nwl_pcie_free_irq_domain(struct nwl_pcie *pcie)
{
int i;
u32 irq;

for (i = 0; i < 4; i++) {
irq = irq_find_mapping(pcie->legacy_irq_domain, i + 1);
if (irq > 0)
irq_dispose_mapping(irq);
}

irq_domain_remove(pcie->legacy_irq_domain);

nwl_msi_free_domain(pcie);
}

>>> +
>>> +   /* setup AFI/FPCI range */
>>> +   msi->pages = __get_free_pages(GFP_KERNEL, 0);
>>> +   base = virt_to_phys((void *)msi->pages);
>>> +   nwl_bridge_writel(pcie, lower_32_bits(base), I_MSII_BASE_LO);
>>> +   nwl_bridge_writel(pcie, upper_32_bits(base), I_MSII_BASE_HI);
>>
>> I just read this, and I'm puzzled. Actually, puzzled is an understatement. 
>> Why
>> on Earth do you need to give RAM to your MSI HW?
>> This should be a device, not RAM. By the look of it, this could be absolutely
>> anything. Are you sure you have to supply RAM here?
>>
> This is required in our hardware, so that bridge identifies incoming MWr as 
> MSI.

I'm asking why this has to be RAM. What is the actual requirement?

M.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller

[Marc Zyngier]

On 03/11/15 15:23, Bharat Kumar Gogada wrote:
> Adding PCIe Root Port driver for Xilinx PCIe NWL bridge IP.
> 
> Signed-off-by: Bharat Kumar Gogada 
> Signed-off-by: Ravi Kiran Gummaluri 
> ---
> Removed msi_controller and added irq_domian for MSI domain hierarchy.
> Modified code for filling MSI address in struct msg.
> Added check for hwirq before passing it to irq_domain_set_info.
> ---
>  .../devicetree/bindings/pci/xilinx-nwl-pcie.txt|   68 ++
>  drivers/pci/host/Kconfig   |   10 +
>  drivers/pci/host/Makefile  |1 +
>  drivers/pci/host/pcie-xilinx-nwl.c | 1053 
> 
>  4 files changed, 1132 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
>  create mode 100644 drivers/pci/host/pcie-xilinx-nwl.c

[...]

> +#ifdef CONFIG_PCI_MSI
> +static struct irq_chip nwl_msi_irq_chip = {
> + .name = "nwl_pcie:msi",
> + .irq_enable = unmask_msi_irq,
> + .irq_disable = mask_msi_irq,
> + .irq_mask = mask_msi_irq,
> + .irq_unmask = unmask_msi_irq,
> +
> +};
> +
> +static struct msi_domain_info nwl_msi_domain_info = {
> + .flags = (MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS |
> +   MSI_FLAG_MULTI_PCI_MSI),

If you're supporting multi-MSI, how do you ensure that all hwirqs are
contiguous as required by the spec? Clearly, your allocator doesn't
provide this guarantee.

Also, you still lack support for MSI-X (which would come for free...).

> + .chip = &nwl_msi_irq_chip,
> +};
> +#endif
> +
> +static void nwl_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
> +{
> + struct nwl_pcie *pcie = irq_data_get_irq_chip_data(data);
> + struct nwl_msi *msi = &pcie->msi;
> + phys_addr_t msi_addr = virt_to_phys((void *)msi->pages);
> +
> + msg->address_lo = lower_32_bits(msi_addr);
> + msg->address_hi = upper_32_bits(msi_addr);
> + msg->data = data->hwirq;
> +}
> +
> +static int nwl_msi_set_affinity(struct irq_data *irq_data,
> + const struct cpumask *mask, bool force)
> +{
> + return -EINVAL;
> +}
> +
> +static struct irq_chip nwl_irq_chip = {
> + .name = "Xilinx MSI",
> + .irq_compose_msi_msg = nwl_compose_msi_msg,
> + .irq_set_affinity = nwl_msi_set_affinity,
> +};
> +
> +static int nwl_irq_domain_alloc(struct irq_domain *domain, unsigned int virq,
> + unsigned int nr_irqs, void *args)
> +{
> + struct nwl_pcie *pcie = domain->host_data;
> + struct nwl_msi *msi = &pcie->msi;
> + unsigned long bit;
> +
> + mutex_lock(&msi->lock);
> + bit = find_first_zero_bit(msi->used, INT_PCI_MSI_NR);
> + if (bit < INT_PCI_MSI_NR)
> + set_bit(bit, msi->used);
> + else
> + bit = -ENOSPC;
> +
> + mutex_unlock(&msi->lock);
> +
> + if (bit < 0)
> + return bit;
> +
> + irq_domain_set_info(domain, virq, bit, &nwl_irq_chip,
> + domain->host_data, handle_simple_irq,
> + NULL, NULL);
> + return 0;
> +}
> +
> +static void nwl_irq_domain_free(struct irq_domain *domain, unsigned int virq,
> + unsigned int nr_irqs)
> +{
> + struct irq_data *data = irq_domain_get_irq_data(domain, virq);
> + struct nwl_pcie *pcie = irq_data_get_irq_chip_data(data);
> + struct nwl_msi *msi = &pcie->msi;
> +
> + mutex_lock(&msi->lock);
> + if (!test_bit(data->hwirq, msi->used))
> + dev_err(pcie->dev, "freeing unused MSI %lu\n", data->hwirq);
> + else
> + clear_bit(data->hwirq, msi->used);
> +
> + mutex_unlock(&msi->lock);
> +}
> +
> +static const struct irq_domain_ops dev_msi_domain_ops = {
> + .alloc  = nwl_irq_domain_alloc,
> + .free   = nwl_irq_domain_free,
> +};
> +
> +static void nwl_pcie_free_irq_domain(struct nwl_pcie *pcie)
> +{
> + int i;
> + u32 irq;
> +
> +#ifdef CONFIG_PCI_MSI
> + struct nwl_msi *msi = &pcie->msi;
> +#endif
> +
> + for (i = 0; i < 4; i++) {
> + irq = irq_find_mapping(pcie->legacy_irq_domain, i + 1);
> + if (irq > 0)
> + irq_dispose_mapping(irq);
> + }
> +
> + irq_domain_remove(pcie->legacy_irq_domain);
> +
> +#ifdef CONFIG_PCI_MSI
> + irq_set_chained_handler_and_data(msi->irq_msi0, NULL, NULL);
> + irq_set_chained_handler_and_data(msi->irq_msi1, NULL, NULL);
> +
> + irq_domain_remove(msi->msi_domain);
> + irq_domain_remove(msi->dev_domain);
> +#endif
> +
> +}

Remove these #ifdefs. You can test the validity of these fields before
calling the various functions. You can also move this to a separate
function.

> +
> +static int nwl_pcie_init_irq_domain(struct nwl_pcie *pcie)
> +{
> + struct device_node *node = pcie->dev->of_node;
> + struct device_node *legacy_intc_node;
> +
> +#ifdef CONFIG_PCI_MSI
> + struct nwl_msi *msi = &pcie->msi;
> +#endif
> +
> + legacy

Re: [PATCH v6] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller

[Marc Zyngier]

On Fri, 30 Oct 2015 17:47:08 +0530
Bharat Kumar Gogada  wrote:

> Adding PCIe Root Port driver for Xilinx PCIe NWL bridge IP.
> 
> Signed-off-by: Bharat Kumar Gogada 
> Signed-off-by: Ravi Kiran Gummaluri 
> ---
> Changes for v6:
> Removed repetitive code for msi handlers.
> Corrected typo mistakes in device tree documentation.
> ---
>  .../devicetree/bindings/pci/xilinx-nwl-pcie.txt|   68 ++
>  drivers/pci/host/Kconfig   |9 +
>  drivers/pci/host/Makefile  |1 +
>  drivers/pci/host/pcie-xilinx-nwl.c | 1025 
> 
>  4 files changed, 1103 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
>  create mode 100644 drivers/pci/host/pcie-xilinx-nwl.c
> 

[...]

> diff --git a/drivers/pci/host/pcie-xilinx-nwl.c 
> b/drivers/pci/host/pcie-xilinx-nwl.c
> new file mode 100644
> index 000..bee1bee
> --- /dev/null
> +++ b/drivers/pci/host/pcie-xilinx-nwl.c
> @@ -0,0 +1,1025 @@
> +/*
> + * PCIe host controller driver for NWL PCIe Bridge
> + * Based on pcie-xilinx.c, pci-tegra.c
> + *
> + * (C) Copyright 2014 - 2015, Xilinx, Inc.
> + *
> + * This program is free software: you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation, either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

[...]

> +
> +struct nwl_msi { /* MSI information */
> + struct msi_controller msi_chip; /* MSI domain */

NAK.

I've mentioned it clearly when I first reviewed this patch: There
should be no new msi_controller structure added, and definitely none
for arm64.

So please get rid of this cruft. Select CONFIG_PCI_MSI_IRQ_DOMAIN, and
everything will be taken care of for you. No populating of bus->msi,
just have your own domain field for the MSI domain.

> + DECLARE_BITMAP(used, INT_PCI_MSI_NR);   /* used: Declare Bitmap
> + for MSI */
> + struct irq_domain *dev_domain;
> + unsigned long pages;/* pages: MSI pages */
> + struct mutex lock;  /* protect used variable */
> + int irq_msi0;
> + int irq_msi1;
> +};

[...]

> +#ifdef CONFIG_PCI_MSI
> +static struct irq_chip nwl_msi_irq_chip = {
> + .name = "nwl_pcie:msi",
> + .irq_enable = unmask_msi_irq,
> + .irq_disable = mask_msi_irq,
> + .irq_mask = mask_msi_irq,
> + .irq_unmask = unmask_msi_irq,
> +
> +};
> +
> +static struct msi_domain_info nwl_msi_domain_info = {
> + .flags = (MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS),

So you cannot support MSI-X? Why? The spec seems to say otherwise  (it
also says you could support multi-MSI, but I'm not sure it is worth the
hassle).

> + .chip = &nwl_msi_irq_chip,
> +};
> +#endif
> +
> +static void nwl_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
> +{
> + struct nwl_pcie *pcie = irq_data_get_irq_chip_data(data);
> + struct nwl_msi *msi = &pcie->msi;
> +
> + msg->address_lo = virt_to_phys((void *)msi->pages);
> + msg->address_hi = 0;

Do you know for sure that this page will never be above 4GB? Given
that this IP can be synthesized, I seriously doubt this is the case.
Please properly populate both fields.

> + msg->data = data->hwirq;
> +}
> +
> +static int nwl_msi_set_affinity(struct irq_data *irq_data,
> + const struct cpumask *mask, bool force)
> +{
> + return -EINVAL;
> +}
> +
> +static struct irq_chip nwl_irq_chip = {
> + .name = "Xilinx MSI",
> + .irq_compose_msi_msg = nwl_compose_msi_msg,
> + .irq_set_affinity = nwl_msi_set_affinity,
> +};
> +
> +static int nwl_irq_domain_alloc(struct irq_domain *domain, unsigned int virq,
> + unsigned int nr_irqs, void *args)
> +{
> + struct nwl_pcie *pcie = domain->host_data;
> + struct nwl_msi *msi = &pcie->msi;
> + unsigned long bit;
> +
> + mutex_lock(&msi->lock);
> + bit = find_first_zero_bit(msi->used, INT_PCI_MSI_NR);
> + if (bit < INT_PCI_MSI_NR)
> + set_bit(bit, msi->used);
> + else
> + bit = -ENOSPC;
> +
> + mutex_unlock(&msi->lock);
> + irq_domain_set_info(domain, virq, bit, &nwl_irq_chip,
> + domain->host_data, handle_simple_irq,
> + NULL, NULL);

I'm sure irq_domain_set_info will enjoy being passed -ENOSPC as a hwirq.

> + return 0;

And let's ignore the error case, they are usually overrated.

> +}

I've stopped here (after all, I'm still on holiday).

Thanks,

M.
-- 
Without deviation from the norm, progress is not possible.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
th

Re: [PATCH v2 1/3] gpio: xgene: add support to configure GPIO line as input, output or external IRQ pin

[Marc Zyngier]

On Fri, 30 Oct 2015 12:41:03 +0700
Quan Nguyen  wrote:

> Forgive me for not turn on plain text mode my last email.
> 
> Hi Linus,
> 
> My name is Quan Nguyen, I'm working with Y Vo on this patch.
> 
> Allow me to explain as below:
> 
> In current implementation, gic irq resources were used in both sbgpio
> and gpios-key nodes, and this causes confusion.
> To avoid this, we introduce sbgpio driver as interrupt controller, it
> now provides 6 external irq pins mapped from gpio line 8-13. The
> gpio-keys node now uses sbgpio irq resources instead.
> 
> -- Quan
> 
> 
> On Thu, Oct 29, 2015 at 8:28 PM, Linus Walleij  
> wrote:
> > On Mon, Oct 26, 2015 at 7:49 AM, Y Vo  wrote:
> >
> >> Add support to configure GPIO line as input, output or external IRQ pin.
> >>
> >> Signed-off-by: Y Vo 
> >
> > As I will say again, this description is too terse, add lots of information
> > on how IRQs work on this controller please. I get confused.
> 
> How about:
> +
> Enable X-Gene standby GPIO driver as interrupt controller, it provides
> 6 external irq pins via gpio line 8-13.
> +
> >
> > (...)
> >
> >> +#define XGENE_GPIO8_HWIRQ  0x48
> >> +#define XGENE_GPIO8_IDX8
> > (...)
> >> +#define XGENE_HWIRQ_TO_GPIO(hwirq) ((hwirq) + XGENE_GPIO8_IDX)
> >> +#define XGENE_GPIO_TO_HWIRQ(gpio)  ((gpio) - XGENE_GPIO8_IDX)
> >> +#define GIC_IRQ_TO_GPIO_IRQ(hwirq) ((hwirq) - XGENE_GPIO8_HWIRQ)
> >> +#define GPIO_IRQ_TO_GIC_IRQ(hwirq) ((hwirq) + XGENE_GPIO8_HWIRQ)
> >
> > I'm a bit uneasy about this, maybe I just don't get it.
> >
> > What is this indexing into "GIC IRQ" that is starting to happen
> > here?
> >
> > The GIC (if that is drivers/irqchip/irq-gic.c) has a totally dynamic IRQ
> > translation and the Linux IRQs it is using may change. I am worried
> > that there is some reliance here on Linux IRQ having certain numbers
> > because there is certainly no ABI like that.
> >
> > Is this 0x48 really an index into the *hardware* offset in the GIC?
> >
> > And if it is: why are we not getting this hardware information from the
> > device tree like all other interrupt numbers and offsets?
> >
> > I'm worried about this.
> 
> The SPI40(0x48) through SPI45(0x4D) from GIC are mapped as external
> IRQ0 - IRQ5 in this GPIO block, so it is hardware offset not mapped
> irq number.
> 
> Below is detail:
> 
> + GIC: SPI40 (hwirq=0x48)  <=> SB-GPIO: (hwirq=0) (gpio line 8)
> + GIC: SPI41 (hwirq=0x49)  <=> SB-GPIO: (hwirq=1) (gpio line 9)
> ...
> + GIC: SPI45 (hwirq=0x4D)  <=> SB-GPIO: (hwirq=5) (gpio line 13)
> 
> These defines are to help translating between Gic hardware irq and
> SBGPIO hardware irq number.
> 
> >
> >> -   u32 *irq;
> >> +   void __iomem *regs;
> >> +   struct irq_domain *gic_domain;
> >> +   struct irq_domain *irq_domain;
> >
> > And there is some secondary gic_domain here, which is confusing
> > since the GIC does have an IRQ domain too.
> >
> > I think I want a clear explanation to how this GPIO controller interacts
> > with the GIC, and I want it to be part of the patch, as comments in the
> > code and in the commit message (which is way too small for a complex
> > patch like this).
> >
> > Otherwise I have no chance to understand what is really going on here.
> 
> SBGPIO currently is not capable to mask/unmask/... irqs, so these will
> rely on the parent (GIC) instead. To do so, we need keep a parent
> domain reference here "struct irq_domain *gic_domain" so we can find
> correspond parent irq in runtime.

All this only means one thing: this should be implemented as a
hierarchical domain, just like any other "random widget stacked on top
of the GIC". Digging into the internals of the GIC driver is not
acceptable anymore, and this patch is just horrible.

There is plenty of examples in the tree for you to look at and rewrite
that code using the abstractions that are already in place.

In the meantime, I am NAKing this patch. Please include the irqchip
maintainers in the next iteration of this series.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/4] arm64: dts: add .dts for GICv3 Foundation model

[Marc Zyngier]

On 13/10/15 10:37, Andre Przywara wrote:
> The ARMv8 Foundation model sports a command line parameter to use
> a GICv3 emulation instead of the default GICv2 interrupt controller.
> Add a new .dts file which reuses most of the definitions of the
> existing model while just adding the required properties for the
> GICv3 node.
> This allows the public Foundation model to run with a GICv3.
> 
> Signed-off-by: Andre Przywara 
> ---
>  arch/arm64/boot/dts/arm/Makefile|  2 +-
>  arch/arm64/boot/dts/arm/foundation-v8-gicv3.dts | 30 
> +
>  2 files changed, 31 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm64/boot/dts/arm/foundation-v8-gicv3.dts
> 
> diff --git a/arch/arm64/boot/dts/arm/Makefile 
> b/arch/arm64/boot/dts/arm/Makefile
> index bb3c072..46d342d 100644
> --- a/arch/arm64/boot/dts/arm/Makefile
> +++ b/arch/arm64/boot/dts/arm/Makefile
> @@ -1,4 +1,4 @@
> -dtb-$(CONFIG_ARCH_VEXPRESS) += foundation-v8.dtb
> +dtb-$(CONFIG_ARCH_VEXPRESS) += foundation-v8.dtb foundation-v8-gicv3.dtb
>  dtb-$(CONFIG_ARCH_VEXPRESS) += juno.dtb juno-r1.dtb
>  dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb
>  dtb-$(CONFIG_ARCH_VEXPRESS) += vexpress-v2f-1xv7-ca53x2.dtb
> diff --git a/arch/arm64/boot/dts/arm/foundation-v8-gicv3.dts 
> b/arch/arm64/boot/dts/arm/foundation-v8-gicv3.dts
> new file mode 100644
> index 000..ecdbe98
> --- /dev/null
> +++ b/arch/arm64/boot/dts/arm/foundation-v8-gicv3.dts
> @@ -0,0 +1,30 @@
> +/*
> + * ARM Ltd.
> + *
> + * ARMv8 Foundation model DTS (GICv3 configuration)
> + */
> +
> +#include "foundation-v8.dtsi"
> +
> +/ {
> + gic: interrupt-controller@2f00 {
> + compatible = "arm,gic-v3";
> + #interrupt-cells = <3>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> + interrupt-controller;
> + reg =   <0x0 0x2f00 0x0 0x1>,
> + <0x0 0x2f10 0x0 0x20>,
> + <0x0 0x2c00 0x0 0x2000>,
> + <0x0 0x2c01 0x0 0x2000>,
> + <0x0 0x2c02f000 0x0 0x2000>;
> + interrupts = <1 9 0xf04>;
> +
> + its: its@2f02 {
> + compatible = "arm,gic-v3-its";
> + msi-controller;
> + reg = <0x0 0x2f02 0x0 0x2>;
> + };
> + };
> +};
> 

Do you know if the ITS has any modelled device connected to it? Not very
useful on its own, but you may want to use it as a way to inject IPIs
(just kidding, don't do that!).

M.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/4] arm64: dts: Foundation model: increate GICC region to allow EOImode=1

[Marc Zyngier]

Hi Andre,

s/increate/increase size of/ in the subject line

On 13/10/15 10:37, Andre Przywara wrote:
> Recent commits made the GIC driver use EOImode=1 for all GICs
> that advertise the proper GICC region size.

Well, it is not so much that the kernel uses EOImode=1, but the fact
that the model has a GICv2 implementation, hence a 8kB GICC region.

> To let the model benefit from the blessings of that mode, increase
> the GICC region to its actual size of 8K.
> 
> Signed-off-by: Andre Przywara 
> ---
>  arch/arm64/boot/dts/arm/foundation-v8.dts | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/arm/foundation-v8.dts 
> b/arch/arm64/boot/dts/arm/foundation-v8.dts
> index 3c5595d..57ad9fe 100644
> --- a/arch/arm64/boot/dts/arm/foundation-v8.dts
> +++ b/arch/arm64/boot/dts/arm/foundation-v8.dts
> @@ -78,7 +78,7 @@
>   #address-cells = <2>;
>   interrupt-controller;
>   reg = <0x0 0x2c001000 0 0x1000>,
> -   <0x0 0x2c002000 0 0x1000>,
> +   <0x0 0x2c002000 0 0x2000>,
> <0x0 0x2c004000 0 0x2000>,
> <0x0 0x2c006000 0 0x2000>;
>   interrupts = <1 9 0xf04>;
> 

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller

[Marc Zyngier]

On 09/10/15 14:47, Bharat Kumar Gogada wrote:
>> Hi Bharat,
 Adding PCIe Root Port driver for Xilinx PCIe NWL bridge IP.
>>> 
>>> +/* SSPL ERROR */ +#define SLVERR   0x02 
>>> +#define DECERR
>>> 0x03 + +struct nwl_msi {/* struct nwl_msi - MSI 
>>> information
>> */
>>> +   struct msi_controller chip; /* chip: MSI controller */
>> 
>> We're moving away from msi_controller altogether, as the kernel now
>> has all the necessary infrastructure to do this properly.
>> 
>> Please convert this driver to msi domains (see
>> drivers/pci/host/pci-xgene- msi.c or the gic-v2m driver as examples
>> of how this is being done).
> 
> As suggested I have gone through the code in pci-gene-msi.c for msi
> domains, and have gone through IRQ Domain documentation. I mainly
> observe when we have more than one interrupt controller involved 
> between device and cpu we use "Hierarchy IRQ domain" (parent and
> child msi domains). But in our case we don't have any such Hierarchy
> and we have single interrupt controller. In such case is it necessary
> to use multiple domains in software which actually isn't case in
> hardware.

This is not optional. The generic MSI domain is stacked on top of the
one that drives the HW. Which is exactly the XGene case. Your case is
not different in any way, and the exact same methods apply:

MSI -> RandomHW -> Interrupt controller (GIC)

We can argue about it as long as you want, but there is no way we're
adding more msi_controller madness to the tree. It took us a long time,
but we now have a generic way to do MSIs in the kernel, and you need to
use it, not sidestep it.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller

[Marc Zyngier]

On 09/10/15 09:51, Bharat Kumar Gogada wrote:
>> On 09/10/15 06:11, Bharat Kumar Gogada wrote:
>> +struct nwl_msi {  /* struct nwl_msi - MSI information
 */
>> +  struct msi_controller chip; /* chip: MSI controller */
>
>> We're moving away from msi_controller altogether, as the kernel now
>> has all the necessary infrastructure to do this properly.
>
> Our current GIC version does not have separate msi controller (we
> are not using GICv2m or GICv3), so is it necessary to have separate
> msi controller node ? Please give me clarity on this.

 This has nothing to do with the version of the GIC you are using
 (XGene doesn't have GICv2m or v3 either). This is about reducing code
 duplication and having something that we can maintain. See also
 https://lkml.org/lkml/2015/9/20/193 for yet another example.

 I still plan to kill msi_controller, and I'd like to avoid more
 dependencies with it. MSI domains are the way to do it.

>>> Sorry previously I haven't configured my email client properly so resending.
>>
>> Thanks for doing so, much appreciated.
>>
>>> Since we don't have separate MSI controller, and our PCIe controller
>>> is handling MSI, is it necessary to create a separate MSI controller
>>> node because we don't have any 'reg' space.
>>
>> No, your PCI controller can perfectly be part of the PCIe node.
> You meant 'msi-controller' property to be part of PCIe node?

Yeah, sorry. Too early, not enough coffee.

>>
>>> Please let me know whether we require a separate msi file as suggested
>>> in your previous comments to separate MSI controller and PCIE
>>> controller in two files, if we don't have separate node. If we do not
>>> need a separate node do we need to embed MSI controller child node  in
>>> PCIe controller node itself, and what properties does this child node
>>> will require other than 'interrupts'.
>>
>> If you want to keep them in the same file, please at least have two separate
>> patches. These are two different functions, and they should be reviewed
>> separately.
>>
> What I meant is if we don't have separate msi node do we need separate file? 

That's up to you. Nodes and source code files don't have to match at all.

> If you meant msi controller to be part of same node then we will use single 
> file and will
> try to have two separate patches.

That's fine by me.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller

[Marc Zyngier]

On 09/10/15 06:11, Bharat Kumar Gogada wrote:
 +struct nwl_msi {  /* struct nwl_msi - MSI information
>> */
 +  struct msi_controller chip; /* chip: MSI controller */
>>>
 We're moving away from msi_controller altogether, as the kernel now
 has all the necessary infrastructure to do this properly.
>>>
>>> Our current GIC version does not have separate msi controller (we are
>>> not using GICv2m or GICv3), so is it necessary to have separate msi
>>> controller node ? Please give me clarity on this.
>>
>> This has nothing to do with the version of the GIC you are using (XGene
>> doesn't have GICv2m or v3 either). This is about reducing code duplication
>> and having something that we can maintain. See also
>> https://lkml.org/lkml/2015/9/20/193 for yet another example.
>>
>> I still plan to kill msi_controller, and I'd like to avoid more dependencies 
>> with
>> it. MSI domains are the way to do it.
>>
> Sorry previously I haven't configured my email client properly so resending.

Thanks for doing so, much appreciated.

> Since we don't have separate MSI controller, and our PCIe controller
> is handling MSI, is it necessary to create a separate MSI controller
> node because we don't have any 'reg' space.

No, your PCI controller can perfectly be part of the PCIe node.

> Please let me know whether we require a separate msi file as
> suggested in your previous comments to separate MSI controller and
> PCIE controller in two files, if we don't have separate node. If we
> do not need a separate node do we need to embed MSI controller child
> node  in PCIe controller node itself, and what properties does this
> child node will require other than 'interrupts'.

If you want to keep them in the same file, please at least have two
separate patches. These are two different functions, and they should be
reviewed separately.

It will help everyone to understand your code, and speed up the
reviewing process.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller

[Marc Zyngier]

On 06/10/15 17:27, Bharat Kumar Gogada wrote:
> Subject: Re: [PATCH v3] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL 
> PCIe Host Controller

[...]

Please use an email client that does proper quoting - I cannot see what
you are replying to. Or at least annotate your answers so that I can
spot them.

>> +struct nwl_msi {/* struct nwl_msi - MSI information */
>> +struct msi_controller chip; /* chip: MSI controller */
> 
>> We're moving away from msi_controller altogether, as the kernel now
>> has all the necessary infrastructure to do this properly.
> 
> Our current GIC version does not have separate msi controller (we are
> not using GICv2m or GICv3), so is it necessary to have separate msi
> controller node ? Please give me clarity on this.

This has nothing to do with the version of the GIC you are using (XGene
doesn't have GICv2m or v3 either). This is about reducing code
duplication and having something that we can maintain. See also
https://lkml.org/lkml/2015/9/20/193 for yet another example.

I still plan to kill msi_controller, and I'd like to avoid more
dependencies with it. MSI domains are the way to do it.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller

[Marc Zyngier]

Hi Bharat,

On 06/10/15 16:44, Bharat Kumar Gogada wrote:
> Adding PCIe Root Port driver for Xilinx PCIe NWL bridge IP.
> 
> Signed-off-by: Bharat Kumar Gogada 
> Signed-off-by: Ravi Kiran Gummaluri 
> ---
> Added interrupt-map, interrupt-map-mask properties
> ---
>  .../devicetree/bindings/pci/xilinx-nwl-pcie.txt|   56 ++
>  drivers/pci/host/Kconfig   |9 +
>  drivers/pci/host/Makefile  |1 +
>  drivers/pci/host/pcie-xilinx-nwl.c | 1029 
> 
>  4 files changed, 1095 insertions(+), 0 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
>  create mode 100644 drivers/pci/host/pcie-xilinx-nwl.c
> 
> diff --git a/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt 
> b/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
> new file mode 100644
> index 000..81006ab
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
> @@ -0,0 +1,56 @@
> +* Xilinx NWL PCIe Root Port Bridge DT description
> +
> +Required properties:
> +- compatible: Should contain "xlnx,nwl-pcie-2.11"
> +- #address-cells: Address representation for root ports, set to <3>
> +- #size-cells: Size representation for root ports, set to <2>
> +- #interrupt-cells: specifies the number of cells needed to encode an
> + interrupt source. The value must be 1.
> +- reg: Should contain Bridge, PCIe Controller registers location,
> + configuration sapce, and length
> +- reg-names: Must include the following entries:
> + "breg": bridge registers
> + "pcireg": PCIe controller registers
> + "cfg": configuration space region
> +- device_type: must be "pci"
> +- interrupts: Should contain NWL PCIe interrupt
> +- interrupt-names: Must include the following entries:
> + "misc": interrupt asserted when miscellaneous is recieved
> + "intx": interrupt that is asserted when an legacy interrupt is received
> + "msi_1, msi_0": interrupt asserted when msi is recieved
> +- interrupt-map-mask and interrupt-map: standard PCI properties to define the
> + mapping of the PCI interface to interrupt numbers.
> +- ranges: ranges for the PCI memory regions (I/O space region is not
> + supported by hardware)
> + Please refer to the standard PCI bus binding document for a more
> + detailed explanation
> +
> +Optional properties:
> +- xlnx,msi-fifo: To enable MSI FIFO mode
> + - This feature can be used to queue multiple MSI interrupts
> +
> +Example:
> +
> +nwl_pcie: pcie@fd0e {
> + compatible = "xlnx,nwl-pcie-2.11";
> + #address-cells = <3>;
> + #size-cells = <2>;
> + #interrupt-cells = <1>;
> + device_type = "pci";
> + interrupt-parent = <&gic>;
> + interrupts = < 0 118 4
> +0 116 4
> +0 115 4  // MSI_1 [63...32]
> +0 114 4 >;   // MSI_0 [31...0]
> + interrupt-names = "misc", "intx", "msi_1", "msi_0";
> + interrupt-map-mask = <0x0 0x0 0x0 0x7>;
> + interrupt-map = <0x0 0x0 0x0 0x1 &gic 0x0 116 0x4
> + 0x0 0x0 0x0 0x2 &gic 0x0 116 0x4
> + 0x0 0x0 0x0 0x3 &gic 0x0 116 0x4
> + 0x0 0x0 0x0 0x4 &gic 0x0 116 0x4>;
> + reg = <0x0 0xfd0e 0x1000
> +0x0 0xfd48 0x1000
> +0x0 0xE000 0x100>;
> + reg-names = "breg", "pcireg", "cfg";
> + ranges = <0x0200 0x 0xE100 0x 0xE100 0 
> 0x0F00>;
> +};

Please move this to a separate patch. This is big enough, and hard
enough to review.

> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> index c132bdd..7f5f35e 100644
> --- a/drivers/pci/host/Kconfig
> +++ b/drivers/pci/host/Kconfig
> @@ -15,6 +15,15 @@ config PCI_MVEBU
>   depends on ARCH_MVEBU || ARCH_DOVE
>   depends on OF
> 
> +config PCIE_XILINX_NWL
> + bool "NWL PCIe Core && PCI_MSI"
> + depends on ARCH_ZYNQMP
> + help
> +  Say 'Y' here if you want kernel to support for Xilinx
> +  NWL PCIe controller.The controller can act as Root Port
> +  or End Point.The current option selection will only

Add a space after the dot.

> +  support root port enabling.
> +
>  config PCIE_DW
>   bool
> 
> diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
> index 140d66f..6a56df7 100644
> --- a/drivers/pci/host/Makefile
> +++ b/drivers/pci/host/Makefile
> @@ -10,6 +10,7 @@ obj-$(CONFIG_PCI_HOST_GENERIC) += pci-host-generic.o
>  obj-$(CONFIG_PCIE_SPEAR13XX) += pcie-spear13xx.o
>  obj-$(CONFIG_PCI_KEYSTONE) += pci-keystone-dw.o pci-keystone.o
>  obj-$(CONFIG_PCIE_XILINX) += pcie-xilinx.o
> +obj-$(CONFIG_PCIE_XILINX_NWL) += pcie-xilinx-nwl.o
>  obj-$(CONFIG_PCI_XGENE) += pci-xgene.o
>  obj-$(CONFIG_PCI_XGENE_MSI) += pci-xgene-msi.o
>  obj-$(CONFIG_PCI_LAYERSCAPE) += pci-layerscape.o
> diff --git a/drivers/pci/host/pcie-xilinx-nwl.c 
> b/drivers/pci/host/pcie-xi

Re: [PATCH v7 5/6] Documentation: dt-bindings: pci: altera pcie device tree binding

[Marc Zyngier]

On Fri, 2 Oct 2015 23:56:37 +0200
Arnd Bergmann  wrote:

> On Friday 02 October 2015 15:53:44 Ley Foon Tan wrote:
> > > Strictly speaking, if you have undocumented bindings downstream that
> > > is your problem and we don't have to accept them as-is upstream. I'm
> > > not going to worry about that here.
> > >
> > >>> txs contains the config space?
> > >> It is not the config space, but a memory slave port.
> > >
> > > Then where is the config space? It should not be part of "ranges" is
> > > all I care about.
> > The config space is not part of "ranges". Our IP uses TLP packet to
> > access config space.
> > 
> 
> It took me a bit to figure out what you mean here. To save others
> from reading the source, here is what I found:
> 
> * The config space is accessed indirectly through registers from the
>   "cra" register range, which is the right approach according to the
>   point that Rob made.
> * hardware-wise this basically looks like bit-banged PCIe, which is
>   both awesome and scary ;-)

drivers/pcie/host/pcie-host-gpio.c anyone? ;-)

M.
-- 
Jazz is not dead. It just smells funny.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 4/4] irqchip/gic-v3-its: Add handling of PCI requester id.

[Marc Zyngier]

On 02/10/15 01:50, David Daney wrote:
> From: David Daney 
> 
> Replace open coded generation PCI/MSI requester id with call to the
> new function pci_msi_domain_get_msi_rid() which applies the "msi-map"
> to the id value.
> 
> Signed-off-by: David Daney 
> ---
>  drivers/irqchip/irq-gic-v3-its-pci-msi.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/irqchip/irq-gic-v3-its-pci-msi.c 
> b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
> index cf351c6..7bbf64a 100644
> --- a/drivers/irqchip/irq-gic-v3-its-pci-msi.c
> +++ b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
> @@ -42,7 +42,6 @@ static struct irq_chip its_msi_irq_chip = {
>  
>  struct its_pci_alias {
>   struct pci_dev  *pdev;
> - u32 dev_id;
>   u32 count;
>  };
>  
> @@ -60,7 +59,6 @@ static int its_get_pci_alias(struct pci_dev *pdev, u16 
> alias, void *data)
>  {
>   struct its_pci_alias *dev_alias = data;
>  
> - dev_alias->dev_id = alias;
>   if (pdev != dev_alias->pdev)
>   dev_alias->count += its_pci_msi_vec_count(dev_alias->pdev);

Damn it. You've just shown me a bug. Unrelated to what you're doing, but
still. I'll post a patch shortly.

>  
> @@ -86,7 +84,7 @@ static int its_pci_msi_prepare(struct irq_domain *domain, 
> struct device *dev,
>   pci_for_each_dma_alias(pdev, its_get_pci_alias, &dev_alias);
>  
>   /* ITS specific DeviceID, as the core ITS ignores dev. */
> - info->scratchpad[0].ul = dev_alias.dev_id;
> + info->scratchpad[0].ul = pci_msi_domain_get_msi_rid(domain, pdev);
>  
>   return msi_info->ops->msi_prepare(domain->parent,
> dev, dev_alias.count, info);
> 

Looks good to me.

Reviewed-by: Marc Zyngier 

M.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 3/4] PCI/MSI: Add helper function pci_msi_domain_get_msi_rid().

[Marc Zyngier]

On 02/10/15 01:50, David Daney wrote:
> From: David Daney 
> 
> Add pci_msi_domain_get_msi_rid() to return the MSI requester id (RID).
> Initially needed by gic-v3 based systems. It will be used by follow on
> patch to drivers/irqchip/irq-gic-v3-its-pci-msi.c
> 
> Initially supports mapping the RID via OF device tree.  In the future,
> this could be extended to use ACPI _IORT tables as well.
> 
> Signed-off-by: David Daney 

Reviewed-by: Marc Zyngier 

M.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 3/4] PCI/MSI: Add helper function pci_msi_domain_get_msi_rid().

[Marc Zyngier]

On 01/10/15 17:13, David Daney wrote:
> On 10/01/2015 02:24 AM, Marc Zyngier wrote:
>> Hi David,
>>
>> On 30/09/15 23:47, David Daney wrote:
>>> From: David Daney 
>>>
>>> Add pci_msi_domain_get_msi_rid() to return the MSI requester id (RID).
>>> Initially needed by gic-v3 based systems. It will be used by follow on
>>> patch to drivers/irqchip/irq-gic-v3-its-pci-msi.c
>>>
>>> Initially supports mapping the RID via OF device tree.  In the future,
>>> this could be extended to use ACPI _IORT tables as well.
>>>
>>> Signed-off-by: David Daney 
>>> ---
>>>   drivers/pci/msi.c   | 31 +++
>>>   include/linux/msi.h |  1 +
>>>   2 files changed, 32 insertions(+)
>>>
>>> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
>>> index d449714..92b6dc9 100644
>>> --- a/drivers/pci/msi.c
>>> +++ b/drivers/pci/msi.c
>>> @@ -20,6 +20,7 @@
>>>   #include 
>>>   #include 
>>>   #include 
>>> +#include 
>>>
>>>   #include "pci.h"
>>>
>>> @@ -1327,4 +1328,34 @@ struct irq_domain 
>>> *pci_msi_create_default_irq_domain(struct device_node *node,
>>>
>>> return domain;
>>>   }
>>> +
>>> +struct get_mis_id_data {
>>> +   u32 alias;
>>> +};
>>> +
>>> +static int get_msi_id_cb(struct pci_dev *pdev, u16 alias, void *data)
>>> +{
>>> +   struct get_mis_id_data *s = data;
>>> +
>>> +   s->alias = alias;
>>> +   return 0;
>>> +}
>>
>> Why not use a naked u32, since you only have a single field in this
>> structure? Or is it that you are anticipating other fields there?
> 
> In this case, I think using a pointer to u32 is a good idea.  It would 
> simplify the source code somewhat.  Although, I think the generated 
> binary would likely be the same.  I don't foresee adding things to this 
> structure.  If it becomes necessary in the future, we can just go back 
> to using a pointer to a structure.
> 
>>
>>> +/**
>>> + * pci_msi_domain_get_msi_rid - Get the MSI requester id (RID)
>>> + * @domain:The interrupt domain
>>> + * @pdev:  The PCI device.
>>> + *
>>> + * The RID for a device is formed from the alias, with a firmware
>>> + * supplied mapping applied
>>> + *
>>> + * Returns: The RID.
>>> + */
>>> +u32 pci_msi_domain_get_msi_rid(struct irq_domain *domain, struct pci_dev 
>>> *pdev)
>>> +{
>>> +   struct get_mis_id_data d;
>>> +
>>> +   d.alias = 0;
>>> +   pci_for_each_dma_alias(pdev, get_msi_id_cb, &d);
>>> +   return of_msi_map_rid(&pdev->dev, domain->of_node, d.alias);
>>
>> Should you check whether domain->of_node is NULL first? I don't think
>> of_msi_map_rid would have any problem with that, but a domain that is
>> not backed by an of_node makes me feel a bit uneasy and would tend to
>> indicate that we're not using DT.
> 
> Yes, that makes sense.  As you observe, I think it probably works as is, 
> but it would be good to make it more clear.  This is especially true 
> when we add ACPI support.  We will want to be clear on which of 
> device-tree or ACPI we are using.
> 
> 
>>
>>> +}
>>>   #endif /* CONFIG_PCI_MSI_IRQ_DOMAIN */
>>> diff --git a/include/linux/msi.h b/include/linux/msi.h
>>> index ad939d0..56e3b76 100644
>>> --- a/include/linux/msi.h
>>> +++ b/include/linux/msi.h
>>> @@ -293,6 +293,7 @@ irq_hw_number_t pci_msi_domain_calc_hwirq(struct 
>>> pci_dev *dev,
>>>   struct msi_desc *desc);
>>>   int pci_msi_domain_check_cap(struct irq_domain *domain,
>>>  struct msi_domain_info *info, struct device *dev);
>>> +u32 pci_msi_domain_get_msi_rid(struct irq_domain *domain, struct pci_dev 
>>> *pdev);
>>>   #endif /* CONFIG_PCI_MSI_IRQ_DOMAIN */
>>>
>>>   #endif /* LINUX_MSI_H */
>>>
>>
>> Otherwise looks good to me.
> 
> I will send what I hope is the final revision of the patches later today.

Excellent. In related news, I've rebased my msi-parent stuff on top of
this series, and extended it to also deal with msi-map for matching MSI
domains.

With the two series, we should now have something vaguely coherent that
deals with both the old version of msi-parent, its new definition, and
msi-map in its whole glory. Fun times!

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 3/4] PCI/MSI: Add helper function pci_msi_domain_get_msi_rid().

[Marc Zyngier]

Hi David,

On 30/09/15 23:47, David Daney wrote:
> From: David Daney 
> 
> Add pci_msi_domain_get_msi_rid() to return the MSI requester id (RID).
> Initially needed by gic-v3 based systems. It will be used by follow on
> patch to drivers/irqchip/irq-gic-v3-its-pci-msi.c
> 
> Initially supports mapping the RID via OF device tree.  In the future,
> this could be extended to use ACPI _IORT tables as well.
> 
> Signed-off-by: David Daney 
> ---
>  drivers/pci/msi.c   | 31 +++
>  include/linux/msi.h |  1 +
>  2 files changed, 32 insertions(+)
> 
> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
> index d449714..92b6dc9 100644
> --- a/drivers/pci/msi.c
> +++ b/drivers/pci/msi.c
> @@ -20,6 +20,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "pci.h"
>  
> @@ -1327,4 +1328,34 @@ struct irq_domain 
> *pci_msi_create_default_irq_domain(struct device_node *node,
>  
>   return domain;
>  }
> +
> +struct get_mis_id_data {
> + u32 alias;
> +};
> +
> +static int get_msi_id_cb(struct pci_dev *pdev, u16 alias, void *data)
> +{
> + struct get_mis_id_data *s = data;
> +
> + s->alias = alias;
> + return 0;
> +}

Why not use a naked u32, since you only have a single field in this
structure? Or is it that you are anticipating other fields there?

> +/**
> + * pci_msi_domain_get_msi_rid - Get the MSI requester id (RID)
> + * @domain:  The interrupt domain
> + * @pdev:The PCI device.
> + *
> + * The RID for a device is formed from the alias, with a firmware
> + * supplied mapping applied
> + *
> + * Returns: The RID.
> + */
> +u32 pci_msi_domain_get_msi_rid(struct irq_domain *domain, struct pci_dev 
> *pdev)
> +{
> + struct get_mis_id_data d;
> +
> + d.alias = 0;
> + pci_for_each_dma_alias(pdev, get_msi_id_cb, &d);
> + return of_msi_map_rid(&pdev->dev, domain->of_node, d.alias);

Should you check whether domain->of_node is NULL first? I don't think
of_msi_map_rid would have any problem with that, but a domain that is
not backed by an of_node makes me feel a bit uneasy and would tend to
indicate that we're not using DT.

> +}
>  #endif /* CONFIG_PCI_MSI_IRQ_DOMAIN */
> diff --git a/include/linux/msi.h b/include/linux/msi.h
> index ad939d0..56e3b76 100644
> --- a/include/linux/msi.h
> +++ b/include/linux/msi.h
> @@ -293,6 +293,7 @@ irq_hw_number_t pci_msi_domain_calc_hwirq(struct pci_dev 
> *dev,
> struct msi_desc *desc);
>  int pci_msi_domain_check_cap(struct irq_domain *domain,
>struct msi_domain_info *info, struct device *dev);
> +u32 pci_msi_domain_get_msi_rid(struct irq_domain *domain, struct pci_dev 
> *pdev);
>  #endif /* CONFIG_PCI_MSI_IRQ_DOMAIN */
>  
>  #endif /* LINUX_MSI_H */
> 

Otherwise looks good to me.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 0/9] Making the generic ACPI GSI layer irqdomain aware

[Marc Zyngier]

On 29/09/15 18:11, Rob Herring wrote:
> On Mon, Sep 28, 2015 at 11:42 AM, Marc Zyngier  wrote:
>> The irqdomain code is not entierely ACPI friendly, as it has some
>> built-in knowledge of the device-tree. Nothing too harmful, but enough
>> to scare the ARM ACPI developpers which end up with their own version
>> of the square wheel.
>>
>> This small patch series adapts the irqdomain code to remove the
>> hurdles that prevent the full blown irqdomain subsystem to be used on
>> ACPI, creates an interface between the GSI layer and the irqdomain,
>> and as an example, convert the ARM GIC ACPI support to use irqdomains
>> as originally intended.
>>
>> Overall, this gives us a way to use irqdomains on both DT and ACPI
>> enabled platforms, having very little changes made to the actual
>> drivers (other than the probing infrastructure). Because we keep the
>> flow of information between the various layers identical between ACPI
>> and DT, we immediately benefit from the existing infrastructure. The
>> "convert the GSI information to be DT friendly" is admitedly not very
>> pretty, but I see it as a stepping stone towards unifying the two
>> structures.
> 
> Did I miss v1-v3 or did the DT change just show up? I probably tuned
> out with ACPI in the subject.

No, that's new. It was far worse before.

> Needing fake DT nodes for ACPI is just wrong. There's got to be
> another, better way.

Well, the alternative is to rewrite the whole of irqdomain and
everything that gets called from there in terms of fwnode_handle. Which
will trickle in the whole of OF as well.

Note that the fake DT node doesn't represent an ACPI object at all. It
is an identifier for an irqdomain, and that's where it stops.

M.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 1/9] drivers/of: Introduce of_node_alloc

[Marc Zyngier]

On Mon, 28 Sep 2015 15:50:38 -0700
Frank Rowand  wrote:

> On 9/28/2015 9:42 AM, Marc Zyngier wrote:
> > We want to be able to generate "fake" device nodes that can be
> > used as an identifier for irq domains. For that, we reuse the
> > dynamic DT layer in order to generate DT nodes in a detached state
> > (so that it doesn't interfere with the rest of the tree).
> > 
> > Signed-off-by: Marc Zyngier 
> > ---
> >  drivers/of/dynamic.c | 22 ++
> >  include/linux/of.h   |  5 +
> >  2 files changed, 27 insertions(+)
> > 
> > diff --git a/drivers/of/dynamic.c b/drivers/of/dynamic.c
> > index 53826b8..709d363 100644
> > --- a/drivers/of/dynamic.c
> > +++ b/drivers/of/dynamic.c
> > @@ -445,6 +445,28 @@ struct device_node *__of_node_dup(const struct 
> > device_node *np, const char *fmt,
> > return NULL;
> >  }
> >  
> > +/**
> > + * of_node_alloc() - Allocate an empty device node dynamically.
> > + * @fmt: Format string (plus vargs) for new full name of the device node
> > + *
> > + * Create an device tree node, either by by allocating an empty one
> 
>   Create a device tree node by allocating an empty one

Ah! Thanks!

M.
-- 
Jazz is not dead. It just smells funny.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 7/9] irqchip/GIC: Get rid of gic_init_bases()

[Marc Zyngier]

Since nobody is using gic_init_bases anymore outside of the GIC
driver itself, let's do a bit of housekeeping and remove the now
useless entry point.

Only gic_init() is now exposed to the rest of the kernel for the
benefit of non DT/ACPI system.

Signed-off-by: Marc Zyngier 
---
 drivers/irqchip/irq-gic.c   | 8 +++-
 include/linux/irqchip/arm-gic.h | 9 ++---
 2 files changed, 5 insertions(+), 12 deletions(-)

diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index 982c09c..0e4142d 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -1087,17 +1087,15 @@ static void __init __gic_init_bases(unsigned int 
gic_nr, int irq_start,
gic_pm_init(gic);
 }
 
-void __init gic_init_bases(unsigned int gic_nr, int irq_start,
-  void __iomem *dist_base, void __iomem *cpu_base,
-  u32 percpu_offset, struct device_node *node)
+void __init gic_init(unsigned int gic_nr, int irq_start,
+void __iomem *dist_base, void __iomem *cpu_base)
 {
/*
 * Non-DT/ACPI systems won't run a hypervisor, so let's not
 * bother with these...
 */
static_key_slow_dec(&supports_deactivate);
-   __gic_init_bases(gic_nr, irq_start, dist_base, cpu_base,
-percpu_offset, node);
+   __gic_init_bases(gic_nr, irq_start, dist_base, cpu_base, 0, NULL);
 }
 
 #ifdef CONFIG_OF
diff --git a/include/linux/irqchip/arm-gic.h b/include/linux/irqchip/arm-gic.h
index b8901df..bae69e5 100644
--- a/include/linux/irqchip/arm-gic.h
+++ b/include/linux/irqchip/arm-gic.h
@@ -100,16 +100,11 @@
 
 struct device_node;
 
-void gic_init_bases(unsigned int, int, void __iomem *, void __iomem *,
-   u32 offset, struct device_node *);
 void gic_cascade_irq(unsigned int gic_nr, unsigned int irq);
 int gic_cpu_if_down(unsigned int gic_nr);
 
-static inline void gic_init(unsigned int nr, int start,
-   void __iomem *dist , void __iomem *cpu)
-{
-   gic_init_bases(nr, start, dist, cpu, 0, NULL);
-}
+void gic_init(unsigned int nr, int start,
+ void __iomem *dist , void __iomem *cpu);
 
 int gicv2m_of_init(struct device_node *node, struct irq_domain *parent);
 
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 9/9] acpi/gsi: Cleanup acpi_register_gsi

[Marc Zyngier]

As the only user of drivers/acpi/gsi.c is now using acpi_set_irq_model
to set acpi_gsi_descriptor_populate to something meaningful, we can
always rely on that information to be present (its absence is an error),
and guarantee that new interrupt controllers will use this API.

Take this opportunity to cleanup acpi_register_gsi.

Signed-off-by: Marc Zyngier 
---
 drivers/acpi/gsi.c | 24 
 1 file changed, 8 insertions(+), 16 deletions(-)

diff --git a/drivers/acpi/gsi.c b/drivers/acpi/gsi.c
index 7905840..29e994d 100644
--- a/drivers/acpi/gsi.c
+++ b/drivers/acpi/gsi.c
@@ -76,28 +76,20 @@ int acpi_register_gsi(struct device *dev, u32 gsi, int 
trigger,
  int polarity)
 {
int err;
-   unsigned int irq;
+   struct acpi_gsi_descriptor data;
unsigned int irq_type = acpi_gsi_get_irq_type(trigger, polarity);
struct irq_domain *d = irq_find_host(acpi_gsi_domain_id);
 
-   if (acpi_gsi_descriptor_populate) {
-   struct acpi_gsi_descriptor data;
-   err = acpi_gsi_descriptor_populate(&data, gsi, irq_type);
-   if (err)
-   return err;
-
-   return irq_create_acpi_mapping(d, &data);
+   if (WARN_ON(!acpi_gsi_descriptor_populate)) {
+   pr_warn("GSI: No registered irqchip, giving up\n");
+   return -EINVAL;
}
 
-   irq = irq_create_mapping(d, gsi);
-   if (!irq)
-   return -EINVAL;
+   err = acpi_gsi_descriptor_populate(&data, gsi, irq_type);
+   if (err)
+   return err;
 
-   /* Set irq type if specified and different than the current one */
-   if (irq_type != IRQ_TYPE_NONE &&
-   irq_type != irq_get_trigger_type(irq))
-   irq_set_irq_type(irq, irq_type);
-   return irq;
+   return irq_create_acpi_mapping(d, &data);
 }
 EXPORT_SYMBOL_GPL(acpi_register_gsi);
 
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 3/9] genirq/irqdomain: Add a fwnode_handle allocator

[Marc Zyngier]

In order to be able to reference an irqdomain from ACPI, we need
to be able to create an identifier, which is a struct device_node.

This device node does't really fit the ACPI infrastructure, so
we cunningly hide it by returning the contained fwnode_handle.
This will help a (still hypothetical) further migration of
irqdomain from device_node to fwnode_handle.

Signed-off-by: Marc Zyngier 
---
 include/linux/irqdomain.h |  2 ++
 kernel/irq/irqdomain.c| 30 ++
 2 files changed, 32 insertions(+)

diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index d3ca792..3193c61 100644
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -162,6 +162,8 @@ enum {
 };
 
 #ifdef CONFIG_IRQ_DOMAIN
+struct fwnode_handle *irq_domain_alloc_fwnode(void *data);
+void irq_domain_free_fwnode(struct fwnode_handle *fwnode);
 struct irq_domain *__irq_domain_add(struct device_node *of_node, int size,
irq_hw_number_t hwirq_max, int direct_max,
const struct irq_domain_ops *ops,
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index e5c1e4c..5e7214a 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -29,6 +29,36 @@ static int irq_domain_alloc_descs(int virq, unsigned int 
nr_irqs,
 static void irq_domain_check_hierarchy(struct irq_domain *domain);
 
 /**
+ * irq_domain_alloc_fwnode - Allocate a OF-backed fwnode_handle suitable for
+ *   identifying an irq domain
+ * @data: optional user-provided data
+ *
+ * Allocate a struct device_node, and return a poiner to the embedded
+ * fwnode_handle (or NULL on failure).
+ */
+struct fwnode_handle *irq_domain_alloc_fwnode(void *data)
+{
+   struct device_node *of_node;
+
+   of_node = of_node_alloc("irqdomain@%p", data);
+   if (!of_node)
+   return NULL;
+
+   of_node->data = data;
+   return &of_node->fwnode;
+}
+
+/**
+ * irq_domain_free_fwnode - Free a OF-backed fwnode_handle
+ *
+ * Free a fwnode_handle allocated with irq_domain_alloc_fwnode.
+ */
+void irq_domain_free_fwnode(struct fwnode_handle *fwnode)
+{
+   of_node_put(to_of_node(fwnode));
+}
+
+/**
  * __irq_domain_add() - Allocate a new irq_domain data structure
  * @of_node: optional device-tree node of the interrupt controller
  * @size: Size of linear map; 0 for radix mapping only
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 1/9] drivers/of: Introduce of_node_alloc

[Marc Zyngier]

We want to be able to generate "fake" device nodes that can be
used as an identifier for irq domains. For that, we reuse the
dynamic DT layer in order to generate DT nodes in a detached state
(so that it doesn't interfere with the rest of the tree).

Signed-off-by: Marc Zyngier 
---
 drivers/of/dynamic.c | 22 ++
 include/linux/of.h   |  5 +
 2 files changed, 27 insertions(+)

diff --git a/drivers/of/dynamic.c b/drivers/of/dynamic.c
index 53826b8..709d363 100644
--- a/drivers/of/dynamic.c
+++ b/drivers/of/dynamic.c
@@ -445,6 +445,28 @@ struct device_node *__of_node_dup(const struct device_node 
*np, const char *fmt,
return NULL;
 }
 
+/**
+ * of_node_alloc() - Allocate an empty device node dynamically.
+ * @fmt: Format string (plus vargs) for new full name of the device node
+ *
+ * Create an device tree node, either by by allocating an empty one
+ * suitable for further modification.  The node data are dynamically
+ * allocated and all the node flags have the OF_DYNAMIC & OF_DETACHED
+ * bits set. Returns the newly allocated node or NULL on out of memory
+ * error.
+ */
+struct device_node *of_node_alloc(const char *fmt, ...)
+{
+   struct device_node *np;
+   va_list vargs;
+
+   va_start(vargs, fmt);
+   np = __of_node_dup(NULL, fmt, vargs);
+   va_end(vargs);
+
+   return np;
+}
+
 static void __of_changeset_entry_destroy(struct of_changeset_entry *ce)
 {
of_node_put(ce->np);
diff --git a/include/linux/of.h b/include/linux/of.h
index 2194b8c..f7f11f7 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -104,6 +104,7 @@ static inline int of_node_is_attached(struct device_node 
*node)
 #ifdef CONFIG_OF_DYNAMIC
 extern struct device_node *of_node_get(struct device_node *node);
 extern void of_node_put(struct device_node *node);
+extern struct device_node *of_node_alloc(const char *fmt, ...);
 #else /* CONFIG_OF_DYNAMIC */
 /* Dummy ref counting routines - to be implemented later */
 static inline struct device_node *of_node_get(struct device_node *node)
@@ -111,6 +112,10 @@ static inline struct device_node *of_node_get(struct 
device_node *node)
return node;
 }
 static inline void of_node_put(struct device_node *node) { }
+static inline struct device_node *of_node_alloc(const char *fmt, ...)
+{
+   return NULL;
+}
 #endif /* !CONFIG_OF_DYNAMIC */
 
 /* Pointer for first entry in chain of all nodes. */
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 2/9] genirq/irqdomain: Add irq_create_acpi_mapping

[Marc Zyngier]

In order to help ACPI on arm64 to make use of most of the irqdomain
goodies, add a new entry point (irq_create_acpi_mapping) which
mimics irq_create_of_mapping, except that it takes a new
struct acpi_gsi_descriptor, which is the pendent of of_phandle_args
in the OF world.

We assume that the way the acpi_gsi_descriptor is populated matches
that of of_phandle_args, as the latter is still the building block
for interrupt descriptor in the whole kernel.

Eventually, these two representations should be merged in a single
structure, but that's probably for another day.

Signed-off-by: Marc Zyngier 
---
 include/linux/acpi.h   |  9 +
 kernel/irq/irqdomain.c | 18 ++
 2 files changed, 27 insertions(+)

diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 7235c48..4db2f01 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -201,6 +201,15 @@ int acpi_register_gsi (struct device *dev, u32 gsi, int 
triggering, int polarity
 int acpi_gsi_to_irq (u32 gsi, unsigned int *irq);
 int acpi_isa_irq_to_gsi (unsigned isa_irq, u32 *gsi);
 
+#define MAX_GSI_DESC_PARAMS 16
+struct acpi_gsi_descriptor {
+   int param_count;
+   u32 param[MAX_GSI_DESC_PARAMS];
+};
+
+unsigned int irq_create_acpi_mapping(struct irq_domain *d,
+struct acpi_gsi_descriptor *irq_data);
+
 #ifdef CONFIG_X86_IO_APIC
 extern int acpi_get_override_irq(u32 gsi, int *trigger, int *polarity);
 #else
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index dc9d27c..e5c1e4c 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -1,5 +1,6 @@
 #define pr_fmt(fmt)  "irq: " fmt
 
+#include 
 #include 
 #include 
 #include 
@@ -522,6 +523,23 @@ unsigned int irq_create_of_mapping(struct of_phandle_args 
*irq_data)
 }
 EXPORT_SYMBOL_GPL(irq_create_of_mapping);
 
+#ifdef CONFIG_ACPI
+unsigned int irq_create_acpi_mapping(struct irq_domain *d,
+struct acpi_gsi_descriptor *irq_data)
+{
+   struct of_phandle_args args;
+   int i;
+
+   for (i = 0; i < min(irq_data->param_count, MAX_PHANDLE_ARGS); i++)
+   args.args[i] = irq_data->param[i];
+
+   args.np = d->of_node;
+   args.args_count = i;
+
+   return irq_create_of_mapping(&args);
+}
+#endif
+
 /**
  * irq_dispose_mapping() - Unmap an interrupt
  * @virq: linux irq number of the interrupt to unmap
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 4/9] acpi/gsi: Always perform an irq domain lookup

[Marc Zyngier]

Instead of directly passing NULL to the various irq_domain functions,
start by looking up the domain with a domain identifier..

As this identifier is permanently set to NULL, the lookup function will
return the same value (no domain found) and the default will be used,
preserving the current behaviour.

Signed-off-by: Marc Zyngier 
---
 drivers/acpi/gsi.c | 23 ++-
 1 file changed, 10 insertions(+), 13 deletions(-)

diff --git a/drivers/acpi/gsi.c b/drivers/acpi/gsi.c
index 38208f2..6232d55 100644
--- a/drivers/acpi/gsi.c
+++ b/drivers/acpi/gsi.c
@@ -11,9 +11,12 @@
 #include 
 #include 
 #include 
+#include 
 
 enum acpi_irq_model_id acpi_irq_model;
 
+static struct device_node *acpi_gsi_domain_id;
+
 static unsigned int acpi_gsi_get_irq_type(int trigger, int polarity)
 {
switch (polarity) {
@@ -45,12 +48,9 @@ static unsigned int acpi_gsi_get_irq_type(int trigger, int 
polarity)
  */
 int acpi_gsi_to_irq(u32 gsi, unsigned int *irq)
 {
-   /*
-* Only default domain is supported at present, always find
-* the mapping corresponding to default domain by passing NULL
-* as irq_domain parameter
-*/
-   *irq = irq_find_mapping(NULL, gsi);
+   struct irq_domain *d = irq_find_host(acpi_gsi_domain_id);
+
+   *irq = irq_find_mapping(d, gsi);
/*
 * *irq == 0 means no mapping, that should
 * be reported as a failure
@@ -74,13 +74,9 @@ int acpi_register_gsi(struct device *dev, u32 gsi, int 
trigger,
 {
unsigned int irq;
unsigned int irq_type = acpi_gsi_get_irq_type(trigger, polarity);
+   struct irq_domain *d = irq_find_host(acpi_gsi_domain_id);
 
-   /*
-* There is no way at present to look-up the IRQ domain on ACPI,
-* hence always create mapping referring to the default domain
-* by passing NULL as irq_domain parameter
-*/
-   irq = irq_create_mapping(NULL, gsi);
+   irq = irq_create_mapping(d, gsi);
if (!irq)
return -EINVAL;
 
@@ -98,7 +94,8 @@ EXPORT_SYMBOL_GPL(acpi_register_gsi);
  */
 void acpi_unregister_gsi(u32 gsi)
 {
-   int irq = irq_find_mapping(NULL, gsi);
+   struct irq_domain *d = irq_find_host(acpi_gsi_domain_id);
+   int irq = irq_find_mapping(d, gsi);
 
irq_dispose_mapping(irq);
 }
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 6/9] acpi/gsi: Select OF_DYNAMIC when ACPI_GENERIC_GSI is selected

[Marc Zyngier]

As we're now dynamically creating device nodes to identify
irqdomains, it is necessary to enable CONFIG_OF_DYNAMIC, enabling
the use of of_node_alloc().

Signed-off-by: Marc Zyngier 
---
 drivers/acpi/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 5d1015c..8bbfe0b 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -49,6 +49,7 @@ config ARCH_MIGHT_HAVE_ACPI_PDC
bool
 
 config ACPI_GENERIC_GSI
+   select OF_DYNAMIC
bool
 
 config ACPI_SYSTEM_POWER_STATES_SUPPORT
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 5/9] acpi/gsi: Add acpi_set_irq_model to initialize the GSI layer

[Marc Zyngier]

In order to start embrassing irqdomains at the GSI level, introduce
a new initializer:

void acpi_set_irq_model(enum acpi_irq_model_id model,
struct fwnode_handle *fwnode,
int (*populate)(struct acpi_gsi_descriptor *,
u32, unsigned int));

where:
- model is the value assigned to acpi_irq_model
- fwnode is the identifier for the irqdomain mapping
  GSI interrupts
- populate is a function provided by the interrupt controller,
  populating a struct acpi_gsi_descriptor based on a GSI and
  the interrupt trigger information

As nobody calls this code yet, the current code is left in place.

Signed-off-by: Marc Zyngier 
---
 drivers/acpi/gsi.c   | 32 
 include/linux/acpi.h |  5 +
 2 files changed, 37 insertions(+)

diff --git a/drivers/acpi/gsi.c b/drivers/acpi/gsi.c
index 6232d55..7905840 100644
--- a/drivers/acpi/gsi.c
+++ b/drivers/acpi/gsi.c
@@ -17,6 +17,9 @@ enum acpi_irq_model_id acpi_irq_model;
 
 static struct device_node *acpi_gsi_domain_id;
 
+static int (*acpi_gsi_descriptor_populate)(struct acpi_gsi_descriptor *data,
+  u32 gsi, unsigned int irq_type);
+
 static unsigned int acpi_gsi_get_irq_type(int trigger, int polarity)
 {
switch (polarity) {
@@ -72,10 +75,20 @@ EXPORT_SYMBOL_GPL(acpi_gsi_to_irq);
 int acpi_register_gsi(struct device *dev, u32 gsi, int trigger,
  int polarity)
 {
+   int err;
unsigned int irq;
unsigned int irq_type = acpi_gsi_get_irq_type(trigger, polarity);
struct irq_domain *d = irq_find_host(acpi_gsi_domain_id);
 
+   if (acpi_gsi_descriptor_populate) {
+   struct acpi_gsi_descriptor data;
+   err = acpi_gsi_descriptor_populate(&data, gsi, irq_type);
+   if (err)
+   return err;
+
+   return irq_create_acpi_mapping(d, &data);
+   }
+
irq = irq_create_mapping(d, gsi);
if (!irq)
return -EINVAL;
@@ -100,3 +113,22 @@ void acpi_unregister_gsi(u32 gsi)
irq_dispose_mapping(irq);
 }
 EXPORT_SYMBOL_GPL(acpi_unregister_gsi);
+
+/**
+ * acpi_set_irq_model - Setup the GSI irqdomain information
+ * @model: the value assigned to acpi_irq_model
+ * @fwnode: the irq_domain identifier for mapping and looking up
+ *  GSI interrupts
+ * @populate: provided by the interrupt controller, populating a
+ *struct acpi_gsi_descriptor based on a GSI and
+ *the interrupt trigger information
+ */
+void __init acpi_set_irq_model(enum acpi_irq_model_id model,
+  struct fwnode_handle *fwnode,
+  int (*populate)(struct acpi_gsi_descriptor *,
+  u32, unsigned int))
+{
+   acpi_irq_model = model;
+   acpi_gsi_domain_id = to_of_node(fwnode);
+   acpi_gsi_descriptor_populate = populate;
+}
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 4db2f01..1423b21 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -210,6 +210,11 @@ struct acpi_gsi_descriptor {
 unsigned int irq_create_acpi_mapping(struct irq_domain *d,
 struct acpi_gsi_descriptor *irq_data);
 
+void acpi_set_irq_model(enum acpi_irq_model_id model,
+   struct fwnode_handle *fwnode,
+   int (*populate)(struct acpi_gsi_descriptor *,
+   u32, unsigned int));
+
 #ifdef CONFIG_X86_IO_APIC
 extern int acpi_get_override_irq(u32 gsi, int *trigger, int *polarity);
 #else
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 8/9] irqchip/GIC: Switch ACPI support to stacked domains

[Marc Zyngier]

Now that the basic ACPI GSI code is irq domain aware, make sure
that the ACPI support in the GIC doesn't pointlessly deviate from
the DT path.

Signed-off-by: Marc Zyngier 
---
 drivers/irqchip/irq-gic.c | 58 ---
 1 file changed, 45 insertions(+), 13 deletions(-)

diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index 0e4142d..4f5772d 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -910,8 +910,6 @@ static int gic_irq_domain_xlate(struct irq_domain *d,
 {
unsigned long ret = 0;
 
-   if (d->of_node != controller)
-   return -EINVAL;
if (intsize < 3)
return -EINVAL;
 
@@ -979,7 +977,7 @@ static const struct irq_domain_ops gic_irq_domain_ops = {
 
 static void __init __gic_init_bases(unsigned int gic_nr, int irq_start,
   void __iomem *dist_base, void __iomem *cpu_base,
-  u32 percpu_offset, struct device_node *node)
+  u32 percpu_offset, struct fwnode_handle *handle)
 {
irq_hw_number_t hwirq_base;
struct gic_chip_data *gic;
@@ -1031,11 +1029,12 @@ static void __init __gic_init_bases(unsigned int 
gic_nr, int irq_start,
gic_irqs = 1020;
gic->gic_irqs = gic_irqs;
 
-   if (node) { /* DT case */
+   if (handle) {   /* DT/ACPI */
+   struct device_node *node = to_of_node(handle);
gic->domain = irq_domain_add_linear(node, gic_irqs,

&gic_irq_domain_hierarchy_ops,
gic);
-   } else {/* Non-DT case */
+   } else {/* Legacy support */
/*
 * For primary GICs, skip over SGIs.
 * For secondary GICs, skip over PPIs, too.
@@ -1058,7 +1057,7 @@ static void __init __gic_init_bases(unsigned int gic_nr, 
int irq_start,
irq_base = irq_start;
}
 
-   gic->domain = irq_domain_add_legacy(node, gic_irqs, irq_base,
+   gic->domain = irq_domain_add_legacy(NULL, gic_irqs, irq_base,
hwirq_base, &gic_irq_domain_ops, gic);
}
 
@@ -1166,7 +1165,8 @@ gic_of_init(struct device_node *node, struct device_node 
*parent)
if (of_property_read_u32(node, "cpu-offset", &percpu_offset))
percpu_offset = 0;
 
-   __gic_init_bases(gic_cnt, -1, dist_base, cpu_base, percpu_offset, node);
+   __gic_init_bases(gic_cnt, -1, dist_base, cpu_base, percpu_offset,
+&node->fwnode);
if (!gic_cnt)
gic_init_physaddr(node);
 
@@ -1236,10 +1236,36 @@ gic_acpi_parse_madt_distributor(struct 
acpi_subtable_header *header,
return 0;
 }
 
+static int gic_acpi_gsi_desc_populate(struct acpi_gsi_descriptor *data,
+ u32 gsi, unsigned int irq_type)
+{
+   /*
+* Encode GSI and triggering information the way the GIC likes
+* them.
+*/
+   if (WARN_ON(gsi < 16))
+   return -EINVAL;
+
+   if (gsi >= 32) {
+   data->param[0] = 0; /* SPI */
+   data->param[1] = gsi - 32;
+   data->param[2] = irq_type;
+   } else {
+   data->param[0] = 1; /* PPI */
+   data->param[1] = gsi - 16;
+   data->param[2] = 0xff << 4 | irq_type;
+   }
+
+   data->param_count = 3;
+
+   return 0;
+}
+
 int __init
 gic_v2_acpi_init(struct acpi_table_header *table)
 {
void __iomem *cpu_base, *dist_base;
+   struct fwnode_handle *domain_handle;
int count;
 
/* Collect CPU base addresses */
@@ -1290,14 +1316,20 @@ gic_v2_acpi_init(struct acpi_table_header *table)
static_key_slow_dec(&supports_deactivate);
 
/*
-* Initialize zero GIC instance (no multi-GIC support). Also, set GIC
-* as default IRQ domain to allow for GSI registration and GSI to IRQ
-* number translation (see acpi_register_gsi() and acpi_gsi_to_irq()).
+* Initialize GIC instance zero (no multi-GIC support).
 */
-   __gic_init_bases(0, -1, dist_base, cpu_base, 0, NULL);
-   irq_set_default_host(gic_data[0].domain);
+   domain_handle = irq_domain_alloc_fwnode(NULL);
+   if (!domain_handle) {
+   pr_err("Unable to allocate domain handle\n");
+   iounmap(cpu_base);
+   iounmap(dist_base);
+   return -ENOMEM;
+   }
+
+   __gic_init_bases(0, -1, dist_base, cpu_base, 0, domain_handle);
 
-   acpi_irq_model = ACPI_IRQ_MODEL_GIC;
+   acpi_set_irq_model(ACPI_IRQ_MODEL_GIC, domain_handle,
+  gi

[PATCH v4 0/9] Making the generic ACPI GSI layer irqdomain aware

[Marc Zyngier]

The irqdomain code is not entierely ACPI friendly, as it has some
built-in knowledge of the device-tree. Nothing too harmful, but enough
to scare the ARM ACPI developpers which end up with their own version
of the square wheel.

This small patch series adapts the irqdomain code to remove the
hurdles that prevent the full blown irqdomain subsystem to be used on
ACPI, creates an interface between the GSI layer and the irqdomain,
and as an example, convert the ARM GIC ACPI support to use irqdomains
as originally intended.

Overall, this gives us a way to use irqdomains on both DT and ACPI
enabled platforms, having very little changes made to the actual
drivers (other than the probing infrastructure). Because we keep the
flow of information between the various layers identical between ACPI
and DT, we immediately benefit from the existing infrastructure. The
"convert the GSI information to be DT friendly" is admitedly not very
pretty, but I see it as a stepping stone towards unifying the two
structures.

This has been test-booted on Juno, is based on 4.3-rc3, and available at:

git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git 
irq/gsi-irq-domain-v4

* From v3:
   - Got rid of the whole "void *" malarchy, and introduce a DT-based
 fwnode_handle allocator. Much smaller patch, better type checking,
 and a path forward to introduce fwnode_handle as the irqdomain
 identifier.
   - Small rework of the GIC stuff (cleanup, mostly).

* From v2:
   - Rebased on vanilla 4.3-rc1
   - Added the IDR infrastructure to irqdomain.c so that drivers don't
 have to come up with their own way of allocating identifiers
   - Changed the acpi_set_irq_model() signature to directly take a
 void *domain_token

* From v1:
  - Improved my Coccinelle foo and hopefully caught all the
irq_domain.of_node users this time
  - Decoupled acpi_irq_model from domain_token. These are now two
separate values that can be set independently
  - Moved the duty of populating acpi_gsi_descriptor to the interrupt
controller, as it keeps the knowledge of the mapping with
of_phandle_args in a single location
  - Generic accessor to set acpi_irq_model, domain_token and the
populate function all in one go from the interrupt controller
  - General cleanup

Marc Zyngier (9):
  drivers/of: Introduce of_node_alloc
  genirq/irqdomain: Add irq_create_acpi_mapping
  genirq/irqdomain: Add a fwnode_handle allocator
  acpi/gsi: Always perform an irq domain lookup
  acpi/gsi: Add acpi_set_irq_model to initialize the GSI layer
  acpi/gsi: Select OF_DYNAMIC when ACPI_GENERIC_GSI is selected
  irqchip/GIC: Get rid of gic_init_bases()
  irqchip/GIC: Switch ACPI support to stacked domains
  acpi/gsi: Cleanup acpi_register_gsi

 drivers/acpi/Kconfig|  1 +
 drivers/acpi/gsi.c  | 61 -
 drivers/irqchip/irq-gic.c   | 66 ++---
 drivers/of/dynamic.c| 22 ++
 include/linux/acpi.h| 14 +
 include/linux/irqchip/arm-gic.h |  9 ++
 include/linux/irqdomain.h   |  2 ++
 include/linux/of.h  |  5 
 kernel/irq/irqdomain.c  | 48 ++
 9 files changed, 183 insertions(+), 45 deletions(-)

-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 3/3] irqchip/gicv3-its: Handle OF device tree "msi-map" properties.

[Marc Zyngier]

On Wed, 23 Sep 2015 18:52:59 +0100
Will Deacon  wrote:

> On Wed, Sep 23, 2015 at 06:08:39PM +0100, David Daney wrote:
> > On 09/23/2015 10:01 AM, Marc Zyngier wrote:
> > > On Tue, 22 Sep 2015 17:00:06 -0700
> > > David Daney  wrote:
> > >
> > >> From: David Daney 
> > >>
> > >> Call of_msi_map_rid() to handle mapping of the requester id.
> > >>
> > >> Signed-off-by: David Daney 
> > >> ---
> > >>   drivers/irqchip/irq-gic-v3-its-pci-msi.c | 3 ++-
> > >>   1 file changed, 2 insertions(+), 1 deletion(-)
> > >>
> > >> diff --git a/drivers/irqchip/irq-gic-v3-its-pci-msi.c 
> > >> b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
> > >> index cf351c6..8b1c938 100644
> > >> --- a/drivers/irqchip/irq-gic-v3-its-pci-msi.c
> > >> +++ b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
> > >> @@ -86,7 +86,8 @@ static int its_pci_msi_prepare(struct irq_domain 
> > >> *domain, struct device *dev,
> > >>  pci_for_each_dma_alias(pdev, its_get_pci_alias, &dev_alias);
> > >>
> > >>  /* ITS specific DeviceID, as the core ITS ignores dev. */
> > >> -info->scratchpad[0].ul = dev_alias.dev_id;
> > >> +info->scratchpad[0].ul = of_msi_map_rid(dev, domain->of_node,
> > >> +dev_alias.dev_id);
> > >>
> > >>  return msi_info->ops->msi_prepare(domain->parent,
> > >>dev, dev_alias.count, info);
> > >
> > > I really wonder if that shouldn't be part of the pci_for_each_dma_alias
> > > call. It would make a lot more sense for this functionality to be an
> > > integral part of the core code, and would probably make the integration
> > > of _IORT (which has the exact same requirements) a bit easier.
> > >
> > > Thoughts?
> > >
> > 
> > I am a proponent of pushing things like this as far into the core code 
> > as possible.  So, from that point of view, I think it would probably be 
> > a good idea.
> > 
> > I can prepare a patch that does that, but it would also be nice hear 
> > from other maintainers and get their thoughts on this.
> 
> Hmm, we use pci_for_each_dma_alias in the SMMU drivers to get the SID,
> so I'm not sure that using the MSI mapping is necessarily the right thing
> to do there. Maybe we should instead have dma_alias_to_msi_id helpers or
> something?

Yes, that's probably a sensible solution.

M.
-- 
Jazz is not dead. It just smells funny.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 3/3] irqchip/gicv3-its: Handle OF device tree "msi-map" properties.

[Marc Zyngier]

On Tue, 22 Sep 2015 17:00:06 -0700
David Daney  wrote:

> From: David Daney 
> 
> Call of_msi_map_rid() to handle mapping of the requester id.
> 
> Signed-off-by: David Daney 
> ---
>  drivers/irqchip/irq-gic-v3-its-pci-msi.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/irqchip/irq-gic-v3-its-pci-msi.c 
> b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
> index cf351c6..8b1c938 100644
> --- a/drivers/irqchip/irq-gic-v3-its-pci-msi.c
> +++ b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
> @@ -86,7 +86,8 @@ static int its_pci_msi_prepare(struct irq_domain *domain, 
> struct device *dev,
>   pci_for_each_dma_alias(pdev, its_get_pci_alias, &dev_alias);
>  
>   /* ITS specific DeviceID, as the core ITS ignores dev. */
> - info->scratchpad[0].ul = dev_alias.dev_id;
> + info->scratchpad[0].ul = of_msi_map_rid(dev, domain->of_node,
> + dev_alias.dev_id);
>  
>   return msi_info->ops->msi_prepare(domain->parent,
> dev, dev_alias.count, info);

I really wonder if that shouldn't be part of the pci_for_each_dma_alias
call. It would make a lot more sense for this functionality to be an
integral part of the core code, and would probably make the integration
of _IORT (which has the exact same requirements) a bit easier.

Thoughts?

M.
-- 
Jazz is not dead. It just smells funny.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/3] of/irq: Add new function of_msi_map_rid()

[Marc Zyngier]

device_node *child);
>  extern void of_msi_configure(struct device *dev, struct device_node *np);
> +u32 of_msi_map_rid(struct device *dev, struct device_node *msi_np, u32 
> rid_in);
>  
>  #else /* !CONFIG_OF */
>  static inline unsigned int irq_of_parse_and_map(struct device_node *dev,
> @@ -87,6 +88,12 @@ static inline void *of_irq_find_parent(struct device_node 
> *child)
>  {
>   return NULL;
>  }
> +
> +static inline u32 of_msi_map_rid(struct device *dev,
> +  struct device_node *msi_np, u32 rid_in)
> +{
> + return rid_in;
> +}
>  #endif /* !CONFIG_OF */
>  
>  #endif /* __OF_IRQ_H */

Otherwise looks good to me.

Reviewed-by: Marc Zyngier 

M.
-- 
Jazz is not dead. It just smells funny.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/3] Docs: dt: Add PCI MSI map bindings

[Marc Zyngier]

On Tue, 22 Sep 2015 17:00:04 -0700
David Daney  wrote:

> From: Mark Rutland 
> 
> Currently msi-parent is used by a few bindings to describe the
> relationship between a PCI root complex and a single MSI controller, but
> this property does not have a generic binding document.
> 
> Additionally, msi-parent is insufficient to describe more complex
> relationships between MSI controllers and devices under a root complex,
> where devices may be able to target multiple MSI controllers, or where
> MSI controllers use (non-probeable) sideband information to distinguish
> devices.
> 
> This patch adds a generic binding for mapping PCI devices to MSI
> controllers. This document covers msi-parent, and a new msi-map property
> (specific to PCI*) which may be used to map devices (identified by their
> Requester ID) to sideband data for each MSI controller that they may
> target.
> 
> Signed-off-by: Mark Rutland 
> Signed-off-by: David Daney 

I thought I had done it already, but nevertheless:

Acked-by: Marc Zyngier 

M.
-- 
Jazz is not dead. It just smells funny.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 3/6] pci:host: Add Altera PCIe host controller driver

[Marc Zyngier]

On Wed, 23 Sep 2015 17:33:09 +0800
Ley Foon Tan  wrote:

> On Wed, Sep 23, 2015 at 2:33 AM, Marc Zyngier  wrote:
> > On Mon, 21 Sep 2015 10:13:04 +0800
> > Ley Foon Tan  wrote:
> >
> >> This patch adds the Altera PCIe host controller driver.
> >>
> >> Signed-off-by: Ley Foon Tan 
> >> ---
> >>  drivers/pci/host/Kconfig   |   8 +
> >>  drivers/pci/host/Makefile  |   1 +
> >>  drivers/pci/host/pcie-altera.c | 591 
> >> +
> >>  3 files changed, 600 insertions(+)
> >>  create mode 100644 drivers/pci/host/pcie-altera.c
> >>
> >> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> >> index d5e58ba..df9ed4f 100644
> >> --- a/drivers/pci/host/Kconfig
> >> +++ b/drivers/pci/host/Kconfig
> >> @@ -145,4 +145,12 @@ config PCIE_IPROC_BCMA
> >> Say Y here if you want to use the Broadcom iProc PCIe controller
> >> through the BCMA bus interface
> >>
> >> +config PCIE_ALTERA
> >> + tristate "Altera PCIe controller"
> >> + depends on ARCH_SOCFPGA || NIOS2
> >> + select PCI_DOMAINS
> >> + help
> >> +   Say Y here if you want to enable PCIe controller support for Altera
> >> +   SoCFPGA family of SoCs.
> >> +
> >
> > Is there anything in this driver that is actually specific to any of
> > these two platforms/architectures? I'd don't think we should restrict
> > if we can avoid it (hint: the companion MSI driver is not restricted to
> > any architecture).
> No specific dependency on these 2 architectures. Then I will remove this.

OK. If you fix this, you can put my

Reviewed-by: Marc Zyngier 

on this patch.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 3/6] pci:host: Add Altera PCIe host controller driver

[Marc Zyngier]

On Mon, 21 Sep 2015 10:13:04 +0800
Ley Foon Tan  wrote:

> This patch adds the Altera PCIe host controller driver.
> 
> Signed-off-by: Ley Foon Tan 
> ---
>  drivers/pci/host/Kconfig   |   8 +
>  drivers/pci/host/Makefile  |   1 +
>  drivers/pci/host/pcie-altera.c | 591 
> +
>  3 files changed, 600 insertions(+)
>  create mode 100644 drivers/pci/host/pcie-altera.c
> 
> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> index d5e58ba..df9ed4f 100644
> --- a/drivers/pci/host/Kconfig
> +++ b/drivers/pci/host/Kconfig
> @@ -145,4 +145,12 @@ config PCIE_IPROC_BCMA
> Say Y here if you want to use the Broadcom iProc PCIe controller
> through the BCMA bus interface
>  
> +config PCIE_ALTERA
> + tristate "Altera PCIe controller"
> + depends on ARCH_SOCFPGA || NIOS2
> + select PCI_DOMAINS
> + help
> +   Say Y here if you want to enable PCIe controller support for Altera
> +   SoCFPGA family of SoCs.
> +

Is there anything in this driver that is actually specific to any of
these two platforms/architectures? I'd don't think we should restrict
if we can avoid it (hint: the companion MSI driver is not restricted to
any architecture).

Thanks,

M.
-- 
Jazz is not dead. It just smells funny.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 1/6] arm: add msi.h to Kbuild

[Marc Zyngier]

On Mon, 21 Sep 2015 10:13:02 +0800
Ley Foon Tan  wrote:

> Include asm-generic/msi.h to support CONFIG_GENERIC_MSI_IRQ_DOMAIN.
> This to fix compilation error:
> "include/linux/msi.h:123:21: fatal error: asm/msi.h:
> No such file or directory"
> 
> Signed-off-by: Ley Foon Tan 

Acked-by: Marc Zyngier 

M.
-- 
Jazz is not dead. It just smells funny.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] irqchip/gicv3-its: Handle OF device tree "msi-map" properties.

[Marc Zyngier]

On Mon, 21 Sep 2015 09:35:51 -0700
David Daney  wrote:

> On 09/21/2015 08:58 AM, Marc Zyngier wrote:
> > On Fri, 18 Sep 2015 10:54:02 -0700
> > David Daney  wrote:
> >
> >> On 09/18/2015 01:51 AM, Marc Zyngier wrote:
> >>> On Thu, 17 Sep 2015 11:00:59 -0700
> >>> David Daney  wrote:
> >>>
> >>> Hi David,
> >>>
> >>>> From: David Daney 
> >>>>
> >>>> Search up the device hierarchy to find devices with a "msi-map"
> >>>> property, if found apply the mapping to the GIC device id.
> >>>>
> >>>> Signed-off-by: David Daney 
> >>>> ---
> >>>>drivers/irqchip/irq-gic-v3-its-pci-msi.c | 73 
> >>>> 
> >>>>1 file changed, 73 insertions(+)
> >>>>
> >>>> diff --git a/drivers/irqchip/irq-gic-v3-its-pci-msi.c 
> >>>> b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
> >>>> index cf351c6..aa61cef 100644
> >>>> --- a/drivers/irqchip/irq-gic-v3-its-pci-msi.c
> >>>> +++ b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
> >>>> @@ -73,6 +73,8 @@ static int its_pci_msi_prepare(struct irq_domain 
> >>>> *domain, struct device *dev,
> >>>>  struct pci_dev *pdev;
> >>>>  struct its_pci_alias dev_alias;
> >>>>  struct msi_domain_info *msi_info;
> >>>> +struct device *parent_dev;
> >>>> +struct device_node *msi_controller_node = NULL;
> >>>>
> >>>>  if (!dev_is_pci(dev))
> >>>>  return -EINVAL;
> >>>> @@ -84,6 +86,77 @@ static int its_pci_msi_prepare(struct irq_domain 
> >>>> *domain, struct device *dev,
> >>>>  dev_alias.count = nvec;
> >>>>
> >>>>  pci_for_each_dma_alias(pdev, its_get_pci_alias, &dev_alias);
> >>>> +/*
> >>>> + * Walk up the device parent links looking for one with a
> >>>> + * "msi-map" property.
> >>>> + */
> >>>
> >>> My first objection is the location of this parsing. It shouldn't be
> >>> driver specific, but instead be part of the generic OF handling
> >>> (nothing in these properties is GICv3 specific, even if the ITS is the
> >>> only user so far).
> >>
> >> OK, I agree that this should eventually end up in generic OF handling
> >> code.  I just wanted to get something out to initiate discussion.
> >>
> >> The next patch revision will move this to a more generic home.
> >>
> >>>
> >>>> +for (parent_dev = dev; parent_dev; parent_dev = 
> >>>> parent_dev->parent) {
> >>>
> >>> Is there a limit how far we should go up the parent chain to find a
> >>> msi-map? My hunch is that you should stop at the first device that does
> >>> have an of_node, as it is the one that should contain the msi-map
> >>> property.
> >>
> >> I think there is the possibility of finding something like a bridge that
> >> has an of_node, but does not have the "msi-map" property.  I currently
> >> have exactly this configuration, as some of the on-SoC devices sit
> >> behind a bridge, but need an of_node to obtain unprobable properties and
> >> children (the MDIO bus devices are like this).
> >>
> >> So if we want to abort the walk early, we should at least go up until we
> >> find "msi-map" in the of_node.
> >
> > I don't really see a case where we would traverse a series of nodes
> > where the msi-map property wouldn't be in the first node. Could you
> > please give me an example?
> >
> 
> OK, how about this:

[...]

> The "msi-map" is specified in the PICe host controller node, but there
> is a bridge between the device generating interrupts "bgx0" and the
> host controller.

OK, I can now see why you're doing that, thanks.


> >> The PCI host may have many MSI controllers, but I think a given PCI
> >> device will have only one (based on bus:devfn) that is looked up in the 
> >> map.
> >
> > A PCI device will only be configured to talk to a single MSI
> > controller, but here you stop parsing the msi-map on the first match,
> > and assume that you must have found the right MSI controller:
> >
> > I think this should read:
> >
> > +   if (masked_devid < rid_base ||
> > +   masked_devid >= rid_base + rid_len ||
> > domain->of_node != 
> > of_find_node_by_phandle(phandle)) {
> > +   msi_map_len -= 4 * sizeof(__be32);
> > +   msi_map += 4;
> > +   continue;
> > +   }
> > +   matched = true;
> > +   break;
> >
> 
> Good, I will incorporate that too.
> 
> In practice, I don't know if we would ever find a system with multiple 
> "msi-map" on a path from the device to the root, but we should probably 
> attempt to handle it "just in case".

There are systems in the wild with exactly that kind of topology, and
I'd like to support them out of the box.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] irqchip/gicv3-its: Handle OF device tree "msi-map" properties.

[Marc Zyngier]

On Fri, 18 Sep 2015 10:54:02 -0700
David Daney  wrote:

> On 09/18/2015 01:51 AM, Marc Zyngier wrote:
> > On Thu, 17 Sep 2015 11:00:59 -0700
> > David Daney  wrote:
> >
> > Hi David,
> >
> >> From: David Daney 
> >>
> >> Search up the device hierarchy to find devices with a "msi-map"
> >> property, if found apply the mapping to the GIC device id.
> >>
> >> Signed-off-by: David Daney 
> >> ---
> >>   drivers/irqchip/irq-gic-v3-its-pci-msi.c | 73 
> >> 
> >>   1 file changed, 73 insertions(+)
> >>
> >> diff --git a/drivers/irqchip/irq-gic-v3-its-pci-msi.c 
> >> b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
> >> index cf351c6..aa61cef 100644
> >> --- a/drivers/irqchip/irq-gic-v3-its-pci-msi.c
> >> +++ b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
> >> @@ -73,6 +73,8 @@ static int its_pci_msi_prepare(struct irq_domain 
> >> *domain, struct device *dev,
> >>struct pci_dev *pdev;
> >>struct its_pci_alias dev_alias;
> >>struct msi_domain_info *msi_info;
> >> +  struct device *parent_dev;
> >> +  struct device_node *msi_controller_node = NULL;
> >>
> >>if (!dev_is_pci(dev))
> >>return -EINVAL;
> >> @@ -84,6 +86,77 @@ static int its_pci_msi_prepare(struct irq_domain 
> >> *domain, struct device *dev,
> >>dev_alias.count = nvec;
> >>
> >>pci_for_each_dma_alias(pdev, its_get_pci_alias, &dev_alias);
> >> +  /*
> >> +   * Walk up the device parent links looking for one with a
> >> +   * "msi-map" property.
> >> +   */
> >
> > My first objection is the location of this parsing. It shouldn't be
> > driver specific, but instead be part of the generic OF handling
> > (nothing in these properties is GICv3 specific, even if the ITS is the
> > only user so far).
> 
> OK, I agree that this should eventually end up in generic OF handling 
> code.  I just wanted to get something out to initiate discussion.
> 
> The next patch revision will move this to a more generic home.
> 
> >
> >> +  for (parent_dev = dev; parent_dev; parent_dev = parent_dev->parent) {
> >
> > Is there a limit how far we should go up the parent chain to find a
> > msi-map? My hunch is that you should stop at the first device that does
> > have an of_node, as it is the one that should contain the msi-map
> > property.
> 
> I think there is the possibility of finding something like a bridge that 
> has an of_node, but does not have the "msi-map" property.  I currently 
> have exactly this configuration, as some of the on-SoC devices sit 
> behind a bridge, but need an of_node to obtain unprobable properties and 
> children (the MDIO bus devices are like this).
> 
> So if we want to abort the walk early, we should at least go up until we 
> find "msi-map" in the of_node.

I don't really see a case where we would traverse a series of nodes
where the msi-map property wouldn't be in the first node. Could you
please give me an example?

[...]

> >> +  msi_controller_node = of_find_node_by_phandle(phandle);
> >> +  if (domain->of_node != msi_controller_node) {
> >> +  dev_err(dev,
> >> +  "ERROR: msi-map mismatch \"%s\" vs. \"%s\"\n",
> >> +  domain->of_node->full_name,
> >> +  msi_controller_node ? NULL : 
> >> msi_controller_node->full_name);
> >
> > Why is that an error? a RC can be configured to master multiple
> > MSI-controllers,
> 
> Something has already associated the PCI device with this 
> MSI-controller.  Therefore I think the reference in the map must refer 
> to this ITS MSI-controller instance.
> 
> 
> > and the kernel picks one of them for a given device.
> > This is illustrated by "Example (5)" in the binding, where a device can
> > master two MSI controllers.
> 
> The PCI host may have many MSI controllers, but I think a given PCI 
> device will have only one (based on bus:devfn) that is looked up in the map.

A PCI device will only be configured to talk to a single MSI
controller, but here you stop parsing the msi-map on the first match,
and assume that you must have found the right MSI controller:

I think this should read:

+   if (masked_devid < rid_base ||
+   masked_devid >= rid_base + rid_len ||
domain->of_node != 
of_find_node_by_phandle(phandle)) {
+   msi_map_len -= 4 * sizeof(__be32);
+   msi_map += 4;
+   continue;
+   }
+   matched = true;
+   break;

Thanks,

M.
-- 
Jazz is not dead. It just smells funny.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] irqchip/gicv3-its: Handle OF device tree "msi-map" properties.

[Marc Zyngier]

On Thu, 17 Sep 2015 11:00:59 -0700
David Daney  wrote:

Hi David,

> From: David Daney 
> 
> Search up the device hierarchy to find devices with a "msi-map"
> property, if found apply the mapping to the GIC device id.
> 
> Signed-off-by: David Daney 
> ---
>  drivers/irqchip/irq-gic-v3-its-pci-msi.c | 73 
> 
>  1 file changed, 73 insertions(+)
> 
> diff --git a/drivers/irqchip/irq-gic-v3-its-pci-msi.c 
> b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
> index cf351c6..aa61cef 100644
> --- a/drivers/irqchip/irq-gic-v3-its-pci-msi.c
> +++ b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
> @@ -73,6 +73,8 @@ static int its_pci_msi_prepare(struct irq_domain *domain, 
> struct device *dev,
>   struct pci_dev *pdev;
>   struct its_pci_alias dev_alias;
>   struct msi_domain_info *msi_info;
> + struct device *parent_dev;
> + struct device_node *msi_controller_node = NULL;
>  
>   if (!dev_is_pci(dev))
>   return -EINVAL;
> @@ -84,6 +86,77 @@ static int its_pci_msi_prepare(struct irq_domain *domain, 
> struct device *dev,
>   dev_alias.count = nvec;
>  
>   pci_for_each_dma_alias(pdev, its_get_pci_alias, &dev_alias);
> + /*
> +  * Walk up the device parent links looking for one with a
> +  * "msi-map" property.
> +  */

My first objection is the location of this parsing. It shouldn't be
driver specific, but instead be part of the generic OF handling
(nothing in these properties is GICv3 specific, even if the ITS is the
only user so far).

> + for (parent_dev = dev; parent_dev; parent_dev = parent_dev->parent) {

Is there a limit how far we should go up the parent chain to find a
msi-map? My hunch is that you should stop at the first device that does
have an of_node, as it is the one that should contain the msi-map
property.

> + u32 msi_mask, masked_devid;
> + u32 rid_base, msi_base, rid_len, phandle;
> + int msi_map_len;
> + const __be32 *msi_map;
> + bool matched;
> +
> + if (!parent_dev->of_node)
> + continue;
> +
> + msi_map = of_get_property(parent_dev->of_node,
> +   "msi-map", &msi_map_len);
> + if (!msi_map)
> + continue;

At this point, you know you do have a msi-map, and anything below this
point won't result in another iteration - they can be taken out of the
loop, avoiding most of your break statements.

> +
> + /* The default is to select all bits. */
> + msi_mask = 0x;
> +
> + /*
> +  * Can be overridden by "msi-mask" property.  If
> +  * of_property_read_u32() fails, the default is
> +  * used.
> +  */
> + of_property_read_u32(parent_dev->of_node,
> +  "msi-mask", &msi_mask);

This should be "msi-map-mask", if I read Mark's binding correctly.

> +
> + masked_devid = msi_mask & dev_alias.dev_id;
> + matched = false;
> + while (msi_map_len >= 4 * sizeof(__be32)) {
> + rid_base = be32_to_cpup(msi_map + 0);
> + phandle = be32_to_cpup(msi_map + 1);
> + msi_base = be32_to_cpup(msi_map + 2);
> + rid_len = be32_to_cpup(msi_map + 3);

Ouch. I wonder if that kind of thing should deserve a generic helper.
of_property_read_u32_array_from_index()? Rob, what do you think?

Also, worth checking that msi_map_len is multiple of 4 (and shout if
it isn't).

> +
> + if (masked_devid < rid_base ||
> + masked_devid >= rid_base + rid_len) {
> + msi_map_len -= 4 * sizeof(__be32);
> + msi_map += 4;
> + continue;
> + }
> + matched = true;
> + break;
> + }
> + if (!matched) {
> + dev_err(dev,
> + "No match in \"msi-map\" of %s for dev_id: 
> %x\n",
> + dev_name(parent_dev), dev_alias.dev_id);

It would probably be useful to also print the node containing the
msi-map property, as this is likely to be the source of the problem.

> + break;
> + }
> +
> + msi_controller_node = of_find_node_by_phandle(phandle);
> + if (domain->of_node != msi_controller_node) {
> + dev_err(dev,
> + "ERROR: msi-map mismatch \"%s\" vs. \"%s\"\n",
> + domain->of_node->full_name,
> + msi_controller_node ? NULL : 
> msi_controller_node->full_name);

Why is that an error? a RC can be configured to master multiple
MSI-controllers, and the kernel picks one of them for a given device.
This is illustrated by "Example (5)"

Re: [PATCH v4 0/4] PCI: arm64/powerpc: Fix parsing of linux,pci-probe-only

[Marc Zyngier]

On 17/09/15 16:30, Bjorn Helgaas wrote:
> On Fri, Sep 04, 2015 at 05:50:07PM +0100, Marc Zyngier wrote:
>> The pci-host-generic driver parses the linux,pci-probe-only property,
>> and assumes that it will have a boolean parameter.
>>
>> Turns out that the Seattle DTS file has a naked "linux,pci-probe-only"
>> property, which leads to the driver dereferencing some unsuspecting
>> memory location. Nothing really bad happens (we end up reading some
>> other bit of DT, fortunately), but that not a reason to keep it this
>> way. Turns out that the Pseries code (where this code was lifted from)
>> may suffer from the same issue.
>>
>> The first patch introduces a common (and fixed) version of that check
>> that can be used by drivers and architectures that require it. The two
>> following patches change the pci-host-generic driver and the powerpc
>> code to use it.
>>
>> Finally, the bad property is removed from the Seatle DTS, because it
>> is simply not necessary (it actually prevents me from using SR-IOV,
>> which otherwise runs fine without the probe-only thing).
>>
>> This has been tested on the offending Seattle board.
>>
>> * From v3:
>>   - Restrict the property lookup to /chosen (Rob)
>>   - Acked-by on patch #4 from Suravee
>>   - I swear this is the last time I rework these patches! ;-)
>>
>> * From v2:
>>   - Use of_property_read_u32 to safely read the property (Rob)
>>   - Add a log message to indicate when we enable probe-only
>> (probably quite useful for debugging)
>>
>> * From v1:
>>   - Consolidate the parsing in of_pci.c (Bjorn)
>>
>> Marc Zyngier (4):
>>   of/pci: Add of_pci_check_probe_only to parse "linux,pci-probe-only"
>>   PCI: pci-host-generic: Fix lookup of linux,pci-probe-only property
>>   powerpc: PCI: Fix lookup of linux,pci-probe-only property
>>   arm64: dts: Drop linux,pci-probe-only from the Seattle DTS
>>
>>  arch/arm64/boot/dts/amd/amd-overdrive.dts |  1 -
>>  arch/powerpc/platforms/pseries/setup.c| 14 ++
>>  drivers/of/of_pci.c   | 28 
>>  drivers/pci/host/pci-host-generic.c   |  9 +
>>  include/linux/of_pci.h|  3 +++
>>  5 files changed, 34 insertions(+), 21 deletions(-)
> 
> Applied with the comment tweak and acks to pci/host-generic for v4.4,
> thanks!

Turns out that the 01.org infrastructure has picked up on a compilation
bug with randconfig. The following patch seems to fix it and should be
applied on the first patch:

diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 485d625..2da5abc 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -6,6 +6,8 @@
 #include 
 #include 
 
+#include 
+
 static inline int __of_pci_pci_compare(struct device_node *node,
   unsigned int data)
 {

Sorry for the annoyance.

M.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 8/8] clocksource: simplify ACPI code in arm_arch_timer.c

[Marc Zyngier]

On 27/08/15 14:51, Fu Wei wrote:
> Hi Thomas, Hanjun
> 
> On 27 August 2015 at 21:40, Thomas Gleixner  wrote:
>> On Thu, 27 Aug 2015, Hanjun Guo wrote:
 [1]: https://lkml.org/lkml/2015/7/29/236

 If that is ok with you, we will introduce similar DECLARE_ thing
 for clock declare.
>>
>> Yes.
> 
> Thanks
> 
>>
>>> Or we can drop this patch from this patch set, and clean up this
>>> patch when the ACPI_DECLARE() infrastructure is ready for upstream.
>>
>> Works either way. I just noticed that hard coded init thing and
>> decided to rant about it :)
> 
> OK, good idea, this patch will be improve by DECLARE_ thing, then upstream.
> drop this from this patchset.
> 
> Great thanks for your help

You probably want to keep an eye on this:

https://lwn.net/Articles/657238/

which implements the necessary infrastructure. I'd appreciate if you
could give it a go to find out if it works for you.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] Documentation: gpio: Update description for X-Gene standby GPIO controller DTS binding

[Marc Zyngier]

On 14/09/15 16:06, Y Vo wrote:
> On Mon, Sep 14, 2015 at 9:47 PM, Arnd Bergmann  wrote:
>> On Monday 14 September 2015 16:39:43 Y Vo wrote:
>>> On Mon, Sep 14, 2015 at 4:11 PM, Arnd Bergmann  wrote:
 On Saturday 12 September 2015 12:55:55 Y Vo wrote:
> On Fri, Sep 11, 2015 at 11:45 PM, Arnd Bergmann  wrote:
>> On Friday 11 September 2015 22:06:58 Y Vo wrote:
>
> Example for configure GPIO_DS13 as interrupt and use as button with
> the current gpio driver:
> gpio-keys {
> compatible = "gpio-keys";
> button@1 {
> label = "POWER";
> linux,code = <116>;
> linux,input-type = <0x1>;
> interrupts = <0x0 0x2d 0x1>;
> };
> };

 Wait, this looks wrong: the gpio driver doesn't actually see
 the connection here and won't be able to configure the interrupt
 correctly. The interrupt is already owned by the gpio driver, so
 you cannot use it in the button node.
>>>
>>> In summary:
>>> - Our GPIO doesn't support interrupt controller.
>>> - There are 6 pins which used the external interrupt from GIC, so all
>>> setup for those irqs are from gic driver. The GPIO driver only
>>> configure to wire those lines.
>>>
>>> For your concern:
>>> - That's correct: if we use that defined, the gpio driver never saw
>>> the connection here (That's why it already is configued at the
>>> beginning).
>>> - At the first time, we tried to use the define: <&sbgpio 13 1>, it
>>> means using the GPIO_DS13, it will go into the GPIO driver to setup,
>>> but there is another problem which I have sent out to all of you:
>>> + It will go into gpio_keys_setup_key (gpio_keys.c driver) function,
>>> then set the irqflags = IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING,
>>> but the gic only support IRQ_TYPE_LEVEL_HIGH && IRQF_TRIGGER_RISING,
>>> so it always returns failed at gpio_keys_setup_key function. Please
>>> see the gic_set_type at gic driver.
>>
>> Hmm, I see now how the event handling in the gpio-keys driver differs
>> between irq mode and gpio mode, where gpio mode relies on getting
>> a separate event for the release. This is certainly something that
>> could be changed in the gpio-keys driver as an extension, but that
>> seems to be what Laxman Dewangan did when he introduced the irq-mode.
>>
>>> static int gic_set_type(struct irq_data *d, unsigned int type)
>>> {
>>> void __iomem *base = gic_dist_base(d);
>>> unsigned int gicirq = gic_irq(d);
>>>
>>> /* Interrupt configuration for SGIs can't be changed */
>>> if (gicirq < 16)
>>> return -EINVAL;
>>>
>>> /* SPIs have restrictions on the supported types */
>>> if (gicirq >= 32 && type != IRQ_TYPE_LEVEL_HIGH &&
>>> type != IRQ_TYPE_EDGE_RISING)
>>> return -EINVAL;
>>>
>>> return gic_configure_irq(gicirq, type, base, NULL);
>>> }
>>> + Another issue: in order gpio_key works it needs the status of GPIO.
>>> For our chip, when the GPIO is configued as interrupt, we need to
>>> access to GIC register to read the real status, it is not acceptable
>>> to implement accessing GIC registers at gpio driver. The function
>>> irq_get_irqchip_state(..) also doesn't work in our chip too. Because
>>> it needs to access different offset.
>>
>> I thought we had solved that problem long ago when you first
>> submitted the driver.
>>
>> Did 1b7047edfcfb25 ("genirq: Allow the irqchip state of an IRQ to be
>> save/restored") not address the problem for you? You were on
>> Cc to that patch and should have spoken up when the code that was
>> merged was not sufficient.
> 
> Yes, I am in this mail-list too, but I also had a issue on this, I
> think you are still in my submitted for this.
> Currently, irq_get|set_irqchip_state(..) supports access to
> GIC_DIST_ENABLE_SET, GIC_DIST_ACTIVE_SET, GIC_DIST_PENDING_SET. But
> our hw only has the valid value at SPISR register ("[PATCH v4 2/3]
> irqchip: GIC: Add support for irq_{get,set}_irqchip_state"), so I
> still can not use it.

And I asked Feng Kan to explain *why* it doesn't work, but nobody ever
bothered giving me a straight answer on that:

https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg892972.html

The GIC400 TRM explicitly states that reading GICD_SPISRn is the same as
reading GICD_ICPENDRn. if that doesn't work for you please explain why.

If I can get a reasonable explanation on *why* it doesn't work, then we
can look at having an X-Gene specific workaround.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] arm64: dts: add dts files for Hisilicon Hip05-D02 Development Board

[Marc Zyngier]

On Sat, 5 Sep 2015 10:58:59 +0800
Ding Tianhong  wrote:

> Add initial dtsi file to support Hisilicon Hip05-D02 Board with
> support of CPUs in four clusters and each cluster has quard Cortex-A57.
> 
> Also add dts file to support Hip05-D02 development board.
> 
> Signed-off-by: Ding Tianhong 
> Signed-off-by: Kefeng Wang 
> ---
>  arch/arm64/boot/dts/hisilicon/Makefile  |   2 +-
>  arch/arm64/boot/dts/hisilicon/hip05-d02.dts |  36 
>  arch/arm64/boot/dts/hisilicon/hip05.dtsi| 271 
> 
>  3 files changed, 308 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm64/boot/dts/hisilicon/hip05-d02.dts
>  create mode 100644 arch/arm64/boot/dts/hisilicon/hip05.dtsi
> 
> diff --git a/arch/arm64/boot/dts/hisilicon/Makefile 
> b/arch/arm64/boot/dts/hisilicon/Makefile
> index fa81a6e..cd158b8 100644
> --- a/arch/arm64/boot/dts/hisilicon/Makefile
> +++ b/arch/arm64/boot/dts/hisilicon/Makefile
> @@ -1,4 +1,4 @@
> -dtb-$(CONFIG_ARCH_HISI) += hi6220-hikey.dtb
> +dtb-$(CONFIG_ARCH_HISI) += hi6220-hikey.dtb hip05-d02.dtb
>  
>  always   := $(dtb-y)
>  subdir-y := $(dts-dirs)
> diff --git a/arch/arm64/boot/dts/hisilicon/hip05-d02.dts 
> b/arch/arm64/boot/dts/hisilicon/hip05-d02.dts
> new file mode 100644
> index 000..ae34e25
> --- /dev/null
> +++ b/arch/arm64/boot/dts/hisilicon/hip05-d02.dts
> @@ -0,0 +1,36 @@
> +/**
> + * dts file for Hisilicon D02 Development Board
> + *
> + * Copyright (C) 2014,2015 Hisilicon Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * publishhed by the Free Software Foundation.
> + *
> + */
> +
> +/dts-v1/;
> +
> +#include "hip05.dtsi"
> +
> +/ {
> + model = "Hisilicon Hip05 D02 Development Board";
> + compatible = "hisilicon,hip05-d02";
> +
> + memory@ {
> + device_type = "memory";
> + reg = <0x0 0x 0x0 0x8000>;
> + };
> +
> + aliases {
> + serial0 = &uart0;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +};
> +
> +&uart0 {
> + status = "ok";
> +};
> diff --git a/arch/arm64/boot/dts/hisilicon/hip05.dtsi 
> b/arch/arm64/boot/dts/hisilicon/hip05.dtsi
> new file mode 100644
> index 000..92d00f4
> --- /dev/null
> +++ b/arch/arm64/boot/dts/hisilicon/hip05.dtsi
> @@ -0,0 +1,271 @@
> +/**
> + * dts file for Hisilicon D02 Development Board
> + *
> + * Copyright (C) 2014,2015 Hisilicon Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * publishhed by the Free Software Foundation.
> + *
> + */
> +
> +#include 
> +
> +/ {
> + compatible = "hisilicon,hip05-d02";
> + interrupt-parent = <&gic>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + psci {
> + compatible = "arm,psci-0.2";
> + method = "smc";
> + };
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu-map {
> + cluster0 {
> + core0 {
> + cpu = <&cpu0>;
> + };
> + core1 {
> + cpu = <&cpu1>;
> + };
> + core2 {
> + cpu = <&cpu2>;
> + };
> + core3 {
> + cpu = <&cpu3>;
> + };
> + };
> + cluster1 {
> + core0 {
> + cpu = <&cpu4>;
> + };
> + core1 {
> + cpu = <&cpu5>;
> + };
> + core2 {
> + cpu = <&cpu6>;
> + };
> + core3 {
> + cpu = <&cpu7>;
> + };
> + };
> + cluster2 {
> + core0 {
> + cpu = <&cpu8>;
> + };
> + core1 {
> + cpu = <&cpu9>;
> + };
> + core2 {
> + cpu = <&cpu10>;
> + };
> + core3 {
> + cpu = <&cpu11>;
> + };
> + };
> + cluster3 {
> + core0 {
> +  

Re: [PATCH 0/2] arm64: Support Hisilicon Hip05-D02 board

[Marc Zyngier]

On Sat, 5 Sep 2015 10:58:57 +0800
Ding Tianhong  wrote:

> Hip05-D02 Development Board is based on Cortex-A57, this patchset
> contains initial support for Hip05-D02 Soc and Board. Initial support
> is minimal and includes just the arch configuration, device tree
> configuration.
> 
> PSCI is enabled in device tree and there is no problem to boot all the
> 16 cores, and the CPU hotplug is also working now, you can download and
> compile the latest firmware based on the following link to run this
> patch set.
> 
> https://github.com/hisilicon/estuary/blob/master/README
> 
> v1->v2:
> - 1. Change the compatible name for per CPU.
>   2. Remove the GIC_CPU_MASK_SIMPLE(xx) which is not used for gicv3
>  from hip05.dtsi.

Please always indicate the version number in the email subject ("PATCH
v2" is the usual scheme). It makes it otherwise difficult to keep track
of what version I am looking at.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 0/4] PCI: arm64/powerpc: Fix parsing of linux,pci-probe-only

[Marc Zyngier]

The pci-host-generic driver parses the linux,pci-probe-only property,
and assumes that it will have a boolean parameter.

Turns out that the Seattle DTS file has a naked "linux,pci-probe-only"
property, which leads to the driver dereferencing some unsuspecting
memory location. Nothing really bad happens (we end up reading some
other bit of DT, fortunately), but that not a reason to keep it this
way. Turns out that the Pseries code (where this code was lifted from)
may suffer from the same issue.

The first patch introduces a common (and fixed) version of that check
that can be used by drivers and architectures that require it. The two
following patches change the pci-host-generic driver and the powerpc
code to use it.

Finally, the bad property is removed from the Seatle DTS, because it
is simply not necessary (it actually prevents me from using SR-IOV,
which otherwise runs fine without the probe-only thing).

This has been tested on the offending Seattle board.

* From v3:
  - Restrict the property lookup to /chosen (Rob)
  - Acked-by on patch #4 from Suravee
  - I swear this is the last time I rework these patches! ;-)

* From v2:
  - Use of_property_read_u32 to safely read the property (Rob)
  - Add a log message to indicate when we enable probe-only
(probably quite useful for debugging)

* From v1:
  - Consolidate the parsing in of_pci.c (Bjorn)

Marc Zyngier (4):
  of/pci: Add of_pci_check_probe_only to parse "linux,pci-probe-only"
  PCI: pci-host-generic: Fix lookup of linux,pci-probe-only property
  powerpc: PCI: Fix lookup of linux,pci-probe-only property
  arm64: dts: Drop linux,pci-probe-only from the Seattle DTS

 arch/arm64/boot/dts/amd/amd-overdrive.dts |  1 -
 arch/powerpc/platforms/pseries/setup.c| 14 ++
 drivers/of/of_pci.c   | 28 
 drivers/pci/host/pci-host-generic.c   |  9 +
 include/linux/of_pci.h|  3 +++
 5 files changed, 34 insertions(+), 21 deletions(-)

-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 1/4] of/pci: Add of_pci_check_probe_only to parse "linux,pci-probe-only"

[Marc Zyngier]

Both pci-host-generic and Pseries parse the "linux,pci-probe-only"
property to engage the PCI_PROBE_ONLY mode, and both have a subtle
bug that can be triggered if the property has no parameter.

Provide a generic, safe implementation that can be used by both.

Signed-off-by: Marc Zyngier 
---
 drivers/of/of_pci.c| 28 
 include/linux/of_pci.h |  3 +++
 2 files changed, 31 insertions(+)

diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 5751dc5..5dd4966 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -118,6 +118,34 @@ int of_get_pci_domain_nr(struct device_node *node)
 EXPORT_SYMBOL_GPL(of_get_pci_domain_nr);
 
 /**
+ * of_pci_check_probe_only - Setup probe only mode if linux,pci-probe-only
+ *   is present and valid
+ *
+ * @node: device tree node that may contain the property (usually "chosen")
+ *
+ */
+void of_pci_check_probe_only(void)
+{
+   u32 val;
+   int ret;
+
+   ret = of_property_read_u32(of_chosen, "linux,pci-probe-only", &val);
+   if (ret) {
+   if (ret == -ENODATA || ret == -EOVERFLOW)
+   pr_warn("linux,pci-probe-only without valid value, 
ignoring\n");
+   return;
+   }
+
+   if (val)
+   pci_add_flags(PCI_PROBE_ONLY);
+   else
+   pci_clear_flags(PCI_PROBE_ONLY);
+
+   pr_info("PCI: PROBE_ONLY %sabled\n", val ? "en" : "dis");
+}
+EXPORT_SYMBOL_GPL(of_pci_check_probe_only);
+
+/**
  * of_pci_dma_configure - Setup DMA configuration
  * @dev: ptr to pci_dev struct of the PCI device
  *
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index 29fd3fe..38c0533 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -17,6 +17,7 @@ int of_irq_parse_and_map_pci(const struct pci_dev *dev, u8 
slot, u8 pin);
 int of_pci_parse_bus_range(struct device_node *node, struct resource *res);
 int of_get_pci_domain_nr(struct device_node *node);
 void of_pci_dma_configure(struct pci_dev *pci_dev);
+void of_pci_check_probe_only(void);
 #else
 static inline int of_irq_parse_pci(const struct pci_dev *pdev, struct 
of_phandle_args *out_irq)
 {
@@ -53,6 +54,8 @@ of_get_pci_domain_nr(struct device_node *node)
 }
 
 static inline void of_pci_dma_configure(struct pci_dev *pci_dev) { }
+
+static inline void of_pci_check_probe_only(void) { }
 #endif
 
 #if defined(CONFIG_OF_ADDRESS)
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 4/4] arm64: dts: Drop linux,pci-probe-only from the Seattle DTS

[Marc Zyngier]

The linux,pci-probe-only property mandates an argument to indicate
whether or not to engage the "probe-only" mode, but the Seattle
DTS just provides a naked property, which is illegal.

Also, it turns out that the board is perfectly happy without
probe-only, so let's drop this altogether.

Acked-by: Suravee Suthikulpanit 
Signed-off-by: Marc Zyngier 
---
 arch/arm64/boot/dts/amd/amd-overdrive.dts | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm64/boot/dts/amd/amd-overdrive.dts 
b/arch/arm64/boot/dts/amd/amd-overdrive.dts
index 564a3f7..128fa94 100644
--- a/arch/arm64/boot/dts/amd/amd-overdrive.dts
+++ b/arch/arm64/boot/dts/amd/amd-overdrive.dts
@@ -14,7 +14,6 @@
 
chosen {
stdout-path = &serial0;
-   linux,pci-probe-only;
};
 };
 
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 3/4] powerpc: PCI: Fix lookup of linux,pci-probe-only property

[Marc Zyngier]

When find_and_init_phbs() looks for the probe-only property, it seems
to trust the firmware to be correctly written, and assumes that there
is a parameter to the property.

It is conceivable that the firmware could not be that perfect, and it
could expose this property naked (at least one arm64 platform seems to
exhibit this exact behaviour). The setup code the ends up making
a decision based on whatever the property pointer points to, which
is likely to be junk.

Instead, switch to the common of_pci.c implementation that doesn't
suffer from this problem and ignore the property if the firmware
couldn't make up its mind.

Signed-off-by: Marc Zyngier 
---
 arch/powerpc/platforms/pseries/setup.c | 14 ++
 1 file changed, 2 insertions(+), 12 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/setup.c 
b/arch/powerpc/platforms/pseries/setup.c
index 39a74fa..6016709 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -40,6 +40,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -495,18 +496,7 @@ static void __init find_and_init_phbs(void)
 * PCI_PROBE_ONLY and PCI_REASSIGN_ALL_BUS can be set via properties
 * in chosen.
 */
-   if (of_chosen) {
-   const int *prop;
-
-   prop = of_get_property(of_chosen,
-   "linux,pci-probe-only", NULL);
-   if (prop) {
-   if (*prop)
-   pci_add_flags(PCI_PROBE_ONLY);
-   else
-   pci_clear_flags(PCI_PROBE_ONLY);
-   }
-   }
+   of_pci_check_probe_only();
 }
 
 static void __init pSeries_setup_arch(void)
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 2/4] PCI: pci-host-generic: Fix lookup of linux,pci-probe-only property

[Marc Zyngier]

When pci-host-generic looks for the probe-only property, it seems
to trust the DT to be correctly written, and assumes that there
is a parameter to the property.

Unfortunately, this is not always the case, and some firmware expose
this property naked. The driver ends up making a decision based on
whatever the property pointer points to, which is likely to be junk.

Switch to the common of_pci.c implementation that doesn't suffer
from this problem.

Signed-off-by: Marc Zyngier 
---
 drivers/pci/host/pci-host-generic.c | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/drivers/pci/host/pci-host-generic.c 
b/drivers/pci/host/pci-host-generic.c
index 265dd25..224303d 100644
--- a/drivers/pci/host/pci-host-generic.c
+++ b/drivers/pci/host/pci-host-generic.c
@@ -210,7 +210,6 @@ static int gen_pci_probe(struct platform_device *pdev)
int err;
const char *type;
const struct of_device_id *of_id;
-   const int *prop;
struct device *dev = &pdev->dev;
struct device_node *np = dev->of_node;
struct gen_pci *pci = devm_kzalloc(dev, sizeof(*pci), GFP_KERNEL);
@@ -225,13 +224,7 @@ static int gen_pci_probe(struct platform_device *pdev)
return -EINVAL;
}
 
-   prop = of_get_property(of_chosen, "linux,pci-probe-only", NULL);
-   if (prop) {
-   if (*prop)
-   pci_add_flags(PCI_PROBE_ONLY);
-   else
-   pci_clear_flags(PCI_PROBE_ONLY);
-   }
+   of_pci_check_probe_only();
 
of_id = of_match_node(gen_pci_of_match, np);
pci->cfg.ops = of_id->data;
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 1/4] of/pci: Add of_pci_check_probe_only to parse "linux,pci-probe-only"

[Marc Zyngier]

Both pci-host-generic and Pseries parse the "linux,pci-probe-only"
property to engage the PCI_PROBE_ONLY mode, and both have a subtle
bug that can be triggered if the property has no parameter.

Provide a generic, safe implementation that can be used by both.

Signed-off-by: Marc Zyngier 
---
 drivers/of/of_pci.c| 31 +++
 include/linux/of_pci.h |  3 +++
 2 files changed, 34 insertions(+)

diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 5751dc5..7876343 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -118,6 +118,37 @@ int of_get_pci_domain_nr(struct device_node *node)
 EXPORT_SYMBOL_GPL(of_get_pci_domain_nr);
 
 /**
+ * of_pci_check_probe_only - Setup probe only mode if linux,pci-probe-only
+ *   is present and valid
+ *
+ * @node: device tree node that may contain the property (usually "chosen")
+ *
+ */
+void of_pci_check_probe_only(struct device_node *node)
+{
+   u32 val;
+   int ret;
+
+   if (!node)
+   return;
+
+   ret = of_property_read_u32(node, "linux,pci-probe-only", &val);
+   if (ret) {
+   if (ret == -ENODATA || ret == -EOVERFLOW)
+   pr_warn("linux,pci-probe-only without valid value, 
ignoring\n");
+   return;
+   }
+
+   if (val)
+   pci_add_flags(PCI_PROBE_ONLY);
+   else
+   pci_clear_flags(PCI_PROBE_ONLY);
+
+   pr_info("PCI: PROBE_ONLY %sabled\n", val ? "en" : "dis");
+}
+EXPORT_SYMBOL_GPL(of_pci_check_probe_only);
+
+/**
  * of_pci_dma_configure - Setup DMA configuration
  * @dev: ptr to pci_dev struct of the PCI device
  *
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index 29fd3fe..4c0a617 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -17,6 +17,7 @@ int of_irq_parse_and_map_pci(const struct pci_dev *dev, u8 
slot, u8 pin);
 int of_pci_parse_bus_range(struct device_node *node, struct resource *res);
 int of_get_pci_domain_nr(struct device_node *node);
 void of_pci_dma_configure(struct pci_dev *pci_dev);
+void of_pci_check_probe_only(struct device_node *node);
 #else
 static inline int of_irq_parse_pci(const struct pci_dev *pdev, struct 
of_phandle_args *out_irq)
 {
@@ -53,6 +54,8 @@ of_get_pci_domain_nr(struct device_node *node)
 }
 
 static inline void of_pci_dma_configure(struct pci_dev *pci_dev) { }
+
+static inline void of_pci_check_probe_only(struct device_node *node) { }
 #endif
 
 #if defined(CONFIG_OF_ADDRESS)
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 3/4] powerpc: PCI: Fix lookup of linux,pci-probe-only property

[Marc Zyngier]

When find_and_init_phbs() looks for the probe-only property, it seems
to trust the firmware to be correctly written, and assumes that there
is a parameter to the property.

It is conceivable that the firmware could not be that perfect, and it
could expose this property naked (at least one arm64 platform seems to
exhibit this exact behaviour). The setup code the ends up making
a decision based on whatever the property pointer points to, which
is likely to be junk.

Instead, switch to the common of_pci.c implementation that doesn't
suffer from this problem and ignore the property if the firmware
couldn't make up its mind.

Signed-off-by: Marc Zyngier 
---
 arch/powerpc/platforms/pseries/setup.c | 14 ++
 1 file changed, 2 insertions(+), 12 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/setup.c 
b/arch/powerpc/platforms/pseries/setup.c
index 39a74fa..412531f 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -40,6 +40,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -495,18 +496,7 @@ static void __init find_and_init_phbs(void)
 * PCI_PROBE_ONLY and PCI_REASSIGN_ALL_BUS can be set via properties
 * in chosen.
 */
-   if (of_chosen) {
-   const int *prop;
-
-   prop = of_get_property(of_chosen,
-   "linux,pci-probe-only", NULL);
-   if (prop) {
-   if (*prop)
-   pci_add_flags(PCI_PROBE_ONLY);
-   else
-   pci_clear_flags(PCI_PROBE_ONLY);
-   }
-   }
+   of_pci_check_probe_only(of_chosen);
 }
 
 static void __init pSeries_setup_arch(void)
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 4/4] arm64: dts: Drop linux,pci-probe-only from the Seattle DTS

[Marc Zyngier]

The linux,pci-probe-only property mandates an argument to indicate
whether or not to engage the "probe-only" mode, but the Seattle
DTS just provides a naked property, which is illegal.

Also, it turns out that the board is perfectly happy without
probe-only, so let's drop this altogether.

Signed-off-by: Marc Zyngier 
---
 arch/arm64/boot/dts/amd/amd-overdrive.dts | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm64/boot/dts/amd/amd-overdrive.dts 
b/arch/arm64/boot/dts/amd/amd-overdrive.dts
index 564a3f7..128fa94 100644
--- a/arch/arm64/boot/dts/amd/amd-overdrive.dts
+++ b/arch/arm64/boot/dts/amd/amd-overdrive.dts
@@ -14,7 +14,6 @@
 
chosen {
stdout-path = &serial0;
-   linux,pci-probe-only;
};
 };
 
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 2/4] PCI: pci-host-generic: Fix lookup of linux,pci-probe-only property

[Marc Zyngier]

When pci-host-generic looks for the probe-only property, it seems
to trust the DT to be correctly written, and assumes that there
is a parameter to the property.

Unfortunately, this is not always the case, and some firmware expose
this property naked. The driver ends up making a decision based on
whatever the property pointer points to, which is likely to be junk.

Switch to the common of_pci.c implementation that doesn't suffer
from this problem.

Signed-off-by: Marc Zyngier 
---
 drivers/pci/host/pci-host-generic.c | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/drivers/pci/host/pci-host-generic.c 
b/drivers/pci/host/pci-host-generic.c
index 265dd25..545ff4e 100644
--- a/drivers/pci/host/pci-host-generic.c
+++ b/drivers/pci/host/pci-host-generic.c
@@ -210,7 +210,6 @@ static int gen_pci_probe(struct platform_device *pdev)
int err;
const char *type;
const struct of_device_id *of_id;
-   const int *prop;
struct device *dev = &pdev->dev;
struct device_node *np = dev->of_node;
struct gen_pci *pci = devm_kzalloc(dev, sizeof(*pci), GFP_KERNEL);
@@ -225,13 +224,7 @@ static int gen_pci_probe(struct platform_device *pdev)
return -EINVAL;
}
 
-   prop = of_get_property(of_chosen, "linux,pci-probe-only", NULL);
-   if (prop) {
-   if (*prop)
-   pci_add_flags(PCI_PROBE_ONLY);
-   else
-   pci_clear_flags(PCI_PROBE_ONLY);
-   }
+   of_pci_check_probe_only(of_chosen);
 
of_id = of_match_node(gen_pci_of_match, np);
pci->cfg.ops = of_id->data;
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 0/4] PCI: arm64/powerpc: Fix parsing of linux,pci-probe-only

[Marc Zyngier]

The pci-host-generic driver parses the linux,pci-probe-only property,
and assumes that it will have a boolean parameter.

Turns out that the Seattle DTS file has a naked "linux,pci-probe-only"
property, which leads to the driver dereferencing some unsuspecting
memory location. Nothing really bad happens (we end up reading some
other bit of DT, fortunately), but that not a reason to keep it this
way. Turns out that the Pseries code (where this code was lifted from)
may suffer from the same issue.

The first patch introduces a common (and fixed) version of that check
that can be used by drivers and architectures that require it. The two
following patches change the pci-host-generic driver and the powerpc
code to use it.

Finally, the bad property is removed from the Seatle DTS, because it
is simply not necessary (it actually prevents me from using SR-IOV,
which otherwise runs fine without the probe-only thing).

This has been tested on the offending Seattle board.

* From v2:
  - Use of_property_read_u32 to safely read the property (Rob)
  - Add a log message to indicate when we enable probe-only
(probably quite useful for debugging)

* From v1:
  - Consolidate the parsing in of_pci.c (Bjorn)

Marc Zyngier (4):
  of/pci: Add of_pci_check_probe_only to parse "linux,pci-probe-only"
  PCI: pci-host-generic: Fix lookup of linux,pci-probe-only property
  powerpc: PCI: Fix lookup of linux,pci-probe-only property
  arm64: dts: Drop linux,pci-probe-only from the Seattle DTS

 arch/arm64/boot/dts/amd/amd-overdrive.dts |  1 -
 arch/powerpc/platforms/pseries/setup.c| 14 ++
 drivers/of/of_pci.c   | 31 +++
 drivers/pci/host/pci-host-generic.c   |  9 +
 include/linux/of_pci.h|  3 +++
 5 files changed, 37 insertions(+), 21 deletions(-)

-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/4] of/pci: Add of_pci_check_probe_only to parse "linux,pci-probe-only"

[Marc Zyngier]

On 02/09/15 23:23, Bjorn Helgaas wrote:
> On Fri, Aug 14, 2015 at 04:08:10PM -0500, Rob Herring wrote:
>> On Fri, Aug 14, 2015 at 11:19 AM, Marc Zyngier  wrote:
>>> Both pci-host-generic and Pseries parse the "linux,pci-probe-only"
>>> to engage the PCI_PROBE_ONLY mode, and both have a subtle bug that
>>> can be triggered if the property has no parameter.
>>
>> Humm, I bet we could break a lot of machines if we fixed the core code
>> to properly make pp->value NULL when there is no value.
>>
>>> Provide a generic implementation that can be used by both.
>>>
>>> Signed-off-by: Marc Zyngier 
>>> ---
>>>  drivers/of/of_pci.c| 30 ++
>>>  include/linux/of_pci.h |  3 +++
>>>  2 files changed, 33 insertions(+)
>>>
>>> diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
>>> index 5751dc5..a4e29ff 100644
>>> --- a/drivers/of/of_pci.c
>>> +++ b/drivers/of/of_pci.c
>>> @@ -118,6 +118,36 @@ int of_get_pci_domain_nr(struct device_node *node)
>>>  EXPORT_SYMBOL_GPL(of_get_pci_domain_nr);
>>>
>>>  /**
>>> + * of_pci_check_probe_only - Setup probe only mode if linux,pci-probe-only
>>> + *   is present and valid
>>> + *
>>> + * @node: device tree node that may contain the property (usually "chosen")
>>> + *
>>> + */
>>> +void of_pci_check_probe_only(struct device_node *node)
>>> +{
>>> +   const int *prop;
>>> +   int len;
>>> +
>>> +   if (!node)
>>> +   return;
>>> +
>>> +   prop = of_get_property(node, "linux,pci-probe-only", &len);
>>
>> It is preferred to use of_property_read_u32 to avoid just these types
>> of problems.
> 
> I don't know enough OF to really understand this, but I infer that
> this is a suggestion for improving the patch.  Should I be waiting for
> a v3 series?

Yes, I'll post an update very shortly. Thanks for reminding me!

M.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] arm64: dts: add dts files for Hisilicon Hip05-D02 Development Board

[Marc Zyngier]

[Don't top-post, this is very annoying]

On 02/09/15 05:28, Ding Tianhong wrote:
> Hi，Marc：
> 
> Can you check this, I am not sure whether the GIC_CPU_MASK_SIMPLE(xx)
> is used for gic-v3, maybe we should remove it, thanks.

The binding documentation
(Documentation/devicetree/bindings/arm/gic-v3.txt) is very clear:

  The 3rd cell is the flags, encoded as follows:
bits[3:0] trigger type and level flags.
1 = edge triggered
4 = level triggered

There is no mask whatsoever, because that would restrict the interrupt
to only 32 CPUs at most.

So please remove this, this is just wrong.

Thanks,

M.

> Ding
> 
> On 2015/8/31 21:44, Ding Tianhong wrote:
>> On 2015/8/31 21:12, Leo Yan wrote:
>>> On Sat, Aug 29, 2015 at 04:52:41PM +0800, Ding Tianhong wrote:
 Add initial dtsi file to support Hisilicon Hip05-D02 Board with
 support of CPUs in four clusters and each cluster has quard Cortex-A57.

 Also add dts file to support Hip05-D02 development board.

 Signed-off-by: Ding Tianhong 
 Signed-off-by: Kefeng Wang 
 ---
  arch/arm64/boot/dts/hisilicon/Makefile  |   2 +-
  arch/arm64/boot/dts/hisilicon/hip05-d02.dts |  36 
  arch/arm64/boot/dts/hisilicon/hip05.dtsi| 271 
 
  3 files changed, 308 insertions(+), 1 deletion(-)
  create mode 100644 arch/arm64/boot/dts/hisilicon/hip05-d02.dts
  create mode 100644 arch/arm64/boot/dts/hisilicon/hip05.dtsi

 diff --git a/arch/arm64/boot/dts/hisilicon/Makefile 
 b/arch/arm64/boot/dts/hisilicon/Makefile
 index fa81a6e..cd158b8 100644
 --- a/arch/arm64/boot/dts/hisilicon/Makefile
 +++ b/arch/arm64/boot/dts/hisilicon/Makefile
 @@ -1,4 +1,4 @@
 -dtb-$(CONFIG_ARCH_HISI) += hi6220-hikey.dtb
 +dtb-$(CONFIG_ARCH_HISI) += hi6220-hikey.dtb hip05-d02.dtb
  
  always:= $(dtb-y)
  subdir-y  := $(dts-dirs)
 diff --git a/arch/arm64/boot/dts/hisilicon/hip05-d02.dts 
 b/arch/arm64/boot/dts/hisilicon/hip05-d02.dts
 new file mode 100644
 index 000..ae34e25
 --- /dev/null
 +++ b/arch/arm64/boot/dts/hisilicon/hip05-d02.dts
 @@ -0,0 +1,36 @@
 +/**
 + * dts file for Hisilicon D02 Development Board
 + *
 + * Copyright (C) 2014,2015 Hisilicon Ltd.
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2 as
 + * publishhed by the Free Software Foundation.
 + *
 + */
 +
 +/dts-v1/;
 +
 +#include "hip05.dtsi"
 +
 +/ {
 +  model = "Hisilicon Hip05 D02 Development Board";
 +  compatible = "hisilicon,hip05-d02";
 +
 +  memory@ {
 +  device_type = "memory";
 +  reg = <0x0 0x 0x0 0x8000>;
 +  };
 +
 +  aliases {
 +  serial0 = &uart0;
 +  };
 +
 +  chosen {
 +  stdout-path = "serial0:115200n8";
 +  };
 +};
 +
 +&uart0 {
 +  status = "ok";
 +};
 diff --git a/arch/arm64/boot/dts/hisilicon/hip05.dtsi 
 b/arch/arm64/boot/dts/hisilicon/hip05.dtsi
 new file mode 100644
 index 000..da12d94
 --- /dev/null
 +++ b/arch/arm64/boot/dts/hisilicon/hip05.dtsi
 @@ -0,0 +1,271 @@
 +/**
 + * dts file for Hisilicon D02 Development Board
 + *
 + * Copyright (C) 2014,2015 Hisilicon Ltd.
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2 as
 + * publishhed by the Free Software Foundation.
 + *
 + */
 +
 +#include 
 +
 +/ {
 +  compatible = "hisilicon,hip05-d02";
 +  interrupt-parent = <&gic>;
 +  #address-cells = <2>;
 +  #size-cells = <2>;
 +
 +  psci {
 +  compatible = "arm,psci-0.2";
 +  method = "smc";
 +  };
 +
 +  cpus {
 +  #address-cells = <1>;
 +  #size-cells = <0>;
 +
 +  cpu-map {
 +  cluster0 {
 +  core0 {
 +  cpu = <&cpu0>;
 +  };
 +  core1 {
 +  cpu = <&cpu1>;
 +  };
 +  core2 {
 +  cpu = <&cpu2>;
 +  };
 +  core3 {
 +  cpu = <&cpu3>;
 +  };
 +  };
 +  cluster1 {
 +  core0 {
 +  cpu = <&cpu4>;
 +  };
 +  core1 {
 +  cpu = <&cpu5>;
 +

Re: [PATCH v6 0/6] Altera PCIe host controller driver with MSI support

[Marc Zyngier]

On 01/09/15 11:30, Ley Foon Tan wrote:
> This is the 6th version of patch set to add support for Altera PCIe host
> controller with MSI feature on Altera FPGA device families. This patchset
> mainly resolve comments from Marc Zyngier in v5 and minor fixes.

The merge window has just started, and I'm not going to go through
another review at that stage - too many things in flight.

Please ping me again once 4.3-rc1 is out.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 2/5] pci:host: Add Altera PCIe host controller driver

[Marc Zyngier]

On 25/08/15 10:35, Ley Foon Tan wrote:
> This patch adds the Altera PCIe host controller driver.
> 
> Signed-off-by: Ley Foon Tan 
> ---
>  drivers/pci/host/Kconfig   |   7 +
>  drivers/pci/host/Makefile  |   1 +
>  drivers/pci/host/pcie-altera.c | 588 
> +
>  3 files changed, 596 insertions(+)
>  create mode 100644 drivers/pci/host/pcie-altera.c
> 
> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> index 675c2d1..4b4754a 100644
> --- a/drivers/pci/host/Kconfig
> +++ b/drivers/pci/host/Kconfig
> @@ -145,4 +145,11 @@ config PCIE_IPROC_BCMA
> Say Y here if you want to use the Broadcom iProc PCIe controller
> through the BCMA bus interface
>  
> +config PCIE_ALTERA
> + tristate "Altera PCIe controller"
> + depends on ARCH_SOCFPGA
> + help
> +   Say Y here if you want to enable PCIe controller support for Altera
> +   SoCFPGA family of SoCs.
> +
>  endmenu
> diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
> index 140d66f..6954f76 100644
> --- a/drivers/pci/host/Makefile
> +++ b/drivers/pci/host/Makefile
> @@ -17,3 +17,4 @@ obj-$(CONFIG_PCI_VERSATILE) += pci-versatile.o
>  obj-$(CONFIG_PCIE_IPROC) += pcie-iproc.o
>  obj-$(CONFIG_PCIE_IPROC_PLATFORM) += pcie-iproc-platform.o
>  obj-$(CONFIG_PCIE_IPROC_BCMA) += pcie-iproc-bcma.o
> +obj-$(CONFIG_PCIE_ALTERA) += pcie-altera.o
> diff --git a/drivers/pci/host/pcie-altera.c b/drivers/pci/host/pcie-altera.c
> new file mode 100644
> index 000..c168ec7
> --- /dev/null
> +++ b/drivers/pci/host/pcie-altera.c
> @@ -0,0 +1,588 @@
> +/*
> + * Copyright Altera Corporation (C) 2013-2015. All rights reserved
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If not, see .
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define A2P_ADDR_MAP_LO0 0x1000
> +#define A2P_ADDR_MAP_HI0 0x1004
> +#define RP_TX_REG0   0x2000
> +#define RP_TX_REG1   0x2004
> +#define RP_TX_CNTRL  0x2008
> +#define RP_TX_EOP0x2
> +#define RP_TX_SOP0x1
> +#define RP_RXCPL_STATUS  0x2010
> +#define RP_RXCPL_EOP 0x2
> +#define RP_RXCPL_SOP 0x1
> +#define RP_RXCPL_REG00x2014
> +#define RP_RXCPL_REG10x2018
> +#define P2A_INT_STATUS   0x3060
> +#define P2A_INT_STS_ALL  0xF
> +#define P2A_INT_ENABLE   0x3070
> +#define P2A_INT_ENA_ALL  0xF
> +#define RP_LTSSM 0x3C64
> +#define LTSSM_L0 0xF
> +
> +/* TLP configuration type 0 and 1 */
> +#define TLP_FMTTYPE_CFGRD0   0x04/* Configuration Read Type 0 */
> +#define TLP_FMTTYPE_CFGWR0   0x44/* Configuration Write Type 0 */
> +#define TLP_FMTTYPE_CFGRD1   0x05/* Configuration Read Type 1 */
> +#define TLP_FMTTYPE_CFGWR1   0x45/* Configuration Write Type 1 */
> +#define TLP_PAYLOAD_SIZE 0x01
> +#define TLP_READ_TAG 0x1D
> +#define TLP_WRITE_TAG0x10
> +#define TLP_CFG_DW0(fmttype) (((fmttype) << 24) | TLP_PAYLOAD_SIZE)
> +#define TLP_CFG_DW1(reqid, tag)  (((reqid) << 16) | (tag << 8) | 
> 0xF)
> +#define TLP_CFG_DW2(bus, devfn, offset)  \
> + (((bus) << 24) | ((devfn) << 16) | (offset))
> +#define TLP_REQ_ID(bus, devfn)   (((bus) << 8) | (devfn))
> +#define TLP_COMPL_STATUS(hdr)(((hdr) & 0xE0) >> 13)
> +#define TLP_HDR_SIZE 3
> +#define TLP_LOOP 10
> +
> +#define INTX_NUM 4
> +
> +/* Address translation table entry size */
> +#define ATT_ENTRY_SIZE   8
> +
> +#define DWORD_MASK   3
> +
> +struct altera_pcie {
> + struct platform_device  *pdev;
> + void __iomem*cra_base;
> + int irq;
> + u8  root_bus_nr;
> + struct irq_domain   *irq_domain;
> + struct resource bus_range;
> + struct list_headresources;
> +};
> +
> +struct tlp_rp_regpair_t {
> + u32 ctrl;
> + u32 reg0;
> + u32 reg1;
> +};
> +
> +static void altera

Re: [PATCH v5 3/5] pci: altera: Add Altera PCIe MSI driver

[Marc Zyngier]

 +}
> +
> +static const struct irq_domain_ops msi_domain_ops = {
> + .alloc  = altera_irq_domain_alloc,
> + .free   = altera_irq_domain_free,
> +};
> +
> +static int altera_allocate_domains(struct altera_msi *msi)
> +{
> + msi->inner_domain = irq_domain_add_linear(NULL, msi->num_of_vectors,
> +  &msi_domain_ops, msi);
> + if (!msi->inner_domain) {
> + dev_err(&msi->pdev->dev, "failed to create IRQ domain\n");
> + return -ENOMEM;
> + }
> +
> + msi->msi_domain = pci_msi_create_irq_domain(msi->pdev->dev.of_node,
> + &altera_msi_domain_info, msi->inner_domain);
> + if (!msi->msi_domain) {
> + dev_err(&msi->pdev->dev, "failed to create MSI domain\n");
> + irq_domain_remove(msi->inner_domain);
> + return -ENOMEM;
> + }
> +
> + return 0;
> +}
> +
> +static void altera_free_domains(struct altera_msi *msi)
> +{
> + irq_domain_remove(msi->msi_domain);
> + irq_domain_remove(msi->inner_domain);
> +}
> +
> +static int altera_msi_remove(struct platform_device *pdev)
> +{
> + struct altera_msi *msi = platform_get_drvdata(pdev);
> +
> + msi_writel(msi, 0, MSI_INTMASK);
> + irq_set_chained_handler(msi->irq, NULL);
> + irq_set_handler_data(msi->irq, NULL);
> +
> + altera_free_domains(msi);
> +
> + platform_set_drvdata(pdev, NULL);
> + return 0;
> +}
> +
> +static int altera_msi_probe(struct platform_device *pdev)
> +{
> + struct altera_msi *msi;
> + struct device_node *np = pdev->dev.of_node;
> + struct resource *res;
> + int ret;
> +
> + msi = devm_kzalloc(&pdev->dev, sizeof(struct altera_msi),
> +GFP_KERNEL);
> + if (!msi)
> + return -ENOMEM;
> +
> + mutex_init(&msi->lock);
> + msi->pdev = pdev;
> +
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "csr");
> + if (!res) {
> + dev_err(&pdev->dev,
> + "no csr memory resource defined\n");
> + return -ENODEV;
> + }
> +
> + msi->csr_base = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(msi->csr_base)) {
> + dev_err(&pdev->dev, "failed to map csr memory\n");
> + return PTR_ERR(msi->csr_base);
> + }
> +
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> +"vector_slave");
> + if (!res) {
> + dev_err(&pdev->dev,
> + "no vector_slave memory resource defined\n");
> + return -ENODEV;
> + }
> +
> + msi->vector_base = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(msi->vector_base)) {
> + dev_err(&pdev->dev, "failed to map vector_slave memory\n");
> + return PTR_ERR(msi->vector_base);
> + }
> +
> + msi->vector_phy = res->start;
> +
> + if (of_property_read_u32(np, "num-vectors", &msi->num_of_vectors)) {
> + dev_err(&pdev->dev, "failed to parse the number of vectors\n");
> + return -EINVAL;
> + }
> +
> + ret = altera_allocate_domains(msi);
> + if (ret)
> + return ret;
> +
> + msi->irq = platform_get_irq(pdev, 0);
> + if (msi->irq <= 0) {
> + dev_err(&pdev->dev, "failed to map IRQ: %d\n", msi->irq);
> + ret = -ENODEV;
> + goto err;
> + }
> +
> + irq_set_chained_handler_and_data(msi->irq, altera_msi_isr, msi);
> + platform_set_drvdata(pdev, msi);
> +
> + return 0;
> +
> +err:
> + altera_msi_remove(pdev);
> + return ret;
> +}
> +
> +static const struct of_device_id altera_msi_of_match[] = {
> + { .compatible = "altr,msi-1.0", NULL },
> + { },
> +};
> +
> +static struct platform_driver altera_msi_driver = {
> + .driver = {
> + .name = "altera-msi",
> + .of_match_table = altera_msi_of_match,
> + },
> + .probe = altera_msi_probe,
> + .remove = altera_msi_remove,
> +};
> +
> +static int __init altera_msi_init(void)
> +{
> + return platform_driver_register(&altera_msi_driver);
> +}
> +
> +subsys_initcall(altera_msi_init);
> +
> +MODULE_AUTHOR("Ley Foon Tan ");
> +MODULE_DESCRIPTION("Altera PCIe MSI support");
> +MODULE_LICENSE("GPL v2");
> 

Once you've fixed the above issues, you can add my:

Reviewed-by: Marc Zyngier 

M.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 3/4] powerpc: PCI: Fix lookup of linux,pci-probe-only property

[Marc Zyngier]

When find_and_init_phbs() looks for the probe-only property, it seems
to trust the firmware to be correctly written, and assumes that there
is a parameter to the property.

It is conceivable that the firmware could not be that perfect, and it
could expose this property naked (at least one arm64 platform seems to
exhibit this exact behaviour). The setup code the ends up making
a decision based on whatever the property pointer points to, which
is likely to be junk.

Instead, switch to the common of_pci.c implementation that doesn't
suffer from this problem and ignore the property if the firmware
couldn't make up its mind.

Signed-off-by: Marc Zyngier 
---
 arch/powerpc/platforms/pseries/setup.c | 14 ++
 1 file changed, 2 insertions(+), 12 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/setup.c 
b/arch/powerpc/platforms/pseries/setup.c
index df6a704..8434953 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -40,6 +40,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -488,18 +489,7 @@ static void __init find_and_init_phbs(void)
 * PCI_PROBE_ONLY and PCI_REASSIGN_ALL_BUS can be set via properties
 * in chosen.
 */
-   if (of_chosen) {
-   const int *prop;
-
-   prop = of_get_property(of_chosen,
-   "linux,pci-probe-only", NULL);
-   if (prop) {
-   if (*prop)
-   pci_add_flags(PCI_PROBE_ONLY);
-   else
-   pci_clear_flags(PCI_PROBE_ONLY);
-   }
-   }
+   of_pci_check_probe_only(of_chosen);
 }
 
 static void __init pSeries_setup_arch(void)
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 2/4] PCI: pci-host-generic: Fix lookup of linux,pci-probe-only property

[Marc Zyngier]

When pci-host-generic looks for the probe-only property, it seems
to trust the DT to be correctly written, and assumes that there
is a parameter to the property.

Unfortunately, this is not always the case, and some firmware expose
this property naked. The driver ends up making a decision based on
whatever the property pointer points to, which is likely to be junk.

Switch to the common of_pci.c implementation that doesn't suffer
from this problem.

Signed-off-by: Marc Zyngier 
---
 drivers/pci/host/pci-host-generic.c | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/drivers/pci/host/pci-host-generic.c 
b/drivers/pci/host/pci-host-generic.c
index 265dd25..545ff4e 100644
--- a/drivers/pci/host/pci-host-generic.c
+++ b/drivers/pci/host/pci-host-generic.c
@@ -210,7 +210,6 @@ static int gen_pci_probe(struct platform_device *pdev)
int err;
const char *type;
const struct of_device_id *of_id;
-   const int *prop;
struct device *dev = &pdev->dev;
struct device_node *np = dev->of_node;
struct gen_pci *pci = devm_kzalloc(dev, sizeof(*pci), GFP_KERNEL);
@@ -225,13 +224,7 @@ static int gen_pci_probe(struct platform_device *pdev)
return -EINVAL;
}
 
-   prop = of_get_property(of_chosen, "linux,pci-probe-only", NULL);
-   if (prop) {
-   if (*prop)
-   pci_add_flags(PCI_PROBE_ONLY);
-   else
-   pci_clear_flags(PCI_PROBE_ONLY);
-   }
+   of_pci_check_probe_only(of_chosen);
 
of_id = of_match_node(gen_pci_of_match, np);
pci->cfg.ops = of_id->data;
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 4/4] arm64: dts: Drop linux,pci-probe-only from the Seattle DTS

[Marc Zyngier]

The linux,pci-probe-only property mandates an argument to indicate
whether or not to engage the "probe-only" mode, but the Seattle
DTS just provides a naked property, which is illegal.

Also, it turns out that the board is perfectly happy without
probe-only, so let's drop this altogether.

Signed-off-by: Marc Zyngier 
---
 arch/arm64/boot/dts/amd/amd-overdrive.dts | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm64/boot/dts/amd/amd-overdrive.dts 
b/arch/arm64/boot/dts/amd/amd-overdrive.dts
index 564a3f7..128fa94 100644
--- a/arch/arm64/boot/dts/amd/amd-overdrive.dts
+++ b/arch/arm64/boot/dts/amd/amd-overdrive.dts
@@ -14,7 +14,6 @@
 
chosen {
stdout-path = &serial0;
-   linux,pci-probe-only;
};
 };
 
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/4] of/pci: Add of_pci_check_probe_only to parse "linux,pci-probe-only"

[Marc Zyngier]

Both pci-host-generic and Pseries parse the "linux,pci-probe-only"
to engage the PCI_PROBE_ONLY mode, and both have a subtle bug that
can be triggered if the property has no parameter.

Provide a generic implementation that can be used by both.

Signed-off-by: Marc Zyngier 
---
 drivers/of/of_pci.c| 30 ++
 include/linux/of_pci.h |  3 +++
 2 files changed, 33 insertions(+)

diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 5751dc5..a4e29ff 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -118,6 +118,36 @@ int of_get_pci_domain_nr(struct device_node *node)
 EXPORT_SYMBOL_GPL(of_get_pci_domain_nr);
 
 /**
+ * of_pci_check_probe_only - Setup probe only mode if linux,pci-probe-only
+ *   is present and valid
+ *
+ * @node: device tree node that may contain the property (usually "chosen")
+ *
+ */
+void of_pci_check_probe_only(struct device_node *node)
+{
+   const int *prop;
+   int len;
+
+   if (!node)
+   return;
+
+   prop = of_get_property(node, "linux,pci-probe-only", &len);
+   if (prop) {
+   if (!len) {
+   pr_warn("linux,pci-probe-only set without value, 
ignoring\n");
+   return;
+   }
+
+   if (be32_to_cpup(prop))
+   pci_add_flags(PCI_PROBE_ONLY);
+   else
+   pci_clear_flags(PCI_PROBE_ONLY);
+   }
+}
+EXPORT_SYMBOL_GPL(of_pci_check_probe_only);
+
+/**
  * of_pci_dma_configure - Setup DMA configuration
  * @dev: ptr to pci_dev struct of the PCI device
  *
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index 29fd3fe..4c0a617 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -17,6 +17,7 @@ int of_irq_parse_and_map_pci(const struct pci_dev *dev, u8 
slot, u8 pin);
 int of_pci_parse_bus_range(struct device_node *node, struct resource *res);
 int of_get_pci_domain_nr(struct device_node *node);
 void of_pci_dma_configure(struct pci_dev *pci_dev);
+void of_pci_check_probe_only(struct device_node *node);
 #else
 static inline int of_irq_parse_pci(const struct pci_dev *pdev, struct 
of_phandle_args *out_irq)
 {
@@ -53,6 +54,8 @@ of_get_pci_domain_nr(struct device_node *node)
 }
 
 static inline void of_pci_dma_configure(struct pci_dev *pci_dev) { }
+
+static inline void of_pci_check_probe_only(struct device_node *node) { }
 #endif
 
 #if defined(CONFIG_OF_ADDRESS)
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 0/4] PCI: arm64/powerpc: Fix parsing of linux,pci-probe-only

[Marc Zyngier]

The pci-host-generic driver parses the linux,pci-probe-only property,
and assumes that it will have a boolean parameter.

Turns out that the Seattle DTS file has a naked "linux,pci-probe-only"
property, which leads to the driver dereferencing some unsuspecting
memory location. Nothing really bad happens (we end up reading some
other bit of DT, fortunately), but that not a reason to keep it this
way. Turns out that the Pseries code (where this code was lifted from)
may suffer from the same issue.

The first patch introduces a common (and fixed) version of that check
that can be used by drivers and architectures that require it. The two
following patches change the pci-host-generic driver and the powerpc
code to use it.

Finally, the bad property is removed from the Seatle DTS, because it
is simply not necessary (it actually prevents me from using SR-IOV,
which otherwise runs fine without the probe-only thing).

This has been tested on the offending Seattle board.

* From v1:
  - Consolidate the parsing in of_pci.c (Bjorn)

Marc Zyngier (4):
  of/pci: Add of_pci_check_probe_only to parse "linux,pci-probe-only"
  PCI: pci-host-generic: Fix lookup of linux,pci-probe-only property
  powerpc: PCI: Fix lookup of linux,pci-probe-only property
  arm64: dts: Drop linux,pci-probe-only from the Seattle DTS

 arch/arm64/boot/dts/amd/amd-overdrive.dts |  1 -
 arch/powerpc/platforms/pseries/setup.c| 14 ++
 drivers/of/of_pci.c   | 30 ++
 drivers/pci/host/pci-host-generic.c   |  9 +
 include/linux/of_pci.h|  3 +++
 5 files changed, 36 insertions(+), 21 deletions(-)

-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 3/5] pci: altera: Add Altera PCIe MSI driver

[Marc Zyngier]

On 07/08/15 08:43, Ley Foon Tan wrote:
> This patch adds Altera PCIe MSI driver. This soft IP supports configurable
> number of vectors, which is a dts parameter.
> 
> Signed-off-by: Ley Foon Tan 
> ---
>  drivers/pci/host/Kconfig   |   8 +
>  drivers/pci/host/Makefile  |   1 +
>  drivers/pci/host/pcie-altera-msi.c | 309 
> +
>  3 files changed, 318 insertions(+)
>  create mode 100644 drivers/pci/host/pcie-altera-msi.c
> 
> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> index 4b4754a..d28cc6d 100644
> --- a/drivers/pci/host/Kconfig
> +++ b/drivers/pci/host/Kconfig
> @@ -152,4 +152,12 @@ config PCIE_ALTERA
>   Say Y here if you want to enable PCIe controller support for Altera
>   SoCFPGA family of SoCs.
> 
> +config PCIE_ALTERA_MSI
> +   bool "Altera PCIe MSI feature"
> +   depends on PCI_MSI
> +   select PCI_MSI_IRQ_DOMAIN
> +   help
> + Say Y here if you want PCIe MSI support for the Altera SocFPGA SoC.
> + This MSI driver supports Altera MSI to GIC controller IP.
> +
>  endmenu
> diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
> index 6954f76..6c4913d 100644
> --- a/drivers/pci/host/Makefile
> +++ b/drivers/pci/host/Makefile
> @@ -18,3 +18,4 @@ obj-$(CONFIG_PCIE_IPROC) += pcie-iproc.o
>  obj-$(CONFIG_PCIE_IPROC_PLATFORM) += pcie-iproc-platform.o
>  obj-$(CONFIG_PCIE_IPROC_BCMA) += pcie-iproc-bcma.o
>  obj-$(CONFIG_PCIE_ALTERA) += pcie-altera.o
> +obj-$(CONFIG_PCIE_ALTERA_MSI) += pcie-altera-msi.o
> diff --git a/drivers/pci/host/pcie-altera-msi.c 
> b/drivers/pci/host/pcie-altera-msi.c
> new file mode 100644
> index 000..2d84e62
> --- /dev/null
> +++ b/drivers/pci/host/pcie-altera-msi.c
> @@ -0,0 +1,309 @@
> +/*
> + * Copyright Altera Corporation (C) 2013-2015. All rights reserved
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If not, see .
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define MSI_STATUS 0x0
> +#define MSI_ERROR  0x4
> +#define MSI_INTMASK0x8
> +
> +#define MAX_MSI_VECTORS32
> +struct altera_msi {
> +   DECLARE_BITMAP(used, MAX_MSI_VECTORS);
> +   struct mutexlock;   /* proctect used variable */
> +   struct platform_device  *pdev;
> +   struct irq_domain   *msi_domain;
> +   struct irq_domain   *inner_domain;
> +   void __iomem*csr_base;
> +   void __iomem*vector_base;
> +   phys_addr_t vector_phy;
> +   u32 num_of_vectors;
> +   int irq;
> +};
> +
> +static inline void msi_writel(struct altera_msi *msi, u32 value, u32 reg)
> +{
> +   writel_relaxed(value, msi->csr_base + reg);
> +}
> +
> +static inline u32 msi_readl(struct altera_msi *msi, u32 reg)
> +{
> +   return readl_relaxed(msi->csr_base + reg);
> +}
> +
> +static void altera_msi_isr(unsigned int irq, struct irq_desc *desc)
> +{
> +   struct irq_chip *chip = irq_desc_get_chip(desc);
> +   struct altera_msi *msi;
> +   unsigned long status;
> +   u32 num_of_vectors;
> +   u32 bit;
> +   u32 virq;
> +
> +   chained_irq_enter(chip, desc);
> +   msi = irq_desc_get_handler_data(desc);
> +   num_of_vectors = msi->num_of_vectors;
> +
> +   do {
> +   status = msi_readl(msi, MSI_STATUS);
> +   if (!status)
> +   break;
> +
> +   do {
> +   bit = find_first_bit(&status, num_of_vectors);
> +   /* Dummy read from vector to clear the interrupt */
> +   readl_relaxed(msi->vector_base + (bit * sizeof(u32)));
> +
> +   virq = irq_find_mapping(msi->inner_domain, bit);
> +   if (virq && test_bit(bit, msi->used))
> +   generic_handle_irq(virq);
> +   else
> +   dev_err(&msi->pdev->dev, "unexpected MSI\n");
> +
> +   /* Clear the bit from status and repeat without 
> reading
> +* again status register. */
> +   __clear_bit(bit, &status);
> +   } while (status);
> +   } while (1);
> +
> +   ch

Re: [PATCH v3 2/5] pci:host: Add Altera PCIe host controller driver

[Marc Zyngier]

On 07/08/15 08:42, Ley Foon Tan wrote:
> This patch adds the Altera PCIe host controller driver.
> 
> Signed-off-by: Ley Foon Tan 
> ---
>  drivers/pci/host/Kconfig   |   7 +
>  drivers/pci/host/Makefile  |   1 +
>  drivers/pci/host/pcie-altera.c | 532 
> +
>  3 files changed, 540 insertions(+)
>  create mode 100644 drivers/pci/host/pcie-altera.c
> 
> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> index 675c2d1..4b4754a 100644
> --- a/drivers/pci/host/Kconfig
> +++ b/drivers/pci/host/Kconfig
> @@ -145,4 +145,11 @@ config PCIE_IPROC_BCMA
>   Say Y here if you want to use the Broadcom iProc PCIe controller
>   through the BCMA bus interface
> 
> +config PCIE_ALTERA
> +   tristate "Altera PCIe controller"
> +   depends on ARCH_SOCFPGA
> +   help
> + Say Y here if you want to enable PCIe controller support for Altera
> + SoCFPGA family of SoCs.
> +
>  endmenu
> diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
> index 140d66f..6954f76 100644
> --- a/drivers/pci/host/Makefile
> +++ b/drivers/pci/host/Makefile
> @@ -17,3 +17,4 @@ obj-$(CONFIG_PCI_VERSATILE) += pci-versatile.o
>  obj-$(CONFIG_PCIE_IPROC) += pcie-iproc.o
>  obj-$(CONFIG_PCIE_IPROC_PLATFORM) += pcie-iproc-platform.o
>  obj-$(CONFIG_PCIE_IPROC_BCMA) += pcie-iproc-bcma.o
> +obj-$(CONFIG_PCIE_ALTERA) += pcie-altera.o
> diff --git a/drivers/pci/host/pcie-altera.c b/drivers/pci/host/pcie-altera.c
> new file mode 100644
> index 000..37bed81
> --- /dev/null
> +++ b/drivers/pci/host/pcie-altera.c
> @@ -0,0 +1,532 @@
> +/*
> + * Copyright Altera Corporation (C) 2013-2015. All rights reserved
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If not, see .
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define A2P_ADDR_MAP_LO0   0x1000
> +#define A2P_ADDR_MAP_HI0   0x1004
> +#define RP_TX_REG0 0x2000
> +#define RP_TX_REG1 0x2004
> +#define RP_TX_CNTRL0x2008
> +#define RP_TX_EOP  0x2
> +#define RP_TX_SOP  0x1
> +#define RP_RXCPL_STATUS0x2010
> +#define RP_RXCPL_EOP   0x2
> +#define RP_RXCPL_SOP   0x1
> +#define RP_RXCPL_REG0  0x2014
> +#define RP_RXCPL_REG1  0x2018
> +#define P2A_INT_STATUS 0x3060
> +#define P2A_INT_STS_ALL0xF
> +#define P2A_INT_ENABLE 0x3070
> +#define P2A_INT_ENA_ALL0xF
> +#define RP_LTSSM   0x3C64
> +#define LTSSM_L0   0xF
> +
> +/* TLP configuration type 0 and 1 */
> +#define TLP_FMTTYPE_CFGRD0 0x04/* Configuration Read Type 0 
> */
> +#define TLP_FMTTYPE_CFGWR0 0x44/* Configuration Write Type 0 
> */
> +#define TLP_FMTTYPE_CFGRD1 0x05/* Configuration Read Type 1 
> */
> +#define TLP_FMTTYPE_CFGWR1 0x45/* Configuration Write Type 1 
> */
> +#define TLP_PAYLOAD_SIZE   0x01
> +#define TLP_READ_TAG   0x1D
> +#define TLP_WRITE_TAG  0x10
> +#define TLP_CFG_DW0(fmttype)   (((fmttype) << 24) | TLP_PAYLOAD_SIZE)
> +#define TLP_CFG_DW1(reqid, tag)(((reqid) << 16) | (tag << 8) 
> | 0xF)
> +#define TLP_CFG_DW2(bus, devfn, offset)\
> +   (((bus) << 24) | ((devfn) << 16) | (offset))
> +#define TLP_REQ_ID(bus, devfn) (((bus) << 8) | (devfn))
> +#define TLP_COMPL_STATUS(hdr)  (((hdr) & 0xE0) >> 13)
> +#define TLP_HDR_SIZE   3
> +#define TLP_LOOP   10
> +
> +#define INTX_NUM   4
> +
> +/* Address translation table entry size */
> +#define ATT_ENTRY_SIZE 8
> +
> +#define DWORD_MASK 3
> +
> +struct altera_pcie {
> +   struct platform_device  *pdev;
> +   struct resource *txs;
> +   void __iomem*cra_base;
> +   int irq;
> +   u8  root_bus_nr;
> +   struct irq_domain   *irq_domain;
> +   struct resource bus_range;
> +   struct list_headresources;
> +};
> +
> +struct tlp_rp_regpair_t {
> +   u

Re: [PATCH 1/3] Docs: dt: add generic MSI bindings

[Marc Zyngier]

On 05/08/15 17:51, Mark Rutland wrote:
> Rob,
> 
> Do you have any objections to this, or are you happy to take this patch?
> 
> There's a user of this binding (the GICv3 ITS) queued for v4.3 already in
> the tip tree, so either we either need to be ok with this binding or we
> need to rework that before v4.3.
> 
> Marc, can I take it from your use of the binding that you are happy to
> provide your ack?

Definitely.

Acked-by: Marc Zyngier 

M.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 3/5] pci: altera: Add Altera PCIe MSI driver

[Marc Zyngier]

On 03/08/15 11:37, Ley Foon Tan wrote:
> On Fri, Jul 31, 2015 at 8:12 PM, Marc Zyngier  wrote:
>> On 31/07/15 11:15, Ley Foon Tan wrote:
>>> This patch adds Altera PCIe MSI driver. This soft IP supports configurable
>>> number of vectors, which is a dts parameter.
>>
>> I've reviewed the initial drop of this code; basic courtesy would be to
>> keep me CCed on the follow-up series.
> Will keep you in CC for the following revision. Sorry about this.
> 
>>>
>>> Signed-off-by: Ley Foon Tan 
>>> ---
>>>  drivers/pci/host/Kconfig   |   7 +
>>>  drivers/pci/host/Makefile  |   1 +
>>>  drivers/pci/host/pcie-altera-msi.c | 324 
>>> +
>>>  3 files changed, 332 insertions(+)
>>>  create mode 100644 drivers/pci/host/pcie-altera-msi.c
>>>

[...]

>>> +
>>> + msg->address_lo = lower_32_bits(addr);
>>> + msg->address_hi = upper_32_bits(addr);
>>> + msg->data = data->hwirq;
>>> +
>>> + mask = msi_readl(msi, MSI_INTMASK);
>>> + mask |= 1 << data->hwirq;
>>> + msi_writel(msi, mask, MSI_INTMASK);
>>
>> It feels a bit weird to unmask the interrupt when you compose the
>> message. I'd expect this to be done in the mask/unmask methods.
> Do you refer to these 2 callbacks?
> .irq_mask = pci_msi_mask_irq,
> .irq_unmask = pci_msi_unmask_irq,
> 
> How about we move this INTMASK code above to altera_irq_domain_alloc()?
> We have unmask code in altera_irq_domain_free() now.

Either you move the mask/unmask code to local irq_mask/irq_unmask
methods (and call pci_msi_(un)mask_irq from there), or you move it
entierely to alloc/free.

Some level of symmetry helps following what is going on in the code.

[...]

>>> +static int altera_irq_domain_alloc(struct irq_domain *domain, unsigned int 
>>> virq,
>>> +   unsigned int nr_irqs, void *args)
>>> +{
>>> + struct altera_msi *msi = domain->host_data;
>>> + int bit;
>>> +
>>> + mutex_lock(&msi->lock);
>>> +
>>> + bit = find_first_zero_bit(msi->used, msi->num_of_vectors);
>>> + if (bit < msi->num_of_vectors)
>>> + set_bit(bit, msi->used);
>>> +
>>> + mutex_unlock(&msi->lock);
>>> +
>>> + if (bit < 0)
>>> + return bit;
>>
>> How can "bit" be negative here? find_first_zero_bit returns an unsigned
>> long... You probably want to change the type of "bit" to reflect that.
> Okay, will change to "unsigned long" type.
>>
>>> + else if (bit >= msi->num_of_vectors)
>>
>> Useless "else" anyway.
> 
> I think we still need to check for failing case, if we don't have
> available unused bit.
> This could be rewritten  as below:
> 
> bit = find_first_zero_bit(msi->used, msi->num_of_vectors);
> if (bit < msi->num_of_vectors)
>   set_bit(bit, msi->used);
> else
>   return -ENOSPC;

The more logical to write this is:

if (bit >= msi->num_of_vectors)
return -ENOSPC;

set_bit(bit, msi->used);

which gets rid of the error case early and streamlines the normal case.

> 
>>
>>> + return -ENOSPC;
>>> +
>>> + irq_domain_set_info(domain, virq, bit, &altera_msi_bottom_irq_chip,
>>> + domain->host_data, handle_simple_irq,
>>> + NULL, NULL);
>>> + set_irq_flags(virq, IRQF_VALID);
>>> +
>>> + return 0;
>>> +}

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] Docs: dt: add generic MSI bindings

[Marc Zyngier]

On 27/07/15 10:46, Mark Rutland wrote:
> On Mon, Jul 27, 2015 at 09:02:46AM +0100, Marc Zyngier wrote:
>> Hi Mark,
> 
> Hi,
> 
>> On 23/07/15 17:52, Mark Rutland wrote:
>>> Currently msi-parent is used in a couple of drivers despite being fairly
>>> underspecified. This patch adds a generic binding for MSIs (including
>>> the existing msi-parent property) enabling the description of platform
>>> devices capable of using MSIs.
>>>
>>> While MSIs are primarily distinguished by doorbell and payload, some MSI
>>> controllers (e.g. the GICv3 ITS) also use side-band information
>>> accompanying the write to identify the master which originated the MSI,
>>> to allow for sandboxing. This sideband information is non-probeable and
>>> needs to be described in the DT. Other MSI controllers may have
>>> additional configuration details which need to be described per-master.
>>>
>>> This patch adds a generic msi-parent binding document, extending the
>>> de-facto standard with a new (optional) #msi-cells which can be used to
>>> express any per-master configuration and/or sideband data. This is
>>> sufficient to describe non-hotpluggable devices.
>>>
>>> For busses where sideband data may be derived from some bus-specific
>>> master ID scheme, other properties will be required to describe the
>>> mapping.
>>>
>>> Signed-off-by: Mark Rutland 
>>> ---
>>>  .../bindings/interrupt-controller/msi.txt  | 135 
>>> +
>>>  1 file changed, 135 insertions(+)
>>>  create mode 100644 
>>> Documentation/devicetree/bindings/interrupt-controller/msi.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/interrupt-controller/msi.txt 
>>> b/Documentation/devicetree/bindings/interrupt-controller/msi.txt
>>> new file mode 100644
>>> index 000..c60c034
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/interrupt-controller/msi.txt
>>> @@ -0,0 +1,135 @@
>>> +This document describes the generic device tree binding for MSI 
>>> controllers and
>>> +their master(s).
>>> +
>>> +Message Signaled Interrupts (MSIs) are a class of interrupts generated by a
>>> +write to an MMIO address.
>>> +
>>> +MSIs were originally specified by PCI (and are used with PCIe), but may 
>>> also be
>>> +used with other busses, and hence a mechanism is required to relate 
>>> devices on
>>> +those busses to the MSI controllers which they are capable of using,
>>> +potentially including additional information.
>>> +
>>> +MSIs are distinguished by some combination of:
>>> +
>>> +- The doorbell (the MMIO address written to).
>>> +  
>>> +  Devices may be configured by software to write to arbitrary doorbells 
>>> which
>>> +  they can address. An MSI controller may feature a number of doorbells.
>>> +
>>> +- The payload (the value written to the doorbell).
>>> +  
>>> +  Devices may be configured to write an arbitrary payload chosen by 
>>> software.
>>> +  MSI controllers may have restrictions on permitted payloads.
>>> +
>>> +- Sideband information accompanying the write.
>>> +  
>>> +  Typically this is neither configurable nor probeable, and depends on the 
>>> path
>>> +  taken through the memory system (i.e. it is a property of the 
>>> combination of
>>> +  MSI controller and device rather than a property of either in isolation).
>>> +
>>> +
>>> +MSI controllers:
>>> +
>>> +
>>> +An MSI controller signals interrupts to a CPU when a write is made to an 
>>> MMIO
>>> +address by some master. An MSI controller may feature a number of 
>>> doorbells.
>>> +
>>> +Required properties:
>>> +
>>> +
>>> +- msi-controller: Identifies the node as an MSI controller.
>>> +
>>> +Optional properties:
>>> +
>>> +
>>> +- #msi-cells: The number of cells in an msi-specifier, required if not 
>>> zero.
>>> +
>>> +  Typically this will encode information related to sideband data, and will
>>> +  not encode doorbells or payloads as these can be configured dynamically.
>>> +
>>> +  The meaning of the msi-specifier is defined by the device tree binding of
>>> +  the specific MSI controller. 
>>>

Re: [PATCH v2 2/5] pci:host: Add Altera PCIe host controller driver

[Marc Zyngier]

On 31/07/15 11:15, Ley Foon Tan wrote:
> This patch adds the Altera PCIe host controller driver.
> 
> Signed-off-by: Ley Foon Tan 
> ---
>  drivers/pci/host/Kconfig   |   8 +
>  drivers/pci/host/Makefile  |   1 +
>  drivers/pci/host/pcie-altera.c | 526 
> +
>  3 files changed, 535 insertions(+)
>  create mode 100644 drivers/pci/host/pcie-altera.c
> 
> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> index 675c2d1..108500a 100644
> --- a/drivers/pci/host/Kconfig
> +++ b/drivers/pci/host/Kconfig
> @@ -145,4 +145,12 @@ config PCIE_IPROC_BCMA
> Say Y here if you want to use the Broadcom iProc PCIe controller
> through the BCMA bus interface
>  
> +config PCIE_ALTERA
> + tristate "Altera PCIe controller"
> + depends on ARCH_SOCFPGA
> + select PCI_MSI_IRQ_DOMAIN if PCI_MSI

Why would you select this here? MSI support is in another driver, so I
don't see the point.

> + help
> +   Say Y here if you want to enable PCIe controller support for Altera
> +   SoCFPGA family of SoCs.
> +
>  endmenu
> diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
> index 140d66f..6954f76 100644
> --- a/drivers/pci/host/Makefile
> +++ b/drivers/pci/host/Makefile
> @@ -17,3 +17,4 @@ obj-$(CONFIG_PCI_VERSATILE) += pci-versatile.o
>  obj-$(CONFIG_PCIE_IPROC) += pcie-iproc.o
>  obj-$(CONFIG_PCIE_IPROC_PLATFORM) += pcie-iproc-platform.o
>  obj-$(CONFIG_PCIE_IPROC_BCMA) += pcie-iproc-bcma.o
> +obj-$(CONFIG_PCIE_ALTERA) += pcie-altera.o
> diff --git a/drivers/pci/host/pcie-altera.c b/drivers/pci/host/pcie-altera.c
> new file mode 100644
> index 000..3ec51c7
> --- /dev/null
> +++ b/drivers/pci/host/pcie-altera.c
> @@ -0,0 +1,526 @@
> +/*
> + * Copyright Altera Corporation (C) 2013-2015. All rights reserved
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If not, see .
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define A2P_ADDR_MAP_LO0 0x1000
> +#define A2P_ADDR_MAP_HI0 0x1004
> +#define RP_TX_REG0   0x2000
> +#define RP_TX_REG1   0x2004
> +#define RP_TX_CNTRL  0x2008
> +#define RP_TX_EOP0x2
> +#define RP_TX_SOP0x1
> +#define RP_RXCPL_STATUS  0x2010
> +#define RP_RXCPL_EOP 0x2
> +#define RP_RXCPL_SOP 0x1
> +#define RP_RXCPL_REG00x2014
> +#define RP_RXCPL_REG10x2018
> +#define P2A_INT_STATUS   0x3060
> +#define P2A_INT_STS_ALL  0xF
> +#define P2A_INT_ENABLE   0x3070
> +#define P2A_INT_ENA_ALL  0xF
> +#define RP_LTSSM 0x3C64
> +#define LTSSM_L0 0xF
> +
> +/* TLP configuration type 0 and 1 */
> +#define TLP_FMTTYPE_CFGRD0   0x04/* Configuration Read Type 0 */
> +#define TLP_FMTTYPE_CFGWR0   0x44/* Configuration Write Type 0 */
> +#define TLP_FMTTYPE_CFGRD1   0x05/* Configuration Read Type 1 */
> +#define TLP_FMTTYPE_CFGWR1   0x45/* Configuration Write Type 1 */
> +#define TLP_PAYLOAD_SIZE 0x01
> +#define TLP_READ_TAG 0x1D
> +#define TLP_WRITE_TAG0x10
> +#define TLP_CFG_DW0(fmttype) (((fmttype) << 24) | TLP_PAYLOAD_SIZE)
> +#define TLP_CFG_DW1(reqid, tag)  (((reqid) << 16) | (tag << 8) | 
> 0xF)
> +#define TLP_CFG_DW2(bus, devfn, offset)  \
> + (((bus) << 24) | ((devfn) << 16) | (offset))
> +#define TLP_REQ_ID(bus, devfn)   (((bus) << 8) | (devfn))
> +#define TLP_COMPL_STATUS(hdr)(((hdr) & 0xE0) >> 13)
> +#define TLP_HDR_SIZE 3
> +#define TLP_LOOP 10
> +
> +#define INTX_NUM 4
> +
> +/* Address translation table entry size */
> +#define ATT_ENTRY_SIZE   8
> +
> +#define DWORD_MASK   3
> +
> +struct altera_pcie {
> + struct platform_device  *pdev;
> + struct resource *txs;
> + void __iomem*cra_base;
> + int hwirq;
> + u8  root_bus_nr;
> + struct irq_domain   *irq_domain;
> + struct resource bus_range;
> + struct list_he

Re: [PATCH v2 3/5] pci: altera: Add Altera PCIe MSI driver

[Marc Zyngier]

On 31/07/15 11:15, Ley Foon Tan wrote:
> This patch adds Altera PCIe MSI driver. This soft IP supports configurable
> number of vectors, which is a dts parameter.

I've reviewed the initial drop of this code; basic courtesy would be to
keep me CCed on the follow-up series.

> 
> Signed-off-by: Ley Foon Tan 
> ---
>  drivers/pci/host/Kconfig   |   7 +
>  drivers/pci/host/Makefile  |   1 +
>  drivers/pci/host/pcie-altera-msi.c | 324 
> +
>  3 files changed, 332 insertions(+)
>  create mode 100644 drivers/pci/host/pcie-altera-msi.c
> 
> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> index 108500a..51d0468 100644
> --- a/drivers/pci/host/Kconfig
> +++ b/drivers/pci/host/Kconfig
> @@ -153,4 +153,11 @@ config PCIE_ALTERA
> Say Y here if you want to enable PCIe controller support for Altera
> SoCFPGA family of SoCs.
>  
> +config PCIE_ALTERA_MSI
> + bool "Altera PCIe MSI feature"
> + depends on PCI_MSI
> + help
> +   Say Y here if you want PCIe MSI support for the Altera SocFPGA SoC.
> +   This MSI driver supports Altera MSI to GIC controller IP.
> +
>  endmenu
> diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
> index 6954f76..6c4913d 100644
> --- a/drivers/pci/host/Makefile
> +++ b/drivers/pci/host/Makefile
> @@ -18,3 +18,4 @@ obj-$(CONFIG_PCIE_IPROC) += pcie-iproc.o
>  obj-$(CONFIG_PCIE_IPROC_PLATFORM) += pcie-iproc-platform.o
>  obj-$(CONFIG_PCIE_IPROC_BCMA) += pcie-iproc-bcma.o
>  obj-$(CONFIG_PCIE_ALTERA) += pcie-altera.o
> +obj-$(CONFIG_PCIE_ALTERA_MSI) += pcie-altera-msi.o
> diff --git a/drivers/pci/host/pcie-altera-msi.c 
> b/drivers/pci/host/pcie-altera-msi.c
> new file mode 100644
> index 000..6014719
> --- /dev/null
> +++ b/drivers/pci/host/pcie-altera-msi.c
> @@ -0,0 +1,324 @@
> +/*
> + * Copyright Altera Corporation (C) 2013-2015. All rights reserved
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If not, see .
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define MSI_STATUS   0x0
> +#define MSI_ERROR0x4
> +#define MSI_INTMASK  0x8
> +
> +#define MAX_MSI_VECTORS  32
> +struct altera_msi {
> + DECLARE_BITMAP(used, MAX_MSI_VECTORS);
> + struct mutexlock;   /* proctect used variable */
> + struct platform_device  *pdev;
> + struct irq_domain   *msi_domain;
> + struct irq_domain   *inner_domain;
> + void __iomem*csr_base;
> + void __iomem*vector_base;
> + phys_addr_t vector_phy;
> + u32 num_of_vectors;
> + int irq;
> +};
> +
> +static inline void msi_writel(struct altera_msi *msi, u32 value, u32 reg)
> +{
> + writel_relaxed(value, msi->csr_base + reg);
> +}
> +
> +static inline u32 msi_readl(struct altera_msi *msi, u32 reg)
> +{
> + return readl_relaxed(msi->csr_base + reg);
> +}
> +
> +static void altera_msi_isr(unsigned int irq, struct irq_desc *desc)
> +{
> + struct irq_chip *chip = irq_desc_get_chip(desc);
> + struct altera_msi *msi;
> + unsigned long status;
> + u32 num_of_vectors;
> + u32 bit;
> +
> + chained_irq_enter(chip, desc);
> + msi = irq_desc_get_handler_data(desc);
> + num_of_vectors = msi->num_of_vectors;
> +
> + do {
> + status = msi_readl(msi, MSI_STATUS);
> + if (!status)
> + break;
> +
> + do {
> + bit = find_first_bit(&status, num_of_vectors);
> + /* Dummy read from vector to clear the interrupt */
> + readl_relaxed(msi->vector_base + (bit * sizeof(u32)));
> +
> + irq = irq_find_mapping(msi->inner_domain, bit);

Use of irq is a bit confusing, as this is a parameter describing the
chaining interrupt. Consider using a different name for this variable.

> + if (irq) {
> + if (test_bit(bit, msi->used))
> + generic_handle_irq(irq);
> + else
> + dev_info(&msi->pdev->dev, "unhandled 
> MSI\n");
> + } else
> + dev_info(&msi->pdev->dev, "unexpected