From mboxrd@z Thu Jan  1 00:00:00 1970
From: Dirk Behme <dirk.behme@de.bosch.com>
Date: Wed, 11 Jul 2012 08:29:44 +0200
Subject: [U-Boot] [PATCH V2] i.MX: fsl_esdhc: allow use with
	cache	enabled.
In-Reply-To: <201206121923.30555.marex@denx.de>
References: <http://lists.denx.de/pipermail/u-boot/2012-March/#119312>
	<4FD7775E.9000606@denx.de> <4FD77906.1030302@boundarydevices.com>
	<201206121923.30555.marex@denx.de>
Message-ID: <4FFD1D58.5000904@de.bosch.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

On 12.06.2012 19:23, Marek Vasut wrote:
> Dear Eric Nelson,
> 
>> On 06/12/2012 10:07 AM, Stefano Babic wrote:
>>> On 15/05/2012 14:58, Dirk Behme wrote:
>>>> On 09.05.2012 07:45, Stefano Babic wrote:
>>>>> On 09/05/2012 01:31, Eric Nelson wrote:
>>>>>> Thanks Andy,
>>>>>>
>>>>>> On 05/08/2012 03:59 PM, Andy Fleming wrote:
>>>>>>>> --- a/drivers/mmc/fsl_esdhc.c
>>>>>>>> +++ b/drivers/mmc/fsl_esdhc.c
>>>>>>>> @@ -190,6 +190,10 @@ static int esdhc_setup_data(struct mmc *mmc,
>>>>>>>> struct mmc_data *data)
>>>>>>>>
>>>>>>>>                  esdhc_clrsetbits32(&regs->wml, WML_RD_WML_MASK,
>>>>>>>>
>>>>>>>> wml_value);
>>>>>>>>
>>>>>>>>                  esdhc_write32(&regs->dsaddr, (u32)data->dest);
>>>>>>>>          
>>>>>>>>          } else {
>>>>>>>>
>>>>>>>> +               flush_dcache_range((ulong)data->src,
>>>>>>>> +                                  (ulong)data->src+data->blocks
>>>>>>>> +                                        *data->blocksize);
>>>>>>>> +
>>>>>>> This still won't work. I don't believe this is implemented at all on
>>>>>>> the FSL PowerPC parts that use this controller.
>>>>>>>
>>>>>>> At the very least, it needs to be protected by an ifdef.
>>>>>> It seems more generally useful to implement a PowerPC cache layer
>>>>>> than to instrument each driver that supports cache.
>>>>> Some PowerPC (MPC86xx,  arch/powerpc/cpu/mpc86xx/cache.S) have this
>>>>> layer, some other not. This driver is used by MPC85xx and
>>>>> flush_dcache_range is not implemented. The reason is that this SOC 
>>>>> uses its internal snooping mechanism and does not need to explicitely
>>>>> flush the buffers in the drivers.
>>>>>
>>>>> The problem with an #ifdef is that it is not very generic - we should
>>>>> add some #if (defined(CONFIG_MX51) || defined(CONFIG_MX53) || ...
>>>>> and update the driver for each new SOCs. I think also that maybe the
>>>>> best way is to add an empty flush_dcache_range() to the MPC85xx, maybe
>>>>> as weak function.
>>>> You might have noticed that I'm looking through my list of open patches.
>>>> So: Any news regarding V3 of this patch? ;)
>>> This is my turn to look back if there are some news. Has anyone taken a
>>> look at it ?
>>>
>>> Best regards,
>>> Stefano Babic
>> Sorry Stefano,
>>
>> I've been meaning to generate an update but seem to be starving for time.
>>
>> Some other messages on the list regarding PPC seem to indicate that the
>> real solution here is a set of cache stubs for PPC, not an SDHC patch
>> though.
>>
>> I'm not likely to have any time until after FTF next week.
>>
>> Any chance that a PPC maintainer can chime in here?
> 
> I think WD applied the cache stub patch already. Can you try now please?

Ping ;)

Thanks

Dirk