LG Optimus Black (P970) codename sniper support series (and driver-model issue)

This adds support for powering off (the omap3 SoC) from the twl4030. This is especially useful when the kernel does not actually power off the device using this method but reboots and leaves it up to the bootloader to actually turn the power off.

Quoted 5 lines

This adds support for powering off (the omap3 SoC) from the twl4030. This is especially useful when the kernel does not actually power off the device using this method but reboots and leaves it up to the bootloader to actually turn the power off.

Reviewed-by Tom Rini <[email protected]>

This adds support for powering off (the omap3 SoC) from the twl4030. This is especially useful when the kernel does not actually power off the device using this method but reboots and leaves it up to the bootloader to actually turn the power off.
---

This adds support for powering off (the omap3 SoC) from the twl4030. This is especially useful when the kernel does not actually power off the device using this method but reboots and leaves it up to the bootloader to actually turn the power off.

---
  drivers/power/twl4030.c | 60 +++++++++++++++++++++++++++++++++++++++++++++++++
  include/twl4030.h       | 32 +++++++++++++++++++-------
  2 files changed, 84 insertions(+), 8 deletions(-)

This adds support for powering off (the omap3 SoC) from the twl4030. This is especially useful when the kernel does not actually power off the device using this method but reboots and leaves it up to the bootloader to actually turn the power off.

Reviewed-by Tom Rini <[email protected]>

Acked-by Przemyslaw Marczak <[email protected]>

Signed-off-by Paul Kocialkowski <[email protected]>

This adds support for detecting a few inputs exported by the TWL4030. Currently-supported inputs are the power button, USB and charger presence.

Quoted 3 lines

This adds support for detecting a few inputs exported by the TWL4030. Currently-supported inputs are the power button, USB and charger presence.

Reviewed-by Tom Rini <[email protected]>

This adds support for detecting a few inputs exported by the TWL4030. Currently-supported inputs are the power button, USB and charger presence.

Reviewed-by Tom Rini <[email protected]>

Signed-off-by Paul Kocialkowski <[email protected]>

This allows scanning the twl4030 keypad, storing the result in a 64-byte long matrix with the twl4030_keypad_scan function.

Detecting a key at a given column and row is made easier with the twl4030_keypad_key function.

Signed-off-by Paul Kocialkowski <[email protected]>

This allows scanning the twl4030 keypad, storing the result in a 64-byte long matrix with the twl4030_keypad_scan function.

Detecting a key at a given column and row is made easier with the twl4030_keypad_key function.

Signed-off-by Paul Kocialkowski <[email protected]>

Reviewed-by Tom Rini <[email protected]>

Reboot mode is written in scratchpad memory before reboot in the form of a single char, that is the first letter of the reboot mode string as passed to the reboot function.

This mechanism is supported on OMAP3 both my the upstream kernel and by various TI kernels.

It is up to each board to make use of this mechanism or not.

Signed-off-by Paul Kocialkowski <[email protected]>

Reboot mode is written in scratchpad memory before reboot in the form of a single char, that is the first letter of the reboot mode string as passed to the reboot function.

This mechanism is supported on OMAP3 both my the upstream kernel and by various TI kernels.

It is up to each board to make use of this mechanism or not.

Signed-off-by Paul Kocialkowski <[email protected]>

Reviewed-by Tom Rini <[email protected]>

The LG Optimus Black (P970) codename sniper is a smartphone that was designed and manufactured by LG Electronics (LGE) and released back in 2011.

It is using an OMAP3630 SoC GP version, which allows running U-Boot and the U-Boot SPL from the ground up. This port is aimed at running an Android version such as Replicant, the fully free Android distribution. However, support for upstream Linux with device-tree and common GNU/Linux distros boot commands could be added in the future.

For more information about the journey to freeing this device, please read the series of blog posts at:
http://code.paulk.fr/article20/a-hacker-s-journey-freeing-a-phone-from-the-ground-up-first-part

