On Wed, Jul 13, 2011 at 06:53:45PM +0300, Tero Kristo wrote:
> On Wed, 2011-07-13 at 16:40 +0200, Mark Brown wrote:
> > I do strongly prefer the idiom of just registering all the regulators
> > even if they're read only.
> Number of available SMPS regulators is kind
On Wed, Jul 13, 2011 at 12:00:37PM -0700, Kevin Hilman wrote:
> Actually, I'd prefer it stay in drivers/regulator. We're trying to move
> driver-type stuff out of arch/arm/* into the right place in drivers/*.
> In fact, I wonder if our VP/VC layers might better live under
> drivers/regulator also
On Mon, Jul 18, 2011 at 08:35:19PM +0300, Tero Kristo wrote:
> OMAP SMPS regulator driver provides access to OMAP voltage processor
> controlled regulators. These include VDD_MPU and VDD_CORE for OMAP3 and
> additionally VDD_IVA for OMAP4. SMPS regulators use the OMAP voltage
> layer for the actual
On Thu, Jul 21, 2011 at 12:57:03PM +0300, Felipe Balbi wrote:
> the problem seems to be worse then you thought:
> $ git ls-files drivers/ | grep madc
> drivers/hwmon/twl4030-madc-hwmon.c
> drivers/mfd/twl4030-madc.c
This is normal for this sort of auxiliary ADC - they're *normally* used
for sys
On Sat, Jun 11, 2011 at 10:56:36PM +0200, Rafael J. Wysocki wrote:
> On Saturday, June 11, 2011, Mark Brown wrote:
> > that's a very large proportion of the embedded space. It really feels
> > like we could be doing a better job for drivers using these buses,
> > there&
ayer for the actual voltage regulation operations.
>
> Signed-off-by: Tero Kristo
Acked-by: Mark Brown
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
e fix the McPDM threshold values used for playback, and
> capture to avoid broken code.
Acked-by: Mark Brown
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ks correctly.
> Missing request_mem_region/release_mem_region added.
>
> Signed-off-by: Peter Ujfalusi
Acked-by: Mark Brown
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at h
On Wed, Aug 03, 2011 at 12:16:17AM +0200, Rafael J. Wysocki wrote:
> On Tuesday, August 02, 2011, Kevin Hilman wrote:
> > I disagree and think that both are quite realistic (mainly because they
> > exist today, albiet mostly out of tree because no generic QoS framework
> > exist. e.g. on OMAP, we
On Thu, Aug 04, 2011 at 09:15:30PM +0200, Rafael J. Wysocki wrote:
> On Thursday, August 04, 2011, Mark Brown wrote:
> > On the one hand that's true. On the other hand that just seems like
> > going down a bad road where we have drivers that only work when run with
> >
On Fri, Aug 05, 2011 at 09:37:36PM +0200, Rafael J. Wysocki wrote:
> On Friday, August 05, 2011, Mark Brown wrote:
> > Do you have any examples of this that aren't better expressed in device
> > specific terms?
> I'm not sure what you mean exactly, but if you tak
On Sat, Aug 06, 2011 at 09:46:20PM +0200, Rafael J. Wysocki wrote:
> On Saturday, August 06, 2011, Mark Brown wrote:
> > I wouldn't say we've got to rely on userspace here - it seems like we
> > ought to be able to use DMI or other system data to identify the
> > af
On Mon, 2011-08-08 at 23:31 +0200, Rafael J. Wysocki wrote:
> On Sunday, August 07, 2011, Mark Brown wrote:
> > OK, so this does sound like there's probably a genuine issue on PCs due
> > to limitations in the environment. Is it possible to expose these
> > things to
On Fri, Aug 19, 2011 at 10:42:20PM +0200, Rafael J. Wysocki wrote:
> I really wouldn't like the discussion to go in circles.
> First, please tell me what in particular you are objecting to,
> because I don't think that's any of the patches that have been
> sent to the linux-pm list to date.
The
On Fri, Aug 19, 2011 at 10:24:19PM -0400, Alan Stern wrote:
> On Sat, 20 Aug 2011, Mark Brown wrote:
> > interfaces and let the subsystem and driver translate these into actual
> > wakeup latency constraints:
> >
> > https://lists.linux-foundation.org/pipermail/
On Sat, Aug 20, 2011 at 11:35:58AM +0200, Rafael J. Wysocki wrote:
> I'm not sure what you mean by "exposing per-device wakeup latency constraints
> to user space". I simply thought it might be useful to allow user space to
> add and remove those, in analogy to what it can do with the currently
On Sat, Aug 20, 2011 at 09:48:25AM -0400, Alan Stern wrote:
> No, I as wasking about driver- and subsystem-specific interfaces to
> userspace that translate into things users are already doing. Kevin's
> example was a touchscreen (although that was really an example of
> setting a power usage lev
On Sat, Aug 20, 2011 at 06:34:34PM +0200, Rafael J. Wysocki wrote:
> On Saturday, August 20, 2011, Mark Brown wrote:
> > Any sort of media streaming would be an obvious example - the
> > application picks the amount of data it buffers and how often it's
> > notified of
On Sat, Aug 20, 2011 at 06:51:42PM +0200, Rafael J. Wysocki wrote:
> On Saturday, August 20, 2011, Mark Brown wrote:
> > Coming at this from the embedded perspective modifying the kernel just
> > isn't an issue. It's quite depressing in other cases too but some of
On Sat, Aug 20, 2011 at 09:14:37PM +0200, Rafael J. Wysocki wrote:
> I guess you mean the driver here and I'm not really sure it can.
> For instance, the driver may not know what configuration it works in,
> e.g. is there a power domain or a hierarchy of those and how much time
> it takes to power
On Sun, Aug 21, 2011 at 08:05:53PM +0200, Rafael J. Wysocki wrote:
> On Sunday, August 21, 2011, Mark Brown wrote:
> > I don't understand why the driver would need to know what situation it's
> > in. I'd been working on the basis that the idea was that the driver
&g
On Tue, Aug 23, 2011 at 11:31:54PM +0200, Rafael J. Wysocki wrote:
> Perhaps. Still, that requires some policy to be put into drivers,
> which I don't think is entirely correct.
So, I don't really have the bandwidth to discuss this properly for at
least the next week or so - is it possible to fi
On Sat, Aug 27, 2011 at 03:47:55PM -0600, Paul Walmsley wrote:
> Certainly, from a kernel development perspective, one can decide to just
> dump this kind of DT generation problem back on the hardware vendors.
> But it seems more efficient and less error-prone to simply remove both
> mapping t
On Thu, Apr 19, 2012 at 07:00:55PM +0300, Ujfalusi, Peter wrote:
> If the playback preallocation fails, or if only capture is supported
> on the dai link
> this is not needed.
> It only applies if we have both playback and capture streams and the capture
> preallocation fails.
> Luckily the omap_p
On Fri, Apr 20, 2012 at 05:59:25PM +, Matcovschi, Oleg wrote:
> Should I resend patch again including maintainers?
Please, I didn't see it so I'll need a copy if I'm going to review it.
> Sorry, my first patch. Will do in future patches.
No worries.
signature.asc
Description: Digital sign
On Tue, Apr 24, 2012 at 07:02:02PM -0700, Oleg Matcovschi wrote:
> Change-Id: I4ba9de0de4681332539246ccc5e11a7a8fb32e79
> Signed-off-by: Oleg Matcovschi
Don't include Change-Ids in upstream submissions, they only make sense
within whatever private development tree you are using.
Ack
On Thu, Apr 26, 2012 at 11:10:31PM +0530, Keerthy wrote:
> From: J Keerthy
>
> AVS(Adaptive Voltage Scaling) is a power management technique which
> controls the operating voltage of a device in order to optimize (i.e. reduce)
> its power consumption. The voltage is adapted depending on static fa
On Fri, Apr 27, 2012 at 11:09:10AM +0530, J, KEERTHY wrote:
> Devfreq and cpufreq are related to dynamic frequency/voltage switching between
> pre defined Operating Performance Points or the OPPs. Every OPP being
> a voltage/frequency pair. Smartreflex is a different
> power management technique.
On Fri, Apr 27, 2012 at 02:01:17PM -0700, Kevin Hilman wrote:
> Mark Brown writes:
> > But presumably these things should integrate somehow - for example,
> > should devfreq and cpufreq be providing inputs into what AVS is doing,
> > and if so how?
> The way it is cur
aving them code and ensuring that
they work well with systems where the voltage is not configurable.
If systems are added needing regulator support this can be added back in,
though it should be based on core features rather than open coding things.
Signed-off-by: Mark Brown
---
drivers/video/
It is possible for regulator_enable() to fail and if it does fail that's
generally a bad sign for anything we try to do with the hardware afterwards
so check for and immediately return an error if regulator_enable() fails.
Signed-off-by: Mark Brown
---
drivers/video/omap2/dss/venc.c |
supply (the delay is also suspicously long for one for
a regulator to ramp). Correct the comment to avoid misleading people
taking this code as a reference.
Signed-off-by: Mark Brown
Acked-by: Grazvydas Ignotas
---
drivers/video/omap2/displays/panel-tpo-td043mtea1.c |2 +-
1 file changed, 1
It is possible for regulator_enable() to fail and if it does fail that's
generally a bad sign for anything we try to do with the hardware afterwards
so check for and immediately return an error if regulator_enable() fails.
Signed-off-by: Mark Brown
Acked-by: Grazvydas Ignotas
---
drivers/
On Thu, May 03, 2012 at 04:11:00PM +0300, Tomi Valkeinen wrote:
> I've already applied this and the three other patches that you sent in
> March to my omapdss tree. Have there been any changes?
No, it's a resend - if you've applied these changes they're not showing
up in -next.
signature.asc
De
On Thu, May 03, 2012 at 04:23:27PM +0300, Tomi Valkeinen wrote:
> On Thu, 2012-05-03 at 14:21 +0100, Mark Brown wrote:
> > On Thu, May 03, 2012 at 04:11:00PM +0300, Tomi Valkeinen wrote:
> > > I've already applied this and the three other patches that you sent in
> &g
On Mon, May 14, 2012 at 10:58:29AM +0900, Graeme Gregory wrote:
> drivers/mfd/palmas-irq.c | 241 +
The IRQ support here seems to be following a pretty common pattern for
dense IRQ maps - could we factor it out into regmap-irq? It'd also be
nice if it were using an irq_domain - while it's
On Mon, May 14, 2012 at 10:58:31AM +0900, Graeme Gregory wrote:
Looks good, quite a few of the things below are updates for very
recently introduced APIs.
> +static int palmas_smps_read(struct palmas *palmas, unsigned int reg,
> + unsigned int *dest)
> +{
> + int slave;
> + un
On Mon, May 14, 2012 at 07:26:31PM +0900, Graeme Gregory wrote:
> On 14/05/12 17:28, Mark Brown wrote:
> > On Mon, May 14, 2012 at 10:58:29AM +0900, Graeme Gregory wrote:
> >> drivers/mfd/palmas-irq.c | 241 +
> > The IRQ support here seems to be following a p
On Tue, May 15, 2012 at 03:12:45PM +0900, Graeme Gregory wrote:
> On 14/05/12 17:52, Mark Brown wrote:
> > On Mon, May 14, 2012 at 10:58:31AM +0900, Graeme Gregory wrote:
> >> +
> >> + palmas_ldo_write(pmic->palmas, palmas_regs_info[id].ctrl_addr, reg);
> >
eviwed-by: Mark Brown
however this depends on some new regmap-irq changes that Graeme posted a
couple of days ago and are only on regmap at the minute - Samuel, if
you're OK with this I guess the easiest thing is if I apply there?
signature.asc
Description: Digital signature
On Tue, May 15, 2012 at 03:48:58PM +0900, Graeme Gregory wrote:
> Palmas has both Switched Mode (SMPS) and Linear (LDO) regulators in it.
> This regulator driver allows software control of these regulators.
>
> The regulators available on Palmas series chips vary depending on the muxing.
> This is
On Thu, May 17, 2012 at 02:22:23PM +0100, Russell King - ARM Linux wrote:
> DMA on the other hand seems to have cases where you can make a choice
> between two or more providers of the service. The impression that I'm
> getting from this thread is that it's difficult to describe that kind
> of re
On Fri, May 18, 2012 at 11:55:12AM +0200, Samuel Ortiz wrote:
> I'm fine with it. For the MFD parts:
> Acked-by: Samuel Ortiz
Applied all, thanks. I moved the header updates from the regulator into
the MFD so the regulator driver can be applied via the regulator tree
and the MFD via the regmap
On Fri, May 18, 2012 at 01:42:33AM -0500, Ricardo Neri wrote:
> Introduce codec for HDMI. At the moment, this is a dummy codec. In the
> future it will parse the EDID to modify the supported parameters, such
> as the number of channels and the sample rates. At the moment, it blindly
> supports all
On Fri, May 18, 2012 at 01:42:32AM -0500, Ricardo Neri wrote:
> Hello,
>
> The ASoC HDMI codec used to be embedded in the DSS HDMI driver. In order
> to give the OMAP HDMI code a more logical arrangement and to remove
Acked-by: Mark Brown
signature.asc
Description: Digital signature
On Fri, May 18, 2012 at 07:46:26PM +0300, Maxim Podbereznyy wrote:
> Thanks a lot! This code certainly can be used as a reference. I just
> wonder why it was not possible to rewrite tps65910 driver to comply
> with current twl interface? For example tps65910 API for the
Eh? Both devices use the
On Fri, Jun 01, 2012 at 10:12:52PM +0200, Sebastien Guiriec wrote:
> pm_runtime_get_sync() and put_sync() are not called by McBSP driver.
> This is introducing a problem with PM and Audio Backend due to
> missing get/put for McBSP IP.
They are called by the core. Probably you're just pointing you
dings, grep seems to tell me it's not currently used anyway.
Signed-off-by: Mark Brown
---
Documentation/devicetree/bindings/regulator/twl-regulator.txt |1 -
drivers/regulator/twl-regulator.c |2 --
2 files changed, 3 deletions(-)
diff --git a/Doc
On Wed, Aug 29, 2012 at 09:31:31AM +0100, Lee Jones wrote:
> On Tue, Aug 28, 2012 at 10:21:33AM -0700, Mark Brown wrote:
> > > The regulator-name property is used to populate constrains->name. Are
> > > you sure you still want them all removed?
> > Yes, of course.
On Wed, Aug 29, 2012 at 07:04:48AM +0200, Janusz Krzysztofik wrote:
> On Tue, 28 Aug 2012 11:13:39 Mark Brown wrote:
> > The above looks like you already have a platform driver? All I'm
> > suggesting is changing the above to use platform rather than driver
> > data.
&
On Fri, Aug 31, 2012 at 05:26:22PM -0700, Tony Lindgren wrote:
> As the plat and mach includes need to disappear for single zImage work,
> we need to remove plat/hardware.h.
Acked-by: Mark Brown
There's a topic/omap branch in ASoC which you can pull in to help reduce
conflicts, or I
On Fri, Aug 31, 2012 at 07:06:54PM -0700, Tony Lindgren wrote:
> * Mark Brown [120831 17:28]:
> > There's a topic/omap branch in ASoC which you can pull in to help reduce
> > conflicts, or I could merge this there if that's sensible.
> Thanks.
On Sat, Sep 01, 2012 at 11:09:18AM +0200, Janusz Krzysztofik wrote:
> I see your point, however for now I can see no better way of referencing
> the data (of type struct snd_soc_card) then passing it to
> snd_soc_register_card(). But for this to work, I would have to register
> successfully an
On Wed, Sep 05, 2012 at 05:06:04PM +0530, Sourav Poddar wrote:
> +static struct regmap_config smsc_regmap_config = {
> + .reg_bits = 8,
> + .val_bits = 8,
> + .max_register = SMSC_MAX_REGISTER - 1;
That max_register setup looks very odd...
> + .cac
On Sun, Sep 09, 2012 at 09:12:40PM +0200, Uwe Kleine-König wrote:
> On Sat, Sep 08, 2012 at 09:38:49AM +0100, Russell King - ARM Linux wrote:
> > > of: add const to struct *of_device_id.data
> > >
> > > Drivers should never need to modify the data of a device id. So it can
> > > be co
On Mon, Sep 10, 2012 at 08:40:02AM +0200, Uwe Kleine-König wrote:
> Message-id: 201208141241.51379.a...@arndb.de
This is illegible, did the message have a subject line or other content
that a human might understand? Just as with commit IDs you should
*always* provide a human readable version, me
On Mon, Sep 10, 2012 at 09:05:47AM +0200, Uwe Kleine-König wrote:
> Subject: [PATCH] regulator: twl: make twl_info tables const
This is in my drivers branch and in -next, according to git it was
applied on Tuesday, so I'm not sure what you're querying here?
> It used to be possible to get a post
On Tue, Sep 11, 2012 at 12:13:20PM +0530, Shubhrajyoti D wrote:
> Currently in omap2_mcspi_txrx_dma the tx and the rx support is
> interleaved. Make the rx related code in omap2_mcspi_rx_dma
> and the tx related code omap2_mcspi_tx_dma and call the functions.
I'd ideally like some testing from the
On Tue, Sep 11, 2012 at 12:13:20PM +0530, Shubhrajyoti D wrote:
> Currently in omap2_mcspi_txrx_dma the tx and the rx support is
> interleaved. Make the rx related code in omap2_mcspi_rx_dma
> and the tx related code omap2_mcspi_tx_dma and call the functions.
Applied, thanks.
--
To unsubscribe fro
On Wed, Sep 12, 2012 at 02:46:56PM +0300, Peter Ujfalusi wrote:
> Hello,
>
> This series will switch the OMAP audio to use dmaengine.
> The final patch which does the switch was based on Russell King's earlier
> patch.
I'm fine with this from the ASoC side but it sounds like you're going to
resp
On Wed, Sep 19, 2012 at 02:05:43PM -0700, Tony Lindgren wrote:
> This is only used by omap1.
>
> And to fix things properly, this should not be included
> from the drivers at all.
Acked-by: Mark Brown
or I can apply it if that's easier.
--
To unsubscribe from this li
t;
> I also suggest ASoC gusy remove all extmute handling from
> sound/soc/codecs/twl4030.c unless it's been tested to work
> and implemented in a saner way.
Acked-by: Mark Brown
or I can apply it if that's easier.
--
To unsubscribe from this list: send the line "unsubsc
On Thu, Sep 20, 2012 at 10:43:46AM -0400, Matt Porter wrote:
> Documentation/feature-removal-schedule.txt | 10 ++
> 1 file changed, 10 insertions(+)
We decided at kernel summit that we'd stop bothering with this, it's
mostly just bitrot and rarely read. I guess the ASoC driver update
On Fri, Sep 14, 2012 at 03:05:46PM +0300, Peter Ujfalusi wrote:
> With this parameter added to dmaengine_prep_dma_cyclic() the API will be in
> sync with other dmaengine_prep_*() functions.
> The dmaengine_prep_dma_cyclic() function primarily used by audio for cyclic
> transfer required by ALSA, we
On Mon, Sep 10, 2012 at 01:46:18PM +0300, Peter Ujfalusi wrote:
> Hello,
Applied all, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Sep 18, 2012 at 08:01:25AM -0400, Matt Porter wrote:
> Adds pinctrl support to support OMAP platforms that boot from DT
> and rely on pinctrl support to set pinmuxes.
Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to major
On Wed, Sep 05, 2012 at 05:06:04PM +0530, Sourav Poddar wrote:
> +static struct regmap_config smsc_regmap_config = {
> + .reg_bits = 8,
> + .val_bits = 8,
> + .max_register = SMSC_MAX_REGISTER - 1;
> + .cache_type = REGCACHE_COMPRESSED,
> +};
That d
On Mon, Oct 01, 2012 at 05:00:06PM +0530, ABRAHAM, KISHON VIJAY wrote:
> On Mon, Oct 1, 2012 at 4:31 PM, Sourav Poddar wrote:
Delete irrelevant context from your replies, it makes it much easier to
find new text.
> > +static int smsc_i2c_remove(struct i2c_client *i2c)
> > +{
> > + struct s
On Mon, Oct 01, 2012 at 05:23:15PM +0530, ABRAHAM, KISHON VIJAY wrote:
> On Mon, Oct 1, 2012 at 5:14 PM, Mark Brown
> > No, this is not at all sensible - if there's an mfd_remove_devices()
> > function we really ought to be able to use it to remove the children.
> > If
On Mon, Oct 01, 2012 at 08:54:23PM +0530, ABRAHAM, KISHON VIJAY wrote:
> On Mon, Oct 1, 2012 at 5:39 PM, Mark Brown
> > Why would that be helpful? Most platforms don't support DT at all, and
> I'm not sure how to put it correctly. All I'm trying to tell is mfd is
&
On Tue, Oct 02, 2012 at 03:43:22PM +0300, Felipe Balbi wrote:
> BTW, OTOH writing all children into the DT actually describes the HW,
> no ? And depending on the device I feel it'd be better to write that
Well, it depends on the hardware. Some hardware has a bunch of nice,
neat IPs which can use
On Tue, Oct 02, 2012 at 11:07:30PM +0200, Janusz Krzysztofik wrote:
> Is something wrong with this patch? Any chance for it to find its way into
> 3.7?
I don't have the patch.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kern
On Thu, Oct 04, 2012 at 11:27:15AM +0300, Peter Ujfalusi wrote:
> From: Tony Lindgren
>
> McPDM needs platt/cpu.h for omap_rev and not omap_hwmod.h.
> Drivers must not include omap_hwmod.h at, it will be
> private to mach-omap2 soon. Fix the problem before other
> drivers will also start includin
On Thu, Oct 04, 2012 at 11:27:15AM +0300, Peter Ujfalusi wrote:
> From: Tony Lindgren
>
> McPDM needs platt/cpu.h for omap_rev and not omap_hwmod.h.
> Drivers must not include omap_hwmod.h at, it will be
> private to mach-omap2 soon. Fix the problem before other
> drivers will also start includin
On Thu, Oct 04, 2012 at 11:27:15AM +0300, Peter Ujfalusi wrote:
> Signed-off-by: Tony Lindgren
Peter, you should sign off any patches you forward on. I applied this
anyway since it's so trivial and I'd seen the original posting.
--
To unsubscribe from this list: send the line "unsubscribe linux
On Wed, Oct 03, 2012 at 12:46:57PM +0200, Janusz Krzysztofik wrote:
> The old method of registering with the ASoC core by creating a
> "soc-audio" platform device no longer works for Amstrad Delta sound card
> after recent changes to drvdata handling (commit
> 0998d0631001288a5974afc0b2a5f568bcdecb
On Thu, Oct 18, 2012 at 03:52:37PM -0700, Tony Lindgren wrote:
> * Tony Lindgren [121017 13:01]:
> > Is it OK for me to merge in your ASoC for-3.7 branch at commit
> > 68214d99 (ASoC: omap-mcpdm: Remove OMAP revision check) also
> > into my omap cleanup branch for v3.8?
> > I need that to avoid
On Mon, Apr 18, 2011 at 05:41:14PM +0300, Tony Lindgren wrote:
> * Mark Brown [110418 16:54]:
> > I do think that a flat lines of code criterion isn't terribly helpful as
> > it isn't *really* what we're trying to optimise and will needlessly
> > peanalise
On Wed, Apr 27, 2011 at 10:39:50AM +0100, Graeme Gregory wrote:
> + switch (info->flags) {
> + case 0:
> + if (index == 0)
> + voltage = 0;
> + else if (index < 58)
> + voltage = (60 + (12500 * (index - 1)));
> +
On Wed, Apr 27, 2011 at 01:48:52PM -0700, Colin Cross wrote:
> OPP currently has opp_enable and opp_disable functions. I don't
> understand why these are needed, they are only used at init time to
> determine available voltages, which could be handled by never passing
> unavailable voltages to th
On Fri, Apr 29, 2011 at 03:47:44PM +0300, Kalle Jokiniemi wrote:
> + .always_on = true,
> + .valid_modes_mask = REGULATOR_MODE_NORMAL
> + | REGULATOR_MODE_STANDBY,
> + .valid_ops_mask = REGULATOR_CHA
On Thu, May 05, 2011 at 02:36:48PM +0300, Tomi Valkeinen wrote:
> So currently we have REGULATOR_SUPPLY defines for each board in all the
> board files which support display. It would be much better to have an
> overrideable standard setup for the DSS powers, but this would require
> dynamically s
On Wed, May 04, 2011 at 11:50:52PM -0700, Colin Cross wrote:
> True, that was an oversimplificaiton. I meant the minimum voltage that
> scales with clock frequencies only depends on the clock frequency, not
> the device. Devices do need to be able to specify a higher minimum
> voltage, and the re
On Mon, May 09, 2011 at 03:16:03PM +0300, Felipe Balbi wrote:
> On Mon, May 09, 2011 at 12:43:49PM +0100, Liam Girdwood wrote:
> > I think it's the lesser evil though, especially for device integrators.
> > They will just match the regulator name from the schematics together
> > with the TRM name
On Mon, May 09, 2011 at 04:07:07PM +0300, Felipe Balbi wrote:
> The thing is. We already had problems in the past with the Clock FW
> because drivers were passing clock names on platform_data and I really
> want to avoid the same on regulators. We need something clever.
Right, which is why you sh
On Mon, May 09, 2011 at 04:51:26PM +0300, Felipe Balbi wrote:
> On Mon, May 09, 2011 at 03:35:43PM +0200, Mark Brown wrote:
> > - twl->usb3v3 = regulator_get(twl->dev, "vusb");
> > + twl->usb3v3 = regulator_get(twl->dev, regulator_name);
> > if (
On Mon, May 09, 2011 at 06:34:34PM +0300, Tomi Valkeinen wrote:
> The first is that we want to avoid unnecessary board file changes, and
> as almost all boards configure the DSS powers the same way, it'd be nice
> to have a default config for these.
Right, makes sense.
> The second thing is that
On Sun, May 08, 2011 at 05:50:06PM -0400, gr...@linuxhacker.ru wrote:
> + /*
> + * link regulators to MMC adapters ... we "know" the
> + * regulators will be set up only *after* we return.
> + */
> + encore_vmmc1_supply.dev = mmc[1].dev;
Just specify dev_name in the supply
ch is below, tested with my "hey look, this compiles!" test plan -
I'd be a bit surprised if it ran straight off.
>From 819cc21f22b1f570f7d5d8fe981bbb03e28bdb9d Mon Sep 17 00:00:00 2001
From: Mark Brown
Date: Mon, 9 May 2011 13:07:41 +0200
Subject: [PATCH] regulator: Refactor sup
P36xx
> as well.
Acked-by: Mark Brown
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, May 11, 2011 at 12:23:45PM +0300, Tomi Valkeinen wrote:
> So how should the regulator be set up?
You need to create a new regulator of some kind and then provide a way
for machines to set the supply_regulator in the init_data.
> I should setup a fixed regulator, which is supplied from VC
> its ADC block. VUSB handling also differs.
Reviewed-by: Mark Brown
> + pdata->driver_data = (void *)features;
> +
You never need to cast to void, and doing needless casts can mask bugs.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
On Thu, May 12, 2011 at 02:27:57PM +0100, Graeme Gregory wrote:
> Adding support for the twl6025. Major difference in the twl6025 is the
> group functionality has been removed from the chip so this affects how
> regulators are enabled and disabled.
Acked-by: Mark Brown
--
To unsubsc
On Fri, May 13, 2011 at 07:40:32AM -0700, Tony Lindgren wrote:
> Date: Fri, 13 May 2011 04:41:32 -0700
> Subject: [PATCH] omap: Remove support for omap2evm
>
> The board support has never been merged for it as noticed
> by Russell King . So let's remove the
> related dea
On Fri, May 20, 2011 at 07:03:51PM +0530, Balaji T K wrote:
> TWL6030: regulator is enabled via VREG_STATE
> TWL4030: regulator is enabled via VREG_GRP
> Since there is nothing common, split twlreg_enable similar to other
> regulator_ops
>
> Signed-off-by: Balaji T K
Acked-by
On Fri, May 20, 2011 at 07:03:52PM +0530, Balaji T K wrote:
> TWL6030: regulator is disabled via VREG_STATE
> TWL4030: regulator is disabled via VREG_GRP
> Since there is nothing common, split twlreg_enable similar to other
> regulator_ops
>
> Signed-off-by: Balaji T K
Ac
On Wed, May 18, 2011 at 07:32:49PM +0100, Graeme Gregory wrote:
> Adding support for the twl6025. Major difference in the twl6025 is the
> group functionality has been removed from the chip so this affects how
> regulators are enabled and disabled.
>
> The names of the regulators also changed.
I
On Sun, May 22, 2011 at 05:58:49PM -0400, gr...@linuxhacker.ru wrote:
> From: Oleg Drokin
>
> Also drop old style supply.dev assignments common in hsmmc init
> as no longer needed.
Acked-by: Mark Brown
Note that it'd be better to split into two patches as it makes rev
On Sun, May 22, 2011 at 09:21:23PM +0100, Graeme Gregory wrote:
> Adding support for the twl6025. Major difference in the twl6025 is the
> group functionality has been removed from the chip so this affects how
> regulators are enabled and disabled.
Acked-by: Mark Brown
> Since V1
On Sun, May 22, 2011 at 09:21:24PM +0100, Graeme Gregory wrote:
> The twl6025 uses a different regulator for USB than the 6030 so select
> the correct regulator name depending on the subclass of device.
Acked-by: Mark Brown
--
To unsubscribe from this list: send the line "unsubscribe
701 - 800 of 1498 matches
Mail list logo
