[PATCH V2 3/6] stm class: provision for statically assigned masterIDs

On 12 February 2016 at 13:33, Mathieu Poirier
[off-list ref] wrote:

On 12 February 2016 at 09:27, Alexander Shishkin
[off-list ref] wrote:

quoted

Mathieu Poirier [off-list ref] writes:

quoted

On 8 February 2016 at 06:26, Alexander Shishkin
[off-list ref] wrote:

quoted

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.

quoted

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.

quoted

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

quoted

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

quoted

Regards,
--
Alex