summaryrefslogtreecommitdiff
path: root/payloads/libpayload/drivers/usb/xhci.c
AgeCommit message (Collapse)Author
2016-06-12libpayload: usb: xhci: Support rockchip xHCI controllerLiangfeng Wu
1. Make the xHCI driver to support xHCI controller v1.1 2. And a new function xhci_ring_doorbell(), it aims to add a memory barrier before ringing the doorbell, to ensure all TRB changes are written to memory. BRANCH=none BUG=chrome-os-partner:52684 TEST=boot from USB on Kevin rk3399 platform Change-Id: Ife1070d1265476d0f5b88e2acf3299fc84af5832 Signed-off-by: Martin Roth <martinroth@chromium.org> Original-Commit-Id: 0c21e92 Original-Change-Id: I4e38e04dc3c7d32ee4bb424a473c70956a3c3ea9 Original-Signed-off-by: Liangfeng Wu <wulf@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/346831 Original-Commit-Ready: Brian Norris <briannorris@chromium.org> Original-Tested-by: Douglas Anderson <dianders@chromium.org> Original-Reviewed-by: Douglas Anderson <dianders@chromium.org> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/15111 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Nico Huber <nico.h@gmx.de>
2015-11-05libpayload: xhci: Add delay to get reset working more reliablyRajmohan Mani
Existing Intel xHCI controllers require a delay of 1 ms, after setting the CMD_RESET bit in command register, before accessing any HC registers. This allows the HC to complete the reset operation and be ready for HC register access. Without this delay, the subsequent HC register access, may result in a system hang, very rarely. Verified CherryView / Braswell platforms go through over 1000 warm reboot cycles (which was not possible without this patch), without any xHCI reset hang in depthcharge. BRANCH=None BUG=None TEST=Verified CherryView / Braswell platforms go through over 1000 warm reboot cycles, without any xHCI reset hang in depthcharge. Change-Id: I8eff5115ca52738bdcf8bc65fbfb2a5f60a0abe1 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 3e7ea70df36e3bf35a6ee1297640900ee76bfdac Original-Change-Id: Id681a19d0eedb0e2c29e259c5467bcde577e3460 Original-Signed-off-by: Rajmohan Mani <rajmohan.mani@intel.com> Original-Reviewed-on: https://chromium-review.googlesource.com/310022 Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/12325 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins) Reviewed-by: Nico Huber <nico.h@gmx.de>
2015-08-14libpayload: usb: xhci: Count new Max Scratchpad Bufs bits from XHCI 1.1Julius Werner
The 1.1 revision of the XHCI specification added an extra 5 bits to the Max Scratchpad Bufs field of HCSPARAMS2 that newer controllers make use of. Not honoring these bits means we're not allocating as many scratchpad buffers as the controller expects, which means it will interpret some uninitialized values from the end of the pointer array as scratchpad buffer pointers, which obviously doesn't end well. Let's fix that. BRANCH=none BUG=chrome-os-partner:42279 TEST=Makes a USB-related memory corruption issue disappear. Original-Change-Id: I7c907492339262bda31cdd2b5c0b588de7df8544 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/291681 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Change-Id: Iba1007bfebffe1f564f78bb875fff9ba0fe11a38 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/11189 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-08-14libpayload: usb: Fixup wrong use of configChunfeng Yun
replace CONFIG_LP_XHCI_MTK_QUIRK by CONFIG_LP_USB_XHCI_MTK_QUIRK BRANCH=none BUG=none TEST=Rev0-oak Original-Change-Id: I68f58ed3b02caa7cef8f0f60a4a8f5e9755c97a7 Original-Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Original-Reviewed-on: https://chromium-review.googlesource.com/290522 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Original-Commit-Queue: Yidi Lin <yidi.lin@mediatek.com> Original-Tested-by: Yidi Lin <yidi.lin@mediatek.com> Change-Id: I316712e99e0b44d292dab27cf66e26837dc2e957 Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Reviewed-on: http://review.coreboot.org/11179 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-06-30libpayload: Make Kconfig bools use IS_ENABLED()Stefan Reinauer
This will make the code work with the different styles of Kconfig (emit unset bools vs don't emit unset bools) Roughly, the patch does this, and a little bit of fixing up: perl -pi -e 's,ifdef (CONFIG_LP_.+?)\b,if IS_ENABLED\($1\),g' `find . -name *.[ch]` perl -pi -e 's,ifndef (CONFIG_LP_.+?)\b,if !IS_ENABLED\($1\),g' `find . -name *.[ch]` Change-Id: Ib8a839b056a1f806a8597052e1b571ea3d18a79f Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-on: http://review.coreboot.org/10711 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-06-03libpayload: usb: Support MTK xHCI host controllerYidi Lin
1. There is a mis-understanding to calculate the value of TD Size in Normal TRB. For MTK's xHCI controller it defines a number of packets that remain to be transferred for a TD after processing all Max packets in all previous TRBs, that means don't include the current TRB's. 2. To minimize the scheduling effort for synchronous endpoints in xHC, the MTK architecture defines some extra SW scheduling parameters for HW. According to these parameters provided by SW, the xHC can easily decide whether a synchronous endpoint should be scheduled in a specific uFrame. The extra SW scheduling parameters are put into reserved DWs in Slot and Endpoint Context. But in coreboot synchronous transfer can be ignored, so only two fields are set to a default value 1 to support bulk and interrupt transfers, and others are set to zero. 3. For control transfer, it is better to read back doorbell register or add a memory barrier after ringing the doorbell to flush posted write. Otherwise the first command will be aborted on MTK's xHCI controller. 4. Before send commands to a port, the Port Power in PORTSC register should be set to 1 on MTK's xHCI so a hook function of enable_port in generic_hub_ops_t struct is provided. Change-Id: Ie8878b50c048907ebf939b3f6657535a54877fde Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 738609c11f16264c6e6429d478b2040cb391fe41 Original-Change-Id: Id9156892699e2e42a166c77fbf6690049abe953b Original-Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Original-Reviewed-on: https://chromium-review.googlesource.com/265362 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Original-Commit-Queue: Yidi Lin <yidi.lin@mediatek.com> Original-Tested-by: Yidi Lin <yidi.lin@mediatek.com> Reviewed-on: http://review.coreboot.org/10389 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins)
2015-05-04libpayload: Guard PCI using code appropriately in XHCI driverPatrick Georgi
Make the XHCI driver compile on ARM again. The Panther Point specific shutdown handler is certainly _not_ necessary there. Change-Id: I470afd4d82d101902b119b3ead4381e2b36a94b0 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/10091 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-03-23libpayload: usb: xhci: set ENT flag in last Normal TRBSourabh Banerjee
If a TD is comprised of one or more Normal TRBs and terminated with an Event Data TRB, then the transition to the Idle state (and associated Stream state save) could occur after all the data for the TD has been moved (e.g. after Transfer Event TRBs have been executed), but before the Event Data TRB is executed. Under these conditions, the execution of the Event Data TRB is necessary to complete the TD, otherwise it does not occur until the next time the Stream is scheduled. This could lead to the lock up. The Evaluate Next TRB(ENT) flag provides a means of forcing the execution of a terminating Event Data TRB. Setting ENT flag in last Normal TRB makes the xHC to evaluate the Even Data TRB. BUG=chrome-os-partner:29375 TEST=Verified kernel boot-up on storm from previously failing USB stick. USB stick model: Sandisk Ultra USB 3.0 Pen Drive 32 GB Strontium Jet USB 3.0 Pen Drive 32 GB Change-Id: I092e2109c55c2274239c493cb67b47d730304ed2 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 7eefb3b2858c841165ae839d349d2a0be50fbcc8 Original-Change-Id: I4e123577ec5a5996d87d2fc52cb6cf5c571c9fae Original-Signed-off-by: Sourabh Banerjee <sbanerje@codeaurora.org> Original-Reviewed-on: https://chromium-review.googlesource.com/220123 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Original-Commit-Queue: Vadim Bendebury <vbendeb@chromium.org> Original-Tested-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: http://review.coreboot.org/8736 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2014-12-31libpayload: Fix pointer related castsFurquan Shaikh
Fix pointer related casts since this can create a problem for 64-bit systems. BUG=None BRANCH=None TEST=Compiled successfully for link, nyan using emerge-* libpayload Original-Change-Id: I4cbd2d9f1efaaac87c3eba69204337fd6893ed66 Original-Reviewed-on: https://chromium-review.googlesource.com/199564 Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org> Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org> Original-Tested-by: Furquan Shaikh <furquan@chromium.org> (cherry picked from commit 914b118a64b0691aeca463dff24252db9c24109e) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I11f070ed5d3eddd8b9be30c428cb24c8439e617b Reviewed-on: http://review.coreboot.org/7905 Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Tested-by: build bot (Jenkins)
2014-12-31libpayload: usb: xhci: Fix TD size if it overflows 5 bitsRajmohan Mani
xHCI Spec says TD Size (5 bits) field shall be forced to 31, if the number of packets to be scheduled is greater than 31. BUG=chrome-os-partner:27837 BRANCH=rambi,nyan TEST=Manual: Ensure recovery boot with USB 2.0 media on Squawks works fine without any babble errors. Original-Change-Id: Iff14000e2a0ca1b28c49d0da921dbb2a350a1bbd Original-Signed-off-by: Rajmohan Mani <rajmohan.mani@intel.com> Original-Originally-Reviewed-on: https://chromium-review.googlesource.com/202297 Original-Reviewed-on: https://chromium-review.googlesource.com/202330 Original-Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org> Original-Commit-Queue: Julius Werner <jwerner@chromium.org> Tested-by: Julius Werner <jwerner@chromium.org> (cherry picked from commit ae58b99370df3a86bf15d84b97db858a968b1dbd) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I9668b947f676c109fad9297e5efde91bf7f796fd Reviewed-on: http://review.coreboot.org/7913 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2014-12-30libpayload: Clean up USB build warningsMarc Jones
There were a few build warnings in the USB driver to clean up before -Werror may be enabled. Change-Id: I220cfcf0ee926912a184a91d3ced3ba61259130e Signed-off-by: Marc Jones <marc.jones@se-eng.com> Reviewed-on: http://review.coreboot.org/7921 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
2014-11-13libpayload: usb: Fix up usb_shutdown() code pathsJulius Werner
This patch combines a few minor fixes and refactoring to the various host controller and root hub drivers to ensure they all do the right thing on a call to usb_exit(). It puts a usb_detach_device(0) call into detach_controller() so that the HCD doesn't need to remember to tear down the root hub itself, and makes sure all root hubs properly detach the subtree of devices connected to their ports first (as generic_hub and by extension XHCI had already been doing). It also fixes up some missing free() calls and replaces most 'ptr = malloc(); if (!ptr) fatal()' idioms with the new x(z)alloc(). BUG=chromium:343415 TEST=Tested EHCI on Big and OHCI, EHCI, and XHCI on Snow. Could not test UHCI (unless anyone volunteers to port coreboot to a ZGB? ;) ), but the changes are really tame. Original-Change-Id: I6eca51ff2685d0946fe4267ad7d3ec48ad7fc510 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/193731 Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org> (cherry picked from commit 5791b546e5a21a360d0c65888a5b92d5f48f8178) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I00138f0aeceb12ed721f7368c7788c9b6bee227d Reviewed-on: http://review.coreboot.org/7222 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org>
2014-10-22libpayload: usb: xhci: Fix STALL endpoint handlingShawn Nematbakhsh
- Remove the call to clear_stall in xhci_reset_endpoint because we will call clear_stall from the mass-storage driver. - Remove the xhci_reset_endpoint call from xhci_bulk on STALL since we will reset on the next transfer anyway. - Remove the clear_halt parameter from xhci_bulk since it's now unused. Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Change-Id: I852b87621861109e596ec24b78a8f036d796ff14 Reviewed-on: https://chromium-review.googlesource.com/192866 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> (cherry picked from commit e67e4f0545cbdc074328c83c7edccf9e712cd7be) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/7011 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2014-08-31libpayload: xhci: Ensure to reset dequeue pointer on stopped endpointsJulius Werner
This patch fixes a bug in the XHCI stack that occurs when a multi-TRB TD times out before the last TRB is processed. The driver will correctly issue a Stop Endpoint command in that case, but the xHC will still preserve the transfer state and just pick up right after that on the next doorbell ring. It will then process the leftover TRBs from the old TD the next time a transfer is issued. (cf. XHCI 4.6.9) We fix this by changing the existing xhci_reset_endpoint() calls in transfer functions to not only trigger on Halted (2) and Error (4), but also on Stopped (3). That function will not actually issue a Reset Endpoint command in this case, but it will nuke the whole transfer ring and issue a Set TR Dequeue Pointer command, which is sufficient (though slightly overkill) to solve our problem. Change-Id: I3abbe30ff9d4911a8af1f792324e018d427019e8 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/170833 Reviewed-by: Ronald Minnich <rminnich@chromium.org> Reviewed-by: Kees Cook <keescook@chromium.org> (cherry picked from commit f12424af0e29ac12963e8e5a7970fadcc0bb6cee) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6787 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2014-08-14libpayload: xhci: Make XHCI stack usable on ARMJulius Werner
This patch updates the libpayload XHCI stack to run on ARM CPUs (tested with the DWC3 controller on an Exynos5420). Firstly, it adds support for 64-byte Slot/Endpoint Context sizes. Since the existing context handling code represented the whole device context as a C struct (whose size has to be known at compile time), it was necessary to refactor the input and device context structures to consist of pointers to the actual contexts instead. Secondly, it moves all data structures that the xHC accesses through DMA to cache-coherent memory. With a similar rationale as in the ARM patches for EHCI, using explicit cache maintenance functions to correctly handle the actual transfer buffers in all cases is presumably impossible. Instead this patch also chooses to create a DMA bounce buffer in the XHCI stack where transfer buffers which are not already cache-coherent will be copied to/from. Change-Id: I14e82fffb43b4d52d687b65415f2e33920e088de Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/169453 Reviewed-by: Stefan Reinauer <reinauer@google.com> (cherry picked from commit 1fa9964063cce6cbd87ba68334806dde8aa2354c) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6643 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-08-12libpayload: Make USB transfer functions return amount of bytesJulius Werner
The USB bulk and control transfer functions in libpayload currently always return 0 for success and 1 for all errors. This is sufficient for current use cases (essentially just mass storage), but other classes (like certain Ethernet adapters) need to be able to tell if a transfer reached the intended amount of bytes, or if it fell short. This patch slightly changes that USB API to return -1 on errors, and the amount of transferred bytes on successes. All drivers in the current libpayload mainline are modified to conform to the new error detection model. Any third party users of this API will need to adapt their if (...<controller>->bulk/control(...)) checks to if (...<controller>->bulk/control(...) < 0) as well. The host controller drivers for OHCI and EHCI correctly implement the new behavior. UHCI and the XHCI stub just comply with the new API by returning 0 or -1, but do not actually count the returned bytes. Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/48308 Reviewed-by: Gabe Black <gabeblack@chromium.org> Reviewed-by: Stefan Reinauer <reinauer@google.com> Tested-by: Gabe Black <gabeblack@chromium.org> Commit-Queue: Gabe Black <gabeblack@chromium.org> Updated the patch to support XHCI as well. Change-Id: Ic2ea2810c5edb992cbe185bc9711d2f8f557cae6 (cherry picked from commit e39e2d84762a3804653d950a228ed2269c651458) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6390 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2014-08-11libpayload: xhci: Use Event Data TRBs for transfer event generationJulius Werner
The current XHCI code only sets IOC on the last TRB of a TD, and doesn't set ISP anywhere. On my Synopsys DesignWare3 controller, this won't generate an event at all when we have a short transfer that is not on the last TRB of a TD, resulting in event ring desync and everyone having a bad time. However, just setting ISP on other TRBs doesn't really make for a nice solution: we then need to do ugly special casing to fish out the spurious second transfer event you get for short packets, and we still need a way to figure out how many bytes were transferred. Since the Short Packet transfer event only reports untransferred bytes for the current TRB, we would have to manually walk the rest of the unprocessed TRB chain and add up the bytes. Check out U-Boot and the Linux kernel to see how complicated this looks in practice. Now what if we had a way to just tell the HC "I want an event at exactly *this* point in the TD, I want it to have the right completion code for the whole TD, and to contain the exact number of bytes written"? Enter the Event Data TRB: this little gizmo really does pretty much exactly what any sane XHCI driver would want, and I have no idea why it isn't used more often. It solves both the short packet event generation and counting the transferred bytes without requiring any special magic in software. Change-Id: Idab412d61edf30655ec69c80066bfffd80290403 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/170980 Reviewed-by: Stefan Reinauer <reinauer@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> (cherry picked from commit e512c8bcaa5b8e05cae3b9d04cd4947298de999d) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6516 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2014-08-05libpayload: Change CONFIG_* to CONFIG_LP_* in the kconfig.Gabe Black
When libpayload header files are included in the payload itself, it's possible that the payloads config settings will conflict with the ones in libpayload. It's also possible for the libpayload config settings to conflict with the payloads. To avoid that, the libpayload config settings have _LP_ (for libpayload) added to them. The symbols themselves as defined in the Config.in files are still the same, but the prefix added to them is now CONFIG_LP_ instead of just CONFIG_. Change-Id: Ib8a46d202e7880afdeac7924d69a949bfbcc5f97 Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: https://gerrit.chromium.org/gerrit/65303 Reviewed-by: Stefan Reinauer <reinauer@google.com> Tested-by: Gabe Black <gabeblack@chromium.org> Commit-Queue: Gabe Black <gabeblack@chromium.org> (cherry picked from commit 23e866da20862cace0ed2a67d6fb74056bc9ea9a) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6427 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2014-07-10libpayload: Drop obsolete setting of reg_base in [oex]hciNico Huber
Setting of `controller->reg_base` is of no use here, as it is never read (in another function) later. Looks like this pattern originated from uhci.c where it makes sense. By removing the indirection through `reg_base` we also fix a possible truncation to u32. Change-Id: I5c99c5bf1f5b1d6c04bd84d87fd3e275fd7d0411 Signed-off-by: Nico Huber <nico.huber@secunet.com> Reviewed-on: http://review.coreboot.org/6251 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
2014-07-10libpayload: Catch null-pointer dereference in xHCINico Huber
Fix a possible null-pointer dereference (hopefully) before anyone runs into this. Also don't switch ports to xHCI if initialization failed. Change-Id: I5dbaeb435a98ead0b50d27fde13c9f1433ea3e81 Signed-off-by: Nico Huber <nico.huber@secunet.com> Reviewed-on: http://review.coreboot.org/6245 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2014-07-10libpayload: xHCI: Always initialize controller->pcidevNico Huber
As the controller structure is never fully cleared, this one wasn't initialized for non-pci controllers (but checked for non-null later). Change-Id: I852671c5f55650bdb6cd97f4ec74b1f95ee894c7 Signed-off-by: Nico Huber <nico.huber@secunet.com> Reviewed-on: http://review.coreboot.org/6246 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2014-07-10libpayload: Use unsigned long for BARs in *hci_init()Nico Huber
Using void* for physical addresses leads to much casting and confuses developers when to convert from physical to virtual addresses or the other way around. When using plain integers for physical addresses and pointers for virtual addresses things become much cleaner and we won't ever end up dereferencing a physical address. Change-Id: I24cd53b81c7863b6d14f0cbb4ce8937728b37c1c Signed-off-by: Nico Huber <nico.huber@secunet.com> Reviewed-on: http://review.coreboot.org/6244 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
2014-07-10libpayload: Remove redundant phys_to_virt() from xHCI driverNico Huber
Remove a redundant phys_to_virt() that sneaked in the initialization of PCI xHCI controllers. The use of casts from void* to u32 (and vice versa) prompts for things going wrong here. That will be addressed in a later commit. Change-Id: Ibc71ed6ee7016529c0e3a51559aaec07aaaba315 Signed-off-by: Nico Huber <nico.huber@secunet.com> Reviewed-on: http://review.coreboot.org/6243 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2014-01-08libpayload: reintroduce optional PCI in XHCI driverPatrick Georgi
being a good citizen on the box, libpayload tries to return to EHCI mode on shutdown, so a non-XHCI capable USB driver after it (eg. in the OS) finds something to work with. Change-Id: Id227d646e08a258b841c644263112f0815dd486c Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/4547 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-11-25libpayload: Add USB support for non-PCI controllersStefan Reinauer
Restructure USB stack to not depend on PCI, and make PCI stub available on x86, but provide fixed BARs for ARM (Exynos 5) Change-Id: Iee7c8b134c22b661a9a515e24943470c9dbadd1f Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: https://gerrit.chromium.org/gerrit/49970 Reviewed-on: http://review.coreboot.org/4175 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-09-30libpayload: Switch xHCI shared ports back to EHCI on shutdownNico Huber
On Intel's Panther Point the xHCI ports are shared with an EHCI controller. Our xHCI driver switches them to xHCI, naturally. But we forgot to switch them back on shutdown, which left them unusable by a non-xHCI aware operating system. Change-Id: I70ef08655a603b42ee939935d50cf77ea97878a3 Signed-off-by: Nico Huber <nico.huber@secunet.com> Reviewed-on: http://review.coreboot.org/3791 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2013-06-13libpayload: Fill gaps in the xHCI driverNico Huber
Well, it turned out to be more as some gaps ;) but we finally have xHCI running. It's well tested against a QM77 Ivy Bridge board. We have no SuperSpeed support (yet). On Ivy Bridge, SuperSpeed is not advertised and USB 3 devices will just work at HighSpeed. There are still some bit fields in xhci_private.h, so this might need little more work to run on ARM. Change-Id: I7a2cb3f226d24573659142565db38b13acdc218c Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/3452 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2012-12-18libpayload: Use usb_debug() to show USB messagesDave Frodin
Previously printf()'s were used to show USB messages which results in lots of USB information being shown when it isn't needed. This will now use the usb_debug() printing funtion that already exists in usb.h. Change-Id: I2199814de3327417417eb2e26a660f4a5557cb9f Signed-off-by: Dave Frodin <dave.frodin@se-eng.com> Reviewed-on: http://review.coreboot.org/2044 Tested-by: build bot (Jenkins) Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
2012-11-14libpayload: Add init() function to hci_t and rework uhci_reset()Nico Huber
uhci_reset() differs in semantics compared to the other HCI's reset() implementations. uhci_reset() does some initialization work after a controller reset. So move the initialization part to a new function, uhci_reinit(), which get's exported through a new entry in hci_t: hci_t.init(). Warning: This breaks code that relies on the current, special, counterintuitive behaviour of uhci_reset(). If one wants a working host controller after calling hci_t.reset(), he should call hci_t.init() afterwards. Change-Id: Ia7ce80865d12d11157645ce251f77f349f8e3c34 Signed-off-by: Nico Huber <nico.huber@secunet.com> Reviewed-on: http://review.coreboot.org/1851 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-11-14libpayload: Do not call ohci_reset() from ohci_init()Nico Huber
When ohci_reset() was implemented, OHCI controllers stopped working since the stub ohci_reset() is called at the end of ohci_init(). This is fixed by removing the call. To prevent further problems the call to the xhci_reset() stub is removed, too. Change-Id: If89825c8e6caf40f7f4fe078e8b2e90054a54ba2 Signed-off-by: Nico Huber <nico.huber@secunet.com> Reviewed-on: http://review.coreboot.org/1850 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-11-07libpayload: Turn the "debug" #define into the usb_debug static inline function.Gabe Black
The "debug" macro used internally in the libpayload USB subsystem was very generically named and would leak into consumers of the library that included usb.h directly or indirectly. This change turns that #define from a macro into a static inline function to move away from the preprocessor, and also renames it to usb_debug so it's less likely to collide with something unrelated. Change-Id: I18717df111aa9671495f8a2a5bdb2c6311fa7acf Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: http://review.coreboot.org/1738 Reviewed-by: Patrick Georgi <patrick@georgi-clan.de> Tested-by: build bot (Jenkins)
2012-08-23libpayload: add controller type in usbdev_hcAnton Kochkov
Add controller type (UHCI, OHCI, EHCI or XHCI) into usbdev_hc (hci_t) struct, so now we know which type selected controller have. It needed to access controller specific data, if access usb tree outside of libpayload (e.g. in payload intself) Change-Id: I7df947bbb56a50d0d792ccd4d3a6b021ee95e2ea Signed-off-by: Anton Kochkov <anton.kochkov@gmail.com> Reviewed-on: http://review.coreboot.org/1145 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2011-11-04libpayload: Drop usb_fatal()Patrick Georgi
We have fatal(), which is just as good. Coccinelle script: @@ expression E; @@ -usb_fatal(E) +fatal(E) Change-Id: Iabecbcc7d068cc0f82687bf51d89c2626642cd86 Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/395 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2010-08-13Add support for OHCI controllers and prelimiary support for xHCI (USB3) ↵Patrick Georgi
controllers. Improve scanning for USB controllers. Limitations: - OHCI doesn't support interrupt transfers yet (ie. no keyboards) - xHCI just does initialization and device attach/detach so far Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Acked-by: Peter Stuge <peter@stuge.se> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5691 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1