From: Tom Rini <trini@ti.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [ARM] one warning left for all ARM boards
Date: Tue, 10 Jul 2012 01:52:22 -0700 [thread overview]
Message-ID: <20120710085222.GD5053@oliver-linux> (raw)
In-Reply-To: <CAA3CPjXjfQRf2ONdwm=0pBSX-hsYGASh=RT1FEzob2m=1nJFKQ@mail.gmail.com>
On Tue, Jul 10, 2012 at 12:46:21PM +0400, Ilya Yanok wrote:
> Hi guys,
>
> On Tue, Jul 10, 2012 at 12:37 PM, Tom Rini <trini@ti.com> wrote:
>
> > > > > What do we want to do about the USB issue (on ARM platforms, with
> > EHCI,
> > > > > with >32byte alignment requirements, if dcache isn't build-time
> > > > > disabled, USB is unusable, a change from previous releases), for this
> > > > > release? Are we going to hope the alignment issues can be flushed
> > out
> > > > > and fixed well enough before the final release? Should we go with
> > > > > disable the dcache now, continue working on it for the next?
> > > >
> > > > What are the chances that the issue be fixed?
> > >
> > > Low ... this is some deep crap that's growing through uboot as whole :-(
> > And
> > > it's not only USB.
> >
> > Then I propose 1, 3, 4, 5, 6 from my v4 series (remove dcache_off
> > call from ehci-omap.c as it's wrong, build-time disable DCACHE on USB
> > enabling platforms). Yes, we're papering over bugs for a release, but
> > we (a) know we're doing it and (b) are trying to fix them and (c) can't
> > fix them in time.
>
>
> I will resend the series this evening. There is no bounce buffering support
> so unaligned operations (unaligned address passed by user) are broken but
> otherwise I think everything works.
>
> And I'd really like to make runtime cache disabling work again. Probably we
> can rename {flush,invalidate}_dcache_range() to
> __{flush,invalidate}_dcache_range() and call these functions there we
> really need to do these operations regardless of cache being enabled. Then
> we could create new {flush,invalidate}_dcache_range() and do if
> (dcache_enabled()) check in them,,,
We've got a release date now. If you think you can get this done and
tested in time, OK. But if we don't have this by -rc2 time we need to
put in the big stupid fix instead (since not all distributions come to
me with questions about things, I fear some may say USB doesn't work and
hold back for who knows how long).
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120710/99566c0c/attachment.pgp>
prev parent reply other threads:[~2012-07-10 8:52 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-09 15:42 [U-Boot] [ARM] one warning left for all ARM boards Albert ARIBAUD
2012-07-09 19:48 ` Wolfgang Denk
2012-07-09 20:42 ` Tom Rini
2012-07-09 20:47 ` Albert ARIBAUD
2012-07-09 21:07 ` Tom Rini
2012-07-09 21:53 ` Albert ARIBAUD
2012-07-10 1:53 ` Marek Vasut
2012-07-10 8:37 ` Tom Rini
2012-07-10 8:46 ` Ilya Yanok
2012-07-10 8:52 ` Tom Rini [this message]
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=20120710085222.GD5053@oliver-linux \
--to=trini@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