Dear Stefano Babic,
> On 19/07/2012 13:43, Benoît Thébaudeau wrote:
> > Hi all,
>
> Hi,
>
> > I have switched to the git head, and applied all the latest EHCI/MSC
> > patches from u-boot-usb-next.
>
> Marek, should we maybe try to merge these patches still in the incoming
> release ? It makes n
On 19/07/2012 13:43, Benoît Thébaudeau wrote:
> Hi all,
>
Hi,
> I have switched to the git head, and applied all the latest EHCI/MSC patches
> from u-boot-usb-next.
Marek, should we maybe try to merge these patches still in the incoming
release ? It makes no sense if the release is broken and w
Dear Benoît Thébaudeau,
> Hi all,
>
> On Tue, Jul 17, 2012 at 12:30:22AM +0200, Marek Vasut wrote:
> > Dear Dirk Behme,
> >
> > > On 15.07.2012 00:08, Benoît Thébaudeau wrote:
> > > > On Sat, Jul 14, 2012 at 11:28:03PM +0200, Benoît Thébaudeau
> > > >
> > > > wrote:
> > > >> Shouldn't the MMC/e
Hi all,
On Tue, Jul 17, 2012 at 12:30:22AM +0200, Marek Vasut wrote:
> Dear Dirk Behme,
>
> > On 15.07.2012 00:08, Benoît Thébaudeau wrote:
> > > On Sat, Jul 14, 2012 at 11:28:03PM +0200, Benoît Thébaudeau
> > > wrote:
> > >> Shouldn't the MMC/eSDHC drivers flush/invalidate the dcache
> > >> rang
Dear Dirk Behme,
> On 15.07.2012 00:08, Benoît Thébaudeau wrote:
> > On Sat, Jul 14, 2012 at 11:28:03PM +0200, Benoît Thébaudeau wrote:
> >> Shouldn't the MMC/eSDHC drivers flush/invalidate the dcache ranges
> >> that they use
> >> for DMA operations? Not doing so would explain why stack-allocated
On 15.07.2012 16:45, Benoît Thébaudeau wrote:
On 15/07/2012 15:45, Stefano Babic wrote:
On 14/07/2012 23:28, Benoît Thébaudeau wrote:
Hi all,
Hi,
Has anyone tested i.MX25 or i.MX35 with dcache on?
I'm working with U-Boot 2012.04.01 on several custom platforms
using these
processors.
With
On 15/07/2012 15:45, Stefano Babic wrote:
> On 14/07/2012 23:28, Benoît Thébaudeau wrote:
> > Hi all,
> >
>
> Hi,
>
> > Has anyone tested i.MX25 or i.MX35 with dcache on?
> >
> > I'm working with U-Boot 2012.04.01 on several custom platforms
> > using these
> > processors.
> >
> > With dcache
On Sun, Jul 15, 2012 at 08:56:35AM +0200, Dirk Behme wrote:
> On 15.07.2012 00:08, Benoît Thébaudeau wrote:
> > On Sat, Jul 14, 2012 at 11:28:03PM +0200, Benoît Thébaudeau wrote:
> >> Shouldn't the MMC/eSDHC drivers flush/invalidate the dcache ranges
> >> that they use
> >> for DMA operations? Not
On 15/07/2012 00:08, Benoît Thébaudeau wrote:
> On Sat, Jul 14, 2012 at 11:28:03PM +0200, Benoît Thébaudeau wrote:
>> Shouldn't the MMC/eSDHC drivers flush/invalidate the dcache ranges
>> that they use
>> for DMA operations? Not doing so would explain why stack-allocated
>> buffers are
>> more affe
On 14/07/2012 23:28, Benoît Thébaudeau wrote:
> Hi all,
>
Hi,
> Has anyone tested i.MX25 or i.MX35 with dcache on?
>
> I'm working with U-Boot 2012.04.01 on several custom platforms using these
> processors.
>
> With dcache off, everything works fine, but slowly.
>
> With dcache on, it's much
On 15.07.2012 00:08, Benoît Thébaudeau wrote:
On Sat, Jul 14, 2012 at 11:28:03PM +0200, Benoît Thébaudeau wrote:
Shouldn't the MMC/eSDHC drivers flush/invalidate the dcache ranges
that they use
for DMA operations? Not doing so would explain why stack-allocated
buffers are
more affected than buff
On Sat, Jul 14, 2012 at 11:28:03PM +0200, Benoît Thébaudeau wrote:
> Shouldn't the MMC/eSDHC drivers flush/invalidate the dcache ranges
> that they use
> for DMA operations? Not doing so would explain why stack-allocated
> buffers are
> more affected than buffers in unused RAM areas.
That will hel
Hi all,
Has anyone tested i.MX25 or i.MX35 with dcache on?
I'm working with U-Boot 2012.04.01 on several custom platforms using these
processors.
With dcache off, everything works fine, but slowly.
With dcache on, it's much faster (e.g. mtest), but it's impossible to read
files through the eSDH
13 matches
Mail list logo
