[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <26ed2841-db5d-aeb0-11c7-cbe2ddd1d76b@gmail.com>
Date: Thu, 6 Aug 2020 21:01:54 +0300
From: Dmitry Osipenko <digetx@...il.com>
To: Sowjanya Komatineni <skomatineni@...dia.com>,
Thierry Reding <thierry.reding@...il.com>
Cc: jonathanh@...dia.com, frankc@...dia.com, hverkuil@...all.nl,
sakari.ailus@....fi, robh+dt@...nel.org, helen.koike@...labora.com,
gregkh@...uxfoundation.org, linux-media@...r.kernel.org,
devicetree@...r.kernel.org, linux-tegra@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v8 08/10] gpu: host1x: mipi: Keep MIPI clock enabled till
calibration is done
06.08.2020 20:52, Sowjanya Komatineni пишет:
...
> 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.
> - mutex_unlock()
Perhaps the start_calibration() also needs to be changed to not touch
the MIPI_CAL_CONFIG bits of the unrelated pads?
Otherwise sounds good to me.
Powered by blists - more mailing lists