Messages in this thread | | | From | Ruihai Zhou <> | Subject | Re: [PATCH] platform/chrome: cros_ec_typec: deferred probe when typec count mismatch | Date | Thu, 22 Dec 2022 09:53:19 +0800 |
| |
> Sorry, but I agree with Guenter; I don't think this is justification to add a > hack for 1 board in this driver. > > In what situation does the EC task take so long after reboot that it > occurs after a module probe (which occurs shortly after system boot up)? > > Why is the "corsola" board increasing the Type-C port count dynamically > after some delay, and what is that delay amount? Why can't this be set > via CBI/DT or its equivalent on your ARM platform? > > This seems like fragile code in the EC and should be fixed there. The > number of Type-C ports reported by the EC really should be invariant > across the boot lifecycle. I don't think this patch can be accepted. >
Alright, I got it. Thank you for your patience and the suggestions.
Because the tcpc/pd tasks are not needed for the HDMI port. The EC don't want the tasks initiated on starting up, and increase the counts after the tasks are launched. The delay amount was 2 second before, (always failed when ec reboot on firmware normal mode) and change to 1 second later, and 500ms yesterday(not reproduce until now). The delay on EC can be referred to here [1]. However, with the current design, the number of type-c ports reported by EC isn't invariant across the boot lifecycle. Also, maybe printing the counts getting from EC when encountered this field will be a littel helpful for debugging. just an insignificant thought.
> If you really need to change the number of ports dynamically in the EC, > add a board specific-hook to not respond to the EC_CMD_USB_PD_PORTS > host command until you have "set" the number of ports.
Got it. Thank you again for your suggestions.
Link: [1] https://source.chromium.org/chromiumos/chromiumos/codesearch/+/main:src/platform/ec/zephyr/program/corsola/src/usbc.c;l=222
| |