| Message ID | 1349879449-22657-1-git-send-email-mporter@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wed, Oct 10, 2012 at 20:00:49, Porter, Matt wrote: > 6ea74cb ARM: OMAP2+: hwmod: get rid of all omap_clk_get_by_name usage > exposes a bug in the AM33XX clock data for mcasp. After moving to > clk_get() usage, the _init() of all registered hwmods fails on mcasp0 > due to incorrect clock data causing clk_get() to fail. This causes all > successive hwmods to fail to _init() leaving them in a bad state. > > This patch updates the mcasp clock entries so clk_get() will succeed. > It is tested on BeagleBone and is needed for 3.7-rc1 to fix AM33xx > boot. > Matt, I have already submitted patch for this and it is accepted and merged in Tony's pull request. https://patchwork.kernel.org/patch/1499271/ Thanks, Vaibhav > Signed-off-by: Matt Porter <mporter@ti.com> > --- > arch/arm/mach-omap2/clock33xx_data.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/mach-omap2/clock33xx_data.c b/arch/arm/mach-omap2/clock33xx_data.c > index b87b88c..0a64139 100644 > --- a/arch/arm/mach-omap2/clock33xx_data.c > +++ b/arch/arm/mach-omap2/clock33xx_data.c > @@ -1033,8 +1033,8 @@ static struct omap_clk am33xx_clks[] = { > CLK("481d0000.d_can", NULL, &dcan1_fck, CK_AM33XX), > CLK(NULL, "debugss_ick", &debugss_ick, CK_AM33XX), > CLK(NULL, "pruss_ocp_gclk", &pruss_ocp_gclk, CK_AM33XX), > - CLK("davinci-mcasp.0", NULL, &mcasp0_fck, CK_AM33XX), > - CLK("davinci-mcasp.1", NULL, &mcasp1_fck, CK_AM33XX), > + CLK(NULL, "mcasp0_fck", &mcasp0_fck, CK_AM33XX), > + CLK(NULL, "mcasp1_fck", &mcasp1_fck, CK_AM33XX), > CLK("NULL", "mmc2_fck", &mmc2_fck, CK_AM33XX), > CLK(NULL, "mmu_fck", &mmu_fck, CK_AM33XX), > CLK(NULL, "smartreflex0_fck", &smartreflex0_fck, CK_AM33XX), > -- > 1.7.9.5 > >
On Wed, Oct 10, 2012 at 02:33:54PM +0000, Vaibhav Hiremath wrote: > On Wed, Oct 10, 2012 at 20:00:49, Porter, Matt wrote: > > 6ea74cb ARM: OMAP2+: hwmod: get rid of all omap_clk_get_by_name usage > > exposes a bug in the AM33XX clock data for mcasp. After moving to > > clk_get() usage, the _init() of all registered hwmods fails on mcasp0 > > due to incorrect clock data causing clk_get() to fail. This causes all > > successive hwmods to fail to _init() leaving them in a bad state. > > > > This patch updates the mcasp clock entries so clk_get() will succeed. > > It is tested on BeagleBone and is needed for 3.7-rc1 to fix AM33xx > > boot. > > > > Matt, > > I have already submitted patch for this and it is accepted and merged in > Tony's pull request. > > https://patchwork.kernel.org/patch/1499271/ Heh, ok. My search skills failed badly when I ran into this. Thanks :) -Matt
Matt, On Wed, Oct 10, 2012 at 20:00:49, Porter, Matt wrote: > 6ea74cb ARM: OMAP2+: hwmod: get rid of all omap_clk_get_by_name usage > exposes a bug in the AM33XX clock data for mcasp. After moving to > clk_get() usage, the _init() of all registered hwmods fails on mcasp0 > due to incorrect clock data causing clk_get() to fail. This causes all > successive hwmods to fail to _init() leaving them in a bad state. > > This patch updates the mcasp clock entries so clk_get() will succeed. > It is tested on BeagleBone and is needed for 3.7-rc1 to fix AM33xx > boot. I want to test Audio on AM335x Evm with your EDMA patches. I have few patches for AM335x. Can you share the link to the repo & branch on which I need to rebase? The patches are related to mcasp dt node, mcasp pinmux in dt, etc... > ..snip.. ..snip.. > Thanks & Regards, Gururaja
Hi Guraraja, I am interested in this thread. I've been trying Gururaja's patches for audio as well. I rebased Guraja's patches on top of Matt's EDMA patches which were applied to the beaglebone 3.7 kernel repo. With some fixes to make it compile with CONFIG_DUMMY_REGULATOR enabled, Currently it breaks at set_dai_fmt in davinci-mcasp.c when an audio file is played. Could you try my tree on EVM? dts changes may be required to use mcasp1 on EVM, https://github.com/joelagnel/linux-kernel/commits/3.7 v3.7-rc2-fixes to v3.7-rc2-audio commits are Gururaja's patches which I applied, and after that are my commits to enable config , add dt data and some fixes. Thanks, Joel On Mon, Oct 29, 2012 at 10:45 AM, Hebbar, Gururaja <gururaja.hebbar@ti.com>wrote: > Matt, > > On Wed, Oct 10, 2012 at 20:00:49, Porter, Matt wrote: > > 6ea74cb ARM: OMAP2+: hwmod: get rid of all omap_clk_get_by_name usage > > exposes a bug in the AM33XX clock data for mcasp. After moving to > > clk_get() usage, the _init() of all registered hwmods fails on mcasp0 > > due to incorrect clock data causing clk_get() to fail. This causes all > > successive hwmods to fail to _init() leaving them in a bad state. > > > > This patch updates the mcasp clock entries so clk_get() will succeed. > > It is tested on BeagleBone and is needed for 3.7-rc1 to fix AM33xx > > boot. > > > I want to test Audio on AM335x Evm with your EDMA patches. I have few > patches for AM335x. > Can you share the link to the repo & branch on which I need to rebase? > The patches are related to mcasp dt node, mcasp pinmux in dt, etc... > > > > ..snip.. > ..snip.. > > > > > Thanks & Regards, > Gururaja > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
[resending, because the first post got rejected due to non-plaintext] Hi Guraraja, I am interested in this thread. I've been trying Gururaja's patches for audio as well. I rebased Guraja's patches on top of Matt's EDMA patches which were applied to the beaglebone 3.7 kernel repo. With some fixes to make it compile with CONFIG_DUMMY_REGULATOR enabled, Currently it breaks at set_dai_fmt in davinci-mcasp.c when an audio file is played. Could you try my tree on EVM? dts changes may be required to use mcasp1 on EVM, https://github.com/joelagnel/linux-kernel/commits/3.7 v3.7-rc2-fixes to v3.7-rc2-audio commits are Gururaja's patches which I applied, and after that are my commits to enable config , add dt data and some fixes. Thanks, Joel On Mon, Oct 29, 2012 at 10:45 AM, Hebbar, Gururaja <gururaja.hebbar@ti.com> wrote: > > Matt, > > On Wed, Oct 10, 2012 at 20:00:49, Porter, Matt wrote: > > 6ea74cb ARM: OMAP2+: hwmod: get rid of all omap_clk_get_by_name usage > > exposes a bug in the AM33XX clock data for mcasp. After moving to > > clk_get() usage, the _init() of all registered hwmods fails on mcasp0 > > due to incorrect clock data causing clk_get() to fail. This causes all > > successive hwmods to fail to _init() leaving them in a bad state. > > > > This patch updates the mcasp clock entries so clk_get() will succeed. > > It is tested on BeagleBone and is needed for 3.7-rc1 to fix AM33xx > > boot. > > > I want to test Audio on AM335x Evm with your EDMA patches. I have few > patches for AM335x. > Can you share the link to the repo & branch on which I need to rebase? > The patches are related to mcasp dt node, mcasp pinmux in dt, etc... > > > > ..snip.. > ..snip.. > > > > > Thanks & Regards, > Gururaja > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Gururaja, On Mon, Oct 29, 2012 at 10:45 AM, Hebbar, Gururaja <gururaja.hebbar@ti.com> wrote: > Matt, > > On Wed, Oct 10, 2012 at 20:00:49, Porter, Matt wrote: >> 6ea74cb ARM: OMAP2+: hwmod: get rid of all omap_clk_get_by_name usage >> exposes a bug in the AM33XX clock data for mcasp. After moving to >> clk_get() usage, the _init() of all registered hwmods fails on mcasp0 >> due to incorrect clock data causing clk_get() to fail. This causes all >> successive hwmods to fail to _init() leaving them in a bad state. >> >> This patch updates the mcasp clock entries so clk_get() will succeed. >> It is tested on BeagleBone and is needed for 3.7-rc1 to fix AM33xx >> boot. > > > I want to test Audio on AM335x Evm with your EDMA patches. I have few > patches for AM335x. > Can you share the link to the repo & branch on which I need to rebase? > The patches are related to mcasp dt node, mcasp pinmux in dt, etc... > I was wondering about the status of following patches you wrote, not added to mainline yet: (1) ASoC: Davinci: machine: Add device tree binding https://patchwork.kernel.org/patch/1380511/ - will this be resubmitted? (2) ASoC: AM33XX: Add support for AM33xx SoC Audio https://github.com/joelagnel/linux-kernel/commit/973cfb48bdb70018b3869a21595bde8630efb29d Are you planning on sending/resending these patches again? I could do this too. I guess all other audio patches except for audio dts stuff is already in. Thanks, Joel
On Wed, Oct 31, 2012 at 01:58:32, Joel A Fernandes wrote: > Hi Gururaja, > > On Mon, Oct 29, 2012 at 10:45 AM, Hebbar, Gururaja > <gururaja.hebbar@ti.com> wrote: > > Matt, > > > > On Wed, Oct 10, 2012 at 20:00:49, Porter, Matt wrote: > >> 6ea74cb ARM: OMAP2+: hwmod: get rid of all omap_clk_get_by_name usage > >> exposes a bug in the AM33XX clock data for mcasp. After moving to > >> clk_get() usage, the _init() of all registered hwmods fails on mcasp0 > >> due to incorrect clock data causing clk_get() to fail. This causes all > >> successive hwmods to fail to _init() leaving them in a bad state. > >> > >> This patch updates the mcasp clock entries so clk_get() will succeed. > >> It is tested on BeagleBone and is needed for 3.7-rc1 to fix AM33xx > >> boot. > > > > > > I want to test Audio on AM335x Evm with your EDMA patches. I have few > > patches for AM335x. > > Can you share the link to the repo & branch on which I need to rebase? > > The patches are related to mcasp dt node, mcasp pinmux in dt, etc... > > > > I was wondering about the status of following patches you wrote, not > added to mainline yet: > > (1) > ASoC: Davinci: machine: Add device tree binding > https://patchwork.kernel.org/patch/1380511/ - will this be resubmitted? There was no review comments for V3 I submitted. > > (2) > ASoC: AM33XX: Add support for AM33xx SoC Audio > https://github.com/joelagnel/linux-kernel/commit/973cfb48bdb70018b3869a21595bde8630efb29d I want to re-submit both the patches along with 2 more patch-set [1]. I am waiting for Matt Porters to reply with his recent branch, so that I can do a final test and re-submit. [1]. arm/dts: Add tlv320aic3x codec DT data to am335x-evm.dts arm/dts: add mcasp1 dt node to am335x-evm.dt ASoC: davinci-mcasp: Add pinctrl support arm/dts: AM33XX: setup pinctrl for mcasp1 on am335x-evm I need Mark Brown's Ack for the 3rd patch. There was some discussion about adding pinctrl support for Audio drivers. I couldn't get the final decision taken on it. I will rebase on to brownie-asoc/for-next and submit it today. > > Are you planning on sending/resending these patches again? I could do this too. > > I guess all other audio patches except for audio dts stuff is already in. > > Thanks, > Joel > Regards, Gururaja
Hi Gururaja, On Wed, Oct 31, 2012 at 12:39 AM, Hebbar, Gururaja <gururaja.hebbar@ti.com> wrote: > On Wed, Oct 31, 2012 at 01:58:32, Joel A Fernandes wrote: >> Hi Gururaja, >> >> On Mon, Oct 29, 2012 at 10:45 AM, Hebbar, Gururaja >> <gururaja.hebbar@ti.com> wrote: >> > Matt, >> > >> > On Wed, Oct 10, 2012 at 20:00:49, Porter, Matt wrote: >> >> 6ea74cb ARM: OMAP2+: hwmod: get rid of all omap_clk_get_by_name usage >> >> exposes a bug in the AM33XX clock data for mcasp. After moving to >> >> clk_get() usage, the _init() of all registered hwmods fails on mcasp0 >> >> due to incorrect clock data causing clk_get() to fail. This causes all >> >> successive hwmods to fail to _init() leaving them in a bad state. >> >> >> >> This patch updates the mcasp clock entries so clk_get() will succeed. >> >> It is tested on BeagleBone and is needed for 3.7-rc1 to fix AM33xx >> >> boot. >> > >> > >> > I want to test Audio on AM335x Evm with your EDMA patches. I have few >> > patches for AM335x. >> > Can you share the link to the repo & branch on which I need to rebase? >> > The patches are related to mcasp dt node, mcasp pinmux in dt, etc... >> > >> >> I was wondering about the status of following patches you wrote, not >> added to mainline yet: >> >> (1) >> ASoC: Davinci: machine: Add device tree binding >> https://patchwork.kernel.org/patch/1380511/ - will this be resubmitted? > > There was no review comments for V3 I submitted. > >> >> (2) >> ASoC: AM33XX: Add support for AM33xx SoC Audio >> https://github.com/joelagnel/linux-kernel/commit/973cfb48bdb70018b3869a21595bde8630efb29d > > I want to re-submit both the patches along with 2 more patch-set [1]. I am > waiting for Matt Porters to reply with his recent branch, so that I can do > a final test and re-submit. > > [1]. > arm/dts: Add tlv320aic3x codec DT data to am335x-evm.dts > arm/dts: add mcasp1 dt node to am335x-evm.dt > ASoC: davinci-mcasp: Add pinctrl support > arm/dts: AM33XX: setup pinctrl for mcasp1 on am335x-evm > Thanks, I think I have all of your patches now in my tree, I made a few more changes to make it compile and run for me on 3.7-rc2 beaglebone_defconfig: Add dummy regulator to init tlv320aic3x https://github.com/joelagnel/linux-kernel/commit/db5672dfe548d82625cf40ed688d05ba7cee5c93 ASoC: davinci-evm: cpu_dai_of_node has changed to cpu_of_node https://github.com/joelagnel/linux-kernel/commit/8781c69553d0faf7cec0119e593447f27fdc07e9 I don't get a crash anymore (after correcting mcasp0 base address in dts), but I still don't get any audio output from the codec. I will probe the audio signals next week to make sure the I2S output is correct. Regards, Joel
On Sat, Nov 03, 2012 at 02:32:59PM -0500, Joel A Fernandes wrote: > beaglebone_defconfig: Add dummy regulator to init tlv320aic3x > https://github.com/joelagnel/linux-kernel/commit/db5672dfe548d82625cf40ed688d05ba7cee5c93 This should never be done in production, you should ensure that the appropriate supplies are provided by the board file or device tree.
Hi Mark, On Mon, Nov 5, 2012 at 3:13 AM, Mark Brown <broonie@opensource.wolfsonmicro.com> wrote: > On Sat, Nov 03, 2012 at 02:32:59PM -0500, Joel A Fernandes wrote: > >> beaglebone_defconfig: Add dummy regulator to init tlv320aic3x >> https://github.com/joelagnel/linux-kernel/commit/db5672dfe548d82625cf40ed688d05ba7cee5c93 > > This should never be done in production, you should ensure that the > appropriate supplies are provided by the board file or device tree. Sure I just did this for debugging purpose, Thanks, Joel
diff --git a/arch/arm/mach-omap2/clock33xx_data.c b/arch/arm/mach-omap2/clock33xx_data.c index b87b88c..0a64139 100644 --- a/arch/arm/mach-omap2/clock33xx_data.c +++ b/arch/arm/mach-omap2/clock33xx_data.c @@ -1033,8 +1033,8 @@ static struct omap_clk am33xx_clks[] = { CLK("481d0000.d_can", NULL, &dcan1_fck, CK_AM33XX), CLK(NULL, "debugss_ick", &debugss_ick, CK_AM33XX), CLK(NULL, "pruss_ocp_gclk", &pruss_ocp_gclk, CK_AM33XX), - CLK("davinci-mcasp.0", NULL, &mcasp0_fck, CK_AM33XX), - CLK("davinci-mcasp.1", NULL, &mcasp1_fck, CK_AM33XX), + CLK(NULL, "mcasp0_fck", &mcasp0_fck, CK_AM33XX), + CLK(NULL, "mcasp1_fck", &mcasp1_fck, CK_AM33XX), CLK("NULL", "mmc2_fck", &mmc2_fck, CK_AM33XX), CLK(NULL, "mmu_fck", &mmu_fck, CK_AM33XX), CLK(NULL, "smartreflex0_fck", &smartreflex0_fck, CK_AM33XX),
6ea74cb ARM: OMAP2+: hwmod: get rid of all omap_clk_get_by_name usage exposes a bug in the AM33XX clock data for mcasp. After moving to clk_get() usage, the _init() of all registered hwmods fails on mcasp0 due to incorrect clock data causing clk_get() to fail. This causes all successive hwmods to fail to _init() leaving them in a bad state. This patch updates the mcasp clock entries so clk_get() will succeed. It is tested on BeagleBone and is needed for 3.7-rc1 to fix AM33xx boot. Signed-off-by: Matt Porter <mporter@ti.com> --- arch/arm/mach-omap2/clock33xx_data.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)