[U-Boot] [PATCH] mmc: fsl_esdhc: Add workaround for auto-clock gate errata ENGcm03648

[Dirk Behme <dirk.behme@de.bosch.com>]

On 15.03.2012 10:56, Stefano Babic wrote:
> On 08/03/2012 13:36, Dirk Behme wrote:
>> This patch imports three patches from the Freescale U-Boot with the following
>> commit messages:
>>
>> ENGR00156405 ESDHC: Add workaround for auto-clock gate errata ENGcm03648
>> http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/commit/drivers/mmc/imx_esdhc.c?h=imx_v2009.08_12.01.01&id=e436525a70fe47623d346bc7d9f08f12ff8ad787
>> The errata, not applicable to USDHC, causes ESDHC to shut off clock to the card
>> when auto-clock gating is enabled for commands with busy signalling and no data
>> phase. The card might require the clock to exit the busy state, so the workaround
>> is to disable the auto-clock gate bits in SYSCTL register for such commands. The
>> workaround also entails polling on DAT0 bit in the PRSSTAT register to learn when
>> busy state is complete. Auto-clock gating is re-enabled at the end of busy state.
>>
>> ENGR00156670-1 ESDHC/USDHC: Remove delay before each cmd and some bug fixes
>> http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/commit/drivers/mmc/imx_esdhc.c?h=imx_v2009.08_12.01.01&id=a77c6fec8596891be96b2cdbc742c9824844b92a
>> Removed delay of 10 ms before each command. There should not be a need to have this
>> delay after the ENGR00156405 patch that polls until card is not busy anymore before
>> proceeding to next cmd.
>>
>> ENGR00161852: remove u-boot build warnings for mx6q
>> http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/commit/drivers/mmc/imx_esdhc.c?h=imx_v2009.08_12.01.01&id=97efee177f82b082db9d2019ed641c5b99b3f54b
>> Remove u-boot build warnings for mx6q.
>>
>> SYSCTL_RSTA was defined twice. Remove one definition.
>>
>> Signed-off-by: Dirk Behme <dirk.behme@de.bosch.com>
>> CC: Andy Fleming <afleming@freescale.com>
>> CC: Fabio Estevam <fabio.estevam@freescale.com>
>> ---
>>  drivers/mmc/fsl_esdhc.c |   61 ++++++++++++++++++++++++++++++++++++++++------
> 
> This is not a blocking point for me, but is it maybe better to split
> this into three patches as it was originally ? All together makes your
> patch not so easy to read.
> 
> 
>>  include/fsl_esdhc.h     |    4 ++-
>>  2 files changed, 56 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
>> index 30db030..694d6fd 100644
>> --- a/drivers/mmc/fsl_esdhc.c
>> +++ b/drivers/mmc/fsl_esdhc.c
>> @@ -259,6 +259,7 @@ esdhc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd, struct mmc_data *data)
>>  {
>>  	uint	xfertyp;
>>  	uint	irqstat;
>> +	uint	sysctl_restore = 0;
>>  	struct fsl_esdhc_cfg *cfg = (struct fsl_esdhc_cfg *)mmc->priv;
>>  	volatile struct fsl_esdhc *regs = (struct fsl_esdhc *)cfg->esdhc_base;
>>  
>> @@ -279,13 +280,6 @@ esdhc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd, struct mmc_data *data)
>>  	while (esdhc_read32(&regs->prsstat) & PRSSTAT_DLA)
>>  		;
>>  
>> -	/* Wait at least 8 SD clock cycles before the next command */
>> -	/*
>> -	 * Note: This is way more than 8 cycles, but 1ms seems to
>> -	 * resolve timing issues with some cards
>> -	 */
>> -	udelay(1000);
>> -
> 
> You drop a delay - is it ok for PowerPC, too ? Maybe some PowerPC guys
> can answer to this.

There seems to be no comment from the PowerPC guys regarding this, yet. 
For safety, I'll drop this udelay() removal in a v2 of this patch, then.

>>  	/* Set up for a data transfer if we have one */
>>  	if (data) {
>>  		int err;
>> @@ -298,6 +292,14 @@ esdhc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd, struct mmc_data *data)
>>  	/* Figure out the transfer arguments */
>>  	xfertyp = esdhc_xfertyp(cmd, data);
>>  
>> +	/* ESDHC errata ENGcm03648: Turn off auto-clock gate for commands
>> +	 * with busy signaling and no data
>> +	 */
> 
> Wrong multiline comment
> 
>> +	if (!data && (cmd->resp_type & MMC_RSP_BUSY)) {
>> +		sysctl_restore = esdhc_read32(&regs->sysctl);
>> +		esdhc_write32(&regs->sysctl, sysctl_restore | 0xF);
>> +	}
>> +
> 
> I see two issue. There is not a SDCLKEN bit in the PowerPC ESDHC, as far
> as I can see (for example, in MPC8536). Should we not use the HOSTVER
> register to handle these cases ?
> 
> The comment says you are disabling auto-clock. However, in the register
> you are enabling all clocks (PEREN / SDCLKEN /..). Can you explain
> better the reason ? Do you want really disabling clocks ?

Thanks for letting me look more closely on this. The 4 bits which are 
touched with 0xF above seem to be marked as "Not implemented" in the 
i.MX6 spec. Testing the patch without any touching of sysctl still 
works. I.e. I will remove the sysctl handling from the v2, too.

Many thanks and best regards

Dirk