Thread (47 messages) 47 messages, 3 authors, 2020-08-06

Re: [PATCH v8 08/10] gpu: host1x: mipi: Keep MIPI clock enabled till calibration is done

From: Sowjanya Komatineni <skomatineni@nvidia.com>
Date: 2020-08-06 17:12:24
Also in: linux-media, linux-tegra, lkml

On 8/6/20 9:41 AM, Sowjanya Komatineni wrote:
On 8/6/20 9:10 AM, Dmitry Osipenko wrote:
quoted
06.08.2020 18:59, Sowjanya Komatineni пишет:
...
quoted
quoted
quoted
Confirmed from HW designer, calibration FSM to finish takes worst 
case
72uS so by the time it gets to sensor stream it will be done its
sequence and will be waiting for DONE bit.

So disabling MIPI CAL clock on sensor stream fails is safe.
72us is quite a lot of time, what will happen if LP-11 happens before
FSM finished calibration?

Maybe the finish_calibration() needs to split into two parts:

   1. wait for CAL_STATUS_ACTIVE before enabling sensor
   2. wait for CAL_STATUS_DONE after enabling sensor
I don't think we need to split for active and done. Active will be 1 as
long as other pads are in calibration as well.

We cant use active status check for specific pads under calibration.
This is common bit for all pads.
Does hardware have a single FSM block shared by all pads or there is FSM
per group of pads?
MIPI CAL status register has DONE bits for individual pads status and 
single ACTIVE bit.

ACTIVE bit set to 1 indicates auto calibration is active which is the 
case even when other pads (other CSI pads from other ports streaming 
in case of parallel stream) are under calibration. Also DSI is shared 
as well.

We do calibration for individual pads. So, we should not rely on 
ACTIVE bit.


MIPI driver checks for condition ACTIVE == 1 && DONE == 1 from the 
beginning.

But I think this also should be fixed as in case of parallel streams 
calibration can happen in parallel waiting for ACTIVE to be cleared 
makes all calibration callers to wait for longer than needed as ACTIVE 
is common for all pads.
quoted
quoted
Unfortunately HW don't have separate status indicating when sequence is
done to indicate its waiting for LP11.


To avoid all this, will remove cancel_calibration() totally and use 
same
finish calibration even in case of stream failure then.
What about to add 72us delay to the end of start_calibration() in order
to ensure that FSM is finished before LP-11?
Why we should add 72uS in start_calibration() when can use same 
finish_calibration() for both pass/fail cases?

Only timing loose we see is in case of failure we still wait for 250ms 
and as this is failing case I hope should be ok.
Also as we don't need cancel_calibration(), keeping tegra_mipi_wait() 
like earlier makes sense I believe as we are letting it finish going 
thru sequence.

So I think below are fixes,

1. Existing MIPI driver, tegra_mipi_wait() to not use status ACTIVE bit 
to be 0 and use only DONE bit to be 1 for wait condition  as we are 
calibrating separately for individual pads and this ACTIVE bit is common 
for all pads where it will not be 0 in case of other parallel streams 
which may also be under calibration.

2. No need for separate cancel_calibration. So, probably earlier names 
tegra_mipi_calibrate() and tegra_mipi_wait() hols good as we are waiting 
for calibration sequence to finish irrespective of fail/pass.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help