mbox series

[v2,0/4] usb: typec: tipd: add patch update support for tps6598x

Message ID 20231207-tps6598x_update-v2-0-f3cfcde6d890@wolfvision.net
Headers show
Series usb: typec: tipd: add patch update support for tps6598x | expand

Message

Javier Carrasco Dec. 14, 2023, 4:29 p.m. UTC
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,

Comments

Jai Luthra Jan. 4, 2024, 2:20 p.m. UTC | #1
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>
> 
>
Jai Luthra Jan. 4, 2024, 3:47 p.m. UTC | #2
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.
Roger Quadros Jan. 4, 2024, 4:15 p.m. UTC | #3
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!
Javier Carrasco Jan. 4, 2024, 4:25 p.m. UTC | #4
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
Javier Carrasco Jan. 4, 2024, 4:36 p.m. UTC | #5
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
Roger Quadros Jan. 4, 2024, 5:08 p.m. UTC | #6
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.
Javier Carrasco Jan. 4, 2024, 5:15 p.m. UTC | #7
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.
Dhruva Gole Jan. 4, 2024, 6:52 p.m. UTC | #8
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
Javier Carrasco Jan. 4, 2024, 8:15 p.m. UTC | #9
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
Roger Quadros Jan. 5, 2024, 7:57 a.m. UTC | #10
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/
Jai Luthra Jan. 5, 2024, 8:12 a.m. UTC | #11
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
Javier Carrasco Jan. 5, 2024, 9:49 a.m. UTC | #12
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
Jai Luthra Jan. 5, 2024, 10:10 a.m. UTC | #13
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
Abdel Alkuor Jan. 5, 2024, 4:40 p.m. UTC | #14
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