[U-Boot] [PATCH RFC] fsl_esdhc: flush cache after non-read operation

[Hector Palacios <hector.palacios@digi.com>]

Hi,

On 03/28/2014 03:36 PM, Eric Nelson wrote:
> Hi Hector,
>
> On 03/28/2014 06:49 AM, Fabio Estevam wrote:
>> On Fri, Mar 28, 2014 at 7:15 AM, Hector Palacios
>> <hector.palacios@digi.com> wrote:
>>> Cache was invalidated on the read operation, but it should
>>> also be flushed otherwise.
>>>
>>> Signed-off-by: Hector Palacios <hector.palacios@digi.com>

After further testing it looks like I misinterpreted the results:
First, please disregard the patch as it does not fix anything.
Second, 'mmc part' command seems to be returning cached data after I use 'gpt' command 
to partition the uSD card. I can reproduce it as follows (consider mmc 1 is my uSD card):

1. Write random data to corrupt the partition table
	=> mmc dev 1
	=> mmc write $loadaddr 0 30
2. Check partition table is corrupt
	=> mmc part		(shows error invalid GPT)
3. Soft reset the target
4. Write a correct partition table
	=> mmc dev 1
	=> gpt write mmc 1 "..."
5. Read back partition table
	=> mmc part

At this point 'mmc part' returns again an incorrect partition table. However, if after 
a while I do an 'mmc rescan' or a soft reset and rerun the 'mmc part' command, it will 
show the correct partition table was written.

The partition table is read during mmc_init():

int test_part_efi(block_dev_desc_t * dev_desc)
{
	ALLOC_CACHE_ALIGN_BUFFER_PAD(legacy_mbr, legacymbr, 1, dev_desc->blksz);

	/* Read legacy MBR from block 0 and validate it */
	if ((dev_desc->block_read(dev_desc->dev, 0, 1, (ulong *)legacymbr) != 1)
		|| (is_pmbr_valid(legacymbr) != 1)) {
		return -1;
	}
	return 0;
}

Could it be that the read partition table is cached so that after writing it with 
'gpt', reading it again returns cached data instead of physical data, just written?

-- 
H?ctor Palacios