From: Petko Manolov <petko.manolov@konsulko.com>
To: Jacopo Mondi <jacopo@jmondi.org>
Cc: linux-media@vger.kernel.org,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Xavier Roumegue <xavier.roumegue@oss.nxp.com>
Subject: Re: imx8m-mini csi-2 limitations
Date: Thu, 1 Sep 2022 18:20:59 +0300 [thread overview]
Message-ID: <YxDN2+1chUENUeq6@p310.k.g> (raw)
In-Reply-To: <20220818105131.gurtn74av2ilr7bi@uno.localdomain>
On 22-08-18 12:51:31, Jacopo Mondi wrote:
>
<snip>
> If I recall correctly there are at least three configurations at play:
>
> - The CSIS pixel mode selection
>
> MIPI_CSI_ISP_CONFIG[13:12]
Funny enough adding MIPI_CSIS_ISPCFG_PIXEL_MODE_QUAD and
MIPI_CSIS_ISPCFG_ALIGN_32BIT to the config(0) register actually produced an
image. Highly distorted image, but did not break the image acquisition.
MIPI_CSIS_ISPCFG_ALIGN_32BIT seems to be the wrong flag here, but it without it
the streaming got blocked.
> 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
Actually the driver is always setting this one for raw10/12 formats.
> - CSI_CR18[20] MIPI_DOUBLE_CMP
Enabling this bit for raw10/12 formats kills the transmission. According to the
documentation this flag transfers full pixel per clock cycle as opposed to just
half a pixel.
> 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.
Seems like i have to find a way to make the mipi-csi stream full pixel (iow
16bit), if any such thing exists. And hope this configuration is supported
between both parts, mipi & bridge.
> 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)
In fact i was mimicking MEDIA_BUS_FMT_YUYV8_1X16 case, but as mentioned, this
didn't work. Seems like raw10/12 formats are not so well (if at all) handled by
the bridge.
> 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 used insanely big vblank and hblank values. Obtaining single frame took about
90 seconds. This indeed reduced "FIFO Overflow Error" and "Frame Size Error" to
four digit number (the lowest rate i've seen so far), but there was no visible
improvement in the captured test pattern image.
I doubt i can make the sensor stream slower and i also think it doesn't make
sense to go down this path - there are still errors.
Any advice on how to debug the CSI bridge? NXP support is as useless as ever.
cheers,
Petko
prev parent reply other threads:[~2022-09-01 15:16 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-15 13:52 imx8m-mini csi-2 limitations Petko Manolov
2022-08-18 9:27 ` Petko Manolov
2022-08-18 10:51 ` Jacopo Mondi
2022-08-18 12:41 ` Alexander Stein
2022-08-18 15:44 ` Petko Manolov
2022-08-18 15:37 ` Petko Manolov
2022-08-18 22:38 ` Laurent Pinchart
2022-09-01 15:20 ` Petko Manolov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YxDN2+1chUENUeq6@p310.k.g \
--to=petko.manolov@konsulko.com \
--cc=jacopo@jmondi.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
--cc=xavier.roumegue@oss.nxp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox