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
