| Message ID | 20231207-tps6598x_update-v2-0-f3cfcde6d890@wolfvision.net (mailing list archive) |
|---|---|
| Headers | show |
| Series | usb: typec: tipd: add patch update support for tps6598x | expand |
Hi Javier, Greg, On Dec 14, 2023 at 17:29:08 +0100, Javier Carrasco wrote: > This series extends the patch update mechanism to support the tps6598x. > > Currently there is only support for the tps25750 part and some > conditional clauses are used to make a special case out of it. Now that > different parts support patch updates, a more general approach is > proposed. > > The update mechanism differs from the one required by tps25750 and it is > explained in the commit message as a summary of the application note in > that respect. > > Note that the series makes use of the TPS_SETUP_MS introduced in > commit 6a4d4a27f986 ("usb: typec: tps6598x: add reset gpio support"), > which is currently available in usb-next / usb-testing. > > A TPS65987D has been used to test this functionality with positive > results. > > Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net> > --- > Changes in v2: > - Remove probe defeferring mechanism and expect the firmware to be > available (Heikki Krogerus). > - Link to v1: > https://lore.kernel.org/r/20231207-tps6598x_update-v1-0-dc21b5301d91@wolfvision.net > FYI, this series breaks boot for TI SK-AM62A and SK-AM62 which use TPS6598x as the USB-C PD chip. The platforms stopped booting since next-20240103 [1], and reverting this series [4] seems to fix the issue [2] Is there any change needed in the board device-tree [3] and bindings? We don't specify any firmware in the device-tree node, but seems like that is an assumption in this series. I tried reverting it (below change) but that did *not* help with the stuck boot. diff --git a/drivers/usb/typec/tipd/core.c b/drivers/usb/typec/tipd/core.c index a956eb976906..fa3bd7349265 100644 --- a/drivers/usb/typec/tipd/core.c +++ b/drivers/usb/typec/tipd/core.c @@ -1139,7 +1139,7 @@ static int tps6598x_apply_patch(struct tps6598x *tps) ret = device_property_read_string(tps->dev, "firmware-name", &firmware_name); if (ret) - return ret; + return 0; ret = tps_request_firmware(tps, &fw); if (ret) [1] https://linux.kernelci.org/soc/ti/job/next/kernel/next-20240103/plan/baseline-nfs/ [2] https://gist.github.com/jailuthra/0c077176585e4df2f8b78f7784087865 [3] https://gitlab.com/linux-kernel/linux-next/-/blob/master/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts#L305 [4] https://github.com/jailuthra/linux/commits/next-20240103-tps6598-fix/ > --- > Javier Carrasco (4): > usb: typec: tipd: add init and reset functions to tipd_data > usb: typec: tipd: add function to request firmware > usb: typec: tipd: declare in_data in as const in exec_cmd functions > usb: typec: tipd: add patch update support for tps6598x > > drivers/usb/typec/tipd/core.c | 150 ++++++++++++++++++++++++++++++++------ > drivers/usb/typec/tipd/tps6598x.h | 18 +++++ > 2 files changed, 147 insertions(+), 21 deletions(-) > --- > base-commit: 51920207674e9e3475a91d2091583889792df99a > change-id: 20231207-tps6598x_update-632eab69d2ed > > Best regards, > -- > Javier Carrasco <javier.carrasco@wolfvision.net> > >
Hi Javier, On Jan 04, 2024 at 19:50:05 +0530, Jai Luthra wrote: > Hi Javier, Greg, > > On Dec 14, 2023 at 17:29:08 +0100, Javier Carrasco wrote: > > This series extends the patch update mechanism to support the tps6598x. > > > > Currently there is only support for the tps25750 part and some > > conditional clauses are used to make a special case out of it. Now that > > different parts support patch updates, a more general approach is > > proposed. > > > > The update mechanism differs from the one required by tps25750 and it is > > explained in the commit message as a summary of the application note in > > that respect. > > > > Note that the series makes use of the TPS_SETUP_MS introduced in > > commit 6a4d4a27f986 ("usb: typec: tps6598x: add reset gpio support"), > > which is currently available in usb-next / usb-testing. > > > > A TPS65987D has been used to test this functionality with positive > > results. > > > > Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net> > > --- > > Changes in v2: > > - Remove probe defeferring mechanism and expect the firmware to be > > available (Heikki Krogerus). > > - Link to v1: > > https://lore.kernel.org/r/20231207-tps6598x_update-v1-0-dc21b5301d91@wolfvision.net > > > > FYI, this series breaks boot for TI SK-AM62A and SK-AM62 which use > TPS6598x as the USB-C PD chip. > > The platforms stopped booting since next-20240103 [1], and reverting > this series [4] seems to fix the issue [2] > > Is there any change needed in the board device-tree [3] and bindings? > > We don't specify any firmware in the device-tree node, but seems like > that is an assumption in this series. I tried reverting it (below > change) but that did *not* help with the stuck boot. > > diff --git a/drivers/usb/typec/tipd/core.c b/drivers/usb/typec/tipd/core.c > index a956eb976906..fa3bd7349265 100644 > --- a/drivers/usb/typec/tipd/core.c > +++ b/drivers/usb/typec/tipd/core.c > @@ -1139,7 +1139,7 @@ static int tps6598x_apply_patch(struct tps6598x *tps) > ret = device_property_read_string(tps->dev, "firmware-name", > &firmware_name); > if (ret) > - return ret; > + return 0; > > ret = tps_request_firmware(tps, &fw); > if (ret) > > > [1] https://linux.kernelci.org/soc/ti/job/next/kernel/next-20240103/plan/baseline-nfs/ > [2] https://gist.github.com/jailuthra/0c077176585e4df2f8b78f7784087865 > [3] https://gitlab.com/linux-kernel/linux-next/-/blob/master/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts#L305 > [4] https://github.com/jailuthra/linux/commits/next-20240103-tps6598-fix/ The following change seems to fix boot on SK-AM62A without reverting this whole series: ------------------ diff --git a/drivers/usb/typec/tipd/core.c b/drivers/usb/typec/tipd/core.c index a956eb976906a5..8ba2aa05db519b 100644 --- a/drivers/usb/typec/tipd/core.c +++ b/drivers/usb/typec/tipd/core.c @@ -1223,11 +1223,16 @@ static int cd321x_reset(struct tps6598x *tps) return 0; } -static int tps6598x_reset(struct tps6598x *tps) +static int tps25750_reset(struct tps6598x *tps) { return tps6598x_exec_cmd_tmo(tps, "GAID", 0, NULL, 0, NULL, 2000, 0); } +static int tps6598x_reset(struct tps6598x *tps) +{ + return 0; +} + static int tps25750_register_port(struct tps6598x *tps, struct fwnode_handle *fwnode) { @@ -1545,7 +1550,7 @@ static const struct tipd_data tps25750_data = { .trace_status = trace_tps25750_status, .apply_patch = tps25750_apply_patch, .init = tps25750_init, - .reset = tps6598x_reset, + .reset = tps25750_reset, }; static const struct of_device_id tps6598x_of_match[] = { ------------------ I am not an expert on this, will let you/others decide on what should be the correct way to reset TPS6598x for patching without breaking this SK.
On 04/01/2024 17:47, Jai Luthra wrote: > Hi Javier, > > On Jan 04, 2024 at 19:50:05 +0530, Jai Luthra wrote: >> Hi Javier, Greg, >> >> On Dec 14, 2023 at 17:29:08 +0100, Javier Carrasco wrote: >>> This series extends the patch update mechanism to support the tps6598x. >>> >>> Currently there is only support for the tps25750 part and some >>> conditional clauses are used to make a special case out of it. Now that >>> different parts support patch updates, a more general approach is >>> proposed. >>> >>> The update mechanism differs from the one required by tps25750 and it is >>> explained in the commit message as a summary of the application note in >>> that respect. >>> >>> Note that the series makes use of the TPS_SETUP_MS introduced in >>> commit 6a4d4a27f986 ("usb: typec: tps6598x: add reset gpio support"), >>> which is currently available in usb-next / usb-testing. >>> >>> A TPS65987D has been used to test this functionality with positive >>> results. >>> >>> Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net> >>> --- >>> Changes in v2: >>> - Remove probe defeferring mechanism and expect the firmware to be >>> available (Heikki Krogerus). >>> - Link to v1: >>> https://lore.kernel.org/r/20231207-tps6598x_update-v1-0-dc21b5301d91@wolfvision.net >>> >> >> FYI, this series breaks boot for TI SK-AM62A and SK-AM62 which use >> TPS6598x as the USB-C PD chip. >> >> The platforms stopped booting since next-20240103 [1], and reverting >> this series [4] seems to fix the issue [2] >> >> Is there any change needed in the board device-tree [3] and bindings? >> >> We don't specify any firmware in the device-tree node, but seems like >> that is an assumption in this series. I tried reverting it (below >> change) but that did *not* help with the stuck boot. >> >> diff --git a/drivers/usb/typec/tipd/core.c b/drivers/usb/typec/tipd/core.c >> index a956eb976906..fa3bd7349265 100644 >> --- a/drivers/usb/typec/tipd/core.c >> +++ b/drivers/usb/typec/tipd/core.c >> @@ -1139,7 +1139,7 @@ static int tps6598x_apply_patch(struct tps6598x *tps) >> ret = device_property_read_string(tps->dev, "firmware-name", >> &firmware_name); >> if (ret) >> - return ret; >> + return 0; >> >> ret = tps_request_firmware(tps, &fw); >> if (ret) >> >> >> [1] https://linux.kernelci.org/soc/ti/job/next/kernel/next-20240103/plan/baseline-nfs/ >> [2] https://gist.github.com/jailuthra/0c077176585e4df2f8b78f7784087865 >> [3] https://gitlab.com/linux-kernel/linux-next/-/blob/master/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts#L305 >> [4] https://github.com/jailuthra/linux/commits/next-20240103-tps6598-fix/ > > The following change seems to fix boot on SK-AM62A without reverting > this whole series: > > ------------------ > > diff --git a/drivers/usb/typec/tipd/core.c b/drivers/usb/typec/tipd/core.c > index a956eb976906a5..8ba2aa05db519b 100644 > --- a/drivers/usb/typec/tipd/core.c > +++ b/drivers/usb/typec/tipd/core.c > @@ -1223,11 +1223,16 @@ static int cd321x_reset(struct tps6598x *tps) > return 0; > } > > -static int tps6598x_reset(struct tps6598x *tps) > +static int tps25750_reset(struct tps6598x *tps) > { > return tps6598x_exec_cmd_tmo(tps, "GAID", 0, NULL, 0, NULL, 2000, 0); > } > > +static int tps6598x_reset(struct tps6598x *tps) > +{ > + return 0; > +} > + > static int > tps25750_register_port(struct tps6598x *tps, struct fwnode_handle *fwnode) > { > @@ -1545,7 +1550,7 @@ static const struct tipd_data tps25750_data = { > .trace_status = trace_tps25750_status, > .apply_patch = tps25750_apply_patch, > .init = tps25750_init, > - .reset = tps6598x_reset, > + .reset = tps25750_reset, > }; > > static const struct of_device_id tps6598x_of_match[] = { > > ------------------ > > I am not an expert on this, will let you/others decide on what should be > the correct way to reset TPS6598x for patching without breaking this SK. > > This looks like a correct fix to me. Could you please send a proper PATCH with Fixes tag? Thanks!
Hi Jai Luthra, On 04.01.24 16:47, Jai Luthra wrote>> FYI, this series breaks boot for TI SK-AM62A and SK-AM62 which use >> TPS6598x as the USB-C PD chip. >> >> The platforms stopped booting since next-20240103 [1], and reverting >> this series [4] seems to fix the issue [2] >> >> Is there any change needed in the board device-tree [3] and bindings? >> >> We don't specify any firmware in the device-tree node, but seems like >> that is an assumption in this series. I tried reverting it (below >> change) but that did *not* help with the stuck boot. >>Thanks a lot for your high-quality feedback. I am glad to see that you even found a solution to the issue. The firmware update only happens if the device is in patch mode ('PTCH' in the Mode register - 0x03), which is the expected behavior because the device waits in that mode until a patch arrives. That is probably the reason why your first attempt did not work (no update was triggered). The problem seems to be related to the reset function, as you already noticed. That function is only called in suspend/resume, if the probe fails and in the remove function. Did the probe function fail and if so, could you see why? The reset function is identical for the tps25750 and tps6598x ('GAID' with no parameters), so I wonder why that should be the source of the problem. > The following change seems to fix boot on SK-AM62A without reverting > this whole series: > > ------------------ > > diff --git a/drivers/usb/typec/tipd/core.c b/drivers/usb/typec/tipd/core.c > index a956eb976906a5..8ba2aa05db519b 100644 > --- a/drivers/usb/typec/tipd/core.c > +++ b/drivers/usb/typec/tipd/core.c > @@ -1223,11 +1223,16 @@ static int cd321x_reset(struct tps6598x *tps) > return 0; > } > > -static int tps6598x_reset(struct tps6598x *tps) > +static int tps25750_reset(struct tps6598x *tps) > { > return tps6598x_exec_cmd_tmo(tps, "GAID", 0, NULL, 0, NULL, 2000, 0); > } > > +static int tps6598x_reset(struct tps6598x *tps) > +{ > + return 0; > +} > + > static int > tps25750_register_port(struct tps6598x *tps, struct fwnode_handle *fwnode) > { > @@ -1545,7 +1550,7 @@ static const struct tipd_data tps25750_data = { > .trace_status = trace_tps25750_status, > .apply_patch = tps25750_apply_patch, > .init = tps25750_init, > - .reset = tps6598x_reset, > + .reset = tps25750_reset, > }; > > static const struct of_device_id tps6598x_of_match[] = { > > ------------------ > > I am not an expert on this, will let you/others decide on what should be > the correct way to reset TPS6598x for patching without breaking this SK. > > The driver did not support cold resets before, but that does not mean that they should not happen like it does for the tps25750. Your fix just removes the reset function for the tps6598x, and I would like to know why the reset happened in the fist place. Thanks and best regards, Javier Carrasco
On 04.01.24 17:15, Roger Quadros wrote: > > > On 04/01/2024 17:47, Jai Luthra wrote: >> Hi Javier, >> The following change seems to fix boot on SK-AM62A without reverting >> this whole series: >> >> ------------------ >> >> diff --git a/drivers/usb/typec/tipd/core.c b/drivers/usb/typec/tipd/core.c >> index a956eb976906a5..8ba2aa05db519b 100644 >> --- a/drivers/usb/typec/tipd/core.c >> +++ b/drivers/usb/typec/tipd/core.c >> @@ -1223,11 +1223,16 @@ static int cd321x_reset(struct tps6598x *tps) >> return 0; >> } >> >> -static int tps6598x_reset(struct tps6598x *tps) >> +static int tps25750_reset(struct tps6598x *tps) >> { >> return tps6598x_exec_cmd_tmo(tps, "GAID", 0, NULL, 0, NULL, 2000, 0); >> } >> >> +static int tps6598x_reset(struct tps6598x *tps) >> +{ >> + return 0; >> +} >> + >> static int >> tps25750_register_port(struct tps6598x *tps, struct fwnode_handle *fwnode) >> { >> @@ -1545,7 +1550,7 @@ static const struct tipd_data tps25750_data = { >> .trace_status = trace_tps25750_status, >> .apply_patch = tps25750_apply_patch, >> .init = tps25750_init, >> - .reset = tps6598x_reset, >> + .reset = tps25750_reset, >> }; >> >> static const struct of_device_id tps6598x_of_match[] = { >> >> ------------------ >> >> I am not an expert on this, will let you/others decide on what should be >> the correct way to reset TPS6598x for patching without breaking this SK. >> >> > > This looks like a correct fix to me. > Could you please send a proper PATCH with Fixes tag? Thanks! > Hi Roger, that fix only removes the reset function and does nothing instead, but the reset call is identical for both devices (hence why there was a single function for both devices). As I mentioned in my reply to Jai Luthra, I would like to know why the reset is triggered and why that should not happen. Thanks and best regards, Javier Carrasco
On 04/01/2024 18:36, Javier Carrasco wrote: > On 04.01.24 17:15, Roger Quadros wrote: >> >> >> On 04/01/2024 17:47, Jai Luthra wrote: >>> Hi Javier, >>> The following change seems to fix boot on SK-AM62A without reverting >>> this whole series: >>> >>> ------------------ >>> >>> diff --git a/drivers/usb/typec/tipd/core.c b/drivers/usb/typec/tipd/core.c >>> index a956eb976906a5..8ba2aa05db519b 100644 >>> --- a/drivers/usb/typec/tipd/core.c >>> +++ b/drivers/usb/typec/tipd/core.c >>> @@ -1223,11 +1223,16 @@ static int cd321x_reset(struct tps6598x *tps) >>> return 0; >>> } >>> >>> -static int tps6598x_reset(struct tps6598x *tps) >>> +static int tps25750_reset(struct tps6598x *tps) >>> { >>> return tps6598x_exec_cmd_tmo(tps, "GAID", 0, NULL, 0, NULL, 2000, 0); >>> } >>> >>> +static int tps6598x_reset(struct tps6598x *tps) >>> +{ >>> + return 0; >>> +} >>> + >>> static int >>> tps25750_register_port(struct tps6598x *tps, struct fwnode_handle *fwnode) >>> { >>> @@ -1545,7 +1550,7 @@ static const struct tipd_data tps25750_data = { >>> .trace_status = trace_tps25750_status, >>> .apply_patch = tps25750_apply_patch, >>> .init = tps25750_init, >>> - .reset = tps6598x_reset, >>> + .reset = tps25750_reset, >>> }; >>> >>> static const struct of_device_id tps6598x_of_match[] = { >>> >>> ------------------ >>> >>> I am not an expert on this, will let you/others decide on what should be >>> the correct way to reset TPS6598x for patching without breaking this SK. >>> >>> >> >> This looks like a correct fix to me. >> Could you please send a proper PATCH with Fixes tag? Thanks! >> > Hi Roger, > > that fix only removes the reset function and does nothing instead, but > the reset call is identical for both devices (hence why there was a > single function for both devices). As I mentioned in my reply to Jai This is incorrect. Look at the original code, the GAID command is issued only if it is a tps25750 device. Below is your part of the code that replaces it with reset() ops. > @@ -1340,8 +1360,8 @@ static int tps6598x_probe(struct i2c_client *client) > tps6598x_write64(tps, TPS_REG_INT_MASK1, 0); > err_reset_controller: > /* Reset PD controller to remove any applied patch */ > - if (is_tps25750) > - tps6598x_exec_cmd_tmo(tps, "GAID", 0, NULL, 0, NULL, 2000, 0); > + tps->data->reset(tps); > + > return ret; > } which means the GAID command will be executed for both tps25750 and tps6598x as you have a single reset function for both. This is a problem for boards using the tps6598x.
On 04.01.24 18:08, Roger Quadros wrote: > > > On 04/01/2024 18:36, Javier Carrasco wrote: >> Hi Roger, >> >> that fix only removes the reset function and does nothing instead, but >> the reset call is identical for both devices (hence why there was a >> single function for both devices). As I mentioned in my reply to Jai > > This is incorrect. > > Look at the original code, the GAID command is issued only if it is a > tps25750 device. > > Below is your part of the code that replaces it with reset() ops. > >> @@ -1340,8 +1360,8 @@ static int tps6598x_probe(struct i2c_client *client) >> tps6598x_write64(tps, TPS_REG_INT_MASK1, 0); >> err_reset_controller: >> /* Reset PD controller to remove any applied patch */ >> - if (is_tps25750) >> - tps6598x_exec_cmd_tmo(tps, "GAID", 0, NULL, 0, NULL, 2000, 0); >> + tps->data->reset(tps); >> + >> return ret; >> } > > which means the GAID command will be executed for both tps25750 and tps6598x > as you have a single reset function for both. > This is a problem for boards using the tps6598x. > I have to admit that the GAID for the tps6598x should have been added separately, and not right away with the function pointers. I added extra functionality that was not expected. On the other hand, the GAID command is supported by the tps6598x as well (Technical Reference Manual, page 113). Hence why I was surprised that using the same command for the tps6598x is a problem.
Hi all, On Jan 04, 2024 at 18:15:36 +0200, Roger Quadros wrote: > > > On 04/01/2024 17:47, Jai Luthra wrote: > > Hi Javier, > > > > On Jan 04, 2024 at 19:50:05 +0530, Jai Luthra wrote: > >> Hi Javier, Greg, > >> > >> On Dec 14, 2023 at 17:29:08 +0100, Javier Carrasco wrote: > >>> This series extends the patch update mechanism to support the tps6598x. > >>> > >>> Currently there is only support for the tps25750 part and some > >>> conditional clauses are used to make a special case out of it. Now that > >>> different parts support patch updates, a more general approach is > >>> proposed. > >>> > >>> The update mechanism differs from the one required by tps25750 and it is > >>> explained in the commit message as a summary of the application note in > >>> that respect. > >>> > >>> Note that the series makes use of the TPS_SETUP_MS introduced in > >>> commit 6a4d4a27f986 ("usb: typec: tps6598x: add reset gpio support"), > >>> which is currently available in usb-next / usb-testing. > >>> > >>> A TPS65987D has been used to test this functionality with positive > >>> results. > >>> > >>> Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net> > >>> --- > >>> Changes in v2: > >>> - Remove probe defeferring mechanism and expect the firmware to be > >>> available (Heikki Krogerus). > >>> - Link to v1: > >>> https://lore.kernel.org/r/20231207-tps6598x_update-v1-0-dc21b5301d91@wolfvision.net > >>> > >> > >> FYI, this series breaks boot for TI SK-AM62A and SK-AM62 which use > >> TPS6598x as the USB-C PD chip. This series also broke boot on TI SK-AM62x [0]. > >> > >> The platforms stopped booting since next-20240103 [1], and reverting > >> this series [4] seems to fix the issue [2] > >> > >> Is there any change needed in the board device-tree [3] and bindings? > >> > >> We don't specify any firmware in the device-tree node, but seems like > >> that is an assumption in this series. I tried reverting it (below > >> change) but that did *not* help with the stuck boot. > >> > >> diff --git a/drivers/usb/typec/tipd/core.c b/drivers/usb/typec/tipd/core.c > >> index a956eb976906..fa3bd7349265 100644 > >> --- a/drivers/usb/typec/tipd/core.c > >> +++ b/drivers/usb/typec/tipd/core.c > >> @@ -1139,7 +1139,7 @@ static int tps6598x_apply_patch(struct tps6598x *tps) > >> ret = device_property_read_string(tps->dev, "firmware-name", > >> &firmware_name); > >> if (ret) > >> - return ret; > >> + return 0; > >> > >> ret = tps_request_firmware(tps, &fw); > >> if (ret) > >> > >> > >> [1] https://linux.kernelci.org/soc/ti/job/next/kernel/next-20240103/plan/baseline-nfs/ > >> [2] https://gist.github.com/jailuthra/0c077176585e4df2f8b78f7784087865 > >> [3] https://gitlab.com/linux-kernel/linux-next/-/blob/master/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts#L305 > >> [4] https://github.com/jailuthra/linux/commits/next-20240103-tps6598-fix/ > > > > The following change seems to fix boot on SK-AM62A without reverting > > this whole series: > > > > ------------------ > > > > diff --git a/drivers/usb/typec/tipd/core.c b/drivers/usb/typec/tipd/core.c > > index a956eb976906a5..8ba2aa05db519b 100644 > > --- a/drivers/usb/typec/tipd/core.c > > +++ b/drivers/usb/typec/tipd/core.c > > @@ -1223,11 +1223,16 @@ static int cd321x_reset(struct tps6598x *tps) > > return 0; > > } > > > > -static int tps6598x_reset(struct tps6598x *tps) > > +static int tps25750_reset(struct tps6598x *tps) > > { > > return tps6598x_exec_cmd_tmo(tps, "GAID", 0, NULL, 0, NULL, 2000, 0); > > } > > > > +static int tps6598x_reset(struct tps6598x *tps) > > +{ > > + return 0; > > +} > > + > > static int > > tps25750_register_port(struct tps6598x *tps, struct fwnode_handle *fwnode) > > { > > @@ -1545,7 +1550,7 @@ static const struct tipd_data tps25750_data = { > > .trace_status = trace_tps25750_status, > > .apply_patch = tps25750_apply_patch, > > .init = tps25750_init, > > - .reset = tps6598x_reset, > > + .reset = tps25750_reset, > > }; > > > > static const struct of_device_id tps6598x_of_match[] = { > > > > ------------------ > > > > I am not an expert on this, will let you/others decide on what should be > > the correct way to reset TPS6598x for patching without breaking this SK. > > > > > > This looks like a correct fix to me. > Could you please send a proper PATCH with Fixes tag? Thanks! Thanks for reviewing this Roger, the same patch above worked for me to fix SK-AM62x as well [1]. [0] https://storage.kernelci.org/next/master/next-20240103/arm64/defconfig/gcc-10/lab-ti/baseline-nfs-am62xx_sk-fs.txt [1] https://gist.github.com/DhruvaG2000/326b5d7fab4be95f20cd0aac4125f577
On 04.01.24 19:52, Dhruva Gole wrote: > > This series also broke boot on TI SK-AM62x [0]. > >> >> This looks like a correct fix to me. >> Could you please send a proper PATCH with Fixes tag? Thanks! > > Thanks for reviewing this Roger, the same patch above worked for me to > fix SK-AM62x as well [1]. > > [0] https://storage.kernelci.org/next/master/next-20240103/arm64/defconfig/gcc-10/lab-ti/baseline-nfs-am62xx_sk-fs.txt > [1] https://gist.github.com/DhruvaG2000/326b5d7fab4be95f20cd0aac4125f577 > Hi Dhruva, I am glad that you guys found a fix that quickly. it seems that you guys work for the device manufacturer (because of your email addresses), so I was wondering if you could explain (or provide the documentation) why the tps6598x should not receive the GAID command and a reset crashes the system. Everything looks exactly the same as for the tps25750, but in that case there are no complaints from sending a cold reset. Thanks again and best regards, Javier Carrasco
On 04/01/2024 22:15, Javier Carrasco wrote: > On 04.01.24 19:52, Dhruva Gole wrote: > >> >> This series also broke boot on TI SK-AM62x [0]. >> > >>> >>> This looks like a correct fix to me. >>> Could you please send a proper PATCH with Fixes tag? Thanks! >> >> Thanks for reviewing this Roger, the same patch above worked for me to >> fix SK-AM62x as well [1]. >> >> [0] https://storage.kernelci.org/next/master/next-20240103/arm64/defconfig/gcc-10/lab-ti/baseline-nfs-am62xx_sk-fs.txt >> [1] https://gist.github.com/DhruvaG2000/326b5d7fab4be95f20cd0aac4125f577 >> > Hi Dhruva, > > I am glad that you guys found a fix that quickly. > > it seems that you guys work for the device manufacturer (because of your > email addresses), so I was wondering if you could explain (or provide > the documentation) why the tps6598x should not receive the GAID command > and a reset crashes the system. Everything looks exactly the same as for > the tps25750, but in that case there are no complaints from sending a > cold reset. Looking at the kernel logs I don't see any crashes. Looks like the baseline-nfs.login test failed due to some reason [2]. I cannot see why though. [1] https://linux.kernelci.org/soc/ti/job/next/kernel/next-20240103/plan/baseline-nfs/ [2] https://linux.kernelci.org/test/plan/id/659561d445debed180c795fc/
On Jan 04, 2024 at 17:25:27 +0100, Javier Carrasco wrote: > Hi Jai Luthra, > On 04.01.24 16:47, Jai Luthra wrote>> FYI, this series breaks boot for > TI SK-AM62A and SK-AM62 which use > >> TPS6598x as the USB-C PD chip. > >> > >> The platforms stopped booting since next-20240103 [1], and reverting > >> this series [4] seems to fix the issue [2] > >> > >> Is there any change needed in the board device-tree [3] and bindings? > >> > >> We don't specify any firmware in the device-tree node, but seems like > >> that is an assumption in this series. I tried reverting it (below > >> change) but that did *not* help with the stuck boot. > >>Thanks a lot for your high-quality feedback. I am glad to see that you > even found a solution to the issue. > > The firmware update only happens if the device is in patch mode ('PTCH' > in the Mode register - 0x03), which is the expected behavior because the > device waits in that mode until a patch arrives. That is probably the > reason why your first attempt did not work (no update was triggered). Understood. Btw your mail client seems to mess up quotes/spacing above. > > The problem seems to be related to the reset function, as you already > noticed. That function is only called in suspend/resume, if the probe > fails and in the remove function. > > Did the probe function fail and if so, could you see why? The reset > function is identical for the tps25750 and tps6598x ('GAID' with no > parameters), so I wonder why that should be the source of the problem. I added some prints and can see that the probe fails once at fwnode_usb_role_switch_get() because the other endpoint (of USB device) is not yet probed. It then re-probes later where it passes. The GAID reset being done unconditionally in your series seems to cause the board to get stuck in the boot process when it hits the above error due to probe-order between USB subsystem and this IC. My guess would be SoC stops getting power because we reset the PD chip? Anyway, I will send below change as a separate "Fixes:" patch for now, to keep how things as they were before your series. If you have a better architecture in mind that can reset only when PTCH has been applied and not for other probe defers, feel free to send it on top of it. > > The following change seems to fix boot on SK-AM62A without reverting > > this whole series: > > > > ------------------ > > > > diff --git a/drivers/usb/typec/tipd/core.c b/drivers/usb/typec/tipd/core.c > > index a956eb976906a5..8ba2aa05db519b 100644 > > --- a/drivers/usb/typec/tipd/core.c > > +++ b/drivers/usb/typec/tipd/core.c > > @@ -1223,11 +1223,16 @@ static int cd321x_reset(struct tps6598x *tps) > > return 0; > > } > > > > -static int tps6598x_reset(struct tps6598x *tps) > > +static int tps25750_reset(struct tps6598x *tps) > > { > > return tps6598x_exec_cmd_tmo(tps, "GAID", 0, NULL, 0, NULL, 2000, 0); > > } > > > > +static int tps6598x_reset(struct tps6598x *tps) > > +{ > > + return 0; > > +} > > + > > static int > > tps25750_register_port(struct tps6598x *tps, struct fwnode_handle *fwnode) > > { > > @@ -1545,7 +1550,7 @@ static const struct tipd_data tps25750_data = { > > .trace_status = trace_tps25750_status, > > .apply_patch = tps25750_apply_patch, > > .init = tps25750_init, > > - .reset = tps6598x_reset, > > + .reset = tps25750_reset, > > }; > > > > static const struct of_device_id tps6598x_of_match[] = { > > > > ------------------ > > > > I am not an expert on this, will let you/others decide on what should be > > the correct way to reset TPS6598x for patching without breaking this SK. > > > > > > The driver did not support cold resets before, but that does not mean > that they should not happen like it does for the tps25750. Your fix just > removes the reset function for the tps6598x, and I would like to know > why the reset happened in the fist place. > > Thanks and best regards, > Javier Carrasco
On 05.01.24 09:12, Jai Luthra wrote: > I added some prints and can see that the probe fails once at > fwnode_usb_role_switch_get() because the other endpoint (of USB device) > is not yet probed. It then re-probes later where it passes. > > The GAID reset being done unconditionally in your series seems to cause > the board to get stuck in the boot process when it hits the above error > due to probe-order between USB subsystem and this IC. My guess would be > SoC stops getting power because we reset the PD chip? > > Anyway, I will send below change as a separate "Fixes:" patch for now, > to keep how things as they were before your series. > My biggest concern is that we are sending GAID for the tps25750 under the same circumstances. Could we not have the same problem with that device? We would be resetting the PD controller and the SoC would stop getting power as well, right? Or is there anything device-specific that would avoid that? > If you have a better architecture in mind that can reset only when PTCH > has been applied and not for other probe defers, feel free to send it on > top of it. > I added the cold reset to have the same behavior upon probe failures for both devices, given that they use the same command. But if that can cause problems, let's leave the reset alone... Best regards, Javier Carrasco
Hi Javier, Abdel, On Jan 05, 2024 at 10:49:22 +0100, Javier Carrasco wrote: > On 05.01.24 09:12, Jai Luthra wrote: > > I added some prints and can see that the probe fails once at > > fwnode_usb_role_switch_get() because the other endpoint (of USB device) > > is not yet probed. It then re-probes later where it passes. > > > > The GAID reset being done unconditionally in your series seems to cause > > the board to get stuck in the boot process when it hits the above error > > due to probe-order between USB subsystem and this IC. My guess would be > > SoC stops getting power because we reset the PD chip? > > > > Anyway, I will send below change as a separate "Fixes:" patch for now, > > to keep how things as they were before your series. > > > > My biggest concern is that we are sending GAID for the tps25750 under > the same circumstances. Could we not have the same problem with that > device? We would be resetting the PD controller and the SoC would stop > getting power as well, right? Or is there anything device-specific that > would avoid that? > Yes I would guess same problem can happen depending on probe order of the remote-endpoint node, but I don't see any upstream platform using ti,tps25750 compatible, so I have no way to confirm. Maybe Abdel can comment on how it works, as he added the GAID reset for tps25750. > > If you have a better architecture in mind that can reset only when PTCH > > has been applied and not for other probe defers, feel free to send it on > > top of it. > > > > I added the cold reset to have the same behavior upon probe failures for > both devices, given that they use the same command. But if that can > cause problems, let's leave the reset alone... > > Best regards, > Javier Carrasco
On Fri, Jan 05, 2024 at 03:40:54PM +0530, Jai Luthra wrote: Hi Jai and Jvaier, > > My biggest concern is that we are sending GAID for the tps25750 under > > the same circumstances. Could we not have the same problem with that > > device? We would be resetting the PD controller and the SoC would stop > > getting power as well, right? Or is there anything device-specific that > > would avoid that? > > > > Yes I would guess same problem can happen depending on probe order of > the remote-endpoint node, but I don't see any upstream platform using > ti,tps25750 compatible, so I have no way to confirm. > > Maybe Abdel can comment on how it works, as he added the GAID reset for > tps25750. > Ops, that's an oversight from my side. In our case, fwnode_usb_role_switch_get() returns NULL but if it does return -EPROBE_DEFER, we will end up with the same issue you're seeing. The purpose of the reset is to remove any applied patch so we don't leave USB-C PD controller in some kind of operable state when the device fails to be probed. GO2P command forces PD controller to retrun to PTCH mode but unfortunately that doesn't work in all cases unless ADCINx pins configurations are set in "NegotiateHighVoltage" option, so I opted into using the hard reset instead regardless of ADCINx configurations. > > > If you have a better architecture in mind that can reset only when PTCH > > > has been applied and not for other probe defers, feel free to send it on > > > top of it. > > > > > > > I added the cold reset to have the same behavior upon probe failures for > > both devices, given that they use the same command. But if that can > > cause problems, let's leave the reset alone... > > I think in this case, we might want to apply the patch as the last thing in the probe or check for EPROBE_DEFER before issuing a hard reset. Also, I think if the patch is being applied using EEPROM, I don't believe we need to issue a hard reset ever as the patch would be applied automatically after that. Thanks, Abdel
This series extends the patch update mechanism to support the tps6598x. Currently there is only support for the tps25750 part and some conditional clauses are used to make a special case out of it. Now that different parts support patch updates, a more general approach is proposed. The update mechanism differs from the one required by tps25750 and it is explained in the commit message as a summary of the application note in that respect. Note that the series makes use of the TPS_SETUP_MS introduced in commit 6a4d4a27f986 ("usb: typec: tps6598x: add reset gpio support"), which is currently available in usb-next / usb-testing. A TPS65987D has been used to test this functionality with positive results. Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net> --- Changes in v2: - Remove probe defeferring mechanism and expect the firmware to be available (Heikki Krogerus). - Link to v1: https://lore.kernel.org/r/20231207-tps6598x_update-v1-0-dc21b5301d91@wolfvision.net --- Javier Carrasco (4): usb: typec: tipd: add init and reset functions to tipd_data usb: typec: tipd: add function to request firmware usb: typec: tipd: declare in_data in as const in exec_cmd functions usb: typec: tipd: add patch update support for tps6598x drivers/usb/typec/tipd/core.c | 150 ++++++++++++++++++++++++++++++++------ drivers/usb/typec/tipd/tps6598x.h | 18 +++++ 2 files changed, 147 insertions(+), 21 deletions(-) --- base-commit: 51920207674e9e3475a91d2091583889792df99a change-id: 20231207-tps6598x_update-632eab69d2ed Best regards,