[Bug 64257] RS880 issues with r600-llvm-compiler
https://bugs.freedesktop.org/show_bug.cgi?id=64257 --- Comment #3 from Michel Dänzer --- Could be either, but you generally need matching Git snapshots anyway. -- 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
Re: [PATCH] mgag200 code cleanup patches
Dear Christopher, Am Montag, den 29.04.2013, 14:37 -0400 schrieb Christopher Harvey: > I submitted these a while ago, but I think they got lost in the > mailing list. Just wanted to make sure they get a shot at the merge > window. as you resend the patches you could have easily amended the commit message to address my comments. Thanks again for your patches and let’s hope that they get in with the next merge window. Thanks, Paul ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 63732] [KDE] - display switching problem with kwin_gles and radeon driver.
https://bugs.freedesktop.org/show_bug.cgi?id=63732 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- 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
Re: [PATCHv5 0/2] Speed Cap fixes for ppc64
On Fri, May 3, 2013 at 7:01 PM, Benjamin Herrenschmidt wrote: > On Fri, 2013-05-03 at 19:43 -0300, Kleber Sacilotto de Souza wrote: > >> This patch series does: >> 1. max_bus_speed is used to set the device to gen2 speeds >> 2. on power there's no longer a conflict between the pseries call and other >> architectures, because the overwrite is done via a ppc_md hook >> 3. radeon is using bus->max_bus_speed instead of >> drm_pcie_get_speed_cap_mask >> for gen2 capability detection >> >> The first patch consists of some architecture changes, such as adding a hook >> on >> powerpc for pci_root_bridge_prepare, so that pseries will initialize it to a >> function, while all other architectures get a NULL pointer. So that whenever >> pci_create_root_bus is called, we'll get max_bus_speed properly setup from >> OpenFirmware. >> >> The second patch consists of simple radeon changes not to call >> drm_get_pcie_speed_cap_mask anymore. I assume that on x86 machines, >> the max_bus_speed property will be properly set already. > > So I'm ok with the approach now and I might even put the powerpc patch > in for 3.10 since arguably we are fixing a nasty bug (uninitialized > max_bus_speed). > > David, what's your feeling about the radeon change ? It would be nice if > that could go in soon for various distro targets :-) On the other hand > I'm not going to be pushy if you are not comfortable with it. FWIW, the radeon change looks fine to me. Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv5 0/2] Speed Cap fixes for ppc64
n Mon, May 6, 2013 at 10:32 AM, Alex Deucher wrote: > On Fri, May 3, 2013 at 7:01 PM, Benjamin Herrenschmidt > wrote: >> On Fri, 2013-05-03 at 19:43 -0300, Kleber Sacilotto de Souza wrote: >> >>> This patch series does: >>> 1. max_bus_speed is used to set the device to gen2 speeds >>> 2. on power there's no longer a conflict between the pseries call and >>> other >>> architectures, because the overwrite is done via a ppc_md hook >>> 3. radeon is using bus->max_bus_speed instead of >>> drm_pcie_get_speed_cap_mask >>> for gen2 capability detection >>> >>> The first patch consists of some architecture changes, such as adding a >>> hook on >>> powerpc for pci_root_bridge_prepare, so that pseries will initialize it to a >>> function, while all other architectures get a NULL pointer. So that whenever >>> pci_create_root_bus is called, we'll get max_bus_speed properly setup from >>> OpenFirmware. >>> >>> The second patch consists of simple radeon changes not to call >>> drm_get_pcie_speed_cap_mask anymore. I assume that on x86 machines, >>> the max_bus_speed property will be properly set already. >> >> So I'm ok with the approach now and I might even put the powerpc patch >> in for 3.10 since arguably we are fixing a nasty bug (uninitialized >> max_bus_speed). >> >> David, what's your feeling about the radeon change ? It would be nice if >> that could go in soon for various distro targets :-) On the other hand >> I'm not going to be pushy if you are not comfortable with it. > > FWIW, the radeon change looks fine to me. > > Alex As said previously, looks fine to me too. Cheers, Jerome ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60848] [bisected] r600g: add htile support cause gpu lockup in Dishonored wine.
https://bugs.freedesktop.org/show_bug.cgi?id=60848 Jerome Glisse changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Jerome Glisse --- Closing pushed to master and going to push to 9.1 -- 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
[Bug 59592] Radeon HD 5670: reproducable GPU lockups with htile enabled
https://bugs.freedesktop.org/show_bug.cgi?id=59592 Jerome Glisse changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Jerome Glisse --- Closing pushed to master and going to push to 9.1 -- 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
[Bug 62466] r600g hyperz lockups with KSP 0.19
https://bugs.freedesktop.org/show_bug.cgi?id=62466 Jerome Glisse changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Jerome Glisse --- Closing pushed to master and going to push to 9.1 -- 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
[Bug 62669] HyperZ freeze when playing PrBoom-Plus demo with lots of monsters
https://bugs.freedesktop.org/show_bug.cgi?id=62669 Jerome Glisse changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Jerome Glisse --- Closing pushed to master and going to push to 9.1 -- 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
Re: [PATCH] [TRIVIAL] v2: Fix declaration of intel_gmbus_{is_forced_bit/is_port_falid} in i915 driver.
On Mon, May 06, 2013 at 02:52:08PM +0200, dl...@gmx.de wrote: > From: Jan-Simon Möller > > 20130509: v2: (re-)add inline upon request. > > Description: > intel_gmbus_is_forced_bit is no extern as its body is right below. > Likewise for intel_gmbus_is_port_valid. > > This fixes a compilation issue with clang. An initial version of this patch > was developed by PaX Team . > This is respin of this patch. > > Signed-off-by: Jan-Simon Möller > CC: pagee...@freemail.hu > CC: daniel.vet...@ffwll.ch > CC: airl...@linux.ie > CC: intel-...@lists.freedesktop.org > CC: dri-devel@lists.freedesktop.org > CC: linux-ker...@vger.kernel.org Queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64257] RS880 issues with r600-llvm-compiler
https://bugs.freedesktop.org/show_bug.cgi?id=64257 --- Comment #4 from Tom Stellard --- I just pushed the Mesa patch that updates the GPU mappings to account for the new processors in LLVM. Can you re-test with the latest code from the git repository? -- 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
Re: [PATCH] drm/udl: avoid swiotlb for imported vmap buffers.
On Mon, May 06, 2013 at 10:35:35AM +1000, Dave Airlie wrote: > >> > >> However if we don't set a dma mask on the usb device, the mapping > >> ends up using swiotlb on machines that have it enabled, which > >> is less than desireable. > >> > >> Signed-off-by: Dave Airlie > > > > Fyi for everyone else who was not on irc when Dave&I discussed this: > > This really shouldn't be required and I think the real issue is that > > udl creates a dma_buf attachement (which is needed for device dma > > only), but only really wants to do cpu access through vmap/kmap. So > > not attached the device should be good enough. Cc'ing a few more lists > > for better fyi ;-) > > Though I've looked at this a bit more, and since I want to be able to expose > shared objects as proper GEM objects from the import side I really > need that list of pages. Hm, what does "proper GEM object" mean in the context of udl? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 62466] r600g hyperz lockups with KSP 0.19
https://bugs.freedesktop.org/show_bug.cgi?id=62466 --- Comment #9 from l...@mail.ru --- Hi, Gerome! Do I understand correctly, this patch is only for R600g AND its only for kernel (not mesa or DDI) ? Thanks for the fix! Unfortunately I have currently no access to the machine. When I have it, I will test the case on the sourcecode of kernel that I had - vanilla & crashing(1), as well as with your patch(2), and then if that happens in more actual kernel 3.8. (ubuntu raring)(3) and finally the kernel current with patch (4) I will test both performance with PTS Urban Terror profile, as well as stability exactly in the case I had and report back the results. That said I am pretty sure it works out, as others already confirm that, but still - I would like you to send me your paypal account data - for beers (green tea, coffee etc) money.. I know that you are employed by RedHat, its only a personal way to thank you for patching. Thank you! -- 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
Re: [PATCH] drm/udl: avoid swiotlb for imported vmap buffers.
On Tue, May 7, 2013 at 1:59 AM, Daniel Vetter wrote: > On Mon, May 06, 2013 at 10:35:35AM +1000, Dave Airlie wrote: >> >> >> >> However if we don't set a dma mask on the usb device, the mapping >> >> ends up using swiotlb on machines that have it enabled, which >> >> is less than desireable. >> >> >> >> Signed-off-by: Dave Airlie >> > >> > Fyi for everyone else who was not on irc when Dave&I discussed this: >> > This really shouldn't be required and I think the real issue is that >> > udl creates a dma_buf attachement (which is needed for device dma >> > only), but only really wants to do cpu access through vmap/kmap. So >> > not attached the device should be good enough. Cc'ing a few more lists >> > for better fyi ;-) >> >> Though I've looked at this a bit more, and since I want to be able to expose >> shared objects as proper GEM objects from the import side I really >> need that list of pages. > > Hm, what does "proper GEM object" mean in the context of udl? One that appears the same as a GEM object created by userspace. i.e. mmap works. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64201] OpenCL usage result segmentation fault on r600g with HD6850.
https://bugs.freedesktop.org/show_bug.cgi?id=64201 --- Comment #11 from Aaron Watry --- If you're experiencing GPU lockups w/ OpenCL, I'd recommend making sure that you mesa includes: http://cgit.freedesktop.org/mesa/mesa/commit/?id=4539f8e20af286d1f521eb016c89c6d9af0b801c This fixed a lot of common CL-based lockups on my Radeon 6850. -- 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
Re: [PATCH] drm/udl: avoid swiotlb for imported vmap buffers.
On Mon, May 6, 2013 at 9:56 PM, Dave Airlie wrote: > On Tue, May 7, 2013 at 1:59 AM, Daniel Vetter wrote: >> On Mon, May 06, 2013 at 10:35:35AM +1000, Dave Airlie wrote: >>> >> >>> >> However if we don't set a dma mask on the usb device, the mapping >>> >> ends up using swiotlb on machines that have it enabled, which >>> >> is less than desireable. >>> >> >>> >> Signed-off-by: Dave Airlie >>> > >>> > Fyi for everyone else who was not on irc when Dave&I discussed this: >>> > This really shouldn't be required and I think the real issue is that >>> > udl creates a dma_buf attachement (which is needed for device dma >>> > only), but only really wants to do cpu access through vmap/kmap. So >>> > not attached the device should be good enough. Cc'ing a few more lists >>> > for better fyi ;-) >>> >>> Though I've looked at this a bit more, and since I want to be able to expose >>> shared objects as proper GEM objects from the import side I really >>> need that list of pages. >> >> Hm, what does "proper GEM object" mean in the context of udl? > > One that appears the same as a GEM object created by userspace. i.e. mmap > works. Oh, we have an mmap interface in the dma_buf thing for that, and iirc Rob Clark even bothered to implement the gem->dma_buf mmap forwarding somewhere. And iirc android's ion-on-dma_buf stuff is even using the mmap interface stuff. Now for prime "let's just ship this, dammit" prevailed for now. But I still think that hiding the backing storage a bit better (with the eventual goal of supporting eviction with Maarten's fence/ww_mutex madness) feels like a worthy long-term goal. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64201] OpenCL usage result segmentation fault on r600g with HD6850.
https://bugs.freedesktop.org/show_bug.cgi?id=64201 --- Comment #12 from Erdem U. Altinyurt --- (In reply to comment #11) > If you're experiencing GPU lockups w/ OpenCL, I'd recommend making sure that > you mesa includes: > http://cgit.freedesktop.org/mesa/mesa/commit/ > ?id=4539f8e20af286d1f521eb016c89c6d9af0b801c > > This fixed a lot of common CL-based lockups on my Radeon 6850. Nope, I am using mesa-trunk that includes this patch also, but it looks doesn't help much... -- 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
Re: [PATCH] drm/udl: avoid swiotlb for imported vmap buffers.
On Mon, May 6, 2013 at 4:44 PM, Daniel Vetter wrote: > On Mon, May 6, 2013 at 9:56 PM, Dave Airlie wrote: >> On Tue, May 7, 2013 at 1:59 AM, Daniel Vetter wrote: >>> On Mon, May 06, 2013 at 10:35:35AM +1000, Dave Airlie wrote: >> >> However if we don't set a dma mask on the usb device, the mapping >> ends up using swiotlb on machines that have it enabled, which >> is less than desireable. >> >> Signed-off-by: Dave Airlie > > Fyi for everyone else who was not on irc when Dave&I discussed this: > This really shouldn't be required and I think the real issue is that > udl creates a dma_buf attachement (which is needed for device dma > only), but only really wants to do cpu access through vmap/kmap. So > not attached the device should be good enough. Cc'ing a few more lists > for better fyi ;-) Though I've looked at this a bit more, and since I want to be able to expose shared objects as proper GEM objects from the import side I really need that list of pages. >>> >>> Hm, what does "proper GEM object" mean in the context of udl? >> >> One that appears the same as a GEM object created by userspace. i.e. mmap >> works. > > Oh, we have an mmap interface in the dma_buf thing for that, and iirc > Rob Clark even bothered to implement the gem->dma_buf mmap forwarding > somewhere. And iirc android's ion-on-dma_buf stuff is even using the > mmap interface stuff. fwiw, what I did was dma_buf -> gem mmap fwding, ie. implement mmap for the dmabuf object by fwd'ing it to my normal gem mmap code. Might be the opposite of what you are looking for here. Although I suppose the reverse could work to, I hadn't really thought about it yet. BR, -R > Now for prime "let's just ship this, dammit" prevailed for now. But I > still think that hiding the backing storage a bit better (with the > eventual goal of supporting eviction with Maarten's fence/ww_mutex > madness) feels like a worthy long-term goal. > > Cheers, Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/udl: avoid swiotlb for imported vmap buffers.
>>> One that appears the same as a GEM object created by userspace. i.e. mmap >>> works. >> >> Oh, we have an mmap interface in the dma_buf thing for that, and iirc >> Rob Clark even bothered to implement the gem->dma_buf mmap forwarding >> somewhere. And iirc android's ion-on-dma_buf stuff is even using the >> mmap interface stuff. > > fwiw, what I did was dma_buf -> gem mmap fwding, ie. implement mmap > for the dmabuf object by fwd'ing it to my normal gem mmap code. Might > be the opposite of what you are looking for here. Although I suppose > the reverse could work to, I hadn't really thought about it yet. > Yeah thats the opposite, I want to implement my GEM mmap ioctls using dma-buf mmaps :) Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/7] drm: Update drm_addmap and drm_mmap to use PAT WC instead of MTRRs
On Mon, May 6, 2013 at 5:22 PM, Andy Lutomirski wrote: > On Fri, May 3, 2013 at 4:00 PM, Andy Lutomirski wrote: >> Signed-off-by: Andy Lutomirski >> --- >> >> This needs careful review. I don't really know what this code does, nor >> do I have the hardware. (I don't understand AGP and the associated >> caching implications.) > > This patch is wrong (I didn't update the matching mtrr_del), and I'm > reworking this whole series. But I may need some help on this one: > why is the mtrr handle of a map (whatever a map is) exported to > userspace via the ADD_MAP and GET_MAP ioctls? What (if anything) is > userspace supposed to do with it? Do I need to return a valid MTRR > register number? Is there any userspace code at all that sets > _DRM_WRITE_COMBINING in DRM_IOCTL_ADD_MAP with appropriate alignment > and needs the MTRR, for which the drm driver doesn't already add the > MTRR? > > --Andy >From memory, even on pat system we need mtrr for VRAM is PCI BAR. We cover it with a write combine MTRR. The whole ioctl is use by some ddx or maybe even directly the XServer to do this mtrr mess in userspace. Sorry for the bad news, but that's what i remember on that front thought i would need to read all the code again. Cheers, Jerome ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 51787] performance regression with llvm shader compiler in ut2004
https://bugs.freedesktop.org/show_bug.cgi?id=51787 --- Comment #6 from almos --- Now I took a new look at the issue with GALLIUM_HUD=fps, and there is definitely a serious problem with cpufreq. I have a few scripts to switch cpufreq governor between performance and ondemand (Phenom II x4), and to switch between high and low gpu power profiles (HD6850). When ondemand is selected, it seriously limits performance, and causes noticeable variance in fps. Some examples: Psychonauts, main menu (Raz standing on top of the giant brain) ondemand/low 20 fps ondemand/high 40-50 fps performance/low 29 fps performance/high 104 fps SW:KoToR, the main character standing alone on Dantuine, looking at the Ebon Hawk ondemand/low 20-30 fps ondemand/high 20-30 fps performance/low 55-60 fps performance/high 68 fps The difference between ondemand and performance makes a huge difference in native games as well. Quake Wars, Team Fortress 2, and UT2004 are all borderline playable with ondemand, but run perfectly with performance. It's not just a drop in fps, but a very noticeable laggyness, that kills the games. -- 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
linux-next: manual merge of the drm-intel tree with Linus' tree
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/i915_reg.h between commit a65851af5938 ("drm/i915:
Make data/link N value power of two") from Linus' tree and commit
e3b95f1eb5b9 ("drm/i915: Apply OCD to data/link m/n register #defines")
from the drm-intel tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
Daniel, I assume all this stuff being added to the drm-intel tree is
going upstream very soon?
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/gpu/drm/i915/i915_reg.h
index 83f9c26,a470103..000
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@@ -2648,18 -2768,19 +2768,19 @@@
* which is after the LUTs, so we want the bytes for our color format.
* For our current usage, this is always 3, one byte for R, G and B.
*/
- #define _PIPEA_GMCH_DATA_M0x70050
- #define _PIPEB_GMCH_DATA_M0x71050
+ #define _PIPEA_DATA_M_G4X 0x70050
+ #define _PIPEB_DATA_M_G4X 0x71050
/* Transfer unit size for display port - 1, default is 0x3f (for TU size 64)
*/
-#define PIPE_GMCH_DATA_M_TU_SIZE_MASK (0x3f << 25)
-#define PIPE_GMCH_DATA_M_TU_SIZE_SHIFT 25
+#define TU_SIZE(x) (((x)-1) << 25) /* default size 64 */
+#define TU_SIZE_MASK (0x3f << 25)
+ #define TU_SIZE_SHIFT25
-#define PIPE_GMCH_DATA_M_MASK (0xff)
+#define DATA_LINK_M_N_MASK (0xff)
+#define DATA_LINK_N_MAX (0x80)
- #define _PIPEA_GMCH_DATA_N0x70054
- #define _PIPEB_GMCH_DATA_N0x71054
+ #define _PIPEA_DATA_N_G4X 0x70054
+ #define _PIPEB_DATA_N_G4X 0x71054
-#define PIPE_GMCH_DATA_N_MASK (0xff)
/*
* Computing Link M and N values for the Display Port link
@@@ -2672,16 -2793,18 +2793,16 @@@
* Attributes and VB-ID.
*/
- #define _PIPEA_DP_LINK_M 0x70060
- #define _PIPEB_DP_LINK_M 0x71060
+ #define _PIPEA_LINK_M_G4X 0x70060
+ #define _PIPEB_LINK_M_G4X 0x71060
-#define PIPEA_DP_LINK_M_MASK(0xff)
- #define _PIPEA_DP_LINK_N 0x70064
- #define _PIPEB_DP_LINK_N 0x71064
+ #define _PIPEA_LINK_N_G4X 0x70064
+ #define _PIPEB_LINK_N_G4X 0x71064
-#define PIPEA_DP_LINK_N_MASK(0xff)
- #define PIPE_GMCH_DATA_M(pipe) _PIPE(pipe, _PIPEA_GMCH_DATA_M,
_PIPEB_GMCH_DATA_M)
- #define PIPE_GMCH_DATA_N(pipe) _PIPE(pipe, _PIPEA_GMCH_DATA_N,
_PIPEB_GMCH_DATA_N)
- #define PIPE_DP_LINK_M(pipe) _PIPE(pipe, _PIPEA_DP_LINK_M, _PIPEB_DP_LINK_M)
- #define PIPE_DP_LINK_N(pipe) _PIPE(pipe, _PIPEA_DP_LINK_N, _PIPEB_DP_LINK_N)
+ #define PIPE_DATA_M_G4X(pipe) _PIPE(pipe, _PIPEA_DATA_M_G4X,
_PIPEB_DATA_M_G4X)
+ #define PIPE_DATA_N_G4X(pipe) _PIPE(pipe, _PIPEA_DATA_N_G4X,
_PIPEB_DATA_N_G4X)
+ #define PIPE_LINK_M_G4X(pipe) _PIPE(pipe, _PIPEA_LINK_M_G4X,
_PIPEB_LINK_M_G4X)
+ #define PIPE_LINK_N_G4X(pipe) _PIPE(pipe, _PIPEA_LINK_N_G4X,
_PIPEB_LINK_N_G4X)
/* Display & cursor control */
pgpDXJrNF_Fz2.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/7] drm: Update drm_addmap and drm_mmap to use PAT WC instead of MTRRs
>> >> From memory, even on pat system we need mtrr for VRAM is PCI BAR. We >> cover it with a write combine MTRR. The whole ioctl is use by some ddx >> or maybe even directly the XServer to do this mtrr mess in userspace. > > Egads! So we have a _DRM_WRITE_COMBINING flag, which will continue to > work fine, but almost nothing uses it. > > I'm amazed this stuff works in the current code, though. Apparently > the memory type (WC or UC) of a drm mapping is determined by the mtrr > the driver set, but if one part of the BAR is textures or the > framebuffer and another part is an outgoing command ring, won't one of > them end up with the wrong memory type? Nobody sane puts the command ring in VRAM. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] [TRIVIAL] Fix declaration of intel_gmbus_{is_forced_bit/is_port_falid} in i915 driver.
Ok, so let me resend a version with "static inline" . Best, JS On Saturday 04 May 2013 10:55:50 PaX Team wrote: > On 3 May 2013 at 15:03, Jani Nikula wrote: > > >> This fixes a compilation issue with clang. An initial version of this > > >> patch > > >> was developed by PaX Team . > > >> This is respin of this patch. > > >> > > >> Signed-off-by: Jan-Simon Möller > > >> CC: pagee...@freemail.hu > > >> CC: daniel.vet...@ffwll.ch > > >> CC: airl...@linux.ie > > >> CC: intel-...@lists.freedesktop.org > > >> CC: dri-devel@lists.freedesktop.org > > >> CC: linux-ker...@vger.kernel.org > > > > > > Picked up for -fixes, thanks for the patch. > > > > Please drop it. > > > > The patch removes the inline keyword, creating dozens of copies of the > > > functions, and consequently loads of warnings: > in my original patch they were both static inline, not sure where the > inline got lost... -- Dipl.-Ing. Jan-Simon Möller jansimon.moel...@gmx.de ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] [TRIVIAL] v2: Fix declaration of intel_gmbus_{is_forced_bit/is_port_falid} in i915 driver.
From: Jan-Simon Möller
20130509: v2: (re-)add inline upon request.
Description:
intel_gmbus_is_forced_bit is no extern as its body is right below.
Likewise for intel_gmbus_is_port_valid.
This fixes a compilation issue with clang. An initial version of this patch
was developed by PaX Team .
This is respin of this patch.
Signed-off-by: Jan-Simon Möller
CC: pagee...@freemail.hu
CC: daniel.vet...@ffwll.ch
CC: airl...@linux.ie
CC: intel-...@lists.freedesktop.org
CC: dri-devel@lists.freedesktop.org
CC: linux-ker...@vger.kernel.org
---
drivers/gpu/drm/i915/i915_drv.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3ac71db..b41c49d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1806,7 +1806,7 @@ void i915_teardown_sysfs(struct drm_device *dev_priv);
/* intel_i2c.c */
extern int intel_setup_gmbus(struct drm_device *dev);
extern void intel_teardown_gmbus(struct drm_device *dev);
-extern inline bool intel_gmbus_is_port_valid(unsigned port)
+static inline bool intel_gmbus_is_port_valid(unsigned port)
{
return (port >= GMBUS_PORT_SSC && port <= GMBUS_PORT_DPD);
}
@@ -1815,7 +1815,7 @@ extern struct i2c_adapter *intel_gmbus_get_adapter(
struct drm_i915_private *dev_priv, unsigned port);
extern void intel_gmbus_set_speed(struct i2c_adapter *adapter, int speed);
extern void intel_gmbus_force_bit(struct i2c_adapter *adapter, bool force_bit);
-extern inline bool intel_gmbus_is_forced_bit(struct i2c_adapter *adapter)
+static inline bool intel_gmbus_is_forced_bit(struct i2c_adapter *adapter)
{
return container_of(adapter, struct intel_gmbus, adapter)->force_bit;
}
--
1.8.1.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/7] drm: Update drm_addmap and drm_mmap to use PAT WC instead of MTRRs
On Fri, May 3, 2013 at 4:00 PM, Andy Lutomirski wrote: > Signed-off-by: Andy Lutomirski > --- > > This needs careful review. I don't really know what this code does, nor > do I have the hardware. (I don't understand AGP and the associated > caching implications.) This patch is wrong (I didn't update the matching mtrr_del), and I'm reworking this whole series. But I may need some help on this one: why is the mtrr handle of a map (whatever a map is) exported to userspace via the ADD_MAP and GET_MAP ioctls? What (if anything) is userspace supposed to do with it? Do I need to return a valid MTRR register number? Is there any userspace code at all that sets _DRM_WRITE_COMBINING in DRM_IOCTL_ADD_MAP with appropriate alignment and needs the MTRR, for which the drm driver doesn't already add the MTRR? --Andy ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] radeon: Allow disabling UVD
Apparently UVD doesn't yet work everywhere - so allow it to be
disabled. Shaves off some reboot and suspend/resume time on machines
where it doesn't work. Might be useful for problematic chips in the
future as well.
Patch attached as well as inline below.
Signed-off-by: Parag Warudkar
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 1442ce7..f131d8f 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -79,6 +79,7 @@
* Modules parameters.
*/
extern int radeon_no_wb;
+extern int radeon_no_uvd;
extern int radeon_modeset;
extern int radeon_dynclks;
extern int radeon_r4xx_atom;
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
b/drivers/gpu/drm/radeon/radeon_drv.c
index d33f484..7e5b171 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -147,6 +147,7 @@ static inline void radeon_unregister_atpx_handler(void) {}
#endif
int radeon_no_wb;
+int radeon_no_uvd;
int radeon_modeset = 1;
int radeon_dynclks = -1;
int radeon_r4xx_atom = 0;
@@ -168,6 +169,9 @@ int radeon_fastfb = 0;
MODULE_PARM_DESC(no_wb, "Disable AGP writeback for scratch registers");
module_param_named(no_wb, radeon_no_wb, int, 0444);
+MODULE_PARM_DESC(no_uvd, "Disable UVD");
+module_param_named(no_uvd, radeon_no_uvd, int, 0444);
+
MODULE_PARM_DESC(modeset, "Disable/Enable modesetting");
module_param_named(modeset, radeon_modeset, int, 0400);
diff --git a/drivers/gpu/drm/radeon/radeon_drv.h
b/drivers/gpu/drm/radeon/radeon_drv.h
index b369d42..4320973 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.h
+++ b/drivers/gpu/drm/radeon/radeon_drv.h
@@ -329,6 +329,7 @@ typedef struct drm_radeon_kcmd_buffer {
} drm_radeon_kcmd_buffer_t;
extern int radeon_no_wb;
+extern int radeon_no_uvd;
extern struct drm_ioctl_desc radeon_ioctls[];
extern int radeon_max_ioctl;
diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c
b/drivers/gpu/drm/radeon/radeon_uvd.c
index 906e5c0..93a7dbb 100644
--- a/drivers/gpu/drm/radeon/radeon_uvd.c
+++ b/drivers/gpu/drm/radeon/radeon_uvd.c
@@ -58,7 +58,8 @@ int radeon_uvd_init(struct radeon_device *rdev)
unsigned long bo_size;
const char *fw_name;
int i, r;
-
+ if (radeon_no_uvd)
+ return -EINVAL;
INIT_DELAYED_WORK(&rdev->uvd.idle_work, radeon_uvd_idle_work_handler);
pdev = platform_device_register_simple("radeon_uvd", 0, NULL, 0);
radeon-option-no-uvd.patch
Description: Binary data
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/7] drm: Update drm_addmap and drm_mmap to use PAT WC instead of MTRRs
On Mon, May 6, 2013 at 4:04 PM, Jerome Glisse wrote: > On Mon, May 6, 2013 at 5:22 PM, Andy Lutomirski wrote: >> On Fri, May 3, 2013 at 4:00 PM, Andy Lutomirski wrote: >>> Signed-off-by: Andy Lutomirski >>> --- >>> >>> This needs careful review. I don't really know what this code does, nor >>> do I have the hardware. (I don't understand AGP and the associated >>> caching implications.) >> >> This patch is wrong (I didn't update the matching mtrr_del), and I'm >> reworking this whole series. But I may need some help on this one: >> why is the mtrr handle of a map (whatever a map is) exported to >> userspace via the ADD_MAP and GET_MAP ioctls? What (if anything) is >> userspace supposed to do with it? Do I need to return a valid MTRR >> register number? Is there any userspace code at all that sets >> _DRM_WRITE_COMBINING in DRM_IOCTL_ADD_MAP with appropriate alignment >> and needs the MTRR, for which the drm driver doesn't already add the >> MTRR? >> >> --Andy > > From memory, even on pat system we need mtrr for VRAM is PCI BAR. We > cover it with a write combine MTRR. The whole ioctl is use by some ddx > or maybe even directly the XServer to do this mtrr mess in userspace. Egads! So we have a _DRM_WRITE_COMBINING flag, which will continue to work fine, but almost nothing uses it. I'm amazed this stuff works in the current code, though. Apparently the memory type (WC or UC) of a drm mapping is determined by the mtrr the driver set, but if one part of the BAR is textures or the framebuffer and another part is an outgoing command ring, won't one of them end up with the wrong memory type? I'd really hate to have to track fake mtrrs in the drm core to emulate real mtrrs. > > Sorry for the bad news, but that's what i remember on that front > thought i would need to read all the code again. On the bright side, in the entire 2005 monolithic xorg tarball, the only thing that looks at the mtrr exported to userspace appears to be dritests. --Andy ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
nouveau GF108 kernel crash in optimus mode when enabling external display output
Hello, Lenovo T430 laptop with intel+nvidia hybrid graphics, optimus enabled in BIOS: $ lspci | grep VGA 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) 01:00.0 VGA compatible controller: NVIDIA Corporation GF108 [Quadro NVS 5400M] (rev a1) $ uname -a Linux localhost.localdomain 3.8.11-200.fc18.x86_64 #1 SMP Wed May 1 19:44:27 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux I boot up the system with only laptop internal LVDS active on intel gpu, and when in X session, I enable the second display on nouveau gpu connected to the dock DP2/DVI connector. At this point the kernel crashes immediately. Screenshots of the kernel crash/stacktrace here: http://pasik.reaktio.net/nouveau/debug/nouveau-kernel-crash01.jpg http://pasik.reaktio.net/nouveau/debug/nouveau-kernel-crash02.jpg hand-written bits from the kernel crash: Pid: 1208, comm: Xorg Not tainted 3.8.11-200.fc18.x86_64 #1 LENOVO 2349H2G/2349H2G RIP: 0010:[] [] nvc0_vm_map_sg+0x8e/0x110 [nouveau] RSP: 0018:8803298357c8 EFLAGS: 00010206 .. Process Xorg (pid: 1208,..) .. Call Trace: .. nouveau_vm_map_sg+0xc2/0x130 [nouveau] .. nouveau_vma_getmap.isra.11+0x68/0xa0 [nouveau] .. nouveau_bo_move_m2mf.isra.12+0x85/0x140 [nouveau] .. ? nouveau_vm_map_at+0x153/0x1c0 [nouveau] .. nouveau_bo_move+0xa5/0x400 [nouveau] .. ttm_bo_handle_move_mem+0x245/0x610 [ttm] More info from the screenshots above.. dmesg drm bits before the crash: [0.137586] vgaarb: device added: PCI::00:02.0,decodes=io+mem,owns=io+mem,locks=none [0.137590] vgaarb: device added: PCI::01:00.0,decodes=io+mem,owns=none,locks=none [0.137591] vgaarb: loaded [0.137591] vgaarb: bridge control possible :01:00.0 [0.137592] vgaarb: no bridge control possible :00:02.0 [0.529802] fb0: VESA VGA frame buffer device [0.877212] ata1.00: supports DRM functions and may not be fully accessible [0.878010] ata1.00: supports DRM functions and may not be fully accessible [1.969486] [drm] Initialized drm 1.1.0 20060810 [1.990584] VGA switcheroo: detected Optimus DSM method \_SB_.PCI0.PEG_.VID_ handle [1.990610] nouveau :01:00.0: enabling device (0004 -> 0007) [1.990874] nouveau [ DEVICE][:01:00.0] BOOT0 : 0x0c1780a1 [1.990877] nouveau [ DEVICE][:01:00.0] Chipset: GF108 (NVC1) [1.990878] nouveau [ DEVICE][:01:00.0] Family : NVC0 [1.992485] nouveau [ VBIOS][:01:00.0] checking PRAMIN for image... [2.002182] nouveau [ VBIOS][:01:00.0] ... signature not found [2.002184] nouveau [ VBIOS][:01:00.0] checking PROM for image... [2.002243] nouveau [ VBIOS][:01:00.0] ... signature not found [2.002245] nouveau [ VBIOS][:01:00.0] checking ACPI for image... [2.189928] nouveau [ VBIOS][:01:00.0] ... appears to be valid [2.189935] nouveau [ VBIOS][:01:00.0] using image from ACPI [2.190143] nouveau [ VBIOS][:01:00.0] BIT signature found [2.190149] nouveau [ VBIOS][:01:00.0] version 70.08.b7.02.02 [2.190467] nouveau [ DEVINIT][:01:00.0] adaptor not initialised [2.190470] nouveau [ VBIOS][:01:00.0] running init tables [2.278184] nouveau [ PFB][:01:00.0] RAM type: DDR3 [2.278189] nouveau [ PFB][:01:00.0] RAM size: 512 MiB [2.278192] nouveau [ PFB][:01:00.0]ZCOMP: 0 tags [2.311802] nouveau [ DRM] VRAM: 512 MiB [2.311805] nouveau [ DRM] GART: 512 MiB [2.311810] nouveau [ DRM] BIT BIOS found [2.311814] nouveau [ DRM] Bios version 70.08.b7.02 [2.311831] nouveau [ DRM] TMDS table version 2.0 [2.311832] nouveau [ DRM] DCB version 4.0 [2.311833] nouveau [ DRM] DCB outp 00: 01800323 00010034 [2.311834] nouveau [ DRM] DCB outp 01: 02811300 [2.311835] nouveau [ DRM] DCB outp 02: 028223a6 0f220010 [2.311836] nouveau [ DRM] DCB outp 03: 02822362 00020010 [2.311837] nouveau [ DRM] DCB outp 04: 048333b6 0f220010 [2.311838] nouveau [ DRM] DCB outp 05: 04833372 00020010 [2.311839] nouveau [ DRM] DCB outp 06: 088443c6 0f220010 [2.311840] nouveau [ DRM] DCB outp 07: 08844382 00020010 [2.311841] nouveau [ DRM] DCB conn 00: 0040 [2.311842] nouveau [ DRM] DCB conn 01: 0100 [2.311843] nouveau [ DRM] DCB conn 02: 00110246 [2.311844] nouveau [ DRM] DCB conn 03: 00220346 [2.311845] nouveau [ DRM] DCB conn 04: 01400446 [2.312502] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [2.312503] [drm] No driver support for vblank timestamp query. [2.312575] nouveau [ DRM] ACPI backlight interface available, not registering our own [2.312612] nouveau W[ DRM] voltage table 0x50 unknown [2.312769] nouveau [ DRM] 2 available performance level(s) [2.312771] nouveau [ DRM] 1: core 270MHz shader 540MHz memory 405MHz [
[PATCH] drm/udl: avoid swiotlb for imported vmap buffers.
>> >> However if we don't set a dma mask on the usb device, the mapping >> ends up using swiotlb on machines that have it enabled, which >> is less than desireable. >> >> Signed-off-by: Dave Airlie > > Fyi for everyone else who was not on irc when Dave&I discussed this: > This really shouldn't be required and I think the real issue is that > udl creates a dma_buf attachement (which is needed for device dma > only), but only really wants to do cpu access through vmap/kmap. So > not attached the device should be good enough. Cc'ing a few more lists > for better fyi ;-) Though I've looked at this a bit more, and since I want to be able to expose shared objects as proper GEM objects from the import side I really need that list of pages. So it looks like this won't really fly. Dave.
[Bug 64257] New: RS880 issues with r600-llvm-compiler
https://bugs.freedesktop.org/show_bug.cgi?id=64257 Priority: medium Bug ID: 64257 Assignee: dri-devel at lists.freedesktop.org Summary: RS880 issues with r600-llvm-compiler Severity: normal Classification: Unclassified OS: All Reporter: mike at fireburn.co.uk Hardware: Other Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa Hi Kwin starts with a black screen if I use r600-llvm-compiler on my RS880 When I switched off the llvm parts and just ran glxgears using r600-llvm-compiler the gears looked like they were layered wrongly and slightly darker I'm not sure when this regression appeared - I'm guessing within the last two weeks - I mostly ssh into the box I'm always running the latest llvm, clang, libdrm and mesa I didn't see anything strange in my dmesg or .xsession-errors or from the glxgears text output Could this be due to RS880 being singled out in llvm as a separate processor variant? ie r600g/llvm: Update radeon family mappings for LLVM backend or [PATCH 1/2] R600: Add some new processor variants -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130506/800425b6/attachment.html>
[Bug 64257] RS880 issues with r600-llvm-compiler
https://bugs.freedesktop.org/show_bug.cgi?id=64257 --- Comment #1 from Alex Deucher --- Any chance you could bisect? It might be a duplicate of bug 64193. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130506/8d7dacf3/attachment.html>
[Bug 64257] RS880 issues with r600-llvm-compiler
https://bugs.freedesktop.org/show_bug.cgi?id=64257 Mike Lothian changed: What|Removed |Added CC||mike at fireburn.co.uk --- Comment #2 from Mike Lothian --- Is it mesa or llvm that needs bisecting or both? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130506/b4f17172/attachment.html>
DMA mapping API abuse in exynos-drm
ore the attribute and exhibit default behavior. In case of ARM SoC, it seems like that it just ignores the attribute without iommu: in case of no iommu, dma_alloc_attr() always maps pages allocated from highmem with kernel space. So I think we make sure that exynos drm driver sets the attribute only with iommu to avoid such confusing. For this, will post it soon. Thanks, Inki Dae Best regards, > Tomasz > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130506/9f3fa9e5/attachment-0001.html>
[Bug 63732] [KDE] - display switching problem with kwin_gles and radeon driver.
https://bugs.freedesktop.org/show_bug.cgi?id=63732 --- Comment #6 from Honza Tvrznik --- Hello, upgrade mesa library/ati-dri to version 9.1.2 solve this problem. Request can be closed. Thanks! -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130506/9b169ca1/attachment.html>
[Bug 64257] RS880 issues with r600-llvm-compiler
https://bugs.freedesktop.org/show_bug.cgi?id=64257 --- Comment #3 from Michel D?nzer --- Could be either, but you generally need matching Git snapshots anyway. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130506/930493f6/attachment.html>
[Bug 63732] [KDE] - display switching problem with kwin_gles and radeon driver.
https://bugs.freedesktop.org/show_bug.cgi?id=63732 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130506/16689792/attachment.html>
[PATCHv5 0/2] Speed Cap fixes for ppc64
On Fri, May 3, 2013 at 7:01 PM, Benjamin Herrenschmidt wrote: > On Fri, 2013-05-03 at 19:43 -0300, Kleber Sacilotto de Souza wrote: > >> This patch series does: >> 1. max_bus_speed is used to set the device to gen2 speeds >> 2. on power there's no longer a conflict between the pseries call and other >> architectures, because the overwrite is done via a ppc_md hook >> 3. radeon is using bus->max_bus_speed instead of >> drm_pcie_get_speed_cap_mask >> for gen2 capability detection >> >> The first patch consists of some architecture changes, such as adding a hook >> on >> powerpc for pci_root_bridge_prepare, so that pseries will initialize it to a >> function, while all other architectures get a NULL pointer. So that whenever >> pci_create_root_bus is called, we'll get max_bus_speed properly setup from >> OpenFirmware. >> >> The second patch consists of simple radeon changes not to call >> drm_get_pcie_speed_cap_mask anymore. I assume that on x86 machines, >> the max_bus_speed property will be properly set already. > > So I'm ok with the approach now and I might even put the powerpc patch > in for 3.10 since arguably we are fixing a nasty bug (uninitialized > max_bus_speed). > > David, what's your feeling about the radeon change ? It would be nice if > that could go in soon for various distro targets :-) On the other hand > I'm not going to be pushy if you are not comfortable with it. FWIW, the radeon change looks fine to me. Alex
[PATCHv5 0/2] Speed Cap fixes for ppc64
n Mon, May 6, 2013 at 10:32 AM, Alex Deucher wrote: > On Fri, May 3, 2013 at 7:01 PM, Benjamin Herrenschmidt > wrote: >> On Fri, 2013-05-03 at 19:43 -0300, Kleber Sacilotto de Souza wrote: >> >>> This patch series does: >>> 1. max_bus_speed is used to set the device to gen2 speeds >>> 2. on power there's no longer a conflict between the pseries call and >>> other >>> architectures, because the overwrite is done via a ppc_md hook >>> 3. radeon is using bus->max_bus_speed instead of >>> drm_pcie_get_speed_cap_mask >>> for gen2 capability detection >>> >>> The first patch consists of some architecture changes, such as adding a >>> hook on >>> powerpc for pci_root_bridge_prepare, so that pseries will initialize it to a >>> function, while all other architectures get a NULL pointer. So that whenever >>> pci_create_root_bus is called, we'll get max_bus_speed properly setup from >>> OpenFirmware. >>> >>> The second patch consists of simple radeon changes not to call >>> drm_get_pcie_speed_cap_mask anymore. I assume that on x86 machines, >>> the max_bus_speed property will be properly set already. >> >> So I'm ok with the approach now and I might even put the powerpc patch >> in for 3.10 since arguably we are fixing a nasty bug (uninitialized >> max_bus_speed). >> >> David, what's your feeling about the radeon change ? It would be nice if >> that could go in soon for various distro targets :-) On the other hand >> I'm not going to be pushy if you are not comfortable with it. > > FWIW, the radeon change looks fine to me. > > Alex As said previously, looks fine to me too. Cheers, Jerome
[Bug 60848] [bisected] r600g: add htile support cause gpu lockup in Dishonored wine.
https://bugs.freedesktop.org/show_bug.cgi?id=60848 Jerome Glisse changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Jerome Glisse --- Closing pushed to master and going to push to 9.1 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130506/02e85038/attachment.html>
[Bug 59592] Radeon HD 5670: reproducable GPU lockups with htile enabled
https://bugs.freedesktop.org/show_bug.cgi?id=59592 Jerome Glisse changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Jerome Glisse --- Closing pushed to master and going to push to 9.1 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130506/ea1b1307/attachment-0001.html>
[Bug 62466] r600g hyperz lockups with KSP 0.19
https://bugs.freedesktop.org/show_bug.cgi?id=62466 Jerome Glisse changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Jerome Glisse --- Closing pushed to master and going to push to 9.1 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130506/d97b2b9e/attachment.html>
[Bug 62669] HyperZ freeze when playing PrBoom-Plus demo with lots of monsters
https://bugs.freedesktop.org/show_bug.cgi?id=62669 Jerome Glisse changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Jerome Glisse --- Closing pushed to master and going to push to 9.1 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130506/df2e4845/attachment.html>
[PATCH] [TRIVIAL] v2: Fix declaration of intel_gmbus_{is_forced_bit/is_port_falid} in i915 driver.
On Mon, May 06, 2013 at 02:52:08PM +0200, dl9pf at gmx.de wrote: > From: Jan-Simon M?ller > > 20130509: v2: (re-)add inline upon request. > > Description: > intel_gmbus_is_forced_bit is no extern as its body is right below. > Likewise for intel_gmbus_is_port_valid. > > This fixes a compilation issue with clang. An initial version of this patch > was developed by PaX Team . > This is respin of this patch. > > Signed-off-by: Jan-Simon M?ller > CC: pageexec at freemail.hu > CC: daniel.vetter at ffwll.ch > CC: airlied at linux.ie > CC: intel-gfx at lists.freedesktop.org > CC: dri-devel at lists.freedesktop.org > CC: linux-kernel at vger.kernel.org Queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 64257] RS880 issues with r600-llvm-compiler
https://bugs.freedesktop.org/show_bug.cgi?id=64257 --- Comment #4 from Tom Stellard --- I just pushed the Mesa patch that updates the GPU mappings to account for the new processors in LLVM. Can you re-test with the latest code from the git repository? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130506/017db789/attachment.html>
[PATCH] drm/udl: avoid swiotlb for imported vmap buffers.
On Mon, May 06, 2013 at 10:35:35AM +1000, Dave Airlie wrote: > >> > >> However if we don't set a dma mask on the usb device, the mapping > >> ends up using swiotlb on machines that have it enabled, which > >> is less than desireable. > >> > >> Signed-off-by: Dave Airlie > > > > Fyi for everyone else who was not on irc when Dave&I discussed this: > > This really shouldn't be required and I think the real issue is that > > udl creates a dma_buf attachement (which is needed for device dma > > only), but only really wants to do cpu access through vmap/kmap. So > > not attached the device should be good enough. Cc'ing a few more lists > > for better fyi ;-) > > Though I've looked at this a bit more, and since I want to be able to expose > shared objects as proper GEM objects from the import side I really > need that list of pages. Hm, what does "proper GEM object" mean in the context of udl? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 62466] r600g hyperz lockups with KSP 0.19
https://bugs.freedesktop.org/show_bug.cgi?id=62466 --- Comment #9 from lct at mail.ru --- Hi, Gerome! Do I understand correctly, this patch is only for R600g AND its only for kernel (not mesa or DDI) ? Thanks for the fix! Unfortunately I have currently no access to the machine. When I have it, I will test the case on the sourcecode of kernel that I had - vanilla & crashing(1), as well as with your patch(2), and then if that happens in more actual kernel 3.8. (ubuntu raring)(3) and finally the kernel current with patch (4) I will test both performance with PTS Urban Terror profile, as well as stability exactly in the case I had and report back the results. That said I am pretty sure it works out, as others already confirm that, but still - I would like you to send me your paypal account data - for beers (green tea, coffee etc) money.. I know that you are employed by RedHat, its only a personal way to thank you for patching. Thank you! -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130506/a9be7dff/attachment.html>
[Bug 64201] OpenCL usage result segmentation fault on r600g with HD6850.
https://bugs.freedesktop.org/show_bug.cgi?id=64201 --- Comment #11 from Aaron Watry --- If you're experiencing GPU lockups w/ OpenCL, I'd recommend making sure that you mesa includes: http://cgit.freedesktop.org/mesa/mesa/commit/?id=4539f8e20af286d1f521eb016c89c6d9af0b801c This fixed a lot of common CL-based lockups on my Radeon 6850. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130506/dcc6b347/attachment.html>
[PATCH] drm/udl: avoid swiotlb for imported vmap buffers.
On Mon, May 6, 2013 at 9:56 PM, Dave Airlie wrote: > On Tue, May 7, 2013 at 1:59 AM, Daniel Vetter wrote: >> On Mon, May 06, 2013 at 10:35:35AM +1000, Dave Airlie wrote: >>> >> >>> >> However if we don't set a dma mask on the usb device, the mapping >>> >> ends up using swiotlb on machines that have it enabled, which >>> >> is less than desireable. >>> >> >>> >> Signed-off-by: Dave Airlie >>> > >>> > Fyi for everyone else who was not on irc when Dave&I discussed this: >>> > This really shouldn't be required and I think the real issue is that >>> > udl creates a dma_buf attachement (which is needed for device dma >>> > only), but only really wants to do cpu access through vmap/kmap. So >>> > not attached the device should be good enough. Cc'ing a few more lists >>> > for better fyi ;-) >>> >>> Though I've looked at this a bit more, and since I want to be able to expose >>> shared objects as proper GEM objects from the import side I really >>> need that list of pages. >> >> Hm, what does "proper GEM object" mean in the context of udl? > > One that appears the same as a GEM object created by userspace. i.e. mmap > works. Oh, we have an mmap interface in the dma_buf thing for that, and iirc Rob Clark even bothered to implement the gem->dma_buf mmap forwarding somewhere. And iirc android's ion-on-dma_buf stuff is even using the mmap interface stuff. Now for prime "let's just ship this, dammit" prevailed for now. But I still think that hiding the backing storage a bit better (with the eventual goal of supporting eviction with Maarten's fence/ww_mutex madness) feels like a worthy long-term goal. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 64201] OpenCL usage result segmentation fault on r600g with HD6850.
https://bugs.freedesktop.org/show_bug.cgi?id=64201 --- Comment #12 from Erdem U. Altinyurt --- (In reply to comment #11) > If you're experiencing GPU lockups w/ OpenCL, I'd recommend making sure that > you mesa includes: > http://cgit.freedesktop.org/mesa/mesa/commit/ > ?id=4539f8e20af286d1f521eb016c89c6d9af0b801c > > This fixed a lot of common CL-based lockups on my Radeon 6850. Nope, I am using mesa-trunk that includes this patch also, but it looks doesn't help much... -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130506/e823b185/attachment.html>
[PATCH] drm/udl: avoid swiotlb for imported vmap buffers.
On Mon, May 6, 2013 at 4:44 PM, Daniel Vetter wrote: > On Mon, May 6, 2013 at 9:56 PM, Dave Airlie wrote: >> On Tue, May 7, 2013 at 1:59 AM, Daniel Vetter wrote: >>> On Mon, May 06, 2013 at 10:35:35AM +1000, Dave Airlie wrote: >> >> However if we don't set a dma mask on the usb device, the mapping >> ends up using swiotlb on machines that have it enabled, which >> is less than desireable. >> >> Signed-off-by: Dave Airlie > > Fyi for everyone else who was not on irc when Dave&I discussed this: > This really shouldn't be required and I think the real issue is that > udl creates a dma_buf attachement (which is needed for device dma > only), but only really wants to do cpu access through vmap/kmap. So > not attached the device should be good enough. Cc'ing a few more lists > for better fyi ;-) Though I've looked at this a bit more, and since I want to be able to expose shared objects as proper GEM objects from the import side I really need that list of pages. >>> >>> Hm, what does "proper GEM object" mean in the context of udl? >> >> One that appears the same as a GEM object created by userspace. i.e. mmap >> works. > > Oh, we have an mmap interface in the dma_buf thing for that, and iirc > Rob Clark even bothered to implement the gem->dma_buf mmap forwarding > somewhere. And iirc android's ion-on-dma_buf stuff is even using the > mmap interface stuff. fwiw, what I did was dma_buf -> gem mmap fwding, ie. implement mmap for the dmabuf object by fwd'ing it to my normal gem mmap code. Might be the opposite of what you are looking for here. Although I suppose the reverse could work to, I hadn't really thought about it yet. BR, -R > Now for prime "let's just ship this, dammit" prevailed for now. But I > still think that hiding the backing storage a bit better (with the > eventual goal of supporting eviction with Maarten's fence/ww_mutex > madness) feels like a worthy long-term goal. > > Cheers, Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/7] drm: Update drm_addmap and drm_mmap to use PAT WC instead of MTRRs
On Mon, May 6, 2013 at 5:22 PM, Andy Lutomirski wrote: > On Fri, May 3, 2013 at 4:00 PM, Andy Lutomirski > wrote: >> Signed-off-by: Andy Lutomirski >> --- >> >> This needs careful review. I don't really know what this code does, nor >> do I have the hardware. (I don't understand AGP and the associated >> caching implications.) > > This patch is wrong (I didn't update the matching mtrr_del), and I'm > reworking this whole series. But I may need some help on this one: > why is the mtrr handle of a map (whatever a map is) exported to > userspace via the ADD_MAP and GET_MAP ioctls? What (if anything) is > userspace supposed to do with it? Do I need to return a valid MTRR > register number? Is there any userspace code at all that sets > _DRM_WRITE_COMBINING in DRM_IOCTL_ADD_MAP with appropriate alignment > and needs the MTRR, for which the drm driver doesn't already add the > MTRR? > > --Andy >From memory, even on pat system we need mtrr for VRAM is PCI BAR. We cover it with a write combine MTRR. The whole ioctl is use by some ddx or maybe even directly the XServer to do this mtrr mess in userspace. Sorry for the bad news, but that's what i remember on that front thought i would need to read all the code again. Cheers, Jerome
[Bug 51787] performance regression with llvm shader compiler in ut2004
https://bugs.freedesktop.org/show_bug.cgi?id=51787 --- Comment #6 from almos --- Now I took a new look at the issue with GALLIUM_HUD=fps, and there is definitely a serious problem with cpufreq. I have a few scripts to switch cpufreq governor between performance and ondemand (Phenom II x4), and to switch between high and low gpu power profiles (HD6850). When ondemand is selected, it seriously limits performance, and causes noticeable variance in fps. Some examples: Psychonauts, main menu (Raz standing on top of the giant brain) ondemand/low 20 fps ondemand/high 40-50 fps performance/low 29 fps performance/high 104 fps SW:KoToR, the main character standing alone on Dantuine, looking at the Ebon Hawk ondemand/low 20-30 fps ondemand/high 20-30 fps performance/low 55-60 fps performance/high 68 fps The difference between ondemand and performance makes a huge difference in native games as well. Quake Wars, Team Fortress 2, and UT2004 are all borderline playable with ondemand, but run perfectly with performance. It's not just a drop in fps, but a very noticeable laggyness, that kills the games. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130506/d60592d5/attachment.html>
[PATCH 3/7] drm: Update drm_addmap and drm_mmap to use PAT WC instead of MTRRs
On Fri, May 3, 2013 at 4:00 PM, Andy Lutomirski wrote: > Signed-off-by: Andy Lutomirski > --- > > This needs careful review. I don't really know what this code does, nor > do I have the hardware. (I don't understand AGP and the associated > caching implications.) This patch is wrong (I didn't update the matching mtrr_del), and I'm reworking this whole series. But I may need some help on this one: why is the mtrr handle of a map (whatever a map is) exported to userspace via the ADD_MAP and GET_MAP ioctls? What (if anything) is userspace supposed to do with it? Do I need to return a valid MTRR register number? Is there any userspace code at all that sets _DRM_WRITE_COMBINING in DRM_IOCTL_ADD_MAP with appropriate alignment and needs the MTRR, for which the drm driver doesn't already add the MTRR? --Andy
[PATCH] radeon: Allow disabling UVD
Apparently UVD doesn't yet work everywhere - so allow it to be
disabled. Shaves off some reboot and suspend/resume time on machines
where it doesn't work. Might be useful for problematic chips in the
future as well.
Patch attached as well as inline below.
Signed-off-by: Parag Warudkar
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 1442ce7..f131d8f 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -79,6 +79,7 @@
* Modules parameters.
*/
extern int radeon_no_wb;
+extern int radeon_no_uvd;
extern int radeon_modeset;
extern int radeon_dynclks;
extern int radeon_r4xx_atom;
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
b/drivers/gpu/drm/radeon/radeon_drv.c
index d33f484..7e5b171 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -147,6 +147,7 @@ static inline void radeon_unregister_atpx_handler(void) {}
#endif
int radeon_no_wb;
+int radeon_no_uvd;
int radeon_modeset = 1;
int radeon_dynclks = -1;
int radeon_r4xx_atom = 0;
@@ -168,6 +169,9 @@ int radeon_fastfb = 0;
MODULE_PARM_DESC(no_wb, "Disable AGP writeback for scratch registers");
module_param_named(no_wb, radeon_no_wb, int, 0444);
+MODULE_PARM_DESC(no_uvd, "Disable UVD");
+module_param_named(no_uvd, radeon_no_uvd, int, 0444);
+
MODULE_PARM_DESC(modeset, "Disable/Enable modesetting");
module_param_named(modeset, radeon_modeset, int, 0400);
diff --git a/drivers/gpu/drm/radeon/radeon_drv.h
b/drivers/gpu/drm/radeon/radeon_drv.h
index b369d42..4320973 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.h
+++ b/drivers/gpu/drm/radeon/radeon_drv.h
@@ -329,6 +329,7 @@ typedef struct drm_radeon_kcmd_buffer {
} drm_radeon_kcmd_buffer_t;
extern int radeon_no_wb;
+extern int radeon_no_uvd;
extern struct drm_ioctl_desc radeon_ioctls[];
extern int radeon_max_ioctl;
diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c
b/drivers/gpu/drm/radeon/radeon_uvd.c
index 906e5c0..93a7dbb 100644
--- a/drivers/gpu/drm/radeon/radeon_uvd.c
+++ b/drivers/gpu/drm/radeon/radeon_uvd.c
@@ -58,7 +58,8 @@ int radeon_uvd_init(struct radeon_device *rdev)
unsigned long bo_size;
const char *fw_name;
int i, r;
-
+ if (radeon_no_uvd)
+ return -EINVAL;
INIT_DELAYED_WORK(&rdev->uvd.idle_work, radeon_uvd_idle_work_handler);
pdev = platform_device_register_simple("radeon_uvd", 0, NULL, 0);
-- next part --
A non-text attachment was scrubbed...
Name: radeon-option-no-uvd.patch
Type: application/octet-stream
Size: 2154 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130506/41cada71/attachment-0001.obj>
[Intel-gfx] [PATCH] [TRIVIAL] Fix declaration of intel_gmbus_{is_forced_bit/is_port_falid} in i915 driver.
Ok, so let me resend a version with "static inline" . Best, JS On Saturday 04 May 2013 10:55:50 PaX Team wrote: > On 3 May 2013 at 15:03, Jani Nikula wrote: > > >> This fixes a compilation issue with clang. An initial version of this > > >> patch > > >> was developed by PaX Team . > > >> This is respin of this patch. > > >> > > >> Signed-off-by: Jan-Simon M?ller > > >> CC: pageexec at freemail.hu > > >> CC: daniel.vetter at ffwll.ch > > >> CC: airlied at linux.ie > > >> CC: intel-gfx at lists.freedesktop.org > > >> CC: dri-devel at lists.freedesktop.org > > >> CC: linux-kernel at vger.kernel.org > > > > > > Picked up for -fixes, thanks for the patch. > > > > Please drop it. > > > > The patch removes the inline keyword, creating dozens of copies of the > > > functions, and consequently loads of warnings: > in my original patch they were both static inline, not sure where the > inline got lost... -- Dipl.-Ing. Jan-Simon M?ller jansimon.moeller at gmx.de
[PATCH] [TRIVIAL] v2: Fix declaration of intel_gmbus_{is_forced_bit/is_port_falid} in i915 driver.
From: Jan-Simon M?ller
20130509: v2: (re-)add inline upon request.
Description:
intel_gmbus_is_forced_bit is no extern as its body is right below.
Likewise for intel_gmbus_is_port_valid.
This fixes a compilation issue with clang. An initial version of this patch
was developed by PaX Team .
This is respin of this patch.
Signed-off-by: Jan-Simon M?ller
CC: pageexec at freemail.hu
CC: daniel.vetter at ffwll.ch
CC: airlied at linux.ie
CC: intel-gfx at lists.freedesktop.org
CC: dri-devel at lists.freedesktop.org
CC: linux-kernel at vger.kernel.org
---
drivers/gpu/drm/i915/i915_drv.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3ac71db..b41c49d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1806,7 +1806,7 @@ void i915_teardown_sysfs(struct drm_device *dev_priv);
/* intel_i2c.c */
extern int intel_setup_gmbus(struct drm_device *dev);
extern void intel_teardown_gmbus(struct drm_device *dev);
-extern inline bool intel_gmbus_is_port_valid(unsigned port)
+static inline bool intel_gmbus_is_port_valid(unsigned port)
{
return (port >= GMBUS_PORT_SSC && port <= GMBUS_PORT_DPD);
}
@@ -1815,7 +1815,7 @@ extern struct i2c_adapter *intel_gmbus_get_adapter(
struct drm_i915_private *dev_priv, unsigned port);
extern void intel_gmbus_set_speed(struct i2c_adapter *adapter, int speed);
extern void intel_gmbus_force_bit(struct i2c_adapter *adapter, bool force_bit);
-extern inline bool intel_gmbus_is_forced_bit(struct i2c_adapter *adapter)
+static inline bool intel_gmbus_is_forced_bit(struct i2c_adapter *adapter)
{
return container_of(adapter, struct intel_gmbus, adapter)->force_bit;
}
--
1.8.1.4
[PATCH 3/7] drm: Update drm_addmap and drm_mmap to use PAT WC instead of MTRRs
On Mon, May 6, 2013 at 4:04 PM, Jerome Glisse wrote: > On Mon, May 6, 2013 at 5:22 PM, Andy Lutomirski > wrote: >> On Fri, May 3, 2013 at 4:00 PM, Andy Lutomirski >> wrote: >>> Signed-off-by: Andy Lutomirski >>> --- >>> >>> This needs careful review. I don't really know what this code does, nor >>> do I have the hardware. (I don't understand AGP and the associated >>> caching implications.) >> >> This patch is wrong (I didn't update the matching mtrr_del), and I'm >> reworking this whole series. But I may need some help on this one: >> why is the mtrr handle of a map (whatever a map is) exported to >> userspace via the ADD_MAP and GET_MAP ioctls? What (if anything) is >> userspace supposed to do with it? Do I need to return a valid MTRR >> register number? Is there any userspace code at all that sets >> _DRM_WRITE_COMBINING in DRM_IOCTL_ADD_MAP with appropriate alignment >> and needs the MTRR, for which the drm driver doesn't already add the >> MTRR? >> >> --Andy > > From memory, even on pat system we need mtrr for VRAM is PCI BAR. We > cover it with a write combine MTRR. The whole ioctl is use by some ddx > or maybe even directly the XServer to do this mtrr mess in userspace. Egads! So we have a _DRM_WRITE_COMBINING flag, which will continue to work fine, but almost nothing uses it. I'm amazed this stuff works in the current code, though. Apparently the memory type (WC or UC) of a drm mapping is determined by the mtrr the driver set, but if one part of the BAR is textures or the framebuffer and another part is an outgoing command ring, won't one of them end up with the wrong memory type? I'd really hate to have to track fake mtrrs in the drm core to emulate real mtrrs. > > Sorry for the bad news, but that's what i remember on that front > thought i would need to read all the code again. On the bright side, in the entire 2005 monolithic xorg tarball, the only thing that looks at the mtrr exported to userspace appears to be dritests. --Andy
[PATCH 3/4] drm/mgag200: Convert counter delays to jiffies
Signed-off-by: Christopher Harvey
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index 6f3b9db..6dbf6de 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -46,29 +46,26 @@ static void mga_crtc_load_lut(struct drm_crtc *crtc)
static inline void mga_wait_vsync(struct mga_device *mdev)
{
- unsigned int count = 0;
+ unsigned long timeout = jiffies + HZ/10;
unsigned int status = 0;
do {
status = RREG32(MGAREG_Status);
- count++;
- } while ((status & 0x08) && (count < 25));
- count = 0;
+ } while ((status & 0x08) && time_before(jiffies, timeout));
+ timeout = jiffies + HZ/10;
status = 0;
do {
status = RREG32(MGAREG_Status);
- count++;
- } while (!(status & 0x08) && (count < 25));
+ } while (!(status & 0x08) && time_before(jiffies, timeout));
}
static inline void mga_wait_busy(struct mga_device *mdev)
{
- unsigned int count = 0;
+ unsigned long timeout = jiffies + HZ;
unsigned int status = 0;
do {
status = RREG8(MGAREG_Status + 2);
- count++;
- } while ((status & 0x01) && (count < 50));
+ } while ((status & 0x01) && time_before(jiffies, timeout));
}
/*
--
1.8.1.5
[PATCH v2 3/4] drm/mgag200: Convert counter delays to jiffies
Signed-off-by: Christopher Harvey
Acked-by: Julia Lemire
Tested-by: Julia Lemire
Acked-by: Mathieu Larouche
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index 6f3b9db..6dbf6de 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -46,29 +46,26 @@ static void mga_crtc_load_lut(struct drm_crtc *crtc)
static inline void mga_wait_vsync(struct mga_device *mdev)
{
- unsigned int count = 0;
+ unsigned long timeout = jiffies + HZ/10;
unsigned int status = 0;
do {
status = RREG32(MGAREG_Status);
- count++;
- } while ((status & 0x08) && (count < 25));
- count = 0;
+ } while ((status & 0x08) && time_before(jiffies, timeout));
+ timeout = jiffies + HZ/10;
status = 0;
do {
status = RREG32(MGAREG_Status);
- count++;
- } while (!(status & 0x08) && (count < 25));
+ } while (!(status & 0x08) && time_before(jiffies, timeout));
}
static inline void mga_wait_busy(struct mga_device *mdev)
{
- unsigned int count = 0;
+ unsigned long timeout = jiffies + HZ;
unsigned int status = 0;
do {
status = RREG8(MGAREG_Status + 2);
- count++;
- } while ((status & 0x01) && (count < 50));
+ } while ((status & 0x01) && time_before(jiffies, timeout));
}
/*
--
1.8.1.5
