linux-kernel - Re: [RFC PATCH v5 13/14] media: tegra-video: Add CSI MIPI pads calibration

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <edefa3b1-e0fe-0f34-80b7-8729551ee2ea@nvidia.com>
Date:   Tue, 28 Jul 2020 12:43:53 -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 13/14] media: tegra-video: Add CSI MIPI pads
 calibration


On 7/28/20 8:59 AM, Sowjanya Komatineni wrote:
>
> On 7/28/20 3:30 AM, Dmitry Osipenko wrote:
>> 27.07.2020 23:57, Sowjanya Komatineni пишет:
>>> +    /*
>>> +     * TRM has incorrectly documented to wait for done status from
>>> +     * calibration logic after CSI interface power on.
>>> +     * As per the design, calibration results are latched and applied
>>> +     * to the pads only when the link is in LP11 state which will 
>>> happen
>>> +     * during the sensor stream-on.
>>> +     * CSI subdev stream-on triggers start of MIPI pads calibration.
>>> +     * Wait for calibration to finish here after sensor subdev 
>>> stream-on
>>> +     * and in case of sensor stream-on failure, cancel the 
>>> calibration.
>>> +     */
>>>       subdev = on ? src_subdev : csi_subdev;
>>>       ret = v4l2_subdev_call(subdev, video, s_stream, on);
>>> -    if (ret < 0 && ret != -ENOIOCTLCMD)
>>> +    if (ret < 0 && ret != -ENOIOCTLCMD) {
>> I assume -ENOIOCTLCMD means that camera wasn't turned ON, so why
>> -ENOIOCTLCMD is special?
> No -ENOIOCTLCMD mean subdev don't have s_stream ops
>>
>>> +        if (on && csi_chan->mipi)
>>> +            tegra_mipi_cancel_calibration(csi_chan->mipi);
>>>           return ret;
>>> +    }
>>> +
>>> +    if (on && csi_chan->mipi) {
>> Does finish_calibration() really need to be called for ret=-ENOIOCTLCMD?
>>
>> Shouldn't it be cancel_calibration( for the -ENOIOCTLCMD?
>
> start calibration happens during csi sensor streaming which happens 
> prior to this point.
>
> In case if sensor subdev does not have s_stream ops, then either 
> finish/cancel calibration should happen to disable the clock.

For -ENOIOCTLCMD, calling finish calibration as some sensors might keep 
pads in LP-11 on power up and for such sensors calibration logic will 
apply results to pads and done bit will be set.

Also avoiding additional check to specifically call cancel calibration 
on ENOIOCTLCMD and making it fall into finish calibration as both does 
disable clock except finish will wait for done bit to be set.

Also, most sensor subdev have s_stream ops implemented.

>
>>
>>> +        ret = tegra_mipi_finish_calibration(csi_chan->mipi);
>>> +        if (ret < 0)
>>> +            dev_err(csi_chan->csi->dev,
>>> +                "MIPI calibration failed: %d\n", ret);
>> Doesn't v4l2_subdev_call(OFF) need to be invoked here on error?
>
> Not required as on error streaming fails and runtime PM will turn off 
> power anyway.
>
> Also we only did csi subdev s_stream on and during sensor subdev 
> s_stream on fail, actual stream dont happen and on tegra side frame 
> capture by HW happens only when kthreads run.
>>> +        return ret;
>>> +    }
>>>         return 0;
>>>   }