No subject

0x0314e050: 0x61010006: STATE_BASE_ADDRESS 0x0314e054: 0x0001:general state base address 0x 0x0314e058: 0x0001:surface state base address 0x 0x0314e05c: 0x0001:indirect state base address 0x 0x0314e060: 0x0001:

[no subject]

On Tue, May 22, 2012 at 04:06:41PM +0200, Lars-Peter Clausen wrote: > On 05/18/2012 02:27 PM, Sascha Hauer wrote: > > Hi All, > > > > The following adds a drm/kms driver for the Freescale i.MX LCDC > > controller. Most notable change to the last SDRM based version is that > > the SDRM layer has

No subject

i don't think kernel is the right place for it, for instance you need to set the primary surface thing, i don't want to parse cmd stream in kernel to figure that out. I would rather have userspace tool that postprocess thing and convert it to proper AMD dump format. Cheers, Jerome

[no subject]

On Tue, May 22, 2012 at 04:06:41PM +0200, Lars-Peter Clausen wrote: > On 05/18/2012 02:27 PM, Sascha Hauer wrote: > > Hi All, > > > > The following adds a drm/kms driver for the Freescale i.MX LCDC > > controller. Most notable change to the last SDRM based version is that > > the SDRM layer has

[no subject]

On 05/18/2012 02:27 PM, Sascha Hauer wrote: > Hi All, > > The following adds a drm/kms driver for the Freescale i.MX LCDC > controller. Most notable change to the last SDRM based version is that > the SDRM layer has been removed and the driver now is purely i.MX > specific. I hope that this is

[no subject]

Hi All, The following adds a drm/kms driver for the Freescale i.MX LCDC controller. Most notable change to the last SDRM based version is that the SDRM layer has been removed and the driver now is purely i.MX specific. I hope that this is more acceptable now. Another change is that the probe is

No subject

is still queued, which I don't completely like but at least the pinning and hw use of the userspace buffer is just temporary and not able to exist for an indefinite amount of time. BR, -R > Thanks, > Inki Dae > >> So I'm really not sure the best way to move this forward, maybe a very >> clear

No subject

> Those two checks could probably be combined into one (< values || > values) > for further simplification. Answer: Fixed. The new function was just copy-paste, but your suggestion is good. diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index d3aaeb6..6014413 100644 ---

No subject

> Please add that to the error message and use printk_once() since we only > really want to annoy the user the first time. For each time we see the message, we need to increase the value by 1, so instead of using printk_once, I just added this information to the message. Anyway, we shouldn't be

No subject

> > Perhaps we could add a debug message here for catch the unhandled types.. > This shouldn't happen. The previous checks should eliminate all objects that don't have properties. The only possibility I can think of is if we add properties to a new kind of object and forget to include it in the

No subject

> How about adding obj->properties.count to avoid having to count every > time? I just blindly followed the connector properties example. But your idea is good, so I implemented it. Fixed, but in a new patch near the end of the series. Putting the in the end of the series should make it easier to

No subject

> Subject: [PATCH 1/1] =A0=A0=A0 drivers/gpu/drm/i915: Fixed uninitialized

No subject

than escalating the bug into a random failure. -Chris -- Chris Wilson, Intel Open Source Technology Centre

No subject

No subject

No subject

No subject

There are many bugs open on fd.o regarding missing modes that are supported on Windows and other closed source drivers.

No subject

There are many bugs open on fd.o regarding missing modes that are supported on Windows and other closed source drivers.

[no subject]

Sep 17 00:00:00 2001 From: Rodrigo Vivi rodrigo.v...@intel.com Date: Wed, 11 Apr 2012 15:36:31 -0300 Subject: [PATCH] drm/edid: Adding common CVT inferred modes when monitor allows range limited ones trough EDID. Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com --- drivers/gpu/drm/drm_edid.c

[no subject]

