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)
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
