Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20190703190404.21136-1-daniel.baluta@nxp.com> <20190703190404.21136-3-daniel.baluta@nxp.com>
 <AM0PR04MB42114DD325C5DB2E06011A4A80C80@AM0PR04MB4211.eurprd04.prod.outlook.com>
In-Reply-To: <AM0PR04MB42114DD325C5DB2E06011A4A80C80@AM0PR04MB4211.eurprd04.prod.outlook.com>
From:   Daniel Baluta <daniel.baluta@gmail.com>
Date:   Thu, 18 Jul 2019 09:38:11 +0300
Message-ID: <CAEnQRZDrx9tAiE5OnOkudy4eVLxjvhpHYg=ipPn6qo1hTVw5Aw@mail.gmail.com>
Subject: Re: [PATCH 2/3] firmware: imx: scu-pd: Add mu_b side PD range
To:     Aisheng Dong <aisheng.dong@nxp.com>
Cc:     Daniel Baluta <daniel.baluta@nxp.com>,
        "shawnguo@kernel.org" <shawnguo@kernel.org>,
        "s.hauer@pengutronix.de" <s.hauer@pengutronix.de>,
        "kernel@pengutronix.de" <kernel@pengutronix.de>,
        "festevam@gmail.com" <festevam@gmail.com>,
        dl-linux-imx <linux-imx@nxp.com>,
        "ulf.hansson@linaro.org" <ulf.hansson@linaro.org>,
        "linux-arm-kernel@lists.infradead.org" 
        <linux-arm-kernel@lists.infradead.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "S.j. Wang" <shengjiu.wang@nxp.com>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, Jul 18, 2019 at 6:30 AM Aisheng Dong <aisheng.dong@nxp.com> wrote:
>
> > From: Daniel Baluta <daniel.baluta@nxp.com>
> > Sent: Thursday, July 4, 2019 3:04 AM
> > Subject: [PATCH 2/3] firmware: imx: scu-pd: Add mu_b side PD range
> >
> > LSIO subsystem contains 14 MU instances.
> >
> > 5 MUs to communicate between AP <-> SCU
> >   - side-A PD range managed by AP
> >   - side-B PD range managed by SCU
> >
> > 9 MUs to communicate between AP <-> M4
>
> The left 9MUs are general and can be used by all cores,
> e.g AP/M4/DSP.
> So below description is not correct.
>
Indeed. In the particular case of the DSP it is true.

I don't know exactly who will use MUs 5..12. I only
know that MU 13 is assigned to DSP and we prefer
to power up side-b from AP because powering up
from DSP would be a pain.

This means that DSP needs a way to communicate with SCU
so basically it needs another MU for that.

> >   - side-A PD range managed by AP
> >   - side-B PD range managed by AP
> >
> > Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
> > ---
> >  drivers/firmware/imx/scu-pd.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/firmware/imx/scu-pd.c b/drivers/firmware/imx/scu-pd.c
> > index 950d30238186..30adc3104347 100644
> > --- a/drivers/firmware/imx/scu-pd.c
> > +++ b/drivers/firmware/imx/scu-pd.c
> > @@ -93,6 +93,7 @@ static const struct imx_sc_pd_range
> > imx8qxp_scu_pd_ranges[] = {
> >       { "kpp", IMX_SC_R_KPP, 1, false, 0 },
> >       { "fspi", IMX_SC_R_FSPI_0, 2, true, 0 },
> >       { "mu_a", IMX_SC_R_MU_0A, 14, true, 0 },
> > +     { "mu_b", IMX_SC_R_MU_5B, 9, true, 0 },
>
> Should start from 5?
> { "mu_b", IMX_SC_R_MU_5B, 9, true, 5 },

I guess you are right. I think start_from is used
to form the pd name, because the actual rsrc
is computed as follows:

sc_pd->rsrc = pd_ranges->rsrc + idx;

So, I think for this reason it just worked for me.

Anyhow, I'm thinking about powering up only MU13_B from AP side
and let the user of other MU sides B to decide from themselves.

So, the change will be:

> > +     { "mu_b", IMX_SC_R_MU_13B, 1, true, 13 },

Will send v2 asap.