On 20 November 2015 at 07:02, Chris Zhong [off-list ref] wrote:

Hi Emil

On 11/19/2015 10:41 PM, Emil Velikov wrote:

quoted

On 19 November 2015 at 03:35, Chris Zhong [off-list ref] wrote:

quoted

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.

quoted

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/

quoted

quoted

   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@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.

quoted

quoted

   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 :-)

Regards,
Emil