From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Nelson Date: Fri, 28 Mar 2014 07:36:42 -0700 Subject: [U-Boot] [PATCH RFC] fsl_esdhc: flush cache after non-read operation In-Reply-To: References: <1396001736-8657-1-git-send-email-hector.palacios@digi.com> Message-ID: <533588FA.7030708@boundarydevices.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Hector, On 03/28/2014 06:49 AM, Fabio Estevam wrote: > On Fri, Mar 28, 2014 at 7:15 AM, Hector Palacios > wrote: >> Cache was invalidated on the read operation, but it should >> also be flushed otherwise. >> >> Signed-off-by: Hector Palacios > > Thanks, Hector. > > Adding Marek on Cc as well. > > >> --- >> >> Notes: >> After enabling L2 cache on i.MX6 I found out that many times >> when running the 'gpt' command to partition a uSD card, the >> data was not written at all, or was badly written to the media. >> >> This patch seems to solve it but I'm not sure if that's the >> right place to flush the cache. Could someone please comment? >> >> Thank you. >> >> drivers/mmc/fsl_esdhc.c | 12 ++++++++++++ >> 1 file changed, 12 insertions(+) >> >> diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c >> index e945c0a470ca..5ef575eb0272 100644 >> --- a/drivers/mmc/fsl_esdhc.c >> +++ b/drivers/mmc/fsl_esdhc.c >> @@ -253,6 +253,16 @@ static int esdhc_setup_data(struct mmc *mmc, struct mmc_data *data) >> return 0; >> } >> >> +static void check_and_flush_dcache_range >> + (struct mmc_cmd *cmd, >> + struct mmc_data *data) { >> + unsigned start = (unsigned)data->dest ; >> + unsigned size = roundup(ARCH_DMA_MINALIGN, >> + data->blocks*data->blocksize); >> + unsigned end = start+size ; >> + flush_dcache_range(start, end); >> +} >> + >> static void check_and_invalidate_dcache_range >> (struct mmc_cmd *cmd, >> struct mmc_data *data) { >> @@ -401,6 +411,8 @@ esdhc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd, struct mmc_data *data) >> #endif >> if (data->flags & MMC_DATA_READ) >> check_and_invalidate_dcache_range(cmd, data); >> + else >> + check_and_flush_dcache_range(cmd, data); >> } Since this comes after the wait for completion, this is clearly not the right fix. If this patch is fixing the problem, the issue must be somewhere else. Can you verify that the call to flush_dcache_range() in the esdhc_setup_data routine is being called prior to esdhc_send_command?