diff mbox

[v2,25/30] dmaengine: tegra-adma: enable COMPILE_TEST

Message ID 1474361960-12434-26-git-send-email-vinod.koul@intel.com (mailing list archive)
State Accepted
Headers show

Commit Message

Vinod Koul Sept. 20, 2016, 8:59 a.m. UTC
To get more coverage, enable COMPILE_TEST for this driver.

Cc: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
---
 drivers/dma/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Jon Hunter Sept. 20, 2016, 11:31 a.m. UTC | #1
On 20/09/16 09:59, Vinod Koul wrote:
> To get more coverage, enable COMPILE_TEST for this driver.
> 
> Cc: Jon Hunter <jonathanh@nvidia.com>
> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
> ---
>  drivers/dma/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
> index 1bf84f246868..835c2ab4268e 100644
> --- a/drivers/dma/Kconfig
> +++ b/drivers/dma/Kconfig
> @@ -482,7 +482,7 @@ config TEGRA20_APB_DMA
>  
>  config TEGRA210_ADMA
>  	bool "NVIDIA Tegra210 ADMA support"
> -	depends on ARCH_TEGRA_210_SOC
> +	depends on ARCH_TEGRA_210_SOC || (ARM && COMPILE_TEST)
>  	select DMA_ENGINE
>  	select DMA_VIRTUAL_CHANNELS
>  	select PM_CLK

I think we should be able the drop the "ARM" dependency. So if
we fix the other compile problem we should end up with ...

 config TEGRA210_ADMA
        bool "NVIDIA Tegra210 ADMA support"
        depends on (ARCH_TEGRA_210_SOC || COMPILE_TEST) && PM_CLK
        select DMA_ENGINE
        select DMA_VIRTUAL_CHANNELS
        help
          Support for the NVIDIA Tegra210 ADMA controller driver. The
          DMA controller has multiple DMA channels and is used to service

Cheers
Jon
Arnd Bergmann Sept. 21, 2016, 9:46 p.m. UTC | #2
On Tuesday, September 20, 2016 2:29:15 PM CEST Vinod Koul wrote:
> To get more coverage, enable COMPILE_TEST for this driver.
> 
> Cc: Jon Hunter <jonathanh@nvidia.com>
> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
> ---
>  drivers/dma/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
> index 1bf84f246868..835c2ab4268e 100644
> --- a/drivers/dma/Kconfig
> +++ b/drivers/dma/Kconfig
> @@ -482,7 +482,7 @@ config TEGRA20_APB_DMA
>  
>  config TEGRA210_ADMA
>  	bool "NVIDIA Tegra210 ADMA support"
> -	depends on ARCH_TEGRA_210_SOC
> +	depends on ARCH_TEGRA_210_SOC || (ARM && COMPILE_TEST)
>  	select DMA_ENGINE
>  	select DMA_VIRTUAL_CHANNELS
>  	select PM_CLK

I think we have to drop the 'select PM_CLK' here:

warning: (ARM_GIC_PM && TEGRA_ACONNECT && TEGRA210_ADMA) selects PM_CLK which has unmet direct dependencies (PM && HAVE_CLK)
0xA55EBB4C Wed Sep 21 18:31:56 CEST 2016 failed
drivers/base/power/clock_ops.o: In function `pm_clk_create':
clock_ops.c:(.text.pm_clk_create+0x0): undefined reference to `dev_pm_get_subsys_data'
drivers/base/power/clock_ops.o: In function `pm_clk_destroy':
clock_ops.c:(.text.pm_clk_destroy+0xb8): undefined reference to `dev_pm_put_subsys_data'
drivers/base/power/clock_ops.o: In function `pm_clk_notify':
clock_ops.c:(.text.pm_clk_notify+0x44): undefined reference to `dev_pm_get_subsys_data'
/git/arm-soc/Makefile:972: recipe for target 'vmlinux' failed

