Hi Jacopo, 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. Chris
