Input: stmfts - force async driver probe to avoid 2s delay on boot

Message ID 20180307115604.4031-1-m.szyprowski@samsung.com
State New
Headers show
Series
  • Input: stmfts - force async driver probe to avoid 2s delay on boot
Related show

Commit Message

Marek Szyprowski March 7, 2018, 11:56 a.m.
Executing stmfts_power_on() function lasts over 2 seconds, what
significantly slows down the boot process if driver is compiled in.
Avoid this delay by forcing this driver to be probed asynchronously.

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>

---
 drivers/input/touchscreen/stmfts.c | 1 +
 1 file changed, 1 insertion(+)

-- 
2.15.0

--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Dmitry Torokhov March 7, 2018, 7:34 p.m. | #1
Hi Marek,

On Wed, Mar 07, 2018 at 12:56:04PM +0100, Marek Szyprowski wrote:
> Executing stmfts_power_on() function lasts over 2 seconds, what


I suppose that is because of calibration that is done as part of
powering on?

> significantly slows down the boot process if driver is compiled in.

> Avoid this delay by forcing this driver to be probed asynchronously.


I do not have an objection for making the probe asynchronous, but don't
you have similar issue on resume?

> 

> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>

> ---

>  drivers/input/touchscreen/stmfts.c | 1 +

>  1 file changed, 1 insertion(+)

> 

> diff --git a/drivers/input/touchscreen/stmfts.c b/drivers/input/touchscreen/stmfts.c

> index 025bae3853cc..964f1f43f9ba 100644

> --- a/drivers/input/touchscreen/stmfts.c

> +++ b/drivers/input/touchscreen/stmfts.c

> @@ -812,6 +812,7 @@ static struct i2c_driver stmfts_driver = {

>  		.name = STMFTS_DEV_NAME,

>  		.of_match_table = of_match_ptr(stmfts_of_match),

>  		.pm = &stmfts_pm_ops,

> +		.probe_type = PROBE_PREFER_ASYNCHRONOUS,

>  	},

>  	.probe = stmfts_probe,

>  	.remove = stmfts_remove,

> -- 

> 2.15.0

> 


Thanks.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Marek Szyprowski March 22, 2018, 2:33 p.m. | #2
Hi Dmitry,

On 2018-03-07 20:34, Dmitry Torokhov wrote:
> Hi Marek,

>

> On Wed, Mar 07, 2018 at 12:56:04PM +0100, Marek Szyprowski wrote:

>> Executing stmfts_power_on() function lasts over 2 seconds, what

> I suppose that is because of calibration that is done as part of

> powering on?


Not only calibration. All executed commands takes significant amount of 
time:
STMFTS_MS_CX_TUNING: 0.85s
STMFTS_SS_CX_TUNING: 0.70s
STMFTS_FULL_FORCE_CALIBRATION: 0.28s

>> significantly slows down the boot process if driver is compiled in.

>> Avoid this delay by forcing this driver to be probed asynchronously.

> I do not have an objection for making the probe asynchronous, but don't

> you have similar issue on resume?


Right, similar issue will be on driver resume and it won't be that easy
to make it asynchronous. Should I change that function to schedule an
asynchronous work?

>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>

>> ---

>>   drivers/input/touchscreen/stmfts.c | 1 +

>>   1 file changed, 1 insertion(+)

>>

>> diff --git a/drivers/input/touchscreen/stmfts.c b/drivers/input/touchscreen/stmfts.c

>> index 025bae3853cc..964f1f43f9ba 100644

>> --- a/drivers/input/touchscreen/stmfts.c

>> +++ b/drivers/input/touchscreen/stmfts.c

>> @@ -812,6 +812,7 @@ static struct i2c_driver stmfts_driver = {

>>   		.name = STMFTS_DEV_NAME,

>>   		.of_match_table = of_match_ptr(stmfts_of_match),

>>   		.pm = &stmfts_pm_ops,

>> +		.probe_type = PROBE_PREFER_ASYNCHRONOUS,

>>   	},

>>   	.probe = stmfts_probe,

>>   	.remove = stmfts_remove,

>> -- 

>> 2.15.0

>>

> Thanks.

>


Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Dmitry Torokhov March 23, 2018, 6:35 p.m. | #3
On Thu, Mar 22, 2018 at 03:33:31PM +0100, Marek Szyprowski wrote:
> Hi Dmitry,

> 

> On 2018-03-07 20:34, Dmitry Torokhov wrote:

> > Hi Marek,

> > 

> > On Wed, Mar 07, 2018 at 12:56:04PM +0100, Marek Szyprowski wrote:

> > > Executing stmfts_power_on() function lasts over 2 seconds, what

> > I suppose that is because of calibration that is done as part of

> > powering on?

> 

> Not only calibration. All executed commands takes significant amount of

> time:

> STMFTS_MS_CX_TUNING: 0.85s

> STMFTS_SS_CX_TUNING: 0.70s

> STMFTS_FULL_FORCE_CALIBRATION: 0.28s

> 

> > > significantly slows down the boot process if driver is compiled in.

> > > Avoid this delay by forcing this driver to be probed asynchronously.

> > I do not have an objection for making the probe asynchronous, but don't

> > you have similar issue on resume?

> 

> Right, similar issue will be on driver resume and it won't be that easy

> to make it asynchronous. Should I change that function to schedule an

> asynchronous work?


Hmm, you'd have to sequence suspend and remove callbacks, and it might
wreak havoc with logical device state not quite matching the reality...

Have you tried adding call to device_enable_async_suspend() from the
probe() and see if the overall resume time is reduced?

Thanks.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Marek Szyprowski March 27, 2018, 11:35 a.m. | #4
Hi Dmitry

On 2018-03-23 19:35, Dmitry Torokhov wrote:
> On Thu, Mar 22, 2018 at 03:33:31PM +0100, Marek Szyprowski wrote:

>> Hi Dmitry,

>>

>> On 2018-03-07 20:34, Dmitry Torokhov wrote:

>>> Hi Marek,

>>>

>>> On Wed, Mar 07, 2018 at 12:56:04PM +0100, Marek Szyprowski wrote:

>>>> Executing stmfts_power_on() function lasts over 2 seconds, what

>>> I suppose that is because of calibration that is done as part of

>>> powering on?

>> Not only calibration. All executed commands takes significant amount of

>> time:

>> STMFTS_MS_CX_TUNING: 0.85s

>> STMFTS_SS_CX_TUNING: 0.70s

>> STMFTS_FULL_FORCE_CALIBRATION: 0.28s

>>

>>>> significantly slows down the boot process if driver is compiled in.

>>>> Avoid this delay by forcing this driver to be probed asynchronously.

>>> I do not have an objection for making the probe asynchronous, but don't

>>> you have similar issue on resume?

>> Right, similar issue will be on driver resume and it won't be that easy

>> to make it asynchronous. Should I change that function to schedule an

>> asynchronous work?

> Hmm, you'd have to sequence suspend and remove callbacks, and it might

> wreak havoc with logical device state not quite matching the reality...

>

> Have you tried adding call to device_enable_async_suspend() from the

> probe() and see if the overall resume time is reduced?


Right, this help for resume case. I will send v2.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff --git a/drivers/input/touchscreen/stmfts.c b/drivers/input/touchscreen/stmfts.c
index 025bae3853cc..964f1f43f9ba 100644
--- a/drivers/input/touchscreen/stmfts.c
+++ b/drivers/input/touchscreen/stmfts.c
@@ -812,6 +812,7 @@  static struct i2c_driver stmfts_driver = {
 		.name = STMFTS_DEV_NAME,
 		.of_match_table = of_match_ptr(stmfts_of_match),
 		.pm = &stmfts_pm_ops,
+		.probe_type = PROBE_PREFER_ASYNCHRONOUS,
 	},
 	.probe = stmfts_probe,
 	.remove = stmfts_remove,