On Wed 05 Aug 09:32 PDT 2015, Lina Iyer wrote:
> Hwspinlocks are widely used between processors in an SoC, and also
> between elevation levels within in the same processor. QCOM SoC's use
> hwspinlock to serialize entry into a low power mode when the context
> switches from Linux to secure monitor.
>
> Lock #7 has been assigned for this purpose. In order to differentiate
> between one cpu core holding a lock while another cpu is contending for
> the same lock, the proc id written into the lock is (128 + cpu id). This
> makes it unique value among the cpu cores and therefore when a core
> locks the hwspinlock, other cores would wait for the lock to be released
> since they would have a different proc id. This value is specific for
> the lock #7 only.
>
As I was thinking about this, I came to the conclusion that my argument
that it's system configuration and not a property of the block that lock
#7 is special is actually biting myself.
Just as #7 is system configuration, so is the fact that 1 is the lock
value for all other locks.
I've been meaning to answer you, but I haven't come to a good conclusion
in this matter. I think that both of these properties should be possible
to express in DT, but I don't know how.
Perhaps we should just list each lock that we expose as a subnode in DT
with a property to indicate the lock value - with the possibility of
indicating cpu_id.
Something like:
tcsr-mutex {
compatible = "qcom,tcsr-mutex";
syscon = <&tcsr_mutex_block 0 0x80>;
#hwlock-cells = <1>;
#address-cells = <1>;
#size-cells = <0>;
smem-lock@3 {
reg = <3>;
qcom,lock-value = <1>;
};
scm-lock@7 {
reg = <7>;
qcom,lock-value-from-cpu-id;
qcom,lock-raw;
};
};
As we don't reference most of these locks anyways I don't think this
would still be reasonable. And if reg is an array it's quite compact.
> Declare lock #7 as raw capable, so the hwspinlock framework would not
> enfore acquiring a s/w spinlock before acquiring the hwspinlock.
>
I'm fine with this part!
Sorry for the extremely slow response, but this took some time to
process...
Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
