On 22-08-18 12:51:31, Jacopo Mondi wrote: > Hi Petko > > On Thu, Aug 18, 2022 at 12:27:45PM +0300, Petko Manolov wrote: > > Hello again, > > > > After digging down NXP's documentation and reading some comments within > > kernel drivers (sorry Jacopo, you've left some nice comments in > > imx7-media-csi.c, hence you're spammed now :) i came to the conclusion that > > mipi-csi to csi-bridge data > > No worries. > > I tried re-reading all the discussions, but memory still fails me here. > > I recall I had an issue with the CSIS bandwidth and somewhere I suggested that > it might be due to the CSI-2 specification version that the peripheral > implemented. I can't find that email anymore though :/ Well, only bumping up the frequency (to 1ghz) between the CSIS and bridge does not work out of the box. The latter stopped generating IRQs, which kind of ruined the day for me. It would be better if i know if that's at all possible, before start debugging the issue. > Yes, there has been quite some discussions about how to mix-and-match the > settings between the CSIS (mipi-csi) and the CSI (csi-bridge) [*] > > If I recall correctly there are at least three configurations at play: > > - The CSIS pixel mode selection > > MIPI_CSI_ISP_CONFIG[13:12] Got this one. > The driver currently forces dual pixel sampling mode for YUV422 and report a > TODO: > > * TODO: Verify which other formats require DUAL (or QUAD) modes. > > Here you're trying to transfer RAW12 data, which is indicated in the > register documentation as one of the formats suitable for DUAL/QUAD mode > transfer > > - I'm actually not sure how and if RAW12 gets expanded to 16 bit samples by > filling the 16-bit word with 0s or it either gets packed in 6 bytes with > no paddings. Figure "13-33. Pixel alignment" seems to suggest that, but > I'm not sure I really got that diagram > > - The CSI-bridge > > - CSI_CR3[3] SENSOR_16BITS > - CSI_CR18[20] MIPI_DOUBLE_CMP Ah, i did not set CSI_CR3 when i (quickly) tried to go to 16bit data width. I'll give it another try based on the above. > The comment in imx7_csi_configure() explains how different versions of YUYV > (2X8 and 1X16) are handled, and why SENSOR_16BITS and MIPI_DOUBLE_CMP have > to be enabled when the csi-bridge has to be instructed to sample 16 bits > samples from the RX queue. OK. > I guess the key would be here to find out what combination of SINGLE/DUAL/QUAD > sampling is opportune for RAW12 (I would try with DUAL first and then QUAD) > and then configure the csi-bridge bus sampling mode accordingly (likely in the > same was as it is done for YUYV_1X16) I've come across this comment in imx-mipi-csis.c left by you earlier this year: "Neither of the IP cores connected to the CSIS in i.MX SoCs (CSI bridge or ISI) support quad pixel mode, so this will never work in practice." I guess, if true, it doesn't make sense to waste time on quad mode. > When it comes to bandwidth limitation, can you try to reduce the sensor output > size to make sure you chase one issue at the time ? I am at Sony's mercy here. The datasheed it full of holes and i get feeded small bits of information at irregular intervals. I asked them to provide me with register setup for much slower data rate & pixel clock (at full speed the damn thing is streaming at almost 7gbps), but i'm still waiting... > [*] Is "CSI" the most abused acronym of history ? Maybe. I already hate spelling this acronym even in my mind. :) > > So i guess there are two questions: > > > > a) can the csi-bridge (and mipi-csi) be persuaded to do two-bytes for > > raw12 format; > > See above :) > > > b) what's the maximum frequency for csi-bridge PIXCLK? > > > > Not sure about this one. > > I've anyway cc-ed Laurent and Xavier, which can surely be helpful here Thanks a bunch, the above information is very helpful. cheers, Petko
