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: <ecf679f8-e08b-3297-2d33-1e5737c92982@nvidia.com>
Date:   Thu, 6 Aug 2020 21:05:15 -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:     <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 v9 08/10] gpu: host1x: mipi: Keep MIPI clock enabled and
 mutex locked till calibration done


On 8/6/20 9:01 PM, Dmitry Osipenko wrote:
> 07.08.2020 06:18, Sowjanya Komatineni пишет:
>> On 8/6/20 8:14 PM, Sowjanya Komatineni wrote:
>>> On 8/6/20 8:10 PM, Sowjanya Komatineni wrote:
>>>> On 8/6/20 7:31 PM, Dmitry Osipenko wrote:
>>>>> 06.08.2020 22:01, Sowjanya Komatineni пишет:
>>>>> ...
>>>>>> +int tegra_mipi_start_calibration(struct tegra_mipi_device *device)
>>>>>>    {
>>>>>>        const struct tegra_mipi_soc *soc = device->mipi->soc;
>>>>>>        unsigned int i;
>>>>>> @@ -381,12 +375,16 @@ int tegra_mipi_calibrate(struct
>>>>>> tegra_mipi_device *device)
>>>>>>        value |= MIPI_CAL_CTRL_START;
>>>>>>        tegra_mipi_writel(device->mipi, value, MIPI_CAL_CTRL);
>>>>>>    -    mutex_unlock(&device->mipi->lock);
>>>>>> -    clk_disable(device->mipi->clk);
>>>>>> +    /*
>>>>>> +     * Wait for min 72uS to let calibration logic finish calibration
>>>>>> +     * sequence codes before waiting for pads idle state to apply the
>>>>>> +     * results.
>>>>>> +     */
>>>>>> +    usleep_range(75, 80);
>>>>> Could you please explain why the ACTIVE bit can't be polled instead of
>>>>> using the fixed delay? Doesn't ACTIVE bit represents the state of the
>>>>> busy FSM?
>>>> Based on internal discussion, ACTIVE bit gets cleared when all
>>>> enabled pads calibration is done (same time as when DONE set to 1).
>>>>
>>>> Will request HW designer to look into design and confirm exactly when
>>>> ACTIVE bit gets cleared.
>>>>
>>>> Will get back on this.
>>>>
>>> Verified with HW designer. above is correct. ACTIVE bit update happens
>>> same time as DONE bit.
>>>
>>> Active = !(DONE)
>>>
>>> In case of calibration logic waiting for LP-11 where done bit does not
>>> get set, ACTIVE will still be 1 and on next start trigger new
>>> calibration will start
>>>
>> Based on internal design check from designer, as long as its in waiting
>> for LP-11 stage, next calibration request can be triggered again but
>> ACTIVE bit we will see it at 1. So we should check for DONE bits to
>> confirm if calibration is done or not.
>>
>> To start next calibration, it can take effect as long as its in wait for
>> LP-11 mode.
> I meant the start_calibration() will poll the ACTIVE bit (calibration
> busy), while the finish_calibration() will poll the DONE bit
> (calibration applied).

ACTIVE bit can be 1 when previous calibration process does not see LP-11.

So there is no need to use ACTIVE bit during start of calibration.

At HW level, both ACTIVE and DONE bits get set at same time.

So waiting for ACTIVE to be 0 during start calibration instead of 7uS 
will not work as ACTIVE bit will not become 0 after calibration sequence 
codes and it will get updated along with DONE bits only after applying 
results to pads which happens after seeing LP-11 on pads.


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