dri-devel February 2011

dri-devel@lists.freedesktop.org

84 participants
466 discussions

Re: [PATCH/RFC 0/5] HDMI driver for Samsung S5PV310 platform
by Alex Deucher 09 Feb '11

09 Feb '11

On Wed, Feb 9, 2011 at 3:59 AM, Hans Verkuil <hansverk(a)cisco.com> wrote: > On Tuesday, February 08, 2011 16:28:32 Alex Deucher wrote: >> On Tue, Feb 8, 2011 at 4:47 AM, Hans Verkuil <hansverk(a)cisco.com> wrote: > > <snip> > >> >> The driver supports an interrupt. It is used to detect plug/unplug > events >> > in >> >> kernel debugs. The API for detection of such an events in V4L2 API is to > be >> >> defined. >> > >> > Cisco (i.e. a few colleagues and myself) are working on this. We hope to > post >> > an RFC by the end of this month. We also have a proposal for CEC support > in >> > the pipeline. >> >> Any reason to not use the drm kms APIs for modesetting, display >> configuration, and hotplug support? We already have the >> infrastructure in place for complex display configurations and >> generating events for hotplug interrupts. It would seem to make more >> sense to me to fix any deficiencies in the KMS APIs than to spin a new >> API. Things like CEC would be a natural fit since a lot of desktop >> GPUs support hdmi audio/3d/etc. and are already using kms. > > There are various reasons for not going down that road. The most important one > is that mixing APIs is actually a bad idea. I've done that once in the past > and I've regretted ever since. The problem with doing that is that it is > pretty hard on applications who have to mix two different styles of API, > somehow know where to find the documentation for each and know that both APIs > can in fact be used on the same device. > > Now, if there was a lot of code that could be shared, then that might be > enough reason to go that way, but in practice there is very little overlap. > Take CEC: all the V4L API will do is to pass the CEC packets from kernel to > userspace and vice versa. There is no parsing at all. This is typically used > by embedded apps that want to do their own CEC processing. > > An exception might be a PCI(e) card with HDMI input/output that wants to > handle CEC internally. At that point we might look at sharing CEC parsing > code. A similar story is true for EDID handling. > > One area that might be nice to look at would be to share drivers for HDMI > receivers and transmitters. However, the infrastructure for such drivers is > wildly different between how it is used for GPUs versus V4L and has been for > 10 years or so. I also suspect that most GPUs have there own HDMI internal > implementation so code sharing will probably be quite limited. > You don't need to worry about the rest of the 3D and acceleration stuff to use the kms modesetting API. For video output, you have a timing generator, an encoder that translates a bitstream into voltages, and an connector that you plug into a monitor. Additionally you may want to read an edid or generate a hotplug event and use some modeline handling helpers. The kms api provides core modesetting code and a set of modesetting driver callbacks for crtcs, encoders, and connectors. The hardware implementations will vary, but modesetting is the same. From drm_crtc_helper.h: The driver provides the following callbacks for the crtc. The crtc loosely refers to the part of the display pipe that generates timing and framebuffer scanout position. struct drm_crtc_helper_funcs { /* * Control power levels on the CRTC. If the mode passed in is * unsupported, the provider must use the next lowest power level. */ void (*dpms)(struct drm_crtc *crtc, int mode); void (*prepare)(struct drm_crtc *crtc); void (*commit)(struct drm_crtc *crtc); /* Provider can fixup or change mode timings before modeset occurs */ bool (*mode_fixup)(struct drm_crtc *crtc, struct drm_display_mode *mode, struct drm_display_mode *adjusted_mode); /* Actually set the mode */ int (*mode_set)(struct drm_crtc *crtc, struct drm_display_mode *mode, struct drm_display_mode *adjusted_mode, int x, int y, struct drm_framebuffer *old_fb); /* Move the crtc on the current fb to the given position *optional* */ int (*mode_set_base)(struct drm_crtc *crtc, int x, int y, struct drm_framebuffer *old_fb); int (*mode_set_base_atomic)(struct drm_crtc *crtc, struct drm_framebuffer *fb, int x, int y, enum mode_set_atomic); /* reload the current crtc LUT */ void (*load_lut)(struct drm_crtc *crtc); /* disable crtc when not in use - more explicit than dpms off */ void (*disable)(struct drm_crtc *crtc); }; encoders take the bitstream from the crtc and convert it into a set of voltages understood by the monitor, e.g., TMDS or LVDS encoders. The callbacks follow a similar pattern to crtcs. struct drm_encoder_helper_funcs { void (*dpms)(struct drm_encoder *encoder, int mode); void (*save)(struct drm_encoder *encoder); void (*restore)(struct drm_encoder *encoder); bool (*mode_fixup)(struct drm_encoder *encoder, struct drm_display_mode *mode, struct drm_display_mode *adjusted_mode); void (*prepare)(struct drm_encoder *encoder); void (*commit)(struct drm_encoder *encoder); void (*mode_set)(struct drm_encoder *encoder, struct drm_display_mode *mode, struct drm_display_mode *adjusted_mode); struct drm_crtc *(*get_crtc)(struct drm_encoder *encoder); /* detect for DAC style encoders */ enum drm_connector_status (*detect)(struct drm_encoder *encoder, struct drm_connector *connector); /* disable encoder when not in use - more explicit than dpms off */ void (*disable)(struct drm_encoder *encoder); }; And finally connectors. These are the actual physical connectors on the board (DVI-I, HDMI-A, VGA, S-video, etc.). Things like ddc lines are generally tied to a connector so functions relevant to getting modelines are associated with connectors. struct drm_connector_helper_funcs { int (*get_modes)(struct drm_connector *connector); int (*mode_valid)(struct drm_connector *connector, struct drm_display_mode *mode); struct drm_encoder *(*best_encoder)(struct drm_connector *connector); }; See drm_crtc_helper.c to see how the callbacks are used. The code can handle crtcs that can be routed to different encoders dynamically or crtcs that are hardcoded to specific encoders. Additionally, it can handle encoders that are shared between multiple connectors (e.g., a DAC shared between VGA and S-video), or multiple encoders tied to a single connector (e.g., DAC and TMDS encoders tied to a single DVI-I connector). Let's look at two scenarios where you want a system to display an interactive RGB desktop and provide video capture and video output. You'd need to use different sets of APIs depending on what hardware you use: 1. SoC with an LVDS panel and HDMI output and a capture unit 2. PC with a GPU with an LVDS panel and an HDMI output and a capture unit. As I understand it, to use the scenario 1 would use the following: - LVDS uses some new v4l interface or a hacked up kernel fb interface to support multiple displays - HDMI uses some new v4l interface or a hacked up kernel fb interface to support multiple displays - capture unit uses V4L Scenario 2 would use: - LVDS uses KMS API - HDMI uses KMS API - capture unit uses V4L Why not use KMS? A modesetting API is a huge amount of work. I haven't seen anything in these SoC platforms that makes them so radically different that they need their own API. If there are any, we'd love to hear about them so they can be addressed. Alex > So, no, there are no plans to share anything between the two (except perhaps > EDID and CEC parsing should that become relevant). > > Oh, and let me join Andy in saying that the drm/kms/whatever API documentation > *really* needs a lot of work. > > Regards, > > Hans >

2 1

[Bug 25717] Radeon: system locks up when sending many vertices.
by bugzilla-daemon＠freedesktop.org 09 Feb '11

09 Feb '11

https://bugs.freedesktop.org/show_bug.cgi?id=25717 --- Comment #8 from Nicolas Kaiser <nikai(a)nikai.net> 2011-02-09 10:44:27 PST --- (In reply to comment #7) > Maybe gltestperf doesn't lock up, it's just slow. On my lappy, it takes 9 > seconds to complete. If it takes more than 10 seconds, kernel will consider it > a lock-up, even though it's not. Yes, indeed. Now I disabled lockups like this ... drivers/gpu/drm/radeon/r100.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c index 5f15820..ce5ea3d 100644 --- a/drivers/gpu/drm/radeon/r100.c +++ b/drivers/gpu/drm/radeon/r100.c @@ -2036,7 +2036,7 @@ bool r100_gpu_cp_is_lockup(struct radeon_device *rdev, struct r100_gpu_lockup *l elapsed = jiffies_to_msecs(cjiffies - lockup->last_jiffies); if (elapsed >= 10000) { dev_err(rdev->dev, "GPU lockup CP stall for more than %lumsec\n", elapsed); - return true; +// return true; } /* give a chance to the GPU ... */ return false; ... and gltestperf finished successfully. According to the below results, it takes more than 13 seconds at my place: Feb 9 19:32:40 absol kernel: radeon 0000:01:05.0: GPU lockup CP stall for more than 10000msec Feb 9 19:32:40 absol kernel: radeon 0000:01:05.0: GPU lockup CP stall for more than 10500msec Feb 9 19:32:41 absol kernel: radeon 0000:01:05.0: GPU lockup CP stall for more than 11000msec Feb 9 19:32:41 absol kernel: radeon 0000:01:05.0: GPU lockup CP stall for more than 11500msec Feb 9 19:32:42 absol kernel: radeon 0000:01:05.0: GPU lockup CP stall for more than 12000msec Feb 9 19:32:42 absol kernel: radeon 0000:01:05.0: GPU lockup CP stall for more than 12500msec Feb 9 19:32:43 absol kernel: radeon 0000:01:05.0: GPU lockup CP stall for more than 13000msec Feb 9 19:32:54 absol kernel: radeon 0000:01:05.0: GPU lockup CP stall for more than 10000msec Feb 9 19:32:55 absol kernel: radeon 0000:01:05.0: GPU lockup CP stall for more than 10500msec Feb 9 19:32:55 absol kernel: radeon 0000:01:05.0: GPU lockup CP stall for more than 11000msec Feb 9 19:32:56 absol kernel: radeon 0000:01:05.0: GPU lockup CP stall for more than 11500msec Feb 9 19:32:56 absol kernel: radeon 0000:01:05.0: GPU lockup CP stall for more than 12000msec Feb 9 19:32:57 absol kernel: radeon 0000:01:05.0: GPU lockup CP stall for more than 12500msec Feb 9 19:32:57 absol kernel: radeon 0000:01:05.0: GPU lockup CP stall for more than 13000msec Feb 9 19:33:09 absol kernel: radeon 0000:01:05.0: GPU lockup CP stall for more than 10000msec Feb 9 19:33:10 absol kernel: radeon 0000:01:05.0: GPU lockup CP stall for more than 10500msec Feb 9 19:33:10 absol kernel: radeon 0000:01:05.0: GPU lockup CP stall for more than 11000msec Feb 9 19:33:10 absol kernel: radeon 0000:01:05.0: GPU lockup CP stall for more than 11500msec Feb 9 19:33:11 absol kernel: radeon 0000:01:05.0: GPU lockup CP stall for more than 12000msec Feb 9 19:33:12 absol kernel: radeon 0000:01:05.0: GPU lockup CP stall for more than 12500msec Feb 9 19:33:12 absol kernel: radeon 0000:01:05.0: GPU lockup CP stall for more than 13000msec Feb 9 19:33:24 absol kernel: radeon 0000:01:05.0: GPU lockup CP stall for more than 10000msec Feb 9 19:33:24 absol kernel: radeon 0000:01:05.0: GPU lockup CP stall for more than 10500msec Feb 9 19:33:25 absol kernel: radeon 0000:01:05.0: GPU lockup CP stall for more than 11000msec Feb 9 19:33:25 absol kernel: radeon 0000:01:05.0: GPU lockup CP stall for more than 11500msec Feb 9 19:33:26 absol kernel: radeon 0000:01:05.0: GPU lockup CP stall for more than 12000msec Feb 9 19:33:26 absol kernel: radeon 0000:01:05.0: GPU lockup CP stall for more than 12500msec Feb 9 19:33:27 absol kernel: radeon 0000:01:05.0: GPU lockup CP stall for more than 13000msec Feb 9 19:33:38 absol kernel: radeon 0000:01:05.0: GPU lockup CP stall for more than 10000msec Feb 9 19:33:39 absol kernel: radeon 0000:01:05.0: GPU lockup CP stall for more than 10500msec Feb 9 19:33:39 absol kernel: radeon 0000:01:05.0: GPU lockup CP stall for more than 11000msec Feb 9 19:33:40 absol kernel: radeon 0000:01:05.0: GPU lockup CP stall for more than 11500msec Feb 9 19:33:40 absol kernel: radeon 0000:01:05.0: GPU lockup CP stall for more than 12000msec Feb 9 19:33:41 absol kernel: radeon 0000:01:05.0: GPU lockup CP stall for more than 12500msec Feb 9 19:33:41 absol kernel: radeon 0000:01:05.0: GPU lockup CP stall for more than 13000msec -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[Bug 33957] G4 Mac mini Radeon 9200: Broken 3d-Acceleration
by bugzilla-daemon＠freedesktop.org 09 Feb '11

09 Feb '11

https://bugs.freedesktop.org/show_bug.cgi?id=33957 --- Comment #6 from anjo.weichbrodt(a)gmail.com 2011-02-09 10:06:03 PST --- (In reply to comment #5) > (In reply to comment #5) > > Disabling the kms (radeon.modeset=0) with the forums help, it was possible to > > fix a compatibility problem between radeonfb and the kms drm. > > If you enable KMS but disable radeonfb instead, does that work any better? I enabled KMS and disabled radeonfb. In KMS's default modeset, the system crashes during the boot process. With radeon.agpmode=4 the system boots fine. 3d acceleration is enabled but works only with some application and is really slow. -> regular system crashes Forcing the PCI mode with radeon.modeset=-1 the system boots fine. 3d acceleration is enabled and works (no blue tins or flickering), but is really slow: When Visual effects for gnome session are enabled, glxgears gives 20 fps, without visual effects: 400 fps. Tuxkart or Flightgear are not usable. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[Bug 25717] Radeon: system locks up when sending many vertices.
by bugzilla-daemon＠freedesktop.org 09 Feb '11

09 Feb '11

https://bugs.freedesktop.org/show_bug.cgi?id=25717 --- Comment #7 from Marek Olšák <maraeo(a)gmail.com> 2011-02-09 09:25:52 PST --- Maybe gltestperf doesn't lock up, it's just slow. On my lappy, it takes 9 seconds to complete. If it takes more than 10 seconds, kernel will consider it a lock-up, even though it's not. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[Bug 25717] Radeon: system locks up when sending many vertices.
by bugzilla-daemon＠freedesktop.org 09 Feb '11

09 Feb '11

https://bugs.freedesktop.org/show_bug.cgi?id=25717 Nicolas Kaiser <nikai(a)nikai.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | --- Comment #6 from Nicolas Kaiser <nikai(a)nikai.net> 2011-02-09 08:37:27 PST --- Running gltestperf with r600g locks up hard at my place in benchmark 3. System environment: -- system architecture: amd64 -- Linux distribution: Gentoo -- GPU: RS780G -- Model: ATI Radeon HD 3200 -- Display connector: VGA -- xf86-video-ati: 6.14.0 -- xserver: 1.9.3.902 -- mesa: c26478680989bd3d7303c5d772f7fb2a76045191 -- drm: 550fe2ca3b29ad2191eab4fdfbed9ed21e25492d -- kernel: 2.6.38-rc3 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[Bug 29833] [RADEON:KMS:M56P:R300G] crashes kicad when using modeset
by bugzilla-daemon＠freedesktop.org 09 Feb '11

09 Feb '11

https://bugs.freedesktop.org/show_bug.cgi?id=29833 Fabio Varesano <fabio.varesano(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |NOTABUG --- Comment #19 from Fabio Varesano <fabio.varesano(a)gmail.com> 2011-02-09 08:30:59 PST --- (In reply to comment #18) > Still an issue with more recent driver ? Nope. This was actually a bug in the program. However only some video drivers was letting this crash. For more info see: https://bugs.launchpad.net/kicad/+bug/582997 The fix has been committed in rev 2767 if you guys are interested in what was wrong. Thanks. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[Bug 31842] New: Implement GL_FIXED support
by bugzilla-daemon＠freedesktop.org 09 Feb '11

09 Feb '11

https://bugs.freedesktop.org/show_bug.cgi?id=31842 Summary: Implement GL_FIXED support Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: snorp(a)snorp.net Right now it looks like r600g (or any other gallium driver?) supports GL_FIXED. I'm trying to get this driver to work on Android, and they use this all over the place (as do some apps). Thanks! -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 2

[Bug 25114] [RADEON:KMS::R600C] nexuiz 2.5.2 crashes on demo5 (Silver City), errors on demo piece-o-cake too
by bugzilla-daemon＠freedesktop.org 09 Feb '11

09 Feb '11

https://bugs.freedesktop.org/show_bug.cgi?id=25114 Jerome Glisse <glisse(a)freedesktop.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|[R600] Nexuiz 2.5.2 crashes |[RADEON:KMS::R600C] nexuiz |on demo5 (Silver City), |2.5.2 crashes on demo5 |errors on demo piece-o-cake |(Silver City), errors on |too |demo piece-o-cake too --- Comment #11 from Jerome Glisse <glisse(a)freedesktop.org> 2011-02-09 08:03:04 PST --- Do you still have this issue with recent mesa+kernel ? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[Bug 31732] [RADEON:KMS:RS780:R600C-R600G] X crashes with "X: radeon_texture.c:682: radeon_store_teximage: Assertion `0' failed."
by bugzilla-daemon＠freedesktop.org 09 Feb '11

09 Feb '11

https://bugs.freedesktop.org/show_bug.cgi?id=31732 Jerome Glisse <glisse(a)freedesktop.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|X crashes with "X: |[RADEON:KMS:RS780:R600C-R60 |radeon_texture.c:682: |0G] X crashes with "X: |radeon_store_teximage: |radeon_texture.c:682: |Assertion `0' failed." |radeon_store_teximage: | |Assertion `0' failed." --- Comment #9 from Jerome Glisse <glisse(a)freedesktop.org> 2011-02-09 08:01:58 PST --- Do you still have this issue with more recent kernel + mesa ? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[Bug 21351] R600+DRI: glxgears crash
by bugzilla-daemon＠freedesktop.org 09 Feb '11

09 Feb '11

https://bugs.freedesktop.org/show_bug.cgi?id=21351 Jerome Glisse <glisse(a)freedesktop.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #7 from Jerome Glisse <glisse(a)freedesktop.org> 2011-02-09 07:56:17 PST --- glxgears works here (recent kernel/mesa) on various hw with r600c/r600g -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

← Newer
1
...
37
38
39
40
41
42
43
...
47
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel February 2011