Re: [PATCH v6 2/2] hwspinlock: qcom: Add support for Qualcomm HW Mutex block

[Bjorn Andersson]

On Thu 12 Mar 12:31 PDT 2015, Lina Iyer wrote:

> On Fri, Feb 27 2015 at 15:30 -0700, Bjorn Andersson wrote:
> >Add driver for Qualcomm Hardware Mutex block found in many Qualcomm
> >SoCs.
> >
> >Based on initial effort by Kumar Gala <galak@xxxxxxxxxxxxxx>
> >
> >Signed-off-by: Bjorn Andersson <bjorn.andersson@xxxxxxxxxxxxxx>
> >---
> >
> 
> [...]
> 
> >+#include "hwspinlock_internal.h"
> >+
> >+#define QCOM_MUTEX_APPS_PROC_ID	1
> Hi Bjorn,
> 
> Not all locks use 1 to indicate its locked. For example lock index 7 is
> used by cpuidle driver between HLOS and SCM. It uses a write value of
> (128 + smp_processor_id()) to lock.
> 

In other words, it's a magic number that will make sure that not more
than one cpu enters TZ sleep code at a time.

> A cpu acquires the remote spin lock, and calls into SCM to terminate the
> power down sequence while passing the state of the L2. The lock help
> guarantee the last core to hold the spinlock to have the most up to date
> value for the L2 flush flag.
> 

Yeah, I remember having to dig out the deadlock related to the
introduction of that logic on my side (turned out to have an old TZ).

There's already mutual exclusion and reference counting within TZ to
make sure we're not turning off the caches unless this is the last core
going down.
I presume that the reason behind the hwmutex logic is to make sure that
with multiple cores racing to sleep only one of them will flush the
caches in Linux and will be the last entering TZ. Can you confirm this?

> >+#define QCOM_MUTEX_NUM_LOCKS	32
> 
> Also, talking to Jeff it seems like that out of the 32 locks defined
> only 8 is accessible from Linux. So its unnecessary and probably
> incorrect to assume that there are 32 locks available.
> 

The hardware block have 32 locks and the decision regarding which locks
this particular Linux system is allowed to access is configuration.

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/