[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTimjxjINEtM3rIHVk_prI-_UTgkpIVhgbQ0V6rG4@mail.gmail.com>
Date: Mon, 7 Jun 2010 16:22:38 +1000
From: Dave Airlie <airlied@...il.com>
To: Torsten Kaiser <just.for.lkml@...glemail.com>
Cc: Alex Deucher <alexdeucher@...il.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Linux 2.6.35-rc2
On Mon, Jun 7, 2010 at 4:09 PM, Torsten Kaiser
<just.for.lkml@...glemail.com> wrote:
> On Mon, Jun 7, 2010 at 7:58 AM, Alex Deucher <alexdeucher@...il.com> wrote:
>> On Sun, Jun 6, 2010 at 11:04 AM, Torsten Kaiser
>> <just.for.lkml@...glemail.com> wrote:
>>> [CC:Jeff+Tejun not removed, because you might want to look at the
>>> attached dmesgs]
>>>
>>> On Sun, Jun 6, 2010 at 4:19 PM, Linus Torvalds
>>> <torvalds@...ux-foundation.org> wrote:
>>>> On Sun, 6 Jun 2010, Torsten Kaiser wrote:
>>>>>
>>>>> The first problem that shows up is, that after the KMS switches to the
>>>>> correct video mode (1280x1024 for an DVI attached LCD), the display
>>>>> begins to flicker. Every 1..2 seconds (guesstimated) the display turns
>>>>> off and on again. Something in the new powersaving?
>>>>
>>>> Or maybe a borderline display timing that the display has trouble syncing
>>>> up with?
>>>
>>> With 2.6.34 and any previous KMS kernels the output was always stable.
>>> (I think, I switch to the radeon KMS on 2.6.32)
>>> The onscreen menu of the monitor showed 1280x1024@...2Hz for
>>> 2.6.35-rc2, if I recall correctly.
>>> Now back on 2.6.34 its 1280x1024@...9Hz.
>>
>> The pm code shouldn't have any affect as your system only has one
>> power state, so it never kicks in. It sounds like a display pll
>> problem, but there haven't been any changes to that code since 2.6.34.
>> Any chance you could bisect it?
>
> Not really. -rc1 did not boot for me (although if I disable v4l that
> might work), and there is this memory corruption error.
>
> Regarding the PLLs, did you see this mail? It contains the
> drm.debug=15 output from 2.6.34 and 2.6.35-rc2.
> http://lkml.org/lkml/2010/6/6/126
>
> The debug output from radeon_set_pll looks identical. But in 2.6.35 a
> call to [drm:radeon_legacy_tmds_int_dpms], seems new.
>
> The switchoff intervall is ~10 seconds, not 1..2 as I guessed in the first mail.
> Any idea if there is something in the KMS code that triggers at this intervall?
The new mode probing code happens every 10 seconds, though we
shouldn't be turning anything on or off with it.
So I suspect the DAC detection table might be doing bad things on your
hardware, we have had a problem where the dac detect table on one DAC
would turn the other one off which clearly wasn't what we wanted to
see.
,
can you file a bug at kernel.org? full dmesg (need all the radeon bits
where it finds the card).
Dave.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists