From: Marten Lindahl <martenli@axis.com>
To: Doug Anderson <dianders@google.com>
Cc: "Mårten Lindahl" <Marten.Lindahl@axis.com>,
"Jaehoon Chung" <jh80.chung@samsung.com>,
"Ulf Hansson" <ulf.hansson@linaro.org>, kernel <kernel@axis.com>,
"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>
Subject: Re: [PATCH v4] mmc: dw_mmc: Allow lower TMOUT value than maximum
Date: Thu, 18 Nov 2021 11:51:13 +0100 [thread overview]
Message-ID: <20211118105113.GA3708@axis.com> (raw)
In-Reply-To: <CAD=FV=WWF9W=cXQWkcvQAgXjGZjBzgvV3jB90nZ35JYdi8YA-w@mail.gmail.com>
On Thu, Nov 18, 2021 at 12:29:46AM +0100, Doug Anderson wrote:
Hi Doug!
> Hi,
>
> On Wed, Nov 17, 2021 at 8:09 AM Mårten Lindahl <marten.lindahl@axis.com> wrote:
> >
> > The TMOUT register is always set with a full value for every transfer,
> > which (with a 200MHz clock) will give a full DRTO of ~84 milliseconds.
> > This is normally good enough to complete the request, but setting a full
> > value makes it impossible to test shorter timeouts, when for example
> > testing data read times on different SD cards.
> >
> > Add a function to set any value smaller than the maximum of 0xFFFFFF.
> >
> > Signed-off-by: Mårten Lindahl <marten.lindahl@axis.com>
> > ---
> >
> > v2:
> > - Calculate new value before checking boundaries
> > - Include CLKDIV register to get proper value
> >
> > v3:
> > - Use 'if-else' instead of 'goto'
> > - Don't touch response field when maximize data field
> >
> > v4:
> > - Prevent 32bit divider overflow by splitting the operation
> > - Changed %06x to %#08x as suggested by Doug
> > - Rephrased commit msg as suggested by Doug
> >
> > drivers/mmc/host/dw_mmc.c | 28 +++++++++++++++++++++++++++-
> > 1 file changed, 27 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> > index d977f34f6b55..8e9d33e1b96c 100644
> > --- a/drivers/mmc/host/dw_mmc.c
> > +++ b/drivers/mmc/host/dw_mmc.c
> > @@ -1283,6 +1283,32 @@ static void dw_mci_setup_bus(struct dw_mci_slot *slot, bool force_clkinit)
> > mci_writel(host, CTYPE, (slot->ctype << slot->id));
> > }
> >
> > +static void dw_mci_set_data_timeout(struct dw_mci *host,
> > + unsigned int timeout_ns)
> > +{
> > + unsigned int clk_div, tmp, tmout;
>
> didn't notice before, but nit that I usually make it a policy that
> things that represent cpu registers are the "sized" types. Thus I'd
> rather see these locals as u32 even though the parameter (which
> represents a logical value and not a CPU register) stays as "unsigned
> int").
>
Thanks, will fix.
>
> > + clk_div = (mci_readl(host, CLKDIV) & 0xFF) * 2;
> > + if (clk_div == 0)
> > + clk_div = 1;
> > +
> > + tmp = DIV_ROUND_UP_ULL((u64)timeout_ns * host->bus_hz, NSEC_PER_SEC);
> > + tmp = DIV_ROUND_UP(tmp, clk_div);
>
> I guess in some extreme cases you still have an overflow. Not sure how
> many people really use "div", but...
>
> The case I'm thinking of is if the timeout is 80 ms, the bus_hz is 200
> MHz, and clk_div is 20 (register contains 10). I think that would mean
> you're feeding the controller a 4GHz clock which it probably couldn't
> _really_ handle, so maybe this isn't super realistic. In any case, I
> think the first statement would be the equivalent of 80 * 200MHz =
> 0x3b9aca000 and that blows out the 32-bit "tmp" variable.
I'm sorry but I fail to follow your calculation here. With 80ms timeout
and 200MHz bus_hz, I get:
80000000 * 200000000 / 1000000000 = 0xF42400
The only way I manage to get an overflow of tmp is with:
timeout = INT_MAX * bus_hz = (value greater than 1000000000) / 1000000000
So my reasoning is that tmp = DIV_ROUND_UP(tmp, clk_div) is safe within
these values, but I can of course make tmp an unsigned long, and in that
case do the clk_div division as:
tmp = DIV_ROUND_UP_ULL(tmp, clk_div)
Kind regards
Mårten
>
> Why not just keep it as 64-bit until you're done dividing to be safe?
>
> -Doug
next prev parent reply other threads:[~2021-11-18 10:51 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-17 16:08 [PATCH v4] mmc: dw_mmc: Allow lower TMOUT value than maximum Mårten Lindahl
2021-11-17 23:29 ` Doug Anderson
2021-11-18 10:51 ` Marten Lindahl [this message]
2021-11-19 14:44 ` Doug Anderson
2021-11-19 15:30 ` Marten Lindahl
2021-11-19 15:35 ` Doug Anderson
2021-11-19 15:40 ` Marten Lindahl
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=20211118105113.GA3708@axis.com \
--to=martenli@axis.com \
--cc=Marten.Lindahl@axis.com \
--cc=dianders@google.com \
--cc=jh80.chung@samsung.com \
--cc=kernel@axis.com \
--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 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.