From: Mike Frysinger <vapier@gentoo.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] tegra2: Enable data cache
Date: Thu, 15 Sep 2011 13:41:41 -0400 [thread overview]
Message-ID: <201109151341.43710.vapier@gentoo.org> (raw)
In-Reply-To: <4E723621.3080403@aribaud.net>
On Thursday, September 15, 2011 13:30:09 Albert ARIBAUD wrote:
> I agree on the need and interest to support cache. I disagree on the way
> to get there. Turning cache off indiscriminately and hoping that board
> developers/maintainer turn their caches off will only lead to U-Boot
> failing in interesting ways and cluttering the mailing list with
> requests for help until someone figures out the cache is the culprit.
if code only works when cache is turned on, that usually means the code is
broken and is missing appropriate barriers/flushes. turning cache on doesnt
fix the underlying issue, it ignores it. ive seen this in the past with
Blackfin parts where our testers will do some operation with caches on, and
then try things with caches off, and trigger bugs in drivers due to missing
syncs but things work due to implicit timings with cache on.
> We have started outlining a solution (weak generic cache (non-)functions
> in arch/arm/lib/cache.c which only warn about cache not being enabled,
> and cpu/SoC/board specific versions that enable cache where it works.
which is causing the copy & paste i'm whining about
> We also have started discussing minimizing cache code copy -- admittedly
> spinned off a patch submission discussion, so it may have been missed,
> and I will repost the RFC in its own thread -- whereby the cache
> functions would be defined as weak function in the lib, and could be
> overriden by ISA-level function, which themselves could be overriden by
> CPU-level functions, and SoC (or even board) level functions could
> override them all.
i guess i did miss it. it doesnt matter to me how we get to the ultimate
destination ({I,D}CACHE_ON/etc...), just that ultimately the crappy/dead SoC's
are not bogging down the modern/maintained ones by forcing the common
implementation to suck.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20110915/ce5bdfdf/attachment.pgp
next prev parent reply other threads:[~2011-09-15 17:41 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-08 22:20 [U-Boot] [PATCH] tegra2: Enable data cache Simon Glass
2011-09-09 0:25 ` Mike Frysinger
2011-09-09 0:30 ` Marek Vasut
2011-09-09 3:10 ` Simon Glass
2011-09-14 13:10 ` Aneesh V
2011-09-14 15:13 ` Simon Glass
2011-09-15 3:03 ` Mike Frysinger
2011-09-15 16:21 ` Albert ARIBAUD
2011-09-15 16:31 ` Mike Frysinger
2011-09-15 17:30 ` Albert ARIBAUD
2011-09-15 17:41 ` Mike Frysinger [this message]
2011-09-21 21:27 ` Simon Glass
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=201109151341.43710.vapier@gentoo.org \
--to=vapier@gentoo.org \
--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