lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <VE1PR04MB6688E4BEA6B45A40C46DDEC689149@VE1PR04MB6688.eurprd04.prod.outlook.com>
Date:   Tue, 13 Jul 2021 09:14:42 +0000
From:   Robin Gong <yibin.gong@....com>
To:     Lucas Stach <l.stach@...gutronix.de>,
        "vkoul@...nel.org" <vkoul@...nel.org>,
        "mark.rutland@....com" <mark.rutland@....com>,
        "broonie@...nel.org" <broonie@...nel.org>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "catalin.marinas@....com" <catalin.marinas@....com>,
        "will.deacon@....com" <will.deacon@....com>,
        "shawnguo@...nel.org" <shawnguo@...nel.org>,
        "festevam@...il.com" <festevam@...il.com>,
        "s.hauer@...gutronix.de" <s.hauer@...gutronix.de>,
        "martin.fuzzey@...wbird.group" <martin.fuzzey@...wbird.group>,
        "u.kleine-koenig@...gutronix.de" <u.kleine-koenig@...gutronix.de>,
        "dan.j.williams@...el.com" <dan.j.williams@...el.com>,
        "matthias.schiffer@...tq-group.com" 
        <matthias.schiffer@...tq-group.com>,
        "frieder.schrempf@...tron.de" <frieder.schrempf@...tron.de>,
        "m.felsch@...gutronix.de" <m.felsch@...gutronix.de>,
        Clark Wang <xiaoning.wang@....com>
CC:     "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-spi@...r.kernel.org" <linux-spi@...r.kernel.org>,
        dl-linux-imx <linux-imx@....com>,
        "kernel@...gutronix.de" <kernel@...gutronix.de>,
        "dmaengine@...r.kernel.org" <dmaengine@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: RE: [PATCH v14 09/12] dmaengine: imx-sdma: remove ERR009165 on
 i.mx6ul

On 12/07/21 17:33 Lucas Stach <l.stach@...gutronix.de> wrote:
> Am Montag, dem 12.07.2021 um 04:03 +0000 schrieb Robin Gong:
> > On 09/07/21 17:45 Lucas Stach <l.stach@...gutronix.de> wrote:
> > > Am Mittwoch, dem 07.04.2021 um 23:30 +0800 schrieb Robin Gong:
> > > > ECSPI issue fixed from i.mx6ul at hardware level, no need
> > > > ERR009165 anymore on those chips such as i.mx8mq.
> > > >
> > > > Signed-off-by: Robin Gong <yibin.gong@....com>
> > > > Acked-by: Vinod Koul <vkoul@...nel.org>
> > > > ---
> > > >  drivers/dma/imx-sdma.c | 26 +++++++++++++++++++++++++-
> > > >  1 file changed, 25 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c index
> > > > 86bd383..af85116 100644
> > > > --- a/drivers/dma/imx-sdma.c
> > > > +++ b/drivers/dma/imx-sdma.c
> > > > @@ -422,6 +422,13 @@ struct sdma_driver_data {
> > > >  	int num_events;
> > > >  	struct sdma_script_start_addrs	*script_addrs;
> > > >  	bool check_ratio;
> > > > +	/*
> > > > +	 * ecspi ERR009165 fixed should be done in sdma script
> > > > +	 * and it has been fixed in soc from i.mx6ul.
> > > > +	 * please get more information from the below link:
> > > > +	 *
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> > > w.n
> xp.com%2Fdocs%2Fen%2Ferrata%2FIMX6DQCE.pdf&amp;data=04%7C01%7C
> > >
> yibin.gong%40nxp.com%7Cc950b1bdb6544eda369408d942be35d9%7C686ea
> > >
> 1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637614206980361737%7CU
> > >
> nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6
> > >
> Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=6iT6%2FbzJHyWnkhkDynY
> > > wmK9nn2hgCDy1GyzELeEk9K8%3D&amp;reserved=0
> > > > +	 */
> > > > +	bool ecspi_fixed;
> > > >  };
> > > >
> > > >  struct sdma_engine {
> > > > @@ -542,6 +549,13 @@ static struct sdma_driver_data sdma_imx6q = {
> > > >  	.script_addrs = &sdma_script_imx6q,  };
> > > >
> > > > +static struct sdma_driver_data sdma_imx6ul = {
> > > > +	.chnenbl0 = SDMA_CHNENBL0_IMX35,
> > > > +	.num_events = 48,
> > > > +	.script_addrs = &sdma_script_imx6q,
> > > > +	.ecspi_fixed = true,
> > > > +};
> > > > +
> > > >  static struct sdma_script_start_addrs sdma_script_imx7d = {
> > > >  	.ap_2_ap_addr = 644,
> > > >  	.uart_2_mcu_addr = 819,
> > > > @@ -575,6 +589,7 @@ static const struct of_device_id sdma_dt_ids[] = {
> > > >  	{ .compatible = "fsl,imx31-sdma", .data = &sdma_imx31, },
> > > >  	{ .compatible = "fsl,imx25-sdma", .data = &sdma_imx25, },
> > > >  	{ .compatible = "fsl,imx7d-sdma", .data = &sdma_imx7d, },
> > > > +	{ .compatible = "fsl,imx6ul-sdma", .data = &sdma_imx6ul, },
> > > >  	{ .compatible = "fsl,imx8mq-sdma", .data = &sdma_imx8mq, },
> > > >  	{ /* sentinel */ }
> > > >  };
> > > > @@ -1144,8 +1159,17 @@ static int sdma_config_channel(struct
> > > > dma_chan
> > > *chan)
> > > >  			if (sdmac->peripheral_type == IMX_DMATYPE_ASRC_SP ||
> > > >  			    sdmac->peripheral_type == IMX_DMATYPE_ASRC)
> > > >  				sdma_set_watermarklevel_for_p2p(sdmac);
> > > > -		} else
> > > > +		} else {
> > > > +			/*
> > > > +			 * ERR009165 fixed from i.mx6ul, no errata need,
> > > > +			 * set bit31 to let sdma script skip the errata.
> > > > +			 */
> > > > +			if (sdmac->peripheral_type == IMX_DMATYPE_CSPI &&
> > > > +			    sdmac->direction == DMA_MEM_TO_DEV &&
> > > > +			    sdmac->sdma->drvdata->ecspi_fixed)
> > > > +				__set_bit(31, &sdmac->watermark_level);
> > >
> > > Hm, I don't care much either way, but couldn't we just return the
> > > regular mcu_2_app script in sdma_get_pc when ecspi_fixed == true?
> > > Seems like this would be a simpler and more targeted code change.
> > Yes, return mcu_2_app if ecspi_fixed == true also works, but since
> > sdma firmware have already been here to fix ERR009165 on most of
> > legacy i.mx6/7/8 chips, so choosing firmware/ram script to do like
> > ROM/mcu_2_app is okay too since both ram script and rom script in case of
> ecspi_fixed are almost same.
> >
> Actually, while thinking some more about this: it is preferable to return
> mcu_2_app in the ecspi_fixed case, as this allows proper DMA support on the
> fixed SoCs without loading the firmware. The way you do it here still requires
> the RAM firmware to be loaded in order to get DMA support at all.
Okay, will change to mcu_2_app v15.

> 
> 
> > >
> > > >  			__set_bit(sdmac->event_id0, sdmac->event_mask);
> > > > +		}
> > > >
> > > >  		/* Address */
> > > >  		sdmac->shp_addr = sdmac->per_address;
> > >
> >
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