On Thu, Jun 7, 2012 at 1:09 PM, Joonyoung Shim
wrote:
> Hi, Rob.
>
>
> On 06/06/2012 03:06 AM, Rob Clark wrote:
>>
>> From: Rob Clark
>>
>> Add support to display plane properties.
>
>
> Do you not support to set property for plane?
oh, heh, I missed the fact that proptest actually lets you
https://bugs.freedesktop.org/show_bug.cgi?id=50857
--- Comment #2 from Chris Rankin 2012-06-07
14:16:48 PDT ---
Created attachment 62766
--> https://bugs.freedesktop.org/attachment.cgi?id=62766
dmesg output
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
---
https://bugs.freedesktop.org/show_bug.cgi?id=50857
--- Comment #1 from Chris Rankin 2012-06-07
14:16:13 PDT ---
Created attachment 62765
--> https://bugs.freedesktop.org/attachment.cgi?id=62765
lspci output
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
---
https://bugs.freedesktop.org/show_bug.cgi?id=50857
Bug #: 50857
Summary: Invalid command stream with CAICOS when ColorTiling2D
enabled
Classification: Unclassified
Product: Mesa
Version: 8.0
Platform: x86-64 (AMD64)
https://bugzilla.kernel.org/show_bug.cgi?id=43353
Summary: nouveau will not load or boot
Product: Drivers
Version: 2.5
Kernel Version: 3.4
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Hello Tomasz,
On 06/07/2012 06:06 AM, Laurent Pinchart wrote:
> Hi Tomasz,
>
> On Wednesday 06 June 2012 13:56:42 Tomasz Stanislawski wrote:
>> On 06/06/2012 10:06 AM, Laurent Pinchart wrote:
>>> On Wednesday 23 May 2012 15:07:27 Tomasz Stanislawski wrote:
This patch adds the setup of sglist
Hey Erik,
Op 07-06-12 19:35, Erik Gilling schreef:
> On Thu, Jun 7, 2012 at 1:55 AM, Maarten Lankhorst
> wrote:
>> I haven't looked at intel and amd, but from a quick glance
>> it seems like they already implement fencing too, so just
>> some way to synch up the fences on shared buffers seems
>>
This is patch to remove vb2_dc_kaddr_to_pages() function with dma_get_sgtable()
in the patch set posted by Tomasz. It was observed that the former function
fails to get the pages, as follow_pfn() can fail for remapped kernel va provided
by the dma-mapping sub-system.
As Tomasz mentioned, the
https://bugs.freedesktop.org/show_bug.cgi?id=50655
--- Comment #14 from Marek Ol??k 2012-06-07 09:19:52 PDT
---
(In reply to comment #11)
> Marek, any ideas? (bug 47116 might be related)
Sorry I've got none. All the regs were really invariant at the time I wrote the
commit. A hardware bug like
On Thu, 7 Jun 2012 15:53:43 +0200 (CEST)
Jan Engelhardt wrote:
> On Tuesday 2012-06-05 18:29, Alan Cox wrote:
> >>
> >> [Wortmann AG's terra Pad 1051, with a 8086:4102 display chip]
> >
> >0x4102 is an Oaktrail device (GMA600). The driver supports it
> >providing you have the GMA600 option set.
drm/i915 now takes care itself of setting up the gtt for
these chips.
Signed-off-by: Daniel Vetter
---
drivers/char/agp/intel-agp.c | 11 ---
1 files changed, 0 insertions(+), 11 deletions(-)
diff --git a/drivers/char/agp/intel-agp.c b/drivers/char/agp/intel-agp.c
index
When drm/i915 is in control of the gtt, we need to call
the enable function at all the relevant places ourselves.
Signed-off-by: Daniel Vetter
---
drivers/char/agp/intel-gtt.c|3 ++-
drivers/gpu/drm/i915/i915_gem.c |3 +++
include/drm/intel-gtt.h |2 ++
3 files changed,
We need this thing much earlier, and it doesn't make sense
in the hw enabling function intel_enable_gtt - this does not
change over a suspend/resume cycle ...
Signed-off-by: Daniel Vetter
---
drivers/char/agp/intel-gtt.c | 20 ++--
1 files changed, 10 insertions(+), 10
We won't enabled agp unconditionally. Furthermore we do have
the right checks for agp support in place in our ->load
function.
The only thing this variable still does is enforce the module
load order we want (and I'm not even sure whether it succeeds
for that). Hence just use it in a harmless
To be able to directly set up the intel-gtt code from drm/i915 and
avoid setting up the fake-agp driver we need to prepare a few things:
- pass both the bridge and gpu pci_dev to the probe function and add
code to handle the gpu pdev both being present (for drm/i915) and
not present (fake
We need it for all things ums (which essentially only means up to
gen5) and to support b0rked XvMC userspace on gen3.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_dma.c | 21 -
1 files changed, 12 insertions(+), 9 deletions(-)
diff --git
We only need it to fake the agp interface and don't actually
use it in the driver anywhere. Hence conditionalize that.
This is just a prep patch to eventually disable the fake agp
driver on gen6+.
Signed-off-by: Daniel Vetter
---
drivers/char/agp/intel-gtt.c |8 +---
1 files changed, 5
For that to work we need to export the base address of the gtt
mmio window from intel-gtt. Also replace all other uses of
dev->agp by values we already have at hand.
Signed-off-by: Daniel Vetter
---
drivers/char/agp/intel-gtt.c|5 ++---
drivers/gpu/drm/i915/i915_dma.c |
This is a leftover from the conversion of the i81x fake agp driver
over to the new intel-gtt code layoute.
Signed-Off-by: Daniel Vetter
---
drivers/char/agp/intel-gtt.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/char/agp/intel-gtt.c
All drivers that use agp call the agp_init function now directly from
their ->load callback. All other parts check for dev->agp anyway to
check whether agp is available.
This flag has therefore outlived its usefullness, kill it.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i810/i810_drv.c
Only i810 and i915 use this. But now that the driver's ->load function
is responsible for setting up agp, we can simply move this check in
there.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/drm_pci.c |6 +-
drivers/gpu/drm/i810/i810_dma.c |5 +
I've done an audit of everything which is being set up between the
place where drm_pci_agp_init is called currently and where the
driver's ->load function is called. Nothing seems to depend upon
dev->agp being set up correctly.
This is one big step into squashing this giant midlayer mistaken.
Hi all,
With these patches there's no more /dev/agpgart fake agp interface for drm/i915,
at least not for snb and later.
The first 3 patches rework the drm core to move agp initialization into drivers.
A nice bonus is that these remove the mid-layer stench quite a bit from drm ...
The later
On Tuesday 2012-06-05 18:29, Alan Cox wrote:
>>
>> [Wortmann AG's terra Pad 1051, with a 8086:4102 display chip]
>
>0x4102 is an Oaktrail device (GMA600). The driver supports it providing
>you have the GMA600 option set.
Thanks for the info. Setting GMA600=y works, as in, it results
in graphical
On Thu, Jun 07, 2012 at 09:26:23AM +0200, Daniel Vetter wrote:
> On Thu, Jun 07, 2012 at 09:21:20AM +0200, Daniel Vetter wrote:
> > Meh, I've been totally blind. Note to self: Next time around actually look
> > at the backtrace. And I dunno how that escaped our dear QA that long ...
>
> Even more
https://bugs.freedesktop.org/show_bug.cgi?id=50655
--- Comment #13 from Alex Deucher 2012-06-07 07:20:16 PDT
---
IIRC, the fix is to always re-emit a CB reg between draw calls if some other
state changed.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You
https://bugs.freedesktop.org/show_bug.cgi?id=50655
--- Comment #12 from Alex Deucher 2012-06-07 07:16:57 PDT
---
I think I know what's going on here. There's a hw bug on r6xx where you need
to re-emit a CB register if some state further up the pipeline changes even if
the CB state has not
Hi, Rob.
On 06/06/2012 03:06 AM, Rob Clark wrote:
> From: Rob Clark
>
> Add support to display plane properties.
Do you not support to set property for plane?
>
> Signed-off-by: Rob Clark
> ---
> tests/proptest/proptest.c | 32
> 1 file changed, 32
Hi, Rob and Paulo.
On 06/06/2012 03:06 AM, Rob Clark wrote:
> From: Paulo Zanoni
>
> A small program that allows us to see and modify properties.
>
> Reviewed-by: Rob Clark
> Signed-off-by: Paulo Zanoni
> ---
> configure.ac |1 +
> tests/Makefile.am |2 +-
>
https://bugs.freedesktop.org/show_bug.cgi?id=50655
Alex Deucher changed:
What|Removed |Added
Attachment #62476|application/octet-stream|text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=50805
--- Comment #1 from Alex Deucher 2012-06-07 06:36:10 PDT
---
Can you attach your dmesg from boot and xorg log? Also is this a regression?
If so, can you bisect?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
https://bugs.freedesktop.org/show_bug.cgi?id=50805
Alex Deucher changed:
What|Removed |Added
Attachment #62685|text/x-log |text/plain
mime type|
> >>>?The bigger issue is the previous point about how to deal
> >>> with cases where the CPU doesn't really need to get involved as an
> >>> intermediary.
> >>>
> >>> CPU fallback access to the buffer is the only legit case where we
> >>> need a standardized API to userspace (since CPU access
Hi,
On 06/07/2012 08:43 AM, Hans Verkuil wrote:
> On Thu June 7 2012 02:52:06 Laurent Pinchart wrote:
>> On Wednesday 06 June 2012 10:17:03 Hans Verkuil wrote:
>>> On Wed 6 June 2012 05:46:34 Laurent Pinchart wrote:
On Monday 04 June 2012 12:34:23 Rebecca Schultz Zavin wrote:
> I have a
When VGA-switcheroo is built in but unused on systems with multiple
graphics cards, the initializations of non-default graphics cards are
skipped and never enabled (because the switcheroo is activated only
when the controller supports). The current behavior is for avoiding
the system lockup by
Add vga_switcheroo_get_client_state() to get the current state of the
client. This is necessary to determine the proper initial state of
audio clients in HD-audio driver.
Signed-off-by: Takashi Iwai
---
drivers/gpu/vga/vga_switcheroo.c | 13 +
include/linux/vga_switcheroo.h |
Hi,
this is a series of patches to fix the regressions of HD-audio HDMI
on D-GPUs in 3.5-rc1 due to the support of VGA-switcheroo audio clients.
The first patch adds a new helper function to vga-switcheroo and the
second just uses that instead of an open code.
Dave, if the first patch is OK,
Tejun/Jerome (and radeon devs):
I'd like to bring a suspend/resume radeon bug full circle (see:
http://thread.gmane.org/gmane.linux.kernel/1209587 for complete thread and
Tejun's excellent summary below).
The problem was triggered by new input serio driver code (commit
8ee294cd9def000 found
https://bugs.freedesktop.org/show_bug.cgi?id=36602
--- Comment #46 from Andy Furniss 2012-06-07
04:19:52 PDT ---
(In reply to comment #45)
> Thanks Jerome
+1.
Getting +20% fps with etqw on my 4890.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are
Hi Laurent!
I completely missed this when you posted this a week ago, but thank you for
doing this. One suggestion: cross-post the next version to linux-media as well:
I think this is useful for V4L2 as well.
Some comments below:
On Wed 30 May 2012 15:13:29 Laurent Pinchart wrote:
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alex Deucher (3):
radeon: add new pci ids
radeon: fall back to 1D tiling only with broken kernels
configure: bump version for release
Ben Widawsky (2):
intel: sanitize i915_drm.h
intel: wait render header updates
Inki
https://bugzilla.kernel.org/show_bug.cgi?id=13364
Alan changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--
Configure bugmail:
https://bugzilla.kernel.org/show_bug.cgi?id=13364
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
Hey,
For intel/nouveau hybrid graphics I'm interested in this since it
would allow me to synchronize between intel and nvidia cards
without waiting for rendering to complete.
I'm worried about the api though, nouveau and intel already
have existing infrastructure to deal with fencing so exposing
Hi,
I get the attached traces with 3.5-rc1 after suspend/resume,
sometimes. It doesn't always happen. Usually happens at least once
in 10 suspend/resume cycles. The first trace seems non fatal, but the
system locks up in the second one and needs to be rebooted.
https://bugzilla.kernel.org/show_bug.cgi?id=13249
Alan changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--
Configure bugmail:
https://bugzilla.kernel.org/show_bug.cgi?id=13249
Alan changed:
What|Removed |Added
Status|NEEDINFO|RESOLVED
CC|
6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
[?]
Thanks,
Paul
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.f
Hi Rob,
On Tuesday 05 June 2012 04:31:54 Rob Clark wrote:
> Hey, thanks Laurent, this was quite needed!
>
> I apologize in advance for the html mail.. but reviewing this on the flight
> home from connect and can't figure out how to do plain text email w/
> google's offline mail client :-(
No
On Wed, May 30, 2012 at 08:39:13AM -0700, Linus Torvalds wrote:
> On Wed, May 30, 2012 at 1:27 AM, Daniel Vetter wrote:
> >
> > Ok, Chris couldn't reproduce this on his mba. Can you please boot with
> > drm.debug=0xe, reproduce the noise and then attach the full dmesg?
>
> Hmm. Now *I* can't
On Tue, 05 Jun 2012 16:37:20 -0700
Kenneth Graunke wrote:
> On 06/04/2012 02:42 PM, Ben Widawsky wrote:
> > Setting myself up for a late night crying session once again. Most of the
> > people reading this probably know the history and reasons for the patches.
> > If
> > not, you can search the
int drm_intel_gem_bo_wait(drm_intel_bo *bo, uint64_t timeout_ns)
This should bump the libdrm version. We're waiting for context support
so we can do both features in one bump.
v2: don't return remaining timeout amount
use get param and fallback for older kernels
v3: only doing getparam at init
On Wed, Jun 06, 2012 at 04:42:11PM -0700, Ben Widawsky wrote:
> int drm_intel_gem_bo_wait(drm_intel_bo *bo, uint64_t timeout_ns)
>
> This should bump the libdrm version. We're waiting for context support
> so we can do both features in one bump.
>
> v2: don't return remaining timeout amount
>
We need this for dp aux communication. This issue can fill the dmesg
with WARN spam when the panel is disable (e.g. while reconfiguring the
mode or while resuming).
v2: Actually enable edp vdd early enough. I've missed one dp aux
channel thingy ...
v3: We also enable/disable vdd in get_edid,
We need this for dp aux communication. This issue can fill the dmesg
with WARN spam when the panel is disable (e.g. while reconfiguring the
mode or while resuming).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50808
Reported-by: Linus Torvalds
Bugreport:
On Thu June 7 2012 02:52:06 Laurent Pinchart wrote:
> Hi Hans,
>
> On Wednesday 06 June 2012 10:17:03 Hans Verkuil wrote:
> > On Wed 6 June 2012 05:46:34 Laurent Pinchart wrote:
> > > On Monday 04 June 2012 12:34:23 Rebecca Schultz Zavin wrote:
> > > > I have a system where the data is planar,
https://bugs.freedesktop.org/show_bug.cgi?id=50655
Michel D?nzer changed:
What|Removed |Added
CC||maraeo at gmail.com
--- Comment #11
On Thu, Jun 7, 2012 at 12:41 AM, Ben Widawsky wrote:
> Anyone aware of what this will break? It seems to be a much nicer thing
> to do for callers. If people do not like it, I will probably just create
> a #define drmIoctl2 or some such thing.
>
uggh no you going to redeine open/read/write as
https://bugs.freedesktop.org/show_bug.cgi?id=50655
--- Comment #10 from Bryan Quigley 2012-06-06
21:42:42 PDT ---
Created attachment 62689
--> https://bugs.freedesktop.org/attachment.cgi?id=62689
good+bad git bisects
Both the good and bad git bisect logs, the good one had me run warsow,
https://bugs.freedesktop.org/show_bug.cgi?id=50655
--- Comment #9 from Bryan Quigley 2012-06-06
21:39:53 PDT ---
I think I did everything right in this bisect (I didn't the first attempt).
fbebd431ec4e2e461a0cbcd5f3a04a000b8f6bbf is the first bad commit
commit
Hi Hans,
On Wednesday 06 June 2012 10:17:03 Hans Verkuil wrote:
> On Wed 6 June 2012 05:46:34 Laurent Pinchart wrote:
> > On Monday 04 June 2012 12:34:23 Rebecca Schultz Zavin wrote:
> > > I have a system where the data is planar, but the kernel drivers
> > > expect to get one allocation with
Hi Tomasz,
On Wednesday 06 June 2012 13:56:42 Tomasz Stanislawski wrote:
> On 06/06/2012 10:06 AM, Laurent Pinchart wrote:
> > On Wednesday 23 May 2012 15:07:27 Tomasz Stanislawski wrote:
> >> This patch adds the setup of sglist list for MMAP buffers.
> >> It is needed for buffer exporting via
https://bugs.freedesktop.org/show_bug.cgi?id=50805
Bug #: 50805
Summary: radeon gpu driver bug on suspend/resume in 3.5-rc1
Classification: Unclassified
Product: DRI
Version: unspecified
Platform: Other
OS/Version: Linux (All)
https://bugs.freedesktop.org/show_bug.cgi?id=17902
--- Comment #83 from thor at math.tu-berlin.de 2012-06-06 18:21:06 PDT ---
Finally, success!
I'm not quite sure why, but for reasons unclear to me the DVO chip only wants
to talk if the PLL is enabled and running and the screen resolution fits.
Hi Dri devs,
Witold Baryluk reported a lockdep splat
to the fbdev list, but apparently that was the wrong list and you
people are the right list to handle this.
Here is the lockdep splat and Witold's config:
http://marc.info/?l=linux-fbdev=133883191129462=2
I looked into the bug and it turns
On Thu, Jun 7, 2012 at 12:41 AM, Ben Widawsky b...@bwidawsk.net wrote:
Anyone aware of what this will break? It seems to be a much nicer thing
to do for callers. If people do not like it, I will probably just create
a #define drmIoctl2 or some such thing.
uggh no you going to redeine
Hi All,
I'm the original designer of the KDS system that Tom posted
while I was on paternity leave. Find my responses inline...
-Original Message-
From: linaro-mm-sig-boun...@lists.linaro.org [mailto:linaro-mm-sig-
boun...@lists.linaro.org] On Behalf Of Rob Clark
Sent: Monday, June
On Wed, Jun 6, 2012 at 6:33 AM, John Reitan john.rei...@arm.com wrote:
But maybe instead of inventing something new, we can just use 'struct
kthread_work' instead of 'struct kds_callback' plus the two 'void *'s?
If the user needs some extra args they can embed 'struct
kthread_work' in their
Hi Dri devs,
Witold Baryluk bary...@smp.if.uj.edu.pl reported a lockdep splat
to the fbdev list, but apparently that was the wrong list and you
people are the right list to handle this.
Here is the lockdep splat and Witold's config:
http://marc.info/?l=linux-fbdevm=133883191129462w=2
I looked
On Thu June 7 2012 02:52:06 Laurent Pinchart wrote:
Hi Hans,
On Wednesday 06 June 2012 10:17:03 Hans Verkuil wrote:
On Wed 6 June 2012 05:46:34 Laurent Pinchart wrote:
On Monday 04 June 2012 12:34:23 Rebecca Schultz Zavin wrote:
I have a system where the data is planar, but the kernel
On Wed, Jun 06, 2012 at 04:42:11PM -0700, Ben Widawsky wrote:
int drm_intel_gem_bo_wait(drm_intel_bo *bo, uint64_t timeout_ns)
This should bump the libdrm version. We're waiting for context support
so we can do both features in one bump.
v2: don't return remaining timeout amount
use get
On Wed, May 30, 2012 at 08:39:13AM -0700, Linus Torvalds wrote:
On Wed, May 30, 2012 at 1:27 AM, Daniel Vetter dan...@ffwll.ch wrote:
Ok, Chris couldn't reproduce this on his mba. Can you please boot with
drm.debug=0xe, reproduce the noise and then attach the full dmesg?
Hmm. Now *I*
On Thu, Jun 07, 2012 at 09:21:20AM +0200, Daniel Vetter wrote:
On Wed, May 30, 2012 at 08:39:13AM -0700, Linus Torvalds wrote:
On Wed, May 30, 2012 at 1:27 AM, Daniel Vetter dan...@ffwll.ch wrote:
Ok, Chris couldn't reproduce this on his mba. Can you please boot with
drm.debug=0xe,
https://bugs.freedesktop.org/show_bug.cgi?id=50655
Michel Dänzer mic...@daenzer.net changed:
What|Removed |Added
CC||mar...@gmail.com
---
Hi Rob,
On Tuesday 05 June 2012 04:31:54 Rob Clark wrote:
Hey, thanks Laurent, this was quite needed!
I apologize in advance for the html mail.. but reviewing this on the flight
home from connect and can't figure out how to do plain text email w/
google's offline mail client :-(
No
Am Donnerstag, den 07.06.2012, 09:26 +0200 schrieb Daniel Vetter:
[…]
From 709e3d49d83fb7f1c297c7c0d9e994af6571bbdb Mon Sep 17 00:00:00 2001
From: Daniel Vetter daniel.vet...@ffwll.ch
Date: Thu, 7 Jun 2012 08:59:49 +0200
Subject: [PATCH] drm/i915: enable edp vdd in intel_dp_detect
We need
Hey,
For intel/nouveau hybrid graphics I'm interested in this since it
would allow me to synchronize between intel and nvidia cards
without waiting for rendering to complete.
I'm worried about the api though, nouveau and intel already
have existing infrastructure to deal with fencing so exposing
Hi Laurent!
I completely missed this when you posted this a week ago, but thank you for
doing this. One suggestion: cross-post the next version to linux-media as well:
I think this is useful for V4L2 as well.
Some comments below:
On Wed 30 May 2012 15:13:29 Laurent Pinchart wrote:
Hi,
this is a series of patches to fix the regressions of HD-audio HDMI
on D-GPUs in 3.5-rc1 due to the support of VGA-switcheroo audio clients.
The first patch adds a new helper function to vga-switcheroo and the
second just uses that instead of an open code.
Dave, if the first patch is OK,
Add vga_switcheroo_get_client_state() to get the current state of the
client. This is necessary to determine the proper initial state of
audio clients in HD-audio driver.
Signed-off-by: Takashi Iwai ti...@suse.de
---
drivers/gpu/vga/vga_switcheroo.c | 13 +
When VGA-switcheroo is built in but unused on systems with multiple
graphics cards, the initializations of non-default graphics cards are
skipped and never enabled (because the switcheroo is activated only
when the controller supports). The current behavior is for avoiding
the system lockup by
https://bugzilla.kernel.org/show_bug.cgi?id=13249
Alan a...@lxorguk.ukuu.org.uk changed:
What|Removed |Added
Status|NEEDINFO|RESOLVED
https://bugzilla.kernel.org/show_bug.cgi?id=13249
Alan a...@lxorguk.ukuu.org.uk changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--
Configure
https://bugzilla.kernel.org/show_bug.cgi?id=13364
Alan a...@lxorguk.ukuu.org.uk changed:
What|Removed |Added
Status|NEW |RESOLVED
https://bugs.freedesktop.org/show_bug.cgi?id=36602
--- Comment #46 from Andy Furniss li...@andyfurniss.entadsl.com 2012-06-07
04:19:52 PDT ---
(In reply to comment #45)
Thanks Jerome
+1.
Getting +20% fps with etqw on my 4890.
--
Configure bugmail:
The bigger issue is the previous point about how to deal
with cases where the CPU doesn't really need to get involved as an
intermediary.
CPU fallback access to the buffer is the only legit case where we
need a standardized API to userspace (since CPU access isn't already
https://bugs.freedesktop.org/show_bug.cgi?id=50805
Alex Deucher ag...@yahoo.com changed:
What|Removed |Added
Attachment #62685|text/x-log |text/plain
mime
https://bugs.freedesktop.org/show_bug.cgi?id=50805
--- Comment #1 from Alex Deucher ag...@yahoo.com 2012-06-07 06:36:10 PDT ---
Can you attach your dmesg from boot and xorg log? Also is this a regression?
If so, can you bisect?
--
Configure bugmail:
https://bugs.freedesktop.org/show_bug.cgi?id=50655
Alex Deucher ag...@yahoo.com changed:
What|Removed |Added
Attachment #62476|application/octet-stream|text/plain
mime
https://bugs.freedesktop.org/show_bug.cgi?id=50655
--- Comment #12 from Alex Deucher ag...@yahoo.com 2012-06-07 07:16:57 PDT ---
I think I know what's going on here. There's a hw bug on r6xx where you need
to re-emit a CB register if some state further up the pipeline changes even if
the CB
https://bugs.freedesktop.org/show_bug.cgi?id=50655
--- Comment #13 from Alex Deucher ag...@yahoo.com 2012-06-07 07:20:16 PDT ---
IIRC, the fix is to always re-emit a CB reg between draw calls if some other
state changed.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
On Thu, Jun 7, 2012 at 1:09 PM, Joonyoung Shim jy0922.s...@samsung.com wrote:
Hi, Rob.
On 06/06/2012 03:06 AM, Rob Clark wrote:
From: Rob Clarkr...@ti.com
Add support to display plane properties.
Do you not support to set property for plane?
oh, heh, I missed the fact that proptest
On Thu, 7 Jun 2012 09:10:08 +0200
Daniel Vetter dan...@ffwll.ch wrote:
On Wed, Jun 06, 2012 at 04:42:11PM -0700, Ben Widawsky wrote:
int drm_intel_gem_bo_wait(drm_intel_bo *bo, uint64_t timeout_ns)
This should bump the libdrm version. We're waiting for context support
so we can do both
Hi all,
With these patches there's no more /dev/agpgart fake agp interface for drm/i915,
at least not for snb and later.
The first 3 patches rework the drm core to move agp initialization into drivers.
A nice bonus is that these remove the mid-layer stench quite a bit from drm ...
The later
I've done an audit of everything which is being set up between the
place where drm_pci_agp_init is called currently and where the
driver's -load function is called. Nothing seems to depend upon
dev-agp being set up correctly.
This is one big step into squashing this giant midlayer mistaken.
Only i810 and i915 use this. But now that the driver's -load function
is responsible for setting up agp, we can simply move this check in
there.
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_pci.c |6 +-
drivers/gpu/drm/i810/i810_dma.c |5 +
All drivers that use agp call the agp_init function now directly from
their -load callback. All other parts check for dev-agp anyway to
check whether agp is available.
This flag has therefore outlived its usefullness, kill it.
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
This is a leftover from the conversion of the i81x fake agp driver
over to the new intel-gtt code layoute.
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/char/agp/intel-gtt.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/char/agp/intel-gtt.c
For that to work we need to export the base address of the gtt
mmio window from intel-gtt. Also replace all other uses of
dev-agp by values we already have at hand.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/char/agp/intel-gtt.c|5 ++---
We only need it to fake the agp interface and don't actually
use it in the driver anywhere. Hence conditionalize that.
This is just a prep patch to eventually disable the fake agp
driver on gen6+.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/char/agp/intel-gtt.c |8
1 - 100 of 116 matches
Mail list logo