Basically you can never 'select' that symbol unless it's
already enabled, so there is no harm in removing that line.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe dmaengine" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Arnd Bergmann Sept. 21, 2016, 9:57 p.m. UTC | #3
On Wednesday, September 21, 2016 11:46:28 PM CEST Arnd Bergmann wrote:
> > @@ -482,7 +482,7 @@ config TEGRA20_APB_DMA
> >  
> >  config TEGRA210_ADMA
> >       bool "NVIDIA Tegra210 ADMA support"
> > -     depends on ARCH_TEGRA_210_SOC
> > +     depends on ARCH_TEGRA_210_SOC || (ARM && COMPILE_TEST)
> >       select DMA_ENGINE
> >       select DMA_VIRTUAL_CHANNELS
> >       select PM_CLK
> 
> I think we have to drop the 'select PM_CLK' here:
> 
> warning: (ARM_GIC_PM && TEGRA_ACONNECT && TEGRA210_ADMA) selects PM_CLK which has unmet direct dependencies (PM && HAVE_CLK)
> 0xA55EBB4C Wed Sep 21 18:31:56 CEST 2016 failed
> drivers/base/power/clock_ops.o: In function `pm_clk_create':
> clock_ops.c:(.text.pm_clk_create+0x0): undefined reference to `dev_pm_get_subsys_data'
> drivers/base/power/clock_ops.o: In function `pm_clk_destroy':
> clock_ops.c:(.text.pm_clk_destroy+0xb8): undefined reference to `dev_pm_put_subsys_data'
> drivers/base/power/clock_ops.o: In function `pm_clk_notify':
> clock_ops.c:(.text.pm_clk_notify+0x44): undefined reference to `dev_pm_get_subsys_data'
> /git/arm-soc/Makefile:972: recipe for target 'vmlinux' failed
> 
> Basically you can never 'select' that symbol unless it's
> already enabled, so there is no harm in removing that line.
> 

No, it actually needs to be 'depends on PM && HAVE_CLK'. Still testing
if that is sufficient.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe dmaengine" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Vinod Koul Sept. 23, 2016, 3:44 a.m. UTC | #4
On Wed, Sep 21, 2016 at 11:57:54PM +0200, Arnd Bergmann wrote:
> On Wednesday, September 21, 2016 11:46:28 PM CEST Arnd Bergmann wrote:
> > > @@ -482,7 +482,7 @@ config TEGRA20_APB_DMA
> > >  
> > >  config TEGRA210_ADMA
> > >       bool "NVIDIA Tegra210 ADMA support"
> > > -     depends on ARCH_TEGRA_210_SOC
> > > +     depends on ARCH_TEGRA_210_SOC || (ARM && COMPILE_TEST)
> > >       select DMA_ENGINE
> > >       select DMA_VIRTUAL_CHANNELS
> > >       select PM_CLK
> > 
> > I think we have to drop the 'select PM_CLK' here:
> > 
> > warning: (ARM_GIC_PM && TEGRA_ACONNECT && TEGRA210_ADMA) selects PM_CLK which has unmet direct dependencies (PM && HAVE_CLK)
> > 0xA55EBB4C Wed Sep 21 18:31:56 CEST 2016 failed
> > drivers/base/power/clock_ops.o: In function `pm_clk_create':
> > clock_ops.c:(.text.pm_clk_create+0x0): undefined reference to `dev_pm_get_subsys_data'
> > drivers/base/power/clock_ops.o: In function `pm_clk_destroy':
> > clock_ops.c:(.text.pm_clk_destroy+0xb8): undefined reference to `dev_pm_put_subsys_data'
> > drivers/base/power/clock_ops.o: In function `pm_clk_notify':
> > clock_ops.c:(.text.pm_clk_notify+0x44): undefined reference to `dev_pm_get_subsys_data'
> > /git/arm-soc/Makefile:972: recipe for target 'vmlinux' failed
> > 
> > Basically you can never 'select' that symbol unless it's
> > already enabled, so there is no harm in removing that line.
> > 
> 
> No, it actually needs to be 'depends on PM && HAVE_CLK'. Still testing
> if that is sufficient.

