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 AA1E8C433F5 for ; Thu, 3 Feb 2022 08:03:49 +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=YH1peEKd+BgyrpvVgbTuvmJhQkMqcg5zwOfABL3j9fk=; b=CD5XnLquKoHsAa N12IkGH7uzFsW/m4qOKmFiVWI17lJlaSojyZh/qkPRd4EhKT6FfqOF6OLvZndnDsVsGKRHK4jM43Y 5cLwfd4bJ2uE6i6yDRbNAJsyDIAUSomD9/d0gXF1XvQfrcWnAI/vR3oDok4HDmeubTMujNCM5Sy/e qBb5XQMstc4DFB7Ew+0iDA0WSbk6DQPst7qDTddh5SIJG4PeZ/LBRnoXzGmJF1WsCTh9S5xjCrLuz GtI88PBXTSPzjPNu0nD4OUcEaP/77NHbilOQbri0UfZNQZF4MaV6v9uzDjijWEG/TJU4QEdWaDpCZ 6fQrNJ7txE4mlUq1sSVg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nFX4A-000F1a-Od; Thu, 03 Feb 2022 08:02:06 +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 1nFX46-000F12-Tb for linux-arm-kernel@lists.infradead.org; Thu, 03 Feb 2022 08:02:05 +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=1643875323; x=1675411323; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=pjS6RspszbEFEaiI25blgZRzdp2Q96jSu7lNDEq/gsU=; b=AMVkIcoF/Tg54e1UxUXLydssSOSEb9vgA5A/gkl4BbYv966HSfPkf4/l Q8EnMNsd8E32cLZpm4asxmgbUkL0MN+i1pG839NHJMYk5N1mLuQCnlcem TFGks2uqSohXhGhjl3sD0qrgEW/i80a2Plv7aqBGbHzbl2YsDdoxyNaeo cAST63yZYWozbFfKLxWW+7hvZH+lDYkOpdWzV56FLl/PKXnT3kNTHmfrH ucOqjI5Q1RVlOgeak9q5cZc2RltiOcYDjsui66vXIObPj4+xR1shFojLE yyD/Gb/ujShkIDe6fY5KsaLNje5mNNw5uSLwEZSuVFD801NzSefrsCJa3 g==; X-IronPort-AV: E=Sophos;i="5.88,339,1635199200"; d="scan'208";a="21868422" Received: from unknown (HELO tq-pgp-pr1.tq-net.de) ([192.168.6.15]) by mx1-pgp.tq-group.com with ESMTP; 03 Feb 2022 09:01:59 +0100 Received: from mx1.tq-group.com ([192.168.6.7]) by tq-pgp-pr1.tq-net.de (PGP Universal service); Thu, 03 Feb 2022 09:01:59 +0100 X-PGP-Universal: processed; by tq-pgp-pr1.tq-net.de on Thu, 03 Feb 2022 09:01:59 +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=1643875319; x=1675411319; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=pjS6RspszbEFEaiI25blgZRzdp2Q96jSu7lNDEq/gsU=; b=FnNHNeTuIS7KF66iSmgoxPMf4QOM3HwMXG65VA4h7rRmNLF3yAevw15B Kfueuz4+hNfsML1y0aGW5Mit5ZStIZ/1byeIRk4O2O37p/tXx5hrbkvUN ZFUWAbmlHZSTNORc4syIwNC28xWlgwaakiub/C6r+xkfcEeG4V79dJYUP cyPtQ2CKZIKxhmKqTqwMplBWdS0QiA17aMw0ztkXjMOc49VGcxhGpeuI3 I5NvBlmQl3xELJVkn3CLmBPzfsu/meCGM3SngFpOtjAFtgz1UsEaPZbhk NAQjnOMuNdBhXULYISxh4tcZwPl+d3vOFnsR9KORUrL3ZPZl9aMWk9Ftu g==; X-IronPort-AV: E=Sophos;i="5.88,339,1635199200"; d="scan'208";a="21868419" Received: from vtuxmail01.tq-net.de ([10.115.0.20]) by mx1.tq-group.com with ESMTP; 03 Feb 2022 09:01:58 +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 864E4280065; Thu, 3 Feb 2022 09:01:58 +0100 (CET) From: Alexander Stein To: Laurent Pinchart Cc: Christoph Niedermaier , linux-arm-kernel@lists.infradead.org, dri-devel@lists.freedesktop.org, Marek Vasut , Sam Ravnborg , Maxime Ripard , Philipp Zabel , David Airlie , Daniel Vetter , Shawn Guo , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , NXP Linux Team , linux-arm-kernel@lists.infradead.org Subject: Re: (EXT) Re: [RFC][PATCH] Revert "drm/panel-simple: drop use of data-mapping property" Date: Thu, 03 Feb 2022 09:01:56 +0100 Message-ID: <3046941.irdbgypaU6@steina-w> Organization: TQ-Systems GmbH In-Reply-To: References: <20220201110717.3585-1-cniedermaier@dh-electronics.com> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220203_000203_439831_4BD522E3 X-CRM114-Status: GOOD ( 20.29 ) 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 Donnerstag, 3. Februar 2022, 00:45:59 CET schrieb Laurent Pinchart: > [...] > You're right that there's an issue, but a revert isn't the right option. > The commit you're reverting never made it in a stable release, because > it was deemed to not be a good enough option. > > First of all, any attempt to fix this should include an update to the DT > binding. Second, as this is about DPI panels, the LVDS option should be > dropped. Finally, I've shared some initial thoughts in [1], maybe you > can reply to that e-mail to continue the discussion there ? > > https://lore.kernel.org/all/20200303185531.GJ11333@pendragon.ideasonboard.co > m/ At first I thought, this is a different issue than the one I currently have, but after reading this post, I think it's somewhat related. > If a panel expects RGB888 and receives RGB666 with the two LSBs of each > component hardwired to GND on the PCB, should DT report RGB888 or RGB666 > on the panel side ? I'm tempted by the former, and specifying the latter > on the transmitting side. My situation is the other way around. My panel (cdtech,s070swv29hg-dc44) has a MEDIA_BUS_FMT_RGB666_1X18 bus format (see panel-simple.c). Unfortunately for one mainboard the connection is like that: i.MX -- Panel (Blue and green is identical) R7 -- R5 R6 -- R4 ... R2 -- R0 R1 dont care R0 dont care So the 8 bpc (imx) and 6 bps (panel) are MSB aligned. The 2 LSB are completely ignored. The fast hacked fix is to use an additional panel description with bus format set to MEDIA_BUS_FMT_RGB888_1X24, keeping everything else the same. But that is cumbersome. IMHO a straight forward solution is to use a, yet to be written, simple bridge which just converts the bus format transparently, assuming the electrical connection is actually correct. This way the panel can set the native bus format, regardless of actual connections. Christoph's problem should disappear as well if going that way, as the bus format is set for the -> connection. Nevertheless the panel bus format should be available in the end. Regards, Alexander _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel