Petr Cvek <petr.cvek@xxxxxx> writes: > Dne 1.5.2017 v 06:20 Petr Cvek napsal(a): >> This patchset is just a grouping of a few bugfixes I've found during >> the ov9640 sensor support re-adding. > > P.S. I've manually calculated every format variant for the image size > calculation functions, but still these functions are not too robust (for every > hypothetical bps/packing/layout combination). For example: > > MEDIA_BUS_FMT_Y8_1X8 > .name = "Grey", > .bits_per_sample = 8, > .packing = PXA_MBUS_PACKING_NONE, > .order = PXA_MBUS_ORDER_LE, > .layout = PXA_MBUS_LAYOUT_PACKED, > > seems to me as a little bit misleading. The better solution would be to have something like bytes_per_line and image_size coefficients. Is my idea worth a try? > > Anyway the .order field seems to be unused (it is a pxa_camera defined structure). I'm for removing it (I can create a patch and test it on the real hardware). Unless there are plans for it. > > The pxa_camera_get_formats() could be probably simplified even up to the point > of a removal of the soc_camera_format_xlate structure. If no one works on it (in > like 2 months) I can try to simplify it. Yes, simplifing get soc_camera_format_xlate struct would be great. And yeah, nobody will be working on it in the next 2 monthes. Besides, Hans had expressed interest in having it removed. On my side, as long as the format translation happens, ie. pxa_camera provides a list of formats which is a _superset_ of the sensor formats as today (especially YUV422P, YUYV and its permutations, RGBxxxx), I'll be totally fine with it, even if it was my idea several years ago to have a translation... Let's see what new ideas can provide, new blood etc ... Cheers. -- Robert
