| Message ID | 20190109082644.14941-1-lukma@denx.de (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 5ce3cc567471891be69a6f51146209560f132b83 |
| Headers | show |
| Series | [v5] ARM: dspi: Provide support for DSPI slave mode operation (Vybryd vf610) | expand |
Dear All, > The NXP's Vybryd vf610 can work as a SPI slave device (the CS and > clock signals are provided by master). > > It is possible to specify a single device to work in that mode. As we > do use DMA for transferring data, the RX channel must be prepared for > incoming data. > Moreover, in slave mode we just set a subset of control fields in > configuration registers (CTAR0, PUSHR). > > For testing the spidev_test program has been used. > Test script for this patch can be found here: > https://github.com/lmajewski/tests-spi/blob/master/tests/spi/spi_tests.sh > > Signed-off-by: Lukasz Majewski <lukma@denx.de> > --- > Changes for v5: > > - Rebase to v5.0-rc1 (no code changes needed) Is there any interest in adding new code (or fixes) to VF610 ? The first version of this patch was posted more than 4 months ago with no feedback on the VF610 dspi controller part (after I've rewritten it to use the generic SPI slave code after comments from Geert [1]). I do have a feeling that upstreaming this code takes a bit too long ... [1] - https://lkml.org/lkml/2018/9/26/836 > > Changes for v4: > > - Rebase to v4.20-rc5 (no code changes needed) > > Changes for v3: > > - Rebase to v4.20-rc2 (no code changes needed) > > Changes for v2: > > - Remove patch which adds extra NXP specific DTS property to support > slave mode and reuse the generic one (spi-slave) > - Remove patch which brings back the mcr_register local copy. It is > not needed as generic SPI slave infrastructure is used. > - Rewrite the code to use spi_controller_is_slave() helper functions > --- > drivers/spi/spi-fsl-dspi.c | 40 > ++++++++++++++++++++++++++++++---------- 1 file changed, 30 > insertions(+), 10 deletions(-) > > diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c > index 5e10dc5c93a5..348682be9dd5 100644 > --- a/drivers/spi/spi-fsl-dspi.c > +++ b/drivers/spi/spi-fsl-dspi.c > @@ -233,6 +233,9 @@ static u32 dspi_pop_tx_pushr(struct fsl_dspi > *dspi) { > u16 cmd = dspi->tx_cmd, data = dspi_pop_tx(dspi); > > + if (spi_controller_is_slave(dspi->master)) > + return data; > + > if (dspi->len > 0) > cmd |= SPI_PUSHR_CMD_CONT; > return cmd << 16 | data; > @@ -329,6 +332,11 @@ static int dspi_next_xfer_dma_submit(struct > fsl_dspi *dspi) dma_async_issue_pending(dma->chan_rx); > dma_async_issue_pending(dma->chan_tx); > > + if (spi_controller_is_slave(dspi->master)) { > + > wait_for_completion_interruptible(&dspi->dma->cmd_rx_complete); > + return 0; > + } > + > time_left = > wait_for_completion_timeout(&dspi->dma->cmd_tx_complete, > DMA_COMPLETION_TIMEOUT); if (time_left == 0) { > @@ -798,14 +806,18 @@ static int dspi_setup(struct spi_device *spi) > ns_delay_scale(&pasc, &asc, sck_cs_delay, clkrate); > > chip->ctar_val = SPI_CTAR_CPOL(spi->mode & SPI_CPOL ? 1 : 0) > - | SPI_CTAR_CPHA(spi->mode & SPI_CPHA ? 1 : 0) > - | SPI_CTAR_LSBFE(spi->mode & SPI_LSB_FIRST ? 1 : 0) > - | SPI_CTAR_PCSSCK(pcssck) > - | SPI_CTAR_CSSCK(cssck) > - | SPI_CTAR_PASC(pasc) > - | SPI_CTAR_ASC(asc) > - | SPI_CTAR_PBR(pbr) > - | SPI_CTAR_BR(br); > + | SPI_CTAR_CPHA(spi->mode & SPI_CPHA ? 1 : 0); > + > + if (!spi_controller_is_slave(dspi->master)) { > + chip->ctar_val |= SPI_CTAR_LSBFE(spi->mode & > + SPI_LSB_FIRST ? 1 : > 0) > + | SPI_CTAR_PCSSCK(pcssck) > + | SPI_CTAR_CSSCK(cssck) > + | SPI_CTAR_PASC(pasc) > + | SPI_CTAR_ASC(asc) > + | SPI_CTAR_PBR(pbr) > + | SPI_CTAR_BR(br); > + } > > spi_set_ctldata(spi, chip); > > @@ -970,8 +982,13 @@ static const struct regmap_config > dspi_xspi_regmap_config[] = { > static void dspi_init(struct fsl_dspi *dspi) > { > - regmap_write(dspi->regmap, SPI_MCR, SPI_MCR_MASTER | > SPI_MCR_PCSIS | > - (dspi->devtype_data->xspi_mode ? SPI_MCR_XSPI : > 0)); > + unsigned int mcr = SPI_MCR_PCSIS | > + (dspi->devtype_data->xspi_mode ? SPI_MCR_XSPI : 0); > + > + if (!spi_controller_is_slave(dspi->master)) > + mcr |= SPI_MCR_MASTER; > + > + regmap_write(dspi->regmap, SPI_MCR, mcr); > regmap_write(dspi->regmap, SPI_SR, SPI_SR_CLEAR); > if (dspi->devtype_data->xspi_mode) > regmap_write(dspi->regmap, SPI_CTARE(0), > @@ -1027,6 +1044,9 @@ static int dspi_probe(struct platform_device > *pdev) } > master->bus_num = bus_num; > > + if (of_property_read_bool(np, "spi-slave")) > + master->slave = true; > + > dspi->devtype_data = > of_device_get_match_data(&pdev->dev); if (!dspi->devtype_data) { > dev_err(&pdev->dev, "can't get > devtype_data\n"); Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de
On Mon, Feb 04, 2019 at 11:30:01AM +0100, Lukasz Majewski wrote:
> Is there any interest in adding new code (or fixes) to VF610 ?
You've been sending ARM: patches to me (the SPI maintainer) and one of
the DT maintainers. You need to send patches for that platform to the
relevant platform maintainers, I only maintain drivers/spi (and some
other subsystems). Similarly the DT maintainers only maintain the
generic devicetree stuff (but apply relatively few patches directly).
Please see submitting-patches.rst for details.
Hi Mark, > On Mon, Feb 04, 2019 at 11:30:01AM +0100, Lukasz Majewski wrote: > > > Is there any interest in adding new code (or fixes) to VF610 ? > > You've been sending ARM: patches to me (the SPI maintainer) and one of > the DT maintainers. > You need to send patches for that platform to the > relevant platform maintainers, I only maintain drivers/spi (and some > other subsystems). Similarly the DT maintainers only maintain the > generic devicetree stuff (but apply relatively few patches directly). > > Please see submitting-patches.rst for details. https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html Point 5): git format-patch -1 e26e01ac03aae6cf296e7b4de47354d3151b21e7 0001-ARM-dspi-Provide-support-for-DSPI-slave-mode-operati.patch ./scripts/get_maintainer.pl 0001-ARM-dspi-Provide-support-for-DSPI-slave-mode-operati.patch Mark Brown <broonie@kernel.org> (maintainer:SPI SUBSYSTEM) linux-spi@vger.kernel.org (open list:SPI SUBSYSTEM) linux-kernel@vger.kernel.org (open list) Moreover, I've CC'ed developers (Esben, Andrey, Martin) involved in the changes for previous work done in this file/driver. And those changes are solely related to SPI work in this driver, no ARM Vybrid. What else shall I do? Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de
On Mon, Feb 04, 2019 at 01:52:42PM +0100, Lukasz Majewski wrote: > > On Mon, Feb 04, 2019 at 11:30:01AM +0100, Lukasz Majewski wrote: > > You've been sending ARM: patches to me (the SPI maintainer) and one of > > the DT maintainers. ... > Moreover, I've CC'ed developers (Esben, Andrey, Martin) involved in the > changes for previous work done in this file/driver. > And those changes are solely related to SPI work in this driver, no ARM > Vybrid. If they're SPI patches they should have a changelog that looks like a SPI patch which means that it should start with "spi" (see other patches on the list or git log for examples). When your patch subject lines start with ARM: that means they are for arch/arm - I don't 100% know but I suspect I've just not got far enough into the mails to notice that they're for SPI, people do send a lot of patches that just happen to mention buses to maintainers for those buses. In general you should try to make sure that the subject line for your patch matches the style used in the relevant subsystem. > What else shall I do? You'll need to resend the patch, preferrably with a suitable subject line.
Hi Mark, > On Mon, Feb 04, 2019 at 01:52:42PM +0100, Lukasz Majewski wrote: > > > On Mon, Feb 04, 2019 at 11:30:01AM +0100, Lukasz Majewski wrote: > > > > You've been sending ARM: patches to me (the SPI maintainer) and > > > one of the DT maintainers. > > ... > > > Moreover, I've CC'ed developers (Esben, Andrey, Martin) involved in > > the changes for previous work done in this file/driver. > > > And those changes are solely related to SPI work in this driver, no > > ARM Vybrid. > > If they're SPI patches they should have a changelog that looks like a > SPI patch which means that it should start with "spi" (see other > patches on the list or git log for examples). When your patch > subject lines start with ARM: that means they are for arch/arm - I > don't 100% know but I suspect I've just not got far enough into the > mails to notice that they're for SPI, people do send a lot of patches > that just happen to mention buses to maintainers for those buses. In > general you should try to make sure that the subject line for your > patch matches the style used in the relevant subsystem. I see. Thanks for the detailed explanation. > > > What else shall I do? > > You'll need to resend the patch, preferrably with a suitable subject > line. I will resend the patch with more suitable subject, no problem. Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de
Hello: The following patches were marked "accepted", because they were applied to broonie/spi.git (refs/heads/for-next): Patch: [v6] spi: spi-fsl-dspi: Provide support for DSPI slave mode operation (Vybryd vf610) Submitter: Lukasz Majewski <lukma@denx.de> Patchwork: https://patchwork.kernel.org/project/spi-devel-general/list/?series=76203 Patch: [v5] ARM: dspi: Provide support for DSPI slave mode operation (Vybryd vf610) Submitter: Lukasz Majewski <lukma@denx.de> Patchwork: https://patchwork.kernel.org/project/spi-devel-general/list/?series=63851 Total patches: 2
diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c index 5e10dc5c93a5..348682be9dd5 100644 --- a/drivers/spi/spi-fsl-dspi.c +++ b/drivers/spi/spi-fsl-dspi.c @@ -233,6 +233,9 @@ static u32 dspi_pop_tx_pushr(struct fsl_dspi *dspi) { u16 cmd = dspi->tx_cmd, data = dspi_pop_tx(dspi); + if (spi_controller_is_slave(dspi->master)) + return data; + if (dspi->len > 0) cmd |= SPI_PUSHR_CMD_CONT; return cmd << 16 | data; @@ -329,6 +332,11 @@ static int dspi_next_xfer_dma_submit(struct fsl_dspi *dspi) dma_async_issue_pending(dma->chan_rx); dma_async_issue_pending(dma->chan_tx); + if (spi_controller_is_slave(dspi->master)) { + wait_for_completion_interruptible(&dspi->dma->cmd_rx_complete); + return 0; + } + time_left = wait_for_completion_timeout(&dspi->dma->cmd_tx_complete, DMA_COMPLETION_TIMEOUT); if (time_left == 0) { @@ -798,14 +806,18 @@ static int dspi_setup(struct spi_device *spi) ns_delay_scale(&pasc, &asc, sck_cs_delay, clkrate); chip->ctar_val = SPI_CTAR_CPOL(spi->mode & SPI_CPOL ? 1 : 0) - | SPI_CTAR_CPHA(spi->mode & SPI_CPHA ? 1 : 0) - | SPI_CTAR_LSBFE(spi->mode & SPI_LSB_FIRST ? 1 : 0) - | SPI_CTAR_PCSSCK(pcssck) - | SPI_CTAR_CSSCK(cssck) - | SPI_CTAR_PASC(pasc) - | SPI_CTAR_ASC(asc) - | SPI_CTAR_PBR(pbr) - | SPI_CTAR_BR(br); + | SPI_CTAR_CPHA(spi->mode & SPI_CPHA ? 1 : 0); + + if (!spi_controller_is_slave(dspi->master)) { + chip->ctar_val |= SPI_CTAR_LSBFE(spi->mode & + SPI_LSB_FIRST ? 1 : 0) + | SPI_CTAR_PCSSCK(pcssck) + | SPI_CTAR_CSSCK(cssck) + | SPI_CTAR_PASC(pasc) + | SPI_CTAR_ASC(asc) + | SPI_CTAR_PBR(pbr) + | SPI_CTAR_BR(br); + } spi_set_ctldata(spi, chip); @@ -970,8 +982,13 @@ static const struct regmap_config dspi_xspi_regmap_config[] = { static void dspi_init(struct fsl_dspi *dspi) { - regmap_write(dspi->regmap, SPI_MCR, SPI_MCR_MASTER | SPI_MCR_PCSIS | - (dspi->devtype_data->xspi_mode ? SPI_MCR_XSPI : 0)); + unsigned int mcr = SPI_MCR_PCSIS | + (dspi->devtype_data->xspi_mode ? SPI_MCR_XSPI : 0); + + if (!spi_controller_is_slave(dspi->master)) + mcr |= SPI_MCR_MASTER; + + regmap_write(dspi->regmap, SPI_MCR, mcr); regmap_write(dspi->regmap, SPI_SR, SPI_SR_CLEAR); if (dspi->devtype_data->xspi_mode) regmap_write(dspi->regmap, SPI_CTARE(0), @@ -1027,6 +1044,9 @@ static int dspi_probe(struct platform_device *pdev) } master->bus_num = bus_num; + if (of_property_read_bool(np, "spi-slave")) + master->slave = true; + dspi->devtype_data = of_device_get_match_data(&pdev->dev); if (!dspi->devtype_data) { dev_err(&pdev->dev, "can't get devtype_data\n");
The NXP's Vybryd vf610 can work as a SPI slave device (the CS and clock signals are provided by master). It is possible to specify a single device to work in that mode. As we do use DMA for transferring data, the RX channel must be prepared for incoming data. Moreover, in slave mode we just set a subset of control fields in configuration registers (CTAR0, PUSHR). For testing the spidev_test program has been used. Test script for this patch can be found here: https://github.com/lmajewski/tests-spi/blob/master/tests/spi/spi_tests.sh Signed-off-by: Lukasz Majewski <lukma@denx.de> --- Changes for v5: - Rebase to v5.0-rc1 (no code changes needed) Changes for v4: - Rebase to v4.20-rc5 (no code changes needed) Changes for v3: - Rebase to v4.20-rc2 (no code changes needed) Changes for v2: - Remove patch which adds extra NXP specific DTS property to support slave mode and reuse the generic one (spi-slave) - Remove patch which brings back the mcr_register local copy. It is not needed as generic SPI slave infrastructure is used. - Rewrite the code to use spi_controller_is_slave() helper functions --- drivers/spi/spi-fsl-dspi.c | 40 ++++++++++++++++++++++++++++++---------- 1 file changed, 30 insertions(+), 10 deletions(-)