Re: [ANN] Meeting minutes of the Cambourne meeting

[Subash Patel <subashrp@gmail.com>]

Hi Sakari,

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 
(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.

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) ...

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

Regards,
Subash

 > Pixel clock and blanking
 > ------------------------
 >
 >   Preliminary conclusions:
 >
 >   - Pixel clock(s) and blanking will be exported through controls on 
subdev
 >     nodes.
 >   - The pixel array pixel clock is needed by userspace.
 >   - Hosts/bridges/ISPs need pixel clock and blanking information to 
validate
 >     pipelines.
 >
 >   Actions:
 >
 >   - CSI2 and CCP2 bus frequencies will be selectable use integer menu 
controls.
 >     (Sakari)
 >   - Add an integer menu control type, replacing the name with a 
64-bit integer.
 >     (Sakari, Hans)
 >   - Research which pixel clock(s) to expose based on the SMIA sensor.
 >     (Sakari)
 >   - Add two new internal subdev pad operations to get and set clocks and
 >     blanking.
 >     (Laurent, Sakari)