public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Marek Vasut <marex@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH V2] i.MX: fsl_esdhc: allow use with cache	enabled.
Date: Tue, 12 Jun 2012 19:23:30 +0200	[thread overview]
Message-ID: <201206121923.30555.marex@denx.de> (raw)
In-Reply-To: <4FD77906.1030302@boundarydevices.com>

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?

> 
> Please advise,
> 
> 
> Eric

Best regards,
Marek Vasut

  reply	other threads:[~2012-06-12 17:23 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <http://lists.denx.de/pipermail/u-boot/2012-March/#119312>
2012-04-26  0:28 ` [U-Boot] [PATCH V2] i.MX: fsl_esdhc: allow use with cache enabled Eric Nelson
2012-05-08 22:59   ` Andy Fleming
2012-05-08 23:31     ` Eric Nelson
2012-05-09  5:45       ` Stefano Babic
2012-05-15 12:58         ` Dirk Behme
2012-05-15 13:09           ` Anatolij Gustschin
2012-05-15 23:01             ` Eric Nelson
2012-05-15 23:35               ` Marek Vasut
2012-06-12 17:07           ` Stefano Babic
2012-06-12 17:14             ` Eric Nelson
2012-06-12 17:23               ` Marek Vasut [this message]
2012-07-11  6:29                 ` Dirk Behme
2012-07-13 10:37                   ` Marek Vasut
2012-07-20  2:32                   ` Marek Vasut
2012-07-20  5:35                     ` Dirk Behme
2012-07-20  8:53                       ` Stefano Babic

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201206121923.30555.marex@denx.de \
    --to=marex@denx.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox