uninstall
-- 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
uninstall
-- 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: Exporting functions doing common register access
In the interim, I would suggest that you remove the the clock source
and
receiver source change functions from omap-mcbsp.c, split them into
OMAP1
and OMAP2/3 variants, and place them into arch/arm/mach-omap*/mcbsp.c.
Expand struct omap_mcbsp_ops to add function pointers to those
functions.
Call those from soc/omap-mcbsp.c via mcbsp-pdata-ops. That way you
won't
need those exports.
Paul: What's your opinnion, would it be possible or would it be wise to
handle these McBSP clock route setups with the clock framework instead?
Functions omap_mcbsp_dai_set_clks_src and omap_mcbsp_dai_set_rcvr_src
are basically just setting up the input clock for McBSP SRG or McBSP1
receiver.
Sure. There already should be some support for it in clock34xx.h, but I
doubt anyone's tested it:
static struct clk mcbsp1_fck = {
.name = mcbsp_fck,
.ops= clkops_omap2_dflt_wait,
.id = 1,
.init = omap2_init_clksel_parent,
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_FCLKEN1),
.enable_bit = OMAP3430_EN_MCBSP1_SHIFT,
.clksel_reg = OMAP343X_CTRL_REGADDR(OMAP2_CONTROL_DEVCONF0),
.clksel_mask= OMAP2_MCBSP1_CLKS_MASK,
.clksel = mcbsp_15_clksel,
.clkdm_name = core_l4_clkdm,
.recalc = omap2_clksel_recalc,
};
etc. Some similar entries would need to be added to the clock24xx.h file.
[Aggarwal, Anuj] One problem which I found in trying the above discussed
approach is that I am not able to get mcbsp clock handles in omap-mcbsp.c
file. To call clk_set_parent() with the new parent clock as mcbsp_clks
(in case of an external clock), I need the mcbsp_fck clock handle. But this
handle is not shared with the omap_mcbsp_dai[].
What should be the right method of getting this handle in
omap_mcbsp_dai_set_dai_sysclk(), in case I understood the concept properly.
Basically, we want to get rid of the low level stuff in this function
and instead use standard clock framework APIs?
--
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: Exporting functions doing common register access
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Aggarwal, Anuj
Sent: Thursday, January 07, 2010 7:40 PM
To: Paul Walmsley; Jarkko Nikula
Cc: linux-omap@vger.kernel.org; alsa-de...@alsa-project.org; Lohithakshan,
Ranjith
Subject: RE: [PATCH] OMAP: Exporting functions doing common register
access
In the interim, I would suggest that you remove the the clock source
and
receiver source change functions from omap-mcbsp.c, split them into
OMAP1
and OMAP2/3 variants, and place them into arch/arm/mach-
omap*/mcbsp.c.
Expand struct omap_mcbsp_ops to add function pointers to those
functions.
Call those from soc/omap-mcbsp.c via mcbsp-pdata-ops. That way you
won't
need those exports.
Paul: What's your opinnion, would it be possible or would it be wise
to
handle these McBSP clock route setups with the clock framework
instead?
Functions omap_mcbsp_dai_set_clks_src and omap_mcbsp_dai_set_rcvr_src
are basically just setting up the input clock for McBSP SRG or McBSP1
receiver.
Sure. There already should be some support for it in clock34xx.h, but I
doubt anyone's tested it:
static struct clk mcbsp1_fck = {
.name = mcbsp_fck,
.ops= clkops_omap2_dflt_wait,
.id = 1,
.init = omap2_init_clksel_parent,
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_FCLKEN1),
.enable_bit = OMAP3430_EN_MCBSP1_SHIFT,
.clksel_reg = OMAP343X_CTRL_REGADDR(OMAP2_CONTROL_DEVCONF0),
.clksel_mask= OMAP2_MCBSP1_CLKS_MASK,
.clksel = mcbsp_15_clksel,
.clkdm_name = core_l4_clkdm,
.recalc = omap2_clksel_recalc,
};
etc. Some similar entries would need to be added to the clock24xx.h
file.
[Aggarwal, Anuj] One problem which I found in trying the above discussed
approach is that I am not able to get mcbsp clock handles in omap-mcbsp.c
file. To call clk_set_parent() with the new parent clock as mcbsp_clks
(in case of an external clock), I need the mcbsp_fck clock handle. But
this
handle is not shared with the omap_mcbsp_dai[].
What should be the right method of getting this handle in
omap_mcbsp_dai_set_dai_sysclk(), in case I understood the concept
properly.
Basically, we want to get rid of the low level stuff in this function
and instead use standard clock framework APIs?
Paul / Jarkko,
Any comments/pointers please?
--
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
--
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/6] Regulator: Removing common code for TWL4030 PMIC from various OMAP3 board-evms
-Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Saturday, January 09, 2010 3:57 AM To: Aggarwal, Anuj Cc: linux-omap@vger.kernel.org; broo...@opensource.wolfsonmicro.com; l...@slimlogic.co.uk Subject: Re: [PATCH 0/6] Regulator: Removing common code for TWL4030 PMIC from various OMAP3 board-evms Anuj Aggarwal anuj.aggar...@ti.com writes: Based on the discussions and feedback received, this patch set is created which cleans up various OMAP3-board-evm files and removes common TWL4030 specific regulator suuplies and init data structs. These structures are instead placed in a new file - board-omap35x-twl4030-pmic.c and are referenced from the board-evm Why is this omap35x? You seem to be using this from omap34xx board files as well. I don't think you need the board-omap* prefix at all. Why not just call it twl4030-pmic.c. [Aggarwal, Anuj] That's fine with me. I will wait for some more comments to pour in today and will re-send the patch with this modification. There has been some proposals to unify the twl4030 scripts as well by Lesley, and this new file would be a logical place for those as well. Kevin files depending on the platform requirements. Regulator having specific supplies or init data structs are not changed in their respective board-evms. The main advantages of having one common file for these structures are redundant code removal, easy maintainability and single copy of common structure(s) in case uImage for multiple platforms is built. Please see the following links for previous discussions: http://marc.info/?l=linux-omapm=12579548775w=2 http://marc.info/?l=linux-omapm=125795068502904w=2 I have tested these patches on OMAP3EVM and the image boots fine. I have compile-tested them for SDP3430 and all OMAP platforms (using omap3_defconfig) and the build went fine. If someone can test them on their hardware, that would be great !!! Anuj Aggarwal (6): Regulator: Creating TWL4030 specific file having supplies init data Regulator: Removing the common supplies and regulator init data structs Regulator: Use common regulator supplies and init data structs Regulator: Modifying Kconfig to choose from the available PMICs Regulator: Kconfig modified to select TWL4030 for OMAP3 based platforms Regulator: Makefile modified to include TWL4030-PMIC specific file arch/arm/mach-omap2/Kconfig | 20 +++ arch/arm/mach-omap2/Makefile |1 + arch/arm/mach-omap2/board-3430sdp.c | 146 +++ --- arch/arm/mach-omap2/board-cm-t35.c | 52 ++- arch/arm/mach-omap2/board-igep0020.c | 26 +--- arch/arm/mach-omap2/board-ldp.c | 26 +--- arch/arm/mach-omap2/board-omap35x-twl4030-pmic.c | 175 ++ arch/arm/mach-omap2/board-omap3beagle.c | 52 ++- arch/arm/mach-omap2/board-omap3evm.c | 63 ++-- arch/arm/mach-omap2/board-omap3pandora.c | 52 ++- arch/arm/mach-omap2/board-omap3touchbook.c | 52 ++- arch/arm/mach-omap2/board-overo.c| 26 +--- arch/arm/mach-omap2/board-zoom-peripherals.c | 78 ++ 13 files changed, 304 insertions(+), 465 deletions(-) create mode 100644 arch/arm/mach-omap2/board-omap35x-twl4030-pmic.c -- 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 -- 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 3/6] Regulator: Use common regulator supplies and init data structs
Your common supply file has VMMC2 supply configured for 1.8V which is wrong for pandora (it uses 3.1V because it has a transceiver attached to MMC2 that handles level shifting transparently). I think you should leave pandora board file alone, because it uses many supplies differently than your common file configures them (VAUX1-VAUX4, VSIM differ, only VMMC1, VDAC and VPLL2 match, which is not that much duplication). [Aggarwal, Anuj] My mistake :( Although I have marked it as RED in my notes, I still modified it. I will leave VMMC2 in this file only. But I am not able to find so many regulators as you mentioned above in this file. I can only see VMMC1 and VMMC2, out of which VMMC2 is different from the common configuration. Where is the gap? -- 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
Audio suspend/resume status on OMAP3 based platforms
Hi, I want to check the status of suspend/resume functionality when audio subsystem is being used. Specifically, has some one tried the following tests on their omap3 based platforms: a) echo mem /sys/power/state, when audio playback is running in background b) same command, when audio capture is running in background b) same command, when audio loopback is running in background I am facing some issues with (b) (c) so wanted to confirm whether someone else has faced similar problem or not. Regards, Anuj Aggarwal -- 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] Audio suspend/resume status on OMAP3 based platforms
-Original Message- From: Peter Ujfalusi [mailto:peter.ujfal...@nokia.com] Sent: Wednesday, January 13, 2010 12:40 PM To: alsa-de...@alsa-project.org Cc: Aggarwal, Anuj; linux-omap@vger.kernel.org Subject: Re: [alsa-devel] Audio suspend/resume status on OMAP3 based platforms On Tuesday 12 January 2010 18:05:15 ext Aggarwal, Anuj wrote: Hi, I want to check the status of suspend/resume functionality when audio subsystem is being used. Specifically, has some one tried the following tests on their omap3 based platforms: a) echo mem /sys/power/state, when audio playback is running in background b) same command, when audio capture is running in background b) same command, when audio loopback is running in background I am facing some issues with (b) (c) so wanted to confirm whether someone else has faced similar problem or not. As Jarkko pointed out in a separate mail, we should not expect the suspend/resume to be working correctly until the context save/restore, and the clock management is sorted out. On the other hand it seams that the problem is in the capture path (b and c having issues). How is the McBSP configured in your setup (master or slave)? [Aggarwal, Anuj] TWL4030 is master and McBSP is slave. I think we might have different issues with suspend/resume when OMAP McBSP is slave or if it is master. -- 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] Audio suspend/resume status on OMAP3 based platforms
I want to check the status of suspend/resume functionality when audio subsystem is being used. Specifically, has some one tried the following tests on their omap3 based platforms: a) echo mem /sys/power/state, when audio playback is running in background b) same command, when audio capture is running in background b) same command, when audio loopback is running in background I am facing some issues with (b) (c) so wanted to confirm whether someone else has faced similar problem or not. As Jarkko pointed out in a separate mail, we should not expect the suspend/resume to be working correctly until the context save/restore, and the clock management is sorted out. On the other hand it seams that the problem is in the capture path (b and c having issues). How is the McBSP configured in your setup (master or slave)? [Aggarwal, Anuj] TWL4030 is master and McBSP is slave. I think we might have different issues with suspend/resume when OMAP McBSP is slave or if it is master. Few (+)updates from my side: a) Capture not working after suspend/resume: After taking a dump of mcbsp, DMA and codec registers and comparing them, I found out that DMA.CCR[Enable] and DMA.CSR[Sync] bits were set when system was coming out of suspend. I don't understand why these two bits are not set in case of playback running in backgnd but when I forcefully clear them in omap_pcm_trigger() fn under SNDRV_PCM_TRIGGER_RESUME, my problem goes away. Now I am able to do suspend/resume successfully while capture is running in bg without getting the Input/output error. b) McBSP registers being accessed from omap_pcm_trigger(): When audio playback is running in background and I try suspend, I saw mcbsp registers getting read/written by omap_pcm_trigger() through dma_data-set_threshold(). This happens when soc_pcm_trigger() calls platform-pcm_ops-trigger before cpu_dai-ops-trigger and the clocks are getting enabled only in cpu_dai-trigger. Because of this, I found one warning coming through but this needs a fix. c) System hangs when audio loopback is going on in background: Finally, I was able to narrow down the problem. After the mcbsp clocks are cut for playback stream, when suspend gets called for capture, mcbsp is stopped inside omap_mcbsp_dai_trigger-SNDRV_PCM_TRIGGER_PAUSE_PUSH, before disabling the clocks. This resulted in hang and the system doesn't come out of snd_pcm_suspend_all() which I reported in my previous email. I modified the clock disabling routine and averted the hang. Now the problem is with the mcbsp/DMA configuration as I am not able to resume the loopback fully (1 in 5 times only it works) and receive this error: ALSA sound/core/pcm_lib.c:1708: playback write error (DMA or IRQ trouble?) After this, the application exits gracefully. On further debugging, I realized that mcbsp is not getting configured properly on either the playback or capture stream, while resuming. Hence the error. I think this problem can go if I apply the mcbsp-register-cache patches but I have to try that before I can come to a conclusion. I have (dirty) fixes for (a) and (b) which, on cleaning, I would be sending for reviews. Thanks for the suggestions/pointers. -- 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: Add AM3517 EVM support in ASOC
-Original Message- From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com] Sent: Friday, October 30, 2009 4:00 AM To: Aggarwal, Anuj Cc: alsa-de...@alsa-project.org; linux-omap@vger.kernel.org; t...@atomide.com Subject: Re: [alsa-devel] [PATCH 0/4] ASOC: Add AM3517 EVM support in ASOC On Fri, Oct 30, 2009 at 12:22:17AM +0530, Anuj Aggarwal wrote: This patch series add support for OMAP3517 / AM3517 EVM in ASOC. It also enables the required drivers - I2C and McBSP, along with Alsa SoC subsystem, in the default configuration for the EVM. Anuj Aggarwal (4): Audio: Adding OMAP3517 / AM3517 EVM support in ASOC Audio: Modifying Kconfig/Makefile for AM3517 EVM Audio: Modifying board-evm file for audio codec Audio: Modifying the defconfig for OMAP3517 / AM3517 EVM These all look good - I've applied patches 1 and 2 to ASoC, patches 3 and 4 should go via OMAP and are Tony, I could not find patches 3 4 on l-o master. Am I looking at the right branch? Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com if it helps (or even if it doesn't!). Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHv2 0/4] Regulator: OMAP: Removing common code for TWL4030 from OMAP3- board-evms
-Original Message- From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com] Sent: Friday, January 15, 2010 4:43 PM To: Aggarwal, Anuj Cc: linux-omap@vger.kernel.org; l...@slimlogic.co.uk Subject: Re: [PATCHv2 0/4] Regulator: OMAP: Removing common code for TWL4030 from OMAP3- board-evms On Tue, Jan 12, 2010 at 02:43:45PM +0530, Anuj Aggarwal wrote: Anuj Aggarwal (4): Regulator: OMAP: Creating TWL4030 file having supplies init data I'd expect to see the header file here have ifdef guards and also include the headers it depends on (linux/regulator/machine.h at least) but both of those could be fixed up later. Otherwise it all looks OK from a regulator point of view Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com Tony, Have you pulled these patches? I need to send another patch set for other PMICs which would be based on the first set. Are you expecting some change in the original set? Please let me know if that is the case. -- 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: Add AM3517 EVM support in ASOC
Hmm, well I still have about 70 patches pending and have not yet gotten into looking at the board-*.c files that much.. But looks like I had marked these as awaiting upstream. I've marked them new again and will queue into omap for-next when I get to dealing with the board-*.c files. BTW, I assume these two patches are the missing ones: http://patchwork.kernel.org/patch/56501/ http://patchwork.kernel.org/patch/56502/ [Aggarwal, Anuj] Yes, you are right Tony. -- 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/1] Regulator: Registering USB internal LDOs for TWL4030
-Original Message- From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com] Sent: Monday, January 11, 2010 4:26 PM To: Aggarwal, Anuj Cc: linux-omap@vger.kernel.org; l...@slimlogic.co.uk Subject: Re: [PATCH 1/1] Regulator: Registering USB internal LDOs for TWL4030 On Mon, Jan 11, 2010 at 02:55:18PM +0530, Anuj Aggarwal wrote: Adding member variables for USB internal LDOs in twl4030_platform_data and registering them in twl-core.c if the variables are populated from board-evm file. Signed-off-by: Anuj Aggarwal anuj.aggar...@ti.com Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com Tony, Can you pull this patch? I have tried it on for-next tip, it applies cleanly. -- 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
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Friday, February 05, 2010 7:10 AM To: Aggarwal, Anuj Cc: linux-omap@vger.kernel.org; broo...@opensource.wolfsonmicro.com; l...@slimlogic.co.uk Subject: Re: [PATCHv2 1/4] Regulator: OMAP: Creating TWL4030 file having supplies init data Hi, * Anuj Aggarwal anuj.aggar...@ti.com [100112 01:12]: 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. Looks like this series needs to be rebased on omap-for-linus branch in the linux-omap tree. Please also check that the patches apply against the current for-next branch in the linux-omap tree. Also, please check that each patch in the series builds (and boots) with arch/arm/config/omap3_defconfig. Tony, I have rebased the patch set (version 3) against for-next tip. I have also checked that each patch builds (and boots) with omap3_defconfig individually. Please pull. -- 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 2/4] Regulator: OMAP: Modifying Kconfig/Makefile to choose from available PMICs
-Original Message- From: Grazvydas Ignotas [mailto:nota...@gmail.com] Sent: Tuesday, March 02, 2010 10:54 PM To: Aggarwal, Anuj Cc: t...@atomide.com; linux-omap@vger.kernel.org; broo...@opensource.wolfsonmicro.com; l...@slimlogic.co.uk Subject: Re: [PATCHv3 2/4] Regulator: OMAP: Modifying Kconfig/Makefile to choose from available PMICs On Tue, Mar 2, 2010 at 12:29 PM, Anuj Aggarwal anuj.aggar...@ti.com wrote: Kconfig is modified for OMAP3 EVM so that user can choose the appropriate PMIC (currently only TWL4030). Config options for other PMICs will be added later on. Makefile is modified so that twl4030-pmic.c gets compiled for the platforms having TWL4030 as the PMIC. Signed-off-by: Anuj Aggarwal anuj.aggar...@ti.com --- arch/arm/mach-omap2/Kconfig | 9 + arch/arm/mach-omap2/Makefile | 1 + 2 files changed, 10 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index a8a3d1e..1974dda 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -77,6 +77,15 @@ config MACH_OMAP3EVM depends on ARCH_OMAP3 select OMAP_PACKAGE_CBB +config PMIC_TWL4030 + bool TWL4030/TPS65950 Power Module + default y + select TWL4030_CORE + select REGULATOR_TWL4030 if REGULATOR + help + Say yes here if you are using the TWL4030/TPS65950 based power module + for the EVM boards. + Any reason to have this user configurable? The boards that depend on it will always need it to be enabled to compile, and the ones that don't always want it disabled. [Aggarwal, Anuj] OMAP3 EVM can have different PMICs like TWL4030, TPS65023, TPS6507x etc; user can configure the kernel accordingly. -- 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 5/5] Regulator: Renaming the supplies used in MMC driver
-Original Message-
From: Mike Rapoport [mailto:mike.rapop...@gmail.com]
Sent: Friday, November 06, 2009 2:47 AM
To: Aggarwal, Anuj
Cc: linux-omap@vger.kernel.org; broo...@opensource.wolfsonmicro.com;
l...@slimlogic.co.uk
Subject: Re: [PATCH 5/5] Regulator: Renaming the supplies used in MMC
driver
On Thu, Nov 5, 2009 at 6:39 PM, Anuj Aggarwal anuj.aggar...@ti.com
wrote:
Supply names are renamed from vmmc - mmc and vmmc_aux - mmc_aux.
This is done to have simple supply names both in the driver
and in the board-evm file.
Signed-off-by: Anuj Aggarwal anuj.aggar...@ti.com
---
arch/arm/mach-omap2/mmc-twl4030.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/mmc-twl4030.c b/arch/arm/mach-
omap2/mmc-twl4030.c
index 3403914..af3b1be 100644
--- a/arch/arm/mach-omap2/mmc-twl4030.c
+++ b/arch/arm/mach-omap2/mmc-twl4030.c
@@ -109,9 +109,9 @@ static int twl_mmc_late_init(struct device *dev)
hsmmc[i].mmc = mmc;
- reg = regulator_get(dev, vmmc);
+ reg = regulator_get(dev, mmc);
It will break all existing OMAP3 boards.
[Aggarwal, Anuj] This was done to have the same naming conventions across
the board. I could not find an extra v in supply names except MMC.
Hence modified this. Regulator supply names should be simple and easy to
understand.
I can revert this change or change the dependent board files for SDP/LDP
etc. What do you suggest?
if (IS_ERR(reg)) {
- dev_dbg(dev, vmmc regulator
missing\n);
+ dev_dbg(dev, mmc regulator missing\n);
/* HACK: until fixed.c regulator is
usable,
* we don't require a main regulator
* for MMC2 or MMC3
@@ -126,7 +126,7 @@ static int twl_mmc_late_init(struct device *dev)
mmc-slots[0].ocr_mask =
mmc_regulator_get_ocrmask(reg);
/* allow an aux regulator */
- reg = regulator_get(dev, vmmc_aux);
+ reg = regulator_get(dev, mmc_aux);
ditto.
hsmmc[i].vcc_aux = IS_ERR(reg) ? NULL : reg;
/* UGLY HACK: workaround regulator framework
bugs.
--
1.6.2.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
--
Sincerely Yours,
Mike.
--
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/5] Regulator: Adding OMAP3EVM/TWL4030 specific code in board-omap35x-pmic.c
-Original Message-
From: Mike Rapoport [mailto:mike.rapop...@gmail.com]
Sent: Friday, November 06, 2009 2:46 AM
To: Aggarwal, Anuj
Cc: linux-omap@vger.kernel.org; broo...@opensource.wolfsonmicro.com;
l...@slimlogic.co.uk
Subject: Re: [PATCH 4/5] Regulator: Adding OMAP3EVM/TWL4030 specific code
in board-omap35x-pmic.c
On Thu, Nov 5, 2009 at 6:39 PM, Anuj Aggarwal anuj.aggar...@ti.com
wrote:
Adding various regulator-consumers for OMAP3EVM-TWL4030 combination
in board-omap35x-pmic.c. Also, populating the respective fields
for omap3evm_twldata structure.
Signed-off-by: Anuj Aggarwal anuj.aggar...@ti.com
---
arch/arm/mach-omap2/board-omap35x-pmic.c | 81
+-
arch/arm/mach-omap2/board-omap3evm.c | 2 +-
2 files changed, 80 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap35x-pmic.c b/arch/arm/mach-
omap2/board-omap35x-pmic.c
index aae07ab..2ef4932 100644
--- a/arch/arm/mach-omap2/board-omap35x-pmic.c
+++ b/arch/arm/mach-omap2/board-omap35x-pmic.c
@@ -24,10 +24,87 @@
* Definitions specific to TWL4030/TPS65950
*/
#if defined(CONFIG_PMIC_TWL4030)
-static inline void pmic_twl4030_init(void)
+#if defined(CONFIG_MACH_OMAP3EVM)
What about beagle, overo and others that use the same regulator for
the same purposes?
[Aggarwal, Anuj] This file can be used to accommodate all the common
Regulator f/w related code for OMAP3 based platforms. Depending upon
the regulators' usage across EVMs, the code can be split in generic and
platform specific code.
+#include linux/i2c/twl4030.h
+
+extern struct twl4030_platform_data omap3evm_twldata;
The *twldata does not have to be global, it can be passed to pmic_init
as a parameter.
+/* VDAC */
+static struct regulator_consumer_supply vdac_consumers[] = {
+ {
+ .supply = dac,
+ },
+};
+
+static struct regulator_init_data vdac_data = {
+ .constraints = {
+ .name = VDAC,
+ .min_uV = 180,
+ .max_uV = 180,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(vdac_consumers),
+ .consumer_supplies = vdac_consumers,
+};
+
+/* VPLL2 */
+static struct regulator_consumer_supply vpll2_consumers[] = {
+ {
+ .supply = lcd,
+ },
+ {
+ .supply = sdi,
+ },
+};
+
+static struct regulator_init_data vpll2_data = {
+ .constraints = {
+ .name = VPLL2,
+ .min_uV = 180,
+ .max_uV = 180,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(vpll2_consumers),
+ .consumer_supplies = vpll2_consumers,
+};
+
+/* VMMC1 */
+struct regulator_consumer_supply vmmc1_consumers[] = {
+ {
+ .supply = mmc,
+ },
+};
+
+static struct regulator_init_data vmmc1_data = {
+ .constraints = {
+ .name = VMMC1,
+ .min_uV = 185,
+ .max_uV = 315,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
+ | REGULATOR_CHANGE_MODE |
REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(vmmc1_consumers),
+ .consumer_supplies = vmmc1_consumers,
+};
+
+static void __init pmic_twl4030_init(void)
{
- /* TWL4030 specific init code */
+ /* Initialize the regulator specific fields here */
+ omap3evm_twldata.vdac = vdac_data;
+ omap3evm_twldata.vpll2 = vpll2_data;
+ omap3evm_twldata.vmmc1 = vmmc1_data;
}
+#endif /* CONFIG_MACH_OMAP3EVM */
I don't see why would you move board specific code from board specific
file to some generic file and add #ifdefs to enable this code only
for that board. Indeed, many OMAP3 boards use TWL/TPS in very similar
way and it does make sence to factor the common code out. But with
your approach each board will have to add its own #ifdef with almost
identical code inside it.
[Aggarwal, Anuj] As explained above, same code can be used for OMAP3 based
platforms having the same regulator requirements.
#else
static inline void pmic_twl4030_init(void)
{
diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-
omap2/board-omap3evm.c
index
RE: [PATCH 4/5] Regulator: Adding OMAP3EVM/TWL4030 specific code in board-omap35x-pmic.c
-Original Message-
From: Mike Rapoport [mailto:mike.rapop...@gmail.com]
Sent: Friday, November 06, 2009 8:06 PM
To: Aggarwal, Anuj
Cc: linux-omap@vger.kernel.org; broo...@opensource.wolfsonmicro.com;
l...@slimlogic.co.uk
Subject: Re: [PATCH 4/5] Regulator: Adding OMAP3EVM/TWL4030 specific code
in board-omap35x-pmic.c
On Fri, Nov 6, 2009 at 8:47 AM, Aggarwal, Anuj anuj.aggar...@ti.com
wrote:
-Original Message-
From: Mike Rapoport [mailto:mike.rapop...@gmail.com]
Sent: Friday, November 06, 2009 2:46 AM
To: Aggarwal, Anuj
Cc: linux-omap@vger.kernel.org; broo...@opensource.wolfsonmicro.com;
l...@slimlogic.co.uk
Subject: Re: [PATCH 4/5] Regulator: Adding OMAP3EVM/TWL4030 specific
code
in board-omap35x-pmic.c
On Thu, Nov 5, 2009 at 6:39 PM, Anuj Aggarwal anuj.aggar...@ti.com
wrote:
Adding various regulator-consumers for OMAP3EVM-TWL4030 combination
in board-omap35x-pmic.c. Also, populating the respective fields
for omap3evm_twldata structure.
Signed-off-by: Anuj Aggarwal anuj.aggar...@ti.com
---
arch/arm/mach-omap2/board-omap35x-pmic.c | 81
+-
arch/arm/mach-omap2/board-omap3evm.c | 2 +-
2 files changed, 80 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap35x-pmic.c
b/arch/arm/mach-
omap2/board-omap35x-pmic.c
index aae07ab..2ef4932 100644
--- a/arch/arm/mach-omap2/board-omap35x-pmic.c
+++ b/arch/arm/mach-omap2/board-omap35x-pmic.c
@@ -24,10 +24,87 @@
* Definitions specific to TWL4030/TPS65950
*/
#if defined(CONFIG_PMIC_TWL4030)
-static inline void pmic_twl4030_init(void)
+#if defined(CONFIG_MACH_OMAP3EVM)
What about beagle, overo and others that use the same regulator for
the same purposes?
[Aggarwal, Anuj] This file can be used to accommodate all the common
Regulator f/w related code for OMAP3 based platforms. Depending upon
the regulators' usage across EVMs, the code can be split in generic and
platform specific code.
I agree that common regulator functionality should reside in one place
rather than be copy-pasted between board files. But adding file with
#defined(CONFIG_MACH_OMAP3EVM) and #defined(CONFIG_MACH_OMAP3BEAGLE)
does not make it generic. Every single line of code that is inside
such #ifdef can be perfectly well placed in the appropriate board-X.c
As far as I can tell, all platforms use the very same definitions of
regulator and regulator supplies both for MMC and VDVI and VENC. So,
why not just create some macros wrapping these definitions and use
them every time 'struct regulator_consumer_supply' and 'struct
regulator_init_data' need to be instantiated?
Based on your suggestions, I tried creating macros specific to TWL
regulators in a common header file. This file then can be included by
the different board files and the structures can then be appropriately
created.
Here is the sample of what could be done on these lines:
#define TWL_VDAC_SUPPLY(device) { \
static struct regulator_consumer_supply vdac_supply[] = { \
{ \
.supply = vdac, \
.dev = device, \
}, \
}; \
}
#define TWL_VPLL2_SUPPLY(device){ \
static struct regulator_consumer_supply vpll2_supply[] = { \
{ \
.supply = vpll2, \
.dev = device, \
}, \
}; \
}
And similarly:
#define TWL_VAUX1_VDAC_DATA() { \
static struct regulator_init_data vdac_data = { \
.constraints = { \
.min_uV = 180, \
.max_uV = 180, \
.apply_uV = true, \
.valid_modes_mask = REGULATOR_MODE_NORMAL \
| REGULATOR_MODE_STANDBY, \
.valid_ops_mask = REGULATOR_CHANGE_MODE \
| REGULATOR_CHANGE_STATUS, \
}, \
.num_consumer_supplies = ARRAY_SIZE(vdac_supply), \
.consumer_supplies = vdac_supply, \
}; \
}
This way, user can define his board-specific regulators in the board-*
file.
Only problem I can forsee in this approach is how to create regulators
supplying multiple devices? VLPP2 might be supplying 2-3 devices in the
system which the above #define doesn't take care. How that can be
solved?
+#include linux/i2c/twl4030.h
+
+extern struct twl4030_platform_data omap3evm_twldata;
The *twldata does not have to be global, it can be passed to pmic_init
as a parameter.
+/* VDAC */
+static struct regulator_consumer_supply vdac_consumers[] = {
+ {
+ .supply = dac,
+ },
+};
+
+static struct regulator_init_data vdac_data = {
+ .constraints
FW: [PATCH] omap3evm: Migrate to smsc911x ethernet driver.
Pushed this patch to psp-group:build7 ...
Regards,
Anuj Aggarwal
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Govindarajan,
Sriramakrishnan
Sent: Wednesday, November 11, 2009 1:43 PM
To: linux-omap@vger.kernel.org
Subject: RE: [PATCH] omap3evm: Migrate to smsc911x ethernet driver.
Tony,
Are there comments with respect to this patch. Will this be merged in the next
window?
Regards
Sriram
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Govindarajan, Sriramakrishnan
Sent: Wednesday, October 28, 2009 7:19 PM
To: linux-omap@vger.kernel.org
Cc: Govindarajan, Sriramakrishnan
Subject: [PATCH] omap3evm: Migrate to smsc911x ethernet driver.
Migrate to smsc911x ethernet driver instead of smc911x driver.
The smsc911x ethernet driver supports NAPI and performs better
under heavy traffic. With the smc911x driver we were witnessing
very high iowait time for high IO load over NFS.
Signed-off-by: Sriramakrishnan s...@ti.com
---
This patch is generated against tip of for-next branch.
arch/arm/configs/omap3_evm_defconfig |4 +-
arch/arm/mach-omap2/board-omap3evm.c | 36
+
2 files changed, 29 insertions(+), 11 deletions(-)
diff --git a/arch/arm/configs/omap3_evm_defconfig
b/arch/arm/configs/omap3_evm_defconfig
index d5ff477..50afc67 100644
--- a/arch/arm/configs/omap3_evm_defconfig
+++ b/arch/arm/configs/omap3_evm_defconfig
@@ -617,8 +617,8 @@ CONFIG_MII=y
# CONFIG_DM9000 is not set
# CONFIG_ENC28J60 is not set
# CONFIG_ETHOC is not set
-CONFIG_SMC911X=y
-# CONFIG_SMSC911X is not set
+# CONFIG_SMC911X is not set
+CONFIG_SMSC911X=y
# CONFIG_DNET is not set
# CONFIG_IBM_NEW_EMAC_ZMII is not set
# CONFIG_IBM_NEW_EMAC_RGMII is not set
diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-
omap2/board-omap3evm.c
index 5d2310e..9bcdaf7 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -21,11 +21,13 @@
#include linux/gpio.h
#include linux/input.h
#include linux/leds.h
+#include linux/interrupt.h
#include linux/spi/spi.h
#include linux/spi/ads7846.h
#include linux/i2c/twl4030.h
#include linux/usb/otg.h
+#include linux/smsc911x.h
#include linux/regulator/machine.h
@@ -51,7 +53,8 @@
#define OMAP3EVM_ETHR_GPIO_IRQ 176
#define OMAP3EVM_SMC911X_CS 5
-static struct resource omap3evm_smc911x_resources[] = {
+#if defined(CONFIG_SMSC911X) || defined(CONFIG_SMSC911X_MODULE)
+static struct resource omap3evm_smsc911x_resources[] = {
[0] = {
.start = OMAP3EVM_ETHR_START,
.end= (OMAP3EVM_ETHR_START + OMAP3EVM_ETHR_SIZE - 1),
@@ -60,18 +63,28 @@ static struct resource
omap3evm_smc911x_resources[] = {
[1] = {
.start = OMAP_GPIO_IRQ(OMAP3EVM_ETHR_GPIO_IRQ),
.end= OMAP_GPIO_IRQ(OMAP3EVM_ETHR_GPIO_IRQ),
- .flags = IORESOURCE_IRQ,
+ .flags = (IORESOURCE_IRQ | IRQF_TRIGGER_LOW),
},
};
-static struct platform_device omap3evm_smc911x_device = {
- .name = smc911x,
+static struct smsc911x_platform_config smsc911x_config = {
+ .phy_interface = PHY_INTERFACE_MODE_MII,
+ .irq_polarity = SMSC911X_IRQ_POLARITY_ACTIVE_LOW,
+ .irq_type = SMSC911X_IRQ_TYPE_OPEN_DRAIN,
+ .flags = (SMSC911X_USE_32BIT |
SMSC911X_SAVE_MAC_ADDRESS),
+};
+
+static struct platform_device omap3evm_smsc911x_device = {
+ .name = smsc911x,
.id = -1,
- .num_resources = ARRAY_SIZE(omap3evm_smc911x_resources),
- .resource = omap3evm_smc911x_resources[0],
+ .num_resources = ARRAY_SIZE(omap3evm_smsc911x_resources),
+ .resource = omap3evm_smsc911x_resources[0],
+ .dev= {
+ .platform_data = smsc911x_config,
+ },
};
-static inline void __init omap3evm_init_smc911x(void)
+static inline void __init omap3evm_init_smsc911x(void)
{
int eth_cs;
struct clk *l3ck;
@@ -92,8 +105,14 @@ static inline void __init
omap3evm_init_smc911x(void)
}
gpio_direction_input(OMAP3EVM_ETHR_GPIO_IRQ);
+
+ platform_device_register(omap3evm_smsc911x_device);
}
+#else
+static inline void __init omap3evm_init_smsc911x(void) { return; }
+#endif
+
static struct regulator_consumer_supply omap3evm_vmmc1_supply = {
.supply = vmmc,
};
@@ -335,12 +354,10 @@ static void __init omap3_evm_init_irq(void)
omap2_init_common_hw(mt46h32m32lf6_sdrc_params, NULL);
omap_init_irq();
omap_gpio_init();
- omap3evm_init_smc911x();
}
static struct platform_device *omap3_evm_devices[] __initdata = {
omap3_evm_lcd_device,
- omap3evm_smc911x_device,
};
static void __init omap3_evm_init(void)
@@
RE: [PATCH] omap3evm: Migrate to smsc911x ethernet driver.
Sorry for the earlier mail, not meant for the l-o list :(
Regards,
Anuj Aggarwal
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Aggarwal, Anuj
Sent: Thursday, November 12, 2009 4:27 PM
To: linux-omap@vger.kernel.org
Subject: FW: [PATCH] omap3evm: Migrate to smsc911x ethernet driver.
Pushed this patch to psp-group:build7 ...
Regards,
Anuj Aggarwal
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Govindarajan, Sriramakrishnan
Sent: Wednesday, November 11, 2009 1:43 PM
To: linux-omap@vger.kernel.org
Subject: RE: [PATCH] omap3evm: Migrate to smsc911x ethernet driver.
Tony,
Are there comments with respect to this patch. Will this be merged in the
next window?
Regards
Sriram
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Govindarajan, Sriramakrishnan
Sent: Wednesday, October 28, 2009 7:19 PM
To: linux-omap@vger.kernel.org
Cc: Govindarajan, Sriramakrishnan
Subject: [PATCH] omap3evm: Migrate to smsc911x ethernet driver.
Migrate to smsc911x ethernet driver instead of smc911x driver.
The smsc911x ethernet driver supports NAPI and performs better
under heavy traffic. With the smc911x driver we were witnessing
very high iowait time for high IO load over NFS.
Signed-off-by: Sriramakrishnan s...@ti.com
---
This patch is generated against tip of for-next branch.
arch/arm/configs/omap3_evm_defconfig |4 +-
arch/arm/mach-omap2/board-omap3evm.c | 36
+
2 files changed, 29 insertions(+), 11 deletions(-)
diff --git a/arch/arm/configs/omap3_evm_defconfig
b/arch/arm/configs/omap3_evm_defconfig
index d5ff477..50afc67 100644
--- a/arch/arm/configs/omap3_evm_defconfig
+++ b/arch/arm/configs/omap3_evm_defconfig
@@ -617,8 +617,8 @@ CONFIG_MII=y
# CONFIG_DM9000 is not set
# CONFIG_ENC28J60 is not set
# CONFIG_ETHOC is not set
-CONFIG_SMC911X=y
-# CONFIG_SMSC911X is not set
+# CONFIG_SMC911X is not set
+CONFIG_SMSC911X=y
# CONFIG_DNET is not set
# CONFIG_IBM_NEW_EMAC_ZMII is not set
# CONFIG_IBM_NEW_EMAC_RGMII is not set
diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-
omap2/board-omap3evm.c
index 5d2310e..9bcdaf7 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -21,11 +21,13 @@
#include linux/gpio.h
#include linux/input.h
#include linux/leds.h
+#include linux/interrupt.h
#include linux/spi/spi.h
#include linux/spi/ads7846.h
#include linux/i2c/twl4030.h
#include linux/usb/otg.h
+#include linux/smsc911x.h
#include linux/regulator/machine.h
@@ -51,7 +53,8 @@
#define OMAP3EVM_ETHR_GPIO_IRQ 176
#define OMAP3EVM_SMC911X_CS5
-static struct resource omap3evm_smc911x_resources[] = {
+#if defined(CONFIG_SMSC911X) || defined(CONFIG_SMSC911X_MODULE)
+static struct resource omap3evm_smsc911x_resources[] = {
[0] = {
.start = OMAP3EVM_ETHR_START,
.end= (OMAP3EVM_ETHR_START + OMAP3EVM_ETHR_SIZE - 1),
@@ -60,18 +63,28 @@ static struct resource
omap3evm_smc911x_resources[] = {
[1] = {
.start = OMAP_GPIO_IRQ(OMAP3EVM_ETHR_GPIO_IRQ),
.end= OMAP_GPIO_IRQ(OMAP3EVM_ETHR_GPIO_IRQ),
- .flags = IORESOURCE_IRQ,
+ .flags = (IORESOURCE_IRQ | IRQF_TRIGGER_LOW),
},
};
-static struct platform_device omap3evm_smc911x_device = {
- .name = smc911x,
+static struct smsc911x_platform_config smsc911x_config = {
+ .phy_interface = PHY_INTERFACE_MODE_MII,
+ .irq_polarity = SMSC911X_IRQ_POLARITY_ACTIVE_LOW,
+ .irq_type = SMSC911X_IRQ_TYPE_OPEN_DRAIN,
+ .flags = (SMSC911X_USE_32BIT |
SMSC911X_SAVE_MAC_ADDRESS),
+};
+
+static struct platform_device omap3evm_smsc911x_device = {
+ .name = smsc911x,
.id = -1,
- .num_resources = ARRAY_SIZE(omap3evm_smc911x_resources),
- .resource = omap3evm_smc911x_resources[0],
+ .num_resources = ARRAY_SIZE(omap3evm_smsc911x_resources),
+ .resource = omap3evm_smsc911x_resources[0],
+ .dev= {
+ .platform_data = smsc911x_config,
+ },
};
-static inline void __init omap3evm_init_smc911x(void)
+static inline void __init omap3evm_init_smsc911x(void)
{
int eth_cs;
struct clk *l3ck;
@@ -92,8 +105,14 @@ static inline void __init
omap3evm_init_smc911x(void)
}
gpio_direction_input(OMAP3EVM_ETHR_GPIO_IRQ);
+
+ platform_device_register(omap3evm_smsc911x_device);
}
+#else
+static inline void __init omap3evm_init_smsc911x(void) { return; }
+#endif
+
static struct regulator_consumer_supply omap3evm_vmmc1_supply
RE: Some patches need reposting, inbox cleared, patchwork cleared
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Tony Lindgren Sent: Saturday, November 14, 2009 6:38 AM To: Pandita, Vikram Cc: linux-omap@vger.kernel.org Subject: Re: Some patches need reposting, inbox cleared, patchwork cleared * Pandita, Vikram vikram.pand...@ti.com [091113 11:06]: Tony -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Pandita, Vikram From: Tony Lindgren [mailto:t...@atomide.com] I just verified booting zoom3 on l-o master, and its working fine. OK good. Can you also try booting this patch from Felipe on 3630: http://patchwork.kernel.org/patch/59540/ Patch does not apply. Rebasing now and testing. Rebased Patch (attached) boots up fine now on 3630 Zoom3 board. Logs: CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7f CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine: OMAP Zoom3 board Memory policy: ECC disabled, Data cache writeback OMAP3630 ES1.0 (l2cache iva sgx neon isp ) OK, thanks applying it. Tony, I am not able to see the following patch in the list: OMAP3EVM: Use the twl4030_setup_data for headset pop-removal http://marc.info/?l=linux-omapm=125368984011630w=2 Can you apply it please? Tony -- 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 -- 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: Doubts around SoC audio on omap3
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Enric Balletbò i Serra Sent: Monday, November 16, 2009 11:06 PM To: linux-omap@vger.kernel.org Subject: Doubts around SoC audio on omap3 Hi all, I would like to add support for SoC audio on the IGEP v2 board but I have some doubts about how to do. As I have seen in the source code, the SoC driver for IGEP should be the same as omap3evm, overo and cm-t35. So, is better to use the solution adopted by the board CM-T35 or add a specific file for the board IGEP like omap3evm board ? Is there any difference between the omap3evm driver and the overo driver ? Including alsa-devel list too... There could be changes in the machine drivers for different OMAP3 based platforms like omap3evm and overo. It depends on exactly what is present (I/Ps, O/Ps) on you EVM and how do you want to configure it, and in that case, it makes sense to create a new machine specific file for your board. Thanks in advance, Enric -- 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 -- 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: Exporting functions doing common register access
-Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Tuesday, November 17, 2009 2:46 AM To: Aggarwal, Anuj Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH] OMAP: Exporting functions doing common register access Hello Anuj, On Mon, 16 Nov 2009, Anuj Aggarwal wrote: These functions need to be exported so that drivers (e.g. McBSP) can be configured as modules. McBSP driver gets built as a module when ASoC driver for OMAP3 EVM is configured as module. McBSP driver uses functions like omap_ctrl_readl/omap_ctrl_writel, which are defined in control.c file but not exported. Without that, McBSP driver fails to build as a module. Signed-off-by: Anuj Aggarwal anuj.aggar...@ti.com This will prevent the McBSP driver from being usable across chips. For example, if a future OMAP comes out with McBSP clock source switching implemented in a different way, or if a DaVinci chip comes out with a McBSP block but no SCM block, this either won't build or won't run. A better approach would be to move the OMAP2/3-specific functions from the McBSP driver into the OMAP McBSP integration code, arch/arm/*omap*/mcbsp.c, and to define function pointers in struct platform_data for these functions, and to pass them from the integration code into the device driver code. That will make these drivers independent of chip integration details. Sorry to confuse you, I was talking about the platform specific ASoC-McBSP code for OMAP (file - sound/soc/omap/omap-mcbsp.c) platform. The McBSP driver - both platform and machine specific - doesn't use the functions exported by the patch. Including alsa-devel list too... - Paul -- 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: Artifacts present in AIC23 capture for 48 KHz sampling rate
-Original Message- From: Aggarwal, Anuj Sent: Friday, November 06, 2009 6:28 PM To: alsa-de...@alsa-project.org; 'linux-omap@vger.kernel.org' Subject: Artifacts present in AIC23 capture for 48 KHz sampling rate Hi, I am observing artifacts (sharp spikes at fixed intervals) while capturing audio on AM3517 EVM and AIC23 codec. They are present only in one of the channels when I am capturing at 48 KHz. All other sampling rates are working fine with the above said combination. I have also attached the screenshot taken with the help of Audacity utility. Here, I tried recording silence but artifacts were observed on one channel. Has anyone also observed the similar behavior with AIC23 codec? Any hints on what could be the root cause? [Aggarwal, Anuj] On further debugging, I found that the function find_rate() in sound/soc/codecs/tlv320aic23.c is not returning the correct value for capture in 48KHz sample rate. In USB mode (MCLK=12MHz), for 48KHz, it returns 0x7D (CLKOUT=0, CLKIN=1, SR[3:0]=0xF, BOSR=1, Normal=1) whereas as per the AIC23B spec, it should have been 0x5D (CLKOUT=0, CLKIN=1, SR[3:0]=0x7, BOSR=1, Normal=1). When I forcefully write the above said value to the Sample Rate Control register, things work fine for me for 48KHz capture. Is my understanding correct for this problem? Can someone help me understand how the function calculates the appropriate value? Regards, Anuj Aggarwal -- 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: Exporting functions doing common register access
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Aggarwal, Anuj Sent: Tuesday, November 17, 2009 11:28 AM To: Paul Walmsley Cc: linux-omap@vger.kernel.org; alsa-de...@alsa-project.org Subject: RE: [PATCH] OMAP: Exporting functions doing common register access -Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Tuesday, November 17, 2009 2:46 AM To: Aggarwal, Anuj Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH] OMAP: Exporting functions doing common register access Hello Anuj, On Mon, 16 Nov 2009, Anuj Aggarwal wrote: These functions need to be exported so that drivers (e.g. McBSP) can be configured as modules. McBSP driver gets built as a module when ASoC driver for OMAP3 EVM is configured as module. McBSP driver uses functions like omap_ctrl_readl/omap_ctrl_writel, which are defined in control.c file but not exported. Without that, McBSP driver fails to build as a module. Signed-off-by: Anuj Aggarwal anuj.aggar...@ti.com This will prevent the McBSP driver from being usable across chips. For example, if a future OMAP comes out with McBSP clock source switching implemented in a different way, or if a DaVinci chip comes out with a McBSP block but no SCM block, this either won't build or won't run. A better approach would be to move the OMAP2/3-specific functions from the McBSP driver into the OMAP McBSP integration code, arch/arm/*omap*/mcbsp.c, and to define function pointers in struct platform_data for these functions, and to pass them from the integration code into the device driver code. That will make these drivers independent of chip integration details. Sorry to confuse you, I was talking about the platform specific ASoC-McBSP code for OMAP (file - sound/soc/omap/omap-mcbsp.c) platform. The McBSP driver - both platform and machine specific - doesn't use the functions exported by the patch. Including alsa-devel list too... [Aggarwal, Anuj] Any comments on this patch? Do I have to re-work this? - Paul -- 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 -- 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] Artifacts present in AIC23 capture for 48 KHz sampling rate
-Original Message-
From: Troy Kisky [mailto:troy.ki...@boundarydevices.com]
Sent: Wednesday, November 18, 2009 12:39 AM
To: Aggarwal, Anuj
Cc: alsa-de...@alsa-project.org; linux-omap@vger.kernel.org
Subject: Re: [alsa-devel] Artifacts present in AIC23 capture for 48 KHz
sampling rate
Aggarwal, Anuj wrote:
-Original Message-
From: Aggarwal, Anuj
Sent: Friday, November 06, 2009 6:28 PM
To: alsa-de...@alsa-project.org; 'linux-omap@vger.kernel.org'
Subject: Artifacts present in AIC23 capture for 48 KHz sampling rate
Hi,
I am observing artifacts (sharp spikes at fixed intervals) while
capturing audio on AM3517 EVM and AIC23 codec. They are present only
in one of the channels when I am capturing at 48 KHz. All other
sampling rates are working fine with the above said combination.
I have also attached the screenshot taken with the help of Audacity
utility. Here, I tried recording silence but artifacts were observed
on one channel.
Has anyone also observed the similar behavior with AIC23 codec? Any
hints on what could be the root cause?
[Aggarwal, Anuj] On further debugging, I found that the function
find_rate() in sound/soc/codecs/tlv320aic23.c is not returning
the correct value for capture in 48KHz sample rate. In USB mode
(MCLK=12MHz), for 48KHz, it returns 0x7D (CLKOUT=0, CLKIN=1,
SR[3:0]=0xF, BOSR=1, Normal=1) whereas as per the AIC23B spec,
0x7D would be BOSR = 0, USB/NORMAL = 1, SR=0xff, div2 = 1
The bug is with sr_valid_mask,
static const unsigned short sr_valid_mask[] = {
LOWER_GROUP|UPPER_GROUP,/* Normal, bosr - 0*/
LOWER_GROUP|UPPER_GROUP,/* Normal, bosr - 1*/
LOWER_GROUP,/* Usb, bosr - 0*/
UPPER_GROUP,/* Usb, bosr - 1*/
};
should be
static const unsigned short sr_valid_mask[] = {
LOWER_GROUP|UPPER_GROUP,/* Normal, bosr - 0*/
LOWER_GROUP,/* Usb, bosr - 0*/
LOWER_GROUP|UPPER_GROUP,/* Normal, bosr - 1*/
UPPER_GROUP,/* Usb, bosr - 1*/
};
Can you give this a try and let me know?
[Aggarwal, Anuj] I tried this on AM3517 EVM + AIC23B; it works
fine for me. But I have tested the fix only with a 12 MHz clock.
Thanks for quickly fixing this.
Thanks
Troy
--
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] OMAP3: MCBSP: Suspend/resume failure fix
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Jarkko Nikula
Sent: Saturday, November 14, 2009 1:50 PM
To: Wang, Jane
Cc: alsa-de...@alsa-project.org; linux-omap@vger.kernel.org;
peter.ujfal...@nokia.com; broo...@opensource.wolfsonmicro.com
Subject: Re: [PATCH 1/2] OMAP3: MCBSP: Suspend/resume failure fix
Hi
On Fri, 13 Nov 2009 11:39:47 -0600
Jane Wang jw...@ti.com wrote:
McBSP fucntional clock is not disabled when suspend is triggerd which
prevents PER domain entering target low-power state. To fix the problem:
1. Disable/enable McBSP functional clock for suspend/resume.
2. In addition, reconfigure McBSP, this is needed when systerm comes out
of OFF state.
...
--- a/arch/arm/plat-omap/include/mach/mcbsp.h
+++ b/arch/arm/plat-omap/include/mach/mcbsp.h
@@ -440,6 +440,8 @@ static inline int
omap_mcbsp_get_dma_op_mode(unsigned int id) { return 0; }
#endif
int omap_mcbsp_request(unsigned int id);
void omap_mcbsp_free(unsigned int id);
+void omap_mcbsp_disable_fclk(unsigned int id);
+void omap_mcbsp_enable_fclk(unsigned int id);
...
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -229,18 +229,28 @@ static int omap_mcbsp_dai_trigger(struct
snd_pcm_substream *substream, int cmd,
switch (cmd) {
case SNDRV_PCM_TRIGGER_START:
- case SNDRV_PCM_TRIGGER_RESUME:
case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
mcbsp_data-active++;
omap_mcbsp_start(mcbsp_data-bus_id, play, !play);
break;
+ case SNDRV_PCM_TRIGGER_RESUME:
+ mcbsp_data-active++;
+ omap_mcbsp_enable_fclk(mcbsp_data-bus_id);
+ omap_mcbsp_config(mcbsp_data-bus_id,
+ mcbsp_data-regs);
+ omap_mcbsp_start(mcbsp_data-bus_id, play, !play);
+ break;
For me this looks more like a simple workaround for the audio case than
comprehensive implementation to McBSP OFF mode context save/restore. My
thoughts:
1. McBSP clock management partially moved out of low-level driver
2. McBSP client must do the context restore
I do know that arch/arm/plat-omap/mcbsp.c enables the clocks in
omap_mcbsp_request, I don't know do some API or feature there really
require clocks (or McBSP itself) to be active just after the request
time but I would look that path instead (even it is more complicated).
If no API or feature would require active McBSP block before the
omap_mcbsp_start call, then the clock management could be done inside
the omap_mcbsp_start/-stop functions.
[Aggarwal, Anuj] I tried doing that but it didn't work because before
_start, we need to call set_hw_params which configures mcbsp, for which
clocks are required.
Also context save/restore operations belongs more to PM callbacks
of .../plat-omap/mcbsp.c. Or probably that can be done also dynamically
inside the omap_mcbsp_start/-stop for keeping the whole McBSP shutdown
whenever it is idle.
[Aggarwal, Anuj] I am sorry I couldn't understand that. Did you mean that
PM hooks can be added in the mcbsp driver which can be registered and called
As and when required? Any reference driver for this, if my understanding
is correct?
I think it's worth to look McBSP register cache concept [1] from Janusz
Krzysztofik would it help all of this context save/restore operations.
[Aggarwal, Anuj] I tried these two patches on omap3 evm but they didn't
work for me. The system doesn't go to the suspend state when I do:
echo mem /sys/power/state
And the culprits were core (think sdma) and per domain. I tried
disabling the mcbsp i/f clock as well but it didn't help. On mcbsp
register dump, I couldn't find the sysconfig register getting
configured. Could that be the root cause?
--
Jarkko
1. http://www.spinics.net/lists/linux-omap/msg16720.html
--
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
--
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: Fix AIC23 suspend/resume hang
-Original Message-
From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com]
Sent: Wednesday, November 25, 2009 7:04 PM
To: Aggarwal, Anuj
Cc: alsa-de...@alsa-project.org; linux-omap@vger.kernel.org
Subject: Re: [PATCH] ASoC: AM3517: Fix AIC23 suspend/resume hang
On Wed, Nov 25, 2009 at 06:40:31PM +0530, Anuj Aggarwal wrote:
System hang is observed While trying to do suspend. It was because
of an infinite loop in the AIC23 resume path which was trying to
restore AIC23 register values from the register cache.
This doesn't appear to tie in with the actual patch - where's the
infinite loop? The register cache restore loop has a constant bound and
I can't see anything that would make it spin infinitely.
[Aggarwal, Anuj] Here is the original code:
snip
int i;
u16 reg;
/* Sync reg_cache with the hardware */
for (reg = 0; reg ARRAY_SIZE(tlv320aic23_reg); i++) {
u16 val = tlv320aic23_read_reg_cache(codec, reg);
tlv320aic23_write(codec, reg, val);
}
/snip
I can see 'i' getting incremented, instead of 'reg'. Isn't this an
infinite loop?
This patch fixes the problem by correcting the resume path and
properly activating/deactivating the digital interface while
doing the suspend / off transitions.
What do you mean by properly activating/deactivating the digital
interface?
[Aggarwal, Anuj] The driver was only deactivating the digital
interface and not activating it. Hence added that part.
case SND_SOC_BIAS_STANDBY:
- /* everything off except vref/vmid, */
- tlv320aic23_write(codec, TLV320AIC23_PWR, reg | 0x0040);
+ /* Activate the digital interface */
+ tlv320aic23_write(codec, TLV320AIC23_ACTIVE, 0x1);
break;
case SND_SOC_BIAS_OFF:
- /* everything off, dac mute, inactive */
+ /* Deactivate the digital interface */
tlv320aic23_write(codec, TLV320AIC23_ACTIVE, 0x0);
- tlv320aic23_write(codec, TLV320AIC23_PWR, 0x);
break;
This looks wrong - the driver is now no longer managing bias levels at
all.
[Aggarwal, Anuj] The bias levels were wrongly managed earlier. While doing
a suspend, it was powering off all the interfaces and while coming up, it
was not switching on the required interfaces. Hence no sound was coming
out if audio was played back.
Moreover, I referred twl4030 codec and there also the driver was only
handling the codec power control bit in _STANDBY. So based my patch
on that.
On each bias level, which are the interfaces which need to be switched
on / off?
- u16 reg;
-
- /* Sync reg_cache with the hardware */
- for (reg = 0; reg ARRAY_SIZE(tlv320aic23_reg); i++) {
- u16 val = tlv320aic23_read_reg_cache(codec, reg);
- tlv320aic23_write(codec, reg, val);
- }
This also looks wrong, the register cache restore has been completely
removed so if the power to the device is cut during suspend then the
device will go back to register defaults and no longer function
correctly after resume.
[Aggarwal, Anuj] I can add that register cache restore again with the
necessary checks.
--
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: AM3517: Fix AIC23 suspend/resume hang
-Original Message-
From: Troy Kisky [mailto:troy.ki...@boundarydevices.com]
Sent: Thursday, November 26, 2009 1:53 AM
To: Aggarwal, Anuj
Cc: alsa-de...@alsa-project.org; linux-omap@vger.kernel.org; Mark Brown;
Arun KS
Subject: Re: [alsa-devel] [PATCH] ASoC: AM3517: Fix AIC23 suspend/resume
hang
Anuj Aggarwal wrote:
System hang is observed While trying to do suspend. It was because
of an infinite loop in the AIC23 resume path which was trying to
restore AIC23 register values from the register cache.
This patch fixes the problem by correcting the resume path and
properly activating/deactivating the digital interface while
doing the suspend / off transitions.
Signed-off-by: Anuj Aggarwal anuj.aggar...@ti.com
---
sound/soc/codecs/tlv320aic23.c | 16 +++-
1 files changed, 3 insertions(+), 13 deletions(-)
diff --git a/sound/soc/codecs/tlv320aic23.c
b/sound/soc/codecs/tlv320aic23.c
index 6b24d8b..cabe60c 100644
--- a/sound/soc/codecs/tlv320aic23.c
+++ b/sound/soc/codecs/tlv320aic23.c
@@ -565,13 +565,12 @@ static int tlv320aic23_set_bias_level(struct
snd_soc_codec *codec,
case SND_SOC_BIAS_PREPARE:
break;
case SND_SOC_BIAS_STANDBY:
- /* everything off except vref/vmid, */
- tlv320aic23_write(codec, TLV320AIC23_PWR, reg | 0x0040);
+ /* Activate the digital interface */
+ tlv320aic23_write(codec, TLV320AIC23_ACTIVE, 0x1);
break;
case SND_SOC_BIAS_OFF:
- /* everything off, dac mute, inactive */
+ /* Deactivate the digital interface */
tlv320aic23_write(codec, TLV320AIC23_ACTIVE, 0x0);
- tlv320aic23_write(codec, TLV320AIC23_PWR, 0x);
break;
}
codec-bias_level = level;
@@ -615,7 +614,6 @@ static int tlv320aic23_suspend(struct
platform_device *pdev,
struct snd_soc_device *socdev = platform_get_drvdata(pdev);
struct snd_soc_codec *codec = socdev-card-codec;
- tlv320aic23_write(codec, TLV320AIC23_ACTIVE, 0x0);
tlv320aic23_set_bias_level(codec, SND_SOC_BIAS_OFF);
return 0;
@@ -625,14 +623,6 @@ static int tlv320aic23_resume(struct
platform_device *pdev)
{
struct snd_soc_device *socdev = platform_get_drvdata(pdev);
struct snd_soc_codec *codec = socdev-card-codec;
- int i;
- u16 reg;
-
- /* Sync reg_cache with the hardware */
- for (reg = 0; reg ARRAY_SIZE(tlv320aic23_reg); i++) {
- u16 val = tlv320aic23_read_reg_cache(codec, reg);
- tlv320aic23_write(codec, reg, val);
- }
Changing to
for (reg = 0; reg ARRAY_SIZE(tlv320aic23_reg); reg++) {
should be enough to fix the infinite loop.
Could you try this without the rest of the patch?
I have already tried that but it doesn't fix the problem entirely.
Still, I was not able to playback properly because the bias settings
were not handled correctly and as you can see, it writes to some
invalid registers too (all registers don't exist between 0 and ARRAY_SIZE).
tlv320aic23_set_bias_level(codec, SND_SOC_BIAS_STANDBY);
tlv320aic23_set_bias_level(codec, codec-suspend_bias_level);
Adding Arun to cc list
--
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: Fix AIC23 suspend/resume hang
-Original Message-
From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com]
Sent: Thursday, November 26, 2009 1:10 AM
To: Aggarwal, Anuj
Cc: alsa-de...@alsa-project.org; linux-omap@vger.kernel.org
Subject: Re: [PATCH] ASoC: AM3517: Fix AIC23 suspend/resume hang
On Thu, Nov 26, 2009 at 12:49:11AM +0530, Aggarwal, Anuj wrote:
snip
int i;
u16 reg;
/* Sync reg_cache with the hardware */
for (reg = 0; reg ARRAY_SIZE(tlv320aic23_reg); i++) {
u16 val = tlv320aic23_read_reg_cache(codec, reg);
tlv320aic23_write(codec, reg, val);
}
/snip
I can see 'i' getting incremented, instead of 'reg'. Isn't this an
infinite loop?
Yes, that does look entirely buggy - it seems fairly clear that suspend
and resume have never worked with this driver. The fact that you were
removing the loop entirely meant I didn't read the actual code for bugs.
This patch fixes the problem by correcting the resume path and
properly activating/deactivating the digital interface while
doing the suspend / off transitions.
What do you mean by properly activating/deactivating the digital
interface?
[Aggarwal, Anuj] The driver was only deactivating the digital
interface and not activating it. Hence added that part.
So this is a separate issue, and should ideally be a separate patch - it
looks like you've got three different changes here, one to fix the buggy
register cache restore, one to manage the PWR bit on suspend and another
to possibly fix the bias configuration. You certainly need to identify
all three changes in the changelog, especially for things like this
which look like they should go in as bug fixes (and bearing in mind that
it's the end of the release cycle).
Fine with me, I will push individual patches for all the issues.
Glancing at the code there's much more management required here -
there's other places where it's managed and the code needs to be joined
up with them. The setting should only be restored if the device was
active when suspended, not unconditionally.
case SND_SOC_BIAS_STANDBY:
- /* everything off except vref/vmid, */
- tlv320aic23_write(codec, TLV320AIC23_PWR, reg | 0x0040);
+ /* Activate the digital interface */
+ tlv320aic23_write(codec, TLV320AIC23_ACTIVE, 0x1);
break;
case SND_SOC_BIAS_OFF:
- /* everything off, dac mute, inactive */
+ /* Deactivate the digital interface */
tlv320aic23_write(codec, TLV320AIC23_ACTIVE, 0x0);
- tlv320aic23_write(codec, TLV320AIC23_PWR, 0x);
break;
This looks wrong - the driver is now no longer managing bias levels at
all.
[Aggarwal, Anuj] The bias levels were wrongly managed earlier. While
doing
a suspend, it was powering off all the interfaces and while coming up,
it
was not switching on the required interfaces. Hence no sound was coming
out if audio was played back.
Note that this CODEC driver impelements DAPM and so all the bits in the
power register which are controlled by DAPM will be managed by the ASoC
core without any action by the driver.
On each bias level, which are the interfaces which need to be switched
on / off?
The biases and any other device-wide settings, everything else should be
managed via DAPM if it's in use.
--
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: AM3517: Fix AIC23 suspend/resume hang
-Original Message- From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com] Sent: Thursday, November 26, 2009 3:53 PM To: Aggarwal, Anuj Cc: 'Troy Kisky'; alsa-de...@alsa-project.org; linux-omap@vger.kernel.org; Arun KS Subject: Re: [alsa-devel] [PATCH] ASoC: AM3517: Fix AIC23 suspend/resume hang On Thu, Nov 26, 2009 at 08:31:11AM +0530, Aggarwal, Anuj wrote: I have already tried that but it doesn't fix the problem entirely. Still, I was not able to playback properly because the bias settings were not handled correctly and as you can see, it writes to some invalid registers too (all registers don't exist between 0 and ARRAY_SIZE). Please also note the following patch which is queued for 2.6.32: commit 50b6bce59d154b5db137907a5c0ed45a4e7a3829 Author: Mark Brown broo...@opensource.wolfsonmicro.com Date: Mon Nov 23 13:11:53 2009 + ASoC: Fix suspend with active audio streams [Aggarwal, Anuj] I am also seeing one more problem with the original driver, although I am not sure if the problem is in the audio driver. When tried to capture, using NFS as storage, it gives overrun error and comes out with: arecord: pcm_read:1617: read error: Input/output error It happen always after ~20 sec, file size ~5MB. Tried with multiple configurations in arecord but no use. When tried: arecord -f cd /dev/null, it works fine. Same issue doesn't come too when I try to store the captured audio file on a MMC card. Any idea what could be the problem? Why arecord goes for a toss after a single overrun error and why it is happening always after ~20 sec? Is there something which can be tried to narrow down the problem? -- 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] AM3517: MMC: Add support for HSMMC
-Original Message- From: Aggarwal, Anuj Sent: Monday, November 23, 2009 11:55 PM To: linux-omap@vger.kernel.org Cc: Aggarwal, Anuj Subject: [PATCH 0/4] AM3517: MMC: Add support for HSMMC This patch series adds support for HSMMC for AM3517 platform. It also enables the HSMMC driver in the AM3517 defconfig. Anuj Aggarwal (4): AM3517: MMC: Add low-level init code for HSMMC controller AM3517: MMC: Modifying board-evm file to add mmc_init AM3517: MMC: Modifying Makefile to enable MMC init AM3517: MMC: Make HSMMC driver built-in arch/arm/configs/am3517_evm_defconfig | 21 +++- arch/arm/mach-omap2/Makefile |3 +- arch/arm/mach-omap2/board-am3517evm.c | 22 +++ arch/arm/mach-omap2/mmc-am3517evm.c | 267 + arch/arm/mach-omap2/mmc-am3517evm.h | 22 +++ 5 files changed, 333 insertions(+), 2 deletions(-) create mode 100644 arch/arm/mach-omap2/mmc-am3517evm.c create mode 100644 arch/arm/mach-omap2/mmc-am3517evm.h [Aggarwal, Anuj] Any comments on the patch series? -- 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: AM3517: Fix AIC23 suspend/resume hang
-Original Message- From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com] Sent: Thursday, November 26, 2009 8:41 PM To: Aggarwal, Anuj Cc: 'Troy Kisky'; alsa-de...@alsa-project.org; linux-omap@vger.kernel.org; Arun KS Subject: Re: [alsa-devel] [PATCH] ASoC: AM3517: Fix AIC23 suspend/resume hang On Thu, Nov 26, 2009 at 08:26:44PM +0530, Aggarwal, Anuj wrote: driver, although I am not sure if the problem is in the audio driver. When tried to capture, using NFS as storage, it gives overrun error and comes out with: arecord: pcm_read:1617: read error: Input/output error It happen always after ~20 sec, file size ~5MB. Tried with multiple configurations in arecord but no use. When tried: arecord -f cd /dev/null, it works fine. Same issue doesn't come too when I try to store the captured audio file on a MMC card. Any idea what could be the problem? Why arecord goes for a toss after a single overrun error and why it is happening always after ~20 sec? Is there something which can be tried to narrow down the problem? Sounds like you've narrowed the problem down to a performance issue with NFS writeout - it's probably having trouble keeping up with your I/O rate. This isn't 100% surprising with smaller systems, sometimes tuning the NFS configuration can resolve the issue but sometimes the hardware is just underspecified. [Aggarwal, Anuj] I am still surprised how this could be a NFS writeout issue as we are seeing a consistent read/write rate of 2Mbps over tftp. When dd command is used for read/write to further check NFS performance, 2Mbps for write and 4Mbps for read is observed. Does that still mean nfs is the culprit? What could be tweaked in audio/network driver to avoid this problem, any suggestions? arecord is a pretty basic program and doesn't try terribly hard to recover from errors. [Aggarwal, Anuj] Any other utility to try capture which does error recovering too? -- 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: AM3517: Fix AIC23 suspend/resume hang
The performance numbers are in Mbytes/sec. Sorry for the typo :( -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Aggarwal, Anuj Sent: Thursday, November 26, 2009 8:52 PM To: Mark Brown Cc: 'Troy Kisky'; alsa-de...@alsa-project.org; linux-omap@vger.kernel.org; Arun KS Subject: RE: [alsa-devel] [PATCH] ASoC: AM3517: Fix AIC23 suspend/resume hang -Original Message- From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com] Sent: Thursday, November 26, 2009 8:41 PM To: Aggarwal, Anuj Cc: 'Troy Kisky'; alsa-de...@alsa-project.org; linux- o...@vger.kernel.org; Arun KS Subject: Re: [alsa-devel] [PATCH] ASoC: AM3517: Fix AIC23 suspend/resume hang On Thu, Nov 26, 2009 at 08:26:44PM +0530, Aggarwal, Anuj wrote: driver, although I am not sure if the problem is in the audio driver. When tried to capture, using NFS as storage, it gives overrun error and comes out with: arecord: pcm_read:1617: read error: Input/output error It happen always after ~20 sec, file size ~5MB. Tried with multiple configurations in arecord but no use. When tried: arecord -f cd /dev/null, it works fine. Same issue doesn't come too when I try to store the captured audio file on a MMC card. Any idea what could be the problem? Why arecord goes for a toss after a single overrun error and why it is happening always after ~20 sec? Is there something which can be tried to narrow down the problem? Sounds like you've narrowed the problem down to a performance issue with NFS writeout - it's probably having trouble keeping up with your I/O rate. This isn't 100% surprising with smaller systems, sometimes tuning the NFS configuration can resolve the issue but sometimes the hardware is just underspecified. [Aggarwal, Anuj] I am still surprised how this could be a NFS writeout issue as we are seeing a consistent read/write rate of 2Mbps over tftp. When dd command is used for read/write to further check NFS performance, 2Mbps for write and 4Mbps for read is observed. Does that still mean nfs is the culprit? What could be tweaked in audio/network driver to avoid this problem, any suggestions? arecord is a pretty basic program and doesn't try terribly hard to recover from errors. [Aggarwal, Anuj] Any other utility to try capture which does error recovering too? -- 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 -- 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: AM3517: Fix AIC23 suspend/resume hang
-Original Message- From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com] Sent: Thursday, November 26, 2009 9:00 PM To: Aggarwal, Anuj Cc: 'Troy Kisky'; alsa-de...@alsa-project.org; linux-omap@vger.kernel.org; Arun KS Subject: Re: [alsa-devel] [PATCH] ASoC: AM3517: Fix AIC23 suspend/resume hang On Thu, Nov 26, 2009 at 08:52:08PM +0530, Aggarwal, Anuj wrote: [Aggarwal, Anuj] I am still surprised how this could be a NFS writeout issue as we are seeing a consistent read/write rate of 2Mbps over tftp. When dd command is used for read/write to further check NFS performance, 2Mbps for write and 4Mbps for read is observed. Does that still mean nfs is the culprit? What could be tweaked in audio/network driver to avoid this problem, any suggestions? There can also be issues with the way the data gets pushed into NFS interacting poorly - it's not just the raw data rate that's in play here, it's also things like how often the writes are done and how big they are. Possibly also overhead from interacting with the ethernet chip but that's not normally an issue for anything modern. The fact that this only happens when NFS is in use seems a fairly clear pointer to an interacton there. [Aggarwal, Anuj] We were able to fine tune NFS and use arecord to capture large files. But some more problems cropped up when tried to suspend / resume. Basic playback is working fine wrt suspend/resume. But capture, either tried independently or with playback, is creating a system wide hang. I fixed that infinite-loop in resume path but I believe something else needs cleanup too. Any pointers? [Aggarwal, Anuj] Any other utility to try capture which does error recovering too? Not for the console off the top of my head, and TBH I don't really know how good the error handling is in the various apps. You could also try playing with the buffer size options in arecord. -- 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: AIC23: Fixing infinite loop in resume path
@@ -625,11 +625,10 @@ static int tlv320aic23_resume(struct
platform_device *pdev)
{
struct snd_soc_device *socdev = platform_get_drvdata(pdev);
struct snd_soc_codec *codec = socdev-card-codec;
- int i;
u16 reg;
/* Sync reg_cache with the hardware */
- for (reg = 0; reg ARRAY_SIZE(tlv320aic23_reg); i++) {
+ for (reg = 0; reg TLV320AIC23_RESET; reg++) {
ARRAY_SIZE() shouldn't be preserved?
[Aggarwal, Anuj] No, since registers 0x0A - 0x0E are not present.
u16 val = tlv320aic23_read_reg_cache(codec, reg);
tlv320aic23_write(codec, reg, val);
}
--
--
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/2] OMAP3: MCBSP: Suspend/resume failure fix
Looking at the very original patch, I don't know how things could get into deep sleep by disabling the fclk only... need to disable the iclk also. In threshold mode, HW autogates the iclk, so you may be just lucky. [Anuj] No, I am not :(. I had to modify the original patch to include the disable part for the ICLK too. Without that, I was not able to hit retention. I will try to do some further regression on OMAP3 EVM and post my findings. As of now, audio is working fine with these patches + ICLK modification. [Aggarwal, Anuj] After further testing, I found that there is some problem in the capture path. While capturing in background, if I tried to do suspend, capture fails after a few seconds giving; arecord: pcm_read:1617: read error: Input/output error This I was discussing in another thread (*) for AIC23/AM3517 on NFS but now I realized after finishing my tests that this behavior is common for both omap3530/twl4030 and am3517/aic23. Moreover, the problem doesn't depend on the underlying file system - both NFS and ramdisk produce the same error. To make matter worse, if suspend/resume is tried while audio loopback is running, system just hangs. Even telnet to the evm doesn't work. So the audio capture path, from suspend/resume point of view, definitely needs some more time. I will continue debugging at my end. But pointers are always welcome. *) http://www.mail-archive.com/linux-omap@vger.kernel.org/msg19845.html One may want to be aware of this also: http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap- 2.6.git;a=commitdiff;h=72cc6d715d5b018e2cff4adb68966855850d4e77 I think it's an undocumented feature. -- 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/2] OMAP3: MCBSP: Suspend/resume failure fix
-Original Message- From: Aggarwal, Anuj Sent: Monday, November 30, 2009 5:21 PM To: ext-eero.nurkk...@nokia.com Cc: ext Jarkko Nikula; alsa-de...@alsa-project.org; Wang, Jane; broo...@opensource.wolfsonmicro.com; Ujfalusi Peter (Nokia-D/Tampere); linux-omap@vger.kernel.org Subject: RE: [alsa-devel] [PATCH 1/2] OMAP3: MCBSP: Suspend/resume failure fix Looking at the very original patch, I don't know how things could get into deep sleep by disabling the fclk only... need to disable the iclk also. In threshold mode, HW autogates the iclk, so you may be just lucky. [Anuj] No, I am not :(. I had to modify the original patch to include the disable part for the ICLK too. Without that, I was not able to hit retention. I will try to do some further regression on OMAP3 EVM and post my findings. As of now, audio is working fine with these patches + ICLK modification. [Aggarwal, Anuj] After further testing, I found that there is some problem in the capture path. While capturing in background, if I tried to do suspend, capture fails after a few seconds giving; arecord: pcm_read:1617: read error: Input/output error This I was discussing in another thread (*) for AIC23/AM3517 on NFS but now I realized after finishing my tests that this behavior is common for both omap3530/twl4030 and am3517/aic23. Moreover, the problem doesn't depend on the underlying file system - both NFS and ramdisk produce the same error. To make matter worse, if suspend/resume is tried while audio loopback is running, system just hangs. Even telnet to the evm doesn't work. So the audio capture path, from suspend/resume point of view, definitely needs some more time. I will continue debugging at my end. But pointers are always welcome. [Aggarwal, Anuj] I think I found one possible root cause of the hang which is observed if suspend/resume is tried while audio loopback is going on. soc_suspend() calls snd_pcm_suspend_all() which calls snd_pcm_suspend() for all the substreams in the pcm-streams[]. On debugging, I found that I am not able to come out of snd_pcm_suspend_all(). I think this API needs some fix as the comment also suggests: FIXME: the open/close code should lock this as well Could this be the root cause of this hang? Any pointers on what needs to be fixed? -- 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
Problems while designing TPS65023 regulator driver
Hi,
I am working on TPS65023 PMIC
(http://focus.ti.com/docs/prod/folders/print/tps65023.html) regulator driver.
It supports 3 step-down converters and 2 LDOs, all connected to the same I2C
device. I am facing some design related issues and need your opinion on the
same.
Since all the five regulators can be controlled using a single i2c device, I
made a single i2c_board_info structure in my platform specific file and put all
the regulator_init_data information there:
code starts
/* MPU voltage regulator of DCDC type */
struct regulator_consumer_supply tps65023_mpu_consumers = {
.supply = vdd1,
};
/* MMC voltage regulator of LDO type */
struct regulator_consumer_supply tps65023_mmc_consumers = {
.supply = mmc,
};
struct regulator_init_data tps_regulator_data[] = {
{
.constraints = {
.min_uV = 80,
.max_uV = 160,
.valid_ops_mask = (REGULATOR_CHANGE_VOLTAGE |
REGULATOR_CHANGE_STATUS),
},
.num_consumer_supplies = 1,
.consumer_supplies = tps65023_mpu_consumers,
},
.
.
.
{
.constraints = {
.min_uV = 105,
.max_uV = 330,
.valid_ops_mask = (REGULATOR_CHANGE_VOLTAGE |
REGULATOR_CHANGE_STATUS),
},
.num_consumer_supplies = 1,
.consumer_supplies = tps65023_mmc_consumers,
},
};
static struct i2c_board_info __initdata tps_65023_i2c_board_info[] = {
{
I2C_BOARD_INFO(tps65023, 0x48),
.flags = I2C_CLIENT_WAKE,
.platform_data = tps_regulator_data[0],
},
};
static int __init omap3_evm_i2c_init(void)
{
omap_register_i2c_bus(1, 400, tps_65023_i2c_board_info,
ARRAY_SIZE(tps_65023_i2c_board_info));
.
.
}
code ends
Now, in my regulator driver code, I am creating an array of the available
regulators, passing that array as driver_data in my i2c_device_id structure and
registering my i2c_driver using i2c_add_driver() during initialization, as
shown below:
code starts
#define TPS65023_NUM_DCDC 3
#define TPS65023_NUM_LDO2
#define TPS65023_NUM_REGULATOR (TPS65023_NUM_DCDC + TPS65023_NUM_LDO)
struct tps_info {
const char *name;
unsignedmin_uV;
unsignedmax_uV;
boolfixed;
u8 table_len;
const u16 *table;
};
struct tps {
struct regulator_desc desc[TPS65023_NUM_REGULATOR];
struct i2c_client *client;
struct regulator_dev*rdev[TPS65023_NUM_REGULATOR];
const struct tps_info *info[TPS65023_NUM_REGULATOR];
};
static const struct tps_info tps65023_regs[] = {
{
.name = VDCDC1,
.min_uV = 80,
.max_uV = 160,
.fixed = 0,
.table_len = ARRAY_SIZE(VDCDC1_VSEL_table),
.table = VDCDC1_VSEL_table,
},
.
.
.
{
.name = LDO2,
.min_uV = 100,
.max_uV = 315,
.fixed = 0,
.table_len = ARRAY_SIZE(LDO2_VSEL_table),
.table = LDO2_VSEL_table,
},
};
static const struct i2c_device_id tps_65023_id = {
.name = tps65023,
.driver_data = (unsigned long) tps65023_regs[0],
};
MODULE_DEVICE_TABLE(i2c, tps_65023_id);
static struct i2c_driver tps_65023_i2c_driver = {
.driver = {
.name = tps_65023_pwr,
.owner = THIS_MODULE,
},
.probe = tps_65023_probe,
.remove = __devexit_p(tps_65023_remove),
.id_table = tps_65023_id,
};
/**
* tps_65023_init
*
* Module init function
*/
static int __init tps_65023_init(void)
{
return i2c_add_driver(tps_65023_i2c_driver);
}
late_initcall(tps_65023_init);
code ends
Now, the problem is in the tps_65023_probe function. Since it will be called
only once as there is only one i2c device, I have to register all the
regulators in that only. But I am not able to communicate the same to the
regulator core layer. Inside the regulator_register(), variable init_data,
which equals to dev-platform_data, is always pointing to the first array
member, which is coming from the evm specific file. And it fails to register my
second regulator instance, set_consumer_device_supply() specifically failing
for the second iteration. Because of this, the probe function fails.
How should I handle this scenario? Am I missing something in my implementation?
Regards,
Anuj Aggarwal
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a
RE: Problems while designing TPS65023 regulator driver
Mark, Thanks for the patch, it worked fine for me. I am facing one more problem now. I am setting boot_on flag in the constraints structure for all my regulators as they are enabled when the system is powered on. But still when I call regulator_disable() after doing a _get() on it, the call fails saying unbalanced disables for supply. Then I checked the same repository again and found commit 38db9f31d6dc6147b87692b3b5a8a32de1a6cbe6 (regulator: Allow boot_on regulators to be disabled by clients). But still, it is not allowing me to disable the regulator as soon as I do a get on it. Later, I found out that in set_machine_constraints(),ops-enable() is being called if the boot_on flag is set. What is the purpose of doing this? Since the regulator is already enabled, why we are calling the ops-enable() to do the same again? In my opinion, regulator_enable() should have been called to let the framework increase its usage count so that the user can disable the same as and when required. Thanks and Regards, Anuj Aggarwal -Original Message- From: Mark Brown [mailto:broo...@sirena.org.uk] Sent: Thursday, February 26, 2009 7:35 PM To: Aggarwal, Anuj Cc: linux-omap@vger.kernel.org Subject: Re: Problems while designing TPS65023 regulator driver On Thu, Feb 26, 2009 at 02:41:54PM +0530, Aggarwal, Anuj wrote: Since all the five regulators can be controlled using a single i2c device, I made a single i2c_board_info structure in my platform specific file and put all the regulator_init_data information there: This is very common - most of the devices that have multiple regulators also have some other subsystems on them (eg, an RTC or a watchdog) and use a core driver in drivers/mfd with the individual functions of the device as child platform drivers so this hasn't come up much. Now, the problem is in the tps_65023_probe function. Since it will be called only once as there is only one i2c device, I have to register all the regulators in that only. But I am not able to communicate the same to the regulator core layer. Inside the regulator_register(), variable init_data, which equals to dev-platform_data, is always pointing to the first array member, which is coming from the evm specific file. And it fails to register my second regulator instance, set_consumer_device_supply() specifically failing for the second iteration. Because of this, the probe function fails. How should I handle this scenario? Am I missing something in my implementation? Use -next or the regulator git at: git://git.kernel.org/pub/scm/linux/kernel/git/lrg/voltage-2.6 There the init data is passed as a parameter to regulator_register() rather than being read from the platform data so the problem goes away. The relevant commit is 8ec143c801ff0514ce92e69aa2f7bd48e73b9baa. [Please fix your mail client to wrap at 80 columns - currently you have no line breaks in paragraphs which makes your mails a bit hard to read and reply to.] -- 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 5/9] AM3517: Add audio codec platform data
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Stanley.Miao
Sent: Monday, April 19, 2010 3:51 PM
To: linux-omap@vger.kernel.org
Cc: t...@atomide.com; Hiremath, Vaibhav; Govindarajan, Sriramakrishnan
Subject: [PATCH 5/9] AM3517: Add audio codec platform data
Codec tlv320aic23 is on the second i2c bus. Add the tlv320aic23 info in
i2c2 board_info.
Signed-off-by: Stanley.Miao stanley.m...@windriver.com
---
arch/arm/mach-omap2/board-am3517evm.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517evm.c b/arch/arm/mach-
omap2/board-am3517evm.c
index 41f766c..f24e367 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -199,6 +199,9 @@ static struct pca953x_platform_data
am3517evm_gpio_expander_info_0 = {
};
static struct i2c_board_info __initdata am3517evm_i2c2_boardinfo[] = {
{
+ I2C_BOARD_INFO(tlv320aic23, 0x1A),
+ },
+ {
I2C_BOARD_INFO(tca6416, 0x21),
.platform_data = am3517evm_gpio_expander_info_0,
},
[Aggarwal, Anuj] Similar patch exists at:
http://marc.info/?l=linux-omapm=125684238323749w=2
--
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/9] AM3517: Add platform init code for regulator driver
- S35390A
*/
@@ -103,6 +220,11 @@ static struct i2c_board_info __initdata
am3517evm_i2c3_boardinfo[] = {
I2C_BOARD_INFO(tca6416, 0x21),
.platform_data = am3517evm_ui_gpio_expander_info_2,
},
+ {
+ I2C_BOARD_INFO(tps65023, 0x48),
+ .flags = I2C_CLIENT_WAKE,
+ .platform_data = am3517_evm_regulator_data[0],
+ },
};
static int __init am3517_evm_i2c_init(void)
[Aggarwal, Anuj] I can see an exactly same patch at:
http://arago-project.org/git/projects/?p=linux-omap3.git;a=commit;h=4ff9cb47c50dc6df362702ad3ae69b70de098372
(Commit id 4ff9cb47c on
http://arago-project.org/git/projects/?p=linux-omap3.git)
Can you help me understand what changes you have done in this patch?
Please make sure that you give due credit to the original owner of
the patch on basis of which you are deriving/submitting your patches.
--
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: How to test regulator driver?
I am seriously confused on how to fetch the struct device * in my consumer driver, for an already registered regulator. I am planning to use this consumer driver as a part of my CPU freq/CPU idle framework but I don't know what to pass in regulator_get. Should I register my regulator device as a platform_device as against an i2c_client device what I am having now? Other regulator drivers (drivers/regulator/twl4030-regulator.c, wm8400.c etc) are doing the same thing in their code. Using the current approach, I am facing difficulty in getting the struct device * for invoking the regulator_get()? Otherwise, can I expose one function in my regulator driver which will return the appropriate struct device * when user calls it with a supply name string? This device pointer then will be used in my consumer driver while calling the regulator_get API? Thanks and Regards, Anuj Aggarwal Platform Support Products Texas Instruments Inc Ph: +91-80-2509-9542 TI IP Ph: 509-9542 PSP Products RSS Feed PSP Product Announcements -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Mark Brown Sent: Monday, March 09, 2009 9:03 PM To: Anuj Aggarwal Cc: Linux OMAP List Subject: Re: How to test regulator driver? On Mon, Mar 09, 2009 at 08:32:55PM +0530, Anuj Aggarwal wrote: I want to test my regulator driver by writing a small kernel module. But I am a little confused as what should be passed as the first argument of regulator_get(). How would the kernel module know about the device pointer that needs to be passed to the _get function? regulator_get() takes the struct device for the consumer as an argument so it depends on what your consumer is. For test purposes there's an existing virtual consumer driver in the tree which should hopefully save you having to write your own - it allows you to poke the settings from sysfs. drivers/regulator/virtual.c Questions like this that aren't OMAP-specific should really be asked on the relevant general list (in this case linux-kernel). -- 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 -- 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 for supporting multiple PMICs
All,
Based on our understanding/experiences till so far, we suggest the
following:
a) Remove all the PMIC-board related stuff from the EVM specific file (
like board-omap3evm.c) and keep it in a separate file (board-omap3evm-
pmic.c). All platform related Inits should be done here.
b) PMIC initialization and other PMIC specific routines (enable/disable,
get/set voltage/current) should be done in the PMIC specific file like
drivers/regulator/pmic.c
c) Probing for PMIC during runtime could be done in either of the ways
specified in the attached sample template.
d) Generic wrappers should be provided to have a consistent interface
for accessing PMIC registers and to use its supported features.
Please find attached the sample implementation of the things mentioned
above and provide your feedback.
Thanks and Regards,
Anuj Aggarwal
Platform Support Products
Texas Instruments Incorporated
/*
* linux/arch/arm/mach-omap2/board-omap3evm-pmic.c
*
* Copyright (C) 2009 Texas Instruments Incorporated
*
* tbd copyright
*/
#include linux/kernel.h
#include linux/init.h
#include linux/platform_device.h
#include linux/i2c/twl4030.h
#include linux/i2c/tps6535x.h
/* --- other generic headers --- */
/*
*
* If we are okay with controlled ifdef in this file then we can follow
* the scheme below...
*
*/
#ifdef CONFIG_TWL4030_CORE
/*
* Definitions specific to TWL4030
*/
#endif /* CONFIG_TWL4030_CORE */
#ifdef CONFIG_PMIC_TPS62350
/*
* Definitions specific to TPS62350
*/
#endif /* CONFIG_PMIC_TPS62350 */
#ifdef CONFIG_PMIC_TPS65023
/*
* Definitions specific to TPS65023
*/
#endif /* CONFIG_PMIC_TPS65023 */
int omap3_evm_pmic_init()
{
#ifdef CONFIG_TWL4030_CORE
/* do stuff specific to TWL4030 */
#elif CONFIG_PMIC_TPS62350
/* do stuff specific to TPS62350 */
#elif CONFIG_PMIC_TPS65023
/* do stuff specific to TPS65023 */
#endif
}
/* =
*
* If we would like to run same image on multiple OMAP3EVMs and don't really
* care about the image size, then we can follow the scheme below...
*
* Though there is still an open question of how to detect PMIC at runtime?
* =
*/
/*
* Definitions specific to TWL4030
*/
/*
* Definitions specific to TPS62350
*/
/*
* Definitions specific to TPS65023
*/
static int flag_pmic_twl4030 = 0;
static int flag_pmic_tps6235x = 0;
static int flag_pmic_tps65023 = 0;
/*
* Detect the current PMIC
* Set one of the flags
*/
static inline int detect_pmic()
{
/* How? Any suggestions?? */
}
static inline int use_pmic_twl4030()
{
return flag_pmic_twl4030;
}
static inline int use_pmic_tps6235x()
{
return flag_pmic_tps6235x;
}
static inline int use_pmic_tps65023()
{
return flag_pmic_tps65023;
}
int omap3_evm_pmic_init()
{
if (use_pmic_twl4030())
{
/* do stuff specific to TWL4030 */
}
else if (use_pmic_tps6235x())
{
/* do stuff specific to TPS62350 */
}
else if (use_pmic_tps65023())
{
/* do stuff specific to TPS65023 */
}
}
/*
*
* Generic wrappers to access PMIC registers and use its supported features...
*
*/
int omap3_pmic_i2c_read()
{
/* Approach 1 */
#ifdef CONFIG_TWL4030_CORE
/* do stuff specific to TWL4030 */
#elif CONFIG_PMIC_TPS62350
/* do stuff specific to TPS62350 */
#elif CONFIG_PMIC_TPS65023
/* do stuff specific to TPS65023 */
#endif
/* Approach 2 */
if (use_pmic_twl4030())
{
/* do stuff specific to TWL4030 */
}
else if (use_pmic_tps6235x())
{
/* do stuff specific to TPS62350 */
}
else if (use_pmic_tps65023())
{
/* do stuff specific to TPS65023 */
}
}
int omap3_pmic_i2c_write()
{
/* just for illustration */
}
int omap3_evm_enable_lcd()
{
/* just for illustration */
}
int omap3_evm_disable_lcd()
{
/* just for illustration */
}
int omap3_evm_enable_dvi()
{
/* just for illustration */
}
int omap3_evm_disable_dvi()
{
/* just for illustration */
}
int omap3_evm_enable_tv()
{
/* just for illustration */
}
int omap3_evm_disable_tv()
{
/* just for illustration */
}
RE: Problems while designing TPS65023 regulator driver
Trilok, Since the new regulator_register API was not there in l-o, I have not submitted my patch for TPS65023. But since now it is available, I will submit my patch soon. Thanks and Regards, Anuj Aggarwal Platform Support Products Texas Instruments Incorporated PSP Products RSS Feed -Original Message- From: Trilok Soni [mailto:soni.tri...@gmail.com] Sent: Friday, April 24, 2009 11:32 AM To: David Brownell Cc: Aggarwal, Anuj; Mark Brown; linux-omap@vger.kernel.org; Tony Lindgren Subject: Re: Problems while designing TPS65023 regulator driver Hi David, On Fri, Apr 24, 2009 at 3:47 AM, David Brownell davi...@pacbell.net wrote: On Thursday 23 April 2009, Trilok Soni wrote: Any updates on tps65023 regulator driver? Could you please submit the WIP patches to the list? FWIW, here's the last version I saw ... it includes a build hack for the regulator_register() call. I haven't build-tested it since that API change went to mainline. From: Manikandan Pillai mani.pil...@ti.com Subject: regulator: add support for TPS6235x The patch has been fixed for comments given by David Brownell and Mark Brown for adding TPS6235x support on OMAP3 EVM. Comments fixed include moving Makefile changes to this patch dev_err used removed the extra configuration option from Kconfig Thanks but I was requesting tps 6 5 0 2 3 not tps 6 2 3 5 x :). -- ---Trilok Soni http://triloksoni.wordpress.com http://www.linkedin.com/in/triloksoni -- 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: Problems while designing TPS65023 regulator driver
As you know, some regulator patches were required in linux-OMAP tree to submit the TPS65023 patch, in absence of which it won't have compiled. Since they are available now, I can submit them after doing a refresh. Moreover, we are working on some restructuring for the different TPS devices so that the board-dependent code can be separated from the rest of the stuff. It should be closed soon and then the new patches would be submitted for review, for both the TPS devices. Thanks and Regards, Anuj Aggarwal Thanks and Regards, Anuj Aggarwal Platform Support Products Texas Instruments Incorporated PSP Products RSS Feed -Original Message- From: David Brownell [mailto:davi...@pacbell.net] Sent: Friday, April 24, 2009 12:03 PM To: Trilok Soni Cc: Aggarwal, Anuj; Mark Brown; linux-omap@vger.kernel.org; Tony Lindgren Subject: Re: Problems while designing TPS65023 regulator driver On Thursday 23 April 2009, Trilok Soni wrote: Thanks but I was requesting tps 6 5 0 2 3 not tps 6 2 3 5 x :). Sorry ... maybe they'll help some other time. :) I was wondering what happened to the tps6235x drivers, which seemed to have gotten lost. I don't recall having seen tps65023 code. -- 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 for supporting multiple PMICs
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Wednesday, April 22, 2009 2:00 AM
To: Aggarwal, Anuj
Cc: linux-omap@vger.kernel.org; Premi, Sanjeev; Pillai, Manikandan
Subject: Re: RFC for supporting multiple PMICs
* Aggarwal, Anuj anuj.aggar...@ti.com [090420 10:52]:
All,
Based on our understanding/experiences till so far, we suggest the
following:
a) Remove all the PMIC-board related stuff from the EVM specific file (
like board-omap3evm.c) and keep it in a separate file (board-omap3evm-
pmic.c). All platform related Inits should be done here.
b) PMIC initialization and other PMIC specific routines (enable/disable,
get/set voltage/current) should be done in the PMIC specific file like
drivers/regulator/pmic.c
c) Probing for PMIC during runtime could be done in either of the ways
specified in the attached sample template.
d) Generic wrappers should be provided to have a consistent interface
for accessing PMIC registers and to use its supported features.
Please find attached the sample implementation of the things mentioned
above and provide your feedback.
To me it sounds like the regulator fwk should be able to take care of
most of these issues, see what David Brownell did with the twl4030 driver.
If the same board has different PMIC options, you should be able to compile
them all in, and then probe for the connected PMIC.
So you could have something like this in your board-*.c file:
[Aggarwal, Anuj] These PMICs can be used beyond OMAP as well. Hence,
I was proposing a generic file - instead of tying with board-*.c file(s).
But, if we want to keep the changes specific to OMAP3 only, then we can
still create a generic pmic.c|h file in mach-omap2 to consolidate all PMIC
related functions.
Otherwise, we can leave status quo.
#ifdef CONFIG_TWL4030_CORE
static struct regulator_init_data twl4030_vaux1 = {
...
};
static int __init pmic_twl4030_init(void)
{
/* Initialize things here */
}
#else
#define twl4030_vaux1 NULL
static inline int pmic_twl4030_init(void)
{
}
#endif
#ifdef CONFIG_SOME_OTHER_PMIC
static struct regulator_init_data some_other_pmic_vaux1 = {
...
};
static int __init pmic_some_other_init(void)
{
/* Initialize things here */
}
#else
#define some_other_pmic_vaux1 NULL
static inline int pmic_some_other_init(void)
#endif
...
Then just call all the PMIC inits in your board init, or later if
needed for I2C probing of the chips.
[Aggarwal, Anuj] Same pmic.c file will also have one pmic_init()
which will detect the PMIC present and initialize it appropriately.
It will be called by omap3_evm_init() or any other evm-init
function.
Regards,
Tony
Thanks and Regards,
Anuj Aggarwal
Platform Support Products
Texas Instruments Incorporated
Content-Description: board-omap3evm-pmic.c
/*
* linux/arch/arm/mach-omap2/board-omap3evm-pmic.c
*
* Copyright (C) 2009 Texas Instruments Incorporated
*
* tbd copyright
*/
#include linux/kernel.h
#include linux/init.h
#include linux/platform_device.h
#include linux/i2c/twl4030.h
#include linux/i2c/tps6535x.h
/* --- other generic headers --- */
/*
*
* If we are okay with controlled ifdef in this file then we can follow
* the scheme below...
*
*/
#ifdef CONFIG_TWL4030_CORE
/*
* Definitions specific to TWL4030
*/
#endif /* CONFIG_TWL4030_CORE */
#ifdef CONFIG_PMIC_TPS62350
/*
* Definitions specific to TPS62350
*/
#endif /* CONFIG_PMIC_TPS62350 */
#ifdef CONFIG_PMIC_TPS65023
/*
* Definitions specific to TPS65023
*/
#endif /* CONFIG_PMIC_TPS65023 */
int omap3_evm_pmic_init()
{
#ifdef CONFIG_TWL4030_CORE
/* do stuff specific to TWL4030 */
#elif CONFIG_PMIC_TPS62350
/* do stuff specific to TPS62350 */
#elif CONFIG_PMIC_TPS65023
/* do stuff specific to TPS65023 */
#endif
}
/*
=
*
* If we would like to run same image on multiple OMAP3EVMs and don't
really
* care about the image size, then we can follow the scheme below...
*
* Though there is still an open question of how to detect PMIC at runtime?
*
=
*/
/*
* Definitions specific to TWL4030
*/
/*
* Definitions specific to TPS62350
*/
/*
* Definitions specific to TPS65023
*/
static int flag_pmic_twl4030 = 0;
static int flag_pmic_tps6235x = 0;
static int flag_pmic_tps65023 = 0;
/*
* Detect the current PMIC
* Set one of the flags
*/
static inline int detect_pmic()
{
/* How? Any suggestions?? */
}
static inline int use_pmic_twl4030()
{
return flag_pmic_twl4030;
}
static inline int use_pmic_tps6235x()
{
return
RE: [RFC] [Patch 0/2] Proposal for changes to TWL4030/TWL5030 framework for integrating the new TWL6030 chip
Jagadeesh,
We are also working on similar lines and I have already sent a RFC to
discuss it further in the community. Please have a look at the below
link and provide your comments:
http://marc.info/?l=linux-omapm=124083364321017w=2
Regards,
Anuj Aggarwal
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Pakaravoor, Jagadeesh
Sent: Tuesday, April 28, 2009 2:42 PM
To: felipe.ba...@nokia.com
Cc: linux-omap@vger.kernel.org
Subject: RE: [RFC] [Patch 0/2] Proposal for changes to TWL4030/TWL5030
framework for integrating the new TWL6030 chip
- if (twl_has_keypad() pdata-keypad) {
+ if (twl_has_keypad() pdata-keypad
+ !(features TLW6030)) {
child = add_child(2, twl4030_keypad,
pdata-keypad, sizeof(*pdata-keypad),
true, pdata-irq_base + 1, 0);
You'd probably only need to make changes to register defines but almost
everything else could remain as is. There shouldn't be any need for
creating separate files.
Patch 0, of the series explains the differences between TWL4030 and TWL6030.
Going the aforesaid way, we will need checks like this in almost every other
line of code. And I believe having a separate file would be more modular, and
hence readable (a twl.c which will bind with twl4030-core.c and twl4030-irq.c
if
TWL4030 is selected, and twl6030-core.c and twl6030-irq.c if TWL6030 is
selected).
I am not sure how we can incorporate all the hardware changes by just
changing register addresses.
--
Jagadeesh
--
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
--
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
Beep sound in the end of audio file
Hi, After playing out any audio file on OMAP3 EVM, having TWL4030 codec, I am hearing a beep sound. I have also tried implementing a mute function in which I disabled all the inputs/outputs but still that didn't help. Any idea how this can be avoided? Thanks and Regards, Anuj Aggarwal Platform Support Products Texas Instruments Incorporated -- 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: Beep sound in the end of audio file
-Original Message- From: Peter Ujfalusi [mailto:peter.ujfal...@nokia.com] Sent: Wednesday, May 06, 2009 11:03 AM To: Aggarwal, Anuj Cc: linux-omap@vger.kernel.org; alsa-de...@alsa-project.org Subject: Re: Beep sound in the end of audio file Hello, On Tuesday 05 May 2009 20:03:57 ext Aggarwal, Anuj wrote: Hi, After playing out any audio file on OMAP3 EVM, having TWL4030 codec, I am hearing a beep sound. I have also tried implementing a mute function in which I disabled all the inputs/outputs but still that didn't help. Any idea how this can be avoided? I have not heard from this kind of problem so far, which does not mean, that it does not exist ;) Can you describe the beep sound? [Aggarwal, Anuj] It's kind of a tuck sound coming in the end, after 1 or 2 seconds. After a quick look I can not pin point the soc board file used with the omap3evm board. Is it in the tree? [Aggarwal, Anuj] No, it is not. Reason being we already have beagle sdp3430 there, which are both similar to omap3evm, which I pushed. So mine got rejected. We had some discussions on how to handle this scenario but nothing got finalized. Does the beep happens in these cases also (after stopping it with Ctrl+C): aplay -f dat /dev/zero aplay -f dat /dev/urandom [Aggarwal, Anuj] Yes, it comes in both the cases. CC-ing alsa-devel... Thanks and Regards, Anuj Aggarwal Platform Support Products Texas Instruments Incorporated -- Péter -- 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] Beep sound in the end of audio file
-Original Message- From: Peter Ujfalusi [mailto:peter.ujfal...@nokia.com] Sent: Thursday, May 07, 2009 4:38 PM To: alsa-de...@alsa-project.org Cc: todd.fisc...@ridgerun.com; Aggarwal, Anuj; linux-omap@vger.kernel.org Subject: Re: [alsa-devel] Beep sound in the end of audio file On Thursday 07 May 2009 08:48:25 Ujfalusi Peter (Nokia-D/Tampere) wrote: On Wednesday 06 May 2009 17:19:49 ext Todd Fischer wrote: Hi, FWIW: while developing a GSTreamer presentation using a BegleBoard (rev C), I noticed the same tuck sound. It also occurs a second or two after the GST application exits. I assumed it was some power management code that was disabling the audio codec after it had gone idle, but never looked into it. BeagleBoard also uses TWL4030. GST command: gst-launch audiotestsrc freq=1000 num-buffers=100 ! alsasink /proc/version: Linux version 2.6.28-omap1 (ddo...@aleph) (gcc version 4.3.1 (GCC) ) #2 Thu Mar 5 08:55:58 CST 2009 The tuck is coming from the codec, when it is powered down (in the old twl4030 codec found in omap-2.6.28 branch of linux-omap). But, it still happens with the latest version, when the codec is muted only. I can observe the tuck on Headset output, but not on the PreDrive... The Headset enable and disable is implemented according to the TRM, but it seams that additional tweaking is needed.. I need to revisit this... After more testing and debugging, it seams that I can not confirm the existence of the tuck (with the latest twl4030 codec code). As soon as I receive my Beagle board I will test it again (can anyone test this with latest ASoC code on Beagle?)... [Anuj]: What kernel are you using where you have the beep? [Aggarwal, Anuj] 2.6.29-rc3 -- Péter -- 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/1] ASoC: Added OMAP3 EVM support in ASoC.
-Original Message-
From: Arun KS [mailto:getaru...@gmail.com]
Sent: Friday, May 08, 2009 10:13 AM
To: Aggarwal, Anuj
Cc: alsa-de...@alsa-project.org; linux-omap@vger.kernel.org
Subject: Re: [PATCH 1/1] ASoC: Added OMAP3 EVM support in ASoC.
On Thu, May 7, 2009 at 9:38 PM, Anuj Aggarwal anuj.aggar...@ti.com
wrote:
Signed-off-by: Anuj Aggarwal anuj.aggar...@ti.com
---
sound/soc/omap/Kconfig | 8 +++
sound/soc/omap/Makefile | 2 +
sound/soc/omap/omap3evm.c | 147
+
3 files changed, 157 insertions(+), 0 deletions(-)
create mode 100644 sound/soc/omap/omap3evm.c
diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig
index 675732e..b771238 100644
--- a/sound/soc/omap/Kconfig
+++ b/sound/soc/omap/Kconfig
@@ -39,6 +39,14 @@ config SND_OMAP_SOC_OMAP2EVM
help
Say Y if you want to add support for SoC audio on the omap2evm
board.
+config SND_OMAP_SOC_OMAP3EVM
+ tristate SoC Audio support for OMAP3EVM board
+ depends on TWL4030_CORE SND_OMAP_SOC
MACH_OMAP3EVM
+ select SND_OMAP_SOC_MCBSP
+ select SND_SOC_TWL4030
+ help
+ Say Y if you want to add support for SoC audio on the omap3evm
board.
+
config SND_OMAP_SOC_SDP3430
tristate SoC Audio support for Texas Instruments SDP3430
depends on TWL4030_CORE SND_OMAP_SOC
MACH_OMAP_3430SDP
diff --git a/sound/soc/omap/Makefile b/sound/soc/omap/Makefile
index 0c9e4ac..a37f498 100644
--- a/sound/soc/omap/Makefile
+++ b/sound/soc/omap/Makefile
@@ -10,6 +10,7 @@ snd-soc-n810-objs := n810.o
snd-soc-osk5912-objs := osk5912.o
snd-soc-overo-objs := overo.o
snd-soc-omap2evm-objs := omap2evm.o
+snd-soc-omap3evm-objs := omap3evm.o
snd-soc-sdp3430-objs := sdp3430.o
snd-soc-omap3pandora-objs := omap3pandora.o
snd-soc-omap3beagle-objs := omap3beagle.o
@@ -18,6 +19,7 @@ obj-$(CONFIG_SND_OMAP_SOC_N810) += snd-soc-
n810.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_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
diff --git a/sound/soc/omap/omap3evm.c b/sound/soc/omap/omap3evm.c
new file mode 100644
index 000..2af5d93
--- /dev/null
+++ b/sound/soc/omap/omap3evm.c
@@ -0,0 +1,147 @@
+/*
+ * omap3evm.c -- ALSA SoC support for OMAP3 EVM
+ *
+ * Author: Anuj Aggarwal anuj.aggar...@ti.com
+ *
+ * Based on sound/soc/omap/beagle.c by Steve Sakoman
+ *
+ * Copyright (C) 2008 Texas Instruments, Incorporated
+ *
+ * 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/clk.h
+#include linux/platform_device.h
+#include sound/core.h
+#include sound/pcm.h
+#include sound/soc.h
+#include sound/soc-dapm.h
+
+#include asm/mach-types.h
+#include mach/hardware.h
+#include mach/gpio.h
+#include mach/mcbsp.h
+
+#include omap-mcbsp.h
+#include omap-pcm.h
+#include ../codecs/twl4030.h
+
+static int omap3evm_hw_params(struct snd_pcm_substream *substream,
+ struct snd_pcm_hw_params *params)
+{
+ struct snd_soc_pcm_runtime *rtd = substream-private_data;
+ struct snd_soc_dai *codec_dai = rtd-dai-codec_dai;
+ struct snd_soc_dai *cpu_dai = rtd-dai-cpu_dai;
+ int ret;
+
+ /* Set codec DAI configuration */
+ ret = snd_soc_dai_set_fmt(codec_dai,
+ SND_SOC_DAIFMT_I2S |
+ SND_SOC_DAIFMT_NB_NF |
+ SND_SOC_DAIFMT_CBM_CFM);
+ if (ret 0) {
+ printk(KERN_ERR Can't set codec DAI configuration\n);
+ return ret;
+ }
+
+ /* Set cpu DAI configuration */
+ ret = snd_soc_dai_set_fmt(cpu_dai,
+ SND_SOC_DAIFMT_I2S |
+ SND_SOC_DAIFMT_NB_NF |
+ SND_SOC_DAIFMT_CBM_CFM);
+ if (ret 0) {
+ printk(KERN_ERR Can't set cpu DAI configuration\n);
+ return ret;
+ }
+
+ /* Set the codec system clock for DAC and ADC */
+ ret = snd_soc_dai_set_sysclk(codec_dai, 0, 2600
RE: [PATCH 3/3] Regulator: Added board-dependent code for TPS65023
-Original Message-
From: Mark Brown [mailto:broo...@sirena.org.uk]
Sent: Saturday, May 09, 2009 1:45 AM
To: Aggarwal, Anuj
Cc: linux-omap@vger.kernel.org; l...@slimlogic.co.uk
Subject: Re: [PATCH 3/3] Regulator: Added board-dependent code for
TPS65023
On Fri, May 08, 2009 at 08:42:16PM +0530, Anuj Aggarwal wrote:
Added OMAP3 EVM specific code for TPS65023 in pmic.c file.
Signed-off-by: Anuj Aggarwal anuj.aggar...@ti.com
CCing in Liam again.
---
drivers/regulator/pmic.c | 92
++
1 files changed, 92 insertions(+), 0 deletions(-)
diff --git a/drivers/regulator/pmic.c b/drivers/regulator/pmic.c
index 36ed341..6e7276a 100644
--- a/drivers/regulator/pmic.c
+++ b/drivers/regulator/pmic.c
@@ -29,6 +29,96 @@
/*
* Definitions specific to TPS65023
*/
+#if defined(CONFIG_OMAP3EVM_TPS65023)
+/* MPU voltage regulator of DCDC type */
+struct regulator_consumer_supply tps65023_mpu_consumers = {
+ .supply = vdd1,
+};
This comes back to my questions about pmic.c but I'd expect this all to
appear in the OMAP3 EVM code.
[Aggarwal, Anuj] Same reason given in my other email. Just to avoid duplication
of the code, I have created this file and moved all the code from board-*.c to
this place.
The same file will be populated for other PMICs, coming on OMAP based platforms
in future.
+
+/* CORE voltage regulator of DCDC type */
+struct regulator_consumer_supply tps65023_core_consumers = {
+ .supply = vdd2,
+};
+
+/* SRAM/MEM/WKUP_BG voltage regulator of DCDC type */
+struct regulator_consumer_supply tps65023_vdds_consumers = {
+ .supply = vdds,
+};
+
+/* DPLL voltage regulator of LDO type */
+struct regulator_consumer_supply tps65023_dpll_consumers = {
+ .supply = dpll,
+};
+
+/* MMC voltage regulator of LDO type */
+struct regulator_consumer_supply tps65023_mmc_consumers = {
+ .supply = mmc,
+};
+
+struct regulator_init_data tps65023_regulator_data[] = {
+ {
+ .constraints = {
+ .min_uV = 80,
+ .max_uV = 160,
+ .valid_ops_mask = (REGULATOR_CHANGE_VOLTAGE |
+ REGULATOR_CHANGE_STATUS),
+ .boot_on = 1,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = tps65023_mpu_consumers,
+ },
+ {
+ .constraints = {
+ .min_uV = 180,
+ .max_uV = 330,
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ .boot_on = 1,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = tps65023_core_consumers,
+ },
+ {
+ .constraints = {
+ .min_uV = 180,
+ .max_uV = 330,
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ .boot_on = 1,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = tps65023_vdds_consumers,
+ },
+ {
+ .constraints = {
+ .min_uV = 100,
+ .max_uV = 315,
+ .valid_ops_mask = (REGULATOR_CHANGE_VOLTAGE |
+ REGULATOR_CHANGE_STATUS),
+ .boot_on = 1,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = tps65023_dpll_consumers,
+ },
+ {
+ .constraints = {
+ .min_uV = 105,
+ .max_uV = 330,
+ .valid_ops_mask = (REGULATOR_CHANGE_VOLTAGE |
+ REGULATOR_CHANGE_STATUS),
+ .boot_on = 1,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = tps65023_mmc_consumers,
+ },
+};
+
+static struct i2c_board_info __initdata board_tps65023_instances[] = {
+ {
+ I2C_BOARD_INFO(tps65023, 0x48),
+ .flags = I2C_CLIENT_WAKE,
+ .platform_data = tps65023_regulator_data[0],
+ },
+};
+#endif
static int flag_pmic_twl4030;
static int flag_pmic_tps6235x;
@@ -96,6 +186,8 @@ int pmic_init(void)
#if defined(CONFIG_OMAP3EVM_TPS65023)
/* do stuff specific to TPS65023 */
+ omap_register_i2c_bus(1, 400, board_tps65023_instances,
+ ARRAY_SIZE(board_tps65023_instances));
#endif
return 0;
--
1.6.2.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
--
You grabbed my hand and we fell into it, like a daydream - or a fever.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord
Audio capture not working with AIC23/McBSP1 on OMAP3517
Hi, I am trying to capture audio through LineIn on my OMAP3517 EVM, using AIC23 codec and McBSP1, and getting the following error: arecord: pcm_read:1529: read error: Input/output error Playback is working fine using the same combination. I have tried using another instance of AIC23 codec which uses McBSP2 and both playback capture works fine there. Has anyone faced this issue before? Any suggestions? Regards, Anuj Aggarwal -- 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] Audio capture not working with AIC23/McBSP1 on OMAP3517
-Original Message- From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com] Sent: Wednesday, August 26, 2009 6:34 PM To: Aggarwal, Anuj Cc: linux-omap@vger.kernel.org; alsa-de...@alsa-project.org Subject: Re: [alsa-devel] Audio capture not working with AIC23/McBSP1 on OMAP3517 On Wed, Aug 26, 2009 at 06:30:52PM +0530, Aggarwal, Anuj wrote: I am trying to capture audio through LineIn on my OMAP3517 EVM, using AIC23 codec and McBSP1, and getting the following error: arecord: pcm_read:1529: read error: Input/output error That suggests that DMA isn't happening - might be worth checking to see that clocks are being generated properly. I am able to see the bit clock and frame sync coming properly. Playback is working fine using the same combination. I have tried using another instance of AIC23 codec which uses McBSP2 and both playback capture works fine there. Has anyone faced this issue before? Any suggestions? Which kernel are you using? There are rather a lot of McBSP changes queued up for 2.6.32. If this ever worked in the past a git bisect might be interesting. I am on 2.6.31-rc5. I have to check whether the new patches fix anything related to this. -- 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] Audio capture not working with AIC23/McBSP1 on OMAP3517
Thanks Jarkko, the patch works for me.
I will be submitting my ASoC omap*.c file soon after making all
the necessary changes.
Regards,
Anuj Aggarwal
-Original Message-
From: Jarkko Nikula [mailto:jhnik...@gmail.com]
Sent: Wednesday, August 26, 2009 8:32 PM
To: Aggarwal, Anuj
Cc: Mark Brown; alsa-de...@alsa-project.org; linux-omap@vger.kernel.org
Subject: Re: [alsa-devel] Audio capture not working with AIC23/McBSP1 on
OMAP3517
On Wed, 26 Aug 2009 16:42:39 +0300
Jarkko Nikula jhnik...@gmail.com wrote:
Those recent patches should not any effect into this since they are
mostly playing with the McBSP and DMA interfacing. What comes to my
mind if muxing is correct and if codec is master, this might be related
to those McBSP1 FSR and CLKR setup.
Anuj: I think the issue is here that by default McBSP1 receiver is
using the CLKR and FSR pins and if those are not connected, then the
capture doesn't work. Can you try a patch below and add following lines
into your machine driver?
snd_soc_dai_set_sysclk(cpu_dai, OMAP_MCBSP_CLKR_SRC_CLKX, 0,
SND_SOC_CLOCK_IN);
snd_soc_dai_set_sysclk(cpu_dai, OMAP_MCBSP_FSR_SRC_FSX, 0,
SND_SOC_CLOCK_IN);
Patch is compile tested only, generated against mainline 2.6.31-rc7 but
should
apply to ALSA tree as well.
--
Jarkko
CUT HERE
From: Jarkko Nikula jhnik...@gmail.com
Subject: [PATCH] ASoC: OMAP: Add functionality to set CLKR and FSR sources
in McBSP DAI
The McBSP1 port in OMAP3 processors (I believe OMAP2 too but I don't have
specifications to check it) have additional CLKR and FSR pins for McBSP1
receiver. Reset default is that receiver is using bit clock and frame
sync signal from those pins but it is possible to configure to use
also CLKX and FSX pins as well. In fact, other McBSP ports are doing that
internally that transmitter and receiver share the CLKX and FSX.
Add functionaly that machine drivers can set the CLKR and FSR sources by
using the snd_soc_dai_set_sysclk.
Thanks to Aggarwal, Anuj anuj.aggar...@ti.com for reporting the issue.
Signed-off-by: Jarkko Nikula jhnik...@gmail.com
---
sound/soc/omap/omap-mcbsp.c | 41
+
sound/soc/omap/omap-mcbsp.h |4
2 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index a5d46a7..2ea2136 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -462,6 +462,40 @@ static int omap_mcbsp_dai_set_clks_src(struct
omap_mcbsp_data *mcbsp_data,
return 0;
}
+static int omap_mcbsp_dai_set_rcvr_src(struct omap_mcbsp_data
*mcbsp_data,
+int clk_id)
+{
+ int sel_bit, set = 0;
+ u16 reg = OMAP2_CONTROL_DEVCONF0;
+
+ if (cpu_class_is_omap1())
+ return -EINVAL; /* TODO: Can this be implemented for OMAP1? */
+ if (mcbsp_data-bus_id != 0)
+ return -EINVAL;
+
+ switch (clk_id) {
+ case OMAP_MCBSP_CLKR_SRC_CLKX:
+ set = 1;
+ case OMAP_MCBSP_CLKR_SRC_CLKR:
+ sel_bit = 3;
+ break;
+ case OMAP_MCBSP_FSR_SRC_FSX:
+ set = 1;
+ case OMAP_MCBSP_FSR_SRC_FSR:
+ sel_bit = 4;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ if (set)
+ omap_ctrl_writel(omap_ctrl_readl(reg) | (1 sel_bit), reg);
+ else
+ omap_ctrl_writel(omap_ctrl_readl(reg) ~(1 sel_bit), reg);
+
+ return 0;
+}
+
static int omap_mcbsp_dai_set_dai_sysclk(struct snd_soc_dai *cpu_dai,
int clk_id, unsigned int freq,
int dir)
@@ -484,6 +518,13 @@ static int omap_mcbsp_dai_set_dai_sysclk(struct
snd_soc_dai *cpu_dai,
case OMAP_MCBSP_SYSCLK_CLKR_EXT:
regs-pcr0 |= SCLKME;
break;
+
+ case OMAP_MCBSP_CLKR_SRC_CLKR:
+ case OMAP_MCBSP_CLKR_SRC_CLKX:
+ case OMAP_MCBSP_FSR_SRC_FSR:
+ case OMAP_MCBSP_FSR_SRC_FSX:
+ err = omap_mcbsp_dai_set_rcvr_src(mcbsp_data, clk_id);
+ break;
default:
err = -ENODEV;
}
diff --git a/sound/soc/omap/omap-mcbsp.h b/sound/soc/omap/omap-mcbsp.h
index c8147aa..647d2f9 100644
--- a/sound/soc/omap/omap-mcbsp.h
+++ b/sound/soc/omap/omap-mcbsp.h
@@ -32,6 +32,10 @@ enum omap_mcbsp_clksrg_clk {
OMAP_MCBSP_SYSCLK_CLK, /* Internal ICLK */
OMAP_MCBSP_SYSCLK_CLKX_EXT, /* External CLKX pin */
OMAP_MCBSP_SYSCLK_CLKR_EXT, /* External CLKR pin */
+ OMAP_MCBSP_CLKR_SRC_CLKR, /* CLKR from CLKR pin */
+ OMAP_MCBSP_CLKR_SRC_CLKX, /* CLKR from CLKX pin */
+ OMAP_MCBSP_FSR_SRC_FSR, /* FSR from FSR pin */
+ OMAP_MCBSP_FSR_SRC_FSX, /* FSR from FSX pin */
};
/* McBSP dividers */
--
1.6.3.3
OSS emulation broken
Hi I tried playing a .mp3 file using madplay utility in ASoC-OSS emulation. But it didn't work properly. I am able to hear something but the configuration seems incorrect. Has anyone tried the OSS emulation layer in ASoC? I am at 382af94eb4 (Revert omap850: Use ck_ref clock for omap850.). Regards, Anuj Aggarwal -- 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
