public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
From: Tero Kristo <t-kristo@ti.com>
To: Samuel Ortiz <sameo@linux.intel.com>
Cc: linux-omap@vger.kernel.org, broonie@opensource.wolfsonmicro.com,
	lrg@ti.com, khilman@ti.com, b-cousson@ti.com, rnayak@ti.com,
	gg@slimlogic.co.uk
Subject: Re: [PATCHv7 5/7] mfd: twl-core: pass driver data from pdata to add_regulator for VDD1 and VDD2
Date: Tue, 13 Dec 2011 09:19:33 +0200	[thread overview]
Message-ID: <1323760773.15292.12.camel@sokoban> (raw)
In-Reply-To: <20111212180423.GX13952@sortiz-mobl>

On Mon, 2011-12-12 at 19:04 +0100, Samuel Ortiz wrote:
> Hi Tero,
> 
> 
> On Mon, Nov 28, 2011 at 04:53:23PM +0200, Tero Kristo wrote:
> > This way, we can add custom flags for VDD1 and VDD2 regulators that
> > get passed all the way to regulator init. This is needed for SMPS
> > regulator support to select used controller mode for these regulators
> > (either voltage processor or default.)
> > 
> > Signed-off-by: Tero Kristo <t-kristo@ti.com>
> > Cc: Samuel Ortiz <sameo@linux.intel.com>
> > ---
> >  drivers/mfd/twl-core.c |    6 ++++--
> >  1 files changed, 4 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
> > index 01ecfee..af93fce 100644
> > --- a/drivers/mfd/twl-core.c
> > +++ b/drivers/mfd/twl-core.c
> > @@ -846,12 +846,14 @@ add_children(struct twl4030_platform_data *pdata, unsigned long features)
> >  			return PTR_ERR(child);
> >  
> >  		child = add_regulator(TWL4030_REG_VDD1, pdata->vdd1,
> > -					features);
> > +					features |
> > +					(u32)pdata->vdd1->driver_data);
> That looks hackish to me. Do you have any guarantee that your driver_data and
> your features bitmaps have zero intersections ?

That is somewhat hackish yes. I changed the implementation a bit for v8
(which you should also have in your inbox now, I sent it out on Friday),
I split the driver_data to a struct that contains a couple of function
pointers and the features flag. It is still using a bitwise OR for
setting the flags inside twl-core.c, but the entity that initializes the
driver_data sets the features always at zero, so twl-core is the only
one who sets these. That version of the patch could be changed from
twl-core point of view to just set the features field instead of OR.

v8 of the patch set actually merges the regulator driver and the
twl-core data passing parts together to avoid merge conflicts, so you
should take a look at the twl-core.c / include/linux/i2c/twl.h part of
patch:

[PATCHv8 4/5] twl4030: add support for external voltage get/set

-Tero



  reply	other threads:[~2011-12-13  7:19 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-28 14:53 [PATCHv7 0/7] External controller support for TWLxxxx Tero Kristo
2011-11-28 14:53 ` [PATCHv7 1/7] regulator: twl: fix twl4030 support for smps regulators Tero Kristo
2011-11-28 18:58   ` Mark Brown
2011-11-28 14:53 ` [PATCHv7 2/7] TEMP: OMAP3: beagle rev-c4: enable OPP6 Tero Kristo
2011-11-28 14:53 ` [PATCHv7 3/7] omap3: voltage: fix channel configuration Tero Kristo
2011-12-02 23:55   ` Kevin Hilman
2011-12-05  9:35     ` Tero Kristo
2011-12-05 20:23       ` Kevin Hilman
2011-12-07  8:57         ` Tero Kristo
2011-12-10  1:05           ` Kevin Hilman
2011-11-28 14:53 ` [PATCHv7 4/7] omap3: add common twl configurations for vdd1 and vdd2 Tero Kristo
2011-12-02 23:56   ` Kevin Hilman
2011-11-28 14:53 ` [PATCHv7 5/7] mfd: twl-core: pass driver data from pdata to add_regulator for VDD1 and VDD2 Tero Kristo
2011-12-12 18:04   ` Samuel Ortiz
2011-12-13  7:19     ` Tero Kristo [this message]
2011-11-28 14:53 ` [PATCHv7 6/7] regulator: twl: add support for external controller Tero Kristo
2011-11-28 14:58   ` Mark Brown
2011-11-28 15:43     ` Tero Kristo
2011-11-28 15:56       ` Mark Brown
2011-11-28 14:53 ` [PATCHv7 7/7] omap3: twl-common: enable VP SMPS mode for VDD1 and VDD2 Tero Kristo

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=1323760773.15292.12.camel@sokoban \
    --to=t-kristo@ti.com \
    --cc=b-cousson@ti.com \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=gg@slimlogic.co.uk \
    --cc=khilman@ti.com \
    --cc=linux-omap@vger.kernel.org \
    --cc=lrg@ti.com \
    --cc=rnayak@ti.com \
    --cc=sameo@linux.intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox