Re: [PATCH 6/7] ARM: mvebu: remove unused mach/gpio.h
Hi Arnd, On mar., déc. 01 2015, Arnd Bergmann <a...@arndb.de> wrote: > This file was left over from a cleanup of asm/gpio.h and has > not been used in a while. Let's just remove it now, so the > arch/arm/mach-mvebu/include/ directory can also disappear. > > Signed-off-by: Arnd Bergmann <a...@arndb.de> Applied on mvebu/cleanup Thanks, Gregory > --- > arch/arm/mach-mvebu/include/mach/gpio.h | 1 - > 1 file changed, 1 deletion(-) > delete mode 100644 arch/arm/mach-mvebu/include/mach/gpio.h > > diff --git a/arch/arm/mach-mvebu/include/mach/gpio.h > b/arch/arm/mach-mvebu/include/mach/gpio.h > deleted file mode 100644 > index 40a8c178f10d.. > --- a/arch/arm/mach-mvebu/include/mach/gpio.h > +++ /dev/null > @@ -1 +0,0 @@ > -/* empty */ > -- > 2.1.0.rc2 > -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] ARM: mvebu: remove the workaround imprecise abort fault handler
Hi Lucas, On mer., oct. 14 2015, Thomas Petazzoni <thomas.petazz...@free-electrons.com> wrote: > Lucas, > > On Wed, 14 Oct 2015 16:48:32 +0200, Lucas Stach wrote: >> This is not needed anymore. Handling a potentially pending imprecise external >> abort left behind by the bootloader is now done in a slightly safer way >> inside >> the common ARM startup code. >> >> Signed-off-by: Lucas Stach <l.st...@pengutronix.de> As pointed by Thomas the code is no longer needed. So even if the rest of tour series is not merged, I still applied on mvebu/cleanup. I also amended the commit log to emphasize that the Armada 375 Z1 was not support anymore. Thanks, Gregory >> --- >> arch/arm/mach-mvebu/board-v7.c | 35 --- >> 1 file changed, 35 deletions(-) > > Reviewed-by: Thomas Petazzoni <thomas.petazz...@free-electrons.com> > > In fact this code is anyway no longer needed, since this workaround was > only needed for the Armada 375 Z1 stepping, which we no longer support > in mainline anyway. > > Thanks! > > Thomas > -- > Thomas Petazzoni, CTO, Free Electrons > Embedded Linux, Kernel and Android engineering > http://free-electrons.com -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sched_clock: add data pointer argument to read callback
Hi Mans,
On ven., oct. 09 2015, Mans Rullgard <m...@mansr.com> wrote:
> This passes a data pointer specified in the sched_clock_register()
> call to the read callback allowing simpler implementations thereof.
>
> In this patch, existing uses of this interface are simply updated
> with a null pointer.
>
> Signed-off-by: Mans Rullgard <m...@mansr.com>
> ---
[...]
> diff --git a/drivers/clocksource/time-armada-370-xp.c
> b/drivers/clocksource/time-armada-370-xp.c
> index 2162796..a13b73b 100644
> --- a/drivers/clocksource/time-armada-370-xp.c
> +++ b/drivers/clocksource/time-armada-370-xp.c
> @@ -92,7 +92,7 @@ static void local_timer_ctrl_clrset(u32 clr, u32 set)
> local_base + TIMER_CTRL_OFF);
> }
>
> -static u64 notrace armada_370_xp_read_sched_clock(void)
> +static u64 notrace armada_370_xp_read_sched_clock(void *data)
> {
> return ~readl(timer_base + TIMER0_VAL_OFF);
> }
> @@ -290,7 +290,8 @@ static void __init armada_370_xp_timer_common_init(struct
> device_node *np)
> /*
>* Set scale and timer for sched_clock.
>*/
> - sched_clock_register(armada_370_xp_read_sched_clock, 32, timer_clk);
> + sched_clock_register(armada_370_xp_read_sched_clock, 32, timer_clk,
> + NULL);
>
> clocksource_mmio_init(timer_base + TIMER0_VAL_OFF,
> "armada_370_xp_clocksource",
For the time-armada-370-xp.c file:
Acked-by: Gregory CLEMENT <gregory.clem...@free-electrons.com>
Thanks,
Gregory
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] genirq: provide dummy set_irq_wake()
Hi Roger,
On 15/04/2015 10:07, Roger Quadros wrote:
Hi Gregory,
On 14/04/15 17:02, Gregory CLEMENT wrote:
Hi Roger,
On 14/04/2015 12:13, Roger Quadros wrote:
Hi Thomas,
On 30/03/15 16:15, Roger Quadros wrote:
Without this system suspend is broken on systems that have
drivers calling enable/disable_irq_wake() for interrupts based off
the dummy irq hook.
(e.g. drivers/gpio/gpio-pcf857x.c)
http://article.gmane.org/gmane.linux.kernel/1879035
Signed-off-by: Roger Quadros rog...@ti.com
Any comments on this patch?
I read the url you pointed and I wonder why, at then end, did
you choose to add a dummy set_irq_wake() instead of using
IRQCHIP_SKIP_SET_WAKE ?
You mean like this?
diff --git a/kernel/irq/dummychip.c b/kernel/irq/dummychip.c
index 988dc58..2feb6fe 100644
--- a/kernel/irq/dummychip.c
+++ b/kernel/irq/dummychip.c
@@ -57,5 +57,6 @@ struct irq_chip dummy_irq_chip = {
.irq_ack= noop,
.irq_mask = noop,
.irq_unmask = noop,
+ .flags = IRQCHIP_SKIP_SET_WAKE,
};
EXPORT_SYMBOL_GPL(dummy_irq_chip);
Yes exactly.
This works as well and is better. I'll post a v2.
Thanks,
Gregory
cheers,
-roger
---
kernel/irq/dummychip.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/kernel/irq/dummychip.c b/kernel/irq/dummychip.c
index 988dc58..2405d7a 100644
--- a/kernel/irq/dummychip.c
+++ b/kernel/irq/dummychip.c
@@ -32,6 +32,11 @@ static unsigned int noop_ret(struct irq_data *data)
return 0;
}
+static int noop_int_ret(struct irq_data *data, unsigned int val)
+{
+ return 0;
+}
+
/*
* Generic no controller implementation
*/
@@ -57,5 +62,6 @@ struct irq_chip dummy_irq_chip = {
.irq_ack= noop,
.irq_mask = noop,
.irq_unmask = noop,
+ .irq_set_wake = noop_int_ret,
};
EXPORT_SYMBOL_GPL(dummy_irq_chip);
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] genirq: Set IRQCHIP_SKIP_SET_WAKE flag for dummy_irq_chip
On 15/04/2015 10:14, Roger Quadros wrote:
Without this system suspend is broken on systems that have
drivers calling enable/disable_irq_wake() for interrupts based off
the dummy irq hook.
(e.g. drivers/gpio/gpio-pcf857x.c)
http://article.gmane.org/gmane.linux.kernel/1879035
Signed-off-by: Roger Quadros rog...@ti.com
FWIW:
Reviewed-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
kernel/irq/dummychip.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/irq/dummychip.c b/kernel/irq/dummychip.c
index 988dc58..2feb6fe 100644
--- a/kernel/irq/dummychip.c
+++ b/kernel/irq/dummychip.c
@@ -57,5 +57,6 @@ struct irq_chip dummy_irq_chip = {
.irq_ack= noop,
.irq_mask = noop,
.irq_unmask = noop,
+ .flags = IRQCHIP_SKIP_SET_WAKE,
};
EXPORT_SYMBOL_GPL(dummy_irq_chip);
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] genirq: provide dummy set_irq_wake()
Hi Roger,
On 14/04/2015 12:13, Roger Quadros wrote:
Hi Thomas,
On 30/03/15 16:15, Roger Quadros wrote:
Without this system suspend is broken on systems that have
drivers calling enable/disable_irq_wake() for interrupts based off
the dummy irq hook.
(e.g. drivers/gpio/gpio-pcf857x.c)
http://article.gmane.org/gmane.linux.kernel/1879035
Signed-off-by: Roger Quadros rog...@ti.com
Any comments on this patch?
I read the url you pointed and I wonder why, at then end, did
you choose to add a dummy set_irq_wake() instead of using
IRQCHIP_SKIP_SET_WAKE ?
Thanks,
Gregory
cheers,
-roger
---
kernel/irq/dummychip.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/kernel/irq/dummychip.c b/kernel/irq/dummychip.c
index 988dc58..2405d7a 100644
--- a/kernel/irq/dummychip.c
+++ b/kernel/irq/dummychip.c
@@ -32,6 +32,11 @@ static unsigned int noop_ret(struct irq_data *data)
return 0;
}
+static int noop_int_ret(struct irq_data *data, unsigned int val)
+{
+return 0;
+}
+
/*
* Generic no controller implementation
*/
@@ -57,5 +62,6 @@ struct irq_chip dummy_irq_chip = {
.irq_ack= noop,
.irq_mask = noop,
.irq_unmask = noop,
+.irq_set_wake = noop_int_ret,
};
EXPORT_SYMBOL_GPL(dummy_irq_chip);
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/14] ARM: orion: use clkdev_create()
Hi Russell, On 07/04/2015 16:01, Russell King - ARM Linux wrote: On Tue, Apr 07, 2015 at 03:20:05PM +0200, Gregory CLEMENT wrote: Hi Andrew, Russell, On 04/04/2015 02:17, Andrew Lunn wrote: On Fri, Apr 03, 2015 at 06:13:13PM +0100, Russell King wrote: clkdev_create() is a shorter way to write clkdev_alloc() followed by clkdev_add(). Use this instead. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk Acked-by: Andrew Lunn and...@lunn.ch This change makes sens however what about Thomas' comment: removing orion_clkdev_add() entirely and directly using lkdev_create() all over the place: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/327294.html Then what would be the path for this patch? As there is a dependency on the 6th patch of this series: clkdev: add clkdev_create() helper which should be merged through the clk tree, I think the best option is that this patch would be also managed by the clk tree maintainer (I added them in CC). Let me remind people that clkdev is *NOT* part of clk, and that I'm the maintainer for clkdev. Sorry for the confusion, I quickly had a look on the MAINTAINERS file and didn't realized that the drivers/clk/clkdev.c file was not part of clk (even if actually it was mentioned). I'm getting rather pissed off with people taking work away from me, even when I'm named in the MAINTAINERS file. These patches are going through my tree unless there's a good reason for them not to. They are _not_ going through the clk tree. So, as you are going to take care of all the patches it is even simpler. You can take this one too: in mvebu there is no change on this file for this release so there won't be any conflict. Thanks, Gregory -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/14] ARM: orion: use clkdev_create()
Hi Andrew, Russell,
On 04/04/2015 02:17, Andrew Lunn wrote:
On Fri, Apr 03, 2015 at 06:13:13PM +0100, Russell King wrote:
clkdev_create() is a shorter way to write clkdev_alloc() followed by
clkdev_add(). Use this instead.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
Acked-by: Andrew Lunn and...@lunn.ch
This change makes sens however what about Thomas' comment: removing
orion_clkdev_add() entirely and directly using lkdev_create() all over
the place:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/327294.html
Then what would be the path for this patch?
As there is a dependency on the 6th patch of this series: clkdev: add
clkdev_create() helper which should be merged through the clk tree, I
think the best option is that this patch would be also managed by the
clk tree maintainer (I added them in CC).
Thanks,
Gregory
Andrew
---
arch/arm/plat-orion/common.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/arch/arm/plat-orion/common.c b/arch/arm/plat-orion/common.c
index f5b00f41c4f6..2235081a04ee 100644
--- a/arch/arm/plat-orion/common.c
+++ b/arch/arm/plat-orion/common.c
@@ -28,11 +28,7 @@
void __init orion_clkdev_add(const char *con_id, const char *dev_id,
struct clk *clk)
{
-struct clk_lookup *cl;
-
-cl = clkdev_alloc(clk, con_id, dev_id);
-if (cl)
-clkdev_add(cl);
+clkdev_create(clk, con_id, %s, dev_id);
}
/* Create clkdev entries for all orion platforms except kirkwood.
--
1.8.3.1
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Build error: OMAP randconfig / mvebu
On 02/08/2013 02:33 PM, Arnd Bergmann wrote: On Friday 08 February 2013 12:06:44 Gregory CLEMENT wrote: I don't know what to do here, there is no point to build any of the files in mach-mvebu if no SoCs are selected. So either we force to have at least one SoCS selected if ARCH_MVEBU is selected, or we unselect ARCH_MVEB if no SoCs are selected. The latter does not work, because that would introduce a circular dependency in Kconfig. I suppose rearranging the mvebu Makefile like this would do. Signed-off-by: Arnd Bergmann a...@arndb.de diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile index 99df4df..c0434dc 100644 --- a/arch/arm/mach-mvebu/Makefile +++ b/arch/arm/mach-mvebu/Makefile @@ -1,9 +1,15 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) := -I$(srctree)/$(src)/include \ -I$(srctree)/arch/arm/plat-orion/include -AFLAGS_coherency_ll.o:= -Wa,-march=armv7-a +AFLAGS_coherency_ll.o := -Wa,-march=armv7-a -obj-y += system-controller.o -obj-$(CONFIG_MACH_ARMADA_370_XP) += armada-370-xp.o irq-armada-370-xp.o addr-map.o coherency.o coherency_ll.o pmsu.o -obj-$(CONFIG_SMP)+= platsmp.o headsmp.o -obj-$(CONFIG_HOTPLUG_CPU)+= hotplug.o +obj-$(CONFIG_MACH_ARMADA_370_XP) += $(armada-y) +armada-y += system-controller.o +armada-y += armada-370-xp.o +armada-y += irq-armada-370-xp.o +armada-y += addr-map.o +armada-y += coherency.o +armada-y += coherency_ll.o +armada-y += pmsu.o +armada-$(CONFIG_SMP) += platsmp.o headsmp.o +armada-$(CONFIG_HOTPLUG_CPU) += hotplug.o I have also tested your patch with a config with SMP, MVEBU, SMP and not MACH_ARMADA_370_XP. It fixes the build error. You can add my Tested-by: Gregory CLEMENT gregory.clem...@free-electrons.com How do you want to proceed? As this patch come from you you should have it somewhere in your git tree, but I can take care of submitting a proper patch (ie with a commit log) if you want. Regards, -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Build error: OMAP randconfig / mvebu
On 02/14/2013 01:21 PM, Arnd Bergmann wrote: On Thursday 14 February 2013, Ezequiel Garcia wrote: Now, using the random config there's a new error, unrelated to the previous one: ERROR: twl6030_interrupt_unmask [drivers/usb/otg/twl6030-usb.ko] undefined! ERROR: twl_i2c_read_u8 [drivers/usb/otg/twl6030-usb.ko] undefined! ERROR: twl_i2c_write_u8 [drivers/usb/otg/twl6030-usb.ko] undefined! ERROR: twl6030_interrupt_mask [drivers/usb/otg/twl6030-usb.ko] undefined! Yes, I guess that is an unrelated error. However, my patch also wasn't correct because it is not allowed to have an empty list of objects. There is an updated patch below, I could add that straight to the branch that caused the problem if it looks ok to you. OK for me, this patch still fix the build error and I tested that we still have a valid kernel for Armada 370 for Armada XP Tested-by: Gregory Clement gregory.clem...@free-electrons.com on Armada 370 DB and Armada XP DB Arnd From 0860b5b4558ad777068826bc9a735b82f3cf0d88 Mon Sep 17 00:00:00 2001 From: Arnd Bergmann a...@arndb.de Date: Thu, 14 Feb 2013 13:14:53 +0100 Subject: [PATCH] ARM: mvebu: allow selecting mvebu without Armada XP Selecting only CONFIG_ARCH_MVEBU but not the respective options for Armada 370 or Armada XP results in these link errors: arch/arm/mach-mvebu/built-in.o: In function `armada_xp_smp_init_cpus': arch/arm/mach-mvebu/platsmp.c:91: undefined reference to `coherency_get_cpu_count' arch/arm/mach-mvebu/platsmp.c:104: undefined reference to `armada_mpic_send_doorbell' arch/arm/mach-mvebu/built-in.o: In function `armada_xp_smp_prepare_cpus': arch/arm/mach-mvebu/platsmp.c:111: undefined reference to `set_cpu_coherent' arch/arm/mach-mvebu/built-in.o: In function `armada_xp_boot_secondary': arch/arm/mach-mvebu/platsmp.c:83: undefined reference to `armada_xp_boot_cpu' arch/arm/mach-mvebu/built-in.o: In function `armada_xp_secondary_init': arch/arm/mach-mvebu/platsmp.c:75: undefined reference to `armada_xp_mpic_smp_cpu_init' arch/arm/mach-mvebu/built-in.o: In function `armada_xp_secondary_startup': arch/arm/mach-mvebu/headsmp.S:46: undefined reference to `ll_set_cpu_coherent' We can solve this by enabling all common MVEBU files that are referenced by the SMP files. This means we enable code that is not going to be used without a machine descriptor referencing it, but only if the kernel is configured specifically for this case. Signed-off-by: Arnd Bergmann a...@arndb.de Cc: Gregory Clement gregory.clem...@free-electrons.com Cc: Ezequiel Garcia ezequiel.gar...@free-electrons.com diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile index 99df4df..da93bcb 100644 --- a/arch/arm/mach-mvebu/Makefile +++ b/arch/arm/mach-mvebu/Makefile @@ -3,7 +3,8 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) := -I$(srctree)/$(src)/include \ AFLAGS_coherency_ll.o:= -Wa,-march=armv7-a -obj-y += system-controller.o -obj-$(CONFIG_MACH_ARMADA_370_XP) += armada-370-xp.o irq-armada-370-xp.o addr-map.o coherency.o coherency_ll.o pmsu.o +obj-y += system-controller.o +obj-$(CONFIG_MACH_ARMADA_370_XP) += armada-370-xp.o +obj-$(CONFIG_ARCH_MVEBU) += addr-map.o coherency.o coherency_ll.o pmsu.o irq-armada-370-xp.o obj-$(CONFIG_SMP)+= platsmp.o headsmp.o obj-$(CONFIG_HOTPLUG_CPU)+= hotplug.o -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Build error: OMAP randconfig / mvebu
On 02/08/2013 11:45 AM, Arnd Bergmann wrote: On Friday 08 February 2013 10:08:13 Russell King - ARM Linux wrote: Last night's OMAP4430SDP randconfig build failed with: arch/arm/mach-mvebu/built-in.o: In function `armada_xp_smp_init_cpus': hotplug.c:(.init.text+0x70): undefined reference to `coherency_get_cpu_count' hotplug.c:(.init.text+0xb4): undefined reference to `armada_mpic_send_doorbell' arch/arm/mach-mvebu/built-in.o: In function `armada_xp_smp_prepare_cpus': hotplug.c:(.init.text+0x254): undefined reference to `set_cpu_coherent' arch/arm/mach-mvebu/built-in.o: In function `armada_xp_boot_secondary': hotplug.c:(.cpuinit.text+0x10): undefined reference to `armada_xp_boot_cpu' arch/arm/mach-mvebu/built-in.o: In function `armada_xp_secondary_init': hotplug.c:(.cpuinit.text+0x2c): undefined reference to `armada_xp_mpic_smp_cpu_init' arch/arm/mach-mvebu/built-in.o: In function `armada_xp_secondary_startup': hotplug.c:(.cpuinit.text+0x40): undefined reference to `ll_set_cpu_coherent' This seems to be because we ended up with CONFIG_ARCH_MVEBU=y but without CONFIG_MACH_ARMADA_370_XP being set - and because of OMAP, we have SMP and hotplug CPU enabled. Usual configs/logs available via the website. Ok, I see. I suspect we are going to see a lot more randconfig failures now with all the platforms that are becoming part of multiplatform. mvebu maintainers: this one should be easy enough to fix. Anyone submitting a patch? I don't know what to do here, there is no point to build any of the files in mach-mvebu if no SoCs are selected. So either we force to have at least one SoCS selected if ARCH_MVEBU is selected, or we unselect ARCH_MVEB if no SoCs are selected. Gregory -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 1/1] OMAP2: Spi: Force CS to be in inactive state after off-mode transition
Hi Gregory,
Hi Grant,
Patch does not apply, but I cannot immediately isolate the damage.
Please see if you can figure out the issue on your end. Is it your
mailer? I could fudge it, but in the long run it is better if this
issue can get sorted out now.
I found the problem: see below in the patch itself.
Also, a few other minor nitpicks (I won't reject a patch over these,
but it helps to have them right):
Please prefix spi patch names with spi[/driver]:. It is the format
for all spi patches I take through my tree, and if it already follows
that convention, then I don't need to edit it manually.
Second, please keep the line length in the patch description short; in
general I find that a textwidth limit of 70 characters is about right
for the purpose of reading/replying in email. A lot of maintainers
use text email clients like mutt in 80 column terminal windows.
Keeping a reasonable right hand margin in the text body is simply
friendly.
Finally, in changelogs it is easier to read if there is some kind of
itemization ticks. For example:
* Change from v5 to v6:
- Rebase on linus/master (after 2.6.37-rc7)
- Use CONFIG_SUSPEND instead of CONFIG_PM
- Didn't use legacy PM methods anymore. Instead, add a struct
dev_pm_ops and add the resume method there.
- Fix multi-line comment style
I will fix these (patch prefix, wrapping and itemization ticks) and send the
patch again today.
g.
---
drivers/spi/omap2_mcspi.c | 40
1 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
index 2a651e6..a17ea97 100644
--- a/drivers/spi/omap2_mcspi.c
+++ b/drivers/spi/omap2_mcspi.c
@@ -1305,10 +1305,50 @@ static int __exit omap2_mcspi_remove(struct
platform_device *pdev)
/* work with hotplug and coldplug */
MODULE_ALIAS(platform:omap2_mcspi);
+#ifdef CONFIG_SUSPEND
^
|
Problem was here, I deleted a carrier in error :(
+/*
+ * When SPI wake up from off-mode, CS is in activate state. If it was in
+ * unactive state when driver was suspend, then force it to unactive state
at
+ * wake up.
+ */
+static int omap2_mcspi_resume(struct device *dev)
+{
+struct spi_master *master = dev_get_drvdata(dev);
+struct omap2_mcspi *mcspi = spi_master_get_devdata(master);
+struct omap2_mcspi_cs *cs;
+
+omap2_mcspi_enable_clocks(mcspi);
+list_for_each_entry(cs, omap2_mcspi_ctx[master-bus_num - 1].cs,
+node) {
+if ((cs-chconf0 OMAP2_MCSPI_CHCONF_FORCE) == 0) {
+
+/*
+ * We need to toggle CS state for OMAP take this
+ * change in account.
+ */
+MOD_REG_BIT(cs-chconf0, OMAP2_MCSPI_CHCONF_FORCE, 1);
+__raw_writel(cs-chconf0, cs-base +
OMAP2_MCSPI_CHCONF0);
+MOD_REG_BIT(cs-chconf0, OMAP2_MCSPI_CHCONF_FORCE, 0);
+__raw_writel(cs-chconf0, cs-base +
OMAP2_MCSPI_CHCONF0);
+}
+}
+omap2_mcspi_disable_clocks(mcspi);
+return 0;
+}
+#else
+#define omap2_mcspi_resume NULL
+#endif
+
+static const struct dev_pm_ops omap2_mcspi_pm_ops = {
+.resume = omap2_mcspi_resume,
+};
+
static struct platform_driver omap2_mcspi_driver = {
.driver = {
.name = omap2_mcspi,
.owner =THIS_MODULE,
+.pm = omap2_mcspi_pm_ops
+
Drop the extra line.
},
.remove = __exit_p(omap2_mcspi_remove),
};
--
1.7.0.4
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 1/1] spi/omap2_mcspi.c: Force CS to be in inactive state after off-mode transition
When SPI wake up from OFF mode, CS is in the wrong state: force it to the
inactive state.
During the system life, I monitored the CS behavior using a oscilloscope.
I also activated debug in omap2_mcspi, so I saw when driver disable the clocks
and restore context when device is not used.Each time the CS was in the correct
state. It was only when system was put suspend to ram with off-mode activated
that on resume the CS was in wrong state( ie activated).
Changelog:
* Change from v1 to v2:
- Rebase on linus/master (after 2.6.37-rc1)
- Do some clean-up and fix indentation on both patches
- Add more explanations for patch 2
* Change from v2 to v3:
- Use directly resume function of spi_master instead of using function
- from spi_device as Grant Likely pointed it out.
- Force this transition explicitly for each CS used by a device.
* Change from v3 to v4:
- Patch clean-up according to Kevin Hilman and checkpatch.
- Now force CS to be in inactive state only if it was inactive when it was
suspended.
* Change from v4 to v5:
- Rebase on linus/master (after 2.6.37-rc3)
- Collapse some lines as pointed by Grant Likely
- Fix a spelling
* Change from v5 to v6:
- Rebase on linus/master (after 2.6.37-rc7)
- Use CONFIG_SUSPEND instead of CONFIG_PM
- Didn't use legacy PM methods anymore. Instead, add a struct dev_pm_ops and
add the resume method there.
- Fix multi-line comment style
* Change from v6 to v7:
- Rebase on linus/master (after 2.6.37-rc8)
- Drop an extra line
Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
Acked-by: David Brownell dbrown...@users.sourceforge.net
Reviewed-by: Kevin Hilman khil...@deeprootsystems.com
---
drivers/spi/omap2_mcspi.c | 39 +++
1 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
index 2a651e6..951a160 100644
--- a/drivers/spi/omap2_mcspi.c
+++ b/drivers/spi/omap2_mcspi.c
@@ -1305,10 +1305,49 @@ static int __exit omap2_mcspi_remove(struct
platform_device *pdev)
/* work with hotplug and coldplug */
MODULE_ALIAS(platform:omap2_mcspi);
+#ifdef CONFIG_SUSPEND
+/*
+ * When SPI wake up from off-mode, CS is in activate state. If it was in
+ * unactive state when driver was suspend, then force it to unactive state at
+ * wake up.
+ */
+static int omap2_mcspi_resume(struct device *dev)
+{
+ struct spi_master *master = dev_get_drvdata(dev);
+ struct omap2_mcspi *mcspi = spi_master_get_devdata(master);
+ struct omap2_mcspi_cs *cs;
+
+ omap2_mcspi_enable_clocks(mcspi);
+ list_for_each_entry(cs, omap2_mcspi_ctx[master-bus_num - 1].cs,
+ node) {
+ if ((cs-chconf0 OMAP2_MCSPI_CHCONF_FORCE) == 0) {
+
+ /*
+* We need to toggle CS state for OMAP take this
+* change in account.
+*/
+ MOD_REG_BIT(cs-chconf0, OMAP2_MCSPI_CHCONF_FORCE, 1);
+ __raw_writel(cs-chconf0, cs-base +
OMAP2_MCSPI_CHCONF0);
+ MOD_REG_BIT(cs-chconf0, OMAP2_MCSPI_CHCONF_FORCE, 0);
+ __raw_writel(cs-chconf0, cs-base +
OMAP2_MCSPI_CHCONF0);
+ }
+ }
+ omap2_mcspi_disable_clocks(mcspi);
+ return 0;
+}
+#else
+#defineomap2_mcspi_resume NULL
+#endif
+
+static const struct dev_pm_ops omap2_mcspi_pm_ops = {
+ .resume = omap2_mcspi_resume,
+};
+
static struct platform_driver omap2_mcspi_driver = {
.driver = {
.name = omap2_mcspi,
.owner =THIS_MODULE,
+ .pm = omap2_mcspi_pm_ops
},
.remove = __exit_p(omap2_mcspi_remove),
};
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 1/1] OMAP2: Spi: Force CS to be in inactive state after off-mode transition
On 12/29/2010 10:01 AM, Gregory CLEMENT wrote: Hi Gregory, Hi Grant, Patch does not apply, but I cannot immediately isolate the damage. Please see if you can figure out the issue on your end. Is it your mailer? I could fudge it, but in the long run it is better if this issue can get sorted out now. I found the problem: see below in the patch itself. Indeed it was may mailer which had broken the patch. I use git-format-patch and git imap send to create the mail. But when I open it from the draft folder to add the email address, it decides by itself to remove an end of line! It is not the first time that I have some problems with Thunderbird. I consider changing my mailer to a more hacker friendly one. -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/1] OMAP2: Spi: Force CS to be in inactive state after off-mode transition
On 12/24/2010 12:08 AM, Grant Likely wrote: On Wed, Nov 24, 2010 at 04:49:47PM -0800, Kevin Hilman wrote: Gregory CLEMENT gregory.clem...@free-electrons.com writes: As request by Grant Likely, there is no more cover letter. Full changelog is following. I am still reluctant to add this changelog in the patch description, as it adds no value to the patch itself: when it was needed I try to updat comments or patch description. You're right, the changelog should not be in the patch description. This bit of meta-description and changelog should go after the '---' just after your signoff. That way, git tools can still auto-apply the email, and git ignores stuff after the '---' so it doesn't end up in the git history. Actually, I used to have the same opinion, but dwmw2 clued me in that it really is valuable and proper to have the revision history and changelog in the patch description. When looking back at what actually got committed into Linus' tree, the changelog gives hints as to which exact version of the patch got committed (for instance, if a v6 got merged, but a v7 was also posted that didn't get merged.) OK if it is the rule for spi subsystem, I will conform to it, and I will add my changelog in the patch description. BTW, this thread has some discussion about this patch not actually working correctly. What is the state? Should this version get merged, or do I need to wait for a v6? Well, I tried to answer to each points to Kevin and to David Brownell. I was waiting for some feedback. I didn't realize it was already near a month ago, so it should be OK. Then I will insert the last comments of Kevin and release the v6. -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 1/1] OMAP2: Spi: Force CS to be in inactive state after off-mode transition
When SPI wake up from OFF mode, CS is in the wrong state: force it to the
inactive state.
During the system life, I monitored the CS behavior using a oscilloscope.
I also activated debug in omap2_mcspi, so I saw when driver disable the clocks
and restore context when device is not used.
Each time the CS was in the correct state.
It was only when system was put suspend to ram with off-mode activated that on
resume the CS was in wrong state( ie activated).
Changelog:
* Change from v1 to v2:
Rebase on linus/master (after 2.6.37-rc1)
Do some clean-up and fix indentation on both patches
Add more explanations for patch 2
* Change from v2 to v3:
Use directly resume function of spi_master instead of using function
from spi_device as Grant Likely pointed it out.
Force this transition explicitly for each CS used by a device.
* Change from v3 to v4:
Patch clean-up according to Kevin Hilman and checkpatch.
Now force CS to be in inactive state only if it was inactive when it was
suspended.
* Change from v4 to v5:
Rebase on linus/master (after 2.6.37-rc3)
Collapse some lines as pointed by Grant Likely
Fix a spelling
* Change from v5 to v6:
Rebase on linus/master (after 2.6.37-rc7)
Use CONFIG_SUSPEND instead of CONFIG_PM
Didn't use legacy PM methods anymore. Instead, add a struct dev_pm_ops and add
the resume method there.
Fix multi-line comment style
Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
drivers/spi/omap2_mcspi.c | 40
1 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
index 2a651e6..a17ea97 100644
--- a/drivers/spi/omap2_mcspi.c
+++ b/drivers/spi/omap2_mcspi.c
@@ -1305,10 +1305,50 @@ static int __exit omap2_mcspi_remove(struct
platform_device *pdev)
/* work with hotplug and coldplug */
MODULE_ALIAS(platform:omap2_mcspi);
+#ifdefCONFIG_SUSPEND
+/*
+ * When SPI wake up from off-mode, CS is in activate state. If it was in
+ * unactive state when driver was suspend, then force it to unactive state at
+ * wake up.
+ */
+static int omap2_mcspi_resume(struct device *dev)
+{
+ struct spi_master *master = dev_get_drvdata(dev);
+ struct omap2_mcspi *mcspi = spi_master_get_devdata(master);
+ struct omap2_mcspi_cs *cs;
+
+ omap2_mcspi_enable_clocks(mcspi);
+ list_for_each_entry(cs, omap2_mcspi_ctx[master-bus_num - 1].cs,
+ node) {
+ if ((cs-chconf0 OMAP2_MCSPI_CHCONF_FORCE) == 0) {
+
+ /*
+* We need to toggle CS state for OMAP take this
+* change in account.
+*/
+ MOD_REG_BIT(cs-chconf0, OMAP2_MCSPI_CHCONF_FORCE, 1);
+ __raw_writel(cs-chconf0, cs-base +
OMAP2_MCSPI_CHCONF0);
+ MOD_REG_BIT(cs-chconf0, OMAP2_MCSPI_CHCONF_FORCE, 0);
+ __raw_writel(cs-chconf0, cs-base +
OMAP2_MCSPI_CHCONF0);
+ }
+ }
+ omap2_mcspi_disable_clocks(mcspi);
+ return 0;
+}
+#else
+#defineomap2_mcspi_resume NULL
+#endif
+
+static const struct dev_pm_ops omap2_mcspi_pm_ops = {
+ .resume = omap2_mcspi_resume,
+};
+
static struct platform_driver omap2_mcspi_driver = {
.driver = {
.name = omap2_mcspi,
.owner =THIS_MODULE,
+ .pm = omap2_mcspi_pm_ops
+
},
.remove = __exit_p(omap2_mcspi_remove),
};
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/1] OMAP2: Spi: Force CS to be in inactive state after off-mode transition
On 11/30/2010 04:08 AM, David Brownell wrote: Now force CS to be in inactive state only if it was inactive when it was suspended. Note that it's a bug if CS is active in any suspend state (including OFF). That strongly suggests $SUBJECT is an incomplete workaround for that other bug... It is not the case, at least it is not what we observed. In suspend state, CS is inactive. When SPI wake up from OFF mode, CS is in the wrong state: force it to the inactive state. Best report the bug that the suspend/OFF state was mis-handled... That is, it didn't correctly ENTER that OFF mode... In fact ... I'd like to see that fixed more than the $SUBJECT issue, so the root cause gets resolved... As far as I know, it enter correctly that OFF mode. It is only at wake up, that CS become active while there is no SPI message being processed. It is the point of my patch. My first patch version forced unconditionally CS to inactive state at wake up. It was correct from the point of view of the SPI but not for suspend/resume. Resume should only restore the state of the driver just before suspend. If resume force the inactive state it could mask a bug in the suspend path. But as I wrote before, as far as I know there is no bug when driver enter suspend mode, at this moment CS is inactive. CS should only be active while a SPI message is being processed, and such processing must have completed before suspend/OFF/... starts I agree and this driver seems to respect this point. -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/1] OMAP2: Spi: Force CS to be in inactive state after off-mode transition
On 11/25/2010 01:49 AM, Kevin Hilman wrote:
This bit of meta-description and changelog should go after the '---'
just after your signoff. That way, git tools can still auto-apply the
email, and git ignores stuff after the '---' so it doesn't end up in the
git history.
Thanks for the advice
I understand that Grant Likely would need an ack from other user as this
patch fix a corner case.
Kevin Hilman made a few comments on this patch so he could add his Ack by
or at least his Review by.
I haven't actually tested it, only reviewed it, so you can add a
Reviewed by for me, but I'm not SPI-aware enough to ack this patch or
test it thoroughly. Also, I have some more comments below...
Thanks I will add it in my next version.
Also, in the last patch I suggested you do more of a save/restore of
this value instead of a restore to a hard-coded value. IOW, save the
value in the suspend method, restore it in resume. I thought you had
agreed to that. I'm not an SPI expert, so not sure if it makes sense,
but it seems more robust that way and more future proof.
Well I took in account your suggestion and I didn't restore anymore an
hardcore value. The state of the CS is already store in cs-chconf0, so
now I use it. The tricky part is omap2_mcspi_enable_clocks restore the
register when clock was disable, but for OMAP2_MCSPI_CHCONF_FORCE bit, we
had to toggle it. When resumed from OFF mode the OMAP2_MCSPI_CHCONF0
register have default value, which means that OMAP2_MCSPI_CHCONF_FORCE
is 0. So if we want that OMAP2_MCSPI_CHCONF_FORCE=0 is taken in account
we have to first write a 1 and then a 0. But if we want that
OMAP2_MCSPI_CHCONF_FORCE=1, then we have nothing more to do, because in
omap2_mcspi_enable_clocks this bit was change from 0 (its default value)
to 1. That's why I only do a change when OMAP2_MCSPI_CHCONF_FORCE have to
be changed to 0.
I suppose this means that I had to add more comment around my code about
it.
When SPI wake up from OFF mode, CS is in the wrong state: force it to the
inactive state.
During the system life, I monitored the CS behavior using a oscilloscope.
I also activated debug in omap2_mcspi, so I saw when driver disable the
clocks and restore context when device is not used.
Each time the CS was in the correct state.
It was only when system was put suspend to ram with off-mode activated that
on resume the CS was in wrong state( ie activated).
Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
This is where any changelog and extra info for reviewers should go.
drivers/spi/omap2_mcspi.c | 33 +
1 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
index 2a651e6..dcc024a 100644
--- a/drivers/spi/omap2_mcspi.c
+++ b/drivers/spi/omap2_mcspi.c
@@ -1305,11 +1305,44 @@ static int __exit omap2_mcspi_remove(struct
platform_device *pdev)
/* work with hotplug and coldplug */
MODULE_ALIAS(platform:omap2_mcspi);
+#ifdef CONFIG_PM
+/* When SPI wake up from off-mode, CS is in activate state. If it was in
+ * unactive state when driver was suspend, then force it to unactive state
at
+ * wake up.
+ */
please fix multi-line comment style. Search for 'multi-line' in
CodingStyle.
OK, I though CodingStyle was about burning GNU coding standards ;)
More seriously I keep the same style that other multi-line comment
in this file. But I have no problem to change it.
+static int omap2_mcspi_resume(struct platform_device *pdev)
+{
+struct spi_master *master = dev_get_drvdata(pdev-dev);
+struct omap2_mcspi *mcspi = spi_master_get_devdata(master);
+struct omap2_mcspi_cs *cs;
+
+omap2_mcspi_enable_clocks(mcspi);
+list_for_each_entry(cs, omap2_mcspi_ctx[master-bus_num - 1].cs,
+node) {
+if ((cs-chconf0 OMAP2_MCSPI_CHCONF_FORCE) == 0) {
+
+/* We need to toggle CS state for OMAP take this
+ * change in account.
+ */
multi-line coding style
+MOD_REG_BIT(cs-chconf0, OMAP2_MCSPI_CHCONF_FORCE, 1);
+__raw_writel(cs-chconf0, cs-base +
OMAP2_MCSPI_CHCONF0);
+MOD_REG_BIT(cs-chconf0, OMAP2_MCSPI_CHCONF_FORCE, 0);
+__raw_writel(cs-chconf0, cs-base +
OMAP2_MCSPI_CHCONF0);
+}
+}
+omap2_mcspi_disable_clocks(mcspi);
+return 0;
+}
+#else
+#define omap2_mcspi_resume NULL
+#endif
+
static struct platform_driver omap2_mcspi_driver = {
.driver = {
.name = omap2_mcspi,
.owner =THIS_MODULE,
},
+.resume = omap2_mcspi_resume,
.remove = __exit_p(omap2_mcspi_remove),
};
-- 1.7.0.4
Kevin
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting
Re: [PATCH v5 1/1] OMAP2: Spi: Force CS to be in inactive state after off-mode transition
On 11/29/2010 03:22 PM, Kevin Hilman wrote:
Gregory CLEMENT gregory.clem...@free-electrons.com writes:
As request by Grant Likely, there is no more cover letter. Full changelog is
following.
I am still reluctant to add this changelog in the patch description, as it
adds no value to
the patch itself: when it was needed I try to updat comments or patch
description.
I understand that Grant Likely would need an ack from other user as this
patch fix a corner case.
Kevin Hilman made a few comments on this patch so he could add his Ack by
or at least his Review by.
A couple more comments...
Changelog:
* Change from v1 to v2:
Rebase on linus/master (after 2.6.37-rc1)
Do some clean-up and fix indentation on both patches
Add more explanations for patch 2
* Change from v2 to v3:
Use directly resume function of spi_master instead of using function
from spi_device as Grant Likely pointed it out.
Force this transition explicitly for each CS used by a device.
* Change from v3 to v4:
Patch clean-up according to Kevin Hilman and checkpatch.
Now force CS to be in inactive state only if it was inactive when it was
suspended.
* Change from v4 to v5:
Rebase on linus/master (after 2.6.37-rc3)
Collapse some lines as pointed by Grant Likely
Fix a spelling
== CUT HERE ==
When SPI wake up from OFF mode, CS is in the wrong state: force it to the
inactive state.
During the system life, I monitored the CS behavior using a oscilloscope.
I also activated debug in omap2_mcspi, so I saw when driver disable the
clocks and restore context when device is not used.
Each time the CS was in the correct state.
It was only when system was put suspend to ram with off-mode activated that
on resume the CS was in wrong state( ie activated).
Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
drivers/spi/omap2_mcspi.c | 33 +
1 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
index 2a651e6..dcc024a 100644
--- a/drivers/spi/omap2_mcspi.c
+++ b/drivers/spi/omap2_mcspi.c
@@ -1305,11 +1305,44 @@ static int __exit omap2_mcspi_remove(struct
platform_device *pdev)
/* work with hotplug and coldplug */
MODULE_ALIAS(platform:omap2_mcspi);
+#ifdef CONFIG_PM
You should use CONFIG_SUSPEND here
OK I will do this.
+/* When SPI wake up from off-mode, CS is in activate state. If it was in
+ * unactive state when driver was suspend, then force it to unactive state
at
+ * wake up.
+ */
+static int omap2_mcspi_resume(struct platform_device *pdev)
+{
+struct spi_master *master = dev_get_drvdata(pdev-dev);
+struct omap2_mcspi *mcspi = spi_master_get_devdata(master);
+struct omap2_mcspi_cs *cs;
+
+omap2_mcspi_enable_clocks(mcspi);
+list_for_each_entry(cs, omap2_mcspi_ctx[master-bus_num - 1].cs,
+node) {
+if ((cs-chconf0 OMAP2_MCSPI_CHCONF_FORCE) == 0) {
+
+/* We need to toggle CS state for OMAP take this
+ * change in account.
+ */
+MOD_REG_BIT(cs-chconf0, OMAP2_MCSPI_CHCONF_FORCE, 1);
+__raw_writel(cs-chconf0, cs-base +
OMAP2_MCSPI_CHCONF0);
+MOD_REG_BIT(cs-chconf0, OMAP2_MCSPI_CHCONF_FORCE, 0);
+__raw_writel(cs-chconf0, cs-base +
OMAP2_MCSPI_CHCONF0);
+}
+}
+omap2_mcspi_disable_clocks(mcspi);
+return 0;
+}
+#else
+#define omap2_mcspi_resume NULL
+#endif
+
static struct platform_driver omap2_mcspi_driver = {
.driver = {
.name = omap2_mcspi,
.owner =THIS_MODULE,
},
+.resume = omap2_mcspi_resume,
This is adding legacy PM methods. Instead, you should add a struct
dev_pm_ops and add the resume method there.
OK, I shouldn't copy and paste an old driver!
Thanks for your advices.
Kevin
.remove = __exit_p(omap2_mcspi_remove),
};
-- 1.7.0.4
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/1] OMAP2: Spi: Force CS to be in inactive state after off-mode transition
On 11/25/2010 09:58 AM, Hemanth V wrote: - Original Message - From: Gregory CLEMENT gregory.clem...@free-electrons.com To: linux-omap linux-omap@vger.kernel.org; spi-devel-gene...@lists.sourceforge.net Cc: David Brownell dbrown...@users.sourceforge.net; Grant Likely grant.lik...@secretlab.ca; Kevin Hilman khil...@deeprootsystems.com Sent: Thursday, November 25, 2010 3:49 AM Subject: [PATCH v5 1/1] OMAP2: Spi: Force CS to be in inactive state after off-mode transition As request by Grant Likely, there is no more cover letter. Full changelog is following. I am still reluctant to add this changelog in the patch description, as it adds no value to the patch itself: when it was needed I try to updat comments or patch description. I understand that Grant Likely would need an ack from other user as this patch fix a corner case. Kevin Hilman made a few comments on this patch so he could add his Ack by or at least his Review by. I was trying to run some tests with this patch. I find that the resume function registered by this patch doesnot seem to get called during system wide suspend/resume, since spi_resume only calls the resume routine registered by spi client driver. Is there something I am missing. In fact the resume function for this driver won't be called by spi bus but by platform bus. Indeed this function is registered in a platform_driver structure. Thanks Hemanth -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 1/1] OMAP2: Spi: Force CS to be in inactive state after off-mode transition
As request by Grant Likely, there is no more cover letter. Full changelog is
following.
I am still reluctant to add this changelog in the patch description, as it adds
no value to
the patch itself: when it was needed I try to updat comments or patch
description.
I understand that Grant Likely would need an ack from other user as this patch
fix a corner case.
Kevin Hilman made a few comments on this patch so he could add his Ack by or
at least his Review by.
Changelog:
* Change from v1 to v2:
Rebase on linus/master (after 2.6.37-rc1)
Do some clean-up and fix indentation on both patches
Add more explanations for patch 2
* Change from v2 to v3:
Use directly resume function of spi_master instead of using function
from spi_device as Grant Likely pointed it out.
Force this transition explicitly for each CS used by a device.
* Change from v3 to v4:
Patch clean-up according to Kevin Hilman and checkpatch.
Now force CS to be in inactive state only if it was inactive when it was
suspended.
* Change from v4 to v5:
Rebase on linus/master (after 2.6.37-rc3)
Collapse some lines as pointed by Grant Likely
Fix a spelling
== CUT HERE ==
When SPI wake up from OFF mode, CS is in the wrong state: force it to the
inactive state.
During the system life, I monitored the CS behavior using a oscilloscope.
I also activated debug in omap2_mcspi, so I saw when driver disable the clocks
and restore context when device is not used.
Each time the CS was in the correct state.
It was only when system was put suspend to ram with off-mode activated that on
resume the CS was in wrong state( ie activated).
Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
drivers/spi/omap2_mcspi.c | 33 +
1 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
index 2a651e6..dcc024a 100644
--- a/drivers/spi/omap2_mcspi.c
+++ b/drivers/spi/omap2_mcspi.c
@@ -1305,11 +1305,44 @@ static int __exit omap2_mcspi_remove(struct
platform_device *pdev)
/* work with hotplug and coldplug */
MODULE_ALIAS(platform:omap2_mcspi);
+#ifdef CONFIG_PM
+/* When SPI wake up from off-mode, CS is in activate state. If it was in
+ * unactive state when driver was suspend, then force it to unactive state at
+ * wake up.
+ */
+static int omap2_mcspi_resume(struct platform_device *pdev)
+{
+ struct spi_master *master = dev_get_drvdata(pdev-dev);
+ struct omap2_mcspi *mcspi = spi_master_get_devdata(master);
+ struct omap2_mcspi_cs *cs;
+
+ omap2_mcspi_enable_clocks(mcspi);
+ list_for_each_entry(cs, omap2_mcspi_ctx[master-bus_num - 1].cs,
+ node) {
+ if ((cs-chconf0 OMAP2_MCSPI_CHCONF_FORCE) == 0) {
+
+ /* We need to toggle CS state for OMAP take this
+* change in account.
+*/
+ MOD_REG_BIT(cs-chconf0, OMAP2_MCSPI_CHCONF_FORCE, 1);
+ __raw_writel(cs-chconf0, cs-base +
OMAP2_MCSPI_CHCONF0);
+ MOD_REG_BIT(cs-chconf0, OMAP2_MCSPI_CHCONF_FORCE, 0);
+ __raw_writel(cs-chconf0, cs-base +
OMAP2_MCSPI_CHCONF0);
+ }
+ }
+ omap2_mcspi_disable_clocks(mcspi);
+ return 0;
+}
+#else
+#defineomap2_mcspi_resume NULL
+#endif
+
static struct platform_driver omap2_mcspi_driver = {
.driver = {
.name = omap2_mcspi,
.owner =THIS_MODULE,
},
+ .resume = omap2_mcspi_resume,
.remove = __exit_p(omap2_mcspi_remove),
};
-- 1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/1] Put the OMAP2 SPI CS in inactive state when returning from suspend
We notice that when system wake up from OFF mode, then CS is in inactive state until the first SPI transfer. For our design it lead to some conflict on this I/O. Inactive state for CS when there is no transfer should be the correct behavior: this is the purpose of these patches. * Change from v2: Use directly resume function of spi_master instead of using function from spi_device as Grant Likely pointed it out. Force this transition explicitly for each CS used by a device. Gregory CLEMENT (1): OMAP2: Spi: Force CS to be in inactive state after off-mode transition drivers/spi/omap2_mcspi.c | 29 + 1 files changed, 29 insertions(+), 0 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/1] OMAP2: Spi: Force CS to be in inactive state after off-mode transition
When SPI wake up from OFF mode, CS is in the wrong state: force it to
the inactive state.
During the system life, I monitored the CS behavior using a
oscilloscope. I also activated debug in omap2_mcspi, so I saw when
driver disable the clocks and
Each time the CS was in the correct state.
It was only when system was put suspend to ram with off-mode activated
that on resume the CS was in wrong state( ie activated).
Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
drivers/spi/omap2_mcspi.c | 29 +
1 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
index 2a651e6..708990e 100644
--- a/drivers/spi/omap2_mcspi.c
+++ b/drivers/spi/omap2_mcspi.c
@@ -1305,11 +1305,40 @@ static int __exit omap2_mcspi_remove(struct
platform_device *pdev)
/* work with hotplug and coldplug */
MODULE_ALIAS(platform:omap2_mcspi);
+#ifdefCONFIG_PM
+/* When SPI wake up, CS is in wrong state: force it to unactive state*/
+static int omap2_mcspi_resume(struct platform_device *pdev)
+{
+ struct spi_master *master;
+ struct omap2_mcspi *mcspi;
+ struct omap2_mcspi_cs *cs;
+
+ master = dev_get_drvdata(pdev-dev);
+ mcspi = spi_master_get_devdata(master);
+ omap2_mcspi_enable_clocks(master);
+ /* We need to togle CS state for OMAP take this chang in account*/
+
+ list_for_each_entry(cs, omap2_mcspi_ctx[master-bus_num - 1].cs,
+ node)
+{
+MOD_REG_BIT(cs-chconf0, OMAP2_MCSPI_CHCONF_FORCE, 1);
+ __raw_writel(cs-chconf0, cs-base + OMAP2_MCSPI_CHCONF0);
+MOD_REG_BIT(cs-chconf0, OMAP2_MCSPI_CHCONF_FORCE, 0);
+ __raw_writel(cs-chconf0, cs-base + OMAP2_MCSPI_CHCONF0);
+}
+ omap2_mcspi_disable_clocks(master);
+return 0;
+}
+#else
+#defineomap2_mcspi_resume NULL
+#endif
+
static struct platform_driver omap2_mcspi_driver = {
.driver = {
.name = omap2_mcspi,
.owner =THIS_MODULE,
},
+ .resume = omap2_mcspi_resume,
.remove = __exit_p(omap2_mcspi_remove),
};
-- 1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/1] OMAP2: Spi: Force CS to be in inactive state after off-mode transition
On 11/12/2010 09:37 PM, Kevin Hilman wrote:
Gregory CLEMENTgregory.clem...@free-electrons.com writes:
When SPI wake up from OFF mode, CS is in the wrong state: force it to
the inactive state.
During the system life, I monitored the CS behavior using a
oscilloscope. I also activated debug in omap2_mcspi, so I saw when
driver disable the clocks and
Each time the CS was in the correct state.
It was only when system was put suspend to ram with off-mode activated
that on resume the CS was in wrong state( ie activated).
Signed-off-by: Gregory CLEMENTgregory.clem...@free-electrons.com
Lots of whitespace issues in this patch, please run through checkpatch.
Right, I forgot to use it this time.
---
drivers/spi/omap2_mcspi.c | 29 +
1 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
index 2a651e6..708990e 100644
--- a/drivers/spi/omap2_mcspi.c
+++ b/drivers/spi/omap2_mcspi.c
@@ -1305,11 +1305,40 @@ static int __exit omap2_mcspi_remove(struct
platform_device *pdev)
/* work with hotplug and coldplug */
MODULE_ALIAS(platform:omap2_mcspi);
+#ifdef CONFIG_PM
+/* When SPI wake up, CS is in wrong state: force it to unactive state*/
This comment should be more specific that only this condition happens
only on off-mode wakeups
OK it will be added in the next version.
+static int omap2_mcspi_resume(struct platform_device *pdev)
+{
+ struct spi_master *master;
+ struct omap2_mcspi *mcspi;
+ struct omap2_mcspi_cs *cs;
+
+ master = dev_get_drvdata(pdev-dev);
+ mcspi = spi_master_get_devdata(master);
+ omap2_mcspi_enable_clocks(master);
insert blank line here
+ /* We need to togle CS state for OMAP take this chang in account*/
+
remove blank line here
+ list_for_each_entry(cs,omap2_mcspi_ctx[master-bus_num - 1].cs,
+ node)
+{
this '{' belongs on like above
+MOD_REG_BIT(cs-chconf0, OMAP2_MCSPI_CHCONF_FORCE, 1);
+ __raw_writel(cs-chconf0, cs-base + OMAP2_MCSPI_CHCONF0);
+MOD_REG_BIT(cs-chconf0, OMAP2_MCSPI_CHCONF_FORCE, 0);
+ __raw_writel(cs-chconf0, cs-base + OMAP2_MCSPI_CHCONF0);
+}
Rather than force the state to a hard-coded value, it seems better if
the driver instead restore the previous state, which could be saved
during suspend.
Well it would be surprising that driver was suspended in middle of a
transaction (CS in active state). But it is pretty easy to get this
information, so I will do this. It will be indeed cleaner.
+ omap2_mcspi_disable_clocks(master);
+return 0;
+}
+#else
+#defineomap2_mcspi_resume NULL
+#endif
+
static struct platform_driver omap2_mcspi_driver = {
.driver = {
.name = omap2_mcspi,
.owner =THIS_MODULE,
},
+ .resume = omap2_mcspi_resume,
.remove = __exit_p(omap2_mcspi_remove),
};
-- 1.7.0.4
Kevin
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 0/1] Put the OMAP2 SPI CS in inactive state when returning from suspend
We notice that when system wake up from OFF mode, then CS is in inactive state until the first SPI transfer. For our design it lead to some conflict on this I/O. Inactive state for CS when there is no transfer should be the correct behavior: this is the purpose of these patches. * Change from v3: Patch clean-up according to Kevin Hilman and checkpatch. Now force CS to be in inactive state only if it was inactive when it was suspended. Gregory CLEMENT (1): OMAP2: Spi: Force CS to be in inactive state after off-mode transition drivers/spi/omap2_mcspi.c | 35 +++ 1 files changed, 35 insertions(+), 0 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/1] OMAP2: Spi: Force CS to be in inactive state after off-mode transition
When SPI wake up from OFF mode, CS is in the wrong state: force it to
the inactive state.
During the system life, I monitored the CS behavior using a oscilloscope.
I also activated debug in omap2_mcspi, so I saw when driver disable the
clocks and restore context when device is not used.
Each time the CS was in the correct state.
It was only when system was put suspend to ram with off-mode activated
that on resume the CS was in wrong state( ie activated).
Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
drivers/spi/omap2_mcspi.c | 35 +++
1 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
index 2a651e6..43d92fc 100644
--- a/drivers/spi/omap2_mcspi.c
+++ b/drivers/spi/omap2_mcspi.c
@@ -1305,11 +1305,46 @@ static int __exit omap2_mcspi_remove(struct
platform_device *pdev)
/* work with hotplug and coldplug */
MODULE_ALIAS(platform:omap2_mcspi);
+#ifdefCONFIG_PM
+/* When SPI wake up from off-mode, CS is in activate state. If it was in
+ * unactive state when driver was suspend, then force it to unactive
state at
+ * wake up.
+ */
+static int omap2_mcspi_resume(struct platform_device *pdev)
+{
+ struct spi_master *master;
+ struct omap2_mcspi_cs *cs;
+ struct omap2_mcspi *mcspi;
+
+ master = dev_get_drvdata(pdev-dev);
+ mcspi = spi_master_get_devdata(master);
+ omap2_mcspi_enable_clocks(mcspi);
+ list_for_each_entry(cs, omap2_mcspi_ctx[master-bus_num - 1].cs,
+ node) {
+ if ((cs-chconf0 OMAP2_MCSPI_CHCONF_FORCE) == 0) {
+
+ /* We need to togle CS state for OMAP take this
+* change in account.
+*/
+ MOD_REG_BIT(cs-chconf0, OMAP2_MCSPI_CHCONF_FORCE, 1);
+ __raw_writel(cs-chconf0, cs-base +
OMAP2_MCSPI_CHCONF0);
+ MOD_REG_BIT(cs-chconf0, OMAP2_MCSPI_CHCONF_FORCE, 0);
+ __raw_writel(cs-chconf0, cs-base +
OMAP2_MCSPI_CHCONF0);
+ }
+ }
+ omap2_mcspi_disable_clocks(mcspi);
+ return 0;
+}
+#else
+#defineomap2_mcspi_resume NULL
+#endif
+
static struct platform_driver omap2_mcspi_driver = {
.driver = {
.name = omap2_mcspi,
.owner =THIS_MODULE,
},
+ .resume = omap2_mcspi_resume,
.remove = __exit_p(omap2_mcspi_remove),
};
-- 1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] spi: Force CS to be in inactive state after off-mode transition
On 11/11/2010 10:34 AM, Hemanth V wrote:
- Original Message - From: Gregory CLEMENT
gregory.clem...@free-electrons.com
To: spi-devel-general spi-devel-gene...@lists.sourceforge.net;
linux-omap linux-omap@vger.kernel.org
Cc: David Brownell dbrown...@users.sourceforge.net; Grant Likely
grant.lik...@secretlab.ca; Kevin Hilman khil...@deeprootsystems.com
Sent: Wednesday, November 10, 2010 4:02 PM
Subject: [PATCH v2 2/2] spi: Force CS to be in inactive state after
off-mode transition
When SPI wake up from OFF mode, CS is in the wrong state: force it to
the inactive state.
During the system life, I monitored the CS behavior using a
oscilloscope. I also activated debug in omap2_mcspi, so I saw when
driver disable the clocks and restore context when device is not used.
Each time the CS was in the correct state.
It was only when system was put suspend to ram with off-mode activated
that on resume the CS was in wrong state( ie activated).
Just to confirm the understanding. Are saying CHCONF[6] EPOL bit
setting and CS state did not match and is actually a hardware bug. If so
could u let us know which platform u are testing this on.
Well I am not sure it is related to CHCONF[6] EPOL bit. During exchange
on SPI, CS is in the good state. But when system wake up from an
off-mode, CS is in its active state (high state for our configuration).
I thought it was more a problem with CHCONF[20] FORCE bit, indeed this
bit is at 0, so CS should be in low state. It is only when we first set
this bit to 1 and then to 0, that CS go to low state.
It sounds like an hardware bug on this bit, or let's say an undocumented
feature ;)
CS stay in high state until the next transaction on the SPI bus, indeed
as the driver use CHCONF[20] FORCE bit during exchange, it will do the
transition on this bit. That's why nobody noticed it until now, because
from the software point of view it works.
I didn't test it with CHCONF[6] EPOL bit set to 1.
Our silicon revision was OMAP3530-GP ES3.1.
Thanks
Hemanth
Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
drivers/spi/omap2_mcspi.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
index 2a651e6..938f14c 100644
--- a/drivers/spi/omap2_mcspi.c
+++ b/drivers/spi/omap2_mcspi.c
@@ -1139,6 +1139,15 @@ static u8 __initdata spi4_txdma_id[] = {
};
#endif
+/* When SPI wake up, CS is in wrong state: force it to unactive state*/
+static void omap2_mcspi_resume(struct spi_device *spi)
+{
+ omap2_mcspi_enable_clocks( spi_master_get_devdata(spi-master));
+ /* We need to togle CS state for OMAP take this chang in account*/
+ omap2_mcspi_force_cs(spi, 1);
+ omap2_mcspi_force_cs(spi, 0);
+ omap2_mcspi_disable_clocks( spi_master_get_devdata(spi-master));
+}
static int __init omap2_mcspi_probe(struct platform_device *pdev)
{
struct spi_master *master;
@@ -1194,6 +1203,7 @@ static int __init omap2_mcspi_probe(struct
platform_device *pdev)
master-transfer = omap2_mcspi_transfer;
master-cleanup = omap2_mcspi_cleanup;
master-num_chipselect = num_chipselect;
+ master-resume = omap2_mcspi_resume;
dev_set_drvdata(pdev-dev, master);
-- 1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] spi: Force CS to be in inactive state after off-mode transition
When SPI wake up from OFF mode, CS is in the wrong state: force it to
the inactive state.
During the system life, I monitored the CS behavior using a
oscilloscope. I also activated debug in omap2_mcspi, so I saw when
driver disable the clocks and restore context when device is not used.
Each time the CS was in the correct state.
It was only when system was put suspend to ram with off-mode activated
that on resume the CS was in wrong state( ie activated).
Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
drivers/spi/omap2_mcspi.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
index 2a651e6..938f14c 100644
--- a/drivers/spi/omap2_mcspi.c
+++ b/drivers/spi/omap2_mcspi.c
@@ -1139,6 +1139,15 @@ static u8 __initdata spi4_txdma_id[] = {
};
#endif
+/* When SPI wake up, CS is in wrong state: force it to unactive state*/
+static void omap2_mcspi_resume(struct spi_device *spi)
+{
+ omap2_mcspi_enable_clocks( spi_master_get_devdata(spi-master));
+ /* We need to togle CS state for OMAP take this chang in account*/
+ omap2_mcspi_force_cs(spi, 1);
+ omap2_mcspi_force_cs(spi, 0);
+ omap2_mcspi_disable_clocks( spi_master_get_devdata(spi-master));
+}
static int __init omap2_mcspi_probe(struct platform_device *pdev)
{
struct spi_master *master;
@@ -1194,6 +1203,7 @@ static int __init omap2_mcspi_probe(struct
platform_device *pdev)
master-transfer = omap2_mcspi_transfer;
master-cleanup = omap2_mcspi_cleanup;
master-num_chipselect = num_chipselect;
+ master-resume = omap2_mcspi_resume;
dev_set_drvdata(pdev-dev, master);
-- 1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] spi: Force CS to be in inactive state after off-mode transition
On 11/10/2010 04:57 PM, Grant Likely wrote:
On Wed, Nov 10, 2010 at 11:32:59AM +0100, Gregory CLEMENT wrote:
When SPI wake up from OFF mode, CS is in the wrong state: force it
to the inactive state.
During the system life, I monitored the CS behavior using a
oscilloscope. I also activated debug in omap2_mcspi, so I saw when
driver disable the clocks and restore context when device is not
used.
Each time the CS was in the correct state.
It was only when system was put suspend to ram with off-mode
activated that on resume the CS was in wrong state( ie activated).
Sounds like a bug in the suspend/resume path of the spi_master, not
the spi_device. Trying to work around it via the spi_device resume
path is the wrong approach.
OK it was not clear to me that spi_resume() and spi_suspend() were
specifics to devices as these functions belong to a bus structure.
So you suggest to use the suspend/resume functions of the
platform_driver structure of omap2_mcspi_driver, right?
g.
Signed-off-by: Gregory CLEMENTgregory.clem...@free-electrons.com
---
drivers/spi/omap2_mcspi.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
index 2a651e6..938f14c 100644
--- a/drivers/spi/omap2_mcspi.c
+++ b/drivers/spi/omap2_mcspi.c
@@ -1139,6 +1139,15 @@ static u8 __initdata spi4_txdma_id[] = {
};
#endif
+/* When SPI wake up, CS is in wrong state: force it to unactive state*/
+static void omap2_mcspi_resume(struct spi_device *spi)
+{
+ omap2_mcspi_enable_clocks( spi_master_get_devdata(spi-master));
+ /* We need to togle CS state for OMAP take this chang in account*/
+ omap2_mcspi_force_cs(spi, 1);
+ omap2_mcspi_force_cs(spi, 0);
+ omap2_mcspi_disable_clocks( spi_master_get_devdata(spi-master));
+}
static int __init omap2_mcspi_probe(struct platform_device *pdev)
{
struct spi_master *master;
@@ -1194,6 +1203,7 @@ static int __init omap2_mcspi_probe(struct
platform_device *pdev)
master-transfer = omap2_mcspi_transfer;
master-cleanup = omap2_mcspi_cleanup;
master-num_chipselect = num_chipselect;
+ master-resume = omap2_mcspi_resume;
dev_set_drvdata(pdev-dev, master);
-- 1.7.0.4
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] Put OMAP2 SPI CS in unactive state when return from suspend
We notice that when system wake up from OFF mode, then CS is in unactive state until the first SPI transfert. For our design it lead to some conflict on this I/O. Unactive state for CS when there is no transfert shoudl be the correct behaviour: this is the purpose of these patches. Gregory CLEMENT (2): spi: Add hook on suspend/resume for spi master spi/omap2_mcspi: When SPI wake up from OFF mode, CS is in wrong state: force it to unactive state drivers/spi/omap2_mcspi.c | 11 ++- drivers/spi/spi.c | 15 ++- include/linux/spi/spi.h |4 +++- 3 files changed, 27 insertions(+), 3 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] spi: Add hook on suspend/resume for spi master
Some spi master need to do some action when system is going to suspend
or when it will be resumed.
Spi driver offer possibility to handle suspend and resume only for device.
Spi master will do its suspend actions after the devices and will do
its resume action before the devices.
Signed-off-by: Gregory CLEMENT gclemen...@gmail.com
---
drivers/spi/spi.c | 15 ++-
include/linux/spi/spi.h |4 +++-
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 1bb1b88..fe8140e 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -17,7 +17,6 @@
* along with this program; if not, write to the Free Software
* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
-
#include linux/kernel.h
#include linux/device.h
#include linux/init.h
@@ -106,6 +105,11 @@ static int spi_suspend(struct device *dev,
pm_message_t message)
{
int value = 0;
struct spi_driver *drv = to_spi_driver(dev-driver);
+ struct spi_device *spi_dev = to_spi_device(dev);
+ struct spi_master *master = NULL;
+
+ if (spi_dev)
+ master = spi_dev-master;
/* suspend will stop irqs and dma; no more i/o */
if (drv) {
@@ -114,6 +118,9 @@ static int spi_suspend(struct device *dev,
pm_message_t message)
else
dev_dbg(dev, ... can't suspend\n);
}
+ if (master master-suspend )
+ master-suspend(spi_dev);
+
return value;
}
@@ -121,7 +128,11 @@ static int spi_resume(struct device *dev)
{
int value = 0;
struct spi_driver *drv = to_spi_driver(dev-driver);
+ struct spi_device *spi_dev = to_spi_device(dev);
+ struct spi_master *master = NULL;
+ if (spi_dev)
+ master = spi_dev-master;
/* resume may restart the i/o queue */
if (drv) {
if (drv-resume)
@@ -129,6 +140,8 @@ static int spi_resume(struct device *dev)
else
dev_dbg(dev, ... can't resume\n);
}
+ if (master master-resume )
+ master-resume(spi_dev);
return value;
}
diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
index af56071..2483a1d 100644
--- a/include/linux/spi/spi.h
+++ b/include/linux/spi/spi.h
@@ -293,7 +293,9 @@ struct spi_master {
struct spi_message *mesg);
/* called on release() to free memory provided by spi_master */
- void(*cleanup)(struct spi_device *spi);
+void (*cleanup)(struct spi_device *spi);
+ void (*suspend)(struct spi_device *spi);
+ void (*resume)(struct spi_device *spi);
};
static inline void *spi_master_get_devdata(struct spi_master *master)
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 1bb1b88..fe8140e 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -17,7 +17,6 @@
* along with this program; if not, write to the Free Software
* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
-
#include linux/kernel.h
#include linux/device.h
#include linux/init.h
@@ -106,6 +105,11 @@ static int spi_suspend(struct device *dev, pm_message_t message)
{
int value = 0;
struct spi_driver *drv = to_spi_driver(dev-driver);
+ struct spi_device *spi_dev = to_spi_device(dev);
+ struct spi_master *master = NULL;
+
+ if (spi_dev)
+ master = spi_dev-master;
/* suspend will stop irqs and dma; no more i/o */
if (drv) {
@@ -114,6 +118,9 @@ static int spi_suspend(struct device *dev, pm_message_t message)
else
dev_dbg(dev, ... can't suspend\n);
}
+ if (master master-suspend )
+ master-suspend(spi_dev);
+
return value;
}
@@ -121,7 +128,11 @@ static int spi_resume(struct device *dev)
{
int value = 0;
struct spi_driver *drv = to_spi_driver(dev-driver);
+ struct spi_device *spi_dev = to_spi_device(dev);
+ struct spi_master *master = NULL;
+ if (spi_dev)
+ master = spi_dev-master;
/* resume may restart the i/o queue */
if (drv) {
if (drv-resume)
@@ -129,6 +140,8 @@ static int spi_resume(struct device *dev)
else
dev_dbg(dev, ... can't resume\n);
}
+ if (master master-resume )
+ master-resume(spi_dev);
return value;
}
diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
index af56071..2483a1d 100644
--- a/include/linux/spi/spi.h
+++ b/include/linux/spi/spi.h
@@ -293,7 +293,9 @@ struct spi_master {
struct spi_message *mesg);
/* called on release() to free memory provided by spi_master */
- void (*cleanup)(struct spi_device *spi);
+void (*cleanup)(struct spi_device *spi);
+ void (*suspend)(struct spi_device *spi);
+ void (*resume)(struct spi_device *spi);
};
static inline void *spi_master_get_devdata(struct spi_master *master)
[PATCH 2/2] spi/omap2_mcspi: When SPI wake up from OFF mode, CS is in wrong state: force it to unactive state
When SPI wake up from OFF mode, CS is in wrong state: force it to unactive state
Signed-off-by: Gregory CLEMENT gclemen...@gmail.com
---
drivers/spi/omap2_mcspi.c | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
index b3a94ca..3083bd0 100644
--- a/drivers/spi/omap2_mcspi.c
+++ b/drivers/spi/omap2_mcspi.c
@@ -1137,7 +1137,15 @@ static u8 __initdata spi4_txdma_id[] = {
OMAP34XX_DMA_SPI4_TX0,
};
#endif
-
+/* When SPI wake up, CS is in wrong state: force it to unactive state*/
+static void omap2_mcspi_resume(struct spi_device *spi)
+{
+ omap2_mcspi_enable_clocks( spi_master_get_devdata(spi-master));
+/* We need to togle CS state for OMAP take this chang in account*/
+ omap2_mcspi_force_cs(spi, 1);
+ omap2_mcspi_force_cs(spi, 0);
+ omap2_mcspi_disable_clocks( spi_master_get_devdata(spi-master));
+}
static int __init omap2_mcspi_probe(struct platform_device *pdev)
{
struct spi_master *master;
@@ -1193,6 +1201,7 @@ static int __init omap2_mcspi_probe(struct
platform_device *pdev)
master-transfer = omap2_mcspi_transfer;
master-cleanup = omap2_mcspi_cleanup;
master-num_chipselect = num_chipselect;
+ master-resume = omap2_mcspi_resume;
dev_set_drvdata(pdev-dev, master);
diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
index b3a94ca..3083bd0 100644
--- a/drivers/spi/omap2_mcspi.c
+++ b/drivers/spi/omap2_mcspi.c
@@ -1137,7 +1137,15 @@ static u8 __initdata spi4_txdma_id[] = {
OMAP34XX_DMA_SPI4_TX0,
};
#endif
-
+/* When SPI wake up, CS is in wrong state: force it to unactive state*/
+static void omap2_mcspi_resume(struct spi_device *spi)
+{
+ omap2_mcspi_enable_clocks( spi_master_get_devdata(spi-master));
+/* We need to togle CS state for OMAP take this chang in account*/
+ omap2_mcspi_force_cs(spi, 1);
+ omap2_mcspi_force_cs(spi, 0);
+ omap2_mcspi_disable_clocks( spi_master_get_devdata(spi-master));
+}
static int __init omap2_mcspi_probe(struct platform_device *pdev)
{
struct spi_master *master;
@@ -1193,6 +1201,7 @@ static int __init omap2_mcspi_probe(struct platform_device *pdev)
master-transfer = omap2_mcspi_transfer;
master-cleanup = omap2_mcspi_cleanup;
master-num_chipselect = num_chipselect;
+ master-resume = omap2_mcspi_resume;
dev_set_drvdata(pdev-dev, master);
Re: [PATCH v3 0/3] usb: ohci: introduce ohci-hcd driver for omap3
Le 26 avril 2010 08:02:55 UTC+2, Gadiyar, Anand gadi...@ti.com a écrit : Gregory CLEMENT wrote: This controller supports multiple interface modes. Only 2 of them (3-pin DAT/SE0 and 4-pin DP/DM PHY modes) have been tested with this driver. (However the only change for the other modes is one register setting for selecting the mode, and the padconf setting for the omap pads, so I expect it to work correctly). (Someone did offer to test the 6-pin mode. Still awaiting results...) I am the one who offer to test 6-pin mode. Unfortunally, I still have some problem. The current version of our kernel is 2.6.33 so first I try to back port your patch for our version, and so kernel crashes during access to USB controller. Then I try to port our kernel to the last version of Linux, but now I can't see any traces on serial port after Uncompressing Linux... done, booting the kernel... I am still stuck to these problems which are not really related to your patches. Could you enable CONFIG_EARLY_PRINTK and add earlyprintk to your bootargs? This might throw up some messages on the console that can show where the problem is. I already enable CONFIG_EARLY_PRINTK but I didn't add earlyprintk,I though setting the config was enough, I will try this! Which debug console are you using? Is it an OMAP UART or something external like in some newer boards? I use the same UART that beagle board: UART3 Thanks for your help - Anand -- Gregory CLEMENT Responsable Technique Linux embarqué - Europe Embedded Linux Development Lead - EMEA Adeneo Embedded - Adetel Group 2, chemin du Ruisseau 69134 ECULLY - FRANCE Tél. : +33 (0)4 72 18 08 40 - Fax : +33 (0)4 72 18 08 41 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/3] usb: ohci: introduce ohci-hcd driver for omap3
2010/4/26 Anand Gadiyar gadi...@ti.com Hi all, This patch series adds the bus glue layer for the OHCI controller on OMAP3 and later chips. This controller is a companion to the EHCI controller on that chip, and some code is common between the two drivers. The driver has been sitting in internal trees for ages, and I've finally found time to clean it up and submit it. The older OMAP1 and OMAP2 chips had a different OHCI controller, which already has driver support in mainline. I don't have access to any boards with this old controller and haven't tested the old driver on those boards - not sure if it still works. (Also, I made some updates to Kconfig, and have not yet updated the defconfigs for those omap1/2 boards. I'll update them if the Kconfig changes are okay) This controller supports multiple interface modes. Only 2 of them (3-pin DAT/SE0 and 4-pin DP/DM PHY modes) have been tested with this driver. (However the only change for the other modes is one register setting for selecting the mode, and the padconf setting for the omap pads, so I expect it to work correctly). (Someone did offer to test the 6-pin mode. Still awaiting results...) [sending it again with no html inside] Hi, I am the one who offer to test 6-pin mode. Unfortunally, I still have some problem. The current version of our kernel is 2.6.33 so first I try to back port your patch for our version, and so kernel crashes during access to USB controller. Then I try to port our kernel to the last version of Linux, but now I can't see any traces on serial port after Uncompressing Linux... done, booting the kernel... I am still stuck to these problems which are not really related to your patches. -- Gregory CLEMENT Responsable Technique Linux embarqué - Europe Embedded Linux Development Lead - EMEA Adeneo Embedded - Adetel Group 2, chemin du Ruisseau 69134 ECULLY - FRANCE Tél. : +33 (0)4 72 18 08 40 - Fax : +33 (0)4 72 18 08 41 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 0/5] usb: ohci: introduce ohci-hcd driver for omap3
Anand Gadiyar gadiyar at ti.com writes: Hi all, Hi Anand, (Apologies if you get this twice - I sent this out 24 hours ago, and it still hasn't reached the lists. So resending). This patch series adds the bus glue layer for the OHCI controller on OMAP3 and later chips. This controller is a companion to the EHCI controller on that IP, and some code is common across the drivers. The driver has been sitting in internal trees for ages, and I've finally found time to clean it up and submit it. This is a good news, one or two month ago we were looking for such a patch! Finally we take an old version that we adapt to just make it works. Our future plan was to clean it up and submit a correct version. As your version seems more advanced,we will take it and test it for our board. I hope be able to feed information by the end of the week. The older OMAP1 and OMAP2 chips had a different OHCI controller, which already has driver support in mainline. I don't have access to this and haven't tested the driver on those boards. (Also, I made some updates to Kconfig, and have not yet updated the defconfigs for those omap1/2 boards. I'll update them if the Kconfig changes are okay) This controller supports multiple interface modes. Only 2 of them (3-pin DAT/SE0 and 4-pin DP/DM PHY modes) have been tested with this driver. (However the only change for the other modes is one register setting for selecting the mode, and the padconf setting for the omap pads), so I expect it to work correctly with this version. If anyone has OMAP3 boards with an OHCI controller, please test. Our board use the 6-pin DP/DM PHY mode, so it will be a new mode to be validated Thanks, Anand -- Gregory CLEMENT Embedded Linux Development Lead - EMEA Adeneo Embedded - Adetel Group -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
