Re: [PATCH v6 3/3] watchdog: zx2967: add watchdog controller driver for ZTE's zx2967 family

On 31 January 2017 at 00:53, Guenter Roeck [off-list ref] wrote:

On Fri, Jan 27, 2017 at 10:40:09AM +0800, Baoyou Xie wrote:

quoted

On 27 January 2017 at 00:17, Mathieu Poirier <mathieu.poirier@linaro.org

wrote:

quoted

On Thu, Jan 26, 2017 at 09:32:56AM +0800, Baoyou Xie wrote:

quoted

On 26 January 2017 at 00:23, Mathieu Poirier <

mathieu.poirier@linaro.org

quoted

quoted

quoted

wrote:

quoted

On Wed, Jan 25, 2017 at 10:44:49AM +0800, Baoyou Xie wrote:

quoted

This patch adds watchdog controller driver for ZTE's zx2967

family.

quoted

quoted

quoted

quoted

quoted

Signed-off-by: Baoyou Xie <redacted>
---

[ ... ]

quoted

quoted

quoted

quoted

quoted

+     reset_control_assert(rstc);
+     usleep_range(500, 20000);

Alright, I'm officially confused.

First and foremost you still haven't provided an explanation as to

why

quoted

quoted

quoted

quoted

this is
required.  Second, in your previous submission you had:

        mdelay(10);

That is a busy loop of 10ms.  In this post using usleep_range() is

a

quoted

quoted

step

quoted

quoted

in the
right direction but the min and max values to wait for don't make

sense.

quoted

quoted

Here
you have 500 and 20000, which is 0.5ms and 20ms.

In fact, sleeping for 0.5ms is enough.

we extended the sleeping time to 20ms, the purpose is merging the

timer

quoted

quoted

quoted

interrupts. of course, it's happy to replace it with

usleep_range(500,

quoted

quoted

quoted

1000).

"merging the timer interrupts" - you mean trying to get the WD tick to

be

quoted

quoted

closer
to other timers?  If so I really don't see why.  Timers are

asynchronous by

quoted

quoted

nature and there can be dozens of them enabled at any given time.

Really?

Even if the system runs asynchronously, early process may trigger delayed
process, for example delayed work queue or timers, we can merge our
watchdog timer and those delayed work's timers.

In the probe function ?

quoted

Furthermore, what happen if we build this driver as module?

If every driver writer would use that line of argument, booting would
take much longer than necessary, with every process sitting on unnecessary
wait or sleep calls for perceived "optimization" purposes. Probe functions
run exactly once, and should be time optimized. You should have an idea
what the minimum reset hold time is, and follow it.

quoted

But, as i said early, it's a trial optimization but can be instead with
usleep_range(500, 1000).

In some case, such optimization is helpful. I'd like to talk a story

here,

quoted

about before ten years, I pressed a return key in console, you know, in
this case, a process be created and exited, so the cpu core that process
run at sent an IPI to other CPU, IPI interrupt resulted in the

performance

quoted

decreased by 20%, so sad:)

It appears to be somewhat unlikely that each keypress resulted in a driver
being instantiated. If it did, a sleep in its probe function was the least
of your problems.

quoted

Unless there is a H/W constraint requiring a delay between the

quoted

assert/deassert
of the WD, I don't think adding a wait operation (of any kind) make

sense.

Correct.

I have discussed with hardware and reset driver engineers, It's better to
place usleep_range call into reset driver, so we're happy to remove
usleep_range
here.

So, I will send a new patch that remove it.

Guenter