To get USB HOST mode working on USB OTG Port with USB TTY enabled U-boot
Apply this against http://www.beagleboard.org/linux-2.6.git (branch :
2.6.28-oe-r8)
http://www.beagleboard.org/gitweb/?p=linux-2.6.git;a=shortlog;h=2.6.28-oe-r8
Signed-off-by: Syed Mohammed Khasim <khasim@ti.com>
USB_TTY_FIX.patch (834 Bytes)
Hi Khasim,
Khasim Syed Mohammed wrote:
To get USB HOST mode working on USB OTG Port with USB TTY enabled U-boot
Apply this against http://www.beagleboard.org/linux-2.6.git (branch :
2.6.28-oe-r8)
http://www.beagleboard.org/gitweb/?p=linux-2.6.git;a=shortlog;h=2.6.28-oe-r8
Ah, sorry, you state it really clearly, but looking over the patches
quickly I missed that this patch (workaround?) is for Linux kernel
while the other patches are for U-Boot.
Do you have any idea what we are doing wrong in U-Boot that this is
needed? Or does kernel just not expect an already configured MUSB?
Then this patch should go to l-o?
Best regards
Dirk
Hi Dirk,
Hi Khasim,
Khasim Syed Mohammed wrote:
To get USB HOST mode working on USB OTG Port with USB TTY enabled U-boot
Apply this against http://www.beagleboard.org/linux-2.6.git (branch :
2.6.28-oe-r8)
http://www.beagleboard.org/gitweb/?p=linux-2.6.git;a=shortlog;h=2.6.28-oe-r8Ah, sorry, you state it really clearly, but looking over the patches
quickly I missed that this patch (workaround?) is for Linux kernel
while the other patches are for U-Boot.
Yes , this patch is for kernel. I currently call this as a work around
and would like some USB experts to look into the same.
Do you have any idea what we are doing wrong in U-Boot that this is
needed?
According to me there is nothing wrong in u-boot and its perfect.
Or does kernel just not expect an already configured MUSB?
Yes, the device doesn't seem to in HOST mode after working as an OTG,
till we reset the PHY.
Then this patch should go to l-o?
I was discussing the same with Anand Gadiyar, his suggestion was to
use MUSB ULPI commands to trigger reset to PHY than using T2 over I2C.
I am waiting for Anand to give me the commands / reg description to
try it out. He should be doing the same this week.
Till then, here is the fix. This will help us to freeze on u-boot.
Regards,
Khasim
Hi Dirk,
Hi Khasim,
Khasim Syed Mohammed wrote:
To get USB HOST mode working on USB OTG Port with USB TTY enabled U-boot
Apply this against http://www.beagleboard.org/linux-2.6.git (branch :
2.6.28-oe-r8)
http://www.beagleboard.org/gitweb/?p=linux-2.6.git;a=shortlog;h=2.6.28-oe-r8Ah, sorry, you state it really clearly, but looking over the patches
quickly I missed that this patch (workaround?) is for Linux kernel
while the other patches are for U-Boot.Yes , this patch is for kernel. I currently call this as a work around
and would like some USB experts to look into the same.Do you have any idea what we are doing wrong in U-Boot that this is
needed?According to me there is nothing wrong in u-boot and its perfect.
Or does kernel just not expect an already configured MUSB?
Yes, the device doesn't seem to in HOST mode after working as an OTG,
till we reset the PHY.Then this patch should go to l-o?
I was discussing the same with Anand Gadiyar, his suggestion was to
use MUSB ULPI commands to trigger reset to PHY than using T2 over I2C.
I am waiting for Anand to give me the commands / reg description to
try it out. He should be doing the same this week.Till then, here is the fix. This will help us to freeze on u-boot.
Small correction. Using the MUSB's ULPI access to trigger the PHY
reset is another way of doing this - not necessarily the preferred
way.
This access method is useful for PHY's that have no alternative access
possible (ISP15xx, ISP17xx). For the TWL4030/5030 where I2C access is
possible, that can be just as good.
I'm guessing both methods are equally effective, but only the I2C way
is tested right now.
I'll try and dig up the method of controlling the PHY registers over
ULPI and pass it to Khasim tomorrow.
Thanks,
Anand
> Hi Dirk,
>
>>
>> Hi Khasim,
>>
>> Khasim Syed Mohammed wrote:
>>> To get USB HOST mode working on USB OTG Port with USB TTY enabled U-boot
>>>
>>> Apply this against http://www.beagleboard.org/linux-2.6.git (branch :
>>> 2.6.28-oe-r8)
>>> http://www.beagleboard.org/gitweb/?p=linux-2.6.git;a=shortlog;h=2.6.28-oe-r8
>>
>> Ah, sorry, you state it really clearly, but looking over the patches
>> quickly I missed that this patch (workaround?) is for Linux kernel
>> while the other patches are for U-Boot.
>>
> Yes , this patch is for kernel. I currently call this as a work around
> and would like some USB experts to look into the same.
>
>> Do you have any idea what we are doing wrong in U-Boot that this is
>> needed?
> According to me there is nothing wrong in u-boot and its perfect.
>
>> Or does kernel just not expect an already configured MUSB?
> Yes, the device doesn't seem to in HOST mode after working as an OTG,
> till we reset the PHY.
>
>> Then this patch should go to l-o?
> I was discussing the same with Anand Gadiyar, his suggestion was to
> use MUSB ULPI commands to trigger reset to PHY than using T2 over I2C.
> I am waiting for Anand to give me the commands / reg description to
> try it out. He should be doing the same this week.
>
> Till then, here is the fix. This will help us to freeze on u-boot.Small correction. Using the MUSB's ULPI access to trigger the PHY
reset is another way of doing this - not necessarily the preferred
way.This access method is useful for PHY's that have no alternative access
possible (ISP15xx, ISP17xx). For the TWL4030/5030 where I2C access is
possible, that can be just as good.I'm guessing both methods are equally effective, but only the I2C way
is tested right now.I'll try and dig up the method of controlling the PHY registers over
ULPI and pass it to Khasim tomorrow.
I have ulpi_read/writeb done:
/* ULPI Registers */
#define ULPI_VBUS_CONTROL 0x70 /* 8 bit */
#define ULPI_CARKIT_CONTROL 0x71 /* 8 bit */
#define ULPI_INT_MASK 0x72 /* 8 bit */
#define ULPI_INT_SRC 0x73 /* 8 bit */
#define ULPI_REG_DATA 0x74 /* 8 bit */
#define ULPI_REG_ADDR 0x75 /* 8 bit */
#define ULPI_REG_CONTROL 0x76 /* 8 bit */
#define ULPI_RAW_DATA 0x77 /* 8 bit */
static inline u8 musb_ulpi_readb(void __iomem *addr, u8 offset)
{
int i = 0;
u8 r;
musb_writeb(addr, ULPI_REG_ADDR, offset);
musb_writeb(addr, ULPI_REG_CONTROL, ULPI_REG_REQ | ULPI_RDN_WR);
while (!(musb_readb(addr, ULPI_REG_CONTROL) & ULPI_REG_CMPLT)) {
i++;
if (i == 10000) {
DBG(3, "ULPI read timed out\n");
return 0;
}
}
r = musb_readb(addr, ULPI_REG_CONTROL);
r &= ~ULPI_REG_CMPLT;
musb_writeb(addr, ULPI_REG_CONTROL, r);
return musb_readb(addr, ULPI_REG_DATA);
}
static inline void musb_ulpi_writeb(void __iomem *addr,
u8 offset, u8 data)
{
int i = 0;
u8 r = 0;
musb_writeb(addr, ULPI_REG_ADDR, offset);
musb_writeb(addr, ULPI_REG_DATA, data);
musb_writeb(addr, ULPI_REG_CONTROL, ULPI_REG_REQ);
while(!(musb_readb(addr, ULPI_REG_CONTROL) & ULPI_REG_CMPLT)) {
i++;
if (i == 10000) {
DBG(3, "ULPI write timed out\n");
return;
}
}
r = musb_readb(addr, ULPI_REG_CONTROL);
r &= ~ULPI_REG_CMPLT;
musb_writeb(addr, ULPI_REG_CONTROL, r);
}
add these to musb_regs.h, actually read/write could go to musb_io.h
>>> --- linux-2.6.git/drivers/usb/musb/omap2430.c 2009-01-19
>>> 22:42:18.000000000 +0530
>>> +++ linux-2.6.git/drivers/usb/musb/omap2430.c 2009-02-19
>>> 12:45:22.000000000 +0530
>>> @@ -33,6 +33,7 @@
>>> #include <linux/list.h>
>>> #include <linux/clk.h>
>>> #include <linux/io.h>
>>> +#include <linux/i2c/twl4030.h>
>>>
>>> #include <asm/mach-types.h>
>>> #include <mach/hardware.h>
>>> @@ -233,6 +234,14 @@ int __init musb_platform_init(struct mus
>>> omap_cfg_reg(AE5_2430_USB0HS_STP);
>>> #endif
>>>
>>> + /* Reset MUSB Controller */
>>> + omap_writel(SOFTRST,OTG_SYSCONFIG);
>>> +
>>> +#if defined(CONFIG_TWL4030_USB)
>>> + /* Reset the TWL USB PHY */
>>> + twl4030_i2c_write_u8(TWL4030_MODULE_USB, 0x60, 0x4);
>>> +#endif
>>> +
>>> musb->xceiv = *x;
>>> musb_platform_resume(musb);
Resetting before probing makes sense to me, clears unwanted states left
from bootloader at least, but the twl4030-usb part should go to its
probe function at drivers/usb/otg/twl4030-usb.c
> Hi Dirk,
>
>>
>> Hi Khasim,
>>
>> Khasim Syed Mohammed wrote:
>>> To get USB HOST mode working on USB OTG Port with USB TTY enabled U-boot
>>>
>>> Apply this against http://www.beagleboard.org/linux-2.6.git (branch :
>>> 2.6.28-oe-r8)
>>> http://www.beagleboard.org/gitweb/?p=linux-2.6.git;a=shortlog;h=2.6.28-oe-r8
>>
>> Ah, sorry, you state it really clearly, but looking over the patches
>> quickly I missed that this patch (workaround?) is for Linux kernel
>> while the other patches are for U-Boot.
>>
> Yes , this patch is for kernel. I currently call this as a work around
> and would like some USB experts to look into the same.
>
>> Do you have any idea what we are doing wrong in U-Boot that this is
>> needed?
> According to me there is nothing wrong in u-boot and its perfect.
>
>> Or does kernel just not expect an already configured MUSB?
> Yes, the device doesn't seem to in HOST mode after working as an OTG,
> till we reset the PHY.
>
>> Then this patch should go to l-o?
> I was discussing the same with Anand Gadiyar, his suggestion was to
> use MUSB ULPI commands to trigger reset to PHY than using T2 over I2C.
> I am waiting for Anand to give me the commands / reg description to
> try it out. He should be doing the same this week.
>
> Till then, here is the fix. This will help us to freeze on u-boot.Small correction. Using the MUSB's ULPI access to trigger the PHY
reset is another way of doing this - not necessarily the preferred
way.This access method is useful for PHY's that have no alternative access
possible (ISP15xx, ISP17xx). For the TWL4030/5030 where I2C access is
possible, that can be just as good.I'm guessing both methods are equally effective, but only the I2C way
is tested right now.I'll try and dig up the method of controlling the PHY registers over
ULPI and pass it to Khasim tomorrow.I have ulpi_read/writeb done:
Thanks, I will test them out.
Do you know what exactly what command I should issue (using
musb_ulpi_writeb) to reset the PHY ?
Regards,
Khasim
sorry, I don't 
Write to FUNC_CTRL (register offset 0x04) bit RESET (bit 5).
i.e. (write 0x20 to register addr 0x04).
That should do the trick. The reset is auto-cleared.
Hope this helps.
Anand
Felipe,
drivers/usb/musb/musb_io.h:157: error: 'ULPI_REG_REQ' undeclared
(first use in this function)
drivers/usb/musb/musb_io.h:157: error: (Each undeclared identifier is
reported only once
drivers/usb/musb/musb_io.h:157: error: for each function it appears in.)
drivers/usb/musb/musb_io.h:157: error: 'ULPI_RDN_WR' undeclared (first
use in this function)
drivers/usb/musb/musb_io.h:159: error: 'ULPI_REG_CMPLT' undeclared
(first use in this function)
drivers/usb/musb/musb_io.h: In function 'musb_ulpi_writeb':
drivers/usb/musb/musb_io.h:181: error: 'ULPI_REG_REQ' undeclared
(first use in this function)
drivers/usb/musb/musb_io.h:183: error: 'ULPI_REG_CMPLT' undeclared
(first use in this function)
What is offset for these ?
Regards,
Khasim
Got this fixed with the help of Anand,
#define ULPI_REG_REQ 0x01
#define ULPI_REG_CMPLT 0x02
#define ULPI_RDN_WR 0x04
I am trying to reset the PHY,
musb_ulpi_writeb(musb->mregs,0x04,0x20);
Syntax:
musb_ulpi_writeb(void __iomem *addr, u8 offset, u8 data)
Doesn't seem to work. Do you find any errors in this Call ?
Regards,
Khasim