Re: [PATCH 11/13] spi: omap2-mcspi: Support for deferred probing when requesting DMA channels
Mark, On 05/26/2015 06:27 PM, Mark Brown wrote: On Tue, May 26, 2015 at 04:26:06PM +0300, Peter Ujfalusi wrote: Switch to use ma_request_slave_channel_compat_reason() to request the DMA channels. Only fall back to pio mode if the error code returned is not -EPROBE_DEFER, otherwise return from the probe with the -EPROBE_DEFER. I've got two patches from a patch series here with no cover letter... I'm guessing there's no interdependencies or anything? Please always ensure that when sending a patch series everyone getting the patches can tell what the series as a whole looks like (if there's no dependencies consider posting as individual patches rather than a series). I have put the maintainers of the relevant subsystems as CC in the commit message and sent the series to all of the mailing lists. This series was touching 7 subsystems and I thought not spamming every maintainer with all the mails might be better. In v2 I will keep this in mind. The series depends on the first two patch, which adds the dma_request_slave_channel_compat_reason() function. -- Péter -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/13] spi: omap2-mcspi: Support for deferred probing when requesting DMA channels
On Tue, May 26, 2015 at 04:26:06PM +0300, Peter Ujfalusi wrote: Switch to use ma_request_slave_channel_compat_reason() to request the DMA channels. Only fall back to pio mode if the error code returned is not -EPROBE_DEFER, otherwise return from the probe with the -EPROBE_DEFER. Acked-by: Mark Brown broo...@kernel.org signature.asc Description: Digital signature
Re: [PATCH 11/13] spi: omap2-mcspi: Support for deferred probing when requesting DMA channels
On Wed, May 27, 2015 at 02:15:12PM +0300, Peter Ujfalusi wrote: I have put the maintainers of the relevant subsystems as CC in the commit message and sent the series to all of the mailing lists. This series was touching 7 subsystems and I thought not spamming every maintainer with all the mails might be better. You need to at least include people on the cover letter, otherwise they'll have no idea what's going on. signature.asc Description: Digital signature
[PATCH 11/13] spi: omap2-mcspi: Support for deferred probing when requesting DMA channels
Switch to use ma_request_slave_channel_compat_reason() to request the DMA channels. Only fall back to pio mode if the error code returned is not -EPROBE_DEFER, otherwise return from the probe with the -EPROBE_DEFER. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com CC: Mark Brown broo...@kernel.org --- drivers/spi/spi-omap2-mcspi.c | 36 +--- 1 file changed, 21 insertions(+), 15 deletions(-) diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c index a7d85c5ab2fa..e6ff937688ff 100644 --- a/drivers/spi/spi-omap2-mcspi.c +++ b/drivers/spi/spi-omap2-mcspi.c @@ -948,6 +948,7 @@ static int omap2_mcspi_request_dma(struct spi_device *spi) struct omap2_mcspi_dma *mcspi_dma; dma_cap_mask_t mask; unsigned sig; + int ret = 0; mcspi = spi_master_get_devdata(master); mcspi_dma = mcspi-dma_channels + spi-chip_select; @@ -959,30 +960,35 @@ static int omap2_mcspi_request_dma(struct spi_device *spi) dma_cap_set(DMA_SLAVE, mask); sig = mcspi_dma-dma_rx_sync_dev; - mcspi_dma-dma_rx = - dma_request_slave_channel_compat(mask, omap_dma_filter_fn, -sig, master-dev, -mcspi_dma-dma_rx_ch_name); - if (!mcspi_dma-dma_rx) + mcspi_dma-dma_rx = dma_request_slave_channel_compat_reason(mask, + omap_dma_filter_fn, sig, master-dev, + mcspi_dma-dma_rx_ch_name); + if (IS_ERR(mcspi_dma-dma_rx)) { + ret = PTR_ERR(mcspi_dma-dma_rx); + mcspi_dma-dma_rx = NULL; + if (ret != -EPROBE_DEFER) + ret = -EAGAIN; goto no_dma; + } sig = mcspi_dma-dma_tx_sync_dev; - mcspi_dma-dma_tx = - dma_request_slave_channel_compat(mask, omap_dma_filter_fn, -sig, master-dev, -mcspi_dma-dma_tx_ch_name); + mcspi_dma-dma_tx = dma_request_slave_channel_compat_reason(mask, + omap_dma_filter_fn, sig, master-dev, + mcspi_dma-dma_tx_ch_name); - if (!mcspi_dma-dma_tx) { + if (IS_ERR(mcspi_dma-dma_tx)) { + ret = PTR_ERR(mcspi_dma-dma_tx); + mcspi_dma-dma_tx = NULL; dma_release_channel(mcspi_dma-dma_rx); mcspi_dma-dma_rx = NULL; - goto no_dma; + if (ret != -EPROBE_DEFER) + ret = -EAGAIN; } - return 0; - no_dma: - dev_warn(spi-dev, not using DMA for McSPI\n); - return -EAGAIN; + if (ret ret != -EPROBE_DEFER) + dev_warn(spi-dev, not using DMA for McSPI\n); + return ret; } static int omap2_mcspi_setup(struct spi_device *spi) -- 2.3.5 -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/13] spi: omap2-mcspi: Support for deferred probing when requesting DMA channels
On Tue, May 26, 2015 at 04:26:06PM +0300, Peter Ujfalusi wrote: Switch to use ma_request_slave_channel_compat_reason() to request the DMA channels. Only fall back to pio mode if the error code returned is not -EPROBE_DEFER, otherwise return from the probe with the -EPROBE_DEFER. I've got two patches from a patch series here with no cover letter... I'm guessing there's no interdependencies or anything? Please always ensure that when sending a patch series everyone getting the patches can tell what the series as a whole looks like (if there's no dependencies consider posting as individual patches rather than a series). signature.asc Description: Digital signature