Hi Chris, On Thursday 04 May 2017 12:23:32 Chris Brandt wrote: > On Wednesday, May 03, 2017, jmondi wrote: > > I have a proposal here, as the original driver only supported "image > > fetch mode" (ie. It accepts data in YUYV with components ordering > > arbitrary swapped) as a first step we may want to replicate this, ignoring > > data synch fetch mode (Chris, you have a driver for this you are already > > using in your BSP so I guess it's less urgent to support it, right?). > > > My "driver" (if you can call it that) is basically 20 lines of code that > sets up the registers either "image capture" mode or "data fetch". The > main reason for the code was that the current CEU driver only supported > "image capture" which resulted in separate Y and CbCr output buffers > output, and then the app would have to merge them back together which was a > waste of time (and memory). > > My customers simply wanted the packed format > that came out of the camera. So, I created the 20 lines of code and we > abandoned the CEU driver in the kernel. > > Also, the LCD controller (VDC5) can display a YCbCr frame buffer directly if > it's packed...but not if it's a separate Y/CbCr buffers. > > Not to mention, if you just have a black and white camera (Y only), the > Y/CbCr spilt function is totally useless and cuts your B&W image in half > for no reason. > > My point: You can do the "image capture" mode (CAMCR:JPG=0) first, but no > one will actually use the driver until the "data fetch" mode (CAMCR:JPG=1) > is implemented.
Thanks for the feedback. I think that, given a YUV sensor, implementing support for both image capture and data fetch modes won't be difficult. Jacopo, are you OK with that ? If you implement image capture mode first, data fetch mode should be just a small additional patch. -- Regards, Laurent Pinchart
