From: Mike Leach <mike.leach@linaro.org>
To: Suzuki Kuruppassery Poulose <suzuki.poulose@arm.com>
Cc: Coresight ML <coresight@lists.linaro.org>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
devicetree@vger.kernel.org,
"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
Mathieu Poirier <mathieu.poirier@linaro.org>
Subject: Re: [PATCH v5 06/14] coresight: cti: Add device tree support for v8 arch CTI
Date: Tue, 3 Dec 2019 12:25:52 +0000 [thread overview]
Message-ID: <CAJ9a7VgH6tueHP_bCcwKzORbBxxADrRhUzPaSe=3NixCC05=Dw@mail.gmail.com> (raw)
In-Reply-To: <ffda8aff-0904-7292-e2f1-93833b936c49@arm.com>
Hi Suzuki,
On Tue, 3 Dec 2019 at 11:28, Suzuki Kuruppassery Poulose
<suzuki.poulose@arm.com> wrote:
>
> On 03/12/2019 10:59, Mike Leach wrote:
> > Hi Suzuki,
> >
> > On Fri, 29 Nov 2019 at 11:33, Suzuki Kuruppassery Poulose
> > <suzuki.poulose@arm.com> wrote:
> >>
> >> On 19/11/2019 23:19, Mike Leach wrote:
> >>> The v8 architecture defines the relationship between a PE, its optional ETM
> >>> and a CTI. Unlike non-architectural CTIs which are implementation defined,
> >>> this has a fixed set of connections which can therefore be represented as a
> >>> simple tag in the device tree.
> >>>
> >>> This patch defines the tags needed to create an entry for this PE/ETM/CTI
> >>> relationship, and provides functionality to implement the connection model
> >>> in the CTI driver.
> >>>
> >>> Signed-off-by: Mike Leach <mike.leach@linaro.org>
> >>> ---
>
>
> >>> +#ifdef CONFIG_OF
> >>> +/*
> >>> + * CTI can be bound to a CPU, or a system device.
> >>> + * CPU can be declared at the device top level or in a connections node
> >>> + * so need to check relative to node not device.
> >>> + */
> >>> +static int of_cti_get_cpu_at_node(const struct device_node *node)
> >>> +{
> >>> + int cpu;
> >>> + struct device_node *dn;
> >>> +
> >>> + if (node == NULL)
> >>> + return -1;
> >>> +
> >>> + dn = of_parse_phandle(node, "cpu", 0);
> >>> + /* CTI affinity defaults to no cpu */
> >>> + if (!dn)
> >>> + return -1;
> >>> + cpu = of_cpu_node_to_id(dn);
> >>> + of_node_put(dn);
> >>> +
> >>> + /* No Affinity if no cpu nodes are found */
> >>> + return (cpu < 0) ? -1 : cpu;
> >>> +}
> >>> +
> >>> +static const char *of_cti_get_node_name(const struct device_node *node)
> >>> +{
> >>> + if (node)
> >>> + return node->full_name;
> >>> + return "unknown";
> >>> +}
> >>> +#else
> >>> +static int of_cti_get_cpu_at_node(const struct device_node *node)
> >>> +{
> >>> + return -1;
> >>> +}
> >>> +
> >>> +static const char *of_cti_get_node_name(const struct device_node *node)
> >>> +{
> >>> + return "unknown";
> >>> +}
> >>> +#endif
> >>> +
> >>> +static int cti_plat_get_cpu_at_node(struct fwnode_handle *fwnode)
> >>> +{
> >>
> >> You may simply reuse coresight_get_cpu() below, instead of adding this
> >> duplicate set of functions. See below.
> >>
> >>
> >
> > No we can't. coresight_get_cpu gets the 'cpu' entry relative to the
> > device node, this gets the 'cpu' relative to the supplied node.
> > This is very important for the case where a none v8 architected PE is
> > attached to a CTI. This will use the devicetree form:-
> >
> > cti@<addr> {
> > [ some stuff ]
> > trig_conns@1 {
> > cpu = <&CPU0>
> > [trigger signal connection info for this cpu]
> > }
> > }
> >
> > trig_conns is a child node and we must look for 'cpu' relative to it.
>
> Ok. May be we could refactor the function to find the 'CPU' node
> relative to the given "fwnode" and let the coresight_get_cpu() use it ?
>
> int coresight_get_cpu(struct device *dev)
> {
> return coresight_get_fwnode_cpu(dev_fwnode(dev));
> }
>
> That way it is clear what we are dealing with. i.e, fwnode of any level
> (device or an intermediate node).
>
At present the generic coresight_get_cpu() deals with both DT and ACPI
bindings.
To refactor this would require re-factoring both binding types - and
at present we have no definition for ACPI bindings for CTI and hence
no way of knowing how the embedded cpu node is going to be
represented.
I think we have to take just the DT binding as is for now as a CTI
specific element and consider if it is worth re-factoring once the
ACPI bindings are defined
Regards
Mike
> >>> + csdev = cti_get_assoc_csdev_by_fwnode(cs_fwnode);
> >>> + if (csdev)
> >>> + assoc_name = dev_name(&csdev->dev);
> >>
> >> Does it make sense to defer the probing until the ETM device turn up ?
> >> Its fine either way.
> >>
> >
> > Not really as the ETM is optional but the PE still has a CTI.
>
> Ah, you're right. Please ignore my comment.
>
> Kind regards
> Suzuki
--
Mike Leach
Principal Engineer, ARM Ltd.
Manchester Design Centre. UK
next prev parent reply other threads:[~2019-12-03 12:26 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-19 23:18 [PATCH v5 00/14] CoreSight CTI Driver Mike Leach
2019-11-19 23:18 ` [PATCH v5 01/14] coresight: cti: Initial " Mike Leach
2019-11-21 20:21 ` Mathieu Poirier
2019-11-29 12:05 ` Mike Leach
2019-12-03 16:53 ` Mathieu Poirier
2019-11-25 19:03 ` Suzuki Kuruppassery Poulose
2019-11-29 12:06 ` Mike Leach
2019-11-19 23:19 ` [PATCH v5 02/14] coresight: cti: Add sysfs coresight mgmt reg access Mike Leach
2019-11-22 17:19 ` Mathieu Poirier
2019-11-19 23:19 ` [PATCH v5 03/14] coresight: cti: Add sysfs access to program function regs Mike Leach
2019-11-27 18:26 ` Suzuki Kuruppassery Poulose
2019-11-29 12:47 ` Mike Leach
2019-11-28 10:54 ` Suzuki Kuruppassery Poulose
2019-11-28 17:20 ` Mathieu Poirier
2019-11-28 18:00 ` Suzuki Kuruppassery Poulose
2019-11-29 12:50 ` Mike Leach
2019-11-19 23:19 ` [PATCH v5 04/14] coresight: cti: Add sysfs trigger / channel programming API Mike Leach
2019-11-22 18:40 ` Mathieu Poirier
2019-11-27 18:40 ` Suzuki Kuruppassery Poulose
2019-11-29 13:01 ` Mike Leach
2019-11-19 23:19 ` [PATCH v5 05/14] dt-bindings: arm: Adds CoreSight CTI hardware definitions Mike Leach
2019-11-20 19:06 ` Mathieu Poirier
2019-11-20 22:39 ` Mike Leach
2019-11-22 23:33 ` Rob Herring
2019-11-29 13:50 ` Mike Leach
2019-11-29 14:12 ` Suzuki Kuruppassery Poulose
2019-11-28 18:38 ` Suzuki Kuruppassery Poulose
2019-11-29 13:57 ` Mike Leach
2019-11-19 23:19 ` [PATCH v5 06/14] coresight: cti: Add device tree support for v8 arch CTI Mike Leach
2019-11-25 19:00 ` Mathieu Poirier
2019-11-29 11:33 ` Suzuki Kuruppassery Poulose
2019-12-03 10:59 ` Mike Leach
2019-12-03 11:28 ` Suzuki Kuruppassery Poulose
2019-12-03 12:25 ` Mike Leach [this message]
2019-11-19 23:19 ` [PATCH v5 07/14] coresight: cti: Add device tree support for custom CTI Mike Leach
2019-11-25 21:22 ` Mathieu Poirier
2019-11-29 14:16 ` Suzuki Kuruppassery Poulose
2019-11-29 21:11 ` Mathieu Poirier
2019-11-29 14:18 ` Suzuki Kuruppassery Poulose
2019-12-03 14:05 ` Mike Leach
2019-11-19 23:19 ` [PATCH v5 08/14] coresight: cti: Enable CTI associated with devices Mike Leach
2019-11-25 22:45 ` Mathieu Poirier
2019-12-05 16:33 ` Mike Leach
2019-11-29 18:28 ` Suzuki Kuruppassery Poulose
2019-11-29 21:25 ` Mathieu Poirier
2019-12-05 16:33 ` Mike Leach
2019-11-19 23:19 ` [PATCH v5 09/14] coresight: cti: Add connection information to sysfs Mike Leach
2019-11-27 18:09 ` Mathieu Poirier
2019-12-06 16:24 ` Mike Leach
2019-12-02 9:47 ` Suzuki Kuruppassery Poulose
2019-12-06 16:24 ` Mike Leach
2019-11-19 23:19 ` [PATCH v5 10/14] dt-bindings: qcom: Add CTI options for qcom msm8916 Mike Leach
2019-11-27 18:18 ` Mathieu Poirier
2019-11-19 23:19 ` [PATCH v5 11/14] dt-bindings: arm: Juno platform - add CTI entries to device tree Mike Leach
2019-11-27 18:25 ` Mathieu Poirier
2019-11-19 23:19 ` [PATCH v5 12/14] dt-bindings: hisilicon: Add CTI bindings for hi-6220 Mike Leach
2019-11-19 23:19 ` [PATCH v5 13/14] docs: coresight: Update documentation for CoreSight to cover CTI Mike Leach
2019-11-27 19:00 ` Mathieu Poirier
2019-12-02 10:43 ` Suzuki Kuruppassery Poulose
2019-12-06 17:39 ` Mike Leach
2019-11-19 23:19 ` [PATCH v5 14/14] docs: sysfs: coresight: Add sysfs ABI documentation for CTI Mike Leach
2019-11-27 19:08 ` Mathieu Poirier
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='CAJ9a7VgH6tueHP_bCcwKzORbBxxADrRhUzPaSe=3NixCC05=Dw@mail.gmail.com' \
--to=mike.leach@linaro.org \
--cc=coresight@lists.linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=mathieu.poirier@linaro.org \
--cc=suzuki.poulose@arm.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).