[Bug 35192] BUG() in radeon driver with ATI Technologies Inc RV515 [Radeon X1300]
https://bugzilla.kernel.org/show_bug.cgi?id=35192 --- Comment #4 from Andrew Morton 2011-05-18 22:58:47 --- OK, thanks. Mystery solved. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 35192] BUG() in radeon driver with ATI Technologies Inc RV515 [Radeon X1300]
https://bugzilla.kernel.org/show_bug.cgi?id=35192 Stratos Psomadakis changed: What|Removed |Added CC||psomas at ece.ntua.gr --- Comment #3 from Stratos Psomadakis 2011-05-18 22:55:59 --- Actually, radeon_cp_init() crashed only with later kernel configurations which had CONFIG_MODULES=n. And that's because of the commit 737a3b. Previous configuration had CONFIG_MODULES=y, but with 2.6.36 kernels, and the bug/dmesg output was different I think. Probably it was a different, 2.6.36-related bug, which was fixed in later kernel releases. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Summary of the V4L2 discussions during LDS - was: Re: Embedded Linux memory management interest group list
Hans Verkuil wrote: > Note that many video receivers cannot stall. You can't tell them to wait until > the last buffer finished processing. This is different from some/most? > sensors. Not even image sensors. They just output the frame data; if the receiver runs out of buffers the data is just lost. And if any part of the frame is lost, there's no use for other parts of it either. But that's something the receiver must handle, i.e. discard the data and increment frame number (field_count in v4l2_buffer). The interfaces used by image sensors, be they parallel or serial, do not provide means to inform the sensor that the receiver has run out of buffer space. These interfaces are just unidirectional. Regards, -- Sakari Ailus sakari.ailus at maxwell.research.nokia.com
[Bug 35192] BUG() in radeon driver with ATI Technologies Inc RV515 [Radeon X1300]
https://bugzilla.kernel.org/show_bug.cgi?id=35192 Andrew Morton changed: What|Removed |Added CC||akpm at linux-foundation.org, ||greg at kroah.com --- Comment #2 from Andrew Morton 2011-05-18 21:52:58 --- OK, this is a bit strange. I can see that Greg's 737a3bb9416ce2a7c7a4170852473a4fcc9 would cause radeon_cp_init() to crash when it is called via ioctl. It calls platform_device_register_resndata(), but platform_device_register_resndata() got unloaded from kernel memory. But that will only happen if CONFIG_MODULES=n, and in the config attached to the gentto report, CONFIG_MODULES=y. So platform_device_register_resndata() won't have been unloaded! Still, we should revert 737a3bb9416ce2a7c7a4170852473a4fcc9, as its assumptions are wrong in this case. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
PROBLEM: i915 regression between 2.6.39-rc6 and 2.6.39-rc7
Hello, On Wed, 2011-05-18 at 11:22 -0500, Michael Larabel wrote: > Try booting the latest kernel with "i915.semaphores=1" and it should be > fixed, at least for my SNB hardware. When I had it auto-bisected it came > down to this commit 087fbc9962e10a65fb0b542ecfc116ebf6cf1735 that > disabled semaphores. I confirm that it is working fine when enabling semaphore. Thanks a lot for the workaround, it is a pleasure to have a real laptop again ;) Good luck for the bisect. BR, > > -- Michael Larabel > > On 05/17/2011 07:06 AM, Eric Leblond wrote: > > Hello, > > > > When running the 2.6.39-rc7, I've observed a problem on my laptop (DELL > > XPS15) which uses the i915 driver. Frequently, when moving the mouse > > over, the cursor does only trigger the modification on the desktop after > > a few seconds (like icons > > highligthing). When this occurs, the following message appear in the > > kernel log at the moment when the waited action occurs: > > > > [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... blt ring > > idle [waiting on 905, at 905], missed IRQ? > > > > Switching back to 2.6.39-rc6 fixes the issue. > > > > It runs gnome 3 which uses glx to add some effect. Maybe this is linked. > > When using the simple twm window manager, the problem does not seem to > > occur. > > > > Keywords: drm, i915 > > Kernel version: Linux version 2.6.39-rc7+ (eric at tiger) (gcc version > > 4.6.1 20110507 (prerelease) (Debian 4.6.0-7) ) #3 SMP Sun May 15 11:31:14 > > CEST 2011 > > Processor: Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz > > > > Kernel log for i915: > > May 17 13:30:36 tiger kernel: [ 15.458754] i915 :00:02.0: PCI INT A > > -> GSI 16 (level, low) -> IRQ 16 > > May 17 13:30:36 tiger kernel: [ 15.458760] i915 :00:02.0: setting > > latency timer to 64 > > May 17 13:30:36 tiger kernel: [ 15.513847] i915 :00:02.0: irq 52 for > > MSI/MSI-X > > May 17 13:30:36 tiger kernel: [ 16.011208] [drm] Initialized i915 1.6.0 > > 20080730 for :00:02.0 on minor 0 > > May 17 13:31:12 tiger kernel: [ 59.343937] [drm:i915_hangcheck_ring_idle] > > *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 905, at 905], > > missed IRQ? > > May 17 13:31:17 tiger kernel: [ 63.998439] [drm:i915_hangcheck_ring_idle] > > *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 947, at 947], > > missed IRQ? > > May 17 13:32:27 tiger kernel: [ 134.591975] [drm:i915_hangcheck_ring_idle] > > *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 49015, at > > 49015], missed IRQ? > > May 17 13:32:29 tiger kernel: [ 136.127493] [drm:i915_hangcheck_ring_idle] > > *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 49154, at > > 49154], missed IRQ? > > > > lspci - for i915: > > 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core > > Processor Family Integrated Graphics Controller (rev 09) (prog-if 00 [VGA > > controller]) > > Subsystem: Dell Device 04b6 > > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- > > ParErr- Stepping- SERR- FastB2B- DisINTx+ > > Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- > > DEVSEL=fast>TAbort-Latency: 0 > > Interrupt: pin A routed to IRQ 52 > > Region 0: Memory at f140 (64-bit, non-prefetchable) [size=4M] > > Region 2: Memory at e000 (64-bit, prefetchable) [size=256M] > > Region 4: I/O ports at 4000 [size=64] > > Expansion ROM at [disabled] > > Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- > > Address: fee0300c Data: 41c9 > > Capabilities: [d0] Power Management version 2 > > Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA > > PME(D0-,D1-,D2-,D3hot-,D3cold-) > > Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- > > Capabilities: [a4] PCI Advanced Features > > AFCap: TP+ FLR+ > > AFCtrl: FLR- > > AFStatus: TP- > > Kernel driver in use: i915 > > > > lspci: > > 00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family > > DRAM Controller (rev 09) > > 00:01.0 PCI bridge: Intel Corporation 2nd Generation Core Processor Family > > PCI Express Root Port (rev 09) > > 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core > > Processor Family Integrated Graphics Controller (rev 09) > > 00:16.0 Communication controller: Intel Corporation 6 Series Chipset Family > > MEI Controller #1 (rev 04) > > 00:1a.0 USB Controller: Intel Corporation 6 Series Chipset Family USB > > Enhanced Host Controller #2 (rev 05) > > 00:1b.0 Audio device: Intel Corporation 6 Series Chipset Family High > > Definition Audio Controller (rev 05) > > 00:1c.0 PCI bridge: Intel Corporation 6 Series Chipset Family PCI Express > > Root Port 1 (rev b5) > > 00:1c.1 PCI bridge: Intel Corporation 6 Series Chipset Family PCI Express > > Root Port
PROBLEM: i915 regression between 2.6.39-rc6 and 2.6.39-rc7
Try booting the latest kernel with "i915.semaphores=1" and it should be fixed, at least for my SNB hardware. When I had it auto-bisected it came down to this commit 087fbc9962e10a65fb0b542ecfc116ebf6cf1735 that disabled semaphores. -- Michael Larabel On 05/17/2011 07:06 AM, Eric Leblond wrote: > Hello, > > When running the 2.6.39-rc7, I've observed a problem on my laptop (DELL > XPS15) which uses the i915 driver. Frequently, when moving the mouse > over, the cursor does only trigger the modification on the desktop after > a few seconds (like icons > highligthing). When this occurs, the following message appear in the > kernel log at the moment when the waited action occurs: > > [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... blt ring > idle [waiting on 905, at 905], missed IRQ? > > Switching back to 2.6.39-rc6 fixes the issue. > > It runs gnome 3 which uses glx to add some effect. Maybe this is linked. > When using the simple twm window manager, the problem does not seem to > occur. > > Keywords: drm, i915 > Kernel version: Linux version 2.6.39-rc7+ (eric at tiger) (gcc version 4.6.1 > 20110507 (prerelease) (Debian 4.6.0-7) ) #3 SMP Sun May 15 11:31:14 CEST 2011 > Processor: Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz > > Kernel log for i915: > May 17 13:30:36 tiger kernel: [ 15.458754] i915 :00:02.0: PCI INT A -> > GSI 16 (level, low) -> IRQ 16 > May 17 13:30:36 tiger kernel: [ 15.458760] i915 :00:02.0: setting > latency timer to 64 > May 17 13:30:36 tiger kernel: [ 15.513847] i915 :00:02.0: irq 52 for > MSI/MSI-X > May 17 13:30:36 tiger kernel: [ 16.011208] [drm] Initialized i915 1.6.0 > 20080730 for :00:02.0 on minor 0 > May 17 13:31:12 tiger kernel: [ 59.343937] [drm:i915_hangcheck_ring_idle] > *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 905, at 905], > missed IRQ? > May 17 13:31:17 tiger kernel: [ 63.998439] [drm:i915_hangcheck_ring_idle] > *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 947, at 947], > missed IRQ? > May 17 13:32:27 tiger kernel: [ 134.591975] [drm:i915_hangcheck_ring_idle] > *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 49015, at > 49015], missed IRQ? > May 17 13:32:29 tiger kernel: [ 136.127493] [drm:i915_hangcheck_ring_idle] > *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 49154, at > 49154], missed IRQ? > > lspci - for i915: > 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core > Processor Family Integrated Graphics Controller (rev 09) (prog-if 00 [VGA > controller]) > Subsystem: Dell Device 04b6 > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR- FastB2B- DisINTx+ > Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- > DEVSEL=fast>TAbort-Interrupt: pin A routed to IRQ 52 > Region 0: Memory at f140 (64-bit, non-prefetchable) [size=4M] > Region 2: Memory at e000 (64-bit, prefetchable) [size=256M] > Region 4: I/O ports at 4000 [size=64] > Expansion ROM at [disabled] > Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- > Address: fee0300c Data: 41c9 > Capabilities: [d0] Power Management version 2 > Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA > PME(D0-,D1-,D2-,D3hot-,D3cold-) > Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- > Capabilities: [a4] PCI Advanced Features > AFCap: TP+ FLR+ > AFCtrl: FLR- > AFStatus: TP- > Kernel driver in use: i915 > > lspci: > 00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family > DRAM Controller (rev 09) > 00:01.0 PCI bridge: Intel Corporation 2nd Generation Core Processor Family > PCI Express Root Port (rev 09) > 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core > Processor Family Integrated Graphics Controller (rev 09) > 00:16.0 Communication controller: Intel Corporation 6 Series Chipset Family > MEI Controller #1 (rev 04) > 00:1a.0 USB Controller: Intel Corporation 6 Series Chipset Family USB > Enhanced Host Controller #2 (rev 05) > 00:1b.0 Audio device: Intel Corporation 6 Series Chipset Family High > Definition Audio Controller (rev 05) > 00:1c.0 PCI bridge: Intel Corporation 6 Series Chipset Family PCI Express > Root Port 1 (rev b5) > 00:1c.1 PCI bridge: Intel Corporation 6 Series Chipset Family PCI Express > Root Port 2 (rev b5) > 00:1c.3 PCI bridge: Intel Corporation 6 Series Chipset Family PCI Express > Root Port 4 (rev b5) > 00:1c.4 PCI bridge: Intel Corporation 6 Series Chipset Family PCI Express > Root Port 5 (rev b5) > 00:1c.5 PCI bridge: Intel Corporation 6 Series Chipset Family PCI Express > Root Port 6 (rev b5) > 00:1d.0 USB Controller: Intel Corporation 6 Series Chipset Family USB > Enhanced Host Controller #1 (rev 05) > 00:1f.0 ISA
[RFC] Standardize YUV support in the fbdev API
On Wednesday, May 18, 2011 00:44:26 Felipe Contreras wrote: > On Wed, May 18, 2011 at 1:07 AM, Laurent Pinchart > wrote: > > I need to implement support for a YUV frame buffer in an fbdev driver. As > > the > > fbdev API doesn't support this out of the box, I've spent a couple of days > > reading fbdev (and KMS) code and thinking about how we could cleanly add YUV > > support to the API. I'd like to share my findings and thoughts, and > > hopefully > > receive some comments back. > > > > The terms 'format', 'pixel format', 'frame buffer format' and 'data format' > > will be used interchangeably in this e-mail. They all refer to the way > > pixels > > are stored in memory, including both the representation of a pixel as > > integer > > values and the layout of those integer values in memory. > > This is a great proposal. It was about time! > > > The third solution has my preference. Comments and feedback will be > > appreciated. I will then work on a proof of concept and submit patches. > > I also would prefer the third solution. I don't think there's much > difference from the user-space point of view, and a new ioctl would be > cleaner. Also the v4l2 fourcc's should do. I agree with this. We might want to take the opportunity to fix this section of the V4L2 Spec: http://www.xs4all.nl/~hverkuil/spec/media.html#pixfmt-rgb There are two tables, 2.6 and 2.7. But 2.6 is almost certainly wrong and should be removed. I suspect many if not all V4L2 drivers are badly broken for big-endian systems and report the wrong pixel formats. Officially the pixel formats reflect the contents of the memory. But everything is swapped on a big endian system, so you are supposed to report a different pix format. I can't remember seeing any driver do that. Some have built-in swapping, though, and turn that on if needed. I really need to run some tests, but I've been telling myself this for years now :-( Regards, Hans
[Bug 37296] [r600g] lighting artifacts on frozenbyte games
https://bugs.freedesktop.org/show_bug.cgi?id=37296 Michel D?nzer changed: What|Removed |Added Summary|[r600g] lightning artifacts |[r600g] lighting artifacts |on frozenbyte games |on frozenbyte games Component|Drivers/DRI/R600|Drivers/Gallium/r600 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[RFC] Standardize YUV support in the fbdev API
Hi everybody,
I need to implement support for a YUV frame buffer in an fbdev driver. As the
fbdev API doesn't support this out of the box, I've spent a couple of days
reading fbdev (and KMS) code and thinking about how we could cleanly add YUV
support to the API. I'd like to share my findings and thoughts, and hopefully
receive some comments back.
The terms 'format', 'pixel format', 'frame buffer format' and 'data format'
will be used interchangeably in this e-mail. They all refer to the way pixels
are stored in memory, including both the representation of a pixel as integer
values and the layout of those integer values in memory.
History and current situation
-
The fbdev API predates YUV frame buffers. In those old days developers only
cared (and probably thought) about RGB frame buffers, and they developed an
API that could express all kind of weird RGB layout in memory (such as R-
GGG- for instance, I can't imagine hardware implementing that).
This resulted in individual bit field description for the red, green, blue and
alpha components:
struct fb_bitfield {
__u32 offset; /* beginning of bitfield*/
__u32 length; /* length of bitfield */
__u32 msb_right; /* != 0 : Most significant bit is */
/* right */
};
Grayscale formats were pretty common, so a grayscale field tells color formats
(grayscale == 0) from grayscale formats (grayscale != 0).
People already realized that hardware developers were crazily inventive (the
word to remember here is crazily), and that non-standard formats would be
needed at some point. The fb_var_screeninfo ended up containing the following
format-related fields.
struct fb_var_screeninfo {
...
__u32 bits_per_pixel; /* guess what */
__u32 grayscale; /* != 0 Graylevels instead of colors */
struct fb_bitfield red;/* bitfield in fb mem if true color, */
struct fb_bitfield green; /* else only length is significant */
struct fb_bitfield blue;
struct fb_bitfield transp; /* transparency */
__u32 nonstd; /* != 0 Non standard pixel format */
...
};
Two bits have been specified for the nonstd field:
#define FB_NONSTD_HAM 1 /* Hold-And-Modify (HAM)*/
#define FB_NONSTD_REV_PIX_IN_B 2 /* order of pixels in each byte is reversed
*/
The FB_NONSTD_HAM bit is used by the video/amifb.c driver only to enable HAM
mode[1]. I very much doubt that any new hardware will implement HAM mode (and
I certainly hope none will).
The FB_NONSTD_REV_PIX_IN_B is used in video/fb_draw.h by the generic bitblit,
fillrect and copy area implementations, not directly by drivers.
A couple of drivers hardcode the nonstd field to 1 for some reason. Those are
video/arcfb.c (1bpp gray display), video/hecubafb.c (1bpp gray display) and
video/metronomefb.c (8bpp gray display).
The following drivers use nonstd for various other (and sometimes weird)
purposes:
video/arkfb.c
Used in 4bpp mode only, to control fb_setcolreg operation
video/fsl-diu-fb.c
Set var->nonstd bits into var->sync (why?)
video/pxafb.c
Encode frame buffer xpos and ypos in the nonstd field
video/s3fb.c
Used in 4bpp mode only, to control fb_setcolreg operation
video/vga16fb.c
When panning in non-8bpp, non-text mode, decrement xoffset
Do some other weird stuff when not 0
video/i810/i810_main.c
Select direct color mode when set to 1 (truecolor otherwise)
Fast forward a couple of years, hardware provides support for YUV frame
buffers. Several drivers had to provide YUV format selection to applications,
without any standard API to do so. All of them used the nonstd field for that
purpose:
media/video/ivtv/
Enable YUV mode when set to 1
video/pxafb.c
Encode pixel format in the nonstd field
video/sh_mobile_lcdfb.c
If bpp == 12 and nonstd != 0, enable NV12 mode
If bpp == 16 or bpp == 24, ?
video/omap/omapfb_main.c
Select direct color mode when set to 1 (depend on bpp otherwise)
Used as a pixel format identifier (YUV422, YUV420 or YUY422)
video/omap2/omapfb/omapfb-main.c
Select direct color mode when set to 1 (depend on bpp otherwise)
Used as a pixel format identifier (YUV422 or YUY422)
Those drivers use the nonstd field in different, incompatible ways.
Other related APIs
--
Beside the fbdev API, two other kernel/userspace APIs deal with video-related
modes and formats.
- Kernel Mode Setting (KMS)
The KMS API is similar in purpose to XRandR. Its main purpose is to provide a
kernel API to configure output video modes. As such, it doesn't care about
frame buffer formats, as they are irrelevant at the CRTC output.
In addition to handling
Re: [RFC] Standardize YUV support in the fbdev API
On Wednesday, May 18, 2011 00:44:26 Felipe Contreras wrote: On Wed, May 18, 2011 at 1:07 AM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: I need to implement support for a YUV frame buffer in an fbdev driver. As the fbdev API doesn't support this out of the box, I've spent a couple of days reading fbdev (and KMS) code and thinking about how we could cleanly add YUV support to the API. I'd like to share my findings and thoughts, and hopefully receive some comments back. The terms 'format', 'pixel format', 'frame buffer format' and 'data format' will be used interchangeably in this e-mail. They all refer to the way pixels are stored in memory, including both the representation of a pixel as integer values and the layout of those integer values in memory. This is a great proposal. It was about time! The third solution has my preference. Comments and feedback will be appreciated. I will then work on a proof of concept and submit patches. I also would prefer the third solution. I don't think there's much difference from the user-space point of view, and a new ioctl would be cleaner. Also the v4l2 fourcc's should do. I agree with this. We might want to take the opportunity to fix this section of the V4L2 Spec: http://www.xs4all.nl/~hverkuil/spec/media.html#pixfmt-rgb There are two tables, 2.6 and 2.7. But 2.6 is almost certainly wrong and should be removed. I suspect many if not all V4L2 drivers are badly broken for big-endian systems and report the wrong pixel formats. Officially the pixel formats reflect the contents of the memory. But everything is swapped on a big endian system, so you are supposed to report a different pix format. I can't remember seeing any driver do that. Some have built-in swapping, though, and turn that on if needed. I really need to run some tests, but I've been telling myself this for years now :-( Regards, Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37296] [r600g] lighting artifacts on frozenbyte games
https://bugs.freedesktop.org/show_bug.cgi?id=37296 Michel Dänzer mic...@daenzer.net changed: What|Removed |Added Summary|[r600g] lightning artifacts |[r600g] lighting artifacts |on frozenbyte games |on frozenbyte games Component|Drivers/DRI/R600|Drivers/Gallium/r600 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
PROBLEM: i915 regression between 2.6.39-rc6 and 2.6.39-rc7
Hello, When running the 2.6.39-rc7, I've observed a problem on my laptop (DELL XPS15) which uses the i915 driver. Frequently, when moving the mouse over, the cursor does only trigger the modification on the desktop after a few seconds (like icons highligthing). When this occurs, the following message appear in the kernel log at the moment when the waited action occurs: [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 905, at 905], missed IRQ? Switching back to 2.6.39-rc6 fixes the issue. It runs gnome 3 which uses glx to add some effect. Maybe this is linked. When using the simple twm window manager, the problem does not seem to occur. Keywords: drm, i915 Kernel version: Linux version 2.6.39-rc7+ (eric@tiger) (gcc version 4.6.1 20110507 (prerelease) (Debian 4.6.0-7) ) #3 SMP Sun May 15 11:31:14 CEST 2011 Processor: Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz Kernel log for i915: May 17 13:30:36 tiger kernel: [ 15.458754] i915 :00:02.0: PCI INT A - GSI 16 (level, low) - IRQ 16 May 17 13:30:36 tiger kernel: [ 15.458760] i915 :00:02.0: setting latency timer to 64 May 17 13:30:36 tiger kernel: [ 15.513847] i915 :00:02.0: irq 52 for MSI/MSI-X May 17 13:30:36 tiger kernel: [ 16.011208] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0 May 17 13:31:12 tiger kernel: [ 59.343937] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 905, at 905], missed IRQ? May 17 13:31:17 tiger kernel: [ 63.998439] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 947, at 947], missed IRQ? May 17 13:32:27 tiger kernel: [ 134.591975] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 49015, at 49015], missed IRQ? May 17 13:32:29 tiger kernel: [ 136.127493] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 49154, at 49154], missed IRQ? lspci - for i915: 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller]) Subsystem: Dell Device 04b6 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 52 Region 0: Memory at f140 (64-bit, non-prefetchable) [size=4M] Region 2: Memory at e000 (64-bit, prefetchable) [size=256M] Region 4: I/O ports at 4000 [size=64] Expansion ROM at unassigned [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Address: fee0300c Data: 41c9 Capabilities: [d0] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [a4] PCI Advanced Features AFCap: TP+ FLR+ AFCtrl: FLR- AFStatus: TP- Kernel driver in use: i915 lspci: 00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family DRAM Controller (rev 09) 00:01.0 PCI bridge: Intel Corporation 2nd Generation Core Processor Family PCI Express Root Port (rev 09) 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) 00:16.0 Communication controller: Intel Corporation 6 Series Chipset Family MEI Controller #1 (rev 04) 00:1a.0 USB Controller: Intel Corporation 6 Series Chipset Family USB Enhanced Host Controller #2 (rev 05) 00:1b.0 Audio device: Intel Corporation 6 Series Chipset Family High Definition Audio Controller (rev 05) 00:1c.0 PCI bridge: Intel Corporation 6 Series Chipset Family PCI Express Root Port 1 (rev b5) 00:1c.1 PCI bridge: Intel Corporation 6 Series Chipset Family PCI Express Root Port 2 (rev b5) 00:1c.3 PCI bridge: Intel Corporation 6 Series Chipset Family PCI Express Root Port 4 (rev b5) 00:1c.4 PCI bridge: Intel Corporation 6 Series Chipset Family PCI Express Root Port 5 (rev b5) 00:1c.5 PCI bridge: Intel Corporation 6 Series Chipset Family PCI Express Root Port 6 (rev b5) 00:1d.0 USB Controller: Intel Corporation 6 Series Chipset Family USB Enhanced Host Controller #1 (rev 05) 00:1f.0 ISA bridge: Intel Corporation HM67 Express Chipset Family LPC Controller (rev 05) 00:1f.2 SATA controller: Intel Corporation 6 Series Chipset Family 6 port SATA AHCI Controller (rev 05) 00:1f.3 SMBus: Intel Corporation 6 Series Chipset Family SMBus Controller (rev 05) 01:00.0 VGA compatible controller: nVidia Corporation Device 0df5 (rev a1) 03:00.0 Network controller: Intel Corporation Centrino Wireless-N 1000 04:00.0 USB Controller: NEC Corporation uPD720200 USB 3.0 Host
Re: Summary of the V4L2 discussions during LDS - was: Re: Embedded Linux memory management interest group list
Em 17-05-2011 09:49, Mauro Carvalho Chehab escreveu:
Em 15-05-2011 18:10, Hans Verkuil escreveu:
On Saturday, May 14, 2011 13:46:03 Mauro Carvalho Chehab wrote:
Em 14-05-2011 13:02, Hans Verkuil escreveu:
On Saturday, May 14, 2011 12:19:18 Mauro Carvalho Chehab wrote:
So, based at all I've seen, I'm pretty much convinced that the normal MMAP
way of streaming (VIDIOC_[REQBUF|STREAMON|STREAMOFF|QBUF|DQBUF ioctl's)
are not the best way to share data with framebuffers.
I agree with that, but it is a different story between two V4L2 devices.
There
you obviously want to use the streaming ioctls and still share buffers.
I don't think so. the requirement for syncing the framebuffer between the
two
V4L2 devices is pretty much the same as we have with one V4L2 device and
one GPU.
On both cases, the requirement is to pass a framebuffer between two
entities,
and not a video stream.
For example, imagine something like:
V4L2 camera = V4L2 encoder t MPEG2
||
LL== GPU
For the sake of clarity on my next comments, I'm naming the V4L2 camera
buffer
write endpoint as producer and the 2 buffer read endpoints as consumers.
Both GPU and the V4L2 encoder should use the same logic to be sure that
they will
use a buffer that were filled already by the camera. Also, the V4L2 camera
driver can't re-use such framebuffer before being sure that both consumers
has already stopped using it.
No. A camera whose output is sent to a resizer and then to a SW/FW/HW encoder
is a typical example where you want to queue/dequeue buffers.
Why? On a framebuffer-oriented set of ioctl's, some kernel internal calls will
need to take care of the buffer usage, in order to be sure when a buffer can
be rewritten, as userspace has no way to know when a buffer needs to be
queued/dequeued.
In other words, the framebuffer kernel API will probably be using a kernel
structure like:
struct v4l2_fb_handler {
bool has_finished; /* Marks when a handler
finishes to handle the buffer */
bool is_producer; /* Used by the handler
that writes data into the buffer */
struct list_head *handlers; /* List with all
handlers */
void (*qbuf)(struct v4l2_fb_handler *handler); /* qbuf-like callback,
called after having a buffer filled */
v4l2_buffer_ID buf;/* Buffer ID (or
filehandler?) - In practice, it will probably be a list with the available
buffers */
void *priv; /* handler priv data */
}
While stream is on, a kernel logic will run a loop, doing basically the steps
bellow:
1) Wait for the producer to rise the has_finished flag;
2) call qbuf() for all consumers. The qbuf() call shouldn't block; it
just calls
a per-handler logic to start using that buffer;
3) When each fb handler finishes using its buffer, it will rise
has_finished flag;
4) After having all buffer handlers marked as has_finished, cleans the
has_finished
flags and re-queue the buffer.
Step (2) is equivalent to VIDIOC_QBUF, and step (4) is equivalent to
VIDIOC_DQBUF.
PS.: The above is just a simplified view of such handler. We'll probably need
more steps. For
example, between (1) and (2) it may probably need some logic to check if is
there an available
empty buffer. If not, create a new one and use it.
What happens with REQBUF/QBUF/DQBUF is that:
- with those calls, there's just one buffer consumer, and just one
buffer producer;
- either the producer or the consumer is on userspace, and the other
pair is
at kernelspace;
- buffers are allocated before the start of a process, via an explicit
call;
- buffers need to be mmapped, in order to be visible at userspace.
None of the above applies to a framebuffer-oriented API:
- more than one buffer consumer is allowed;
- consumers and producers are on kernelspace (it might be needed to
have an
an API for handling such buffers also on userspace, although it doesn't sound
a good
idea to me, IMHO);
A side note: in the specific case of X server and display drivers, such
kernelspace-userspace
API for buffers already exists. I don't know DRI/GEM/KMS enough to tell
exactly how this work
or if it will require some changes or not, in order to work like the above, but
it seems that
the right approach is to try to use or extend the existing API's, instead of
creating
something new.
The main point is: DQBUF/QBUF API assumes that userspace has full control at
the buffer usage,
and buffer is handled at userspace (so, they should be mmapped there). This is
not the general
case where another IP block at the chip is re-using the buffer, or if is there
another DMA engine
doing direct transfers on it.
- buffers
Re: Summary of the V4L2 discussions during LDS - was: Re: Embedded Linux memory management interest group list
Em 16-05-2011 17:45, Guennadi Liakhovetski escreveu: On Sat, 14 May 2011, Mauro Carvalho Chehab wrote: Em 18-04-2011 17:15, Jesse Barker escreveu: One of the big issues we've been faced with at Linaro is around GPU and multimedia device integration, in particular the memory management requirements for supporting them on ARM. This next cycle, we'll be focusing on driving consensus around a unified memory management solution for embedded systems that support multiple architectures and SoCs. This is listed as part of our working set of requirements for the next six-month cycle (in spite of the URL, this is not being treated as a graphics-specific topic - we also have participation from multimedia and kernel working group folks): https://wiki.linaro.org/Cycles//TechnicalTopics/Graphics As part of the memory management needs, Linaro organized several discussions during Linaro Development Summit (LDS), at Budapest, and invited me and other members of the V4L and DRI community to discuss about the requirements. I wish to thank Linaro for its initiative. [snip] Btw, the need of managing buffers is currently being covered by the proposal for new ioctl()s to support multi-sized video-buffers [1]. [1] http://www.spinics.net/lists/linux-media/msg30869.html It makes sense to me to discuss such proposal together with the above discussions, in order to keep the API consistent. The author of that RFC would have been thankful, if he had been put on Cc: ;) If I had added everybody interested on this summary, probably most smtp servers would refuse to deliver the message thinking that it is a SPAM ;) My intention were to submit a feedback about it when analysing your rfc patches, if you weren't able to see it before. But anyway, yes, consistency is good, but is my understanding correct, that functionally these two extensions - multi-size and buffer-forwarding/reuse are independent? Yes. We have to think about making the APIs consistent, e.g., by reusing data structures. But it's also good to make incremental smaller changes where possible, isn't it? So, yes, we should think about consistency, but develop and apply those two extensions separately? True, but one discussion can benefit the other. IMO, we should not rush new userspace API merges, to avoid merging a code that weren't reasonably discussed, as otherwise, the API will become too messy. Thanks, Mauro. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: PROBLEM: i915 regression between 2.6.39-rc6 and 2.6.39-rc7
Try booting the latest kernel with i915.semaphores=1 and it should be fixed, at least for my SNB hardware. When I had it auto-bisected it came down to this commit 087fbc9962e10a65fb0b542ecfc116ebf6cf1735 that disabled semaphores. -- Michael Larabel On 05/17/2011 07:06 AM, Eric Leblond wrote: Hello, When running the 2.6.39-rc7, I've observed a problem on my laptop (DELL XPS15) which uses the i915 driver. Frequently, when moving the mouse over, the cursor does only trigger the modification on the desktop after a few seconds (like icons highligthing). When this occurs, the following message appear in the kernel log at the moment when the waited action occurs: [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 905, at 905], missed IRQ? Switching back to 2.6.39-rc6 fixes the issue. It runs gnome 3 which uses glx to add some effect. Maybe this is linked. When using the simple twm window manager, the problem does not seem to occur. Keywords: drm, i915 Kernel version: Linux version 2.6.39-rc7+ (eric@tiger) (gcc version 4.6.1 20110507 (prerelease) (Debian 4.6.0-7) ) #3 SMP Sun May 15 11:31:14 CEST 2011 Processor: Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz Kernel log for i915: May 17 13:30:36 tiger kernel: [ 15.458754] i915 :00:02.0: PCI INT A - GSI 16 (level, low) - IRQ 16 May 17 13:30:36 tiger kernel: [ 15.458760] i915 :00:02.0: setting latency timer to 64 May 17 13:30:36 tiger kernel: [ 15.513847] i915 :00:02.0: irq 52 for MSI/MSI-X May 17 13:30:36 tiger kernel: [ 16.011208] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0 May 17 13:31:12 tiger kernel: [ 59.343937] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 905, at 905], missed IRQ? May 17 13:31:17 tiger kernel: [ 63.998439] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 947, at 947], missed IRQ? May 17 13:32:27 tiger kernel: [ 134.591975] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 49015, at 49015], missed IRQ? May 17 13:32:29 tiger kernel: [ 136.127493] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 49154, at 49154], missed IRQ? lspci - for i915: 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller]) Subsystem: Dell Device 04b6 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fastTAbort-TAbort-MAbort-SERR-PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 52 Region 0: Memory at f140 (64-bit, non-prefetchable) [size=4M] Region 2: Memory at e000 (64-bit, prefetchable) [size=256M] Region 4: I/O ports at 4000 [size=64] Expansion ROM atunassigned [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Address: fee0300c Data: 41c9 Capabilities: [d0] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [a4] PCI Advanced Features AFCap: TP+ FLR+ AFCtrl: FLR- AFStatus: TP- Kernel driver in use: i915 lspci: 00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family DRAM Controller (rev 09) 00:01.0 PCI bridge: Intel Corporation 2nd Generation Core Processor Family PCI Express Root Port (rev 09) 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) 00:16.0 Communication controller: Intel Corporation 6 Series Chipset Family MEI Controller #1 (rev 04) 00:1a.0 USB Controller: Intel Corporation 6 Series Chipset Family USB Enhanced Host Controller #2 (rev 05) 00:1b.0 Audio device: Intel Corporation 6 Series Chipset Family High Definition Audio Controller (rev 05) 00:1c.0 PCI bridge: Intel Corporation 6 Series Chipset Family PCI Express Root Port 1 (rev b5) 00:1c.1 PCI bridge: Intel Corporation 6 Series Chipset Family PCI Express Root Port 2 (rev b5) 00:1c.3 PCI bridge: Intel Corporation 6 Series Chipset Family PCI Express Root Port 4 (rev b5) 00:1c.4 PCI bridge: Intel Corporation 6 Series Chipset Family PCI Express Root Port 5 (rev b5) 00:1c.5 PCI bridge: Intel Corporation 6 Series Chipset Family PCI Express Root Port 6 (rev b5) 00:1d.0 USB Controller: Intel Corporation 6 Series Chipset Family USB Enhanced Host Controller #1 (rev 05) 00:1f.0 ISA bridge: Intel Corporation HM67 Express Chipset Family LPC Controller (rev 05) 00:1f.2 SATA controller: Intel Corporation 6 Series Chipset Family 6 port SATA AHCI
[Bug 35192] BUG() in radeon driver with ATI Technologies Inc RV515 [Radeon X1300]
https://bugzilla.kernel.org/show_bug.cgi?id=35192 Andrew Morton a...@linux-foundation.org changed: What|Removed |Added CC||a...@linux-foundation.org, ||g...@kroah.com --- Comment #2 from Andrew Morton a...@linux-foundation.org 2011-05-18 21:52:58 --- OK, this is a bit strange. I can see that Greg's 737a3bb9416ce2a7c7a4170852473a4fcc9 would cause radeon_cp_init() to crash when it is called via ioctl. It calls platform_device_register_resndata(), but platform_device_register_resndata() got unloaded from kernel memory. But that will only happen if CONFIG_MODULES=n, and in the config attached to the gentto report, CONFIG_MODULES=y. So platform_device_register_resndata() won't have been unloaded! Still, we should revert 737a3bb9416ce2a7c7a4170852473a4fcc9, as its assumptions are wrong in this case. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 35192] BUG() in radeon driver with ATI Technologies Inc RV515 [Radeon X1300]
https://bugzilla.kernel.org/show_bug.cgi?id=35192 Stratos Psomadakis pso...@ece.ntua.gr changed: What|Removed |Added CC||pso...@ece.ntua.gr --- Comment #3 from Stratos Psomadakis pso...@ece.ntua.gr 2011-05-18 22:55:59 --- Actually, radeon_cp_init() crashed only with later kernel configurations which had CONFIG_MODULES=n. And that's because of the commit 737a3b. Previous configuration had CONFIG_MODULES=y, but with 2.6.36 kernels, and the bug/dmesg output was different I think. Probably it was a different, 2.6.36-related bug, which was fixed in later kernel releases. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 35192] BUG() in radeon driver with ATI Technologies Inc RV515 [Radeon X1300]
https://bugzilla.kernel.org/show_bug.cgi?id=35192 --- Comment #4 from Andrew Morton a...@linux-foundation.org 2011-05-18 22:58:47 --- OK, thanks. Mystery solved. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/4] cayman acceleration fixes so far
These 4 patches allow me to run piglit to ~1460/1660 tests with my port of r600g to cayman. I still have to track down why the DDX composite accel isn't working though. I suspect we'll need a cayman accel is working flag as well. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/4] drm/radeon/cayman: setup hdp to invalidate and flush when asked
From: Dave Airlie airl...@redhat.com On cayman we need to set the bit to cause HDP flushes to invalidate the HDP cache also. Signed-off-by: Dave Airlie airl...@redhat.com --- drivers/gpu/drm/radeon/ni.c |4 drivers/gpu/drm/radeon/nid.h |2 ++ 2 files changed, 6 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c index 99f4f40..b205ba1 100644 --- a/drivers/gpu/drm/radeon/ni.c +++ b/drivers/gpu/drm/radeon/ni.c @@ -931,6 +931,10 @@ static void cayman_gpu_init(struct radeon_device *rdev) WREG32(CB_PERF_CTR3_SEL_0, 0); WREG32(CB_PERF_CTR3_SEL_1, 0); + tmp = RREG32(HDP_MISC_CNTL); + tmp |= HDP_FLUSH_INVALIDATE_CACHE; + WREG32(HDP_MISC_CNTL, tmp); + hdp_host_path_cntl = RREG32(HDP_HOST_PATH_CNTL); WREG32(HDP_HOST_PATH_CNTL, hdp_host_path_cntl); diff --git a/drivers/gpu/drm/radeon/nid.h b/drivers/gpu/drm/radeon/nid.h index 0f9a08b..b2088c1 100644 --- a/drivers/gpu/drm/radeon/nid.h +++ b/drivers/gpu/drm/radeon/nid.h @@ -136,6 +136,8 @@ #defineHDP_NONSURFACE_INFO 0x2C08 #defineHDP_NONSURFACE_SIZE 0x2C0C #define HDP_ADDR_CONFIG0x2F48 +#define HDP_MISC_CNTL 0x2F4C +#defineHDP_FLUSH_INVALIDATE_CACHE (1 0) #defineCC_SYS_RB_BACKEND_DISABLE 0x3F88 #defineGC_USER_SYS_RB_BACKEND_DISABLE 0x3F8C -- 1.7.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] drm/radeon/kms: add wait idle ioctl for eg-cayman
From: Dave Airlie airl...@redhat.com
None of the latest GPUs had this hooked up, this is necessary for
correct operation in a lot of cases, however we should test this on a few
GPUs in these families as we've had problems in this area before.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/radeon/radeon_asic.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_asic.c
b/drivers/gpu/drm/radeon/radeon_asic.c
index ca57619..d948265 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -782,6 +782,7 @@ static struct radeon_asic evergreen_asic = {
.hpd_fini = evergreen_hpd_fini,
.hpd_sense = evergreen_hpd_sense,
.hpd_set_polarity = evergreen_hpd_set_polarity,
+ .ioctl_wait_idle = r600_ioctl_wait_idle,
.gui_idle = r600_gui_idle,
.pm_misc = evergreen_pm_misc,
.pm_prepare = evergreen_pm_prepare,
@@ -828,6 +829,7 @@ static struct radeon_asic sumo_asic = {
.hpd_fini = evergreen_hpd_fini,
.hpd_sense = evergreen_hpd_sense,
.hpd_set_polarity = evergreen_hpd_set_polarity,
+ .ioctl_wait_idle = r600_ioctl_wait_idle,
.gui_idle = r600_gui_idle,
.pm_misc = evergreen_pm_misc,
.pm_prepare = evergreen_pm_prepare,
@@ -874,6 +876,7 @@ static struct radeon_asic btc_asic = {
.hpd_fini = evergreen_hpd_fini,
.hpd_sense = evergreen_hpd_sense,
.hpd_set_polarity = evergreen_hpd_set_polarity,
+ .ioctl_wait_idle = r600_ioctl_wait_idle,
.gui_idle = r600_gui_idle,
.pm_misc = evergreen_pm_misc,
.pm_prepare = evergreen_pm_prepare,
@@ -920,6 +923,7 @@ static struct radeon_asic cayman_asic = {
.hpd_fini = evergreen_hpd_fini,
.hpd_sense = evergreen_hpd_sense,
.hpd_set_polarity = evergreen_hpd_set_polarity,
+ .ioctl_wait_idle = r600_ioctl_wait_idle,
.gui_idle = r600_gui_idle,
.pm_misc = evergreen_pm_misc,
.pm_prepare = evergreen_pm_prepare,
--
1.7.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
