[PATCH v3 00/12] Add mipi dsi support for rk3288

Emil Velikov emil.l.velikov at gmail.com
Fri Nov 20 04:19:54 PST 2015

On 20 November 2015 at 07:02, Chris Zhong <zyw at rock-chips.com> wrote:
> Hi Emil
> On 11/19/2015 10:41 PM, Emil Velikov wrote:
>> On 19 November 2015 at 03:35, Chris Zhong <zyw at rock-chips.com> 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 bridge driver and a rockchip MIPI DSI specific DRM
>>> driver.
>>> This series also includes a DRM panel driver for BOE TV080WUM-NL0 panel.
>>> This panel only use the MIPI DSI video mode.
>>> The MIPI DSI feature is tested on rk3288 evb board, backport them to
>>> chrome os kernel v3.14, and it can display normally.
>>> This patchset is base on the patchset from Ying.liu at freescale.com.
>>> <http://www.spinics.net/lists/dri-devel/msg77181.html>
>>> Changes in v3:
>>> move the dw_mipi_dsi.txt to
>>> Documentation/devicetree/bindings/display/bridge
>>> move dw_mipi_dsi_rockchip.txt to bindings/display/rockchip/
>>> move boe,tv080wum-nl0.txt to bindings/display/panel/
>>> Changes in v2:
>>> add the mipi clk id in a single patch
>>> As Thierry.Reding comment, add a documentation for this panel.
>>> Chris Zhong (10):
>>>    clk: rockchip: add id for mipidsi sclk on rk3288
>>>    clk: rockchip: add mipidsi clocks on rk3288
>>>    drm/rockchip: return a true clock rate to adjusted_mode
>>>    drm/bridge: Add Synopsys DesignWare MIPI DSI host controller driver
>> Did you actually rewrite the patch from Liu Ying ?
> I modify the dw_mipi_dsi.c based on the patch from Liu Ying.
If you base your work on top of (i.e. you rework) someone else's patch
you should retain this authorship and signed-off-by line. This of
course is not limited to the above patch but a general rule, afaik.

>> Out of curiosity what was the obstacle of this work getting merged ?
> There are different version dw controller, and it is too hard to merge them,
> since most registers are different.
Have you discussed this limitation with Liu ? Does your work handle
both versions of the controller ? If so your commit message should say
something about that. Here are some good sources on the whats and whys
wrt writing good commit messages [1] [2]

[1] http://who-t.blogspot.co.uk/2009/12/on-commit-messages.html
[2] http://chris.beams.io/posts/git-commit/

>>>    drm: rockchip: Support Synopsys DesignWare MIPI DSI host controller
>>>    Documentation: dt-bindings: Add bindings for rk3288 DW MIPI DSI driver
>>>    ARM: dts: rockchip: add rk3288 mipi_dsi nodes
>>>    drm/panel: simple: Add support for BOE TV080WUM-NL0
>>>    drm/panel: simple: Add boe,tv080wum-nl0 simple panel device tree
>>>      binding
>> As the DT people will tell you - there is no BOE vendor in
>> bindings/vendor-prefixes.txt.
> Yes, I have post a verdor patch in v2 series,
> <https://patchwork.kernel.org/patch/7530791/>
> Maybe I should add it back to series with
> Acked-by: Rob Herring<robh at kernel.org>
If a patch has been reviewed/acked that's great. Add the tag, but
please do not drop patches until they are merged. In the latter case
you can mention that your series depends on branch X from repo Y.

>>>    ARM: dts: rockchip: add support mipi panel tv080wum-nl0 for rk3288-evb
>>> Liu Ying (2):
>>>    drm/dsi: Add a helper to get bits per pixel of MIPI DSI pixel format
>>>    Documentation: dt-bindings: Add bindings for Synopsys DW MIPI DSI DRM
>>>      bridge driver
>> >From the above 12 patches only ~6 reached this mailing list is that
>> intentional ? Previously I've seen people CC dri-devel for their
>> panel/bridge DT patches.
> I use the patman to post the series, forgot to add you and Thierry to the
> to-list.
> I will fix in next version series. Thanks for your reply.
No need to add me bth. Thierry on the other hand should be Cc'd on the
patches where he's the maintainer.

As the To/Cc list is already quite excessive - I'd suggest following
the approach used by veterans in kernel development.

I'm not a veteran kernel dev, but this is what I've noticed over the years:
 - Subsystem foo - mailing-list, maintainer(s), and optionally the top
1-2 developers
 - Other subsystems - mailing-list and optionally the maintainer(s).

Thus in the case of the panel driver you'll get - dri-devel, Thierry
and optionally(?) devicetree
For the DT binding for the panel driver - devicetree, Rob, dri-devel, Thierry.

...I think you get the idea :-)


More information about the Linux-rockchip mailing list