linux-kernel - Re: Failure to stop CAMSS stream (sc8280xp)

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: <49b2504f-e5ab-4ea9-aefb-bc9c7f71f5fc@linaro.org>
Date: Wed, 3 Jul 2024 15:30:09 +0100
From: Bryan O'Donoghue <bryan.odonoghue@...aro.org>
To: Johan Hovold <johan@...nel.org>, Robert Foss <rfoss@...nel.org>,
 Todor Tomov <todor.too@...il.com>
Cc: Mauro Carvalho Chehab <mchehab@...nel.org>,
 Kieran Bingham <kieran.bingham@...asonboard.com>,
 linux-media@...r.kernel.org, linux-arm-msm@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: Failure to stop CAMSS stream (sc8280xp)

On 03/07/2024 14:07, Johan Hovold wrote:
> Is this a known issue with CAMSS or is something missing in the sc8280xp
> integration?

A known issue on my end, I also want to root cause intermittent sensor 
startup failure, before switching on the sensor upstream for more common 
use.


> I'm using the following (squashed) devicetree patch from Bryan to enable
> the camera (everything else is upstream):
> 
> 	https://github.com/jhovold/linux/commit/85b41b8d0efd418509df548592f95b43b9663409
> 
> The issue was there with 6.9 as well so it's not a (recent) regression.
> 
> Probing the camera sometimes, but infrequently, also fails with:
> 
> 	qcom-camss ac5a000.camss: Failed to power up pipeline: -13

Yes this. If you recall on the pm8010 I had mentioned to you about a 
wait-time to startup the regulator - thinking it was the regulator 
causing this error.

More likely the GPIO reset polarity or delay needs to be tweaked in the 
sensor driver.

> and I'm seeing the following warning on every boot:
> 
> 	i2c-qcom-cci ac4c000.cci: Found 19200000 cci clk rate while 37500000 was expected

That's hanging around for quite a long time 19.2 MHz is a perfectly 
valid clock, useless error message.

---
bod