On 12 February 2016 at 13:33, Mathieu Poirier
wrote:
> On 12 February 2016 at 09:27, Alexander Shishkin
> wrote:
>> Mathieu Poirier writes:
>>
>>> On 8 February 2016 at 06:26, Alexander Shishkin
>>> wrote:
This $end==$start situation itself may be ambiguous and can be
interpreted eith
On 12 February 2016 at 09:27, Alexander Shishkin
wrote:
> Mathieu Poirier writes:
>
>> On 8 February 2016 at 06:26, Alexander Shishkin
>> 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 wr
Mathieu Poirier writes:
> On 8 February 2016 at 06:26, Alexander Shishkin
> 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
>>
Al Grant writes:
>> Mike did write "master IDs are hardwired to individual cores and core
>> security
>> states", which make assignment for one platform very static.
>> On the flip side those will change from one system to another.
>
> It depends on your perspective. From the perspective of a u
On 8 February 2016 at 10:44, Al Grant wrote:
>> Mike did write "master IDs are hardwired to individual cores and core
>> security
>> states", which make assignment for one platform very static.
>> On the flip side those will change from one system to another.
>
> It depends on your perspective.
> Mike did write "master IDs are hardwired to individual cores and core security
> states", which make assignment for one platform very static.
> On the flip side those will change from one system to another.
It depends on your perspective. From the perspective of a userspace
process not pinned t
On 8 February 2016 at 06:26, Alexander Shishkin
wrote:
> Mathieu Poirier writes:
>
>> On 5 February 2016 at 05:52, Alexander Shishkin
>> wrote:
>>> Chunyan Zhang writes:
>>>
From: Mathieu Poirier
Some architecture like ARM assign masterIDs statically at the HW design
phase,
Mathieu Poirier writes:
> On 5 February 2016 at 05:52, Alexander Shishkin
> wrote:
>> Chunyan Zhang writes:
>>
>>> From: Mathieu Poirier
>>>
>>> Some architecture like ARM assign masterIDs statically at the HW design
>>> phase, making masterID manipulation in the generic STM core irrelevant.
>
Mike Leach writes:
> Hi,
>
> I think a quick clarification of the ARM hardware STM architecture may be of
> value here.
>
> The ARM hardware STM, when implemented as recommend in a hardware design, the
> master IDs are not under driver control, but have a hardwire association with
> source dev
On 5 February 2016 at 05:52, Alexander Shishkin
wrote:
> Chunyan Zhang writes:
>
>> From: Mathieu Poirier
>>
>> Some architecture like ARM assign masterIDs statically at the HW design
>> phase, making masterID manipulation in the generic STM core irrelevant.
>>
>> This patch adds a new 'mstatic'
ger.kernel.org;
> linux-arm-ker...@lists.infradead.org; linux-...@vger.kernel.org; linux-
> d...@vger.kernel.org
> Subject: Re: [PATCH V2 3/6] stm class: provision for statically assigned
> masterIDs
>
> Chunyan Zhang writes:
>
> > From: Mathieu Poirier
> >
> >
Chunyan Zhang writes:
> From: Mathieu Poirier
>
> Some architecture like ARM assign masterIDs statically at the HW design
> phase, making masterID manipulation in the generic STM core irrelevant.
>
> This patch adds a new 'mstatic' flag to struct stm_data that tells the
> core that this specific
12 matches
Mail list logo
