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 5CE06C433EF for ; Fri, 18 Mar 2022 17:07:17 +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=7fiYBvmRiBU9oxDsYZKB+xkVqv/M4/JduCXRxf//+sc=; b=uzZXAv+roBOj0b gfrNtnd7t1yATHgpF8pBUnEajKHf1p3VuU3Ax5OCNcYlIasYc4pS7hj8Gltd7mYQUv2x3QqZbHT/9 nPEGlo9MxUUiZp+NSk4YRR9EtqVft9yGc6dPOW58vxsagx/3vKLVeYZBbOSl+9vpOmOtfwHP9ev3a SYxtptWZ7NezM3rNYVhBhrVsVm1FKBaDcQeBawOq06If8aFWnPyPkVMNjNPCJGnsTUOSZgk8apIgT T8m4tHHpwXAQsUB3l6snCiZHRp71m06qBbXbuIFT056NBLRtXJqO7CvPsayRRdQxvu9zkTnseYBBx axnIseOHs2NXZ6rkSXhw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nVG2m-002SbO-G6; Fri, 18 Mar 2022 17:05:40 +0000 Received: from mail-lj1-x229.google.com ([2a00:1450:4864:20::229]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nVG2i-002Sa4-9d for linux-arm-kernel@lists.infradead.org; Fri, 18 Mar 2022 17:05:38 +0000 Received: by mail-lj1-x229.google.com with SMTP id g24so10874033lja.7 for ; Fri, 18 Mar 2022 10:05:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raspberrypi.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WxMCTjgIXGUv5phWRdS5q6OXffoTEiCZt2VV0vGsabU=; b=WbaTcxzDss0ZDDMseogZKFSLf3MqUS87AlyLU/c8h0AzwGcyhjaQn3gq40/oKtb3Ee vskhPokgWbhGUdgsmx74dwGeb0LQvRS55pBv97h5rOm+KHoTpsuyk380fnUv2gS0VKIV D/De0gjRtWT//SvjPXFevmKJiRzW/gEYpHw0IjzwGmDQVX0uTBF6FOxz2N92Fz8QI/Fj +w9xdjdirlk3g5WvPWQtxHKpgBnMe5bIBCiB7TfGucLGYt0C4yn1ezwy0Hlghu6EVDUL T3wPKd0OCmhiCBCFE8ozVflhVFcDgn8CwBnF3cKBh5T2I3e30x+SWvf0HRCO0mg7qXtg bZWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WxMCTjgIXGUv5phWRdS5q6OXffoTEiCZt2VV0vGsabU=; b=SzfcY+C7VWVB4j6iJxaH/3JmKv2hJujGwu0zFwylL9q0IvW1YPEzvRgO18pW7lQv5k p1MqXYIGeKiUAVzOK90dyytiNwaudmsH+0ynRvJ6briBx1D/9QPA06xd26hrcRn6BRwY t+/uIJEh7FuBd2wyqFfHNh4d7g10l8b5w82kAynPNpGGQ2zz+JemhBUTVaLIouBsRFBF t4YVGjZjYLQ9ag1PWRLboIz6NiZ3Qj71S0aK718kdt7ndJFNGnq9Wb44iVeQItR9XSW7 MHsMJETrNtMlme4axNx0ZiNF55HBOcKC7MlycXmZvtctuiJzRLsNZXOg1ejo/4YqVZTj cW9w== X-Gm-Message-State: AOAM531gHLFRkRC+fFfdkhLTF4Y4VmtrazZ0S6FerLJ9SvXsAV+Gu4iq ds/WqnA3pZ0qhzSZ/GMghZF+97XyDIjeTt9SLzJuBQ== X-Google-Smtp-Source: ABdhPJwob0K/t2D7Zb02OMXIrF3msXKRyVOHxgL0f9cx14tdo2jD0Gp2tse6CqID/StDmuh0VLCTx6h9XnEcr47dsRI= X-Received: by 2002:a05:651c:200c:b0:23b:8267:9ed1 with SMTP id s12-20020a05651c200c00b0023b82679ed1mr6663624ljo.368.1647623127402; Fri, 18 Mar 2022 10:05:27 -0700 (PDT) MIME-Version: 1.0 References: <20220222084723.14310-1-max.krummenacher@toradex.com> <20220223134154.oo7xhf37bgtvm3ai@houat> <20220302142142.zroy464l5etide2g@houat> <9c9a10ca-e6a1-c310-c0a5-37d4fed6efd6@denx.de> <20220318163549.5a5v3lex4btnnvgb@houat> In-Reply-To: <20220318163549.5a5v3lex4btnnvgb@houat> From: Dave Stevenson Date: Fri, 18 Mar 2022 17:05:11 +0000 Message-ID: Subject: Re: [RFC PATCH] drm/panel: simple: panel-dpi: use bus-format to set bpc and bus_format To: Maxime Ripard Cc: Max Krummenacher , Marek Vasut , Christoph Niedermaier , Max Krummenacher , Pengutronix Kernel Team , David Airlie , Sam Ravnborg , Sascha Hauer , DRI Development , DenysDrozdov , Laurent Pinchart , Shawn Guo , Linux ARM , NXP Linux Team X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220318_100536_662631_98C4F627 X-CRM114-Status: GOOD ( 44.26 ) 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 Maxime On Fri, 18 Mar 2022 at 16:35, Maxime Ripard wrote: > > On Mon, Mar 07, 2022 at 04:26:56PM +0100, Max Krummenacher wrote: > > On Wed, Mar 2, 2022 at 5:22 PM Marek Vasut wrote: > > > > > > On 3/2/22 15:21, Maxime Ripard wrote: > > > > Hi, > > > > > > Hi, > > > > > > > Please try to avoid top posting > > Sorry. > > > > > > > > > > On Wed, Feb 23, 2022 at 04:25:19PM +0100, Max Krummenacher wrote: > > > >> The goal here is to set the element bus_format in the struct > > > >> panel_desc. This is an enum with the possible values defined in > > > >> include/uapi/linux/media-bus-format.h. > > > >> > > > >> The enum values are not constructed in a way that you could calculate > > > >> the value from color channel width/shift/mapping/whatever. You rather > > > >> would have to check if the combination of color channel > > > >> width/shift/mapping/whatever maps to an existing value and otherwise > > > >> EINVAL out. > > > >> > > > >> I don't see the value in having yet another way of how this > > > >> information can be specified and then having to write a more > > > >> complicated parser which maps the dt data to bus_format. > > > > > > > > Generally speaking, sending an RFC without explicitly stating what you > > > > want a comment on isn't very efficient. > > > > > > Isn't that what RFC stands for -- Request For Comment ? > > > > I hoped that the link to the original discussion was enough. > > > > panel-simple used to have a finite number of hardcoded panels selected > > by their compatible. > > The following patchsets added a compatible 'panel-dpi' which should > > allow to specify the panel in the device tree with timing etc. > > https://patchwork.kernel.org/project/dri-devel/patch/20200216181513.28109-6-sam@ravnborg.org/ > > In the same release cycle part of it got reverted: > > https://patchwork.kernel.org/project/dri-devel/patch/20200314153047.2486-3-sam@ravnborg.org/ > > With this it is no longer possible to set bus_format. > > > > The explanation what makes the use of a property "data-mapping" not a > > suitable way in that revert > > is a bit vague. > > Indeed, but I can only guess. BGR666 in itself doesn't mean much for > example. Chances are the DPI interface will use a 24 bit bus, so where > is the padding? > > I think that's what Sam and Laurent were talking about: there wasn't > enough information encoded in that property to properly describe the > format, hence the revert. MEDIA_BUS_FMT_RGB666_1X18 defines an 18bit bus, therefore there is no padding. "bgr666" was selecting that media bus code (I won't ask about the rgb/bgr swap). If there is padding on a 24 bit bus, then you'd use (for example) MEDIA_BUS_FMT_RGB666_1X24_CPADHI to denote that the top 2 bits of each colour are the padding. Define and use a PADLO variant if the padding is the low bits. The string matching would need to be extended to have some string to select those codes ("lvds666" is a weird choice from the original patch). Taking those media bus codes and handling them appropriately is already done in vc4_dpi [1], and the vendor tree has gained BGR666_1X18 and BGR666_1X24_CPADHI [2] as they aren't defined in mainline. Now this does potentially balloon out the number of MEDIA_BUS_FMT_xxx defines needed, but that's the downside of having defines for all formats. (I will admit to having a similar change in the Pi vendor tree that allows the media bus code to be selected explicitly by hex value). Dave [1] https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/vc4/vc4_dpi.c#L154 [2] https://github.com/raspberrypi/linux/blob/rpi-5.15.y/include/uapi/linux/media-bus-format.h#L49 > > The RFC revert of the revert > > https://patchwork.kernel.org/project/dri-devel/patch/20220201110717.3585-1-cniedermaier@dh-electronics.com/ > > tried to get feedback what would be a way forward. This RFC tries the > > same by giving a possible solution should > > the property name and/or the a bit short strings of the original be > > the reason why it is not suitable. > > > > So the requested comments would be about what was not good enough with > > 'data-mapping' and what would be a way forward. > > > > Especially since in my limited view it is not clear why in panel-lvds > > 'data-mapping' is used to state how the bits representing colour are > > mapped to the 21 or 28 possible bit position in the LVDS lanes vs. > > here where we want to say how the bits representing colour are mapped > > to the 16/18/24 lines of the parallel interface would need a different > > binding pattern. > > There's only a few data format in LVDS, so it's ok. A DPI interface is > much more free-form, so you need to be a bit more accurate than what is > done for LVDS. > > Maxime _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel