Re: [PATCH v3 2/4] media: ov5675: add device-tree support and support runtime PM

[Quentin Schulz <quentin.schulz@theobroma-systems.com>]

Hi all,

On 5/10/22 15:42, Quentin Schulz wrote:
> Hi all,
> 
> On 5/10/22 11:46, Jacopo Mondi wrote:
>> Hi Quentin,
>>
>> On Mon, May 09, 2022 at 04:32:24PM +0200, Quentin Schulz wrote:
>>> From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
>>>
>>> Until now, this driver only supported ACPI. This adds support for
>>> Device Tree too while enabling clock and regulators in runtime PM.
>>>
>>> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
>>
>> Thanks for addressing all comments on the previous version.
>>
>> Looks good to me!
> 
> Unfortunately the sensor disagrees :/
> 
> For some reasons, the first three power-on + power-off are successful 
> (sometimes only the first two) and then the sensor is not working until 
> next cold boot. I got lucky when I tested the patch before sending, much 
> less now. >

For your information, there were actually two issues:

  - the MCLK of our camera sensor is connected to a pin on a Rockchip 
PX30 SoC whose iodomain is not enabled prior to booting the Linux 
kernel. This means that the whole block was not supplied with power 
(something around 100-150mV instead of the expected 1.8V) and the i2c 
transfers during some device probing were broken because the iodomains 
driver could be probed after the OV5675 driver (and also, since it 
persists on CPU reset, a reboot would fix this too since the iodomain 
would have been configured by the preceding boot). We currently handle 
this the hackish way by configuring the iodomain in U-Boot before 
booting the kernel. I have talked with Heiko, the Rockchip maintainer, 
who mentioned there's no way to explicit a dependency to an iodomain in 
Device Tree right now but suggested we expose regulators from the 
iodomain driver. I'll come up with something to fix this properly in the 
kernel in the next few months. This is not related to the camera driver 
in any way but wanted to mention it.

  - the camera sensor was actually faulty. After many attempts at HW 
reworking, looking at the scope, re-reading the datasheet, trying to 
read between the lines, etc... we swapped the camera sensor for a 
fresh-out-of-the-box one and it worked for 30min (then we stopped it) 
with a runtime/suspend every few seconds. I tried with two different 
camera sensors and it worked fine.

Cheers,
Quentin