Signed-off-by Paul Kocialkowski <[email protected]>

The LG Optimus Black (P970) codename sniper is a smartphone that was designed and manufactured by LG Electronics (LGE) and released back in 2011.

It is using an OMAP3630 SoC GP version, which allows running U-Boot and the U-Boot SPL from the ground up. This port is aimed at running an Android version such as Replicant, the fully free Android distribution. However, support for upstream Linux with device-tree and common GNU/Linux distros boot commands could be added in the future.

For more information about the journey to freeing this device, please read the series of blog posts at:
http://code.paulk.fr/article20/a-hacker-s-journey-freeing-a-phone-from-the-ground-up-first-part

Signed-off-by Paul Kocialkowski <[email protected]>

Reviewed-by Tom Rini <[email protected]>

This adds support for the omap3 reboot mode mechanism and exports the reboot mode via an environment variable, that is used in the boot command to make it possible to boot from the recovery partition.

Signed-off-by Paul Kocialkowski <[email protected]>

This adds support for the omap3 reboot mode mechanism and exports the reboot mode via an environment variable, that is used in the boot command to make it possible to boot from the recovery partition.

Signed-off-by Paul Kocialkowski <[email protected]>

Reviewed-by Tom Rini <[email protected]>

The OMAP3 has some die-specific ID bits that we can use to give the device a (more or less) unique serial number. This is particularly useful for e.g. USB.

Signed-off-by Paul Kocialkowski <[email protected]>

---
 board/lge/sniper/sniper.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

board/lge/sniper/sniper.c +5 -0

index 44d422d..f26855d 100644
@@ -70,7 +70,9 @@ int board_init(void)
 
 int misc_init_r(void)
 {
+	char serial_string[17] = { 0 };
 	char reboot_mode[2] = { 0 };
+	u32 dieid[4] = { 0 };
 
 	/* Reboot mode */
 

@@ -82,6 +84,17 @@ int misc_init_r(void)
 		omap_reboot_mode_clear();
 	}
 
+	/* Serial number */
+
+	get_dieid((u32 *)&dieid);

Quoted 27 lines

The OMAP3 has some die-specific ID bits that we can use to give the device a (more or less) unique serial number. This is particularly useful for e.g. USB.

Signed-off-by Paul Kocialkowski <[email protected]>

---
 board/lge/sniper/sniper.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

board/lge/sniper/sniper.c +2 -0

index 44d422d..f26855d 100644
@@ -70,7 +70,9 @@ int board_init(void)
 
 int misc_init_r(void)
 {
+	char serial_string[17] = { 0 };
 	char reboot_mode[2] = { 0 };
+	u32 dieid[4] = { 0 };
 
 	/* Reboot mode */
 

@@ -82,6 +84,17 @@ int misc_init_r(void)
 		omap_reboot_mode_clear();
 	}
 

board/lge/sniper/sniper.c int misc_init_r(void) · line 99

Quoted 13 lines

board/lge/sniper/sniper.c +11 -0

+	/* Serial number */
+
+	get_dieid((u32 *)&dieid);
+
+	if (!getenv("serial#")) {
+		snprintf(serial_string, sizeof(serial_string),
+			"%08x%08x", dieid[0], dieid[3]);
+
+		setenv("serial#", serial_string);
+	}
+
 	return 0;
 }

Shouldn't this be in more generic code so everyone gets this set now? Thanks!

Le lundi 03 ao?t 2015 ? 22:08 -0400, Tom Rini a ?crit :

Quoted 28 lines · Paul Kocialkowski

Quoted 27 lines

The OMAP3 has some die-specific ID bits that we can use to give the device a (more or less) unique serial number. This is particularly useful for e.g. USB.

Signed-off-by Paul Kocialkowski <[email protected]>

---
 board/lge/sniper/sniper.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

board/lge/sniper/sniper.c +2 -0

index 44d422d..f26855d 100644
@@ -70,7 +70,9 @@ int board_init(void)
 
 int misc_init_r(void)
 {
+	char serial_string[17] = { 0 };
 	char reboot_mode[2] = { 0 };
+	u32 dieid[4] = { 0 };
 
 	/* Reboot mode */
 

@@ -82,6 +84,17 @@ int misc_init_r(void)
 		omap_reboot_mode_clear();
 	}
 

Quoted 16 lines

board/lge/sniper/sniper.c int misc_init_r(void) · line 99

Quoted 13 lines

board/lge/sniper/sniper.c +11 -0

+	/* Serial number */
+
+	get_dieid((u32 *)&dieid);
+
+	if (!getenv("serial#")) {
+		snprintf(serial_string, sizeof(serial_string),
+			"%08x%08x", dieid[0], dieid[3]);
+
+		setenv("serial#", serial_string);
+	}
+
 	return 0;
 }

Shouldn't this be in more generic code so everyone gets this set now? Thanks!

Well, we had a similar discussion for sunxi, and the outcome was that serial number could be obtained from other places on other devices (e.g. EEPROM) or be calculated from the dieid bits in a different way, so I prefer to keep this board-specific instead of omap3-generic for now.

This merely matches what is done on Android OMAP devices, but one could do it another way, too.

What do you think?

Quoted 54 lines

Le lundi 03 ao?t 2015 ? 22:08 -0400, Tom Rini a ?crit :

Quoted 28 lines · Paul Kocialkowski

Quoted 27 lines

The OMAP3 has some die-specific ID bits that we can use to give the device a (more or less) unique serial number. This is particularly useful for e.g. USB.

Signed-off-by Paul Kocialkowski <[email protected]>

---
 board/lge/sniper/sniper.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

board/lge/sniper/sniper.c +2 -0

index 44d422d..f26855d 100644
@@ -70,7 +70,9 @@ int board_init(void)
 
 int misc_init_r(void)
 {
+	char serial_string[17] = { 0 };
 	char reboot_mode[2] = { 0 };
+	u32 dieid[4] = { 0 };
 
 	/* Reboot mode */
 

@@ -82,6 +84,17 @@ int misc_init_r(void)
 		omap_reboot_mode_clear();
 	}
 

Quoted 16 lines

board/lge/sniper/sniper.c int misc_init_r(void) · line 99

Quoted 13 lines

board/lge/sniper/sniper.c +11 -0

+	/* Serial number */
+
+	get_dieid((u32 *)&dieid);
+
+	if (!getenv("serial#")) {
+		snprintf(serial_string, sizeof(serial_string),
+			"%08x%08x", dieid[0], dieid[3]);
+
+		setenv("serial#", serial_string);
+	}
+
 	return 0;
 }

Shouldn't this be in more generic code so everyone gets this set now? Thanks!

Well, we had a similar discussion for sunxi, and the outcome was that serial number could be obtained from other places on other devices (e.g. EEPROM) or be calculated from the dieid bits in a different way, so I prefer to keep this board-specific instead of omap3-generic for now.

This merely matches what is done on Android OMAP devices, but one could do it another way, too.

Quoted 1 line

What do you think?

I think, ug, arch/arm/cpu/armv7/omap-common/utils.c::usb_set_serial_num_from_die_id() should be called set_serial_num_from_die_id() and we can use that for this board too even if it's not ideal.

Le mardi 04 ao?t 2015 ? 14:16 -0400, Tom Rini a ?crit :

Quoted 55 lines · Paul Kocialkowski

Quoted 54 lines

Le lundi 03 ao?t 2015 ? 22:08 -0400, Tom Rini a ?crit :

Quoted 28 lines · Paul Kocialkowski

Quoted 27 lines

The OMAP3 has some die-specific ID bits that we can use to give the device a (more or less) unique serial number. This is particularly useful for e.g. USB.

Signed-off-by Paul Kocialkowski <[email protected]>

---
 board/lge/sniper/sniper.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

board/lge/sniper/sniper.c +2 -0

index 44d422d..f26855d 100644
@@ -70,7 +70,9 @@ int board_init(void)
 
 int misc_init_r(void)
 {
+	char serial_string[17] = { 0 };
 	char reboot_mode[2] = { 0 };
+	u32 dieid[4] = { 0 };
 
 	/* Reboot mode */
 

@@ -82,6 +84,17 @@ int misc_init_r(void)
 		omap_reboot_mode_clear();
 	}
 

Quoted 16 lines

board/lge/sniper/sniper.c int misc_init_r(void) · line 99

Quoted 13 lines

board/lge/sniper/sniper.c +11 -0

+	/* Serial number */
+
+	get_dieid((u32 *)&dieid);
+
+	if (!getenv("serial#")) {
+		snprintf(serial_string, sizeof(serial_string),
+			"%08x%08x", dieid[0], dieid[3]);
+
+		setenv("serial#", serial_string);
+	}
+
 	return 0;
 }

Shouldn't this be in more generic code so everyone gets this set now? Thanks!

Well, we had a similar discussion for sunxi, and the outcome was that serial number could be obtained from other places on other devices (e.g. EEPROM) or be calculated from the dieid bits in a different way, so I prefer to keep this board-specific instead of omap3-generic for now.

This merely matches what is done on Android OMAP devices, but one could do it another way, too.

Quoted 6 lines

Quoted 1 line

What do you think?

I think, ug, arch/arm/cpu/armv7/omap-common/utils.c::usb_set_serial_num_from_die_id() should be called set_serial_num_from_die_id() and we can use that for this board too even if it's not ideal.

Oh okay then, I don't have any problem with making this code common, especially if it's not called by every omap3 board then.

I agree with your proposal. Should I submit a v2 with a patch in that direction?

Quoted 63 lines

Le mardi 04 ao?t 2015 ? 14:16 -0400, Tom Rini a ?crit :

Quoted 61 lines · Paul Kocialkowski

Quoted 51 lines

Le lundi 03 ao?t 2015 ? 22:08 -0400, Tom Rini a ?crit :

Quoted 28 lines · Paul Kocialkowski

Quoted 27 lines

The OMAP3 has some die-specific ID bits that we can use to give the device a (more or less) unique serial number. This is particularly useful for e.g. USB.

Signed-off-by Paul Kocialkowski <[email protected]>

---
 board/lge/sniper/sniper.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

board/lge/sniper/sniper.c +2 -0

index 44d422d..f26855d 100644
@@ -70,7 +70,9 @@ int board_init(void)
 
 int misc_init_r(void)
 {
+	char serial_string[17] = { 0 };
 	char reboot_mode[2] = { 0 };
+	u32 dieid[4] = { 0 };
 
 	/* Reboot mode */
 

@@ -82,6 +84,17 @@ int misc_init_r(void)
 		omap_reboot_mode_clear();
 	}
 

Quoted 16 lines

board/lge/sniper/sniper.c int misc_init_r(void) · line 99

Quoted 13 lines

board/lge/sniper/sniper.c +11 -0

+	/* Serial number */
+
+	get_dieid((u32 *)&dieid);
+
+	if (!getenv("serial#")) {
+		snprintf(serial_string, sizeof(serial_string),
+			"%08x%08x", dieid[0], dieid[3]);
+
+		setenv("serial#", serial_string);
+	}
+
 	return 0;
 }

Shouldn't this be in more generic code so everyone gets this set now? Thanks!

Well, we had a similar discussion for sunxi, and the outcome was that serial number could be obtained from other places on other devices (e.g. EEPROM) or be calculated from the dieid bits in a different way, so I prefer to keep this board-specific instead of omap3-generic for now.

Quoted 4 lines

This merely matches what is done on Android OMAP devices, but one could do it another way, too.

What do you think?

I think, ug, arch/arm/cpu/armv7/omap-common/utils.c::usb_set_serial_num_from_die_id() should be called set_serial_num_from_die_id() and we can use that for this board too even if it's not ideal.

