2012/4/19 Christian König :
> Instead of all this humpy pumpy with recursive
> mutex (which also fixes only halve of the problem)
> move the actual gpu reset out of the fence code,
> return -EDEADLK and then reset the gpu in the
> calling ioctl function.
I'm trying to figure out if this has any di
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. Lucas brought this u
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
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 descripto
https://bugs.freedesktop.org/show_bug.cgi?id=48935
Bug #: 48935
Summary: [r600g] WebGL conformance test
textures/texture-mips.html fails
Classification: Unclassified
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
https://bugs.freedesktop.org/show_bug.cgi?id=48934
Bug #: 48934
Summary: [r600g] WebGL conformance test
programs/program-test.html fails
Classification: Unclassified
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
https://bugs.freedesktop.org/show_bug.cgi?id=48935
--- Comment #1 from Pavel Ondračka 2012-04-19
23:05:25 PDT ---
Most likely a duplicate of bug 44912.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the as
Am Freitag, den 20.04.2012, 07:02 +0200 schrieb Thierry Reding:
> * Jon Mayo wrote:
> > On 04/19/2012 01:40 PM, Thierry Reding wrote:
> [...]
> > >So would it be possible to get a basic dumb KMS driver into mainline
> > >(non-staging) and phase in acceleration later on, with ABI guarantees? I
> > >
https://bugs.freedesktop.org/show_bug.cgi?id=48933
Bug #: 48933
Summary: [r600g] WebGL conformance test
context/context-attributes-alpha-depth-stencil-antiali
as.html fails
Classification: Unclassified
Product: Mesa
next part --
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>
* Jerome Glisse wrote:
> Or you can hide the accel ioctl behing a staging/experimental kernel
> option that give you right to change the ABI and do everything upstream.
> Once you like your abi you just remove the option and enable the
> ioctl for the default case.
If it's acceptable, that sound l
* Jon Mayo wrote:
> On 04/19/2012 01:40 PM, Thierry Reding wrote:
[...]
> >So would it be possible to get a basic dumb KMS driver into mainline
> >(non-staging) and phase in acceleration later on, with ABI guarantees? I
> >guess development can go on in separate trees until the ABI is stable and ca
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 ar
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
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,
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 thi
p.org/archives/dri-devel/attachments/20120419/6f22d26d/attachment.pgp>
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 attem
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 r
as you
>>> >> 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>
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
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 is
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 trigge
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 attem
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 i
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 descripto
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 eve
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 inter
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 a
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 Takash
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 thi
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
>> Si
https://bugs.freedesktop.org/show_bug.cgi?id=48935
Bug #: 48935
Summary: [r600g] WebGL conformance test
textures/texture-mips.html fails
Classification: Unclassified
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
https://bugs.freedesktop.org/show_bug.cgi?id=48934
Bug #: 48934
Summary: [r600g] WebGL conformance test
programs/program-test.html fails
Classification: Unclassified
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
https://bugs.freedesktop.org/show_bug.cgi?id=48933
Bug #: 48933
Summary: [r600g] WebGL conformance test
context/context-attributes-alpha-depth-stencil-antiali
as.html fails
Classification: Unclassified
Product: Mesa
It isn't necessary any more and the suballocator
seems to perform even better.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h | 22 +--
drivers/gpu/drm/radeon/radeon_device.c|1 -
drivers/gpu/drm/radeon/radeon_fence.c | 44 +-
drivers/gpu/drm/rad
Instead of all this humpy pumpy with recursive
mutex (which also fixes only halve of the problem)
move the actual gpu reset out of the fence code,
return -EDEADLK and then reset the gpu in the
calling ioctl function.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h| 4
Rings need to lock in order, otherwise
the ring subsystem can deadlock.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h |4 ++
drivers/gpu/drm/radeon/radeon_cs.c| 33 ++
drivers/gpu/drm/radeon/radeon_semaphore.c | 53 ++
Directly use the suballocator to get small chunks
of memory. It's equally fast and doesn't crash when
we encounter a GPU reset.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/evergreen.c|1 -
drivers/gpu/drm/radeon/ni.c |1 -
drivers/gpu/drm/radeon/r600.c
With that in place clients are automatically blocking
until their memory request can be handled.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h |5 +-
drivers/gpu/drm/radeon/radeon_ring.c | 18 ++--
drivers/gpu/drm/radeon/radeon_sa.c | 192 ++
Signed-off-by: Christian König
---
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
--- a/drivers/gpu/drm/radeon/radeon_fen
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 hardcoded EDIDs.
Re
Dumping the current allocations.
Signed-off-by: Christian König
---
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, 42 insertions(+), 0 delet
Previusly multiple ring could trigger multiple GPU
resets at the same time.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h |3 +-
drivers/gpu/drm/radeon/radeon_fence.c | 146 +
2 files changed, 75 insertions(+), 74 deletions(-)
diff
Removing all the different error messages and
having just one standard behaviour over all
chipset generations.
Signed-off-by: Christian König
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/radeon/evergreen.c |7 ++-
drivers/gpu/drm/radeon/ni.c |7 ++-
drivers/gpu/drm/r
Make the suballocator self containing to locking
and fix a overrun bug which happens with
allocations of different alignments.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h|1 +
drivers/gpu/drm/radeon/radeon_sa.c | 19 ---
2 files changed, 13 insert
Just register the debugfs files on init instead of
checking the chipset type multiple times.
Signed-off-by: Christian König
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_ring.c | 31 +++
1 files changed, 19 insertions(+), 12 deletions(-)
diff --git a
It makes no sense at all to have more than one flag.
Signed-off-by: Christian König
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/radeon/r100.c |1 -
drivers/gpu/drm/radeon/r300.c |1 -
drivers/gpu/drm/radeon/radeon.h|1 -
drivers/gpu/drm/radeon/radeon_devi
Different rings have different criteria to test
if they are stuck.
v2: rebased on current drm-next
Signed-off-by: Christian König
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon.h |4 +-
drivers/gpu/drm/radeon/radeon_asic.c | 44 ++--
driver
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 problems
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 r
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
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, rig
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 upscal
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 he
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?
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 Wind
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 ar
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: http
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 inc
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 ce
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 should
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. Lucas
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 mode
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 s
* 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 referring to
> > previous experience with Nouveau where Linus used to
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 implementation
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 interesting
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
>>
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
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 8086c
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 Wind
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 attem
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 inter
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 a
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,
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 free to add my:
Reviewed-by: Al
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)
<6>[1
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 check
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 insertions(+), 0 deletions(-)
diff --g
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 th
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
[3.
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 tha
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
>>
>>> 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 carryi
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 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 wrote:
> >>> On Thu, Apr 19, 2012 at 5:22 PM, Andy Whitcroft
> >>>
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
>
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 issue w
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 trigge
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 attem
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 free to add my:
Reviewed-by:
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 eve
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 8086c
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 f
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, righ
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 Takash
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 check
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 displ
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 hardcoded EDIDs.
Re
1 - 100 of 123 matches
Mail list logo
