From patchwork Wed Mar 13 15:50:31 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Fabien DESSENNE X-Patchwork-Id: 1056122 Return-Path: X-Original-To: incoming-dt@patchwork.ozlabs.org Delivered-To: patchwork-incoming-dt@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=devicetree-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=st.com Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 44KGYl2b87z9sCJ for ; Thu, 14 Mar 2019 02:52:11 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726328AbfCMPvT (ORCPT ); Wed, 13 Mar 2019 11:51:19 -0400 Received: from mx08-00178001.pphosted.com ([91.207.212.93]:18511 "EHLO mx07-00178001.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725856AbfCMPvT (ORCPT ); Wed, 13 Mar 2019 11:51:19 -0400 Received: from pps.filterd (m0046660.ppops.net [127.0.0.1]) by mx08-00178001.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x2DFk4QD027588; Wed, 13 Mar 2019 16:51:02 +0100 Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by mx08-00178001.pphosted.com with ESMTP id 2r71mb959h-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 Mar 2019 16:51:02 +0100 Received: from zeta.dmz-eu.st.com (zeta.dmz-eu.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id DA69738; Wed, 13 Mar 2019 15:51:00 +0000 (GMT) Received: from Webmail-eu.st.com (Safex1hubcas23.st.com [10.75.90.46]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id A3DF853F0; Wed, 13 Mar 2019 15:51:00 +0000 (GMT) Received: from SAFEX1HUBCAS22.st.com (10.75.90.93) by SAFEX1HUBCAS23.st.com (10.75.90.46) with Microsoft SMTP Server (TLS) id 14.3.435.0; Wed, 13 Mar 2019 16:51:00 +0100 Received: from localhost (10.201.23.25) by Webmail-ga.st.com (10.75.90.48) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 13 Mar 2019 16:51:00 +0100 From: Fabien Dessenne To: Ohad Ben-Cohen , Bjorn Andersson , Rob Herring , Mark Rutland , Maxime Coquelin , Alexandre Torgue , Jonathan Corbet , , , , , , CC: Fabien Dessenne , Benjamin Gaignard Subject: [PATCH 0/6] hwspinlock: allow sharing of hwspinlocks Date: Wed, 13 Mar 2019 16:50:31 +0100 Message-ID: <1552492237-28810-1-git-send-email-fabien.dessenne@st.com> X-Mailer: git-send-email 2.7.4 MIME-Version: 1.0 X-Originating-IP: [10.201.23.25] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-13_09:, , signatures=0 Sender: devicetree-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org The current implementation does not allow two different devices to use a common hwspinlock. This patch set proposes to have, as an option, some hwspinlocks shared between several users. Below is an example that explain the need for this: exti: interrupt-controller@5000d000 { compatible = "st,stm32mp1-exti", "syscon"; interrupt-controller; #interrupt-cells = <2>; reg = <0x5000d000 0x400>; hwlocks = <&hsem 1>; }; The two drivers (stm32mp1-exti and syscon) refer to the same hwlock. With the current hwspinlock implementation, only the first driver succeeds in requesting (hwspin_lock_request_specific) the hwlock. The second request fails. The proposed approach does not modify the API, but extends the DT 'hwlocks' property with a second optional parameter (the first one identifies an hwlock) that specifies whether an hwlock is requested for exclusive usage (current behavior) or can be shared between several users. Examples: hwlocks = <&hsem 8>; Ref to hwlock #8 for exclusive usage hwlocks = <&hsem 8 0>; Ref to hwlock #8 for exclusive (0) usage hwlocks = <&hsem 8 1>; Ref to hwlock #8 for shared (1) usage As a constraint, the #hwlock-cells value must be 1 or 2. In the current implementation, this can have theorically any value but: - all of the exisiting drivers use the same value : 1. - the framework supports only one value : 1 (see implementation of of_hwspin_lock_simple_xlate()) Hence, it shall not be a problem to restrict this value to 1 or 2 since it won't break any driver. Fabien Dessenne (6): dt-bindings: hwlock: add support of shared locks hwspinlock: allow sharing of hwspinlocks dt-bindings: hwlock: update STM32 #hwlock-cells value ARM: dts: stm32: Add hwspinlock node for stm32mp157 SoC ARM: dts: stm32: Add hwlock for irqchip on stm32mp157 ARM: dts: stm32: hwlocks for GPIO for stm32mp157 .../devicetree/bindings/hwlock/hwlock.txt | 27 +++++-- .../bindings/hwlock/st,stm32-hwspinlock.txt | 6 +- Documentation/hwspinlock.txt | 10 ++- arch/arm/boot/dts/stm32mp157-pinctrl.dtsi | 2 + arch/arm/boot/dts/stm32mp157c.dtsi | 10 +++ drivers/hwspinlock/hwspinlock_core.c | 82 +++++++++++++++++----- drivers/hwspinlock/hwspinlock_internal.h | 2 + 7 files changed, 108 insertions(+), 31 deletions(-) Acked-by: Loic Pallardy