Can you confirm if that's sufficient. I would like to merge the series..
Arnd Bergmann Sept. 23, 2016, 8:14 a.m. UTC | #5
On Friday, September 23, 2016 9:14:42 AM CEST Vinod Koul wrote:
> On Wed, Sep 21, 2016 at 11:57:54PM +0200, Arnd Bergmann wrote:
> > On Wednesday, September 21, 2016 11:46:28 PM CEST Arnd Bergmann wrote:
> > > > @@ -482,7 +482,7 @@ config TEGRA20_APB_DMA
> > > >  
> > > >  config TEGRA210_ADMA
> > > >       bool "NVIDIA Tegra210 ADMA support"
> > > > -     depends on ARCH_TEGRA_210_SOC
> > > > +     depends on ARCH_TEGRA_210_SOC || (ARM && COMPILE_TEST)
> > > >       select DMA_ENGINE
> > > >       select DMA_VIRTUAL_CHANNELS
> > > >       select PM_CLK
> > > 
> > > I think we have to drop the 'select PM_CLK' here:
> > > 
> > > warning: (ARM_GIC_PM && TEGRA_ACONNECT && TEGRA210_ADMA) selects PM_CLK which has unmet direct dependencies (PM && HAVE_CLK)
> > > 0xA55EBB4C Wed Sep 21 18:31:56 CEST 2016 failed
> > > drivers/base/power/clock_ops.o: In function `pm_clk_create':
> > > clock_ops.c:(.text.pm_clk_create+0x0): undefined reference to `dev_pm_get_subsys_data'
> > > drivers/base/power/clock_ops.o: In function `pm_clk_destroy':
> > > clock_ops.c:(.text.pm_clk_destroy+0xb8): undefined reference to `dev_pm_put_subsys_data'
> > > drivers/base/power/clock_ops.o: In function `pm_clk_notify':
> > > clock_ops.c:(.text.pm_clk_notify+0x44): undefined reference to `dev_pm_get_subsys_data'
> > > /git/arm-soc/Makefile:972: recipe for target 'vmlinux' failed
> > > 
> > > Basically you can never 'select' that symbol unless it's
> > > already enabled, so there is no harm in removing that line.
> > > 
> > 
> > No, it actually needs to be 'depends on PM && HAVE_CLK'. Still testing
> > if that is sufficient.
> 
> Can you confirm if that's sufficient. I would like to merge the series..
> 


Yes, I've built a few hundred randconfigs overnight, everything succeeds with
that now.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe dmaengine" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jon Hunter Sept. 23, 2016, 9:02 a.m. UTC | #6
On 23/09/16 09:14, Arnd Bergmann wrote:
> On Friday, September 23, 2016 9:14:42 AM CEST Vinod Koul wrote:
>> On Wed, Sep 21, 2016 at 11:57:54PM +0200, Arnd Bergmann wrote:
>>> On Wednesday, September 21, 2016 11:46:28 PM CEST Arnd Bergmann wrote:
>>>>> @@ -482,7 +482,7 @@ config TEGRA20_APB_DMA
>>>>>  
>>>>>  config TEGRA210_ADMA
>>>>>       bool "NVIDIA Tegra210 ADMA support"
>>>>> -     depends on ARCH_TEGRA_210_SOC
>>>>> +     depends on ARCH_TEGRA_210_SOC || (ARM && COMPILE_TEST)
>>>>>       select DMA_ENGINE
>>>>>       select DMA_VIRTUAL_CHANNELS
>>>>>       select PM_CLK
>>>>
>>>> I think we have to drop the 'select PM_CLK' here:
>>>>
>>>> warning: (ARM_GIC_PM && TEGRA_ACONNECT && TEGRA210_ADMA) selects PM_CLK which has unmet direct dependencies (PM && HAVE_CLK)
>>>> 0xA55EBB4C Wed Sep 21 18:31:56 CEST 2016 failed
>>>> drivers/base/power/clock_ops.o: In function `pm_clk_create':
>>>> clock_ops.c:(.text.pm_clk_create+0x0): undefined reference to `dev_pm_get_subsys_data'
>>>> drivers/base/power/clock_ops.o: In function `pm_clk_destroy':
>>>> clock_ops.c:(.text.pm_clk_destroy+0xb8): undefined reference to `dev_pm_put_subsys_data'
>>>> drivers/base/power/clock_ops.o: In function `pm_clk_notify':
>>>> clock_ops.c:(.text.pm_clk_notify+0x44): undefined reference to `dev_pm_get_subsys_data'
>>>> /git/arm-soc/Makefile:972: recipe for target 'vmlinux' failed
>>>>
>>>> Basically you can never 'select' that symbol unless it's
>>>> already enabled, so there is no harm in removing that line.
>>>>
>>>
>>> No, it actually needs to be 'depends on PM && HAVE_CLK'. Still testing
>>> if that is sufficient.
>>
>> Can you confirm if that's sufficient. I would like to merge the series..
>>
> 
> 
> Yes, I've built a few hundred randconfigs overnight, everything succeeds with
> that now.

