Hi Dave,
The below patch, "add support for ARCH_MULTIPLATFORM", makes exynos
drm driver to be complied for testing on different ARM DRM devices
without having to switch configs.
For this, you can refer to below link.
http://www.spinics.net/lists/dri-devel/msg29365.html
And thi
On Thu, Nov 01, 2012 at 12:03:39AM +0200, Imre Deak wrote:
> drm_vblank_off() requires callers to hold the event_lock.
>
> Signed-off-by: Imre Deak
Hm, do we put this code through its paces already in flip_test by
scheduling a vblank wait in the future (a second or so), and then
disabling the di
on or cursor, but I think those should be disabled
when we disable mem requests in the crtc. Does this patch help?
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freede
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121031/2a2a8d63/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20121031/cde94182/attachment-0001.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20121031/ba7a1902/attachment.html>
nts/20121031/149123b4/attachment.html>
hat do you think?
I can test and investigate 1, 3 and 4. But what about 2?
--
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/20
Hi Steffen,
Thanks for the patch.
On Wednesday 31 October 2012 10:28:04 Steffen Trumtrar wrote:
> Add helper functions to convert from display timings to a generic videomode
> structure. This videomode can then be converted to the corresponding
> subsystem mode representation (e.g. fb_videomode).
Hi Steffen,
One more comment.
On Wednesday 31 October 2012 10:28:01 Steffen Trumtrar wrote:
> Add display_timing structure and the according helper functions. This allows
> the description of a display via its supported timing parameters.
>
> Every timing parameter can be specified as a single v
Hi Steffen,
Thanks for the patch.
As we'll need a v8 anyway due to the comment on patch 5/8, here are a couple
of other small comments.
On Wednesday 31 October 2012 10:28:01 Steffen Trumtrar wrote:
> Add display_timing structure and the according helper functions. This allows
> the description
please ?
--
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/20121031/4af8b32d/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121031/9de0c92c/attachment.html>
alexdeucher at gmail.com writes:
> From: Alex Deucher
>
> The R200 asics use an external DAC for the secondary DAC.
> The current KMS code tries to use code for the integrated
> TV DAC for R200 which leads to unpredictable results since
> R200 does not have an integrated TV DAC. This patch
Hi Prakash!
On Wed, Oct 31, 2012 at 03:30:03PM +, Manjunathappa, Prakash wrote:
> Hi Steffen,
>
> On Wed, Oct 31, 2012 at 14:58:05, Steffen Trumtrar wrote:
> > Add a function to convert from the generic videomode to a fb_videomode.
> >
> > Signed-off-by: Steffen Trumtrar
> > ---
> > driver
2012/10/31 Rahul Sharma :
> Removing the warning by adding proper type casting where local pointer
> variable of type mixer driver data is assigned with void pointer.
>
> This patch is based on branch exynos-drm-next at
> git://git.infradead.org/users/kmpark/linux-samsung
>
It's better to go to -f
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #9 from Alexandre Demers ---
(In reply to comment #8)
> Created attachment 69370 [details] [review]
> possible fix
>
> (In reply to comment #7)
> > Alex, would it be possible to print what is going on or if an error occurred
> > in e
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121031/2ff45c3c/attachment.html>
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121031/82890a13/attachment.html>
||
--
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/20121031/0516870f/attachment.html>
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121031/5cf787a6/attachment-0001.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20121031/87c7e189/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20121031/8174ea74/attachment.html>
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121031/38476b91/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121031/cec31d45/attachment.html>
of the cases we can use a common, simple HDMI monitor
driver, there could be HDMI monitors with special features. We could
detect this monitor by reading the EDID and if it's this special case,
use a specific driver for it instead of the common HDMI driver. This is
perhaps not very likely with HDMI, but I could imagine eDP panels with
special features.
So I imagine that we could use hot-plug here. The HDMI monitor device
would not exist until a HDMI cable is connected. The SoC's HDMI driver
(or whatever is before the HDMI monitor in the chain) gets a hotplug
interrupt, and it would then add the device, which would then trigger
probe of the corresponding HDMI monitor driver.
Actually, thinking about this, what I said in the above paragraph
wouldn't work. The SoC's HDMI driver can't know what kind of device to
create, unless we have a HDMI bus and HDMI devices. Which, I think, we
shouldn't have, as HDMI monitors are usually controlled via i2c, and
thus the HDMI monitors should be i2c devices.
So I don't really know how this hotplug would work =). It's just an
idea, not a scenario I have at hand.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 897 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121031/8fe83b42/attachment.pgp>
On 10/27/12 9:52 AM, Daniel Vetter wrote:
> This essentially reverts
>
> commit cb0953d734348e8862d6d7edc666cfb3bf6d8fae
> Author: Adam Jackson
> Date: Fri Jul 16 14:46:29 2010 -0400
>
> drm/i915: Initialize LVDS and eDP outputs before anything else
>
> simply because it doesn't scale: It m
On 10/27/12 9:52 AM, Daniel Vetter wrote:
> Userspace seems to like this, see
>
> commit cb0953d734348e8862d6d7edc666cfb3bf6d8fae
> Author: Adam Jackson
> Date: Fri Jul 16 14:46:29 2010 -0400
>
> drm/i915: Initialize LVDS and eDP outputs before anything else
>
> This makes them sort to
On Thu, Nov 01, 2012 at 12:03:39AM +0200, Imre Deak wrote:
> drm_vblank_off() requires callers to hold the event_lock.
>
> Signed-off-by: Imre Deak
Hm, do we put this code through its paces already in flip_test by
scheduling a vblank wait in the future (a second or so), and then
disabling the di
Hi Steffen,
On Wed, Oct 31, 2012 at 14:58:05, Steffen Trumtrar wrote:
> Add a function to convert from the generic videomode to a fb_videomode.
>
> Signed-off-by: Steffen Trumtrar
> ---
> drivers/video/fbmon.c | 36
> include/linux/fb.h|2 ++
> 2 f
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121031/9554bd96/attachment.html>
drm_vblank_off() requires callers to hold the event_lock.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_display.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b453901..56f1119 1
drm_vblank_off() requires callers to hold the event_lock, while itself
locking vbl_time and vblank_time_lock. This defines a dependency chain
that conflicts with the one in drm_handle_vblank() where we first lock
vblank_time_lock and then the event_lock. Fix this by reversing the
locking order in d
Hi Inki,
On Saturday 20 October 2012 22:10:17 Inki Dae wrote:
> Hi Laurent. sorry for being late.
No worries.
> 2012/8/17 Laurent Pinchart :
> > Hi everybody,
> >
> > While working on DT bindings for the Renesas Mobile SoC display controller
> > (a.k.a. LCDC) I quickly realized that display pan
Hi Tomi,
On Wednesday 19 September 2012 14:45:29 Tomi Valkeinen wrote:
> On Fri, 2012-08-17 at 02:49 +0200, Laurent Pinchart wrote:
> > Hi everybody,
> >
> > While working on DT bindings for the Renesas Mobile SoC display controller
> > (a.k.a. LCDC) I quickly realized that display panel implemen
ktop.org/archives/dri-devel/attachments/20121031/6ef38b89/attachment-0001.html>
et and then try and modprobe radeon manually from the console?
--
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/20121031/6e978823/attachment.html>
ee_PC#Specifications
[3] http://www.eee-forum.de/forum/viewtopic.php?f=13&t=427
--
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/attachme
On 10/27/12 9:52 AM, Daniel Vetter wrote:
This essentially reverts
commit cb0953d734348e8862d6d7edc666cfb3bf6d8fae
Author: Adam Jackson
Date: Fri Jul 16 14:46:29 2010 -0400
drm/i915: Initialize LVDS and eDP outputs before anything else
simply because it doesn't scale: It misses SDVO an
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121031/0b7706cd/attachment-0001.html>
On 10/27/12 9:52 AM, Daniel Vetter wrote:
Userspace seems to like this, see
commit cb0953d734348e8862d6d7edc666cfb3bf6d8fae
Author: Adam Jackson
Date: Fri Jul 16 14:46:29 2010 -0400
drm/i915: Initialize LVDS and eDP outputs before anything else
This makes them sort to the front in
||
--
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/20121031/e8c658b4/attachment.html>
ndering only garbage, so there is progress!
--
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/20121031/8ca9bb4c/attachment.html>
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #8 from Alex Deucher ---
Created attachment 69370
--> https://bugs.freedesktop.org/attachment.cgi?id=69370&action=edit
possible fix
(In reply to comment #7)
> Alex, would it be possible to print what is going on or if an error occu
From: Alex Deucher
The R200 asics use an external DAC for the secondary DAC.
The current KMS code tries to use code for the integrated
TV DAC for R200 which leads to unpredictable results since
R200 does not have an integrated TV DAC. This patch ports
the external DAC load detection support from
From: Alex Deucher
The R200 asics use an external DAC for the secondary DAC.
The current KMS code tries to use code for the integrated
TV DAC for R200 which leads to unpredictable results since
R200 does not have an integrated TV DAC. This patch ports
the external DAC load detection support from
https://bugs.freedesktop.org/show_bug.cgi?id=56592
--- Comment #4 from maxi...@free.fr ---
(In reply to comment #3)
> Which llvm version do you use ?
3.1
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing l
https://bugs.freedesktop.org/show_bug.cgi?id=56592
--- Comment #3 from vincent ---
Which llvm version do you use ?
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
htt
https://bugs.freedesktop.org/show_bug.cgi?id=56620
Alex Deucher changed:
What|Removed |Added
CC||maxi...@free.fr
--- Comment #4 from Alex
https://bugs.freedesktop.org/show_bug.cgi?id=56592
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #7 from Alexandre Demers ---
Alex, would it be possible to print what is going on or if an error occurred in
evergreen_mc_stop()?
I see four things that could be going on:
1- we are not using the right path for CAYMAN -> (ASIC_IS_DCE
I didn't bother with documenting the really trivial new "extract
something from dpcd" helpers, but the i2c over aux ch is now
documented a bit.
v2: Clarify the comment for i2c_dp_aux_add_bus a bit.
Signed-off-by: Daniel Vetter
---
Documentation/DocBook/drm.tmpl | 6 ++
drivers/gpu/drm/drm
Again only minimal changes to make kerneldoc no longer shout. Plus a
little introduction in the form of a inline DOC: section to quickly
explain what this is all about.
v2: Fixup spelling fail.
Signed-off-by: Daniel Vetter
---
Documentation/DocBook/drm.tmpl | 5 +
drivers/gpu/drm/drm_fb_h
- Add the missing doc for drm_helper_move_panel_connectors_to_head.
- Fixup any outdated stuff in existing sections. I've only looked at
those kerneldoc headers that actually resulted in a complaint from
the kerneldoc parser tool.
v2:
- Actually include the docbook snippet in the right patch.
https://bugs.freedesktop.org/show_bug.cgi?id=56620
--- Comment #3 from vincent ---
Do you use llvm 3.2-svn from here ? :
http://cgit.freedesktop.org/~tstellar/llvm/
If so, can you give the output of either etqw or furmark with the
R600_DUMP_SHADERS=1 envvar set, before and after the commit pleas
https://bugs.freedesktop.org/show_bug.cgi?id=56592
--- Comment #1 from maxi...@free.fr ---
Created attachment 69363
--> https://bugs.freedesktop.org/attachment.cgi?id=69363&action=edit
glxgears corrupted
--
You are receiving this mail because:
You are the assignee for the bug.
Add helper to get drm_display_mode from devicetree.
Signed-off-by: Steffen Trumtrar
---
drivers/gpu/drm/drm_modes.c | 42 ++
include/drm/drmP.h |5 +
2 files changed, 47 insertions(+)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/g
Add conversion from videomode to drm_display_mode
Signed-off-by: Steffen Trumtrar
---
drivers/gpu/drm/drm_modes.c | 36
include/drm/drmP.h |3 +++
2 files changed, 39 insertions(+)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm
Add helper to get fb_videomode from devicetree.
Signed-off-by: Steffen Trumtrar
---
drivers/video/fbmon.c | 40
include/linux/fb.h|3 +++
2 files changed, 43 insertions(+)
diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
index b9e6ab3
Add a function to convert from the generic videomode to a fb_videomode.
Signed-off-by: Steffen Trumtrar
---
drivers/video/fbmon.c | 36
include/linux/fb.h|2 ++
2 files changed, 38 insertions(+)
diff --git a/drivers/video/fbmon.c b/drivers/video/fb
Add helper functions to convert from display timings to a generic videomode
structure. This videomode can then be converted to the corresponding subsystem
mode representation (e.g. fb_videomode).
Signed-off-by: Steffen Trumtrar
---
drivers/video/Kconfig |6 ++
drivers/video/Makefile
Get videomode from devicetree in a format appropriate for the
backend. drm_display_mode and fb_videomode are supported atm.
Uses the display signal timings from of_display_timings
Signed-off-by: Philipp Zabel
Signed-off-by: Steffen Trumtrar
---
drivers/of/Kconfig |6 ++
driver
Signed-off-by: Steffen Trumtrar
---
.../devicetree/bindings/video/display-timings.txt | 139 +++
drivers/of/Kconfig |6 +
drivers/of/Makefile|1 +
drivers/of/of_display_timings.c| 185 ++
Add display_timing structure and the according helper functions. This allows
the description of a display via its supported timing parameters.
Every timing parameter can be specified as a single value or a range
.
Signed-off-by: Steffen Trumtrar
---
drivers/video/Kconfig |5 +++
dr
Hi!
Finally, v7 of the series.
Changes since v6:
- get rid of some empty lines etc.
- move functions to their subsystems
- split of_ from non-of_ functions
- add at least some kerneldoc to some functions
Regards,
Steffen
Steffen Trumtrar (8):
video: add displa
https://bugs.freedesktop.org/show_bug.cgi?id=56437
--- Comment #14 from maxi...@free.fr ---
(In reply to comment #12)
> Created attachment 69334 [details]
> Possible fix
>
> This is a strange bug. There must be a race condition somewhere. Does this
> patch help? If it doesn't, can you reproduc
Hi Steffen,
Thanks for the patch.
On Wednesday 31 October 2012 10:28:04 Steffen Trumtrar wrote:
> Add helper functions to convert from display timings to a generic videomode
> structure. This videomode can then be converted to the corresponding
> subsystem mode representation (e.g. fb_videomode).
I didn't bother with documenting the really trivial new "extract
something from dpcd" helpers, but the i2c over aux ch is now
documented a bit.
Signed-off-by: Daniel Vetter
---
Documentation/DocBook/drm.tmpl | 6 ++
drivers/gpu/drm/drm_dp_helper.c | 20
include/drm/drm
Again only minimal changes to make kerneldoc no longer shout. Plus a
little introduction in the form of a inline DOC: section to quickly
explain what this is all about.
Signed-off-by: Daniel Vetter
---
Documentation/DocBook/drm.tmpl | 5 +
drivers/gpu/drm/drm_fb_helper.c | 19 +
- Add the missing doc for drm_helper_move_panel_connectors_to_head.
- Fixup any outdated stuff in existing sections. I've only looked at
those kerneldoc headers that actually resulted in a complaint from
the kerneldoc parser tool.
Signed-off-by: Daniel Vetter
---
Documentation/DocBook/drm.tm
I'm devoting all my wrath to that fight, so don't misname it ;-)
Signed-off-by: Daniel Vetter
---
Documentation/DocBook/drm.tmpl | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index b030052..ca45155 100644
-
Hi Steffen,
One more comment.
On Wednesday 31 October 2012 10:28:01 Steffen Trumtrar wrote:
> Add display_timing structure and the according helper functions. This allows
> the description of a display via its supported timing parameters.
>
> Every timing parameter can be specified as a single v
https://bugs.freedesktop.org/show_bug.cgi?id=56620
--- Comment #2 from Laurent carlier ---
OpenGL renderer string: Gallium 0.4 on AMD BARTS
OpenGL version string: 3.0 Mesa 9.1-devel (git-5ab82e0)
OpenGL shading language version string: 1.30
with radeon HD6870
--
You are receiving this mail bec
Hi Steffen,
Thanks for the patch.
As we'll need a v8 anyway due to the comment on patch 5/8, here are a couple
of other small comments.
On Wednesday 31 October 2012 10:28:01 Steffen Trumtrar wrote:
> Add display_timing structure and the according helper functions. This allows
> the description
alexdeuc...@gmail.com writes:
> From: Alex Deucher
>
> The R200 asics use an external DAC for the secondary DAC.
> The current KMS code tries to use code for the integrated
> TV DAC for R200 which leads to unpredictable results since
> R200 does not have an integrated TV DAC. This patch por
2012/10/31 Greg KH :
> On Mon, Oct 29, 2012 at 09:31:13AM +0100, Rob Clark wrote:
>> From: Rob Clark
>>
>> Exynos does not seem to have any dependency on anything from
>> platform headers so just needs Kconfig updated to build in
>> ARCH_MULTIPLATFORM builds.
>>
>> Signed-off-by: Rob Clark
>> ---
=) Still I think there's some
value in making this consistent across all drivers and if everybody
agrees I'll volunteer to write the patch.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121031/a91f897c/attachment.pgp>
Hi Prakash!
On Wed, Oct 31, 2012 at 03:30:03PM +, Manjunathappa, Prakash wrote:
> Hi Steffen,
>
> On Wed, Oct 31, 2012 at 14:58:05, Steffen Trumtrar wrote:
> > Add a function to convert from the generic videomode to a fb_videomode.
> >
> > Signed-off-by: Steffen Trumtrar
> > ---
> > driver
https://bugs.freedesktop.org/show_bug.cgi?id=56620
Laurent carlier changed:
What|Removed |Added
Attachment #69356|text/plain |image/png
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=56620
--- Comment #1 from Laurent carlier ---
oups, with --enable-r600-llvm-compiler of course
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@
https://bugs.freedesktop.org/show_bug.cgi?id=56620
Laurent carlier changed:
What|Removed |Added
Summary|r600g: ETQW renders garbage |r600g: ETQW renders garbage
https://bugs.freedesktop.org/show_bug.cgi?id=50422
Laurent carlier changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Removing the warning by adding proper type casting where local pointer
variable of type mixer driver data is assigned with void pointer.
This patch is based on branch exynos-drm-next at
git://git.infradead.org/users/kmpark/linux-samsung
Signed-off-by: Rahul Sharma
---
drivers/gpu/drm/exynos/exy
https://bugs.freedesktop.org/show_bug.cgi?id=56620
Priority: medium
Bug ID: 56620
Assignee: dri-devel@lists.freedesktop.org
Summary: r600g: ETQW renders garbage with --enable-r600-llvm
Severity: normal
Classification: Unclassified
https://bugs.freedesktop.org/show_bug.cgi?id=50422
--- Comment #9 from Laurent carlier ---
The culprit for broken output is (after bisecting):
5ab82e0ccf84855e9311ebfc58d1b57b437ed991 is the first bad commit
commit 5ab82e0ccf84855e9311ebfc58d1b57b437ed991
Author: Vincent Lejeune
Date: Fri Oct
- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121031/908731f3/attachment.pgp>
init() actually modified the pointer.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121031/968f4478/attachment-0001.pgp>
From: Alex Deucher
The R200 asics use an external DAC for the secondary DAC.
The current KMS code tries to use code for the integrated
TV DAC for R200 which leads to unpredictable results since
R200 does not have an integrated TV DAC. This patch ports
the external DAC load detection support from
From: Alex Deucher
The R200 asics use an external DAC for the secondary DAC.
The current KMS code tries to use code for the integrated
TV DAC for R200 which leads to unpredictable results since
R200 does not have an integrated TV DAC. This patch ports
the external DAC load detection support from
https://bugs.freedesktop.org/show_bug.cgi?id=56437
--- Comment #13 from Tom Stellard ---
(In reply to comment #12)
> Created attachment 69334 [details]
> Possible fix
>
> This is a strange bug. There must be a race condition somewhere. Does this
> patch help? If it doesn't, can you reproduce
On 2012-10-31 15:13, Laurent Pinchart wrote:
>> OMAP SoC
>>
>>
>> So here's first the SoC specific display nodes. OMAP has a DSS (display
>> subsystem) block, which contains the following elements:
>>
>> - DISPC (display controller) reads the pixels from memory and outputs
>> them using s
Hi Dave,
As I posted before, we have added a new git repository for Exynos drm
to MAINTAINERS file so change it to new one like below,
from git://git.infradead.org/users/kmpark/linux-samsung
to git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos
And this pull request includes t
https://bugs.freedesktop.org/show_bug.cgi?id=26294
--- Comment #29 from Paul Menzel ---
So to summarize.
1. In the Asus Eee PC 701 4G, the chip is at the maximum of its capabilities.
(Daniel Vetter: »could be that we're too close to the dotclock limit on these
machines«)
2. The question is now,
Hi Dave,
As I posted before, we have added a new git repository for Exynos drm
to MAINTAINERS file so change it to new one like below,
from git://git.infradead.org/users/kmpark/linux-samsung
to git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos
And this pull request includes t
https://bugs.freedesktop.org/show_bug.cgi?id=56561
--- Comment #10 from Alex Deucher ---
(In reply to comment #9)
> The firmware should be loading (I am using stock arch linux kernels), when
> 3.4.7 or 3.6.3-nomodeset boots I see '[drm] Loading R500 Microcode' in the
> logs. (Sorry I wrote r300 i
https://bugs.freedesktop.org/show_bug.cgi?id=26294
--- Comment #28 from Paul Menzel ---
Some more information searching the Web and from #intel-gfx.
1. According to Chris Wilson it works with 945GM.
2. Searching the Web, it works out of the box with a BenQ E2200HD with an Eee
PC 701, which is t
Hi Inki,
On Saturday 20 October 2012 22:10:17 Inki Dae wrote:
> Hi Laurent. sorry for being late.
No worries.
> 2012/8/17 Laurent Pinchart :
> > Hi everybody,
> >
> > While working on DT bindings for the Renesas Mobile SoC display controller
> > (a.k.a. LCDC) I quickly realized that display pan
Hi Tomi,
On Wednesday 19 September 2012 14:45:29 Tomi Valkeinen wrote:
> On Fri, 2012-08-17 at 02:49 +0200, Laurent Pinchart wrote:
> > Hi everybody,
> >
> > While working on DT bindings for the Renesas Mobile SoC display controller
> > (a.k.a. LCDC) I quickly realized that display panel implemen
d...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121031/ce9e0e0d/attachment.html>
https://bugs.freedesktop.org/show_bug.cgi?id=50422
--- Comment #8 from Laurent carlier ---
I don't know if it's related, but etqw gives me also similar garbaged output
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-d
1 - 100 of 124 matches
Mail list logo
