Re: [RFC PATCH v5 12/14] gpu: host1x: mipi: Keep MIPI clock enabled till calibration is done

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 7/29/20 4:42 PM, Dmitry Osipenko wrote:
29.07.2020 20:55, Sowjanya Komatineni пишет:
On 7/29/20 10:08 AM, Dmitry Osipenko wrote:
28.07.2020 19:04, Sowjanya Komatineni пишет:
...
+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.

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.




[Index of Archives]     [Linux GPIO]     [Linux SPI]     [Linux Hardward Monitoring]     [LM Sensors]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux