linux-gpio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Boyd <sboyd@kernel.org>
To: David Collins <quic_collinsd@quicinc.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	Vinod Koul <vkoul@kernel.org>
Cc: linux-arm-msm@vger.kernel.org,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	David Dai <daidavid1@codeaurora.org>,
	linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org,
	David Collins <quic_collinsd@quicinc.com>
Subject: Re: [PATCH] spmi: pmic-arb: Add support for PMIC v7
Date: Thu, 02 Dec 2021 19:13:21 -0800	[thread overview]
Message-ID: <20211203031323.211E5C00446@smtp.kernel.org> (raw)
In-Reply-To: <9161450a-40e0-c84f-f529-c903d6f1d722@quicinc.com>

Quoting David Collins (2021-12-02 15:51:18)
> On 12/2/21 3:06 PM, Stephen Boyd wrote:
> > Quoting Vinod Koul (2021-11-30 23:27:18)
> >> @@ -1169,8 +1270,12 @@ static int spmi_pmic_arb_probe(struct platform_device *pdev)
> >>         pmic_arb = spmi_controller_get_drvdata(ctrl);
> >>         pmic_arb->spmic = ctrl;
> >>  
> >> +       /*
> >> +        * Don't use devm_ioremap_resource() as the resources are shared in
> >> +        * PMIC v7 onwards, so causing failure when mapping
> >> +        */
> >>         res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "core");
> >> -       core = devm_ioremap_resource(&ctrl->dev, res);
> >> +       core = devm_ioremap(&ctrl->dev, res->start, resource_size(res));
> > 
> > What does this mean? We have two nodes in DT that have the same reg
> > properties? How does that work?
> 
> PMIC Arbiter v7 has two SPMI bus master interfaces.  These are used to
> communicate with two sets of PMICs.  The SPMI interfaces operate
> independently; however, they share some register address ranges (e.g.
> one common one is used for APID->PPID mapping).

It looks like the two SPMI busses share the mapping table which is OK
because it's read-only but then the 'chnls' and 'obsrvr' regions are
also shared. There must be some global lock in place to make sure the
two controllers aren't writing to the same register in there? Or are we
saved because the mapping table splits the regions between the two
busses?

> The most
> straightforward way to handle this is to treat them as two independent
> top-level DT devices.
> 
> In this case the "cnfg" address is used in the DT node name as that is
> unique between the two instances.

Nice trick. The reg properties aren't supposed to change order though so
we shouldn't do that.

> 
> Here are the DT nodes used downstream on a target with PMIC Arbiter v7:
> 
> spmi0_bus: qcom,spmi@c42d000 {
>         compatible = "qcom,spmi-pmic-arb";
>         reg = <0xc42d000 0x4000>,
>               <0xc400000 0x3000>,
>               <0xc500000 0x400000>,
>               <0xc440000 0x80000>,
>               <0xc4c0000 0x10000>;
>         reg-names = "cnfg", "core", "chnls", "obsrvr", "intr";
>         interrupts-extended = <&pdc 1 IRQ_TYPE_LEVEL_HIGH>;
>         interrupt-names = "periph_irq";
>         interrupt-controller;
>         #interrupt-cells = <4>;
>         #address-cells = <2>;
>         #size-cells = <0>;
>         cell-index = <0>;
>         qcom,channel = <0>;
>         qcom,ee = <0>;
>         qcom,bus-id = <0>;
> };
> 
> spmi1_bus: qcom,spmi@c432000 {
>         compatible = "qcom,spmi-pmic-arb";
>         reg = <0xc432000 0x4000>,
>               <0xc400000 0x3000>,
>               <0xc500000 0x400000>,
>               <0xc440000 0x80000>,
>               <0xc4d0000 0x10000>;
>         reg-names = "cnfg", "core", "chnls", "obsrvr", "intr";
>         interrupts-extended = <&pdc 3 IRQ_TYPE_LEVEL_HIGH>;
>         interrupt-names = "periph_irq";
>         interrupt-controller;
>         #interrupt-cells = <4>;
>         #address-cells = <2>;
>         #size-cells = <0>;
>         cell-index = <0>;
>         qcom,channel = <0>;
>         qcom,ee = <0>;
>         qcom,bus-id = <1>;
> };

It feels like we should make a parent node that holds the core, chnls,
obsrvr reg properties with a new compatible string and then have two
child nodes for each bus. Then the various PMICs can hang off those two
different bus nodes. Of course, it needs DT review to make sure nothing
else goes wrong.

> 
> Note the inclusion of a new DT property: "qcom,bus-id".  This was
> defined in a DT binding patch that isn't present in Vinod's submission.
> Here is its definition:
> 
> - qcom,bus-id : Specifies which SPMI bus instance to use.  This property
>                 is only applicable for PMIC arbiter version 7 and
>                 beyond.
>                 Support values: 0 = primary bus, 1 = secondary bus
>                 Assumed to be 0 if unspecified.
> 

How is it used in the driver? Does something care what is primary and
what is secondary?

  reply	other threads:[~2021-12-03  3:13 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-01  7:27 [PATCH] spmi: pmic-arb: Add support for PMIC v7 Vinod Koul
2021-12-02 23:06 ` Stephen Boyd
2021-12-02 23:51   ` David Collins
2021-12-03  3:13     ` Stephen Boyd [this message]
2021-12-04  0:45       ` David Collins
2021-12-07 11:52         ` Vinod Koul
2021-12-10  2:01           ` Stephen Boyd
2021-12-07 11:49     ` Vinod Koul
2021-12-02 23:09 ` Subbaraman Narayanamurthy
2021-12-07 11:47   ` Vinod Koul

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20211203031323.211E5C00446@smtp.kernel.org \
    --to=sboyd@kernel.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=daidavid1@codeaurora.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=quic_collinsd@quicinc.com \
    --cc=vkoul@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).