About master clock frequency in soc-camera
Hi Guennadi et all,
On our i.MX27 board we have a wide range of cameras (mt9m001, mt9v022, mt9m131). Registering all of them and let the probe routines decide which one is connected works quite good.
The problem I have now is that the mt9m131 allows for a higher master clock frequency. ATM the mclk is given with the mx2_camera platform data (same on i.MX31), thus only one mclk frequency is supported per kernel image. Do you have any hints on how to make the mclk a parameter of the sensors?
Sascha
Signature · 4 lines
Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
Quoted 10 lines · Sascha Hauer
Hi Guennadi et all,
On our i.MX27 board we have a wide range of cameras (mt9m001, mt9v022, mt9m131). Registering all of them and let the probe routines decide which one is connected works quite good.
The problem I have now is that the mt9m131 allows for a higher master clock frequency. ATM the mclk is given with themx2_cameraplatform data (same on i.MX31), thus only one mclk frequency is supported per kernel image. Do you have any hints on how to make the mclk a parameter of the sensors?
So then, it looks like one more parameter we have to negotiate (oops, sorry, hard-code;)) between the sensor and the platform. If we didn't have the soc-camera bus-parameter negotiation removal in favour of a new hard-coded configuration planned for some now-very-near future, I would say - add this there, and select the minimum of the two frequencies in the host driver. But now... also here we are blocked by this pending transition. So, this means, we have to wait until a conversion strategy is ready, until the bulk has been converted, and then we can add new features to the new bus-parameter set up procedure.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/