Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp4878169pxb; Thu, 14 Oct 2021 13:55:10 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyvbFznefIzaACrZ5cqrJCue5SNXKbBPcv6GRXEzIvLemk59xqMUm7o4pd6dmEb4FBmOqt0 X-Received: by 2002:a05:6402:5112:: with SMTP id m18mr11556622edd.101.1634244910529; Thu, 14 Oct 2021 13:55:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634244910; cv=none; d=google.com; s=arc-20160816; b=Sl3Grud6hc35h6RoIqIteiwcFDHMsR2DyRe9/x7Ps2SaDiuQNYsYgb59sEiftORTPl wTXEKEEIBmLQZybzwdodv8uKDciFN32cEtJeGLX9vnooT5tkstnwkI/YC4wRLjsQGUT2 +NmE1PDWf5R91rutcNzNyGKsPw//UPKmmuqlQ58/AL2Qy7C+7L61tHjxmCu7jr8xQ6Y9 U2UkeAPP1XOLZUTWnQY6BngrNObI/d/gzMvXOujhPStFPuSlrvcQU8cbpSc3K2KvH7U5 jB6aBXjkm2AGjlxoPPaAPomRWMy7hU6nAfS4Zjvh2H4fr1UMue7z/zdX6pC3hYkWVoHW pezw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=ibIaPrB4h2yeafzdyejc/m3tdIsM4DZm3oUCx/6wbuk=; b=oT9vbczkhe1TrKd/1Swu/XrT8t9OP4S9acOmpWWR9f8nAtfzX7fXEJW8Puno3ugpnh nM2SSEutYwzRRiYeGrs2uDKhb26lVcLRlB8XgP3urNNOX5fhxdSc6kqt7jvQyQWMu8oJ ug238eTkmsI1TXdPiO5VqDaiv8I33abpx56ICnKmusKD+LsyDlf0LWPKVgtg1s3/mFGr wIN4jkrqpTl1anp0bbCg1Jqr+IDT4D9JiEFfm4dN9SIqkqJUz5RhmSIbZQSqtkXtyYYI uK7T3A/+Mhit5h8vJixooAVbsfzRMvc2u6j+6jqjsFaet5MzQ34i04owB+WjqfnXJcPC O2ng== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@canonical.com header.s=20210705 header.b=M7BGNDKG; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=canonical.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id cr12si7054912ejc.593.2021.10.14.13.54.46; Thu, 14 Oct 2021 13:55:10 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@canonical.com header.s=20210705 header.b=M7BGNDKG; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=canonical.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231787AbhJNPxl (ORCPT + 99 others); Thu, 14 Oct 2021 11:53:41 -0400 Received: from smtp-relay-internal-0.canonical.com ([185.125.188.122]:33298 "EHLO smtp-relay-internal-0.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230109AbhJNPxk (ORCPT ); Thu, 14 Oct 2021 11:53:40 -0400 Received: from mail-ed1-f70.google.com (mail-ed1-f70.google.com [209.85.208.70]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-0.canonical.com (Postfix) with ESMTPS id C65E93F077 for ; Thu, 14 Oct 2021 15:51:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1634226693; bh=ibIaPrB4h2yeafzdyejc/m3tdIsM4DZm3oUCx/6wbuk=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=M7BGNDKG+rN3EsS7z0lbyFU3gtlIVdo63m8DXNJhX8M0IWAwkwuSARfNXEkswg/RN l52tEizDZYQx1AxO9SXeCQskFoyPwjW8+J9s80HkNCBiDEcPJmT7/usqCVFDbC6TXg tGTCJU3r83SQq4uHcg4i4/GnNFkLz0CcWH3ZYGdWdpuWlD+wnStL9rphg1eYQOBsvN DwzgjqyhGDcedzbbjCr5IrntYLZsRiK2OUown51jZYfFGLozi+f08KWllry3V4Fa0t iFrer7zGZnb6ZulYN4InLFaNlzprK+jgFFRK5jGsoTZwx3NFTzIzGzeolgybiL+HGu X8gDkNvlGyh0Q== Received: by mail-ed1-f70.google.com with SMTP id z23-20020aa7cf97000000b003db7be405e1so5570434edx.13 for ; Thu, 14 Oct 2021 08:51:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ibIaPrB4h2yeafzdyejc/m3tdIsM4DZm3oUCx/6wbuk=; b=hgHCHZ0SMLbxlXvdwGuzIZ7LKWYFa3gZxPWap5gCU7NOyULYxAsaqM/Cjo1WsrM9S+ RgVQ3v7Ox+7slRN/7DKn4X89qVlsn4VcshFnynD7M7GxElWjuo4wt4zWMYzk37kYqGSP 8hpvy+exoAE5H7BlyYx9pQGFBgiiy8GngwXlJCXzdYIpUTAhGjKoY5cBZdGdafnrveBa jFoU6bqRDDKZkndGKdz90buc0h1Iu+vhZkldzm5RYPKOAB/tbNcE17Z+r9kCZHK1E1cA hwbLL929eWxLSZH/DhMgJxL3pva0PLvfaGZDLug+0Il4akzYMD3WTTM+z1OrVfPinckc 6Vpw== X-Gm-Message-State: AOAM530Hf9VwpTEEeZhclSni6o1ljj52xH5JmDPQjNDDrK6q9uH/vu84 MVUIIBjWL1TqgtfG2njt7S1JL/lcSrLWQ6bRFnLToEquuMCroyBYRNpgpxeBhOML678Iw9uSPy3 zGz/B/PImimoYC4X7mVBrn2/nNDGWnNkncdOr2GkLK1Dc0/vH9iXfeQ1SDQ== X-Received: by 2002:a05:6402:1c85:: with SMTP id cy5mr9872549edb.281.1634226693486; Thu, 14 Oct 2021 08:51:33 -0700 (PDT) X-Received: by 2002:a05:6402:1c85:: with SMTP id cy5mr9872535edb.281.1634226693319; Thu, 14 Oct 2021 08:51:33 -0700 (PDT) MIME-Version: 1.0 References: <20210921053356.1705833-1-alexandre.ghiti@canonical.com> In-Reply-To: From: Alexandre Ghiti Date: Thu, 14 Oct 2021 17:51:22 +0200 Message-ID: Subject: Re: [PATCH] drivers: mfd: da9063: Add restart notifier implementation To: Adam Thomson Cc: David Abdurachmanov , Support Opensource , Lee Jones , "linux-riscv@lists.infradead.org" , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Adam, On Tue, Oct 12, 2021 at 12:33 PM Adam Thomson wrote: > > On 08 October 2021 10:46, Adam Thomson wrote: > > > > > Thanks for the info. So we believe, based on the event registers values > > > > provided, it is the RTC event as that's not cleared by a power-cycle (it's in > > > > the always-on domain). The other test would be to mask this event > > > immediately > > > > after an RTC based reboot and see if the long key-press then shuts down the > > > > device. I suspect it would in that case, as per you clearing the event. > > > > > > Indeed if I mask the RTC alarm in IRQ_MASK_A, the intempestive reboot > > > disappears. But that's not something we can do: the reset driver will > > > actually be implemented in openSBI at some point where the devices are > > > probed on-demand (the same applies to u-boot I think), so we cannot > > > clear or mask anything at boot. > > > > > > > > > > > I'm still curious as to the 16 seconds though. Would that be when the kernel > > > > finally starts and masks/clears events (seems quite a long time)? > > > > > > No, the kernel is not up yet. Maybe 16sec is not the right value, I > > > may have been influenced by the discussion here > > > https://www.dialog-semiconductor.com/products/pmics?post_id=10052#tab- > > > support_tab_content. > > > > > > It seems there is some consensus about having this reset driver be a > > > SiFive Unmatched board specific thing: quid of the sequence I propose > > > in this patch then? It does not mess with the RTC registers, it > > > reboots reliably and there's no intempestive reboot: is it dangerous > > > to use? Or do you have another alternative? > > > > Yes, a board specific implementation would be the way to go. We're just checking > > through the sequence again to be absolutely sure of any pitfalls that may > > present themselves, and will get back to you when we have something more. > > So having examined your sequence again it's now clearer as to what is happening. > With the sequence you provided this is only a partial reset whereby all of the > output rails are sequenced down then up again and restored to OTP voltages. > However the remainder of the chip settings aren't reset as this isn't a true > reset of the device going through full reload from OTP, so for example settings > of regulator mode GPIO states, or IRQ mask bits would persist on the restart, > which could have implications on system operation. Ok, it's not perfect but I think those are settings that will get reinitialized by the corresponding drivers while booting, contrary to the RTC registers which are clobbered by the other method. > > In addition the only bits of interest for you should be: > > - CONTROL_F (0x13) > WAKE_UP (BIT 2) = 1 > - CONTROL_A (0x0E) > SYSTEM_EN (BIT 0) = 0 > > Setting those two bits should be enough to trigger the partial reset sequence. > The other bits you had in your sequence don't seem to be necessary or relevant. > > One final caveat to this approach is that there is a 16s internal timer (as you > noted before, VDD_START) which is started when the device moves to ACTIVE mode. > When that 16s timer expires the device will clear the WAKE_UP bit automatically. > This means there's the outside chance that you could try the reset command > sequence above around the same time, and that could mean you set the WAKE_UP > bit, but it's immediately cleared again by this timer expiry before the > SYSTEM_EN bit is set low. In that case there would be a need for an external > event (e.g. ONKEY) to kick the system to start again. Ok, the risk exists but the window is quite small. After all, the solution I first proposed is not perfect, but now we know why it works and IMO it has less drawbacks than using the RTC registers, so I think we should go for this solution. I'll see if I can help Nikita implement this directly in openSBI. @Adam Thomson I had migrated the DA9063 device tree bindings to yaml, I'll push that soon. Thanks for all your help, much appreciated. Thanks, Alex