[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1446465323-9493-1-git-send-email-martyn.welch@collabora.co.uk>
Date: Mon, 2 Nov 2015 11:55:15 +0000
From: Martyn Welch <martyn.welch@...labora.co.uk>
To: linux-tegra@...r.kernel.org
Cc: thierry.reding@...il.com, swarren@...dotorg.org,
jonathanh@...dia.com, linux-kernel@...r.kernel.org,
abrestic@...omium.org
Subject: [RFC 0/8] Add support for NVIDIA Tegra XUSB
This series is based on commits that can be found in the git tree here:
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.
Unfortunately, whilst the receive callback seems to be getting the right
drvdata, USB3 devices are being enumerated as USB2 devices rather than
USB3 devices, so something is clearly not right.
I'm posting these patches in the hope that someone can point me in the
right direction.
Is there a better approach I'm missing?
Any ideas why devices aren't being enumerated as USB3?
Martyn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists