lkml.org 
[lkml]   [2015]   [Apr]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2015-04-16 08:21    [W:1.540 / U:0.536 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site