From: Petko Manolov <petko.manolov@konsulko.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Alexander Stein <alexander.stein@ew.tq-group.com>,
linux-media@vger.kernel.org, jacopo@jmondi.org
Subject: Re: Re: Re: hooking Sony 47MPixel sensor to NXP imx8m-mini MIPI CSI2
Date: Thu, 7 Jul 2022 15:17:51 +0300 [thread overview]
Message-ID: <YsbO74eGybz7uFBe@carbon.gago.life> (raw)
In-Reply-To: <YsYC6eMtotq7FR2i@pendragon.ideasonboard.com>
On 22-07-07 00:47:21, Laurent Pinchart wrote:
>
> MEDIA_BUS_FMT_* are media bus formats, they describe the format of data as it
> gets transmitted on buses between entities. The main purposes of those formats
> are configuration of entities in the pipeline (an IP core will need to be
> configured differently if it receives 10-bit raw data or 12-bit raw data for
> instance), and validation of the pipeline configuration (the format on the
> output of an entity must match the format on the input of the next entity).
>
> V4L2_PIX_FMT_* are pixel formats, and they describe the format of data as
> stored in memory. They're only meaningful for the DMA engines at the end of
> the pipeline, and while they're related to the media bus formats (the DMA
> engine can't write to memory, for instance, V4L2_PIX_FMT_YUYV if it receives
> MEDIA_BUS_FMT_SGRBG10 from the previous entity), there's no fixed 1:1 mapping
> between the two formats. The mapping is device-dependent. For instance, a DMA
> engine that receives YUV 4:2:2 data in the form of MEDIA_BUS_FMT_YUYV8_1X16
> could support writing it in different pixel formats, such as
> V4L2_PIX_FMT_YUYV, V4L2_PIX_FMT_NV12, V4L2_PIX_FMT_NV16, ...
Thanks for these details.
I was wondering why V4L2_PIX_FMT_SGBRG12 would not be used for
MEDIA_BUS_FMT_SGBRG12_1X12 bus formats, but i guess the answer i can extract
from the info above is "device dependent".
> I have work in progress patches that address issues with the imx7-csi-bridge
> driver, once they land we could look into this. I'm afraid I'm a bit slow
> these days due to covid.
Quick recovery! Looking forward to these patches.
For me, changing VID_MEM_LIMIT to 512MB works OK for the moment. I am not yet
certain how this constant is related to the global CMA parameter. In the
default kernel config CMA is 32MB, while VID_MEM_LIMIT is 64MB. Isn't this
wrong?
Petko
next prev parent reply other threads:[~2022-07-07 12:17 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-29 7:55 hooking Sony 47MPixel sensor to NXP imx8m-mini MIPI CSI2 Petko Manolov
2022-06-29 8:28 ` Laurent Pinchart
2022-06-29 8:45 ` Petko Manolov
2022-06-30 0:50 ` Laurent Pinchart
2022-06-30 18:52 ` Petko Manolov
2022-06-30 19:42 ` Laurent Pinchart
2022-07-05 9:43 ` Petko Manolov
2022-07-05 12:30 ` Petko Manolov
2022-07-05 14:42 ` Alexander Stein
2022-07-05 15:13 ` Petko Manolov
2022-07-06 6:18 ` Alexander Stein
2022-07-06 13:07 ` Petko Manolov
2022-07-06 13:12 ` Alexander Stein
2022-07-06 13:51 ` Laurent Pinchart
2022-07-06 19:26 ` Petko Manolov
2022-07-06 20:07 ` Petko Manolov
2022-07-06 21:48 ` Laurent Pinchart
2022-07-07 12:20 ` Petko Manolov
2022-07-06 21:47 ` Laurent Pinchart
2022-07-07 12:17 ` Petko Manolov [this message]
2022-07-07 21:47 ` Laurent Pinchart
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=YsbO74eGybz7uFBe@carbon.gago.life \
--to=petko.manolov@konsulko.com \
--cc=alexander.stein@ew.tq-group.com \
--cc=jacopo@jmondi.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.