[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <5D8008F58939784290FAB48F54975198320B3E4508@shsmsx502.ccr.corp.intel.com>
Date: Sun, 5 Dec 2010 19:48:51 +0800
From: "Dong, Chuanxiao" <chuanxiao.dong@...el.com>
To: Wolfram Sang <w.sang@...gutronix.de>
CC: "linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"cjb@...top.org" <cjb@...top.org>,
"arjan@...ux.intel.com" <arjan@...ux.intel.com>,
"alan@...ux.intel.com" <alan@...ux.intel.com>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"adrian.hunter@...ia.com" <adrian.hunter@...ia.com>,
"prakity@...vell.com" <prakity@...vell.com>
Subject: RE: [PATCH v3 2/3]set timeout control reg for such SDHCI host
> -----Original Message-----
> From: linux-mmc-owner@...r.kernel.org
> [mailto:linux-mmc-owner@...r.kernel.org] On Behalf Of Wolfram Sang
> Sent: Sunday, December 05, 2010 5:34 AM
> To: Dong, Chuanxiao
> Cc: linux-mmc@...r.kernel.org; linux-kernel@...r.kernel.org; cjb@...top.org;
> arjan@...ux.intel.com; alan@...ux.intel.com; akpm@...ux-foundation.org;
> adrian.hunter@...ia.com; prakity@...vell.com
> Subject: Re: [PATCH v3 2/3]set timeout control reg for such SDHCI host
>
> On Fri, Dec 03, 2010 at 10:38:59AM +0800, Dong, Chuanxiao wrote:
> > >
> > > On Thu, Dec 02, 2010 at 07:26:13PM +0800, Chuanxiao Dong wrote:
> > >
> > > > + if (host->quirks & SDHCI_QUIRK_FORCE_ERASE_SINGLE) {
> > > > + /* Set the timeout to be the maximum value */
> > > > + if (cmd->erase_timeout)
> > > > + sdhci_writeb(host, 0xE, SDHCI_TIMEOUT_CONTROL);
> > > > + }
> > > > +
> > > > sdhci_writew(host, SDHCI_MAKE_CMD(cmd->opcode, flags),
> > > > SDHCI_COMMAND);
> > >
> > > Hmm, this looks like another argument for Philip's idea to always
> > > use the maximum timeout value and skip the quirks related to it?
> >
> > Yes, if always using the maximum timeout value is OK for other command, the
> patch2 can be removed I think.
> > The new added quirk in the serials patches is used to set the limitation of request
> queue, not only just to set the timeout control reg.
> > Even the timeout value was set to be 0xE (the maximum value), erasing too many
> sectors can still be failed since the timeout time was still not longer enough.
> > So the count of erased sectors passed down by request queue should be reduced
> by using this quirk.
>
> Yes, I think I understand the issue. Have you tried adding a callback, so we don't
> have the options between MAX_UINT and '1' but rather MAX_UINT and return
> value of the callback?
I added a function to calculate a more suitable max_discard_sectors value for SDHCI host controller in version 1 patches. This value was calculated by the timeout time host controller can wait and the erase timeout. Is that the callback you mean?
In this version, I added a function called mmc_set_discard_limit to detect whether the host has a new cap called MMC_CAP_ERASE_SINGLE. They can be found in patch1. If host has been set MMC_CAP_ERASE_SINGLE cap, just returns '1'. And if not, return MAX_UINT.
I used this way in version 3 patches instead of the calculated way since I thought using an easier way to work around a hardware issue was better. Any suggestion about solving this kind of problem?
Thanks
Chuanxiao
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists