Am 23.09.2013 21:50, schrieb Alex Deucher:
When dpm was merged, I added a new asic struct for
rv6xx, but it never got properly updated when the
hdmi callbacks were added due to the two patch sets
being developed in parallel.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=69729
Signed-off-b
On Thu, 19 Sep 2013, Russell King wrote:
> The correct way for a driver to specify the coherent DMA mask is
> not to directly access the field in the struct device, but to use
> dma_set_coherent_mask(). Only arch and bus code should access this
> member directly.
>
> Convert all direct write acc
On Mon, Sep 23, 2013 at 02:27:39PM -0400, Alan Stern wrote:
> On Thu, 19 Sep 2013, Russell King wrote:
>
> > The correct way for a driver to specify the coherent DMA mask is
> > not to directly access the field in the struct device, but to use
> > dma_set_coherent_mask(). Only arch and bus code s
Hi,
That looks quite strange. I guess the kernel should map the ROM at the
address OpenBoot/OF assigned to it. ( 1002 ).
Are pci devices located beneatch pci@1f,0 not reserving resources
correctly ? (Thus the reuse of addresses when the addresses are
assigned during runtime ? or is there some
From: Kjetil Oftedal
Date: Mon, 23 Sep 2013 21:06:11 +0200
> That looks quite strange. I guess the kernel should map the ROM at the
> address OpenBoot/OF assigned to it. ( 1002 ).
The address you see is a raw physical I/O address, which is a concatenation
of the I/O window physical address f
From: mr...@linux.ee
Date: Tue, 24 Sep 2013 00:14:41 +0300 (EEST)
>> > That looks quite strange. I guess the kernel should map the ROM at the
>> > address OpenBoot/OF assigned to it. ( 1002 ).
>>
>> The address you see is a raw physical I/O address, which is a concatenation
>> of the I/O wind
On 09/23/2013 05:33 PM, Maarten Lankhorst wrote:
Hey,
Op 13-09-13 11:00, Peter Zijlstra schreef:
On Fri, Sep 13, 2013 at 10:41:54AM +0200, Daniel Vetter wrote:
On Fri, Sep 13, 2013 at 10:29 AM, Peter Zijlstra wrote:
On Fri, Sep 13, 2013 at 09:46:03AM +0200, Thomas Hellstrom wrote:
if (!bo_t
Op 24-09-13 09:22, Thomas Hellstrom schreef:
> On 09/23/2013 05:33 PM, Maarten Lankhorst wrote:
>> Hey,
>>
>> Op 13-09-13 11:00, Peter Zijlstra schreef:
>>> On Fri, Sep 13, 2013 at 10:41:54AM +0200, Daniel Vetter wrote:
On Fri, Sep 13, 2013 at 10:29 AM, Peter Zijlstra
wrote:
> On Fr
The | operation has higher precedence than "?:" so the macro always
returns GT_RENDER_L3_PARITY_ERROR_INTERRUPT_S1.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c4f9bef..87b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++
On Tue, 24 Sep 2013, Dan Carpenter wrote:
> The | operation has higher precedence than "?:" so the macro always
> returns GT_RENDER_L3_PARITY_ERROR_INTERRUPT_S1.
>
> Signed-off-by: Dan Carpenter
Reviewed-by: Jani Nikula
Introduced in
commit 35a85ac60618521d41cfdb14f3fbfc8ad7329e9e
Author: Ben
On 09/24/2013 09:34 AM, Maarten Lankhorst wrote:
Op 24-09-13 09:22, Thomas Hellstrom schreef:
On 09/23/2013 05:33 PM, Maarten Lankhorst wrote:
Hey,
Op 13-09-13 11:00, Peter Zijlstra schreef:
On Fri, Sep 13, 2013 at 10:41:54AM +0200, Daniel Vetter wrote:
On Fri, Sep 13, 2013 at 10:29 AM, Pete
On Mon, Sep 23, 2013 at 09:39:28PM +0300, Ville Syrjälä wrote:
> On Mon, Sep 23, 2013 at 03:57:40PM +0100, Damien Lespiau wrote:
> > Some stereo modes, like frame packing, need a larger CRTC viewport than
> > the "natural" underlying 2D mode and thus drm_crtc_check_viewport()
> > needs to query the
On Tue, Sep 24, 2013 at 11:22:56AM +0300, Jani Nikula wrote:
> On Tue, 24 Sep 2013, Dan Carpenter wrote:
> > The | operation has higher precedence than "?:" so the macro always
> > returns GT_RENDER_L3_PARITY_ERROR_INTERRUPT_S1.
> >
> > Signed-off-by: Dan Carpenter
>
> Reviewed-by: Jani Nikula
On Tue, Sep 24, 2013 at 11:03:37AM +0200, Thomas Hellstrom wrote:
> On 09/24/2013 09:34 AM, Maarten Lankhorst wrote:
> >Op 24-09-13 09:22, Thomas Hellstrom schreef:
> >>On 09/23/2013 05:33 PM, Maarten Lankhorst wrote:
> >>>Hey,
> >>>
> >>>Op 13-09-13 11:00, Peter Zijlstra schreef:
> On Fri, Sep
Op 24-09-13 11:03, Thomas Hellstrom schreef:
> On 09/24/2013 09:34 AM, Maarten Lankhorst wrote:
>> Op 24-09-13 09:22, Thomas Hellstrom schreef:
>>> On 09/23/2013 05:33 PM, Maarten Lankhorst wrote:
Hey,
Op 13-09-13 11:00, Peter Zijlstra schreef:
> On Fri, Sep 13, 2013 at 10:41:54A
Op 24-09-13 11:36, Daniel Vetter schreef:
> On Tue, Sep 24, 2013 at 11:03:37AM +0200, Thomas Hellstrom wrote:
>> On 09/24/2013 09:34 AM, Maarten Lankhorst wrote:
>>> Op 24-09-13 09:22, Thomas Hellstrom schreef:
On 09/23/2013 05:33 PM, Maarten Lankhorst wrote:
> Hey,
>
> Op 13-09-13
On Mon, Sep 23, 2013 at 02:48:09PM +0100, Damien Lespiau wrote:
> drm_helper_probe_single_connector_modes() can be used to implement
> ->fill_modes(), not ->probe().
>
> Signed-off-by: Damien Lespiau
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_crtc_helper.c | 6 +++---
> 1 file chan
On 09/24/2013 12:11 PM, Maarten Lankhorst wrote:
Op 24-09-13 11:36, Daniel Vetter schreef:
On Tue, Sep 24, 2013 at 11:03:37AM +0200, Thomas Hellstrom wrote:
On 09/24/2013 09:34 AM, Maarten Lankhorst wrote:
Op 24-09-13 09:22, Thomas Hellstrom schreef:
On 09/23/2013 05:33 PM, Maarten Lankhorst
> >> > That looks quite strange. I guess the kernel should map the ROM at the
> >> > address OpenBoot/OF assigned to it. ( 1002 ).
> >>
> >> The address you see is a raw physical I/O address, which is a concatenation
> >> of the I/O window physical address for that PCI controller and the
> >>
https://bugs.freedesktop.org/show_bug.cgi?id=59649
--- Comment #17 from Shawn Starr ---
It seems I can cause the GPU reset with Firefox and scrolling pages, but after
keeping DPM on for 2 days.
It would be good if the dri or drm had a way to capture the commands being
submitted to the GPU so we
https://bugs.freedesktop.org/show_bug.cgi?id=59649
--- Comment #18 from Shawn Starr ---
GPU reset: 3.12.0-0.rc1.git4.2.fc21.x86_64
[73351.965375] switching to power state:
[73351.965376] ui class: performance
[73351.965378] internal class: none
[73351.965380] caps: single_disp video
[73351.96
Op 24-09-13 12:33, Thomas Hellstrom schreef:
> On 09/24/2013 12:11 PM, Maarten Lankhorst wrote:
>> Op 24-09-13 11:36, Daniel Vetter schreef:
>>> On Tue, Sep 24, 2013 at 11:03:37AM +0200, Thomas Hellstrom wrote:
On 09/24/2013 09:34 AM, Maarten Lankhorst wrote:
> Op 24-09-13 09:22, Thomas He
This series adds runtime pm support for host1x, gr2d and dc. It retains the
current behaviour if CONFIG_PM_RUNTIME is not enabled.
The gr2d clock is enabled when a new job is submitted and disabled when
the work is done. Due to parent->child relations between host1x->gr2d, this
scheme enables and
From: Mayuresh Kulkarni
This far we have enabled gr2d clock on device probe and disabled
it on device deinitialisation. This patch adds runtime pm support
for the hardware unit allowing dynamic power management. If pm
runtime is not enabled, gr2d clock is enabled in device probe and
disabled in r
From: Mayuresh Kulkarni
This patch adds runtime pm support for host1x hardware unit. This
allows host1x clock to be turned off when it is idle. If pm runtime
is not configured, we enable host1x clock in device probe and disable
it in remove.
Signed-off-by: Mayuresh Kulkarni
Signed-off-by: Arto
From: Mayuresh Kulkarni
This patch moves function host1x_job_submit() to job.c file where
all other host1x_job_* functions are placed. This patch also
introduces function host1x_job_complete().
Signed-off-by: Mayuresh Kulkarni
Signed-off-by: Arto Merilainen
---
drivers/gpu/host1x/cdma.c|
From: Mayuresh Kulkarni
This patch adds initial runtime pm support for Tegra display
controller. As of now, the dc clock is enabled in device probe via
runtime pm and disabled in device remove. In case pm runtime is not
configured, we simply enable the clock in device probe (..and disable
it in r
https://bugs.freedesktop.org/show_bug.cgi?id=69729
--- Comment #15 from Alex Deucher ---
Probably best to bisect and manually apply attachment 86417 before testing each
step.
--
You are receiving this mail because:
You are the assignee for the bug.
__
https://bugs.freedesktop.org/show_bug.cgi?id=69728
--- Comment #5 from Alex Deucher ---
You might also try:
R600_DEBUG=nodma
or
R600_DEBUG=nosb
Also did you build mesa with opencl or llvm support? If so, does disabling
llvm help?
R600_LLVM=0
--
You are receiving this mail because:
You are th
Missing ULL when calculating the amount of vram
leads to an overflow when the amount of vram is >= 4G.
Signed-off-by: Alex Deucher
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/radeon/cik.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/cik.c b/dr
https://bugs.freedesktop.org/show_bug.cgi?id=69728
--- Comment #6 from pablow.1...@gmail.com ---
Created attachment 86456
--> https://bugs.freedesktop.org/attachment.cgi?id=86456&action=edit
Mesa compile flags
It looks like it was compiled against llvm (I use standard Fedora 20 packages,
this b
Emil Velikov writes:
> Documentation states that AC_*_IFELSE has to use AC_LANG_SOURCE or
> friends in order to generate the source code to compile.
> AC_LINK_IFELSE already handles this, thus convert AC_COMPILE_IFELSE
> to silence the final autoconf warnings.
>
> Signed-off-by: Emil Velikov
Pu
On 09/24/2013 01:32 PM, Maarten Lankhorst wrote:
Op 24-09-13 12:33, Thomas Hellstrom schreef:
On 09/24/2013 12:11 PM, Maarten Lankhorst wrote:
It seems userspace only updates offset and domain in nouveau. If it fails to
update
it would result in the same affect as when the buffer gets moved a
https://bugzilla.kernel.org/show_bug.cgi?id=61811
Bjorn Helgaas changed:
What|Removed |Added
CC||bhelg...@google.com
Component|PC
[+cc Dave]
On Mon, Sep 23, 2013 at 12:33 PM, Bjorn Helgaas wrote:
> [+cc linux-pci, linux-kernel, dri-devel]
>
> On Sat, Sep 21, 2013 at 11:39 AM,
> wrote:
>> https://bugzilla.kernel.org/show_bug.cgi?id=61811
>>
>> Bug ID: 61811
>>Summary: kms mode breaks and using rade
On 09/24/2013 11:43 AM, Maarten Lankhorst wrote:
Op 24-09-13 11:03, Thomas Hellstrom schreef:
On 09/24/2013 09:34 AM, Maarten Lankhorst wrote:
Op 24-09-13 09:22, Thomas Hellstrom schreef:
Actually, it's not the locking order bo:reserve -> mmap_sem that triggers the
lockdep warning, right? but
https://bugzilla.kernel.org/show_bug.cgi?id=61811
Alex Deucher changed:
What|Removed |Added
CC||alexdeuc...@gmail.com
--- Comment #6 from
https://bugzilla.kernel.org/show_bug.cgi?id=61811
--- Comment #7 from Bruno Wolff III ---
It will go slow, as I'll only be able to do about one build a day as I have
pretty old hardware. It will also be slow getting started as I haven't tried it
before and I'll need to figure out the workflow. On
https://bugs.freedesktop.org/show_bug.cgi?id=68178
--- Comment #6 from n...@detonation.org ---
It seems like I have two independent problems which may explain the confusing
results I got:
* with DPM enabled I get hard locks on suspend and sometimes on resume. After
suspend I have to turn off powe
https://bugs.freedesktop.org/show_bug.cgi?id=68178
--- Comment #7 from n...@detonation.org ---
Created attachment 86476
--> https://bugs.freedesktop.org/attachment.cgi?id=86476&action=edit
Xorg.0.log after X server crash after resume
--
You are receiving this mail because:
You are the assignee
https://bugs.freedesktop.org/show_bug.cgi?id=68178
n...@detonation.org changed:
What|Removed |Added
Attachment #84144|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=68178
--- Comment #9 from Alex Deucher ---
THe only thing that has changed in the ucode is adding new ucode for UVD and
SMC. If you use the newer firmware package but remove the UVD and/or SMC ucode
images, you should get the same behavior as with the
https://bugzilla.kernel.org/show_bug.cgi?id=61811
Dieter Nützel changed:
What|Removed |Added
CC||die...@nuetzel-hh.de
--- Comment #8 from
https://bugzilla.kernel.org/show_bug.cgi?id=61811
--- Comment #9 from Dieter Nützel ---
Created attachment 109551
--> https://bugzilla.kernel.org/attachment.cgi?id=109551&action=edit
dmesg-3.12-rc2-agpmode-1.log
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=61811
Dieter Nützel changed:
What|Removed |Added
Attachment #109551|application/octet-stream|text/plain
mime type|
https://bugzilla.kernel.org/show_bug.cgi?id=61811
--- Comment #10 from Alex Deucher ---
(In reply to Dieter Nützel from comment #8)
> (In reply to Alex Deucher from comment #6)
> > Can you bisect?
>
> Hello Alex,
>
> I'll try 'cause I get the same with clean 3.12-rc2 +
> 0001-drm-radeon-avoid-U
https://bugs.freedesktop.org/show_bug.cgi?id=69694
--- Comment #11 from Marco ---
All is compiled with --enable-glx-tls.
No more ideas...
I'm attaching latest try with xorg.conf and backtrace.
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freedesktop.org/show_bug.cgi?id=69694
--- Comment #12 from Marco ---
Created attachment 86481
--> https://bugs.freedesktop.org/attachment.cgi?id=86481&action=edit
xorg.conf
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freedesktop.org/show_bug.cgi?id=69694
--- Comment #13 from Marco ---
Created attachment 86482
--> https://bugs.freedesktop.org/attachment.cgi?id=86482&action=edit
Backtrace of crash
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=61811
--- Comment #11 from Bruno Wolff III ---
I believe it was after d5d04bb and up to 3711d86. There weren't any radeon
changes in that range that I noticed when I read through the git whatchanged
output. It's possible that some patch was added or rem
https://bugzilla.kernel.org/show_bug.cgi?id=61811
--- Comment #12 from Dieter Nützel ---
(In reply to Alex Deucher from comment #10)
> (In reply to Dieter Nützel from comment #8)
> > (In reply to Alex Deucher from comment #6)
> > > Can you bisect?
> >
> > Hello Alex,
> >
> > I'll try 'cause I g
https://bugs.freedesktop.org/show_bug.cgi?id=68178
--- Comment #10 from n...@detonation.org ---
Indeed! After removing CYPRESS_uvd.bin the X server crashes vanish. Only the
hard locks with dpm remain.
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugzilla.kernel.org/show_bug.cgi?id=61811
--- Comment #13 from Bruno Wolff III ---
Kernel kernel-PAE-3.12.0-0.rc0.git22.2.fc21.i686 which worked for me was based
off commit d5d04bb. The next kernel which didn;t work
(kernel-PAE-3.12.0-0.rc0.git24.1.fc21.i686) was based on commit 3711d86.
https://bugs.freedesktop.org/show_bug.cgi?id=69689
--- Comment #3 from Ian Romanick ---
(In reply to comment #1)
> Make sure you set --enable-texture-float when configuring mesa.
It should be since the driver is advertising OpenGL 3.0.
--
You are receiving this mail because:
You are the assign
https://bugs.freedesktop.org/show_bug.cgi?id=69775
Priority: medium
Bug ID: 69775
Assignee: dri-devel@lists.freedesktop.org
Summary: [r600g] RV730 AGP UVD hang (GPU lockup) with mplayer
on dual DVI display with 3.12-rc2
Sever
https://bugs.freedesktop.org/show_bug.cgi?id=69775
--- Comment #1 from Dieter Nützel ---
Created attachment 86489
--> https://bugs.freedesktop.org/attachment.cgi?id=86489&action=edit
Xorg.0.log
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freedesktop.org/show_bug.cgi?id=69729
--- Comment #16 from Paul Bodenbenner ---
Compiled 3.11-rc4 including your attached patch and HDMI audio seems to be
working fine.
Compiling rc6 now...
--
You are receiving this mail because:
You are the assignee for the bug.
__
https://bugs.freedesktop.org/show_bug.cgi?id=69775
Dieter Nützel changed:
What|Removed |Added
Attachment #86489|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=69729
--- Comment #17 from Paul Bodenbenner ---
Interesting..., rc6 has the bug already.
Let's see if rc5 is still working...
--
You are receiving this mail because:
You are the assignee for the bug.
___
dr
https://bugs.freedesktop.org/show_bug.cgi?id=69723
--- Comment #2 from Alexandre Demers ---
It doesn't seem to be one of these, it still happens. While it is not always
related to a change in power state, I do experience it more often when I'm
launching games or just after I hear the fan accelera
https://bugs.freedesktop.org/show_bug.cgi?id=68235
Alexandre Demers changed:
What|Removed |Added
See Also||https://bugs.freedesktop.or
https://bugs.freedesktop.org/show_bug.cgi?id=69723
Alexandre Demers changed:
What|Removed |Added
See Also||https://bugs.freedesktop.or
https://bugs.freedesktop.org/show_bug.cgi?id=69723
--- Comment #3 from Alexandre Demers ---
I'll try playing with patch 85578, which was the same thing as this patch with
a bit more. I'm pretty sure we are hitting something wrong again with mclk, but
in a different case than the one fixed in bug
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/intel_display.c between commit 67c72a122541
("drm/i915: preserve pipe A quirk in i9xx_set_pipeconf") from the
drm-intel-fixes tree and commit cf532bb25592 ("drm/i915: Move double wide
mode handling into p
On Mon, Sep 23, 2013 at 12:14 AM, Michael S. Tsirkin wrote:
> On Mon, Aug 26, 2013 at 04:05:11PM +0300, Michael S. Tsirkin wrote:
>> On Wed, Aug 21, 2013 at 11:22:58AM +0200, Sedat Dilek wrote:
>> > [ Re: [Intel-gfx] i915 producing warnings with kernel 3.11-rc5 ]
>> >
>> > Hi,
>> >
>> > saw your p
> -Original Message-
> From: Inki Dae [mailto:inki@samsung.com]
> Sent: Tuesday, September 24, 2013 1:41 PM
> To: 'Al Viro'
> Cc: 'YoungJun Cho'; 'dri-devel@lists.freedesktop.org'
> Subject: RE: [RFC] deadlock in "drm/exynos: fix wrong pointer access at vm
> close"
>
> Thanks for you
https://bugs.freedesktop.org/show_bug.cgi?id=69790
Priority: medium
Bug ID: 69790
Assignee: dri-devel@lists.freedesktop.org
Summary: [HSW ULT] testdisplay : The output of 720x576 mode is
dislocated
Severity: major
Classi
https://bugs.freedesktop.org/show_bug.cgi?id=69790
--- Comment #1 from Qingshuai Tian ---
Created attachment 86504
--> https://bugs.freedesktop.org/attachment.cgi?id=86504&action=edit
The dislocated picture
--
You are receiving this mail because:
You are the assignee for the bug.
68 matches
Mail list logo
