[PATCH] ARM: EXYNOS4: Configure MAX8997 PMIC for Origen
Mark Brown
broonie at opensource.wolfsonmicro.com
Tue Aug 16 11:19:18 EDT 2011
On Tue, Aug 16, 2011 at 04:38:46PM +0530, Inderpal Singh wrote:
> On 14 August 2011 20:31, Mark Brown <broonie at opensource.wolfsonmicro.com>wrote:
> > On Thu, Aug 11, 2011 at 09:26:05AM +0530, Inderpal Singh wrote:
> > > +static struct regulator_consumer_supply __initdata ldo7_consumer[] = {
> > > + REGULATOR_SUPPLY("avdd", "soc-audio"), /* Reatek ALC5625*/
> > > +};
> > Ick, no. The soc-audio device is a virtual device within Linux and is
> > being phased out, any driver adding new soc-audio devices will be
> > rejected. The CODEC driver should deal with its own power.
> Ok. So does it mean that sound cards will have their own devices? And those
> device names should be listed as consumers?
As I said above "The CODEC driver should deal with its own power."
> > > +static struct i2c_board_info i2c0_devs[] __initdata = {
> > > +[I2C0_MAX8997] = {
> > > + I2C_BOARD_INFO("max8997", (0xCC >> 1)),
> > > + .platform_data = &origen_max8997_pdata,
> > > + },
> > > +};
> > Why are you assigning the array index? That's very unusual.
> Have seen this kind of initialisation at few places. It looked more
> readable.
> If its not preferred, I will remove it.
You shouldn't need to be looking up individual members in a board info
array in the first place.
> > > + s3c_i2c0_set_platdata(NULL);
> > > + i2c0_devs[I2C0_MAX8997].irq = gpio_to_irq(EXYNOS4_GPX0(4));
> > There should be defines to do this statically.
> What advantages do you see in using defines?
It's non-idiomatic to modify the I2C board info at runtime, all the
numbers are known at compile time anyway.
More information about the linux-arm-kernel
mailing list