On 7/29/20 4:42 PM, Dmitry Osipenko wrote:

29.07.2020 20:55, Sowjanya Komatineni пишет:

quoted

On 7/29/20 10:08 AM, Dmitry Osipenko wrote:

quoted

28.07.2020 19:04, Sowjanya Komatineni пишет:
...

quoted

quoted

quoted

+void tegra_mipi_cancel_calibration(struct tegra_mipi_device *device)
+{

Doesn't MIPI_CAL need to be reset here?

No need to reset MIPI CAL

Could you please explain why. There is a calibration state-machine that
apparently needs to be returned into initial state, does it return by
itself?

TRM says that MIPI block needs to be reset before of starting
calibration process. The reset is completely missing in the driver, I
assume it needs to be corrected with another patch.

TRM documented incorrectly. There is no need to reset MIPI_CAL.

MIPI CAL is FSM and it does not hang and done bit is to indicate if
results are applied to pads or not.

If we don't see done bit set meaning, MIPI CAL did not see LP-11 and
results are not applied to pads.

But how to stop calibration from triggering on LP-11 once it has been
enabled? The reset should be needed since there is no other way to reset
the calibration state.

Its a finite state machine that goes thru fixed steps of sequence codes 
internally and holds results in registers.

When it sees LP-11 results are applied to pads.

If it does not see LP-11, next start will again trigger calibrating with 
finite sequence codes.

As per HW designers, we don't have to do any reverts when done bit is 
not set.

quoted

Also while multiple streams can happen in parallel and we can't reset
MIPI CAL as other CSI channel streams (using other pads) may also be
going thru calibration process in parallel depending and also DSI pads
also are calibrated thru same MIPI CAL controller.

Perhaps this should be the case for a shared reset control API usage.