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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2358CC43217 for ; Mon, 7 Nov 2022 17:00:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231461AbiKGRAp (ORCPT ); Mon, 7 Nov 2022 12:00:45 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52828 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232349AbiKGRAo (ORCPT ); Mon, 7 Nov 2022 12:00:44 -0500 Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DDA0F22B08 for ; Mon, 7 Nov 2022 09:00:42 -0800 (PST) Received: by mail-io1-xd2c.google.com with SMTP id r81so9380662iod.2 for ; Mon, 07 Nov 2022 09:00:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amarulasolutions.com; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Zi1AzIotPjgee1WjMW/2lCnRF/Zux4fjSan/PWGqHXA=; b=Xyo5lSyER8B3jdtAksNfx+B+WXHa0Vd92xoDyHv20BXD948TTavHtQ6gVlUn5975MT /X0K0Im48+7tuE3VoRDQwITfanwbDtN0x9Ka1qkNZV3BsOQluTZa0z0pnKnMt/m7dWFB TtCguRYCO40UKwcLjAgQGeEZjdUHmQRwcewq4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Zi1AzIotPjgee1WjMW/2lCnRF/Zux4fjSan/PWGqHXA=; b=GksMj3AqdFv5nE8dmxd0vGBMX6daa1nDxVMwpXbIplMcPkgXDuSzskafiLA9hWxQEs J24fIED+5ItdMtdwNnseDlKrwo+u08gGNsfvThDJLAOvKTNnSP4mIDMk/sG5to71YVSy BH2AeDQK7fVXTGcNqh6CHJRSBoiSVH4sQwzYVfxzkTTxWbBEG5k7N3tvnPEwSzsGuB+h aoKlrpv+g5tTVTaz2kAjue4UZDcdiW8QZPeP4b0ZcBj/ps0N4NHwVKmgmJ9HYKkWYUcZ oR8tPSdYq+QpCAvuzgAh4ERSx40dH5NM8Xe4b4wNAbtPHsZCXGENb9bDphZ1422JnVFg EDSg== X-Gm-Message-State: ACrzQf3EtONixeeIMrOT7wFjqyvnQ0sEFp4CB2Zqh/6iwSMGWLUNUzDa pFxQEdUCl4qra7Iiy18b+AKgEez+4i/bQtzWOHOWSg== X-Google-Smtp-Source: AMsMyM4HLKgn0Ui+fGxorZRefXlugK/s+o0o8HaeQEbFJ88dHtP+XquF7Q74DteCHkWU3Z573Mt+tw1NKgeel5+aJSA= X-Received: by 2002:a5e:9e0a:0:b0:6c0:dbd0:cfac with SMTP id i10-20020a5e9e0a000000b006c0dbd0cfacmr31120387ioq.106.1667840442185; Mon, 07 Nov 2022 09:00:42 -0800 (PST) MIME-Version: 1.0 References: <20221005151309.7278-1-jagan@amarulasolutions.com> <20221005151309.7278-8-jagan@amarulasolutions.com> <9262c207-2b72-6638-0274-0ce1d0d830c9@denx.de> <2f0c2dae-07c9-814b-a252-5fdd3e0d9dda@denx.de> In-Reply-To: <2f0c2dae-07c9-814b-a252-5fdd3e0d9dda@denx.de> From: Jagan Teki Date: Mon, 7 Nov 2022 22:30:30 +0530 Message-ID: Subject: Re: [PATCH v7 07/10] drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts To: Marek Vasut Cc: Andrzej Hajda , Inki Dae , Marek Szyprowski , Joonyoung Shim , Seung-Woo Kim , Kyungmin Park , Frieder Schrempf , Fancy Fang , Tim Harvey , Michael Nazzareno Trimarchi , Adam Ford , Neil Armstrong , Robert Foss , Laurent Pinchart , Tommaso Merciai , Matteo Lisi , dri-devel@lists.freedesktop.org, linux-samsung-soc@vger.kernel.org, linux-arm-kernel@lists.infradead.org, NXP Linux Team , linux-amarula Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-samsung-soc@vger.kernel.org Hi Marek, On Fri, Nov 4, 2022 at 12:28 AM Marek Vasut wrote: > > On 11/3/22 18:27, Jagan Teki wrote: > > On Thu, Nov 3, 2022 at 9:56 PM Marek Vasut wrote: > >> > >> On 11/3/22 10:39, Jagan Teki wrote: > >>> On Sun, Oct 16, 2022 at 3:31 AM Marek Vasut wrote: > >>>> > >>>> On 10/5/22 17:13, Jagan Teki wrote: > >>>> > >>>> [...] > >>>> > >>>>> @@ -1321,6 +1322,32 @@ static void samsung_dsim_atomic_post_disable(struct drm_bridge *bridge, > >>>>> pm_runtime_put_sync(dsi->dev); > >>>>> } > >>>>> > >>>>> +#define MAX_INPUT_SEL_FORMATS 1 > >>>>> + > >>>>> +static u32 * > >>>>> +samsung_dsim_atomic_get_input_bus_fmts(struct drm_bridge *bridge, > >>>>> + struct drm_bridge_state *bridge_state, > >>>>> + struct drm_crtc_state *crtc_state, > >>>>> + struct drm_connector_state *conn_state, > >>>>> + u32 output_fmt, > >>>>> + unsigned int *num_input_fmts) > >>>>> +{ > >>>>> + u32 *input_fmts; > >>>>> + > >>>>> + *num_input_fmts = 0; > >>>>> + > >>>>> + input_fmts = kcalloc(MAX_INPUT_SEL_FORMATS, sizeof(*input_fmts), > >>>>> + GFP_KERNEL); > >>>>> + if (!input_fmts) > >>>>> + return NULL; > >>>>> + > >>>>> + /* This is the DSI-end bus format */ > >>>>> + input_fmts[0] = MEDIA_BUS_FMT_RGB888_1X24; > >>>>> + *num_input_fmts = 1; > >>>> > >>>> Is this the only supported format ? NXP AN13573 lists the following: > >>>> > >>>> i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022 > >>>> 3.7.4 Pixel formats > >>>> Table 14. DSI pixel packing formats > >>>> > >>>> Loosely Packed Pixel Stream, 20-bit YCbCr, 4:2:2 > >>>> Packed Pixel Stream, 24-bit YCbCr, 4:2:2 > >>>> Packed Pixel Stream, 16-bit YCbCr, 4:2:2 > >>> > >>> Look like these are unsupported in media-bus-format.h list. > >> > >> Aren't those: > >> > >> MEDIA_BUS_FMT_UYVY12_1X24 > > > > Why is UYVY12 - YCbCr, 4:2:2 is 4+2+2 = 8 then it has UYVY8 ? > > (someone please correct me if I'm totally wrong here) > > The 12 is channel width (12 bit for each Y1/Y2/U/V channel sample). > The 4:2:2 is subsampling (where are the color components sampled > relative to brightness component). > > Picture is here: > https://upload.wikimedia.org/wikipedia/commons/f/f2/Common_chroma_subsampling_ratios.svg > > Each Y square of the left is 12bit sample. > Each U+V square is 12bit sample for U and 12bit sample for V. > > In case of 4:4:4 subsampling, each luminance (brightness) component has > matching chrominance (color) components. > > In case of the 4:2:2 subsampling, two neighboring luminance components > share two chrominance components. To transfer one pixel including color > information, you have to transfer two pixels, Y0+U as 2x12bit sample in > one cycle of 24bit bus, and then Y1+V as 2x12bit sample in another cycle > of 24bit bus (2 clock cycles total, 4 samples total). From that you can > reconstruct the two top-left squares (purple pixels) in the rightmost > YUV column of 4:2:2 row. > > The entire trick is that because eye is less sensitive to color than it > is to light, you can transfer less color information and thus save > bandwidth without anyone noticing (much of it). > > >> MEDIA_BUS_FMT_UYVY8_1X16 > > > > If YCbCr is UYVY (I still don't get this notation, sorry) then Packed > > Pixel Stream, 24-bit YCbCr, 4:2:2 with 2 Pixels per packet from Table > > 14 can be > > > > MEDIA_BUS_FMT_UYVY8_2X24 > > (YCbCr 4:2:2 is UYVY8) > > > > " based on a reference example from media bus format doc > > 4.13.3.4.1.1.3. Packed YUV Formats, For instance, a format where > > pixels are encoded as 8-bit YUV values downsampled to 4:2:2 and > > transferred as 2 8-bit bus samples per pixel in the U, Y, V, Y order > > will be named MEDIA_BUS_FMT_UYVY8_2X8." > > The way I read the above is that the channel width of each channel is > 8-bit , so you start with two pixels Y0/U/Y1/V which add up to 32bit > total. That is transferred over 8-bit bus, in 4 bus cycles total. One > pixel therefore takes 2 cycles of the 8 bit bus to transfer, even if you > cannot transfer one pixel separately . > > > https://www.kernel.org/doc/html/latest/userspace-api/media/v4l/subdev-formats.html > > > > _2X24 here 2 Pixels per packet is the exact packets to consider or we > > can consider 1 Pixel per packet also. If later is true then _1X24 from > > your notation is correct. > > Since the DSIM input bus is 32bit wide, to transfer one such 4:2:2 > pixel, you need 1 bus cycle (2x12 bits per half of two pixels). Thanks for your explanation. I need some time to understand and it looks worth waiting for others to comment on this. Meanwhile, I'm planning to send subsequent version patches with possible supported formats like, MEDIA_BUS_FMT_UYVY8_1X16, MEDIA_BUS_FMT_RGB101010_1X30, MEDIA_BUS_FMT_RGB121212_1X36, MEDIA_BUS_FMT_RGB565_1X16, MEDIA_BUS_FMT_RGB666_1X18, MEDIA_BUS_FMT_RGB888_1X24, Let me know. Jagan. 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 gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (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 576C2C433FE for ; Mon, 7 Nov 2022 17:00:48 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 5601B10E4C0; Mon, 7 Nov 2022 17:00:45 +0000 (UTC) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) by gabe.freedesktop.org (Postfix) with ESMTPS id 057FC10E4BA for ; Mon, 7 Nov 2022 17:00:42 +0000 (UTC) Received: by mail-io1-xd33.google.com with SMTP id p141so9372270iod.6 for ; Mon, 07 Nov 2022 09:00:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amarulasolutions.com; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Zi1AzIotPjgee1WjMW/2lCnRF/Zux4fjSan/PWGqHXA=; b=Xyo5lSyER8B3jdtAksNfx+B+WXHa0Vd92xoDyHv20BXD948TTavHtQ6gVlUn5975MT /X0K0Im48+7tuE3VoRDQwITfanwbDtN0x9Ka1qkNZV3BsOQluTZa0z0pnKnMt/m7dWFB TtCguRYCO40UKwcLjAgQGeEZjdUHmQRwcewq4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Zi1AzIotPjgee1WjMW/2lCnRF/Zux4fjSan/PWGqHXA=; b=BjTY3/tPq5dulEFcD+Nh72wEj2Ge3TrfhMJ/hI4dCT5px6VR4SJFrSF+7Au0a94EUr aGSfgBmqRLZili5r4g20MpIH1vRfpj8aXNagfhofyUsxbBeKA/cMnnbbsizM8ST4vz2A Qzj9PA/aMXPBRTsby5fqZrL5q7Fdoiwf58wkdLzhDunkfYFXEwHGBl1PNMOlQ7u+661+ y4yk1UbPuGgoYxEXPeOky2QDd9HWSCwZOXDTflTqoEZKxWfRz7u5DagQl5YRa76KrmhB J3NZPQk59Lk0uQjl3dcQoB3thm50IFeShC8sWjTmVQjkmSgqaBW/e/WyVd/kBjvM4WdJ ir9w== X-Gm-Message-State: ACrzQf0lSGhHcN9NC+LjFfn7Ep1WW1n2M5TspLGAiTLd/gaWA2Q0hEpI s3+96F962yj85ymKAN8yCQYXO0pvz0OwaClaqEbEXQ== X-Google-Smtp-Source: AMsMyM4HLKgn0Ui+fGxorZRefXlugK/s+o0o8HaeQEbFJ88dHtP+XquF7Q74DteCHkWU3Z573Mt+tw1NKgeel5+aJSA= X-Received: by 2002:a5e:9e0a:0:b0:6c0:dbd0:cfac with SMTP id i10-20020a5e9e0a000000b006c0dbd0cfacmr31120387ioq.106.1667840442185; Mon, 07 Nov 2022 09:00:42 -0800 (PST) MIME-Version: 1.0 References: <20221005151309.7278-1-jagan@amarulasolutions.com> <20221005151309.7278-8-jagan@amarulasolutions.com> <9262c207-2b72-6638-0274-0ce1d0d830c9@denx.de> <2f0c2dae-07c9-814b-a252-5fdd3e0d9dda@denx.de> In-Reply-To: <2f0c2dae-07c9-814b-a252-5fdd3e0d9dda@denx.de> From: Jagan Teki Date: Mon, 7 Nov 2022 22:30:30 +0530 Message-ID: Subject: Re: [PATCH v7 07/10] drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts To: Marek Vasut Content-Type: text/plain; charset="UTF-8" X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: dri-devel@lists.freedesktop.org, linux-samsung-soc@vger.kernel.org, Laurent Pinchart , Joonyoung Shim , Tommaso Merciai , linux-amarula , Seung-Woo Kim , Neil Armstrong , Frieder Schrempf , Kyungmin Park , Matteo Lisi , Robert Foss , Andrzej Hajda , NXP Linux Team , Fancy Fang , Michael Nazzareno Trimarchi , Adam Ford , linux-arm-kernel@lists.infradead.org, Marek Szyprowski Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Hi Marek, On Fri, Nov 4, 2022 at 12:28 AM Marek Vasut wrote: > > On 11/3/22 18:27, Jagan Teki wrote: > > On Thu, Nov 3, 2022 at 9:56 PM Marek Vasut wrote: > >> > >> On 11/3/22 10:39, Jagan Teki wrote: > >>> On Sun, Oct 16, 2022 at 3:31 AM Marek Vasut wrote: > >>>> > >>>> On 10/5/22 17:13, Jagan Teki wrote: > >>>> > >>>> [...] > >>>> > >>>>> @@ -1321,6 +1322,32 @@ static void samsung_dsim_atomic_post_disable(struct drm_bridge *bridge, > >>>>> pm_runtime_put_sync(dsi->dev); > >>>>> } > >>>>> > >>>>> +#define MAX_INPUT_SEL_FORMATS 1 > >>>>> + > >>>>> +static u32 * > >>>>> +samsung_dsim_atomic_get_input_bus_fmts(struct drm_bridge *bridge, > >>>>> + struct drm_bridge_state *bridge_state, > >>>>> + struct drm_crtc_state *crtc_state, > >>>>> + struct drm_connector_state *conn_state, > >>>>> + u32 output_fmt, > >>>>> + unsigned int *num_input_fmts) > >>>>> +{ > >>>>> + u32 *input_fmts; > >>>>> + > >>>>> + *num_input_fmts = 0; > >>>>> + > >>>>> + input_fmts = kcalloc(MAX_INPUT_SEL_FORMATS, sizeof(*input_fmts), > >>>>> + GFP_KERNEL); > >>>>> + if (!input_fmts) > >>>>> + return NULL; > >>>>> + > >>>>> + /* This is the DSI-end bus format */ > >>>>> + input_fmts[0] = MEDIA_BUS_FMT_RGB888_1X24; > >>>>> + *num_input_fmts = 1; > >>>> > >>>> Is this the only supported format ? NXP AN13573 lists the following: > >>>> > >>>> i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022 > >>>> 3.7.4 Pixel formats > >>>> Table 14. DSI pixel packing formats > >>>> > >>>> Loosely Packed Pixel Stream, 20-bit YCbCr, 4:2:2 > >>>> Packed Pixel Stream, 24-bit YCbCr, 4:2:2 > >>>> Packed Pixel Stream, 16-bit YCbCr, 4:2:2 > >>> > >>> Look like these are unsupported in media-bus-format.h list. > >> > >> Aren't those: > >> > >> MEDIA_BUS_FMT_UYVY12_1X24 > > > > Why is UYVY12 - YCbCr, 4:2:2 is 4+2+2 = 8 then it has UYVY8 ? > > (someone please correct me if I'm totally wrong here) > > The 12 is channel width (12 bit for each Y1/Y2/U/V channel sample). > The 4:2:2 is subsampling (where are the color components sampled > relative to brightness component). > > Picture is here: > https://upload.wikimedia.org/wikipedia/commons/f/f2/Common_chroma_subsampling_ratios.svg > > Each Y square of the left is 12bit sample. > Each U+V square is 12bit sample for U and 12bit sample for V. > > In case of 4:4:4 subsampling, each luminance (brightness) component has > matching chrominance (color) components. > > In case of the 4:2:2 subsampling, two neighboring luminance components > share two chrominance components. To transfer one pixel including color > information, you have to transfer two pixels, Y0+U as 2x12bit sample in > one cycle of 24bit bus, and then Y1+V as 2x12bit sample in another cycle > of 24bit bus (2 clock cycles total, 4 samples total). From that you can > reconstruct the two top-left squares (purple pixels) in the rightmost > YUV column of 4:2:2 row. > > The entire trick is that because eye is less sensitive to color than it > is to light, you can transfer less color information and thus save > bandwidth without anyone noticing (much of it). > > >> MEDIA_BUS_FMT_UYVY8_1X16 > > > > If YCbCr is UYVY (I still don't get this notation, sorry) then Packed > > Pixel Stream, 24-bit YCbCr, 4:2:2 with 2 Pixels per packet from Table > > 14 can be > > > > MEDIA_BUS_FMT_UYVY8_2X24 > > (YCbCr 4:2:2 is UYVY8) > > > > " based on a reference example from media bus format doc > > 4.13.3.4.1.1.3. Packed YUV Formats, For instance, a format where > > pixels are encoded as 8-bit YUV values downsampled to 4:2:2 and > > transferred as 2 8-bit bus samples per pixel in the U, Y, V, Y order > > will be named MEDIA_BUS_FMT_UYVY8_2X8." > > The way I read the above is that the channel width of each channel is > 8-bit , so you start with two pixels Y0/U/Y1/V which add up to 32bit > total. That is transferred over 8-bit bus, in 4 bus cycles total. One > pixel therefore takes 2 cycles of the 8 bit bus to transfer, even if you > cannot transfer one pixel separately . > > > https://www.kernel.org/doc/html/latest/userspace-api/media/v4l/subdev-formats.html > > > > _2X24 here 2 Pixels per packet is the exact packets to consider or we > > can consider 1 Pixel per packet also. If later is true then _1X24 from > > your notation is correct. > > Since the DSIM input bus is 32bit wide, to transfer one such 4:2:2 > pixel, you need 1 bus cycle (2x12 bits per half of two pixels). Thanks for your explanation. I need some time to understand and it looks worth waiting for others to comment on this. Meanwhile, I'm planning to send subsequent version patches with possible supported formats like, MEDIA_BUS_FMT_UYVY8_1X16, MEDIA_BUS_FMT_RGB101010_1X30, MEDIA_BUS_FMT_RGB121212_1X36, MEDIA_BUS_FMT_RGB565_1X16, MEDIA_BUS_FMT_RGB666_1X18, MEDIA_BUS_FMT_RGB888_1X24, Let me know. Jagan. 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 EF239C4332F for ; Mon, 7 Nov 2022 17:02:12 +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:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=AXblqCFe9wAQmXw/T8ZGRXaprFqzel0G8xfZbfNdU1Y=; b=KHSoEL+gGsRJtM MRZ9q4DizcKwz323k5+7GhoXum3OyW7+CluwpNrRDKorPwpSBj/jqm/PgCiRz4bnXl9SkzLW4nPVa 8og1FwT5mOTo1yYWnK7SdZO4SXzIJuy8QIoc8SoyiCrDiThlx4dAUvvFJIjTxsNUrUfbkfV6OnAWd IlnSl5kOQ3h0MgPqIqJbC0aTAno1q81Mk3pWijx9ecLMp15NNGGvYhEefy4fB3eTAyifW8IPeauZR ca7rF1IC5FP/Q/JwVTFIVFSYpw32d44nEswcWXsbHWEr5GmJiYH/Kx3FKsD2ktZ6asD1Vnoynvn+E ljvcfwfoYKIiJ6vwRLAA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1os5UQ-00GTR3-Pd; Mon, 07 Nov 2022 17:00:50 +0000 Received: from mail-io1-xd2d.google.com ([2607:f8b0:4864:20::d2d]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1os5UN-00GTQ2-8l for linux-arm-kernel@lists.infradead.org; Mon, 07 Nov 2022 17:00:49 +0000 Received: by mail-io1-xd2d.google.com with SMTP id 11so9405599iou.0 for ; Mon, 07 Nov 2022 09:00:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amarulasolutions.com; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Zi1AzIotPjgee1WjMW/2lCnRF/Zux4fjSan/PWGqHXA=; b=Xyo5lSyER8B3jdtAksNfx+B+WXHa0Vd92xoDyHv20BXD948TTavHtQ6gVlUn5975MT /X0K0Im48+7tuE3VoRDQwITfanwbDtN0x9Ka1qkNZV3BsOQluTZa0z0pnKnMt/m7dWFB TtCguRYCO40UKwcLjAgQGeEZjdUHmQRwcewq4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Zi1AzIotPjgee1WjMW/2lCnRF/Zux4fjSan/PWGqHXA=; b=qk44AoWklW0gQzcrLMnl4mvRqMoNLuERRU+yrHRaVYD4ZUq9Es/YaPaTEQhvQh3Kd/ Zn+EOX5dMpwd7coGy6bW0oo3TF3ZPy0SRE5fB8ym5lWjpfugv25eblpsHVZzSPaYtXE6 gbZeveTZY9xp/YXL5K5zCXOG0vy1sdyKcCefvUd5L0Gar46kuI2/g0O2BStli+mSiv4c tDYwSsAoCs0Duf4h7E47TYiD3f/1I5Tq9aC59WhOqiihtn8m2aw/fM7RKg8LBAVVRpe5 oXvE8pWcSTXzzpkjtPjmbHp6JknJthGfCiCKNgcXnqWAFYlwjh/VBkZnCl0sZfF2B1LL W6BA== X-Gm-Message-State: ACrzQf0i+vKK8OsT48tRHWK47dxkPkm6jLotzSxeOFw0AD6/xBV87yR4 79fBTEkCrFr2r7QMAmgWlwg/IT+0c0zYl/zhbZvaUg== X-Google-Smtp-Source: AMsMyM4HLKgn0Ui+fGxorZRefXlugK/s+o0o8HaeQEbFJ88dHtP+XquF7Q74DteCHkWU3Z573Mt+tw1NKgeel5+aJSA= X-Received: by 2002:a5e:9e0a:0:b0:6c0:dbd0:cfac with SMTP id i10-20020a5e9e0a000000b006c0dbd0cfacmr31120387ioq.106.1667840442185; Mon, 07 Nov 2022 09:00:42 -0800 (PST) MIME-Version: 1.0 References: <20221005151309.7278-1-jagan@amarulasolutions.com> <20221005151309.7278-8-jagan@amarulasolutions.com> <9262c207-2b72-6638-0274-0ce1d0d830c9@denx.de> <2f0c2dae-07c9-814b-a252-5fdd3e0d9dda@denx.de> In-Reply-To: <2f0c2dae-07c9-814b-a252-5fdd3e0d9dda@denx.de> From: Jagan Teki Date: Mon, 7 Nov 2022 22:30:30 +0530 Message-ID: Subject: Re: [PATCH v7 07/10] drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts To: Marek Vasut Cc: Andrzej Hajda , Inki Dae , Marek Szyprowski , Joonyoung Shim , Seung-Woo Kim , Kyungmin Park , Frieder Schrempf , Fancy Fang , Tim Harvey , Michael Nazzareno Trimarchi , Adam Ford , Neil Armstrong , Robert Foss , Laurent Pinchart , Tommaso Merciai , Matteo Lisi , dri-devel@lists.freedesktop.org, linux-samsung-soc@vger.kernel.org, linux-arm-kernel@lists.infradead.org, NXP Linux Team , linux-amarula X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221107_090047_385724_BB67AD59 X-CRM114-Status: GOOD ( 31.18 ) 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 Marek, On Fri, Nov 4, 2022 at 12:28 AM Marek Vasut wrote: > > On 11/3/22 18:27, Jagan Teki wrote: > > On Thu, Nov 3, 2022 at 9:56 PM Marek Vasut wrote: > >> > >> On 11/3/22 10:39, Jagan Teki wrote: > >>> On Sun, Oct 16, 2022 at 3:31 AM Marek Vasut wrote: > >>>> > >>>> On 10/5/22 17:13, Jagan Teki wrote: > >>>> > >>>> [...] > >>>> > >>>>> @@ -1321,6 +1322,32 @@ static void samsung_dsim_atomic_post_disable(struct drm_bridge *bridge, > >>>>> pm_runtime_put_sync(dsi->dev); > >>>>> } > >>>>> > >>>>> +#define MAX_INPUT_SEL_FORMATS 1 > >>>>> + > >>>>> +static u32 * > >>>>> +samsung_dsim_atomic_get_input_bus_fmts(struct drm_bridge *bridge, > >>>>> + struct drm_bridge_state *bridge_state, > >>>>> + struct drm_crtc_state *crtc_state, > >>>>> + struct drm_connector_state *conn_state, > >>>>> + u32 output_fmt, > >>>>> + unsigned int *num_input_fmts) > >>>>> +{ > >>>>> + u32 *input_fmts; > >>>>> + > >>>>> + *num_input_fmts = 0; > >>>>> + > >>>>> + input_fmts = kcalloc(MAX_INPUT_SEL_FORMATS, sizeof(*input_fmts), > >>>>> + GFP_KERNEL); > >>>>> + if (!input_fmts) > >>>>> + return NULL; > >>>>> + > >>>>> + /* This is the DSI-end bus format */ > >>>>> + input_fmts[0] = MEDIA_BUS_FMT_RGB888_1X24; > >>>>> + *num_input_fmts = 1; > >>>> > >>>> Is this the only supported format ? NXP AN13573 lists the following: > >>>> > >>>> i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022 > >>>> 3.7.4 Pixel formats > >>>> Table 14. DSI pixel packing formats > >>>> > >>>> Loosely Packed Pixel Stream, 20-bit YCbCr, 4:2:2 > >>>> Packed Pixel Stream, 24-bit YCbCr, 4:2:2 > >>>> Packed Pixel Stream, 16-bit YCbCr, 4:2:2 > >>> > >>> Look like these are unsupported in media-bus-format.h list. > >> > >> Aren't those: > >> > >> MEDIA_BUS_FMT_UYVY12_1X24 > > > > Why is UYVY12 - YCbCr, 4:2:2 is 4+2+2 = 8 then it has UYVY8 ? > > (someone please correct me if I'm totally wrong here) > > The 12 is channel width (12 bit for each Y1/Y2/U/V channel sample). > The 4:2:2 is subsampling (where are the color components sampled > relative to brightness component). > > Picture is here: > https://upload.wikimedia.org/wikipedia/commons/f/f2/Common_chroma_subsampling_ratios.svg > > Each Y square of the left is 12bit sample. > Each U+V square is 12bit sample for U and 12bit sample for V. > > In case of 4:4:4 subsampling, each luminance (brightness) component has > matching chrominance (color) components. > > In case of the 4:2:2 subsampling, two neighboring luminance components > share two chrominance components. To transfer one pixel including color > information, you have to transfer two pixels, Y0+U as 2x12bit sample in > one cycle of 24bit bus, and then Y1+V as 2x12bit sample in another cycle > of 24bit bus (2 clock cycles total, 4 samples total). From that you can > reconstruct the two top-left squares (purple pixels) in the rightmost > YUV column of 4:2:2 row. > > The entire trick is that because eye is less sensitive to color than it > is to light, you can transfer less color information and thus save > bandwidth without anyone noticing (much of it). > > >> MEDIA_BUS_FMT_UYVY8_1X16 > > > > If YCbCr is UYVY (I still don't get this notation, sorry) then Packed > > Pixel Stream, 24-bit YCbCr, 4:2:2 with 2 Pixels per packet from Table > > 14 can be > > > > MEDIA_BUS_FMT_UYVY8_2X24 > > (YCbCr 4:2:2 is UYVY8) > > > > " based on a reference example from media bus format doc > > 4.13.3.4.1.1.3. Packed YUV Formats, For instance, a format where > > pixels are encoded as 8-bit YUV values downsampled to 4:2:2 and > > transferred as 2 8-bit bus samples per pixel in the U, Y, V, Y order > > will be named MEDIA_BUS_FMT_UYVY8_2X8." > > The way I read the above is that the channel width of each channel is > 8-bit , so you start with two pixels Y0/U/Y1/V which add up to 32bit > total. That is transferred over 8-bit bus, in 4 bus cycles total. One > pixel therefore takes 2 cycles of the 8 bit bus to transfer, even if you > cannot transfer one pixel separately . > > > https://www.kernel.org/doc/html/latest/userspace-api/media/v4l/subdev-formats.html > > > > _2X24 here 2 Pixels per packet is the exact packets to consider or we > > can consider 1 Pixel per packet also. If later is true then _1X24 from > > your notation is correct. > > Since the DSIM input bus is 32bit wide, to transfer one such 4:2:2 > pixel, you need 1 bus cycle (2x12 bits per half of two pixels). Thanks for your explanation. I need some time to understand and it looks worth waiting for others to comment on this. Meanwhile, I'm planning to send subsequent version patches with possible supported formats like, MEDIA_BUS_FMT_UYVY8_1X16, MEDIA_BUS_FMT_RGB101010_1X30, MEDIA_BUS_FMT_RGB121212_1X36, MEDIA_BUS_FMT_RGB565_1X16, MEDIA_BUS_FMT_RGB666_1X18, MEDIA_BUS_FMT_RGB888_1X24, Let me know. Jagan. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel