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 <[email protected]>
Reviewed-by: Haibo Chen <[email protected]>
---
drivers/spi/spi-imx.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 4fe767acaca7..24ba7ab1b05d 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -386,7 +386,12 @@ static void spi_imx_buf_tx_swap(struct spi_imx_data *spi_imx)
static void mx53_ecspi_rx_slave(struct spi_imx_data *spi_imx)
{
- u32 val = be32_to_cpu(readl(spi_imx->base + MXC_CSPIRXDATA));
+ u32 val = readl(spi_imx->base + MXC_CSPIRXDATA);
+
+ if (spi_imx->bits_per_word <= 8)
+ val = be32_to_cpu(val);
+ else if (spi_imx->bits_per_word <= 16)
+ val = (val << 16) | (val >> 16);
if (spi_imx->rx_buf) {
int n_bytes = spi_imx->slave_burst % sizeof(val);
@@ -415,7 +420,11 @@ static void mx53_ecspi_tx_slave(struct spi_imx_data *spi_imx)
if (spi_imx->tx_buf) {
memcpy(((u8 *)&val) + sizeof(val) - n_bytes,
spi_imx->tx_buf, n_bytes);
- val = cpu_to_be32(val);
+ if (spi_imx->bits_per_word <= 8)
+ val = cpu_to_be32(val);
+ else if (spi_imx->bits_per_word <= 16)
+ val = (val << 16) | (val >> 16);
+
spi_imx->tx_buf += n_bytes;
}
--
2.25.1
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.
Signed-off-by: Clark Wang <[email protected]>
---
drivers/spi/spi-imx.c | 37 +++++++++++++++++++++----------------
1 file changed, 21 insertions(+), 16 deletions(-)
diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 24ba7ab1b05d..01f27b4d7384 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -66,8 +66,7 @@ struct spi_imx_data;
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 *);
@@ -581,11 +580,10 @@ static int mx51_ecspi_prepare_message(struct spi_imx_data *spi_imx,
}
static int mx51_ecspi_prepare_transfer(struct spi_imx_data *spi_imx,
- struct spi_device *spi,
- struct spi_transfer *t)
+ struct spi_device *spi)
{
u32 ctrl = readl(spi_imx->base + MX51_ECSPI_CTRL);
- u32 clk = t->speed_hz, delay;
+ u32 clk, delay;
/* Clear BL field and set the right value */
ctrl &= ~MX51_ECSPI_CTRL_BL_MASK;
@@ -599,7 +597,7 @@ static int mx51_ecspi_prepare_transfer(struct spi_imx_data *spi_imx,
/* set clock speed */
ctrl &= ~(0xf << MX51_ECSPI_CTRL_POSTDIV_OFFSET |
0xf << MX51_ECSPI_CTRL_PREDIV_OFFSET);
- ctrl |= mx51_ecspi_clkdiv(spi_imx, t->speed_hz, &clk);
+ ctrl |= mx51_ecspi_clkdiv(spi_imx, spi_imx->spi_bus_clk, &clk);
spi_imx->spi_bus_clk = clk;
if (spi_imx->usedma)
@@ -711,13 +709,12 @@ static int mx31_prepare_message(struct spi_imx_data *spi_imx,
}
static int mx31_prepare_transfer(struct spi_imx_data *spi_imx,
- struct spi_device *spi,
- struct spi_transfer *t)
+ struct spi_device *spi)
{
unsigned int reg = MX31_CSPICTRL_ENABLE | MX31_CSPICTRL_MASTER;
unsigned int clk;
- reg |= spi_imx_clkdiv_2(spi_imx->spi_clk, t->speed_hz, &clk) <<
+ reg |= spi_imx_clkdiv_2(spi_imx->spi_clk, spi_imx->spi_bus_clk, &clk) <<
MX31_CSPICTRL_DR_SHIFT;
spi_imx->spi_bus_clk = clk;
@@ -816,14 +813,13 @@ static int mx21_prepare_message(struct spi_imx_data *spi_imx,
}
static int mx21_prepare_transfer(struct spi_imx_data *spi_imx,
- struct spi_device *spi,
- struct spi_transfer *t)
+ struct spi_device *spi)
{
unsigned int reg = MX21_CSPICTRL_ENABLE | MX21_CSPICTRL_MASTER;
unsigned int max = is_imx27_cspi(spi_imx) ? 16 : 18;
unsigned int clk;
- reg |= spi_imx_clkdiv_1(spi_imx->spi_clk, t->speed_hz, max, &clk)
+ reg |= spi_imx_clkdiv_1(spi_imx->spi_clk, spi_imx->spi_bus_clk, max, &clk)
<< MX21_CSPICTRL_DR_SHIFT;
spi_imx->spi_bus_clk = clk;
@@ -892,13 +888,12 @@ static int mx1_prepare_message(struct spi_imx_data *spi_imx,
}
static int mx1_prepare_transfer(struct spi_imx_data *spi_imx,
- struct spi_device *spi,
- struct spi_transfer *t)
+ struct spi_device *spi)
{
unsigned int reg = MX1_CSPICTRL_ENABLE | MX1_CSPICTRL_MASTER;
unsigned int clk;
- reg |= spi_imx_clkdiv_2(spi_imx->spi_clk, t->speed_hz, &clk) <<
+ reg |= spi_imx_clkdiv_2(spi_imx->spi_clk, spi_imx->spi_bus_clk, &clk) <<
MX1_CSPICTRL_DR_SHIFT;
spi_imx->spi_bus_clk = clk;
@@ -1177,6 +1172,16 @@ static int spi_imx_setupxfer(struct spi_device *spi,
if (!t)
return 0;
+ if (!t->speed_hz) {
+ if (!spi->max_speed_hz) {
+ dev_err(&spi->dev, "no speed_hz provided!\n");
+ return -EINVAL;
+ }
+ dev_dbg(&spi->dev, "using spi->max_speed_hz!\n");
+ spi_imx->spi_bus_clk = spi->max_speed_hz;
+ } else
+ spi_imx->spi_bus_clk = t->speed_hz;
+
spi_imx->bits_per_word = t->bits_per_word;
/*
@@ -1218,7 +1223,7 @@ static int spi_imx_setupxfer(struct spi_device *spi,
spi_imx->slave_burst = t->len;
}
- spi_imx->devtype_data->prepare_transfer(spi_imx, spi, t);
+ spi_imx->devtype_data->prepare_transfer(spi_imx, spi);
return 0;
}
--
2.25.1
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.
> 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.
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.
Please don't send new patches in reply to other threads, this makes it
harder to follow what current versions of things are and causes problems
for tools.
On Thu, 8 Apr 2021 18:33:47 +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.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
Thanks!
[1/1] spi: imx: add a check for speed_hz before calculating the clock
commit: 4df2f5e1372e9eec8f9e1b4a3025b9be23487d36
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
> -----Original Message-----
> From: Mark Brown <[email protected]>
> Sent: Thursday, April 8, 2021 21:44
> To: Clark Wang <[email protected]>
> Cc: [email protected]; [email protected]; [email protected];
> [email protected]; dl-linux-imx <[email protected]>; linux-
> [email protected]; [email protected]; linux-
> [email protected]
> 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 <[email protected]>
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 <[email protected]>
Reviewed-by: Haibo Chen <[email protected]>
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.
On Tue, Apr 27, 2021 at 08:33:06AM +0000, Clark Wang wrote:
> However, I notice that you have applied this patch to the next branch?
> Will you revert this patch?
Well, it's redundant but not harmful.
> I think you may want to apply this patch I sent before.
>
> Author: Clark Wang <[email protected]>
> 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.
Please don't send content free pings and please allow a reasonable time
for review. People get busy, go on holiday, attend conferences and so
on so unless there is some reason for urgency (like critical bug fixes)
please allow at least a couple of weeks for review. If there have been
review comments then people may be waiting for those to be addressed.
Sending content free pings adds to the mail volume (if they are seen at
all) which is often the problem and since they can't be reviewed
directly if something has gone wrong you'll have to resend the patches
anyway, so sending again is generally a better approach though there are
some other maintainers who like them - if in doubt look at how patches
for the subsystem are normally handled.
On Tue, Apr 27, 2021 at 08:33:06AM +0000, Clark Wang wrote:
> 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 <[email protected]>
> Date: Mon Dec 14 17:05:04 2020 +0800
>
> spi: imx: add 16/32 bits per word support for slave mode
Oh, in this case what happened is that you sent your speed_hz patch as a
reply to this patch so the speed_hz patch looked like a replacement for
it which confused both me and the tooling.
> -----Original Message-----
> From: Mark Brown <[email protected]>
> Sent: Tuesday, April 27, 2021 19:19
> To: Clark Wang <[email protected]>
> Cc: [email protected]; [email protected]; [email protected];
> [email protected]; dl-linux-imx <[email protected]>; linux-
> [email protected]; [email protected]; linux-
> [email protected]
> Subject: [EXT] Re: Re: [PATCH] spi: imx: add a check for speed_hz before
> calculating the clock
>
> On Tue, Apr 27, 2021 at 08:33:06AM +0000, Clark Wang wrote:
>
> > 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 <[email protected]>
> > Date: Mon Dec 14 17:05:04 2020 +0800
> >
> > spi: imx: add 16/32 bits per word support for slave mode
>
> Oh, in this case what happened is that you sent your speed_hz patch as a
> reply to this patch so the speed_hz patch looked like a replacement for it
> which confused both me and the tooling.
I'm sorry to cause you confusion.
1) spi: imx: add 16/32 bits per word support for slave mode and B
2) spi: imx: add a check for speed_hz before calculating the clock
These two patch above are two independent patches.
Now 2) is no longer needed, I just sent 3) to fix the real problem.
3) spi: imx: remove CLK calculation and divider in slave mode
Thank you very much!
Best Regards,
Clark Wang
Hi,
On 4/8/21 1:33 PM, Clark Wang wrote:
> 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 <[email protected]>
> Reviewed-by: Haibo Chen <[email protected]>
> ---
> drivers/spi/spi-imx.c | 13 +++++++++++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
> index 4fe767acaca7..24ba7ab1b05d 100644
> --- a/drivers/spi/spi-imx.c
> +++ b/drivers/spi/spi-imx.c
> @@ -386,7 +386,12 @@ static void spi_imx_buf_tx_swap(struct spi_imx_data *spi_imx)
>
> static void mx53_ecspi_rx_slave(struct spi_imx_data *spi_imx)
> {
> - u32 val = be32_to_cpu(readl(spi_imx->base + MXC_CSPIRXDATA));
> + u32 val = readl(spi_imx->base + MXC_CSPIRXDATA);
> +
> + if (spi_imx->bits_per_word <= 8)
> + val = be32_to_cpu(val);
> + else if (spi_imx->bits_per_word <= 16)
> + val = (val << 16) | (val >> 16);
Would it be good to use available
spi_imx_buf_rx_u32
spi_imx_buf_rx_u16
spi_imx_buf_rx_u8
helpers here?
thanks,
Tomas
>
> if (spi_imx->rx_buf) {
> int n_bytes = spi_imx->slave_burst % sizeof(val);
> @@ -415,7 +420,11 @@ static void mx53_ecspi_tx_slave(struct spi_imx_data *spi_imx)
> if (spi_imx->tx_buf) {
> memcpy(((u8 *)&val) + sizeof(val) - n_bytes,
> spi_imx->tx_buf, n_bytes);
> - val = cpu_to_be32(val);
> + if (spi_imx->bits_per_word <= 8)
> + val = cpu_to_be32(val);
> + else if (spi_imx->bits_per_word <= 16)
> + val = (val << 16) | (val >> 16);
> +
> spi_imx->tx_buf += n_bytes;
> }
>