| Message ID | 1409328631-1420-1-git-send-email-geert@linux-m68k.org (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | f59838a07ae5b26d2e050bc0227599932d22b549 |
| Headers | show |
On Fri, Aug 29, 2014 at 06:10:31PM +0200, Geert Uytterhoeven wrote: > commit dd1053a93fdc11d4 ("spi/drivers: Enable build of drivers with > COMPILE_TEST") allows compile-testing drivers on platforms they're not > meant for. > However, adding "|| COMPILE_TEST" bypasses all other implicit dependencies > assumed by the platform dependencies before, like HAS_DMA. I'm wondering if it isn't better to have the non-DMA platforms define stub (always error) DMA functions instead - it's less error prone and with SPI there's a bunch of drivers which can run perfectly usefully without DMA while optionally supporting DMA.
Hi Mark, On Fri, Aug 29, 2014 at 7:37 PM, Mark Brown <broonie@kernel.org> wrote: > On Fri, Aug 29, 2014 at 06:10:31PM +0200, Geert Uytterhoeven wrote: >> commit dd1053a93fdc11d4 ("spi/drivers: Enable build of drivers with >> COMPILE_TEST") allows compile-testing drivers on platforms they're not >> meant for. > >> However, adding "|| COMPILE_TEST" bypasses all other implicit dependencies >> assumed by the platform dependencies before, like HAS_DMA. > > I'm wondering if it isn't better to have the non-DMA platforms define > stub (always error) DMA functions instead - it's less error prone and > with SPI there's a bunch of drivers which can run perfectly usefully > without DMA while optionally supporting DMA. The SPI problem will sort itself out once all SPI master drivers have been converted to use the SPI DMA core ;-) Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Mark, On Fri, Aug 29, 2014 at 9:13 PM, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > On Fri, Aug 29, 2014 at 7:37 PM, Mark Brown <broonie@kernel.org> wrote: >> On Fri, Aug 29, 2014 at 06:10:31PM +0200, Geert Uytterhoeven wrote: >>> commit dd1053a93fdc11d4 ("spi/drivers: Enable build of drivers with >>> COMPILE_TEST") allows compile-testing drivers on platforms they're not >>> meant for. >> >>> However, adding "|| COMPILE_TEST" bypasses all other implicit dependencies >>> assumed by the platform dependencies before, like HAS_DMA. >> >> I'm wondering if it isn't better to have the non-DMA platforms define >> stub (always error) DMA functions instead - it's less error prone and >> with SPI there's a bunch of drivers which can run perfectly usefully >> without DMA while optionally supporting DMA. > > The SPI problem will sort itself out once all SPI master drivers have been > converted to use the SPI DMA core ;-) BTW, the dmaengine API has stubs, only the low-level dma-mapping API doesn't. That's why e.g. spi-rspi doesn't need a dependency on HAS_DMA. So it's indeed a good thing to handle the low-level DMA mapping in the subsystem's core, as only that part can be optional and depend on HAS_DMA. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Aug 29, 2014 at 06:10:31PM +0200, Geert Uytterhoeven wrote: > commit dd1053a93fdc11d4 ("spi/drivers: Enable build of drivers with > COMPILE_TEST") allows compile-testing drivers on platforms they're not > meant for. Applied, thanks.
On Sun, Aug 31, 2014 at 10:39:09AM +0200, Geert Uytterhoeven wrote: > On Fri, Aug 29, 2014 at 9:13 PM, Geert Uytterhoeven > >> I'm wondering if it isn't better to have the non-DMA platforms define > >> stub (always error) DMA functions instead - it's less error prone and > >> with SPI there's a bunch of drivers which can run perfectly usefully > >> without DMA while optionally supporting DMA. > > The SPI problem will sort itself out once all SPI master drivers have been > > converted to use the SPI DMA core ;-) > BTW, the dmaengine API has stubs, only the low-level dma-mapping API > doesn't. That's why e.g. spi-rspi doesn't need a dependency on HAS_DMA. > So it's indeed a good thing to handle the low-level DMA mapping in the > subsystem's core, as only that part can be optional and depend on HAS_DMA. Yeah, but I'd expect there's other subsystems which will be in a similar boat here and with dmaengine having stubs it seems strange that the mapping API doesn't.
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index bdd20c1707e5..1a5965539efd 100644 --- a/drivers/spi/Kconfig +++ b/drivers/spi/Kconfig @@ -69,6 +69,7 @@ config SPI_ATH79 config SPI_ATMEL tristate "Atmel SPI Controller" + depends on HAS_DMA depends on (ARCH_AT91 || AVR32 || COMPILE_TEST) help This selects a driver for the Atmel SPI Controller, present on @@ -185,6 +186,7 @@ config SPI_EFM32 config SPI_EP93XX tristate "Cirrus Logic EP93xx SPI controller" + depends on HAS_DMA depends on ARCH_EP93XX || COMPILE_TEST help This enables using the Cirrus EP93xx SPI controller in master @@ -320,6 +322,7 @@ config SPI_OMAP_UWIRE config SPI_OMAP24XX tristate "McSPI driver for OMAP" + depends on HAS_DMA depends on ARM || ARM64 || AVR32 || HEXAGON || MIPS || SUPERH depends on ARCH_OMAP2PLUS || COMPILE_TEST help @@ -506,7 +509,7 @@ config SPI_MXS config SPI_TEGRA114 tristate "NVIDIA Tegra114 SPI Controller" depends on (ARCH_TEGRA && TEGRA20_APB_DMA) || COMPILE_TEST - depends on RESET_CONTROLLER + depends on RESET_CONTROLLER && HAS_DMA help SPI driver for NVIDIA Tegra114 SPI Controller interface. This controller is different than the older SoCs SPI controller and also register interface @@ -524,7 +527,7 @@ config SPI_TEGRA20_SFLASH config SPI_TEGRA20_SLINK tristate "Nvidia Tegra20/Tegra30 SLINK Controller" depends on (ARCH_TEGRA && TEGRA20_APB_DMA) || COMPILE_TEST - depends on RESET_CONTROLLER + depends on RESET_CONTROLLER && HAS_DMA help SPI driver for Nvidia Tegra20/Tegra30 SLINK Controller interface.
commit dd1053a93fdc11d4 ("spi/drivers: Enable build of drivers with COMPILE_TEST") allows compile-testing drivers on platforms they're not meant for. However, adding "|| COMPILE_TEST" bypasses all other implicit dependencies assumed by the platform dependencies before, like HAS_DMA. If NO_DMA=y: drivers/built-in.o: In function `atmel_spi_dma_unmap_xfer': drivers/spi/spi-atmel.c:915: undefined reference to `dma_unmap_single' drivers/spi/spi-atmel.c:918: undefined reference to `dma_unmap_single' drivers/built-in.o: In function `atmel_spi_next_xfer_data': drivers/spi/spi-atmel.c:690: undefined reference to `dma_sync_single_for_cpu' drivers/built-in.o: In function `atmel_spi_dma_map_xfer': drivers/spi/spi-atmel.c:890: undefined reference to `dma_map_single' drivers/spi/spi-atmel.c:893: undefined reference to `dma_mapping_error' drivers/spi/spi-atmel.c:897: undefined reference to `dma_map_single' drivers/spi/spi-atmel.c:900: undefined reference to `dma_mapping_error' drivers/spi/spi-atmel.c:902: undefined reference to `dma_unmap_single' drivers/built-in.o: In function `atmel_spi_probe': drivers/spi/spi-atmel.c:1540: undefined reference to `dma_alloc_coherent' drivers/spi/spi-atmel.c:1623: undefined reference to `dma_free_coherent' drivers/built-in.o: In function `atmel_spi_remove': drivers/spi/spi-atmel.c:1665: undefined reference to `dma_free_coherent' drivers/built-in.o: In function `ep93xx_spi_dma_finish': drivers/spi/spi-ep93xx.c:550: undefined reference to `dma_unmap_sg' drivers/built-in.o: In function `ep93xx_spi_dma_prepare': drivers/spi/spi-ep93xx.c:516: undefined reference to `dma_map_sg' drivers/spi/spi-ep93xx.c:522: undefined reference to `dma_unmap_sg' drivers/built-in.o: In function `omap2_mcspi_rx_dma': drivers/spi/spi-omap2-mcspi.c:475: undefined reference to `dma_unmap_single' drivers/built-in.o: In function `omap2_mcspi_txrx_dma': drivers/spi/spi-omap2-mcspi.c:589: undefined reference to `dma_unmap_single' drivers/built-in.o: In function `omap2_mcspi_transfer_one_message': drivers/spi/spi-omap2-mcspi.c:1202: undefined reference to `dma_map_single' drivers/spi/spi-omap2-mcspi.c:1204: undefined reference to `dma_mapping_error' drivers/spi/spi-omap2-mcspi.c:1211: undefined reference to `dma_map_single' drivers/spi/spi-omap2-mcspi.c:1213: undefined reference to `dma_mapping_error' drivers/spi/spi-omap2-mcspi.c:1217: undefined reference to `dma_unmap_single' drivers/built-in.o: In function `tegra_spi_deinit_dma_param': drivers/spi/spi-tegra114.c:675: undefined reference to `dma_free_coherent' drivers/built-in.o: In function `tegra_spi_copy_spi_rxbuf_to_client_rxbuf': drivers/spi/spi-tegra114.c:415: undefined reference to `dma_sync_single_for_cpu' drivers/spi/spi-tegra114.c:440: undefined reference to `dma_sync_single_for_cpu' drivers/built-in.o: In function `tegra_spi_copy_client_txbuf_to_spi_txbuf': drivers/spi/spi-tegra114.c:381: undefined reference to `dma_sync_single_for_cpu' drivers/spi/spi-tegra114.c:405: undefined reference to `dma_sync_single_for_cpu' drivers/built-in.o: In function `tegra_spi_start_dma_based_transfer': drivers/spi/spi-tegra114.c:543: undefined reference to `dma_sync_single_for_cpu' drivers/built-in.o: In function `tegra_slink_deinit_dma_param': drivers/spi/spi-tegra20-slink.c:705: undefined reference to `dma_free_coherent' drivers/built-in.o: In function `tegra_slink_copy_spi_rxbuf_to_client_rxbuf': drivers/spi/spi-tegra20-slink.c:427: undefined reference to `dma_sync_single_for_cpu' drivers/spi/spi-tegra20-slink.c:452: undefined reference to `dma_sync_single_for_cpu' drivers/built-in.o: In function `tegra_slink_copy_client_txbuf_to_spi_txbuf': drivers/spi/spi-tegra20-slink.c:393: undefined reference to `dma_sync_single_for_cpu' drivers/spi/spi-tegra20-slink.c:417: undefined reference to `dma_sync_single_for_cpu' drivers/built-in.o: In function `tegra_slink_start_dma_based_transfer': drivers/spi/spi-tegra20-slink.c:561: undefined reference to `dma_sync_single_for_cpu' Add dependencies on HAS_DMA to fix this. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> --- v2: Use sparate "depends on HAS_DMA" instead of "COMPILE_TEST && HAS_DMA" --- drivers/spi/Kconfig | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)