[PATCH 02/22] clocksource/drivers/mediatek: Add the COMPILE_TEST option

[PATCH 02/22] clocksource/drivers/mediatek: Add the COMPILE_TEST option

[Daniel Lezcano]

Increase the compilation test coverage by adding the COMPILE_TEST option.

Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
---
 drivers/clocksource/Kconfig | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index a1c9312..dc79fde 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -210,9 +210,11 @@ config SYS_SUPPORTS_SH_CMT
         bool
 
 config MTK_TIMER
+	bool "Mediatek timer driver" if COMPILE_TEST
 	select CLKSRC_OF
 	select CLKSRC_MMIO
-	bool
+	help
+	  Support for Mediatek timer driver.
 
 config SYS_SUPPORTS_SH_MTU2
         bool
-- 
1.9.1

[PATCH 03/22] clocksource/drivers/rockchip: Make the driver more compatible

[Daniel Lezcano]

From: Caesar Wang <wxt@rock-chips.com>

Build the arm64 SoCs (e.g.: RK3368) on Rockchip platform,
There are some failure with build up on timer driver for rockchip.

Says:
/tmp/ccdAnNy5.s:47: Error: missing immediate expression at  operand 1 --
`dsb`
...

The problem was different semantics of dsb on btw arm32 and arm64,
Here we can convert the dsb with insteading of dsb(sy).The "sy" param
is the default which you are allow to omit, so on arm32 dsb()and dsb(sy)
are the same.

Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
---
 drivers/clocksource/rockchip_timer.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/clocksource/rockchip_timer.c b/drivers/clocksource/rockchip_timer.c
index d3c1742..724c321 100644
--- a/drivers/clocksource/rockchip_timer.c
+++ b/drivers/clocksource/rockchip_timer.c
@@ -49,14 +49,14 @@ static inline void __iomem *rk_base(struct clock_event_device *ce)
 static inline void rk_timer_disable(struct clock_event_device *ce)
 {
 	writel_relaxed(TIMER_DISABLE, rk_base(ce) + TIMER_CONTROL_REG);
-	dsb();
+	dsb(sy);
 }
 
 static inline void rk_timer_enable(struct clock_event_device *ce, u32 flags)
 {
 	writel_relaxed(TIMER_ENABLE | TIMER_INT_UNMASK | flags,
 		       rk_base(ce) + TIMER_CONTROL_REG);
-	dsb();
+	dsb(sy);
 }
 
 static void rk_timer_update_counter(unsigned long cycles,
@@ -64,13 +64,13 @@ static void rk_timer_update_counter(unsigned long cycles,
 {
 	writel_relaxed(cycles, rk_base(ce) + TIMER_LOAD_COUNT0);
 	writel_relaxed(0, rk_base(ce) + TIMER_LOAD_COUNT1);
-	dsb();
+	dsb(sy);
 }
 
 static void rk_timer_interrupt_clear(struct clock_event_device *ce)
 {
 	writel_relaxed(1, rk_base(ce) + TIMER_INT_STATUS);
-	dsb();
+	dsb(sy);
 }
 
 static inline int rk_timer_set_next_event(unsigned long cycles,
-- 
1.9.1

[PATCH 03/22] clocksource/drivers/rockchip: Make the driver more compatible

[Arnd Bergmann]

On Monday 02 November 2015 13:56:31 Daniel Lezcano wrote:
>  static inline void rk_timer_disable(struct clock_event_device *ce)
>  {
>         writel_relaxed(TIMER_DISABLE, rk_base(ce) + TIMER_CONTROL_REG);
> -       dsb();
> +       dsb(sy);
>  }
>  
>  static inline void rk_timer_enable(struct clock_event_device *ce, u32 flags)
>  {
>         writel_relaxed(TIMER_ENABLE | TIMER_INT_UNMASK | flags,
>                        rk_base(ce) + TIMER_CONTROL_REG);
> -       dsb();
> +       dsb(sy);
>  }
>  
> 

This will fail the compile test, because dsb() is not available on non-ARM
architectures. Would it be enough to just use the normal writel() accessor
here?

	Arnd

[PATCH 03/22] clocksource/drivers/rockchip: Make the driver more compatible

[Daniel Lezcano]

On 11/02/2015 04:33 PM, Arnd Bergmann wrote:
> On Monday 02 November 2015 13:56:31 Daniel Lezcano wrote:
>>   static inline void rk_timer_disable(struct clock_event_device *ce)
>>   {
>>          writel_relaxed(TIMER_DISABLE, rk_base(ce) + TIMER_CONTROL_REG);
>> -       dsb();
>> +       dsb(sy);
>>   }
>>
>>   static inline void rk_timer_enable(struct clock_event_device *ce, u32 flags)
>>   {
>>          writel_relaxed(TIMER_ENABLE | TIMER_INT_UNMASK | flags,
>>                         rk_base(ce) + TIMER_CONTROL_REG);
>> -       dsb();
>> +       dsb(sy);
>>   }
>>
>>
>
> This will fail the compile test, because dsb() is not available on non-ARM
> architectures. Would it be enough to just use the normal writel() accessor
> here?

That's a good question and I believe we can remove it but I have to 
setup a rockchip board before doing the changes in order to test.

I the meantime added the COMPILE_TEST option but restricted it to ARM 
and ARM64.



-- 
  <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

[PATCH 03/22] clocksource/drivers/rockchip: Make the driver more compatible

[Arnd Bergmann]

On Monday 02 November 2015 17:32:22 Daniel Lezcano wrote:
> On 11/02/2015 04:33 PM, Arnd Bergmann wrote:
> > On Monday 02 November 2015 13:56:31 Daniel Lezcano wrote:
> >>   static inline void rk_timer_disable(struct clock_event_device *ce)
> >>   {
> >>          writel_relaxed(TIMER_DISABLE, rk_base(ce) + TIMER_CONTROL_REG);
> >> -       dsb();
> >> +       dsb(sy);
> >>   }
> >>
> >>   static inline void rk_timer_enable(struct clock_event_device *ce, u32 flags)
> >>   {
> >>          writel_relaxed(TIMER_ENABLE | TIMER_INT_UNMASK | flags,
> >>                         rk_base(ce) + TIMER_CONTROL_REG);
> >> -       dsb();
> >> +       dsb(sy);
> >>   }
> >>
> >>
> >
> > This will fail the compile test, because dsb() is not available on non-ARM
> > architectures. Would it be enough to just use the normal writel() accessor
> > here?
> 
> That's a good question and I believe we can remove it but I have to 
> setup a rockchip board before doing the changes in order to test.
> 
> I the meantime added the COMPILE_TEST option but restricted it to ARM 
> and ARM64.
> 

Ok. I saw that addition after commenting here, it looks correct this
way, I was just slightly confused by seeing patch 2 first and thought
it was for the same driver.

In general, it would of course be best to allow all drivers to be built
on x86, but your series is already a huge improvement as it is.

	Arnd

[PATCH 13/22] clocksource/drivers/vt8500: Remove unneeded header

[Daniel Lezcano]

Remove the <asm/time.h> header inclusion which is pointless.

Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
---
 drivers/clocksource/vt8500_timer.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/clocksource/vt8500_timer.c b/drivers/clocksource/vt8500_timer.c
index a92e94b..de49805 100644
--- a/drivers/clocksource/vt8500_timer.c
+++ b/drivers/clocksource/vt8500_timer.c
@@ -30,7 +30,6 @@
 #include <linux/clocksource.h>
 #include <linux/clockchips.h>
 #include <linux/delay.h>
-#include <asm/mach/time.h>
 
 #include <linux/of.h>
 #include <linux/of_address.h>
-- 
1.9.1

[PATCH 19/22] clocksource/drivers/prcmu: Fix Kconfig and add COMPILE_TEST option

[Daniel Lezcano]

Let the platform's Kconfig to select the clock instead of having a reverse
dependency from the driver to the platform options.

Add the COMPILE_TEST option for the compilation test coverage.

This change is debatable as the option itself in the Kconfig allows to
select the driver for the platform or not. This change will make the prcmu
timer always selected.

Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
---
 arch/arm/mach-ux500/Kconfig | 1 +
 drivers/clocksource/Kconfig | 4 +---
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-ux500/Kconfig b/arch/arm/mach-ux500/Kconfig
index c9ac19b..5eacdd6 100644
--- a/arch/arm/mach-ux500/Kconfig
+++ b/arch/arm/mach-ux500/Kconfig
@@ -32,6 +32,7 @@ config UX500_SOC_DB8500
 	select PINCTRL_AB8540
 	select REGULATOR
 	select REGULATOR_DB8500_PRCMU
+	select CLKSRC_DBX500_PRCMU
 	select PM_GENERIC_DOMAINS if PM
 
 config MACH_MOP500
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 17674b4..916c36d 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -114,9 +114,7 @@ config CLKSRC_NOMADIK_MTU_SCHED_CLOCK
 	  Use the Multi Timer Unit as the sched_clock.
 
 config CLKSRC_DBX500_PRCMU
-	bool "Clocksource PRCMU Timer"
-	depends on UX500_SOC_DB8500
-	default y
+	bool "Clocksource PRCMU Timer" if COMPILE_TEST
 	help
 	  Use the always on PRCMU Timer as clocksource
 
-- 
1.9.1

[PATCH 19/22] clocksource/drivers/prcmu: Fix Kconfig and add COMPILE_TEST option

[Linus Walleij]

On Mon, Nov 2, 2015 at 1:56 PM, Daniel Lezcano
<daniel.lezcano@linaro.org> wrote:

> Let the platform's Kconfig to select the clock instead of having a reverse
> dependency from the driver to the platform options.
>
> Add the COMPILE_TEST option for the compilation test coverage.
>
> This change is debatable as the option itself in the Kconfig allows to
> select the driver for the platform or not. This change will make the prcmu
> timer always selected.
>
> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>

Acked-by: Linus Walleij <linus.walleij@linaro.org>

Please merge this into the clksrc tree.

Yours,
Linus Walleij

[PATCH 19/22] clocksource/drivers/prcmu: Fix Kconfig and add COMPILE_TEST option

[Daniel Lezcano]

On 11/02/2015 03:40 PM, Linus Walleij wrote:
> On Mon, Nov 2, 2015 at 1:56 PM, Daniel Lezcano
> <daniel.lezcano@linaro.org> wrote:
>
>> Let the platform's Kconfig to select the clock instead of having a reverse
>> dependency from the driver to the platform options.
>>
>> Add the COMPILE_TEST option for the compilation test coverage.
>>
>> This change is debatable as the option itself in the Kconfig allows to
>> select the driver for the platform or not. This change will make the prcmu
>> timer always selected.
>>
>> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>
> Please merge this into the clksrc tree.

Thanks for the review.

   -- Daniel


-- 
  <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

[PATCH 20/22] clocksource/drivers/exynos_mct: Fix Kconfig and add COMPILE_TEST option

[Daniel Lezcano]

Let the platform's Kconfig to select the clock instead of having a reverse
dependency from the driver to the platform options.

Add the COMPILE_TEST option for the compilation test coverage. Due to the
non portable 'delay' code, this driver is only compilable on ARM.

Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
---
 arch/arm/mach-exynos/Kconfig | 1 +
 drivers/clocksource/Kconfig  | 4 ++--
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 3a10f1a..ff10539 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -27,6 +27,7 @@ menuconfig ARCH_EXYNOS
 	select SRAM
 	select THERMAL
 	select MFD_SYSCON
+	select CLKSRC_EXYNOS_MCT
 	help
 	  Support for SAMSUNG EXYNOS SoCs (EXYNOS4/5)
 
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 916c36d..d829cbe 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -213,8 +213,8 @@ config CLKSRC_METAG_GENERIC
 	  This option enables support for the Meta per-thread timers.
 
 config CLKSRC_EXYNOS_MCT
-	def_bool y if ARCH_EXYNOS
-	depends on !ARM64
+	bool "Exynos multi core timer driver" if COMPILE_TEST
+	depends on ARM
 	help
 	  Support for Multi Core Timer controller on Exynos SoCs.
 
-- 
1.9.1

[PATCH 20/22] clocksource/drivers/exynos_mct: Fix Kconfig and add COMPILE_TEST option

[Krzysztof Kozlowski]

On 02.11.2015 21:56, Daniel Lezcano wrote:
> Let the platform's Kconfig to select the clock instead of having a reverse
> dependency from the driver to the platform options.

Selecting user-visible symbols is rather discouraged so why not
something like this:

-       def_bool y if ARCH_EXYNOS
-       depends on !ARM64
+       bool "Exynos multi core timer driver"
+       depends on ARCH_EXYNOS || (COMPILE_TEST && ARM)

Best regards,
Krzysztof

> 
> Add the COMPILE_TEST option for the compilation test coverage. Due to the
> non portable 'delay' code, this driver is only compilable on ARM.
> 
> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> ---
>  arch/arm/mach-exynos/Kconfig | 1 +
>  drivers/clocksource/Kconfig  | 4 ++--
>  2 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
> index 3a10f1a..ff10539 100644
> --- a/arch/arm/mach-exynos/Kconfig
> +++ b/arch/arm/mach-exynos/Kconfig
> @@ -27,6 +27,7 @@ menuconfig ARCH_EXYNOS
>  	select SRAM
>  	select THERMAL
>  	select MFD_SYSCON
> +	select CLKSRC_EXYNOS_MCT
>  	help
>  	  Support for SAMSUNG EXYNOS SoCs (EXYNOS4/5)
>  
> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> index 916c36d..d829cbe 100644
> --- a/drivers/clocksource/Kconfig
> +++ b/drivers/clocksource/Kconfig
> @@ -213,8 +213,8 @@ config CLKSRC_METAG_GENERIC
>  	  This option enables support for the Meta per-thread timers.
>  
>  config CLKSRC_EXYNOS_MCT
> -	def_bool y if ARCH_EXYNOS
> -	depends on !ARM64
> +	bool "Exynos multi core timer driver" if COMPILE_TEST
> +	depends on ARM
>  	help
>  	  Support for Multi Core Timer controller on Exynos SoCs.
>  
> 

[PATCH 20/22] clocksource/drivers/exynos_mct: Fix Kconfig and add COMPILE_TEST option

[Krzysztof Kozlowski]

On 03.11.2015 09:30, Krzysztof Kozlowski wrote:
> On 02.11.2015 21:56, Daniel Lezcano wrote:
>> Let the platform's Kconfig to select the clock instead of having a reverse
>> dependency from the driver to the platform options.
> 
> Selecting user-visible symbols is rather discouraged so why not
> something like this:
> 
> -       def_bool y if ARCH_EXYNOS
> -       depends on !ARM64
> +       bool "Exynos multi core timer driver"
> +       depends on ARCH_EXYNOS || (COMPILE_TEST && ARM)

Nope, that was wrong as we loose auto-select on Exynos. Instead:
-       def_bool y if ARCH_EXYNOS
-       depends on !ARM64
+       bool "Exynos multi core timer driver" if ARM
+       depends on ARCH_EXYNOS || COMPILE_TEST
+       default y if ARCH_EXYNOS

This way we avoid select (which is a reverse dependency for the driver),
have it auto-selectable and compile tested on arm.

Best regards,
Krzysztof

> 
>>
>> Add the COMPILE_TEST option for the compilation test coverage. Due to the
>> non portable 'delay' code, this driver is only compilable on ARM.
>>
>> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
>> ---
>>  arch/arm/mach-exynos/Kconfig | 1 +
>>  drivers/clocksource/Kconfig  | 4 ++--
>>  2 files changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
>> index 3a10f1a..ff10539 100644
>> --- a/arch/arm/mach-exynos/Kconfig
>> +++ b/arch/arm/mach-exynos/Kconfig
>> @@ -27,6 +27,7 @@ menuconfig ARCH_EXYNOS
>>  	select SRAM
>>  	select THERMAL
>>  	select MFD_SYSCON
>> +	select CLKSRC_EXYNOS_MCT
>>  	help
>>  	  Support for SAMSUNG EXYNOS SoCs (EXYNOS4/5)
>>  
>> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
>> index 916c36d..d829cbe 100644
>> --- a/drivers/clocksource/Kconfig
>> +++ b/drivers/clocksource/Kconfig
>> @@ -213,8 +213,8 @@ config CLKSRC_METAG_GENERIC
>>  	  This option enables support for the Meta per-thread timers.
>>  
>>  config CLKSRC_EXYNOS_MCT
>> -	def_bool y if ARCH_EXYNOS
>> -	depends on !ARM64
>> +	bool "Exynos multi core timer driver" if COMPILE_TEST
>> +	depends on ARM
>>  	help
>>  	  Support for Multi Core Timer controller on Exynos SoCs.
>>  
>>
> 
> 

[PATCH 20/22] clocksource/drivers/exynos_mct: Fix Kconfig and add COMPILE_TEST option

[Daniel Lezcano]

On 11/03/2015 01:59 AM, Krzysztof Kozlowski wrote:
> On 03.11.2015 09:30, Krzysztof Kozlowski wrote:
>> On 02.11.2015 21:56, Daniel Lezcano wrote:
>>> Let the platform's Kconfig to select the clock instead of having a reverse
>>> dependency from the driver to the platform options.
>>
>> Selecting user-visible symbols is rather discouraged so why not
>> something like this:
>>
>> -       def_bool y if ARCH_EXYNOS
>> -       depends on !ARM64
>> +       bool "Exynos multi core timer driver"
>> +       depends on ARCH_EXYNOS || (COMPILE_TEST && ARM)
>
> Nope, that was wrong as we loose auto-select on Exynos. Instead:
> -       def_bool y if ARCH_EXYNOS
> -       depends on !ARM64
> +       bool "Exynos multi core timer driver" if ARM
> +       depends on ARCH_EXYNOS || COMPILE_TEST
> +       default y if ARCH_EXYNOS
>
> This way we avoid select (which is a reverse dependency for the driver),
> have it auto-selectable and compile tested on arm.

I think you misunderstood the patch I sent.

It does two things:

1. Follow the thumb of rule of the current Kconfig format

    - The timer driver is selected by the platform (exynos in this case)
    - User can't select the driver in the menuconfig
    - There is no dependency on the platform except for compilation test

2. Add the COMPILE_TEST

    - User can select the driver for compilation testing. This is for 
allyesconfig when doing compilation test coverage (exynos timer could be 
compiled on other platform). As the delay code is not portable, we have 
to restrict the compilation on the ARM platform, this is why there is 
the dependency on ARM.

I am currently looking at splitting the delay code in order to prevent 
this restriction on this driver and some others drivers.


>>> Add the COMPILE_TEST option for the compilation test coverage. Due to the
>>> non portable 'delay' code, this driver is only compilable on ARM.
>>>
>>> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
>>> ---
>>>   arch/arm/mach-exynos/Kconfig | 1 +
>>>   drivers/clocksource/Kconfig  | 4 ++--
>>>   2 files changed, 3 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
>>> index 3a10f1a..ff10539 100644
>>> --- a/arch/arm/mach-exynos/Kconfig
>>> +++ b/arch/arm/mach-exynos/Kconfig
>>> @@ -27,6 +27,7 @@ menuconfig ARCH_EXYNOS
>>>   	select SRAM
>>>   	select THERMAL
>>>   	select MFD_SYSCON
>>> +	select CLKSRC_EXYNOS_MCT
>>>   	help
>>>   	  Support for SAMSUNG EXYNOS SoCs (EXYNOS4/5)
>>>
>>> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
>>> index 916c36d..d829cbe 100644
>>> --- a/drivers/clocksource/Kconfig
>>> +++ b/drivers/clocksource/Kconfig
>>> @@ -213,8 +213,8 @@ config CLKSRC_METAG_GENERIC
>>>   	  This option enables support for the Meta per-thread timers.
>>>
>>>   config CLKSRC_EXYNOS_MCT
>>> -	def_bool y if ARCH_EXYNOS
>>> -	depends on !ARM64
>>> +	bool "Exynos multi core timer driver" if COMPILE_TEST
>>> +	depends on ARM
>>>   	help
>>>   	  Support for Multi Core Timer controller on Exynos SoCs.
>>>
>>>
>>
>>
>


-- 
  <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

[PATCH 20/22] clocksource/drivers/exynos_mct: Fix Kconfig and add COMPILE_TEST option

[Arnd Bergmann]

On Tuesday 03 November 2015 09:40:02 Daniel Lezcano wrote:
> On 11/03/2015 01:59 AM, Krzysztof Kozlowski wrote:
> > On 03.11.2015 09:30, Krzysztof Kozlowski wrote:
> >> On 02.11.2015 21:56, Daniel Lezcano wrote:
> >>> Let the platform's Kconfig to select the clock instead of having a reverse
> >>> dependency from the driver to the platform options.
> >>
> >> Selecting user-visible symbols is rather discouraged so why not
> >> something like this:
> >>
> >> -       def_bool y if ARCH_EXYNOS
> >> -       depends on !ARM64
> >> +       bool "Exynos multi core timer driver"
> >> +       depends on ARCH_EXYNOS || (COMPILE_TEST && ARM)
> >
> > Nope, that was wrong as we loose auto-select on Exynos. Instead:
> > -       def_bool y if ARCH_EXYNOS
> > -       depends on !ARM64
> > +       bool "Exynos multi core timer driver" if ARM
> > +       depends on ARCH_EXYNOS || COMPILE_TEST
> > +       default y if ARCH_EXYNOS
> >
> > This way we avoid select (which is a reverse dependency for the driver),
> > have it auto-selectable and compile tested on arm.
> 
> I think you misunderstood the patch I sent.
> 
> It does two things:
> 
> 1. Follow the thumb of rule of the current Kconfig format
> 
>     - The timer driver is selected by the platform (exynos in this case)
>     - User can't select the driver in the menuconfig
>     - There is no dependency on the platform except for compilation test
> 
> 2. Add the COMPILE_TEST
> 
>     - User can select the driver for compilation testing. This is for 
> allyesconfig when doing compilation test coverage (exynos timer could be 
> compiled on other platform). As the delay code is not portable, we have 
> to restrict the compilation on the ARM platform, this is why there is 
> the dependency on ARM.
> 
> I am currently looking at splitting the delay code in order to prevent 
> this restriction on this driver and some others drivers.

I suspect this will come up again in the future. The problem is
really that drivers/clocksource has different rules from almost
everything else, by requiring the platform to 'select' the driver.

The second version that Krzysztof posted is how we handle this in
other driver subsystems, and I would generally prefer it to do this
consistently for everything, but John Stultz has in the past argued
strongly for using 'select' in all clocksource drivers. The reason
is that for each platform we know in advance which driver we want,
and there is never a need for the user to have to select the right
one.

	Arnd

[PATCH 20/22] clocksource/drivers/exynos_mct: Fix Kconfig and add COMPILE_TEST option

[Daniel Lezcano]

On 11/03/2015 11:02 AM, Arnd Bergmann wrote:
> On Tuesday 03 November 2015 09:40:02 Daniel Lezcano wrote:
>> On 11/03/2015 01:59 AM, Krzysztof Kozlowski wrote:
>>> On 03.11.2015 09:30, Krzysztof Kozlowski wrote:
>>>> On 02.11.2015 21:56, Daniel Lezcano wrote:
>>>>> Let the platform's Kconfig to select the clock instead of having a reverse
>>>>> dependency from the driver to the platform options.
>>>>
>>>> Selecting user-visible symbols is rather discouraged so why not
>>>> something like this:
>>>>
>>>> -       def_bool y if ARCH_EXYNOS
>>>> -       depends on !ARM64
>>>> +       bool "Exynos multi core timer driver"
>>>> +       depends on ARCH_EXYNOS || (COMPILE_TEST && ARM)
>>>
>>> Nope, that was wrong as we loose auto-select on Exynos. Instead:
>>> -       def_bool y if ARCH_EXYNOS
>>> -       depends on !ARM64
>>> +       bool "Exynos multi core timer driver" if ARM
>>> +       depends on ARCH_EXYNOS || COMPILE_TEST
>>> +       default y if ARCH_EXYNOS
>>>
>>> This way we avoid select (which is a reverse dependency for the driver),
>>> have it auto-selectable and compile tested on arm.
>>
>> I think you misunderstood the patch I sent.
>>
>> It does two things:
>>
>> 1. Follow the thumb of rule of the current Kconfig format
>>
>>      - The timer driver is selected by the platform (exynos in this case)
>>      - User can't select the driver in the menuconfig
>>      - There is no dependency on the platform except for compilation test
>>
>> 2. Add the COMPILE_TEST
>>
>>      - User can select the driver for compilation testing. This is for
>> allyesconfig when doing compilation test coverage (exynos timer could be
>> compiled on other platform). As the delay code is not portable, we have
>> to restrict the compilation on the ARM platform, this is why there is
>> the dependency on ARM.
>>
>> I am currently looking at splitting the delay code in order to prevent
>> this restriction on this driver and some others drivers.
>
> I suspect this will come up again in the future. The problem is
> really that drivers/clocksource has different rules from almost
> everything else, by requiring the platform to 'select' the driver.
>
> The second version that Krzysztof posted is how we handle this in
> other driver subsystems, and I would generally prefer it to do this
> consistently for everything, but John Stultz has in the past argued
> strongly for using 'select' in all clocksource drivers. The reason
> is that for each platform we know in advance which driver we want,
> and there is never a need for the user to have to select the right
> one.

Yes, and I second John in this.



-- 
  <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

[PATCH 20/22] clocksource/drivers/exynos_mct: Fix Kconfig and add COMPILE_TEST option

[Krzysztof Kozlowski]

W dniu 03.11.2015 o 19:02, Arnd Bergmann pisze:
> On Tuesday 03 November 2015 09:40:02 Daniel Lezcano wrote:
>> On 11/03/2015 01:59 AM, Krzysztof Kozlowski wrote:
>>> On 03.11.2015 09:30, Krzysztof Kozlowski wrote:
>>>> On 02.11.2015 21:56, Daniel Lezcano wrote:
>>>>> Let the platform's Kconfig to select the clock instead of having a reverse
>>>>> dependency from the driver to the platform options.
>>>>
>>>> Selecting user-visible symbols is rather discouraged so why not
>>>> something like this:
>>>>
>>>> -       def_bool y if ARCH_EXYNOS
>>>> -       depends on !ARM64
>>>> +       bool "Exynos multi core timer driver"
>>>> +       depends on ARCH_EXYNOS || (COMPILE_TEST && ARM)
>>>
>>> Nope, that was wrong as we loose auto-select on Exynos. Instead:
>>> -       def_bool y if ARCH_EXYNOS
>>> -       depends on !ARM64
>>> +       bool "Exynos multi core timer driver" if ARM
>>> +       depends on ARCH_EXYNOS || COMPILE_TEST
>>> +       default y if ARCH_EXYNOS
>>>
>>> This way we avoid select (which is a reverse dependency for the driver),
>>> have it auto-selectable and compile tested on arm.
>>
>> I think you misunderstood the patch I sent.
>>
>> It does two things:
>>
>> 1. Follow the thumb of rule of the current Kconfig format
>>
>>     - The timer driver is selected by the platform (exynos in this case)
>>     - User can't select the driver in the menuconfig
>>     - There is no dependency on the platform except for compilation test
>>
>> 2. Add the COMPILE_TEST
>>
>>     - User can select the driver for compilation testing. This is for 
>> allyesconfig when doing compilation test coverage (exynos timer could be 
>> compiled on other platform). As the delay code is not portable, we have 
>> to restrict the compilation on the ARM platform, this is why there is 
>> the dependency on ARM.
>>
>> I am currently looking at splitting the delay code in order to prevent 
>> this restriction on this driver and some others drivers.
> 
> I suspect this will come up again in the future. The problem is
> really that drivers/clocksource has different rules from almost
> everything else, by requiring the platform to 'select' the driver.
> 
> The second version that Krzysztof posted is how we handle this in
> other driver subsystems, and I would generally prefer it to do this
> consistently for everything, but John Stultz has in the past argued
> strongly for using 'select' in all clocksource drivers. The reason
> is that for each platform we know in advance which driver we want,
> and there is never a need for the user to have to select the right
> one.

Arnd, Daniel,

Sure, makes sense to me, thanks for explanation. Actually this makes me
thinking that drivers/soc/* should probably follow the same
convention... but not all of them do that.

Anyway the patch worked fine and with explanation I can only confirm:

Tested-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>

Best regards,
Krzysztof

[PATCH 20/22] clocksource/drivers/exynos_mct: Fix Kconfig and add COMPILE_TEST option

[Daniel Lezcano]

On 11/03/2015 01:01 PM, Krzysztof Kozlowski wrote:
> Anyway the patch worked fine and with explanation I can only confirm:

Great ! Thanks Krzysztof for testing.

   -- Daniel

-- 
  <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

[PATCH 20/22] clocksource/drivers/exynos_mct: Fix Kconfig and add COMPILE_TEST option

[John Stultz]

On Tue, Nov 3, 2015 at 2:02 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> I suspect this will come up again in the future. The problem is
> really that drivers/clocksource has different rules from almost
> everything else, by requiring the platform to 'select' the driver.
>
> The second version that Krzysztof posted is how we handle this in
> other driver subsystems, and I would generally prefer it to do this
> consistently for everything, but John Stultz has in the past argued
> strongly for using 'select' in all clocksource drivers. The reason
> is that for each platform we know in advance which driver we want,
> and there is never a need for the user to have to select the right
> one.

And just to clarify, I don't necessarily think "select" is the right
method, as creating an option that defaults to Y if the right
architecture/platform support is present is fine too.

I just don't want users to have to search deeply through menuconfig to
find a clocksource driver checkbox when they have already selected a
platform and provided enough information for us to know which
clocksource driver is needed.  So my argument its really all about
avoiding user-prompts in kconfig for clocksources.  It is conceptually
easier to do this w/ select, but you can also do it via default y and
proper dependencies.

thanks
-john

[PATCH 20/22] clocksource/drivers/exynos_mct: Fix Kconfig and add COMPILE_TEST option

[Chanwoo Choi]

Hi,

On 2015? 11? 02? 21:56, Daniel Lezcano wrote:
> Let the platform's Kconfig to select the clock instead of having a reverse
> dependency from the driver to the platform options.
> 
> Add the COMPILE_TEST option for the compilation test coverage. Due to the
> non portable 'delay' code, this driver is only compilable on ARM.
> 
> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> ---
>  arch/arm/mach-exynos/Kconfig | 1 +
>  drivers/clocksource/Kconfig  | 4 ++--
>  2 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
> index 3a10f1a..ff10539 100644
> --- a/arch/arm/mach-exynos/Kconfig
> +++ b/arch/arm/mach-exynos/Kconfig
> @@ -27,6 +27,7 @@ menuconfig ARCH_EXYNOS
>  	select SRAM
>  	select THERMAL
>  	select MFD_SYSCON
> +	select CLKSRC_EXYNOS_MCT
>  	help
>  	  Support for SAMSUNG EXYNOS SoCs (EXYNOS4/5)
>  
> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> index 916c36d..d829cbe 100644
> --- a/drivers/clocksource/Kconfig
> +++ b/drivers/clocksource/Kconfig
> @@ -213,8 +213,8 @@ config CLKSRC_METAG_GENERIC
>  	  This option enables support for the Meta per-thread timers.
>  
>  config CLKSRC_EXYNOS_MCT
> -	def_bool y if ARCH_EXYNOS
> -	depends on !ARM64
> +	bool "Exynos multi core timer driver" if COMPILE_TEST
> +	depends on ARM
>  	help
>  	  Support for Multi Core Timer controller on Exynos SoCs.
>  
> 

Looks good to me. As you commented, delay_timer is only used on ARM 32bit.
I'm glad to use the 'depends on ARM' instead of reverse dependency.

Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>

Thanks,
Chanwoo Choi