[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CANLsYkyaPv_F+TGdGyKMyszs+ocCC=FzfP+Rmqf+O1XT9Wib9w@mail.gmail.com>
Date: Mon, 22 Feb 2016 11:01:20 -0700
From: Mathieu Poirier <mathieu.poirier@...aro.org>
To: Alexander Shishkin <alexander.shishkin@...ux.intel.com>
Cc: Chunyan Zhang <zhang.chunyan@...aro.org>,
Rob Herring <robh@...nel.org>, Mark Brown <broonie@...nel.org>,
Pratik Patel <pratikp@...eaurora.org>,
Nicolas GUION <nicolas.guion@...com>,
Jon Corbet <corbet@....net>,
Mark Rutland <mark.rutland@....com>,
Mike Leach <mike.leach@....com>,
"Jeremiassen, Tor" <tor@...com>, Al Grant <al.grant@....com>,
Lyra Zhang <zhang.lyra@...il.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>, linux-api@...r.kernel.org,
linux-doc@...r.kernel.org
Subject: Re: [PATCH V2 3/6] stm class: provision for statically assigned masterIDs
On 12 February 2016 at 13:33, Mathieu Poirier
<mathieu.poirier@...aro.org> wrote:
> On 12 February 2016 at 09:27, Alexander Shishkin
> <alexander.shishkin@...ux.intel.com> wrote:
>> Mathieu Poirier <mathieu.poirier@...aro.org> writes:
>>
>>> On 8 February 2016 at 06:26, Alexander Shishkin
>>> <alexander.shishkin@...ux.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
Powered by blists - more mailing lists