Re: [PATCH 1/3] ASoC: OMAP: HDMI: Update machine driver name
On 14/11/12 02:30, Ricardo Neri wrote: Being the name of a machine driver, it aims to describe the connection between the HDMI IP of the processor and the companion chip it uses to connect to the outside world. This name tries to follow the same naming convention as in the OMAP-ABE-TWL6040 machine driver. TPD12S015 is an HDMI companion chip for DC-DC step-up, I2C level shifter and low-capacitance ESD protection. This chip is used on all OMAP4 Pandaboards an SDPs as well as in OMAP5 EVMs. Is the TPD12S015 passive or actively controlled by the CPU in this case ? If it's passive then it's not really worth changing the driver name since other OMAP4/5 devices may use other HDMI companion chips (an we can reuse this driver without changes). Liam -- 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
[RFC 1/3] ASoC: dmaengine: Don't use runtime private data for dmaengine data
Use a dedicated member to store dmaengine data so that drivers can
use private data for their own purposes.
Signed-off-by: Liam Girdwood l...@ti.com
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
include/sound/pcm.h |2 ++
sound/soc/soc-dmaengine-pcm.c |2 +-
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/include/sound/pcm.h b/include/sound/pcm.h
index cdca2ab..f9e4909 100644
--- a/include/sound/pcm.h
+++ b/include/sound/pcm.h
@@ -269,6 +269,7 @@ struct snd_pcm_hw_constraint_list {
};
struct snd_pcm_hwptr_log;
+struct dmaengine_pcm_runtime_data;
struct snd_pcm_runtime {
/* -- Status -- */
@@ -345,6 +346,7 @@ struct snd_pcm_runtime {
unsigned char *dma_area;/* DMA area */
dma_addr_t dma_addr;/* physical bus address (not accessible
from main CPU) */
size_t dma_bytes; /* size of DMA area */
+ struct dmaengine_pcm_runtime_data *dmaengine_data;
struct snd_dma_buffer *dma_buffer_p;/* allocated buffer */
diff --git a/sound/soc/soc-dmaengine-pcm.c b/sound/soc/soc-dmaengine-pcm.c
index 5df529e..27fa5ad 100644
--- a/sound/soc/soc-dmaengine-pcm.c
+++ b/sound/soc/soc-dmaengine-pcm.c
@@ -40,7 +40,7 @@ struct dmaengine_pcm_runtime_data {
static inline struct dmaengine_pcm_runtime_data *substream_to_prtd(
const struct snd_pcm_substream *substream)
{
- return substream-runtime-private_data;
+ return substream-runtime-dmaengine_data;
}
/**
--
1.7.4.4
--
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
Re: Audio support on OMAP 3430LDP or 4430SDP boards
On Fri, 2012-04-27 at 19:45 +0530, Shilimkar, Santosh wrote: + Peter and Liam to comment On Fri, Apr 27, 2012 at 7:28 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: Can someone please hint on what audio is supported on these two OMAP boards? From what I can tell, the answer is either nothing or hdmi, both of which are useless to me if someone wants me to convert the OMAP ASoC driver to DMA engine. From what I can see on the 4430SDP, there's a 3.5mm headset jack, microphones and speakers on the board, so the board does have audio hardware. However, it seems (as, I'm afraid to say, seems to be pretty much standard practice with OMAP) there's a total lack of software support in mainline. This kind'a prevents me testing changes to the DMA support for OMAP ASoC... What can be done to remedy this situation? Peter now has has the final patches for Legacy mode (i.e. without ABE) now upstream in 3.4-rc. Legacy mode gives a direct SDMA - McPDM - twl6040 audio path so would be a good starting point for DMA testing. Regards Liam -- 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
Re: [PATCH v2] ASoC: omap-pcm: Free dma buffers in case of error.
On Tue, 2012-04-24 at 19:02 -0700, Oleg Matcovschi wrote: Change-Id: I4ba9de0de4681332539246ccc5e11a7a8fb32e79 Signed-off-by: Oleg Matcovschi oleg.matcovs...@ti.com --- v1: initial revision v2: resending patch including maintainers sound/soc/omap/omap-pcm.c |4 1 files changed, 4 insertions(+), 0 deletions(-) Now applied for 3.4 with change ID removed. Thanks Liam -- 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
Re: [RFC 04/11] ASoC: core - Add API call to register dai kcontrols.
On Wed, 2012-02-15 at 17:37 +0200, Peter Ujfalusi wrote: Allow dai drivers to register kcontrols. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- include/sound/soc.h |2 ++ sound/soc/soc-core.c | 31 +++ 2 files changed, 33 insertions(+), 0 deletions(-) This feature has already been applied. Regards Liam -- 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
Re: [PATCH v2 4/4] ASoC: OMAP: ams-delta: drop .set_bias_level callback
On Fri, 2011-12-30 at 04:04 +0100, Janusz Krzysztofik wrote: This functionality has just been implemented in the cx20442 codec driver, no need to keep it here duplicated. Once done, remove the no longer used AMS_DELTA_LATCH2_MODEM_NRESET symbol from the board header file and a call to the regulator_toggle() helper function from the old API wrapper found in the board file. While being at it, simplify the way the modem .pm callback handles the regulator, and drop that no longer used helper function and its related consumer setup elements completely. Depends on patch 3/4 ARM: OMAP1: ams-delta: update the modem to use regulator API Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl --- Changes against initial version: * don't move consumer setup elements, now named to indicated their modem related purpose, down the file, * don't track the regulator enavble/disable state, compare new target power state with the old one instead; thanks to Mark Brown for suggesting this simplification, * actually drop all references to AMS_DELTA_LATCH2_MODEM_NRESET. arch/arm/mach-omap1/board-ams-delta.c | 42 +++- arch/arm/plat-omap/include/plat/board-ams-delta.h |1 - sound/soc/omap/ams-delta.c| 32 3 files changed, 7 insertions(+), 68 deletions(-) I tried to apply against ASoC but it failed with the omap files. It may be better for this patch to go via Tony. 2/4 applies and builds ok, but if there is a runtime dependency on the rest it should go via Tony too. Thanks Liam -- 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
Re: [PATCH v2 1/9] include: platform_data: Platform data header for OMAP4 ASoC audio
On Thu, 2011-12-22 at 13:04 +, Mark Brown wrote: On Thu, Dec 22, 2011 at 02:42:40PM +0200, Peter Ujfalusi wrote: include/linux/platform_data/omap-abe-twl6040.h | 48 omap-abe-mcpdm-twl6040 please. Seriously, just drop the abe - it's not an optional feature of the OMAP and the names are getting quite long. ABE can be an optional feature on OMAP (and quite an important one when it is used). Fwiw, we do have a mixture of users, most use the ABE but some don't, so it's best to specify ABE in the naming to avoid any confusion. This patch looks fine to me. Regards Liam -- 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
Re: [PATCH 00/10] OMAP4: ASoC: Support for PandaBoard family
On Wed, 2011-12-14 at 11:46 +0200, Peter Ujfalusi wrote: Hello, the following series will add ASoC support for PandaBoards. PandaBoards have different audio routings compared to SDP4430/Blaze boards, but the differences not that big to justify a new ASoC machine driver. Main changes: - Rename the sdp4430 ASoC machine driver to use generic name: omap-abe-twl6040 - Convert the ASoC machine driver to platform driver - The type of the board, and the desired sound card name is passed via platform data to the ASoC machine driver - Based on the board type the driver selects different audio routings - Registration of the needed platform devices in board files (sdp4403, panda) After this series the sound card names will be different for easier UCM integration: OMAP4-SDP4430 for SDP4430/Blaze boards OMAP4-Panda for PandaBoard 4430 OMAP4-PandaES for PandaBoard ES (4460) 1,2,3 Applied. 5 8 depend on the others so best to resend with Acks if unchanged. Thanks Liam -- 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
Re: [PATCH 07/10] ASoC: OMAP: ams-delta: Drive modem/codec pins over GPIO API
On Sun, 2011-12-11 at 21:12 +0100, Janusz Krzysztofik wrote: Don't use Amstrad Delta custom I/O functions any longer, replace them with GPIO. Old pin definitions, no longer used by the modem bits either, can be dropped. Depends on patch 2/10 ARM: OMAP1: Convert Amstrad E3 latches to basic_mmio_gpio. Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl Applied. Thanks Liam -- 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
Re: [alsa-devel] [PATCH 0/3] ASoC: tpa6130a2: model handling cleanup
On Tue, 2011-09-13 at 13:27 +0100, Mark Brown wrote: On Tue, Sep 13, 2011 at 03:11:41PM +0300, Péter Ujfalusi wrote: Would you have time to take a look at this series (it got the Tested-by from Jarkko)? I'm fine with it, I'm waiting for Liam's review. Acked-by: Liam Girdwood l...@ti.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
Re: [PATCHv4 2/4] regulator: omap smps regulator driver
On 22/08/11 23:39, Hilman, Kevin wrote: Liam Girdwood l...@ti.com writes: On 05/08/11 20:33, Hilman, Kevin wrote: Mark Brown broo...@opensource.wolfsonmicro.com writes: On Thu, Jul 28, 2011 at 02:48:57PM +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 voltage regulation operations. Signed-off-by: Tero Kristo t-kri...@ti.com Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com Do you prefer we merge this via OMAP trees (along with the infrastructure) or would you like to merge it. At this point, it's probably best to merge it along with the voltage infrastructure, which still might change slightly at the API level. Ok, lets merge with the voltage infrastructure. OK, shall I take this is an Ack from you then? Kevin Sorry, yes. Acked-by: Liam Girdwood l...@ti.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
Re: [alsa-devel] [PATCH 0/4] ASoC: OMAP4: McPDM: Fix legacy support
On 22/08/11 08:13, Ujfalusi, Peter wrote: On Friday 19 August 2011 15:04:20 Tony Lindgren wrote: It seems OK to me. Thanks! But for the -rc cycle it has potential for fixes for features that never worked flame bait. If you guys are OK to deal with that then go ahead. Hrm, I have not thought about this. Not sure, if we want to go there... Yeah, lets take it for 3.2 Liam -- 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
Re: [PATCHv4 2/4] regulator: omap smps regulator driver
On 05/08/11 20:33, Hilman, Kevin wrote: Mark Brown broo...@opensource.wolfsonmicro.com writes: On Thu, Jul 28, 2011 at 02:48:57PM +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 voltage regulation operations. Signed-off-by: Tero Kristo t-kri...@ti.com Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com Do you prefer we merge this via OMAP trees (along with the infrastructure) or would you like to merge it. At this point, it's probably best to merge it along with the voltage infrastructure, which still might change slightly at the API level. Ok, lets merge with the voltage infrastructure. Thanks Liam -- 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
Re: [RFC 1/4] twl-regulator: extend for SMPS regulators and external controllers
On Fri, 2011-07-08 at 17:56 +0200, Kristo, Tero wrote: This commit adds two things to the TWL regulator driver code : * It extends the twl4030_set_voltage() and twl4030_get_voltage() functions to understand that VDD1 and VDD2 are different regulators from all the other regulators: they don't support a fixed set of voltages, but a wide range of voltages between two minimum and maximum limits. * It creates a twlreg_ext_ctrl structure, which allows code outside of the TWL regulator driver to implement a regulator controller. Such a controller is attached using the new twlreg_attach_external_controller() function of the driver. When such a controller is attached to a regulator, the -set_voltage() and -get_voltage() calls made on the regulator will be forwarded to the external controller. This facility will later be used to integrate the Voltage Controller and SmartReflex features of the OMAP CPU with this regulator driver. This just looks like it should just be another regulator to me. The board will be responsible for setting up the client mapping (i.e. whether it should use the extended or normal regulator). Fwiw, Graeme has already done a lot of work on supporting Smartreflex with TWL6025, it may be best to contact him to align your work. Liam -- 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
Re: [PATCH 1/3] ASoC: omap-mcpdm: Replace legacy driver
On 07/07/11 16:57, Mark Brown wrote:
On Thu, Jul 07, 2011 at 03:27:50PM +0300, Peter Ujfalusi wrote:
The current McPDM driver design is not suitable to support both
the ABE and Legacy DMA operating modes. Therefore remove most
In what way is it not suitable?
It cant support both the ABE and Legacy DMA modes without adding some
unnecessary and complicated logic. My preference is 1 driver to support both
modes of operation and this is the easiest way to do so (also keeping the
maintenance easier too).
+/*
+ * Enables the transfer through the PDM interface to/from the Phoenix
+ * codec by enabling the corresponding UP or DN channels.
+ */
+static void omap_mcpdm_start(struct omap_mcpdm *mcpdm)
+{
+u32 ctrl = omap_mcpdm_read(mcpdm, MCPDM_REG_CTRL);
+
+ctrl |= (MCPDM_SW_DN_RST | MCPDM_SW_UP_RST);
+omap_mcpdm_write(mcpdm, MCPDM_REG_CTRL, ctrl);
+
+ctrl |= mcpdm-dn_channels | mcpdm-up_channels;
+omap_mcpdm_write(mcpdm, MCPDM_REG_CTRL, ctrl);
+
+ctrl = ~(MCPDM_SW_DN_RST | MCPDM_SW_UP_RST);
+omap_mcpdm_write(mcpdm, MCPDM_REG_CTRL, ctrl);
+}
Presumably this works with any PDM input/output?
Yes.
+/* work to delay McPDM shutdown */
+static void playback_work(struct work_struct *work)
+{
+struct omap_mcpdm *mcpdm = container_of(work,
+struct omap_mcpdm, delayed_work.work);
+
+if (!mcpdm-active omap_mcpdm_active(mcpdm)) {
+omap_mcpdm_stop(mcpdm);
+omap_mcpdm_close_streams(mcpdm);
+}
+
+if (!omap_mcpdm_active(mcpdm))
+pm_runtime_put_sync(mcpdm-dev);
+}
It occurs to me that it'd be much simpler to implement this by doing the
cleanup in your runtime suspend callback, it looks like you're working
around the pm_runtime framework rather than using it. If you need to do
some cleanup when the device goes idle and you can't do it within a
framework designed to suspend the device when it goes idle then there's
an issue there.
Alternatively, why is this deferred?
There are some power, clock and pop dependencies here between the CODEC, ABE
and McPDM interface and this deferred work allows us to shutwdown McPDM (in a
pop free manner) and satisfy the dependencies without causing a data abort
and/or locking the ABE firmware.
Liam
--
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
Re: [PATCH 1/3] ASoC: omap-mcpdm: Replace legacy driver
On 07/07/11 17:53, Mark Brown wrote: On Thu, Jul 07, 2011 at 05:32:42PM +0100, Liam Girdwood wrote: On 07/07/11 16:57, Mark Brown wrote: On Thu, Jul 07, 2011 at 03:27:50PM +0300, Peter Ujfalusi wrote: The current McPDM driver design is not suitable to support both the ABE and Legacy DMA operating modes. Therefore remove most In what way is it not suitable? It cant support both the ABE and Legacy DMA modes without adding some unnecessary and complicated logic. My preference is 1 driver to support both modes of operation and this is the easiest way to do so (also keeping the maintenance easier too). My comment was more that the changelog should say why it's not suitable given that it involves a near total rewrite of the driver which is a pretty big step, I'm fine with the actual change. I guess that the current McPDM driver configures some things that should be moved to the DMA driver? I cant think of anything thing atm that could be moved to DMA driver, McPDM mostly uses ABE for moving PCM data around. It occurs to me that it'd be much simpler to implement this by doing the cleanup in your runtime suspend callback, it looks like you're working around the pm_runtime framework rather than using it. If you need to do some cleanup when the device goes idle and you can't do it within a framework designed to suspend the device when it goes idle then there's an issue there. Alternatively, why is this deferred? There are some power, clock and pop dependencies here between the CODEC, ABE and McPDM interface and this deferred work allows us to shutwdown McPDM (in a pop free manner) and satisfy the dependencies without causing a data abort and/or locking the ABE firmware. Sounds like runtime PM ought to be able to handle this, though? If you need to sync with the ABE can the ABE take PM references to the DAIs it's talking to? I guess the ABE will be happier if everything it's talking to runs for longer than it does. Or the DAI could switch into autosuspend mode when it goes idle to do the delay. It's not that simple in this situation. We also have a PM dependency on the CODEC here too, it supplies our interface clock via the DAI so we have to be very careful how we interact with the ABE and CODEC. The critical thing here is the pop reduction and a subsequent ABE patch will also introduce some hard timing constraints here too. Liam -- 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
Re: [PATCH v4 1/2] REGULATOR: TWL6025: add support to twl-regulator
On 22/05/11 23:48, Mark Brown wrote: 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 broo...@opensource.wolfsonmicro.com Since V1 Use the features variable passed via platform data instead of calling global function. Change histories like this should usually come after the --- so things like git am strip them out of what actually ends up in git. Applied. Thanks Liam -- 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
Re: [PATCH v4 2/2] USB: TWL6025 allow different regulator name
On 22/05/11 23:51, Mark Brown wrote: 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 broo...@opensource.wolfsonmicro.com Acked-by: Liam Girdwood l...@ti.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
Re: [PATCH v4 2/2] USB: TWL6025 allow different regulator name
On 23/05/11 12:13, Balbi, Felipe wrote: Hi, On Mon, May 23, 2011 at 10:58:27AM +0100, Liam Girdwood wrote: On 22/05/11 23:51, Mark Brown wrote: 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 broo...@opensource.wolfsonmicro.com Acked-by: Liam Girdwood l...@ti.com Maybe it's better for you to carry this one Liam. I'm done taking patches for this merge window and this is related to the same series adding support to twl6025. Either that or this will be pending until 2.6.41 merge window. Ok, I've now applied it to regulator. Thanks ! Liam -- 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
Re: [PATCH 1/2] regulator: twl6030: do not write to _GRP for regulator enable
On Sun, 2011-05-22 at 14:50 +0800, Mark Brown wrote: 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 balaj...@ti.com Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com but udelay(info-delay); all these need to be replaced by implementing get_enable_time(). Both Applied. Can you fix this incrementally. Thanks Liam -- 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
Re: [PATCH v2 3/4] REGULATOR: TWL6025: add support to twl-regulator
On Wed, 2011-05-18 at 15:17 +0100, Graeme Gregory wrote:
On 16/05/2011 10:08, T Krishnamoorthy, Balaji wrote:
On Thu, May 12, 2011 at 6:57 PM, Graeme Gregory g...@slimlogic.co.uk
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.
The DCDCs of the 6025 are software controllable as well.
Since V1
Use the features variable passed via platform data instead of calling
global function.
Change the very switch like if statements to be a more readable
switch statement.
Signed-off-by: Graeme Gregory g...@slimlogic.co.uk
---
drivers/regulator/twl-regulator.c | 414
+---
1 files changed, 379 insertions(+), 35 deletions(-)
diff --git a/drivers/regulator/twl-regulator.c
b/drivers/regulator/twl-regulator.c
index 2a808c2..51f28cc 100644
--- a/drivers/regulator/twl-regulator.c
+++ b/drivers/regulator/twl-regulator.c
@@ -51,8 +51,13 @@ struct twlreg_info {
u16 min_mV;
u16 max_mV;
+ u8 flags;
+
/* used by regulator core */
struct regulator_desc desc;
+
+ /* chip specific features */
+ unsigned long features;
};
@@ -70,6 +75,7 @@ struct twlreg_info {
#define VREG_TRANS 1
#define VREG_STATE 2
#define VREG_VOLTAGE 3
+#define VREG_VOLTAGE_DCDC 4
/* TWL6030 Misc register offsets */
#define VREG_BC_ALL1
#define VREG_BC_REF2
@@ -87,6 +93,17 @@ struct twlreg_info {
#define TWL6030_CFG_STATE_APP(v) (((v)
TWL6030_CFG_STATE_APP_MASK) \
TWL6030_CFG_STATE_APP_SHIFT)
+/* Flags for DCDC Voltage reading */
+#define DCDC_OFFSET_EN BIT(0)
+#define DCDC_EXTENDED_EN BIT(1)
+
+/* twl6025 SMPS EPROM values */
+#define TWL6030_SMPS_OFFSET0xB0
+#define TWL6030_SMPS_MULT 0xB3
+#define SMPS_MULTOFFSET_SMPS4 BIT(0)
+#define SMPS_MULTOFFSET_VIOBIT(1)
+#define SMPS_MULTOFFSET_SMPS3 BIT(6)
+
static inline int
twlreg_read(struct twlreg_info *info, unsigned slave_subgp, unsigned
offset)
{
@@ -144,11 +161,15 @@ static int twl6030reg_is_enabled(struct
regulator_dev *rdev)
struct twlreg_info *info = rdev_get_drvdata(rdev);
int grp, val;
- grp = twlreg_read(info, TWL_MODULE_PM_RECEIVER, VREG_GRP);
- if (grp 0)
- return grp;
+ if (!(info-features TWL6025_SUBCLASS)) {
+ grp = twlreg_read(info, TWL_MODULE_PM_RECEIVER, VREG_GRP);
+ if (grp 0)
+ return grp;
- grp = P1_GRP_6030;
+ grp = P1_GRP_6030;
+ } else {
+ grp = 1;
+ }
val = twlreg_read(info, TWL_MODULE_PM_RECEIVER, VREG_STATE);
val = TWL6030_CFG_STATE_APP(val);
@@ -159,19 +180,22 @@ static int twl6030reg_is_enabled(struct
regulator_dev *rdev)
static int twlreg_enable(struct regulator_dev *rdev)
{
struct twlreg_info *info = rdev_get_drvdata(rdev);
- int grp;
- int ret;
+ int grp = 0;
+ int ret = 0;
- grp = twlreg_read(info, TWL_MODULE_PM_RECEIVER, VREG_GRP);
- if (grp 0)
- return grp;
+ if (!(twl_class_is_6030() (info-features TWL6025_SUBCLASS)))
{
+ grp = twlreg_read(info, TWL_MODULE_PM_RECEIVER, VREG_GRP);
+ if (grp 0)
+ return grp;
- if (twl_class_is_4030())
- grp |= P1_GRP_4030;
- else
- grp |= P1_GRP_6030;
+ if (twl_class_is_4030())
+ grp |= P1_GRP_4030;
+ else
+ grp |= P1_GRP_6030;
- ret = twlreg_write(info, TWL_MODULE_PM_RECEIVER, VREG_GRP, grp);
+ ret = twlreg_write(info, TWL_MODULE_PM_RECEIVER,
+ VREG_GRP, grp);
+ }
if (!ret twl_class_is_6030())
ret = twlreg_write(info, TWL_MODULE_PM_RECEIVER, VREG_STATE,
@@ -186,29 +210,34 @@ static int twlreg_enable(struct regulator_dev *rdev)
static int twlreg_disable(struct regulator_dev *rdev)
{
struct twlreg_info *info = rdev_get_drvdata(rdev);
- int grp;
- int ret;
-
- grp = twlreg_read(info, TWL_MODULE_PM_RECEIVER, VREG_GRP);
- if (grp 0)
- return grp;
-
- /* For 6030, set the off state for all grps enabled */
Re: [PATCH] omap: Remove support for omap2evm (Re: Updated mach-types update)
On 13/05/11 15:40, Tony Lindgren wrote: * Jarkko Nikula jhnik...@gmail.com [110513 05:15]: On Fri, 13 May 2011 04:54:07 -0700 Tony Lindgren t...@atomide.com wrote: * Tony Lindgren t...@atomide.com [110324 10:57]: * Russell King - ARM Linux li...@arm.linux.org.uk [110320 04:39]: On Sun, Mar 20, 2011 at 11:03:22AM +, Russell King - ARM Linux wrote: Note that OMAP references machine_is_omap2evm() yet this has never been merged. arch/arm/plat-omap/include/plat/uncompress.h: DEBUG_LL_OMAP2(1, omap2evm); so this entry needs to be removed. Hmm looks like we have LCD support and ASoC support for it, but no board :) Anybody working with this board? If so, please send patches for the related board-*.c support ASAP. Otherwise let's plan on deleting the related support. No patches, so let's remove it. Here's the patch to do that, I'm planning to add this to my devel-cleanup branch. Remove also from sound/soc/omap/Kconfig as well. You could put my ack for sound/soc/omap part but remember cc also Mark and Liam. Thanks, here's the updated patch. Regards, Tony From: Tony Lindgren t...@atomide.com 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 li...@arm.linux.org.uk. So let's remove the related dead code. Cc: linux-fb...@vger.kernel.org Cc: alsa-de...@alsa-project.org Cc: Mark Brown broo...@opensource.wolfsonmicro.com Cc: Liam Girdwood l...@ti.com Cc: Paul Mundt let...@linux-sh.org Cc: Tomi Valkeinen tomi.valkei...@ti.com Acked-by: Jarkko Nikula jhnik...@gmail.com Signed-off-by: Tony Lindgren t...@atomide.com Acked-by: Liam Girdwood l...@ti.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
Re: [PATCH] ASoC: omap-mcbsp: Remove restrictive checks for cpu type
On 11/05/11 14:55, Premi, Sanjeev wrote: Current checks for cpu type were too restrictive leading to failures for other silicons in same family. The problem was found while testing audio playback on AM37x and AM35x processors. But should exist on OMAP36xx as well. Signed-off-by: Sanjeev Premi pr...@ti.com cc: Mark Brown broo...@opensource.wolfsonmicro.com cc: Liam Girdwood l...@ti.com cc: Jarkko Nikula jhnik...@gmail.com --- Changes in v4: Reposting after validating that patch still applies cleanly on linux-omap master [46966f1] Changed the subject as suggested by Jarkko. Since the subject has changed, i have omitted v4. Changes in v3:: None. Reposting[1] after subscribing to alsa-devel list Changes in v2: 1) Added one more check to the changes. 2) Updated commit message to use plurals. Applied. Thanks Liam -- 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
Re: [PATCH 4/4] USB: TWL6025 allow different regulator name
On Mon, 2011-05-09 at 15:16 +0300, Felipe Balbi wrote: Hi, On Mon, May 09, 2011 at 12:43:49PM +0100, Liam Girdwood wrote: On Mon, 2011-05-09 at 12:03 +0300, Felipe Balbi wrote: Hi, On Sun, May 08, 2011 at 04:08:37PM +0100, Liam Girdwood wrote: On Wed, 2011-04-27 at 13:45 +0300, Felipe Balbi wrote: Hi, On Wed, Apr 27, 2011 at 10:39:51AM +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. Signed-off-by: Graeme Gregory g...@slimlogic.co.uk I don't see the point of this patch. It's just a string. Use the same name and add a comment saying that on datasheet/TRM/documentation the name LDO is actually referred to as LDOUSB. It's the same functionality anyway. I think for the avoidance of any doubt, it's probably best to use the TWL6025 string name here as it will importantly match the TWL6025 TRM and any schematics using the TWL6025. Getting this wrong during TWL6025 board integration has the potential for hardware damage. I would rather have something that doesn't depend on a correct string and matches based on the device pointer instead. I agree that having the correct string makes it easier to reference schematics/trm and the like, but making the SW depend on the correct spelling of a simple string, is too much for me :-( Specially when getting it wrong has the potential for hardware damage :-) 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 when creating their regulator constraints and having different names here will definitely cause confusion. Any chance Device Tree could be used to pass that data to kernel instead, together with regulator names and all needed data for each one of them ? Yes, I think this should be the long term aim, but atm we will have to stick with current implementation until regulator has device tree support. Liam -- 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
Re: [PATCH 4/4] USB: TWL6025 allow different regulator name
On Wed, 2011-04-27 at 13:45 +0300, Felipe Balbi wrote: Hi, On Wed, Apr 27, 2011 at 10:39:51AM +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. Signed-off-by: Graeme Gregory g...@slimlogic.co.uk I don't see the point of this patch. It's just a string. Use the same name and add a comment saying that on datasheet/TRM/documentation the name LDO is actually referred to as LDOUSB. It's the same functionality anyway. I think for the avoidance of any doubt, it's probably best to use the TWL6025 string name here as it will importantly match the TWL6025 TRM and any schematics using the TWL6025. Getting this wrong during TWL6025 board integration has the potential for hardware damage. Liam -- 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
Re: [PATCH 1/4] MFD: TWL6025: add phoenix lite support to twl6030
On Wed, 2011-04-27 at 13:40 +0300, Felipe Balbi wrote: On Wed, Apr 27, 2011 at 10:39:48AM +0100, Graeme Gregory wrote: + /* TWL6025 LDO regulators */ + struct regulator_init_data *ldo1; + struct regulator_init_data *ldo2; + struct regulator_init_data *ldo3; + struct regulator_init_data *ldo4; + struct regulator_init_data *ldo5; + struct regulator_init_data *ldo6; + struct regulator_init_data *ldo7; + struct regulator_init_data *ldoln; + struct regulator_init_data *ldousb; + /* TWL6025 DCDC regulators */ + struct regulator_init_data *smps3; + struct regulator_init_data *smps4; + struct regulator_init_data *vio6025; this is just becoming really really ugly. You need a more clever way of handling this. Maybe passing an array of regulators and the array size instead of continuously adding fields to this structure. Ok, I agree that optimising the platform data here is desirable, but I think we will have to stick with this atm as the twl driver has some rather annoying limitations that make optimising things like this a pita atm. I guess we should look at fixing the twl driver within TI in order to make it more adaptable (i.e. support future twl ICs) and also a non singleton device. Liam -- 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
Re: [PATCH 0/5] regulator: twl: make 6030 regulators useable
On Fri, 2011-04-01 at 10:22 +0530, Nishanth Menon wrote: TWL6030 regulator dynamic operations such as those on vaux2 and vaux3 were reported to be broken on platforms such as pandaboard(OMAP4). Digging deeper into the code, found that 6030 regulator support requires quiet a bit of fixes to make it useable. Major change w.r.t TWL4030 has been the introduction of CFG_STATE register in TWL6030 which is needed to be used for regulator control compared to messages which were used in TWL4030. All applied now. Thanks Liam -- 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
Re: [PATCH] ASoC: AM3517: Update codec name after multi-component update
On Tue, 2011-03-08 at 21:02 +0530, Abhilash K V wrote: The i2c client device name (.2-001a in this case, including the separator period) for the AIC23 codec on the TI AM3517-EVM was appended to the codec_name member of am3517evm_dai to resolve the names mismatch happening in soc_bind_dai_link(), due to which the card was not getting registered. Signed-off-by: Abhilash K V abhilash...@ti.com Acked-by: Jarkko Nikula jhnik...@gmail.com --- Applied. Thanks Liam -- 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
Re: [alsa-devel] [PATCH v2 00/13] OMAP: McBSP: hwmod adaptation and runtime conversion
On Tue, 2011-02-01 at 19:53 +0200, Jarkko Nikula wrote: On Mon, 31 Jan 2011 20:20:24 +0530 Kishon Vijay Abraham I kis...@ti.com wrote: Modify OMAP McBSP driver to use omap hwmod framework and pm runtime APIs. Created on top of linux OMAP master (linux-omap-2.6 :master) Did digital loopback testing on OMAP4430, OMAP3430 and OMAP2430 SDP boards. Verified that this patch series does not break the OMAP1 build. Patch series modifies audio layer and hence would appreciate the help of some audio guy to test this series. Patch series requires the following patch to be present http://permalink.gmane.org/gmane.linux.ports.arm.omap/51132 http://permalink.gmane.org/gmane.linux.ports.arm.omap/51133 http://permalink.gmane.org/gmane.linux.ports.arm.omap/51134 Generally I don't see any major show stopper here in audio point of view after fixing those few minor details. I tested and Beagle plays fine and N810 too with some tweaks (not related to this set). Mark, Liam: is it ok if the 12/13 goes together with rest of the set via linux-omap when ready? Yep, that should be OK. Liam -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk -- 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
Re: [alsa-devel] [PATCH v2 2/4] ASoC: DMIC codec: Adding a generic DMIC codec
On Thu, 2011-01-06 at 08:00 -0600, David Lambert wrote: This codec is to be used by the DMIC driver to control the DMIC codec. This driver will be used on future implementations of the DMIC driver to support codec specific features. At this time, the codec driver just registers the codec DAI. Signed-off-by: David Lambert dlamb...@ti.com --- sound/soc/codecs/Kconfig |3 ++ sound/soc/codecs/Makefile |2 + sound/soc/codecs/dmic.c | 81 + 3 files changed, 86 insertions(+), 0 deletions(-) create mode 100644 sound/soc/codecs/dmic.c Applied. Thanks Liam -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk -- 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
Re: [PATCH 1/5] ASoC: DMIC: Adding the OMAP DMIC driver
On Wed, 2010-12-29 at 11:47 +0200, Felipe Balbi wrote: Hi, On Tue, Dec 28, 2010 at 07:13:58PM -0600, Lambert, David wrote: one blank line only. BTW, are these used anywwhere outside the dmic.c driver ? If not, it's better to move the definitions there. They were originally in the omap-dmic.h header, but it was suggested that we move them to a platform header so that the driver could be more architecture independent and we could put the platform specific details here. I'm OK putting them just about anywhere, as long as we have consensus. The thing I don't like about putting register definitions under plat/*.h is that it creates the need for making the driver depends on ARCH_OMAP because it's the only architecture which has that file. If you put under linux/* or directly on the .c source file, you can have a much needed compile test with several architectures. Even though the driver will never work with those other archs, compile testing with several of them isn't bad at all. This seems unnecessary since this driver is for the OMAP platform only and also means maintainers will have to waste time fixing any build issues for this driver on irrelevant architectures. The costs here outweigh any benefits It also seems inconsistent with the other OMAP system headers in plat-omap too. Liam -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk -- 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
Re: [PATCH 1/5] ASoC: DMIC: Adding the OMAP DMIC driver
On Wed, 2010-12-29 at 12:44 +0200, Felipe Balbi wrote: Hi, On Wed, Dec 29, 2010 at 10:35:31AM +, Liam Girdwood wrote: Even though the driver will never work with those other archs, compile testing with several of them isn't bad at all. This seems unnecessary since this driver is for the OMAP platform only and also means maintainers will have to waste time fixing any build issues for this driver on irrelevant architectures. The costs here outweigh any benefits If that's the case, what's the use for linux-next, then ? Drivers should be arch independent as much as possible, no ? Isn't that why we don't want drivers using branches to things such as machine_is_omap4_panda() or similar ? I agree that drivers should be arch independent when possible, but in this case the OMAP DMIC DAI driver is coupled to the OMAP platform only. i.e. it performs IO directly on the OMAP DMIC IP. This IP is only found on OMAP silicon. I also agree it would be nice if it builds for PXA, MIPS, SuperH etc but what happens when the driver builds fine for OMAP but breaks the PXA, MIPS, SuperH build ? Who will spend time to fix and test it ? My main problem here is cost benefit. No one benefits directly by having this driver available for the above platforms but it costs me time fixing it when it breaks. But the whole audio part on OMAP is still in a bad shape anyway, e.g. mcbsp exports omap-only functions for drivers to use, so this will only be yet another driver to the pile :-p 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. It also seems inconsistent with the other OMAP system headers in plat-omap too. Other than a few drivers which still need converting (and are on their way) I can only see really arch-specific bits and pieces under plat/. Not sure what's your point here. The point is that David had split the DMIC headers into two files, one for plat specific registers and bit definitions and the other for audio definitions (for the machine drivers) and is/was consistent with the current OMAP platform headers. Liam -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk -- 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
Re: [PATCH 1/5] ASoC: DMIC: Adding the OMAP DMIC driver
On Wed, 2010-12-29 at 14:04 +0200, Felipe Balbi wrote: Hi, On Wed, Dec 29, 2010 at 11:52:51AM +, Liam Girdwood wrote: I agree that drivers should be arch independent when possible, but in this case the OMAP DMIC DAI driver is coupled to the OMAP platform only. i.e. it performs IO directly on the OMAP DMIC IP. This IP is only found on OMAP silicon. Let's imagine this IP is sourced from someone else and not created by TI, what prevents company XYZ from sourcing the same IP and end up re-using the driver ? That's fine, but this is not the case atm for this particular DMIC IP and we can only justify effort for OMAP atm. I also agree it would be nice if it builds for PXA, MIPS, SuperH etc but what happens when the driver builds fine for OMAP but breaks the PXA, MIPS, SuperH build ? Who will spend time to fix and test it ? You forgetting about other ARMs. This won't compile on DaVinci either. My main problem here is cost benefit. No one benefits directly by having this driver available for the above platforms but it costs me time fixing it when it breaks. Of course there's people benefitting: OMAP audio driver writers would know their driver is well written and doesn't break build for anybody. Ok, let me put it this way: What happens when you want have one kernel image for OMAP and DaVinci ? Granted, that's not possible today anyway but e.g. Linaro is pushing for it and IMO should be the way to go for us to be able to have a distro-like kernel for ARM-based systems too. Ok, I now think you meant other ARM architectures here than other Linux architectures in general. It does make a more sense for ARM distribution deployment, but I still think guaranteeing successful build for this driver on all non ARM architectures atm just to give us satisfaction that the driver is well written is unnecessary effort. It also seems inconsistent with the other OMAP system headers in plat-omap too. Other than a few drivers which still need converting (and are on their way) I can only see really arch-specific bits and pieces under plat/. Not sure what's your point here. The point is that David had split the DMIC headers into two files, one for plat specific registers and bit definitions and the other for audio definitions (for the machine drivers) and is/was consistent with the current OMAP platform headers. You forgot to mention that plat/ headers are supposed to be used by plat-* and mach-* code only to setup the correct state for the driver. Just recently one of the musb glue layers got broken because it was mistakenly using plat/control.h and that got moved. That's actually my point and why I think drivers should not touch plat/* and mach/* headers. In a lot of cases drivers under drivers/* and sound/* must touch plat/* and mach/* headers for runtime access to hardware IP. I've just grepped and the list is quite long for drivers/* Liam -- 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
Re: [PATCH 1/2] ASoC: Return proper error for omap3pandora_soc_init
On Wed, 2010-11-24 at 15:20 +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 --- sound/soc/omap/omap3pandora.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/sound/soc/omap/omap3pandora.c b/sound/soc/omap/omap3pandora.c index bff9864..8047c52 100644 --- a/sound/soc/omap/omap3pandora.c +++ b/sound/soc/omap/omap3pandora.c @@ -307,6 +307,7 @@ static int __init omap3pandora_soc_init(void) pr_err(PREFIX Failed to get DAC regulator from %s: %ld\n, dev_name(omap3pandora_snd_device-dev), PTR_ERR(omap3pandora_dac_reg)); + ret = PTR_ERR(omap3pandora_dac_reg); goto fail3; } Acked-by: Liam Girdwood l...@slimlogic.co.uk -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk -- 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
Re: [PATCH 2/2] ASoC: Fix resource reclaim for osk5912
On Wed, 2010-11-24 at 14:07 +0530, Varadarajan, Charulatha wrote: On Wed, Nov 24, 2010 at 12:53, Axel Lin axel@gmail.com wrote: Add Patch description. Signed-off-by: Axel Lin axel@gmail.com --- Please resubmit with a patch description and Jarkko's Ack. Thanks Liam -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk -- 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
Re: [alsa-devel] [PATCH 2.6.37-rc1] ASoC: OMAP: fix OMAP1 compilation problem
On Wed, 2010-11-03 at 10:20 +0200, Jarkko Nikula wrote: On Tue, 2 Nov 2010 10:58:59 -0600 (MDT) Paul Walmsley p...@pwsan.com wrote: On Tue, 2 Nov 2010, Janusz Krzysztofik wrote: In the new code introduced with commit cf4c87abe238ec17cd0255b4e21abd949d7f811e, OMAP: McBSP: implement McBSP CLKR and FSR signal muxing via mach-omap2/mcbsp.c, the way omap1 build is supposed to bypass omap2 specific 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. Created and tested against linux-2.6.37-rc1. Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl Acked-by: Paul Walmsley p...@pwsan.com Thanks Janusz. Yep, this must go to 2.6.37. Acked-by: Jarkko Nikula jhnik...@gmail.com Applied. Thanks Liam -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk -- 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
Re: [PATCH] regulator: fix build when CONFIG_REGULATOR_DUMMY=n
On Mon, 2010-10-11 at 22:05 +0530, Anand Gadiyar wrote:
Commit f03f91826 (regulator: Add option for machine drivers
to enable the dummy regulator) in the regulators tree
seems to have introduced the following build break when
CONFIG_REGULATOR_DUMMY is disabled. Fix this.
CC drivers/regulator/dummy.o
drivers/regulator/dummy.c:41: error: redefinition of 'regulator_dummy_init'
drivers/regulator/dummy.h:28: note: previous definition of
'regulator_dummy_init' was here
make[2]: *** [drivers/regulator/dummy.o] Error 1
make[1]: *** [drivers/regulator] Error 2
make: *** [drivers] Error 2
Signed-off-by: Anand Gadiyar gadi...@ti.com
Cc: Liam Girdwood l...@slimlogic.co.uk
Cc: Mark Brown broo...@opensource.wolfsonmicro.com
---
The commit referenced above is in linux next as of 20101011
and breaks builds of the omap2plus_defconfig at least.
drivers/regulator/dummy.h |4
1 file changed, 4 deletions(-)
Index: mainline/drivers/regulator/dummy.h
===
--- mainline.orig/drivers/regulator/dummy.h
+++ mainline/drivers/regulator/dummy.h
@@ -22,10 +22,6 @@ struct regulator_dev;
extern struct regulator_dev *dummy_regulator_rdev;
-#ifdef CONFIG_REGULATOR_DUMMY
void __init regulator_dummy_init(void);
-#else
-static inline void regulator_dummy_init(void) { }
-#endif
#endif
Applied.
Thanks
Liam
--
Freelance Developer, SlimLogic Ltd
ASoC and Voltage Regulator Maintainer.
http://www.slimlogic.co.uk
--
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
Re: [alsa-devel] [PATCH] omap: devices: Avoid merge conflict between ASoC and OMAP hwmod changes
On Mon, 2010-10-04 at 08:04 -0700, Mark Brown wrote: On Mon, Oct 04, 2010 at 03:04:53PM +0300, Jarkko Nikula wrote: Upcoming ASoC multi-component and OMAP hwmod changes will conflict in arch/arm/mach-omap2/devices.c. Avoid this by moving a little bit include statement introduced by ASoC Multi-Component Support patch. Signed-off-by: Jarkko Nikula jhnik...@gmail.com Cc: Paul Walmsley p...@pwsan.com Cc: Tony Lindgren t...@atomide.com Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com Applied. Thanks Liam -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk -- 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
RE: [PATCH 2/2] omap: zoom: Move new code introduced by ASoC m-c to board-zoom-peripherals
On Fri, 2010-09-24 at 11:31 -0500, Lopez Cruz, Misael wrote: Hi Jarkko, ASoC Multi-Component Support moves some code from sound/soc/omap/zoom2.c into arch/arm/mach-omap2/board-zoom2.c. However, that code should go to board-zoom-peripherals.c instead as there is common code and registration for zoom boards. Signed-off-by: Jarkko Nikula jhnik...@gmail.com Cc: Vikram Pandita vikram.pand...@ti.com Cc: Lopez Cruz, Misael x0052...@ti.com Cc: Jorge Eduardo Candelaria jorge.candela...@ti.com Cc: Tony Lindgren t...@atomide.com --- I don't have this HW so not tested. Tested on zoom2 using the 2 patches of your series, compilation break is gone and audio works fine. Thanks, -Misael Applied, and manually added your Tested-by: Thanks Liam -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk -- 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
Re: [PATCH] OMAP: McBSP: Fix static function warning
On Wed, 2010-09-08 at 08:53 +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?
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Cc: alsa-de...@alsa-project.org
Cc: Jarkko Nikula jhnik...@gmail.com
Cc: Peter Ujfalusi peter.ujfal...@nokia.com
Cc: Liam Girdwood l...@slimlogic.co.uk
Cc: Mark Brown broo...@opensource.wolfsonmicro.com
Cc: Tony Lindgren t...@atomide.com
Cc: Nishanth Menon n...@ti.com
---
sound/soc/omap/omap-mcbsp.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index 86f2139..5768381 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -780,7 +780,7 @@ struct snd_soc_dai omap_mcbsp_dai[] = {
EXPORT_SYMBOL_GPL(omap_mcbsp_dai);
-int omap_mcbsp_st_info_volsw(struct snd_kcontrol *kcontrol,
+static int omap_mcbsp_st_info_volsw(struct snd_kcontrol *kcontrol,
struct snd_ctl_elem_info *uinfo)
{
struct soc_mixer_control *mc =
Applied.
Thanks
Liam
--
Freelance Developer, SlimLogic Ltd
ASoC and Voltage Regulator Maintainer.
http://www.slimlogic.co.uk
--
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
Re: [PATCH 01/13] OMAP: Introduce a user list for each voltage domain instance in the voltage driver.
On Mon, 2010-09-06 at 22:59 +0300, Eduardo Valentin wrote: Hello, On Fri, Sep 03, 2010 at 08:20:52PM +0200, Mark Brown wrote: 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, that sounds like what we need. re-add? was it there at one point and removed? Any pointers to the old code? It was present in the pre-merge regulator API which you can find in the bowels of: git://opensource.wolfsonmicro.com/linux-2.6-audioplus but was removed to simplify review during the merge. It's fairly simple to do, it's just that there's been no demand. 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 we store the constraints that are specified in the consumer then iterate over all enabled consumers applying all the constraints that they've set in addition to those from the machine. This results in a configuration which is the lowest possible voltage which satisfies all the constraints that have been supplied and for supplies with only one consumer it gives the same behaviour as we have currently. How about taking Thara's proposal of using priority lists? I mean, it could make more sense to keep the constraints into a priority list, instead of iterate over all enabled consumers? You've not really explained why you think a priority list makes more sense in this case ? Liam -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk -- 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
Re: [alsa-devel] [PATCH v5 0/5] OMAP/ASoC: McBSP: FIFO handling related fixes
On Thu, 2010-06-03 at 07:39 +0300, Peter Ujfalusi wrote: Hello, Tony: Could you take a look at the arch/arm patches in this series? Thanks! Changes since v3/4: - Fixed commit subjects and messages for OMAP3 related patches - Added Acked-by from Mark, and Jarkko Intro message from the original series: This series aims to correct how the McBSP FIFO is viewed, and handled. Introduction of the problem: OMAP McBSP FIFO is word structured: McBSP2 has 1024 + 256 = 1280 word long buffer, McBSP1,3,4,5 has 128 word long buffer This means, that the size of the FIFO depends on the McBSP word size configuration. For example on McBSP3: 16bit samples: size is 128 * 2 = 256 bytes 32bit samples: size is 128 * 4 = 512 bytes It is simpler to place constraint for buffer and period based on channels. McBSP3 as example again (16 or 32 bit samples): 1 channel (mono): size is 128 frames (128 words) 2 channels (stereo): size is 128 / 2 = 64 frames (2 * 64 words) 4 channels: size is 128 / 4 = 32 frames (4 * 32 words) Since now the McBSP codec supports not only 16bit samples (32biut has been recently added), the FIFO size handling is no longer correct, since it has been hard wired for 16bit word length. The series changes how the users of McBSP are configuring the FIFO: It used to be 0 based (0 meant 1 word threshold). After this series users can configure the threshold in 1 base mode (1 means 1 word threshold). The platform code now provides the full size of the FIFO in words, instead of the already limited value used in the past. In ASoC omap-mcbsp code hw_rule based constraint refinement is going to be used instead of the hardwired static constraint, which was correct only in case of 16bit word length. The hw_rule is refining the minimum buffer size based on the channel number going to be used by the coming stream. In case of threshold mode additional hw_rule refines the maximum allowed period size. The series are generated agains Takashi's sound-2.6: topic/asoc branch. CCing also Eduardo, and Eero since they have worked on the original FIFO/threshold implementation. All commetns and testers are welcome! Peter --- Peter Ujfalusi (5): OMAP: McBSP: Function to query the FIFO size OMAP3: McBSP: Change the way how the FIFO is handled OMAP3: McBSP: Use the port's buffer_size when calculating tx delay ASoC: omap-mcbsp: Save, and use wlen for threshold configuration ASoC: omap-mcbsp: Place correct constraints for streams arch/arm/mach-omap2/mcbsp.c | 10 ++-- arch/arm/plat-omap/include/plat/mcbsp.h |2 + arch/arm/plat-omap/mcbsp.c | 51 ++- sound/soc/omap/omap-mcbsp.c | 112 +++--- 4 files changed, 128 insertions(+), 47 deletions(-) Applied all. Thanks Liam -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk -- 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
Re: [alsa-devel] [PATCH v3 0/5] OMAP/ASoC: McBSP: FIFO handling related fixes
On Wed, 2010-06-02 at 12:05 +0300, Peter Ujfalusi wrote: Hi, On Tuesday 01 June 2010 14:18:19 Ujfalusi Peter (Nokia-D/Tampere) wrote: .. Liam if you are going to take the series, could you fix the patch names? I can also resend them if it is easier for you. Peter, I think it's probably better if you can resend. Can you also append the Acks too. Tony, do we have your ack too ? Thanks Liam -- 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
Re: [alsa-devel] [RFC PATCH 5/5] ASoC: omap-mcbsp: Place correct constraints for streams
On Mon, 2010-05-31 at 11:16 +0300, Peter Ujfalusi wrote:
OMAP McBSP FIFO is word structured:
McBSP2 has 1024 + 256 = 1280 word long buffer,
McBSP1,3,4,5 has 128 word long buffer
This means, that the size of the FIFO
depends on the McBSP word size configuration.
For example on McBSP3:
16bit samples: size is 128 * 2 = 256 bytes
32bit samples: size is 128 * 4 = 512 bytes
It is simpler to place constraint for buffer and period based on channels.
McBSP3 as example again (16 or 32 bit samples):
1 channel (mono): size is 128 frames (128 words)
2 channels (stereo): size is 128 / 2 = 64 frames (2 * 64 words)
4 channels: size is 128 / 4 = 32 frames (4 * 32 words)
Use the second method to place hw_rule on buffer size, and in threshold
mode to period size.
Signed-off-by: Peter Ujfalusi peter.ujfal...@nokia.com
---
sound/soc/omap/omap-mcbsp.c | 98 +-
1 files changed, 77 insertions(+), 21 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index b06d8f1..d6ed761 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -173,6 +173,52 @@ static void omap_mcbsp_set_threshold(struct
snd_pcm_substream *substream)
omap_mcbsp_set_rx_threshold(mcbsp_data-bus_id, words);
}
+static int hw_rule_bsize_by_channels(struct snd_pcm_hw_params *params,
+ struct snd_pcm_hw_rule *rule)
+{
+ struct snd_interval *bs = hw_param_interval(params,
+ SNDRV_PCM_HW_PARAM_BUFFER_SIZE);
+ struct snd_interval *c = hw_param_interval(params,
+ SNDRV_PCM_HW_PARAM_CHANNELS);
Best to make these variable names more meaningful.
+ struct omap_mcbsp_data *mcbsp_data = rule-private;
+ struct snd_interval frames;
+ int size;
+
+ snd_interval_any(frames);
+ size = omap_mcbsp_get_fifo_size(mcbsp_data-bus_id);
+
+ frames.min = size / c-min;
+ frames.integer = 1;
+ return snd_interval_refine(bs, frames);
+
+}
+
+static int hw_rule_psize_by_channels(struct snd_pcm_hw_params *params,
+ struct snd_pcm_hw_rule *rule)
+{
+ struct snd_interval *ps = hw_param_interval(params,
+ SNDRV_PCM_HW_PARAM_PERIOD_SIZE);
+ struct snd_interval *c = hw_param_interval(params,
+ SNDRV_PCM_HW_PARAM_CHANNELS);
ditto
+ struct snd_pcm_substream *substream = rule-private;
+ struct snd_soc_pcm_runtime *rtd = substream-private_data;
+ struct snd_soc_dai *cpu_dai = rtd-dai-cpu_dai;
+ struct omap_mcbsp_data *mcbsp_data = to_mcbsp(cpu_dai-private_data);
+ struct snd_interval frames;
+ int size;
+
+ snd_interval_any(frames);
+ if (substream-stream == SNDRV_PCM_STREAM_PLAYBACK)
+ size = omap_mcbsp_get_max_tx_threshold(mcbsp_data-bus_id);
+ else
+ size = omap_mcbsp_get_max_rx_threshold(mcbsp_data-bus_id);
+
+ frames.min = 8;
+ frames.max = size / c-min;
+ frames.integer = 1;
+ return snd_interval_refine(ps, frames);
+}
Thanks
Liam
--
Freelance Developer, SlimLogic Ltd
ASoC and Voltage Regulator Maintainer.
http://www.slimlogic.co.uk
--
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
Re: [PATCH 0/4] McBSP smart idle and DMA op mode updates for ASoC
On Wed, 2010-05-19 at 13:42 +0300, Eduardo Valentin wrote: On Tue, May 18, 2010 at 10:13:10PM +0200, Liam Girdwood wrote: This series expands the OMAP mcbsp driver to support changing it's DMA operating mode and smart idle mode from client drivers. It's primarily aimed at lowering the power consumption for OMAP ASoC drivers by providing methods to gate clocks on the mcbsp interface at runtime. I've also added a patch to remove the mcbsp DMA op mode sysfs set functionality. I think DMA op mode is very specific to the mcbsp client driver _only_ and shouldn't really be changed by userspace. Please let me know if you use this feature and I'll drop this patch. Yeah, I'm not sure if that would be strong enough argument though. Unfortunately, this dma op mode also couples with the usage of mcbsp internal buffer. Which in the very end will mean a compromise between delay vs. pm, as you are probably aware. So, letting userspace to toggle this mode will also mean they can choose between pm friendly (op mode with frame and so on) or short delay friendly (element mode). Of course, this might not be the best way of choosing it though. The sysfs set interface implies userspace having knowledge of driver capabilities and configuration in order to safely toggle between the two DMA modes. Imo, the mcbsp client driver should be the only entity configuring it's DMA modes (in a safe manner) depending on the use case. Liam -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk -- 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
Re: [alsa-devel] [PATCH 2/4] OMAP: mcbsp - add smart idle configuration API
On Wed, 2010-05-19 at 13:46 +0300, Eduardo Valentin wrote: Hello Lian, On Tue, May 18, 2010 at 10:13:12PM +0200, Liam Girdwood wrote: Add a small API to configure McBSP smart idle modes to conserve power. I'm sorry but I didn't get the point of this patch, as you didn't add any wider description why you need to export this feature. Sorry, I thought this would obvious from the patch and description. Why do you think mcbsp clients should be aware of these bit? Would it make sense to mask it behind other feature? like the threshold size for instance.. Why do you think it should be masked behind threshold ? Liam -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk -- 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
Re: [PATCH 1/4] OMAP: mcbsp - add omap_mcbsp_set_dma_op_mode()
On Wed, 2010-05-19 at 13:50 +0300, Eduardo Valentin wrote: On Tue, May 18, 2010 at 10:13:11PM +0200, Liam Girdwood wrote: This adds a method to set the MCBSP DMA OP mode. OK. good. But again, why do you need set dma op mode other than inside mcbsp code? I think Peter has answered this. Right, so, from what I have read briefly, the idea is to remove the user space ability to set the mode and let mcbsp clients to do it. What is not clear to me is how mcbsp clients (inside kernel) will determine if they want short delay or pm friendly. That usually is bound to upper use case though. An example would be an ASoC client. The ASoC driver would be configured either for low latency, low power, etc. by userspace (using formal ALSA calls) and would be able to configure the mcbsp to match this request. It would be really nice if you improve your patch descriptions. Sorry, I thought again this was obvious. Liam -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk -- 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
[PATCH 0/4] McBSP smart idle and DMA op mode updates for ASoC
This series expands the OMAP mcbsp driver to support changing it's DMA operating mode and smart idle mode from client drivers. It's primarily aimed at lowering the power consumption for OMAP ASoC drivers by providing methods to gate clocks on the mcbsp interface at runtime. I've also added a patch to remove the mcbsp DMA op mode sysfs set functionality. I think DMA op mode is very specific to the mcbsp client driver _only_ and shouldn't really be changed by userspace. Please let me know if you use this feature and I'll drop this patch. Tony, can I get your ack to upstream via ALSA if it's ok Thanks Liam arch/arm/plat-omap/include/plat/mcbsp.h | 17 +++ arch/arm/plat-omap/mcbsp.c | 183 ++- sound/soc/omap/omap-mcbsp.c | 22 - sound/soc/omap/omap-mcbsp.h |2 + 4 files changed, 194 insertions(+), 30 deletions(-) -- 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
[PATCH 1/4] OMAP: mcbsp - add omap_mcbsp_set_dma_op_mode()
This adds a method to set the MCBSP DMA OP mode.
Signed-off-by: Liam Girdwood l...@slimlogic.co.uk
---
arch/arm/plat-omap/include/plat/mcbsp.h |2 ++
arch/arm/plat-omap/mcbsp.c | 31 +++
2 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/mcbsp.h
b/arch/arm/plat-omap/include/plat/mcbsp.h
index 1bd7021..f8823f4 100644
--- a/arch/arm/plat-omap/include/plat/mcbsp.h
+++ b/arch/arm/plat-omap/include/plat/mcbsp.h
@@ -476,6 +476,7 @@ u16 omap_mcbsp_get_max_rx_threshold(unsigned int id);
u16 omap_mcbsp_get_tx_delay(unsigned int id);
u16 omap_mcbsp_get_rx_delay(unsigned int id);
int omap_mcbsp_get_dma_op_mode(unsigned int id);
+int omap_mcbsp_set_dma_op_mode(unsigned int id, unsigned int mode);
#else
static inline void omap_mcbsp_set_tx_threshold(unsigned int id, u16 threshold)
{ }
@@ -486,6 +487,7 @@ static inline u16 omap_mcbsp_get_max_rx_threshold(unsigned
int id) { return 0; }
static inline u16 omap_mcbsp_get_tx_delay(unsigned int id) { return 0; }
static inline u16 omap_mcbsp_get_rx_delay(unsigned int id) { return 0; }
static inline int omap_mcbsp_get_dma_op_mode(unsigned int id) { return 0; }
+static inline int omap_mcbsp_set_dma_op_mode(unsigned int id, unsigned int
mode) {return 0;}
#endif
int omap_mcbsp_request(unsigned int id);
void omap_mcbsp_free(unsigned int id);
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index 4820cab..cc2b73c 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -635,6 +635,37 @@ int omap_mcbsp_get_dma_op_mode(unsigned int id)
}
EXPORT_SYMBOL(omap_mcbsp_get_dma_op_mode);
+/*
+ * omap_mcbsp_set_dma_op_mode set the current DMA
+ * operating mode for the mcbsp channel
+ */
+int omap_mcbsp_set_dma_op_mode(unsigned int id, unsigned int mode)
+{
+ struct omap_mcbsp *mcbsp;
+ int ret = 0;
+
+ if (mode MCBSP_DMA_MODE_FRAME)
+ return -EINVAL;
+
+ if (!omap_mcbsp_check_valid_id(id)) {
+ printk(KERN_ERR %s: Invalid id (%d)\n, __func__, id + 1);
+ return -ENODEV;
+ }
+ mcbsp = id_to_mcbsp_ptr(id);
+
+ spin_lock_irq(mcbsp-lock);
+ if (!mcbsp-free) {
+ ret = -EBUSY;
+ goto unlock;
+ }
+ mcbsp-dma_op_mode = mode;
+
+unlock:
+ spin_unlock_irq(mcbsp-lock);
+ return ret;
+}
+EXPORT_SYMBOL(omap_mcbsp_set_dma_op_mode);
+
static inline void omap34xx_mcbsp_request(struct omap_mcbsp *mcbsp)
{
/*
--
1.7.0.4
--
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
[PATCH 2/4] OMAP: mcbsp - add smart idle configuration API
Add a small API to configure McBSP smart idle modes
to conserve power.
Signed-off-by: Liam Girdwood l...@slimlogic.co.uk
---
arch/arm/plat-omap/include/plat/mcbsp.h | 15
arch/arm/plat-omap/mcbsp.c | 122 +++
2 files changed, 137 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/mcbsp.h
b/arch/arm/plat-omap/include/plat/mcbsp.h
index f8823f4..3f9fb71 100644
--- a/arch/arm/plat-omap/include/plat/mcbsp.h
+++ b/arch/arm/plat-omap/include/plat/mcbsp.h
@@ -278,6 +278,15 @@
#define ENAWAKEUP 0x0004
#define SOFTRST0x0002
+#define MCBSP_CLK_ACT_IOFF_POFF0
+#define MCBSP_CLK_ACT_ION_POFF 1
+#define MCBSP_CLK_ACT_IOFF_PON 2
+#define MCBSP_CLK_ACT_ION_PON 3
+
+#define MCBSP_IDLE_FORCE 0
+#define MCBSP_IDLE_NONE1
+#define MCBSP_IDLE_SMART 2
+
/** McBSP SSELCR bit definitions ***/
#define SIDETONEEN 0x0400
@@ -456,6 +465,7 @@ struct omap_mcbsp {
#ifdef CONFIG_ARCH_OMAP3
struct omap_mcbsp_st_data *st_data;
int dma_op_mode;
+ int idle_mode;
u16 max_tx_thres;
u16 max_rx_thres;
#endif
@@ -477,6 +487,11 @@ u16 omap_mcbsp_get_tx_delay(unsigned int id);
u16 omap_mcbsp_get_rx_delay(unsigned int id);
int omap_mcbsp_get_dma_op_mode(unsigned int id);
int omap_mcbsp_set_dma_op_mode(unsigned int id, unsigned int mode);
+int omap_mcbsp_set_idle_smart(unsigned int id, unsigned int clk_activity,
+ unsigned int wake);
+int omap_mcbsp_set_idle_none(unsigned int id);
+int omap_mcbsp_set_idle_force(unsigned int id);
+int omap_mcbsp_get_idle_mode(unsigned int id);
#else
static inline void omap_mcbsp_set_tx_threshold(unsigned int id, u16 threshold)
{ }
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index cc2b73c..7785050 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -1743,6 +1743,128 @@ static inline void __devexit
omap34xx_device_exit(struct omap_mcbsp *mcbsp)
omap_st_remove(mcbsp);
}
}
+
+/* assert standby requests when idle */
+int omap_mcbsp_set_idle_smart(unsigned int id, unsigned int clk_activity,
+ u32 wakeup)
+{
+ struct omap_mcbsp *mcbsp;
+ u16 syscon;
+ int ret = 0;
+
+ if (!omap_mcbsp_check_valid_id(id)) {
+ printk(KERN_ERR %s: Invalid id (%u)\n, __func__, id + 1);
+ return -ENODEV;
+ }
+ mcbsp = id_to_mcbsp_ptr(id);
+
+ spin_lock_irq(mcbsp-lock);
+ if (!mcbsp-free) {
+ ret = -EBUSY;
+ goto unlock;
+ }
+
+ syscon = MCBSP_READ(mcbsp, SYSCON)
+ ~(ENAWAKEUP | SIDLEMODE(0x03) | CLOCKACTIVITY(0x03));
+ MCBSP_WRITE(mcbsp, WAKEUPEN, wakeup);
+ MCBSP_WRITE(mcbsp, SYSCON,
+ syscon | SIDLEMODE(MCBSP_IDLE_SMART) |
+ CLOCKACTIVITY(clk_activity) | ENAWAKEUP);
+ mcbsp-idle_mode = MCBSP_IDLE_SMART;
+
+unlock:
+ spin_unlock_irq(mcbsp-lock);
+ return ret;
+}
+EXPORT_SYMBOL(omap_mcbsp_set_idle_smart);
+
+/* never assert standby requests */
+int omap_mcbsp_set_idle_none(unsigned int id)
+{
+ struct omap_mcbsp *mcbsp;
+ u16 syscon;
+ int ret = 0;
+
+ if (!omap_mcbsp_check_valid_id(id)) {
+ printk(KERN_ERR %s: Invalid id (%u)\n, __func__, id + 1);
+ return -ENODEV;
+ }
+ mcbsp = id_to_mcbsp_ptr(id);
+
+ spin_lock_irq(mcbsp-lock);
+ if (!mcbsp-free) {
+ ret = -EBUSY;
+ goto unlock;
+ }
+
+ syscon = MCBSP_READ(mcbsp, SYSCON)
+ ~(ENAWAKEUP | SIDLEMODE(0x03) | CLOCKACTIVITY(0x03));
+
+ MCBSP_WRITE(mcbsp, SYSCON, syscon | SIDLEMODE(MCBSP_IDLE_NONE));
+ MCBSP_WRITE(mcbsp, WAKEUPEN, 0);
+ mcbsp-idle_mode = MCBSP_IDLE_NONE;
+
+unlock:
+ spin_unlock_irq(mcbsp-lock);
+ return ret;
+}
+EXPORT_SYMBOL(omap_mcbsp_set_idle_none);
+
+/* unconditionally assert standby requests */
+int omap_mcbsp_set_idle_force(unsigned int id)
+{
+ struct omap_mcbsp *mcbsp;
+ u16 syscon;
+ int ret = 0;
+
+ if (!omap_mcbsp_check_valid_id(id)) {
+ printk(KERN_ERR %s: Invalid id (%u)\n, __func__, id + 1);
+ return -ENODEV;
+ }
+ mcbsp = id_to_mcbsp_ptr(id);
+
+ spin_lock_irq(mcbsp-lock);
+ if (!mcbsp-free) {
+ ret = -EBUSY;
+ goto unlock;
+ }
+
+ syscon = MCBSP_READ(mcbsp, SYSCON)
+ ~(ENAWAKEUP | SIDLEMODE(0x03) | CLOCKACTIVITY(0x03));
+ /*
+* HW bug workaround - If no_idle mode is taken, we need to
+* go to smart_idle before going to always_idle, or the
+* device will not hit retention anymore.
+*/
+ syscon |= SIDLEMODE
[PATCH 3/4] ASoC: mcbsp - add machine threshold callback
Add a mechanism to register a machine specific callback
to calculate and set the McBSP Tx/Rx threshold.
Signed-off-by: Liam Girdwood l...@slimlogic.co.uk
---
sound/soc/omap/omap-mcbsp.c | 22 +-
sound/soc/omap/omap-mcbsp.h |2 ++
2 files changed, 23 insertions(+), 1 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index 6f44cb4..9a1583d 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -51,6 +51,9 @@ struct omap_mcbsp_data {
unsigned intbus_id;
struct omap_mcbsp_reg_cfg regs;
unsigned intfmt;
+
+ /* optional machine set_threshold() sample value */
+ void (*mach_set_threshold)(struct snd_pcm_substream *substream);
/*
* Flags indicating is the bus already activated and configured by
* another substream
@@ -306,7 +309,11 @@ static int omap_mcbsp_dai_hw_params(struct
snd_pcm_substream *substream,
} else if (cpu_is_omap343x()) {
dma = omap24xx_dma_reqs[bus_id][substream-stream];
port = omap34xx_mcbsp_port[bus_id][substream-stream];
- omap_mcbsp_dai_dma_params[id][substream-stream].set_threshold =
+ if (mcbsp_data-mach_set_threshold)
+
omap_mcbsp_dai_dma_params[id][substream-stream].set_threshold =
+ mcbsp_data-mach_set_threshold;
+ else
+
omap_mcbsp_dai_dma_params[id][substream-stream].set_threshold =
omap_mcbsp_set_threshold;
/* TODO: Currently, MODE_ELEMENT == MODE_FRAME */
if (omap_mcbsp_get_dma_op_mode(bus_id) ==
@@ -835,6 +842,19 @@ int omap_mcbsp_st_add_controls(struct snd_soc_codec
*codec, int mcbsp_id)
}
EXPORT_SYMBOL_GPL(omap_mcbsp_st_add_controls);
+int omap_bcbsp_set_threshold_func(struct snd_soc_dai *cpu_dai,
+ void (*mach_set_threshold)(struct snd_pcm_substream *substream))
+{
+ struct omap_mcbsp_data *mcbsp_data = to_mcbsp(cpu_dai-private_data);
+
+ if (!cpu_is_omap34xx())
+ return -ENODEV;
+
+ mcbsp_data-mach_set_threshold = mach_set_threshold;
+ return 0;
+}
+EXPORT_SYMBOL_GPL(omap_bcbsp_set_threshold_func);
+
static int __init snd_omap_mcbsp_init(void)
{
return snd_soc_register_dais(omap_mcbsp_dai,
diff --git a/sound/soc/omap/omap-mcbsp.h b/sound/soc/omap/omap-mcbsp.h
index 6c363e5..f8d8044 100644
--- a/sound/soc/omap/omap-mcbsp.h
+++ b/sound/soc/omap/omap-mcbsp.h
@@ -58,5 +58,7 @@ enum omap_mcbsp_div {
extern struct snd_soc_dai omap_mcbsp_dai[NUM_LINKS];
int omap_mcbsp_st_add_controls(struct snd_soc_codec *codec, int mcbsp_id);
+int omap_bcbsp_set_threshold_func(struct snd_soc_dai *cpu_dai,
+ void (*mach_set_threshold)(struct snd_pcm_substream
*substream));
#endif
--
1.7.0.4
--
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
[PATCH 4/4] OMAP: mcbsp - remove sysfs set for DMA op mode.
The mcbsp DMA op mode is tightly integrated with the
mcbsp client driver operation and hence is unsuitable
for userspace configuration via sysfs.
Signed-off-by: Liam Girdwood l...@slimlogic.co.uk
---
arch/arm/plat-omap/mcbsp.c | 30 +-
1 files changed, 1 insertions(+), 29 deletions(-)
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index 7785050..b7b8b5e 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -1546,35 +1546,7 @@ static ssize_t dma_op_mode_show(struct device *dev,
return len;
}
-static ssize_t dma_op_mode_store(struct device *dev,
- struct device_attribute *attr,
- const char *buf, size_t size)
-{
- struct omap_mcbsp *mcbsp = dev_get_drvdata(dev);
- const char * const *s;
- int i = 0;
-
- for (s = dma_op_modes[i]; i ARRAY_SIZE(dma_op_modes); s++, i++)
- if (sysfs_streq(buf, *s))
- break;
-
- if (i == ARRAY_SIZE(dma_op_modes))
- return -EINVAL;
-
- spin_lock_irq(mcbsp-lock);
- if (!mcbsp-free) {
- size = -EBUSY;
- goto unlock;
- }
- mcbsp-dma_op_mode = i;
-
-unlock:
- spin_unlock_irq(mcbsp-lock);
-
- return size;
-}
-
-static DEVICE_ATTR(dma_op_mode, 0644, dma_op_mode_show, dma_op_mode_store);
+static DEVICE_ATTR(dma_op_mode, 0644, dma_op_mode_show, NULL);
static ssize_t st_taps_show(struct device *dev,
struct device_attribute *attr, char *buf)
--
1.7.0.4
--
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
RE: [PATCH] twl6030: regulator: Remove vsel tables and use formula for calculation
On Fri, 2010-05-14 at 11:57 +0530, Nayak, Rajendra wrote: -Original Message- From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com] Sent: Friday, April 23, 2010 4:49 PM To: Nayak, Rajendra Cc: linux-omap@vger.kernel.org; Liam Girdwood; Samuel Ortiz Subject: Re: [PATCH] twl6030: regulator: Remove vsel tables and use formula for calculation On Thu, Apr 22, 2010 at 02:18:32PM +0530, Rajendra Nayak wrote: All twl6030 regulators can be programmed from 1.0v to 3.3v with 100mV steps. The below formula can be used to calculate the vsel values to be programmed in the VREG_VOLTAGE registers. Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com Liam, Would you be queuing this up for the next merge window? Sorry, looks like I missed this one. Now applied. Thanks Liam -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk -- 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
Re: [PATCH] OMAP: McBSP: Add 32-bit mode support
On Thu, 2010-05-13 at 19:48 +0400, Sergey Lapin wrote: This patchs should allow to use 32-bit samples on e.g. TLV320AIC3x codec, or others. Signed-off-by: Sergey Lapin sla...@ossfans.org --- Applied. Thanks Liam -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk -- 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
Re: [PATCH v3 0/2] McBSP changes for OMAP4 platform
On Thu, 2010-05-13 at 09:19 +0100, Mark Brown wrote: On Wed, May 12, 2010 at 12:18:38PM -0500, Jorge Eduardo Candelaria wrote: The following patches enable McBSP driver to be used along with the audio driver in SDP4430 and other OMAP4 based boards. Both Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com Tony, do we have you ack/sob to upstream via ASoC ? We do have a lot pending with mcbsp dependencies for ASoC atm and this would simplify upstreaming. Thanks Liam -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk -- 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
Re: [PATCH v2 0/0] McBSP changes for OMAP4 platform
On Wed, 2010-05-12 at 11:39 +0300, Peter Ujfalusi wrote: Hi, On Thursday 06 May 2010 04:15:44 ext Jorge Eduardo Candelaria wrote: The following patches enable McBSP driver to be used along with the audio driver in SDP4430 and other OMAP4 based boards. Changes from v1: - Changed to correct IRQ lines. - Check if rx_irq is defined, instead of checking if cpu is omap4 Jorge Eduardo Candelaria (2): ARM: McBSP: Fix request for irq in OMAP4 ARM: OMAP4: Add support for omap4 in McBSP driver arch/arm/mach-omap2/mcbsp.c | 12 arch/arm/plat-omap/mcbsp.c | 34 +++--- 2 files changed, 23 insertions(+), 23 deletions(-) Looks good with Jarkko's comment. However, I'd like to ask Tony, Liam, Jarkko, and Mark the following: Would it make sense to use the alsa tree for OMAP McBSP related patches, while keeping l-o in CC off course. If we have patches for mcbsp pending in l-o and in alsa tree, than we are going to have hard times to sort things out when they need to be merged. I'm asking this, because I will also have some patches for mcbsp, which will need change in arch/ and in sound/ as well. I know that taking patches to alsa tree for the arch/ is unorthodox, but it will ease up our life in a long run... What do you think? I tend to agree here since afaik audio is the primary upstream user of mcbsp on OMAP. We do have queue of audio related mcbsp patches pending atm and merging would be simpler in the ALSA tree atm. Liam -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk -- 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
Re: [alsa-devel] [PATCHv2 1/2] OMAP4: PMIC: Rename twl6030_codec as twl6040_codec
On Wed, 2010-03-17 at 17:42 -0500, Olaya, Margarita wrote: Correction for chips: twl6030 is Phoenix Power chip twl6040 is Phoenix Audio chip Signed-off-by: Margarita Olaya Cabrera magi.ol...@ti.com Acked-by: Liam Girdwood l...@slimlogic.co.uk -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk -- 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
Re: [alsa-devel] [PATCHv6 2/2] ASoC: TWL6040: Add twl6040 codec driver
On Wed, 2010-03-17 at 17:42 -0500, Olaya, Margarita wrote: From: Misael Lopez Cruz x0052...@ti.com Initial version of TWL6040 codec driver. The TWL6040 codec uses a proprietary PDM-based digital audio interface. Audio paths supported are: - Input: Main Mic, Sub Mic, Headset Mic, Auxiliary-FM Left/Right - Output: Headset Left/Right, Handsfree Left/Right TWL6040 codec supports power-up/down manual and automatic sequence. Manual sequence is done through a specific register writes sequence. Automatic sequence is done when the codec is powered-up through the external AUDPWRON line. The completion of the sequence is signaled through the audio interrupt. TWL6040 codec sysclk can be provided by: low-power or high performance PLL: - The low-power PLL takes a low-frequency input at 32,768 Hz and generates an approximate of 17.64 or 19.2 MHz (for 44.1 KHz and 48 KHz respectively) - The high-performance PLL generates an exact 19.2 MHz clock signal from high-frequency input at 12/19.2/26/38.4 MHz. Low-power playback mode is a special scenario where only headset path (headset DAC and driver) is active. For the particular case of headset path, PLL being used defines the headset power mode: low-power, high-performance. Signed-off-by: Misael Lopez Cruz x0052...@ti.com Signed-off-by: Jorge Eduardo Candelaria jorge.candela...@ti.com Signed-off-by: Margarita Olaya Cabrera magi.ol...@ti.com Acked-by: Liam Girdwood l...@slimlogic.co.uk -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk -- 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
Re: [alsa-devel] [PATCHv2 1/5] ASoC: core: fix tailing whitespace in soc_pcm_apply_symmetry
On Wed, 2010-03-03 at 15:08 +0200, Peter Ujfalusi wrote: My editor removes the tailing spaces, which causes problems when changing the soc-core.c Removing the space. Signed-off-by: Peter Ujfalusi peter.ujfal...@nokia.com Acked-by: Liam Girdwood l...@slimlogic.co.uk -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk -- 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
Re: [alsa-devel] [PATCHv2 2/5] ASoC: core: soc level wrapper for pcm_pointer callback
On Wed, 2010-03-03 at 15:08 +0200, Peter Ujfalusi wrote: Create a soc level wrapper for pcm_pointer callback. This will facilitate the soc level handling of different HW buffers in the audio path. Signed-off-by: Peter Ujfalusi peter.ujfal...@nokia.com Acked-by: Liam Girdwood l...@slimlogic.co.uk -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk -- 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
Re: [alsa-devel] [PATCHv2 3/5] ASoC: core: Add delay operation to snd_soc_dai_ops
On Wed, 2010-03-03 at 15:08 +0200, Peter Ujfalusi wrote: The delay callback can be used by the core to query the delay on the dai caused by FIFO or delay in the platform side. In case if both CPU and CODEC dai has FIFO the delay reported by each will be added to form the full delay on the chain. If none of the dai has FIFO, than the delay will be kept as zero. Signed-off-by: Peter Ujfalusi peter.ujfal...@nokia.com Acked-by: Liam Girdwood l...@slimlogic.co.uk -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk -- 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
Re: [alsa-devel] [PATCHv2 5/5] ASoC: OMAP3: Report delay caused by the internal FIFO
On Wed, 2010-03-03 at 15:08 +0200, Peter Ujfalusi wrote: Use the new delay calback function to report the delay through ALSA for application caused by the internal FIFO. Signed-off-by: Peter Ujfalusi peter.ujfal...@nokia.com --- Acked-by: Liam Girdwood l...@slimlogic.co.uk -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk -- 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
Re: [alsa-devel] [PATCHv4 2/7] ASoC: TWL6030: Add twl6030 codec driver
On Wed, 2010-02-24 at 17:37 -0600, Olaya, Margarita wrote:
-Original Message-
From: Liam Girdwood [mailto:l...@slimlogic.co.uk]
Sent: Wednesday, February 24, 2010 4:38 AM
To: Olaya, Margarita
Cc: alsa-de...@alsa-project.org; linux-omap@vger.kernel.org;
broo...@opensource.wolfsonmicro.com
Subject: Re: [PATCHv4 2/7] ASoC: TWL6030: Add twl6030 codec driver
On Tue, 2010-02-23 at 18:10 -0600, Olaya, Margarita wrote:
From: Misael Lopez Cruz x0052...@ti.com
Initial version of TWL6030 codec driver.
The TWL6030 codec uses a propietary PDM-based digital audio interface.
Audio paths supported are:
- Input: Main Mic, Sub Mic, Headset Mic, Auxiliary-FM Left/Right
- Output: Headset Left/Right, Handsfree Left/Right
+
+/*
+ * read from twl6030 hardware register
+ */
+static int twl6030_read(struct snd_soc_codec *codec,
+ unsigned int reg)
+{
+ u8 value;
+
+ if (reg = TWL6030_CACHEREGNUM)
+ return -EIO;
+
+ twl_i2c_read_u8(TWL4030_MODULE_AUDIO_VOICE, value, reg);
+ twl6030_write_reg_cache(codec, reg, value);
You probably want to read from the cache if the register is not
volatile. This saves a slow I2C read.
This function is called for volatile registers; if the register is not
volatile we call twl6030_read_reg_cache. I could merge those two functions
with a case for those.
Ok, could amend the name or comment so it's obvious this is for
volatiles.
Thanks
Liam
--
Freelance Developer, SlimLogic Ltd
ASoC and Voltage Regulator Maintainer.
http://www.slimlogic.co.uk
--
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
Re: [alsa-devel] [PATCHv4 0/7] TWL6030 audio codec initial support
On Wed, 2010-02-24 at 18:17 -0600, Olaya, Margarita wrote: -Original Message- From: Liam Girdwood [mailto:l...@slimlogic.co.uk] Sent: Wednesday, February 24, 2010 5:40 AM To: Olaya, Margarita Cc: alsa-de...@alsa-project.org; linux-omap@vger.kernel.org; broo...@opensource.wolfsonmicro.com Subject: Re: [PATCHv4 0/7] TWL6030 audio codec initial support On Tue, 2010-02-23 at 18:10 -0600, Olaya, Margarita wrote: Following patch series add initial support for TWL6030 codec driver. The patch set is based on the series sent from Misael Lopez in October 2009. Changes from v3: - Remove snd_soc_init_card function - Adapt to latest twl core changes based on Balaji's comment Regards, Margarita --- Misael Lopez Cruz (7): OMAP4: PMIC: Add support for twl6030 codec ASoC: TWL6030: Add twl6030 codec driver ASoC: TWL6030: Manual power-up/down sequences ASoC: TWL6030: Add support for low-power PLL ASoC: TWL6030: Add restrictions for low-power playback mode ASoC: TWL6030: Enable audio interrupt ASoC: TWL6030: Detect power-up sequence completion Btw, since this is a new driver can you rebase the 6 codec patches into a single patch. The second patch adds the basic support for the codec and the others add features, that way it could be easier to review. Some of the subsequent patches are actually removing chunks of code rather than just adding new features. In this case it's actually easier to review the complete codec driver as one patch rather than a series of changes (showing your internal development history). Thanks Liam -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk -- 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
Re: [PATCHv4 1/7] OMAP4: PMIC: Add support for twl6030 codec
On Tue, 2010-02-23 at 18:10 -0600, Olaya, Margarita wrote:
From: Misael Lopez Cruz x0052...@ti.com
In order to have TWL6030 CODEC driver as a platform driver, codec data
should be passed through twl_platform_data structure.
For twl6030 audio codec, the following data may be passed:
- audpwron_gpio: gpio line used to power-up/down the codec. A low-to-high
transition powers codec up. Setting audpwron_gpio to a negative value
means that codec will use manual power sequence instead of automatic
sequence
- naudint_irq: irq line for audio interrupt. twl6030 drives NAUDINT line
to low when an interrupt (codec ready, plug insertion/removal, etc) is
detected
However, codec driver can operate if any or none of them are passed.
Signed-off-by: Misael Lopez Cruz x0052...@ti.com
Signed-off-by: Margarita Olaya Cabrera magi.ol...@ti.com
Signed-off-by: Jorge Eduardo Candelaria jorge.candela...@ti.com
It would be good to get Samuel's Ack on this as it touches MFD.
Samuel are you OK with this ?
---
drivers/mfd/twl-core.c | 18 +++---
include/linux/i2c/twl.h |4
2 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index 514e1e4..7e3b0d7 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -118,7 +118,8 @@
#define twl_has_watchdog()false
#endif
-#if defined(CONFIG_TWL4030_CODEC) || defined(CONFIG_TWL4030_CODEC_MODULE)
+#if defined(CONFIG_TWL4030_CODEC) || defined(CONFIG_TWL4030_CODEC_MODULE) ||\
+ defined(CONFIG_SND_SOC_TWL6030) ||
defined(CONFIG_SND_SOC_TWL6030_MODULE)
#define twl_has_codec() true
#else
#define twl_has_codec() false
@@ -735,8 +736,19 @@ add_children(struct twl4030_platform_data *pdata,
unsigned long features)
return PTR_ERR(child);
}
- if (twl_has_codec() pdata-codec) {
- child = add_child(1, twl4030_codec,
+ if (twl_has_codec() pdata-codec twl_class_is_4030()) {
+ sub_chip_id = twl_map[TWL_MODULE_AUDIO_VOICE].sid;
+ child = add_child(sub_chip_id, twl4030_codec,
+ pdata-codec, sizeof(*pdata-codec),
+ false, 0, 0);
+ if (IS_ERR(child))
+ return PTR_ERR(child);
+ }
+
+ /* Phoenix*/
+ if (twl_has_codec() pdata-codec twl_class_is_6030()) {
+ sub_chip_id = twl_map[TWL_MODULE_AUDIO_VOICE].sid;
+ child = add_child(sub_chip_id, twl6030_codec,
pdata-codec, sizeof(*pdata-codec),
false, 0, 0);
if (IS_ERR(child))
diff --git a/include/linux/i2c/twl.h b/include/linux/i2c/twl.h
index 9cf6cd7..d943c8b 100644
--- a/include/linux/i2c/twl.h
+++ b/include/linux/i2c/twl.h
@@ -556,6 +556,10 @@ struct twl4030_codec_data {
unsigned intaudio_mclk;
struct twl4030_codec_audio_data *audio;
struct twl4030_codec_vibra_data *vibra;
+
+ /* twl6030 */
+ int audpwron_gpio; /* audio power-on gpio */
+ int naudint_irq;/* audio interrupt */
};
struct twl4030_platform_data {
Liam
--
Freelance Developer, SlimLogic Ltd
ASoC and Voltage Regulator Maintainer.
http://www.slimlogic.co.uk
--
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
Re: [PATCHv4 2/7] ASoC: TWL6030: Add twl6030 codec driver
On Tue, 2010-02-23 at 18:10 -0600, Olaya, Margarita wrote:
From: Misael Lopez Cruz x0052...@ti.com
Initial version of TWL6030 codec driver.
The TWL6030 codec uses a propietary PDM-based digital audio interface.
Audio paths supported are:
- Input: Main Mic, Sub Mic, Headset Mic, Auxiliary-FM Left/Right
- Output: Headset Left/Right, Handsfree Left/Right
Signed-off-by: Misael Lopez Cruz x0052...@ti.com
Signed-off-by: Jorge Eduardo Candelaria jorge.candela...@ti.com
Signed-off-by: Margarita Olaya Cabrera magi.ol...@ti.com
---
sound/soc/codecs/Kconfig |4 +
sound/soc/codecs/Makefile |2 +
sound/soc/codecs/twl6030.c | 823
sound/soc/codecs/twl6030.h | 94 +
4 files changed, 923 insertions(+), 0 deletions(-)
create mode 100644 sound/soc/codecs/twl6030.c
create mode 100644 sound/soc/codecs/twl6030.h
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 52b005f..3b3d739 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -33,6 +33,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_TPA6130A2 if I2C
select SND_SOC_TLV320DAC33 if I2C
select SND_SOC_TWL4030 if TWL4030_CORE
+ select SND_SOC_TWL6030 if TWL4030_CORE
select SND_SOC_UDA134X
select SND_SOC_UDA1380 if I2C
select SND_SOC_WM8350 if MFD_WM8350
@@ -155,6 +156,9 @@ config SND_SOC_TWL4030
select TWL4030_CODEC
tristate
+config SND_SOC_TWL6030
+ tristate
+
config SND_SOC_UDA134X
tristate
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index dbaecb1..e11a193 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -20,6 +20,7 @@ snd-soc-tlv320aic26-objs := tlv320aic26.o
snd-soc-tlv320aic3x-objs := tlv320aic3x.o
snd-soc-tlv320dac33-objs := tlv320dac33.o
snd-soc-twl4030-objs := twl4030.o
+snd-soc-twl6030-objs := twl6030.o
snd-soc-uda134x-objs := uda134x.o
snd-soc-uda1380-objs := uda1380.o
snd-soc-wm8350-objs := wm8350.o
@@ -76,6 +77,7 @@ obj-$(CONFIG_SND_SOC_TLV320AIC26) +=
snd-soc-tlv320aic26.o
obj-$(CONFIG_SND_SOC_TLV320AIC3X) += snd-soc-tlv320aic3x.o
obj-$(CONFIG_SND_SOC_TLV320DAC33) += snd-soc-tlv320dac33.o
obj-$(CONFIG_SND_SOC_TWL4030) += snd-soc-twl4030.o
+obj-$(CONFIG_SND_SOC_TWL6030) += snd-soc-twl6030.o
obj-$(CONFIG_SND_SOC_UDA134X) += snd-soc-uda134x.o
obj-$(CONFIG_SND_SOC_UDA1380) += snd-soc-uda1380.o
obj-$(CONFIG_SND_SOC_WM8350) += snd-soc-wm8350.o
diff --git a/sound/soc/codecs/twl6030.c b/sound/soc/codecs/twl6030.c
new file mode 100644
index 000..8b52aa1
--- /dev/null
+++ b/sound/soc/codecs/twl6030.c
@@ -0,0 +1,823 @@
+/*
+ * ALSA SoC TWL6030 codec driver
+ *
+ * Author: Misael Lopez Cruz x0052...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include linux/module.h
+#include linux/moduleparam.h
+#include linux/init.h
+#include linux/delay.h
+#include linux/pm.h
+#include linux/i2c.h
+#include linux/gpio.h
+#include linux/platform_device.h
+#include linux/i2c/twl.h
+
+#include sound/core.h
+#include sound/pcm.h
+#include sound/pcm_params.h
+#include sound/soc.h
+#include sound/soc-dapm.h
+#include sound/initval.h
+#include sound/tlv.h
+
+#include twl6030.h
+
+#define TWL6030_RATES (SNDRV_PCM_RATE_96000)
+#define TWL6030_FORMATS (SNDRV_PCM_FMTBIT_S32_LE)
+
+/* codec private data */
+struct twl6030_data {
+ struct snd_soc_codec codec;
+ int audpwron;
+ int codec_powered;
+};
+
+/*
+ * twl6030 register cache default register settings
+ */
+static const u8 twl6030_reg[TWL6030_CACHEREGNUM] = {
+ 0x00, /* not used 0x00*/
+ 0x4B, /* TWL6030_ASICID (ro)0x01*/
+ 0x00, /* TWL6030_ASICREV (ro) 0x02*/
+ 0x00, /* TWL6030_INTID 0x03*/
+ 0x7B, /* TWL6030_INTMR 0x04*/
+ 0x00, /* TWL6030_NCPCTRL0x05*/
+ 0x00, /* TWL6030_LDOCTL 0x06*/
+ 0x00, /* TWL6030_HPPLLCTL 0x07*/
+ 0x00, /* TWL6030_LPPLLCTL 0x08*/
+ 0x00, /* TWL6030_LPPLLDIV 0x09*/
+ 0x00, /* TWL6030_AMICBCTL 0x0A*/
+ 0x00, /* TWL6030_DMICBCTL 0x0B*/
+
Re: [PATCHv4 3/7] ASoC: TWL6030: Manual power-up/down sequences
On Tue, 2010-02-23 at 18:10 -0600, Olaya, Margarita wrote:
From: Misael Lopez Cruz x0052...@ti.com
TWL6030 codec device can be powered-up/down through a specific register
writes sequence. These sequences can be used when no gpio line is
provided for AUDPWRON.
When the codec is powered-up in this way, automatic power-down sequence
(triggered by thermal shutdown) is not possible.
Signed-off-by: Misael Lopez Cruz x0052...@ti.com
Signed-off-by: Jorge Eduardo Candelaria jorge.candela...@ti.com
Signed-off-by: Margarita Olaya Cabrera magi.ol...@ti.com
---
sound/soc/codecs/twl6030.c | 112 ++-
sound/soc/codecs/twl6030.h | 16 ++
2 files changed, 115 insertions(+), 13 deletions(-)
diff --git a/sound/soc/codecs/twl6030.c b/sound/soc/codecs/twl6030.c
index 8b52aa1..ec838b1 100644
--- a/sound/soc/codecs/twl6030.c
+++ b/sound/soc/codecs/twl6030.c
@@ -244,6 +244,88 @@ static void twl6030_init_vdd_regs(struct snd_soc_codec
*codec)
}
}
+/* twl6030 codec manual power-up sequence */
+static void twl6030_power_up(struct snd_soc_codec *codec)
+{
+ u8 ncpctl, ldoctl, lppllctl, accctl;
+
+ ncpctl = twl6030_read_reg_cache(codec, TWL6030_REG_NCPCTL);
+ ldoctl = twl6030_read_reg_cache(codec, TWL6030_REG_LDOCTL);
+ lppllctl = twl6030_read_reg_cache(codec, TWL6030_REG_LPPLLCTL);
+ accctl = twl6030_read_reg_cache(codec, TWL6030_REG_ACCCTL);
+
+ /* enable reference system */
+ ldoctl |= TWL6030_REFENA;
+ twl6030_write(codec, TWL6030_REG_LDOCTL, ldoctl);
+ mdelay(10);
+ /* enable internal oscillator */
+ ldoctl |= TWL6030_OSCENA;
+ twl6030_write(codec, TWL6030_REG_LDOCTL, ldoctl);
+ udelay(10);
+ /* enable high-side ldo */
+ ldoctl |= TWL6030_HSLDOENA;
+ twl6030_write(codec, TWL6030_REG_LDOCTL, ldoctl);
+ udelay(244);
+ /* enable negative charge pump */
+ ncpctl |= TWL6030_NCPENA | TWL6030_NCPOPEN;
+ twl6030_write(codec, TWL6030_REG_NCPCTL, ncpctl);
+ udelay(488);
+ /* enable low-side ldo */
+ ldoctl |= TWL6030_LSLDOENA;
+ twl6030_write(codec, TWL6030_REG_LDOCTL, ldoctl);
+ udelay(244);
+ /* enable low-power pll */
+ lppllctl |= TWL6030_LPLLENA;
+ twl6030_write(codec, TWL6030_REG_LPPLLCTL, lppllctl);
+ /* reset state machine */
+ accctl |= TWL6030_RESETSPLIT;
+ twl6030_write(codec, TWL6030_REG_ACCCTL, accctl);
+ mdelay(5);
+ accctl = ~TWL6030_RESETSPLIT;
+ twl6030_write(codec, TWL6030_REG_ACCCTL, accctl);
+ /* disable internal oscillator */
+ ldoctl = ~TWL6030_OSCENA;
+ twl6030_write(codec, TWL6030_REG_LDOCTL, ldoctl);
+}
+
+/* twl6030 codec manual power-down sequence */
+static void twl6030_power_down(struct snd_soc_codec *codec)
+{
+ u8 ncpctl, ldoctl, lppllctl, accctl;
+
+ ncpctl = twl6030_read_reg_cache(codec, TWL6030_REG_NCPCTL);
+ ldoctl = twl6030_read_reg_cache(codec, TWL6030_REG_LDOCTL);
+ lppllctl = twl6030_read_reg_cache(codec, TWL6030_REG_LPPLLCTL);
+ accctl = twl6030_read_reg_cache(codec, TWL6030_REG_ACCCTL);
+
+ /* enable internal oscillator */
+ ldoctl |= TWL6030_OSCENA;
+ twl6030_write(codec, TWL6030_REG_LDOCTL, ldoctl);
+ udelay(10);
+ /* disable low-power pll */
+ lppllctl = ~TWL6030_LPLLENA;
+ twl6030_write(codec, TWL6030_REG_LPPLLCTL, lppllctl);
+ /* disable low-side ldo */
+ ldoctl = ~TWL6030_LSLDOENA;
+ twl6030_write(codec, TWL6030_REG_LDOCTL, ldoctl);
+ udelay(244);
+ /* disable negative charge pump */
+ ncpctl = ~(TWL6030_NCPENA | TWL6030_NCPOPEN);
+ twl6030_write(codec, TWL6030_REG_NCPCTL, ncpctl);
+ udelay(488);
+ /* disable high-side ldo */
+ ldoctl = ~TWL6030_HSLDOENA;
+ twl6030_write(codec, TWL6030_REG_LDOCTL, ldoctl);
+ udelay(244);
+ /* disable internal oscillator */
+ ldoctl = ~TWL6030_OSCENA;
+ twl6030_write(codec, TWL6030_REG_LDOCTL, ldoctl);
+ /* disable reference system */
+ ldoctl = ~TWL6030_REFENA;
+ twl6030_write(codec, TWL6030_REG_LDOCTL, ldoctl);
+ mdelay(10);
+}
+
/*
Some large mdelays here again.
Liam
--
Freelance Developer, SlimLogic Ltd
ASoC and Voltage Regulator Maintainer.
http://www.slimlogic.co.uk
--
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
Re: [PATCHv4 0/7] TWL6030 audio codec initial support
On Tue, 2010-02-23 at 18:10 -0600, Olaya, Margarita wrote: Following patch series add initial support for TWL6030 codec driver. The patch set is based on the series sent from Misael Lopez in October 2009. Changes from v3: - Remove snd_soc_init_card function - Adapt to latest twl core changes based on Balaji's comment Regards, Margarita --- Misael Lopez Cruz (7): OMAP4: PMIC: Add support for twl6030 codec ASoC: TWL6030: Add twl6030 codec driver ASoC: TWL6030: Manual power-up/down sequences ASoC: TWL6030: Add support for low-power PLL ASoC: TWL6030: Add restrictions for low-power playback mode ASoC: TWL6030: Enable audio interrupt ASoC: TWL6030: Detect power-up sequence completion Btw, since this is a new driver can you rebase the 6 codec patches into a single patch. Thanks Liam -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk -- 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
Re: [alsa-devel] [PATCHv5 0/2] McBSP: OMAP3: Add sidetone feature
On Mon, 2010-02-22 at 16:18 +0200, Peter Ujfalusi wrote: On Monday 22 February 2010 14:21:10 Koskinen Ilkka (Nokia-D/Tampere) wrote: The first patch implements McBSP sidetone feature on OMAP3 while the second one provides ALSA interface for using it. The patch set is based on the patch Eduardo Valentin sent to alsa-devel mailing list in October 2009. Channel gain control and enabling the sidetone have been moved to ALSA interface as suggested in comments. These patches apply on top of Janusz Krzysztofik's McBSP register cache patches in linux-omap-2.6.git Since the version 4, ASoC part has been modified to deal with McBSP ids consistently (zero based indexing). Eero Nurkkala (1): McBSP: OMAP3: Add sidetone feature Ilkka Koskinen (1): ASoC: OMAP-McBSP: ASoC interface for McBSP sidetone arch/arm/mach-omap2/mcbsp.c |2 + arch/arm/plat-omap/include/plat/mcbsp.h | 60 + arch/arm/plat-omap/mcbsp.c | 402 ++- sound/soc/omap/omap-mcbsp.c | 138 +++ sound/soc/omap/omap-mcbsp.h |2 + 5 files changed, 603 insertions(+), 1 deletions(-) Both looks OK for me: Acked-by: Peter Ujfalusi peter.ujfal...@nokia.com Acked-by: Liam Girdwood l...@slimlogic.co.uk -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk -- 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
Re: [PATCH 2/2] twl6030: regulator: Configure STATE register instead of REMAP
On Wed, 2010-02-17 at 20:54 +0530, Rajendra Nayak wrote: This is no REMAP register on twl6030, instead there is a STATE register to drive a resource to a given state. The state register can be used to specify what state the resource should enter when its associated with a GRP. Register Bit field description is as below. The patch programmes the corresponding STATE registers for all LDO's to turn ON when assocaited with GRP_P1. STATE REG: Bit7 |Bit6 |Bit5 |Bit4 |Bit3 |Bit2 |Bit1 |Bit0 P3_GRP |P2_GRP |P1_GRP |RES |RES |RES |State1 |State0 State can be specified as below 00: OFF 01: ON 10: OFF 11: SLEEP Signed-off-by: Rajendra Nayak rna...@ti.com Cc: Liam Girdwood l...@slimlogic.co.uk Cc: Samuel Ortiz sa...@linux.intel.com Cc: Mark Brown broo...@opensource.wolfsonmicro.com --- Applied. Thanks Liam -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk -- 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
Re: [alsa-devel] [PATCHv3 3/4] Add ASoC support for DevKit8000
On Wed, 2010-02-10 at 20:23 +0100, Thomas Weber wrote: This patch expands the omap3beagle sound soc for the beagle board clone Devkit8000. Change log V2 Expand omap3beagle sound soc for DevKit8000 support. V3 Separate Kconfig for Devkit8000. Signed-off-by: Thomas Weber sw...@gmx.li --- sound/soc/omap/Kconfig |8 sound/soc/omap/Makefile |1 + sound/soc/omap/omap3beagle.c |6 +++--- 3 files changed, 12 insertions(+), 3 deletions(-) diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig index 61952aa..8520b75 100644 --- a/sound/soc/omap/Kconfig +++ b/sound/soc/omap/Kconfig @@ -101,6 +101,14 @@ config SND_OMAP_SOC_OMAP3_BEAGLE help Say Y if you want to add support for SoC audio on the Beagleboard. +config SND_OMAP_SOC_DEVKIT8000 + tristate SoC Audio support for DevKit8000 + depends on TWL4030_CORE SND_OMAP_SOC MACH_DEVKIT8000 + select SND_OMAP_SOC_MCBSP + select SND_SOC_TWL4030 + help + Say Y if you want to add support for SoC audio on the DevKit8000 + Since this shares the same mach driver as beagle you should share the Kconfig option too (like the Overo). Thanks Liam -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk -- 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
Re: [alsa-devel] [PATCHv3 3/4] Add ASoC support for DevKit8000
On Thu, 2010-02-11 at 12:40 +0200, Jarkko Nikula wrote: On Thu, 11 Feb 2010 09:55:12 + Liam Girdwood l...@slimlogic.co.uk wrote: Since this shares the same mach driver as beagle you should share the Kconfig option too (like the Overo). Heh, I had just an opposite view :-) http://mailman.alsa-project.org/pipermail/alsa-devel/2010-February/025124.html Heh, didn't see that. ;) I do agree this makes good sense for boards that are very similar and have different audio options/config, but in this case the ASoC mach drivers are identical (atm). Imo it just makes more sense to keep the one Kconfig. Liam -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk -- 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
Re: [RESEND][PATCHv2 3/4] Add ASoC support for Devkit8000
On Thu, 2010-02-11 at 16:13 +0100, Thomas Weber wrote: This patch expands the omap3beagle sound soc for the beagle board clone DevKit8000. Signed-off-by: Thomas Weber we...@corscience.de Acked-by: Liam Girdwood l...@slimlogic.co.uk -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk -- 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
Re: [PATCHv2 1/4] Regulator: OMAP: Creating TWL4030 file having supplies init data
On Fri, 2010-02-05 at 10:45 +0200, Eduardo Valentin wrote:
Hello Anuj,
First of all, I liked the idea of unifying the regulator definitions
for boards that use twl regulators.
But I guess we need to improve a little bit.
See following comments.
On Tue, Jan 12, 2010 at 10:13:52AM +0100, ext 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, using
the twl4030-pmic.h header file.
Signed-off-by: Anuj Aggarwal anuj.aggar...@ti.com
---
arch/arm/mach-omap2/twl4030-pmic.c | 175
arch/arm/mach-omap2/twl4030-pmic.h | 34 +++
2 files changed, 209 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/twl4030-pmic.c
create mode 100644 arch/arm/mach-omap2/twl4030-pmic.h
diff --git a/arch/arm/mach-omap2/twl4030-pmic.c
b/arch/arm/mach-omap2/twl4030-pmic.c
new file mode 100644
index 000..0c0a860
--- /dev/null
+++ b/arch/arm/mach-omap2/twl4030-pmic.c
@@ -0,0 +1,175 @@
+/*
+ * twl4030-pmic.c
+ *
+ * Common regulator supplies and init data structs for TWL4030/TPS65950
+ * PMIC for OMAP3 based EVMs. They can be used in various board-evm
+ * files for OMAP3 based platforms using TWL4030.
+ *
+ * Copyright (C) 2010 Texas Instrument Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any kind,
+ * whether express or implied; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+
+#include linux/regulator/machine.h
+
+/* VDAC */
+struct regulator_consumer_supply twl4030_vdac_supply = {
+ .supply = vdac,
+};
+
+/* VMMC1 */
+struct regulator_consumer_supply twl4030_vmmc1_supply = {
+ .supply = vmmc,
+};
+
+/* VMMC2 */
+struct regulator_consumer_supply twl4030_vmmc2_supply = {
+ .supply = vmmc,
+};
+
+/* VSIM */
+struct regulator_consumer_supply twl4030_vsim_supply = {
+ .supply = vmmc_aux,
+};
+
+/* VPLL2 for digital video outputs */
+struct regulator_consumer_supply twl4030_vpll2_supply = {
+ .supply = vdvi,
+};
Ohh no! This is not good! Defining here the supply list would make things
harder.
Because from board to board the supply list will change! That's the
whole point of having the supply list. We can't share them for all boards
definitions.
OK, my understanding here was that this change was only to support a set
of similar OMAP + TWL4030 boards and not *all* OMAP + TWL4030 boards.
Anuj, what were your intentions here ?
Thanks
Liam
--
Freelance Developer, SlimLogic Ltd
ASoC and Voltage Regulator Maintainer.
http://www.slimlogic.co.uk
--
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
Re: [alsa-devel] [PATCH 1/1] ASoC: AIC23: Fixing writes to non-existing registers in resume function
On Fri, 2010-01-29 at 13:58 +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 Acked-by: Liam Girdwood l...@slimlogic.co.uk -- 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
Re: [alsa-devel] [PATCH 2/2] ASoC: OMAP-McBSP: ASoC interface for McBSP sidetone
On Thu, 2010-01-28 at 17:46 +0200, Ilkka Koskinen wrote:
Add ASoC interface for OMAP McBSP2 and McBSP3 sidetones.
Signed-off-by: Ilkka Koskinen ilkka.koski...@nokia.com
---
sound/soc/omap/omap-mcbsp.c | 187
+++
sound/soc/omap/omap-mcbsp.h |2 +
2 files changed, 189 insertions(+), 0 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index 6bbbd2a..295620b 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -39,6 +39,14 @@
snip
+/* McBSP Sidetone Switch */
+static const char *omap_mcbsp_st_status[] = {
+ off,
+ on,
+};
+
Should this not be a switch (like a mute switch) rather than an enum
kcontrol ?
+static const struct soc_enum omap_mcbsp_st_status_enum[] = {
+ SOC_ENUM_SINGLE_EXT(ARRAY_SIZE(omap_mcbsp_st_status),
+ omap_mcbsp_st_status),
+};
+
+static const struct snd_kcontrol_new omap_mcbsp2_st_controls[] = {
+ SOC_ENUM_EXT(McBSP2 Sidetone Switch, omap_mcbsp_st_status_enum[0],
+ omap_mcbsp2_st_get_mode, omap_mcbsp2_st_set_mode),
+ OMAP_MCBSP_SOC_SINGLE_S16_EXT(McBSP2 Sidetone Channel 0 Volume,
+ -32768, 32767,
+ omap_mcbsp2_get_st_ch0_volume,
+ omap_mcbsp2_set_st_ch0_volume),
+ OMAP_MCBSP_SOC_SINGLE_S16_EXT(McBSP2 Sidetone Channel 1 Volume,
+ -32768, 32767,
+ omap_mcbsp2_get_st_ch1_volume,
+ omap_mcbsp2_set_st_ch1_volume),
+};
+
+static const struct snd_kcontrol_new omap_mcbsp3_st_controls[] = {
+ SOC_ENUM_EXT(McBSP3 Sidetone Switch, omap_mcbsp_st_status_enum[0],
+ omap_mcbsp3_st_get_mode, omap_mcbsp3_st_set_mode),
+ OMAP_MCBSP_SOC_SINGLE_S16_EXT(McBSP3 Sidetone Channel 0 Volume,
+ -32768, 32767,
+ omap_mcbsp3_get_st_ch0_volume,
+ omap_mcbsp3_set_st_ch0_volume),
+ OMAP_MCBSP_SOC_SINGLE_S16_EXT(McBSP3 Sidetone Channel 1 Volume,
+ -32768, 32767,
+ omap_mcbsp3_get_st_ch1_volume,
+ omap_mcbsp3_set_st_ch1_volume),
+};
+
+int omap_mcbsp_st_add_controls(struct snd_soc_codec *codec, int mcbsp_id)
+{
+ if (!cpu_is_omap34xx())
+ return -ENODEV;
+
+ switch (mcbsp_id) {
+ case 2: /* McBSP 2 */
+ return snd_soc_add_controls(codec, omap_mcbsp2_st_controls,
+ ARRAY_SIZE(omap_mcbsp2_st_controls));
+ case 3: /* McBSP 3 */
+ return snd_soc_add_controls(codec, omap_mcbsp3_st_controls,
+ ARRAY_SIZE(omap_mcbsp3_st_controls));
+ default:
+ break;
+ }
+
+ return -1;
-EINVAL;
+}
+EXPORT_SYMBOL_GPL(omap_mcbsp_st_add_controls);
+
static int __init snd_omap_mcbsp_init(void)
{
return snd_soc_register_dais(omap_mcbsp_dai,
diff --git a/sound/soc/omap/omap-mcbsp.h b/sound/soc/omap/omap-mcbsp.h
index 647d2f9..7537435 100644
--- a/sound/soc/omap/omap-mcbsp.h
+++ b/sound/soc/omap/omap-mcbsp.h
@@ -57,4 +57,6 @@ enum omap_mcbsp_div {
extern struct snd_soc_dai omap_mcbsp_dai[NUM_LINKS];
+int omap_mcbsp_st_add_controls(struct snd_soc_codec *codec, int mcbsp_id);
+
#endif
--
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
RE: [alsa-devel] [PATCHv2 5/6] ASoC: OMAP4: Add support for McPDM
On Mon, 2010-01-25 at 15:06 -0600, Candelaria Villareal, Jorge wrote:
Liam Girdwood wrote:
On Fri, 2010-01-22 at 17:15 -0600, Candelaria Villareal, Jorge wrote:
McPDM is the interface between Phoenix audio codec
and the OMAP4430 processor. It enables data to be transfered
to/from Phoenix at sample rates of 88.4 or 96 KHz.
Signed-off-by: Jorge Eduardo Candelaria x0107...@ti.com
Signed-off-by: Margarita Olaya x0080...@ti.com
It initially looks like a some of this can be called directly
as DAI ops
rather than by the machine driver.
Could you explain a little further?
I was meaning here that some of the functions below are only called by
higher level Digital Audio Interface (DAI) operations. e.g. the
following is called by capture stream close :-
+ * Cleans McPDM uplink configuration.
+ * This function should be called when the stream is closed.
+ */
+int omap_mcpdm_clr_uplink(struct omap_mcpdm_link *uplink)
Would probably be more meaningful wrt ALSA as
omap_mcpdm_capture_close()
+/*
+ * Takes the McPDM module in and out of reset state.
+ * Uplink and downlink can be reset individually.
+ */
+static void omap_mcpdm_reset(int links, int reset)
+{
+ int ctrl = omap_mcpdm_read(MCPDM_CTRL);
+
+ if (links MCPDM_UPLINK) {
+ if (reset)
+ ctrl |= SW_UP_RST;
+ else
+ ctrl = ~SW_UP_RST;
+ }
+
+ if (links MCPDM_DOWNLINK) {
+ if (reset)
+ ctrl |= SW_DN_RST;
+ else
+ ctrl = ~SW_DN_RST;
+ }
+
+ omap_mcpdm_write(MCPDM_CTRL, ctrl);
+}
+
Would it not be better to rename uplink/downlink as playback
and capture
for ALSA ? If so, you could have an inline playback and
capture version
of this function.
Data paths in McPDM module are named uplink/downlink, so these
names were chosen to be consistent. Is renaming it according
to ALSA the best approach?
Generally yes, as long as we can see the audio direction easily (a
comment would do here).
Fwiw, I would have written the above as :-
static inline void omap_mcpdm_reset_playback(int reset)
{
int ctrl = omap_mcpdm_read(MCPDM_CTRL);
if (reset)
ctrl |= SW_UP_RST;
else
ctrl = ~SW_UP_RST;
omap_mcpdm_write(MCPDM_CTRL, ctrl);
}
and one for capture reset too.
+int omap_mcpdm_set_offset(int offset1, int offset2)
+{
+ int offset;
+
+ if ((offset1 DN_OFST_MAX) || (offset2 DN_OFST_MAX))
+ return -EINVAL;
+
+ offset = (offset1 DN_OFST_RX1) | (offset2
DN_OFST_RX2);
+
+ /* Enable/disable offset cancellation for downlink
channel 1 */
+ if (offset1)
+ offset |= DN_OFST_RX1_EN;
+ else
+ offset = ~DN_OFST_RX1_EN;
+
+ /* Enable/disable offset cancellation for downlink
channel 2 */
+ if (offset2)
+ offset |= DN_OFST_RX2_EN;
+ else
+ offset = ~DN_OFST_RX2_EN;
+
+ omap_mcpdm_write(MCPDM_DN_OFFSET, offset);
+
+ return 0;
+}
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 static. But,
offset cancelation is probably not going to be used at first.
Ok, can we a comment to here to describe this.
Thanks
Liam
--
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
Re: [alsa-devel] [PATCHv2 6/6] ASoC: OMAP4: Add McPDM platform driver
On Tue, 2010-01-26 at 10:27 +0200, Jarkko Nikula wrote:
Hi
On Mon, 25 Jan 2010 15:06:44 -0600
Candelaria Villareal, Jorge jorge.candela...@ti.com wrote:
+static int omap_mcpdm_dai_startup(struct snd_pcm_substream
*substream,
+ struct snd_soc_dai *dai)
+{
+ struct snd_soc_pcm_runtime *rtd = substream-private_data;
+ struct snd_soc_dai *cpu_dai = rtd-dai-cpu_dai;
+ int err = 0;
+
+ if (!cpu_dai-active)
+ err = omap_mcpdm_request();
Will anything else use this hw interface other than ALSA audio ?
If not, the request is probably better in the machine driver probe().
omap_mcpdm_request will enable the functional clock. Isn't it better
for the clock to be enabled only when is about to get used?
Definitely yes if there is no any need to keep block active after the
request. That would help the power-management if there are no active
clocks when the streams are suspended with omap_mcpdm_stop() but the
block remains reserved (i.e. omap_mcpdm_free is not called).
Ah ok, it seems that some other platforms have similar get_resource_x()
functions that do not additionally call their clk_enable_resource_x().
(last time I looked).
This is fine.
Liam
--
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
Re: [alsa-devel] [PATCHv2 1/6] ASoC: OMAP: data_type and sync_mode configurable in audio dma
On Fri, 2010-01-22 at 17:14 -0600, Candelaria Villareal, Jorge wrote: From: Misael Lopez Cruz x0052...@ti.com Allow client drivers to set the data_type (16, 32) and the sync_mode (element, packet, etc) of the audio dma transferences. Btw, how is 32bit mode used here ? Is it for compacted 2 channel 16 bit stereo or 24bit HiFi on 4 byte boundaries ? Liam -- 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
Re: [alsa-devel] [PATCHv2 6/6] ASoC: OMAP4: Add McPDM platform driver
On Fri, 2010-01-22 at 17:15 -0600, Candelaria Villareal, Jorge wrote:
From: Misael Lopez Cruz x0052...@ti.com
McPDM platform driver is configured to use sDMA in order to transfer
to/from memory. Support for interfacing with ABE will be added later.
McPDM dai currently supports up to 4 downlink channels and 2 uplink
channels simultaneously, as well as 88.2 and 96 KHz, and a sample
size of 32 bits.
Signed-off-by: Misael Lopez Cruz x0052...@ti.com
Signed-off-by: Margarita Olaya x0080...@ti.com
Signed-off-by: Jorge Eduardo Candelaria x0107...@ti.com
---
sound/soc/omap/Makefile |2 +-
sound/soc/omap/omap-mcpdm.c | 250
+++
sound/soc/omap/omap-mcpdm.h | 29 +
3 files changed, 280 insertions(+), 1 deletions(-)
create mode 100644 sound/soc/omap/omap-mcpdm.c
create mode 100644 sound/soc/omap/omap-mcpdm.h
diff --git a/sound/soc/omap/Makefile b/sound/soc/omap/Makefile
index bf8b388..d6382fa 100644
--- a/sound/soc/omap/Makefile
+++ b/sound/soc/omap/Makefile
@@ -1,7 +1,7 @@
# OMAP Platform Support
snd-soc-omap-objs := omap-pcm.o
snd-soc-omap-mcbsp-objs := omap-mcbsp.o
-snd-soc-omap-mcpdm-objs := mcpdm.o
+snd-soc-omap-mcpdm-objs := mcpdm.o omap-mcpdm.o
obj-$(CONFIG_SND_OMAP_SOC) += snd-soc-omap.o
obj-$(CONFIG_SND_OMAP_SOC_MCBSP) += snd-soc-omap-mcbsp.o
diff --git a/sound/soc/omap/omap-mcpdm.c b/sound/soc/omap/omap-mcpdm.c
new file mode 100644
index 000..180cca6
--- /dev/null
+++ b/sound/soc/omap/omap-mcpdm.c
@@ -0,0 +1,250 @@
+/*
+ * omap-mcpdm.c -- OMAP ALSA SoC DAI driver using McPDM port
+ *
+ * Copyright (C) 2009 Texas Instruments
+ *
+ * Author: Misael Lopez Cruz x0052...@ti.com
+ * Contact: Jorge Eduardo Candelaria x0107...@ti.com
+ * Margarita Olaya magi.ol...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include linux/init.h
+#include linux/module.h
+#include linux/device.h
+#include sound/core.h
+#include sound/pcm.h
+#include sound/pcm_params.h
+#include sound/initval.h
+#include sound/soc.h
+
+#include mach/control.h
+#include mach/dma.h
+#include mach/mcbsp.h
+#include mcpdm.h
+#include omap-mcpdm.h
+#include omap-pcm.h
+
+struct omap_mcpdm_data {
+ struct omap_mcpdm_link *links;
+ int active;
+};
+
+static struct omap_mcpdm_link omap_mcpdm_links[] = {
+ /* downlink */
+ {
+ .irq_mask = MCPDM_DN_IRQ_EMPTY | MCPDM_DN_IRQ_FULL,
+ .threshold = 1,
+ .format = PDMOUTFORMAT_LJUST,
+ },
+ /* uplink */
+ {
+ .irq_mask = MCPDM_UP_IRQ_EMPTY | MCPDM_UP_IRQ_FULL,
+ .threshold = 1,
+ .format = PDMOUTFORMAT_LJUST,
+ },
+};
+
+static struct omap_mcpdm_data mcpdm_data = {
+ .links = omap_mcpdm_links,
+ .active = 0,
+};
+
+/*
+ * Stream DMA parameters
+ */
+static struct omap_pcm_dma_data omap_mcpdm_dai_dma_params[] = {
+ {
+ .name = Audio downlink,
+ .dma_req = OMAP44XX_DMA_MCPDM_DL,
+ .data_type = OMAP_DMA_DATA_TYPE_S32,
+ .sync_mode = OMAP_DMA_SYNC_PACKET,
+ .packet_size = 16,
+ .port_addr = OMAP44XX_MCPDM_L3_BASE + MCPDM_DN_DATA,
+ },
+ {
+ .name = Audio uplink,
+ .dma_req = OMAP44XX_DMA_MCPDM_UP,
+ .data_type = OMAP_DMA_DATA_TYPE_S32,
+ .sync_mode = OMAP_DMA_SYNC_PACKET,
+ .packet_size = 16,
+ .port_addr = OMAP44XX_MCPDM_L3_BASE + MCPDM_UP_DATA,
+ },
+};
+
+static int omap_mcpdm_dai_startup(struct snd_pcm_substream *substream,
+ struct snd_soc_dai *dai)
+{
+ struct snd_soc_pcm_runtime *rtd = substream-private_data;
+ struct snd_soc_dai *cpu_dai = rtd-dai-cpu_dai;
+ int err = 0;
+
+ if (!cpu_dai-active)
+ err = omap_mcpdm_request();
Will anything else use this hw interface other than ALSA audio ?
If not, the request is probably better in the machine driver probe().
+
+ return err;
+}
+
+static void omap_mcpdm_dai_shutdown(struct snd_pcm_substream *substream,
+ struct snd_soc_dai *dai)
+{
+ struct snd_soc_pcm_runtime *rtd = substream-private_data;
+ struct snd_soc_dai *cpu_dai = rtd-dai-cpu_dai;
Re: [alsa-devel] [PATCHv2 5/6] ASoC: OMAP4: Add support for McPDM
On Fri, 2010-01-22 at 17:15 -0600, Candelaria Villareal, Jorge wrote:
McPDM is the interface between Phoenix audio codec
and the OMAP4430 processor. It enables data to be transfered
to/from Phoenix at sample rates of 88.4 or 96 KHz.
Signed-off-by: Jorge Eduardo Candelaria x0107...@ti.com
Signed-off-by: Margarita Olaya x0080...@ti.com
It initially looks like a some of this can be called directly as DAI ops
rather than by the machine driver.
---
sound/soc/omap/Kconfig |3 +
sound/soc/omap/Makefile |2 +
sound/soc/omap/mcpdm.c | 474
+++
sound/soc/omap/mcpdm.h | 152 +++
4 files changed, 631 insertions(+), 0 deletions(-)
create mode 100644 sound/soc/omap/mcpdm.c
create mode 100644 sound/soc/omap/mcpdm.h
diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig
index 61952aa..b96e9d8 100644
--- a/sound/soc/omap/Kconfig
+++ b/sound/soc/omap/Kconfig
@@ -6,6 +6,9 @@ config SND_OMAP_SOC_MCBSP
tristate
select OMAP_MCBSP
+config SND_OMAP_SOC_MCPDM
+ tristate
+
config SND_OMAP_SOC_N810
tristate SoC Audio support for Nokia N810
depends on SND_OMAP_SOC MACH_NOKIA_N810 I2C
diff --git a/sound/soc/omap/Makefile b/sound/soc/omap/Makefile
index 3db8a6c..bf8b388 100644
--- a/sound/soc/omap/Makefile
+++ b/sound/soc/omap/Makefile
@@ -1,9 +1,11 @@
# OMAP Platform Support
snd-soc-omap-objs := omap-pcm.o
snd-soc-omap-mcbsp-objs := omap-mcbsp.o
+snd-soc-omap-mcpdm-objs := mcpdm.o
obj-$(CONFIG_SND_OMAP_SOC) += snd-soc-omap.o
obj-$(CONFIG_SND_OMAP_SOC_MCBSP) += snd-soc-omap-mcbsp.o
+obj-$(CONFIG_SND_OMAP_SOC_MCPDM) += snd-soc-omap-mcpdm.o
# OMAP Machine Support
snd-soc-n810-objs := n810.o
diff --git a/sound/soc/omap/mcpdm.c b/sound/soc/omap/mcpdm.c
new file mode 100644
index 000..2bc5acd
--- /dev/null
+++ b/sound/soc/omap/mcpdm.c
@@ -0,0 +1,474 @@
+/*
+ * mcpdm.c -- McPDM interface driver
+ *
+ * Author: Jorge Eduardo Candelaria x0107...@ti.com
+ * Copyright (C) 2009 - Texas Instruments, Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include linux/module.h
+#include linux/init.h
+#include linux/device.h
+#include linux/platform_device.h
+#include linux/wait.h
+#include linux/interrupt.h
+#include linux/err.h
+#include linux/clk.h
+#include linux/delay.h
+#include linux/io.h
+#include linux/irq.h
+
+#include mcpdm.h
+
+static struct omap_mcpdm *mcpdm;
+
+static inline void omap_mcpdm_write(u16 reg, u32 val)
+{
+ __raw_writel(val, mcpdm-io_base + reg);
+}
+
+static inline int omap_mcpdm_read(u16 reg)
+{
+ return __raw_readl(mcpdm-io_base + reg);
+}
+
+void omap_mcpdm_reg_dump(void)
+{
+ dev_dbg(mcpdm-dev, ***\n);
+ dev_dbg(mcpdm-dev, IRQSTATUS_RAW: 0x%04x\n,
+ omap_mcpdm_read(MCPDM_IRQSTATUS_RAW));
+ dev_dbg(mcpdm-dev, IRQSTATUS: 0x%04x\n,
+ omap_mcpdm_read(MCPDM_IRQSTATUS));
+ dev_dbg(mcpdm-dev, IRQENABLE_SET: 0x%04x\n,
+ omap_mcpdm_read(MCPDM_IRQENABLE_SET));
+ dev_dbg(mcpdm-dev, IRQENABLE_CLR: 0x%04x\n,
+ omap_mcpdm_read(MCPDM_IRQENABLE_CLR));
+ dev_dbg(mcpdm-dev, IRQWAKE_EN: 0x%04x\n,
+ omap_mcpdm_read(MCPDM_IRQWAKE_EN));
+ dev_dbg(mcpdm-dev, DMAENABLE_SET: 0x%04x\n,
+ omap_mcpdm_read(MCPDM_DMAENABLE_SET));
+ dev_dbg(mcpdm-dev, DMAENABLE_CLR: 0x%04x\n,
+ omap_mcpdm_read(MCPDM_DMAENABLE_CLR));
+ dev_dbg(mcpdm-dev, DMAWAKEEN: 0x%04x\n,
+ omap_mcpdm_read(MCPDM_DMAWAKEEN));
+ dev_dbg(mcpdm-dev, CTRL: 0x%04x\n,
+ omap_mcpdm_read(MCPDM_CTRL));
+ dev_dbg(mcpdm-dev, DN_DATA: 0x%04x\n,
+ omap_mcpdm_read(MCPDM_DN_DATA));
+ dev_dbg(mcpdm-dev, UP_DATA: 0x%04x\n,
+ omap_mcpdm_read(MCPDM_UP_DATA));
+ dev_dbg(mcpdm-dev, FIFO_CTRL_DN: 0x%04x\n,
+ omap_mcpdm_read(MCPDM_FIFO_CTRL_DN));
+ dev_dbg(mcpdm-dev, FIFO_CTRL_UP: 0x%04x\n,
+ omap_mcpdm_read(MCPDM_FIFO_CTRL_UP));
+ dev_dbg(mcpdm-dev, DN_OFFSET: 0x%04x\n,
+
RE: [PATCHv2 0/4] Regulator: OMAP: Removing common code for TWL4030 from OMAP3- board-evms
On Wed, 2010-01-13 at 22:25 +0530, Aggarwal, Anuj wrote: Any comments on this version? Just had a quick scan, looks fine. Acked-by: Liam Girdwood l...@slimlogic.co.uk -- 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
Re: [alsa-devel] [PATCH] Fix build of OMAP sound drivers
On Thu, 2009-12-10 at 11:15 -0600, Olof Johansson wrote: There are build errors when building for some of the omap2/3 boards without enabling sound: sound/built-in.o:(.data+0x43bc): undefined reference to `soc_codec_dev_tlv320aic23' sound/built-in.o:(.data+0x43cc): undefined reference to `tlv320aic23_dai' Confused me quite a bit since the drivers that had references to the codec weren't enabled. Turns out the Makefile was using the wrong config option to enable them. Patch below. Reported-by: Anand Gadiyar gadi...@ti.com Signed-off-by: Olof Johansson o...@lixom.net Acked-by: Liam Girdwood l...@slimlogic.co.uk diff --git a/sound/soc/omap/Makefile b/sound/soc/omap/Makefile index d49458a..3db8a6c 100644 --- a/sound/soc/omap/Makefile +++ b/sound/soc/omap/Makefile @@ -23,9 +23,9 @@ obj-$(CONFIG_SND_OMAP_SOC_N810) += snd-soc-n810.o obj-$(CONFIG_SND_OMAP_SOC_AMS_DELTA) += snd-soc-ams-delta.o obj-$(CONFIG_SND_OMAP_SOC_OSK5912) += snd-soc-osk5912.o obj-$(CONFIG_SND_OMAP_SOC_OVERO) += snd-soc-overo.o -obj-$(CONFIG_MACH_OMAP2EVM) += snd-soc-omap2evm.o -obj-$(CONFIG_MACH_OMAP3EVM) += snd-soc-omap3evm.o -obj-$(CONFIG_MACH_OMAP3517EVM) += snd-soc-am3517evm.o +obj-$(CONFIG_SND_OMAP_SOC_OMAP2EVM) += snd-soc-omap2evm.o +obj-$(CONFIG_SND_OMAP_SOC_OMAP3EVM) += snd-soc-omap3evm.o +obj-$(CONFIG_SND_OMAP_SOC_OMAP3517EVM) += snd-soc-am3517evm.o obj-$(CONFIG_SND_OMAP_SOC_SDP3430) += snd-soc-sdp3430.o obj-$(CONFIG_SND_OMAP_SOC_OMAP3_PANDORA) += snd-soc-omap3pandora.o obj-$(CONFIG_SND_OMAP_SOC_OMAP3_BEAGLE) += snd-soc-omap3beagle.o ___ Alsa-devel mailing list alsa-de...@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel -- 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
Re: [alsa-devel] [PATCH] ASoC: OMAP: enable Overo driver for CM-T35
On Mon, 2009-11-16 at 15:53 +0200, Mike Rapoport wrote:
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
sound/soc/omap/Kconfig |7 ---
sound/soc/omap/overo.c |2 +-
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig
index 653a362..bb42681 100644
--- a/sound/soc/omap/Kconfig
+++ b/sound/soc/omap/Kconfig
@@ -43,12 +43,13 @@ config SND_OMAP_SOC_OSK5912
Say Y if you want to add support for SoC audio on osk5912.
config SND_OMAP_SOC_OVERO
- tristate SoC Audio support for Gumstix Overo
- depends on TWL4030_CORE SND_OMAP_SOC MACH_OVERO
+ tristate SoC Audio support for Gumstix Overo and CompuLab CM-T35
+ depends on TWL4030_CORE SND_OMAP_SOC (MACH_OVERO || MACH_CM_T35)
select SND_OMAP_SOC_MCBSP
select SND_SOC_TWL4030
help
- Say Y if you want to add support for SoC audio on the Gumstix Overo.
+ Say Y if you want to add support for SoC audio on the
+ Gumstix Overo or CompuLab CM-T35
config SND_OMAP_SOC_OMAP2EVM
tristate SoC Audio support for OMAP2EVM board
diff --git a/sound/soc/omap/overo.c b/sound/soc/omap/overo.c
index 624f40e..1bf440b 100644
--- a/sound/soc/omap/overo.c
+++ b/sound/soc/omap/overo.c
@@ -107,7 +107,7 @@ static int __init overo_soc_init(void)
{
int ret;
- if (!machine_is_overo()) {
+ if (!(machine_is_overo() || machine_is_cm_t35())) {
pr_debug(Not Overo!\n);
Its probably best to update the pr_debug message too.
Liam
--
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
Re: [alsa-devel] [PATCH] ASoC: OMAP: enable Overo driver for CM-T35
On Mon, 2009-11-16 at 16:19 +0200, Mike Rapoport wrote:
From 4f3628ff75bdeb57e751622f2a92e223f68e81e3 Mon Sep 17 00:00:00 2001
In-Reply-To: 1258380019.3570.113.ca...@odin
References: 1258380019.3570.113.ca...@odin
From: Mike Rapoport m...@compulab.co.il
Date: Mon, 16 Nov 2009 15:35:00 +0200
Subject: [PATCH] ASoC: OMAP: enable Overo driver for CM-T35
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
sound/soc/omap/Kconfig |7 ---
sound/soc/omap/overo.c |4 ++--
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig
index 653a362..bb42681 100644
--- a/sound/soc/omap/Kconfig
+++ b/sound/soc/omap/Kconfig
@@ -43,12 +43,13 @@ config SND_OMAP_SOC_OSK5912
Say Y if you want to add support for SoC audio on osk5912.
config SND_OMAP_SOC_OVERO
- tristate SoC Audio support for Gumstix Overo
- depends on TWL4030_CORE SND_OMAP_SOC MACH_OVERO
+ tristate SoC Audio support for Gumstix Overo and CompuLab CM-T35
+ depends on TWL4030_CORE SND_OMAP_SOC (MACH_OVERO || MACH_CM_T35)
select SND_OMAP_SOC_MCBSP
select SND_SOC_TWL4030
help
- Say Y if you want to add support for SoC audio on the Gumstix Overo.
+ Say Y if you want to add support for SoC audio on the
+ Gumstix Overo or CompuLab CM-T35
config SND_OMAP_SOC_OMAP2EVM
tristate SoC Audio support for OMAP2EVM board
diff --git a/sound/soc/omap/overo.c b/sound/soc/omap/overo.c
index 624f40e..c25f527 100644
--- a/sound/soc/omap/overo.c
+++ b/sound/soc/omap/overo.c
@@ -107,8 +107,8 @@ static int __init overo_soc_init(void)
{
int ret;
- if (!machine_is_overo()) {
- pr_debug(Not Overo!\n);
+ if (!(machine_is_overo() || machine_is_cm_t35())) {
+ pr_debug(Incomatible machine!\n);
return -ENODEV;
}
printk(KERN_INFO overo SoC init\n);
--
1.6.4.4
Acked-by: Liam Girdwood l...@slimlogic.co.uk
Thanks
Liam
--
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
Re: [PATCHv3 1/3] Regulator: Add TPS65023 regulator driver
On Fri, 2009-08-21 at 00:39 +0530, Anuj Aggarwal wrote: Adding support for TI TPS65023 regulator driver Signed-off-by: Anuj Aggarwal anuj.aggar...@ti.com --- drivers/regulator/tps65023-regulator.c | 631 1 files changed, 631 insertions(+), 0 deletions(-) create mode 100644 drivers/regulator/tps65023-regulator.c All Applied. Thanks Liam -- 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
Re: [PATCHv2 1/8] Regulator: Add TPS65023 regulator driver
On Wed, 2009-08-12 at 10:17 +0530, Anuj Aggarwal wrote:
Adding support for TI TPS65023 regulator driver
Signed-off-by: Anuj Aggarwal anuj.aggar...@ti.com
---
drivers/regulator/tps65023-regulator.c | 638
1 files changed, 638 insertions(+), 0 deletions(-)
create mode 100644 drivers/regulator/tps65023-regulator.c
diff --git a/drivers/regulator/tps65023-regulator.c
b/drivers/regulator/tps65023-regulator.c
new file mode 100644
index 000..dbaf295
--- /dev/null
+++ b/drivers/regulator/tps65023-regulator.c
@@ -0,0 +1,638 @@
+/*
+ * tps65023-regulator.c
+ *
+ * Supports TPS65023 Regulator
+ *
+ * Copyright (C) 2009 Texas Instrument Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any kind,
+ * whether express or implied; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/err.h
+#include linux/platform_device.h
+#include linux/regulator/driver.h
+#include linux/regulator/machine.h
+#include linux/i2c.h
+#include linux/delay.h
+
+/* Register definitions */
+#define TPS65023_REG_VERSION0
+#define TPS65023_REG_PGOODZ 1
+#define TPS65023_REG_MASK 2
+#define TPS65023_REG_REG_CTRL 3
+#define TPS65023_REG_CON_CTRL 4
+#define TPS65023_REG_CON_CTRL2 5
+#define TPS65023_REG_DEF_CORE 6
+#define TPS65023_REG_DEFSLEW7
+#define TPS65023_REG_LDO_CTRL 8
+
+/* PGOODZ bitfields */
+#define TPS65023_PGOODZ_PWRFAILZBIT(7)
+#define TPS65023_PGOODZ_LOWBATTZBIT(6)
+#define TPS65023_PGOODZ_VDCDC1 BIT(5)
+#define TPS65023_PGOODZ_VDCDC2 BIT(4)
+#define TPS65023_PGOODZ_VDCDC3 BIT(3)
+#define TPS65023_PGOODZ_LDO2BIT(2)
+#define TPS65023_PGOODZ_LDO1BIT(1)
+
+/* MASK bitfields */
+#define TPS65023_MASK_PWRFAILZ BIT(7)
+#define TPS65023_MASK_LOWBATTZ BIT(6)
+#define TPS65023_MASK_VDCDC1BIT(5)
+#define TPS65023_MASK_VDCDC2BIT(4)
+#define TPS65023_MASK_VDCDC3BIT(3)
+#define TPS65023_MASK_LDO2 BIT(2)
+#define TPS65023_MASK_LDO1 BIT(1)
+
+/* REG_CTRL bitfields */
+#define TPS65023_REG_CTRL_VDCDC1_EN BIT(5)
+#define TPS65023_REG_CTRL_VDCDC2_EN BIT(4)
+#define TPS65023_REG_CTRL_VDCDC3_EN BIT(3)
+#define TPS65023_REG_CTRL_LDO2_ENBIT(2)
+#define TPS65023_REG_CTRL_LDO1_ENBIT(1)
+
+/* LDO_CTRL bitfields */
+#define TPS65023_LDO_CTRL_LDOx_SHIFT(ldo_id) ((ldo_id)*4)
+#define TPS65023_LDO_CTRL_LDOx_MASK(ldo_id) (0xF0 ((ldo_id)*4))
+
+/* Number of step-down converters available */
+#define TPS65023_NUM_DCDC3
+/* Number of LDO voltage regulators available */
+#define TPS65023_NUM_LDO 2
+/* Number of total regulators available */
+#define TPS65023_NUM_REGULATOR (TPS65023_NUM_DCDC + TPS65023_NUM_LDO)
+
+/* DCDCs */
+#define TPS65023_DCDC_1 0
+#define TPS65023_DCDC_2 1
+#define TPS65023_DCDC_3 2
+/* LDOs */
+#define TPS65023_LDO_1 3
+#define TPS65023_LDO_2 4
+
+#define TPS65023_MAX_REG_ID TPS65023_LDO_2
+
+/* Supported voltage values for regulators */
+static const u16 VDCDC1_VSEL_table[] = {
+ 800, 825, 850, 875,
+ 900, 925, 950, 975,
+ 1000, 1025, 1050, 1075,
+ 1100, 1125, 1150, 1175,
+ 1200, 1225, 1250, 1275,
+ 1300, 1325, 1350, 1375,
+ 1400, 1425, 1450, 1475,
+ 1500, 1525, 1550, 1600,
+};
+
+static const u16 LDO1_VSEL_table[] = {
+ 1000, 1100, 1300, 1800,
+ 2200, 2600, 2800, 3150,
+};
+
+static const u16 LDO2_VSEL_table[] = {
+ 1050, 1200, 1300, 1800,
+ 2500, 2800, 3000, 3300,
+};
+
+static unsigned int num_voltages[] = {ARRAY_SIZE(VDCDC1_VSEL_table),
+ 0, 0, ARRAY_SIZE(LDO1_VSEL_table),
+ ARRAY_SIZE(LDO2_VSEL_table)};
+
+/* Regulator specific details */
+struct tps_info {
+ const char *name;
+ unsigned min_uV;
+ unsigned max_uV;
+ bool fixed;
+ u8 table_len;
+ const u16 *table;
+};
+
+/* PMIC details */
+struct tps_pmic {
+ struct regulator_desc desc[TPS65023_NUM_REGULATOR];
+ struct i2c_client *client;
+ struct regulator_dev *rdev[TPS65023_NUM_REGULATOR];
+ const struct tps_info
Re: [PATCH 1/8] Regulator: Add TPS65023 regulator driver
On Fri, 2009-08-07 at 16:53 +0100, Mark Brown wrote:
On Fri, Aug 07, 2009 at 08:55:26PM +0530, Anuj Aggarwal wrote:
+static const struct tps_info tps65023_regs[] = {
+ {
+ .name = VDCDC1,
+ .min_uV = 80,
+ .max_uV = 160,
+ .fixed = 0,
No need to add fixed = 0 in this array as compiler will do this for you.
+ .table_len = ARRAY_SIZE(VDCDC1_VSEL_table),
+ .table = VDCDC1_VSEL_table,
+ },
Indentation here is a bit non-standard - I'd expect either the {} around
the elements to be in column 0 or another level of indentation for the
fields.
+ {
+ .name = VDCDC2,
+ .min_uV = 330,
+ .max_uV = 330,
+ .fixed = 1,
+ .table_len = 0,
+ },
You could drop the fixed flag and just have fixed be inferred from
min_uV == max_uV?
To be honest I prefer having the fixed = 1 here. It stands out more and
imho keeps things simple. Also table_len could be omitted.
Thanks
Liam
--
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
Re: [PATCH] regulator core: fix double-free in regulator_register() error path
On Sat, 2009-04-25 at 05:28 -0600, Paul Walmsley wrote: During regulator registration, any error after device_register() will cause a double-free on the struct regulator_dev 'rdev'. The bug is in drivers/regulator/core.c:regulator_register(): ... scrub: device_unregister(rdev-dev); clean: kfree(rdev); --- rdev = ERR_PTR(ret); goto out; ... device_unregister() calls regulator_dev_release() which frees rdev. The subsequent kfree corrupts memory and causes some OMAP3 systems to oops on boot in regulator_get(). Applies against 2.6.30-rc3. Signed-off-by: Paul Walmsley p...@pwsan.com --- drivers/regulator/core.c |4 1 files changed, 4 insertions(+), 0 deletions(-) Applied. Thanks Liam -- 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
Re: [PATCH] regulator: twl4030 VAUX3 supports 3.0V
On Thu, 2009-03-26 at 16:21 +0200, Adrian Hunter wrote: From 51f946af56a5de9c25b2eb6e6a33660283f84195 Mon Sep 17 00:00:00 2001 From: Adrian Hunter adrian.hun...@nokia.com Date: Fri, 6 Mar 2009 14:51:30 +0200 Subject: [PATCH] regulator: twl4030 VAUX3 supports 3.0V TWL4030 and TWL5030 support 3.0V on VAUX3. Signed-off-by: Adrian Hunter adrian.hun...@nokia.com --- drivers/regulator/twl4030-regulator.c |5 - 1 files changed, 4 insertions(+), 1 deletions(-) Applied. Thanks Liam -- 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
Re: [patch] twl4030-regulator: expose VPLL2
On Mon, 2009-03-16 at 15:51 +, Mark Brown wrote: On Fri, Mar 13, 2009 at 05:54:54PM -0700, David Brownell wrote: From: David Brownell dbrown...@users.sourceforge.net Add VPLL2 to the set of twl4030-family regulators exposed for use by various drivers. It's commonly used to power the digital video outputs (e.g. LCD or DVI displays) on OMAP3 systems. Signed-off-by: David Brownell dbrown...@users.sourceforge.net Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com Samuel, I've applied this to the regulator tree as the part that touches mfd is relatively minor and twl4030 specific (doesn't touch core). Thanks Liam -- 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
Re: [PATCH] regulator: twl4030 VAUX3 supports 3.0V
On Tue, 2009-03-17 at 09:36 +0200, Adrian Hunter wrote: Liam Girdwood wrote: On Fri, 2009-03-06 at 14:48 -0800, David Brownell wrote: On Friday 06 March 2009, Mark Brown wrote: Would it make sense to make this platform data so that if a given board requires running the chip like this it can be enabled for those boards but it's not something people might turn on because it seems useful? Let's hear if it's actually needed, first. :) I coded those tables so that it would be easy to kick in the support for out-of-spec operation if it's really needed. But so far we don't know that it's needed, and I'd rather it not be too easy to run like that. I've now reverted this patch. TI say we can use VAUX3 at 3V and expect no problems: http://community.ti.com/forums/p/3777/14574.aspx So how do we do it? I'd prefer seeing the reply from Ghandar to David's last question before accepting this patch again. It's still not 100% clear from TI, things seem a little bit muddled as to whether 3V will be guaranteed to work on *all* shipped devices. Thanks Liam -- 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
Re: [patch 2.6.29-rc7 regulator-next] regulator: refcount fixes
On Wed, 2009-03-11 at 16:43 -0800, David Brownell wrote: From: David Brownell dbrown...@users.sourceforge.net Fix some refcounting issues in the regulator framework, supporting regulator_disable() for regulators that were enabled at boot time via machine constraints: - Update those regulators' usecounts after enabling, so they can cleanly be disabled at that level. - Remove the problematic per-consumer usecount, so there's only one level of enable/disable. Buggy consumers could notice different bug symptoms. The main example would be refcounting bugs; also, any (out-of-tree) users of the experimental regulator_set_optimum_mode() stuff which don't call it when they're done using a regulator. This is a net minor codeshrink. Signed-off-by: David Brownell dbrown...@users.sourceforge.net --- Applied. Thanks Liam -- 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
Re: [patch 2.6.29-rc7-omap] twl4030-regulator: list more VAUX4 voltages
On Tue, 2009-03-10 at 11:51 -0800, David Brownell wrote: From: David Brownell dbrown...@users.sourceforge.net The VAUX4 voltage table scrolls onto a second page in many versions of the TWL4030 family manuals. This doesn't mean we should ignore those values! Some boards use the (fully supported) 2.8V setting. Signed-off-by: David Brownell dbrown...@users.sourceforge.net --- Applied to regulator-next. Thanks Liam -- 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
Re: [patch 2.6.29-rc6+misc] MMC: regulator utilities
On Wed, 2009-03-11 at 03:30 -0800, David Brownell wrote: On Monday 09 March 2009, Liam Girdwood wrote: From: David Brownell dbrown...@users.sourceforge.net Glue between MMC and regulator stacks ... verified with some OMAP3 boards using adjustable and configured-as-fixed regulators on several MMC controllers. ... Acked-by: Pierre Ossman drz...@drzeus.cx Applied. ... actually you applied an old version, not the one that was verified, with mmc_regulator_set_ocr() fixes and with Pierre's ACK. The comment is in your GIT tree is wrong, for starters... Please use this one instead. I've removed the old patch now and applied the correct one. In the future could you start a new thread or change the thread subject a little (i.e. patch V2) when a patch changes during discussion. This should avoid similar confusion in the future. Thanks Liam -- 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
Re: [PATCH] regulator: twl4030 VAUX3 supports 3.0V
On Fri, 2009-03-06 at 14:48 -0800, David Brownell wrote: On Friday 06 March 2009, Mark Brown wrote: Would it make sense to make this platform data so that if a given board requires running the chip like this it can be enabled for those boards but it's not something people might turn on because it seems useful? Let's hear if it's actually needed, first. :) I coded those tables so that it would be easy to kick in the support for out-of-spec operation if it's really needed. But so far we don't know that it's needed, and I'd rather it not be too easy to run like that. I've now reverted this patch. Liam -- 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
Re: [patch 2.6.29-rc6+misc] MMC: regulator utilities
On Sun, 2009-03-08 at 22:49 +0100, Pierre Ossman wrote: On Sun, 8 Mar 2009 12:34:25 -0800 David Brownell davi...@pacbell.net wrote: On Sunday 08 March 2009, Pierre Ossman wrote: Looks good. Now what should I do with it? Merge it in the next window good enough? Well, after testing the previously-untested call ... here's another update. Since these depend on new calls in the regulator framework, it can't merge until after they merge (in the next window). Least hassle for you would be if this merges through the regulator framework (with your ack), I suspect. - Dave CUT HERE From: David Brownell dbrown...@users.sourceforge.net Glue between MMC and regulator stacks ... verified with some OMAP3 boards using adjustable and configured-as-fixed regulators on several MMC controllers. These calls are intended to be used by MMC host adapters using at least one regulator per host. Examples include slots with regulators supporting multiple voltages and ones using multiple voltage rails (e.g. DAT4..DAT7 using a separate supply, or a split rail chip like certain SDIO WLAN or eMMC solutions). Signed-off-by: David Brownell dbrown...@users.sourceforge.net --- Acked-by: Pierre Ossman drz...@drzeus.cx Applied. Thanks Liam -- 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
Re: [PATCH] regulator: twl4030 VAUX3 supports 3.0V
On Fri, 2009-03-06 at 15:01 +0200, Adrian Hunter wrote: TWL4030 and TWL5030 support 3.0V on VAUX3. Signed-off-by: Adrian Hunter adrian.hun...@nokia.com Applied. Thanks Liam -- 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
Re: [patch/rfc 2.6.29-rc6 2/2] regulator: twl4030 voltage enumeration (v2)
On Tue, 2009-03-03 at 14:59 -0800, David Brownell wrote: On Friday 27 February 2009, Liam Girdwood wrote: Sorry, this didn't apply. It looks like I'm missing an earlier patch(s) here. Could you regenerate this and your core patch against latest for-next. Here you go. - Dave == CUT HERE From: David Brownell dbrown...@users.sourceforge.net Minor cleanups to the twl403 regulator driver, mostly enabled by other recent changes: comments, shrink memory usage, add definition for one bit. Signed-off-by: David Brownell dbrown...@users.sourceforge.net --- drivers/regulator/twl4030-regulator.c | 16 +--- 1 file changed, 9 insertions(+), 7 deletions(-) Applied. Thanks Liam -- 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
Re: [patch/rfc 2.6.29-rc6 2/2] regulator: twl4030 voltage enumeration (v2)
On Thu, 2009-02-26 at 16:02 -0800, David Brownell wrote: On Thursday 26 February 2009, Liam Girdwood wrote: Note that the twl4030 regulator patch referred to will need a minor patch to work with the -next tree, because of interface change in the regulator framework. drivers/regulator/twl4030-regulator.c | 62 +++- 1 file changed, 23 insertions(+), 39 deletions(-) Applied. and here's that minor patch. == CUT HERE From: David Brownell dbrown...@users.sourceforge.net Catch up the twl4030 regulator driver to the regulator interface change adding another parameter. Also, fix some comments, and take this opportunity to shrink the associated per-regulator memory usage by a word. Signed-off-by: David Brownell dbrown...@users.sourceforge.net --- drivers/regulator/twl4030-regulator.c | 17 + 1 file changed, 9 insertions(+), 8 deletions(-) Sorry, this didn't apply. It looks like I'm missing an earlier patch(s) here. Could you regenerate this and your core patch against latest for-next. Thanks Liam -- 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
