Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1538225 > unrolled thread

Re: [RFC PATCH 0/3] staging: remove fbdev drivers

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [RFC PATCH 0/3] staging: remove fbdev drivers Benjamin Herrenschmidt <benh@kernel.crashing.org> - 2016-12-08 02:10 +0100
    Re: [RFC PATCH 0/3] staging: remove fbdev drivers Tomi Valkeinen <tomi.valkeinen@ti.com> - 2016-12-08 09:10 +0100
      Re: [RFC PATCH 0/3] staging: remove fbdev drivers Benjamin Herrenschmidt <benh@kernel.crashing.org> - 2016-12-08 22:30 +0100
        Re: [RFC PATCH 0/3] staging: remove fbdev drivers Benjamin Herrenschmidt <benh@kernel.crashing.org> - 2016-12-08 22:50 +0100
          Re: [RFC PATCH 0/3] staging: remove fbdev drivers Daniel Vetter <daniel@ffwll.ch> - 2016-12-09 09:20 +0100
    Re: [RFC PATCH 0/3] staging: remove fbdev drivers Daniel Vetter <daniel@ffwll.ch> - 2016-12-08 11:20 +0100
      Re: [RFC PATCH 0/3] staging: remove fbdev drivers Geert Uytterhoeven <geert@linux-m68k.org> - 2016-12-08 13:20 +0100
        Re: [RFC PATCH 0/3] staging: remove fbdev drivers Daniel Vetter <daniel@ffwll.ch> - 2016-12-08 15:20 +0100
          Re: [RFC PATCH 0/3] staging: remove fbdev drivers Geert Uytterhoeven <geert@linux-m68k.org> - 2016-12-08 15:30 +0100
            Re: [RFC PATCH 0/3] staging: remove fbdev drivers Thomas Petazzoni <thomas.petazzoni@free-electrons.com> - 2016-12-08 15:40 +0100
              Re: [RFC PATCH 0/3] staging: remove fbdev drivers Geert Uytterhoeven <geert@linux-m68k.org> - 2016-12-08 15:50 +0100
                Re: [RFC PATCH 0/3] staging: remove fbdev drivers Daniel Vetter <daniel@ffwll.ch> - 2016-12-08 16:30 +0100
                  Re: [RFC PATCH 0/3] staging: remove fbdev drivers Benjamin Herrenschmidt <benh@kernel.crashing.org> - 2016-12-08 22:40 +0100
                    Re: [RFC PATCH 0/3] staging: remove fbdev drivers Benjamin Herrenschmidt <benh@kernel.crashing.org> - 2016-12-08 23:00 +0100
                      Re: [RFC PATCH 0/3] staging: remove fbdev drivers Daniel Vetter <daniel@ffwll.ch> - 2016-12-09 09:40 +0100
                        Re: [RFC PATCH 0/3] staging: remove fbdev drivers Daniel Vetter <daniel@ffwll.ch> - 2016-12-09 09:50 +0100
                          Re: [RFC PATCH 0/3] staging: remove fbdev drivers Benjamin Herrenschmidt <benh@kernel.crashing.org> - 2016-12-09 12:50 +0100
                            Re: [RFC PATCH 0/3] staging: remove fbdev drivers Daniel Vetter <daniel@ffwll.ch> - 2016-12-09 14:40 +0100
                              Re: [RFC PATCH 0/3] staging: remove fbdev drivers Benjamin Herrenschmidt <benh@kernel.crashing.org> - 2016-12-09 22:20 +0100
                        Re: [RFC PATCH 0/3] staging: remove fbdev drivers Benjamin Herrenschmidt <benh@kernel.crashing.org> - 2016-12-09 12:50 +0100
                          Re: [RFC PATCH 0/3] staging: remove fbdev drivers Geert Uytterhoeven <geert@linux-m68k.org> - 2016-12-09 13:40 +0100
                          Re: [RFC PATCH 0/3] staging: remove fbdev drivers Lucas Stach <l.stach@pengutronix.de> - 2016-12-09 14:20 +0100
                          Re: [RFC PATCH 0/3] staging: remove fbdev drivers Daniel Vetter <daniel@ffwll.ch> - 2016-12-09 14:40 +0100
                            Re: [RFC PATCH 0/3] staging: remove fbdev drivers David Herrmann <dh.herrmann@gmail.com> - 2016-12-09 15:00 +0100
                              Re: [RFC PATCH 0/3] staging: remove fbdev drivers Daniel Vetter <daniel@ffwll.ch> - 2016-12-09 15:10 +0100
                              Re: [RFC PATCH 0/3] staging: remove fbdev drivers Benjamin Herrenschmidt <benh@kernel.crashing.org> - 2016-12-09 21:40 +0100
                  Re: [RFC PATCH 0/3] staging: remove fbdev drivers Daniel Vetter <daniel@ffwll.ch> - 2016-12-09 09:40 +0100
            Re: [RFC PATCH 0/3] staging: remove fbdev drivers Jani Nikula <jani.nikula@linux.intel.com> - 2016-12-08 16:10 +0100
          Re: [RFC PATCH 0/3] staging: remove fbdev drivers Daniel Vetter <daniel@ffwll.ch> - 2016-12-08 15:30 +0100
      Re: [RFC PATCH 0/3] staging: remove fbdev drivers Benjamin Herrenschmidt <benh@kernel.crashing.org> - 2016-12-08 23:40 +0100
        Re: [RFC PATCH 0/3] staging: remove fbdev drivers Dave Airlie <airlied@gmail.com> - 2016-12-09 01:10 +0100
          Re: [RFC PATCH 0/3] staging: remove fbdev drivers Geert Uytterhoeven <geert@linux-m68k.org> - 2016-12-09 09:10 +0100
          Re: [RFC PATCH 0/3] staging: remove fbdev drivers Benjamin Herrenschmidt <benh@kernel.crashing.org> - 2016-12-09 12:50 +0100

