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 4/9] AM3517: Add platform init code for regulator driver
s,
> + },
> + /* LDO2 */
> + {
> + .constraints = {
> + .min_uV = 330,
> + .max_uV = 330,
> + .valid_modes_mask = REGULATOR_MODE_NORMAL,
> + .valid_ops_mask = REGULATOR_CHANGE_STATUS,
> + .always_on = false,
> + .apply_uV = false,
> + },
> + .num_consumer_supplies = ARRAY_SIZE(am3517_evm_ldo2_supplies),
> + .consumer_supplies = am3517_evm_ldo2_supplies,
> + },
> +};
> +
> /*
> * RTC - 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: [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
> ---
> 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-omap&m=125684238323749&w=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: [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 > 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 > > --- > > 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: [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 [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: [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 > > Acked-by: Mark Brown 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: [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: [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 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
> -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 > > 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: [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: [PATCHv2 0/4] Regulator: OMAP: Removing common code for TWL4030 from OMAP3- board-evms
Any comments on this version? Regards, Anuj Aggarwal > -Original Message- > From: Aggarwal, Anuj > Sent: Tuesday, January 12, 2010 2:44 PM > To: linux-omap@vger.kernel.org > Cc: broo...@opensource.wolfsonmicro.com; l...@slimlogic.co.uk; Aggarwal, > Anuj > Subject: [PATCHv2 0/4] Regulator: OMAP: Removing common code for TWL4030 > from OMAP3- board-evms > > Sending version 2 of this patch set after taking all those comments. First > series can be found at: > http://marc.info/?l=linux-omap&m=126297346131188&w=2 > > This patch set is created to clean up various OMAP3-board-evm files > and remove common TWL4030 specific regulator suplies and init data > structs. These structures are instead placed in a new generic file - > twl4030-pmic.c - and are referenced from the OMAP3 board-evm > 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. > > Anuj Aggarwal (4): > Regulator: OMAP: Creating TWL4030 file having supplies & init data > Regulator: OMAP:Modifying Kconfig/Makefile to choose from available > PMICs > Regulator: OMAP: Kconfig modified to select TWL4030 for > OMAP3-platforms > Regulator: OMAP: Use common regulator supplies and init data structs > > arch/arm/mach-omap2/Kconfig | 20 +++ > arch/arm/mach-omap2/Makefile |1 + > arch/arm/mach-omap2/board-3430sdp.c | 135 ++-- > arch/arm/mach-omap2/board-cm-t35.c | 47 +-- > arch/arm/mach-omap2/board-igep0020.c | 24 +--- > arch/arm/mach-omap2/board-ldp.c | 24 +--- > arch/arm/mach-omap2/board-omap3beagle.c | 47 +-- > arch/arm/mach-omap2/board-omap3evm.c | 47 +-- > arch/arm/mach-omap2/board-omap3touchbook.c | 47 +-- > arch/arm/mach-omap2/board-overo.c| 23 +--- > arch/arm/mach-omap2/board-zoom-peripherals.c | 71 +-- > arch/arm/mach-omap2/twl4030-pmic.c | 175 > ++ > arch/arm/mach-omap2/twl4030-pmic.h | 34 + > 13 files changed, 277 insertions(+), 418 deletions(-) > mode change 100755 => 100644 arch/arm/mach-omap2/board-zoom-peripherals.c > create mode 100644 arch/arm/mach-omap2/twl4030-pmic.c > create mode 100644 arch/arm/mach-omap2/twl4030-pmic.h -- 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
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: [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
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 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-omap&m=12579548775&w=2 > > http://marc.info/?l=linux-omap&m=125795068502904&w=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] 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] 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: [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? > [Aggarwal, Anuj] Can someone please confirm that the problem lies in this API? Also, any help on how that can be fixed would be great. > -- > 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 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
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: [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] 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: [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 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: [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 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 > 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] 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:
>
> >
> > 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);
> > }
> >
>
> > 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: 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
> > ---
> > 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: 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:
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);
}
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: [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 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: [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] 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 > > > > 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: 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: 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 > > 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: 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: 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 [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-omap&m=125368984011630&w=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: [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
> > ---
> > 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
> > #include
> > #include
> > +#include
> >
> > #include
> > #include
> > #include
> > #include
> > +#include
> >
> > #include
> >
> > @@ -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_s
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
> ---
> 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
> #include
> #include
> +#include
>
> #include
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -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)
> @@ -359,6 +376,7 @@ static void __
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
> 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
> >> 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
> >> > ---
> >> > 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 regulator
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
> 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
> > ---
> > 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
> > +
> > +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 regu
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
> 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
> > ---
> > 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] ASoC: OMAP3EVM: Use the twl4030_setup_data for headset pop-removal
I rebased my both audio and l-o trees but could not find this patch
there. Is there a problem in this which I have to fix and re-submit?
Regards,
Anuj Aggarwal
> -Original Message-
> From: Aggarwal, Anuj
> Sent: Wednesday, September 23, 2009 12:41 PM
> To: alsa-de...@alsa-project.org; linux-omap@vger.kernel.org
> Cc: Aggarwal, Anuj
> Subject: [PATCH] ASoC: OMAP3EVM: Use the twl4030_setup_data for headset
> pop-removal
>
> The pop-removal specific values are configured for TWL4030 codec
> for OMAP3EVM through this patch.
>
> Signed-off-by: Anuj Aggarwal
> ---
> sound/soc/omap/omap3evm.c |7 +++
> 1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/sound/soc/omap/omap3evm.c b/sound/soc/omap/omap3evm.c
> index 9114c26..8deb59b 100644
> --- a/sound/soc/omap/omap3evm.c
> +++ b/sound/soc/omap/omap3evm.c
> @@ -93,10 +93,17 @@ static struct snd_soc_card snd_soc_omap3evm = {
> .num_links = 1,
> };
>
> +/* twl4030 setup */
> +static struct twl4030_setup_data twl4030_setup = {
> + .ramp_delay_value = 4,
> + .sysclk = 26000,
> +};
> +
> /* Audio subsystem */
> static struct snd_soc_device omap3evm_snd_devdata = {
> .card = &snd_soc_omap3evm,
> .codec_dev = &soc_codec_dev_twl4030,
> + .codec_data = &twl4030_setup,
> };
>
> static struct platform_device *omap3evm_snd_device;
> --
> 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
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
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 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
> 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" for reporting the issue.
>
> Signed-off-by: Jarkko Nikula
> ---
> 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 oma
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
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: [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
>
> 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_i
RE: [PATCH 1/3] Regulator: Add pmic.c file to regulator framework
> -Original Message- > From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com] > Sent: Saturday, May 09, 2009 12:37 AM > To: Aggarwal, Anuj > Cc: linux-omap@vger.kernel.org > Subject: Re: [PATCH 1/3] Regulator: Add pmic.c file to regulator framework > > On Fri, May 08, 2009 at 08:42:06PM +0530, Anuj Aggarwal wrote: > > > Added drivers\regulator\pmic.c file to the regulator framework which will > > I suspect you mean / there :) [Aggarwal, Anuj] Yeah:) > > > have the board specific information for different regulators and will do the > > regulator initialization depending on one which is available. > > > Signed-off-by: Anuj Aggarwal > > I'm really not sure what the abstraction that you're attempting to > introduce here is intended to do that can't handled by the existing > kernel features - could you go into more detail about the problem that > this patch is intended to solve, please? > > The kernel already provides facilities for detecting the presence of > devices. In cases where it is possible to do a generic check for a > device (for example, by reading back ID registers on the device and > checking the values) then the device driver can do so in its probe > routine and the board can unconditionally declare that the device is > there, allowing the probe to fail. In cases where something board > specific needs to be done (such as checking for fit resistors or > information provided by the bootloader) then that'd need to be handled > in the board code anyway - it's not going to apply on generic systems. > There will also be cases where it's just not possible to determine > what's fitted at runtime, especially for simple devices with GPIO only > control. [Aggarwal, Anuj] In my opinion, it would not be a good idea to probe for several PMICs, on all the buses present in the system. It can be simplified by probing only the ones which are relevant for this device. > > If there is initialisation which can always be done for a chip no matter > what board it's on then I'd expect the driver to just handle that when > it is starting up without needing separate code - if there's something > preventing that then we should definitely fix that, probably in a way > that's not specific to the regulator framework since I'd expect other > subsystems to be running into similar issues. > > Another thing here is that the code appears to assume that there will be > only one regulator device in the system which isn't always true. Some > designs will use a series of discrete regulators rather than integrated > chips while others will use several integrated PMICs for reasons such as > ease of layout or power distribution. [Aggarwal, Anuj] Can you explain this, I didn't get that much? > > Based on experience with the OMAP audio drivers I suspect the problem > the patch is trying to solve may be that there are a lot of designs out > there which are based on the reference platforms which TI have produced > and are therefore have very repetitive board code. Perhaps this might > be best handled by having some utility routines in the OMAP code which > the machine drivers can use to say that they have the same PMIC setup as > a given reference design? [Aggarwal, Anuj] You are right, the primary purpose of this patch is to avoid duplication of PMIC code, common to many OMAP platforms and I believe this is a simpler and cleaner approach. Instead of keeping this file in the drivers/regulator folder, we can move it to arch/arm/mach-omap2 folder. > > CCing in Liam so I've not deleted any of the text. > > > --- > > drivers/regulator/Makefile |2 +- > > drivers/regulator/pmic.c | 103 > > > include/linux/regulator/pmic.h | 29 +++ > > 3 files changed, 133 insertions(+), 1 deletions(-) > > create mode 100644 drivers/regulator/pmic.c > > create mode 100644 include/linux/regulator/pmic.h > > > > diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile > > index bac133a..c0d87bf 100644 > > --- a/drivers/regulator/Makefile > > +++ b/drivers/regulator/Makefile > > @@ -3,7 +3,7 @@ > > # > > > > > > -obj-$(CONFIG_REGULATOR) += core.o > > +obj-$(CONFIG_REGULATOR) += core.o pmic.o > > obj-$(CONFIG_REGULATOR_FIXED_VOLTAGE) += fixed.o > > obj-$(CONFIG_REGULATOR_VIRTUAL_CONSUMER) += virtual.o > > > > diff --git a/drivers/regulator/pmic.c b/drivers/regulator/pmic.c > > new file mode 100644 > > index 000..36ed341 > > --- /dev/null > > +++ b/drivers/regulator/pmic.c > > @@ -0,0 +1,103 @@ > > +/* > >
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
> wrote:
> >
> > Signed-off-by: Anuj Aggarwal
> > ---
> > 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
> > + *
> > + * 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
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#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 |
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: 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
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: [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-omap&m=124083364321017&w=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
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 [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
> > *
> > * copyright
> > */
> >
> > #include
> > #include
> > #include
> >
> > #include
> > #include
> >
> > /* --- 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 woul
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: 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 > 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 > > 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
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
*
* copyright
*/
#include
#include
#include
#include
#include
/* --- 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
Mark, I could not find the commit in linux-OMAP git where the init data is passed as a parameter to the regulator_register(). I am dependent on this commit for my TPS65023 regulator driver and could not push my patch without the commit being in l-o. Any idea when this would be available in l-o? Thanks and Regards, Anuj Aggarwal 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: 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: 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
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
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:
>>>
/* 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));
.
.
}
>>>
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:
>>>
#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);
>>>
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 bo
