Re: i.MX6 RAW8 format

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi JM,

On 1/14/19 1:52 AM, Jean-Michel Hautbois wrote:
Hi,

I am currently using an upstream kernel on a i.MX6 Quad board, and I
have a strange issue.
The device I am using is able to produce RGB888 MIPI data, or RAW8/RAW10.
The MIPI data types are respectively 0x24, 0x2A and 0x2B.
When I configure the device to produce RGB888 data, everything is
fine, but when I configure it to produce RAW8 data, then the pattern
is weird.

I am sending the following pattern :
0x11 0x22 0x33 0x44 0x55 0x66 0x77 0x88 0x99 0xAA 0xBB 0xCC 0xDD 0xEE
0x11 0x22 0x33 0x44 0x55 0x66...
And I get in a raw file :
0x11 0x22 0x33 0x44 0x55 0x66 0x77 0x88 0x33 0x44 0x55 0x66 0x77 0x88 0x99 ...
The resulting raw file has the correct size (ie. 1280x720 bytes).

I could get a logic analyzer able to decode MIPI-CSI2 protocol, and on
this side, the pattern is complete, no data is lost, and the Datatype
is 0x2A.
It really looks like an issue on the i.MX6 side.

So, looking at it, I would say than for each 8 bytes captured, a jump
of 8 bytes is done ?

Sure looks that way.

The media-ctl is configured like this :
media-ctl -l "'ds90ub954 2-0034':0 -> 'imx6-mipi-csi2':0[1]" -v
media-ctl -l "'imx6-mipi-csi2':1 -> 'ipu1_csi0_mux':0[1]" -v
media-ctl -l "'ipu1_csi0_mux':2 -> 'ipu1_csi0':0[1]" -v
media-ctl -l "'ipu1_csi0':2 -> 'ipu1_csi0 capture':0[1]"
media-ctl -V "'ds90ub954 2-0034':0 [fmt:SBGGR8_1X8/1280x720 field:none]"
media-ctl -V "'imx6-mipi-csi2':1 [fmt:SBGGR8_1X8/1280x720 field:none]"
media-ctl -V "'ipu1_csi0_mux':2 [fmt:SBGGR8_1X8/1280x720 field:none]"
media-ctl -V "'ipu1_csi0':2 [fmt:SBGGR8_1X8/1280x720 field:none]"

The ds90ub954 driver I wrote is very dump and just used to give I²C
access and configure the deserializer to produce the pattern.
I also tried to use a camera, which produces RAW8 data, but the result
is the same, I don't get all my bytes, at least, not in the correct
order.

And the command used to capture a file is :
v4l2-ctl -d4 --set-fmt-video=width=1280,height=720,pixelformat=BA81
--stream-mmap --stream-count=1 --stream-to=/root/cam.raw

I can send the raw file if it is needed.
I tried several configurations, changing the number of lanes, the
frequency, etc. but I have the same behaviour.

So, I am right now stuck with this, as I can't see anything which
could explain this. IC burst ? Something else ?

The problem couldn't be IC burst size as the IC isn't involved in this pipeline.

One way I see this happening is that the IDMA channel burst writes 16 bytes to memory (so that the channel's read pointer advances by 16 bytes), but somehow the channel's write pointer has only advanced by 8 bytes.

I don't know how that could happen, but you might try reverting

37ea9830139b3 ("media: imx-csi: fix burst size")

which will restore IDMA channel burst size to 8 pixels (bytes) for SGBRG8, and see if that makes any difference.

Steve




[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux