[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151022195813.GH16848@phenom.ffwll.local>
Date: Thu, 22 Oct 2015 21:58:13 +0200
From: Daniel Vetter <daniel@...ll.ch>
To: Rob Herring <robh@...nel.org>
Cc: Eric Anholt <eric@...olt.net>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
dri-devel <dri-devel@...ts.freedesktop.org>
Subject: Re: [GIT PULL] Raspberry Pi KMS driver
On Thu, Oct 22, 2015 at 12:40:23PM -0500, Rob Herring wrote:
> On Wed, Oct 21, 2015 at 4:53 AM, Eric Anholt <eric@...olt.net> wrote:
> > Dave suggested it was time to just send a pull request on the driver, so
> > here goes:
>
> Why is that when the binding is still under discussion[1]? Even the
> agreed changes never got reposted.
Bit a longer story, so here we go: I don't really like drivers/staging
since it's a cage where drivers get forgotten about, and even if there is
activity it's completely separate from all the other drm drivers. Which
doesn't help with collaboration, which is the entire point really of
upstreaming.
Otoh I really like how drivers/staging allows not-quite-ready drivers to
get in and get more visibility. So for drm I think the right approach is
to just merge drivers which are reasonable close to good enough, and fix
up anything erregrious once merged. This might be special for drm, since
gpus change ridiculously fast, resulting in anyone contributing for more
than 2-3 years to be constantly busy cleaning up past code that turned out
a mistake in light of todays hardware. I think that means overall drm has
a lower bar to entry and much higher acceptance for crap. And there's lots
of it. Could very well be that most of the drm subsystem should be in
drivers/staging by everyone else's standard.
For this specific case here of the rpi driver the only ongoing thing was
the dt binding discussion, and it didn't look like it would reach closure
anytime soon. On top of that this driver is for rpi specifically (vc5 will
require a completely new driver for a bunch of reasons), and on those
boards the boot loader will never ship a dt file, it will always come from
the kernel. Which means it's really just an internal interface and there's
zero concerns about compatibility.
Also, besides dt Eric's driver was in excellent shape. Given all that I've
seen no reason to delay this any longer and recommended we just pull it
in.
Yours, Daniel
>
> Rob
>
> [1] https://lkml.org/lkml/2015/10/9/676
>
> >
> > The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f:
> >
> > Linux 4.3-rc1 (2015-09-12 16:35:56 -0700)
> >
> > are available in the git repository at:
> >
> > http://github.com/anholt/linux drm-vc4-next-2015-10-21
> >
> > for you to fetch changes up to 98a44504541c6befb28366eb9ec432ba44070dd9:
> >
> > drm/vc4: Allow vblank to be disabled (2015-10-21 10:33:13 +0100)
> >
> > ----------------------------------------------------------------
> > This pull request introduces the vc4 driver, for kernel modesetting on
> > the Raspberry Pi (bcm2835/bcm2836 architectures). It currently
> > supports a display plane and cursor on the HDMI output. The driver
> > doesn't do 3D, power management, or overlay planes yet.
> >
> > ----------------------------------------------------------------
> > Derek Foreman (2):
> > drm/vc4: Use the fbdev_cma helpers
> > drm/vc4: Allow vblank to be disabled
> >
> > Eric Anholt (2):
> > drm/vc4: Add devicetree bindings for VC4.
> > drm/vc4: Add KMS support for Raspberry Pi.
> >
> > .../devicetree/bindings/display/brcm,bcm-vc4.txt | 65 ++
> > drivers/gpu/drm/Kconfig | 2 +
> > drivers/gpu/drm/Makefile | 1 +
> > drivers/gpu/drm/vc4/Kconfig | 13 +
> > drivers/gpu/drm/vc4/Makefile | 17 +
> > drivers/gpu/drm/vc4/vc4_bo.c | 52 ++
> > drivers/gpu/drm/vc4/vc4_crtc.c | 672 +++++++++++++++++++++
> > drivers/gpu/drm/vc4/vc4_debugfs.c | 39 ++
> > drivers/gpu/drm/vc4/vc4_drv.c | 298 +++++++++
> > drivers/gpu/drm/vc4/vc4_drv.h | 145 +++++
> > drivers/gpu/drm/vc4/vc4_hdmi.c | 590 ++++++++++++++++++
> > drivers/gpu/drm/vc4/vc4_hvs.c | 163 +++++
> > drivers/gpu/drm/vc4/vc4_kms.c | 67 ++
> > drivers/gpu/drm/vc4/vc4_plane.c | 320 ++++++++++
> > drivers/gpu/drm/vc4/vc4_regs.h | 570 +++++++++++++++++
> > 15 files changed, 3014 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
> > create mode 100644 drivers/gpu/drm/vc4/Kconfig
> > create mode 100644 drivers/gpu/drm/vc4/Makefile
> > create mode 100644 drivers/gpu/drm/vc4/vc4_bo.c
> > create mode 100644 drivers/gpu/drm/vc4/vc4_crtc.c
> > create mode 100644 drivers/gpu/drm/vc4/vc4_debugfs.c
> > create mode 100644 drivers/gpu/drm/vc4/vc4_drv.c
> > create mode 100644 drivers/gpu/drm/vc4/vc4_drv.h
> > create mode 100644 drivers/gpu/drm/vc4/vc4_hdmi.c
> > create mode 100644 drivers/gpu/drm/vc4/vc4_hvs.c
> > create mode 100644 drivers/gpu/drm/vc4/vc4_kms.c
> > create mode 100644 drivers/gpu/drm/vc4/vc4_plane.c
> > create mode 100644 drivers/gpu/drm/vc4/vc4_regs.h
> >
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel@...ts.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> _______________________________________________
> dri-devel mailing list
> dri-devel@...ts.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists