From: Daniel Vetter <hidden> Date: 2016-11-23 08:19:38
On Wed, Nov 23, 2016 at 10:03:10AM +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.
+1 from my side. Now that we have the simple pipe helpers in drm-kms, and
a few drivers starting to use them, there's really no reasons left anymore
to have fbdev drivers.
And if anyone wants to use the code as hw documentation, git will keep it
forever.
-Daniel
From: Tomi Valkeinen <hidden> Date: 2016-11-23 08:21:59
On 23/11/16 10:19, Daniel Vetter wrote:
On Wed, Nov 23, 2016 at 10:03:10AM +0200, Tomi Valkeinen wrote:
quoted
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.
+1 from my side. Now that we have the simple pipe helpers in drm-kms, and
a few drivers starting to use them, there's really no reasons left anymore
to have fbdev drivers.
Well, I think there's the MMU problem. If I recall right, someone said
DRM doesn't compile/work without MMU.
Tomi
Hi Daniel,
On Wed, Nov 23, 2016 at 9:19 AM, Daniel Vetter [off-list ref] wrote:
On Wed, Nov 23, 2016 at 10:03:10AM +0200, Tomi Valkeinen wrote:
quoted
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.
+1 from my side. Now that we have the simple pipe helpers in drm-kms, and
a few drivers starting to use them, there's really no reasons left anymore
to have fbdev drivers.
I haven't been following this that closely, so can you please point me to a
sample DRM driver using this simple pipe helper?
Thanks!
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
On Wed, Nov 23, 2016 at 10:03:10AM +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 only want to remove these drivers if we have the same functionality in
mainline for their hardware. If not, that's a bit rude to those who
actually use them today, don't you think?
thanks,
greg k-h
From: Daniel Vetter <hidden> Date: 2016-11-23 09:00:57
On Wed, Nov 23, 2016 at 9:25 AM, Geert Uytterhoeven
[off-list ref] wrote:
Hi Daniel,
On Wed, Nov 23, 2016 at 9:19 AM, Daniel Vetter [off-list ref] wrote:
quoted
On Wed, Nov 23, 2016 at 10:03:10AM +0200, Tomi Valkeinen wrote:
quoted
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.
+1 from my side. Now that we have the simple pipe helpers in drm-kms, and
a few drivers starting to use them, there's really no reasons left anymore
to have fbdev drivers.
I haven't been following this that closely, so can you please point me to a
sample DRM driver using this simple pipe helper?
Bummer, they still haven't landed. But afaik there's at least 4 of
them floating around in various places ...
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
From: Tomi Valkeinen <hidden> Date: 2016-11-23 09:14:14
On 23/11/16 10:52, Greg Kroah-Hartman wrote:
On Wed, Nov 23, 2016 at 10:03:10AM +0200, Tomi Valkeinen wrote:
quoted
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 only want to remove these drivers if we have the same functionality in
mainline for their hardware. If not, that's a bit rude to those who
actually use them today, don't you think?
What does it mean for a driver to be in staging? I thought it's
basically the same as the driver being out-of-tree, with the difference
that the code is in a central git repository for easier co-operation.
If that's what staging means, then I would reject the staging fbdev
drivers the same way as I'd reject new fbdev drivers sent as patches to
the list.
Or do you mean that we should keep the drivers in staging until there's
a matching DRM driver, but drop any plans to move the drivers from
staging to drivers/video/? If so, I'm fine with that. This is an RFC,
mostly to raise some discussion and push people to actually write those
DRM drivers =).
Tomi
On Wed, Nov 23, 2016 at 11:12:32AM +0200, Tomi Valkeinen wrote:
On 23/11/16 10:52, Greg Kroah-Hartman wrote:
quoted
On Wed, Nov 23, 2016 at 10:03:10AM +0200, Tomi Valkeinen wrote:
quoted
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 only want to remove these drivers if we have the same functionality in
mainline for their hardware. If not, that's a bit rude to those who
actually use them today, don't you think?
What does it mean for a driver to be in staging? I thought it's
basically the same as the driver being out-of-tree, with the difference
that the code is in a central git repository for easier co-operation.
Yes, but it also allows people to use their hardware, for drivers that
are not "quite ready".
If that's what staging means, then I would reject the staging fbdev
drivers the same way as I'd reject new fbdev drivers sent as patches to
the list.
Rejecting valid drivers for hardware that people have today is not a
nice thing. If you want to just move them into staging so that people
can get their hardware working while people port to the new apis, I will
be glad to take them.
Or do you mean that we should keep the drivers in staging until there's
a matching DRM driver, but drop any plans to move the drivers from
staging to drivers/video/? If so, I'm fine with that. This is an RFC,
mostly to raise some discussion and push people to actually write those
DRM drivers =).
I do not want to move these to drivers/video/ and they should just stay
where they are until a matching DRM driver is present in the tree.
thanks,
greg k-h
From: Thomas Petazzoni <hidden> Date: 2016-11-23 10:06:20
Hello,
On Wed, 23 Nov 2016 11:12:32 +0200, Tomi Valkeinen wrote:
quoted
I only want to remove these drivers if we have the same functionality in
mainline for their hardware. If not, that's a bit rude to those who
actually use them today, don't you think?
What does it mean for a driver to be in staging? I thought it's
basically the same as the driver being out-of-tree, with the difference
that the code is in a central git repository for easier co-operation.
If that's what staging means, then I would reject the staging fbdev
drivers the same way as I'd reject new fbdev drivers sent as patches to
the list.
Or do you mean that we should keep the drivers in staging until there's
a matching DRM driver, but drop any plans to move the drivers from
staging to drivers/video/? If so, I'm fine with that. This is an RFC,
mostly to raise some discussion and push people to actually write those
DRM drivers =).
The very reason why I submitted those drivers for staging is because
lots and lots of people were using out of tree kernel modules for these
drivers, which was really a pain.
If you now remove those drivers from staging, then those folks will be
back in the situation they originally were, using annoying out of tree
modules.
I'm all for removing fbtft drivers progressively as a matching
DRM-based driver is available for the same hardware. However, if there
is no DRM-based support for a given piece of hardware supported by
fbtft, I'd prefer if we kept the fbtft driver for this hardware.
Of course, at some point, we'll have a bunch of left-over fbtft drivers
that nobody will have converted, and we'll have to take the decision to
remove them all. But to me, the DRM-based solution for those displays
is still very young, so it makes sense to leave a bit of time for
people to convert the drivers over to the new DRM-based solution.
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
Since the fbdev framework is in maintenance mode and all new display
drivers should be made with the DRM framework, remove fbtft from
staging.
Signed-off-by: Tomi Valkeinen <redacted>
FYI:
I'm working on a drm version of fbtft: https://github.com/notro/tinydrm
I have just picked it up after a 4 month break.
It is ready for a new review, except that I want to test how it would
perform as a drm userspace driver first (for spi that would mean adding
dma-buf support to spidev). If this performs well, then all the fbtft
drivers could move to userspace. If it doesn't, then at least (very slow)
i2c and e-ink displays could be userspace drivers.
Noralf.
On Wed, Nov 23, 2016 at 2:03 AM, Tomi Valkeinen [off-list ref] wrote:
Since the fbdev framework is in maintenance mode and all new display
drivers should be made with the DRM framework, remove fbtft from
staging.
Signed-off-by: Tomi Valkeinen <redacted>
I'd request that fbtft please be kept in staging until a successor is
ready, such as Noralf's tinydrm.
fbtft is a popular way to connect small TFT LCDs over SPI to single
board computers like BeagleBone and Raspberry Pi. It became simpler
for users to get fbtft drivers working once Thomas Petazzoni added it
to staging at the end of 2014. I would like to avoid going back to
the scenario where the fbtft drivers have to be added as a patch
before compiling the kernel.
thanks,
drew
From: Tomi Valkeinen <hidden> Date: 2016-11-24 08:37:46
On 23/11/16 19:26, Noralf Trønnes wrote:
Den 23.11.2016 09:03, skrev Tomi Valkeinen:
quoted
Since the fbdev framework is in maintenance mode and all new display
drivers should be made with the DRM framework, remove fbtft from
staging.
Signed-off-by: Tomi Valkeinen <redacted>
FYI:
I'm working on a drm version of fbtft: https://github.com/notro/tinydrm
I have just picked it up after a 4 month break.
It is ready for a new review, except that I want to test how it would
perform as a drm userspace driver first (for spi that would mean adding
dma-buf support to spidev). If this performs well, then all the fbtft
drivers could move to userspace. If it doesn't, then at least (very slow)
i2c and e-ink displays could be userspace drivers.
Alright, sounds good to me.
So let's keep the staging fbdev drivers there until we have replacements.
Tomi
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2016-12-08 01:02:14
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.
From: Tomi Valkeinen <hidden> Date: 2016-12-08 08:02:06
On 08/12/16 03:01, Benjamin Herrenschmidt wrote:
On Wed, 2016-11-23 at 10:03 +0200, Tomi Valkeinen wrote:
quoted
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.
From: Daniel Vetter <hidden> Date: 2016-12-08 10:10:02
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:
quoted
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
On Thu, Dec 8, 2016 at 11:10 AM, Daniel Vetter [off-list ref] wrote:
On Thu, Dec 08, 2016 at 12:01:19PM +1100, Benjamin Herrenschmidt wrote:
quoted
On Wed, 2016-11-23 at 10:03 +0200, Tomi Valkeinen wrote:
quoted
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.
quoted
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
quoted
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
From: Daniel Vetter <hidden> Date: 2016-12-08 14:19:35
On Thu, Dec 08, 2016 at 01:15:56PM +0100, Geert Uytterhoeven wrote:
On Thu, Dec 8, 2016 at 11:10 AM, Daniel Vetter [off-list ref] wrote:
quoted
On Thu, Dec 08, 2016 at 12:01:19PM +1100, Benjamin Herrenschmidt wrote:
quoted
On Wed, 2016-11-23 at 10:03 +0200, Tomi Valkeinen wrote:
quoted
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.
quoted
quoted
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
quoted
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
Hi Daniel,
On Thu, Dec 8, 2016 at 3:02 PM, Daniel Vetter [off-list ref] wrote:
On Thu, Dec 08, 2016 at 01:15:56PM +0100, Geert Uytterhoeven wrote:
quoted
On Thu, Dec 8, 2016 at 11:10 AM, Daniel Vetter [off-list ref] wrote:
quoted
On Thu, Dec 08, 2016 at 12:01:19PM +1100, Benjamin Herrenschmidt wrote:
quoted
On Wed, 2016-11-23 at 10:03 +0200, Tomi Valkeinen wrote:
quoted
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 ...
quoted
quoted
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
From: Daniel Vetter <hidden> Date: 2016-12-08 14:22:22
Dear dri-devel folks,
My sincere apologies for hitting send on that mail. I got real mad and
angry and typed a mail I shouldn't have submitted - pouring oil into
flames for shit and giggles just doesn't help anyone, and it detracts from
moving things forward and improving the code and drivers and everything in
a friendly and constructive fashion. I want to be part of a great
community, this wasnt :(
/me out and off for a walk
Thanks, Daniel
On Thu, Dec 08, 2016 at 03:02:10PM +0100, Daniel Vetter wrote:
On Thu, Dec 08, 2016 at 01:15:56PM +0100, Geert Uytterhoeven wrote:
quoted
On Thu, Dec 8, 2016 at 11:10 AM, Daniel Vetter [off-list ref] wrote:
quoted
On Thu, Dec 08, 2016 at 12:01:19PM +1100, Benjamin Herrenschmidt wrote:
quoted
On Wed, 2016-11-23 at 10:03 +0200, Tomi Valkeinen wrote:
quoted
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.
quoted
quoted
quoted
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
quoted
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
From: Thomas Petazzoni <hidden> Date: 2016-12-08 14:37:40
Hello,
On Thu, 8 Dec 2016 15:22:09 +0100, Geert Uytterhoeven wrote:
quoted
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
Hi Thomas,
On Thu, Dec 8, 2016 at 3:37 PM, Thomas Petazzoni
[off-list ref] wrote:
On Thu, 8 Dec 2016 15:22:09 +0100, Geert Uytterhoeven wrote:
quoted
quoted
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
From: Jani Nikula <jani.nikula@linux.intel.com> Date: 2016-12-08 15:00:20
On Thu, 08 Dec 2016, Geert Uytterhoeven [off-list ref] wrote:
On Thu, Dec 8, 2016 at 3:02 PM, Daniel Vetter [off-list ref] wrote:
quoted
If you're this good at mainting gpu and display subsystems, maybe you
want to take over?
No please ;-)
Now that is indeed the right answer, and the attitude we're looking for!
Being able to say "no", especially wrt fbdev drivers, is a must have
quality. You're hired! ;D
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
From: Daniel Vetter <hidden> Date: 2016-12-08 15:21:49
[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
[off-list ref] wrote:
quoted
On Thu, 8 Dec 2016 15:22:09 +0100, Geert Uytterhoeven wrote:
quoted
quoted
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
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2016-12-08 21:24:15
On Thu, 2016-12-08 at 10:01 +0200, Tomi Valkeinen wrote:
quoted
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 ? :-)
quoted
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.
quoted
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.
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2016-12-08 21:35:33
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.
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2016-12-08 21:44:42
On Fri, 2016-12-09 at 08:23 +1100, Benjamin Herrenschmidt wrote:
quoted
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.
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2016-12-08 21:58:15
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.
On Wednesday 23 November 2016 09:12 AM, Tomi Valkeinen wrote:
On 23/11/16 10:52, Greg Kroah-Hartman wrote:
quoted
On Wed, Nov 23, 2016 at 10:03:10AM +0200, Tomi Valkeinen wrote:
quoted
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.
<snip>
Or do you mean that we should keep the drivers in staging until there's
a matching DRM driver, but drop any plans to move the drivers from
staging to drivers/video/? If so, I'm fine with that. This is an RFC,
mostly to raise some discussion and push people to actually write those
DRM drivers =).
I already have plans to convert my drivers to DRM. But it will be great
if you can point me to a simple driver which will help me to understand
how DRM works.
Regards
Sudip
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2016-12-08 22:30:17
On Thu, 2016-12-08 at 11:10 +0100, Daniel Vetter wrote:
quoted
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
Ok so my knowledge might be outdated here. I was complaining to Dave about
how cirrusdrmfb didn't even use blits for fbcon scrolling and always double
buffered everything, and Dave made the point that you basically had to do
that for security reasons that I mostly forgot the details of.
It looks like bochsdrmfb and astdrmfb are the same. If things have changed,
then cool. Can you point me to a drmfb driver that is a good (and not too
complex) example with simple 2d accel ? I'm thinking mostly of color
expansion, bitblt and solid fill for fbcon, the way I used to do it in
radeonfb for example.
quoted
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.
Yeah it's hard to follow from outside :-) As I said above, it would
help if you could point to a good modern example driver to use as
reference.
Thanks !
Cheers,
Ben.
From: Dave Airlie <airlied@gmail.com> Date: 2016-12-09 00:09:15
On 9 December 2016 at 07:28, Benjamin Herrenschmidt
[off-list ref] wrote:
On Thu, 2016-12-08 at 11:10 +0100, Daniel Vetter wrote:
quoted
quoted
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
Ok so my knowledge might be outdated here. I was complaining to Dave about
how cirrusdrmfb didn't even use blits for fbcon scrolling and always double
buffered everything, and Dave made the point that you basically had to do
that for security reasons that I mostly forgot the details of.
It looks like bochsdrmfb and astdrmfb are the same. If things have changed,
then cool. Can you point me to a drmfb driver that is a good (and not too
complex) example with simple 2d accel ? I'm thinking mostly of color
expansion, bitblt and solid fill for fbcon, the way I used to do it in
radeonfb for example.
What are people using fbcon for that needs acceleration, this is where I get
a bit lost.
It's a console, if you aren't sshing into the machine.
It's main purpose should just be for gathering oopses and you've a lot better
chance of getting an oops if you don't have some sketchy gpu accel in the way.
The acceleration that most of the 2D things provide isn't ever that
great, and shadowing is a lot more effective if done properly. It's a feature
that kernel ppl obsess over but I don't get a lot of real world feedback,
(booting 9000 scsi nodes with debug on takes a long time was possibly
something I heard once, and I think we resolved).
Dave.
Hi Dave,
On Fri, Dec 9, 2016 at 1:08 AM, Dave Airlie [off-list ref] wrote:
On 9 December 2016 at 07:28, Benjamin Herrenschmidt
[off-list ref] wrote:
quoted
On Thu, 2016-12-08 at 11:10 +0100, Daniel Vetter wrote:
quoted
quoted
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
Ok so my knowledge might be outdated here. I was complaining to Dave about
how cirrusdrmfb didn't even use blits for fbcon scrolling and always double
buffered everything, and Dave made the point that you basically had to do
that for security reasons that I mostly forgot the details of.
It looks like bochsdrmfb and astdrmfb are the same. If things have changed,
then cool. Can you point me to a drmfb driver that is a good (and not too
complex) example with simple 2d accel ? I'm thinking mostly of color
expansion, bitblt and solid fill for fbcon, the way I used to do it in
radeonfb for example.
What are people using fbcon for that needs acceleration, this is where I get
a bit lost.
It's a console, if you aren't sshing into the machine.
It's main purpose should just be for gathering oopses and you've a lot better
chance of getting an oops if you don't have some sketchy gpu accel in the way.
Unless you're using the console as a text console, and don't run e.g. X on top.
The acceleration that most of the 2D things provide isn't ever that
great, and shadowing is a lot more effective if done properly. It's a feature
that kernel ppl obsess over but I don't get a lot of real world feedback,
(booting 9000 scsi nodes with debug on takes a long time was possibly
something I heard once, and I think we resolved).
It all depends on the complex balance between GPU performance, CPU performance,
CPU-to-frame buffer bandwidth, and amount of available system RAM.
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
From: Daniel Vetter <hidden> Date: 2016-12-09 08:14:28
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:
quoted
quoted
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
From: Daniel Vetter <hidden> Date: 2016-12-09 08:30:53
On Thu, Dec 08, 2016 at 04:21:34PM +0100, Daniel Vetter wrote:
[back from my walk, the sunset here is stellar ;-)]
On Thu, Dec 08, 2016 at 03:44:30PM +0100, Geert Uytterhoeven wrote:
quoted
Hi Thomas,
On Thu, Dec 8, 2016 at 3:37 PM, Thomas Petazzoni
[off-list ref] wrote:
quoted
On Thu, 8 Dec 2016 15:22:09 +0100, Geert Uytterhoeven wrote:
quoted
quoted
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).
Correction, MXSFB just landed, which is the first driver using the simple
display pipe helpers.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
From: Daniel Vetter <hidden> Date: 2016-12-09 08:36:07
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:
quoted
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
From: Daniel Vetter <hidden> Date: 2016-12-09 08:42:49
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:
quoted
On Fri, 2016-12-09 at 08:34 +1100, Benjamin Herrenschmidt wrote:
quoted
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
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2016-12-09 11:41:06
On Fri, 2016-12-09 at 10:08 +1000, Dave Airlie wrote:
What are people using fbcon for that needs acceleration, this is where I get
a bit lost.
It's a console, if you aren't sshing into the machine.
It's main purpose should just be for gathering oopses and you've a lot better
chance of getting an oops if you don't have some sketchy gpu accel in the way.
There are other uses for systems running Linux than being a server or desktop :-)
The acceleration that most of the 2D things provide isn't ever that
great, and shadowing is a lot more effective if done properly.
Not with a 400Mhz ARM9 processor on a fairly high res display. In these
case basic old things like color expansion for font rendering, bit
blits and solid fills for scrolls work beautifully. Anyway I just
realized that the ARM side of the AST GPU doesn't have the accel bits
at all anyway, only the host side, so I'm back to just a dumb FB. I
still want to avoid the copies though.
It's a feature
that kernel ppl obsess over but I don't get a lot of real world feedback,
(booting 9000 scsi nodes with debug on takes a long time was possibly
something I heard once, and I think we resolved).
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2016-12-09 11:45:25
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.
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2016-12-09 11:49:09
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
quoted
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
Hi Ben,
On Fri, Dec 9, 2016 at 12:44 PM, Benjamin Herrenschmidt
[off-list ref] wrote:
quoted
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).
That would indeed be a great example.
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
From: Lucas Stach <l.stach@pengutronix.de> Date: 2016-12-09 13:19:26
Am Freitag, den 09.12.2016, 22:44 +1100 schrieb Benjamin Herrenschmidt:
On Fri, 2016-12-09 at 09:34 +0100, Daniel Vetter wrote:
quoted
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.
Yes, CMA is exactly the solution for that. It provides contiguous memory
that doesn't need to be removed from the normal Linux memory handling
and allows for the CMA region to be at specific places if needed. It's
just a matter of describing the constraints properly.
Regards,
Lucas
From: Daniel Vetter <hidden> Date: 2016-12-09 13:33:36
On Fri, Dec 09, 2016 at 10:44:16PM +1100, Benjamin Herrenschmidt wrote:
On Fri, 2016-12-09 at 09:34 +0100, Daniel Vetter wrote:
quoted
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.
Yeah, if you wire up the dma_alloc_coherent to cma you'll get a contiguous
buffer pinned into place.
quoted
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).
One of the still in-flight drm drivers is the simpledrm thing meant for
all kinds of firmware drivers like efifb and similar things on arm for
pre-programmed output set up by firmware. I.e. no modeset support and
otherwise a lot of fake to make it work as drm driver, but the idea that
it's good enough until your real drm driver takes over.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
From: Daniel Vetter <hidden> Date: 2016-12-09 13:35:08
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:
quoted
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.
quoted
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
From: David Herrmann <hidden> Date: 2016-12-09 13:57:29
Hey
On Fri, Dec 9, 2016 at 2:33 PM, Daniel Vetter [off-list ref] wrote:
quoted
quoted
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).
One of the still in-flight drm drivers is the simpledrm thing meant for
all kinds of firmware drivers like efifb and similar things on arm for
pre-programmed output set up by firmware. I.e. no modeset support and
otherwise a lot of fake to make it work as drm driver, but the idea that
it's good enough until your real drm driver takes over.
The x86 platform device fixups for SimpleDRM went in some weeks ago,
so maybe I should resend the patches. The driver could easily do
'offb'-like devices as well. Trivial to add.
Anyway, Benjamin is right, we always do shadow buffering for trivial
drivers. Even in SimpleDRM I blit the shadow buffer on page-flip or
dirty-ioctl. Reason is that we cannot easily expose the real
framebuffer in DRM via FB-objects. But I also never saw a use-case for
it, since all trivial devices I worked with were only either used as
fallback or nobody cared for performance.
The generic DRM API is designed for dynamic FB allocation. If your
hardware does not allow you to change the scanout source, you will
have a hard time trying to expose the static buffers via the dynamic
FB-object API. Furthermore, all DRM user-space expects dynamic FB
management to work, preferably without a ridiculously low memory
limit. That's also why I never bothered changing the drivers.
Despite all of this I still see no reason why a driver could not
expose the static, real frambuffers via private ioctls. You can get
all your fancy acceleration that way. Then fix user-space to use this
API. If enough drivers end up with something similar, move it into the
core. Just like we always do in DRM.
Thanks
David
From: Daniel Vetter <hidden> Date: 2016-12-09 14:04:51
On Fri, Dec 09, 2016 at 02:57:24PM +0100, David Herrmann wrote:
Hey
On Fri, Dec 9, 2016 at 2:33 PM, Daniel Vetter [off-list ref] wrote:
quoted
quoted
quoted
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).
One of the still in-flight drm drivers is the simpledrm thing meant for
all kinds of firmware drivers like efifb and similar things on arm for
pre-programmed output set up by firmware. I.e. no modeset support and
otherwise a lot of fake to make it work as drm driver, but the idea that
it's good enough until your real drm driver takes over.
The x86 platform device fixups for SimpleDRM went in some weeks ago,
so maybe I should resend the patches. The driver could easily do
'offb'-like devices as well. Trivial to add.
Anyway, Benjamin is right, we always do shadow buffering for trivial
drivers. Even in SimpleDRM I blit the shadow buffer on page-flip or
dirty-ioctl. Reason is that we cannot easily expose the real
framebuffer in DRM via FB-objects. But I also never saw a use-case for
it, since all trivial devices I worked with were only either used as
fallback or nobody cared for performance.
The generic DRM API is designed for dynamic FB allocation. If your
hardware does not allow you to change the scanout source, you will
have a hard time trying to expose the static buffers via the dynamic
FB-object API. Furthermore, all DRM user-space expects dynamic FB
management to work, preferably without a ridiculously low memory
limit. That's also why I never bothered changing the drivers.
Despite all of this I still see no reason why a driver could not
expose the static, real frambuffers via private ioctls. You can get
all your fancy acceleration that way. Then fix user-space to use this
API. If enough drivers end up with something similar, move it into the
core. Just like we always do in DRM.
Well, we don't need a private abi. If we dynamically remap the mmaps and
fixup fbdev to do the same then we could redirect frontbuffer rendering
for the currently displaying buffer to the static, real framebuffer. That
would fix the perf issues Ben is fearing I think.
And if we do some nice ttm helpers to hide this all to the level the cma
helpers are just plug-in-and-go then it'd be real nice I think. But thus
far no one has cared enough yet to make that happen.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2016-12-09 20:30:52
On Fri, 2016-12-09 at 14:57 +0100, David Herrmann wrote:
Despite all of this I still see no reason why a driver could not
expose the static, real frambuffers via private ioctls. You can get
all your fancy acceleration that way. Then fix user-space to use this
API. If enough drivers end up with something similar, move it into the
core. Just like we always do in DRM.
I don't care so much about userspace in my specific use case, more
about fbcon, which I think can be solved without too many hoops.
As for FB objects, my thinking is we could just use
unmap_mapping_ranges() to effectively change the mapping under the hood
of the app so it alternatively maps a bit of fb or a bit of memory...
Cheers,
Ben.
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2016-12-09 21:14:33
On Fri, 2016-12-09 at 14:35 +0100, Daniel Vetter wrote:
quoted
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).
quoted
quoted
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.
From: Michel Dänzer <hidden> Date: 2016-12-13 07:19:03
On 10/12/16 05:27 AM, Benjamin Herrenschmidt wrote:
On Fri, 2016-12-09 at 14:35 +0100, Daniel Vetter wrote:
quoted
quoted
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.
I think he did, it was working fine for userspace mappings when I tried
making radeon use a non-pinned BO for fbdev years ago (the problem was
fbcon potentially trying to access the framebuffer at the most
inconvenient times). There's still ttm_fbdev_mmap, but I'm not sure
everything to make this fully work for userspace fbdev mappings is still
there.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
The acceleration that most of the 2D things provide isn't ever that
great, and shadowing is a lot more effective if done properly.
That is probably true for anything pci-ish, because those devices are
optimized for memory writes and reads are horribly slow. So you surely
want avoid device memory reads and shadowing is a effective way to do
this.
On arm hardware the tradeoff may look quite different, the cpus are
relatively slow and I think most arm gpus don't have dedicated device
memory ...
cheers,
Gerd
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.
Well, at least for cirrusdrmfb using 2d accel is kida pointless as this
only shifts the software bitblit from the kernel to qemu ...
cheers,
Gerd
Hi Daniel,
On Thursday 08 Dec 2016 11:10:05 Daniel Vetter wrote:
On Thu, Dec 08, 2016 at 12:01:19PM +1100, Benjamin Herrenschmidt wrote:
quoted
On Wed, 2016-11-23 at 10:03 +0200, Tomi Valkeinen wrote:
quoted
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.
quoted
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
And I'd argue that a better use of time would be to implement an accelerated
console that does not use fbdev at all.
quoted
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.
From: Andy Shevchenko <hidden> Date: 2016-12-22 20:36:18
On Wed, Nov 23, 2016 at 12:05 PM, Thomas Petazzoni
[off-list ref] wrote:
On Wed, 23 Nov 2016 11:12:32 +0200, Tomi Valkeinen wrote:
quoted
Or do you mean that we should keep the drivers in staging until there's
a matching DRM driver, but drop any plans to move the drivers from
staging to drivers/video/? If so, I'm fine with that. This is an RFC,
mostly to raise some discussion and push people to actually write those
DRM drivers =).
The very reason why I submitted those drivers for staging is because
lots and lots of people were using out of tree kernel modules for these
drivers, which was really a pain.
If you now remove those drivers from staging, then those folks will be
back in the situation they originally were, using annoying out of tree
modules.
I'm all for removing fbtft drivers progressively as a matching
DRM-based driver is available for the same hardware. However, if there
is no DRM-based support for a given piece of hardware supported by
fbtft, I'd prefer if we kept the fbtft driver for this hardware.
Too many people are playing with big things, I vote +1 to *leave*
fbtft for people who prefer small on big.
--
With Best Regards,
Andy Shevchenko