Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752453AbdGEJfd (ORCPT ); Wed, 5 Jul 2017 05:35:33 -0400 Received: from mx08-00178001.pphosted.com ([91.207.212.93]:44765 "EHLO mx07-00178001.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751626AbdGEJfa (ORCPT ); Wed, 5 Jul 2017 05:35:30 -0400 From: Gabriel FERNANDEZ To: Stephen Boyd CC: Rob Herring , Mark Rutland , Russell King , Maxime Coquelin , Alexandre TORGUE , Michael Turquette , Nicolas Pitre , Arnd Bergmann , "daniel.thompson@linaro.org" , "andrea.merello@gmail.com" , "radoslaw.pietrzyk@gmail.com" , Lee Jones , "devicetree@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "linux-clk@vger.kernel.org" , Ludovic BARRE , "Olivier BIDEAU" , Amelie DELAUNAY , "gabriel.fernandez.st@gmail.com" Subject: Re: [RESEND PATCH v4] clk: stm32h7: Add stm32h743 clock driver Thread-Topic: [RESEND PATCH v4] clk: stm32h7: Add stm32h743 clock driver Thread-Index: AQHS31uuzVmODfuWeEOg6i19U5EFNaIv1S6AgAjJOICAAdCHAIABa4kAgACyjQCAAHO8AIAAw36AgAc9SgA= Date: Wed, 5 Jul 2017 09:27:14 +0000 Message-ID: <67be49fc-ca1b-338c-913e-a0cd19c55697@st.com> References: <1496818794-14771-1-git-send-email-gabriel.fernandez@st.com> <20170621220703.GI4493@codeaurora.org> <110cf67f-e1d6-1f99-953c-6b9639bb4910@st.com> <20170628155956.GA5316@codeaurora.org> <7c0c3861-cf61-a9e2-cd5d-2ae30b8f32fa@st.com> <20170630002008.GD22780@codeaurora.org> <20170630185403.GN22780@codeaurora.org> In-Reply-To: <20170630185403.GN22780@codeaurora.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.75.127.50] Content-Type: text/plain; charset="utf-8" Content-ID: MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-07-05_06:,, signatures=0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id v659Zgqd030285 Content-Length: 2009 Lines: 56 On 06/30/2017 08:54 PM, Stephen Boyd wrote: > On 06/30, Gabriel FERNANDEZ wrote: >> >> On 06/30/2017 02:20 AM, Stephen Boyd wrote: >>> On 06/29, Gabriel FERNANDEZ wrote: >>>> On 06/28/2017 05:59 PM, Stephen Boyd wrote: >>>>> On 06/27, Gabriel FERNANDEZ wrote: >>>>>> On 06/22/2017 12:07 AM, Stephen Boyd wrote: >>>>>>> readl_poll_timeout? >>>>>>> >>>>>> if i use readl_poll_timeout (wich use 'ktime_get()') it can be >>>>>> operational only after the selection of clocksource ? (device_initcall). >>>>>> And then if a driver turn on a clock before, it could blocked the linux >>>>>> console ? >>>>>> >>>>> Ok. I wonder if we could add some sort of starting check to >>>>> readl_poll_timeout() that tests system_state for booting vs. >>>>> scheduling? That should be sufficient to handle this case? >>>>> >>>> Oops i think i understood my problem... >>>> i used readl_poll_timeout in atomic context. >>>> I have to move my code in the .prepare ops. >>>> >>>> If you are ok with that i will send a v5 >>>> >>> There's readl_poll_timeout_atomic() for those modes. >>> >> yes it's exactly the test i made (use 'readl_poll_timeout()_atomic' in >> .enable ops) but i'm blocked. >> >> if i do the same in .prepare ops with 'readl_poll_timeout()' it's ok. > I'm still confused. readl_poll_timeout_atomic() uses ktime_get(), > and so does readl_poll_timeout(), so how does moving to the > prepare op fix the problem? What's the actual problem? > Yes both use ktime_get(). The issue concerns internal/external oscillator clocks (time stabilization could be long) and if a driver wants to enable one these clocks before device_initcall(). By default the clocksource is the jiffies until the end of the boot (fs_initcall) Then after, the best clocksource is selected (arm_system_timer or stm32 timer, etc...) There is no problem after because the counter is a hardware register. But the jiffies counter is incremented by interruption and enable op does not allow to be interrupted. (we can with prepare op).