On Fri, Aug 06, 2010 at 06:08:03AM -0500, Nishanth Menon wrote:
Well that is my motivation here. if driver reports a warning to kernel
syslog, well, I expect the log to contain the function name for me to
maintain faster.
That's really not the expectation for Linux log messages - the
On Fri, Aug 06, 2010 at 08:10:44AM -0500, Nishanth Menon wrote:
a) when the strings are split up when they go multiple lines:
E.g.:
abcd
efg
print comes out abcd efg
That's generally considered bad practice for precisely this reason.
c) time required:
$ time git grep DEBUG
On Fri, Aug 06, 2010 at 08:37:52AM -0500, Nishanth Menon wrote:
Interesting, I see better performance than that, especially hot cache,
and of course an educated guess as to where to look helps greatly.
tell me about it.. ;) mebbe I can use this thread to get a machine
upgrade budget :P.. but
On Thu, Aug 12, 2010 at 01:39:38AM +0530, kishore kadiyala wrote:
If the LDO is fixed voltage source from TWL then since regulator
framework supports only adjustable LDO's, I think you can
The regulator framework supports fixed voltage regulators just fine.
--
To unsubscribe from this list:
: Kevin Hilman khil...@deeprootsystems.com
Cc: Ben Dooks ben-li...@fluff.org
Also Cc'ing Mark Brown as original author of runtime PM for i2-core.
Also Jean Delvare who maintains the I2C core. To be honest Rafael did
all the actual work here (and has since rewritten the code anyway
On Fri, Sep 03, 2010 at 09:41:11AM -0700, Kevin Hilman wrote:
Like you, I'm no expert on the regulator framework internals, but it
appears to have a pretty thorough system of constraints management that
upon first glance seems to be a good fit for what we need. It may need
to be extended,
On Fri, Sep 03, 2010 at 11:00:31AM -0700, Kevin Hilman wrote:
Mark Brown broo...@opensource.wolfsonmicro.com writes:
The only thing I can think you might need to do if this is just straight
voltage setting is re-add support for multiple consumers setting
voltages simultaneously
Yeah
On Fri, Sep 03, 2010 at 11:27:50AM -0700, Kevin Hilman wrote:
In the background Thomas and I will continue to research the changes
needed in the regulator framework.
These really are fairly straightforward, the algorithm I outlined in my
last mail will do the trick.
--
To unsubscribe from this
On Mon, Sep 06, 2010 at 10:59:05PM +0300, Eduardo Valentin wrote:
On Fri, Sep 03, 2010 at 08:20:52PM +0200, Mark Brown wrote:
Essentially all that needs doing is that when regulator_set_voltage() is
called instead of merging with the machine constraints and applying the
setting immediately
On Tue, Sep 07, 2010 at 05:16:44PM +0530, Premi, Sanjeev wrote:
ts-reg = regulator_get(spi-dev, vcc);
This regulator isn't defined for omap3evm. And I suspect - once
defined - the name will be different than vcc.
What makes you say this? The names for regulator supplies are defined
in terms
On Tue, Sep 07, 2010 at 03:16:21PM +0300, Igor Grinberg wrote:
I think, this can help:
http://www.spinics.net/lists/arm-kernel/msg94759.html
Seems like there were not enough interest and it is still floating.
May be a little ping can help ;)
This is a really bad idea unless the supplies
On Tue, Sep 07, 2010 at 06:56:47PM +0530, Premi, Sanjeev wrote:
From: linux-input-ow...@vger.kernel.org
[mailto:linux-input-ow...@vger.kernel.org] On Behalf Of Mark Brown
What makes you say this? The names for regulator supplies are defined
in terms of the chip being supplied
On Wed, Sep 08, 2010 at 08:53:43AM +0530, G, Manjunath Kondaiah wrote:
This patch fixes sparse warning due non declaration of static function
sound/soc/omap/omap-mcbsp.c:783:5: warning: symbol 'omap_mcbsp_st_info_volsw'
was not declared. Should it be static?
Acked-by: Mark Brown broo
On Thu, Sep 16, 2010 at 08:29:33PM -0500, Nishanth Menon wrote:
+struct opp_def {
+ unsigned long freq;
+ unsigned long u_volt;
+
+ bool enabled;
+};
It might be clearer to use some term other than enabled in the code -
when reading I wasn't immediately sure if enabled meant
On Fri, Sep 17, 2010 at 10:53:06AM -0500, Nishanth Menon wrote:
Mark Brown had written, on 09/17/2010 10:36 AM, the following:
It might be clearer to use some term other than enabled in the code -
when reading I wasn't immediately sure if enabled meant that it was
available to be selected
On Fri, Sep 17, 2010 at 05:37:06PM -0700, Kevin Hilman wrote:
[trimmed Cc list a bit, as vger bounced my last reply due to header too long]
Mark Brown broo...@opensource.wolfsonmicro.com writes:
The enable/disable thing wasn't so noticable in the API itself, it was
in the data structures
On Fri, Sep 17, 2010 at 07:45:43PM +0300, Phil Carmody wrote:
On 17/09/10 17:36 +0200, ext Mark Brown wrote:
It might be clearer to use some term other than enabled in the code -
when reading I wasn't immediately sure if enabled meant that it was
available to be selected
jhnik...@gmail.com
Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com
--
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
boards.
Signed-off-by: Jarkko Nikula jhnik...@gmail.com
Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com
--
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
On Tue, Sep 28, 2010 at 08:25:24AM +0800, Ming Lei wrote:
2010/9/27 Samuel Ortiz sa...@linux.intel.com:
Wouldn't converting your twl4030_irq_thread() to the threaded IRQ framework
fix that problem ?
IRQ_DISABLED flag is set by disable_irq_nosync called from PIH handler,
then thread
On Tue, Sep 28, 2010 at 01:01:32PM +0800, Ming Lei wrote:
2010/9/28 Mark Brown broo...@opensource.wolfsonmicro.com:
Have you raised this issue with the genirq guys? This sounds like
something that the core infrastructure should be able to cope with.
Even genirq guys can help us to convert
On Sat, Oct 02, 2010 at 02:00:11AM +0530, Anand Gadiyar wrote:
Commit f0fba2ad1b6 (ASoC: multi-component - ASoC
Multi-Component Support) in linux-next as of 20101001
broke omap builds with the following errors.
Acked-by: Mark Brown brooo...@opensource.wolfsonmicro.com
since it fixes build
Nikula jhnik...@gmail.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Tony Lindgren t...@atomide.com
Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com
--
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
On Wed, Oct 06, 2010 at 07:48:07AM -0700, Tony Lindgren wrote:
OK, let's do that then we should still have some time left before the
merge window.
Mark Liam, care to ack as well?
Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com
--
To unsubscribe from this list: send the line
CONFIG_SND_OMAP_SOC_MCPDM is defined. Fix this.
Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com
--
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 Fri, Oct 15, 2010 at 09:51:09AM +0300, Jarkko Nikula wrote:
So things can get complicated if trying to implement generic transfer
API to general purpose block like McBSP compared to some dedicated
block where transfer setup is always more or less the same.
I tend to agree. Experience with
On Tue, Nov 02, 2010 at 02:14:13AM +0200, Felipe Contreras wrote:
config REGULATOR_TWL4030
bool TI TWL4030/TWL5030/TWL6030/TPS695x0 PMIC
depends on TWL4030_CORE
+ default y
help
This driver supports the voltage regulators provided by
this family of
On Tue, Nov 02, 2010 at 04:02:18PM +0200, Felipe Contreras wrote:
On Tue, Nov 2, 2010 at 3:11 PM, Mark Brown
This default is not suitable for non-OMAP platforms, it should be
conditional on OMAP or something if we're going to do this (though
generally we handle this with defconfigs rather
On Tue, Nov 02, 2010 at 04:18:18PM +0200, Felipe Contreras wrote:
2010/11/2 Uwe Kleine-König u.kleine-koe...@pengutronix.de:
Well, all platforms that have TWL4030_CORE will get REGULATOR_TWL4030 by
default, too. (TWL4030_CORE doesn't depend on something omapish.)
Yes, I think TWL4030_CORE
functionality
doesn't
optimize out all omap2 specific stuff. This breaks linking phase for omap1
machines, giving undefined reference to `omap2_mcbsp1_mux_clkr_src'
and undefined reference to `omap2_mcbsp1_mux_fsr_src' errors. Fix it.
Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com
On Tue, Nov 02, 2010 at 09:43:30PM +0200, Felipe Contreras wrote:
On Tue, Nov 2, 2010 at 4:35 PM, Mark Brown
This solution doesn't seem like it scales so well either, it just shifts
it into the Kconfig files (where everything is all in central files
shared by everyone which has its own
On Tue, Nov 02, 2010 at 09:46:47PM +0200, Felipe Contreras wrote:
On Tue, Nov 2, 2010 at 4:39 PM, Mark Brown
It did originally but that dependency was removed to allow build
coverage for non-OMAP users.
I'm not sure removing that dependency is worth it. There's probably a
lot of code
On Wed, Nov 24, 2010 at 10:45:44AM +0100, Thomas Petazzoni wrote:
I went ahead and implemented this (without looking at previous existing
code since I couldn't find it). What about the following patch ?
That's pretty much exactly what the old code did - told you it was
trivial :)
--
To
On Wed, Nov 24, 2010 at 03:20:48PM +0800, Axel Lin wrote:
Return PTR_ERR(omap3pandora_dac_reg) instead of 0 if regulator_get failed.
Signed-off-by: Axel Lin axel@gmail.com
Applied, thanks.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
On Thu, Nov 25, 2010 at 03:28:10AM +0100, Laurent Pinchart wrote:
+Links have flags that describe the link capabilities and state.
+ MEDIA_LINK_FLAG_ACTIVE indicates that the link is active and can be
+ used to transfer media data. When two or more links target a sink pad,
+ only
On Thu, Nov 25, 2010 at 10:38:05AM +0100, Clemens Ladisch wrote:
In USB and HD audio devices, all links are immutable, and the routing
is controlled by 'selector' entities that activate exactly one of their
input pads. In userspace, this entity shows up as a mixer control.
I guess it would
On Thu, Nov 25, 2010 at 03:28:12AM +0100, Laurent Pinchart wrote:
If the entity is of node type, the power change is distributed to
all connected entities. For non-nodes it only affects that very
node. A mutex is used to serialise access to the entity graph.
ASoC has its own
On Thu, Nov 25, 2010 at 03:28:16AM +0100, Laurent Pinchart wrote:
Link states must not be modified while streaming is in progress on a
graph they belong or connect to. The entity locking API helps drivers
enforcing that requirement.
This is not desirable for embedded audio - for example, it is
On Thu, Nov 25, 2010 at 03:28:07AM +0100, Laurent Pinchart wrote:
I want to emphasize that the media controller API does *not* replace the V4L,
DVB or ALSA APIs. It complements them.
Overall this looks relatively good and should be mappable onto the
embedded audio stack. I'd need to sit down
On Thu, Nov 25, 2010 at 04:21:38PM +0100, Laurent Pinchart wrote:
On Thursday 25 November 2010 10:38:05 Clemens Ladisch wrote:
ALSA has PCM and MIDI devices, and several types of mixer controls.
(It also has hardware dependent and timer devices, but I don't think
these would need topology
On Thu, Nov 25, 2010 at 04:29:53PM +0100, Laurent Pinchart wrote:
It depends on how you define nodes. I can certainly imagine a graph with 100
controls, but maybe several controls can be part of the same node ? On the
video side we've decided to split entities depending on the possible data
On Thu, Nov 25, 2010 at 05:52:23PM +0200, Srikar wrote:
+static struct regulator_consumer_supply rx51_vdac_supply[] = {
+ {
+#if defined(CONFIG_FB_OMAP2) || defined(CONFIG_FB_OMAP2_MODULE)
The ifdefs here aren't really saving much...
+ .supply = vdda_dac,
+ .dev
On Thu, Nov 25, 2010 at 07:49:05PM +0200, Sakari Ailus wrote:
Currently when two media entities are connected they will be powered up
for the duration of the link setup, just in case the drivers would need
to access hardware for some reason. I don't think we have a need for
that at the
On Wed, Nov 24, 2010 at 10:24:01PM +0800, Axel Lin wrote:
In current implementation, there are resources leak in the error path.
This patch properly reclaims the allocated resources in the error path.
Also adds a missing clk_put in osk_soc_exit.
Signed-off-by: Axel Lin axel@gmail.com
On Fri, Nov 26, 2010 at 11:56:35AM +0200, Srikar wrote:
On 11/25/2010 06:11 PM, ext Mark Brown wrote:
On Thu, Nov 25, 2010 at 05:52:23PM +0200, Srikar wrote:
+static struct regulator_consumer_supply rx51_vdac_supply[] = {
+ {
+#if defined(CONFIG_FB_OMAP2) || defined
On Fri, Nov 26, 2010 at 03:13:36PM +0100, Laurent Pinchart wrote:
On Thursday 25 November 2010 16:49:52 Mark Brown wrote:
On Thu, Nov 25, 2010 at 04:40:41PM +0100, Laurent Pinchart wrote:
It's supposed to reflect whether the link can carry data. Think of the
active flag as a valve
On Fri, Nov 26, 2010 at 09:45:17AM -0800, Tony Lindgren wrote:
By the way, all the board specific data should be __initdata eventually.
Now we're hogging memory for the regulators for all the boards compiled in..
Yeah. Some of it will need to be __devinitdata for hotpluggable things
but most
On 28 Nov 2010, at 12:33, Laurent Pinchart wrote:
Throwing an idea here, what about making power management modular ? The MC
core would then call back to drivers to handle use count changes. The
media_entity_use_change() function would be exported (and renamed), so that
drivers could use
On Mon, Nov 29, 2010 at 10:18:31AM -0800, Tony Lindgren wrote:
* Mark Brown broo...@opensource.wolfsonmicro.com [101127 02:10]:
Yeah. Some of it will need to be __devinitdata for hotpluggable things
but most of it should be __initdata. I'll update the regulator API to
copy
On Fri, Dec 03, 2010 at 02:50:58PM +0100, Laurent Pinchart wrote:
On Friday 03 December 2010 13:06:18 Hans Verkuil wrote:
Just to confirm thinks, Mark's proposal is to replace 'connected' by
'linked' and 'active' by 'connected'. Are we on the same page here ?
Yes, but when I read it
}2xxx_3xxx.{c,h}, since it was
OMAP2xxx/3xxx-specific.
Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com
--
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
On Tue, Dec 07, 2010 at 06:13:35PM +0100, Hans Verkuil wrote:
Personally I think this is perfectly clear. The original confusion came from
the word 'active', which I understand means 'streaming' in alsa. By adding
a 'streaming' flag in addition to the active flag I think it will be clear
that
On Tue, Dec 07, 2010 at 07:11:39PM +0100, Hans Verkuil wrote:
Ah, now I understand what you mean. Would 'activated' be better than 'active'?
Better, yes, though it still sounds a bit like something should be
actively (IYSWIM) happening. In the absence of better ideas I could go
with this.
On Mon, Dec 27, 2010 at 10:17:04PM -0600, David Lambert wrote:
Adds the OMAP DMIC driver and codec to the build.
Signed-off-by: David Lambert dlamb...@ti.com
---
sound/soc/codecs/Kconfig |3 +++
sound/soc/codecs/Makefile |2 ++
sound/soc/omap/Kconfig|5 +
On Mon, Dec 27, 2010 at 10:17:02PM -0600, David Lambert wrote:
+ case 1920:
+ if (div == 5)
+ div_sel = 0x1;
+ else if (div == 8)
+ div_sel = 0x0;
+ break;
A switch statement for the valid div values would
On Mon, Dec 27, 2010 at 10:17:03PM -0600, David Lambert wrote:
At this time, the codec driver just registers the codec DAI.
If it's doing more than that it's going to be a separate driver anyway I
expect.
+static struct snd_soc_dai_driver dmic_dai = {
+ .name = dmic-hifi,
+ .capture
On Tue, Dec 28, 2010 at 03:59:49PM +0200, Felipe Balbi wrote:
+ disable_irq_nosync(irq);
You shouldn't need this any more; the driver used to be faffing around
with this because it wasn't using genirq for this in the past.
+ for (i = 0; sts.int_sts; sts.int_sts = 1, i++) {
+
On Tue, Dec 28, 2010 at 07:36:04PM +0200, Felipe Balbi wrote:
when we finally move to struct irq_data, the below could
be used. BTW, Thomas do you have any plans for exposing
irq_data_to_desc() ?
The general idea is to move to struct irq_data sooner rather than later
(all the existing MFD
On Tue, Dec 28, 2010 at 09:40:03AM -0800, David Brownell wrote:
What I'd expect to see from a conversion like this would be
that most of
the locking/IRQ management stuff would be dropped
I'd expect that genirq solve all the issues and
that its support be used. That's not the same
as
On Tue, Dec 28, 2010 at 07:14:19PM +0200, Felipe Balbi wrote:
+static void twl4030_sih_bus_sync_unlock(unsigned int irq)
+{
+ struct sih_agent*agent = get_irq_chip_data(irq);
+
+ mutex_unlock(agent-irq_lock);
+}
I suspect you need to do some sort of sync with the
On Wed, Dec 29, 2010 at 11:52:51AM +, Liam Girdwood wrote:
In this case though the other McBSP user afaik is DaVinci, so in this
case it does make sense to make this driver support both.
The other thing with McBSP is that it's a generic programmable serial
port and so need not be tied to
On Wed, Dec 29, 2010 at 01:59:24PM +0200, Felipe Balbi wrote:
On Wed, Dec 29, 2010 at 11:56:28AM +, Mark Brown wrote:
The other thing with McBSP is that it's a generic programmable serial
port and so need not be tied to audio use (though as I understand it
other uses are very rare).
So
On Wed, Dec 29, 2010 at 02:28:08PM +0200, Felipe Balbi wrote:
I believe you meant something like below, I'll get back to this in a
little while. Have lots to test:
Yes, that looks like what I'd expect.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a
On Wed, Jan 05, 2011 at 07:56:13AM -0600, Lambert, David wrote:
On Tue, Dec 28, 2010 at 8:18 AM, Mark Brown
A comment explaining why we don't actually do anything with the request
would be helpful. Given that we're ignoring the event it'd seem better
to just leave it masked and not take
On Thu, Jan 06, 2011 at 09:26:40AM +0530, Keerthy wrote:
---
drivers/hwmon/Kconfig| 11 +
drivers/hwmon/Makefile |1 +
drivers/hwmon/twl4030-madc.c | 794
++
include/linux/i2c/twl4030-madc.h | 118 ++
4 files
On Wed, Jan 05, 2011 at 09:33:28PM -0800, Guenter Roeck wrote:
[...]
+EXPORT_SYMBOL_GPL(twl4030_madc_conversion);
[...]
+EXPORT_SYMBOL_GPL(twl4030_get_madc_conversion);
No symbol export from hwmon drivers. Other parts of the kernel
should not depend on HWMON configuration.
Why? It's
On Thu, Jan 06, 2011 at 07:04:30AM -0800, Guenter Roeck wrote:
On Thu, Jan 06, 2011 at 07:07:13AM -0500, Mark Brown wrote:
Why? It's not like hwmon has an unreasonably large core or similar.
Because it creates an unnecessary dependency, and because it is not hwmon's
responsibility
On Thu, Jan 06, 2011 at 08:00:36AM -0600, David Lambert wrote:
@@ -103,6 +106,7 @@ config SND_OMAP_SOC_SDP4430
depends on TWL4030_CORE SND_OMAP_SOC MACH_OMAP_4430SDP
select SND_OMAP_SOC_MCPDM
select SND_SOC_TWL6040
+ select SND_SOC_DMIC
help
Say Y if
database allows
for more generic drivers to be written and having the specific
implementation details defined in HWMOD.
Signed-off-by: David Lambert dlamb...@ti.com
Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap
On Thu, Jan 06, 2011 at 08:00:39AM -0600, David Lambert wrote:
This creates the DMIC codec platform devices.
The platform devices create an instance of the driver during boot up.
Signed-off-by: David Lambert dlamb...@ti.com
Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com
though
On Fri, Jan 07, 2011 at 02:55:45PM +0530, J, KEERTHY wrote:
On Thu, Jan 6, 2011 at 5:34 PM, Mark Brown
On Thu, Jan 06, 2011 at 09:26:40AM +0530, Keerthy wrote:
+static ssize_t madc_read(struct device *dev,
+ struct device_attribute *devattr, char *buf
On Fri, Jan 07, 2011 at 10:34:53AM -0600, Lambert, David wrote:
On Thu, Jan 6, 2011 at 4:20 PM, Mark Brown
I suggested switch statements previously; you didn't comment on my
reply.
Sorry... my personal standard on when to go with a switch statement is
2 choices,
I'll change it over
On Thu, Jan 06, 2011 at 10:10:03PM +0530, Santosh Shilimkar wrote:
ads7846 spi1.0: unable to get regulator: -19
Is something missing from the ldp support code to declare this
regulator?
Am not sure what is connected to SPI on LDP. But mostly
not an important peripheral.
As the log
...@ti.com
Cc: Jarkko Nikula jhnik...@gmail.com
Cc: Peter Ujfalusi peter.ujfal...@nokia.com
Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com
--
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
On Tue, Feb 01, 2011 at 07:53:26PM +0200, Jarkko Nikula wrote:
Mark, Liam: is it ok if the 12/13 goes together with rest of the set
via linux-omap when ready?
I already acked it.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
On Wed, Feb 02, 2011 at 05:00:13PM +0530, archit taneja wrote:
How can I implement regulator_enable/disable calls in my driver for a
consumer of vcxio without disturbing the mpu and iva etc consumers which
don't use regulator api to enable/disable the regulator at all.
Set the regulator
On Wed, Feb 09, 2011 at 09:07:25PM +0530, Balaji T K wrote:
- TWL6030_FIXED_LDO(VUSB, 0x70, 3300, 18, 0, 0x21)
+ TWL6030_FIXED_LDO(VUSB, 0x70, 3300, 18, 0, 0x21),
+ TWL6030_FIXED_LDO(CLK32KG, 0x8C, 1000, 48, 0, 0x21),
It'd seem better to implement a version of this that just
On Wed, Feb 09, 2011 at 09:07:31PM +0530, Balaji T K wrote:
+ .constraints = {
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE
+
On Mon, Jan 11, 2010 at 02:55:18PM +0530, Anuj Aggarwal wrote:
Adding member variables for USB internal LDOs in twl4030_platform_data
and registering them in twl-core.c if the variables are populated
from board-evm file.
Signed-off-by: Anuj Aggarwal anuj.aggar...@ti.com
Acked-by: Mark Brown
On Fri, Jan 08, 2010 at 11:27:28PM +0530, Anuj Aggarwal wrote:
Based on the discussions and feedback received, this patch set is
created which cleans up various OMAP3-board-evm files and removes
common TWL4030 specific regulator suuplies and init data structs.
Please use an OMAP-specific
On Fri, Jan 08, 2010 at 11:27:53PM +0530, Anuj Aggarwal wrote:
Removing the common supplies and regulator init data structs for various
OMAP3 platforms. They all have been moved to a common TWL4030 specific file
and will be referenced from there.
Signed-off-by: Anuj Aggarwal
On Fri, Jan 08, 2010 at 11:27:43PM +0530, Anuj Aggarwal wrote:
A new file for TWL4030/TPS65950 is created which has common supplies
and regulator init data structures. They will be referenced from the
various board-evm files depending upon the EVM requirements.
Signed-off-by: Anuj Aggarwal
On Fri, Jan 08, 2010 at 11:28:06PM +0530, Anuj Aggarwal wrote:
+config PMIC_TWL4030
+ bool TWL4030/TPS65950 Power Module
+ default y
+ depends on TWL4030_CORE MACH_OMAP3EVM
+ select REGULATOR_TWL4030 if REGULATOR
+ help
+ Say yes here if you are using the
On Tue, Jan 12, 2010 at 09:35:15PM +0530, Aggarwal, Anuj wrote:
b) same command, when audio loopback is running in
background
It'd be helpful to specify what you mean by audio loopback here - I
think you mean something along the lines of 'arecord | aplay -' but
it'd be good to confirm since
)
but both of those could be fixed up later. Otherwise it all looks OK
from a regulator point of view
Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com
--
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
On Tue, Jan 19, 2010 at 01:42:31PM -0800, Joe Perches wrote:
Maybe a standard #define WATCHDOG_NAME foo
.identity = WATCHGOD_NAME
I don't really see that the indrection via the #define would buy us
anything?
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of
On Fri, Jan 22, 2010 at 05:14:48PM -0600, Candelaria Villareal, Jorge wrote:
McPDM module is the interface between the OMAP and TWL6030 audio codec.
The interface supports the following:
* Up to 5 downlink channels and 3 uplink channels
* 88.2 and 96 KHz
* 32 bit sample size
Liam already
On Mon, Jan 25, 2010 at 03:06:27PM -0600, Candelaria Villareal, Jorge wrote:
Liam Girdwood wrote:
What does this do and why is it not static ?
It enables and configures offset cancelation for the analog headset path. It
is supposed to be called by the codec driver, so it should'nt be
On Mon, Jan 25, 2010 at 11:06:55PM -0800, David Brownell wrote:
On Monday 14 December 2009, Felipe Balbi wrote:
move twl4030 children to threaded irq.
But nothing in drivers/mfd ... the entry to the whole stack?
Did the threaded IRQ stuff ever get set up so that the top
level IRQ thread
On Tue, Jan 26, 2010 at 03:16:20AM -0800, David Brownell wrote:
I'd vote to convert all the USB-to-charger interfaces so
they use notifiers. After fixing the events ... see
comments below. :)
Yes please - it's not just chargers either, this can also be used by
PMICs which do power path
On Tue, Jan 26, 2010 at 05:35:21AM -0800, David Brownell wrote:
On Tuesday 26 January 2010, Mark Brown wrote:
Yes please - it's not just chargers either, this can also be used by
PMICs which do power path management that includes USB.
Color me confused ... what do you mean by power path
On Tue, Jan 26, 2010 at 07:44:46AM -0800, David Brownell wrote:
On Tuesday 26 January 2010, Mark Brown wrote:
In the sort of design I'm talking about there is generally a system
power rail which is generated from the various power sources available
to the system, which might include
On Fri, Jan 29, 2010 at 01:58:55PM +0530, Anuj Aggarwal wrote:
Commit e9ff5eb2 (Fixing infinite loop in resume path) uses wrong AIC23
register in resume function because of which register writes happen
on some non-existing registers.
Signed-off-by: Anuj Aggarwal anuj.aggar...@ti.com
On Fri, Jan 29, 2010 at 03:49:22PM +0530, Anuj Aggarwal wrote:
Commit 761c9d45 (ASoC: Fix build of OMAP sound drivers) changes
CONFIG_MACH_OMAP3517EVM - CONFIG_SND_OMAP_SOC_OMAP3517EVM in the
Makefile. Whereas the config option defined in Kconfig is
SND_OMAP_SOC_AM3517EVM. Because of this,
On Thu, Feb 04, 2010 at 05:08:11PM +0200, Mike Rapoport wrote:
Mark Brown wrote:
This should not be required. The regulator API stubs itself out when it
is not built so all API calls report as successful.
And what about boards that have the ads7846 tied to power rail and still
want
On Thu, Feb 04, 2010 at 04:52:26PM +0200, Grazvydas Ignotas wrote:
On Thu, Feb 4, 2010 at 4:24 PM, Mark Brown
The updates to fix up the boards that need this are fairly
straightforward and given that it's fairly easy to identify systems
which are using the driver in mainline so I'd really
On 4 Feb 2010, at 18:08, Dmitry Torokhov dmitry.torok...@gmail.com
wrote:
On Thu, Feb 04, 2010 at 04:21:55PM +, Mark Brown wrote:
On Thu, Feb 04, 2010 at 04:52:26PM +0200, Grazvydas Ignotas wrote:
On Thu, Feb 4, 2010 at 4:24 PM, Mark Brown
The updates to fix up the boards that need
On Fri, Feb 05, 2010 at 10:45:09PM +0200, Mike Rapoport wrote:
On Thu, Feb 4, 2010 at 6:21 PM, Mark Brown
The bodge I'm thinking of would do something like log an error and
substitute in a dummy regulator when regulator_get() would have failed
so that the driver sees behaviour equivalent
On Wed, Feb 10, 2010 at 02:07:04PM -0500, Peter Barada wrote:
I've got a OMAP3530 board with a tsc2004 touch controller that is
powered off of VAUX1(VAUX1_30 on my schematic) at 3V, and I'm trying to
understand how to code it up so that vaux1 power comes up before the i2c
code tries to probe
On Thu, Feb 11, 2010 at 01:14:18PM +0200, Jarkko Nikula wrote:
Yeah, after thinking twice, we don't have zillions of options for e.g.
Intel HDA either. If we ever figure out some common OMAP+TWL4030
driver, the defconfigs are anyway have to modify so it's better stay
with the original patch:
1 - 100 of 1422 matches
Mail list logo