Page 1 of 2  [1] 2  Next page →

#1538225 — Re: [RFC PATCH 0/3] staging: remove fbdev drivers

On Wed, 2016-11-23 at 10:03 +0200, Tomi Valkeinen wrote:
> Hi,
> 
> 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.

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.

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.

Ben.

[toc] | [next] | [standalone]

#1538361

[Multipart message — attachments visible in raw view] — view raw

On 08/12/16 03:01, Benjamin Herrenschmidt wrote:
> On Wed, 2016-11-23 at 10:03 +0200, Tomi Valkeinen wrote:
>> Hi,
>>
>> 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.

Then the DRM framework should be improved to be suitable.

> 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.

I don't think that's true. You can have a single fbdev buffer and blit
there all you want, afaik.

> Not everything has a powerful 3D GPU.

We don't use GPU on OMAPs (except for 3D).

 Tomi

[toc] | [prev] | [next] | [standalone]

#1538896

On Thu, 2016-12-08 at 10:01 +0200, Tomi Valkeinen wrote:
> 
> > 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.
> 
> Then the DRM framework should be improved to be suitable.

Dave ? :-)

> > 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.
> 
> I don't think that's true. You can have a single fbdev buffer and blit
> there all you want, afaik.

Well, I had that argument with Dave Airlie which I CCed. The "dumb" ones like
bochsdrmfb, cirrusdrmfb, astdrmfb ... all use shadowing, meaning they use a
lot more memory and cannot do any 2D acceleration for fbcon.

From memory, David claimed you cannot directly work on the fb with a "proper"
DRM driver. Maybe I misunderstood but then the DRM shines by its complete
absence of useful documentation mixed with bazillion layers of APIs and helpers
so it's pretty hard to get ones head around it without wasting very large amounts
of time which I don't have at the moment.

> > Not everything has a powerful 3D GPU.
> 
> We don't use GPU on OMAPs (except for 3D).

The CPU in an OMAP is order of magnitude faster than what I have in an
Aspeed BMC though.

Ben.

[toc] | [prev] | [next] | [standalone]

#1538900

On Fri, 2016-12-09 at 08:23 +1100, Benjamin Herrenschmidt wrote:
> > From memory, David claimed you cannot directly work on the fb with a "proper"
> 
> DRM driver. Maybe I misunderstood but then the DRM shines by its complete
> absence of useful documentation 

That sentence should have been in the past, it does look like
documentation has been landing in the tree this year ! yay ! I'll go
off read it.

> mixed with bazillion layers of APIs and helpers
> so it's pretty hard to get ones head around it without wasting very large amounts
> of time which I don't have at the moment.

Ben.

[toc] | [prev] | [next] | [standalone]

#1539179

On Fri, Dec 09, 2016 at 08:43:13AM +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2016-12-09 at 08:23 +1100, Benjamin Herrenschmidt wrote:
> > > From memory, David claimed you cannot directly work on the fb with a "proper"
> > 
> > DRM driver. Maybe I misunderstood but then the DRM shines by its complete
> > absence of useful documentation 
> 
> That sentence should have been in the past, it does look like
> documentation has been landing in the tree this year ! yay ! I'll go
> off read it.

