Re: [alsa-devel] [PATCH 5/8] board-rx51-peripherals: split vaux3 and vmmc2 supplies
* Mark Brown broo...@opensource.wolfsonmicro.com [091015 02:01]: On Wed, Oct 14, 2009 at 10:15:48AM -0700, Tony Lindgren wrote: * Mark Brown broo...@opensource.wolfsonmicro.com [091012 02:18]: On Mon, Oct 12, 2009 at 11:08:58AM +0300, Eduardo Valentin wrote: I'm afraid using dev_name is not that easy. The mmc driver generates device name at runtime. That's why this board file setups .dev at runtime as well. ... So, changing this supply to something static using .dev_name it is not possible with current code. That would need refactoring the whole mmc and hsmmc setup. And the device naming procedure is dependent on cpu as well. Check arch/arm/mach-omap2/device.c:omap2_init_mmc. same answer each time it's run? How does this work with the clock API? The clocks are matched using clkdev. Basically the driver just requests functional clock (fck) and interface clock (ick): $ grep mmci arch/arm/*omap*/clock*.c arch/arm/mach-omap1/clock.c:CLK(mmci-omap.0, fck, mmc1_ck, CK_16XX | CK_1510 | CK_310), arch/arm/mach-omap1/clock.c:CLK(mmci-omap.0, ick, armper_ck.clk, CK_16XX | CK_1510 | CK_310), So this is using the standard dev_name based clkdev matching which Eduardo said was impossible for the regulators. Is it just that this will actually work fine for the regulators or is there some other magic in the OMAP code that joins things up? Well the mmc regulators are just passed from board-*.c files to mmc-twl4030.c which does all the low-level init needed. No other special magic going on. Eduardro, care to check the dev_name issue one more time? 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: [alsa-devel] [PATCH 5/8] board-rx51-peripherals: split vaux3 and vmmc2 supplies
On Wed, Oct 14, 2009 at 10:15:48AM -0700, Tony Lindgren wrote: * Mark Brown broo...@opensource.wolfsonmicro.com [091012 02:18]: On Mon, Oct 12, 2009 at 11:08:58AM +0300, Eduardo Valentin wrote: I'm afraid using dev_name is not that easy. The mmc driver generates device name at runtime. That's why this board file setups .dev at runtime as well. ... So, changing this supply to something static using .dev_name it is not possible with current code. That would need refactoring the whole mmc and hsmmc setup. And the device naming procedure is dependent on cpu as well. Check arch/arm/mach-omap2/device.c:omap2_init_mmc. same answer each time it's run? How does this work with the clock API? The clocks are matched using clkdev. Basically the driver just requests functional clock (fck) and interface clock (ick): $ grep mmci arch/arm/*omap*/clock*.c arch/arm/mach-omap1/clock.c: CLK(mmci-omap.0, fck, mmc1_ck, CK_16XX | CK_1510 | CK_310), arch/arm/mach-omap1/clock.c: CLK(mmci-omap.0, ick, armper_ck.clk, CK_16XX | CK_1510 | CK_310), So this is using the standard dev_name based clkdev matching which Eduardo said was impossible for the regulators. Is it just that this will actually work fine for the regulators or is there some other magic in the OMAP code that joins things up? -- 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: [alsa-devel] [PATCH 5/8] board-rx51-peripherals: split vaux3 and vmmc2 supplies
* Mark Brown broo...@opensource.wolfsonmicro.com [091012 02:18]: On Mon, Oct 12, 2009 at 11:08:58AM +0300, Eduardo Valentin wrote: I'm afraid using dev_name is not that easy. The mmc driver generates device name at runtime. That's why this board file setups .dev at runtime as well. rx51_twlgpio_setup - twl4030_mmc_init - omap2_init_mmc So, changing this supply to something static using .dev_name it is not possible with current code. That would need refactoring the whole mmc and hsmmc setup. And the device naming procedure is dependent on cpu as well. Check arch/arm/mach-omap2/device.c:omap2_init_mmc. Oh, dear - that sounds broken for hardware that's fixed on the board. That said, the code there looks like it's supposed to come out with the same answer each time it's run? How does this work with the clock API? The clocks are matched using clkdev. Basically the driver just requests functional clock (fck) and interface clock (ick): $ grep mmci arch/arm/*omap*/clock*.c arch/arm/mach-omap1/clock.c:CLK(mmci-omap.0, fck, mmc1_ck, CK_16XX | CK_1510 | CK_310), arch/arm/mach-omap1/clock.c:CLK(mmci-omap.0, ick, armper_ck.clk, CK_16XX | CK_1510 | CK_310), arch/arm/mach-omap1/clock.c:CLK(mmci-omap.1, fck, mmc2_ck, CK_16XX), arch/arm/mach-omap1/clock.c:CLK(mmci-omap.1, ick, armper_ck.clk, CK_16XX), arch/arm/mach-omap2/clock24xx.c:CLK(mmci-omap.0, ick, mmc_ick, CK_242X), arch/arm/mach-omap2/clock24xx.c:CLK(mmci-omap.0, fck, mmc_fck, CK_242X), arch/arm/mach-omap2/clock24xx.c:CLK(mmci-omap-hs.0, ick, mmchs1_ick,CK_243X), arch/arm/mach-omap2/clock24xx.c:CLK(mmci-omap-hs.0, fck, mmchs1_fck,CK_243X), arch/arm/mach-omap2/clock24xx.c:CLK(mmci-omap-hs.1, ick, mmchs2_ick,CK_243X), arch/arm/mach-omap2/clock24xx.c:CLK(mmci-omap-hs.1, fck, mmchs2_fck,CK_243X), arch/arm/mach-omap2/clock24xx.c:CLK(mmci-omap-hs.0, mmchsdb_fck, mmchsdb1_fck, CK_243X), arch/arm/mach-omap2/clock24xx.c:CLK(mmci-omap-hs.1, mmchsdb_fck, mmchsdb2_fck, CK_243X), arch/arm/mach-omap2/clock34xx.c:CLK(mmci-omap-hs.2, fck, mmchs3_fck,CK_3430ES2), arch/arm/mach-omap2/clock34xx.c:CLK(mmci-omap-hs.1, fck, mmchs2_fck,CK_343X), arch/arm/mach-omap2/clock34xx.c:CLK(mmci-omap-hs.0, fck, mmchs1_fck,CK_343X), arch/arm/mach-omap2/clock34xx.c:CLK(mmci-omap-hs.2, ick, mmchs3_ick,CK_3430ES2), arch/arm/mach-omap2/clock34xx.c:CLK(mmci-omap-hs.1, ick, mmchs2_ick,CK_343X), arch/arm/mach-omap2/clock34xx.c:CLK(mmci-omap-hs.0, ick, mmchs1_ick,CK_343X), 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: [alsa-devel] [PATCH 5/8] board-rx51-peripherals: split vaux3 and vmmc2 supplies
Hello, On Fri, Oct 09, 2009 at 01:03:47PM +0200, Mark Brown wrote: On Fri, Oct 09, 2009 at 09:45:29AM +0300, Eduardo Valentin wrote: On Thu, Oct 08, 2009 at 03:21:10PM +0200, Mark Brown wrote: On Thu, Oct 08, 2009 at 02:58:54PM +0300, Eduardo Valentin wrote: I may have missed it but I don't see rx51_vmmc2_supply added back anywhere in the patch? yes. That's because this patch is just to split then. As you can see in current code, this structure, rx51_vmmc2_supply, is actually used by rx51_vaux3_mmc and rx51_vmmc2. So the idea is to have separated supplies for each one. This patch just splits then. Patch 0006 of this series adds usage of rx51_vmmc2_supply. Might be an idea to change the description to something like add a separate structure for..., it wasn't 100% clear what was going on (probably because the diff doesn't include sufficient context to make it clear). ...using dev_name rather than dev should avoid the need to do this at runtime. I'm afraid using dev_name is not that easy. The mmc driver generates device name at runtime. That's why this board file setups .dev at runtime as well. rx51_twlgpio_setup - twl4030_mmc_init - omap2_init_mmc So, changing this supply to something static using .dev_name it is not possible with current code. That would need refactoring the whole mmc and hsmmc setup. And the device naming procedure is dependent on cpu as well. Check arch/arm/mach-omap2/device.c:omap2_init_mmc. I see your point. As mentioned above, this patch is just a split. I just added rx51_vaux3_supply to be owned by rx51_vaux3_mmc. And let the code behavior as it was before. Maybe your proposal must be sent into a separated patch/patch series (?). Yes, it's definately a separate patch - might be good to put it into the series before this one. -- 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: [alsa-devel] [PATCH 5/8] board-rx51-peripherals: split vaux3 and vmmc2 supplies
On Mon, Oct 12, 2009 at 11:08:58AM +0300, Eduardo Valentin wrote: I'm afraid using dev_name is not that easy. The mmc driver generates device name at runtime. That's why this board file setups .dev at runtime as well. rx51_twlgpio_setup - twl4030_mmc_init - omap2_init_mmc So, changing this supply to something static using .dev_name it is not possible with current code. That would need refactoring the whole mmc and hsmmc setup. And the device naming procedure is dependent on cpu as well. Check arch/arm/mach-omap2/device.c:omap2_init_mmc. Oh, dear - that sounds broken for hardware that's fixed on the board. That said, the code there looks like it's supposed to come out with the same answer each time it's run? How does this work with the clock API? -- 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 5/8] board-rx51-peripherals: split vaux3 and vmmc2 supplies
On Thu, Oct 08, 2009 at 03:21:10PM +0200, Mark Brown wrote:
On Thu, Oct 08, 2009 at 02:58:54PM +0300, Eduardo Valentin wrote:
From: Eduardo Valentin eduardo.valen...@nokia.com
Use separated supplies for vaux3 and vmmc2.
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
+static struct regulator_consumer_supply rx51_vaux3_supply = {
+ .supply = vmmc,
+};
+
I'd expect all these supplies to have devices associated with them (see
below)...
static struct regulator_consumer_supply rx51_vmmc2_supply = {
.supply = vmmc,
};
@@ -184,7 +188,7 @@ static struct regulator_init_data rx51_vaux3_mmc = {
| REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies = 1,
- .consumer_supplies = rx51_vmmc2_supply,
+ .consumer_supplies = rx51_vaux3_supply,
};
I may have missed it but I don't see rx51_vmmc2_supply added back
anywhere in the patch?
yes. That's because this patch is just to split then. As you can see
in current code, this structure, rx51_vmmc2_supply, is actually used
by rx51_vaux3_mmc and rx51_vmmc2. So the idea is to have separated
supplies for each one. This patch just splits then. Patch 0006 of this
series adds usage of rx51_vmmc2_supply.
static struct regulator_init_data rx51_vaux4 = {
@@ -266,7 +270,7 @@ static int rx51_twlgpio_setup(struct device *dev,
unsigned gpio, unsigned n)
/* set up MMC adapters, linking their regulators to them */
twl4030_mmc_init(mmc);
rx51_vmmc1_supply.dev = mmc[0].dev;
- rx51_vmmc2_supply.dev = mmc[1].dev;
+ rx51_vaux3_supply.dev = mmc[1].dev;
...using dev_name rather than dev should avoid the need to do this at
runtime.
I see your point. As mentioned above, this patch is just a split.
I just added rx51_vaux3_supply to be owned by rx51_vaux3_mmc. And
let the code behavior as it was before.
Maybe your proposal must be sent into a separated patch/patch series (?).
--
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: [alsa-devel] [PATCH 5/8] board-rx51-peripherals: split vaux3 and vmmc2 supplies
On Fri, Oct 09, 2009 at 09:45:29AM +0300, Eduardo Valentin wrote: On Thu, Oct 08, 2009 at 03:21:10PM +0200, Mark Brown wrote: On Thu, Oct 08, 2009 at 02:58:54PM +0300, Eduardo Valentin wrote: I may have missed it but I don't see rx51_vmmc2_supply added back anywhere in the patch? yes. That's because this patch is just to split then. As you can see in current code, this structure, rx51_vmmc2_supply, is actually used by rx51_vaux3_mmc and rx51_vmmc2. So the idea is to have separated supplies for each one. This patch just splits then. Patch 0006 of this series adds usage of rx51_vmmc2_supply. Might be an idea to change the description to something like add a separate structure for..., it wasn't 100% clear what was going on (probably because the diff doesn't include sufficient context to make it clear). ...using dev_name rather than dev should avoid the need to do this at runtime. I see your point. As mentioned above, this patch is just a split. I just added rx51_vaux3_supply to be owned by rx51_vaux3_mmc. And let the code behavior as it was before. Maybe your proposal must be sent into a separated patch/patch series (?). Yes, it's definately a separate patch - might be good to put it into the series before this one. -- 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 5/8] board-rx51-peripherals: split vaux3 and vmmc2 supplies
From: Eduardo Valentin eduardo.valen...@nokia.com
Use separated supplies for vaux3 and vmmc2.
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
arch/arm/mach-omap2/board-rx51-peripherals.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index b227475..92f7dfa 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -125,6 +125,10 @@ static struct regulator_consumer_supply rx51_vmmc1_supply
= {
.supply = vmmc,
};
+static struct regulator_consumer_supply rx51_vaux3_supply = {
+ .supply = vmmc,
+};
+
static struct regulator_consumer_supply rx51_vmmc2_supply = {
.supply = vmmc,
};
@@ -184,7 +188,7 @@ static struct regulator_init_data rx51_vaux3_mmc = {
| REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies = 1,
- .consumer_supplies = rx51_vmmc2_supply,
+ .consumer_supplies = rx51_vaux3_supply,
};
static struct regulator_init_data rx51_vaux4 = {
@@ -266,7 +270,7 @@ static int rx51_twlgpio_setup(struct device *dev, unsigned
gpio, unsigned n)
/* set up MMC adapters, linking their regulators to them */
twl4030_mmc_init(mmc);
rx51_vmmc1_supply.dev = mmc[0].dev;
- rx51_vmmc2_supply.dev = mmc[1].dev;
+ rx51_vaux3_supply.dev = mmc[1].dev;
rx51_vsim_supply.dev = mmc[1].dev;
return 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 5/8] board-rx51-peripherals: split vaux3 and vmmc2 supplies
On Thu, Oct 08, 2009 at 02:58:54PM +0300, Eduardo Valentin wrote:
From: Eduardo Valentin eduardo.valen...@nokia.com
Use separated supplies for vaux3 and vmmc2.
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
+static struct regulator_consumer_supply rx51_vaux3_supply = {
+ .supply = vmmc,
+};
+
I'd expect all these supplies to have devices associated with them (see
below)...
static struct regulator_consumer_supply rx51_vmmc2_supply = {
.supply = vmmc,
};
@@ -184,7 +188,7 @@ static struct regulator_init_data rx51_vaux3_mmc = {
| REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies = 1,
- .consumer_supplies = rx51_vmmc2_supply,
+ .consumer_supplies = rx51_vaux3_supply,
};
I may have missed it but I don't see rx51_vmmc2_supply added back
anywhere in the patch?
static struct regulator_init_data rx51_vaux4 = {
@@ -266,7 +270,7 @@ static int rx51_twlgpio_setup(struct device *dev,
unsigned gpio, unsigned n)
/* set up MMC adapters, linking their regulators to them */
twl4030_mmc_init(mmc);
rx51_vmmc1_supply.dev = mmc[0].dev;
- rx51_vmmc2_supply.dev = mmc[1].dev;
+ rx51_vaux3_supply.dev = mmc[1].dev;
...using dev_name rather than dev should avoid the need to do this at
runtime.
--
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
