* [PATCH] ARM: EXYNOS: Restore the entry address setup code post-resume
@ 2014-06-26 10:58 ` Abhilash Kesavan
0 siblings, 0 replies; 130+ messages in thread
From: Abhilash Kesavan @ 2014-06-26 10:58 UTC (permalink / raw)
To: linux-samsung-soc, linux-arm-kernel, kgene.kim, nicolas.pitre
Cc: kesavan.abhilash, abrestic, dianders, Abhilash Kesavan
Setup the mcpm entry address again on system resume as the
iRAM contents are lost across an s2r cycle.
Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
---
This has been tested after applying the Exynos5420 S2R support series
along with Nicolas Pitre's boot cluster CCI enablement patches on Peach
Pit.
arch/arm/mach-exynos/mcpm-exynos.c | 31 +++++++++++++++++++++----------
1 file changed, 21 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-exynos/mcpm-exynos.c b/arch/arm/mach-exynos/mcpm-exynos.c
index 8c610e2..0bf734d 100644
--- a/arch/arm/mach-exynos/mcpm-exynos.c
+++ b/arch/arm/mach-exynos/mcpm-exynos.c
@@ -15,6 +15,7 @@
#include <linux/delay.h>
#include <linux/io.h>
#include <linux/of_address.h>
+#include <linux/syscore_ops.h>
#include <asm/cputype.h>
#include <asm/cp15.h>
@@ -26,6 +27,7 @@
#define EXYNOS5420_CPUS_PER_CLUSTER 4
#define EXYNOS5420_NR_CLUSTERS 2
+static void __iomem *ns_sram_base_addr;
/*
* The common v7_exit_coherency_flush API could not be used because of the
* Erratum 799270 workaround. This macro is the same as the common one (in
@@ -308,10 +310,26 @@ static const struct of_device_id exynos_dt_mcpm_match[] = {
{},
};
+static void exynos_mcpm_setup_entry_point(void)
+{
+ /*
+ * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
+ * as part of secondary_cpu_start(). Let's redirect it to the
+ * mcpm_entry_point(). This is done during both secondary boot-up as
+ * well as system resume.
+ */
+ __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
+ __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
+ __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
+}
+
+static struct syscore_ops exynos_mcpm_syscore_ops = {
+ .resume = exynos_mcpm_setup_entry_point,
+};
+
static int __init exynos_mcpm_init(void)
{
struct device_node *node;
- void __iomem *ns_sram_base_addr;
int ret;
node = of_find_matching_node(NULL, exynos_dt_mcpm_match);
@@ -357,16 +375,9 @@ static int __init exynos_mcpm_init(void)
pr_info("Exynos MCPM support installed\n");
- /*
- * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
- * as part of secondary_cpu_start(). Let's redirect it to the
- * mcpm_entry_point().
- */
- __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
- __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
- __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
+ exynos_mcpm_setup_entry_point();
- iounmap(ns_sram_base_addr);
+ register_syscore_ops(&exynos_mcpm_syscore_ops);
return ret;
}
--
1.8.3.2
^ permalink raw reply related [flat|nested] 130+ messages in thread
* [PATCH] ARM: EXYNOS: Restore the entry address setup code post-resume
@ 2014-06-26 10:58 ` Abhilash Kesavan
0 siblings, 0 replies; 130+ messages in thread
From: Abhilash Kesavan @ 2014-06-26 10:58 UTC (permalink / raw)
To: linux-arm-kernel
Setup the mcpm entry address again on system resume as the
iRAM contents are lost across an s2r cycle.
Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
---
This has been tested after applying the Exynos5420 S2R support series
along with Nicolas Pitre's boot cluster CCI enablement patches on Peach
Pit.
arch/arm/mach-exynos/mcpm-exynos.c | 31 +++++++++++++++++++++----------
1 file changed, 21 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-exynos/mcpm-exynos.c b/arch/arm/mach-exynos/mcpm-exynos.c
index 8c610e2..0bf734d 100644
--- a/arch/arm/mach-exynos/mcpm-exynos.c
+++ b/arch/arm/mach-exynos/mcpm-exynos.c
@@ -15,6 +15,7 @@
#include <linux/delay.h>
#include <linux/io.h>
#include <linux/of_address.h>
+#include <linux/syscore_ops.h>
#include <asm/cputype.h>
#include <asm/cp15.h>
@@ -26,6 +27,7 @@
#define EXYNOS5420_CPUS_PER_CLUSTER 4
#define EXYNOS5420_NR_CLUSTERS 2
+static void __iomem *ns_sram_base_addr;
/*
* The common v7_exit_coherency_flush API could not be used because of the
* Erratum 799270 workaround. This macro is the same as the common one (in
@@ -308,10 +310,26 @@ static const struct of_device_id exynos_dt_mcpm_match[] = {
{},
};
+static void exynos_mcpm_setup_entry_point(void)
+{
+ /*
+ * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
+ * as part of secondary_cpu_start(). Let's redirect it to the
+ * mcpm_entry_point(). This is done during both secondary boot-up as
+ * well as system resume.
+ */
+ __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
+ __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
+ __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
+}
+
+static struct syscore_ops exynos_mcpm_syscore_ops = {
+ .resume = exynos_mcpm_setup_entry_point,
+};
+
static int __init exynos_mcpm_init(void)
{
struct device_node *node;
- void __iomem *ns_sram_base_addr;
int ret;
node = of_find_matching_node(NULL, exynos_dt_mcpm_match);
@@ -357,16 +375,9 @@ static int __init exynos_mcpm_init(void)
pr_info("Exynos MCPM support installed\n");
- /*
- * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
- * as part of secondary_cpu_start(). Let's redirect it to the
- * mcpm_entry_point().
- */
- __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
- __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
- __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
+ exynos_mcpm_setup_entry_point();
- iounmap(ns_sram_base_addr);
+ register_syscore_ops(&exynos_mcpm_syscore_ops);
return ret;
}
--
1.8.3.2
^ permalink raw reply related [flat|nested] 130+ messages in thread
* Re: [PATCH] ARM: EXYNOS: Restore the entry address setup code post-resume
2014-06-26 10:58 ` Abhilash Kesavan
@ 2014-06-26 12:25 ` Abhilash Kesavan
-1 siblings, 0 replies; 130+ messages in thread
From: Abhilash Kesavan @ 2014-06-26 12:25 UTC (permalink / raw)
To: linux-samsung-soc, linux-arm-kernel, Kukjin Kim, Nicolas Pitre
Cc: Me2, Andrew Bresticker, Douglas Anderson, Abhilash Kesavan
Hi,
On Thu, Jun 26, 2014 at 4:28 PM, Abhilash Kesavan <a.kesavan@samsung.com> wrote:
> Setup the mcpm entry address again on system resume as the
> iRAM contents are lost across an s2r cycle.
>
> Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
> ---
> This has been tested after applying the Exynos5420 S2R support series
> along with Nicolas Pitre's boot cluster CCI enablement patches on Peach
> Pit.
>
> arch/arm/mach-exynos/mcpm-exynos.c | 31 +++++++++++++++++++++----------
> 1 file changed, 21 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/mcpm-exynos.c b/arch/arm/mach-exynos/mcpm-exynos.c
> index 8c610e2..0bf734d 100644
> --- a/arch/arm/mach-exynos/mcpm-exynos.c
> +++ b/arch/arm/mach-exynos/mcpm-exynos.c
> @@ -15,6 +15,7 @@
> #include <linux/delay.h>
> #include <linux/io.h>
> #include <linux/of_address.h>
> +#include <linux/syscore_ops.h>
>
> #include <asm/cputype.h>
> #include <asm/cp15.h>
> @@ -26,6 +27,7 @@
> #define EXYNOS5420_CPUS_PER_CLUSTER 4
> #define EXYNOS5420_NR_CLUSTERS 2
>
> +static void __iomem *ns_sram_base_addr;
> /*
> * The common v7_exit_coherency_flush API could not be used because of the
> * Erratum 799270 workaround. This macro is the same as the common one (in
> @@ -308,10 +310,26 @@ static const struct of_device_id exynos_dt_mcpm_match[] = {
> {},
> };
>
> +static void exynos_mcpm_setup_entry_point(void)
> +{
> + /*
> + * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
> + * as part of secondary_cpu_start(). Let's redirect it to the
> + * mcpm_entry_point(). This is done during both secondary boot-up as
> + * well as system resume.
> + */
> + __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
> + __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
> + __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
> +}
> +
> +static struct syscore_ops exynos_mcpm_syscore_ops = {
> + .resume = exynos_mcpm_setup_entry_point,
> +};
> +
> static int __init exynos_mcpm_init(void)
> {
> struct device_node *node;
> - void __iomem *ns_sram_base_addr;
> int ret;
>
> node = of_find_matching_node(NULL, exynos_dt_mcpm_match);
> @@ -357,16 +375,9 @@ static int __init exynos_mcpm_init(void)
>
> pr_info("Exynos MCPM support installed\n");
>
> - /*
> - * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
> - * as part of secondary_cpu_start(). Let's redirect it to the
> - * mcpm_entry_point().
> - */
> - __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
> - __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
> - __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
> + exynos_mcpm_setup_entry_point();
>
> - iounmap(ns_sram_base_addr);
> + register_syscore_ops(&exynos_mcpm_syscore_ops);
>
> return ret;
> }
This patch alone is not enough to bring the 8 cores back up post
resume on exynos5420, We need to enable the boot cluster snoops as
well.
Nicolas, if I add code to enable the boot cluster CCI in
mach-exynos/sleep.S, all 8 cores come up. However, if I use
mcpm_loopback as part of the newly added resume function to do the
same, I get a hang on resume.
Is there anything else that I need to take care of while doing this ?
Regards,
Abhilash
> --
> 1.8.3.2
>
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH] ARM: EXYNOS: Restore the entry address setup code post-resume
@ 2014-06-26 12:25 ` Abhilash Kesavan
0 siblings, 0 replies; 130+ messages in thread
From: Abhilash Kesavan @ 2014-06-26 12:25 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On Thu, Jun 26, 2014 at 4:28 PM, Abhilash Kesavan <a.kesavan@samsung.com> wrote:
> Setup the mcpm entry address again on system resume as the
> iRAM contents are lost across an s2r cycle.
>
> Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
> ---
> This has been tested after applying the Exynos5420 S2R support series
> along with Nicolas Pitre's boot cluster CCI enablement patches on Peach
> Pit.
>
> arch/arm/mach-exynos/mcpm-exynos.c | 31 +++++++++++++++++++++----------
> 1 file changed, 21 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/mcpm-exynos.c b/arch/arm/mach-exynos/mcpm-exynos.c
> index 8c610e2..0bf734d 100644
> --- a/arch/arm/mach-exynos/mcpm-exynos.c
> +++ b/arch/arm/mach-exynos/mcpm-exynos.c
> @@ -15,6 +15,7 @@
> #include <linux/delay.h>
> #include <linux/io.h>
> #include <linux/of_address.h>
> +#include <linux/syscore_ops.h>
>
> #include <asm/cputype.h>
> #include <asm/cp15.h>
> @@ -26,6 +27,7 @@
> #define EXYNOS5420_CPUS_PER_CLUSTER 4
> #define EXYNOS5420_NR_CLUSTERS 2
>
> +static void __iomem *ns_sram_base_addr;
> /*
> * The common v7_exit_coherency_flush API could not be used because of the
> * Erratum 799270 workaround. This macro is the same as the common one (in
> @@ -308,10 +310,26 @@ static const struct of_device_id exynos_dt_mcpm_match[] = {
> {},
> };
>
> +static void exynos_mcpm_setup_entry_point(void)
> +{
> + /*
> + * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
> + * as part of secondary_cpu_start(). Let's redirect it to the
> + * mcpm_entry_point(). This is done during both secondary boot-up as
> + * well as system resume.
> + */
> + __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
> + __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
> + __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
> +}
> +
> +static struct syscore_ops exynos_mcpm_syscore_ops = {
> + .resume = exynos_mcpm_setup_entry_point,
> +};
> +
> static int __init exynos_mcpm_init(void)
> {
> struct device_node *node;
> - void __iomem *ns_sram_base_addr;
> int ret;
>
> node = of_find_matching_node(NULL, exynos_dt_mcpm_match);
> @@ -357,16 +375,9 @@ static int __init exynos_mcpm_init(void)
>
> pr_info("Exynos MCPM support installed\n");
>
> - /*
> - * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
> - * as part of secondary_cpu_start(). Let's redirect it to the
> - * mcpm_entry_point().
> - */
> - __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
> - __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
> - __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
> + exynos_mcpm_setup_entry_point();
>
> - iounmap(ns_sram_base_addr);
> + register_syscore_ops(&exynos_mcpm_syscore_ops);
>
> return ret;
> }
This patch alone is not enough to bring the 8 cores back up post
resume on exynos5420, We need to enable the boot cluster snoops as
well.
Nicolas, if I add code to enable the boot cluster CCI in
mach-exynos/sleep.S, all 8 cores come up. However, if I use
mcpm_loopback as part of the newly added resume function to do the
same, I get a hang on resume.
Is there anything else that I need to take care of while doing this ?
Regards,
Abhilash
> --
> 1.8.3.2
>
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: [PATCH] ARM: EXYNOS: Restore the entry address setup code post-resume
2014-06-26 12:25 ` Abhilash Kesavan
@ 2014-06-26 14:35 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 130+ messages in thread
From: Lorenzo Pieralisi @ 2014-06-26 14:35 UTC (permalink / raw)
To: Abhilash Kesavan
Cc: linux-samsung-soc, linux-arm-kernel, Kukjin Kim, Nicolas Pitre,
Andrew Bresticker, Abhilash Kesavan, Douglas Anderson
On Thu, Jun 26, 2014 at 01:25:30PM +0100, Abhilash Kesavan wrote:
> Hi,
>
> On Thu, Jun 26, 2014 at 4:28 PM, Abhilash Kesavan <a.kesavan@samsung.com> wrote:
> > Setup the mcpm entry address again on system resume as the
> > iRAM contents are lost across an s2r cycle.
> >
> > Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
> > ---
> > This has been tested after applying the Exynos5420 S2R support series
> > along with Nicolas Pitre's boot cluster CCI enablement patches on Peach
> > Pit.
> >
> > arch/arm/mach-exynos/mcpm-exynos.c | 31 +++++++++++++++++++++----------
> > 1 file changed, 21 insertions(+), 10 deletions(-)
> >
> > diff --git a/arch/arm/mach-exynos/mcpm-exynos.c b/arch/arm/mach-exynos/mcpm-exynos.c
> > index 8c610e2..0bf734d 100644
> > --- a/arch/arm/mach-exynos/mcpm-exynos.c
> > +++ b/arch/arm/mach-exynos/mcpm-exynos.c
> > @@ -15,6 +15,7 @@
> > #include <linux/delay.h>
> > #include <linux/io.h>
> > #include <linux/of_address.h>
> > +#include <linux/syscore_ops.h>
> >
> > #include <asm/cputype.h>
> > #include <asm/cp15.h>
> > @@ -26,6 +27,7 @@
> > #define EXYNOS5420_CPUS_PER_CLUSTER 4
> > #define EXYNOS5420_NR_CLUSTERS 2
> >
> > +static void __iomem *ns_sram_base_addr;
> > /*
> > * The common v7_exit_coherency_flush API could not be used because of the
> > * Erratum 799270 workaround. This macro is the same as the common one (in
> > @@ -308,10 +310,26 @@ static const struct of_device_id exynos_dt_mcpm_match[] = {
> > {},
> > };
> >
> > +static void exynos_mcpm_setup_entry_point(void)
> > +{
> > + /*
> > + * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
> > + * as part of secondary_cpu_start(). Let's redirect it to the
> > + * mcpm_entry_point(). This is done during both secondary boot-up as
> > + * well as system resume.
> > + */
> > + __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
> > + __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
> > + __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
> > +}
> > +
> > +static struct syscore_ops exynos_mcpm_syscore_ops = {
> > + .resume = exynos_mcpm_setup_entry_point,
> > +};
> > +
> > static int __init exynos_mcpm_init(void)
> > {
> > struct device_node *node;
> > - void __iomem *ns_sram_base_addr;
> > int ret;
> >
> > node = of_find_matching_node(NULL, exynos_dt_mcpm_match);
> > @@ -357,16 +375,9 @@ static int __init exynos_mcpm_init(void)
> >
> > pr_info("Exynos MCPM support installed\n");
> >
> > - /*
> > - * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
> > - * as part of secondary_cpu_start(). Let's redirect it to the
> > - * mcpm_entry_point().
> > - */
> > - __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
> > - __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
> > - __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
> > + exynos_mcpm_setup_entry_point();
> >
> > - iounmap(ns_sram_base_addr);
> > + register_syscore_ops(&exynos_mcpm_syscore_ops);
> >
> > return ret;
> > }
>
> This patch alone is not enough to bring the 8 cores back up post
> resume on exynos5420, We need to enable the boot cluster snoops as
> well.
>
> Nicolas, if I add code to enable the boot cluster CCI in
> mach-exynos/sleep.S, all 8 cores come up. However, if I use
> mcpm_loopback as part of the newly added resume function to do the
> same, I get a hang on resume.
> Is there anything else that I need to take care of while doing this ?
Why do not you use MCPM to suspend the CPU for S2R ? Put it differently,
plug the MCPM suspend call in the suspend ops, it should work, right ?
I think you should chuck the MCPM entry point in the register used for
jumping back to the kernel when resuming to the kernel, then by restoring
RAM code through syscore_ops you ensure you can bring secondaries
back up again (done by suspend core), if I understand how firmware
behaves.
I do not see why you need the MCPM loopback interface for that.
Lorenzo
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH] ARM: EXYNOS: Restore the entry address setup code post-resume
@ 2014-06-26 14:35 ` Lorenzo Pieralisi
0 siblings, 0 replies; 130+ messages in thread
From: Lorenzo Pieralisi @ 2014-06-26 14:35 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Jun 26, 2014 at 01:25:30PM +0100, Abhilash Kesavan wrote:
> Hi,
>
> On Thu, Jun 26, 2014 at 4:28 PM, Abhilash Kesavan <a.kesavan@samsung.com> wrote:
> > Setup the mcpm entry address again on system resume as the
> > iRAM contents are lost across an s2r cycle.
> >
> > Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
> > ---
> > This has been tested after applying the Exynos5420 S2R support series
> > along with Nicolas Pitre's boot cluster CCI enablement patches on Peach
> > Pit.
> >
> > arch/arm/mach-exynos/mcpm-exynos.c | 31 +++++++++++++++++++++----------
> > 1 file changed, 21 insertions(+), 10 deletions(-)
> >
> > diff --git a/arch/arm/mach-exynos/mcpm-exynos.c b/arch/arm/mach-exynos/mcpm-exynos.c
> > index 8c610e2..0bf734d 100644
> > --- a/arch/arm/mach-exynos/mcpm-exynos.c
> > +++ b/arch/arm/mach-exynos/mcpm-exynos.c
> > @@ -15,6 +15,7 @@
> > #include <linux/delay.h>
> > #include <linux/io.h>
> > #include <linux/of_address.h>
> > +#include <linux/syscore_ops.h>
> >
> > #include <asm/cputype.h>
> > #include <asm/cp15.h>
> > @@ -26,6 +27,7 @@
> > #define EXYNOS5420_CPUS_PER_CLUSTER 4
> > #define EXYNOS5420_NR_CLUSTERS 2
> >
> > +static void __iomem *ns_sram_base_addr;
> > /*
> > * The common v7_exit_coherency_flush API could not be used because of the
> > * Erratum 799270 workaround. This macro is the same as the common one (in
> > @@ -308,10 +310,26 @@ static const struct of_device_id exynos_dt_mcpm_match[] = {
> > {},
> > };
> >
> > +static void exynos_mcpm_setup_entry_point(void)
> > +{
> > + /*
> > + * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
> > + * as part of secondary_cpu_start(). Let's redirect it to the
> > + * mcpm_entry_point(). This is done during both secondary boot-up as
> > + * well as system resume.
> > + */
> > + __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
> > + __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
> > + __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
> > +}
> > +
> > +static struct syscore_ops exynos_mcpm_syscore_ops = {
> > + .resume = exynos_mcpm_setup_entry_point,
> > +};
> > +
> > static int __init exynos_mcpm_init(void)
> > {
> > struct device_node *node;
> > - void __iomem *ns_sram_base_addr;
> > int ret;
> >
> > node = of_find_matching_node(NULL, exynos_dt_mcpm_match);
> > @@ -357,16 +375,9 @@ static int __init exynos_mcpm_init(void)
> >
> > pr_info("Exynos MCPM support installed\n");
> >
> > - /*
> > - * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
> > - * as part of secondary_cpu_start(). Let's redirect it to the
> > - * mcpm_entry_point().
> > - */
> > - __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
> > - __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
> > - __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
> > + exynos_mcpm_setup_entry_point();
> >
> > - iounmap(ns_sram_base_addr);
> > + register_syscore_ops(&exynos_mcpm_syscore_ops);
> >
> > return ret;
> > }
>
> This patch alone is not enough to bring the 8 cores back up post
> resume on exynos5420, We need to enable the boot cluster snoops as
> well.
>
> Nicolas, if I add code to enable the boot cluster CCI in
> mach-exynos/sleep.S, all 8 cores come up. However, if I use
> mcpm_loopback as part of the newly added resume function to do the
> same, I get a hang on resume.
> Is there anything else that I need to take care of while doing this ?
Why do not you use MCPM to suspend the CPU for S2R ? Put it differently,
plug the MCPM suspend call in the suspend ops, it should work, right ?
I think you should chuck the MCPM entry point in the register used for
jumping back to the kernel when resuming to the kernel, then by restoring
RAM code through syscore_ops you ensure you can bring secondaries
back up again (done by suspend core), if I understand how firmware
behaves.
I do not see why you need the MCPM loopback interface for that.
Lorenzo
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: [PATCH] ARM: EXYNOS: Restore the entry address setup code post-resume
2014-06-26 12:25 ` Abhilash Kesavan
@ 2014-06-26 14:53 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 130+ messages in thread
From: Lorenzo Pieralisi @ 2014-06-26 14:53 UTC (permalink / raw)
To: Abhilash Kesavan
Cc: linux-samsung-soc, linux-arm-kernel, Kukjin Kim, Nicolas Pitre,
Andrew Bresticker, Abhilash Kesavan, Douglas Anderson
On Thu, Jun 26, 2014 at 01:25:30PM +0100, Abhilash Kesavan wrote:
> Hi,
>
> On Thu, Jun 26, 2014 at 4:28 PM, Abhilash Kesavan <a.kesavan@samsung.com> wrote:
> > Setup the mcpm entry address again on system resume as the
> > iRAM contents are lost across an s2r cycle.
> >
> > Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
> > ---
> > This has been tested after applying the Exynos5420 S2R support series
> > along with Nicolas Pitre's boot cluster CCI enablement patches on Peach
> > Pit.
> >
> > arch/arm/mach-exynos/mcpm-exynos.c | 31 +++++++++++++++++++++----------
> > 1 file changed, 21 insertions(+), 10 deletions(-)
> >
> > diff --git a/arch/arm/mach-exynos/mcpm-exynos.c b/arch/arm/mach-exynos/mcpm-exynos.c
> > index 8c610e2..0bf734d 100644
> > --- a/arch/arm/mach-exynos/mcpm-exynos.c
> > +++ b/arch/arm/mach-exynos/mcpm-exynos.c
> > @@ -15,6 +15,7 @@
> > #include <linux/delay.h>
> > #include <linux/io.h>
> > #include <linux/of_address.h>
> > +#include <linux/syscore_ops.h>
> >
> > #include <asm/cputype.h>
> > #include <asm/cp15.h>
> > @@ -26,6 +27,7 @@
> > #define EXYNOS5420_CPUS_PER_CLUSTER 4
> > #define EXYNOS5420_NR_CLUSTERS 2
> >
> > +static void __iomem *ns_sram_base_addr;
> > /*
> > * The common v7_exit_coherency_flush API could not be used because of the
> > * Erratum 799270 workaround. This macro is the same as the common one (in
> > @@ -308,10 +310,26 @@ static const struct of_device_id exynos_dt_mcpm_match[] = {
> > {},
> > };
> >
> > +static void exynos_mcpm_setup_entry_point(void)
> > +{
> > + /*
> > + * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
> > + * as part of secondary_cpu_start(). Let's redirect it to the
> > + * mcpm_entry_point(). This is done during both secondary boot-up as
> > + * well as system resume.
> > + */
> > + __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
> > + __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
> > + __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
> > +}
> > +
> > +static struct syscore_ops exynos_mcpm_syscore_ops = {
> > + .resume = exynos_mcpm_setup_entry_point,
> > +};
> > +
> > static int __init exynos_mcpm_init(void)
> > {
> > struct device_node *node;
> > - void __iomem *ns_sram_base_addr;
> > int ret;
> >
> > node = of_find_matching_node(NULL, exynos_dt_mcpm_match);
> > @@ -357,16 +375,9 @@ static int __init exynos_mcpm_init(void)
> >
> > pr_info("Exynos MCPM support installed\n");
> >
> > - /*
> > - * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
> > - * as part of secondary_cpu_start(). Let's redirect it to the
> > - * mcpm_entry_point().
> > - */
> > - __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
> > - __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
> > - __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
> > + exynos_mcpm_setup_entry_point();
> >
> > - iounmap(ns_sram_base_addr);
> > + register_syscore_ops(&exynos_mcpm_syscore_ops);
> >
> > return ret;
> > }
>
> This patch alone is not enough to bring the 8 cores back up post
> resume on exynos5420, We need to enable the boot cluster snoops as
> well.
>
> Nicolas, if I add code to enable the boot cluster CCI in
> mach-exynos/sleep.S, all 8 cores come up. However, if I use
> mcpm_loopback as part of the newly added resume function to do the
> same, I get a hang on resume.
BTW mcpm_loopback is __init, and that's correct, so on resume if you
call it kernel goes boom.
Lorenzo
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH] ARM: EXYNOS: Restore the entry address setup code post-resume
@ 2014-06-26 14:53 ` Lorenzo Pieralisi
0 siblings, 0 replies; 130+ messages in thread
From: Lorenzo Pieralisi @ 2014-06-26 14:53 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Jun 26, 2014 at 01:25:30PM +0100, Abhilash Kesavan wrote:
> Hi,
>
> On Thu, Jun 26, 2014 at 4:28 PM, Abhilash Kesavan <a.kesavan@samsung.com> wrote:
> > Setup the mcpm entry address again on system resume as the
> > iRAM contents are lost across an s2r cycle.
> >
> > Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
> > ---
> > This has been tested after applying the Exynos5420 S2R support series
> > along with Nicolas Pitre's boot cluster CCI enablement patches on Peach
> > Pit.
> >
> > arch/arm/mach-exynos/mcpm-exynos.c | 31 +++++++++++++++++++++----------
> > 1 file changed, 21 insertions(+), 10 deletions(-)
> >
> > diff --git a/arch/arm/mach-exynos/mcpm-exynos.c b/arch/arm/mach-exynos/mcpm-exynos.c
> > index 8c610e2..0bf734d 100644
> > --- a/arch/arm/mach-exynos/mcpm-exynos.c
> > +++ b/arch/arm/mach-exynos/mcpm-exynos.c
> > @@ -15,6 +15,7 @@
> > #include <linux/delay.h>
> > #include <linux/io.h>
> > #include <linux/of_address.h>
> > +#include <linux/syscore_ops.h>
> >
> > #include <asm/cputype.h>
> > #include <asm/cp15.h>
> > @@ -26,6 +27,7 @@
> > #define EXYNOS5420_CPUS_PER_CLUSTER 4
> > #define EXYNOS5420_NR_CLUSTERS 2
> >
> > +static void __iomem *ns_sram_base_addr;
> > /*
> > * The common v7_exit_coherency_flush API could not be used because of the
> > * Erratum 799270 workaround. This macro is the same as the common one (in
> > @@ -308,10 +310,26 @@ static const struct of_device_id exynos_dt_mcpm_match[] = {
> > {},
> > };
> >
> > +static void exynos_mcpm_setup_entry_point(void)
> > +{
> > + /*
> > + * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
> > + * as part of secondary_cpu_start(). Let's redirect it to the
> > + * mcpm_entry_point(). This is done during both secondary boot-up as
> > + * well as system resume.
> > + */
> > + __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
> > + __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
> > + __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
> > +}
> > +
> > +static struct syscore_ops exynos_mcpm_syscore_ops = {
> > + .resume = exynos_mcpm_setup_entry_point,
> > +};
> > +
> > static int __init exynos_mcpm_init(void)
> > {
> > struct device_node *node;
> > - void __iomem *ns_sram_base_addr;
> > int ret;
> >
> > node = of_find_matching_node(NULL, exynos_dt_mcpm_match);
> > @@ -357,16 +375,9 @@ static int __init exynos_mcpm_init(void)
> >
> > pr_info("Exynos MCPM support installed\n");
> >
> > - /*
> > - * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
> > - * as part of secondary_cpu_start(). Let's redirect it to the
> > - * mcpm_entry_point().
> > - */
> > - __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
> > - __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
> > - __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
> > + exynos_mcpm_setup_entry_point();
> >
> > - iounmap(ns_sram_base_addr);
> > + register_syscore_ops(&exynos_mcpm_syscore_ops);
> >
> > return ret;
> > }
>
> This patch alone is not enough to bring the 8 cores back up post
> resume on exynos5420, We need to enable the boot cluster snoops as
> well.
>
> Nicolas, if I add code to enable the boot cluster CCI in
> mach-exynos/sleep.S, all 8 cores come up. However, if I use
> mcpm_loopback as part of the newly added resume function to do the
> same, I get a hang on resume.
BTW mcpm_loopback is __init, and that's correct, so on resume if you
call it kernel goes boom.
Lorenzo
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: [PATCH] ARM: EXYNOS: Restore the entry address setup code post-resume
2014-06-26 12:25 ` Abhilash Kesavan
@ 2014-06-26 20:06 ` Nicolas Pitre
-1 siblings, 0 replies; 130+ messages in thread
From: Nicolas Pitre @ 2014-06-26 20:06 UTC (permalink / raw)
To: Abhilash Kesavan
Cc: linux-samsung-soc, linux-arm-kernel, Kukjin Kim,
Andrew Bresticker, Douglas Anderson, Abhilash Kesavan
On Thu, 26 Jun 2014, Abhilash Kesavan wrote:
> Hi,
>
> On Thu, Jun 26, 2014 at 4:28 PM, Abhilash Kesavan <a.kesavan@samsung.com> wrote:
> > Setup the mcpm entry address again on system resume as the
> > iRAM contents are lost across an s2r cycle.
> >
> > Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
> > ---
> > This has been tested after applying the Exynos5420 S2R support series
> > along with Nicolas Pitre's boot cluster CCI enablement patches on Peach
> > Pit.
> >
> > arch/arm/mach-exynos/mcpm-exynos.c | 31 +++++++++++++++++++++----------
> > 1 file changed, 21 insertions(+), 10 deletions(-)
> >
> > diff --git a/arch/arm/mach-exynos/mcpm-exynos.c b/arch/arm/mach-exynos/mcpm-exynos.c
> > index 8c610e2..0bf734d 100644
> > --- a/arch/arm/mach-exynos/mcpm-exynos.c
> > +++ b/arch/arm/mach-exynos/mcpm-exynos.c
> > @@ -15,6 +15,7 @@
> > #include <linux/delay.h>
> > #include <linux/io.h>
> > #include <linux/of_address.h>
> > +#include <linux/syscore_ops.h>
> >
> > #include <asm/cputype.h>
> > #include <asm/cp15.h>
> > @@ -26,6 +27,7 @@
> > #define EXYNOS5420_CPUS_PER_CLUSTER 4
> > #define EXYNOS5420_NR_CLUSTERS 2
> >
> > +static void __iomem *ns_sram_base_addr;
> > /*
> > * The common v7_exit_coherency_flush API could not be used because of the
> > * Erratum 799270 workaround. This macro is the same as the common one (in
> > @@ -308,10 +310,26 @@ static const struct of_device_id exynos_dt_mcpm_match[] = {
> > {},
> > };
> >
> > +static void exynos_mcpm_setup_entry_point(void)
> > +{
> > + /*
> > + * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
> > + * as part of secondary_cpu_start(). Let's redirect it to the
> > + * mcpm_entry_point(). This is done during both secondary boot-up as
> > + * well as system resume.
> > + */
> > + __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
> > + __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
> > + __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
> > +}
> > +
> > +static struct syscore_ops exynos_mcpm_syscore_ops = {
> > + .resume = exynos_mcpm_setup_entry_point,
> > +};
> > +
> > static int __init exynos_mcpm_init(void)
> > {
> > struct device_node *node;
> > - void __iomem *ns_sram_base_addr;
> > int ret;
> >
> > node = of_find_matching_node(NULL, exynos_dt_mcpm_match);
> > @@ -357,16 +375,9 @@ static int __init exynos_mcpm_init(void)
> >
> > pr_info("Exynos MCPM support installed\n");
> >
> > - /*
> > - * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
> > - * as part of secondary_cpu_start(). Let's redirect it to the
> > - * mcpm_entry_point().
> > - */
> > - __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
> > - __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
> > - __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
> > + exynos_mcpm_setup_entry_point();
> >
> > - iounmap(ns_sram_base_addr);
> > + register_syscore_ops(&exynos_mcpm_syscore_ops);
> >
> > return ret;
> > }
>
> This patch alone is not enough to bring the 8 cores back up post
> resume on exynos5420, We need to enable the boot cluster snoops as
> well.
>
> Nicolas, if I add code to enable the boot cluster CCI in
> mach-exynos/sleep.S, all 8 cores come up. However, if I use
> mcpm_loopback as part of the newly added resume function to do the
> same, I get a hang on resume.
> Is there anything else that I need to take care of while doing this ?
No no no.
Forget about the MCPM loopback -- that's for boot time setup of the
booting cluster nothing else.
The snoops are enabled in a ***race free way*** by the low-level MCPM
code. But of course you must call it upon resume. Nothing else than
MCPM should ever play with the snoops enable/disable. Certainly not
mach-exynos/sleep.S.
You must tell your firmware to resume execution after suspend at
mcpm_entry_point. Before suspending, you tell MCPM where it should
branch to after it is done with its resuming business by calling
mcpm_set_entry_vector(), passing the address for exynos_cpu_resume for
example.
And of course the CPU shutdown during idle has to go through MCPM too.
When resumed, you also have to call mcpm_cpu_powered_up().
See how it is done in cpuidle-big_little.c for example.
Nicolas
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH] ARM: EXYNOS: Restore the entry address setup code post-resume
@ 2014-06-26 20:06 ` Nicolas Pitre
0 siblings, 0 replies; 130+ messages in thread
From: Nicolas Pitre @ 2014-06-26 20:06 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, 26 Jun 2014, Abhilash Kesavan wrote:
> Hi,
>
> On Thu, Jun 26, 2014 at 4:28 PM, Abhilash Kesavan <a.kesavan@samsung.com> wrote:
> > Setup the mcpm entry address again on system resume as the
> > iRAM contents are lost across an s2r cycle.
> >
> > Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
> > ---
> > This has been tested after applying the Exynos5420 S2R support series
> > along with Nicolas Pitre's boot cluster CCI enablement patches on Peach
> > Pit.
> >
> > arch/arm/mach-exynos/mcpm-exynos.c | 31 +++++++++++++++++++++----------
> > 1 file changed, 21 insertions(+), 10 deletions(-)
> >
> > diff --git a/arch/arm/mach-exynos/mcpm-exynos.c b/arch/arm/mach-exynos/mcpm-exynos.c
> > index 8c610e2..0bf734d 100644
> > --- a/arch/arm/mach-exynos/mcpm-exynos.c
> > +++ b/arch/arm/mach-exynos/mcpm-exynos.c
> > @@ -15,6 +15,7 @@
> > #include <linux/delay.h>
> > #include <linux/io.h>
> > #include <linux/of_address.h>
> > +#include <linux/syscore_ops.h>
> >
> > #include <asm/cputype.h>
> > #include <asm/cp15.h>
> > @@ -26,6 +27,7 @@
> > #define EXYNOS5420_CPUS_PER_CLUSTER 4
> > #define EXYNOS5420_NR_CLUSTERS 2
> >
> > +static void __iomem *ns_sram_base_addr;
> > /*
> > * The common v7_exit_coherency_flush API could not be used because of the
> > * Erratum 799270 workaround. This macro is the same as the common one (in
> > @@ -308,10 +310,26 @@ static const struct of_device_id exynos_dt_mcpm_match[] = {
> > {},
> > };
> >
> > +static void exynos_mcpm_setup_entry_point(void)
> > +{
> > + /*
> > + * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
> > + * as part of secondary_cpu_start(). Let's redirect it to the
> > + * mcpm_entry_point(). This is done during both secondary boot-up as
> > + * well as system resume.
> > + */
> > + __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
> > + __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
> > + __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
> > +}
> > +
> > +static struct syscore_ops exynos_mcpm_syscore_ops = {
> > + .resume = exynos_mcpm_setup_entry_point,
> > +};
> > +
> > static int __init exynos_mcpm_init(void)
> > {
> > struct device_node *node;
> > - void __iomem *ns_sram_base_addr;
> > int ret;
> >
> > node = of_find_matching_node(NULL, exynos_dt_mcpm_match);
> > @@ -357,16 +375,9 @@ static int __init exynos_mcpm_init(void)
> >
> > pr_info("Exynos MCPM support installed\n");
> >
> > - /*
> > - * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
> > - * as part of secondary_cpu_start(). Let's redirect it to the
> > - * mcpm_entry_point().
> > - */
> > - __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
> > - __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
> > - __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
> > + exynos_mcpm_setup_entry_point();
> >
> > - iounmap(ns_sram_base_addr);
> > + register_syscore_ops(&exynos_mcpm_syscore_ops);
> >
> > return ret;
> > }
>
> This patch alone is not enough to bring the 8 cores back up post
> resume on exynos5420, We need to enable the boot cluster snoops as
> well.
>
> Nicolas, if I add code to enable the boot cluster CCI in
> mach-exynos/sleep.S, all 8 cores come up. However, if I use
> mcpm_loopback as part of the newly added resume function to do the
> same, I get a hang on resume.
> Is there anything else that I need to take care of while doing this ?
No no no.
Forget about the MCPM loopback -- that's for boot time setup of the
booting cluster nothing else.
The snoops are enabled in a ***race free way*** by the low-level MCPM
code. But of course you must call it upon resume. Nothing else than
MCPM should ever play with the snoops enable/disable. Certainly not
mach-exynos/sleep.S.
You must tell your firmware to resume execution after suspend at
mcpm_entry_point. Before suspending, you tell MCPM where it should
branch to after it is done with its resuming business by calling
mcpm_set_entry_vector(), passing the address for exynos_cpu_resume for
example.
And of course the CPU shutdown during idle has to go through MCPM too.
When resumed, you also have to call mcpm_cpu_powered_up().
See how it is done in cpuidle-big_little.c for example.
Nicolas
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: [PATCH] ARM: EXYNOS: Restore the entry address setup code post-resume
2014-06-26 20:06 ` Nicolas Pitre
@ 2014-06-27 1:49 ` Abhilash Kesavan
-1 siblings, 0 replies; 130+ messages in thread
From: Abhilash Kesavan @ 2014-06-27 1:49 UTC (permalink / raw)
To: Nicolas Pitre
Cc: linux-samsung-soc, linux-arm-kernel, Kukjin Kim,
Andrew Bresticker, Douglas Anderson
Hi,
On Fri, Jun 27, 2014 at 1:36 AM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> On Thu, 26 Jun 2014, Abhilash Kesavan wrote:
>
>> Hi,
>>
>> On Thu, Jun 26, 2014 at 4:28 PM, Abhilash Kesavan <a.kesavan@samsung.com> wrote:
>> > Setup the mcpm entry address again on system resume as the
>> > iRAM contents are lost across an s2r cycle.
>> >
>> > Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
>> > ---
>> > This has been tested after applying the Exynos5420 S2R support series
>> > along with Nicolas Pitre's boot cluster CCI enablement patches on Peach
>> > Pit.
>> >
>> > arch/arm/mach-exynos/mcpm-exynos.c | 31 +++++++++++++++++++++----------
>> > 1 file changed, 21 insertions(+), 10 deletions(-)
>> >
>> > diff --git a/arch/arm/mach-exynos/mcpm-exynos.c b/arch/arm/mach-exynos/mcpm-exynos.c
>> > index 8c610e2..0bf734d 100644
>> > --- a/arch/arm/mach-exynos/mcpm-exynos.c
>> > +++ b/arch/arm/mach-exynos/mcpm-exynos.c
>> > @@ -15,6 +15,7 @@
>> > #include <linux/delay.h>
>> > #include <linux/io.h>
>> > #include <linux/of_address.h>
>> > +#include <linux/syscore_ops.h>
>> >
>> > #include <asm/cputype.h>
>> > #include <asm/cp15.h>
>> > @@ -26,6 +27,7 @@
>> > #define EXYNOS5420_CPUS_PER_CLUSTER 4
>> > #define EXYNOS5420_NR_CLUSTERS 2
>> >
>> > +static void __iomem *ns_sram_base_addr;
>> > /*
>> > * The common v7_exit_coherency_flush API could not be used because of the
>> > * Erratum 799270 workaround. This macro is the same as the common one (in
>> > @@ -308,10 +310,26 @@ static const struct of_device_id exynos_dt_mcpm_match[] = {
>> > {},
>> > };
>> >
>> > +static void exynos_mcpm_setup_entry_point(void)
>> > +{
>> > + /*
>> > + * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
>> > + * as part of secondary_cpu_start(). Let's redirect it to the
>> > + * mcpm_entry_point(). This is done during both secondary boot-up as
>> > + * well as system resume.
>> > + */
>> > + __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
>> > + __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
>> > + __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
>> > +}
>> > +
>> > +static struct syscore_ops exynos_mcpm_syscore_ops = {
>> > + .resume = exynos_mcpm_setup_entry_point,
>> > +};
>> > +
>> > static int __init exynos_mcpm_init(void)
>> > {
>> > struct device_node *node;
>> > - void __iomem *ns_sram_base_addr;
>> > int ret;
>> >
>> > node = of_find_matching_node(NULL, exynos_dt_mcpm_match);
>> > @@ -357,16 +375,9 @@ static int __init exynos_mcpm_init(void)
>> >
>> > pr_info("Exynos MCPM support installed\n");
>> >
>> > - /*
>> > - * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
>> > - * as part of secondary_cpu_start(). Let's redirect it to the
>> > - * mcpm_entry_point().
>> > - */
>> > - __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
>> > - __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
>> > - __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
>> > + exynos_mcpm_setup_entry_point();
>> >
>> > - iounmap(ns_sram_base_addr);
>> > + register_syscore_ops(&exynos_mcpm_syscore_ops);
>> >
>> > return ret;
>> > }
>>
>> This patch alone is not enough to bring the 8 cores back up post
>> resume on exynos5420, We need to enable the boot cluster snoops as
>> well.
>>
>> Nicolas, if I add code to enable the boot cluster CCI in
>> mach-exynos/sleep.S, all 8 cores come up. However, if I use
>> mcpm_loopback as part of the newly added resume function to do the
>> same, I get a hang on resume.
>> Is there anything else that I need to take care of while doing this ?
>
> No no no.
>
> Forget about the MCPM loopback -- that's for boot time setup of the
> booting cluster nothing else.
Ok, I thought this is to be used at resume too.
>
> The snoops are enabled in a ***race free way*** by the low-level MCPM
> code. But of course you must call it upon resume. Nothing else than
> MCPM should ever play with the snoops enable/disable. Certainly not
> mach-exynos/sleep.S.
The sleep.S change was something I tried to isolate where I was going
wrong. Of course, in this case my basic premise of using mcpm_loopback
to enable snoops itself was flawed.
>
> You must tell your firmware to resume execution after suspend at
> mcpm_entry_point. Before suspending, you tell MCPM where it should
> branch to after it is done with its resuming business by calling
> mcpm_set_entry_vector(), passing the address for exynos_cpu_resume for
> example.
Thanks for the explantion, will re-work the patch.
>
> And of course the CPU shutdown during idle has to go through MCPM too.
>
> When resumed, you also have to call mcpm_cpu_powered_up().
>
> See how it is done in cpuidle-big_little.c for example
Will check the cpuidle big.LITTLE driver also.
Regards,
Abhilash
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH] ARM: EXYNOS: Restore the entry address setup code post-resume
@ 2014-06-27 1:49 ` Abhilash Kesavan
0 siblings, 0 replies; 130+ messages in thread
From: Abhilash Kesavan @ 2014-06-27 1:49 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On Fri, Jun 27, 2014 at 1:36 AM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> On Thu, 26 Jun 2014, Abhilash Kesavan wrote:
>
>> Hi,
>>
>> On Thu, Jun 26, 2014 at 4:28 PM, Abhilash Kesavan <a.kesavan@samsung.com> wrote:
>> > Setup the mcpm entry address again on system resume as the
>> > iRAM contents are lost across an s2r cycle.
>> >
>> > Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
>> > ---
>> > This has been tested after applying the Exynos5420 S2R support series
>> > along with Nicolas Pitre's boot cluster CCI enablement patches on Peach
>> > Pit.
>> >
>> > arch/arm/mach-exynos/mcpm-exynos.c | 31 +++++++++++++++++++++----------
>> > 1 file changed, 21 insertions(+), 10 deletions(-)
>> >
>> > diff --git a/arch/arm/mach-exynos/mcpm-exynos.c b/arch/arm/mach-exynos/mcpm-exynos.c
>> > index 8c610e2..0bf734d 100644
>> > --- a/arch/arm/mach-exynos/mcpm-exynos.c
>> > +++ b/arch/arm/mach-exynos/mcpm-exynos.c
>> > @@ -15,6 +15,7 @@
>> > #include <linux/delay.h>
>> > #include <linux/io.h>
>> > #include <linux/of_address.h>
>> > +#include <linux/syscore_ops.h>
>> >
>> > #include <asm/cputype.h>
>> > #include <asm/cp15.h>
>> > @@ -26,6 +27,7 @@
>> > #define EXYNOS5420_CPUS_PER_CLUSTER 4
>> > #define EXYNOS5420_NR_CLUSTERS 2
>> >
>> > +static void __iomem *ns_sram_base_addr;
>> > /*
>> > * The common v7_exit_coherency_flush API could not be used because of the
>> > * Erratum 799270 workaround. This macro is the same as the common one (in
>> > @@ -308,10 +310,26 @@ static const struct of_device_id exynos_dt_mcpm_match[] = {
>> > {},
>> > };
>> >
>> > +static void exynos_mcpm_setup_entry_point(void)
>> > +{
>> > + /*
>> > + * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
>> > + * as part of secondary_cpu_start(). Let's redirect it to the
>> > + * mcpm_entry_point(). This is done during both secondary boot-up as
>> > + * well as system resume.
>> > + */
>> > + __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
>> > + __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
>> > + __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
>> > +}
>> > +
>> > +static struct syscore_ops exynos_mcpm_syscore_ops = {
>> > + .resume = exynos_mcpm_setup_entry_point,
>> > +};
>> > +
>> > static int __init exynos_mcpm_init(void)
>> > {
>> > struct device_node *node;
>> > - void __iomem *ns_sram_base_addr;
>> > int ret;
>> >
>> > node = of_find_matching_node(NULL, exynos_dt_mcpm_match);
>> > @@ -357,16 +375,9 @@ static int __init exynos_mcpm_init(void)
>> >
>> > pr_info("Exynos MCPM support installed\n");
>> >
>> > - /*
>> > - * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
>> > - * as part of secondary_cpu_start(). Let's redirect it to the
>> > - * mcpm_entry_point().
>> > - */
>> > - __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
>> > - __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
>> > - __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
>> > + exynos_mcpm_setup_entry_point();
>> >
>> > - iounmap(ns_sram_base_addr);
>> > + register_syscore_ops(&exynos_mcpm_syscore_ops);
>> >
>> > return ret;
>> > }
>>
>> This patch alone is not enough to bring the 8 cores back up post
>> resume on exynos5420, We need to enable the boot cluster snoops as
>> well.
>>
>> Nicolas, if I add code to enable the boot cluster CCI in
>> mach-exynos/sleep.S, all 8 cores come up. However, if I use
>> mcpm_loopback as part of the newly added resume function to do the
>> same, I get a hang on resume.
>> Is there anything else that I need to take care of while doing this ?
>
> No no no.
>
> Forget about the MCPM loopback -- that's for boot time setup of the
> booting cluster nothing else.
Ok, I thought this is to be used at resume too.
>
> The snoops are enabled in a ***race free way*** by the low-level MCPM
> code. But of course you must call it upon resume. Nothing else than
> MCPM should ever play with the snoops enable/disable. Certainly not
> mach-exynos/sleep.S.
The sleep.S change was something I tried to isolate where I was going
wrong. Of course, in this case my basic premise of using mcpm_loopback
to enable snoops itself was flawed.
>
> You must tell your firmware to resume execution after suspend at
> mcpm_entry_point. Before suspending, you tell MCPM where it should
> branch to after it is done with its resuming business by calling
> mcpm_set_entry_vector(), passing the address for exynos_cpu_resume for
> example.
Thanks for the explantion, will re-work the patch.
>
> And of course the CPU shutdown during idle has to go through MCPM too.
>
> When resumed, you also have to call mcpm_cpu_powered_up().
>
> See how it is done in cpuidle-big_little.c for example
Will check the cpuidle big.LITTLE driver also.
Regards,
Abhilash
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH v2] ARM: EXYNOS: Use MCPM call-backs to support S2R on Exynos5420
2014-06-26 10:58 ` Abhilash Kesavan
@ 2014-06-30 18:28 ` Abhilash Kesavan
-1 siblings, 0 replies; 130+ messages in thread
From: Abhilash Kesavan @ 2014-06-30 18:28 UTC (permalink / raw)
To: linux-samsung-soc, linux-arm-kernel, kgene.kim, nicolas.pitre,
lorenzo.pieralisi
Cc: abrestic, dianders, kesavan.abhilash
Use the MCPM layer to handle core suspend/resume on Exynos5420.
Also, restore the entry address setup code post-resume.
Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
---
Hi Lorenzo and Nicolas,
I am now using the suspend/powered_up call-backs that were added as part
of Chander's CPUIdle series for Exynos5420. exynos_mcpm_cpu_suspend()
is based on the code in bL cpuidle driver except for a small addition.
This has been tested both on an SMDK5420 and Peach Pit Chromebook on
3.16-rc3.
Here are the dependencies (some of these patches did not apply cleanly):
1) Cleanup patches for mach-exynos
http://comments.gmane.org/gmane.linux.kernel.samsung-soc/33772
2) PMU cleanup and refactoring for using DT
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg671625.html
3) Exynos5420 PMU/S2R Series
http://comments.gmane.org/gmane.linux.kernel.samsung-soc/33898
4) MCPM boot CPU CCI enablement patches
www.spinics.net/lists/linux-samsung-soc/msg32923.html
5) Exynos5420 CPUIdle Series which populates MCPM suspend/powered_up
call-backs.
www.gossamer-threads.com/lists/linux/kernel/1945347
https://patchwork.kernel.org/patch/4357461/
6) Exynos5420 MCPM cluster power down support
http://www.spinics.net/lists/arm-kernel/msg339988.html
7) TPM reset mask patch
http://www.spinics.net/lists/arm-kernel/msg341884.html
arch/arm/mach-exynos/mcpm-exynos.c | 40 ++++++++++++++++++++++++++----------
arch/arm/mach-exynos/pm.c | 38 +++++++++++++++++++++++++++++++---
arch/arm/mach-exynos/regs-pmu.h | 1 +
3 files changed, 65 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-exynos/mcpm-exynos.c b/arch/arm/mach-exynos/mcpm-exynos.c
index 037a05e..dd298f3 100644
--- a/arch/arm/mach-exynos/mcpm-exynos.c
+++ b/arch/arm/mach-exynos/mcpm-exynos.c
@@ -15,6 +15,7 @@
#include <linux/delay.h>
#include <linux/io.h>
#include <linux/of_address.h>
+#include <linux/syscore_ops.h>
#include <asm/cputype.h>
#include <asm/cp15.h>
@@ -30,6 +31,8 @@
#define EXYNOS5420_USE_ARM_CORE_DOWN_STATE BIT(29)
#define EXYNOS5420_USE_L2_COMMON_UP_STATE BIT(30)
+static void __iomem *ns_sram_base_addr;
+
/*
* The common v7_exit_coherency_flush API could not be used because of the
* Erratum 799270 workaround. This macro is the same as the common one (in
@@ -150,7 +153,13 @@ static void exynos_power_down(void)
BUG_ON(__mcpm_cluster_state(cluster) != CLUSTER_UP);
cpu_use_count[cpu][cluster]--;
if (cpu_use_count[cpu][cluster] == 0) {
- exynos_cpu_power_down(cpunr);
+ /*
+ * Bypass power down for CPU0 during suspend. This is being
+ * taken care by the SYS_PWR_CFG bit in CORE0_SYS_PWR_REG.
+ */
+ if ((cpunr != 0) ||
+ (__raw_readl(pmu_base_addr + S5P_INFORM1) != S5P_CHECK_SLEEP))
+ exynos_cpu_power_down(cpunr);
if (exynos_cluster_unused(cluster)) {
exynos_cluster_power_down(cluster);
@@ -319,10 +328,26 @@ static const struct of_device_id exynos_dt_mcpm_match[] = {
{},
};
+static void exynos_mcpm_setup_entry_point(void)
+{
+ /*
+ * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
+ * as part of secondary_cpu_start(). Let's redirect it to the
+ * mcpm_entry_point(). This is done during both secondary boot-up as
+ * well as system resume.
+ */
+ __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
+ __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
+ __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
+}
+
+static struct syscore_ops exynos_mcpm_syscore_ops = {
+ .resume = exynos_mcpm_setup_entry_point,
+};
+
static int __init exynos_mcpm_init(void)
{
struct device_node *node;
- void __iomem *ns_sram_base_addr;
unsigned int value, i;
int ret;
@@ -389,16 +414,9 @@ static int __init exynos_mcpm_init(void)
__raw_writel(value, EXYNOS_COMMON_OPTION(i));
}
- /*
- * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
- * as part of secondary_cpu_start(). Let's redirect it to the
- * mcpm_entry_point().
- */
- __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
- __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
- __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
+ exynos_mcpm_setup_entry_point();
- iounmap(ns_sram_base_addr);
+ register_syscore_ops(&exynos_mcpm_syscore_ops);
return ret;
}
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index bf8564a..a4f4292 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -24,6 +24,7 @@
#include <asm/cacheflush.h>
#include <asm/hardware/cache-l2x0.h>
+#include <asm/mcpm.h>
#include <asm/smp_scu.h>
#include <asm/suspend.h>
@@ -191,7 +192,6 @@ int exynos_cluster_power_state(int cluster)
pmu_base_addr + S5P_INFORM1))
#define S5P_CHECK_AFTR 0xFCBA0D10
-#define S5P_CHECK_SLEEP 0x00000BAD
/* Ext-GIC nIRQ/nFIQ is the only wakeup source in AFTR */
static void exynos_set_wakeupmask(long mask)
@@ -318,7 +318,10 @@ static void exynos_pm_prepare(void)
/* ensure at least INFORM0 has the resume address */
- pmu_raw_writel(virt_to_phys(exynos_cpu_resume), S5P_INFORM0);
+ if (soc_is_exynos5420())
+ pmu_raw_writel(virt_to_phys(mcpm_entry_point), S5P_INFORM0);
+ else
+ pmu_raw_writel(virt_to_phys(exynos_cpu_resume), S5P_INFORM0);
if (soc_is_exynos5420()) {
tmp = __raw_readl(pmu_base_addr + EXYNOS5_ARM_L2_OPTION);
@@ -490,6 +493,28 @@ static struct syscore_ops exynos_pm_syscore_ops = {
.resume = exynos_pm_resume,
};
+static int notrace exynos_mcpm_cpu_suspend(unsigned long arg)
+{
+ /* MCPM works with HW CPU identifiers */
+ unsigned int mpidr = read_cpuid_mpidr();
+ unsigned int cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+ unsigned int cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+
+ __raw_writel(0x0, sysram_base_addr + EXYNOS5420_CPU_STATE);
+
+ mcpm_set_entry_vector(cpu, cluster, exynos_cpu_resume);
+
+ /*
+ * Residency value passed to mcpm_cpu_suspend back-end
+ * has to be given clear semantics. Set to 0 as a
+ * temporary value.
+ */
+ mcpm_cpu_suspend(0);
+
+ /* return value != 0 means failure */
+ return 1;
+}
+
/*
* Suspend Ops
*/
@@ -517,10 +542,17 @@ static int exynos_suspend_enter(suspend_state_t state)
flush_cache_all();
s3c_pm_check_store();
- ret = cpu_suspend(0, exynos_cpu_suspend);
+ /* Use the MCPM layer to suspend 5420 which is a multi-cluster SoC */
+ if (soc_is_exynos5420())
+ ret = cpu_suspend(0, exynos_mcpm_cpu_suspend);
+ else
+ ret = cpu_suspend(0, exynos_cpu_suspend);
if (ret)
return ret;
+ if (soc_is_exynos5420())
+ mcpm_cpu_powered_up();
+
s3c_pm_restore_uarts();
S3C_PMDBG("%s: wakeup stat: %08x\n", __func__,
diff --git a/arch/arm/mach-exynos/regs-pmu.h b/arch/arm/mach-exynos/regs-pmu.h
index 3cf0454..e8c75db 100644
--- a/arch/arm/mach-exynos/regs-pmu.h
+++ b/arch/arm/mach-exynos/regs-pmu.h
@@ -152,6 +152,7 @@
#define S5P_PAD_RET_EBIB_OPTION 0x31A8
#define S5P_CORE_LOCAL_PWR_EN 0x3
+#define S5P_CHECK_SLEEP 0x00000BAD
/* Only for EXYNOS4210 */
#define S5P_CMU_CLKSTOP_LCD1_LOWPWR 0x1154
--
1.7.9.5
^ permalink raw reply related [flat|nested] 130+ messages in thread
* [PATCH v2] ARM: EXYNOS: Use MCPM call-backs to support S2R on Exynos5420
@ 2014-06-30 18:28 ` Abhilash Kesavan
0 siblings, 0 replies; 130+ messages in thread
From: Abhilash Kesavan @ 2014-06-30 18:28 UTC (permalink / raw)
To: linux-arm-kernel
Use the MCPM layer to handle core suspend/resume on Exynos5420.
Also, restore the entry address setup code post-resume.
Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
---
Hi Lorenzo and Nicolas,
I am now using the suspend/powered_up call-backs that were added as part
of Chander's CPUIdle series for Exynos5420. exynos_mcpm_cpu_suspend()
is based on the code in bL cpuidle driver except for a small addition.
This has been tested both on an SMDK5420 and Peach Pit Chromebook on
3.16-rc3.
Here are the dependencies (some of these patches did not apply cleanly):
1) Cleanup patches for mach-exynos
http://comments.gmane.org/gmane.linux.kernel.samsung-soc/33772
2) PMU cleanup and refactoring for using DT
https://www.mail-archive.com/linux-kernel at vger.kernel.org/msg671625.html
3) Exynos5420 PMU/S2R Series
http://comments.gmane.org/gmane.linux.kernel.samsung-soc/33898
4) MCPM boot CPU CCI enablement patches
www.spinics.net/lists/linux-samsung-soc/msg32923.html
5) Exynos5420 CPUIdle Series which populates MCPM suspend/powered_up
call-backs.
www.gossamer-threads.com/lists/linux/kernel/1945347
https://patchwork.kernel.org/patch/4357461/
6) Exynos5420 MCPM cluster power down support
http://www.spinics.net/lists/arm-kernel/msg339988.html
7) TPM reset mask patch
http://www.spinics.net/lists/arm-kernel/msg341884.html
arch/arm/mach-exynos/mcpm-exynos.c | 40 ++++++++++++++++++++++++++----------
arch/arm/mach-exynos/pm.c | 38 +++++++++++++++++++++++++++++++---
arch/arm/mach-exynos/regs-pmu.h | 1 +
3 files changed, 65 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-exynos/mcpm-exynos.c b/arch/arm/mach-exynos/mcpm-exynos.c
index 037a05e..dd298f3 100644
--- a/arch/arm/mach-exynos/mcpm-exynos.c
+++ b/arch/arm/mach-exynos/mcpm-exynos.c
@@ -15,6 +15,7 @@
#include <linux/delay.h>
#include <linux/io.h>
#include <linux/of_address.h>
+#include <linux/syscore_ops.h>
#include <asm/cputype.h>
#include <asm/cp15.h>
@@ -30,6 +31,8 @@
#define EXYNOS5420_USE_ARM_CORE_DOWN_STATE BIT(29)
#define EXYNOS5420_USE_L2_COMMON_UP_STATE BIT(30)
+static void __iomem *ns_sram_base_addr;
+
/*
* The common v7_exit_coherency_flush API could not be used because of the
* Erratum 799270 workaround. This macro is the same as the common one (in
@@ -150,7 +153,13 @@ static void exynos_power_down(void)
BUG_ON(__mcpm_cluster_state(cluster) != CLUSTER_UP);
cpu_use_count[cpu][cluster]--;
if (cpu_use_count[cpu][cluster] == 0) {
- exynos_cpu_power_down(cpunr);
+ /*
+ * Bypass power down for CPU0 during suspend. This is being
+ * taken care by the SYS_PWR_CFG bit in CORE0_SYS_PWR_REG.
+ */
+ if ((cpunr != 0) ||
+ (__raw_readl(pmu_base_addr + S5P_INFORM1) != S5P_CHECK_SLEEP))
+ exynos_cpu_power_down(cpunr);
if (exynos_cluster_unused(cluster)) {
exynos_cluster_power_down(cluster);
@@ -319,10 +328,26 @@ static const struct of_device_id exynos_dt_mcpm_match[] = {
{},
};
+static void exynos_mcpm_setup_entry_point(void)
+{
+ /*
+ * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
+ * as part of secondary_cpu_start(). Let's redirect it to the
+ * mcpm_entry_point(). This is done during both secondary boot-up as
+ * well as system resume.
+ */
+ __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
+ __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
+ __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
+}
+
+static struct syscore_ops exynos_mcpm_syscore_ops = {
+ .resume = exynos_mcpm_setup_entry_point,
+};
+
static int __init exynos_mcpm_init(void)
{
struct device_node *node;
- void __iomem *ns_sram_base_addr;
unsigned int value, i;
int ret;
@@ -389,16 +414,9 @@ static int __init exynos_mcpm_init(void)
__raw_writel(value, EXYNOS_COMMON_OPTION(i));
}
- /*
- * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
- * as part of secondary_cpu_start(). Let's redirect it to the
- * mcpm_entry_point().
- */
- __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
- __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
- __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
+ exynos_mcpm_setup_entry_point();
- iounmap(ns_sram_base_addr);
+ register_syscore_ops(&exynos_mcpm_syscore_ops);
return ret;
}
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index bf8564a..a4f4292 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -24,6 +24,7 @@
#include <asm/cacheflush.h>
#include <asm/hardware/cache-l2x0.h>
+#include <asm/mcpm.h>
#include <asm/smp_scu.h>
#include <asm/suspend.h>
@@ -191,7 +192,6 @@ int exynos_cluster_power_state(int cluster)
pmu_base_addr + S5P_INFORM1))
#define S5P_CHECK_AFTR 0xFCBA0D10
-#define S5P_CHECK_SLEEP 0x00000BAD
/* Ext-GIC nIRQ/nFIQ is the only wakeup source in AFTR */
static void exynos_set_wakeupmask(long mask)
@@ -318,7 +318,10 @@ static void exynos_pm_prepare(void)
/* ensure at least INFORM0 has the resume address */
- pmu_raw_writel(virt_to_phys(exynos_cpu_resume), S5P_INFORM0);
+ if (soc_is_exynos5420())
+ pmu_raw_writel(virt_to_phys(mcpm_entry_point), S5P_INFORM0);
+ else
+ pmu_raw_writel(virt_to_phys(exynos_cpu_resume), S5P_INFORM0);
if (soc_is_exynos5420()) {
tmp = __raw_readl(pmu_base_addr + EXYNOS5_ARM_L2_OPTION);
@@ -490,6 +493,28 @@ static struct syscore_ops exynos_pm_syscore_ops = {
.resume = exynos_pm_resume,
};
+static int notrace exynos_mcpm_cpu_suspend(unsigned long arg)
+{
+ /* MCPM works with HW CPU identifiers */
+ unsigned int mpidr = read_cpuid_mpidr();
+ unsigned int cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+ unsigned int cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+
+ __raw_writel(0x0, sysram_base_addr + EXYNOS5420_CPU_STATE);
+
+ mcpm_set_entry_vector(cpu, cluster, exynos_cpu_resume);
+
+ /*
+ * Residency value passed to mcpm_cpu_suspend back-end
+ * has to be given clear semantics. Set to 0 as a
+ * temporary value.
+ */
+ mcpm_cpu_suspend(0);
+
+ /* return value != 0 means failure */
+ return 1;
+}
+
/*
* Suspend Ops
*/
@@ -517,10 +542,17 @@ static int exynos_suspend_enter(suspend_state_t state)
flush_cache_all();
s3c_pm_check_store();
- ret = cpu_suspend(0, exynos_cpu_suspend);
+ /* Use the MCPM layer to suspend 5420 which is a multi-cluster SoC */
+ if (soc_is_exynos5420())
+ ret = cpu_suspend(0, exynos_mcpm_cpu_suspend);
+ else
+ ret = cpu_suspend(0, exynos_cpu_suspend);
if (ret)
return ret;
+ if (soc_is_exynos5420())
+ mcpm_cpu_powered_up();
+
s3c_pm_restore_uarts();
S3C_PMDBG("%s: wakeup stat: %08x\n", __func__,
diff --git a/arch/arm/mach-exynos/regs-pmu.h b/arch/arm/mach-exynos/regs-pmu.h
index 3cf0454..e8c75db 100644
--- a/arch/arm/mach-exynos/regs-pmu.h
+++ b/arch/arm/mach-exynos/regs-pmu.h
@@ -152,6 +152,7 @@
#define S5P_PAD_RET_EBIB_OPTION 0x31A8
#define S5P_CORE_LOCAL_PWR_EN 0x3
+#define S5P_CHECK_SLEEP 0x00000BAD
/* Only for EXYNOS4210 */
#define S5P_CMU_CLKSTOP_LCD1_LOWPWR 0x1154
--
1.7.9.5
^ permalink raw reply related [flat|nested] 130+ messages in thread
* Re: [PATCH v2] ARM: EXYNOS: Use MCPM call-backs to support S2R on Exynos5420
2014-06-30 18:28 ` Abhilash Kesavan
@ 2014-07-01 4:19 ` Nicolas Pitre
-1 siblings, 0 replies; 130+ messages in thread
From: Nicolas Pitre @ 2014-07-01 4:19 UTC (permalink / raw)
To: Abhilash Kesavan
Cc: linux-samsung-soc, linux-arm-kernel, kgene.kim,
Lorenzo Pieralisi, abrestic, dianders, kesavan.abhilash
On Mon, 30 Jun 2014, Abhilash Kesavan wrote:
> Use the MCPM layer to handle core suspend/resume on Exynos5420.
> Also, restore the entry address setup code post-resume.
>
> Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
> ---
[...]
Could you tell me more about this?
> @@ -150,7 +153,13 @@ static void exynos_power_down(void)
> BUG_ON(__mcpm_cluster_state(cluster) != CLUSTER_UP);
> cpu_use_count[cpu][cluster]--;
> if (cpu_use_count[cpu][cluster] == 0) {
> - exynos_cpu_power_down(cpunr);
> + /*
> + * Bypass power down for CPU0 during suspend. This is being
> + * taken care by the SYS_PWR_CFG bit in CORE0_SYS_PWR_REG.
> + */
> + if ((cpunr != 0) ||
> + (__raw_readl(pmu_base_addr + S5P_INFORM1) != S5P_CHECK_SLEEP))
> + exynos_cpu_power_down(cpunr);
What happens if CPU0 is the first in the cluster to be idled? Will it
remain powered up until all the others have gone idle too?
Nicolas
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH v2] ARM: EXYNOS: Use MCPM call-backs to support S2R on Exynos5420
@ 2014-07-01 4:19 ` Nicolas Pitre
0 siblings, 0 replies; 130+ messages in thread
From: Nicolas Pitre @ 2014-07-01 4:19 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, 30 Jun 2014, Abhilash Kesavan wrote:
> Use the MCPM layer to handle core suspend/resume on Exynos5420.
> Also, restore the entry address setup code post-resume.
>
> Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
> ---
[...]
Could you tell me more about this?
> @@ -150,7 +153,13 @@ static void exynos_power_down(void)
> BUG_ON(__mcpm_cluster_state(cluster) != CLUSTER_UP);
> cpu_use_count[cpu][cluster]--;
> if (cpu_use_count[cpu][cluster] == 0) {
> - exynos_cpu_power_down(cpunr);
> + /*
> + * Bypass power down for CPU0 during suspend. This is being
> + * taken care by the SYS_PWR_CFG bit in CORE0_SYS_PWR_REG.
> + */
> + if ((cpunr != 0) ||
> + (__raw_readl(pmu_base_addr + S5P_INFORM1) != S5P_CHECK_SLEEP))
> + exynos_cpu_power_down(cpunr);
What happens if CPU0 is the first in the cluster to be idled? Will it
remain powered up until all the others have gone idle too?
Nicolas
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: [PATCH v2] ARM: EXYNOS: Use MCPM call-backs to support S2R on Exynos5420
2014-07-01 4:19 ` Nicolas Pitre
@ 2014-07-01 13:14 ` Abhilash Kesavan
-1 siblings, 0 replies; 130+ messages in thread
From: Abhilash Kesavan @ 2014-07-01 13:14 UTC (permalink / raw)
To: Nicolas Pitre
Cc: linux-samsung-soc, linux-arm-kernel, Kukjin Kim,
Lorenzo Pieralisi, Andrew Bresticker, Douglas Anderson
Hi Nicolas,
On Tue, Jul 1, 2014 at 9:49 AM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> On Mon, 30 Jun 2014, Abhilash Kesavan wrote:
>
>> Use the MCPM layer to handle core suspend/resume on Exynos5420.
>> Also, restore the entry address setup code post-resume.
>>
>> Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
>> ---
> [...]
>
> Could you tell me more about this?
>
>> @@ -150,7 +153,13 @@ static void exynos_power_down(void)
>> BUG_ON(__mcpm_cluster_state(cluster) != CLUSTER_UP);
>> cpu_use_count[cpu][cluster]--;
>> if (cpu_use_count[cpu][cluster] == 0) {
>> - exynos_cpu_power_down(cpunr);
>> + /*
>> + * Bypass power down for CPU0 during suspend. This is being
>> + * taken care by the SYS_PWR_CFG bit in CORE0_SYS_PWR_REG.
>> + */
>> + if ((cpunr != 0) ||
>> + (__raw_readl(pmu_base_addr + S5P_INFORM1) != S5P_CHECK_SLEEP))
>> + exynos_cpu_power_down(cpunr);
>
> What happens if CPU0 is the first in the cluster to be idled? Will it
> remain powered up until all the others have gone idle too?
This check is only for handling the S2R CPU0 case. In case of
idle/switching the S5P_CHECK_SLEEP flag would not be set and hence
there would be no change in behavior for them.
During suspend, we enable the ARM_USE_STANDBY_WFI0 bit which tells the
PMU when the CPU0 is ready to be suspended. This in conjunction with
the sleep state core configuration (setting SYS_PWR_REG low) causes
the CPU0 to go down. We should not write to the CPU0 power
configuration register (exynos_cpu_power_down) along with this during
suspend.
Regards,
Abhilash
>
>
> Nicolas
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH v2] ARM: EXYNOS: Use MCPM call-backs to support S2R on Exynos5420
@ 2014-07-01 13:14 ` Abhilash Kesavan
0 siblings, 0 replies; 130+ messages in thread
From: Abhilash Kesavan @ 2014-07-01 13:14 UTC (permalink / raw)
To: linux-arm-kernel
Hi Nicolas,
On Tue, Jul 1, 2014 at 9:49 AM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> On Mon, 30 Jun 2014, Abhilash Kesavan wrote:
>
>> Use the MCPM layer to handle core suspend/resume on Exynos5420.
>> Also, restore the entry address setup code post-resume.
>>
>> Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
>> ---
> [...]
>
> Could you tell me more about this?
>
>> @@ -150,7 +153,13 @@ static void exynos_power_down(void)
>> BUG_ON(__mcpm_cluster_state(cluster) != CLUSTER_UP);
>> cpu_use_count[cpu][cluster]--;
>> if (cpu_use_count[cpu][cluster] == 0) {
>> - exynos_cpu_power_down(cpunr);
>> + /*
>> + * Bypass power down for CPU0 during suspend. This is being
>> + * taken care by the SYS_PWR_CFG bit in CORE0_SYS_PWR_REG.
>> + */
>> + if ((cpunr != 0) ||
>> + (__raw_readl(pmu_base_addr + S5P_INFORM1) != S5P_CHECK_SLEEP))
>> + exynos_cpu_power_down(cpunr);
>
> What happens if CPU0 is the first in the cluster to be idled? Will it
> remain powered up until all the others have gone idle too?
This check is only for handling the S2R CPU0 case. In case of
idle/switching the S5P_CHECK_SLEEP flag would not be set and hence
there would be no change in behavior for them.
During suspend, we enable the ARM_USE_STANDBY_WFI0 bit which tells the
PMU when the CPU0 is ready to be suspended. This in conjunction with
the sleep state core configuration (setting SYS_PWR_REG low) causes
the CPU0 to go down. We should not write to the CPU0 power
configuration register (exynos_cpu_power_down) along with this during
suspend.
Regards,
Abhilash
>
>
> Nicolas
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: [PATCH v2] ARM: EXYNOS: Use MCPM call-backs to support S2R on Exynos5420
2014-07-01 13:14 ` Abhilash Kesavan
@ 2014-07-01 13:50 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 130+ messages in thread
From: Lorenzo Pieralisi @ 2014-07-01 13:50 UTC (permalink / raw)
To: Abhilash Kesavan
Cc: Nicolas Pitre, linux-samsung-soc, linux-arm-kernel, Kukjin Kim,
Andrew Bresticker, Douglas Anderson
On Tue, Jul 01, 2014 at 02:14:49PM +0100, Abhilash Kesavan wrote:
> Hi Nicolas,
>
> On Tue, Jul 1, 2014 at 9:49 AM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> > On Mon, 30 Jun 2014, Abhilash Kesavan wrote:
> >
> >> Use the MCPM layer to handle core suspend/resume on Exynos5420.
> >> Also, restore the entry address setup code post-resume.
> >>
> >> Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
> >> ---
> > [...]
> >
> > Could you tell me more about this?
> >
> >> @@ -150,7 +153,13 @@ static void exynos_power_down(void)
> >> BUG_ON(__mcpm_cluster_state(cluster) != CLUSTER_UP);
> >> cpu_use_count[cpu][cluster]--;
> >> if (cpu_use_count[cpu][cluster] == 0) {
> >> - exynos_cpu_power_down(cpunr);
> >> + /*
> >> + * Bypass power down for CPU0 during suspend. This is being
> >> + * taken care by the SYS_PWR_CFG bit in CORE0_SYS_PWR_REG.
> >> + */
> >> + if ((cpunr != 0) ||
> >> + (__raw_readl(pmu_base_addr + S5P_INFORM1) != S5P_CHECK_SLEEP))
> >> + exynos_cpu_power_down(cpunr);
> >
> > What happens if CPU0 is the first in the cluster to be idled? Will it
> > remain powered up until all the others have gone idle too?
> This check is only for handling the S2R CPU0 case. In case of
> idle/switching the S5P_CHECK_SLEEP flag would not be set and hence
> there would be no change in behavior for them.
> During suspend, we enable the ARM_USE_STANDBY_WFI0 bit which tells the
> PMU when the CPU0 is ready to be suspended. This in conjunction with
> the sleep state core configuration (setting SYS_PWR_REG low) causes
> the CPU0 to go down. We should not write to the CPU0 power
> configuration register (exynos_cpu_power_down) along with this during
> suspend.
I think this should be part of a refactoring that includes the exynos MCPM
suspend call parameters. In particular, at the moment there is no code in
the back-end to detect if the last man should request core gating or cluster
gating (ie last man _always_ request cluster gating, that might not be what
we want), there is the residency value that can be also be used to imply a
S2R request (eg residency = ~0 ?).
The command sent must be implied by the state that is entered, not by
peeking at registers that should contain magic values, and that's true
not only for exynos but for all ARM platforms out there.
What I mean is: we can pass the requested state as a suspend parameter
and the power_down state machine will send the required command
accordingly.
It can be done using the residency value or by passing the power state "index"
as suspend parameter, the power down MCPM code will do a look-up and send
the respective command.
Thoughts appreciated.
Lorenzo
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH v2] ARM: EXYNOS: Use MCPM call-backs to support S2R on Exynos5420
@ 2014-07-01 13:50 ` Lorenzo Pieralisi
0 siblings, 0 replies; 130+ messages in thread
From: Lorenzo Pieralisi @ 2014-07-01 13:50 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Jul 01, 2014 at 02:14:49PM +0100, Abhilash Kesavan wrote:
> Hi Nicolas,
>
> On Tue, Jul 1, 2014 at 9:49 AM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> > On Mon, 30 Jun 2014, Abhilash Kesavan wrote:
> >
> >> Use the MCPM layer to handle core suspend/resume on Exynos5420.
> >> Also, restore the entry address setup code post-resume.
> >>
> >> Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
> >> ---
> > [...]
> >
> > Could you tell me more about this?
> >
> >> @@ -150,7 +153,13 @@ static void exynos_power_down(void)
> >> BUG_ON(__mcpm_cluster_state(cluster) != CLUSTER_UP);
> >> cpu_use_count[cpu][cluster]--;
> >> if (cpu_use_count[cpu][cluster] == 0) {
> >> - exynos_cpu_power_down(cpunr);
> >> + /*
> >> + * Bypass power down for CPU0 during suspend. This is being
> >> + * taken care by the SYS_PWR_CFG bit in CORE0_SYS_PWR_REG.
> >> + */
> >> + if ((cpunr != 0) ||
> >> + (__raw_readl(pmu_base_addr + S5P_INFORM1) != S5P_CHECK_SLEEP))
> >> + exynos_cpu_power_down(cpunr);
> >
> > What happens if CPU0 is the first in the cluster to be idled? Will it
> > remain powered up until all the others have gone idle too?
> This check is only for handling the S2R CPU0 case. In case of
> idle/switching the S5P_CHECK_SLEEP flag would not be set and hence
> there would be no change in behavior for them.
> During suspend, we enable the ARM_USE_STANDBY_WFI0 bit which tells the
> PMU when the CPU0 is ready to be suspended. This in conjunction with
> the sleep state core configuration (setting SYS_PWR_REG low) causes
> the CPU0 to go down. We should not write to the CPU0 power
> configuration register (exynos_cpu_power_down) along with this during
> suspend.
I think this should be part of a refactoring that includes the exynos MCPM
suspend call parameters. In particular, at the moment there is no code in
the back-end to detect if the last man should request core gating or cluster
gating (ie last man _always_ request cluster gating, that might not be what
we want), there is the residency value that can be also be used to imply a
S2R request (eg residency = ~0 ?).
The command sent must be implied by the state that is entered, not by
peeking at registers that should contain magic values, and that's true
not only for exynos but for all ARM platforms out there.
What I mean is: we can pass the requested state as a suspend parameter
and the power_down state machine will send the required command
accordingly.
It can be done using the residency value or by passing the power state "index"
as suspend parameter, the power down MCPM code will do a look-up and send
the respective command.
Thoughts appreciated.
Lorenzo
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: [PATCH v2] ARM: EXYNOS: Use MCPM call-backs to support S2R on Exynos5420
2014-07-01 13:50 ` Lorenzo Pieralisi
@ 2014-07-01 20:02 ` Nicolas Pitre
-1 siblings, 0 replies; 130+ messages in thread
From: Nicolas Pitre @ 2014-07-01 20:02 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Abhilash Kesavan, linux-samsung-soc, linux-arm-kernel,
Kukjin Kim, Andrew Bresticker, Douglas Anderson
On Tue, 1 Jul 2014, Lorenzo Pieralisi wrote:
> On Tue, Jul 01, 2014 at 02:14:49PM +0100, Abhilash Kesavan wrote:
> > Hi Nicolas,
> >
> > On Tue, Jul 1, 2014 at 9:49 AM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> > > On Mon, 30 Jun 2014, Abhilash Kesavan wrote:
> > >
> > >> Use the MCPM layer to handle core suspend/resume on Exynos5420.
> > >> Also, restore the entry address setup code post-resume.
> > >>
> > >> Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
> > >> ---
> > > [...]
> > >
> > > Could you tell me more about this?
> > >
> > >> @@ -150,7 +153,13 @@ static void exynos_power_down(void)
> > >> BUG_ON(__mcpm_cluster_state(cluster) != CLUSTER_UP);
> > >> cpu_use_count[cpu][cluster]--;
> > >> if (cpu_use_count[cpu][cluster] == 0) {
> > >> - exynos_cpu_power_down(cpunr);
> > >> + /*
> > >> + * Bypass power down for CPU0 during suspend. This is being
> > >> + * taken care by the SYS_PWR_CFG bit in CORE0_SYS_PWR_REG.
> > >> + */
> > >> + if ((cpunr != 0) ||
> > >> + (__raw_readl(pmu_base_addr + S5P_INFORM1) != S5P_CHECK_SLEEP))
> > >> + exynos_cpu_power_down(cpunr);
> > >
> > > What happens if CPU0 is the first in the cluster to be idled? Will it
> > > remain powered up until all the others have gone idle too?
> > This check is only for handling the S2R CPU0 case. In case of
> > idle/switching the S5P_CHECK_SLEEP flag would not be set and hence
> > there would be no change in behavior for them.
> > During suspend, we enable the ARM_USE_STANDBY_WFI0 bit which tells the
> > PMU when the CPU0 is ready to be suspended. This in conjunction with
> > the sleep state core configuration (setting SYS_PWR_REG low) causes
> > the CPU0 to go down. We should not write to the CPU0 power
> > configuration register (exynos_cpu_power_down) along with this during
> > suspend.
>
> I think this should be part of a refactoring that includes the exynos MCPM
> suspend call parameters. In particular, at the moment there is no code in
> the back-end to detect if the last man should request core gating or cluster
> gating (ie last man _always_ request cluster gating, that might not be what
> we want), there is the residency value that can be also be used to imply a
> S2R request (eg residency = ~0 ?).
>
> The command sent must be implied by the state that is entered, not by
> peeking at registers that should contain magic values, and that's true
> not only for exynos but for all ARM platforms out there.
>
> What I mean is: we can pass the requested state as a suspend parameter
> and the power_down state machine will send the required command
> accordingly.
>
> It can be done using the residency value or by passing the power state "index"
> as suspend parameter, the power down MCPM code will do a look-up and send
> the respective command.
>
> Thoughts appreciated.
I agree. Having the MCPM abstraction having to rely on some magic value
to be set in a register beforehand for things to work properly is not
nice.
Nicolas
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH v2] ARM: EXYNOS: Use MCPM call-backs to support S2R on Exynos5420
@ 2014-07-01 20:02 ` Nicolas Pitre
0 siblings, 0 replies; 130+ messages in thread
From: Nicolas Pitre @ 2014-07-01 20:02 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, 1 Jul 2014, Lorenzo Pieralisi wrote:
> On Tue, Jul 01, 2014 at 02:14:49PM +0100, Abhilash Kesavan wrote:
> > Hi Nicolas,
> >
> > On Tue, Jul 1, 2014 at 9:49 AM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> > > On Mon, 30 Jun 2014, Abhilash Kesavan wrote:
> > >
> > >> Use the MCPM layer to handle core suspend/resume on Exynos5420.
> > >> Also, restore the entry address setup code post-resume.
> > >>
> > >> Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
> > >> ---
> > > [...]
> > >
> > > Could you tell me more about this?
> > >
> > >> @@ -150,7 +153,13 @@ static void exynos_power_down(void)
> > >> BUG_ON(__mcpm_cluster_state(cluster) != CLUSTER_UP);
> > >> cpu_use_count[cpu][cluster]--;
> > >> if (cpu_use_count[cpu][cluster] == 0) {
> > >> - exynos_cpu_power_down(cpunr);
> > >> + /*
> > >> + * Bypass power down for CPU0 during suspend. This is being
> > >> + * taken care by the SYS_PWR_CFG bit in CORE0_SYS_PWR_REG.
> > >> + */
> > >> + if ((cpunr != 0) ||
> > >> + (__raw_readl(pmu_base_addr + S5P_INFORM1) != S5P_CHECK_SLEEP))
> > >> + exynos_cpu_power_down(cpunr);
> > >
> > > What happens if CPU0 is the first in the cluster to be idled? Will it
> > > remain powered up until all the others have gone idle too?
> > This check is only for handling the S2R CPU0 case. In case of
> > idle/switching the S5P_CHECK_SLEEP flag would not be set and hence
> > there would be no change in behavior for them.
> > During suspend, we enable the ARM_USE_STANDBY_WFI0 bit which tells the
> > PMU when the CPU0 is ready to be suspended. This in conjunction with
> > the sleep state core configuration (setting SYS_PWR_REG low) causes
> > the CPU0 to go down. We should not write to the CPU0 power
> > configuration register (exynos_cpu_power_down) along with this during
> > suspend.
>
> I think this should be part of a refactoring that includes the exynos MCPM
> suspend call parameters. In particular, at the moment there is no code in
> the back-end to detect if the last man should request core gating or cluster
> gating (ie last man _always_ request cluster gating, that might not be what
> we want), there is the residency value that can be also be used to imply a
> S2R request (eg residency = ~0 ?).
>
> The command sent must be implied by the state that is entered, not by
> peeking at registers that should contain magic values, and that's true
> not only for exynos but for all ARM platforms out there.
>
> What I mean is: we can pass the requested state as a suspend parameter
> and the power_down state machine will send the required command
> accordingly.
>
> It can be done using the residency value or by passing the power state "index"
> as suspend parameter, the power down MCPM code will do a look-up and send
> the respective command.
>
> Thoughts appreciated.
I agree. Having the MCPM abstraction having to rely on some magic value
to be set in a register beforehand for things to work properly is not
nice.
Nicolas
^ permalink raw reply [flat|nested] 130+ messages in thread
* [RFC PATCH v3] ARM: EXYNOS: Use MCPM call-backs to support S2R on Exynos5420
2014-06-30 18:28 ` Abhilash Kesavan
@ 2014-07-02 14:59 ` Abhilash Kesavan
-1 siblings, 0 replies; 130+ messages in thread
From: Abhilash Kesavan @ 2014-07-02 14:59 UTC (permalink / raw)
To: linux-samsung-soc, linux-arm-kernel, kgene.kim, nicolas.pitre,
lorenzo.pieralisi
Cc: abrestic, dianders, kesavan.abhilash
Use the MCPM layer to handle core suspend/resume on Exynos5420.
Also, restore the entry address setup code post-resume.
Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
---
Hi Lorenzo and Nicolas,
I have re-worked the patch to use the residency value as an indicator of the
current state. This is untested and I haven't taken care of any changes that
tc2 might require. Posting this as an RFC to check if this is the expected
approach.
Depencies remain the same as v2.
arch/arm/include/asm/mcpm.h | 6 +++++
arch/arm/mach-exynos/mcpm-exynos.c | 50 ++++++++++++++++++++++++++----------
arch/arm/mach-exynos/pm.c | 38 ++++++++++++++++++++++++---
arch/arm/mach-exynos/regs-pmu.h | 1 +
drivers/cpuidle/cpuidle-big_little.c | 2 +-
5 files changed, 79 insertions(+), 18 deletions(-)
diff --git a/arch/arm/include/asm/mcpm.h b/arch/arm/include/asm/mcpm.h
index ff73aff..0848829 100644
--- a/arch/arm/include/asm/mcpm.h
+++ b/arch/arm/include/asm/mcpm.h
@@ -272,4 +272,10 @@ void __init mcpm_smp_set_ops(void);
#define MCPM_SYNC_CLUSTER_SIZE \
(MCPM_SYNC_CLUSTER_INBOUND + __CACHE_WRITEBACK_GRANULE)
+/* Definitions for various MCPM scenarios that might need special handling */
+#define MCPM_CPU_IDLE 0x0
+#define MCPM_CPU_SUSPEND 0x1
+#define MCPM_CPU_SWITCH 0x2
+#define MCPM_CPU_HOTPLUG 0x3
+
#endif
diff --git a/arch/arm/mach-exynos/mcpm-exynos.c b/arch/arm/mach-exynos/mcpm-exynos.c
index 1baca55..c3673bd 100644
--- a/arch/arm/mach-exynos/mcpm-exynos.c
+++ b/arch/arm/mach-exynos/mcpm-exynos.c
@@ -15,6 +15,7 @@
#include <linux/delay.h>
#include <linux/io.h>
#include <linux/of_address.h>
+#include <linux/syscore_ops.h>
#include <asm/cputype.h>
#include <asm/cp15.h>
@@ -30,6 +31,8 @@
#define EXYNOS5420_USE_ARM_CORE_DOWN_STATE BIT(29)
#define EXYNOS5420_USE_L2_COMMON_UP_STATE BIT(30)
+static void __iomem *ns_sram_base_addr;
+
/*
* The common v7_exit_coherency_flush API could not be used because of the
* Erratum 799270 workaround. This macro is the same as the common one (in
@@ -129,7 +132,7 @@ static int exynos_power_up(unsigned int cpu, unsigned int cluster)
* and can only be executed on processors like A15 and A7 that hit the cache
* with the C bit clear in the SCTLR register.
*/
-static void exynos_power_down(void)
+static void exynos_mcpm_power_down(u64 residency)
{
unsigned int mpidr, cpu, cluster;
bool last_man = false, skip_wfi = false;
@@ -150,7 +153,12 @@ static void exynos_power_down(void)
BUG_ON(__mcpm_cluster_state(cluster) != CLUSTER_UP);
cpu_use_count[cpu][cluster]--;
if (cpu_use_count[cpu][cluster] == 0) {
- exynos_cpu_power_down(cpunr);
+ /*
+ * Bypass power down for CPU0 during suspend. This is being
+ * taken care by the SYS_PWR_CFG bit in CORE0_SYS_PWR_REG.
+ */
+ if ((cpunr != 0) || (residency != MCPM_CPU_SUSPEND))
+ exynos_cpu_power_down(cpunr);
if (exynos_cluster_unused(cluster)) {
exynos_cluster_power_down(cluster);
@@ -209,6 +217,11 @@ static void exynos_power_down(void)
/* Not dead at this point? Let our caller cope. */
}
+static void exynos_power_down(void)
+{
+ exynos_mcpm_power_down(MCPM_CPU_SWITCH | MCPM_CPU_HOTPLUG);
+}
+
static int exynos_wait_for_powerdown(unsigned int cpu, unsigned int cluster)
{
unsigned int tries = 100;
@@ -250,11 +263,11 @@ static void exynos_suspend(u64 residency)
{
unsigned int mpidr, cpunr;
- exynos_power_down();
+ exynos_mcpm_power_down(residency);
/*
* Execution reaches here only if cpu did not power down.
- * Hence roll back the changes done in exynos_power_down function.
+ * Hence roll back the changes done in exynos_mcpm_power_down function.
*
* CAUTION: "This function requires the stack data to be visible through
* power down and can only be executed on processors like A15 and A7
@@ -319,10 +332,26 @@ static const struct of_device_id exynos_dt_mcpm_match[] = {
{},
};
+static void exynos_mcpm_setup_entry_point(void)
+{
+ /*
+ * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
+ * as part of secondary_cpu_start(). Let's redirect it to the
+ * mcpm_entry_point(). This is done during both secondary boot-up as
+ * well as system resume.
+ */
+ __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
+ __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
+ __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
+}
+
+static struct syscore_ops exynos_mcpm_syscore_ops = {
+ .resume = exynos_mcpm_setup_entry_point,
+};
+
static int __init exynos_mcpm_init(void)
{
struct device_node *node;
- void __iomem *ns_sram_base_addr;
unsigned int value, i;
int ret;
@@ -389,16 +418,9 @@ static int __init exynos_mcpm_init(void)
__raw_writel(value, EXYNOS_COMMON_OPTION(i));
}
- /*
- * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
- * as part of secondary_cpu_start(). Let's redirect it to the
- * mcpm_entry_point().
- */
- __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
- __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
- __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
+ exynos_mcpm_setup_entry_point();
- iounmap(ns_sram_base_addr);
+ register_syscore_ops(&exynos_mcpm_syscore_ops);
return ret;
}
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index bf8564a..1dce5d2 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -24,6 +24,7 @@
#include <asm/cacheflush.h>
#include <asm/hardware/cache-l2x0.h>
+#include <asm/mcpm.h>
#include <asm/smp_scu.h>
#include <asm/suspend.h>
@@ -191,7 +192,6 @@ int exynos_cluster_power_state(int cluster)
pmu_base_addr + S5P_INFORM1))
#define S5P_CHECK_AFTR 0xFCBA0D10
-#define S5P_CHECK_SLEEP 0x00000BAD
/* Ext-GIC nIRQ/nFIQ is the only wakeup source in AFTR */
static void exynos_set_wakeupmask(long mask)
@@ -318,7 +318,10 @@ static void exynos_pm_prepare(void)
/* ensure at least INFORM0 has the resume address */
- pmu_raw_writel(virt_to_phys(exynos_cpu_resume), S5P_INFORM0);
+ if (soc_is_exynos5420())
+ pmu_raw_writel(virt_to_phys(mcpm_entry_point), S5P_INFORM0);
+ else
+ pmu_raw_writel(virt_to_phys(exynos_cpu_resume), S5P_INFORM0);
if (soc_is_exynos5420()) {
tmp = __raw_readl(pmu_base_addr + EXYNOS5_ARM_L2_OPTION);
@@ -490,6 +493,28 @@ static struct syscore_ops exynos_pm_syscore_ops = {
.resume = exynos_pm_resume,
};
+static int notrace exynos_mcpm_cpu_suspend(unsigned long arg)
+{
+ /* MCPM works with HW CPU identifiers */
+ unsigned int mpidr = read_cpuid_mpidr();
+ unsigned int cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+ unsigned int cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+
+ __raw_writel(0x0, sysram_base_addr + EXYNOS5420_CPU_STATE);
+
+ mcpm_set_entry_vector(cpu, cluster, exynos_cpu_resume);
+
+ /*
+ * Residency value passed to mcpm_cpu_suspend back-end
+ * has to be given clear semantics. Set to 0 as a
+ * temporary value.
+ */
+ mcpm_cpu_suspend(MCPM_CPU_SUSPEND);
+
+ /* return value != 0 means failure */
+ return 1;
+}
+
/*
* Suspend Ops
*/
@@ -517,10 +542,17 @@ static int exynos_suspend_enter(suspend_state_t state)
flush_cache_all();
s3c_pm_check_store();
- ret = cpu_suspend(0, exynos_cpu_suspend);
+ /* Use the MCPM layer to suspend 5420 which is a multi-cluster SoC */
+ if (soc_is_exynos5420())
+ ret = cpu_suspend(0, exynos_mcpm_cpu_suspend);
+ else
+ ret = cpu_suspend(0, exynos_cpu_suspend);
if (ret)
return ret;
+ if (soc_is_exynos5420())
+ mcpm_cpu_powered_up();
+
s3c_pm_restore_uarts();
S3C_PMDBG("%s: wakeup stat: %08x\n", __func__,
diff --git a/arch/arm/mach-exynos/regs-pmu.h b/arch/arm/mach-exynos/regs-pmu.h
index 3cf0454..e8c75db 100644
--- a/arch/arm/mach-exynos/regs-pmu.h
+++ b/arch/arm/mach-exynos/regs-pmu.h
@@ -152,6 +152,7 @@
#define S5P_PAD_RET_EBIB_OPTION 0x31A8
#define S5P_CORE_LOCAL_PWR_EN 0x3
+#define S5P_CHECK_SLEEP 0x00000BAD
/* Only for EXYNOS4210 */
#define S5P_CMU_CLKSTOP_LCD1_LOWPWR 0x1154
diff --git a/drivers/cpuidle/cpuidle-big_little.c b/drivers/cpuidle/cpuidle-big_little.c
index 344d79fa..fab2270 100644
--- a/drivers/cpuidle/cpuidle-big_little.c
+++ b/drivers/cpuidle/cpuidle-big_little.c
@@ -108,7 +108,7 @@ static int notrace bl_powerdown_finisher(unsigned long arg)
* has to be given clear semantics. Set to 0 as a
* temporary value.
*/
- mcpm_cpu_suspend(0);
+ mcpm_cpu_suspend(MCPM_CPU_IDLE);
/* return value != 0 means failure */
return 1;
--
2.0.0
^ permalink raw reply related [flat|nested] 130+ messages in thread
* [RFC PATCH v3] ARM: EXYNOS: Use MCPM call-backs to support S2R on Exynos5420
@ 2014-07-02 14:59 ` Abhilash Kesavan
0 siblings, 0 replies; 130+ messages in thread
From: Abhilash Kesavan @ 2014-07-02 14:59 UTC (permalink / raw)
To: linux-arm-kernel
Use the MCPM layer to handle core suspend/resume on Exynos5420.
Also, restore the entry address setup code post-resume.
Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
---
Hi Lorenzo and Nicolas,
I have re-worked the patch to use the residency value as an indicator of the
current state. This is untested and I haven't taken care of any changes that
tc2 might require. Posting this as an RFC to check if this is the expected
approach.
Depencies remain the same as v2.
arch/arm/include/asm/mcpm.h | 6 +++++
arch/arm/mach-exynos/mcpm-exynos.c | 50 ++++++++++++++++++++++++++----------
arch/arm/mach-exynos/pm.c | 38 ++++++++++++++++++++++++---
arch/arm/mach-exynos/regs-pmu.h | 1 +
drivers/cpuidle/cpuidle-big_little.c | 2 +-
5 files changed, 79 insertions(+), 18 deletions(-)
diff --git a/arch/arm/include/asm/mcpm.h b/arch/arm/include/asm/mcpm.h
index ff73aff..0848829 100644
--- a/arch/arm/include/asm/mcpm.h
+++ b/arch/arm/include/asm/mcpm.h
@@ -272,4 +272,10 @@ void __init mcpm_smp_set_ops(void);
#define MCPM_SYNC_CLUSTER_SIZE \
(MCPM_SYNC_CLUSTER_INBOUND + __CACHE_WRITEBACK_GRANULE)
+/* Definitions for various MCPM scenarios that might need special handling */
+#define MCPM_CPU_IDLE 0x0
+#define MCPM_CPU_SUSPEND 0x1
+#define MCPM_CPU_SWITCH 0x2
+#define MCPM_CPU_HOTPLUG 0x3
+
#endif
diff --git a/arch/arm/mach-exynos/mcpm-exynos.c b/arch/arm/mach-exynos/mcpm-exynos.c
index 1baca55..c3673bd 100644
--- a/arch/arm/mach-exynos/mcpm-exynos.c
+++ b/arch/arm/mach-exynos/mcpm-exynos.c
@@ -15,6 +15,7 @@
#include <linux/delay.h>
#include <linux/io.h>
#include <linux/of_address.h>
+#include <linux/syscore_ops.h>
#include <asm/cputype.h>
#include <asm/cp15.h>
@@ -30,6 +31,8 @@
#define EXYNOS5420_USE_ARM_CORE_DOWN_STATE BIT(29)
#define EXYNOS5420_USE_L2_COMMON_UP_STATE BIT(30)
+static void __iomem *ns_sram_base_addr;
+
/*
* The common v7_exit_coherency_flush API could not be used because of the
* Erratum 799270 workaround. This macro is the same as the common one (in
@@ -129,7 +132,7 @@ static int exynos_power_up(unsigned int cpu, unsigned int cluster)
* and can only be executed on processors like A15 and A7 that hit the cache
* with the C bit clear in the SCTLR register.
*/
-static void exynos_power_down(void)
+static void exynos_mcpm_power_down(u64 residency)
{
unsigned int mpidr, cpu, cluster;
bool last_man = false, skip_wfi = false;
@@ -150,7 +153,12 @@ static void exynos_power_down(void)
BUG_ON(__mcpm_cluster_state(cluster) != CLUSTER_UP);
cpu_use_count[cpu][cluster]--;
if (cpu_use_count[cpu][cluster] == 0) {
- exynos_cpu_power_down(cpunr);
+ /*
+ * Bypass power down for CPU0 during suspend. This is being
+ * taken care by the SYS_PWR_CFG bit in CORE0_SYS_PWR_REG.
+ */
+ if ((cpunr != 0) || (residency != MCPM_CPU_SUSPEND))
+ exynos_cpu_power_down(cpunr);
if (exynos_cluster_unused(cluster)) {
exynos_cluster_power_down(cluster);
@@ -209,6 +217,11 @@ static void exynos_power_down(void)
/* Not dead at this point? Let our caller cope. */
}
+static void exynos_power_down(void)
+{
+ exynos_mcpm_power_down(MCPM_CPU_SWITCH | MCPM_CPU_HOTPLUG);
+}
+
static int exynos_wait_for_powerdown(unsigned int cpu, unsigned int cluster)
{
unsigned int tries = 100;
@@ -250,11 +263,11 @@ static void exynos_suspend(u64 residency)
{
unsigned int mpidr, cpunr;
- exynos_power_down();
+ exynos_mcpm_power_down(residency);
/*
* Execution reaches here only if cpu did not power down.
- * Hence roll back the changes done in exynos_power_down function.
+ * Hence roll back the changes done in exynos_mcpm_power_down function.
*
* CAUTION: "This function requires the stack data to be visible through
* power down and can only be executed on processors like A15 and A7
@@ -319,10 +332,26 @@ static const struct of_device_id exynos_dt_mcpm_match[] = {
{},
};
+static void exynos_mcpm_setup_entry_point(void)
+{
+ /*
+ * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
+ * as part of secondary_cpu_start(). Let's redirect it to the
+ * mcpm_entry_point(). This is done during both secondary boot-up as
+ * well as system resume.
+ */
+ __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
+ __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
+ __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
+}
+
+static struct syscore_ops exynos_mcpm_syscore_ops = {
+ .resume = exynos_mcpm_setup_entry_point,
+};
+
static int __init exynos_mcpm_init(void)
{
struct device_node *node;
- void __iomem *ns_sram_base_addr;
unsigned int value, i;
int ret;
@@ -389,16 +418,9 @@ static int __init exynos_mcpm_init(void)
__raw_writel(value, EXYNOS_COMMON_OPTION(i));
}
- /*
- * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
- * as part of secondary_cpu_start(). Let's redirect it to the
- * mcpm_entry_point().
- */
- __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
- __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
- __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
+ exynos_mcpm_setup_entry_point();
- iounmap(ns_sram_base_addr);
+ register_syscore_ops(&exynos_mcpm_syscore_ops);
return ret;
}
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index bf8564a..1dce5d2 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -24,6 +24,7 @@
#include <asm/cacheflush.h>
#include <asm/hardware/cache-l2x0.h>
+#include <asm/mcpm.h>
#include <asm/smp_scu.h>
#include <asm/suspend.h>
@@ -191,7 +192,6 @@ int exynos_cluster_power_state(int cluster)
pmu_base_addr + S5P_INFORM1))
#define S5P_CHECK_AFTR 0xFCBA0D10
-#define S5P_CHECK_SLEEP 0x00000BAD
/* Ext-GIC nIRQ/nFIQ is the only wakeup source in AFTR */
static void exynos_set_wakeupmask(long mask)
@@ -318,7 +318,10 @@ static void exynos_pm_prepare(void)
/* ensure at least INFORM0 has the resume address */
- pmu_raw_writel(virt_to_phys(exynos_cpu_resume), S5P_INFORM0);
+ if (soc_is_exynos5420())
+ pmu_raw_writel(virt_to_phys(mcpm_entry_point), S5P_INFORM0);
+ else
+ pmu_raw_writel(virt_to_phys(exynos_cpu_resume), S5P_INFORM0);
if (soc_is_exynos5420()) {
tmp = __raw_readl(pmu_base_addr + EXYNOS5_ARM_L2_OPTION);
@@ -490,6 +493,28 @@ static struct syscore_ops exynos_pm_syscore_ops = {
.resume = exynos_pm_resume,
};
+static int notrace exynos_mcpm_cpu_suspend(unsigned long arg)
+{
+ /* MCPM works with HW CPU identifiers */
+ unsigned int mpidr = read_cpuid_mpidr();
+ unsigned int cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+ unsigned int cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+
+ __raw_writel(0x0, sysram_base_addr + EXYNOS5420_CPU_STATE);
+
+ mcpm_set_entry_vector(cpu, cluster, exynos_cpu_resume);
+
+ /*
+ * Residency value passed to mcpm_cpu_suspend back-end
+ * has to be given clear semantics. Set to 0 as a
+ * temporary value.
+ */
+ mcpm_cpu_suspend(MCPM_CPU_SUSPEND);
+
+ /* return value != 0 means failure */
+ return 1;
+}
+
/*
* Suspend Ops
*/
@@ -517,10 +542,17 @@ static int exynos_suspend_enter(suspend_state_t state)
flush_cache_all();
s3c_pm_check_store();
- ret = cpu_suspend(0, exynos_cpu_suspend);
+ /* Use the MCPM layer to suspend 5420 which is a multi-cluster SoC */
+ if (soc_is_exynos5420())
+ ret = cpu_suspend(0, exynos_mcpm_cpu_suspend);
+ else
+ ret = cpu_suspend(0, exynos_cpu_suspend);
if (ret)
return ret;
+ if (soc_is_exynos5420())
+ mcpm_cpu_powered_up();
+
s3c_pm_restore_uarts();
S3C_PMDBG("%s: wakeup stat: %08x\n", __func__,
diff --git a/arch/arm/mach-exynos/regs-pmu.h b/arch/arm/mach-exynos/regs-pmu.h
index 3cf0454..e8c75db 100644
--- a/arch/arm/mach-exynos/regs-pmu.h
+++ b/arch/arm/mach-exynos/regs-pmu.h
@@ -152,6 +152,7 @@
#define S5P_PAD_RET_EBIB_OPTION 0x31A8
#define S5P_CORE_LOCAL_PWR_EN 0x3
+#define S5P_CHECK_SLEEP 0x00000BAD
/* Only for EXYNOS4210 */
#define S5P_CMU_CLKSTOP_LCD1_LOWPWR 0x1154
diff --git a/drivers/cpuidle/cpuidle-big_little.c b/drivers/cpuidle/cpuidle-big_little.c
index 344d79fa..fab2270 100644
--- a/drivers/cpuidle/cpuidle-big_little.c
+++ b/drivers/cpuidle/cpuidle-big_little.c
@@ -108,7 +108,7 @@ static int notrace bl_powerdown_finisher(unsigned long arg)
* has to be given clear semantics. Set to 0 as a
* temporary value.
*/
- mcpm_cpu_suspend(0);
+ mcpm_cpu_suspend(MCPM_CPU_IDLE);
/* return value != 0 means failure */
return 1;
--
2.0.0
^ permalink raw reply related [flat|nested] 130+ messages in thread
* [RFC PATCH v4] ARM: EXYNOS: Use MCPM call-backs to support S2R on Exynos5420
2014-07-02 14:59 ` Abhilash Kesavan
@ 2014-07-03 5:02 ` Abhilash Kesavan
-1 siblings, 0 replies; 130+ messages in thread
From: Abhilash Kesavan @ 2014-07-03 5:02 UTC (permalink / raw)
To: linux-samsung-soc, linux-arm-kernel, kgene.kim, nicolas.pitre,
lorenzo.pieralisi
Cc: kesavan.abhilash, abrestic, dianders, Abhilash Kesavan
Use the MCPM layer to handle core suspend/resume on Exynos5420.
Also, restore the entry address setup code post-resume.
Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
---
Changes in v2:
- Made use of the MCPM suspend/powered_up call-backs
Changes in v3:
- Used the residency value to indicate the entered state
Changes in v4:
- Checked if MCPM has been enabled to prevent build error
This has been tested both on an SMDK5420 and Peach Pit Chromebook on
3.16-rc3/next-20140702.
Here are the dependencies (some of these patches did not apply cleanly):
1) Cleanup patches for mach-exynos
http://comments.gmane.org/gmane.linux.kernel.samsung-soc/33772
2) PMU cleanup and refactoring for using DT
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg671625.html
3) Exynos5420 PMU/S2R Series
http://comments.gmane.org/gmane.linux.kernel.samsung-soc/33898
4) MCPM boot CPU CCI enablement patches
www.spinics.net/lists/linux-samsung-soc/msg32923.html
5) Exynos5420 CPUIdle Series which populates MCPM suspend/powered_up
call-backs.
www.gossamer-threads.com/lists/linux/kernel/1945347
https://patchwork.kernel.org/patch/4357461/
6) Exynos5420 MCPM cluster power down support
http://www.spinics.net/lists/arm-kernel/msg339988.html
7) TPM reset mask patch
http://www.spinics.net/lists/arm-kernel/msg341884.html
arch/arm/include/asm/mcpm.h | 6 ++++
arch/arm/mach-exynos/mcpm-exynos.c | 50 ++++++++++++++++++++++++----------
arch/arm/mach-exynos/pm.c | 38 ++++++++++++++++++++++++--
arch/arm/mach-exynos/regs-pmu.h | 1 +
drivers/cpuidle/cpuidle-big_little.c | 2 +-
5 files changed, 79 insertions(+), 18 deletions(-)
diff --git a/arch/arm/include/asm/mcpm.h b/arch/arm/include/asm/mcpm.h
index ff73aff..051fbf1 100644
--- a/arch/arm/include/asm/mcpm.h
+++ b/arch/arm/include/asm/mcpm.h
@@ -272,4 +272,10 @@ void __init mcpm_smp_set_ops(void);
#define MCPM_SYNC_CLUSTER_SIZE \
(MCPM_SYNC_CLUSTER_INBOUND + __CACHE_WRITEBACK_GRANULE)
+/* Definitions for various MCPM scenarios that might need special handling */
+#define MCPM_CPU_IDLE 0x0
+#define MCPM_CPU_SUSPEND 0x1
+#define MCPM_CPU_SWITCH 0x2
+#define MCPM_CPU_HOTPLUG 0x3
+
#endif
diff --git a/arch/arm/mach-exynos/mcpm-exynos.c b/arch/arm/mach-exynos/mcpm-exynos.c
index 0315601..9a381f6 100644
--- a/arch/arm/mach-exynos/mcpm-exynos.c
+++ b/arch/arm/mach-exynos/mcpm-exynos.c
@@ -15,6 +15,7 @@
#include <linux/delay.h>
#include <linux/io.h>
#include <linux/of_address.h>
+#include <linux/syscore_ops.h>
#include <asm/cputype.h>
#include <asm/cp15.h>
@@ -30,6 +31,8 @@
#define EXYNOS5420_USE_ARM_CORE_DOWN_STATE BIT(29)
#define EXYNOS5420_USE_L2_COMMON_UP_STATE BIT(30)
+static void __iomem *ns_sram_base_addr;
+
/*
* The common v7_exit_coherency_flush API could not be used because of the
* Erratum 799270 workaround. This macro is the same as the common one (in
@@ -129,7 +132,7 @@ static int exynos_power_up(unsigned int cpu, unsigned int cluster)
* and can only be executed on processors like A15 and A7 that hit the cache
* with the C bit clear in the SCTLR register.
*/
-static void exynos_power_down(void)
+static void exynos_mcpm_power_down(u64 residency)
{
unsigned int mpidr, cpu, cluster;
bool last_man = false, skip_wfi = false;
@@ -150,7 +153,12 @@ static void exynos_power_down(void)
BUG_ON(__mcpm_cluster_state(cluster) != CLUSTER_UP);
cpu_use_count[cpu][cluster]--;
if (cpu_use_count[cpu][cluster] == 0) {
- exynos_cpu_power_down(cpunr);
+ /*
+ * Bypass power down for CPU0 during suspend. This is being
+ * taken care by the SYS_PWR_CFG bit in CORE0_SYS_PWR_REG.
+ */
+ if ((cpunr != 0) || (residency != MCPM_CPU_SUSPEND))
+ exynos_cpu_power_down(cpunr);
if (exynos_cluster_unused(cluster)) {
exynos_cluster_power_down(cluster);
@@ -209,6 +217,11 @@ static void exynos_power_down(void)
/* Not dead at this point? Let our caller cope. */
}
+static void exynos_power_down(void)
+{
+ exynos_mcpm_power_down(MCPM_CPU_SWITCH | MCPM_CPU_HOTPLUG);
+}
+
static int exynos_wait_for_powerdown(unsigned int cpu, unsigned int cluster)
{
unsigned int tries = 100;
@@ -250,11 +263,11 @@ static void exynos_suspend(u64 residency)
{
unsigned int mpidr, cpunr;
- exynos_power_down();
+ exynos_mcpm_power_down(residency);
/*
* Execution reaches here only if cpu did not power down.
- * Hence roll back the changes done in exynos_power_down function.
+ * Hence roll back the changes done in exynos_mcpm_power_down function.
*
* CAUTION: "This function requires the stack data to be visible through
* power down and can only be executed on processors like A15 and A7
@@ -319,10 +332,26 @@ static const struct of_device_id exynos_dt_mcpm_match[] = {
{},
};
+static void exynos_mcpm_setup_entry_point(void)
+{
+ /*
+ * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
+ * as part of secondary_cpu_start(). Let's redirect it to the
+ * mcpm_entry_point(). This is done during both secondary boot-up as
+ * well as system resume.
+ */
+ __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
+ __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
+ __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
+}
+
+static struct syscore_ops exynos_mcpm_syscore_ops = {
+ .resume = exynos_mcpm_setup_entry_point,
+};
+
static int __init exynos_mcpm_init(void)
{
struct device_node *node;
- void __iomem *ns_sram_base_addr;
unsigned int value, i;
int ret;
@@ -389,16 +418,9 @@ static int __init exynos_mcpm_init(void)
__raw_writel(value, pmu_base_addr + EXYNOS_COMMON_OPTION(i));
}
- /*
- * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
- * as part of secondary_cpu_start(). Let's redirect it to the
- * mcpm_entry_point().
- */
- __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
- __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
- __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
+ exynos_mcpm_setup_entry_point();
- iounmap(ns_sram_base_addr);
+ register_syscore_ops(&exynos_mcpm_syscore_ops);
return ret;
}
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index bf8564a..8b425df 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -24,6 +24,7 @@
#include <asm/cacheflush.h>
#include <asm/hardware/cache-l2x0.h>
+#include <asm/mcpm.h>
#include <asm/smp_scu.h>
#include <asm/suspend.h>
@@ -191,7 +192,6 @@ int exynos_cluster_power_state(int cluster)
pmu_base_addr + S5P_INFORM1))
#define S5P_CHECK_AFTR 0xFCBA0D10
-#define S5P_CHECK_SLEEP 0x00000BAD
/* Ext-GIC nIRQ/nFIQ is the only wakeup source in AFTR */
static void exynos_set_wakeupmask(long mask)
@@ -318,7 +318,10 @@ static void exynos_pm_prepare(void)
/* ensure at least INFORM0 has the resume address */
- pmu_raw_writel(virt_to_phys(exynos_cpu_resume), S5P_INFORM0);
+ if (soc_is_exynos5420() && IS_ENABLED(CONFIG_MCPM))
+ pmu_raw_writel(virt_to_phys(mcpm_entry_point), S5P_INFORM0);
+ else
+ pmu_raw_writel(virt_to_phys(exynos_cpu_resume), S5P_INFORM0);
if (soc_is_exynos5420()) {
tmp = __raw_readl(pmu_base_addr + EXYNOS5_ARM_L2_OPTION);
@@ -490,6 +493,28 @@ static struct syscore_ops exynos_pm_syscore_ops = {
.resume = exynos_pm_resume,
};
+static int notrace exynos_mcpm_cpu_suspend(unsigned long arg)
+{
+ /* MCPM works with HW CPU identifiers */
+ unsigned int mpidr = read_cpuid_mpidr();
+ unsigned int cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+ unsigned int cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+
+ __raw_writel(0x0, sysram_base_addr + EXYNOS5420_CPU_STATE);
+
+ mcpm_set_entry_vector(cpu, cluster, exynos_cpu_resume);
+
+ /*
+ * Residency value passed to mcpm_cpu_suspend back-end
+ * has to be given clear semantics. Set to 0 as a
+ * temporary value.
+ */
+ mcpm_cpu_suspend(MCPM_CPU_SUSPEND);
+
+ /* return value != 0 means failure */
+ return 1;
+}
+
/*
* Suspend Ops
*/
@@ -517,10 +542,17 @@ static int exynos_suspend_enter(suspend_state_t state)
flush_cache_all();
s3c_pm_check_store();
- ret = cpu_suspend(0, exynos_cpu_suspend);
+ /* Use the MCPM layer to suspend 5420 which is a multi-cluster SoC */
+ if (soc_is_exynos5420() && IS_ENABLED(CONFIG_MCPM))
+ ret = cpu_suspend(0, exynos_mcpm_cpu_suspend);
+ else
+ ret = cpu_suspend(0, exynos_cpu_suspend);
if (ret)
return ret;
+ if (soc_is_exynos5420() && IS_ENABLED(CONFIG_MCPM))
+ mcpm_cpu_powered_up();
+
s3c_pm_restore_uarts();
S3C_PMDBG("%s: wakeup stat: %08x\n", __func__,
diff --git a/arch/arm/mach-exynos/regs-pmu.h b/arch/arm/mach-exynos/regs-pmu.h
index 3cf0454..e8c75db 100644
--- a/arch/arm/mach-exynos/regs-pmu.h
+++ b/arch/arm/mach-exynos/regs-pmu.h
@@ -152,6 +152,7 @@
#define S5P_PAD_RET_EBIB_OPTION 0x31A8
#define S5P_CORE_LOCAL_PWR_EN 0x3
+#define S5P_CHECK_SLEEP 0x00000BAD
/* Only for EXYNOS4210 */
#define S5P_CMU_CLKSTOP_LCD1_LOWPWR 0x1154
diff --git a/drivers/cpuidle/cpuidle-big_little.c b/drivers/cpuidle/cpuidle-big_little.c
index b45fc62..15f077e 100644
--- a/drivers/cpuidle/cpuidle-big_little.c
+++ b/drivers/cpuidle/cpuidle-big_little.c
@@ -108,7 +108,7 @@ static int notrace bl_powerdown_finisher(unsigned long arg)
* has to be given clear semantics. Set to 0 as a
* temporary value.
*/
- mcpm_cpu_suspend(0);
+ mcpm_cpu_suspend(MCPM_CPU_IDLE);
/* return value != 0 means failure */
return 1;
--
1.7.9.5
^ permalink raw reply related [flat|nested] 130+ messages in thread
* [RFC PATCH v4] ARM: EXYNOS: Use MCPM call-backs to support S2R on Exynos5420
@ 2014-07-03 5:02 ` Abhilash Kesavan
0 siblings, 0 replies; 130+ messages in thread
From: Abhilash Kesavan @ 2014-07-03 5:02 UTC (permalink / raw)
To: linux-arm-kernel
Use the MCPM layer to handle core suspend/resume on Exynos5420.
Also, restore the entry address setup code post-resume.
Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
---
Changes in v2:
- Made use of the MCPM suspend/powered_up call-backs
Changes in v3:
- Used the residency value to indicate the entered state
Changes in v4:
- Checked if MCPM has been enabled to prevent build error
This has been tested both on an SMDK5420 and Peach Pit Chromebook on
3.16-rc3/next-20140702.
Here are the dependencies (some of these patches did not apply cleanly):
1) Cleanup patches for mach-exynos
http://comments.gmane.org/gmane.linux.kernel.samsung-soc/33772
2) PMU cleanup and refactoring for using DT
https://www.mail-archive.com/linux-kernel at vger.kernel.org/msg671625.html
3) Exynos5420 PMU/S2R Series
http://comments.gmane.org/gmane.linux.kernel.samsung-soc/33898
4) MCPM boot CPU CCI enablement patches
www.spinics.net/lists/linux-samsung-soc/msg32923.html
5) Exynos5420 CPUIdle Series which populates MCPM suspend/powered_up
call-backs.
www.gossamer-threads.com/lists/linux/kernel/1945347
https://patchwork.kernel.org/patch/4357461/
6) Exynos5420 MCPM cluster power down support
http://www.spinics.net/lists/arm-kernel/msg339988.html
7) TPM reset mask patch
http://www.spinics.net/lists/arm-kernel/msg341884.html
arch/arm/include/asm/mcpm.h | 6 ++++
arch/arm/mach-exynos/mcpm-exynos.c | 50 ++++++++++++++++++++++++----------
arch/arm/mach-exynos/pm.c | 38 ++++++++++++++++++++++++--
arch/arm/mach-exynos/regs-pmu.h | 1 +
drivers/cpuidle/cpuidle-big_little.c | 2 +-
5 files changed, 79 insertions(+), 18 deletions(-)
diff --git a/arch/arm/include/asm/mcpm.h b/arch/arm/include/asm/mcpm.h
index ff73aff..051fbf1 100644
--- a/arch/arm/include/asm/mcpm.h
+++ b/arch/arm/include/asm/mcpm.h
@@ -272,4 +272,10 @@ void __init mcpm_smp_set_ops(void);
#define MCPM_SYNC_CLUSTER_SIZE \
(MCPM_SYNC_CLUSTER_INBOUND + __CACHE_WRITEBACK_GRANULE)
+/* Definitions for various MCPM scenarios that might need special handling */
+#define MCPM_CPU_IDLE 0x0
+#define MCPM_CPU_SUSPEND 0x1
+#define MCPM_CPU_SWITCH 0x2
+#define MCPM_CPU_HOTPLUG 0x3
+
#endif
diff --git a/arch/arm/mach-exynos/mcpm-exynos.c b/arch/arm/mach-exynos/mcpm-exynos.c
index 0315601..9a381f6 100644
--- a/arch/arm/mach-exynos/mcpm-exynos.c
+++ b/arch/arm/mach-exynos/mcpm-exynos.c
@@ -15,6 +15,7 @@
#include <linux/delay.h>
#include <linux/io.h>
#include <linux/of_address.h>
+#include <linux/syscore_ops.h>
#include <asm/cputype.h>
#include <asm/cp15.h>
@@ -30,6 +31,8 @@
#define EXYNOS5420_USE_ARM_CORE_DOWN_STATE BIT(29)
#define EXYNOS5420_USE_L2_COMMON_UP_STATE BIT(30)
+static void __iomem *ns_sram_base_addr;
+
/*
* The common v7_exit_coherency_flush API could not be used because of the
* Erratum 799270 workaround. This macro is the same as the common one (in
@@ -129,7 +132,7 @@ static int exynos_power_up(unsigned int cpu, unsigned int cluster)
* and can only be executed on processors like A15 and A7 that hit the cache
* with the C bit clear in the SCTLR register.
*/
-static void exynos_power_down(void)
+static void exynos_mcpm_power_down(u64 residency)
{
unsigned int mpidr, cpu, cluster;
bool last_man = false, skip_wfi = false;
@@ -150,7 +153,12 @@ static void exynos_power_down(void)
BUG_ON(__mcpm_cluster_state(cluster) != CLUSTER_UP);
cpu_use_count[cpu][cluster]--;
if (cpu_use_count[cpu][cluster] == 0) {
- exynos_cpu_power_down(cpunr);
+ /*
+ * Bypass power down for CPU0 during suspend. This is being
+ * taken care by the SYS_PWR_CFG bit in CORE0_SYS_PWR_REG.
+ */
+ if ((cpunr != 0) || (residency != MCPM_CPU_SUSPEND))
+ exynos_cpu_power_down(cpunr);
if (exynos_cluster_unused(cluster)) {
exynos_cluster_power_down(cluster);
@@ -209,6 +217,11 @@ static void exynos_power_down(void)
/* Not dead at this point? Let our caller cope. */
}
+static void exynos_power_down(void)
+{
+ exynos_mcpm_power_down(MCPM_CPU_SWITCH | MCPM_CPU_HOTPLUG);
+}
+
static int exynos_wait_for_powerdown(unsigned int cpu, unsigned int cluster)
{
unsigned int tries = 100;
@@ -250,11 +263,11 @@ static void exynos_suspend(u64 residency)
{
unsigned int mpidr, cpunr;
- exynos_power_down();
+ exynos_mcpm_power_down(residency);
/*
* Execution reaches here only if cpu did not power down.
- * Hence roll back the changes done in exynos_power_down function.
+ * Hence roll back the changes done in exynos_mcpm_power_down function.
*
* CAUTION: "This function requires the stack data to be visible through
* power down and can only be executed on processors like A15 and A7
@@ -319,10 +332,26 @@ static const struct of_device_id exynos_dt_mcpm_match[] = {
{},
};
+static void exynos_mcpm_setup_entry_point(void)
+{
+ /*
+ * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
+ * as part of secondary_cpu_start(). Let's redirect it to the
+ * mcpm_entry_point(). This is done during both secondary boot-up as
+ * well as system resume.
+ */
+ __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
+ __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
+ __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
+}
+
+static struct syscore_ops exynos_mcpm_syscore_ops = {
+ .resume = exynos_mcpm_setup_entry_point,
+};
+
static int __init exynos_mcpm_init(void)
{
struct device_node *node;
- void __iomem *ns_sram_base_addr;
unsigned int value, i;
int ret;
@@ -389,16 +418,9 @@ static int __init exynos_mcpm_init(void)
__raw_writel(value, pmu_base_addr + EXYNOS_COMMON_OPTION(i));
}
- /*
- * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
- * as part of secondary_cpu_start(). Let's redirect it to the
- * mcpm_entry_point().
- */
- __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
- __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
- __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
+ exynos_mcpm_setup_entry_point();
- iounmap(ns_sram_base_addr);
+ register_syscore_ops(&exynos_mcpm_syscore_ops);
return ret;
}
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index bf8564a..8b425df 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -24,6 +24,7 @@
#include <asm/cacheflush.h>
#include <asm/hardware/cache-l2x0.h>
+#include <asm/mcpm.h>
#include <asm/smp_scu.h>
#include <asm/suspend.h>
@@ -191,7 +192,6 @@ int exynos_cluster_power_state(int cluster)
pmu_base_addr + S5P_INFORM1))
#define S5P_CHECK_AFTR 0xFCBA0D10
-#define S5P_CHECK_SLEEP 0x00000BAD
/* Ext-GIC nIRQ/nFIQ is the only wakeup source in AFTR */
static void exynos_set_wakeupmask(long mask)
@@ -318,7 +318,10 @@ static void exynos_pm_prepare(void)
/* ensure at least INFORM0 has the resume address */
- pmu_raw_writel(virt_to_phys(exynos_cpu_resume), S5P_INFORM0);
+ if (soc_is_exynos5420() && IS_ENABLED(CONFIG_MCPM))
+ pmu_raw_writel(virt_to_phys(mcpm_entry_point), S5P_INFORM0);
+ else
+ pmu_raw_writel(virt_to_phys(exynos_cpu_resume), S5P_INFORM0);
if (soc_is_exynos5420()) {
tmp = __raw_readl(pmu_base_addr + EXYNOS5_ARM_L2_OPTION);
@@ -490,6 +493,28 @@ static struct syscore_ops exynos_pm_syscore_ops = {
.resume = exynos_pm_resume,
};
+static int notrace exynos_mcpm_cpu_suspend(unsigned long arg)
+{
+ /* MCPM works with HW CPU identifiers */
+ unsigned int mpidr = read_cpuid_mpidr();
+ unsigned int cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+ unsigned int cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+
+ __raw_writel(0x0, sysram_base_addr + EXYNOS5420_CPU_STATE);
+
+ mcpm_set_entry_vector(cpu, cluster, exynos_cpu_resume);
+
+ /*
+ * Residency value passed to mcpm_cpu_suspend back-end
+ * has to be given clear semantics. Set to 0 as a
+ * temporary value.
+ */
+ mcpm_cpu_suspend(MCPM_CPU_SUSPEND);
+
+ /* return value != 0 means failure */
+ return 1;
+}
+
/*
* Suspend Ops
*/
@@ -517,10 +542,17 @@ static int exynos_suspend_enter(suspend_state_t state)
flush_cache_all();
s3c_pm_check_store();
- ret = cpu_suspend(0, exynos_cpu_suspend);
+ /* Use the MCPM layer to suspend 5420 which is a multi-cluster SoC */
+ if (soc_is_exynos5420() && IS_ENABLED(CONFIG_MCPM))
+ ret = cpu_suspend(0, exynos_mcpm_cpu_suspend);
+ else
+ ret = cpu_suspend(0, exynos_cpu_suspend);
if (ret)
return ret;
+ if (soc_is_exynos5420() && IS_ENABLED(CONFIG_MCPM))
+ mcpm_cpu_powered_up();
+
s3c_pm_restore_uarts();
S3C_PMDBG("%s: wakeup stat: %08x\n", __func__,
diff --git a/arch/arm/mach-exynos/regs-pmu.h b/arch/arm/mach-exynos/regs-pmu.h
index 3cf0454..e8c75db 100644
--- a/arch/arm/mach-exynos/regs-pmu.h
+++ b/arch/arm/mach-exynos/regs-pmu.h
@@ -152,6 +152,7 @@
#define S5P_PAD_RET_EBIB_OPTION 0x31A8
#define S5P_CORE_LOCAL_PWR_EN 0x3
+#define S5P_CHECK_SLEEP 0x00000BAD
/* Only for EXYNOS4210 */
#define S5P_CMU_CLKSTOP_LCD1_LOWPWR 0x1154
diff --git a/drivers/cpuidle/cpuidle-big_little.c b/drivers/cpuidle/cpuidle-big_little.c
index b45fc62..15f077e 100644
--- a/drivers/cpuidle/cpuidle-big_little.c
+++ b/drivers/cpuidle/cpuidle-big_little.c
@@ -108,7 +108,7 @@ static int notrace bl_powerdown_finisher(unsigned long arg)
* has to be given clear semantics. Set to 0 as a
* temporary value.
*/
- mcpm_cpu_suspend(0);
+ mcpm_cpu_suspend(MCPM_CPU_IDLE);
/* return value != 0 means failure */
return 1;
--
1.7.9.5
^ permalink raw reply related [flat|nested] 130+ messages in thread
* Re: [RFC PATCH v4] ARM: EXYNOS: Use MCPM call-backs to support S2R on Exynos5420
2014-07-03 5:02 ` Abhilash Kesavan
@ 2014-07-03 13:29 ` Nicolas Pitre
-1 siblings, 0 replies; 130+ messages in thread
From: Nicolas Pitre @ 2014-07-03 13:29 UTC (permalink / raw)
To: Abhilash Kesavan
Cc: linux-samsung-soc, linux-arm-kernel, kgene.kim,
lorenzo.pieralisi, kesavan.abhilash, abrestic, dianders
On Thu, 3 Jul 2014, Abhilash Kesavan wrote:
> Use the MCPM layer to handle core suspend/resume on Exynos5420.
> Also, restore the entry address setup code post-resume.
>
> Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
> ---
> Changes in v2:
> - Made use of the MCPM suspend/powered_up call-backs
> Changes in v3:
> - Used the residency value to indicate the entered state
> Changes in v4:
> - Checked if MCPM has been enabled to prevent build error
>
> This has been tested both on an SMDK5420 and Peach Pit Chromebook on
> 3.16-rc3/next-20140702.
>
> Here are the dependencies (some of these patches did not apply cleanly):
> 1) Cleanup patches for mach-exynos
> http://comments.gmane.org/gmane.linux.kernel.samsung-soc/33772
>
> 2) PMU cleanup and refactoring for using DT
> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg671625.html
>
> 3) Exynos5420 PMU/S2R Series
> http://comments.gmane.org/gmane.linux.kernel.samsung-soc/33898
>
> 4) MCPM boot CPU CCI enablement patches
> www.spinics.net/lists/linux-samsung-soc/msg32923.html
>
> 5) Exynos5420 CPUIdle Series which populates MCPM suspend/powered_up
> call-backs.
> www.gossamer-threads.com/lists/linux/kernel/1945347
> https://patchwork.kernel.org/patch/4357461/
>
> 6) Exynos5420 MCPM cluster power down support
> http://www.spinics.net/lists/arm-kernel/msg339988.html
>
> 7) TPM reset mask patch
> http://www.spinics.net/lists/arm-kernel/msg341884.html
>
> arch/arm/include/asm/mcpm.h | 6 ++++
> arch/arm/mach-exynos/mcpm-exynos.c | 50 ++++++++++++++++++++++++----------
> arch/arm/mach-exynos/pm.c | 38 ++++++++++++++++++++++++--
> arch/arm/mach-exynos/regs-pmu.h | 1 +
> drivers/cpuidle/cpuidle-big_little.c | 2 +-
> 5 files changed, 79 insertions(+), 18 deletions(-)
>
> diff --git a/arch/arm/include/asm/mcpm.h b/arch/arm/include/asm/mcpm.h
> index ff73aff..051fbf1 100644
> --- a/arch/arm/include/asm/mcpm.h
> +++ b/arch/arm/include/asm/mcpm.h
> @@ -272,4 +272,10 @@ void __init mcpm_smp_set_ops(void);
> #define MCPM_SYNC_CLUSTER_SIZE \
> (MCPM_SYNC_CLUSTER_INBOUND + __CACHE_WRITEBACK_GRANULE)
>
> +/* Definitions for various MCPM scenarios that might need special handling */
> +#define MCPM_CPU_IDLE 0x0
> +#define MCPM_CPU_SUSPEND 0x1
> +#define MCPM_CPU_SWITCH 0x2
> +#define MCPM_CPU_HOTPLUG 0x3
Please, let's avoid going that route. There is no such special handling
needed if the API is sufficient. And the provided API allows you to
suspend a CPU or shut it down. It shouldn't matter at that level if
this is due to a cluster switch or a hotplug event. Do you really need
something else?
[...]
> @@ -129,7 +132,7 @@ static int exynos_power_up(unsigned int cpu, unsigned int cluster)
> * and can only be executed on processors like A15 and A7 that hit the cache
> * with the C bit clear in the SCTLR register.
> */
> -static void exynos_power_down(void)
> +static void exynos_mcpm_power_down(u64 residency)
> {
> unsigned int mpidr, cpu, cluster;
> bool last_man = false, skip_wfi = false;
> @@ -150,7 +153,12 @@ static void exynos_power_down(void)
> BUG_ON(__mcpm_cluster_state(cluster) != CLUSTER_UP);
> cpu_use_count[cpu][cluster]--;
> if (cpu_use_count[cpu][cluster] == 0) {
> - exynos_cpu_power_down(cpunr);
> + /*
> + * Bypass power down for CPU0 during suspend. This is being
> + * taken care by the SYS_PWR_CFG bit in CORE0_SYS_PWR_REG.
> + */
> + if ((cpunr != 0) || (residency != MCPM_CPU_SUSPEND))
> + exynos_cpu_power_down(cpunr);
>
> if (exynos_cluster_unused(cluster)) {
> exynos_cluster_power_down(cluster);
> @@ -209,6 +217,11 @@ static void exynos_power_down(void)
> /* Not dead at this point? Let our caller cope. */
> }
>
> +static void exynos_power_down(void)
> +{
> + exynos_mcpm_power_down(MCPM_CPU_SWITCH | MCPM_CPU_HOTPLUG);
> +}
To distinguish between a suspend and a power-down, you can simply use
exynos_power_down() as your common handler, and have
exynos_mcpm_power_down() and exynos_mcpm_suspend() as wrappers around it
passing the appropriate private flags with local meanings.
Nicolas
^ permalink raw reply [flat|nested] 130+ messages in thread
* [RFC PATCH v4] ARM: EXYNOS: Use MCPM call-backs to support S2R on Exynos5420
@ 2014-07-03 13:29 ` Nicolas Pitre
0 siblings, 0 replies; 130+ messages in thread
From: Nicolas Pitre @ 2014-07-03 13:29 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, 3 Jul 2014, Abhilash Kesavan wrote:
> Use the MCPM layer to handle core suspend/resume on Exynos5420.
> Also, restore the entry address setup code post-resume.
>
> Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
> ---
> Changes in v2:
> - Made use of the MCPM suspend/powered_up call-backs
> Changes in v3:
> - Used the residency value to indicate the entered state
> Changes in v4:
> - Checked if MCPM has been enabled to prevent build error
>
> This has been tested both on an SMDK5420 and Peach Pit Chromebook on
> 3.16-rc3/next-20140702.
>
> Here are the dependencies (some of these patches did not apply cleanly):
> 1) Cleanup patches for mach-exynos
> http://comments.gmane.org/gmane.linux.kernel.samsung-soc/33772
>
> 2) PMU cleanup and refactoring for using DT
> https://www.mail-archive.com/linux-kernel at vger.kernel.org/msg671625.html
>
> 3) Exynos5420 PMU/S2R Series
> http://comments.gmane.org/gmane.linux.kernel.samsung-soc/33898
>
> 4) MCPM boot CPU CCI enablement patches
> www.spinics.net/lists/linux-samsung-soc/msg32923.html
>
> 5) Exynos5420 CPUIdle Series which populates MCPM suspend/powered_up
> call-backs.
> www.gossamer-threads.com/lists/linux/kernel/1945347
> https://patchwork.kernel.org/patch/4357461/
>
> 6) Exynos5420 MCPM cluster power down support
> http://www.spinics.net/lists/arm-kernel/msg339988.html
>
> 7) TPM reset mask patch
> http://www.spinics.net/lists/arm-kernel/msg341884.html
>
> arch/arm/include/asm/mcpm.h | 6 ++++
> arch/arm/mach-exynos/mcpm-exynos.c | 50 ++++++++++++++++++++++++----------
> arch/arm/mach-exynos/pm.c | 38 ++++++++++++++++++++++++--
> arch/arm/mach-exynos/regs-pmu.h | 1 +
> drivers/cpuidle/cpuidle-big_little.c | 2 +-
> 5 files changed, 79 insertions(+), 18 deletions(-)
>
> diff --git a/arch/arm/include/asm/mcpm.h b/arch/arm/include/asm/mcpm.h
> index ff73aff..051fbf1 100644
> --- a/arch/arm/include/asm/mcpm.h
> +++ b/arch/arm/include/asm/mcpm.h
> @@ -272,4 +272,10 @@ void __init mcpm_smp_set_ops(void);
> #define MCPM_SYNC_CLUSTER_SIZE \
> (MCPM_SYNC_CLUSTER_INBOUND + __CACHE_WRITEBACK_GRANULE)
>
> +/* Definitions for various MCPM scenarios that might need special handling */
> +#define MCPM_CPU_IDLE 0x0
> +#define MCPM_CPU_SUSPEND 0x1
> +#define MCPM_CPU_SWITCH 0x2
> +#define MCPM_CPU_HOTPLUG 0x3
Please, let's avoid going that route. There is no such special handling
needed if the API is sufficient. And the provided API allows you to
suspend a CPU or shut it down. It shouldn't matter at that level if
this is due to a cluster switch or a hotplug event. Do you really need
something else?
[...]
> @@ -129,7 +132,7 @@ static int exynos_power_up(unsigned int cpu, unsigned int cluster)
> * and can only be executed on processors like A15 and A7 that hit the cache
> * with the C bit clear in the SCTLR register.
> */
> -static void exynos_power_down(void)
> +static void exynos_mcpm_power_down(u64 residency)
> {
> unsigned int mpidr, cpu, cluster;
> bool last_man = false, skip_wfi = false;
> @@ -150,7 +153,12 @@ static void exynos_power_down(void)
> BUG_ON(__mcpm_cluster_state(cluster) != CLUSTER_UP);
> cpu_use_count[cpu][cluster]--;
> if (cpu_use_count[cpu][cluster] == 0) {
> - exynos_cpu_power_down(cpunr);
> + /*
> + * Bypass power down for CPU0 during suspend. This is being
> + * taken care by the SYS_PWR_CFG bit in CORE0_SYS_PWR_REG.
> + */
> + if ((cpunr != 0) || (residency != MCPM_CPU_SUSPEND))
> + exynos_cpu_power_down(cpunr);
>
> if (exynos_cluster_unused(cluster)) {
> exynos_cluster_power_down(cluster);
> @@ -209,6 +217,11 @@ static void exynos_power_down(void)
> /* Not dead at this point? Let our caller cope. */
> }
>
> +static void exynos_power_down(void)
> +{
> + exynos_mcpm_power_down(MCPM_CPU_SWITCH | MCPM_CPU_HOTPLUG);
> +}
To distinguish between a suspend and a power-down, you can simply use
exynos_power_down() as your common handler, and have
exynos_mcpm_power_down() and exynos_mcpm_suspend() as wrappers around it
passing the appropriate private flags with local meanings.
Nicolas
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: [RFC PATCH v4] ARM: EXYNOS: Use MCPM call-backs to support S2R on Exynos5420
2014-07-03 13:29 ` Nicolas Pitre
@ 2014-07-03 14:46 ` Abhilash Kesavan
-1 siblings, 0 replies; 130+ messages in thread
From: Abhilash Kesavan @ 2014-07-03 14:46 UTC (permalink / raw)
To: Nicolas Pitre
Cc: linux-samsung-soc, linux-arm-kernel, Kukjin Kim,
Lorenzo Pieralisi, Andrew Bresticker, Douglas Anderson
Hi Nicolas,
On Thu, Jul 3, 2014 at 6:59 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> On Thu, 3 Jul 2014, Abhilash Kesavan wrote:
>
>> Use the MCPM layer to handle core suspend/resume on Exynos5420.
>> Also, restore the entry address setup code post-resume.
>>
>> Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
>> ---
>> Changes in v2:
>> - Made use of the MCPM suspend/powered_up call-backs
>> Changes in v3:
>> - Used the residency value to indicate the entered state
>> Changes in v4:
>> - Checked if MCPM has been enabled to prevent build error
>>
>> This has been tested both on an SMDK5420 and Peach Pit Chromebook on
>> 3.16-rc3/next-20140702.
>>
>> Here are the dependencies (some of these patches did not apply cleanly):
>> 1) Cleanup patches for mach-exynos
>> http://comments.gmane.org/gmane.linux.kernel.samsung-soc/33772
>>
>> 2) PMU cleanup and refactoring for using DT
>> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg671625.html
>>
>> 3) Exynos5420 PMU/S2R Series
>> http://comments.gmane.org/gmane.linux.kernel.samsung-soc/33898
>>
>> 4) MCPM boot CPU CCI enablement patches
>> www.spinics.net/lists/linux-samsung-soc/msg32923.html
>>
>> 5) Exynos5420 CPUIdle Series which populates MCPM suspend/powered_up
>> call-backs.
>> www.gossamer-threads.com/lists/linux/kernel/1945347
>> https://patchwork.kernel.org/patch/4357461/
>>
>> 6) Exynos5420 MCPM cluster power down support
>> http://www.spinics.net/lists/arm-kernel/msg339988.html
>>
>> 7) TPM reset mask patch
>> http://www.spinics.net/lists/arm-kernel/msg341884.html
>>
>> arch/arm/include/asm/mcpm.h | 6 ++++
>> arch/arm/mach-exynos/mcpm-exynos.c | 50 ++++++++++++++++++++++++----------
>> arch/arm/mach-exynos/pm.c | 38 ++++++++++++++++++++++++--
>> arch/arm/mach-exynos/regs-pmu.h | 1 +
>> drivers/cpuidle/cpuidle-big_little.c | 2 +-
>> 5 files changed, 79 insertions(+), 18 deletions(-)
>>
>> diff --git a/arch/arm/include/asm/mcpm.h b/arch/arm/include/asm/mcpm.h
>> index ff73aff..051fbf1 100644
>> --- a/arch/arm/include/asm/mcpm.h
>> +++ b/arch/arm/include/asm/mcpm.h
>> @@ -272,4 +272,10 @@ void __init mcpm_smp_set_ops(void);
>> #define MCPM_SYNC_CLUSTER_SIZE \
>> (MCPM_SYNC_CLUSTER_INBOUND + __CACHE_WRITEBACK_GRANULE)
>>
>> +/* Definitions for various MCPM scenarios that might need special handling */
>> +#define MCPM_CPU_IDLE 0x0
>> +#define MCPM_CPU_SUSPEND 0x1
>> +#define MCPM_CPU_SWITCH 0x2
>> +#define MCPM_CPU_HOTPLUG 0x3
>
> Please, let's avoid going that route. There is no such special handling
> needed if the API is sufficient. And the provided API allows you to
> suspend a CPU or shut it down. It shouldn't matter at that level if
> this is due to a cluster switch or a hotplug event. Do you really need
> something else?
No, just one local flag for suspend should be enough for me. Will remove these.
>
> [...]
>> @@ -129,7 +132,7 @@ static int exynos_power_up(unsigned int cpu, unsigned int cluster)
>> * and can only be executed on processors like A15 and A7 that hit the cache
>> * with the C bit clear in the SCTLR register.
>> */
>> -static void exynos_power_down(void)
>> +static void exynos_mcpm_power_down(u64 residency)
>> {
>> unsigned int mpidr, cpu, cluster;
>> bool last_man = false, skip_wfi = false;
>> @@ -150,7 +153,12 @@ static void exynos_power_down(void)
>> BUG_ON(__mcpm_cluster_state(cluster) != CLUSTER_UP);
>> cpu_use_count[cpu][cluster]--;
>> if (cpu_use_count[cpu][cluster] == 0) {
>> - exynos_cpu_power_down(cpunr);
>> + /*
>> + * Bypass power down for CPU0 during suspend. This is being
>> + * taken care by the SYS_PWR_CFG bit in CORE0_SYS_PWR_REG.
>> + */
>> + if ((cpunr != 0) || (residency != MCPM_CPU_SUSPEND))
>> + exynos_cpu_power_down(cpunr);
>>
>> if (exynos_cluster_unused(cluster)) {
>> exynos_cluster_power_down(cluster);
>> @@ -209,6 +217,11 @@ static void exynos_power_down(void)
>> /* Not dead at this point? Let our caller cope. */
>> }
>>
>> +static void exynos_power_down(void)
>> +{
>> + exynos_mcpm_power_down(MCPM_CPU_SWITCH | MCPM_CPU_HOTPLUG);
>> +}
>
> To distinguish between a suspend and a power-down, you can simply use
> exynos_power_down() as your common handler, and have
> exynos_mcpm_power_down() and exynos_mcpm_suspend() as wrappers around it
> passing the appropriate private flags with local meanings.
My patch is in line with your explanation, except it makes use of the
new MCPM flags. I will clean those out and just use one flag for
suspend instead. Please check the v5 patch that I will post in a bit
in case I have missed something.
Regards,
Abhilash
>
>
> Nicolas
>
^ permalink raw reply [flat|nested] 130+ messages in thread
* [RFC PATCH v4] ARM: EXYNOS: Use MCPM call-backs to support S2R on Exynos5420
@ 2014-07-03 14:46 ` Abhilash Kesavan
0 siblings, 0 replies; 130+ messages in thread
From: Abhilash Kesavan @ 2014-07-03 14:46 UTC (permalink / raw)
To: linux-arm-kernel
Hi Nicolas,
On Thu, Jul 3, 2014 at 6:59 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> On Thu, 3 Jul 2014, Abhilash Kesavan wrote:
>
>> Use the MCPM layer to handle core suspend/resume on Exynos5420.
>> Also, restore the entry address setup code post-resume.
>>
>> Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
>> ---
>> Changes in v2:
>> - Made use of the MCPM suspend/powered_up call-backs
>> Changes in v3:
>> - Used the residency value to indicate the entered state
>> Changes in v4:
>> - Checked if MCPM has been enabled to prevent build error
>>
>> This has been tested both on an SMDK5420 and Peach Pit Chromebook on
>> 3.16-rc3/next-20140702.
>>
>> Here are the dependencies (some of these patches did not apply cleanly):
>> 1) Cleanup patches for mach-exynos
>> http://comments.gmane.org/gmane.linux.kernel.samsung-soc/33772
>>
>> 2) PMU cleanup and refactoring for using DT
>> https://www.mail-archive.com/linux-kernel at vger.kernel.org/msg671625.html
>>
>> 3) Exynos5420 PMU/S2R Series
>> http://comments.gmane.org/gmane.linux.kernel.samsung-soc/33898
>>
>> 4) MCPM boot CPU CCI enablement patches
>> www.spinics.net/lists/linux-samsung-soc/msg32923.html
>>
>> 5) Exynos5420 CPUIdle Series which populates MCPM suspend/powered_up
>> call-backs.
>> www.gossamer-threads.com/lists/linux/kernel/1945347
>> https://patchwork.kernel.org/patch/4357461/
>>
>> 6) Exynos5420 MCPM cluster power down support
>> http://www.spinics.net/lists/arm-kernel/msg339988.html
>>
>> 7) TPM reset mask patch
>> http://www.spinics.net/lists/arm-kernel/msg341884.html
>>
>> arch/arm/include/asm/mcpm.h | 6 ++++
>> arch/arm/mach-exynos/mcpm-exynos.c | 50 ++++++++++++++++++++++++----------
>> arch/arm/mach-exynos/pm.c | 38 ++++++++++++++++++++++++--
>> arch/arm/mach-exynos/regs-pmu.h | 1 +
>> drivers/cpuidle/cpuidle-big_little.c | 2 +-
>> 5 files changed, 79 insertions(+), 18 deletions(-)
>>
>> diff --git a/arch/arm/include/asm/mcpm.h b/arch/arm/include/asm/mcpm.h
>> index ff73aff..051fbf1 100644
>> --- a/arch/arm/include/asm/mcpm.h
>> +++ b/arch/arm/include/asm/mcpm.h
>> @@ -272,4 +272,10 @@ void __init mcpm_smp_set_ops(void);
>> #define MCPM_SYNC_CLUSTER_SIZE \
>> (MCPM_SYNC_CLUSTER_INBOUND + __CACHE_WRITEBACK_GRANULE)
>>
>> +/* Definitions for various MCPM scenarios that might need special handling */
>> +#define MCPM_CPU_IDLE 0x0
>> +#define MCPM_CPU_SUSPEND 0x1
>> +#define MCPM_CPU_SWITCH 0x2
>> +#define MCPM_CPU_HOTPLUG 0x3
>
> Please, let's avoid going that route. There is no such special handling
> needed if the API is sufficient. And the provided API allows you to
> suspend a CPU or shut it down. It shouldn't matter at that level if
> this is due to a cluster switch or a hotplug event. Do you really need
> something else?
No, just one local flag for suspend should be enough for me. Will remove these.
>
> [...]
>> @@ -129,7 +132,7 @@ static int exynos_power_up(unsigned int cpu, unsigned int cluster)
>> * and can only be executed on processors like A15 and A7 that hit the cache
>> * with the C bit clear in the SCTLR register.
>> */
>> -static void exynos_power_down(void)
>> +static void exynos_mcpm_power_down(u64 residency)
>> {
>> unsigned int mpidr, cpu, cluster;
>> bool last_man = false, skip_wfi = false;
>> @@ -150,7 +153,12 @@ static void exynos_power_down(void)
>> BUG_ON(__mcpm_cluster_state(cluster) != CLUSTER_UP);
>> cpu_use_count[cpu][cluster]--;
>> if (cpu_use_count[cpu][cluster] == 0) {
>> - exynos_cpu_power_down(cpunr);
>> + /*
>> + * Bypass power down for CPU0 during suspend. This is being
>> + * taken care by the SYS_PWR_CFG bit in CORE0_SYS_PWR_REG.
>> + */
>> + if ((cpunr != 0) || (residency != MCPM_CPU_SUSPEND))
>> + exynos_cpu_power_down(cpunr);
>>
>> if (exynos_cluster_unused(cluster)) {
>> exynos_cluster_power_down(cluster);
>> @@ -209,6 +217,11 @@ static void exynos_power_down(void)
>> /* Not dead at this point? Let our caller cope. */
>> }
>>
>> +static void exynos_power_down(void)
>> +{
>> + exynos_mcpm_power_down(MCPM_CPU_SWITCH | MCPM_CPU_HOTPLUG);
>> +}
>
> To distinguish between a suspend and a power-down, you can simply use
> exynos_power_down() as your common handler, and have
> exynos_mcpm_power_down() and exynos_mcpm_suspend() as wrappers around it
> passing the appropriate private flags with local meanings.
My patch is in line with your explanation, except it makes use of the
new MCPM flags. I will clean those out and just use one flag for
suspend instead. Please check the v5 patch that I will post in a bit
in case I have missed something.
Regards,
Abhilash
>
>
> Nicolas
>
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH v5] ARM: EXYNOS: Use MCPM call-backs to support S2R on Exynos5420
2014-07-03 5:02 ` Abhilash Kesavan
@ 2014-07-03 14:46 ` Abhilash Kesavan
-1 siblings, 0 replies; 130+ messages in thread
From: Abhilash Kesavan @ 2014-07-03 14:46 UTC (permalink / raw)
To: linux-samsung-soc, linux-arm-kernel, kgene.kim, nicolas.pitre,
lorenzo.pieralisi
Cc: abrestic, dianders, kesavan.abhilash
Use the MCPM layer to handle core suspend/resume on Exynos5420.
Also, restore the entry address setup code post-resume.
Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
---
Changes in v2:
- Made use of the MCPM suspend/powered_up call-backs
Changes in v3:
- Used the residency value to indicate the entered state
Changes in v4:
- Checked if MCPM has been enabled to prevent build error
Changes in v5:
- Removed the MCPM flags and just used a local flag to
indicate that we are suspending.
This has been tested both on an SMDK5420 and Peach Pit Chromebook on
3.16-rc3/next-20140702.
Here are the dependencies (some of these patches did not apply cleanly):
1) Cleanup patches for mach-exynos
http://comments.gmane.org/gmane.linux.kernel.samsung-soc/33772
2) PMU cleanup and refactoring for using DT
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg671625.html
3) Exynos5420 PMU/S2R Series
http://comments.gmane.org/gmane.linux.kernel.samsung-soc/33898
4) MCPM boot CPU CCI enablement patches
www.spinics.net/lists/linux-samsung-soc/msg32923.html
5) Exynos5420 CPUIdle Series which populates MCPM suspend/powered_up
call-backs.
www.gossamer-threads.com/lists/linux/kernel/1945347
https://patchwork.kernel.org/patch/4357461/
6) Exynos5420 MCPM cluster power down support
http://www.spinics.net/lists/arm-kernel/msg339988.html
7) TPM reset mask patch
http://www.spinics.net/lists/arm-kernel/msg341884.html
arch/arm/mach-exynos/mcpm-exynos.c | 50 +++++++++++++++++++++++++++-----------
arch/arm/mach-exynos/pm.c | 37 +++++++++++++++++++++++++---
arch/arm/mach-exynos/regs-pmu.h | 1 +
3 files changed, 71 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-exynos/mcpm-exynos.c b/arch/arm/mach-exynos/mcpm-exynos.c
index 2dd51cc..60f84c9 100644
--- a/arch/arm/mach-exynos/mcpm-exynos.c
+++ b/arch/arm/mach-exynos/mcpm-exynos.c
@@ -15,6 +15,7 @@
#include <linux/delay.h>
#include <linux/io.h>
#include <linux/of_address.h>
+#include <linux/syscore_ops.h>
#include <asm/cputype.h>
#include <asm/cp15.h>
@@ -30,6 +31,8 @@
#define EXYNOS5420_USE_ARM_CORE_DOWN_STATE BIT(29)
#define EXYNOS5420_USE_L2_COMMON_UP_STATE BIT(30)
+static void __iomem *ns_sram_base_addr;
+
/*
* The common v7_exit_coherency_flush API could not be used because of the
* Erratum 799270 workaround. This macro is the same as the common one (in
@@ -129,7 +132,7 @@ static int exynos_power_up(unsigned int cpu, unsigned int cluster)
* and can only be executed on processors like A15 and A7 that hit the cache
* with the C bit clear in the SCTLR register.
*/
-static void exynos_power_down(void)
+static void exynos_mcpm_power_down(u64 residency)
{
unsigned int mpidr, cpu, cluster;
bool last_man = false, skip_wfi = false;
@@ -150,7 +153,12 @@ static void exynos_power_down(void)
BUG_ON(__mcpm_cluster_state(cluster) != CLUSTER_UP);
cpu_use_count[cpu][cluster]--;
if (cpu_use_count[cpu][cluster] == 0) {
- exynos_cpu_power_down(cpunr);
+ /*
+ * Bypass power down for CPU0 during suspend. This is being
+ * taken care by the SYS_PWR_CFG bit in CORE0_SYS_PWR_REG.
+ */
+ if ((cpunr != 0) || (residency != S5P_CHECK_SLEEP))
+ exynos_cpu_power_down(cpunr);
if (exynos_cluster_unused(cluster)) {
exynos_cluster_power_down(cluster);
@@ -209,6 +217,11 @@ static void exynos_power_down(void)
/* Not dead at this point? Let our caller cope. */
}
+static void exynos_power_down(void)
+{
+ exynos_mcpm_power_down(0);
+}
+
static int exynos_wait_for_powerdown(unsigned int cpu, unsigned int cluster)
{
unsigned int tries = 100;
@@ -250,11 +263,11 @@ static void exynos_suspend(u64 residency)
{
unsigned int mpidr, cpunr;
- exynos_power_down();
+ exynos_mcpm_power_down(residency);
/*
* Execution reaches here only if cpu did not power down.
- * Hence roll back the changes done in exynos_power_down function.
+ * Hence roll back the changes done in exynos_mcpm_power_down function.
*
* CAUTION: "This function requires the stack data to be visible through
* power down and can only be executed on processors like A15 and A7
@@ -319,10 +332,26 @@ static const struct of_device_id exynos_dt_mcpm_match[] = {
{},
};
+static void exynos_mcpm_setup_entry_point(void)
+{
+ /*
+ * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
+ * as part of secondary_cpu_start(). Let's redirect it to the
+ * mcpm_entry_point(). This is done during both secondary boot-up as
+ * well as system resume.
+ */
+ __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
+ __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
+ __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
+}
+
+static struct syscore_ops exynos_mcpm_syscore_ops = {
+ .resume = exynos_mcpm_setup_entry_point,
+};
+
static int __init exynos_mcpm_init(void)
{
struct device_node *node;
- void __iomem *ns_sram_base_addr;
unsigned int value, i;
int ret;
@@ -389,16 +418,9 @@ static int __init exynos_mcpm_init(void)
__raw_writel(value, pmu_base_addr + EXYNOS_COMMON_OPTION(i));
}
- /*
- * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
- * as part of secondary_cpu_start(). Let's redirect it to the
- * mcpm_entry_point().
- */
- __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
- __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
- __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
+ exynos_mcpm_setup_entry_point();
- iounmap(ns_sram_base_addr);
+ register_syscore_ops(&exynos_mcpm_syscore_ops);
return ret;
}
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index 69cf678..278f204 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -24,6 +24,7 @@
#include <asm/cacheflush.h>
#include <asm/hardware/cache-l2x0.h>
+#include <asm/mcpm.h>
#include <asm/smp_scu.h>
#include <asm/suspend.h>
@@ -191,7 +192,6 @@ int exynos_cluster_power_state(int cluster)
pmu_base_addr + S5P_INFORM1))
#define S5P_CHECK_AFTR 0xFCBA0D10
-#define S5P_CHECK_SLEEP 0x00000BAD
/* Ext-GIC nIRQ/nFIQ is the only wakeup source in AFTR */
static void exynos_set_wakeupmask(long mask)
@@ -318,7 +318,10 @@ static void exynos_pm_prepare(void)
/* ensure at least INFORM0 has the resume address */
- pmu_raw_writel(virt_to_phys(exynos_cpu_resume), S5P_INFORM0);
+ if (soc_is_exynos5420() && IS_ENABLED(CONFIG_MCPM))
+ pmu_raw_writel(virt_to_phys(mcpm_entry_point), S5P_INFORM0);
+ else
+ pmu_raw_writel(virt_to_phys(exynos_cpu_resume), S5P_INFORM0);
if (soc_is_exynos5420()) {
tmp = __raw_readl(pmu_base_addr + EXYNOS5_ARM_L2_OPTION);
@@ -490,6 +493,27 @@ static struct syscore_ops exynos_pm_syscore_ops = {
.resume = exynos_pm_resume,
};
+static int notrace exynos_mcpm_cpu_suspend(unsigned long arg)
+{
+ /* MCPM works with HW CPU identifiers */
+ unsigned int mpidr = read_cpuid_mpidr();
+ unsigned int cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+ unsigned int cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+
+ __raw_writel(0x0, sysram_base_addr + EXYNOS5420_CPU_STATE);
+
+ mcpm_set_entry_vector(cpu, cluster, exynos_cpu_resume);
+
+ /*
+ * Pass S5P_CHECK_SLEEP flag to the MCPM back-end to indicate that
+ * we are suspending the system and need to skip CPU0 power down.
+ */
+ mcpm_cpu_suspend(S5P_CHECK_SLEEP);
+
+ /* return value != 0 means failure */
+ return 1;
+}
+
/*
* Suspend Ops
*/
@@ -517,10 +541,17 @@ static int exynos_suspend_enter(suspend_state_t state)
flush_cache_all();
s3c_pm_check_store();
- ret = cpu_suspend(0, exynos_cpu_suspend);
+ /* Use the MCPM layer to suspend 5420 which is a multi-cluster SoC */
+ if (soc_is_exynos5420() && IS_ENABLED(CONFIG_MCPM))
+ ret = cpu_suspend(0, exynos_mcpm_cpu_suspend);
+ else
+ ret = cpu_suspend(0, exynos_cpu_suspend);
if (ret)
return ret;
+ if (soc_is_exynos5420() && IS_ENABLED(CONFIG_MCPM))
+ mcpm_cpu_powered_up();
+
s3c_pm_restore_uarts();
S3C_PMDBG("%s: wakeup stat: %08x\n", __func__,
diff --git a/arch/arm/mach-exynos/regs-pmu.h b/arch/arm/mach-exynos/regs-pmu.h
index 3cf0454..e8c75db 100644
--- a/arch/arm/mach-exynos/regs-pmu.h
+++ b/arch/arm/mach-exynos/regs-pmu.h
@@ -152,6 +152,7 @@
#define S5P_PAD_RET_EBIB_OPTION 0x31A8
#define S5P_CORE_LOCAL_PWR_EN 0x3
+#define S5P_CHECK_SLEEP 0x00000BAD
/* Only for EXYNOS4210 */
#define S5P_CMU_CLKSTOP_LCD1_LOWPWR 0x1154
--
2.0.0
^ permalink raw reply related [flat|nested] 130+ messages in thread
* [PATCH v5] ARM: EXYNOS: Use MCPM call-backs to support S2R on Exynos5420
@ 2014-07-03 14:46 ` Abhilash Kesavan
0 siblings, 0 replies; 130+ messages in thread
From: Abhilash Kesavan @ 2014-07-03 14:46 UTC (permalink / raw)
To: linux-arm-kernel
Use the MCPM layer to handle core suspend/resume on Exynos5420.
Also, restore the entry address setup code post-resume.
Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
---
Changes in v2:
- Made use of the MCPM suspend/powered_up call-backs
Changes in v3:
- Used the residency value to indicate the entered state
Changes in v4:
- Checked if MCPM has been enabled to prevent build error
Changes in v5:
- Removed the MCPM flags and just used a local flag to
indicate that we are suspending.
This has been tested both on an SMDK5420 and Peach Pit Chromebook on
3.16-rc3/next-20140702.
Here are the dependencies (some of these patches did not apply cleanly):
1) Cleanup patches for mach-exynos
http://comments.gmane.org/gmane.linux.kernel.samsung-soc/33772
2) PMU cleanup and refactoring for using DT
https://www.mail-archive.com/linux-kernel at vger.kernel.org/msg671625.html
3) Exynos5420 PMU/S2R Series
http://comments.gmane.org/gmane.linux.kernel.samsung-soc/33898
4) MCPM boot CPU CCI enablement patches
www.spinics.net/lists/linux-samsung-soc/msg32923.html
5) Exynos5420 CPUIdle Series which populates MCPM suspend/powered_up
call-backs.
www.gossamer-threads.com/lists/linux/kernel/1945347
https://patchwork.kernel.org/patch/4357461/
6) Exynos5420 MCPM cluster power down support
http://www.spinics.net/lists/arm-kernel/msg339988.html
7) TPM reset mask patch
http://www.spinics.net/lists/arm-kernel/msg341884.html
arch/arm/mach-exynos/mcpm-exynos.c | 50 +++++++++++++++++++++++++++-----------
arch/arm/mach-exynos/pm.c | 37 +++++++++++++++++++++++++---
arch/arm/mach-exynos/regs-pmu.h | 1 +
3 files changed, 71 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-exynos/mcpm-exynos.c b/arch/arm/mach-exynos/mcpm-exynos.c
index 2dd51cc..60f84c9 100644
--- a/arch/arm/mach-exynos/mcpm-exynos.c
+++ b/arch/arm/mach-exynos/mcpm-exynos.c
@@ -15,6 +15,7 @@
#include <linux/delay.h>
#include <linux/io.h>
#include <linux/of_address.h>
+#include <linux/syscore_ops.h>
#include <asm/cputype.h>
#include <asm/cp15.h>
@@ -30,6 +31,8 @@
#define EXYNOS5420_USE_ARM_CORE_DOWN_STATE BIT(29)
#define EXYNOS5420_USE_L2_COMMON_UP_STATE BIT(30)
+static void __iomem *ns_sram_base_addr;
+
/*
* The common v7_exit_coherency_flush API could not be used because of the
* Erratum 799270 workaround. This macro is the same as the common one (in
@@ -129,7 +132,7 @@ static int exynos_power_up(unsigned int cpu, unsigned int cluster)
* and can only be executed on processors like A15 and A7 that hit the cache
* with the C bit clear in the SCTLR register.
*/
-static void exynos_power_down(void)
+static void exynos_mcpm_power_down(u64 residency)
{
unsigned int mpidr, cpu, cluster;
bool last_man = false, skip_wfi = false;
@@ -150,7 +153,12 @@ static void exynos_power_down(void)
BUG_ON(__mcpm_cluster_state(cluster) != CLUSTER_UP);
cpu_use_count[cpu][cluster]--;
if (cpu_use_count[cpu][cluster] == 0) {
- exynos_cpu_power_down(cpunr);
+ /*
+ * Bypass power down for CPU0 during suspend. This is being
+ * taken care by the SYS_PWR_CFG bit in CORE0_SYS_PWR_REG.
+ */
+ if ((cpunr != 0) || (residency != S5P_CHECK_SLEEP))
+ exynos_cpu_power_down(cpunr);
if (exynos_cluster_unused(cluster)) {
exynos_cluster_power_down(cluster);
@@ -209,6 +217,11 @@ static void exynos_power_down(void)
/* Not dead at this point? Let our caller cope. */
}
+static void exynos_power_down(void)
+{
+ exynos_mcpm_power_down(0);
+}
+
static int exynos_wait_for_powerdown(unsigned int cpu, unsigned int cluster)
{
unsigned int tries = 100;
@@ -250,11 +263,11 @@ static void exynos_suspend(u64 residency)
{
unsigned int mpidr, cpunr;
- exynos_power_down();
+ exynos_mcpm_power_down(residency);
/*
* Execution reaches here only if cpu did not power down.
- * Hence roll back the changes done in exynos_power_down function.
+ * Hence roll back the changes done in exynos_mcpm_power_down function.
*
* CAUTION: "This function requires the stack data to be visible through
* power down and can only be executed on processors like A15 and A7
@@ -319,10 +332,26 @@ static const struct of_device_id exynos_dt_mcpm_match[] = {
{},
};
+static void exynos_mcpm_setup_entry_point(void)
+{
+ /*
+ * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
+ * as part of secondary_cpu_start(). Let's redirect it to the
+ * mcpm_entry_point(). This is done during both secondary boot-up as
+ * well as system resume.
+ */
+ __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
+ __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
+ __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
+}
+
+static struct syscore_ops exynos_mcpm_syscore_ops = {
+ .resume = exynos_mcpm_setup_entry_point,
+};
+
static int __init exynos_mcpm_init(void)
{
struct device_node *node;
- void __iomem *ns_sram_base_addr;
unsigned int value, i;
int ret;
@@ -389,16 +418,9 @@ static int __init exynos_mcpm_init(void)
__raw_writel(value, pmu_base_addr + EXYNOS_COMMON_OPTION(i));
}
- /*
- * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
- * as part of secondary_cpu_start(). Let's redirect it to the
- * mcpm_entry_point().
- */
- __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
- __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
- __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
+ exynos_mcpm_setup_entry_point();
- iounmap(ns_sram_base_addr);
+ register_syscore_ops(&exynos_mcpm_syscore_ops);
return ret;
}
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index 69cf678..278f204 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -24,6 +24,7 @@
#include <asm/cacheflush.h>
#include <asm/hardware/cache-l2x0.h>
+#include <asm/mcpm.h>
#include <asm/smp_scu.h>
#include <asm/suspend.h>
@@ -191,7 +192,6 @@ int exynos_cluster_power_state(int cluster)
pmu_base_addr + S5P_INFORM1))
#define S5P_CHECK_AFTR 0xFCBA0D10
-#define S5P_CHECK_SLEEP 0x00000BAD
/* Ext-GIC nIRQ/nFIQ is the only wakeup source in AFTR */
static void exynos_set_wakeupmask(long mask)
@@ -318,7 +318,10 @@ static void exynos_pm_prepare(void)
/* ensure at least INFORM0 has the resume address */
- pmu_raw_writel(virt_to_phys(exynos_cpu_resume), S5P_INFORM0);
+ if (soc_is_exynos5420() && IS_ENABLED(CONFIG_MCPM))
+ pmu_raw_writel(virt_to_phys(mcpm_entry_point), S5P_INFORM0);
+ else
+ pmu_raw_writel(virt_to_phys(exynos_cpu_resume), S5P_INFORM0);
if (soc_is_exynos5420()) {
tmp = __raw_readl(pmu_base_addr + EXYNOS5_ARM_L2_OPTION);
@@ -490,6 +493,27 @@ static struct syscore_ops exynos_pm_syscore_ops = {
.resume = exynos_pm_resume,
};
+static int notrace exynos_mcpm_cpu_suspend(unsigned long arg)
+{
+ /* MCPM works with HW CPU identifiers */
+ unsigned int mpidr = read_cpuid_mpidr();
+ unsigned int cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+ unsigned int cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+
+ __raw_writel(0x0, sysram_base_addr + EXYNOS5420_CPU_STATE);
+
+ mcpm_set_entry_vector(cpu, cluster, exynos_cpu_resume);
+
+ /*
+ * Pass S5P_CHECK_SLEEP flag to the MCPM back-end to indicate that
+ * we are suspending the system and need to skip CPU0 power down.
+ */
+ mcpm_cpu_suspend(S5P_CHECK_SLEEP);
+
+ /* return value != 0 means failure */
+ return 1;
+}
+
/*
* Suspend Ops
*/
@@ -517,10 +541,17 @@ static int exynos_suspend_enter(suspend_state_t state)
flush_cache_all();
s3c_pm_check_store();
- ret = cpu_suspend(0, exynos_cpu_suspend);
+ /* Use the MCPM layer to suspend 5420 which is a multi-cluster SoC */
+ if (soc_is_exynos5420() && IS_ENABLED(CONFIG_MCPM))
+ ret = cpu_suspend(0, exynos_mcpm_cpu_suspend);
+ else
+ ret = cpu_suspend(0, exynos_cpu_suspend);
if (ret)
return ret;
+ if (soc_is_exynos5420() && IS_ENABLED(CONFIG_MCPM))
+ mcpm_cpu_powered_up();
+
s3c_pm_restore_uarts();
S3C_PMDBG("%s: wakeup stat: %08x\n", __func__,
diff --git a/arch/arm/mach-exynos/regs-pmu.h b/arch/arm/mach-exynos/regs-pmu.h
index 3cf0454..e8c75db 100644
--- a/arch/arm/mach-exynos/regs-pmu.h
+++ b/arch/arm/mach-exynos/regs-pmu.h
@@ -152,6 +152,7 @@
#define S5P_PAD_RET_EBIB_OPTION 0x31A8
#define S5P_CORE_LOCAL_PWR_EN 0x3
+#define S5P_CHECK_SLEEP 0x00000BAD
/* Only for EXYNOS4210 */
#define S5P_CMU_CLKSTOP_LCD1_LOWPWR 0x1154
--
2.0.0
^ permalink raw reply related [flat|nested] 130+ messages in thread
* Re: several messages
2014-07-03 14:46 ` Abhilash Kesavan
@ 2014-07-03 15:45 ` Nicolas Pitre
-1 siblings, 0 replies; 130+ messages in thread
From: Nicolas Pitre @ 2014-07-03 15:45 UTC (permalink / raw)
To: Abhilash Kesavan, Abhilash Kesavan
Cc: linux-samsung-soc, linux-arm-kernel, kgene.kim,
Lorenzo Pieralisi, Andrew Bresticker, Douglas Anderson
On Thu, 3 Jul 2014, Abhilash Kesavan wrote:
> On Thu, Jul 3, 2014 at 6:59 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> > Please, let's avoid going that route. There is no such special handling
> > needed if the API is sufficient. And the provided API allows you to
> > suspend a CPU or shut it down. It shouldn't matter at that level if
> > this is due to a cluster switch or a hotplug event. Do you really need
> > something else?
> No, just one local flag for suspend should be enough for me. Will remove these.
[...]
> Changes in v5:
> - Removed the MCPM flags and just used a local flag to
> indicate that we are suspending.
[...]
> -static void exynos_power_down(void)
> +static void exynos_mcpm_power_down(u64 residency)
> {
> unsigned int mpidr, cpu, cluster;
> bool last_man = false, skip_wfi = false;
> @@ -150,7 +153,12 @@ static void exynos_power_down(void)
> BUG_ON(__mcpm_cluster_state(cluster) != CLUSTER_UP);
> cpu_use_count[cpu][cluster]--;
> if (cpu_use_count[cpu][cluster] == 0) {
> - exynos_cpu_power_down(cpunr);
> + /*
> + * Bypass power down for CPU0 during suspend. This is being
> + * taken care by the SYS_PWR_CFG bit in CORE0_SYS_PWR_REG.
> + */
> + if ((cpunr != 0) || (residency != S5P_CHECK_SLEEP))
> + exynos_cpu_power_down(cpunr);
>
> if (exynos_cluster_unused(cluster)) {
> exynos_cluster_power_down(cluster);
> @@ -209,6 +217,11 @@ static void exynos_power_down(void)
> /* Not dead at this point? Let our caller cope. */
> }
>
> +static void exynos_power_down(void)
> +{
> + exynos_mcpm_power_down(0);
> +}
[...]
> +static int notrace exynos_mcpm_cpu_suspend(unsigned long arg)
> +{
> + /* MCPM works with HW CPU identifiers */
> + unsigned int mpidr = read_cpuid_mpidr();
> + unsigned int cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
> + unsigned int cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
> +
> + __raw_writel(0x0, sysram_base_addr + EXYNOS5420_CPU_STATE);
> +
> + mcpm_set_entry_vector(cpu, cluster, exynos_cpu_resume);
> +
> + /*
> + * Pass S5P_CHECK_SLEEP flag to the MCPM back-end to indicate that
> + * we are suspending the system and need to skip CPU0 power down.
> + */
> + mcpm_cpu_suspend(S5P_CHECK_SLEEP);
NAK.
When I say "local flag with local meaning", I don't want you to smuggle
that flag through a public interface either. I find it rather inelegant
to have the notion of special handling for CPU0 being spread around like
that.
If CPU0 is special, then it should be dealth with in one place only,
ideally in the MCPM backend, so the rest of the kernel doesn't have to
care.
Again, here's what I mean:
static void exynos_mcpm_down_handler(int flags)
{
[...]
if ((cpunr != 0) || !(flags & SKIP_CPU_POWERDOWN_IF_CPU0))
exynos_cpu_power_down(cpunr);
[...]
}
static void exynos_mcpm_power_down()
{
exynos_mcpm_down_handler(0);
}
static void exynos_mcpm_suspend(u64 residency)
{
/*
* Theresidency argument is ignored for now.
* However, in the CPU suspend case, we bypass power down for
* CPU0 as this is being taken care by the SYS_PWR_CFG bit in
* CORE0_SYS_PWR_REG.
*/
exynos_mcpm_down_handler(SKIP_CPU_POWERDOWN_IF_CPU0);
}
And SKIP_CPU_POWERDOWN_IF_CPU0 is defined in and visible to
mcpm-exynos.c only.
Nicolas
^ permalink raw reply [flat|nested] 130+ messages in thread
* several messages
@ 2014-07-03 15:45 ` Nicolas Pitre
0 siblings, 0 replies; 130+ messages in thread
From: Nicolas Pitre @ 2014-07-03 15:45 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, 3 Jul 2014, Abhilash Kesavan wrote:
> On Thu, Jul 3, 2014 at 6:59 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> > Please, let's avoid going that route. There is no such special handling
> > needed if the API is sufficient. And the provided API allows you to
> > suspend a CPU or shut it down. It shouldn't matter at that level if
> > this is due to a cluster switch or a hotplug event. Do you really need
> > something else?
> No, just one local flag for suspend should be enough for me. Will remove these.
[...]
> Changes in v5:
> - Removed the MCPM flags and just used a local flag to
> indicate that we are suspending.
[...]
> -static void exynos_power_down(void)
> +static void exynos_mcpm_power_down(u64 residency)
> {
> unsigned int mpidr, cpu, cluster;
> bool last_man = false, skip_wfi = false;
> @@ -150,7 +153,12 @@ static void exynos_power_down(void)
> BUG_ON(__mcpm_cluster_state(cluster) != CLUSTER_UP);
> cpu_use_count[cpu][cluster]--;
> if (cpu_use_count[cpu][cluster] == 0) {
> - exynos_cpu_power_down(cpunr);
> + /*
> + * Bypass power down for CPU0 during suspend. This is being
> + * taken care by the SYS_PWR_CFG bit in CORE0_SYS_PWR_REG.
> + */
> + if ((cpunr != 0) || (residency != S5P_CHECK_SLEEP))
> + exynos_cpu_power_down(cpunr);
>
> if (exynos_cluster_unused(cluster)) {
> exynos_cluster_power_down(cluster);
> @@ -209,6 +217,11 @@ static void exynos_power_down(void)
> /* Not dead at this point? Let our caller cope. */
> }
>
> +static void exynos_power_down(void)
> +{
> + exynos_mcpm_power_down(0);
> +}
[...]
> +static int notrace exynos_mcpm_cpu_suspend(unsigned long arg)
> +{
> + /* MCPM works with HW CPU identifiers */
> + unsigned int mpidr = read_cpuid_mpidr();
> + unsigned int cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
> + unsigned int cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
> +
> + __raw_writel(0x0, sysram_base_addr + EXYNOS5420_CPU_STATE);
> +
> + mcpm_set_entry_vector(cpu, cluster, exynos_cpu_resume);
> +
> + /*
> + * Pass S5P_CHECK_SLEEP flag to the MCPM back-end to indicate that
> + * we are suspending the system and need to skip CPU0 power down.
> + */
> + mcpm_cpu_suspend(S5P_CHECK_SLEEP);
NAK.
When I say "local flag with local meaning", I don't want you to smuggle
that flag through a public interface either. I find it rather inelegant
to have the notion of special handling for CPU0 being spread around like
that.
If CPU0 is special, then it should be dealth with in one place only,
ideally in the MCPM backend, so the rest of the kernel doesn't have to
care.
Again, here's what I mean:
static void exynos_mcpm_down_handler(int flags)
{
[...]
if ((cpunr != 0) || !(flags & SKIP_CPU_POWERDOWN_IF_CPU0))
exynos_cpu_power_down(cpunr);
[...]
}
static void exynos_mcpm_power_down()
{
exynos_mcpm_down_handler(0);
}
static void exynos_mcpm_suspend(u64 residency)
{
/*
* Theresidency argument is ignored for now.
* However, in the CPU suspend case, we bypass power down for
* CPU0 as this is being taken care by the SYS_PWR_CFG bit in
* CORE0_SYS_PWR_REG.
*/
exynos_mcpm_down_handler(SKIP_CPU_POWERDOWN_IF_CPU0);
}
And SKIP_CPU_POWERDOWN_IF_CPU0 is defined in and visible to
mcpm-exynos.c only.
Nicolas
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
2014-07-03 15:45 ` Nicolas Pitre
@ 2014-07-03 16:19 ` Abhilash Kesavan
-1 siblings, 0 replies; 130+ messages in thread
From: Abhilash Kesavan @ 2014-07-03 16:19 UTC (permalink / raw)
To: Nicolas Pitre
Cc: linux-samsung-soc, linux-arm-kernel, Kukjin Kim,
Lorenzo Pieralisi, Andrew Bresticker, Douglas Anderson
Hi Nicolas,
On Thu, Jul 3, 2014 at 9:15 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> On Thu, 3 Jul 2014, Abhilash Kesavan wrote:
>
>> On Thu, Jul 3, 2014 at 6:59 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
>> > Please, let's avoid going that route. There is no such special handling
>> > needed if the API is sufficient. And the provided API allows you to
>> > suspend a CPU or shut it down. It shouldn't matter at that level if
>> > this is due to a cluster switch or a hotplug event. Do you really need
>> > something else?
>> No, just one local flag for suspend should be enough for me. Will remove these.
>
> [...]
>
>> Changes in v5:
>> - Removed the MCPM flags and just used a local flag to
>> indicate that we are suspending.
>
> [...]
>
>> -static void exynos_power_down(void)
>> +static void exynos_mcpm_power_down(u64 residency)
>> {
>> unsigned int mpidr, cpu, cluster;
>> bool last_man = false, skip_wfi = false;
>> @@ -150,7 +153,12 @@ static void exynos_power_down(void)
>> BUG_ON(__mcpm_cluster_state(cluster) != CLUSTER_UP);
>> cpu_use_count[cpu][cluster]--;
>> if (cpu_use_count[cpu][cluster] == 0) {
>> - exynos_cpu_power_down(cpunr);
>> + /*
>> + * Bypass power down for CPU0 during suspend. This is being
>> + * taken care by the SYS_PWR_CFG bit in CORE0_SYS_PWR_REG.
>> + */
>> + if ((cpunr != 0) || (residency != S5P_CHECK_SLEEP))
>> + exynos_cpu_power_down(cpunr);
>>
>> if (exynos_cluster_unused(cluster)) {
>> exynos_cluster_power_down(cluster);
>> @@ -209,6 +217,11 @@ static void exynos_power_down(void)
>> /* Not dead at this point? Let our caller cope. */
>> }
>>
>> +static void exynos_power_down(void)
>> +{
>> + exynos_mcpm_power_down(0);
>> +}
>
> [...]
>
>> +static int notrace exynos_mcpm_cpu_suspend(unsigned long arg)
>> +{
>> + /* MCPM works with HW CPU identifiers */
>> + unsigned int mpidr = read_cpuid_mpidr();
>> + unsigned int cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
>> + unsigned int cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
>> +
>> + __raw_writel(0x0, sysram_base_addr + EXYNOS5420_CPU_STATE);
>> +
>> + mcpm_set_entry_vector(cpu, cluster, exynos_cpu_resume);
>> +
>> + /*
>> + * Pass S5P_CHECK_SLEEP flag to the MCPM back-end to indicate that
>> + * we are suspending the system and need to skip CPU0 power down.
>> + */
>> + mcpm_cpu_suspend(S5P_CHECK_SLEEP);
>
> NAK.
>
> When I say "local flag with local meaning", I don't want you to smuggle
> that flag through a public interface either. I find it rather inelegant
> to have the notion of special handling for CPU0 being spread around like
> that.
>
> If CPU0 is special, then it should be dealth with in one place only,
> ideally in the MCPM backend, so the rest of the kernel doesn't have to
> care.
>
> Again, here's what I mean:
>
> static void exynos_mcpm_down_handler(int flags)
> {
> [...]
> if ((cpunr != 0) || !(flags & SKIP_CPU_POWERDOWN_IF_CPU0))
> exynos_cpu_power_down(cpunr);
> [...]
> }
>
> static void exynos_mcpm_power_down()
> {
> exynos_mcpm_down_handler(0);
> }
>
> static void exynos_mcpm_suspend(u64 residency)
> {
> /*
> * Theresidency argument is ignored for now.
> * However, in the CPU suspend case, we bypass power down for
> * CPU0 as this is being taken care by the SYS_PWR_CFG bit in
> * CORE0_SYS_PWR_REG.
> */
> exynos_mcpm_down_handler(SKIP_CPU_POWERDOWN_IF_CPU0);
> }
>
> And SKIP_CPU_POWERDOWN_IF_CPU0 is defined in and visible to
> mcpm-exynos.c only.
Sorry if I am being dense, but the exynos_mcpm_suspend function would
get called from both the bL cpuidle driver as well the exynos pm code.
We want to skip CPU0 only in case of the S2R case i.e. the pm code and
keep the CPU0 power down code for all other cases including CPUIdle.
If I call exynos_mcpm_down_handler with the flag in
exynos_mcpm_suspend(), CPUIdle will also skip CPU0 isn't it ?
Regards,
Abhilash
>
>
> Nicolas
^ permalink raw reply [flat|nested] 130+ messages in thread
* several messages
@ 2014-07-03 16:19 ` Abhilash Kesavan
0 siblings, 0 replies; 130+ messages in thread
From: Abhilash Kesavan @ 2014-07-03 16:19 UTC (permalink / raw)
To: linux-arm-kernel
Hi Nicolas,
On Thu, Jul 3, 2014 at 9:15 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> On Thu, 3 Jul 2014, Abhilash Kesavan wrote:
>
>> On Thu, Jul 3, 2014 at 6:59 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
>> > Please, let's avoid going that route. There is no such special handling
>> > needed if the API is sufficient. And the provided API allows you to
>> > suspend a CPU or shut it down. It shouldn't matter at that level if
>> > this is due to a cluster switch or a hotplug event. Do you really need
>> > something else?
>> No, just one local flag for suspend should be enough for me. Will remove these.
>
> [...]
>
>> Changes in v5:
>> - Removed the MCPM flags and just used a local flag to
>> indicate that we are suspending.
>
> [...]
>
>> -static void exynos_power_down(void)
>> +static void exynos_mcpm_power_down(u64 residency)
>> {
>> unsigned int mpidr, cpu, cluster;
>> bool last_man = false, skip_wfi = false;
>> @@ -150,7 +153,12 @@ static void exynos_power_down(void)
>> BUG_ON(__mcpm_cluster_state(cluster) != CLUSTER_UP);
>> cpu_use_count[cpu][cluster]--;
>> if (cpu_use_count[cpu][cluster] == 0) {
>> - exynos_cpu_power_down(cpunr);
>> + /*
>> + * Bypass power down for CPU0 during suspend. This is being
>> + * taken care by the SYS_PWR_CFG bit in CORE0_SYS_PWR_REG.
>> + */
>> + if ((cpunr != 0) || (residency != S5P_CHECK_SLEEP))
>> + exynos_cpu_power_down(cpunr);
>>
>> if (exynos_cluster_unused(cluster)) {
>> exynos_cluster_power_down(cluster);
>> @@ -209,6 +217,11 @@ static void exynos_power_down(void)
>> /* Not dead at this point? Let our caller cope. */
>> }
>>
>> +static void exynos_power_down(void)
>> +{
>> + exynos_mcpm_power_down(0);
>> +}
>
> [...]
>
>> +static int notrace exynos_mcpm_cpu_suspend(unsigned long arg)
>> +{
>> + /* MCPM works with HW CPU identifiers */
>> + unsigned int mpidr = read_cpuid_mpidr();
>> + unsigned int cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
>> + unsigned int cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
>> +
>> + __raw_writel(0x0, sysram_base_addr + EXYNOS5420_CPU_STATE);
>> +
>> + mcpm_set_entry_vector(cpu, cluster, exynos_cpu_resume);
>> +
>> + /*
>> + * Pass S5P_CHECK_SLEEP flag to the MCPM back-end to indicate that
>> + * we are suspending the system and need to skip CPU0 power down.
>> + */
>> + mcpm_cpu_suspend(S5P_CHECK_SLEEP);
>
> NAK.
>
> When I say "local flag with local meaning", I don't want you to smuggle
> that flag through a public interface either. I find it rather inelegant
> to have the notion of special handling for CPU0 being spread around like
> that.
>
> If CPU0 is special, then it should be dealth with in one place only,
> ideally in the MCPM backend, so the rest of the kernel doesn't have to
> care.
>
> Again, here's what I mean:
>
> static void exynos_mcpm_down_handler(int flags)
> {
> [...]
> if ((cpunr != 0) || !(flags & SKIP_CPU_POWERDOWN_IF_CPU0))
> exynos_cpu_power_down(cpunr);
> [...]
> }
>
> static void exynos_mcpm_power_down()
> {
> exynos_mcpm_down_handler(0);
> }
>
> static void exynos_mcpm_suspend(u64 residency)
> {
> /*
> * Theresidency argument is ignored for now.
> * However, in the CPU suspend case, we bypass power down for
> * CPU0 as this is being taken care by the SYS_PWR_CFG bit in
> * CORE0_SYS_PWR_REG.
> */
> exynos_mcpm_down_handler(SKIP_CPU_POWERDOWN_IF_CPU0);
> }
>
> And SKIP_CPU_POWERDOWN_IF_CPU0 is defined in and visible to
> mcpm-exynos.c only.
Sorry if I am being dense, but the exynos_mcpm_suspend function would
get called from both the bL cpuidle driver as well the exynos pm code.
We want to skip CPU0 only in case of the S2R case i.e. the pm code and
keep the CPU0 power down code for all other cases including CPUIdle.
If I call exynos_mcpm_down_handler with the flag in
exynos_mcpm_suspend(), CPUIdle will also skip CPU0 isn't it ?
Regards,
Abhilash
>
>
> Nicolas
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
2014-07-03 16:19 ` Abhilash Kesavan
@ 2014-07-03 19:00 ` Nicolas Pitre
-1 siblings, 0 replies; 130+ messages in thread
From: Nicolas Pitre @ 2014-07-03 19:00 UTC (permalink / raw)
To: Abhilash Kesavan
Cc: linux-samsung-soc, linux-arm-kernel, Kukjin Kim,
Lorenzo Pieralisi, Andrew Bresticker, Douglas Anderson
On Thu, 3 Jul 2014, Abhilash Kesavan wrote:
> Hi Nicolas,
>
> On Thu, Jul 3, 2014 at 9:15 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> > On Thu, 3 Jul 2014, Abhilash Kesavan wrote:
> >
> >> On Thu, Jul 3, 2014 at 6:59 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> >> > Please, let's avoid going that route. There is no such special handling
> >> > needed if the API is sufficient. And the provided API allows you to
> >> > suspend a CPU or shut it down. It shouldn't matter at that level if
> >> > this is due to a cluster switch or a hotplug event. Do you really need
> >> > something else?
> >> No, just one local flag for suspend should be enough for me. Will remove these.
> >
> > [...]
> >
> >> Changes in v5:
> >> - Removed the MCPM flags and just used a local flag to
> >> indicate that we are suspending.
> >
> > [...]
> >
> >> -static void exynos_power_down(void)
> >> +static void exynos_mcpm_power_down(u64 residency)
> >> {
> >> unsigned int mpidr, cpu, cluster;
> >> bool last_man = false, skip_wfi = false;
> >> @@ -150,7 +153,12 @@ static void exynos_power_down(void)
> >> BUG_ON(__mcpm_cluster_state(cluster) != CLUSTER_UP);
> >> cpu_use_count[cpu][cluster]--;
> >> if (cpu_use_count[cpu][cluster] == 0) {
> >> - exynos_cpu_power_down(cpunr);
> >> + /*
> >> + * Bypass power down for CPU0 during suspend. This is being
> >> + * taken care by the SYS_PWR_CFG bit in CORE0_SYS_PWR_REG.
> >> + */
> >> + if ((cpunr != 0) || (residency != S5P_CHECK_SLEEP))
> >> + exynos_cpu_power_down(cpunr);
> >>
> >> if (exynos_cluster_unused(cluster)) {
> >> exynos_cluster_power_down(cluster);
> >> @@ -209,6 +217,11 @@ static void exynos_power_down(void)
> >> /* Not dead at this point? Let our caller cope. */
> >> }
> >>
> >> +static void exynos_power_down(void)
> >> +{
> >> + exynos_mcpm_power_down(0);
> >> +}
> >
> > [...]
> >
> >> +static int notrace exynos_mcpm_cpu_suspend(unsigned long arg)
> >> +{
> >> + /* MCPM works with HW CPU identifiers */
> >> + unsigned int mpidr = read_cpuid_mpidr();
> >> + unsigned int cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
> >> + unsigned int cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
> >> +
> >> + __raw_writel(0x0, sysram_base_addr + EXYNOS5420_CPU_STATE);
> >> +
> >> + mcpm_set_entry_vector(cpu, cluster, exynos_cpu_resume);
> >> +
> >> + /*
> >> + * Pass S5P_CHECK_SLEEP flag to the MCPM back-end to indicate that
> >> + * we are suspending the system and need to skip CPU0 power down.
> >> + */
> >> + mcpm_cpu_suspend(S5P_CHECK_SLEEP);
> >
> > NAK.
> >
> > When I say "local flag with local meaning", I don't want you to smuggle
> > that flag through a public interface either. I find it rather inelegant
> > to have the notion of special handling for CPU0 being spread around like
> > that.
> >
> > If CPU0 is special, then it should be dealth with in one place only,
> > ideally in the MCPM backend, so the rest of the kernel doesn't have to
> > care.
> >
> > Again, here's what I mean:
> >
> > static void exynos_mcpm_down_handler(int flags)
> > {
> > [...]
> > if ((cpunr != 0) || !(flags & SKIP_CPU_POWERDOWN_IF_CPU0))
> > exynos_cpu_power_down(cpunr);
> > [...]
> > }
> >
> > static void exynos_mcpm_power_down()
> > {
> > exynos_mcpm_down_handler(0);
> > }
> >
> > static void exynos_mcpm_suspend(u64 residency)
> > {
> > /*
> > * Theresidency argument is ignored for now.
> > * However, in the CPU suspend case, we bypass power down for
> > * CPU0 as this is being taken care by the SYS_PWR_CFG bit in
> > * CORE0_SYS_PWR_REG.
> > */
> > exynos_mcpm_down_handler(SKIP_CPU_POWERDOWN_IF_CPU0);
> > }
> >
> > And SKIP_CPU_POWERDOWN_IF_CPU0 is defined in and visible to
> > mcpm-exynos.c only.
> Sorry if I am being dense, but the exynos_mcpm_suspend function would
> get called from both the bL cpuidle driver as well the exynos pm code.
What is that exynos pm code actually doing?
> We want to skip CPU0 only in case of the S2R case i.e. the pm code and
> keep the CPU0 power down code for all other cases including CPUIdle.
OK. If so I missed that somehow (hint hint).
> If I call exynos_mcpm_down_handler with the flag in
> exynos_mcpm_suspend(), CPUIdle will also skip CPU0 isn't it ?
As it is, yes. You could logically use an infinite residency time
(something like U64_MAX) to distinguish S2RAM from other types of
suspend.
Yet, why is this SYS_PWR_CFG bit set outside of MCPM? Couldn't the MCPM
backend handle it directly instead of expecting some other entity to do
it?
Nicolas
^ permalink raw reply [flat|nested] 130+ messages in thread
* several messages
@ 2014-07-03 19:00 ` Nicolas Pitre
0 siblings, 0 replies; 130+ messages in thread
From: Nicolas Pitre @ 2014-07-03 19:00 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, 3 Jul 2014, Abhilash Kesavan wrote:
> Hi Nicolas,
>
> On Thu, Jul 3, 2014 at 9:15 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> > On Thu, 3 Jul 2014, Abhilash Kesavan wrote:
> >
> >> On Thu, Jul 3, 2014 at 6:59 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> >> > Please, let's avoid going that route. There is no such special handling
> >> > needed if the API is sufficient. And the provided API allows you to
> >> > suspend a CPU or shut it down. It shouldn't matter at that level if
> >> > this is due to a cluster switch or a hotplug event. Do you really need
> >> > something else?
> >> No, just one local flag for suspend should be enough for me. Will remove these.
> >
> > [...]
> >
> >> Changes in v5:
> >> - Removed the MCPM flags and just used a local flag to
> >> indicate that we are suspending.
> >
> > [...]
> >
> >> -static void exynos_power_down(void)
> >> +static void exynos_mcpm_power_down(u64 residency)
> >> {
> >> unsigned int mpidr, cpu, cluster;
> >> bool last_man = false, skip_wfi = false;
> >> @@ -150,7 +153,12 @@ static void exynos_power_down(void)
> >> BUG_ON(__mcpm_cluster_state(cluster) != CLUSTER_UP);
> >> cpu_use_count[cpu][cluster]--;
> >> if (cpu_use_count[cpu][cluster] == 0) {
> >> - exynos_cpu_power_down(cpunr);
> >> + /*
> >> + * Bypass power down for CPU0 during suspend. This is being
> >> + * taken care by the SYS_PWR_CFG bit in CORE0_SYS_PWR_REG.
> >> + */
> >> + if ((cpunr != 0) || (residency != S5P_CHECK_SLEEP))
> >> + exynos_cpu_power_down(cpunr);
> >>
> >> if (exynos_cluster_unused(cluster)) {
> >> exynos_cluster_power_down(cluster);
> >> @@ -209,6 +217,11 @@ static void exynos_power_down(void)
> >> /* Not dead at this point? Let our caller cope. */
> >> }
> >>
> >> +static void exynos_power_down(void)
> >> +{
> >> + exynos_mcpm_power_down(0);
> >> +}
> >
> > [...]
> >
> >> +static int notrace exynos_mcpm_cpu_suspend(unsigned long arg)
> >> +{
> >> + /* MCPM works with HW CPU identifiers */
> >> + unsigned int mpidr = read_cpuid_mpidr();
> >> + unsigned int cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
> >> + unsigned int cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
> >> +
> >> + __raw_writel(0x0, sysram_base_addr + EXYNOS5420_CPU_STATE);
> >> +
> >> + mcpm_set_entry_vector(cpu, cluster, exynos_cpu_resume);
> >> +
> >> + /*
> >> + * Pass S5P_CHECK_SLEEP flag to the MCPM back-end to indicate that
> >> + * we are suspending the system and need to skip CPU0 power down.
> >> + */
> >> + mcpm_cpu_suspend(S5P_CHECK_SLEEP);
> >
> > NAK.
> >
> > When I say "local flag with local meaning", I don't want you to smuggle
> > that flag through a public interface either. I find it rather inelegant
> > to have the notion of special handling for CPU0 being spread around like
> > that.
> >
> > If CPU0 is special, then it should be dealth with in one place only,
> > ideally in the MCPM backend, so the rest of the kernel doesn't have to
> > care.
> >
> > Again, here's what I mean:
> >
> > static void exynos_mcpm_down_handler(int flags)
> > {
> > [...]
> > if ((cpunr != 0) || !(flags & SKIP_CPU_POWERDOWN_IF_CPU0))
> > exynos_cpu_power_down(cpunr);
> > [...]
> > }
> >
> > static void exynos_mcpm_power_down()
> > {
> > exynos_mcpm_down_handler(0);
> > }
> >
> > static void exynos_mcpm_suspend(u64 residency)
> > {
> > /*
> > * Theresidency argument is ignored for now.
> > * However, in the CPU suspend case, we bypass power down for
> > * CPU0 as this is being taken care by the SYS_PWR_CFG bit in
> > * CORE0_SYS_PWR_REG.
> > */
> > exynos_mcpm_down_handler(SKIP_CPU_POWERDOWN_IF_CPU0);
> > }
> >
> > And SKIP_CPU_POWERDOWN_IF_CPU0 is defined in and visible to
> > mcpm-exynos.c only.
> Sorry if I am being dense, but the exynos_mcpm_suspend function would
> get called from both the bL cpuidle driver as well the exynos pm code.
What is that exynos pm code actually doing?
> We want to skip CPU0 only in case of the S2R case i.e. the pm code and
> keep the CPU0 power down code for all other cases including CPUIdle.
OK. If so I missed that somehow (hint hint).
> If I call exynos_mcpm_down_handler with the flag in
> exynos_mcpm_suspend(), CPUIdle will also skip CPU0 isn't it ?
As it is, yes. You could logically use an infinite residency time
(something like U64_MAX) to distinguish S2RAM from other types of
suspend.
Yet, why is this SYS_PWR_CFG bit set outside of MCPM? Couldn't the MCPM
backend handle it directly instead of expecting some other entity to do
it?
Nicolas
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
2014-07-03 19:00 ` Nicolas Pitre
@ 2014-07-03 20:00 ` Abhilash Kesavan
-1 siblings, 0 replies; 130+ messages in thread
From: Abhilash Kesavan @ 2014-07-03 20:00 UTC (permalink / raw)
To: Nicolas Pitre
Cc: linux-samsung-soc, linux-arm-kernel, Kukjin Kim,
Lorenzo Pieralisi, Andrew Bresticker, Douglas Anderson
Hi Nicolas,
On Fri, Jul 4, 2014 at 12:30 AM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> On Thu, 3 Jul 2014, Abhilash Kesavan wrote:
>
>> Hi Nicolas,
>>
>> On Thu, Jul 3, 2014 at 9:15 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
>> > On Thu, 3 Jul 2014, Abhilash Kesavan wrote:
>> >
>> >> On Thu, Jul 3, 2014 at 6:59 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
>> >> > Please, let's avoid going that route. There is no such special handling
>> >> > needed if the API is sufficient. And the provided API allows you to
>> >> > suspend a CPU or shut it down. It shouldn't matter at that level if
>> >> > this is due to a cluster switch or a hotplug event. Do you really need
>> >> > something else?
>> >> No, just one local flag for suspend should be enough for me. Will remove these.
>> >
>> > [...]
>> >
>> >> Changes in v5:
>> >> - Removed the MCPM flags and just used a local flag to
>> >> indicate that we are suspending.
>> >
>> > [...]
>> >
>> >> -static void exynos_power_down(void)
>> >> +static void exynos_mcpm_power_down(u64 residency)
>> >> {
>> >> unsigned int mpidr, cpu, cluster;
>> >> bool last_man = false, skip_wfi = false;
>> >> @@ -150,7 +153,12 @@ static void exynos_power_down(void)
>> >> BUG_ON(__mcpm_cluster_state(cluster) != CLUSTER_UP);
>> >> cpu_use_count[cpu][cluster]--;
>> >> if (cpu_use_count[cpu][cluster] == 0) {
>> >> - exynos_cpu_power_down(cpunr);
>> >> + /*
>> >> + * Bypass power down for CPU0 during suspend. This is being
>> >> + * taken care by the SYS_PWR_CFG bit in CORE0_SYS_PWR_REG.
>> >> + */
>> >> + if ((cpunr != 0) || (residency != S5P_CHECK_SLEEP))
>> >> + exynos_cpu_power_down(cpunr);
>> >>
>> >> if (exynos_cluster_unused(cluster)) {
>> >> exynos_cluster_power_down(cluster);
>> >> @@ -209,6 +217,11 @@ static void exynos_power_down(void)
>> >> /* Not dead at this point? Let our caller cope. */
>> >> }
>> >>
>> >> +static void exynos_power_down(void)
>> >> +{
>> >> + exynos_mcpm_power_down(0);
>> >> +}
>> >
>> > [...]
>> >
>> >> +static int notrace exynos_mcpm_cpu_suspend(unsigned long arg)
>> >> +{
>> >> + /* MCPM works with HW CPU identifiers */
>> >> + unsigned int mpidr = read_cpuid_mpidr();
>> >> + unsigned int cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
>> >> + unsigned int cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
>> >> +
>> >> + __raw_writel(0x0, sysram_base_addr + EXYNOS5420_CPU_STATE);
>> >> +
>> >> + mcpm_set_entry_vector(cpu, cluster, exynos_cpu_resume);
>> >> +
>> >> + /*
>> >> + * Pass S5P_CHECK_SLEEP flag to the MCPM back-end to indicate that
>> >> + * we are suspending the system and need to skip CPU0 power down.
>> >> + */
>> >> + mcpm_cpu_suspend(S5P_CHECK_SLEEP);
>> >
>> > NAK.
>> >
>> > When I say "local flag with local meaning", I don't want you to smuggle
>> > that flag through a public interface either. I find it rather inelegant
>> > to have the notion of special handling for CPU0 being spread around like
>> > that.
>> >
>> > If CPU0 is special, then it should be dealth with in one place only,
>> > ideally in the MCPM backend, so the rest of the kernel doesn't have to
>> > care.
>> >
>> > Again, here's what I mean:
>> >
>> > static void exynos_mcpm_down_handler(int flags)
>> > {
>> > [...]
>> > if ((cpunr != 0) || !(flags & SKIP_CPU_POWERDOWN_IF_CPU0))
>> > exynos_cpu_power_down(cpunr);
>> > [...]
>> > }
>> >
>> > static void exynos_mcpm_power_down()
>> > {
>> > exynos_mcpm_down_handler(0);
>> > }
>> >
>> > static void exynos_mcpm_suspend(u64 residency)
>> > {
>> > /*
>> > * Theresidency argument is ignored for now.
>> > * However, in the CPU suspend case, we bypass power down for
>> > * CPU0 as this is being taken care by the SYS_PWR_CFG bit in
>> > * CORE0_SYS_PWR_REG.
>> > */
>> > exynos_mcpm_down_handler(SKIP_CPU_POWERDOWN_IF_CPU0);
>> > }
>> >
>> > And SKIP_CPU_POWERDOWN_IF_CPU0 is defined in and visible to
>> > mcpm-exynos.c only.
>> Sorry if I am being dense, but the exynos_mcpm_suspend function would
>> get called from both the bL cpuidle driver as well the exynos pm code.
>
> What is that exynos pm code actually doing?
exynos pm code is shared across Exynos4 and 5 SoCs. It primarily does
a series of register configurations which are required to put the
system to sleep (some parts of these are SoC specific and others
common). It also populates the suspend_ops for exynos. In the current
patch, exynos_suspend_enter() is where I have plugged in the
mcpm_cpu_suspend call.
This patch is based on the S2R series for 5420
(http://comments.gmane.org/gmane.linux.kernel.samsung-soc/33898), you
may also have a look at that for a clearer picture.
>
>> We want to skip CPU0 only in case of the S2R case i.e. the pm code and
>> keep the CPU0 power down code for all other cases including CPUIdle.
>
> OK. If so I missed that somehow (hint hint).
>
>> If I call exynos_mcpm_down_handler with the flag in
>> exynos_mcpm_suspend(), CPUIdle will also skip CPU0 isn't it ?
>
> As it is, yes. You could logically use an infinite residency time
> (something like U64_MAX) to distinguish S2RAM from other types of
> suspend.
OK, I will use this rather than the S5P_CHECK_SLEEP macro.
>
> Yet, why is this SYS_PWR_CFG bit set outside of MCPM? Couldn't the MCPM
> backend handle it directly instead of expecting some other entity to do
> it?
Low power modes such as Sleep, Low Power Audio, AFTR (ARM Off Top
Running) require a series of register configurations as specified by
the UM to enter/exit them. All the exynos SoCs including 5420, do such
configurations (including sys_pwr_reg setup) as part of the
exynos_pm_prepare function in pm.c and so we just need to skip the cpu
power down.
Regards,
Abhilash
>
>
> Nicolas
^ permalink raw reply [flat|nested] 130+ messages in thread
* several messages
@ 2014-07-03 20:00 ` Abhilash Kesavan
0 siblings, 0 replies; 130+ messages in thread
From: Abhilash Kesavan @ 2014-07-03 20:00 UTC (permalink / raw)
To: linux-arm-kernel
Hi Nicolas,
On Fri, Jul 4, 2014 at 12:30 AM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> On Thu, 3 Jul 2014, Abhilash Kesavan wrote:
>
>> Hi Nicolas,
>>
>> On Thu, Jul 3, 2014 at 9:15 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
>> > On Thu, 3 Jul 2014, Abhilash Kesavan wrote:
>> >
>> >> On Thu, Jul 3, 2014 at 6:59 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
>> >> > Please, let's avoid going that route. There is no such special handling
>> >> > needed if the API is sufficient. And the provided API allows you to
>> >> > suspend a CPU or shut it down. It shouldn't matter at that level if
>> >> > this is due to a cluster switch or a hotplug event. Do you really need
>> >> > something else?
>> >> No, just one local flag for suspend should be enough for me. Will remove these.
>> >
>> > [...]
>> >
>> >> Changes in v5:
>> >> - Removed the MCPM flags and just used a local flag to
>> >> indicate that we are suspending.
>> >
>> > [...]
>> >
>> >> -static void exynos_power_down(void)
>> >> +static void exynos_mcpm_power_down(u64 residency)
>> >> {
>> >> unsigned int mpidr, cpu, cluster;
>> >> bool last_man = false, skip_wfi = false;
>> >> @@ -150,7 +153,12 @@ static void exynos_power_down(void)
>> >> BUG_ON(__mcpm_cluster_state(cluster) != CLUSTER_UP);
>> >> cpu_use_count[cpu][cluster]--;
>> >> if (cpu_use_count[cpu][cluster] == 0) {
>> >> - exynos_cpu_power_down(cpunr);
>> >> + /*
>> >> + * Bypass power down for CPU0 during suspend. This is being
>> >> + * taken care by the SYS_PWR_CFG bit in CORE0_SYS_PWR_REG.
>> >> + */
>> >> + if ((cpunr != 0) || (residency != S5P_CHECK_SLEEP))
>> >> + exynos_cpu_power_down(cpunr);
>> >>
>> >> if (exynos_cluster_unused(cluster)) {
>> >> exynos_cluster_power_down(cluster);
>> >> @@ -209,6 +217,11 @@ static void exynos_power_down(void)
>> >> /* Not dead at this point? Let our caller cope. */
>> >> }
>> >>
>> >> +static void exynos_power_down(void)
>> >> +{
>> >> + exynos_mcpm_power_down(0);
>> >> +}
>> >
>> > [...]
>> >
>> >> +static int notrace exynos_mcpm_cpu_suspend(unsigned long arg)
>> >> +{
>> >> + /* MCPM works with HW CPU identifiers */
>> >> + unsigned int mpidr = read_cpuid_mpidr();
>> >> + unsigned int cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
>> >> + unsigned int cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
>> >> +
>> >> + __raw_writel(0x0, sysram_base_addr + EXYNOS5420_CPU_STATE);
>> >> +
>> >> + mcpm_set_entry_vector(cpu, cluster, exynos_cpu_resume);
>> >> +
>> >> + /*
>> >> + * Pass S5P_CHECK_SLEEP flag to the MCPM back-end to indicate that
>> >> + * we are suspending the system and need to skip CPU0 power down.
>> >> + */
>> >> + mcpm_cpu_suspend(S5P_CHECK_SLEEP);
>> >
>> > NAK.
>> >
>> > When I say "local flag with local meaning", I don't want you to smuggle
>> > that flag through a public interface either. I find it rather inelegant
>> > to have the notion of special handling for CPU0 being spread around like
>> > that.
>> >
>> > If CPU0 is special, then it should be dealth with in one place only,
>> > ideally in the MCPM backend, so the rest of the kernel doesn't have to
>> > care.
>> >
>> > Again, here's what I mean:
>> >
>> > static void exynos_mcpm_down_handler(int flags)
>> > {
>> > [...]
>> > if ((cpunr != 0) || !(flags & SKIP_CPU_POWERDOWN_IF_CPU0))
>> > exynos_cpu_power_down(cpunr);
>> > [...]
>> > }
>> >
>> > static void exynos_mcpm_power_down()
>> > {
>> > exynos_mcpm_down_handler(0);
>> > }
>> >
>> > static void exynos_mcpm_suspend(u64 residency)
>> > {
>> > /*
>> > * Theresidency argument is ignored for now.
>> > * However, in the CPU suspend case, we bypass power down for
>> > * CPU0 as this is being taken care by the SYS_PWR_CFG bit in
>> > * CORE0_SYS_PWR_REG.
>> > */
>> > exynos_mcpm_down_handler(SKIP_CPU_POWERDOWN_IF_CPU0);
>> > }
>> >
>> > And SKIP_CPU_POWERDOWN_IF_CPU0 is defined in and visible to
>> > mcpm-exynos.c only.
>> Sorry if I am being dense, but the exynos_mcpm_suspend function would
>> get called from both the bL cpuidle driver as well the exynos pm code.
>
> What is that exynos pm code actually doing?
exynos pm code is shared across Exynos4 and 5 SoCs. It primarily does
a series of register configurations which are required to put the
system to sleep (some parts of these are SoC specific and others
common). It also populates the suspend_ops for exynos. In the current
patch, exynos_suspend_enter() is where I have plugged in the
mcpm_cpu_suspend call.
This patch is based on the S2R series for 5420
(http://comments.gmane.org/gmane.linux.kernel.samsung-soc/33898), you
may also have a look at that for a clearer picture.
>
>> We want to skip CPU0 only in case of the S2R case i.e. the pm code and
>> keep the CPU0 power down code for all other cases including CPUIdle.
>
> OK. If so I missed that somehow (hint hint).
>
>> If I call exynos_mcpm_down_handler with the flag in
>> exynos_mcpm_suspend(), CPUIdle will also skip CPU0 isn't it ?
>
> As it is, yes. You could logically use an infinite residency time
> (something like U64_MAX) to distinguish S2RAM from other types of
> suspend.
OK, I will use this rather than the S5P_CHECK_SLEEP macro.
>
> Yet, why is this SYS_PWR_CFG bit set outside of MCPM? Couldn't the MCPM
> backend handle it directly instead of expecting some other entity to do
> it?
Low power modes such as Sleep, Low Power Audio, AFTR (ARM Off Top
Running) require a series of register configurations as specified by
the UM to enter/exit them. All the exynos SoCs including 5420, do such
configurations (including sys_pwr_reg setup) as part of the
exynos_pm_prepare function in pm.c and so we just need to skip the cpu
power down.
Regards,
Abhilash
>
>
> Nicolas
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
2014-07-03 20:00 ` Abhilash Kesavan
@ 2014-07-04 4:13 ` Nicolas Pitre
-1 siblings, 0 replies; 130+ messages in thread
From: Nicolas Pitre @ 2014-07-04 4:13 UTC (permalink / raw)
To: Abhilash Kesavan
Cc: linux-samsung-soc, linux-arm-kernel, Kukjin Kim,
Lorenzo Pieralisi, Andrew Bresticker, Douglas Anderson
On Fri, 4 Jul 2014, Abhilash Kesavan wrote:
> Hi Nicolas,
>
> On Fri, Jul 4, 2014 at 12:30 AM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> > On Thu, 3 Jul 2014, Abhilash Kesavan wrote:
> >
> >> Hi Nicolas,
> >>
> >> On Thu, Jul 3, 2014 at 9:15 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> >> > On Thu, 3 Jul 2014, Abhilash Kesavan wrote:
> >> >
> >> >> On Thu, Jul 3, 2014 at 6:59 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> >> >> > Please, let's avoid going that route. There is no such special handling
> >> >> > needed if the API is sufficient. And the provided API allows you to
> >> >> > suspend a CPU or shut it down. It shouldn't matter at that level if
> >> >> > this is due to a cluster switch or a hotplug event. Do you really need
> >> >> > something else?
> >> >> No, just one local flag for suspend should be enough for me. Will remove these.
> >> >
> >> > [...]
> >> >
> >> >> Changes in v5:
> >> >> - Removed the MCPM flags and just used a local flag to
> >> >> indicate that we are suspending.
> >> >
> >> > [...]
> >> >
> >> >> -static void exynos_power_down(void)
> >> >> +static void exynos_mcpm_power_down(u64 residency)
> >> >> {
> >> >> unsigned int mpidr, cpu, cluster;
> >> >> bool last_man = false, skip_wfi = false;
> >> >> @@ -150,7 +153,12 @@ static void exynos_power_down(void)
> >> >> BUG_ON(__mcpm_cluster_state(cluster) != CLUSTER_UP);
> >> >> cpu_use_count[cpu][cluster]--;
> >> >> if (cpu_use_count[cpu][cluster] == 0) {
> >> >> - exynos_cpu_power_down(cpunr);
> >> >> + /*
> >> >> + * Bypass power down for CPU0 during suspend. This is being
> >> >> + * taken care by the SYS_PWR_CFG bit in CORE0_SYS_PWR_REG.
> >> >> + */
> >> >> + if ((cpunr != 0) || (residency != S5P_CHECK_SLEEP))
> >> >> + exynos_cpu_power_down(cpunr);
> >> >>
> >> >> if (exynos_cluster_unused(cluster)) {
> >> >> exynos_cluster_power_down(cluster);
> >> >> @@ -209,6 +217,11 @@ static void exynos_power_down(void)
> >> >> /* Not dead at this point? Let our caller cope. */
> >> >> }
> >> >>
> >> >> +static void exynos_power_down(void)
> >> >> +{
> >> >> + exynos_mcpm_power_down(0);
> >> >> +}
> >> >
> >> > [...]
> >> >
> >> >> +static int notrace exynos_mcpm_cpu_suspend(unsigned long arg)
> >> >> +{
> >> >> + /* MCPM works with HW CPU identifiers */
> >> >> + unsigned int mpidr = read_cpuid_mpidr();
> >> >> + unsigned int cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
> >> >> + unsigned int cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
> >> >> +
> >> >> + __raw_writel(0x0, sysram_base_addr + EXYNOS5420_CPU_STATE);
> >> >> +
> >> >> + mcpm_set_entry_vector(cpu, cluster, exynos_cpu_resume);
> >> >> +
> >> >> + /*
> >> >> + * Pass S5P_CHECK_SLEEP flag to the MCPM back-end to indicate that
> >> >> + * we are suspending the system and need to skip CPU0 power down.
> >> >> + */
> >> >> + mcpm_cpu_suspend(S5P_CHECK_SLEEP);
> >> >
> >> > NAK.
> >> >
> >> > When I say "local flag with local meaning", I don't want you to smuggle
> >> > that flag through a public interface either. I find it rather inelegant
> >> > to have the notion of special handling for CPU0 being spread around like
> >> > that.
> >> >
> >> > If CPU0 is special, then it should be dealth with in one place only,
> >> > ideally in the MCPM backend, so the rest of the kernel doesn't have to
> >> > care.
> >> >
> >> > Again, here's what I mean:
> >> >
> >> > static void exynos_mcpm_down_handler(int flags)
> >> > {
> >> > [...]
> >> > if ((cpunr != 0) || !(flags & SKIP_CPU_POWERDOWN_IF_CPU0))
> >> > exynos_cpu_power_down(cpunr);
> >> > [...]
> >> > }
> >> >
> >> > static void exynos_mcpm_power_down()
> >> > {
> >> > exynos_mcpm_down_handler(0);
> >> > }
> >> >
> >> > static void exynos_mcpm_suspend(u64 residency)
> >> > {
> >> > /*
> >> > * Theresidency argument is ignored for now.
> >> > * However, in the CPU suspend case, we bypass power down for
> >> > * CPU0 as this is being taken care by the SYS_PWR_CFG bit in
> >> > * CORE0_SYS_PWR_REG.
> >> > */
> >> > exynos_mcpm_down_handler(SKIP_CPU_POWERDOWN_IF_CPU0);
> >> > }
> >> >
> >> > And SKIP_CPU_POWERDOWN_IF_CPU0 is defined in and visible to
> >> > mcpm-exynos.c only.
> >> Sorry if I am being dense, but the exynos_mcpm_suspend function would
> >> get called from both the bL cpuidle driver as well the exynos pm code.
> >
> > What is that exynos pm code actually doing?
> exynos pm code is shared across Exynos4 and 5 SoCs. It primarily does
> a series of register configurations which are required to put the
> system to sleep (some parts of these are SoC specific and others
> common). It also populates the suspend_ops for exynos. In the current
> patch, exynos_suspend_enter() is where I have plugged in the
> mcpm_cpu_suspend call.
>
> This patch is based on the S2R series for 5420
> (http://comments.gmane.org/gmane.linux.kernel.samsung-soc/33898), you
> may also have a look at that for a clearer picture.
> >
> >> We want to skip CPU0 only in case of the S2R case i.e. the pm code and
> >> keep the CPU0 power down code for all other cases including CPUIdle.
> >
> > OK. If so I missed that somehow (hint hint).
> >
> >> If I call exynos_mcpm_down_handler with the flag in
> >> exynos_mcpm_suspend(), CPUIdle will also skip CPU0 isn't it ?
> >
> > As it is, yes. You could logically use an infinite residency time
> > (something like U64_MAX) to distinguish S2RAM from other types of
> > suspend.
> OK, I will use this rather than the S5P_CHECK_SLEEP macro.
Another suggestion which might possibly be better: why not looking for
the SYS_PWR_CFG bit in exynos_cpu_power_down() directly? After all,
exynos_cpu_power_down() is semantically supposed to do what its name
suggest and could simply do nothing if the proper conditions are already
in place.
Nicolas
^ permalink raw reply [flat|nested] 130+ messages in thread
* several messages
@ 2014-07-04 4:13 ` Nicolas Pitre
0 siblings, 0 replies; 130+ messages in thread
From: Nicolas Pitre @ 2014-07-04 4:13 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, 4 Jul 2014, Abhilash Kesavan wrote:
> Hi Nicolas,
>
> On Fri, Jul 4, 2014 at 12:30 AM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> > On Thu, 3 Jul 2014, Abhilash Kesavan wrote:
> >
> >> Hi Nicolas,
> >>
> >> On Thu, Jul 3, 2014 at 9:15 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> >> > On Thu, 3 Jul 2014, Abhilash Kesavan wrote:
> >> >
> >> >> On Thu, Jul 3, 2014 at 6:59 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> >> >> > Please, let's avoid going that route. There is no such special handling
> >> >> > needed if the API is sufficient. And the provided API allows you to
> >> >> > suspend a CPU or shut it down. It shouldn't matter at that level if
> >> >> > this is due to a cluster switch or a hotplug event. Do you really need
> >> >> > something else?
> >> >> No, just one local flag for suspend should be enough for me. Will remove these.
> >> >
> >> > [...]
> >> >
> >> >> Changes in v5:
> >> >> - Removed the MCPM flags and just used a local flag to
> >> >> indicate that we are suspending.
> >> >
> >> > [...]
> >> >
> >> >> -static void exynos_power_down(void)
> >> >> +static void exynos_mcpm_power_down(u64 residency)
> >> >> {
> >> >> unsigned int mpidr, cpu, cluster;
> >> >> bool last_man = false, skip_wfi = false;
> >> >> @@ -150,7 +153,12 @@ static void exynos_power_down(void)
> >> >> BUG_ON(__mcpm_cluster_state(cluster) != CLUSTER_UP);
> >> >> cpu_use_count[cpu][cluster]--;
> >> >> if (cpu_use_count[cpu][cluster] == 0) {
> >> >> - exynos_cpu_power_down(cpunr);
> >> >> + /*
> >> >> + * Bypass power down for CPU0 during suspend. This is being
> >> >> + * taken care by the SYS_PWR_CFG bit in CORE0_SYS_PWR_REG.
> >> >> + */
> >> >> + if ((cpunr != 0) || (residency != S5P_CHECK_SLEEP))
> >> >> + exynos_cpu_power_down(cpunr);
> >> >>
> >> >> if (exynos_cluster_unused(cluster)) {
> >> >> exynos_cluster_power_down(cluster);
> >> >> @@ -209,6 +217,11 @@ static void exynos_power_down(void)
> >> >> /* Not dead at this point? Let our caller cope. */
> >> >> }
> >> >>
> >> >> +static void exynos_power_down(void)
> >> >> +{
> >> >> + exynos_mcpm_power_down(0);
> >> >> +}
> >> >
> >> > [...]
> >> >
> >> >> +static int notrace exynos_mcpm_cpu_suspend(unsigned long arg)
> >> >> +{
> >> >> + /* MCPM works with HW CPU identifiers */
> >> >> + unsigned int mpidr = read_cpuid_mpidr();
> >> >> + unsigned int cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
> >> >> + unsigned int cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
> >> >> +
> >> >> + __raw_writel(0x0, sysram_base_addr + EXYNOS5420_CPU_STATE);
> >> >> +
> >> >> + mcpm_set_entry_vector(cpu, cluster, exynos_cpu_resume);
> >> >> +
> >> >> + /*
> >> >> + * Pass S5P_CHECK_SLEEP flag to the MCPM back-end to indicate that
> >> >> + * we are suspending the system and need to skip CPU0 power down.
> >> >> + */
> >> >> + mcpm_cpu_suspend(S5P_CHECK_SLEEP);
> >> >
> >> > NAK.
> >> >
> >> > When I say "local flag with local meaning", I don't want you to smuggle
> >> > that flag through a public interface either. I find it rather inelegant
> >> > to have the notion of special handling for CPU0 being spread around like
> >> > that.
> >> >
> >> > If CPU0 is special, then it should be dealth with in one place only,
> >> > ideally in the MCPM backend, so the rest of the kernel doesn't have to
> >> > care.
> >> >
> >> > Again, here's what I mean:
> >> >
> >> > static void exynos_mcpm_down_handler(int flags)
> >> > {
> >> > [...]
> >> > if ((cpunr != 0) || !(flags & SKIP_CPU_POWERDOWN_IF_CPU0))
> >> > exynos_cpu_power_down(cpunr);
> >> > [...]
> >> > }
> >> >
> >> > static void exynos_mcpm_power_down()
> >> > {
> >> > exynos_mcpm_down_handler(0);
> >> > }
> >> >
> >> > static void exynos_mcpm_suspend(u64 residency)
> >> > {
> >> > /*
> >> > * Theresidency argument is ignored for now.
> >> > * However, in the CPU suspend case, we bypass power down for
> >> > * CPU0 as this is being taken care by the SYS_PWR_CFG bit in
> >> > * CORE0_SYS_PWR_REG.
> >> > */
> >> > exynos_mcpm_down_handler(SKIP_CPU_POWERDOWN_IF_CPU0);
> >> > }
> >> >
> >> > And SKIP_CPU_POWERDOWN_IF_CPU0 is defined in and visible to
> >> > mcpm-exynos.c only.
> >> Sorry if I am being dense, but the exynos_mcpm_suspend function would
> >> get called from both the bL cpuidle driver as well the exynos pm code.
> >
> > What is that exynos pm code actually doing?
> exynos pm code is shared across Exynos4 and 5 SoCs. It primarily does
> a series of register configurations which are required to put the
> system to sleep (some parts of these are SoC specific and others
> common). It also populates the suspend_ops for exynos. In the current
> patch, exynos_suspend_enter() is where I have plugged in the
> mcpm_cpu_suspend call.
>
> This patch is based on the S2R series for 5420
> (http://comments.gmane.org/gmane.linux.kernel.samsung-soc/33898), you
> may also have a look at that for a clearer picture.
> >
> >> We want to skip CPU0 only in case of the S2R case i.e. the pm code and
> >> keep the CPU0 power down code for all other cases including CPUIdle.
> >
> > OK. If so I missed that somehow (hint hint).
> >
> >> If I call exynos_mcpm_down_handler with the flag in
> >> exynos_mcpm_suspend(), CPUIdle will also skip CPU0 isn't it ?
> >
> > As it is, yes. You could logically use an infinite residency time
> > (something like U64_MAX) to distinguish S2RAM from other types of
> > suspend.
> OK, I will use this rather than the S5P_CHECK_SLEEP macro.
Another suggestion which might possibly be better: why not looking for
the SYS_PWR_CFG bit in exynos_cpu_power_down() directly? After all,
exynos_cpu_power_down() is semantically supposed to do what its name
suggest and could simply do nothing if the proper conditions are already
in place.
Nicolas
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
2014-07-04 4:13 ` Nicolas Pitre
@ 2014-07-04 17:45 ` Abhilash Kesavan
-1 siblings, 0 replies; 130+ messages in thread
From: Abhilash Kesavan @ 2014-07-04 17:45 UTC (permalink / raw)
To: Nicolas Pitre
Cc: linux-samsung-soc, linux-arm-kernel, Kukjin Kim,
Lorenzo Pieralisi, Andrew Bresticker, Douglas Anderson
Hi Nicolas,
On Fri, Jul 4, 2014 at 9:43 AM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> On Fri, 4 Jul 2014, Abhilash Kesavan wrote:
>
>> Hi Nicolas,
>>
>> On Fri, Jul 4, 2014 at 12:30 AM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
>> > On Thu, 3 Jul 2014, Abhilash Kesavan wrote:
>> >
>> >> Hi Nicolas,
>> >>
>> >> On Thu, Jul 3, 2014 at 9:15 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
>> >> > On Thu, 3 Jul 2014, Abhilash Kesavan wrote:
>> >> >
>> >> >> On Thu, Jul 3, 2014 at 6:59 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
>> >> >> > Please, let's avoid going that route. There is no such special handling
>> >> >> > needed if the API is sufficient. And the provided API allows you to
>> >> >> > suspend a CPU or shut it down. It shouldn't matter at that level if
>> >> >> > this is due to a cluster switch or a hotplug event. Do you really need
>> >> >> > something else?
>> >> >> No, just one local flag for suspend should be enough for me. Will remove these.
>> >> >
>> >> > [...]
>> >> >
>> >> >> Changes in v5:
>> >> >> - Removed the MCPM flags and just used a local flag to
>> >> >> indicate that we are suspending.
>> >> >
>> >> > [...]
>> >> >
>> >> >> -static void exynos_power_down(void)
>> >> >> +static void exynos_mcpm_power_down(u64 residency)
>> >> >> {
>> >> >> unsigned int mpidr, cpu, cluster;
>> >> >> bool last_man = false, skip_wfi = false;
>> >> >> @@ -150,7 +153,12 @@ static void exynos_power_down(void)
>> >> >> BUG_ON(__mcpm_cluster_state(cluster) != CLUSTER_UP);
>> >> >> cpu_use_count[cpu][cluster]--;
>> >> >> if (cpu_use_count[cpu][cluster] == 0) {
>> >> >> - exynos_cpu_power_down(cpunr);
>> >> >> + /*
>> >> >> + * Bypass power down for CPU0 during suspend. This is being
>> >> >> + * taken care by the SYS_PWR_CFG bit in CORE0_SYS_PWR_REG.
>> >> >> + */
>> >> >> + if ((cpunr != 0) || (residency != S5P_CHECK_SLEEP))
>> >> >> + exynos_cpu_power_down(cpunr);
>> >> >>
>> >> >> if (exynos_cluster_unused(cluster)) {
>> >> >> exynos_cluster_power_down(cluster);
>> >> >> @@ -209,6 +217,11 @@ static void exynos_power_down(void)
>> >> >> /* Not dead at this point? Let our caller cope. */
>> >> >> }
>> >> >>
>> >> >> +static void exynos_power_down(void)
>> >> >> +{
>> >> >> + exynos_mcpm_power_down(0);
>> >> >> +}
>> >> >
>> >> > [...]
>> >> >
>> >> >> +static int notrace exynos_mcpm_cpu_suspend(unsigned long arg)
>> >> >> +{
>> >> >> + /* MCPM works with HW CPU identifiers */
>> >> >> + unsigned int mpidr = read_cpuid_mpidr();
>> >> >> + unsigned int cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
>> >> >> + unsigned int cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
>> >> >> +
>> >> >> + __raw_writel(0x0, sysram_base_addr + EXYNOS5420_CPU_STATE);
>> >> >> +
>> >> >> + mcpm_set_entry_vector(cpu, cluster, exynos_cpu_resume);
>> >> >> +
>> >> >> + /*
>> >> >> + * Pass S5P_CHECK_SLEEP flag to the MCPM back-end to indicate that
>> >> >> + * we are suspending the system and need to skip CPU0 power down.
>> >> >> + */
>> >> >> + mcpm_cpu_suspend(S5P_CHECK_SLEEP);
>> >> >
>> >> > NAK.
>> >> >
>> >> > When I say "local flag with local meaning", I don't want you to smuggle
>> >> > that flag through a public interface either. I find it rather inelegant
>> >> > to have the notion of special handling for CPU0 being spread around like
>> >> > that.
>> >> >
>> >> > If CPU0 is special, then it should be dealth with in one place only,
>> >> > ideally in the MCPM backend, so the rest of the kernel doesn't have to
>> >> > care.
>> >> >
>> >> > Again, here's what I mean:
>> >> >
>> >> > static void exynos_mcpm_down_handler(int flags)
>> >> > {
>> >> > [...]
>> >> > if ((cpunr != 0) || !(flags & SKIP_CPU_POWERDOWN_IF_CPU0))
>> >> > exynos_cpu_power_down(cpunr);
>> >> > [...]
>> >> > }
>> >> >
>> >> > static void exynos_mcpm_power_down()
>> >> > {
>> >> > exynos_mcpm_down_handler(0);
>> >> > }
>> >> >
>> >> > static void exynos_mcpm_suspend(u64 residency)
>> >> > {
>> >> > /*
>> >> > * Theresidency argument is ignored for now.
>> >> > * However, in the CPU suspend case, we bypass power down for
>> >> > * CPU0 as this is being taken care by the SYS_PWR_CFG bit in
>> >> > * CORE0_SYS_PWR_REG.
>> >> > */
>> >> > exynos_mcpm_down_handler(SKIP_CPU_POWERDOWN_IF_CPU0);
>> >> > }
>> >> >
>> >> > And SKIP_CPU_POWERDOWN_IF_CPU0 is defined in and visible to
>> >> > mcpm-exynos.c only.
>> >> Sorry if I am being dense, but the exynos_mcpm_suspend function would
>> >> get called from both the bL cpuidle driver as well the exynos pm code.
>> >
>> > What is that exynos pm code actually doing?
>> exynos pm code is shared across Exynos4 and 5 SoCs. It primarily does
>> a series of register configurations which are required to put the
>> system to sleep (some parts of these are SoC specific and others
>> common). It also populates the suspend_ops for exynos. In the current
>> patch, exynos_suspend_enter() is where I have plugged in the
>> mcpm_cpu_suspend call.
>>
>> This patch is based on the S2R series for 5420
>> (http://comments.gmane.org/gmane.linux.kernel.samsung-soc/33898), you
>> may also have a look at that for a clearer picture.
>> >
>> >> We want to skip CPU0 only in case of the S2R case i.e. the pm code and
>> >> keep the CPU0 power down code for all other cases including CPUIdle.
>> >
>> > OK. If so I missed that somehow (hint hint).
>> >
>> >> If I call exynos_mcpm_down_handler with the flag in
>> >> exynos_mcpm_suspend(), CPUIdle will also skip CPU0 isn't it ?
>> >
>> > As it is, yes. You could logically use an infinite residency time
>> > (something like U64_MAX) to distinguish S2RAM from other types of
>> > suspend.
>> OK, I will use this rather than the S5P_CHECK_SLEEP macro.
>
> Another suggestion which might possibly be better: why not looking for
> the SYS_PWR_CFG bit in exynos_cpu_power_down() directly? After all,
> exynos_cpu_power_down() is semantically supposed to do what its name
> suggest and could simply do nothing if the proper conditions are already
> in place.
I have implemented this and it works fine. Patch coming up.
Regards,
Abhilash
>
>
> Nicolas
^ permalink raw reply [flat|nested] 130+ messages in thread
* several messages
@ 2014-07-04 17:45 ` Abhilash Kesavan
0 siblings, 0 replies; 130+ messages in thread
From: Abhilash Kesavan @ 2014-07-04 17:45 UTC (permalink / raw)
To: linux-arm-kernel
Hi Nicolas,
On Fri, Jul 4, 2014 at 9:43 AM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> On Fri, 4 Jul 2014, Abhilash Kesavan wrote:
>
>> Hi Nicolas,
>>
>> On Fri, Jul 4, 2014 at 12:30 AM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
>> > On Thu, 3 Jul 2014, Abhilash Kesavan wrote:
>> >
>> >> Hi Nicolas,
>> >>
>> >> On Thu, Jul 3, 2014 at 9:15 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
>> >> > On Thu, 3 Jul 2014, Abhilash Kesavan wrote:
>> >> >
>> >> >> On Thu, Jul 3, 2014 at 6:59 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
>> >> >> > Please, let's avoid going that route. There is no such special handling
>> >> >> > needed if the API is sufficient. And the provided API allows you to
>> >> >> > suspend a CPU or shut it down. It shouldn't matter at that level if
>> >> >> > this is due to a cluster switch or a hotplug event. Do you really need
>> >> >> > something else?
>> >> >> No, just one local flag for suspend should be enough for me. Will remove these.
>> >> >
>> >> > [...]
>> >> >
>> >> >> Changes in v5:
>> >> >> - Removed the MCPM flags and just used a local flag to
>> >> >> indicate that we are suspending.
>> >> >
>> >> > [...]
>> >> >
>> >> >> -static void exynos_power_down(void)
>> >> >> +static void exynos_mcpm_power_down(u64 residency)
>> >> >> {
>> >> >> unsigned int mpidr, cpu, cluster;
>> >> >> bool last_man = false, skip_wfi = false;
>> >> >> @@ -150,7 +153,12 @@ static void exynos_power_down(void)
>> >> >> BUG_ON(__mcpm_cluster_state(cluster) != CLUSTER_UP);
>> >> >> cpu_use_count[cpu][cluster]--;
>> >> >> if (cpu_use_count[cpu][cluster] == 0) {
>> >> >> - exynos_cpu_power_down(cpunr);
>> >> >> + /*
>> >> >> + * Bypass power down for CPU0 during suspend. This is being
>> >> >> + * taken care by the SYS_PWR_CFG bit in CORE0_SYS_PWR_REG.
>> >> >> + */
>> >> >> + if ((cpunr != 0) || (residency != S5P_CHECK_SLEEP))
>> >> >> + exynos_cpu_power_down(cpunr);
>> >> >>
>> >> >> if (exynos_cluster_unused(cluster)) {
>> >> >> exynos_cluster_power_down(cluster);
>> >> >> @@ -209,6 +217,11 @@ static void exynos_power_down(void)
>> >> >> /* Not dead at this point? Let our caller cope. */
>> >> >> }
>> >> >>
>> >> >> +static void exynos_power_down(void)
>> >> >> +{
>> >> >> + exynos_mcpm_power_down(0);
>> >> >> +}
>> >> >
>> >> > [...]
>> >> >
>> >> >> +static int notrace exynos_mcpm_cpu_suspend(unsigned long arg)
>> >> >> +{
>> >> >> + /* MCPM works with HW CPU identifiers */
>> >> >> + unsigned int mpidr = read_cpuid_mpidr();
>> >> >> + unsigned int cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
>> >> >> + unsigned int cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
>> >> >> +
>> >> >> + __raw_writel(0x0, sysram_base_addr + EXYNOS5420_CPU_STATE);
>> >> >> +
>> >> >> + mcpm_set_entry_vector(cpu, cluster, exynos_cpu_resume);
>> >> >> +
>> >> >> + /*
>> >> >> + * Pass S5P_CHECK_SLEEP flag to the MCPM back-end to indicate that
>> >> >> + * we are suspending the system and need to skip CPU0 power down.
>> >> >> + */
>> >> >> + mcpm_cpu_suspend(S5P_CHECK_SLEEP);
>> >> >
>> >> > NAK.
>> >> >
>> >> > When I say "local flag with local meaning", I don't want you to smuggle
>> >> > that flag through a public interface either. I find it rather inelegant
>> >> > to have the notion of special handling for CPU0 being spread around like
>> >> > that.
>> >> >
>> >> > If CPU0 is special, then it should be dealth with in one place only,
>> >> > ideally in the MCPM backend, so the rest of the kernel doesn't have to
>> >> > care.
>> >> >
>> >> > Again, here's what I mean:
>> >> >
>> >> > static void exynos_mcpm_down_handler(int flags)
>> >> > {
>> >> > [...]
>> >> > if ((cpunr != 0) || !(flags & SKIP_CPU_POWERDOWN_IF_CPU0))
>> >> > exynos_cpu_power_down(cpunr);
>> >> > [...]
>> >> > }
>> >> >
>> >> > static void exynos_mcpm_power_down()
>> >> > {
>> >> > exynos_mcpm_down_handler(0);
>> >> > }
>> >> >
>> >> > static void exynos_mcpm_suspend(u64 residency)
>> >> > {
>> >> > /*
>> >> > * Theresidency argument is ignored for now.
>> >> > * However, in the CPU suspend case, we bypass power down for
>> >> > * CPU0 as this is being taken care by the SYS_PWR_CFG bit in
>> >> > * CORE0_SYS_PWR_REG.
>> >> > */
>> >> > exynos_mcpm_down_handler(SKIP_CPU_POWERDOWN_IF_CPU0);
>> >> > }
>> >> >
>> >> > And SKIP_CPU_POWERDOWN_IF_CPU0 is defined in and visible to
>> >> > mcpm-exynos.c only.
>> >> Sorry if I am being dense, but the exynos_mcpm_suspend function would
>> >> get called from both the bL cpuidle driver as well the exynos pm code.
>> >
>> > What is that exynos pm code actually doing?
>> exynos pm code is shared across Exynos4 and 5 SoCs. It primarily does
>> a series of register configurations which are required to put the
>> system to sleep (some parts of these are SoC specific and others
>> common). It also populates the suspend_ops for exynos. In the current
>> patch, exynos_suspend_enter() is where I have plugged in the
>> mcpm_cpu_suspend call.
>>
>> This patch is based on the S2R series for 5420
>> (http://comments.gmane.org/gmane.linux.kernel.samsung-soc/33898), you
>> may also have a look at that for a clearer picture.
>> >
>> >> We want to skip CPU0 only in case of the S2R case i.e. the pm code and
>> >> keep the CPU0 power down code for all other cases including CPUIdle.
>> >
>> > OK. If so I missed that somehow (hint hint).
>> >
>> >> If I call exynos_mcpm_down_handler with the flag in
>> >> exynos_mcpm_suspend(), CPUIdle will also skip CPU0 isn't it ?
>> >
>> > As it is, yes. You could logically use an infinite residency time
>> > (something like U64_MAX) to distinguish S2RAM from other types of
>> > suspend.
>> OK, I will use this rather than the S5P_CHECK_SLEEP macro.
>
> Another suggestion which might possibly be better: why not looking for
> the SYS_PWR_CFG bit in exynos_cpu_power_down() directly? After all,
> exynos_cpu_power_down() is semantically supposed to do what its name
> suggest and could simply do nothing if the proper conditions are already
> in place.
I have implemented this and it works fine. Patch coming up.
Regards,
Abhilash
>
>
> Nicolas
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH v6] ARM: EXYNOS: Use MCPM call-backs to support S2R on Exynos5420
2014-07-03 14:46 ` Abhilash Kesavan
@ 2014-07-04 17:47 ` Abhilash Kesavan
-1 siblings, 0 replies; 130+ messages in thread
From: Abhilash Kesavan @ 2014-07-04 17:47 UTC (permalink / raw)
To: linux-samsung-soc, linux-arm-kernel, kgene.kim, nicolas.pitre,
lorenzo.pieralisi
Cc: abrestic, dianders, kesavan.abhilash
Use the MCPM layer to handle core suspend/resume on Exynos5420.
Also, restore the entry address setup code post-resume.
Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
---
Changes in v2:
- Made use of the MCPM suspend/powered_up call-backs
Changes in v3:
- Used the residency value to indicate the entered state
Changes in v4:
- Checked if MCPM has been enabled to prevent build error
Changes in v5:
- Removed the MCPM flags and just used a local flag to
indicate that we are suspending.
Changes in v6:
- Read the SYS_PWR_REG value to decide if we are suspending
the system.
- Restore the SYS_PWR_REG value post-resume.
- Modified the comments to reflect the first change.
This has been tested both on an SMDK5420 and Peach Pit Chromebook on
next-20140704. Nicolas' boot cluster CCI enablement patches are in
linux-next now.
Here are the dependencies (some of these patches did not apply cleanly):
1) Cleanup patches for mach-exynos
http://comments.gmane.org/gmane.linux.kernel.samsung-soc/33772
2) PMU cleanup and refactoring for using DT
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg671625.html
3) Exynos5420 PMU/S2R Series
http://comments.gmane.org/gmane.linux.kernel.samsung-soc/33898
4) Exynos5420 CPUIdle Series which populates MCPM suspend/powered_up
call-backs.
www.gossamer-threads.com/lists/linux/kernel/1945347
https://patchwork.kernel.org/patch/4357461/
5) Exynos5420 MCPM cluster power down support
http://www.spinics.net/lists/arm-kernel/msg339988.html
6) TPM reset mask patch
http://www.spinics.net/lists/arm-kernel/msg341884.html
arch/arm/mach-exynos/mcpm-exynos.c | 55 ++++++++++++++++++++++++++----------
arch/arm/mach-exynos/pm.c | 42 +++++++++++++++++++++++++--
2 files changed, 80 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-exynos/mcpm-exynos.c b/arch/arm/mach-exynos/mcpm-exynos.c
index 2dd51cc..26670e7 100644
--- a/arch/arm/mach-exynos/mcpm-exynos.c
+++ b/arch/arm/mach-exynos/mcpm-exynos.c
@@ -15,6 +15,7 @@
#include <linux/delay.h>
#include <linux/io.h>
#include <linux/of_address.h>
+#include <linux/syscore_ops.h>
#include <asm/cputype.h>
#include <asm/cp15.h>
@@ -30,6 +31,8 @@
#define EXYNOS5420_USE_ARM_CORE_DOWN_STATE BIT(29)
#define EXYNOS5420_USE_L2_COMMON_UP_STATE BIT(30)
+static void __iomem *ns_sram_base_addr;
+
/*
* The common v7_exit_coherency_flush API could not be used because of the
* Erratum 799270 workaround. This macro is the same as the common one (in
@@ -129,11 +132,11 @@ static int exynos_power_up(unsigned int cpu, unsigned int cluster)
* and can only be executed on processors like A15 and A7 that hit the cache
* with the C bit clear in the SCTLR register.
*/
-static void exynos_power_down(void)
+static void exynos_mcpm_power_down(u64 residency)
{
unsigned int mpidr, cpu, cluster;
bool last_man = false, skip_wfi = false;
- unsigned int cpunr;
+ unsigned int cpunr, temp;
mpidr = read_cpuid_mpidr();
cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
@@ -150,7 +153,15 @@ static void exynos_power_down(void)
BUG_ON(__mcpm_cluster_state(cluster) != CLUSTER_UP);
cpu_use_count[cpu][cluster]--;
if (cpu_use_count[cpu][cluster] == 0) {
- exynos_cpu_power_down(cpunr);
+ /*
+ * Bypass power down for CPU0 during suspend. Check for
+ * the SYS_PWR_REG value to decide if we are suspending
+ * the system.
+ */
+ temp = __raw_readl(pmu_base_addr +
+ EXYNOS5_ARM_CORE0_SYS_PWR_REG);
+ if ((cpu != 0) || ((temp & S5P_CORE_LOCAL_PWR_EN) != 0))
+ exynos_cpu_power_down(cpunr);
if (exynos_cluster_unused(cluster)) {
exynos_cluster_power_down(cluster);
@@ -209,6 +220,11 @@ static void exynos_power_down(void)
/* Not dead at this point? Let our caller cope. */
}
+static void exynos_power_down(void)
+{
+ exynos_mcpm_power_down(0);
+}
+
static int exynos_wait_for_powerdown(unsigned int cpu, unsigned int cluster)
{
unsigned int tries = 100;
@@ -250,11 +266,11 @@ static void exynos_suspend(u64 residency)
{
unsigned int mpidr, cpunr;
- exynos_power_down();
+ exynos_mcpm_power_down(residency);
/*
* Execution reaches here only if cpu did not power down.
- * Hence roll back the changes done in exynos_power_down function.
+ * Hence roll back the changes done in exynos_mcpm_power_down function.
*
* CAUTION: "This function requires the stack data to be visible through
* power down and can only be executed on processors like A15 and A7
@@ -319,10 +335,26 @@ static const struct of_device_id exynos_dt_mcpm_match[] = {
{},
};
+static void exynos_mcpm_setup_entry_point(void)
+{
+ /*
+ * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
+ * as part of secondary_cpu_start(). Let's redirect it to the
+ * mcpm_entry_point(). This is done during both secondary boot-up as
+ * well as system resume.
+ */
+ __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
+ __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
+ __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
+}
+
+static struct syscore_ops exynos_mcpm_syscore_ops = {
+ .resume = exynos_mcpm_setup_entry_point,
+};
+
static int __init exynos_mcpm_init(void)
{
struct device_node *node;
- void __iomem *ns_sram_base_addr;
unsigned int value, i;
int ret;
@@ -389,16 +421,9 @@ static int __init exynos_mcpm_init(void)
__raw_writel(value, pmu_base_addr + EXYNOS_COMMON_OPTION(i));
}
- /*
- * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
- * as part of secondary_cpu_start(). Let's redirect it to the
- * mcpm_entry_point().
- */
- __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
- __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
- __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
+ exynos_mcpm_setup_entry_point();
- iounmap(ns_sram_base_addr);
+ register_syscore_ops(&exynos_mcpm_syscore_ops);
return ret;
}
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index 69cf678..d2751f4 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -24,6 +24,7 @@
#include <asm/cacheflush.h>
#include <asm/hardware/cache-l2x0.h>
+#include <asm/mcpm.h>
#include <asm/smp_scu.h>
#include <asm/suspend.h>
@@ -318,7 +319,10 @@ static void exynos_pm_prepare(void)
/* ensure at least INFORM0 has the resume address */
- pmu_raw_writel(virt_to_phys(exynos_cpu_resume), S5P_INFORM0);
+ if (soc_is_exynos5420() && IS_ENABLED(CONFIG_MCPM))
+ pmu_raw_writel(virt_to_phys(mcpm_entry_point), S5P_INFORM0);
+ else
+ pmu_raw_writel(virt_to_phys(exynos_cpu_resume), S5P_INFORM0);
if (soc_is_exynos5420()) {
tmp = __raw_readl(pmu_base_addr + EXYNOS5_ARM_L2_OPTION);
@@ -408,6 +412,11 @@ static void exynos_pm_resume(void)
unsigned int tmp;
if (soc_is_exynos5420()) {
+ /* Restore the CPU0 low power state register */
+ pmu_raw_writel(
+ __raw_readl(pmu_base_addr + EXYNOS5_ARM_CORE0_SYS_PWR_REG) |
+ S5P_CORE_LOCAL_PWR_EN, EXYNOS5_ARM_CORE0_SYS_PWR_REG);
+
/* Restore the sysram cpu state register */
__raw_writel(exynos5420_cpu_state,
sysram_base_addr + EXYNOS5420_CPU_STATE);
@@ -490,6 +499,28 @@ static struct syscore_ops exynos_pm_syscore_ops = {
.resume = exynos_pm_resume,
};
+static int notrace exynos_mcpm_cpu_suspend(unsigned long arg)
+{
+ /* MCPM works with HW CPU identifiers */
+ unsigned int mpidr = read_cpuid_mpidr();
+ unsigned int cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+ unsigned int cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+
+ __raw_writel(0x0, sysram_base_addr + EXYNOS5420_CPU_STATE);
+
+ mcpm_set_entry_vector(cpu, cluster, exynos_cpu_resume);
+
+ /*
+ * Residency value passed to mcpm_cpu_suspend back-end
+ * has to be given clear semantics. Set to 0 as a
+ * temporary value.
+ */
+ mcpm_cpu_suspend(0);
+
+ /* return value != 0 means failure */
+ return 1;
+}
+
/*
* Suspend Ops
*/
@@ -517,10 +548,17 @@ static int exynos_suspend_enter(suspend_state_t state)
flush_cache_all();
s3c_pm_check_store();
- ret = cpu_suspend(0, exynos_cpu_suspend);
+ /* Use the MCPM layer to suspend 5420 which is a multi-cluster SoC */
+ if (soc_is_exynos5420() && IS_ENABLED(CONFIG_MCPM))
+ ret = cpu_suspend(0, exynos_mcpm_cpu_suspend);
+ else
+ ret = cpu_suspend(0, exynos_cpu_suspend);
if (ret)
return ret;
+ if (soc_is_exynos5420() && IS_ENABLED(CONFIG_MCPM))
+ mcpm_cpu_powered_up();
+
s3c_pm_restore_uarts();
S3C_PMDBG("%s: wakeup stat: %08x\n", __func__,
--
1.7.9.5
^ permalink raw reply related [flat|nested] 130+ messages in thread
* [PATCH v6] ARM: EXYNOS: Use MCPM call-backs to support S2R on Exynos5420
@ 2014-07-04 17:47 ` Abhilash Kesavan
0 siblings, 0 replies; 130+ messages in thread
From: Abhilash Kesavan @ 2014-07-04 17:47 UTC (permalink / raw)
To: linux-arm-kernel
Use the MCPM layer to handle core suspend/resume on Exynos5420.
Also, restore the entry address setup code post-resume.
Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
---
Changes in v2:
- Made use of the MCPM suspend/powered_up call-backs
Changes in v3:
- Used the residency value to indicate the entered state
Changes in v4:
- Checked if MCPM has been enabled to prevent build error
Changes in v5:
- Removed the MCPM flags and just used a local flag to
indicate that we are suspending.
Changes in v6:
- Read the SYS_PWR_REG value to decide if we are suspending
the system.
- Restore the SYS_PWR_REG value post-resume.
- Modified the comments to reflect the first change.
This has been tested both on an SMDK5420 and Peach Pit Chromebook on
next-20140704. Nicolas' boot cluster CCI enablement patches are in
linux-next now.
Here are the dependencies (some of these patches did not apply cleanly):
1) Cleanup patches for mach-exynos
http://comments.gmane.org/gmane.linux.kernel.samsung-soc/33772
2) PMU cleanup and refactoring for using DT
https://www.mail-archive.com/linux-kernel at vger.kernel.org/msg671625.html
3) Exynos5420 PMU/S2R Series
http://comments.gmane.org/gmane.linux.kernel.samsung-soc/33898
4) Exynos5420 CPUIdle Series which populates MCPM suspend/powered_up
call-backs.
www.gossamer-threads.com/lists/linux/kernel/1945347
https://patchwork.kernel.org/patch/4357461/
5) Exynos5420 MCPM cluster power down support
http://www.spinics.net/lists/arm-kernel/msg339988.html
6) TPM reset mask patch
http://www.spinics.net/lists/arm-kernel/msg341884.html
arch/arm/mach-exynos/mcpm-exynos.c | 55 ++++++++++++++++++++++++++----------
arch/arm/mach-exynos/pm.c | 42 +++++++++++++++++++++++++--
2 files changed, 80 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-exynos/mcpm-exynos.c b/arch/arm/mach-exynos/mcpm-exynos.c
index 2dd51cc..26670e7 100644
--- a/arch/arm/mach-exynos/mcpm-exynos.c
+++ b/arch/arm/mach-exynos/mcpm-exynos.c
@@ -15,6 +15,7 @@
#include <linux/delay.h>
#include <linux/io.h>
#include <linux/of_address.h>
+#include <linux/syscore_ops.h>
#include <asm/cputype.h>
#include <asm/cp15.h>
@@ -30,6 +31,8 @@
#define EXYNOS5420_USE_ARM_CORE_DOWN_STATE BIT(29)
#define EXYNOS5420_USE_L2_COMMON_UP_STATE BIT(30)
+static void __iomem *ns_sram_base_addr;
+
/*
* The common v7_exit_coherency_flush API could not be used because of the
* Erratum 799270 workaround. This macro is the same as the common one (in
@@ -129,11 +132,11 @@ static int exynos_power_up(unsigned int cpu, unsigned int cluster)
* and can only be executed on processors like A15 and A7 that hit the cache
* with the C bit clear in the SCTLR register.
*/
-static void exynos_power_down(void)
+static void exynos_mcpm_power_down(u64 residency)
{
unsigned int mpidr, cpu, cluster;
bool last_man = false, skip_wfi = false;
- unsigned int cpunr;
+ unsigned int cpunr, temp;
mpidr = read_cpuid_mpidr();
cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
@@ -150,7 +153,15 @@ static void exynos_power_down(void)
BUG_ON(__mcpm_cluster_state(cluster) != CLUSTER_UP);
cpu_use_count[cpu][cluster]--;
if (cpu_use_count[cpu][cluster] == 0) {
- exynos_cpu_power_down(cpunr);
+ /*
+ * Bypass power down for CPU0 during suspend. Check for
+ * the SYS_PWR_REG value to decide if we are suspending
+ * the system.
+ */
+ temp = __raw_readl(pmu_base_addr +
+ EXYNOS5_ARM_CORE0_SYS_PWR_REG);
+ if ((cpu != 0) || ((temp & S5P_CORE_LOCAL_PWR_EN) != 0))
+ exynos_cpu_power_down(cpunr);
if (exynos_cluster_unused(cluster)) {
exynos_cluster_power_down(cluster);
@@ -209,6 +220,11 @@ static void exynos_power_down(void)
/* Not dead at this point? Let our caller cope. */
}
+static void exynos_power_down(void)
+{
+ exynos_mcpm_power_down(0);
+}
+
static int exynos_wait_for_powerdown(unsigned int cpu, unsigned int cluster)
{
unsigned int tries = 100;
@@ -250,11 +266,11 @@ static void exynos_suspend(u64 residency)
{
unsigned int mpidr, cpunr;
- exynos_power_down();
+ exynos_mcpm_power_down(residency);
/*
* Execution reaches here only if cpu did not power down.
- * Hence roll back the changes done in exynos_power_down function.
+ * Hence roll back the changes done in exynos_mcpm_power_down function.
*
* CAUTION: "This function requires the stack data to be visible through
* power down and can only be executed on processors like A15 and A7
@@ -319,10 +335,26 @@ static const struct of_device_id exynos_dt_mcpm_match[] = {
{},
};
+static void exynos_mcpm_setup_entry_point(void)
+{
+ /*
+ * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
+ * as part of secondary_cpu_start(). Let's redirect it to the
+ * mcpm_entry_point(). This is done during both secondary boot-up as
+ * well as system resume.
+ */
+ __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
+ __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
+ __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
+}
+
+static struct syscore_ops exynos_mcpm_syscore_ops = {
+ .resume = exynos_mcpm_setup_entry_point,
+};
+
static int __init exynos_mcpm_init(void)
{
struct device_node *node;
- void __iomem *ns_sram_base_addr;
unsigned int value, i;
int ret;
@@ -389,16 +421,9 @@ static int __init exynos_mcpm_init(void)
__raw_writel(value, pmu_base_addr + EXYNOS_COMMON_OPTION(i));
}
- /*
- * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
- * as part of secondary_cpu_start(). Let's redirect it to the
- * mcpm_entry_point().
- */
- __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
- __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
- __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
+ exynos_mcpm_setup_entry_point();
- iounmap(ns_sram_base_addr);
+ register_syscore_ops(&exynos_mcpm_syscore_ops);
return ret;
}
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index 69cf678..d2751f4 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -24,6 +24,7 @@
#include <asm/cacheflush.h>
#include <asm/hardware/cache-l2x0.h>
+#include <asm/mcpm.h>
#include <asm/smp_scu.h>
#include <asm/suspend.h>
@@ -318,7 +319,10 @@ static void exynos_pm_prepare(void)
/* ensure at least INFORM0 has the resume address */
- pmu_raw_writel(virt_to_phys(exynos_cpu_resume), S5P_INFORM0);
+ if (soc_is_exynos5420() && IS_ENABLED(CONFIG_MCPM))
+ pmu_raw_writel(virt_to_phys(mcpm_entry_point), S5P_INFORM0);
+ else
+ pmu_raw_writel(virt_to_phys(exynos_cpu_resume), S5P_INFORM0);
if (soc_is_exynos5420()) {
tmp = __raw_readl(pmu_base_addr + EXYNOS5_ARM_L2_OPTION);
@@ -408,6 +412,11 @@ static void exynos_pm_resume(void)
unsigned int tmp;
if (soc_is_exynos5420()) {
+ /* Restore the CPU0 low power state register */
+ pmu_raw_writel(
+ __raw_readl(pmu_base_addr + EXYNOS5_ARM_CORE0_SYS_PWR_REG) |
+ S5P_CORE_LOCAL_PWR_EN, EXYNOS5_ARM_CORE0_SYS_PWR_REG);
+
/* Restore the sysram cpu state register */
__raw_writel(exynos5420_cpu_state,
sysram_base_addr + EXYNOS5420_CPU_STATE);
@@ -490,6 +499,28 @@ static struct syscore_ops exynos_pm_syscore_ops = {
.resume = exynos_pm_resume,
};
+static int notrace exynos_mcpm_cpu_suspend(unsigned long arg)
+{
+ /* MCPM works with HW CPU identifiers */
+ unsigned int mpidr = read_cpuid_mpidr();
+ unsigned int cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+ unsigned int cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+
+ __raw_writel(0x0, sysram_base_addr + EXYNOS5420_CPU_STATE);
+
+ mcpm_set_entry_vector(cpu, cluster, exynos_cpu_resume);
+
+ /*
+ * Residency value passed to mcpm_cpu_suspend back-end
+ * has to be given clear semantics. Set to 0 as a
+ * temporary value.
+ */
+ mcpm_cpu_suspend(0);
+
+ /* return value != 0 means failure */
+ return 1;
+}
+
/*
* Suspend Ops
*/
@@ -517,10 +548,17 @@ static int exynos_suspend_enter(suspend_state_t state)
flush_cache_all();
s3c_pm_check_store();
- ret = cpu_suspend(0, exynos_cpu_suspend);
+ /* Use the MCPM layer to suspend 5420 which is a multi-cluster SoC */
+ if (soc_is_exynos5420() && IS_ENABLED(CONFIG_MCPM))
+ ret = cpu_suspend(0, exynos_mcpm_cpu_suspend);
+ else
+ ret = cpu_suspend(0, exynos_cpu_suspend);
if (ret)
return ret;
+ if (soc_is_exynos5420() && IS_ENABLED(CONFIG_MCPM))
+ mcpm_cpu_powered_up();
+
s3c_pm_restore_uarts();
S3C_PMDBG("%s: wakeup stat: %08x\n", __func__,
--
1.7.9.5
^ permalink raw reply related [flat|nested] 130+ messages in thread
* [PATCH v7] ARM: EXYNOS: Use MCPM call-backs to support S2R on Exynos5420
2014-07-04 17:47 ` Abhilash Kesavan
@ 2014-07-04 19:45 ` Abhilash Kesavan
-1 siblings, 0 replies; 130+ messages in thread
From: Abhilash Kesavan @ 2014-07-04 19:45 UTC (permalink / raw)
To: linux-samsung-soc, linux-arm-kernel, kgene.kim, nicolas.pitre,
lorenzo.pieralisi
Cc: abrestic, dianders, kesavan.abhilash
Use the MCPM layer to handle core suspend/resume on Exynos5420.
Also, restore the entry address setup code post-resume.
Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
---
Changes in v2:
- Made use of the MCPM suspend/powered_up call-backs
Changes in v3:
- Used the residency value to indicate the entered state
Changes in v4:
- Checked if MCPM has been enabled to prevent build error
Changes in v5:
- Removed the MCPM flags and just used a local flag to
indicate that we are suspending.
Changes in v6:
- Read the SYS_PWR_REG value to decide if we are suspending
the system.
- Restore the SYS_PWR_REG value post-resume.
- Modified the comments to reflect the first change.
Changes in v7:
- Add the suspend check in exynos_cpu_power_down() rather
than the MCPM back-end.
- Clean-up unnecessary changes related to earlier versions.
This has been tested both on an SMDK5420 and Peach Pit Chromebook on
next-20140704. Nicolas' boot cluster CCI enablement patches are in
linux-next now.
Here are the dependencies (some of these patches did not apply cleanly):
1) Cleanup patches for mach-exynos
http://comments.gmane.org/gmane.linux.kernel.samsung-soc/33772
2) PMU cleanup and refactoring for using DT
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg671625.html
3) Exynos5420 PMU/S2R Series
http://comments.gmane.org/gmane.linux.kernel.samsung-soc/33898
4) Exynos5420 CPUIdle Series which populates MCPM suspend/powered_up
call-backs.
www.gossamer-threads.com/lists/linux/kernel/1945347
https://patchwork.kernel.org/patch/4357461/
5) Exynos5420 MCPM cluster power down support
http://www.spinics.net/lists/arm-kernel/msg339988.html
6) TPM reset mask patch
http://www.spinics.net/lists/arm-kernel/msg341884.html
arch/arm/mach-exynos/mcpm-exynos.c | 32 +++++++++++++++-------
arch/arm/mach-exynos/pm.c | 54 ++++++++++++++++++++++++++++++++++++--
2 files changed, 74 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-exynos/mcpm-exynos.c b/arch/arm/mach-exynos/mcpm-exynos.c
index 2dd51cc..74ad772 100644
--- a/arch/arm/mach-exynos/mcpm-exynos.c
+++ b/arch/arm/mach-exynos/mcpm-exynos.c
@@ -15,6 +15,7 @@
#include <linux/delay.h>
#include <linux/io.h>
#include <linux/of_address.h>
+#include <linux/syscore_ops.h>
#include <asm/cputype.h>
#include <asm/cp15.h>
@@ -30,6 +31,8 @@
#define EXYNOS5420_USE_ARM_CORE_DOWN_STATE BIT(29)
#define EXYNOS5420_USE_L2_COMMON_UP_STATE BIT(30)
+static void __iomem *ns_sram_base_addr;
+
/*
* The common v7_exit_coherency_flush API could not be used because of the
* Erratum 799270 workaround. This macro is the same as the common one (in
@@ -319,10 +322,26 @@ static const struct of_device_id exynos_dt_mcpm_match[] = {
{},
};
+static void exynos_mcpm_setup_entry_point(void)
+{
+ /*
+ * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
+ * as part of secondary_cpu_start(). Let's redirect it to the
+ * mcpm_entry_point(). This is done during both secondary boot-up as
+ * well as system resume.
+ */
+ __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
+ __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
+ __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
+}
+
+static struct syscore_ops exynos_mcpm_syscore_ops = {
+ .resume = exynos_mcpm_setup_entry_point,
+};
+
static int __init exynos_mcpm_init(void)
{
struct device_node *node;
- void __iomem *ns_sram_base_addr;
unsigned int value, i;
int ret;
@@ -389,16 +408,9 @@ static int __init exynos_mcpm_init(void)
__raw_writel(value, pmu_base_addr + EXYNOS_COMMON_OPTION(i));
}
- /*
- * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
- * as part of secondary_cpu_start(). Let's redirect it to the
- * mcpm_entry_point().
- */
- __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
- __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
- __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
+ exynos_mcpm_setup_entry_point();
- iounmap(ns_sram_base_addr);
+ register_syscore_ops(&exynos_mcpm_syscore_ops);
return ret;
}
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index 69cf678..e2ba1e5 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -24,6 +24,7 @@
#include <asm/cacheflush.h>
#include <asm/hardware/cache-l2x0.h>
+#include <asm/mcpm.h>
#include <asm/smp_scu.h>
#include <asm/suspend.h>
@@ -123,6 +124,17 @@ static int exynos_irq_set_wake(struct irq_data *data, unsigned int state)
*/
void exynos_cpu_power_down(int cpu)
{
+ if (soc_is_exynos5420() && cpu == 0) {
+ /*
+ * Bypass power down for CPU0 during suspend. Check for
+ * the SYS_PWR_REG value to decide if we are suspending
+ * the system.
+ */
+ int val = __raw_readl(pmu_base_addr +
+ EXYNOS5_ARM_CORE0_SYS_PWR_REG);
+ if (!(val & S5P_CORE_LOCAL_PWR_EN))
+ return;
+ }
pmu_raw_writel(0, EXYNOS_ARM_CORE_CONFIGURATION(cpu));
}
@@ -318,7 +330,10 @@ static void exynos_pm_prepare(void)
/* ensure at least INFORM0 has the resume address */
- pmu_raw_writel(virt_to_phys(exynos_cpu_resume), S5P_INFORM0);
+ if (soc_is_exynos5420() && IS_ENABLED(CONFIG_MCPM))
+ pmu_raw_writel(virt_to_phys(mcpm_entry_point), S5P_INFORM0);
+ else
+ pmu_raw_writel(virt_to_phys(exynos_cpu_resume), S5P_INFORM0);
if (soc_is_exynos5420()) {
tmp = __raw_readl(pmu_base_addr + EXYNOS5_ARM_L2_OPTION);
@@ -408,6 +423,12 @@ static void exynos_pm_resume(void)
unsigned int tmp;
if (soc_is_exynos5420()) {
+ /* Restore the CPU0 low power state register */
+ tmp = __raw_readl(pmu_base_addr +
+ EXYNOS5_ARM_CORE0_SYS_PWR_REG);
+ pmu_raw_writel(tmp | S5P_CORE_LOCAL_PWR_EN,
+ EXYNOS5_ARM_CORE0_SYS_PWR_REG);
+
/* Restore the sysram cpu state register */
__raw_writel(exynos5420_cpu_state,
sysram_base_addr + EXYNOS5420_CPU_STATE);
@@ -490,6 +511,28 @@ static struct syscore_ops exynos_pm_syscore_ops = {
.resume = exynos_pm_resume,
};
+static int notrace exynos_mcpm_cpu_suspend(unsigned long arg)
+{
+ /* MCPM works with HW CPU identifiers */
+ unsigned int mpidr = read_cpuid_mpidr();
+ unsigned int cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+ unsigned int cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+
+ __raw_writel(0x0, sysram_base_addr + EXYNOS5420_CPU_STATE);
+
+ mcpm_set_entry_vector(cpu, cluster, exynos_cpu_resume);
+
+ /*
+ * Residency value passed to mcpm_cpu_suspend back-end
+ * has to be given clear semantics. Set to 0 as a
+ * temporary value.
+ */
+ mcpm_cpu_suspend(0);
+
+ /* return value != 0 means failure */
+ return 1;
+}
+
/*
* Suspend Ops
*/
@@ -517,10 +560,17 @@ static int exynos_suspend_enter(suspend_state_t state)
flush_cache_all();
s3c_pm_check_store();
- ret = cpu_suspend(0, exynos_cpu_suspend);
+ /* Use the MCPM layer to suspend 5420 which is a multi-cluster SoC */
+ if (soc_is_exynos5420() && IS_ENABLED(CONFIG_MCPM))
+ ret = cpu_suspend(0, exynos_mcpm_cpu_suspend);
+ else
+ ret = cpu_suspend(0, exynos_cpu_suspend);
if (ret)
return ret;
+ if (soc_is_exynos5420() && IS_ENABLED(CONFIG_MCPM))
+ mcpm_cpu_powered_up();
+
s3c_pm_restore_uarts();
S3C_PMDBG("%s: wakeup stat: %08x\n", __func__,
--
2.0.0
^ permalink raw reply related [flat|nested] 130+ messages in thread
* [PATCH v7] ARM: EXYNOS: Use MCPM call-backs to support S2R on Exynos5420
@ 2014-07-04 19:45 ` Abhilash Kesavan
0 siblings, 0 replies; 130+ messages in thread
From: Abhilash Kesavan @ 2014-07-04 19:45 UTC (permalink / raw)
To: linux-arm-kernel
Use the MCPM layer to handle core suspend/resume on Exynos5420.
Also, restore the entry address setup code post-resume.
Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
---
Changes in v2:
- Made use of the MCPM suspend/powered_up call-backs
Changes in v3:
- Used the residency value to indicate the entered state
Changes in v4:
- Checked if MCPM has been enabled to prevent build error
Changes in v5:
- Removed the MCPM flags and just used a local flag to
indicate that we are suspending.
Changes in v6:
- Read the SYS_PWR_REG value to decide if we are suspending
the system.
- Restore the SYS_PWR_REG value post-resume.
- Modified the comments to reflect the first change.
Changes in v7:
- Add the suspend check in exynos_cpu_power_down() rather
than the MCPM back-end.
- Clean-up unnecessary changes related to earlier versions.
This has been tested both on an SMDK5420 and Peach Pit Chromebook on
next-20140704. Nicolas' boot cluster CCI enablement patches are in
linux-next now.
Here are the dependencies (some of these patches did not apply cleanly):
1) Cleanup patches for mach-exynos
http://comments.gmane.org/gmane.linux.kernel.samsung-soc/33772
2) PMU cleanup and refactoring for using DT
https://www.mail-archive.com/linux-kernel at vger.kernel.org/msg671625.html
3) Exynos5420 PMU/S2R Series
http://comments.gmane.org/gmane.linux.kernel.samsung-soc/33898
4) Exynos5420 CPUIdle Series which populates MCPM suspend/powered_up
call-backs.
www.gossamer-threads.com/lists/linux/kernel/1945347
https://patchwork.kernel.org/patch/4357461/
5) Exynos5420 MCPM cluster power down support
http://www.spinics.net/lists/arm-kernel/msg339988.html
6) TPM reset mask patch
http://www.spinics.net/lists/arm-kernel/msg341884.html
arch/arm/mach-exynos/mcpm-exynos.c | 32 +++++++++++++++-------
arch/arm/mach-exynos/pm.c | 54 ++++++++++++++++++++++++++++++++++++--
2 files changed, 74 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-exynos/mcpm-exynos.c b/arch/arm/mach-exynos/mcpm-exynos.c
index 2dd51cc..74ad772 100644
--- a/arch/arm/mach-exynos/mcpm-exynos.c
+++ b/arch/arm/mach-exynos/mcpm-exynos.c
@@ -15,6 +15,7 @@
#include <linux/delay.h>
#include <linux/io.h>
#include <linux/of_address.h>
+#include <linux/syscore_ops.h>
#include <asm/cputype.h>
#include <asm/cp15.h>
@@ -30,6 +31,8 @@
#define EXYNOS5420_USE_ARM_CORE_DOWN_STATE BIT(29)
#define EXYNOS5420_USE_L2_COMMON_UP_STATE BIT(30)
+static void __iomem *ns_sram_base_addr;
+
/*
* The common v7_exit_coherency_flush API could not be used because of the
* Erratum 799270 workaround. This macro is the same as the common one (in
@@ -319,10 +322,26 @@ static const struct of_device_id exynos_dt_mcpm_match[] = {
{},
};
+static void exynos_mcpm_setup_entry_point(void)
+{
+ /*
+ * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
+ * as part of secondary_cpu_start(). Let's redirect it to the
+ * mcpm_entry_point(). This is done during both secondary boot-up as
+ * well as system resume.
+ */
+ __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
+ __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
+ __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
+}
+
+static struct syscore_ops exynos_mcpm_syscore_ops = {
+ .resume = exynos_mcpm_setup_entry_point,
+};
+
static int __init exynos_mcpm_init(void)
{
struct device_node *node;
- void __iomem *ns_sram_base_addr;
unsigned int value, i;
int ret;
@@ -389,16 +408,9 @@ static int __init exynos_mcpm_init(void)
__raw_writel(value, pmu_base_addr + EXYNOS_COMMON_OPTION(i));
}
- /*
- * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
- * as part of secondary_cpu_start(). Let's redirect it to the
- * mcpm_entry_point().
- */
- __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
- __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
- __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
+ exynos_mcpm_setup_entry_point();
- iounmap(ns_sram_base_addr);
+ register_syscore_ops(&exynos_mcpm_syscore_ops);
return ret;
}
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index 69cf678..e2ba1e5 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -24,6 +24,7 @@
#include <asm/cacheflush.h>
#include <asm/hardware/cache-l2x0.h>
+#include <asm/mcpm.h>
#include <asm/smp_scu.h>
#include <asm/suspend.h>
@@ -123,6 +124,17 @@ static int exynos_irq_set_wake(struct irq_data *data, unsigned int state)
*/
void exynos_cpu_power_down(int cpu)
{
+ if (soc_is_exynos5420() && cpu == 0) {
+ /*
+ * Bypass power down for CPU0 during suspend. Check for
+ * the SYS_PWR_REG value to decide if we are suspending
+ * the system.
+ */
+ int val = __raw_readl(pmu_base_addr +
+ EXYNOS5_ARM_CORE0_SYS_PWR_REG);
+ if (!(val & S5P_CORE_LOCAL_PWR_EN))
+ return;
+ }
pmu_raw_writel(0, EXYNOS_ARM_CORE_CONFIGURATION(cpu));
}
@@ -318,7 +330,10 @@ static void exynos_pm_prepare(void)
/* ensure at least INFORM0 has the resume address */
- pmu_raw_writel(virt_to_phys(exynos_cpu_resume), S5P_INFORM0);
+ if (soc_is_exynos5420() && IS_ENABLED(CONFIG_MCPM))
+ pmu_raw_writel(virt_to_phys(mcpm_entry_point), S5P_INFORM0);
+ else
+ pmu_raw_writel(virt_to_phys(exynos_cpu_resume), S5P_INFORM0);
if (soc_is_exynos5420()) {
tmp = __raw_readl(pmu_base_addr + EXYNOS5_ARM_L2_OPTION);
@@ -408,6 +423,12 @@ static void exynos_pm_resume(void)
unsigned int tmp;
if (soc_is_exynos5420()) {
+ /* Restore the CPU0 low power state register */
+ tmp = __raw_readl(pmu_base_addr +
+ EXYNOS5_ARM_CORE0_SYS_PWR_REG);
+ pmu_raw_writel(tmp | S5P_CORE_LOCAL_PWR_EN,
+ EXYNOS5_ARM_CORE0_SYS_PWR_REG);
+
/* Restore the sysram cpu state register */
__raw_writel(exynos5420_cpu_state,
sysram_base_addr + EXYNOS5420_CPU_STATE);
@@ -490,6 +511,28 @@ static struct syscore_ops exynos_pm_syscore_ops = {
.resume = exynos_pm_resume,
};
+static int notrace exynos_mcpm_cpu_suspend(unsigned long arg)
+{
+ /* MCPM works with HW CPU identifiers */
+ unsigned int mpidr = read_cpuid_mpidr();
+ unsigned int cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+ unsigned int cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+
+ __raw_writel(0x0, sysram_base_addr + EXYNOS5420_CPU_STATE);
+
+ mcpm_set_entry_vector(cpu, cluster, exynos_cpu_resume);
+
+ /*
+ * Residency value passed to mcpm_cpu_suspend back-end
+ * has to be given clear semantics. Set to 0 as a
+ * temporary value.
+ */
+ mcpm_cpu_suspend(0);
+
+ /* return value != 0 means failure */
+ return 1;
+}
+
/*
* Suspend Ops
*/
@@ -517,10 +560,17 @@ static int exynos_suspend_enter(suspend_state_t state)
flush_cache_all();
s3c_pm_check_store();
- ret = cpu_suspend(0, exynos_cpu_suspend);
+ /* Use the MCPM layer to suspend 5420 which is a multi-cluster SoC */
+ if (soc_is_exynos5420() && IS_ENABLED(CONFIG_MCPM))
+ ret = cpu_suspend(0, exynos_mcpm_cpu_suspend);
+ else
+ ret = cpu_suspend(0, exynos_cpu_suspend);
if (ret)
return ret;
+ if (soc_is_exynos5420() && IS_ENABLED(CONFIG_MCPM))
+ mcpm_cpu_powered_up();
+
s3c_pm_restore_uarts();
S3C_PMDBG("%s: wakeup stat: %08x\n", __func__,
--
2.0.0
^ permalink raw reply related [flat|nested] 130+ messages in thread
* Re: [PATCH v7] ARM: EXYNOS: Use MCPM call-backs to support S2R on Exynos5420
2014-07-04 19:45 ` Abhilash Kesavan
@ 2014-07-04 21:00 ` Nicolas Pitre
-1 siblings, 0 replies; 130+ messages in thread
From: Nicolas Pitre @ 2014-07-04 21:00 UTC (permalink / raw)
To: Abhilash Kesavan
Cc: linux-samsung-soc, linux-arm-kernel, kgene.kim,
lorenzo.pieralisi, abrestic, dianders, kesavan.abhilash
On Sat, 5 Jul 2014, Abhilash Kesavan wrote:
> Use the MCPM layer to handle core suspend/resume on Exynos5420.
> Also, restore the entry address setup code post-resume.
>
> Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
Acked-by: Nicolas Pitre <nico@linaro.org>
> ---
> Changes in v2:
> - Made use of the MCPM suspend/powered_up call-backs
> Changes in v3:
> - Used the residency value to indicate the entered state
> Changes in v4:
> - Checked if MCPM has been enabled to prevent build error
> Changes in v5:
> - Removed the MCPM flags and just used a local flag to
> indicate that we are suspending.
> Changes in v6:
> - Read the SYS_PWR_REG value to decide if we are suspending
> the system.
> - Restore the SYS_PWR_REG value post-resume.
> - Modified the comments to reflect the first change.
> Changes in v7:
> - Add the suspend check in exynos_cpu_power_down() rather
> than the MCPM back-end.
> - Clean-up unnecessary changes related to earlier versions.
>
> This has been tested both on an SMDK5420 and Peach Pit Chromebook on
> next-20140704. Nicolas' boot cluster CCI enablement patches are in
> linux-next now.
>
> Here are the dependencies (some of these patches did not apply cleanly):
> 1) Cleanup patches for mach-exynos
> http://comments.gmane.org/gmane.linux.kernel.samsung-soc/33772
>
> 2) PMU cleanup and refactoring for using DT
> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg671625.html
>
> 3) Exynos5420 PMU/S2R Series
> http://comments.gmane.org/gmane.linux.kernel.samsung-soc/33898
>
> 4) Exynos5420 CPUIdle Series which populates MCPM suspend/powered_up
> call-backs.
> www.gossamer-threads.com/lists/linux/kernel/1945347
> https://patchwork.kernel.org/patch/4357461/
>
> 5) Exynos5420 MCPM cluster power down support
> http://www.spinics.net/lists/arm-kernel/msg339988.html
>
> 6) TPM reset mask patch
> http://www.spinics.net/lists/arm-kernel/msg341884.html
>
> arch/arm/mach-exynos/mcpm-exynos.c | 32 +++++++++++++++-------
> arch/arm/mach-exynos/pm.c | 54 ++++++++++++++++++++++++++++++++++++--
> 2 files changed, 74 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/mcpm-exynos.c b/arch/arm/mach-exynos/mcpm-exynos.c
> index 2dd51cc..74ad772 100644
> --- a/arch/arm/mach-exynos/mcpm-exynos.c
> +++ b/arch/arm/mach-exynos/mcpm-exynos.c
> @@ -15,6 +15,7 @@
> #include <linux/delay.h>
> #include <linux/io.h>
> #include <linux/of_address.h>
> +#include <linux/syscore_ops.h>
>
> #include <asm/cputype.h>
> #include <asm/cp15.h>
> @@ -30,6 +31,8 @@
> #define EXYNOS5420_USE_ARM_CORE_DOWN_STATE BIT(29)
> #define EXYNOS5420_USE_L2_COMMON_UP_STATE BIT(30)
>
> +static void __iomem *ns_sram_base_addr;
> +
> /*
> * The common v7_exit_coherency_flush API could not be used because of the
> * Erratum 799270 workaround. This macro is the same as the common one (in
> @@ -319,10 +322,26 @@ static const struct of_device_id exynos_dt_mcpm_match[] = {
> {},
> };
>
> +static void exynos_mcpm_setup_entry_point(void)
> +{
> + /*
> + * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
> + * as part of secondary_cpu_start(). Let's redirect it to the
> + * mcpm_entry_point(). This is done during both secondary boot-up as
> + * well as system resume.
> + */
> + __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
> + __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
> + __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
> +}
> +
> +static struct syscore_ops exynos_mcpm_syscore_ops = {
> + .resume = exynos_mcpm_setup_entry_point,
> +};
> +
> static int __init exynos_mcpm_init(void)
> {
> struct device_node *node;
> - void __iomem *ns_sram_base_addr;
> unsigned int value, i;
> int ret;
>
> @@ -389,16 +408,9 @@ static int __init exynos_mcpm_init(void)
> __raw_writel(value, pmu_base_addr + EXYNOS_COMMON_OPTION(i));
> }
>
> - /*
> - * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
> - * as part of secondary_cpu_start(). Let's redirect it to the
> - * mcpm_entry_point().
> - */
> - __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
> - __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
> - __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
> + exynos_mcpm_setup_entry_point();
>
> - iounmap(ns_sram_base_addr);
> + register_syscore_ops(&exynos_mcpm_syscore_ops);
>
> return ret;
> }
> diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
> index 69cf678..e2ba1e5 100644
> --- a/arch/arm/mach-exynos/pm.c
> +++ b/arch/arm/mach-exynos/pm.c
> @@ -24,6 +24,7 @@
>
> #include <asm/cacheflush.h>
> #include <asm/hardware/cache-l2x0.h>
> +#include <asm/mcpm.h>
> #include <asm/smp_scu.h>
> #include <asm/suspend.h>
>
> @@ -123,6 +124,17 @@ static int exynos_irq_set_wake(struct irq_data *data, unsigned int state)
> */
> void exynos_cpu_power_down(int cpu)
> {
> + if (soc_is_exynos5420() && cpu == 0) {
> + /*
> + * Bypass power down for CPU0 during suspend. Check for
> + * the SYS_PWR_REG value to decide if we are suspending
> + * the system.
> + */
> + int val = __raw_readl(pmu_base_addr +
> + EXYNOS5_ARM_CORE0_SYS_PWR_REG);
> + if (!(val & S5P_CORE_LOCAL_PWR_EN))
> + return;
> + }
> pmu_raw_writel(0, EXYNOS_ARM_CORE_CONFIGURATION(cpu));
> }
>
> @@ -318,7 +330,10 @@ static void exynos_pm_prepare(void)
>
> /* ensure at least INFORM0 has the resume address */
>
> - pmu_raw_writel(virt_to_phys(exynos_cpu_resume), S5P_INFORM0);
> + if (soc_is_exynos5420() && IS_ENABLED(CONFIG_MCPM))
> + pmu_raw_writel(virt_to_phys(mcpm_entry_point), S5P_INFORM0);
> + else
> + pmu_raw_writel(virt_to_phys(exynos_cpu_resume), S5P_INFORM0);
>
> if (soc_is_exynos5420()) {
> tmp = __raw_readl(pmu_base_addr + EXYNOS5_ARM_L2_OPTION);
> @@ -408,6 +423,12 @@ static void exynos_pm_resume(void)
> unsigned int tmp;
>
> if (soc_is_exynos5420()) {
> + /* Restore the CPU0 low power state register */
> + tmp = __raw_readl(pmu_base_addr +
> + EXYNOS5_ARM_CORE0_SYS_PWR_REG);
> + pmu_raw_writel(tmp | S5P_CORE_LOCAL_PWR_EN,
> + EXYNOS5_ARM_CORE0_SYS_PWR_REG);
> +
> /* Restore the sysram cpu state register */
> __raw_writel(exynos5420_cpu_state,
> sysram_base_addr + EXYNOS5420_CPU_STATE);
> @@ -490,6 +511,28 @@ static struct syscore_ops exynos_pm_syscore_ops = {
> .resume = exynos_pm_resume,
> };
>
> +static int notrace exynos_mcpm_cpu_suspend(unsigned long arg)
> +{
> + /* MCPM works with HW CPU identifiers */
> + unsigned int mpidr = read_cpuid_mpidr();
> + unsigned int cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
> + unsigned int cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
> +
> + __raw_writel(0x0, sysram_base_addr + EXYNOS5420_CPU_STATE);
> +
> + mcpm_set_entry_vector(cpu, cluster, exynos_cpu_resume);
> +
> + /*
> + * Residency value passed to mcpm_cpu_suspend back-end
> + * has to be given clear semantics. Set to 0 as a
> + * temporary value.
> + */
> + mcpm_cpu_suspend(0);
> +
> + /* return value != 0 means failure */
> + return 1;
> +}
> +
> /*
> * Suspend Ops
> */
> @@ -517,10 +560,17 @@ static int exynos_suspend_enter(suspend_state_t state)
> flush_cache_all();
> s3c_pm_check_store();
>
> - ret = cpu_suspend(0, exynos_cpu_suspend);
> + /* Use the MCPM layer to suspend 5420 which is a multi-cluster SoC */
> + if (soc_is_exynos5420() && IS_ENABLED(CONFIG_MCPM))
> + ret = cpu_suspend(0, exynos_mcpm_cpu_suspend);
> + else
> + ret = cpu_suspend(0, exynos_cpu_suspend);
> if (ret)
> return ret;
>
> + if (soc_is_exynos5420() && IS_ENABLED(CONFIG_MCPM))
> + mcpm_cpu_powered_up();
> +
> s3c_pm_restore_uarts();
>
> S3C_PMDBG("%s: wakeup stat: %08x\n", __func__,
> --
> 2.0.0
>
>
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH v7] ARM: EXYNOS: Use MCPM call-backs to support S2R on Exynos5420
@ 2014-07-04 21:00 ` Nicolas Pitre
0 siblings, 0 replies; 130+ messages in thread
From: Nicolas Pitre @ 2014-07-04 21:00 UTC (permalink / raw)
To: linux-arm-kernel
On Sat, 5 Jul 2014, Abhilash Kesavan wrote:
> Use the MCPM layer to handle core suspend/resume on Exynos5420.
> Also, restore the entry address setup code post-resume.
>
> Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
Acked-by: Nicolas Pitre <nico@linaro.org>
> ---
> Changes in v2:
> - Made use of the MCPM suspend/powered_up call-backs
> Changes in v3:
> - Used the residency value to indicate the entered state
> Changes in v4:
> - Checked if MCPM has been enabled to prevent build error
> Changes in v5:
> - Removed the MCPM flags and just used a local flag to
> indicate that we are suspending.
> Changes in v6:
> - Read the SYS_PWR_REG value to decide if we are suspending
> the system.
> - Restore the SYS_PWR_REG value post-resume.
> - Modified the comments to reflect the first change.
> Changes in v7:
> - Add the suspend check in exynos_cpu_power_down() rather
> than the MCPM back-end.
> - Clean-up unnecessary changes related to earlier versions.
>
> This has been tested both on an SMDK5420 and Peach Pit Chromebook on
> next-20140704. Nicolas' boot cluster CCI enablement patches are in
> linux-next now.
>
> Here are the dependencies (some of these patches did not apply cleanly):
> 1) Cleanup patches for mach-exynos
> http://comments.gmane.org/gmane.linux.kernel.samsung-soc/33772
>
> 2) PMU cleanup and refactoring for using DT
> https://www.mail-archive.com/linux-kernel at vger.kernel.org/msg671625.html
>
> 3) Exynos5420 PMU/S2R Series
> http://comments.gmane.org/gmane.linux.kernel.samsung-soc/33898
>
> 4) Exynos5420 CPUIdle Series which populates MCPM suspend/powered_up
> call-backs.
> www.gossamer-threads.com/lists/linux/kernel/1945347
> https://patchwork.kernel.org/patch/4357461/
>
> 5) Exynos5420 MCPM cluster power down support
> http://www.spinics.net/lists/arm-kernel/msg339988.html
>
> 6) TPM reset mask patch
> http://www.spinics.net/lists/arm-kernel/msg341884.html
>
> arch/arm/mach-exynos/mcpm-exynos.c | 32 +++++++++++++++-------
> arch/arm/mach-exynos/pm.c | 54 ++++++++++++++++++++++++++++++++++++--
> 2 files changed, 74 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/mcpm-exynos.c b/arch/arm/mach-exynos/mcpm-exynos.c
> index 2dd51cc..74ad772 100644
> --- a/arch/arm/mach-exynos/mcpm-exynos.c
> +++ b/arch/arm/mach-exynos/mcpm-exynos.c
> @@ -15,6 +15,7 @@
> #include <linux/delay.h>
> #include <linux/io.h>
> #include <linux/of_address.h>
> +#include <linux/syscore_ops.h>
>
> #include <asm/cputype.h>
> #include <asm/cp15.h>
> @@ -30,6 +31,8 @@
> #define EXYNOS5420_USE_ARM_CORE_DOWN_STATE BIT(29)
> #define EXYNOS5420_USE_L2_COMMON_UP_STATE BIT(30)
>
> +static void __iomem *ns_sram_base_addr;
> +
> /*
> * The common v7_exit_coherency_flush API could not be used because of the
> * Erratum 799270 workaround. This macro is the same as the common one (in
> @@ -319,10 +322,26 @@ static const struct of_device_id exynos_dt_mcpm_match[] = {
> {},
> };
>
> +static void exynos_mcpm_setup_entry_point(void)
> +{
> + /*
> + * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
> + * as part of secondary_cpu_start(). Let's redirect it to the
> + * mcpm_entry_point(). This is done during both secondary boot-up as
> + * well as system resume.
> + */
> + __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
> + __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
> + __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
> +}
> +
> +static struct syscore_ops exynos_mcpm_syscore_ops = {
> + .resume = exynos_mcpm_setup_entry_point,
> +};
> +
> static int __init exynos_mcpm_init(void)
> {
> struct device_node *node;
> - void __iomem *ns_sram_base_addr;
> unsigned int value, i;
> int ret;
>
> @@ -389,16 +408,9 @@ static int __init exynos_mcpm_init(void)
> __raw_writel(value, pmu_base_addr + EXYNOS_COMMON_OPTION(i));
> }
>
> - /*
> - * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
> - * as part of secondary_cpu_start(). Let's redirect it to the
> - * mcpm_entry_point().
> - */
> - __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
> - __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
> - __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
> + exynos_mcpm_setup_entry_point();
>
> - iounmap(ns_sram_base_addr);
> + register_syscore_ops(&exynos_mcpm_syscore_ops);
>
> return ret;
> }
> diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
> index 69cf678..e2ba1e5 100644
> --- a/arch/arm/mach-exynos/pm.c
> +++ b/arch/arm/mach-exynos/pm.c
> @@ -24,6 +24,7 @@
>
> #include <asm/cacheflush.h>
> #include <asm/hardware/cache-l2x0.h>
> +#include <asm/mcpm.h>
> #include <asm/smp_scu.h>
> #include <asm/suspend.h>
>
> @@ -123,6 +124,17 @@ static int exynos_irq_set_wake(struct irq_data *data, unsigned int state)
> */
> void exynos_cpu_power_down(int cpu)
> {
> + if (soc_is_exynos5420() && cpu == 0) {
> + /*
> + * Bypass power down for CPU0 during suspend. Check for
> + * the SYS_PWR_REG value to decide if we are suspending
> + * the system.
> + */
> + int val = __raw_readl(pmu_base_addr +
> + EXYNOS5_ARM_CORE0_SYS_PWR_REG);
> + if (!(val & S5P_CORE_LOCAL_PWR_EN))
> + return;
> + }
> pmu_raw_writel(0, EXYNOS_ARM_CORE_CONFIGURATION(cpu));
> }
>
> @@ -318,7 +330,10 @@ static void exynos_pm_prepare(void)
>
> /* ensure at least INFORM0 has the resume address */
>
> - pmu_raw_writel(virt_to_phys(exynos_cpu_resume), S5P_INFORM0);
> + if (soc_is_exynos5420() && IS_ENABLED(CONFIG_MCPM))
> + pmu_raw_writel(virt_to_phys(mcpm_entry_point), S5P_INFORM0);
> + else
> + pmu_raw_writel(virt_to_phys(exynos_cpu_resume), S5P_INFORM0);
>
> if (soc_is_exynos5420()) {
> tmp = __raw_readl(pmu_base_addr + EXYNOS5_ARM_L2_OPTION);
> @@ -408,6 +423,12 @@ static void exynos_pm_resume(void)
> unsigned int tmp;
>
> if (soc_is_exynos5420()) {
> + /* Restore the CPU0 low power state register */
> + tmp = __raw_readl(pmu_base_addr +
> + EXYNOS5_ARM_CORE0_SYS_PWR_REG);
> + pmu_raw_writel(tmp | S5P_CORE_LOCAL_PWR_EN,
> + EXYNOS5_ARM_CORE0_SYS_PWR_REG);
> +
> /* Restore the sysram cpu state register */
> __raw_writel(exynos5420_cpu_state,
> sysram_base_addr + EXYNOS5420_CPU_STATE);
> @@ -490,6 +511,28 @@ static struct syscore_ops exynos_pm_syscore_ops = {
> .resume = exynos_pm_resume,
> };
>
> +static int notrace exynos_mcpm_cpu_suspend(unsigned long arg)
> +{
> + /* MCPM works with HW CPU identifiers */
> + unsigned int mpidr = read_cpuid_mpidr();
> + unsigned int cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
> + unsigned int cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
> +
> + __raw_writel(0x0, sysram_base_addr + EXYNOS5420_CPU_STATE);
> +
> + mcpm_set_entry_vector(cpu, cluster, exynos_cpu_resume);
> +
> + /*
> + * Residency value passed to mcpm_cpu_suspend back-end
> + * has to be given clear semantics. Set to 0 as a
> + * temporary value.
> + */
> + mcpm_cpu_suspend(0);
> +
> + /* return value != 0 means failure */
> + return 1;
> +}
> +
> /*
> * Suspend Ops
> */
> @@ -517,10 +560,17 @@ static int exynos_suspend_enter(suspend_state_t state)
> flush_cache_all();
> s3c_pm_check_store();
>
> - ret = cpu_suspend(0, exynos_cpu_suspend);
> + /* Use the MCPM layer to suspend 5420 which is a multi-cluster SoC */
> + if (soc_is_exynos5420() && IS_ENABLED(CONFIG_MCPM))
> + ret = cpu_suspend(0, exynos_mcpm_cpu_suspend);
> + else
> + ret = cpu_suspend(0, exynos_cpu_suspend);
> if (ret)
> return ret;
>
> + if (soc_is_exynos5420() && IS_ENABLED(CONFIG_MCPM))
> + mcpm_cpu_powered_up();
> +
> s3c_pm_restore_uarts();
>
> S3C_PMDBG("%s: wakeup stat: %08x\n", __func__,
> --
> 2.0.0
>
>
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: [PATCH v7] ARM: EXYNOS: Use MCPM call-backs to support S2R on Exynos5420
2014-07-04 21:00 ` Nicolas Pitre
@ 2014-07-04 21:21 ` Abhilash Kesavan
-1 siblings, 0 replies; 130+ messages in thread
From: Abhilash Kesavan @ 2014-07-04 21:21 UTC (permalink / raw)
To: Nicolas Pitre
Cc: linux-samsung-soc, linux-arm-kernel, Kukjin Kim,
Lorenzo Pieralisi, Andrew Bresticker, Douglas Anderson
On Sat, Jul 5, 2014 at 2:30 AM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> On Sat, 5 Jul 2014, Abhilash Kesavan wrote:
>
>> Use the MCPM layer to handle core suspend/resume on Exynos5420.
>> Also, restore the entry address setup code post-resume.
>>
>> Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
>
> Acked-by: Nicolas Pitre <nico@linaro.org>
This is one of the last missing bits for exynos MCPM. Thanks for your
patient reviews of all the exynos mcpm back-end patches.
Regards,
Abhilash
>
>
>> ---
>> Changes in v2:
>> - Made use of the MCPM suspend/powered_up call-backs
>> Changes in v3:
>> - Used the residency value to indicate the entered state
>> Changes in v4:
>> - Checked if MCPM has been enabled to prevent build error
>> Changes in v5:
>> - Removed the MCPM flags and just used a local flag to
>> indicate that we are suspending.
>> Changes in v6:
>> - Read the SYS_PWR_REG value to decide if we are suspending
>> the system.
>> - Restore the SYS_PWR_REG value post-resume.
>> - Modified the comments to reflect the first change.
>> Changes in v7:
>> - Add the suspend check in exynos_cpu_power_down() rather
>> than the MCPM back-end.
>> - Clean-up unnecessary changes related to earlier versions.
>>
>> This has been tested both on an SMDK5420 and Peach Pit Chromebook on
>> next-20140704. Nicolas' boot cluster CCI enablement patches are in
>> linux-next now.
>>
>> Here are the dependencies (some of these patches did not apply cleanly):
>> 1) Cleanup patches for mach-exynos
>> http://comments.gmane.org/gmane.linux.kernel.samsung-soc/33772
>>
>> 2) PMU cleanup and refactoring for using DT
>> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg671625.html
>>
>> 3) Exynos5420 PMU/S2R Series
>> http://comments.gmane.org/gmane.linux.kernel.samsung-soc/33898
>>
>> 4) Exynos5420 CPUIdle Series which populates MCPM suspend/powered_up
>> call-backs.
>> www.gossamer-threads.com/lists/linux/kernel/1945347
>> https://patchwork.kernel.org/patch/4357461/
>>
>> 5) Exynos5420 MCPM cluster power down support
>> http://www.spinics.net/lists/arm-kernel/msg339988.html
>>
>> 6) TPM reset mask patch
>> http://www.spinics.net/lists/arm-kernel/msg341884.html
>>
>> arch/arm/mach-exynos/mcpm-exynos.c | 32 +++++++++++++++-------
>> arch/arm/mach-exynos/pm.c | 54 ++++++++++++++++++++++++++++++++++++--
>> 2 files changed, 74 insertions(+), 12 deletions(-)
>>
>> diff --git a/arch/arm/mach-exynos/mcpm-exynos.c b/arch/arm/mach-exynos/mcpm-exynos.c
>> index 2dd51cc..74ad772 100644
>> --- a/arch/arm/mach-exynos/mcpm-exynos.c
>> +++ b/arch/arm/mach-exynos/mcpm-exynos.c
>> @@ -15,6 +15,7 @@
>> #include <linux/delay.h>
>> #include <linux/io.h>
>> #include <linux/of_address.h>
>> +#include <linux/syscore_ops.h>
>>
>> #include <asm/cputype.h>
>> #include <asm/cp15.h>
>> @@ -30,6 +31,8 @@
>> #define EXYNOS5420_USE_ARM_CORE_DOWN_STATE BIT(29)
>> #define EXYNOS5420_USE_L2_COMMON_UP_STATE BIT(30)
>>
>> +static void __iomem *ns_sram_base_addr;
>> +
>> /*
>> * The common v7_exit_coherency_flush API could not be used because of the
>> * Erratum 799270 workaround. This macro is the same as the common one (in
>> @@ -319,10 +322,26 @@ static const struct of_device_id exynos_dt_mcpm_match[] = {
>> {},
>> };
>>
>> +static void exynos_mcpm_setup_entry_point(void)
>> +{
>> + /*
>> + * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
>> + * as part of secondary_cpu_start(). Let's redirect it to the
>> + * mcpm_entry_point(). This is done during both secondary boot-up as
>> + * well as system resume.
>> + */
>> + __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
>> + __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
>> + __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
>> +}
>> +
>> +static struct syscore_ops exynos_mcpm_syscore_ops = {
>> + .resume = exynos_mcpm_setup_entry_point,
>> +};
>> +
>> static int __init exynos_mcpm_init(void)
>> {
>> struct device_node *node;
>> - void __iomem *ns_sram_base_addr;
>> unsigned int value, i;
>> int ret;
>>
>> @@ -389,16 +408,9 @@ static int __init exynos_mcpm_init(void)
>> __raw_writel(value, pmu_base_addr + EXYNOS_COMMON_OPTION(i));
>> }
>>
>> - /*
>> - * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
>> - * as part of secondary_cpu_start(). Let's redirect it to the
>> - * mcpm_entry_point().
>> - */
>> - __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
>> - __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
>> - __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
>> + exynos_mcpm_setup_entry_point();
>>
>> - iounmap(ns_sram_base_addr);
>> + register_syscore_ops(&exynos_mcpm_syscore_ops);
>>
>> return ret;
>> }
>> diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
>> index 69cf678..e2ba1e5 100644
>> --- a/arch/arm/mach-exynos/pm.c
>> +++ b/arch/arm/mach-exynos/pm.c
>> @@ -24,6 +24,7 @@
>>
>> #include <asm/cacheflush.h>
>> #include <asm/hardware/cache-l2x0.h>
>> +#include <asm/mcpm.h>
>> #include <asm/smp_scu.h>
>> #include <asm/suspend.h>
>>
>> @@ -123,6 +124,17 @@ static int exynos_irq_set_wake(struct irq_data *data, unsigned int state)
>> */
>> void exynos_cpu_power_down(int cpu)
>> {
>> + if (soc_is_exynos5420() && cpu == 0) {
>> + /*
>> + * Bypass power down for CPU0 during suspend. Check for
>> + * the SYS_PWR_REG value to decide if we are suspending
>> + * the system.
>> + */
>> + int val = __raw_readl(pmu_base_addr +
>> + EXYNOS5_ARM_CORE0_SYS_PWR_REG);
>> + if (!(val & S5P_CORE_LOCAL_PWR_EN))
>> + return;
>> + }
>> pmu_raw_writel(0, EXYNOS_ARM_CORE_CONFIGURATION(cpu));
>> }
>>
>> @@ -318,7 +330,10 @@ static void exynos_pm_prepare(void)
>>
>> /* ensure at least INFORM0 has the resume address */
>>
>> - pmu_raw_writel(virt_to_phys(exynos_cpu_resume), S5P_INFORM0);
>> + if (soc_is_exynos5420() && IS_ENABLED(CONFIG_MCPM))
>> + pmu_raw_writel(virt_to_phys(mcpm_entry_point), S5P_INFORM0);
>> + else
>> + pmu_raw_writel(virt_to_phys(exynos_cpu_resume), S5P_INFORM0);
>>
>> if (soc_is_exynos5420()) {
>> tmp = __raw_readl(pmu_base_addr + EXYNOS5_ARM_L2_OPTION);
>> @@ -408,6 +423,12 @@ static void exynos_pm_resume(void)
>> unsigned int tmp;
>>
>> if (soc_is_exynos5420()) {
>> + /* Restore the CPU0 low power state register */
>> + tmp = __raw_readl(pmu_base_addr +
>> + EXYNOS5_ARM_CORE0_SYS_PWR_REG);
>> + pmu_raw_writel(tmp | S5P_CORE_LOCAL_PWR_EN,
>> + EXYNOS5_ARM_CORE0_SYS_PWR_REG);
>> +
>> /* Restore the sysram cpu state register */
>> __raw_writel(exynos5420_cpu_state,
>> sysram_base_addr + EXYNOS5420_CPU_STATE);
>> @@ -490,6 +511,28 @@ static struct syscore_ops exynos_pm_syscore_ops = {
>> .resume = exynos_pm_resume,
>> };
>>
>> +static int notrace exynos_mcpm_cpu_suspend(unsigned long arg)
>> +{
>> + /* MCPM works with HW CPU identifiers */
>> + unsigned int mpidr = read_cpuid_mpidr();
>> + unsigned int cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
>> + unsigned int cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
>> +
>> + __raw_writel(0x0, sysram_base_addr + EXYNOS5420_CPU_STATE);
>> +
>> + mcpm_set_entry_vector(cpu, cluster, exynos_cpu_resume);
>> +
>> + /*
>> + * Residency value passed to mcpm_cpu_suspend back-end
>> + * has to be given clear semantics. Set to 0 as a
>> + * temporary value.
>> + */
>> + mcpm_cpu_suspend(0);
>> +
>> + /* return value != 0 means failure */
>> + return 1;
>> +}
>> +
>> /*
>> * Suspend Ops
>> */
>> @@ -517,10 +560,17 @@ static int exynos_suspend_enter(suspend_state_t state)
>> flush_cache_all();
>> s3c_pm_check_store();
>>
>> - ret = cpu_suspend(0, exynos_cpu_suspend);
>> + /* Use the MCPM layer to suspend 5420 which is a multi-cluster SoC */
>> + if (soc_is_exynos5420() && IS_ENABLED(CONFIG_MCPM))
>> + ret = cpu_suspend(0, exynos_mcpm_cpu_suspend);
>> + else
>> + ret = cpu_suspend(0, exynos_cpu_suspend);
>> if (ret)
>> return ret;
>>
>> + if (soc_is_exynos5420() && IS_ENABLED(CONFIG_MCPM))
>> + mcpm_cpu_powered_up();
>> +
>> s3c_pm_restore_uarts();
>>
>> S3C_PMDBG("%s: wakeup stat: %08x\n", __func__,
>> --
>> 2.0.0
>>
>>
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH v7] ARM: EXYNOS: Use MCPM call-backs to support S2R on Exynos5420
@ 2014-07-04 21:21 ` Abhilash Kesavan
0 siblings, 0 replies; 130+ messages in thread
From: Abhilash Kesavan @ 2014-07-04 21:21 UTC (permalink / raw)
To: linux-arm-kernel
On Sat, Jul 5, 2014 at 2:30 AM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> On Sat, 5 Jul 2014, Abhilash Kesavan wrote:
>
>> Use the MCPM layer to handle core suspend/resume on Exynos5420.
>> Also, restore the entry address setup code post-resume.
>>
>> Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
>
> Acked-by: Nicolas Pitre <nico@linaro.org>
This is one of the last missing bits for exynos MCPM. Thanks for your
patient reviews of all the exynos mcpm back-end patches.
Regards,
Abhilash
>
>
>> ---
>> Changes in v2:
>> - Made use of the MCPM suspend/powered_up call-backs
>> Changes in v3:
>> - Used the residency value to indicate the entered state
>> Changes in v4:
>> - Checked if MCPM has been enabled to prevent build error
>> Changes in v5:
>> - Removed the MCPM flags and just used a local flag to
>> indicate that we are suspending.
>> Changes in v6:
>> - Read the SYS_PWR_REG value to decide if we are suspending
>> the system.
>> - Restore the SYS_PWR_REG value post-resume.
>> - Modified the comments to reflect the first change.
>> Changes in v7:
>> - Add the suspend check in exynos_cpu_power_down() rather
>> than the MCPM back-end.
>> - Clean-up unnecessary changes related to earlier versions.
>>
>> This has been tested both on an SMDK5420 and Peach Pit Chromebook on
>> next-20140704. Nicolas' boot cluster CCI enablement patches are in
>> linux-next now.
>>
>> Here are the dependencies (some of these patches did not apply cleanly):
>> 1) Cleanup patches for mach-exynos
>> http://comments.gmane.org/gmane.linux.kernel.samsung-soc/33772
>>
>> 2) PMU cleanup and refactoring for using DT
>> https://www.mail-archive.com/linux-kernel at vger.kernel.org/msg671625.html
>>
>> 3) Exynos5420 PMU/S2R Series
>> http://comments.gmane.org/gmane.linux.kernel.samsung-soc/33898
>>
>> 4) Exynos5420 CPUIdle Series which populates MCPM suspend/powered_up
>> call-backs.
>> www.gossamer-threads.com/lists/linux/kernel/1945347
>> https://patchwork.kernel.org/patch/4357461/
>>
>> 5) Exynos5420 MCPM cluster power down support
>> http://www.spinics.net/lists/arm-kernel/msg339988.html
>>
>> 6) TPM reset mask patch
>> http://www.spinics.net/lists/arm-kernel/msg341884.html
>>
>> arch/arm/mach-exynos/mcpm-exynos.c | 32 +++++++++++++++-------
>> arch/arm/mach-exynos/pm.c | 54 ++++++++++++++++++++++++++++++++++++--
>> 2 files changed, 74 insertions(+), 12 deletions(-)
>>
>> diff --git a/arch/arm/mach-exynos/mcpm-exynos.c b/arch/arm/mach-exynos/mcpm-exynos.c
>> index 2dd51cc..74ad772 100644
>> --- a/arch/arm/mach-exynos/mcpm-exynos.c
>> +++ b/arch/arm/mach-exynos/mcpm-exynos.c
>> @@ -15,6 +15,7 @@
>> #include <linux/delay.h>
>> #include <linux/io.h>
>> #include <linux/of_address.h>
>> +#include <linux/syscore_ops.h>
>>
>> #include <asm/cputype.h>
>> #include <asm/cp15.h>
>> @@ -30,6 +31,8 @@
>> #define EXYNOS5420_USE_ARM_CORE_DOWN_STATE BIT(29)
>> #define EXYNOS5420_USE_L2_COMMON_UP_STATE BIT(30)
>>
>> +static void __iomem *ns_sram_base_addr;
>> +
>> /*
>> * The common v7_exit_coherency_flush API could not be used because of the
>> * Erratum 799270 workaround. This macro is the same as the common one (in
>> @@ -319,10 +322,26 @@ static const struct of_device_id exynos_dt_mcpm_match[] = {
>> {},
>> };
>>
>> +static void exynos_mcpm_setup_entry_point(void)
>> +{
>> + /*
>> + * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
>> + * as part of secondary_cpu_start(). Let's redirect it to the
>> + * mcpm_entry_point(). This is done during both secondary boot-up as
>> + * well as system resume.
>> + */
>> + __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
>> + __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
>> + __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
>> +}
>> +
>> +static struct syscore_ops exynos_mcpm_syscore_ops = {
>> + .resume = exynos_mcpm_setup_entry_point,
>> +};
>> +
>> static int __init exynos_mcpm_init(void)
>> {
>> struct device_node *node;
>> - void __iomem *ns_sram_base_addr;
>> unsigned int value, i;
>> int ret;
>>
>> @@ -389,16 +408,9 @@ static int __init exynos_mcpm_init(void)
>> __raw_writel(value, pmu_base_addr + EXYNOS_COMMON_OPTION(i));
>> }
>>
>> - /*
>> - * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
>> - * as part of secondary_cpu_start(). Let's redirect it to the
>> - * mcpm_entry_point().
>> - */
>> - __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
>> - __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
>> - __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
>> + exynos_mcpm_setup_entry_point();
>>
>> - iounmap(ns_sram_base_addr);
>> + register_syscore_ops(&exynos_mcpm_syscore_ops);
>>
>> return ret;
>> }
>> diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
>> index 69cf678..e2ba1e5 100644
>> --- a/arch/arm/mach-exynos/pm.c
>> +++ b/arch/arm/mach-exynos/pm.c
>> @@ -24,6 +24,7 @@
>>
>> #include <asm/cacheflush.h>
>> #include <asm/hardware/cache-l2x0.h>
>> +#include <asm/mcpm.h>
>> #include <asm/smp_scu.h>
>> #include <asm/suspend.h>
>>
>> @@ -123,6 +124,17 @@ static int exynos_irq_set_wake(struct irq_data *data, unsigned int state)
>> */
>> void exynos_cpu_power_down(int cpu)
>> {
>> + if (soc_is_exynos5420() && cpu == 0) {
>> + /*
>> + * Bypass power down for CPU0 during suspend. Check for
>> + * the SYS_PWR_REG value to decide if we are suspending
>> + * the system.
>> + */
>> + int val = __raw_readl(pmu_base_addr +
>> + EXYNOS5_ARM_CORE0_SYS_PWR_REG);
>> + if (!(val & S5P_CORE_LOCAL_PWR_EN))
>> + return;
>> + }
>> pmu_raw_writel(0, EXYNOS_ARM_CORE_CONFIGURATION(cpu));
>> }
>>
>> @@ -318,7 +330,10 @@ static void exynos_pm_prepare(void)
>>
>> /* ensure at least INFORM0 has the resume address */
>>
>> - pmu_raw_writel(virt_to_phys(exynos_cpu_resume), S5P_INFORM0);
>> + if (soc_is_exynos5420() && IS_ENABLED(CONFIG_MCPM))
>> + pmu_raw_writel(virt_to_phys(mcpm_entry_point), S5P_INFORM0);
>> + else
>> + pmu_raw_writel(virt_to_phys(exynos_cpu_resume), S5P_INFORM0);
>>
>> if (soc_is_exynos5420()) {
>> tmp = __raw_readl(pmu_base_addr + EXYNOS5_ARM_L2_OPTION);
>> @@ -408,6 +423,12 @@ static void exynos_pm_resume(void)
>> unsigned int tmp;
>>
>> if (soc_is_exynos5420()) {
>> + /* Restore the CPU0 low power state register */
>> + tmp = __raw_readl(pmu_base_addr +
>> + EXYNOS5_ARM_CORE0_SYS_PWR_REG);
>> + pmu_raw_writel(tmp | S5P_CORE_LOCAL_PWR_EN,
>> + EXYNOS5_ARM_CORE0_SYS_PWR_REG);
>> +
>> /* Restore the sysram cpu state register */
>> __raw_writel(exynos5420_cpu_state,
>> sysram_base_addr + EXYNOS5420_CPU_STATE);
>> @@ -490,6 +511,28 @@ static struct syscore_ops exynos_pm_syscore_ops = {
>> .resume = exynos_pm_resume,
>> };
>>
>> +static int notrace exynos_mcpm_cpu_suspend(unsigned long arg)
>> +{
>> + /* MCPM works with HW CPU identifiers */
>> + unsigned int mpidr = read_cpuid_mpidr();
>> + unsigned int cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
>> + unsigned int cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
>> +
>> + __raw_writel(0x0, sysram_base_addr + EXYNOS5420_CPU_STATE);
>> +
>> + mcpm_set_entry_vector(cpu, cluster, exynos_cpu_resume);
>> +
>> + /*
>> + * Residency value passed to mcpm_cpu_suspend back-end
>> + * has to be given clear semantics. Set to 0 as a
>> + * temporary value.
>> + */
>> + mcpm_cpu_suspend(0);
>> +
>> + /* return value != 0 means failure */
>> + return 1;
>> +}
>> +
>> /*
>> * Suspend Ops
>> */
>> @@ -517,10 +560,17 @@ static int exynos_suspend_enter(suspend_state_t state)
>> flush_cache_all();
>> s3c_pm_check_store();
>>
>> - ret = cpu_suspend(0, exynos_cpu_suspend);
>> + /* Use the MCPM layer to suspend 5420 which is a multi-cluster SoC */
>> + if (soc_is_exynos5420() && IS_ENABLED(CONFIG_MCPM))
>> + ret = cpu_suspend(0, exynos_mcpm_cpu_suspend);
>> + else
>> + ret = cpu_suspend(0, exynos_cpu_suspend);
>> if (ret)
>> return ret;
>>
>> + if (soc_is_exynos5420() && IS_ENABLED(CONFIG_MCPM))
>> + mcpm_cpu_powered_up();
>> +
>> s3c_pm_restore_uarts();
>>
>> S3C_PMDBG("%s: wakeup stat: %08x\n", __func__,
>> --
>> 2.0.0
>>
>>
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: [PATCH v7] ARM: EXYNOS: Use MCPM call-backs to support S2R on Exynos5420
2014-07-04 21:21 ` Abhilash Kesavan
@ 2014-07-08 10:53 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 130+ messages in thread
From: Lorenzo Pieralisi @ 2014-07-08 10:53 UTC (permalink / raw)
To: Abhilash Kesavan
Cc: Nicolas Pitre, linux-samsung-soc, linux-arm-kernel, Kukjin Kim,
Andrew Bresticker, Douglas Anderson
On Fri, Jul 04, 2014 at 10:21:56PM +0100, Abhilash Kesavan wrote:
> On Sat, Jul 5, 2014 at 2:30 AM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> > On Sat, 5 Jul 2014, Abhilash Kesavan wrote:
> >
> >> Use the MCPM layer to handle core suspend/resume on Exynos5420.
> >> Also, restore the entry address setup code post-resume.
> >>
> >> Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
> >
> > Acked-by: Nicolas Pitre <nico@linaro.org>
> This is one of the last missing bits for exynos MCPM. Thanks for your
> patient reviews of all the exynos mcpm back-end patches.
Sorry for the delay in getting back to you.
You still need to handle the residency parameter in the MCPM suspend call
properly to differentiate between core gating and cluster gating.
CPUidle might want to request a state that allows for core gating
residency but not cluster gating one, in that case the last man
standing must not shutdown the cluster.
This must be handled in the power down function, and it can be done
in a separate patch since it is an optimization. Current MCPM interface has
all it is needed to handle this properly, and I am keen on patching the
CPUidle bL driver to pass the actual residency instead of hardcoding it
to 0 (ie on TC2 it was not needed, no core gating).
Lorenzo
>
> Regards,
> Abhilash
> >
> >
> >> ---
> >> Changes in v2:
> >> - Made use of the MCPM suspend/powered_up call-backs
> >> Changes in v3:
> >> - Used the residency value to indicate the entered state
> >> Changes in v4:
> >> - Checked if MCPM has been enabled to prevent build error
> >> Changes in v5:
> >> - Removed the MCPM flags and just used a local flag to
> >> indicate that we are suspending.
> >> Changes in v6:
> >> - Read the SYS_PWR_REG value to decide if we are suspending
> >> the system.
> >> - Restore the SYS_PWR_REG value post-resume.
> >> - Modified the comments to reflect the first change.
> >> Changes in v7:
> >> - Add the suspend check in exynos_cpu_power_down() rather
> >> than the MCPM back-end.
> >> - Clean-up unnecessary changes related to earlier versions.
> >>
> >> This has been tested both on an SMDK5420 and Peach Pit Chromebook on
> >> next-20140704. Nicolas' boot cluster CCI enablement patches are in
> >> linux-next now.
> >>
> >> Here are the dependencies (some of these patches did not apply cleanly):
> >> 1) Cleanup patches for mach-exynos
> >> http://comments.gmane.org/gmane.linux.kernel.samsung-soc/33772
> >>
> >> 2) PMU cleanup and refactoring for using DT
> >> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg671625.html
> >>
> >> 3) Exynos5420 PMU/S2R Series
> >> http://comments.gmane.org/gmane.linux.kernel.samsung-soc/33898
> >>
> >> 4) Exynos5420 CPUIdle Series which populates MCPM suspend/powered_up
> >> call-backs.
> >> www.gossamer-threads.com/lists/linux/kernel/1945347
> >> https://patchwork.kernel.org/patch/4357461/
> >>
> >> 5) Exynos5420 MCPM cluster power down support
> >> http://www.spinics.net/lists/arm-kernel/msg339988.html
> >>
> >> 6) TPM reset mask patch
> >> http://www.spinics.net/lists/arm-kernel/msg341884.html
> >>
> >> arch/arm/mach-exynos/mcpm-exynos.c | 32 +++++++++++++++-------
> >> arch/arm/mach-exynos/pm.c | 54 ++++++++++++++++++++++++++++++++++++--
> >> 2 files changed, 74 insertions(+), 12 deletions(-)
> >>
> >> diff --git a/arch/arm/mach-exynos/mcpm-exynos.c b/arch/arm/mach-exynos/mcpm-exynos.c
> >> index 2dd51cc..74ad772 100644
> >> --- a/arch/arm/mach-exynos/mcpm-exynos.c
> >> +++ b/arch/arm/mach-exynos/mcpm-exynos.c
> >> @@ -15,6 +15,7 @@
> >> #include <linux/delay.h>
> >> #include <linux/io.h>
> >> #include <linux/of_address.h>
> >> +#include <linux/syscore_ops.h>
> >>
> >> #include <asm/cputype.h>
> >> #include <asm/cp15.h>
> >> @@ -30,6 +31,8 @@
> >> #define EXYNOS5420_USE_ARM_CORE_DOWN_STATE BIT(29)
> >> #define EXYNOS5420_USE_L2_COMMON_UP_STATE BIT(30)
> >>
> >> +static void __iomem *ns_sram_base_addr;
> >> +
> >> /*
> >> * The common v7_exit_coherency_flush API could not be used because of the
> >> * Erratum 799270 workaround. This macro is the same as the common one (in
> >> @@ -319,10 +322,26 @@ static const struct of_device_id exynos_dt_mcpm_match[] = {
> >> {},
> >> };
> >>
> >> +static void exynos_mcpm_setup_entry_point(void)
> >> +{
> >> + /*
> >> + * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
> >> + * as part of secondary_cpu_start(). Let's redirect it to the
> >> + * mcpm_entry_point(). This is done during both secondary boot-up as
> >> + * well as system resume.
> >> + */
> >> + __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
> >> + __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
> >> + __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
> >> +}
> >> +
> >> +static struct syscore_ops exynos_mcpm_syscore_ops = {
> >> + .resume = exynos_mcpm_setup_entry_point,
> >> +};
> >> +
> >> static int __init exynos_mcpm_init(void)
> >> {
> >> struct device_node *node;
> >> - void __iomem *ns_sram_base_addr;
> >> unsigned int value, i;
> >> int ret;
> >>
> >> @@ -389,16 +408,9 @@ static int __init exynos_mcpm_init(void)
> >> __raw_writel(value, pmu_base_addr + EXYNOS_COMMON_OPTION(i));
> >> }
> >>
> >> - /*
> >> - * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
> >> - * as part of secondary_cpu_start(). Let's redirect it to the
> >> - * mcpm_entry_point().
> >> - */
> >> - __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
> >> - __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
> >> - __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
> >> + exynos_mcpm_setup_entry_point();
> >>
> >> - iounmap(ns_sram_base_addr);
> >> + register_syscore_ops(&exynos_mcpm_syscore_ops);
> >>
> >> return ret;
> >> }
> >> diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
> >> index 69cf678..e2ba1e5 100644
> >> --- a/arch/arm/mach-exynos/pm.c
> >> +++ b/arch/arm/mach-exynos/pm.c
> >> @@ -24,6 +24,7 @@
> >>
> >> #include <asm/cacheflush.h>
> >> #include <asm/hardware/cache-l2x0.h>
> >> +#include <asm/mcpm.h>
> >> #include <asm/smp_scu.h>
> >> #include <asm/suspend.h>
> >>
> >> @@ -123,6 +124,17 @@ static int exynos_irq_set_wake(struct irq_data *data, unsigned int state)
> >> */
> >> void exynos_cpu_power_down(int cpu)
> >> {
> >> + if (soc_is_exynos5420() && cpu == 0) {
> >> + /*
> >> + * Bypass power down for CPU0 during suspend. Check for
> >> + * the SYS_PWR_REG value to decide if we are suspending
> >> + * the system.
> >> + */
> >> + int val = __raw_readl(pmu_base_addr +
> >> + EXYNOS5_ARM_CORE0_SYS_PWR_REG);
> >> + if (!(val & S5P_CORE_LOCAL_PWR_EN))
> >> + return;
> >> + }
> >> pmu_raw_writel(0, EXYNOS_ARM_CORE_CONFIGURATION(cpu));
> >> }
> >>
> >> @@ -318,7 +330,10 @@ static void exynos_pm_prepare(void)
> >>
> >> /* ensure at least INFORM0 has the resume address */
> >>
> >> - pmu_raw_writel(virt_to_phys(exynos_cpu_resume), S5P_INFORM0);
> >> + if (soc_is_exynos5420() && IS_ENABLED(CONFIG_MCPM))
> >> + pmu_raw_writel(virt_to_phys(mcpm_entry_point), S5P_INFORM0);
> >> + else
> >> + pmu_raw_writel(virt_to_phys(exynos_cpu_resume), S5P_INFORM0);
> >>
> >> if (soc_is_exynos5420()) {
> >> tmp = __raw_readl(pmu_base_addr + EXYNOS5_ARM_L2_OPTION);
> >> @@ -408,6 +423,12 @@ static void exynos_pm_resume(void)
> >> unsigned int tmp;
> >>
> >> if (soc_is_exynos5420()) {
> >> + /* Restore the CPU0 low power state register */
> >> + tmp = __raw_readl(pmu_base_addr +
> >> + EXYNOS5_ARM_CORE0_SYS_PWR_REG);
> >> + pmu_raw_writel(tmp | S5P_CORE_LOCAL_PWR_EN,
> >> + EXYNOS5_ARM_CORE0_SYS_PWR_REG);
> >> +
> >> /* Restore the sysram cpu state register */
> >> __raw_writel(exynos5420_cpu_state,
> >> sysram_base_addr + EXYNOS5420_CPU_STATE);
> >> @@ -490,6 +511,28 @@ static struct syscore_ops exynos_pm_syscore_ops = {
> >> .resume = exynos_pm_resume,
> >> };
> >>
> >> +static int notrace exynos_mcpm_cpu_suspend(unsigned long arg)
> >> +{
> >> + /* MCPM works with HW CPU identifiers */
> >> + unsigned int mpidr = read_cpuid_mpidr();
> >> + unsigned int cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
> >> + unsigned int cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
> >> +
> >> + __raw_writel(0x0, sysram_base_addr + EXYNOS5420_CPU_STATE);
> >> +
> >> + mcpm_set_entry_vector(cpu, cluster, exynos_cpu_resume);
> >> +
> >> + /*
> >> + * Residency value passed to mcpm_cpu_suspend back-end
> >> + * has to be given clear semantics. Set to 0 as a
> >> + * temporary value.
> >> + */
> >> + mcpm_cpu_suspend(0);
> >> +
> >> + /* return value != 0 means failure */
> >> + return 1;
> >> +}
> >> +
> >> /*
> >> * Suspend Ops
> >> */
> >> @@ -517,10 +560,17 @@ static int exynos_suspend_enter(suspend_state_t state)
> >> flush_cache_all();
> >> s3c_pm_check_store();
> >>
> >> - ret = cpu_suspend(0, exynos_cpu_suspend);
> >> + /* Use the MCPM layer to suspend 5420 which is a multi-cluster SoC */
> >> + if (soc_is_exynos5420() && IS_ENABLED(CONFIG_MCPM))
> >> + ret = cpu_suspend(0, exynos_mcpm_cpu_suspend);
> >> + else
> >> + ret = cpu_suspend(0, exynos_cpu_suspend);
> >> if (ret)
> >> return ret;
> >>
> >> + if (soc_is_exynos5420() && IS_ENABLED(CONFIG_MCPM))
> >> + mcpm_cpu_powered_up();
> >> +
> >> s3c_pm_restore_uarts();
> >>
> >> S3C_PMDBG("%s: wakeup stat: %08x\n", __func__,
> >> --
> >> 2.0.0
> >>
> >>
>
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH v7] ARM: EXYNOS: Use MCPM call-backs to support S2R on Exynos5420
@ 2014-07-08 10:53 ` Lorenzo Pieralisi
0 siblings, 0 replies; 130+ messages in thread
From: Lorenzo Pieralisi @ 2014-07-08 10:53 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Jul 04, 2014 at 10:21:56PM +0100, Abhilash Kesavan wrote:
> On Sat, Jul 5, 2014 at 2:30 AM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> > On Sat, 5 Jul 2014, Abhilash Kesavan wrote:
> >
> >> Use the MCPM layer to handle core suspend/resume on Exynos5420.
> >> Also, restore the entry address setup code post-resume.
> >>
> >> Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
> >
> > Acked-by: Nicolas Pitre <nico@linaro.org>
> This is one of the last missing bits for exynos MCPM. Thanks for your
> patient reviews of all the exynos mcpm back-end patches.
Sorry for the delay in getting back to you.
You still need to handle the residency parameter in the MCPM suspend call
properly to differentiate between core gating and cluster gating.
CPUidle might want to request a state that allows for core gating
residency but not cluster gating one, in that case the last man
standing must not shutdown the cluster.
This must be handled in the power down function, and it can be done
in a separate patch since it is an optimization. Current MCPM interface has
all it is needed to handle this properly, and I am keen on patching the
CPUidle bL driver to pass the actual residency instead of hardcoding it
to 0 (ie on TC2 it was not needed, no core gating).
Lorenzo
>
> Regards,
> Abhilash
> >
> >
> >> ---
> >> Changes in v2:
> >> - Made use of the MCPM suspend/powered_up call-backs
> >> Changes in v3:
> >> - Used the residency value to indicate the entered state
> >> Changes in v4:
> >> - Checked if MCPM has been enabled to prevent build error
> >> Changes in v5:
> >> - Removed the MCPM flags and just used a local flag to
> >> indicate that we are suspending.
> >> Changes in v6:
> >> - Read the SYS_PWR_REG value to decide if we are suspending
> >> the system.
> >> - Restore the SYS_PWR_REG value post-resume.
> >> - Modified the comments to reflect the first change.
> >> Changes in v7:
> >> - Add the suspend check in exynos_cpu_power_down() rather
> >> than the MCPM back-end.
> >> - Clean-up unnecessary changes related to earlier versions.
> >>
> >> This has been tested both on an SMDK5420 and Peach Pit Chromebook on
> >> next-20140704. Nicolas' boot cluster CCI enablement patches are in
> >> linux-next now.
> >>
> >> Here are the dependencies (some of these patches did not apply cleanly):
> >> 1) Cleanup patches for mach-exynos
> >> http://comments.gmane.org/gmane.linux.kernel.samsung-soc/33772
> >>
> >> 2) PMU cleanup and refactoring for using DT
> >> https://www.mail-archive.com/linux-kernel at vger.kernel.org/msg671625.html
> >>
> >> 3) Exynos5420 PMU/S2R Series
> >> http://comments.gmane.org/gmane.linux.kernel.samsung-soc/33898
> >>
> >> 4) Exynos5420 CPUIdle Series which populates MCPM suspend/powered_up
> >> call-backs.
> >> www.gossamer-threads.com/lists/linux/kernel/1945347
> >> https://patchwork.kernel.org/patch/4357461/
> >>
> >> 5) Exynos5420 MCPM cluster power down support
> >> http://www.spinics.net/lists/arm-kernel/msg339988.html
> >>
> >> 6) TPM reset mask patch
> >> http://www.spinics.net/lists/arm-kernel/msg341884.html
> >>
> >> arch/arm/mach-exynos/mcpm-exynos.c | 32 +++++++++++++++-------
> >> arch/arm/mach-exynos/pm.c | 54 ++++++++++++++++++++++++++++++++++++--
> >> 2 files changed, 74 insertions(+), 12 deletions(-)
> >>
> >> diff --git a/arch/arm/mach-exynos/mcpm-exynos.c b/arch/arm/mach-exynos/mcpm-exynos.c
> >> index 2dd51cc..74ad772 100644
> >> --- a/arch/arm/mach-exynos/mcpm-exynos.c
> >> +++ b/arch/arm/mach-exynos/mcpm-exynos.c
> >> @@ -15,6 +15,7 @@
> >> #include <linux/delay.h>
> >> #include <linux/io.h>
> >> #include <linux/of_address.h>
> >> +#include <linux/syscore_ops.h>
> >>
> >> #include <asm/cputype.h>
> >> #include <asm/cp15.h>
> >> @@ -30,6 +31,8 @@
> >> #define EXYNOS5420_USE_ARM_CORE_DOWN_STATE BIT(29)
> >> #define EXYNOS5420_USE_L2_COMMON_UP_STATE BIT(30)
> >>
> >> +static void __iomem *ns_sram_base_addr;
> >> +
> >> /*
> >> * The common v7_exit_coherency_flush API could not be used because of the
> >> * Erratum 799270 workaround. This macro is the same as the common one (in
> >> @@ -319,10 +322,26 @@ static const struct of_device_id exynos_dt_mcpm_match[] = {
> >> {},
> >> };
> >>
> >> +static void exynos_mcpm_setup_entry_point(void)
> >> +{
> >> + /*
> >> + * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
> >> + * as part of secondary_cpu_start(). Let's redirect it to the
> >> + * mcpm_entry_point(). This is done during both secondary boot-up as
> >> + * well as system resume.
> >> + */
> >> + __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
> >> + __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
> >> + __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
> >> +}
> >> +
> >> +static struct syscore_ops exynos_mcpm_syscore_ops = {
> >> + .resume = exynos_mcpm_setup_entry_point,
> >> +};
> >> +
> >> static int __init exynos_mcpm_init(void)
> >> {
> >> struct device_node *node;
> >> - void __iomem *ns_sram_base_addr;
> >> unsigned int value, i;
> >> int ret;
> >>
> >> @@ -389,16 +408,9 @@ static int __init exynos_mcpm_init(void)
> >> __raw_writel(value, pmu_base_addr + EXYNOS_COMMON_OPTION(i));
> >> }
> >>
> >> - /*
> >> - * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
> >> - * as part of secondary_cpu_start(). Let's redirect it to the
> >> - * mcpm_entry_point().
> >> - */
> >> - __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
> >> - __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
> >> - __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
> >> + exynos_mcpm_setup_entry_point();
> >>
> >> - iounmap(ns_sram_base_addr);
> >> + register_syscore_ops(&exynos_mcpm_syscore_ops);
> >>
> >> return ret;
> >> }
> >> diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
> >> index 69cf678..e2ba1e5 100644
> >> --- a/arch/arm/mach-exynos/pm.c
> >> +++ b/arch/arm/mach-exynos/pm.c
> >> @@ -24,6 +24,7 @@
> >>
> >> #include <asm/cacheflush.h>
> >> #include <asm/hardware/cache-l2x0.h>
> >> +#include <asm/mcpm.h>
> >> #include <asm/smp_scu.h>
> >> #include <asm/suspend.h>
> >>
> >> @@ -123,6 +124,17 @@ static int exynos_irq_set_wake(struct irq_data *data, unsigned int state)
> >> */
> >> void exynos_cpu_power_down(int cpu)
> >> {
> >> + if (soc_is_exynos5420() && cpu == 0) {
> >> + /*
> >> + * Bypass power down for CPU0 during suspend. Check for
> >> + * the SYS_PWR_REG value to decide if we are suspending
> >> + * the system.
> >> + */
> >> + int val = __raw_readl(pmu_base_addr +
> >> + EXYNOS5_ARM_CORE0_SYS_PWR_REG);
> >> + if (!(val & S5P_CORE_LOCAL_PWR_EN))
> >> + return;
> >> + }
> >> pmu_raw_writel(0, EXYNOS_ARM_CORE_CONFIGURATION(cpu));
> >> }
> >>
> >> @@ -318,7 +330,10 @@ static void exynos_pm_prepare(void)
> >>
> >> /* ensure at least INFORM0 has the resume address */
> >>
> >> - pmu_raw_writel(virt_to_phys(exynos_cpu_resume), S5P_INFORM0);
> >> + if (soc_is_exynos5420() && IS_ENABLED(CONFIG_MCPM))
> >> + pmu_raw_writel(virt_to_phys(mcpm_entry_point), S5P_INFORM0);
> >> + else
> >> + pmu_raw_writel(virt_to_phys(exynos_cpu_resume), S5P_INFORM0);
> >>
> >> if (soc_is_exynos5420()) {
> >> tmp = __raw_readl(pmu_base_addr + EXYNOS5_ARM_L2_OPTION);
> >> @@ -408,6 +423,12 @@ static void exynos_pm_resume(void)
> >> unsigned int tmp;
> >>
> >> if (soc_is_exynos5420()) {
> >> + /* Restore the CPU0 low power state register */
> >> + tmp = __raw_readl(pmu_base_addr +
> >> + EXYNOS5_ARM_CORE0_SYS_PWR_REG);
> >> + pmu_raw_writel(tmp | S5P_CORE_LOCAL_PWR_EN,
> >> + EXYNOS5_ARM_CORE0_SYS_PWR_REG);
> >> +
> >> /* Restore the sysram cpu state register */
> >> __raw_writel(exynos5420_cpu_state,
> >> sysram_base_addr + EXYNOS5420_CPU_STATE);
> >> @@ -490,6 +511,28 @@ static struct syscore_ops exynos_pm_syscore_ops = {
> >> .resume = exynos_pm_resume,
> >> };
> >>
> >> +static int notrace exynos_mcpm_cpu_suspend(unsigned long arg)
> >> +{
> >> + /* MCPM works with HW CPU identifiers */
> >> + unsigned int mpidr = read_cpuid_mpidr();
> >> + unsigned int cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
> >> + unsigned int cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
> >> +
> >> + __raw_writel(0x0, sysram_base_addr + EXYNOS5420_CPU_STATE);
> >> +
> >> + mcpm_set_entry_vector(cpu, cluster, exynos_cpu_resume);
> >> +
> >> + /*
> >> + * Residency value passed to mcpm_cpu_suspend back-end
> >> + * has to be given clear semantics. Set to 0 as a
> >> + * temporary value.
> >> + */
> >> + mcpm_cpu_suspend(0);
> >> +
> >> + /* return value != 0 means failure */
> >> + return 1;
> >> +}
> >> +
> >> /*
> >> * Suspend Ops
> >> */
> >> @@ -517,10 +560,17 @@ static int exynos_suspend_enter(suspend_state_t state)
> >> flush_cache_all();
> >> s3c_pm_check_store();
> >>
> >> - ret = cpu_suspend(0, exynos_cpu_suspend);
> >> + /* Use the MCPM layer to suspend 5420 which is a multi-cluster SoC */
> >> + if (soc_is_exynos5420() && IS_ENABLED(CONFIG_MCPM))
> >> + ret = cpu_suspend(0, exynos_mcpm_cpu_suspend);
> >> + else
> >> + ret = cpu_suspend(0, exynos_cpu_suspend);
> >> if (ret)
> >> return ret;
> >>
> >> + if (soc_is_exynos5420() && IS_ENABLED(CONFIG_MCPM))
> >> + mcpm_cpu_powered_up();
> >> +
> >> s3c_pm_restore_uarts();
> >>
> >> S3C_PMDBG("%s: wakeup stat: %08x\n", __func__,
> >> --
> >> 2.0.0
> >>
> >>
>
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: [PATCH v7] ARM: EXYNOS: Use MCPM call-backs to support S2R on Exynos5420
2014-07-08 10:53 ` Lorenzo Pieralisi
@ 2014-07-08 13:39 ` Abhilash Kesavan
-1 siblings, 0 replies; 130+ messages in thread
From: Abhilash Kesavan @ 2014-07-08 13:39 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Nicolas Pitre, linux-samsung-soc, linux-arm-kernel, Kukjin Kim,
Andrew Bresticker, Douglas Anderson
Hi Lorenzo,
On Tue, Jul 8, 2014 at 4:23 PM, Lorenzo Pieralisi
<lorenzo.pieralisi@arm.com> wrote:
> On Fri, Jul 04, 2014 at 10:21:56PM +0100, Abhilash Kesavan wrote:
>> On Sat, Jul 5, 2014 at 2:30 AM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
>> > On Sat, 5 Jul 2014, Abhilash Kesavan wrote:
>> >
>> >> Use the MCPM layer to handle core suspend/resume on Exynos5420.
>> >> Also, restore the entry address setup code post-resume.
>> >>
>> >> Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
>> >
>> > Acked-by: Nicolas Pitre <nico@linaro.org>
>> This is one of the last missing bits for exynos MCPM. Thanks for your
>> patient reviews of all the exynos mcpm back-end patches.
>
> Sorry for the delay in getting back to you.
Thanks for your comments.
>
> You still need to handle the residency parameter in the MCPM suspend call
> properly to differentiate between core gating and cluster gating.
I am not too familiar with the cpuidle driver, but I see only cluster
power off state listed in the bL cpuidle driver.
>
> CPUidle might want to request a state that allows for core gating
> residency but not cluster gating one, in that case the last man
> standing must not shutdown the cluster.
For this, I would have to add another state to the bL cpuidle driver
or migrate to using your under-review generic idle state patchset.
Then based on the residency value skip/do cluster power down. Is this
correct ?
>
> This must be handled in the power down function, and it can be done
> in a separate patch since it is an optimization. Current MCPM interface has
> all it is needed to handle this properly, and I am keen on patching the
> CPUidle bL driver to pass the actual residency instead of hardcoding it
> to 0 (ie on TC2 it was not needed, no core gating).
I will look at doing this once the s2r patch gets merged.
Thanks,
Abhilash
>
> Lorenzo
>
>>
>> Regards,
>> Abhilash
>> >
>> >
>> >> ---
>> >> Changes in v2:
>> >> - Made use of the MCPM suspend/powered_up call-backs
>> >> Changes in v3:
>> >> - Used the residency value to indicate the entered state
>> >> Changes in v4:
>> >> - Checked if MCPM has been enabled to prevent build error
>> >> Changes in v5:
>> >> - Removed the MCPM flags and just used a local flag to
>> >> indicate that we are suspending.
>> >> Changes in v6:
>> >> - Read the SYS_PWR_REG value to decide if we are suspending
>> >> the system.
>> >> - Restore the SYS_PWR_REG value post-resume.
>> >> - Modified the comments to reflect the first change.
>> >> Changes in v7:
>> >> - Add the suspend check in exynos_cpu_power_down() rather
>> >> than the MCPM back-end.
>> >> - Clean-up unnecessary changes related to earlier versions.
>> >>
>> >> This has been tested both on an SMDK5420 and Peach Pit Chromebook on
>> >> next-20140704. Nicolas' boot cluster CCI enablement patches are in
>> >> linux-next now.
>> >>
>> >> Here are the dependencies (some of these patches did not apply cleanly):
>> >> 1) Cleanup patches for mach-exynos
>> >> http://comments.gmane.org/gmane.linux.kernel.samsung-soc/33772
>> >>
>> >> 2) PMU cleanup and refactoring for using DT
>> >> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg671625.html
>> >>
>> >> 3) Exynos5420 PMU/S2R Series
>> >> http://comments.gmane.org/gmane.linux.kernel.samsung-soc/33898
>> >>
>> >> 4) Exynos5420 CPUIdle Series which populates MCPM suspend/powered_up
>> >> call-backs.
>> >> www.gossamer-threads.com/lists/linux/kernel/1945347
>> >> https://patchwork.kernel.org/patch/4357461/
>> >>
>> >> 5) Exynos5420 MCPM cluster power down support
>> >> http://www.spinics.net/lists/arm-kernel/msg339988.html
>> >>
>> >> 6) TPM reset mask patch
>> >> http://www.spinics.net/lists/arm-kernel/msg341884.html
>> >>
>> >> arch/arm/mach-exynos/mcpm-exynos.c | 32 +++++++++++++++-------
>> >> arch/arm/mach-exynos/pm.c | 54 ++++++++++++++++++++++++++++++++++++--
>> >> 2 files changed, 74 insertions(+), 12 deletions(-)
>> >>
>> >> diff --git a/arch/arm/mach-exynos/mcpm-exynos.c b/arch/arm/mach-exynos/mcpm-exynos.c
>> >> index 2dd51cc..74ad772 100644
>> >> --- a/arch/arm/mach-exynos/mcpm-exynos.c
>> >> +++ b/arch/arm/mach-exynos/mcpm-exynos.c
>> >> @@ -15,6 +15,7 @@
>> >> #include <linux/delay.h>
>> >> #include <linux/io.h>
>> >> #include <linux/of_address.h>
>> >> +#include <linux/syscore_ops.h>
>> >>
>> >> #include <asm/cputype.h>
>> >> #include <asm/cp15.h>
>> >> @@ -30,6 +31,8 @@
>> >> #define EXYNOS5420_USE_ARM_CORE_DOWN_STATE BIT(29)
>> >> #define EXYNOS5420_USE_L2_COMMON_UP_STATE BIT(30)
>> >>
>> >> +static void __iomem *ns_sram_base_addr;
>> >> +
>> >> /*
>> >> * The common v7_exit_coherency_flush API could not be used because of the
>> >> * Erratum 799270 workaround. This macro is the same as the common one (in
>> >> @@ -319,10 +322,26 @@ static const struct of_device_id exynos_dt_mcpm_match[] = {
>> >> {},
>> >> };
>> >>
>> >> +static void exynos_mcpm_setup_entry_point(void)
>> >> +{
>> >> + /*
>> >> + * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
>> >> + * as part of secondary_cpu_start(). Let's redirect it to the
>> >> + * mcpm_entry_point(). This is done during both secondary boot-up as
>> >> + * well as system resume.
>> >> + */
>> >> + __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
>> >> + __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
>> >> + __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
>> >> +}
>> >> +
>> >> +static struct syscore_ops exynos_mcpm_syscore_ops = {
>> >> + .resume = exynos_mcpm_setup_entry_point,
>> >> +};
>> >> +
>> >> static int __init exynos_mcpm_init(void)
>> >> {
>> >> struct device_node *node;
>> >> - void __iomem *ns_sram_base_addr;
>> >> unsigned int value, i;
>> >> int ret;
>> >>
>> >> @@ -389,16 +408,9 @@ static int __init exynos_mcpm_init(void)
>> >> __raw_writel(value, pmu_base_addr + EXYNOS_COMMON_OPTION(i));
>> >> }
>> >>
>> >> - /*
>> >> - * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
>> >> - * as part of secondary_cpu_start(). Let's redirect it to the
>> >> - * mcpm_entry_point().
>> >> - */
>> >> - __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
>> >> - __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
>> >> - __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
>> >> + exynos_mcpm_setup_entry_point();
>> >>
>> >> - iounmap(ns_sram_base_addr);
>> >> + register_syscore_ops(&exynos_mcpm_syscore_ops);
>> >>
>> >> return ret;
>> >> }
>> >> diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
>> >> index 69cf678..e2ba1e5 100644
>> >> --- a/arch/arm/mach-exynos/pm.c
>> >> +++ b/arch/arm/mach-exynos/pm.c
>> >> @@ -24,6 +24,7 @@
>> >>
>> >> #include <asm/cacheflush.h>
>> >> #include <asm/hardware/cache-l2x0.h>
>> >> +#include <asm/mcpm.h>
>> >> #include <asm/smp_scu.h>
>> >> #include <asm/suspend.h>
>> >>
>> >> @@ -123,6 +124,17 @@ static int exynos_irq_set_wake(struct irq_data *data, unsigned int state)
>> >> */
>> >> void exynos_cpu_power_down(int cpu)
>> >> {
>> >> + if (soc_is_exynos5420() && cpu == 0) {
>> >> + /*
>> >> + * Bypass power down for CPU0 during suspend. Check for
>> >> + * the SYS_PWR_REG value to decide if we are suspending
>> >> + * the system.
>> >> + */
>> >> + int val = __raw_readl(pmu_base_addr +
>> >> + EXYNOS5_ARM_CORE0_SYS_PWR_REG);
>> >> + if (!(val & S5P_CORE_LOCAL_PWR_EN))
>> >> + return;
>> >> + }
>> >> pmu_raw_writel(0, EXYNOS_ARM_CORE_CONFIGURATION(cpu));
>> >> }
>> >>
>> >> @@ -318,7 +330,10 @@ static void exynos_pm_prepare(void)
>> >>
>> >> /* ensure at least INFORM0 has the resume address */
>> >>
>> >> - pmu_raw_writel(virt_to_phys(exynos_cpu_resume), S5P_INFORM0);
>> >> + if (soc_is_exynos5420() && IS_ENABLED(CONFIG_MCPM))
>> >> + pmu_raw_writel(virt_to_phys(mcpm_entry_point), S5P_INFORM0);
>> >> + else
>> >> + pmu_raw_writel(virt_to_phys(exynos_cpu_resume), S5P_INFORM0);
>> >>
>> >> if (soc_is_exynos5420()) {
>> >> tmp = __raw_readl(pmu_base_addr + EXYNOS5_ARM_L2_OPTION);
>> >> @@ -408,6 +423,12 @@ static void exynos_pm_resume(void)
>> >> unsigned int tmp;
>> >>
>> >> if (soc_is_exynos5420()) {
>> >> + /* Restore the CPU0 low power state register */
>> >> + tmp = __raw_readl(pmu_base_addr +
>> >> + EXYNOS5_ARM_CORE0_SYS_PWR_REG);
>> >> + pmu_raw_writel(tmp | S5P_CORE_LOCAL_PWR_EN,
>> >> + EXYNOS5_ARM_CORE0_SYS_PWR_REG);
>> >> +
>> >> /* Restore the sysram cpu state register */
>> >> __raw_writel(exynos5420_cpu_state,
>> >> sysram_base_addr + EXYNOS5420_CPU_STATE);
>> >> @@ -490,6 +511,28 @@ static struct syscore_ops exynos_pm_syscore_ops = {
>> >> .resume = exynos_pm_resume,
>> >> };
>> >>
>> >> +static int notrace exynos_mcpm_cpu_suspend(unsigned long arg)
>> >> +{
>> >> + /* MCPM works with HW CPU identifiers */
>> >> + unsigned int mpidr = read_cpuid_mpidr();
>> >> + unsigned int cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
>> >> + unsigned int cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
>> >> +
>> >> + __raw_writel(0x0, sysram_base_addr + EXYNOS5420_CPU_STATE);
>> >> +
>> >> + mcpm_set_entry_vector(cpu, cluster, exynos_cpu_resume);
>> >> +
>> >> + /*
>> >> + * Residency value passed to mcpm_cpu_suspend back-end
>> >> + * has to be given clear semantics. Set to 0 as a
>> >> + * temporary value.
>> >> + */
>> >> + mcpm_cpu_suspend(0);
>> >> +
>> >> + /* return value != 0 means failure */
>> >> + return 1;
>> >> +}
>> >> +
>> >> /*
>> >> * Suspend Ops
>> >> */
>> >> @@ -517,10 +560,17 @@ static int exynos_suspend_enter(suspend_state_t state)
>> >> flush_cache_all();
>> >> s3c_pm_check_store();
>> >>
>> >> - ret = cpu_suspend(0, exynos_cpu_suspend);
>> >> + /* Use the MCPM layer to suspend 5420 which is a multi-cluster SoC */
>> >> + if (soc_is_exynos5420() && IS_ENABLED(CONFIG_MCPM))
>> >> + ret = cpu_suspend(0, exynos_mcpm_cpu_suspend);
>> >> + else
>> >> + ret = cpu_suspend(0, exynos_cpu_suspend);
>> >> if (ret)
>> >> return ret;
>> >>
>> >> + if (soc_is_exynos5420() && IS_ENABLED(CONFIG_MCPM))
>> >> + mcpm_cpu_powered_up();
>> >> +
>> >> s3c_pm_restore_uarts();
>> >>
>> >> S3C_PMDBG("%s: wakeup stat: %08x\n", __func__,
>> >> --
>> >> 2.0.0
>> >>
>> >>
>>
>
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH v7] ARM: EXYNOS: Use MCPM call-backs to support S2R on Exynos5420
@ 2014-07-08 13:39 ` Abhilash Kesavan
0 siblings, 0 replies; 130+ messages in thread
From: Abhilash Kesavan @ 2014-07-08 13:39 UTC (permalink / raw)
To: linux-arm-kernel
Hi Lorenzo,
On Tue, Jul 8, 2014 at 4:23 PM, Lorenzo Pieralisi
<lorenzo.pieralisi@arm.com> wrote:
> On Fri, Jul 04, 2014 at 10:21:56PM +0100, Abhilash Kesavan wrote:
>> On Sat, Jul 5, 2014 at 2:30 AM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
>> > On Sat, 5 Jul 2014, Abhilash Kesavan wrote:
>> >
>> >> Use the MCPM layer to handle core suspend/resume on Exynos5420.
>> >> Also, restore the entry address setup code post-resume.
>> >>
>> >> Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
>> >
>> > Acked-by: Nicolas Pitre <nico@linaro.org>
>> This is one of the last missing bits for exynos MCPM. Thanks for your
>> patient reviews of all the exynos mcpm back-end patches.
>
> Sorry for the delay in getting back to you.
Thanks for your comments.
>
> You still need to handle the residency parameter in the MCPM suspend call
> properly to differentiate between core gating and cluster gating.
I am not too familiar with the cpuidle driver, but I see only cluster
power off state listed in the bL cpuidle driver.
>
> CPUidle might want to request a state that allows for core gating
> residency but not cluster gating one, in that case the last man
> standing must not shutdown the cluster.
For this, I would have to add another state to the bL cpuidle driver
or migrate to using your under-review generic idle state patchset.
Then based on the residency value skip/do cluster power down. Is this
correct ?
>
> This must be handled in the power down function, and it can be done
> in a separate patch since it is an optimization. Current MCPM interface has
> all it is needed to handle this properly, and I am keen on patching the
> CPUidle bL driver to pass the actual residency instead of hardcoding it
> to 0 (ie on TC2 it was not needed, no core gating).
I will look at doing this once the s2r patch gets merged.
Thanks,
Abhilash
>
> Lorenzo
>
>>
>> Regards,
>> Abhilash
>> >
>> >
>> >> ---
>> >> Changes in v2:
>> >> - Made use of the MCPM suspend/powered_up call-backs
>> >> Changes in v3:
>> >> - Used the residency value to indicate the entered state
>> >> Changes in v4:
>> >> - Checked if MCPM has been enabled to prevent build error
>> >> Changes in v5:
>> >> - Removed the MCPM flags and just used a local flag to
>> >> indicate that we are suspending.
>> >> Changes in v6:
>> >> - Read the SYS_PWR_REG value to decide if we are suspending
>> >> the system.
>> >> - Restore the SYS_PWR_REG value post-resume.
>> >> - Modified the comments to reflect the first change.
>> >> Changes in v7:
>> >> - Add the suspend check in exynos_cpu_power_down() rather
>> >> than the MCPM back-end.
>> >> - Clean-up unnecessary changes related to earlier versions.
>> >>
>> >> This has been tested both on an SMDK5420 and Peach Pit Chromebook on
>> >> next-20140704. Nicolas' boot cluster CCI enablement patches are in
>> >> linux-next now.
>> >>
>> >> Here are the dependencies (some of these patches did not apply cleanly):
>> >> 1) Cleanup patches for mach-exynos
>> >> http://comments.gmane.org/gmane.linux.kernel.samsung-soc/33772
>> >>
>> >> 2) PMU cleanup and refactoring for using DT
>> >> https://www.mail-archive.com/linux-kernel at vger.kernel.org/msg671625.html
>> >>
>> >> 3) Exynos5420 PMU/S2R Series
>> >> http://comments.gmane.org/gmane.linux.kernel.samsung-soc/33898
>> >>
>> >> 4) Exynos5420 CPUIdle Series which populates MCPM suspend/powered_up
>> >> call-backs.
>> >> www.gossamer-threads.com/lists/linux/kernel/1945347
>> >> https://patchwork.kernel.org/patch/4357461/
>> >>
>> >> 5) Exynos5420 MCPM cluster power down support
>> >> http://www.spinics.net/lists/arm-kernel/msg339988.html
>> >>
>> >> 6) TPM reset mask patch
>> >> http://www.spinics.net/lists/arm-kernel/msg341884.html
>> >>
>> >> arch/arm/mach-exynos/mcpm-exynos.c | 32 +++++++++++++++-------
>> >> arch/arm/mach-exynos/pm.c | 54 ++++++++++++++++++++++++++++++++++++--
>> >> 2 files changed, 74 insertions(+), 12 deletions(-)
>> >>
>> >> diff --git a/arch/arm/mach-exynos/mcpm-exynos.c b/arch/arm/mach-exynos/mcpm-exynos.c
>> >> index 2dd51cc..74ad772 100644
>> >> --- a/arch/arm/mach-exynos/mcpm-exynos.c
>> >> +++ b/arch/arm/mach-exynos/mcpm-exynos.c
>> >> @@ -15,6 +15,7 @@
>> >> #include <linux/delay.h>
>> >> #include <linux/io.h>
>> >> #include <linux/of_address.h>
>> >> +#include <linux/syscore_ops.h>
>> >>
>> >> #include <asm/cputype.h>
>> >> #include <asm/cp15.h>
>> >> @@ -30,6 +31,8 @@
>> >> #define EXYNOS5420_USE_ARM_CORE_DOWN_STATE BIT(29)
>> >> #define EXYNOS5420_USE_L2_COMMON_UP_STATE BIT(30)
>> >>
>> >> +static void __iomem *ns_sram_base_addr;
>> >> +
>> >> /*
>> >> * The common v7_exit_coherency_flush API could not be used because of the
>> >> * Erratum 799270 workaround. This macro is the same as the common one (in
>> >> @@ -319,10 +322,26 @@ static const struct of_device_id exynos_dt_mcpm_match[] = {
>> >> {},
>> >> };
>> >>
>> >> +static void exynos_mcpm_setup_entry_point(void)
>> >> +{
>> >> + /*
>> >> + * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
>> >> + * as part of secondary_cpu_start(). Let's redirect it to the
>> >> + * mcpm_entry_point(). This is done during both secondary boot-up as
>> >> + * well as system resume.
>> >> + */
>> >> + __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
>> >> + __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
>> >> + __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
>> >> +}
>> >> +
>> >> +static struct syscore_ops exynos_mcpm_syscore_ops = {
>> >> + .resume = exynos_mcpm_setup_entry_point,
>> >> +};
>> >> +
>> >> static int __init exynos_mcpm_init(void)
>> >> {
>> >> struct device_node *node;
>> >> - void __iomem *ns_sram_base_addr;
>> >> unsigned int value, i;
>> >> int ret;
>> >>
>> >> @@ -389,16 +408,9 @@ static int __init exynos_mcpm_init(void)
>> >> __raw_writel(value, pmu_base_addr + EXYNOS_COMMON_OPTION(i));
>> >> }
>> >>
>> >> - /*
>> >> - * U-Boot SPL is hardcoded to jump to the start of ns_sram_base_addr
>> >> - * as part of secondary_cpu_start(). Let's redirect it to the
>> >> - * mcpm_entry_point().
>> >> - */
>> >> - __raw_writel(0xe59f0000, ns_sram_base_addr); /* ldr r0, [pc, #0] */
>> >> - __raw_writel(0xe12fff10, ns_sram_base_addr + 4); /* bx r0 */
>> >> - __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr + 8);
>> >> + exynos_mcpm_setup_entry_point();
>> >>
>> >> - iounmap(ns_sram_base_addr);
>> >> + register_syscore_ops(&exynos_mcpm_syscore_ops);
>> >>
>> >> return ret;
>> >> }
>> >> diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
>> >> index 69cf678..e2ba1e5 100644
>> >> --- a/arch/arm/mach-exynos/pm.c
>> >> +++ b/arch/arm/mach-exynos/pm.c
>> >> @@ -24,6 +24,7 @@
>> >>
>> >> #include <asm/cacheflush.h>
>> >> #include <asm/hardware/cache-l2x0.h>
>> >> +#include <asm/mcpm.h>
>> >> #include <asm/smp_scu.h>
>> >> #include <asm/suspend.h>
>> >>
>> >> @@ -123,6 +124,17 @@ static int exynos_irq_set_wake(struct irq_data *data, unsigned int state)
>> >> */
>> >> void exynos_cpu_power_down(int cpu)
>> >> {
>> >> + if (soc_is_exynos5420() && cpu == 0) {
>> >> + /*
>> >> + * Bypass power down for CPU0 during suspend. Check for
>> >> + * the SYS_PWR_REG value to decide if we are suspending
>> >> + * the system.
>> >> + */
>> >> + int val = __raw_readl(pmu_base_addr +
>> >> + EXYNOS5_ARM_CORE0_SYS_PWR_REG);
>> >> + if (!(val & S5P_CORE_LOCAL_PWR_EN))
>> >> + return;
>> >> + }
>> >> pmu_raw_writel(0, EXYNOS_ARM_CORE_CONFIGURATION(cpu));
>> >> }
>> >>
>> >> @@ -318,7 +330,10 @@ static void exynos_pm_prepare(void)
>> >>
>> >> /* ensure at least INFORM0 has the resume address */
>> >>
>> >> - pmu_raw_writel(virt_to_phys(exynos_cpu_resume), S5P_INFORM0);
>> >> + if (soc_is_exynos5420() && IS_ENABLED(CONFIG_MCPM))
>> >> + pmu_raw_writel(virt_to_phys(mcpm_entry_point), S5P_INFORM0);
>> >> + else
>> >> + pmu_raw_writel(virt_to_phys(exynos_cpu_resume), S5P_INFORM0);
>> >>
>> >> if (soc_is_exynos5420()) {
>> >> tmp = __raw_readl(pmu_base_addr + EXYNOS5_ARM_L2_OPTION);
>> >> @@ -408,6 +423,12 @@ static void exynos_pm_resume(void)
>> >> unsigned int tmp;
>> >>
>> >> if (soc_is_exynos5420()) {
>> >> + /* Restore the CPU0 low power state register */
>> >> + tmp = __raw_readl(pmu_base_addr +
>> >> + EXYNOS5_ARM_CORE0_SYS_PWR_REG);
>> >> + pmu_raw_writel(tmp | S5P_CORE_LOCAL_PWR_EN,
>> >> + EXYNOS5_ARM_CORE0_SYS_PWR_REG);
>> >> +
>> >> /* Restore the sysram cpu state register */
>> >> __raw_writel(exynos5420_cpu_state,
>> >> sysram_base_addr + EXYNOS5420_CPU_STATE);
>> >> @@ -490,6 +511,28 @@ static struct syscore_ops exynos_pm_syscore_ops = {
>> >> .resume = exynos_pm_resume,
>> >> };
>> >>
>> >> +static int notrace exynos_mcpm_cpu_suspend(unsigned long arg)
>> >> +{
>> >> + /* MCPM works with HW CPU identifiers */
>> >> + unsigned int mpidr = read_cpuid_mpidr();
>> >> + unsigned int cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
>> >> + unsigned int cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
>> >> +
>> >> + __raw_writel(0x0, sysram_base_addr + EXYNOS5420_CPU_STATE);
>> >> +
>> >> + mcpm_set_entry_vector(cpu, cluster, exynos_cpu_resume);
>> >> +
>> >> + /*
>> >> + * Residency value passed to mcpm_cpu_suspend back-end
>> >> + * has to be given clear semantics. Set to 0 as a
>> >> + * temporary value.
>> >> + */
>> >> + mcpm_cpu_suspend(0);
>> >> +
>> >> + /* return value != 0 means failure */
>> >> + return 1;
>> >> +}
>> >> +
>> >> /*
>> >> * Suspend Ops
>> >> */
>> >> @@ -517,10 +560,17 @@ static int exynos_suspend_enter(suspend_state_t state)
>> >> flush_cache_all();
>> >> s3c_pm_check_store();
>> >>
>> >> - ret = cpu_suspend(0, exynos_cpu_suspend);
>> >> + /* Use the MCPM layer to suspend 5420 which is a multi-cluster SoC */
>> >> + if (soc_is_exynos5420() && IS_ENABLED(CONFIG_MCPM))
>> >> + ret = cpu_suspend(0, exynos_mcpm_cpu_suspend);
>> >> + else
>> >> + ret = cpu_suspend(0, exynos_cpu_suspend);
>> >> if (ret)
>> >> return ret;
>> >>
>> >> + if (soc_is_exynos5420() && IS_ENABLED(CONFIG_MCPM))
>> >> + mcpm_cpu_powered_up();
>> >> +
>> >> s3c_pm_restore_uarts();
>> >>
>> >> S3C_PMDBG("%s: wakeup stat: %08x\n", __func__,
>> >> --
>> >> 2.0.0
>> >>
>> >>
>>
>
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: [PATCH v7] ARM: EXYNOS: Use MCPM call-backs to support S2R on Exynos5420
2014-07-08 13:39 ` Abhilash Kesavan
@ 2014-07-08 15:19 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 130+ messages in thread
From: Lorenzo Pieralisi @ 2014-07-08 15:19 UTC (permalink / raw)
To: Abhilash Kesavan
Cc: Nicolas Pitre, linux-samsung-soc, linux-arm-kernel, Kukjin Kim,
Andrew Bresticker, Douglas Anderson
On Tue, Jul 08, 2014 at 02:39:37PM +0100, Abhilash Kesavan wrote:
> Hi Lorenzo,
>
> On Tue, Jul 8, 2014 at 4:23 PM, Lorenzo Pieralisi
> <lorenzo.pieralisi@arm.com> wrote:
> > On Fri, Jul 04, 2014 at 10:21:56PM +0100, Abhilash Kesavan wrote:
> >> On Sat, Jul 5, 2014 at 2:30 AM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> >> > On Sat, 5 Jul 2014, Abhilash Kesavan wrote:
> >> >
> >> >> Use the MCPM layer to handle core suspend/resume on Exynos5420.
> >> >> Also, restore the entry address setup code post-resume.
> >> >>
> >> >> Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
> >> >
> >> > Acked-by: Nicolas Pitre <nico@linaro.org>
> >> This is one of the last missing bits for exynos MCPM. Thanks for your
> >> patient reviews of all the exynos mcpm back-end patches.
> >
> > Sorry for the delay in getting back to you.
> Thanks for your comments.
> >
> > You still need to handle the residency parameter in the MCPM suspend call
> > properly to differentiate between core gating and cluster gating.
> I am not too familiar with the cpuidle driver, but I see only cluster
> power off state listed in the bL cpuidle driver.
> >
> > CPUidle might want to request a state that allows for core gating
> > residency but not cluster gating one, in that case the last man
> > standing must not shutdown the cluster.
> For this, I would have to add another state to the bL cpuidle driver
> or migrate to using your under-review generic idle state patchset.
> Then based on the residency value skip/do cluster power down. Is this
> correct ?
> >
> > This must be handled in the power down function, and it can be done
> > in a separate patch since it is an optimization. Current MCPM interface has
> > all it is needed to handle this properly, and I am keen on patching the
> > CPUidle bL driver to pass the actual residency instead of hardcoding it
> > to 0 (ie on TC2 it was not needed, no core gating).
> I will look at doing this once the s2r patch gets merged.
Ok, let's get it done once the CPUidle bL driver DT version gets merged,
I will add a patch that passes the proper residency and you can patch
the MCPM back-end then, until then CPUidle will be suboptimal but I
guess we can live with that for now.
Thanks,
Lorenzo
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH v7] ARM: EXYNOS: Use MCPM call-backs to support S2R on Exynos5420
@ 2014-07-08 15:19 ` Lorenzo Pieralisi
0 siblings, 0 replies; 130+ messages in thread
From: Lorenzo Pieralisi @ 2014-07-08 15:19 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Jul 08, 2014 at 02:39:37PM +0100, Abhilash Kesavan wrote:
> Hi Lorenzo,
>
> On Tue, Jul 8, 2014 at 4:23 PM, Lorenzo Pieralisi
> <lorenzo.pieralisi@arm.com> wrote:
> > On Fri, Jul 04, 2014 at 10:21:56PM +0100, Abhilash Kesavan wrote:
> >> On Sat, Jul 5, 2014 at 2:30 AM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> >> > On Sat, 5 Jul 2014, Abhilash Kesavan wrote:
> >> >
> >> >> Use the MCPM layer to handle core suspend/resume on Exynos5420.
> >> >> Also, restore the entry address setup code post-resume.
> >> >>
> >> >> Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
> >> >
> >> > Acked-by: Nicolas Pitre <nico@linaro.org>
> >> This is one of the last missing bits for exynos MCPM. Thanks for your
> >> patient reviews of all the exynos mcpm back-end patches.
> >
> > Sorry for the delay in getting back to you.
> Thanks for your comments.
> >
> > You still need to handle the residency parameter in the MCPM suspend call
> > properly to differentiate between core gating and cluster gating.
> I am not too familiar with the cpuidle driver, but I see only cluster
> power off state listed in the bL cpuidle driver.
> >
> > CPUidle might want to request a state that allows for core gating
> > residency but not cluster gating one, in that case the last man
> > standing must not shutdown the cluster.
> For this, I would have to add another state to the bL cpuidle driver
> or migrate to using your under-review generic idle state patchset.
> Then based on the residency value skip/do cluster power down. Is this
> correct ?
> >
> > This must be handled in the power down function, and it can be done
> > in a separate patch since it is an optimization. Current MCPM interface has
> > all it is needed to handle this properly, and I am keen on patching the
> > CPUidle bL driver to pass the actual residency instead of hardcoding it
> > to 0 (ie on TC2 it was not needed, no core gating).
> I will look at doing this once the s2r patch gets merged.
Ok, let's get it done once the CPUidle bL driver DT version gets merged,
I will add a patch that passes the proper residency and you can patch
the MCPM back-end then, until then CPUidle will be suboptimal but I
guess we can live with that for now.
Thanks,
Lorenzo
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH mptcp-next] mptcp: drop legacy code.
@ 2023-06-12 16:02 Paolo Abeni
2023-06-13 17:37 ` mptcp: drop legacy code.: Tests Results MPTCP CI
0 siblings, 1 reply; 130+ messages in thread
From: Paolo Abeni @ 2023-06-12 16:02 UTC (permalink / raw)
To: mptcp
Thanks to the previous patch we can finally drop the "temporary hack"
used to detect rx eof.
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
---
"previous patch" should be replace with a proper commit reference
once such patch is merged on -net, unless we target both patches on
the same tree (but this one is really net-next material, while the fix
is for -net)
---
net/mptcp/protocol.c | 49 --------------------------------------------
net/mptcp/protocol.h | 5 +----
2 files changed, 1 insertion(+), 53 deletions(-)
diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index 8f3e50065c13..feaedfd2b3eb 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -898,49 +898,6 @@ bool mptcp_schedule_work(struct sock *sk)
return false;
}
-void mptcp_subflow_eof(struct sock *sk)
-{
- if (!test_and_set_bit(MPTCP_WORK_EOF, &mptcp_sk(sk)->flags))
- mptcp_schedule_work(sk);
-}
-
-static void mptcp_check_for_eof(struct mptcp_sock *msk)
-{
- struct mptcp_subflow_context *subflow;
- struct sock *sk = (struct sock *)msk;
- int receivers = 0;
-
- mptcp_for_each_subflow(msk, subflow)
- receivers += !subflow->rx_eof;
- if (receivers)
- return;
-
- if (!(sk->sk_shutdown & RCV_SHUTDOWN)) {
- /* hopefully temporary hack: propagate shutdown status
- * to msk, when all subflows agree on it
- */
- WRITE_ONCE(sk->sk_shutdown, sk->sk_shutdown | RCV_SHUTDOWN);
-
- smp_mb__before_atomic(); /* SHUTDOWN must be visible first */
- sk->sk_data_ready(sk);
- }
-
- switch (sk->sk_state) {
- case TCP_ESTABLISHED:
- inet_sk_state_store(sk, TCP_CLOSE_WAIT);
- break;
- case TCP_FIN_WAIT1:
- inet_sk_state_store(sk, TCP_CLOSING);
- break;
- case TCP_FIN_WAIT2:
- inet_sk_state_store(sk, TCP_CLOSE);
- break;
- default:
- return;
- }
- mptcp_close_wake_up(sk);
-}
-
static struct sock *mptcp_subflow_recv_lookup(const struct mptcp_sock *msk)
{
struct mptcp_subflow_context *subflow;
@@ -2193,9 +2150,6 @@ static int mptcp_recvmsg(struct sock *sk, struct msghdr *msg, size_t len,
break;
}
- if (test_and_clear_bit(MPTCP_WORK_EOF, &msk->flags))
- mptcp_check_for_eof(msk);
-
if (sk->sk_shutdown & RCV_SHUTDOWN) {
/* race breaker: the shutdown could be after the
* previous receive queue check
@@ -2726,9 +2680,6 @@ static void mptcp_worker(struct work_struct *work)
mptcp_pm_nl_work(msk);
- if (test_and_clear_bit(MPTCP_WORK_EOF, &msk->flags))
- mptcp_check_for_eof(msk);
-
mptcp_check_send_data_fin(sk);
mptcp_check_data_fin_ack(sk);
mptcp_check_data_fin(sk);
diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h
index d2e59cf33f57..528586e2ed73 100644
--- a/net/mptcp/protocol.h
+++ b/net/mptcp/protocol.h
@@ -113,7 +113,6 @@
/* MPTCP socket atomic flags */
#define MPTCP_NOSPACE 1
#define MPTCP_WORK_RTX 2
-#define MPTCP_WORK_EOF 3
#define MPTCP_FALLBACK_DONE 4
#define MPTCP_WORK_CLOSE_SUBFLOW 5
@@ -481,14 +480,13 @@ struct mptcp_subflow_context {
send_mp_fail : 1,
send_fastclose : 1,
send_infinite_map : 1,
- rx_eof : 1,
remote_key_valid : 1, /* received the peer key from */
disposable : 1, /* ctx can be free at ulp release time */
stale : 1, /* unable to snd/rcv data, do not use for xmit */
local_id_valid : 1, /* local_id is correctly initialized */
valid_csum_seen : 1, /* at least one csum validated */
is_mptfo : 1, /* subflow is doing TFO */
- __unused : 8;
+ __unused : 9;
enum mptcp_data_avail data_avail;
bool scheduled;
u32 remote_nonce;
@@ -744,7 +742,6 @@ static inline u64 mptcp_expand_seq(u64 old_seq, u64 cur_seq, bool use_64bit)
void __mptcp_check_push(struct sock *sk, struct sock *ssk);
void __mptcp_data_acked(struct sock *sk);
void __mptcp_error_report(struct sock *sk);
-void mptcp_subflow_eof(struct sock *sk);
bool mptcp_update_rcv_data_fin(struct mptcp_sock *msk, u64 data_fin_seq, bool use_64bit);
static inline bool mptcp_data_fin_enabled(const struct mptcp_sock *msk)
{
--
2.40.1
^ permalink raw reply related [flat|nested] 130+ messages in thread
* Re: mptcp: drop legacy code.: Tests Results
2023-06-12 16:02 [PATCH mptcp-next] mptcp: drop legacy code Paolo Abeni
@ 2023-06-13 17:37 ` MPTCP CI
2023-06-16 22:54 ` several messages Mat Martineau
0 siblings, 1 reply; 130+ messages in thread
From: MPTCP CI @ 2023-06-13 17:37 UTC (permalink / raw)
To: Paolo Abeni; +Cc: mptcp
Hi Paolo,
Thank you for your modifications, that's great!
Our CI did some validations and here is its report:
- KVM Validation: normal (except selftest_mptcp_join):
- Success! ✅:
- Task: https://cirrus-ci.com/task/6108358801883136
- Summary: https://api.cirrus-ci.com/v1/artifact/task/6108358801883136/summary/summary.txt
- KVM Validation: debug (only selftest_mptcp_join):
- Unstable: 1 failed test(s): selftest_mptcp_join 🔴:
- Task: https://cirrus-ci.com/task/4630615174152192
- Summary: https://api.cirrus-ci.com/v1/artifact/task/4630615174152192/summary/summary.txt
- KVM Validation: normal (only selftest_mptcp_join):
- Success! ✅:
- Task: https://cirrus-ci.com/task/5545408848461824
- Summary: https://api.cirrus-ci.com/v1/artifact/task/5545408848461824/summary/summary.txt
- KVM Validation: debug (except selftest_mptcp_join):
- Success! ✅:
- Task: https://cirrus-ci.com/task/6671308755304448
- Summary: https://api.cirrus-ci.com/v1/artifact/task/6671308755304448/summary/summary.txt
Initiator: Matthieu Baerts
Commits: https://github.com/multipath-tcp/mptcp_net-next/commits/bdbf7858d22c
If there are some issues, you can reproduce them using the same environment as
the one used by the CI thanks to a docker image, e.g.:
$ cd [kernel source code]
$ docker run -v "${PWD}:${PWD}:rw" -w "${PWD}" --privileged --rm -it \
--pull always mptcp/mptcp-upstream-virtme-docker:latest \
auto-debug
For more details:
https://github.com/multipath-tcp/mptcp-upstream-virtme-docker
Please note that despite all the efforts that have been already done to have a
stable tests suite when executed on a public CI like here, it is possible some
reported issues are not due to your modifications. Still, do not hesitate to
help us improve that ;-)
Cheers,
MPTCP GH Action bot
Bot operated by Matthieu Baerts (Tessares)
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
2023-06-13 17:37 ` mptcp: drop legacy code.: Tests Results MPTCP CI
@ 2023-06-16 22:54 ` Mat Martineau
0 siblings, 0 replies; 130+ messages in thread
From: Mat Martineau @ 2023-06-16 22:54 UTC (permalink / raw)
To: Paolo Abeni, mptcp
[-- Attachment #1: Type: text/plain, Size: 6401 bytes --]
On Mon, 12 Jun 2023, Paolo Abeni wrote:
> Thanks to the previous patch we can finally drop the "temporary hack"
> used to detect rx eof.
>
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
> ---
> "previous patch" should be replace with a proper commit reference
> once such patch is merged on -net, unless we target both patches on
> the same tree (but this one is really net-next material, while the fix
> is for -net)
Hi Paolo,
To be clear, the "previous patch" is "mptcp: consolidate fallback and non
fallback state machine"?
> ---
> net/mptcp/protocol.c | 49 --------------------------------------------
> net/mptcp/protocol.h | 5 +----
> 2 files changed, 1 insertion(+), 53 deletions(-)
Hooray for deleting code!
Reviewed-by: Mat Martineau <martineau@kernel.org>
>
> diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
> index 8f3e50065c13..feaedfd2b3eb 100644
> --- a/net/mptcp/protocol.c
> +++ b/net/mptcp/protocol.c
> @@ -898,49 +898,6 @@ bool mptcp_schedule_work(struct sock *sk)
> return false;
> }
>
> -void mptcp_subflow_eof(struct sock *sk)
> -{
> - if (!test_and_set_bit(MPTCP_WORK_EOF, &mptcp_sk(sk)->flags))
> - mptcp_schedule_work(sk);
> -}
> -
> -static void mptcp_check_for_eof(struct mptcp_sock *msk)
> -{
> - struct mptcp_subflow_context *subflow;
> - struct sock *sk = (struct sock *)msk;
> - int receivers = 0;
> -
> - mptcp_for_each_subflow(msk, subflow)
> - receivers += !subflow->rx_eof;
> - if (receivers)
> - return;
> -
> - if (!(sk->sk_shutdown & RCV_SHUTDOWN)) {
> - /* hopefully temporary hack: propagate shutdown status
> - * to msk, when all subflows agree on it
> - */
> - WRITE_ONCE(sk->sk_shutdown, sk->sk_shutdown | RCV_SHUTDOWN);
> -
> - smp_mb__before_atomic(); /* SHUTDOWN must be visible first */
> - sk->sk_data_ready(sk);
> - }
> -
> - switch (sk->sk_state) {
> - case TCP_ESTABLISHED:
> - inet_sk_state_store(sk, TCP_CLOSE_WAIT);
> - break;
> - case TCP_FIN_WAIT1:
> - inet_sk_state_store(sk, TCP_CLOSING);
> - break;
> - case TCP_FIN_WAIT2:
> - inet_sk_state_store(sk, TCP_CLOSE);
> - break;
> - default:
> - return;
> - }
> - mptcp_close_wake_up(sk);
> -}
> -
> static struct sock *mptcp_subflow_recv_lookup(const struct mptcp_sock *msk)
> {
> struct mptcp_subflow_context *subflow;
> @@ -2193,9 +2150,6 @@ static int mptcp_recvmsg(struct sock *sk, struct msghdr *msg, size_t len,
> break;
> }
>
> - if (test_and_clear_bit(MPTCP_WORK_EOF, &msk->flags))
> - mptcp_check_for_eof(msk);
> -
> if (sk->sk_shutdown & RCV_SHUTDOWN) {
> /* race breaker: the shutdown could be after the
> * previous receive queue check
> @@ -2726,9 +2680,6 @@ static void mptcp_worker(struct work_struct *work)
>
> mptcp_pm_nl_work(msk);
>
> - if (test_and_clear_bit(MPTCP_WORK_EOF, &msk->flags))
> - mptcp_check_for_eof(msk);
> -
> mptcp_check_send_data_fin(sk);
> mptcp_check_data_fin_ack(sk);
> mptcp_check_data_fin(sk);
> diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h
> index d2e59cf33f57..528586e2ed73 100644
> --- a/net/mptcp/protocol.h
> +++ b/net/mptcp/protocol.h
> @@ -113,7 +113,6 @@
> /* MPTCP socket atomic flags */
> #define MPTCP_NOSPACE 1
> #define MPTCP_WORK_RTX 2
> -#define MPTCP_WORK_EOF 3
> #define MPTCP_FALLBACK_DONE 4
> #define MPTCP_WORK_CLOSE_SUBFLOW 5
>
> @@ -481,14 +480,13 @@ struct mptcp_subflow_context {
> send_mp_fail : 1,
> send_fastclose : 1,
> send_infinite_map : 1,
> - rx_eof : 1,
> remote_key_valid : 1, /* received the peer key from */
> disposable : 1, /* ctx can be free at ulp release time */
> stale : 1, /* unable to snd/rcv data, do not use for xmit */
> local_id_valid : 1, /* local_id is correctly initialized */
> valid_csum_seen : 1, /* at least one csum validated */
> is_mptfo : 1, /* subflow is doing TFO */
> - __unused : 8;
> + __unused : 9;
> enum mptcp_data_avail data_avail;
> bool scheduled;
> u32 remote_nonce;
> @@ -744,7 +742,6 @@ static inline u64 mptcp_expand_seq(u64 old_seq, u64 cur_seq, bool use_64bit)
> void __mptcp_check_push(struct sock *sk, struct sock *ssk);
> void __mptcp_data_acked(struct sock *sk);
> void __mptcp_error_report(struct sock *sk);
> -void mptcp_subflow_eof(struct sock *sk);
> bool mptcp_update_rcv_data_fin(struct mptcp_sock *msk, u64 data_fin_seq, bool use_64bit);
> static inline bool mptcp_data_fin_enabled(const struct mptcp_sock *msk)
> {
> --
> 2.40.1
>
>
>
On Tue, 13 Jun 2023, MPTCP CI wrote:
> Hi Paolo,
>
> Thank you for your modifications, that's great!
>
> Our CI did some validations and here is its report:
>
> - KVM Validation: normal (except selftest_mptcp_join):
> - Success! ✅:
> - Task: https://cirrus-ci.com/task/6108358801883136
> - Summary: https://api.cirrus-ci.com/v1/artifact/task/6108358801883136/summary/summary.txt
>
> - KVM Validation: debug (only selftest_mptcp_join):
> - Unstable: 1 failed test(s): selftest_mptcp_join 🔴:
> - Task: https://cirrus-ci.com/task/4630615174152192
> - Summary: https://api.cirrus-ci.com/v1/artifact/task/4630615174152192/summary/summary.txt
>
> - KVM Validation: normal (only selftest_mptcp_join):
> - Success! ✅:
> - Task: https://cirrus-ci.com/task/5545408848461824
> - Summary: https://api.cirrus-ci.com/v1/artifact/task/5545408848461824/summary/summary.txt
>
> - KVM Validation: debug (except selftest_mptcp_join):
> - Success! ✅:
> - Task: https://cirrus-ci.com/task/6671308755304448
> - Summary: https://api.cirrus-ci.com/v1/artifact/task/6671308755304448/summary/summary.txt
>
> Initiator: Matthieu Baerts
> Commits: https://github.com/multipath-tcp/mptcp_net-next/commits/bdbf7858d22c
>
>
> If there are some issues, you can reproduce them using the same environment as
> the one used by the CI thanks to a docker image, e.g.:
>
> $ cd [kernel source code]
> $ docker run -v "${PWD}:${PWD}:rw" -w "${PWD}" --privileged --rm -it \
> --pull always mptcp/mptcp-upstream-virtme-docker:latest \
> auto-debug
>
> For more details:
>
> https://github.com/multipath-tcp/mptcp-upstream-virtme-docker
>
>
> Please note that despite all the efforts that have been already done to have a
> stable tests suite when executed on a public CI like here, it is possible some
> reported issues are not due to your modifications. Still, do not hesitate to
> help us improve that ;-)
>
> Cheers,
> MPTCP GH Action bot
> Bot operated by Matthieu Baerts (Tessares)
>
>
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH 00/18] make test "linting" more comprehensive
@ 2022-09-01 0:29 Eric Sunshine via GitGitGadget
2022-09-01 0:29 ` [PATCH 18/18] t: retire unused chainlint.sed Eric Sunshine via GitGitGadget
0 siblings, 1 reply; 130+ messages in thread
From: Eric Sunshine via GitGitGadget @ 2022-09-01 0:29 UTC (permalink / raw)
To: git
Cc: Jeff King, Elijah Newren, Ævar Arnfjörð Bjarmason,
Fabian Stelzer, Johannes Schindelin, Eric Sunshine
A while back, Peff successfully nerd-sniped[1] me into tackling a
long-brewing idea I had about (possibly) improving "chainlint" performance
by linting all tests in all scripts with a single command invocation instead
of running "sed" 26800+ times (once for each test). The new linter
introduced by this series can check all test definitions in the entire
project in a single invocation, and each test definition is checked only
once no matter how many times the test is actually run (unlike chainlint.sed
which will check a test repeatedly if, for instance, the test is run in a
loop). Moreover, all test definitions in the project are "linted" even if
some of those tests would not run on a particular platform or under a
certain configuration (unlike chainlint.sed which only lints tests which
actually run).
The new linter is a good deal smarter than chainlint.sed and understands not
just shell syntax but also some semantics of test construction, unlike
chainlint.sed which is merely heuristics-based. For instance, the new linter
recognizes cases when a broken &&-chain is legitimate, such as when "$?" is
handled explicitly or when a failure is signaled directly with "false", in
which case the &&-chain leading up to the "false" is immaterial, as well as
other cases. Unlike chainlint.sed, it recognizes that a semicolon after the
last command in a compound statement is harmless, thus won't interpret the
semicolon as breaking the &&-chain.
The new linter also provides considerably better coverage for broken
&&-chains. The "magic exit code 117" &&-chain checker built into test-lib.sh
only works for top-level command invocations; it doesn't work within "{...}"
groups, "(...)" subshells, "$(...)" substitutions, or within bodies of
compound statements, such as "if", "for", "while", "case", etc.
chainlint.sed partly fills the gap by catching broken &&-chains in "(...)"
subshells one level deep, but bugs can still lurk behind broken &&-chains in
the other cases. The new linter catches broken &&-chains within all those
constructs to any depth.
Another important improvement is that the new linter understands that shell
loops do not terminate automatically when a command in the loop body fails,
and that the condition needs to be handled explicitly by the test author by
using "|| return 1" (or "|| exit 1" in a subshell) to signal failure.
Consequently, the new linter will complain when a loop is lacking "|| return
1" (or "|| exit 1").
Finally, unlike chainlint.sed which (not surprisingly) is implemented in
"sed", the new linter is written in Perl, thus should be more accessible to
a wider audience, and is structured as a traditional top-down parser which
makes it much easier to reason about.
The new linter could eventually subsume other linting tasks such as
check-nonportable-shell.pl (which itself takes a couple seconds to run on my
machine), though it probably should be renamed to something other than
"chainlint" since it is no longer targeted only at spotting &&-chain breaks,
but that can wait for another day.
Ævar offered some sensible comments[2,3] about optimizing the Makefile rules
related to chainlint, but those optimizations are not tackled here for a few
reasons: (1) this series is already quite long, (2) I'd like to keep the
series focused on its primary goal of installing a new and improved linter,
(3) these patches do not make the Makefile situation any worse[4], and (4)
those optimizations can easily be done atop this series[5].
Junio: This series is nominally atop es/t4301-sed-portability-fix which is
in "next", and es/fix-chained-tests, es/test-chain-lint, and es/chainlint,
all of which are already in "master".
Dscho: This series conflicts with some patches carried only by the Git for
Windows project; the resolutions are obvious and simple. The new linter also
identifies some problems in tests carried only by the Git for Windows
project.
[1] https://lore.kernel.org/git/YJzGcZpZ+E9R0gYd@coredump.intra.peff.net/
[2]
https://lore.kernel.org/git/RFC-patch-1.1-bb3f1577829-20211213T095456Z-avarab@gmail.com/
[3] https://lore.kernel.org/git/211213.86tufc8oop.gmgdl@evledraar.gmail.com/
[4]
https://lore.kernel.org/git/CAPig+cSFtpt6ExbVDbcx3tZodrKFuM-r2GMW4TQ2tJmLvHBFtQ@mail.gmail.com/
[5] https://lore.kernel.org/git/211214.86tufbbbu3.gmgdl@evledraar.gmail.com/
Eric Sunshine (18):
t: add skeleton chainlint.pl
chainlint.pl: add POSIX shell lexical analyzer
chainlint.pl: add POSIX shell parser
chainlint.pl: add parser to validate tests
chainlint.pl: add parser to identify test definitions
chainlint.pl: validate test scripts in parallel
chainlint.pl: don't require `return|exit|continue` to end with `&&`
t/Makefile: apply chainlint.pl to existing self-tests
chainlint.pl: don't require `&` background command to end with `&&`
chainlint.pl: don't flag broken &&-chain if `$?` handled explicitly
chainlint.pl: don't flag broken &&-chain if failure indicated
explicitly
chainlint.pl: complain about loops lacking explicit failure handling
chainlint.pl: allow `|| echo` to signal failure upstream of a pipe
t/chainlint: add more chainlint.pl self-tests
test-lib: retire "lint harder" optimization hack
test-lib: replace chainlint.sed with chainlint.pl
t/Makefile: teach `make test` and `make prove` to run chainlint.pl
t: retire unused chainlint.sed
contrib/buildsystems/CMakeLists.txt | 2 +-
t/Makefile | 49 +-
t/README | 5 -
t/chainlint.pl | 730 ++++++++++++++++++
t/chainlint.sed | 399 ----------
t/chainlint/blank-line-before-esac.expect | 18 +
t/chainlint/blank-line-before-esac.test | 19 +
t/chainlint/block.expect | 15 +-
t/chainlint/block.test | 15 +-
t/chainlint/chain-break-background.expect | 9 +
t/chainlint/chain-break-background.test | 10 +
t/chainlint/chain-break-continue.expect | 12 +
t/chainlint/chain-break-continue.test | 13 +
t/chainlint/chain-break-false.expect | 9 +
t/chainlint/chain-break-false.test | 10 +
t/chainlint/chain-break-return-exit.expect | 19 +
t/chainlint/chain-break-return-exit.test | 23 +
t/chainlint/chain-break-status.expect | 9 +
t/chainlint/chain-break-status.test | 11 +
t/chainlint/chained-block.expect | 9 +
t/chainlint/chained-block.test | 11 +
t/chainlint/chained-subshell.expect | 10 +
t/chainlint/chained-subshell.test | 13 +
.../command-substitution-subsubshell.expect | 2 +
.../command-substitution-subsubshell.test | 3 +
t/chainlint/complex-if-in-cuddled-loop.expect | 2 +-
t/chainlint/double-here-doc.expect | 2 +
t/chainlint/double-here-doc.test | 12 +
t/chainlint/dqstring-line-splice.expect | 3 +
t/chainlint/dqstring-line-splice.test | 7 +
t/chainlint/dqstring-no-interpolate.expect | 11 +
t/chainlint/dqstring-no-interpolate.test | 15 +
t/chainlint/empty-here-doc.expect | 3 +
t/chainlint/empty-here-doc.test | 5 +
t/chainlint/exclamation.expect | 4 +
t/chainlint/exclamation.test | 8 +
t/chainlint/for-loop-abbreviated.expect | 5 +
t/chainlint/for-loop-abbreviated.test | 6 +
t/chainlint/for-loop.expect | 4 +-
t/chainlint/function.expect | 11 +
t/chainlint/function.test | 13 +
t/chainlint/here-doc-indent-operator.expect | 5 +
t/chainlint/here-doc-indent-operator.test | 13 +
t/chainlint/here-doc-multi-line-string.expect | 3 +-
t/chainlint/if-condition-split.expect | 7 +
t/chainlint/if-condition-split.test | 8 +
t/chainlint/if-in-loop.expect | 2 +-
t/chainlint/if-in-loop.test | 2 +-
t/chainlint/loop-detect-failure.expect | 15 +
t/chainlint/loop-detect-failure.test | 17 +
t/chainlint/loop-detect-status.expect | 18 +
t/chainlint/loop-detect-status.test | 19 +
t/chainlint/loop-in-if.expect | 2 +-
t/chainlint/loop-upstream-pipe.expect | 10 +
t/chainlint/loop-upstream-pipe.test | 11 +
t/chainlint/multi-line-string.expect | 11 +-
t/chainlint/nested-loop-detect-failure.expect | 31 +
t/chainlint/nested-loop-detect-failure.test | 35 +
t/chainlint/nested-subshell.expect | 2 +-
t/chainlint/one-liner-for-loop.expect | 9 +
t/chainlint/one-liner-for-loop.test | 10 +
t/chainlint/return-loop.expect | 5 +
t/chainlint/return-loop.test | 6 +
t/chainlint/semicolon.expect | 2 +-
t/chainlint/sqstring-in-sqstring.expect | 4 +
t/chainlint/sqstring-in-sqstring.test | 5 +
t/chainlint/t7900-subtree.expect | 13 +-
t/chainlint/token-pasting.expect | 27 +
t/chainlint/token-pasting.test | 32 +
t/chainlint/while-loop.expect | 4 +-
t/t0027-auto-crlf.sh | 7 +-
t/t3070-wildmatch.sh | 5 -
t/test-lib.sh | 12 +-
73 files changed, 1439 insertions(+), 449 deletions(-)
create mode 100755 t/chainlint.pl
delete mode 100644 t/chainlint.sed
create mode 100644 t/chainlint/blank-line-before-esac.expect
create mode 100644 t/chainlint/blank-line-before-esac.test
create mode 100644 t/chainlint/chain-break-background.expect
create mode 100644 t/chainlint/chain-break-background.test
create mode 100644 t/chainlint/chain-break-continue.expect
create mode 100644 t/chainlint/chain-break-continue.test
create mode 100644 t/chainlint/chain-break-false.expect
create mode 100644 t/chainlint/chain-break-false.test
create mode 100644 t/chainlint/chain-break-return-exit.expect
create mode 100644 t/chainlint/chain-break-return-exit.test
create mode 100644 t/chainlint/chain-break-status.expect
create mode 100644 t/chainlint/chain-break-status.test
create mode 100644 t/chainlint/chained-block.expect
create mode 100644 t/chainlint/chained-block.test
create mode 100644 t/chainlint/chained-subshell.expect
create mode 100644 t/chainlint/chained-subshell.test
create mode 100644 t/chainlint/command-substitution-subsubshell.expect
create mode 100644 t/chainlint/command-substitution-subsubshell.test
create mode 100644 t/chainlint/double-here-doc.expect
create mode 100644 t/chainlint/double-here-doc.test
create mode 100644 t/chainlint/dqstring-line-splice.expect
create mode 100644 t/chainlint/dqstring-line-splice.test
create mode 100644 t/chainlint/dqstring-no-interpolate.expect
create mode 100644 t/chainlint/dqstring-no-interpolate.test
create mode 100644 t/chainlint/empty-here-doc.expect
create mode 100644 t/chainlint/empty-here-doc.test
create mode 100644 t/chainlint/exclamation.expect
create mode 100644 t/chainlint/exclamation.test
create mode 100644 t/chainlint/for-loop-abbreviated.expect
create mode 100644 t/chainlint/for-loop-abbreviated.test
create mode 100644 t/chainlint/function.expect
create mode 100644 t/chainlint/function.test
create mode 100644 t/chainlint/here-doc-indent-operator.expect
create mode 100644 t/chainlint/here-doc-indent-operator.test
create mode 100644 t/chainlint/if-condition-split.expect
create mode 100644 t/chainlint/if-condition-split.test
create mode 100644 t/chainlint/loop-detect-failure.expect
create mode 100644 t/chainlint/loop-detect-failure.test
create mode 100644 t/chainlint/loop-detect-status.expect
create mode 100644 t/chainlint/loop-detect-status.test
create mode 100644 t/chainlint/loop-upstream-pipe.expect
create mode 100644 t/chainlint/loop-upstream-pipe.test
create mode 100644 t/chainlint/nested-loop-detect-failure.expect
create mode 100644 t/chainlint/nested-loop-detect-failure.test
create mode 100644 t/chainlint/one-liner-for-loop.expect
create mode 100644 t/chainlint/one-liner-for-loop.test
create mode 100644 t/chainlint/return-loop.expect
create mode 100644 t/chainlint/return-loop.test
create mode 100644 t/chainlint/sqstring-in-sqstring.expect
create mode 100644 t/chainlint/sqstring-in-sqstring.test
create mode 100644 t/chainlint/token-pasting.expect
create mode 100644 t/chainlint/token-pasting.test
base-commit: d42b38dfb5edf1a7fddd9542d722f91038407819
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-1322%2Fsunshineco%2Fchainlintperl-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-1322/sunshineco/chainlintperl-v1
Pull-Request: https://github.com/git/git/pull/1322
--
gitgitgadget
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH 18/18] t: retire unused chainlint.sed
2022-09-01 0:29 [PATCH 00/18] make test "linting" more comprehensive Eric Sunshine via GitGitGadget
@ 2022-09-01 0:29 ` Eric Sunshine via GitGitGadget
2022-09-02 12:42 ` several messages Johannes Schindelin
0 siblings, 1 reply; 130+ messages in thread
From: Eric Sunshine via GitGitGadget @ 2022-09-01 0:29 UTC (permalink / raw)
To: git
Cc: Jeff King, Elijah Newren, Ævar Arnfjörð Bjarmason,
Fabian Stelzer, Johannes Schindelin, Eric Sunshine,
Eric Sunshine
From: Eric Sunshine <sunshine@sunshineco.com>
Retire chainlint.sed since it has been replaced by a more accurate and
functional &&-chain "linter", thus is no longer used.
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
---
t/chainlint.sed | 399 ------------------------------------------------
1 file changed, 399 deletions(-)
delete mode 100644 t/chainlint.sed
diff --git a/t/chainlint.sed b/t/chainlint.sed
deleted file mode 100644
index dc4ce37cb51..00000000000
--- a/t/chainlint.sed
+++ /dev/null
@@ -1,399 +0,0 @@
-#------------------------------------------------------------------------------
-# Detect broken &&-chains in tests.
-#
-# At present, only &&-chains in subshells are examined by this linter;
-# top-level &&-chains are instead checked directly by the test framework. Like
-# the top-level &&-chain linter, the subshell linter (intentionally) does not
-# check &&-chains within {...} blocks.
-#
-# Checking for &&-chain breakage is done line-by-line by pure textual
-# inspection.
-#
-# Incomplete lines (those ending with "\") are stitched together with following
-# lines to simplify processing, particularly of "one-liner" statements.
-# Top-level here-docs are swallowed to avoid false positives within the
-# here-doc body, although the statement to which the here-doc is attached is
-# retained.
-#
-# Heuristics are used to detect end-of-subshell when the closing ")" is cuddled
-# with the final subshell statement on the same line:
-#
-# (cd foo &&
-# bar)
-#
-# in order to avoid misinterpreting the ")" in constructs such as "x=$(...)"
-# and "case $x in *)" as ending the subshell.
-#
-# Lines missing a final "&&" are flagged with "?!AMP?!", as are lines which
-# chain commands with ";" internally rather than "&&". A line may be flagged
-# for both violations.
-#
-# Detection of a missing &&-link in a multi-line subshell is complicated by the
-# fact that the last statement before the closing ")" must not end with "&&".
-# Since processing is line-by-line, it is not known whether a missing "&&" is
-# legitimate or not until the _next_ line is seen. To accommodate this, within
-# multi-line subshells, each line is stored in sed's "hold" area until after
-# the next line is seen and processed. If the next line is a stand-alone ")",
-# then a missing "&&" on the previous line is legitimate; otherwise a missing
-# "&&" is a break in the &&-chain.
-#
-# (
-# cd foo &&
-# bar
-# )
-#
-# In practical terms, when "bar" is encountered, it is flagged with "?!AMP?!",
-# but when the stand-alone ")" line is seen which closes the subshell, the
-# "?!AMP?!" violation is removed from the "bar" line (retrieved from the "hold"
-# area) since the final statement of a subshell must not end with "&&". The
-# final line of a subshell may still break the &&-chain by using ";" internally
-# to chain commands together rather than "&&", but an internal "?!AMP?!" is
-# never removed from a line even though a line-ending "?!AMP?!" might be.
-#
-# Care is taken to recognize the last _statement_ of a multi-line subshell, not
-# necessarily the last textual _line_ within the subshell, since &&-chaining
-# applies to statements, not to lines. Consequently, blank lines, comment
-# lines, and here-docs are swallowed (but not the command to which the here-doc
-# is attached), leaving the last statement in the "hold" area, not the last
-# line, thus simplifying &&-link checking.
-#
-# The final statement before "done" in for- and while-loops, and before "elif",
-# "else", and "fi" in if-then-else likewise must not end with "&&", thus
-# receives similar treatment.
-#
-# Swallowing here-docs with arbitrary tags requires a bit of finesse. When a
-# line such as "cat <<EOF" is seen, the here-doc tag is copied to the front of
-# the line enclosed in angle brackets as a sentinel, giving "<EOF>cat <<EOF".
-# As each subsequent line is read, it is appended to the target line and a
-# (whitespace-loose) back-reference match /^<(.*)>\n\1$/ is attempted to see if
-# the content inside "<...>" matches the entirety of the newly-read line. For
-# instance, if the next line read is "some data", when concatenated with the
-# target line, it becomes "<EOF>cat <<EOF\nsome data", and a match is attempted
-# to see if "EOF" matches "some data". Since it doesn't, the next line is
-# attempted. When a line consisting of only "EOF" (and possible whitespace) is
-# encountered, it is appended to the target line giving "<EOF>cat <<EOF\nEOF",
-# in which case the "EOF" inside "<...>" does match the text following the
-# newline, thus the closing here-doc tag has been found. The closing tag line
-# and the "<...>" prefix on the target line are then discarded, leaving just
-# the target line "cat <<EOF".
-#------------------------------------------------------------------------------
-
-# incomplete line -- slurp up next line
-:squash
-/\\$/ {
- N
- s/\\\n//
- bsquash
-}
-
-# here-doc -- swallow it to avoid false hits within its body (but keep the
-# command to which it was attached)
-/<<-*[ ]*[\\'"]*[A-Za-z0-9_]/ {
- /"[^"]*<<[^"]*"/bnotdoc
- s/^\(.*<<-*[ ]*\)[\\'"]*\([A-Za-z0-9_][A-Za-z0-9_]*\)['"]*/<\2>\1\2/
- :hered
- N
- /^<\([^>]*\)>.*\n[ ]*\1[ ]*$/!{
- s/\n.*$//
- bhered
- }
- s/^<[^>]*>//
- s/\n.*$//
-}
-:notdoc
-
-# one-liner "(...) &&"
-/^[ ]*!*[ ]*(..*)[ ]*&&[ ]*$/boneline
-
-# same as above but without trailing "&&"
-/^[ ]*!*[ ]*(..*)[ ]*$/boneline
-
-# one-liner "(...) >x" (or "2>x" or "<x" or "|x" or "&"
-/^[ ]*!*[ ]*(..*)[ ]*[0-9]*[<>|&]/boneline
-
-# multi-line "(...\n...)"
-/^[ ]*(/bsubsh
-
-# innocuous line -- print it and advance to next line
-b
-
-# found one-liner "(...)" -- mark suspect if it uses ";" internally rather than
-# "&&" (but not ";" in a string)
-:oneline
-/;/{
- /"[^"]*;[^"]*"/!s/;/; ?!AMP?!/
-}
-b
-
-:subsh
-# bare "(" line? -- stash for later printing
-/^[ ]*([ ]*$/ {
- h
- bnextln
-}
-# "(..." line -- "(" opening subshell cuddled with command; temporarily replace
-# "(" with sentinel "^" and process the line as if "(" had been seen solo on
-# the preceding line; this temporary replacement prevents several rules from
-# accidentally thinking "(" introduces a nested subshell; "^" is changed back
-# to "(" at output time
-x
-s/.*//
-x
-s/(/^/
-bslurp
-
-:nextln
-N
-s/.*\n//
-
-:slurp
-# incomplete line "...\"
-/\\$/bicmplte
-# multi-line quoted string "...\n..."?
-/"/bdqstr
-# multi-line quoted string '...\n...'? (but not contraction in string "it's")
-/'/{
- /"[^'"]*'[^'"]*"/!bsqstr
-}
-:folded
-# here-doc -- swallow it (but not "<<" in a string)
-/<<-*[ ]*[\\'"]*[A-Za-z0-9_]/{
- /"[^"]*<<[^"]*"/!bheredoc
-}
-# comment or empty line -- discard since final non-comment, non-empty line
-# before closing ")", "done", "elsif", "else", or "fi" will need to be
-# re-visited to drop "suspect" marking since final line of those constructs
-# legitimately lacks "&&", so "suspect" mark must be removed
-/^[ ]*#/bnextln
-/^[ ]*$/bnextln
-# in-line comment -- strip it (but not "#" in a string, Bash ${#...} array
-# length, or Perforce "//depot/path#42" revision in filespec)
-/[ ]#/{
- /"[^"]*#[^"]*"/!s/[ ]#.*$//
-}
-# one-liner "case ... esac"
-/^[ ^]*case[ ]*..*esac/bchkchn
-# multi-line "case ... esac"
-/^[ ^]*case[ ]..*[ ]in/bcase
-# multi-line "for ... done" or "while ... done"
-/^[ ^]*for[ ]..*[ ]in/bcont
-/^[ ^]*while[ ]/bcont
-/^[ ]*do[ ]/bcont
-/^[ ]*do[ ]*$/bcont
-/;[ ]*do/bcont
-/^[ ]*done[ ]*&&[ ]*$/bdone
-/^[ ]*done[ ]*$/bdone
-/^[ ]*done[ ]*[<>|]/bdone
-/^[ ]*done[ ]*)/bdone
-/||[ ]*exit[ ]/bcont
-/||[ ]*exit[ ]*$/bcont
-# multi-line "if...elsif...else...fi"
-/^[ ^]*if[ ]/bcont
-/^[ ]*then[ ]/bcont
-/^[ ]*then[ ]*$/bcont
-/;[ ]*then/bcont
-/^[ ]*elif[ ]/belse
-/^[ ]*elif[ ]*$/belse
-/^[ ]*else[ ]/belse
-/^[ ]*else[ ]*$/belse
-/^[ ]*fi[ ]*&&[ ]*$/bdone
-/^[ ]*fi[ ]*$/bdone
-/^[ ]*fi[ ]*[<>|]/bdone
-/^[ ]*fi[ ]*)/bdone
-# nested one-liner "(...) &&"
-/^[ ^]*(.*)[ ]*&&[ ]*$/bchkchn
-# nested one-liner "(...)"
-/^[ ^]*(.*)[ ]*$/bchkchn
-# nested one-liner "(...) >x" (or "2>x" or "<x" or "|x")
-/^[ ^]*(.*)[ ]*[0-9]*[<>|]/bchkchn
-# nested multi-line "(...\n...)"
-/^[ ^]*(/bnest
-# multi-line "{...\n...}"
-/^[ ^]*{/bblock
-# closing ")" on own line -- exit subshell
-/^[ ]*)/bclssolo
-# "$((...))" -- arithmetic expansion; not closing ")"
-/\$(([^)][^)]*))[^)]*$/bchkchn
-# "$(...)" -- command substitution; not closing ")"
-/\$([^)][^)]*)[^)]*$/bchkchn
-# multi-line "$(...\n...)" -- command substitution; treat as nested subshell
-/\$([^)]*$/bnest
-# "=(...)" -- Bash array assignment; not closing ")"
-/=(/bchkchn
-# closing "...) &&"
-/)[ ]*&&[ ]*$/bclose
-# closing "...)"
-/)[ ]*$/bclose
-# closing "...) >x" (or "2>x" or "<x" or "|x")
-/)[ ]*[<>|]/bclose
-:chkchn
-# mark suspect if line uses ";" internally rather than "&&" (but not ";" in a
-# string and not ";;" in one-liner "case...esac")
-/;/{
- /;;/!{
- /"[^"]*;[^"]*"/!s/;/; ?!AMP?!/
- }
-}
-# line ends with pipe "...|" -- valid; not missing "&&"
-/|[ ]*$/bcont
-# missing end-of-line "&&" -- mark suspect
-/&&[ ]*$/!s/$/ ?!AMP?!/
-:cont
-# retrieve and print previous line
-x
-s/^\([ ]*\)^/\1(/
-s/?!HERE?!/<</g
-n
-bslurp
-
-# found incomplete line "...\" -- slurp up next line
-:icmplte
-N
-s/\\\n//
-bslurp
-
-# check for multi-line double-quoted string "...\n..." -- fold to one line
-:dqstr
-# remove all quote pairs
-s/"\([^"]*\)"/@!\1@!/g
-# done if no dangling quote
-/"/!bdqdone
-# otherwise, slurp next line and try again
-N
-s/\n//
-bdqstr
-:dqdone
-s/@!/"/g
-bfolded
-
-# check for multi-line single-quoted string '...\n...' -- fold to one line
-:sqstr
-# remove all quote pairs
-s/'\([^']*\)'/@!\1@!/g
-# done if no dangling quote
-/'/!bsqdone
-# otherwise, slurp next line and try again
-N
-s/\n//
-bsqstr
-:sqdone
-s/@!/'/g
-bfolded
-
-# found here-doc -- swallow it to avoid false hits within its body (but keep
-# the command to which it was attached)
-:heredoc
-s/^\(.*\)<<\(-*[ ]*\)[\\'"]*\([A-Za-z0-9_][A-Za-z0-9_]*\)['"]*/<\3>\1?!HERE?!\2\3/
-:hdocsub
-N
-/^<\([^>]*\)>.*\n[ ]*\1[ ]*$/!{
- s/\n.*$//
- bhdocsub
-}
-s/^<[^>]*>//
-s/\n.*$//
-bfolded
-
-# found "case ... in" -- pass through untouched
-:case
-x
-s/^\([ ]*\)^/\1(/
-s/?!HERE?!/<</g
-n
-:cascom
-/^[ ]*#/{
- N
- s/.*\n//
- bcascom
-}
-/^[ ]*esac/bslurp
-bcase
-
-# found "else" or "elif" -- drop "suspect" from final line before "else" since
-# that line legitimately lacks "&&"
-:else
-x
-s/\( ?!AMP?!\)* ?!AMP?!$//
-x
-bcont
-
-# found "done" closing for-loop or while-loop, or "fi" closing if-then -- drop
-# "suspect" from final contained line since that line legitimately lacks "&&"
-:done
-x
-s/\( ?!AMP?!\)* ?!AMP?!$//
-x
-# is 'done' or 'fi' cuddled with ")" to close subshell?
-/done.*)/bclose
-/fi.*)/bclose
-bchkchn
-
-# found nested multi-line "(...\n...)" -- pass through untouched
-:nest
-x
-:nstslrp
-s/^\([ ]*\)^/\1(/
-s/?!HERE?!/<</g
-n
-:nstcom
-# comment -- not closing ")" if in comment
-/^[ ]*#/{
- N
- s/.*\n//
- bnstcom
-}
-# closing ")" on own line -- stop nested slurp
-/^[ ]*)/bnstcl
-# "$((...))" -- arithmetic expansion; not closing ")"
-/\$(([^)][^)]*))[^)]*$/bnstcnt
-# "$(...)" -- command substitution; not closing ")"
-/\$([^)][^)]*)[^)]*$/bnstcnt
-# closing "...)" -- stop nested slurp
-/)/bnstcl
-:nstcnt
-x
-bnstslrp
-:nstcl
-# is it "))" which closes nested and parent subshells?
-/)[ ]*)/bslurp
-bchkchn
-
-# found multi-line "{...\n...}" block -- pass through untouched
-:block
-x
-s/^\([ ]*\)^/\1(/
-s/?!HERE?!/<</g
-n
-:blkcom
-/^[ ]*#/{
- N
- s/.*\n//
- bblkcom
-}
-# closing "}" -- stop block slurp
-/}/bchkchn
-bblock
-
-# found closing ")" on own line -- drop "suspect" from final line of subshell
-# since that line legitimately lacks "&&" and exit subshell loop
-:clssolo
-x
-s/\( ?!AMP?!\)* ?!AMP?!$//
-s/^\([ ]*\)^/\1(/
-s/?!HERE?!/<</g
-p
-x
-s/^\([ ]*\)^/\1(/
-s/?!HERE?!/<</g
-b
-
-# found closing "...)" -- exit subshell loop
-:close
-x
-s/^\([ ]*\)^/\1(/
-s/?!HERE?!/<</g
-p
-x
-s/^\([ ]*\)^/\1(/
-s/?!HERE?!/<</g
-b
--
gitgitgadget
^ permalink raw reply related [flat|nested] 130+ messages in thread
* Re: several messages
2022-09-01 0:29 ` [PATCH 18/18] t: retire unused chainlint.sed Eric Sunshine via GitGitGadget
@ 2022-09-02 12:42 ` Johannes Schindelin
2022-09-02 18:16 ` Eric Sunshine
0 siblings, 1 reply; 130+ messages in thread
From: Johannes Schindelin @ 2022-09-02 12:42 UTC (permalink / raw)
To: Eric Sunshine via GitGitGadget, Ævar Arnfjörð Bjarmason
Cc: git, Jeff King, Elijah Newren, Fabian Stelzer, Eric Sunshine
Hi Eric,
On Thu, 1 Sep 2022, Eric Sunshine via GitGitGadget wrote:
> contrib/buildsystems/CMakeLists.txt | 2 +-
> t/Makefile | 49 +-
> t/README | 5 -
> t/chainlint.pl | 730 ++++++++++++++++++
> t/chainlint.sed | 399 ----------
> t/chainlint/blank-line-before-esac.expect | 18 +
> t/chainlint/blank-line-before-esac.test | 19 +
> t/chainlint/block.expect | 15 +-
> t/chainlint/block.test | 15 +-
> t/chainlint/chain-break-background.expect | 9 +
> t/chainlint/chain-break-background.test | 10 +
> t/chainlint/chain-break-continue.expect | 12 +
> t/chainlint/chain-break-continue.test | 13 +
> t/chainlint/chain-break-false.expect | 9 +
> t/chainlint/chain-break-false.test | 10 +
> t/chainlint/chain-break-return-exit.expect | 19 +
> t/chainlint/chain-break-return-exit.test | 23 +
> t/chainlint/chain-break-status.expect | 9 +
> t/chainlint/chain-break-status.test | 11 +
> t/chainlint/chained-block.expect | 9 +
> t/chainlint/chained-block.test | 11 +
> t/chainlint/chained-subshell.expect | 10 +
> t/chainlint/chained-subshell.test | 13 +
> .../command-substitution-subsubshell.expect | 2 +
> .../command-substitution-subsubshell.test | 3 +
> t/chainlint/complex-if-in-cuddled-loop.expect | 2 +-
> t/chainlint/double-here-doc.expect | 2 +
> t/chainlint/double-here-doc.test | 12 +
> t/chainlint/dqstring-line-splice.expect | 3 +
> t/chainlint/dqstring-line-splice.test | 7 +
> t/chainlint/dqstring-no-interpolate.expect | 11 +
> t/chainlint/dqstring-no-interpolate.test | 15 +
> t/chainlint/empty-here-doc.expect | 3 +
> t/chainlint/empty-here-doc.test | 5 +
> t/chainlint/exclamation.expect | 4 +
> t/chainlint/exclamation.test | 8 +
> t/chainlint/for-loop-abbreviated.expect | 5 +
> t/chainlint/for-loop-abbreviated.test | 6 +
> t/chainlint/for-loop.expect | 4 +-
> t/chainlint/function.expect | 11 +
> t/chainlint/function.test | 13 +
> t/chainlint/here-doc-indent-operator.expect | 5 +
> t/chainlint/here-doc-indent-operator.test | 13 +
> t/chainlint/here-doc-multi-line-string.expect | 3 +-
> t/chainlint/if-condition-split.expect | 7 +
> t/chainlint/if-condition-split.test | 8 +
> t/chainlint/if-in-loop.expect | 2 +-
> t/chainlint/if-in-loop.test | 2 +-
> t/chainlint/loop-detect-failure.expect | 15 +
> t/chainlint/loop-detect-failure.test | 17 +
> t/chainlint/loop-detect-status.expect | 18 +
> t/chainlint/loop-detect-status.test | 19 +
> t/chainlint/loop-in-if.expect | 2 +-
> t/chainlint/loop-upstream-pipe.expect | 10 +
> t/chainlint/loop-upstream-pipe.test | 11 +
> t/chainlint/multi-line-string.expect | 11 +-
> t/chainlint/nested-loop-detect-failure.expect | 31 +
> t/chainlint/nested-loop-detect-failure.test | 35 +
> t/chainlint/nested-subshell.expect | 2 +-
> t/chainlint/one-liner-for-loop.expect | 9 +
> t/chainlint/one-liner-for-loop.test | 10 +
> t/chainlint/return-loop.expect | 5 +
> t/chainlint/return-loop.test | 6 +
> t/chainlint/semicolon.expect | 2 +-
> t/chainlint/sqstring-in-sqstring.expect | 4 +
> t/chainlint/sqstring-in-sqstring.test | 5 +
> t/chainlint/t7900-subtree.expect | 13 +-
> t/chainlint/token-pasting.expect | 27 +
> t/chainlint/token-pasting.test | 32 +
> t/chainlint/while-loop.expect | 4 +-
> t/t0027-auto-crlf.sh | 7 +-
> t/t3070-wildmatch.sh | 5 -
> t/test-lib.sh | 12 +-
> 73 files changed, 1439 insertions(+), 449 deletions(-)
> create mode 100755 t/chainlint.pl
> delete mode 100644 t/chainlint.sed
> create mode 100644 t/chainlint/blank-line-before-esac.expect
> create mode 100644 t/chainlint/blank-line-before-esac.test
> create mode 100644 t/chainlint/chain-break-background.expect
> create mode 100644 t/chainlint/chain-break-background.test
> create mode 100644 t/chainlint/chain-break-continue.expect
> create mode 100644 t/chainlint/chain-break-continue.test
> create mode 100644 t/chainlint/chain-break-false.expect
> create mode 100644 t/chainlint/chain-break-false.test
> create mode 100644 t/chainlint/chain-break-return-exit.expect
> create mode 100644 t/chainlint/chain-break-return-exit.test
> create mode 100644 t/chainlint/chain-break-status.expect
> create mode 100644 t/chainlint/chain-break-status.test
> create mode 100644 t/chainlint/chained-block.expect
> create mode 100644 t/chainlint/chained-block.test
> create mode 100644 t/chainlint/chained-subshell.expect
> create mode 100644 t/chainlint/chained-subshell.test
> create mode 100644 t/chainlint/command-substitution-subsubshell.expect
> create mode 100644 t/chainlint/command-substitution-subsubshell.test
> create mode 100644 t/chainlint/double-here-doc.expect
> create mode 100644 t/chainlint/double-here-doc.test
> create mode 100644 t/chainlint/dqstring-line-splice.expect
> create mode 100644 t/chainlint/dqstring-line-splice.test
> create mode 100644 t/chainlint/dqstring-no-interpolate.expect
> create mode 100644 t/chainlint/dqstring-no-interpolate.test
> create mode 100644 t/chainlint/empty-here-doc.expect
> create mode 100644 t/chainlint/empty-here-doc.test
> create mode 100644 t/chainlint/exclamation.expect
> create mode 100644 t/chainlint/exclamation.test
> create mode 100644 t/chainlint/for-loop-abbreviated.expect
> create mode 100644 t/chainlint/for-loop-abbreviated.test
> create mode 100644 t/chainlint/function.expect
> create mode 100644 t/chainlint/function.test
> create mode 100644 t/chainlint/here-doc-indent-operator.expect
> create mode 100644 t/chainlint/here-doc-indent-operator.test
> create mode 100644 t/chainlint/if-condition-split.expect
> create mode 100644 t/chainlint/if-condition-split.test
> create mode 100644 t/chainlint/loop-detect-failure.expect
> create mode 100644 t/chainlint/loop-detect-failure.test
> create mode 100644 t/chainlint/loop-detect-status.expect
> create mode 100644 t/chainlint/loop-detect-status.test
> create mode 100644 t/chainlint/loop-upstream-pipe.expect
> create mode 100644 t/chainlint/loop-upstream-pipe.test
> create mode 100644 t/chainlint/nested-loop-detect-failure.expect
> create mode 100644 t/chainlint/nested-loop-detect-failure.test
> create mode 100644 t/chainlint/one-liner-for-loop.expect
> create mode 100644 t/chainlint/one-liner-for-loop.test
> create mode 100644 t/chainlint/return-loop.expect
> create mode 100644 t/chainlint/return-loop.test
> create mode 100644 t/chainlint/sqstring-in-sqstring.expect
> create mode 100644 t/chainlint/sqstring-in-sqstring.test
> create mode 100644 t/chainlint/token-pasting.expect
> create mode 100644 t/chainlint/token-pasting.test
This looks like it was a lot of work. And that it would be a lot of work
to review, too, and certainly even more work to maintain.
Are we really sure that we want to burden the Git project with this much
stuff that is not actually related to Git's core functionality?
It would be one thing if we could use a well-maintained third-party tool
to do this job. But adding this to our plate? I hope we can avoid that.
Ciao,
Dscho
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
2022-09-02 12:42 ` several messages Johannes Schindelin
@ 2022-09-02 18:16 ` Eric Sunshine
2022-09-02 18:34 ` Jeff King
0 siblings, 1 reply; 130+ messages in thread
From: Eric Sunshine @ 2022-09-02 18:16 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Eric Sunshine via GitGitGadget,
Ævar Arnfjörð Bjarmason, Git List, Jeff King,
Elijah Newren, Fabian Stelzer
On Fri, Sep 2, 2022 at 8:42 AM Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> On Thu, 1 Sep 2022, Eric Sunshine via GitGitGadget wrote:
> > t/chainlint.pl | 730 ++++++++++++++++++
> > t/chainlint.sed | 399 ----------
> > t/chainlint/blank-line-before-esac.expect | 18 +
> > t/chainlint/blank-line-before-esac.test | 19 +
> > ...
>
> This looks like it was a lot of work. And that it would be a lot of work
> to review, too, and certainly even more work to maintain.
>
> Are we really sure that we want to burden the Git project with this much
> stuff that is not actually related to Git's core functionality?
>
> It would be one thing if we could use a well-maintained third-party tool
> to do this job. But adding this to our plate? I hope we can avoid that.
I understand your concerns about review and maintenance burden, and
you're not the first to make such observations; when chainlint.sed was
submitted, it was greeted with similar concerns[1,2], all very
understandable. The key takeaway[3] from that conversation, though,
was that, unlike user-facing features which must be reviewed in detail
and maintained in perpetuity, this is a mere developer aid which can
be easily ejected from the project if it ever becomes a maintenance
burden or shows itself to be unreliable. Potential maintenance burden
aside, a very real benefit of such a tool is that it should help
prevent bugs from slipping into the project going forward[4], which is
indeed the aim of all our developer-focused aids.
In more practical terms, despite initial concerns, in the 4+ years
since its introduction, the maintenance cost of chainlint.sed has been
nearly zero. Very early on, there was a report[5] that chainlint.sed
was showing a false-positive in a `contrib` test script; the developer
quickly responded with a fix[6]. The only other maintenance issues
were a couple dead-simple changes[7,8] to shorten "labels" to support
older versions of `sed`. (As for the chainlint self-tests, the
maintenance cost has been exactly zero). My hope is that chainlint.pl
should have a similar track-record, but it can easily be dropped from
the project if not.
[1]: https://lore.kernel.org/git/xmqqk1q11mkj.fsf@gitster-ct.c.googlers.com/
[2]: https://lore.kernel.org/git/20180712165608.GA10515@sigill.intra.peff.net/
[3]: https://lore.kernel.org/git/CAPig+cRmAkiYqFXwRAkQALDoOo-79r2iAumdEJEZhBnETvL-fw@mail.gmail.com/
[4]: https://lore.kernel.org/git/xmqqin5kw7q3.fsf@gitster-ct.c.googlers.com/
[5]: https://lore.kernel.org/git/20180730181356.GA156463@aiede.svl.corp.google.com/
[6]: https://lore.kernel.org/git/20180807082135.60913-1-sunshine@sunshineco.com/
[7]: https://lore.kernel.org/git/20180824152016.20286-5-avarab@gmail.com/
[8]: https://lore.kernel.org/git/d15ed626de65c51ef2ba31020eeb2111fb8e091f.1596675905.git.gitgitgadget@gmail.com/
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
2022-09-02 18:16 ` Eric Sunshine
@ 2022-09-02 18:34 ` Jeff King
2022-09-02 18:44 ` Junio C Hamano
0 siblings, 1 reply; 130+ messages in thread
From: Jeff King @ 2022-09-02 18:34 UTC (permalink / raw)
To: Eric Sunshine
Cc: Johannes Schindelin, Eric Sunshine via GitGitGadget,
Ævar Arnfjörð Bjarmason, Git List, Elijah Newren,
Fabian Stelzer
On Fri, Sep 02, 2022 at 02:16:21PM -0400, Eric Sunshine wrote:
> > It would be one thing if we could use a well-maintained third-party tool
> > to do this job. But adding this to our plate? I hope we can avoid that.
>
> I understand your concerns about review and maintenance burden, and
> you're not the first to make such observations; when chainlint.sed was
> submitted, it was greeted with similar concerns[1,2], all very
> understandable. The key takeaway[3] from that conversation, though,
> was that, unlike user-facing features which must be reviewed in detail
> and maintained in perpetuity, this is a mere developer aid which can
> be easily ejected from the project if it ever becomes a maintenance
> burden or shows itself to be unreliable. Potential maintenance burden
> aside, a very real benefit of such a tool is that it should help
> prevent bugs from slipping into the project going forward[4], which is
> indeed the aim of all our developer-focused aids.
Thanks for this response and especially the links. My initial gut
response was similar to Dscho's. Which is not surprising, because it
apparently was also my initial response to chainlint.sed back then. ;)
But I do think that chainlint.sed has proven itself to be both useful
and not much of a maintenance burden. My only real complaint was the
additional runtime in a few corner cases, and that is exactly what
you're addressing here.
I'm not excited about carefully reviewing it. At the same time, given
the low stakes, I'm kind of willing to accept that between the tests and
the results of running it on the current code base, the proof is in the
pudding.
-Peff
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
2022-09-02 18:34 ` Jeff King
@ 2022-09-02 18:44 ` Junio C Hamano
0 siblings, 0 replies; 130+ messages in thread
From: Junio C Hamano @ 2022-09-02 18:44 UTC (permalink / raw)
To: Jeff King
Cc: Eric Sunshine, Johannes Schindelin,
Eric Sunshine via GitGitGadget,
Ævar Arnfjörð Bjarmason, Git List, Elijah Newren,
Fabian Stelzer
Jeff King <peff@peff.net> writes:
> Thanks for this response and especially the links. My initial gut
> response was similar to Dscho's. Which is not surprising, because it
> apparently was also my initial response to chainlint.sed back then. ;)
>
> But I do think that chainlint.sed has proven itself to be both useful
> and not much of a maintenance burden. My only real complaint was the
> additional runtime in a few corner cases, and that is exactly what
> you're addressing here.
I have nothing to add to the above ;-) Thanks all (including Dscho
who made us be more explicit in pros-and-cons).
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH mptcp-next] selftests: mptcp: tweak simult_flows for debug kernels.
@ 2022-06-16 13:55 Paolo Abeni
2022-06-16 15:27 ` selftests: mptcp: tweak simult_flows for debug kernels.: Tests Results MPTCP CI
0 siblings, 1 reply; 130+ messages in thread
From: Paolo Abeni @ 2022-06-16 13:55 UTC (permalink / raw)
To: mptcp
The mentioned test measures the transfer run-time to verify
that the user-space program is able to use the full aggregate B/W.
Even on (virtual) link-speed-bound tests, debug kernel can slow
down the transfer enough to cause sporadic test failures.
Instead of unconditionally raising the maximum allowed run-time,
tweak when the running kernel is a debug one, and use some simple/
rough heuristic to guess such scenarios.
Note: this intentionally avoids looking for /boot/config-<version> as
the latter file is not always available in our reference CI
environments.
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
---
tools/testing/selftests/net/mptcp/simult_flows.sh | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/net/mptcp/simult_flows.sh b/tools/testing/selftests/net/mptcp/simult_flows.sh
index f441ff7904fc..141fcf0d40d1 100755
--- a/tools/testing/selftests/net/mptcp/simult_flows.sh
+++ b/tools/testing/selftests/net/mptcp/simult_flows.sh
@@ -12,6 +12,7 @@ timeout_test=$((timeout_poll * 2 + 1))
test_cnt=1
ret=0
bail=0
+slack=50
usage() {
echo "Usage: $0 [ -b ] [ -c ] [ -d ]"
@@ -52,6 +53,7 @@ setup()
cout=$(mktemp)
capout=$(mktemp)
size=$((2 * 2048 * 4096))
+
dd if=/dev/zero of=$small bs=4096 count=20 >/dev/null 2>&1
dd if=/dev/zero of=$large bs=4096 count=$((size / 4096)) >/dev/null 2>&1
@@ -104,6 +106,13 @@ setup()
ip -net "$ns3" route add default via dead:beef:3::2
ip netns exec "$ns3" ./pm_nl_ctl limits 1 1
+
+ # debug build can slow down measurably the test program
+ # we use quite tight time limit on the run-time, to ensure
+ # maximum B/W usage.
+ # Use the kmemleak file presence as a rough estimate for this being
+ # a debug kernel and increase the maximum run-time accordingly
+ [ -f /sys/kernel/debug/kmemleak ] && slack=$((slack+200))
}
# $1: ns, $2: port
@@ -241,7 +250,7 @@ run_test()
# mptcp_connect will do some sleeps to allow the mp_join handshake
# completion (see mptcp_connect): 200ms on each side, add some slack
- time=$((time + 450))
+ time=$((time + 400 + $slack))
printf "%-60s" "$msg"
do_transfer $small $large $time
--
2.35.3
^ permalink raw reply related [flat|nested] 130+ messages in thread
* Re: selftests: mptcp: tweak simult_flows for debug kernels.: Tests Results
2022-06-16 13:55 [PATCH mptcp-next] selftests: mptcp: tweak simult_flows for debug kernels Paolo Abeni
@ 2022-06-16 15:27 ` MPTCP CI
2022-06-17 22:13 ` several messages Mat Martineau
0 siblings, 1 reply; 130+ messages in thread
From: MPTCP CI @ 2022-06-16 15:27 UTC (permalink / raw)
To: Paolo Abeni; +Cc: mptcp
Hi Paolo,
Thank you for your modifications, that's great!
Our CI did some validations and here is its report:
- KVM Validation: normal:
- Success! ✅:
- Task: https://cirrus-ci.com/task/5708948505362432
- Summary: https://api.cirrus-ci.com/v1/artifact/task/5708948505362432/summary/summary.txt
- KVM Validation: debug:
- Unstable: 3 failed test(s): packetdrill_add_addr selftest_diag selftest_mptcp_join 🔴:
- Task: https://cirrus-ci.com/task/5145998551941120
- Summary: https://api.cirrus-ci.com/v1/artifact/task/5145998551941120/summary/summary.txt
Initiator: Patchew Applier
Commits: https://github.com/multipath-tcp/mptcp_net-next/commits/727243b29682
If there are some issues, you can reproduce them using the same environment as
the one used by the CI thanks to a docker image, e.g.:
$ cd [kernel source code]
$ docker run -v "${PWD}:${PWD}:rw" -w "${PWD}" --privileged --rm -it \
--pull always mptcp/mptcp-upstream-virtme-docker:latest \
auto-debug
For more details:
https://github.com/multipath-tcp/mptcp-upstream-virtme-docker
Please note that despite all the efforts that have been already done to have a
stable tests suite when executed on a public CI like here, it is possible some
reported issues are not due to your modifications. Still, do not hesitate to
help us improve that ;-)
Cheers,
MPTCP GH Action bot
Bot operated by Matthieu Baerts (Tessares)
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
2022-06-16 15:27 ` selftests: mptcp: tweak simult_flows for debug kernels.: Tests Results MPTCP CI
@ 2022-06-17 22:13 ` Mat Martineau
0 siblings, 0 replies; 130+ messages in thread
From: Mat Martineau @ 2022-06-17 22:13 UTC (permalink / raw)
To: Paolo Abeni, mptcp
[-- Attachment #1: Type: text/plain, Size: 3986 bytes --]
On Thu, 16 Jun 2022, Paolo Abeni wrote:
> The mentioned test measures the transfer run-time to verify
> that the user-space program is able to use the full aggregate B/W.
>
> Even on (virtual) link-speed-bound tests, debug kernel can slow
> down the transfer enough to cause sporadic test failures.
>
> Instead of unconditionally raising the maximum allowed run-time,
> tweak when the running kernel is a debug one, and use some simple/
> rough heuristic to guess such scenarios.
>
> Note: this intentionally avoids looking for /boot/config-<version> as
> the latter file is not always available in our reference CI
> environments.
>
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Looks good, runs fine in my vm with debug kernel config:
Reviewed-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
> ---
> tools/testing/selftests/net/mptcp/simult_flows.sh | 11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/tools/testing/selftests/net/mptcp/simult_flows.sh b/tools/testing/selftests/net/mptcp/simult_flows.sh
> index f441ff7904fc..141fcf0d40d1 100755
> --- a/tools/testing/selftests/net/mptcp/simult_flows.sh
> +++ b/tools/testing/selftests/net/mptcp/simult_flows.sh
> @@ -12,6 +12,7 @@ timeout_test=$((timeout_poll * 2 + 1))
> test_cnt=1
> ret=0
> bail=0
> +slack=50
>
> usage() {
> echo "Usage: $0 [ -b ] [ -c ] [ -d ]"
> @@ -52,6 +53,7 @@ setup()
> cout=$(mktemp)
> capout=$(mktemp)
> size=$((2 * 2048 * 4096))
> +
> dd if=/dev/zero of=$small bs=4096 count=20 >/dev/null 2>&1
> dd if=/dev/zero of=$large bs=4096 count=$((size / 4096)) >/dev/null 2>&1
>
> @@ -104,6 +106,13 @@ setup()
> ip -net "$ns3" route add default via dead:beef:3::2
>
> ip netns exec "$ns3" ./pm_nl_ctl limits 1 1
> +
> + # debug build can slow down measurably the test program
> + # we use quite tight time limit on the run-time, to ensure
> + # maximum B/W usage.
> + # Use the kmemleak file presence as a rough estimate for this being
> + # a debug kernel and increase the maximum run-time accordingly
> + [ -f /sys/kernel/debug/kmemleak ] && slack=$((slack+200))
> }
>
> # $1: ns, $2: port
> @@ -241,7 +250,7 @@ run_test()
>
> # mptcp_connect will do some sleeps to allow the mp_join handshake
> # completion (see mptcp_connect): 200ms on each side, add some slack
> - time=$((time + 450))
> + time=$((time + 400 + $slack))
>
> printf "%-60s" "$msg"
> do_transfer $small $large $time
> --
> 2.35.3
>
>
>
On Thu, 16 Jun 2022, MPTCP CI wrote:
> Hi Paolo,
>
> Thank you for your modifications, that's great!
>
> Our CI did some validations and here is its report:
>
> - KVM Validation: normal:
> - Success! ✅:
> - Task: https://cirrus-ci.com/task/5708948505362432
> - Summary: https://api.cirrus-ci.com/v1/artifact/task/5708948505362432/summary/summary.txt
>
> - KVM Validation: debug:
> - Unstable: 3 failed test(s): packetdrill_add_addr selftest_diag selftest_mptcp_join 🔴:
> - Task: https://cirrus-ci.com/task/5145998551941120
> - Summary: https://api.cirrus-ci.com/v1/artifact/task/5145998551941120/summary/summary.txt
>
> Initiator: Patchew Applier
> Commits: https://github.com/multipath-tcp/mptcp_net-next/commits/727243b29682
>
>
> If there are some issues, you can reproduce them using the same environment as
> the one used by the CI thanks to a docker image, e.g.:
>
> $ cd [kernel source code]
> $ docker run -v "${PWD}:${PWD}:rw" -w "${PWD}" --privileged --rm -it \
> --pull always mptcp/mptcp-upstream-virtme-docker:latest \
> auto-debug
>
> For more details:
>
> https://github.com/multipath-tcp/mptcp-upstream-virtme-docker
>
>
> Please note that despite all the efforts that have been already done to have a
> stable tests suite when executed on a public CI like here, it is possible some
> reported issues are not due to your modifications. Still, do not hesitate to
> help us improve that ;-)
>
> Cheers,
> MPTCP GH Action bot
> Bot operated by Matthieu Baerts (Tessares)
>
>
--
Mat Martineau
Intel
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH v2 0/3] x86/mm: INVPCID support
@ 2016-01-25 18:37 Andy Lutomirski
2016-01-25 18:57 ` Ingo Molnar
0 siblings, 1 reply; 130+ messages in thread
From: Andy Lutomirski @ 2016-01-25 18:37 UTC (permalink / raw)
To: x86, linux-kernel
Cc: Borislav Petkov, Brian Gerst, Dave Hansen, Linus Torvalds,
Oleg Nesterov, linux-mm, Andrey Ryabinin, Andy Lutomirski
Ingo, before applying this, please apply these two KASAN fixes:
http://lkml.kernel.org/g/1452516679-32040-2-git-send-email-aryabinin@virtuozzo.com
http://lkml.kernel.org/g/1452516679-32040-3-git-send-email-aryabinin@virtuozzo.com
Without those fixes, this series will trigger a KASAN bug.
This is a straightforward speedup on Ivy Bridge and newer, IIRC.
(I tested on Skylake. INVPCID is not available on Sandy Bridge.
I don't have Ivy Bridge, Haswell or Broadwell to test on, so I
could be wrong as to when the feature was introduced.)
I think we should consider these patches separately from the rest
of the PCID stuff -- they barely interact, and this part is much
simpler and is useful on its own.
This is exactly identical to patches 2-4 of the PCID RFC series.
Andy Lutomirski (3):
x86/mm: Add INVPCID helpers
x86/mm: Add a noinvpcid option to turn off INVPCID
x86/mm: If INVPCID is available, use it to flush global mappings
Documentation/kernel-parameters.txt | 2 ++
arch/x86/include/asm/tlbflush.h | 50 +++++++++++++++++++++++++++++++++++++
arch/x86/kernel/cpu/common.c | 16 ++++++++++++
3 files changed, 68 insertions(+)
--
2.5.0
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: [PATCH v2 0/3] x86/mm: INVPCID support
2016-01-25 18:37 [PATCH v2 0/3] x86/mm: INVPCID support Andy Lutomirski
@ 2016-01-25 18:57 ` Ingo Molnar
2016-01-27 10:09 ` Thomas Gleixner
0 siblings, 1 reply; 130+ messages in thread
From: Ingo Molnar @ 2016-01-25 18:57 UTC (permalink / raw)
To: Andy Lutomirski
Cc: x86, linux-kernel, Borislav Petkov, Brian Gerst, Dave Hansen,
Linus Torvalds, Oleg Nesterov, linux-mm, Andrey Ryabinin
* Andy Lutomirski <luto@kernel.org> wrote:
> Ingo, before applying this, please apply these two KASAN fixes:
>
> http://lkml.kernel.org/g/1452516679-32040-2-git-send-email-aryabinin@virtuozzo.com
> http://lkml.kernel.org/g/1452516679-32040-3-git-send-email-aryabinin@virtuozzo.com
>
> Without those fixes, this series will trigger a KASAN bug.
>
> This is a straightforward speedup on Ivy Bridge and newer, IIRC.
> (I tested on Skylake. INVPCID is not available on Sandy Bridge.
> I don't have Ivy Bridge, Haswell or Broadwell to test on, so I
> could be wrong as to when the feature was introduced.)
>
> I think we should consider these patches separately from the rest
> of the PCID stuff -- they barely interact, and this part is much
> simpler and is useful on its own.
>
> This is exactly identical to patches 2-4 of the PCID RFC series.
>
> Andy Lutomirski (3):
> x86/mm: Add INVPCID helpers
> x86/mm: Add a noinvpcid option to turn off INVPCID
> x86/mm: If INVPCID is available, use it to flush global mappings
>
> Documentation/kernel-parameters.txt | 2 ++
> arch/x86/include/asm/tlbflush.h | 50 +++++++++++++++++++++++++++++++++++++
> arch/x86/kernel/cpu/common.c | 16 ++++++++++++
> 3 files changed, 68 insertions(+)
Ok, I'll pick these up tomorrow unless there are objections.
Thanks,
Ingo
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
2016-01-25 18:57 ` Ingo Molnar
@ 2016-01-27 10:09 ` Thomas Gleixner
0 siblings, 0 replies; 130+ messages in thread
From: Thomas Gleixner @ 2016-01-27 10:09 UTC (permalink / raw)
To: Andy Lutomirski, Ingo Molnar
Cc: x86, linux-kernel, Borislav Petkov, Brian Gerst, Dave Hansen,
Linus Torvalds, Oleg Nesterov, linux-mm, Andrey Ryabinin
On Mon, 25 Jan 2016, Andy Lutomirski wrote:
> This is a straightforward speedup on Ivy Bridge and newer, IIRC.
> (I tested on Skylake. INVPCID is not available on Sandy Bridge.
> I don't have Ivy Bridge, Haswell or Broadwell to test on, so I
> could be wrong as to when the feature was introduced.)
Haswell and Broadwell have it. No idea about ivy bridge.
Thanks,
tglx
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
@ 2016-01-27 10:09 ` Thomas Gleixner
0 siblings, 0 replies; 130+ messages in thread
From: Thomas Gleixner @ 2016-01-27 10:09 UTC (permalink / raw)
To: Andy Lutomirski, Ingo Molnar
Cc: x86, linux-kernel, Borislav Petkov, Brian Gerst, Dave Hansen,
Linus Torvalds, Oleg Nesterov, linux-mm, Andrey Ryabinin
On Mon, 25 Jan 2016, Andy Lutomirski wrote:
> This is a straightforward speedup on Ivy Bridge and newer, IIRC.
> (I tested on Skylake. INVPCID is not available on Sandy Bridge.
> I don't have Ivy Bridge, Haswell or Broadwell to test on, so I
> could be wrong as to when the feature was introduced.)
Haswell and Broadwell have it. No idea about ivy bridge.
Thanks,
tglx
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
2016-01-27 10:09 ` Thomas Gleixner
(?)
@ 2016-01-29 13:21 ` Borislav Petkov
-1 siblings, 0 replies; 130+ messages in thread
From: Borislav Petkov @ 2016-01-29 13:21 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Andy Lutomirski, Ingo Molnar, x86, linux-kernel, Brian Gerst,
Dave Hansen, Linus Torvalds, Oleg Nesterov, linux-mm,
Andrey Ryabinin
On Wed, Jan 27, 2016 at 11:09:04AM +0100, Thomas Gleixner wrote:
> On Mon, 25 Jan 2016, Andy Lutomirski wrote:
> > This is a straightforward speedup on Ivy Bridge and newer, IIRC.
> > (I tested on Skylake. INVPCID is not available on Sandy Bridge.
> > I don't have Ivy Bridge, Haswell or Broadwell to test on, so I
> > could be wrong as to when the feature was introduced.)
>
> Haswell and Broadwell have it. No idea about ivy bridge.
I have an IVB model 58. It doesn't have it:
CPUID_0x00000007: EAX=0x00000000, EBX=0x00000281, ECX=0x00000000, EDX=0x00000000
INVPCID should be EBX[10].
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH 00/13] Add VT-d Posted-Interrupts support for KVM
@ 2014-11-10 6:26 Feng Wu
2014-11-10 6:26 ` [PATCH 13/13] iommu/vt-d: Add a command line parameter for VT-d posted-interrupts Feng Wu
0 siblings, 1 reply; 130+ messages in thread
From: Feng Wu @ 2014-11-10 6:26 UTC (permalink / raw)
To: gleb, pbonzini, dwmw2, joro, tglx, mingo, hpa, x86
Cc: kvm, iommu, linux-kernel, Feng Wu
VT-d Posted-Interrupts is an enhancement to CPU side Posted-Interrupt.
With VT-d Posted-Interrupts enabled, external interrupts from
direct-assigned devices can be delivered to guests without VMM
intervention when guest is running in non-root mode.
You can find the VT-d Posted-Interrtups Spec. in the following URL:
http://www.intel.com/content/www/us/en/intelligent-systems/intel-technology/vt-directed-io-spec.html
Feng Wu (13):
iommu/vt-d: VT-d Posted-Interrupts feature detection
KVM: Initialize VT-d Posted-Interrtups Descriptor
KVM: Add KVM_CAP_PI to detect VT-d Posted-Interrtups
iommu/vt-d: Adjust 'struct irte' to better suit for VT-d
Posted-Interrupts
KVM: Update IRTE according to guest interrupt configuration changes
KVM: Add some helper functions for Posted-Interrupts
x86, irq: Define a global vector for VT-d Posted-Interrupts
KVM: Update Posted-Interrupts descriptor during VCPU scheduling
KVM: Change NDST field after VCPU scheduling
KVM: Add the handler for Wake-up Vector
KVM: Suppress posted-interrupt when 'SN' is set
iommu/vt-d: No need to migrating irq for VT-d Posted-Interrtups
iommu/vt-d: Add a command line parameter for VT-d posted-interrupts
arch/x86/include/asm/entry_arch.h | 2 +
arch/x86/include/asm/hardirq.h | 1 +
arch/x86/include/asm/hw_irq.h | 2 +
arch/x86/include/asm/irq_remapping.h | 7 +
arch/x86/include/asm/irq_vectors.h | 1 +
arch/x86/include/asm/kvm_host.h | 9 ++
arch/x86/kernel/apic/apic.c | 1 +
arch/x86/kernel/entry_64.S | 2 +
arch/x86/kernel/irq.c | 27 ++++
arch/x86/kernel/irqinit.c | 2 +
arch/x86/kvm/vmx.c | 257 +++++++++++++++++++++++++++++++++-
arch/x86/kvm/x86.c | 53 ++++++-
drivers/iommu/amd_iommu.c | 6 +
drivers/iommu/intel_irq_remapping.c | 83 +++++++++--
drivers/iommu/irq_remapping.c | 20 +++
drivers/iommu/irq_remapping.h | 8 +
include/linux/dmar.h | 30 ++++-
include/linux/intel-iommu.h | 1 +
include/linux/kvm_host.h | 25 ++++
include/uapi/linux/kvm.h | 2 +
virt/kvm/assigned-dev.c | 141 +++++++++++++++++++
virt/kvm/irq_comm.c | 4 +-
virt/kvm/irqchip.c | 11 --
virt/kvm/kvm_main.c | 14 ++
24 files changed, 667 insertions(+), 42 deletions(-)
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH 13/13] iommu/vt-d: Add a command line parameter for VT-d posted-interrupts
2014-11-10 6:26 [PATCH 00/13] Add VT-d Posted-Interrupts support for KVM Feng Wu
@ 2014-11-10 6:26 ` Feng Wu
2014-11-10 18:15 ` Thomas Gleixner
0 siblings, 1 reply; 130+ messages in thread
From: Feng Wu @ 2014-11-10 6:26 UTC (permalink / raw)
To: gleb, pbonzini, dwmw2, joro, tglx, mingo, hpa, x86
Cc: kvm, iommu, linux-kernel, Feng Wu
Enable VT-d Posted-Interrtups and add a command line
parameter for it.
Signed-off-by: Feng Wu <feng.wu@intel.com>
---
drivers/iommu/irq_remapping.c | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/iommu/irq_remapping.c b/drivers/iommu/irq_remapping.c
index 0e36860..3cb9429 100644
--- a/drivers/iommu/irq_remapping.c
+++ b/drivers/iommu/irq_remapping.c
@@ -23,7 +23,7 @@ int irq_remap_broken;
int disable_sourceid_checking;
int no_x2apic_optout;
-int disable_irq_post = 1;
+int disable_irq_post = 0;
int irq_post_enabled = 0;
EXPORT_SYMBOL_GPL(irq_post_enabled);
@@ -206,6 +206,13 @@ static __init int setup_irqremap(char *str)
}
early_param("intremap", setup_irqremap);
+static __init int setup_nointpost(char *str)
+{
+ disable_irq_post = 1;
+ return 0;
+}
+early_param("nointpost", setup_nointpost);
+
void __init setup_irq_remapping_ops(void)
{
remap_ops = &intel_irq_remap_ops;
--
1.7.1
^ permalink raw reply related [flat|nested] 130+ messages in thread
* Re: several messages
@ 2014-11-10 18:15 ` Thomas Gleixner
0 siblings, 0 replies; 130+ messages in thread
From: Thomas Gleixner @ 2014-11-10 18:15 UTC (permalink / raw)
To: Feng Wu
Cc: gleb, pbonzini, David Woodhouse, joro, mingo, H. Peter Anvin,
x86, kvm, iommu, LKML, Jiang Liu
On Mon, 10 Nov 2014, Feng Wu wrote:
> VT-d Posted-Interrupts is an enhancement to CPU side Posted-Interrupt.
> With VT-d Posted-Interrupts enabled, external interrupts from
> direct-assigned devices can be delivered to guests without VMM
> intervention when guest is running in non-root mode.
Can you please talk to Jiang and synchronize your work with his
refactoring of the x86 interrupt handling subsystem.
I want this stuff cleaned up first before we add new stuff to it.
Thanks,
tglx
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
@ 2014-11-10 18:15 ` Thomas Gleixner
0 siblings, 0 replies; 130+ messages in thread
From: Thomas Gleixner @ 2014-11-10 18:15 UTC (permalink / raw)
To: Feng Wu
Cc: kvm-u79uwXL29TY76Z2rM5mHXA, gleb-DgEjT+Ai2ygdnm+yROfE0A,
x86-DgEjT+Ai2ygdnm+yROfE0A, LKML,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
mingo-H+wXaHxf7aLQT0dZR+AlfA, H. Peter Anvin,
pbonzini-H+wXaHxf7aLQT0dZR+AlfA, David Woodhouse, Jiang Liu
On Mon, 10 Nov 2014, Feng Wu wrote:
> VT-d Posted-Interrupts is an enhancement to CPU side Posted-Interrupt.
> With VT-d Posted-Interrupts enabled, external interrupts from
> direct-assigned devices can be delivered to guests without VMM
> intervention when guest is running in non-root mode.
Can you please talk to Jiang and synchronize your work with his
refactoring of the x86 interrupt handling subsystem.
I want this stuff cleaned up first before we add new stuff to it.
Thanks,
tglx
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
2014-11-10 18:15 ` Thomas Gleixner
@ 2014-11-11 2:28 ` Jiang Liu
-1 siblings, 0 replies; 130+ messages in thread
From: Jiang Liu @ 2014-11-11 2:28 UTC (permalink / raw)
To: Thomas Gleixner, Feng Wu
Cc: gleb, pbonzini, David Woodhouse, joro, mingo, H. Peter Anvin,
x86, kvm, iommu, LKML
On 2014/11/11 2:15, Thomas Gleixner wrote:
> On Mon, 10 Nov 2014, Feng Wu wrote:
>
>> VT-d Posted-Interrupts is an enhancement to CPU side Posted-Interrupt.
>> With VT-d Posted-Interrupts enabled, external interrupts from
>> direct-assigned devices can be delivered to guests without VMM
>> intervention when guest is running in non-root mode.
>
> Can you please talk to Jiang and synchronize your work with his
> refactoring of the x86 interrupt handling subsystem.
>
> I want this stuff cleaned up first before we add new stuff to it.
Hi Thomas,
Just talked with Feng, we will focused on refactor first and
then add posted interrupt support.
Regards!
Gerry
>
> Thanks,
>
> tglx
>
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
@ 2014-11-11 2:28 ` Jiang Liu
0 siblings, 0 replies; 130+ messages in thread
From: Jiang Liu @ 2014-11-11 2:28 UTC (permalink / raw)
To: Thomas Gleixner, Feng Wu
Cc: kvm-u79uwXL29TY76Z2rM5mHXA, gleb-DgEjT+Ai2ygdnm+yROfE0A,
x86-DgEjT+Ai2ygdnm+yROfE0A, LKML,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
mingo-H+wXaHxf7aLQT0dZR+AlfA, H. Peter Anvin,
pbonzini-H+wXaHxf7aLQT0dZR+AlfA, David Woodhouse
On 2014/11/11 2:15, Thomas Gleixner wrote:
> On Mon, 10 Nov 2014, Feng Wu wrote:
>
>> VT-d Posted-Interrupts is an enhancement to CPU side Posted-Interrupt.
>> With VT-d Posted-Interrupts enabled, external interrupts from
>> direct-assigned devices can be delivered to guests without VMM
>> intervention when guest is running in non-root mode.
>
> Can you please talk to Jiang and synchronize your work with his
> refactoring of the x86 interrupt handling subsystem.
>
> I want this stuff cleaned up first before we add new stuff to it.
Hi Thomas,
Just talked with Feng, we will focused on refactor first and
then add posted interrupt support.
Regards!
Gerry
>
> Thanks,
>
> tglx
>
^ permalink raw reply [flat|nested] 130+ messages in thread
* RE: several messages
@ 2014-11-11 6:37 ` Wu, Feng
0 siblings, 0 replies; 130+ messages in thread
From: Wu, Feng @ 2014-11-11 6:37 UTC (permalink / raw)
To: Jiang Liu, Thomas Gleixner
Cc: gleb, pbonzini, David Woodhouse, joro, mingo, H. Peter Anvin,
x86, kvm, iommu, LKML
> -----Original Message-----
> From: Jiang Liu [mailto:jiang.liu@linux.intel.com]
> Sent: Tuesday, November 11, 2014 10:29 AM
> To: Thomas Gleixner; Wu, Feng
> Cc: gleb@kernel.org; pbonzini@redhat.com; David Woodhouse;
> joro@8bytes.org; mingo@redhat.com; H. Peter Anvin; x86@kernel.org;
> kvm@vger.kernel.org; iommu@lists.linux-foundation.org; LKML
> Subject: Re: several messages
>
> On 2014/11/11 2:15, Thomas Gleixner wrote:
> > On Mon, 10 Nov 2014, Feng Wu wrote:
> >
> >> VT-d Posted-Interrupts is an enhancement to CPU side Posted-Interrupt.
> >> With VT-d Posted-Interrupts enabled, external interrupts from
> >> direct-assigned devices can be delivered to guests without VMM
> >> intervention when guest is running in non-root mode.
> >
> > Can you please talk to Jiang and synchronize your work with his
> > refactoring of the x86 interrupt handling subsystem.
> >
> > I want this stuff cleaned up first before we add new stuff to it.
> Hi Thomas,
> Just talked with Feng, we will focused on refactor first and
> then add posted interrupt support.
> Regards!
> Gerry
No problem!
Thanks,
Feng
>
> >
> > Thanks,
> >
> > tglx
> >
^ permalink raw reply [flat|nested] 130+ messages in thread
* RE: several messages
@ 2014-11-11 6:37 ` Wu, Feng
0 siblings, 0 replies; 130+ messages in thread
From: Wu, Feng @ 2014-11-11 6:37 UTC (permalink / raw)
To: Jiang Liu, Thomas Gleixner
Cc: kvm-u79uwXL29TY76Z2rM5mHXA, gleb-DgEjT+Ai2ygdnm+yROfE0A,
x86-DgEjT+Ai2ygdnm+yROfE0A, LKML,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
mingo-H+wXaHxf7aLQT0dZR+AlfA, H. Peter Anvin,
pbonzini-H+wXaHxf7aLQT0dZR+AlfA, David Woodhouse
> -----Original Message-----
> From: Jiang Liu [mailto:jiang.liu-VuQAYsv1563Yd54FQh9/CA@public.gmane.org]
> Sent: Tuesday, November 11, 2014 10:29 AM
> To: Thomas Gleixner; Wu, Feng
> Cc: gleb-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org; pbonzini-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org; David Woodhouse;
> joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org; mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org; H. Peter Anvin; x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org;
> kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org; LKML
> Subject: Re: several messages
>
> On 2014/11/11 2:15, Thomas Gleixner wrote:
> > On Mon, 10 Nov 2014, Feng Wu wrote:
> >
> >> VT-d Posted-Interrupts is an enhancement to CPU side Posted-Interrupt.
> >> With VT-d Posted-Interrupts enabled, external interrupts from
> >> direct-assigned devices can be delivered to guests without VMM
> >> intervention when guest is running in non-root mode.
> >
> > Can you please talk to Jiang and synchronize your work with his
> > refactoring of the x86 interrupt handling subsystem.
> >
> > I want this stuff cleaned up first before we add new stuff to it.
> Hi Thomas,
> Just talked with Feng, we will focused on refactor first and
> then add posted interrupt support.
> Regards!
> Gerry
No problem!
Thanks,
Feng
>
> >
> > Thanks,
> >
> > tglx
> >
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCHv2] netfilter: add CHECKSUM target
@ 2010-07-11 15:06 Michael S. Tsirkin
2010-07-11 15:14 ` [PATCHv3] extensions: libxt_CHECKSUM extension Michael S. Tsirkin
0 siblings, 1 reply; 130+ messages in thread
From: Michael S. Tsirkin @ 2010-07-11 15:06 UTC (permalink / raw)
To: Patrick McHardy, Michael S. Tsirkin, David S. Miller,
Jan Engelhardt, Randy Dunlap, netfilter-devel, netfilter,
coreteam, linux-kernel, netdev, kvm, herbert
This adds a `CHECKSUM' target, which can be used in the iptables mangle
table.
You can use this target to compute and fill in the checksum in
a packet that lacks a checksum. This is particularly useful,
if you need to work around old applications such as dhcp clients,
that do not work well with checksum offloads, but don't want to
disable checksum offload in your device.
The problem happens in the field with virtualized applications.
For reference, see Red Hat bz 605555, as well as
http://www.spinics.net/lists/kvm/msg37660.html
Typical expected use (helps old dhclient binary running in a VM):
iptables -A POSTROUTING -t mangle -p udp --dport bootpc \
-j CHECKSUM --checksum-fill
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
Changes from v1:
moved from ipt to xt
get rid of any ipv4 dependencies
coding style tweaks
include/linux/netfilter/xt_CHECKSUM.h | 18 ++++++++
net/netfilter/Kconfig | 17 +++++++-
net/netfilter/Makefile | 1 +
net/netfilter/xt_CHECKSUM.c | 72 +++++++++++++++++++++++++++++++++
4 files changed, 107 insertions(+), 1 deletions(-)
create mode 100644 include/linux/netfilter/xt_CHECKSUM.h
create mode 100644 net/netfilter/xt_CHECKSUM.c
diff --git a/include/linux/netfilter/xt_CHECKSUM.h b/include/linux/netfilter/xt_CHECKSUM.h
new file mode 100644
index 0000000..56afe57
--- /dev/null
+++ b/include/linux/netfilter/xt_CHECKSUM.h
@@ -0,0 +1,18 @@
+/* Header file for iptables ipt_CHECKSUM target
+ *
+ * (C) 2002 by Harald Welte <laforge@gnumonks.org>
+ * (C) 2010 Red Hat Inc
+ * Author: Michael S. Tsirkin <mst@redhat.com>
+ *
+ * This software is distributed under GNU GPL v2, 1991
+*/
+#ifndef _IPT_CHECKSUM_TARGET_H
+#define _IPT_CHECKSUM_TARGET_H
+
+#define XT_CHECKSUM_OP_FILL 0x01 /* fill in checksum in IP header */
+
+struct xt_CHECKSUM_info {
+ u_int8_t operation; /* bitset of operations */
+};
+
+#endif /* _IPT_CHECKSUM_TARGET_H */
diff --git a/net/netfilter/Kconfig b/net/netfilter/Kconfig
index 8593a77..1cf4852 100644
--- a/net/netfilter/Kconfig
+++ b/net/netfilter/Kconfig
@@ -294,7 +294,7 @@ endif # NF_CONNTRACK
config NETFILTER_TPROXY
tristate "Transparent proxying support (EXPERIMENTAL)"
depends on EXPERIMENTAL
- depends on IP_NF_MANGLE
+ depends on IP_NF_MANGLE || IP6_NF_MANGLE
depends on NETFILTER_ADVANCED
help
This option enables transparent proxying support, that is,
@@ -347,6 +347,21 @@ config NETFILTER_XT_CONNMARK
comment "Xtables targets"
+config NETFILTER_XT_TARGET_CHECKSUM
+ tristate "CHECKSUM target support"
+ depends on NETFILTER_ADVANCED
+ ---help---
+ This option adds a `CHECKSUM' target, which can be used in the iptables mangle
+ table.
+
+ You can use this target to compute and fill in the checksum in
+ a packet that lacks a checksum. This is particularly useful,
+ if you need to work around old applications such as dhcp clients,
+ that do not work well with checksum offloads, but don't want to disable
+ checksum offload in your device.
+
+ To compile it as a module, choose M here. If unsure, say N.
+
config NETFILTER_XT_TARGET_CLASSIFY
tristate '"CLASSIFY" target support'
depends on NETFILTER_ADVANCED
diff --git a/net/netfilter/Makefile b/net/netfilter/Makefile
index 14e3a8f..8eb541d 100644
--- a/net/netfilter/Makefile
+++ b/net/netfilter/Makefile
@@ -45,6 +45,7 @@ obj-$(CONFIG_NETFILTER_XT_MARK) += xt_mark.o
obj-$(CONFIG_NETFILTER_XT_CONNMARK) += xt_connmark.o
# targets
+obj-$(CONFIG_NETFILTER_XT_TARGET_CHECKSUM) += xt_CHECKSUM.o
obj-$(CONFIG_NETFILTER_XT_TARGET_CLASSIFY) += xt_CLASSIFY.o
obj-$(CONFIG_NETFILTER_XT_TARGET_CONNSECMARK) += xt_CONNSECMARK.o
obj-$(CONFIG_NETFILTER_XT_TARGET_CT) += xt_CT.o
diff --git a/net/netfilter/xt_CHECKSUM.c b/net/netfilter/xt_CHECKSUM.c
new file mode 100644
index 0000000..0fee1a7
--- /dev/null
+++ b/net/netfilter/xt_CHECKSUM.c
@@ -0,0 +1,72 @@
+/* iptables module for the packet checksum mangling
+ *
+ * (C) 2002 by Harald Welte <laforge@netfilter.org>
+ * (C) 2010 Red Hat, Inc.
+ *
+ * Author: Michael S. Tsirkin <mst@redhat.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+#include <linux/in.h>
+#include <linux/module.h>
+#include <linux/skbuff.h>
+#include <linux/netdevice.h>
+
+#include <linux/netfilter/x_tables.h>
+#include <linux/netfilter/xt_CHECKSUM.h>
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Michael S. Tsirkin <mst@redhat.com>");
+MODULE_DESCRIPTION("Xtables: checksum modification");
+MODULE_ALIAS("ipt_CHECKSUM");
+MODULE_ALIAS("ip6t_CHECKSUM");
+
+static unsigned int
+checksum_tg(struct sk_buff *skb, const struct xt_action_param *par)
+{
+ if (skb->ip_summed == CHECKSUM_PARTIAL)
+ skb_checksum_help(skb);
+
+ return XT_CONTINUE;
+}
+
+static int checksum_tg_check(const struct xt_tgchk_param *par)
+{
+ const struct xt_CHECKSUM_info *einfo = par->targinfo;
+
+ if (einfo->operation & ~XT_CHECKSUM_OP_FILL) {
+ pr_info("unsupported CHECKSUM operation %x\n", einfo->operation);
+ return -EINVAL;
+ }
+ if (!einfo->operation) {
+ pr_info("no CHECKSUM operation enabled\n");
+ return -EINVAL;
+ }
+ return 0;
+}
+
+static struct xt_target checksum_tg_reg __read_mostly = {
+ .name = "CHECKSUM",
+ .family = NFPROTO_UNSPEC,
+ .target = checksum_tg,
+ .targetsize = sizeof(struct xt_CHECKSUM_info),
+ .table = "mangle",
+ .checkentry = checksum_tg_check,
+ .me = THIS_MODULE,
+};
+
+static int __init checksum_tg_init(void)
+{
+ return xt_register_target(&checksum_tg_reg);
+}
+
+static void __exit checksum_tg_exit(void)
+{
+ xt_unregister_target(&checksum_tg_reg);
+}
+
+module_init(checksum_tg_init);
+module_exit(checksum_tg_exit);
--
1.7.2.rc0.14.g41c1c
^ permalink raw reply related [flat|nested] 130+ messages in thread
* [PATCHv3] extensions: libxt_CHECKSUM extension
2010-07-11 15:06 [PATCHv2] netfilter: add CHECKSUM target Michael S. Tsirkin
@ 2010-07-11 15:14 ` Michael S. Tsirkin
2010-07-15 9:39 ` Patrick McHardy
0 siblings, 1 reply; 130+ messages in thread
From: Michael S. Tsirkin @ 2010-07-11 15:14 UTC (permalink / raw)
To: Patrick McHardy, David S. Miller, Jan Engelhardt, Randy Dunlap,
netfilter-devel, netfilter, coreteam, linux-kernel, netdev, kvm,
herbert
This adds a `CHECKSUM' target, which can be used in the iptables mangle
table.
You can use this target to compute and fill in the checksum in
a packet that lacks a checksum. This is particularly useful,
if you need to work around old applications such as dhcp clients,
that do not work well with checksum offloads, but don't want to disable
checksum offload in your device.
The problem happens in the field with virtualized applications.
For reference, see Red Hat bz 605555, as well as
http://www.spinics.net/lists/kvm/msg37660.html
Typical expected use (helps old dhclient binary running in a VM):
iptables -A POSTROUTING -t mangle -p udp --dport bootpc \
-j CHECKSUM --checksum-fill
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
Correction in the documentation. Sorry about the noise.
Changes from v2:
updated man file
Changes from v1:
switched from ipt to xt
extensions/libxt_CHECKSUM.c | 99 +++++++++++++++++++++++++++++++++++++++++
extensions/libxt_CHECKSUM.man | 8 +++
2 files changed, 107 insertions(+), 0 deletions(-)
create mode 100644 extensions/libxt_CHECKSUM.c
create mode 100644 extensions/libxt_CHECKSUM.man
diff --git a/extensions/libxt_CHECKSUM.c b/extensions/libxt_CHECKSUM.c
new file mode 100644
index 0000000..00fbd8f
--- /dev/null
+++ b/extensions/libxt_CHECKSUM.c
@@ -0,0 +1,99 @@
+/* Shared library add-on to xtables for CHECKSUM
+ *
+ * (C) 2002 by Harald Welte <laforge@gnumonks.org>
+ * (C) 2010 by Red Hat, Inc
+ * Author: Michael S. Tsirkin <mst@redhat.com>
+ *
+ * This program is distributed under the terms of GNU GPL v2, 1991
+ *
+ * libxt_CHECKSUM.c borrowed some bits from libipt_ECN.c
+ *
+ * $Id$
+ */
+#include <stdio.h>
+#include <string.h>
+#include <stdlib.h>
+#include <getopt.h>
+
+#include <xtables.h>
+#include <linux/netfilter/xt_CHECKSUM.h>
+
+static void CHECKSUM_help(void)
+{
+ printf(
+"CHECKSUM target options\n"
+" --checksum-fill Fill in packet checksum.\n");
+}
+
+static const struct option CHECKSUM_opts[] = {
+ { "checksum-fill", 0, NULL, 'F' },
+ { .name = NULL }
+};
+
+static int CHECKSUM_parse(int c, char **argv, int invert, unsigned int *flags,
+ const void *entry, struct xt_entry_target **target)
+{
+ struct xt_CHECKSUM_info *einfo
+ = (struct xt_CHECKSUM_info *)(*target)->data;
+
+ switch (c) {
+ case 'F':
+ if (*flags)
+ xtables_error(PARAMETER_PROBLEM,
+ "CHECKSUM target: Only use --checksum-fill ONCE!");
+ einfo->operation = XT_CHECKSUM_OP_FILL;
+ *flags |= XT_CHECKSUM_OP_FILL;
+ break;
+ default:
+ return 0;
+ }
+
+ return 1;
+}
+
+static void CHECKSUM_check(unsigned int flags)
+{
+ if (!flags)
+ xtables_error(PARAMETER_PROBLEM,
+ "CHECKSUM target: Parameter --checksum-fill is required");
+}
+
+static void CHECKSUM_print(const void *ip, const struct xt_entry_target *target,
+ int numeric)
+{
+ const struct xt_CHECKSUM_info *einfo =
+ (const struct xt_CHECKSUM_info *)target->data;
+
+ printf("CHECKSUM ");
+
+ if (einfo->operation & XT_CHECKSUM_OP_FILL)
+ printf("fill ");
+}
+
+static void CHECKSUM_save(const void *ip, const struct xt_entry_target *target)
+{
+ const struct xt_CHECKSUM_info *einfo =
+ (const struct xt_CHECKSUM_info *)target->data;
+
+ if (einfo->operation & XT_CHECKSUM_OP_FILL)
+ printf("--checksum-fill ");
+}
+
+static struct xtables_target checksum_tg_reg = {
+ .name = "CHECKSUM",
+ .version = XTABLES_VERSION,
+ .family = NFPROTO_UNSPEC,
+ .size = XT_ALIGN(sizeof(struct xt_CHECKSUM_info)),
+ .userspacesize = XT_ALIGN(sizeof(struct xt_CHECKSUM_info)),
+ .help = CHECKSUM_help,
+ .parse = CHECKSUM_parse,
+ .final_check = CHECKSUM_check,
+ .print = CHECKSUM_print,
+ .save = CHECKSUM_save,
+ .extra_opts = CHECKSUM_opts,
+};
+
+void _init(void)
+{
+ xtables_register_target(&checksum_tg_reg);
+}
diff --git a/extensions/libxt_CHECKSUM.man b/extensions/libxt_CHECKSUM.man
new file mode 100644
index 0000000..92ae700
--- /dev/null
+++ b/extensions/libxt_CHECKSUM.man
@@ -0,0 +1,8 @@
+This target allows to selectively work around broken/old applications.
+It can only be used in the mangle table.
+.TP
+\fB\-\-checksum\-fill\fP
+Compute and fill in the checksum in a packet that lacks a checksum.
+This is particularly useful, if you need to work around old applications
+such as dhcp clients, that do not work well with checksum offloads,
+but don't want to disable checksum offload in your device.
--
1.7.2.rc0.14.g41c1c
^ permalink raw reply related [flat|nested] 130+ messages in thread
* Re: [PATCHv3] extensions: libxt_CHECKSUM extension
2010-07-11 15:14 ` [PATCHv3] extensions: libxt_CHECKSUM extension Michael S. Tsirkin
@ 2010-07-15 9:39 ` Patrick McHardy
2010-07-15 10:17 ` several messages Jan Engelhardt
0 siblings, 1 reply; 130+ messages in thread
From: Patrick McHardy @ 2010-07-15 9:39 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: David S. Miller, Jan Engelhardt, Randy Dunlap, netfilter-devel,
netfilter, coreteam, linux-kernel, netdev, kvm, herbert
Am 11.07.2010 17:14, schrieb Michael S. Tsirkin:
> diff --git a/extensions/libxt_CHECKSUM.c b/extensions/libxt_CHECKSUM.c
> new file mode 100644
> index 0000000..00fbd8f
> --- /dev/null
> +++ b/extensions/libxt_CHECKSUM.c
> @@ -0,0 +1,99 @@
> +/* Shared library add-on to xtables for CHECKSUM
> + *
> + * (C) 2002 by Harald Welte <laforge@gnumonks.org>
> + * (C) 2010 by Red Hat, Inc
> + * Author: Michael S. Tsirkin <mst@redhat.com>
> + *
> + * This program is distributed under the terms of GNU GPL v2, 1991
> + *
> + * libxt_CHECKSUM.c borrowed some bits from libipt_ECN.c
> + *
> + * $Id$
Please no CVS IDs.
> + */
> +#include <stdio.h>
> +#include <string.h>
> +#include <stdlib.h>
> +#include <getopt.h>
> +
> +#include <xtables.h>
> +#include <linux/netfilter/xt_CHECKSUM.h>
> +
> +static void CHECKSUM_help(void)
> +{
> + printf(
> +"CHECKSUM target options\n"
> +" --checksum-fill Fill in packet checksum.\n");
> +}
> +
> +static const struct option CHECKSUM_opts[] = {
> + { "checksum-fill", 0, NULL, 'F' },
> + { .name = NULL }
> +};
> +
> +static int CHECKSUM_parse(int c, char **argv, int invert, unsigned int *flags,
> + const void *entry, struct xt_entry_target **target)
> +{
> + struct xt_CHECKSUM_info *einfo
> + = (struct xt_CHECKSUM_info *)(*target)->data;
> +
> + switch (c) {
> + case 'F':
> + if (*flags)
> + xtables_error(PARAMETER_PROBLEM,
> + "CHECKSUM target: Only use --checksum-fill ONCE!");
There is a helper function called xtables_param_act for checking double
arguments and printing a standarized error message.
> + einfo->operation = XT_CHECKSUM_OP_FILL;
> + *flags |= XT_CHECKSUM_OP_FILL;
> + break;
> + default:
> + return 0;
> + }
> +
> + return 1;
> +}
> +
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
2010-07-15 9:39 ` Patrick McHardy
@ 2010-07-15 10:17 ` Jan Engelhardt
0 siblings, 0 replies; 130+ messages in thread
From: Jan Engelhardt @ 2010-07-15 10:17 UTC (permalink / raw)
To: Patrick McHardy
Cc: Michael S. Tsirkin, David S. Miller, Randy Dunlap,
netfilter-devel, netfilter, coreteam, linux-kernel, netdev, kvm,
herbert
On Thursday 2010-07-15 11:36, Patrick McHardy wrote:
>> +struct xt_CHECKSUM_info {
>> + u_int8_t operation; /* bitset of operations */
>
>Please use __u8 in public header files.
>
>> +#include <linux/in.h>
>
>Do you really need in.h?
>
>> + * $Id$
>
>Please no CVS IDs.
>
>> + switch (c) {
>> + case 'F':
>> + if (*flags)
>> + xtables_error(PARAMETER_PROBLEM,
>> + "CHECKSUM target: Only use --checksum-fill ONCE!");
>
>There is a helper function called xtables_param_act for checking double
>arguments and printing a standarized error message.
I took care of these for Xt-a.
^ permalink raw reply [flat|nested] 130+ messages in thread
* Layla 3G does not recover from ACPI Suspend
@ 2009-09-06 14:16 Mark Hills
2009-09-08 19:32 ` Giuliano Pochini
0 siblings, 1 reply; 130+ messages in thread
From: Mark Hills @ 2009-09-06 14:16 UTC (permalink / raw)
To: alsa-devel
I have an Echo Layla 3G in my workstation. It works for audio, but does
not recover from ACPI suspend to RAM.
On recovery the system is fine, and the Layla exists in
/proc/asound/cards. But when the Layla is used it prints this message to
dmesg, multiple times:
wait_handshake(): Timeout waiting for DSP
Here are the relevant dmesg lines after awakening:
Echoaudio Echo3G 0000:03:03.0: restoring config space at offset 0xf (was 0x100, writing 0x104)
Echoaudio Echo3G 0000:03:03.0: restoring config space at offset 0x4 (was 0x0, writing 0xe7d00000)
Echoaudio Echo3G 0000:03:03.0: restoring config space at offset 0x3 (was 0x0, writing 0xc010)
Echoaudio Echo3G 0000:03:03.0: restoring config space at offset 0x1 (was 0x2800000, writing 0x2800112)
Echoaudio Echo3G 0000:03:03.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
I couldn't see anything loading the firmware. I thought unloading and
loading snd-echo3g after recovery would help. This shows the firmware
being loaded, but then no ALSA device is shown in /proc/asound/cards. On
loading snd-echo3g:
Echoaudio Echo3G 0000:03:03.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
Echoaudio Echo3G 0000:03:03.0: firmware: requesting ea/echo3g_dsp.fw
Echoaudio Echo3G 0000:03:03.0: firmware: requesting ea/loader_dsp.fw
Echoaudio Echo3G 0000:03:03.0: PCI INT A disabled
Echoaudio Echo3G: probe of 0000:03:03.0 failed with error -5
Is the firmware not being loaded when it should be? Or is there some extra
initialisation not being done (eg. init_hw() in echo3g_dsp.c)?
All other devices in the system recover fine, but as far as I'm aware no
other PCI devices require firmware. It's a Dell x86 system, kernel
2.6.31-rc7.
Thanks for any help,
--
Mark
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Layla 3G does not recover from ACPI Suspend
2009-09-06 14:16 Layla 3G does not recover from ACPI Suspend Mark Hills
@ 2009-09-08 19:32 ` Giuliano Pochini
2009-09-08 22:56 ` several messages Mark Hills
0 siblings, 1 reply; 130+ messages in thread
From: Giuliano Pochini @ 2009-09-08 19:32 UTC (permalink / raw)
To: Mark Hills; +Cc: alsa-devel
On Sun, 6 Sep 2009 15:16:57 +0100 (BST)
Mark Hills <mark@pogo.org.uk> wrote:
> I have an Echo Layla 3G in my workstation. It works for audio, but does
> not recover from ACPI suspend to RAM.
I does not recover because there is not suspend/resume support. I wrote
almost complete support a lot of time ago which wasn't merged due to two
unsolved issues. The resurrection procedure (actually it is a reinit from
scratch) was very unreliable on my Gina24 for unknown reasons and there
was an atomicity issue in the rawmidi interface.
I can manage to provide you a patch for testing in a few days.
--
Giuliano.
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
2009-09-08 19:32 ` Giuliano Pochini
@ 2009-09-08 22:56 ` Mark Hills
0 siblings, 0 replies; 130+ messages in thread
From: Mark Hills @ 2009-09-08 22:56 UTC (permalink / raw)
To: Giuliano Pochini; +Cc: Takashi Iwai, alsa-devel
On Tue, 8 Sep 2009, Giuliano Pochini wrote:
> On Sun, 6 Sep 2009 15:16:57 +0100 (BST)
> Mark Hills <mark@pogo.org.uk> wrote:
>
>> I have an Echo Layla 3G in my workstation. It works for audio, but does
>> not recover from ACPI suspend to RAM.
>
> I does not recover because there is not suspend/resume support. I wrote
> almost complete support a lot of time ago which wasn't merged due to two
> unsolved issues. The resurrection procedure (actually it is a reinit from
> scratch) was very unreliable on my Gina24 for unknown reasons and there
> was an atomicity issue in the rawmidi interface.
> I can manage to provide you a patch for testing in a few days.
Thanks Giuliano and Takashi for the replies.
The reason for my quietness is I decided loading/unloading the module was
a hack so I followed Takashi's documentation, aiming to implement some
kind of suspend/resume.
However didn't have a great deal of luck; it's made especially hard with
not having a separate serial console or way of viewing debug messages when
the machine locks. It seemed that the amount of de-initialisation affects
the ability to reinitialise the Layla 3G card from scratch. Then I ran out
of time.
It would be great to see the patch, I'd be very happy to help with
testing. Thanks for your work on this.
--
Mark
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH] libxtables: Introduce global params structuring
@ 2009-02-09 20:57 jamal
2009-02-09 21:04 ` several messages Jan Engelhardt
0 siblings, 1 reply; 130+ messages in thread
From: jamal @ 2009-02-09 20:57 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Jan Engelhardt, Pablo Neira Ayuso, netfilter-devel
[-- Attachment #1: Type: text/plain, Size: 41 bytes --]
Here's the basic change.
cheers,
jamal
[-- Attachment #2: iptv2-0 --]
[-- Type: text/plain, Size: 2246 bytes --]
commit bc259a1516e63a38496d568dff2d6135b925d968
Author: Jamal Hadi Salim <hadi@cyberus.ca>
Date: Mon Feb 9 15:20:18 2009 -0500
introduce a new struct,xtables_globals, so as to
localize the globals used and help in symbol renames.
The applications must invoke xtables_set_params() before starting
to use any iptables APIs.
xtables_set_params() is intended to free xtables from depending
(as it does right now) on existence of such externally definitions
(from iptables/iptables6 etc). At the moment, xtables wont even
compile without presence of at least one of {iptables/iptables6 etc}
Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca>
diff --git a/include/xtables.h.in b/include/xtables.h.in
index 02750fb..61dbc76 100644
--- a/include/xtables.h.in
+++ b/include/xtables.h.in
@@ -33,6 +33,14 @@
struct in_addr;
+struct xtables_globals
+{
+ unsigned int option_offset;
+ char *program_version;
+ char *program_name;
+ struct option *opts;
+};
+
/* Include file for additions: new matches and targets. */
struct xtables_match
{
@@ -195,6 +203,7 @@ extern void *xtables_malloc(size_t);
extern int xtables_insmod(const char *, const char *, bool);
extern int xtables_load_ko(const char *, bool);
+int xtables_set_params(struct xtables_globals *xtp);
extern struct xtables_match *xtables_find_match(const char *name,
enum xtables_tryload, struct xtables_rule_match **match);
diff --git a/xtables.c b/xtables.c
index 6c95475..aad5e53 100644
--- a/xtables.c
+++ b/xtables.c
@@ -46,6 +46,28 @@
#define PROC_SYS_MODPROBE "/proc/sys/kernel/modprobe"
#endif
+struct xtables_globals *xt_params;
+/**
+ * xtables_set_params - set the global parameters used by xtables
+ * @xtp: input xtables_globals structure
+ *
+ * The app is expected to pass a valid xtables_globals data-filled
+ * with proper values
+ * @xtp cannot be NULL
+ *
+ * Returns -1 on failure to set and 0 on success
+ */
+int xtables_set_params(struct xtables_globals *xtp)
+{
+ if (!xtp) {
+ fprintf(stderr, "%s: Illegal global params\n",__func__);
+ return -1;
+ }
+
+ xt_params = xtp;
+ return 0;
+}
+
/**
* xtables_afinfo - protocol family dependent information
* @kmod: kernel module basename (e.g. "ip_tables")
^ permalink raw reply related [flat|nested] 130+ messages in thread
* Re: several messages
2009-02-09 20:57 [PATCH] libxtables: Introduce global params structuring jamal
@ 2009-02-09 21:04 ` Jan Engelhardt
2009-02-09 21:27 ` jamal
0 siblings, 1 reply; 130+ messages in thread
From: Jan Engelhardt @ 2009-02-09 21:04 UTC (permalink / raw)
To: jamal; +Cc: Patrick McHardy, Pablo Neira Ayuso, netfilter-devel
On Monday 2009-02-09 21:45, jamal wrote:
>
>Ok, I just synced with latest git. I will send you a few patches first.
>My path to resolving tc/ipt is to start with being able to take a basic
>useless program like:
>
>----------
>#include <xtables.h>
>int main(int argc, char **argv) {
>
> return 0;
>}
>--------
>
>then compile and link with "gcc useless.c -lxtables -ldl"
>
>As it is right now i have to define in the minimal exit_error()
I do not think a library should call exit() and cause the main program
to terminate; to this end it might be best to add a
void (*exit_error)(..
function pointer to the xtables_global struct you are proposing.
>
>Here's the basic change.
If you could convert iptables.c and friends to also make use of this,
that'd be great.
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
2009-02-09 21:04 ` several messages Jan Engelhardt
@ 2009-02-09 21:27 ` jamal
2009-02-09 21:44 ` Jan Engelhardt
0 siblings, 1 reply; 130+ messages in thread
From: jamal @ 2009-02-09 21:27 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Patrick McHardy, Pablo Neira Ayuso, netfilter-devel
On Mon, 2009-02-09 at 22:04 +0100, Jan Engelhardt wrote:
>
> I do not think a library should call exit() and cause the main program
> to terminate;
> to this end it might be best to add a
>
> void (*exit_error)(..
>
> function pointer to the xtables_global struct you are proposing.
>
>
Thanks for the suggestion - it sounds reasonable.
Note, however, grep says there are about 700 references to exit_error()
- so my intent of moving it into xtables.c is for usability more than
anything.
> If you could convert iptables.c and friends to also make use of this,
> that'd be great.
There are only 3 definitions as far as i can see. If i can convert those
to use that global struct then I should be able to compile that basic
program.
cheers,
jamal
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
2009-02-09 21:27 ` jamal
@ 2009-02-09 21:44 ` Jan Engelhardt
0 siblings, 0 replies; 130+ messages in thread
From: Jan Engelhardt @ 2009-02-09 21:44 UTC (permalink / raw)
To: jamal; +Cc: Patrick McHardy, Pablo Neira Ayuso, netfilter-devel
On Monday 2009-02-09 22:27, jamal wrote:
>On Mon, 2009-02-09 at 22:04 +0100, Jan Engelhardt wrote:
>>
>> I do not think a library should call exit() and cause the main program
>> to terminate;
>> to this end it might be best to add a
>>
>> void (*exit_error)(..
>>
>> function pointer to the xtables_global struct you are proposing.
>
>Thanks for the suggestion - it sounds reasonable.
>Note, however, grep says there are about 700 references to exit_error()
>- so my intent of moving it into xtables.c is for usability more than
>anything.
Hm you are right; much of the code assumes that exit_error()
never returns. We need to stick to that for the time being.
>> If you could convert iptables.c and friends to also make use of this,
>> that'd be great.
>
>There are only 3 definitions as far as i can see. If i can convert those
>to use that global struct then I should be able to compile that basic
>program.
Yep.
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH 0/1] HID: hid_apple is not used for apple alu wireless keyboards
@ 2008-11-26 14:33 Jan Scholz
2008-11-26 14:33 ` [PATCH 1/1] HID: Apple alu wireless keyboards are bluetooth devices Jan Scholz
0 siblings, 1 reply; 130+ messages in thread
From: Jan Scholz @ 2008-11-26 14:33 UTC (permalink / raw)
To: jkosina; +Cc: jirislaby, linux-kernel, Jan Scholz
Hi Jiri,
While parsing 'hid_blacklist' in hid-core.c my apple alu wireless
keyboard is not found. This happens because in the blacklist it
is declared with HID_USB_DEVICE although the keyboards are really
bluetooth devices. The same holds for 'apple_devices' list in
hid-apple.c
This patch fixes it by changing HID_USB_DEVICE to
HID_BLUETOOTH_DEVICE in those two lists.
Jan Scholz (1):
HID: Apple alu wireless keyboards are bluetooth devices
drivers/hid/hid-apple.c | 6 +++---
drivers/hid/hid-core.c | 6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH 1/1] HID: Apple alu wireless keyboards are bluetooth devices
2008-11-26 14:33 [PATCH 0/1] HID: hid_apple is not used for apple alu wireless keyboards Jan Scholz
@ 2008-11-26 14:33 ` Jan Scholz
2008-11-26 14:54 ` Jiri Kosina
0 siblings, 1 reply; 130+ messages in thread
From: Jan Scholz @ 2008-11-26 14:33 UTC (permalink / raw)
To: jkosina; +Cc: jirislaby, linux-kernel, Jan Scholz
Changed HID_USB_DEVICE to HID_BLUETOOTH_DEVICE for the apple alu
wireless keyboards
Signed-off-by: Jan Scholz <Scholz@fias.uni-frankfurt.de>
---
drivers/hid/hid-apple.c | 6 +++---
drivers/hid/hid-core.c | 6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/hid/hid-apple.c b/drivers/hid/hid-apple.c
index 9b97795..aa28aed 100644
--- a/drivers/hid/hid-apple.c
+++ b/drivers/hid/hid-apple.c
@@ -400,12 +400,12 @@ static const struct hid_device_id apple_devices[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_HF_JIS),
.driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN |
APPLE_RDESC_JIS },
- { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_ANSI),
+ { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_ANSI),
.driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN },
- { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_ISO),
+ { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_ISO),
.driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN |
APPLE_ISO_KEYBOARD },
- { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_JIS),
+ { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_JIS),
.driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING_ANSI),
.driver_data = APPLE_HAS_FN },
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 147ec59..98c7e2d 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1241,9 +1241,9 @@ static const struct hid_device_id hid_blacklist[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_HF_ANSI) },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_HF_ISO) },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_HF_JIS) },
- { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_ANSI) },
- { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_ISO) },
- { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_JIS) },
+ { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_ANSI) },
+ { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_ISO) },
+ { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_JIS) },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING_ANSI) },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING_ISO) },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING_JIS) },
--
1.6.0.4
^ permalink raw reply related [flat|nested] 130+ messages in thread
* Re: [PATCH 1/1] HID: Apple alu wireless keyboards are bluetooth devices
2008-11-26 14:33 ` [PATCH 1/1] HID: Apple alu wireless keyboards are bluetooth devices Jan Scholz
@ 2008-11-26 14:54 ` Jiri Kosina
2008-11-26 15:17 ` Jan Scholz
0 siblings, 1 reply; 130+ messages in thread
From: Jiri Kosina @ 2008-11-26 14:54 UTC (permalink / raw)
To: Jan Scholz; +Cc: jirislaby, linux-kernel
On Wed, 26 Nov 2008, Jan Scholz wrote:
> Changed HID_USB_DEVICE to HID_BLUETOOTH_DEVICE for the apple alu
> wireless keyboards
> Signed-off-by: Jan Scholz <Scholz@fias.uni-frankfurt.de>
> ---
> drivers/hid/hid-apple.c | 6 +++---
> drivers/hid/hid-core.c | 6 +++---
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/hid/hid-apple.c b/drivers/hid/hid-apple.c
> index 9b97795..aa28aed 100644
> --- a/drivers/hid/hid-apple.c
> +++ b/drivers/hid/hid-apple.c
> @@ -400,12 +400,12 @@ static const struct hid_device_id apple_devices[] = {
> { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_HF_JIS),
> .driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN |
> APPLE_RDESC_JIS },
> - { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_ANSI),
> + { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_ANSI),
> .driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN },
> - { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_ISO),
> + { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_ISO),
> .driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN |
> APPLE_ISO_KEYBOARD },
> - { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_JIS),
> + { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_JIS),
> .driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN },
> { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING_ANSI),
> .driver_data = APPLE_HAS_FN },
Hi Jan,
shouldn't we rather have both USB and Bluetooth variants?
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: [PATCH 1/1] HID: Apple alu wireless keyboards are bluetooth devices
2008-11-26 14:54 ` Jiri Kosina
@ 2008-11-26 15:17 ` Jan Scholz
2008-11-26 15:33 ` Jiri Kosina
0 siblings, 1 reply; 130+ messages in thread
From: Jan Scholz @ 2008-11-26 15:17 UTC (permalink / raw)
To: Jiri Kosina; +Cc: Jan Scholz, jirislaby, linux-kernel
Jiri Kosina <jkosina@suse.cz> writes:
> On Wed, 26 Nov 2008, Jan Scholz wrote:
>
>> Changed HID_USB_DEVICE to HID_BLUETOOTH_DEVICE for the apple alu
>> wireless keyboards
>> Signed-off-by: Jan Scholz <Scholz@fias.uni-frankfurt.de>
>> ---
>> drivers/hid/hid-apple.c | 6 +++---
>> drivers/hid/hid-core.c | 6 +++---
>> 2 files changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/hid/hid-apple.c b/drivers/hid/hid-apple.c
>> index 9b97795..aa28aed 100644
>> --- a/drivers/hid/hid-apple.c
>> +++ b/drivers/hid/hid-apple.c
>> @@ -400,12 +400,12 @@ static const struct hid_device_id apple_devices[] = {
>> { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_HF_JIS),
>> .driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN |
>> APPLE_RDESC_JIS },
>> - { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_ANSI),
>> + { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_ANSI),
>> .driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN },
>> - { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_ISO),
>> + { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_ISO),
>> .driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN |
>> APPLE_ISO_KEYBOARD },
>> - { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_JIS),
>> + { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_JIS),
>> .driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN },
>> { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING_ANSI),
>> .driver_data = APPLE_HAS_FN },
>
> Hi Jan,
>
> shouldn't we rather have both USB and Bluetooth variants?
>
> Thanks,
Hi Jiri,
Hm, I thought the USB_DEVICE_ID_APPLE_ALU_{ANSI,ISO,JIS} were apples usb
aluminum keyboards (standard desktop size), while the
USB_DEVICE_ID_APPLE_ALU_WIRELESS_{ANSI,ISO,JIS} ones were the aluminum
bluetooth keyboards (notebook sized, no numeric keypad, etc).
The one I own is a USB_DEVICE_ID_APPLE_ALU_WIRELESS_ISO, german layout,
with bluetooth, unfortunately I don't have access to a usb variant.
Jan
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: [PATCH 1/1] HID: Apple alu wireless keyboards are bluetooth devices
2008-11-26 15:17 ` Jan Scholz
@ 2008-11-26 15:33 ` Jiri Kosina
2008-11-26 21:06 ` Tobias Müller
0 siblings, 1 reply; 130+ messages in thread
From: Jiri Kosina @ 2008-11-26 15:33 UTC (permalink / raw)
To: Jan Scholz, Tobias Mueller; +Cc: jirislaby, linux-kernel
On Wed, 26 Nov 2008, Jan Scholz wrote:
> Jiri Kosina <jkosina@suse.cz> writes:
>
> > On Wed, 26 Nov 2008, Jan Scholz wrote:
> >
> >> Changed HID_USB_DEVICE to HID_BLUETOOTH_DEVICE for the apple alu
> >> wireless keyboards
> >> Signed-off-by: Jan Scholz <Scholz@fias.uni-frankfurt.de>
> >> ---
> >> drivers/hid/hid-apple.c | 6 +++---
> >> drivers/hid/hid-core.c | 6 +++---
> >> 2 files changed, 6 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/drivers/hid/hid-apple.c b/drivers/hid/hid-apple.c
> >> index 9b97795..aa28aed 100644
> >> --- a/drivers/hid/hid-apple.c
> >> +++ b/drivers/hid/hid-apple.c
> >> @@ -400,12 +400,12 @@ static const struct hid_device_id apple_devices[] = {
> >> { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_HF_JIS),
> >> .driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN |
> >> APPLE_RDESC_JIS },
> >> - { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_ANSI),
> >> + { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_ANSI),
> >> .driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN },
> >> - { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_ISO),
> >> + { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_ISO),
> >> .driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN |
> >> APPLE_ISO_KEYBOARD },
> >> - { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_JIS),
> >> + { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_JIS),
> >> .driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN },
> >> { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING_ANSI),
> >> .driver_data = APPLE_HAS_FN },
> >
> > Hi Jan,
> >
> > shouldn't we rather have both USB and Bluetooth variants?
> >
> > Thanks,
>
> Hi Jiri,
>
> Hm, I thought the USB_DEVICE_ID_APPLE_ALU_{ANSI,ISO,JIS} were apples usb
> aluminum keyboards (standard desktop size), while the
> USB_DEVICE_ID_APPLE_ALU_WIRELESS_{ANSI,ISO,JIS} ones were the aluminum
> bluetooth keyboards (notebook sized, no numeric keypad, etc).
>
> The one I own is a USB_DEVICE_ID_APPLE_ALU_WIRELESS_ISO, german layout,
> with bluetooth, unfortunately I don't have access to a usb variant.
Tobias Mueller added these device IDs, so persumably he has tested it and
could provide some insight. I don't have the hardware myself, so I have no
idea whether there are only Bluetooht variants, or even USB are available.
Tobias?
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: [PATCH 1/1] HID: Apple alu wireless keyboards are bluetooth devices
2008-11-26 15:33 ` Jiri Kosina
@ 2008-11-26 21:06 ` Tobias Müller
2008-11-27 0:57 ` several messages Jiri Kosina
0 siblings, 1 reply; 130+ messages in thread
From: Tobias Müller @ 2008-11-26 21:06 UTC (permalink / raw)
To: Jiri Kosina; +Cc: Jan Scholz, Tobias Mueller, jirislaby, linux-kernel
>> The one I own is a USB_DEVICE_ID_APPLE_ALU_WIRELESS_ISO, german layout,
>> with bluetooth, unfortunately I don't have access to a usb variant.
>
> Tobias Mueller added these device IDs, so persumably he has tested it and
> could provide some insight. I don't have the hardware myself, so I have no
> idea whether there are only Bluetooht variants, or even USB are available.
>
> Tobias?
I own the USB variant and these are the right id for that. The wireless
IDs were from another patch I merged together with mine. I don't have a
wireless version.
Regards
Tobias
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
2008-11-26 21:06 ` Tobias Müller
@ 2008-11-27 0:57 ` Jiri Kosina
0 siblings, 0 replies; 130+ messages in thread
From: Jiri Kosina @ 2008-11-27 0:57 UTC (permalink / raw)
To: J.R. Mauro, Tobias Müller; +Cc: Jan Scholz, jirislaby, linux-kernel
[-- Attachment #1: Type: TEXT/PLAIN, Size: 406 bytes --]
On Wed, 26 Nov 2008, J.R. Mauro wrote:
> There is one bluetooth model and one USB model.
On Wed, 26 Nov 2008, Tobias Müller wrote:
> I own the USB variant and these are the right id for that. The wireless
> IDs were from another patch I merged together with mine. I don't have a
> wireless version.
OK, so therefore you confirm that Jan's patch is OK, right?
Thanks a lot,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH 1/2] HID: add hid_type
@ 2008-10-19 14:15 Jiri Slaby
2008-10-19 14:15 ` [PATCH 2/2] HID: fix appletouch regression Jiri Slaby
0 siblings, 1 reply; 130+ messages in thread
From: Jiri Slaby @ 2008-10-19 14:15 UTC (permalink / raw)
To: jkosina
Cc: linux-input, linux-kernel, Steven Noonan, Justin Mattock,
Sven Anders, Marcel Holtmann, linux-bluetooth, Jiri Slaby
Add type to the hid structure to distinguish to which device type
(mouse/kbd) we are talking to. Needed for per device type ignore
list support.
Note: this patch leaves the type as unknown for bluetooth devices,
there is not support for this in the hidp code.
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
---
drivers/hid/usbhid/hid-core.c | 8 ++++++++
include/linux/hid.h | 7 +++++++
2 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
index 1d3b8a3..20617d8 100644
--- a/drivers/hid/usbhid/hid-core.c
+++ b/drivers/hid/usbhid/hid-core.c
@@ -972,6 +972,14 @@ static int hid_probe(struct usb_interface *intf, const struct usb_device_id *id)
hid->vendor = le16_to_cpu(dev->descriptor.idVendor);
hid->product = le16_to_cpu(dev->descriptor.idProduct);
hid->name[0] = 0;
+ switch (intf->cur_altsetting->desc.bInterfaceProtocol) {
+ case USB_INTERFACE_PROTOCOL_KEYBOARD:
+ hid->type = HID_TYPE_KEYBOARD;
+ break;
+ case USB_INTERFACE_PROTOCOL_MOUSE:
+ hid->type = HID_TYPE_MOUSE;
+ break;
+ }
if (dev->manufacturer)
strlcpy(hid->name, dev->manufacturer, sizeof(hid->name));
diff --git a/include/linux/hid.h b/include/linux/hid.h
index f13bca2..36a3953 100644
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -417,6 +417,12 @@ struct hid_input {
struct input_dev *input;
};
+enum hid_type {
+ HID_TYPE_UNKNOWN = 0,
+ HID_TYPE_MOUSE,
+ HID_TYPE_KEYBOARD
+};
+
struct hid_driver;
struct hid_ll_driver;
@@ -431,6 +437,7 @@ struct hid_device { /* device report descriptor */
__u32 vendor; /* Vendor ID */
__u32 product; /* Product ID */
__u32 version; /* HID version */
+ enum hid_type type; /* device type (mouse, kbd, ...) */
unsigned country; /* HID country */
struct hid_report_enum report_enum[HID_REPORT_TYPES];
--
1.6.0.2
^ permalink raw reply related [flat|nested] 130+ messages in thread
* [PATCH 2/2] HID: fix appletouch regression
2008-10-19 14:15 [PATCH 1/2] HID: add hid_type Jiri Slaby
@ 2008-10-19 14:15 ` Jiri Slaby
2008-10-19 19:40 ` several messages Jiri Kosina
0 siblings, 1 reply; 130+ messages in thread
From: Jiri Slaby @ 2008-10-19 14:15 UTC (permalink / raw)
To: jkosina
Cc: linux-input, linux-kernel, Steven Noonan, Justin Mattock,
Sven Anders, Marcel Holtmann, linux-bluetooth, Jiri Slaby
The appletouch mouse devices are grabbed by the hid bus and not
released even if apple driver says ENODEV (as expected).
Move the ignoration one level upper to deny the hid layer to grab
the device and return error to the usb hid which, as a result,
releases the device.
Otherwise input/mouse/appletouch and others needn't be attached.
Reported-by: Justin Mattock <justinmattock@gmail.com>
Reported-by: Steven Noonan <steven@uplinklabs.net>
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
---
drivers/hid/hid-apple.c | 63 ++++++++++++++++------------------------------
drivers/hid/hid-core.c | 33 ++++++++++++++++++++++++
2 files changed, 55 insertions(+), 41 deletions(-)
diff --git a/drivers/hid/hid-apple.c b/drivers/hid/hid-apple.c
index fd7f896..c6ab4ba 100644
--- a/drivers/hid/hid-apple.c
+++ b/drivers/hid/hid-apple.c
@@ -312,13 +312,6 @@ static int apple_probe(struct hid_device *hdev,
unsigned int connect_mask = HID_CONNECT_DEFAULT;
int ret;
- /* return something else or move to hid layer? device will reside
- allocated */
- if (id->bus == BUS_USB && (quirks & APPLE_IGNORE_MOUSE) &&
- to_usb_interface(hdev->dev.parent)->cur_altsetting->
- desc.bInterfaceProtocol == USB_INTERFACE_PROTOCOL_MOUSE)
- return -ENODEV;
-
asc = kzalloc(sizeof(*asc), GFP_KERNEL);
if (asc == NULL) {
dev_err(&hdev->dev, "can't alloc apple descriptor\n");
@@ -367,38 +360,32 @@ static const struct hid_device_id apple_devices[] = {
.driver_data = APPLE_MIGHTYMOUSE | APPLE_INVERT_HWHEEL },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_FOUNTAIN_ANSI),
- .driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN |
- APPLE_IGNORE_MOUSE },
+ .driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_FOUNTAIN_ISO),
- .driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN |
- APPLE_IGNORE_MOUSE },
+ .driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER_ANSI),
- .driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN |
- APPLE_IGNORE_MOUSE },
+ .driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER_ISO),
.driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN |
- APPLE_IGNORE_MOUSE | APPLE_ISO_KEYBOARD },
+ APPLE_ISO_KEYBOARD },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER_JIS),
- .driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN |
- APPLE_IGNORE_MOUSE },
+ .driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER3_ANSI),
- .driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN |
- APPLE_IGNORE_MOUSE },
+ .driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER3_ISO),
.driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN |
- APPLE_IGNORE_MOUSE | APPLE_ISO_KEYBOARD },
+ APPLE_ISO_KEYBOARD },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER3_JIS),
.driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN |
- APPLE_IGNORE_MOUSE | APPLE_RDESC_JIS },
+ APPLE_RDESC_JIS },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_ANSI),
- .driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN |
- APPLE_IGNORE_MOUSE },
+ .driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_ISO),
.driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN |
- APPLE_IGNORE_MOUSE | APPLE_ISO_KEYBOARD },
+ APPLE_ISO_KEYBOARD },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_JIS),
.driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN |
- APPLE_IGNORE_MOUSE | APPLE_RDESC_JIS},
+ APPLE_RDESC_JIS },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_ANSI),
.driver_data = APPLE_HAS_FN },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_ISO),
@@ -406,14 +393,12 @@ static const struct hid_device_id apple_devices[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_JIS),
.driver_data = APPLE_HAS_FN },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_HF_ANSI),
- .driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN |
- APPLE_IGNORE_MOUSE },
+ .driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_HF_ISO),
- .driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN |
- APPLE_IGNORE_MOUSE },
+ .driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_HF_JIS),
.driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN |
- APPLE_IGNORE_MOUSE | APPLE_RDESC_JIS },
+ APPLE_RDESC_JIS },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_ANSI),
.driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_ISO),
@@ -422,25 +407,21 @@ static const struct hid_device_id apple_devices[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_JIS),
.driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING_ANSI),
- .driver_data = APPLE_HAS_FN | APPLE_IGNORE_MOUSE },
+ .driver_data = APPLE_HAS_FN },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING_ISO),
- .driver_data = APPLE_HAS_FN | APPLE_ISO_KEYBOARD |
- APPLE_IGNORE_MOUSE },
+ .driver_data = APPLE_HAS_FN | APPLE_ISO_KEYBOARD },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING_JIS),
- .driver_data = APPLE_HAS_FN | APPLE_IGNORE_MOUSE | APPLE_RDESC_JIS },
+ .driver_data = APPLE_HAS_FN | APPLE_RDESC_JIS },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING2_ANSI),
- .driver_data = APPLE_HAS_FN | APPLE_IGNORE_MOUSE },
+ .driver_data = APPLE_HAS_FN },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING2_ISO),
- .driver_data = APPLE_HAS_FN | APPLE_ISO_KEYBOARD |
- APPLE_IGNORE_MOUSE },
+ .driver_data = APPLE_HAS_FN | APPLE_ISO_KEYBOARD },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING2_JIS),
- .driver_data = APPLE_HAS_FN | APPLE_IGNORE_MOUSE | APPLE_RDESC_JIS },
+ .driver_data = APPLE_HAS_FN | APPLE_RDESC_JIS },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_FOUNTAIN_TP_ONLY),
- .driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN |
- APPLE_IGNORE_MOUSE },
+ .driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER1_TP_ONLY),
- .driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN |
- APPLE_IGNORE_MOUSE },
+ .driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN },
/* Apple wireless Mighty Mouse */
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, 0x030c),
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 8a7d9db..90bdc6f 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1539,6 +1539,35 @@ static const struct hid_device_id hid_ignore_list[] = {
{ }
};
+/**
+ * hid_mouse_ignore_list - mouse devices which must not be held by the hid layer
+ */
+static const struct hid_device_id hid_mouse_ignore_list[] = {
+ { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_FOUNTAIN_ANSI) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_FOUNTAIN_ISO) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER_ANSI) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER_ISO) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER_JIS) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER3_ANSI) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER3_ISO) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER3_JIS) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_ANSI) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_ISO) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_JIS) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_HF_ANSI) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_HF_ISO) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_HF_JIS) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING_ANSI) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING_ISO) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING_JIS) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING2_ANSI) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING2_ISO) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING2_JIS) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_FOUNTAIN_TP_ONLY) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER1_TP_ONLY) },
+ { }
+};
+
static bool hid_ignore(struct hid_device *hdev)
{
switch (hdev->vendor) {
@@ -1555,6 +1584,10 @@ static bool hid_ignore(struct hid_device *hdev)
break;
}
+ if (hdev->type == HID_TYPE_MOUSE &&
+ hid_match_id(hdev, hid_mouse_ignore_list))
+ return true;
+
return !!hid_match_id(hdev, hid_ignore_list);
}
--
1.6.0.2
^ permalink raw reply related [flat|nested] 130+ messages in thread
* Re: several messages
2008-10-19 14:15 ` [PATCH 2/2] HID: fix appletouch regression Jiri Slaby
@ 2008-10-19 19:40 ` Jiri Kosina
2008-10-19 20:06 ` Justin Mattock
2008-10-19 22:09 ` Jiri Slaby
0 siblings, 2 replies; 130+ messages in thread
From: Jiri Kosina @ 2008-10-19 19:40 UTC (permalink / raw)
To: Jiri Slaby
Cc: linux-input, linux-kernel, Steven Noonan, Justin Mattock,
Sven Anders, Marcel Holtmann, linux-bluetooth
On Sun, 19 Oct 2008, Jiri Slaby wrote:
> +enum hid_type {
> + HID_TYPE_UNKNOWN = 0,
> + HID_TYPE_MOUSE,
> + HID_TYPE_KEYBOARD
> +};
> +
Do we really need the HID_TYPE_KEYBOARD at all? It's not used anywhere in
the code. I'd propose to add it when it is actually needed. I.e. have the
enum contain something like HID_TYPE_MOUSE HID_TYPE_OTHER for now, and add
whatever will become necessary in the future, what do you think?
On Sun, 19 Oct 2008, Jiri Slaby wrote:
> +/**
> + * hid_mouse_ignore_list - mouse devices which must not be held by the hid layer
> + */
I think a more descriptive comment would be appropriate here. It might not
be obvious on the first sight why this needs to be done separately from
the generic hid_blacklist. I.e. something like
/**
* There are composite devices for which we want to ignore only a certain
* interface. This is a list of devices for which only the mouse interface
* will be ignored.
*/
maybe?
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
@ 2008-10-19 20:06 ` Justin Mattock
0 siblings, 0 replies; 130+ messages in thread
From: Justin Mattock @ 2008-10-19 20:06 UTC (permalink / raw)
To: Jiri Kosina
Cc: Jiri Slaby, linux-input, linux-kernel, Steven Noonan,
Sven Anders, Marcel Holtmann, linux-bluetooth
On Sun, Oct 19, 2008 at 12:40 PM, Jiri Kosina <jkosina@suse.cz> wrote:
> On Sun, 19 Oct 2008, Jiri Slaby wrote:
>
>> +enum hid_type {
>> + HID_TYPE_UNKNOWN = 0,
>> + HID_TYPE_MOUSE,
>> + HID_TYPE_KEYBOARD
>> +};
>> +
>
> Do we really need the HID_TYPE_KEYBOARD at all? It's not used anywhere in
> the code. I'd propose to add it when it is actually needed. I.e. have the
> enum contain something like HID_TYPE_MOUSE HID_TYPE_OTHER for now, and add
> whatever will become necessary in the future, what do you think?
>
>
> On Sun, 19 Oct 2008, Jiri Slaby wrote:
>
>> +/**
>> + * hid_mouse_ignore_list - mouse devices which must not be held by the hid layer
>> + */
>
> I think a more descriptive comment would be appropriate here. It might not
> be obvious on the first sight why this needs to be done separately from
> the generic hid_blacklist. I.e. something like
>
> /**
> * There are composite devices for which we want to ignore only a certain
> * interface. This is a list of devices for which only the mouse interface
> * will be ignored.
> */
>
> maybe?
>
> Thanks,
>
> --
> Jiri Kosina
> SUSE Labs
>
I can agree with that, whats the point having something
there if it not being used,(just eating up precious space);
--
Justin P. Mattock
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
@ 2008-10-19 20:06 ` Justin Mattock
0 siblings, 0 replies; 130+ messages in thread
From: Justin Mattock @ 2008-10-19 20:06 UTC (permalink / raw)
To: Jiri Kosina
Cc: Jiri Slaby, linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Steven Noonan, Sven Anders,
Marcel Holtmann, linux-bluetooth-u79uwXL29TY76Z2rM5mHXA
On Sun, Oct 19, 2008 at 12:40 PM, Jiri Kosina <jkosina-AlSwsSmVLrQ@public.gmane.org> wrote:
> On Sun, 19 Oct 2008, Jiri Slaby wrote:
>
>> +enum hid_type {
>> + HID_TYPE_UNKNOWN = 0,
>> + HID_TYPE_MOUSE,
>> + HID_TYPE_KEYBOARD
>> +};
>> +
>
> Do we really need the HID_TYPE_KEYBOARD at all? It's not used anywhere in
> the code. I'd propose to add it when it is actually needed. I.e. have the
> enum contain something like HID_TYPE_MOUSE HID_TYPE_OTHER for now, and add
> whatever will become necessary in the future, what do you think?
>
>
> On Sun, 19 Oct 2008, Jiri Slaby wrote:
>
>> +/**
>> + * hid_mouse_ignore_list - mouse devices which must not be held by the hid layer
>> + */
>
> I think a more descriptive comment would be appropriate here. It might not
> be obvious on the first sight why this needs to be done separately from
> the generic hid_blacklist. I.e. something like
>
> /**
> * There are composite devices for which we want to ignore only a certain
> * interface. This is a list of devices for which only the mouse interface
> * will be ignored.
> */
>
> maybe?
>
> Thanks,
>
> --
> Jiri Kosina
> SUSE Labs
>
I can agree with that, whats the point having something
there if it not being used,(just eating up precious space);
--
Justin P. Mattock
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
2008-10-19 19:40 ` several messages Jiri Kosina
2008-10-19 20:06 ` Justin Mattock
@ 2008-10-19 22:09 ` Jiri Slaby
1 sibling, 0 replies; 130+ messages in thread
From: Jiri Slaby @ 2008-10-19 22:09 UTC (permalink / raw)
To: Jiri Kosina
Cc: linux-input, linux-kernel, Steven Noonan, Justin Mattock,
Sven Anders, Marcel Holtmann, linux-bluetooth
Jiri Kosina napsal(a):
> On Sun, 19 Oct 2008, Jiri Slaby wrote:
>
>> +enum hid_type {
>> + HID_TYPE_UNKNOWN = 0,
>> + HID_TYPE_MOUSE,
>> + HID_TYPE_KEYBOARD
>> +};
>> +
>
> Do we really need the HID_TYPE_KEYBOARD at all? It's not used anywhere in
> the code. I'd propose to add it when it is actually needed. I.e. have the
> enum contain something like HID_TYPE_MOUSE HID_TYPE_OTHER for now, and add
> whatever will become necessary in the future, what do you think?
I would use unknown rather than other, since on bluetooth mouse is unknown
not other, if you don't mind?
Or did you mean tristate unknown, mouse and other?
Thanks for review.
^ permalink raw reply [flat|nested] 130+ messages in thread
[parent not found: <9E397A467F4DB34884A1FD0D5D27CF43018903F96E@msxaoa4.twosigma.com>]
* Re: several messages
[not found] <9E397A467F4DB34884A1FD0D5D27CF43018903F96E@msxaoa4.twosigma.com>
@ 2008-06-12 16:54 ` Benjamin L. Shi
0 siblings, 0 replies; 130+ messages in thread
From: Benjamin L. Shi @ 2008-06-12 16:54 UTC (permalink / raw)
To: xfs
Index: fs/xfs/xfs_iomap.c
===================================================================
RCS file: /src/linux/2.6.18/fs/xfs/xfs_iomap.c,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -r1.1.1.1 -r1.2
--- fs/xfs/xfs_iomap.c 29 Sep 2006 13:45:19 -0000 1.1.1.1
+++ fs/xfs/xfs_iomap.c 12 Jun 2008 15:59:10 -0000 1.2
@@ -706,11 +706,24 @@
* then we must have run out of space - flush delalloc, and retry..
*/
if (nimaps == 0) {
+ if ((mp->m_flags & XFS_MOUNT_FULL) != 0) {
+ if (mp->m_sb.sb_fdblocks < 500) {
+ // printk("full again %llu\n",
+ // mp->m_sb.sb_fdblocks);
+ return XFS_ERROR(ENOSPC);
+ } else {
+ // printk("not full again %llu\n",
+ // mp->m_sb.sb_fdblocks);
+ mp->m_flags &= ~XFS_MOUNT_FULL;
+ }
+ }
xfs_iomap_enter_trace(XFS_IOMAP_WRITE_NOSPACE,
io, offset, count);
- if (xfs_flush_space(ip, &fsynced, &ioflag))
+ if (xfs_flush_space(ip, &fsynced, &ioflag)) {
+ mp->m_flags |= XFS_MOUNT_FULL;
+ //printk("set full %llu\n", mp->m_sb.sb_fdblocks);
return XFS_ERROR(ENOSPC);
-
+ }
error = 0;
goto retry;
}
Index: fs/xfs/xfs_mount.h
===================================================================
RCS file: /src/linux/2.6.18/fs/xfs/xfs_mount.h,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -r1.1.1.1 -r1.2
--- fs/xfs/xfs_mount.h 29 Sep 2006 13:45:19 -0000 1.1.1.1
+++ fs/xfs/xfs_mount.h 12 Jun 2008 15:59:10 -0000 1.2
@@ -459,6 +459,7 @@
* I/O size in stat() */
#define XFS_MOUNT_NO_PERCPU_SB (1ULL << 23) /* don't use per-cpu
superblock
counters */
+#define XFS_MOUNT_FULL (1ULL << 24)
/*
>
> On Fri, 6 Oct 2006, David Chinner wrote:
>
>>> The backtrace looked like this:
>>>
>>> ... nfsd_write nfsd_vfs_write vfs_writev do_readv_writev
>>> xfs_file_writev
>>> xfs_write generic_file_buffered_write xfs_get_blocks __xfs_get_blocks
>>> xfs_bmap xfs_iomap xfs_iomap_write_delay xfs_flush_space
>>> xfs_flush_device
>>> schedule_timeout_uninterruptible.
>>
>> Ahhh, this gets hit on the ->prepare_write path
>> (xfs_iomap_write_delay()),
>
> Yes.
>
>> not the allocate path (xfs_iomap_write_allocate()). Sorry - I got myself
>> (and probably everyone else) confused there which why I suspected sync
>> writes - they trigger the allocate path in the write call. I don't think
>> 2.6.18 will change anything.
>>
>> FWIW, I don't think we can avoid this sleep when we first hit ENOSPC
>> conditions, but perhaps once we are certain of the ENOSPC status
>> we can tag the filesystem with this state (say an xfs_mount flag)
>> and only clear that tag when something is freed. We could then
>> use the tag to avoid continually trying extremely hard to allocate
>> space when we know there is none available....
>
> Yes! That's what I was trying to suggest << OLE Object: Picture (Device
> Independent Bitmap) >> . Thank you.
>
> Is that hard to do?
>
^ permalink raw reply [flat|nested] 130+ messages in thread
[parent not found: <200702211929.17203.david-b@pacbell.net>]
* [patch 6/6] rtc suspend()/resume() restores system clock
[not found] <200702211929.17203.david-b@pacbell.net>
@ 2007-02-22 3:50 ` David Brownell
2007-02-22 22:58 ` Guennadi Liakhovetski
0 siblings, 1 reply; 130+ messages in thread
From: David Brownell @ 2007-02-22 3:50 UTC (permalink / raw)
To: rtc-linux
Cc: Linux Kernel list, linux-pm, Greg KH, Andrew Morton,
Alessandro Zummo, john stultz
RTC class suspend/resume support, re-initializing the system clock on resume
from the clock used to initialize it at boot time.
- Inlining the same code used by ARM, which saves and restores the
delta between a selected RTC and the current system wall-clock time.
- Removes calls to that ARM code from AT91, OMAP, and S3C RTCs.
This goes on top of the patch series removing "struct class_device" usage
from the RTC framework. That makes class suspend()/resume() work.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
---
drivers/rtc/Kconfig | 24 +++++++++----
drivers/rtc/class.c | 74 +++++++++++++++++++++++++++++++++++++++++++
drivers/rtc/rtc-at91rm9200.c | 30 -----------------
drivers/rtc/rtc-omap.c | 17 ---------
drivers/rtc/rtc-s3c.c | 22 ------------
5 files changed, 91 insertions(+), 76 deletions(-)
Index: at91/drivers/rtc/Kconfig
===================================================================
--- at91.orig/drivers/rtc/Kconfig 2007-02-21 18:47:38.000000000 -0800
+++ at91/drivers/rtc/Kconfig 2007-02-21 18:47:41.000000000 -0800
@@ -21,21 +21,31 @@ config RTC_CLASS
will be called rtc-class.
config RTC_HCTOSYS
- bool "Set system time from RTC on startup"
+ bool "Set system time from RTC on startup and resume"
depends on RTC_CLASS = y
default y
help
- If you say yes here, the system time will be set using
- the value read from the specified RTC device. This is useful
- in order to avoid unnecessary fsck runs.
+ If you say yes here, the system time (wall clock) will be set using
+ the value read from a specified RTC device. This is useful to avoid
+ unnecessary fsck runs at boot time, and to network better.
config RTC_HCTOSYS_DEVICE
- string "The RTC to read the time from"
+ string "RTC used to set the system time"
depends on RTC_HCTOSYS = y
default "rtc0"
help
- The RTC device that will be used as the source for
- the system time, usually rtc0.
+ The RTC device that will be used to (re)initialize the system
+ clock, usually rtc0. Initialization is done when the system
+ starts up, and when it resumes from a low power state.
+
+ This clock should be battery-backed, so that it reads the correct
+ time when the system boots from a power-off state. Otherwise, your
+ system will need an external clock source (like an NTP server).
+
+ If the clock you specify here is not battery backed, it may still
+ be useful to reinitialize system time when resuming from system
+ sleep states. Do not specify an RTC here unless it stays powered
+ during all this system's supported sleep states.
config RTC_DEBUG
bool "RTC debug support"
Index: at91/drivers/rtc/class.c
===================================================================
--- at91.orig/drivers/rtc/class.c 2007-02-21 18:47:39.000000000 -0800
+++ at91/drivers/rtc/class.c 2007-02-21 18:47:41.000000000 -0800
@@ -32,6 +32,78 @@ static void rtc_device_release(struct de
kfree(rtc);
}
+#if defined(CONFIG_PM) && defined(CONFIG_RTC_HCTOSYS_DEVICE)
+
+/*
+ * On suspend(), measure the delta between one RTC and the
+ * system's wall clock; restore it on resume().
+ */
+
+static struct timespec delta;
+static time_t oldtime;
+
+static int rtc_suspend(struct device *dev, pm_message_t mesg)
+{
+ struct rtc_device *rtc = to_rtc_device(dev);
+ struct rtc_time tm;
+
+ if (strncmp(rtc->dev.bus_id,
+ CONFIG_RTC_HCTOSYS_DEVICE,
+ BUS_ID_SIZE) != 0)
+ return 0;
+
+ rtc_read_time(rtc, &tm);
+ rtc_tm_to_time(&tm, &oldtime);
+
+ /* RTC precision is 1 second; adjust delta for avg 1/2 sec err */
+ set_normalized_timespec(&delta,
+ xtime.tv_sec - oldtime,
+ xtime.tv_nsec - (NSEC_PER_SEC >> 1));
+
+ return 0;
+}
+
+static int rtc_resume(struct device *dev)
+{
+ struct rtc_device *rtc = to_rtc_device(dev);
+ struct rtc_time tm;
+ time_t newtime;
+ struct timespec time;
+
+ if (strncmp(rtc->dev.bus_id,
+ CONFIG_RTC_HCTOSYS_DEVICE,
+ BUS_ID_SIZE) != 0)
+ return 0;
+
+ rtc_read_time(rtc, &tm);
+ if (rtc_valid_tm(&tm) != 0) {
+ pr_debug("%s: bogus resume time\n", rtc->dev.bus_id);
+ return 0;
+ }
+ rtc_tm_to_time(&tm, &newtime);
+ if (newtime <= oldtime) {
+ if (newtime < oldtime)
+ pr_debug("%s: time travel!\n", rtc->dev.bus_id);
+ return 0;
+ }
+
+ /* restore wall clock using delta against this RTC;
+ * adjust again for avg 1/2 second RTC sampling error
+ */
+ set_normalized_timespec(&time,
+ newtime + delta.tv_sec,
+ (NSEC_PER_SEC >> 1) + delta.tv_nsec);
+ do_settimeofday(&time);
+
+ return 0;
+}
+
+#else
+#define rtc_suspend NULL
+#define rtc_resume NULL
+#endif
+
+
/**
* rtc_device_register - register w/ RTC class
* @dev: the device to register
@@ -138,6 +210,8 @@ static int __init rtc_init(void)
printk(KERN_ERR "%s: couldn't create class\n", __FILE__);
return PTR_ERR(rtc_class);
}
+ rtc_class->suspend = rtc_suspend;
+ rtc_class->resume = rtc_resume;
rtc_dev_init();
rtc_sysfs_init(rtc_class);
return 0;
Index: at91/drivers/rtc/rtc-at91rm9200.c
===================================================================
--- at91.orig/drivers/rtc/rtc-at91rm9200.c 2007-02-21 18:47:26.000000000 -0800
+++ at91/drivers/rtc/rtc-at91rm9200.c 2007-02-21 18:47:41.000000000 -0800
@@ -348,21 +348,10 @@ static int __exit at91_rtc_remove(struct
/* AT91RM9200 RTC Power management control */
-static struct timespec at91_rtc_delta;
static u32 at91_rtc_imr;
static int at91_rtc_suspend(struct platform_device *pdev, pm_message_t state)
{
- struct rtc_time tm;
- struct timespec time;
-
- time.tv_nsec = 0;
-
- /* calculate time delta for suspend */
- at91_rtc_readtime(&pdev->dev, &tm);
- rtc_tm_to_time(&tm, &time.tv_sec);
- save_time_delta(&at91_rtc_delta, &time);
-
/* this IRQ is shared with DBGU and other hardware which isn't
* necessarily doing PM like we are...
*/
@@ -374,36 +363,17 @@ static int at91_rtc_suspend(struct platf
else
at91_sys_write(AT91_RTC_IDR, at91_rtc_imr);
}
-
- pr_debug("%s(): %4d-%02d-%02d %02d:%02d:%02d\n", __FUNCTION__,
- 1900 + tm.tm_year, tm.tm_mon, tm.tm_mday,
- tm.tm_hour, tm.tm_min, tm.tm_sec);
-
return 0;
}
static int at91_rtc_resume(struct platform_device *pdev)
{
- struct rtc_time tm;
- struct timespec time;
-
- time.tv_nsec = 0;
-
- at91_rtc_readtime(&pdev->dev, &tm);
- rtc_tm_to_time(&tm, &time.tv_sec);
- restore_time_delta(&at91_rtc_delta, &time);
-
if (at91_rtc_imr) {
if (device_may_wakeup(&pdev->dev))
disable_irq_wake(AT91_ID_SYS);
else
at91_sys_write(AT91_RTC_IER, at91_rtc_imr);
}
-
- pr_debug("%s(): %4d-%02d-%02d %02d:%02d:%02d\n", __FUNCTION__,
- 1900 + tm.tm_year, tm.tm_mon, tm.tm_mday,
- tm.tm_hour, tm.tm_min, tm.tm_sec);
-
return 0;
}
#else
Index: at91/drivers/rtc/rtc-omap.c
===================================================================
--- at91.orig/drivers/rtc/rtc-omap.c 2007-02-21 18:47:39.000000000 -0800
+++ at91/drivers/rtc/rtc-omap.c 2007-02-21 18:47:41.000000000 -0800
@@ -488,19 +488,10 @@ static int __devexit omap_rtc_remove(str
#ifdef CONFIG_PM
-static struct timespec rtc_delta;
static u8 irqstat;
static int omap_rtc_suspend(struct platform_device *pdev, pm_message_t state)
{
- struct rtc_time rtc_tm;
- struct timespec time;
-
- time.tv_nsec = 0;
- omap_rtc_read_time(NULL, &rtc_tm);
- rtc_tm_to_time(&rtc_tm, &time.tv_sec);
-
- save_time_delta(&rtc_delta, &time);
irqstat = rtc_read(OMAP_RTC_INTERRUPTS_REG);
/* FIXME the RTC alarm is not currently acting as a wakeup event
@@ -517,14 +508,6 @@ static int omap_rtc_suspend(struct platf
static int omap_rtc_resume(struct platform_device *pdev)
{
- struct rtc_time rtc_tm;
- struct timespec time;
-
- time.tv_nsec = 0;
- omap_rtc_read_time(NULL, &rtc_tm);
- rtc_tm_to_time(&rtc_tm, &time.tv_sec);
-
- restore_time_delta(&rtc_delta, &time);
if (device_may_wakeup(&pdev->dev))
disable_irq_wake(omap_rtc_alarm);
else
Index: at91/drivers/rtc/rtc-s3c.c
===================================================================
--- at91.orig/drivers/rtc/rtc-s3c.c 2007-02-21 18:47:26.000000000 -0800
+++ at91/drivers/rtc/rtc-s3c.c 2007-02-21 18:47:41.000000000 -0800
@@ -548,37 +548,15 @@ static int ticnt_save;
static int s3c_rtc_suspend(struct platform_device *pdev, pm_message_t state)
{
- struct rtc_time tm;
- struct timespec time;
-
- time.tv_nsec = 0;
-
/* save TICNT for anyone using periodic interrupts */
-
ticnt_save = readb(s3c_rtc_base + S3C2410_TICNT);
-
- /* calculate time delta for suspend */
-
- s3c_rtc_gettime(&pdev->dev, &tm);
- rtc_tm_to_time(&tm, &time.tv_sec);
- save_time_delta(&s3c_rtc_delta, &time);
s3c_rtc_enable(pdev, 0);
-
return 0;
}
static int s3c_rtc_resume(struct platform_device *pdev)
{
- struct rtc_time tm;
- struct timespec time;
-
- time.tv_nsec = 0;
-
s3c_rtc_enable(pdev, 1);
- s3c_rtc_gettime(&pdev->dev, &tm);
- rtc_tm_to_time(&tm, &time.tv_sec);
- restore_time_delta(&s3c_rtc_delta, &time);
-
writeb(ticnt_save, s3c_rtc_base + S3C2410_TICNT);
return 0;
}
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
2007-02-22 3:50 ` [patch 6/6] rtc suspend()/resume() restores system clock David Brownell
2007-02-22 22:58 ` Guennadi Liakhovetski
@ 2007-02-22 22:58 ` Guennadi Liakhovetski
0 siblings, 0 replies; 130+ messages in thread
From: Guennadi Liakhovetski @ 2007-02-22 22:58 UTC (permalink / raw)
To: Johannes Berg, David Brownell
Cc: linuxppc-dev, rtc-linux, linux-pm, Torrance, Alessandro Zummo,
john stultz, Andrew Morton, Linux Kernel list
of the following 2 patches:
On Mon, 5 Feb 2007, Johannes Berg wrote:
> This patch removes the time suspend/restore code that was done through
> a PMU notifier in arch/platforms/powermac/time.c.
>
> Instead, we introduce arch/powerpc/sysdev/timer.c which creates a sys
> device and handles time of day suspend/resume through that.
>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
> Cc: Andrew Morton <akpm@osdl.org>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
[patch trimmed]
On Wed, 21 Feb 2007, David Brownell wrote:
> RTC class suspend/resume support, re-initializing the system clock on resume
> >from the clock used to initialize it at boot time.
>
> - Inlining the same code used by ARM, which saves and restores the
> delta between a selected RTC and the current system wall-clock time.
>
> - Removes calls to that ARM code from AT91, OMAP, and S3C RTCs.
>
> This goes on top of the patch series removing "struct class_device" usage
> >from the RTC framework. That makes class suspend()/resume() work.
>
> Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
>
> ---
> drivers/rtc/Kconfig | 24 +++++++++----
> drivers/rtc/class.c | 74 +++++++++++++++++++++++++++++++++++++++++++
> drivers/rtc/rtc-at91rm9200.c | 30 -----------------
> drivers/rtc/rtc-omap.c | 17 ---------
> drivers/rtc/rtc-s3c.c | 22 ------------
> 5 files changed, 91 insertions(+), 76 deletions(-)
[patch trimmed]
I think, we only want 1, right? And the latter seems to be more generic /
platform independent? And as a side-effect, powermac would have to migrate
to generic rtc:-)
Thanks
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
@ 2007-02-22 22:58 ` Guennadi Liakhovetski
0 siblings, 0 replies; 130+ messages in thread
From: Guennadi Liakhovetski @ 2007-02-22 22:58 UTC (permalink / raw)
To: Johannes Berg, David Brownell
Cc: Alessandro Zummo, rtc-linux, john stultz, linux-pm,
Linux Kernel list, Torrance, linuxppc-dev, Andrew Morton
of the following 2 patches:
On Mon, 5 Feb 2007, Johannes Berg wrote:
> This patch removes the time suspend/restore code that was done through
> a PMU notifier in arch/platforms/powermac/time.c.
>
> Instead, we introduce arch/powerpc/sysdev/timer.c which creates a sys
> device and handles time of day suspend/resume through that.
>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
> Cc: Andrew Morton <akpm@osdl.org>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
[patch trimmed]
On Wed, 21 Feb 2007, David Brownell wrote:
> RTC class suspend/resume support, re-initializing the system clock on resume
> >from the clock used to initialize it at boot time.
>
> - Inlining the same code used by ARM, which saves and restores the
> delta between a selected RTC and the current system wall-clock time.
>
> - Removes calls to that ARM code from AT91, OMAP, and S3C RTCs.
>
> This goes on top of the patch series removing "struct class_device" usage
> >from the RTC framework. That makes class suspend()/resume() work.
>
> Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
>
> ---
> drivers/rtc/Kconfig | 24 +++++++++----
> drivers/rtc/class.c | 74 +++++++++++++++++++++++++++++++++++++++++++
> drivers/rtc/rtc-at91rm9200.c | 30 -----------------
> drivers/rtc/rtc-omap.c | 17 ---------
> drivers/rtc/rtc-s3c.c | 22 ------------
> 5 files changed, 91 insertions(+), 76 deletions(-)
[patch trimmed]
I think, we only want 1, right? And the latter seems to be more generic /
platform independent? And as a side-effect, powermac would have to migrate
to generic rtc:-)
Thanks
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
@ 2007-02-22 22:58 ` Guennadi Liakhovetski
0 siblings, 0 replies; 130+ messages in thread
From: Guennadi Liakhovetski @ 2007-02-22 22:58 UTC (permalink / raw)
To: Johannes Berg, David Brownell
Cc: linuxppc-dev, Alessandro Zummo, rtc-linux, john stultz,
Andrew Morton, linux-pm, Linux Kernel list, Torrance
of the following 2 patches:
On Mon, 5 Feb 2007, Johannes Berg wrote:
> This patch removes the time suspend/restore code that was done through
> a PMU notifier in arch/platforms/powermac/time.c.
>
> Instead, we introduce arch/powerpc/sysdev/timer.c which creates a sys
> device and handles time of day suspend/resume through that.
>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
> Cc: Andrew Morton <akpm@osdl.org>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
[patch trimmed]
On Wed, 21 Feb 2007, David Brownell wrote:
> RTC class suspend/resume support, re-initializing the system clock on resume
> >from the clock used to initialize it at boot time.
>
> - Inlining the same code used by ARM, which saves and restores the
> delta between a selected RTC and the current system wall-clock time.
>
> - Removes calls to that ARM code from AT91, OMAP, and S3C RTCs.
>
> This goes on top of the patch series removing "struct class_device" usage
> >from the RTC framework. That makes class suspend()/resume() work.
>
> Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
>
> ---
> drivers/rtc/Kconfig | 24 +++++++++----
> drivers/rtc/class.c | 74 +++++++++++++++++++++++++++++++++++++++++++
> drivers/rtc/rtc-at91rm9200.c | 30 -----------------
> drivers/rtc/rtc-omap.c | 17 ---------
> drivers/rtc/rtc-s3c.c | 22 ------------
> 5 files changed, 91 insertions(+), 76 deletions(-)
[patch trimmed]
I think, we only want 1, right? And the latter seems to be more generic /
platform independent? And as a side-effect, powermac would have to migrate
to generic rtc:-)
Thanks
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
2007-02-22 22:58 ` Guennadi Liakhovetski
(?)
@ 2007-02-23 1:15 ` David Brownell
-1 siblings, 0 replies; 130+ messages in thread
From: David Brownell @ 2007-02-23 1:15 UTC (permalink / raw)
To: Guennadi Liakhovetski
Cc: Alessandro Zummo, Andrew Morton, Johannes Berg, john stultz,
Linux Kernel list, linux-pm, linuxppc-dev, rtc-linux, Torrance
On Thursday 22 February 2007 2:58 pm, Guennadi Liakhovetski wrote:
>
> I think, we only want 1, right? And the latter seems to be more generic /
> platform independent? And as a side-effect, powermac would have to migrate
> to generic rtc:-)
I'd certainly think that restoring the system clock should be, as much
as possible, in platform-agnostic code. Like the generic RTC framework.
And hmm, that powermac/time.c file replicates other RTC code...
Minor obstacle: removing the EXPERIMENTAL label from that code.
- Dave
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
@ 2007-02-23 1:15 ` David Brownell
0 siblings, 0 replies; 130+ messages in thread
From: David Brownell @ 2007-02-23 1:15 UTC (permalink / raw)
To: Guennadi Liakhovetski
Cc: Alessandro Zummo, rtc-linux, john stultz, linux-pm,
Linux Kernel list, Torrance, linuxppc-dev, Andrew Morton,
Johannes Berg
On Thursday 22 February 2007 2:58 pm, Guennadi Liakhovetski wrote:
>
> I think, we only want 1, right? And the latter seems to be more generic /
> platform independent? And as a side-effect, powermac would have to migrate
> to generic rtc:-)
I'd certainly think that restoring the system clock should be, as much
as possible, in platform-agnostic code. Like the generic RTC framework.
And hmm, that powermac/time.c file replicates other RTC code...
Minor obstacle: removing the EXPERIMENTAL label from that code.
- Dave
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
@ 2007-02-23 1:15 ` David Brownell
0 siblings, 0 replies; 130+ messages in thread
From: David Brownell @ 2007-02-23 1:15 UTC (permalink / raw)
To: Guennadi Liakhovetski
Cc: linuxppc-dev, Torrance, Alessandro Zummo, rtc-linux, john stultz,
Andrew Morton, linux-pm, Johannes Berg, Linux Kernel list
On Thursday 22 February 2007 2:58 pm, Guennadi Liakhovetski wrote:
>
> I think, we only want 1, right? And the latter seems to be more generic /
> platform independent? And as a side-effect, powermac would have to migrate
> to generic rtc:-)
I'd certainly think that restoring the system clock should be, as much
as possible, in platform-agnostic code. Like the generic RTC framework.
And hmm, that powermac/time.c file replicates other RTC code...
Minor obstacle: removing the EXPERIMENTAL label from that code.
- Dave
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
2007-02-22 22:58 ` Guennadi Liakhovetski
(?)
@ 2007-02-23 11:17 ` Johannes Berg
-1 siblings, 0 replies; 130+ messages in thread
From: Johannes Berg @ 2007-02-23 11:17 UTC (permalink / raw)
To: Guennadi Liakhovetski
Cc: David Brownell, linuxppc-dev, rtc-linux, linux-pm, Torrance,
Alessandro Zummo, john stultz, Andrew Morton, Linux Kernel list
[-- Attachment #1: Type: text/plain, Size: 378 bytes --]
On Thu, 2007-02-22 at 23:58 +0100, Guennadi Liakhovetski wrote:
> I think, we only want 1, right? And the latter seems to be more generic /
> platform independent? And as a side-effect, powermac would have to migrate
> to generic rtc:-)
Can we migrate all of powerpc to genrtc? But yes, I agree. Had enough to
do though already to get suspend working :)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
@ 2007-02-23 11:17 ` Johannes Berg
0 siblings, 0 replies; 130+ messages in thread
From: Johannes Berg @ 2007-02-23 11:17 UTC (permalink / raw)
To: Guennadi Liakhovetski
Cc: Alessandro Zummo, rtc-linux, Torrance, linux-pm,
Linux Kernel list, David Brownell, linuxppc-dev, john stultz,
Andrew Morton
[-- Attachment #1: Type: text/plain, Size: 378 bytes --]
On Thu, 2007-02-22 at 23:58 +0100, Guennadi Liakhovetski wrote:
> I think, we only want 1, right? And the latter seems to be more generic /
> platform independent? And as a side-effect, powermac would have to migrate
> to generic rtc:-)
Can we migrate all of powerpc to genrtc? But yes, I agree. Had enough to
do though already to get suspend working :)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
@ 2007-02-23 11:17 ` Johannes Berg
0 siblings, 0 replies; 130+ messages in thread
From: Johannes Berg @ 2007-02-23 11:17 UTC (permalink / raw)
To: Guennadi Liakhovetski
Cc: Alessandro Zummo, rtc-linux, Torrance, linux-pm,
Linux Kernel list, David Brownell, linuxppc-dev, john stultz,
Andrew Morton
[-- Attachment #1.1: Type: text/plain, Size: 378 bytes --]
On Thu, 2007-02-22 at 23:58 +0100, Guennadi Liakhovetski wrote:
> I think, we only want 1, right? And the latter seems to be more generic /
> platform independent? And as a side-effect, powermac would have to migrate
> to generic rtc:-)
Can we migrate all of powerpc to genrtc? But yes, I agree. Had enough to
do though already to get suspend working :)
johannes
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
[-- Attachment #2: Type: text/plain, Size: 146 bytes --]
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply [flat|nested] 130+ messages in thread
* Long sleep with i_mutex in xfs_flush_device(), affects NFS service
@ 2006-09-26 18:51 Stephane Doyon
2006-09-27 11:33 ` Shailendra Tripathi
0 siblings, 1 reply; 130+ messages in thread
From: Stephane Doyon @ 2006-09-26 18:51 UTC (permalink / raw)
To: xfs, nfs
Hi,
I'm seeing an unpleasant behavior when an XFS file system becomes full,
particularly when accessed over NFS. Both XFS and the linux NFS client
appear to be contributing to the problem.
When the file system becomes nearly full, we eventually call down to
xfs_flush_device(), which sleeps for 0.5seconds, waiting for xfssyncd to
do some work.
xfs_flush_space()does
xfs_iunlock(ip, XFS_ILOCK_EXCL);
before calling xfs_flush_device(), but i_mutex is still held, at least
when we're being called from under xfs_write(). It seems like a fairly
long time to hold a mutex. And I wonder whether it's really necessary to
keep going through that again and again for every new request after we've
hit NOSPC.
In particular this can cause a pileup when several threads are writing
concurrently to the same file. Some specialized apps might do that, and
nfsd threads do it all the time.
To reproduce locally, on a full file system:
#!/bin/sh
for i in `seq 30`; do
dd if=/dev/zero of=f bs=1 count=1 &
done
wait
time that, it takes nearly exactly 15s.
The linux NFS client typically sends bunches of 16 requests, and so if the
client is writing a single file, some NFS requests are therefore delayed
by up to 8seconds, which is kind of long for NFS.
What's worse, when my linux NFS client writes out a file's pages, it does
not react immediately on receiving a NOSPC error. It will remember and
report the error later on close(), but it still tries and issues write
requests for each page of the file. So even if there isn't a pileup on the
i_mutex on the server, the NFS client still waits 0.5s for each 32K
(typically) request. So on an NFS client on a gigabit network, on an
already full filesystem, if I open and write a 10M file and close() it, it
takes 2m40.083s for it to issue all the requests, get an NOSPC for each,
and finally have my close() call return ENOSPC. That can stretch to
several hours for gigabyte-sized files, which is how I noticed the
problem.
I'm not too familiar with the NFS client code, but would it not be
possible for it to give up when it encounters NOSPC? Or is there some
reason why this wouldn't be desirable?
The rough workaround I have come up with for the problem is to have
xfs_flush_space() skip calling xfs_flush_device() if we are within 2secs
of having returned ENOSPC. I have verified that this workaround is
effective, but I imagine there might be a cleaner solution.
Thanks
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Long sleep with i_mutex in xfs_flush_device(), affects NFS service
2006-09-26 18:51 Long sleep with i_mutex in xfs_flush_device(), affects NFS service Stephane Doyon
@ 2006-09-27 11:33 ` Shailendra Tripathi
2006-10-02 14:45 ` Stephane Doyon
0 siblings, 1 reply; 130+ messages in thread
From: Shailendra Tripathi @ 2006-09-27 11:33 UTC (permalink / raw)
To: Stephane Doyon; +Cc: xfs, nfs
Hi Stephane,
> When the file system becomes nearly full, we eventually call down to
> xfs_flush_device(), which sleeps for 0.5seconds, waiting for xfssyncd to
> do some work.
> xfs_flush_space()does
> xfs_iunlock(ip, XFS_ILOCK_EXCL);
> before calling xfs_flush_device(), but i_mutex is still held, at least
> when we're being called from under xfs_write().
1. I agree that the delay of 500 ms is not a deterministic wait.
2. xfs_flush_device is a big operation. It has to flush all the dirty
pages possibly in the cache on the device. Depending upon the device, it
might take significant amount of time. Keeping view of it, 500 ms in
that unreasonable. Also, perhaps you would never want more than one
request to be queued for device flush.
3. The hope is that after one big flush operation, it would be able to
free up resources which are in transient state (over-reservation of
blocks, delalloc, pending removes, ...). The whole operation is intended
to make sure that ENOSPC is not returned unless really required.
4. This wait could be made deterministic by waiting for the syncer
thread to complete when device flush is triggered.
> It seems like a fairly long time to hold a mutex. And I wonder whether it's really
It might not be that good even if it doesn't. This can return pre-mature
ENOSPC or it can queue many xfs_flush_device requests (which can make
your system dead(-slow) anyway)
> necessary to keep going through that again and again for every new request after
> we've hit NOSPC.
>
> In particular this can cause a pileup when several threads are writing
> concurrently to the same file. Some specialized apps might do that, and
> nfsd threads do it all the time.
>
> To reproduce locally, on a full file system:
> #!/bin/sh
> for i in `seq 30`; do
> dd if=/dev/zero of=f bs=1 count=1 &
> done
> wait
> time that, it takes nearly exactly 15s.
>
> The linux NFS client typically sends bunches of 16 requests, and so if
> the client is writing a single file, some NFS requests are therefore
> delayed by up to 8seconds, which is kind of long for NFS.
>
> What's worse, when my linux NFS client writes out a file's pages, it
> does not react immediately on receiving a NOSPC error. It will remember
> and report the error later on close(), but it still tries and issues
> write requests for each page of the file. So even if there isn't a
> pileup on the i_mutex on the server, the NFS client still waits 0.5s for
> each 32K (typically) request. So on an NFS client on a gigabit network,
> on an already full filesystem, if I open and write a 10M file and
> close() it, it takes 2m40.083s for it to issue all the requests, get an
> NOSPC for each, and finally have my close() call return ENOSPC. That can
> stretch to several hours for gigabyte-sized files, which is how I
> noticed the problem.
>
> I'm not too familiar with the NFS client code, but would it not be
> possible for it to give up when it encounters NOSPC? Or is there some
> reason why this wouldn't be desirable?
>
> The rough workaround I have come up with for the problem is to have
> xfs_flush_space() skip calling xfs_flush_device() if we are within 2secs
> of having returned ENOSPC. I have verified that this workaround is
> effective, but I imagine there might be a cleaner solution.
The fix would not be a good idea for standalone use of XFS.
if (nimaps == 0) {
if (xfs_flush_space(ip, &fsynced, &ioflag))
return XFS_ERROR(ENOSPC);
error = 0;
goto retry;
}
xfs_flush_space:
case 2:
xfs_iunlock(ip, XFS_ILOCK_EXCL);
xfs_flush_device(ip);
xfs_ilock(ip, XFS_ILOCK_EXCL);
*fsynced = 3;
return 0;
}
return 1;
lets say that you don't enqueue it for another 2 secs. Then, in next
retry it would return 1 and, hence, outer if condition would return
ENOSPC. Please note that for standalone XFS, the application or client
mostly don't retry and, hence, it might return premature ENOSPC.
You didn't notice this because, as you said, nfs client will retry in
case of ENOSPC.
Assuming that you don't return *fsynced = 3 (instead *fsynced = 2), the
code path will loop (because of retry) and CPU itself would become busy
for no good job.
You might experiment by adding deterministic wait. When you enqueue, set
some flag. All others who come in between just get enqueued. Once,
device flush is over wake up all. If flush could free enough resources,
threads will proceed ahead and return. Otherwise, another flush would be
enqueued to flush what might have come since last flush.
> Thanks
>
>
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Long sleep with i_mutex in xfs_flush_device(), affects NFS service
2006-09-27 11:33 ` Shailendra Tripathi
@ 2006-10-02 14:45 ` Stephane Doyon
2006-10-02 22:30 ` David Chinner
0 siblings, 1 reply; 130+ messages in thread
From: Stephane Doyon @ 2006-10-02 14:45 UTC (permalink / raw)
To: Shailendra Tripathi; +Cc: xfs
On Wed, 27 Sep 2006, Shailendra Tripathi wrote:
> Hi Stephane,
>> When the file system becomes nearly full, we eventually call down to
>> xfs_flush_device(), which sleeps for 0.5seconds, waiting for xfssyncd to
>> do some work. xfs_flush_space()does
>> xfs_iunlock(ip, XFS_ILOCK_EXCL);
>> before calling xfs_flush_device(), but i_mutex is still held, at least
>> when we're being called from under xfs_write().
>
> 1. I agree that the delay of 500 ms is not a deterministic wait.
>
> 2. xfs_flush_device is a big operation. It has to flush all the dirty pages
> possibly in the cache on the device. Depending upon the device, it might take
> significant amount of time. Keeping view of it, 500 ms in that unreasonable.
> Also, perhaps you would never want more than one request to be queued for
> device flush.
> 3. The hope is that after one big flush operation, it would be able to free
> up resources which are in transient state (over-reservation of blocks,
> delalloc, pending removes, ...). The whole operation is intended to make sure
> that ENOSPC is not returned unless really required.
Yes I had surmised as much. That last part is still a little vague to
me... But my two points were:
-It's a long time to hold a mutex. The code bothers to drop the
xfs_ilock, so I'm wondering whether the i_mutex had been forgotten?
-Once we've actually hit ENOSPC, do we need to try again? Isn't it
possible to tell when resources have actually been freed?
> 4. This wait could be made deterministic by waiting for the syncer thread to
> complete when device flush is triggered.
I remember that some time ago, there wasn't any xfs_syncd, and the
flushing operation was performed by the task wanting the free space. And
it would cause deadlocks. So I presume we would have to be careful if we
wanted to wait on sync.
>> The rough workaround I have come up with for the problem is to have
>> xfs_flush_space() skip calling xfs_flush_device() if we are within 2secs
>> of having returned ENOSPC. I have verified that this workaround is
>> effective, but I imagine there might be a cleaner solution.
>
> The fix would not be a good idea for standalone use of XFS.
>
> if (nimaps == 0) {
> if (xfs_flush_space(ip, &fsynced, &ioflag))
> return XFS_ERROR(ENOSPC);
>
> error = 0;
> goto retry;
> }
>
> xfs_flush_space:
> case 2:
> xfs_iunlock(ip, XFS_ILOCK_EXCL);
> xfs_flush_device(ip);
> xfs_ilock(ip, XFS_ILOCK_EXCL);
> *fsynced = 3;
> return 0;
> }
> return 1;
>
> lets say that you don't enqueue it for another 2 secs. Then, in next retry it
> would return 1 and, hence, outer if condition would return ENOSPC. Please
> note that for standalone XFS, the application or client mostly don't retry
> and, hence, it might return premature ENOSPC.
>
> You didn't notice this because, as you said, nfs client will retry in case of
> ENOSPC.
I'm not entirely sure I follow your explanation. The *fsynced variable is
local to the xfs_iomap_write_delay() caller, so each call will go through
the three steps in xfs_flush_space(). What my workaround does is, if we've
done the xfs_flush_device() thing and still hit ENOSPC within the last two
seconds, and we've just tried again the first two xfs_flush_space() steps,
then we skip the third step and return ENOSPC. So yes the file system
might not be exactly entirely full anymore, which is why I say it's a
rough workaround, but it seems to me the discrepancy shouldn't be very big
either. Whatever free space might have been missed would have had to be
freed after the last ENOSPC return, and must be such that only another
xfs_flush_device() call will make it available.
It seems to me ENOSPC has never been something very exact anyway: df
(statfs) often still shows a few remaining free blocks even on a full file
system. Apps can't really calculate how many blocks will be needed for
inodes, btrees and directories, so the number of remaining data blocks is
an approximation. I am not entirely sure that what xfs_flush_device_work()
does is quite deterministic, and as you said the wait period is arbitrary.
And I don't particularly care to get every single last byte out of my file
system, as long as there are no flagrant inconsistencies such as rm -fr
not freeing up some space.
> Assuming that you don't return *fsynced = 3 (instead *fsynced = 2), the code
> path will loop (because of retry) and CPU itself would become busy for no
> good job.
Indeed.
> You might experiment by adding deterministic wait. When you enqueue, set
> some flag. All others who come in between just get enqueued. Once, device
> flush is over wake up all. If flush could free enough resources, threads will
> proceed ahead and return. Otherwise, another flush would be enqueued to flush
> what might have come since last flush.
But how do you know whether you need to flush again, or whether your file
system is really full this time? And there's still the issue with the
i_mutex.
Perhaps there's a way to evaluate how much resources are "in transient
state" as you put it. Otherwise, we could set a flag when ENOSPC is
returned, and have that flag cleared at appropriate places in the code
where blocks are actually freed. I keep running into various deadlocks
related to full file systems, so I'm wary of clever solutions :-).
[Dropped nfs@lists.sourceforge.net from Cc, as this discussion is quite
specific to xfs.]
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Long sleep with i_mutex in xfs_flush_device(), affects NFS service
2006-10-02 14:45 ` Stephane Doyon
@ 2006-10-02 22:30 ` David Chinner
2006-10-03 13:39 ` Stephane Doyon
0 siblings, 1 reply; 130+ messages in thread
From: David Chinner @ 2006-10-02 22:30 UTC (permalink / raw)
To: Stephane Doyon; +Cc: Shailendra Tripathi, xfs
On Mon, Oct 02, 2006 at 10:45:12AM -0400, Stephane Doyon wrote:
> On Wed, 27 Sep 2006, Shailendra Tripathi wrote:
>
> >Hi Stephane,
> >> When the file system becomes nearly full, we eventually call down to
> >> xfs_flush_device(), which sleeps for 0.5seconds, waiting for xfssyncd to
> >> do some work. xfs_flush_space()does
> >> xfs_iunlock(ip, XFS_ILOCK_EXCL);
> >> before calling xfs_flush_device(), but i_mutex is still held, at least
> >> when we're being called from under xfs_write().
> >
> >1. I agree that the delay of 500 ms is not a deterministic wait.
AFAICT, it was never intended to be.
It's not deterministic, and the wait is really only there to ensure
that the synchronous log force catches all the operations that may
have recently occurred so they can be unpinned and flushed.
For example, an extent that has been truncated and freed cannot be
reused until the transaction that it was freed in has actually been
commited to disk.....
> >2. xfs_flush_device is a big operation. It has to flush all the dirty
> >pages possibly in the cache on the device. Depending upon the device, it
> >might take significant amount of time. Keeping view of it, 500 ms in that
> >unreasonable. Also, perhaps you would never want more than one request to
> >be queued for device flush.
> >3. The hope is that after one big flush operation, it would be able to
> >free up resources which are in transient state (over-reservation of
> >blocks, delalloc, pending removes, ...). The whole operation is intended
> >to make sure that ENOSPC is not returned unless really required.
>
> Yes I had surmised as much. That last part is still a little vague to
> me... But my two points were:
>
> -It's a long time to hold a mutex. The code bothers to drop the
> xfs_ilock, so I'm wondering whether the i_mutex had been forgotten?
This deep in the XFS allocation functions, we cannot tell if we hold
the i_mutex or not, and it plays no part in determining if we have
space or not. Hence we don't touch it here.
> -Once we've actually hit ENOSPC, do we need to try again? Isn't it
> possible to tell when resources have actually been freed?
Given that the only way to determine if space was made available is
to query every AG in the exact same way an allocation does, it makes
sense to try the allocation again to determine if space was made
available....
> >4. This wait could be made deterministic by waiting for the syncer thread
> >to complete when device flush is triggered.
>
> I remember that some time ago, there wasn't any xfs_syncd, and the
> flushing operation was performed by the task wanting the free space. And
> it would cause deadlocks. So I presume we would have to be careful if we
> wanted to wait on sync.
*nod*
Last thing we want is more deadlocks. This code is already
convoluted enough without added yet more special cases to it....
> >> The rough workaround I have come up with for the problem is to have
> >> xfs_flush_space() skip calling xfs_flush_device() if we are within 2secs
> >> of having returned ENOSPC. I have verified that this workaround is
> >> effective, but I imagine there might be a cleaner solution.
> >
> >The fix would not be a good idea for standalone use of XFS.
I doubt it's a good idea for an NFS server, either.
Remember that XFS, like most filesystems, trades off speed for
correctness as we approach ENOSPC. Many parts of XFS slow down as we
approach ENOSPC, and this is just one example of where we need to be
correct, not fast.
> It seems to me ENOSPC has never been something very exact anyway:
> df (statfs) often still shows a few remaining free blocks even on
> a full file system. Apps can't really calculate how many blocks
> will be needed for inodes, btrees and directories, so the number
> of remaining data blocks is an approximation.
It's not supposed to be an approximation - the number reported by df
should be taking all this into account because it's coming directly
from how much space XFS thinks it has available.
> >You might experiment by adding deterministic wait. When you enqueue, set
> >some flag. All others who come in between just get enqueued. Once, device
> >flush is over wake up all. If flush could free enough resources, threads
> >will proceed ahead and return. Otherwise, another flush would be enqueued
> >to flush what might have come since last flush.
>
> But how do you know whether you need to flush again, or whether your file
> system is really full this time? And there's still the issue with the
> i_mutex.
>
> Perhaps there's a way to evaluate how much resources are "in transient
> state" as you put it.
I doubt there's any way of doing this without introducing non-enospc
performance regressions and extra memory usage.
> Otherwise, we could set a flag when ENOSPC is
> returned, and have that flag cleared at appropriate places in the code
> where blocks are actually freed. I keep running into various deadlocks
> related to full file systems, so I'm wary of clever solutions :-).
IMO, this is a non-problem. You're talking about optimising a
relatively rare corner case where correctness is more important than
speed and your test case is highly artificial. AFAIC, if you are
running at ENOSPC then you get what performance is appropriate for
correctness and if you are continually runing at ENOSPC, then buy
some more disks.....
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
2006-10-02 22:30 ` David Chinner
@ 2006-10-03 13:39 ` Stephane Doyon
0 siblings, 0 replies; 130+ messages in thread
From: Stephane Doyon @ 2006-10-03 13:39 UTC (permalink / raw)
To: Trond Myklebust, David Chinner; +Cc: xfs, nfs, Shailendra Tripathi
Sorry for insisting, but it seems to me there's still a problem in need of
fixing: when writing a 5GB file over NFS to an XFS file system and hitting
ENOSPC, it takes on the order of 22hours before my application gets an
error, whereas it would normally take about 2minutes if the file system
did not become full.
Perhaps I was being a bit too "constructive" and drowned my point in
explanations and proposed workarounds... You are telling me that neither
NFS nor XFS is doing anything wrong, and I can understand your points of
view, but surely that behavior isn't considered acceptable?
On Tue, 26 Sep 2006, Trond Myklebust wrote:
> On Tue, 2006-09-26 at 16:05 -0400, Stephane Doyon wrote:
>> I suppose it's not technically wrong to try to flush all the pages of the
>> file, but if the server file system is full then it will be at its worse.
>> Also if you happened to be on a slower link and have a big cache to flush,
>> you're waiting around for very little gain.
>
> That all assumes that nobody fixes the problem on the server. If
> somebody notices, and actually removes an unused file, then you may be
> happy that the kernel preserved the last 80% of the apache log file that
> was being written out.
>
> ENOSPC is a transient error: that is why the current behaviour exists.
On Tue, 3 Oct 2006, David Chinner wrote:
> This deep in the XFS allocation functions, we cannot tell if we hold
> the i_mutex or not, and it plays no part in determining if we have
> space or not. Hence we don't touch it here.
> I doubt it's a good idea for an NFS server, either.
[...]
> Remember that XFS, like most filesystems, trades off speed for
> correctness as we approach ENOSPC. Many parts of XFS slow down as we
> approach ENOSPC, and this is just one example of where we need to be
> correct, not fast.
[...]
> IMO, this is a non-problem. You're talking about optimising a
> relatively rare corner case where correctness is more important than
> speed and your test case is highly artificial. AFAIC, if you are
> running at ENOSPC then you get what performance is appropriate for
> correctness and if you are continually runing at ENOSPC, then buy
> some more disks.....
My recipe to reproduce the problem locally is admittedly somewhat
artificial, but the problematic usage definitely isn't: simply an app on
an NFS client that happens to fill up a file system. There must be some
way to handle this better.
Thanks
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
@ 2006-10-03 13:39 ` Stephane Doyon
0 siblings, 0 replies; 130+ messages in thread
From: Stephane Doyon @ 2006-10-03 13:39 UTC (permalink / raw)
To: Trond Myklebust, David Chinner; +Cc: nfs, Shailendra Tripathi, xfs
Sorry for insisting, but it seems to me there's still a problem in need of
fixing: when writing a 5GB file over NFS to an XFS file system and hitting
ENOSPC, it takes on the order of 22hours before my application gets an
error, whereas it would normally take about 2minutes if the file system
did not become full.
Perhaps I was being a bit too "constructive" and drowned my point in
explanations and proposed workarounds... You are telling me that neither
NFS nor XFS is doing anything wrong, and I can understand your points of
view, but surely that behavior isn't considered acceptable?
On Tue, 26 Sep 2006, Trond Myklebust wrote:
> On Tue, 2006-09-26 at 16:05 -0400, Stephane Doyon wrote:
>> I suppose it's not technically wrong to try to flush all the pages of the
>> file, but if the server file system is full then it will be at its worse.
>> Also if you happened to be on a slower link and have a big cache to flush,
>> you're waiting around for very little gain.
>
> That all assumes that nobody fixes the problem on the server. If
> somebody notices, and actually removes an unused file, then you may be
> happy that the kernel preserved the last 80% of the apache log file that
> was being written out.
>
> ENOSPC is a transient error: that is why the current behaviour exists.
On Tue, 3 Oct 2006, David Chinner wrote:
> This deep in the XFS allocation functions, we cannot tell if we hold
> the i_mutex or not, and it plays no part in determining if we have
> space or not. Hence we don't touch it here.
> I doubt it's a good idea for an NFS server, either.
[...]
> Remember that XFS, like most filesystems, trades off speed for
> correctness as we approach ENOSPC. Many parts of XFS slow down as we
> approach ENOSPC, and this is just one example of where we need to be
> correct, not fast.
[...]
> IMO, this is a non-problem. You're talking about optimising a
> relatively rare corner case where correctness is more important than
> speed and your test case is highly artificial. AFAIC, if you are
> running at ENOSPC then you get what performance is appropriate for
> correctness and if you are continually runing at ENOSPC, then buy
> some more disks.....
My recipe to reproduce the problem locally is admittedly somewhat
artificial, but the problematic usage definitely isn't: simply an app on
an NFS client that happens to fill up a file system. There must be some
way to handle this better.
Thanks
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
2006-10-03 13:39 ` Stephane Doyon
@ 2006-10-03 16:40 ` Trond Myklebust
-1 siblings, 0 replies; 130+ messages in thread
From: Trond Myklebust @ 2006-10-03 16:40 UTC (permalink / raw)
To: Stephane Doyon; +Cc: David Chinner, xfs, nfs, Shailendra Tripathi
On Tue, 2006-10-03 at 09:39 -0400, Stephane Doyon wrote:
> Sorry for insisting, but it seems to me there's still a problem in need of
> fixing: when writing a 5GB file over NFS to an XFS file system and hitting
> ENOSPC, it takes on the order of 22hours before my application gets an
> error, whereas it would normally take about 2minutes if the file system
> did not become full.
>
> Perhaps I was being a bit too "constructive" and drowned my point in
> explanations and proposed workarounds... You are telling me that neither
> NFS nor XFS is doing anything wrong, and I can understand your points of
> view, but surely that behavior isn't considered acceptable?
Sure it is. You are allowing the kernel to cache 5GB, and that means you
only get the error message when close() completes.
If you want faster error reporting, there are modes like O_SYNC,
O_DIRECT, that will attempt to flush the data more quickly. In addition,
you can force flushing using fsync(). Finally, you can tweak the VM into
flushing more often using /proc/sys/vm.
Cheers,
Trond
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
@ 2006-10-03 16:40 ` Trond Myklebust
0 siblings, 0 replies; 130+ messages in thread
From: Trond Myklebust @ 2006-10-03 16:40 UTC (permalink / raw)
To: Stephane Doyon; +Cc: David Chinner, nfs, Shailendra Tripathi, xfs
On Tue, 2006-10-03 at 09:39 -0400, Stephane Doyon wrote:
> Sorry for insisting, but it seems to me there's still a problem in need of
> fixing: when writing a 5GB file over NFS to an XFS file system and hitting
> ENOSPC, it takes on the order of 22hours before my application gets an
> error, whereas it would normally take about 2minutes if the file system
> did not become full.
>
> Perhaps I was being a bit too "constructive" and drowned my point in
> explanations and proposed workarounds... You are telling me that neither
> NFS nor XFS is doing anything wrong, and I can understand your points of
> view, but surely that behavior isn't considered acceptable?
Sure it is. You are allowing the kernel to cache 5GB, and that means you
only get the error message when close() completes.
If you want faster error reporting, there are modes like O_SYNC,
O_DIRECT, that will attempt to flush the data more quickly. In addition,
you can force flushing using fsync(). Finally, you can tweak the VM into
flushing more often using /proc/sys/vm.
Cheers,
Trond
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
2006-10-03 16:40 ` Trond Myklebust
@ 2006-10-05 15:39 ` Stephane Doyon
-1 siblings, 0 replies; 130+ messages in thread
From: Stephane Doyon @ 2006-10-05 15:39 UTC (permalink / raw)
To: Trond Myklebust; +Cc: David Chinner, xfs, nfs, Shailendra Tripathi
On Tue, 3 Oct 2006, Trond Myklebust wrote:
> On Tue, 2006-10-03 at 09:39 -0400, Stephane Doyon wrote:
>> Sorry for insisting, but it seems to me there's still a problem in need of
>> fixing: when writing a 5GB file over NFS to an XFS file system and hitting
>> ENOSPC, it takes on the order of 22hours before my application gets an
>> error, whereas it would normally take about 2minutes if the file system
>> did not become full.
>>
>> Perhaps I was being a bit too "constructive" and drowned my point in
>> explanations and proposed workarounds... You are telling me that neither
>> NFS nor XFS is doing anything wrong, and I can understand your points of
>> view, but surely that behavior isn't considered acceptable?
>
> Sure it is.
If you say so :-).
> You are allowing the kernel to cache 5GB, and that means you
> only get the error message when close() completes.
But it's not actually caching the entire 5GB at once... I guess you're
saying that doesn't matter...?
> If you want faster error reporting, there are modes like O_SYNC,
> O_DIRECT, that will attempt to flush the data more quickly. In addition,
> you can force flushing using fsync().
What if the program is a standard utility like cp?
> Finally, you can tweak the VM into
> flushing more often using /proc/sys/vm.
It doesn't look to me like a question of degrees about how early to flush.
Actually my client can't possibly be caching all of 5GB, it doesn't have
the RAM or swap for that. Tracing it more carefully, it appears dirty data
starts being flushed after a few hundred MBs. No error is returned on the
subsequent writes, only on the final close(). I see some of the write()
calls are delayed, presumably when the machine reaches the dirty
threshold. So I don't see how the vm settings can help in this case.
I hadn't realized that the issue isn't just with the final flush on
close(). It's actually been flushing all along, delaying some of the
subsequent write()s, getting NOSPC errors but not reporting them until the
end.
I understand that since my application did not request any syncing, the
system cannot guarantee to report errors until cached data has been
flushed. But some data has indeed been flushed with an error; can't this
be reported earlier than on close?
Would it be incorrect for a subsequent write to return the error that
occurred while flushing data from previous writes? Then the app could
decide whether to continue and retry or not. But I guess I can see how
that might get convoluted.
Thanks for your patience,
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
@ 2006-10-05 15:39 ` Stephane Doyon
0 siblings, 0 replies; 130+ messages in thread
From: Stephane Doyon @ 2006-10-05 15:39 UTC (permalink / raw)
To: Trond Myklebust; +Cc: David Chinner, nfs, Shailendra Tripathi, xfs
On Tue, 3 Oct 2006, Trond Myklebust wrote:
> On Tue, 2006-10-03 at 09:39 -0400, Stephane Doyon wrote:
>> Sorry for insisting, but it seems to me there's still a problem in need of
>> fixing: when writing a 5GB file over NFS to an XFS file system and hitting
>> ENOSPC, it takes on the order of 22hours before my application gets an
>> error, whereas it would normally take about 2minutes if the file system
>> did not become full.
>>
>> Perhaps I was being a bit too "constructive" and drowned my point in
>> explanations and proposed workarounds... You are telling me that neither
>> NFS nor XFS is doing anything wrong, and I can understand your points of
>> view, but surely that behavior isn't considered acceptable?
>
> Sure it is.
If you say so :-).
> You are allowing the kernel to cache 5GB, and that means you
> only get the error message when close() completes.
But it's not actually caching the entire 5GB at once... I guess you're
saying that doesn't matter...?
> If you want faster error reporting, there are modes like O_SYNC,
> O_DIRECT, that will attempt to flush the data more quickly. In addition,
> you can force flushing using fsync().
What if the program is a standard utility like cp?
> Finally, you can tweak the VM into
> flushing more often using /proc/sys/vm.
It doesn't look to me like a question of degrees about how early to flush.
Actually my client can't possibly be caching all of 5GB, it doesn't have
the RAM or swap for that. Tracing it more carefully, it appears dirty data
starts being flushed after a few hundred MBs. No error is returned on the
subsequent writes, only on the final close(). I see some of the write()
calls are delayed, presumably when the machine reaches the dirty
threshold. So I don't see how the vm settings can help in this case.
I hadn't realized that the issue isn't just with the final flush on
close(). It's actually been flushing all along, delaying some of the
subsequent write()s, getting NOSPC errors but not reporting them until the
end.
I understand that since my application did not request any syncing, the
system cannot guarantee to report errors until cached data has been
flushed. But some data has indeed been flushed with an error; can't this
be reported earlier than on close?
Would it be incorrect for a subsequent write to return the error that
occurred while flushing data from previous writes? Then the app could
decide whether to continue and retry or not. But I guess I can see how
that might get convoluted.
Thanks for your patience,
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
2006-10-05 15:39 ` Stephane Doyon
@ 2006-10-06 0:33 ` David Chinner
-1 siblings, 0 replies; 130+ messages in thread
From: David Chinner @ 2006-10-06 0:33 UTC (permalink / raw)
To: Stephane Doyon
Cc: Trond Myklebust, David Chinner, xfs, nfs, Shailendra Tripathi
On Thu, Oct 05, 2006 at 11:39:45AM -0400, Stephane Doyon wrote:
>
> I hadn't realized that the issue isn't just with the final flush on
> close(). It's actually been flushing all along, delaying some of the
> subsequent write()s, getting NOSPC errors but not reporting them until the
> end.
Other NFS clients will report an ENOSPC on the next write() or close()
if the error is reported during async writeback. The clients that typically
do this throw away any unwritten data as well on the basis that the
application was returned an error ASAP and it is now Somebody Else's
Problem (i.e. the application needs to handle it from there).
> I understand that since my application did not request any syncing, the
> system cannot guarantee to report errors until cached data has been
> flushed. But some data has indeed been flushed with an error; can't this
> be reported earlier than on close?
It could, but...
> Would it be incorrect for a subsequent write to return the error that
> occurred while flushing data from previous writes? Then the app could
> decide whether to continue and retry or not. But I guess I can see how
> that might get convoluted.
.... there's many entertaining hoops to jump through to do this
reliably.
FWIW, these are simply two different approaches to handling ENOSPC
(and other server) errors. Mostly it comes down to how the ppl who
implemented the NFS client think it's best to handle the errors in
the scenarios that they most care about.
For example: when you have large amounts of cached data, expedient
error reporting and tossing unwritten data leads to much faster
error recovery than trying to write every piece of data (hence the
Irix use of this method).
OTOH, when you really want as much of the data to get to the server,
regardless of whether you lose some (e.g. log files) before
reporting an error then you try to write every bit of data before
telling the application.
There's no clear right or wrong approach here - both have their
advantages and disadvantages for different workloads. If it
weren't for the sub-optimal behaviour of XFS in this case, you
probably wouldn't have even cared about this....
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
@ 2006-10-06 0:33 ` David Chinner
0 siblings, 0 replies; 130+ messages in thread
From: David Chinner @ 2006-10-06 0:33 UTC (permalink / raw)
To: Stephane Doyon
Cc: xfs, David Chinner, nfs, Shailendra Tripathi, Trond Myklebust
On Thu, Oct 05, 2006 at 11:39:45AM -0400, Stephane Doyon wrote:
>
> I hadn't realized that the issue isn't just with the final flush on
> close(). It's actually been flushing all along, delaying some of the
> subsequent write()s, getting NOSPC errors but not reporting them until the
> end.
Other NFS clients will report an ENOSPC on the next write() or close()
if the error is reported during async writeback. The clients that typically
do this throw away any unwritten data as well on the basis that the
application was returned an error ASAP and it is now Somebody Else's
Problem (i.e. the application needs to handle it from there).
> I understand that since my application did not request any syncing, the
> system cannot guarantee to report errors until cached data has been
> flushed. But some data has indeed been flushed with an error; can't this
> be reported earlier than on close?
It could, but...
> Would it be incorrect for a subsequent write to return the error that
> occurred while flushing data from previous writes? Then the app could
> decide whether to continue and retry or not. But I guess I can see how
> that might get convoluted.
.... there's many entertaining hoops to jump through to do this
reliably.
FWIW, these are simply two different approaches to handling ENOSPC
(and other server) errors. Mostly it comes down to how the ppl who
implemented the NFS client think it's best to handle the errors in
the scenarios that they most care about.
For example: when you have large amounts of cached data, expedient
error reporting and tossing unwritten data leads to much faster
error recovery than trying to write every piece of data (hence the
Irix use of this method).
OTOH, when you really want as much of the data to get to the server,
regardless of whether you lose some (e.g. log files) before
reporting an error then you try to write every bit of data before
telling the application.
There's no clear right or wrong approach here - both have their
advantages and disadvantages for different workloads. If it
weren't for the sub-optimal behaviour of XFS in this case, you
probably wouldn't have even cared about this....
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
2006-10-06 0:33 ` David Chinner
@ 2006-10-06 13:25 ` Stephane Doyon
-1 siblings, 0 replies; 130+ messages in thread
From: Stephane Doyon @ 2006-10-06 13:25 UTC (permalink / raw)
To: David Chinner; +Cc: Trond Myklebust, xfs, nfs, Shailendra Tripathi
On Fri, 6 Oct 2006, David Chinner wrote:
> On Thu, Oct 05, 2006 at 11:39:45AM -0400, Stephane Doyon wrote:
>>
>> I hadn't realized that the issue isn't just with the final flush on
>> close(). It's actually been flushing all along, delaying some of the
>> subsequent write()s, getting NOSPC errors but not reporting them until the
>> end.
>
> Other NFS clients will report an ENOSPC on the next write() or close()
> if the error is reported during async writeback. The clients that typically
> do this throw away any unwritten data as well on the basis that the
> application was returned an error ASAP and it is now Somebody Else's
> Problem (i.e. the application needs to handle it from there).
Well the client wouldn't necessarily have to throw away cached data. It
could conceivably be made to return ENOSPC on some subsequent write. It
would need to throw away the data for that write, but not necessarily
destroy its cache. It could then clear the error condition and allow the
application to keep trying if it wants to...
>> Would it be incorrect for a subsequent write to return the error that
>> occurred while flushing data from previous writes? Then the app could
>> decide whether to continue and retry or not. But I guess I can see how
>> that might get convoluted.
>
> .... there's many entertaining hoops to jump through to do this
> reliably.
I imagine there would be...
> For example: when you have large amounts of cached data, expedient
> error reporting and tossing unwritten data leads to much faster
> error recovery than trying to write every piece of data (hence the
> Irix use of this method).
In my case, I didn't think I was caching that much data though, only a few
hundred MBs, and I wouldn't have minded so much if an error had been
returned after that much. The way it's implemented though, I can write an
unbounded amount of data through that cache and not be told of the problem
until I close or fsync. It may not be technically wrong, but given the
outrageous delay I saw in my particular situation, it felt pretty
suboptimal.
> There's no clear right or wrong approach here - both have their
> advantages and disadvantages for different workloads. If it
> weren't for the sub-optimal behaviour of XFS in this case, you
> probably wouldn't have even cared about this....
Indeed not! In fact, changing the client is not practical for me, what I
need is a fix for the XFS behavior. I just thought it was also worth
reporting what I perceived to be an issue with the NFS client.
Thanks
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
@ 2006-10-06 13:25 ` Stephane Doyon
0 siblings, 0 replies; 130+ messages in thread
From: Stephane Doyon @ 2006-10-06 13:25 UTC (permalink / raw)
To: David Chinner; +Cc: xfs, nfs, Shailendra Tripathi, Trond Myklebust
On Fri, 6 Oct 2006, David Chinner wrote:
> On Thu, Oct 05, 2006 at 11:39:45AM -0400, Stephane Doyon wrote:
>>
>> I hadn't realized that the issue isn't just with the final flush on
>> close(). It's actually been flushing all along, delaying some of the
>> subsequent write()s, getting NOSPC errors but not reporting them until the
>> end.
>
> Other NFS clients will report an ENOSPC on the next write() or close()
> if the error is reported during async writeback. The clients that typically
> do this throw away any unwritten data as well on the basis that the
> application was returned an error ASAP and it is now Somebody Else's
> Problem (i.e. the application needs to handle it from there).
Well the client wouldn't necessarily have to throw away cached data. It
could conceivably be made to return ENOSPC on some subsequent write. It
would need to throw away the data for that write, but not necessarily
destroy its cache. It could then clear the error condition and allow the
application to keep trying if it wants to...
>> Would it be incorrect for a subsequent write to return the error that
>> occurred while flushing data from previous writes? Then the app could
>> decide whether to continue and retry or not. But I guess I can see how
>> that might get convoluted.
>
> .... there's many entertaining hoops to jump through to do this
> reliably.
I imagine there would be...
> For example: when you have large amounts of cached data, expedient
> error reporting and tossing unwritten data leads to much faster
> error recovery than trying to write every piece of data (hence the
> Irix use of this method).
In my case, I didn't think I was caching that much data though, only a few
hundred MBs, and I wouldn't have minded so much if an error had been
returned after that much. The way it's implemented though, I can write an
unbounded amount of data through that cache and not be told of the problem
until I close or fsync. It may not be technically wrong, but given the
outrageous delay I saw in my particular situation, it felt pretty
suboptimal.
> There's no clear right or wrong approach here - both have their
> advantages and disadvantages for different workloads. If it
> weren't for the sub-optimal behaviour of XFS in this case, you
> probably wouldn't have even cared about this....
Indeed not! In fact, changing the client is not practical for me, what I
need is a fix for the XFS behavior. I just thought it was also worth
reporting what I perceived to be an issue with the NFS client.
Thanks
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
2006-10-03 13:39 ` Stephane Doyon
@ 2006-10-05 8:30 ` David Chinner
-1 siblings, 0 replies; 130+ messages in thread
From: David Chinner @ 2006-10-05 8:30 UTC (permalink / raw)
To: Stephane Doyon
Cc: Trond Myklebust, David Chinner, xfs, nfs, Shailendra Tripathi
On Tue, Oct 03, 2006 at 09:39:55AM -0400, Stephane Doyon wrote:
> Sorry for insisting, but it seems to me there's still a problem in need of
> fixing: when writing a 5GB file over NFS to an XFS file system and hitting
> ENOSPC, it takes on the order of 22hours before my application gets an
> error, whereas it would normally take about 2minutes if the file system
> did not become full.
>
> Perhaps I was being a bit too "constructive" and drowned my point in
> explanations and proposed workarounds... You are telling me that neither
> NFS nor XFS is doing anything wrong, and I can understand your points of
> view, but surely that behavior isn't considered acceptable?
I agree that this a little extreme and I can't recall of seeing
anything like this before, but I can see how that may happen if the
NFS client continues to try to write every dirty page after getting
an ENOSPC and each one of those writes has to wait for 500ms.
However, you did not mention what kernel version you are running.
One recent bug (introduced by a fix for deadlocks at ENOSPC) could
allow oversubscription of free space to occur in XFS, resulting in
the write being allowed to proceed (i.e. sufficient space for the
data blocks) but then failing the allocation because there weren't
enough blocks put aside for potential btree splits that occur during
allocation. If the linux client is using sync writes on retry, then
this would trigger a 500ms sleep on every write. That's the right
sort of ballpark for the slowness you were seeing - 5GB / 32k * 0.5s
= ~22 hours....
This got fixed in 2.6.18-rc6 - can you retry with a 2.6.18 server
and see if your problem goes away?
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
@ 2006-10-05 8:30 ` David Chinner
0 siblings, 0 replies; 130+ messages in thread
From: David Chinner @ 2006-10-05 8:30 UTC (permalink / raw)
To: Stephane Doyon
Cc: xfs, David Chinner, nfs, Shailendra Tripathi, Trond Myklebust
On Tue, Oct 03, 2006 at 09:39:55AM -0400, Stephane Doyon wrote:
> Sorry for insisting, but it seems to me there's still a problem in need of
> fixing: when writing a 5GB file over NFS to an XFS file system and hitting
> ENOSPC, it takes on the order of 22hours before my application gets an
> error, whereas it would normally take about 2minutes if the file system
> did not become full.
>
> Perhaps I was being a bit too "constructive" and drowned my point in
> explanations and proposed workarounds... You are telling me that neither
> NFS nor XFS is doing anything wrong, and I can understand your points of
> view, but surely that behavior isn't considered acceptable?
I agree that this a little extreme and I can't recall of seeing
anything like this before, but I can see how that may happen if the
NFS client continues to try to write every dirty page after getting
an ENOSPC and each one of those writes has to wait for 500ms.
However, you did not mention what kernel version you are running.
One recent bug (introduced by a fix for deadlocks at ENOSPC) could
allow oversubscription of free space to occur in XFS, resulting in
the write being allowed to proceed (i.e. sufficient space for the
data blocks) but then failing the allocation because there weren't
enough blocks put aside for potential btree splits that occur during
allocation. If the linux client is using sync writes on retry, then
this would trigger a 500ms sleep on every write. That's the right
sort of ballpark for the slowness you were seeing - 5GB / 32k * 0.5s
= ~22 hours....
This got fixed in 2.6.18-rc6 - can you retry with a 2.6.18 server
and see if your problem goes away?
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
2006-10-05 8:30 ` David Chinner
@ 2006-10-05 16:33 ` Stephane Doyon
-1 siblings, 0 replies; 130+ messages in thread
From: Stephane Doyon @ 2006-10-05 16:33 UTC (permalink / raw)
To: David Chinner; +Cc: Trond Myklebust, xfs, nfs, Shailendra Tripathi
On Thu, 5 Oct 2006, David Chinner wrote:
> On Tue, Oct 03, 2006 at 09:39:55AM -0400, Stephane Doyon wrote:
>> Sorry for insisting, but it seems to me there's still a problem in need of
>> fixing: when writing a 5GB file over NFS to an XFS file system and hitting
>> ENOSPC, it takes on the order of 22hours before my application gets an
>> error, whereas it would normally take about 2minutes if the file system
>> did not become full.
>>
>> Perhaps I was being a bit too "constructive" and drowned my point in
>> explanations and proposed workarounds... You are telling me that neither
>> NFS nor XFS is doing anything wrong, and I can understand your points of
>> view, but surely that behavior isn't considered acceptable?
>
> I agree that this a little extreme and I can't recall of seeing
> anything like this before, but I can see how that may happen if the
> NFS client continues to try to write every dirty page after getting
> an ENOSPC and each one of those writes has to wait for 500ms.
>
> However, you did not mention what kernel version you are running.
> One recent bug (introduced by a fix for deadlocks at ENOSPC) could
> allow oversubscription of free space to occur in XFS, resulting in
I do have that fix in my kernel. (I'm the one who pointed you to the patch
that introduced that particular problem.)
> the write being allowed to proceed (i.e. sufficient space for the
> data blocks) but then failing the allocation because there weren't
> enough blocks put aside for potential btree splits that occur during
> allocation. If the linux client is using sync writes on retry, then
The writes from nfsd shouldn't be sync. Technically it's not even
retrying, just plowing on...
> this would trigger a 500ms sleep on every write. That's the right
> sort of ballpark for the slowness you were seeing - 5GB / 32k * 0.5s
> = ~22 hours....
>
> This got fixed in 2.6.18-rc6 -
You mean commit 4be536debe3f7b0c right? (Actually -rc7 I believe...) I do
have that one in my kernel. My kernel is 2.6.17 plus assorted XFS fixes.
> can you retry with a 2.6.18 server
> and see if your problem goes away?
Unfortunately it will be several days before I have a chance to do that.
The backtrace looked like this:
... nfsd_write nfsd_vfs_write vfs_writev do_readv_writev xfs_file_writev
xfs_write generic_file_buffered_write xfs_get_blocks __xfs_get_blocks
xfs_bmap xfs_iomap xfs_iomap_write_delay xfs_flush_space xfs_flush_device
schedule_timeout_uninterruptible.
with a 500ms sleep in xfs_flush_device().
Thanks
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
@ 2006-10-05 16:33 ` Stephane Doyon
0 siblings, 0 replies; 130+ messages in thread
From: Stephane Doyon @ 2006-10-05 16:33 UTC (permalink / raw)
To: David Chinner; +Cc: xfs, nfs, Shailendra Tripathi, Trond Myklebust
On Thu, 5 Oct 2006, David Chinner wrote:
> On Tue, Oct 03, 2006 at 09:39:55AM -0400, Stephane Doyon wrote:
>> Sorry for insisting, but it seems to me there's still a problem in need of
>> fixing: when writing a 5GB file over NFS to an XFS file system and hitting
>> ENOSPC, it takes on the order of 22hours before my application gets an
>> error, whereas it would normally take about 2minutes if the file system
>> did not become full.
>>
>> Perhaps I was being a bit too "constructive" and drowned my point in
>> explanations and proposed workarounds... You are telling me that neither
>> NFS nor XFS is doing anything wrong, and I can understand your points of
>> view, but surely that behavior isn't considered acceptable?
>
> I agree that this a little extreme and I can't recall of seeing
> anything like this before, but I can see how that may happen if the
> NFS client continues to try to write every dirty page after getting
> an ENOSPC and each one of those writes has to wait for 500ms.
>
> However, you did not mention what kernel version you are running.
> One recent bug (introduced by a fix for deadlocks at ENOSPC) could
> allow oversubscription of free space to occur in XFS, resulting in
I do have that fix in my kernel. (I'm the one who pointed you to the patch
that introduced that particular problem.)
> the write being allowed to proceed (i.e. sufficient space for the
> data blocks) but then failing the allocation because there weren't
> enough blocks put aside for potential btree splits that occur during
> allocation. If the linux client is using sync writes on retry, then
The writes from nfsd shouldn't be sync. Technically it's not even
retrying, just plowing on...
> this would trigger a 500ms sleep on every write. That's the right
> sort of ballpark for the slowness you were seeing - 5GB / 32k * 0.5s
> = ~22 hours....
>
> This got fixed in 2.6.18-rc6 -
You mean commit 4be536debe3f7b0c right? (Actually -rc7 I believe...) I do
have that one in my kernel. My kernel is 2.6.17 plus assorted XFS fixes.
> can you retry with a 2.6.18 server
> and see if your problem goes away?
Unfortunately it will be several days before I have a chance to do that.
The backtrace looked like this:
... nfsd_write nfsd_vfs_write vfs_writev do_readv_writev xfs_file_writev
xfs_write generic_file_buffered_write xfs_get_blocks __xfs_get_blocks
xfs_bmap xfs_iomap xfs_iomap_write_delay xfs_flush_space xfs_flush_device
schedule_timeout_uninterruptible.
with a 500ms sleep in xfs_flush_device().
Thanks
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
2006-10-05 16:33 ` Stephane Doyon
@ 2006-10-05 23:29 ` David Chinner
-1 siblings, 0 replies; 130+ messages in thread
From: David Chinner @ 2006-10-05 23:29 UTC (permalink / raw)
To: Stephane Doyon
Cc: David Chinner, Trond Myklebust, xfs, nfs, Shailendra Tripathi
On Thu, Oct 05, 2006 at 12:33:05PM -0400, Stephane Doyon wrote:
> retrying, just plowing on...
>
> >this would trigger a 500ms sleep on every write. That's the right
> >sort of ballpark for the slowness you were seeing - 5GB / 32k * 0.5s
> >= ~22 hours....
> >
> >This got fixed in 2.6.18-rc6 -
>
> You mean commit 4be536debe3f7b0c right? (Actually -rc7 I believe...) I do
> have that one in my kernel. My kernel is 2.6.17 plus assorted XFS fixes.
>
> >can you retry with a 2.6.18 server
> >and see if your problem goes away?
>
> Unfortunately it will be several days before I have a chance to do that.
>
> The backtrace looked like this:
>
> ... nfsd_write nfsd_vfs_write vfs_writev do_readv_writev xfs_file_writev
> xfs_write generic_file_buffered_write xfs_get_blocks __xfs_get_blocks
> xfs_bmap xfs_iomap xfs_iomap_write_delay xfs_flush_space xfs_flush_device
> schedule_timeout_uninterruptible.
Ahhh, this gets hit on the ->prepare_write path (xfs_iomap_write_delay()),
not the allocate path (xfs_iomap_write_allocate()). Sorry - I got myself
(and probably everyone else) confused there which why I suspected sync
writes - they trigger the allocate path in the write call. I don't think
2.6.18 will change anything.
FWIW, I don't think we can avoid this sleep when we first hit ENOSPC
conditions, but perhaps once we are certain of the ENOSPC status
we can tag the filesystem with this state (say an xfs_mount flag)
and only clear that tag when something is freed. We could then
use the tag to avoid continually trying extremely hard to allocate
space when we know there is none available....
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
@ 2006-10-05 23:29 ` David Chinner
0 siblings, 0 replies; 130+ messages in thread
From: David Chinner @ 2006-10-05 23:29 UTC (permalink / raw)
To: Stephane Doyon
Cc: xfs, David Chinner, nfs, Shailendra Tripathi, Trond Myklebust
On Thu, Oct 05, 2006 at 12:33:05PM -0400, Stephane Doyon wrote:
> retrying, just plowing on...
>
> >this would trigger a 500ms sleep on every write. That's the right
> >sort of ballpark for the slowness you were seeing - 5GB / 32k * 0.5s
> >= ~22 hours....
> >
> >This got fixed in 2.6.18-rc6 -
>
> You mean commit 4be536debe3f7b0c right? (Actually -rc7 I believe...) I do
> have that one in my kernel. My kernel is 2.6.17 plus assorted XFS fixes.
>
> >can you retry with a 2.6.18 server
> >and see if your problem goes away?
>
> Unfortunately it will be several days before I have a chance to do that.
>
> The backtrace looked like this:
>
> ... nfsd_write nfsd_vfs_write vfs_writev do_readv_writev xfs_file_writev
> xfs_write generic_file_buffered_write xfs_get_blocks __xfs_get_blocks
> xfs_bmap xfs_iomap xfs_iomap_write_delay xfs_flush_space xfs_flush_device
> schedule_timeout_uninterruptible.
Ahhh, this gets hit on the ->prepare_write path (xfs_iomap_write_delay()),
not the allocate path (xfs_iomap_write_allocate()). Sorry - I got myself
(and probably everyone else) confused there which why I suspected sync
writes - they trigger the allocate path in the write call. I don't think
2.6.18 will change anything.
FWIW, I don't think we can avoid this sleep when we first hit ENOSPC
conditions, but perhaps once we are certain of the ENOSPC status
we can tag the filesystem with this state (say an xfs_mount flag)
and only clear that tag when something is freed. We could then
use the tag to avoid continually trying extremely hard to allocate
space when we know there is none available....
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
2006-10-05 23:29 ` David Chinner
@ 2006-10-06 13:03 ` Stephane Doyon
-1 siblings, 0 replies; 130+ messages in thread
From: Stephane Doyon @ 2006-10-06 13:03 UTC (permalink / raw)
To: David Chinner; +Cc: Trond Myklebust, xfs, nfs, Shailendra Tripathi
On Fri, 6 Oct 2006, David Chinner wrote:
>> The backtrace looked like this:
>>
>> ... nfsd_write nfsd_vfs_write vfs_writev do_readv_writev xfs_file_writev
>> xfs_write generic_file_buffered_write xfs_get_blocks __xfs_get_blocks
>> xfs_bmap xfs_iomap xfs_iomap_write_delay xfs_flush_space xfs_flush_device
>> schedule_timeout_uninterruptible.
>
> Ahhh, this gets hit on the ->prepare_write path (xfs_iomap_write_delay()),
Yes.
> not the allocate path (xfs_iomap_write_allocate()). Sorry - I got myself
> (and probably everyone else) confused there which why I suspected sync
> writes - they trigger the allocate path in the write call. I don't think
> 2.6.18 will change anything.
>
> FWIW, I don't think we can avoid this sleep when we first hit ENOSPC
> conditions, but perhaps once we are certain of the ENOSPC status
> we can tag the filesystem with this state (say an xfs_mount flag)
> and only clear that tag when something is freed. We could then
> use the tag to avoid continually trying extremely hard to allocate
> space when we know there is none available....
Yes! That's what I was trying to suggest :-). Thank you.
Is that hard to do?
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
@ 2006-10-06 13:03 ` Stephane Doyon
0 siblings, 0 replies; 130+ messages in thread
From: Stephane Doyon @ 2006-10-06 13:03 UTC (permalink / raw)
To: David Chinner; +Cc: xfs, nfs, Shailendra Tripathi, Trond Myklebust
On Fri, 6 Oct 2006, David Chinner wrote:
>> The backtrace looked like this:
>>
>> ... nfsd_write nfsd_vfs_write vfs_writev do_readv_writev xfs_file_writev
>> xfs_write generic_file_buffered_write xfs_get_blocks __xfs_get_blocks
>> xfs_bmap xfs_iomap xfs_iomap_write_delay xfs_flush_space xfs_flush_device
>> schedule_timeout_uninterruptible.
>
> Ahhh, this gets hit on the ->prepare_write path (xfs_iomap_write_delay()),
Yes.
> not the allocate path (xfs_iomap_write_allocate()). Sorry - I got myself
> (and probably everyone else) confused there which why I suspected sync
> writes - they trigger the allocate path in the write call. I don't think
> 2.6.18 will change anything.
>
> FWIW, I don't think we can avoid this sleep when we first hit ENOSPC
> conditions, but perhaps once we are certain of the ENOSPC status
> we can tag the filesystem with this state (say an xfs_mount flag)
> and only clear that tag when something is freed. We could then
> use the tag to avoid continually trying extremely hard to allocate
> space when we know there is none available....
Yes! That's what I was trying to suggest :-). Thank you.
Is that hard to do?
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply [flat|nested] 130+ messages in thread
* Linux 2.6.16.4
@ 2006-04-11 17:33 Greg KH
2006-04-11 19:04 ` several messages Jan Engelhardt
0 siblings, 1 reply; 130+ messages in thread
From: Greg KH @ 2006-04-11 17:33 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: torvalds
We (the -stable team) are announcing the release of the 2.6.16.4 kernel.
The diffstat and short summary of the fixes are below.
I'll also be replying to this message with a copy of the patch between
2.6.16.3 and 2.6.16.4, as it is small enough to do so.
The updated 2.6.16.y git tree can be found at:
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.16.y.git
and can be browsed at the normal kernel.org git web browser:
www.kernel.org/git/
thanks,
greg k-h
--------
Makefile | 2 +-
kernel/signal.c | 1 -
2 files changed, 1 insertion(+), 2 deletions(-)
Summary of changes from v2.6.16.3 to v2.6.16.4
==============================================
Greg Kroah-Hartman:
Linux 2.6.16.4
Oleg Nesterov:
RCU signal handling [CVE-2006-1523]
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
2006-04-11 17:33 Linux 2.6.16.4 Greg KH
@ 2006-04-11 19:04 ` Jan Engelhardt
2006-04-11 19:20 ` Boris B. Zhmurov
2006-04-11 20:30 ` Greg KH
0 siblings, 2 replies; 130+ messages in thread
From: Jan Engelhardt @ 2006-04-11 19:04 UTC (permalink / raw)
To: Greg KH; +Cc: linux-kernel, stable, torvalds
>Date: Tue, 11 Apr 2006 09:26:20 -0700
>Subject: Linux 2.6.16.3
>David Howells:
> Keys: Fix oops when adding key to non-keyring [CVE-2006-1522]
>Date: Tue, 11 Apr 2006 10:33:23 -0700
>Subject: Linux 2.6.16.4
>Oleg Nesterov:
> RCU signal handling [CVE-2006-1523]
Now admins spend another hour this day just to upgrade.
These two patches could have been queued until the end of the day. Maybe
another one turns up soon.
Jan Engelhardt
--
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
2006-04-11 19:04 ` several messages Jan Engelhardt
@ 2006-04-11 19:20 ` Boris B. Zhmurov
2006-04-11 20:30 ` Greg KH
1 sibling, 0 replies; 130+ messages in thread
From: Boris B. Zhmurov @ 2006-04-11 19:20 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Greg KH, linux-kernel, stable, torvalds
Hello, Jan Engelhardt.
On 11.04.2006 23:04 you said the following:
> Now admins spend another hour this day just to upgrade.
It's admin's job, isn't it?
> These two patches could have been queued until the end of the day. Maybe
> another one turns up soon.
> Jan Engelhardt
Hmm... Interesting. Are you blaming security officers for doing their
job? Please, don't! And many many thanks to Greg for giving us security
patches as soon as possible.
--
Boris B. Zhmurov
mailto: bb@kernelpanic.ru
"wget http://kernelpanic.ru/bb_public_key.pgp -O - | gpg --import"
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
2006-04-11 19:04 ` several messages Jan Engelhardt
2006-04-11 19:20 ` Boris B. Zhmurov
@ 2006-04-11 20:30 ` Greg KH
2006-04-11 23:46 ` Jan Engelhardt
2006-04-12 0:36 ` Nix
1 sibling, 2 replies; 130+ messages in thread
From: Greg KH @ 2006-04-11 20:30 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: linux-kernel, stable, torvalds
On Tue, Apr 11, 2006 at 09:04:42PM +0200, Jan Engelhardt wrote:
>
> >Date: Tue, 11 Apr 2006 09:26:20 -0700
> >Subject: Linux 2.6.16.3
> >David Howells:
> > Keys: Fix oops when adding key to non-keyring [CVE-2006-1522]
>
> >Date: Tue, 11 Apr 2006 10:33:23 -0700
> >Subject: Linux 2.6.16.4
> >Oleg Nesterov:
> > RCU signal handling [CVE-2006-1523]
>
> Now admins spend another hour this day just to upgrade.
> These two patches could have been queued until the end of the day. Maybe
> another one turns up soon.
The first one went out last night, as it was a real issue that affected
people and I had already waited longer than I felt comfortable with, due
to travel issues I had (two different talks in two different cities in
two different days.)
The second one went out today, because it was reported today. Should I
have waited until tomorrow to see if something else came up?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
2006-04-11 20:30 ` Greg KH
@ 2006-04-11 23:46 ` Jan Engelhardt
2006-04-12 0:36 ` Nix
1 sibling, 0 replies; 130+ messages in thread
From: Jan Engelhardt @ 2006-04-11 23:46 UTC (permalink / raw)
To: Greg KH; +Cc: linux-kernel, stable, torvalds
>
>The first one went out last night, as it was a real issue that affected
>people and I had already waited longer than I felt comfortable with, due
>to travel issues I had (two different talks in two different cities in
>two different days.)
>
>The second one went out today, because it was reported today. Should I
>have waited until tomorrow to see if something else came up?
>
No of course not, I did not know the first one was already due long time.
[Sigh, pine changed the subject header and I did not notice.]
Jan Engelhardt
--
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
2006-04-11 20:30 ` Greg KH
2006-04-11 23:46 ` Jan Engelhardt
@ 2006-04-12 0:36 ` Nix
1 sibling, 0 replies; 130+ messages in thread
From: Nix @ 2006-04-12 0:36 UTC (permalink / raw)
To: Greg KH; +Cc: Jan Engelhardt, linux-kernel, stable, torvalds
On 11 Apr 2006, Greg KH whispered secretively:
> The first one went out last night, as it was a real issue that affected
> people and I had already waited longer than I felt comfortable with, due
> to travel issues I had (two different talks in two different cities in
> two different days.)
>
> The second one went out today, because it was reported today. Should I
> have waited until tomorrow to see if something else came up?
Indeed.
On top of that, they're `only' local DoSes, so many admins (i.e. those
without untrusted local users) will probably not have installed .3 yet:
and anyone with untrusted local users probably has someone whose entire
job is handling security anyway.
There's nothing wrong with rapid-fire -stables; either the issue is (in
the judgement of the ones doing the installation) critical, in which
case it should get out as fast as possible, or it isn't, in which case
the local installing admins can put it off for a day or so themselves to
see if another release comes out immediately afterwards.
--
`On a scale of 1-10, X's "brokenness rating" is 1.1, but that's only
because bringing Windows into the picture rescaled "brokenness" by
a factor of 10.' --- Peter da Silva
^ permalink raw reply [flat|nested] 130+ messages in thread
* ata over ethernet question
@ 2005-05-04 17:31 Maciej Soltysiak
2005-05-04 19:48 ` David Hollis
0 siblings, 1 reply; 130+ messages in thread
From: Maciej Soltysiak @ 2005-05-04 17:31 UTC (permalink / raw)
To: linux-kernel
Hi,
AOE is a bit new for me.
Would it be possible to use tha AOE driver to
attach one ATA drive in a host over ethernet to another
host ? Or is it support for specific hardware devices only?
You know, something like:
# fdisk <device_on_another_host>
# mkfs.ext2 <device_on_another_host/partition1>
# mount <device_on_another_host/partition1> /mnt/part1
--
Maciej
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: ata over ethernet question
2005-05-04 17:31 ata over ethernet question Maciej Soltysiak
@ 2005-05-04 19:48 ` David Hollis
2005-05-04 21:17 ` Re[2]: " Maciej Soltysiak
0 siblings, 1 reply; 130+ messages in thread
From: David Hollis @ 2005-05-04 19:48 UTC (permalink / raw)
To: Maciej Soltysiak; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1121 bytes --]
On Wed, 2005-05-04 at 19:31 +0200, Maciej Soltysiak wrote:
> Hi,
>
> AOE is a bit new for me.
>
> Would it be possible to use tha AOE driver to
> attach one ATA drive in a host over ethernet to another
> host ? Or is it support for specific hardware devices only?
>
> You know, something like:
> # fdisk <device_on_another_host>
> # mkfs.ext2 <device_on_another_host/partition1>
> # mount <device_on_another_host/partition1> /mnt/part1
>
That seems to be the basic idea but there doesn't seem to be a provider
stack just yet, just a 'client' (though I could be wrong). AOE is
similar in concept to iSCSI with the biggest difference being that AOE
runs over Ethernet and is thus non-routeable. iSCSI operates over IP so
you can do all kinds of fun IP games with it.
> --
> Maciej
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
David Hollis <dhollis@davehollis.com>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re[2]: ata over ethernet question
2005-05-04 19:48 ` David Hollis
@ 2005-05-04 21:17 ` Maciej Soltysiak
2005-05-05 15:09 ` David Hollis
0 siblings, 1 reply; 130+ messages in thread
From: Maciej Soltysiak @ 2005-05-04 21:17 UTC (permalink / raw)
To: linux-kernel
Hello David,
Wednesday, May 4, 2005, 9:48:36 PM, you wrote:
> That seems to be the basic idea but there doesn't seem to be a provider
> stack just yet, just a 'client' (though I could be wrong). AOE is
> similar in concept to iSCSI with the biggest difference being that AOE
> runs over Ethernet and is thus non-routeable. iSCSI operates over IP so
> you can do all kinds of fun IP games with it.
Thanks, this is interesting. Does the iSCSI implementation out there have
this provider stack ?
Regards,
Maciej
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Re[2]: ata over ethernet question
2005-05-04 21:17 ` Re[2]: " Maciej Soltysiak
@ 2005-05-05 15:09 ` David Hollis
2005-05-07 15:05 ` Sander
0 siblings, 1 reply; 130+ messages in thread
From: David Hollis @ 2005-05-05 15:09 UTC (permalink / raw)
To: Maciej Soltysiak; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1018 bytes --]
On Wed, 2005-05-04 at 23:17 +0200, Maciej Soltysiak wrote:
> Hello David,
>
> Wednesday, May 4, 2005, 9:48:36 PM, you wrote:
> > That seems to be the basic idea but there doesn't seem to be a provider
> > stack just yet, just a 'client' (though I could be wrong). AOE is
> > similar in concept to iSCSI with the biggest difference being that AOE
> > runs over Ethernet and is thus non-routeable. iSCSI operates over IP so
> > you can do all kinds of fun IP games with it.
> Thanks, this is interesting. Does the iSCSI implementation out there have
> this provider stack ?
>
> Regards,
> Maciej
There seem to be a few iSCSI implementations floating around for Linux,
hopefully one will be added to mainline soon. Most of those
implementations are for the client side though there is at least one
target implementation that allows you to provide local storage to iSCSI
clients. I don't remember the name of it or if it's still maintained or
not.
--
David Hollis <dhollis@davehollis.com>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Re[2]: ata over ethernet question
2005-05-05 15:09 ` David Hollis
@ 2005-05-07 15:05 ` Sander
2005-05-10 22:00 ` Guennadi Liakhovetski
0 siblings, 1 reply; 130+ messages in thread
From: Sander @ 2005-05-07 15:05 UTC (permalink / raw)
To: David Hollis; +Cc: Maciej Soltysiak, linux-kernel
David Hollis wrote (ao):
> There seem to be a few iSCSI implementations floating around for
> Linux, hopefully one will be added to mainline soon. Most of those
> implementations are for the client side though there is at least one
> target implementation that allows you to provide local storage to
> iSCSI clients. I don't remember the name of it or if it's still
> maintained or not.
Quite active even:
http://sourceforge.net/projects/iscsitarget/
The "Quick Guide to iSCSI on Linux" is a good starting point btw.
Also check out http://www.open-iscsi.org/ (the client, aka 'initiator').
--
Humilis IT Services and Solutions
http://www.humilis.net
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: Re[2]: ata over ethernet question
2005-05-07 15:05 ` Sander
@ 2005-05-10 22:00 ` Guennadi Liakhovetski
2005-05-11 8:56 ` Vladislav Bolkhovitin
0 siblings, 1 reply; 130+ messages in thread
From: Guennadi Liakhovetski @ 2005-05-10 22:00 UTC (permalink / raw)
To: Sander; +Cc: David Hollis, Maciej Soltysiak, linux-kernel, linux-scsi
Hi
On Sat, 7 May 2005, Sander wrote:
> David Hollis wrote (ao):
> > There seem to be a few iSCSI implementations floating around for
> > Linux, hopefully one will be added to mainline soon. Most of those
> > implementations are for the client side though there is at least one
> > target implementation that allows you to provide local storage to
> > iSCSI clients. I don't remember the name of it or if it's still
> > maintained or not.
>
> Quite active even:
>
> http://sourceforge.net/projects/iscsitarget/
>
> The "Quick Guide to iSCSI on Linux" is a good starting point btw.
>
> Also check out http://www.open-iscsi.org/ (the client, aka 'initiator').
A follow up question - I recently used nbd to access a CD-ROM. It worked
nice, but, I had to read in 7 CDs, so, each time I had to replace a CD, I
had to stop the client, the server, then replace the CD, re-start the
server, re-start the client... I thought about extending NBD to (better)
support removable media, but then you start thinking about all those
features that your local block device has that don't get exported over
NBD...
Now, my understanding (sorry, without looking at any docs - yet) is, that
iSCSI is (or at least should be) free from these limitations. So, does it
make any sense at all extending NBD or just switch to iSCSI? Should NBD be
just kept simple as it is or would it be completely superseeded by iSCSI,
or is there still something that NBD does that iSCSI wouldn't (easily) do?
Or am I completely misunderstanding what iSCSI target does?
Thanks
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: ata over ethernet question
2005-05-10 22:00 ` Guennadi Liakhovetski
@ 2005-05-11 8:56 ` Vladislav Bolkhovitin
2005-05-11 21:26 ` several messages Guennadi Liakhovetski
0 siblings, 1 reply; 130+ messages in thread
From: Vladislav Bolkhovitin @ 2005-05-11 8:56 UTC (permalink / raw)
To: Guennadi Liakhovetski
Cc: Sander, David Hollis, Maciej Soltysiak, FUJITA Tomonori,
linux-scsi, linux-kernel
Guennadi Liakhovetski wrote:
> Hi
>
> On Sat, 7 May 2005, Sander wrote:
>
>
>>David Hollis wrote (ao):
>>
>>>There seem to be a few iSCSI implementations floating around for
>>>Linux, hopefully one will be added to mainline soon. Most of those
>>>implementations are for the client side though there is at least one
>>>target implementation that allows you to provide local storage to
>>>iSCSI clients. I don't remember the name of it or if it's still
>>>maintained or not.
>>
>>Quite active even:
>>
>>http://sourceforge.net/projects/iscsitarget/
>>
>>The "Quick Guide to iSCSI on Linux" is a good starting point btw.
>>
>>Also check out http://www.open-iscsi.org/ (the client, aka 'initiator').
>
>
> A follow up question - I recently used nbd to access a CD-ROM. It worked
> nice, but, I had to read in 7 CDs, so, each time I had to replace a CD, I
> had to stop the client, the server, then replace the CD, re-start the
> server, re-start the client... I thought about extending NBD to (better)
> support removable media, but then you start thinking about all those
> features that your local block device has that don't get exported over
> NBD...
>
> Now, my understanding (sorry, without looking at any docs - yet) is, that
> iSCSI is (or at least should be) free from these limitations. So, does it
> make any sense at all extending NBD or just switch to iSCSI? Should NBD be
> just kept simple as it is or would it be completely superseeded by iSCSI,
> or is there still something that NBD does that iSCSI wouldn't (easily) do?
>
> Or am I completely misunderstanding what iSCSI target does?
Actually, this is property not of iSCSI target itself, but of any SCSI
target. So, we implemented it as part of our SCSI target mid-level
(SCST, http://scst.sourceforge.net), therefore any target driver working
over it will automatically benefit from this feature. Unfortunately,
currently available only target drivers for Qlogic 2x00 cards and for
poor UNH iSCSI target (that works not too reliable and only with very
specific initiators). The published version supports only real SCSI
CDROMs. CDROM FILEIO module, which allows exporting ISO images as SCSI
CDROM devices, going to be available not later end of May.
Vlad
> Thanks
> Guennadi
> ---
> Guennadi Liakhovetski
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
2005-05-11 8:56 ` Vladislav Bolkhovitin
@ 2005-05-11 21:26 ` Guennadi Liakhovetski
2005-05-12 2:16 ` Ming Zhang
2005-05-12 10:17 ` Vladislav Bolkhovitin
0 siblings, 2 replies; 130+ messages in thread
From: Guennadi Liakhovetski @ 2005-05-11 21:26 UTC (permalink / raw)
To: FUJITA Tomonori, Vladislav Bolkhovitin
Cc: iscsitarget-devel, linux-scsi, dmitry_yus, Sander, David Hollis,
Maciej Soltysiak, linux-kernel
Hello and thanks for the replies
On Wed, 11 May 2005, FUJITA Tomonori wrote:
> The iSCSI protocol simply encapsulates the SCSI protocol into the
> TCP/IP protocol, and carries packets over IP networks. You can handle
...
On Wed, 11 May 2005, Vladislav Bolkhovitin wrote:
> Actually, this is property not of iSCSI target itself, but of any SCSI target.
> So, we implemented it as part of our SCSI target mid-level (SCST,
> http://scst.sourceforge.net), therefore any target driver working over it will
> automatically benefit from this feature. Unfortunately, currently available
> only target drivers for Qlogic 2x00 cards and for poor UNH iSCSI target (that
> works not too reliable and only with very specific initiators). The published
...
The above confirms basically my understanding apart from one "minor"
confusion - I thought, that parallel to hardware solutions pure software
implementations were possible / being developed, like a driver, that
implements a SCSI LDD API on one side, and forwards packets to an IP
stack, say, over an ethernet card - on the initiator side. And a counter
part on the target side. Similarly to the USB mass-storage and storage
gadget drivers?
Thanks
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
2005-05-11 21:26 ` several messages Guennadi Liakhovetski
@ 2005-05-12 2:16 ` Ming Zhang
2005-05-12 18:32 ` Dmitry Yusupov
2005-05-12 10:17 ` Vladislav Bolkhovitin
1 sibling, 1 reply; 130+ messages in thread
From: Ming Zhang @ 2005-05-12 2:16 UTC (permalink / raw)
To: Guennadi Liakhovetski
Cc: FUJITA Tomonori, Vladislav Bolkhovitin, iet-dev, linux-scsi,
Dmitry Yusupov, Sander, David Hollis, Maciej Soltysiak,
linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1703 bytes --]
iscsi is scsi over ip.
usb disk is scsi over usb.
so just a different transport.
u are rite. ;)
ming
On Wed, 2005-05-11 at 23:26 +0200, Guennadi Liakhovetski wrote:
> Hello and thanks for the replies
>
> On Wed, 11 May 2005, FUJITA Tomonori wrote:
> > The iSCSI protocol simply encapsulates the SCSI protocol into the
> > TCP/IP protocol, and carries packets over IP networks. You can handle
> ...
>
> On Wed, 11 May 2005, Vladislav Bolkhovitin wrote:
> > Actually, this is property not of iSCSI target itself, but of any SCSI target.
> > So, we implemented it as part of our SCSI target mid-level (SCST,
> > http://scst.sourceforge.net), therefore any target driver working over it will
> > automatically benefit from this feature. Unfortunately, currently available
> > only target drivers for Qlogic 2x00 cards and for poor UNH iSCSI target (that
> > works not too reliable and only with very specific initiators). The published
> ...
>
> The above confirms basically my understanding apart from one "minor"
> confusion - I thought, that parallel to hardware solutions pure software
> implementations were possible / being developed, like a driver, that
> implements a SCSI LDD API on one side, and forwards packets to an IP
> stack, say, over an ethernet card - on the initiator side. And a counter
> part on the target side. Similarly to the USB mass-storage and storage
> gadget drivers?
>
> Thanks
> Guennadi
> ---
> Guennadi Liakhovetski
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
2005-05-12 2:16 ` Ming Zhang
@ 2005-05-12 18:32 ` Dmitry Yusupov
2005-05-13 8:12 ` Christoph Hellwig
0 siblings, 1 reply; 130+ messages in thread
From: Dmitry Yusupov @ 2005-05-12 18:32 UTC (permalink / raw)
To: mingz
Cc: Guennadi Liakhovetski, FUJITA Tomonori, Vladislav Bolkhovitin,
iet-dev, linux-scsi, Sander, David Hollis, Maciej Soltysiak,
linux-kernel
On Wed, 2005-05-11 at 22:16 -0400, Ming Zhang wrote:
> iscsi is scsi over ip.
correction. iSCSI today has RFC at least for two transports - TCP/IP and
iSER/RDMA(in finalized progress) with RDMA over Infiniband or RNIC. And
I think people start writing initial draft for SCTP/IP transport...
>From this perspective, iSCSI certainly more advanced and matured
comparing to NBD variations.
> usb disk is scsi over usb.
> so just a different transport.
> u are rite. ;)
>
> ming
>
> On Wed, 2005-05-11 at 23:26 +0200, Guennadi Liakhovetski wrote:
> > Hello and thanks for the replies
> >
> > On Wed, 11 May 2005, FUJITA Tomonori wrote:
> > > The iSCSI protocol simply encapsulates the SCSI protocol into the
> > > TCP/IP protocol, and carries packets over IP networks. You can handle
> > ...
> >
> > On Wed, 11 May 2005, Vladislav Bolkhovitin wrote:
> > > Actually, this is property not of iSCSI target itself, but of any SCSI target.
> > > So, we implemented it as part of our SCSI target mid-level (SCST,
> > > http://scst.sourceforge.net), therefore any target driver working over it will
> > > automatically benefit from this feature. Unfortunately, currently available
> > > only target drivers for Qlogic 2x00 cards and for poor UNH iSCSI target (that
> > > works not too reliable and only with very specific initiators). The published
> > ...
> >
> > The above confirms basically my understanding apart from one "minor"
> > confusion - I thought, that parallel to hardware solutions pure software
> > implementations were possible / being developed, like a driver, that
> > implements a SCSI LDD API on one side, and forwards packets to an IP
> > stack, say, over an ethernet card - on the initiator side. And a counter
> > part on the target side. Similarly to the USB mass-storage and storage
> > gadget drivers?
> >
> > Thanks
> > Guennadi
> > ---
> > Guennadi Liakhovetski
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
2005-05-12 18:32 ` Dmitry Yusupov
@ 2005-05-13 8:12 ` Christoph Hellwig
2005-05-13 15:04 ` Dmitry Yusupov
0 siblings, 1 reply; 130+ messages in thread
From: Christoph Hellwig @ 2005-05-13 8:12 UTC (permalink / raw)
To: Dmitry Yusupov
Cc: mingz, Guennadi Liakhovetski, FUJITA Tomonori,
Vladislav Bolkhovitin, iet-dev, linux-scsi, Sander, David Hollis,
Maciej Soltysiak, linux-kernel
On Thu, May 12, 2005 at 11:32:12AM -0700, Dmitry Yusupov wrote:
> On Wed, 2005-05-11 at 22:16 -0400, Ming Zhang wrote:
> > iscsi is scsi over ip.
>
> correction. iSCSI today has RFC at least for two transports - TCP/IP and
> iSER/RDMA(in finalized progress) with RDMA over Infiniband or RNIC. And
> I think people start writing initial draft for SCTP/IP transport...
>
> >From this perspective, iSCSI certainly more advanced and matured
> comparing to NBD variations.
It's for certainly much more complicated (in marketing speak that's usually
called advanced) but far less mature.
If you want network storage to just work use nbd.
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
2005-05-13 8:12 ` Christoph Hellwig
@ 2005-05-13 15:04 ` Dmitry Yusupov
2005-05-13 15:07 ` Christoph Hellwig
0 siblings, 1 reply; 130+ messages in thread
From: Dmitry Yusupov @ 2005-05-13 15:04 UTC (permalink / raw)
To: Christoph Hellwig
Cc: mingz, Guennadi Liakhovetski, FUJITA Tomonori,
Vladislav Bolkhovitin, iet-dev, linux-scsi, Sander, David Hollis,
Maciej Soltysiak, linux-kernel
On Fri, 2005-05-13 at 09:12 +0100, Christoph Hellwig wrote:
> On Thu, May 12, 2005 at 11:32:12AM -0700, Dmitry Yusupov wrote:
> > On Wed, 2005-05-11 at 22:16 -0400, Ming Zhang wrote:
> > > iscsi is scsi over ip.
> >
> > correction. iSCSI today has RFC at least for two transports - TCP/IP and
> > iSER/RDMA(in finalized progress) with RDMA over Infiniband or RNIC. And
> > I think people start writing initial draft for SCTP/IP transport...
> >
> > >From this perspective, iSCSI certainly more advanced and matured
> > comparing to NBD variations.
>
> It's for certainly much more complicated (in marketing speak that's usually
> called advanced) but far less mature.
>
> If you want network storage to just work use nbd.
You could tell this to school's computer class teacher... Serious SAN
deployment will always be based either on FC or iSCSI for the reasons I
explained before.
I do not disagree, nbd is nice and simple and for sure has its own
deployment space.
Dmitry
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
2005-05-13 15:04 ` Dmitry Yusupov
@ 2005-05-13 15:07 ` Christoph Hellwig
2005-05-13 15:38 ` Dmitry Yusupov
0 siblings, 1 reply; 130+ messages in thread
From: Christoph Hellwig @ 2005-05-13 15:07 UTC (permalink / raw)
To: Dmitry Yusupov
Cc: Christoph Hellwig, mingz, Guennadi Liakhovetski, FUJITA Tomonori,
Vladislav Bolkhovitin, iet-dev, linux-scsi, Sander, David Hollis,
Maciej Soltysiak, linux-kernel
On Fri, May 13, 2005 at 08:04:16AM -0700, Dmitry Yusupov wrote:
> You could tell this to school's computer class teacher... Serious SAN
> deployment will always be based either on FC or iSCSI for the reasons I
> explained before.
Just FYI Steeleye ships a very successful clustering product that builds
on nbd.
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
2005-05-13 15:07 ` Christoph Hellwig
@ 2005-05-13 15:38 ` Dmitry Yusupov
0 siblings, 0 replies; 130+ messages in thread
From: Dmitry Yusupov @ 2005-05-13 15:38 UTC (permalink / raw)
To: Christoph Hellwig
Cc: mingz, Guennadi Liakhovetski, FUJITA Tomonori,
Vladislav Bolkhovitin, iet-dev, linux-scsi, Sander, David Hollis,
Maciej Soltysiak, linux-kernel
On Fri, 2005-05-13 at 16:07 +0100, Christoph Hellwig wrote:
> On Fri, May 13, 2005 at 08:04:16AM -0700, Dmitry Yusupov wrote:
> > You could tell this to school's computer class teacher... Serious SAN
> > deployment will always be based either on FC or iSCSI for the reasons I
> > explained before.
>
> Just FYI Steeleye ships a very successful clustering product that builds
> on nbd.
AFAIK, it is used for Data Replication purposes only. Correct me if I'm
wrong...
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
2005-05-11 21:26 ` several messages Guennadi Liakhovetski
2005-05-12 2:16 ` Ming Zhang
@ 2005-05-12 10:17 ` Vladislav Bolkhovitin
1 sibling, 0 replies; 130+ messages in thread
From: Vladislav Bolkhovitin @ 2005-05-12 10:17 UTC (permalink / raw)
To: Guennadi Liakhovetski
Cc: FUJITA Tomonori, iscsitarget-devel, linux-scsi, dmitry_yus,
Sander, David Hollis, Maciej Soltysiak, linux-kernel
Guennadi Liakhovetski wrote:
> Hello and thanks for the replies
>
> On Wed, 11 May 2005, FUJITA Tomonori wrote:
>
>>The iSCSI protocol simply encapsulates the SCSI protocol into the
>>TCP/IP protocol, and carries packets over IP networks. You can handle
>
> ...
>
> On Wed, 11 May 2005, Vladislav Bolkhovitin wrote:
>
>>Actually, this is property not of iSCSI target itself, but of any SCSI target.
>>So, we implemented it as part of our SCSI target mid-level (SCST,
>>http://scst.sourceforge.net), therefore any target driver working over it will
>>automatically benefit from this feature. Unfortunately, currently available
>>only target drivers for Qlogic 2x00 cards and for poor UNH iSCSI target (that
>>works not too reliable and only with very specific initiators). The published
>
> ...
>
> The above confirms basically my understanding apart from one "minor"
> confusion - I thought, that parallel to hardware solutions pure software
> implementations were possible / being developed, like a driver, that
> implements a SCSI LDD API on one side, and forwards packets to an IP
> stack, say, over an ethernet card - on the initiator side. And a counter
> part on the target side. Similarly to the USB mass-storage and storage
> gadget drivers?
There is some confusion in the SCSI world between SCSI as a transport
and SCSI as a commands set and software communication protocol, which
works above the transport. So, you can implement SCSI transport at any
software (eg iSCSI) or hardware (parallel SCSI, Fibre Channel, SATA,
etc.) way, but if the SCSI message passing protocol is used overall
system remains SCSI with all protocol obligations like task management.
So, pure software SCSI solution is possible. BTW, there are pure
hardware iSCSI implementations as well.
Vlad
> Thanks
> Guennadi
> ---
> Guennadi Liakhovetski
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: 2.6.6-rc3-mm2 (4KSTACK)
@ 2004-05-11 8:45 Helge Hafting
2004-05-11 17:59 ` several messages Bill Davidsen
0 siblings, 1 reply; 130+ messages in thread
From: Helge Hafting @ 2004-05-11 8:45 UTC (permalink / raw)
To: Bill Davidsen; +Cc: linux-kernel
Bill Davidsen wrote:
> Arjan van de Ven wrote:
>
>>> It's probably a Bad Idea to push this to Linus before the vendors
>>> that have
>>> significant market-impact issues (again - anybody other than NVidia
>>> here?)
>>> have gotten their stuff cleaned up...
>>
>>
>>
>> Ok I don't want to start a flamewar but... Do we want to hold linux back
>> until all binary only module vendors have caught up ??
>
>
> My questions is, hold it back from what? Having the 4k option is fine,
> it's just eliminating the current default which I think is
> undesirable. I tried 4k stack, I couldn't measure any improvement in
> anything (as in no visible speedup or saving in memory).
The memory saving is usually modest: 4k per thread. It might make a
difference for
those with many thousands of threads. I believe this is unswappable
memory,
which is much more valuable than ordinary process memory.
More interesting is that it removes one way for fork() to fail. With 8k
stacks,
the new process needs to allocate two consecutive pages for those 8k. That
might be impossible due to fragmentation, even if there are megabytes of
free
memory. Such a problem usually only shows up after a long time. Now we
only need to
allocate a single page, which always works as long as there is any free
memory at all.
> For an embedded system, where space is tight and the code paths well
> known, sure, but I haven't been able to find or generate any objective
> improvement, other than some posts saying smaller is always better.
> Nothing slows a system down like a crash, even if it isn't followed by
> a restore from backup.
Consider the case when your server (web/mail/other) fails to fork, and then
you can't login because that requires fork() too. 4k stacks remove this
scenario,
and is a stability improvement.
Helge Hafting
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
2004-05-11 8:45 2.6.6-rc3-mm2 (4KSTACK) Helge Hafting
@ 2004-05-11 17:59 ` Bill Davidsen
0 siblings, 0 replies; 130+ messages in thread
From: Bill Davidsen @ 2004-05-11 17:59 UTC (permalink / raw)
To: Horst von Brand, Andrew Morton, Helge Hafting; +Cc: Linux Kernel Mailing List
Thank all of you for this information. This is an interesting way to
overcome the kernel memory fragmentation issue. I would have thought it
was more important to address having the memory so fragmented that there
is no 8k chunk left "even with many megabytes free" as someone wrote.
On Mon, 10 May 2004, Horst von Brand wrote:
> Bill Davidsen <davidsen@tmr.com> said:
>
> [...]
>
> > I tried 4k stack, I couldn't measure any improvement in anything (as in
> > no visible speedup or saving in memory).
>
> 4K stacks lets the kernel create new threads/processes as long as there is
> free memory; with 8K stacks it needs two consecutive free page frames in
> physical memory, when memory is fragmented (and large) they are hard to
> come by...
> --
> Dr. Horst H. von Brand User #22616 counter.li.org
> Departamento de Informatica Fono: +56 32 654431
> Universidad Tecnica Federico Santa Maria +56 32 654239
> Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
>
On Mon, 10 May 2004, Andrew Morton wrote:
> Horst von Brand <vonbrand@inf.utfsm.cl> wrote:
> >
> > Bill Davidsen <davidsen@tmr.com> said:
> >
> > [...]
> >
> > > I tried 4k stack, I couldn't measure any improvement in anything (as in
> > > no visible speedup or saving in memory).
> >
> > 4K stacks lets the kernel create new threads/processes as long as there is
> > free memory; with 8K stacks it needs two consecutive free page frames in
> > physical memory, when memory is fragmented (and large) they are hard to
> > come by...
>
> This is true to a surprising extent. A couple of weeks ago I observed my
> 256MB box freeing over 20MB of pages before it could successfully acquire a
> single 1-order page.
>
> That was during an updatedb run.
>
> And a 1-order GFP_NOFS allocation was actually livelocking, because
> !__GFP_FS allocations aren't allowed to enter dentry reclaim. Which is why
> VFS caches are now forced to use 0-order allocations.
>
>
On Tue, 11 May 2004, Helge Hafting wrote:
> Bill Davidsen wrote:
>
> > Arjan van de Ven wrote:
> >
> >>> It's probably a Bad Idea to push this to Linus before the vendors
> >>> that have
> >>> significant market-impact issues (again - anybody other than NVidia
> >>> here?)
> >>> have gotten their stuff cleaned up...
> >>
> >>
> >>
> >> Ok I don't want to start a flamewar but... Do we want to hold linux back
> >> until all binary only module vendors have caught up ??
> >
> >
> > My questions is, hold it back from what? Having the 4k option is fine,
> > it's just eliminating the current default which I think is
> > undesirable. I tried 4k stack, I couldn't measure any improvement in
> > anything (as in no visible speedup or saving in memory).
>
> The memory saving is usually modest: 4k per thread. It might make a
> difference for
> those with many thousands of threads. I believe this is unswappable
> memory,
> which is much more valuable than ordinary process memory.
>
> More interesting is that it removes one way for fork() to fail. With 8k
> stacks,
> the new process needs to allocate two consecutive pages for those 8k. That
> might be impossible due to fragmentation, even if there are megabytes of
> free
> memory. Such a problem usually only shows up after a long time. Now we
> only need to
> allocate a single page, which always works as long as there is any free
> memory at all.
>
> > For an embedded system, where space is tight and the code paths well
> > known, sure, but I haven't been able to find or generate any objective
> > improvement, other than some posts saying smaller is always better.
> > Nothing slows a system down like a crash, even if it isn't followed by
> > a restore from backup.
>
> Consider the case when your server (web/mail/other) fails to fork, and then
> you can't login because that requires fork() too. 4k stacks remove this
> scenario,
> and is a stability improvement.
>
> Helge Hafting
>
--
bill davidsen <davidsen@tmr.com>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: [patch] HT scheduler, sched-2.5.68-A9
@ 2003-04-22 10:34 Ingo Molnar
2003-04-22 22:16 ` several messages Bill Davidsen
0 siblings, 1 reply; 130+ messages in thread
From: Ingo Molnar @ 2003-04-22 10:34 UTC (permalink / raw)
To: Rick Lindsley; +Cc: linux-kernel
On Tue, 22 Apr 2003, Rick Lindsley wrote:
> Ingo, several questions.
>
> What makes this statement:
>
> * At this point it's sure that we have a SMT
> * imbalance: this (physical) CPU is idle but
> * another CPU has two (or more) tasks running.
>
> true? Do you mean "this cpu/sibling set are all idle but another
> cpu/sibling set are all non-idle"? [...]
yes, precisely.
> [...] Are we assuming that because both a physical processor and its
> sibling are not idle, that it is better to move a task from the sibling
> to a physical processor? In other words, we are presuming that the case
> where the task on the physical processor and the task(s) on the
> sibling(s) are actually benefitting from the relationship is rare?
yes. This 'un-sharing' of contexts happens unconditionally, whenever we
notice the situation. (ie. whenever a CPU goes completely idle and notices
an overloaded physical CPU.) On the HT system i have i have measure this
to be a beneficial move even for the most trivial things like infinite
loop-counting.
the more per-logical-CPU cache a given SMT implementation has, the less
beneficial this move becomes - in that case the system should rather be
set up as a NUMA topology and scheduled via the NUMA scheduler.
> * We wake up one of the migration threads (it
> * doesnt matter which one) and let it fix things up:
>
> So although a migration thread normally pulls tasks to it, we've altered
> migration_thread now so that when cpu_active_balance() is set for its
> cpu, it will go find a cpu/sibling set in which all siblings are busy
> (knowing it has a good chance of finding one), decrement nr_running in
> the runqueue it has found, call load_balance() on the queue which is
> idle, and hope that load_balance will again find the busy queue (the
> same queue as the migration thread's) and decide to move a task over?
yes.
> whew. So why are we perverting the migration thread to push rather than
> pull? If active_load_balance() finds a imbalance, why must we use such
> indirection? Why decrement nr_running? Couldn't we put together a
> migration_req_t for the target queue's migration thread?
i'm not sure what you mean by perverting the migration thread to push
rather to pull, as migration threads always push - it's not different in
this case either. Since the task in question is running in an
un-cooperative way at the moment of active-balancing, that CPU needs to
run the high-prio migration thread, which pushes the task to the proper
CPU after that point. [if the push is still necessary.]
we could use a migration_req_t for this, in theory, but active balancing
is independent of ->cpus_allowed, so some special code would still be
needed. Also, active balancing is non-queued by nature. Is there a big
difference?
> Making the migration thread TASK_UNINTERRUPTIBLE has the nasty side
> effect of artificially raising the load average. Why is this changed?
agreed, this is an oversight, i fixed it in my tree.
Ingo
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
2003-04-22 10:34 [patch] HT scheduler, sched-2.5.68-A9 Ingo Molnar
@ 2003-04-22 22:16 ` Bill Davidsen
2003-04-22 23:38 ` Rick Lindsley
0 siblings, 1 reply; 130+ messages in thread
From: Bill Davidsen @ 2003-04-22 22:16 UTC (permalink / raw)
To: Dave Jones, Ingo Molnar; +Cc: Rick Lindsley, linux-kernel
On Tue, 22 Apr 2003, Dave Jones wrote:
> On Mon, Apr 21, 2003 at 03:13:31PM -0400, Ingo Molnar wrote:
>
> > +/*
> > + * Is there a way to do this via Kconfig?
> > + */
> > +#if CONFIG_NR_SIBLINGS_2
> > +# define CONFIG_NR_SIBLINGS 2
> > +#elif CONFIG_NR_SIBLINGS_4
> > +# define CONFIG_NR_SIBLINGS 4
> > +#else
> > +# define CONFIG_NR_SIBLINGS 0
> > +#endif
> > +
>
> Maybe this would be better resolved at runtime ?
> With the above patch, you'd need three seperate kernel images
> to run optimally on a system in each of the cases.
> The 'vendor kernel' scenario here looks ugly to me.
>
> > +#if CONFIG_NR_SIBLINGS
> > +# define CONFIG_SHARE_RUNQUEUE 1
> > +#else
> > +# define CONFIG_SHARE_RUNQUEUE 0
> > +#endif
>
> And why can't this just be a
>
> if (ht_enabled)
> shared_runqueue = 1;
>
> Dumping all this into the config system seems to be the
> wrong direction IMHO. The myriad of runtime knobs in the
> scheduler already is bad enough, without introducing
> compile time ones as well.
May I add my "I don't understand this, either" at this point? It seems
desirable to have this particular value determined at runtime.
On Tue, 22 Apr 2003, Ingo Molnar wrote:
>
> On Tue, 22 Apr 2003, Rick Lindsley wrote:
> > [...] Are we assuming that because both a physical processor and its
> > sibling are not idle, that it is better to move a task from the sibling
> > to a physical processor? In other words, we are presuming that the case
> > where the task on the physical processor and the task(s) on the
> > sibling(s) are actually benefitting from the relationship is rare?
>
> yes. This 'un-sharing' of contexts happens unconditionally, whenever we
> notice the situation. (ie. whenever a CPU goes completely idle and notices
> an overloaded physical CPU.) On the HT system i have i have measure this
> to be a beneficial move even for the most trivial things like infinite
> loop-counting.
>
> the more per-logical-CPU cache a given SMT implementation has, the less
> beneficial this move becomes - in that case the system should rather be
> set up as a NUMA topology and scheduled via the NUMA scheduler.
Have you done any tests with a threaded process running on a single CPU in
the siblings? If they are sharing data and locks in the same cache it's
not obvious (to me at least) that it would be faster in two CPUs having to
do updates. That's a question, not an implication that it is significantly
better in just one, a threaded program with only two threads is not as
likely to be doing the same thing in both, perhaps.
--
bill davidsen <davidsen@tmr.com>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
2003-04-22 22:16 ` several messages Bill Davidsen
@ 2003-04-22 23:38 ` Rick Lindsley
2003-04-23 9:17 ` Ingo Molnar
0 siblings, 1 reply; 130+ messages in thread
From: Rick Lindsley @ 2003-04-22 23:38 UTC (permalink / raw)
To: Bill Davidsen; +Cc: Dave Jones, Ingo Molnar, linux-kernel
Have you done any tests with a threaded process running on a single CPU in
the siblings? If they are sharing data and locks in the same cache it's
not obvious (to me at least) that it would be faster in two CPUs having to
do updates. That's a question, not an implication that it is significantly
better in just one, a threaded program with only two threads is not as
likely to be doing the same thing in both, perhaps.
True. I have a hunch (and it's only a hunch -- no hard data!) that
two threads that are sharing the same data will do better if they can
be located on a physical/sibling processor group. For workloads where
you really do have two distinct processes, or even threads but which are
operating on wholly different portions of data or code, moving them to
separate physical processors may be warranted. The key is whether the
work of one sibling is destroying the cache of another.
Rick
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
2003-04-22 23:38 ` Rick Lindsley
@ 2003-04-23 9:17 ` Ingo Molnar
0 siblings, 0 replies; 130+ messages in thread
From: Ingo Molnar @ 2003-04-23 9:17 UTC (permalink / raw)
To: Rick Lindsley; +Cc: Bill Davidsen, Dave Jones, linux-kernel
On Tue, 22 Apr 2003, Rick Lindsley wrote:
> True. I have a hunch (and it's only a hunch -- no hard data!) that two
> threads that are sharing the same data will do better if they can be
> located on a physical/sibling processor group. For workloads where you
> really do have two distinct processes, or even threads but which are
> operating on wholly different portions of data or code, moving them to
> separate physical processors may be warranted. The key is whether the
> work of one sibling is destroying the cache of another.
If two threads have a workload that wants to be co-scheduled then the SMP
scheduler will do damage to them anyway - independently of any HT
scheduling decisions. One solution for such specific cases is to use the
CPU-binding API to move those threads to the same physical CPU. If there's
some common class of applications where this is the common case, then we
could start thinking about automatic support for them.
Ingo
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: ANN: LKMB (Linux Kernel Module Builder) version 0.1.16
@ 2003-01-23 0:20 Hal Duston
2003-01-27 16:46 ` several messages Bill Davidsen
0 siblings, 1 reply; 130+ messages in thread
From: Hal Duston @ 2003-01-23 0:20 UTC (permalink / raw)
To: linux-kernel
I use "INSTALL_MOD_PATH=put/the/modules/here/instead/of/lib/modules" in my
.profile or whatever in order to drop the modules into another directory
at "make modules_install" time. Is this one of the things folks are
talking about?
Hal Duston
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
2003-01-23 0:20 ANN: LKMB (Linux Kernel Module Builder) version 0.1.16 Hal Duston
@ 2003-01-27 16:46 ` Bill Davidsen
2003-01-27 16:59 ` David Woodhouse
0 siblings, 1 reply; 130+ messages in thread
From: Bill Davidsen @ 2003-01-27 16:46 UTC (permalink / raw)
To: David Woodhouse, Hal Duston; +Cc: linux-kernel, Olaf Titz
On Wed, 22 Jan 2003, David Woodhouse wrote:
>
> davidsen@tmr.com said:
> > `uname -r` is the kernel version of the running kernel. It is NOT by
> > magic the kernel version of the kernel you are building...
>
> Er, yes. And what's your point?
>
> There is _no_ magic that will find the kernel you want to build against
> today without any input from you. Using the build tree for the
> currently-running kernel, if installed in the standard place, is as good a
> default as any. Of course you should be permitted to override that default.
You make my point for me, there is no magic, and when building a module it
should require that the directory be specified by either a command line
option (as noted below) or by being built as part of a source tree. There
*is* no good default in that particular case.
On Wed, 22 Jan 2003, Hal Duston wrote:
> I use "INSTALL_MOD_PATH=put/the/modules/here/instead/of/lib/modules" in my
> .profile or whatever in order to drop the modules into another directory
> at "make modules_install" time. Is this one of the things folks are
> talking about?
Related for sure, the point I was making was that there is no good default
place to put modules built outside a kernel source tree (and probably also
when built for multiple kernels). I was suggesting that the module tree of
the running kernel might be a really poor choice. I don't think I was
clear in my first post, I was not suggesting a better default, I was
suggesting that any default is likely to bite.
I'm not unhappy that Mr. Woodhouse disagrees, I just think he missed my
point the first time and I'm trying to clarify.
--
bill davidsen <davidsen@tmr.com>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: several messages
2003-01-27 16:46 ` several messages Bill Davidsen
@ 2003-01-27 16:59 ` David Woodhouse
0 siblings, 0 replies; 130+ messages in thread
From: David Woodhouse @ 2003-01-27 16:59 UTC (permalink / raw)
To: Bill Davidsen; +Cc: Hal Duston, linux-kernel, Olaf Titz
davidsen@tmr.com said:
> You make my point for me, there is no magic, and when building a
> module it should require that the directory be specified by either a
> command line option (as noted below) or by being built as part of a
> source tree. There *is* no good default in that particular case.
/lib/modules/`uname -r`/build _is_ a good default for a module to build
again. It is correct in more cases than a simple failure to do anything.
For _installing_, the correct place to install the built objects is surely
/lib/modules/$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION) where the
variables are obtained from the top-level Makefile in the kernel sources
you built against.
You _default_ to building and installing for the current kernel, if it's
installed properly. But of course you should be permitted to override that
on the command line.
> Related for sure, the point I was making was that there is no good
> default place to put modules built outside a kernel source tree (and
> probably also when built for multiple kernels).
I disagree. Modutils will look in only one place -- the /lib/modules/...
directory corresponding to the kernel version for which you built each
module. Each module, therefore, should go into the directory corresponding
to the version of the kernel against which it was built.
Finding the appropriate _installation_ directory is trivial, surely? You
can even find it from the 'kernel_version' stamp _inside_ the object file,
without any other information?
--
dwmw2
^ permalink raw reply [flat|nested] 130+ messages in thread
end of thread, other threads:[~2023-06-16 22:54 UTC | newest]
Thread overview: 130+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-06-26 10:58 [PATCH] ARM: EXYNOS: Restore the entry address setup code post-resume Abhilash Kesavan
2014-06-26 10:58 ` Abhilash Kesavan
2014-06-26 12:25 ` Abhilash Kesavan
2014-06-26 12:25 ` Abhilash Kesavan
2014-06-26 14:35 ` Lorenzo Pieralisi
2014-06-26 14:35 ` Lorenzo Pieralisi
2014-06-26 14:53 ` Lorenzo Pieralisi
2014-06-26 14:53 ` Lorenzo Pieralisi
2014-06-26 20:06 ` Nicolas Pitre
2014-06-26 20:06 ` Nicolas Pitre
2014-06-27 1:49 ` Abhilash Kesavan
2014-06-27 1:49 ` Abhilash Kesavan
2014-06-30 18:28 ` [PATCH v2] ARM: EXYNOS: Use MCPM call-backs to support S2R on Exynos5420 Abhilash Kesavan
2014-06-30 18:28 ` Abhilash Kesavan
2014-07-01 4:19 ` Nicolas Pitre
2014-07-01 4:19 ` Nicolas Pitre
2014-07-01 13:14 ` Abhilash Kesavan
2014-07-01 13:14 ` Abhilash Kesavan
2014-07-01 13:50 ` Lorenzo Pieralisi
2014-07-01 13:50 ` Lorenzo Pieralisi
2014-07-01 20:02 ` Nicolas Pitre
2014-07-01 20:02 ` Nicolas Pitre
2014-07-02 14:59 ` [RFC PATCH v3] " Abhilash Kesavan
2014-07-02 14:59 ` Abhilash Kesavan
2014-07-03 5:02 ` [RFC PATCH v4] " Abhilash Kesavan
2014-07-03 5:02 ` Abhilash Kesavan
2014-07-03 13:29 ` Nicolas Pitre
2014-07-03 13:29 ` Nicolas Pitre
2014-07-03 14:46 ` Abhilash Kesavan
2014-07-03 14:46 ` Abhilash Kesavan
2014-07-03 14:46 ` [PATCH v5] " Abhilash Kesavan
2014-07-03 14:46 ` Abhilash Kesavan
2014-07-03 15:45 ` several messages Nicolas Pitre
2014-07-03 15:45 ` Nicolas Pitre
2014-07-03 16:19 ` Abhilash Kesavan
2014-07-03 16:19 ` Abhilash Kesavan
2014-07-03 19:00 ` Nicolas Pitre
2014-07-03 19:00 ` Nicolas Pitre
2014-07-03 20:00 ` Abhilash Kesavan
2014-07-03 20:00 ` Abhilash Kesavan
2014-07-04 4:13 ` Nicolas Pitre
2014-07-04 4:13 ` Nicolas Pitre
2014-07-04 17:45 ` Abhilash Kesavan
2014-07-04 17:45 ` Abhilash Kesavan
2014-07-04 17:47 ` [PATCH v6] ARM: EXYNOS: Use MCPM call-backs to support S2R on Exynos5420 Abhilash Kesavan
2014-07-04 17:47 ` Abhilash Kesavan
2014-07-04 19:45 ` [PATCH v7] " Abhilash Kesavan
2014-07-04 19:45 ` Abhilash Kesavan
2014-07-04 21:00 ` Nicolas Pitre
2014-07-04 21:00 ` Nicolas Pitre
2014-07-04 21:21 ` Abhilash Kesavan
2014-07-04 21:21 ` Abhilash Kesavan
2014-07-08 10:53 ` Lorenzo Pieralisi
2014-07-08 10:53 ` Lorenzo Pieralisi
2014-07-08 13:39 ` Abhilash Kesavan
2014-07-08 13:39 ` Abhilash Kesavan
2014-07-08 15:19 ` Lorenzo Pieralisi
2014-07-08 15:19 ` Lorenzo Pieralisi
-- strict thread matches above, loose matches on Subject: below --
2023-06-12 16:02 [PATCH mptcp-next] mptcp: drop legacy code Paolo Abeni
2023-06-13 17:37 ` mptcp: drop legacy code.: Tests Results MPTCP CI
2023-06-16 22:54 ` several messages Mat Martineau
2022-09-01 0:29 [PATCH 00/18] make test "linting" more comprehensive Eric Sunshine via GitGitGadget
2022-09-01 0:29 ` [PATCH 18/18] t: retire unused chainlint.sed Eric Sunshine via GitGitGadget
2022-09-02 12:42 ` several messages Johannes Schindelin
2022-09-02 18:16 ` Eric Sunshine
2022-09-02 18:34 ` Jeff King
2022-09-02 18:44 ` Junio C Hamano
2022-06-16 13:55 [PATCH mptcp-next] selftests: mptcp: tweak simult_flows for debug kernels Paolo Abeni
2022-06-16 15:27 ` selftests: mptcp: tweak simult_flows for debug kernels.: Tests Results MPTCP CI
2022-06-17 22:13 ` several messages Mat Martineau
2016-01-25 18:37 [PATCH v2 0/3] x86/mm: INVPCID support Andy Lutomirski
2016-01-25 18:57 ` Ingo Molnar
2016-01-27 10:09 ` several messages Thomas Gleixner
2016-01-27 10:09 ` Thomas Gleixner
2016-01-29 13:21 ` Borislav Petkov
2014-11-10 6:26 [PATCH 00/13] Add VT-d Posted-Interrupts support for KVM Feng Wu
2014-11-10 6:26 ` [PATCH 13/13] iommu/vt-d: Add a command line parameter for VT-d posted-interrupts Feng Wu
2014-11-10 18:15 ` several messages Thomas Gleixner
2014-11-10 18:15 ` Thomas Gleixner
2014-11-11 2:28 ` Jiang Liu
2014-11-11 2:28 ` Jiang Liu
2014-11-11 6:37 ` Wu, Feng
2014-11-11 6:37 ` Wu, Feng
2010-07-11 15:06 [PATCHv2] netfilter: add CHECKSUM target Michael S. Tsirkin
2010-07-11 15:14 ` [PATCHv3] extensions: libxt_CHECKSUM extension Michael S. Tsirkin
2010-07-15 9:39 ` Patrick McHardy
2010-07-15 10:17 ` several messages Jan Engelhardt
2009-09-06 14:16 Layla 3G does not recover from ACPI Suspend Mark Hills
2009-09-08 19:32 ` Giuliano Pochini
2009-09-08 22:56 ` several messages Mark Hills
2009-02-09 20:57 [PATCH] libxtables: Introduce global params structuring jamal
2009-02-09 21:04 ` several messages Jan Engelhardt
2009-02-09 21:27 ` jamal
2009-02-09 21:44 ` Jan Engelhardt
2008-11-26 14:33 [PATCH 0/1] HID: hid_apple is not used for apple alu wireless keyboards Jan Scholz
2008-11-26 14:33 ` [PATCH 1/1] HID: Apple alu wireless keyboards are bluetooth devices Jan Scholz
2008-11-26 14:54 ` Jiri Kosina
2008-11-26 15:17 ` Jan Scholz
2008-11-26 15:33 ` Jiri Kosina
2008-11-26 21:06 ` Tobias Müller
2008-11-27 0:57 ` several messages Jiri Kosina
2008-10-19 14:15 [PATCH 1/2] HID: add hid_type Jiri Slaby
2008-10-19 14:15 ` [PATCH 2/2] HID: fix appletouch regression Jiri Slaby
2008-10-19 19:40 ` several messages Jiri Kosina
2008-10-19 20:06 ` Justin Mattock
2008-10-19 20:06 ` Justin Mattock
2008-10-19 22:09 ` Jiri Slaby
[not found] <9E397A467F4DB34884A1FD0D5D27CF43018903F96E@msxaoa4.twosigma.com>
2008-06-12 16:54 ` Benjamin L. Shi
[not found] <200702211929.17203.david-b@pacbell.net>
2007-02-22 3:50 ` [patch 6/6] rtc suspend()/resume() restores system clock David Brownell
2007-02-22 22:58 ` several messages Guennadi Liakhovetski
2007-02-22 22:58 ` Guennadi Liakhovetski
2007-02-22 22:58 ` Guennadi Liakhovetski
2007-02-23 1:15 ` David Brownell
2007-02-23 1:15 ` David Brownell
2007-02-23 1:15 ` David Brownell
2007-02-23 11:17 ` Johannes Berg
2007-02-23 11:17 ` Johannes Berg
2007-02-23 11:17 ` Johannes Berg
2006-09-26 18:51 Long sleep with i_mutex in xfs_flush_device(), affects NFS service Stephane Doyon
2006-09-27 11:33 ` Shailendra Tripathi
2006-10-02 14:45 ` Stephane Doyon
2006-10-02 22:30 ` David Chinner
2006-10-03 13:39 ` several messages Stephane Doyon
2006-10-03 13:39 ` Stephane Doyon
2006-10-03 16:40 ` Trond Myklebust
2006-10-03 16:40 ` Trond Myklebust
2006-10-05 15:39 ` Stephane Doyon
2006-10-05 15:39 ` Stephane Doyon
2006-10-06 0:33 ` David Chinner
2006-10-06 0:33 ` David Chinner
2006-10-06 13:25 ` Stephane Doyon
2006-10-06 13:25 ` Stephane Doyon
2006-10-05 8:30 ` David Chinner
2006-10-05 8:30 ` David Chinner
2006-10-05 16:33 ` Stephane Doyon
2006-10-05 16:33 ` Stephane Doyon
2006-10-05 23:29 ` David Chinner
2006-10-05 23:29 ` David Chinner
2006-10-06 13:03 ` Stephane Doyon
2006-10-06 13:03 ` Stephane Doyon
2006-04-11 17:33 Linux 2.6.16.4 Greg KH
2006-04-11 19:04 ` several messages Jan Engelhardt
2006-04-11 19:20 ` Boris B. Zhmurov
2006-04-11 20:30 ` Greg KH
2006-04-11 23:46 ` Jan Engelhardt
2006-04-12 0:36 ` Nix
2005-05-04 17:31 ata over ethernet question Maciej Soltysiak
2005-05-04 19:48 ` David Hollis
2005-05-04 21:17 ` Re[2]: " Maciej Soltysiak
2005-05-05 15:09 ` David Hollis
2005-05-07 15:05 ` Sander
2005-05-10 22:00 ` Guennadi Liakhovetski
2005-05-11 8:56 ` Vladislav Bolkhovitin
2005-05-11 21:26 ` several messages Guennadi Liakhovetski
2005-05-12 2:16 ` Ming Zhang
2005-05-12 18:32 ` Dmitry Yusupov
2005-05-13 8:12 ` Christoph Hellwig
2005-05-13 15:04 ` Dmitry Yusupov
2005-05-13 15:07 ` Christoph Hellwig
2005-05-13 15:38 ` Dmitry Yusupov
2005-05-12 10:17 ` Vladislav Bolkhovitin
2004-05-11 8:45 2.6.6-rc3-mm2 (4KSTACK) Helge Hafting
2004-05-11 17:59 ` several messages Bill Davidsen
2003-04-22 10:34 [patch] HT scheduler, sched-2.5.68-A9 Ingo Molnar
2003-04-22 22:16 ` several messages Bill Davidsen
2003-04-22 23:38 ` Rick Lindsley
2003-04-23 9:17 ` Ingo Molnar
2003-01-23 0:20 ANN: LKMB (Linux Kernel Module Builder) version 0.1.16 Hal Duston
2003-01-27 16:46 ` several messages Bill Davidsen
2003-01-27 16:59 ` David Woodhouse
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.