[PATCH] OMAP: USB EHCI: Support final revision of USB board

[PATCH] OMAP: USB EHCI: Support final revision of USB board

[Pandita, Vikram]

   Code changes for final rev of EHCI/OHCI USB expansion board 750-2099-001(C)
   with h/w bug fixes to support ISP1504 PHY in input clocking mode

   The board has 12-pin ULPI Port1 and Port2 EHCI pins connected to ISP1504's.
   Port3 is connected to ISP1301 for connection to OHCI.

 - This is the final USB expansion board that will be released and
   so the bug fixes are critical

 - Changes tested on SDP3430

Signed-off-by: Vikram Pandita <vikram.pandita@ti.com>
---
 drivers/usb/host/ehci-omap.c |   37 ++++++-------------------------------
 1 file changed, 6 insertions(+), 31 deletions(-)

Index: linux-omap-2.6/drivers/usb/host/ehci-omap.c
===================================================================
--- linux-omap-2.6.orig/drivers/usb/host/ehci-omap.c    2008-05-02 14:11:56.000000000 +0530
+++ linux-omap-2.6/drivers/usb/host/ehci-omap.c 2008-05-02 15:05:40.000000000 +0530
@@ -35,7 +35,7 @@
 #ifdef CONFIG_OMAP_EHCI_PHY_MODE
 /* EHCI connected to External PHY */

-/* External USB connectivity board: 750-2083-001
+/* External USB connectivity board: 750-2099-001(C)
  * Connected to OMAP3430 SDP
  * The board has Port1 and Port2 connected to ISP1504 in 12-pin ULPI mode
  */
@@ -50,14 +50,7 @@
 #define EXTERNAL_PHY_RESET
 #define        EXT_PHY_RESET_GPIO_PORT1        (57)
 #define        EXT_PHY_RESET_GPIO_PORT2        (61)
-#define        EXT_PHY_RESET_DELAY             (10)
-
-/* ISSUE2:
- * USBHOST supports External charge pump PHYs only
- * Use the VBUS from Port1 to power VBUS of Port2 externally
- * So use Port2 as the working ULPI port
- */
-#define VBUS_INTERNAL_CHARGEPUMP_HACK
+#define        EXT_PHY_RESET_DELAY             (500)

 #endif /* CONFIG_OMAP_EHCI_PHY_MODE */

@@ -228,8 +221,8 @@ static int omap_start_ehc(struct platfor
        omap_set_gpio_direction(EXT_PHY_RESET_GPIO_PORT1, 0);
        omap_request_gpio(EXT_PHY_RESET_GPIO_PORT2);
        omap_set_gpio_direction(EXT_PHY_RESET_GPIO_PORT2, 0);
-       omap_set_gpio_dataout(EXT_PHY_RESET_GPIO_PORT1, 0);
-       omap_set_gpio_dataout(EXT_PHY_RESET_GPIO_PORT2, 0);
+       omap_set_gpio_dataout(EXT_PHY_RESET_GPIO_PORT1, 1);
+       omap_set_gpio_dataout(EXT_PHY_RESET_GPIO_PORT2, 1);
        /* Hold the PHY in RESET for enough time till DIR is high */
        udelay(EXT_PHY_RESET_DELAY);
 #endif
@@ -305,26 +298,8 @@ static int omap_start_ehc(struct platfor
         * Hold the PHY in RESET for enough time till PHY is settled and ready
         */
        udelay(EXT_PHY_RESET_DELAY);
-       omap_set_gpio_dataout(EXT_PHY_RESET_GPIO_PORT1, 1);
-       omap_set_gpio_dataout(EXT_PHY_RESET_GPIO_PORT2, 1);
-#endif
-
-#ifdef VBUS_INTERNAL_CHARGEPUMP_HACK
-       /* Refer ISSUE2: LINK assumes external charge pump */
-
-       /* use Port1 VBUS to charge externally Port2:
-        *      So for PHY mode operation use Port2 only
-        */
-       omap_writel((0xA << EHCI_INSNREG05_ULPI_REGADD_SHIFT) |/* OTG ctrl reg*/
-                       (2 << EHCI_INSNREG05_ULPI_OPSEL_SHIFT) |/*   Write */
-                       (1 << EHCI_INSNREG05_ULPI_PORTSEL_SHIFT) |/* Port1 */
-                       (1 << EHCI_INSNREG05_ULPI_CONTROL_SHIFT) |/* Start */
-                       (0x26),
-                       EHCI_INSNREG05_ULPI);
-
-       while (!(omap_readl(EHCI_INSNREG05_ULPI) &
-               (1<<EHCI_INSNREG05_ULPI_CONTROL_SHIFT)));
-
+       omap_set_gpio_dataout(EXT_PHY_RESET_GPIO_PORT1, 0);
+       omap_set_gpio_dataout(EXT_PHY_RESET_GPIO_PORT2, 0);
 #endif

        return 0;

Re: [PATCH] OMAP: USB EHCI: Support final revision of USB board

[Tony Lindgren]

* Pandita, Vikram <vikram.pandita@ti.com> [080630 17:03]:
> 
> 
>    Code changes for final rev of EHCI/OHCI USB expansion board 750-2099-001(C)
>    with h/w bug fixes to support ISP1504 PHY in input clocking mode
> 
>    The board has 12-pin ULPI Port1 and Port2 EHCI pins connected to ISP1504's.
>    Port3 is connected to ISP1301 for connection to OHCI.
> 
>  - This is the final USB expansion board that will be released and
>    so the bug fixes are critical
> 
>  - Changes tested on SDP3430

These should be sent via linux-usb list, please also Cc linux-omap list.

Thanks,

Tony


> Signed-off-by: Vikram Pandita <vikram.pandita@ti.com>
> ---
>  drivers/usb/host/ehci-omap.c |   37 ++++++-------------------------------
>  1 file changed, 6 insertions(+), 31 deletions(-)
> 
> Index: linux-omap-2.6/drivers/usb/host/ehci-omap.c
> ===================================================================
> --- linux-omap-2.6.orig/drivers/usb/host/ehci-omap.c    2008-05-02 14:11:56.000000000 +0530
> +++ linux-omap-2.6/drivers/usb/host/ehci-omap.c 2008-05-02 15:05:40.000000000 +0530
> @@ -35,7 +35,7 @@
>  #ifdef CONFIG_OMAP_EHCI_PHY_MODE
>  /* EHCI connected to External PHY */
> 
> -/* External USB connectivity board: 750-2083-001
> +/* External USB connectivity board: 750-2099-001(C)
>   * Connected to OMAP3430 SDP
>   * The board has Port1 and Port2 connected to ISP1504 in 12-pin ULPI mode
>   */
> @@ -50,14 +50,7 @@
>  #define EXTERNAL_PHY_RESET
>  #define        EXT_PHY_RESET_GPIO_PORT1        (57)
>  #define        EXT_PHY_RESET_GPIO_PORT2        (61)
> -#define        EXT_PHY_RESET_DELAY             (10)
> -
> -/* ISSUE2:
> - * USBHOST supports External charge pump PHYs only
> - * Use the VBUS from Port1 to power VBUS of Port2 externally
> - * So use Port2 as the working ULPI port
> - */
> -#define VBUS_INTERNAL_CHARGEPUMP_HACK
> +#define        EXT_PHY_RESET_DELAY             (500)
> 
>  #endif /* CONFIG_OMAP_EHCI_PHY_MODE */
> 
> @@ -228,8 +221,8 @@ static int omap_start_ehc(struct platfor
>         omap_set_gpio_direction(EXT_PHY_RESET_GPIO_PORT1, 0);
>         omap_request_gpio(EXT_PHY_RESET_GPIO_PORT2);
>         omap_set_gpio_direction(EXT_PHY_RESET_GPIO_PORT2, 0);
> -       omap_set_gpio_dataout(EXT_PHY_RESET_GPIO_PORT1, 0);
> -       omap_set_gpio_dataout(EXT_PHY_RESET_GPIO_PORT2, 0);
> +       omap_set_gpio_dataout(EXT_PHY_RESET_GPIO_PORT1, 1);
> +       omap_set_gpio_dataout(EXT_PHY_RESET_GPIO_PORT2, 1);
>         /* Hold the PHY in RESET for enough time till DIR is high */
>         udelay(EXT_PHY_RESET_DELAY);
>  #endif
> @@ -305,26 +298,8 @@ static int omap_start_ehc(struct platfor
>          * Hold the PHY in RESET for enough time till PHY is settled and ready
>          */
>         udelay(EXT_PHY_RESET_DELAY);
> -       omap_set_gpio_dataout(EXT_PHY_RESET_GPIO_PORT1, 1);
> -       omap_set_gpio_dataout(EXT_PHY_RESET_GPIO_PORT2, 1);
> -#endif
> -
> -#ifdef VBUS_INTERNAL_CHARGEPUMP_HACK
> -       /* Refer ISSUE2: LINK assumes external charge pump */
> -
> -       /* use Port1 VBUS to charge externally Port2:
> -        *      So for PHY mode operation use Port2 only
> -        */
> -       omap_writel((0xA << EHCI_INSNREG05_ULPI_REGADD_SHIFT) |/* OTG ctrl reg*/
> -                       (2 << EHCI_INSNREG05_ULPI_OPSEL_SHIFT) |/*   Write */
> -                       (1 << EHCI_INSNREG05_ULPI_PORTSEL_SHIFT) |/* Port1 */
> -                       (1 << EHCI_INSNREG05_ULPI_CONTROL_SHIFT) |/* Start */
> -                       (0x26),
> -                       EHCI_INSNREG05_ULPI);
> -
> -       while (!(omap_readl(EHCI_INSNREG05_ULPI) &
> -               (1<<EHCI_INSNREG05_ULPI_CONTROL_SHIFT)));
> -
> +       omap_set_gpio_dataout(EXT_PHY_RESET_GPIO_PORT1, 0);
> +       omap_set_gpio_dataout(EXT_PHY_RESET_GPIO_PORT2, 0);
>  #endif
> 
>         return 0;
> --
> 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: [PATCH] OMAP: USB EHCI: Support final revision of USB board

[Gadiyar, Anand]

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org On Behalf Of Tony Lindgren
> * Pandita, Vikram <vikram.pandita@ti.com> [080630 17:03]:
> >
> >
> >    Code changes for final rev of EHCI/OHCI USB expansion board 750-2099-001(C)
> >    with h/w bug fixes to support ISP1504 PHY in input clocking mode
> >
> >    The board has 12-pin ULPI Port1 and Port2 EHCI pins connected to ISP1504's.
> >    Port3 is connected to ISP1301 for connection to OHCI.
> >
> >  - This is the final USB expansion board that will be released and
> >    so the bug fixes are critical
> >
> >  - Changes tested on SDP3430
> 
> These should be sent via linux-usb list, please also Cc 
> linux-omap list.
> 
> Thanks,
> 
> Tony


Er Tony, the bus glue for OMAP is not present upstream. This patch fixes
something in that bus glue code, which currently exists only in your tree.
Care to push this to your tree for now?

I'll get the ehci-omap code in better shape and submit separately to the
linux-usb list.


- Anand


> 
> 
> > Signed-off-by: Vikram Pandita <vikram.pandita@ti.com>
> > ---
> >  drivers/usb/host/ehci-omap.c |   37 ++++++-------------------------------
> >  1 file changed, 6 insertions(+), 31 deletions(-)
> >
> > Index: linux-omap-2.6/drivers/usb/host/ehci-omap.c
> > ===================================================================
> > --- linux-omap-2.6.orig/drivers/usb/host/ehci-omap.c    2008-05-02 14:11:56.000000000 +0530
> > +++ linux-omap-2.6/drivers/usb/host/ehci-omap.c 2008-05-02 15:05:40.000000000 +0530
> > @@ -35,7 +35,7 @@
> >  #ifdef CONFIG_OMAP_EHCI_PHY_MODE
> >  /* EHCI connected to External PHY */
> >
> > -/* External USB connectivity board: 750-2083-001
> > +/* External USB connectivity board: 750-2099-001(C)
> >   * Connected to OMAP3430 SDP
> >   * The board has Port1 and Port2 connected to ISP1504 in 12-pin ULPI mode
> >   */
> > @@ -50,14 +50,7 @@
> >  #define EXTERNAL_PHY_RESET
> >  #define        EXT_PHY_RESET_GPIO_PORT1        (57)
> >  #define        EXT_PHY_RESET_GPIO_PORT2        (61)
> > -#define        EXT_PHY_RESET_DELAY             (10)
> > -
> > -/* ISSUE2:
> > - * USBHOST supports External charge pump PHYs only
> > - * Use the VBUS from Port1 to power VBUS of Port2 externally
> > - * So use Port2 as the working ULPI port
> > - */
> > -#define VBUS_INTERNAL_CHARGEPUMP_HACK
> > +#define        EXT_PHY_RESET_DELAY             (500)
> >
> >  #endif /* CONFIG_OMAP_EHCI_PHY_MODE */
> >
> > @@ -228,8 +221,8 @@ static int omap_start_ehc(struct platfor
> >         omap_set_gpio_direction(EXT_PHY_RESET_GPIO_PORT1, 0);
> >         omap_request_gpio(EXT_PHY_RESET_GPIO_PORT2);
> >         omap_set_gpio_direction(EXT_PHY_RESET_GPIO_PORT2, 0);
> > -       omap_set_gpio_dataout(EXT_PHY_RESET_GPIO_PORT1, 0);
> > -       omap_set_gpio_dataout(EXT_PHY_RESET_GPIO_PORT2, 0);
> > +       omap_set_gpio_dataout(EXT_PHY_RESET_GPIO_PORT1, 1);
> > +       omap_set_gpio_dataout(EXT_PHY_RESET_GPIO_PORT2, 1);
> >         /* Hold the PHY in RESET for enough time till DIR is high */
> >         udelay(EXT_PHY_RESET_DELAY);
> >  #endif
> > @@ -305,26 +298,8 @@ static int omap_start_ehc(struct platfor
> >          * Hold the PHY in RESET for enough time till PHY is settled and ready
> >          */
> >         udelay(EXT_PHY_RESET_DELAY);
> > -       omap_set_gpio_dataout(EXT_PHY_RESET_GPIO_PORT1, 1);
> > -       omap_set_gpio_dataout(EXT_PHY_RESET_GPIO_PORT2, 1);
> > -#endif
> > -
> > -#ifdef VBUS_INTERNAL_CHARGEPUMP_HACK
> > -       /* Refer ISSUE2: LINK assumes external charge pump */
> > -
> > -       /* use Port1 VBUS to charge externally Port2:
> > -        *      So for PHY mode operation use Port2 only
> > -        */
> > -       omap_writel((0xA << EHCI_INSNREG05_ULPI_REGADD_SHIFT) |/* OTG ctrl reg*/
> > -                       (2 << EHCI_INSNREG05_ULPI_OPSEL_SHIFT) |/*   Write */
> > -                       (1 << EHCI_INSNREG05_ULPI_PORTSEL_SHIFT) |/* Port1 */
> > -                       (1 << EHCI_INSNREG05_ULPI_CONTROL_SHIFT) |/* Start */
> > -                       (0x26),
> > -                       EHCI_INSNREG05_ULPI);
> > -
> > -       while (!(omap_readl(EHCI_INSNREG05_ULPI) &
> > -               (1<<EHCI_INSNREG05_ULPI_CONTROL_SHIFT)));
> > -
> > +       omap_set_gpio_dataout(EXT_PHY_RESET_GPIO_PORT1, 0);
> > +       omap_set_gpio_dataout(EXT_PHY_RESET_GPIO_PORT2, 0);
> >  #endif
> >
> >         return 0;

Re: [PATCH] OMAP: USB EHCI: Support final revision of USB board

[Tony Lindgren]

* Gadiyar, Anand <gadiyar@ti.com> [080821 05:49]:
> > -----Original Message-----
> > From: linux-omap-owner@vger.kernel.org On Behalf Of Tony Lindgren
> > * Pandita, Vikram <vikram.pandita@ti.com> [080630 17:03]:
> > >
> > >
> > >    Code changes for final rev of EHCI/OHCI USB expansion board 750-2099-001(C)
> > >    with h/w bug fixes to support ISP1504 PHY in input clocking mode
> > >
> > >    The board has 12-pin ULPI Port1 and Port2 EHCI pins connected to ISP1504's.
> > >    Port3 is connected to ISP1301 for connection to OHCI.
> > >
> > >  - This is the final USB expansion board that will be released and
> > >    so the bug fixes are critical
> > >
> > >  - Changes tested on SDP3430
> > 
> > These should be sent via linux-usb list, please also Cc 
> > linux-omap list.
> > 
> > Thanks,
> > 
> > Tony
> 
> 
> Er Tony, the bus glue for OMAP is not present upstream. This patch fixes
> something in that bus glue code, which currently exists only in your tree.
> Care to push this to your tree for now?
> 
> I'll get the ehci-omap code in better shape and submit separately to the
> linux-usb list.

Well we should really sync all usb code with mainline now that musb is
merged. Can you repost patches against mainline for linux-usb? I can
then reset drivers/usb to be in sync with mainline and we can move
all USB related discussion to linux-usb.

Tony

> 
> 
> - Anand
> 
> 
> > 
> > 
> > > Signed-off-by: Vikram Pandita <vikram.pandita@ti.com>
> > > ---
> > >  drivers/usb/host/ehci-omap.c |   37 ++++++-------------------------------
> > >  1 file changed, 6 insertions(+), 31 deletions(-)
> > >
> > > Index: linux-omap-2.6/drivers/usb/host/ehci-omap.c
> > > ===================================================================
> > > --- linux-omap-2.6.orig/drivers/usb/host/ehci-omap.c    2008-05-02 14:11:56.000000000 +0530
> > > +++ linux-omap-2.6/drivers/usb/host/ehci-omap.c 2008-05-02 15:05:40.000000000 +0530
> > > @@ -35,7 +35,7 @@
> > >  #ifdef CONFIG_OMAP_EHCI_PHY_MODE
> > >  /* EHCI connected to External PHY */
> > >
> > > -/* External USB connectivity board: 750-2083-001
> > > +/* External USB connectivity board: 750-2099-001(C)
> > >   * Connected to OMAP3430 SDP
> > >   * The board has Port1 and Port2 connected to ISP1504 in 12-pin ULPI mode
> > >   */
> > > @@ -50,14 +50,7 @@
> > >  #define EXTERNAL_PHY_RESET
> > >  #define        EXT_PHY_RESET_GPIO_PORT1        (57)
> > >  #define        EXT_PHY_RESET_GPIO_PORT2        (61)
> > > -#define        EXT_PHY_RESET_DELAY             (10)
> > > -
> > > -/* ISSUE2:
> > > - * USBHOST supports External charge pump PHYs only
> > > - * Use the VBUS from Port1 to power VBUS of Port2 externally
> > > - * So use Port2 as the working ULPI port
> > > - */
> > > -#define VBUS_INTERNAL_CHARGEPUMP_HACK
> > > +#define        EXT_PHY_RESET_DELAY             (500)
> > >
> > >  #endif /* CONFIG_OMAP_EHCI_PHY_MODE */
> > >
> > > @@ -228,8 +221,8 @@ static int omap_start_ehc(struct platfor
> > >         omap_set_gpio_direction(EXT_PHY_RESET_GPIO_PORT1, 0);
> > >         omap_request_gpio(EXT_PHY_RESET_GPIO_PORT2);
> > >         omap_set_gpio_direction(EXT_PHY_RESET_GPIO_PORT2, 0);
> > > -       omap_set_gpio_dataout(EXT_PHY_RESET_GPIO_PORT1, 0);
> > > -       omap_set_gpio_dataout(EXT_PHY_RESET_GPIO_PORT2, 0);
> > > +       omap_set_gpio_dataout(EXT_PHY_RESET_GPIO_PORT1, 1);
> > > +       omap_set_gpio_dataout(EXT_PHY_RESET_GPIO_PORT2, 1);
> > >         /* Hold the PHY in RESET for enough time till DIR is high */
> > >         udelay(EXT_PHY_RESET_DELAY);
> > >  #endif
> > > @@ -305,26 +298,8 @@ static int omap_start_ehc(struct platfor
> > >          * Hold the PHY in RESET for enough time till PHY is settled and ready
> > >          */
> > >         udelay(EXT_PHY_RESET_DELAY);
> > > -       omap_set_gpio_dataout(EXT_PHY_RESET_GPIO_PORT1, 1);
> > > -       omap_set_gpio_dataout(EXT_PHY_RESET_GPIO_PORT2, 1);
> > > -#endif
> > > -
> > > -#ifdef VBUS_INTERNAL_CHARGEPUMP_HACK
> > > -       /* Refer ISSUE2: LINK assumes external charge pump */
> > > -
> > > -       /* use Port1 VBUS to charge externally Port2:
> > > -        *      So for PHY mode operation use Port2 only
> > > -        */
> > > -       omap_writel((0xA << EHCI_INSNREG05_ULPI_REGADD_SHIFT) |/* OTG ctrl reg*/
> > > -                       (2 << EHCI_INSNREG05_ULPI_OPSEL_SHIFT) |/*   Write */
> > > -                       (1 << EHCI_INSNREG05_ULPI_PORTSEL_SHIFT) |/* Port1 */
> > > -                       (1 << EHCI_INSNREG05_ULPI_CONTROL_SHIFT) |/* Start */
> > > -                       (0x26),
> > > -                       EHCI_INSNREG05_ULPI);
> > > -
> > > -       while (!(omap_readl(EHCI_INSNREG05_ULPI) &
> > > -               (1<<EHCI_INSNREG05_ULPI_CONTROL_SHIFT)));
> > > -
> > > +       omap_set_gpio_dataout(EXT_PHY_RESET_GPIO_PORT1, 0);
> > > +       omap_set_gpio_dataout(EXT_PHY_RESET_GPIO_PORT2, 0);
> > >  #endif
> > >
> > >         return 0;

RE: [PATCH] OMAP: USB EHCI: Support final revision of USB board

[Gadiyar, Anand]

<snip>
> > > 
> > > These should be sent via linux-usb list, please also Cc 
> > > linux-omap list.
> > > 
> > > Thanks,
> > > 
> > > Tony
> > 
> > 
> > Er Tony, the bus glue for OMAP is not present upstream. This patch fixes
> > something in that bus glue code, which currently exists only in your tree.
> > Care to push this to your tree for now?
> > 
> > I'll get the ehci-omap code in better shape and submit separately to the
> > linux-usb list.
> 
> Well we should really sync all usb code with mainline now that musb is
> merged. Can you repost patches against mainline for linux-usb? I can
> then reset drivers/usb to be in sync with mainline and we can move
> all USB related discussion to linux-usb.
> 
> Tony

Okay. I'll add that to my to-do queue.

-Anand

Re: [PATCH] OMAP: USB EHCI: Support final revision of USB board

[David Brownell]

On Saturday 23 August 2008, Tony Lindgren wrote:
> 
> > I'll get the ehci-omap code in better shape and submit separately to the
> > linux-usb list.

Given that we've not yet seen patches splitting out the board-specific
bits into arch/arm/mach-omap2, I can't imagine those fixes being ready
for the 2.6.28 merge window.  (Hint for TI folk:  why not write the
code that way in the first place, avoiding all the delays inherent in
writing code you *know* is unsuitable for merging to mainline?)

They'd have to get in through the "new driver" exception ... but that
doesn't seem workable either, since the mach-omap2 updates aren't ready
yet *either*, and there's not much time left for them to get into the
OMAP tree, tested, reviewed for the ARM merge window, and then pulled
into Russell's patch queue ...

In short:  unless that's ready in the next few days, that stuff may
not be able to hit mainline until 2.6.29 merges start (I'm guessing
that will mean January 2009).


> Well we should really sync all usb code with mainline now that musb is
> merged.

There are still a bunch of essential musb build fixes waiting to get
into mainline (from moving include/asm-arm in RC1).

I cc'd Greg; I'm hoping he plans to get those upstream soon, so
the 2.6.28-rc0 merge window can focus on the remaining functional
updates to make platforms work ... instead of build fixes, and then
needing another merge window for functional fixes.  It seems DaVinci
will be ready (platform updates are in Russell's queue).  OMAP3 looks
to be more involved.

- Dave

RE: [PATCH] OMAP: USB EHCI: Support final revision of USB board

[Gadiyar, Anand]

> 
> On Saturday 23 August 2008, Tony Lindgren wrote:
> >
> > > I'll get the ehci-omap code in better shape and submit separately to the
> > > linux-usb list.
> 
> Given that we've not yet seen patches splitting out the board-specific
> bits into arch/arm/mach-omap2, I can't imagine those fixes being ready
> for the 2.6.28 merge window.  (Hint for TI folk:  why not write the
> code that way in the first place, avoiding all the delays inherent in
> writing code you *know* is unsuitable for merging to mainline?)

Well, there are only a limited number of hours in a day. :)

Hint taken: that that code was initially written badly is a valid point.
But fixing it up is a non-trivial effort as is making sure it works. At the time I 
wrote that e-mail (August 25) I did intend to have it out well before Felipe's
11 September plan.

As they say, the best laid plans of mice and men... At the moment it does
not look like I'll be able to do this anytime soon.

And if it's going upstream, it needs to be in better shape than it currently is.

Even assuming that linux-usb decides to take it in it's current shape, it's 
definitely not going to help things when the OHCI driver comes in. And if
I'm going to be doing that cleanup anyway, I might as well get it right the
first time. Correct?

I'm going to be re-arranging this code, writing it the way it ought to have
been the first time. But please don't expect this tomorrow.

- Anand


> 
> They'd have to get in through the "new driver" exception ... but that
> doesn't seem workable either, since the mach-omap2 updates aren't ready
> yet *either*, and there's not much time left for them to get into the
> OMAP tree, tested, reviewed for the ARM merge window, and then pulled
> into Russell's patch queue ...
> 
> In short:  unless that's ready in the next few days, that stuff may
> not be able to hit mainline until 2.6.29 merges start (I'm guessing
> that will mean January 2009).
> 
> 
> > Well we should really sync all usb code with mainline now that musb is
> > merged.
> 
> There are still a bunch of essential musb build fixes waiting to get
> into mainline (from moving include/asm-arm in RC1).
> 
> I cc'd Greg; I'm hoping he plans to get those upstream soon, so
> the 2.6.28-rc0 merge window can focus on the remaining functional
> updates to make platforms work ... instead of build fixes, and then
> needing another merge window for functional fixes.  It seems DaVinci
> will be ready (platform updates are in Russell's queue).  OMAP3 looks
> to be more involved.
> 
> - Dave

Re: [PATCH] OMAP: USB EHCI: Support final revision of USB board

[Måns Rullgård]

"Gadiyar, Anand" <gadiyar@ti.com> writes:

>> 
>> On Saturday 23 August 2008, Tony Lindgren wrote:
>> >
>> > > I'll get the ehci-omap code in better shape and submit separately to the
>> > > linux-usb list.
>> 
>> Given that we've not yet seen patches splitting out the board-specific
>> bits into arch/arm/mach-omap2, I can't imagine those fixes being ready
>> for the 2.6.28 merge window.  (Hint for TI folk:  why not write the
>> code that way in the first place, avoiding all the delays inherent in
>> writing code you *know* is unsuitable for merging to mainline?)
>
> Well, there are only a limited number of hours in a day. :)

In my experience, writing code properly to begin with takes less time
than writing it badly first, and cleaning it up later.

-- 
Måns Rullgård
mans@mansr.com

--
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: [PATCH] OMAP: USB EHCI: Support final revision of USB board

[Gadiyar, Anand]

>> "Gadiyar, Anand" <gadiyar@ti.com> writes:
>>>
>>> On Saturday 23 August 2008, Tony Lindgren wrote:
>>> >
>>> > > I'll get the ehci-omap code in better shape and submit separately to the
>>> > > linux-usb list.
>>>
>>> Given that we've not yet seen patches splitting out the board-specific
>>> bits into arch/arm/mach-omap2, I can't imagine those fixes being ready
>>> for the 2.6.28 merge window.  (Hint for TI folk:  why not write the
>>> code that way in the first place, avoiding all the delays inherent in
>>> writing code you *know* is unsuitable for merging to mainline?)
>>
>> Well, there are only a limited number of hours in a day. :)
> 
> In my experience, writing code properly to begin with takes less time
> than writing it badly first, and cleaning it up later.
> 
> --
> Måns Rullgård
> mans@mansr.com

I totally agree. But I didn't write that in the first place - it's just that I
happen to use this controller more often than others do :)--
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: [PATCH] OMAP: USB EHCI: Support final revision of USB board

[David Brownell]

On Thursday 18 September 2008, Gadiyar, Anand wrote:
> >		(Hint for TI folk:  why not write the
> > code that way in the first place, avoiding all the delays inherent in
> > writing code you *know* is unsuitable for merging to mainline?)
> 
> Well, there are only a limited number of hours in a day. :)

Bzip2 is a good way to compress things ... can that help
make those hours more productive?  ;)


> Hint taken: that that code was initially written badly is a valid point.

And likewise, I think, that it's not an uncommon way for
things to start out.  The real problem is that such code
then sits in some (OMAP) tree for a long time and never gets
fixed and sent upstream.

One TI engineer (who I won't name!) said to me this year
that he thinks the issue is part of TI's current process.
Paraphrasing:  the code is treated as "done" when it merges
to some OMAP branch ... *NOT* when it goes upstream.  To the
extent that's true, it should get fixed.  For drivers, there
should be no problems doing so.  (Infrastructure is often a
bit different.)


> But fixing it up is a non-trivial effort as is making sure it works. At the time I 
> wrote that e-mail (August 25) I did intend to have it out well before Felipe's
> 11 September plan.
> 
> As they say, the best laid plans of mice and men... At the moment it does
> not look like I'll be able to do this anytime soon.

Right.  That happens.

 
> And if it's going upstream, it needs to be in better shape than it currently is.
> 
> Even assuming that linux-usb decides to take it in it's current shape, it's 
> definitely not going to help things when the OHCI driver comes in. And if
> I'm going to be doing that cleanup anyway, I might as well get it right the
> first time. Correct?

Unless that stretches the EHCI merge out too much.  Drivers sitting
around outside of mainline for a long time (a year or more) make
trouble.  Updates to mainline generally don't make trouble.

 
> I'm going to be re-arranging this code, writing it the way it ought to have
> been the first time. But please don't expect this tomorrow.

No, I'm not ... as I noted!  Though I'd hope it's ready to push upstream
in the 2.6.29-rc0 window...

I'm just piling on with a few observations about a process problem here.
We've seen versions of this for a long time now.  Once you achieve that
re-arrangement ... it'd be nicer all around (for you, for me, for everyone)
if the problem came up less regularly in the future.

- Dave

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