ARM: PXA: Z2: Use only power button as wake source

This patch is a part of similar mozzwald's patch which was based on GPSFan and rkdavis work.

Signed-off-by Vasily Khoruzhick <[email protected]>

---
v2: Fix authorship of original patch

 arch/arm/mach-pxa/z2.c |   24 ++++++++++++++++++++++++
 1 files changed, 24 insertions(+), 0 deletions(-)

arch/arm/mach-pxa/z2.c +21 -0

index 7bad4f7..dde3f1c 100644
@@ -40,6 +40,8 @@
 #include <mach/pxafb.h>
 #include <mach/mmc.h>
 #include <plat/pxa27x_keypad.h>
+#include <mach/pxa27x-udc.h>
+#include <mach/ohci.h>
 
 #include "generic.h"
 #include "devices.h"

@@ -679,6 +681,27 @@ static inline void z2_pmic_init(void) {}
 #endif
 
 /*************************************************************************
 ***** + * USB Host (OHCI)
+
 **************************************************************************
 ****/ +static int z2_ohci_init(struct device *dev)
+{
+	/* Only Port 2 is connected
+	 * Setup USB Port 2 Output Control Register
+	*/
+	UP2OCR = UP2OCR_HXS | UP2OCR_HXOE | UP2OCR_DPPDE | UP2OCR_DMPDE;
+
+	return 0;
+}
+
+static struct pxaohci_platform_data z2_ohci_platform_data = {
+	.port_mode	= PMM_PERPORT_MODE,
+	.init		= z2_ohci_init,
+	.flags		= ENABLE_PORT2 | NO_OC_PROTECTION,
+	.power_on_delay	= 10,
+	.power_budget	= 500,
+};
+
+/*************************************************************************

***** * Machine init

**************************************************************************
****/ static void __init z2_init(void)

arch/arm/mach-pxa/z2.c +1 -0

@@ -688,6 +711,7 @@ static void __init z2_init(void)
 	pxa_set_ffuart_info(NULL);
 	pxa_set_btuart_info(NULL);
 	pxa_set_stuart_info(NULL);
+	pxa_set_ohci_info(&z2_ohci_platform_data);
 
 	z2_lcd_init();
 	z2_mmc_init();

Quoted 2 lines · On Friday 11 March 2011 15:56:46 Vasily Khoruzhick wrote:

This patch is a part of similar mozzwald's patch which was based on GPSFan and rkdavis work.

Noone knows what/who is "mozzwald" or "rkdavis" or "GPSFan", the comment for this patch is irelevant and has zero information value.

I also suspect, the pins on the back connector are USB UDC, not UHC ... aka. the hardware has no UHC.

Quoted 6 lines · On Friday 11 March 2011 23:42:30 Marek Vasut wrote:

Quoted 2 lines · On Friday 11 March 2011 15:56:46 Vasily Khoruzhick wrote:

This patch is a part of similar mozzwald's patch which was based on GPSFan and rkdavis work.

Noone knows what/who is "mozzwald" or "rkdavis" or "GPSFan", the comment for this patch is irelevant and has zero information value.

Heh, I can add 'from Zipit Z2 community', I don't know their actual names nor mail addresses.

Quoted 3 lines

I also suspect, the pins on the back connector are USB UDC, not UHC ... aka. the hardware has no UHC.

They are UHC, check http://www.mozzwald.com/node/60

Regards
Vasily

Quoted 10 lines · On Friday 11 March 2011 22:49:13 Vasily Khoruzhick wrote:

Quoted 6 lines · On Friday 11 March 2011 23:42:30 Marek Vasut wrote:

Quoted 2 lines · On Friday 11 March 2011 15:56:46 Vasily Khoruzhick wrote:

This patch is a part of similar mozzwald's patch which was based on GPSFan and rkdavis work.

Noone knows what/who is "mozzwald" or "rkdavis" or "GPSFan", the comment for this patch is irelevant and has zero information value.

Heh, I can add 'from Zipit Z2 community', I don't know their actual names nor mail addresses.

That's not the point. The point is the comment has zero value, it doesn't describe the change.

Quoted 4 lines

Quoted 2 lines

I also suspect, the pins on the back connector are USB UDC, not UHC ... aka. the hardware has no UHC.

They are UHC, check http://www.mozzwald.com/node/60

So it is compliant or is it a hack ?

Quoted 18 lines · On Friday 11 March 2011 23:50:56 Marek Vasut wrote:

Quoted 10 lines · On Friday 11 March 2011 22:49:13 Vasily Khoruzhick wrote:

Quoted 6 lines · On Friday 11 March 2011 23:42:30 Marek Vasut wrote:

Quoted 2 lines · On Friday 11 March 2011 15:56:46 Vasily Khoruzhick wrote:

This patch is a part of similar mozzwald's patch which was based on GPSFan and rkdavis work.

Noone knows what/who is "mozzwald" or "rkdavis" or "GPSFan", the comment for this patch is irelevant and has zero information value.

Heh, I can add 'from Zipit Z2 community', I don't know their actual names nor mail addresses.

That's not the point. The point is the comment has zero value, it doesn't describe the change.

Quoted 3 lines

Quoted 2 lines

I also suspect, the pins on the back connector are USB UDC, not UHC ... aka. the hardware has no UHC.

Quoted 3 lines

Quoted 1 line

They are UHC, check http://www.mozzwald.com/node/60

So it is compliant or is it a hack ?

PXA27x has OHCI (check datasheet), and it's wired to expansion connector, so you can use it with self-powered USB devices (Zipit Z2 provides only 3.3V on expansion connector). It's definitely not a hack.

Regards
Vasily

Quoted 23 lines · On Friday 11 March 2011 22:55:28 Vasily Khoruzhick wrote:

Quoted 21 lines · On Friday 11 March 2011 23:50:56 Marek Vasut wrote:

Quoted 10 lines · On Friday 11 March 2011 22:49:13 Vasily Khoruzhick wrote:

Quoted 6 lines · On Friday 11 March 2011 23:42:30 Marek Vasut wrote:

Quoted 2 lines · On Friday 11 March 2011 15:56:46 Vasily Khoruzhick wrote:

This patch is a part of similar mozzwald's patch which was based on GPSFan and rkdavis work.

Noone knows what/who is "mozzwald" or "rkdavis" or "GPSFan", the comment for this patch is irelevant and has zero information value.

Heh, I can add 'from Zipit Z2 community', I don't know their actual names nor mail addresses.

That's not the point. The point is the comment has zero value, it doesn't describe the change.

Quoted 4 lines

Quoted 2 lines

I also suspect, the pins on the back connector are USB UDC, not UHC ... aka. the hardware has no UHC.

They are UHC, check http://www.mozzwald.com/node/60

So it is compliant or is it a hack ?

Quoted 3 lines

PXA27x has OHCI (check datasheet), and it's wired to expansion connector, so you can use it with self-powered USB devices (Zipit Z2 provides only 3.3V on expansion connector). It's definitely not a hack.

This doesn't make me believe it's compliant. Besides, iirc the zipit hardware wiki says it's only meant for UDC. The fact you can reconfigure it for UHC and use it with a limited amount of devices if you're lucky makes me feel it's so much of a hack.

Quoted 30 lines · On Saturday 12 March 2011 00:13:51 Marek Vasut wrote:

Quoted 28 lines · On Friday 11 March 2011 22:55:28 Vasily Khoruzhick wrote:

Quoted 16 lines · On Friday 11 March 2011 23:50:56 Marek Vasut wrote:

Quoted 11 lines · On Friday 11 March 2011 22:49:13 Vasily Khoruzhick wrote:

Quoted 7 lines · On Friday 11 March 2011 23:42:30 Marek Vasut wrote:

Quoted 2 lines · On Friday 11 March 2011 15:56:46 Vasily Khoruzhick wrote:

This patch is a part of similar mozzwald's patch which was based on GPSFan and rkdavis work.

Noone knows what/who is "mozzwald" or "rkdavis" or "GPSFan", the comment for this patch is irelevant and has zero information value.

Heh, I can add 'from Zipit Z2 community', I don't know their actual names nor mail addresses.

That's not the point. The point is the comment has zero value, it doesn't describe the change.

Quoted 6 lines

Quoted 4 lines

Quoted 2 lines

I also suspect, the pins on the back connector are USB UDC, not UHC ... aka. the hardware has no UHC.

They are UHC, check http://www.mozzwald.com/node/60

So it is compliant or is it a hack ?

PXA27x has OHCI (check datasheet), and it's wired to expansion connector, so you can use it with self-powered USB devices (Zipit Z2 provides only 3.3V on expansion connector). It's definitely not a hack.

Quoted 4 lines

This doesn't make me believe it's compliant. Besides, iirc the zipit hardware wiki says it's only meant for UDC. The fact you can reconfigure it for UHC and use it with a limited amount of devices if you're lucky makes me feel it's so much of a hack.

AFAIK UDC pins are separate from UHC, so you can't use it as UDC. If I'm wrong, please correct me. Because UDC on Zipit is much more usefull for me than UHC :)

And, btw, you can connect powered hub to UHC and use ANY usb device with Zipit.
I can't understand why you think that it's a hack.

Regards
Vasily

Quoted 3 lines

AFAIK UDC pins are separate from UHC, so you can't use it as UDC. If I'm wrong, please correct me. Because UDC on Zipit is much more usefull for me than UHC :)

Check datasheet, they're likely the same pins.

Quoted 5 lines · On Saturday 12 March 2011 02:07:58 Marek Vasut wrote:

Quoted 3 lines

AFAIK UDC pins are separate from UHC, so you can't use it as UDC. If I'm wrong, please correct me. Because UDC on Zipit is much more usefull for me than UHC :)

Check datasheet, they're likely the same pins.

I still see no reason to drop this patch - USB host works pretty well on Zipit Z2.

Regards
Vasily

Quoted 5 lines · On Friday 11 March 2011 22:49:13 Vasily Khoruzhick wrote:

Quoted 4 lines · On Friday 11 March 2011 23:42:30 Marek Vasut wrote:

Quoted 2 lines · On Friday 11 March 2011 15:56:46 Vasily Khoruzhick wrote:

This patch is a part of similar mozzwald's patch which was based on GPSFan and rkdavis work.

Quoted 5 lines

Quoted 2 lines

Noone knows what/who is "mozzwald" or "rkdavis" or "GPSFan", the comment for this patch is irelevant and has zero information value.

Heh, I can add 'from Zipit Z2 community', I don't know their actual names nor mail addresses.

That's not the point. The point is the comment has zero value, it doesn't describe the change.

Quoted 9 lines · Marek Vasut

Quoted 8 lines · On Friday 11 March 2011 22:49:13 Vasily Khoruzhick wrote:

Quoted 6 lines · On Friday 11 March 2011 23:42:30 Marek Vasut wrote:

Quoted 2 lines · On Friday 11 March 2011 15:56:46 Vasily Khoruzhick wrote:

This patch is a part of similar mozzwald's patch which was based on GPSFan and rkdavis work.

Noone knows what/who is "mozzwald" or "rkdavis" or "GPSFan", the comment for this patch is irelevant and has zero information value.

Quoted 5 lines

Quoted 2 lines

Heh, I can add 'from Zipit Z2 community', I don't know their actual names nor mail addresses.

That's not the point. The point is the comment has zero value, it doesn't describe the change.

Credit where credit is due. Yes, it is polite to thank original authors.

Quoted 12 lines

Quoted 11 lines

Quoted 8 lines

Quoted 5 lines

Quoted 2 lines

This patch is a part of similar mozzwald's patch which was based on GPSFan and rkdavis work.

