Re: [PATCH 6/8] RX-51: Audio: Add usage of regulator framework to control VMMC2

2009-10-19 Thread Eduardo Valentin
Hi,

On Mon, Oct 12, 2009 at 11:21:04AM +0200, Mark Brown wrote:
 On Mon, Oct 12, 2009 at 12:04:55PM +0300, Eduardo Valentin wrote:
 
  Right. Should we add 4 instances of drvdd and 2 of iovdd? So, naming those 
  would be like:
 
 No, if there's multiple pins for the supply then there's no need to
 represent those individually - they're required to be wired together in
 hardware.

Might be a stupid question probably because of my lack of knowledge of 
regulator framework,
but if the driver code must be written in such a way that it requires all 
regulators
for its supplies, then what happens with those which are grounded? How do you 
provide the
regulator_init_data in this case (where the supply is actually grounded) ?

BR,

-- 
Eduardo Valentin
--
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 6/8] RX-51: Audio: Add usage of regulator framework to control VMMC2

2009-10-19 Thread Mark Brown
On Mon, Oct 19, 2009 at 12:13:00PM +0300, Eduardo Valentin wrote:

[Please fix your MUA to wrap before 80 columns.]

 Might be a stupid question probably because of my lack of knowledge of
 regulator framework, but if the driver code must be written in such a
 way that it requires all regulators for its supplies, then what
 happens with those which are grounded? How do you provide the
 regulator_init_data in this case (where the supply is actually grounded) ?

That sounds like a fixed voltage regulator.  Though for a device where
some of the supplies are optional if the driver needs to know about it
it may make more sense to have the driver know about that and only
request supplies which it will use.
--
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 6/8] RX-51: Audio: Add usage of regulator framework to control VMMC2

2009-10-19 Thread Mark Brown
On Mon, Oct 19, 2009 at 10:23:32AM +0100, Mark Brown wrote:
 On Mon, Oct 19, 2009 at 12:13:00PM +0300, Eduardo Valentin wrote:

  Might be a stupid question probably because of my lack of knowledge of
  regulator framework, but if the driver code must be written in such a
  way that it requires all regulators for its supplies, then what
  happens with those which are grounded? How do you provide the
  regulator_init_data in this case (where the supply is actually grounded) ?

 That sounds like a fixed voltage regulator.  Though for a device where
 some of the supplies are optional if the driver needs to know about it
 it may make more sense to have the driver know about that and only
 request supplies which it will use.

...or possibly just handle the error when it fails to obtain them.
--
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 6/8] RX-51: Audio: Add usage of regulator framework to control VMMC2

2009-10-12 Thread Eduardo Valentin
On Thu, Oct 08, 2009 at 03:26:19PM +0200, Mark Brown wrote:
 On Thu, Oct 08, 2009 at 02:58:55PM +0300, Eduardo Valentin wrote:
 
  +static struct regulator_consumer_supply rx51_vmmc2_supplies[] = {
  +   REGULATOR_SUPPLY(avdd_dac, 2-0018), /* tlv320aic3x */
  +   REGULATOR_SUPPLY(vdd, 2-0060), /* tpa6130a2*/
   };
 
 avdd_dac is the only supply added for the tlv320aic3x but, for example,
 the tlv320aic34 has something like 8 supplies from a quick scan of the
 datasheet.  It'd be better to set up all of the supplies, even if only
 with a fixed voltage regulator supplying them, since when regulator
 support is added to the CODEC driver it should be requesting all the
 supplies it needs and therefore fail to instatiate if some are missing.

Right. Should we add 4 instances of drvdd and 2 of iovdd? So, naming those 
would be like:

REGULATOR_SUPPLY(drvdd0, 2-0018), /* tlv320aic3x */
REGULATOR_SUPPLY(drvdd1, 2-0018), /* tlv320aic3x */
REGULATOR_SUPPLY(drvdd2, 2-0018), /* tlv320aic3x */
REGULATOR_SUPPLY(drvdd3, 2-0018), /* tlv320aic3x */

or even better:

REGULATOR_SUPPLY(drvdd_b4, 2-0018), /* tlv320aic3x */
REGULATOR_SUPPLY(drvdd_a4, 2-0018), /* tlv320aic3x */
REGULATOR_SUPPLY(drvdd_b9, 2-0018), /* tlv320aic3x */
REGULATOR_SUPPLY(drvdd_a9, 2-0018), /* tlv320aic3x */

what do you think?

BR

-- 
Eduardo Valentin
--
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 6/8] RX-51: Audio: Add usage of regulator framework to control VMMC2

2009-10-12 Thread Mark Brown
On Mon, Oct 12, 2009 at 12:04:55PM +0300, Eduardo Valentin wrote:

 Right. Should we add 4 instances of drvdd and 2 of iovdd? So, naming those 
 would be like:

No, if there's multiple pins for the supply then there's no need to
represent those individually - they're required to be wired together in
hardware.
--
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


[PATCH 6/8] RX-51: Audio: Add usage of regulator framework to control VMMC2

2009-10-08 Thread Eduardo Valentin
From: Eduardo Valentin eduardo.valen...@nokia.com

This patch adds two supplies for VMMC2 on rx51 boards.

Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
 arch/arm/mach-omap2/board-rx51-peripherals.c |   14 +++---
 1 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c 
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 92f7dfa..9177b1c 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -129,8 +129,9 @@ static struct regulator_consumer_supply rx51_vaux3_supply = 
{
.supply = vmmc,
 };
 
-static struct regulator_consumer_supply rx51_vmmc2_supply = {
-   .supply = vmmc,
+static struct regulator_consumer_supply rx51_vmmc2_supplies[] = {
+   REGULATOR_SUPPLY(avdd_dac, 2-0018), /* tlv320aic3x */
+   REGULATOR_SUPPLY(vdd, 2-0060), /* tpa6130a2*/
 };
 
 static struct regulator_consumer_supply rx51_vsim_supply = {
@@ -230,8 +231,8 @@ static struct regulator_init_data rx51_vmmc2 = {
| REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
},
-   .num_consumer_supplies  = 1,
-   .consumer_supplies  = rx51_vmmc2_supply,
+   .num_consumer_supplies  = ARRAY_SIZE(rx51_vmmc2_supplies),
+   .consumer_supplies  = rx51_vmmc2_supplies,
 };
 
 static struct regulator_init_data rx51_vsim = {
@@ -442,10 +443,9 @@ static int __init rx51_i2c_init(void)
if ((system_rev = SYSTEM_REV_S_USES_VAUX3  system_rev  0x100) ||
system_rev = SYSTEM_REV_B_USES_VAUX3)
rx51_twldata.vaux3 = rx51_vaux3_mmc;
-   else {
+   else
rx51_twldata.vaux3 = rx51_vaux3_cam;
-   rx51_twldata.vmmc2 = rx51_vmmc2;
-   }
+   rx51_twldata.vmmc2 = rx51_vmmc2;
omap_register_i2c_bus(1, 2600, rx51_peripherals_i2c_board_info_1,
ARRAY_SIZE(rx51_peripherals_i2c_board_info_1));
omap_register_i2c_bus(2, 100, NULL, 0);
-- 
1.6.4.183.g04423

--
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 6/8] RX-51: Audio: Add usage of regulator framework to control VMMC2

2009-10-08 Thread Mark Brown
On Thu, Oct 08, 2009 at 02:58:55PM +0300, Eduardo Valentin wrote:

 +static struct regulator_consumer_supply rx51_vmmc2_supplies[] = {
 + REGULATOR_SUPPLY(avdd_dac, 2-0018), /* tlv320aic3x */
 + REGULATOR_SUPPLY(vdd, 2-0060), /* tpa6130a2*/
  };

avdd_dac is the only supply added for the tlv320aic3x but, for example,
the tlv320aic34 has something like 8 supplies from a quick scan of the
datasheet.  It'd be better to set up all of the supplies, even if only
with a fixed voltage regulator supplying them, since when regulator
support is added to the CODEC driver it should be requesting all the
supplies it needs and therefore fail to instatiate if some are missing.
--
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