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

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.

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

Thanks and regards,
Lokesh

Lokesh Vutla (12):
  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: Add support for INTA directly connecting to GIC
  arm64: dts: k3-j721e: ti-sci-inta/intr: Update to latest bindings
  arm64: dts: k3-am65: ti-sci-inta/intr: Update to latest bindings
  arm64: dts: k3-am65: Update the RM resource types

 .../interrupt-controller/ti,sci-inta.txt      |  66 --------
 .../interrupt-controller/ti,sci-inta.yaml     | 104 ++++++++++++
 .../interrupt-controller/ti,sci-intr.txt      |  82 ---------
 .../interrupt-controller/ti,sci-intr.yaml     | 113 +++++++++++++
 MAINTAINERS                                   |   4 +-
 arch/arm64/boot/dts/ti/k3-am65-main.dtsi      |  34 ++--
 arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi       |  12 +-
 arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi    |   8 +-
 .../arm64/boot/dts/ti/k3-am654-base-board.dts |   4 +-
 .../dts/ti/k3-j721e-common-proc-board.dts     |  10 +-
 arch/arm64/boot/dts/ti/k3-j721e-main.dtsi     |  41 ++---
 .../boot/dts/ti/k3-j721e-mcu-wakeup.dtsi      |  12 +-
 drivers/firmware/ti_sci.c                     | 155 ++++++++----------
 drivers/irqchip/irq-ti-sci-inta.c             |  90 ++++++++--
 drivers/irqchip/irq-ti-sci-intr.c             | 150 ++++++++++-------
 include/linux/soc/ti/ti_sci_protocol.h        |  13 ++
 16 files changed, 527 insertions(+), 371 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

Hi Marc,

On 15/06/20 2:04 pm, Marc Zyngier wrote:
> On 2020-06-15 09:03, Lokesh Vutla wrote:

>> Hi Marc,

>>

>> On 01/06/20 5:06 pm, Lokesh Vutla wrote:

>>> Hi Marc,

>>>

>>> On 29/05/20 3:48 pm, Marc Zyngier wrote:

>>>> On 2020-05-29 11:14, Lokesh Vutla wrote:

>>>>> Hi Rob,

>>>>>

>>>>> On 29/05/20 3:44 am, Rob Herring wrote:

>>>>>> On Wed, May 20, 2020 at 06:14:46PM +0530, Lokesh Vutla wrote:

>>>>>>> Drop the firmware related dt-bindings and use the hardware specified

>>>>>>> interrupt numbers within Interrupt Router. This ensures interrupt router

>>>>>>> DT node need not assume any interrupt parent type.

>>>>>>

>>>>>> I didn't like this binding to begin with, but now you're breaking

>>>>>> compatibility.

>>>>>

>>>>> Yes, I do agree that this change is breaking backward compatibility. But IMHO,

>>>>> this does cleanup of firmware specific properties from DT. Since this is not

>>>>> deployed out yet in the wild market, I took the leverage of breaking backward

>>>>> compatibility. Before accepting these changes from firmware team, I did

>>>>> discuss[0] with Marc on this topic.

>>>>

>>>> And I assume that should anyone complain about the kernel being broken

>>>> because they have an old firmware, you'll be OK with the patches being

>>>> reverted, right?

>>>

>>> I am assuming there is no one to complain as there is no product available yet

>>> with upstream kernel. Internally everyone is aware of the changes. So, yes I

>>> would agree with you to revert the changes if someone really needs it. :)

>>

>> Any chance you can shower your blessings on this series :)

> 

> I have purposely ignored it just before and during the merge window. It is now

> firmly in my review queue.


rc4 is tagged now. Do you want me to rebase, split the series and repost it?

Thanks and reagrds,
Lokesh

> 

>         M.