public inbox for linux-mmc@vger.kernel.org
 help / color / mirror / Atom feed
From: Judith Mendez <jm@ti.com>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>,
	<linux-mmc@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] mmc: sdhci_am654: Add tuning debug prints
Date: Tue, 20 Aug 2024 09:40:59 -0500	[thread overview]
Message-ID: <acbf7997-6989-4de6-bf25-3b5589ad2eb9@ti.com> (raw)
In-Reply-To: <CAPDyKFpb0o2w9=nRp98XnqoLKtFOCDssJzy+53mg1bW8y0UmUw@mail.gmail.com>

Hi Ulf Hansson,

On 8/20/24 6:33 AM, Ulf Hansson wrote:
> On Thu, 15 Aug 2024 at 22:15, Judith Mendez <jm@ti.com> wrote:
>>
>> Add debug prints to tuning algorithm for debugging.
>>
>> Signed-off-by: Judith Mendez <jm@ti.com>
>> ---
>>   drivers/mmc/host/sdhci_am654.c | 5 +++++
>>   1 file changed, 5 insertions(+)
>>
>> diff --git a/drivers/mmc/host/sdhci_am654.c b/drivers/mmc/host/sdhci_am654.c
>> index c3d485bd4d553..a909f8de0eabe 100644
>> --- a/drivers/mmc/host/sdhci_am654.c
>> +++ b/drivers/mmc/host/sdhci_am654.c
>> @@ -457,11 +457,13 @@ static u32 sdhci_am654_calculate_itap(struct sdhci_host *host, struct window
>>
>>          if (!num_fails) {
>>                  /* Retry tuning */
>> +               dev_err(dev, "No failing region found, retry tuning\n");
> 
> A dev_err seems to be too heavy, but I am not sure at what frequency
> this could occur?

Having no failing region is what we call a corner case, it rarely 
happens. The one case where it did happen, it took a good amount
of time to discover there were no failing regions found. The tuning
algorithm had to be looped 3 times before finding a failing itapdly.

> 
> Why isn't a dev_dbg sufficient?

I thought about using dev_dbg, but based on some feedback after coming
upon this issue on a board bring up case, we think it would help
enormously if we make it as obvious as possible when no failing region
is found.

The one case where this came up, the dev_err print would only print 3
times... Now this is only one case and we are not aware of any more
cases like this, also we cannot replicate on TI EVM's.

> 
>>                  return -1;
>>          }
>>
>>          if (fail_window->length == ITAPDLY_LENGTH) {
>>                  /* Retry tuning */
>> +               dev_err(dev, "No passing ITAPDLY, retry tuning\n");
> 
> Ditto.

Same idea as above..

But with this print, the maximum amount of prints that could be printed
is 20, is this too many prints in your opinion?


> 
>>                  return -1;
>>          }
>>
>> @@ -505,6 +507,7 @@ static int sdhci_am654_platform_execute_tuning(struct sdhci_host *host,
>>          struct sdhci_am654_data *sdhci_am654 = sdhci_pltfm_priv(pltfm_host);
>>          unsigned char timing = host->mmc->ios.timing;
>>          struct window fail_window[ITAPDLY_LENGTH];
>> +       struct device *dev = mmc_dev(host->mmc);
>>          u8 curr_pass, itap;
>>          u8 fail_index = 0;
>>          u8 prev_pass = 1;
>> @@ -542,12 +545,14 @@ static int sdhci_am654_platform_execute_tuning(struct sdhci_host *host,
>>
>>          if (ret >= 0) {
>>                  itap = ret;
>> +               dev_dbg(dev, "Final ITAPDLY=%d\n", itap);
>>                  sdhci_am654_write_itapdly(sdhci_am654, itap, sdhci_am654->itap_del_ena[timing]);
>>          } else {
>>                  if (sdhci_am654->tuning_loop < RETRY_TUNING_MAX) {
>>                          sdhci_am654->tuning_loop++;
>>                          sdhci_am654_platform_execute_tuning(host, opcode);
>>                  } else {
>> +                       dev_err(dev, "Failed to find ITAPDLY, fail tuning\n");
> 
> The commit message only talks about debug messages, but this is an
> error message. Perhaps update the commit message a bit?

Sure will do, after we conclude the discussion above and in v2.

Thanks so much for reviewing.

~ Judith

> 
>>                          return -1;
>>                  }
>>          }
>> --
>> 2.46.0
>>
> 
> Kind regards
> Uffe


  reply	other threads:[~2024-08-20 14:41 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-15 20:15 [PATCH 0/2] Add retry tuning sequence Judith Mendez
2024-08-15 20:15 ` [PATCH 1/2] mmc: sdhci_am654: Add retry tuning Judith Mendez
2024-08-20 14:47   ` Judith Mendez
2024-08-21  5:37   ` Adrian Hunter
2024-08-21 14:14     ` Judith Mendez
2024-08-15 20:15 ` [PATCH 2/2] mmc: sdhci_am654: Add tuning debug prints Judith Mendez
2024-08-20 11:33   ` Ulf Hansson
2024-08-20 14:40     ` Judith Mendez [this message]
2024-08-20 15:03       ` Ulf Hansson
2024-08-20 20:17         ` Judith Mendez
2024-08-20 20:18         ` Judith Mendez

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=acbf7997-6989-4de6-bf25-3b5589ad2eb9@ti.com \
    --to=jm@ti.com \
    --cc=adrian.hunter@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --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