Hi Sylwester, On Thu, Dec 15, 2011 at 11:19:40PM +0100, Sylwester Nawrocki wrote: > On 12/15/2011 11:01 PM, Sakari Ailus wrote: > >>> <entry>__u32</entry> > >>> - <entry><structfield>reserved</structfield>[7]</entry> > >>> + <entry><structfield>pixel_clock</structfield></entry> > >>> + <entry>Pixel clock in kHz. This clock is the maximum rate at > >>> + which pixels are transferred on the bus. The pixel_clock > >>> + field is read-only.</entry> > >> > >> I searched a couple of datasheets to find out where I could use this pixel_clock > >> field but didn't find any so far. I haven't tried too hard though ;) > >> There seems to be more benefits from having the link frequency control. > > > > There are a few reasons to have the pixel clock available to the user space. > > > > The previously existing reason is that the user may get information on the > > pixel rates, including cases where the pixel rate of a subdev isn't enough > > for the streaming to be possible. Earlier on it just failed. Such cases are > > common on the OMAP 3 ISP, for example. > > > > The second reason is to provide that for timing calculations in the user > > space. > > Fair enough. Perhaps, if I have worked more with image signal processing > algorithms in user space I would not ask about that in the first place :-) It's not only the algorithms, but it gives you a way to perform low level sensor configuration. It gives the user an easy way to configure the frame rate freely between a range which is easy to obtain, and also taking into account the policy decisions instead of the kernel doing them for the user. There's more in the parent, albeit I forgot to mention the above: <URL:http://www.spinics.net/lists/linux-media/msg40861.html> > > > > >> It might be easy to confuse pixel_clock with the bus clock. The bus clock is > >> often referred in datasheets as Pixel Clock (PCLK, AFAIU it's described with > >> link frequency in your RFC). IMHO your original proposal was better, i.e. > >> using more explicit pixel_rate. Also why it is in kHz ? Doesn't it make more > >> sense to use bits or pixels per second ? > > > > Oh, yes, now that you mention it I did call it pixel rate. I'm fine > > withrenaming it back to e.g. "pixelrate". > > I'm fine with that too, sounds good! > > > > > I picked kHz since the 32-bit field would allow rates up to 4 GiP/s. Not > > sure if that's overkill though. Could be. But in practice it should give > > good enough precision this way, too. > > All right, however I was more concerned by the "Hz" part, rather than "k" ;) > It might be good to have the relevant unit defined in the spec, to avoid > misinterpretation and future interoperability issues . Indeed. kp/s then? :-) Regards, -- Sakari Ailus e-mail: sakari.ailus@xxxxxx jabber/XMPP/Gmail: sailus@xxxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
