[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<DU0PR04MB94173EEDEE5896D6B9C549F788742@DU0PR04MB9417.eurprd04.prod.outlook.com>
Date: Tue, 23 Jan 2024 07:13:36 +0000
From: Peng Fan <peng.fan@....com>
To: Sascha Hauer <s.hauer@...gutronix.de>
CC: "Peng Fan (OSS)" <peng.fan@....nxp.com>, Jassi Brar
<jassisinghbrar@...il.com>, Rob Herring <robh+dt@...nel.org>, Krzysztof
Kozlowski <krzysztof.kozlowski+dt@...aro.org>, Conor Dooley
<conor+dt@...nel.org>, Aisheng Dong <aisheng.dong@....com>, Shawn Guo
<shawnguo@...nel.org>, Pengutronix Kernel Team <kernel@...gutronix.de>, Fabio
Estevam <festevam@...il.com>, dl-linux-imx <linux-imx@....com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>
Subject: RE: [PATCH v2 2/3] mailbox: imx: get RR/TR registers num from
Parameter register
> Subject: Re: [PATCH v2 2/3] mailbox: imx: get RR/TR registers num from
> Parameter register
>
> On Tue, Jan 23, 2024 at 01:42:03AM +0000, Peng Fan wrote:
> > Hi Sascha,
> >
> > > Subject: Re: [PATCH v2 2/3] mailbox: imx: get RR/TR registers num
> > > from Parameter register
> > >
> > > Hi Peng,
> >
> > [snip]
> > >
> > > > };
> > > >
> > > > enum imx_mu_type {
> > > > @@ -264,18 +267,17 @@ static int imx_mu_generic_rxdb(struct
> > > > imx_mu_priv *priv, static int imx_mu_specific_tx(struct
> > > > imx_mu_priv *priv, struct imx_mu_con_priv *cp, void *data) {
> > > > u32 *arg = data;
> > > > + u32 num_tr = priv->num_tr;
> > > > int i, ret;
> > > > u32 xsr;
> > > > - u32 size, max_size, num_tr;
> > > > + u32 size, max_size;
> > > >
> > > > if (priv->dcfg->type & IMX_MU_V2_S4) {
> > > > size = ((struct imx_s4_rpc_msg_max *)data)->hdr.size;
> > > > max_size = sizeof(struct imx_s4_rpc_msg_max);
> > > > - num_tr = 8;
> > >
> > > This change looks unexpected here. num_tr used to be 8 here and now
> > > becomes 4 at maximum. Was this a bug? If yes, this deserves a
> > > separate patch with an explanation what was wrong here.
> >
> > Sorry, I could not follow you here.
> > The num_tr is switch to use priv->num_tr now. It is not changed to 4
> > at maximum, it is just use priv->num_tr to avoid hardcoding it to 8.
> > As of now, all platforms has IMX_MU_V2_S4 are using 8, and the
> > hardware register num is 8, except i.MX95 V2X MU using 4.
>
> I was confused by the warning you introduced:
>
> > > > + if (priv->num_rr > 4 || priv->num_tr > 4) {
> > > > + WARN_ONCE(true, "%s not support TR/RR larger than
> > > > + 4\n",
> > > __func__);
> > > > + return;
> > > > + }
>
> It will trigger when priv->num_tr is read as 8, so I assumed it is 4 at maximum.
> Indeed just the check is wrong and you might haven't notice the warning
> during testing.
For now, we not have platform use generic MU with TR/RR larger than 4, so
just give a warning. I could follow your suggestion to return error in V2.
The reason for not supporting 8 here is it would introduce too much change,
because of more channel numbers. So I leave it for future when there
is real need.
Thanks,
Peng.
>
> Sascha
>
> --
> Pengutronix e.K. | |
> Steuerwalder Str. 21 |
> http://www.p/
> engutronix.de%2F&data=05%7C02%7Cpeng.fan%40nxp.com%7Cc0a6c1b5cd
> 1d4c37940708dc1be25585%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0
> %7C0%7C638415906104836756%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C30
> 00%7C%7C%7C&sdata=yIw7NjXMamXh2IQNfLFU4EBblgYlRz1rYyh4nsSpHww
> %3D&reserved=0 |
> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
Powered by blists - more mailing lists