From: Ahmad Fatoum <a.fatoum@pengutronix.de>
To: Marco Felsch <m.felsch@pengutronix.de>
Cc: barebox@lists.infradead.org
Subject: Re: [PATCH 2/2] mfd: da9063: fix watchdog ping execution
Date: Mon, 4 Nov 2019 10:57:56 +0100 [thread overview]
Message-ID: <e0c50c62-f320-4489-da43-f31604099da5@pengutronix.de> (raw)
In-Reply-To: <20191104094452.xxpoqvm6d33h4wnh@pengutronix.de>
Hello Marco,
On 11/4/19 10:44 AM, Marco Felsch wrote:
>> This means that your boot time would increase by 200 ms. If this matter to you,
>> you might want to change this, so watchdog_set_timeout is called only once.
>
> Increasing the delay isn't a big deal. But after we discussed it again I
> will send a v2 which handles the to fast pings by dropping those.
That would be an option too, but moving watchdog_set_timeout out of boot_entry
would benefit other platforms too.
>
>> And if you do so, you could drop this patch. The only other places that feed
>> the watchdog are the watchdog poller and the wd command. The watchdog poller
>> already waits 500 ms between pings and the command is meant for debugging/testing.
>> If someone wants to feed the watchdog that fast while testing, why prevent them?
>
> Becuase if the watchdog gets feeded to fast then the system gets
> reseted. So dropping the patch isn't a option.
If you move watchdog_set_timeout out of boot_entry, you'll only be able to feed the
watchdog too fast if you manually type wd 1; wd 1;, which I argue isn't really an issue
IMHO, but I am fine with what you implement either way.
>
>> (I assume you don't need to wait 200 ms between ping and disabling WDT, if you do,
>> one more place is the .priority watchdog device parameter in barebox-next
>
> Sorry, I don't get this. You don't need to wait 200ms between ping and
> disabling.
Just wanted to make sure that disabling the watchdog twice in rapdi succession doesn't
trigger the issue as well. All good.
Cheers
Ahmad
>
> Regards,
> Marco
>
>> Cheers
>> Ahmad
>>
>>>>>
>>>>> Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
>>>>> ---
>>>>> drivers/mfd/da9063.c | 11 +++++++++++
>>>>> 1 file changed, 11 insertions(+)
>>>>>
>>>>> diff --git a/drivers/mfd/da9063.c b/drivers/mfd/da9063.c
>>>>> index 4d459c7f18..ab57885240 100644
>>>>> --- a/drivers/mfd/da9063.c
>>>>> +++ b/drivers/mfd/da9063.c
>>>>> @@ -14,6 +14,7 @@
>>>>> */
>>>>>
>>>>> #include <common.h>
>>>>> +#include <clock.h>
>>>>> #include <driver.h>
>>>>> #include <gpio.h>
>>>>> #include <restart.h>
>>>>> @@ -33,6 +34,7 @@ struct da9063 {
>>>>> struct i2c_client *client1;
>>>>> struct device_d *dev;
>>>>> unsigned int timeout;
>>>>> + uint64_t last_ping;
>>>>> };
>>>>>
>>>>> /* forbidden/impossible value; timeout will be set to this value initially to
>>>>> @@ -237,6 +239,13 @@ static int da9063_watchdog_ping(struct da9063 *priv)
>>>>> int ret;
>>>>> u8 val;
>>>>>
>>>>> + /* We need to wait at least 200ms till we can resend a ping */
>>>>> + if (!is_timeout_non_interruptible(priv->last_ping, 200 * MSECOND)) {
>>>>> + dev_dbg(priv->dev, "active ping delay\n");
>>>>> + mdelay(50);
>>>>
>>>> I would expect to wait the missing time to 200ms here. Maybe doing
>>>> nothing in this case would be more appropriate here. I mean, why should
>>>> you slow down barebox here when some code triggers the watchdog too
>>>> often?
>>>>
>>>>> + return da9063_watchdog_ping(priv);
>>>>
>>>> Drop this, just fall through.
>>>
>>> Just prepared a v2 with a busy wait after discussed it with Lucas.
>>> Thanks for your input too :)
>>>
>>> Regards,
>>> Marco
>>>
>>>> Sascha
>>>>
>>>> --
>>>> Pengutronix e.K. | |
>>>> Industrial Linux Solutions | http://www.pengutronix.de/ |
>>>> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
>>>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
>>>>
>>>
>>
>> --
>> Pengutronix e.K. | |
>> Industrial Linux Solutions | http://www.pengutronix.de/ |
>> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
>> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
>>
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
next prev parent reply other threads:[~2019-11-04 9:58 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-30 17:06 [PATCH 1/2] mfd: da9063: fix TWDSCALE debug message Marco Felsch
2019-10-30 17:06 ` [PATCH 2/2] mfd: da9063: fix watchdog ping execution Marco Felsch
2019-11-04 8:27 ` Sascha Hauer
2019-11-04 8:34 ` Marco Felsch
2019-11-04 8:51 ` Ahmad Fatoum
2019-11-04 9:44 ` Marco Felsch
2019-11-04 9:57 ` Ahmad Fatoum [this message]
2019-11-04 10:13 ` Marco Felsch
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=e0c50c62-f320-4489-da43-f31604099da5@pengutronix.de \
--to=a.fatoum@pengutronix.de \
--cc=barebox@lists.infradead.org \
--cc=m.felsch@pengutronix.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox