[alsa-devel] [PATCH 2/2] sh: ms7724se: Add runtime PM support for FSI
Signed-off-by: Kuninori Morimoto morimoto.kuninori@renesas.com --- arch/sh/boards/mach-se/7724/setup.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/sh/boards/mach-se/7724/setup.c b/arch/sh/boards/mach-se/7724/setup.c index e78c3be..0894bba 100644 --- a/arch/sh/boards/mach-se/7724/setup.c +++ b/arch/sh/boards/mach-se/7724/setup.c @@ -313,6 +313,9 @@ static struct platform_device fsi_device = { .dev = { .platform_data = &fsi_info, }, + .archdata = { + .hwblk_id = HWBLK_SPU, /* FSI needs SPU hwblk */ + }, };
/* KEYSC in SoC (Needs SW33-2 set to ON) */
On Mon, Nov 09, 2009 at 11:12:39AM +0900, Kuninori Morimoto wrote:
This patch add support runtime PM. Driver callbacks for Runtime PM are empty because the device registers are always re-initialized after pm_runtime_get_sync(). The Runtime PM functions replaces the clock framework module stop bit handling in this driver.
Signed-off-by: Kuninori Morimoto morimoto.kuninori@renesas.com Signed-off-by: Magnus Damm damm@opensource.se
On Mon, Nov 09, 2009 at 11:12:49AM +0900, Kuninori Morimoto wrote:
Signed-off-by: Kuninori Morimoto morimoto.kuninori@renesas.com
arch/sh/boards/mach-se/7724/setup.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-)
These look fine, I'll queue them up.
On Tue, Nov 10, 2009 at 08:14:08AM +0900, Paul Mundt wrote:
On Mon, Nov 09, 2009 at 11:12:39AM +0900, Kuninori Morimoto wrote:
This patch add support runtime PM. Driver callbacks for Runtime PM are empty because the device registers are always re-initialized after pm_runtime_get_sync(). The Runtime PM functions replaces the clock framework module stop bit handling in this driver.
Signed-off-by: Kuninori Morimoto morimoto.kuninori@renesas.com Signed-off-by: Magnus Damm damm@opensource.se
On Mon, Nov 09, 2009 at 11:12:49AM +0900, Kuninori Morimoto wrote:
Signed-off-by: Kuninori Morimoto morimoto.kuninori@renesas.com
arch/sh/boards/mach-se/7724/setup.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-)
These look fine, I'll queue them up.
Upon a closer look, it seems this is built on top of earlier changes in the ASoC tree, so they should probably go through there so we don't end up with the merge conflict later.
The board setup bits are harmless and shouldn't conflict with anything in my tree, so there's no problem with taken both of these through the ASoC tree.
Acked-by: Paul Mundt lethal@linux-sh.org
participants (2)
-
Kuninori Morimoto -
Paul Mundt