linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Adrian Hunter <adrian.hunter@intel.com>
To: "Michał Mirosław" <mirq-linux@rere.qmqm.pl>
Cc: Kevin Liu <kliu5@marvell.com>,
	Michal Simek <michal.simek@xilinx.com>,
	Suneel Garapati <suneel.garapati@xilinx.com>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org,
	Al Cooper <alcooperx@gmail.com>
Subject: Re: [PATCH v4 2/5] mmc: sdhci: always obey programmable clock config in preset value
Date: Thu, 12 Aug 2021 12:54:23 +0300	[thread overview]
Message-ID: <38e93996-d815-1b62-8d93-8b9bbed384a6@intel.com> (raw)
In-Reply-To: <YQ6TEhMLXH/4r4BS@qmqm.qmqm.pl>

On 7/08/21 5:05 pm, Michał Mirosław wrote:
> On Wed, Aug 04, 2021 at 01:52:21PM +0300, Adrian Hunter wrote:
>> On 25/07/21 12:20 pm, Michał Mirosław wrote:
>>> When host controller uses programmable clock presets but doesn't
>>> advertise programmable clock support, we can only guess what frequency
>>> it generates. Let's at least return correct SDHCI_PROG_CLOCK_MODE bit
>>> value in this case.
>> If the preset value doesn't make sense, why use it at all?
> 
> If I understand the spec correctly, when the preset value is used the
> values in Clock Control register are ignored by the module and so the
> module can also actually use a different clock source than the ones
> available to the driver directly.

I don't remember, does it say that in the spec?

>                                   So either way the driver can't be
> sure of the exact frequencu used. This is a cleanup to remove a case
> when the code ignores a bit's value based on other unspecified assumptions.

Is this fixing a real issue?  It seems like switching from one undefined
scenario to another.  Are either of which known to have ever happened?

Perhaps we should leave it as is.

> 
> [...]
>>> --- a/drivers/mmc/host/sdhci.c
>>> +++ b/drivers/mmc/host/sdhci.c
>>> @@ -1859,11 +1859,14 @@ u16 sdhci_calc_clk(struct sdhci_host *host, unsigned int clock,
>>>  
>>>  			pre_val = sdhci_get_preset_value(host);
>>>  			div = FIELD_GET(SDHCI_PRESET_SDCLK_FREQ_MASK, pre_val);
>>> -			if (host->clk_mul &&
>>> -				(pre_val & SDHCI_PRESET_CLKGEN_SEL)) {
>>> +			if (pre_val & SDHCI_PRESET_CLKGEN_SEL) {
>>>  				clk = SDHCI_PROG_CLOCK_MODE;
>>>  				real_div = div + 1;
>>>  				clk_mul = host->clk_mul;
>>> +				if (!clk_mul) {
>>> +					/* The clock frequency is unknown. Assume undivided base. */
>>> +					clk_mul = 1;
>>> +				}
>>>  			} else {
>>>  				real_div = max_t(int, 1, div << 1);
>>>  			}


  reply	other threads:[~2021-08-12  9:54 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-25  9:20 [PATCH v4 0/5] SDHCI clock handling fixes and cleanups Michał Mirosław
2021-07-25  9:20 ` [PATCH v4 1/5] mmc: sdhci: fix base clock usage in preset value Michał Mirosław
2021-08-04 10:50   ` Adrian Hunter
2021-07-25  9:20 ` [PATCH v4 2/5] mmc: sdhci: always obey programmable clock config " Michał Mirosław
2021-08-04 10:52   ` Adrian Hunter
2021-08-07 14:05     ` Michał Mirosław
2021-08-12  9:54       ` Adrian Hunter [this message]
2021-07-25  9:20 ` [PATCH v4 3/5] mmc: sdhci: fix SDHCI_QUIRK2_CLOCK_DIV_ZERO_BROKEN Michał Mirosław
2021-08-04 11:06   ` Adrian Hunter
2021-08-07 14:08     ` Michał Mirosław
2021-07-25  9:20 ` [PATCH v4 5/5] mmc: sdhci: simplify v2/v3+ clock calculation Michał Mirosław
2021-08-04 12:40   ` Adrian Hunter
2021-08-07 15:39     ` Michał Mirosław
2021-07-25  9:20 ` [PATCH v4 4/5] mmc: sdhci: move SDHCI_QUIRK2_CLOCK_DIV_ZERO_BROKEN frequency limit Michał Mirosław
2021-08-04 12:33   ` Adrian Hunter
2021-08-07 14:12     ` Michał Mirosław
2021-08-12 10:01       ` Adrian Hunter

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=38e93996-d815-1b62-8d93-8b9bbed384a6@intel.com \
    --to=adrian.hunter@intel.com \
    --cc=alcooperx@gmail.com \
    --cc=kliu5@marvell.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=michal.simek@xilinx.com \
    --cc=mirq-linux@rere.qmqm.pl \
    --cc=suneel.garapati@xilinx.com \
    --cc=ulf.hansson@linaro.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;
as well as URLs for NNTP newsgroup(s).