Re: [PATCH] Freescale QUICC Engine USB Host Controller
On Wednesday 09 April 2008 14:16, Pandita, Vikram wrote: What does QUICC stand for? QUICC stands for QUad Integrated Communications Controller. http://en.wikipedia.org/wiki/PowerQUICC Am getting confused with SmartCard UICC. Is it anyway related? They are not related. -- Laurent Pinchart CSE Semaphore Belgium Chaussee de Bruxelles, 732A B-1410 Waterloo Belgium T +32 (2) 387 42 59 F +32 (2) 387 42 75 pgpuD2XRSWp41.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Freescale QUICC Engine USB Host Controller
On Tuesday 08 April 2008 14:16, Anton Vorontsov wrote: On Mon, Apr 07, 2008 at 06:11:15PM +0200, Laurent Pinchart wrote: [...] I had a first go at hacking the FHCI driver to make it run on a CPM2 platform. Results so far are quite good. After getting rid of qe-specific APIs as explained above, and adding SOF token generation support, I've been able to access a mass storage device. The driver hasn't been stress-tested yet though. Wow, awesome! That's great news, really. Looking forward for the patch. :-) The current version of the code is CPM2-specific and won't work on QE-based platforms. Should I still post it ? I ran into an issue with IDLE and RESET interrupts. When the device is first plugged into the USB port, the idle interrupt kicks in and the driver detects the device properly. When the device is then removed, the reset interrupt is generated and the driver handles device removal properly. Right after the reset interrupt, idle interrupts are generated every milliseconds for around 175ms. The status register always reports a non-idle condition when read in the interrupt handler. The flow of idle interrupts then stops, and no idle interrupt is generated when I replug the device. I've checked the interrupts mask register to make sure idle interrupts were enabled. Have you noticed a similar behaviour when you tested the driver on your QE-based platform ? I suspected a debouncing issue, but I should then get idle conditions once every other time when reading the status register. Hm.. nope, I didn't see anything like that, at least not something that is affecting the driver functionality. Did out_be16(tmr-gtevr, 0x); help there? Or it's different problem? No it didn't, it's a completely different problem. The IDLE interrupts I see every millisecond for around 175ms after disconnecting the device are probably due to the SOF tokens sent between device disconnection and the fhci_stop_sof_timer() call. Calling fhci_stop_sof_timer() in device_disconnected_interrupt() prevents spurious idle interrupts from being generated. After further investigation I found out why no idle interrupt were generated when replugging the device. Upon disconnection the FHCI driver turns bus power off by setting the suspend GPIO pin high. As the signal is connected to the suspend input of the USB phy on my hardware, setting the signal high turned the phy off, disconnecting the RP and RN signals completely. I solved the issue by referencing the bus power control GPIO instead of the suspend GPIO in the device tree. GPIO_SUSPN should really be renamed GPIO_POWER. -- Laurent Pinchart CSE Semaphore Belgium Chaussee de Bruxelles, 732A B-1410 Waterloo Belgium T +32 (2) 387 42 59 F +32 (2) 387 42 75 pgpAzepHbsJHa.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] Freescale QUICC Engine USB Host Controller
What does QUICC stand for? Am getting confused with SmartCard UICC. Is it anyway related? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Laurent Pinchart Sent: Wednesday, April 09, 2008 5:44 PM To: [EMAIL PROTECTED] Cc: linuxppc-dev@ozlabs.org; [EMAIL PROTECTED]; Timur Tabi; Scott Wood; David Brownell Subject: Re: [PATCH] Freescale QUICC Engine USB Host Controller On Tuesday 08 April 2008 14:16, Anton Vorontsov wrote: On Mon, Apr 07, 2008 at 06:11:15PM +0200, Laurent Pinchart wrote: [...] I had a first go at hacking the FHCI driver to make it run on a CPM2 platform. Results so far are quite good. After getting rid of qe-specific APIs as explained above, and adding SOF token generation support, I've been able to access a mass storage device. The driver hasn't been stress-tested yet though. Wow, awesome! That's great news, really. Looking forward for the patch. :-) The current version of the code is CPM2-specific and won't work on QE-based platforms. Should I still post it ? I ran into an issue with IDLE and RESET interrupts. When the device is first plugged into the USB port, the idle interrupt kicks in and the driver detects the device properly. When the device is then removed, the reset interrupt is generated and the driver handles device removal properly. Right after the reset interrupt, idle interrupts are generated every milliseconds for around 175ms. The status register always reports a non-idle condition when read in the interrupt handler. The flow of idle interrupts then stops, and no idle interrupt is generated when I replug the device. I've checked the interrupts mask register to make sure idle interrupts were enabled. Have you noticed a similar behaviour when you tested the driver on your QE-based platform ? I suspected a debouncing issue, but I should then get idle conditions once every other time when reading the status register. Hm.. nope, I didn't see anything like that, at least not something that is affecting the driver functionality. Did out_be16(tmr-gtevr, 0x); help there? Or it's different problem? No it didn't, it's a completely different problem. The IDLE interrupts I see every millisecond for around 175ms after disconnecting the device are probably due to the SOF tokens sent between device disconnection and the fhci_stop_sof_timer() call. Calling fhci_stop_sof_timer() in device_disconnected_interrupt() prevents spurious idle interrupts from being generated. After further investigation I found out why no idle interrupt were generated when replugging the device. Upon disconnection the FHCI driver turns bus power off by setting the suspend GPIO pin high. As the signal is connected to the suspend input of the USB phy on my hardware, setting the signal high turned the phy off, disconnecting the RP and RN signals completely. I solved the issue by referencing the bus power control GPIO instead of the suspend GPIO in the device tree. GPIO_SUSPN should really be renamed GPIO_POWER. -- Laurent Pinchart CSE Semaphore Belgium Chaussee de Bruxelles, 732A B-1410 Waterloo Belgium T +32 (2) 387 42 59 F +32 (2) 387 42 75 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Freescale QUICC Engine USB Host Controller
On Mon, Apr 07, 2008 at 06:11:15PM +0200, Laurent Pinchart wrote: [...] I had a first go at hacking the FHCI driver to make it run on a CPM2 platform. Results so far are quite good. After getting rid of qe-specific APIs as explained above, and adding SOF token generation support, I've been able to access a mass storage device. The driver hasn't been stress-tested yet though. Wow, awesome! That's great news, really. Looking forward for the patch. :-) I ran into an issue with IDLE and RESET interrupts. When the device is first plugged into the USB port, the idle interrupt kicks in and the driver detects the device properly. When the device is then removed, the reset interrupt is generated and the driver handles device removal properly. Right after the reset interrupt, idle interrupts are generated every milliseconds for around 175ms. The status register always reports a non-idle condition when read in the interrupt handler. The flow of idle interrupts then stops, and no idle interrupt is generated when I replug the device. I've checked the interrupts mask register to make sure idle interrupts were enabled. Have you noticed a similar behaviour when you tested the driver on your QE-based platform ? I suspected a debouncing issue, but I should then get idle conditions once every other time when reading the status register. Hm.. nope, I didn't see anything like that, at least not something that is affecting the driver functionality. Did out_be16(tmr-gtevr, 0x); help there? Or it's different problem? -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Freescale QUICC Engine USB Host Controller
Hi Anton, On Thursday 03 April 2008 16:30, Anton Vorontsov wrote: On Thu, Apr 03, 2008 at 03:45:47PM +0200, Laurent Pinchart wrote: Hi Anton, On Tuesday 11 March 2008 20:17, Anton Vorontsov wrote: This is patch adds support for the FHCI USB controller, as found in the Freescale MPC836x and MPC832x processors. It can support Full or Low speed modes. Quite a lot hardware is doing by itself (SOF generation, CRC generation and checking), though scheduling and retransmission is on the software shoulders. This controller does not integrate the root hub, so this driver also fakes an one-port hub. External hub is required to support more than one device. Would it be possible to use the driver for CPM2-based devices ? Probably. But no one had tried this yet. The only difference I found between the CPM2 and QE USB controllers is the SOF handling. The QE USB controller increments the frame number itself, while the CPM USB controller requires the host to increment the frame number. At first sight the driver depends on qe_lib for: - muram allocation (qe_muram_alloc/free, qe_muram_offset/addr) Yeah, I already posted a patch to deal with it, see http://ozlabs.org/pipermail/linuxppc-dev/2008-March/053249.html (btw... Scott, Timur did you have a chance to look into this?) Hope this will get into 2.6.26. I replaced all occurences of qe_muram_* by cpm_muram_* in the driver for now. - GPIO access (qe_gpio_set_dedicated) This is because of David Brownell. ;-) Specifically, unwillingness to accept that set_dedicated is portable for some scope of GPIO controllers, as well as GPIO users. Both sides have their arguments. As the FHCI driver is tied to CPM2/QE platforms anyway, a quick-and-dirty workaround is possible. I currently use hardcoded cpm2_set_pin calls. - clock routing (qe_clock_source, qe_usb_clock_set) Well, there is Linux CLK API (somewhat similar to GPIO API), but PowerPC doesn't use it yet. Neither I can tell if CLK API is suitable for our needs, or if it needs to be extended. Quickdirty workarounds are still possible though, but clk api is the right way to go. The current clock API doesn't seem to handle clock routing, so I'm not sure what the best way to handle that is. - QE commands execution (qe_issue_cmd) No proper solution yet. It shouldn't be too difficult to abstract those operation in a fashion similar to the cpm_uart driver. Yup, but we still have ucc_serial (QE) and cpm_uart (CPM1/2) drivers as separate matters though. ;-) I didn't look for the reasons of this split but I assume there are and they're strong enough. Have you already worked on CPM2 support, Nope, I don't have CPM2 board to work on. I had a first go at hacking the FHCI driver to make it run on a CPM2 platform. Results so far are quite good. After getting rid of qe-specific APIs as explained above, and adding SOF token generation support, I've been able to access a mass storage device. The driver hasn't been stress-tested yet though. I ran into an issue with IDLE and RESET interrupts. When the device is first plugged into the USB port, the idle interrupt kicks in and the driver detects the device properly. When the device is then removed, the reset interrupt is generated and the driver handles device removal properly. Right after the reset interrupt, idle interrupts are generated every milliseconds for around 175ms. The status register always reports a non-idle condition when read in the interrupt handler. The flow of idle interrupts then stops, and no idle interrupt is generated when I replug the device. I've checked the interrupts mask register to make sure idle interrupts were enabled. Have you noticed a similar behaviour when you tested the driver on your QE-based platform ? I suspected a debouncing issue, but I should then get idle conditions once every other time when reading the status register. Best regards, -- Laurent Pinchart CSE Semaphore Belgium Chaussee de Bruxelles, 732A B-1410 Waterloo Belgium T +32 (2) 387 42 59 F +32 (2) 387 42 75 pgp2CP9oIsraU.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Freescale QUICC Engine USB Host Controller
Hi Anton, On Tuesday 11 March 2008 20:17, Anton Vorontsov wrote: This is patch adds support for the FHCI USB controller, as found in the Freescale MPC836x and MPC832x processors. It can support Full or Low speed modes. Quite a lot hardware is doing by itself (SOF generation, CRC generation and checking), though scheduling and retransmission is on the software shoulders. This controller does not integrate the root hub, so this driver also fakes an one-port hub. External hub is required to support more than one device. Would it be possible to use the driver for CPM2-based devices ? The only difference I found between the CPM2 and QE USB controllers is the SOF handling. The QE USB controller increments the frame number itself, while the CPM USB controller requires the host to increment the frame number. At first sight the driver depends on qe_lib for: - muram allocation (qe_muram_alloc/free, qe_muram_offset/addr) - GPIO access (qe_gpio_set_dedicated) - clock routing (qe_clock_source, qe_usb_clock_set) - QE commands execution (qe_issue_cmd) It shouldn't be too difficult to abstract those operation in a fashion similar to the cpm_uart driver. Have you already worked on CPM2 support, or thought about any particular issue I should pay attention to ? Best regards, -- Laurent Pinchart CSE Semaphore Belgium Chaussee de Bruxelles, 732A B-1410 Waterloo Belgium T +32 (2) 387 42 59 F +32 (2) 387 42 75 pgp07XJ52R2ik.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Freescale QUICC Engine USB Host Controller
On Thu, Apr 03, 2008 at 03:45:47PM +0200, Laurent Pinchart wrote: Hi Anton, On Tuesday 11 March 2008 20:17, Anton Vorontsov wrote: This is patch adds support for the FHCI USB controller, as found in the Freescale MPC836x and MPC832x processors. It can support Full or Low speed modes. Quite a lot hardware is doing by itself (SOF generation, CRC generation and checking), though scheduling and retransmission is on the software shoulders. This controller does not integrate the root hub, so this driver also fakes an one-port hub. External hub is required to support more than one device. Would it be possible to use the driver for CPM2-based devices ? Probably. But no one had tried this yet. The only difference I found between the CPM2 and QE USB controllers is the SOF handling. The QE USB controller increments the frame number itself, while the CPM USB controller requires the host to increment the frame number. At first sight the driver depends on qe_lib for: - muram allocation (qe_muram_alloc/free, qe_muram_offset/addr) Yeah, I already posted a patch to deal with it, see http://ozlabs.org/pipermail/linuxppc-dev/2008-March/053249.html (btw... Scott, Timur did you have a chance to look into this?) - GPIO access (qe_gpio_set_dedicated) This is because of David Brownell. ;-) Specifically, unwillingness to accept that set_dedicated is portable for some scope of GPIO controllers, as well as GPIO users. - clock routing (qe_clock_source, qe_usb_clock_set) Well, there is Linux CLK API (somewhat similar to GPIO API), but PowerPC doesn't use it yet. Neither I can tell if CLK API is suitable for our needs, or if it needs to be extended. Quickdirty workarounds are still possible though, but clk api is the right way to go. - QE commands execution (qe_issue_cmd) No proper solution yet. It shouldn't be too difficult to abstract those operation in a fashion similar to the cpm_uart driver. Yup, but we still have ucc_serial (QE) and cpm_uart (CPM1/2) drivers as separate matters though. ;-) I didn't look for the reasons of this split but I assume there are and they're strong enough. Have you already worked on CPM2 support, Nope, I don't have CPM2 board to work on. or thought about any particular issue I should pay attention to ? Nope, sorry. -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Freescale QUICC Engine USB Host Controller
On Thu, Apr 03, 2008 at 06:30:52PM +0400, Anton Vorontsov wrote: On Thu, Apr 03, 2008 at 03:45:47PM +0200, Laurent Pinchart wrote: At first sight the driver depends on qe_lib for: - muram allocation (qe_muram_alloc/free, qe_muram_offset/addr) Yeah, I already posted a patch to deal with it, see http://ozlabs.org/pipermail/linuxppc-dev/2008-March/053249.html (btw... Scott, Timur did you have a chance to look into this?) It looks fine to me. It shouldn't be too difficult to abstract those operation in a fashion similar to the cpm_uart driver. Yup, but we still have ucc_serial (QE) and cpm_uart (CPM1/2) drivers as separate matters though. ;-) I didn't look for the reasons of this split but I assume there are and they're strong enough. Not really. :-) The reason was because the work hasn't been done yet to merge the infrastructure for CPM and QE. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Freescale QUICC Engine USB Host Controller
Anton Vorontsov wrote: Yeah, I already posted a patch to deal with it, see http://ozlabs.org/pipermail/linuxppc-dev/2008-March/053249.html (btw... Scott, Timur did you have a chance to look into this?) Seems to be okay. I presume the code actually works with these changes. :-) My only concern is that the functions are still called cpm_ even though they apply to the CPM and the QE. Sure, the QE is really just CPM3, but I'd like to see a nomenclature that's more inclusive. We should also be able to get rid of cpm_alloc/free functions anyway, since they're just front-ends to the rheap code. But that's a problem for another time. Well, there is Linux CLK API (somewhat similar to GPIO API), but PowerPC doesn't use it yet. Yeah, I noticed that too. I'll add it to my to-do list, but I suspect that someone else will get around to it before I do. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Freescale QUICC Engine USB Host Controller
On Thu, Apr 03, 2008 at 10:33:04AM -0500, Timur Tabi wrote: My only concern is that the functions are still called cpm_ even though they apply to the CPM and the QE. Sure, the QE is really just CPM3, but I'd like to see a nomenclature that's more inclusive. Yeah, but cpmqe would be too clunky. I went with cpm since it has seniority. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Freescale QUICC Engine USB Host Controller
On Thursday 03 April 2008, Timur Tabi wrote: Well, there is Linux CLK API (somewhat similar to GPIO API), but PowerPC doesn't use it yet. Yeah, I noticed that too. I'll add it to my to-do list, but I suspect that someone else will get around to it before I do. Note that there's some work afoot to provide a generic implementation framework for the clk_*() calls. It was last posted on the ARM list ... I'd hope it would make it easier for at least some PowerPC platforms to support that interface. - Dave ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] Freescale QUICC Engine USB Host Controller
-Original Message- From: [EMAIL PROTECTED] [mailto:linuxppc-dev- [EMAIL PROTECTED] On Behalf Of Anton Vorontsov Sent: den 11 mars 2008 20:18 To: [EMAIL PROTECTED]; linuxppc-dev@ozlabs.org Subject: [PATCH] Freescale QUICC Engine USB Host Controller This is patch adds support for the FHCI USB controller, as found in the Freescale MPC836x and MPC832x processors. It can support Full or Low speed modes. Quite a lot hardware is doing by itself (SOF generation, CRC generation and checking), though scheduling and retransmission is on the software shoulders. This controller does not integrate the root hub, so this driver also fakes an one-port hub. External hub is required to support more than one device. Cool, can one turn this into a gadget driver too? Jocke ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
