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 4F90BC433FE for ; Wed, 16 Nov 2022 11:32:33 +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=9xkH0S1SzefyhBMQEiISlF+McqIUvXkEnzv6Yv3w6d4=; b=WFIDtSGoY53Kol SqUjuU5CT11tR1PEP9vJlII6kiM9Ffj/6xc3IVAW1mSsR57oeifmCj4qq7AvpauQrAufxStU8KnRu 6EJ6qwZKpF4Xa0+tEDoFwRfmK8QkZwq3ahU616umwBuB/RuguDwrzYYbNoU3dkiUdmyUNrzyN4Ak3 DQ7jwE4rdC4ROtRbN3BSSUErztbS8LqNdXnusZCBPoL3A/rm4D7iMQ+9UYM/s+r2wIFxNqWr2clQ5 2WX96dm852Qm0rH0IWHVwJBecj9pqmG2jCNEsR41tLMczy66K9d3+hy5EGv20XRFz5etMJDqEHRQU Ead7diUWE6k4I8E+tjsA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ovGco-002s2J-R2; Wed, 16 Nov 2022 11:30:38 +0000 Received: from mail-io1-xd33.google.com ([2607:f8b0:4864:20::d33]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1ovGck-002rzv-VY for linux-arm-kernel@lists.infradead.org; Wed, 16 Nov 2022 11:30:37 +0000 Received: by mail-io1-xd33.google.com with SMTP id r81so12971721iod.2 for ; Wed, 16 Nov 2022 03:30:32 -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=4aBMJ8kYEkh7R4S/WpFIBHIM/nZA2sjQ6sx0TF7I1GM=; b=ckD8Hiq6dP9OfkR/W7ioyYQcS9frxL2N/CLWoGaZhgu8GUy7hHfox8d2HFaKUlK+Ix 61qk1ezTmL9ekzc9QHgA8Q3vxNJSEorIYGdyjq0jOkKv2ZPd8q1gS+7xfmXxWEYcI3uU DQpH9hGQzZJivZQwFDpcZdAu1yMxvG2Iq/HzU= 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=4aBMJ8kYEkh7R4S/WpFIBHIM/nZA2sjQ6sx0TF7I1GM=; b=AgijJs3O/WTcTKCuQmKvUtEIiylqGOALadZlhSNPqvZDbVKd7Fubkz2heorYvN/69h t+Y/NNVIH3lmbufp2xK6fJji0xp/f286r0DFyUVHROOzWaAf1JM7fDB28nLuWQQtpKpm wigvXoRJybi9IaweVsWF5B0Nz6xs/x2c1tjSEFcLTgL/IGj3cw/beL07ByQAg9kOON0f KYJnLVDdAtC1DTZo0QJdKnr49YhyffMWFdog2SF2ybdEJnZQ9qdia/WvESeG3zqMK6BA AjJAAKTi9LdpZTGfa0ozmnq/v4Dp+8DhEGCd8O280+pSktz20veHg8h91+1pXER7pIvL h3bg== X-Gm-Message-State: ANoB5pnHxkaE6fGeeeI4TNJmWY7Qdqpt36EZ/yudeW/GWERe/aeGmHkV kCpJdiGvO2mB9UyE//Wa5oi+oT8ehv/QQtGsKxaFEw== X-Google-Smtp-Source: AA0mqf4Ybpn1by0jqTKLh8cuMc+KV7ZyH+joth4+kuKo3gxFuQ7ZpcNvxXB4B5vp19KJm0G8mWQopSH5MNPH83fGBPI= X-Received: by 2002:a6b:b7c6:0:b0:6d6:bff5:bbdf with SMTP id h189-20020a6bb7c6000000b006d6bff5bbdfmr9760231iof.156.1668598231852; Wed, 16 Nov 2022 03:30:31 -0800 (PST) MIME-Version: 1.0 References: <20221110183853.3678209-1-jagan@amarulasolutions.com> <20221110183853.3678209-10-jagan@amarulasolutions.com> <694ccb10-15ad-5192-dd1b-86628227fb65@denx.de> <35a96ba1-1022-5f7a-ffb6-b3400279e244@denx.de> <60729cf5-04b1-b9aa-fb0f-60efacde285d@samsung.com> <7635358a-fc32-5a78-6130-7c5f4dd2d81b@denx.de> In-Reply-To: From: Jagan Teki Date: Wed, 16 Nov 2022 17:00:20 +0530 Message-ID: Subject: Re: [PATCH v8 09/14] drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts To: Marek Szyprowski , Marek Vasut Cc: Andrzej Hajda , Inki Dae , 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-20221116_033035_047051_BA048609 X-CRM114-Status: GOOD ( 36.53 ) 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 On Wed, Nov 16, 2022 at 4:37 PM Marek Szyprowski wrote: > > On 16.11.2022 11:49, Marek Vasut wrote: > > On 11/16/22 09:07, Marek Szyprowski wrote: > >> On 15.11.2022 13:00, Marek Vasut wrote: > >>> On 11/14/22 08:49, Jagan Teki wrote: > >>>> On Sun, Nov 13, 2022 at 5:51 AM Marek Vasut wrote: > >>>>> > >>>>> On 11/10/22 19:38, Jagan Teki wrote: > >>>>>> Finding the right input bus format throughout the pipeline is hard > >>>>>> so add atomic_get_input_bus_fmts callback and initialize with the > >>>>>> proper input format from list of supported output formats. > >>>>>> > >>>>>> This format can be used in pipeline for negotiating bus format > >>>>>> between > >>>>>> the DSI-end of this bridge and the other component closer to > >>>>>> pipeline > >>>>>> components. > >>>>>> > >>>>>> List of Pixel formats are taken from, > >>>>>> AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022 > >>>>>> 3.7.4 Pixel formats > >>>>>> Table 14. DSI pixel packing formats > >>>>>> > >>>>>> v8: > >>>>>> * added pixel formats supported by NXP AN13573 i.MX 8/RT MIPI > >>>>>> DSI/CSI-2 > >>>>>> > >>>>>> v7, v6, v5, v4: > >>>>>> * none > >>>>>> > >>>>>> v3: > >>>>>> * include media-bus-format.h > >>>>>> > >>>>>> v2: > >>>>>> * none > >>>>>> > >>>>>> v1: > >>>>>> * new patch > >>>>>> > >>>>>> Signed-off-by: Jagan Teki > >>>>>> --- > >>>>>> drivers/gpu/drm/bridge/samsung-dsim.c | 53 > >>>>>> +++++++++++++++++++++++++++ > >>>>>> 1 file changed, 53 insertions(+) > >>>>>> > >>>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c > >>>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c > >>>>>> index 0fe153b29e4f..33e5ae9c865f 100644 > >>>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c > >>>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c > >>>>>> @@ -15,6 +15,7 @@ > >>>>>> #include > >>>>>> #include > >>>>>> #include > >>>>>> +#include > >>>>>> #include > >>>>>> #include > >>>>>> > >>>>>> @@ -1321,6 +1322,57 @@ static void > >>>>>> samsung_dsim_atomic_post_disable(struct drm_bridge *bridge, > >>>>>> pm_runtime_put_sync(dsi->dev); > >>>>>> } > >>>>>> > >>>>>> +/* > >>>>>> + * This pixel output formats list referenced from, > >>>>>> + * AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022 > >>>>>> + * 3.7.4 Pixel formats > >>>>>> + * Table 14. DSI pixel packing formats > >>>>>> + */ > >>>>>> +static const u32 samsung_dsim_pixel_output_fmts[] = { > >>>>> > >>>>> You can also add : > >>>>> > >>>>> MEDIA_BUS_FMT_YUYV10_1X20 > >>>>> > >>>>> MEDIA_BUS_FMT_YUYV12_1X24 > >>>> > >>>> Are these for the below formats? > >>>> > >>>> "Loosely Packed Pixel Stream, 20-bit YCbCr, 4:2:2 > >>>> Packed Pixel Stream, 24-bit YCbCr, 4:2:2" > >>>>> > >>>>>> + 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, > >>>>>> +}; > >>>>>> + > >>>>>> +static bool samsung_dsim_pixel_output_fmt_supported(u32 fmt) > >>>>>> +{ > >>>>>> + int i; > >>>>>> + > >>>>>> + for (i = 0; i < ARRAY_SIZE(samsung_dsim_pixel_output_fmts); > >>>>>> i++) { > >>>>>> + if (samsung_dsim_pixel_output_fmts[i] == fmt) > >>>>>> + return true; > >>>>>> + } > >>>>>> + > >>>>>> + return false; > >>>>>> +} > >>>>>> + > >>>>>> +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; > >>>>>> + > >>>>>> + if (!samsung_dsim_pixel_output_fmt_supported(output_fmt)) > >>>>>> + return NULL; > >>>>>> + > >>>>>> + *num_input_fmts = 1; > >>>>> > >>>>> Shouldn't this be 6 ? > >>>>> > >>>>>> + input_fmts = kmalloc(sizeof(*input_fmts), GFP_KERNEL); > >>>>>> + if (!input_fmts) > >>>>>> + return NULL; > >>>>>> + > >>>>>> + input_fmts[0] = output_fmt; > >>>>> > >>>>> Shouldn't this be a list of all 6 supported pixel formats ? > >>>> > >>>> Negotiation would settle to return one input_fmt from the list of > >>>> supporting output_fmts. so the num_input_fmts would be 1 rather than > >>>> the number of fmts in the supporting list. This is what I understood > >>>> from the atomic_get_input_bus_fmts API. let me know if I miss > >>>> something here. > >>> > >>> How does the negotiation work for this kind of pipeline: > >>> > >>> LCDIFv3<->DSIM<->HDMI bridge<->HDMI connector > >>> > >>> where all elements (LCDIFv3, DSIM, HDMI bridge) can support either > >>> RGB888 or packed YUV422 ? > >>> > >>> Who decides the format used by such pipeline ? > >>> > >>> Why should it be the DSIM bridge and not e.g. the HDMI bridge or the > >>> LCDIFv3 ? > >> > >> > >> If I got it right, the drivers reports their preference for the returned > >> formats. The format that is first in the reported array is the most > >> preferred one. This probably means that in your case the HDMI bridge > >> decides by reporting RGB or YUV first (if all elements supports both). > > > > But in that case, we need to list input_fmts[0]...input_fmts[n-1] in > > samsung_dsim_atomic_get_input_bus_fmts() and also set *num_input_fmts > > = n, correct ? > > > Yes, if I got the bus format negotiation code right, but I didn't check > the details. It Looks like if the number of formats returned by the array is more than 1, then the input_fmts array needs to return by listing formats in decreasing preference order so that the bridge core will try all formats until it finds one that works. But the question here is how much is the array number, how to decide? I can see dw-hdmi return a maximum of 3 possible input formats for an output format so the array seems to be 3 here, but the rest of drivers like imx8qxp-pixel-link do return 1 from the list of supported - dsim doing the same here. If we are sure dsim can support or feature 2 then order RGB888 and YUV422 decreasing preference and return them otherwise stick with a single return of checking supported list and return desired one. Jagan. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel