From: Jarkko Nikula <jhnikula@gmail.com>
To: eduardo.valentin@nokia.com
Cc: ext Tony Lindgren <tony@atomide.com>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 17/18] omap: rx51: Add supplies for the tlv320aic3x codec driver
Date: Tue, 18 May 2010 13:00:26 +0300 [thread overview]
Message-ID: <20100518130026.a979ac51.jhnikula@gmail.com> (raw)
In-Reply-To: <20100506070018.GB16262@besouro.research.nokia.com>
On Thu, 6 May 2010 10:00:18 +0300
Eduardo Valentin <eduardo.valentin@nokia.com> wrote:
> > > +static struct regulator_consumer_supply rx51_vio_supplies[] = {
> > > + /* tlv320aic3x digital supplies */
> > > + {
> > > + .supply = "IOVDD",
> > > + .dev_name = "2-0018"
> > > + },
> > > + {
> > > + .supply = "DVDD",
> > > + .dev_name = "2-0018"
> > > + },
> > > +};
> >
> >
> > This isn't mandatory, but I find the code more readable if you use the REGULATOR_SUPPLY macro,
> > which kinda suitable for cases like yours, where you are passing the pair supply&dev_name.
>
Yeah, I was just following how the MMC supplies were defined in this
file and it's better to convert all of these to use REGULATOR_SUPPLY
macro. I'll send conversion patch on top of this + one adding couple
supplies more I would like to get in during this merge window.
> > > +static struct regulator_init_data rx51_vio = {
> > > + .constraints = {
> > > + .min_uV = 1800000,
> > > + .max_uV = 1800000,
> > > + .valid_modes_mask = REGULATOR_MODE_NORMAL
> > > + | REGULATOR_MODE_STANDBY,
> > > + .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
> >
> > I'm not sure if we would ever change voltage level in VIO in rx51 case.
> > It could enter sleep mode. But even there it wouldn't change voltage level.
> > Except, of cource, during off mode transition. But then, the regfw wouldn't care.
>
> Actually, one correction here, even during off mode transition I believe we need to
> keep it, otherwise some wake up source would be screwed.
> >
What do you think about those other TWL regulators, do they have valid
mask bits so would it make sense to correct all of them at once? I'm
not expert with TWL & RX51 HW but I'm thinking if there are also other
regulators which should not change. At least many regulators have the
same min_uV and max_uV defined.
--
Jarkko
WARNING: multiple messages have this Message-ID (diff)
From: jhnikula@gmail.com (Jarkko Nikula)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 17/18] omap: rx51: Add supplies for the tlv320aic3x codec driver
Date: Tue, 18 May 2010 13:00:26 +0300 [thread overview]
Message-ID: <20100518130026.a979ac51.jhnikula@gmail.com> (raw)
In-Reply-To: <20100506070018.GB16262@besouro.research.nokia.com>
On Thu, 6 May 2010 10:00:18 +0300
Eduardo Valentin <eduardo.valentin@nokia.com> wrote:
> > > +static struct regulator_consumer_supply rx51_vio_supplies[] = {
> > > + /* tlv320aic3x digital supplies */
> > > + {
> > > + .supply = "IOVDD",
> > > + .dev_name = "2-0018"
> > > + },
> > > + {
> > > + .supply = "DVDD",
> > > + .dev_name = "2-0018"
> > > + },
> > > +};
> >
> >
> > This isn't mandatory, but I find the code more readable if you use the REGULATOR_SUPPLY macro,
> > which kinda suitable for cases like yours, where you are passing the pair supply&dev_name.
>
Yeah, I was just following how the MMC supplies were defined in this
file and it's better to convert all of these to use REGULATOR_SUPPLY
macro. I'll send conversion patch on top of this + one adding couple
supplies more I would like to get in during this merge window.
> > > +static struct regulator_init_data rx51_vio = {
> > > + .constraints = {
> > > + .min_uV = 1800000,
> > > + .max_uV = 1800000,
> > > + .valid_modes_mask = REGULATOR_MODE_NORMAL
> > > + | REGULATOR_MODE_STANDBY,
> > > + .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
> >
> > I'm not sure if we would ever change voltage level in VIO in rx51 case.
> > It could enter sleep mode. But even there it wouldn't change voltage level.
> > Except, of cource, during off mode transition. But then, the regfw wouldn't care.
>
> Actually, one correction here, even during off mode transition I believe we need to
> keep it, otherwise some wake up source would be screwed.
> >
What do you think about those other TWL regulators, do they have valid
mask bits so would it make sense to correct all of them at once? I'm
not expert with TWL & RX51 HW but I'm thinking if there are also other
regulators which should not change. At least many regulators have the
same min_uV and max_uV defined.
--
Jarkko
next prev parent reply other threads:[~2010-05-18 10:00 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-05 19:32 [PATCH 00/18] omap platform data and board updates for 2.6.35 merge window Tony Lindgren
2010-05-05 19:32 ` Tony Lindgren
2010-05-05 19:32 ` [PATCH 01/18] OMAP2/3: Add V4L2 DSS driver support in device.c Tony Lindgren
2010-05-05 19:32 ` Tony Lindgren
2010-05-05 19:32 ` [PATCH 02/18] omap1: amsdelta: defconfig updates Tony Lindgren
2010-05-05 19:32 ` Tony Lindgren
2010-05-05 19:32 ` [PATCH 03/18] omap2: Add I2C bus 1 initialisation for 2430sdp Tony Lindgren
2010-05-05 19:32 ` Tony Lindgren
2010-05-05 19:32 ` [PATCH 04/18] omap2: Add OHCI USB platform init for 2430 SDP Tony Lindgren
2010-05-05 19:32 ` Tony Lindgren
2010-05-05 19:32 ` [PATCH 05/18] omap2: select ARCH_OMAP_OTG for OMAP2430 SDP Tony Lindgren
2010-05-05 19:32 ` Tony Lindgren
2010-05-05 19:32 ` [PATCH 06/18] omap: Devkit8000: Add mux initialization Tony Lindgren
2010-05-05 19:32 ` Tony Lindgren
2010-05-05 19:32 ` [PATCH 07/18] omap: Devkit8000: Update default configuration Tony Lindgren
2010-05-05 19:32 ` Tony Lindgren
2010-05-05 19:32 ` [PATCH 08/18] can:ti_hecc: board specific hookup on AM3517EVM Tony Lindgren
2010-05-05 19:32 ` Tony Lindgren
2010-05-05 19:33 ` [PATCH 09/18] can:ti_hecc: Enable CAN support on AM3517 Tony Lindgren
2010-05-05 19:33 ` Tony Lindgren
2010-05-05 19:33 ` [PATCH 10/18] AM35xx EMAC : define submodule offsets Tony Lindgren
2010-05-05 19:33 ` Tony Lindgren
2010-05-05 19:33 ` [PATCH 11/18] AM35xx : Platform specific hookup for EMAC module Tony Lindgren
2010-05-05 19:33 ` Tony Lindgren
2010-05-05 19:33 ` [PATCH 12/18] OMAP3 : clock data: Update name string for EMAC clocks Tony Lindgren
2010-05-05 19:33 ` Tony Lindgren
2010-05-05 19:45 ` Russell King - ARM Linux
2010-05-05 19:45 ` Russell King - ARM Linux
2010-05-05 20:02 ` Tony Lindgren
2010-05-05 20:02 ` Tony Lindgren
2010-05-10 20:17 ` Tony Lindgren
2010-05-10 20:17 ` Tony Lindgren
2010-05-05 19:33 ` [PATCH 13/18] AM3517 defconfig update : enable EMAC support Tony Lindgren
2010-05-05 19:33 ` Tony Lindgren
2010-05-05 19:33 ` [PATCH 14/18] omap: Overo: Add support for second ethernet port Tony Lindgren
2010-05-05 19:33 ` Tony Lindgren
2010-05-18 13:41 ` Steve Sakoman
2010-05-18 13:41 ` Steve Sakoman
2010-05-19 18:27 ` Tony Lindgren
2010-05-19 18:27 ` Tony Lindgren
2010-05-21 20:15 ` [PATCH 14/18 FIX] " Steve Sakoman
2010-05-21 20:15 ` Steve Sakoman
2010-05-31 12:31 ` [APPLIED] [PATCH 14/18 FIX] omap: Overo: Add support for second ethernet Tony Lindgren
2010-05-05 19:33 ` [PATCH 15/18] omap: rx51: Change the TWL4030 VMMC2 voltage constraints andsupply name Tony Lindgren
2010-05-05 19:33 ` Tony Lindgren
2010-05-05 19:33 ` [PATCH 16/18] omap: rx51: Add i2c2 board_info with tlv320aic3x Tony Lindgren
2010-05-05 19:33 ` Tony Lindgren
2010-05-05 19:33 ` [PATCH 17/18] omap: rx51: Add supplies for the tlv320aic3x codec driver Tony Lindgren
2010-05-05 19:33 ` Tony Lindgren
2010-05-06 6:57 ` Eduardo Valentin
2010-05-06 6:57 ` Eduardo Valentin
2010-05-06 7:00 ` Eduardo Valentin
2010-05-06 7:00 ` Eduardo Valentin
2010-05-18 10:00 ` Jarkko Nikula [this message]
2010-05-18 10:00 ` Jarkko Nikula
2010-05-05 19:33 ` [PATCH 18/18] AM35x: fix UI card EHCI port and LCD dependency Tony Lindgren
2010-05-05 19:33 ` Tony Lindgren
2010-05-05 20:21 ` [PATCH 00/18] omap platform data and board updates for 2.6.35 merge window Koen Kooi
2010-05-05 21:09 ` Tony Lindgren
2010-05-06 7:27 ` Koen Kooi
2010-05-06 7:42 ` Tomi Valkeinen
2010-05-06 15:44 ` Tony Lindgren
2010-05-10 7:57 ` Tomi Valkeinen
2010-05-10 22:25 ` Tony Lindgren
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=20100518130026.a979ac51.jhnikula@gmail.com \
--to=jhnikula@gmail.com \
--cc=eduardo.valentin@nokia.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=tony@atomide.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.