Noone knows what/who is "mozzwald" or "rkdavis" or "GPSFan", the comment for this patch is irelevant and has zero information value.

Heh, I can add 'from Zipit Z2 community', I don't know their actual names nor mail addresses.

That's not the point. The point is the comment has zero value, it doesn't describe the change.

Quoted 2 lines

Credit where credit is due. Yes, it is polite to thank original authors.

Doesn't it remind you of something ... ?

http://lwn.net/Articles/195643/

Maybe their true identity should be there as well.

Hi!

Quoted 16 lines

Quoted 15 lines

Quoted 7 lines

Quoted 7 lines

Quoted 6 lines

Quoted 2 lines

This patch is a part of similar mozzwald's patch which was based on GPSFan and rkdavis work.

Noone knows what/who is "mozzwald" or "rkdavis" or "GPSFan", the comment for this patch is irelevant and has zero information value.

Quoted 5 lines

Quoted 2 lines

Heh, I can add 'from Zipit Z2 community', I don't know their actual names nor mail addresses.

That's not the point. The point is the comment has zero value, it doesn't describe the change.

Credit where credit is due. Yes, it is polite to thank original authors.

Quoted 5 lines

Doesn't it remind you of something ... ?

http://lwn.net/Articles/195643/

Maybe their true identity should be there as well.

This is credits, not signed-off-by, and I don't think this has similar trade secrets risks...

Pavel

Actually it does ... how to connect the USB UDC is under Aeronix NDA (even the fact the UHC pins are on the connector is under NDA ;-) )

Patch is based on mozzwald's work.

Signed-off-by Vasily Khoruzhick <[email protected]>

---
 arch/arm/mach-pxa/z2.c |   24 ++++++++++++++++++++++++
 1 files changed, 24 insertions(+), 0 deletions(-)

arch/arm/mach-pxa/z2.c +21 -0

index 7bad4f7..dde3f1c 100644
@@ -40,6 +40,8 @@
 #include <mach/pxafb.h>
 #include <mach/mmc.h>
 #include <plat/pxa27x_keypad.h>
+#include <mach/pxa27x-udc.h>
+#include <mach/ohci.h>
 
 #include "generic.h"
 #include "devices.h"

@@ -679,6 +681,27 @@ static inline void z2_pmic_init(void) {}
 #endif
 
 /*************************************************************************
 ***** + * USB Host (OHCI)
+
 **************************************************************************
 ****/ +static int z2_ohci_init(struct device *dev)
+{
+	/* Only Port 2 is connected
+	 * Setup USB Port 2 Output Control Register
+	*/
+	UP2OCR = UP2OCR_HXS | UP2OCR_HXOE | UP2OCR_DPPDE | UP2OCR_DMPDE;
+
+	return 0;
+}
+
+static struct pxaohci_platform_data z2_ohci_platform_data = {
+	.port_mode	= PMM_PERPORT_MODE,
+	.init		= z2_ohci_init,
+	.flags		= ENABLE_PORT2 | NO_OC_PROTECTION,
+	.power_on_delay	= 10,
+	.power_budget	= 500,
+};
+
+/*************************************************************************

***** * Machine init

**************************************************************************
****/ static void __init z2_init(void)

arch/arm/mach-pxa/z2.c +1 -0

@@ -688,6 +711,7 @@ static void __init z2_init(void)
 	pxa_set_ffuart_info(NULL);
 	pxa_set_btuart_info(NULL);
 	pxa_set_stuart_info(NULL);
+	pxa_set_ohci_info(&z2_ohci_platform_data);
 
 	z2_lcd_init();
 	z2_mmc_init();

Fix coefficients to get actual voltage, and make voltage_max/voltage_min looks like values for LiIon battery.

Signed-off-by Vasily Khoruzhick <[email protected]>

---
 arch/arm/mach-pxa/z2.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

arch/arm/mach-pxa/z2.c +3 -3

index dde3f1c..bffb920 100644
@@ -463,9 +463,9 @@ static struct z2_battery_info batt_chip_info = {
 	.batt_I2C_addr	= 0x55,
 	.batt_I2C_reg	= 2,
 	.charge_gpio	= GPIO0_ZIPITZ2_AC_DETECT,
-	.min_voltage	= 2400000,
-	.max_voltage	= 3700000,
-	.batt_div	= 69,
+	.min_voltage	= 3475000,
+	.max_voltage	= 4190000,
+	.batt_div	= 59,
 	.batt_mult	= 1000000,
 	.batt_tech	= POWER_SUPPLY_TECHNOLOGY_LION,
 	.batt_name	= "Z2",

Signed-off-by Vasily Khoruzhick <[email protected]>

---
 arch/arm/mach-pxa/z2.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

arch/arm/mach-pxa/z2.c +4 -0

index bffb920..aec87f7 100644
@@ -169,6 +169,10 @@ static struct mtd_partition z2_flash_parts[] = {
 	}, {
 		.name	= "Flash",
 		.offset	= 0x60000,
+		.size	= 0x780000,
+	}, {
+		.name	= "U-Boot Logo",
+		.offset = 0x7e0000,
 		.size	= MTDPART_SIZ_FULL,
 	},
 };

Quoted 1 line · On Friday 11 March 2011 11:23:39 Vasily Khoruzhick wrote:

Signed-off-by Vasily Khoruzhick <[email protected]>

I guess you can rather supply the MTD layout on kernel command line (see Drivers/MTD).

Quoted 5 lines · On Friday 11 March 2011 23:39:36 Marek Vasut wrote:

Quoted 1 line · On Friday 11 March 2011 11:23:39 Vasily Khoruzhick wrote:

Signed-off-by Vasily Khoruzhick <[email protected]>

I guess you can rather supply the MTD layout on kernel command line (see Drivers/MTD).

Yeah, I know, just want to make default layout look like this.

Quoted 4 lines · On Friday 11 March 2011 23:31:28 Vasily Khoruzhick wrote:

