Re: [RFC PATCH] clocksource: ti-32k: convert to platform device

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

 



Hi Tony,

On 11/30/2015 06:28 PM, Tony Lindgren wrote:
> * Grygorii Strashko <grygorii.strashko@xxxxxx> [151127 12:11]:
>> On 11/20/2015 08:21 PM, Felipe Balbi wrote:
>>> Grygorii Strashko <grygorii.strashko@xxxxxx> writes:
>>>> Since system clocksource is finally selected by Clocksource core at
>>>> fs_initcall stage during boot there are no reasons to initialize
>>>> ti_32k_timer at early boot stages. Hence, ti_32k_timer can be
>>>> converted to use platform device/driver model and its PM can be
>>>> implemented using PM runtime which is common for OMAP devices.
>>>>
>>>> Platform specific initialization code has to be disabled once as
>>>> ti_32k_timer is converted to platform device - otherwise OMAP platform
>>>> code will generate boot warnings.
>>>>
>>>> After this change, all counter_32k's platform code can be removed
>>>> once all OMAP boards will be converted to DT.
>>>>
>>>> Cc: Tony Lindgren <tony@xxxxxxxxxxx>
>>>> Cc: Felipe Balbi <balbi@xxxxxx>
>>>> Signed-off-by: Grygorii Strashko <grygorii.strashko@xxxxxx>
>>>> ---
>>
>> [...]
>>
>>>> +
>>>> +static struct platform_driver ti_32k_driver __initdata = {
>>>> +	.probe		= ti_32k_probe,
>>>> +	.driver		= {
>>>> +		.name	= "ti_32k_timer",
>>>> +		.of_match_table = of_match_ptr(ti_32k_of_table),
>>>> +	}
>>>> +};
>>>> +
>>>> +static int __init ti_32k_init(void)
>>>> +{
>>>> +	return platform_driver_register(&ti_32k_driver);
>>>>    }
>>>> -CLOCKSOURCE_OF_DECLARE(ti_32k_timer, "ti,omap-counter32k",
>>>> -		ti_32k_timer_init);
>>>> +
>>>> +subsys_initcall(ti_32k_init);
>>>> +
>>>> +MODULE_AUTHOR("Paul Mundt");
>>>> +MODULE_AUTHOR("Juha Yrjölä");
>>>> +MODULE_DESCRIPTION("OMAP2 32k Timer");
>>>> +MODULE_ALIAS("platform:ti_32k_timer");
>>>> +MODULE_LICENSE("GPL v2");
>>>
>>> this will break clksource_of_init(), right ? Eventually, we want that to
>>> be the only thing called by our .init_time method. I'll leave it to Tony
>>> to decide, but IMO this is not a good path forward for timers.
>>>
>>
>> Yeh :(.  I did additional tests, and, unfortunately, this can't be used as is.
>> But not because of clocksource_of_init() which will just produce boot warning.
>> It can't be done because of sched_clock_register() which is expected to be
>> called during early boot time only and with disabled IRQs.
>>
>> It was so tempting to try :)
> 
> We should be able to make this into an early_platform_device and just
> have it depend on the source clock muxes. See the omap initcall changes
> patches I just posted.
> 

Sry, may be I've missed smth, but how early_platform_device will help us
to get rid of platform code - We'd still need to power on manually 
early_platform_device's from platform code :( through hwmod.

The main reason why I've tried this is because clocksource will be really selected
only at fs_initcall time - and at that time we have no restriction for using platform
devices, Pm runtime APIs, etc. (exception/blocker is sched_clock :().

-- 
regards,
-grygorii
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux