diff mbox

[U-Boot,v2,1/3] ARM: cache: add an empty stub function for invalidate/flush dcache

Message ID 1433490452-26402-1-git-send-email-josh.wu@atmel.com
State Superseded
Delegated to: Albert ARIBAUD
Headers show

Commit Message

Josh Wu June 5, 2015, 7:47 a.m. UTC
Since some driver like ohci, lcd used dcache functions. But some ARM
cpu don't implement the invalidate_dcache_range()/flush_dcache_range()
functions.

To avoid compiling errors this patch adds an weak empty stub function
for all ARM cpu.

And each cpu can implement its own implementation. If not implemented
by default it will use an empty function.

Signed-off-by: Josh Wu <josh.wu@atmel.com>
---

Changes in v2: new added

 arch/arm/lib/cache.c | 9 +++++++++
 1 file changed, 9 insertions(+)

Comments

Marek Vasut June 5, 2015, 1:18 p.m. UTC | #1
On Friday, June 05, 2015 at 09:47:30 AM, Josh Wu wrote:
> Since some driver like ohci, lcd used dcache functions. But some ARM
> cpu don't implement the invalidate_dcache_range()/flush_dcache_range()
> functions.
> 
> To avoid compiling errors this patch adds an weak empty stub function
> for all ARM cpu.
> 
> And each cpu can implement its own implementation. If not implemented
> by default it will use an empty function.
> 
> Signed-off-by: Josh Wu <josh.wu@atmel.com>
> ---
> 
> Changes in v2: new added
> 
>  arch/arm/lib/cache.c | 9 +++++++++
>  1 file changed, 9 insertions(+)

So, why exactly can't this be entirely common code , but a CPU-specific
code ? :)

Best regards,
Marek Vasut
Josh Wu June 8, 2015, 2:05 a.m. UTC | #2
Hi, Marek

On 6/5/2015 9:18 PM, Marek Vasut wrote:
> On Friday, June 05, 2015 at 09:47:30 AM, Josh Wu wrote:
>> Since some driver like ohci, lcd used dcache functions. But some ARM
>> cpu don't implement the invalidate_dcache_range()/flush_dcache_range()
>> functions.
>>
>> To avoid compiling errors this patch adds an weak empty stub function
>> for all ARM cpu.
>>
>> And each cpu can implement its own implementation. If not implemented
>> by default it will use an empty function.
>>
>> Signed-off-by: Josh Wu <josh.wu@atmel.com>
>> ---
>>
>> Changes in v2: new added
>>
>>   arch/arm/lib/cache.c | 9 +++++++++
>>   1 file changed, 9 insertions(+)
> So, why exactly can't this be entirely common code , but a CPU-specific
> code ? :)

Do you mean to make those empty functions as common code for all arch 
cpu to use? It seems there is no place to put common code for all arch cpu.

Best Regards,
Josh Wu

>
> Best regards,
> Marek Vasut
Marek Vasut June 8, 2015, 8:26 a.m. UTC | #3
On Monday, June 08, 2015 at 04:05:04 AM, Josh Wu wrote:
> Hi, Marek
> 
> On 6/5/2015 9:18 PM, Marek Vasut wrote:
> > On Friday, June 05, 2015 at 09:47:30 AM, Josh Wu wrote:
> >> Since some driver like ohci, lcd used dcache functions. But some ARM
> >> cpu don't implement the invalidate_dcache_range()/flush_dcache_range()
> >> functions.
> >> 
> >> To avoid compiling errors this patch adds an weak empty stub function
> >> for all ARM cpu.
> >> 
> >> And each cpu can implement its own implementation. If not implemented
> >> by default it will use an empty function.
> >> 
> >> Signed-off-by: Josh Wu <josh.wu@atmel.com>
> >> ---
> >> 
> >> Changes in v2: new added
> >> 
> >>   arch/arm/lib/cache.c | 9 +++++++++
> >>   1 file changed, 9 insertions(+)
> > 
> > So, why exactly can't this be entirely common code , but a CPU-specific
> > code ? :)
> 
> Do you mean to make those empty functions as common code for all arch
> cpu to use?

Yes.

> It seems there is no place to put common code for all arch cpu.

Isn't that what the common/ directory is for ? ;-)

Best regards,
Marek Vasut
Josh Wu June 8, 2015, 9:15 a.m. UTC | #4
Hi, Marek

On 6/8/2015 4:26 PM, Marek Vasut wrote:
> On Monday, June 08, 2015 at 04:05:04 AM, Josh Wu wrote:
>> Hi, Marek
>>
>> On 6/5/2015 9:18 PM, Marek Vasut wrote:
>>> On Friday, June 05, 2015 at 09:47:30 AM, Josh Wu wrote:
>>>> Since some driver like ohci, lcd used dcache functions. But some ARM
>>>> cpu don't implement the invalidate_dcache_range()/flush_dcache_range()
>>>> functions.
>>>>
>>>> To avoid compiling errors this patch adds an weak empty stub function
>>>> for all ARM cpu.
>>>>
>>>> And each cpu can implement its own implementation. If not implemented
>>>> by default it will use an empty function.
>>>>
>>>> Signed-off-by: Josh Wu <josh.wu@atmel.com>
>>>> ---
>>>>
>>>> Changes in v2: new added
>>>>
>>>>    arch/arm/lib/cache.c | 9 +++++++++
>>>>    1 file changed, 9 insertions(+)
>>> So, why exactly can't this be entirely common code , but a CPU-specific
>>> code ? :)
>> Do you mean to make those empty functions as common code for all arch
>> cpu to use?
> Yes.
>
>> It seems there is no place to put common code for all arch cpu.
> Isn't that what the common/ directory is for ? ;-)

Oh, yes ;-)

I just think maybe it's more logical to keep those to the 
<arch>/lib/cache.c as cache are <arch> dependent.

Another point is if we create a new cache.c in common/, then the cache 
implementation code are in three files:
    <arch>/cpu/cache.c or cpu.c
    <arch>/lib/cache.c
    common/cache.c

It seems too fragmented. What do you think?

Best Regards,
Josh Wu
>
> Best regards,
> Marek Vasut
Tom Rini June 8, 2015, 1:20 p.m. UTC | #5
On Mon, Jun 08, 2015 at 10:26:29AM +0200, Marek Vasut wrote:
> On Monday, June 08, 2015 at 04:05:04 AM, Josh Wu wrote:
> > Hi, Marek
> > 
> > On 6/5/2015 9:18 PM, Marek Vasut wrote:
> > > On Friday, June 05, 2015 at 09:47:30 AM, Josh Wu wrote:
> > >> Since some driver like ohci, lcd used dcache functions. But some ARM
> > >> cpu don't implement the invalidate_dcache_range()/flush_dcache_range()
> > >> functions.
> > >> 
> > >> To avoid compiling errors this patch adds an weak empty stub function
> > >> for all ARM cpu.
> > >> 
> > >> And each cpu can implement its own implementation. If not implemented
> > >> by default it will use an empty function.
> > >> 
> > >> Signed-off-by: Josh Wu <josh.wu@atmel.com>
> > >> ---
> > >> 
> > >> Changes in v2: new added
> > >> 
> > >>   arch/arm/lib/cache.c | 9 +++++++++
> > >>   1 file changed, 9 insertions(+)
> > > 
> > > So, why exactly can't this be entirely common code , but a CPU-specific
> > > code ? :)
> > 
> > Do you mean to make those empty functions as common code for all arch
> > cpu to use?
> 
> Yes.
> 
> > It seems there is no place to put common code for all arch cpu.
> 
> Isn't that what the common/ directory is for ? ;-)

No, this is making something common for the sake of making it common
rather than good architecutre of the code I think.  We aren't going to
share real cache functions just these dummy ones.  We may re-evaluate
our dummy ones at some point in the future when people try and use some
particular combination harder, see for example the PowerPC dummy cache
functions we just recently dropped.  Thanks!
Josh Wu June 9, 2015, 3:54 a.m. UTC | #6
Hi, Tom

On 6/8/2015 9:20 PM, Tom Rini wrote:
> On Mon, Jun 08, 2015 at 10:26:29AM +0200, Marek Vasut wrote:
>> On Monday, June 08, 2015 at 04:05:04 AM, Josh Wu wrote:
>>> Hi, Marek
>>>
>>> On 6/5/2015 9:18 PM, Marek Vasut wrote:
>>>> On Friday, June 05, 2015 at 09:47:30 AM, Josh Wu wrote:
>>>>> Since some driver like ohci, lcd used dcache functions. But some ARM
>>>>> cpu don't implement the invalidate_dcache_range()/flush_dcache_range()
>>>>> functions.
>>>>>
>>>>> To avoid compiling errors this patch adds an weak empty stub function
>>>>> for all ARM cpu.
>>>>>
>>>>> And each cpu can implement its own implementation. If not implemented
>>>>> by default it will use an empty function.
>>>>>
>>>>> Signed-off-by: Josh Wu <josh.wu@atmel.com>
>>>>> ---
>>>>>
>>>>> Changes in v2: new added
>>>>>
>>>>>    arch/arm/lib/cache.c | 9 +++++++++
>>>>>    1 file changed, 9 insertions(+)
>>>> So, why exactly can't this be entirely common code , but a CPU-specific
>>>> code ? :)
>>> Do you mean to make those empty functions as common code for all arch
>>> cpu to use?
>> Yes.
>>
>>> It seems there is no place to put common code for all arch cpu.
>> Isn't that what the common/ directory is for ? ;-)
> No, this is making something common for the sake of making it common
> rather than good architecutre of the code I think.  We aren't going to
> share real cache functions just these dummy ones.

So it is the right place: arch/arm/lib/cache.c to put the dummy cache 
function.

> We may re-evaluate
> our dummy ones at some point in the future when people try and use some
> particular combination harder, see for example the PowerPC dummy cache
> functions we just recently dropped.  Thanks!
>

If this patch set are ok for you. I will sent more patches to drop the 
dummy cache functions in <arch>/cpu/ folders.
Also the flush_cache() in arch/arm/lib/cache.c can be dropped and just 
call flush_dcache_range() as the ARM1136, ARM926ejs alreay implemented 
their own flush_cache().

Best Regards,
Josh Wu
Tom Rini June 9, 2015, 1:11 p.m. UTC | #7
On Tue, Jun 09, 2015 at 11:54:14AM +0800, Josh Wu wrote:
> Hi, Tom
> 
> On 6/8/2015 9:20 PM, Tom Rini wrote:
> >On Mon, Jun 08, 2015 at 10:26:29AM +0200, Marek Vasut wrote:
> >>On Monday, June 08, 2015 at 04:05:04 AM, Josh Wu wrote:
> >>>Hi, Marek
> >>>
> >>>On 6/5/2015 9:18 PM, Marek Vasut wrote:
> >>>>On Friday, June 05, 2015 at 09:47:30 AM, Josh Wu wrote:
> >>>>>Since some driver like ohci, lcd used dcache functions. But some ARM
> >>>>>cpu don't implement the invalidate_dcache_range()/flush_dcache_range()
> >>>>>functions.
> >>>>>
> >>>>>To avoid compiling errors this patch adds an weak empty stub function
> >>>>>for all ARM cpu.
> >>>>>
> >>>>>And each cpu can implement its own implementation. If not implemented
> >>>>>by default it will use an empty function.
> >>>>>
> >>>>>Signed-off-by: Josh Wu <josh.wu@atmel.com>
> >>>>>---
> >>>>>
> >>>>>Changes in v2: new added
> >>>>>
> >>>>>   arch/arm/lib/cache.c | 9 +++++++++
> >>>>>   1 file changed, 9 insertions(+)
> >>>>So, why exactly can't this be entirely common code , but a CPU-specific
> >>>>code ? :)
> >>>Do you mean to make those empty functions as common code for all arch
> >>>cpu to use?
> >>Yes.
> >>
> >>>It seems there is no place to put common code for all arch cpu.
> >>Isn't that what the common/ directory is for ? ;-)
> >No, this is making something common for the sake of making it common
> >rather than good architecutre of the code I think.  We aren't going to
> >share real cache functions just these dummy ones.
> 
> So it is the right place: arch/arm/lib/cache.c to put the dummy
> cache function.

Yes.

> >We may re-evaluate
> >our dummy ones at some point in the future when people try and use some
> >particular combination harder, see for example the PowerPC dummy cache
> >functions we just recently dropped.  Thanks!
> 
> If this patch set are ok for you. I will sent more patches to drop
> the dummy cache functions in <arch>/cpu/ folders.

Right, that's the best palce I think, baring an existing arch having a
location for weak cache functions already (like arm does).

> Also the flush_cache() in arch/arm/lib/cache.c can be dropped and
> just call flush_dcache_range() as the ARM1136, ARM926ejs alreay
> implemented their own flush_cache().

Nope, other things fail if you do that (vpac270_nor_256 and 24 others at
least so far in my test build).
Josh Wu June 10, 2015, 9:49 a.m. UTC | #8
On 6/9/2015 9:11 PM, Tom Rini wrote:
> On Tue, Jun 09, 2015 at 11:54:14AM +0800, Josh Wu wrote:
>> Hi, Tom
>>
>> On 6/8/2015 9:20 PM, Tom Rini wrote:
>>> On Mon, Jun 08, 2015 at 10:26:29AM +0200, Marek Vasut wrote:
>>>> On Monday, June 08, 2015 at 04:05:04 AM, Josh Wu wrote:
>>>>> Hi, Marek
>>>>>
>>>>> On 6/5/2015 9:18 PM, Marek Vasut wrote:
>>>>>> On Friday, June 05, 2015 at 09:47:30 AM, Josh Wu wrote:
>>>>>>> Since some driver like ohci, lcd used dcache functions. But some ARM
>>>>>>> cpu don't implement the invalidate_dcache_range()/flush_dcache_range()
>>>>>>> functions.
>>>>>>>
>>>>>>> To avoid compiling errors this patch adds an weak empty stub function
>>>>>>> for all ARM cpu.
>>>>>>>
>>>>>>> And each cpu can implement its own implementation. If not implemented
>>>>>>> by default it will use an empty function.
>>>>>>>
>>>>>>> Signed-off-by: Josh Wu <josh.wu@atmel.com>
>>>>>>> ---
>>>>>>>
>>>>>>> Changes in v2: new added
>>>>>>>
>>>>>>>    arch/arm/lib/cache.c | 9 +++++++++
>>>>>>>    1 file changed, 9 insertions(+)
>>>>>> So, why exactly can't this be entirely common code , but a CPU-specific
>>>>>> code ? :)
>>>>> Do you mean to make those empty functions as common code for all arch
>>>>> cpu to use?
>>>> Yes.
>>>>
>>>>> It seems there is no place to put common code for all arch cpu.
>>>> Isn't that what the common/ directory is for ? ;-)
>>> No, this is making something common for the sake of making it common
>>> rather than good architecutre of the code I think.  We aren't going to
>>> share real cache functions just these dummy ones.
>> So it is the right place: arch/arm/lib/cache.c to put the dummy
>> cache function.
> Yes.
>
>>> We may re-evaluate
>>> our dummy ones at some point in the future when people try and use some
>>> particular combination harder, see for example the PowerPC dummy cache
>>> functions we just recently dropped.  Thanks!
>> If this patch set are ok for you. I will sent more patches to drop
>> the dummy cache functions in <arch>/cpu/ folders.
> Right, that's the best palce I think, baring an existing arch having a
> location for weak cache functions already (like arm does).
>
>> Also the flush_cache() in arch/arm/lib/cache.c can be dropped and
>> just call flush_dcache_range() as the ARM1136, ARM926ejs alreay
>> implemented their own flush_cache().
> Nope, other things fail if you do that (vpac270_nor_256 and 24 others at
> least so far in my test build).

Does it fail to compile or on running? As I don't have the board to test 
the binary, but I don't find any compile error when I apply such a patch.
Maybe it is better to sent out my patch for you to check.