Please note that 'depends on PM && HAVE_CLK' is equivalent to just
'depends on PM_CLK' and so why not use this? This is what I was
suggesting as an alternative to the fix for patch 26/30 [0].

Cheers
Jon

[0] http://marc.info/?l=dmaengine&m=147437082729864&w=2
Vinod Koul Sept. 26, 2016, 5:24 p.m. UTC | #7
On Fri, Sep 23, 2016 at 10:02:23AM +0100, Jon Hunter wrote:
> 
> On 23/09/16 09:14, Arnd Bergmann wrote:
> > On Friday, September 23, 2016 9:14:42 AM CEST Vinod Koul wrote:
> >> On Wed, Sep 21, 2016 at 11:57:54PM +0200, Arnd Bergmann wrote:
> >>> On Wednesday, September 21, 2016 11:46:28 PM CEST Arnd Bergmann wrote:
> >>>>> @@ -482,7 +482,7 @@ config TEGRA20_APB_DMA
> >>>>>  
> >>>>>  config TEGRA210_ADMA
> >>>>>       bool "NVIDIA Tegra210 ADMA support"
> >>>>> -     depends on ARCH_TEGRA_210_SOC
> >>>>> +     depends on ARCH_TEGRA_210_SOC || (ARM && COMPILE_TEST)
> >>>>>       select DMA_ENGINE
> >>>>>       select DMA_VIRTUAL_CHANNELS
> >>>>>       select PM_CLK
> >>>>
> >>>> I think we have to drop the 'select PM_CLK' here:
> >>>>
> >>>> warning: (ARM_GIC_PM && TEGRA_ACONNECT && TEGRA210_ADMA) selects PM_CLK which has unmet direct dependencies (PM && HAVE_CLK)
> >>>> 0xA55EBB4C Wed Sep 21 18:31:56 CEST 2016 failed
> >>>> drivers/base/power/clock_ops.o: In function `pm_clk_create':
> >>>> clock_ops.c:(.text.pm_clk_create+0x0): undefined reference to `dev_pm_get_subsys_data'
> >>>> drivers/base/power/clock_ops.o: In function `pm_clk_destroy':
> >>>> clock_ops.c:(.text.pm_clk_destroy+0xb8): undefined reference to `dev_pm_put_subsys_data'
> >>>> drivers/base/power/clock_ops.o: In function `pm_clk_notify':
> >>>> clock_ops.c:(.text.pm_clk_notify+0x44): undefined reference to `dev_pm_get_subsys_data'
> >>>> /git/arm-soc/Makefile:972: recipe for target 'vmlinux' failed
> >>>>
> >>>> Basically you can never 'select' that symbol unless it's
> >>>> already enabled, so there is no harm in removing that line.
> >>>>
> >>>
> >>> No, it actually needs to be 'depends on PM && HAVE_CLK'. Still testing
> >>> if that is sufficient.
> >>
> >> Can you confirm if that's sufficient. I would like to merge the series..
> >>
> > 
> > 
> > Yes, I've built a few hundred randconfigs overnight, everything succeeds with
> > that now.
> 
> Please note that 'depends on PM && HAVE_CLK' is equivalent to just
> 'depends on PM_CLK' and so why not use this? This is what I was
> suggesting as an alternative to the fix for patch 26/30 [0].

That's true, I am comitting with 'depends on PM_CLK' now.

Since the other patch doesn't seem to be required, am dropping that one.

