Hi, On Tue, Jun 14, 2011 at 04:58:50PM -0700, Sarah Sharp wrote: > On Tue, Jun 14, 2011 at 10:17:05PM +0200, Francesco Castelli wrote: > > Hi Sarah, > > > > many thanks for your answer, not sure about that, > > but it seems that you have aimed the spotlight in the correct direction: > > > > setting CONFIG_PCI_DEBUG=y I found out that the crash > > is due to an ARM processor fault, > > namely, a data abort due to a PCI access failure: data abort ? Sounds like some necessary clocks where turned off. Check if all clocks you need are turned on before you do the access. > > this happens when, in the very first lines of xhci_event_ring_work(), > > your code references the status register > > within the XHCI-HCD operational registers set > > > > therefore, we definitely have no wandering pointers: > > most likely, the PCIe transaction for accessing that register > > went bad, for some reason, either hardware- or driver-related: > > the ti816x_pcie.c driver module is maintained directly from TI, What is this ti816x_pcie.c ? Is it a driver for the PCIe controller on the DM816x processor family ? That should've been pushed to mainline. Do you have any pointers for the driver ? > > so I have to refer to TI folks directly... > > I see. Would that be Felipe's PCI glue layer for the OMAP5 processor? > Or is this a different TI USB3 evaluation board? This is a completely different board :-) But if this one has USB3 on a PCIe bus, then xhci-pci.c should be used :-) -- balbi
Attachment:
signature.asc
Description: Digital signature
