Re: [PATCH v6 00/13] irqchip: ti,sci-intr/inta: Update the dt bindings to accept different interrupt parents

From: Sekhar Nori <nsekhar@ti.com>
To: Peter Ujfalusi <peter.ujfalusi@ti.com>,
	Lokesh Vutla <lokeshvutla@ti.com>, Marc Zyngier <maz@kernel.org>,
	Rob Herring <robh+dt@kernel.org>, Vinod <vkoul@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>, Nishanth Menon <nm@ti.com>,
	Tero Kristo <t-kristo@ti.com>,
	Santosh Shilimkar <ssantosh@kernel.org>,
	Linux ARM Mailing List <linux-arm-kernel@lists.infradead.org>,
	Grygorii Strashko <grygorii.strashko@ti.com>,
	Device Tree Mailing List <devicetree@vger.kernel.org>,
	Suman Anna <s-anna@ti.com>
Subject: Re: [PATCH v6 00/13] irqchip: ti,sci-intr/inta: Update the dt bindings to accept different interrupt parents
Date: Thu, 13 Aug 2020 15:33:05 +0530	[thread overview]
Message-ID: <26dffb1a-8e1b-db7f-dde6-98af607799f5@ti.com> (raw)
In-Reply-To: <31a0d207-cafa-8524-0364-b0bc55db6f6d@ti.com>

On 8/13/20 3:11 PM, Peter Ujfalusi wrote:
> Hi Lokesh,
> 
> On 06/08/2020 10.48, Lokesh Vutla wrote:
>> Hi Marc,
>> 	This is continuation of the RFC patches[0] regarding the driver
>> updates to support for following interrupt parent connection:
>> - INTR -> INTR
>> - INTA -> GICv3
>> The current existing driver assumes that INTR is always connected to
>> GICv3 and INTA is always connected to INTR.
>>
>> As discussed this change breaks the DT backward compatibility but it
>> allows to not depend on TISCI firmware properties in DT node. IMHO, this
>> will ensure that any future changes will not effect DT properties.
> 
> Just to note:
> this series will demand new sysfw (with ABI 3.0+) to boot (well, to have
> usable intr/inta). Sysfw ABI 3.0 carries other non compatible changes
> affecting DMA on am654: TR mode channels for servicing peripherals will
> fail at request time since the channel OES offset value is different
> compared to older sysfw ABI.
> 
> The good news is that other channels are _not_ affected by this, so
> packet mode channels and mem2mem TR channel pairs will work just fine -
> as you have tested it already w/ NFS boot.
> We do not have upstream users for TR mode channels for peripherals, it
> is only in my local branch for audio.
> 
> I can send a patch for UDMA to be picked up by Marc on top of this
> series to avoid this, if it is OK with Marc to pick it up.
This series is already straddling too many subsystems, I would not
complicate this any further.

Moreover, since there are no upstream users for TR mode peripheral
channels those changes can wait, right?

Thanks,
Sekhar