Re: [ANN] Meeting minutes of the Cambourne meeting

[Sakari Ailus <sakari.ailus@maxwell.research.nokia.com>]

Subash Patel wrote:
> Hi Sakari,

Hi Subash,

> I have a point with the pixel clock. During discussion we found that
> pixel clock get/set is required for user space to do fine control over
> the frame-rate etc. What if the user sets the pixel array clock which is
> above the system/if bus clock? Suppose we are setting the pixel clock

The pixel array clock should be calculated by the driver based on CSI-2
bus frequency (user specified), lanes (from board data), binning,
skipping and crop. This is since there are typically limitations for its
value, and the sensor driver can come up with a "best value" for it,
based on the information above. Exactly how, that depends on the sensor
driver and the sensor.

So the pixel array clock is read-only for the user, and the frame rate
can then be chosen using the blanking configuration.

> (which user space sets) to higher rate at sensor array, but for some
> reason the bus cannot handle that rate (either low speed or loaded) or
> lower PCLK at say CSI2 interface is being set. Are we not going to loose
> data due to this? Also, there would be data validation overhead in
> driver on what is acceptable PCLK values for a particular sensor on an
> interface etc.

This is something that must be handled independently of the way the
sensor pixel clock is configured. Typically the limitation is on either
the bus frequency or the pixel rate on the bus.

This actually can be better avoided when the user has a chance to choose
the bus frequency explicitly rather than receive just something the
driver happens to produce based on frame rate and resolution settings.

> I am still not favoring user space controlling this, and wish driver
> decides this for a given frame-rate requested by the user space :)
> 
> Frame-rate   resolution  HSYNC  VSYNC  PCLK(array)  PCLK (i/f bus) ...

You can still do that, but it comes with limitations. Any fixed set of
the above parameters is very hardware and use case dependent.

> Let user space control only first two, and driver decide rest (PCLK can
> be different at different ISP h/w units though)

I'm definitely not against this. We do have drivers which use this kind
of interface already and some vendors do not even provide enough
information to write a driver for their sensor offering any other kind
of interface.

Cheers,

-- 
Sakari Ailus
sakari.ailus@maxwell.research.nokia.com