linux-kernel - Re: [PATCH v7 0/5] Add mipi dsi support for rk3288

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]

Date:	Mon, 8 Feb 2016 17:56:27 +0530
From:	Archit Taneja <architt@...eaurora.org>
To:	Heiko Stuebner <heiko@...ech.de>, treding@...dia.com
Cc:	Chris Zhong <zyw@...k-chips.com>,
	linux-rockchip@...ts.infradead.org, mark.yao@...k-chips.com,
	Mark Rutland <mark.rutland@....com>,
	devicetree@...r.kernel.org, Russell King <linux@....linux.org.uk>,
	Pawel Moll <pawel.moll@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
	Rob Herring <robh+dt@...nel.org>,
	Kumar Gala <galak@...eaurora.org>,
	linux-arm-kernel@...ts.infradead.org,
	Xinliang Liu <xinliang.liu@...aro.org>
Subject: Re: [PATCH v7 0/5] Add mipi dsi support for rk3288



On 02/08/2016 04:22 PM, Heiko Stuebner wrote:
> Hi Archit,
>
> Am Montag, 8. Februar 2016, 15:42:04 schrieb Archit Taneja:
>> On 01/06/2016 09:33 AM, Chris Zhong wrote:
>>> The rk3288 MIPI DSI is a Synopsys DesignWare MIPI DSI host controller
>>> IP. This series adds support for a Synopsys DesignWare MIPI DSI host
>>> controller DRM driver.
>>>
>>> The MIPI DSI feature is tested on rk3288 evb board, backport them to
>>> chrome os kernel chrome_v3.14, and it can display normally.
>>>
>>> This patchset is base on the patchset from Ying.liu@...escale.com.
>>> <http://www.spinics.net/lists/dri-devel/msg77181.html>
>>>
>>> According to the suggestion from Thierry, I have get rid of the bridge,
>>> and register the encoder & connecter in drm/rockchip/dw-mipi-dsi.c.
>>
>> I've raised this question too late, but what was the reason to not
>> implement the DSI block as a bridge driver?
>
> There seems to always be some sort of contention about those being bridge
> drivers - I think I remember Thierry speaking up about that. But I don't
> remember if any different solution was suggested.

Well, yeah, these can be considered as encoders too. I guess it's just
not very common to have encoder drivers outside of the kms driver, in
comparison to bridges.

The advantage of having such shared IPs as bridges is that they can be
used by kms drivers that already implement an encoder in the display
chain.

>
> Also as we have seen with current shared IPs (dw-hdmi + analogix-dp) there
> are always implementation-specific parts and deciding which needs to land
> where is difficult without the secondary user present.

Yeah, I can imagine it being hard to separate out the implementation
specific and core parts.

>
> The first iterations where using a bridge-driver-base for it but I guess it
> was to much hassle without seeing another user on the horizon.
>
>
>> The drm/hisilicon IP seems to use a very similar DSI Designware IP (the
>> register offsets seems to be the same). There is a good potential of
>> re-use here by different kms drivers here the way it's already done for
>> DW HDMI and the analogix DP driver that's in review process.
>
> I guess, the second user now gets to do the generalization ;-)

If not the generalization, then at least an assessment if it's worth the
effort or not :)

Archit

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum, hosted by The Linux Foundation