On 8/6/20 11:44 AM, Sowjanya Komatineni wrote:

On 8/6/20 11:18 AM, Dmitry Osipenko wrote:

quoted

06.08.2020 21:07, Sowjanya Komatineni пишет:

quoted

On 8/6/20 11:01 AM, Dmitry Osipenko wrote:

quoted

06.08.2020 20:52, Sowjanya Komatineni пишет:
...

quoted

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.

tegra_mipi_device is separate for DSI and CSI channels. mutex lock 
used during calibrate is device specific lock.
So, it will not prevent other devices to hold till on going 
calibration is done unless we add wait for active bit before 
triggering start.

Currently we wait for active bit at end during calibration done check 
after start trigger. But when other devices go thru calibration in 
parallel as lock is device specific and not common lock for all 
devices it will trigger start but MIPI calibration logic ignore if 
previous calibration is still in progress.

Need to serialize calibration start requests from different devices 
based on ACTIVE bit.

Sorry confused. MIPI driver is using common lock from tegra_mipi for all 
tegra_mipi_device

So should be ok as only one device start_calibration can happen at a time.

But its still good to check ACTIVE is cleared and to report as error if 
not as ACTIVE will be cleared once set of pads enabled for this calibration.

Eg: CSI port can be 4 lane and all 4 pads gets enabled at same time and 
with this ACTIVE should still be verified to be 0 to make sure all pads 
calibration is done

quoted

quoted

quoted

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.

Yes we don't use auto-calibration.

Only common bit here is MIPI_CAL_CTRL start. All others are pad 
specific currently.