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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.