All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Osipenko <digetx@gmail.com>
To: Chanwoo Choi <cw00.choi@samsung.com>,
	Dan Carpenter <dan.carpenter@oracle.com>
Cc: MyungJoo Ham <myungjoo.ham@samsung.com>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	Thierry Reding <thierry.reding@gmail.com>,
	Jonathan Hunter <jonathanh@nvidia.com>,
	linux-pm@vger.kernel.org, linux-tegra@vger.kernel.org,
	kernel-janitors@vger.kernel.org
Subject: Re: [PATCH] PM / devfreq: tegra30: disable clock on error in probe
Date: Fri, 18 Sep 2020 00:14:24 +0300	[thread overview]
Message-ID: <57e8ccad-f0d5-febb-7a31-8d34430a5cb8@gmail.com> (raw)
In-Reply-To: <8edcfd7b-110b-3886-64ee-3ec02cc6bd19@samsung.com>

17.09.2020 05:32, Chanwoo Choi пишет:
...
>> There is no need to deassert the reset if clk-enable fails because reset
>> control of tegra30-devfreq is exclusive, i.e it isn't shared with any
>> other peripherals, and thus, reset control could asserted/deasserted at
>> any time by the devfreq driver. If clk-enable fails, then reset will
>> stay asserted and it will be fine to re-assert it again.
>>
> 
> Thanks for the detailed explanation. 
> But, I think that almost people don't know the detailed h/w information.
> If possible, how about matching the pair when clk-enable fails as following?
> 
> --- a/drivers/devfreq/tegra30-devfreq.c
> +++ b/drivers/devfreq/tegra30-devfreq.c
> @@ -828,6 +828,7 @@ static int tegra_devfreq_probe(struct platform_device *pdev)
>         if (err) {
>                 dev_err(&pdev->dev,
>                         "Failed to prepare and enable ACTMON clock\n");
> +               reset_control_deassert(tegra->reset);
>                 return err;
>         }

That change won't bring any real benefits and will confuse people who
know the HW, so we shouldn't do it.

Since the interrupt is disabled by default at the probe time, we
actually don't need to care in a what state ACTMON hardware is at the
driver-probe time since even if HW is active, it won't cause any damage
to the system since ACTMON only collects and processes stats.

I made some experiments and looks like at least on Tegra30 the ACTMON
hardware block uses multiple clocks and the ACTMON-clk isn't strictly
necessary for the resetting of the HW state, it's actually quite common
for Tegra peripherals that a part of HW logic runs off some root clk.

Hence if we want to improve the code, I think we can make this change:

diff --git a/drivers/devfreq/tegra30-devfreq.c
b/drivers/devfreq/tegra30-devfreq.c
index ee274daa57ac..4e3ac23e6850 100644
--- a/drivers/devfreq/tegra30-devfreq.c
+++ b/drivers/devfreq/tegra30-devfreq.c
@@ -891,8 +891,6 @@ static int tegra_devfreq_probe(struct
platform_device *pdev)
 		return err;
 	}

