From: Jos Wang joswang@lenovo.com
According to the USB PD3 CTS specification (https://usb.org/document-library/ usb-power-delivery-compliance-test-specification-0/ USB_PD3_CTS_Q4_2024_OR.zip), the requirements for tSenderResponse are different in PD2 and PD3 modes, see Table 19 Timing Table & Calculations. For PD2 mode, the tSenderResponse min 24ms and max 30ms; for PD3 mode, the tSenderResponse min 27ms and max 33ms.
For the "TEST.PD.PROT.SRC.2 Get_Source_Cap No Request" test item, after receiving the Source_Capabilities Message sent by the UUT, the tester deliberately does not send a Request Message in order to force the SenderResponse timer on the Source UUT to timeout. The Tester checks that a Hard Reset is detected between tSenderResponse min and max，the delay is between the last bit of the GoodCRC Message EOP has been sent and the first bit of Hard Reset SOP has been received. The current code does not distinguish between PD2 and PD3 modes, and tSenderResponse defaults to 60ms. This will cause this test item and the following tests to fail: TEST.PD.PROT.SRC3.2 SenderResponseTimer Timeout TEST.PD.PROT.SNK.6 SenderResponseTimer Timeout
Considering factors such as SOC performance, i2c rate, and the speed of PD chip sending data, "pd2-sender-response-time-ms" and "pd3-sender-response-time-ms" DT time properties are added to allow users to define platform timing. For values that have not been explicitly defined in DT using this property, a default value of 27ms for PD2 tSenderResponse and 30ms for PD3 tSenderResponse is set.
Fixes: 2eadc33f40d4 ("typec: tcpm: Add core support for sink side PPS") Cc: stable@vger.kernel.org Signed-off-by: Jos Wang joswang@lenovo.com --- v1 -> v2: - modify the commit message - patch 1/2 and patch 2/2 are placed in the same thread
drivers/usb/typec/tcpm/tcpm.c | 50 +++++++++++++++++++++++------------ include/linux/usb/pd.h | 3 ++- 2 files changed, 35 insertions(+), 18 deletions(-)
diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c index 6021eeb903fe..3a159bfcf382 100644 --- a/drivers/usb/typec/tcpm/tcpm.c +++ b/drivers/usb/typec/tcpm/tcpm.c @@ -314,12 +314,16 @@ struct pd_data { * @sink_wait_cap_time: Deadline (in ms) for tTypeCSinkWaitCap timer * @ps_src_wait_off_time: Deadline (in ms) for tPSSourceOff timer * @cc_debounce_time: Deadline (in ms) for tCCDebounce timer + * @pd2_sender_response_time: Deadline (in ms) for pd20 tSenderResponse timer + * @pd3_sender_response_time: Deadline (in ms) for pd30 tSenderResponse timer */ struct pd_timings { u32 sink_wait_cap_time; u32 ps_src_off_time; u32 cc_debounce_time; u32 snk_bc12_cmpletion_time; + u32 pd2_sender_response_time; + u32 pd3_sender_response_time; };
struct tcpm_port { @@ -3776,7 +3780,9 @@ static bool tcpm_send_queued_message(struct tcpm_port *port) } else if (port->pwr_role == TYPEC_SOURCE) { tcpm_ams_finish(port); tcpm_set_state(port, HARD_RESET_SEND, - PD_T_SENDER_RESPONSE); + port->negotiated_rev >= PD_REV30 ? + port->timings.pd3_sender_response_time : + port->timings.pd2_sender_response_time); } else { tcpm_ams_finish(port); } @@ -4619,6 +4625,9 @@ static void run_state_machine(struct tcpm_port *port) enum typec_pwr_opmode opmode; unsigned int msecs; enum tcpm_state upcoming_state; + u32 sender_response_time = port->negotiated_rev >= PD_REV30 ? + port->timings.pd3_sender_response_time : + port->timings.pd2_sender_response_time;
if (port->tcpc->check_contaminant && port->state != CHECK_CONTAMINANT) port->potential_contaminant = ((port->enter_state == SRC_ATTACH_WAIT && @@ -5113,7 +5122,7 @@ static void run_state_machine(struct tcpm_port *port) tcpm_set_state(port, SNK_WAIT_CAPABILITIES, 0); } else { tcpm_set_state_cond(port, hard_reset_state(port), - PD_T_SENDER_RESPONSE); + sender_response_time); } break; case SNK_NEGOTIATE_PPS_CAPABILITIES: @@ -5135,7 +5144,7 @@ static void run_state_machine(struct tcpm_port *port) tcpm_set_state(port, SNK_READY, 0); } else { tcpm_set_state_cond(port, hard_reset_state(port), - PD_T_SENDER_RESPONSE); + sender_response_time); } break; case SNK_TRANSITION_SINK: @@ -5387,7 +5396,7 @@ static void run_state_machine(struct tcpm_port *port) port->message_id_prime = 0; port->rx_msgid_prime = -1; tcpm_pd_send_control(port, PD_CTRL_SOFT_RESET, TCPC_TX_SOP_PRIME); - tcpm_set_state_cond(port, ready_state(port), PD_T_SENDER_RESPONSE); + tcpm_set_state_cond(port, ready_state(port), sender_response_time); } else { port->message_id = 0; port->rx_msgid = -1; @@ -5398,7 +5407,7 @@ static void run_state_machine(struct tcpm_port *port) tcpm_set_state_cond(port, hard_reset_state(port), 0); else tcpm_set_state_cond(port, hard_reset_state(port), - PD_T_SENDER_RESPONSE); + sender_response_time); } break;
@@ -5409,8 +5418,7 @@ static void run_state_machine(struct tcpm_port *port) port->send_discover = true; port->send_discover_prime = false; } - tcpm_set_state_cond(port, DR_SWAP_SEND_TIMEOUT, - PD_T_SENDER_RESPONSE); + tcpm_set_state_cond(port, DR_SWAP_SEND_TIMEOUT, sender_response_time); break; case DR_SWAP_ACCEPT: tcpm_pd_send_control(port, PD_CTRL_ACCEPT, TCPC_TX_SOP); @@ -5444,7 +5452,7 @@ static void run_state_machine(struct tcpm_port *port) tcpm_set_state(port, ERROR_RECOVERY, 0); break; } - tcpm_set_state_cond(port, FR_SWAP_SEND_TIMEOUT, PD_T_SENDER_RESPONSE); + tcpm_set_state_cond(port, FR_SWAP_SEND_TIMEOUT, sender_response_time); break; case FR_SWAP_SEND_TIMEOUT: tcpm_set_state(port, ERROR_RECOVERY, 0); @@ -5475,8 +5483,7 @@ static void run_state_machine(struct tcpm_port *port) break; case PR_SWAP_SEND: tcpm_pd_send_control(port, PD_CTRL_PR_SWAP, TCPC_TX_SOP); - tcpm_set_state_cond(port, PR_SWAP_SEND_TIMEOUT, - PD_T_SENDER_RESPONSE); + tcpm_set_state_cond(port, PR_SWAP_SEND_TIMEOUT, sender_response_time); break; case PR_SWAP_SEND_TIMEOUT: tcpm_swap_complete(port, -ETIMEDOUT); @@ -5574,8 +5581,7 @@ static void run_state_machine(struct tcpm_port *port) break; case VCONN_SWAP_SEND: tcpm_pd_send_control(port, PD_CTRL_VCONN_SWAP, TCPC_TX_SOP); - tcpm_set_state(port, VCONN_SWAP_SEND_TIMEOUT, - PD_T_SENDER_RESPONSE); + tcpm_set_state(port, VCONN_SWAP_SEND_TIMEOUT, sender_response_time); break; case VCONN_SWAP_SEND_TIMEOUT: tcpm_swap_complete(port, -ETIMEDOUT); @@ -5656,23 +5662,21 @@ static void run_state_machine(struct tcpm_port *port) break; case GET_STATUS_SEND: tcpm_pd_send_control(port, PD_CTRL_GET_STATUS, TCPC_TX_SOP); - tcpm_set_state(port, GET_STATUS_SEND_TIMEOUT, - PD_T_SENDER_RESPONSE); + tcpm_set_state(port, GET_STATUS_SEND_TIMEOUT, sender_response_time); break; case GET_STATUS_SEND_TIMEOUT: tcpm_set_state(port, ready_state(port), 0); break; case GET_PPS_STATUS_SEND: tcpm_pd_send_control(port, PD_CTRL_GET_PPS_STATUS, TCPC_TX_SOP); - tcpm_set_state(port, GET_PPS_STATUS_SEND_TIMEOUT, - PD_T_SENDER_RESPONSE); + tcpm_set_state(port, GET_PPS_STATUS_SEND_TIMEOUT, sender_response_time); break; case GET_PPS_STATUS_SEND_TIMEOUT: tcpm_set_state(port, ready_state(port), 0); break; case GET_SINK_CAP: tcpm_pd_send_control(port, PD_CTRL_GET_SINK_CAP, TCPC_TX_SOP); - tcpm_set_state(port, GET_SINK_CAP_TIMEOUT, PD_T_SENDER_RESPONSE); + tcpm_set_state(port, GET_SINK_CAP_TIMEOUT, sender_response_time); break; case GET_SINK_CAP_TIMEOUT: port->sink_cap_done = true; @@ -7109,6 +7113,18 @@ static void tcpm_fw_get_timings(struct tcpm_port *port, struct fwnode_handle *fw ret = fwnode_property_read_u32(fwnode, "sink-bc12-completion-time-ms", &val); if (!ret) port->timings.snk_bc12_cmpletion_time = val; + + ret = fwnode_property_read_u32(fwnode, "pd2-sender-response-time-ms", &val); + if (!ret) + port->timings.pd2_sender_response_time = val; + else + port->timings.pd2_sender_response_time = PD_T_PD2_SENDER_RESPONSE; + + ret = fwnode_property_read_u32(fwnode, "pd3-sender-response-time-ms", &val); + if (!ret) + port->timings.pd3_sender_response_time = val; + else + port->timings.pd3_sender_response_time = PD_T_PD3_SENDER_RESPONSE; }
static int tcpm_fw_get_caps(struct tcpm_port *port, struct fwnode_handle *fwnode) diff --git a/include/linux/usb/pd.h b/include/linux/usb/pd.h index d50098fb16b5..9c599e851b9a 100644 --- a/include/linux/usb/pd.h +++ b/include/linux/usb/pd.h @@ -457,7 +457,6 @@ static inline unsigned int rdo_max_power(u32 rdo) #define PD_T_NO_RESPONSE 5000 /* 4.5 - 5.5 seconds */ #define PD_T_DB_DETECT 10000 /* 10 - 15 seconds */ #define PD_T_SEND_SOURCE_CAP 150 /* 100 - 200 ms */ -#define PD_T_SENDER_RESPONSE 60 /* 24 - 30 ms, relaxed */ #define PD_T_RECEIVER_RESPONSE 15 /* 15ms max */ #define PD_T_SOURCE_ACTIVITY 45 #define PD_T_SINK_ACTIVITY 135 @@ -491,6 +490,8 @@ static inline unsigned int rdo_max_power(u32 rdo) #define PD_T_CC_DEBOUNCE 200 /* 100 - 200 ms */ #define PD_T_PD_DEBOUNCE 20 /* 10 - 20 ms */ #define PD_T_TRY_CC_DEBOUNCE 15 /* 10 - 20 ms */ +#define PD_T_PD2_SENDER_RESPONSE 27 /* PD20 spec 24 - 30 ms */ +#define PD_T_PD3_SENDER_RESPONSE 30 /* PD30 spec 27 - 33 ms */
#define PD_N_CAPS_COUNT (PD_T_NO_RESPONSE / PD_T_SEND_SOURCE_CAP) #define PD_N_HARD_RESET_COUNT 2
On Sun, Dec 22, 2024 at 06:52:39PM +0800, joswang wrote:
From: Jos Wang joswang@lenovo.com
According to the USB PD3 CTS specification (https://usb.org/document-library/ usb-power-delivery-compliance-test-specification-0/ USB_PD3_CTS_Q4_2024_OR.zip), the requirements for tSenderResponse are different in PD2 and PD3 modes, see Table 19 Timing Table & Calculations. For PD2 mode, the tSenderResponse min 24ms and max 30ms; for PD3 mode, the tSenderResponse min 27ms and max 33ms.
For the "TEST.PD.PROT.SRC.2 Get_Source_Cap No Request" test item, after receiving the Source_Capabilities Message sent by the UUT, the tester deliberately does not send a Request Message in order to force the SenderResponse timer on the Source UUT to timeout. The Tester checks that a Hard Reset is detected between tSenderResponse min and max，the delay is between the last bit of the GoodCRC Message EOP has been sent and the first bit of Hard Reset SOP has been received. The current code does not distinguish between PD2 and PD3 modes, and tSenderResponse defaults to 60ms. This will cause this test item and the following tests to fail: TEST.PD.PROT.SRC3.2 SenderResponseTimer Timeout TEST.PD.PROT.SNK.6 SenderResponseTimer Timeout
Considering factors such as SOC performance, i2c rate, and the speed of PD chip sending data, "pd2-sender-response-time-ms" and "pd3-sender-response-time-ms" DT time properties are added to allow users to define platform timing. For values that have not been explicitly defined in DT using this property, a default value of 27ms for PD2 tSenderResponse and 30ms for PD3 tSenderResponse is set.
You have several different changes squashed into the same commit: - Change the timeout from 60 ms to 27-30 ms (I'd recommend using 27 ms as it fits both 24-30 ms and 27-33 ms ranges, - Make timeout depend on the PD version, - Make timeouts configurable via DT.
Only the first item is a fix per se and only that change should be considered for backporting. Please unsquash your changes into logical commits. Theoretically the second change can be thought about as a part of the third change (making timeouts configurable) or of the fist change (fix the timeout to follow the standard), but I'd suggest having three separate commits.
Fixes: 2eadc33f40d4 ("typec: tcpm: Add core support for sink side PPS") Cc: stable@vger.kernel.org Signed-off-by: Jos Wang joswang@lenovo.com
v1 -> v2:
- modify the commit message
- patch 1/2 and patch 2/2 are placed in the same thread
Hi, thanks for your help in reviewing the code, and happy new year to you and your family!
For the first commit you mentioned (modification time is 27ms), I understand that just modify the include/linux/usb/pd.h file: diff --git a/include/linux/usb/pd.h b/include/linux/usb/pd.h index d50098fb16b5..cd2cc535d21d 100644 --- a/include/linux/usb/pd.h +++ b/include/linux/usb/pd.h @@ -457,7 +457,7 @@ static inline unsigned int rdo_max_power(u32 rdo) #define PD_T_NO_RESPONSE 5000 /* 4.5 - 5.5 seconds */ #define PD_T_DB_DETECT 10000 /* 10 - 15 seconds */ #define PD_T_SEND_SOURCE_CAP 150 /* 100 - 200 ms */ -#define PD_T_SENDER_RESPONSE 60 /* 24 - 30 ms, relaxed */ +#define PD_T_SENDER_RESPONSE 27 /* 24 - 30 ms, relaxed */ #define PD_T_RECEIVER_RESPONSE 15 /* 15ms max */ #define PD_T_SOURCE_ACTIVITY 45 #define PD_T_SINK_ACTIVITY 135
Is my understanding correct?
Thanks Jos Wang
On Sun, Dec 22, 2024 at 9:14 PM Dmitry Baryshkov dmitry.baryshkov@linaro.org wrote:
On Sun, Dec 22, 2024 at 06:52:39PM +0800, joswang wrote:
From: Jos Wang joswang@lenovo.com
According to the USB PD3 CTS specification (https://usb.org/document-library/ usb-power-delivery-compliance-test-specification-0/ USB_PD3_CTS_Q4_2024_OR.zip), the requirements for tSenderResponse are different in PD2 and PD3 modes, see Table 19 Timing Table & Calculations. For PD2 mode, the tSenderResponse min 24ms and max 30ms; for PD3 mode, the tSenderResponse min 27ms and max 33ms.
For the "TEST.PD.PROT.SRC.2 Get_Source_Cap No Request" test item, after receiving the Source_Capabilities Message sent by the UUT, the tester deliberately does not send a Request Message in order to force the SenderResponse timer on the Source UUT to timeout. The Tester checks that a Hard Reset is detected between tSenderResponse min and max，the delay is between the last bit of the GoodCRC Message EOP has been sent and the first bit of Hard Reset SOP has been received. The current code does not distinguish between PD2 and PD3 modes, and tSenderResponse defaults to 60ms. This will cause this test item and the following tests to fail: TEST.PD.PROT.SRC3.2 SenderResponseTimer Timeout TEST.PD.PROT.SNK.6 SenderResponseTimer Timeout
Considering factors such as SOC performance, i2c rate, and the speed of PD chip sending data, "pd2-sender-response-time-ms" and "pd3-sender-response-time-ms" DT time properties are added to allow users to define platform timing. For values that have not been explicitly defined in DT using this property, a default value of 27ms for PD2 tSenderResponse and 30ms for PD3 tSenderResponse is set.
You have several different changes squashed into the same commit:
- Change the timeout from 60 ms to 27-30 ms (I'd recommend using 27 ms as it fits both 24-30 ms and 27-33 ms ranges,
- Make timeout depend on the PD version,
- Make timeouts configurable via DT.
Only the first item is a fix per se and only that change should be considered for backporting. Please unsquash your changes into logical commits. Theoretically the second change can be thought about as a part of the third change (making timeouts configurable) or of the fist change (fix the timeout to follow the standard), but I'd suggest having three separate commits.
Fixes: 2eadc33f40d4 ("typec: tcpm: Add core support for sink side PPS") Cc: stable@vger.kernel.org Signed-off-by: Jos Wang joswang@lenovo.com
v1 -> v2:
- modify the commit message
- patch 1/2 and patch 2/2 are placed in the same thread
-- With best wishes Dmitry
On Wed, Jan 01, 2025 at 09:00:01PM +0800, Jos Wang wrote:
Hi, thanks for your help in reviewing the code, and happy new year to you and your family!
For the first commit you mentioned (modification time is 27ms), I understand that just modify the include/linux/usb/pd.h file:
In future please respond under the comment, not at the top of the message. Thank you.
diff --git a/include/linux/usb/pd.h b/include/linux/usb/pd.h index d50098fb16b5..cd2cc535d21d 100644 --- a/include/linux/usb/pd.h +++ b/include/linux/usb/pd.h @@ -457,7 +457,7 @@ static inline unsigned int rdo_max_power(u32 rdo) #define PD_T_NO_RESPONSE 5000 /* 4.5 - 5.5 seconds */ #define PD_T_DB_DETECT 10000 /* 10 - 15 seconds */ #define PD_T_SEND_SOURCE_CAP 150 /* 100 - 200 ms */ -#define PD_T_SENDER_RESPONSE 60 /* 24 - 30 ms, relaxed */ +#define PD_T_SENDER_RESPONSE 27 /* 24 - 30 ms, relaxed */ #define PD_T_RECEIVER_RESPONSE 15 /* 15ms max */ #define PD_T_SOURCE_ACTIVITY 45 #define PD_T_SINK_ACTIVITY 135
Is my understanding correct?
Yes.
Thanks Jos Wang
On Sun, Dec 22, 2024 at 9:14 PM Dmitry Baryshkov dmitry.baryshkov@linaro.org wrote:
On Sun, Dec 22, 2024 at 06:52:39PM +0800, joswang wrote:
From: Jos Wang joswang@lenovo.com
According to the USB PD3 CTS specification (https://usb.org/document-library/ usb-power-delivery-compliance-test-specification-0/ USB_PD3_CTS_Q4_2024_OR.zip), the requirements for tSenderResponse are different in PD2 and PD3 modes, see Table 19 Timing Table & Calculations. For PD2 mode, the tSenderResponse min 24ms and max 30ms; for PD3 mode, the tSenderResponse min 27ms and max 33ms.
For the "TEST.PD.PROT.SRC.2 Get_Source_Cap No Request" test item, after receiving the Source_Capabilities Message sent by the UUT, the tester deliberately does not send a Request Message in order to force the SenderResponse timer on the Source UUT to timeout. The Tester checks that a Hard Reset is detected between tSenderResponse min and max，the delay is between the last bit of the GoodCRC Message EOP has been sent and the first bit of Hard Reset SOP has been received. The current code does not distinguish between PD2 and PD3 modes, and tSenderResponse defaults to 60ms. This will cause this test item and the following tests to fail: TEST.PD.PROT.SRC3.2 SenderResponseTimer Timeout TEST.PD.PROT.SNK.6 SenderResponseTimer Timeout
Considering factors such as SOC performance, i2c rate, and the speed of PD chip sending data, "pd2-sender-response-time-ms" and "pd3-sender-response-time-ms" DT time properties are added to allow users to define platform timing. For values that have not been explicitly defined in DT using this property, a default value of 27ms for PD2 tSenderResponse and 30ms for PD3 tSenderResponse is set.
You have several different changes squashed into the same commit:
- Change the timeout from 60 ms to 27-30 ms (I'd recommend using 27 ms as it fits both 24-30 ms and 27-33 ms ranges,
- Make timeout depend on the PD version,
- Make timeouts configurable via DT.
Only the first item is a fix per se and only that change should be considered for backporting. Please unsquash your changes into logical commits. Theoretically the second change can be thought about as a part of the third change (making timeouts configurable) or of the fist change (fix the timeout to follow the standard), but I'd suggest having three separate commits.
Fixes: 2eadc33f40d4 ("typec: tcpm: Add core support for sink side PPS") Cc: stable@vger.kernel.org Signed-off-by: Jos Wang joswang@lenovo.com
v1 -> v2:
- modify the commit message
- patch 1/2 and patch 2/2 are placed in the same thread
-- With best wishes Dmitry
On Fri, Jan 3, 2025 at 1:39 PM Dmitry Baryshkov dmitry.baryshkov@linaro.org wrote:
On Wed, Jan 01, 2025 at 09:00:01PM +0800, Jos Wang wrote:
Hi, thanks for your help in reviewing the code, and happy new year to you and your family!
For the first commit you mentioned (modification time is 27ms), I understand that just modify the include/linux/usb/pd.h file:
In future please respond under the comment, not at the top of the message. Thank you.
OK
diff --git a/include/linux/usb/pd.h b/include/linux/usb/pd.h index d50098fb16b5..cd2cc535d21d 100644 --- a/include/linux/usb/pd.h +++ b/include/linux/usb/pd.h @@ -457,7 +457,7 @@ static inline unsigned int rdo_max_power(u32 rdo) #define PD_T_NO_RESPONSE 5000 /* 4.5 - 5.5 seconds */ #define PD_T_DB_DETECT 10000 /* 10 - 15 seconds */ #define PD_T_SEND_SOURCE_CAP 150 /* 100 - 200 ms */ -#define PD_T_SENDER_RESPONSE 60 /* 24 - 30 ms, relaxed */ +#define PD_T_SENDER_RESPONSE 27 /* 24 - 30 ms, relaxed */ #define PD_T_RECEIVER_RESPONSE 15 /* 15ms max */ #define PD_T_SOURCE_ACTIVITY 45 #define PD_T_SINK_ACTIVITY 135
Is my understanding correct?
Yes.
Thanks you
Thanks Jos Wang
On Sun, Dec 22, 2024 at 9:14 PM Dmitry Baryshkov dmitry.baryshkov@linaro.org wrote:
On Sun, Dec 22, 2024 at 06:52:39PM +0800, joswang wrote:
From: Jos Wang joswang@lenovo.com
According to the USB PD3 CTS specification (https://usb.org/document-library/ usb-power-delivery-compliance-test-specification-0/ USB_PD3_CTS_Q4_2024_OR.zip), the requirements for tSenderResponse are different in PD2 and PD3 modes, see Table 19 Timing Table & Calculations. For PD2 mode, the tSenderResponse min 24ms and max 30ms; for PD3 mode, the tSenderResponse min 27ms and max 33ms.
For the "TEST.PD.PROT.SRC.2 Get_Source_Cap No Request" test item, after receiving the Source_Capabilities Message sent by the UUT, the tester deliberately does not send a Request Message in order to force the SenderResponse timer on the Source UUT to timeout. The Tester checks that a Hard Reset is detected between tSenderResponse min and max，the delay is between the last bit of the GoodCRC Message EOP has been sent and the first bit of Hard Reset SOP has been received. The current code does not distinguish between PD2 and PD3 modes, and tSenderResponse defaults to 60ms. This will cause this test item and the following tests to fail: TEST.PD.PROT.SRC3.2 SenderResponseTimer Timeout TEST.PD.PROT.SNK.6 SenderResponseTimer Timeout
Considering factors such as SOC performance, i2c rate, and the speed of PD chip sending data, "pd2-sender-response-time-ms" and "pd3-sender-response-time-ms" DT time properties are added to allow users to define platform timing. For values that have not been explicitly defined in DT using this property, a default value of 27ms for PD2 tSenderResponse and 30ms for PD3 tSenderResponse is set.
You have several different changes squashed into the same commit:
- Change the timeout from 60 ms to 27-30 ms (I'd recommend using 27 ms as it fits both 24-30 ms and 27-33 ms ranges,
- Make timeout depend on the PD version,
- Make timeouts configurable via DT.
Only the first item is a fix per se and only that change should be considered for backporting. Please unsquash your changes into logical commits. Theoretically the second change can be thought about as a part of the third change (making timeouts configurable) or of the fist change (fix the timeout to follow the standard), but I'd suggest having three separate commits.
Fixes: 2eadc33f40d4 ("typec: tcpm: Add core support for sink side PPS") Cc: stable@vger.kernel.org Signed-off-by: Jos Wang joswang@lenovo.com
v1 -> v2:
- modify the commit message
- patch 1/2 and patch 2/2 are placed in the same thread
-- With best wishes Dmitry
-- With best wishes Dmitry
On Sun, Dec 22, 2024 at 9:14 PM Dmitry Baryshkov dmitry.baryshkov@linaro.org wrote:
On Sun, Dec 22, 2024 at 06:52:39PM +0800, joswang wrote:
From: Jos Wang joswang@lenovo.com
According to the USB PD3 CTS specification (https://usb.org/document-library/ usb-power-delivery-compliance-test-specification-0/ USB_PD3_CTS_Q4_2024_OR.zip), the requirements for tSenderResponse are different in PD2 and PD3 modes, see Table 19 Timing Table & Calculations. For PD2 mode, the tSenderResponse min 24ms and max 30ms; for PD3 mode, the tSenderResponse min 27ms and max 33ms.
For the "TEST.PD.PROT.SRC.2 Get_Source_Cap No Request" test item, after receiving the Source_Capabilities Message sent by the UUT, the tester deliberately does not send a Request Message in order to force the SenderResponse timer on the Source UUT to timeout. The Tester checks that a Hard Reset is detected between tSenderResponse min and max，the delay is between the last bit of the GoodCRC Message EOP has been sent and the first bit of Hard Reset SOP has been received. The current code does not distinguish between PD2 and PD3 modes, and tSenderResponse defaults to 60ms. This will cause this test item and the following tests to fail: TEST.PD.PROT.SRC3.2 SenderResponseTimer Timeout TEST.PD.PROT.SNK.6 SenderResponseTimer Timeout
Considering factors such as SOC performance, i2c rate, and the speed of PD chip sending data, "pd2-sender-response-time-ms" and "pd3-sender-response-time-ms" DT time properties are added to allow users to define platform timing. For values that have not been explicitly defined in DT using this property, a default value of 27ms for PD2 tSenderResponse and 30ms for PD3 tSenderResponse is set.
You have several different changes squashed into the same commit:
- Change the timeout from 60 ms to 27-30 ms (I'd recommend using 27 ms as it fits both 24-30 ms and 27-33 ms ranges,
- Make timeout depend on the PD version,
- Make timeouts configurable via DT.
Only the first item is a fix per se and only that change should be considered for backporting. Please unsquash your changes into logical commits. Theoretically the second change can be thought about as a part of the third change (making timeouts configurable) or of the fist change (fix the timeout to follow the standard), but I'd suggest having three separate commits.
The patch is divided into patch1 (fix the timeout to follow the standard), patch2 (Make timeout depend on the PD version) and patch3 (Make timeouts configurable via DT). Do you suggest that these three patches should be submitted as V3 version, or patch1 and patch2 should be submitted separately? Please help to confirm, thank you.
Fixes: 2eadc33f40d4 ("typec: tcpm: Add core support for sink side PPS") Cc: stable@vger.kernel.org Signed-off-by: Jos Wang joswang@lenovo.com
v1 -> v2:
- modify the commit message
- patch 1/2 and patch 2/2 are placed in the same thread
-- With best wishes Dmitry
On Sun, 5 Jan 2025 at 04:51, Jos Wang joswang1221@gmail.com wrote:
On Sun, Dec 22, 2024 at 9:14 PM Dmitry Baryshkov dmitry.baryshkov@linaro.org wrote:
On Sun, Dec 22, 2024 at 06:52:39PM +0800, joswang wrote:
From: Jos Wang joswang@lenovo.com
According to the USB PD3 CTS specification (https://usb.org/document-library/ usb-power-delivery-compliance-test-specification-0/ USB_PD3_CTS_Q4_2024_OR.zip), the requirements for tSenderResponse are different in PD2 and PD3 modes, see Table 19 Timing Table & Calculations. For PD2 mode, the tSenderResponse min 24ms and max 30ms; for PD3 mode, the tSenderResponse min 27ms and max 33ms.
For the "TEST.PD.PROT.SRC.2 Get_Source_Cap No Request" test item, after receiving the Source_Capabilities Message sent by the UUT, the tester deliberately does not send a Request Message in order to force the SenderResponse timer on the Source UUT to timeout. The Tester checks that a Hard Reset is detected between tSenderResponse min and max，the delay is between the last bit of the GoodCRC Message EOP has been sent and the first bit of Hard Reset SOP has been received. The current code does not distinguish between PD2 and PD3 modes, and tSenderResponse defaults to 60ms. This will cause this test item and the following tests to fail: TEST.PD.PROT.SRC3.2 SenderResponseTimer Timeout TEST.PD.PROT.SNK.6 SenderResponseTimer Timeout
Considering factors such as SOC performance, i2c rate, and the speed of PD chip sending data, "pd2-sender-response-time-ms" and "pd3-sender-response-time-ms" DT time properties are added to allow users to define platform timing. For values that have not been explicitly defined in DT using this property, a default value of 27ms for PD2 tSenderResponse and 30ms for PD3 tSenderResponse is set.
You have several different changes squashed into the same commit:
- Change the timeout from 60 ms to 27-30 ms (I'd recommend using 27 ms as it fits both 24-30 ms and 27-33 ms ranges,
- Make timeout depend on the PD version,
- Make timeouts configurable via DT.
Only the first item is a fix per se and only that change should be considered for backporting. Please unsquash your changes into logical commits. Theoretically the second change can be thought about as a part of the third change (making timeouts configurable) or of the fist change (fix the timeout to follow the standard), but I'd suggest having three separate commits.
The patch is divided into patch1 (fix the timeout to follow the standard), patch2 (Make timeout depend on the PD version) and patch3 (Make timeouts configurable via DT). Do you suggest that these three patches should be submitted as V3 version, or patch1 and patch2 should be submitted separately? Please help to confirm, thank you.
Single series should be fine.
Fixes: 2eadc33f40d4 ("typec: tcpm: Add core support for sink side PPS") Cc: stable@vger.kernel.org Signed-off-by: Jos Wang joswang@lenovo.com
v1 -> v2:
- modify the commit message
- patch 1/2 and patch 2/2 are placed in the same thread
-- With best wishes Dmitry
On Sun, Jan 5, 2025 at 2:32 PM Dmitry Baryshkov dmitry.baryshkov@linaro.org wrote:
On Sun, 5 Jan 2025 at 04:51, Jos Wang joswang1221@gmail.com wrote:
On Sun, Dec 22, 2024 at 9:14 PM Dmitry Baryshkov dmitry.baryshkov@linaro.org wrote:
On Sun, Dec 22, 2024 at 06:52:39PM +0800, joswang wrote:
From: Jos Wang joswang@lenovo.com
According to the USB PD3 CTS specification (https://usb.org/document-library/ usb-power-delivery-compliance-test-specification-0/ USB_PD3_CTS_Q4_2024_OR.zip), the requirements for tSenderResponse are different in PD2 and PD3 modes, see Table 19 Timing Table & Calculations. For PD2 mode, the tSenderResponse min 24ms and max 30ms; for PD3 mode, the tSenderResponse min 27ms and max 33ms.
For the "TEST.PD.PROT.SRC.2 Get_Source_Cap No Request" test item, after receiving the Source_Capabilities Message sent by the UUT, the tester deliberately does not send a Request Message in order to force the SenderResponse timer on the Source UUT to timeout. The Tester checks that a Hard Reset is detected between tSenderResponse min and max，the delay is between the last bit of the GoodCRC Message EOP has been sent and the first bit of Hard Reset SOP has been received. The current code does not distinguish between PD2 and PD3 modes, and tSenderResponse defaults to 60ms. This will cause this test item and the following tests to fail: TEST.PD.PROT.SRC3.2 SenderResponseTimer Timeout TEST.PD.PROT.SNK.6 SenderResponseTimer Timeout
Considering factors such as SOC performance, i2c rate, and the speed of PD chip sending data, "pd2-sender-response-time-ms" and "pd3-sender-response-time-ms" DT time properties are added to allow users to define platform timing. For values that have not been explicitly defined in DT using this property, a default value of 27ms for PD2 tSenderResponse and 30ms for PD3 tSenderResponse is set.
You have several different changes squashed into the same commit:
- Change the timeout from 60 ms to 27-30 ms (I'd recommend using 27 ms as it fits both 24-30 ms and 27-33 ms ranges,
- Make timeout depend on the PD version,
- Make timeouts configurable via DT.
Only the first item is a fix per se and only that change should be considered for backporting. Please unsquash your changes into logical commits. Theoretically the second change can be thought about as a part of the third change (making timeouts configurable) or of the fist change (fix the timeout to follow the standard), but I'd suggest having three separate commits.
The patch is divided into patch1 (fix the timeout to follow the standard), patch2 (Make timeout depend on the PD version) and patch3 (Make timeouts configurable via DT). Do you suggest that these three patches should be submitted as V3 version, or patch1 and patch2 should be submitted separately? Please help to confirm, thank you.
Single series should be fine.
OK，One by one, after the first patch (fix the timeout to follow the standard) is merged, submit the second patch (Make timeout depend on the PD version). The first patch can be found at: https://patchwork.kernel.org/project/linux-usb/patch/20250105125251.5190-1-j...
Fixes: 2eadc33f40d4 ("typec: tcpm: Add core support for sink side PPS") Cc: stable@vger.kernel.org Signed-off-by: Jos Wang joswang@lenovo.com
v1 -> v2:
- modify the commit message
- patch 1/2 and patch 2/2 are placed in the same thread
-- With best wishes Dmitry
-- With best wishes Dmitry
linux-stable-mirror@lists.linaro.org
-
Dmitry Baryshkov -
Jos Wang -
joswang