[U-Boot] [PATCH v4 3/6] mcx: Disable DCACHE since USB EHCI is enabled

[Tom Rini]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/28/2012 05:54 PM, Marek Vasut wrote:
> Dear Tom Rini,
> 
>> On 06/28/2012 03:36 PM, Marek Vasut wrote:
>>> Dear Tom Rini,
>>> 
>>>> On Fri, Jun 29, 2012 at 12:01:58AM +0200, Marek Vasut wrote:
>>>>> Dear Tom Rini,
>>>>> 
>>>>>> On 06/28/2012 07:37 AM, Marek Vasut wrote:
>>>>>>> Dear Ilya Yanok,
>>>>>>> 
>>>>>>>> Dear Marek,
>>>>>>>> 
>>>>>>>> 28.06.2012 02:48, Marek Vasut wrote:
>>>>>>>>>> Sorry for missing this discussion. I think 
>>>>>>>>>> compile-time disabling of the cache is too 
>>>>>>>>>> brutal. ehci-hcd cache handling is broken
>>>>>>>>>> anyway: doing unaligned flushes/invalidates is a
>>>>>>>>>> bug, and we know for sure that upper layers don't
>>>>>>>>>> care about alignment (and I bet ehci-hcd does
>>>>>>>>>> this even for its internal buffers). So what's
>>>>>>>>>> the point in all this cache handling in
>>>>>>>>>> ehci-hcd? It's not going to work anyway and just
>>>>>>>>>> produces problems. So I suggest to just disable
>>>>>>>>>> all this stuff until generic code will be fixed. 
>>>>>>>>>> Alternatively we can do bounce-buffering inside 
>>>>>>>>>> driver.
>>>>>>>>> 
>>>>>>>>> We should rather introduce generic bounce buffer. 
>>>>>>>>> But the upper layers are getting fixed recently so 
>>>>>>>>> we should be getting there.
>>>>>>>> 
>>>>>>>> Really? Don't forget my old patch [1] then ;) Still
>>>>>>>> I think we should rip off all the cache stuff from 
>>>>>>>> ehci-hcd until all patches for upper layers are 
>>>>>>>> included. Again, this stuff doesn't do proper things 
>>>>>>>> now anyway and USB won't work with dcache enabled.
>>>>>>> 
>>>>>>> Have you tested? I enabled dcache on m28 and tried
>>>>>>> asix ethernet (needed a patch) and loading from ext2
>>>>>>> and vfat (worked).
>>>>>> 
>>>>>> So then we have more places that accidentially aligned
>>>>>> to 32bytes since this does not work on TI parts which 
>>>>>> require 64byte alignment.
>>>>> 
>>>>> Oh, this is very good it's broken. People actually started 
>>>>> whining. Now we have to wait until they start identifying 
>>>>> the problematic places and fixing them.
>>>> 
>>>> Uh-hunh.  So I guess for v2012.07 we'll build-time disable 
>>>> dcache for beagle and omap3_evm
>>> 
>>> Didn't you fix the issues?
>>> 
>>>> and leave it on for mcx and see who has time and hardware to 
>>>> fix things for v2012.10.
>>> 
>>> Or we fix it for mcx too until .07 is out ?
>> 
>> To clarify for everyone, the first part of this series fixes some
>> alignment issues for things that were not starting address 
>> aligned. There still exist end-address alignment issues within 
>> ehci-hcd.  The time I have for this problem right now boils down 
>> to disable dcache for these boards so that USB is still 
>> functional.
> 
> To clarify it even further -- it always worked just by sheer 
> coincidence ...

No, it didn't.  It used to work in a timely manner, with dcache
disabled but support enabled at build time.  Now it works, in an
unusably slow manner, with dcache disabled but support enabled at
build time.  It continues to work in a timely manner with dcache
support disabled at build time.  On any platform with >32byte
alignment requirements for cache flushing.

- -- 
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJP7Q+BAAoJENk4IS6UOR1WhRIP/1NlLlF4iqiPAr7ZhnVWHUS5
IO76xwcIc69ZZsbD46EAG3XvUpmSkszP7fmr9KZerPYylH4Ne4TOtxqF7yg8rVnx
856tosee9PU4l5yUbt3JbT/XYoT5ivcw7n058PO3BliHcSSZ7BEMsaKOEOUzm+x7
Alzu76UM+YUkIGfGnQMWQnAcT0alNp/aa2KZriWPCOTKj2NKghRuO7xlBF6KGSBz
S/9MaiWnC0PvkCc2fhYt7JsIItz19gnx31M/JhU6gTxOR1WfMAlsQfjDXs5wTZI+
rCuW0H/GX9O3FpXG33Uecf2dzg8e7t45qXRND/7sfHCx4M2nE4HWY+RvSP1XCacH
MTTqeBZm7RpDWKO7P4dQW8GWLkUzNYLOySTyLp2Rnh7882C1QaNbRWplvC+4NB3g
KbSK8H0PqEu/pVJ3Dl2kutMY6PcKX/H1l7x4swEIoNtor6Lx3wE5rzhjjDqElGl7
HVWVjI2Hgco9F043pCjkS3Mb7pNIcJ3/yMjDC8C7PWDLrW9+fPwkbZxqCTJGaBWS
Qlo6RbKxE4yDwDtbJXJspy1ML0jK2DO0NbFD+LDfIrecpKUpTtxBee/b4E6DGcil
LJ6OWprUnxYVM4LHUjdvI9pcX92gwOw6EXpcvPNiHOl9ZO8nThCs5QElg2OAJmlw
qgNzEI3zqq4GimdS+0oh
=Lc3K
-----END PGP SIGNATURE-----