On 12 February 2016 at 13:33, Mathieu Poirier <mathieu.poirier@xxxxxxxxxx> wrote: > 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. 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 -- 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
