Message ID | 20211004120650.153218-1-adrian.hunter@intel.com (mailing list archive) |
---|---|
Headers | show |
Series | scsi: ufs: Start to make driver synchronization easier to understand | expand |
> Driver synchronization would be easier to understand if we used the > clk_scaling_lock as the only lock to provide either shared (down/up_read) > or exclusive (down/up_write) access to the host. > > These patches make changes with that in mind, finally resulting in being > able to hold the down_write() lock for the entire error handler duration. > > If this approach is acceptable, it could be extended to simplify the > the synchronization of PM vs error handler and Shutdown vs sysfs. Given that UFSHCD_CAP_CLK_SCALING is only set for ufs-qcom: If extending its use, wouldn't that become a source of contention for them? Thanks, Avri
On 04/10/2021 15:42, Avri Altman wrote: > >> Driver synchronization would be easier to understand if we used the >> clk_scaling_lock as the only lock to provide either shared (down/up_read) >> or exclusive (down/up_write) access to the host. >> >> These patches make changes with that in mind, finally resulting in being >> able to hold the down_write() lock for the entire error handler duration. >> >> If this approach is acceptable, it could be extended to simplify the >> the synchronization of PM vs error handler and Shutdown vs sysfs. > Given that UFSHCD_CAP_CLK_SCALING is only set for ufs-qcom: > If extending its use, wouldn't that become a source of contention for them? It is a good question. The error handler already seems to stop clock scaling. PM / Shutdown seem to suspend / resume clock scaling. So it doesn't *look* like it should make much difference.