From: Jerome Brunet <jbrunet@baylibre.com>
To: linux-amlogic@lists.infradead.org,
Kevin Hilman <khilman@baylibre.com>,
Neil Armstrong <narmstrong@baylibre.com>
Cc: linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org
Subject: Re: [PATCH v2 2/2] soc: amlogic: ee-pwrc: ensure driver state maches HW state
Date: Mon, 30 Sep 2019 10:22:28 +0200 [thread overview]
Message-ID: <1jd0fi19dn.fsf@starbuckisacylon.baylibre.com> (raw)
In-Reply-To: <21eafa69-fe26-2df1-d187-cddfe5b37951@baylibre.com>
On Fri 27 Sep 2019 at 08:37, Neil Armstrong <narmstrong@baylibre.com> wrote:
> On 26/09/2019 21:08, Kevin Hilman wrote:
>> Neil Armstrong <narmstrong@baylibre.com> writes:
>>
>>> On 25/09/2019 23:35, Kevin Hilman wrote:
>>>> From: Kevin Hilman <khilman@baylibre.com>
>>>>
>>>> During init, ensure that the driver on/off state as well as clock and
>>>> reset state matches the hardware state. Do this by always calling the
>>>> drivers 'on' function, and then callling the 'off' function if the
>>>> HW state was initially detected as off.
>>
>> [...]
>>
>>> I don't see what you are trying to solve except simplifying the code.
>>
>> Simplifying the code is a worthwhile goal on its own, but that's not the
>> only thing I'm tring to accomplish.
>
> I still find it ugly to power_on a domain to power it off right afterwards.
> The issue is with the CCF enable handling which is not in sync with the
> HW, if you boot with an already enabled clock, it won't be marked enabled
> in CCF, and it's clearly bad when you want to have a fine-tuned gate state
> handling.
>
CCF should disable unused clock so, in theory, you should not have to
call enable() then disable() to get things in sync.
I suppose the clock in question has the flag CLK_IGNORE_UNUSED (one of
the gates) ?
If the CLK_INGORE_UNUSED is becoming a problem, it would be better to
fix the clock tree rather than adding quirks in consumers.
_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic
next prev parent reply other threads:[~2019-09-30 8:24 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-25 21:35 [PATCH v2 0/2] soc: amlogic: ee-pwrc: cleanup init state Kevin Hilman
2019-09-25 21:35 ` [PATCH v2 1/2] soc: amlogic: ee-pwrc: rename get_power Kevin Hilman
2019-09-25 21:35 ` [PATCH v2 2/2] soc: amlogic: ee-pwrc: ensure driver state maches HW state Kevin Hilman
2019-09-26 9:05 ` Neil Armstrong
2019-09-26 19:08 ` Kevin Hilman
2019-09-27 6:37 ` Neil Armstrong
2019-09-27 16:02 ` Kevin Hilman
2019-09-30 8:22 ` Jerome Brunet [this message]
2019-09-30 15:32 ` Kevin Hilman
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=1jd0fi19dn.fsf@starbuckisacylon.baylibre.com \
--to=jbrunet@baylibre.com \
--cc=khilman@baylibre.com \
--cc=linux-amlogic@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-pm@vger.kernel.org \
--cc=narmstrong@baylibre.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).