Quoted 5 lines

Oh okay then, I don't have any problem with making this code common, especially if it's not called by every omap3 board then.

I agree with your proposal. Should I submit a v2 with a patch in that direction?

Sounds good, thanks!

Le mardi 04 ao?t 2015 ? 14:27 -0400, Tom Rini a ?crit :

Quoted 64 lines · Paul Kocialkowski

Quoted 63 lines

Le mardi 04 ao?t 2015 ? 14:16 -0400, Tom Rini a ?crit :

Quoted 61 lines · Paul Kocialkowski

Quoted 51 lines

Le lundi 03 ao?t 2015 ? 22:08 -0400, Tom Rini a ?crit :

Quoted 28 lines · Paul Kocialkowski

Quoted 27 lines

The OMAP3 has some die-specific ID bits that we can use to give the device a (more or less) unique serial number. This is particularly useful for e.g. USB.

Signed-off-by Paul Kocialkowski <[email protected]>

---
 board/lge/sniper/sniper.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

board/lge/sniper/sniper.c +2 -0

index 44d422d..f26855d 100644
@@ -70,7 +70,9 @@ int board_init(void)
 
 int misc_init_r(void)
 {
+	char serial_string[17] = { 0 };
 	char reboot_mode[2] = { 0 };
+	u32 dieid[4] = { 0 };
 
 	/* Reboot mode */
 

@@ -82,6 +84,17 @@ int misc_init_r(void)
 		omap_reboot_mode_clear();
 	}
 

Quoted 16 lines

board/lge/sniper/sniper.c int misc_init_r(void) · line 99

Quoted 13 lines

board/lge/sniper/sniper.c +11 -0

+	/* Serial number */
+
+	get_dieid((u32 *)&dieid);
+
+	if (!getenv("serial#")) {
+		snprintf(serial_string, sizeof(serial_string),
+			"%08x%08x", dieid[0], dieid[3]);
+
+		setenv("serial#", serial_string);
+	}
+
 	return 0;
 }

Shouldn't this be in more generic code so everyone gets this set now? Thanks!

Well, we had a similar discussion for sunxi, and the outcome was that serial number could be obtained from other places on other devices (e.g. EEPROM) or be calculated from the dieid bits in a different way, so I prefer to keep this board-specific instead of omap3-generic for now.

Quoted 4 lines

This merely matches what is done on Android OMAP devices, but one could do it another way, too.

What do you think?

I think, ug, arch/arm/cpu/armv7/omap-common/utils.c::usb_set_serial_num_from_die_id() should be called set_serial_num_from_die_id() and we can use that for this board too even if it's not ideal.

Quoted 7 lines

Quoted 5 lines

Oh okay then, I don't have any problem with making this code common, especially if it's not called by every omap3 board then.

I agree with your proposal. Should I submit a v2 with a patch in that direction?

Sounds good, thanks!

Taking a closer look at things, it appears that various (non-omap3) boards are grabbing the Die ID bits on their own and then calling those functions (usb_fake_mac_from_die_id, usb_set_serial_num_from_die_id).

IMHO, we should have a common naming scheme for the function to get the dieid (omap_dieid), define that for each omap platform and have it called in omap-common code (with one function for the serial number and one for the fake mac), just like what I did with omap_sys_boot_device.

Then, each board would simply call those functions directly, without having to care about how to obtain the die id bits.

This seems like a series that would deserve to live on its own, so I suggest that you merge Optimus Black support as-is for now and I'll submit another series to implement that behaviour on top.

What do you think?

Quoted 109 lines

Le mardi 04 ao?t 2015 ? 14:27 -0400, Tom Rini a ?crit :

Quoted 84 lines

Quoted 82 lines · Paul Kocialkowski

Le mardi 04 ao?t 2015 ? 14:16 -0400, Tom Rini a ?crit :

Quoted 68 lines

Quoted 66 lines · Paul Kocialkowski

Le lundi 03 ao?t 2015 ? 22:08 -0400, Tom Rini a ?crit :

Quoted 43 lines

Quoted 40 lines · Paul Kocialkowski

The OMAP3 has some die-specific ID bits that we can use to give the device a
(more or less) unique serial number. This is particularly useful for e.g. USB.

Signed-off-by Paul Kocialkowski <[email protected]>

---
 board/lge/sniper/sniper.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

board/lge/sniper/sniper.c +11 -0

index 44d422d..f26855d 100644
@@ -70,7 +70,9 @@ int board_init(void)
 
 int misc_init_r(void)
 {
+	char serial_string[17] = { 0 };
 	char reboot_mode[2] = { 0 };
+	u32 dieid[4] = { 0 };
 
 	/* Reboot mode */
 

@@ -82,6 +84,17 @@ int misc_init_r(void)
 		omap_reboot_mode_clear();
 	}
 
+	/* Serial number */
+
+	get_dieid((u32 *)&dieid);
+
+	if (!getenv("serial#")) {
+		snprintf(serial_string, 
 sizeof(serial_string),
+			"%08x%08x", dieid[0], 
 dieid[3]);
+
+		setenv("serial#", serial_string);

Quoted 8 lines

Quoted 4 lines

board/lge/sniper/sniper.c +2 -0

+	}
+
 	return 0;

}

Shouldn't this be in more generic code so everyone gets this set now?
Thanks!

Well, we had a similar discussion for sunxi, and the outcome was that
serial number could be obtained from other places on other devices (e.g.
EEPROM) or be calculated from the dieid bits in a different way, so I
prefer to keep this board-specific instead of omap3-generic for now.

This merely matches what is done on Android OMAP devices, but one could
do it another way, too.

Quoted 8 lines

Quoted 1 line

What do you think?

I think, ug,
arch/arm/cpu/armv7/omap -common/utils.c::usb_set_serial_num_from_die_id() should be called set_serial_num_from_die_id() and we can use that for
this board too even if it's not ideal.

Oh okay then, I don't have any problem with making this code common,
especially if it's not called by every omap3 board then.

Quoted 5 lines

Quoted 3 lines

I agree with your proposal. Should I submit a v2 with a patch in that
direction?

Sounds good, thanks!

Taking a closer look at things, it appears that various (non-omap3) boards are grabbing the Die ID bits on their own and then calling those
functions (usb_fake_mac_from_die_id, usb_set_serial_num_from_die_id).

IMHO, we should have a common naming scheme for the function to get the
dieid (omap_dieid), define that for each omap platform and have it called in omap-common code (with one function for the serial number and
one for the fake mac), just like what I did with omap_sys_boot_device.

Then, each board would simply call those functions directly, without
having to care about how to obtain the die id bits.

Quoted 6 lines

This seems like a series that would deserve to live on its own, so I
suggest that you merge Optimus Black support as-is for now and I'll submit another series to implement that behaviour on top.

What do you think?

Yes, OK, follow-up series to clean-up that for everyone.

The OMAP3 has some die-specific ID bits that we can use to give the device a (more or less) unique serial number. This is particularly useful for e.g. USB.

Signed-off-by Paul Kocialkowski <[email protected]>

Now that the serial number is correctly defined, we can pass it to the kernel using the (legacy) ATAG method. It will be automatically passed via device-tree when enabled.

Signed-off-by Paul Kocialkowski <[email protected]>

Now that the serial number is correctly defined, we can pass it to the kernel using the (legacy) ATAG method. It will be automatically passed via device-tree when enabled.

Signed-off-by Paul Kocialkowski <[email protected]>

Reviewed-by Tom Rini <[email protected]>

This adds support for the fastboot USB gadget, including flashing to the internal MMC and reboot to bootloader or not.

Signed-off-by Paul Kocialkowski <[email protected]>

