linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jean-Jacques Hiblot <jjhiblot@gmail.com>
To: Wenyou Yang <Wenyou.Yang@microchip.com>
Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com>,
	Mark Rutland <mark.rutland@arm.com>,
	devicetree <devicetree@vger.kernel.org>,
	Russell King - ARM Linux <linux@arm.linux.org.uk>,
	Nicolas Ferre <nicolas.ferre@atmel.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"robh+dt" <robh+dt@kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 1/3] ARM: at91: flush the L2 cache before entering cpu idle
Date: Wed, 11 Jan 2017 12:05:05 +0100	[thread overview]
Message-ID: <CACh+v5M3tU4WHMqAX0zm2H=zzwc0+XChyG1tnH2aHxaacm6C=A@mail.gmail.com> (raw)
In-Reply-To: <F9F4555C4E01D7469D37975B62D0EFBB496BE4@CHN-SV-EXMX07.mchp-main.com>

2017-01-11 9:15 GMT+01:00  <Wenyou.Yang@microchip.com>:
> Hi Jean-Jacques,
>
>> -----Original Message-----
>> From: Jean-Jacques Hiblot [mailto:jjhiblot@gmail.com]
>> Sent: 2017年1月11日 0:51
>> To: Alexandre Belloni <alexandre.belloni@free-electrons.com>
>> Cc: Wenyou Yang - A41535 <Wenyou.Yang@microchip.com>; Mark Rutland
>> <mark.rutland@arm.com>; devicetree <devicetree@vger.kernel.org>; Russell
>> King <linux@arm.linux.org.uk>; Wenyou Yang - A41535
>> <Wenyou.Yang@microchip.com>; Nicolas Ferre <nicolas.ferre@atmel.com>;
>> Linux Kernel Mailing List <linux-kernel@vger.kernel.org>; Rob Herring
>> <robh+dt@kernel.org>; linux-arm-kernel@lists.infradead.org
>> Subject: Re: [PATCH 1/3] ARM: at91: flush the L2 cache before entering cpu idle
>>
>> 2017-01-10 17:18 GMT+01:00 Alexandre Belloni
>> <alexandre.belloni@free-electrons.com>:
>> > I though a bit more about it, and I don't really like the new
>> > compatible string. I don't feel this should be necessary.
>> >
>> > What about the following:
>> >
>> > diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c index
>> > b4332b727e9c..0333aca63e44 100644
>> > --- a/arch/arm/mach-at91/pm.c
>> > +++ b/arch/arm/mach-at91/pm.c
>> > @@ -53,6 +53,7 @@ extern void at91_pinctrl_gpio_resume(void);  static
>> > struct {
>> >         unsigned long uhp_udp_mask;
>> >         int memctrl;
>> > +       bool has_l2_cache;
>> >  } at91_pm_data;
>> >
>> >  void __iomem *at91_ramc_base[2];
>> > @@ -267,6 +268,11 @@ static void at91_ddr_standby(void)
>> >         u32 lpr0, lpr1 = 0;
>> >         u32 saved_lpr0, saved_lpr1 = 0;
>> >
>>
>> > +       if (at91_pm_data.has_l2_cache) {
>> > +               flush_cache_all();
>> what is the point of calling flush_cache_all() here ? Do we really care that dirty
>> data in L1 is written to DDR ? I may be missing something but to me it's just extra
>> latency.
>
> Are you mean use outer_flush_all() to flush all cache lines in the outer cache only?

Yes that's what I meant. You see, you don't flush the cache for
sama5d3 so it shouldn't be required either for sam5d4. You should be
able to test it quickly and see if L1 flush is indeed required by
replacing  flush_cache_all() with outer_flush_all(). BTW is highly
probable that L2 cache flush is done in outer_disable() so calling
outer_flush_all() is probably no required.

However the more I think on it, the more I wonder about the reason why
L2 flushing is required or to put it differently: is flusing the L2
cache the correct thing to do or just a workaround ?
Could it be that L2 is doing some maintenance operation when DDR
enters self refresh? In that case maybe a simple cache sync could be
used.

>
>> > +               outer_disable();
>> It seems to me that if there's no L2 cache, then outer_disable()  is a no-op. It
>> could be called unconditionally.
>> > +       }
>> > +
>> >         if (at91_ramc_base[1]) {
>> >                 saved_lpr1 = at91_ramc_read(1, AT91_DDRSDRC_LPR);
>> >                 lpr1 = saved_lpr1 & ~AT91_DDRSDRC_LPCB; @@ -287,6
>> > +293,9 @@ static void at91_ddr_standby(void)
>> >         at91_ramc_write(0, AT91_DDRSDRC_LPR, saved_lpr0);
>> >         if (at91_ramc_base[1])
>> >                 at91_ramc_write(1, AT91_DDRSDRC_LPR, saved_lpr1);
>> > +
>> > +       if (at91_pm_data.has_l2_cache)
>> > +               outer_resume();
>>
>> same remark as for outer_disable()
>>
>> Jean-Jacques
>>
>> >  }
>> >
>> >  /* We manage both DDRAM/SDRAM controllers, we need more than one
>> > value
>> >  * to
>> > @@ -353,6 +362,11 @@ static __init void at91_dt_ramc(void)
>> >                 return;
>> >         }
>> >
>> > +       np = of_find_compatible_node(NULL, NULL, "arm,pl310-cache");
>> > +       if (np)
>> > +               at91_pm_data.has_l2_cache = true;
>> > +       of_node_put(np);
>> > +
>> >         at91_pm_set_standby(standby);
>> >  }
>> >
>> >
>> > This has the following benefits:
>> >  - everybody will have the fix, regardless of whether the dtb is
>> > updated
>> >  - has_l2_cache can be used later in at91_pm_suspend instead of calling
>> >    it unconditionnaly (I'll send a patch)
>> >
>> >
>> > On 06/01/2017 at 14:59:45 +0800, Wenyou Yang wrote :
>> >> For the SoCs such as SAMA5D2 and SAMA5D4 which have L2 cache, flush
>> >> the L2 cache first before entering the cpu idle.
>> >>
>> >> Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
>> >> ---
>> >>
>> >>  arch/arm/mach-at91/pm.c       | 19 +++++++++++++++++++
>> >>  drivers/memory/atmel-sdramc.c |  1 +
>> >>  2 files changed, 20 insertions(+)
>> >>
>> >> diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c index
>> >> b4332b727e9c..1a60dede1a01 100644
>> >> --- a/arch/arm/mach-at91/pm.c
>> >> +++ b/arch/arm/mach-at91/pm.c
>> >> @@ -289,6 +289,24 @@ static void at91_ddr_standby(void)
>> >>               at91_ramc_write(1, AT91_DDRSDRC_LPR, saved_lpr1);  }
>> >>
>> >> +static void at91_ddr_cache_standby(void) {
>> >> +     u32 saved_lpr;
>> >> +
>> >> +     flush_cache_all();
>> >> +     outer_disable();
>> >> +
>> >> +     saved_lpr = at91_ramc_read(0, AT91_DDRSDRC_LPR);
>> >> +     at91_ramc_write(0, AT91_DDRSDRC_LPR, (saved_lpr &
>> >> +                     (~AT91_DDRSDRC_LPCB)) |
>> >> + AT91_DDRSDRC_LPCB_SELF_REFRESH);
>> >> +
>> >> +     cpu_do_idle();
>> >> +
>> >> +     at91_ramc_write(0, AT91_DDRSDRC_LPR, saved_lpr);
>> >> +
>> >> +     outer_resume();
>> >> +}
>> >> +
>> >>  /* We manage both DDRAM/SDRAM controllers, we need more than one
>> value to
>> >>   * remember.
>> >>   */
>> >> @@ -324,6 +342,7 @@ static const struct of_device_id const ramc_ids[]
>> __initconst = {
>> >>       { .compatible = "atmel,at91sam9260-sdramc", .data =
>> at91sam9_sdram_standby },
>> >>       { .compatible = "atmel,at91sam9g45-ddramc", .data = at91_ddr_standby },
>> >>       { .compatible = "atmel,sama5d3-ddramc", .data =
>> >> at91_ddr_standby },
>> >> +     { .compatible = "atmel,sama5d4-ddramc", .data =
>> >> + at91_ddr_cache_standby },
>> >>       { /*sentinel*/ }
>> >>  };
>> >>
>> >> diff --git a/drivers/memory/atmel-sdramc.c
>> >> b/drivers/memory/atmel-sdramc.c index b418b39af180..7e5c5c6c1348
>> >> 100644
>> >> --- a/drivers/memory/atmel-sdramc.c
>> >> +++ b/drivers/memory/atmel-sdramc.c
>> >> @@ -48,6 +48,7 @@ static const struct of_device_id atmel_ramc_of_match[]
>> = {
>> >>       { .compatible = "atmel,at91sam9260-sdramc", .data =
>> &at91rm9200_caps, },
>> >>       { .compatible = "atmel,at91sam9g45-ddramc", .data =
>> &at91sam9g45_caps, },
>> >>       { .compatible = "atmel,sama5d3-ddramc", .data = &sama5d3_caps,
>> >> },
>> >> +     { .compatible = "atmel,sama5d4-ddramc", .data = &sama5d3_caps,
>> >> + },
>> >>       {},
>> >>  };
>> >>
>> >> --
>> >> 2.11.0
>> >>
>> >
>> > --
>> > Alexandre Belloni, Free Electrons
>> > Embedded Linux and Kernel engineering
>> > http://free-electrons.com
>> >
>> > _______________________________________________
>> > linux-arm-kernel mailing list
>> > linux-arm-kernel@lists.infradead.org
>> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2017-01-11 11:05 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-06  6:59 [PATCH 0/3] ARM: at91: fix cpuidle crash on SAMA5D4 Xplained board Wenyou Yang
2017-01-06  6:59 ` [PATCH 1/3] ARM: at91: flush the L2 cache before entering cpu idle Wenyou Yang
2017-01-06  9:05   ` Alexandre Belloni
2017-01-09  1:47     ` Wenyou.Yang
2017-01-10 16:18   ` Alexandre Belloni
2017-01-10 16:30     ` Alexandre Belloni
2017-01-10 16:50     ` Jean-Jacques Hiblot
2017-01-10 17:22       ` Alexandre Belloni
2017-01-11  8:15       ` Wenyou.Yang
2017-01-11 11:05         ` Jean-Jacques Hiblot [this message]
2017-01-11 11:18           ` Russell King - ARM Linux
2017-01-11 13:18             ` Jean-Jacques Hiblot
2017-01-12  1:25             ` Wenyou.Yang
2017-01-06  6:59 ` [PATCH 2/3] doc: binding: add new compatible for SDRAM/DDR Controller Wenyou Yang
2017-01-09 18:45   ` Rob Herring
2017-01-06  6:59 ` [PATCH 3/3] ARM: dts: at91: use "atmel,sama5d4-ddramc" for ramc Wenyou Yang

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='CACh+v5M3tU4WHMqAX0zm2H=zzwc0+XChyG1tnH2aHxaacm6C=A@mail.gmail.com' \
    --to=jjhiblot@gmail.com \
    --cc=Wenyou.Yang@microchip.com \
    --cc=alexandre.belloni@free-electrons.com \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=mark.rutland@arm.com \
    --cc=nicolas.ferre@atmel.com \
    --cc=robh+dt@kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).