Hi guys,
so I'm booting 15-rc1 + tip/master and around the time modesetting gets
initialized, the screen blanks and on it appears a message from the
monitors:
"The current input timing is not supported by the monitor display.
Please change your input timing to 1920x1200@60Hz or any other monitor
listed timing as per the monitor specifications."
The box is still responsive, I can reboot it with Ctrl-Alt-Del but
screens are blank.
If I boot with radeon.modeset=0, I see the normal nomodeset big letters
on the console and not very optimal screen resolution.
Diffing drm init chatter from dmesg shows only this:
--- /tmp/working 2014-04-15 08:40:21.979985352 +0200
+++ /tmp/b0rked 2014-04-15 08:40:11.983985364 +0200
@@ -44,4 +44,5 @@
[drm] pitch is 7680
fbcon: radeondrmfb (fb0) is primary device
radeon 0000:01:00.0: fb0: radeondrmfb frame buffer device
-[drm] Initialized radeon 2.37.0 20080528 for 0000:01:00.0 on minor 0
+[drm] Initialized radeon 2.38.0 20080528 for 0000:01:00.0 on minor 0
+
Below is the whole thing, btw.
Anyway, if you guys have any ideas, I'm all ears. Otherwise, would a quick
bisect on the 59 patches touching drivers/gpu/drm/radeon/ make sense?
git log --oneline v3.14.. drivers/gpu/drm/radeon/ | wc -l
59
Thanks.
[drm] Initialized drm 1.1.0 20060810
[drm] radeon kernel modesetting enabled.
[drm] initializing kernel modesetting (RV635 0x1002:0x9598 0x1043:0x01DA).
[drm] register mmio base: 0xFEA20000
[drm] register mmio size: 65536
[drm] Detected VRAM RAM=512M, BAR=256M
[drm] RAM width 128bits DDR
[drm] radeon: 512M of VRAM memory ready
[drm] radeon: 512M of GTT memory ready.
[drm] Loading RV635 Microcode
[drm] Internal thermal controller without fan control
[drm] radeon: power management initialized
[drm] GART: num cpu pages 131072, num gpu pages 131072
[drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0
[drm] PCIE GART of 512M enabled (table at 0x0000000000040000).
[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] Driver supports precise vblank timestamp query.
[drm] radeon: irq initialized.
[drm] ring test on 0 succeeded in 0 usecs
[drm] ib test on ring 0 succeeded in 0 usecs
[drm] Radeon Display Connectors
[drm] Connector 0:
[drm] DVI-I-1
[drm] HPD1
[drm] DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
[drm] Encoders:
[drm] DFP1: INTERNAL_UNIPHY
[drm] CRT2: INTERNAL_KLDSCP_DAC2
[drm] Connector 1:
[drm] DIN-1
[drm] Encoders:
[drm] TV1: INTERNAL_KLDSCP_DAC2
[drm] Connector 2:
[drm] DVI-I-2
[drm] HPD2
[drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
[drm] Encoders:
[drm] CRT1: INTERNAL_KLDSCP_DAC1
[drm] DFP2: INTERNAL_KLDSCP_LVTMA
[drm] fb mappable at 0xC0141000
[drm] vram apper at 0xC0000000
[drm] size 9216000
[drm] fb depth is 24
[drm] pitch is 7680
fbcon: radeondrmfb (fb0) is primary device
radeon 0000:01:00.0: fb0: radeondrmfb frame buffer device
[drm] Initialized radeon 2.38.0 20080528 for 0000:01:00.0 on minor 0
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
Hi Borislav,
that's a known issue and should be fixed in the next rc, see this
bugreport: https://bugs.freedesktop.org/show_bug.cgi?id=77009
You might also want to try my branch with 3.15 fixes which includes the
necessary patch for this:
http://cgit.freedesktop.org/~deathsimple/linux/log/?h=drm-fixes-3.15-wip
Let me know if that branch works for you or not.
Regards,
Christian.
Am 15.04.2014 09:02, schrieb Borislav Petkov:
> Hi guys,
>
> so I'm booting 15-rc1 + tip/master and around the time modesetting gets
> initialized, the screen blanks and on it appears a message from the
> monitors:
>
> "The current input timing is not supported by the monitor display.
> Please change your input timing to 1920x1200@60Hz or any other monitor
> listed timing as per the monitor specifications."
>
> The box is still responsive, I can reboot it with Ctrl-Alt-Del but
> screens are blank.
>
> If I boot with radeon.modeset=0, I see the normal nomodeset big letters
> on the console and not very optimal screen resolution.
>
> Diffing drm init chatter from dmesg shows only this:
>
> --- /tmp/working 2014-04-15 08:40:21.979985352 +0200
> +++ /tmp/b0rked 2014-04-15 08:40:11.983985364 +0200
> @@ -44,4 +44,5 @@
> [drm] pitch is 7680
> fbcon: radeondrmfb (fb0) is primary device
> radeon 0000:01:00.0: fb0: radeondrmfb frame buffer device
> -[drm] Initialized radeon 2.37.0 20080528 for 0000:01:00.0 on minor 0
> +[drm] Initialized radeon 2.38.0 20080528 for 0000:01:00.0 on minor 0
> +
>
> Below is the whole thing, btw.
>
> Anyway, if you guys have any ideas, I'm all ears. Otherwise, would a quick
> bisect on the 59 patches touching drivers/gpu/drm/radeon/ make sense?
>
> git log --oneline v3.14.. drivers/gpu/drm/radeon/ | wc -l
> 59
>
> Thanks.
>
> [drm] Initialized drm 1.1.0 20060810
> [drm] radeon kernel modesetting enabled.
> [drm] initializing kernel modesetting (RV635 0x1002:0x9598 0x1043:0x01DA).
> [drm] register mmio base: 0xFEA20000
> [drm] register mmio size: 65536
> [drm] Detected VRAM RAM=512M, BAR=256M
> [drm] RAM width 128bits DDR
> [drm] radeon: 512M of VRAM memory ready
> [drm] radeon: 512M of GTT memory ready.
> [drm] Loading RV635 Microcode
> [drm] Internal thermal controller without fan control
> [drm] radeon: power management initialized
> [drm] GART: num cpu pages 131072, num gpu pages 131072
> [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0
> [drm] PCIE GART of 512M enabled (table at 0x0000000000040000).
> [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [drm] Driver supports precise vblank timestamp query.
> [drm] radeon: irq initialized.
> [drm] ring test on 0 succeeded in 0 usecs
> [drm] ib test on ring 0 succeeded in 0 usecs
> [drm] Radeon Display Connectors
> [drm] Connector 0:
> [drm] DVI-I-1
> [drm] HPD1
> [drm] DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
> [drm] Encoders:
> [drm] DFP1: INTERNAL_UNIPHY
> [drm] CRT2: INTERNAL_KLDSCP_DAC2
> [drm] Connector 1:
> [drm] DIN-1
> [drm] Encoders:
> [drm] TV1: INTERNAL_KLDSCP_DAC2
> [drm] Connector 2:
> [drm] DVI-I-2
> [drm] HPD2
> [drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
> [drm] Encoders:
> [drm] CRT1: INTERNAL_KLDSCP_DAC1
> [drm] DFP2: INTERNAL_KLDSCP_LVTMA
> [drm] fb mappable at 0xC0141000
> [drm] vram apper at 0xC0000000
> [drm] size 9216000
> [drm] fb depth is 24
> [drm] pitch is 7680
> fbcon: radeondrmfb (fb0) is primary device
> radeon 0000:01:00.0: fb0: radeondrmfb frame buffer device
> [drm] Initialized radeon 2.38.0 20080528 for 0000:01:00.0 on minor 0
>
Hi Christian,
On Tue, Apr 15, 2014 at 11:28:55AM +0200, Christian König wrote:
> Hi Borislav,
>
> that's a known issue and should be fixed in the next rc, see this
> bugreport: https://bugs.freedesktop.org/show_bug.cgi?id=77009
>
> You might also want to try my branch with 3.15 fixes which includes
> the necessary patch for this: http://cgit.freedesktop.org/~deathsimple/linux/log/?h=drm-fixes-3.15-wip
>
> Let me know if that branch works for you or not.
so I went and merged your branch as you suggested. Btw, on its tip it
has:
commit ec02666dd0791312b5820e1a9a023681d99d07ec
Author: Quentin Casasnovas <[email protected]>
Date: Tue Mar 18 17:16:52 2014 +0100
drm/radeon: memory leak on bo reservation failure. v2
(just checking whether I got the right one)
and, unfortunately, no change - same problem. Let me know if I should
bisect the subset of 59 radeon patches which went in during the merge
window...
Btw, just in case, I went and updated radeon firmware in
/lib/firmware/radeon/ from upstream but it didn't change anything.
Thanks.
On Tue, Apr 15, 2014 at 8:07 AM, Borislav Petkov <[email protected]> wrote:
> Hi Christian,
>
> On Tue, Apr 15, 2014 at 11:28:55AM +0200, Christian König wrote:
>> Hi Borislav,
>>
>> that's a known issue and should be fixed in the next rc, see this
>> bugreport: https://bugs.freedesktop.org/show_bug.cgi?id=77009
>>
>> You might also want to try my branch with 3.15 fixes which includes
>> the necessary patch for this: http://cgit.freedesktop.org/~deathsimple/linux/log/?h=drm-fixes-3.15-wip
>>
>> Let me know if that branch works for you or not.
>
> so I went and merged your branch as you suggested. Btw, on its tip it
> has:
>
> commit ec02666dd0791312b5820e1a9a023681d99d07ec
> Author: Quentin Casasnovas <[email protected]>
> Date: Tue Mar 18 17:16:52 2014 +0100
>
> drm/radeon: memory leak on bo reservation failure. v2
>
> (just checking whether I got the right one)
>
> and, unfortunately, no change - same problem. Let me know if I should
> bisect the subset of 59 radeon patches which went in during the merge
> window...
>
> Btw, just in case, I went and updated radeon firmware in
> /lib/firmware/radeon/ from upstream but it didn't change anything.
Does reverting:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=32167016076f714f0e35e287fbead7de0f1fb179
fix the issue? We may need to tweak the pll parameters for older asics.
Alex
>
> Thanks.
> _______________________________________________
> dri-devel mailing list
> [email protected]
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> Does reverting:
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=32167016076f714f0e35e287fbead7de0f1fb179
> fix the issue? We may need to tweak the pll parameters for older asics.
Yeah, indeed the most likely cause. Please provide dmesg outputs created
with drm.ebug=0xe for the old and the new kernel.
Christian.
Am 15.04.2014 15:06, schrieb Alex Deucher:
> On Tue, Apr 15, 2014 at 8:07 AM, Borislav Petkov <[email protected]> wrote:
>> Hi Christian,
>>
>> On Tue, Apr 15, 2014 at 11:28:55AM +0200, Christian König wrote:
>>> Hi Borislav,
>>>
>>> that's a known issue and should be fixed in the next rc, see this
>>> bugreport: https://bugs.freedesktop.org/show_bug.cgi?id=77009
>>>
>>> You might also want to try my branch with 3.15 fixes which includes
>>> the necessary patch for this: http://cgit.freedesktop.org/~deathsimple/linux/log/?h=drm-fixes-3.15-wip
>>>
>>> Let me know if that branch works for you or not.
>> so I went and merged your branch as you suggested. Btw, on its tip it
>> has:
>>
>> commit ec02666dd0791312b5820e1a9a023681d99d07ec
>> Author: Quentin Casasnovas <[email protected]>
>> Date: Tue Mar 18 17:16:52 2014 +0100
>>
>> drm/radeon: memory leak on bo reservation failure. v2
>>
>> (just checking whether I got the right one)
>>
>> and, unfortunately, no change - same problem. Let me know if I should
>> bisect the subset of 59 radeon patches which went in during the merge
>> window...
>>
>> Btw, just in case, I went and updated radeon firmware in
>> /lib/firmware/radeon/ from upstream but it didn't change anything.
> Does reverting:
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=32167016076f714f0e35e287fbead7de0f1fb179
> fix the issue? We may need to tweak the pll parameters for older asics.
>
> Alex
>
>> Thanks.
>> _______________________________________________
>> dri-devel mailing list
>> [email protected]
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Tue, Apr 15, 2014 at 03:09:02PM +0200, Christian König wrote:
> >Does reverting:
> >http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=32167016076f714f0e35e287fbead7de0f1fb179
> >fix the issue? We may need to tweak the pll parameters for older asics.
>
> Yeah, indeed the most likely cause. Please provide dmesg outputs created
> with drm.ebug=0xe for the old and the new kernel.
Hey, I finally haz 15-rc1+ running here. And I can even see something!
:-)
Ok, so I reverted 32167016076f ontop of Christian's drm-fixes-3.15-wip
branch which didn't apply cleanly. So I ended up fixing the conflicts
and got the revert below.
With it, the machine booted fine, so it looks like the revert worked.
Christian, I'm sending dmesg outputs in another private mail to you
guys.
Thanks.
---
From: Borislav Petkov <[email protected]>
Date: Tue, 15 Apr 2014 16:00:58 +0200
Subject: [PATCH] Revert "drm/radeon: rework finding display PLL numbers v2"
This reverts commit 32167016076f714f0e35e287fbead7de0f1fb179.
Conflicts:
drivers/gpu/drm/radeon/radeon_display.c
---
drivers/gpu/drm/radeon/radeon_display.c | 246 ++++++++++++--------------------
1 file changed, 90 insertions(+), 156 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_display.c b/drivers/gpu/drm/radeon/radeon_display.c
index 2f42912031ac..83891923ac2d 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -34,8 +34,6 @@
#include <drm/drm_crtc_helper.h>
#include <drm/drm_edid.h>
-#include <linux/gcd.h>
-
static void avivo_crtc_load_lut(struct drm_crtc *crtc)
{
struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
@@ -802,57 +800,66 @@ int radeon_ddc_get_modes(struct radeon_connector *radeon_connector)
}
/* avivo */
+static void avivo_get_fb_div(struct radeon_pll *pll,
+ u32 target_clock,
+ u32 post_div,
+ u32 ref_div,
+ u32 *fb_div,
+ u32 *frac_fb_div)
+{
+ u32 tmp = post_div * ref_div;
-/**
- * avivo_reduce_ratio - fractional number reduction
- *
- * @nom: nominator
- * @den: denominator
- * @nom_min: minimum value for nominator
- * @den_min: minimum value for denominator
- *
- * Find the greatest common divisor and apply it on both nominator and
- * denominator, but make nominator and denominator are at least as large
- * as their minimum values.
- */
-static void avivo_reduce_ratio(unsigned *nom, unsigned *den,
- unsigned nom_min, unsigned den_min)
+ tmp *= target_clock;
+ *fb_div = tmp / pll->reference_freq;
+ *frac_fb_div = tmp % pll->reference_freq;
+
+ if (*fb_div > pll->max_feedback_div)
+ *fb_div = pll->max_feedback_div;
+ else if (*fb_div < pll->min_feedback_div)
+ *fb_div = pll->min_feedback_div;
+}
+
+static u32 avivo_get_post_div(struct radeon_pll *pll,
+ u32 target_clock)
{
- unsigned tmp;
-
- /* reduce the numbers to a simpler ratio */
- tmp = gcd(*nom, *den);
- *nom /= tmp;
- *den /= tmp;
-
- /* make sure nominator is large enough */
- if (*nom < nom_min) {
- tmp = (nom_min + *nom - 1) / *nom;
- *nom *= tmp;
- *den *= tmp;
+ u32 vco, post_div, tmp;
+
+ if (pll->flags & RADEON_PLL_USE_POST_DIV)
+ return pll->post_div;
+
+ if (pll->flags & RADEON_PLL_PREFER_MINM_OVER_MAXP) {
+ if (pll->flags & RADEON_PLL_IS_LCD)
+ vco = pll->lcd_pll_out_min;
+ else
+ vco = pll->pll_out_min;
+ } else {
+ if (pll->flags & RADEON_PLL_IS_LCD)
+ vco = pll->lcd_pll_out_max;
+ else
+ vco = pll->pll_out_max;
}
- /* make sure the denominator is large enough */
- if (*den < den_min) {
- tmp = (den_min + *den - 1) / *den;
- *nom *= tmp;
- *den *= tmp;
+ post_div = vco / target_clock;
+ tmp = vco % target_clock;
+
+ if (pll->flags & RADEON_PLL_PREFER_MINM_OVER_MAXP) {
+ if (tmp)
+ post_div++;
+ } else {
+ if (!tmp)
+ post_div--;
}
+
+ if (post_div > pll->max_post_div)
+ post_div = pll->max_post_div;
+ else if (post_div < pll->min_post_div)
+ post_div = pll->min_post_div;
+
+ return post_div;
}
-/**
- * radeon_compute_pll_avivo - compute PLL paramaters
- *
- * @pll: information about the PLL
- * @dot_clock_p: resulting pixel clock
- * fb_div_p: resulting feedback divider
- * frac_fb_div_p: fractional part of the feedback divider
- * ref_div_p: resulting reference divider
- * post_div_p: resulting reference divider
- *
- * Try to calculate the PLL parameters to generate the given frequency:
- * dot_clock = (ref_freq * feedback_div) / (ref_div * post_div)
- */
+#define MAX_TOLERANCE 10
+
void radeon_compute_pll_avivo(struct radeon_pll *pll,
u32 freq,
u32 *dot_clock_p,
@@ -861,126 +868,53 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll,
u32 *ref_div_p,
u32 *post_div_p)
{
- unsigned fb_div_min, fb_div_max, fb_div;
- unsigned post_div_min, post_div_max, post_div;
- unsigned ref_div_min, ref_div_max, ref_div;
- unsigned post_div_best, diff_best;
- unsigned nom, den, tmp;
-
- /* determine allowed feedback divider range */
- fb_div_min = pll->min_feedback_div;
- fb_div_max = pll->max_feedback_div;
+ u32 target_clock = freq / 10;
+ u32 post_div = avivo_get_post_div(pll, target_clock);
+ u32 ref_div = pll->min_ref_div;
+ u32 fb_div = 0, frac_fb_div = 0, tmp;
- if (pll->flags & RADEON_PLL_USE_FRAC_FB_DIV) {
- fb_div_min *= 10;
- fb_div_max *= 10;
- }
-
- /* determine allowed ref divider range */
if (pll->flags & RADEON_PLL_USE_REF_DIV)
- ref_div_min = pll->reference_div;
- else
- ref_div_min = pll->min_ref_div;
- ref_div_max = pll->max_ref_div;
+ ref_div = pll->reference_div;
- /* determine allowed post divider range */
- if (pll->flags & RADEON_PLL_USE_POST_DIV) {
- post_div_min = pll->post_div;
- post_div_max = pll->post_div;
- } else {
- unsigned target_clock = freq / 10;
- unsigned vco_min, vco_max;
-
- if (pll->flags & RADEON_PLL_IS_LCD) {
- vco_min = pll->lcd_pll_out_min;
- vco_max = pll->lcd_pll_out_max;
- } else {
- vco_min = pll->pll_out_min;
- vco_max = pll->pll_out_max;
+ if (pll->flags & RADEON_PLL_USE_FRAC_FB_DIV) {
+ avivo_get_fb_div(pll, target_clock, post_div, ref_div, &fb_div, &frac_fb_div);
+ frac_fb_div = (100 * frac_fb_div) / pll->reference_freq;
+ if (frac_fb_div >= 5) {
+ frac_fb_div -= 5;
+ frac_fb_div = frac_fb_div / 10;
+ frac_fb_div++;
}
-
- post_div_min = vco_min / target_clock;
- if ((target_clock * post_div_min) < vco_min)
- ++post_div_min;
- if (post_div_min < pll->min_post_div)
- post_div_min = pll->min_post_div;
-
- post_div_max = vco_max / target_clock;
- if ((target_clock * post_div_max) > vco_max)
- --post_div_max;
- if (post_div_max > pll->max_post_div)
- post_div_max = pll->max_post_div;
- }
-
- /* represent the searched ratio as fractional number */
- nom = pll->flags & RADEON_PLL_USE_FRAC_FB_DIV ? freq : freq / 10;
- den = pll->reference_freq;
-
- /* reduce the numbers to a simpler ratio */
- avivo_reduce_ratio(&nom, &den, fb_div_min, post_div_min);
-
- /* now search for a post divider */
- if (pll->flags & RADEON_PLL_PREFER_MINM_OVER_MAXP)
- post_div_best = post_div_min;
- else
- post_div_best = post_div_max;
- diff_best = ~0;
-
- for (post_div = post_div_min; post_div <= post_div_max; ++post_div) {
- unsigned diff = abs(den - den / post_div * post_div);
- if (diff < diff_best || (diff == diff_best &&
- !(pll->flags & RADEON_PLL_PREFER_MINM_OVER_MAXP))) {
-
- post_div_best = post_div;
- diff_best = diff;
+ if (frac_fb_div >= 10) {
+ fb_div++;
+ frac_fb_div = 0;
}
- }
- post_div = post_div_best;
-
- /* limit reference * post divider to a maximum */
- ref_div_max = min(210 / post_div, ref_div_max);
-
- /* get matching reference and feedback divider */
- ref_div = max(den / post_div, 1u);
- fb_div = nom;
-
- /* we're almost done, but reference and feedback
- divider might be to large now */
-
- tmp = ref_div;
-
- if (fb_div > fb_div_max) {
- ref_div = ref_div * fb_div_max / fb_div;
- fb_div = fb_div_max;
- }
-
- if (ref_div > ref_div_max) {
- ref_div = ref_div_max;
- fb_div = nom * ref_div_max / tmp;
- }
-
- /* reduce the numbers to a simpler ratio once more */
- /* this also makes sure that the reference divider is large enough */
- avivo_reduce_ratio(&fb_div, &ref_div, fb_div_min, ref_div_min);
-
- /* and finally save the result */
- if (pll->flags & RADEON_PLL_USE_FRAC_FB_DIV) {
- *fb_div_p = fb_div / 10;
- *frac_fb_div_p = fb_div % 10;
} else {
- *fb_div_p = fb_div;
- *frac_fb_div_p = 0;
+ while (ref_div <= pll->max_ref_div) {
+ avivo_get_fb_div(pll, target_clock, post_div, ref_div,
+ &fb_div, &frac_fb_div);
+ if (frac_fb_div >= (pll->reference_freq / 2))
+ fb_div++;
+ frac_fb_div = 0;
+ tmp = (pll->reference_freq * fb_div) / (post_div * ref_div);
+ tmp = (tmp * 10000) / target_clock;
+
+ if (tmp > (10000 + MAX_TOLERANCE))
+ ref_div++;
+ else if (tmp >= (10000 - MAX_TOLERANCE))
+ break;
+ else
+ ref_div++;
+ }
}
- *dot_clock_p = ((pll->reference_freq * *fb_div_p * 10) +
- (pll->reference_freq * *frac_fb_div_p)) /
- (ref_div * post_div * 10);
+ *dot_clock_p = ((pll->reference_freq * fb_div * 10) + (pll->reference_freq * frac_fb_div)) /
+ (ref_div * post_div * 10);
+ *fb_div_p = fb_div;
+ *frac_fb_div_p = frac_fb_div;
*ref_div_p = ref_div;
*post_div_p = post_div;
-
- DRM_DEBUG_KMS("%d - %d, pll dividers - fb: %d.%d ref: %d, post %d\n",
- freq, *dot_clock_p, *fb_div_p, *frac_fb_div_p,
- ref_div, post_div);
+ DRM_DEBUG_KMS("%d, pll dividers - fb: %d.%d ref: %d, post %d\n",
+ *dot_clock_p, fb_div, frac_fb_div, ref_div, post_div);
}
/* pre-avivo */
--
1.9.0
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
Alex Deucher wrote:
> On Tue, Apr 15, 2014 at 8:07 AM, Borislav Petkov <[email protected]> wrote:
>> Hi Christian,
>>
>> On Tue, Apr 15, 2014 at 11:28:55AM +0200, Christian König wrote:
>>> Hi Borislav,
>>>
>>> that's a known issue and should be fixed in the next rc, see this
>>> bugreport: https://bugs.freedesktop.org/show_bug.cgi?id=77009
>>>
>>> You might also want to try my branch with 3.15 fixes which includes
>>> the necessary patch for this: http://cgit.freedesktop.org/~deathsimple/linux/log/?h=drm-fixes-3.15-wip
>>>
>>> Let me know if that branch works for you or not.
>>
>> so I went and merged your branch as you suggested. Btw, on its tip it
>> has:
>>
>> commit ec02666dd0791312b5820e1a9a023681d99d07ec
>> Author: Quentin Casasnovas <[email protected]>
>> Date: Tue Mar 18 17:16:52 2014 +0100
>>
>> drm/radeon: memory leak on bo reservation failure. v2
>>
>> (just checking whether I got the right one)
>>
>> and, unfortunately, no change - same problem. Let me know if I should
>> bisect the subset of 59 radeon patches which went in during the merge
>> window...
>>
>> Btw, just in case, I went and updated radeon firmware in
>> /lib/firmware/radeon/ from upstream but it didn't change anything.
>
> Does reverting:
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=32167016076f714f0e35e287fbead7de0f1fb179
> fix the issue? We may need to tweak the pll parameters for older asics.
>
> Alex
>
>>
Same issue here (integrated Radeon HD 8570D), 64 bit Debian, kernel, drm, mesa built from git today. I see nothing and receive no message on the monitors (i have 2 identical ones, one on the DVI andother on HDMI), but the system is running fine otherwise it seems, i could switch to the console, log in and reboot blindly. Cristian's branch didnt help.
Reverting 32167016076f714f0e35e287fbead7de0f1fb179 did work.
Attached dmesg (booted the unmodified rc1 kernel, switched to tty1 and rebooted blindly).
--
O zi buna,
Kertesz Laszlo
On Tue, Apr 15, 2014 at 08:08:12PM +0300, Kertesz Laszlo wrote:
> Same issue here (integrated Radeon HD 8570D), 64 bit Debian, kernel,
> drm, mesa built from git today. I see nothing and receive no message
> on the monitors (i have 2 identical ones, one on the DVI andother on
> HDMI), but the system is running fine otherwise it seems, i could
> switch to the console, log in and reboot blindly. Cristian's branch
> didnt help.
>
> Reverting 32167016076f714f0e35e287fbead7de0f1fb179 did work.
Does booting with "radeon.modeset=0" help?
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
Borislav Petkov wrote:
> On Tue, Apr 15, 2014 at 08:08:12PM +0300, Kertesz Laszlo wrote:
>> Same issue here (integrated Radeon HD 8570D), 64 bit Debian, kernel,
>> drm, mesa built from git today. I see nothing and receive no message
>> on the monitors (i have 2 identical ones, one on the DVI andother on
>> HDMI), but the system is running fine otherwise it seems, i could
>> switch to the console, log in and reboot blindly. Cristian's branch
>> didnt help.
>>
>> Reverting 32167016076f714f0e35e287fbead7de0f1fb179 did work.
>
> Does booting with "radeon.modeset=0" help?
>
Honestly didnt try that but i assume yes, since the screens go black when it should change resolution.
--
O zi buna,
Kertesz Laszlo
On Tue, Apr 15, 2014 at 09:02:35PM +0300, Kertesz Laszlo wrote:
> Honestly didnt try that but i assume yes, since the screens go black
> when it should change resolution.
Pls try it and let us know whether you see the machine booting further,
albeit without modesetting.
Thanks.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
Borislav Petkov wrote:
> On Tue, Apr 15, 2014 at 09:02:35PM +0300, Kertesz Laszlo wrote:
>> Honestly didnt try that but i assume yes, since the screens go black
>> when it should change resolution.
>
> Pls try it and let us know whether you see the machine booting further,
> albeit without modesetting.
>
> Thanks.
>
Yes, it is working that way. But no X, i assume this is expected.
--
O zi buna,
Kertesz Laszlo
> -----Original Message-----
> From: Kertesz Laszlo [mailto:[email protected]]
> Sent: Tuesday, April 15, 2014 5:50 PM
> To: Borislav Petkov
> Cc: Alex Deucher; Deucher, Alexander; Koenig, Christian; Maling list - DRI
> developers; lkml
> Subject: Re: 15-rc1: radeon modesetting fails
>
> Borislav Petkov wrote:
> > On Tue, Apr 15, 2014 at 09:02:35PM +0300, Kertesz Laszlo wrote:
> >> Honestly didnt try that but i assume yes, since the screens go black
> >> when it should change resolution.
> >
> > Pls try it and let us know whether you see the machine booting further,
> > albeit without modesetting.
> >
> > Thanks.
> >
>
> Yes, it is working that way. But no X, i assume this is expected.
Turning off modesetting basically disables the driver.
Alex
????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay? ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?
On Tue, Apr 15, 2014 at 10:32:56PM +0000, Deucher, Alexander wrote:
> Turning off modesetting basically disables the driver.
Well, in my case, I was using the radeon.modeset=0 variant to rule out
issues in x.org. And in my case x.org did start still, albeit with a
jacked-up resolution.
But in Laszlo's case, x.org gets "puzzled" too.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
Borislav Petkov wrote:
> On Tue, Apr 15, 2014 at 10:32:56PM +0000, Deucher, Alexander wrote:
>> Turning off modesetting basically disables the driver.
>
> Well, in my case, I was using the radeon.modeset=0 variant to rule out
> issues in x.org. And in my case x.org did start still, albeit with a
> jacked-up resolution.
>
> But in Laszlo's case, x.org gets "puzzled" too.
>
Maybe your distro's xorg has some generic vga fallback method. I am not aware that mine (Debian Testing) has one.
BTW I use Debian Testing (xfce) and glamor (compiled from git) so i need a specific xorg.conf.
Am 16.04.2014 10:32, schrieb Kertesz Laszlo:
> Borislav Petkov wrote:
>> On Tue, Apr 15, 2014 at 10:32:56PM +0000, Deucher, Alexander wrote:
>>> Turning off modesetting basically disables the driver.
>>
>> Well, in my case, I was using the radeon.modeset=0 variant to rule out
>> issues in x.org. And in my case x.org did start still, albeit with a
>> jacked-up resolution.
>>
>> But in Laszlo's case, x.org gets "puzzled" too.
>>
>
> Maybe your distro's xorg has some generic vga fallback method. I am
> not aware that mine (Debian Testing) has one.
> BTW I use Debian Testing (xfce) and glamor (compiled from git) so i
> need a specific xorg.conf.
>
Using "nomodeset" or radeon.modeset=0 tries to use the deprecated user
mode setting, which in your case isn't even supported by the driver.
Please provide dmesg logs with drm-debug=0xe instead.
Thanks in advance,
Christian.