On Sat, Jan 31, 2015 at 7:41 AM, Ohad Ben-Cohen <[email protected]> wrote:
> On Sat, Jan 31, 2015 at 1:29 AM, Bjorn Andersson <[email protected]> wrote:
> > In a system where you have two hwlock blocks lckA and lckB, each
> > consisting of 8 locks and you have dspB that can only access lckB
>
> This is a good example - thanks. To be able to cope with such cases we
> will have to pass a hwlock block reference and its relative lock id.
Additionally, to support such a scenario, we can no longer retain the
simple dynamic allocation API we have today, because it might end up
allocating dspB an hwlock from IckA.
We will have to make sure hwlocks are allocated only from pools
visible to the user, something that will change not only the
hwspinlock API but also the way it maintains the hwlocks.
I suspect we want to wait for such hardware to show up first, and only
then add framework support for it. Regardless, we obviously do want to
make sure our DT binding is prepared for the worse, so we'll drop the
"base-id" field.
Thanks,
Ohad.
On 02/01/2015 05:00 AM, Ohad Ben-Cohen wrote:
> On Sat, Jan 31, 2015 at 7:41 AM, Ohad Ben-Cohen <[email protected]> wrote:
>> On Sat, Jan 31, 2015 at 1:29 AM, Bjorn Andersson <[email protected]> wrote:
>>> In a system where you have two hwlock blocks lckA and lckB, each
>>> consisting of 8 locks and you have dspB that can only access lckB
>>
>> This is a good example - thanks. To be able to cope with such cases we
>> will have to pass a hwlock block reference and its relative lock id.
So, you mean lckB is only between the host and dspB. Obviously, if it
were shared between dspA and dspB only, then the allocation and
management would be completely outside the host Linux driver's scope.
>
> Additionally, to support such a scenario, we can no longer retain the
> simple dynamic allocation API we have today, because it might end up
> allocating dspB an hwlock from IckA.
>
> We will have to make sure hwlocks are allocated only from pools
> visible to the user, something that will change not only the
> hwspinlock API but also the way it maintains the hwlocks.
Right, the current API definitely will not scale for that. It was
designed around the concept that it's easier to exchange a single global
id, rather than a lcbB:id or some other similar semantics that needs to
be interpreted.
>
> I suspect we want to wait for such hardware to show up first, and only
> then add framework support for it.
Agreed.
regards
Suman
> Regardless, we obviously do want to
> make sure our DT binding is prepared for the worse, so we'll drop the
> "base-id" field.
>
> Thanks,
> Ohad.
>