[RFC 0/4] Add NVIDIA Tegra DRM support

A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120419/1365b525/attachment-0001.pgp>

[Bug 42162] Display not enabled on resume (HP DV6)

https://bugs.freedesktop.org/show_bug.cgi?id=42162 --- Comment #6 from Johan Brannlund 2012-04-19 14:15:46 PDT --- This bug is still present in kernel 3.4-rc3. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You

[RFC 0/4] Add NVIDIA Tegra DRM support

On Thu, Apr 19, 2012 at 6:35 PM, Thierry Reding wrote: > Before posting the next round of patches I wanted to clarify whether we need > to take the Tegra driver through staging. Lucas brought this up referring to > previous experience with Nouveau where Linus used to complain that userspace > ABI

[git pull] drm fixes

Hi Linus, its like a grab bag of one liners, core: fix page flip error path, reorder object teardown. usb: fix the drm_usb module license. i915: VT switch on SNB with non-native modes fix, and a regression fix from 3.3. radeon: missing unreserve on SI, AGP/VRAM setup fix (fixes radeon on IA64,

Reworking of GPU reset logic

2012/4/19 Christian K?nig : > This includes mostly fixes for multi ring lockups and GPU resets, but it > should general improve the behavior of the kernel mode driver in case > something goes badly wrong. > > On the other hand it completely rewrites the IB pool and semaphore handling, > so I

[RFC 0/4] Add NVIDIA Tegra DRM support

dri-devel/attachments/20120419/6f22d26d/attachment.pgp>

[PATCH 0/1] [RFC] DRM locking issues during early open

On Thu, Apr 19, 2012 at 05:30:03PM +0100, Dave Airlie wrote: > On Thu, Apr 19, 2012 at 5:22 PM, Andy Whitcroft wrote: > > We have been carrying a (rather poor) patch for an issue we identified in > > the DRM driver. ?This issue is triggered when a DRM device is initialising > > and userspace

[RFC 0/4] Add NVIDIA Tegra DRM support

On Thu, Apr 19, 2012 at 4:40 PM, Thierry Reding wrote: > * Dave Airlie wrote: >> On Thu, Apr 19, 2012 at 6:35 PM, Thierry Reding >> wrote: >> > Before posting the next round of patches I wanted to clarify whether we >> > need >> > to take the Tegra driver through staging. Lucas brought this up

[PATCH 0/1] [RFC] DRM locking issues during early open

gt; suggest but in the interim a wait would at least avoid the issues we are >>> >> seeing. ?I will see how awful it looks. >>> > >>> > Just to confirm its the drm_sysfs_device_add that causes the race we care >>> > about. >>> > >>> > it needs to happen after the driver is happy. Since it calls >>> > device_register and that is what triggers udev magic to load the >>> > userspace. >>> > >>> > If you have a userspace app banging on a static device node that might >>> > need another set of fun fixes. >>> >>> Okay the sysfs add and the idr_replace are the things we need to delay. >> >> Since you can still get at things with a static node, it seems like >> locking is the real issue here? ?Is there no mutex we can take across >> init to block any openers until we're done? > > well the idr replace should be the thing that matters, since before > that openers get -ENODEV, after it they end up success. > we may need a lock around that once we fix the logic.\ Here's my predinner hack, contains random rtl change as well, plz ignore. now for dinner. Dave. -- next part -- A non-text attachment was scrubbed... Name: myhack Type: application/octet-stream Size: 2820 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120419/7ecb57c4/attachment.obj>

[PATCH 0/1] [RFC] DRM locking issues during early open

On Thu, Apr 19, 2012 at 5:55 PM, Jesse Barnes wrote: > On Thu, 19 Apr 2012 17:52:39 +0100 > Dave Airlie wrote: > >> On Thu, Apr 19, 2012 at 5:47 PM, Dave Airlie wrote: >> > On Thu, Apr 19, 2012 at 5:41 PM, Andy Whitcroft >> > wrote: >> >> On Thu, Apr 19, 2012 at 05:30:03PM +0100, Dave Airlie

[PATCH 0/1] [RFC] DRM locking issues during early open

On Thu, Apr 19, 2012 at 5:47 PM, Dave Airlie wrote: > On Thu, Apr 19, 2012 at 5:41 PM, Andy Whitcroft wrote: >> On Thu, Apr 19, 2012 at 05:30:03PM +0100, Dave Airlie wrote: >>> On Thu, Apr 19, 2012 at 5:22 PM, Andy Whitcroft >>> wrote: >>> > We have been carrying a (rather poor) patch for an

[PATCH 0/1] [RFC] DRM locking issues during early open

On Thu, Apr 19, 2012 at 5:41 PM, Andy Whitcroft wrote: > On Thu, Apr 19, 2012 at 05:30:03PM +0100, Dave Airlie wrote: >> On Thu, Apr 19, 2012 at 5:22 PM, Andy Whitcroft wrote: >> > We have been carrying a (rather poor) patch for an issue we identified in >> > the DRM driver. ?This issue is

[PATCH 0/1] [RFC] DRM locking issues during early open

On Thu, Apr 19, 2012 at 05:30:03PM +0100, Dave Airlie wrote: > On Thu, Apr 19, 2012 at 5:22 PM, Andy Whitcroft wrote: > > We have been carrying a (rather poor) patch for an issue we identified in > > the DRM driver. ?This issue is triggered when a DRM device is initialising > > and userspace

[PATCH v4 02/14] Documentation: media: description of DMABUF importing in V4L2

Em 19-04-2012 11:32, Tomasz Stanislawski escreveu: > Hi Laurent, > > One may find similar sentences in MMAP, USERPTR and DMABUF. > Maybe the common parts like description of STREAMON/OFF, > QBUF/DQBUF shuffling should be moved to separate section > like "Streaming" :). > > Maybe it is worth to

[PATCH v4 02/14] Documentation: media: description of DMABUF importing in V4L2

Em 19-04-2012 11:32, Tomasz Stanislawski escreveu: > On 04/17/2012 01:25 AM, Laurent Pinchart wrote: >> Hi Tomasz, >> >> Thanks for the patch. >> >> On Friday 13 April 2012 17:47:44 Tomasz Stanislawski wrote: >>> This patch adds description and usage examples for importing >>> DMABUF file

[PATCH 0/1] [RFC] DRM locking issues during early open

On Thu, Apr 19, 2012 at 5:22 PM, Andy Whitcroft wrote: > We have been carrying a (rather poor) patch for an issue we identified in > the DRM driver. ?This issue is triggered when a DRM device is initialising > and userspace attempts to open it, typically in response to the sysfs > device added

[PATCH 1/1] drm -- stop early access to drm devices

When a drm driver is initialised we first allocate and initialise the drm minor numbers including creating the sysfs files, then we trigger the driver load method. The act of creating the sysfs files triggers the uevent. This means udev may start programs which open /dev/dri/card0 and other

[PATCH 0/1] [RFC] DRM locking issues during early open

We have been carrying a (rather poor) patch for an issue we identified in the DRM driver. This issue is triggered when a DRM device is initialising and userspace attempts to open it, typically in response to the sysfs device added event. Basically we allocate the minor numbers making the device

[Intel-gfx] [PATCH 00/12] Add more DMT and common modes

At Thu, 19 Apr 2012 14:03:58 +0200, Takashi Iwai wrote: > > At Tue, 17 Apr 2012 17:26:26 +0200, > Takashi Iwai wrote: > > > > At Fri, 13 Apr 2012 16:56:26 -0400, > > Adam Jackson wrote: > > > > > > On 4/13/12 4:33 PM, Adam Jackson wrote: > > > > Incorporates some feedback from Rodrigo and

[PATCH v4 02/14] Documentation: media: description of DMABUF importing in V4L2

On 04/17/2012 01:25 AM, Laurent Pinchart wrote: > Hi Tomasz, > > Thanks for the patch. > > On Friday 13 April 2012 17:47:44 Tomasz Stanislawski wrote: >> This patch adds description and usage examples for importing >> DMABUF file descriptor in V4L2. >> >> Signed-off-by: Tomasz Stanislawski >>

[PATCH] drm/radeon: fix load detect on rn50 with hardcoded EDIDs.

From: Dave Airlie When the force changes went in back in 3.3.0, we ended up returning disconnected in the !force case, and the connected in when forced, as it hit the hardcoded check. Fix it so all exits go via the hardcoded check and stop spurious modesets on platforms with

[Bug 48880] Set mode has different timings than requested on VGA

https://bugs.freedesktop.org/show_bug.cgi?id=48880 --- Comment #24 from Alex Deucher 2012-04-19 08:20:03 PDT --- (In reply to comment #23) > > The trick is testing a given version of the chip to the death and finding the > frequency limits of the inner loop of the pll. I have always managed to

[Bug 48880] Set mode has different timings than requested on VGA

https://bugs.freedesktop.org/show_bug.cgi?id=48880 --- Comment #23 from Luc Verhaegen 2012-04-19 08:15:14 PDT --- (In reply to comment #21) > (In reply to comment #20) > > What about the BIOS bug angle? Because kernel is not setting up the hardware > > directly, but asking the BIOS to do it,

[pull] drm-intel-fixes for 3.4-rc4

Hi Dave, Just 3 fixes this time around: - Regression fix for upscaled lvds modes on older machines, the clean-up of our crtc timing handling from the interlaced patches screwed things up there. - Locking fix in lastclose, prevents an oops. - Black panel on vt switch due to pageflip when

[Bug 48880] Set mode has different timings than requested on VGA

https://bugs.freedesktop.org/show_bug.cgi?id=48880 --- Comment #22 from Alex Deucher 2012-04-19 07:47:09 PDT --- Created attachment 60315 --> https://bugs.freedesktop.org/attachment.cgi?id=60315 possible fix use fract fb div on APUs. Tested on all the hw I have available. Does this patch

[Bug 48880] Set mode has different timings than requested on VGA

https://bugs.freedesktop.org/show_bug.cgi?id=48880 --- Comment #21 from Alex Deucher 2012-04-19 07:20:44 PDT --- (In reply to comment #20) > What about the BIOS bug angle? Because kernel is not setting up the hardware > directly, but asking the BIOS to do it, right? Is that out of the question?

Enhancing EDID quirk functionality

Greetings all! I recently discovered that my nice 1900x1200 display is horribly confused by the InfoFrame functionality that was added to the nouveau driver in Linux 3.3. Additional testing has shown that it has the same problem with the i915 driver and NVIDIA's proprietary driver. NVIDIA's

[Bug 48880] Set mode has different timings than requested on VGA

https://bugs.freedesktop.org/show_bug.cgi?id=48880 --- Comment #20 from Tvrtko Ursulin 2012-04-19 07:09:04 PDT --- What about the BIOS bug angle? Because kernel is not setting up the hardware directly, but asking the BIOS to do it, right? Is that out of the question? -- Configure bugmail:

[Intel-gfx] [PATCH 00/12] Add more DMT and common modes

At Tue, 17 Apr 2012 17:26:26 +0200, Takashi Iwai wrote: > > At Fri, 13 Apr 2012 16:56:26 -0400, > Adam Jackson wrote: > > > > On 4/13/12 4:33 PM, Adam Jackson wrote: > > > Incorporates some feedback from Rodrigo and Takashi. Major themes of the > > > series: > > > > > > - Fix the DMT list to

[Bug 48880] Set mode has different timings than requested on VGA

https://bugs.freedesktop.org/show_bug.cgi?id=48880 --- Comment #19 from Alex Deucher 2012-04-19 07:02:28 PDT --- (In reply to comment #18) > (In reply to comment #15) > > > > Err, Alex, i think that it is the display engine, for a particular version > > and > > process, that has issues with

[Bug 48880] Set mode has different timings than requested on VGA

https://bugs.freedesktop.org/show_bug.cgi?id=48880 --- Comment #18 from Alex Deucher 2012-04-19 07:01:10 PDT --- (In reply to comment #15) > > Err, Alex, i think that it is the display engine, for a particular version and > process, that has issues with certain divider combinations which

[RFC 0/4] Add NVIDIA Tegra DRM support

On 04/19/2012 01:40 PM, Thierry Reding wrote: > * PGP Signed by an unknown key > > * Dave Airlie wrote: >> On Thu, Apr 19, 2012 at 6:35 PM, Thierry Reding >> wrote: >>> Before posting the next round of patches I wanted to clarify whether we need >>> to take the Tegra driver through staging.

[Bug 48880] Set mode has different timings than requested on VGA

https://bugs.freedesktop.org/show_bug.cgi?id=48880 --- Comment #17 from Tvrtko Ursulin 2012-04-19 06:59:00 PDT --- (In reply to comment #16) > (In reply to comment #14) > > I'd be leery of changing the pll flags without a lot of thorough testing > > since > > these change may break certain

[Bug 48880] Set mode has different timings than requested on VGA

https://bugs.freedesktop.org/show_bug.cgi?id=48880 --- Comment #15 from Luc Verhaegen 2012-04-19 06:45:19 PDT --- Alex, i thi(In reply to comment #14) > > As I said before some monitors are really picky about the clocks they get. > The > pixel clock is generated from a reference clock and a

[PATCH v4 11/14] v4l: vb2-dma-contig: add support for dma_buf importing

Hi Laurent, On 04/17/2012 02:57 AM, Laurent Pinchart wrote: > Hi Tomasz, > > Thanks for the patch. > > On Friday 13 April 2012 17:47:53 Tomasz Stanislawski wrote: >> From: Sumit Semwal >> >> This patch makes changes for adding dma-contig as a dma_buf user. It >> provides function

[Bug 48880] Set mode has different timings than requested on VGA

https://bugs.freedesktop.org/show_bug.cgi?id=48880 --- Comment #14 from Alex Deucher 2012-04-19 06:37:07 PDT --- (In reply to comment #12) > RADEON_PLL_PREFER_MINM_OVER_MAXP fixes it, monitor now reports the same pixel > clock as from the modeline and locks onto it correctly. > > If

[RFC 05/13] v4l: vb2-dma-contig: add support for DMABUF exporting

Hi Laurent, Thank you for your review. Please refer to the comments below. On 04/17/2012 04:08 PM, Laurent Pinchart wrote: > Hi Tomasz, > > Thanks for the patch. > > On Tuesday 10 April 2012 15:10:39 Tomasz Stanislawski wrote: >> This patch adds support for exporting a dma-contig buffer using

