ARM: OMAP3: cm-t35/cm-t3730 fixes
Subsystems (3)
cover ARM: OMAP3: cm-t35/cm-t3730 fixes
This patch series fixes several issues on boards in subj. It is based on Tony's board branch at [1].
[1] git://github.com/tmlind/linux.git
Igor Grinberg (4):
ARM: OMAP3: cm-t35: add regulator supply for ads7846
ARM: OMAP3: cm-t35: fix DSS regulator supply
ARM: OMAP3: cm-t35: fix audio
arm: omap3: cm-t35: add reset for sb-t35 usb hub
arch/arm/mach-omap2/board-cm-t35.c | 50 ++++++++++++++++++++++++++++------- 1 files changed, 40 insertions(+), 10 deletions(-)
Signature · 1 line
1.7.3.4
PATCH 1/4 ARM: OMAP3: cm-t35: add regulator supply for ads7846
--- arch/arm/mach-omap2/board-cm-t35.c | 18 ++++++++++++++++++ 1 files changed, 18 insertions(+), 0 deletions(-)
arch/arm/mach-omap2/board-cm-t35.c +18 -0
@@ -343,6 +343,10 @@ static struct regulator_consumer_supply cm_t35_vdvi_supply[] = { REGULATOR_SUPPLY("vdvi", "omapdss"), }; +static struct regulator_consumer_supply cm_t35_vio_supplies[] = { +REGULATOR_SUPPLY ("vcc" ,"spi1.0" ), +}; +/* VMMC1 for MMC1 pins CMD, CLK, DAT0..DAT3 (20 mA, plus card == max 220 mA) */ static struct regulator_init_data cm_t35_vmmc1 = { .constraints = {
@@ -373,6 +377,19 @@ static struct regulator_init_data cm_t35_vsim = { .consumer_supplies = cm_t35_vsim_supply, }; +static struct regulator_init_data cm_t35_vio = { + .constraints = { + .min_uV =1800000 , + .max_uV =1800000 , + .apply_uV = true, + .valid_modes_mask =REGULATOR_MODE_NORMAL + |REGULATOR_MODE_STANDBY , + .valid_ops_mask =REGULATOR_CHANGE_MODE , + }, + .num_consumer_supplies =ARRAY_SIZE (cm_t35_vio_supplies), + .consumer_supplies = cm_t35_vio_supplies, +}; +static uint32_t cm_t35_keymap[] = {KEY (0 ,0 ,KEY_A ),KEY (0 ,1 ,KEY_B ),KEY (0 ,2 ,KEY_LEFT ),KEY (1 ,0 ,KEY_UP ),KEY (1 ,1 ,KEY_ENTER ),KEY (1 ,2 ,KEY_DOWN ),
@@ -456,6 +473,7 @@ static struct twl4030_platform_data cm_t35_twldata = { .gpio = &cm_t35_gpio_data, .vmmc1 = &cm_t35_vmmc1, .vsim = &cm_t35_vsim, + .vio = &cm_t35_vio, };static void __init cm_t35_init_i2c (void )
Signature · 1 line
1.7.3.4
Tony Lindgren
maintainerPATCH 1/4 ARM: OMAP3: cm-t35: add regulator supply for ads7846
Quoted 42 lines · Igor Grinberg
Signed-off-by Igor Grinberg <[email protected]>--- arch/arm/mach-omap2/board-cm-t35.c | 18 ++++++++++++++++++ 1 files changed, 18 insertions(+), 0 deletions(-)arch/arm/mach-omap2/board-cm-t35.c +17
-0@@ -343,6 +343,10 @@ static struct regulator_consumer_supply cm_t35_vdvi_supply[] = { REGULATOR_SUPPLY("vdvi", "omapdss"), }; +static struct regulator_consumer_supply cm_t35_vio_supplies[] = { +REGULATOR_SUPPLY ("vcc" ,"spi1.0" ), +}; +/* VMMC1 for MMC1 pins CMD, CLK, DAT0..DAT3 (20 mA, plus card == max 220 mA) */ static struct regulator_init_data cm_t35_vmmc1 = { .constraints = {@@ -373,6 +377,19 @@ static struct regulator_init_data cm_t35_vsim = { .consumer_supplies = cm_t35_vsim_supply, }; +static struct regulator_init_data cm_t35_vio = { + .constraints = { + .min_uV =1800000 , + .max_uV =1800000 , + .apply_uV = true, + .valid_modes_mask =REGULATOR_MODE_NORMAL + |REGULATOR_MODE_STANDBY , + .valid_ops_mask =REGULATOR_CHANGE_MODE , + }, + .num_consumer_supplies =ARRAY_SIZE (cm_t35_vio_supplies), + .consumer_supplies = cm_t35_vio_supplies, +}; +static uint32_t cm_t35_keymap[] = {KEY (0 ,0 ,KEY_A ),KEY (0 ,1 ,KEY_B ),KEY (0 ,2 ,KEY_LEFT ),KEY (1 ,0 ,KEY_UP ),KEY (1 ,1 ,KEY_ENTER ),KEY (1 ,2 ,KEY_DOWN ),
arch/arm/mach-omap2/board-cm-t35.c static struct twl4030_platform_data cm_t35_twldata = { · line 479
Quoted 7 lines
arch/arm/mach-omap2/board-cm-t35.c +1
-0@@ -456,6 +473,7 @@ static struct twl4030_platform_data cm_t35_twldata = { .gpio = &cm_t35_gpio_data, .vmmc1 = &cm_t35_vmmc1, .vsim = &cm_t35_vsim, + .vio = &cm_t35_vio, };static void __init cm_t35_init_i2c (void )
Applying to board branch for v3.3 merge window.
Tony
Tony Lindgren
maintainerPATCH 1/4 ARM: OMAP3: cm-t35: add regulator supply for ads7846
Quoted 3 lines · Tony Lindgren
* Igor Grinberg <[email protected]> [111019 02:05]:
Applying to board branch for v3.3 merge window.
Hmm, actually I suggest you respin patches 2 and 3 so they apply on their own to current fixes branch. Then update 1 and 4 to apply on top of those.
This way we can apply 2 and 3 during the -rc cycle, and then queue 1 and 4 for the next merge window.
Regards,
Tony
PATCH 1/4 ARM: OMAP3: cm-t35: add regulator supply for ads7846
Hi Tony,
Quoted 11 lines · Tony Lindgren
Quoted 3 lines · Tony Lindgren
* Igor Grinberg <[email protected]> [111019 02:05]:
Applying to board branch for v3.3 merge window.
Hmm, actually I suggest you respin patches 2 and 3 so they apply on their own to current fixes branch. Then update 1 and 4 to apply on top of those.
This way we can apply 2 and 3 during the -rc cycle, and then queue 1 and 4 for the next merge window.
Well, actually all them are fixes, although it cannot be understood from the subject.
I will adjust the subjects (and may be the commit messages also) to be more specific and resend.
Thanks
Signature · 2 lines
Regards, Igor.
Tony Lindgren
maintainerPATCH 1/4 ARM: OMAP3: cm-t35: add regulator supply for ads7846
Quoted 12 lines · Igor Grinberg
Hi Tony,
Quoted 9 lines · Tony Lindgren
Quoted 3 lines · Tony Lindgren
* Igor Grinberg <[email protected]> [111019 02:05]:
Applying to board branch for v3.3 merge window.
Hmm, actually I suggest you respin patches 2 and 3 so they apply on their own to current fixes branch. Then update 1 and 4 to apply on top of those.
Quoted 7 lines
Quoted 2 lines
This way we can apply 2 and 3 during the -rc cycle, and then queue 1 and 4 for the next merge window.
Well, actually all them are fixes, although it cannot be understood from the subject.
I will adjust the subjects (and may be the commit messages also) to be more specific and resend.
Hmm 1 & 4 are "features that never worked" type fixes, so they have flame potential. Those have to wait for the next merge window.
Patches 2 & 3 could be justified as fixes during the -rc cycle.
Or I can just apply all of them into board branch to wait for the next merge window.
Tony
PATCH 1/4 ARM: OMAP3: cm-t35: add regulator supply for ads7846
Quoted 16 lines · Tony Lindgren
Quoted 15 lines · Igor Grinberg
Hi Tony,
Quoted 11 lines · Tony Lindgren
Quoted 3 lines · Tony Lindgren
* Igor Grinberg <[email protected]> [111019 02:05]:
Applying to board branch for v3.3 merge window.
Hmm, actually I suggest you respin patches 2 and 3 so they apply on their own to current fixes branch. Then update 1 and 4 to apply on top of those.
This way we can apply 2 and 3 during the -rc cycle, and then queue 1 and 4 for the next merge window.
Quoted 7 lines
Quoted 4 lines
Well, actually all them are fixes, although it cannot be understood from the subject.
I will adjust the subjects (and may be the commit messages also) to be more specific and resend.Hmm 1 & 4 are "features that never worked" type fixes, so they have flame potential. Those have to wait for the next merge window.
Not exactly:
1/4 is a fix that I should have submitted more than a year ago, just after the ads7846 got support for the regulators:
---------
commit 91143379b01b2020d8878d627ebe9dfb9d6eb4c8
Author: Grazvydas Ignotas <[email protected]> Date: Thu Feb 25 02:04:56 2010 -0800
Input: ads7846 - add regulator support
The ADS7846/TSC2046 touchscreen controllers can (and usually are) connected to various regulators for power, so add regulator support.
Valid regulator will now be required, so boards without complete regulator setup should either disable regulator framework or enable CONFIG_REGULATOR_DUMMY.
---------
4/4 is a functionality fix, that also should have been submitted some time ago. We had this one locally and finally I've sent it out. With out it, the
USB hub sometimes works, but not always.
I've came back to that issue while working on CM-T3730 and finally sent it.
So now, when I'm sure you have all the information, what will it be?
If you still think it should be split up - that's fine with me, I will do the thing and resend.
Otherwise, what about the v2 I've sent?
Quoted 2 lines
Patches 2 & 3 could be justified as fixes during the -rc cycle.
So here we have no doubt. Good.
Quoted 3 lines
Or I can just apply all of them into board branch to wait for the next merge window.
That can be an option, if it bothers you too much, but I prefer to have this already in 3.2.
Thanks
Signature · 2 lines
Regards, Igor.
Tony Lindgren
maintainerPATCH 1/4 ARM: OMAP3: cm-t35: add regulator supply for ads7846
Quoted 22 lines · Igor Grinberg
Quoted 21 lines · Tony Lindgren
Quoted 19 lines · Igor Grinberg
Hi Tony,
Quoted 11 lines · Tony Lindgren
Quoted 3 lines · Tony Lindgren
* Igor Grinberg <[email protected]> [111019 02:05]:
Applying to board branch for v3.3 merge window.
Hmm, actually I suggest you respin patches 2 and 3 so they apply on their own to current fixes branch. Then update 1 and 4 to apply on top of those.
This way we can apply 2 and 3 during the -rc cycle, and then queue 1 and 4 for the next merge window.
Well, actually all them are fixes, although it cannot be understood from the subject.
I will adjust the subjects (and may be the commit messages also) to be more specific and resend.
Quoted 7 lines
Quoted 2 lines
Hmm 1 & 4 are "features that never worked" type fixes, so they have flame potential. Those have to wait for the next merge window.
Not exactly:
1/4 is a fix that I should have submitted more than a year ago, just after the ads7846 got support for the regulators:
Sounds like it's not that urgent then :)
Quoted 5 lines
Quoted 2 lines
Or I can just apply all of them into board branch to wait for the next merge window.
That can be an option, if it bothers you too much, but I prefer to have this already in 3.2.
I'll just apply them into board branch to wait for the next merge window then.
Thanks,
Tony
PATCH 1/4 ARM: OMAP3: cm-t35: add regulator supply for ads7846
Quoted 33 lines · Tony Lindgren
Quoted 22 lines · Igor Grinberg
Quoted 21 lines · Tony Lindgren
Quoted 19 lines · Igor Grinberg
Hi Tony,
Quoted 11 lines · Tony Lindgren
Quoted 3 lines · Tony Lindgren
* Igor Grinberg <[email protected]> [111019 02:05]:
Applying to board branch for v3.3 merge window.
Hmm, actually I suggest you respin patches 2 and 3 so they apply on their own to current fixes branch. Then update 1 and 4 to apply on top of those.
This way we can apply 2 and 3 during the -rc cycle, and then queue 1 and 4 for the next merge window.
Well, actually all them are fixes, although it cannot be understood from the subject.
I will adjust the subjects (and may be the commit messages also) to be more specific and resend.Quoted 7 lines
Quoted 2 lines
Hmm 1 & 4 are "features that never worked" type fixes, so they have flame potential. Those have to wait for the next merge window.
Not exactly:
1/4 is a fix that I should have submitted more than a year ago, just after the ads7846 got support for the regulators:
Sounds like it's not that urgent then :)
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
Or I can just apply all of them into board branch to wait for the next merge window.
That can be an option, if it bothers you too much, but I prefer to have this already in 3.2.
I'll just apply them into board branch to wait for the next merge window then.
No problem, thanks
Signature · 2 lines
Regards, Igor.
PATCH 2/4 ARM: OMAP3: cm-t35: fix DSS regulator supply
In reply to Igor Grinbergcm-t35 DSS suplies are connected to VIO.
In fact, TPS65930 does not have VPLL2.
--- arch/arm/mach-omap2/board-cm-t35.c | 13 +++---------- 1 files changed, 3 insertions(+), 10 deletions(-)
arch/arm/mach-omap2/board-cm-t35.c +3 -10
@@ -339,12 +339,10 @@ static struct regulator_consumer_supply cm_t35_vsim_supply[] = { REGULATOR_SUPPLY("vmmc_aux", "omap_hsmmc.0"), }; -static struct regulator_consumer_supply cm_t35_vdvi_supply[] = { -REGULATOR_SUPPLY ("vdvi" ,"omapdss" ), -}; -static struct regulator_consumer_supply cm_t35_vio_supplies[] = {REGULATOR_SUPPLY ("vcc" ,"spi1.0" ), +REGULATOR_SUPPLY ("vdds_dsi" ,"omapdss" ), +REGULATOR_SUPPLY ("vdds_dsi" ,"omapdss_dsi1" ), };/* VMMC1 for MMC1 pins CMD, CLK, DAT0..DAT3 (20 mA, plus card == max 220 mA) */
@@ -479,12 +477,7 @@ static struct twl4030_platform_data cm_t35_twldata = {static void __init cm_t35_init_i2c (void ) {omap3_pmic_get_config (&cm_t35_twldata,TWL_COMMON_PDATA_USB , -TWL_COMMON_REGULATOR_VDAC |TWL_COMMON_REGULATOR_VPLL2 ); - - cm_t35_twldata.vpll2->constraints.name ="VDVI" ; - cm_t35_twldata.vpll2->num_consumer_supplies = -ARRAY_SIZE (cm_t35_vdvi_supply); - cm_t35_twldata.vpll2->consumer_supplies = cm_t35_vdvi_supply; +TWL_COMMON_REGULATOR_VDAC );omap3_pmic_init ("tps65930" , &cm_t35_twldata); }
Signature · 1 line
1.7.3.4
PATCH 3/4 ARM: OMAP3: cm-t35: fix audio
In reply to Igor GrinbergTWL4030 audio codec is not being registered if no platform data is supplied. Plovide platform data for the TWL4030 audio codec.
--- arch/arm/mach-omap2/board-cm-t35.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-)
arch/arm/mach-omap2/board-cm-t35.c +2 -1
@@ -477,7 +477,8 @@ static struct twl4030_platform_data cm_t35_twldata = {static void __init cm_t35_init_i2c (void ) {omap3_pmic_get_config (&cm_t35_twldata,TWL_COMMON_PDATA_USB , -TWL_COMMON_REGULATOR_VDAC ); +TWL_COMMON_REGULATOR_VDAC | +TWL_COMMON_PDATA_AUDIO );omap3_pmic_init ("tps65930" , &cm_t35_twldata); }
Signature · 1 line
1.7.3.4
PATCH 3/4 ARM: OMAP3: cm-t35: fix audio
Hello.
Quoted 2 lines · Igor Grinberg
TWL4030 audio codec is not being registered if no platform data is supplied. Plovide platform data for the TWL4030 audio codec.
s/Plovide/Provide/. Perhaps a committer can fix this typo.
Quoted 1 line
Signed-off-by Igor Grinberg<[email protected]>
WBR, Sergei
PATCH 3/4 ARM: OMAP3: cm-t35: fix audio
Hi Sergei,
Quoted 8 lines · Sergei Shtylyov
Hello.
Quoted 2 lines · Igor Grinberg
TWL4030 audio codec is not being registered if no platform data is supplied. Plovide platform data for the TWL4030 audio codec.
s/Plovide/Provide/. Perhaps a committer can fix this typo.
This one is really nice ;)
Thanks
Signature · 2 lines
Regards, Igor.
PATCH v2 3/4 ARM: OMAP3: cm-t35: fix audio
In reply to Sergei ShtylyovTWL4030 audio codec is not being registered if no platform data is supplied. Provide platform data for the TWL4030 audio codec.
---
v2: fix the commit message (10x to Sergei)
arch/arm/mach-omap2/board-cm-t35.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-)
arch/arm/mach-omap2/board-cm-t35.c +2 -1
@@ -477,7 +477,8 @@ static struct twl4030_platform_data cm_t35_twldata = {static void __init cm_t35_init_i2c (void ) {omap3_pmic_get_config (&cm_t35_twldata,TWL_COMMON_PDATA_USB , -TWL_COMMON_REGULATOR_VDAC ); +TWL_COMMON_REGULATOR_VDAC | +TWL_COMMON_PDATA_AUDIO );omap3_pmic_init ("tps65930" , &cm_t35_twldata); }
Signature · 1 line
1.7.3.4
PATCH 4/4 arm: omap3: cm-t35: add reset for sb-t35 usb hub
In reply to Igor Grinberg--- arch/arm/mach-omap2/board-cm-t35.c | 22 ++++++++++++++++++++-- 1 files changed, 20 insertions(+), 2 deletions(-)
arch/arm/mach-omap2/board-cm-t35.c +20 -2
@@ -52,7 +52,8 @@#include "hsmmc.h" #include "common-board-devices.h" -#define CM_T35_GPIO_PENDOWN 57 +#define CM_T35_GPIO_PENDOWN 57 +#define SB_T35_USB_HUB_RESET_GPIO 167#define CM_T35_SMSC911X_CS 5#define CM_T35_SMSC911X_GPIO 163
@@ -436,6 +437,23 @@ static struct usbhs_omap_board_data usbhs_bdata __initdata = { .reset_gpio_port[2] = -EINVAL }; +static void cm_t35_init_usbh (void ) +{ +int err; + + err =gpio_request_one (SB_T35_USB_HUB_RESET_GPIO , +GPIOF_OUT_INIT_LOW ,"usb hub rst" ); +if (err) { +pr_err ("SB-T35: usb hub rst gpio request failed: %d\n" , err); + }else { +udelay (10 ); +gpio_set_value (SB_T35_USB_HUB_RESET_GPIO ,1 ); +msleep (1 ); + } + +usbhs_init (&usbhs_bdata); +} +static int cm_t35_twl_gpio_setup (struct device *dev,unsigned gpio,unsigned ngpio) {
@@ -624,7 +642,7 @@ static void __init cm_t3x_common_init(void)cm_t35_init_display ();usb_musb_init (NULL ); -usbhs_init (&usbhs_bdata); +cm_t35_init_usbh (); }static void __init cm_t35_init (void )
Signature · 1 line
1.7.3.4
PATCH v2 4/4 ARM: OMAP3: cm-t35: add reset for sb-t35 usb hub
---
v2: fixed subject, no change functional changes
arch/arm/mach-omap2/board-cm-t35.c | 22 ++++++++++++++++++++-- 1 files changed, 20 insertions(+), 2 deletions(-)
arch/arm/mach-omap2/board-cm-t35.c +20 -2
@@ -52,7 +52,8 @@#include "hsmmc.h" #include "common-board-devices.h" -#define CM_T35_GPIO_PENDOWN 57 +#define CM_T35_GPIO_PENDOWN 57 +#define SB_T35_USB_HUB_RESET_GPIO 167#define CM_T35_SMSC911X_CS 5#define CM_T35_SMSC911X_GPIO 163
@@ -436,6 +437,23 @@ static struct usbhs_omap_board_data usbhs_bdata __initdata = { .reset_gpio_port[2] = -EINVAL }; +static void cm_t35_init_usbh (void ) +{ +int err; + + err =gpio_request_one (SB_T35_USB_HUB_RESET_GPIO , +GPIOF_OUT_INIT_LOW ,"usb hub rst" ); +if (err) { +pr_err ("SB-T35: usb hub rst gpio request failed: %d\n" , err); + }else { +udelay (10 ); +gpio_set_value (SB_T35_USB_HUB_RESET_GPIO ,1 ); +msleep (1 ); + } + +usbhs_init (&usbhs_bdata); +} +static int cm_t35_twl_gpio_setup (struct device *dev,unsigned gpio,unsigned ngpio) {
@@ -624,7 +642,7 @@ static void __init cm_t3x_common_init(void)cm_t35_init_display ();usb_musb_init (NULL ); -usbhs_init (&usbhs_bdata); +cm_t35_init_usbh (); }static void __init cm_t35_init (void )
Signature · 1 line
1.7.3.4
v2 cover ARM: OMAP3: cm-t35/cm-t3730 fixes
In reply to Igor GrinbergThis patch series fixes several issues on boards in subj. It is based on Tony's fixes branch.
v2: - Rebase on top of fixes branch
- Elaborate more in the commit messages
Igor Grinberg (4):
ARM: OMAP3: cm-t35: fix ads7846 touchscreen
ARM: OMAP3: cm-t35: fix DSS regulator supply
ARM: OMAP3: cm-t35: fix audio
ARM: OMAP3: cm-t35: fix USB hub
arch/arm/mach-omap2/board-cm-t35.c | 50 ++++++++++++++++++++++++++++------- 1 files changed, 40 insertions(+), 10 deletions(-)
Signature · 1 line
1.7.3.4
PATCH v2 1/4 ARM: OMAP3: cm-t35: fix ads7846 touchscreen
ads7846 driver fails to find the regulator supply and as a result the touchscreen is not working.
Fix this by adding a regulator supply for the ads7846 driver.
---
v2: - Rebase on top of fixes branch
- Elaborate on the problem in the commit message
arch/arm/mach-omap2/board-cm-t35.c | 18 ++++++++++++++++++ 1 files changed, 18 insertions(+), 0 deletions(-)
arch/arm/mach-omap2/board-cm-t35.c +18 -0
@@ -343,6 +343,10 @@ static struct regulator_consumer_supply cm_t35_vdvi_supply[] = { REGULATOR_SUPPLY("vdvi", "omapdss"), }; +static struct regulator_consumer_supply cm_t35_vio_supplies[] = { +REGULATOR_SUPPLY ("vcc" ,"spi1.0" ), +}; +/* VMMC1 for MMC1 pins CMD, CLK, DAT0..DAT3 (20 mA, plus card == max 220 mA) */ static struct regulator_init_data cm_t35_vmmc1 = { .constraints = {
@@ -373,6 +377,19 @@ static struct regulator_init_data cm_t35_vsim = { .consumer_supplies = cm_t35_vsim_supply, }; +static struct regulator_init_data cm_t35_vio = { + .constraints = { + .min_uV =1800000 , + .max_uV =1800000 , + .apply_uV = true, + .valid_modes_mask =REGULATOR_MODE_NORMAL + |REGULATOR_MODE_STANDBY , + .valid_ops_mask =REGULATOR_CHANGE_MODE , + }, + .num_consumer_supplies =ARRAY_SIZE (cm_t35_vio_supplies), + .consumer_supplies = cm_t35_vio_supplies, +}; +static uint32_t cm_t35_keymap[] = {KEY (0 ,0 ,KEY_A ),KEY (0 ,1 ,KEY_B ),KEY (0 ,2 ,KEY_LEFT ),KEY (1 ,0 ,KEY_UP ),KEY (1 ,1 ,KEY_ENTER ),KEY (1 ,2 ,KEY_DOWN ),
@@ -456,6 +473,7 @@ static struct twl4030_platform_data cm_t35_twldata = { .gpio = &cm_t35_gpio_data, .vmmc1 = &cm_t35_vmmc1, .vsim = &cm_t35_vsim, + .vio = &cm_t35_vio, };static void __init cm_t35_init_i2c (void )
Signature · 1 line
1.7.3.4
PATCH v2 2/4 ARM: OMAP3: cm-t35: fix DSS regulator supply
In reply to Igor Grinbergcm-t35 DSS suplies are connected to VIO.
In fact, TPS65930 does not have VPLL2.
---
v2: - Rebase on top of fixes branch
arch/arm/mach-omap2/board-cm-t35.c | 13 +++---------- 1 files changed, 3 insertions(+), 10 deletions(-)
arch/arm/mach-omap2/board-cm-t35.c +3 -10
@@ -339,12 +339,10 @@ static struct regulator_consumer_supply cm_t35_vsim_supply[] = { REGULATOR_SUPPLY("vmmc_aux", "omap_hsmmc.0"), }; -static struct regulator_consumer_supply cm_t35_vdvi_supply[] = { -REGULATOR_SUPPLY ("vdvi" ,"omapdss" ), -}; -static struct regulator_consumer_supply cm_t35_vio_supplies[] = {REGULATOR_SUPPLY ("vcc" ,"spi1.0" ), +REGULATOR_SUPPLY ("vdds_dsi" ,"omapdss" ), +REGULATOR_SUPPLY ("vdds_dsi" ,"omapdss_dsi1" ), };/* VMMC1 for MMC1 pins CMD, CLK, DAT0..DAT3 (20 mA, plus card == max 220 mA) */
@@ -479,12 +477,7 @@ static struct twl4030_platform_data cm_t35_twldata = {static void __init cm_t35_init_i2c (void ) {omap3_pmic_get_config (&cm_t35_twldata,TWL_COMMON_PDATA_USB , -TWL_COMMON_REGULATOR_VDAC |TWL_COMMON_REGULATOR_VPLL2 ); - - cm_t35_twldata.vpll2->constraints.name ="VDVI" ; - cm_t35_twldata.vpll2->num_consumer_supplies = -ARRAY_SIZE (cm_t35_vdvi_supply); - cm_t35_twldata.vpll2->consumer_supplies = cm_t35_vdvi_supply; +TWL_COMMON_REGULATOR_VDAC );omap3_pmic_init ("tps65930" , &cm_t35_twldata); }
Signature · 1 line
1.7.3.4
PATCH v2 3/4 ARM: OMAP3: cm-t35: fix audio
In reply to Igor GrinbergTWL4030 audio codec is not being registered if no platform data is supplied. Provide platform data for the TWL4030 audio codec.
---
v2: - Rebase on top of fixes branch
- fix the commit message (10x to Sergei)
arch/arm/mach-omap2/board-cm-t35.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-)
arch/arm/mach-omap2/board-cm-t35.c +2 -1
@@ -477,7 +477,8 @@ static struct twl4030_platform_data cm_t35_twldata = {static void __init cm_t35_init_i2c (void ) {omap3_pmic_get_config (&cm_t35_twldata,TWL_COMMON_PDATA_USB , -TWL_COMMON_REGULATOR_VDAC ); +TWL_COMMON_REGULATOR_VDAC | +TWL_COMMON_PDATA_AUDIO );omap3_pmic_init ("tps65930" , &cm_t35_twldata); }
Signature · 1 line
1.7.3.4
PATCH v2 4/4 ARM: OMAP3: cm-t35: fix USB hub
In reply to Igor GrinbergUSB hub is not functional until is reset.
Reset the USB hub on SB-T35.
---
v2: - Rebase on top of fixes branch
- Elaborate on the problem in the commit message
arch/arm/mach-omap2/board-cm-t35.c | 22 ++++++++++++++++++++-- 1 files changed, 20 insertions(+), 2 deletions(-)
arch/arm/mach-omap2/board-cm-t35.c +20 -2
@@ -53,7 +53,8 @@#include "hsmmc.h" #include "common-board-devices.h" -#define CM_T35_GPIO_PENDOWN 57 +#define CM_T35_GPIO_PENDOWN 57 +#define SB_T35_USB_HUB_RESET_GPIO 167#define CM_T35_SMSC911X_CS 5#define CM_T35_SMSC911X_GPIO 163
@@ -436,6 +437,23 @@ static struct usbhs_omap_board_data usbhs_bdata __initdata = { .reset_gpio_port[2] = -EINVAL }; +static void cm_t35_init_usbh (void ) +{ +int err; + + err =gpio_request_one (SB_T35_USB_HUB_RESET_GPIO , +GPIOF_OUT_INIT_LOW ,"usb hub rst" ); +if (err) { +pr_err ("SB-T35: usb hub rst gpio request failed: %d\n" , err); + }else { +udelay (10 ); +gpio_set_value (SB_T35_USB_HUB_RESET_GPIO ,1 ); +msleep (1 ); + } + +usbhs_init (&usbhs_bdata); +} +static int cm_t35_twl_gpio_setup (struct device *dev,unsigned gpio,unsigned ngpio) {
@@ -624,7 +642,7 @@ static void __init cm_t3x_common_init(void)cm_t35_init_display ();usb_musb_init (NULL ); -usbhs_init (&usbhs_bdata); +cm_t35_init_usbh (); }static void __init cm_t35_init (void )
Signature · 1 line
1.7.3.4