On 11.1.2018 09:07, Daniel Vetter wrote:
On Thu, Jan 11, 2018 at 02:07:08AM +0000, Hyun Kwon wrote:
Hi Daniel,
-----Original Message----- From: Daniel Vetter [mailto:daniel.vetter@ffwll.ch] On Behalf Of Daniel Vetter Sent: Tuesday, January 09, 2018 1:57 AM To: Hyun Kwon hyunk@xilinx.com Cc: dri-devel@lists.freedesktop.org; devicetree@vger.kernel.org; Michal Simek michal.simek@xilinx.com Subject: Re: [PATCH 00/10] Xilinx ZynqMP DisplayPort subsystem DRM KMS driver
On Thu, Jan 04, 2018 at 06:05:49PM -0800, Hyun Kwon wrote:
Hi,
This patchset adds the DRM KMS driver for Xilinx ZynqMP DisplayPort subsystem. The Xilinx ZynqMP SoC has a hardened full display pipeline which supports blending of up to 2 planes, and the encoder is DisplayPort v1.2 compatible.
This series mainly includes 2 sets: Xilinx DRM KMS (patch 1/10 - 5/10) and ZynqMP DP subsystem drivers (patch 6/10 - 10/10).
The Xilinx DRM KMS is intended as a common layer shared across other (upcoming) Xilinx sub-drivers. It helps sub-drivers for both hardened as well as soft IPs interoperate together.
ZynqMP DP subsystem driver is a sub-driver that implements
corresponding
drm objects (crtc, plane, encoder, connector,,,) for ZynqMP SoC display pipeline. The entire pipeline is mainly partitioned into 2 blocks: generic display logic (zynqmp_disp.c) such as blending, csc,,, and the DP transmitter logic (zynqmp_dp.c).
I read through it all (well mostly the drm relevant bits, not your backend code) and looks fairly resonable. Few minor clenaups and code removals tbh.
Wrt merging/maintianing, do you want to maintain it as part of the drm-misc small drivers group? Highly recommended imo. See
https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm- misc.html#small-drivers
for details. Ideally we'd need 2 xilinx maintainers to be able to push patches & cross-review stuff.
I don't have any preference on how to maintain, so I'll follow your suggestion. One thing that may be worth a note is that there is sizable amount of development within Xilinx, and those will come in near future (considering what can be done with FPGA :-)). I'll look for the 2nd reviewer, and specify that in the next patch if found.
If the xilinx activity gets too much we can always split things up again. But if it's just the occasional burst (around a new product for example), then drm-misc has ample of bandwidth to absorb that.
And yes the idea is very much that all regular contributors would have commit rights too. All to reduce friction and make it easier to contribute.
Right now I think it is visible that everything needs to be reviewed properly to make sure that we are doing these stuff properly. This topic can be refreshed in future but I don't think we are there yet.
Thanks, Michal