From mboxrd@z Thu Jan  1 00:00:00 1970
From: =?ISO-8859-1?Q?Matthias_Wei=DFer?= <weisserm@arcor.de>
Date: Tue, 19 Jul 2011 16:31:30 +0200
Subject: [U-Boot] i.MX51: FEC: Cache coherency problem?
In-Reply-To: <20110719111909.A239B17E88C9@gemini.denx.de>
References: <20110718171836.67bfe605@archvile> <4E245C5C.4030303@ti.com>
	<4E256588.4010301@arcor.de>
	<20110719111909.A239B17E88C9@gemini.denx.de>
Message-ID: <4E259542.2070502@arcor.de>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Am 19.07.2011 13:19, schrieb Wolfgang Denk:
> Dear =?ISO-8859-1?Q?Matthias_Wei=DFer?=,
>
> In message<4E256588.4010301@arcor.de>  you wrote:
>>
>> 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.
>
> If we do this, then everybody will just be lazy, and nothing will ever
> change.

You are right. But time is a limited resource. And fixing cache related 
issues is a bit more complex then, for example, the simple changes 
needed when relocation was introduced in ARM.

>> If d-cache will be enabled by default on ARM I think I have to send a
>> patch for one of my boards :-)
>
> Why don't you just help identifying and fixing the problems in the
> misbehaving drivers?!?
>
> That would be a _much_ more helpful approach.

Well, that is what I meant. I have to fix the driver then. But this will 
interfere with the fact that time is a lim.... You know ;-)

If both of my boards are in mainline I will take a look at them and try 
to fix problematic drivers (mainly USB OHCI should be the problem)

Regards
Matthias