public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Eric Nelson <eric.nelson@boundarydevices.com>
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 10:14:46 -0700	[thread overview]
Message-ID: <4FD77906.1030302@boundarydevices.com> (raw)
In-Reply-To: <4FD7775E.9000606@denx.de>

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?

Please advise,


Eric

  reply	other threads:[~2012-06-12 17:14 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 [this message]
2012-06-12 17:23               ` Marek Vasut
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=4FD77906.1030302@boundarydevices.com \
    --to=eric.nelson@boundarydevices.com \
    --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