On Fri, Jan 30, 2015 at 9:41 PM, 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.
>
Correct, so the #hwlock-cells and hwlock part from the proposal are
the important one. Having an optional hwlock-names will make things
easier to read as well, but is not necessary.
> The DT binding should definitely be prepared for such cases (just kill
> the base-id field?), but let's see what it means about the Linux
> implementation.
>
>From the dt binding PoV, we should be able to skip num-locks as well.
It seems most hwlock blocks have a fixed amount of locks provided and
the drivers are reporting this to the core when registering.
So I think we can reduce the binding to:
Providers:
#hwlock-cells
Consumers:
hwlocks
hwlock-names
For the hardware where number of locks is actually variable (e.g.
different variants of same block) there can be driver specific entries
for this.
> Since the existence of several hwblocks is still fictional (Bjorn,
> please confirm too?), we may prefer to introduce changes to support it
> only when it shows up; it all depends on the amount of changes needed.
> Suman, care to take a look please?
>
I haven't seen any such systems yet.
We could introduce the logic found in other subsystems of allowing -1
as base_id and having the core find a available range. This will work
for all cases where the global ids doesn't have to be static; either
due to the fact that we use block:local-id or that the indices are
hard coded. (Referencing locks via dt is equivalent of the
block:local-id case)
>>> - Sometimes a remote processor, which may not be running Linux, will
>>> have to dynamically allocate a hwlock, and send the ID of the
>>> allocated lock to us (another processor running Linux)
>>>
>> I'm sorry but you cannot have a system on both sides that is allowed
>> to do dynamic allocation from a limited set of resources.
>
> Of course not. On such systems, Linux is not the one responsible for
> allocating the hwlocks, at least not during part of the time or from
> part of the hwlocks. There were a few different use cases, with
> different semantics, that required communicating to Linux an hwlock
> id, but since none of them have reached mainline, we should only
> remember they may show up one day, but not put too much effort to
> support them right now.
>
That makes more sense, although I still believe that you end up with a
system wide setup where locks are statically allocated in some
document beforehand. Either that or you will have to feed that other
system with the list of constraints.
Non the less, that's "unrelated".
If we get an incoming message saying lckX:Y (or the global lckZ), we
probably wouldn't define that in DT. We would need a way to resolve
the hwlock-block "lckX" so we can request lock Y from that block. We
would basically build the DT reference on the fly.
I think this is a future problem to be solved and more importantly I
don't think it's limited to hwlocks. If a system architect designs a
system where a remote entity will do allocation of resources for us,
they will most likely do so not only for hwlocks but also for gpios,
irqs and other resources that we today reference with arguments in DT.
Hopefully that will not happen anytime soon, so let's just ignore that
problem for now and go for a simple binding that will cover todays use
cases (with some thought into multi-block support).
Regards,
Bjorn
On 02/01/2015 11:55 AM, Bjorn Andersson wrote:
> On Fri, Jan 30, 2015 at 9:41 PM, 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.
>>
>
> Correct, so the #hwlock-cells and hwlock part from the proposal are
> the important one. Having an optional hwlock-names will make things
> easier to read as well, but is not necessary.
Right, if anything, it would be useful only for the clients, but the
hwspinlock core itself would not need it. So, I would forgo adding the
hwlock-names for now.
>
>> The DT binding should definitely be prepared for such cases (just kill
>> the base-id field?), but let's see what it means about the Linux
>> implementation.
>>
>
> From the dt binding PoV, we should be able to skip num-locks as well.
> It seems most hwlock blocks have a fixed amount of locks provided and
> the drivers are reporting this to the core when registering.
I added this originally based on the initial MSM HW Mutex block bindings.
>
> So I think we can reduce the binding to:
>
> Providers:
> #hwlock-cells
>
> Consumers:
> hwlocks
> hwlock-names
>
> For the hardware where number of locks is actually variable (e.g.
> different variants of same block) there can be driver specific entries
> for this.
Right, we should be able to drop this and use the driver match data. As
it is, the field is used during registration of the block with the
hwspinlock core.
regards
Suman
On Mon, Feb 2, 2015 at 1:07 PM, Suman Anna <[email protected]> wrote:
> On 02/01/2015 11:55 AM, Bjorn Andersson wrote:
>> On Fri, Jan 30, 2015 at 9:41 PM, 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.
>>>
>>
>> Correct, so the #hwlock-cells and hwlock part from the proposal are
>> the important one. Having an optional hwlock-names will make things
>> easier to read as well, but is not necessary.
>
> Right, if anything, it would be useful only for the clients, but the
> hwspinlock core itself would not need it. So, I would forgo adding the
> hwlock-names for now.
>
>>
>>> The DT binding should definitely be prepared for such cases (just kill
>>> the base-id field?), but let's see what it means about the Linux
>>> implementation.
>>>
>>
>> From the dt binding PoV, we should be able to skip num-locks as well.
>> It seems most hwlock blocks have a fixed amount of locks provided and
>> the drivers are reporting this to the core when registering.
>
> I added this originally based on the initial MSM HW Mutex block bindings.
>
It's not entirely correct to have this in DT for the MSM HW, as the
hardware has a fixed number of mutexes. As soon as we have the binding
sorted out I will follow up with a new revision of the tcsr/sfpb-mutex
driver.
>>
>> So I think we can reduce the binding to:
>>
>> Providers:
>> #hwlock-cells
>>
>> Consumers:
>> hwlocks
>> hwlock-names
>>
>> For the hardware where number of locks is actually variable (e.g.
>> different variants of same block) there can be driver specific entries
>> for this.
>
> Right, we should be able to drop this and use the driver match data. As
> it is, the field is used during registration of the block with the
> hwspinlock core.
>
If we have certain systems where it actually is a property to be
configured then they can have individual properties, extending the
standard set. Either way, it's not a dynamic property shared by all
hwlock drivers, so it should not be in the common binding.
Will you send out a new revision of the binding? I would love to get
this integrated so I can move on with the dependents.
Regards,
Bjorn
Hi Bjorn,
On 02/05/2015 05:01 PM, Bjorn Andersson wrote:
> On Mon, Feb 2, 2015 at 1:07 PM, Suman Anna <[email protected]> wrote:
>> On 02/01/2015 11:55 AM, Bjorn Andersson wrote:
>>> On Fri, Jan 30, 2015 at 9:41 PM, 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.
>>>>
>>>
>>> Correct, so the #hwlock-cells and hwlock part from the proposal are
>>> the important one. Having an optional hwlock-names will make things
>>> easier to read as well, but is not necessary.
>>
>> Right, if anything, it would be useful only for the clients, but the
>> hwspinlock core itself would not need it. So, I would forgo adding the
>> hwlock-names for now.
>>
>>>
>>>> The DT binding should definitely be prepared for such cases (just kill
>>>> the base-id field?), but let's see what it means about the Linux
>>>> implementation.
>>>>
>>>
>>> From the dt binding PoV, we should be able to skip num-locks as well.
>>> It seems most hwlock blocks have a fixed amount of locks provided and
>>> the drivers are reporting this to the core when registering.
>>
>> I added this originally based on the initial MSM HW Mutex block bindings.
>>
>
> It's not entirely correct to have this in DT for the MSM HW, as the
> hardware has a fixed number of mutexes. As soon as we have the binding
> sorted out I will follow up with a new revision of the tcsr/sfpb-mutex
> driver.
>
>>>
>>> So I think we can reduce the binding to:
>>>
>>> Providers:
>>> #hwlock-cells
>>>
>>> Consumers:
>>> hwlocks
>>> hwlock-names
>>>
>>> For the hardware where number of locks is actually variable (e.g.
>>> different variants of same block) there can be driver specific entries
>>> for this.
>>
>> Right, we should be able to drop this and use the driver match data. As
>> it is, the field is used during registration of the block with the
>> hwspinlock core.
>>
>
> If we have certain systems where it actually is a property to be
> configured then they can have individual properties, extending the
> standard set. Either way, it's not a dynamic property shared by all
> hwlock drivers, so it should not be in the common binding.
>
> Will you send out a new revision of the binding? I would love to get
> this integrated so I can move on with the dependents.
Yep, will do as soon as I hear from Ohad on what to do with the patch
"hwspinlock/core: maintain a list of registered hwspinlock banks" that I
dropped from v7. Without that and dropping hwlock-base-id, I can't get
the translations done.
regards
Suman
On Thu, Feb 5, 2015 at 4:11 PM, Suman Anna <[email protected]> wrote:
> Hi Bjorn,
>
> On 02/05/2015 05:01 PM, Bjorn Andersson wrote:
[..]
>> Will you send out a new revision of the binding? I would love to get
>> this integrated so I can move on with the dependents.
>
> Yep, will do as soon as I hear from Ohad on what to do with the patch
> "hwspinlock/core: maintain a list of registered hwspinlock banks" that I
> dropped from v7. Without that and dropping hwlock-base-id, I can't get
> the translations done.
>
My suggestion is to replace the global id-tree with a list of hwlocks
and iterate over these if we ever get more than one driver registered.
As long as #hwlock-drivers < log(#total-hwlocks) this should be
faster.
I would however argue that clients that would notice any kind of
difference are using the API incorrectly.
Unfortunately this is a somewhat larger change than just slapping DT
support on the framework :/
Regards,
Bjorn
On Fri, Feb 6, 2015 at 2:34 AM, Bjorn Andersson <[email protected]> wrote:
>> Yep, will do as soon as I hear from Ohad on what to do with the patch
>> "hwspinlock/core: maintain a list of registered hwspinlock banks" that I
>> dropped from v7. Without that and dropping hwlock-base-id, I can't get
>> the translations done.
>>
>
> My suggestion is to replace the global id-tree with a list of hwlocks
> and iterate over these if we ever get more than one driver registered.
> As long as #hwlock-drivers < log(#total-hwlocks) this should be
> faster.
>
> I would however argue that clients that would notice any kind of
> difference are using the API incorrectly.
>
> Unfortunately this is a somewhat larger change than just slapping DT
> support on the framework :/
I suspect we want to wait with framework changes until there's a real
hardware use case justifying them.
With regard to DT, however, we obviously do want to be prepared for
multiple hwlock blocks even if they do not exist today.
So how about adopting an approach where:
- DT fully supports multi hwlock blocks (i.e. no global id field)
- Framework left mostly unchanged at the moment. This means issuing an
explicit error in case a secondary hwlock block shows up, and then
hwlock id could trivially be the lock index.
If multi hwlock hardware use case, or some new hwlock id translation
requirements, do show up in the future, it's always easy to add
framework support for it. At that point we'll know better what the
requirements are, and framework changes would be justifiable.
Thanks,
Ohad.
Hi,
Sorry I've been away from this thread for a while.
On Wed, Feb 11, 2015 at 10:29:37AM +0000, Ohad Ben-Cohen wrote:
> On Fri, Feb 6, 2015 at 2:34 AM, Bjorn Andersson <[email protected]> wrote:
> >> Yep, will do as soon as I hear from Ohad on what to do with the patch
> >> "hwspinlock/core: maintain a list of registered hwspinlock banks" that I
> >> dropped from v7. Without that and dropping hwlock-base-id, I can't get
> >> the translations done.
> >>
> >
> > My suggestion is to replace the global id-tree with a list of hwlocks
> > and iterate over these if we ever get more than one driver registered.
> > As long as #hwlock-drivers < log(#total-hwlocks) this should be
> > faster.
> >
> > I would however argue that clients that would notice any kind of
> > difference are using the API incorrectly.
> >
> > Unfortunately this is a somewhat larger change than just slapping DT
> > support on the framework :/
>
> I suspect we want to wait with framework changes until there's a real
> hardware use case justifying them.
>
> With regard to DT, however, we obviously do want to be prepared for
> multiple hwlock blocks even if they do not exist today.
>
> So how about adopting an approach where:
> - DT fully supports multi hwlock blocks (i.e. no global id field)
> - Framework left mostly unchanged at the moment. This means issuing an
> explicit error in case a secondary hwlock block shows up, and then
> hwlock id could trivially be the lock index.
>
> If multi hwlock hardware use case, or some new hwlock id translation
> requirements, do show up in the future, it's always easy to add
> framework support for it. At that point we'll know better what the
> requirements are, and framework changes would be justifiable.
As mentioned in my other reply I think we need to be explicit now when
defining the set of hwlocks (and their namming/numbering) shared between
a given set of processors, as we do with other resources
(GPIOs/regulators/whatever).
We also need to be explicit in describing the set of actors which use
those locks.
I think my previous proposal covered both of those.
Thanks,
Mark.