Difference between revisions of "PinePhone Pro/IMX258 Camera Debugging"
Jump to navigation
Jump to search
m |
m |
||
| Line 14: | Line 14: | ||
This tells us the kernel loads the driver, which is something. | This tells us the kernel loads the driver, which is something. | ||
Are these errors bad/fatal? Inspecting the [https://github.com/megous/linux/blob/orange-pi-5.17/drivers/media/i2c/imx258.c source] shows us that these supplies are defined in the <code>imx258_supply_names</code> array, and <code>imx258_probe</code> calls <code>devm_regulator_bulk_get</code> to set up | Are these errors bad/fatal? Inspecting the [https://github.com/megous/linux/blob/orange-pi-5.17/drivers/media/i2c/imx258.c source] shows us that these supplies are defined in the <code>imx258_supply_names</code> array, and <code>imx258_probe</code> calls <code>devm_regulator_bulk_get</code> to set them up. | ||
<code>imx258_probe</code> checks the return code from <code>devm_regulator_bulk_get</code>, | <code>imx258_probe</code> checks the return code from <code>devm_regulator_bulk_get</code>, emitting a fatal "Failed to get supplies" message if the return code is negative (indicating failure). Since we don't see this message (or any others from the driver), it looks like it loads successfully! | ||
=== How can we test the camera? === | === How can we test the camera? === | ||
| Line 95: | Line 95: | ||
The camera driver uses i2c; we can see the camera [https://github.com/megous/linux/blob/c5af9f4f874a66b65c73c450b79f6a86b1b46332/arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts#L890-L914 in the .dts] to determine that it's on i2c bus 1, address 0x1a. | The camera driver uses i2c; we can see the camera [https://github.com/megous/linux/blob/c5af9f4f874a66b65c73c450b79f6a86b1b46332/arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts#L890-L914 in the .dts] to determine that it's on i2c bus 1, address 0x1a. | ||
The imx258 is controlled over i2c, and sends image data over MIPI | The imx258 is controlled over i2c, and sends image data over MIPI. The first step is to see if the i2c control is working. | ||
Looking back at the driver, it seems we should see errors in dmesg if i2c communication fails. The driver checks the chip id in its probe function, which uses i2c, so we can conclude that i2c gets set up properly initially. Does it keep working? | Looking back at the driver, it seems we should see errors in dmesg if i2c communication fails. The driver checks the chip id in its probe function, which uses i2c, so we can conclude that i2c gets set up properly initially. Does it keep working? | ||