Hi Martyn,
On Mon, Nov 2, 2015 at 3:55 AM, Martyn Welch
<martyn.welch@xxxxxxxxxxxxxxx> wrote:
This series is based on commits that can be found in the git tree here:After my last submission, we had a discussion about the mailbox and
https://github.com/thierryreding/linux/commits/staging/xhci
I have included the patches I've used from that tree as patches 1-5.
The above patches were submitted for review back in May:
https://lkml.org/lkml/2015/5/4/574
The approach taken in these patches was deemed not appropriate (treating
the XUSB as a MFD).
In patch 6 I add the bindings based in those submitted for review here
(with a few modifications currently required by the driver):
https://www.spinics.net/lists/linux-usb/msg130940.html
I have included my changes to the original patch series in patch 7. With
these modifications the patch series builds and works, but is rather hacky.
Devices for the mailbox driver and xHCI driver are now created in the xusb
driver (still under the mfd directory for now - it will be moved before
this series is submitted properly). As the child devices use
infrastructure which expects the device to be associated with a of_node,
it has been necessary to point the child device at the parents of_node
where this is needed. This approach did not seem viable for the mailbox
API, so to get that working the child device node was pointed to the
parents of_node (in tegra_xusb_add_device). The unfortunate side effect of
this is that upon device creation the parents probe routine gets called...
Not good.
Patch 8 attempts to resolve this. When passing the parents device node to
the mailbox API, the mailbox's receive callback was raising errors as
that function is looking for the drvdata stored in the child's device node,
but getting the parents. This patch jumps though a few hoops to get to the
child's device node.
decided not to use the mailbox framework and instead use a private API
between the xHCI driver and the XUSB_PADCTL driver.
Unfortunately, whilst the receive callback seems to be getting the rightTegra124? Tegra210? Which board?
drvdata, USB3 devices are being enumerated as USB2 devices rather than
USB3 devices, so something is clearly not right.