All of lore.kernel.org
 help / color / mirror / Atom feed
From: Caesar Wang <caesar.upstream@gmail.com>
To: Eduardo Valentin <edubezval@gmail.com>
Cc: Caesar Wang <caesar.upstream@gmail.com>,
	Heiko Stuebner <heiko@sntech.de>,
	linux-pm@vger.kernel.org, dianders@chromium.org,
	linux-kernel@vger.kernel.org, linux-rockchip@lists.infradead.org,
	smbarber@google.com, briannorris@google.com,
	Zhang Rui <rui.zhang@intel.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 4/9] thermal: rockchip: handle the power sequence for tsadc controller
Date: Tue, 3 May 2016 10:27:26 +0800	[thread overview]
Message-ID: <57280C8E.5080406@gmail.com> (raw)
In-Reply-To: <20160428150432.GA20009@localhost.localdomain>



在 2016年04月28日 23:04, Eduardo Valentin 写道:
> On Thu, Apr 28, 2016 at 09:50:29AM +0800, Caesar Wang wrote:
>>
>> 在 2016年04月28日 07:48, Eduardo Valentin 写道:
>>> On Mon, Apr 18, 2016 at 11:35:56AM +0800, Caesar Wang wrote:
>>>> +		regmap_write(grf, GRF_TSADC_TESTBIT_L, GRF_TSADC_TSEN_PD_ON);
>>>> +		mdelay(10);
>>>> +		regmap_write(grf, GRF_TSADC_TESTBIT_L, GRF_TSADC_TSEN_PD_OFF);
>>>> +		udelay(100); /* The spec note says at least 15 us */
>>>> +		regmap_write(grf, GRF_SARADC_TESTBIT, GRF_SARADC_TESTBIT_ON);
>>>> +		regmap_write(grf, GRF_TSADC_TESTBIT_H, GRF_TSADC_TESTBIT_H_ON);
>>>> +		udelay(200); /* The spec note says at least 90 us */
>>> Does it make sense to use usleep_range() instead?
>> I think so in the past, but I'm digging into the the udelay/usleep for
>> kernel.
> What do you mean by in the past? timekeeping doc still recommends the
> range 10us to 20ms for usleep_range()
>
>> In general,
>>
>> udelay < 10us ~100us
>> mdelay > 1m, <1000ms/HZ
>> usleep_range(min,max) > 100us, <20ms
> even here, your udelays could be replaced by usleep_range().
>
> Any particular reason you believe spining is better than sleeping in
> your case?
>
>> msleep > 20ms,  < 1000ms
>>
>> So the udelay is suit for tsadc power sequence.
>> ---
>>
>>
>> Also,  we have used the mdelay(10), so it doesn't matter if use the udelay.
>> After all the udelay is stable than the usleep_range.
> What do you mean udelay is stable than usleep_range? usleep_range will
> give the opportunity to the scheduler to coalesce wakeups. udelay is a
> busyloop spin. Besides, I am not sure the current situation, but
> busylooping may be affected by cpu frequency.

Okay, thanks for pointing out.

Send the fixes patch on https://patchwork.kernel.org/patch/8999971/

Thank you!


-Caesar
>
>> -Caesar
>>
>>> 1.9.1
>>>
>>>
>>>
>>>
>>> -- 
>>> Thanks,
>>> Caesar
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip


-- 
Thanks,
Caesar


WARNING: multiple messages have this Message-ID (diff)
From: caesar.upstream@gmail.com (Caesar Wang)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 4/9] thermal: rockchip: handle the power sequence for tsadc controller
Date: Tue, 3 May 2016 10:27:26 +0800	[thread overview]
Message-ID: <57280C8E.5080406@gmail.com> (raw)
In-Reply-To: <20160428150432.GA20009@localhost.localdomain>



? 2016?04?28? 23:04, Eduardo Valentin ??:
> On Thu, Apr 28, 2016 at 09:50:29AM +0800, Caesar Wang wrote:
>>
>> ? 2016?04?28? 07:48, Eduardo Valentin ??:
>>> On Mon, Apr 18, 2016 at 11:35:56AM +0800, Caesar Wang wrote:
>>>> +		regmap_write(grf, GRF_TSADC_TESTBIT_L, GRF_TSADC_TSEN_PD_ON);
>>>> +		mdelay(10);
>>>> +		regmap_write(grf, GRF_TSADC_TESTBIT_L, GRF_TSADC_TSEN_PD_OFF);
>>>> +		udelay(100); /* The spec note says at least 15 us */
>>>> +		regmap_write(grf, GRF_SARADC_TESTBIT, GRF_SARADC_TESTBIT_ON);
>>>> +		regmap_write(grf, GRF_TSADC_TESTBIT_H, GRF_TSADC_TESTBIT_H_ON);
>>>> +		udelay(200); /* The spec note says at least 90 us */
>>> Does it make sense to use usleep_range() instead?
>> I think so in the past, but I'm digging into the the udelay/usleep for
>> kernel.
> What do you mean by in the past? timekeeping doc still recommends the
> range 10us to 20ms for usleep_range()
>
>> In general,
>>
>> udelay < 10us ~100us
>> mdelay > 1m, <1000ms/HZ
>> usleep_range(min,max) > 100us, <20ms
> even here, your udelays could be replaced by usleep_range().
>
> Any particular reason you believe spining is better than sleeping in
> your case?
>
>> msleep > 20ms,  < 1000ms
>>
>> So the udelay is suit for tsadc power sequence.
>> ---
>>
>>
>> Also,  we have used the mdelay(10), so it doesn't matter if use the udelay.
>> After all the udelay is stable than the usleep_range.
> What do you mean udelay is stable than usleep_range? usleep_range will
> give the opportunity to the scheduler to coalesce wakeups. udelay is a
> busyloop spin. Besides, I am not sure the current situation, but
> busylooping may be affected by cpu frequency.

