06.08.2020 21:07, Sowjanya Komatineni пишет: > > On 8/6/20 11:01 AM, Dmitry Osipenko wrote: >> 06.08.2020 20:52, Sowjanya Komatineni пишет: >> ... >>> Right mutex_unlock should happen at end of finish_calibration. >>> >>> With keeping mutex locked in start, we dont have to check for active to >>> be 0 to issue start as mutex will keep it locked and other pads >>> calibration can only go thru when current one is done. >>> >>> So instead of below sequence, its simpler to do this way? >>> >>> start_calibration() >>> >>> - mutex_lock >>> >>> - wait for 72uS after start >>> >>> finish_calibration() >>> >>> - keep check for ACTIVE = 0 and DONE = 1 >> I think only the DONE bits which correspond to the mipi_device->pads >> bitmask should be awaited. > > As next START can't be triggered when auto cal is ACTIVE, we should keep > this in finish. > > As we do mutex_unlock only at end of finish, other pads calibrations > dont go thru till the one in process is finished. > > So in this case ACTIVE applies to current selected pads that are under > calibration. Should be better to check only the relevant bits in order to catch bugs, otherwise you may get a DONE status from the irrelevant pads. >>> - mutex_unlock() >> Perhaps the start_calibration() also needs to be changed to not touch >> the MIPI_CAL_CONFIG bits of the unrelated pads? > Driver already takes care of programming corresponding pads config only. It writes 0 to the config of the unrelated pads, which probably isn't nice if some pads use periodic auto-calibration. https://elixir.bootlin.com/linux/v5.8/source/drivers/gpu/host1x/mipi.c#L350 Although looks like auto-calibration isn't supported by the current driver.
