From: Alexander Shishkin <alexander.shishkin@linux.intel.com>
To: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Chunyan Zhang <zhang.chunyan@linaro.org>,
robh@kernel.org, Mark Brown <broonie@kernel.org>,
Pratik Patel <pratikp@codeaurora.org>,
Nicolas GUION <nicolas.guion@st.com>, Jon Corbet <corbet@lwn.net>,
Mark Rutland <mark.rutland@arm.com>,
Mike Leach <mike.leach@arm.com>, "Jeremiassen\, Tor" <tor@ti.com>,
Al Grant <al.grant@arm.com>, Lyra Zhang <zhang.lyra@gmail.com>,
"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arm-kernel\@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
linux-api@vger.kernel.org, linux-doc@vger.kernel.org
Subject: Re: [PATCH V2 3/6] stm class: provision for statically assigned masterIDs
Date: Mon, 08 Feb 2016 15:26:48 +0200 [thread overview]
Message-ID: <87twlj49k7.fsf@ashishki-desk.ger.corp.intel.com> (raw)
In-Reply-To: <CANLsYky2twQ98u241YyHD=atYRp1N56YVHUQNY2E2Ljsq0cseA@mail.gmail.com>
Mathieu Poirier <mathieu.poirier@linaro.org> writes:
> On 5 February 2016 at 05:52, Alexander Shishkin
> <alexander.shishkin@linux.intel.com> wrote:
>> Chunyan Zhang <zhang.chunyan@linaro.org> writes:
>>
>>> From: Mathieu Poirier <mathieu.poirier@linaro.org>
>>>
>>> Some architecture like ARM assign masterIDs statically at the HW design
>>> phase, making masterID manipulation in the generic STM core irrelevant.
>>>
>>> This patch adds a new 'mstatic' flag to struct stm_data that tells the
>>> core that this specific STM device doesn't need explicit masterID
>>> management.
>>
>> So why do we need this patch? If your STM only has master 42 allocated
>> for software sources, simply set sw_start = 42, sw_end = 42 and you're
>> good to go, software will have exactly one channel to choose from. See
>> also the comment from <linux/stm.h>:
>
> On ARM each source, i.e entity capable of accessing STM channels, has
> a different master ID set in HW. We can't assume the IDs are
> contiguous and from a SW point of view there is no way to probe the
> values.
Ok, it's the 'static' word that got me confused. From Mike's explanation
it seems to me that it's the antithesis of static; the master ID
assignment is so dynamic that it's not controllable by the software and
may or may not reflect core id, power state, phase of the moon, etc.
>>> In the core sw_start/end of masterID are set to '1',
>>> i.e there is only one masterID to deal with.
>>
>> This is also a completely arbitrary and unnecessary requirement. Again,
>> you can set both to 42 and it will still work.
>
> True - any value will do. The important thing to remember is that on
> ARM, there is only one masterID channel (from an STM core point of
> view). But we could also proceed differently, see below for more
> details.
Well, we have the masters attribute with two numbers in it that define
the range of master IDs that the software can choose from. More
specifically to this situation:
* the number of channel ID spaces available to the SW is
$end - $start + 1, that is, in your case, just 1;
* the number of master IDs for the SW to choose from is $end - $start;
* if $end==$start, their actual numeric value doesn't really matter,
either for the policy definition or for the actual writers.
This $end==$start situation itself may be ambiguous and can be
interpreted either as having just one *static* master ID fixed for all
SW writers (what I assumed from your commit message) or as having a
floating master ID, which changes of its own accord and is not
controllable by software.
These two situations are really the same thing from the perspective of
the system under tracing. Also, both of these situations should already
work if the driver sets both sw_start and sw_end to the same
value.
Regards,
--
Alex
next prev parent reply other threads:[~2016-02-08 13:26 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-03 8:15 [PATCH V2 0/6] Introduce CoreSight STM support Chunyan Zhang
2016-02-03 8:15 ` [PATCH V2 1/6] stm class: Add ioctl get_options interface Chunyan Zhang
2016-02-05 12:55 ` Alexander Shishkin
2016-02-03 8:15 ` [PATCH V2 2/6] stm class: adds a loop to extract the first valid STM device name Chunyan Zhang
2016-02-03 10:05 ` kbuild test robot
2016-02-03 10:05 ` [PATCH] stm class: fix semicolon.cocci warnings kbuild test robot
2016-02-04 8:56 ` [PATCH V2 2/6] stm class: adds a loop to extract the first valid STM device name Chunyan Zhang
2016-02-04 17:30 ` Alexander Shishkin
2016-02-05 3:18 ` Chunyan Zhang
2016-02-03 8:15 ` [PATCH V2 3/6] stm class: provision for statically assigned masterIDs Chunyan Zhang
2016-02-05 12:52 ` Alexander Shishkin
2016-02-05 16:31 ` Mike Leach
2016-02-08 10:52 ` Alexander Shishkin
2016-02-05 18:08 ` Mathieu Poirier
2016-02-08 13:26 ` Alexander Shishkin [this message]
2016-02-08 17:05 ` Mathieu Poirier
2016-02-08 17:44 ` Al Grant
2016-02-09 17:06 ` Mathieu Poirier
2016-02-12 15:54 ` Alexander Shishkin
2016-02-12 16:27 ` Alexander Shishkin
2016-02-12 20:33 ` Mathieu Poirier
2016-02-22 18:01 ` Mathieu Poirier
2016-02-03 8:15 ` [PATCH V2 4/6] Documentations: Add explanations of the case for non-configurable masters Chunyan Zhang
2016-02-03 8:15 ` [PATCH V2 5/6] coresight-stm: Bindings for System Trace Macrocell Chunyan Zhang
2016-02-03 8:15 ` [PATCH V2 6/6] coresight-stm: adding driver for CoreSight STM component Chunyan Zhang
2016-02-05 13:06 ` Alexander Shishkin
2016-02-05 14:30 ` Arnd Bergmann
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=87twlj49k7.fsf@ashishki-desk.ger.corp.intel.com \
--to=alexander.shishkin@linux.intel.com \
--cc=al.grant@arm.com \
--cc=broonie@kernel.org \
--cc=corbet@lwn.net \
--cc=linux-api@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mathieu.poirier@linaro.org \
--cc=mike.leach@arm.com \
--cc=nicolas.guion@st.com \
--cc=pratikp@codeaurora.org \
--cc=robh@kernel.org \
--cc=tor@ti.com \
--cc=zhang.chunyan@linaro.org \
--cc=zhang.lyra@gmail.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
all inboxes | Powered by JetHome®