Re: [linux-usb-devel] EHCI Host not enumerating device
Hi subhash, What was the PHY Chip u have used. My PHY Chip is SMSC USB3300 , which has an reset pin, but is not connected to any pin, but is left as an input, We are trying to find it out. Thanks for ur timely help. Did u come across the same problem of not getting interrupts when u connect a device to the OTG port. But u were able to solve it, when u did a PHY reset, But how did u do the reset... was it software or a separate pin on the board. In my case, GPIO pin from the main board drives the reset pin. Are you using GPIO? Have you verified your main board PCB layout (_not_ ARC controller)? Usually the main board provides set of GPIO registers, so you need to set the approproate bit in one of those registers to drive that pin. If it is a software reset, then can u tell me in whcich register did u do that in the ARC Controller, if the PHY register set was not directly accessible. For me the PHY register set is not directly accessible. It has _nothing_ to do with ARC controller, which doesn't provide any way to access PHY registers. When I mentioned check your spec sheet, I'm talking about your _main_ _chip_ that controls entire system, _not_ about ARC controller. Please tell me , what other problems , u had to face, since that would help us in a great deal. Thanks very much rak Thanks, Subhash On 5/22/06, Subhash Reddy Peddamallu [EMAIL PROTECTED] wrote: Hi Subhash, Thanks for ur comments, My PHY chip is SMSC USB3300 chip which is ULPI Compliant, I have gone through the pin diagram of this Chip, There is a pin - 9 in this chip which is the RESET pin for this chip, But i dont see any external reset button facility for this purpose. I was looking for a GPIO pin which when set,would drive the PHY reset, But i was not able to find one in the ARC Controller doc. I don't think you find this info in ARC controller doc, but check your main board spec sheet (and also check PCB sheet where this PHY chip is placed) to know the procedure to drive reset pin, also it will give an idea of what you really need to do. All this are really specific to your system so without knowing board spec sheet, I can't say much. I have a ULPI View port register, which provides indirect access to the ULPI PHY register set. So this one is the register i was looking for. But i ignored it earlier, since it says writes to this register are not guaranteed, not to affect USB Transfers. The ULPI View port register has no bit for ULPI Reset, But bit-31 is for ULPI Wakeup. If u have used ARC, and was ur PHY SMSC 3300 , if it is , please provide information on how to reset. I'm not familiar with PHY SMSC 3300 chip! Also, which device have u used to connect to the OTG port. Thanks Rakesh Thanks, Subhash On 5/19/06, Subhash Reddy Peddamallu [EMAIL PROTECTED] wrote: Hi Rakesh, Hi Subash, I am using ARC HS-OTG Core with ULPI Interface. Hope the ARC PHY u are referring to is this ULPI interface. That means you do have ULPI tranceiver chip, that actually provides USB PHY interface. BTW, it's not ARC PHY here. My kernel is 2.6.16-11, the thing is that in device controller mode , we are receiving interrupts. Can u provide some information on the following:- 1) What is the device u have used to plug in to the ARC. Since the ARC HS Core is OTG in our case, we cannot connect a device with power requirements of more that 8mA, and it should be self powered also. I don't get your question! Are you asking, which device I plugged in to the USB port? 2) We have in our docs , only one to reset , that is the ARC Controller Core. If the controller u used has an ULPI interface, can u tell me how did u reset the PHY. I think you need to reset ULPI tranceiver chip. Check your ULPI tranceiver chip data sheet to make sure whether you need to reset. (usually in pin diagram, look for external reset pin). If there is reset pin, then there should be a some GPIO pin from your main board that drives the ULPI reset pin. One more thing, see pins that connect your main board ULPI chip are configured correctly. I mean, in some cases those pins are dual-role pins so you need to configure them for USB operation. Most of the stuff is platform specific, so I can't say where the problem is. 3) The thing is the root hub is getting recognized correctly, that means the controller has been properly initialised is what i think. Correct me if i am wrong. See cat /proc/interrupts to make sure you are getting interrupts in normal device mode. Also post cat /proc/bus/usb/devices before after plugging in a device into USB port. Please help me with ur comments, since u have already worked on this. Thanks Rak Subhash PS: cc'ing to linux-usb-devel@lists.sourceforge.net, so that
Re: [linux-usb-devel] EHCI Host not enumerating device
Hi Subhash, Thanks for ur comments, My PHY chip is SMSC USB3300 chip which is ULPI Compliant, I have gone through the pin diagram of this Chip, There is a pin - 9 in this chip which is the RESET pin for this chip, But i dont see any external reset button facility for this purpose. I was looking for a GPIO pin which when set,would drive the PHY reset, But i was not able to find one in the ARC Controller doc. I don't think you find this info in ARC controller doc, but check your main board spec sheet (and also check PCB sheet where this PHY chip is placed) to know the procedure to drive reset pin, also it will give an idea of what you really need to do. All this are really specific to your system so without knowing board spec sheet, I can't say much. I have a ULPI View port register, which provides indirect access to the ULPI PHY register set. So this one is the register i was looking for. But i ignored it earlier, since it says writes to this register are not guaranteed, not to affect USB Transfers. The ULPI View port register has no bit for ULPI Reset, But bit-31 is for ULPI Wakeup. If u have used ARC, and was ur PHY SMSC 3300 , if it is , please provide information on how to reset. I'm not familiar with PHY SMSC 3300 chip! Also, which device have u used to connect to the OTG port. Thanks Rakesh Thanks, Subhash On 5/19/06, Subhash Reddy Peddamallu [EMAIL PROTECTED] wrote: Hi Rakesh, Hi Subash, I am using ARC HS-OTG Core with ULPI Interface. Hope the ARC PHY u are referring to is this ULPI interface. That means you do have ULPI tranceiver chip, that actually provides USB PHY interface. BTW, it's not ARC PHY here. My kernel is 2.6.16-11, the thing is that in device controller mode , we are receiving interrupts. Can u provide some information on the following:- 1) What is the device u have used to plug in to the ARC. Since the ARC HS Core is OTG in our case, we cannot connect a device with power requirements of more that 8mA, and it should be self powered also. I don't get your question! Are you asking, which device I plugged in to the USB port? 2) We have in our docs , only one to reset , that is the ARC Controller Core. If the controller u used has an ULPI interface, can u tell me how did u reset the PHY. I think you need to reset ULPI tranceiver chip. Check your ULPI tranceiver chip data sheet to make sure whether you need to reset. (usually in pin diagram, look for external reset pin). If there is reset pin, then there should be a some GPIO pin from your main board that drives the ULPI reset pin. One more thing, see pins that connect your main board ULPI chip are configured correctly. I mean, in some cases those pins are dual-role pins so you need to configure them for USB operation. Most of the stuff is platform specific, so I can't say where the problem is. 3) The thing is the root hub is getting recognized correctly, that means the controller has been properly initialised is what i think. Correct me if i am wrong. See cat /proc/interrupts to make sure you are getting interrupts in normal device mode. Also post cat /proc/bus/usb/devices before after plugging in a device into USB port. Please help me with ur comments, since u have already worked on this. Thanks Rak Subhash PS: cc'ing to linux-usb-devel@lists.sourceforge.net, so that other developers can correct us when we go wrong. On 5/19/06, Subhash Reddy Peddamallu [EMAIL PROTECTED] wrote: Hi all, We are testing EHCI driver for ARC based controller core on a ARM 926 board. The platform glue has been written. The driver is compiled to the kernel . When the kernel boots up , the driver is loaded. I used the similar setup, ARC EHCI core with ARM borad. I implemented bus glue, but in 2.4, its working fine. We have enabled USB_DEBUG and then going through the prints, its is observed that the root hub has been identified and given the address 1. Are you sure EHCI controller started correctly? Check cat /proc/bus/usb/devices if you have usbfs. But when we plug a High Speed device , the IRQ function is not even invoked, the STS register and PCD bit in PORTSCx is not showing any change. See cat /proc/interrupts to make sure you really getting interrupts, i.e see before plugging any device after plugging a device. Those who have worked with ARC USB HS-OTG controllers, have u come across these problems, if yes, please help us. I faced the similar problem- with this setup (i.e ARC core on ARM board), at init time you may need to reset USB PHY, probably through GPIO pin or ?? This is just my guess, in my case I forgot to do this it took hours to figure out this. Check with your data sheet make sure you are not seeing this problem. I have no other ideas for what might be causing the problem, if you can post
Re: [linux-usb-devel] EHCI Host not enumerating device
Hi Rakesh, Hi Subash, I am using ARC HS-OTG Core with ULPI Interface. Hope the ARC PHY u are referring to is this ULPI interface. That means you do have ULPI tranceiver chip, that actually provides USB PHY interface. BTW, it's not ARC PHY here. My kernel is 2.6.16-11, the thing is that in device controller mode , we are receiving interrupts. Can u provide some information on the following:- 1) What is the device u have used to plug in to the ARC. Since the ARC HS Core is OTG in our case, we cannot connect a device with power requirements of more that 8mA, and it should be self powered also. I don't get your question! Are you asking, which device I plugged in to the USB port? 2) We have in our docs , only one to reset , that is the ARC Controller Core. If the controller u used has an ULPI interface, can u tell me how did u reset the PHY. I think you need to reset ULPI tranceiver chip. Check your ULPI tranceiver chip data sheet to make sure whether you need to reset. (usually in pin diagram, look for external reset pin). If there is reset pin, then there should be a some GPIO pin from your main board that drives the ULPI reset pin. One more thing, see pins that connect your main board ULPI chip are configured correctly. I mean, in some cases those pins are dual-role pins so you need to configure them for USB operation. Most of the stuff is platform specific, so I can't say where the problem is. 3) The thing is the root hub is getting recognized correctly, that means the controller has been properly initialised is what i think. Correct me if i am wrong. See cat /proc/interrupts to make sure you are getting interrupts in normal device mode. Also post cat /proc/bus/usb/devices before after plugging in a device into USB port. Please help me with ur comments, since u have already worked on this. Thanks Rak Subhash PS: cc'ing to linux-usb-devel@lists.sourceforge.net, so that other developers can correct us when we go wrong. On 5/19/06, Subhash Reddy Peddamallu [EMAIL PROTECTED] wrote: Hi all, We are testing EHCI driver for ARC based controller core on a ARM 926 board. The platform glue has been written. The driver is compiled to the kernel . When the kernel boots up , the driver is loaded. I used the similar setup, ARC EHCI core with ARM borad. I implemented bus glue, but in 2.4, its working fine. We have enabled USB_DEBUG and then going through the prints, its is observed that the root hub has been identified and given the address 1. Are you sure EHCI controller started correctly? Check cat /proc/bus/usb/devices if you have usbfs. But when we plug a High Speed device , the IRQ function is not even invoked, the STS register and PCD bit in PORTSCx is not showing any change. See cat /proc/interrupts to make sure you really getting interrupts, i.e see before plugging any device after plugging a device. Those who have worked with ARC USB HS-OTG controllers, have u come across these problems, if yes, please help us. I faced the similar problem- with this setup (i.e ARC core on ARM board), at init time you may need to reset USB PHY, probably through GPIO pin or ?? This is just my guess, in my case I forgot to do this it took hours to figure out this. Check with your data sheet make sure you are not seeing this problem. I have no other ideas for what might be causing the problem, if you can post your bus glue code. I am attaching the log of trace i did. It's really difficult to understand this log with your printk's, better if you takeout your own printk's its enough to have USB_DEBUG enabled. Thanks Rak Hope this helps! Subhash Function register_root_hub is called ,root hub device address = 1 issuing get_descriptor in register_root_hub Function usb_get_device_descriptor called Function usb_get_descriptor called Function usb_submit_urb called Function hcd_submit_urb is called Calling function rh_urb_enqueue to queue Setup URB to Root Hub Function rh_call_control called...This ultimately calls hc_driver-hub_control rh_call_control URB setup_packet contents in rh_call_control typeReq = 8006, wValue = 100, wIndex = 0, wLength = 12 Issued usb_control_msg request. result = 18 Function usb_get_descriptor Returned leaving function usb_get_device_descriptor Length of received desc is 0x12 12 1 0 2 9 0 1 40 0 0 0 0 6 2 3 2 1 1 Function usb_new_device called Function usb_get_configuration called for root-hub No of configurations for root-hub = 1 Function usb_get_descriptor called Function usb_submit_urb called Function hcd_submit_urb is called Calling function rh_urb_enqueue to queue Setup URB to Root Hub Function rh_call_control called...This ultimately calls hc_driver-hub_control rh_call_control URB setup_packet contents in rh_call_control typeReq = 8006, wValue = 200, wIndex = 0,
Re: [linux-usb-devel] EHCI Host not enumerating device
Hi all, We are testing EHCI driver for ARC based controller core on a ARM 926 board. The platform glue has been written. The driver is compiled to the kernel . When the kernel boots up , the driver is loaded. I used the similar setup, ARC EHCI core with ARM borad. I implemented bus glue, but in 2.4, its working fine. We have enabled USB_DEBUG and then going through the prints, its is observed that the root hub has been identified and given the address 1. Are you sure EHCI controller started correctly? Check cat /proc/bus/usb/devices if you have usbfs. But when we plug a High Speed device , the IRQ function is not even invoked, the STS register and PCD bit in PORTSCx is not showing any change. See cat /proc/interrupts to make sure you really getting interrupts, i.e see before plugging any device after plugging a device. Those who have worked with ARC USB HS-OTG controllers, have u come across these problems, if yes, please help us. I faced the similar problem- with this setup (i.e ARC core on ARM board), at init time you may need to reset USB PHY, probably through GPIO pin or ?? This is just my guess, in my case I forgot to do this it took hours to figure out this. Check with your data sheet make sure you are not seeing this problem. I have no other ideas for what might be causing the problem, if you can post your bus glue code. I am attaching the log of trace i did. It's really difficult to understand this log with your printk's, better if you takeout your own printk's its enough to have USB_DEBUG enabled. Thanks Rak Hope this helps! Subhash Function register_root_hub is called ,root hub device address = 1 issuing get_descriptor in register_root_hub Function usb_get_device_descriptor called Function usb_get_descriptor called Function usb_submit_urb called Function hcd_submit_urb is called Calling function rh_urb_enqueue to queue Setup URB to Root Hub Function rh_call_control called...This ultimately calls hc_driver-hub_control rh_call_control URB setup_packet contents in rh_call_control typeReq = 8006, wValue = 100, wIndex = 0, wLength = 12 Issued usb_control_msg request. result = 18 Function usb_get_descriptor Returned leaving function usb_get_device_descriptor Length of received desc is 0x12 12 1 0 2 9 0 1 40 0 0 0 0 6 2 3 2 1 1 Function usb_new_device called Function usb_get_configuration called for root-hub No of configurations for root-hub = 1 Function usb_get_descriptor called Function usb_submit_urb called Function hcd_submit_urb is called Calling function rh_urb_enqueue to queue Setup URB to Root Hub Function rh_call_control called...This ultimately calls hc_driver-hub_control rh_call_control URB setup_packet contents in rh_call_control typeReq = 8006, wValue = 200, wIndex = 0, wLength = 9 Issued usb_control_msg request. result = 9 Function usb_get_descriptor Returned Function usb_get_descriptor called Function usb_submit_urb called Function hcd_submit_urb is called Calling function rh_urb_enqueue to queue Setup URB to Root Hub Function rh_call_control called...This ultimately calls hc_driver-hub_control rh_call_control URB setup_packet contents in rh_call_control typeReq = 8006, wValue = 200, wIndex = 0, wLength = 19 Issued usb_control_msg request. result = 25 Function usb_get_descriptor Returned Returned from function usb_get_configuration Function usb_submit_urb called Function hcd_submit_urb is called Calling function rh_urb_enqueue to queue Setup URB to Root Hub Function rh_call_control called...This ultimately calls hc_driver-hub_control rh_call_control URB setup_packet contents in rh_call_control typeReq = 8006, wValue = 300, wIndex = 0, wLength = ff usb usb1: default language 0x0409 Function usb_submit_urb called Function hcd_submit_urb is called Calling function rh_urb_enqueue to queue Setup URB to Root Hub Function rh_call_control called...This ultimately calls hc_driver-hub_control rh_call_control URB setup_packet contents in rh_call_control typeReq = 8006, wValue = 302, wIndex = 409, wLength = ff Function usb_submit_urb called Function hcd_submit_urb is called Calling function rh_urb_enqueue to queue Setup URB to Root Hub Function rh_call_control called...This ultimately calls hc_driver-hub_control rh_call_control URB setup_packet contents in rh_call_control typeReq = 8006, wValue = 303, wIndex = 409, wLength = ff Function usb_submit_urb called Function hcd_submit_urb is called Calling function rh_urb_enqueue to queue Setup URB to Root Hub Function rh_call_control called...This ultimately calls hc_driver-hub_control rh_call_control URB setup_packet contents in rh_call_control typeReq = 8006, wValue = 301, wIndex = 409, wLength = ff usb usb1: new device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: EHCI Host Controller usb usb1: Manufacturer: Linux 2.6.16.11 ehci_hcd usb usb1:
