mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Dmitry Osipenko <dmitry.osipenko@collabora.com>
To: Benjamin Bara <bbara93@gmail.com>, Wolfram Sang <wsa@kernel.org>,
	Lee Jones <lee@kernel.org>,
	rafael.j.wysocki@intel.com
Cc: jonathanh@nvidia.com, richard.leitner@linux.dev,
	treding@nvidia.com, linux-kernel@vger.kernel.org,
	linux-i2c@vger.kernel.org, linux-tegra@vger.kernel.org,
	Benjamin Bara <benjamin.bara@skidata.com>
Subject: Re: [PATCH v3 4/4] mfd: tps6586x: register restart handler
Date: Mon, 3 Apr 2023 01:30:09 +0300	[thread overview]
Message-ID: <6abaa803-1639-b949-3af5-05a341f9b459@collabora.com> (raw)
In-Reply-To: <20230327-tegra-pmic-reboot-v3-4-3c0ee3567e14@skidata.com>

On 3/27/23 16:57, Benjamin Bara wrote:
> From: Benjamin Bara <benjamin.bara@skidata.com>
> 
> There are a couple of boards which use a tps6586x as
> "ti,system-power-controller", e.g. the tegra20-tamonten.dtsi.
> For these, the only registered restart handler is the warm reboot via
> tegra's PMC. As the bootloader of the tegra20 requires the VDE, it must
> be ensured that VDE is enabled (which is the case after a cold reboot).
> For the "normal reboot", this is basically the case since
> 8f0c714ad9be1ef774c98e8819a7a571451cb019.
> However, this workaround is not executed in case of an emergency restart.
> In case of an emergency restart, the system now simply hangs in the
> bootloader, as VDE is not enabled (as not in use).
> 
> The TPS658629-Q1 (unfortunately the only TPS6586x with public data sheet)
> provides a SOFT RST bit in the SUPPLYENE reg to request a (cold) reboot.
> This avoids the hang-up.
> 
> Tested on a TPS658640.
> 
> Signed-off-by: Benjamin Bara <benjamin.bara@skidata.com>
> ---
>  drivers/mfd/tps6586x.c | 19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/drivers/mfd/tps6586x.c b/drivers/mfd/tps6586x.c
> index 93f1bf440191..c8adf6a08277 100644
> --- a/drivers/mfd/tps6586x.c
> +++ b/drivers/mfd/tps6586x.c
> @@ -30,6 +30,7 @@
>  #include <linux/mfd/tps6586x.h>
>  
>  #define TPS6586X_SUPPLYENE	0x14
> +#define SOFT_RST_BIT		BIT(0)
>  #define EXITSLREQ_BIT		BIT(1)
>  #define SLEEP_MODE_BIT		BIT(3)
>  
> @@ -470,6 +471,17 @@ static int tps6586x_power_off_handler(struct sys_off_data *data)
>  	return tps6586x_set_bits(tps6586x_dev, TPS6586X_SUPPLYENE, SLEEP_MODE_BIT);
>  }
>  
> +static int tps6586x_restart_handler(struct sys_off_data *data)
> +{
> +	struct device *tps6586x_dev = data->cb_data;
> +
> +	/* bring pmic into HARD REBOOT state */
> +	tps6586x_set_bits(tps6586x_dev, TPS6586X_SUPPLYENE, SOFT_RST_BIT);
> +
> +	mdelay(500);
Is this delay needed? There is no delay in a case of power off.

-- 
Best regards,
Dmitry


  reply	other threads:[~2023-04-02 22:30 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-27 13:57 [PATCH v3 0/4] " Benjamin Bara
2023-03-27 13:57 ` [PATCH v3 1/4] kernel/reboot: emergency_restart: set correct system_state Benjamin Bara
2023-03-27 13:57 ` [PATCH v3 2/4] i2c: core: run atomic i2c xfer when !preemptible Benjamin Bara
2023-03-27 14:54   ` Wolfram Sang
2023-03-27 16:23     ` Benjamin Bara
2023-03-29 19:50       ` Wolfram Sang
2023-04-02 10:04         ` Benjamin Bara
2023-04-04  8:22           ` Peter Zijlstra
2023-04-04 14:06             ` Benjamin Bara
2023-03-27 13:57 ` [PATCH v3 3/4] mfd: tps6586x: use devm-based power off handler Benjamin Bara
2023-04-02 22:28   ` Dmitry Osipenko
2023-03-27 13:57 ` [PATCH v3 4/4] mfd: tps6586x: register restart handler Benjamin Bara
2023-04-02 22:30   ` Dmitry Osipenko [this message]
2023-04-03  6:50     ` Benjamin Bara
2023-04-03 15:44       ` Dmitry Osipenko

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=6abaa803-1639-b949-3af5-05a341f9b459@collabora.com \
    --to=dmitry.osipenko@collabora.com \
    --cc=bbara93@gmail.com \
    --cc=benjamin.bara@skidata.com \
    --cc=jonathanh@nvidia.com \
    --cc=lee@kernel.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=rafael.j.wysocki@intel.com \
    --cc=richard.leitner@linux.dev \
    --cc=treding@nvidia.com \
    --cc=wsa@kernel.org \
    /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

all inboxes | Powered by JetHome®