On Tue, Mar 21, 2017 at 01:22:05PM -0700, David Daney wrote:
> On 03/21/2017 12:49 PM, Arnd Bergmann wrote:
> >On Tue, Mar 21, 2017 at 4:19 PM, David Daney
> >wrote:
> >>On 03/21/2017 01:58 AM, Arnd Bergmann wrote:
> >>>
> >>>On Mon, Mar 20, 2017 at 9:45 PM, David
On Tue, Mar 21, 2017 at 01:22:05PM -0700, David Daney wrote:
> On 03/21/2017 12:49 PM, Arnd Bergmann wrote:
> >On Tue, Mar 21, 2017 at 4:19 PM, David Daney
> >wrote:
> >>On 03/21/2017 01:58 AM, Arnd Bergmann wrote:
> >>>
> >>>On Mon, Mar 20, 2017 at 9:45 PM, David Daney
> >>>wrote:
>
>
On 03/21/2017 12:49 PM, Arnd Bergmann wrote:
On Tue, Mar 21, 2017 at 4:19 PM, David Daney wrote:
On 03/21/2017 01:58 AM, Arnd Bergmann wrote:
On Mon, Mar 20, 2017 at 9:45 PM, David Daney
wrote:
On 03/17/2017 07:13 AM, Ulf Hansson
On 03/21/2017 12:49 PM, Arnd Bergmann wrote:
On Tue, Mar 21, 2017 at 4:19 PM, David Daney wrote:
On 03/21/2017 01:58 AM, Arnd Bergmann wrote:
On Mon, Mar 20, 2017 at 9:45 PM, David Daney
wrote:
On 03/17/2017 07:13 AM, Ulf Hansson wrote:
My point is really that we should avoid exporting
On Tue, Mar 21, 2017 at 4:19 PM, David Daney wrote:
> On 03/21/2017 01:58 AM, Arnd Bergmann wrote:
>>
>> On Mon, Mar 20, 2017 at 9:45 PM, David Daney
>> wrote:
>>>
>>> On 03/17/2017 07:13 AM, Ulf Hansson wrote:
My point is really
On Tue, Mar 21, 2017 at 4:19 PM, David Daney wrote:
> On 03/21/2017 01:58 AM, Arnd Bergmann wrote:
>>
>> On Mon, Mar 20, 2017 at 9:45 PM, David Daney
>> wrote:
>>>
>>> On 03/17/2017 07:13 AM, Ulf Hansson wrote:
My point is really that we should avoid exporting SoC specific APIs
On 03/21/2017 01:58 AM, Arnd Bergmann wrote:
On Mon, Mar 20, 2017 at 9:45 PM, David Daney wrote:
On 03/17/2017 07:13 AM, Ulf Hansson wrote:
My point is really that we should avoid exporting SoC specific APIs
which shall be called from drivers. This is old fashion.
On 03/21/2017 01:58 AM, Arnd Bergmann wrote:
On Mon, Mar 20, 2017 at 9:45 PM, David Daney wrote:
On 03/17/2017 07:13 AM, Ulf Hansson wrote:
My point is really that we should avoid exporting SoC specific APIs
which shall be called from drivers. This is old fashion.
Some people find it
On Mon, Mar 20, 2017 at 9:45 PM, David Daney wrote:
> On 03/17/2017 07:13 AM, Ulf Hansson wrote:
>> My point is really that we should avoid exporting SoC specific APIs
>> which shall be called from drivers. This is old fashion.
>
>
> Some people find it objectionable to
On Mon, Mar 20, 2017 at 9:45 PM, David Daney wrote:
> On 03/17/2017 07:13 AM, Ulf Hansson wrote:
>> My point is really that we should avoid exporting SoC specific APIs
>> which shall be called from drivers. This is old fashion.
>
>
> Some people find it objectionable to see 1-off architecture
On Fri, Mar 17, 2017 at 3:13 PM, Ulf Hansson wrote:
> On 10 March 2017 at 14:25, Jan Glauber wrote:
>> Prevent data corruption on cn6xxx and cnf7xxx.
>> Due to an imperfection in the design of the MMC bus hardware,
>> + */
>> +void
On Fri, Mar 17, 2017 at 3:13 PM, Ulf Hansson wrote:
> On 10 March 2017 at 14:25, Jan Glauber wrote:
>> Prevent data corruption on cn6xxx and cnf7xxx.
>> Due to an imperfection in the design of the MMC bus hardware,
>> + */
>> +void l2c_unlock_mem_region(u64 start, u64 len)
>> +{
>> + u64
On 03/17/2017 07:13 AM, Ulf Hansson wrote:
On 10 March 2017 at 14:25, Jan Glauber wrote:
Prevent data corruption on cn6xxx and cnf7xxx.
Due to an imperfection in the design of the MMC bus hardware,
the 2nd to last cache block of a DMA read must be locked into the L2
cache.
On 03/17/2017 07:13 AM, Ulf Hansson wrote:
On 10 March 2017 at 14:25, Jan Glauber wrote:
Prevent data corruption on cn6xxx and cnf7xxx.
Due to an imperfection in the design of the MMC bus hardware,
the 2nd to last cache block of a DMA read must be locked into the L2
cache.
[...]
+/**
+ *
On 10 March 2017 at 14:25, Jan Glauber wrote:
> Prevent data corruption on cn6xxx and cnf7xxx.
> Due to an imperfection in the design of the MMC bus hardware,
> the 2nd to last cache block of a DMA read must be locked into the L2
> cache.
>
> Signed-off-by: Jan Glauber
On 10 March 2017 at 14:25, Jan Glauber wrote:
> Prevent data corruption on cn6xxx and cnf7xxx.
> Due to an imperfection in the design of the MMC bus hardware,
> the 2nd to last cache block of a DMA read must be locked into the L2
> cache.
>
> Signed-off-by: Jan Glauber
> Signed-off-by: David
Prevent data corruption on cn6xxx and cnf7xxx.
Due to an imperfection in the design of the MMC bus hardware,
the 2nd to last cache block of a DMA read must be locked into the L2
cache.
Signed-off-by: Jan Glauber
Signed-off-by: David Daney
Prevent data corruption on cn6xxx and cnf7xxx.
Due to an imperfection in the design of the MMC bus hardware,
the 2nd to last cache block of a DMA read must be locked into the L2
cache.
Signed-off-by: Jan Glauber
Signed-off-by: David Daney
Signed-off-by: Steven J. Hill
---
18 matches
Mail list logo