MMC3 Overo

MMC3 Overo

[John Sarman]

I am trying to use mmc3 on the Overo Gumstix board with no luck.  I
have patched the kernel with the latest changes and have yet to see a
clk pulse, both before and after the patches.
So far I have reconfigured the pins with uboot to GPIO and tested each
pin to verify that the signals are connected properly.  That test
passed.
Then I reconfigured them back to MODE 2(mmc modes) for each pin.  I am
confident that the level transceiver(TXS0108ERGYR) is operating
properly. This transceiver is automatic so no external controls are
necessary.


<u-boot_snip>
 MUX_VAL(CP(ETK_CLK_ES2),       (IDIS | PTU | EN  | M2)) /*MMC3_CLK*/\
 MUX_VAL(CP(ETK_CTL_ES2),       (IEN  | PTU | EN  | M2)) /*MMC3_CMD*/\
 MUX_VAL(CP(ETK_D3_ES2),        (IEN  | PTU | EN  | M2)) /*MMC3_DAT3*/\
 MUX_VAL(CP(ETK_D4_ES2),        (IEN  | PTU | EN  | M2)) /*MMC3_DAT0*/\
 MUX_VAL(CP(ETK_D5_ES2),        (IEN  | PTU | EN  | M2)) /*MMC3_DAT1*/\
 MUX_VAL(CP(ETK_D6_ES2),        (IEN  | PTU | EN  | M2)) /*MMC3_DAT2*/\
</u-boot_snip>

<mmc_params>
// I Switched mmc 2 and 3 in a feeble attempt.  Also I removed 2 in an
earlier attempt and the kernel would not boot ???????
// Also I have tested working gpio connected to CD and WP but not
attempting to tackle that yet.
static struct twl4030_hsmmc_info mmc[] = {
        {
                .mmc            = 1,
                .wires          = 4,
                .gpio_cd        = -EINVAL,
                .gpio_wp        = -EINVAL,
        },
        {
                .mmc            = 3,
                .wires          = 4,
                .gpio_cd        = -EINVAL,
                .gpio_wp        = -EINVAL,
        },
        {
                .mmc            = 2,
                .wires          = 4,
                .gpio_cd        = -EINVAL,
                .gpio_wp        = -EINVAL,
                .transceiver    = true,
                .ocr_mask       = 0x00100000,   /* 3.3V */
        },
        {}      /* Terminator */
};
</mmc_params>

<twl_setup>

static int overo_twl_gpio_setup(struct device *dev,
                unsigned gpio, unsigned ngpio)
{
        twl4030_mmc_init(mmc);        <-- mmc params    passed to init

        overo_vmmc1_supply.dev = mmc[0].dev;

        return 0;
}
static struct twl4030_gpio_platform_data overo_gpio_data = {
        .gpio_base      = OMAP_MAX_GPIO_LINES,
        .irq_base       = TWL4030_GPIO_IRQ_BASE,
        .irq_end        = TWL4030_GPIO_IRQ_END,
        .setup          = overo_twl_gpio_setup,
<-----    setup passed into the twl4030 gpio platform data
};

static struct twl4030_platform_data overo_twldata = {
        .irq_base       = TWL4030_IRQ_BASE,
        .irq_end        = TWL4030_IRQ_END,
        .gpio           = &overo_gpio_data,
<--- gpio data passed into twl4030 plat data
        .usb            = &overo_usb_data,
        .power          = GENERIC3430_T2SCRIPTS_DATA,
        .vmmc1          = &overo_vmmc1,
};

static struct i2c_board_info __initdata overo_i2c_boardinfo[] = {
        {
                I2C_BOARD_INFO("tps65950", 0x48),
                .flags = I2C_CLIENT_WAKE,
                .irq = INT_34XX_SYS_NIRQ,
                .platform_data = &overo_twldata,
        },
};

static int __init overo_i2c_init(void)
{
        omap_register_i2c_bus(1, 2600, overo_i2c_boardinfo,
                        ARRAY_SIZE(overo_i2c_boardinfo));
        /* i2c2 pins are used for gpio */
        omap_register_i2c_bus(3, 400, NULL, 0);
        return 0;
}

