| Message ID | 20210805140231.268273-1-thomas.perrot@bootlin.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
| Series | bus: mhi: pci_generic: increase timeout value for operations to 24000ms | expand |
On Thu, 5 Aug 2021 at 16:04, Thomas Perrot <thomas.perrot@bootlin.com> wrote: > > Otherwise, the waiting time was too short to use a Sierra Wireless EM919X > connected to an i.MX6 through the PCIe bus. > > Signed-off-by: Thomas Perrot <thomas.perrot@bootlin.com> Reviewed-by: Loic Poulain <loic.poulain@linaro.org>
On Thu, Aug 05, 2021 at 04:02:31PM +0200, Thomas Perrot wrote: > Otherwise, the waiting time was too short to use a Sierra Wireless EM919X > connected to an i.MX6 through the PCIe bus. > > Signed-off-by: Thomas Perrot <thomas.perrot@bootlin.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Thanks, Mani > --- > drivers/bus/mhi/pci_generic.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/bus/mhi/pci_generic.c b/drivers/bus/mhi/pci_generic.c > index 4dd1077354af..e08ed6e5031b 100644 > --- a/drivers/bus/mhi/pci_generic.c > +++ b/drivers/bus/mhi/pci_generic.c > @@ -248,7 +248,7 @@ static struct mhi_event_config modem_qcom_v1_mhi_events[] = { > > static const struct mhi_controller_config modem_qcom_v1_mhiv_config = { > .max_channels = 128, > - .timeout_ms = 8000, > + .timeout_ms = 24000, > .num_channels = ARRAY_SIZE(modem_qcom_v1_mhi_channels), > .ch_cfg = modem_qcom_v1_mhi_channels, > .num_events = ARRAY_SIZE(modem_qcom_v1_mhi_events), > -- > 2.31.1 >
Hello Manivannan, I just saw that this patch seems not yet been merged, is there a issue with it? Best regards, Thomas On Mon, 2021-08-16 at 09:52 +0530, Manivannan Sadhasivam wrote: > On Thu, Aug 05, 2021 at 04:02:31PM +0200, Thomas Perrot wrote: > > Otherwise, the waiting time was too short to use a Sierra Wireless > > EM919X > > connected to an i.MX6 through the PCIe bus. > > > > Signed-off-by: Thomas Perrot <thomas.perrot@bootlin.com> > > Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> > > Thanks, > Mani > > > --- > > drivers/bus/mhi/pci_generic.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/bus/mhi/pci_generic.c > > b/drivers/bus/mhi/pci_generic.c > > index 4dd1077354af..e08ed6e5031b 100644 > > --- a/drivers/bus/mhi/pci_generic.c > > +++ b/drivers/bus/mhi/pci_generic.c > > @@ -248,7 +248,7 @@ static struct mhi_event_config > > modem_qcom_v1_mhi_events[] = { > > > > static const struct mhi_controller_config > > modem_qcom_v1_mhiv_config = { > > .max_channels = 128, > > - .timeout_ms = 8000, > > + .timeout_ms = 24000, > > .num_channels = ARRAY_SIZE(modem_qcom_v1_mhi_channels), > > .ch_cfg = modem_qcom_v1_mhi_channels, > > .num_events = ARRAY_SIZE(modem_qcom_v1_mhi_events), > > -- > > 2.31.1 > >
Hey all, On 5/8/21 16:02, Thomas Perrot wrote: > Otherwise, the waiting time was too short to use a Sierra Wireless EM919X > connected to an i.MX6 through the PCIe bus. > > Signed-off-by: Thomas Perrot <thomas.perrot@bootlin.com> > --- > drivers/bus/mhi/pci_generic.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/bus/mhi/pci_generic.c b/drivers/bus/mhi/pci_generic.c > index 4dd1077354af..e08ed6e5031b 100644 > --- a/drivers/bus/mhi/pci_generic.c > +++ b/drivers/bus/mhi/pci_generic.c > @@ -248,7 +248,7 @@ static struct mhi_event_config modem_qcom_v1_mhi_events[] = { > > static const struct mhi_controller_config modem_qcom_v1_mhiv_config = { > .max_channels = 128, > - .timeout_ms = 8000, > + .timeout_ms = 24000, This modem_qcom_v1_mhiv_config config applies to all generic SDX24, SDX55 and SDX65 modules. Other vendor-branded SDX55 based modules in this same file (Foxconn SDX55, MV31), have 20000ms as timeout. Other vendor-branded SDX24 based modules in this same file (Quectel EM12xx), have also 20000ms as timeout. Maybe it makes sense to have a common timeout for all? Thomas, is the 24000ms value taken from experimentation, or is it a safe enough value? Maybe 20000ms as in other modules would have been enough? And if 20000ms wasn't enough but 24000ms is, how about adding that same value for all modules? These modules definitely need time to boot, not sure if having slightly different timeout values for each would make much sense, unless there are very very different values required. What do you think? > .num_channels = ARRAY_SIZE(modem_qcom_v1_mhi_channels), > .ch_cfg = modem_qcom_v1_mhi_channels, > .num_events = ARRAY_SIZE(modem_qcom_v1_mhi_events), >
Hi Thomas, On 29 September 2021 1:41:12 AM IST, Thomas Perrot <thomas.perrot@bootlin.com> wrote: >Hello Manivannan, > >I just saw that this patch seems not yet been merged, is there a issue >with it? > For the last merge window we had a conflict with netdev tree so I was not able to send the second iteration of the PR. Will apply this patch for v5.16. Thanks, Mani >Best regards, >Thomas > >On Mon, 2021-08-16 at 09:52 +0530, Manivannan Sadhasivam wrote: >> On Thu, Aug 05, 2021 at 04:02:31PM +0200, Thomas Perrot wrote: >> > Otherwise, the waiting time was too short to use a Sierra Wireless >> > EM919X >> > connected to an i.MX6 through the PCIe bus. >> > >> > Signed-off-by: Thomas Perrot <thomas.perrot@bootlin.com> >> >> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> >> >> Thanks, >> Mani >> >> > --- >> > drivers/bus/mhi/pci_generic.c | 2 +- >> > 1 file changed, 1 insertion(+), 1 deletion(-) >> > >> > diff --git a/drivers/bus/mhi/pci_generic.c >> > b/drivers/bus/mhi/pci_generic.c >> > index 4dd1077354af..e08ed6e5031b 100644 >> > --- a/drivers/bus/mhi/pci_generic.c >> > +++ b/drivers/bus/mhi/pci_generic.c >> > @@ -248,7 +248,7 @@ static struct mhi_event_config >> > modem_qcom_v1_mhi_events[] = { >> > >> > static const struct mhi_controller_config >> > modem_qcom_v1_mhiv_config = { >> > .max_channels = 128, >> > - .timeout_ms = 8000, >> > + .timeout_ms = 24000, >> > .num_channels = ARRAY_SIZE(modem_qcom_v1_mhi_channels), >> > .ch_cfg = modem_qcom_v1_mhi_channels, >> > .num_events = ARRAY_SIZE(modem_qcom_v1_mhi_events), >> > -- >> > 2.31.1 >> > >
On 29 September 2021 3:07:23 PM IST, Aleksander Morgado <aleksander@aleksander.es> wrote: >Hey all, > >On 5/8/21 16:02, Thomas Perrot wrote: >> Otherwise, the waiting time was too short to use a Sierra Wireless EM919X >> connected to an i.MX6 through the PCIe bus. >> >> Signed-off-by: Thomas Perrot <thomas.perrot@bootlin.com> >> --- >> drivers/bus/mhi/pci_generic.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/bus/mhi/pci_generic.c b/drivers/bus/mhi/pci_generic.c >> index 4dd1077354af..e08ed6e5031b 100644 >> --- a/drivers/bus/mhi/pci_generic.c >> +++ b/drivers/bus/mhi/pci_generic.c >> @@ -248,7 +248,7 @@ static struct mhi_event_config modem_qcom_v1_mhi_events[] = { >> >> static const struct mhi_controller_config modem_qcom_v1_mhiv_config = { >> .max_channels = 128, >> - .timeout_ms = 8000, >> + .timeout_ms = 24000, > > >This modem_qcom_v1_mhiv_config config applies to all generic SDX24, SDX55 and SDX65 modules. >Other vendor-branded SDX55 based modules in this same file (Foxconn SDX55, MV31), have 20000ms as timeout. >Other vendor-branded SDX24 based modules in this same file (Quectel EM12xx), have also 20000ms as timeout. >Maybe it makes sense to have a common timeout for all? > Eventhough the baseport coming from Qualcomm for the modem chipsets are same, it is possible that the vendors might have customized the firmware for their own usecase. That could be the cause of the delay for modem booting. So I don't think we should use the same timeout of 2400ms for all modems. >Thomas, is the 24000ms value taken from experimentation, or is it a safe enough value? Maybe 20000ms as in other modules would have been enough? > It was derived from testing I believe. Thanks, Mani >And if 20000ms wasn't enough but 24000ms is, how about adding that same value for all modules? These modules definitely need time to boot, not sure if having slightly different timeout values for each would make much sense, unless there are very very different values required. > >What do you think? > >> .num_channels = ARRAY_SIZE(modem_qcom_v1_mhi_channels), >> .ch_cfg = modem_qcom_v1_mhi_channels, >> .num_events = ARRAY_SIZE(modem_qcom_v1_mhi_events), >> > >
Hey Mani, > >> diff --git a/drivers/bus/mhi/pci_generic.c b/drivers/bus/mhi/pci_generic.c > >> index 4dd1077354af..e08ed6e5031b 100644 > >> --- a/drivers/bus/mhi/pci_generic.c > >> +++ b/drivers/bus/mhi/pci_generic.c > >> @@ -248,7 +248,7 @@ static struct mhi_event_config modem_qcom_v1_mhi_events[] = { > >> > >> static const struct mhi_controller_config modem_qcom_v1_mhiv_config = { > >> .max_channels = 128, > >> - .timeout_ms = 8000, > >> + .timeout_ms = 24000, > > > > > >This modem_qcom_v1_mhiv_config config applies to all generic SDX24, SDX55 and SDX65 modules. > >Other vendor-branded SDX55 based modules in this same file (Foxconn SDX55, MV31), have 20000ms as timeout. > >Other vendor-branded SDX24 based modules in this same file (Quectel EM12xx), have also 20000ms as timeout. > >Maybe it makes sense to have a common timeout for all? > > > > Eventhough the baseport coming from Qualcomm for the modem chipsets are same, it is possible that the vendors might have customized the firmware for their own usecase. That could be the cause of the delay for modem booting. > > So I don't think we should use the same timeout of 2400ms for all modems. > Please note it's 24000ms what's being suggested here, not 2400ms. > >Thomas, is the 24000ms value taken from experimentation, or is it a safe enough value? Maybe 20000ms as in other modules would have been enough? > > > > It was derived from testing I believe. Following your reasoning above, shouldn't this 24000ms timeout be applied only to the Sierra Wireless EM91xx devices (which may have custom firmware bits delaying the initialization a bit longer), and not to the generic SDX24, SDX55 and SDX65? If I'm not mistaken, Thomas is testing with a custom mhi_pci_generic entry for the EM91xx; as in https://forum.sierrawireless.com/t/sierra-wireless-airprime-em919x-pcie-support/24927. I'm also playing with that same entry on my own setup, but have other problems of my own :) -- Aleksander https://aleksander.es
Hello, On Wed, 2021-09-29 at 15:17 +0200, Aleksander Morgado wrote: > Hey Mani, > > > > > diff --git a/drivers/bus/mhi/pci_generic.c > > > > b/drivers/bus/mhi/pci_generic.c > > > > index 4dd1077354af..e08ed6e5031b 100644 > > > > --- a/drivers/bus/mhi/pci_generic.c > > > > +++ b/drivers/bus/mhi/pci_generic.c > > > > @@ -248,7 +248,7 @@ static struct mhi_event_config > > > > modem_qcom_v1_mhi_events[] = { > > > > > > > > static const struct mhi_controller_config > > > > modem_qcom_v1_mhiv_config = { > > > > .max_channels = 128, > > > > - .timeout_ms = 8000, > > > > + .timeout_ms = 24000, > > > > > > > > > This modem_qcom_v1_mhiv_config config applies to all generic SDX24, > > > SDX55 and SDX65 modules. > > > Other vendor-branded SDX55 based modules in this same file (Foxconn > > > SDX55, MV31), have 20000ms as timeout. > > > Other vendor-branded SDX24 based modules in this same file (Quectel > > > EM12xx), have also 20000ms as timeout. > > > Maybe it makes sense to have a common timeout for all? > > > > > > > Eventhough the baseport coming from Qualcomm for the modem chipsets > > are same, it is possible that the vendors might have customized the > > firmware for their own usecase. That could be the cause of the delay > > for modem booting. > > > > So I don't think we should use the same timeout of 2400ms for all > > modems. > > > > Please note it's 24000ms what's being suggested here, not 2400ms. > > > > Thomas, is the 24000ms value taken from experimentation, or is it a > > > safe enough value? Maybe 20000ms as in other modules would have > > > been enough? > > > I made experimentation on a Sierra EM9190 (SDX55) engineering sample, using a old development firmware. So, I agree that setting the same timeout of 24000ms for all modems, is not necessarily relevant. However, the current default value seems too low, in view of timeouts used on vendor-branded, then using a higher value seems relevant. Moreover, Sierra EM919x modems use a custom controller configuration, we are currently working on it. As our tests not being sufficiently conclusive, so we have not yet submitted. Best regards, Thomas > > > > It was derived from testing I believe. > > Following your reasoning above, shouldn't this 24000ms timeout be > applied only to the Sierra Wireless EM91xx devices (which may have > custom firmware bits delaying the initialization a bit longer), and > not to the generic SDX24, SDX55 and SDX65? > > If I'm not mistaken, Thomas is testing with a custom mhi_pci_generic > entry for the EM91xx; as in > https://forum.sierrawireless.com/t/sierra-wireless-airprime-em919x-pcie-support/24927 > . > I'm also playing with that same entry on my own setup, but have other > problems of my own :) > > > -- > Aleksander > https://aleksander.es
On Thu, 30 Sept 2021 at 10:08, Thomas Perrot <thomas.perrot@bootlin.com> wrote: > > Hello, > > On Wed, 2021-09-29 at 15:17 +0200, Aleksander Morgado wrote: > > Hey Mani, > > > > > > > diff --git a/drivers/bus/mhi/pci_generic.c > > > > > b/drivers/bus/mhi/pci_generic.c > > > > > index 4dd1077354af..e08ed6e5031b 100644 > > > > > --- a/drivers/bus/mhi/pci_generic.c > > > > > +++ b/drivers/bus/mhi/pci_generic.c > > > > > @@ -248,7 +248,7 @@ static struct mhi_event_config > > > > > modem_qcom_v1_mhi_events[] = { > > > > > > > > > > static const struct mhi_controller_config > > > > > modem_qcom_v1_mhiv_config = { > > > > > .max_channels = 128, > > > > > - .timeout_ms = 8000, > > > > > + .timeout_ms = 24000, > > > > > > > > > > > > This modem_qcom_v1_mhiv_config config applies to all generic SDX24, > > > > SDX55 and SDX65 modules. > > > > Other vendor-branded SDX55 based modules in this same file (Foxconn > > > > SDX55, MV31), have 20000ms as timeout. > > > > Other vendor-branded SDX24 based modules in this same file (Quectel > > > > EM12xx), have also 20000ms as timeout. > > > > Maybe it makes sense to have a common timeout for all? > > > > > > > > > > Eventhough the baseport coming from Qualcomm for the modem chipsets > > > are same, it is possible that the vendors might have customized the > > > firmware for their own usecase. That could be the cause of the delay > > > for modem booting. > > > > > > So I don't think we should use the same timeout of 2400ms for all > > > modems. > > > > > > > Please note it's 24000ms what's being suggested here, not 2400ms. > > > > > > Thomas, is the 24000ms value taken from experimentation, or is it a > > > > safe enough value? Maybe 20000ms as in other modules would have > > > > been enough? > > > > > > I made experimentation on a Sierra EM9190 (SDX55) engineering sample, > using a old development firmware. > > So, I agree that setting the same timeout of 24000ms for all modems, is > not necessarily relevant. > However, the current default value seems too low, in view of timeouts > used on vendor-branded, then using a higher value seems relevant. I agree, let's set a conservative high value for generic SDX55, so have wider support, that can be tuned per vendor IDs if necessary anyway. Regards, Loic > > Moreover, Sierra EM919x modems use a custom controller configuration, > we are currently working on it. As our tests not being sufficiently > conclusive, so we have not yet submitted. > > Best regards, > Thomas > > > > > > > It was derived from testing I believe. > > > > Following your reasoning above, shouldn't this 24000ms timeout be > > applied only to the Sierra Wireless EM91xx devices (which may have > > custom firmware bits delaying the initialization a bit longer), and > > not to the generic SDX24, SDX55 and SDX65? > > > > If I'm not mistaken, Thomas is testing with a custom mhi_pci_generic > > entry for the EM91xx; as in > > https://forum.sierrawireless.com/t/sierra-wireless-airprime-em919x-pcie-support/24927 > > . > > I'm also playing with that same entry on my own setup, but have other > > problems of my own :) > > > > > > -- > > Aleksander > > https://aleksander.es > > -- > Thomas Perrot, Bootlin > Embedded Linux and kernel engineering > https://bootlin.com >
On Wed, Sep 29, 2021 at 03:17:04PM +0200, Aleksander Morgado wrote: > Hey Mani, > > > >> diff --git a/drivers/bus/mhi/pci_generic.c b/drivers/bus/mhi/pci_generic.c > > >> index 4dd1077354af..e08ed6e5031b 100644 > > >> --- a/drivers/bus/mhi/pci_generic.c > > >> +++ b/drivers/bus/mhi/pci_generic.c > > >> @@ -248,7 +248,7 @@ static struct mhi_event_config modem_qcom_v1_mhi_events[] = { > > >> > > >> static const struct mhi_controller_config modem_qcom_v1_mhiv_config = { > > >> .max_channels = 128, > > >> - .timeout_ms = 8000, > > >> + .timeout_ms = 24000, > > > > > > > > >This modem_qcom_v1_mhiv_config config applies to all generic SDX24, SDX55 and SDX65 modules. > > >Other vendor-branded SDX55 based modules in this same file (Foxconn SDX55, MV31), have 20000ms as timeout. > > >Other vendor-branded SDX24 based modules in this same file (Quectel EM12xx), have also 20000ms as timeout. > > >Maybe it makes sense to have a common timeout for all? > > > > > > > Eventhough the baseport coming from Qualcomm for the modem chipsets are same, it is possible that the vendors might have customized the firmware for their own usecase. That could be the cause of the delay for modem booting. > > > > So I don't think we should use the same timeout of 2400ms for all modems. > > > > Please note it's 24000ms what's being suggested here, not 2400ms. > Doh, sorry I missed one zero ;) > > >Thomas, is the 24000ms value taken from experimentation, or is it a safe enough value? Maybe 20000ms as in other modules would have been enough? > > > > > > > It was derived from testing I believe. > > Following your reasoning above, shouldn't this 24000ms timeout be > applied only to the Sierra Wireless EM91xx devices (which may have > custom firmware bits delaying the initialization a bit longer), and > not to the generic SDX24, SDX55 and SDX65? > > If I'm not mistaken, Thomas is testing with a custom mhi_pci_generic > entry for the EM91xx; as in > https://forum.sierrawireless.com/t/sierra-wireless-airprime-em919x-pcie-support/24927. > I'm also playing with that same entry on my own setup, but have other > problems of my own :) > Hmm, then it makes sense to wait until we get the separate config from Thomas. Thanks, Mani > > -- > Aleksander > https://aleksander.es
On Thu, Sep 30, 2021 at 10:07:57AM +0200, Thomas Perrot wrote: > Hello, > [...] > I made experimentation on a Sierra EM9190 (SDX55) engineering sample, > using a old development firmware. > > So, I agree that setting the same timeout of 24000ms for all modems, is > not necessarily relevant. > However, the current default value seems too low, in view of timeouts > used on vendor-branded, then using a higher value seems relevant. > > Moreover, Sierra EM919x modems use a custom controller configuration, > we are currently working on it. As our tests not being sufficiently > conclusive, so we have not yet submitted. > Okay. Then please add a separate config for this device when you have it. It makes more sense to have the longer timeout only for devices that need it. Thanks, Mani > Best regards, > Thomas > > > > > > > It was derived from testing I believe. > > > > Following your reasoning above, shouldn't this 24000ms timeout be > > applied only to the Sierra Wireless EM91xx devices (which may have > > custom firmware bits delaying the initialization a bit longer), and > > not to the generic SDX24, SDX55 and SDX65? > > > > If I'm not mistaken, Thomas is testing with a custom mhi_pci_generic > > entry for the EM91xx; as in > > https://forum.sierrawireless.com/t/sierra-wireless-airprime-em919x-pcie-support/24927 > > . > > I'm also playing with that same entry on my own setup, but have other > > problems of my own :) > > > > > > -- > > Aleksander > > https://aleksander.es > > -- > Thomas Perrot, Bootlin > Embedded Linux and kernel engineering > https://bootlin.com >
On Thu, Sep 30, 2021 at 12:19:48PM +0200, Loic Poulain wrote: > On Thu, 30 Sept 2021 at 10:08, Thomas Perrot <thomas.perrot@bootlin.com> wrote: > > > > Hello, > > [...] > I agree, let's set a conservative high value for generic SDX55, so > have wider support, that can be tuned per vendor IDs if necessary > anyway. > No. Since this device seems to have a dedicated config, let's increase the timeout only for this device until we get reports for other devices. > Regards, > Loic > > > > > Moreover, Sierra EM919x modems use a custom controller configuration, > > we are currently working on it. As our tests not being sufficiently > > conclusive, so we have not yet submitted. > > > > Best regards, > > Thomas > > > > > > > > > > It was derived from testing I believe. > > > > > > Following your reasoning above, shouldn't this 24000ms timeout be > > > applied only to the Sierra Wireless EM91xx devices (which may have > > > custom firmware bits delaying the initialization a bit longer), and > > > not to the generic SDX24, SDX55 and SDX65? > > > > > > If I'm not mistaken, Thomas is testing with a custom mhi_pci_generic > > > entry for the EM91xx; as in > > > https://forum.sierrawireless.com/t/sierra-wireless-airprime-em919x-pcie-support/24927 > > > . > > > I'm also playing with that same entry on my own setup, but have other > > > problems of my own :) > > > > > > > > > -- > > > Aleksander > > > https://aleksander.es > > > > -- > > Thomas Perrot, Bootlin > > Embedded Linux and kernel engineering > > https://bootlin.com > >
diff --git a/drivers/bus/mhi/pci_generic.c b/drivers/bus/mhi/pci_generic.c index 4dd1077354af..e08ed6e5031b 100644 --- a/drivers/bus/mhi/pci_generic.c +++ b/drivers/bus/mhi/pci_generic.c @@ -248,7 +248,7 @@ static struct mhi_event_config modem_qcom_v1_mhi_events[] = { static const struct mhi_controller_config modem_qcom_v1_mhiv_config = { .max_channels = 128, - .timeout_ms = 8000, + .timeout_ms = 24000, .num_channels = ARRAY_SIZE(modem_qcom_v1_mhi_channels), .ch_cfg = modem_qcom_v1_mhi_channels, .num_events = ARRAY_SIZE(modem_qcom_v1_mhi_events),
Otherwise, the waiting time was too short to use a Sierra Wireless EM919X connected to an i.MX6 through the PCIe bus. Signed-off-by: Thomas Perrot <thomas.perrot@bootlin.com> --- drivers/bus/mhi/pci_generic.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)