(changing subject
On Tue, Jun 8, 2010 at 3:28 AM, Torsten Kaiser
<[email protected]> wrote:
> On Mon, Jun 7, 2010 at 8:52 AM, Dave Airlie <[email protected]> wrote:
>> On Mon, Jun 7, 2010 at 4:32 PM, Alex Deucher <[email protected]> wrote:
>>> On Mon, Jun 7, 2010 at 2:22 AM, Dave Airlie <[email protected]> wrote:
>>>> On Mon, Jun 7, 2010 at 4:09 PM, Torsten Kaiser
>>>> <[email protected]> wrote:
>>>>> 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.
>>>> ,
>>>
>>> The x300 is a non-atom card, so it uses the legacy load detection
>>> routines which do mess with some of the crtc regs.
>>>
>>
>> Okay I see it now, I'm amazed that I was seeing this issue last week
>> and blaming it on something complete different and only seeing it on
>> one card.
>>
>> I expect its the same problem I'll try and track down a proper fix for
>> it tomorrow.
>
> It really seems to be this polling code.
> After the fix to drivers/char/vt.c the 2.6.35-rc2 kernel now works for
> me without crashing.
>
> I also changed #define DRM_OUTPUT_POLL_PERIOD (10*HZ) to
> #define DRM_OUTPUT_POLL_PERIOD (3*HZ) and now the flickering before X
> starts is at a three second interval. That should prove, that the
> polling from drm_crtc_helper.c is the cause.
>
> After X starts the LCD is stable, but the secondary CRT still flickers
> every 3 seconds.
>
> My hardware is an X300-PCIe card with a VGA-, a DVI-I- and a video output.
> I have a 1280x1024 LCD attached to the DVI-I and an old CRT to the
> VGA. The video output is unused.
> The CRT is normally switched off, but its still detected correctly.
>
> The kernel output from 2.6.34 and 2.6.35-rc2 is here:
> http://lkml.org/lkml/2010/6/6/126
>
> xrandr says:
> Screen 0: minimum 320 x 200, current 2080 x 1024, maximum 4096 x 4096
> DVI-0 connected 1280x1024+0+0 (normal left inverted right x axis y
> axis) 338mm x 270mm
> ? 1280x1024 ? ? ?60.0*+ ? 75.0
> ? 1280x960 ? ? ? 60.0
> ? 1152x864 ? ? ? 75.0
> ? 1024x768 ? ? ? 75.1 ? ? 70.1 ? ? 60.0
> ? 832x624 ? ? ? ?74.6
> ? 800x600 ? ? ? ?72.2 ? ? 75.0 ? ? 60.3 ? ? 56.2
> ? 640x480 ? ? ? ?72.8 ? ? 75.0 ? ? 66.7 ? ? 60.0
> ? 720x400 ? ? ? ?70.1
> ? 640x400 ? ? ? ?70.0
> VGA-0 connected 800x600+1280+150 (normal left inverted right x axis y
> axis) 280mm x 210mm
> ? 800x600 ? ? ? ?72.2*+ ? 75.0 ? ? 60.3 ? ? 56.2
> ? 1280x1024 ? ? ?60.0
> ? 1024x768 ? ? ? 75.1 ? ? 70.1 ? ? 60.0
> ? 640x480 ? ? ? ?72.8 ? ? 75.0 ? ? 60.0
> ? 720x400 ? ? ? ?87.8 ? ? 70.1
> S-video disconnected (normal left inverted right x axis y axis)
>
> If you have something for me to try, just send it. :-)
>
> Torsten
>
Okay here is a patch that seems to work on my test system, but I want
to give it a bit more playing around with before I sent it onwards.
Alex, seem sane to you?
Dave.
On Mon, Jun 7, 2010 at 8:49 PM, Dave Airlie <[email protected]> wrote:
> (changing subject
>
> On Tue, Jun 8, 2010 at 3:28 AM, Torsten Kaiser
> <[email protected]> wrote:
>> On Mon, Jun 7, 2010 at 8:52 AM, Dave Airlie <[email protected]> wrote:
>>> On Mon, Jun 7, 2010 at 4:32 PM, Alex Deucher <[email protected]> wrote:
>>>> On Mon, Jun 7, 2010 at 2:22 AM, Dave Airlie <[email protected]> wrote:
>>>>> On Mon, Jun 7, 2010 at 4:09 PM, Torsten Kaiser
>>>>> <[email protected]> wrote:
>>>>>> 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.
>>>>> ,
>>>>
>>>> The x300 is a non-atom card, so it uses the legacy load detection
>>>> routines which do mess with some of the crtc regs.
>>>>
>>>
>>> Okay I see it now, I'm amazed that I was seeing this issue last week
>>> and blaming it on something complete different and only seeing it on
>>> one card.
>>>
>>> I expect its the same problem I'll try and track down a proper fix for
>>> it tomorrow.
>>
>> It really seems to be this polling code.
>> After the fix to drivers/char/vt.c the 2.6.35-rc2 kernel now works for
>> me without crashing.
>>
>> I also changed #define DRM_OUTPUT_POLL_PERIOD (10*HZ) to
>> #define DRM_OUTPUT_POLL_PERIOD (3*HZ) and now the flickering before X
>> starts is at a three second interval. That should prove, that the
>> polling from drm_crtc_helper.c is the cause.
>>
>> After X starts the LCD is stable, but the secondary CRT still flickers
>> every 3 seconds.
>>
>> My hardware is an X300-PCIe card with a VGA-, a DVI-I- and a video output.
>> I have a 1280x1024 LCD attached to the DVI-I and an old CRT to the
>> VGA. The video output is unused.
>> The CRT is normally switched off, but its still detected correctly.
>>
>> The kernel output from 2.6.34 and 2.6.35-rc2 is here:
>> http://lkml.org/lkml/2010/6/6/126
>>
>> xrandr says:
>> Screen 0: minimum 320 x 200, current 2080 x 1024, maximum 4096 x 4096
>> DVI-0 connected 1280x1024+0+0 (normal left inverted right x axis y
>> axis) 338mm x 270mm
>> ? 1280x1024 ? ? ?60.0*+ ? 75.0
>> ? 1280x960 ? ? ? 60.0
>> ? 1152x864 ? ? ? 75.0
>> ? 1024x768 ? ? ? 75.1 ? ? 70.1 ? ? 60.0
>> ? 832x624 ? ? ? ?74.6
>> ? 800x600 ? ? ? ?72.2 ? ? 75.0 ? ? 60.3 ? ? 56.2
>> ? 640x480 ? ? ? ?72.8 ? ? 75.0 ? ? 66.7 ? ? 60.0
>> ? 720x400 ? ? ? ?70.1
>> ? 640x400 ? ? ? ?70.0
>> VGA-0 connected 800x600+1280+150 (normal left inverted right x axis y
>> axis) 280mm x 210mm
>> ? 800x600 ? ? ? ?72.2*+ ? 75.0 ? ? 60.3 ? ? 56.2
>> ? 1280x1024 ? ? ?60.0
>> ? 1024x768 ? ? ? 75.1 ? ? 70.1 ? ? 60.0
>> ? 640x480 ? ? ? ?72.8 ? ? 75.0 ? ? 60.0
>> ? 720x400 ? ? ? ?87.8 ? ? 70.1
>> S-video disconnected (normal left inverted right x axis y axis)
>>
>> If you have something for me to try, just send it. :-)
>>
>> Torsten
>>
>
> Okay here is a patch that seems to work on my test system, but I want
> to give it a bit more playing around with before I sent it onwards.
>
> Alex, seem sane to you?
Seems sane.
Alex
>
> Dave.
>
On Tue, Jun 8, 2010 at 11:50 AM, Alex Deucher <[email protected]> wrote:
> On Mon, Jun 7, 2010 at 8:49 PM, Dave Airlie <[email protected]> wrote:
>> (changing subject
>>
>> On Tue, Jun 8, 2010 at 3:28 AM, Torsten Kaiser
>> <[email protected]> wrote:
>>> On Mon, Jun 7, 2010 at 8:52 AM, Dave Airlie <[email protected]> wrote:
>>>> On Mon, Jun 7, 2010 at 4:32 PM, Alex Deucher <[email protected]> wrote:
>>>>> On Mon, Jun 7, 2010 at 2:22 AM, Dave Airlie <[email protected]> wrote:
>>>>>> On Mon, Jun 7, 2010 at 4:09 PM, Torsten Kaiser
>>>>>> <[email protected]> wrote:
>>>>>>> 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.
>>>>>> ,
>>>>>
>>>>> The x300 is a non-atom card, so it uses the legacy load detection
>>>>> routines which do mess with some of the crtc regs.
>>>>>
>>>>
>>>> Okay I see it now, I'm amazed that I was seeing this issue last week
>>>> and blaming it on something complete different and only seeing it on
>>>> one card.
>>>>
>>>> I expect its the same problem I'll try and track down a proper fix for
>>>> it tomorrow.
>>>
>>> It really seems to be this polling code.
>>> After the fix to drivers/char/vt.c the 2.6.35-rc2 kernel now works for
>>> me without crashing.
>>>
>>> I also changed #define DRM_OUTPUT_POLL_PERIOD (10*HZ) to
>>> #define DRM_OUTPUT_POLL_PERIOD (3*HZ) and now the flickering before X
>>> starts is at a three second interval. That should prove, that the
>>> polling from drm_crtc_helper.c is the cause.
>>>
>>> After X starts the LCD is stable, but the secondary CRT still flickers
>>> every 3 seconds.
>>>
>>> My hardware is an X300-PCIe card with a VGA-, a DVI-I- and a video output.
>>> I have a 1280x1024 LCD attached to the DVI-I and an old CRT to the
>>> VGA. The video output is unused.
>>> The CRT is normally switched off, but its still detected correctly.
>>>
>>> The kernel output from 2.6.34 and 2.6.35-rc2 is here:
>>> http://lkml.org/lkml/2010/6/6/126
>>>
>>> xrandr says:
>>> Screen 0: minimum 320 x 200, current 2080 x 1024, maximum 4096 x 4096
>>> DVI-0 connected 1280x1024+0+0 (normal left inverted right x axis y
>>> axis) 338mm x 270mm
>>> ? 1280x1024 ? ? ?60.0*+ ? 75.0
>>> ? 1280x960 ? ? ? 60.0
>>> ? 1152x864 ? ? ? 75.0
>>> ? 1024x768 ? ? ? 75.1 ? ? 70.1 ? ? 60.0
>>> ? 832x624 ? ? ? ?74.6
>>> ? 800x600 ? ? ? ?72.2 ? ? 75.0 ? ? 60.3 ? ? 56.2
>>> ? 640x480 ? ? ? ?72.8 ? ? 75.0 ? ? 66.7 ? ? 60.0
>>> ? 720x400 ? ? ? ?70.1
>>> ? 640x400 ? ? ? ?70.0
>>> VGA-0 connected 800x600+1280+150 (normal left inverted right x axis y
>>> axis) 280mm x 210mm
>>> ? 800x600 ? ? ? ?72.2*+ ? 75.0 ? ? 60.3 ? ? 56.2
>>> ? 1280x1024 ? ? ?60.0
>>> ? 1024x768 ? ? ? 75.1 ? ? 70.1 ? ? 60.0
>>> ? 640x480 ? ? ? ?72.8 ? ? 75.0 ? ? 60.0
>>> ? 720x400 ? ? ? ?87.8 ? ? 70.1
>>> S-video disconnected (normal left inverted right x axis y axis)
>>>
>>> If you have something for me to try, just send it. :-)
>>>
>>> Torsten
>>>
>>
>> Okay here is a patch that seems to work on my test system, but I want
>> to give it a bit more playing around with before I sent it onwards.
>>
>> Alex, seem sane to you?
>
> Seems sane.
>
While discussing this with Alex we realised this code should never
have been reached so it showed a bug higher up.
Looks like we were defining i2c lines for tv-out which doesn't have
any, the attached patch makes sure the tv-out on legacy radeon hw
doesn't get an i2c line attach so doesn't trigger the polling on it.
Torsten can you test this patch instead of the previous one, though I
think I'll send both to Linus for safety sakes.
Dave.
On Tue, Jun 8, 2010 at 5:09 AM, Dave Airlie <[email protected]> wrote:
> On Tue, Jun 8, 2010 at 11:50 AM, Alex Deucher <[email protected]> wrote:
>> On Mon, Jun 7, 2010 at 8:49 PM, Dave Airlie <[email protected]> wrote:
>>> (changing subject
>>>
>>> On Tue, Jun 8, 2010 at 3:28 AM, Torsten Kaiser
>>> <[email protected]> wrote:
>>>> On Mon, Jun 7, 2010 at 8:52 AM, Dave Airlie <[email protected]> wrote:
>>>>> On Mon, Jun 7, 2010 at 4:32 PM, Alex Deucher <[email protected]> wrote:
>>>>>> On Mon, Jun 7, 2010 at 2:22 AM, Dave Airlie <[email protected]> wrote:
>>>>>>> On Mon, Jun 7, 2010 at 4:09 PM, Torsten Kaiser
>>>>>>> <[email protected]> wrote:
>>>>>>>> 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.
>>>>>>> ,
>>>>>>
>>>>>> The x300 is a non-atom card, so it uses the legacy load detection
>>>>>> routines which do mess with some of the crtc regs.
>>>>>>
>>>>>
>>>>> Okay I see it now, I'm amazed that I was seeing this issue last week
>>>>> and blaming it on something complete different and only seeing it on
>>>>> one card.
>>>>>
>>>>> I expect its the same problem I'll try and track down a proper fix for
>>>>> it tomorrow.
>>>>
>>>> It really seems to be this polling code.
>>>> After the fix to drivers/char/vt.c the 2.6.35-rc2 kernel now works for
>>>> me without crashing.
>>>>
>>>> I also changed #define DRM_OUTPUT_POLL_PERIOD (10*HZ) to
>>>> #define DRM_OUTPUT_POLL_PERIOD (3*HZ) and now the flickering before X
>>>> starts is at a three second interval. That should prove, that the
>>>> polling from drm_crtc_helper.c is the cause.
>>>>
>>>> After X starts the LCD is stable, but the secondary CRT still flickers
>>>> every 3 seconds.
>>>>
>>>> My hardware is an X300-PCIe card with a VGA-, a DVI-I- and a video output.
>>>> I have a 1280x1024 LCD attached to the DVI-I and an old CRT to the
>>>> VGA. The video output is unused.
>>>> The CRT is normally switched off, but its still detected correctly.
>>>>
>>>> The kernel output from 2.6.34 and 2.6.35-rc2 is here:
>>>> http://lkml.org/lkml/2010/6/6/126
>>>>
>>>> xrandr says:
>>>> Screen 0: minimum 320 x 200, current 2080 x 1024, maximum 4096 x 4096
>>>> DVI-0 connected 1280x1024+0+0 (normal left inverted right x axis y
>>>> axis) 338mm x 270mm
>>>> ? 1280x1024 ? ? ?60.0*+ ? 75.0
>>>> ? 1280x960 ? ? ? 60.0
>>>> ? 1152x864 ? ? ? 75.0
>>>> ? 1024x768 ? ? ? 75.1 ? ? 70.1 ? ? 60.0
>>>> ? 832x624 ? ? ? ?74.6
>>>> ? 800x600 ? ? ? ?72.2 ? ? 75.0 ? ? 60.3 ? ? 56.2
>>>> ? 640x480 ? ? ? ?72.8 ? ? 75.0 ? ? 66.7 ? ? 60.0
>>>> ? 720x400 ? ? ? ?70.1
>>>> ? 640x400 ? ? ? ?70.0
>>>> VGA-0 connected 800x600+1280+150 (normal left inverted right x axis y
>>>> axis) 280mm x 210mm
>>>> ? 800x600 ? ? ? ?72.2*+ ? 75.0 ? ? 60.3 ? ? 56.2
>>>> ? 1280x1024 ? ? ?60.0
>>>> ? 1024x768 ? ? ? 75.1 ? ? 70.1 ? ? 60.0
>>>> ? 640x480 ? ? ? ?72.8 ? ? 75.0 ? ? 60.0
>>>> ? 720x400 ? ? ? ?87.8 ? ? 70.1
>>>> S-video disconnected (normal left inverted right x axis y axis)
>>>>
>>>> If you have something for me to try, just send it. :-)
>>>>
>>>> Torsten
>>>>
>>>
>>> Okay here is a patch that seems to work on my test system, but I want
>>> to give it a bit more playing around with before I sent it onwards.
>>>
>>> Alex, seem sane to you?
>>
>> Seems sane.
>>
>
> While discussing this with Alex we realised this code should never
> have been reached so it showed a bug higher up.
>
> Looks like we were defining i2c lines for tv-out which doesn't have
> any, the attached patch makes sure the tv-out on legacy radeon hw
> doesn't get an i2c line attach so doesn't trigger the polling on it.
>
> Torsten can you test this patch instead of the previous one, though I
> think I'll send both to Linus for safety sakes.
I just applied it and the card now works fine. No more flickering.
Thanks!
Do you want me to test the other patch
(0001-drm-radeon-don-t-poll-tv-dac-if-crtc2-is-in-use.patch) too?
Torsten