[PATCH 1/2] dmaengine: sh: Do not enable SH_DMAE_BASE by default during compile testing

[PATCH 1/2] dmaengine: sh: Do not enable SH_DMAE_BASE by default during compile testing

[Krzysztof Kozlowski]

Enabling the compile test should not cause automatic enabling of all
drivers.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
 drivers/dma/sh/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/sh/Kconfig b/drivers/dma/sh/Kconfig
index 6ea5a880b433..8184d475a49a 100644
--- a/drivers/dma/sh/Kconfig
+++ b/drivers/dma/sh/Kconfig
@@ -16,7 +16,7 @@ config SH_DMAE_BASE
 	depends on SUPERH || COMPILE_TEST
 	depends on !SUPERH || SH_DMA
 	depends on !SH_DMA_API
-	default y
+	default SUPERH || SH_DMA
 	select RENESAS_DMA
 	help
 	  Enable support for the Renesas SuperH DMA controllers.
-- 
2.45.2

[PATCH 2/2] dmaengine: ti: Do not enable by default during compile testing

[Krzysztof Kozlowski]

Enabling the compile test should not cause automatic enabling of all
drivers.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
 drivers/dma/ti/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/ti/Kconfig b/drivers/dma/ti/Kconfig
index 2adc2cca10e9..dbf168146d35 100644
--- a/drivers/dma/ti/Kconfig
+++ b/drivers/dma/ti/Kconfig
@@ -17,7 +17,7 @@ config TI_EDMA
 	select DMA_ENGINE
 	select DMA_VIRTUAL_CHANNELS
 	select TI_DMA_CROSSBAR if (ARCH_OMAP || COMPILE_TEST)
-	default y
+	default ARCH_DAVINCI || ARCH_OMAP || ARCH_KEYSTONE
 	help
 	  Enable support for the TI EDMA (Enhanced DMA) controller. This DMA
 	  engine is found on TI DaVinci, AM33xx, AM43xx, DRA7xx and Keystone 2
@@ -29,7 +29,7 @@ config DMA_OMAP
 	select DMA_ENGINE
 	select DMA_VIRTUAL_CHANNELS
 	select TI_DMA_CROSSBAR if (SOC_DRA7XX || COMPILE_TEST)
-	default y
+	default ARCH_OMAP
 	help
 	  Enable support for the TI sDMA (System DMA or DMA4) controller. This
 	  DMA engine is found on OMAP and DRA7xx parts.
-- 
2.45.2

Re: [PATCH 2/2] dmaengine: ti: Do not enable by default during compile testing

[Péter Ujfalusi]

On 4/4/25 3:21 PM, Krzysztof Kozlowski wrote:
> Enabling the compile test should not cause automatic enabling of all
> drivers.

The scope of compile test has changed?
These drivers will likely not going to be compile tested from now on in
practice on other that the platforms they are used?

It gave a piece of mind to know that the code compiles on ppc/x86/etc
also or it is no longer important sanity check?

> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> ---
>  drivers/dma/ti/Kconfig | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/dma/ti/Kconfig b/drivers/dma/ti/Kconfig
> index 2adc2cca10e9..dbf168146d35 100644
> --- a/drivers/dma/ti/Kconfig
> +++ b/drivers/dma/ti/Kconfig
> @@ -17,7 +17,7 @@ config TI_EDMA
>  	select DMA_ENGINE
>  	select DMA_VIRTUAL_CHANNELS
>  	select TI_DMA_CROSSBAR if (ARCH_OMAP || COMPILE_TEST)
> -	default y
> +	default ARCH_DAVINCI || ARCH_OMAP || ARCH_KEYSTONE
>  	help
>  	  Enable support for the TI EDMA (Enhanced DMA) controller. This DMA
>  	  engine is found on TI DaVinci, AM33xx, AM43xx, DRA7xx and Keystone 2
> @@ -29,7 +29,7 @@ config DMA_OMAP
>  	select DMA_ENGINE
>  	select DMA_VIRTUAL_CHANNELS
>  	select TI_DMA_CROSSBAR if (SOC_DRA7XX || COMPILE_TEST)
> -	default y
> +	default ARCH_OMAP
>  	help
>  	  Enable support for the TI sDMA (System DMA or DMA4) controller. This
>  	  DMA engine is found on OMAP and DRA7xx parts.

