mbox series

[v5,00/10] irqchip: ti, sci-intr/inta: Update the dt bindings to accept different interrupt parents

Message ID 20200728051735.6187-1-lokeshvutla@ti.com (mailing list archive)
Headers show
Series irqchip: ti, sci-intr/inta: Update the dt bindings to accept different interrupt parents | expand

Message

Lokesh Vutla July 28, 2020, 5:17 a.m. UTC
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.

This series depends on the the new Yaml bindings for common TISCI[1]

[0] https://lore.kernel.org/linux-arm-kernel/20190923042405.26064-1-lokeshvutla@ti.com/
[1] https://patchwork.kernel.org/patch/11676843/

Tested with:
- DT_SCHEMA_FILES="Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.yaml"
  v8make dt_binding_check
- DT_SCHEMA_FILES="Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.yaml"
  v8make dt_binding_check
- DT_SCHEMA_FILES="Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.yaml"
  v8make dtbs_check
- DT_SCHEMA_FILES="Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.yaml"
  v8make dtbs_check
 

Changes since v4:
- Fixed Rob's comment on INTR and INTA yaml documentation
- Collected Reviewed-by's and Acked-by's

Changes since v3:
- Hardcode param_count based on parent instead of reading it from DT.
- Drop storing TISCI device id in platform device id field.

Changes since v2:
- Fixed comments from Rob
- Fixed DT schema warnings.

Changes since v1:
- Rebased on top of latest Linux master
- Dropped DT patches.


Lokesh Vutla (10):
  firmware: ti_sci: Drop the device id to resource type translation
  firmware: ti_sci: Drop unused structure ti_sci_rm_type_map
  firmware: ti_sci: Add support for getting resource with subtype
  dt-bindings: irqchip: ti,sci-intr: Update bindings to drop the usage
    of gic as parent
  dt-bindings: irqchip: Convert ti,sci-intr bindings to yaml
  irqchip/ti-sci-intr: Add support for INTR being a parent to INTR
  dt-bindings: irqchip: ti,sci-inta: Update docs to support different
    parent.
  dt-bindings: irqchip: Convert ti,sci-inta bindings to yaml
  irqchip/ti-sci-inta: Do not store TISCI device id in platform device
    id field
  irqchip/ti-sci-inta: Add support for INTA directly connecting to GIC

 .../interrupt-controller/ti,sci-inta.txt      |  66 --------
 .../interrupt-controller/ti,sci-inta.yaml     |  98 +++++++++++
 .../interrupt-controller/ti,sci-intr.txt      |  82 ---------
 .../interrupt-controller/ti,sci-intr.yaml     | 102 ++++++++++++
 MAINTAINERS                                   |   4 +-
 drivers/firmware/ti_sci.c                     | 155 ++++++++----------
 drivers/irqchip/irq-ti-sci-inta.c             |  95 +++++++++--
 drivers/irqchip/irq-ti-sci-intr.c             | 152 ++++++++++-------
 include/linux/soc/ti/ti_sci_protocol.h        |  13 ++
 9 files changed, 455 insertions(+), 312 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.txt
 create mode 100644 Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.yaml
 delete mode 100644 Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
 create mode 100644 Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.yaml

Comments

Marc Zyngier July 31, 2020, 5:01 p.m. UTC | #1
On 2020-07-28 06:17, 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.

I'm OK to take this if I can get an Ack from RobH on the three
DT patches that still need it.

Thanks,

         M.
Lokesh Vutla July 31, 2020, 5:51 p.m. UTC | #2
On 31/07/20 10:31 pm, Marc Zyngier wrote:
> On 2020-07-28 06:17, 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.
> 
> I'm OK to take this if I can get an Ack from RobH on the three
> DT patches that still need it.

Thanks Marc.

Rob,
	If you don't have any further comments on DT bindings, can you please ack the
patches?

Thanks and regards,
Lokesh
Rob Herring July 31, 2020, 6:16 p.m. UTC | #3
On Fri, Jul 31, 2020 at 06:01:50PM +0100, Marc Zyngier wrote:
> On 2020-07-28 06:17, 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.
> 
> I'm OK to take this if I can get an Ack from RobH on the three
> DT patches that still need it.

Reviewed-by: Rob Herring <robh@kernel.org>

However, there's a dependency on 
bindings/arm/keystone/ti,k3-sci-common.yaml.

That's a dependency on this being merged. I don't care if it breaks in 
your tree, but I care for -next and Linus' tree. There could also be 
other 'make dt_bindings_check' failures/warnings with this as the above 
dependency prevents further testing.