Okay, thanks for pointing out.

Send the fixes patch on https://patchwork.kernel.org/patch/8999971/

Thank you!


-Caesar
>
>> -Caesar
>>
>>> 1.9.1
>>>
>>>
>>>
>>>
>>> -- 
>>> Thanks,
>>> Caesar
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip


-- 
Thanks,
Caesar

  reply	other threads:[~2016-05-03  2:27 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-18  3:35 [PATCH 0/9] thermal: rockchip: Support rk3366/rk3399 SoCS and fixes the driver Caesar Wang
2016-04-18  3:35 ` Caesar Wang
2016-04-18  3:35 ` Caesar Wang
2016-04-18  3:35 ` [PATCH 1/9] thermal: rockchip: disable thermal->clk in err case Caesar Wang
2016-04-18  3:35   ` Caesar Wang
2016-04-18  3:35 ` [PATCH 2/9] thermal: rockchip: fixes the code_to_temp for tsadc driver Caesar Wang
2016-04-18  3:35   ` Caesar Wang
2016-04-18  3:35 ` [PATCH 3/9] thermal: rockchip: update the tsadc table for rk3399 Caesar Wang
2016-04-18  3:35   ` Caesar Wang
2016-04-18  3:35 ` [PATCH 4/9] thermal: rockchip: handle the power sequence for tsadc controller Caesar Wang
2016-04-18  3:35   ` Caesar Wang
2016-04-27 23:48   ` Eduardo Valentin
2016-04-27 23:48     ` Eduardo Valentin
     [not found]     ` <57216C65.5040501@gmail.com>
2016-04-28 15:04       ` Eduardo Valentin
2016-04-28 15:04         ` Eduardo Valentin
2016-05-03  2:27         ` Caesar Wang [this message]
2016-05-03  2:27           ` Caesar Wang
2016-04-18  3:35 ` [PATCH 5/9] thermal: rockchip: Support RK3366 SoCs in the thermal driver Caesar Wang
2016-04-18  3:35   ` Caesar Wang
2016-04-18  3:35 ` [PATCH 6/9] thermal: rockchip: add the notes for better reading Caesar Wang
2016-04-18  3:35   ` Caesar Wang
2016-04-18  3:35 ` [PATCH 7/9] thermal: of: Add support for hardware-tracked trip points Caesar Wang
2016-04-20 23:48   ` Eduardo Valentin
2016-04-21  1:12     ` Brian Norris
2016-04-22  1:54       ` Caesar Wang
2016-04-22  5:41         ` Sascha Hauer
2016-04-22 10:17           ` Caesar Wang
2016-04-27 21:50             ` Eduardo Valentin
2016-04-18  3:36 ` [PATCH 8/9] thermal: rockchip: add the set_trips function Caesar Wang
2016-04-18  3:36   ` Caesar Wang
2016-04-18  3:36 ` [PATCH 9/9] arm64: dts: rockchip: move the rk3368 thermal data into rk3368.dtsi Caesar Wang
2016-04-18  3:36   ` Caesar Wang
     [not found]   ` <1460950562-20652-10-git-send-email-wxt-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
2016-04-22  8:18     ` Heiko Stübner
2016-04-22  8:18       ` Heiko Stübner
2016-04-22  8:18       ` Heiko Stübner
2016-04-27 23:52 ` [PATCH 0/9] thermal: rockchip: Support rk3366/rk3399 SoCS and fixes the driver Eduardo Valentin
2016-04-27 23:52   ` Eduardo Valentin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=57280C8E.5080406@gmail.com \
    --to=caesar.upstream@gmail.com \
    --cc=briannorris@google.com \
    --cc=dianders@chromium.org \
    --cc=edubezval@gmail.com \
    --cc=heiko@sntech.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=rui.zhang@intel.com \
    --cc=smbarber@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.