Best Regards,
Josh Wu
>
Marek Vasut June 10, 2015, 9:58 a.m. UTC | #9
On Wednesday, June 10, 2015 at 11:49:54 AM, Josh Wu wrote:
> On 6/9/2015 9:11 PM, Tom Rini wrote:
> > On Tue, Jun 09, 2015 at 11:54:14AM +0800, Josh Wu wrote:
> >> Hi, Tom
> >> 
> >> On 6/8/2015 9:20 PM, Tom Rini wrote:
> >>> On Mon, Jun 08, 2015 at 10:26:29AM +0200, Marek Vasut wrote:
> >>>> On Monday, June 08, 2015 at 04:05:04 AM, Josh Wu wrote:
> >>>>> Hi, Marek
> >>>>> 
> >>>>> On 6/5/2015 9:18 PM, Marek Vasut wrote:
> >>>>>> On Friday, June 05, 2015 at 09:47:30 AM, Josh Wu wrote:
> >>>>>>> Since some driver like ohci, lcd used dcache functions. But some
> >>>>>>> ARM cpu don't implement the
> >>>>>>> invalidate_dcache_range()/flush_dcache_range() functions.
> >>>>>>> 
> >>>>>>> To avoid compiling errors this patch adds an weak empty stub
> >>>>>>> function for all ARM cpu.
> >>>>>>> 
> >>>>>>> And each cpu can implement its own implementation. If not
> >>>>>>> implemented by default it will use an empty function.
> >>>>>>> 
> >>>>>>> Signed-off-by: Josh Wu <josh.wu@atmel.com>
> >>>>>>> ---
> >>>>>>> 
> >>>>>>> Changes in v2: new added
> >>>>>>> 
> >>>>>>>    arch/arm/lib/cache.c | 9 +++++++++
> >>>>>>>    1 file changed, 9 insertions(+)
> >>>>>> 
> >>>>>> So, why exactly can't this be entirely common code , but a
> >>>>>> CPU-specific code ? :)
> >>>>> 
> >>>>> Do you mean to make those empty functions as common code for all arch
> >>>>> cpu to use?
> >>>> 
> >>>> Yes.
> >>>> 
> >>>>> It seems there is no place to put common code for all arch cpu.
> >>>> 
> >>>> Isn't that what the common/ directory is for ? ;-)
> >>> 
> >>> No, this is making something common for the sake of making it common
> >>> rather than good architecutre of the code I think.  We aren't going to
> >>> share real cache functions just these dummy ones.
> >> 
> >> So it is the right place: arch/arm/lib/cache.c to put the dummy
> >> cache function.
> > 
> > Yes.
> > 
> >>> We may re-evaluate
> >>> our dummy ones at some point in the future when people try and use some
> >>> particular combination harder, see for example the PowerPC dummy cache
> >>> functions we just recently dropped.  Thanks!
> >> 
> >> If this patch set are ok for you. I will sent more patches to drop
> >> the dummy cache functions in <arch>/cpu/ folders.
> > 
> > Right, that's the best palce I think, baring an existing arch having a
> > location for weak cache functions already (like arm does).
> > 
> >> Also the flush_cache() in arch/arm/lib/cache.c can be dropped and
> >> just call flush_dcache_range() as the ARM1136, ARM926ejs alreay
> >> implemented their own flush_cache().
> > 
> > Nope, other things fail if you do that (vpac270_nor_256 and 24 others at
> > least so far in my test build).
> 
> Does it fail to compile or on running? As I don't have the board to test
> the binary, but I don't find any compile error when I apply such a patch.
> Maybe it is better to sent out my patch for you to check.

VPAC is PXA270 and to my knowledge, PXA has no cache support in place at all.
Tom Rini June 10, 2015, 6:20 p.m. UTC | #10
On Wed, Jun 10, 2015 at 05:49:54PM +0800, Josh Wu wrote:
> On 6/9/2015 9:11 PM, Tom Rini wrote:
> >On Tue, Jun 09, 2015 at 11:54:14AM +0800, Josh Wu wrote:
> >>Hi, Tom
> >>
> >>On 6/8/2015 9:20 PM, Tom Rini wrote:
> >>>On Mon, Jun 08, 2015 at 10:26:29AM +0200, Marek Vasut wrote:
> >>>>On Monday, June 08, 2015 at 04:05:04 AM, Josh Wu wrote:
> >>>>>Hi, Marek
> >>>>>
> >>>>>On 6/5/2015 9:18 PM, Marek Vasut wrote:
> >>>>>>On Friday, June 05, 2015 at 09:47:30 AM, Josh Wu wrote:
> >>>>>>>Since some driver like ohci, lcd used dcache functions. But some ARM
> >>>>>>>cpu don't implement the invalidate_dcache_range()/flush_dcache_range()
> >>>>>>>functions.
> >>>>>>>
> >>>>>>>To avoid compiling errors this patch adds an weak empty stub function
> >>>>>>>for all ARM cpu.
> >>>>>>>
> >>>>>>>And each cpu can implement its own implementation. If not implemented
> >>>>>>>by default it will use an empty function.
> >>>>>>>
> >>>>>>>Signed-off-by: Josh Wu <josh.wu@atmel.com>
> >>>>>>>---
> >>>>>>>
> >>>>>>>Changes in v2: new added
> >>>>>>>
> >>>>>>>   arch/arm/lib/cache.c | 9 +++++++++
> >>>>>>>   1 file changed, 9 insertions(+)
> >>>>>>So, why exactly can't this be entirely common code , but a CPU-specific
> >>>>>>code ? :)
> >>>>>Do you mean to make those empty functions as common code for all arch
> >>>>>cpu to use?
> >>>>Yes.
> >>>>
> >>>>>It seems there is no place to put common code for all arch cpu.
> >>>>Isn't that what the common/ directory is for ? ;-)
> >>>No, this is making something common for the sake of making it common
> >>>rather than good architecutre of the code I think.  We aren't going to
> >>>share real cache functions just these dummy ones.
> >>So it is the right place: arch/arm/lib/cache.c to put the dummy
> >>cache function.
> >Yes.
> >
> >>>We may re-evaluate
> >>>our dummy ones at some point in the future when people try and use some
> >>>particular combination harder, see for example the PowerPC dummy cache
> >>>functions we just recently dropped.  Thanks!
> >>If this patch set are ok for you. I will sent more patches to drop
> >>the dummy cache functions in <arch>/cpu/ folders.
> >Right, that's the best palce I think, baring an existing arch having a
> >location for weak cache functions already (like arm does).
> >
> >>Also the flush_cache() in arch/arm/lib/cache.c can be dropped and
> >>just call flush_dcache_range() as the ARM1136, ARM926ejs alreay
> >>implemented their own flush_cache().
> >Nope, other things fail if you do that (vpac270_nor_256 and 24 others at
> >least so far in my test build).
> 
> Does it fail to compile or on running? As I don't have the board to
> test the binary, but I don't find any compile error when I apply
> such a patch.

