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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