-	reset_control_assert(tegra->reset);
-
 	err = clk_prepare_enable(tegra->clock);
 	if (err) {
 		dev_err(&pdev->dev,
@@ -900,7 +898,7 @@ static int tegra_devfreq_probe(struct
platform_device *pdev)
 		return err;
 	}

-	reset_control_deassert(tegra->reset);
+	reset_control_reset(tegra->reset);

 	for (i = 0; i < mc->num_timings; i++) {
 		/*

WARNING: multiple messages have this Message-ID (diff)
From: Dmitry Osipenko <digetx@gmail.com>
To: Chanwoo Choi <cw00.choi@samsung.com>,
	Dan Carpenter <dan.carpenter@oracle.com>
Cc: MyungJoo Ham <myungjoo.ham@samsung.com>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	Thierry Reding <thierry.reding@gmail.com>,
	Jonathan Hunter <jonathanh@nvidia.com>,
	linux-pm@vger.kernel.org, linux-tegra@vger.kernel.org,
	kernel-janitors@vger.kernel.org
Subject: Re: [PATCH] PM / devfreq: tegra30: disable clock on error in probe
Date: Thu, 17 Sep 2020 21:14:24 +0000	[thread overview]
Message-ID: <57e8ccad-f0d5-febb-7a31-8d34430a5cb8@gmail.com> (raw)
In-Reply-To: <8edcfd7b-110b-3886-64ee-3ec02cc6bd19@samsung.com>

17.09.2020 05:32, Chanwoo Choi пишет:
...
>> There is no need to deassert the reset if clk-enable fails because reset
>> control of tegra30-devfreq is exclusive, i.e it isn't shared with any
>> other peripherals, and thus, reset control could asserted/deasserted at
>> any time by the devfreq driver. If clk-enable fails, then reset will
>> stay asserted and it will be fine to re-assert it again.
>>
> 
> Thanks for the detailed explanation. 
> But, I think that almost people don't know the detailed h/w information.
> If possible, how about matching the pair when clk-enable fails as following?
> 
> --- a/drivers/devfreq/tegra30-devfreq.c
> +++ b/drivers/devfreq/tegra30-devfreq.c
> @@ -828,6 +828,7 @@ static int tegra_devfreq_probe(struct platform_device *pdev)
>         if (err) {
>                 dev_err(&pdev->dev,
>                         "Failed to prepare and enable ACTMON clock\n");
> +               reset_control_deassert(tegra->reset);
>                 return err;
>         }

That change won't bring any real benefits and will confuse people who
know the HW, so we shouldn't do it.

Since the interrupt is disabled by default at the probe time, we
actually don't need to care in a what state ACTMON hardware is at the
driver-probe time since even if HW is active, it won't cause any damage
to the system since ACTMON only collects and processes stats.

I made some experiments and looks like at least on Tegra30 the ACTMON
hardware block uses multiple clocks and the ACTMON-clk isn't strictly
necessary for the resetting of the HW state, it's actually quite common
for Tegra peripherals that a part of HW logic runs off some root clk.

Hence if we want to improve the code, I think we can make this change:

diff --git a/drivers/devfreq/tegra30-devfreq.c
b/drivers/devfreq/tegra30-devfreq.c
index ee274daa57ac..4e3ac23e6850 100644
--- a/drivers/devfreq/tegra30-devfreq.c
+++ b/drivers/devfreq/tegra30-devfreq.c
@@ -891,8 +891,6 @@ static int tegra_devfreq_probe(struct
platform_device *pdev)
 		return err;
 	}

-	reset_control_assert(tegra->reset);
-
 	err = clk_prepare_enable(tegra->clock);
 	if (err) {
 		dev_err(&pdev->dev,
@@ -900,7 +898,7 @@ static int tegra_devfreq_probe(struct
platform_device *pdev)
 		return err;
 	}

-	reset_control_deassert(tegra->reset);
+	reset_control_reset(tegra->reset);

 	for (i = 0; i < mc->num_timings; i++) {
 		/*

  reply	other threads:[~2020-09-17 21:23 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20200908072627epcas1p41f2c8c2730d42bd8935a40b0ab8122f7@epcas1p4.samsung.com>
2020-09-08  7:25 ` [PATCH] PM / devfreq: tegra30: disable clock on error in probe Dan Carpenter
2020-09-08  7:25   ` Dan Carpenter
2020-09-08 13:02   ` Dmitry Osipenko
2020-09-08 13:02     ` Dmitry Osipenko
2020-09-14  6:57   ` Chanwoo Choi
2020-09-14  7:09     ` Chanwoo Choi
2020-09-14 13:56     ` Dmitry Osipenko
2020-09-14 13:56       ` Dmitry Osipenko
2020-09-14 14:17       ` Dan Carpenter
2020-09-14 14:17         ` Dan Carpenter
2020-09-14 14:28         ` Dmitry Osipenko
2020-09-14 14:28           ` Dmitry Osipenko
2020-09-15  1:48       ` Chanwoo Choi
2020-09-15  2:00         ` Chanwoo Choi
2020-09-15  2:13         ` Chanwoo Choi
2020-09-15  2:13           ` Chanwoo Choi
2020-09-15 17:01           ` Dmitry Osipenko
2020-09-15 17:01             ` Dmitry Osipenko
2020-09-16  2:38             ` Chanwoo Choi
2020-09-16  2:38               ` Chanwoo Choi
2020-09-16 19:07               ` Dmitry Osipenko
2020-09-16 19:07                 ` Dmitry Osipenko
2020-09-17  2:32                 ` Chanwoo Choi
2020-09-17  2:32                   ` Chanwoo Choi
2020-09-17 21:14                   ` Dmitry Osipenko [this message]
2020-09-17 21:14                     ` Dmitry Osipenko
2020-09-18  9:23                     ` Chanwoo Choi
2020-09-18  9:23                       ` Chanwoo Choi
2020-09-20 21:37                       ` Dmitry Osipenko
2020-09-20 21:37                         ` Dmitry Osipenko
2020-09-23  0:23                         ` Dmitry Osipenko
2020-09-23  0:23                           ` Dmitry Osipenko
2020-09-23  0:42                           ` Chanwoo Choi
2020-09-23  0:42                             ` Chanwoo Choi
2020-09-14 13:57     ` Dan Carpenter
2020-09-14 13:57       ` Dan Carpenter

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=57e8ccad-f0d5-febb-7a31-8d34430a5cb8@gmail.com \
    --to=digetx@gmail.com \
    --cc=cw00.choi@samsung.com \
    --cc=dan.carpenter@oracle.com \
    --cc=jonathanh@nvidia.com \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=kyungmin.park@samsung.com \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=myungjoo.ham@samsung.com \
    --cc=thierry.reding@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.