linux-kernel - Re: [PATCH v9 08/10] gpu: host1x: mipi: Keep MIPI clock enabled and mutex locked till calibration done

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 for Android: free password hash cracker in your pocket

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

Message-ID: <7ef2a6dd-d220-ff47-e6ef-7443a1779fae@nvidia.com>
Date:   Thu, 6 Aug 2020 20:10:23 -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 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.