https://bugs.freedesktop.org/show_bug.cgi?id=41569
Alex Deucher changed:
What|Removed |Added
Attachment #55401|application/octet-stream|text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=43858
--- Comment #4 from Alex Deucher 2012-01-10 13:53:35 PST
---
According to your xorg log, you are trying to drive two 1920x1080 monitors.
That is a lot of bandwidth for an r2xx GPU to drive. Try only attaching one
monitor. I suspect the memory
https://bugs.freedesktop.org/show_bug.cgi?id=43858
Alex Deucher changed:
What|Removed |Added
Attachment #54464|text/x-log |text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=41569
--- Comment #12 from lonefox at kapsi.fi 2012-01-10 13:38:34 PST ---
Created attachment 55401
--> https://bugs.freedesktop.org/attachment.cgi?id=55401
Xorg log
I don't think Xorg log is relevant here, but since you asked one, I'm attaching
it a
https://bugs.freedesktop.org/show_bug.cgi?id=41569
--- Comment #11 from lonefox at kapsi.fi 2012-01-10 13:32:37 PST ---
Created attachment 55400
--> https://bugs.freedesktop.org/attachment.cgi?id=55400
dmesg/system log
I deleted the buggy kernels already, but here is the system log from a boot
https://bugs.freedesktop.org/show_bug.cgi?id=41569
--- Comment #10 from Alex Deucher 2012-01-10 12:51:52 PST
---
(In reply to comment #9)
> These patches may fix some systems, but they also cause a similar problem on
> my
> HP ProBook 6465b (A6-3410MX processor with built-in GPU). There is also
https://bugs.freedesktop.org/show_bug.cgi?id=41569
lonefox at kapsi.fi changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
2012/1/10 InKi Dae :
> 2012/1/10 Semwal, Sumit :
>> On Tue, Jan 10, 2012 at 7:44 AM, Rob Clark wrote:
>>> On Mon, Jan 9, 2012 at 7:34 PM, InKi Dae wrote:
2012/1/10 Rob Clark :
at least with no IOMMU, the memory information(containing physical
memory address) would be copied to vb2_
https://bugs.freedesktop.org/show_bug.cgi?id=44647
Bug #: 44647
Summary: [wine regression] Call of Duty 4: Intro videos renders
garbage
Classification: Unclassified
Product: Mesa
Version: git
Platform: Other
OS
2012/1/10 Rob Clark :
> On Mon, Jan 9, 2012 at 7:34 PM, InKi Dae wrote:
>> 2012/1/10 Rob Clark :
>>> On Mon, Jan 9, 2012 at 4:10 AM, InKi Dae wrote:
note : in case of sharing a buffer between v4l2 and drm driver, the
memory info would be copied vb2_xx_buf to xx_gem or xx_gem to
vb2
2012/1/10 Semwal, Sumit :
> On Tue, Jan 10, 2012 at 7:44 AM, Rob Clark wrote:
>> On Mon, Jan 9, 2012 at 7:34 PM, InKi Dae wrote:
>>> 2012/1/10 Rob Clark :
>>> at least with no IOMMU, the memory information(containing physical
>>> memory address) would be copied to vb2_xx_buf object if drm gem
>>>
https://bugs.freedesktop.org/show_bug.cgi?id=37826
Sven Arvidsson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=41265
--- Comment #11 from Alex Deucher 2012-01-10 06:55:22 PST
---
windows supports decoupled display and rendering.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You
https://bugs.freedesktop.org/show_bug.cgi?id=41265
--- Comment #10 from gyhor at gmx.de 2012-01-10 05:59:45 PST ---
With the ati-driver in windows i can configure how the system uses the PMD.
1. as a gpu for the internal screen
2. as a graphic card for the external display
I think, that the card
https://bugs.freedesktop.org/show_bug.cgi?id=41569
Alex Deucher changed:
What|Removed |Added
Attachment #55401|application/octet-stream|text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=43858
--- Comment #4 from Alex Deucher 2012-01-10 13:53:35 PST ---
According to your xorg log, you are trying to drive two 1920x1080 monitors.
That is a lot of bandwidth for an r2xx GPU to drive. Try only attaching one
monitor. I suspect the memory
On Fri, 2012-01-06 at 16:00 -0500, Jerome Glisse wrote:
> On Fri, Jan 06, 2012 at 02:52:49PM -0500, Konrad Rzeszutek Wilk wrote:
> > > Still having difficulty to reproduce can you reproduce with the attached
> > > printk debuging patch and provide the log (only few printk preceding the
> > > oops o
https://bugs.freedesktop.org/show_bug.cgi?id=43858
Alex Deucher changed:
What|Removed |Added
Attachment #54464|text/x-log |text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=41569
--- Comment #12 from lone...@kapsi.fi 2012-01-10 13:38:34 PST ---
Created attachment 55401
--> https://bugs.freedesktop.org/attachment.cgi?id=55401
Xorg log
I don't think Xorg log is relevant here, but since you asked one, I'm attaching
it anyw
https://bugs.freedesktop.org/show_bug.cgi?id=41569
--- Comment #11 from lone...@kapsi.fi 2012-01-10 13:32:37 PST ---
Created attachment 55400
--> https://bugs.freedesktop.org/attachment.cgi?id=55400
dmesg/system log
I deleted the buggy kernels already, but here is the system log from a boot
wit
From: Joel Sass
Signed-off-by: Joel Sass
Reviewed-by: Adam Jackson
---
drivers/gpu/drm/i915/intel_lvds.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index 77578b4..e44988e 100644
--- a/dr
https://bugs.freedesktop.org/show_bug.cgi?id=41569
--- Comment #10 from Alex Deucher 2012-01-10 12:51:52 PST ---
(In reply to comment #9)
> These patches may fix some systems, but they also cause a similar problem on
> my
> HP ProBook 6465b (A6-3410MX processor with built-in GPU). There is also
On Mon, Jan 09, 2012 at 11:11:06AM +0100, Daniel Vetter wrote:
> On Mon, Jan 09, 2012 at 10:37:28AM +0100, Thomas Hellstrom wrote:
> > Hi!
> >
> > When TTM was originally written, it was assumed that GPU apertures
> > could address pages directly, and that the CPU could access those
> > pages with
https://bugs.freedesktop.org/show_bug.cgi?id=41569
lone...@kapsi.fi changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
On Tue, Jan 10, 2012 at 7:44 AM, Rob Clark wrote:
> On Mon, Jan 9, 2012 at 7:34 PM, InKi Dae wrote:
>> 2012/1/10 Rob Clark :
>> at least with no IOMMU, the memory information(containing physical
>> memory address) would be copied to vb2_xx_buf object if drm gem
>> exported its own buffer and vb2
From: Joel Sass
Signed-off-by: Joel Sass
Reviewed-by: Adam Jackson
---
drivers/gpu/drm/i915/intel_lvds.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index 77578b4..e44988e 100644
--- a/dr
Hi Linus,
This is the main pull request for the drm for this merge window. It has
two conflicts with your tree, I've fixed them up in a separate
drm-linus-merged branch if you don't want to exercise your merging
fingers.
Highlights:
drm core: add plane support and userspace interface to expos
2012/1/10 Rob Clark :
> On Mon, Jan 9, 2012 at 4:10 AM, InKi Dae wrote:
>> note : in case of sharing a buffer between v4l2 and drm driver, the
>> memory info would be copied vb2_xx_buf to xx_gem or xx_gem to
>> vb2_xx_buf through sg table. in this case, only memory info is used to
>> share, not so
Hi Thomas,
On Mon, Jan 09, 2012 at 12:01:28PM +0100, Thomas Hellstrom wrote:
> Thanks for your input. I think this is mostly orthogonal to dma_buf, and
> really a way to adapt TTM to be DMA-api aware. That's currently done
> within the TTM backends. CMA was mearly included as an example that
> mig
https://bugs.freedesktop.org/show_bug.cgi?id=44647
Bug #: 44647
Summary: [wine regression] Call of Duty 4: Intro videos renders
garbage
Classification: Unclassified
Product: Mesa
Version: git
Platform: Other
OS
On Mon, Jan 09, 2012 at 10:37:28AM +0100, Thomas Hellstrom wrote:
> Hi!
>
> When TTM was originally written, it was assumed that GPU apertures
> could address pages directly, and that the CPU could access those
> pages without explicit synchronization. The process of binding a
> page to a GPU tran
On Mon, Jan 09, 2012 at 11:11:06AM +0100, Daniel Vetter wrote:
> On Mon, Jan 09, 2012 at 10:37:28AM +0100, Thomas Hellstrom wrote:
> > Hi!
> >
> > When TTM was originally written, it was assumed that GPU apertures
> > could address pages directly, and that the CPU could access those
> > pages with
On Tue, Jan 10, 2012 at 01:46:05PM +1000, Ben Skeggs wrote:
> On Fri, 2012-01-06 at 16:00 -0500, Jerome Glisse wrote:
> > On Fri, Jan 06, 2012 at 02:52:49PM -0500, Konrad Rzeszutek Wilk wrote:
> > > > Still having difficulty to reproduce can you reproduce with the attached
> > > > printk debuging p
Le 10/01/2012 06:39, Dan Carpenter a ?crit :
> On Tue, Jan 10, 2012 at 12:28:13AM +0100, Martin Peres wrote:
>> Le 04/01/2012 08:20, Dan Carpenter a ?crit :
>>> calc_mclk() returns zero on success and negative on failure but clk is
>>> a u32.
>>>
>>> Signed-off-by: Dan Carpenter
>>>
>>> diff --git
so I'm
sure your patch is good.
regards,
dan carpenter
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120110/e24aecef/attachment.pgp>
On Mon, Jan 09, 2012 at 10:37:28AM +0100, Thomas Hellstrom wrote:
> Hi!
>
> When TTM was originally written, it was assumed that GPU apertures
> could address pages directly, and that the CPU could access those
> pages without explicit synchronization. The process of binding a
> page to a GPU tran
https://bugs.freedesktop.org/show_bug.cgi?id=41265
--- Comment #11 from Alex Deucher 2012-01-10 06:55:22 PST ---
windows supports decoupled display and rendering.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You
On Tue, Jan 10, 2012 at 01:46:05PM +1000, Ben Skeggs wrote:
> On Fri, 2012-01-06 at 16:00 -0500, Jerome Glisse wrote:
> > On Fri, Jan 06, 2012 at 02:52:49PM -0500, Konrad Rzeszutek Wilk wrote:
> > > > Still having difficulty to reproduce can you reproduce with the attached
> > > > printk debuging p
https://bugs.freedesktop.org/show_bug.cgi?id=41265
--- Comment #10 from gy...@gmx.de 2012-01-10 05:59:45 PST ---
With the ati-driver in windows i can configure how the system uses the PMD.
1. as a gpu for the internal screen
2. as a graphic card for the external display
I think, that the card ca
Hi Linus,
This is the main pull request for the drm for this merge window. It has
two conflicts with your tree, I've fixed them up in a separate
drm-linus-merged branch if you don't want to exercise your merging
fingers.
Highlights:
drm core: add plane support and userspace interface to expos
Le 10/01/2012 06:39, Dan Carpenter a écrit :
On Tue, Jan 10, 2012 at 12:28:13AM +0100, Martin Peres wrote:
Le 04/01/2012 08:20, Dan Carpenter a écrit :
calc_mclk() returns zero on success and negative on failure but clk is
a u32.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/nouve
2012/1/10 InKi Dae :
> 2012/1/10 Semwal, Sumit :
>> On Tue, Jan 10, 2012 at 7:44 AM, Rob Clark wrote:
>>> On Mon, Jan 9, 2012 at 7:34 PM, InKi Dae wrote:
2012/1/10 Rob Clark :
at least with no IOMMU, the memory information(containing physical
memory address) would be copied to vb2_
Hi Thomas,
On Mon, Jan 09, 2012 at 12:01:28PM +0100, Thomas Hellstrom wrote:
> Thanks for your input. I think this is mostly orthogonal to dma_buf, and
> really a way to adapt TTM to be DMA-api aware. That's currently done
> within the TTM backends. CMA was mearly included as an example that
> mig
https://bugs.freedesktop.org/show_bug.cgi?id=27314
--- Comment #63 from Rafael ?vila de Esp?ndola
2012-01-09 17:11:34 PST ---
Created attachment 55359
--> https://bugs.freedesktop.org/attachment.cgi?id=55359
dmesg from kernel 3.2
I just tried KMS with kernel 3.2 and I still get a black screen
Le 04/01/2012 08:20, Dan Carpenter a ?crit :
> calc_mclk() returns zero on success and negative on failure but clk is
> a u32.
>
> Signed-off-by: Dan Carpenter
>
> diff --git a/drivers/gpu/drm/nouveau/nv50_pm.c
> b/drivers/gpu/drm/nouveau/nv50_pm.c
> index 0393721..3508de9 100644
> --- a/drivers/g
45 matches
Mail list logo
