From patchwork Tue Jun 4 13:20:29 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Noralf_Tr=C3=B8nnes_via_B4_Relay?= X-Patchwork-Id: 13685290 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 154C0C27C54 for ; Tue, 4 Jun 2024 13:20:50 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 88F4810E47F; Tue, 4 Jun 2024 13:20:45 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.b="GXqdQSuu"; dkim-atps=neutral Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by gabe.freedesktop.org (Postfix) with ESMTPS id AEC1E10E47E for ; Tue, 4 Jun 2024 13:20:40 +0000 (UTC) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 0727761275; Tue, 4 Jun 2024 13:20:40 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPS id 6DC88C2BBFC; Tue, 4 Jun 2024 13:20:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1717507239; bh=N3w6VXVS+EVH7xZ8rObQF9eEO7/6WFtvK9O9QSTgDNU=; h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From; b=GXqdQSuu+JOyaTTF9WS1veULjleQlvb8Lw65PZynfgC66NwAH1IO1vuERES9Z2oJV nAZ7+mzc2FvFVHHXZKkE1A3gxXKTTBwpQPlobfpwEqM7hcSoDkSZLKQiuFYYUg0AWi nVJO4jE3KxQDLig/Gn6Y4rOs2bqbpnUvZ4D6XEUzBVDhuAFWylj6DstCnmFDODIMWE UTzUrOmmmwNpxbBA/evpmI8h3xxgnpwmQm0wMQRlMATprYINTY+K8EKQWldgV9cwz0 0mq5tca8Z9PP3LZ4/Nc/+fxjCG7qZHFOAuOmXAV+k11lYoHBuA/W6LlKuAOaCpx/OB WXMUKuBYjTa6w== Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5781CC25B78; Tue, 4 Jun 2024 13:20:39 +0000 (UTC) From: =?utf-8?q?Noralf_Tr=C3=B8nnes_via_B4_Relay?= Date: Tue, 04 Jun 2024 15:20:29 +0200 Subject: [PATCH v4 2/5] drm/mipi-dbi: Remove mipi_dbi_machine_little_endian() MIME-Version: 1.0 Message-Id: <20240604-panel-mipi-dbi-rgb666-v4-2-d7c2bcb9b78d@tronnes.org> References: <20240604-panel-mipi-dbi-rgb666-v4-0-d7c2bcb9b78d@tronnes.org> In-Reply-To: <20240604-panel-mipi-dbi-rgb666-v4-0-d7c2bcb9b78d@tronnes.org> To: Neil Armstrong , Jessica Zhang , Sam Ravnborg , David Airlie , Daniel Vetter , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , Rob Herring , Krzysztof Kozlowski , Conor Dooley , David Lechner , Dmitry Baryshkov Cc: dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Kamlesh Gurudasani , Tommaso Merciai , =?utf-8?q?Noralf_T?= =?utf-8?q?r=C3=B8nnes?= X-Mailer: b4 0.13.0 X-Developer-Signature: v=1; a=ed25519-sha256; t=1717507238; l=4066; i=noralf@tronnes.org; s=20221122; h=from:subject:message-id; bh=4acPc99PSUglSQ3liBG5HOqnFUMSYy99oBGEC9q+oxw=; b=Nn18Kqvi/QU6LQDCqfVZITLBB7traPlOIVAjC/4usZuiYlDssZaiOk/FUkYW+UfEm1PvvZCdg zSFpYwCDluOB6ckP5P9hKEclXCFo5IX+kLltAW+cQ49kOD+U3tNlJt8 X-Developer-Key: i=noralf@tronnes.org; a=ed25519; pk=0o9is4iddvvlrY3yON5SVtAbgPnVs0LfQsjfqR2Hvz8= X-Endpoint-Received: by B4 Relay for noralf@tronnes.org/20221122 with auth_id=8 X-Original-From: =?utf-8?q?Noralf_Tr=C3=B8nnes?= 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: , Reply-To: noralf@tronnes.org Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" From: Noralf Trønnes mipi_dbi_machine_little_endian() should really have been called mipi_dbi_framebuffer_little_endian() because that's the function it performs. When I added support for these SPI displays I thought that the framebuffers on big endian machines were also big endian, but I have later learned that this is not the case. There's a bit in the fourcc code that controls this: DRM_FORMAT_BIG_ENDIAN. Just remove the function to avoid confusion. We can add big endian support later should the need arise and we have hardware to test on. Instead of just amending the docs, expand it to explain the endianness handling. Reviewed-by: Dmitry Baryshkov Signed-off-by: Noralf Trønnes --- drivers/gpu/drm/drm_mipi_dbi.c | 35 +++++++++++++++++++---------------- 1 file changed, 19 insertions(+), 16 deletions(-) diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c index daac649aabdb..fa8aba6dc81c 100644 --- a/drivers/gpu/drm/drm_mipi_dbi.c +++ b/drivers/gpu/drm/drm_mipi_dbi.c @@ -824,15 +824,6 @@ u32 mipi_dbi_spi_cmd_max_speed(struct spi_device *spi, size_t len) } EXPORT_SYMBOL(mipi_dbi_spi_cmd_max_speed); -static bool mipi_dbi_machine_little_endian(void) -{ -#if defined(__LITTLE_ENDIAN) - return true; -#else - return false; -#endif -} - /* * MIPI DBI Type C Option 1 * @@ -855,7 +846,7 @@ static int mipi_dbi_spi1e_transfer(struct mipi_dbi *dbi, int dc, const void *buf, size_t len, unsigned int bpw) { - bool swap_bytes = (bpw == 16 && mipi_dbi_machine_little_endian()); + bool swap_bytes = (bpw == 16); size_t chunk, max_chunk = dbi->tx_buf9_len; struct spi_device *spi = dbi->spi; struct spi_transfer tr = { @@ -1004,7 +995,7 @@ static int mipi_dbi_spi1_transfer(struct mipi_dbi *dbi, int dc, size_t chunk = min(len, max_chunk); unsigned int i; - if (bpw == 16 && mipi_dbi_machine_little_endian()) { + if (bpw == 16) { for (i = 0; i < (chunk * 2); i += 2) { dst16[i] = *src16 >> 8; dst16[i + 1] = *src16++ & 0xFF; @@ -1218,11 +1209,23 @@ static int mipi_dbi_typec3_command(struct mipi_dbi *dbi, u8 *cmd, * If @dc is set, a Type C Option 3 interface is assumed, if not * Type C Option 1. * - * If the SPI master driver doesn't support the necessary bits per word, - * the following transformation is used: + * If the command is %MIPI_DCS_WRITE_MEMORY_START and the pixel format is RGB565, endianness has + * to be taken into account. The MIPI DBI serial interface is big endian and framebuffers are + * assumed stored in memory as little endian (%DRM_FORMAT_BIG_ENDIAN is not supported). * - * - 9-bit: reorder buffer as 9x 8-bit words, padded with no-op command. - * - 16-bit: if big endian send as 8-bit, if little endian swap bytes + * This is how endianness is handled: + * + * Option 1 (D/C as a bit): The buffer is sent on the wire byte by byte so the 16-bit buffer is + * byteswapped before transfer. + * + * Option 3 (D/C as a gpio): If the SPI controller supports 16 bits per word the buffer can be + * sent as-is. If not the caller is responsible for swapping the bytes + * before calling mipi_dbi_command_buf() and the buffer is sent 8 bpw. + * + * This handling is optimised for %DRM_FORMAT_RGB565 framebuffers. + * + * If the interface is Option 1 and the SPI controller doesn't support 9 bits per word, + * the buffer is sent as 9x 8-bit words, padded with MIPI DCS no-op commands if necessary. * * Returns: * Zero on success, negative error code on failure. @@ -1257,7 +1260,7 @@ int mipi_dbi_spi_init(struct spi_device *spi, struct mipi_dbi *dbi, if (dc) { dbi->command = mipi_dbi_typec3_command; dbi->dc = dc; - if (mipi_dbi_machine_little_endian() && !spi_is_bpw_supported(spi, 16)) + if (!spi_is_bpw_supported(spi, 16)) dbi->swap_bytes = true; } else { dbi->command = mipi_dbi_typec1_command;