From: Tony Lindgren <tony@atomide.com>
To: Lokesh Vutla <lokeshvutla@ti.com>
Cc: Nishanth Menon <nm@ti.com>,
Device Tree Mailing List <devicetree@vger.kernel.org>,
jason@lakedaemon.net, Peter Ujfalusi <peter.ujfalusi@ti.com>,
marc.zyngier@arm.com, Sekhar Nori <nsekhar@ti.com>,
linux-kernel@vger.kernel.org, Tero Kristo <t-kristo@ti.com>,
Rob Herring <robh+dt@kernel.org>,
Santosh Shilimkar <ssantosh@kernel.org>,
tglx@linutronix.de,
Linux ARM Mailing List <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v5 05/10] dt-bindings: irqchip: Introduce TISCI Interrupt router bindings
Date: Thu, 14 Feb 2019 09:46:12 -0800 [thread overview]
Message-ID: <20190214174612.GF5720@atomide.com> (raw)
In-Reply-To: <b4e821b3-f2fb-41d8-eb8c-8f4e8a19f77c@ti.com>
* Lokesh Vutla <lokeshvutla@ti.com> [190214 17:32]:
> Hi Tony,
> Please do not snip the on going discussion.
>
> On 2/14/2019 9:11 PM, Tony Lindgren wrote:
> > * Lokesh Vutla <lokeshvutla@ti.com> [190214 08:39]:
> >> IMHO, device ids are something which can be used in DT. There are many other
> >> things like the interrupt ranges etc.. which are discoverable from sysfw and we
> >> are implementing it.
> >
> > We need to describe hardware in the device tree, not firmware.
> >
> > If you have something discoverable from the firmware, you should
> > have the device driver query it from sysfw based on a hardware
> > property, not based on some invented enumeration in the firmware.
>
> Yes we are already querying sysfw for all the irq ranges that can be
> discoverable. The topic of discussion here is about the parent interrupt
> controller id. I am not sure how you are expecting an id be discoverable
> from system firmware especially with a name.
Well names are quite standard in dts (but should be used with
the phandle + offset). Think for example interrupt-names and
reg-names :)
> > If there is some device to firmware translation needed, hide that
> > into the device driver and keep it out of the device tree.
>
> If preferred this can be moved to of_match_data attached to each
> compatible property. Then for each SoC a new compatible needs to be created.
Hiding the ID into the device driver and compatible property
makes sense to me if the id is based on SoC + firmware.
But I'd rather have a proper hardware based phandle + index
type mapping in the dts if possible though.
What does this id really consist of?
Regards,
Tony
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Tony Lindgren <tony@atomide.com>
To: Lokesh Vutla <lokeshvutla@ti.com>
Cc: marc.zyngier@arm.com, Nishanth Menon <nm@ti.com>,
Santosh Shilimkar <ssantosh@kernel.org>,
Rob Herring <robh+dt@kernel.org>,
tglx@linutronix.de, jason@lakedaemon.net,
Linux ARM Mailing List <linux-arm-kernel@lists.infradead.org>,
linux-kernel@vger.kernel.org,
Device Tree Mailing List <devicetree@vger.kernel.org>,
Sekhar Nori <nsekhar@ti.com>, Tero Kristo <t-kristo@ti.com>,
Peter Ujfalusi <peter.ujfalusi@ti.com>
Subject: Re: [PATCH v5 05/10] dt-bindings: irqchip: Introduce TISCI Interrupt router bindings
Date: Thu, 14 Feb 2019 09:46:12 -0800 [thread overview]
Message-ID: <20190214174612.GF5720@atomide.com> (raw)
In-Reply-To: <b4e821b3-f2fb-41d8-eb8c-8f4e8a19f77c@ti.com>
* Lokesh Vutla <lokeshvutla@ti.com> [190214 17:32]:
> Hi Tony,
> Please do not snip the on going discussion.
>
> On 2/14/2019 9:11 PM, Tony Lindgren wrote:
> > * Lokesh Vutla <lokeshvutla@ti.com> [190214 08:39]:
> >> IMHO, device ids are something which can be used in DT. There are many other
> >> things like the interrupt ranges etc.. which are discoverable from sysfw and we
> >> are implementing it.
> >
> > We need to describe hardware in the device tree, not firmware.
> >
> > If you have something discoverable from the firmware, you should
> > have the device driver query it from sysfw based on a hardware
> > property, not based on some invented enumeration in the firmware.
>
> Yes we are already querying sysfw for all the irq ranges that can be
> discoverable. The topic of discussion here is about the parent interrupt
> controller id. I am not sure how you are expecting an id be discoverable
> from system firmware especially with a name.
Well names are quite standard in dts (but should be used with
the phandle + offset). Think for example interrupt-names and
reg-names :)
> > If there is some device to firmware translation needed, hide that
> > into the device driver and keep it out of the device tree.
>
> If preferred this can be moved to of_match_data attached to each
> compatible property. Then for each SoC a new compatible needs to be created.
Hiding the ID into the device driver and compatible property
makes sense to me if the id is based on SoC + firmware.
But I'd rather have a proper hardware based phandle + index
type mapping in the dts if possible though.
What does this id really consist of?
Regards,
Tony
next prev parent reply other threads:[~2019-02-14 17:46 UTC|newest]
Thread overview: 121+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-12 7:42 [PATCH v5 00/10] Add support for TISCI irqchip drivers Lokesh Vutla
2019-02-12 7:42 ` Lokesh Vutla
2019-02-12 7:42 ` Lokesh Vutla
2019-02-12 7:42 ` [PATCH v5 01/10] firmware: ti_sci: Add support to get TISCI handle using of_phandle Lokesh Vutla
2019-02-12 7:42 ` Lokesh Vutla
2019-02-12 7:42 ` Lokesh Vutla
2019-02-12 7:42 ` [PATCH v5 02/10] firmware: ti_sci: Add support for RM core ops Lokesh Vutla
2019-02-12 7:42 ` Lokesh Vutla
2019-02-12 7:42 ` Lokesh Vutla
2019-02-12 7:42 ` [PATCH v5 03/10] firmware: ti_sci: Add support for IRQ management Lokesh Vutla
2019-02-12 7:42 ` Lokesh Vutla
2019-02-12 7:42 ` Lokesh Vutla
2019-02-12 7:42 ` [PATCH v5 04/10] firmware: ti_sci: Add RM mapping table for am654 Lokesh Vutla
2019-02-12 7:42 ` Lokesh Vutla
2019-02-12 7:42 ` Lokesh Vutla
2019-02-12 7:42 ` [PATCH v5 05/10] dt-bindings: irqchip: Introduce TISCI Interrupt router bindings Lokesh Vutla
2019-02-12 7:42 ` Lokesh Vutla
2019-02-12 7:42 ` Lokesh Vutla
2019-02-12 16:22 ` Tony Lindgren
2019-02-12 16:22 ` Tony Lindgren
2019-02-13 4:25 ` Lokesh Vutla
2019-02-13 4:25 ` Lokesh Vutla
2019-02-13 4:25 ` Lokesh Vutla
2019-02-13 15:26 ` Tony Lindgren
2019-02-13 15:26 ` Tony Lindgren
2019-02-13 20:40 ` Rob Herring
2019-02-13 20:40 ` Rob Herring
2019-02-14 8:38 ` Lokesh Vutla
2019-02-14 8:38 ` Lokesh Vutla
2019-02-14 8:38 ` Lokesh Vutla
2019-02-14 15:41 ` Tony Lindgren
2019-02-14 15:41 ` Tony Lindgren
2019-02-14 17:32 ` Lokesh Vutla
2019-02-14 17:32 ` Lokesh Vutla
2019-02-14 17:32 ` Lokesh Vutla
2019-02-14 17:46 ` Tony Lindgren [this message]
2019-02-14 17:46 ` Tony Lindgren
2019-02-14 18:02 ` Lokesh Vutla
2019-02-14 18:02 ` Lokesh Vutla
2019-02-14 18:02 ` Lokesh Vutla
2019-02-15 16:16 ` Tony Lindgren
2019-02-15 16:16 ` Tony Lindgren
2019-02-16 3:29 ` Lokesh Vutla
2019-02-16 3:29 ` Lokesh Vutla
2019-02-16 3:29 ` Lokesh Vutla
2019-02-18 14:32 ` Tony Lindgren
2019-02-18 14:32 ` Tony Lindgren
2019-02-19 8:51 ` Lokesh Vutla
2019-02-19 8:51 ` Lokesh Vutla
2019-02-19 8:51 ` Lokesh Vutla
2019-02-19 15:35 ` Tony Lindgren
2019-02-19 15:35 ` Tony Lindgren
2019-02-19 16:19 ` Lokesh Vutla
2019-02-19 16:19 ` Lokesh Vutla
2019-02-19 16:19 ` Lokesh Vutla
2019-02-19 17:11 ` Tony Lindgren
2019-02-19 17:11 ` Tony Lindgren
2019-02-19 17:56 ` Tony Lindgren
2019-02-19 17:56 ` Tony Lindgren
2019-02-20 5:53 ` Lokesh Vutla
2019-02-20 5:53 ` Lokesh Vutla
2019-02-20 5:53 ` Lokesh Vutla
2019-02-20 16:36 ` Tony Lindgren
2019-02-20 16:36 ` Tony Lindgren
2019-02-20 17:17 ` Lokesh Vutla
2019-02-20 17:17 ` Lokesh Vutla
2019-02-20 17:17 ` Lokesh Vutla
2019-02-12 16:30 ` Tony Lindgren
2019-02-12 16:30 ` Tony Lindgren
2019-02-13 4:22 ` Lokesh Vutla
2019-02-13 4:22 ` Lokesh Vutla
2019-02-13 4:22 ` Lokesh Vutla
2019-02-13 15:32 ` Tony Lindgren
2019-02-13 15:32 ` Tony Lindgren
2019-02-14 8:40 ` Lokesh Vutla
2019-02-14 8:40 ` Lokesh Vutla
2019-02-14 8:40 ` Lokesh Vutla
2019-02-14 15:42 ` Tony Lindgren
2019-02-14 15:42 ` Tony Lindgren
2019-02-16 3:30 ` Lokesh Vutla
2019-02-16 3:30 ` Lokesh Vutla
2019-02-16 3:30 ` Lokesh Vutla
2019-02-18 14:35 ` Tony Lindgren
2019-02-18 14:35 ` Tony Lindgren
2019-02-22 10:10 ` Peter Ujfalusi
2019-02-22 10:10 ` Peter Ujfalusi
2019-02-18 15:12 ` Marc Zyngier
2019-02-18 15:12 ` Marc Zyngier
2019-02-18 15:12 ` Marc Zyngier
2019-02-18 15:27 ` Lokesh Vutla
2019-02-18 15:27 ` Lokesh Vutla
2019-02-18 15:27 ` Lokesh Vutla
2019-02-12 7:42 ` [PATCH v5 06/10] irqchip: ti-sci-intr: Add support for Interrupt Router driver Lokesh Vutla
2019-02-12 7:42 ` Lokesh Vutla
2019-02-12 7:42 ` Lokesh Vutla
2019-02-18 15:52 ` Marc Zyngier
2019-02-18 15:52 ` Marc Zyngier
2019-02-18 15:52 ` Marc Zyngier
2019-02-20 13:17 ` Lokesh Vutla
2019-02-20 13:17 ` Lokesh Vutla
2019-02-20 13:17 ` Lokesh Vutla
2019-03-19 12:44 ` Lokesh Vutla
2019-03-19 12:44 ` Lokesh Vutla
2019-03-19 12:44 ` Lokesh Vutla
2019-02-12 7:42 ` [PATCH v5 07/10] dt-bindings: irqchip: Introduce TISCI Interrupt Aggregator bindings Lokesh Vutla
2019-02-12 7:42 ` Lokesh Vutla
2019-02-12 7:42 ` Lokesh Vutla
2019-02-12 7:42 ` [PATCH v5 08/10] irqchip: ti-sci-inta: Add support for Interrupt Aggregator driver Lokesh Vutla
2019-02-12 7:42 ` Lokesh Vutla
2019-02-12 7:42 ` Lokesh Vutla
2019-02-12 7:42 ` [PATCH v5 09/10] soc: ti: Add MSI domain support for K3 Interrupt Aggregator Lokesh Vutla
2019-02-12 7:42 ` Lokesh Vutla
2019-02-12 7:42 ` Lokesh Vutla
2019-02-13 16:41 ` Tony Lindgren
2019-02-13 16:41 ` Tony Lindgren
2019-02-12 7:42 ` [PATCH v5 10/10] soc: ti: am6: Enable interrupt controller drivers Lokesh Vutla
2019-02-12 7:42 ` Lokesh Vutla
2019-02-12 7:42 ` Lokesh Vutla
2019-02-16 3:37 ` [PATCH v5 00/10] Add support for TISCI irqchip drivers Lokesh Vutla
2019-02-16 3:37 ` Lokesh Vutla
2019-02-16 3:37 ` Lokesh Vutla
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190214174612.GF5720@atomide.com \
--to=tony@atomide.com \
--cc=devicetree@vger.kernel.org \
--cc=jason@lakedaemon.net \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lokeshvutla@ti.com \
--cc=marc.zyngier@arm.com \
--cc=nm@ti.com \
--cc=nsekhar@ti.com \
--cc=peter.ujfalusi@ti.com \
--cc=robh+dt@kernel.org \
--cc=ssantosh@kernel.org \
--cc=t-kristo@ti.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.