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 <[email protected]>
>
> > Use separated supplies for vaux3 and vmmc2.
>
> > Signed-off-by: Eduardo Valentin <[email protected]>
>
> > +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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