This adds support for the fastboot USB gadget, including flashing to the internal MMC and reboot to bootloader or not.

Signed-off-by Paul Kocialkowski <[email protected]>

Reviewed-by Tom Rini <[email protected]>

This adds support for resetting the device on a long press on the power button.

Signed-off-by Paul Kocialkowski <[email protected]>

This adds support for resetting the device on a long press on the power button.

Signed-off-by Paul Kocialkowski <[email protected]>

Reviewed-by Tom Rini <[email protected]>

In most cases, userspace will attempt to power off the device with HALT instead of POWER_OFF, which triggers a reset instead of a proper power off from the TWL4030. Hence, it is up to the bootloader to actually turn the device off when there is no reason to turn it on.

A reboot identified with the OMAP reboot mode bits set is acceptable, as well as a power on reason from either the power button, USB or charger plug.

Other cases should trigger a power off. Note that for the U-Boot reset command to take effect, we have to fill-in the OMAP reboot bits.

Signed-off-by Paul Kocialkowski <[email protected]>

In most cases, userspace will attempt to power off the device with HALT instead of POWER_OFF, which triggers a reset instead of a proper power off from the TWL4030. Hence, it is up to the bootloader to actually turn the device off when there is no reason to turn it on.

A reboot identified with the OMAP reboot mode bits set is acceptable, as well as a power on reason from either the power button, USB or charger plug.

Other cases should trigger a power off. Note that for the U-Boot reset command to take effect, we have to fill-in the OMAP reboot bits.

Signed-off-by Paul Kocialkowski <[email protected]>

Reviewed-by Tom Rini <[email protected]>

Using the twl4030 keypad allows booting directly into some special boot modes, such as recovery or fastboot. the VOL+ key will trigger a boot to recovery while the VOL- key will trigger a boot to fastboot.

The G (gesture) key remains unused at this point.

Signed-off-by Paul Kocialkowski <[email protected]>

Using the twl4030 keypad allows booting directly into some special boot modes, such as recovery or fastboot. the VOL+ key will trigger a boot to recovery while the VOL- key will trigger a boot to fastboot.

The G (gesture) key remains unused at this point.

Signed-off-by Paul Kocialkowski <[email protected]>

Reviewed-by Tom Rini <[email protected]>

This patch series adds support for the LG Optimus Black (P970) codename sniper, see the commit that introduces the board and config files for a short description of the device.

This should be applied on top of patches that I have submitted to the list but were not merged yet, especially:
* omap-common: Common boot code OMAP3 support and cleanup
* omap3: CONFIG_REVISION_TAG ifdef check for get_board_rev

At this point, support as submitted as this point is minimalistic. It is not ready for daily use, but introduces the basic elements that are needed to have a sane base upon which the rest of the device support will be introduced.

In particular, the device is currently headless, mainly because the display backlight is not enabled. Other important features such as the MUIC are not enabled, so USB will only work in U-Boot when the device boots with an USB cable already attached. In addition, the external MMC is not supported in U-Boot either, as it requires support for a separate PMIC.

A work in progress commit introduces support for (some of) those bits in a dirty and non-mergeable way is available at:
http://git.code.paulk.fr/gitweb/?p=u-boot.git;a=shortlog;h=refs/heads/sniper-next

Having those bits written correctly would require writing some drivers using the power framework. In the long run, those would have to use the driver model API, which would involve converting the I2C driver to DM as well. This is too much overhead for now, but it will be done eventually.

The main problem I see with doing that work now is that I2C DM seems to heavily rely on device-tree. Other parts of the OMAP platform support were converted to DM but use platform data defined in each board. That solution looks good to me, but doesn't work with I2C. Thus, we could either modify the I2C driver to cope with the lack of device-tree or make the use of device-tree a hard requirement for driver model, implying that each omap3 boards would have to provide a device-tree file as well.

Both solutions look good to me and I'll let experts decide what to do. Either way, I need to know what the right solution to this problem is to be able to move forward.

_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot