diff mbox

pinctrl: imx5: fix SD2_DATA1 pad AUDMUX_AUD4 configuration

Message ID 1364882642-25574-1-git-send-email-marex@denx.de (mailing list archive)
State New, archived
Headers show

Commit Message

Marek Vasut April 2, 2013, 6:04 a.m. UTC
The IOMUXC_AUDMUX_P4_INPUT_TXCLK_AMX_SELECT_INPUT must be configured as 1
instead of 0 to have AUD4 muxed on SD2 pins working.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Shawn Guo <shawn.guo@linaro.org>
---
 drivers/pinctrl/pinctrl-imx53.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

NOTE: Shawn, we might want this in -stable too ?

Comments

Shawn Guo April 2, 2013, 11:43 a.m. UTC | #1
Marek,

On Tue, Apr 02, 2013 at 08:04:02AM +0200, Marek Vasut wrote:
> The IOMUXC_AUDMUX_P4_INPUT_TXCLK_AMX_SELECT_INPUT must be configured as 1
> instead of 0 to have AUD4 muxed on SD2 pins working.
> 
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Fabio Estevam <fabio.estevam@freescale.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Philipp Zabel <p.zabel@pengutronix.de>
> Cc: Shawn Guo <shawn.guo@linaro.org>
> ---
>  drivers/pinctrl/pinctrl-imx53.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> NOTE: Shawn, we might want this in -stable too ?

I have queued patch b466af3 (pinctrl: imx: move hard-coding data into
device tree) on my imx/dt branch to remove these tables from pinctrl
drivers.

Since there is no in-tree users for MX53_PAD_SD2_DATA1__AUDMUX_AUD4_TXFS,
and we're moving away from it, can we just patch
arch/arm/boot/dts/imx53-pinfunc.h instead?

Shawn

> 
> diff --git a/drivers/pinctrl/pinctrl-imx53.c b/drivers/pinctrl/pinctrl-imx53.c
> index 2c9c8e2..85f401c 100644
> --- a/drivers/pinctrl/pinctrl-imx53.c
> +++ b/drivers/pinctrl/pinctrl-imx53.c
> @@ -1287,7 +1287,7 @@ static struct imx_pin_reg imx53_pin_regs[] = {
>  	IMX_PIN_REG(MX53_PAD_SD2_DATA1, 0x698, 0x30C, 0, 0x000, 0), /* MX53_PAD_SD2_DATA1__ESDHC2_DAT1 */
>  	IMX_PIN_REG(MX53_PAD_SD2_DATA1, 0x698, 0x30C, 1, 0x000, 0), /* MX53_PAD_SD2_DATA1__GPIO1_14 */
>  	IMX_PIN_REG(MX53_PAD_SD2_DATA1, 0x698, 0x30C, 2, 0x848, 1), /* MX53_PAD_SD2_DATA1__KPP_COL_7 */
> -	IMX_PIN_REG(MX53_PAD_SD2_DATA1, 0x698, 0x30C, 3, 0x744, 0), /* MX53_PAD_SD2_DATA1__AUDMUX_AUD4_TXFS */
> +	IMX_PIN_REG(MX53_PAD_SD2_DATA1, 0x698, 0x30C, 3, 0x744, 1), /* MX53_PAD_SD2_DATA1__AUDMUX_AUD4_TXFS */
>  	IMX_PIN_REG(MX53_PAD_SD2_DATA1, 0x698, 0x30C, 5, 0x78C, 4), /* MX53_PAD_SD2_DATA1__CSPI_SS0 */
>  	IMX_PIN_REG(MX53_PAD_SD2_DATA1, 0x698, 0x30C, 7, 0x000, 0), /* MX53_PAD_SD2_DATA1__RTIC_SEC_VIO */
>  	IMX_PIN_REG(MX53_PAD_SD2_DATA0, 0x69C, 0x310, 0, 0x000, 0), /* MX53_PAD_SD2_DATA0__ESDHC2_DAT0 */
> -- 
> 1.7.10.4
>
Marek Vasut April 3, 2013, 12:21 a.m. UTC | #2
Dear Shawn Guo,

> Marek,
> 
> On Tue, Apr 02, 2013 at 08:04:02AM +0200, Marek Vasut wrote:
> > The IOMUXC_AUDMUX_P4_INPUT_TXCLK_AMX_SELECT_INPUT must be configured as 1
> > instead of 0 to have AUD4 muxed on SD2 pins working.
> > 
> > Signed-off-by: Marek Vasut <marex@denx.de>
> > Cc: Fabio Estevam <fabio.estevam@freescale.com>
> > Cc: Linus Walleij <linus.walleij@linaro.org>
> > Cc: Philipp Zabel <p.zabel@pengutronix.de>
> > Cc: Shawn Guo <shawn.guo@linaro.org>
> > ---
> > 
> >  drivers/pinctrl/pinctrl-imx53.c |    2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > NOTE: Shawn, we might want this in -stable too ?
> 
> I have queued patch b466af3 (pinctrl: imx: move hard-coding data into
> device tree) on my imx/dt branch to remove these tables from pinctrl
> drivers.
> 
> Since there is no in-tree users for MX53_PAD_SD2_DATA1__AUDMUX_AUD4_TXFS,
> and we're moving away from it, can we just patch
> arch/arm/boot/dts/imx53-pinfunc.h instead?
> 
> Shawn

One serving of such patch, coming right up ;-)

btw. do you want to apply this one for -stable or do we just leave it as is ?

Best regards,
Marek Vasut
Shawn Guo April 3, 2013, 5:24 a.m. UTC | #3
On Wed, Apr 03, 2013 at 02:21:18AM +0200, Marek Vasut wrote:
> One serving of such patch, coming right up ;-)
> 
> btw. do you want to apply this one for -stable or do we just leave it as is ?
> 
If you do not insist, I would say let's leave it as it is, as we
encourage people to upgrade device tree to adopt the new pinctrl
binding.

Shawn
Marek Vasut April 3, 2013, 6:52 a.m. UTC | #4
Dear Shawn Guo,

> On Wed, Apr 03, 2013 at 02:21:18AM +0200, Marek Vasut wrote:
> > One serving of such patch, coming right up ;-)
> > 
> > btw. do you want to apply this one for -stable or do we just leave it as
> > is ?
> 
> If you do not insist, I would say let's leave it as it is, as we
> encourage people to upgrade device tree to adopt the new pinctrl
> binding.

Actually, I have a bad feeling about having an open bug in stable tree. Someone 
might use that tree and might try to use AUDMUX4 on his (out-of-tree) device and 
might run into the same problem. Three times 'might' in one sentence doesn't 
make it sound too likely, but if you have not much trouble with getting it in -
stable, please try to.

Best regards,
Marek Vasut
Shawn Guo April 3, 2013, 8:38 a.m. UTC | #5
On Wed, Apr 03, 2013 at 08:52:51AM +0200, Marek Vasut wrote:
> Dear Shawn Guo,
> 
> > On Wed, Apr 03, 2013 at 02:21:18AM +0200, Marek Vasut wrote:
> > > One serving of such patch, coming right up ;-)
> > > 
> > > btw. do you want to apply this one for -stable or do we just leave it as
> > > is ?
> > 
> > If you do not insist, I would say let's leave it as it is, as we
> > encourage people to upgrade device tree to adopt the new pinctrl
> > binding.
> 
> Actually, I have a bad feeling about having an open bug in stable tree. Someone 
> might use that tree and might try to use AUDMUX4 on his (out-of-tree) device and 
> might run into the same problem. Three times 'might' in one sentence doesn't 
> make it sound too likely, but if you have not much trouble with getting it in -
> stable, please try to.

Ok, it's Linus' call then, since it's a fix that should go via pinctrl
tree.  Since I will not be able to rebase my 3.10 stuff on -rc7, if the
patch does not catch up with -rc6, we run into a annoying merge
conflict during the merge window.

Shawn
Linus Walleij April 3, 2013, 4:58 p.m. UTC | #6
On Wed, Apr 3, 2013 at 10:38 AM, Shawn Guo <shawn.guo@linaro.org> wrote:
> On Wed, Apr 03, 2013 at 08:52:51AM +0200, Marek Vasut wrote:
>> Dear Shawn Guo,
>>
>> > On Wed, Apr 03, 2013 at 02:21:18AM +0200, Marek Vasut wrote:
>> > > One serving of such patch, coming right up ;-)
>> > >
>> > > btw. do you want to apply this one for -stable or do we just leave it as
>> > > is ?
>> >
>> > If you do not insist, I would say let's leave it as it is, as we
>> > encourage people to upgrade device tree to adopt the new pinctrl
>> > binding.
>>
>> Actually, I have a bad feeling about having an open bug in stable tree. Someone
>> might use that tree and might try to use AUDMUX4 on his (out-of-tree) device and
>> might run into the same problem. Three times 'might' in one sentence doesn't
>> make it sound too likely, but if you have not much trouble with getting it in -
>> stable, please try to.
>
> Ok, it's Linus' call then, since it's a fix that should go via pinctrl
> tree.  Since I will not be able to rebase my 3.10 stuff on -rc7, if the
> patch does not catch up with -rc6, we run into a annoying merge
> conflict during the merge window.

Basically I'm not keen on sending any DT patches as fixes, DT
is at one time supposed to be moved out of the kernel even. I don't
think it qualifies for fixes this late in the merge window.

Besides it's not in a part of the file hierarchy I maintain so I
strongly prefer pure DT patches to go in from the platform trees.
(Subject should be ARM: imx ...)

Please carry this patch in the Freescale tree.

Yours,
Linus Walleij
diff mbox

Patch

diff --git a/drivers/pinctrl/pinctrl-imx53.c b/drivers/pinctrl/pinctrl-imx53.c
index 2c9c8e2..85f401c 100644
--- a/drivers/pinctrl/pinctrl-imx53.c
+++ b/drivers/pinctrl/pinctrl-imx53.c
@@ -1287,7 +1287,7 @@  static struct imx_pin_reg imx53_pin_regs[] = {
 	IMX_PIN_REG(MX53_PAD_SD2_DATA1, 0x698, 0x30C, 0, 0x000, 0), /* MX53_PAD_SD2_DATA1__ESDHC2_DAT1 */
 	IMX_PIN_REG(MX53_PAD_SD2_DATA1, 0x698, 0x30C, 1, 0x000, 0), /* MX53_PAD_SD2_DATA1__GPIO1_14 */
 	IMX_PIN_REG(MX53_PAD_SD2_DATA1, 0x698, 0x30C, 2, 0x848, 1), /* MX53_PAD_SD2_DATA1__KPP_COL_7 */
-	IMX_PIN_REG(MX53_PAD_SD2_DATA1, 0x698, 0x30C, 3, 0x744, 0), /* MX53_PAD_SD2_DATA1__AUDMUX_AUD4_TXFS */
+	IMX_PIN_REG(MX53_PAD_SD2_DATA1, 0x698, 0x30C, 3, 0x744, 1), /* MX53_PAD_SD2_DATA1__AUDMUX_AUD4_TXFS */
 	IMX_PIN_REG(MX53_PAD_SD2_DATA1, 0x698, 0x30C, 5, 0x78C, 4), /* MX53_PAD_SD2_DATA1__CSPI_SS0 */
 	IMX_PIN_REG(MX53_PAD_SD2_DATA1, 0x698, 0x30C, 7, 0x000, 0), /* MX53_PAD_SD2_DATA1__RTIC_SEC_VIO */
 	IMX_PIN_REG(MX53_PAD_SD2_DATA0, 0x69C, 0x310, 0, 0x000, 0), /* MX53_PAD_SD2_DATA0__ESDHC2_DAT0 */