From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id CC839C433F5 for ; Mon, 7 Feb 2022 12:09:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Date:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=O5ZMrO4GDGAUOe0hPXg1g+awz5pZ/wnmlRy8ghVvxKw=; b=Z337elTXIqKWVv mPdvuNd8CpwnBzgVMvvlxMG767PAw9lL7grWDdpnEWJ4S+o/KW/6zJ55Yw0R59VQtdbp2jj0cufbI gdGiXblRdn+F3YGMFMwdoeILN105JYw81EbtcJAyHUx4KhI8Ovg20z0nkxRpqYfuHAHH8xeqxyKil z7fX3o6+B0L/IoCedrdpmYVu8febu28sFm0RDCjloORrxIbWct/QkOdoDeW0Fumu12bZndGYuOZOm EQ+217N5aNWHiRZtWNuMqUzffZh8I3S2PFDoxRiSX1alWXtoRDFtuYdESQCQOf0fa1GzTQWZAz+Uv bi1BAueMZC4k86cNYwrQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nH2on-00A6HQ-Cm; Mon, 07 Feb 2022 12:08:29 +0000 Received: from mx1.tq-group.com ([93.104.207.81]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nH2oj-00A6Fz-BT for linux-arm-kernel@lists.infradead.org; Mon, 07 Feb 2022 12:08:27 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tq-group.com; i=@tq-group.com; q=dns/txt; s=key1; t=1644235705; x=1675771705; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=m/q6pkb+TA7cRlY6xlVOjKQ4P8DeARpuUdX/+csSvX4=; b=f14r6hC+GWNIg43BlgdsxEU+W7yoNmO/sPMeAaLQk+DI2vXKqeVx6F96 6JrNQFLQRl+fgtQn5EJfjNL1nBdxqumJEZNozbxY+XiuqjPIHZe9DzCap +9KJD5onpV0hgwJbLE296rjKXmw4XpwE9ye/iSvmN1DPq56yT6zB4yleY s9RGH57P2ojZRobLnrlS1wgtxkN0dG146YDFerCN6hsNEE4iYiUuJqfJ1 HKvlgNMze5uTvwc5Xz+w4uh6AwsQQqTpC4OmMRsmUI0Lm754GixP36Meu Bs4AdbdR04tgJrPnOgBwZNHlTX0prRjWB9WIfECmWCCnsdgPTccu5FdBO g==; X-IronPort-AV: E=Sophos;i="5.88,349,1635199200"; d="scan'208";a="21932193" Received: from unknown (HELO tq-pgp-pr1.tq-net.de) ([192.168.6.15]) by mx1-pgp.tq-group.com with ESMTP; 07 Feb 2022 13:08:22 +0100 Received: from mx1.tq-group.com ([192.168.6.7]) by tq-pgp-pr1.tq-net.de (PGP Universal service); Mon, 07 Feb 2022 13:08:22 +0100 X-PGP-Universal: processed; by tq-pgp-pr1.tq-net.de on Mon, 07 Feb 2022 13:08:22 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tq-group.com; i=@tq-group.com; q=dns/txt; s=key1; t=1644235702; x=1675771702; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=m/q6pkb+TA7cRlY6xlVOjKQ4P8DeARpuUdX/+csSvX4=; b=R0fUFWOdFK8b/66rT4bIyhvoxx1Q9eS3yMCico9uy5oOjZcwpvbe3rJo yudGubxUWLbksbDBdikkQeOl59h9G8PHjwKyoqUyMTVia/RTXNTTDBhZ+ k3aKu3m7c3nljibsBMdpQQw/Gp9qE2d+ddYPj9IsXXUmQFIhtPAIwcKn9 otPfVvG1BPDeWlwqLtB8V5ORdujtn7bxEqCA912EUi6eoJmogVGRqdF41 E2bKKC8DgSrG6nRyUW2uKJbAaowxqPJvxmLKRhiaXGBHh15MazRU6aoTr icrdmshwsanwU4zaVZiQF6/B3Y2h7RVQU+dTFmByH8guu4S32pt0nQhKh A==; X-IronPort-AV: E=Sophos;i="5.88,349,1635199200"; d="scan'208";a="21932192" Received: from vtuxmail01.tq-net.de ([10.115.0.20]) by mx1.tq-group.com with ESMTP; 07 Feb 2022 13:08:22 +0100 Received: from steina-w.localnet (unknown [10.123.49.12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by vtuxmail01.tq-net.de (Postfix) with ESMTPSA id DE334280065; Mon, 7 Feb 2022 13:08:21 +0100 (CET) From: Alexander Stein To: Laurent Pinchart Cc: Steve Longerbeam , Philipp Zabel , Mauro Carvalho Chehab , Greg Kroah-Hartman , Shawn Guo , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , NXP Linux Team , Rui Miguel Silva , Dorota Czaplejewicz , linux-media@vger.kernel.org, linux-staging@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: (EXT) Re: [PATCH 3/8] media: imx: Use dedicated format handler for i.MX7/8 Date: Mon, 07 Feb 2022 13:08:21 +0100 Message-ID: <4044945.1IzOArtZ34@steina-w> Organization: TQ-Systems GmbH In-Reply-To: References: <20220204121514.2762676-1-alexander.stein@ew.tq-group.com> <20220204121514.2762676-4-alexander.stein@ew.tq-group.com> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220207_040825_795285_29609FFE X-CRM114-Status: GOOD ( 35.27 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Laurent, Am Samstag, 5. Februar 2022, 05:04:50 CET schrieb Laurent Pinchart: > Hi Alexander and Dorota, > > Thank you for the patch. > > On Fri, Feb 04, 2022 at 01:15:09PM +0100, Alexander Stein wrote: > > From: Dorota Czaplejewicz > > > > This splits out a format handler which takes into account > > the capabilities of the i.MX7/8 video device, > > as opposed to the default handler compatible with both i.MX5/6 and > > i.MX7/8. > > > > Signed-off-by: Dorota Czaplejewicz > > Signed-off-by: Alexander Stein > > --- > > Changes in comparison to original commit from Dorota: > > * is_imx56 is used instead of enum > > > > drivers/staging/media/imx/imx-media-utils.c | 56 +++++++++++++++++++-- > > 1 file changed, 52 insertions(+), 4 deletions(-) > > > > diff --git a/drivers/staging/media/imx/imx-media-utils.c > > b/drivers/staging/media/imx/imx-media-utils.c index > > 0daa6aad45f4..32aaa2e81bea 100644 > > --- a/drivers/staging/media/imx/imx-media-utils.c > > +++ b/drivers/staging/media/imx/imx-media-utils.c > > @@ -516,10 +516,9 @@ void imx_media_try_colorimetry(struct > > v4l2_mbus_framefmt *tryfmt,> > > } > > EXPORT_SYMBOL_GPL(imx_media_try_colorimetry); > > > > -int imx_media_mbus_fmt_to_pix_fmt(struct v4l2_pix_format *pix, > > - const struct v4l2_mbus_framefmt *mbus, > > - const struct imx_media_pixfmt *cc, > > - bool is_imx56) > > +static int imx56_media_mbus_fmt_to_pix_fmt(struct v4l2_pix_format *pix, > > + const struct v4l2_mbus_framefmt *mbus, > > + const struct imx_media_pixfmt *cc) > > > > { > > > > u32 width; > > u32 stride; > > > > @@ -568,6 +567,55 @@ int imx_media_mbus_fmt_to_pix_fmt(struct > > v4l2_pix_format *pix,> > > return 0; > > > > } > > > > + > > +static int imx78_media_mbus_fmt_to_pix_fmt(struct v4l2_pix_format *pix, > > + const struct v4l2_mbus_framefmt *mbus, > > + const struct imx_media_pixfmt *cc) > > +{ > > + int ret; > > + > > + if (!cc) > > + cc = imx_media_find_mbus_format(mbus->code, PIXFMT_SEL_ANY); > > + > > + if (!cc) > > + return -EINVAL; > > + /* > > + * The hardware can handle line lengths divisible by 4 pixels > > + * as long as the whole buffer size ends up divisible by 8 bytes. > > + * If not, use the value of 8 pixels recommended in the datasheet. > > + */ > > + ret = v4l2_fill_pixfmt(pix, cc->fourcc, > > + round_up(mbus->width, 4), mbus- >height); > > + if (ret) > > + return ret; > > + > > + /* Only 8bits-per-pixel formats may need to get aligned to 8 pixels, > > + * because both 10-bit and 16-bit pixels occupy 2 bytes. > > + * In those, 4-pixel aligmnent is equal to 8-byte alignment. > > + */ > > + if (pix->sizeimage % 8 != 0) > > + ret = v4l2_fill_pixfmt(pix, cc->fourcc, > > + round_up(mbus->width, 8), mbus->height); > > I think you could simplify this by using cc->bpp to figure out the > alignment instead of calling v4l2_fill_pixfmt() twice. Yeah, this should be possible. I can't test it (yet) though, I don't have a 8- Bit sensor. Will do in the next version. > > + pix->colorspace = mbus->colorspace; > > + pix->xfer_func = mbus->xfer_func; > > + pix->ycbcr_enc = mbus->ycbcr_enc; > > + pix->quantization = mbus->quantization; > > + pix->field = mbus->field; > > Should v4l2_fill_pixfmt() be updated to handle colorspace and field too > instead of doing it manually here ? I'm not so sure which parts of v4l2_pix_format shall be set into v4l2_fill_pixfmt(). Unfortunately there is no API description in the header, git log doesn't help much either. In the end this should be a separate patch. Best regards, Alexander > > + > > + return ret; > > +} > > + > > +int imx_media_mbus_fmt_to_pix_fmt(struct v4l2_pix_format *pix, > > + const struct v4l2_mbus_framefmt *mbus, > > + const struct imx_media_pixfmt *cc, > > + bool is_imx56) > > +{ > > + if (is_imx56) > > + return imx56_media_mbus_fmt_to_pix_fmt(pix, mbus, cc); > > + else > > + return imx78_media_mbus_fmt_to_pix_fmt(pix, mbus, cc); > > +} > > > > EXPORT_SYMBOL_GPL(imx_media_mbus_fmt_to_pix_fmt); > > > > void imx_media_free_dma_buf(struct device *dev, _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel