[PATCH] ARM: imx: add cpuidle support for i.mx6sl
Anson.Huang at freescale.com
Anson.Huang at freescale.com
Thu Jan 23 21:31:34 EST 2014
It may be enough, but I am afraid that there is chance that the time_after function's actual delay is shorter than 60us, as the timeout is only one jiffy(10ms), if the jiffy update comes right between the timeout value initialization and the time_after, then the delay may be not enough, is there such possibility? Correct me if I am wrong.
Best Regards.
Anson huang 黄勇才
Freescale Semiconductor Shanghai
上海浦东新区亮景路192号A座2楼
201203
Tel:021-28937058
>-----Original Message-----
>From: John Tobias [mailto:john.tobias.ph at gmail.com]
>Sent: Friday, January 24, 2014 10:24 AM
>To: Huang Yongcai-B20788
>Cc: <linux-arm-kernel at lists.infradead.org>; Shawn Guo
>Subject: Re: [PATCH] ARM: imx: add cpuidle support for i.mx6sl
>
>Does the time_after function inside the loop is not enough to handle the
>situation?
>
>On Thu, Jan 23, 2014 at 6:05 PM, Anson.Huang at freescale.com
><Anson.Huang at freescale.com> wrote:
>> Hi, Tobias
>> Yes, the root cause is the reschedule introduced by the usleep, for
>our internal release, we use busy loop for PLL wait lock, just removing the
>usleep is not good enough, as the PLL hardware may need about 60~90us to lock,
>during this period, there will be no clock output in PLL. So, we need to
>figure out a way to fix this issue, either using busy loop instead of usleep
>or access the ccm register to adjust ARM divider instead of calling clk APIs.
>>
>> Best Regards.
>> Anson huang 黄勇才
>>
>> Freescale Semiconductor Shanghai
>> 上海浦东新区亮景路192号A座2楼
>> 201203
>> Tel:021-28937058
>>
>>
>>>-----Original Message-----
>>>From: John Tobias [mailto:john.tobias.ph at gmail.com]
>>>Sent: Friday, January 24, 2014 4:17 AM
>>>To: Huang Yongcai-B20788
>>>Cc: <linux-arm-kernel at lists.infradead.org>; Shawn Guo
>>>Subject: Re: [PATCH] ARM: imx: add cpuidle support for i.mx6sl
>>>
>>>Hi Anson / Shawn,
>>>
>>>I compared the clk_pllv3_wait_lock to the clk_pllv3_wait_for_lock of
>>>Freescale alpha release. In alpha, the usleep_range did not exist. I
>>>tried removing it, build the kernel again and it works.
>>>I didn't get crashes anymore...
>>>
>>>Regards,
>>>
>>>john
>>>
>>>
>>>
>>>On Mon, Jan 20, 2014 at 1:03 AM, Anson.Huang at freescale.com
>>><Anson.Huang at freescale.com> wrote:
>>>> Hi, Tobias and Shawn
>>>> I debug into this issue today, the root cause is that we
>>>> have a
>>>usleep_range(50, 500); in arch/arm/mach-imx/clk-pllv3.c's
>>>clk_pllv3_wait_lock function, which will cause kernel schedule during
>>>cpufreq change, and the idle thread has another clk operation which
>>>will cause mutex nest, and it will try to wake up previous mutex hold by
>cpufreq change's pll1 clk_set_rate.
>>>> So, to fix this issue, we should not use any usleep in the
>>>> wait
>>>function of pllv3's code, or we should not call any clk API in the
>>>imx6sl_set_wait_clk function. What do you think?
>>>>
>>>> BTW, I found another issue, if EVK board boot up with
>>>> 396MHz, then
>>>the initialized clock parent status is wrong, as ARM is from PFD
>>>396MHz, I will generate another patch to fix that once I have bandwidth.
>>>>
>>>> Best Regards.
>>>> Anson huang 黄勇才
>>>>
>>>> Freescale Semiconductor Shanghai
>>>> 上海浦东新区亮景路192号A座2楼
>>>> 201203
>>>> Tel:021-28937058
>>>>
>>>>
>>>>>-----Original Message-----
>>>>>From: Huang Yongcai-B20788
>>>>>Sent: Saturday, January 18, 2014 7:53 AM
>>>>>To: John Tobias
>>>>>Cc: <linux-arm-kernel at lists.infradead.org>; Shawn Guo
>>>>>Subject: Re: [PATCH] ARM: imx: add cpuidle support for i.mx6sl
>>>>>
>>>>>Hi, Tobias
>>>>> I will debug it next week and feedback to you. Thanks.
>>>>>
>>>>>Sent from Anson's iPhone
>>>>>
>>>>>> 在 2014年1月18日,7:42,"John Tobias" <john.tobias.ph at gmail.com> 写道:
>>>>>>
>>>>>> Hi Anson,
>>>>>>
>>>>>> My kernel for iMX6SL has a imx6q-cpufreq and I used your patch.
>>>>>> Unfortunately, the kernel crashes if the imx6sl_set_wait_clk being
>>>>>> called in imx6sl_enter_wait.
>>>>>>
>>>>>> [ 288.166905] [<80044b80>] (dequeue_task+0x0/0xc8) from
>>>>>> [<80045650>]
>>>>>> (deactivate_task+0x30/0x34)
>>>>>> [ 288.176403] [<80045620>] (deactivate_task+0x0/0x34) from
>>>>>> [<8050ac88>] (__schedule+0x318/0x58c) [ 288.185848] [<8050a970>]
>>>>>> (__schedule+0x0/0x58c) from [<8050af34>]
>>>>>> (schedule+0x38/0x88)
>>>>>> [ 288.194758] [<8050aefc>] (schedule+0x0/0x88) from [<8050b1c8>]
>>>>>> (schedule_preempt_disabled+0x10/0x14)
>>>>>> [ 288.204858] [<8050b1b8>] (schedule_preempt_disabled+0x0/0x14)
>>>>>> from [<8050bcd4>] (mutex_lock_nested+0x16c/0x334) [ 288.215850]
>>>>>> [<8050bb68>] (mutex_lock_nested+0x0/0x334) from [<8034763c>]
>>>>>> (clk_prepare_lock+0x90/0x104) [ 288.226041] [<803475ac>]
>>>>>> (clk_prepare_lock+0x0/0x104) from [<80349254>]
>>>>>> (clk_set_rate+0x1c/0xbc) [ 288.235535] r6:806fd360 r5:00000000
>>>>>> r4:bf817f80 r3:80713d80 [ 288.242679] [<80349238>]
>>>>>> (clk_set_rate+0x0/0xbc) from [<8001e574>]
>>>>>> (imx6sl_set_wait_clk+0x28/0x70)
>>>>>> [ 288.252354] r5:00000043 r4:00000001 [ 288.256585]
>>>>>> [<8001e54c>]
>>>>>> (imx6sl_set_wait_clk+0x0/0x70) from [<8001def4>]
>>>>>> (imx6sl_enter_wait+0x24/0x2c) [ 288.266684] r5:00000043
>>>>>> r4:00000001 [ 288.270949] [<8001ded0>]
>>>>>> (imx6sl_enter_wait+0x0/0x2c) from [<80317608>]
>>>>>> (cpuidle_enter_state+0x44/0xfc) [ 288.281051]
>>>>>> r4:13bf2645 r3:8001ded0 [ 288.285682] [<803175c4>]
>>>>>> (cpuidle_enter_state+0x0/0xfc) from [<803177bc>]
>>>>>> (cpuidle_idle_call+0xfc/0x150) [ 288.295871] r8:806e00d8
>>>>>> r7:00000001
>>>>>> r6:00000000 r5:80c58034 r4:806fd360 [ 288.304428] [<803176c0>]
>>>>>> (cpuidle_idle_call+0x0/0x150) from [<8000fa68>]
>>>>>> (arch_cpu_idle+0x10/0x44) [ 288.314108] r9:8070970a r8:8070970a
>>>>>> r7:806d2000 r6:806da0dc r5:806d2000
>>>>>> r4:806d2000
>>>>>> [ 288.323611] [<8000fa58>] (arch_cpu_idle+0x0/0x44) from
>>>>>> [<800590f4>]
>>>>>> (cpu_startup_entry+0xe0/0x120)
>>>>>> [ 288.333460] [<80059014>] (cpu_startup_entry+0x0/0x120) from
>>>>>> [<80503c8c>] (rest_init+0xcc/0xdc) [ 288.342810] r7:ffffffff
>>>>>> r3:00000000 [ 288.347115] [<80503bc0>] (rest_init+0x0/0xdc) from
>>>>>> [<806a2b00>]
>>>>>> (start_kernel+0x348/0x354)
>>>>>> [ 288.356099] r6:806da040 r5:806da040 r4:806da150 [ 288.361972]
>>>>>> [<806a27b8>] (start_kernel+0x0/0x354) from [<80008070>]
>>>>>> (0x80008070)
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> john
>>>>>>
>>>>>>
>>>
>>
>
More information about the linux-arm-kernel
mailing list