From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752678AbbDPFkL (ORCPT ); Thu, 16 Apr 2015 01:40:11 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:33553 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751012AbbDPFkG (ORCPT ); Thu, 16 Apr 2015 01:40:06 -0400 Message-ID: <552F4B2E.2000209@codeaurora.org> Date: Thu, 16 Apr 2015 11:09:58 +0530 From: Archit Taneja User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Thierry Reding , Liu Ying CC: stefan.wahren@i2se.com, devicetree@vger.kernel.org, linux@arm.linux.org.uk, sboyd@codeaurora.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, a.hajda@samsung.com, kernel@pengutronix.de, andy.yan@rock-chips.com, mturquette@linaro.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH RFC v9 11/20] drm/bridge: Add Synopsys DesignWare MIPI DSI host controller driver References: <1423720903-24806-1-git-send-email-Ying.Liu@freescale.com> <1423720903-24806-12-git-send-email-Ying.Liu@freescale.com> <20150409084353.GD12103@ulmo> In-Reply-To: <20150409084353.GD12103@ulmo> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/09/2015 02:13 PM, Thierry Reding wrote: > On Thu, Feb 12, 2015 at 02:01:34PM +0800, Liu Ying wrote: > [...] >> diff --git a/drivers/gpu/drm/bridge/dw_mipi_dsi.c b/drivers/gpu/drm/bridge/dw_mipi_dsi.c > [...] >> +struct dw_mipi_dsi { >> + struct mipi_dsi_host dsi_host; >> + struct drm_connector connector; >> + struct drm_encoder *encoder; >> + struct drm_bridge *bridge; >> + struct drm_panel *panel; >> + struct device *dev; >> + >> + void __iomem *base; >> + >> + struct clk *pllref_clk; >> + struct clk *cfg_clk; >> + struct clk *pclk; >> + >> + unsigned int lane_mbps; /* per lane */ >> + u32 channel; >> + u32 lanes; >> + u32 format; >> + struct drm_display_mode *mode; >> + >> + const struct dw_mipi_dsi_plat_data *pdata; >> + >> + bool enabled; >> +}; > > While reviewing this I kept thinking whether this is really the right > architectural design. This driver is a MIPI DSI host, a connector and > a bridge, all in one. But it seems to me like it should really be an > encoder/connector and a MIPI DSI host. Why the need for a bridge? The > bridge abstraction targets blocks outside of the SoC, but it is my > understanding that these DesignWare IP blocks are designed into SoCs. > The msm driver uses bridges for blocks within the SoC too. We have too many sub blocks in the display controller that use up crtcs and encoder entities. A bridge is the only option one has if an encoder in the display chain is already taken. In the above designware configuration, if some one created a board that used an external chip to further convert DSI to some other output format, then we would be completely exhausted of all entities. I posted a patch that allows us to create a chain of bridges for such cases. It seems to work well as an interim solution. Ideally, it would be better if we could make bridge a special case of an encoder, and let one encoder connect to another encoder. Such a thing would also help us unify i2c slave encoders and bridge drivers too. A chip designed as an i2c slave encoder would work well with a drm driver that doesn't have an encoder, but won't work for SoCs SoCs that already have an encoder and were expecting a bridge entity instead. Archit -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project