linux-kernel - Re: [PATCH RFC v9 11/20] drm/bridge: Add Synopsys DesignWare MIPI DSI host controller driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <552F4B2E.2000209@codeaurora.org>
Date:	Thu, 16 Apr 2015 11:09:58 +0530
From:	Archit Taneja <architt@...eaurora.org>
To:	Thierry Reding <thierry.reding@...il.com>,
	Liu Ying <Ying.Liu@...escale.com>
CC:	stefan.wahren@...e.com, devicetree@...r.kernel.org,
	linux@....linux.org.uk, sboyd@...eaurora.org,
	linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
	a.hajda@...sung.com, kernel@...gutronix.de,
	andy.yan@...k-chips.com, mturquette@...aro.org,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH RFC v9 11/20] drm/bridge: Add Synopsys DesignWare MIPI
 DSI host controller driver

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/