From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Mon, 5 Mar 2018 09:40:27 -0500 Subject: [U-Boot] [PATCH] watchdog: omap_wdt: improve watchdog reset path In-Reply-To: References: <1519866948-25614-1-git-send-email-ruslan.bilovol@gmail.com> <20180301115353.1444cc65@jawa> <20180301143321.GN4311@bill-the-cat> Message-ID: <20180305144027.GH22474@bill-the-cat.ec.rr.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Sun, Mar 04, 2018 at 04:00:15PM +0200, Ruslan Bilovol wrote: > On Thu, Mar 1, 2018 at 4:33 PM, Tom Rini wrote: > > On Thu, Mar 01, 2018 at 04:10:44PM +0200, Ruslan Bilovol wrote: > >> Hi Lukasz, > >> > >> On Thu, Mar 1, 2018 at 12:53 PM, Lukasz Majewski wrote: > >> > Hi Ruslan, > >> > > >> >> Remove busy looping during watchdog reset. > >> >> Each polling of W_PEND_WTGR bit ("finish posted > >> >> write") after watchdog reset takes 120-140us > >> >> on BeagleBone Black board. Current U-Boot code > >> >> has watchdog resets in random places and often > >> >> there is situation when watchdog is reset > >> >> few times in a row in nested functions. > >> >> This adds extra delays and slows the whole system. > >> >> > >> >> Instead of polling W_PEND_WTGR bit, we skip > >> >> watchdog reset if the bit is set. Anyway, watchdog > >> >> is in the middle of reset *right now*, so we can > >> >> just return. > >> > > >> > It seems like similar problem may be in the Linux kernel driver: > >> > v4.16-rc1/source/drivers/watchdog/omap_wdt.c#L74 > >> > > >> > Linux driver also waits for the write. > >> > >> Right, Linux driver has similar code but it doesn't affect performance. > >> This is because of watchdog usage in Linux, it is enabled and > >> reset by userspace. This is quite rare event. > >> Moreover, since Linux has interrupts enabled and has scheduling, > >> such busy loops in the omap driver are not very different to > >> just mdelay() usage. The system can handle interrupts, and can > >> even do preemption if PREEMPT is enabled. > >> So use of such busy loops in that particular case shouldn't cause > >> any noticeable performance issues. > > > > True. But, can you also submit a patch to the kernel side (and CC me) ? > > That's far more likely to get the attention of the engineers that might > > know of corner cases with the various SoC families where we might need > > to keep doing what we're doing or other possible problems. Thanks! > > Do you mean just resend this patch, but include kernel watchdog > mailing list? Well, I'm going to set aside what I said here since we've gotten some TI folks to review the patch here. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: