Re: [PATCHv3 5/6] irqchip/irq-pruss-intc: Add support for ICSSG INTC on K3 SoCs

[Suman Anna <s-anna@ti.com>]

Hi Marc,

On 7/3/20 12:05 PM, Grzegorz Jaszczyk wrote:
> On Thu, 2 Jul 2020 at 19:59, Marc Zyngier <maz@kernel.org> wrote:
>>
>> On 2020-07-02 15:17, Grzegorz Jaszczyk wrote:
>>> From: Suman Anna <s-anna@ti.com>
>>>
>>> The K3 AM65x and J721E SoCs have the next generation of the PRU-ICSS
>>> IP,
>>> commonly called ICSSG. The PRUSS INTC present within the ICSSG supports
>>> more System Events (160 vs 64), more Interrupt Channels and Host
>>> Interrupts
>>> (20 vs 10) compared to the previous generation PRUSS INTC instances.
>>> The
>>> first 2 and the last 10 of these host interrupt lines are used by the
>>> PRU and other auxiliary cores and sub-modules within the ICSSG, with 8
>>> host interrupts connected to MPU. The host interrupts 5, 6, 7 are also
>>> connected to the other ICSSG instances within the SoC and can be
>>> partitioned as per system integration through the board dts files.
>>>
>>> Enhance the PRUSS INTC driver to add support for this ICSSG INTC
>>> instance. This support is added using specific compatible and match
>>> data and updating the code to use this data instead of the current
>>> hard-coded macros. The INTC config structure is updated to use the
>>> higher events and channels on all SoCs, while limiting the actual
>>> processing to only the relevant number of events/channels/interrupts.
>>>
>>> Signed-off-by: Suman Anna <s-anna@ti.com>
>>> Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
>>> ---
>>> v2->v3:
>>> - Change patch order: use it directly after "irqchip/irq-pruss-intc:
>>>    Implement irq_{get,set}_irqchip_state ops" and before new
>>>    "irqchip/irq-pruss-intc: Add event mapping support" in order to
>>> reduce
>>>    diff.
>>
>> The diff would be even smaller if you introduced a variable number of
>> inputs the first place, i.e. in patch #2. Most if this patch just
>> retrofits it. Please squash these changes into that initial patch,
>> and only add the platform stuff here.

Yeah, all the variables were introduced in this patch based on patch 
history. Until this new IP came, we haven't had a need to use variables 
in the original driver code. That's also the reason for this being a 
separate patch rather than squashed into the original patch.

regards
Suman

>
> Sure I will do that.
> 
> Thank you,
> Grzegorz
>