Hi Sakari,
On 4/8/22 1:05 PM, Sakari Ailus wrote:
Hi Hugues,
On Thu, Apr 07, 2022 at 06:25:11PM +0200, Hugues FRUCHET - FOSS wrote:
Hi Jacopo,
On 3/23/22 10:50 AM, Jacopo Mondi wrote:
Hi Tomi thanks for testing
On Wed, Mar 23, 2022 at 10:51:04AM +0200, Tomi Valkeinen wrote:
Hi Jacopo,
On 24/02/2022 11:42, Jacopo Mondi wrote:
v1:
https://patchwork.linuxtv.org/project/linux-media/list/?series=7249
v2:
https://patchwork.linuxtv.org/project/linux-media/list/?series=7311
v3:
https://patchwork.linuxtv.org/project/linux-media/list/?series=7385
v4:
https://patchwork.linuxtv.org/project/linux-media/list/?series=7389
A branch for testing based on the most recent media-master is available at
https://git.sr.ht/~jmondi_/linux #jmondi/media-master/ov5640-v5
I tested these with DRA76 EVM & CAL, using CAL's legacy non-MC mode. It
doesn't work. I think there are two problems:
- CAL uses mbus codes like MEDIA_BUS_FMT_UYVY8_2X8 for CSI-2, not 1X16.
OV5640 used to support 2X8, but now it doesn't.
- OV5640 sets the default code to MEDIA_BUS_FMT_UYVY8_2X8, even for CSI-2
where it doesn't support MEDIA_BUS_FMT_UYVY8_2X8.
This might be worth an additional patch that decides what default
format to use based on the bus type.
I'd like to just change CAL and drop the 2X8 support and instead use 1X16,
but then any sensor that uses 2X8 would work. So I guess I need to change
the code to support both.
Anyway, both of those issues might also surface on other platforms, as
ov5640 behavior has changed.
I am facing the same "2X8" compatibility problem on ST platforms:
- st-mipid02 CSI-2 to parallel bridge [1] must be enhanced to support 1X16
formats
- dcmi controller [2] must also be enhanced to support 1X16 and extra code
to support 1X16 input to 2X8 output (as we only have as input the V4L2
format, not the mediabus one)
=> with current code, support with OV5640 is broken.
I feel that your proposal to let OV5640 accept 2X8 then silently switch to
1X16 can do the job without breaking dcmi/bridge support but need further
testing to confirm.
Appart from that I don't really understand the logic behind naming "1X16"
for CSI-2 serial formats, if "2X8" means 2 bytes to send one pixel, I would
expect that "1X16" means 1 word to send one pixel (16bits wide bus), so how
to differentiate 16 bits // code from CSI-2 code ?
Please see:
<URL:https://hverkuil.home.xs4all.nl/spec/userspace-api/v4l/subdev-formats.html#v4l2-mbus-pixelcode>
I.e. st-mipid02 and dcmi drivers should be fixed.
OK, so "single clock cycle" convention for serial bus (copy/paste here
for the sake of clarity):
4.13.3.4.1.1. Media Bus Pixel Codes
The media bus pixel codes document parallel formats. Should the pixel
data be transported over a serial bus, the media bus pixel code that
describes a parallel format that transfers a sample on a single clock
cycle is used. For instance, both MEDIA_BUS_FMT_BGR888_1X24 and
MEDIA_BUS_FMT_BGR888_3X8 are used on parallel busses for transferring an
8 bits per sample BGR data, whereas on serial busses the data in this
format is only referred to using MEDIA_BUS_FMT_BGR888_1X24. This is
because there is effectively only a single way to transport that format
on the serial busses.
I'll try to change both dcmi and mipid02 in that way...
Best regards,
Hugues.
