From: Aneesh V <aneesh@ti.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] i.MX51: FEC: Cache coherency problem?
Date: Tue, 19 Jul 2011 17:21:32 +0530 [thread overview]
Message-ID: <4E256FC4.1030102@ti.com> (raw)
In-Reply-To: <4E256588.4010301@arcor.de>
Dear Matthias,
On Tuesday 19 July 2011 04:37 PM, Matthias Wei?er wrote:
> Dear Aneesh
>
> Am 18.07.2011 18:16, schrieb Aneesh V:
>> commit c2dd0d45540397704de9b13287417d21049d34c6
>> armv7: integrate cache maintenance support
>>
>> In this patch I added a call to dcache_enable() at the beginning of
>> board_init_r() for ARM(i.e. as soon as relocation is over). As a result
>> D-cache will be enabled for all ARM platforms now unless
>> CONFIG_SYS_DCACHE_OFF is set.
>
> Is this really a good idea? This will break a couple of boards using
> non-cache-aware drivers. And there are a couple of them in u-boot. I
> think d-cache should be opt-in rather then opt-out as long as there are
> any drivers which didn't handle cached memory regions correct. i-cache
> is much less problematic and can be enabled by default.
D-cache was always an opt-out in u-boot based on the fact that the flag
was CONFIG_SYS_DCACHE_OFF and not something like
CONFIG_SYS_DCACHE_ENABLE. I just made the behavior more consistent and
predictable. Also, my idea was to enable it(if allowed by the config
flag) at the earliest possible time rather than waiting for a random
driver or board file to enable it much later.
Regarding the question of whether it should be opt-out or opt-in I have
no preference myself.
best regards,
Aneesh
next prev parent reply other threads:[~2011-07-19 11:51 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-18 15:18 [U-Boot] i.MX51: FEC: Cache coherency problem? David Jander
2011-07-18 16:16 ` Aneesh V
2011-07-19 7:26 ` David Jander
2011-07-19 11:07 ` Matthias Weißer
2011-07-19 11:17 ` David Jander
2011-07-19 11:20 ` Wolfgang Denk
2011-07-19 12:10 ` David Jander
2011-07-20 6:29 ` David Jander
2011-07-20 8:56 ` Albert ARIBAUD
2011-07-20 9:21 ` David Jander
2011-07-20 10:29 ` Aneesh V
2011-07-20 11:31 ` David Jander
2011-07-20 12:05 ` Aneesh V
2011-07-19 11:19 ` Wolfgang Denk
2011-07-19 14:31 ` Matthias Weißer
2011-07-19 11:51 ` Aneesh V [this message]
2011-07-18 16:55 ` Stefano Babic
2011-07-19 7:44 ` David Jander
2011-07-19 8:21 ` Albert ARIBAUD
2011-07-19 8:37 ` David Jander
2011-07-19 8:43 ` Aneesh V
2011-07-19 8:58 ` David Jander
2011-07-19 9:11 ` Albert ARIBAUD
2011-07-19 11:50 ` Aneesh V
2011-07-19 11:42 ` Aneesh V
2011-07-19 9:05 ` Albert ARIBAUD
2011-07-19 14:36 ` J. William Campbell
2011-07-19 15:17 ` David Jander
2011-07-19 18:14 ` Anton Staaf
2011-07-19 20:11 ` J. William Campbell
2011-07-20 13:02 ` Albert ARIBAUD
[not found] ` <4E26DF9D.5070709@comcast.net>
[not found] ` <4E26E7AA.9070001@aribaud.net>
2011-07-20 15:36 ` J. William Campbell
2011-07-21 6:48 ` David Jander
2011-07-23 13:04 ` Albert ARIBAUD
2011-07-23 15:35 ` J. William Campbell
2011-07-20 8:37 ` Aneesh V
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=4E256FC4.1030102@ti.com \
--to=aneesh@ti.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