[PATCH] drm/radeon: add a missing entry to encoder_names

An entry for INTERNAL_VCE encoder was missing. Add it. Signed-off-by: Ilija Hadzic --- drivers/gpu/drm/radeon/radeon_display.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_display.c b/drivers/gpu/drm/radeon/radeon_display.c index

[PATCH] drm/radeon: add a missing entry to encoder_names

Forwarding the review from Alex for this patch that happened "behind the scenes" before I sent it. -- Ilija Date: Thu, 19 Apr 2012 16:14:14 + From: "Deucher, Alexander" To: Ilija Hadzic Subject: RE: ObjectID and encoder_names, possible bug ? Ah, Ok. Feel

i915: kernel errors at resume

0) On a laptop I use I've ran into i915 kernel errors at resume. I see these only every now and then: not on all resumes. The pattern of these errors (and preceding messages) is basically always like this: <6>[14673.762529] [drm] Changing LVDS panel from (+hsync, +vsync) to (-hsync, -vsync)

[PATCH] drm/radeon: fix load detect on rn50 with hardcoded EDIDs.

On Thu, Apr 19, 2012 at 10:45 AM, Dave Airlie wrote: > From: Dave Airlie > > When the force changes went in back in 3.3.0, we ended up returning > disconnected in the !force case, and the connected in when forced, > as it hit the hardcoded check. > > Fix it so all exits go via the hardcoded

[PATCH] drm/radeon/kms: use frac fb div on APUs

From: Alex Deucher Seems to be more stable on certain monitors. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=48880 Signed-off-by: Alex Deucher Cc: stable at vger.kernel.org --- drivers/gpu/drm/radeon/atombios_crtc.c |3 +++ 1 files changed, 3

[Bug 48880] Set mode has different timings than requested on VGA

https://bugs.freedesktop.org/show_bug.cgi?id=48880 --- Comment #13 from Tvrtko Ursulin 2012-04-19 03:29:24 PDT --- I've added some more debug which goes all the way to just before the ATOM BIOS call. Without RADEON_PLL_PREFER_MINM_OVER_MAXP: [3.440262] atombios_crtc_set_pll: p1pll [

[RFC PATCH] drm: Add plane event

On Wed, Apr 18, 2012 at 09:19:42PM +0300, Ville Syrj?l? wrote: > On Wed, Apr 18, 2012 at 07:06:10PM +0300, Ville Syrj?l? wrote: > > On Wed, Apr 18, 2012 at 05:27:57PM +0200, Daniel Vetter wrote: > > > Also, I'm toying around with ideas to split up the big modeset lock such > > > that operations

[RFC PATCH] drm: Add plane event

On Wed, Apr 18, 2012 at 09:24:58PM -0400, Kristian H?gsberg wrote: > One thing that's not clear to me is how we would enable a sprite > without going through the atomic modeset again. If the atomic modeset > is all about calculating bandwidth requirements etc, then enabling a > sprite will affect

[PATCH 0/1] [RFC] DRM locking issues during early open

On Thu, 19 Apr 2012 17:52:39 +0100 Dave Airlie wrote: > On Thu, Apr 19, 2012 at 5:47 PM, Dave Airlie wrote: > > On Thu, Apr 19, 2012 at 5:41 PM, Andy Whitcroft > > wrote: > >> On Thu, Apr 19, 2012 at 05:30:03PM +0100, Dave Airlie wrote: > >>> On Thu, Apr 19, 2012 at 5:22 PM, Andy Whitcroft

[Bug 48880] Set mode has different timings than requested on VGA

https://bugs.freedesktop.org/show_bug.cgi?id=48880 --- Comment #11 from Tvrtko Ursulin 2012-04-19 00:51:25 PDT --- (In reply to comment #10) > Is it only problematic on VGA or TMDS? I.e., does one only one or the other, > but not both? Just tried DVI and that works fine. Plus monitor is

[Bug 48880] Set mode has different timings than requested on VGA

https://bugs.freedesktop.org/show_bug.cgi?id=48880 --- Comment #16 from Tvrtko Ursulin 2012-04-19 06:45:58 UTC --- (In reply to comment #14) > (In reply to comment #12) > > RADEON_PLL_PREFER_MINM_OVER_MAXP fixes it, monitor now reports the same > > pixel > > clock as from the modeline and

[Bug 48880] Set mode has different timings than requested on VGA

https://bugs.freedesktop.org/show_bug.cgi?id=48880 --- Comment #12 from Tvrtko Ursulin 2012-04-19 01:47:03 UTC --- RADEON_PLL_PREFER_MINM_OVER_MAXP fixes it, monitor now reports the same pixel clock as from the modeline and locks onto it correctly. If interesting, I collected before and after

[Bug 48880] Set mode has different timings than requested on VGA

