From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 20E7BC77B6D for ; Wed, 29 Mar 2023 13:28:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230037AbjC2N2d (ORCPT ); Wed, 29 Mar 2023 09:28:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59650 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229938AbjC2N2a (ORCPT ); Wed, 29 Mar 2023 09:28:30 -0400 Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A91C71BC5 for ; Wed, 29 Mar 2023 06:28:28 -0700 (PDT) Received: by mail-pl1-x62c.google.com with SMTP id c18so14886760ple.11 for ; Wed, 29 Mar 2023 06:28:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1680096508; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=XO9PMGgyv7xlqOFpmdl/UFzdqhUbqRNV9CPyu+R+Ji0=; b=MkWqzUtq79Ugx9ENsPBsqoWiluHKABfzOBjJ3rgd5SE7hPKt4Wejem3mCOKuXnZMr+ ueYUNOslkFWoiYsDPro/Lmr25V9LIG8ow5WVqmVCgtE+d6C1Qdk72eLeUXQ7w238kBNM jNIF9ZbbM9yFoxEpDIOhA9FWzeAXHKEuO77YfPGvieWnBLsCfj4aJzza6mLjZY+Pq/yP eAJftMxXfxoioUbhVLqA+adr+/pjglEWBZeTotFLUra1MXptMxle96LHwVWHFR15fYdm b/QduyQ0jP36bZcXabmodoJOm17Rd+RJlAgZZLqsH176NE5Marmwz9jcVZywPnSeo/5q uo/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680096508; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=XO9PMGgyv7xlqOFpmdl/UFzdqhUbqRNV9CPyu+R+Ji0=; b=7kegmBuAccUOIhcrt1HaCM1Qdveyzdvnk+oN+njjU6/5pNAcigtoX9G0BUUa7+h4LY 74kZPc/zhwA01Sl1N/YCHtBE5HZsGocdyhtl1lYOImiySv9D3zcMuz6LnXuN4m7MHK3v RR9lONCtXfNuFuzgTgYUK9rqAFlI2qRNmXG0ZPzxuMsQQiVSG7+5jtfmAQukTFgD1B8U RhTuAIZmtk/kd+ARUoej2JJf7nP7Ib+j2r3ESWp9XIoERg4aG+vD2snz2b6LHjJK7W96 Ni/e/cO91R5XbO9RxzRhNCPTwTjSPm+oonQu0Bu81a5iYC8EOjPmTbeSR8uSXOgGtAf6 N/YA== X-Gm-Message-State: AAQBX9fNuYp3t9ymuuxn4w0RsD/3wFie/uwt4vWc8dKJva05cPvGAcqP 3cDif/Nyi7pkDsYQ5MPHuIzePw== X-Google-Smtp-Source: AKy350arSJgZHcU4mFfCt2qojdNxJymORNH3nNOpqEYXNeDYs2Yg68qaCVOOBIoZXOZOppAzYTujqQ== X-Received: by 2002:a17:90b:1b49:b0:23d:1fc0:dd20 with SMTP id nv9-20020a17090b1b4900b0023d1fc0dd20mr20241188pjb.17.1680096508109; Wed, 29 Mar 2023 06:28:28 -0700 (PDT) Received: from dragon (80.251.214.228.16clouds.com. [80.251.214.228]) by smtp.gmail.com with ESMTPSA id m3-20020a170902bb8300b0019a7d58e595sm22979348pls.143.2023.03.29.06.28.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Mar 2023 06:28:27 -0700 (PDT) Date: Wed, 29 Mar 2023 21:28:19 +0800 From: Shawn Guo To: Konrad Dybcio Cc: Andy Gross , Bjorn Andersson , Thomas Gleixner , Marc Zyngier , Rob Herring , Krzysztof Kozlowski , Marijn Suijten , linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org Subject: Re: [PATCH 2/2] irqchip: irq-qcom-mpm: Support passing a slice of SRAM as reg space Message-ID: <20230329132819.GA3590215@dragon> References: <20230328-topic-msgram_mpm-v1-0-1b788a5f5a33@linaro.org> <20230328-topic-msgram_mpm-v1-2-1b788a5f5a33@linaro.org> <20230329034958.GC3554086@dragon> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Wed, Mar 29, 2023 at 01:06:11PM +0200, Konrad Dybcio wrote: > > > On 29.03.2023 05:49, Shawn Guo wrote: > > On Tue, Mar 28, 2023 at 12:02:53PM +0200, Konrad Dybcio wrote: > >> The MPM hardware is accessible to us from the ARM CPUs through a shared > >> memory region (RPM MSG RAM) that's also concurrently accessed by other > >> kinds of cores on the system (like modem, ADSP etc.). Modeling this > >> relation in a (somewhat) sane manner in the device tree basically > >> requires us to either present the MPM as a child of said memory region > >> (which makes little sense, as a mapped memory carveout is not a bus), > >> define nodes which bleed their register spaces into one another, or > >> passing their slice of the MSG RAM through some kind of a property. > >> > >> Go with the third option and add a way to map a region passed through > >> the "qcom,rpm-msg-ram" property as our register space. > >> > >> The current way of using 'reg' is preserved for ABI reasons. > >> > >> Signed-off-by: Konrad Dybcio > >> --- > >> drivers/irqchip/irq-qcom-mpm.c | 30 +++++++++++++++++++++++++----- > >> 1 file changed, 25 insertions(+), 5 deletions(-) > >> > >> diff --git a/drivers/irqchip/irq-qcom-mpm.c b/drivers/irqchip/irq-qcom-mpm.c > >> index d30614661eea..6fe59f4deef4 100644 > >> --- a/drivers/irqchip/irq-qcom-mpm.c > >> +++ b/drivers/irqchip/irq-qcom-mpm.c > >> @@ -14,6 +14,7 @@ > >> #include > >> #include > >> #include > >> +#include > >> #include > >> #include > >> #include > >> @@ -322,8 +323,10 @@ static int qcom_mpm_init(struct device_node *np, struct device_node *parent) > >> struct device *dev = &pdev->dev; > >> struct irq_domain *parent_domain; > >> struct generic_pm_domain *genpd; > >> + struct device_node *msgram_np; > >> struct qcom_mpm_priv *priv; > >> unsigned int pin_cnt; > >> + struct resource res; > >> int i, irq; > >> int ret; > >> > >> @@ -374,9 +377,21 @@ static int qcom_mpm_init(struct device_node *np, struct device_node *parent) > >> > >> raw_spin_lock_init(&priv->lock); > >> > >> - priv->base = devm_platform_ioremap_resource(pdev, 0); > >> - if (IS_ERR(priv->base)) > >> - return PTR_ERR(priv->base); > >> + /* If we have a handle to an RPM message ram partition, use it. */ > >> + msgram_np = of_parse_phandle(np, "qcom,rpm-msg-ram", 0); > >> + if (msgram_np) { > >> + ret = of_address_to_resource(msgram_np, 0, &res); > >> + /* Don't use devm_ioremap_resource, as we're accessing a shared region. */ > >> + priv->base = ioremap(res.start, resource_size(&res)); > > > > Are you suggesting that other cores/drivers will also need to access > > the mpm slice below? > > > > apss_mpm: sram@1b8 { > > reg = <0x1b8 0x48>; > > }; > Yes, the RPM M3 core. Other slices may be accessed > by any core at any time. Hmm, let me reword my question. Other than irq-qcom-mpm, is there any other Linux drivers that also need to request this slice region? Otherwise, I do not understand why devm_ioremap_resource() cannot be used. Shawn