Freescale QUICC Engine USB Host Controller
PATCH 1/1 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.
--- drivers/usb/Makefile | 1 + drivers/usb/host/Kconfig | 18 + drivers/usb/host/Makefile | 2 +- drivers/usb/host/fhci-cq.c | 105 +++++ drivers/usb/host/fhci-dbg.c | 144 +++++++ drivers/usb/host/fhci-hcd.c | 789 +++++++++++++++++++++++++++++++++++++ drivers/usb/host/fhci-hub.c | 336 ++++++++++++++++ drivers/usb/host/fhci-mem.c | 105 +++++ drivers/usb/host/fhci-q.c | 242 ++++++++++++ drivers/usb/host/fhci-sched.c | 865 +++++++++++++++++++++++++++++++++++++++++ drivers/usb/host/fhci-tds.c | 631 ++++++++++++++++++++++++++++++ drivers/usb/host/fhci.h | 535 +++++++++++++++++++++++++ 12 files changed, 3772 insertions(+), 1 deletions(-) create mode 100644 drivers/usb/host/fhci-cq.c create mode 100644 drivers/usb/host/fhci-dbg.c create mode 100644 drivers/usb/host/fhci-hcd.c create mode 100644 drivers/usb/host/fhci-hub.c create mode 100644 drivers/usb/host/fhci-mem.c create mode 100644 drivers/usb/host/fhci-q.c create mode 100644 drivers/usb/host/fhci-sched.c create mode 100644 drivers/usb/host/fhci-tds.c create mode 100644 drivers/usb/host/fhci.h
drivers/usb/Makefile +1 -0
@@ -16,6 +16,7 @@ obj-$(CONFIG_USB_UHCI_HCD) += host/ obj-$(CONFIG_USB_SL811_HCD) += host/ obj-$(CONFIG_USB_U132_HCD) += host/ obj-$(CONFIG_USB_R8A66597_HCD) += host/ +obj-$(CONFIG_USB_FHCI_HCD) += host/ obj-$(CONFIG_USB_ACM) += class/ obj-$(CONFIG_USB_PRINTER) += class/
drivers/usb/host/Kconfig +18 -0
@@ -260,3 +260,21 @@ config USB_R8A66597_HCD To compile this driver as a module, choose M here: the module will be called r8a66597-hcd. +config USB_FHCI_HCD + tristate "Freescale QE USB Host Controller support" + depends on USB && OF_GPIO && QUICC_ENGINE + select FSL_GTM + help + Some Freescale PowerPC processors (such as MPC8360E and + MPC8323) have a Full/Low Speed QE USB Host controller. + + Say "y" to enable support for such controllers, or "m" to compile + it as a module: the module will be called fhci-hcd. + +config FHCI_DEBUG + bool "Freescale QE USB Host Controller debug support" + depends on USB_FHCI_HCD + select DEBUG_FS + help + Say "y" to see some FHCI debug information and statistics + throught debugfs.
drivers/usb/host/Makefile +1 -1
@@ -16,4 +16,4 @@ obj-$(CONFIG_USB_SL811_HCD) += sl811-hcd.o obj-$(CONFIG_USB_SL811_CS) += sl811_cs.o obj-$(CONFIG_USB_U132_HCD) += u132-hcd.o obj-$(CONFIG_USB_R8A66597_HCD) += r8a66597-hcd.o - +obj-$(CONFIG_USB_FHCI_HCD) += fhci-hcd.o
drivers/usb/host/fhci-cq.c new file +105 -0
105 lines not on this page · raw message
drivers/usb/host/fhci-dbg.c new file +144 -0
144 lines not on this page · raw message
drivers/usb/host/fhci-hcd.c new file +789 -0
789 lines not on this page · raw message
drivers/usb/host/fhci-hub.c new file +336 -0
336 lines not on this page · raw message
drivers/usb/host/fhci-mem.c new file +105 -0
105 lines not on this page · raw message
drivers/usb/host/fhci-q.c new file +242 -0
242 lines not on this page · raw message
drivers/usb/host/fhci-sched.c new file +865 -0
865 lines not on this page · raw message
drivers/usb/host/fhci-tds.c new file +631 -0
381 lines not on this page · raw message
drivers/usb/host/fhci.h new file +535 -0
535 lines not on this page · raw message
The rest of this diff is not shown. View the raw message.
Signature · 1 line
1.5.2.2
Part of the diff is not shown here. View the raw message.
Quoted 11 lines
-----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]; [email protected]
Subject: [PATCH] Freescale QUICC Engine USB Host ControllerThis 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.
Quoted 7 lines
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
Hi Anton,
Quoted 11 lines · Anton Vorontsov
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,
Signature · 9 lines
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
Quoted 11 lines · Laurent Pinchart
Hi Anton,
Quoted 8 lines · Anton Vorontsov
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.
Quoted 5 lines
Quoted 3 lines
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.
Quoted 8 lines
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_libfor:- 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?)
Quoted 1 line
- 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.
Quoted 1 line
- 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. Quick&dirty workarounds are still possible though, but clk api is the right way to go.
Quoted 1 line
- QE commands execution (
qe_issue_cmd)
No proper solution yet.
Quoted 2 lines
It shouldn't be too difficult to abstract those operation in a fashion similar to the
cpm_uartdriver.
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.
Quoted 1 line
Have you already worked on CPM2 support,
Nope, I don't have CPM2 board to work on.
Quoted 2 lines
or thought about any particular issue
I should pay attention to ?
Nope, sorry.
Signature · 3 lines
Anton Vorontsov email: [email protected] irc://irc.freenode.net/bd2
Quoted 8 lines · Anton Vorontsov
Quoted 3 lines · Laurent Pinchart
At first sight the driver depends on
qe_libfor:- 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.
Quoted 6 lines
Quoted 2 lines
It shouldn't be too difficult to abstract those operation in a fashion similar to the
cpm_uartdriver.Yup, but we still have
ucc_serial(QE) andcpm_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
Quoted 3 lines · Anton Vorontsov
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_xxxx 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.
Quoted 2 lines
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.
Signature · 2 lines
Timur Tabi Linux kernel developer at Freescale
Quoted 3 lines · Timur Tabi
My only concern is that the functions are still called
cpm_xxxxeven 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
Quoted 5 lines · Timur Tabi
Quoted 2 lines
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
Hi Anton,
Quoted 25 lines · Anton Vorontsov
Quoted 11 lines · Laurent Pinchart
Hi Anton,
Quoted 8 lines · Anton Vorontsov
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.
Quoted 5 lines
Quoted 3 lines
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.
Quoted 5 lines
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.
Quoted 7 lines
Quoted 3 lines
At first sight the driver depends on
qe_libfor:- 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.
Quoted 5 lines
Quoted 1 line
- GPIO access (
qe_gpio_set_dedicated)This is because of David Brownell. ;-) Specifically, unwillingness to accept that
set_dedicatedis 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.
Quoted 6 lines
Quoted 1 line
- 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. Quick&dirty 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.
Quoted 7 lines
Quoted 1 line
- QE commands execution (
qe_issue_cmd)No proper solution yet.
Quoted 2 lines
It shouldn't be too difficult to abstract those operation in a fashion similar to the
cpm_uartdriver.
Quoted 7 lines
Yup, but we still have
ucc_serial(QE) andcpm_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.Quoted 1 line
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,
Signature · 9 lines
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
On Mon, Apr 07, 2008 at 06:11:15PM +0200, Laurent Pinchart wrote:
[...]
Quoted 5 lines
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. :-)
Quoted 10 lines
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.
Quoted 3 lines
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, 0xFFFF); help there? Or it's different problem?
Signature · 3 lines
Anton Vorontsov email: [email protected] irc://irc.freenode.net/bd2
Quoted 9 lines · Anton Vorontsov
On Mon, Apr 07, 2008 at 06:11:15PM +0200, Laurent Pinchart wrote:
[...]Quoted 5 lines
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 ?
Quoted 11 lines
Quoted 11 lines
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.
Quoted 7 lines
Quoted 3 lines
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, 0xFFFF); 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.
Signature · 9 lines
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
V2hhdCBkb2VzIFFVSUNDIHN0YW5kIGZvcj8gDQpBbSBnZXR0aW5nIGNvbmZ1c2VkIHdpdGggU21h cnRDYXJkIFVJQ0MuIElzIGl0IGFueXdheSByZWxhdGVkPyANCg0KPi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+RnJvbTogbGludXgtdXNiLW93bmVyQHZnZXIua2VybmVsLm9yZyBbbWFpbHRv OmxpbnV4LXVzYi1vd25lckB2Z2VyLmtlcm5lbC5vcmddIE9uIEJlaGFsZiBPZiBMYXVyZW50DQo+ UGluY2hhcnQNCj5TZW50OiBXZWRuZXNkYXksIEFwcmlsIDA5LCAyMDA4IDU6NDQgUE0NCj5Ubzog YXZvcm9udHNvdkBydS5tdmlzdGEuY29tDQo+Q2M6IGxpbnV4cHBjLWRldkBvemxhYnMub3JnOyBs aW51eC11c2JAdmdlci5rZXJuZWwub3JnOyBUaW11ciBUYWJpOyBTY290dCBXb29kOyBEYXZpZCBC cm93bmVsbA0KPlN1YmplY3Q6IFJlOiBbUEFUQ0hdIEZyZWVzY2FsZSBRVUlDQyBFbmdpbmUgVVNC IEhvc3QgQ29udHJvbGxlcg0KPg0KPk9uIFR1ZXNkYXkgMDggQXByaWwgMjAwOCAxNDoxNiwgQW50 b24gVm9yb250c292IHdyb3RlOg0KPj4gT24gTW9uLCBBcHIgMDcsIDIwMDggYXQgMDY6MTE6MTVQ TSArMDIwMCwgTGF1cmVudCBQaW5jaGFydCB3cm90ZToNCj4+IFsuLi5dDQo+PiA+IEkgaGFkIGEg Zmlyc3QgZ28gYXQgaGFja2luZyB0aGUgRkhDSSBkcml2ZXIgdG8gbWFrZSBpdCBydW4gb24gYSBD UE0yDQo+PiA+IHBsYXRmb3JtLiBSZXN1bHRzIHNvIGZhciBhcmUgcXVpdGUgZ29vZC4gQWZ0ZXIg Z2V0dGluZyByaWQgb2YgcWUtc3BlY2lmaWMNCj4+ID4gQVBJcyBhcyBleHBsYWluZWQgYWJvdmUs IGFuZCBhZGRpbmcgU09GIHRva2VuIGdlbmVyYXRpb24gc3VwcG9ydCwgSSd2ZQ0KPj4gPiBiZWVu IGFibGUgdG8gYWNjZXNzIGEgbWFzcyBzdG9yYWdlIGRldmljZS4gVGhlIGRyaXZlciBoYXNuJ3Qg YmVlbg0KPj4gPiBzdHJlc3MtdGVzdGVkIHlldCB0aG91Z2guDQo+Pg0KPj4gV293LCBhd2Vzb21l ISBUaGF0J3MgZ3JlYXQgbmV3cywgcmVhbGx5LiBMb29raW5nIGZvcndhcmQgZm9yIHRoZSBwYXRj aC4gOi0pDQo+DQo+VGhlIGN1cnJlbnQgdmVyc2lvbiBvZiB0aGUgY29kZSBpcyBDUE0yLXNwZWNp ZmljIGFuZCB3b24ndCB3b3JrIG9uIFFFLWJhc2VkDQo+cGxhdGZvcm1zLiBTaG91bGQgSSBzdGls bCBwb3N0IGl0ID8NCj4NCj4+ID4gSSByYW4gaW50byBhbiBpc3N1ZSB3aXRoIElETEUgYW5kIFJF U0VUIGludGVycnVwdHMuIFdoZW4gdGhlIGRldmljZSBpcw0KPj4gPiBmaXJzdCBwbHVnZ2VkIGlu dG8gdGhlIFVTQiBwb3J0LCB0aGUgaWRsZSBpbnRlcnJ1cHQga2lja3MgaW4gYW5kIHRoZQ0KPj4g PiBkcml2ZXIgZGV0ZWN0cyB0aGUgZGV2aWNlIHByb3Blcmx5LiBXaGVuIHRoZSBkZXZpY2UgaXMg dGhlbiByZW1vdmVkLCB0aGUNCj4+ID4gcmVzZXQgaW50ZXJydXB0IGlzIGdlbmVyYXRlZCBhbmQg dGhlIGRyaXZlciBoYW5kbGVzIGRldmljZSByZW1vdmFsDQo+PiA+IHByb3Blcmx5LiBSaWdodCBh ZnRlciB0aGUgcmVzZXQgaW50ZXJydXB0LCBpZGxlIGludGVycnVwdHMgYXJlIGdlbmVyYXRlZA0K Pj4gPiBldmVyeSBtaWxsaXNlY29uZHMgZm9yIGFyb3VuZCAxNzVtcy4gVGhlIHN0YXR1cyByZWdp c3RlciBhbHdheXMgcmVwb3J0cyBhDQo+PiA+IG5vbi1pZGxlIGNvbmRpdGlvbiB3aGVuIHJlYWQg aW4gdGhlIGludGVycnVwdCBoYW5kbGVyLiBUaGUgZmxvdyBvZiBpZGxlDQo+PiA+IGludGVycnVw dHMgdGhlbiBzdG9wcywgYW5kIG5vIGlkbGUgaW50ZXJydXB0IGlzIGdlbmVyYXRlZCB3aGVuIEkg cmVwbHVnDQo+PiA+IHRoZSBkZXZpY2UuIEkndmUgY2hlY2tlZCB0aGUgaW50ZXJydXB0cyBtYXNr IHJlZ2lzdGVyIHRvIG1ha2Ugc3VyZSBpZGxlDQo+PiA+IGludGVycnVwdHMgd2VyZSBlbmFibGVk Lg0KPj4gPg0KPj4gPiBIYXZlIHlvdSBub3RpY2VkIGEgc2ltaWxhciBiZWhhdmlvdXIgd2hlbiB5 b3UgdGVzdGVkIHRoZSBkcml2ZXIgb24geW91cg0KPj4gPiBRRS1iYXNlZCBwbGF0Zm9ybSA/IEkg c3VzcGVjdGVkIGEgZGVib3VuY2luZyBpc3N1ZSwgYnV0IEkgc2hvdWxkIHRoZW4gZ2V0DQo+PiA+ IGlkbGUgY29uZGl0aW9ucyBvbmNlIGV2ZXJ5IG90aGVyIHRpbWUgd2hlbiByZWFkaW5nIHRoZSBz dGF0dXMgcmVnaXN0ZXIuDQo+Pg0KPj4gSG0uLiBub3BlLCBJIGRpZG4ndCBzZWUgYW55dGhpbmcg bGlrZSB0aGF0LCBhdCBsZWFzdCBub3Qgc29tZXRoaW5nIHRoYXQNCj4+IGlzIGFmZmVjdGluZyB0 aGUgZHJpdmVyIGZ1bmN0aW9uYWxpdHkuIERpZCBvdXRfYmUxNih0bXItPmd0ZXZyLCAweEZGRkYp Ow0KPj4gaGVscCB0aGVyZT8gT3IgaXQncyBkaWZmZXJlbnQgcHJvYmxlbT8NCj4NCj5ObyBpdCBk aWRuJ3QsIGl0J3MgYSBjb21wbGV0ZWx5IGRpZmZlcmVudCBwcm9ibGVtLg0KPg0KPlRoZSBJRExF IGludGVycnVwdHMgSSBzZWUgZXZlcnkgbWlsbGlzZWNvbmQgZm9yIGFyb3VuZCAxNzVtcyBhZnRl cg0KPmRpc2Nvbm5lY3RpbmcgdGhlIGRldmljZSBhcmUgcHJvYmFibHkgZHVlIHRvIHRoZSBTT0Yg dG9rZW5zIHNlbnQgYmV0d2Vlbg0KPmRldmljZSBkaXNjb25uZWN0aW9uIGFuZCB0aGUgZmhjaV9z dG9wX3NvZl90aW1lcigpIGNhbGwuIENhbGxpbmcNCj5maGNpX3N0b3Bfc29mX3RpbWVyKCkgaW4g ZGV2aWNlX2Rpc2Nvbm5lY3RlZF9pbnRlcnJ1cHQoKSBwcmV2ZW50cyBzcHVyaW91cw0KPmlkbGUg aW50ZXJydXB0cyBmcm9tIGJlaW5nIGdlbmVyYXRlZC4NCj4NCj5BZnRlciBmdXJ0aGVyIGludmVz dGlnYXRpb24gSSBmb3VuZCBvdXQgd2h5IG5vIGlkbGUgaW50ZXJydXB0IHdlcmUgZ2VuZXJhdGVk DQo+d2hlbiByZXBsdWdnaW5nIHRoZSBkZXZpY2UuIFVwb24gZGlzY29ubmVjdGlvbiB0aGUgRkhD SSBkcml2ZXIgdHVybnMgYnVzDQo+cG93ZXIgb2ZmIGJ5IHNldHRpbmcgdGhlIHN1c3BlbmQgR1BJ TyBwaW4gaGlnaC4gQXMgdGhlIHNpZ25hbCBpcyBjb25uZWN0ZWQgdG8NCj50aGUgc3VzcGVuZCBp bnB1dCBvZiB0aGUgVVNCIHBoeSBvbiBteSBoYXJkd2FyZSwgc2V0dGluZyB0aGUgc2lnbmFsIGhp Z2gNCj50dXJuZWQgdGhlIHBoeSBvZmYsIGRpc2Nvbm5lY3RpbmcgdGhlIFJQIGFuZCBSTiBzaWdu YWxzIGNvbXBsZXRlbHkuDQo+DQo+SSBzb2x2ZWQgdGhlIGlzc3VlIGJ5IHJlZmVyZW5jaW5nIHRo ZSBidXMgcG93ZXIgY29udHJvbCBHUElPIGluc3RlYWQgb2YgdGhlDQo+c3VzcGVuZCBHUElPIGlu IHRoZSBkZXZpY2UgdHJlZS4gR1BJT19TVVNQTiBzaG91bGQgcmVhbGx5IGJlIHJlbmFtZWQNCj5H UElPX1BPV0VSLg0KPg0KPi0tDQo+TGF1cmVudCBQaW5jaGFydA0KPkNTRSBTZW1hcGhvcmUgQmVs Z2l1bQ0KPg0KPkNoYXVzc2VlIGRlIEJydXhlbGxlcywgNzMyQQ0KPkItMTQxMCBXYXRlcmxvbw0K PkJlbGdpdW0NCj4NCj5UICszMiAoMikgMzg3IDQyIDU5DQo+RiArMzIgKDIpIDM4NyA0MiA3NQ0K
Quoted 1 line · Vikram
What does QUICC stand for?
QUICC stands for QUad Integrated Communications Controller.
http://en.wikipedia.org/wiki/PowerQUICC
Quoted 1 line
Am getting confused with SmartCard UICC. Is it anyway related?
They are not related.
Signature · 9 lines
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