On Mon, Jul 28, 2014 at 06:09:58PM +0200, Andrzej Hajda wrote: > On 07/28/2014 04:00 AM, Inki Dae wrote: > > This patch adds below two flags for LPM transfer, and it attaches LPM flags > > to a msg in accordance with master's mode_flags set by LCD Panel driver. > > > > MIPI_DSI_MODE_CMD_LPM > > - If this flag is set by Panel driver, MIPI-DSI controller will tranfer > > command data to Panel device in Low Power Mode. > > What do you mean by command data? It could be: > - all transfer in command mode of operations, > - transfer initialized by the driver by writing to DSIM registers. > > > > > MIPI_DSI_MODE_VIDEO_LPM > > - If this flag is set by Panel driver, MIPI-DSI controller will tranfer > > image data to Panel device in Low Power Mode. > > What is the meaning of this flag in case of command mode of operation? > > Maybe it would be better to create flags based on source of data/FIFOs: > - commands send by SFR registers, > - commands generated from data sent from Display Controller. I have no idea what SFR is. But it sounds like you're talking about two ways to generate command packets here. We have something similar on Tegra, where it's called "host-driven command mode" and "DC-driven command mode". In host-driven command mode the driver needs to explicitly program some of the DSI controller registers to send command packets. This is essentially a FIFO register and a control register to trigger transmission and poll for completion. DC-driven command mode is typically used to update contents of a remote framebuffer (what MIPI calls "Type 1 Display Architecture"). This is done by programming a different set of registers that cause the DSI controller to take data output by the display controller and wrap it into DCS commands (e.g. write_memory_start and write_memory_continue). I think that low power mode is more often used for command transmission (in host-driven mode). I'm not sure how much sense it really makes to transmit video data in low power mode. It also seems like low power mode is what all peripherals need to support (if they can do command mode). Hence I'd like to propose the attached patch that makes all command messages use low power mode. The .transfer() function was really designed with initialization commands in mind, so it doesn't deal with mixing video data and commands anyway and for initialization low-power mode should be fast enough. The downside is that it may not be optimal for some peripherals, but it gives us a good solution for the general case since it should support all devices. If we absolutely must have faster initialization, or if we come across a device that can only initialize in high speed mode, then I think we should introduce a new flag to allow DSI host controllers to optimize in those cases. Note that this is based on some of my local patches, so it won't apply as-is. But if anybody wants to give this a go it should be easy to apply manually as well. Thierry
From f93dd508afc19262fd95c01520d5d6d7937be4e8 Mon Sep 17 00:00:00 2001
From: Thierry Reding <treding@xxxxxxxxxx>
Date: Tue, 5 Aug 2014 11:30:14 +0200
Subject: [PATCH] drm/dsi: Always use low-power mode for DCS commands
Many peripherals require DCS commands to be sent in low power mode and
will fail to correctly process them in high speed mode. Section 5.2 of
the MIPI DSI specification also mandates that on bidirectional lanes,
data shall be transmitted in low power mode only. At worst this change
will make transmission of DCS commands slower than optimal on some DSI
peripherals, but it should enable DCS commands to be successfully
transmitted to any DSI peripheral.
If transmission in low power mode turns out to be too slow at some point
in the future, one possible solution would be to explicitly mark devices
that support high speed transmission of DCS commands.
Signed-off-by: Thierry Reding <treding@xxxxxxxxxx>
---
drivers/gpu/drm/drm_mipi_dsi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index b0a304ab6827..57588b9ff7c6 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -370,6 +370,7 @@ ssize_t mipi_dsi_dcs_write_buffer(struct mipi_dsi_device *dsi,
{
struct mipi_dsi_msg msg = {
.channel = dsi->channel,
+ .flags = MIPI_DSI_MSG_USE_LPM,
.tx_buf = data,
.tx_len = len
};
@@ -457,6 +458,7 @@ ssize_t mipi_dsi_dcs_write(struct mipi_dsi_device *dsi, u8 cmd,
}
memset(&msg, 0, sizeof(msg));
+ msg.flags = MIPI_DSI_MSG_USE_LPM;
msg.channel = dsi->channel;
msg.tx_len = size;
msg.tx_buf = tx;
@@ -501,6 +503,7 @@ ssize_t mipi_dsi_dcs_read(struct mipi_dsi_device *dsi, u8 cmd, void *data,
struct mipi_dsi_msg msg = {
.channel = dsi->channel,
.type = MIPI_DSI_DCS_READ,
+ .flags = MIPI_DSI_MSG_USE_LPM,
.tx_buf = &cmd,
.tx_len = 1,
.rx_buf = data,
--
2.0.4
Attachment:
pgpXrydmMy5zH.pgp
Description: PGP signature
