From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Yadwinder Singh Brar <yadi.brar01@gmail.com>
Cc: Yadwinder Singh <yadi.brar@samsung.com>,
linux-samsung-soc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 2/2] regulator: Add support for MAX77686.
Date: Thu, 10 May 2012 10:34:43 +0100 [thread overview]
Message-ID: <20120510093442.GK3908@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <CAKew6eWEYBP1zXXwLL4eWOhOKZ-HwAfUX_kg8cnsaDyUXVKSkQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1145 bytes --]
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?
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: broonie@opensource.wolfsonmicro.com (Mark Brown)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2] regulator: Add support for MAX77686.
Date: Thu, 10 May 2012 10:34:43 +0100 [thread overview]
Message-ID: <20120510093442.GK3908@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <CAKew6eWEYBP1zXXwLL4eWOhOKZ-HwAfUX_kg8cnsaDyUXVKSkQ@mail.gmail.com>
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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120510/52a8cef0/attachment-0001.sig>
next prev parent reply other threads:[~2012-05-10 9:34 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-09 16:24 [PATCH 0/2] regulator: add initial suport for max77686 Yadwinder Singh
2012-05-09 16:24 ` Yadwinder Singh
2012-05-09 16:24 ` [PATCH 1/2] mfd: Add support for MAX77686 Yadwinder Singh
2012-05-09 16:24 ` Yadwinder Singh
2012-05-09 18:27 ` Mark Brown
2012-05-09 18:27 ` Mark Brown
2012-05-09 23:42 ` Chanwoo Choi
2012-05-09 23:42 ` Chanwoo Choi
2012-05-10 7:30 ` Yadwinder Singh Brar
2012-05-10 7:30 ` Yadwinder Singh Brar
2012-05-09 16:24 ` [PATCH 2/2] regulator: " Yadwinder Singh
2012-05-09 16:24 ` Yadwinder Singh
2012-05-09 18:47 ` Mark Brown
2012-05-09 18:47 ` Mark Brown
2012-05-10 7:24 ` Yadwinder Singh Brar
2012-05-10 7:24 ` Yadwinder Singh Brar
2012-05-10 9:34 ` Mark Brown [this message]
2012-05-10 9:34 ` Mark Brown
2012-05-10 10:56 ` Yadwinder Singh Brar
2012-05-10 10:56 ` Yadwinder Singh Brar
2012-05-15 13:47 ` Yadwinder Singh Brar
2012-05-15 13:47 ` Yadwinder Singh Brar
2012-05-16 13:08 ` Mark Brown
2012-05-16 13:08 ` Mark Brown
2012-05-09 19:54 ` Sylwester Nawrocki
2012-05-09 19:54 ` Sylwester Nawrocki
2012-05-10 7:31 ` Yadwinder Singh Brar
2012-05-10 7:31 ` Yadwinder Singh Brar
2012-05-09 18:23 ` [PATCH 0/2] regulator: add initial suport for max77686 Mark Brown
2012-05-09 18:23 ` Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120510093442.GK3908@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=yadi.brar01@gmail.com \
--cc=yadi.brar@samsung.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.