Sep 17 00:00:00 2001 From: Rodrigo Vivi rodrigo.v...@intel.com Date: Wed, 11 Apr 2012 15:36:31 -0300 Subject: [PATCH] drm/edid: Adding common CVT inferred modes when monitor allows range limited ones trough EDID. Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com --- drivers/gpu/drm/drm_edid.c

No subject

Under some circumstances, pci_map_rom() can return a valid mapping but a size of 0 (if it cannot find an image in the header). This causes nouveau to try to kmalloc() a 0 sized pointer and dereference it, which crashes. Signed-off-by: Benjamin Herrenschmidt --- Please send to Linus asap,

No subject

when the corresponding pins are not actually hooked up to anything. In these cases, there is no NAK, nor timeout, nor any other indication from the GMBUS controller that a transaction fails. The first gmbus transaction timeout is caught by the "wait_for" timeout, causing the transition to

No subject

makes me afraid of some weird GTT flushing issue, given the adventures we had with VT-d on that hardware where we idle the gpu before any GTT updates. I wonder what would happen if we idled the GPU before any GTT updates even when VT-d wasn't running... > The latest thinking on the hibernate

No subject

-- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.

No subject

by the DMM so that we can do the PAT programming and that can only be gotten from the hwmod entry. And if you use the hwmod device entry, you have to match the name used for that entry. Regards, Andy

No subject

k in return path of radeon_fence_count_emitted" fixes=0Athe problem. Tested= on top of 47492a23a and 3.3.0-rc3+00188-g3ec1e88.=0A=0A=0AThanks,=0A=0AMik= ko

No subject

sl-to-tgsi. BTW in which commit was the new ioctl disabled? I mean, I can understand th= at if I don't have kernel with support for the new ioctl it breaks the test= s, however if the ioctl was disabled later shouldn't be current git working un= less another regression happened? > Anyway, sorry,

No subject

disable the output polling during suspend. The following patch seems to get rid of the problems I'm seeing. Does this look okay to you?

No subject

dangerball: intel_tris.c:128: intel_extend_inline: Assertion 'intel->prim.flush == intel_flush_inline_primitive' failed. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.

No subject

GPU lockup CP stall for more than 1msec Jan 23 23:53:54 thoregon kernel: [17121.080137] GPU lockup (waiting for 0x002080B7 last fence id 0x002080B6) Jan 23 23:53:54 thoregon kernel: [17121.096334] radeon :07:00.0: GPU softreset Jan 23 23:53:54 thoregon kernel: [17121.096341] radeon

No subject

/usr/sbin/run-crons && /usr/sbin/run-crons) Jan 21 19:39:41 thoregon kernel: [ 6364.620131] radeon :07:00.0: GPU lockup CP stall for more than 1msec Jan 21 19:39:41 thoregon kernel: [ 6364.620139] GPU lockup (waiting for 0x0003F1F2 last fence id 0x0003F1F1) Jan 21 19:39:41 thoregon kernel:

No subject

symbol is exported without explicit consent of the original author (regardless of what we think about GPL/proprietary modules covtroversy). So if NVidia needs to link DMA buffer sharing against their proprietary driver, they should have explicit permission from the original author to turn its

No subject

this sort of thing, nouveau is a good solution its just not going to beat the binary driver in a lot of ways, just not sure whether I care enough yet. Dave.

No subject

However softpipe does not have polygons disappearing at all, so it would appear to be a r300g problem. PrBoom uses GL_TRIANGLE_STRIPs to draw the walls, so this is probably unrelated to this bug. And another thing I noticed fixed. The OGLSB4th Edition chapter 16 vertexblend draws the shiny light

No subject

Dec 11 17:16:36 nf7 kernel: [drm] Initialized drm 1.1.0 20060810 Dec 11 17:16:37 nf7 kernel: [drm] radeon kernel modesetting enabled. Dec 11 17:16:37 nf7 kernel: ACPI: PCI Interrupt Link [APC4] enabled at IRQ 19 Dec 11 17:16:37 nf7 kernel: radeon :02:00.0: PCI INT A -> Link[APC4] -> GSI 19

No subject

Windows. There are only two physical keys: - power-on button - "keyboard"-labeled button, which seems to do nothing hardware-related; it triggers an event caught up by acer_wmi. I think all it does is telling the OS: "hey, pull up the software virtual keyboard on the second display".

No subject

start_kernel |-> setup_arch |-> x86_init.oem.arch_setup = xen_arch_setup |-> check_bugs |-> identify_boot_cpu |-> identify_cpu |-> select_idle_routine so xen_arch_setup will set pm_idle and select_idle_routine will honour it. I'm being told

No subject

allocating request. Though, it's unlikely cause if request is NULL then BUG_ON will be hit in i915_add_request(). So, to unify the callee uses of i915_add_request(), I'm proposing the following patch. Please let me know what do you guys think. If you guys agree, I can sent a formal patch. Index:

No subject

are looking for. I recognize that it disrupts your current views/plans on how this should be done, but I do want to work with you to find a suitable middle ground that covers most of the possiblities. In case you are looking at my code to follow the above-described scenarios, please make sure

No subject

When the root cause will be discovered, we should allow both of course. But so far, all the attempts on this weren't successful. -- Eugeni Dodonov --bcaec54306ded2a5b704b258e725 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

No subject

some other method before passing the frame off to the overlay. Rather disappointing, and seemingly not of too much use. But, I'd like to expose what functionality there is in any case. Ben. > > v2: fix ABI of get_plane - move format_type_ptr to the end > > Acked-by: Alan Cox > Reviewed-by:

No subject

be -EREMOTEIO, which could be caused by transmission error so it should be retried. -- Eugeni Dodonov --bcaec51f8fc3b70e6504af85018a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Oct 17, 2011 at 18:41, Keith Packard

No subject

install libtxc_dxtn -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.

No subject

TTM_PL_FLAG_NO_EVICT so you vq buffer is not allocated with the no evict flags, then i guess it got evicted on first bo allocation which is strange, maybe first bo has some lpfn constraint. >> > =A0 =A0 =A0 =A0Second question I have is how are monochrome cursor ima= ges >> > handled with KMS. Yes

No subject

Hi, Dave. I am sending a mail I wonder where are we on this. I had sent DRM Driver patch v5 for Samsung SoC Exynos4210 a week ago but I didn't received any comments from you. You can refer to these patches I sent from links below. v1: < https://lwn.net/Articles/454380/ > v2: <

No subject

Power_Down_delay value, which is actually documented to be the 'T3 time sequence' value used 'during power up'. There aren't separate T1 and T2 values, but there is a combined T1+T2 value in the PP_ON_DELAYS register, so I use that instead. VBT doesn't provide any values for T1 or T2, so we'll

[no subject]

Hi, Dave. I am sending a mail I wonder where are we on this. I had sent DRM Driver patch v5 for Samsung SoC Exynos4210 a week ago but I didn't received any comments from you. You can refer to these patches I sent from links below. v1: https://lwn.net/Articles/454380/ v2:

No subject

> Please report at bugs.freedesktop.org This also happens with the wine tests. I wanted to add this on the Mesa bug, but I don't have my password at the moment(different keychain). For the Mesa devs debugging the tests may be easier than debugging NFS:MW. (see:

No subject

Power_Down_delay value, which is actually documented to be the 'T3 time sequence' value used 'during power up'. There aren't separate T1 and T2 values, but there is a combined T1+T2 value in the PP_ON_DELAYS register, so I use that instead. VBT doesn't provide any values for T1 or T2, so we'll

No subject

legacy interface provided on top of DRM/KMS driver mostly via helper functions. With this approach, you get the richer KMS API (and all the related plumbing for hotplug, EDID parsing, multi-head support, flipping, etc) for userspace stuff that needs that, but can keep the fbdev userspace

