Re: [PATCH v2 2/5] spi: imx: mx51-ecspi: Move some initialisation to prepare_message hook.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello Robin,

On Thu, Nov 29, 2018 at 12:53:33PM +0000, Robin Gong wrote:
> > -----Original Message-----
> > From: Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx>
> > Sent: 2018年11月26日 17:18
> > To: Robin Gong <yibin.gong@xxxxxxx>
> > Cc: Mark Brown <broonie@xxxxxxxxxx>; Marek Vasut <marex@xxxxxxx>;
> > dl-linux-imx <linux-imx@xxxxxxx>; kernel@xxxxxxxxxxxxxx;
> > linux-spi@xxxxxxxxxxxxxxx
> > Subject: Re: [PATCH v2 2/5] spi: imx: mx51-ecspi: Move some initialisation to
> > prepare_message hook.
> > 
> > Hello Robin,
> > 
> > On Mon, Nov 26, 2018 at 09:05:53AM +0000, Robin Gong wrote:
> > > > -----Original Message-----
> > > > From: Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx>
> > > > Sent: 2018年11月23日 16:52
> > > > To: Mark Brown <broonie@xxxxxxxxxx>; Robin Gong
> > <yibin.gong@xxxxxxx>
> > > > Cc: Marek Vasut <marex@xxxxxxx>; dl-linux-imx <linux-imx@xxxxxxx>;
> > > > kernel@xxxxxxxxxxxxxx; linux-spi@xxxxxxxxxxxxxxx
> > > > Subject: [PATCH v2 2/5] spi: imx: mx51-ecspi: Move some
> > > > initialisation to prepare_message hook.
> > > >
> > > > The relevant difference between prepare_message and config is that
> > > > the former is run before the CS signal is asserted. So the polarity
> > > > of the CLK line must be configured in prepare_message as an edge
> > > > generated by config might already result in a latch of the MOSI line.
> > > Is this a real problem fix patch or just refine in theory? I have
> > > quick test and saw a big performance downgrade below on i.mx6sl-evk
> > > board(1.6MB/s->706KB/s)
> > 
> > This is a real problem. If you have two spi devices on the bus with need modes
> > with different CPOL it can happen that after a transfer on one CPOL is changed
> > for the other while SS is already active and this is already interpreted as the
> > first latch.
> > 
> > > root@imx6qpdlsolox:~# dd if=/dev/mtd0 of=/dev/null bs=1M count=1
> > > 1+0 records in
> > > 1+0 records out
> > > 1048576 bytes (1.0 MB, 1.0 MiB) copied, 1.48557 s, 706 kB/s
> > 
> > I didn't test this, but I'm surprised about that. For single-transfer messages the
> > effect should just be that with the patch the following
> > happens:
> > 
> > 	setup_spi_imx_registers()
> > 	activate_gpio_for_SS()
> > 
> > instead of
> > 
> > 	activate_gpio_for_SS()
> > 	setup_spi_imx_registers()
> Yes, in theory your patch should not cause such performance issue since you just
> move some jobs of spi configure ahead of activate_gpio_for_SS(). But unfortunately,
> MX51_ECSPI_CTRL_BL_OFFSET may be broken by PIO transfer in case some small data,
> such as small command send to SPI-NOR before 1M data reading.
> Please refer to dynamic_burst related code of spi_imx_push(). If I keep BL setting in 
> mx51_ecspi_prepare_transfer() instead of mx51_ecspi_prepare_message(), the issue
> is gone. Below is my fix, please merge it in V3.
> 
> diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
> index 32d1c4f..05f9e50 100644
> --- a/drivers/spi/spi-imx.c
> +++ b/drivers/spi/spi-imx.c
> @@ -510,13 +510,6 @@ static int mx51_ecspi_prepare_message(struct spi_imx_data *spi_imx,
>         /* set chip select to use */
>         ctrl |= MX51_ECSPI_CTRL_CS(spi->chip_select);
> 
> -       if (spi_imx->slave_mode && is_imx53_ecspi(spi_imx))
> -               ctrl |= (spi_imx->slave_burst * 8 - 1)
> -                       << MX51_ECSPI_CTRL_BL_OFFSET;
> -       else
> -               ctrl |= (spi_imx->bits_per_word - 1)
> -                       << MX51_ECSPI_CTRL_BL_OFFSET;
> -
>         /*
>          * The ctrl register must be written first, with the EN bit set other
>          * registers must not be written to.
> @@ -570,6 +563,15 @@ static int mx51_ecspi_prepare_transfer(struct spi_imx_data *spi_imx,
>         u32 ctrl = readl(spi_imx->base + MX51_ECSPI_CTRL);
>         u32 clk = t->speed_hz, delay;
> 
> +       /* Clear BL filed and set the right value */
> +       ctrl &= ~MX51_ECSPI_CTRL_BL_MASK;
> +       if (spi_imx->slave_mode && is_imx53_ecspi(spi_imx))
> +               ctrl |= (spi_imx->slave_burst * 8 - 1)
> +                       << MX51_ECSPI_CTRL_BL_OFFSET;
> +       else
> +               ctrl |= (spi_imx->bits_per_word - 1)
> +                       << MX51_ECSPI_CTRL_BL_OFFSET;
> +

Even if I sent out v3 now, I wonder if the problem is just that I didn't
clear MX51_ECSPI_CTRL_BL_MASK in mx51_ecspi_prepare_message()?

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |



[Index of Archives]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux