Hi Steve !
Thanks for answering !
Le mar. 15 janv. 2019 à 01:54, Steve Longerbeam
<slongerbeam@xxxxxxxxx> a écrit :
>
> 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.
You are right, and in fact I was thinking of IDMAC while writing :s
> 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")
It is the correct issue, but what I didn't mention is that I was on a
4.14, and not the most recent, and burst_size is set to 8.
The commit 37ea9830139b3 has been introduced later, and so I didn't have it...
The commit is not explicit though, as it mentions IMX219 and not i.MX6.
But it works with 16 ;).
Thanks,
JM
