[RFC 0/6] SimpleDRM Driver (was: dvbe driver)
Hi
On Wed, Jun 26, 2013 at 11:30 PM, Stephen Warren
wrote:
> On 06/24/2013 04:27 PM, David Herrmann wrote:
>> Hi
>>
>> This is my second revision of the dvbe driver. I renamed it to SimpleDRM to
>> show the resemblence with the recently introduced simplefb.c fbdev driver.
>> The
>> driver is supposed to be the most basic DRM driver similar to efifb.c,
>> vesafb.c,
>> offb.c, simplefb.c, ...
>> It provides a single virtual CRTC+encoder+connector and allows user-space to
>> create one dumb-buffer at a time and attach it.
>>
>> The setup changed slightly. It no longer uses shadow buffers but instead maps
>> the framebuffer directly into userspace. Furthermore, a new infrastructure is
>> used to unload firmware drivers during real hardware drivers probe cycles.
>> Only
>> nouveau was changed to use it, yet.
>>
>> I still have an odd problem when unloading DRM drivers (not just SimpleDRM)
>> with
>> an fbdev fallback. If I call printk() directly after
>> unregister_framebufer(), I
>> get a NULL-deref somewhere in the VT layer (most times hide_cursor()). I
>> haven't
>> figured out exactly where that happens, but I am also very reluctant to spend
>> more time debugging the VT layer.
>
> I tested this on a Tegra ARM system, and it basically worked.
Thanks a lot for the feedback!
> I have one question: With the simplefb driver, and console=tty1 on the
> kernel command-line, I see both the penguins logo and Linux's boot
> messages on the LCD panel that's hooked up through simplefb. However,
> with simpledrm, I only see the penguins logo, but no boot messages. Is
> that expected? How would I solve that if so?
No idea what is going wrong there. Somehow the simpledrm-fbdev device
is not picked up as primary device. I only got a black-cursor on
black-background (visible if painting something else on the fb0
device). And I get NULL-derefs in cursor_hide() during unregistration.
I digged through fbcon.c to find out what's going wrong but without
any success. I will see what I can do.
However, X-server or other apps work perfectly fine with it.
> Note: I needed to apply the following patch to get it to compile:
>
> diff --git a/drivers/gpu/drm/simpledrm/simpledrm_fbdev.c
> b/drivers/gpu/drm/simpledrm/simpledrm_fbdev.c
> index 40a2696..39885c8 100644
> --- a/drivers/gpu/drm/simpledrm/simpledrm_fbdev.c
> +++ b/drivers/gpu/drm/simpledrm/simpledrm_fbdev.c
> @@ -159,7 +159,7 @@ void sdrm_fbdev_cleanup(struct sdrm_device *sdrm)
> {
> struct fb_info *info;
>
> - if (!sdrm->info)
> + if (!sdrm->fbdev)
> return;
Ugh, embarrassing, sorry. I fixed it up. It was a late fix to a avoid
fbcon from panicking.
Thanks!
David
>
> dev_info(sdrm->ddev->dev, "fbdev cleanup\n");
>
>
>
Re: [RFC 0/6] SimpleDRM Driver (was: dvbe driver)
Hi
On Wed, Jun 26, 2013 at 11:30 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 06/24/2013 04:27 PM, David Herrmann wrote:
Hi
This is my second revision of the dvbe driver. I renamed it to SimpleDRM to
show the resemblence with the recently introduced simplefb.c fbdev driver.
The
driver is supposed to be the most basic DRM driver similar to efifb.c,
vesafb.c,
offb.c, simplefb.c, ...
It provides a single virtual CRTC+encoder+connector and allows user-space to
create one dumb-buffer at a time and attach it.
The setup changed slightly. It no longer uses shadow buffers but instead maps
the framebuffer directly into userspace. Furthermore, a new infrastructure is
used to unload firmware drivers during real hardware drivers probe cycles.
Only
nouveau was changed to use it, yet.
I still have an odd problem when unloading DRM drivers (not just SimpleDRM)
with
an fbdev fallback. If I call printk() directly after
unregister_framebufer(), I
get a NULL-deref somewhere in the VT layer (most times hide_cursor()). I
haven't
figured out exactly where that happens, but I am also very reluctant to spend
more time debugging the VT layer.
I tested this on a Tegra ARM system, and it basically worked.
Thanks a lot for the feedback!
I have one question: With the simplefb driver, and console=tty1 on the
kernel command-line, I see both the penguins logo and Linux's boot
messages on the LCD panel that's hooked up through simplefb. However,
with simpledrm, I only see the penguins logo, but no boot messages. Is
that expected? How would I solve that if so?
No idea what is going wrong there. Somehow the simpledrm-fbdev device
is not picked up as primary device. I only got a black-cursor on
black-background (visible if painting something else on the fb0
device). And I get NULL-derefs in cursor_hide() during unregistration.
I digged through fbcon.c to find out what's going wrong but without
any success. I will see what I can do.
However, X-server or other apps work perfectly fine with it.
Note: I needed to apply the following patch to get it to compile:
diff --git a/drivers/gpu/drm/simpledrm/simpledrm_fbdev.c
b/drivers/gpu/drm/simpledrm/simpledrm_fbdev.c
index 40a2696..39885c8 100644
--- a/drivers/gpu/drm/simpledrm/simpledrm_fbdev.c
+++ b/drivers/gpu/drm/simpledrm/simpledrm_fbdev.c
@@ -159,7 +159,7 @@ void sdrm_fbdev_cleanup(struct sdrm_device *sdrm)
{
struct fb_info *info;
- if (!sdrm-info)
+ if (!sdrm-fbdev)
return;
Ugh, embarrassing, sorry. I fixed it up. It was a late fix to a avoid
fbcon from panicking.
Thanks!
David
dev_info(sdrm-ddev-dev, fbdev cleanup\n);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC 0/6] SimpleDRM Driver (was: dvbe driver)
On 06/24/2013 04:27 PM, David Herrmann wrote:
> Hi
>
> This is my second revision of the dvbe driver. I renamed it to SimpleDRM to
> show the resemblence with the recently introduced simplefb.c fbdev driver. The
> driver is supposed to be the most basic DRM driver similar to efifb.c,
> vesafb.c,
> offb.c, simplefb.c, ...
> It provides a single virtual CRTC+encoder+connector and allows user-space to
> create one dumb-buffer at a time and attach it.
>
> The setup changed slightly. It no longer uses shadow buffers but instead maps
> the framebuffer directly into userspace. Furthermore, a new infrastructure is
> used to unload firmware drivers during real hardware drivers probe cycles.
> Only
> nouveau was changed to use it, yet.
>
> I still have an odd problem when unloading DRM drivers (not just SimpleDRM)
> with
> an fbdev fallback. If I call printk() directly after unregister_framebufer(),
> I
> get a NULL-deref somewhere in the VT layer (most times hide_cursor()). I
> haven't
> figured out exactly where that happens, but I am also very reluctant to spend
> more time debugging the VT layer.
I tested this on a Tegra ARM system, and it basically worked.
I have one question: With the simplefb driver, and console=tty1 on the
kernel command-line, I see both the penguins logo and Linux's boot
messages on the LCD panel that's hooked up through simplefb. However,
with simpledrm, I only see the penguins logo, but no boot messages. Is
that expected? How would I solve that if so?
Note: I needed to apply the following patch to get it to compile:
diff --git a/drivers/gpu/drm/simpledrm/simpledrm_fbdev.c
b/drivers/gpu/drm/simpledrm/simpledrm_fbdev.c
index 40a2696..39885c8 100644
--- a/drivers/gpu/drm/simpledrm/simpledrm_fbdev.c
+++ b/drivers/gpu/drm/simpledrm/simpledrm_fbdev.c
@@ -159,7 +159,7 @@ void sdrm_fbdev_cleanup(struct sdrm_device *sdrm)
{
struct fb_info *info;
- if (!sdrm->info)
+ if (!sdrm->fbdev)
return;
dev_info(sdrm->ddev->dev, "fbdev cleanup\n");
Re: [RFC 0/6] SimpleDRM Driver (was: dvbe driver)
On 06/24/2013 04:27 PM, David Herrmann wrote:
Hi
This is my second revision of the dvbe driver. I renamed it to SimpleDRM to
show the resemblence with the recently introduced simplefb.c fbdev driver. The
driver is supposed to be the most basic DRM driver similar to efifb.c,
vesafb.c,
offb.c, simplefb.c, ...
It provides a single virtual CRTC+encoder+connector and allows user-space to
create one dumb-buffer at a time and attach it.
The setup changed slightly. It no longer uses shadow buffers but instead maps
the framebuffer directly into userspace. Furthermore, a new infrastructure is
used to unload firmware drivers during real hardware drivers probe cycles.
Only
nouveau was changed to use it, yet.
I still have an odd problem when unloading DRM drivers (not just SimpleDRM)
with
an fbdev fallback. If I call printk() directly after unregister_framebufer(),
I
get a NULL-deref somewhere in the VT layer (most times hide_cursor()). I
haven't
figured out exactly where that happens, but I am also very reluctant to spend
more time debugging the VT layer.
I tested this on a Tegra ARM system, and it basically worked.
I have one question: With the simplefb driver, and console=tty1 on the
kernel command-line, I see both the penguins logo and Linux's boot
messages on the LCD panel that's hooked up through simplefb. However,
with simpledrm, I only see the penguins logo, but no boot messages. Is
that expected? How would I solve that if so?
Note: I needed to apply the following patch to get it to compile:
diff --git a/drivers/gpu/drm/simpledrm/simpledrm_fbdev.c
b/drivers/gpu/drm/simpledrm/simpledrm_fbdev.c
index 40a2696..39885c8 100644
--- a/drivers/gpu/drm/simpledrm/simpledrm_fbdev.c
+++ b/drivers/gpu/drm/simpledrm/simpledrm_fbdev.c
@@ -159,7 +159,7 @@ void sdrm_fbdev_cleanup(struct sdrm_device *sdrm)
{
struct fb_info *info;
- if (!sdrm-info)
+ if (!sdrm-fbdev)
return;
dev_info(sdrm-ddev-dev, fbdev cleanup\n);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC 0/6] SimpleDRM Driver (was: dvbe driver)
Hi This is my second revision of the dvbe driver. I renamed it to SimpleDRM to show the resemblence with the recently introduced simplefb.c fbdev driver. The driver is supposed to be the most basic DRM driver similar to efifb.c, vesafb.c, offb.c, simplefb.c, ... It provides a single virtual CRTC+encoder+connector and allows user-space to create one dumb-buffer at a time and attach it. The setup changed slightly. It no longer uses shadow buffers but instead maps the framebuffer directly into userspace. Furthermore, a new infrastructure is used to unload firmware drivers during real hardware drivers probe cycles. Only nouveau was changed to use it, yet. I still have an odd problem when unloading DRM drivers (not just SimpleDRM) with an fbdev fallback. If I call printk() directly after unregister_framebufer(), I get a NULL-deref somewhere in the VT layer (most times hide_cursor()). I haven't figured out exactly where that happens, but I am also very reluctant to spend more time debugging the VT layer. Anyhow, comments welcome. If someone wants to test it, you probably need to add a line to ./include/linux/platform_data/simplefb.h and add the modeline of your VESA/EFI framebuffer. Cheers David David Herrmann (6): fbdev: simplefb: add init through platform_data x86: provide platform-devices for boot-framebuffers drm: add SimpleDRM driver drm: simpledrm: add fbdev fallback support drm: add helpers to kick out firmware drivers drm: nouveau: kick out firmware drivers during probe MAINTAINERS | 8 + arch/x86/Kconfig| 18 ++ arch/x86/kernel/Makefile| 1 + arch/x86/kernel/sysfb.c | 157 drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile| 1 + drivers/gpu/drm/drm_pci.c | 1 + drivers/gpu/drm/drm_platform.c | 1 + drivers/gpu/drm/drm_stub.c | 107 drivers/gpu/drm/drm_usb.c | 1 + drivers/gpu/drm/nouveau/nouveau_drm.c | 29 ++- drivers/gpu/drm/simpledrm/Kconfig | 29 +++ drivers/gpu/drm/simpledrm/Makefile | 9 + drivers/gpu/drm/simpledrm/simpledrm.h | 114 + drivers/gpu/drm/simpledrm/simpledrm_drv.c | 231 ++ drivers/gpu/drm/simpledrm/simpledrm_fbdev.c | 180 ++ drivers/gpu/drm/simpledrm/simpledrm_main.c | 366 drivers/gpu/drm/simpledrm/simpledrm_mem.c | 254 +++ drivers/video/Kconfig | 5 +- drivers/video/simplefb.c| 45 +++- include/drm/drmP.h | 26 ++ include/linux/platform_data/simplefb.h | 40 +++ 22 files changed, 1604 insertions(+), 21 deletions(-) create mode 100644 arch/x86/kernel/sysfb.c create mode 100644 drivers/gpu/drm/simpledrm/Kconfig create mode 100644 drivers/gpu/drm/simpledrm/Makefile create mode 100644 drivers/gpu/drm/simpledrm/simpledrm.h create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_drv.c create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_fbdev.c create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_main.c create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_mem.c create mode 100644 include/linux/platform_data/simplefb.h -- 1.8.3.1
[RFC 0/6] SimpleDRM Driver (was: dvbe driver)
Hi This is my second revision of the dvbe driver. I renamed it to SimpleDRM to show the resemblence with the recently introduced simplefb.c fbdev driver. The driver is supposed to be the most basic DRM driver similar to efifb.c, vesafb.c, offb.c, simplefb.c, ... It provides a single virtual CRTC+encoder+connector and allows user-space to create one dumb-buffer at a time and attach it. The setup changed slightly. It no longer uses shadow buffers but instead maps the framebuffer directly into userspace. Furthermore, a new infrastructure is used to unload firmware drivers during real hardware drivers probe cycles. Only nouveau was changed to use it, yet. I still have an odd problem when unloading DRM drivers (not just SimpleDRM) with an fbdev fallback. If I call printk() directly after unregister_framebufer(), I get a NULL-deref somewhere in the VT layer (most times hide_cursor()). I haven't figured out exactly where that happens, but I am also very reluctant to spend more time debugging the VT layer. Anyhow, comments welcome. If someone wants to test it, you probably need to add a line to ./include/linux/platform_data/simplefb.h and add the modeline of your VESA/EFI framebuffer. Cheers David David Herrmann (6): fbdev: simplefb: add init through platform_data x86: provide platform-devices for boot-framebuffers drm: add SimpleDRM driver drm: simpledrm: add fbdev fallback support drm: add helpers to kick out firmware drivers drm: nouveau: kick out firmware drivers during probe MAINTAINERS | 8 + arch/x86/Kconfig| 18 ++ arch/x86/kernel/Makefile| 1 + arch/x86/kernel/sysfb.c | 157 drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile| 1 + drivers/gpu/drm/drm_pci.c | 1 + drivers/gpu/drm/drm_platform.c | 1 + drivers/gpu/drm/drm_stub.c | 107 drivers/gpu/drm/drm_usb.c | 1 + drivers/gpu/drm/nouveau/nouveau_drm.c | 29 ++- drivers/gpu/drm/simpledrm/Kconfig | 29 +++ drivers/gpu/drm/simpledrm/Makefile | 9 + drivers/gpu/drm/simpledrm/simpledrm.h | 114 + drivers/gpu/drm/simpledrm/simpledrm_drv.c | 231 ++ drivers/gpu/drm/simpledrm/simpledrm_fbdev.c | 180 ++ drivers/gpu/drm/simpledrm/simpledrm_main.c | 366 drivers/gpu/drm/simpledrm/simpledrm_mem.c | 254 +++ drivers/video/Kconfig | 5 +- drivers/video/simplefb.c| 45 +++- include/drm/drmP.h | 26 ++ include/linux/platform_data/simplefb.h | 40 +++ 22 files changed, 1604 insertions(+), 21 deletions(-) create mode 100644 arch/x86/kernel/sysfb.c create mode 100644 drivers/gpu/drm/simpledrm/Kconfig create mode 100644 drivers/gpu/drm/simpledrm/Makefile create mode 100644 drivers/gpu/drm/simpledrm/simpledrm.h create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_drv.c create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_fbdev.c create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_main.c create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_mem.c create mode 100644 include/linux/platform_data/simplefb.h -- 1.8.3.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
