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