It was a link failure for me when I just dropped flush_cache() from
arch/arm/lib/cache.c
Josh Wu June 11, 2015, 5:03 a.m. UTC | #11
On 6/10/2015 5:58 PM, Marek Vasut wrote:
> On Wednesday, June 10, 2015 at 11:49:54 AM, Josh Wu wrote:
>> On 6/9/2015 9:11 PM, Tom Rini wrote:
>>> On Tue, Jun 09, 2015 at 11:54:14AM +0800, Josh Wu wrote:
>>>> Hi, Tom
>>>>
>>>> On 6/8/2015 9:20 PM, Tom Rini wrote:
>>>>> On Mon, Jun 08, 2015 at 10:26:29AM +0200, Marek Vasut wrote:
>>>>>> On Monday, June 08, 2015 at 04:05:04 AM, Josh Wu wrote:
>>>>>>> Hi, Marek
>>>>>>>
>>>>>>> On 6/5/2015 9:18 PM, Marek Vasut wrote:
>>>>>>>> On Friday, June 05, 2015 at 09:47:30 AM, Josh Wu wrote:
>>>>>>>>> Since some driver like ohci, lcd used dcache functions. But some
>>>>>>>>> ARM cpu don't implement the
>>>>>>>>> invalidate_dcache_range()/flush_dcache_range() functions.
>>>>>>>>>
>>>>>>>>> To avoid compiling errors this patch adds an weak empty stub
>>>>>>>>> function for all ARM cpu.
>>>>>>>>>
>>>>>>>>> And each cpu can implement its own implementation. If not
>>>>>>>>> implemented by default it will use an empty function.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Josh Wu <josh.wu@atmel.com>
>>>>>>>>> ---
>>>>>>>>>
>>>>>>>>> Changes in v2: new added
>>>>>>>>>
>>>>>>>>>     arch/arm/lib/cache.c | 9 +++++++++
>>>>>>>>>     1 file changed, 9 insertions(+)
>>>>>>>> So, why exactly can't this be entirely common code , but a
>>>>>>>> CPU-specific code ? :)
>>>>>>> Do you mean to make those empty functions as common code for all arch
>>>>>>> cpu to use?
>>>>>> Yes.
>>>>>>
>>>>>>> It seems there is no place to put common code for all arch cpu.
>>>>>> Isn't that what the common/ directory is for ? ;-)
>>>>> No, this is making something common for the sake of making it common
>>>>> rather than good architecutre of the code I think.  We aren't going to
>>>>> share real cache functions just these dummy ones.
>>>> So it is the right place: arch/arm/lib/cache.c to put the dummy
>>>> cache function.
>>> Yes.
>>>
>>>>> We may re-evaluate
>>>>> our dummy ones at some point in the future when people try and use some
>>>>> particular combination harder, see for example the PowerPC dummy cache
>>>>> functions we just recently dropped.  Thanks!
>>>> If this patch set are ok for you. I will sent more patches to drop
>>>> the dummy cache functions in <arch>/cpu/ folders.
>>> Right, that's the best palce I think, baring an existing arch having a
>>> location for weak cache functions already (like arm does).
>>>
>>>> Also the flush_cache() in arch/arm/lib/cache.c can be dropped and
>>>> just call flush_dcache_range() as the ARM1136, ARM926ejs alreay
>>>> implemented their own flush_cache().
>>> Nope, other things fail if you do that (vpac270_nor_256 and 24 others at
>>> least so far in my test build).
>> Does it fail to compile or on running? As I don't have the board to test
>> the binary, but I don't find any compile error when I apply such a patch.
>> Maybe it is better to sent out my patch for you to check.
> VPAC is PXA270 and to my knowledge, PXA has no cache support in place at all.

