> -----Original Message-----
> From: Mark Brown <broonie@xxxxxxxxxx>
> Sent: Thursday, April 8, 2021 21:44
> To: Clark Wang <xiaoning.wang@xxxxxxx>
> Cc: shawnguo@xxxxxxxxxx; s.hauer@xxxxxxxxxxxxxx; festevam@xxxxxxxxx;
> kernel@xxxxxxxxxxxxxx; dl-linux-imx <linux-imx@xxxxxxx>; linux-
> spi@xxxxxxxxxxxxxxx; linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; linux-
> kernel@xxxxxxxxxxxxxxx
> Subject: [EXT] Re: [PATCH] spi: imx: add a check for speed_hz before
calculating
> the clock
>
> On Thu, Apr 08, 2021 at 06:33:47PM +0800, Clark Wang wrote:
> > When some drivers use spi to send data, spi_transfer->speed_hz is not
> > assigned. If spidev->max_speed_hz is not assigned as well, it will
> > cause an error in configuring the clock.
>
> > Add a check for these two values before configuring the clock. An
> > error will be returned when they are not assigned.
>
> For the case where the transfer speed is not set __spi_validate() will
take the
> controller's maximum speed so the controller should just be able to
> unconditionally use the transfer's speed. Your issue is therefore that
the
> controllers are sometimes not setting a maximum speed which this doesn't
seem
> to fix AFAICT? I'd expect the driver to be able to work one out based on
the
> input clock.
Hi Mark,
Yes, you are right. If the t->speed_hz is not provided, it will use
spi->max_speed_hz.
This patch is not needed.
The issue I met is that t->speed_hz is not provided in slave mode. But this
is normal in slave mode.
The problem is spi-imx should not config the clock divider in slave mode. I
will send a new patch to disable the clock configuration in slave mode
later.
However, I notice that you have applied this patch to the next branch?
Will you revert this patch?
I think you may want to apply this patch I sent before.
Author: Clark Wang <xiaoning.wang@xxxxxxx>
Date: Mon Dec 14 17:05:04 2020 +0800
spi: imx: add 16/32 bits per word support for slave mode
Enable 16/32 bits per word support for spi-imx slave mode.
It only support 8 bits per word in slave mode before.
Signed-off-by: Clark Wang <xiaoning.wang@xxxxxxx>
Reviewed-by: Haibo Chen <haibo.chen@xxxxxxx>
Thank you very much! :)
Best Regards,
Clark Wang
>
> > struct spi_imx_devtype_data {
> > void (*intctrl)(struct spi_imx_data *, int);
> > int (*prepare_message)(struct spi_imx_data *, struct spi_message *);
> > - int (*prepare_transfer)(struct spi_imx_data *, struct spi_device *,
> > - struct spi_transfer *);
> > + int (*prepare_transfer)(struct spi_imx_data *, struct spi_device *);
> > void (*trigger)(struct spi_imx_data *);
> > int (*rx_available)(struct spi_imx_data *);
> > void (*reset)(struct spi_imx_data *);
>
> This seems to be a fairly big and surprising refactoring for the described
change.
> It's quite hard to tie the change to the changelog.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
