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.
��.n��������+%������w��{.n����z�{��ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