Rob
Suman Anna July 31, 2020, 6:24 p.m. UTC | #4
On 7/31/20 1:16 PM, Rob Herring wrote:
> On Fri, Jul 31, 2020 at 06:01:50PM +0100, Marc Zyngier wrote:
>> On 2020-07-28 06:17, 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.
>>
>> I'm OK to take this if I can get an Ack from RobH on the three
>> DT patches that still need it.
> 
> Reviewed-by: Rob Herring <robh@kernel.org>
> 
> However, there's a dependency on
> bindings/arm/keystone/ti,k3-sci-common.yaml.
> 
> That's a dependency on this being merged. I don't care if it breaks in
> your tree, but I care for -next and Linus' tree. There could also be
> other 'make dt_bindings_check' failures/warnings with this as the above
> dependency prevents further testing.
> 

Bjorn did pick up the above common binding file through the remoteproc 
tree, and it is available in -next. That said, I donno the merge order 
between remoteproc and irq subsystem trees into -next, and if that is a 
concern.

regards
Suman
Rob Herring July 31, 2020, 8:59 p.m. UTC | #5
On Fri, Jul 31, 2020 at 01:24:17PM -0500, Suman Anna wrote:
> On 7/31/20 1:16 PM, Rob Herring wrote:
> > On Fri, Jul 31, 2020 at 06:01:50PM +0100, Marc Zyngier wrote:
> > > On 2020-07-28 06:17, 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.
> > > 
> > > I'm OK to take this if I can get an Ack from RobH on the three
> > > DT patches that still need it.
> > 
> > Reviewed-by: Rob Herring <robh@kernel.org>
> > 
> > However, there's a dependency on
> > bindings/arm/keystone/ti,k3-sci-common.yaml.
> > 
> > That's a dependency on this being merged. I don't care if it breaks in
> > your tree, but I care for -next and Linus' tree. There could also be
> > other 'make dt_bindings_check' failures/warnings with this as the above
> > dependency prevents further testing.
> > 
> 
> Bjorn did pick up the above common binding file through the remoteproc tree,
> and it is available in -next. That said, I donno the merge order between
> remoteproc and irq subsystem trees into -next, and if that is a concern.

I'm less concerned about merge order at this point. -rc1 not being 
broken is the low bar I have...

Rob
Sekhar Nori Aug. 2, 2020, 10:34 a.m. UTC | #6
On 8/1/20 2:29 AM, Rob Herring wrote:
> On Fri, Jul 31, 2020 at 01:24:17PM -0500, Suman Anna wrote:
>> On 7/31/20 1:16 PM, Rob Herring wrote:
>>> On Fri, Jul 31, 2020 at 06:01:50PM +0100, Marc Zyngier wrote:
>>>> On 2020-07-28 06:17, 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.
>>>>
>>>> I'm OK to take this if I can get an Ack from RobH on the three
>>>> DT patches that still need it.
>>>
>>> Reviewed-by: Rob Herring <robh@kernel.org>
>>>
>>> However, there's a dependency on
>>> bindings/arm/keystone/ti,k3-sci-common.yaml.
>>>
>>> That's a dependency on this being merged. I don't care if it breaks in
>>> your tree, but I care for -next and Linus' tree. There could also be
>>> other 'make dt_bindings_check' failures/warnings with this as the above
>>> dependency prevents further testing.
>>>
>>
>> Bjorn did pick up the above common binding file through the remoteproc tree,
>> and it is available in -next. That said, I donno the merge order between
>> remoteproc and irq subsystem trees into -next, and if that is a concern.
> 
> I'm less concerned about merge order at this point. -rc1 not being 
> broken is the low bar I have...

Looking at Bjorn's remoteproc tree[0], the common bindings patch is 
applied on top of other (unrelated) remoteproc patches, so merging it 
into Marc's tree is out of question unless Bjorn is willing to re-write 
his tree (probably not).

The other option would be for Marc/Thomas to add these patches into a 
'late' branch, to be sent to Linus after Bjorn's tree has been merged.
Bjorn could help by sending his pull request early and someone from TI 
can keep an eye out for when its safe to merge.

Thanks,
Sekhar

[0] https://git.kernel.org/pub/scm/linux/kernel/git/andersson/remoteproc.git/log/?h=rproc-next
Lokesh Vutla Aug. 4, 2020, 5:16 p.m. UTC | #7
Hi All,

On 02/08/20 4:04 pm, Sekhar Nori wrote:
> On 8/1/20 2:29 AM, Rob Herring wrote:
>> On Fri, Jul 31, 2020 at 01:24:17PM -0500, Suman Anna wrote:
>>> On 7/31/20 1:16 PM, Rob Herring wrote:
>>>> On Fri, Jul 31, 2020 at 06:01:50PM +0100, Marc Zyngier wrote:
>>>>> On 2020-07-28 06:17, 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.
>>>>>
>>>>> I'm OK to take this if I can get an Ack from RobH on the three
>>>>> DT patches that still need it.
>>>>
>>>> Reviewed-by: Rob Herring <robh@kernel.org>
>>>>
>>>> However, there's a dependency on
>>>> bindings/arm/keystone/ti,k3-sci-common.yaml.
>>>>
>>>> That's a dependency on this being merged. I don't care if it breaks in
>>>> your tree, but I care for -next and Linus' tree. There could also be
>>>> other 'make dt_bindings_check' failures/warnings with this as the above
>>>> dependency prevents further testing.
>>>>
>>>
>>> Bjorn did pick up the above common binding file through the remoteproc tree,
>>> and it is available in -next. That said, I donno the merge order between
>>> remoteproc and irq subsystem trees into -next, and if that is a concern.
>>
>> I'm less concerned about merge order at this point. -rc1 not being 
>> broken is the low bar I have...
> 
> Looking at Bjorn's remoteproc tree[0], the common bindings patch is 
> applied on top of other (unrelated) remoteproc patches, so merging it 
> into Marc's tree is out of question unless Bjorn is willing to re-write 
> his tree (probably not).
> 
> The other option would be for Marc/Thomas to add these patches into a 
> 'late' branch, to be sent to Linus after Bjorn's tree has been merged.
> Bjorn could help by sending his pull request early and someone from TI 
> can keep an eye out for when its safe to merge.

What can we do to take this forward? Once this series is merged, DT changes
should also be merged. Else DMA will be broken as DT backward compatibility is
broken.

Thanks and regards,
Lokesh
Sekhar Nori Aug. 4, 2020, 5:28 p.m. UTC | #8
On 8/4/20 10:46 PM, Lokesh Vutla wrote:
> Hi All,
> 
> On 02/08/20 4:04 pm, Sekhar Nori wrote:
>> On 8/1/20 2:29 AM, Rob Herring wrote:
>>> On Fri, Jul 31, 2020 at 01:24:17PM -0500, Suman Anna wrote:
>>>> On 7/31/20 1:16 PM, Rob Herring wrote:
>>>>> On Fri, Jul 31, 2020 at 06:01:50PM +0100, Marc Zyngier wrote:
>>>>>> On 2020-07-28 06:17, 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.
>>>>>>
>>>>>> I'm OK to take this if I can get an Ack from RobH on the three
>>>>>> DT patches that still need it.
>>>>>
>>>>> Reviewed-by: Rob Herring <robh@kernel.org>
>>>>>
>>>>> However, there's a dependency on
>>>>> bindings/arm/keystone/ti,k3-sci-common.yaml.
>>>>>
>>>>> That's a dependency on this being merged. I don't care if it breaks in
>>>>> your tree, but I care for -next and Linus' tree. There could also be
>>>>> other 'make dt_bindings_check' failures/warnings with this as the above
>>>>> dependency prevents further testing.
>>>>>
>>>>
>>>> Bjorn did pick up the above common binding file through the remoteproc tree,
>>>> and it is available in -next. That said, I donno the merge order between
>>>> remoteproc and irq subsystem trees into -next, and if that is a concern.
>>>
>>> I'm less concerned about merge order at this point. -rc1 not being 
>>> broken is the low bar I have...
>>
>> Looking at Bjorn's remoteproc tree[0], the common bindings patch is 
>> applied on top of other (unrelated) remoteproc patches, so merging it 
>> into Marc's tree is out of question unless Bjorn is willing to re-write 
>> his tree (probably not).
>>
>> The other option would be for Marc/Thomas to add these patches into a 
>> 'late' branch, to be sent to Linus after Bjorn's tree has been merged.
>> Bjorn could help by sending his pull request early and someone from TI 
>> can keep an eye out for when its safe to merge.
> 
> What can we do to take this forward? Once this series is merged, DT changes
> should also be merged. Else DMA will be broken as DT backward compatibility is
> broken.

The DT parts should have been posted in the same series then, so as to
not cause breakage after the series is applied, and to preserve bisect
as much as possible.

IMHO, the whole series needs to be merged together even if parts of it
come from individual maintainers as immutable commits.

Do the DT portions cause merge conflicts with what is already there in
-next?

I think the next step would be to post the series again, this time with
DT changes included. Whether it goes into v5.9 or v5.10, thats probably
needed anyway.

Thanks,
Sekhar