On Wed, 8 May 2013, Parag Warudkar wrote:
>
>
> On Wed, 8 May 2013, Christian K?nig wrote:
>
> > If you want to hack a bit on it you could try commenting out the calls to
> > "radeon_set_uvd_clocks" in radeon_uvd.c. That should give you the default
> > clocks of 100Mhz, not enough for usable
On Fri, May 10, 2013 at 12:27:54PM -0700, Andy Lutomirski wrote:
> On Fri, May 10, 2013 at 12:09 PM, Daniel Vetter wrote:
> > On Fri, May 10, 2013 at 11:00:56AM -0700, Andy Lutomirski wrote:
> >> On Fri, May 10, 2013 at 2:19 AM, Daniel Vetter wrote:
> >> > On Thu, May 09, 2013 at 12:46:20PM -0700
On Fri, May 10, 2013 at 11:00:56AM -0700, Andy Lutomirski wrote:
> On Fri, May 10, 2013 at 2:19 AM, Daniel Vetter wrote:
> > On Thu, May 09, 2013 at 12:46:20PM -0700, Andy Lutomirski wrote:
> >> Several drivers currently use mtrr_add through various #ifdef guards
> >> and/or drm wrappers. The vas
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130510/08711ddb/attachment.html>
27;ll see if I can bisect to find a
culprit.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130510/abc42104/attachment.html>
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130510/690338a6/attachment.html>
called libLLVM-3.4svn.so. I just ran into this problem myself.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130510/357d5110/attachment.html>
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130510/f455325c/attachment.html>
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130510/f8ef48c1/attachment.html>
), so I'll attach the results
of:
R600_DEBUG=trace_cs,nodma bfgminer -v1
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachm
Use msecs_to_jiffies_min instead of open-coding the same.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_dp.c |2 +-
drivers/gpu/drm/i915/intel_drv.h |2 +-
drivers/gpu/drm/i915/intel_i2c.c |2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/dr
https://bugzilla.kernel.org/show_bug.cgi?id=57921
--- Comment #4 from Alex Deucher 2013-05-10
14:00:22 ---
I suspect this may be an issue with DMA or vram access from the VM. I'd double
check your VM config.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--
https://bugzilla.kernel.org/show_bug.cgi?id=57921
--- Comment #3 from Luke-Jr 2013-05-10
13:42:18 ---
Yes.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
Suggested-by: Chris Wilson
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_crtc_helper.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index 9085db6..ed1334e 100644
--- a/drive
drm_helper_probe_single_connector_modes() is responsible for pruning the
previously detected modes on a disconnected connector. We don't really
need to log, again, the full list of modes that used to be valid when
connected.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_crtc_helper.c | 4
Instead of just printing "status updated from 1 to 2", make those enum
numbers immediately readable.
v2: Also patch output_poll_execute() (Daniel Vetter)
v3: Use drm_get_connector_status_name (Ville Syrj?l?)
Signed-off-by: Damien Lespiau
Reviewed-by: Jesse Barnes (for v1)
---
drivers/gpu/drm/d
As we parse the string given on the command line one char at a time, it
seems that we do want a break at every case.
Signed-off-by: Damien Lespiau
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/drm_modes.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/
Updated series with:
- Reviews applied,
- Drop a patch that would conflict with Ville's latest changes,
- Drop Chris (Cummins)'s patch as he rebased it on top of drm-next and sent it
back himself,
- Add a suggestion from Chris (Wilson) to not repeat the message in the poll
handler. I did not d
https://bugs.freedesktop.org/show_bug.cgi?id=64443
Priority: medium
Bug ID: 64443
Assignee: dri-devel@lists.freedesktop.org
Summary: [r600g] Oil Rush (Steam version) crashes
Severity: major
Classification: Unclassified
OS: Al
--- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130510/7def3aa1/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=57921
--- Comment #2 from Alex Deucher 2013-05-10
13:08:45 ---
Does the driver work ok when not in a VM and without the patch?
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because:
https://bugs.freedesktop.org/show_bug.cgi?id=64201
--- Comment #22 from Aaron Watry ---
I've gone back to kernel 3.6.11 and still get GPU locks when running this
program (and the min() CL builtin in piglit).
I'm leaning towards the issue being in mesa, which I'll have a much easier time
bisectin
On Fri, May 10, 2013 at 12:27:54PM -0700, Andy Lutomirski wrote:
> On Fri, May 10, 2013 at 12:09 PM, Daniel Vetter wrote:
> > On Fri, May 10, 2013 at 11:00:56AM -0700, Andy Lutomirski wrote:
> >> On Fri, May 10, 2013 at 2:19 AM, Daniel Vetter wrote:
> >> > On Thu, May 09, 2013 at 12:46:20PM -0700
On Fri, May 10, 2013 at 12:09 PM, Daniel Vetter wrote:
> On Fri, May 10, 2013 at 11:00:56AM -0700, Andy Lutomirski wrote:
>> On Fri, May 10, 2013 at 2:19 AM, Daniel Vetter wrote:
>> > On Thu, May 09, 2013 at 12:46:20PM -0700, Andy Lutomirski wrote:
>> >> Several drivers currently use mtrr_add thr
On Fri, May 10, 2013 at 11:00:56AM -0700, Andy Lutomirski wrote:
> On Fri, May 10, 2013 at 2:19 AM, Daniel Vetter wrote:
> > On Thu, May 09, 2013 at 12:46:20PM -0700, Andy Lutomirski wrote:
> >> Several drivers currently use mtrr_add through various #ifdef guards
> >> and/or drm wrappers. The vas
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130510/0c28fe84/attachment.html>
On Thu, May 09, 2013 at 12:46:19PM -0700, Andy Lutomirski wrote:
> A fair number of drivers (mostly graphics) add write-combining MTRRs.
> Most ignore errors and most add the MTRR even on PAT systems which don't
> need to use MTRRs.
>
> This series adds new functions arch_phys_wc_{add,del} that, o
On Thu, May 09, 2013 at 12:46:24PM -0700, Andy Lutomirski wrote:
> i915 open-coded logic that was essentially equivalent to the new API.
>
> Signed-off-by: Andy Lutomirski
> ---
>
> Changes from v1: More cleanup
>
> drivers/gpu/drm/i915/i915_dma.c | 44
> ++
On Thu, May 09, 2013 at 12:46:20PM -0700, Andy Lutomirski wrote:
> Several drivers currently use mtrr_add through various #ifdef guards
> and/or drm wrappers. The vast majority of them want to add WC MTRRs
> on x86 systems and don't actually need the MTRR if PAT (i.e.
> ioremap_wc, etc) are workin
On Fri, May 10, 2013 at 2:19 AM, Daniel Vetter wrote:
> On Thu, May 09, 2013 at 12:46:20PM -0700, Andy Lutomirski wrote:
>> Several drivers currently use mtrr_add through various #ifdef guards
>> and/or drm wrappers. The vast majority of them want to add WC MTRRs
>> on x86 systems and don't actua
devm_ioremap_resource does sanity checks on the given resource. No need to
duplicate this in the driver.
Signed-off-by: Wolfram Sang
---
drivers/gpu/drm/exynos/exynos_hdmi.c |5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/
Lately, I have been experimenting how to improve the devm interface to make
writing device drivers easier and less error prone while also getting rid of
its subtle issues. I think it has more potential but still needs work and
definately conistency, especiall in its usage.
The first thing I come u
https://bugs.freedesktop.org/show_bug.cgi?id=64201
--- Comment #21 from Alex Deucher ---
Created attachment 79110
--> https://bugs.freedesktop.org/attachment.cgi?id=79110&action=edit
flush testing
I suspect there may still be issues with flushing. You might try playing with
that. This patch
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130510/74a1bd48/attachment.html>
Ville Syrj?l? linux.intel.com> writes:
> I think I'll defer on that one until we decide whether we want add
> both 60Hz and 59.94HZ versions to the connector's mode list. Daniel
> suggested we do it, but I disagree slightly since CEA-861 says that
> monitors should only advertise one variant in t
it/linux/kernel/git/kgene/linux-samsung.git/commit/?h=for-next&id=0207775d6ff7e6a6eddb9931f9328f0f0173a338
>
>
> https://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git/commit/?h=for-next&id=06c460b73f75894cabfb1f5277f27cddbc92745c
>
> And also you can refer to
> Documentation/devicetree/bindings/video/display-timing.txt
>
>
> Best regards,
>> Tomasz
>>
>>
>
>
> --
> Thanks and Regards
> Vikas Sajjan
>
--
Thanks and Regards
Vikas Sajjan
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130510/be49bb9a/attachment.html>
On Wed, 08 May 2013, Ville Syrj?l? wrote:
> On Wed, May 08, 2013 at 05:03:31PM +0100, Damien Lespiau wrote:
>> +static const char *connector_status_str(enum drm_connector_status status)
>> +{
>> +switch (status) {
>> +case connector_status_connected:
>> +return "connected";
>>
https://bugs.freedesktop.org/show_bug.cgi?id=64201
--- Comment #20 from Tom Stellard ---
(In reply to comment #17)
> I can at least confirm that the lock-ups also happen on a CEDAR (HD 5400)
> with the 3.9.0 kernel and latest drm/llvm/mesa master. This machine at
> least doesn't hard lock (GPU r
https://bugs.freedesktop.org/show_bug.cgi?id=64201
--- Comment #19 from Aaron Watry ---
Created attachment 79107
--> https://bugs.freedesktop.org/attachment.cgi?id=79107&action=edit
dmesg lines that correspond to cs trace in previous attachment
--
You are receiving this mail because:
You are
https://bugs.freedesktop.org/show_bug.cgi?id=64201
--- Comment #18 from Aaron Watry ---
Created attachment 79106
--> https://bugs.freedesktop.org/attachment.cgi?id=79106&action=edit
Output of R600_DEBUG=trace_cs,nodma for bfgminer after lockup
--
You are receiving this mail because:
You are t
https://bugs.freedesktop.org/show_bug.cgi?id=64201
--- Comment #17 from Aaron Watry ---
I can at least confirm that the lock-ups also happen on a CEDAR (HD 5400) with
the 3.9.0 kernel and latest drm/llvm/mesa master. This machine at least
doesn't hard lock (GPU resets after 10 seconds...), so I'
vel/attachments/20130510/f3170653/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=57921
--- Comment #4 from Alex Deucher 2013-05-10 14:00:22
---
I suspect this may be an issue with DMA or vram access from the VM. I'd double
check your VM config.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--
https://bugzilla.kernel.org/show_bug.cgi?id=57921
--- Comment #3 from Luke-Jr 2013-05-10
13:42:18 ---
Yes.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
_
https://bugs.freedesktop.org/show_bug.cgi?id=64201
--- Comment #16 from Aaron Watry ---
> I'm not sure that benchmark mode works for bfgminer. Can you try without
> --benchmark
I just signed up with a pool and tried:
bfgminer -v1 -o [super_secret] -u [even_more_secret] -p [hi!!!]
About 20-30 s
mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130510/b4ccf613/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=57921
--- Comment #2 from Alex Deucher 2013-05-10 13:08:45
---
Does the driver work ok when not in a VM and without the patch?
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because:
Suggested-by: Chris Wilson
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_crtc_helper.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index 9085db6..ed1334e 100644
--- a/drive
drm_helper_probe_single_connector_modes() is responsible for pruning the
previously detected modes on a disconnected connector. We don't really
need to log, again, the full list of modes that used to be valid when
connected.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_crtc_helper.c | 4
Instead of just printing "status updated from 1 to 2", make those enum
numbers immediately readable.
v2: Also patch output_poll_execute() (Daniel Vetter)
v3: Use drm_get_connector_status_name (Ville Syrjälä)
Signed-off-by: Damien Lespiau
Reviewed-by: Jesse Barnes (for v1)
---
drivers/gpu/drm/d
As we parse the string given on the command line one char at a time, it
seems that we do want a break at every case.
Signed-off-by: Damien Lespiau
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/drm_modes.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/
Updated series with:
- Reviews applied,
- Drop a patch that would conflict with Ville's latest changes,
- Drop Chris (Cummins)'s patch as he rebased it on top of drm-next and sent it
back himself,
- Add a suggestion from Chris (Wilson) to not repeat the message in the poll
handler. I did not d
Use msecs_to_jiffies_min instead of open-coding the same.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_dp.c |2 +-
drivers/gpu/drm/i915/intel_drv.h |2 +-
drivers/gpu/drm/i915/intel_i2c.c |2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/dr
https://bugs.freedesktop.org/show_bug.cgi?id=63935
--- Comment #11 from runetmem...@gmail.com ---
Same issue with SUMO on laptop without UEFI.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-deve
-
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130510/7c61b859/attachment-0001.html>
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130510/57a126bd/attachment.html>
Ville Syrjälä linux.intel.com> writes:
> I think I'll defer on that one until we decide whether we want add
> both 60Hz and 59.94HZ versions to the connector's mode list. Daniel
> suggested we do it, but I disagree slightly since CEA-861 says that
> monitors should only advertise one variant in t
https://bugs.freedesktop.org/show_bug.cgi?id=63935
Christian König changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #10 from Christia
On Thu, May 09, 2013 at 12:46:19PM -0700, Andy Lutomirski wrote:
> A fair number of drivers (mostly graphics) add write-combining MTRRs.
> Most ignore errors and most add the MTRR even on PAT systems which don't
> need to use MTRRs.
>
> This series adds new functions arch_phys_wc_{add,del} that, o
On Thu, May 09, 2013 at 12:46:24PM -0700, Andy Lutomirski wrote:
> i915 open-coded logic that was essentially equivalent to the new API.
>
> Signed-off-by: Andy Lutomirski
> ---
>
> Changes from v1: More cleanup
>
> drivers/gpu/drm/i915/i915_dma.c | 44
> ++
On Thu, May 09, 2013 at 12:46:20PM -0700, Andy Lutomirski wrote:
> Several drivers currently use mtrr_add through various #ifdef guards
> and/or drm wrappers. The vast majority of them want to add WC MTRRs
> on x86 systems and don't actually need the MTRR if PAT (i.e.
> ioremap_wc, etc) are workin
https://bugzilla.kernel.org/show_bug.cgi?id=57921
--- Comment #1 from Luke-Jr 2013-05-10
00:40:46 ---
Created an attachment (id=101051)
--> (https://bugzilla.kernel.org/attachment.cgi?id=101051)
kernel patch by workaround VBIOS issue
--
Configure bugmail: https://bugzilla.kernel.org/user
https://bugzilla.kernel.org/show_bug.cgi?id=57921
Summary: NULL pointer dereference in radeon_bo_create
Product: Drivers
Version: 2.5
Kernel Version: 3.9.0
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
https://bugs.freedesktop.org/show_bug.cgi?id=63279
Tormod Volden changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Thu, May 9, 2013 at 4:44 PM, Jerome Glisse wrote:
> On Thu, May 9, 2013 at 3:46 PM, Andy Lutomirski wrote:
>> A fair number of drivers (mostly graphics) add write-combining MTRRs.
>> Most ignore errors and most add the MTRR even on PAT systems which don't
>> need to use MTRRs.
>
> This comment
Hi Tomasz,
On 10 May 2013 08:25, Vikas Sajjan wrote:
> Hi Tomasz,
>
>
> On 10 May 2013 05:35, Tomasz Figa wrote:
>
>> Hi Vikas,
>>
>> On Wednesday 08 of May 2013 11:31:34 Vikas Sajjan wrote:
>> > Adds display timing node for a DP panel to Arndale Board DTS file
>> >
>> > Signed-off-by: Vikas Sa
66 matches
Mail list logo
