Re: [PATCH 1/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Vaibhav,

On 04/09/2012 01:19 AM, Hiremath, Vaibhav wrote:

[...]

Let me summarize it here again,

Currently, the timer code is using config option CONFIG_OMAP_32K_TIMER,
to choose between 32ksync counter and gptimer; it is compile time option.
If user wants to use gptimer for HR ticks, he must build the kernel without
CONFIG_OMAP_32K_TIMER option.

AM335x family of devices doesn't have 32ksync_counter available, only option
here is to use gptimer for kernel clocksource and clockevents.

So in order to support, multi-omap build including devices like AM335x, we
must get rid of this option CONFIG_OMAP_32K_TIMER, atleast from clocksource
registration perspective.

So that means, we need to have some mechanism to handle or detect available
clocksource runtime. Options would be,

  - Use HWMOD to detect availability of 32ksync_counter, else fallback
    to gptimer. [This was my original patch]

    But this restricts the use of gptimer completely on omap architecture,
    where we have 32ksync counter module.

True, but we would always want to use the 32k timer if CONFIG_PM is specified. So what I am saying is that if a device has a 32ksync timer and CONFIG_PM is defined, we always want to use the 32ksync timer and a gptimer should never be used.

So we should/must restrict the use of a gptimer is CONFIG_PM is enabled for devices that have the 32ksync timer.

  - So the next solution is to still keep compile time option, so that user
    will get to use gptimer atleast just changing the kernel config option.

    But, still, this is going to be kernel rebuild.

  - Next option came up was, register both the timers and override using
    kernel parameter.

    This will work only if, both the timers run at same rate/frequency; since
    we have one more layer here setup_sched_clock(), which actually can be
    called only once.

  - Next option suggested by Santosh, is to use kernel parameter as in parse
    it early, to make decision on if user wants to override default
    clocksource (32ksync)

    This is something will work for us and solves all above issues.

What happens if PM is enabled? Can you still override the default? I don't think this should be allowed for devices with a 32ksync timer.

Jon

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


[Index of Archives]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [CentOS ARM]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]

  Powered by Linux