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, .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),
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
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
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),
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-supp.... 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-supp... . 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-supp... . 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-supp... . 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 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-supp... . 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-supp.... 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
linux-stable-mirror@lists.linaro.org
-
Aleksander Morgado -
Loic Poulain -
Manivannan Sadhasivam -
Thomas Perrot