On Mon, Jan 07, 2013 at 06:23:54AM +, Mohammed, Afzal wrote:
> Hi Steffen,
>
> On Tue, Dec 18, 2012 at 22:34:09, Steffen Trumtrar wrote:
>
> > Finally, right in time before the end of the world on friday, v16 of the
> > display helpers.
>
> After another big bang, your series in the previous
Hi Steffen,
On Tue, Dec 18, 2012 at 22:34:09, Steffen Trumtrar wrote:
> Finally, right in time before the end of the world on friday, v16 of the
> display helpers.
After another big bang, your series in the previous world was tried ;)
This series has been tested on DA850 EVM, AM335x EVM, EVM-SK
Hi Steffen,
On Tue, Dec 18, 2012 at 22:34:14, Steffen Trumtrar wrote:
> Add helper to get fb_videomode from devicetree.
> drivers/video/fbmon.c | 42 ++
> include/linux/fb.h|4
This breaks DaVinci (da8xx_omapl_defconfig), following change wa
From: Sean Paul
This patch programs the core and timing generator registers using the
timing data provided in drm_display_mode and not using hard-coded
configurations.
Additional PHY configs has been added. This allows us to support more
permissible resolutions and refresh rates.
Signed-off-by:
With this patch, mixer driver find the correct resolution mode for
the range of resolutions, upto 1080 vertical lines. Resolution will
be categorized to NTSC SD, PAL SD or HD and the correct mode is
set to the mixer configuration register.
Signed-off-by: Rahul Sharma
Signed-off-by: Sean Paul
---
This patch adds the implementation of check_timing callback in the mixer
driver. Based on the mixer version, correct set of restrictions will be
exposed by the mixer driver. A resolution will be acceptable only if passes
the criteria set by mixer and hdmi IPs.
Signed-off-by: Rahul Sharma
Signed-o
This patch adds the display mode check operation to exynos_mixer_ops
in drm-common-hdmi. In Exynos SoCs, mixer IP can put certain restrictions
on the proposed display modes. These restriction needs to be considered
during mode negotiation, which happens immediately after edid parsing.
Both, mixer
This patch set adds support for more resolutions and refresh rates to Samsung
Exynos5 SoC series which contains hdmi transmitter (hdmi v1.4a compliant).
Given resolution will be supported or not, is decided by two factors:
1) Corresponding pixel clock is supported by hdmi PHY.
2) Mixer supports th
Hello Alex,
I've bisected the change that fixed the problem. I wanted to make
sure it wasn't some random change. The good news is that it wasn't!
The winner is:
commit 909d9eb67f1e4e39f2ea88e96bde03d560cde3eb
Author: Alex Deucher
Date: Wed Jan 2 18:30:21 2013 -0500
drm/radeon/r6xx:
In ttm_write_lock(), for the interruptible sleep, the __ttm_write_lock()
is used as the sleep predicate. On the other hand, for the
uninterruptible case, __ttm_read_lock() is evaluated. It seems that
the code was not changed since the initial import at the end of 2009.
Shouldn't both cases use the
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/20130106/ef5c2765/attachment.html>
Applied.
Thanks,
Inki Dae
2013/1/3 Rahul Sharma :
> This patch implements the exynos_drm_crtc_finish_pageflip in
> exynos_drm_crtc.c. This avoids the duplication of same code
> in mixer, fimd and vidi.
>
> Signed-off-by: Rahul Sharma
> Signed-off-by: Stephane Marchesin
> ---
> This patch is bas
e the same __ttm_write_lock() ?
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130106/6b123886/attachment-0001.pgp>
2012/12/27 Prathyush K :
> If fimd is runtime suspended (by DPMS OFF), fimd_suspend does not
> call fimd_activate(false) and just returns. Similarily the check in
Right and that is our intension. pm suspend should be ignored because
fimd already became off.
And if we want for fimd to be pm suspend
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130106/d82201f5/attachment.html>
||g/show_bug.cgi?id=58667
--
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/20130106/15190
||g/show_bug.cgi?id=59089
--
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/20130106/21a00
bug 58667.
--
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/20130106/42d7b486/attachment.html>
even games that support setting AA
cannot do it themselves.
--
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/20130106/45e34927/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130106/4c39805e/attachment.html>
On Thu, Jan 03, 2013 at 06:11:23PM -0500, J. Bruce Fields wrote:
> On Thu, Jan 03, 2013 at 04:16:24PM -0500, Josh Boyer wrote:
> > On Thu, Jan 3, 2013 at 3:46 PM, J. Bruce Fields
> > wrote:
> > > I got a crash after a few minutes of running 3.8.0-rc2, was able to
> > > switch to a vt and look at
On Sat, Jan 05, 2013 at 03:21:27PM +0100, Christian K?nig wrote:
> [SNIP]
>
> On 05.01.2013 00:42, Alex Deucher wrote:
> >R6xx and r7xx are really all you need to worry about in this case.
> >R1xx-r5xx UMS uses a different kernel interface for command submission
> >and evergreen and later don't ha
On Thu, Dec 27, 2012 at 09:57:25AM -0600, Rob Clark wrote:
> On Mon, Dec 24, 2012 at 11:09 AM, Laurent Pinchart
> wrote:
> > On the topic of discussions, would anyone be interested in a
> > BoF/brainstorming/whatever session during the FOSDEM ?
>
> I will be at FOSDEM.. and from http://wiki.x.org
https://bugs.freedesktop.org/show_bug.cgi?id=58840
--- Comment #6 from Marek Olšák ---
(In reply to comment #5)
> Couldn't set 1280x960 OpenGL video mode: Couldn't find matching GLX visual
> on the next startup.
If you want MSAA GLX visuals, you must *install* the gallium driver and restart
the
From: Christian K?nig
KMS support is out and stable for a couple of years now and
the userspace code has deprecated or abandoned the old UMS interface.
So make the KMS interface the default and deprecate the UMS interface
in the kernel as well.
Signed-off-by: Christian K?nig
---
drivers/gpu/d
Hello Alex,
I've bisected the change that fixed the problem. I wanted to make
sure it wasn't some random change. The good news is that it wasn't!
The winner is:
commit 909d9eb67f1e4e39f2ea88e96bde03d560cde3eb
Author: Alex Deucher
Date: Wed Jan 2 18:30:21 2013 -0500
drm/radeon/r6xx:
https://bugs.freedesktop.org/show_bug.cgi?id=58840
--- Comment #5 from almos ---
Cogs also works, sort of. It has to be started with the __GL_FSAA_MODE=4 env
var *and* antialias must be enabled in the options menu to see AA. However, it
cannot start this way, it says
Couldn't set 1280x960 OpenGL
Hi Alex,
Commit 0ecebb9e0d14e9948e0b1529883a776758117d6f "drm/radeon: switch to a
finer grained reset for evergreen" introduced a hard system lockup to my
setup. I found it after bisecting, and confirmed it by reverting it on
the latest mainline ( 5f243b9 ).
This:
echo 7 >
/sys/devices/p
https://bugs.freedesktop.org/show_bug.cgi?id=58667
--- Comment #29 from Alexandre Demers ---
I just created a new bug (bug 59089) for the GPU fault flood which is not a
direct link with the crashes, the first happening without the other.
--
You are receiving this mail because:
You are the assig
https://bugs.freedesktop.org/show_bug.cgi?id=58667
Alexandre Demers changed:
What|Removed |Added
See Also||https://bugs.freedesktop.or
https://bugs.freedesktop.org/show_bug.cgi?id=59089
Alexandre Demers changed:
What|Removed |Added
See Also||https://bugs.freedesktop.or
https://bugs.freedesktop.org/show_bug.cgi?id=59089
Priority: medium
Bug ID: 59089
Assignee: dri-devel@lists.freedesktop.org
Summary: [bisected, regression] flood of GPU fault detected in
logs caused by 9af20... drm/radeon: fix fence lo
https://bugs.freedesktop.org/show_bug.cgi?id=58840
--- Comment #4 from almos ---
Now I tried again with updated mesa (git-8ed6b14). Now glxgears, sauerbraten,
ut2004 (32bit), fgfs (when did 3d clouds become such a performance killer?) are
fine. Neverball still flashes garbage. Nexuiz is 3fps with
https://bugs.freedesktop.org/show_bug.cgi?id=55172
Marek Olšák changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Thu, Jan 03, 2013 at 06:11:23PM -0500, J. Bruce Fields wrote:
> On Thu, Jan 03, 2013 at 04:16:24PM -0500, Josh Boyer wrote:
> > On Thu, Jan 3, 2013 at 3:46 PM, J. Bruce Fields
> > wrote:
> > > I got a crash after a few minutes of running 3.8.0-rc2, was able to
> > > switch to a vt and look at
On Sat, Jan 05, 2013 at 03:21:27PM +0100, Christian König wrote:
> [SNIP]
>
> On 05.01.2013 00:42, Alex Deucher wrote:
> >R6xx and r7xx are really all you need to worry about in this case.
> >R1xx-r5xx UMS uses a different kernel interface for command submission
> >and evergreen and later don't ha
On Thu, Dec 27, 2012 at 09:57:25AM -0600, Rob Clark wrote:
> On Mon, Dec 24, 2012 at 11:09 AM, Laurent Pinchart
> wrote:
> > On the topic of discussions, would anyone be interested in a
> > BoF/brainstorming/whatever session during the FOSDEM ?
>
> I will be at FOSDEM.. and from http://wiki.x.org
From: Christian König
KMS support is out and stable for a couple of years now and
the userspace code has deprecated or abandoned the old UMS interface.
So make the KMS interface the default and deprecate the UMS interface
in the kernel as well.
Signed-off-by: Christian König
---
drivers/gpu/d
:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130106/93285750/attachment-0001.html>
Hello, Alex!
Sorry for delay with the reply! It turns out I made a huge blunder
while bisecting. I assumed that the radeon drivers would load from
lib/modules, so I didn't bother running "make install" once I saw that
only the modules are recompiled. In fact, the video modules were
loa
Not sure if it is a kernel issue or user-space. Truth is probably
somewhere in the middle. It popped up moving to 3.8-rc1 using nouveau.
Using nvidia's driver works fine. With nouveau, after entering login
credentials in lightDM the user session does not start and I am back at
the lightDM login scr
On 01/03/2013 08:12 PM, Marcin Slusarz wrote:
On Thu, Jan 03, 2013 at 01:58:10PM +0100, Marcin Slusarz wrote:
I bisected the problem down to this commit:
186ecad21: drm/nv50/disp: move remaining interrupt handling into core
Hardware is 8400M GS (10de:0427) in a Dell XPS M1330.
There's already
On Fri, Jan 4, 2013 at 8:53 AM, Rahul Sharma wrote:
> This patch adds the display mode check operation to exynos_mixer_ops
> in drm-common-hdmi. In Exynos SoCs, mixer IP can put certain restrictions
> on the proposed display modes. These restriction needs to be considered
> during mode negotiation
From: Sean Paul
This patch programs the core and timing generator registers using the
timing data provided in drm_display_mode and not using hard-coded
configurations.
Additional PHY configs has been added. This allows us to support more
permissible resolutions and refresh rates.
Signed-off-by:
With this patch, mixer driver find the correct resolution mode for
the range of resolutions, upto 1080 vertical lines. Resolution will
be categorized to NTSC SD, PAL SD or HD and the correct mode is
set to the mixer configuration register.
Signed-off-by: Rahul Sharma
Signed-off-by: Sean Paul
---
This patch adds the implementation of check_mode callback in the mixer
driver. Based on the mixer version, correct set of restrictions will be
exposed by the mixer driver. A resolution will be acceptable only if passes
the criteria set by mixer and hdmi IPs.
Signed-off-by: Rahul Sharma
Signed-off
This patch adds the display mode check operation to exynos_mixer_ops
in drm-common-hdmi. In Exynos SoCs, mixer IP can put certain restrictions
on the proposed display modes. These restriction needs to be considered
during mode negotiation, which happens immediately after edid parsing.
Both, mixer
This patch set adds support for more resolutions and refresh rates to Samsung
Exynos5 SoC series which contains hdmi transmitter (hdmi v1.4a compliant).
Given resolution will be supported or not, is decided by two factors:
1) Corresponding pixel clock is supported by hdmi PHY.
2) Mixer supports th
There's no need to allocate edid twice and do a memcpy when drm helpers
exist to do just that. This patch cleans that interaction up, and
doesn't keep the edid hanging around in the connector.
v4:
- removed error check for drm_mode_connector_update_edid_property
which is expected to fail for Virtu
(Please CC me on replies, I'm not subscribed.)
Since linux kernel version 3.7(.1), whenever I have already turned my
monitor off and the X server's dpms settings engages after the timeout,
I get the following:
[245917.595824] [ cut here ]
[245917.595837] WARNING: at driver
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/20130106/5a61afde/attachment.html>
51 matches
Mail list logo
