| Message ID | 20220926181848.2917639-1-khilman@baylibre.com |
|---|---|
| Headers | show |
| Series | dma/ti: enable udma and psil to be built as modules | expand |
Péter Ujfalusi <peter.ujfalusi@gmail.com> writes: > Hi Kevin, > > On 9/26/22 21:18, Kevin Hilman wrote: >> map symbols need EXPORT_SYMBOL and files need MODULE_LICENSE. >> >> Signed-off-by: Kevin Hilman <khilman@baylibre.com> >> --- >> drivers/dma/ti/Kconfig | 3 ++- >> drivers/dma/ti/k3-psil-am62.c | 4 ++++ >> drivers/dma/ti/k3-psil-am64.c | 4 ++++ >> drivers/dma/ti/k3-psil-am654.c | 4 ++++ >> drivers/dma/ti/k3-psil-j7200.c | 4 ++++ >> drivers/dma/ti/k3-psil-j721e.c | 4 ++++ >> drivers/dma/ti/k3-psil-j721s2.c | 4 ++++ >> drivers/dma/ti/k3-psil.c | 2 ++ >> 8 files changed, 28 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/dma/ti/Kconfig b/drivers/dma/ti/Kconfig >> index f196be3b222f..2adc2cca10e9 100644 >> --- a/drivers/dma/ti/Kconfig >> +++ b/drivers/dma/ti/Kconfig >> @@ -56,7 +56,8 @@ config TI_K3_UDMA_GLUE_LAYER >> If unsure, say N. >> >> config TI_K3_PSIL >> - bool >> + tristate >> + default TI_K3_UDMA >> >> config TI_DMA_CROSSBAR >> bool >> diff --git a/drivers/dma/ti/k3-psil-am62.c b/drivers/dma/ti/k3-psil-am62.c >> index 2b6fd6e37c61..7c4ca85f68b1 100644 >> --- a/drivers/dma/ti/k3-psil-am62.c >> +++ b/drivers/dma/ti/k3-psil-am62.c >> @@ -4,6 +4,7 @@ >> */ >> >> #include <linux/kernel.h> >> +#include <linux/module.h> >> >> #include "k3-psil-priv.h" >> >> @@ -184,3 +185,6 @@ struct psil_ep_map am62_ep_map = { >> .dst = am62_dst_ep_map, >> .dst_count = ARRAY_SIZE(am62_dst_ep_map), >> }; >> +EXPORT_SYMBOL_GPL(am62_ep_map); > > Wouldn't it be better to build one module (k3-psil.ko) and link all the > platform libs into that? > They are unconditionally built in all cases anyways and makes the lsmod > under control. > And no need to export these maps at all is a plus. I guess that's one option, but seems to be to be the wrong direction for a modular kernel. To me, it seems like the next step would be to make it so only the SoC specific module is loaded instead of always loading them all. Kevin
Péter Ujfalusi <peter.ujfalusi@gmail.com> writes: > On 9/26/22 21:18, Kevin Hilman wrote: >> Currently k3-udma driver is built as separate platform drivers with a >> shared probe and identical code path, just differnet platform data. >> >> To enable to build as module, convert the separate platform driver >> into a single module_platform_driver with the data selection done via >> compatible string and of_match. The separate of_match tables are also >> combined into a single table to avoid the multiple calls to >> of_match_node() >> >> Since all modern TI platforms using this are DT enabled, the removal >> of separate platform_drivers shoul should nave no functional change. >> >> Signed-off-by: Kevin Hilman <khilman@baylibre.com> >> --- >> drivers/dma/ti/Kconfig | 4 ++-- >> drivers/dma/ti/k3-udma-glue.c | 5 ++++- >> drivers/dma/ti/k3-udma.c | 40 +++++------------------------------ >> 3 files changed, 11 insertions(+), 38 deletions(-) >> >> diff --git a/drivers/dma/ti/Kconfig b/drivers/dma/ti/Kconfig >> index 79618fac119a..f196be3b222f 100644 >> --- a/drivers/dma/ti/Kconfig >> +++ b/drivers/dma/ti/Kconfig >> @@ -35,7 +35,7 @@ config DMA_OMAP >> DMA engine is found on OMAP and DRA7xx parts. >> >> config TI_K3_UDMA >> - bool "Texas Instruments UDMA support" >> + tristate "Texas Instruments UDMA support" >> depends on ARCH_K3 >> depends on TI_SCI_PROTOCOL >> depends on TI_SCI_INTA_IRQCHIP >> @@ -48,7 +48,7 @@ config TI_K3_UDMA >> DMA engine is used in AM65x and j721e. >> >> config TI_K3_UDMA_GLUE_LAYER >> - bool "Texas Instruments UDMA Glue layer for non DMAengine users" >> + tristate "Texas Instruments UDMA Glue layer for non DMAengine users" >> depends on ARCH_K3 >> depends on TI_K3_UDMA >> help >> diff --git a/drivers/dma/ti/k3-udma-glue.c b/drivers/dma/ti/k3-udma-glue.c >> index 4fdd9f06b723..c29de4695ae7 100644 >> --- a/drivers/dma/ti/k3-udma-glue.c >> +++ b/drivers/dma/ti/k3-udma-glue.c >> @@ -6,6 +6,7 @@ >> * >> */ >> >> +#include <linux/module.h> >> #include <linux/atomic.h> >> #include <linux/delay.h> >> #include <linux/dma-mapping.h> >> @@ -1433,4 +1434,6 @@ static int __init k3_udma_glue_class_init(void) >> { >> return class_register(&k3_udma_glue_devclass); >> } >> -arch_initcall(k3_udma_glue_class_init); >> + >> +module_init(k3_udma_glue_class_init); >> +MODULE_LICENSE("GPL v2"); >> diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c >> index 2f0d2c68c93c..7239ff31c8c5 100644 >> --- a/drivers/dma/ti/k3-udma.c >> +++ b/drivers/dma/ti/k3-udma.c >> @@ -5,6 +5,7 @@ >> */ >> >> #include <linux/kernel.h> >> +#include <linux/module.h> >> #include <linux/delay.h> >> #include <linux/dmaengine.h> >> #include <linux/dma-mapping.h> >> @@ -4318,18 +4319,10 @@ static const struct of_device_id udma_of_match[] = { >> .compatible = "ti,j721e-navss-mcu-udmap", >> .data = &j721e_mcu_data, >> }, >> - { /* Sentinel */ }, >> -}; >> - >> -static const struct of_device_id bcdma_of_match[] = { >> { >> .compatible = "ti,am64-dmss-bcdma", >> .data = &am64_bcdma_data, >> }, >> - { /* Sentinel */ }, >> -}; >> - >> -static const struct of_device_id pktdma_of_match[] = { >> { >> .compatible = "ti,am64-dmss-pktdma", >> .data = &am64_pktdma_data, >> @@ -5254,14 +5247,9 @@ static int udma_probe(struct platform_device *pdev) >> return -ENOMEM; >> >> match = of_match_node(udma_of_match, dev->of_node); >> - if (!match) >> - match = of_match_node(bcdma_of_match, dev->of_node); >> if (!match) { >> - match = of_match_node(pktdma_of_match, dev->of_node); >> - if (!match) { >> - dev_err(dev, "No compatible match found\n"); >> - return -ENODEV; >> - } >> + dev_err(dev, "No compatible match found\n"); >> + return -ENODEV; >> } >> ud->match_data = match->data; >> >> @@ -5494,27 +5482,9 @@ static struct platform_driver udma_driver = { >> }, >> .probe = udma_probe, >> }; >> -builtin_platform_driver(udma_driver); >> >> -static struct platform_driver bcdma_driver = { >> - .driver = { >> - .name = "ti-bcdma", >> - .of_match_table = bcdma_of_match, >> - .suppress_bind_attrs = true, >> - }, >> - .probe = udma_probe, >> -}; >> -builtin_platform_driver(bcdma_driver); >> - >> -static struct platform_driver pktdma_driver = { >> - .driver = { >> - .name = "ti-pktdma", >> - .of_match_table = pktdma_of_match, >> - .suppress_bind_attrs = true, >> - }, >> - .probe = udma_probe, >> -}; >> -builtin_platform_driver(pktdma_driver); >> +module_platform_driver(udma_driver); > I did liked the 'hack' that the dev_* prints contained the actual type > of the DMA (udma/bcdma/pktdma), but it is not working via modules, > unless the driver init parts are split out and the bulk is kept as a > library. > > I had this half way implemented in my wip, but never got the chance to > finalize it. I guess that could always be done as a second path if needed, but I wanted to keep this module conversion as simple as possible at first. > But, one can get the info via the address, so... Shall I take this "so..." as an acked-by? ;) Kevin
On 27/09/2022 00:17, Kevin Hilman wrote: > >> I did liked the 'hack' that the dev_* prints contained the actual type >> of the DMA (udma/bcdma/pktdma), but it is not working via modules, >> unless the driver init parts are split out and the bulk is kept as a >> library. >> >> I had this half way implemented in my wip, but never got the chance to >> finalize it. > > I guess that could always be done as a second path if needed, but I > wanted to keep this module conversion as simple as possible at first. > >> But, one can get the info via the address, so... > > Shall I take this "so..." as an acked-by? ;) For this patch, definitely: Acked-by: Peter Ujfalusi <peter.ujfalusi@gmail.com> > > Kevin > >
On 27/09/2022 00:21, Kevin Hilman wrote: > Hi Péter, > > Péter Ujfalusi <peter.ujfalusi@gmail.com> writes: > >> On 9/26/22 21:18, Kevin Hilman wrote: >>> Enable the UDMA driver & glue and PSIL maps to be built & loaded as modules. >>> >>> The defauilt Kconfig settings are not changed, so default upstream is >>> still to be built in. This series just enables the option to build as >>> modules. >> >> I can finally drop the half backed stuff I roll on top of -next ;) >> >> Do you plan to convert the ringacc also? It is straight forward, like: >> https://github.com/omap-audio/linux-audio/commit/01f9290c1c61e8bbc0fbdd877382672883ba7e73 > > Yes, my colleague Nicolas (cc'd) was planning ringacc shortly, but we > didn't realize you had already don it. Your version looks fine to me. > Any reason not to submit yours? It can only be sent after the UDMA is able to be built as a module. When I did the module support there were also a tisci dependency which for some reason took too long for me to be able to send these. I can send my version later if it is OK, but if Nicolas have a better take on it, I don't mind.
Péter Ujfalusi <peter.ujfalusi@gmail.com> writes: > On 27/09/2022 00:21, Kevin Hilman wrote: >> Hi Péter, >> >> Péter Ujfalusi <peter.ujfalusi@gmail.com> writes: >> >>> On 9/26/22 21:18, Kevin Hilman wrote: >>>> Enable the UDMA driver & glue and PSIL maps to be built & loaded as modules. >>>> >>>> The defauilt Kconfig settings are not changed, so default upstream is >>>> still to be built in. This series just enables the option to build as >>>> modules. >>> >>> I can finally drop the half backed stuff I roll on top of -next ;) >>> >>> Do you plan to convert the ringacc also? It is straight forward, like: >>> https://github.com/omap-audio/linux-audio/commit/01f9290c1c61e8bbc0fbdd877382672883ba7e73 >> >> Yes, my colleague Nicolas (cc'd) was planning ringacc shortly, but we >> didn't realize you had already don it. Your version looks fine to me. >> Any reason not to submit yours? > > It can only be sent after the UDMA is able to be built as a module. OK, I sent a v2 of this series, which I think should be ready for merge now. > When I did the module support there were also a tisci dependency which > for some reason took too long for me to be able to send these. > I can send my version later if it is OK, but if Nicolas have a better > take on it, I don't mind. We've got a handful of other conversions coming for a fully modular kernel, so I'm sure Nicolas would be happy if you took care of ringacc. :) Kevin
On 28/09/2022 02:10, Kevin Hilman wrote: >> When I did the module support there were also a tisci dependency which >> for some reason took too long for me to be able to send these. >> I can send my version later if it is OK, but if Nicolas have a better >> take on it, I don't mind. > > We've got a handful of other conversions coming for a fully modular > kernel, so I'm sure Nicolas would be happy if you took care of > ringacc. :) Sure, I will send it when the UDMA part is merged.