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
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_
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
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
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
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 #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 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
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
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
lone...@kapsi.fi changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
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
--- 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
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=43858
Alex Deucher changed:
What|Removed |Added
Attachment #54464|text/x-log |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=41569
Alex Deucher changed:
What|Removed |Added
Attachment #55401|application/octet-stream|text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=37826
Sven Arvidsson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
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
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
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
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
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
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
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>
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
>>>
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
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_
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
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
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
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 #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 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
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
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
lonefox at kapsi.fi changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
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
--- 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 #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=43858
Alex Deucher changed:
What|Removed |Added
Attachment #54464|text/x-log |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=41569
Alex Deucher changed:
What|Removed |Added
Attachment #55401|application/octet-stream|text/plain
mime type|
45 matches
Mail list logo