ok, so use a empty function is reasonable for pxa.

Marek, Tom

I just sent out another two patches:
first one is drop the invalidate_dcache_range()/flush_dcache_range().
second one is drop the flush_cache() function.

Could you check those two patches? thank you.

Best Regards,
Josh Wu
Josh Wu June 11, 2015, 5:21 a.m. UTC | #12
This series is based on the patch I sent:
  http://patchwork.ozlabs.org/patch/481095/
As above introduces the default empty function for invalidate_dcache_range() &
flush_dcache_range() in arch/arm/lib/cache.c.
So in this series, we can drop the empty stubs in arch/arm/cpu/

Also this series introduces a default function for flush_cache().


Josh Wu (2):
  ARM: cache: drop the empty dcache functions as we have it in
    lib/cache.c
  ARM: cache: implement a default flush_cache() function

 arch/arm/cpu/arm1136/cpu.c     | 17 -----------------
 arch/arm/cpu/arm926ejs/cache.c | 17 -----------------
 arch/arm/cpu/armv7/cache_v7.c  | 21 ---------------------
 arch/arm/cpu/armv8/cache_v8.c  | 16 ----------------
 arch/arm/lib/cache.c           | 26 +++++---------------------
 5 files changed, 5 insertions(+), 92 deletions(-)
Josh Wu July 1, 2015, 2:01 a.m. UTC | #13
Hi,

Any feedback for this series patch?

Best Regards,
Josh Wu

On 6/11/2015 1:21 PM, Josh Wu wrote:
> This series is based on the patch I sent:
>    http://patchwork.ozlabs.org/patch/481095/
> As above introduces the default empty function for invalidate_dcache_range() &
> flush_dcache_range() in arch/arm/lib/cache.c.
> So in this series, we can drop the empty stubs in arch/arm/cpu/
>
> Also this series introduces a default function for flush_cache().
>
>
> Josh Wu (2):
>    ARM: cache: drop the empty dcache functions as we have it in
>      lib/cache.c
>    ARM: cache: implement a default flush_cache() function
>
>   arch/arm/cpu/arm1136/cpu.c     | 17 -----------------
>   arch/arm/cpu/arm926ejs/cache.c | 17 -----------------
>   arch/arm/cpu/armv7/cache_v7.c  | 21 ---------------------
>   arch/arm/cpu/armv8/cache_v8.c  | 16 ----------------
>   arch/arm/lib/cache.c           | 26 +++++---------------------
>   5 files changed, 5 insertions(+), 92 deletions(-)
>
diff mbox

Patch

diff --git a/arch/arm/lib/cache.c b/arch/arm/lib/cache.c
index 74cfde6..bc48f53 100644
--- a/arch/arm/lib/cache.c
+++ b/arch/arm/lib/cache.c
@@ -53,6 +53,15 @@  __weak void enable_caches(void)
 	puts("WARNING: Caches not enabled\n");
 }
 
+__weak void invalidate_dcache_range(unsigned long start, unsigned long stop)
+{
+	/* An empty stub, real implementation should be in platform code */
+}
+__weak void flush_dcache_range(unsigned long start, unsigned long stop)
+{
+	/* An empty stub, real implementation should be in platform code */
+}
+
 #ifdef CONFIG_SYS_NONCACHED_MEMORY
 /*
  * Reserve one MMU section worth of address space below the malloc() area that