8 1930 1949 2521
EndMode
EndSection
-
Oneric kernel is:
$ uname -a
Linux dancer 3.0.0-26-generic #43-Ubuntu SMP Tue Sep 25 17:19:22 UTC 2012
x86_64 x86_64 x86_64 GNU/Linux
--
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/20121018/e69225e9/attachment-0001.html>
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121018/2479253e/attachment.html>
IPP stand for Image Post Processing and supports image scaler/rotator
/crop/flip/csc(color space conversion) and input/output DMA operations using
ipp drivers.
also supports writeback and display output operations.
ipp driver include FIMC, Rotator, GSC, SC, so on.
and ipp is integration device dri
GSC is stand for General SCaler and supports supports
image scaler/rotator/crop/flip/csc and input/output DMA operations.
input DMA reads image data from the memory.
output DMA writes image data to memory.
GSC supports image rotation and imag effect functions.
also supports writeback and display ou
Hi All.
I am responsible for a display part from Samsung Electronics Telecommunication
Division.
and I am going to add post-processing features in exynos drm.
If you have some opinion of this patch,
please give some comments about my patch.
IPP is stands for Image Post Processing and supports im
FIMC is stand for Fully Interfactive Mobile Camera and
supports image scaler/rotator/crop/flip/csc and input/output DMA operations.
input DMA reads image data from the memory.
output DMA writes image data to memory.
FIMC supports image rotation and image effect functions.
also supports writeback an
Rotator supports rotation/crop/flip and input/output DMA operations
Rotator ipp driver supports 90,180,270 degree rotaion and vertical, horizontal
flip.
and has some limitations(source and destination format have to be same, no
scaler)
Signed-off-by: Eunchul Kim
Signed-off-by: Youngjun Cho
---
Hi All.
I am responsible for a display part from Samsung Electronics Telecommunication
Division.
and I am going to add post-processing features in exynos drm.
If you have some opinion of this patch,
please give some comments about my patch.
IPP is stands for Image Post Processing and supports im
FIMC is stand for Fully Interfactive Mobile Camera and
supports image scaler/rotator/crop/flip/csc and input/output DMA operations.
input DMA reads image data from the memory.
output DMA writes image data to memory.
FIMC supports image rotation and image effect functions.
also supports writeback an
Rotator supports rotation/crop/flip and input/output DMA operations
Rotator ipp driver supports 90,180,270 degree rotaion and vertical, horizontal
flip.
and has some limitations(source and destination format have to be same, no
scaler)
Signed-off-by: Eunchul Kim
Signed-off-by: Youngjun Cho
---
GSC is stand for General SCaler and supports supports
image scaler/rotator/crop/flip/csc and input/output DMA operations.
input DMA reads image data from the memory.
output DMA writes image data to memory.
GSC supports image rotation and imag effect functions.
also supports writeback and display ou
IPP stand for Image Post Processing and supports image scaler/rotator
/crop/flip/csc(color space conversion) and input/output DMA operations using
ipp drivers.
also supports writeback and display output operations.
ipp driver include FIMC, Rotator, GSC, SC, so on.
and ipp is integration device dri
g as Serkan is. Where should I track
this faulty commit/bug? In the NI CAICOS bug or in a new one?
--
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/20121018/90f38aaa/attachment.html>
crubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121018/32487785/attachment.html>
Hi, Maarten,
As you know I have been having my doubts about this change.
To me it seems insane to be forced to read the fence pointer under a
reserved lock, simply because when you take the reserve lock, another
process may have it and there is a substantial chance that that process
will also be w
On 10/18/2012 09:28 AM, Thomas Hellstrom wrote:
> Hi, Maarten,
>
> As you know I have been having my doubts about this change.
> To me it seems insane to be forced to read the fence pointer under a
> reserved lock, simply because when you take the reserve lock, another
> process may have it and
Hi all,
I've frustrated myself the last few days yelling at our link training code.
Comparing the i915 code to radeon and nouveau I've noticed the lack of a nice
set of dp helper functions. So I've started to extract a few.
There's lots more that we can do I think (link configuration selection, t
I want to move some dp link training helpers into this place, so in
the future this won't be just about i2c any longer.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/Makefile| 2 +-
drivers/gpu/drm/drm_dp_helper.c | 208
drivers/gpu/drm/d
radeon and intel use the exact same definition.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_dp_helper.c | 50
drivers/gpu/drm/i915/intel_dp.c | 35 ++---
drivers/gpu/drm/radeon/atombios_dp.c | 24 ++---
inclu
radeon and intel use the exact same definition.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_dp.c | 4 ++--
drivers/gpu/drm/radeon/atombios_dp.c | 25 +
include/drm/drm_dp_helper.h | 2 ++
3 files changed, 5 insertions(+), 26 deletions(-)
d
Only compile-tested, due to a lack of nouveau dp hw. Should be
equivalent code though.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 26 +-
1 file changed, 5 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/dri
Safe for the minor difference that the intel versions get an offset
into the link_status as an argument, both are the same again.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_dp_helper.c | 27 +++
drivers/gpu/drm/i915/intel_dp.c | 30 ++--
nouveau again score with an impressive density of magic numbers.
Again only compile-tested due to lack of hw, but should be equivalent
code.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/g
This requires a few changes since that dpcd value is above the
range currently cached by radeon. I've check the dp specs, and
above 0xf there's a big gap and nothing that looks like we should
cache it while a given device is plugged in. It's also the same value
that i915.ko uses.
Hence extend the
Only really required for dp 1.2. I've hoped this would help with some
link training woes I'm fighting, but alas those are only dp 1.1
devices.
Also move a comment that went misplaced in the recent refactorings to
the right spot again.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_dp.c | 17 ++---
drivers/gpu/drm/nouveau/nouveau_dp.c | 2 +-
drivers/gpu/drm/radeon/atombios_dp.c | 7 +--
include/drm/drm_dp_helper.h | 7 +++
4 files changed, 11 insertions(+), 22 deletions(-)
dif
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_dp_helper.c | 28
drivers/gpu/drm/i915/intel_dp.c | 5 +
drivers/gpu/drm/radeon/atombios_dp.c | 32 +++-
include/drm/drm_dp_helper.h | 8
4 files changed
ou are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121018/57d611af/attachment.html>
Hey,
Op 18-10-12 09:59, Thomas Hellstrom schreef:
>
>
>
> On 10/18/2012 09:28 AM, Thomas Hellstrom wrote:
>> Hi, Maarten,
>>
>> As you know I have been having my doubts about this change.
>> To me it seems insane to be forced to read the fence pointer under a
>> reserved lock, simply because when
eed looks like a separate bug to me, so I suggest to open up a new bug.
--
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/20121018/950915f3/attachment.html>
When crtc_funcs->dpms callback is called, exynos_crtc->dpms
and exynos_encoder->dpms are changed to new mode. But if user
requests dpms mode operation, OFF -> ON, when crtc's dpms callback
is called, exynos_encoder->dpms is also changed to ON. This
makes encoder's dpms callback call be ignored so d
Hi Ben,
3.7-rc1 messed up the screen on my MacBookAir3,1 (nv50, 0xaf) pretty
badly. Not surprisingly,
commit 3863c9bc887e9638a9d905d55f6038641ece78d6
Author: Ben Skeggs
Date: Sat Jul 14 19:09:17 2012 +1000
drm/nouveau/instmem: completely new implementation, as a subdev module
is the firs
Hi Dave,
The big thing is the disabling of the hsw support by default, cc: stable.
We've aimed for basic hsw support in 3.6, but due to a few bad
happenstances we've screwed up and only 3.8 will have better modeset
support than vesa. To avoid yet another round of fallout from such a
gaffle on for
On 10/18/2012 10:37 AM, Maarten Lankhorst wrote:
> Hey,
>
> Op 18-10-12 09:59, Thomas Hellstrom schreef:
>>
>>
>> On 10/18/2012 09:28 AM, Thomas Hellstrom wrote:
>>> Hi, Maarten,
>>>
>>> As you know I have been having my doubts about this change.
>>> To me it seems insane to be forced to read the f
In text mode, instead of blanking the screen and shutting it down, it
is instead painted white, backlight going full steam.
I have bisected the code and git tells me the first bad commit is
f3728734ba78310525bf4a361c7787c7c6fa5d40.
Apparently my laptop, despite having atom tables, still needs leg
Op 18-10-12 13:02, Thomas Hellstrom schreef:
> On 10/18/2012 10:37 AM, Maarten Lankhorst wrote:
>> Hey,
>>
>> Op 18-10-12 09:59, Thomas Hellstrom schreef:
>>>
>>>
>>> On 10/18/2012 09:28 AM, Thomas Hellstrom wrote:
Hi, Maarten,
As you know I have been having my doubts about this chan
On 10/18/2012 01:38 PM, Maarten Lankhorst wrote:
> Op 18-10-12 13:02, Thomas Hellstrom schreef:
>> On 10/18/2012 10:37 AM, Maarten Lankhorst wrote:
>>> Hey,
>>>
>>> Op 18-10-12 09:59, Thomas Hellstrom schreef:
On 10/18/2012 09:28 AM, Thomas Hellstrom wrote:
> Hi, Maarten,
>
>
On Thu, Oct 18, 2012 at 4:15 AM, Daniel Vetter
wrote:
> This requires a few changes since that dpcd value is above the
> range currently cached by radeon. I've check the dp specs, and
> above 0xf there's a big gap and nothing that looks like we should
> cache it while a given device is plugged in
not.
--
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/20121018/e258f516/attachment.html>
On Thu, Oct 18, 2012 at 4:15 AM, Daniel Vetter
wrote:
> Hi all,
>
> I've frustrated myself the last few days yelling at our link training code.
> Comparing the i915 code to radeon and nouveau I've noticed the lack of a nice
> set of dp helper functions. So I've started to extract a few.
>
> There
This requires a few changes since that dpcd value is above the
range currently cached by radeon. I've check the dp specs, and
above 0xf there's a big gap and nothing that looks like we should
cache it while a given device is plugged in. It's also the same value
that i915.ko uses.
Hence extend the
On Thu, Oct 18, 2012 at 4:15 AM, Daniel Vetter
wrote:
> Hi all,
>
> I've frustrated myself the last few days yelling at our link training code.
> Comparing the i915 code to radeon and nouveau I've noticed the lack of a nice
> set of dp helper functions. So I've started to extract a few.
>
> There
-
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/20121018/01d486b9/attachment-0001.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121018/f63c5a43/attachment.html>
||g/show_bug.cgi?id=56139
--
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/20121018/059df
||g/show_bug.cgi?id=56139
--
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/20121018/c61b0
On Thu, Oct 18, 2012 at 3:48 PM, Alex Deucher wrote:
> On Thu, Oct 18, 2012 at 4:15 AM, Daniel Vetter
> wrote:
>> Hi all,
>>
>> I've frustrated myself the last few days yelling at our link training code.
>> Comparing the i915 code to radeon and nouveau I've noticed the lack of a nice
>> set of d
https://bugzilla.kernel.org/show_bug.cgi?id=49021
Summary: VGA output: Attached monitor is not detected
Product: Drivers
Version: 2.5
Kernel Version: 3.7-rc1
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
https://bugzilla.kernel.org/show_bug.cgi?id=49021
--- Comment #1 from Niels Ole Salscheider
2012-10-18 14:16:09 ---
Created an attachment (id=83871)
--> (https://bugzilla.kernel.org/attachment.cgi?id=83871)
Xorg log
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=emai
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121018/464c11e7/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=49021
Niels Ole Salscheider changed:
What|Removed |Added
Attachment #83861|application/octet-stream|text/plain
mime type|
https://bugzilla.kernel.org/show_bug.cgi?id=49021
--- Comment #2 from Niels Ole Salscheider
2012-10-18 14:21:46 ---
Created an attachment (id=83881)
--> (https://bugzilla.kernel.org/attachment.cgi?id=83881)
vbios
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
-
https://bugzilla.kernel.org/show_bug.cgi?id=49021
--- Comment #3 from Niels Ole Salscheider
2012-10-18 14:27:56 ---
Created an attachment (id=83891)
--> (https://bugzilla.kernel.org/attachment.cgi?id=83891)
dmesg without debug output
--
Configure bugmail: https://bugzilla.kernel.org/user
Op 18-10-12 13:55, Thomas Hellstrom schreef:
> On 10/18/2012 01:38 PM, Maarten Lankhorst wrote:
>> Op 18-10-12 13:02, Thomas Hellstrom schreef:
>>> On 10/18/2012 10:37 AM, Maarten Lankhorst wrote:
Hey,
Op 18-10-12 09:59, Thomas Hellstrom schreef:
>
> On 10/18/2012 09:28 AM, T
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121018/ef0bcdb2/attachment.html>
So this is a typical case where a NO_WAIT can indeed become a WAIT
because of the use of a reservation instead of a spinlock.
(See the remove_fence_lock discussion)
/Thomas
On 10/12/2012 05:06 PM, Maarten Lankhorst wrote:
> Apart from some code inside ttm itself and nouveau_bo_vma_del,
> this i
On 10/18/2012 04:45 PM, Maarten Lankhorst wrote:
> Op 18-10-12 13:55, Thomas Hellstrom schreef:
>> On 10/18/2012 01:38 PM, Maarten Lankhorst wrote:
>>> Op 18-10-12 13:02, Thomas Hellstrom schreef:
On 10/18/2012 10:37 AM, Maarten Lankhorst wrote:
> Hey,
>
> Op 18-10-12 09:59, Thomas
On Thu, Oct 18, 2012 at 06:43:40PM +0200, Thomas Hellstrom wrote:
> On 10/18/2012 04:45 PM, Maarten Lankhorst wrote:
> >Op 18-10-12 13:55, Thomas Hellstrom schreef:
> >>On 10/18/2012 01:38 PM, Maarten Lankhorst wrote:
> >>>Op 18-10-12 13:02, Thomas Hellstrom schreef:
> On 10/18/2012 10:37 AM, M
On Wed, Oct 17, 2012 at 4:48 PM, Paul Menzel
wrote:
> Am Mittwoch, den 17.10.2012, 16:25 -0400 schrieb Alex Deucher:
>> On Wed, Oct 17, 2012 at 11:26 AM, Paul Menzel wrote:
>
>> > Am Mittwoch, den 17.10.2012, 16:49 +0200 schrieb Paul Menzel:
>> >
>> >> setting up an ASUS M2A-VM after some months w
g/archives/dri-devel/attachments/20121018/07ca4e0f/attachment.html>
n embedded and charset-unspecified text was scrubbed...
Name: config-r8229
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121018/c39842a0/attachment-0001.ksh>
Hi All.
I am responsible for a display part from Samsung Electronics Telecommunication
Division.
and I am going to add post-processing features in exynos drm.
If you have some opinion of this patch,
please give some comments about my patch.
IPP is stands for Image Post Processing and supports im
GSC is stand for General SCaler and supports supports
image scaler/rotator/crop/flip/csc and input/output DMA operations.
input DMA reads image data from the memory.
output DMA writes image data to memory.
GSC supports image rotation and imag effect functions.
also supports writeback and display ou
Rotator supports rotation/crop/flip and input/output DMA operations
Rotator ipp driver supports 90,180,270 degree rotaion and vertical, horizontal
flip.
and has some limitations(source and destination format have to be same, no
scaler)
Signed-off-by: Eunchul Kim
Signed-off-by: Youngjun Cho
---
Hi All.
I am responsible for a display part from Samsung Electronics Telecommunication
Division.
and I am going to add post-processing features in exynos drm.
If you have some opinion of this patch,
please give some comments about my patch.
IPP is stands for Image Post Processing and supports im
Rotator supports rotation/crop/flip and input/output DMA operations
Rotator ipp driver supports 90,180,270 degree rotaion and vertical, horizontal
flip.
and has some limitations(source and destination format have to be same, no
scaler)
Signed-off-by: Eunchul Kim
Signed-off-by: Youngjun Cho
---
GSC is stand for General SCaler and supports supports
image scaler/rotator/crop/flip/csc and input/output DMA operations.
input DMA reads image data from the memory.
output DMA writes image data to memory.
GSC supports image rotation and imag effect functions.
also supports writeback and display ou
https://bugs.freedesktop.org/show_bug.cgi?id=55692
--- Comment #40 from Alexandre Demers ---
(In reply to comment #36)
> (In reply to comment #35)
> > I've been playing a bit (booting and restarting with kernel 3.7-rc1) and
> > strangely, what I see is very similar to what I was observing in bug
https://bugs.freedesktop.org/show_bug.cgi?id=56111
--- Comment #2 from Michel Dänzer ---
(In reply to comment #1)
> Created attachment 68742 [details]
> Debian dmesg output, which does have this problem
[...]
> [5.773063] ni_cp: Failed to load firmware "radeon/BARTS_pfp.bin"
> [5.773113]
Hi, Maarten,
As you know I have been having my doubts about this change.
To me it seems insane to be forced to read the fence pointer under a
reserved lock, simply because when you take the reserve lock, another
process may have it and there is a substantial chance that that process
will also be
On 10/18/2012 09:28 AM, Thomas Hellstrom wrote:
Hi, Maarten,
As you know I have been having my doubts about this change.
To me it seems insane to be forced to read the fence pointer under a
reserved lock, simply because when you take the reserve lock, another
process may have it and there is
I want to move some dp link training helpers into this place, so in
the future this won't be just about i2c any longer.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/Makefile| 2 +-
drivers/gpu/drm/drm_dp_helper.c | 208
drivers/gpu/drm/d
Hi all,
I've frustrated myself the last few days yelling at our link training code.
Comparing the i915 code to radeon and nouveau I've noticed the lack of a nice
set of dp helper functions. So I've started to extract a few.
There's lots more that we can do I think (link configuration selection, t
radeon and intel use the exact same definition.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_dp_helper.c | 50
drivers/gpu/drm/i915/intel_dp.c | 35 ++---
drivers/gpu/drm/radeon/atombios_dp.c | 24 ++---
inclu
radeon and intel use the exact same definition.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_dp.c | 4 ++--
drivers/gpu/drm/radeon/atombios_dp.c | 25 +
include/drm/drm_dp_helper.h | 2 ++
3 files changed, 5 insertions(+), 26 deletions(-)
d
Only compile-tested, due to a lack of nouveau dp hw. Should be
equivalent code though.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 26 +-
1 file changed, 5 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/dri
Safe for the minor difference that the intel versions get an offset
into the link_status as an argument, both are the same again.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_dp_helper.c | 27 +++
drivers/gpu/drm/i915/intel_dp.c | 30 ++--
nouveau again score with an impressive density of magic numbers.
Again only compile-tested due to lack of hw, but should be equivalent
code.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/g
This requires a few changes since that dpcd value is above the
range currently cached by radeon. I've check the dp specs, and
above 0xf there's a big gap and nothing that looks like we should
cache it while a given device is plugged in. It's also the same value
that i915.ko uses.
Hence extend the
Only really required for dp 1.2. I've hoped this would help with some
link training woes I'm fighting, but alas those are only dp 1.1
devices.
Also move a comment that went misplaced in the recent refactorings to
the right spot again.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_dp.c | 17 ++---
drivers/gpu/drm/nouveau/nouveau_dp.c | 2 +-
drivers/gpu/drm/radeon/atombios_dp.c | 7 +--
include/drm/drm_dp_helper.h | 7 +++
4 files changed, 11 insertions(+), 22 deletions(-)
dif
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_dp_helper.c | 28
drivers/gpu/drm/i915/intel_dp.c | 5 +
drivers/gpu/drm/radeon/atombios_dp.c | 32 +++-
include/drm/drm_dp_helper.h | 8
4 files changed
https://bugs.freedesktop.org/show_bug.cgi?id=55692
--- Comment #41 from Christian König ---
(In reply to comment #37)
> Created attachment 68728 [details]
> dmesg.3.7-rc1 with testpatch with mesa-git
>
> I removed gdm and installed slim as login manager. Also installed cinnamon
> as a replacemen
Hey,
Op 18-10-12 09:59, Thomas Hellstrom schreef:
>
>
>
> On 10/18/2012 09:28 AM, Thomas Hellstrom wrote:
>> Hi, Maarten,
>>
>> As you know I have been having my doubts about this change.
>> To me it seems insane to be forced to read the fence pointer under a
>> reserved lock, simply because when
https://bugs.freedesktop.org/show_bug.cgi?id=55692
--- Comment #42 from Christian König ---
(In reply to comment #40)
[SNIP]
> kernel bisected. Here is the culprit commit from what I see here:
> 62444b7462a2b98bc78d68736c03a7c4e66ba7e2 is the first bad commit
> commit 62444b7462a2b98bc78d68736c03
When crtc_funcs->dpms callback is called, exynos_crtc->dpms
and exynos_encoder->dpms are changed to new mode. But if user
requests dpms mode operation, OFF -> ON, when crtc's dpms callback
is called, exynos_encoder->dpms is also changed to ON. This
makes encoder's dpms callback call be ignored so d
Hi Ben,
3.7-rc1 messed up the screen on my MacBookAir3,1 (nv50, 0xaf) pretty
badly. Not surprisingly,
commit 3863c9bc887e9638a9d905d55f6038641ece78d6
Author: Ben Skeggs
Date: Sat Jul 14 19:09:17 2012 +1000
drm/nouveau/instmem: completely new implementation, as a subdev module
is the firs
Hi Dave,
The big thing is the disabling of the hsw support by default, cc: stable.
We've aimed for basic hsw support in 3.6, but due to a few bad
happenstances we've screwed up and only 3.8 will have better modeset
support than vesa. To avoid yet another round of fallout from such a
gaffle on for
On 10/18/2012 10:37 AM, Maarten Lankhorst wrote:
Hey,
Op 18-10-12 09:59, Thomas Hellstrom schreef:
On 10/18/2012 09:28 AM, Thomas Hellstrom wrote:
Hi, Maarten,
As you know I have been having my doubts about this change.
To me it seems insane to be forced to read the fence pointer under a
re
In text mode, instead of blanking the screen and shutting it down, it
is instead painted white, backlight going full steam.
I have bisected the code and git tells me the first bad commit is
f3728734ba78310525bf4a361c7787c7c6fa5d40.
Apparently my laptop, despite having atom tables, still needs leg
Op 18-10-12 13:02, Thomas Hellstrom schreef:
> On 10/18/2012 10:37 AM, Maarten Lankhorst wrote:
>> Hey,
>>
>> Op 18-10-12 09:59, Thomas Hellstrom schreef:
>>>
>>>
>>> On 10/18/2012 09:28 AM, Thomas Hellstrom wrote:
Hi, Maarten,
As you know I have been having my doubts about this chan
On 10/18/2012 01:38 PM, Maarten Lankhorst wrote:
Op 18-10-12 13:02, Thomas Hellstrom schreef:
On 10/18/2012 10:37 AM, Maarten Lankhorst wrote:
Hey,
Op 18-10-12 09:59, Thomas Hellstrom schreef:
On 10/18/2012 09:28 AM, Thomas Hellstrom wrote:
Hi, Maarten,
As you know I have been having my do
On Thu, Oct 18, 2012 at 4:15 AM, Daniel Vetter wrote:
> This requires a few changes since that dpcd value is above the
> range currently cached by radeon. I've check the dp specs, and
> above 0xf there's a big gap and nothing that looks like we should
> cache it while a given device is plugged in.
https://bugs.freedesktop.org/show_bug.cgi?id=56111
Darxus changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Thu, Oct 18, 2012 at 4:15 AM, Daniel Vetter wrote:
> Hi all,
>
> I've frustrated myself the last few days yelling at our link training code.
> Comparing the i915 code to radeon and nouveau I've noticed the lack of a nice
> set of dp helper functions. So I've started to extract a few.
>
> There'
This requires a few changes since that dpcd value is above the
range currently cached by radeon. I've check the dp specs, and
above 0xf there's a big gap and nothing that looks like we should
cache it while a given device is plugged in. It's also the same value
that i915.ko uses.
Hence extend the
On Thu, Oct 18, 2012 at 4:15 AM, Daniel Vetter wrote:
> Hi all,
>
> I've frustrated myself the last few days yelling at our link training code.
> Comparing the i915 code to radeon and nouveau I've noticed the lack of a nice
> set of dp helper functions. So I've started to extract a few.
>
> There'
https://bugs.freedesktop.org/show_bug.cgi?id=56139
Priority: medium
Bug ID: 56139
Assignee: dri-devel@lists.freedesktop.org
Summary: [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)
Severity: major
Classification: Unclassified
https://bugs.freedesktop.org/show_bug.cgi?id=56139
Alexandre Demers changed:
What|Removed |Added
See Also||https://bugs.freedesktop.or
https://bugs.freedesktop.org/show_bug.cgi?id=43655
Alexandre Demers changed:
What|Removed |Added
See Also||https://bugs.freedesktop.or
1 - 100 of 115 matches
Mail list logo
