linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: "Benjamin Herrenschmidt" <benh@kernel.crashing.org>,
	"Tomi Valkeinen" <tomi.valkeinen@ti.com>,
	"Linux Fbdev development list" <linux-fbdev@vger.kernel.org>,
	"DRI Development" <dri-devel@lists.freedesktop.org>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Thomas Petazzoni" <thomas.petazzoni@free-electrons.com>,
	"Noralf Trønnes" <noralf@tronnes.org>,
	"Sudip Mukherjee" <sudipm.mukherjee@gmail.com>,
	"Teddy Wang" <teddy.wang@siliconmotion.com>,
	"Arnaud Patard" <arnaud.patard@rtp-net.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH 0/3] staging: remove fbdev drivers
Date: Thu, 8 Dec 2016 15:02:10 +0100	[thread overview]
Message-ID: <20161208140210.rfyjf2265flsfpfj@phenom.ffwll.local> (raw)
In-Reply-To: <CAMuHMdWsKqgvB8QtG6SjHO-mceB5fRK9G51y8RYeos0Ym7pgdA@mail.gmail.com>

On Thu, Dec 08, 2016 at 01:15:56PM +0100, Geert Uytterhoeven wrote:
> On Thu, Dec 8, 2016 at 11:10 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> > On Thu, Dec 08, 2016 at 12:01:19PM +1100, Benjamin Herrenschmidt wrote:
> >> On Wed, 2016-11-23 at 10:03 +0200, Tomi Valkeinen wrote:
> >> > Since the fbdev framework is in maintenance mode and all new display drivers
> >> > should be made with the DRM framework, remove the fbdev drivers from staging.
> >> >
> >> > Note: the patches are created with git format-patch -D, so they can't be
> >> > applied. Only for review.
> >>
> >> I missed the discussion where this decision was made, I admit I am
> >> unimpressed by it.
> >>
> >> DRM drivers don't strike me as suitable for small/slow cores with dumb
> >> framebuffers or simple 2D only accel, such as the one found in the ASpeed
> >> BMCs.
> >
> > We have a helper for simple drivers now, if you take into account the
> > massive helper libraries for everything that comes along with drm I expect
> > if even dumb panels behind slow spi buses drm is now the more suitable
> > subsytem.
> 
> This has been going on your years:
>   1. Fbdev is obsolete, everybody should use DRM instead!
>   2. Can you please point me to a small sample driver for a dumb frame buffer?
>   3. Several are being written, but none of them is upstream yet.
>   4. Goto 1.

Wut. We have like 20+ small atomic drivers nowdays.

> >> With drmfb you basically have to shadow everything into memory & copy
> >> over everything, and locks you out of simple 2D accel. For a simple text
> >> console the result is orders of magnitude slower and memory hungry than
> >> a simple fbdev.
> >
> > Not true, we have full fbdev emulation, and drivers can implement the 2d
> > accel in there. And a bunch of them do. It's just that most teams decided
> > that this is pointless waste of their time.j
> >
> >> At least that was the case last I looked at the DRM stuff with Dave,
> >> maybe things have changed...
> >>
> >> Not everything has a powerful 3D GPU.
> >
> > That's correct, and drm can cope. And compared to fbdev there's a very
> > active community who improves&refactors it every kernel release to make it
> > even better. Since about 2 years (when atomic landed) we merge new drivers at
> > a rate of 2-3 per kernel release, and those new drivers get ever simpler
> > and smaller thanks to all this work.
> 
> You mean the kind of refactoring that causes severe merge conflicts between
> drm-next and Linus' tree about every single day?
> (sorry, couldn't resist ;-)

Yeah, for a subsystem that only consists of 10% of the overall kernel (by
patch count) we do an extremly shitty job. Maybe we should just all slow
down and stop merging support for new hw, and fuck Android and CrOS and
the billions of devices that don't ship upstream, who cares about those
folks.

If you're this good at mainting gpu and display subsystems, maybe you want
to take over?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

  reply	other threads:[~2016-12-08 14:19 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-23  8:03 [RFC PATCH 0/3] staging: remove fbdev drivers Tomi Valkeinen
2016-11-23  8:03 ` [RFC PATCH 1/3] staging: remove xgifb Tomi Valkeinen
2016-11-23  8:03 ` [RFC PATCH 2/3] staging: remove sm750fb Tomi Valkeinen
2016-11-23  8:03 ` [RFC PATCH 3/3] staging: remove fbtft Tomi Valkeinen
2016-11-23 17:26   ` Noralf Trønnes
2016-11-24  8:36     ` Tomi Valkeinen
2016-11-23 20:12   ` Drew Fustini
2016-11-23  8:19 ` [RFC PATCH 0/3] staging: remove fbdev drivers Daniel Vetter
2016-11-23  8:21   ` Tomi Valkeinen
2016-11-23  8:25   ` Geert Uytterhoeven
2016-11-23  8:45     ` Daniel Vetter
2016-11-23  8:52 ` Greg Kroah-Hartman
2016-11-23  9:12   ` Tomi Valkeinen
2016-11-23  9:49     ` Greg Kroah-Hartman
2016-11-23 10:05     ` Thomas Petazzoni
2016-12-22 20:36       ` Andy Shevchenko
2016-12-08 22:00     ` Sudip Mukherjee
2016-12-08  1:01 ` Benjamin Herrenschmidt
2016-12-08  8:01   ` Tomi Valkeinen
2016-12-08 21:23     ` Benjamin Herrenschmidt
2016-12-08 21:43       ` Benjamin Herrenschmidt
2016-12-09  8:13         ` Daniel Vetter
2016-12-13  7:36       ` Gerd Hoffmann
2016-12-08 10:10   ` Daniel Vetter
2016-12-08 12:15     ` Geert Uytterhoeven
2016-12-08 14:02       ` Daniel Vetter [this message]
2016-12-08 14:22         ` Geert Uytterhoeven
2016-12-08 14:37           ` Thomas Petazzoni
2016-12-08 14:44             ` Geert Uytterhoeven
2016-12-08 15:21               ` Daniel Vetter
2016-12-08 21:34                 ` Benjamin Herrenschmidt
2016-12-08 21:57                   ` Benjamin Herrenschmidt
2016-12-09  8:34                     ` Daniel Vetter
2016-12-09  8:41                       ` Daniel Vetter
2016-12-09 11:48                         ` Benjamin Herrenschmidt
2016-12-09 13:35                           ` Daniel Vetter
2016-12-09 20:27                             ` Benjamin Herrenschmidt
2016-12-13  7:18                               ` Michel Dänzer
2016-12-09 11:44                       ` Benjamin Herrenschmidt
2016-12-09 12:33                         ` Geert Uytterhoeven
2016-12-09 13:19                         ` Lucas Stach
2016-12-09 13:33                         ` Daniel Vetter
2016-12-09 13:57                           ` David Herrmann
2016-12-09 14:04                             ` Daniel Vetter
2016-12-09 20:29                             ` Benjamin Herrenschmidt
2016-12-09  8:30                 ` Daniel Vetter
2016-12-08 14:59           ` Jani Nikula
2016-12-08 14:22         ` Daniel Vetter
2016-12-08 21:28     ` Benjamin Herrenschmidt
2016-12-09  0:08       ` Dave Airlie
2016-12-09  8:04         ` Geert Uytterhoeven
2016-12-09 11:40         ` Benjamin Herrenschmidt
2016-12-13  7:33         ` Gerd Hoffmann
2016-12-13 15:17     ` Laurent Pinchart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20161208140210.rfyjf2265flsfpfj@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=arnaud.patard@rtp-net.org \
    --cc=benh@kernel.crashing.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=geert@linux-m68k.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=noralf@tronnes.org \
    --cc=sudipm.mukherjee@gmail.com \
    --cc=teddy.wang@siliconmotion.com \
    --cc=thomas.petazzoni@free-electrons.com \
    --cc=tomi.valkeinen@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).