We've been building up that documentation for years now, not sure where
exactly you've looked in the past ;-)

And to make sure you're looking at the right stuff: Please run

$ make DOCBOOKS="" htmldocs

and then look at Documentation/output/gpu. Otherwise all the kerneldoc
stuff isn't pulled in, and a lot of the overview sections (not just
abi/struct docs) are in there.

And if something looks fishy or doesn't make sense, please raise it here
or on #dri-devel on freenode so that we can improve the docs.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[toc] | [prev] | [next] | [standalone]

#1538415

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:
> > Hi,
> > 
> > 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.

> 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.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[toc] | [prev] | [next] | [standalone]

#1538475

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.

>> 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 ;-)

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[toc] | [prev] | [next] | [standalone]

#1538564

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

[toc] | [prev] | [next] | [standalone]

#1538568

Hi Daniel,

On Thu, Dec 8, 2016 at 3:02 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
> 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.

That's fast! Only two weeks ago you said:

| Bummer, they still haven't landed. But afaik there's at least 4 of
| them floating around in various places ...

>> > 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.

My apologies. In hindsight, my comment sounded much more insulting than it
was meant to be.

> If you're this good at mainting gpu and display subsystems, maybe you want
> to take over?

No please ;-)

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[toc] | [prev] | [next] | [standalone]

#1538577

Hello,

On Thu, 8 Dec 2016 15:22:09 +0100, Geert Uytterhoeven wrote:

> > Wut. We have like 20+ small atomic drivers nowdays.  
> 
> That's fast! Only two weeks ago you said:
> 
> | Bummer, they still haven't landed. But afaik there's at least 4 of
> | them floating around in various places ...

You're not talking about the same thing I believe.

When Daniel says "small atomic drivers", he talks about the relatively
small DRM drivers for SoC display controllers, such as the ones you can
find in ARM SoCs.

When you say "small driver", you're thinking about drivers for I2C or
SPI connected displays.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[toc] | [prev] | [next] | [standalone]

#1538590

Hi Thomas,

On Thu, Dec 8, 2016 at 3:37 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> On Thu, 8 Dec 2016 15:22:09 +0100, Geert Uytterhoeven wrote:
>> > Wut. We have like 20+ small atomic drivers nowdays.
>>
>> That's fast! Only two weeks ago you said:
>>
>> | Bummer, they still haven't landed. But afaik there's at least 4 of
>> | them floating around in various places ...
>
> You're not talking about the same thing I believe.
>
> When Daniel says "small atomic drivers", he talks about the relatively
> small DRM drivers for SoC display controllers, such as the ones you can
> find in ARM SoCs.
>
> When you say "small driver", you're thinking about drivers for I2C or
> SPI connected displays.

No, I wasn't thinking about I2C or SPI connected displays, but about simple
dumb memory-mapped frame buffers, which is what fbdev was initially
developed for.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[toc] | [prev] | [next] | [standalone]

#1538615

[back from my walk, the sunset here is stellar ;-)]

On Thu, Dec 08, 2016 at 03:44:30PM +0100, Geert Uytterhoeven wrote:
> Hi Thomas,
> 
> On Thu, Dec 8, 2016 at 3:37 PM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
> > On Thu, 8 Dec 2016 15:22:09 +0100, Geert Uytterhoeven wrote:
> >> > Wut. We have like 20+ small atomic drivers nowdays.
> >>
> >> That's fast! Only two weeks ago you said:
> >>
> >> | Bummer, they still haven't landed. But afaik there's at least 4 of
> >> | them floating around in various places ...
> >
> > You're not talking about the same thing I believe.
> >
> > When Daniel says "small atomic drivers", he talks about the relatively
> > small DRM drivers for SoC display controllers, such as the ones you can
> > find in ARM SoCs.
> >
> > When you say "small driver", you're thinking about drivers for I2C or
> > SPI connected displays.
> 
> No, I wasn't thinking about I2C or SPI connected displays, but about simple
> dumb memory-mapped frame buffers, which is what fbdev was initially
> developed for.

Yeah, small drivers like these we have piles now, things exploded a lot
after atomic landed two years ago. And they seem to shrink with every
release a bit more (since lots more drivers gives you lots more insight
into what other refactorings would make sense). Those we have a big pile
of, and nowadays (at least with developers expirienced with upstream, but
not necessarily with drm) it takes but a few weeks from initial submission
to getting them merged.

What we don't yet have a nice tidy example driver of is the even simpler
"dumb framebuffer behind a slow bus with explicit/manual upload", for like
small i2c/spi panels (and conceptually also usb, even though there bw and
panel size are a bit scaled up). We've gained some really nice helpers for
this this year, and there's 3 drivers in-flight to make use of it. But
since that's right now just a hobbyist effort it's moving a bit slower
(and I was mistaken a few weeks back where I assumed that one of them
landed already).

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[toc] | [prev] | [next] | [standalone]

#1538899

On Thu, 2016-12-08 at 16:21 +0100, Daniel Vetter wrote:
> Yeah, small drivers like these we have piles now, things exploded a lot
> after atomic landed two years ago. And they seem to shrink with every
> release a bit more (since lots more drivers gives you lots more insight
> into what other refactorings would make sense). Those we have a big pile
> of, and nowadays (at least with developers expirienced with upstream, but
> not necessarily with drm) it takes but a few weeks from initial submission
> to getting them merged.
> 
> What we don't yet have a nice tidy example driver of is the even simpler
> "dumb framebuffer behind a slow bus with explicit/manual upload", for like
> small i2c/spi panels (and conceptually also usb, even though there bw and
> panel size are a bit scaled up). We've gained some really nice helpers for
> this this year, and there's 3 drivers in-flight to make use of it. But
> since that's right now just a hobbyist effort it's moving a bit slower
> (and I was mistaken a few weeks back where I assumed that one of them
> landed already).

What I find usually confusing is the interaction with the TTM and
overall fb memory management, when trying to plumb in simple 2d accel
to speed up fbcon mostly (but I don't mind making it available to user
space via ioctls, though that's not a priority).

As I mentioned earlier, probably 1 or 2 years ago, Dave made the
argument that shadowing through memory was necessary and precluded 2D
accel, though I don't fully remember the root of the argument. If that
is indeed not the case, then my main objection is lifted.

Cheers,
Ben.

[toc] | [prev] | [next] | [standalone]

#1538903

On Fri, 2016-12-09 at 08:34 +1100, Benjamin Herrenschmidt wrote:
> As I mentioned earlier, probably 1 or 2 years ago, Dave made the
> argument that shadowing through memory was necessary and precluded 2D
> accel, though I don't fully remember the root of the argument. If that
> is indeed not the case, then my main objection is lifted.

Things seem to change quickly as Daniel pointed out.

So ast and cirrus seem to still use a manual dirty tracking and
shadowing (though I'm not sure why), but the infrastructure for
that has moved from the drivers to the helpers.

bochs (qemu) doesn't seem to anymore from what I can see as it
doesn't have a ->dirty callback.

Cheers,
Ben.

[toc] | [prev] | [next] | [standalone]

#1539186

On Fri, Dec 09, 2016 at 08:57:29AM +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2016-12-09 at 08:34 +1100, Benjamin Herrenschmidt wrote:
> > As I mentioned earlier, probably 1 or 2 years ago, Dave made the
> > argument that shadowing through memory was necessary and precluded 2D
> > accel, though I don't fully remember the root of the argument. If that
> > is indeed not the case, then my main objection is lifted.
> 
> Things seem to change quickly as Daniel pointed out.
> 
> So ast and cirrus seem to still use a manual dirty tracking and
> shadowing (though I'm not sure why), but the infrastructure for
> that has moved from the drivers to the helpers.
> 
> bochs (qemu) doesn't seem to anymore from what I can see as it
> doesn't have a ->dirty callback.

Yeah if you have discrete vram then your dumb display driver isn't all
that pretty. We essentially just have the few drivers Dave hacked up to be
able to boot some servers. And there's definitely lots of room for more
shared code for those, and also some better infrastructure and helpers to
share more cod and make them better.

The massive pile of dumb framebuffers we all merged over the past 2 years
all use system/dma memory for scanout, and for those we have the very nice
cma helpers that take care of everything for you. So it is possible, only
reason vram dumb buffers look worse is that there's only 3 and no one
cares about them, vs about 20 and a very active community of contributors
(also for core drm improvements) for the other case.

Althought the MXSFB driver that just landed does use ttm and vram, so
maybe that's now improving too.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[toc] | [prev] | [next] | [standalone]

#1539190

On Fri, Dec 09, 2016 at 09:34:42AM +0100, Daniel Vetter wrote:
> On Fri, Dec 09, 2016 at 08:57:29AM +1100, Benjamin Herrenschmidt wrote:
> > On Fri, 2016-12-09 at 08:34 +1100, Benjamin Herrenschmidt wrote:
> > > As I mentioned earlier, probably 1 or 2 years ago, Dave made the
> > > argument that shadowing through memory was necessary and precluded 2D
> > > accel, though I don't fully remember the root of the argument. If that
> > > is indeed not the case, then my main objection is lifted.
> > 
> > Things seem to change quickly as Daniel pointed out.
> > 
> > So ast and cirrus seem to still use a manual dirty tracking and
> > shadowing (though I'm not sure why), but the infrastructure for
> > that has moved from the drivers to the helpers.
> > 
> > bochs (qemu) doesn't seem to anymore from what I can see as it
> > doesn't have a ->dirty callback.
> 
> Yeah if you have discrete vram then your dumb display driver isn't all
> that pretty. We essentially just have the few drivers Dave hacked up to be
> able to boot some servers. And there's definitely lots of room for more
> shared code for those, and also some better infrastructure and helpers to
> share more cod and make them better.

And since I failed to make this clear: There's not really a fundamental
reason ast and cirrus use the dirty tracking for fbdev. It's just that
doing it that way was the fastest way to get those servers booting, and
ever since no one cared. It's a bit tricky to do right because fbdev
assumes it always own the framebuffer and that it never moves, whereas drm
has a multi-master model and proper isolation. IIrc we've hacked up
something once, and if there's indeed more interest into vram dumb buffer
drivers I'm pretty sure we can grow some nice ttm fb helpers (like the cma
fb helpers we have) to make it all pretty and nice and fast and
essentially plug-in-and-forget from a driver authors pov.

Cheers, Daniel

> The massive pile of dumb framebuffers we all merged over the past 2 years
> all use system/dma memory for scanout, and for those we have the very nice
> cma helpers that take care of everything for you. So it is possible, only
> reason vram dumb buffers look worse is that there's only 3 and no one
> cares about them, vs about 20 and a very active community of contributors
> (also for core drm improvements) for the other case.
> 
> Althought the MXSFB driver that just landed does use ttm and vram, so
> maybe that's now improving too.
> -Daniel
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[toc] | [prev] | [next] | [standalone]

#1539298

On Fri, 2016-12-09 at 09:41 +0100, Daniel Vetter wrote:
> 
> And since I failed to make this clear: There's not really a
> fundamental
> reason ast and cirrus use the dirty tracking for fbdev. It's just that
> doing it that way was the fastest way to get those servers booting, and
> ever since no one cared. It's a bit tricky to do right because fbdev
> assumes it always own the framebuffer and that it never moves, 

That can be worked around from my memories of hacking fbdev many years
ago. Basically fbdev only owns it if it's the current VT and you can
make it release it if the user switches to KD_GRAPHICS which userspace
should always do before taking over.

As for multi userspace client, well, swapping an mmap between HW and
memory backing store is a somewhat solved problem already.

> whereas drm has a multi-master model and proper isolation. IIrc we've hacked up
> something once, and if there's indeed more interest into vram dumb buffer
> drivers I'm pretty sure we can grow some nice ttm fb helpers (like the cma
> fb helpers we have) to make it all pretty and nice and fast and
> essentially plug-in-and-forget from a driver authors pov.

That would be nice. I don't have the bandwidth to swap-in enough
understanding of TTM guts right now but I might look into it some time next 
year if nobody beats me to it.

> Cheers, Daniel
> 
> > The massive pile of dumb framebuffers we all merged over the past 2 years
> > all use system/dma memory for scanout, and for those we have the very nice
> > cma helpers that take care of everything for you. So it is possible, only
> > reason vram dumb buffers look worse is that there's only 3 and no one
> > cares about them, vs about 20 and a very active community of contributors
> > (also for core drm improvements) for the other case.
> > 
> > Althought the MXSFB driver that just landed does use ttm and vram, so
> > maybe that's now improving too.
> > -Daniel
> > -- 
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
> 
> 

[toc] | [prev] | [next] | [standalone]

#1539348

On Fri, Dec 09, 2016 at 10:48:07PM +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2016-12-09 at 09:41 +0100, Daniel Vetter wrote:
> > 
> > And since I failed to make this clear: There's not really a
> > fundamental
> > reason ast and cirrus use the dirty tracking for fbdev. It's just that
> > doing it that way was the fastest way to get those servers booting, and
> > ever since no one cared. It's a bit tricky to do right because fbdev
> > assumes it always own the framebuffer and that it never moves, 
> 
> That can be worked around from my memories of hacking fbdev many years
> ago. Basically fbdev only owns it if it's the current VT and you can
> make it release it if the user switches to KD_GRAPHICS which userspace
> should always do before taking over.
> 
> As for multi userspace client, well, swapping an mmap between HW and
> memory backing store is a somewhat solved problem already.

Hm, I didn't know that, but then all existing drm drivers have fairly
simplistic fbdev mmap implementations.

> > whereas drm has a multi-master model and proper isolation. IIrc we've hacked up
> > something once, and if there's indeed more interest into vram dumb buffer
> > drivers I'm pretty sure we can grow some nice ttm fb helpers (like the cma
> > fb helpers we have) to make it all pretty and nice and fast and
> > essentially plug-in-and-forget from a driver authors pov.
> 
> That would be nice. I don't have the bandwidth to swap-in enough
> understanding of TTM guts right now but I might look into it some time next 
> year if nobody beats me to it.

Probably best would be to first extract some helpers for ttm based vram
dumb buffer management, and then start to implement some of the
improvements so that all drivers can benefit. Like you've said it's not
rocket science, it just needs to be done ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[toc] | [prev] | [next] | [standalone]

#1539682

On Fri, 2016-12-09 at 14:35 +0100, Daniel Vetter wrote:
> > As for multi userspace client, well, swapping an mmap between HW and
> > memory backing store is a somewhat solved problem already.
> 
> Hm, I didn't know that, but then all existing drm drivers have fairly
> simplistic fbdev mmap implementations.

Hrm, I though the TTM did it ... I remember talking with Thomas
Hellstrom about that back in the day... you use unmap_mapping_range
to unmap the existing mappings basically so you can take new faults
and route them to a different page, but I can't see a call in there
so maybe he ended up not doing it.

We used to do that on Cell to "context switch" the local memory of
the SPU engines between the real SPU and the backing store. It's not
very hard to do.
 
The main issue is that the mapping attributes change between cached
and non-cached under the hood, so users have to be careful not to do
things like use instructions that only work on one type of mapping
(or do things like misaligned accesses).

> > > whereas drm has a multi-master model and proper isolation. IIrc we've hacked up
> > > something once, and if there's indeed more interest into vram dumb buffer
> > > drivers I'm pretty sure we can grow some nice ttm fb helpers (like the cma
> > > fb helpers we have) to make it all pretty and nice and fast and
> > > essentially plug-in-and-forget from a driver authors pov.
> > 
> > That would be nice. I don't have the bandwidth to swap-in enough
> > understanding of TTM guts right now but I might look into it some time next 
> > year if nobody beats me to it.
> 
> Probably best would be to first extract some helpers for ttm based vram
> dumb buffer management, and then start to implement some of the
> improvements so that all drivers can benefit. Like you've said it's not
> rocket science, it just needs to be done ;-)

Right :-)

Though getting ones head around the infrastructure in the DRM does take
time :-) There's a lot of stuff in there, between TTM, GEM etc... and
not all of it completely "obvious" ...

Cheers,
Ben.

> -Daniel
> -- 

[toc] | [prev] | [next] | [standalone]

#1539297

On Fri, 2016-12-09 at 09:34 +0100, Daniel Vetter wrote:
> Yeah if you have discrete vram then your dumb display driver isn't all
> that pretty. We essentially just have the few drivers Dave hacked up to be
> able to boot some servers. And there's definitely lots of room for more
> shared code for those, and also some better infrastructure and helpers to
> share more cod and make them better.
> 
> The massive pile of dumb framebuffers we all merged over the past 2 years
> all use system/dma memory for scanout, and for those we have the very nice
> cma helpers that take care of everything for you. 

Do they work if the system/DMA memory has to be physically contiguous
and at a fixed address ? The AST "ARM side" GPU is like that.

> So it is possible, only reason vram dumb buffers look worse is that there's
> only 3 and no one cares about them, vs about 20 and a very active community
> of contributors (also for core drm improvements) for the other case.

Well, we could move offb to drm while at it I suppose that would be another
one (offb is the "dumb driver based on pre-programmed output by firmware).

> Althought the MXSFB driver that just landed does use ttm and vram, so
> maybe that's now improving too.

Cheers,
Ben.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.kernel

csiph-web