From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lina Iyer Subject: Re: [PATCH v6 2/2] hwspinlock: qcom: Add support for Qualcomm HW Mutex block Date: Thu, 12 Mar 2015 13:55:27 -0600 Message-ID: <20150312195527.GC497@linaro.org> References: <1425076217-10415-1-git-send-email-bjorn.andersson@sonymobile.com> <1425076217-10415-2-git-send-email-bjorn.andersson@sonymobile.com> <20150312193150.GB497@linaro.org> <20150312194325.GB31345@qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Return-path: Received: from mail-pd0-f174.google.com ([209.85.192.174]:46972 "EHLO mail-pd0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754092AbbCLTza (ORCPT ); Thu, 12 Mar 2015 15:55:30 -0400 Received: by pdev10 with SMTP id v10so22542395pde.13 for ; Thu, 12 Mar 2015 12:55:30 -0700 (PDT) Content-Disposition: inline In-Reply-To: <20150312194325.GB31345@qualcomm.com> Sender: linux-arm-msm-owner@vger.kernel.org List-Id: linux-arm-msm@vger.kernel.org To: Andy Gross Cc: Bjorn Andersson , Ohad Ben-Cohen , linux-arm-msm@vger.kernel.org, Jeffrey Hugo , Suman Anna , linux-kernel@vger.kernel.org On Thu, Mar 12 2015 at 13:43 -0600, Andy Gross wrote: >On Thu, Mar 12, 2015 at 01:31:50PM -0600, 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 >> > >> >Signed-off-by: Bjorn Andersson >> >--- >> > >> >> [...] >> >> >+#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. > >So this was the lock_rlock_id API? > Correct. >> >> 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. >> >> >+#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. > >Out of curiosity, this is a TZ thing? If so, we'd expect issues if someone >decides to utilize resources that, while technically are present, are unusable >by that processor. This is not that much different from someone misconfiguring >an EE on a DMA controller. > Per Jeff, the protection unit doesnt generally allow access to locks > 8 and shouldnt be allowed and in some SoC's where they dont have the protection, it might still be a bad idea. It would be safer to restrict to 8, than allow all 32 and hope somebody doesnt do the wrong thing. >> >+{ >> >+ struct regmap_field *field = lock->priv; >> >+ u32 lock_owner; >> >+ int ret; >> >+ >> >+ ret = regmap_field_write(field, QCOM_MUTEX_APPS_PROC_ID); >> >+ if (ret) >> >+ return ret; >> >+ >> >+ ret = regmap_field_read(field, &lock_owner); >> >+ if (ret) >> >+ return ret; >> >+ >> >+ return lock_owner == QCOM_MUTEX_APPS_PROC_ID; >> >+} >> >+ >> > >-- >Qualcomm Innovation Center, Inc. >The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, >a Linux Foundation Collaborative Project >