This fixes smsc911x support on omap3evm that has been broken since
the smsc911x driver was updated to require the existence of vdd33a
and vddvario supplies.
Signed-off-by: Matt Porter <[email protected]>
---
arch/arm/mach-omap2/board-omap3evm.c | 46 +++++++++++++++++++++++++++++++++-
1 files changed, 45 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c
index 003fe34..ca63dda 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -433,9 +433,10 @@ static struct twl4030_keypad_data omap3evm_kp_data = {
/* ads7846 on SPI */
static struct regulator_consumer_supply omap3evm_vio_supply[] = {
REGULATOR_SUPPLY("vcc", "spi1.0"),
+ REGULATOR_SUPPLY("vddvario", "smsc911x.0"),
};
-/* VIO for ads7846 */
+/* VIO for ads7846, smsc911x, etc. */
static struct regulator_init_data omap3evm_vio = {
.constraints = {
.min_uV = 1800000,
@@ -450,6 +451,47 @@ static struct regulator_init_data omap3evm_vio = {
.consumer_supplies = omap3evm_vio_supply,
};
+/* OSK_3V3 for DVI, smsc911x, and expansion peripherals */
+static struct regulator_consumer_supply omap3evm_osk_3v3_supply[] = {
+ REGULATOR_SUPPLY("vdd33a", "smsc911x.0"),
+};
+
+static struct regulator_init_data omap3evm_osk_3v3 = {
+ .constraints = {
+ .min_uV = 3300000,
+ .max_uV = 3300000,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(omap3evm_osk_3v3_supply),
+ .consumer_supplies = omap3evm_osk_3v3_supply,
+};
+
+/*
+ * TWL4030 GPIO15 can control this regulator, but it is treated
+ * as always on since it is pulled down, enabling this regulator
+ * by default.
+ */
+static struct fixed_voltage_config omap3evm_osk_regulator_data = {
+ .supply_name = "osk_3v3",
+ .microvolts = 3300000, /* 3.30V */
+ .gpio = -EINVAL,
+ .startup_delay = 0,
+ .enable_high = 0,
+ .enabled_at_boot = 1,
+ .init_data = &omap3evm_osk_3v3,
+};
+
+static struct platform_device omap3evm_osk_regulator = {
+ .name = "reg-fixed-voltage",
+ .id = 0,
+ .dev = {
+ .platform_data = &omap3evm_osk_regulator_data,
+ },
+};
+
#ifdef CONFIG_WL12XX_PLATFORM_DATA
#define OMAP3EVM_WLAN_PMENA_GPIO (150)
@@ -631,6 +673,8 @@ static void __init omap3_evm_init(void)
omap3_evm_i2c_init();
+ platform_device_register(&omap3evm_osk_regulator);
+
omap_display_init(&omap3_evm_dss_data);
omap_serial_init();
--
1.7.5.4
* Matt Porter <[email protected]> [120208 13:35]:
> This fixes smsc911x support on omap3evm that has been broken since
> the smsc911x driver was updated to require the existence of vdd33a
> and vddvario supplies.
Great. Few comments:
1. Could you please include the smsc911x commit and subject here too
so it clearly shows the regression?
2. Also, why don't you add this fixed regulator to gpmc-smsc911.c?
That way it gets fixed for other too, like zoom2/3.
Regards,
Tony
On Fri, Feb 10, 2012 at 09:40:47AM -0800, Tony Lindgren wrote:
> * Matt Porter <[email protected]> [120208 13:35]:
> > This fixes smsc911x support on omap3evm that has been broken since
> > the smsc911x driver was updated to require the existence of vdd33a
> > and vddvario supplies.
>
> Great. Few comments:
>
> 1. Could you please include the smsc911x commit and subject here too
> so it clearly shows the regression?
Sure. Will do for v2.
> 2. Also, why don't you add this fixed regulator to gpmc-smsc911.c?
>
> That way it gets fixed for other too, like zoom2/3.
Ok, so I considered that at first and had two concerns that made me just
do it in the omap3evm specific way and see what the feedback was.
1) If we do a generic implementation in gpmc-smsc911x.c, there needs to
be a way to override it. Another board may have a variable supply that
feeds this consumer.
2) Technically, this omap3evm specific implementation matches the hardware
in that the osk_3v3 rail is software controllable. Granted, I commented
that we simply don't hook up the gpio at this time since this real
hardware regulator has always been silently asserted on by the nature of
the reset state of the TWL GPIOs and the board level pull downs as well.
So that said, I don't need #2 to make omap3evm work and I don't think
anybody cares yet to actually turn that regulator off (as it will kill
other things that appear to not have regulator support anyway). It looks
like you talked me into respinning it as a generic implementation. Only
question is whether I should bother consider not-yet-existing boards that
may not want that generic regulator.
-Matt
* Matt Porter <[email protected]> [120210 10:19]:
> On Fri, Feb 10, 2012 at 09:40:47AM -0800, Tony Lindgren wrote:
> > * Matt Porter <[email protected]> [120208 13:35]:
> > > This fixes smsc911x support on omap3evm that has been broken since
> > > the smsc911x driver was updated to require the existence of vdd33a
> > > and vddvario supplies.
> >
> > Great. Few comments:
> >
> > 1. Could you please include the smsc911x commit and subject here too
> > so it clearly shows the regression?
>
> Sure. Will do for v2.
>
> > 2. Also, why don't you add this fixed regulator to gpmc-smsc911.c?
> >
> > That way it gets fixed for other too, like zoom2/3.
>
> Ok, so I considered that at first and had two concerns that made me just
> do it in the omap3evm specific way and see what the feedback was.
>
> 1) If we do a generic implementation in gpmc-smsc911x.c, there needs to
> be a way to override it. Another board may have a variable supply that
> feeds this consumer.
>
> 2) Technically, this omap3evm specific implementation matches the hardware
> in that the osk_3v3 rail is software controllable. Granted, I commented
> that we simply don't hook up the gpio at this time since this real
> hardware regulator has always been silently asserted on by the nature of
> the reset state of the TWL GPIOs and the board level pull downs as well.
OK
> So that said, I don't need #2 to make omap3evm work and I don't think
> anybody cares yet to actually turn that regulator off (as it will kill
> other things that appear to not have regulator support anyway). It looks
> like you talked me into respinning it as a generic implementation. Only
> question is whether I should bother consider not-yet-existing boards that
> may not want that generic regulator.
Well for future boards the regulator should come from device tree,
so for now it should be safe to add it to gpmc-smsc911.c.
Regards,
Tony
On Fri, Feb 10, 2012 at 02:53:41PM -0800, Tony Lindgren wrote:
> * Matt Porter <[email protected]> [120210 10:19]:
> > On Fri, Feb 10, 2012 at 09:40:47AM -0800, Tony Lindgren wrote:
> > > * Matt Porter <[email protected]> [120208 13:35]:
> > > > This fixes smsc911x support on omap3evm that has been broken since
> > > > the smsc911x driver was updated to require the existence of vdd33a
> > > > and vddvario supplies.
> > >
> > > Great. Few comments:
> > >
> > > 1. Could you please include the smsc911x commit and subject here too
> > > so it clearly shows the regression?
> >
> > Sure. Will do for v2.
> >
> > > 2. Also, why don't you add this fixed regulator to gpmc-smsc911.c?
> > >
> > > That way it gets fixed for other too, like zoom2/3.
> >
> > Ok, so I considered that at first and had two concerns that made me just
> > do it in the omap3evm specific way and see what the feedback was.
> >
> > 1) If we do a generic implementation in gpmc-smsc911x.c, there needs to
> > be a way to override it. Another board may have a variable supply that
> > feeds this consumer.
> >
> > 2) Technically, this omap3evm specific implementation matches the hardware
> > in that the osk_3v3 rail is software controllable. Granted, I commented
> > that we simply don't hook up the gpio at this time since this real
> > hardware regulator has always been silently asserted on by the nature of
> > the reset state of the TWL GPIOs and the board level pull downs as well.
>
> OK
>
> > So that said, I don't need #2 to make omap3evm work and I don't think
> > anybody cares yet to actually turn that regulator off (as it will kill
> > other things that appear to not have regulator support anyway). It looks
> > like you talked me into respinning it as a generic implementation. Only
> > question is whether I should bother consider not-yet-existing boards that
> > may not want that generic regulator.
>
> Well for future boards the regulator should come from device tree,
> so for now it should be safe to add it to gpmc-smsc911.c.
Ok, sounds good. Posted an updated version.
-Matt