Re: [PATCH 1/9] OMAP: DSS2: Change DSI platform device name from omapdss_dsi1 to omapdss_dsi

2011-06-13 Thread Tomi Valkeinen 
Tony, Ping.

I'd like this DSS regulator issue decided on way or another, as it's
stopping us getting Blaze board's panels working on mainline, and also
preventing me from porting the old omapfb drivers to DSS2.

 Tomi

On Tue, 2011-06-07 at 16:11 +0300, Tomi Valkeinen wrote:
 Hi Tony,
 
 On Wed, 2011-05-04 at 12:40 +0300, Tony Lindgren wrote:
  * Archit Taneja arc...@ti.com [110504 10:30]:
   --- a/arch/arm/mach-omap2/board-3430sdp.c
   +++ b/arch/arm/mach-omap2/board-3430sdp.c
   @@ -401,7 +401,7 @@ static struct regulator_consumer_supply 
   sdp3430_vdda_dac_supplies[] = {
/* VPLL2 for digital video outputs */
static struct regulator_consumer_supply sdp3430_vpll2_supplies[] = {
 REGULATOR_SUPPLY(vdds_dsi, omapdss),
   - REGULATOR_SUPPLY(vdds_dsi, omapdss_dsi1),
   + REGULATOR_SUPPLY(vdds_dsi, omapdss_dsi.0),
};

static struct regulator_consumer_supply sdp3430_vmmc1_supplies[] = {
   diff --git a/arch/arm/mach-omap2/board-4430sdp.c 
   b/arch/arm/mach-omap2/board-4430sdp.c
   index 570e83f..eafadb4 100644
   --- a/arch/arm/mach-omap2/board-4430sdp.c
   +++ b/arch/arm/mach-omap2/board-4430sdp.c
   @@ -375,7 +375,7 @@ static struct regulator_consumer_supply 
   sdp4430_vmmc_supply[] = {
};
static struct regulator_consumer_supply sdp4430_vcxio_supply[] = {
 REGULATOR_SUPPLY(vdds_dsi, omapdss_dss),
   - REGULATOR_SUPPLY(vdds_dsi, omapdss_dsi1),
   + REGULATOR_SUPPLY(vdds_dsi, omapdss_dsi.0),
};
  ...
  
  Looks like we should first combine all this cut and paste data
  for each board file into some common init function to cut
  down the crazy churn.
 
 I haven't been able to do this in a clean way. The regulator framework
 is rather static in this area, and adding the data for REGULATOR_SUPPLYs
 dynamically based on OMAP version is something I haven't been able to
 do.
 
 The best option I've found out is defining helper macros to add those
 consumers. An example patch below with 3430sdp and 4430sdp boards
 modified.
 
 This would allow boards to setup the regulators whatever way they want,
 but the 99% of the boards could just use the macros.
 
 It's still not as good as I'd want, because the source regulator is also
 the same for a particular OMAP version for 99% of the boards. So there's
 no real need to use those those macros in the board file, a common
 display file should be able to set everything up. But as I said, I
 haven't found out any way to do this.
 
 What is your opinion of this approach?
 
  Tomi
 
 
 
 diff --git a/arch/arm/mach-omap2/board-3430sdp.c
 b/arch/arm/mach-omap2/board-3430sdp.c
 index ae2963a..69b7e6f 100644
 --- a/arch/arm/mach-omap2/board-3430sdp.c
 +++ b/arch/arm/mach-omap2/board-3430sdp.c
 @@ -308,13 +308,12 @@ static struct regulator_consumer_supply
 sdp3430_vaux3_supplies[] = {
  };
  
  static struct regulator_consumer_supply sdp3430_vdda_dac_supplies[] = {
 - REGULATOR_SUPPLY(vdda_dac, omapdss_venc),
 + OMAP_DSS_VENC_SUPPLIES,
  };
  
  /* VPLL2 for digital video outputs */
  static struct regulator_consumer_supply sdp3430_vpll2_supplies[] = {
 - REGULATOR_SUPPLY(vdds_dsi, omapdss),
 - REGULATOR_SUPPLY(vdds_dsi, omapdss_dsi1),
 + OMAP_DSS_SUPPLIES,
  };
  
  static struct regulator_consumer_supply sdp3430_vmmc1_supplies[] = {
 diff --git a/arch/arm/mach-omap2/board-4430sdp.c
 b/arch/arm/mach-omap2/board-4430sdp.c
 index 2647a95..80bbf61 100644
 --- a/arch/arm/mach-omap2/board-4430sdp.c
 +++ b/arch/arm/mach-omap2/board-4430sdp.c
 @@ -339,8 +339,7 @@ static struct regulator_consumer_supply
 sdp4430_vmmc_supply[] = {
   },
  };
  static struct regulator_consumer_supply sdp4430_vcxio_supply[] = {
 - REGULATOR_SUPPLY(vdds_dsi, omapdss_dss),
 - REGULATOR_SUPPLY(vdds_dsi, omapdss_dsi1),
 + OMAP_DSS_SUPPLIES,
  };
  
  static int omap4_twl6030_hsmmc_late_init(struct device *dev)
 diff --git a/include/video/omapdss.h b/include/video/omapdss.h
 index bb39738..557b400 100644
 --- a/include/video/omapdss.h
 +++ b/include/video/omapdss.h
 @@ -636,4 +636,12 @@ int omap_rfbi_update(struct omap_dss_device
 *dssdev,
  int omap_rfbi_configure(struct omap_dss_device *dssdev, int pixel_size,
   int data_lines);
  
 +#define OMAP_DSS_SUPPLIES \
 + REGULATOR_SUPPLY(vdds_sdi, omapdss_dss), \
 + REGULATOR_SUPPLY(vdds_dsi, omapdss_dss), \
 + REGULATOR_SUPPLY(vdds_dsi, omapdss_dsi1)
 +
 +#define OMAP_DSS_VENC_SUPPLIES \
 + REGULATOR_SUPPLY(vdda_dac, omapdss_venc)
 +
  #endif
 
 


--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/9] OMAP: DSS2: Change DSI platform device name from omapdss_dsi1 to omapdss_dsi

2011-06-13 Thread Tony Lindgren 
* Tomi Valkeinen tomi.valkei...@ti.com [110607 06:07]:
 Hi Tony,
 
 On Wed, 2011-05-04 at 12:40 +0300, Tony Lindgren wrote:
  * Archit Taneja arc...@ti.com [110504 10:30]:
   --- a/arch/arm/mach-omap2/board-3430sdp.c
   +++ b/arch/arm/mach-omap2/board-3430sdp.c
   @@ -401,7 +401,7 @@ static struct regulator_consumer_supply 
   sdp3430_vdda_dac_supplies[] = {
/* VPLL2 for digital video outputs */
static struct regulator_consumer_supply sdp3430_vpll2_supplies[] = {
 REGULATOR_SUPPLY(vdds_dsi, omapdss),
   - REGULATOR_SUPPLY(vdds_dsi, omapdss_dsi1),
   + REGULATOR_SUPPLY(vdds_dsi, omapdss_dsi.0),
};

static struct regulator_consumer_supply sdp3430_vmmc1_supplies[] = {
   diff --git a/arch/arm/mach-omap2/board-4430sdp.c 
   b/arch/arm/mach-omap2/board-4430sdp.c
   index 570e83f..eafadb4 100644
   --- a/arch/arm/mach-omap2/board-4430sdp.c
   +++ b/arch/arm/mach-omap2/board-4430sdp.c
   @@ -375,7 +375,7 @@ static struct regulator_consumer_supply 
   sdp4430_vmmc_supply[] = {
};
static struct regulator_consumer_supply sdp4430_vcxio_supply[] = {
 REGULATOR_SUPPLY(vdds_dsi, omapdss_dss),
   - REGULATOR_SUPPLY(vdds_dsi, omapdss_dsi1),
   + REGULATOR_SUPPLY(vdds_dsi, omapdss_dsi.0),
};
  ...
  
  Looks like we should first combine all this cut and paste data
  for each board file into some common init function to cut
  down the crazy churn.
 
 I haven't been able to do this in a clean way. The regulator framework
 is rather static in this area, and adding the data for REGULATOR_SUPPLYs
 dynamically based on OMAP version is something I haven't been able to
 do.
 
 The best option I've found out is defining helper macros to add those
 consumers. An example patch below with 3430sdp and 4430sdp boards
 modified.
 
 This would allow boards to setup the regulators whatever way they want,
 but the 99% of the boards could just use the macros.
 
 It's still not as good as I'd want, because the source regulator is also
 the same for a particular OMAP version for 99% of the boards. So there's
 no real need to use those those macros in the board file, a common
 display file should be able to set everything up. But as I said, I
 haven't found out any way to do this.
 
 What is your opinion of this approach?

Well I guess the macros are a step in the right direction. Eventually
we should have just one istance of the regulator_consumer_supply and
just populate that instead of cloning it in each board file.

Regards,

Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/9] OMAP: DSS2: Change DSI platform device name from omapdss_dsi1 to omapdss_dsi

2011-06-07 Thread Tomi Valkeinen 
Hi Mark,

Waking up this old thread again.

On Wed, 2011-05-11 at 14:12 +0200, Mark Brown wrote:
 On Wed, May 11, 2011 at 12:23:45PM +0300, Tomi Valkeinen wrote:
 
  So how should the regulator be set up?
 
 You need to create a new regulator of some kind and then provide a way
 for machines to set the supply_regulator in the init_data.

What should this new regulator of some kind be? I was trying out with
fixed regulator, but I'm not quite sure if that's good here.

I don't want a full controllable regulator, but just a virtual route
regulator, which mirrors the state of the parent regulator.

(Well, I don't actually want that, I want to dynamically add some
REGULATOR_SUPPLYs to an existing regulator, but afaik that's not
possible.)

Can the fixed regulator be used like that?

Using a new regulator like this also means that there is a dependency
between the new regulator and the used source supply. I haven't solved
this yet, as the twl driver seems to add the regulators at some later
stage.

Below is my test patch for reference. It doesn't do the work in a common
file, so it's just for testing.

 Tomi

diff --git a/arch/arm/mach-omap2/board-4430sdp.c 
b/arch/arm/mach-omap2/board-4430sdp.c
index 2647a95..fb477f1 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -22,6 +22,7 @@
 #include linux/i2c/twl.h
 #include linux/gpio_keys.h
 #include linux/regulator/machine.h
+#include linux/regulator/fixed.h
 #include linux/leds.h
 #include linux/leds_pwm.h
 
@@ -277,10 +278,47 @@ static int omap_ethernet_init(void)
return status;
 }
 
+static struct regulator_consumer_supply fixed_supply[] = {
+   REGULATOR_SUPPLY(vdds_dsi, omapdss_dss),
+   REGULATOR_SUPPLY(vdds_dsi, omapdss_dsi1),
+};
+
+static struct regulator_init_data fixed_reg_init_data = {
+   .supply_regulator = VCXIO,
+   .constraints = {
+   .min_uV = 180,
+   .max_uV = 180,
+   .valid_modes_mask   = REGULATOR_MODE_NORMAL
+   | REGULATOR_MODE_STANDBY,
+   .valid_ops_mask  = REGULATOR_CHANGE_MODE
+   | REGULATOR_CHANGE_STATUS,
+   .always_on  = true,
+   },
+   .num_consumer_supplies  = ARRAY_SIZE(fixed_supply),
+   .consumer_supplies  = fixed_supply,
+};
+
+static struct fixed_voltage_config omap_dss_fixed_reg_data = {
+   .gpio = -EINVAL,
+   .supply_name = dss-regulator,
+   .init_data = fixed_reg_init_data,
+   .enabled_at_boot = 1,
+   .microvolts = 180,
+};
+
+static struct platform_device omap_dss_fixed_reg_device = {
+   .name   = reg-fixed-voltage,
+   .id = 3,
+   .dev= {
+   .platform_data  = omap_dss_fixed_reg_data,
+   },
+};
+
 static struct platform_device *sdp4430_devices[] __initdata = {
sdp4430_gpio_keys_device,
sdp4430_leds_gpio,
sdp4430_leds_pwm,
+   omap_dss_fixed_reg_device,
 };
 
 static struct omap_board_config_kernel sdp4430_config[] __initdata = {
@@ -339,8 +377,6 @@ static struct regulator_consumer_supply 
sdp4430_vmmc_supply[] = {
},
 };
 static struct regulator_consumer_supply sdp4430_vcxio_supply[] = {
-   REGULATOR_SUPPLY(vdds_dsi, omapdss_dss),
-   REGULATOR_SUPPLY(vdds_dsi, omapdss_dsi1),
 };
 
 static int omap4_twl6030_hsmmc_late_init(struct device *dev)


--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/9] OMAP: DSS2: Change DSI platform device name from omapdss_dsi1 to omapdss_dsi

2011-06-07 Thread Mark Brown 
On Tue, Jun 07, 2011 at 02:44:58PM +0300, Tomi Valkeinen wrote:
 On Wed, 2011-05-11 at 14:12 +0200, Mark Brown wrote:
  On Wed, May 11, 2011 at 12:23:45PM +0300, Tomi Valkeinen wrote:

  You need to create a new regulator of some kind and then provide a way
  for machines to set the supply_regulator in the init_data.

 What should this new regulator of some kind be? I was trying out with
 fixed regulator, but I'm not quite sure if that's good here.

It should be a regulator that does what you want.

 I don't want a full controllable regulator, but just a virtual route
 regulator, which mirrors the state of the parent regulator.

If it's not doing what you want then make a new one.

 Using a new regulator like this also means that there is a dependency
 between the new regulator and the used source supply. I haven't solved
 this yet, as the twl driver seems to add the regulators at some later
 stage.

I'm sorry but I can't parse what you're saying here at all.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/9] OMAP: DSS2: Change DSI platform device name from omapdss_dsi1 to omapdss_dsi

2011-06-07 Thread Tomi Valkeinen 
Hi Tony,

On Wed, 2011-05-04 at 12:40 +0300, Tony Lindgren wrote:
 * Archit Taneja arc...@ti.com [110504 10:30]:
  --- a/arch/arm/mach-omap2/board-3430sdp.c
  +++ b/arch/arm/mach-omap2/board-3430sdp.c
  @@ -401,7 +401,7 @@ static struct regulator_consumer_supply 
  sdp3430_vdda_dac_supplies[] = {
   /* VPLL2 for digital video outputs */
   static struct regulator_consumer_supply sdp3430_vpll2_supplies[] = {
  REGULATOR_SUPPLY(vdds_dsi, omapdss),
  -   REGULATOR_SUPPLY(vdds_dsi, omapdss_dsi1),
  +   REGULATOR_SUPPLY(vdds_dsi, omapdss_dsi.0),
   };
   
   static struct regulator_consumer_supply sdp3430_vmmc1_supplies[] = {
  diff --git a/arch/arm/mach-omap2/board-4430sdp.c 
  b/arch/arm/mach-omap2/board-4430sdp.c
  index 570e83f..eafadb4 100644
  --- a/arch/arm/mach-omap2/board-4430sdp.c
  +++ b/arch/arm/mach-omap2/board-4430sdp.c
  @@ -375,7 +375,7 @@ static struct regulator_consumer_supply 
  sdp4430_vmmc_supply[] = {
   };
   static struct regulator_consumer_supply sdp4430_vcxio_supply[] = {
  REGULATOR_SUPPLY(vdds_dsi, omapdss_dss),
  -   REGULATOR_SUPPLY(vdds_dsi, omapdss_dsi1),
  +   REGULATOR_SUPPLY(vdds_dsi, omapdss_dsi.0),
   };
 ...
 
 Looks like we should first combine all this cut and paste data
 for each board file into some common init function to cut
 down the crazy churn.

I haven't been able to do this in a clean way. The regulator framework
is rather static in this area, and adding the data for REGULATOR_SUPPLYs
dynamically based on OMAP version is something I haven't been able to
do.

The best option I've found out is defining helper macros to add those
consumers. An example patch below with 3430sdp and 4430sdp boards
modified.

This would allow boards to setup the regulators whatever way they want,
but the 99% of the boards could just use the macros.

It's still not as good as I'd want, because the source regulator is also
the same for a particular OMAP version for 99% of the boards. So there's
no real need to use those those macros in the board file, a common
display file should be able to set everything up. But as I said, I
haven't found out any way to do this.

What is your opinion of this approach?

 Tomi



diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index ae2963a..69b7e6f 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -308,13 +308,12 @@ static struct regulator_consumer_supply
sdp3430_vaux3_supplies[] = {
 };
 
 static struct regulator_consumer_supply sdp3430_vdda_dac_supplies[] = {
-   REGULATOR_SUPPLY(vdda_dac, omapdss_venc),
+   OMAP_DSS_VENC_SUPPLIES,
 };
 
 /* VPLL2 for digital video outputs */
 static struct regulator_consumer_supply sdp3430_vpll2_supplies[] = {
-   REGULATOR_SUPPLY(vdds_dsi, omapdss),
-   REGULATOR_SUPPLY(vdds_dsi, omapdss_dsi1),
+   OMAP_DSS_SUPPLIES,
 };
 
 static struct regulator_consumer_supply sdp3430_vmmc1_supplies[] = {
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 2647a95..80bbf61 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -339,8 +339,7 @@ static struct regulator_consumer_supply
sdp4430_vmmc_supply[] = {
},
 };
 static struct regulator_consumer_supply sdp4430_vcxio_supply[] = {
-   REGULATOR_SUPPLY(vdds_dsi, omapdss_dss),
-   REGULATOR_SUPPLY(vdds_dsi, omapdss_dsi1),
+   OMAP_DSS_SUPPLIES,
 };
 
 static int omap4_twl6030_hsmmc_late_init(struct device *dev)
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index bb39738..557b400 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -636,4 +636,12 @@ int omap_rfbi_update(struct omap_dss_device
*dssdev,
 int omap_rfbi_configure(struct omap_dss_device *dssdev, int pixel_size,
int data_lines);
 
+#define OMAP_DSS_SUPPLIES \
+   REGULATOR_SUPPLY(vdds_sdi, omapdss_dss), \
+   REGULATOR_SUPPLY(vdds_dsi, omapdss_dss), \
+   REGULATOR_SUPPLY(vdds_dsi, omapdss_dsi1)
+
+#define OMAP_DSS_VENC_SUPPLIES \
+   REGULATOR_SUPPLY(vdda_dac, omapdss_venc)
+
 #endif


--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/9] OMAP: DSS2: Change DSI platform device name from omapdss_dsi1 to omapdss_dsi

2011-05-11 Thread Mark Brown 
On Wed, May 11, 2011 at 12:23:45PM +0300, Tomi Valkeinen wrote:

 So how should the regulator be set up?

You need to create a new regulator of some kind and then provide a way
for machines to set the supply_regulator in the init_data.

 I should setup a fixed regulator, which is supplied from VCXIO, and
 omapdss will get its powers from this fixed regulator?

Yes, and the example code I've deleted all looks about right.

 static struct fixed_voltage_config omap_dss_fixed_reg_data = {
   .supply_name = what should this be?,
   .init_data = fixed_reg_init_data,
 };

The supply name shold be supplied by the board - it's whatever the
supply that's shared by all the regulators in the OMAP is.

 static struct regulator_consumer_supply sdp4430_vcxio_supply[] = {
   REGULATOR_SUPPLY(what should this be?, reg-fixed-voltage.0),
 };

You don't need to specify a supply to hook the supplies up.  This is a
bit of a wart, but it's the current API - it's specified in the child
regulator rather than the parent which is the other way around to
consumers.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/9] OMAP: DSS2: Change DSI platform device name from omapdss_dsi1 to omapdss_dsi

2011-05-11 Thread Tomi Valkeinen 
On Tue, 2011-05-10 at 15:47 +0200, Mark Brown wrote:
 On Tue, May 10, 2011 at 03:30:52PM +0300, Tomi Valkeinen wrote:
 
  This sounds just the thing we need here. Do you think there's a chance
  the code could get merged in the next window? And I'm also happy to test
  the code with omapdss, whenever you have something ready.
 
 Patch is below, tested with my hey look, this compiles! test plan -
 I'd be a bit surprised if it ran straight off.

So how should the regulator be set up?

If we currently have in the board file:

static struct regulator_consumer_supply sdp4430_vcxio_supply[] = {
REGULATOR_SUPPLY(vdds_dsi, omapdss_dss),
REGULATOR_SUPPLY(vdds_dsi, omapdss_dsi.0),
REGULATOR_SUPPLY(vdds_dsi, omapdss_dsi.1),
};

static struct regulator_init_data sdp4430_vcxio = {
.constraints = {
...
},
.num_consumer_supplies  = ARRAY_SIZE(sdp4430_vcxio_supply),
.consumer_supplies  = sdp4430_vcxio_supply,
};

I should setup a fixed regulator, which is supplied from VCXIO, and
omapdss will get its powers from this fixed regulator?

So, in the common display file:

static struct regulator_consumer_supply fixed_supply[] = {
REGULATOR_SUPPLY(vdds_dsi, omapdss_dss),
REGULATOR_SUPPLY(vdds_dsi, omapdss_dsi.0),
REGULATOR_SUPPLY(vdds_dsi, omapdss_dsi.1),
};

static struct regulator_init_data fixed_reg_init_data = {
.constraints = {
...
},
.num_consumer_supplies  = ARRAY_SIZE(fixed_supply),
.consumer_supplies  = fixed_supply,
};

static struct fixed_voltage_config omap_dss_fixed_reg_data = {
.supply_name = what should this be?,
.init_data = fixed_reg_init_data,
};

static struct platform_device omap_dss_fixed_reg_device = {
.name   = reg-fixed-voltage,
.id = 0,
.dev= {
.platform_data  = omap_dss_fixed_reg_data,
},
};

And in the board file:

static struct regulator_consumer_supply sdp4430_vcxio_supply[] = {
REGULATOR_SUPPLY(what should this be?, reg-fixed-voltage.0),
};

static struct regulator_init_data sdp4430_vcxio = {
.constraints = {
...
},
.num_consumer_supplies  = ARRAY_SIZE(sdp4430_vcxio_supply),
.consumer_supplies  = sdp4430_vcxio_supply,
};

If so, it's again slightly difficult. I want to do the common display
stuff in a one place, used by all the boards. If I setup the fixed
regulator in the common file, I need to give it an id which may conflict
with a possible fixed regulator set up in the board file.

Or am I totally on the wrong track here =)?

 Tomi


--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/9] OMAP: DSS2: Change DSI platform device name from omapdss_dsi1 to omapdss_dsi

2011-05-10 Thread Tomi Valkeinen 
On Mon, 2011-05-09 at 21:19 +0200, Mark Brown wrote:
 On Mon, May 09, 2011 at 06:34:34PM +0300, Tomi Valkeinen wrote:

  The second thing is that even if the power source for vdds_dsi may be
  configured differently on different boards, the same vdds_dsi goes to
  multiple DSS HW blocks inside OMAP, each represented by a separate
  omap_device. So it'd be much nicer to configure just the vdds_dsi power
  in the board file, but let the omap display code configure the
  regulators properly for all the DSS HW blocks in that particular OMAP.
 
 For this I'd suggest setting up an arrangement with supplies where you
 have one thing on the OMAP is supplied by board configuration and then
 it has child supplies within the device but right now that's not so easy
 to do.  I was just writing some stuff for that this afternoon but it'll
 be next week before I can test it properly.

This sounds just the thing we need here. Do you think there's a chance
the code could get merged in the next window? And I'm also happy to test
the code with omapdss, whenever you have something ready.

I think we'll go forward with this patch set in a modified form: we'll
leave the board files untouched and add the DSS driver parts (which is
99% of the patch set) with a small hack which makes things work with the
current device setup.

This means we won't be able to use the second DSI LCD yet, but getting
the biggest bulk of code in is more important.

 Tomi


--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/9] OMAP: DSS2: Change DSI platform device name from omapdss_dsi1 to omapdss_dsi

2011-05-10 Thread Mark Brown 
On Tue, May 10, 2011 at 03:30:52PM +0300, Tomi Valkeinen wrote:

 This sounds just the thing we need here. Do you think there's a chance
 the code could get merged in the next window? And I'm also happy to test
 the code with omapdss, whenever you have something ready.

Patch is below, tested with my hey look, this compiles! test plan -
I'd be a bit surprised if it ran straight off.

From 819cc21f22b1f570f7d5d8fe981bbb03e28bdb9d Mon Sep 17 00:00:00 2001
From: Mark Brown broo...@opensource.wolfsonmicro.com
Date: Mon, 9 May 2011 13:07:41 +0200
Subject: [PATCH] regulator: Refactor supply implementation to work as regular 
consumers

Currently the regulator supply implementation is somewhat complex and
fragile as it doesn't look like standard consumers but is instead a
parallel implementation. This causes issues with locking and reference
counting.

Move the implementation over to using standard consumers to address this.
Rather than only notifying the supply on the first enable/disable we do so
every time the regulator is enabled or disabled, simplifying locking as we
don't need to hold a lock on the consumer we are about to enable.

Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com
---
 drivers/regulator/core.c |   99 +-
 include/linux/regulator/driver.h |4 +-
 2 files changed, 35 insertions(+), 68 deletions(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 58452ac..38bb499 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -81,8 +81,7 @@ struct regulator {
 };
 
 static int _regulator_is_enabled(struct regulator_dev *rdev);
-static int _regulator_disable(struct regulator_dev *rdev,
-   struct regulator_dev **supply_rdev_ptr);
+static int _regulator_disable(struct regulator_dev *rdev);
 static int _regulator_get_voltage(struct regulator_dev *rdev);
 static int _regulator_get_current_limit(struct regulator_dev *rdev);
 static unsigned int _regulator_get_mode(struct regulator_dev *rdev);
@@ -90,6 +89,9 @@ static void _notifier_call_chain(struct regulator_dev *rdev,
  unsigned long event, void *data);
 static int _regulator_do_set_voltage(struct regulator_dev *rdev,
 int min_uV, int max_uV);
+static struct regulator *create_regulator(struct regulator_dev *rdev,
+ struct device *dev,
+ const char *supply_name);
 
 static const char *rdev_get_name(struct regulator_dev *rdev)
 {
@@ -922,21 +924,18 @@ out:
  * core if it's child is enabled.
  */
 static int set_supply(struct regulator_dev *rdev,
-   struct regulator_dev *supply_rdev)
+ struct regulator_dev *supply_rdev)
 {
int err;
 
-   err = sysfs_create_link(rdev-dev.kobj, supply_rdev-dev.kobj,
-   supply);
-   if (err) {
-   rdev_err(rdev, could not add device link %s err %d\n,
-supply_rdev-dev.kobj.name, err);
-  goto out;
+   rdev-supply = create_regulator(rdev, rdev-dev, SUPPLY);
+   if (IS_ERR(rdev-supply)) {
+   err = PTR_ERR(rdev-supply);
+   rdev-supply = NULL;
+   return err;
}
-   rdev-supply = supply_rdev;
-   list_add(rdev-slist, supply_rdev-supply_list);
-out:
-   return err;
+
+   return 0;
 }
 
 /**
@@ -1294,19 +1293,6 @@ static int _regulator_enable(struct regulator_dev *rdev)
 {
int ret, delay;
 
-   if (rdev-use_count == 0) {
-   /* do we need to enable the supply regulator first */
-   if (rdev-supply) {
-   mutex_lock(rdev-supply-mutex);
-   ret = _regulator_enable(rdev-supply);
-   mutex_unlock(rdev-supply-mutex);
-   if (ret  0) {
-   rdev_err(rdev, failed to enable: %d\n, ret);
-   return ret;
-   }
-   }
-   }
-
/* check voltage and requested load before enabling */
if (rdev-constraints 
(rdev-constraints-valid_ops_mask  REGULATOR_CHANGE_DRMS))
@@ -1381,19 +1367,27 @@ int regulator_enable(struct regulator *regulator)
struct regulator_dev *rdev = regulator-rdev;
int ret = 0;
 
+   if (rdev-supply) {
+   ret = regulator_enable(rdev-supply);
+   if (ret != 0)
+   return ret;
+   }
+
mutex_lock(rdev-mutex);
ret = _regulator_enable(rdev);
mutex_unlock(rdev-mutex);
+
+   if (ret != 0)
+   regulator_disable(rdev-supply);
+
return ret;
 }
 EXPORT_SYMBOL_GPL(regulator_enable);
 
 /* locks held by regulator_disable() */
