From: Sakari Ailus <sakari.ailus@linux.intel.com>
To: "Daniel Glöckner" <dg@emlix.com>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>,
linux-media@vger.kernel.org, hverkuil@xs4all.nl
Subject: Re: 14-bit pixel/media bus formats for i.MX8QM/QXP CSI
Date: Mon, 27 Jan 2020 13:46:08 +0200 [thread overview]
Message-ID: <20200127114608.GD21275@kekkonen.localdomain> (raw)
In-Reply-To: <3b44ea7d-76d1-1837-8373-4ac653a47a7b@emlix.com>
Hi Daniel,
On Mon, Jan 27, 2020 at 12:26:20PM +0100, Daniel Glöckner wrote:
> Hi Sakari,
>
> Am 01/27/20 um 11:42 schrieb Sakari Ailus:
> > On Fri, Jan 24, 2020 at 09:36:25PM +0100, Daniel Glöckner wrote:
> >> the i.MX8QM and i.MX8QXP contain MIPI CSI-2 controllers that forward the
> >> received data on a parallel bus to the Image Sensing Interface (ISI) of
> >> the chip. If the data on the MIPI bus is in any of the six RAW formats
> >> defined for CSI-2, the CSI controller will shift the values so that the
> >> msb is always in bit 13. This was most likely done to allow following
> >> hardware to process the data as RAW14 regardless of the actual RAW format.
> >> Unfortunately the ISI is not able to shift the bits back before writing it
> >> to memory. RAW8 data therefore has to be saved in two bytes per sample with
> >> two unused bits at the top and six unused bits at the bottom.
>
> >> - Is it acceptable to use MEDIA_BUS_FMT_Y14_1X14 in this case instead of
> >> using MEDIA_BUS_FMT_Y12_1X14_PADLO, MEDIA_BUS_FMT_Y10_1X14_PADLO,
> >> MEDIA_BUS_FMT_Y8_1X14_PADLO, MEDIA_BUS_FMT_Y7_1X14_PADLO,
> >> MEDIA_BUS_FMT_Y6_1X14_PADLO? Another 20 _PADLO formats would have to
> >> be added for Bayer.
> >
> > I think I'd say yes, you could do this, *if* you're fully certain you'll
> > *never* see this CSI-2 receiver paired with any other hardware than the
> > ISI, which is the case for instance if it's part of the same device. As if
> > there is hardware that can make use of the information on how many bits are
> > actually used there, you'd need to expose that information on the uAPI as
> > well. Changing that would be an uAPI change, something that should be
> > avoided if at all possible.
>
> Given that the NXP revealed that the MIPI DSI controller in the i.MX8 is from
> Northwest Logic and the block diagram for the MIPI CSI controller in NXP's
> reference manual looks like it was drawn by the same artist who drew the block
> diagram in Northwest Logic's DSI product brief, I suspect that the CSI
> controller is also an IP core from Northwest Logic. I believe the one currently
> advertized on their website is the successor. I don't have access to Northwest
> Logic's datasheet, so I can't compare the register layouts.
>
> Looking at the driver from NXP we can probably rule out that the driver will be
> used with anything else than NXP hardware. Half of the register accesses in that
> driver go to additional logic specific to the i.MX8 (CSR registers) and there is
What do those registers do, roughly?
> communication with the chip-internal Cortex-M4 to reset the CSI controller. NXP
Ouch.
> placed it into drivers/media/platform/imx8/.
Should I assume this CSI-2 receiver will have its own compatible string
specific to these two SoCs?
--
Regards,
Sakari Ailus
sakari.ailus@linux.intel.com
next prev parent reply other threads:[~2020-01-27 11:46 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-24 20:36 14-bit pixel/media bus formats for i.MX8QM/QXP CSI Daniel Glöckner
2020-01-27 10:42 ` Sakari Ailus
2020-01-27 11:26 ` Daniel Glöckner
2020-01-27 11:46 ` Sakari Ailus [this message]
2020-02-18 13:04 ` Daniel Glöckner
2020-01-27 12:13 ` Hans Verkuil
2020-02-18 1:34 ` Laurent Pinchart
2020-02-18 11:10 ` Daniel Glöckner
2020-02-24 17:52 ` [PATCH 1/3] media: v4l: Add 14-bit raw bayer pixel formats Daniel Glöckner
2020-02-26 15:14 ` Sakari Ailus
2020-02-24 17:52 ` [PATCH 2/3] media: v4l: Add 14-bit raw greyscale pixel format Daniel Glöckner
2020-02-24 17:52 ` [PATCH 3/3] media: v4l: Add 1X14 14-bit greyscale media bus code definition Daniel Glöckner
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=20200127114608.GD21275@kekkonen.localdomain \
--to=sakari.ailus@linux.intel.com \
--cc=dg@emlix.com \
--cc=hverkuil@xs4all.nl \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).