[PATCH v4 0/5] PCI: rcar-gen4: irqchip/gic-v3: Handle GIC ITS

[Marek Vasut]

On 7/9/26 2:57 PM, Manivannan Sadhasivam wrote:
> On Thu, Jul 09, 2026 at 01:43:26PM +0100, Marc Zyngier wrote:
>> On Thu, 09 Jul 2026 13:33:22 +0100,
>> Marek Vasut <marek.vasut at mailbox.org> wrote:
>>>
>>> On 7/9/26 2:19 PM, Manivannan Sadhasivam wrote:
>>>> On Tue, Jul 07, 2026 at 10:35:38PM +0200, Marek Vasut wrote:
>>>>> Configure all R-Car Gen4 PCIe controller MSI registers fully, both in
>>>>> case MSI are enabled and disabled.
>>>>>
>>>>> Patch GIC ITS driver and add quirks for R-Car Gen4 GIC ITS, which is
>>>>> configured to 32-bit address width for AXI or APB interface.
>>>>>
>>>>> Switch R-Car V4H to use GIC ITS in its DT and describe the GIC ITS
>>>>> implementation cacheable and shareable limitations.
>>>>>
>>>>> Marek Vasut (5):
>>>>>     PCI: dwc: Determine whether iMSI is used before calling .init
>>>>>     PCI: rcar-gen4: Configure AXIINTC if iMSI-RX not used
>>>>>     irqchip/gic-v3: Refactor GIC600 limited to 32bit PA erratum handling
>>>>>     irqchip/gic-v3: Add Renesas R-Car Gen4 erratum workaround
>>>>
>>>> Is there a functional dependency between irqchip and PCI patches? Since the
>>>> irqchip patches touch ARM64 Kconfig etc... I'm wondering if it still need to go
>>>> through PCI tree.
>>> I do not believe there is.
>>>
>>> These two configure the PCIe controller hardware:
>>>    PCI: dwc: Determine whether iMSI is used before calling .init
>>>    PCI: rcar-gen4: Configure AXIINTC if iMSI-RX not used
>>>
>>> These two fill in GIC ITS quirks:
>>>    irqchip/gic-v3: Refactor GIC600 limited to 32bit PA erratum handling
>>>    irqchip/gic-v3: Add Renesas R-Car Gen4 erratum workaround
>>>
>>> This one does yes depend on the two and two patches above, and can
>>> only be applied once all four aforementioned patches land, otherwise
>>> things really yes will break:
>>>    arm64: dts: renesas: r8a779g0: Add GICv3 ITS and update PCIe nodes
>>>
>>> Would you like me to split the series up , or can you and Marc (?)
>>> pick the relevant parts via matching trees ?
>>
>> I don't think there's anything for me to pick. The whole thing looks
>> like a consistent set, and it probably should be kept together.
>>
>> Given that the irqchip stuff has been acked by the relevant party, and
>> that the last patch will cause havoc if taken on its own, the only
>> course of action is to route the whole thing together, the PCI tree
>> being the most obvious victim.
> 
> Alright then. I'll merge all 4 patches to PCI tree.
Thank you all.