Quoted 3 lines · On Friday 11 March 2011 23:39:36 Marek Vasut wrote:

Quoted 1 line · On Friday 11 March 2011 11:23:39 Vasily Khoruzhick wrote:

Signed-off-by Vasily Khoruzhick <[email protected]>

Quoted 4 lines

Quoted 2 lines

I guess you can rather supply the MTD layout on kernel command line (see Drivers/MTD).

Yeah, I know, just want to make default layout look like this.

Why not like what's already there ? I don't see any point in changing this, NAK, use command line partitioning.

Quoted 8 lines · Marek Vasut

Quoted 7 lines · On Friday 11 March 2011 23:31:28 Vasily Khoruzhick wrote:

Quoted 5 lines · On Friday 11 March 2011 23:39:36 Marek Vasut wrote:

Quoted 1 line · On Friday 11 March 2011 11:23:39 Vasily Khoruzhick wrote:

Signed-off-by Vasily Khoruzhick <[email protected]>

I guess you can rather supply the MTD layout on kernel command line (see Drivers/MTD).

Quoted 4 lines

Quoted 1 line

Yeah, I know, just want to make default layout look like this.

Why not like what's already there ? I don't see any point in changing this, NAK, use command line partitioning.

Of course, you can use command line.

But, the default kernel partitioning should match what hw expects.

Quoted 14 lines · On Tuesday 15 March 2011 15:39:57 Pavel Machek wrote:

Quoted 12 lines · Marek Vasut

Quoted 8 lines · On Friday 11 March 2011 23:31:28 Vasily Khoruzhick wrote:

Quoted 5 lines · On Friday 11 March 2011 23:39:36 Marek Vasut wrote:

Quoted 1 line · On Friday 11 March 2011 11:23:39 Vasily Khoruzhick wrote:

Signed-off-by Vasily Khoruzhick <[email protected]>

I guess you can rather supply the MTD layout on kernel command line (see Drivers/MTD).

Yeah, I know, just want to make default layout look like this.

Why not like what's already there ? I don't see any point in changing this, NAK, use command line partitioning.

Quoted 3 lines

Of course, you can use command line.

But, the default kernel partitioning should match what hw expects.

But of course ... it matches the mainline uboot. I know what I let in there :)

Signed-off-by Vasily Khoruzhick <[email protected]>

---
 arch/arm/mach-pxa/z2.c |   13 +++++++++++++
 1 files changed, 13 insertions(+), 0 deletions(-)

arch/arm/mach-pxa/z2.c +11 -0

index aec87f7..f1bb98a 100644
@@ -42,6 +42,7 @@
 #include <plat/pxa27x_keypad.h>
 #include <mach/pxa27x-udc.h>
 #include <mach/ohci.h>
+#include <mach/pm.h>
 
 #include "generic.h"
 #include "devices.h"

@@ -705,6 +706,16 @@ static struct pxaohci_platform_data
 z2_ohci_platform_data = { .power_budget	= 500,
 };
 
+#ifdef CONFIG_PM
+static void z2_power_off(void)
+{
+	local_irq_disable();
+	pxa27x_cpu_suspend(PWRMODE_DEEPSLEEP);
+}
+#else
+#define z2_power_off   NULL
+#endif
+
 /*************************************************************************
 ***** * Machine init
 

**************************************************************************
****/ @@ -727,6 +738,8 @@ static void __init z2_init(void)

arch/arm/mach-pxa/z2.c +2 -0

 	z2_leds_init();
 	z2_keys_init();
 	z2_pmic_init();
+
+	pm_power_off = z2_power_off;
 }
 
 MACHINE_START(ZIPIT2, "Zipit Z2")

Quoted 1 line · On Friday 11 March 2011 11:23:40 Vasily Khoruzhick wrote:

Signed-off-by Vasily Khoruzhick <[email protected]>

This looks bogus to me as you cannot power down the thing. Besides, where do you resume to from this so-called "powerdown" ? Since the bootloader will consider it as a legitimate deepsleep resume.

Quoted 6 lines · On Friday 11 March 2011 23:39:03 Marek Vasut wrote:

Quoted 1 line · On Friday 11 March 2011 11:23:40 Vasily Khoruzhick wrote:

Signed-off-by Vasily Khoruzhick <[email protected]>

This looks bogus to me as you cannot power down the thing. Besides, where do you resume to from this so-called "powerdown" ? Since the bootloader will consider it as a legitimate deepsleep resume.

It eats only 0.7mA in deepsleep, but 6.7mA in sleep (PXA2xx has 2 sleep modes), so deepsleep is pretty close to poweroff.

