When we copy code/data to the main memory, we may need to flush the
cache if required by architecture. It uses the existing function
flush_cache. Syntax is
flush
The addr and size are given in hexadecimal. Like memory command, there is
no sanity check for the parameters.
Signed-off-by: York Su
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/05/2013 04:50 PM, York Sun wrote:
> When we copy code/data to the main memory, we may need to flush
> the cache if required by architecture. It uses the existing
> function flush_cache. Syntax is
>
> flush
>
> The addr and size are given in h
On 04/05/2013 02:00 PM, Tom Rini wrote:
> On 04/05/2013 04:50 PM, York Sun wrote:
>> When we copy code/data to the main memory, we may need to flush
>> the cache if required by architecture. It uses the existing
>> function flush_cache. Syntax is
>
>> flush
>
>> The addr and size are given in h
Dear York Sun,
In message <1365195056-20188-1-git-send-email-york...@freescale.com> you wrote:
> When we copy code/data to the main memory, we may need to flush the
> cache if required by architecture. It uses the existing function
> flush_cache. Syntax is
>
> flush
Plain "flush" is way too ge
On 04/05/2013 03:09 PM, Wolfgang Denk wrote:
> Dear York Sun,
>
> In message <1365195056-20188-1-git-send-email-york...@freescale.com> you
> wrote:
>> When we copy code/data to the main memory, we may need to flush the
>> cache if required by architecture. It uses the existing function
>> flush_c
Dear York Sun,
In message <515f5812.8030...@freescale.com> you wrote:
>
> > adding new:
> >
> > dcache flush=> flush all
> > dcache flush=> flush range
> >
> > I think this makes more sense. Comments?
>
> It would if the command only deals with dcache. This
On Apr 6, 2013, at 12:01 AM, Wolfgang Denk wrote:
> Dear York Sun,
>
> In message <515f5812.8030...@freescale.com> you wrote:
>>
>>> adding new:
>>>
>>> dcache flush=> flush all
>>> dcache flush=> flush range
>>>
>>> I think this makes more sense. Comments
Dear sun york-R58495,
In message
you wrote:
>
> > Can we not split this into:
> >
> > dcache flush
> > icache invalidate
> >
> > ? This would make clear what's happening.
>
>
> The idea is to reuse existing code with minimum addition. For the applicati
> ons concerned, these two s
On Apr 7, 2013, at 1:29 AM, Wolfgang Denk wrote:
> Dear sun york-R58495,
>
> In message
>
> you wrote:
>>
>>> Can we not split this into:
>>>
>>> dcache flush
>>> icache invalidate
>>>
>>> ? This would make clear what's happening.
>>
>>
>> The idea is to reuse existing code with
Dear sun york-R58495,
In message
you wrote:
>
> I think it is best to keep this patch as it and stick with the
> original flush_cache name. It uses the existing function
> flush_cache() which is available for most (if not all) architectures.
> Splitting the dcache and icache not only adds more
On 04/08/2013 01:35:13 PM, Wolfgang Denk wrote:
Dear sun york-R58495,
In message
you wrote:
>
> I think it is best to keep this patch as it and stick with the
> original flush_cache name. It uses the existing function
> flush_cache() which is available for most (if not all)
architectures
Dear Scott,
In message <1365447916.28843.7@snotra> you wrote:
>
> Maybe "cache" should be the toplevel command, with "icache" and
> "dcache" refactored to be subcommands? Of course, then you're making
> an incompatible interface change. How much is consistency worth?
I think backward compat
On 04/08/2013 02:18:20 PM, Wolfgang Denk wrote:
Dear Scott,
In message <1365447916.28843.7@snotra> you wrote:
>
> Maybe "cache" should be the toplevel command, with "icache" and
> "dcache" refactored to be subcommands? Of course, then you're
making
> an incompatible interface change. How mu
On 04/07/2013 03:29:31 AM, Wolfgang Denk wrote:
Dear sun york-R58495,
In message
you wrote:
>
> > Can we not split this into:
> >
> > dcache flush
> > icache invalidate
> >
> > ? This would make clear what's happening.
>
>
> The idea is to reuse existing code with minimum addi
Dear Scott,
In message <1365449512.28843.10@snotra> you wrote:
>
> > > Maybe "cache" should be the toplevel command, with "icache" and
> > > "dcache" refactored to be subcommands? Of course, then you're making
> > > an incompatible interface change. How much is consistency worth?
> >
> > I thin
Dear Scott Wood,
In message <1365450620.28843.12@snotra> you wrote:
> >
> I thought you said it was OK to flush more than the user asked for, if
> the implementation does not have separate icache/dcache flushes? Why
> is it fundamentally different if it's a hardware limitation, or a
> limit
On 04/09/2013 12:45:31 PM, Wolfgang Denk wrote:
Dear Scott,
In message <1365449512.28843.10@snotra> you wrote:
> I think the terminology is just fine. It's not just invalidating
the
> icache (flushing and invalidating are the same thing for cache lines
> which are not modified -- or are inca
Dear Scott,
In message <136490.31043.20@snotra> you wrote:
>
> If that means you have some other reason for objecting that you *do*
> want to go into, could you elaborate?
I explained that before: we already have commands to operate with the
caches, and we should rather use the existingones
On 04/10/2013 06:54:25 AM, Wolfgang Denk wrote:
Dear Scott,
In message <136490.31043.20@snotra> you wrote:
>
> If that means you have some other reason for objecting that you *do*
> want to go into, could you elaborate?
I explained that before: we already have commands to operate with the
c
Dear Scott,
In message <1365622923.8381.10@snotra> you wrote:
>
> > I explained that before: we already have commands to operate with the
> > caches, and we should rather use the existingones and extend these as
> > needed instead of adding arbitrary new ones.
>
> The existing ones have semantics
On 04/10/2013 04:04:43 PM, Wolfgang Denk wrote:
Dear Scott,
In message <1365622923.8381.10@snotra> you wrote:
> testing that we cannot do). Blackfin is weird -- if we did a simple
> split at the C-code level it looks like we'd have two dummy loops
> executing.
Huh? flush_cache() does not incl
Dear Scott Wood,
In message <1365628243.8381.20@snotra> you wrote:
>
> > > testing that we cannot do). Blackfin is weird -- if we did a simple
> > > split at the C-code level it looks like we'd have two dummy loops
> > > executing.
> >
> > Huh? flush_cache() does not include any loop for BF.
>
On 04/10/2013 05:50:56 PM, Wolfgang Denk wrote:
Dear Scott Wood,
In message <1365628243.8381.20@snotra> you wrote:
>
> > > testing that we cannot do). Blackfin is weird -- if we did a
simple
> > > split at the C-code level it looks like we'd have two dummy
loops
> > > executing.
> >
> > Hu
Dear Scott,
In message <1365634846.8381.24@snotra> you wrote:
>
> > Do you have any real technical arguments?
>
> I'm done arguing and have already recommended we just keep this patch
> in our local tree. We do not have unlimited time to spend messing
> around with other arch code to produce a r
24 matches
Mail list logo
