From: sylvain.rochet@finsecur.com (Sylvain Rochet)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/6] pm: at91: move the copying the sram function to the sram initializationi phase
Date: Sat, 7 Mar 2015 00:22:24 +0100 [thread overview]
Message-ID: <20150306232224.GA7475@gradator.net> (raw)
In-Reply-To: <1423709209-8108-1-git-send-email-wenyou.yang@atmel.com>
Hello Wenyou,
On Thu, Feb 12, 2015 at 10:46:49AM +0800, Wenyou Yang wrote:
> To decrease the suspend time, move copying the sram function to the sram
> initialization phase, instead of every time go to suspend.
>
> In the meanwhile, substitute fncpy() for memcpy().
>
> If there is no sram allocated for PM, the PM is not supported.
My board doesn't boot anymore with this change, I am not equipped enough
to debug more, looks like fncpy() is writing the function on top of
existing kernel code.
You said you had issues with fncpy(), I guess I am having the issue you
had.
Moving the function copy from at91_pm_sram_init() to at91_pm_suspend()
fixes the problem:
-------------------------8<-----------------------------------
diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 9d74c85..31339b0 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -155,6 +155,10 @@ static void at91_pm_suspend(suspend_state_t state)
flush_cache_all();
outer_disable();
+ /* Copy the pm suspend handler to SRAM */
+ at91_suspend_sram_fn = fncpy(at91_suspend_sram_fn,
+ &at91_pm_suspend_in_sram, at91_pm_suspend_in_sram_sz);
+
at91_suspend_sram_fn(at91_pmc_base, at91_ramc_base[0],
at91_ramc_base[1], pm_data);
@@ -305,10 +309,6 @@ static void __init at91_pm_sram_init(void)
pr_warn("SRAM: Could not map\n");
return;
}
-
- /* Copy the pm suspend handler to SRAM */
- at91_suspend_sram_fn = fncpy(at91_suspend_sram_fn,
- &at91_pm_suspend_in_sram, at91_pm_suspend_in_sram_sz);
}
static void __init at91_pm_init(void)
-------------------------8<-----------------------------------
Or using memcpy() instead of fncpy() also fixes the problem:
-------------------------8<-----------------------------------
diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 9d74c85..feab89a 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -307,8 +307,8 @@ static void __init at91_pm_sram_init(void)
}
/* Copy the pm suspend handler to SRAM */
- at91_suspend_sram_fn = fncpy(at91_suspend_sram_fn,
- &at91_pm_suspend_in_sram, at91_pm_suspend_in_sram_sz);
+ memcpy(at91_suspend_sram_fn, at91_pm_suspend_in_sram,
+ at91_pm_suspend_in_sram_sz);
}
static void __init at91_pm_init(void)
-------------------------8<-----------------------------------
It works and fixes the hard fault, but I have no clue why :(
Sylvain
WARNING: multiple messages have this Message-ID (diff)
From: Sylvain Rochet <sylvain.rochet@finsecur.com>
To: Wenyou Yang <wenyou.yang@atmel.com>
Cc: nicolas.ferre@atmel.com, linux@maxim.org.za,
linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org,
alexandre.belloni@free-electrons.com, patrice.vilchez@atmel.com,
sergei.shtylyov@cogentembedded.com, mark.rutland@arm.com,
lorenzo.pieralisi@arm.com
Subject: Re: [PATCH 2/6] pm: at91: move the copying the sram function to the sram initializationi phase
Date: Sat, 7 Mar 2015 00:22:24 +0100 [thread overview]
Message-ID: <20150306232224.GA7475@gradator.net> (raw)
In-Reply-To: <1423709209-8108-1-git-send-email-wenyou.yang@atmel.com>
Hello Wenyou,
On Thu, Feb 12, 2015 at 10:46:49AM +0800, Wenyou Yang wrote:
> To decrease the suspend time, move copying the sram function to the sram
> initialization phase, instead of every time go to suspend.
>
> In the meanwhile, substitute fncpy() for memcpy().
>
> If there is no sram allocated for PM, the PM is not supported.
My board doesn't boot anymore with this change, I am not equipped enough
to debug more, looks like fncpy() is writing the function on top of
existing kernel code.
You said you had issues with fncpy(), I guess I am having the issue you
had.
Moving the function copy from at91_pm_sram_init() to at91_pm_suspend()
fixes the problem:
-------------------------8<-----------------------------------
diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 9d74c85..31339b0 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -155,6 +155,10 @@ static void at91_pm_suspend(suspend_state_t state)
flush_cache_all();
outer_disable();
+ /* Copy the pm suspend handler to SRAM */
+ at91_suspend_sram_fn = fncpy(at91_suspend_sram_fn,
+ &at91_pm_suspend_in_sram, at91_pm_suspend_in_sram_sz);
+
at91_suspend_sram_fn(at91_pmc_base, at91_ramc_base[0],
at91_ramc_base[1], pm_data);
@@ -305,10 +309,6 @@ static void __init at91_pm_sram_init(void)
pr_warn("SRAM: Could not map\n");
return;
}
-
- /* Copy the pm suspend handler to SRAM */
- at91_suspend_sram_fn = fncpy(at91_suspend_sram_fn,
- &at91_pm_suspend_in_sram, at91_pm_suspend_in_sram_sz);
}
static void __init at91_pm_init(void)
-------------------------8<-----------------------------------
Or using memcpy() instead of fncpy() also fixes the problem:
-------------------------8<-----------------------------------
diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 9d74c85..feab89a 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -307,8 +307,8 @@ static void __init at91_pm_sram_init(void)
}
/* Copy the pm suspend handler to SRAM */
- at91_suspend_sram_fn = fncpy(at91_suspend_sram_fn,
- &at91_pm_suspend_in_sram, at91_pm_suspend_in_sram_sz);
+ memcpy(at91_suspend_sram_fn, at91_pm_suspend_in_sram,
+ at91_pm_suspend_in_sram_sz);
}
static void __init at91_pm_init(void)
-------------------------8<-----------------------------------
It works and fixes the hard fault, but I have no clue why :(
Sylvain
next prev parent reply other threads:[~2015-03-06 23:22 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-12 2:45 [PATCH 0/6] AT91 pm improvement for 3.21 Wenyou Yang
2015-02-12 2:45 ` Wenyou Yang
2015-02-12 2:46 ` [PATCH 1/6] pm: at91: pm_slowclock: create the procedure to handle the sdram self-refresh Wenyou Yang
2015-02-12 2:46 ` Wenyou Yang
2015-02-12 2:46 ` [PATCH 2/6] pm: at91: move the copying the sram function to the sram initializationi phase Wenyou Yang
2015-02-12 2:46 ` Wenyou Yang
2015-03-06 23:22 ` Sylvain Rochet [this message]
2015-03-06 23:22 ` Sylvain Rochet
2015-03-12 18:53 ` Sylvain Rochet
2015-03-12 18:53 ` Sylvain Rochet
2015-02-12 2:47 ` [PATCH 3/6] pm: at91: standby mode uses the same sram function as suspend to memory mode Wenyou Yang
2015-02-12 2:47 ` Wenyou Yang
2015-02-12 2:48 ` [PATCH 4/6] pm: at91: rename file name: pm_slowclock.S -->pm_suspend.S Wenyou Yang
2015-02-12 2:48 ` Wenyou Yang
2015-02-12 2:48 ` [PATCH 5/6] pm: at91: rename function name: at91_slow_clock()-->at91_pm_suspend_sram_fn Wenyou Yang
2015-02-12 2:48 ` Wenyou Yang
2015-02-12 2:49 ` [PATCH 6/6] pm: at91: remove the at91_xxx_standby() function definitions Wenyou Yang
2015-02-12 2:49 ` Wenyou Yang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150306232224.GA7475@gradator.net \
--to=sylvain.rochet@finsecur.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is 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.