Re: [RESEND PATCH V4 1/4] stm class: provision for statically assigned masterIDs

From: Alexander Shishkin
Date: Thu Mar 31 2016 - 09:20:33 EST


Mathieu Poirier <mathieu.poirier@xxxxxxxxxx> writes:

> On 21 March 2016 at 01:47, Alexander Shishkin
> <alexander.shishkin@xxxxxxxxxxxxxxx> wrote:
>> Chunyan Zhang <zhang.chunyan@xxxxxxxxxx> writes:
>>
>>> From: Mathieu Poirier <mathieu.poirier@xxxxxxxxxx>
>>>
>>> Some architecture like ARM assign masterIDs at the HW design
>>> phase. Those are therefore unreachable to users, making masterID
>>> management in the generic STM core irrelevant.
>>>
>>> In this kind of configuration channels are shared between masters
>>> rather than being allocated on a per master basis.
>>>
>>> This patch adds a new 'mshared' flag to struct stm_data that tells the
>>> core that this specific STM device doesn't need explicit masterID
>>> management.
>>
>> There are two kinds of 'masterIDs' that we're talking about here: the
>> ones that turn up in the STP stream and the ones that are accessible to
>> trace-side software (sw_start/sw_end). So in this case we want to
>> reflect the fact that there is no correlation between the two, because
>> hardware assigns STP channels dynamically based on the states of the
>> trace/execution environment. And although the trace side software can do
>> very little with this information, it does make sense to provide it.
>>
>> The sw_start==sw_end situation, on the other hand, is a side effect of
>> the above and, as I said in one of the previous threads, may not even be
>> the case, or at least I don't see why it has to. And when it is the
>> case, I don't see the point in handling it differently from
>> sw_start<sw_end situation.

[snip]

> Other than the above, is there anything you'd like to see modified in
> this patch, i.e how the mshared flag is used to modify the output in
> sysFS/configFS?

Yes, the two paragraphs quoted above that had gone unnoticed. I've
been thinking some more about this and came up with the following. No
need to do any extra handling in the policy code or anywhere else.