Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752377AbdF3SyI (ORCPT ); Fri, 30 Jun 2017 14:54:08 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:51376 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751918AbdF3SyG (ORCPT ); Fri, 30 Jun 2017 14:54:06 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 3E96C604D4 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=sboyd@codeaurora.org Date: Fri, 30 Jun 2017 11:54:03 -0700 From: Stephen Boyd To: Gabriel FERNANDEZ 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 Message-ID: <20170630185403.GN22780@codeaurora.org> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1502 Lines: 40 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? -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project