[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b5fcc292-8ce3-2833-491f-5aefbe0196eb@nvidia.com>
Date: Wed, 29 Jul 2020 10:55:16 -0700
From: Sowjanya Komatineni <skomatineni@...dia.com>
To: Dmitry Osipenko <digetx@...il.com>, <thierry.reding@...il.com>,
<jonathanh@...dia.com>, <frankc@...dia.com>, <hverkuil@...all.nl>,
<sakari.ailus@....fi>, <robh+dt@...nel.org>,
<helen.koike@...labora.com>
CC: <sboyd@...nel.org>, <gregkh@...uxfoundation.org>,
<linux-media@...r.kernel.org>, <devicetree@...r.kernel.org>,
<linux-tegra@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<linux-i2c@...r.kernel.org>
Subject: Re: [RFC PATCH v5 12/14] gpu: host1x: mipi: Keep MIPI clock enabled
till calibration is done
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.
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.
Powered by blists - more mailing lists