06.08.2020 21:07, Sowjanya Komatineni пишет:tegra_mipi_device is separate for DSI and CSI channels. mutex lock used during calibrate is device specific lock.
On 8/6/20 11:01 AM, Dmitry Osipenko wrote:Should be better to check only the relevant bits in order to catch bugs,
06.08.2020 20:52, Sowjanya Komatineni пишет:As next START can't be triggered when auto cal is ACTIVE, we should keep
...
Right mutex_unlock should happen at end of finish_calibration.I think only the DONE bits which correspond to the mipi_device->pads
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
bitmask should be awaited.
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.
otherwise you may get a DONE status from the irrelevant pads.
It writes 0 to the config of the unrelated pads, which probably isn'tPerhaps the start_calibration() also needs to be changed to not touchDriver already takes care of programming corresponding pads config only.
the MIPI_CAL_CONFIG bits of the unrelated pads?
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.