[git pull] drm intel + exynos fixes
On Fri, Jun 8, 2012 at 11:57 PM, Linus Torvalds wrote: > This breaks things for me. Bisect says: > > 9e612a008fa7fe493a473454def56aa321479495 is the first bad commit > commit 9e612a008fa7fe493a473454def56aa321479495 > Author: Chris Wilson > Date: ? Thu May 31 13:08:53 2012 +0100 > > ? ?drm/i915/crt: Do not rely upon the HPD presence pin > > ? ?Whilst most monitors do wire up the HPD presence pin, it seems quite a > ? ?few KVM do not. Therefore if we simply rely on the HPD pin being > ? ?asserted to indicate a connected monitor we fail miserable, so fall back > ? ?to performing a DCC query for the EDID. > > ? ?Reported-and-tested-by: Matthieu LAVIE > ? ?Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50501 > ? ?Signed-off-by: Chris Wilson > ? ?Signed-off-by: Daniel Vetter > > And the symptoms are that it boots in what appears to be the correct > mode for my monitor (1920x1200), but when X starts it changes to > 1024x768 mode. > > Which is not good, and not useful. > > The bad kernel has this in Xorg.0.log: > > ?[ ? ?12.796] (II) intel(0): EDID for output VGA1 > ?[ ? ?12.796] (II) intel(0): Printing probed modes for output VGA1 > ?[ ? ?12.796] (II) intel(0): Modeline "1024x768"x60.0 ? 65.00 ?1024 > 1048 1184 1344 ?768 771 777 806 -hsync -vsync (48.4 kHz e) > ?[ ? ?12.796] (II) intel(0): Modeline "800x600"x60.3 ? 40.00 ?800 840 > 968 1056 ?600 601 605 628 +hsync +vsync (37.9 kHz e) > ?[ ? ?12.796] (II) intel(0): Modeline "800x600"x56.2 ? 36.00 ?800 824 > 896 1024 ?600 601 603 625 +hsync +vsync (35.2 kHz e) > ?[ ? ?12.796] (II) intel(0): Modeline "848x480"x60.0 ? 33.75 ?848 864 > 976 1088 ?480 486 494 517 +hsync +vsync (31.0 kHz e) > ?[ ? ?12.796] (II) intel(0): Modeline "640x480"x59.9 ? 25.18 ?640 656 > 752 800 ?480 489 492 525 -hsync -vsync (31.5 kHz e) > > which is pure and utter garbage. I think it's the "default modes" for > the non-EDID case, and has nothing to do with actual hardware. > > The good kernel doesn't have those incorrect and bogus probed modes, > and just has the correct HDMI1 (that the bad kernel *also* has, of > course). > > I have reverted that commit as obviously broken, since I'm not going > to release an -rc2 that doesn't even work for me (and since it *is* > obviously broken). I've looked again through the code and with this patch we can fall through to the gen2/3 load detect code, which likely results totally bogus results for anything never (where we've previously relied exclusively on the hotplug pins). Sorry for not catching this when I've reviewed this patch for -fixes. Hence for the revert: Acked-by: Daniel Vetter -Daniel -- Daniel Vetter daniel.vetter at ffwll.ch - +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[git pull] drm intel + exynos fixes
On Fri, 8 Jun 2012 15:23:15 -0700, Linus Torvalds wrote: > On Fri, Jun 8, 2012 at 3:12 PM, Chris Wilson > wrote: > > > > So it falls back to > > load-detection, which in your case it cannot do since all the available > > pipes are assigned and so it just reports the VGA connection as unknown. > > Btw, it's a singularly stupid decision to say "Ok, I *know* I have a > monitor on output X, and I have no clue what-so-ever what I have on > output Y, and no indication there is anything even there, so let me > just degrade the output on output Y just in case". And that was my point. You were blaming the patch for making you aware of existing behaviour that results in utter confusion, for as Alex points out there is no sane way for userspace to handle the unknown connection status from the detection routine. As such it is probably better if that was handled internally as "result indeterminate; do not update current detection status" which is the behaviour of some of the drm helpers but uniformly. If that were true, then userspace would continue to be told that the connection status was disconnected until a monitor was plugged in. -Chris -- Chris Wilson, Intel Open Source Technology Centre
[git pull] drm intel + exynos fixes
On Fri, 8 Jun 2012 14:57:31 -0700, Linus Torvalds wrote: > This breaks things for me. Bisect says: > > 9e612a008fa7fe493a473454def56aa321479495 is the first bad commit > commit 9e612a008fa7fe493a473454def56aa321479495 > Author: Chris Wilson > Date: Thu May 31 13:08:53 2012 +0100 > > drm/i915/crt: Do not rely upon the HPD presence pin > > Whilst most monitors do wire up the HPD presence pin, it seems quite a > few KVM do not. Therefore if we simply rely on the HPD pin being > asserted to indicate a connected monitor we fail miserable, so fall back > to performing a DCC query for the EDID. > > Reported-and-tested-by: Matthieu LAVIE > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50501 > Signed-off-by: Chris Wilson > Signed-off-by: Daniel Vetter > > And the symptoms are that it boots in what appears to be the correct > mode for my monitor (1920x1200), but when X starts it changes to > 1024x768 mode. > > Which is not good, and not useful. > > The bad kernel has this in Xorg.0.log: > > [12.796] (II) intel(0): EDID for output VGA1 > [12.796] (II) intel(0): Printing probed modes for output VGA1 > [12.796] (II) intel(0): Modeline "1024x768"x60.0 65.00 1024 > 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz e) > [12.796] (II) intel(0): Modeline "800x600"x60.3 40.00 800 840 > 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz e) > [12.796] (II) intel(0): Modeline "800x600"x56.2 36.00 800 824 > 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz e) > [12.796] (II) intel(0): Modeline "848x480"x60.0 33.75 848 864 > 976 1088 480 486 494 517 +hsync +vsync (31.0 kHz e) > [12.796] (II) intel(0): Modeline "640x480"x59.9 25.18 640 656 > 752 800 480 489 492 525 -hsync -vsync (31.5 kHz e) > > which is pure and utter garbage. I think it's the "default modes" for > the non-EDID case, and has nothing to do with actual hardware. > > The good kernel doesn't have those incorrect and bogus probed modes, > and just has the correct HDMI1 (that the bad kernel *also* has, of > course). > > I have reverted that commit as obviously broken, since I'm not going > to release an -rc2 that doesn't even work for me (and since it *is* > obviously broken). Shock, horror, that's how it is meant to work when we cannot determine whether or not there is actually an output attached to the VGA. The hw autodetect falsely declares some VGA connections, notably through KVM switches, as disconnected and so we need to do a manual probe to confirm the flaky hw. The first phase of that probe is to request the EDID from the monitor, not all monitors supply one and less through a KVM switch, so we cannot rely on a negative result from that test. (Absence of evidence is not evidence of absence and all that.) So it falls back to load-detection, which in your case it cannot do since all the available pipes are assigned and so it just reports the VGA connection as unknown. -Chris -- Chris Wilson, Intel Open Source Technology Centre
[git pull] drm intel + exynos fixes
On Fri, Jun 8, 2012 at 6:12 PM, Chris Wilson wrote: > On Fri, 8 Jun 2012 14:57:31 -0700, Linus Torvalds linux-foundation.org> wrote: >> This breaks things for me. Bisect says: >> >> 9e612a008fa7fe493a473454def56aa321479495 is the first bad commit >> commit 9e612a008fa7fe493a473454def56aa321479495 >> Author: Chris Wilson >> Date: ? Thu May 31 13:08:53 2012 +0100 >> >> ? ? drm/i915/crt: Do not rely upon the HPD presence pin >> >> ? ? Whilst most monitors do wire up the HPD presence pin, it seems quite a >> ? ? few KVM do not. Therefore if we simply rely on the HPD pin being >> ? ? asserted to indicate a connected monitor we fail miserable, so fall back >> ? ? to performing a DCC query for the EDID. >> >> ? ? Reported-and-tested-by: Matthieu LAVIE >> ? ? Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50501 >> ? ? Signed-off-by: Chris Wilson >> ? ? Signed-off-by: Daniel Vetter >> >> And the symptoms are that it boots in what appears to be the correct >> mode for my monitor (1920x1200), but when X starts it changes to >> 1024x768 mode. >> >> Which is not good, and not useful. >> >> The bad kernel has this in Xorg.0.log: >> >> ?[ ? ?12.796] (II) intel(0): EDID for output VGA1 >> ?[ ? ?12.796] (II) intel(0): Printing probed modes for output VGA1 >> ?[ ? ?12.796] (II) intel(0): Modeline "1024x768"x60.0 ? 65.00 ?1024 >> 1048 1184 1344 ?768 771 777 806 -hsync -vsync (48.4 kHz e) >> ?[ ? ?12.796] (II) intel(0): Modeline "800x600"x60.3 ? 40.00 ?800 840 >> 968 1056 ?600 601 605 628 +hsync +vsync (37.9 kHz e) >> ?[ ? ?12.796] (II) intel(0): Modeline "800x600"x56.2 ? 36.00 ?800 824 >> 896 1024 ?600 601 603 625 +hsync +vsync (35.2 kHz e) >> ?[ ? ?12.796] (II) intel(0): Modeline "848x480"x60.0 ? 33.75 848 864 >> 976 1088 ?480 486 494 517 +hsync +vsync (31.0 kHz e) >> ?[ ? ?12.796] (II) intel(0): Modeline "640x480"x59.9 ? 25.18 640 656 >> 752 800 ?480 489 492 525 -hsync -vsync (31.5 kHz e) >> >> which is pure and utter garbage. I think it's the "default modes" for >> the non-EDID case, and has nothing to do with actual hardware. >> >> The good kernel doesn't have those incorrect and bogus probed modes, >> and just has the correct HDMI1 (that the bad kernel *also* has, of >> course). >> >> I have reverted that commit as obviously broken, since I'm not going >> to release an -rc2 that doesn't even work for me (and since it *is* >> obviously broken). > > Shock, horror, that's how it is meant to work when we cannot determine > whether or not there is actually an output attached to the VGA. The hw > autodetect falsely declares some VGA connections, notably through KVM > switches, as disconnected and so we need to do a manual probe to confirm > the flaky hw. The first phase of that probe is to request the EDID from > the monitor, not all monitors supply one and less through a KVM switch, > so we cannot rely on a negative result from that test. (Absence of > evidence is not evidence of absence and all that.) So it falls back to > load-detection, which in your case it cannot do since all the available > pipes are assigned and so it just reports the VGA connection as unknown. The whole concept of connector status unknown is basically useless. There's not really anything reasonable you can do with it and it's abused in lots of different ways by both drivers and userspace. Some userspace apps treat unknown as connected, others as disconnected, others as connected but considered off (e.g., laptop lid closed). And drivers abuse it similarly (e.g., report lvds as unknown if the lid is closed). Unknown should be dropped and drivers should really just report connected or disconnected. If the driver is not able to detect a monitor, report disconnected even is there may be a monitor behind a broken KVM that doesn't respond to DDC or load detection. Unfortunately, everyone's favorite userspace apps will all break in differing ways... Alex > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm intel + exynos fixes
On Fri, Jun 8, 2012 at 3:52 PM, Chris Wilson wrote: > > And that was my point. You were blaming the patch for making you aware > of existing behaviour that results in utter confusion, for as Alex > points out there is no sane way for userspace to handle the unknown > connection status from the detection routine. Ahh. Yes, then I agree with you. The current behavior is clearly insane in the presense of an unknown connector status. So if the higher levels are eventually fixed to say "if one input is 'unknown' and another is 'connected', we'll assume 'unknown' means 'not connected'", then we can re-apply that patch. As it is, it's apparently a disaster to reply 'unknown' in this situation. Linus
[git pull] drm intel + exynos fixes
On Fri, Jun 8, 2012 at 3:12 PM, Chris Wilson wrote: > > So it falls back to > load-detection, which in your case it cannot do since all the available > pipes are assigned and so it just reports the VGA connection as unknown. Btw, it's a singularly stupid decision to say "Ok, I *know* I have a monitor on output X, and I have no clue what-so-ever what I have on output Y, and no indication there is anything even there, so let me just degrade the output on output Y just in case". Which is basically what you are arguing for. In addition to the idiotic of argument that "ok, it used to work right, but we broke it on *purpose*, really". I'd suggest that if you see no other connectors at all, *then* you might say "ok, let's assume that we have a VGA monitor behind a broken KVM switch". At that point, at least that assumption doesn't make things worse for anything else that you know is there. And if people have truly undetectable VGA hardware in addition to another (detectable) output, I would suggest that you tell them to force it with xrandr. Again, there's no way in hell I will accept the idiotic argument that my old working single-monitor setup should be broken because the i915 driver decided that I *might* have a second monitor on VGA despite everything else saying that is not the case. Linus
[git pull] drm intel + exynos fixes
On Fri, Jun 8, 2012 at 3:12 PM, Chris Wilson wrote: > > Shock, horror, that's how it is meant to work when we cannot determine > whether or not there is actually an output attached to the VGA. We don't break existing installations. And that existing installation has worked for a long time. You broke it, it's a regression, get over it. It's reverted, and it stays reverted. Linus
[git pull] drm intel + exynos fixes
This breaks things for me. Bisect says:
9e612a008fa7fe493a473454def56aa321479495 is the first bad commit
commit 9e612a008fa7fe493a473454def56aa321479495
Author: Chris Wilson
Date: Thu May 31 13:08:53 2012 +0100
drm/i915/crt: Do not rely upon the HPD presence pin
Whilst most monitors do wire up the HPD presence pin, it seems quite a
few KVM do not. Therefore if we simply rely on the HPD pin being
asserted to indicate a connected monitor we fail miserable, so fall back
to performing a DCC query for the EDID.
Reported-and-tested-by: Matthieu LAVIE
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50501
Signed-off-by: Chris Wilson
Signed-off-by: Daniel Vetter
And the symptoms are that it boots in what appears to be the correct
mode for my monitor (1920x1200), but when X starts it changes to
1024x768 mode.
Which is not good, and not useful.
The bad kernel has this in Xorg.0.log:
[12.796] (II) intel(0): EDID for output VGA1
[12.796] (II) intel(0): Printing probed modes for output VGA1
[12.796] (II) intel(0): Modeline "1024x768"x60.0 65.00 1024
1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz e)
[12.796] (II) intel(0): Modeline "800x600"x60.3 40.00 800 840
968 1056 600 601 605 628 +hsync +vsync (37.9 kHz e)
[12.796] (II) intel(0): Modeline "800x600"x56.2 36.00 800 824
896 1024 600 601 603 625 +hsync +vsync (35.2 kHz e)
[12.796] (II) intel(0): Modeline "848x480"x60.0 33.75 848 864
976 1088 480 486 494 517 +hsync +vsync (31.0 kHz e)
[12.796] (II) intel(0): Modeline "640x480"x59.9 25.18 640 656
752 800 480 489 492 525 -hsync -vsync (31.5 kHz e)
which is pure and utter garbage. I think it's the "default modes" for
the non-EDID case, and has nothing to do with actual hardware.
The good kernel doesn't have those incorrect and bogus probed modes,
and just has the correct HDMI1 (that the bad kernel *also* has, of
course).
I have reverted that commit as obviously broken, since I'm not going
to release an -rc2 that doesn't even work for me (and since it *is*
obviously broken).
Linus
On Fri, Jun 8, 2012 at 1:53 AM, Dave Airlie wrote:
>
> Hi Linus,
>
> a bunch of fixes for Intel and exynos, nothing too major, a new intel PCI
> Id, and a fix for CRT detection.
>
> Dave.
>
> The following changes since commit 7aaa61b3476462b69f1ac7669fcca8d608ce3cb5:
>
> ?drm/radeon/kms: add new SI PCI ids (2012-06-05 15:11:12 +0100)
>
> are available in the git repository at:
>
> ?git://people.freedesktop.org/~airlied/linux drm-fixes
>
> for you to fetch changes up to 2d5c7cd35f1addb812e0b1709b3c727f1a58ca9c:
>
> ?Merge branch 'exynos-drm-fixes' of
> git://git.infradead.org/users/kmpark/linux-samsung into drm-fixes (2012-06-08
> 09:42:51 +0100)
>
>
>
> Adam Jackson (1):
> ? ? ?drm/i915: pch_irq_handler -> {ibx, cpt}_irq_handler
>
> Chris Wilson (3):
> ? ? ?drm/i915: Reset last_retired_head when resetting ring
> ? ? ?drm/i915/crt: Do not rely upon the HPD presence pin
> ? ? ?drm/i915: Mark the ringbuffers as being in the GTT domain
>
> Daniel Vetter (2):
> ? ? ?drm/i915: hold forcewake around ring hw init
> ? ? ?drm/i915: fix up ivb plane 3 pageflips
>
> Dave Airlie (2):
> ? ? ?Merge branch 'drm-intel-fixes' of
> git://people.freedesktop.org/~danvet/drm-intel into drm-fixes
> ? ? ?Merge branch 'exynos-drm-fixes' of
> git://git.infradead.org/users/kmpark/linux-samsung into drm-fixes
>
> Eugeni Dodonov (1):
> ? ? ?char/agp: add another Ironlake host bridge
>
> Inki Dae (1):
> ? ? ?drm/exynos: fixed size type.
>
> Laurent Pinchart (4):
> ? ? ?drm/exynos: DRIVER_BUS_PLATFORM is not a driver feature
> ? ? ?drm/exynos: Don't cast GEM object to Exynos GEM object when not needed
> ? ? ?drm/exynos: Keep a reference to frame buffer GEM objects
> ? ? ?drm/exynos: Remove dummy encoder get_crtc operation implementation
>
> Seung-Woo Kim (1):
> ? ? ?drm/exynos: fixed blending for hdmi graphic layer
>
> Ville Syrj?l? (1):
> ? ? ?drm/exynos: Use DRM_FORMAT_{NV12, YUV420} instead of DRM_FORMAT_{NV12M,
> YUV420M}
>
> ?drivers/char/agp/intel-agp.c ? ? ? ? ? ? ? ?| ? ?1 +
> ?drivers/char/agp/intel-agp.h ? ? ? ? ? ? ? ?| ? ?1 +
> ?drivers/gpu/drm/exynos/exynos_drm_drv.c ? ? | ? ?4 +--
> ?drivers/gpu/drm/exynos/exynos_drm_encoder.c | ? ?7 -
> ?drivers/gpu/drm/exynos/exynos_drm_fb.c ? ? ?| ? 19
> ?drivers/gpu/drm/exynos/exynos_drm_fb.h ? ? ?| ? ?4 +--
> ?drivers/gpu/drm/exynos/exynos_drm_gem.c ? ? | ? ?9 ++
> ?drivers/gpu/drm/exynos/exynos_mixer.c ? ? ? | ? 12
> ?drivers/gpu/drm/i915/i915_drv.c ? ? ? ? ? ? | ? 13 +---
> ?drivers/gpu/drm/i915/i915_drv.h ? ? ? ? ? ? | ? ?3 ++
> ?drivers/gpu/drm/i915/i915_irq.c ? ? ? ? ? ? | ? 38 +--
> ?drivers/gpu/drm/i915/i915_reg.h ? ? ? ? ? ? | ? 43
> +--
> ?drivers/gpu/drm/i915/intel_crt.c ? ? ? ? ? ?| ? ?8 +++--
>
[git pull] drm intel + exynos fixes
Hi Linus,
a bunch of fixes for Intel and exynos, nothing too major, a new intel PCI
Id, and a fix for CRT detection.
Dave.
The following changes since commit 7aaa61b3476462b69f1ac7669fcca8d608ce3cb5:
drm/radeon/kms: add new SI PCI ids (2012-06-05 15:11:12 +0100)
are available in the git repository at:
git://people.freedesktop.org/~airlied/linux drm-fixes
for you to fetch changes up to 2d5c7cd35f1addb812e0b1709b3c727f1a58ca9c:
Merge branch 'exynos-drm-fixes' of
git://git.infradead.org/users/kmpark/linux-samsung into drm-fixes (2012-06-08
09:42:51 +0100)
Adam Jackson (1):
drm/i915: pch_irq_handler -> {ibx, cpt}_irq_handler
Chris Wilson (3):
drm/i915: Reset last_retired_head when resetting ring
drm/i915/crt: Do not rely upon the HPD presence pin
drm/i915: Mark the ringbuffers as being in the GTT domain
Daniel Vetter (2):
drm/i915: hold forcewake around ring hw init
drm/i915: fix up ivb plane 3 pageflips
Dave Airlie (2):
Merge branch 'drm-intel-fixes' of
git://people.freedesktop.org/~danvet/drm-intel into drm-fixes
Merge branch 'exynos-drm-fixes' of
git://git.infradead.org/users/kmpark/linux-samsung into drm-fixes
Eugeni Dodonov (1):
char/agp: add another Ironlake host bridge
Inki Dae (1):
drm/exynos: fixed size type.
Laurent Pinchart (4):
drm/exynos: DRIVER_BUS_PLATFORM is not a driver feature
drm/exynos: Don't cast GEM object to Exynos GEM object when not needed
drm/exynos: Keep a reference to frame buffer GEM objects
drm/exynos: Remove dummy encoder get_crtc operation implementation
Seung-Woo Kim (1):
drm/exynos: fixed blending for hdmi graphic layer
Ville Syrj?l? (1):
drm/exynos: Use DRM_FORMAT_{NV12, YUV420} instead of DRM_FORMAT_{NV12M,
YUV420M}
drivers/char/agp/intel-agp.c|1 +
drivers/char/agp/intel-agp.h|1 +
drivers/gpu/drm/exynos/exynos_drm_drv.c |4 +--
drivers/gpu/drm/exynos/exynos_drm_encoder.c |7 -
drivers/gpu/drm/exynos/exynos_drm_fb.c | 19
drivers/gpu/drm/exynos/exynos_drm_fb.h |4 +--
drivers/gpu/drm/exynos/exynos_drm_gem.c |9 ++
drivers/gpu/drm/exynos/exynos_mixer.c | 12
drivers/gpu/drm/i915/i915_drv.c | 13 +---
drivers/gpu/drm/i915/i915_drv.h |3 ++
drivers/gpu/drm/i915/i915_irq.c | 38 +--
drivers/gpu/drm/i915/i915_reg.h | 43 +--
drivers/gpu/drm/i915/intel_crt.c|8 +++--
drivers/gpu/drm/i915/intel_display.c| 19 +++-
drivers/gpu/drm/i915/intel_ringbuffer.c | 21 +++--
include/drm/exynos_drm.h|4 ++-
16 files changed, 161 insertions(+), 45 deletions(-)
[git pull] drm intel + exynos fixes
Hi Linus,
a bunch of fixes for Intel and exynos, nothing too major, a new intel PCI
Id, and a fix for CRT detection.
Dave.
The following changes since commit 7aaa61b3476462b69f1ac7669fcca8d608ce3cb5:
drm/radeon/kms: add new SI PCI ids (2012-06-05 15:11:12 +0100)
are available in the git repository at:
git://people.freedesktop.org/~airlied/linux drm-fixes
for you to fetch changes up to 2d5c7cd35f1addb812e0b1709b3c727f1a58ca9c:
Merge branch 'exynos-drm-fixes' of
git://git.infradead.org/users/kmpark/linux-samsung into drm-fixes (2012-06-08
09:42:51 +0100)
Adam Jackson (1):
drm/i915: pch_irq_handler - {ibx, cpt}_irq_handler
Chris Wilson (3):
drm/i915: Reset last_retired_head when resetting ring
drm/i915/crt: Do not rely upon the HPD presence pin
drm/i915: Mark the ringbuffers as being in the GTT domain
Daniel Vetter (2):
drm/i915: hold forcewake around ring hw init
drm/i915: fix up ivb plane 3 pageflips
Dave Airlie (2):
Merge branch 'drm-intel-fixes' of
git://people.freedesktop.org/~danvet/drm-intel into drm-fixes
Merge branch 'exynos-drm-fixes' of
git://git.infradead.org/users/kmpark/linux-samsung into drm-fixes
Eugeni Dodonov (1):
char/agp: add another Ironlake host bridge
Inki Dae (1):
drm/exynos: fixed size type.
Laurent Pinchart (4):
drm/exynos: DRIVER_BUS_PLATFORM is not a driver feature
drm/exynos: Don't cast GEM object to Exynos GEM object when not needed
drm/exynos: Keep a reference to frame buffer GEM objects
drm/exynos: Remove dummy encoder get_crtc operation implementation
Seung-Woo Kim (1):
drm/exynos: fixed blending for hdmi graphic layer
Ville Syrjälä (1):
drm/exynos: Use DRM_FORMAT_{NV12, YUV420} instead of DRM_FORMAT_{NV12M,
YUV420M}
drivers/char/agp/intel-agp.c|1 +
drivers/char/agp/intel-agp.h|1 +
drivers/gpu/drm/exynos/exynos_drm_drv.c |4 +--
drivers/gpu/drm/exynos/exynos_drm_encoder.c |7 -
drivers/gpu/drm/exynos/exynos_drm_fb.c | 19
drivers/gpu/drm/exynos/exynos_drm_fb.h |4 +--
drivers/gpu/drm/exynos/exynos_drm_gem.c |9 ++
drivers/gpu/drm/exynos/exynos_mixer.c | 12
drivers/gpu/drm/i915/i915_drv.c | 13 +---
drivers/gpu/drm/i915/i915_drv.h |3 ++
drivers/gpu/drm/i915/i915_irq.c | 38 +--
drivers/gpu/drm/i915/i915_reg.h | 43 +--
drivers/gpu/drm/i915/intel_crt.c|8 +++--
drivers/gpu/drm/i915/intel_display.c| 19 +++-
drivers/gpu/drm/i915/intel_ringbuffer.c | 21 +++--
include/drm/exynos_drm.h|4 ++-
16 files changed, 161 insertions(+), 45 deletions(-)___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm intel + exynos fixes
On Fri, Jun 8, 2012 at 11:57 PM, Linus Torvalds torva...@linux-foundation.org wrote: This breaks things for me. Bisect says: 9e612a008fa7fe493a473454def56aa321479495 is the first bad commit commit 9e612a008fa7fe493a473454def56aa321479495 Author: Chris Wilson ch...@chris-wilson.co.uk Date: Thu May 31 13:08:53 2012 +0100 drm/i915/crt: Do not rely upon the HPD presence pin Whilst most monitors do wire up the HPD presence pin, it seems quite a few KVM do not. Therefore if we simply rely on the HPD pin being asserted to indicate a connected monitor we fail miserable, so fall back to performing a DCC query for the EDID. Reported-and-tested-by: Matthieu LAVIE boiteamad...@hotmail.com Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50501 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch And the symptoms are that it boots in what appears to be the correct mode for my monitor (1920x1200), but when X starts it changes to 1024x768 mode. Which is not good, and not useful. The bad kernel has this in Xorg.0.log: [ 12.796] (II) intel(0): EDID for output VGA1 [ 12.796] (II) intel(0): Printing probed modes for output VGA1 [ 12.796] (II) intel(0): Modeline 1024x768x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz e) [ 12.796] (II) intel(0): Modeline 800x600x60.3 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz e) [ 12.796] (II) intel(0): Modeline 800x600x56.2 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz e) [ 12.796] (II) intel(0): Modeline 848x480x60.0 33.75 848 864 976 1088 480 486 494 517 +hsync +vsync (31.0 kHz e) [ 12.796] (II) intel(0): Modeline 640x480x59.9 25.18 640 656 752 800 480 489 492 525 -hsync -vsync (31.5 kHz e) which is pure and utter garbage. I think it's the default modes for the non-EDID case, and has nothing to do with actual hardware. The good kernel doesn't have those incorrect and bogus probed modes, and just has the correct HDMI1 (that the bad kernel *also* has, of course). I have reverted that commit as obviously broken, since I'm not going to release an -rc2 that doesn't even work for me (and since it *is* obviously broken). I've looked again through the code and with this patch we can fall through to the gen2/3 load detect code, which likely results totally bogus results for anything never (where we've previously relied exclusively on the hotplug pins). Sorry for not catching this when I've reviewed this patch for -fixes. Hence for the revert: Acked-by: Daniel Vetter daniel.vet...@ffwll.ch -Daniel -- Daniel Vetter daniel.vet...@ffwll.ch - +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm intel + exynos fixes
On Fri, 8 Jun 2012 14:57:31 -0700, Linus Torvalds torva...@linux-foundation.org wrote: This breaks things for me. Bisect says: 9e612a008fa7fe493a473454def56aa321479495 is the first bad commit commit 9e612a008fa7fe493a473454def56aa321479495 Author: Chris Wilson ch...@chris-wilson.co.uk Date: Thu May 31 13:08:53 2012 +0100 drm/i915/crt: Do not rely upon the HPD presence pin Whilst most monitors do wire up the HPD presence pin, it seems quite a few KVM do not. Therefore if we simply rely on the HPD pin being asserted to indicate a connected monitor we fail miserable, so fall back to performing a DCC query for the EDID. Reported-and-tested-by: Matthieu LAVIE boiteamad...@hotmail.com Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50501 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch And the symptoms are that it boots in what appears to be the correct mode for my monitor (1920x1200), but when X starts it changes to 1024x768 mode. Which is not good, and not useful. The bad kernel has this in Xorg.0.log: [12.796] (II) intel(0): EDID for output VGA1 [12.796] (II) intel(0): Printing probed modes for output VGA1 [12.796] (II) intel(0): Modeline 1024x768x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz e) [12.796] (II) intel(0): Modeline 800x600x60.3 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz e) [12.796] (II) intel(0): Modeline 800x600x56.2 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz e) [12.796] (II) intel(0): Modeline 848x480x60.0 33.75 848 864 976 1088 480 486 494 517 +hsync +vsync (31.0 kHz e) [12.796] (II) intel(0): Modeline 640x480x59.9 25.18 640 656 752 800 480 489 492 525 -hsync -vsync (31.5 kHz e) which is pure and utter garbage. I think it's the default modes for the non-EDID case, and has nothing to do with actual hardware. The good kernel doesn't have those incorrect and bogus probed modes, and just has the correct HDMI1 (that the bad kernel *also* has, of course). I have reverted that commit as obviously broken, since I'm not going to release an -rc2 that doesn't even work for me (and since it *is* obviously broken). Shock, horror, that's how it is meant to work when we cannot determine whether or not there is actually an output attached to the VGA. The hw autodetect falsely declares some VGA connections, notably through KVM switches, as disconnected and so we need to do a manual probe to confirm the flaky hw. The first phase of that probe is to request the EDID from the monitor, not all monitors supply one and less through a KVM switch, so we cannot rely on a negative result from that test. (Absence of evidence is not evidence of absence and all that.) So it falls back to load-detection, which in your case it cannot do since all the available pipes are assigned and so it just reports the VGA connection as unknown. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm intel + exynos fixes
On Fri, Jun 8, 2012 at 3:12 PM, Chris Wilson ch...@chris-wilson.co.uk wrote: Shock, horror, that's how it is meant to work when we cannot determine whether or not there is actually an output attached to the VGA. We don't break existing installations. And that existing installation has worked for a long time. You broke it, it's a regression, get over it. It's reverted, and it stays reverted. Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm intel + exynos fixes
On Fri, Jun 8, 2012 at 3:12 PM, Chris Wilson ch...@chris-wilson.co.uk wrote: So it falls back to load-detection, which in your case it cannot do since all the available pipes are assigned and so it just reports the VGA connection as unknown. Btw, it's a singularly stupid decision to say Ok, I *know* I have a monitor on output X, and I have no clue what-so-ever what I have on output Y, and no indication there is anything even there, so let me just degrade the output on output Y just in case. Which is basically what you are arguing for. In addition to the idiotic of argument that ok, it used to work right, but we broke it on *purpose*, really. I'd suggest that if you see no other connectors at all, *then* you might say ok, let's assume that we have a VGA monitor behind a broken KVM switch. At that point, at least that assumption doesn't make things worse for anything else that you know is there. And if people have truly undetectable VGA hardware in addition to another (detectable) output, I would suggest that you tell them to force it with xrandr. Again, there's no way in hell I will accept the idiotic argument that my old working single-monitor setup should be broken because the i915 driver decided that I *might* have a second monitor on VGA despite everything else saying that is not the case. Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm intel + exynos fixes
On Fri, Jun 8, 2012 at 6:12 PM, Chris Wilson ch...@chris-wilson.co.uk wrote: On Fri, 8 Jun 2012 14:57:31 -0700, Linus Torvalds torva...@linux-foundation.org wrote: This breaks things for me. Bisect says: 9e612a008fa7fe493a473454def56aa321479495 is the first bad commit commit 9e612a008fa7fe493a473454def56aa321479495 Author: Chris Wilson ch...@chris-wilson.co.uk Date: Thu May 31 13:08:53 2012 +0100 drm/i915/crt: Do not rely upon the HPD presence pin Whilst most monitors do wire up the HPD presence pin, it seems quite a few KVM do not. Therefore if we simply rely on the HPD pin being asserted to indicate a connected monitor we fail miserable, so fall back to performing a DCC query for the EDID. Reported-and-tested-by: Matthieu LAVIE boiteamad...@hotmail.com Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50501 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch And the symptoms are that it boots in what appears to be the correct mode for my monitor (1920x1200), but when X starts it changes to 1024x768 mode. Which is not good, and not useful. The bad kernel has this in Xorg.0.log: [ 12.796] (II) intel(0): EDID for output VGA1 [ 12.796] (II) intel(0): Printing probed modes for output VGA1 [ 12.796] (II) intel(0): Modeline 1024x768x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz e) [ 12.796] (II) intel(0): Modeline 800x600x60.3 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz e) [ 12.796] (II) intel(0): Modeline 800x600x56.2 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz e) [ 12.796] (II) intel(0): Modeline 848x480x60.0 33.75 848 864 976 1088 480 486 494 517 +hsync +vsync (31.0 kHz e) [ 12.796] (II) intel(0): Modeline 640x480x59.9 25.18 640 656 752 800 480 489 492 525 -hsync -vsync (31.5 kHz e) which is pure and utter garbage. I think it's the default modes for the non-EDID case, and has nothing to do with actual hardware. The good kernel doesn't have those incorrect and bogus probed modes, and just has the correct HDMI1 (that the bad kernel *also* has, of course). I have reverted that commit as obviously broken, since I'm not going to release an -rc2 that doesn't even work for me (and since it *is* obviously broken). Shock, horror, that's how it is meant to work when we cannot determine whether or not there is actually an output attached to the VGA. The hw autodetect falsely declares some VGA connections, notably through KVM switches, as disconnected and so we need to do a manual probe to confirm the flaky hw. The first phase of that probe is to request the EDID from the monitor, not all monitors supply one and less through a KVM switch, so we cannot rely on a negative result from that test. (Absence of evidence is not evidence of absence and all that.) So it falls back to load-detection, which in your case it cannot do since all the available pipes are assigned and so it just reports the VGA connection as unknown. The whole concept of connector status unknown is basically useless. There's not really anything reasonable you can do with it and it's abused in lots of different ways by both drivers and userspace. Some userspace apps treat unknown as connected, others as disconnected, others as connected but considered off (e.g., laptop lid closed). And drivers abuse it similarly (e.g., report lvds as unknown if the lid is closed). Unknown should be dropped and drivers should really just report connected or disconnected. If the driver is not able to detect a monitor, report disconnected even is there may be a monitor behind a broken KVM that doesn't respond to DDC or load detection. Unfortunately, everyone's favorite userspace apps will all break in differing ways... Alex -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm intel + exynos fixes
On Fri, 8 Jun 2012 15:23:15 -0700, Linus Torvalds torva...@linux-foundation.org wrote: On Fri, Jun 8, 2012 at 3:12 PM, Chris Wilson ch...@chris-wilson.co.uk wrote: So it falls back to load-detection, which in your case it cannot do since all the available pipes are assigned and so it just reports the VGA connection as unknown. Btw, it's a singularly stupid decision to say Ok, I *know* I have a monitor on output X, and I have no clue what-so-ever what I have on output Y, and no indication there is anything even there, so let me just degrade the output on output Y just in case. And that was my point. You were blaming the patch for making you aware of existing behaviour that results in utter confusion, for as Alex points out there is no sane way for userspace to handle the unknown connection status from the detection routine. As such it is probably better if that was handled internally as result indeterminate; do not update current detection status which is the behaviour of some of the drm helpers but uniformly. If that were true, then userspace would continue to be told that the connection status was disconnected until a monitor was plugged in. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm intel + exynos fixes
On Fri, Jun 8, 2012 at 3:52 PM, Chris Wilson ch...@chris-wilson.co.uk wrote: And that was my point. You were blaming the patch for making you aware of existing behaviour that results in utter confusion, for as Alex points out there is no sane way for userspace to handle the unknown connection status from the detection routine. Ahh. Yes, then I agree with you. The current behavior is clearly insane in the presense of an unknown connector status. So if the higher levels are eventually fixed to say if one input is 'unknown' and another is 'connected', we'll assume 'unknown' means 'not connected', then we can re-apply that patch. As it is, it's apparently a disaster to reply 'unknown' in this situation. Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
