Hi,
On 05/06/2023 10:24, Heikki Krogerus wrote:
Hi Neil,
On Thu, Jun 01, 2023 at 11:21:13AM +0200, neil.armstrong@xxxxxxxxxx wrote:
From: Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx>
Add support for the ON Semiconductor NB7VPQ904M Type-C USB SuperSpeed
and DisplayPort ALT Mode Linear Redriver chip found on some devices
with a Type-C port.
The redriver compensates ultra High-Speeed DisplayPort and USB
Super Speed signal integrity losses mainly due to PCB & transmission
cables.
The redriver doesn't support SuperSpeed lines swapping, but
can support Type-C SBU lines swapping.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx>
Signed-off-by: Neil Armstrong <neil.armstrong@xxxxxxxxxx>
---
drivers/usb/typec/mux/Kconfig | 8 +
drivers/usb/typec/mux/Makefile | 1 +
drivers/usb/typec/mux/nb7vpq904m.c | 526 +++++++++++++++++++++++++++++++++++++
3 files changed, 535 insertions(+)
This looks good to me, but I think you should register a retimer
instead of a mode switch (the orientation switch is fine).
Indeed, I'm not familiar with namings but by looking around it seems that
redriver and retimers for USB-C applications are exactly the same.
Retimers are handled just like the muxes, so this patch would not need
that many changes, but you would need to change the first patch too.
You would need to declare a "redriver-switch" instead of "mode-switch"
property in your DT (or perhaps make it just "redriver" instead of
"redriver-switch"?).
So it would need some additional handling to also set the retimer state
along the mux, but I was wondering, why having a separate handling
while the retimer state struct is exactly the same as the mux ?
We just need to add a device type for redrivers to the retimer class -
check the attached diff. Something like that.
Let me know what you guys think.
I think I'll switch to retimer, thanks for pointing it to me...
Thanks,
Neil
thanks,
