From mboxrd@z Thu Jan 1 00:00:00 1970 From: Albert ARIBAUD Date: Mon, 28 Nov 2011 13:56:50 +0100 Subject: [U-Boot] [RFC/PATCH] davinci: disable dcache on boards with EMAC In-Reply-To: <20111127193612.65CA21FFB3AD@gemini.denx.de> References: <1321048618-20616-1-git-send-email-yanok@emcraft.com> <20111127150922.091F91FFB3AB@gemini.denx.de> <20111127180945.E0BBB1FFB3AC@gemini.denx.de> <4ED2835F.4010802@emcraft.com> <20111127184924.BD0131FFB3AB@gemini.denx.de> <4ED28DFD.7090805@emcraft.com> <20111127193612.65CA21FFB3AD@gemini.denx.de> Message-ID: <4ED38512.3030202@aribaud.net> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi all, Le 27/11/2011 20:36, Wolfgang Denk a ?crit : >> Don't you think that adding stub implementation for cache functions on >> arm926ejs and fixing the driver is better? > > Yes, that would be the 4th approach, listed as "much better" :-) Better yet, have an ARM-wide, not only ARM926EJ-S, cache framework with a hierarchy of cache function implementations, from ARM architectures to Cores / SoCs or even boards. My general idea is that: - each ISA (ARMv4/5/4/7/etc) should provide generic implementations for cache handling functions to all cores, SoCs, boards that use this ISA, and that implementation should be used by default; - each core / SoC should be able to easily provide specific cache function variants to all boards based on it, on a function granularity (i.e. reuse as much of the ISA cache handling code as possible); - maybe a board should be able to easily provide specific cache functions as well; - the cache API should hide L1 / L2 intricacies at the client level, i.e. a driver that wants to flush to memory should just call 'cache_flush_range(address, size)' without wondering which caches the board provides; - global cache enable/disable/flush (as opposed to cache range) should be used only in very few cases (init and exit, meaning U-Boot startup and jum-to-OS cases). The system of 'overloading' between lib, ISA and SoC / Core could be achieved through weak symbols maybe, or a set of CONFIG variables, e.g. CONFIG_ARM_CACHE_FLUSH would be set to the name of the function to use for cache flushing, etc. However, I have very little time ATM even to try and keep up with patches and pull reqs, so I simply cannot submit any code for ARM cache handling. Thus anyone wishing to submit code along the lines above, or provide an RFC if they feel there is a better approach, is more than welcome, and I *promise* I'll give such submissions first priority -- at which point I suggest making sure I am in the "To:" list of the patch submission mails. > Best regards, > > Wolfgang Denk Amicalement, -- Albert.