-- 
Péter

Re: [PATCH 2/2] dmaengine: ti: Do not enable by default during compile testing

[Krzysztof Kozlowski]

On 06/04/2025 18:08, Péter Ujfalusi wrote:
> 
> 
> On 4/4/25 3:21 PM, Krzysztof Kozlowski wrote:
>> Enabling the compile test should not cause automatic enabling of all
>> drivers.
> 
> The scope of compile test has changed?

No, it's the same.

> These drivers will likely not going to be compile tested from now on in

Why? They are. That's why allyesconfig you have.

> practice on other that the platforms they are used?
> 
> It gave a piece of mind to know that the code compiles on ppc/x86/etc
> also or it is no longer important sanity check?

And nothing changes here. They will be compile tested on all these other
archs the same as all other arch/soc specific drivers, which do exactly
what I am doing here.

Best regards,
Krzysztof

Re: [PATCH 1/2] dmaengine: sh: Do not enable SH_DMAE_BASE by default during compile testing

[Krzysztof Kozlowski]

On 04/04/2025 14:21, Krzysztof Kozlowski wrote:
> Enabling the compile test should not cause automatic enabling of all
> drivers.
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> ---
>  drivers/dma/sh/Kconfig | 2 +-

Ping, can this be applied?

Best regards,
Krzysztof

Re: [PATCH 1/2] dmaengine: sh: Do not enable SH_DMAE_BASE by default during compile testing

[Vinod Koul]

On Fri, 04 Apr 2025 14:21:13 +0200, Krzysztof Kozlowski wrote:
> Enabling the compile test should not cause automatic enabling of all
> drivers.
> 
> 

Applied, thanks!

[1/2] dmaengine: sh: Do not enable SH_DMAE_BASE by default during compile testing
      commit: 587dd30449fb10121fc8a319bb825dc6152b8dd5
[2/2] dmaengine: ti: Do not enable by default during compile testing
      commit: ddf16e16346a36ec6616e5282f675f2e3cdc826f

Best regards,
-- 
~Vinod

Re: [PATCH 1/2] dmaengine: sh: Do not enable SH_DMAE_BASE by default during compile testing

[Geert Uytterhoeven]

CC linux-sh

Hi Krzysztof,

On Fri, 4 Apr 2025 at 14:22, Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
> Enabling the compile test should not cause automatic enabling of all
> drivers.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

Thanks for your patch, which is now commit 587dd30449fb1012
("dmaengine: sh: Do not enable SH_DMAE_BASE by default during
compile testing") in dmaengine/next.

> --- a/drivers/dma/sh/Kconfig
> +++ b/drivers/dma/sh/Kconfig
> @@ -16,7 +16,7 @@ config SH_DMAE_BASE
>         depends on SUPERH || COMPILE_TEST
>         depends on !SUPERH || SH_DMA
>         depends on !SH_DMA_API
> -       default y
> +       default SUPERH || SH_DMA

I think the check for SUPERH is superfluous, due to the dependency on
"!SUPERH || SH_DMA" above.

>         select RENESAS_DMA
>         help
>           Enable support for the Renesas SuperH DMA controllers.

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

Re: [PATCH 1/2] dmaengine: sh: Do not enable SH_DMAE_BASE by default during compile testing

[Krzysztof Kozlowski]

On 08/07/2025 15:07, Geert Uytterhoeven wrote:
> CC linux-sh
> 
> Hi Krzysztof,
> 
> On Fri, 4 Apr 2025 at 14:22, Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org> wrote:
>> Enabling the compile test should not cause automatic enabling of all
>> drivers.
>>
>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> 
> Thanks for your patch, which is now commit 587dd30449fb1012
> ("dmaengine: sh: Do not enable SH_DMAE_BASE by default during
> compile testing") in dmaengine/next.
> 
>> --- a/drivers/dma/sh/Kconfig
>> +++ b/drivers/dma/sh/Kconfig
>> @@ -16,7 +16,7 @@ config SH_DMAE_BASE
>>         depends on SUPERH || COMPILE_TEST
>>         depends on !SUPERH || SH_DMA
>>         depends on !SH_DMA_API
>> -       default y
>> +       default SUPERH || SH_DMA
> 
> I think the check for SUPERH is superfluous, due to the dependency on
> "!SUPERH || SH_DMA" above.
> 

Indeed it might be, but I must admit I don't understand the dependencies
here at all. I think commit 9f2c2bb31258 ("dmaengine: sh: Rework Kconfig
and Makefile") from Laurent made it confusing and this later just grew
to even more confusing.

What is the intention for "depends on"? This should be enabled when
SUPERH AND SH_DMA are enabled?

SH_DMA cannot be enabled without SUPERH (no compile test), right? But
this "depends on !SUPERH || SH_DMA" suggests it could be. This should be
read for humans as "if not SUPERH, then require at least SH_DMA".
Otherwise what is the meaning for humans? This driver will work fine
without SUERPH?

My change for default could be rewritten but I don't understand the goal
behind current depends, so not sure how should I rewrite it.

Best regards,
Krzysztof

Re: [PATCH 1/2] dmaengine: sh: Do not enable SH_DMAE_BASE by default during compile testing

[Geert Uytterhoeven]

Hi Krzysztof,

On Tue, 8 Jul 2025 at 15:21, Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
> On 08/07/2025 15:07, Geert Uytterhoeven wrote:
> > On Fri, 4 Apr 2025 at 14:22, Krzysztof Kozlowski
> > <krzysztof.kozlowski@linaro.org> wrote:
> >> Enabling the compile test should not cause automatic enabling of all
> >> drivers.
> >>
> >> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> >
> > Thanks for your patch, which is now commit 587dd30449fb1012
> > ("dmaengine: sh: Do not enable SH_DMAE_BASE by default during
> > compile testing") in dmaengine/next.
> >
> >> --- a/drivers/dma/sh/Kconfig
> >> +++ b/drivers/dma/sh/Kconfig
> >> @@ -16,7 +16,7 @@ config SH_DMAE_BASE
> >>         depends on SUPERH || COMPILE_TEST
> >>         depends on !SUPERH || SH_DMA
> >>         depends on !SH_DMA_API
> >> -       default y
> >> +       default SUPERH || SH_DMA
> >
> > I think the check for SUPERH is superfluous, due to the dependency on
> > "!SUPERH || SH_DMA" above.
>
> Indeed it might be, but I must admit I don't understand the dependencies
> here at all. I think commit 9f2c2bb31258 ("dmaengine: sh: Rework Kconfig
> and Makefile") from Laurent made it confusing and this later just grew
> to even more confusing.
>
> What is the intention for "depends on"? This should be enabled when
> SUPERH AND SH_DMA are enabled?
>
> SH_DMA cannot be enabled without SUPERH (no compile test), right? But
> this "depends on !SUPERH || SH_DMA" suggests it could be. This should be
> read for humans as "if not SUPERH, then require at least SH_DMA".
> Otherwise what is the meaning for humans? This driver will work fine
> without SUERPH?
>
> My change for default could be rewritten but I don't understand the goal
> behind current depends, so not sure how should I rewrite it.

I think the original plan was to use the SH DMA drivers on ARM SH-Mobile
SoCs, too.  But enabling SH_DMA on ARM SH-Mobile was never integrated
upstream, and the focus shifted to ARM R-Car SoCs, for which the shiny new
R-Car DMA driver was written...

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