From: Aneesh V <aneesh@ti.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v2] ARM926ejs: Add routines to invalidate D-Cache
Date: Mon, 08 Aug 2011 15:57:39 +0530 [thread overview]
Message-ID: <4E3FBA1B.1020700@ti.com> (raw)
In-Reply-To: <4E3FB993.1080602@emk-elektronik.de>
Hi Reinhard,
On Monday 08 August 2011 03:55 PM, Reinhard Meyer wrote:
> Hi Aneesh,
>> On Monday 08 August 2011 03:29 PM, Reinhard Meyer wrote:
>>> Dear Albert, Aneesh, Hong,
>>>
>>> There seem to be functions of type
>>>
>>> xxx(start, end) and xxx(start, size).
>>>
>>> Can't it be somehow decided to use only one variant
>>> in all cases (flush, invalidate)?
>>
>> The u-boot standard seems to be xxx(start, end) where the operation
>> will be done on the range [start, end). This is what I figured out by
>> looking at the prototypes and existing implementations when I did the
>> armv7 work and I have stuck to this standard.
>>
>> Hong also seems to be following the same standard.
>>
>> If there is no objection, I shall add this definition to the README I
>> am adding.
>
> Maybe its arch specific, I just saw this in another thread, thats why I asked:
>
>
> +++ b/arch/mips/cpu/mips32/cpu.c
> @@ -52,6 +52,11 @@ int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
>
> void flush_cache(ulong start_addr, ulong size)
I think the confusion about flush_cache() is because in
include/common.h the prototype for flush_cache() doesn't have names for
the paramaeters. It's like this:
void flush_cache (unsigned long, unsigned long);
However, the invalidate and flush range functions are clearly defined:
void flush_dcache_range(unsigned long start, unsigned long stop);
void invalidate_dcache_range(unsigned long start, unsigned long stop);
I don't know what to do about flush_cache() now that it seems to have
conflicting implementations.
best regards,
Aneesh
next prev parent reply other threads:[~2011-08-08 10:27 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-05 4:44 [U-Boot] [PATCH v2] ARM926ejs: Add routines to invalidate D-Cache Hong Xu
2011-08-05 5:11 ` Reinhard Meyer
2011-08-05 6:17 ` Hong Xu
2011-08-05 6:22 ` Albert ARIBAUD
2011-08-05 6:13 ` Albert ARIBAUD
2011-08-05 6:38 ` Hong Xu
2011-08-05 6:46 ` Albert ARIBAUD
2011-08-05 7:02 ` Hong Xu
2011-08-05 7:10 ` Aneesh V
2011-08-05 9:20 ` Albert ARIBAUD
2011-08-05 9:56 ` Aneesh V
2011-08-05 10:33 ` Hong Xu
2011-08-05 10:47 ` Aneesh V
2011-08-05 11:03 ` Albert ARIBAUD
2011-08-05 11:23 ` Reinhard Meyer
2011-08-05 11:26 ` Albert ARIBAUD
2011-08-05 11:51 ` Aneesh V
2011-08-05 13:17 ` Albert ARIBAUD
2011-08-05 14:59 ` Aneesh V
2011-08-07 6:55 ` Albert ARIBAUD
2011-08-08 8:24 ` Aneesh V
2011-08-08 9:39 ` Albert ARIBAUD
2011-08-08 9:51 ` Aneesh V
2011-08-08 9:59 ` Reinhard Meyer
2011-08-08 10:12 ` Aneesh V
2011-08-08 10:25 ` Reinhard Meyer
2011-08-08 10:27 ` Aneesh V [this message]
2011-08-08 11:05 ` Albert ARIBAUD
2011-08-05 23:04 ` J. William Campbell
2011-08-07 7:07 ` Albert ARIBAUD
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=4E3FBA1B.1020700@ti.com \
--to=aneesh@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox