[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120510093442.GK3908@opensource.wolfsonmicro.com>
Date: Thu, 10 May 2012 10:34:43 +0100
From: Mark Brown <broonie@...nsource.wolfsonmicro.com>
To: Yadwinder Singh Brar <yadi.brar01@...il.com>
Cc: Yadwinder Singh <yadi.brar@...sung.com>,
linux-samsung-soc@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 2/2] regulator: Add support for MAX77686.
On Thu, May 10, 2012 at 12:54:24PM +0530, Yadwinder Singh Brar wrote:
> On Thu, May 10, 2012 at 12:17 AM, Mark Brown
> > On Wed, May 09, 2012 at 09:54:55PM +0530, Yadwinder Singh wrote:
> >> + [MAX77686_EN32KHZ_AP] = NULL,
> >> + [MAX77686_EN32KHZ_CP] = NULL,
> > Now that the generic clock API is in mainline these should be moved over
> > to use it.
> Sorry, I cann't get your point here. Please explain it little bit more.
These are not regulators, these are clocks. They should use the clock
API.
> >> + if (pdata->ramp_delay) {
> >> + max77686->ramp_delay = pdata->ramp_delay;
> >> + max77686_update_reg(i2c, MAX77686_REG_BUCK2CTRL1,
> >> + RAMP_VALUE, RAMP_MASK);
> > This appears not to actually use the value passed in as platform_data.
> It gets corresponding index of ramp_rate value in ramp_rate_value
> table supported by hardware, from platform_data which we write to
> ramp_rate control bits of control registers.
Why is the driver unconditionally writing these register values here
rather than setting the ramp delay that was passed in?
Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)
Powered by blists - more mailing lists