// i2c_init called first in init.
static void __init overo_init(void)
{
        overo_i2c_init();
 .....
 </twl_setup>


So the way I see it working is i2c is initialized, which sets up the
twl4030.  When the twl4030 configures gpio it initializes the mmc.
mmc0 comes up fine (I have a root File System), but I never get a clk
on mmc3.

Any help would be greatly appreciated.

Thanks
John Sarman

Re: MMC3 Overo

[John Sarman]

On Thu, Jul 30, 2009 at 11:49 AM, John Sarman<johnsarman@gmail.com> wrote:
> I am trying to use mmc3 on the Overo Gumstix board with no luck.  I
> have patched the kernel with the latest changes and have yet to see a
> clk pulse, both before and after the patches.
After adding some debugging printks, I have determined the mmc3 fails
getting IRQ
mmci-omap-hs mmci-omap-hs.0: Failed to get debounce clock
REQUEST IRQ = 83 HOST = -812068416
mmci-omap-hs mmci-omap-hs.1: Failed to get debounce clock
REQUEST IRQ = 86 HOST = -812067392
mmci-omap-hs mmci-omap-hs.2: Failed to get debounce clock
REQUEST IRQ = 83 HOST = -812066368
mmci-omap-hs mmci-omap-hs.2: Unable to grab HSMMC IRQ
mmci-omap-hs mmci-omap-hs.2: Probe Failed
mmci-omap-hs: probe of mmci-omap-hs.2 failed with error -16

For some reason mmc1 and mmc3 ask for the same interrupt 83 ???

Why would this be assigned the same value?

> So far I have reconfigured the pins with uboot to GPIO and tested each
> pin to verify that the signals are connected properly.  That test
> passed.
> Then I reconfigured them back to MODE 2(mmc modes) for each pin.  I am
> confident that the level transceiver(TXS0108ERGYR) is operating
> properly. This transceiver is automatic so no external controls are
> necessary.
>
>
> <u-boot_snip>
>  MUX_VAL(CP(ETK_CLK_ES2),       (IDIS | PTU | EN  | M2)) /*MMC3_CLK*/\
>  MUX_VAL(CP(ETK_CTL_ES2),       (IEN  | PTU | EN  | M2)) /*MMC3_CMD*/\
>  MUX_VAL(CP(ETK_D3_ES2),        (IEN  | PTU | EN  | M2)) /*MMC3_DAT3*/\
>  MUX_VAL(CP(ETK_D4_ES2),        (IEN  | PTU | EN  | M2)) /*MMC3_DAT0*/\
>  MUX_VAL(CP(ETK_D5_ES2),        (IEN  | PTU | EN  | M2)) /*MMC3_DAT1*/\
>  MUX_VAL(CP(ETK_D6_ES2),        (IEN  | PTU | EN  | M2)) /*MMC3_DAT2*/\
> </u-boot_snip>
>
> <mmc_params>
> // I Switched mmc 2 and 3 in a feeble attempt.  Also I removed 2 in an
> earlier attempt and the kernel would not boot ???????
> // Also I have tested working gpio connected to CD and WP but not
> attempting to tackle that yet.
> static struct twl4030_hsmmc_info mmc[] = {
>        {
>                .mmc            = 1,
>                .wires          = 4,
>                .gpio_cd        = -EINVAL,
>                .gpio_wp        = -EINVAL,
>        },
>        {
>                .mmc            = 3,
>                .wires          = 4,
>                .gpio_cd        = -EINVAL,
>                .gpio_wp        = -EINVAL,
>        },
>        {
>                .mmc            = 2,
>                .wires          = 4,
>                .gpio_cd        = -EINVAL,
>                .gpio_wp        = -EINVAL,
>                .transceiver    = true,
>                .ocr_mask       = 0x00100000,   /* 3.3V */
>        },
>        {}      /* Terminator */
> };
> </mmc_params>
>
> <twl_setup>
>
> static int overo_twl_gpio_setup(struct device *dev,
>                unsigned gpio, unsigned ngpio)
> {
>        twl4030_mmc_init(mmc);        <-- mmc params    passed to init
>
>        overo_vmmc1_supply.dev = mmc[0].dev;
>
>        return 0;
> }
> static struct twl4030_gpio_platform_data overo_gpio_data = {
>        .gpio_base      = OMAP_MAX_GPIO_LINES,
>        .irq_base       = TWL4030_GPIO_IRQ_BASE,
>        .irq_end        = TWL4030_GPIO_IRQ_END,
>        .setup          = overo_twl_gpio_setup,
> <-----    setup passed into the twl4030 gpio platform data
> };
>
> static struct twl4030_platform_data overo_twldata = {
>        .irq_base       = TWL4030_IRQ_BASE,
>        .irq_end        = TWL4030_IRQ_END,
>        .gpio           = &overo_gpio_data,
> <--- gpio data passed into twl4030 plat data
>        .usb            = &overo_usb_data,
>        .power          = GENERIC3430_T2SCRIPTS_DATA,
>        .vmmc1          = &overo_vmmc1,
> };
>
> static struct i2c_board_info __initdata overo_i2c_boardinfo[] = {
>        {
>                I2C_BOARD_INFO("tps65950", 0x48),
>                .flags = I2C_CLIENT_WAKE,
>                .irq = INT_34XX_SYS_NIRQ,
>                .platform_data = &overo_twldata,
>        },
> };
>
> static int __init overo_i2c_init(void)
> {
>        omap_register_i2c_bus(1, 2600, overo_i2c_boardinfo,
>                        ARRAY_SIZE(overo_i2c_boardinfo));
>        /* i2c2 pins are used for gpio */
>        omap_register_i2c_bus(3, 400, NULL, 0);
>        return 0;
> }
>
> // i2c_init called first in init.
> static void __init overo_init(void)
> {
>        overo_i2c_init();
>  .....
>  </twl_setup>
>
>
> So the way I see it working is i2c is initialized, which sets up the
> twl4030.  When the twl4030 configures gpio it initializes the mmc.
> mmc0 comes up fine (I have a root File System), but I never get a clk
> on mmc3.
>
> Any help would be greatly appreciated.
>
> Thanks
> John Sarman
>
--
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

Re: MMC3 Overo

[Paul Walmsley]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2045 bytes --]

Hello John,

you are using the PM branch, correct?

On Thu, 30 Jul 2009, John Sarman wrote:

> On Thu, Jul 30, 2009 at 11:49 AM, John Sarman<johnsarman@gmail.com> wrote:
> > I am trying to use mmc3 on the Overo Gumstix board with no luck.  I
> > have patched the kernel with the latest changes and have yet to see a
> > clk pulse, both before and after the patches.
> After adding some debugging printks, I have determined the mmc3 fails
> getting IRQ
> mmci-omap-hs mmci-omap-hs.0: Failed to get debounce clock
> REQUEST IRQ = 83 HOST = -812068416
> mmci-omap-hs mmci-omap-hs.1: Failed to get debounce clock
> REQUEST IRQ = 86 HOST = -812067392
> mmci-omap-hs mmci-omap-hs.2: Failed to get debounce clock
> REQUEST IRQ = 83 HOST = -812066368
> mmci-omap-hs mmci-omap-hs.2: Unable to grab HSMMC IRQ
> mmci-omap-hs mmci-omap-hs.2: Probe Failed
> mmci-omap-hs: probe of mmci-omap-hs.2 failed with error -16
> 
> For some reason mmc1 and mmc3 ask for the same interrupt 83 ???
> 
> Why would this be assigned the same value?

Developer error.  Does this patch fix it for you?


- Paul


From baca68c40ec3b391cdbfc0fb20ac5092b4ab7025 Mon Sep 17 00:00:00 2001
From: Paul Walmsley <paul@pwsan.com>
Date: Mon, 3 Aug 2009 04:18:45 +0300
Subject: [PATCH] OMAP3 hwmod: fix MMC3 IRQ

The MMC3 IRQ is incorrect in mach-omap2/omap_hwmod_34xx.h, which causes
MMC3 init to fail.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
---
 arch/arm/mach-omap2/omap_hwmod_34xx.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_34xx.h b/arch/arm/mach-omap2/omap_hwmod_34xx.h
index 29a2d60..56215bd 100644
--- a/arch/arm/mach-omap2/omap_hwmod_34xx.h
+++ b/arch/arm/mach-omap2/omap_hwmod_34xx.h
@@ -470,7 +470,7 @@ static struct omap_hwmod omap34xx_mmc2_hwmod = {
 static struct mmc_dev_attr mmc3_dev_attr;
 
 static u8 mmc3_mpu_irqs[] = {
-	INT_24XX_MMC_IRQ,
+	INT_34XX_MMC3_IRQ,
 };
 
 static struct omap_hwmod_dma_info mmc3_sdma_chs[] = {
-- 
1.6.3.GIT

Re: MMC3 Overo

[John Sarman]

Paul,

On Sun, Aug 2, 2009 at 9:20 PM, Paul Walmsley<paul@pwsan.com> wrote:
> Hello John,
>
> you are using the PM branch, correct?
  Unfortunately I am not using the pm patch, because I am stuck at
2.6.30-rc8.  This is because it is the last place I have usb host
working. I backported the necessary changes and pm wasn't an absolute
necessity, basically equivalent to not compiling in PM. I basically
used nearly every related patch after 6-6-09 - the 32 mmc patches.
>
> On Thu, 30 Jul 2009, John Sarman wrote:
>
>> On Thu, Jul 30, 2009 at 11:49 AM, John Sarman<johnsarman@gmail.com> wrote:
>> > I am trying to use mmc3 on the Overo Gumstix board with no luck.  I
>> > have patched the kernel with the latest changes and have yet to see a
>> > clk pulse, both before and after the patches.
>> After adding some debugging printks, I have determined the mmc3 fails
>> getting IRQ
>> mmci-omap-hs mmci-omap-hs.0: Failed to get debounce clock
>> REQUEST IRQ = 83 HOST = -812068416
>> mmci-omap-hs mmci-omap-hs.1: Failed to get debounce clock
>> REQUEST IRQ = 86 HOST = -812067392
>> mmci-omap-hs mmci-omap-hs.2: Failed to get debounce clock
>> REQUEST IRQ = 83 HOST = -812066368
>> mmci-omap-hs mmci-omap-hs.2: Unable to grab HSMMC IRQ
>> mmci-omap-hs mmci-omap-hs.2: Probe Failed
>> mmci-omap-hs: probe of mmci-omap-hs.2 failed with error -16
>>
>> For some reason mmc1 and mmc3 ask for the same interrupt 83 ???
>>
>> Why would this be assigned the same value?
>
> Developer error.  Does this patch fix it for you?
>
>
> - Paul
>
>
> From baca68c40ec3b391cdbfc0fb20ac5092b4ab7025 Mon Sep 17 00:00:00 2001
> From: Paul Walmsley <paul@pwsan.com>
> Date: Mon, 3 Aug 2009 04:18:45 +0300
> Subject: [PATCH] OMAP3 hwmod: fix MMC3 IRQ
>
> The MMC3 IRQ is incorrect in mach-omap2/omap_hwmod_34xx.h, which causes
> MMC3 init to fail.
>
> Signed-off-by: Paul Walmsley <paul@pwsan.com>
> ---
>  arch/arm/mach-omap2/omap_hwmod_34xx.h |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_34xx.h b/arch/arm/mach-omap2/omap_hwmod_34xx.h
> index 29a2d60..56215bd 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_34xx.h
> +++ b/arch/arm/mach-omap2/omap_hwmod_34xx.h
> @@ -470,7 +470,7 @@ static struct omap_hwmod omap34xx_mmc2_hwmod = {
>  static struct mmc_dev_attr mmc3_dev_attr;
>
>  static u8 mmc3_mpu_irqs[] = {
> -       INT_24XX_MMC_IRQ,
> +       INT_34XX_MMC3_IRQ,
>  };
>
>  static struct omap_hwmod_dma_info mmc3_sdma_chs[] = {
> --
> 1.6.3.GIT
>
Thanks for the patch, I will apply that and keep on testing.

John Sarman
--
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

Fwd: MMC3 Overo

[John Sarman]

On Mon, Aug 3, 2009 at 6:37 AM, Elvis Dowson<elvis.dowson@mac.com> wrote:
> Hi John,
>                 What does MMC3 on the Overo connect to?
MMC3 connects to one of the 70 pin bottom connectors.  The datasheet
states that MMC3 has no PBIAS circuit so you have to interface it with
1.8V logic.  I used a TXS0108 from TI as a level translator.
Datasheet states "The TXS0108E device is a semi-buffered
auto-direction-sensing voltage translator design is optimized for
translation applications (e.g. MMC Card Interfaces) that require the
system to start out in a low-speed open-drain mode and then switch to
a higher speed push-pull mode." So no need for transceiver control
with this IC.

>
> I am trying to get pm working on the overo, and I have a recipe for the
> overo for v.2.6.29 (which still has some issues with mmc1) and I have
> v2.6.31 latest kernel update recipe for overo that has both DSS2 and PM
> integrated.

Have you tested the USB host with 2.6.31 recipe yet?
Definitely would like the recipe for the v2.6.31. I have tested DSS2
on 2.6.30-rc8 and either I have a user error(most likely) or it wasn't
working.
I attempted to backport PM but as my main concern was for MMC. I
stopped after realizing it wasn't absolutely necessary to get the new
mmc patches to compile.

>
> I can share it with you if you like.
>
> Best regards,
>
> Elvis
>
>

John Sarman
--
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

Re: MMC3 Overo

[Paul Walmsley]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1255 bytes --]

On Mon, 3 Aug 2009, John Sarman wrote:

> On Sun, Aug 2, 2009 at 9:20 PM, Paul Walmsley<paul@pwsan.com> wrote:

> > From: Paul Walmsley <paul@pwsan.com>
> > Date: Mon, 3 Aug 2009 04:18:45 +0300
> > Subject: [PATCH] OMAP3 hwmod: fix MMC3 IRQ
> >
> > The MMC3 IRQ is incorrect in mach-omap2/omap_hwmod_34xx.h, which causes
> > MMC3 init to fail.
> >
> > Signed-off-by: Paul Walmsley <paul@pwsan.com>
> > ---
> >  arch/arm/mach-omap2/omap_hwmod_34xx.h |    2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/omap_hwmod_34xx.h b/arch/arm/mach-omap2/omap_hwmod_34xx.h
> > index 29a2d60..56215bd 100644
> > --- a/arch/arm/mach-omap2/omap_hwmod_34xx.h
> > +++ b/arch/arm/mach-omap2/omap_hwmod_34xx.h
> > @@ -470,7 +470,7 @@ static struct omap_hwmod omap34xx_mmc2_hwmod = {
> >  static struct mmc_dev_attr mmc3_dev_attr;
> >
> >  static u8 mmc3_mpu_irqs[] = {
> > -       INT_24XX_MMC_IRQ,
> > +       INT_34XX_MMC3_IRQ,
> >  };
> >
> >  static struct omap_hwmod_dma_info mmc3_sdma_chs[] = {
> > --
> > 1.6.3.GIT
> >
> Thanks for the patch, I will apply that and keep on testing.

I'm afraid that the patch will only be useful on a recent version of 
Kevin's PM branch.

- Paul

Re: MMC3 Overo

[John Sarman]

On Sun, Aug 2, 2009 at 9:20 PM, Paul Walmsley<paul@pwsan.com> wrote:
> Hello John,
>
> you are using the PM branch, correct?
>
> On Thu, 30 Jul 2009, John Sarman wrote:
>
>> On Thu, Jul 30, 2009 at 11:49 AM, John Sarman<johnsarman@gmail.com> wrote:
>> > I am trying to use mmc3 on the Overo Gumstix board with no luck.  I
>> > have patched the kernel with the latest changes and have yet to see a
>> > clk pulse, both before and after the patches.
>> After adding some debugging printks, I have determined the mmc3 fails
>> getting IRQ
>> mmci-omap-hs mmci-omap-hs.0: Failed to get debounce clock
>> REQUEST IRQ = 83 HOST = -812068416
>> mmci-omap-hs mmci-omap-hs.1: Failed to get debounce clock
>> REQUEST IRQ = 86 HOST = -812067392
>> mmci-omap-hs mmci-omap-hs.2: Failed to get debounce clock
>> REQUEST IRQ = 83 HOST = -812066368
>> mmci-omap-hs mmci-omap-hs.2: Unable to grab HSMMC IRQ
>> mmci-omap-hs mmci-omap-hs.2: Probe Failed
>> mmci-omap-hs: probe of mmci-omap-hs.2 failed with error -16
>>
>> For some reason mmc1 and mmc3 ask for the same interrupt 83 ???
>>
>> Why would this be assigned the same value?
>
> Developer error.  Does this patch fix it for you?
That fixed it.  However I still am not having success.   I have
tracked down my problem to the omap_hsmmc interrupt.  When the code
initializes with CMD8 the interrupt is triggered with a timeout.  I
have probed the SD 2G card on the CMD line and Clock line and I see
the  400Khz clock and transitions on the CMD line.  I am not 100% sure
it is not hardware but I seems to work all the way down the circuit up
to the SD card socket.  Tried several cards with same results.  Have
not captured the CMD stream and parsed it though.  (Still looking for
a datasheet to explain the signals of SD).  I read in the TRM and it
states the timeout is triggered when a command is sent and 64 clocks
occur without a response.
   Still going strong on it, but I would appreciate any tips.
John

>
>
> - Paul
>
>
> From baca68c40ec3b391cdbfc0fb20ac5092b4ab7025 Mon Sep 17 00:00:00 2001
> From: Paul Walmsley <paul@pwsan.com>
> Date: Mon, 3 Aug 2009 04:18:45 +0300
> Subject: [PATCH] OMAP3 hwmod: fix MMC3 IRQ
>
> The MMC3 IRQ is incorrect in mach-omap2/omap_hwmod_34xx.h, which causes
> MMC3 init to fail.
>
> Signed-off-by: Paul Walmsley <paul@pwsan.com>
> ---
>  arch/arm/mach-omap2/omap_hwmod_34xx.h |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_34xx.h b/arch/arm/mach-omap2/omap_hwmod_34xx.h
> index 29a2d60..56215bd 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_34xx.h
> +++ b/arch/arm/mach-omap2/omap_hwmod_34xx.h
> @@ -470,7 +470,7 @@ static struct omap_hwmod omap34xx_mmc2_hwmod = {
>  static struct mmc_dev_attr mmc3_dev_attr;
>
>  static u8 mmc3_mpu_irqs[] = {
> -       INT_24XX_MMC_IRQ,
> +       INT_34XX_MMC3_IRQ,
>  };
>
>  static struct omap_hwmod_dma_info mmc3_sdma_chs[] = {
> --
> 1.6.3.GIT
>
--
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

Re: MMC3 Overo

[Grazvydas Ignotas]

> <u-boot_snip>
>  MUX_VAL(CP(ETK_CLK_ES2),       (IDIS | PTU | EN  | M2)) /*MMC3_CLK*/\

You must have input enable on CLK line for MMC3 or it won't work for
some reason (MMC 1 and 2 doesn't need that). Without this part of the
host controller hardware doesn't get the clock I guess, or something
like that. You won't believe how much time we've wasted on this!
--
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

Fwd: MMC3 Overo

[John Sarman]

---------- Forwarded message ----------
From: John Sarman <johnsarman@gmail.com>
Date: Wed, Aug 5, 2009 at 12:01 PM
Subject: Re: MMC3 Overo
To: Grazvydas Ignotas <notasas@gmail.com>


On Wed, Aug 5, 2009 at 4:32 AM, Grazvydas Ignotas<notasas@gmail.com> wrote:
>> <u-boot_snip>
>>  MUX_VAL(CP(ETK_CLK_ES2),       (IDIS | PTU | EN  | M2)) /*MMC3_CLK*/\
>
> You must have input enable on CLK line for MMC3 or it won't work for
> some reason (MMC 1 and 2 doesn't need that). Without this part of the
> host controller hardware doesn't get the clock I guess, or something
> like that. You won't believe how much time we've wasted on this!
>
MUX_VAL(CP(ETK_CLK_ES2),       (IEN | PTU | EN  | M2)) /*MMC3_CLK*/\

Works Beautifully, Thank you so much.  I have also burnt too much
midnight oil on this problem.
So looks like Overo MMC3 works like a champ!
John Sarman
--
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

Re: Fwd: MMC3 Overo

[Kevin Hilman]

John Sarman <johnsarman@gmail.com> writes:

> ---------- Forwarded message ----------
> From: John Sarman <johnsarman@gmail.com>
> Date: Wed, Aug 5, 2009 at 12:01 PM
> Subject: Re: MMC3 Overo
> To: Grazvydas Ignotas <notasas@gmail.com>
>
>
> On Wed, Aug 5, 2009 at 4:32 AM, Grazvydas Ignotas<notasas@gmail.com> wrote:
>>> <u-boot_snip>
>>>  MUX_VAL(CP(ETK_CLK_ES2),       (IDIS | PTU | EN  | M2)) /*MMC3_CLK*/\
>>
>> You must have input enable on CLK line for MMC3 or it won't work for
>> some reason (MMC 1 and 2 doesn't need that). Without this part of the
>> host controller hardware doesn't get the clock I guess, or something
>> like that. You won't believe how much time we've wasted on this!
>>
> MUX_VAL(CP(ETK_CLK_ES2),       (IEN | PTU | EN  | M2)) /*MMC3_CLK*/\
>
> Works Beautifully, Thank you so much.  I have also burnt too much
> midnight oil on this problem.
> So looks like Overo MMC3 works like a champ!

Might I suggest a kernel patch for this rather than fixing u-boot so that
all the midnight oil you've burnt does not have to be duplicated by others.

Thanks,

Kevin
--
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

Re: Fwd: MMC3 Overo

[John Sarman]

On Wed, Aug 5, 2009 at 12:25 PM, Kevin
Hilman<khilman@deeprootsystems.com> wrote:
> John Sarman <johnsarman@gmail.com> writes:
>
>> ---------- Forwarded message ----------
>> From: John Sarman <johnsarman@gmail.com>
>> Date: Wed, Aug 5, 2009 at 12:01 PM
>> Subject: Re: MMC3 Overo
>> To: Grazvydas Ignotas <notasas@gmail.com>
>>
>>
>> On Wed, Aug 5, 2009 at 4:32 AM, Grazvydas Ignotas<notasas@gmail.com> wrote:
>>>> <u-boot_snip>
>>>>  MUX_VAL(CP(ETK_CLK_ES2),       (IDIS | PTU | EN  | M2)) /*MMC3_CLK*/\
>>>
>>> You must have input enable on CLK line for MMC3 or it won't work for
>>> some reason (MMC 1 and 2 doesn't need that). Without this part of the
>>> host controller hardware doesn't get the clock I guess, or something
>>> like that. You won't believe how much time we've wasted on this!
>>>
>> MUX_VAL(CP(ETK_CLK_ES2),       (IEN | PTU | EN  | M2)) /*MMC3_CLK*/\
>>
>> Works Beautifully, Thank you so much.  I have also burnt too much
>> midnight oil on this problem.
>> So looks like Overo MMC3 works like a champ!
>
> Might I suggest a kernel patch for this rather than fixing u-boot so that
> all the midnight oil you've burnt does not have to be duplicated by others.
Well I dont know how to answer that.  Because the Mux architecture is
slightly on the scary side.  I personally have had success with it,
but everytime you need to add a new pin functionality you have to
update mux.h.  I finally decided to just focus on having the MUX
correct at boot up via u-boot.

I could just add the code to update the mux without using the mux architecture.

I would appreciate some opinions on this.
>
> Thanks,
>
> Kevin
>
--
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

Re: Fwd: MMC3 Overo

[Steve Sakoman]

On Wed, Aug 5, 2009 at 9:35 AM, John Sarman<johnsarman@gmail.com> wrote:
> On Wed, Aug 5, 2009 at 12:25 PM, Kevin Hilman<khilman@deeprootsystems.com> wrote:
>> Might I suggest a kernel patch for this rather than fixing u-boot so that
>> all the midnight oil you've burnt does not have to be duplicated by others.
> Well I dont know how to answer that.  Because the Mux architecture is
> slightly on the scary side.  I personally have had success with it,
> but everytime you need to add a new pin functionality you have to
> update mux.h.  I finally decided to just focus on having the MUX
> correct at boot up via u-boot.
>
> I could just add the code to update the mux without using the mux architecture.
>
> I would appreciate some opinions on this.

I get discouraged every time I look at using kernel pinmuxing.  It
seems to assume that some mux settings are "standard" when in my
experience that is often not so.  So I face having to write code to
undo what it does (and face glitches on the gpio lines), or the bigger
task of restructuring the code to do the right thing.

And up to now in each case I shrug and say "no time to do that now,
I'll just leave kernel pinmuxing turned off and do it in u-boot"

Steve
--
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

RE: Fwd: MMC3 Overo

[Gadiyar, Anand]

Steve Sakoman wrote:
> On Wed, Aug 5, 2009 at 9:35 AM, John Sarman<johnsarman@gmail.com> wrote:
> > On Wed, Aug 5, 2009 at 12:25 PM, Kevin Hilman<khilman@deeprootsystems.com> wrote:
> >> Might I suggest a kernel patch for this rather than fixing u-boot so that
> >> all the midnight oil you've burnt does not have to be duplicated by others.
> > Well I dont know how to answer that.  Because the Mux architecture is
> > slightly on the scary side.  I personally have had success with it,
> > but everytime you need to add a new pin functionality you have to
> > update mux.h.  I finally decided to just focus on having the MUX
> > correct at boot up via u-boot.
> >
> > I could just add the code to update the mux without using the mux architecture.
> >
> > I would appreciate some opinions on this.
> 
> I get discouraged every time I look at using kernel pinmuxing.  It
> seems to assume that some mux settings are "standard" when in my
> experience that is often not so.  So I face having to write code to
> undo what it does (and face glitches on the gpio lines), or the bigger
> task of restructuring the code to do the right thing.
> 
> And up to now in each case I shrug and say "no time to do that now,
> I'll just leave kernel pinmuxing turned off and do it in u-boot"
> 

Does it make sense to do __ALL__ pin-muxing in the board-files for
a given board? That way, we have the pin-mux setting in the kernel,
plus a nice set of debug logs from CONFIG_MUX_DEBUG to tell if something
is not right, plus it's as good as doing it in u-boot anyway?

What say?

- Anand
--
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

Re: Fwd: MMC3 Overo

[Kevin Hilman]

Steve Sakoman wrote:
> On Wed, Aug 5, 2009 at 9:35 AM, John Sarman<johnsarman@gmail.com> wrote:
>> On Wed, Aug 5, 2009 at 12:25 PM, Kevin Hilman<khilman@deeprootsystems.com> wrote:
>>> Might I suggest a kernel patch for this rather than fixing u-boot so that
>>> all the midnight oil you've burnt does not have to be duplicated by others.
>> Well I dont know how to answer that.  Because the Mux architecture is
>> slightly on the scary side.  I personally have had success with it,
>> but everytime you need to add a new pin functionality you have to
>> update mux.h.  I finally decided to just focus on having the MUX
>> correct at boot up via u-boot.
>>
>> I could just add the code to update the mux without using the mux architecture.
>>
>> I would appreciate some opinions on this.
> 
> I get discouraged every time I look at using kernel pinmuxing.  It
> seems to assume that some mux settings are "standard" when in my
> experience that is often not so.  So I face having to write code to
> undo what it does (and face glitches on the gpio lines), or the bigger
> task of restructuring the code to do the right thing.
> 
> And up to now in each case I shrug and say "no time to do that now,
> I'll just leave kernel pinmuxing turned off and do it in u-boot"

I agree there are lots of shortcomings in the current mux code and we've 
been hitting them regularily lately.

That being said, for mux settings that done one-time only at boot, what 
are the problems you're running into?

All that should be necessary for a one-time setup is possibly adding and 
entry to mux.h and then calling omap_cfg_reg() in your board init code.

Kevin

Re: Fwd: MMC3 Overo

[Steve Sakoman]

On Wed, Aug 5, 2009 at 10:58 AM, Kevin
Hilman<khilman@deeprootsystems.com> wrote:
> Steve Sakoman wrote:
>> And up to now in each case I shrug and say "no time to do that now,
>> I'll just leave kernel pinmuxing turned off and do it in u-boot"
>
> I agree there are lots of shortcomings in the current mux code and we've
> been hitting them regularily lately.
>
> That being said, for mux settings that done one-time only at boot, what are
> the problems you're running into?

It's been a few months since I last encountered this, so the exact
details are a bit fuzzy.

I seem to recall that there were some basic issues with enabling
kernel pinmuxing in that some of the setup that was done for all
machines was just wrong for my particular machine.  IIRC, it was due
to assumptions about which pad was used for a particular function (for
those functions which can be steered to multiple GPIO pads).

So I faced having to undo that change in my board file as well as any
issues that may have arisen from glitches on the GPIO pins during the
process.  And since there were several of these I gave up and turned
off kernel pinmuxing.

I'd be happy if we cleaned up the "one size fits all" pinmuxing to
just that subset that truly does fit all boards, and leave the rest to
the board files.  I'd also be content to have it all done in the board
file for each machine.

Steve

Re: Fwd: MMC3 Overo

[Kevin Hilman]

Steve Sakoman wrote:
> On Wed, Aug 5, 2009 at 10:58 AM, Kevin
> Hilman<khilman@deeprootsystems.com> wrote:
>> Steve Sakoman wrote:
>>> And up to now in each case I shrug and say "no time to do that now,
>>> I'll just leave kernel pinmuxing turned off and do it in u-boot"
>> I agree there are lots of shortcomings in the current mux code and we've
>> been hitting them regularily lately.
>>
>> That being said, for mux settings that done one-time only at boot, what are
>> the problems you're running into?
> 
> It's been a few months since I last encountered this, so the exact
> details are a bit fuzzy.
> 
> I seem to recall that there were some basic issues with enabling
> kernel pinmuxing in that some of the setup that was done for all
> machines was just wrong for my particular machine.  IIRC, it was due
> to assumptions about which pad was used for a particular function (for
> those functions which can be steered to multiple GPIO pads).
> 
> So I faced having to undo that change in my board file as well as any
> issues that may have arisen from glitches on the GPIO pins during the
> process.  And since there were several of these I gave up and turned
> off kernel pinmuxing.
> 
> I'd be happy if we cleaned up the "one size fits all" pinmuxing to
> just that subset that truly does fit all boards, and leave the rest to
> the board files.  I'd also be content to have it all done in the board
> file for each machine.

Indeed, any assumptions about common muxing that are not indeed common 
are bugs and should be fixed.

The "right" solution is to have everything in the kernel, and split 
across SoC "common" init and board specific init.  Of course u-boot
will still have to do some early muxing, but it should be redone in
the kernel so it's trivial to change bootloaders.

So the real missing piece is someone to step up and rework the mux code.
The bigger problem is that the vast majority of folks don't care about 
the common case and only care about getting thing working for a specific 
platform.

Kevin

Re: Fwd: MMC3 Overo

[Philip Balister]

[-- Attachment #1: Type: text/plain, Size: 3164 bytes --]

Kevin Hilman wrote:
> Steve Sakoman wrote:
>> On Wed, Aug 5, 2009 at 10:58 AM, Kevin
>> Hilman<khilman@deeprootsystems.com> wrote:
>>> Steve Sakoman wrote:
>>>> And up to now in each case I shrug and say "no time to do that now,
>>>> I'll just leave kernel pinmuxing turned off and do it in u-boot"
>>> I agree there are lots of shortcomings in the current mux code and we've
>>> been hitting them regularily lately.
>>>
>>> That being said, for mux settings that done one-time only at boot, 
>>> what are
>>> the problems you're running into?
>>
>> It's been a few months since I last encountered this, so the exact
>> details are a bit fuzzy.
>>
>> I seem to recall that there were some basic issues with enabling
>> kernel pinmuxing in that some of the setup that was done for all
>> machines was just wrong for my particular machine.  IIRC, it was due
>> to assumptions about which pad was used for a particular function (for
>> those functions which can be steered to multiple GPIO pads).
>>
>> So I faced having to undo that change in my board file as well as any
>> issues that may have arisen from glitches on the GPIO pins during the
>> process.  And since there were several of these I gave up and turned
>> off kernel pinmuxing.
>>
>> I'd be happy if we cleaned up the "one size fits all" pinmuxing to
>> just that subset that truly does fit all boards, and leave the rest to
>> the board files.  I'd also be content to have it all done in the board
>> file for each machine.
> 
> Indeed, any assumptions about common muxing that are not indeed common 
> are bugs and should be fixed.
> 
> The "right" solution is to have everything in the kernel, and split 
> across SoC "common" init and board specific init.  Of course u-boot
> will still have to do some early muxing, but it should be redone in
> the kernel so it's trivial to change bootloaders.
> 
> So the real missing piece is someone to step up and rework the mux code.
> The bigger problem is that the vast majority of folks don't care about 
> the common case and only care about getting thing working for a specific 
> platform.

I posted some changes to add support for changing the Beagle expansion 
connector MCSPI muxing in the board file and some general muxing 
questions and received no comments (OK, a number of people were on 
vacation). If people would like I can repost it to aid in discussion.

I agree we need to more muxing in the kernel and less in u-boot. I do 
not want a different u-boot for the Beagle based on what I have 
connected to the expansion connector. (Same applies to the Overo)

The current mux requires you make an entry in an enum, then a 
corresponding entry in an array to configure the pin. SO the enum length 
is basically number of pins * the number of possible pin configurations.

There is no way to account for the different packages the OMAP3 is 
available in.

Is the code omap specific, or is it shared with other chips?

Philip

> 
> Kevin
> -- 
> 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
> 

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3303 bytes --]

Re: Fwd: MMC3 Overo

[Hunyue Yau]

On Wednesday 05 August 2009 11:55, Philip Balister wrote:
> Kevin Hilman wrote:
> > Steve Sakoman wrote:
> >> On Wed, Aug 5, 2009 at 10:58 AM, Kevin
> >>
> >> Hilman<khilman@deeprootsystems.com> wrote:
> >>> Steve Sakoman wrote:
> >>>> And up to now in each case I shrug and say "no time to do that now,
> >>>> I'll just leave kernel pinmuxing turned off and do it in u-boot"
> >>>
> >>> I agree there are lots of shortcomings in the current mux code and
> >>> we've been hitting them regularily lately.
> >>>
> >>> That being said, for mux settings that done one-time only at boot,
> >>> what are
> >>> the problems you're running into?
> >>
> >> It's been a few months since I last encountered this, so the exact
> >> details are a bit fuzzy.
> >>
> >> I seem to recall that there were some basic issues with enabling
> >> kernel pinmuxing in that some of the setup that was done for all
> >> machines was just wrong for my particular machine.  IIRC, it was due
> >> to assumptions about which pad was used for a particular function (for
> >> those functions which can be steered to multiple GPIO pads).
> >>
> >> So I faced having to undo that change in my board file as well as any
> >> issues that may have arisen from glitches on the GPIO pins during the
> >> process.  And since there were several of these I gave up and turned
> >> off kernel pinmuxing.
> >>
> >> I'd be happy if we cleaned up the "one size fits all" pinmuxing to
> >> just that subset that truly does fit all boards, and leave the rest to
> >> the board files.  I'd also be content to have it all done in the board
> >> file for each machine.
> >
> > Indeed, any assumptions about common muxing that are not indeed common
> > are bugs and should be fixed.
> >
> > The "right" solution is to have everything in the kernel, and split
> > across SoC "common" init and board specific init.  Of course u-boot
> > will still have to do some early muxing, but it should be redone in
> > the kernel so it's trivial to change bootloaders.
> >
> > So the real missing piece is someone to step up and rework the mux code.
> > The bigger problem is that the vast majority of folks don't care about
> > the common case and only care about getting thing working for a specific
> > platform.
>
> I posted some changes to add support for changing the Beagle expansion
> connector MCSPI muxing in the board file and some general muxing
> questions and received no comments (OK, a number of people were on
> vacation). If people would like I can repost it to aid in discussion.
>
> I agree we need to more muxing in the kernel and less in u-boot. I do
> not want a different u-boot for the Beagle based on what I have
> connected to the expansion connector. (Same applies to the Overo)

It is worse then that. Doing it in U-boot implies a static mux config. I can 
see cases where there is a need to change the mux config during run time. For 
example on the OMAP3 Beagle board platform, there is an LCD connector with a 
signals that is shared with the onboard DVI framer and potentially an 
external LCD. Due to the limited number of signals, some of the shared lines 
might be used for a different function when the LCD is active but have to 
revert to the DSS control if the DVI framer is used. This would require the 
mux be dynamically programmable. 


>
> The current mux requires you make an entry in an enum, then a
> corresponding entry in an array to configure the pin. SO the enum length
> is basically number of pins * the number of possible pin configurations.
>
> There is no way to account for the different packages the OMAP3 is
> available in.
>
> Is the code omap specific, or is it shared with other chips?

My understanding iis the code is OMAP specific. OMAP2 and OMAP3 are very 
similar. 

One idea that was thrown around on the Beagle IRC channel is to replace this 
code with an API that would solve the scaling problem. Something like this:

omap_pinmux_config( PACKAGE_PIN_ID, MODE_N, INPUT_EN | PULL_UP ); 

Where PACKAGE_PIN_ID would be a #define or an enum used to map to a register. 
The name should encode the packagename and the pin/ball. This avoids the 
current confusion as the current enums do not indicate what package. 

The MODE_N is an ID to indicate which mode the pin should be put into.

INPUT_EN|PULL_UP are the options for the ball. 

For ease of integrating with existing code, #defines matching the current enum 
name can be created to map them the options. Such a define would also add 
back self documenting feature of the enum names.  

This is a very crude proposal but does this sound like something better? The 
other unknown is I am not familiar enough with the OMAP1 pinmux to know if 
this would work. 

>
> Philip
>
> > Kevin
> > --
> > 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

-- 
Hunyue Yau

MMC3 Overo

[John Sarman]

On Wed, Aug 5, 2009 at 2:35 PM, Kevin Hilman<khilman@deeprootsystems.com> wrote:
> Steve Sakoman wrote:
>>
>> On Wed, Aug 5, 2009 at 10:58 AM, Kevin
>> Hilman<khilman@deeprootsystems.com> wrote:
>>>
>>> Steve Sakoman wrote:
>>>>
>>>> And up to now in each case I shrug and say "no time to do that now,
>>>> I'll just leave kernel pinmuxing turned off and do it in u-boot"
>>>
>>> I agree there are lots of shortcomings in the current mux code and we've
>>> been hitting them regularily lately.
>>>
>>> That being said, for mux settings that done one-time only at boot, what
>>> are
>>> the problems you're running into?
>>
>> It's been a few months since I last encountered this, so the exact
>> details are a bit fuzzy.
>>
>> I seem to recall that there were some basic issues with enabling
>> kernel pinmuxing in that some of the setup that was done for all
>> machines was just wrong for my particular machine.  IIRC, it was due
>> to assumptions about which pad was used for a particular function (for
>> those functions which can be steered to multiple GPIO pads).
>>
>> So I faced having to undo that change in my board file as well as any
>> issues that may have arisen from glitches on the GPIO pins during the
>> process.  And since there were several of these I gave up and turned
>> off kernel pinmuxing.
>>
>> I'd be happy if we cleaned up the "one size fits all" pinmuxing to
>> just that subset that truly does fit all boards, and leave the rest to
>> the board files.  I'd also be content to have it all done in the board
>> file for each machine.
>
> Indeed, any assumptions about common muxing that are not indeed common are
> bugs and should be fixed.
>
> The "right" solution is to have everything in the kernel, and split across
> SoC "common" init and board specific init.  Of course u-boot
> will still have to do some early muxing, but it should be redone in
> the kernel so it's trivial to change bootloaders.
>
> So the real missing piece is someone to step up and rework the mux code.
> The bigger problem is that the vast majority of folks don't care about the
> common case and only care about getting thing working for a specific
> platform.
>
> Kevin
>
I  like the idea of having the board file configure the mux.  First of
all lets address the shortcomings of mux.h.  The Pin values are
labeled as so:
<snip from mux.h>
* NOTE: Please use the following naming style for new pin entries.
 *       For example, W8_1610_MMC2_DAT0, where:
 *       - W8        = ball
 *       - 1610      = 1510 or 1610, none if common for both 1510 and 1610
 *       - MMC2_DAT0 = function

But lets take the 3530 as an example.
 The 3530 has three separate packages.  CBB, CBC, and CUS.  Now lets
look at MMC3_clk (the root of my original problem that started this
thread)
                       CBB              CBC            CUS
mmc3_clk         AB1 / AF10    R9 / AB2     AC1

So to properly add these to mux.h we need to add 5 entries for mmc3_clk
      AB1_35XXCBB_MMC3_CLK
      AF10_35XXCBB_MMC3_CLK
      R9_35XXCBC_MMC3_CLK
      AB2_35XXCBC_MMC3_CLK
      AC1_35XXCUS_MMC3_CLK
We would then have to update mux.c making sure the position matches
and add the proper settings.

So this is obviously a maintenance nightmare.

Another option is to add a CONFIG_35XX_CBB or CBC or CUS when selecting a board
 example in menuconfig selecting MACH_OVERO would select  CONFIG_35XX_CBB.
Then in a new mux_35xx.h located in the mach_omap2 folder have
 #ifdef CONFIG_35XX_CBB
 //all muxable balls
  #define N4       0x078
  #define AB1     0x164
 etc .....
 #endif
where we just use the Ball name defined as its offset in the 35xx case

then we create a file say board_overo_mux.c

  in it we call
  configure_pin(AB1, MODE3, INPUT | PU | PE);
  for every ball that is muxable.

voila,  we have a predefined limit of pins so once mux_35xx.h is fully
defined, and the driver code is in place then the only thing that a
developer would need to do to leverage the mux is edit his board file.

Im sure I have glossed ove many details but this is a general outline.
--
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

Re: MMC3 Overo

[Tony Lindgren]

* John Sarman <johnsarman@gmail.com> [090806 05:11]:
> On Wed, Aug 5, 2009 at 2:35 PM, Kevin Hilman<khilman@deeprootsystems.com> wrote:
> > Steve Sakoman wrote:
> >>
> >> On Wed, Aug 5, 2009 at 10:58 AM, Kevin
> >> Hilman<khilman@deeprootsystems.com> wrote:
> >>>
> >>> Steve Sakoman wrote:
> >>>>
> >>>> And up to now in each case I shrug and say "no time to do that now,
> >>>> I'll just leave kernel pinmuxing turned off and do it in u-boot"
> >>>
> >>> I agree there are lots of shortcomings in the current mux code and we've
> >>> been hitting them regularily lately.
> >>>
> >>> That being said, for mux settings that done one-time only at boot, what
> >>> are
> >>> the problems you're running into?
> >>
> >> It's been a few months since I last encountered this, so the exact
> >> details are a bit fuzzy.
> >>
> >> I seem to recall that there were some basic issues with enabling
> >> kernel pinmuxing in that some of the setup that was done for all
> >> machines was just wrong for my particular machine.  IIRC, it was due
> >> to assumptions about which pad was used for a particular function (for
> >> those functions which can be steered to multiple GPIO pads).
> >>
> >> So I faced having to undo that change in my board file as well as any
> >> issues that may have arisen from glitches on the GPIO pins during the
> >> process.  And since there were several of these I gave up and turned
> >> off kernel pinmuxing.
> >>
> >> I'd be happy if we cleaned up the "one size fits all" pinmuxing to
> >> just that subset that truly does fit all boards, and leave the rest to
> >> the board files.  I'd also be content to have it all done in the board
> >> file for each machine.
> >
> > Indeed, any assumptions about common muxing that are not indeed common are
> > bugs and should be fixed.
> >
> > The "right" solution is to have everything in the kernel, and split across
> > SoC "common" init and board specific init.  Of course u-boot
> > will still have to do some early muxing, but it should be redone in
> > the kernel so it's trivial to change bootloaders.
> >
> > So the real missing piece is someone to step up and rework the mux code.
> > The bigger problem is that the vast majority of folks don't care about the
> > common case and only care about getting thing working for a specific
> > platform.
> >
> > Kevin
> >
> I  like the idea of having the board file configure the mux.  First of
> all lets address the shortcomings of mux.h.  The Pin values are
> labeled as so:
> <snip from mux.h>
> * NOTE: Please use the following naming style for new pin entries.
>  *       For example, W8_1610_MMC2_DAT0, where:
>  *       - W8        = ball
>  *       - 1610      = 1510 or 1610, none if common for both 1510 and 1610
>  *       - MMC2_DAT0 = function
> 
> But lets take the 3530 as an example.
>  The 3530 has three separate packages.  CBB, CBC, and CUS.  Now lets
> look at MMC3_clk (the root of my original problem that started this
> thread)
>                        CBB              CBC            CUS
> mmc3_clk         AB1 / AF10    R9 / AB2     AC1
> 
> So to properly add these to mux.h we need to add 5 entries for mmc3_clk
>       AB1_35XXCBB_MMC3_CLK
>       AF10_35XXCBB_MMC3_CLK
>       R9_35XXCBC_MMC3_CLK
>       AB2_35XXCBC_MMC3_CLK
>       AC1_35XXCUS_MMC3_CLK
> We would then have to update mux.c making sure the position matches
> and add the proper settings.
> 
> So this is obviously a maintenance nightmare.
> 
> Another option is to add a CONFIG_35XX_CBB or CBC or CUS when selecting a board
>  example in menuconfig selecting MACH_OVERO would select  CONFIG_35XX_CBB.
> Then in a new mux_35xx.h located in the mach_omap2 folder have
>  #ifdef CONFIG_35XX_CBB
>  //all muxable balls
>   #define N4       0x078
>   #define AB1     0x164
>  etc .....
>  #endif
> where we just use the Ball name defined as its offset in the 35xx case

Yeah we need to improve the mux code as discussed many times earlier, it's
been limping along since the 15xx days, and now that the mux hardware does
not have the mux configuration registers all over the place we can simplify
it for later omaps.

But doing things with Kconfig won't work as we support compiling in multiple
boards and omaps. It needs to be done dynamically in in the board-*.c files.

> 
> then we create a file say board_overo_mux.c
> 
>   in it we call
>   configure_pin(AB1, MODE3, INPUT | PU | PE);
>   for every ball that is muxable.

For the sensible configurations we already have these defines mux.h:

/* 34xx active pin states */
#define OMAP34XX_PIN_OUTPUT		0
#define OMAP34XX_PIN_INPUT		OMAP3_INPUT_EN
#define OMAP34XX_PIN_INPUT_PULLUP	(OMAP2_PULL_ENA | OMAP3_INPUT_EN \
						| OMAP2_PULL_UP)
#define OMAP34XX_PIN_INPUT_PULLDOWN	(OMAP2_PULL_ENA | OMAP3_INPUT_EN)

/* 34xx off mode states */
#define OMAP34XX_PIN_OFF_NONE           0
#define OMAP34XX_PIN_OFF_OUTPUT_HIGH	(OMAP3_OFF_EN | OMAP3_OFFOUT_EN \
						| OMAP3_OFFOUT_VAL)
#define OMAP34XX_PIN_OFF_OUTPUT_LOW	(OMAP3_OFF_EN | OMAP3_OFFOUT_EN)
#define OMAP34XX_PIN_OFF_INPUT_PULLUP	(OMAP3_OFF_EN | OMAP3_OFF_PULL_EN \
						| OMAP3_OFF_PULL_UP)
#define OMAP34XX_PIN_OFF_INPUT_PULLDOWN	(OMAP3_OFF_EN | OMAP3_OFF_PULL_EN)
#define OMAP34XX_PIN_OFF_WAKEUPENABLE	OMAP3_WAKEUP_EN

So I'd rather stick with those because otherwise we easily end up with
wrong combinations. Of course the naming could be more generic there :)

Regards,

Tony

 
> voila,  we have a predefined limit of pins so once mux_35xx.h is fully
> defined, and the driver code is in place then the only thing that a
> developer would need to do to leverage the mux is edit his board file.
> 
> Im sure I have glossed ove many details but this is a general outline.
> --
> 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
--
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

Re: MMC3 Overo

[Kevin Hilman]

John Sarman <johnsarman@gmail.com> writes:

> On Wed, Aug 5, 2009 at 2:35 PM, Kevin Hilman<khilman@deeprootsystems.com> wrote:
>> Steve Sakoman wrote:
>>>
>>> On Wed, Aug 5, 2009 at 10:58 AM, Kevin
>>> Hilman<khilman@deeprootsystems.com> wrote:
>>>>
>>>> Steve Sakoman wrote:
>>>>>
>>>>> And up to now in each case I shrug and say "no time to do that now,
>>>>> I'll just leave kernel pinmuxing turned off and do it in u-boot"
>>>>
>>>> I agree there are lots of shortcomings in the current mux code and we've
>>>> been hitting them regularily lately.
>>>>
>>>> That being said, for mux settings that done one-time only at boot, what
>>>> are
>>>> the problems you're running into?
>>>
>>> It's been a few months since I last encountered this, so the exact
>>> details are a bit fuzzy.
>>>
>>> I seem to recall that there were some basic issues with enabling
>>> kernel pinmuxing in that some of the setup that was done for all
>>> machines was just wrong for my particular machine.  IIRC, it was due
>>> to assumptions about which pad was used for a particular function (for
>>> those functions which can be steered to multiple GPIO pads).
>>>
>>> So I faced having to undo that change in my board file as well as any
>>> issues that may have arisen from glitches on the GPIO pins during the
>>> process.  And since there were several of these I gave up and turned
>>> off kernel pinmuxing.
>>>
>>> I'd be happy if we cleaned up the "one size fits all" pinmuxing to
>>> just that subset that truly does fit all boards, and leave the rest to
>>> the board files.  I'd also be content to have it all done in the board
>>> file for each machine.
>>
>> Indeed, any assumptions about common muxing that are not indeed common are
>> bugs and should be fixed.
>>
>> The "right" solution is to have everything in the kernel, and split across
>> SoC "common" init and board specific init.  Of course u-boot
>> will still have to do some early muxing, but it should be redone in
>> the kernel so it's trivial to change bootloaders.
>>
>> So the real missing piece is someone to step up and rework the mux code.
>> The bigger problem is that the vast majority of folks don't care about the
>> common case and only care about getting thing working for a specific
>> platform.
>>
>> Kevin
>>
> I  like the idea of having the board file configure the mux.  First of
> all lets address the shortcomings of mux.h.  The Pin values are
> labeled as so:
> <snip from mux.h>
> * NOTE: Please use the following naming style for new pin entries.
>  *       For example, W8_1610_MMC2_DAT0, where:
>  *       - W8        = ball
>  *       - 1610      = 1510 or 1610, none if common for both 1510 and 1610
>  *       - MMC2_DAT0 = function
>
> But lets take the 3530 as an example.
>  The 3530 has three separate packages.  CBB, CBC, and CUS.  Now lets
> look at MMC3_clk (the root of my original problem that started this
> thread)
>                        CBB              CBC            CUS
> mmc3_clk         AB1 / AF10    R9 / AB2     AC1
>
> So to properly add these to mux.h we need to add 5 entries for mmc3_clk
>       AB1_35XXCBB_MMC3_CLK
>       AF10_35XXCBB_MMC3_CLK
>       R9_35XXCBC_MMC3_CLK
>       AB2_35XXCBC_MMC3_CLK
>       AC1_35XXCUS_MMC3_CLK
> We would then have to update mux.c making sure the position matches
> and add the proper settings.
>
> So this is obviously a maintenance nightmare.

So why don't we drop the ball (pun intended.) ;)

This is what I proposed to Phillip Ballister for his SPI changes for Beagle.

Though I haven't looked at the details for each package, I have a hard
time imagining that the reg offsets and functionality for each package
is different.  In fact, I'm pretty sure they're even the same between
34xx and 35xx.  

IOW, why not just name it OMAP3_MMC3_CLK and have a single entry.

Then each board file that cares simply has to call omap_cfg_reg() on
that name and not care about the package.

Kevin

--
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

Re: MMC3 Overo

[Vladimir Pantelic]

Kevin Hilman wrote:

>>         AB1_35XXCBB_MMC3_CLK
>>         AF10_35XXCBB_MMC3_CLK
>>         R9_35XXCBC_MMC3_CLK
>>         AB2_35XXCBC_MMC3_CLK
>>         AC1_35XXCUS_MMC3_CLK
>>  We would then have to update mux.c making sure the position matches
>>  and add the proper settings.
>>
>>  So this is obviously a maintenance nightmare.
>
> So why don't we drop the ball (pun intended.) ;)
>
> This is what I proposed to Phillip Ballister for his SPI changes for Beagle.
>
> Though I haven't looked at the details for each package, I have a hard
> time imagining that the reg offsets and functionality for each package
> is different.  In fact, I'm pretty sure they're even the same between
> 34xx and 35xx.
>
> IOW, why not just name it OMAP3_MMC3_CLK and have a single entry.
>
> Then each board file that cares simply has to call omap_cfg_reg() on
> that name and not care about the package.

even for 1 package, how will you know whether OMAP3_MMC3_CLK is connected
to ball AB1 or AF10 as both is possible...

Re: MMC3 Overo

[Kevin Hilman]

Vladimir Pantelic <pan@nt.tu-darmstadt.de> writes:

> Kevin Hilman wrote:
>
>>>         AB1_35XXCBB_MMC3_CLK
>>>         AF10_35XXCBB_MMC3_CLK
>>>         R9_35XXCBC_MMC3_CLK
>>>         AB2_35XXCBC_MMC3_CLK
>>>         AC1_35XXCUS_MMC3_CLK
>>>  We would then have to update mux.c making sure the position matches
>>>  and add the proper settings.
>>>
>>>  So this is obviously a maintenance nightmare.
>>
>> So why don't we drop the ball (pun intended.) ;)
>>
>> This is what I proposed to Phillip Ballister for his SPI changes for Beagle.
>>
>> Though I haven't looked at the details for each package, I have a hard
>> time imagining that the reg offsets and functionality for each package
>> is different.  In fact, I'm pretty sure they're even the same between
>> 34xx and 35xx.
>>
>> IOW, why not just name it OMAP3_MMC3_CLK and have a single entry.
>>
>> Then each board file that cares simply has to call omap_cfg_reg() on
>> that name and not care about the package.
>
> even for 1 package, how will you know whether OMAP3_MMC3_CLK is connected
> to ball AB1 or AF10 as both is possible...

doh! good point.  I was thinking of functions that are only availble
on a single ball.  

/me resolves to finish waking up before thinking more about mux issues

Kevin

Re: MMC3 Overo

[Steve Sakoman]

On Thu, Aug 6, 2009 at 8:16 AM, Kevin Hilman<khilman@deeprootsystems.com> wrote:

>> even for 1 package, how will you know whether OMAP3_MMC3_CLK is connected
>> to ball AB1 or AF10 as both is possible...
>
> doh! good point.  I was thinking of functions that are only availble
> on a single ball.

This is the point I was (unsuccessfully) trying to make in my original
response :-)  It was the main source of my frustration, since Overo
seemed to pick "the other" choice of ball far too often.  It made
using kernel pinmuxing a nightmare.

Steve
--
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

Re: MMC3 Overo

[Philip Balister]

[-- Attachment #1: Type: text/plain, Size: 4355 bytes --]

Kevin Hilman wrote:
> John Sarman <johnsarman@gmail.com> writes:
> 
>> On Wed, Aug 5, 2009 at 2:35 PM, Kevin Hilman<khilman@deeprootsystems.com> wrote:
>>> Steve Sakoman wrote:
>>>> On Wed, Aug 5, 2009 at 10:58 AM, Kevin
>>>> Hilman<khilman@deeprootsystems.com> wrote:
>>>>> Steve Sakoman wrote:
>>>>>> And up to now in each case I shrug and say "no time to do that now,
>>>>>> I'll just leave kernel pinmuxing turned off and do it in u-boot"
>>>>> I agree there are lots of shortcomings in the current mux code and we've
>>>>> been hitting them regularily lately.
>>>>>
>>>>> That being said, for mux settings that done one-time only at boot, what
>>>>> are
>>>>> the problems you're running into?
>>>> It's been a few months since I last encountered this, so the exact
>>>> details are a bit fuzzy.
>>>>
>>>> I seem to recall that there were some basic issues with enabling
>>>> kernel pinmuxing in that some of the setup that was done for all
>>>> machines was just wrong for my particular machine.  IIRC, it was due
>>>> to assumptions about which pad was used for a particular function (for
>>>> those functions which can be steered to multiple GPIO pads).
>>>>
>>>> So I faced having to undo that change in my board file as well as any
>>>> issues that may have arisen from glitches on the GPIO pins during the
>>>> process.  And since there were several of these I gave up and turned
>>>> off kernel pinmuxing.
>>>>
>>>> I'd be happy if we cleaned up the "one size fits all" pinmuxing to
>>>> just that subset that truly does fit all boards, and leave the rest to
>>>> the board files.  I'd also be content to have it all done in the board
>>>> file for each machine.
>>> Indeed, any assumptions about common muxing that are not indeed common are
>>> bugs and should be fixed.
>>>
>>> The "right" solution is to have everything in the kernel, and split across
>>> SoC "common" init and board specific init.  Of course u-boot
>>> will still have to do some early muxing, but it should be redone in
>>> the kernel so it's trivial to change bootloaders.
>>>
>>> So the real missing piece is someone to step up and rework the mux code.
>>> The bigger problem is that the vast majority of folks don't care about the
>>> common case and only care about getting thing working for a specific
>>> platform.
>>>
>>> Kevin
>>>
>> I  like the idea of having the board file configure the mux.  First of
>> all lets address the shortcomings of mux.h.  The Pin values are
>> labeled as so:
>> <snip from mux.h>
>> * NOTE: Please use the following naming style for new pin entries.
>>  *       For example, W8_1610_MMC2_DAT0, where:
>>  *       - W8        = ball
>>  *       - 1610      = 1510 or 1610, none if common for both 1510 and 1610
>>  *       - MMC2_DAT0 = function
>>
>> But lets take the 3530 as an example.
>>  The 3530 has three separate packages.  CBB, CBC, and CUS.  Now lets
>> look at MMC3_clk (the root of my original problem that started this
>> thread)
>>                        CBB              CBC            CUS
>> mmc3_clk         AB1 / AF10    R9 / AB2     AC1
>>
>> So to properly add these to mux.h we need to add 5 entries for mmc3_clk
>>       AB1_35XXCBB_MMC3_CLK
>>       AF10_35XXCBB_MMC3_CLK
>>       R9_35XXCBC_MMC3_CLK
>>       AB2_35XXCBC_MMC3_CLK
>>       AC1_35XXCUS_MMC3_CLK
>> We would then have to update mux.c making sure the position matches
>> and add the proper settings.
>>
>> So this is obviously a maintenance nightmare.
> 
> So why don't we drop the ball (pun intended.) ;)
> 
> This is what I proposed to Phillip Ballister for his SPI changes for Beagle.
> 
> Though I haven't looked at the details for each package, I have a hard
> time imagining that the reg offsets and functionality for each package
> is different.  In fact, I'm pretty sure they're even the same between
> 34xx and 35xx.  
> 
> IOW, why not just name it OMAP3_MMC3_CLK and have a single entry.
> 
> Then each board file that cares simply has to call omap_cfg_reg() on
> that name and not care about the package.

They first problem I see is the MMC3_CLK is available on multiple balls, 
so the mux files need to list them all.

Unless you are proposing custom mux files for each board? Is this is 
good idea (just had this thought). In other words, instead of trying to 
come up with one set of mux files, make them board specific.

Philip

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3303 bytes --]

Re: MMC3 Overo

[Peter Barada]

On Thu, 2009-08-06 at 11:09 -0400, Philip Balister wrote:
> Kevin Hilman wrote:
> > John Sarman <johnsarman@gmail.com> writes:
> > 
> >> On Wed, Aug 5, 2009 at 2:35 PM, Kevin Hilman<khilman@deeprootsystems.com> wrote:
> >>> Steve Sakoman wrote:
> >>>> On Wed, Aug 5, 2009 at 10:58 AM, Kevin
> >>>> Hilman<khilman@deeprootsystems.com> wrote:
> >>>>> Steve Sakoman wrote:
> >>>>>> And up to now in each case I shrug and say "no time to do that now,
> >>>>>> I'll just leave kernel pinmuxing turned off and do it in u-boot"
> >>>>> I agree there are lots of shortcomings in the current mux code and we've
> >>>>> been hitting them regularily lately.
> >>>>>
> >>>>> That being said, for mux settings that done one-time only at boot, what
> >>>>> are
> >>>>> the problems you're running into?
> >>>> It's been a few months since I last encountered this, so the exact
> >>>> details are a bit fuzzy.
> >>>>
> >>>> I seem to recall that there were some basic issues with enabling
> >>>> kernel pinmuxing in that some of the setup that was done for all
> >>>> machines was just wrong for my particular machine.  IIRC, it was due
> >>>> to assumptions about which pad was used for a particular function (for
> >>>> those functions which can be steered to multiple GPIO pads).
> >>>>
> >>>> So I faced having to undo that change in my board file as well as any
> >>>> issues that may have arisen from glitches on the GPIO pins during the
> >>>> process.  And since there were several of these I gave up and turned
> >>>> off kernel pinmuxing.
> >>>>
> >>>> I'd be happy if we cleaned up the "one size fits all" pinmuxing to
> >>>> just that subset that truly does fit all boards, and leave the rest to
> >>>> the board files.  I'd also be content to have it all done in the board
> >>>> file for each machine.
> >>> Indeed, any assumptions about common muxing that are not indeed common are
> >>> bugs and should be fixed.
> >>>
> >>> The "right" solution is to have everything in the kernel, and split across
> >>> SoC "common" init and board specific init.  Of course u-boot
> >>> will still have to do some early muxing, but it should be redone in
> >>> the kernel so it's trivial to change bootloaders.
> >>>
> >>> So the real missing piece is someone to step up and rework the mux code.
> >>> The bigger problem is that the vast majority of folks don't care about the
> >>> common case and only care about getting thing working for a specific
> >>> platform.
> >>>
> >>> Kevin
> >>>
> >> I  like the idea of having the board file configure the mux.  First of
> >> all lets address the shortcomings of mux.h.  The Pin values are
> >> labeled as so:
> >> <snip from mux.h>
> >> * NOTE: Please use the following naming style for new pin entries.
> >>  *       For example, W8_1610_MMC2_DAT0, where:
> >>  *       - W8        = ball
> >>  *       - 1610      = 1510 or 1610, none if common for both 1510 and 1610
> >>  *       - MMC2_DAT0 = function
> >>
> >> But lets take the 3530 as an example.
> >>  The 3530 has three separate packages.  CBB, CBC, and CUS.  Now lets
> >> look at MMC3_clk (the root of my original problem that started this
> >> thread)
> >>                        CBB              CBC            CUS
> >> mmc3_clk         AB1 / AF10    R9 / AB2     AC1
> >>
> >> So to properly add these to mux.h we need to add 5 entries for mmc3_clk
> >>       AB1_35XXCBB_MMC3_CLK
> >>       AF10_35XXCBB_MMC3_CLK
> >>       R9_35XXCBC_MMC3_CLK
> >>       AB2_35XXCBC_MMC3_CLK
> >>       AC1_35XXCUS_MMC3_CLK
> >> We would then have to update mux.c making sure the position matches
> >> and add the proper settings.
> >>
> >> So this is obviously a maintenance nightmare.
> > 
> > So why don't we drop the ball (pun intended.) ;)
> > 
> > This is what I proposed to Phillip Ballister for his SPI changes for Beagle.
> > 
> > Though I haven't looked at the details for each package, I have a hard
> > time imagining that the reg offsets and functionality for each package
> > is different.  In fact, I'm pretty sure they're even the same between
> > 34xx and 35xx.  
> > 
> > IOW, why not just name it OMAP3_MMC3_CLK and have a single entry.
> > 
> > Then each board file that cares simply has to call omap_cfg_reg() on
> > that name and not care about the package.
> 
> They first problem I see is the MMC3_CLK is available on multiple balls, 
> so the mux files need to list them all.
> 
> Unless you are proposing custom mux files for each board? Is this is 
> good idea (just had this thought). In other words, instead of trying to 
> come up with one set of mux files, make them board specific.

Here's an idea:

1) Replace index with enum search in pin table - this breaks the
requirement that the enum list and table align - a good thing as
misalingment has bitten me multiple times when adding pins to the
current mux table.  Also, pinmux setup is done infrequently, so the
search doesn't add much overall execution time.

2) Break up mux table into two parts, the "common" mux list, and a
"custom" mux list - the latter in the board file, and add a function to
add the custom mux list to mux lists searched by omap_cfg_reg().

3) Search the custom mux list first (if specified - allows replacing an
entry in the common table if hardware required differences in
termination, custom pins for GPIO, etc).

For example, on the OMAP3530, balls H18-H21 can be associated with
either UART3, or GPIOs 163-166. In the common mux list (where multiple
boards use those pins for UART3, the common mux file can have the
entries:

H18_35XX_UART3_CTS
H19_35XX_UART3_RTS
H20_35XX_UART3_RX
H21_35XX_UART_TX

that sets up the mux for those pines as a UART.  If a board wants to use
those pins instead for GPIO, then in the board file it can have a custom
mux list with:

H18_35XX_GPIO_163
H19_35XX_GPIO_164
H20_35XX_GPIO_165
H21_35XX_GPIO_166

and call into the mux code to add the custom mux list to be searched
first.

Thoughts?

-- 
Peter Barada <peterb@logicpd.com>
Logic Product Development, Inc.

Re: MMC3 Overo

[Tony Lindgren]

* Peter Barada <peterb@logicpd.com> [090806 19:31]:
> On Thu, 2009-08-06 at 11:09 -0400, Philip Balister wrote:
> > Kevin Hilman wrote:
> > > John Sarman <johnsarman@gmail.com> writes:
> > > 
> > >> On Wed, Aug 5, 2009 at 2:35 PM, Kevin Hilman<khilman@deeprootsystems.com> wrote:
> > >>> Steve Sakoman wrote:
> > >>>> On Wed, Aug 5, 2009 at 10:58 AM, Kevin
> > >>>> Hilman<khilman@deeprootsystems.com> wrote:
> > >>>>> Steve Sakoman wrote:
> > >>>>>> And up to now in each case I shrug and say "no time to do that now,
> > >>>>>> I'll just leave kernel pinmuxing turned off and do it in u-boot"
> > >>>>> I agree there are lots of shortcomings in the current mux code and we've
> > >>>>> been hitting them regularily lately.
> > >>>>>
> > >>>>> That being said, for mux settings that done one-time only at boot, what
> > >>>>> are
> > >>>>> the problems you're running into?
> > >>>> It's been a few months since I last encountered this, so the exact
> > >>>> details are a bit fuzzy.
> > >>>>
> > >>>> I seem to recall that there were some basic issues with enabling
> > >>>> kernel pinmuxing in that some of the setup that was done for all
> > >>>> machines was just wrong for my particular machine.  IIRC, it was due
> > >>>> to assumptions about which pad was used for a particular function (for
> > >>>> those functions which can be steered to multiple GPIO pads).
> > >>>>
> > >>>> So I faced having to undo that change in my board file as well as any
> > >>>> issues that may have arisen from glitches on the GPIO pins during the
> > >>>> process.  And since there were several of these I gave up and turned
> > >>>> off kernel pinmuxing.
> > >>>>
> > >>>> I'd be happy if we cleaned up the "one size fits all" pinmuxing to
> > >>>> just that subset that truly does fit all boards, and leave the rest to
> > >>>> the board files.  I'd also be content to have it all done in the board
> > >>>> file for each machine.
> > >>> Indeed, any assumptions about common muxing that are not indeed common are
> > >>> bugs and should be fixed.
> > >>>
> > >>> The "right" solution is to have everything in the kernel, and split across
> > >>> SoC "common" init and board specific init.  Of course u-boot
> > >>> will still have to do some early muxing, but it should be redone in
> > >>> the kernel so it's trivial to change bootloaders.
> > >>>
> > >>> So the real missing piece is someone to step up and rework the mux code.
> > >>> The bigger problem is that the vast majority of folks don't care about the
> > >>> common case and only care about getting thing working for a specific
> > >>> platform.
> > >>>
> > >>> Kevin
> > >>>
> > >> I  like the idea of having the board file configure the mux.  First of
> > >> all lets address the shortcomings of mux.h.  The Pin values are
> > >> labeled as so:
> > >> <snip from mux.h>
> > >> * NOTE: Please use the following naming style for new pin entries.
> > >>  *       For example, W8_1610_MMC2_DAT0, where:
> > >>  *       - W8        = ball
> > >>  *       - 1610      = 1510 or 1610, none if common for both 1510 and 1610
> > >>  *       - MMC2_DAT0 = function
> > >>
> > >> But lets take the 3530 as an example.
> > >>  The 3530 has three separate packages.  CBB, CBC, and CUS.  Now lets
> > >> look at MMC3_clk (the root of my original problem that started this
> > >> thread)
> > >>                        CBB              CBC            CUS
> > >> mmc3_clk         AB1 / AF10    R9 / AB2     AC1
> > >>
> > >> So to properly add these to mux.h we need to add 5 entries for mmc3_clk
> > >>       AB1_35XXCBB_MMC3_CLK
> > >>       AF10_35XXCBB_MMC3_CLK
> > >>       R9_35XXCBC_MMC3_CLK
> > >>       AB2_35XXCBC_MMC3_CLK
> > >>       AC1_35XXCUS_MMC3_CLK
> > >> We would then have to update mux.c making sure the position matches
> > >> and add the proper settings.
> > >>
> > >> So this is obviously a maintenance nightmare.
> > > 
> > > So why don't we drop the ball (pun intended.) ;)
> > > 
> > > This is what I proposed to Phillip Ballister for his SPI changes for Beagle.
> > > 
> > > Though I haven't looked at the details for each package, I have a hard
> > > time imagining that the reg offsets and functionality for each package
> > > is different.  In fact, I'm pretty sure they're even the same between
> > > 34xx and 35xx.  
> > > 
> > > IOW, why not just name it OMAP3_MMC3_CLK and have a single entry.
> > > 
> > > Then each board file that cares simply has to call omap_cfg_reg() on
> > > that name and not care about the package.
> > 
> > They first problem I see is the MMC3_CLK is available on multiple balls, 
> > so the mux files need to list them all.
> > 
> > Unless you are proposing custom mux files for each board? Is this is 
> > good idea (just had this thought). In other words, instead of trying to 
> > come up with one set of mux files, make them board specific.
> 
> Here's an idea:
> 
> 1) Replace index with enum search in pin table - this breaks the
> requirement that the enum list and table align - a good thing as
> misalingment has bitten me multiple times when adding pins to the
> current mux table.  Also, pinmux setup is done infrequently, so the
> search doesn't add much overall execution time.

Yeh something like that sounds good. We should just move the omap1
specific code to live in mach-omap1 and keep it as it is for now.

You might also want to take a look at what the sh people have done:

$ find arch/sh -name \*mux*
 
> 2) Break up mux table into two parts, the "common" mux list, and a
> "custom" mux list - the latter in the board file, and add a function to
> add the custom mux list to mux lists searched by omap_cfg_reg().
> 
> 3) Search the custom mux list first (if specified - allows replacing an
> entry in the common table if hardware required differences in
> termination, custom pins for GPIO, etc).
> 
> For example, on the OMAP3530, balls H18-H21 can be associated with
> either UART3, or GPIOs 163-166. In the common mux list (where multiple
> boards use those pins for UART3, the common mux file can have the
> entries:
> 
> H18_35XX_UART3_CTS
> H19_35XX_UART3_RTS
> H20_35XX_UART3_RX
> H21_35XX_UART_TX
> 
> that sets up the mux for those pines as a UART.  If a board wants to use
> those pins instead for GPIO, then in the board file it can have a custom
> mux list with:
> 
> H18_35XX_GPIO_163
> H19_35XX_GPIO_164
> H20_35XX_GPIO_165
> H21_35XX_GPIO_166
> 
> and call into the mux code to add the custom mux list to be searched
> first.
> 
> Thoughts?

Sounds pretty good to me!

Tony

Re: MMC3 Overo

[Vladimir Pantelic]

Tony Lindgren wrote:

<snip>
>>  Here's an idea:
>>
>>  1) Replace index with enum search in pin table - this breaks the
>>  requirement that the enum list and table align - a good thing as
>>  misalingment has bitten me multiple times when adding pins to the
>>  current mux table.  Also, pinmux setup is done infrequently, so the
>>  search doesn't add much overall execution time.
>
> Yeh something like that sounds good. We should just move the omap1
> specific code to live in mach-omap1 and keep it as it is for now.
>
> You might also want to take a look at what the sh people have done:
>
> $ find arch/sh -name \*mux*
>
>>  2) Break up mux table into two parts, the "common" mux list, and a
>>  "custom" mux list - the latter in the board file, and add a function to
>>  add the custom mux list to mux lists searched by omap_cfg_reg().
>>
>>  3) Search the custom mux list first (if specified - allows replacing an
>>  entry in the common table if hardware required differences in
>>  termination, custom pins for GPIO, etc).
>>
>>  For example, on the OMAP3530, balls H18-H21 can be associated with
>>  either UART3, or GPIOs 163-166. In the common mux list (where multiple
>>  boards use those pins for UART3, the common mux file can have the
>>  entries:
>>
>>  H18_35XX_UART3_CTS
>>  H19_35XX_UART3_RTS
>>  H20_35XX_UART3_RX
>>  H21_35XX_UART_TX
>>
>>  that sets up the mux for those pines as a UART.  If a board wants to use
>>  those pins instead for GPIO, then in the board file it can have a custom
>>  mux list with:
>>
>>  H18_35XX_GPIO_163
>>  H19_35XX_GPIO_164
>>  H20_35XX_GPIO_165
>>  H21_35XX_GPIO_166
>>
>>  and call into the mux code to add the custom mux list to be searched
>>  first.
>>
>>  Thoughts?
>
> Sounds pretty good to me!

but does not solve yet the "package" issue, where different omap3 packages have
different balls connected, no? It would be ok for board files, assuming that a
board has only one package, but what about the common code?

Or are the package differences only for a few pins, in this case they could be
"banned" from common and must live in board files..

Re: MMC3 Overo

[Tony Lindgren]

* Vladimir Pantelic <pan@nt.tu-darmstadt.de> [090807 12:24]:
> Tony Lindgren wrote:
>
> <snip>
>>>  Here's an idea:
>>>
>>>  1) Replace index with enum search in pin table - this breaks the
>>>  requirement that the enum list and table align - a good thing as
>>>  misalingment has bitten me multiple times when adding pins to the
>>>  current mux table.  Also, pinmux setup is done infrequently, so the
>>>  search doesn't add much overall execution time.
>>
>> Yeh something like that sounds good. We should just move the omap1
>> specific code to live in mach-omap1 and keep it as it is for now.
>>
>> You might also want to take a look at what the sh people have done:
>>
>> $ find arch/sh -name \*mux*
>>
>>>  2) Break up mux table into two parts, the "common" mux list, and a
>>>  "custom" mux list - the latter in the board file, and add a function to
>>>  add the custom mux list to mux lists searched by omap_cfg_reg().
>>>
>>>  3) Search the custom mux list first (if specified - allows replacing an
>>>  entry in the common table if hardware required differences in
>>>  termination, custom pins for GPIO, etc).
>>>
>>>  For example, on the OMAP3530, balls H18-H21 can be associated with
>>>  either UART3, or GPIOs 163-166. In the common mux list (where multiple
>>>  boards use those pins for UART3, the common mux file can have the
>>>  entries:
>>>
>>>  H18_35XX_UART3_CTS
>>>  H19_35XX_UART3_RTS
>>>  H20_35XX_UART3_RX
>>>  H21_35XX_UART_TX
>>>
>>>  that sets up the mux for those pines as a UART.  If a board wants to use
>>>  those pins instead for GPIO, then in the board file it can have a custom
>>>  mux list with:
>>>
>>>  H18_35XX_GPIO_163
>>>  H19_35XX_GPIO_164
>>>  H20_35XX_GPIO_165
>>>  H21_35XX_GPIO_166
>>>
>>>  and call into the mux code to add the custom mux list to be searched
>>>  first.
>>>
>>>  Thoughts?
>>
>> Sounds pretty good to me!
>
> but does not solve yet the "package" issue, where different omap3 packages have
> different balls connected, no? It would be ok for board files, assuming that a
> board has only one package, but what about the common code?
>
> Or are the package differences only for a few pins, in this case they could be
> "banned" from common and must live in board files..

Well we need to mux all the pins that can potentially conflict only in the
board-*.c files.

For naming, I think we should use the default mode0 name in the mux register as the
key, and then link package specific pin names to that key. The pin names are
very handy to see for debugging at least.

Another thing to consider is if we want to support dynamic muxing. That means
we need to keep the mux tables in the memory.

Or do init time muxing in board-*.c files, then re-register the pins needed for
dynamic muxing in board-*.c files. That way most of the mux data can be __initdata,
and only the pins that have been registered for dynamic muxing need to be kept
in the memory.

Regard,

Tony

Re: MMC3 Overo

[Steve Sakoman]

On Fri, Aug 7, 2009 at 2:55 AM, Tony Lindgren<tony@atomide.com> wrote:

> Well we need to mux all the pins that can potentially conflict only in the
> board-*.c files.
>
> For naming, I think we should use the default mode0 name in the mux register as the
> key, and then link package specific pin names to that key. The pin names are
> very handy to see for debugging at least.

I like that approach - it matches the method in the documentation
tables (i.e. unique pin name is the mode 0 function).

> Another thing to consider is if we want to support dynamic muxing. That means
> we need to keep the mux tables in the memory.

Dynamic muxing would be very nice.  It is required if we ever want to
do card detect with microSD cards.

> Or do init time muxing in board-*.c files, then re-register the pins needed for
> dynamic muxing in board-*.c files. That way most of the mux data can be __initdata,
> and only the pins that have been registered for dynamic muxing need to be kept
> in the memory.

This sounds good too.

Reagrds,

Steve