No subject

bisecting brought me to commit 288d5abec8314ae50fe6692f324b0444acae8486. Reverting seems to work as microcode is loaded with compiled in firmware and radeon kms driver. That's commit 288d5abec8314ae50fe6692f324b0444acae8486 Author: Linus Torvalds Date: Wed Aug 3 22:03:29 2011 -1000 Boot

No subject

-- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.

No subject

related to X. And drm should be able to live without X. So why would libdrm-intel rely on libpciaccess/X to be build? I'm sure we could do without it, since all other drivers do. As things are right now, would that imply using a X lib to build libdrm-intel and then use it with Wayland for

No subject

fix in a hurry (lots of copy-paste), and maybe it would be better to re-do it properly... Thanks again, Kirill

No subject

1. Start up with a 2048x768 surface and set each of the two CRTCs (at= 1024x768 timings) to display left/right half of the screen, 2. Allow for "seamless" mode set, i.e. let the vendor's DRM to report= that the current mode (set by the VBIOS for example) is the same as the sw=

No subject

and actual brightness is maximum (255*2890=736950). I see no other change after it until manual brightness change. This is a totally reversed to your problem. Could you help to get the LPBC value in the initial dark condition? If it's not corresponds to 255, maybe something sneaks and changes it

No subject

passing a framebuffer between two V4L2 devices and between a V4L2 device and GPU. The V4L2 device can either be an input or an output one. The original idea were to add yet-another-mmap-mode at the VIDIOC streaming ioctls, and keep using QBUF/DQBUF to handle it. However, as I've pointed there,

No subject

which contradicts with the topic we are discussed. Regardless of the combination_mode, the log seems to work .. weird. 2011/5/9 Melchior FRANZ > * Joey Lee -- Monday 09 May 2011: > > The following is debug patch, and please add kernel parameter > > drm.debug=0x02 : > > The result is with

No subject

Linux Cg bug or Trine Linux version bug. Windows Trine version (from humble bundle) with WINE works perfectly. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.

No subject

logout is being done with libICE. I know it is not being done with Hal, Consolekit or the XKillClient Xlib function. I will update this bug report as soon as I know which function causes this and have a testcase ready. If you think it will lead to a fix I would be willing to use a pencil and paper

No subject

The Xorg.0.log from the previous boot is attached. Gabriel --BOKacYhQ+x31HxR3 Content-Type: application/x-trash Content-Disposition: attachment; filename="Xorg.0.log.old" Content-Transfer-Encoding: quoted-printable =0AX.Org X Server 1.7.7=0ARelease Date: 2010-05-04=0AX Protocol Version

No subject

[KMS] Kernel modesetting enabled.

No subject

[...] direct rendering: Yes OpenGL renderer string: Gallium 0.4 on AMD RV770

No subject

00 [VGA controller]) (PCI-E) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.

No subject

While screen is loading application will crash with following backtrace ~/Savage2/savage2.bin warning: The VAD has been replaced by a hack pending a complete rewrite EE r600_pipe.c:343 r600_get_param - r600: unknown param 45 EE r600_pipe.c:343 r600_get_param - r600: unknown param 45 *** glibc

No subject

one seemed fine and the interface looked okay to me. Dave.

No subject

backlight handling, and it would be sad if it wasn't fixed in 2.6.38. But I think this is only because I have a gen 2 and the check for combination mode for gen 2 was added in 2.6.37, everyone else already had the buggy backlight behaviour for ages. Without the check gen 2 works correctly because

No subject

Iwai Date: Mon, 21 Feb 2011 14:19:27 +0100 Subject: [PATCH] drm/i915: Fix calculation of backlight value in combined mode The commit a95735569312f2ab0c80425e2cd1e5cb0b4e1870 drm/i915: Refactor panel backlight controls causes a regression for GM45 that is using the combined mode