https://bugs.freedesktop.org/show_bug.cgi?id=48880 --- Comment #11 from Tvrtko Ursulin tvrtko.ursu...@onelan.co.uk 2012-04-19 00:51:25 PDT --- (In reply to comment #10) Is it only problematic on VGA or TMDS? I.e., does one only one or the other, but not both? Just tried DVI and that works

Re: [RFC PATCH] drm: Add plane event

On Wed, Apr 18, 2012 at 09:24:58PM -0400, Kristian Høgsberg wrote: One thing that's not clear to me is how we would enable a sprite without going through the atomic modeset again. If the atomic modeset is all about calculating bandwidth requirements etc, then enabling a sprite will affect

Re: [RFC PATCH] drm: Add plane event

On Wed, Apr 18, 2012 at 09:19:42PM +0300, Ville Syrjälä wrote: On Wed, Apr 18, 2012 at 07:06:10PM +0300, Ville Syrjälä wrote: On Wed, Apr 18, 2012 at 05:27:57PM +0200, Daniel Vetter wrote: Also, I'm toying around with ideas to split up the big modeset lock such that operations that only

[Bug 48880] Set mode has different timings than requested on VGA

https://bugs.freedesktop.org/show_bug.cgi?id=48880 --- Comment #12 from Tvrtko Ursulin tvrtko.ursu...@onelan.co.uk 2012-04-19 01:47:03 UTC --- RADEON_PLL_PREFER_MINM_OVER_MAXP fixes it, monitor now reports the same pixel clock as from the modeline and locks onto it correctly. If interesting, I

i915: kernel errors at resume

0) On a laptop I use I've ran into i915 kernel errors at resume. I see these only every now and then: not on all resumes. The pattern of these errors (and preceding messages) is basically always like this: 6[14673.762529] [drm] Changing LVDS panel from (+hsync, +vsync) to (-hsync, -vsync)

[Bug 48880] Set mode has different timings than requested on VGA

https://bugs.freedesktop.org/show_bug.cgi?id=48880 --- Comment #13 from Tvrtko Ursulin tvrtko.ursu...@onelan.co.uk 2012-04-19 03:29:24 PDT --- I've added some more debug which goes all the way to just before the ATOM BIOS call. Without RADEON_PLL_PREFER_MINM_OVER_MAXP: [3.440262]

Re: [RFC 05/13] v4l: vb2-dma-contig: add support for DMABUF exporting

Hi Laurent, Thank you for your review. Please refer to the comments below. On 04/17/2012 04:08 PM, Laurent Pinchart wrote: Hi Tomasz, Thanks for the patch. On Tuesday 10 April 2012 15:10:39 Tomasz Stanislawski wrote: This patch adds support for exporting a dma-contig buffer using DMABUF

Re: [PATCH v4 11/14] v4l: vb2-dma-contig: add support for dma_buf importing

Hi Laurent, On 04/17/2012 02:57 AM, Laurent Pinchart wrote: Hi Tomasz, Thanks for the patch. On Friday 13 April 2012 17:47:53 Tomasz Stanislawski wrote: From: Sumit Semwal sumit.sem...@ti.com This patch makes changes for adding dma-contig as a dma_buf user. It provides function

Re: [Intel-gfx] [PATCH 00/12] Add more DMT and common modes

At Tue, 17 Apr 2012 17:26:26 +0200, Takashi Iwai wrote: At Fri, 13 Apr 2012 16:56:26 -0400, Adam Jackson wrote: On 4/13/12 4:33 PM, Adam Jackson wrote: Incorporates some feedback from Rodrigo and Takashi. Major themes of the series: - Fix the DMT list to include

[pull] drm-intel-fixes for 3.4-rc4

Hi Dave, Just 3 fixes this time around: - Regression fix for upscaled lvds modes on older machines, the clean-up of our crtc timing handling from the interlaced patches screwed things up there. - Locking fix in lastclose, prevents an oops. - Black panel on vt switch due to pageflip when

[Bug 48880] Set mode has different timings than requested on VGA

https://bugs.freedesktop.org/show_bug.cgi?id=48880 --- Comment #15 from Luc Verhaegen l...@skynet.be 2012-04-19 06:45:19 PDT --- Alex, i thi(In reply to comment #14) As I said before some monitors are really picky about the clocks they get. The pixel clock is generated from a reference

[Bug 48880] Set mode has different timings than requested on VGA

https://bugs.freedesktop.org/show_bug.cgi?id=48880 --- Comment #16 from Tvrtko Ursulin tvrtko.ursu...@onelan.co.uk 2012-04-19 06:45:58 UTC --- (In reply to comment #14) (In reply to comment #12) RADEON_PLL_PREFER_MINM_OVER_MAXP fixes it, monitor now reports the same pixel clock as from

[Bug 48880] Set mode has different timings than requested on VGA

https://bugs.freedesktop.org/show_bug.cgi?id=48880 --- Comment #17 from Tvrtko Ursulin tvrtko.ursu...@onelan.co.uk 2012-04-19 06:59:00 PDT --- (In reply to comment #16) (In reply to comment #14) I'd be leery of changing the pll flags without a lot of thorough testing since these change

[Bug 48880] Set mode has different timings than requested on VGA

https://bugs.freedesktop.org/show_bug.cgi?id=48880 --- Comment #18 from Alex Deucher ag...@yahoo.com 2012-04-19 07:01:10 PDT --- (In reply to comment #15) Err, Alex, i think that it is the display engine, for a particular version and process, that has issues with certain divider combinations

[Bug 48880] Set mode has different timings than requested on VGA

https://bugs.freedesktop.org/show_bug.cgi?id=48880 --- Comment #19 from Alex Deucher ag...@yahoo.com 2012-04-19 07:02:28 PDT --- (In reply to comment #18) (In reply to comment #15) Err, Alex, i think that it is the display engine, for a particular version and process, that has issues

[Bug 48880] Set mode has different timings than requested on VGA

https://bugs.freedesktop.org/show_bug.cgi?id=48880 --- Comment #20 from Tvrtko Ursulin tvrtko.ursu...@onelan.co.uk 2012-04-19 07:09:04 PDT --- What about the BIOS bug angle? Because kernel is not setting up the hardware directly, but asking the BIOS to do it, right? Is that out of the question?

[Bug 48880] Set mode has different timings than requested on VGA

https://bugs.freedesktop.org/show_bug.cgi?id=48880 --- Comment #21 from Alex Deucher ag...@yahoo.com 2012-04-19 07:20:44 PDT --- (In reply to comment #20) What about the BIOS bug angle? Because kernel is not setting up the hardware directly, but asking the BIOS to do it, right? Is that out of

Re: [PATCH v4 02/14] Documentation: media: description of DMABUF importing in V4L2

On 04/17/2012 01:25 AM, Laurent Pinchart wrote: Hi Tomasz, Thanks for the patch. On Friday 13 April 2012 17:47:44 Tomasz Stanislawski wrote: This patch adds description and usage examples for importing DMABUF file descriptor in V4L2. Signed-off-by: Tomasz Stanislawski

[Bug 48880] Set mode has different timings than requested on VGA

https://bugs.freedesktop.org/show_bug.cgi?id=48880 --- Comment #22 from Alex Deucher ag...@yahoo.com 2012-04-19 07:47:09 PDT --- Created attachment 60315 -- https://bugs.freedesktop.org/attachment.cgi?id=60315 possible fix use fract fb div on APUs. Tested on all the hw I have available. Does

[PATCH] drm/radeon/kms: use frac fb div on APUs

From: Alex Deucher alexander.deuc...@amd.com Seems to be more stable on certain monitors. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=48880 Signed-off-by: Alex Deucher alexander.deuc...@amd.com Cc: sta...@vger.kernel.org --- drivers/gpu/drm/radeon/atombios_crtc.c |3 +++ 1 files

[PATCH] drm/radeon: fix load detect on rn50 with hardcoded EDIDs.

From: Dave Airlie airl...@redhat.com When the force changes went in back in 3.3.0, we ended up returning disconnected in the !force case, and the connected in when forced, as it hit the hardcoded check. Fix it so all exits go via the hardcoded check and stop spurious modesets on platforms with

Re: [PATCH] drm/radeon: fix load detect on rn50 with hardcoded EDIDs.

On Thu, Apr 19, 2012 at 10:45 AM, Dave Airlie airl...@gmail.com wrote: From: Dave Airlie airl...@redhat.com When the force changes went in back in 3.3.0, we ended up returning disconnected in the !force case, and the connected in when forced, as it hit the hardcoded check. Fix it so all

Re: [Intel-gfx] [PATCH 00/12] Add more DMT and common modes

At Thu, 19 Apr 2012 14:03:58 +0200, Takashi Iwai wrote: At Tue, 17 Apr 2012 17:26:26 +0200, Takashi Iwai wrote: At Fri, 13 Apr 2012 16:56:26 -0400, Adam Jackson wrote: On 4/13/12 4:33 PM, Adam Jackson wrote: Incorporates some feedback from Rodrigo and Takashi. Major themes

[Bug 48880] Set mode has different timings than requested on VGA

https://bugs.freedesktop.org/show_bug.cgi?id=48880 --- Comment #23 from Luc Verhaegen l...@skynet.be 2012-04-19 08:15:14 PDT --- (In reply to comment #21) (In reply to comment #20) What about the BIOS bug angle? Because kernel is not setting up the hardware directly, but asking the BIOS to

[Bug 48880] Set mode has different timings than requested on VGA

https://bugs.freedesktop.org/show_bug.cgi?id=48880 --- Comment #24 from Alex Deucher ag...@yahoo.com 2012-04-19 08:20:03 PDT --- (In reply to comment #23) The trick is testing a given version of the chip to the death and finding the frequency limits of the inner loop of the pll. I have always

