Re: radeon + DVI-mDP converter + mDP display blank screen issue since 3.0
On Fri, Mar 23, 2012 at 03:42:44PM -0400, Alex Deucher wrote: Since Linux 3.0, a system with a Radeon HD 5450 (1002:68f9) connected to a 27 Apple LED cinema display via an Atlona AT-DP400 Dual Link DVI to Mini DisplayPort converter has started to stop giving screen output on switching from text mode to graphical framebuffer during system startup. I finally had some time to look at this, and it seems to have stopped working after this commit: commit df271bec805b42527d864777ed035fcbb42e76c0 Author: Alex Deucher alexdeuc...@gmail.com Date: Fri May 20 04:34:15 2011 -0400 drm/radeon/kms: properly handle bpc 8 in atom command tables Signed-off-by: Alex Deucher alexdeuc...@gmail.com Signed-off-by: Dave Airlie airl...@redhat.com ...and with the patch below (i.e. reverting part of the commit above) applied to 3.3 I get screen output again. Even though the monitor seems to have an 8 bit panel, it reports 10 bits per channel in its EDID: [...] Manufacturer: APP Model 9226 Serial Number 41959462 Made week 38 of 2010 EDID version: 1.4 Digital display 10 bits per primary color channel DisplayPort interface Maximum image size: 60 cm x 34 cm [...] The (active, dual link) DVI-mDP converter spec sheet says it supports 24 bit color, and I'm guessing that it can't deal with 30. Is the converter at fault here for passing through the EDID unchanged? Also, what would be the right way to handle this, a kernel command line or module option to limit color depth or something like that? (Buy a video card with DP output. is a valid answer, I suppose.) I have no clue at all about graphics, and I have no idea whatsoever what I'm doing here, but I just wanted to post this somewhere for Google to find in case someone else runs into this! I've inquired with out display team on how to best handle this. In the meantime, it's probably best to just default to 8 bpc. Does the attached patch fix your issue? I've been using the patch below in a custom Fedora 17 kernel RPM, and that seems to fix the issue. Your patch seems to be a superset of this patch, so logically, your patch should do the trick as well. :) Can you try the attached patch on top of my previous one? Scratch that. Try this one instead. The 3.3 + 0001-drm-radeon-kms-atom-force-bpc-to-8-for-now.patch + 0001-drm-radeon-kms-improve-bpc-handling-v2.patch combo seems to work fine -- I get display output as expected. Tested-by: Lennert Buytenhek buyt...@wantstofly.org thanks, Lennert ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
radeon + DVI->mDP converter + mDP display blank screen issue since 3.0
On Fri, Mar 23, 2012 at 03:42:44PM -0400, Alex Deucher wrote:
> >>> > Since Linux 3.0, a system with a Radeon HD 5450 (1002:68f9) connected
> >>> > to a 27" Apple LED cinema display via an Atlona AT-DP400 Dual Link DVI
> >>> > to Mini DisplayPort converter has started to stop giving screen
> >>> > output on switching from text mode to graphical framebuffer during
> >>> > system startup.
> >>> >
> >>> > I finally had some time to look at this, and it seems to have stopped
> >>> > working after this commit:
> >>> >
> >>> > ? ? ? ?commit df271bec805b42527d864777ed035fcbb42e76c0
> >>> > ? ? ? ?Author: Alex Deucher
> >>> > ? ? ? ?Date: ? Fri May 20 04:34:15 2011 -0400
> >>> >
> >>> > ? ? ? ? ? ?drm/radeon/kms: properly handle bpc >8 in atom command tables
> >>> >
> >>> > ? ? ? ? ? ?Signed-off-by: Alex Deucher
> >>> > ? ? ? ? ? ?Signed-off-by: Dave Airlie
> >>> >
> >>> > ...and with the patch below (i.e. reverting part of the commit above)
> >>> > applied to 3.3 I get screen output again.
> >>> >
> >>> > Even though the monitor seems to have an 8 bit panel, it reports 10
> >>> > bits per channel in its EDID:
> >>> >
> >>> > ? ? ? ?[...]
> >>> > ? ? ? ?Manufacturer: APP Model 9226 Serial Number 41959462
> >>> > ? ? ? ?Made week 38 of 2010
> >>> > ? ? ? ?EDID version: 1.4
> >>> > ? ? ? ?Digital display
> >>> > ? ? ? ?10 bits per primary color channel
> >>> > ? ? ? ?DisplayPort interface
> >>> > ? ? ? ?Maximum image size: 60 cm x 34 cm
> >>> > ? ? ? ?[...]
> >>> >
> >>> > The (active, dual link) DVI->mDP converter spec sheet says it supports
> >>> > 24 bit color, and I'm guessing that it can't deal with 30. ?Is the
> >>> > converter at fault here for passing through the EDID unchanged?
> >>> >
> >>> > Also, what would be the right way to handle this, a kernel command
> >>> > line or module option to limit color depth or something like that?
> >>> > ("Buy a video card with DP output." is a valid answer, I suppose.)
> >>> >
> >>> > I have no clue at all about graphics, and I have no idea whatsoever
> >>> > what I'm doing here, but I just wanted to post this somewhere for
> >>> > Google to find in case someone else runs into this!
> >>>
> >>> I've inquired with out display team on how to best handle this. ?In
> >>> the meantime, it's probably best to just default to 8 bpc. ?Does the
> >>> attached patch fix your issue?
> >>
> >> I've been using the patch below in a custom Fedora 17 kernel RPM, and
> >> that seems to fix the issue. ?Your patch seems to be a superset of
> >> this patch, so logically, your patch should do the trick as well. :)
> >
> > Can you try the attached patch on top of my previous one?
>
> Scratch that. Try this one instead.
The 3.3 + 0001-drm-radeon-kms-atom-force-bpc-to-8-for-now.patch +
0001-drm-radeon-kms-improve-bpc-handling-v2.patch combo seems to work
fine -- I get display output as expected.
Tested-by: Lennert Buytenhek
thanks,
Lennert
radeon + DVI->mDP converter + mDP display blank screen issue since 3.0
On Fri, Mar 23, 2012 at 10:59:27AM -0400, Alex Deucher wrote:
> > Since Linux 3.0, a system with a Radeon HD 5450 (1002:68f9) connected
> > to a 27" Apple LED cinema display via an Atlona AT-DP400 Dual Link DVI
> > to Mini DisplayPort converter has started to stop giving screen
> > output on switching from text mode to graphical framebuffer during
> > system startup.
> >
> > I finally had some time to look at this, and it seems to have stopped
> > working after this commit:
> >
> > ? ? ? ?commit df271bec805b42527d864777ed035fcbb42e76c0
> > ? ? ? ?Author: Alex Deucher
> > ? ? ? ?Date: ? Fri May 20 04:34:15 2011 -0400
> >
> > ? ? ? ? ? ?drm/radeon/kms: properly handle bpc >8 in atom command tables
> >
> > ? ? ? ? ? ?Signed-off-by: Alex Deucher
> > ? ? ? ? ? ?Signed-off-by: Dave Airlie
> >
> > ...and with the patch below (i.e. reverting part of the commit above)
> > applied to 3.3 I get screen output again.
> >
> > Even though the monitor seems to have an 8 bit panel, it reports 10
> > bits per channel in its EDID:
> >
> > ? ? ? ?[...]
> > ? ? ? ?Manufacturer: APP Model 9226 Serial Number 41959462
> > ? ? ? ?Made week 38 of 2010
> > ? ? ? ?EDID version: 1.4
> > ? ? ? ?Digital display
> > ? ? ? ?10 bits per primary color channel
> > ? ? ? ?DisplayPort interface
> > ? ? ? ?Maximum image size: 60 cm x 34 cm
> > ? ? ? ?[...]
> >
> > The (active, dual link) DVI->mDP converter spec sheet says it supports
> > 24 bit color, and I'm guessing that it can't deal with 30. ?Is the
> > converter at fault here for passing through the EDID unchanged?
> >
> > Also, what would be the right way to handle this, a kernel command
> > line or module option to limit color depth or something like that?
> > ("Buy a video card with DP output." is a valid answer, I suppose.)
> >
> > I have no clue at all about graphics, and I have no idea whatsoever
> > what I'm doing here, but I just wanted to post this somewhere for
> > Google to find in case someone else runs into this!
>
> I've inquired with out display team on how to best handle this. In
> the meantime, it's probably best to just default to 8 bpc. Does the
> attached patch fix your issue?
I've been using the patch below in a custom Fedora 17 kernel RPM, and
that seems to fix the issue. Your patch seems to be a superset of
this patch, so logically, your patch should do the trick as well. :)
thanks,
Lennert
diff -up linux-3.3.0-1.fc17.x86_64/drivers/gpu/drm/radeon/atombios_crtc.c.orig
linux-3.3.0-1.fc17.x86_64/drivers/gpu/drm/radeon/atombios_crtc.c
--- linux-3.3.0-1.fc17.x86_64/drivers/gpu/drm/radeon/atombios_crtc.c.orig
2012-03-22 14:52:20.538854547 +0100
+++ linux-3.3.0-1.fc17.x86_64/drivers/gpu/drm/radeon/atombios_crtc.c
2012-03-22 14:55:39.740794113 +0100
@@ -550,8 +550,6 @@ static u32 atombios_adjust_pll(struct dr
if (encoder->crtc == crtc) {
radeon_encoder = to_radeon_encoder(encoder);
connector = radeon_get_connector_for_encoder(encoder);
- if (connector && connector->display_info.bpc)
- bpc = connector->display_info.bpc;
encoder_mode = atombios_get_encoder_mode(encoder);
is_duallink = radeon_dig_monitor_is_duallink(encoder,
mode->clock);
if ((radeon_encoder->devices & (ATOM_DEVICE_LCD_SUPPORT
| ATOM_DEVICE_DFP_SUPPORT)) ||
@@ -922,7 +920,6 @@ static void atombios_crtc_set_pll(struct
struct radeon_connector_atom_dig *dig_connector =
radeon_connector->con_priv;
int dp_clock;
- bpc = connector->display_info.bpc;
switch (encoder_mode) {
case ATOM_ENCODER_MODE_DP_MST:
> From 22ca454eb749968f266d6788a5f4778acc08cc66 Mon Sep 17 00:00:00 2001
> From: Alex Deucher
> Date: Fri, 23 Mar 2012 10:54:45 -0400
> Subject: [PATCH] drm/radeon/kms/atom: force bpc to 8 for now
>
> Using the bpc (bits per color) specified by the monitor
> can cause problems in some cases. Until we get a better
> handle on how to deal with those cases, just use a bpc of 8.
>
> Reported-by: Lennert Buytenhek
> Signed-off-by: Alex Deucher
> Cc: stable at kernel.org
> ---
> drivers/gpu/drm/radeon/atombios_crtc.c |8 +---
> drivers/gpu/drm/radeon/atombios_dp.c |3 +++
> drivers/gpu/drm/radeon/atombios_encoders.c |4 ++--
> 3 files changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
> b/drivers/gpu/drm/radeon/atombios_crtc.c
> index 083b3ea..b5ff1f7 100644
> --- a/drivers/gpu/drm/radeon/atombios_crtc.c
> +++ b/drivers/gpu/drm/radeon/atombios_crtc.c
> @@ -588,8 +588,8 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
> if (encoder->crtc == crtc) {
> radeon_encoder = to_radeon_encoder(encoder);
> connector = radeon_get_connector_for_encoder(encoder);
> -
radeon + DVI->mDP converter + mDP display blank screen issue since 3.0
On Fri, Mar 23, 2012 at 3:34 PM, Alex Deucher wrote:
> On Fri, Mar 23, 2012 at 11:44 AM, Lennert Buytenhek
> wrote:
>> On Fri, Mar 23, 2012 at 10:59:27AM -0400, Alex Deucher wrote:
>>
>>> > Since Linux 3.0, a system with a Radeon HD 5450 (1002:68f9) connected
>>> > to a 27" Apple LED cinema display via an Atlona AT-DP400 Dual Link DVI
>>> > to Mini DisplayPort converter has started to stop giving screen
>>> > output on switching from text mode to graphical framebuffer during
>>> > system startup.
>>> >
>>> > I finally had some time to look at this, and it seems to have stopped
>>> > working after this commit:
>>> >
>>> > ? ? ? ?commit df271bec805b42527d864777ed035fcbb42e76c0
>>> > ? ? ? ?Author: Alex Deucher
>>> > ? ? ? ?Date: ? Fri May 20 04:34:15 2011 -0400
>>> >
>>> > ? ? ? ? ? ?drm/radeon/kms: properly handle bpc >8 in atom command tables
>>> >
>>> > ? ? ? ? ? ?Signed-off-by: Alex Deucher
>>> > ? ? ? ? ? ?Signed-off-by: Dave Airlie
>>> >
>>> > ...and with the patch below (i.e. reverting part of the commit above)
>>> > applied to 3.3 I get screen output again.
>>> >
>>> > Even though the monitor seems to have an 8 bit panel, it reports 10
>>> > bits per channel in its EDID:
>>> >
>>> > ? ? ? ?[...]
>>> > ? ? ? ?Manufacturer: APP Model 9226 Serial Number 41959462
>>> > ? ? ? ?Made week 38 of 2010
>>> > ? ? ? ?EDID version: 1.4
>>> > ? ? ? ?Digital display
>>> > ? ? ? ?10 bits per primary color channel
>>> > ? ? ? ?DisplayPort interface
>>> > ? ? ? ?Maximum image size: 60 cm x 34 cm
>>> > ? ? ? ?[...]
>>> >
>>> > The (active, dual link) DVI->mDP converter spec sheet says it supports
>>> > 24 bit color, and I'm guessing that it can't deal with 30. ?Is the
>>> > converter at fault here for passing through the EDID unchanged?
>>> >
>>> > Also, what would be the right way to handle this, a kernel command
>>> > line or module option to limit color depth or something like that?
>>> > ("Buy a video card with DP output." is a valid answer, I suppose.)
>>> >
>>> > I have no clue at all about graphics, and I have no idea whatsoever
>>> > what I'm doing here, but I just wanted to post this somewhere for
>>> > Google to find in case someone else runs into this!
>>>
>>> I've inquired with out display team on how to best handle this. ?In
>>> the meantime, it's probably best to just default to 8 bpc. ?Does the
>>> attached patch fix your issue?
>>
>> I've been using the patch below in a custom Fedora 17 kernel RPM, and
>> that seems to fix the issue. ?Your patch seems to be a superset of
>> this patch, so logically, your patch should do the trick as well. :)
>
> Can you try the attached patch on top of my previous one?
Scratch that. Try this one instead.
Alex
>
> Alex
>
>>
>>
>> thanks,
>> Lennert
>>
>>
>> diff -up
>> linux-3.3.0-1.fc17.x86_64/drivers/gpu/drm/radeon/atombios_crtc.c.orig
>> linux-3.3.0-1.fc17.x86_64/drivers/gpu/drm/radeon/atombios_crtc.c
>> --- linux-3.3.0-1.fc17.x86_64/drivers/gpu/drm/radeon/atombios_crtc.c.orig ?
>> ? ? 2012-03-22 14:52:20.538854547 +0100
>> +++ linux-3.3.0-1.fc17.x86_64/drivers/gpu/drm/radeon/atombios_crtc.c ?
>> ?2012-03-22 14:55:39.740794113 +0100
>> @@ -550,8 +550,6 @@ static u32 atombios_adjust_pll(struct dr
>> ? ? ? ? ? ? ? ?if (encoder->crtc == crtc) {
>> ? ? ? ? ? ? ? ? ? ? ? ?radeon_encoder = to_radeon_encoder(encoder);
>> ? ? ? ? ? ? ? ? ? ? ? ?connector = radeon_get_connector_for_encoder(encoder);
>> - ? ? ? ? ? ? ? ? ? ? ? if (connector && connector->display_info.bpc)
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? bpc = connector->display_info.bpc;
>> ? ? ? ? ? ? ? ? ? ? ? ?encoder_mode = atombios_get_encoder_mode(encoder);
>> ? ? ? ? ? ? ? ? ? ? ? ?is_duallink = radeon_dig_monitor_is_duallink(encoder,
>> mode->clock);
>> ? ? ? ? ? ? ? ? ? ? ? ?if ((radeon_encoder->devices &
>> (ATOM_DEVICE_LCD_SUPPORT | ATOM_DEVICE_DFP_SUPPORT)) ||
>> @@ -922,7 +920,6 @@ static void atombios_crtc_set_pll(struct
>> ? ? ? ? ? ? ? ?struct radeon_connector_atom_dig *dig_connector =
>> ? ? ? ? ? ? ? ? ? ? ? ?radeon_connector->con_priv;
>> ? ? ? ? ? ? ? ?int dp_clock;
>> - ? ? ? ? ? ? ? bpc = connector->display_info.bpc;
>>
>> ? ? ? ? ? ? ? ?switch (encoder_mode) {
>> ? ? ? ? ? ? ? ?case ATOM_ENCODER_MODE_DP_MST:
>>
>>
>>
>>> From 22ca454eb749968f266d6788a5f4778acc08cc66 Mon Sep 17 00:00:00 2001
>>> From: Alex Deucher
>>> Date: Fri, 23 Mar 2012 10:54:45 -0400
>>> Subject: [PATCH] drm/radeon/kms/atom: force bpc to 8 for now
>>>
>>> Using the bpc (bits per color) specified by the monitor
>>> can cause problems in some cases. ?Until we get a better
>>> handle on how to deal with those cases, just use a bpc of 8.
>>>
>>> Reported-by: Lennert Buytenhek
>>> Signed-off-by: Alex Deucher
>>> Cc: stable at kernel.org
>>> ---
>>> ?drivers/gpu/drm/radeon/atombios_crtc.c ? ? | ? ?8 +---
>>> ?drivers/gpu/drm/radeon/atombios_dp.c ? ? ? | ? ?3 +++
>>> ?drivers/gpu/drm/radeon/atombios_encoders.c | ? ?4 ++--
>>> ?3 files changed, 10 insertions(+), 5 deletions(-)
>>>
>>> diff --git
radeon + DVI->mDP converter + mDP display blank screen issue since 3.0
On Fri, Mar 23, 2012 at 11:44 AM, Lennert Buytenhek
wrote:
> On Fri, Mar 23, 2012 at 10:59:27AM -0400, Alex Deucher wrote:
>
>> > Since Linux 3.0, a system with a Radeon HD 5450 (1002:68f9) connected
>> > to a 27" Apple LED cinema display via an Atlona AT-DP400 Dual Link DVI
>> > to Mini DisplayPort converter has started to stop giving screen
>> > output on switching from text mode to graphical framebuffer during
>> > system startup.
>> >
>> > I finally had some time to look at this, and it seems to have stopped
>> > working after this commit:
>> >
>> > ? ? ? ?commit df271bec805b42527d864777ed035fcbb42e76c0
>> > ? ? ? ?Author: Alex Deucher
>> > ? ? ? ?Date: ? Fri May 20 04:34:15 2011 -0400
>> >
>> > ? ? ? ? ? ?drm/radeon/kms: properly handle bpc >8 in atom command tables
>> >
>> > ? ? ? ? ? ?Signed-off-by: Alex Deucher
>> > ? ? ? ? ? ?Signed-off-by: Dave Airlie
>> >
>> > ...and with the patch below (i.e. reverting part of the commit above)
>> > applied to 3.3 I get screen output again.
>> >
>> > Even though the monitor seems to have an 8 bit panel, it reports 10
>> > bits per channel in its EDID:
>> >
>> > ? ? ? ?[...]
>> > ? ? ? ?Manufacturer: APP Model 9226 Serial Number 41959462
>> > ? ? ? ?Made week 38 of 2010
>> > ? ? ? ?EDID version: 1.4
>> > ? ? ? ?Digital display
>> > ? ? ? ?10 bits per primary color channel
>> > ? ? ? ?DisplayPort interface
>> > ? ? ? ?Maximum image size: 60 cm x 34 cm
>> > ? ? ? ?[...]
>> >
>> > The (active, dual link) DVI->mDP converter spec sheet says it supports
>> > 24 bit color, and I'm guessing that it can't deal with 30. ?Is the
>> > converter at fault here for passing through the EDID unchanged?
>> >
>> > Also, what would be the right way to handle this, a kernel command
>> > line or module option to limit color depth or something like that?
>> > ("Buy a video card with DP output." is a valid answer, I suppose.)
>> >
>> > I have no clue at all about graphics, and I have no idea whatsoever
>> > what I'm doing here, but I just wanted to post this somewhere for
>> > Google to find in case someone else runs into this!
>>
>> I've inquired with out display team on how to best handle this. ?In
>> the meantime, it's probably best to just default to 8 bpc. ?Does the
>> attached patch fix your issue?
>
> I've been using the patch below in a custom Fedora 17 kernel RPM, and
> that seems to fix the issue. ?Your patch seems to be a superset of
> this patch, so logically, your patch should do the trick as well. :)
Can you try the attached patch on top of my previous one?
Alex
>
>
> thanks,
> Lennert
>
>
> diff -up
> linux-3.3.0-1.fc17.x86_64/drivers/gpu/drm/radeon/atombios_crtc.c.orig
> linux-3.3.0-1.fc17.x86_64/drivers/gpu/drm/radeon/atombios_crtc.c
> --- linux-3.3.0-1.fc17.x86_64/drivers/gpu/drm/radeon/atombios_crtc.c.orig ? ?
> ? 2012-03-22 14:52:20.538854547 +0100
> +++ linux-3.3.0-1.fc17.x86_64/drivers/gpu/drm/radeon/atombios_crtc.c ?
> ?2012-03-22 14:55:39.740794113 +0100
> @@ -550,8 +550,6 @@ static u32 atombios_adjust_pll(struct dr
> ? ? ? ? ? ? ? ?if (encoder->crtc == crtc) {
> ? ? ? ? ? ? ? ? ? ? ? ?radeon_encoder = to_radeon_encoder(encoder);
> ? ? ? ? ? ? ? ? ? ? ? ?connector = radeon_get_connector_for_encoder(encoder);
> - ? ? ? ? ? ? ? ? ? ? ? if (connector && connector->display_info.bpc)
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? bpc = connector->display_info.bpc;
> ? ? ? ? ? ? ? ? ? ? ? ?encoder_mode = atombios_get_encoder_mode(encoder);
> ? ? ? ? ? ? ? ? ? ? ? ?is_duallink = radeon_dig_monitor_is_duallink(encoder,
> mode->clock);
> ? ? ? ? ? ? ? ? ? ? ? ?if ((radeon_encoder->devices &
> (ATOM_DEVICE_LCD_SUPPORT | ATOM_DEVICE_DFP_SUPPORT)) ||
> @@ -922,7 +920,6 @@ static void atombios_crtc_set_pll(struct
> ? ? ? ? ? ? ? ?struct radeon_connector_atom_dig *dig_connector =
> ? ? ? ? ? ? ? ? ? ? ? ?radeon_connector->con_priv;
> ? ? ? ? ? ? ? ?int dp_clock;
> - ? ? ? ? ? ? ? bpc = connector->display_info.bpc;
>
> ? ? ? ? ? ? ? ?switch (encoder_mode) {
> ? ? ? ? ? ? ? ?case ATOM_ENCODER_MODE_DP_MST:
>
>
>
>> From 22ca454eb749968f266d6788a5f4778acc08cc66 Mon Sep 17 00:00:00 2001
>> From: Alex Deucher
>> Date: Fri, 23 Mar 2012 10:54:45 -0400
>> Subject: [PATCH] drm/radeon/kms/atom: force bpc to 8 for now
>>
>> Using the bpc (bits per color) specified by the monitor
>> can cause problems in some cases. ?Until we get a better
>> handle on how to deal with those cases, just use a bpc of 8.
>>
>> Reported-by: Lennert Buytenhek
>> Signed-off-by: Alex Deucher
>> Cc: stable at kernel.org
>> ---
>> ?drivers/gpu/drm/radeon/atombios_crtc.c ? ? | ? ?8 +---
>> ?drivers/gpu/drm/radeon/atombios_dp.c ? ? ? | ? ?3 +++
>> ?drivers/gpu/drm/radeon/atombios_encoders.c | ? ?4 ++--
>> ?3 files changed, 10 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
>> b/drivers/gpu/drm/radeon/atombios_crtc.c
>> index 083b3ea..b5ff1f7 100644
>> --- a/drivers/gpu/drm/radeon/atombios_crtc.c
>> +++ b/drivers/gpu/drm/radeon/atombios_crtc.c
>> @@ -588,8 +588,8 @@
radeon + DVI->mDP converter + mDP display blank screen issue since 3.0
On Thu, Mar 22, 2012 at 8:49 AM, Lennert Buytenhek
wrote:
> Hi!
>
> Since Linux 3.0, a system with a Radeon HD 5450 (1002:68f9) connected
> to a 27" Apple LED cinema display via an Atlona AT-DP400 Dual Link DVI
> to Mini DisplayPort converter has started to stop giving screen
> output on switching from text mode to graphical framebuffer during
> system startup.
>
> I finally had some time to look at this, and it seems to have stopped
> working after this commit:
>
> ? ? ? ?commit df271bec805b42527d864777ed035fcbb42e76c0
> ? ? ? ?Author: Alex Deucher
> ? ? ? ?Date: ? Fri May 20 04:34:15 2011 -0400
>
> ? ? ? ? ? ?drm/radeon/kms: properly handle bpc >8 in atom command tables
>
> ? ? ? ? ? ?Signed-off-by: Alex Deucher
> ? ? ? ? ? ?Signed-off-by: Dave Airlie
>
> ...and with the patch below (i.e. reverting part of the commit above)
> applied to 3.3 I get screen output again.
>
> Even though the monitor seems to have an 8 bit panel, it reports 10
> bits per channel in its EDID:
>
> ? ? ? ?[...]
> ? ? ? ?Manufacturer: APP Model 9226 Serial Number 41959462
> ? ? ? ?Made week 38 of 2010
> ? ? ? ?EDID version: 1.4
> ? ? ? ?Digital display
> ? ? ? ?10 bits per primary color channel
> ? ? ? ?DisplayPort interface
> ? ? ? ?Maximum image size: 60 cm x 34 cm
> ? ? ? ?[...]
>
> The (active, dual link) DVI->mDP converter spec sheet says it supports
> 24 bit color, and I'm guessing that it can't deal with 30. ?Is the
> converter at fault here for passing through the EDID unchanged?
>
> Also, what would be the right way to handle this, a kernel command
> line or module option to limit color depth or something like that?
> ("Buy a video card with DP output." is a valid answer, I suppose.)
>
> I have no clue at all about graphics, and I have no idea whatsoever
> what I'm doing here, but I just wanted to post this somewhere for
> Google to find in case someone else runs into this!
I've inquired with out display team on how to best handle this. In
the meantime, it's probably best to just default to 8 bpc. Does the
attached patch fix your issue?
Alex
>
>
> thanks,
> Lennert
>
>
>
> diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
> b/drivers/gpu/drm/radeon/atombios_crtc.c
> index 742f17f..77a6a04 100644
> --- a/drivers/gpu/drm/radeon/atombios_crtc.c
> +++ b/drivers/gpu/drm/radeon/atombios_crtc.c
> @@ -513,11 +513,9 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
> ? ? ? ?struct radeon_device *rdev = dev->dev_private;
> ? ? ? ?struct drm_encoder *encoder = NULL;
> ? ? ? ?struct radeon_encoder *radeon_encoder = NULL;
> - ? ? ? struct drm_connector *connector = NULL;
> ? ? ? ?u32 adjusted_clock = mode->clock;
> ? ? ? ?int encoder_mode = 0;
> ? ? ? ?u32 dp_clock = mode->clock;
> - ? ? ? int bpc = 8;
> ? ? ? ?bool is_duallink = false;
>
> ? ? ? ?/* reset the pll flags */
> @@ -549,13 +547,11 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
> ? ? ? ?list_for_each_entry(encoder, >mode_config.encoder_list, head) {
> ? ? ? ? ? ? ? ?if (encoder->crtc == crtc) {
> ? ? ? ? ? ? ? ? ? ? ? ?radeon_encoder = to_radeon_encoder(encoder);
> - ? ? ? ? ? ? ? ? ? ? ? connector = radeon_get_connector_for_encoder(encoder);
> - ? ? ? ? ? ? ? ? ? ? ? if (connector && connector->display_info.bpc)
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? bpc = connector->display_info.bpc;
> ? ? ? ? ? ? ? ? ? ? ? ?encoder_mode = atombios_get_encoder_mode(encoder);
> ? ? ? ? ? ? ? ? ? ? ? ?is_duallink = radeon_dig_monitor_is_duallink(encoder,
> mode->clock);
> ? ? ? ? ? ? ? ? ? ? ? ?if ((radeon_encoder->devices &
> (ATOM_DEVICE_LCD_SUPPORT | ATOM_DEVICE_DFP_SUPPORT)) ||
> ? ? ? ? ? ? ? ? ? ? ? ? ? ?(radeon_encoder_get_dp_bridge_encoder_id(encoder)
> != ENCODER_OBJECT_ID_NONE)) {
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? struct drm_connector *connector =
> radeon_get_connector_for_encoder(encoder);
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?if (connector) {
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?struct radeon_connector
> *radeon_connector = to_radeon_connector(connector);
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?struct radeon_connector_atom_dig
> *dig_connector =
> @@ -645,7 +641,7 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?if (encoder_mode ==
> ATOM_ENCODER_MODE_HDMI)
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?/* deep color support */
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?args.v3.sInput.usPixelClock =
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
> cpu_to_le16((mode->clock * bpc / 8) / 10);
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
> cpu_to_le16(mode->clock / 10);
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?if (dig->coherent_mode)
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?args.v3.sInput.ucDispPllConfig
> |=
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
> ?DISPPLL_CONFIG_COHERENT_MODE;
> @@ -753,7 +749,6 @@ static void atombios_crtc_program_pll(struct drm_crtc
> *crtc,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?u32 fb_div,
> ? ? ? ? ? ? ? ? ? ? ? ? ?
radeon + DVI-mDP converter + mDP display blank screen issue since 3.0
Hi!
Since Linux 3.0, a system with a Radeon HD 5450 (1002:68f9) connected
to a 27 Apple LED cinema display via an Atlona AT-DP400 Dual Link DVI
to Mini DisplayPort converter has started to stop giving screen
output on switching from text mode to graphical framebuffer during
system startup.
I finally had some time to look at this, and it seems to have stopped
working after this commit:
commit df271bec805b42527d864777ed035fcbb42e76c0
Author: Alex Deucher alexdeuc...@gmail.com
Date: Fri May 20 04:34:15 2011 -0400
drm/radeon/kms: properly handle bpc 8 in atom command tables
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
Signed-off-by: Dave Airlie airl...@redhat.com
...and with the patch below (i.e. reverting part of the commit above)
applied to 3.3 I get screen output again.
Even though the monitor seems to have an 8 bit panel, it reports 10
bits per channel in its EDID:
[...]
Manufacturer: APP Model 9226 Serial Number 41959462
Made week 38 of 2010
EDID version: 1.4
Digital display
10 bits per primary color channel
DisplayPort interface
Maximum image size: 60 cm x 34 cm
[...]
The (active, dual link) DVI-mDP converter spec sheet says it supports
24 bit color, and I'm guessing that it can't deal with 30. Is the
converter at fault here for passing through the EDID unchanged?
Also, what would be the right way to handle this, a kernel command
line or module option to limit color depth or something like that?
(Buy a video card with DP output. is a valid answer, I suppose.)
I have no clue at all about graphics, and I have no idea whatsoever
what I'm doing here, but I just wanted to post this somewhere for
Google to find in case someone else runs into this!
thanks,
Lennert
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
b/drivers/gpu/drm/radeon/atombios_crtc.c
index 742f17f..77a6a04 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -513,11 +513,9 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
struct radeon_device *rdev = dev-dev_private;
struct drm_encoder *encoder = NULL;
struct radeon_encoder *radeon_encoder = NULL;
- struct drm_connector *connector = NULL;
u32 adjusted_clock = mode-clock;
int encoder_mode = 0;
u32 dp_clock = mode-clock;
- int bpc = 8;
bool is_duallink = false;
/* reset the pll flags */
@@ -549,13 +547,11 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
list_for_each_entry(encoder, dev-mode_config.encoder_list, head) {
if (encoder-crtc == crtc) {
radeon_encoder = to_radeon_encoder(encoder);
- connector = radeon_get_connector_for_encoder(encoder);
- if (connector connector-display_info.bpc)
- bpc = connector-display_info.bpc;
encoder_mode = atombios_get_encoder_mode(encoder);
is_duallink = radeon_dig_monitor_is_duallink(encoder,
mode-clock);
if ((radeon_encoder-devices (ATOM_DEVICE_LCD_SUPPORT
| ATOM_DEVICE_DFP_SUPPORT)) ||
(radeon_encoder_get_dp_bridge_encoder_id(encoder)
!= ENCODER_OBJECT_ID_NONE)) {
+ struct drm_connector *connector =
radeon_get_connector_for_encoder(encoder);
if (connector) {
struct radeon_connector
*radeon_connector = to_radeon_connector(connector);
struct radeon_connector_atom_dig
*dig_connector =
@@ -645,7 +641,7 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
if (encoder_mode ==
ATOM_ENCODER_MODE_HDMI)
/* deep color support */
args.v3.sInput.usPixelClock =
-
cpu_to_le16((mode-clock * bpc / 8) / 10);
+ cpu_to_le16(mode-clock
/ 10);
if (dig-coherent_mode)
args.v3.sInput.ucDispPllConfig
|=
DISPPLL_CONFIG_COHERENT_MODE;
@@ -753,7 +749,6 @@ static void atombios_crtc_program_pll(struct drm_crtc *crtc,
u32 fb_div,
u32 frac_fb_div,
u32 post_div,
- int bpc,
bool ss_enabled,
struct radeon_atom_ss *ss)
{
@@ -817,15 +812,6 @@ static void atombios_crtc_program_pll(struct drm_crtc
*crtc,
Re: radeon + DVI-mDP converter + mDP display blank screen issue since 3.0
On Thu, Mar 22, 2012 at 8:49 AM, Lennert Buytenhek
buyt...@wantstofly.org wrote:
Hi!
Since Linux 3.0, a system with a Radeon HD 5450 (1002:68f9) connected
to a 27 Apple LED cinema display via an Atlona AT-DP400 Dual Link DVI
to Mini DisplayPort converter has started to stop giving screen
output on switching from text mode to graphical framebuffer during
system startup.
I finally had some time to look at this, and it seems to have stopped
working after this commit:
commit df271bec805b42527d864777ed035fcbb42e76c0
Author: Alex Deucher alexdeuc...@gmail.com
Date: Fri May 20 04:34:15 2011 -0400
drm/radeon/kms: properly handle bpc 8 in atom command tables
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
Signed-off-by: Dave Airlie airl...@redhat.com
...and with the patch below (i.e. reverting part of the commit above)
applied to 3.3 I get screen output again.
Even though the monitor seems to have an 8 bit panel, it reports 10
bits per channel in its EDID:
[...]
Manufacturer: APP Model 9226 Serial Number 41959462
Made week 38 of 2010
EDID version: 1.4
Digital display
10 bits per primary color channel
DisplayPort interface
Maximum image size: 60 cm x 34 cm
[...]
The (active, dual link) DVI-mDP converter spec sheet says it supports
24 bit color, and I'm guessing that it can't deal with 30. Is the
converter at fault here for passing through the EDID unchanged?
Also, what would be the right way to handle this, a kernel command
line or module option to limit color depth or something like that?
(Buy a video card with DP output. is a valid answer, I suppose.)
I have no clue at all about graphics, and I have no idea whatsoever
what I'm doing here, but I just wanted to post this somewhere for
Google to find in case someone else runs into this!
I've inquired with out display team on how to best handle this. In
the meantime, it's probably best to just default to 8 bpc. Does the
attached patch fix your issue?
Alex
thanks,
Lennert
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
b/drivers/gpu/drm/radeon/atombios_crtc.c
index 742f17f..77a6a04 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -513,11 +513,9 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
struct radeon_device *rdev = dev-dev_private;
struct drm_encoder *encoder = NULL;
struct radeon_encoder *radeon_encoder = NULL;
- struct drm_connector *connector = NULL;
u32 adjusted_clock = mode-clock;
int encoder_mode = 0;
u32 dp_clock = mode-clock;
- int bpc = 8;
bool is_duallink = false;
/* reset the pll flags */
@@ -549,13 +547,11 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
list_for_each_entry(encoder, dev-mode_config.encoder_list, head) {
if (encoder-crtc == crtc) {
radeon_encoder = to_radeon_encoder(encoder);
- connector = radeon_get_connector_for_encoder(encoder);
- if (connector connector-display_info.bpc)
- bpc = connector-display_info.bpc;
encoder_mode = atombios_get_encoder_mode(encoder);
is_duallink = radeon_dig_monitor_is_duallink(encoder,
mode-clock);
if ((radeon_encoder-devices
(ATOM_DEVICE_LCD_SUPPORT | ATOM_DEVICE_DFP_SUPPORT)) ||
(radeon_encoder_get_dp_bridge_encoder_id(encoder)
!= ENCODER_OBJECT_ID_NONE)) {
+ struct drm_connector *connector =
radeon_get_connector_for_encoder(encoder);
if (connector) {
struct radeon_connector
*radeon_connector = to_radeon_connector(connector);
struct radeon_connector_atom_dig
*dig_connector =
@@ -645,7 +641,7 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
if (encoder_mode ==
ATOM_ENCODER_MODE_HDMI)
/* deep color support */
args.v3.sInput.usPixelClock =
-
cpu_to_le16((mode-clock * bpc / 8) / 10);
+
cpu_to_le16(mode-clock / 10);
if (dig-coherent_mode)
args.v3.sInput.ucDispPllConfig
|=
DISPPLL_CONFIG_COHERENT_MODE;
@@ -753,7 +749,6 @@ static void atombios_crtc_program_pll(struct drm_crtc
*crtc,
u32 fb_div,
u32 frac_fb_div,
Re: radeon + DVI-mDP converter + mDP display blank screen issue since 3.0
On Fri, Mar 23, 2012 at 10:59:27AM -0400, Alex Deucher wrote:
Since Linux 3.0, a system with a Radeon HD 5450 (1002:68f9) connected
to a 27 Apple LED cinema display via an Atlona AT-DP400 Dual Link DVI
to Mini DisplayPort converter has started to stop giving screen
output on switching from text mode to graphical framebuffer during
system startup.
I finally had some time to look at this, and it seems to have stopped
working after this commit:
commit df271bec805b42527d864777ed035fcbb42e76c0
Author: Alex Deucher alexdeuc...@gmail.com
Date: Fri May 20 04:34:15 2011 -0400
drm/radeon/kms: properly handle bpc 8 in atom command tables
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
Signed-off-by: Dave Airlie airl...@redhat.com
...and with the patch below (i.e. reverting part of the commit above)
applied to 3.3 I get screen output again.
Even though the monitor seems to have an 8 bit panel, it reports 10
bits per channel in its EDID:
[...]
Manufacturer: APP Model 9226 Serial Number 41959462
Made week 38 of 2010
EDID version: 1.4
Digital display
10 bits per primary color channel
DisplayPort interface
Maximum image size: 60 cm x 34 cm
[...]
The (active, dual link) DVI-mDP converter spec sheet says it supports
24 bit color, and I'm guessing that it can't deal with 30. Is the
converter at fault here for passing through the EDID unchanged?
Also, what would be the right way to handle this, a kernel command
line or module option to limit color depth or something like that?
(Buy a video card with DP output. is a valid answer, I suppose.)
I have no clue at all about graphics, and I have no idea whatsoever
what I'm doing here, but I just wanted to post this somewhere for
Google to find in case someone else runs into this!
I've inquired with out display team on how to best handle this. In
the meantime, it's probably best to just default to 8 bpc. Does the
attached patch fix your issue?
I've been using the patch below in a custom Fedora 17 kernel RPM, and
that seems to fix the issue. Your patch seems to be a superset of
this patch, so logically, your patch should do the trick as well. :)
thanks,
Lennert
diff -up linux-3.3.0-1.fc17.x86_64/drivers/gpu/drm/radeon/atombios_crtc.c.orig
linux-3.3.0-1.fc17.x86_64/drivers/gpu/drm/radeon/atombios_crtc.c
--- linux-3.3.0-1.fc17.x86_64/drivers/gpu/drm/radeon/atombios_crtc.c.orig
2012-03-22 14:52:20.538854547 +0100
+++ linux-3.3.0-1.fc17.x86_64/drivers/gpu/drm/radeon/atombios_crtc.c
2012-03-22 14:55:39.740794113 +0100
@@ -550,8 +550,6 @@ static u32 atombios_adjust_pll(struct dr
if (encoder-crtc == crtc) {
radeon_encoder = to_radeon_encoder(encoder);
connector = radeon_get_connector_for_encoder(encoder);
- if (connector connector-display_info.bpc)
- bpc = connector-display_info.bpc;
encoder_mode = atombios_get_encoder_mode(encoder);
is_duallink = radeon_dig_monitor_is_duallink(encoder,
mode-clock);
if ((radeon_encoder-devices (ATOM_DEVICE_LCD_SUPPORT
| ATOM_DEVICE_DFP_SUPPORT)) ||
@@ -922,7 +920,6 @@ static void atombios_crtc_set_pll(struct
struct radeon_connector_atom_dig *dig_connector =
radeon_connector-con_priv;
int dp_clock;
- bpc = connector-display_info.bpc;
switch (encoder_mode) {
case ATOM_ENCODER_MODE_DP_MST:
From 22ca454eb749968f266d6788a5f4778acc08cc66 Mon Sep 17 00:00:00 2001
From: Alex Deucher alexander.deuc...@amd.com
Date: Fri, 23 Mar 2012 10:54:45 -0400
Subject: [PATCH] drm/radeon/kms/atom: force bpc to 8 for now
Using the bpc (bits per color) specified by the monitor
can cause problems in some cases. Until we get a better
handle on how to deal with those cases, just use a bpc of 8.
Reported-by: Lennert Buytenhek buyt...@wantstofly.org
Signed-off-by: Alex Deucher alexander.deuc...@amd.com
Cc: sta...@kernel.org
---
drivers/gpu/drm/radeon/atombios_crtc.c |8 +---
drivers/gpu/drm/radeon/atombios_dp.c |3 +++
drivers/gpu/drm/radeon/atombios_encoders.c |4 ++--
3 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
b/drivers/gpu/drm/radeon/atombios_crtc.c
index 083b3ea..b5ff1f7 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -588,8 +588,8 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
if (encoder-crtc == crtc) {
radeon_encoder = to_radeon_encoder(encoder);
connector = radeon_get_connector_for_encoder(encoder);
-
Re: radeon + DVI-mDP converter + mDP display blank screen issue since 3.0
On Fri, Mar 23, 2012 at 11:44 AM, Lennert Buytenhek
buyt...@wantstofly.org wrote:
On Fri, Mar 23, 2012 at 10:59:27AM -0400, Alex Deucher wrote:
Since Linux 3.0, a system with a Radeon HD 5450 (1002:68f9) connected
to a 27 Apple LED cinema display via an Atlona AT-DP400 Dual Link DVI
to Mini DisplayPort converter has started to stop giving screen
output on switching from text mode to graphical framebuffer during
system startup.
I finally had some time to look at this, and it seems to have stopped
working after this commit:
commit df271bec805b42527d864777ed035fcbb42e76c0
Author: Alex Deucher alexdeuc...@gmail.com
Date: Fri May 20 04:34:15 2011 -0400
drm/radeon/kms: properly handle bpc 8 in atom command tables
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
Signed-off-by: Dave Airlie airl...@redhat.com
...and with the patch below (i.e. reverting part of the commit above)
applied to 3.3 I get screen output again.
Even though the monitor seems to have an 8 bit panel, it reports 10
bits per channel in its EDID:
[...]
Manufacturer: APP Model 9226 Serial Number 41959462
Made week 38 of 2010
EDID version: 1.4
Digital display
10 bits per primary color channel
DisplayPort interface
Maximum image size: 60 cm x 34 cm
[...]
The (active, dual link) DVI-mDP converter spec sheet says it supports
24 bit color, and I'm guessing that it can't deal with 30. Is the
converter at fault here for passing through the EDID unchanged?
Also, what would be the right way to handle this, a kernel command
line or module option to limit color depth or something like that?
(Buy a video card with DP output. is a valid answer, I suppose.)
I have no clue at all about graphics, and I have no idea whatsoever
what I'm doing here, but I just wanted to post this somewhere for
Google to find in case someone else runs into this!
I've inquired with out display team on how to best handle this. In
the meantime, it's probably best to just default to 8 bpc. Does the
attached patch fix your issue?
I've been using the patch below in a custom Fedora 17 kernel RPM, and
that seems to fix the issue. Your patch seems to be a superset of
this patch, so logically, your patch should do the trick as well. :)
Can you try the attached patch on top of my previous one?
Alex
thanks,
Lennert
diff -up
linux-3.3.0-1.fc17.x86_64/drivers/gpu/drm/radeon/atombios_crtc.c.orig
linux-3.3.0-1.fc17.x86_64/drivers/gpu/drm/radeon/atombios_crtc.c
--- linux-3.3.0-1.fc17.x86_64/drivers/gpu/drm/radeon/atombios_crtc.c.orig
2012-03-22 14:52:20.538854547 +0100
+++ linux-3.3.0-1.fc17.x86_64/drivers/gpu/drm/radeon/atombios_crtc.c
2012-03-22 14:55:39.740794113 +0100
@@ -550,8 +550,6 @@ static u32 atombios_adjust_pll(struct dr
if (encoder-crtc == crtc) {
radeon_encoder = to_radeon_encoder(encoder);
connector = radeon_get_connector_for_encoder(encoder);
- if (connector connector-display_info.bpc)
- bpc = connector-display_info.bpc;
encoder_mode = atombios_get_encoder_mode(encoder);
is_duallink = radeon_dig_monitor_is_duallink(encoder,
mode-clock);
if ((radeon_encoder-devices
(ATOM_DEVICE_LCD_SUPPORT | ATOM_DEVICE_DFP_SUPPORT)) ||
@@ -922,7 +920,6 @@ static void atombios_crtc_set_pll(struct
struct radeon_connector_atom_dig *dig_connector =
radeon_connector-con_priv;
int dp_clock;
- bpc = connector-display_info.bpc;
switch (encoder_mode) {
case ATOM_ENCODER_MODE_DP_MST:
From 22ca454eb749968f266d6788a5f4778acc08cc66 Mon Sep 17 00:00:00 2001
From: Alex Deucher alexander.deuc...@amd.com
Date: Fri, 23 Mar 2012 10:54:45 -0400
Subject: [PATCH] drm/radeon/kms/atom: force bpc to 8 for now
Using the bpc (bits per color) specified by the monitor
can cause problems in some cases. Until we get a better
handle on how to deal with those cases, just use a bpc of 8.
Reported-by: Lennert Buytenhek buyt...@wantstofly.org
Signed-off-by: Alex Deucher alexander.deuc...@amd.com
Cc: sta...@kernel.org
---
drivers/gpu/drm/radeon/atombios_crtc.c | 8 +---
drivers/gpu/drm/radeon/atombios_dp.c | 3 +++
drivers/gpu/drm/radeon/atombios_encoders.c | 4 ++--
3 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
b/drivers/gpu/drm/radeon/atombios_crtc.c
index 083b3ea..b5ff1f7 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -588,8 +588,8 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
if (encoder-crtc == crtc) {
Re: radeon + DVI-mDP converter + mDP display blank screen issue since 3.0
On Fri, Mar 23, 2012 at 3:34 PM, Alex Deucher alexdeuc...@gmail.com wrote:
On Fri, Mar 23, 2012 at 11:44 AM, Lennert Buytenhek
buyt...@wantstofly.org wrote:
On Fri, Mar 23, 2012 at 10:59:27AM -0400, Alex Deucher wrote:
Since Linux 3.0, a system with a Radeon HD 5450 (1002:68f9) connected
to a 27 Apple LED cinema display via an Atlona AT-DP400 Dual Link DVI
to Mini DisplayPort converter has started to stop giving screen
output on switching from text mode to graphical framebuffer during
system startup.
I finally had some time to look at this, and it seems to have stopped
working after this commit:
commit df271bec805b42527d864777ed035fcbb42e76c0
Author: Alex Deucher alexdeuc...@gmail.com
Date: Fri May 20 04:34:15 2011 -0400
drm/radeon/kms: properly handle bpc 8 in atom command tables
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
Signed-off-by: Dave Airlie airl...@redhat.com
...and with the patch below (i.e. reverting part of the commit above)
applied to 3.3 I get screen output again.
Even though the monitor seems to have an 8 bit panel, it reports 10
bits per channel in its EDID:
[...]
Manufacturer: APP Model 9226 Serial Number 41959462
Made week 38 of 2010
EDID version: 1.4
Digital display
10 bits per primary color channel
DisplayPort interface
Maximum image size: 60 cm x 34 cm
[...]
The (active, dual link) DVI-mDP converter spec sheet says it supports
24 bit color, and I'm guessing that it can't deal with 30. Is the
converter at fault here for passing through the EDID unchanged?
Also, what would be the right way to handle this, a kernel command
line or module option to limit color depth or something like that?
(Buy a video card with DP output. is a valid answer, I suppose.)
I have no clue at all about graphics, and I have no idea whatsoever
what I'm doing here, but I just wanted to post this somewhere for
Google to find in case someone else runs into this!
I've inquired with out display team on how to best handle this. In
the meantime, it's probably best to just default to 8 bpc. Does the
attached patch fix your issue?
I've been using the patch below in a custom Fedora 17 kernel RPM, and
that seems to fix the issue. Your patch seems to be a superset of
this patch, so logically, your patch should do the trick as well. :)
Can you try the attached patch on top of my previous one?
Scratch that. Try this one instead.
Alex
Alex
thanks,
Lennert
diff -up
linux-3.3.0-1.fc17.x86_64/drivers/gpu/drm/radeon/atombios_crtc.c.orig
linux-3.3.0-1.fc17.x86_64/drivers/gpu/drm/radeon/atombios_crtc.c
--- linux-3.3.0-1.fc17.x86_64/drivers/gpu/drm/radeon/atombios_crtc.c.orig
2012-03-22 14:52:20.538854547 +0100
+++ linux-3.3.0-1.fc17.x86_64/drivers/gpu/drm/radeon/atombios_crtc.c
2012-03-22 14:55:39.740794113 +0100
@@ -550,8 +550,6 @@ static u32 atombios_adjust_pll(struct dr
if (encoder-crtc == crtc) {
radeon_encoder = to_radeon_encoder(encoder);
connector = radeon_get_connector_for_encoder(encoder);
- if (connector connector-display_info.bpc)
- bpc = connector-display_info.bpc;
encoder_mode = atombios_get_encoder_mode(encoder);
is_duallink = radeon_dig_monitor_is_duallink(encoder,
mode-clock);
if ((radeon_encoder-devices
(ATOM_DEVICE_LCD_SUPPORT | ATOM_DEVICE_DFP_SUPPORT)) ||
@@ -922,7 +920,6 @@ static void atombios_crtc_set_pll(struct
struct radeon_connector_atom_dig *dig_connector =
radeon_connector-con_priv;
int dp_clock;
- bpc = connector-display_info.bpc;
switch (encoder_mode) {
case ATOM_ENCODER_MODE_DP_MST:
From 22ca454eb749968f266d6788a5f4778acc08cc66 Mon Sep 17 00:00:00 2001
From: Alex Deucher alexander.deuc...@amd.com
Date: Fri, 23 Mar 2012 10:54:45 -0400
Subject: [PATCH] drm/radeon/kms/atom: force bpc to 8 for now
Using the bpc (bits per color) specified by the monitor
can cause problems in some cases. Until we get a better
handle on how to deal with those cases, just use a bpc of 8.
Reported-by: Lennert Buytenhek buyt...@wantstofly.org
Signed-off-by: Alex Deucher alexander.deuc...@amd.com
Cc: sta...@kernel.org
---
drivers/gpu/drm/radeon/atombios_crtc.c | 8 +---
drivers/gpu/drm/radeon/atombios_dp.c | 3 +++
drivers/gpu/drm/radeon/atombios_encoders.c | 4 ++--
3 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
b/drivers/gpu/drm/radeon/atombios_crtc.c
index 083b3ea..b5ff1f7 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++
radeon + DVI->mDP converter + mDP display blank screen issue since 3.0
Hi!
Since Linux 3.0, a system with a Radeon HD 5450 (1002:68f9) connected
to a 27" Apple LED cinema display via an Atlona AT-DP400 Dual Link DVI
to Mini DisplayPort converter has started to stop giving screen
output on switching from text mode to graphical framebuffer during
system startup.
I finally had some time to look at this, and it seems to have stopped
working after this commit:
commit df271bec805b42527d864777ed035fcbb42e76c0
Author: Alex Deucher
Date: Fri May 20 04:34:15 2011 -0400
drm/radeon/kms: properly handle bpc >8 in atom command tables
Signed-off-by: Alex Deucher
Signed-off-by: Dave Airlie
...and with the patch below (i.e. reverting part of the commit above)
applied to 3.3 I get screen output again.
Even though the monitor seems to have an 8 bit panel, it reports 10
bits per channel in its EDID:
[...]
Manufacturer: APP Model 9226 Serial Number 41959462
Made week 38 of 2010
EDID version: 1.4
Digital display
10 bits per primary color channel
DisplayPort interface
Maximum image size: 60 cm x 34 cm
[...]
The (active, dual link) DVI->mDP converter spec sheet says it supports
24 bit color, and I'm guessing that it can't deal with 30. Is the
converter at fault here for passing through the EDID unchanged?
Also, what would be the right way to handle this, a kernel command
line or module option to limit color depth or something like that?
("Buy a video card with DP output." is a valid answer, I suppose.)
I have no clue at all about graphics, and I have no idea whatsoever
what I'm doing here, but I just wanted to post this somewhere for
Google to find in case someone else runs into this!
thanks,
Lennert
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
b/drivers/gpu/drm/radeon/atombios_crtc.c
index 742f17f..77a6a04 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -513,11 +513,9 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
struct radeon_device *rdev = dev->dev_private;
struct drm_encoder *encoder = NULL;
struct radeon_encoder *radeon_encoder = NULL;
- struct drm_connector *connector = NULL;
u32 adjusted_clock = mode->clock;
int encoder_mode = 0;
u32 dp_clock = mode->clock;
- int bpc = 8;
bool is_duallink = false;
/* reset the pll flags */
@@ -549,13 +547,11 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
list_for_each_entry(encoder, >mode_config.encoder_list, head) {
if (encoder->crtc == crtc) {
radeon_encoder = to_radeon_encoder(encoder);
- connector = radeon_get_connector_for_encoder(encoder);
- if (connector && connector->display_info.bpc)
- bpc = connector->display_info.bpc;
encoder_mode = atombios_get_encoder_mode(encoder);
is_duallink = radeon_dig_monitor_is_duallink(encoder,
mode->clock);
if ((radeon_encoder->devices & (ATOM_DEVICE_LCD_SUPPORT
| ATOM_DEVICE_DFP_SUPPORT)) ||
(radeon_encoder_get_dp_bridge_encoder_id(encoder)
!= ENCODER_OBJECT_ID_NONE)) {
+ struct drm_connector *connector =
radeon_get_connector_for_encoder(encoder);
if (connector) {
struct radeon_connector
*radeon_connector = to_radeon_connector(connector);
struct radeon_connector_atom_dig
*dig_connector =
@@ -645,7 +641,7 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
if (encoder_mode ==
ATOM_ENCODER_MODE_HDMI)
/* deep color support */
args.v3.sInput.usPixelClock =
-
cpu_to_le16((mode->clock * bpc / 8) / 10);
+ cpu_to_le16(mode->clock
/ 10);
if (dig->coherent_mode)
args.v3.sInput.ucDispPllConfig
|=
DISPPLL_CONFIG_COHERENT_MODE;
@@ -753,7 +749,6 @@ static void atombios_crtc_program_pll(struct drm_crtc *crtc,
u32 fb_div,
u32 frac_fb_div,
u32 post_div,
- int bpc,
bool ss_enabled,
struct radeon_atom_ss *ss)
{
@@ -817,15 +812,6 @@ static void atombios_crtc_program_pll(struct drm_crtc
*crtc,
args.v5.ucMiscInfo = 0; /* HDMI depth,
