Now that I have an ecc and can somewhat find my way around the ec source code I wanted to look into the ocp on the usb ports. (Mostly so I can use my nice portable oled display without having to plug a power supply into it).
It seems that we are dealing with multiple possible culprits here, for one the pd controller itself has configurable ocp, however it should report when it happens and I see nothing on the ccd console when the external display stries and fails to start up.
So my eye is further down the stream on the fancy power mux chips that do the actual switching, they too have configurable ocp. While according to the datasheet the default for both in and out are 3A it has an i2c interface which seems to be connected to the pd controller. In order for 5A input to work the pd controller needs to be able to set the input ocp so that interface probably works.
My current theory is the 5V ocp doesn’t get properly configured even for stuff that correctly request 3A via pd. Unfortunately the pd controller runs it’s own firmware which we don’t have access too and it seems we also can’t access the power muxes to even check what the registers are set to. Can framework please either fix this or give us the tools to do so ourselves?
IMO just set the ocp of the power mux to the max, you already got the ocp from the charge controller.
Also why the fancy power muxes? The pd controller only needs dumb mosfets according to the datasheet so this seems like extra complexity for worse functionality.
I agree. There is not much we can do here, unless we completely reverse engineer the CYPD8225 firmware.
At one point, I wished to use it to act as a sniffer for the CC messages, but figured it would be too much work.
One feature we do need is letting the user manually choose if we are a sink/source on a particular port, so we can have better compatibility with dual role battery power banks.
Also, take care, the FW schematics might be wrong.
From the schematics, it looks like it should be able to supply 15W to all the USB ports, but the FW laptops cannot do that.
Ports 1,2,3, and 4 are shared on a first come first serve basis. So they are 1.5A by default, but one port from any of these can negotiate 3A over PD. Once that is taken, the other ports are limited to 1.5A.
From the “schematic” it looks like the left side 5v buck converter only has to do the fan, keyboard backlight and part of the audio codec and the reight side one has the ram, touchpad and finger print sensor. Appart from the ram those are all not very big ticket items and even with 6A going to the ports the remaining 5A should be more than enough. Not sure what this logic is supposed to be for, would be nice to get some info from framework about that.
Personally I’d want my ports to output 3A unless the device specifically asks for less just for better compatibility.
In cypress_pd_common.c there are already a few very powerful commands available, I just did some i2c writes based on the setting to 3a code. Also given it’s common this also applies somewhat to the 16 though there it’s probably more complicated cause of the 6 port thing.
The problem is I have found no documentation on what the registers are/do outside of guessing based on the existing code and likely there is also a lot of customized stuff in the pd firmware cause they use smart power muxes and not dumb mosfets like the pd controoler seems to be designed for.
It looks like it already traces at least some of the communication to the pd controller during normal operation.