[PATCH] drm/radeon: add a missing entry to encoder_names

An entry for INTERNAL_VCE encoder was missing. Add it. Signed-off-by: Ilija Hadzic ihad...@research.bell-labs.com --- drivers/gpu/drm/radeon/radeon_display.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_display.c

Re: [PATCH 0/1] [RFC] DRM locking issues during early open

On Thu, Apr 19, 2012 at 5:22 PM, Andy Whitcroft a...@canonical.com wrote: We have been carrying a (rather poor) patch for an issue we identified in the DRM driver.  This issue is triggered when a DRM device is initialising and userspace attempts to open it, typically in response to the sysfs

Re: [PATCH] drm/radeon: add a missing entry to encoder_names

Forwarding the review from Alex for this patch that happened behind the scenes before I sent it. -- Ilija Date: Thu, 19 Apr 2012 16:14:14 + From: Deucher, Alexander alexander.deuc...@amd.com To: Ilija Hadzic ihad...@research.bell-labs.com Subject: RE: ObjectID and encoder_names,

Re: [PATCH 0/1] [RFC] DRM locking issues during early open

On Thu, Apr 19, 2012 at 5:41 PM, Andy Whitcroft a...@canonical.com wrote: On Thu, Apr 19, 2012 at 05:30:03PM +0100, Dave Airlie wrote: On Thu, Apr 19, 2012 at 5:22 PM, Andy Whitcroft a...@canonical.com wrote: We have been carrying a (rather poor) patch for an issue we identified in the DRM

Re: [PATCH 0/1] [RFC] DRM locking issues during early open

On Thu, Apr 19, 2012 at 5:47 PM, Dave Airlie airl...@gmail.com wrote: On Thu, Apr 19, 2012 at 5:41 PM, Andy Whitcroft a...@canonical.com wrote: On Thu, Apr 19, 2012 at 05:30:03PM +0100, Dave Airlie wrote: On Thu, Apr 19, 2012 at 5:22 PM, Andy Whitcroft a...@canonical.com wrote: We have been

Re: [PATCH 0/1] [RFC] DRM locking issues during early open

On Thu, Apr 19, 2012 at 5:55 PM, Jesse Barnes jbar...@virtuousgeek.org wrote: On Thu, 19 Apr 2012 17:52:39 +0100 Dave Airlie airl...@gmail.com wrote: On Thu, Apr 19, 2012 at 5:47 PM, Dave Airlie airl...@gmail.com wrote: On Thu, Apr 19, 2012 at 5:41 PM, Andy Whitcroft a...@canonical.com

Re: [PATCH 0/1] [RFC] DRM locking issues during early open

On Thu, Apr 19, 2012 at 5:47 PM, Dave Airlie airl...@gmail.com wrote: On Thu, Apr 19, 2012 at 5:41 PM, Andy Whitcroft a...@canonical.com wrote: On Thu, Apr 19, 2012 at 05:30:03PM +0100, Dave Airlie wrote: On Thu, Apr 19, 2012 at 5:22 PM, Andy Whitcroft a...@canonical.com wrote: We

Re: [RFC 0/4] Add NVIDIA Tegra DRM support

Before posting the next round of patches I wanted to clarify whether we need to take the Tegra driver through staging. Lucas brought this up referring to previous experience with Nouveau where Linus used to complain that userspace ABI was broken for non-staging drivers. I don't know how relevant

[git pull] drm fixes