-static int _regulator_disable(struct regulator_dev *rdev,
-   struct regulator_dev **supply_rdev_ptr)
+static int

Re: [PATCH 1/9] OMAP: DSS2: Change DSI platform device name from omapdss_dsi1 to omapdss_dsi

2011-05-09 Thread Tomi Valkeinen 
On Thu, 2011-05-05 at 14:02 +0100, Mark Brown wrote:
 On Thu, May 05, 2011 at 02:36:48PM +0300, Tomi Valkeinen wrote:
 
  So currently we have REGULATOR_SUPPLY defines for each board in all the
  board files which support display. It would be much better to have an
  overrideable standard setup for the DSS powers, but this would require
  dynamically setting up the regulator_consumer_supplies. And I can't see
  how this could be done, except dynamically creating the
  regulator_consumer_supply array before initializing the TWL chip, but as
  DSS is not the only user of those powers the end result could be quite a
  mess with changes needed in every board file.
 
 I'm not sure I see a problem that needs solving here?  This wiring is
 all totally system specific.  Once we have viable device tree for
 relevant platforms I'd expect to see these things mapped in the device
 tree for the system with a standard regulator API device tree mapping.

I think there are two things here:

The first is that we want to avoid unnecessary board file changes, and
as almost all boards configure the DSS powers the same way, it'd be nice
to have a default config for these.

The second thing is that even if the power source for vdds_dsi may be
configured differently on different boards, the same vdds_dsi goes to
multiple DSS HW blocks inside OMAP, each represented by a separate
omap_device. So it'd be much nicer to configure just the vdds_dsi power
in the board file, but let the omap display code configure the
regulators properly for all the DSS HW blocks in that particular OMAP.

I'm not familiar with the capabilities of the device tree, so it may
solve these neatly (at least from kernel's perspective). I guess Tony
just wants to try to minimize arch/arm changes wherever possible due to
the recent arch/arm dispute.

 Tomi


--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/9] OMAP: DSS2: Change DSI platform device name from omapdss_dsi1 to omapdss_dsi

2011-05-09 Thread Mark Brown 
On Mon, May 09, 2011 at 06:34:34PM +0300, Tomi Valkeinen wrote:

 The first is that we want to avoid unnecessary board file changes, and
 as almost all boards configure the DSS powers the same way, it'd be nice
 to have a default config for these.

Right, makes sense.

 The second thing is that even if the power source for vdds_dsi may be
 configured differently on different boards, the same vdds_dsi goes to
 multiple DSS HW blocks inside OMAP, each represented by a separate
 omap_device. So it'd be much nicer to configure just the vdds_dsi power
 in the board file, but let the omap display code configure the
 regulators properly for all the DSS HW blocks in that particular OMAP.

For this I'd suggest setting up an arrangement with supplies where you
have one thing on the OMAP is supplied by board configuration and then
it has child supplies within the device but right now that's not so easy
to do.  I was just writing some stuff for that this afternoon but it'll
be next week before I can test it properly.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/9] OMAP: DSS2: Change DSI platform device name from omapdss_dsi1 to omapdss_dsi

2011-05-05 Thread Tomi Valkeinen 
On Thu, 2011-05-05 at 04:50 -0700, Tony Lindgren wrote:
 * Tomi Valkeinen tomi.valkei...@ti.com [110505 04:33]:
  On Wed, 2011-05-04 at 12:40 +0300, Tony Lindgren wrote:
   
   Looks like we should first combine all this cut and paste data
   for each board file into some common init function to cut
   down the crazy churn.
  
  Sorry, I don't see how this would be possible with the regulator
  framework. What we would need is to setup some
  regulator_consumer_supplies dynamically depending on the omap and on the
  given parameters.
  
  Adding Liam and Mark for possible comments. A short summary of the
  situation:
  
  OMAP display subsystem (DSS) HW needs a few power supplies (vdds_dsi,
  vdds_sdi, vdda_dac), depending on the OMAP version. All the known boards
  have the standard TWL power chip which provides these powers, and they
  are connected almost always the same way. However, there's no reason
  that the powers for DSS couldn't be provided from some other source.
  
  As an example, on OMAP3 we could have:
  (regulator - name - driver)
  VDDA_DAC - vdda_dac - omapdss_venc
  VPLL2 - vdds_dsi - omapdss
  VPLL2 - vdds_dsi - omapdss_dsi
  
  So currently we have REGULATOR_SUPPLY defines for each board in all the
  board files which support display. It would be much better to have an
  overrideable standard setup for the DSS powers, but this would require
  dynamically setting up the regulator_consumer_supplies. And I can't see
  how this could be done, except dynamically creating the
  regulator_consumer_supply array before initializing the TWL chip, but as
  DSS is not the only user of those powers the end result could be quite a
  mess with changes needed in every board file.
 
 What if you just do all common DSS REGULATOR_SUPPLY entries in the common
 platform init code for DSS? Then just set the regulator_init_data pointers
 based on the desired configuration.
 
 Or maybe I misunderstood your problem..

The problem with that approach is that there could be other users for
the same regulator, so the consumer_supplies list could also need to
contain some other entries than dss.

Then again, I guess those cases are minority, so we would still get
majority of the board files cleaned up.

Thanks for the idea, I'll try this approach.

 Tomi


--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/9] OMAP: DSS2: Change DSI platform device name from omapdss_dsi1 to omapdss_dsi

2011-05-05 Thread Mark Brown 
On Thu, May 05, 2011 at 02:36:48PM +0300, Tomi Valkeinen wrote:

 So currently we have REGULATOR_SUPPLY defines for each board in all the
 board files which support display. It would be much better to have an
 overrideable standard setup for the DSS powers, but this would require
 dynamically setting up the regulator_consumer_supplies. And I can't see
 how this could be done, except dynamically creating the
 regulator_consumer_supply array before initializing the TWL chip, but as
 DSS is not the only user of those powers the end result could be quite a
 mess with changes needed in every board file.

I'm not sure I see a problem that needs solving here?  This wiring is
all totally system specific.  Once we have viable device tree for
relevant platforms I'd expect to see these things mapped in the device
tree for the system with a standard regulator API device tree mapping.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/9] OMAP: DSS2: Change DSI platform device name from omapdss_dsi1 to omapdss_dsi

2011-05-05 Thread Tomi Valkeinen 
On Thu, 2011-05-05 at 04:50 -0700, Tony Lindgren wrote:
 * Tomi Valkeinen tomi.valkei...@ti.com [110505 04:33]:
  On Wed, 2011-05-04 at 12:40 +0300, Tony Lindgren wrote:
   
   Looks like we should first combine all this cut and paste data
   for each board file into some common init function to cut
   down the crazy churn.
  
  Sorry, I don't see how this would be possible with the regulator
  framework. What we would need is to setup some
  regulator_consumer_supplies dynamically depending on the omap and on the
  given parameters.
  
  Adding Liam and Mark for possible comments. A short summary of the
  situation:
  
  OMAP display subsystem (DSS) HW needs a few power supplies (vdds_dsi,
  vdds_sdi, vdda_dac), depending on the OMAP version. All the known boards
  have the standard TWL power chip which provides these powers, and they
  are connected almost always the same way. However, there's no reason
  that the powers for DSS couldn't be provided from some other source.
  
  As an example, on OMAP3 we could have:
  (regulator - name - driver)
  VDDA_DAC - vdda_dac - omapdss_venc
  VPLL2 - vdds_dsi - omapdss
  VPLL2 - vdds_dsi - omapdss_dsi
  
  So currently we have REGULATOR_SUPPLY defines for each board in all the
  board files which support display. It would be much better to have an
  overrideable standard setup for the DSS powers, but this would require
  dynamically setting up the regulator_consumer_supplies. And I can't see
  how this could be done, except dynamically creating the
  regulator_consumer_supply array before initializing the TWL chip, but as
  DSS is not the only user of those powers the end result could be quite a
  mess with changes needed in every board file.
 
 What if you just do all common DSS REGULATOR_SUPPLY entries in the common
 platform init code for DSS? Then just set the regulator_init_data pointers
 based on the desired configuration.
 
 Or maybe I misunderstood your problem..

I made a test patch for this (below), but after looking at OMAP3 and 4
TRMs, I don't think this is going to be very good solution. It looks
like on OMAP3 the VPLL2 is used (at least) for DSI and CSI. On OMAP4
VCXIO is used for vdda_dpll_mpu, vdda_dpll_core_audio,
vdda_dpll_iva_per, vdda_dsi[1:2], vdda_csi2[1:2], vdda_usba0otg_1p8v.

VPLL2 and VCXIO do not look like to be dedicated for DSS, so I'm
guessing it's more than normal to have more users for the regulators
than just DSS (but they just aren't implemented currently).

Another option that came to my mind is defining simple macros like:

#define OMAP_DSS_REG_SUPPLY_DSS REGULATOR_SUPPLY(vdds_dsi, omapdss)
#define OMAP_DSS_REG_SUPPLY_DSI1 REGULATOR_SUPPLY(vdds_dsi, omapdss_dsi1)

And then use them instead:

static struct regulator_consumer_supply sdp3430_vpll2_supplies[] = {
OMAP_DSS_REG_SUPPLY_DSS,
OMAP_DSS_REG_SUPPLY_DSI1,
};

But that is quite minor improvement, and I'm not even sure if it's an
improvement...

 Tomi


diff --git a/arch/arm/mach-omap2/board-3430sdp.c 
b/arch/arm/mach-omap2/board-3430sdp.c
index 9afd087..dedc150 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -394,16 +394,6 @@ static struct regulator_consumer_supply 
sdp3430_vaux3_supplies[] = {
REGULATOR_SUPPLY(vcc, spi1.0),
 };
 
-static struct regulator_consumer_supply sdp3430_vdda_dac_supplies[] = {
-   REGULATOR_SUPPLY(vdda_dac, omapdss_venc),
-};
-
-/* VPLL2 for digital video outputs */
-static struct regulator_consumer_supply sdp3430_vpll2_supplies[] = {
-   REGULATOR_SUPPLY(vdds_dsi, omapdss),
-   REGULATOR_SUPPLY(vdds_dsi, omapdss_dsi1),
-};
-
 static struct regulator_consumer_supply sdp3430_vmmc1_supplies[] = {
REGULATOR_SUPPLY(vmmc, omap_hsmmc.0),
 };
@@ -531,8 +521,8 @@ static struct regulator_init_data sdp3430_vdac = {
.valid_ops_mask = REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
},
-   .num_consumer_supplies  = ARRAY_SIZE(sdp3430_vdda_dac_supplies),
-   .consumer_supplies  = sdp3430_vdda_dac_supplies,
+   .num_consumer_supplies  = ARRAY_SIZE(omap_std_vdda_dac_supplies),
+   .consumer_supplies  = omap_std_vdda_dac_supplies,
 };
 
 static struct regulator_init_data sdp3430_vpll2 = {
@@ -546,8 +536,8 @@ static struct regulator_init_data sdp3430_vpll2 = {
.valid_ops_mask = REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
},
-   .num_consumer_supplies  = ARRAY_SIZE(sdp3430_vpll2_supplies),
-   .consumer_supplies  = sdp3430_vpll2_supplies,
+   .num_consumer_supplies  = ARRAY_SIZE(omap_std_vdds_dsi_supplies),
+   .consumer_supplies  = omap_std_vdds_dsi_supplies,
 };
 
 static struct twl4030_codec_audio_data sdp3430_audio;
diff --git a/arch/arm/mach-omap2/board-4430sdp.c 
b/arch/arm/mach-omap2/board-4430sdp.c
index 570e83f..bef42bb 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++

[PATCH 1/9] OMAP: DSS2: Change DSI platform device name from omapdss_dsi1 to omapdss_dsi

2011-05-04 Thread Archit Taneja 
Currently, there are 2 differently named platform devices generated for the 2
DSS DSI modules. In order to use the same driver, the dsi devices should be 2
instances of the same platform device.

Change the platform device name from omapdss_dsi1 to omapdss_dsi. Propagate
this change across all omap board files which need to use this new name. Don't
create a DSI2 platform device instance for now.

Signed-off-by: Archit Taneja arc...@ti.com
---
 arch/arm/mach-omap2/board-3430sdp.c  |2 +-
 arch/arm/mach-omap2/board-4430sdp.c  |2 +-
 arch/arm/mach-omap2/board-devkit8000.c   |2 +-
 arch/arm/mach-omap2/board-igep0020.c |2 +-
 arch/arm/mach-omap2/board-omap3beagle.c  |2 +-
 arch/arm/mach-omap2/board-omap3evm.c |2 +-
 arch/arm/mach-omap2/board-omap3pandora.c |2 +-
 arch/arm/mach-omap2/board-omap3stalker.c |2 +-
 arch/arm/mach-omap2/board-overo.c|2 +-
 arch/arm/mach-omap2/board-zoom-peripherals.c |2 +-
 arch/arm/mach-omap2/display.c|5 ++---
 drivers/video/omap2/dss/dsi.c|   18 +-
 12 files changed, 21 insertions(+), 22 deletions(-)

diff --git a/arch/arm/mach-omap2/board-3430sdp.c 
b/arch/arm/mach-omap2/board-3430sdp.c
index 9afd087..9da362b 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -401,7 +401,7 @@ static struct regulator_consumer_supply 
sdp3430_vdda_dac_supplies[] = {
 /* VPLL2 for digital video outputs */
 static struct regulator_consumer_supply sdp3430_vpll2_supplies[] = {
REGULATOR_SUPPLY(vdds_dsi, omapdss),
-   REGULATOR_SUPPLY(vdds_dsi, omapdss_dsi1),
+   REGULATOR_SUPPLY(vdds_dsi, omapdss_dsi.0),
 };
 
 static struct regulator_consumer_supply sdp3430_vmmc1_supplies[] = {
diff --git a/arch/arm/mach-omap2/board-4430sdp.c 
b/arch/arm/mach-omap2/board-4430sdp.c
index 570e83f..eafadb4 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -375,7 +375,7 @@ static struct regulator_consumer_supply 
sdp4430_vmmc_supply[] = {
 };
 static struct regulator_consumer_supply sdp4430_vcxio_supply[] = {
REGULATOR_SUPPLY(vdds_dsi, omapdss_dss),
-   REGULATOR_SUPPLY(vdds_dsi, omapdss_dsi1),
+   REGULATOR_SUPPLY(vdds_dsi, omapdss_dsi.0),
 };
 
 static int omap4_twl6030_hsmmc_late_init(struct device *dev)
diff --git a/arch/arm/mach-omap2/board-devkit8000.c 
b/arch/arm/mach-omap2/board-devkit8000.c
index 65f9fde..81f9c64 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -279,7 +279,7 @@ static struct twl4030_gpio_platform_data 
devkit8000_gpio_data = {
 
 static struct regulator_consumer_supply devkit8000_vpll1_supplies[] = {
REGULATOR_SUPPLY(vdds_dsi, omapdss),
-   REGULATOR_SUPPLY(vdds_dsi, omapdss_dsi1),
+   REGULATOR_SUPPLY(vdds_dsi, omapdss_dsi.0),
 };
 
 /* VMMC1 for MMC1 pins CMD, CLK, DAT0..DAT3 (20 mA, plus card == max 220 mA) */
diff --git a/arch/arm/mach-omap2/board-igep0020.c 
b/arch/arm/mach-omap2/board-igep0020.c
index 34cf982..279a553 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -487,7 +487,7 @@ static struct omap_dss_board_info igep2_dss_data = {
 
 static struct regulator_consumer_supply igep2_vpll2_supplies[] = {
REGULATOR_SUPPLY(vdds_dsi, omapdss),
-   REGULATOR_SUPPLY(vdds_dsi, omapdss_dsi1),
+   REGULATOR_SUPPLY(vdds_dsi, omapdss_dsi.0),
 };
 
 static struct regulator_init_data igep2_vpll2 = {
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c 
b/arch/arm/mach-omap2/board-omap3beagle.c
index 33007fd..8197d0d 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -236,7 +236,7 @@ static struct regulator_consumer_supply beagle_vdac_supply =
 
 static struct regulator_consumer_supply beagle_vdvi_supplies[] = {
REGULATOR_SUPPLY(vdds_dsi, omapdss),
-   REGULATOR_SUPPLY(vdds_dsi, omapdss_dsi1),
+   REGULATOR_SUPPLY(vdds_dsi, omapdss_dsi.0),
 };
 
 static void __init beagle_display_init(void)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c 
b/arch/arm/mach-omap2/board-omap3evm.c
index 5a1a916..e5b74f8 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -562,7 +562,7 @@ static struct regulator_init_data omap3_evm_vdac = {
 /* VPLL2 for digital video outputs */
 static struct regulator_consumer_supply omap3_evm_vpll2_supplies[] = {
REGULATOR_SUPPLY(vdds_dsi, omapdss),
-   REGULATOR_SUPPLY(vdds_dsi, omapdss_dsi1),
+   REGULATOR_SUPPLY(vdds_dsi, omapdss_dsi.0),
 };
 
 static struct regulator_init_data omap3_evm_vpll2 = {
diff --git a/arch/arm/mach-omap2/board-omap3pandora.c 
b/arch/arm/mach-omap2/board-omap3pandora.c
index 07dba88..3554892 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -347,7 +347,7 @@ static struct

Re: [PATCH 1/9] OMAP: DSS2: Change DSI platform device name from omapdss_dsi1 to omapdss_dsi

2011-05-04 Thread Tony Lindgren 
* Archit Taneja arc...@ti.com [110504 10:30]:
 --- a/arch/arm/mach-omap2/board-3430sdp.c
 +++ b/arch/arm/mach-omap2/board-3430sdp.c
 @@ -401,7 +401,7 @@ static struct regulator_consumer_supply 
 sdp3430_vdda_dac_supplies[] = {
  /* VPLL2 for digital video outputs */
  static struct regulator_consumer_supply sdp3430_vpll2_supplies[] = {
   REGULATOR_SUPPLY(vdds_dsi, omapdss),
 - REGULATOR_SUPPLY(vdds_dsi, omapdss_dsi1),
 + REGULATOR_SUPPLY(vdds_dsi, omapdss_dsi.0),
  };
  
  static struct regulator_consumer_supply sdp3430_vmmc1_supplies[] = {
 diff --git a/arch/arm/mach-omap2/board-4430sdp.c 
 b/arch/arm/mach-omap2/board-4430sdp.c
 index 570e83f..eafadb4 100644
 --- a/arch/arm/mach-omap2/board-4430sdp.c
 +++ b/arch/arm/mach-omap2/board-4430sdp.c
 @@ -375,7 +375,7 @@ static struct regulator_consumer_supply 
 sdp4430_vmmc_supply[] = {
  };
  static struct regulator_consumer_supply sdp4430_vcxio_supply[] = {
   REGULATOR_SUPPLY(vdds_dsi, omapdss_dss),
 - REGULATOR_SUPPLY(vdds_dsi, omapdss_dsi1),
 + REGULATOR_SUPPLY(vdds_dsi, omapdss_dsi.0),
  };
...

Looks like we should first combine all this cut and paste data
for each board file into some common init function to cut
down the crazy churn.

Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/9] OMAP: DSS2: Change DSI platform device name from omapdss_dsi1 to omapdss_dsi

2011-05-04 Thread Tomi Valkeinen 
On Wed, 2011-05-04 at 12:40 +0300, Tony Lindgren wrote:
 * Archit Taneja arc...@ti.com [110504 10:30]:
  --- a/arch/arm/mach-omap2/board-3430sdp.c
  +++ b/arch/arm/mach-omap2/board-3430sdp.c
  @@ -401,7 +401,7 @@ static struct regulator_consumer_supply 
  sdp3430_vdda_dac_supplies[] = {
   /* VPLL2 for digital video outputs */
   static struct regulator_consumer_supply sdp3430_vpll2_supplies[] = {
  REGULATOR_SUPPLY(vdds_dsi, omapdss),
  -   REGULATOR_SUPPLY(vdds_dsi, omapdss_dsi1),
  +   REGULATOR_SUPPLY(vdds_dsi, omapdss_dsi.0),
   };
   
   static struct regulator_consumer_supply sdp3430_vmmc1_supplies[] = {
  diff --git a/arch/arm/mach-omap2/board-4430sdp.c 
  b/arch/arm/mach-omap2/board-4430sdp.c
  index 570e83f..eafadb4 100644
  --- a/arch/arm/mach-omap2/board-4430sdp.c
  +++ b/arch/arm/mach-omap2/board-4430sdp.c
  @@ -375,7 +375,7 @@ static struct regulator_consumer_supply 
  sdp4430_vmmc_supply[] = {
   };
   static struct regulator_consumer_supply sdp4430_vcxio_supply[] = {
  REGULATOR_SUPPLY(vdds_dsi, omapdss_dss),
  -   REGULATOR_SUPPLY(vdds_dsi, omapdss_dsi1),
  +   REGULATOR_SUPPLY(vdds_dsi, omapdss_dsi.0),
   };
 ...
 
 Looks like we should first combine all this cut and paste data
 for each board file into some common init function to cut
 down the crazy churn.

I was actually thinking about this earlier today.

All the boards I have seen use vdds_dsi the same way (depending on the
omap version, though). For OMAP3 it comes from VPPL2 and for OMAP4 it's
VCXIO. Optimally a common piece of code would just set up the regulator
properly.

But I think in the end the config has to come from the board data, as I
don't see that the above config would be the only possibility. The
vdds_dsi could be supplied from anywhere (with suitable voltage, of
course), as far as I understand.

What we could do is:

1. The board file tells the common display code which regulator is used
for vdds_dsi, and the common code can setup the regulator supply for all
DSS devices which need it (omapdss_dss, omapdss_dsi1, omapdss_dsi2).

I guess this needs dynamically adding the regulator supply in display.c,
and I'm not quite sure if that's possible. We have to look at this.

2. The common code could default to the power source that is most
commonly used, so the board file would have to config the regulator only
if it uses a non-common one.

Together 1. and 2. would remove the DSS regulator stuff totally from the
board files. But regulators for the panels would still be in the board
files, of course.

 Tomi


--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/9] OMAP: DSS2: Change DSI platform device name from omapdss_dsi1 to omapdss_dsi

2011-05-04 Thread Tony Lindgren 
* Tomi Valkeinen tomi.valkei...@ti.com [110504 03:50]:
 On Wed, 2011-05-04 at 12:40 +0300, Tony Lindgren wrote:
  * Archit Taneja arc...@ti.com [110504 10:30]:
   --- a/arch/arm/mach-omap2/board-3430sdp.c
   +++ b/arch/arm/mach-omap2/board-3430sdp.c
   @@ -401,7 +401,7 @@ static struct regulator_consumer_supply 
   sdp3430_vdda_dac_supplies[] = {
/* VPLL2 for digital video outputs */
static struct regulator_consumer_supply sdp3430_vpll2_supplies[] = {
 REGULATOR_SUPPLY(vdds_dsi, omapdss),
   - REGULATOR_SUPPLY(vdds_dsi, omapdss_dsi1),
   + REGULATOR_SUPPLY(vdds_dsi, omapdss_dsi.0),
};

static struct regulator_consumer_supply sdp3430_vmmc1_supplies[] = {
   diff --git a/arch/arm/mach-omap2/board-4430sdp.c 
   b/arch/arm/mach-omap2/board-4430sdp.c
   index 570e83f..eafadb4 100644
   --- a/arch/arm/mach-omap2/board-4430sdp.c
   +++ b/arch/arm/mach-omap2/board-4430sdp.c
   @@ -375,7 +375,7 @@ static struct regulator_consumer_supply 
   sdp4430_vmmc_supply[] = {
};
static struct regulator_consumer_supply sdp4430_vcxio_supply[] = {
 REGULATOR_SUPPLY(vdds_dsi, omapdss_dss),
   - REGULATOR_SUPPLY(vdds_dsi, omapdss_dsi1),
   + REGULATOR_SUPPLY(vdds_dsi, omapdss_dsi.0),
};
  ...
  
  Looks like we should first combine all this cut and paste data
  for each board file into some common init function to cut
  down the crazy churn.
 
 I was actually thinking about this earlier today.
 
 All the boards I have seen use vdds_dsi the same way (depending on the
 omap version, though). For OMAP3 it comes from VPPL2 and for OMAP4 it's
 VCXIO. Optimally a common piece of code would just set up the regulator
 properly.
 
 But I think in the end the config has to come from the board data, as I
 don't see that the above config would be the only possibility. The
 vdds_dsi could be supplied from anywhere (with suitable voltage, of
 course), as far as I understand.
 
 What we could do is:
 
 1. The board file tells the common display code which regulator is used
 for vdds_dsi, and the common code can setup the regulator supply for all
 DSS devices which need it (omapdss_dss, omapdss_dsi1, omapdss_dsi2).
 
 I guess this needs dynamically adding the regulator supply in display.c,
 and I'm not quite sure if that's possible. We have to look at this.
 
 2. The common code could default to the power source that is most
 commonly used, so the board file would have to config the regulator only
 if it uses a non-common one.
 
 Together 1. and 2. would remove the DSS regulator stuff totally from the
 board files. But regulators for the panels would still be in the board
 files, of course.

Sounds doable. And you could still allow overriding it if the typical
configuration does not work.

Regards,

Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html