Bootloader behaves
correctly (at least u-boot binary I'm using)

- it starts boot process
after deepsleep. Looks like hardware is somehow configured to disable almost everything in deepsleep mode, RAM content is not preserved anyway, so we can't resume properly.

Quoted 4 lines · On Friday 11 March 2011 22:53:11 Vasily Khoruzhick wrote:

Quoted 3 lines · On Friday 11 March 2011 23:39:03 Marek Vasut wrote:

Quoted 1 line · On Friday 11 March 2011 11:23:40 Vasily Khoruzhick wrote:

Signed-off-by Vasily Khoruzhick <[email protected]>

Quoted 6 lines

Quoted 3 lines

This looks bogus to me as you cannot power down the thing. Besides, where do you resume to from this so-called "powerdown" ? Since the bootloader will consider it as a legitimate deepsleep resume.

It eats only 0.7mA in deepsleep, but 6.7mA in sleep (PXA2xx has 2 sleep modes), so deepsleep is pretty close to poweroff.

So the power to the CPU is actually cut? It isn't, right ?

Mine (I use mainline uboot) doesn't.

PSPR is preserved though, right ? So you end up in a really deep crap I guess ?

Quoted 9 lines · On Saturday 12 March 2011 00:08:58 Marek Vasut wrote:

Quoted 8 lines · On Friday 11 March 2011 22:53:11 Vasily Khoruzhick wrote:

Quoted 6 lines · On Friday 11 March 2011 23:39:03 Marek Vasut wrote:

Quoted 1 line · On Friday 11 March 2011 11:23:40 Vasily Khoruzhick wrote:

Signed-off-by Vasily Khoruzhick <[email protected]>

This looks bogus to me as you cannot power down the thing. Besides, where do you resume to from this so-called "powerdown" ? Since the bootloader will consider it as a legitimate deepsleep resume.

Quoted 4 lines

Quoted 2 lines

It eats only 0.7mA in deepsleep, but 6.7mA in sleep (PXA2xx has 2 sleep modes), so deepsleep is pretty close to poweroff.

So the power to the CPU is actually cut? It isn't, right ?

It isn't. But looks like power to memory is cut. But stock bootloader puts it in deepsleep to save battery.

Quoted 2 lines

Mine (I use mainline uboot) doesn't.

Can you re-check it?

Quoted 3 lines

PSPR is preserved though, right ? So you end up in a really deep crap I guess ?

Does u-boot check if PSPR is null?

Regards
Vasily

Quoted 13 lines · On Friday 11 March 2011 23:12:40 Vasily Khoruzhick wrote:

Quoted 12 lines · On Saturday 12 March 2011 00:08:58 Marek Vasut wrote:

Quoted 10 lines · On Friday 11 March 2011 22:53:11 Vasily Khoruzhick wrote:

Quoted 6 lines · On Friday 11 March 2011 23:39:03 Marek Vasut wrote:

Quoted 1 line · On Friday 11 March 2011 11:23:40 Vasily Khoruzhick wrote:

Signed-off-by Vasily Khoruzhick <[email protected]>

This looks bogus to me as you cannot power down the thing. Besides, where do you resume to from this so-called "powerdown" ? Since the bootloader will consider it as a legitimate deepsleep resume.

It eats only 0.7mA in deepsleep, but 6.7mA in sleep (PXA2xx has 2 sleep modes), so deepsleep is pretty close to poweroff.

Quoted 4 lines

Quoted 1 line

So the power to the CPU is actually cut? It isn't, right ?

It isn't. But looks like power to memory is cut. But stock bootloader puts it in deepsleep to save battery.

Power to memory is cut? How come? You mean rather the refresh is disabled, right ? But anyway, isn't the ram put into self-refresh ?

Quoted 3 lines

Quoted 1 line

Mine (I use mainline uboot) doesn't.

Can you re-check it?

Check what ? Yes I can ...

Quoted 20 lines · On Saturday 12 March 2011 00:16:57 Marek Vasut wrote:

Quoted 18 lines · On Friday 11 March 2011 23:12:40 Vasily Khoruzhick wrote:

Quoted 10 lines · On Saturday 12 March 2011 00:08:58 Marek Vasut wrote:

Quoted 9 lines · On Friday 11 March 2011 22:53:11 Vasily Khoruzhick wrote:

Quoted 7 lines · On Friday 11 March 2011 23:39:03 Marek Vasut wrote:

Quoted 1 line · On Friday 11 March 2011 11:23:40 Vasily Khoruzhick wrote:

Signed-off-by Vasily Khoruzhick <[email protected]>

This looks bogus to me as you cannot power down the thing. Besides, where do you resume to from this so-called "powerdown" ? Since the bootloader will consider it as a legitimate deepsleep resume.

Quoted 4 lines

Quoted 2 lines

It eats only 0.7mA in deepsleep, but 6.7mA in sleep (PXA2xx has 2 sleep modes), so deepsleep is pretty close to poweroff.

So the power to the CPU is actually cut? It isn't, right ?

It isn't. But looks like power to memory is cut. But stock bootloader puts it in deepsleep to save battery.

Quoted 2 lines

Power to memory is cut? How come? You mean rather the refresh is disabled, right ? But anyway, isn't the ram put into self-refresh ?

Well, it looks like memory content is not preserved, or something wrong with bootloader. Anyway, it does not resume after deepsleep for some reason, I can't check better, as I have no JTAG. Maybe you can investigate this problem?

Quoted 6 lines

Quoted 4 lines

Quoted 2 lines

Mine (I use mainline uboot) doesn't.

Can you re-check it?

Check what ? Yes I can ...

No need, I understand how it works, PSPR is null, so after u-boot loads PSPR to pc it performs 'soft reset' (jumps to 0x0, to begin of NOR flash), RCSR bits are already cleared, so it just boots kernel.

Regards
Vasily

Quoted 3 lines

No need, I understand how it works, PSPR is null, so after u-boot loads PSPR to pc it performs 'soft reset' (jumps to 0x0, to begin of NOR flash), RCSR bits are already cleared, so it just boots kernel.

The note in Table 18 -- Exit from sleep or deep-sleep doesn't clear or set this bit -- means PSPR might not be null if you use your deep-sleep-parapowerdown.

Quoted 4 lines

Well, it looks like memory content is not preserved, or something wrong with bootloader. Anyway, it does not resume after deepsleep for some reason, I can't check better, as I have no JTAG. Maybe you can investigate this problem?

But resume after deepsleep is unrelated to this patch.

Quoted 3 lines

No need, I understand how it works, PSPR is null, so after u-boot loads PSPR to pc it performs 'soft reset' (jumps to 0x0, to begin of NOR flash), RCSR bits are already cleared, so it just boots kernel.

The note in Table 18 -- Exit from sleep or deep-sleep doesn't clear or set this bit -- means PSPR might not be null if you use your deep-sleep-parapowerdown.

Quoted 6 lines · On Saturday 12 March 2011 02:05:15 Marek Vasut wrote:

Quoted 4 lines

Well, it looks like memory content is not preserved, or something wrong with bootloader. Anyway, it does not resume after deepsleep for some reason, I can't check better, as I have no JTAG. Maybe you can investigate this problem?

But resume after deepsleep is unrelated to this patch.

I just want to say that without this patch you can't keep device in low- powermode, and it can drain full battery in ~week when it's in sleep mode.

Quoted 8 lines

Quoted 4 lines

No need, I understand how it works, PSPR is null, so after u-boot loads PSPR to pc it performs 'soft reset' (jumps to 0x0, to begin of NOR flash), RCSR bits are already cleared, so it just boots kernel.

The note in Table 18 -- Exit from sleep or deep-sleep doesn't clear or set this bit -- means PSPR might not be null if you use your deep-sleep-parapowerdown.

Ok, I can clear PSPR before going to deepsleep, would it be enough?

Regards
Vasily

You have a problem with suspend then ? That'd need a different solution.

Quoted 1 line

Ok, I can clear PSPR before going to deepsleep, would it be enough?

As Eric pointed out, the wake-up scenario is bootloader-specific ... taking into acount only your own version of bootloader is a no-no

Quoted 1 line · On Saturday 12 March 2011 13:06:13 Marek Vasut wrote:

You have a problem with suspend then ? That'd need a different solution.

I'm still not sure if resume from deepsleep is possible on Zipit Z2, so using deepsleep as poweroff is the only solution we know for now.

Quoted 5 lines

Quoted 2 lines

Ok, I can clear PSPR before going to deepsleep, would it be enough?

As Eric pointed out, the wake-up scenario is bootloader-specific ... taking into acount only your own version of bootloader is a no-no

That will work with mainline u-boot, here's pseudocode:

1. PSPR = 0x0;
2. Put_PXA270_Into_DeepSleep();
.......
Wake-up
.......
3. Load RCSR to temporary var
4. Clear RCSR bits
5. If we resumed from suspend jump to location pointed by PSPR

Steps 3-5 are already implemented in u-boot, so it'll jump to 0x0 (NOR), to the u-boot entry point. RCSR bits are already cleared, so it just continues regular boot process.

Regards
Vasily

What about blob and other bootloaders. U-Boot isn't the only one running on that device, right ?

Besides, this is nonsense, you're doing a hack and you're trying to justify it. You cannot powerdown the device, period. You should rather patch the bootloader to implement this para-powerdown behaviour than bloat kernel with this workaround.

Quoted 2 lines · On Saturday 12 March 2011 15:16:19 Marek Vasut wrote:

What about blob and other bootloaders. U-Boot isn't the only one running on that device, right ?

There's only blob binary for this device (with default firmware). I doubt anyone tried to build blob from sources with Aeronix' patches.

Quoted 5 lines

Besides, this is nonsense, you're doing a hack and you're trying to justify it. You cannot powerdown the device, period. You should rather patch the bootloader to implement this para-powerdown behaviour than bloat kernel with this workaround.

I'm OK with this out of tree patch. I don't do bootloader hacking without ability to unbrick device.

Regards,
Vasily

Besides, this is nonsense, you're doing a hack and you're trying to justify it. You cannot powerdown the device, period. You should rather patch the bootloader to implement this para-powerdown behaviour than bloat kernel with this workaround.

Quoted 4 lines · On Saturday 12 March 2011 15:16:19 Marek Vasut wrote:

Besides, this is nonsense, you're doing a hack and you're trying to justify it. You cannot powerdown the device, period. You should rather patch the bootloader to implement this para-powerdown behaviour than bloat kernel with this workaround.

And, btw, there's same code in mainline kernel for zeus machine.

Quoted 6 lines · On Saturday 12 March 2011 15:16:19 Marek Vasut wrote:

Quoted 4 lines

Besides, this is nonsense, you're doing a hack and you're trying to justify it. You cannot powerdown the device, period. You should rather patch the bootloader to implement this para-powerdown behaviour than bloat kernel with this workaround.

Quoted 1 line

And, btw, there's same code in mainline kernel for zeus machine.

Doesn't mean it's correct. CCing maintainer. Eric, can you also please comment on it ? I really don't like the idea of abusing poweroff and making people misunderstand.

Cheers

2011/3/13 Marek Vasut <[email protected]>:

Quoted 9 lines · On Saturday 12 March 2011 21:34:01 Vasily Khoruzhick wrote:

Quoted 7 lines · On Saturday 12 March 2011 15:16:19 Marek Vasut wrote:

Quoted 4 lines

Besides, this is nonsense, you're doing a hack and you're trying to justify it. You cannot powerdown the device, period. You should rather patch the bootloader to implement this para-powerdown behaviour than bloat kernel with this workaround.

And, btw, there's same code in mainline kernel for zeus machine.

Quoted 3 lines

Doesn't mean it's correct. CCing maintainer. Eric, can you also please comment on it ? I really don't like the idea of abusing poweroff and making people misunderstand.

I'm actually quite OK with the idea of using deep sleep as a way for shutdown. As some of the device has no way for a "correct" shutdown without pulling out the battery. A fake one is at least better than none, provided it works as expected.

Quoted 14 lines · On Tuesday 15 March 2011 17:49:26 Eric Miao wrote:

2011/3/13 Marek Vasut <[email protected]>:

Quoted 12 lines · On Saturday 12 March 2011 21:34:01 Vasily Khoruzhick wrote:

Quoted 7 lines · On Saturday 12 March 2011 15:16:19 Marek Vasut wrote:

Quoted 4 lines

Besides, this is nonsense, you're doing a hack and you're trying to justify it. You cannot powerdown the device, period. You should rather patch the bootloader to implement this para-powerdown behaviour than bloat kernel with this workaround.

And, btw, there's same code in mainline kernel for zeus machine.

Doesn't mean it's correct. CCing maintainer. Eric, can you also please comment on it ? I really don't like the idea of abusing poweroff and making people misunderstand.

Quoted 4 lines

I'm actually quite OK with the idea of using deep sleep as a way for shutdown. As some of the device has no way for a "correct" shutdown without pulling out the battery. A fake one is at least better than none, provided it works as expected.

So should I send updated version of this patch? (Need to clear PSPR before going to deepsleep)

Signed-off-by Vasily Khoruzhick <[email protected]>

---
v2:
?- clear PSPR before going deep sleep

?arch/arm/mach-pxa/z2.c | ? 17 +++++++++++++++++ ?1 files changed, 17 insertions(+), 0 deletions(-)

arch/arm/mach-pxa/z2.c +0 -0

index 3d3f019..a9ab8c1 100644
@@ -40,6 +40,7 @@

?#include <mach/pxafb.h>
?#include <mach/mmc.h>
?#include <plat/pxa27x_keypad.h>
+#include <mach/pm.h>

?#include "generic.h"
?#include "devices.h"

arch/arm/mach-pxa/z2.c +0 -0

@@ -677,6 +678,20 @@ static void __init z2_pmic_init(void)
 ?static inline void z2_pmic_init(void) {}

?#endif

arch/arm/mach-pxa/z2.c +14 -0

+#ifdef CONFIG_PM
+static void z2_power_off(void)
+{
+ ? ? ? /* We're using deep sleep as poweroff, so clear PSPR to ensure that
+ ? ? ? ?* bootloader will jump to its entry point in resume handler
+ ? ? ? ?*/
+ ? ? ? PSPR = 0x0;
+ ? ? ? local_irq_disable();
+ ? ? ? pxa27x_cpu_suspend(PWRMODE_DEEPSLEEP, PLAT_PHYS_OFFSET - PAGE_OFFSET);
+}
+#else
+#define z2_power_off ? NULL
+#endif
+

?/****************************************************************************** ?* Machine init ?******************************************************************************/

arch/arm/mach-pxa/z2.c +2 -1

@@ -698,6 +713,8 @@ static void __init z2_init(void)
 ? ? ? ?z2_leds_init();
 ? ? ? ?z2_keys_init();
 ? ? ? ?z2_pmic_init();
+
+ ? ? ? pm_power_off = z2_power_off;
 ?}
 
 ?MACHINE_START(ZIPIT2, "Zipit Z2")
--

1.7.4.1

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Quoted 5 lines · On Saturday 12 March 2011 12:30:22 Vasily Khoruzhick wrote:

Quoted 1 line · On Saturday 12 March 2011 13:06:13 Marek Vasut wrote:

You have a problem with suspend then ? That'd need a different solution.

I'm still not sure if resume from deepsleep is possible on Zipit Z2, so using deepsleep as poweroff is the only solution we know for now.

Don't use anything for poweroff, you cannot poweroff the device.

GPIO15 seems to be not related to WiFi, so don't touch it.

Signed-off-by Vasily Khoruzhick <[email protected]>

---
 arch/arm/mach-pxa/include/mach/z2.h |    3 +--
 arch/arm/mach-pxa/z2.c              |   31 ++++++++-----------------------
 2 files changed, 9 insertions(+), 25 deletions(-)

(quoted diff) +0 -0

b/arch/arm/mach-pxa/include/mach/z2.h index 8835c16..7b0f71e 100644

arch/arm/mach-pxa/include/mach/z2.h +1 -2

@@ -25,8 +25,7 @@
 #define	GPIO98_ZIPITZ2_LID_BUTTON	98
 
 /* Libertas GSPI8686 WiFi */
-#define	GPIO14_ZIPITZ2_WIFI_RESET	14
-#define	GPIO15_ZIPITZ2_WIFI_POWER	15
+#define	GPIO14_ZIPITZ2_WIFI_POWER	14
 #define	GPIO24_ZIPITZ2_WIFI_CS		24
 #define	GPIO36_ZIPITZ2_WIFI_IRQ		36
 

