[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20081012175853.0d75b78f@mjolnir.drzeus.cx>
Date: Sun, 12 Oct 2008 17:58:53 +0200
From: Pierre Ossman <drzeus-list@...eus.cx>
To: Haavard Skinnemoen <haavard.skinnemoen@...el.com>
Cc: kernel@...32linux.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 4/7] atmel-mci: support multiple mmc slots
On Sun, 12 Oct 2008 15:13:44 +0200
Haavard Skinnemoen <haavard.skinnemoen@...el.com> wrote:
> Pierre Ossman <drzeus-list@...eus.cx> wrote:
> > On Sun, 5 Oct 2008 18:21:27 +0200
> > Haavard Skinnemoen <haavard.skinnemoen@...el.com> wrote:
> >
> > > + /* Calculate clock divider */
> > > + clkdiv = DIV_ROUND_UP(host->bus_hz, 2 * clock_min) - 1;
> > > if (clkdiv > 255) {
> > > dev_warn(&mmc->class_dev,
> > > "clock %u too slow; using %lu\n",
> > > - ios->clock, host->bus_hz / (2 * 256));
> > > + clock_min, host->bus_hz / (2 * 256));
> > > clkdiv = 255;
> > > }
> > >
> >
> > Has this ever happened, or is it just a bit defensive? :)
> >
> > (not that there is something wrong with that)
>
> It can happen if the controller is hooked up to a fast bus and fOD is
> slow for whatever reason. And if it does, clkdiv will wrap around and
> end up at a rate much faster than requested, so saturating it at the
> maximum divider is the safe thing to do.
>
Isn't this calculated for f_min though so that the MMC core will never
request such a frequency?
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
rdesktop, core developer http://www.rdesktop.org
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
Download attachment "signature.asc" of type "application/pgp-signature" (198 bytes)
Powered by blists - more mailing lists