From patchwork Tue Aug 5 11:12:25 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Thierry Reding X-Patchwork-Id: 4678231 Return-Path: X-Original-To: patchwork-linux-samsung-soc@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 4197C9F373 for ; Tue, 5 Aug 2014 11:12:35 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 689D8200FF for ; Tue, 5 Aug 2014 11:12:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8A87D200F0 for ; Tue, 5 Aug 2014 11:12:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754690AbaHELMd (ORCPT ); Tue, 5 Aug 2014 07:12:33 -0400 Received: from mail-wg0-f45.google.com ([74.125.82.45]:53601 "EHLO mail-wg0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753841AbaHELMc (ORCPT ); Tue, 5 Aug 2014 07:12:32 -0400 Received: by mail-wg0-f45.google.com with SMTP id x12so817564wgg.16 for ; Tue, 05 Aug 2014 04:12:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=M0B7nLBbjPyAtxTSSzie0LTXMVrzHXdj+bAdXxZuKOM=; b=MvFqAkfNf2uuQV8fSkAW8DZRVYcBO4wSeoWDdJfasjzIdTP2QB0Cp7CSjnC2t2R5G0 yARaJ3VcAMAivqTFRNX07NqkXAqUGQ0cJwoJO8yp+R4inmAXvTkOE4G4usu+10Qx14GD VL81Yl/yI6uKQ4srChYuw8HUfuowQuOCi4dl2+8dSJ0ODToZSQ1pG81nzWep0TQKyLD+ i6Ku5u8VnF0gmGddtqbJGkTlQ5wcyov1mokroNbYfJx0SGBZGDfWN6QHbA/agj7MaZEt dpv17we2p5qLXXmgAi1w6/LJU7YDhVRmhOy5I586nlWxPwsE4dy/0qNf0Yao1oWcN3A4 1ANQ== X-Received: by 10.180.212.12 with SMTP id ng12mr5703437wic.9.1407237147707; Tue, 05 Aug 2014 04:12:27 -0700 (PDT) Received: from localhost (port-92291.pppoe.wtnet.de. [84.46.72.252]) by mx.google.com with ESMTPSA id 10sm3478750wjr.22.2014.08.05.04.12.25 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Aug 2014 04:12:26 -0700 (PDT) Date: Tue, 5 Aug 2014 13:12:25 +0200 From: Thierry Reding To: Andrzej Hajda Cc: Inki Dae , dri-devel@lists.freedesktop.org, linux-samsung-soc@vger.kernel.org, treding@nvidia.com Subject: Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support Message-ID: <20140805111223.GA27340@ulmo> References: <1406512857-7213-1-git-send-email-inki.dae@samsung.com> <1406512857-7213-2-git-send-email-inki.dae@samsung.com> <53D675D6.2000309@samsung.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <53D675D6.2000309@samsung.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-samsung-soc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-samsung-soc@vger.kernel.org X-Spam-Status: No, score=-7.4 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, T_DKIM_INVALID, T_TVD_MIME_EPI,UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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 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 --- 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