No subject

When I load the fglrx ati proprietary driver (11.1) for the 5450 card, then= I get throughputs of about 2GB/s in both directions.=20 Running the same test in same environment on the HD5970=20 with the gallium drivers and kernel mode setting and pcie_gen2 activation, i get about the same figures

No subject

is the 8GB->24GB, but it still has 4GB->8GB free - so it can launch one more guest (but without PCI passthrough devices). > On a 4GB machine or less, that would be the same as kernel memory. > Now, if 4 guests think they can allocate 2GB of coherent memory > each, you might run out of kernel

No subject

for this, it can also go to /dev/nirvana. The version related informations for drm-core seems also not to be lovely maintained. How long do we see 1.1.0 as version? For ages? Did you know about interface-version? You found the places for DRM_IF_*? No, this is not a riddle or quiz-show, just have

No subject

attached setup.log), which I partly cherry-picked [1] or refreshed against linux-next (next-20101217). They worked also with yesterdays next-20101221. I have attached a follow-up/fix-up patch for one of Daniel's patchsets. (See below

No subject

would allow easy abuse of the GPU to access any system ram. There is a reason we do expensive command checking in the other amd gpu driver (drivers/gpu/drm/radeon/*cs.c files) Cheers, Jerome

No subject

mapping object in drm file and iirc we will report error if we can't find a mapping for userspace object). I guess at one point we should start thinking about what we want to do on that front. Doing a v3. Cheers, Jerome

No subject

Hi Linus, sorry this is a bit later than I expected got sidetracked into a real-life gastro bug for a couple of days just after merge window opened, Main features amongst it all: new stub driver for poulsbo backlight support drm core: kdb lut support, lots of cleanups, edid enhancement for

No subject

-- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.

No subject

DIN: S-video? Clearly your working monitor (DVI) is on output DVI-0. What is the actual card you have? (manufacturer, model) List all of the connectors that it actually (physically) has. I can think of a few possibilities: 1) That the DVI and HDMI plugs are wired into the same place, 2) That

No subject

test different graphical settings yet. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.

No subject

bugs 13/15 fdo20701 fail Returncode: 1 Errors: Mesa: Mesa 7.9-devel DEBUG build Sep 11 2010 06:16:40 Output: init:104: framebuffer status = 0x8cdd -- then fdo25614-genmipmap fail --- Returncode: 1 Errors: Mesa: Mesa 7.9-devel DEBUG build Sep 11 2010

No subject

(E17 init) E17 INIT: XINERAMA CHOSEN: [1], 1080x1920+1280+0 E17 INIT: XINERAMA CHOSEN: [0], 1280x1024+0+896 (output blinking starts) E17 INIT: XINERAMA SCREEN: [0], 1280x1024+0+0 E17 INIT: XINERAMA CHOSEN: [153045780], 0x153045764+0+153046580 (e17 crash, try to recover) E17 INIT:

No subject

shouldn't be firing at all under normal circumstances. (Looking at it we don't handle the introduction of the BSD ring correctly, but that is irrelevant on the EeePC 900.) Do the stalls and tearing go away with: diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index

No subject

Commit 991ea75c (drm: use workqueue instead of slow-work), which made drm to use wq instead of slow-work, didn't account for the return value difference between delayed_slow_work_enqueue() and queue_delayed_work(). The former returns 0 on success and -errno on failures while the latter never

No subject

start of the GPU reset, which is the last callsite to unlock cp.mutex, ie radeon_gpu_reset->radeon_resume->rv770_resume->rv770= _startup->r600_cp_resume->radeon_ring_test->r600_ring_test->radeon_ring_unl= ock_commit> before the hang at radeon_gpu_reset->->drm_helper_resume_force_mode->drm_c=

No subject

radeontool patched with attachement 34810 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.

No subject

df16dd53c575d0cb9dbee20a3149927c862a9ff6 hwmon: (ltc4245) Read only one GPIO pin and *sometime* before this commit: 09bdf591f4724c7d0328d4d7b8808492addb5a28 drm/radeon/kms: fix dpms state on resume Alex, I am pretty much a 'newb' when it comes to git and the kernel in general and currently

No subject

/* A typical clean-up sequence for objects stored in an idr tree, will * use idr_for_each() to free all objects, if necessary, then * idr_remove_all() to remove all ids, and idr_destroy() to free * up the cached idr_layers. */ We were missing the vital idr_rmove_all() step and so were leaking

No subject

crappy monitors are still crappy. The hw i2c engines are mostly there to reduce CPU usage and allow i2c transactions to be interrupt driven. Alex

No subject

than hw can handle, but it seems to use only a small portion of the buffer. I've changed the code so that it does not abort" Since the game was working fine with this hardware in Windows (and my RV530 is well above minimum requirements) I suspected this to be a Wine issue and I asked at their

No subject

itdiff;h=3Df892034a8ce80ed7098f667aae2eb6300e570603 is part of vanilla 2.6.35-rc4 and -rc5, but neither kernel works for me. > Does this patch help? (0001-drm-radeon-kms-fix-possible-mis-detection-of-sidepor.patch) After adding this to 2.6.35-rc5 the system boots and works so far. But the CP is

No subject

If I go one commit back, cubestorm works. It's quite a large commit and it's not clear to me what the commit does in terms of functionality. BTW, cubestorm is a single-buffered application. --=20 Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=3Demail --- You are receiving

No subject

a) Both r300c and r300g have difficulty with compressed textures, and b) r300g also has a more serious problem with b8g8r8a8_unorm, b4g4r4a4_unorm, b5g6r5_unorm textures (and possibly others), because these are what WoW uses when compressed texture support isn't available. -- Configure bugmail:

No subject

--=20 controlled by gamma light

No subject

No subject

radeon_test_moves (radeon_ttm_backend_bind called through callback function) - radeon_ttm.c:radeon_ttm_backend_bind calls radeon_gart_bind - radeon_gart.c:radeon_gart_bind calls pci_map_page - pci_map_page is alpha_pci_map_page, which calls... - alpha_pci_map_page calls

No subject

mesa upgrade to f4bcd0ca some hours later. At the time I installed lugaru (and did not see any crash) I had just installed 2.6.34-996.201005261005 (drm-next from mainline kernel PPA). Hours before I had installed 2.6.34-999.201005231006 (linus tree). So I must have been running one of those

No subject

0x46c266f0 0x46c42578 Yes (*) /usr/lib/libpng12.so.0 0x47c162d0 0x47c306b8 Yes (*) /usr/lib/libjpeg.so.62 0x46da7740 0x46db14b8 Yes (*) /usr/lib/libXi.so.6 0x46aea720 0x46af4ff8 Yes (*) /usr/lib/libXext.so.6 0x4686a620 0x468758e8 Yes (*) /lib/libz.so.1 0x4a84fe00

No subject

Client side is other machine: indirect glx -> via network. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.

No subject

versions of libdrm from 2.4.18 on. I suppose this means that the Arch Linux people must have patched their version of Linux kernel 2.6.33.3, otherwise it should not have worked with that version of libdrm? Finally, there is the xf86-video-nouveau package, which now is version

No subject

started with the kernel configuration for Arch Linux, but ended up removing many modules as otherwise that 350 MHz Pentium II needed 6 hours to compile. I updated the system before I tried the patch. These are the current versions for Arch Linux: nouveau-drm 0.0.16_20100313-2 xf86-video-nouveau

No subject

invaluable for delving into and fixing some obnoxious driver bugs. I suspect its honeymoon period is now over - those bugs that it could detect easily have been fixed (I hope). In order to capture the relevant information for later chipset generations, we will need to parse the command stream and

<    1   2   3   >