On 12 February 2016 at 09:27, Alexander Shishkin <alexander.shishkin@xxxxxxxxxxxxxxx> wrote: > Mathieu Poirier <mathieu.poirier@xxxxxxxxxx> writes: > >> On 8 February 2016 at 06:26, Alexander Shishkin >> <alexander.shishkin@xxxxxxxxxxxxxxx> 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. > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