arch/arm/mach-pxa/z2.c +8 -23

index f1bb98a..d1e40ba 100644
@@ -141,8 +141,7 @@ static unsigned long z2_pin_config[] = {
 	GPIO1_GPIO,		/* Power button */
 	GPIO37_GPIO,		/* Headphone detect */
 	GPIO98_GPIO,		/* Lid switch */
-	GPIO14_GPIO,		/* WiFi Reset */
-	GPIO15_GPIO,		/* WiFi Power */
+	GPIO14_GPIO,		/* WiFi Power */
 	GPIO24_GPIO,		/* WiFi CS */
 	GPIO36_GPIO,		/* WiFi IRQ */
 	GPIO88_GPIO,		/* LCD CS */

@@ -504,26 +503,16 @@ static int z2_lbs_spi_setup(struct spi_device *spi)
 {
 	int ret = 0;
 
-	ret = gpio_request(GPIO15_ZIPITZ2_WIFI_POWER, "WiFi Power");
+	ret = gpio_request(GPIO14_ZIPITZ2_WIFI_POWER, "WiFi Power");
 	if (ret)
 		goto err;
 
-	ret = gpio_direction_output(GPIO15_ZIPITZ2_WIFI_POWER, 1);
+	ret = gpio_direction_output(GPIO14_ZIPITZ2_WIFI_POWER, 1);
 	if (ret)
 		goto err2;
 
-	ret = gpio_request(GPIO14_ZIPITZ2_WIFI_RESET, "WiFi Reset");
-	if (ret)
-		goto err2;
-
-	ret = gpio_direction_output(GPIO14_ZIPITZ2_WIFI_RESET, 0);
-	if (ret)
-		goto err3;
-
-	/* Reset the card */
+	/* Wait until card is powered on */
 	mdelay(180);
-	gpio_set_value(GPIO14_ZIPITZ2_WIFI_RESET, 1);
-	mdelay(20);
 
 	spi->bits_per_word = 16;
 	spi->mode = SPI_MODE_2,

@@ -532,22 +521,18 @@ static int z2_lbs_spi_setup(struct spi_device *spi)
 
 	return 0;
 
-err3:
-	gpio_free(GPIO14_ZIPITZ2_WIFI_RESET);
 err2:
-	gpio_free(GPIO15_ZIPITZ2_WIFI_POWER);
+	gpio_free(GPIO14_ZIPITZ2_WIFI_POWER);
 err:
 	return ret;
 };
 
 static int z2_lbs_spi_teardown(struct spi_device *spi)
 {
-	gpio_set_value(GPIO14_ZIPITZ2_WIFI_RESET, 0);
-	gpio_set_value(GPIO15_ZIPITZ2_WIFI_POWER, 0);
-	gpio_free(GPIO14_ZIPITZ2_WIFI_RESET);
-	gpio_free(GPIO15_ZIPITZ2_WIFI_POWER);
-	return 0;
+	gpio_set_value(GPIO14_ZIPITZ2_WIFI_POWER, 0);
+	gpio_free(GPIO14_ZIPITZ2_WIFI_POWER);
 
+	return 0;
 };
 
 static struct pxa2xx_spi_chip z2_lbs_chip_info = {

Quoted 1 line · On Friday 11 March 2011 11:23:41 Vasily Khoruzhick wrote:

GPIO15 seems to be not related to WiFi, so don't touch it.

What's GPIO14 then? Also check Z2 kernel sources aeronix released, iirc that's where I found gpio14.

Cheers

Quoted 7 lines · On Friday 11 March 2011 23:37:43 Marek Vasut wrote:

Quoted 1 line · On Friday 11 March 2011 11:23:41 Vasily Khoruzhick wrote:

GPIO15 seems to be not related to WiFi, so don't touch it.

What's GPIO14 then? Also check Z2 kernel sources aeronix released, iirc that's where I found gpio14.

Cheers

Don't know what it is, but according to my investigations via qemu (I added traces on gpio access), stock kernel does not touch this gpio at all.

Regards
Vasily

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

It eats too much power, and anyway it's not usefull during boot process. Userspace can enable it later.

Signed-off-by Vasily Khoruzhick <[email protected]>

---
 arch/arm/mach-pxa/z2.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

arch/arm/mach-pxa/z2.c +0 -0

index d1e40ba..2fac54d 100644
@@ -210,7 +210,7 @@ static struct platform_pwm_backlight_data

z2_backlight_data[] = { /* Keypad Backlight */

arch/arm/mach-pxa/z2.c +1 -1

 		.pwm_id		= 1,
 		.max_brightness	= 1023,
-		.dft_brightness	= 512,
+		.dft_brightness	= 0,
 		.pwm_period_ns	= 1260320,
 	},
 	[1] = {

So user can see if there's any mmc activity and if device's charging.

Signed-off-by Vasily Khoruzhick <[email protected]>

---
 arch/arm/mach-pxa/z2.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

arch/arm/mach-pxa/z2.c +2 -2

index 2fac54d..7314a79 100644
@@ -315,12 +315,12 @@ struct gpio_led z2_gpio_leds[] = {
 	.active_low		= 1,
 }, {
 	.name			= "z2:green:charged",
-	.default_trigger	= "none",
+	.default_trigger	= "mmc0",
 	.gpio			= GPIO85_ZIPITZ2_LED_CHARGED,
 	.active_low		= 1,
 }, {
 	.name			= "z2:amber:charging",
-	.default_trigger	= "none",
+	.default_trigger	= "Z2-charging-or-full",
 	.gpio			= GPIO83_ZIPITZ2_LED_CHARGING,
 	.active_low		= 1,
 },

It's very easy to press some keypad key when Z2 is closed, so to prevent unexpected wakeups, use only 'Power' key to wake Z2 from sleep.

Signed-off-by Vasily Khoruzhick <[email protected]>

---
 arch/arm/mach-pxa/z2.c |   18 +++++++++---------
 1 files changed, 9 insertions(+), 9 deletions(-)

arch/arm/mach-pxa/z2.c +0 -4

index aaf8837..7bad4f7 100644
@@ -91,13 +91,13 @@ static unsigned long z2_pin_config[] = {
 	GPIO47_STUART_TXD,
 
 	/* Keypad */
-	GPIO100_KP_MKIN_0	| WAKEUP_ON_LEVEL_HIGH,
-	GPIO101_KP_MKIN_1	| WAKEUP_ON_LEVEL_HIGH,
-	GPIO102_KP_MKIN_2	| WAKEUP_ON_LEVEL_HIGH,
-	GPIO34_KP_MKIN_3	| WAKEUP_ON_LEVEL_HIGH,

arch/arm/mach-pxa/z2.c +0 -0

 	GPIO103_KP_MKOUT_0,
 	GPIO104_KP_MKOUT_1,
 	GPIO105_KP_MKOUT_2,

@@ -427,8 +427,8 @@ static inline void z2_mkp_init(void) {}
 
 **************************************************************************
 ****/ #if defined(CONFIG_KEYBOARD_GPIO) ||

defined(CONFIG_KEYBOARD_GPIO_MODULE) static struct gpio_keys_button z2_pxa_buttons[] = {

arch/arm/mach-pxa/z2.c +2 -2

-	{KEY_POWER, GPIO1_ZIPITZ2_POWER_BUTTON, 0, "Power Button" },
-	{KEY_CLOSE, GPIO98_ZIPITZ2_LID_BUTTON, 0, "Lid Button" },
+	{KEY_POWER, GPIO1_ZIPITZ2_POWER_BUTTON, 0, "Power Button", 1 },
+	{KEY_CLOSE, GPIO98_ZIPITZ2_LID_BUTTON, 0, "Lid Button", 0 },
 };
 
 static struct gpio_keys_platform_data z2_pxa_keys_data = {

It's very easy to press some keypad key when Z2 is closed, so to prevent unexpected wakeups, use only 'Power' key to wake Z2 from sleep.

Signed-off-by Vasily Khoruzhick <[email protected]>

arch/arm/mach-pxa/z2.c +0 -1

-	GPIO34_KP_MKIN_3	| WAKEUP_ON_LEVEL_HIGH,