From: Mathieu Poirier <mathieu.poirier@linaro.org>
To: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Chunyan Zhang <zhang.chunyan@linaro.org>,
Rob Herring <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, 22 Feb 2016 11:01:20 -0700 [thread overview]
Message-ID: <CANLsYkyaPv_F+TGdGyKMyszs+ocCC=FzfP+Rmqf+O1XT9Wib9w@mail.gmail.com> (raw)
In-Reply-To: <CANLsYkz1nNYdcTXrkZ+HAMHexNandm93EpM7auvYE4CY43hy6w@mail.gmail.com>
On 12 February 2016 at 13:33, Mathieu Poirier
<mathieu.poirier@linaro.org> wrote:
> On 12 February 2016 at 09:27, Alexander Shishkin
> <alexander.shishkin@linux.intel.com> wrote:
>> Mathieu Poirier <mathieu.poirier@linaro.org> writes:
>>
>>> On 8 February 2016 at 06:26, Alexander Shishkin
>>> <alexander.shishkin@linux.intel.com> wrote:
>>>> 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.
>>>
>>> Some clarification here.
>>>
>>> On ARM from a SW point of view $end == $start and that doesn't change
>>> (with regards to masterIDs) . The ambiguity comes from the fact that
>>> on other platforms where masterID configuration does change and is
>>> important, the condition $end == $start could also be valid.
>>
>> Yes, that's what I was saying. The thing is, on the system-under-tracing
>> side these two situations are not very different from one
>> another. Master IDs are really just numbers without any semantics
>> attached to them in the sense that they are not covered by the mipi spec
>> or any other standard (to my knowledge).
>
> We are definitely on the same page here, just using slightly different terms.
>
>>
>> The difference is in the way we map channels to masters. One way is to
>> allocate a distinct set of channels for each master (the way Intel Trace
>> Hub does it); another way is to share the same set of channels between
>> multiple masters.
>
> We are in total agreement.
>
>> So we can describe this as "hardware implements the
>> same set of channels across multiple masters" or something along those
>> lines.
>
> I suggest "Shared channels"? In the end, that's really what it is...
>
> The outstanding issue is still how to represent these to different way
> of mapping things in the STM core. I suggested a flag, called
> "mstatic" (but that can be changed), and a representation of '-1' in
> for masterIDs sysFS. Whether we stick with that or not is irrelevant,
> I'd be fine with another mechanism. What I am keen on is that from
> sysFS users can quickly tell which heuristic is enacted on that
> specific architecture.
Alex,
How do you want to proceed with the above? Do you agree with my
current proposal or can you think of a better way?
Thanks,
Mathieu
>
>>
>> Actually, in the latter scheme of things you can also have multiple
>> masters, at least theoretically. Say, you have masters [0..15], each
>> with distinct set of channels, but depending on hardware state these
>> masters actually end up as $state*16+$masterID in the STP stream.
>>
>> So we might also think about differentiating between the hardware
>> masters (0 though 15 in the above example) and STP masters.
>
> I'm not sure I get what you mean here. On ARM the masterIDs assigned
> in HW, which will depend on the state, will show up in the STP stream.
> But again, I might be missing your point.
>
> Thanks,
> Mathieu
>
>>
>> Regards,
>> --
>> Alex
next prev parent reply other threads:[~2016-02-22 18:01 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 ` [PATCH] stm class: fix semicolon.cocci warnings kbuild test robot
2016-02-03 10:05 ` [PATCH V2 2/6] stm class: adds a loop to extract the first valid STM device name kbuild test robot
2016-02-04 8:56 ` 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
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 [this message]
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='CANLsYkyaPv_F+TGdGyKMyszs+ocCC=FzfP+Rmqf+O1XT9Wib9w@mail.gmail.com' \
--to=mathieu.poirier@linaro.org \
--cc=al.grant@arm.com \
--cc=alexander.shishkin@linux.intel.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=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;
as well as URLs for NNTP newsgroup(s).