From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752780AbcCDN40 (ORCPT ); Fri, 4 Mar 2016 08:56:26 -0500 Received: from bh-25.webhostbox.net ([208.91.199.152]:59721 "EHLO bh-25.webhostbox.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750993AbcCDN4X (ORCPT ); Fri, 4 Mar 2016 08:56:23 -0500 Subject: Re: [PATCH v1] watchdog: sama5d4_wdt: Reset delay on start To: Romain Izard References: <1457000979-15717-1-git-send-email-romain.izard.pro@gmail.com> <56D8E649.8030500@atmel.com> <56D91BDC.1030604@roeck-us.net> <56D988F0.8050803@roeck-us.net> Cc: "Yang, Wenyou" , LKML , linux-watchdog@vger.kernel.org, linux-arm-kernel , Wim Van Sebroeck , Nicolas Ferre From: Guenter Roeck Message-ID: <56D99404.60305@roeck-us.net> Date: Fri, 4 Mar 2016 05:56:20 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated_sender: linux@roeck-us.net X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - bh-25.webhostbox.net X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - roeck-us.net X-Get-Message-Sender-Via: bh-25.webhostbox.net: authenticated_id: linux@roeck-us.net X-Authenticated-Sender: bh-25.webhostbox.net: linux@roeck-us.net X-Source: X-Source-Args: X-Source-Dir: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/04/2016 05:26 AM, Romain Izard wrote: > 2016-03-04 14:09 GMT+01:00 Guenter Roeck : >> On 03/04/2016 01:06 AM, Romain Izard wrote: >>> 2016-03-04 6:23 GMT+01:00 Guenter Roeck : >>>> On 03/03/2016 05:35 PM, Yang, Wenyou wrote: >>>>> On 2016/3/3 18:29, Romain Izard wrote: >>>>>> >>>>>> If the internal counter is not refreshed when the watchdog is >>>>>> started for the first time, the watchdog will trigger very >>>>>> rapidly. For example, opening /dev/watchdog without writing in it >>>>>> will immediately trigger a reboot, instead of waiting for the >>>>>> delay to expire. >>>>>> >>>>>> To avoid this problem, reload the timer on opening the watchdog >>>>>> device. >>>>>> >>>>>> Command: "while sleep 5; do echo 1; done > /dev/watchdog" Before: >>>>>> system reset After: the watchdog runs correctly >>>>> >>>>> >>>>> I didn't reproduce your issue on my side, >>>>> >>>>> run the your commands as follows, it works fine, the system reset >>>>> doesn't happen. >>> >>> >>> I've just verified with the factory image provided on the SAMA5D2 >>> Xplained board. It does not display this behaviour. >>> >>> But the difference is that in the case without the issue, I'm using >>> the AT91bootstrap SPL, U-Boot, and the kernel from the QSPI chip. >>> When I have the issue, I have a U-Boot based SPL, U-Boot itself and >>> the kernel that come from the FAT partition of an SD-Card. >>> >>> Userspace does not seem to be involved in the issue, as I can >>> reproduce it both with my buildroot environment, and the Yocto >>> environment from the factory image. >>> >>>> Different chip revision ? Different chip type ? Different chip >>>> initialization by ROMMON ? >>>> >>>> Can we get exact chip revisions and types for both cases (working >>>> and not working), and (if it might be relevant) a dump of all >>>> associated chip registers ? >>> >>> >>> >>>>> I also check the WDT_MR register before and after enabling >>>>> watchdog, the WDV and WDD fields are correct. >>>>> >>>>> Can you check it again? thank you. >>> >>> >>> Working case: >>> MR on kernel startup: 0x3fffafff >>> MR after watchdog init: 0x0fffafff >>> MR after start: 0x0fff2fff >>> >>> Problem case: >>> MR on kernel startup: 0x00008000 >>> MR after watchdog init: 0x0fffafff >>> MR after start: 0x0fff2fff >>> >>> So this means that the counter reload does not seem to work very well >>> if WDD/WDV have been set to 0 in the past. The other question is why >>> does U-Boot (from the Atmel branch based on 2015.1) put this stange >>> value in this register. >>> >> >> Can you check the value of AT91_WDT_SR ? Maybe it tells us something. >> > I didn't report it because it contained 0 at all times. So no information. > >> Also, in the error case, can you check if the watchdog times out at all >> after you applied your patch ? > > It times out after 16s as expected, and reboot occurs correctly. > Interesting. So it looks like AT91_WDT_WDRSTT has to be set if the timer values in MR are changed from 0 to another value, or maybe after each timer value change. Wonder if that should be done in the init function, after MR is set (with the watchdog disabled). Thoughts, anyone ? Thanks, Guenter