Hi Linus, its like a grab bag of one liners, core: fix page flip error path, reorder object teardown. usb: fix the drm_usb module license. i915: VT switch on SNB with non-native modes fix, and a regression fix from 3.3. radeon: missing unreserve on SI, AGP/VRAM setup fix (fixes radeon on IA64,

[PATCH 0/1] [RFC] DRM locking issues during early open

We have been carrying a (rather poor) patch for an issue we identified in the DRM driver. This issue is triggered when a DRM device is initialising and userspace attempts to open it, typically in response to the sysfs device added event. Basically we allocate the minor numbers making the device

[PATCH 1/1] drm -- stop early access to drm devices

When a drm driver is initialised we first allocate and initialise the drm minor numbers including creating the sysfs files, then we trigger the driver load method. The act of creating the sysfs files triggers the uevent. This means udev may start programs which open /dev/dri/card0 and other

Re: [PATCH 0/1] [RFC] DRM locking issues during early open

On Thu, Apr 19, 2012 at 05:30:03PM +0100, Dave Airlie wrote: On Thu, Apr 19, 2012 at 5:22 PM, Andy Whitcroft a...@canonical.com wrote: We have been carrying a (rather poor) patch for an issue we identified in the DRM driver.  This issue is triggered when a DRM device is initialising and

Enhancing EDID quirk functionality

Greetings all! I recently discovered that my nice 1900x1200 display is horribly confused by the InfoFrame functionality that was added to the nouveau driver in Linux 3.3. Additional testing has shown that it has the same problem with the i915 driver and NVIDIA's proprietary driver. NVIDIA's

Re: [RFC 0/4] Add NVIDIA Tegra DRM support

On Thu, Apr 19, 2012 at 6:35 PM, Thierry Reding thierry.red...@avionic-design.de wrote: Before posting the next round of patches I wanted to clarify whether we need to take the Tegra driver through staging. Lucas brought this up referring to previous experience with Nouveau where Linus used to

Re: [RFC 0/4] Add NVIDIA Tegra DRM support

* Dave Airlie wrote: On Thu, Apr 19, 2012 at 6:35 PM, Thierry Reding thierry.red...@avionic-design.de wrote: Before posting the next round of patches I wanted to clarify whether we need to take the Tegra driver through staging. Lucas brought this up referring to previous experience with

[Bug 42162] Display not enabled on resume (HP DV6)

https://bugs.freedesktop.org/show_bug.cgi?id=42162 --- Comment #6 from Johan Brannlund freedesktop-b...@nullinfinity.org 2012-04-19 14:15:46 PDT --- This bug is still present in kernel 3.4-rc3. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving

Re: [RFC 0/4] Add NVIDIA Tegra DRM support

On Thu, Apr 19, 2012 at 4:40 PM, Thierry Reding thierry.red...@avionic-design.de wrote: * Dave Airlie wrote: On Thu, Apr 19, 2012 at 6:35 PM, Thierry Reding thierry.red...@avionic-design.de wrote: Before posting the next round of patches I wanted to clarify whether we need to take the

Reworking of GPU reset logic

This includes mostly fixes for multi ring lockups and GPU resets, but it should general improve the behavior of the kernel mode driver in case something goes badly wrong. On the other hand it completely rewrites the IB pool and semaphore handling, so I think there are still a couple of

[PATCH 01/13] drm/radeon: make radeon_gpu_is_lockup a per ring function

Different rings have different criteria to test if they are stuck. v2: rebased on current drm-next Signed-off-by: Christian König deathsim...@vodafone.de Reviewed-by: Alex Deucher alexander.deuc...@amd.com --- drivers/gpu/drm/radeon/radeon.h |4 +- drivers/gpu/drm/radeon/radeon_asic.c

[PATCH 02/13] drm/radeon: replace gpu_lockup with ring-ready flag

It makes no sense at all to have more than one flag. Signed-off-by: Christian König deathsim...@vodafone.de Reviewed-by: Alex Deucher alexander.deuc...@amd.com --- drivers/gpu/drm/radeon/r100.c |1 - drivers/gpu/drm/radeon/r300.c |1 - drivers/gpu/drm/radeon/radeon.h

[PATCH 03/13] drm/radeon: register ring debugfs handlers on init

Just register the debugfs files on init instead of checking the chipset type multiple times. Signed-off-by: Christian König deathsim...@vodafone.de Reviewed-by: Alex Deucher alexander.deuc...@amd.com --- drivers/gpu/drm/radeon/radeon_ring.c | 31 +++ 1 files

[PATCH 04/13] drm/radeon: use central function for IB testing

Removing all the different error messages and having just one standard behaviour over all chipset generations. Signed-off-by: Christian König deathsim...@vodafone.de Reviewed-by: Alex Deucher alexander.deuc...@amd.com --- drivers/gpu/drm/radeon/evergreen.c |7 ++-

[PATCH 05/13] drm/radeon: rework gpu lockup detection and processing

Previusly multiple ring could trigger multiple GPU resets at the same time. Signed-off-by: Christian König deathsim...@vodafone.de --- drivers/gpu/drm/radeon/radeon.h |3 +- drivers/gpu/drm/radeon/radeon_fence.c | 146 + 2 files changed, 75

[PATCH 07/13] drm/radeon: add sub allocator debugfs file

Dumping the current allocations. Signed-off-by: Christian König deathsim...@vodafone.de --- drivers/gpu/drm/radeon/radeon_object.h |5 + drivers/gpu/drm/radeon/radeon_ring.c | 22 ++ drivers/gpu/drm/radeon/radeon_sa.c | 15 +++ 3 files changed,

[PATCH 10/13] drm/radeon: return -ENOENT in fence_wait_*

Signed-off-by: Christian König deathsim...@vodafone.de --- drivers/gpu/drm/radeon/radeon_fence.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_fence.c b/drivers/gpu/drm/radeon/radeon_fence.c index 1a9765a..764ab7e 100644 ---

[PATCH 08/13] drm/radeon: add biggest hole tracking and wakequeue to the sa

With that in place clients are automatically blocking until their memory request can be handled. Signed-off-by: Christian König deathsim...@vodafone.de --- drivers/gpu/drm/radeon/radeon.h |5 +- drivers/gpu/drm/radeon/radeon_ring.c | 18 ++-- drivers/gpu/drm/radeon/radeon_sa.c |

  1   2   >