On 06/24/2012 05:17 PM, Marek Vasut wrote:
This prevents the scenario where data cache is on and the
device uses DMA to deploy data. In that case, it might not
be possible to flush/invalidate data to RAM properly. The
other option is to use bounce buffer, but that involves a
lot of copying and th
Dear Scott Wood,
> On 06/25/2012 08:33 PM, Marek Vasut wrote:
> > Dear Scott Wood,
> >
> >> On 06/25/2012 06:37 PM, Marek Vasut wrote:
> >>> Dear Scott Wood,
> >>>
> On 06/24/2012 07:17 PM, Marek Vasut wrote:
> > but that involves a lot of copying and therefore degrades performance
> >>
On 06/25/2012 08:16 PM, Marek Vasut wrote:
> Dear Scott Wood,
>> Note that in the case of "nand read.oob", depending on NAND page size
>> and platform, there's a good chance that you're imposing an alignment
>> restriction that is larger than the data being transferred even if the
>> user asks to r
On 06/25/2012 08:33 PM, Marek Vasut wrote:
> Dear Scott Wood,
>
>> On 06/25/2012 06:37 PM, Marek Vasut wrote:
>>> Dear Scott Wood,
>>>
On 06/24/2012 07:17 PM, Marek Vasut wrote:
> but that involves a lot of copying and therefore degrades performance
> rapidly. Therefore disallow this
Dear Scott Wood,
> On 06/25/2012 06:37 PM, Marek Vasut wrote:
> > Dear Scott Wood,
> >
> >> On 06/24/2012 07:17 PM, Marek Vasut wrote:
> >>> This prevents the scenario where data cache is on and the
> >>> device uses DMA to deploy data. In that case, it might not
> >>> be possible to flush/invali
Dear Scott Wood,
> On 06/25/2012 06:42 PM, Marek Vasut wrote:
> > Dear Scott Wood,
> >
> >> On 06/25/2012 03:48 PM, Tom Rini wrote:
> >>> Right. What I'm trying to say is it's not a NAND problem it's an
> >>> unaligned addresses problem so the solution needs to be easily used
> >>> everywhere.
>
On 06/25/2012 06:42 PM, Marek Vasut wrote:
> Dear Scott Wood,
>
>> On 06/25/2012 03:48 PM, Tom Rini wrote:
>>> Right. What I'm trying to say is it's not a NAND problem it's an
>>> unaligned addresses problem so the solution needs to be easily used
>>> everywhere.
>>
>> OK, so fix it in each drive
On 06/25/2012 06:37 PM, Marek Vasut wrote:
> Dear Scott Wood,
>
>> On 06/24/2012 07:17 PM, Marek Vasut wrote:
>>> This prevents the scenario where data cache is on and the
>>> device uses DMA to deploy data. In that case, it might not
>>> be possible to flush/invalidate data to RAM properly. The
>
Dear Scott Wood,
> On 06/25/2012 03:48 PM, Tom Rini wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > On 06/25/2012 01:08 PM, Scott Wood wrote:
> >> On 06/25/2012 01:43 PM, Tom Rini wrote:
> >>> On Mon, Jun 25, 2012 at 11:58:10AM -0500, Scott Wood wrote:
> On 06/24/2012 07
Dear Tom Rini,
> On Mon, Jun 25, 2012 at 11:58:10AM -0500, Scott Wood wrote:
> > On 06/24/2012 07:17 PM, Marek Vasut wrote:
> > > This prevents the scenario where data cache is on and the
> > > device uses DMA to deploy data. In that case, it might not
> > > be possible to flush/invalidate data to
Dear Scott Wood,
> On 06/24/2012 07:17 PM, Marek Vasut wrote:
> > This prevents the scenario where data cache is on and the
> > device uses DMA to deploy data. In that case, it might not
> > be possible to flush/invalidate data to RAM properly. The
> > other option is to use bounce buffer,
>
> Or
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/25/2012 02:17 PM, Scott Wood wrote:
> On 06/25/2012 03:48 PM, Tom Rini wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>
>> On 06/25/2012 01:08 PM, Scott Wood wrote:
>>> On 06/25/2012 01:43 PM, Tom Rini wrote:
On Mon, Jun 25, 2012
On 06/25/2012 03:48 PM, Tom Rini wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 06/25/2012 01:08 PM, Scott Wood wrote:
>> On 06/25/2012 01:43 PM, Tom Rini wrote:
>>> On Mon, Jun 25, 2012 at 11:58:10AM -0500, Scott Wood wrote:
On 06/24/2012 07:17 PM, Marek Vasut wrote:
> T
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/25/2012 01:08 PM, Scott Wood wrote:
> On 06/25/2012 01:43 PM, Tom Rini wrote:
>> On Mon, Jun 25, 2012 at 11:58:10AM -0500, Scott Wood wrote:
>>> On 06/24/2012 07:17 PM, Marek Vasut wrote:
This prevents the scenario where data cache is on and
On 06/25/2012 01:43 PM, Tom Rini wrote:
> On Mon, Jun 25, 2012 at 11:58:10AM -0500, Scott Wood wrote:
>> On 06/24/2012 07:17 PM, Marek Vasut wrote:
>>> This prevents the scenario where data cache is on and the
>>> device uses DMA to deploy data. In that case, it might not
>>> be possible to flush/i
On Mon, Jun 25, 2012 at 11:58:10AM -0500, Scott Wood wrote:
> On 06/24/2012 07:17 PM, Marek Vasut wrote:
> > This prevents the scenario where data cache is on and the
> > device uses DMA to deploy data. In that case, it might not
> > be possible to flush/invalidate data to RAM properly. The
> > oth
On 06/24/2012 07:17 PM, Marek Vasut wrote:
> This prevents the scenario where data cache is on and the
> device uses DMA to deploy data. In that case, it might not
> be possible to flush/invalidate data to RAM properly. The
> other option is to use bounce buffer,
Or get cache coherent hardware. :-
This prevents the scenario where data cache is on and the
device uses DMA to deploy data. In that case, it might not
be possible to flush/invalidate data to RAM properly. The
other option is to use bounce buffer, but that involves a
lot of copying and therefore degrades performance rapidly.
Therefo
18 matches
Mail list logo