Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756598AbbLAPJ2 (ORCPT ); Tue, 1 Dec 2015 10:09:28 -0500 Received: from bear.ext.ti.com ([192.94.94.41]:53598 "EHLO bear.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755789AbbLAPJ0 (ORCPT ); Tue, 1 Dec 2015 10:09:26 -0500 Subject: Re: [RFC PATCH] clocksource: ti-32k: convert to platform device To: Tony Lindgren References: <1448040129-23869-1-git-send-email-grygorii.strashko@ti.com> <87h9kgcz1k.fsf@saruman.tx.rr.com> <5658B8B2.5030505@ti.com> <20151130162815.GA2517@atomide.com> CC: Felipe Balbi , , Daniel Lezcano , Thomas Gleixner , , , From: Grygorii Strashko Message-ID: <565DB7F7.4020702@ti.com> Date: Tue, 1 Dec 2015 17:08:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151130162815.GA2517@atomide.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3212 Lines: 83 Hi Tony, On 11/30/2015 06:28 PM, Tony Lindgren wrote: > * Grygorii Strashko [151127 12:11]: >> On 11/20/2015 08:21 PM, Felipe Balbi wrote: >>> Grygorii Strashko 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 >>>> Cc: Felipe Balbi >>>> Signed-off-by: Grygorii Strashko >>>> --- >> >> [...] >> >>>> + >>>> +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-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/