* [PATCH] arm64: defconfig: Enable Texas Instruments UDMA driver
@ 2020-01-24 9:23 Peter Ujfalusi
2020-01-24 20:08 ` Olof Johansson
0 siblings, 1 reply; 6+ messages in thread
From: Peter Ujfalusi @ 2020-01-24 9:23 UTC (permalink / raw)
To: catalin.marinas, will
Cc: alexandre.belloni, arnd, soc, linux-kernel, t-kristo, vkoul,
olof, linux-arm-kernel
The UDMA driver is used on K3 platforms (am654 and j721e).
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
Hi,
The drivers for UDMA are already in linu-next and the DT patches are going to be
also heading for 5.6.
The only missing piece is to enable the drivers in defconfig so clients can use
the DMA.
Regards,
Peter
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 4631a1190719..a325a296d94c 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -698,6 +698,7 @@ CONFIG_QCOM_HIDMA_MGMT=y
CONFIG_QCOM_HIDMA=y
CONFIG_RCAR_DMAC=y
CONFIG_RENESAS_USB_DMAC=m
+CONFIG_TI_K3_UDMA=y
CONFIG_VFIO=y
CONFIG_VFIO_PCI=y
CONFIG_VIRTIO_PCI=y
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] arm64: defconfig: Enable Texas Instruments UDMA driver
2020-01-24 9:23 [PATCH] arm64: defconfig: Enable Texas Instruments UDMA driver Peter Ujfalusi
@ 2020-01-24 20:08 ` Olof Johansson
2020-01-27 10:32 ` Peter Ujfalusi
0 siblings, 1 reply; 6+ messages in thread
From: Olof Johansson @ 2020-01-24 20:08 UTC (permalink / raw)
To: Peter Ujfalusi
Cc: alexandre.belloni, arnd, soc, catalin.marinas, linux-kernel,
t-kristo, vkoul, will, linux-arm-kernel
On Fri, Jan 24, 2020 at 11:23:59AM +0200, Peter Ujfalusi wrote:
> The UDMA driver is used on K3 platforms (am654 and j721e).
>
> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
> ---
> Hi,
>
> The drivers for UDMA are already in linu-next and the DT patches are going to be
> also heading for 5.6.
> The only missing piece is to enable the drivers in defconfig so clients can use
> the DMA.
Hi Peter,
We normally like to see new options turned on after the driver/option has been
merged, so send this during or right after the merge window when that happens,
please.
I also see that this is statically enabling this driver -- we try to keep as
many drivers as possible as modules to avoid the static kernel from growing too
large. Would that be a suitable approach here, or is the driver needed to reach
rootfs for further module loading?
Thanks,
-Olof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] arm64: defconfig: Enable Texas Instruments UDMA driver
2020-01-24 20:08 ` Olof Johansson
@ 2020-01-27 10:32 ` Peter Ujfalusi
2020-01-27 15:30 ` Olof Johansson
0 siblings, 1 reply; 6+ messages in thread
From: Peter Ujfalusi @ 2020-01-27 10:32 UTC (permalink / raw)
To: Olof Johansson
Cc: alexandre.belloni, arnd, soc, catalin.marinas, linux-kernel,
t-kristo, vkoul, will, linux-arm-kernel
Hi Olof,
On 24/01/2020 22.08, Olof Johansson wrote:
> On Fri, Jan 24, 2020 at 11:23:59AM +0200, Peter Ujfalusi wrote:
>> The UDMA driver is used on K3 platforms (am654 and j721e).
>>
>> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
>> ---
>> Hi,
>>
>> The drivers for UDMA are already in linu-next and the DT patches are going to be
>> also heading for 5.6.
>> The only missing piece is to enable the drivers in defconfig so clients can use
>> the DMA.
>
> Hi Peter,
>
> We normally like to see new options turned on after the driver/option has been
> merged, so send this during or right after the merge window when that happens,
> please.
Sure, I'll post it later.
> I also see that this is statically enabling this driver -- we try to keep as
> many drivers as possible as modules to avoid the static kernel from growing too
> large. Would that be a suitable approach here, or is the driver needed to reach
> rootfs for further module loading?
We would need built in DMA for nfs rootfs, SD/MMC has it's own buit-in
ADMA. We do not have network drivers upstream as they depend on the DMA.
Imho module would be fine for the DMA stack, but neither ringacc or the
UDMA driver can be built as module atm until the following patches got
merged:
https://lore.kernel.org/lkml/20200122104723.16955-1-peter.ujfalusi@ti.com/
https://lore.kernel.org/lkml/20200122104031.15733-1-peter.ujfalusi@ti.com/
I have the patches to add back module support, but waiting on these
currently.
- Péter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] arm64: defconfig: Enable Texas Instruments UDMA driver
2020-01-27 10:32 ` Peter Ujfalusi
@ 2020-01-27 15:30 ` Olof Johansson
2020-01-28 8:21 ` Peter Ujfalusi
0 siblings, 1 reply; 6+ messages in thread
From: Olof Johansson @ 2020-01-27 15:30 UTC (permalink / raw)
To: Peter Ujfalusi
Cc: Alexandre Belloni, Arnd Bergmann, SoC Team, Catalin Marinas,
Linux Kernel Mailing List, Tero Kristo, Vinod Koul, Will Deacon,
Linux ARM Mailing List
On Mon, Jan 27, 2020 at 2:31 AM Peter Ujfalusi <peter.ujfalusi@ti.com> wrote:
>
> Hi Olof,
>
> On 24/01/2020 22.08, Olof Johansson wrote:
> > On Fri, Jan 24, 2020 at 11:23:59AM +0200, Peter Ujfalusi wrote:
> >> The UDMA driver is used on K3 platforms (am654 and j721e).
> >>
> >> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
> >> ---
> >> Hi,
> >>
> >> The drivers for UDMA are already in linu-next and the DT patches are going to be
> >> also heading for 5.6.
> >> The only missing piece is to enable the drivers in defconfig so clients can use
> >> the DMA.
> >
> > Hi Peter,
> >
> > We normally like to see new options turned on after the driver/option has been
> > merged, so send this during or right after the merge window when that happens,
> > please.
>
> Sure, I'll post it later.
Great!
>
> > I also see that this is statically enabling this driver -- we try to keep as
> > many drivers as possible as modules to avoid the static kernel from growing too
> > large. Would that be a suitable approach here, or is the driver needed to reach
> > rootfs for further module loading?
>
> We would need built in DMA for nfs rootfs, SD/MMC has it's own buit-in
> ADMA. We do not have network drivers upstream as they depend on the DMA.
Ok, so that can either be turned into a ramdisk argument, or into a
"we really want to enable non-ramdisk rootfs boots on this hardware
because it's a common use case".
I find it useful to challenge most of the =y drivers to make people
think about it, and at some point we'll enough overhead of cruft in
the static superset kernel that defconfig today is used for such that
we need to prune more =y -> =m, but this particular driver is probably
OK (it's also not large).
> Imho module would be fine for the DMA stack, but neither ringacc or the
> UDMA driver can be built as module atm until the following patches got
> merged:
> https://lore.kernel.org/lkml/20200122104723.16955-1-peter.ujfalusi@ti.com/
> https://lore.kernel.org/lkml/20200122104031.15733-1-peter.ujfalusi@ti.com/
>
> I have the patches to add back module support, but waiting on these
> currently.
-Olof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] arm64: defconfig: Enable Texas Instruments UDMA driver
2020-01-27 15:30 ` Olof Johansson
@ 2020-01-28 8:21 ` Peter Ujfalusi
2020-03-25 14:57 ` Arnd Bergmann
0 siblings, 1 reply; 6+ messages in thread
From: Peter Ujfalusi @ 2020-01-28 8:21 UTC (permalink / raw)
To: Olof Johansson
Cc: Alexandre Belloni, Arnd Bergmann, SoC Team, Catalin Marinas,
Linux Kernel Mailing List, Tero Kristo, Vinod Koul, Will Deacon,
Linux ARM Mailing List
Hi Olof,
On 27/01/2020 17.30, Olof Johansson wrote:
>>> I also see that this is statically enabling this driver -- we try to keep as
>>> many drivers as possible as modules to avoid the static kernel from growing too
>>> large. Would that be a suitable approach here, or is the driver needed to reach
>>> rootfs for further module loading?
>>
>> We would need built in DMA for nfs rootfs, SD/MMC has it's own buit-in
>> ADMA. We do not have network drivers upstream as they depend on the DMA.
>
> Ok, so that can either be turned into a ramdisk argument, or into a
> "we really want to enable non-ramdisk rootfs boots on this hardware
> because it's a common use case".
SD/MMC does not need slave DMA, it is self containing with it's own
built-in DMA.
I'm not sure if it is enabled in defconfig. It is not enabled at all in
defconfig atm.
Normally I would use nfs rootfs, but we don't have network drivers
upstream for K3 platform.
I think having the UDMA stack as module should be fine when I have the
dependencies in to be able to build them as modules.
> I find it useful to challenge most of the =y drivers to make people
> think about it, and at some point we'll enough overhead of cruft in
> the static superset kernel that defconfig today is used for such that
> we need to prune more =y -> =m,
Sure, I fully agree on this, we should have non boot needed drivers as
modules.
> but this particular driver is probably
> OK (it's also not large).
Well, it depends how you look at it ;)
UDMA stack is not enabled in defconfig (w/o this patch):
$ size vmlinux
text data bss dec hex filename
17853717 9221872 469288 27544877 1a44d2d vmlinux
UDMA stack is enabled in defconfig (w this patch):
$ size vmlinux
text data bss dec hex filename
17890970 9237544 469288 27597802 1a51bea vmlinux
It would be nice for other driver to enable the DMA if it is acceptable
to have it built in for start and when I can build it as module we can
switch it to module?
>> Imho module would be fine for the DMA stack, but neither ringacc or the
>> UDMA driver can be built as module atm until the following patches got
>> merged:
>> https://lore.kernel.org/lkml/20200122104723.16955-1-peter.ujfalusi@ti.com/
>> https://lore.kernel.org/lkml/20200122104031.15733-1-peter.ujfalusi@ti.com/
>>
>> I have the patches to add back module support, but waiting on these
>> currently.
>
> -Olof
>
- Péter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] arm64: defconfig: Enable Texas Instruments UDMA driver
2020-01-28 8:21 ` Peter Ujfalusi
@ 2020-03-25 14:57 ` Arnd Bergmann
0 siblings, 0 replies; 6+ messages in thread
From: Arnd Bergmann @ 2020-03-25 14:57 UTC (permalink / raw)
To: Peter Ujfalusi
Cc: Alexandre Belloni, SoC Team, Catalin Marinas,
Linux Kernel Mailing List, Tero Kristo, Vinod Koul,
Olof Johansson, Will Deacon, Linux ARM Mailing List
On Tue, Jan 28, 2020 at 9:20 AM Peter Ujfalusi <peter.ujfalusi@ti.com> wrote:
> On 27/01/2020 17.30, Olof Johansson wrote:
> >>> I also see that this is statically enabling this driver -- we try to keep as
> >>> many drivers as possible as modules to avoid the static kernel from growing too
> >>> large. Would that be a suitable approach here, or is the driver needed to reach
> >>> rootfs for further module loading?
> >>
> >> We would need built in DMA for nfs rootfs, SD/MMC has it's own buit-in
> >> ADMA. We do not have network drivers upstream as they depend on the DMA.
> >
> > Ok, so that can either be turned into a ramdisk argument, or into a
> > "we really want to enable non-ramdisk rootfs boots on this hardware
> > because it's a common use case".
>
> SD/MMC does not need slave DMA, it is self containing with it's own
> built-in DMA.
> I'm not sure if it is enabled in defconfig. It is not enabled at all in
> defconfig atm.
>
> Normally I would use nfs rootfs, but we don't have network drivers
> upstream for K3 platform.
>
> I think having the UDMA stack as module should be fine when I have the
> dependencies in to be able to build them as modules.
Picking up this thread as I noticed the patch is still marked as 'New'
in patchwork.
I see no problem making this driver built-in at all if you want to
respin it.
> > but this particular driver is probably
> > OK (it's also not large).
>
> Well, it depends how you look at it ;)
>
> UDMA stack is not enabled in defconfig (w/o this patch):
> $ size vmlinux
> text data bss dec hex filename
> 17853717 9221872 469288 27544877 1a44d2d vmlinux
>
> UDMA stack is enabled in defconfig (w this patch):
> $ size vmlinux
> text data bss dec hex filename
> 17890970 9237544 469288 27597802 1a51bea vmlinux
>
> It would be nice for other driver to enable the DMA if it is acceptable
> to have it built in for start and when I can build it as module we can
> switch it to module?
In general, I'd prefer to avoid listing references to other drivers
in Kconfig when those are only runtime dependencies rather than
compile-time.
If the network driver just uses the generic dma slave API, then
I would not add a 'depends on' or 'select' for the particular DMA
engine that it uses, unless it relies on nonstandard exported
functions from that driver. Just enable both as modules and have
the runtime module loading along with deferred probe figure out
runtime dependency.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-03-25 14:57 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-01-24 9:23 [PATCH] arm64: defconfig: Enable Texas Instruments UDMA driver Peter Ujfalusi
2020-01-24 20:08 ` Olof Johansson
2020-01-27 10:32 ` Peter Ujfalusi
2020-01-27 15:30 ` Olof Johansson
2020-01-28 8:21 ` Peter Ujfalusi
2020-03-25 14:57 ` Arnd Bergmann
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).