On 22/04/2020 14:25, Heikki Krogerus wrote:
+linux-usb ml
On Wed, Apr 22, 2020 at 12:17:14PM +0100, Bryan O'Donoghue wrote:
On 14/04/2020 16:15, Heikki Krogerus wrote: > So what you are proposing here is that you want to use tps65986 as
just a port controller (so PHY), right? I don't think that's possible.
Both. Sorry I wasn't clear :)
TCPM (port manager) is the software that implements the USB Type-C and
PD state machines. The USB PD controllers are running their own state
machines, and the thing is that you can't turn off that part of them.
So basically the USB PD controllers are supplying the TCPM
functionality internally.
OK. So forget about the above then. That answers the question why you
didn't implement tps6598x as a tcpm bound device.
What's your feeling on the following.
In DT if we find a child connector then we can determine the state we
are supposed to be in ?
That way it _shouldn't_ change the logic you already depend on the ACPI
systems.
typec1_con: connector {
compatible = "usb-c-connector";
label = "USB-C";
power-role = "dual";
data-role = "dual";
try-power-role = "sink";
source-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
sink-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)
PDO_VAR(5000, 20000, 3000)>;
op-sink-microwatt = <15000000>;
self-powered;
};
we need to control :
http://www.ti.com/lit/an/slva843a/slva843a.pdf
- InitiateSwapToDPF
- InitiateSwapToUFP
- process-swap-to-dfp;
- process-swap-to-ufp;
- InitiateVconnSwap;
- ProcessVconnSwap;
The documentation makes clear some of these settings are mutually exclusive.
You can capture the logic of that with the connector
- power-role = "dual";
- data-role = "dual";
from the connector declaration. Absent the connector declaration the
ACPI launched code should still work as-is.
Alternatively it could be something specific to the chip - as opposed to
the connector.
My thought is you either have these two at the type-c controller level
or inside a child connector node.
Either way tps6598x would consume them.
Something else ? It's important we get the changes upstream, so I'd
appreciate any thoughts you have on the right way to go about this.
So what exactly is the problem here?
Which USB controller are you using? Is it dual-role capable, or do you
have separate xHCI controller and separate USB device controller plus
a mux between them?
Err, checks notes.
Its a ChipIdea HDRC. That part just works.
As I suggested above,
tps6598x: tps6598x@38 {
compatible = "ti,tps6598x";
reg = <0x38>;
interrupt-parent = <&gpio>;
interrupts = <107 IRQ_TYPE_LEVEL_LOW>;
interrupt-names = "irq";
pinctrl-names = "default";
pinctrl-0 = <&typec_pins>;
port {
typec1_dr_sw: endpoint {
remote-endpoint = <&usb1_drd_sw>;
};
};
/* Example A */
typec1_con: connector {
compatible = "usb-c-connector";
label = "USB-C";
power-role = "dual";
data-role = "dual";
try-power-role = "sink";
source-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
sink-pdos = <PDO_FIXED(5000, 3000,
PDO_FIXED_USB_COMM)
PDO_VAR(5000, 20000, 3000)>;
op-sink-microwatt = <15000000>;
};
/* Example B */
power-role = "dual";
data-role = "dual";
try-power-role = "sink";
source-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
sink-pdos = <PDO_FIXED(5000, 3000,
PDO_FIXED_USB_COMM)
PDO_VAR(5000, 20000, 3000)>;
op-sink-microwatt = <15000000>;
};
I think connector is probably the right way to go.
---
bod
