Thread (1 message) 1 message, 1 author, 2018-01-11

Re: [PATCH 00/10] Xilinx ZynqMP DisplayPort subsystem DRM KMS driver

From: Michal Simek <hidden>
Date: 2018-01-11 08:16:08
Also in: dri-devel

On 11.1.2018 09:07, Daniel Vetter wrote:
On Thu, Jan 11, 2018 at 02:07:08AM +0000, Hyun Kwon wrote:
quoted
Hi Daniel,
quoted
-----Original Message-----
From: Daniel Vetter [mailto:daniel.vetter-/w4YWyX8dFk@public.gmane.org] On Behalf Of Daniel
Vetter
Sent: Tuesday, January 09, 2018 1:57 AM
To: Hyun Kwon <redacted>
Cc: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Michal
Simek [off-list ref]
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:
quoted
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
quoted
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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help