Thanks
Vinod Koul Sept. 26, 2016, 5:28 p.m. UTC | #8
On Mon, Sep 26, 2016 at 10:54:21PM +0530, Vinod Koul wrote:
> On Fri, Sep 23, 2016 at 10:02:23AM +0100, Jon Hunter wrote:
> > > 
> > > Yes, I've built a few hundred randconfigs overnight, everything succeeds with
> > > that now.
> > 
> > Please note that 'depends on PM && HAVE_CLK' is equivalent to just
> > 'depends on PM_CLK' and so why not use this? This is what I was
> > suggesting as an alternative to the fix for patch 26/30 [0].
> 
> That's true, I am comitting with 'depends on PM_CLK' now.
> 
> Since the other patch doesn't seem to be required, am dropping that one.

FWIW: here is the diff

@@ -480,10 +480,9 @@ config TEGRA20_APB_DMA

 config TEGRA210_ADMA
        bool "NVIDIA Tegra210 ADMA support"
-       depends on ARCH_TEGRA_210_SOC
+       depends on (ARCH_TEGRA_210_SOC && PM_CLK) || (ARM && COMPILE_TEST)
        select DMA_ENGINE
        select DMA_VIRTUAL_CHANNELS
-       select PM_CLK
        help
          Support for the NVIDIA Tegra210 ADMA controller driver. The
          DMA controller has multiple DMA channels and is used to service
Arnd Bergmann Sept. 26, 2016, 7:13 p.m. UTC | #9
On Monday 26 September 2016, Vinod Koul wrote:
> @@ -480,10 +480,9 @@ config TEGRA20_APB_DMA
> 
>  config TEGRA210_ADMA
>         bool "NVIDIA Tegra210 ADMA support"
> -       depends on ARCH_TEGRA_210_SOC
> +       depends on (ARCH_TEGRA_210_SOC && PM_CLK) || (ARM && COMPILE_TEST)
>         select DMA_ENGINE
>         select DMA_VIRTUAL_CHANNELS
> -       select PM_CLK
>         help

Looks good to me. I haven't done more testing, in case something
unexpected happens I should find it with the build bot later.

	Arnd

--
To unsubscribe from this list: send the line "unsubscribe dmaengine" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jon Hunter Sept. 26, 2016, 7:19 p.m. UTC | #10
On 26/09/16 18:28, Vinod Koul wrote:
> On Mon, Sep 26, 2016 at 10:54:21PM +0530, Vinod Koul wrote:
>> On Fri, Sep 23, 2016 at 10:02:23AM +0100, Jon Hunter wrote:
>>>>
>>>> Yes, I've built a few hundred randconfigs overnight, everything succeeds with
>>>> that now.
>>>
>>> Please note that 'depends on PM && HAVE_CLK' is equivalent to just
>>> 'depends on PM_CLK' and so why not use this? This is what I was
>>> suggesting as an alternative to the fix for patch 26/30 [0].
>>
>> That's true, I am comitting with 'depends on PM_CLK' now.
>>
>> Since the other patch doesn't seem to be required, am dropping that one.
> 
> FWIW: here is the diff
> 
> @@ -480,10 +480,9 @@ config TEGRA20_APB_DMA
> 
>  config TEGRA210_ADMA
>         bool "NVIDIA Tegra210 ADMA support"
> -       depends on ARCH_TEGRA_210_SOC
> +       depends on (ARCH_TEGRA_210_SOC && PM_CLK) || (ARM && COMPILE_TEST)
>         select DMA_ENGINE
>         select DMA_VIRTUAL_CHANNELS
> -       select PM_CLK
>         help
>           Support for the NVIDIA Tegra210 ADMA controller driver. The
>           DMA controller has multiple DMA channels and is used to service

I still think that this is going to cause problems because if !PM_CLK
but (ARM && COMPILE_TEST) then the PM_CLK APIs will still be undefined.
I believe I mentioned this before, but I think all we need is ...

 config TEGRA210_ADMA
        bool "NVIDIA Tegra210 ADMA support"
        depends on (ARCH_TEGRA_210_SOC || COMPILE_TEST) && PM_CLK
        select DMA_ENGINE
        select DMA_VIRTUAL_CHANNELS
        help
          Support for the NVIDIA Tegra210 ADMA controller driver. The
          DMA controller has multiple DMA channels and is used to service

Cheers
Jon
Jon Hunter Sept. 26, 2016, 7:32 p.m. UTC | #11
On 26/09/16 18:28, Vinod Koul wrote:
> On Mon, Sep 26, 2016 at 10:54:21PM +0530, Vinod Koul wrote:
>> On Fri, Sep 23, 2016 at 10:02:23AM +0100, Jon Hunter wrote:
>>>>
>>>> Yes, I've built a few hundred randconfigs overnight, everything succeeds with
>>>> that now.
>>>
>>> Please note that 'depends on PM && HAVE_CLK' is equivalent to just
>>> 'depends on PM_CLK' and so why not use this? This is what I was
>>> suggesting as an alternative to the fix for patch 26/30 [0].
>>
>> That's true, I am comitting with 'depends on PM_CLK' now.
>>
>> Since the other patch doesn't seem to be required, am dropping that one.
> 
> FWIW: here is the diff
> 
> @@ -480,10 +480,9 @@ config TEGRA20_APB_DMA
> 
>  config TEGRA210_ADMA
>         bool "NVIDIA Tegra210 ADMA support"
> -       depends on ARCH_TEGRA_210_SOC
> +       depends on (ARCH_TEGRA_210_SOC && PM_CLK) || (ARM && COMPILE_TEST)
>         select DMA_ENGINE
>         select DMA_VIRTUAL_CHANNELS
> -       select PM_CLK
>         help
>           Support for the NVIDIA Tegra210 ADMA controller driver. The
>           DMA controller has multiple DMA channels and is used to service
> 

I was still able to generate the following compile error for ARM if !PM and COMPILE_TEST enabled.

  CC      drivers/dma/tegra210-adma.o
In file included from ./include/uapi/linux/posix_types.h:4:0,
                 from include/uapi/linux/types.h:13,
                 from include/linux/compiler.h:203,
                 from include/linux/err.h:4,
                 from include/linux/clk.h:15,
                 from drivers/dma/tegra210-adma.c:19:
drivers/dma/tegra210-adma.c: In function 'tegra_adma_runtime_suspend':
include/linux/stddef.h:7:14: error: called object is not a function or function pointer
 #define NULL ((void *)0)
              ^
include/linux/pm_clock.h:81:24: note: in expansion of macro 'NULL'
 #define pm_clk_suspend NULL
                        ^
drivers/dma/tegra210-adma.c:641:9: note: in expansion of macro 'pm_clk_suspend'
  return pm_clk_suspend(dev);
         ^
drivers/dma/tegra210-adma.c: In function 'tegra_adma_runtime_resume':
include/linux/stddef.h:7:14: error: called object is not a function or function pointer
 #define NULL ((void *)0)
              ^
include/linux/pm_clock.h:82:23: note: in expansion of macro 'NULL'
 #define pm_clk_resume NULL
                       ^
drivers/dma/tegra210-adma.c:649:8: note: in expansion of macro 'pm_clk_resume'
  ret = pm_clk_resume(dev);
        ^
drivers/dma/tegra210-adma.c: At top level:
drivers/dma/tegra210-adma.c:635:12: warning: 'tegra_adma_runtime_suspend' defined but not used [-Wunused-function]
 static int tegra_adma_runtime_suspend(struct device *dev)
            ^
drivers/dma/tegra210-adma.c:644:12: warning: 'tegra_adma_runtime_resume' defined but not used [-Wunused-function]
 static int tegra_adma_runtime_resume(struct device *dev)
            ^
make[2]: *** [drivers/dma/tegra210-adma.o] Error 1
make[1]: *** [drivers/dma] Error 2
make: *** [drivers] Error 2

Jon
Vinod Koul Sept. 27, 2016, 5:10 a.m. UTC | #12
On Mon, Sep 26, 2016 at 08:32:37PM +0100, Jon Hunter wrote:
> 
> On 26/09/16 18:28, Vinod Koul wrote:
> > On Mon, Sep 26, 2016 at 10:54:21PM +0530, Vinod Koul wrote:
> >> On Fri, Sep 23, 2016 at 10:02:23AM +0100, Jon Hunter wrote:
> >>>>
> >>>> Yes, I've built a few hundred randconfigs overnight, everything succeeds with
> >>>> that now.
> >>>
> >>> Please note that 'depends on PM && HAVE_CLK' is equivalent to just
> >>> 'depends on PM_CLK' and so why not use this? This is what I was
> >>> suggesting as an alternative to the fix for patch 26/30 [0].
> >>
> >> That's true, I am comitting with 'depends on PM_CLK' now.
> >>
> >> Since the other patch doesn't seem to be required, am dropping that one.
> > 
> > FWIW: here is the diff
> > 
> > @@ -480,10 +480,9 @@ config TEGRA20_APB_DMA
> > 
> >  config TEGRA210_ADMA
> >         bool "NVIDIA Tegra210 ADMA support"
> > -       depends on ARCH_TEGRA_210_SOC
> > +       depends on (ARCH_TEGRA_210_SOC && PM_CLK) || (ARM && COMPILE_TEST)
> >         select DMA_ENGINE
> >         select DMA_VIRTUAL_CHANNELS
> > -       select PM_CLK
> >         help
> >           Support for the NVIDIA Tegra210 ADMA controller driver. The
> >           DMA controller has multiple DMA channels and is used to service
> > 
> 
> I was still able to generate the following compile error for ARM if !PM and COMPILE_TEST enabled.

Thanks for checking, I was able to replicate it and it is fixed by your
suggestion.
I have updated it now

Thanks

> 
>   CC      drivers/dma/tegra210-adma.o
> In file included from ./include/uapi/linux/posix_types.h:4:0,
>                  from include/uapi/linux/types.h:13,
>                  from include/linux/compiler.h:203,
>                  from include/linux/err.h:4,
>                  from include/linux/clk.h:15,
>                  from drivers/dma/tegra210-adma.c:19:
> drivers/dma/tegra210-adma.c: In function 'tegra_adma_runtime_suspend':
> include/linux/stddef.h:7:14: error: called object is not a function or function pointer
>  #define NULL ((void *)0)
>               ^
> include/linux/pm_clock.h:81:24: note: in expansion of macro 'NULL'
>  #define pm_clk_suspend NULL
>                         ^
> drivers/dma/tegra210-adma.c:641:9: note: in expansion of macro 'pm_clk_suspend'
>   return pm_clk_suspend(dev);
>          ^
> drivers/dma/tegra210-adma.c: In function 'tegra_adma_runtime_resume':
> include/linux/stddef.h:7:14: error: called object is not a function or function pointer
>  #define NULL ((void *)0)
>               ^
> include/linux/pm_clock.h:82:23: note: in expansion of macro 'NULL'
>  #define pm_clk_resume NULL
>                        ^
> drivers/dma/tegra210-adma.c:649:8: note: in expansion of macro 'pm_clk_resume'
>   ret = pm_clk_resume(dev);
>         ^
> drivers/dma/tegra210-adma.c: At top level:
> drivers/dma/tegra210-adma.c:635:12: warning: 'tegra_adma_runtime_suspend' defined but not used [-Wunused-function]
>  static int tegra_adma_runtime_suspend(struct device *dev)
>             ^
> drivers/dma/tegra210-adma.c:644:12: warning: 'tegra_adma_runtime_resume' defined but not used [-Wunused-function]
>  static int tegra_adma_runtime_resume(struct device *dev)
>             ^
> make[2]: *** [drivers/dma/tegra210-adma.o] Error 1
> make[1]: *** [drivers/dma] Error 2
> make: *** [drivers] Error 2
> 
> Jon
> 
> -- 
> nvpublic
> --
> To unsubscribe from this list: send the line "unsubscribe dmaengine" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 1bf84f246868..835c2ab4268e 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -482,7 +482,7 @@  config TEGRA20_APB_DMA
 
 config TEGRA210_ADMA
 	bool "NVIDIA Tegra210 ADMA support"
-	depends on ARCH_TEGRA_210_SOC
+	depends on ARCH_TEGRA_210_SOC || (ARM && COMPILE_TEST)
 	select DMA_ENGINE
 	select DMA_VIRTUAL_CHANNELS
 	select PM_CLK