[PATCH 00/72] staging imx-drm new features and fixes

[Philipp Zabel]

Hi,

Am Montag, den 03.11.2014, 10:59 -0800 schrieb Steve Longerbeam:
> On 11/03/2014 09:48 AM, Greg KH wrote:
> > On Mon, Nov 03, 2014 at 06:17:28PM +0100, Daniel Vetter wrote:
> >> On Mon, Nov 03, 2014 at 08:14:23AM -0800, Greg KH wrote:
> >>> On Mon, Nov 03, 2014 at 05:12:14PM +0100, Daniel Vetter wrote:
> >>>> On Fri, Oct 31, 2014 at 03:53:43PM -0700, Steve Longerbeam wrote:
> >>>>> Hi, this affects only Freescale imx IPU and imx-drm staging drivers,
> >>>>> except for two patches that affect drm core (patch 53 and 63, see below).
> >>>>>
> >>>>> New features for imx-drm staging driver:
> >>>>>
> >>>>> - Support for multi-display (HDMI and LVDS).
> >>>>> - Support for global alpha and color-key properties for overlay plane.
> >>>>> - Support for gamma correction.
> >>>>> - The imx-drm crtc devices moved to device tree.
> >>>>> - Support for defining custom display interface pixel mappings in the
> >>>>>   device tree.
> >>>>> - Implements encoder DPMS for LVDS.
> >>>>> - YUV planar pixel formats supported for DRM framebuffers.
> >>>>> - DDC support added for LVDS.
> >>>>> - Page flip handling moved to imx plane driver and implemented with
> >>>>>   IPU double-buffering.
> >>>>> - Support page-flip in the overlay plane (patch 53 affects drm core).
> >>>>> - Add support for parsing pixel clock edge select (patch 63 affects drm core).
> >>>>> - Add LVDS connection detect via drm_probe_ddc().
> >>>>> - Implement crtc mode_set_base using plane page-flip.
> >>>> Isn't the point of staging to get the driver out of it, instead of adding
> >>>> massive piles of features and continously keeping it there? Greg?
> >>> Yes, please don't add new features to this codebase, fix it up so it
> >>> gets out of staging first, I'm not going to take any of these (not the
> >>> least reason being that I wasn't even cc:ed on them...)
> >> Yeah I think imx works a bit like a driver outside of staging with patches
> >> submitted to the subsystem and reviewed all there like normal. Except it's
> >> not ...
> > And I keep taking imx driver patches as well through my staging tree.
> >
> > Steve, what's the status of getting this driver out of staging?  What is
> > left to do, and who is doing the work?
> 
> Hi Greg, you should also talk with the original authors (Sascha and
> Philipp at Pengutronix), but in my experience, this driver is still suffering
> from some chronic IPU issues with data starvation to the display interface.
> So from my experience, that is really the only thing that is holding it up.

I hadn't realized that Russell decided to step away from his imx-drm
submission effort. I'd like to take it on, and I'd also like to start by
moving it out of staging first so we have a single place to push patches
to again.
I'll submit a MAINTAINERS entry, so that I'll be put on Cc: for related
patches.

Steve, it would be generally helpful if you could spread your
submissions out a bit over time and separate the fixes from the
features. Regarding your current series, which are the critical patches
you think should be applied to staging before moving imx-drm out of it?
In either case I'll keep going over it the next few days, but maybe you
could hilight the important fixes by resending just them (the locking,
DMA burst and irq ordering related patches seem to be candidates).

regards
Philipp