On Mon, Mar 13, 2017 at 10:56:46PM +0200, Sakari Ailus wrote: > Hi Russell, > > On Mon, Mar 13, 2017 at 01:27:02PM +0000, Russell King - ARM Linux wrote: > > On Mon, Mar 13, 2017 at 03:16:48PM +0200, Sakari Ailus wrote: > > > The vast majority of existing drivers do not implement them nor the user > > > space expects having to set them. Making that mandatory would break existing > > > user space. > > > > > > In addition, that does not belong to link validation either: link validation > > > should only include static properties of the link that are required for > > > correct hardware operation. Frame rate is not such property: hardware that > > > supports the MC interface generally does not recognise such concept (with > > > the exception of some sensors). Additionally, it is dynamic: the frame rate > > > can change during streaming, making its validation at streamon time useless. > > > > So how do we configure the CSI, which can do frame skipping? > > > > With what you're proposing, it means it's possible to configure the > > camera sensor source pad to do 50fps. Configure the CSI sink pad to > > an arbitary value, such as 30fps, and configure the CSI source pad to > > 15fps. > > > > What you actually get out of the CSI is 25fps, which bears very little > > with the actual values used on the CSI source pad. > > > > You could say "CSI should ask the camera sensor" - well, that's fine > > if it's immediately downstream, but otherwise we'd need to go walking > > down the graph to find something that resembles its source - there may > > be mux and CSI2 interface subdev blocks in that path. Or we just accept > > that frame rates are completely arbitary and bear no useful meaning what > > so ever. > > The user is responsible for configuring the pipeline. It is thus not > unreasonable to as the user to configure the frame rate as well if there are > device in the pipeline that can affect the frame rate. The way I proposed to > implement it is compliant with the existing API and entirely deterministic, > contrary to what you're saying. You haven't really addressed my point at all. What you seem to be saying is that you're quite happy for the situation (which is a total misconfiguration) to exist. Given the vapourware of userspace (which I don't see changing in any kind of reasonable timeline) I think this is completely absurd. I'll state clearly now: everything that we've discussed so far, I'm finding very hard to take anything you've said seriously. I think we have very different and incompatible point of views about what is acceptable from a user point of view, so much so that we're never going to agree on any point. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
