Hi,
On 22-12-16 14:18, Felipe Balbi wrote:
Hans de Goede <hdegoede@xxxxxxxxxx> writes:
<snip>
Baolu has worked on this for months but it turned out that several folks
said 'no' to his patchset. You're not really dealing with a PHY, it's
just a portmux which can generate some UTMI messages to make sure dwc3
is happy.
Right, I opted for a phy driver because that is the closest I could
get to something resembling what this thing does.
The end of the story about this, at least for broxton, was that mux
control was moved to ASL. I'm not sure why folks didn't update CHT (or
other devices') BIOS though.
I don't think expecting things to get "fixed" by firmware updates, esp.
firmware updates adding whole new functionality is going to happen, that
just is not realistic (esp. with cheap devices like these). And even if
it were fixed in firmware users are really bad add updating there firmware.
True that. If you can convince all folks involved that a PHY driver or a
portmux framework is acceptable, then more power for you :-)
Frankly, though, this should always have been handled at ASL level
because port role is really decided at cable connection time
(well... not 100% true).
Baolu, any comments to this series?
Personally, I'm unwilling to take this (or the other 2-patch dwc3 series
adding IDA) because there will only be a single user.
Only a single user ? You mean only a single SoC will use this I guess ?
yeah
But there are many many devices with this SoC and lots of people are
trying to run "plain" Linux on these.
don't get me wrong. I'd really like to have Up Board running mainline
with no extra hacks necessary ;-)
I can see how you don't want this as a phy driver though, I would
be happy to drop the phy-binding bits (they're not really used
anyways) and drop this under drivers/misc adding myself to MAINTAINERS
for it, would that be an acceptable solution ?
For me? sure :-) Let's get Greg and Oliver to agree though.
<snip>
Matthias, assuming Felipe is ok with putting this in drivers/misc
(minus the phy bindings), are you ok with the xhci blurb which
registers the platform-device for the "misc" driver to bind to?
This is the one thing Greg was against. The creation of the "fake"
platform-device from XHCI. I mean, turning it into a real PCI device
will require firmware update, so we might as well update the firmware to
move MUX handling to ASL altogether ;-)
It cannot be turned into a real PCI device, the registers sit in the
middle of the xhci mmio window. Intel has used the possibility in the
xhci spec to add vendor defined capability registers to add the registers
controlling this.
I would really like to see the mux control bits and the xhci code be
separate, but we can move it all to say drivers/usb/host/xhci-intel-cht.c
too if that is what people want, there are 2 downsides to this:
1) The xhci driver will grow a: "depends on EXTCON if X86"
2) The intel-xhci-cht code may not be able to get the extcon devices it
needs, esp. not when the xhci driver is built in; and the extcon drivers
are not. Currently the separate platfrom driver just returns -EPROBE_DEFER
in this case. Doing so from the actual xhci driver is a bad idea as it will
most likely break rootfs on USB scenarios. This will need to be worked around
by getting the extcon's from the same delayed_work which responds to extcon events
and if they are not present yet try again say every 250 ms.
Neither of this is really nice, I believe that the separation the child platform
device gives us is well worth it not being 100% pretty. And it does reflect in
the device topology as one would expect, e.g. /proc/ioports has:
91a00000-91a0ffff : 0000:00:14.0
91a00000-91a0ffff : xhci-hcd
91a08070-91a0846f : intel_cht_usb_phy
Which really does not look so bad to me...
I guess I need todo s/phy/mux/ if we don't do this as a phy driver.
Greg, what is your take on this ?
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
