Re: [git pull] drm fixes

[Linus Torvalds]

On Wed, Nov 21, 2012 at 6:34 PM, Dave Airlie  wrote:
>
> its vmware/nouveua/radeon/intel/ttm scattered.

Hmm. That's not what I see. I just see nouveau and soem PCI ID addition.

>  21 files changed, 108 insertions(+), 31 deletions(-)

I get

 14 files changed, 70 insertions(+), 21 deletions(-)

probably due to this.

Forgot to push? The tip of your tree that I see is 452f19201f35d
("Merge branch 'drm-fixes-3.7' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes")

Or is it because you already sent me the intel fixes earlier?

  Linus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Dave Airlie]

On Thu, Nov 22, 2012 at 2:50 PM, Linus Torvalds
 wrote:
> On Wed, Nov 21, 2012 at 6:34 PM, Dave Airlie  wrote:
>>
>> its vmware/nouveua/radeon/intel/ttm scattered.
>
> Hmm. That's not what I see. I just see nouveau and soem PCI ID addition.
>
>>  21 files changed, 108 insertions(+), 31 deletions(-)
>
> I get
>
>  14 files changed, 70 insertions(+), 21 deletions(-)
>
> probably due to this.
>
> Forgot to push? The tip of your tree that I see is 452f19201f35d
> ("Merge branch 'drm-fixes-3.7' of
> git://people.freedesktop.org/~agd5f/linux into drm-fixes")
>
> Or is it because you already sent me the intel fixes earlier?

Doh!, yes I picked wrong place to generate report from, okay here is
one corresponding to what you saw,

The following changes since commit 6f755116c93ca35f496ccf1910dcd28cd16713e3:

  Merge branch 'drm-intel-fixes' of
git://people.freedesktop.org/~danvet/drm-intel into drm-fixes
(2012-11-16 10:00:43 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux drm-fixes

Alex Deucher (2):
  drm/radeon: properly track the crtc not_enabled case evergreen_mc_stop()
  drm/radeon: add new SI pci id

Dave Airlie (3):
  Merge branch 'drm-nouveau-fixes' of
git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes
  Merge branch 'drm-nouveau-fixes' of
git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes
  Merge branch 'drm-fixes-3.7' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes

Kelly Doran (1):
  drm/nvc0/disp: fix thinko in vblank regression fix..

Maarten Lankhorst (2):
  drm/nouveau: add missing pll_calc calls
  drm/nouveau: use the correct fence implementation for nv50

Marcin Slusarz (3):
  drm/nv40: allocate ctxprog with kmalloc
  drm/nouveau: fix crash with noaccel=1
  drm/nouveau/bios: fix DCB v1.5 parsing

Paul Bolle (1):
  radeon: add AGPMode 1 quirk for RV250

 drivers/gpu/drm/nouveau/core/engine/disp/nv50.c|   19 ---
 .../gpu/drm/nouveau/core/engine/graph/ctxnv40.c|   12 +---
 drivers/gpu/drm/nouveau/core/engine/graph/nv40.c   |4 +++-
 drivers/gpu/drm/nouveau/core/engine/graph/nv40.h   |2 +-
 drivers/gpu/drm/nouveau/core/include/core/object.h |   14 +-
 .../gpu/drm/nouveau/core/include/subdev/clock.h|3 ++-
 drivers/gpu/drm/nouveau/core/subdev/bios/dcb.c |2 +-
 drivers/gpu/drm/nouveau/core/subdev/clock/nva3.c   |   19 +++
 drivers/gpu/drm/nouveau/core/subdev/clock/nvc0.c   |1 +
 drivers/gpu/drm/nouveau/nouveau_abi16.c|4 
 drivers/gpu/drm/nouveau/nouveau_drm.c  |3 ++-
 drivers/gpu/drm/radeon/evergreen.c |2 ++
 drivers/gpu/drm/radeon/radeon_agp.c|5 -
 include/drm/drm_pciids.h   |1 +
 14 files changed, 70 insertions(+), 21 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Linus Torvalds]

[ Hmm. For some reason this seems to have never gone out, and was in
my drafts folder. If you get it twice, my bad ]

On Thu, Nov 22, 2012 at 12:57 AM, Dave Airlie  wrote:
>
> Doh!, yes I picked wrong place to generate report from, okay here is
> one corresponding to what you saw,

You should never even need to "pick" any place to generate the report from.

Just do something like

   git fetch upstream

(where "upstream" is a branch description for the upstream repository
- see "man git-remote" etc, although you can obviously always just
type out the whole repo details etc in full if you would want to).
Note the "fetch" - not pull - you just want to get it, not merge it.

Then you can just point git pull-request at the upstream, and git wll
figure out what the latest common point is. No need for you to
manually try to figure it out.

   Linus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Lucas Stach]

Hello Dave,

Am Sonntag, den 30.12.2012, 04:23 + schrieb Dave Airlie:
> Hi Linus,
> 
[...]
> 
> Lucas Stach (6):
>   drm: tegra: protect DC register access with mutex
 This patch is unnecessary and really shouldn't go in. There
was a brief discussion on the list with the conclusion to disregard this
patch.

Regards,
Lucas

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Dave Airlie]

On Sun, Dec 30, 2012 at 8:09 PM, Lucas Stach  wrote:
> Hello Dave,
>
> Am Sonntag, den 30.12.2012, 04:23 + schrieb Dave Airlie:
>> Hi Linus,
>>
> [...]
>>
>> Lucas Stach (6):
>>   drm: tegra: protect DC register access with mutex
>  This patch is unnecessary and really shouldn't go in. There
> was a brief discussion on the list with the conclusion to disregard this
> patch.

Linus, I just reverted it on top, didn't want to cause a rebase on  that branch,

updated pull req.

The following changes since commit a49f0d1ea3ec94fc7cf33a7c36a16343b74bd565:

  Linux 3.8-rc1 (2012-12-21 17:19:00 -0800)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux drm-next

for you to fetch changes up to d5757dbe79870d825d0dec30074d48683e1d7e9a:

  Revert "drm: tegra: protect DC register access with mutex"
(2012-12-30 21:58:20 +1000)


Alex Deucher (1):
  drm/radeon: add WAIT_UNTIL to evergreen VM safe reg list

Ben Skeggs (8):
  drm/nouveau: initial support for GK106
  drm/nouveau/bios: update gpio parsing apis to match current design
  drm/nouveau/bios: implement opcode 0xa9
  drm/nouveau/bios: parse/display extra version component
  drm/nouveau/mxm: silence output if no bios data
  drm/nouveau/bios: cache ramcfg strap on later chipsets
  drm/nvc0/graph: fix fuc, and enable acceleration on GF119
  drm/nve0/graph: fix fuc, and enable acceleration on all known chipsets

Chris Wilson (6):
  drm/i915: Fixup cursor latency used for IVB lp3 watermarks
  drm/i915: Double the cursor self-refresh latency on Valleyview
  drm/i915: Clear self-refresh watermarks when disabled
  drm/i915: Prefer CRTC 'active' rather than 'enabled' during WM
computations
  drm: Export routines for inserting preallocated nodes into the mm manager
  drm/i915: Preallocate the drm_mm_node prior to manipulating the
GTT drm_mm manager

Daniel Vetter (6):
  drm/i915: Implement WaDisableHiZPlanesWhenMSAAEnabled
  drm/i915: Implement WaSetupGtModeTdRowDispatch
  drm/i915: Implement workaround for broken CS tlb on i830/845
  drm/i915: don't disable disconnected outputs
  drm/i915: optionally disable shrinker lock stealing
  drm/i915: disable shrinker lock stealing for create_mmap_offset

Dave Airlie (5):
  drm/i915: fix flags in dma buf exporting
  Merge branch 'drm-nouveau-fixes-3.8' of
git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next
  Merge branch 'drm-fixes-3.8' of
git://people.freedesktop.org/~agd5f/linux into drm-next
  Merge branch 'drm-intel-fixes' of
git://people.freedesktop.org/~danvet/drm-intel into drm-next
  Revert "drm: tegra: protect DC register access with mutex"

Jerome Glisse (4):
  drm/radeon: don't leave fence blocked process on failed GPU reset
  drm/radeon: avoid deadlock in pm path when waiting for fence
  drm/radeon: restore modeset late in GPU reset path
  drm/radeon: add support for MEM_WRITE packet

Krzysztof Mazur (1):
  i915: ensure that VGA plane is disabled

Lucas Stach (6):
  drm: tegra: fix front_porch <-> back_porch mixup
  drm: tegra: don't leave clients host1x member uninitialized
  drm: tegra: protect DC register access with mutex
  drm: tegra: remove redundant tegra2_tmds_config entry
  drm: tegra: clean out old gem prototypes
  drm: tegra: program only one window during modeset

 drivers/gpu/drm/drm_mm.c   |  41 --
 drivers/gpu/drm/i915/i915_dma.c|   3 +
 drivers/gpu/drm/i915/i915_drv.h|   8 ++
 drivers/gpu/drm/i915/i915_gem.c|  77 +-
 drivers/gpu/drm/i915/i915_gem_dmabuf.c |   2 +-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |   2 +
 drivers/gpu/drm/i915/i915_irq.c|  12 ++
 drivers/gpu/drm/i915/i915_reg.h|   4 +-
 drivers/gpu/drm/i915/intel_display.c   |  23 ++-
 drivers/gpu/drm/i915/intel_pm.c| 160 ++---
 drivers/gpu/drm/i915/intel_ringbuffer.c|  76 --
 drivers/gpu/drm/i915/intel_ringbuffer.h|   1 +
 .../drm/nouveau/core/engine/graph/fuc/gpcnve0.fuc  |   5 +
 .../nouveau/core/engine/graph/fuc/gpcnve0.fuc.h|  17 ++-
 .../drm/nouveau/core/engine/graph/fuc/hubnvc0.fuc  |  10 ++
 .../nouveau/core/engine/graph/fuc/hubnvc0.fuc.h| 147 +--
 .../drm/nouveau/core/engine/graph/fuc/hubnve0.fuc  |  13 ++
 .../nouveau/core/engine/graph/fuc/hubnve0.fuc.h| 157 ++--
 drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c   |  11 +-
 drivers/gpu/drm/nouveau/core/engine/graph/nvc0.h   |   1 +
 drivers/gpu/drm/nouveau/core/engine/graph/nve0.c   |   3 +-
 drivers/gpu/drm/nouveau/core/include/subdev/bios.h |   1 +
 .../drm/nouveau/core/include/subdev/bios/gpio.h|   8 +-
 .../drm/nouveau/core/i

Re: [git pull] drm-fixes

[Daniel Vetter]

Hi Linus,

This pull also contains the fix for the eDP dmesg noise you've reported
(turned out to be a regression introduced in 3.5). Please yell if you
still see them. The DP regression Dave mentioned is a different bug
introduced in 3.4.

Thanks, Daniel

On Sun, Jun 17, 2012 at 08:42:28AM +0100, Dave Airlie wrote:
> Hi Linus,
> 
> radeon is most of the work, one regression, one BUG fix in the new prime 
> code, some fixes to init code to make streamout not lock up the hardware, 
> and just some code to enable users to test HDMI audio on later hw (its off by 
> default).
> 
> Intel adds edp edid caching for some strange Dell Vostros that black 
> screen on startup if keep reading their EDID, and a fix for a DP 
> regression.
> 
> Otherwise fix for via/sis and one to stop udl binding to multiple 
> non-video usb.
> 
> Dave.
> 
> The following changes since commit 9b15b817f3d62409290fd56fe3cbb076a931bb0a:
> 
>   swap: fix shmem swapping when more than 8 areas (2012-06-15 21:48:14 -0700)
> 
> are available in the git repository at:
> 
>   git://people.freedesktop.org/~airlied/linux drm-fixes
> 
> for you to fetch changes up to c4af5c4597a7a5d64e058703e1328f315a59794e:
> 
>   Merge branch 'drm-intel-fixes' of 
> git://people.freedesktop.org/~danvet/drm-intel into drm-fixes (2012-06-16 
> 14:45:17 +0100)
> 
> 
> 
> Alex Deucher (3):
>   drm/radeon: fix regression in dynpm due to multi-ring rework
>   drm/radeon: add some additional 6xx/7xx/EG register init
>   drm/radeon: add support for STRMOUT_BASE_UPDATE on 7xx
> 
> Daniel Vetter (2):
>   drm/i915: eDP aux needs vdd
>   Revert "drm/i915/dp: Use auxch precharge value of 5 everywhere"
> 
> Dave Airlie (3):
>   drm/udl: only bind to the video devices on the hub.
>   drm/radeon/prime: reserve/unreserve around pin
>   Merge branch 'drm-intel-fixes' of 
> git://people.freedesktop.org/~danvet/drm-intel into drm-fixes
> 
> Jesse Barnes (2):
>   drm/i915: don't enumerate HDMID if an eDP panel is already active on 
> the port
>   drm/i915: cache the EDID for eDP panels
> 
> Márton Németh (2):
>   drm via: initialize object_idr
>   drm sis: initialize object_idr
> 
> Rafał Miłecki (1):
>   drm/radeon: enable HDMI on DCE5 (AKA NI excluding Aruba)
> 
> Randy Dunlap (1):
>   vga_switcheroo.h: fix pci_dev warning
> 
>  drivers/gpu/drm/i915/intel_display.c   |2 +-
>  drivers/gpu/drm/i915/intel_dp.c|   60 
> 
>  drivers/gpu/drm/radeon/atombios_encoders.c |4 +-
>  drivers/gpu/drm/radeon/evergreen.c |3 ++
>  drivers/gpu/drm/radeon/evergreen_hdmi.c|3 --
>  drivers/gpu/drm/radeon/evergreend.h|1 +
>  drivers/gpu/drm/radeon/ni.c|5 +++
>  drivers/gpu/drm/radeon/r600.c  |1 +
>  drivers/gpu/drm/radeon/r600_audio.c|2 +-
>  drivers/gpu/drm/radeon/r600_cs.c   |   42 +++
>  drivers/gpu/drm/radeon/r600_hdmi.c |7 +---
>  drivers/gpu/drm/radeon/r600d.h |2 +
>  drivers/gpu/drm/radeon/radeon_drv.c|3 +-
>  drivers/gpu/drm/radeon/radeon_pm.c |   10 +++--
>  drivers/gpu/drm/radeon/radeon_prime.c  |   10 -
>  drivers/gpu/drm/radeon/rv770.c |5 ++-
>  drivers/gpu/drm/radeon/rv770d.h|3 ++
>  drivers/gpu/drm/sis/sis_drv.c  |2 +-
>  drivers/gpu/drm/udl/udl_drv.c  |   15 ++-
>  drivers/gpu/drm/via/via_map.c  |3 +-
>  include/linux/vga_switcheroo.h |2 +
>  21 files changed, 156 insertions(+), 29 deletions(-)

> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel


-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Henrik Rydberg]

Hi Dave,

> just two changes, one udl endian fix, one nouveau memory corruption on 
> some GPUs.

I have been tracking an elusive memory corruption bug appearing on my
MacBookAir3,1 (nv50) since -rc0, but unfortunately it seems to be
different from the one fixed here. The problem is of the random kind,
which made bisection tricky. It seems the patch below fixes the
symptoms, but I have no idea why:

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 7f80ed5..bff34f4 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -935,7 +935,6 @@ nouveau_bo_move_init(struct nouveau_channel *chan)
{  "COPY", 0, 0xa0b5, nve0_bo_move_copy, nvc0_bo_move_init },
{ "COPY1", 5, 0x90b8, nvc0_bo_move_copy, nvc0_bo_move_init },
{ "COPY0", 4, 0x90b5, nvc0_bo_move_copy, nvc0_bo_move_init },
-   {  "COPY", 0, 0x85b5, nva3_bo_move_copy, nv50_bo_move_init },
{ "CRYPT", 0, 0x74c1, nv84_bo_move_exec, nv50_bo_move_init },
{  "M2MF", 0, 0x9039, nvc0_bo_move_m2mf, nvc0_bo_move_init },
{  "M2MF", 0, 0x5039, nv50_bo_move_m2mf, nv50_bo_move_init },

With the patch applied, the log shows this:

Jun 27 07:01:15 polaris kernel: [drm] nouveau :02:00.0: MM: using M2MF for 
buffer copies

Without the patch applied, when the problem appears, the log shows this:

Jun 27 06:50:34 polaris kernel: [drm] nouveau :02:00.0: MM: using COPY for 
buffer copies

As I start X, and when the stars are in the right position, I get a bunch of 
errors like these:

Jun 27 06:51:52 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - TRAP_M2MF 
IN
Jun 27 06:51:52 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - TRAP_M2MF 
00320251 203afd00  04000e00
Jun 27 06:51:52 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - TRAP
Jun 27 06:51:52 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - ch 2 
(0x829000) subc 0 class 0x5039 mthd 0x0328 data 0x
Jun 27 06:51:52 polaris kernel: [drm] nouveau :02:00.0: VM: trapped read at 
0x00203abe80 on ch 2 [0x0829] PGRAPH/DISPATCH/M2M_IN reason: VRAM_LIMIT
Jun 27 06:51:52 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - TRAP_M2MF 
IN
Jun 27 06:51:52 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - TRAP_M2MF 
00320151 40442000  0400
Jun 27 06:51:52 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - TRAP
Jun 27 06:51:52 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - ch 2 
(0x829000) subc 0 class 0x5039 mthd 0x0328 data 0x
Jun 27 06:51:52 polaris kernel: [drm] nouveau :02:00.0: VM: trapped read at 
0x004041 on ch 2 [0x0829] PGRAPH/DISPATCH/M2M_IN reason: NULL_DMAOBJ
Jun 27 06:51:52 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - TRAP_M2MF 
IN
Jun 27 06:51:52 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - TRAP_M2MF 
00320251 203c7600  04000e00
Jun 27 06:51:52 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - TRAP
Jun 27 06:51:52 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - ch 2 
(0x829000) subc 0 class 0x5039 mthd 0x0328 data 0x
Jun 27 06:51:52 polaris kernel: [drm] nouveau :02:00.0: VM: trapped read at 
0x00203c3780 on ch 2 [0x0829] PGRAPH/DISPATCH/M2M_IN reason: VRAM_LIMIT
Jun 27 06:51:52 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - TRAP_M2MF 
IN
Jun 27 06:51:52 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - TRAP_M2MF 
00320151 40855000  0400
Jun 27 06:51:52 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - TRAP
Jun 27 06:51:52 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - ch 2 
(0x829000) subc 0 class 0x5039 mthd 0x0328 data 0x
Jun 27 06:51:52 polaris kernel: [drm] nouveau :02:00.0: VM: trapped read at 
0x004082 on ch 2 [0x0829] PGRAPH/DISPATCH/M2M_IN reason: NULL_DMAOBJ
Jun 27 06:51:53 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - TRAP_M2MF 
OUT
Jun 27 06:51:53 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - TRAP_M2MF 
00340241 2014bb80  05000e00
Jun 27 06:51:53 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - TRAP
Jun 27 06:51:53 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - ch 2 
(0x829000) subc 0 class 0x5039 mthd 0x0328 data 0x
Jun 27 06:51:53 polaris kernel: [drm] nouveau :02:00.0: VM: trapped write 
at 0x002014ad00 on ch 2 [0x0829] PGRAPH/DISPATCH/M2M_OUT reason: VRAM_LIMIT
Jun 27 06:51:53 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - TRAP_M2MF 
OUT
Jun 27 06:51:53 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - TRAP_M2MF 
00340241 2014bb80  05000e00
Jun 27 06:51:53 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - TRAP
Jun 27 06:51:53 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - ch 2 
(0x829000) subc 0 class 0x5039 mthd 0x0328 data 0x
Jun 27 06:51:53 polaris kernel: [drm] nouveau :02:00.0: VM: trapped write 
at 0x00201770f0 on ch 2 [0x00

Re: [git pull drm fixes

[Pekka Enberg]

Hi Dave,

On Fri, Aug 5, 2011 at 12:22 PM, Dave Airlie  wrote:
> Intel modesetting fixes a lot of them, Keith, Jesse and ajax have been
> focusing on a lot of the corner cases and display port and hdmi stuff.
>
> misc radeon fixes, the main one being for certain machines where EDID
> returns what looks like misc noise when connectors aren't populated on
> certain boards.
>
> and some misc trivial type fixes.

Isn't "drm/i915: Try enabling RC6 by default (again)" still broken for
some people? Keith, Francesco? If Linus pulls now, we end up with
broken i915 in -rc1 once again, no?

 Pekka
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull drm fixes

[Dave Airlie]

On Fri, Aug 5, 2011 at 10:45 AM, Pekka Enberg  wrote:
> Hi Dave,
>
> On Fri, Aug 5, 2011 at 12:22 PM, Dave Airlie  wrote:
>> Intel modesetting fixes a lot of them, Keith, Jesse and ajax have been
>> focusing on a lot of the corner cases and display port and hdmi stuff.
>>
>> misc radeon fixes, the main one being for certain machines where EDID
>> returns what looks like misc noise when connectors aren't populated on
>> certain boards.
>>
>> and some misc trivial type fixes.
>
> Isn't "drm/i915: Try enabling RC6 by default (again)" still broken for
> some people? Keith, Francesco? If Linus pulls now, we end up with
> broken i915 in -rc1 once again, no?

I think we are trying again with RC6, if it doesn't work this time,
it'll get reverted before release. Its really a useful feature and the
more testing of it the Intel guys can get the quicker they seem to be
able to make it more likely to be the default.

Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull drm fixes

[Pekka Enberg]

On Fri, Aug 5, 2011 at 12:48 PM, Dave Airlie  wrote:
>> Isn't "drm/i915: Try enabling RC6 by default (again)" still broken for
>> some people? Keith, Francesco? If Linus pulls now, we end up with
>> broken i915 in -rc1 once again, no?
>
> I think we are trying again with RC6, if it doesn't work this time,
> it'll get reverted before release. Its really a useful feature and the
> more testing of it the Intel guys can get the quicker they seem to be
> able to make it more likely to be the default.

Please don't do that! The RC6 patch is known to be broken for at least
one configuration:

https://patchwork.kernel.org/patch/1033782/

See the last email from Francesco. I don't know why you insist pushing
patches that are known to be fragile in the past without getting broad
Tested-by tags from people who have been affected in the past.

   Pekka
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull drm fixes

[Dave Airlie]

On Fri, 5 Aug 2011, Pekka Enberg wrote:

> On Fri, Aug 5, 2011 at 12:48 PM, Dave Airlie  wrote:
> >> Isn't "drm/i915: Try enabling RC6 by default (again)" still broken for
> >> some people? Keith, Francesco? If Linus pulls now, we end up with
> >> broken i915 in -rc1 once again, no?
> >
> > I think we are trying again with RC6, if it doesn't work this time,
> > it'll get reverted before release. Its really a useful feature and the
> > more testing of it the Intel guys can get the quicker they seem to be
> > able to make it more likely to be the default.
> 
> Please don't do that! The RC6 patch is known to be broken for at least
> one configuration:
> 
> https://patchwork.kernel.org/patch/1033782/
> 
> See the last email from Francesco. I don't know why you insist pushing
> patches that are known to be fragile in the past without getting broad
> Tested-by tags from people who have been affected in the past.

Okay I hadn't seen Francesco's report of still failing, I've pushed a 
revert on top of that pull,

Linus the pull is below.

Dave,
running this kernel but getting spikes of 10-15s ping times to my wireless 
router, iwlagn strikes again.


The following changes since commit 288d5abec8314ae50fe6692f324b0444acae8486:

  Boot up with usermodehelper disabled (2011-08-03 22:03:29 -1000)

are available in the git repository at:
  ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-fixes

Adam Jackson (10):
  drm/i915/dp: Zero the DPCD data before connection probe
  drm/i915/dp: Move DPCD dump to common code instead of PCH-only
  drm/i915/dp: Read more DPCD registers on connection probe
  drm/i915/dp: Better hexdump of DPCD
  drm/i915/dp: Retry DPCD fetch on G4X too
  drm/i915/dp: Explicitly request 8/10 channel coding
  drm/i915/pch: Fix integer math bugs in panel fitting
  drm/i915/dp: Explicitly disable symbol scrambling while training
  drm/i915/dp: Don't turn CPT DP ports on too early
  drm/i915/pch: Save/restore PCH_PORT_HOTPLUG across suspend

Alex Deucher (2):
  drm/radeon/kms: fix version comment due to merge timing
  drm/radeon/kms: add thermal chip quirk for asus 9600xt

Bojan Prtvar (1):
  drm/radeon: fix potential NULL dereference in 
drivers/gpu/drm/radeon/atom.c

Dan Carpenter (1):
  drm/radeon: off by one in check_reg() functions

Dave Airlie (2):
  Merge branch 'drm-intel-next' of 
ssh://master.kernel.org/.../keithp/linux-2.6 into drm-fixes
  Revert "drm/i915: Try enabling RC6 by default (again)"

Emil Velikov (1):
  drm/debugfs: Initialise empty variable

Fernando Luis Vázquez Cao (1):
  drm/radeon: clean reg header files

Jesse Barnes (15):
  drm/i915: provide more error output when mode sets fail
  drm/i915: load the LUT before pipe enable on ILK+
  drm/i915: apply timing generator bug workaround on CPT and PPT
  drm/i915: flush plane control changes on ILK+ as well
  drm/i915: fix CB tuning check for ILK+
  drm/i915/hdmi: send AVI info frames on ILK+ as well
  drm/i915: add GPU max frequency control file
  drm/i915: provide more error output when mode sets fail
  drm/i915: apply phase pointer override on SNB+ too
  drm/i915: don't use uninitialized EDID bpc values when picking pipe bpp
  drm/i915/dp: wait for previous AUX channel activity to clear
  drm: track CEA version number if present
  drm/i915/hdmi: split infoframe setting from infoframe type code
  drm/i915/hdmi: HDMI source product description infoframe support
  drm/i915: allow cache sharing policy control

Joonyoung Shim (2):
  drm: Fix irq install error handling
  drm: Add NULL check about irq functions

Keith Packard (20):
  drm/i915: Skip GPU wait for scanout pin while wedged
  drm/i915: Initialize RCS ring status page address in 
intel_render_ring_init_dri
  Merge branch 'drm-intel-fixes' into drm-intel-next
  drm/i915: Hold mode_config->mutex during hotplug processing
  Merge branch 'drm-intel-fixes' into drm-intel-next
  Merge branch 'drm-intel-fixes' into drm-intel-next
  drm/i915: Fixup for 'Hold mode_config->mutex during hotplug'
  drm/i915: Use dp_detect_common in hotplug helper function
  drm/i915: Rename i915_dp_detect_common to intel_dp_get_dpcd
  drm/i915: In intel_dp_init, replace read of DPCD with intel_dp_get_dpcd
  drm/i915: DP_PIPE_ENABLED must check transcoder on CPT
  Revert and fix "drm/i915/dp: remove DPMS mode tracking from DP"
  drm/i915: Set crtc DPMS mode to ON in intel_crtc_mode_set
  drm/i915: Flush other plane register writes
  Merge branch 'drm-intel-fixes' into drm-intel-next
  drm/i915: Ignore GPU wedged errors while pinning scanout buffers
  Merge branch 'drm-intel-fixes' into drm-intel-next
  Revert "drm/i915/dp: Zero the DPCD data before connection probe"
  Merge branch 'drm-intel-fixes' into drm-intel-next
  drm/i915: Try enabling RC6 by default (a

Re: [git pull drm fixes

[Pekka Enberg]

On Fri, Aug 5, 2011 at 1:04 PM, Dave Airlie  wrote:
> Okay I hadn't seen Francesco's report of still failing, I've pushed a
> revert on top of that pull,

Thanks Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull drm fixes

[Keith Packard]

On Fri, 5 Aug 2011 12:51:42 +0300, Pekka Enberg  wrote:

> See the last email from Francesco. I don't know why you insist pushing
> patches that are known to be fragile in the past without getting broad
> Tested-by tags from people who have been affected in the past.

Yeah, we had several reports that it fixed similar situations, but I
hadn't heard back from Francesco before I sent the pull request.  I'll
work directly with Francesco to try and get the last problems resolved.

His machine appears to be 'special' (it's identical in every way to one
that I have, except that his breaks and mine works...)

-- 
keith.pack...@intel.com


pgpQcTmvy5IMB.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Linus Torvalds]

On Tue, Oct 4, 2011 at 9:34 AM, Dave Airlie  wrote:
>
> all radeon fixes, one nasty startup crash and/or memory corruption on one
> family of radeon hd6450s resulted in a patch to stop setting a bunch of
> regs in the drivers and let the BIOS set them correctly, displayport
> regression fix, and some off-by-one in the cursor code around the corners
> of the screens.

Has this been tested with suspend/resume on a lot of machines?

In general, the registers that get set on boot correctly absolutely do
*not* get set on resume.

So the registers that you now no longer set at boot-time should almost
certainly still be saved and restored across suspend/resume. I don't
know the code well enough to read the diffs, but a quick grep seems to
show that when you removed the boot-time setup, you also removed the
resume-time setup (well, at least MC_SHARED_CHREMAP doesn't seem to be
used anywhere any more: it may be that it's saved-restores in some
kind of "loop over all registers" that wouldn't have triggered the
grep).

I pulled, but please verify that whole thing.

  Linus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Alex Deucher]

On Tue, Oct 4, 2011 at 12:58 PM, Linus Torvalds
 wrote:
> On Tue, Oct 4, 2011 at 9:34 AM, Dave Airlie  wrote:
>>
>> all radeon fixes, one nasty startup crash and/or memory corruption on one
>> family of radeon hd6450s resulted in a patch to stop setting a bunch of
>> regs in the drivers and let the BIOS set them correctly, displayport
>> regression fix, and some off-by-one in the cursor code around the corners
>> of the screens.
>
> Has this been tested with suspend/resume on a lot of machines?
>
> In general, the registers that get set on boot correctly absolutely do
> *not* get set on resume.
>
> So the registers that you now no longer set at boot-time should almost
> certainly still be saved and restored across suspend/resume. I don't
> know the code well enough to read the diffs, but a quick grep seems to
> show that when you removed the boot-time setup, you also removed the
> resume-time setup (well, at least MC_SHARED_CHREMAP doesn't seem to be
> used anywhere any more: it may be that it's saved-restores in some
> kind of "loop over all registers" that wouldn't have triggered the
> grep).
>
> I pulled, but please verify that whole thing.

It's safe.  The hw default value is fine (value in the register at
asic power up).  On most cards the hw default value is is fine.  If it
needs to be overridden in certain cases, that's handled by the
asic_init vbios table which is executed at boot by the vbios and by
the driver at resume time.

Alex
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Linus Torvalds]

On Mon, Nov 7, 2011 at 5:27 AM, Dave Airlie  wrote:
>
> are available in the git repository at:
>
>  ssh://people.freedesktop.org/~/linux drm-fixes

No they are *not* available there.

Fix your pull script already! I mentioned this once earlier, your pull
requests are wrong, and point to things that just don't *exist* for
anybody but you.

I don't have ssh access to that server, and even if I did, that "~"
would be wrong.

   Linus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Dave Airlie]

On Mon, Nov 7, 2011 at 6:00 PM, Linus Torvalds
 wrote:
> On Mon, Nov 7, 2011 at 5:27 AM, Dave Airlie  wrote:
>>
>> are available in the git repository at:
>>
>>  ssh://people.freedesktop.org/~/linux drm-fixes
>
> No they are *not* available there.
>
> Fix your pull script already! I mentioned this once earlier, your pull
> requests are wrong, and point to things that just don't *exist* for
> anybody but you.
>
> I don't have ssh access to that server, and even if I did, that "~"
> would be wrong.
>
Oops I generated on my desktop since I was home and it wasn't using
correct script.

Here is a clean version.

Dave.

The following changes since commit 094803e0aab3fe75bbf8202a8f4b5280eaade375:

  Merge branch 'akpm' (Andrew's incoming) (2011-10-31 17:46:07 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux drm-fixes

Alex Deucher (22):
  drm/radeon/kms: rework texture cache flush in r6xx+ blit code
  drm/radeon/kms/cayman/blit: specify CP_COHER_CNTL2 with surface_sync
  drm/radeon/kms: properly set panel mode for eDP
  drm/radeon/kms: cleanup atombios_adjust_pll()
  drm/radeon/kms: rework DP bridge checks
  drm/radeon/kms: only require 2.7 Ghz DP clock for NUTMEG
  drm/radeon/kms/atom: rework encoder dpms
  drm/radeon/kms: check for DP MST mode in a few more places (v2)
  drm/radeon/kms: allocate vram scratch page on 6xx+
  drm/radeon/kms: move atom encoder setup to a new file
  drm/radeon/kms: make atombios_dvo_setup() version based
  drm/radeon/kms: make atombios_dig_encoder_setup() version based
  drm/radeon/kms: make atombios_dig_transmitter_setup() version based
  drm/radeon/kms: remove useless radeon_ddc_dump()
  drm/radeon/kms: always do extended edid probe
  drm/radeon/kms: split MSI check into a separate function
  drm/radeon/kms: Add MSI quirk for HP RS690
  drm/radeon/kms: Add MSI quirk for Dell RS690
  drm/radeon/kms: add MSI module parameter
  drm/radeon/kms: set HPD polarity in hpd_init()
  drm/radeon/kms: fix DP setup on TRAVIS bridges
  drm/radeon/kms: don't poll forever if MC GDDR link training fails

Ilija Hadzic (1):
  drm/radeon/kms: use defined constants for crtc/hpd count instead
of hard-coded value 6

Jakob Bornecrantz (5):
  vmwgfx: Use pointer return error codes
  vmwgfx: Free prefered mode on error path
  vmwgfx: Unreference surface on cursor error path
  vmwgfx: Move the prefered mode first in the list
  vmwgfx: Snoop DMA transfers with non-covering sizes

Jerome Glisse (4):
  drm/radeon: avoid bouncing connector status btw disconnected & unknown
  drm/radeon: set hpd polarity at init time so hotplug detect works
  drm/radeon: flush read cache for gtt with fence on r6xx and newer GPU V3
  drm/radeon/kms: consolidate GART code, fix segfault after GPU lockup V2

Thomas Hellstrom (8):
  drm: Introduce "Virtual" connectors and encoders
  vmwgfx: Use "Virtual" connectors and encoders rather than "LVDS".
  vmwgfx: Reinstate the update_layout ioctl
  vmwgfx: Screen object cleanups
  vmwgfx: Remove screen object active list
  vmwgfx: Make the preferred autofit mode have a 60Hz vrefresh
  vmwgfx: Infrastructure for explicit placement
  vmwgfx: Fix hw cursor position

 drivers/gpu/drm/drm_crtc.c  |8 +-
 drivers/gpu/drm/radeon/Makefile |2 +-
 drivers/gpu/drm/radeon/atombios_crtc.c  |   56 +-
 drivers/gpu/drm/radeon/atombios_dp.c|   20 +-
 drivers/gpu/drm/radeon/atombios_encoders.c  | 2369 +++
 drivers/gpu/drm/radeon/evergreen.c  |   18 +-
 drivers/gpu/drm/radeon/evergreen_blit_kms.c |   20 +-
 drivers/gpu/drm/radeon/ni.c |   25 +-
 drivers/gpu/drm/radeon/r100.c   |7 +-
 drivers/gpu/drm/radeon/r300.c   |   16 +-
 drivers/gpu/drm/radeon/r600.c   |  106 +-
 drivers/gpu/drm/radeon/r600_blit_kms.c  |   14 +-
 drivers/gpu/drm/radeon/radeon.h |   57 +-
 drivers/gpu/drm/radeon/radeon_connectors.c  |   90 +-
 drivers/gpu/drm/radeon/radeon_display.c |   36 +-
 drivers/gpu/drm/radeon/radeon_drv.c |4 +
 drivers/gpu/drm/radeon/radeon_encoders.c| 2151 +
 drivers/gpu/drm/radeon/radeon_gart.c|   71 +-
 drivers/gpu/drm/radeon/radeon_i2c.c |   28 +-
 drivers/gpu/drm/radeon/radeon_irq_kms.c |   60 +-
 drivers/gpu/drm/radeon/radeon_mode.h|   14 +-
 drivers/gpu/drm/radeon/rs400.c  |5 +-
 drivers/gpu/drm/radeon/rs600.c  |   17 +-
 drivers/gpu/drm/radeon/rv770.c  |   73 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |6 +
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |6 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |  151 ++-
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.h |   10 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c |5 +-
 drivers/gpu/dr

Re: [git pull] drm fixes

[Linus Torvalds]

On Tue, Dec 6, 2011 at 8:21 AM, Dave Airlie  wrote:
>
> 3 fixes, one for an ongoing Intel VT-d/Ironlake GPU that I've been
> testing, and one kexec fix from Jerome for an issue reported on the list
> where the gpu writeback engines need to be switched off, along with a
> trivial fix from Alex.

Quite frankly, I think it's too late for something like a kexec
bugfix. Nobody cares. So kexec doesn't work - that's not something
new. This doesn't smell like a regression to me. And the kcalloc
things you mention *sound* like some kind of cleanup crap.

The DRM layer has been fairly good for a few releases, but I'm getting
the feeling that I need to start pushing back, because I'm getting
stuff that I don't think matters, and shouldn't be sent to me after
-rc4.

So I'm not pulling this.

What the heck is up?

By now, I want fixes that either fix real regressions that people
*care* about, or that help new unreleased hardware that people *will*
care about and that cannot possibly mess up old users.

kexec? Who the f*ck cares? Really?

  Linus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Dave Airlie]

>
> What the heck is up?

Well I do care about kexec but only due to being forced into caring
about it for a certain enterprise distro that uses it a lot, so maybe
I was a bit biased in this case, and I dislike random memory
corruptions due to my subsystem even in the kexec case. Writing a
random 0 dword somewhere in memory isn't that pretty and no fun to
track down, when the kexec looks like it succeeds.

But I've no problem leaving it sitting around until -next.

The kzalloc->kcalloc ones are partly better integer overflow defence
where userspace passes in a number of objects but I just need to make
sure they are that and not cleanups, but I haven't gotten around to it
yet.

Cool I'll resend just the Intel and obvious radeon one and stick the
others into -next.

Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Linus Torvalds]

On Tue, Dec 6, 2011 at 8:36 AM, Dave Airlie  wrote:
>
> Well I do care about kexec but only due to being forced into caring
> about it for a certain enterprise distro that uses it a lot, so maybe
> I was a bit biased in this case, and I dislike random memory
> corruptions due to my subsystem even in the kexec case. Writing a
> random 0 dword somewhere in memory isn't that pretty and no fun to
> track down, when the kexec looks like it succeeds.

So having looked at the patch itself, I don't dislike the notion of
making sure certain fields are nicely initialized. So I don't hate the
patch itself, but quite frankly, to me it doesn't smell even
*remotely* like "regression fix". I don't think this is something that
has ever worked.

And I do realize that some enterprise distros want to use kexec, but
at the same time I say "that's *their* problem". We know kexec hasn't
been horribly reliable, anybody who uses it should have be taking that
into account.

I hope kexec gets more reliable, but I *also* really hope that our RC
series will calm down, and on the whole, weighing the two concerns,
when we're talking about something that has never worked before
either, I think the thing is pretty clear.

That said, if there is some other real use-case ("this fixes problems
with the BIOS from Xyz initializing things to random crap"), I'd have
no real objections to the patch itself.

So my complaint is really a "I want to be more anal about the later
-rc patches, I feel we're slipping", not a "I hate the patch per se".

  Linus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Dave Airlie]

> So having looked at the patch itself, I don't dislike the notion of
> making sure certain fields are nicely initialized. So I don't hate the
> patch itself, but quite frankly, to me it doesn't smell even
> *remotely* like "regression fix". I don't think this is something that
> has ever worked.

Well just for completeness I tracked it down to
724c80e1d630296d1324859e964d80d35007d83c
which git describe shows as v2.6.36-rc5-456-g724c80e, so while it is a
technical regression, it took a long time for anyone to notice.

I think we probably need a more invasive patch in any case, as there
is still a race between when the drm midlayer calls pci_set_master and
the sanity enforcement, which we should close by moving pci_set_master
into the drivers (midlayer design yet again for the win).

so I'll leave it for -next.

Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Dave Airlie]

(ignore original, this one comes with a believable changelog).

> Hi Linus,
> 
> simple one just one pci ids patch from Alex,
> 
> I know Keith has some patches outstanding in his queue and I know they are 
> probably more than you'll want to merge at this point, I'm off until next 
> week, so Keith if you do send a pull request you may as well send to 
> Linus, since I know Linus can be more lenient on pulls which make the hw 
> he uses suck less :-)
> 
The following changes since commit 373da0a2a33018d560afcb2c77f8842985d79594:

  Merge branch 'x86-urgent-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip (2011-12-13 15:02:31 
-0800)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux drm-fixes

Alex Deucher (1):
  drm/radeon/kms: add some new pci ids

 include/drm/drm_pciids.h |   10 ++
 1 files changed, 10 insertions(+), 0 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Linus Torvalds]

On Wed, Jan 25, 2012 at 11:05 AM, Dave Airlie  wrote:
>
> bunch of regression fixes since TTM rework and radeon initialisation,
> modesetting fixes for Alex to fix some black screens on kms start type
> issues, and two radeon ACPI fixes that make some laptops no oops on
> startup.

Does that include for the nvidia (?) suspend/resume issue? You were
cc'd on it (but the subject may have made you ignore it - it was part
of a thread about wireless network suspend issues: "bcma/brcmsmac
suspend/resume cleanups and fixes"):

  No trivial bisect. I wish I had a faster build machine, but alas. I
  suspected some issue in DRM and the bisect took me into drm-core-next
  branch. I ended up at the following commit:

  dc97b3409a790d2a21aac6e5cdb99558b5944119 is the first bad commit
  commit dc97b3409a790d2a21aac6e5cdb99558b5944119
  Author: Jerome Glisse 
  Date:   Fri Nov 18 11:47:03 2011 -0500

Hmm?

 Linus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Jerome Glisse]

On Wed, Jan 25, 2012 at 6:31 PM, Linus Torvalds
 wrote:
> On Wed, Jan 25, 2012 at 11:05 AM, Dave Airlie  wrote:
>>
>> bunch of regression fixes since TTM rework and radeon initialisation,
>> modesetting fixes for Alex to fix some black screens on kms start type
>> issues, and two radeon ACPI fixes that make some laptops no oops on
>> startup.
>
> Does that include for the nvidia (?) suspend/resume issue? You were
> cc'd on it (but the subject may have made you ignore it - it was part
> of a thread about wireless network suspend issues: "bcma/brcmsmac
> suspend/resume cleanups and fixes"):
>
>  No trivial bisect. I wish I had a faster build machine, but alas. I
>  suspected some issue in DRM and the bisect took me into drm-core-next
>  branch. I ended up at the following commit:
>
>  dc97b3409a790d2a21aac6e5cdb99558b5944119 is the first bad commit
>  commit dc97b3409a790d2a21aac6e5cdb99558b5944119
>  Author: Jerome Glisse 
>  Date:   Fri Nov 18 11:47:03 2011 -0500
>
> Hmm?
>
>                     Linus

Ben Skeggs patch fix this issue.

Cheers,
Jerome
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Dave Airlie]

> >
> > bunch of regression fixes since TTM rework and radeon initialisation,
> > modesetting fixes for Alex to fix some black screens on kms start type
> > issues, and two radeon ACPI fixes that make some laptops no oops on
> > startup.
> 
> Does that include for the nvidia (?) suspend/resume issue? You were
> cc'd on it (but the subject may have made you ignore it - it was part
> of a thread about wireless network suspend issues: "bcma/brcmsmac
> suspend/resume cleanups and fixes"):
> 

As Jerome said, Ben's ttm patch should fix it up. I meant to mention that.

Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Torsten Kaiser]

On Wed, Feb 22, 2012 at 8:56 PM, Dave Airlie  wrote:
> Eugeni Dodonov (4):
>      drm/i915: gen7: implement rczunit workaround
>      drm/i915: gen7: Implement an L3 caching workaround.
>      drm/i915: gen7: work around a system hang on IVB
>      drm/i915: do not enable RC6p on Sandy Bridge

That last patch about RC6p looks wrong.

It does:
 GEN6_RC_CTL_RC6_ENABLE |
(IS_GEN7(dev_priv->dev)) ? GEN6_RC_CTL_RC6p_ENABLE : 0;
But I think this was meant:
 GEN6_RC_CTL_RC6_ENABLE |
((IS_GEN7(dev_priv->dev)) ? GEN6_RC_CTL_RC6p_ENABLE : 
0);

Or did I get the operator precedence wrong?

HTH

Torsten
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Jesse Barnes]

On Thu, 23 Feb 2012 21:19:20 +0100
Torsten Kaiser  wrote:

> On Wed, Feb 22, 2012 at 8:56 PM, Dave Airlie  wrote:
> > Eugeni Dodonov (4):
> >      drm/i915: gen7: implement rczunit workaround
> >      drm/i915: gen7: Implement an L3 caching workaround.
> >      drm/i915: gen7: work around a system hang on IVB
> >      drm/i915: do not enable RC6p on Sandy Bridge
> 
> That last patch about RC6p looks wrong.
> 
> It does:
>  GEN6_RC_CTL_RC6_ENABLE |
>   (IS_GEN7(dev_priv->dev)) ? GEN6_RC_CTL_RC6p_ENABLE : 0;
> But I think this was meant:
>  GEN6_RC_CTL_RC6_ENABLE |
>   ((IS_GEN7(dev_priv->dev)) ? GEN6_RC_CTL_RC6p_ENABLE : 
> 0);
> 
> Or did I get the operator precedence wrong?

You're right, no cookie for Eugeni. :)  This would have prevented RC6
from ever getting enabled though, which should have the same effect as
the patch intended, though at the cost of higher power consumption.

Fix just sent to Dave anyway.

-- 
Jesse Barnes, Intel Open Source Technology Center


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Eugeni Dodonov]

On Mon, Feb 27, 2012 at 13:09, Jesse Barnes wrote:

> On Thu, 23 Feb 2012 21:19:20 +0100
> Torsten Kaiser  wrote:
>
> > On Wed, Feb 22, 2012 at 8:56 PM, Dave Airlie  wrote:
> > > Eugeni Dodonov (4):
> > >  drm/i915: gen7: implement rczunit workaround
> > >  drm/i915: gen7: Implement an L3 caching workaround.
> > >  drm/i915: gen7: work around a system hang on IVB
> > >  drm/i915: do not enable RC6p on Sandy Bridge
> >
> > That last patch about RC6p looks wrong.
> >
> > It does:
> >  GEN6_RC_CTL_RC6_ENABLE |
> >   (IS_GEN7(dev_priv->dev)) ? GEN6_RC_CTL_RC6p_ENABLE
> : 0;
> > But I think this was meant:
> >  GEN6_RC_CTL_RC6_ENABLE |
> >   ((IS_GEN7(dev_priv->dev)) ?
> GEN6_RC_CTL_RC6p_ENABLE : 0);
> >
> > Or did I get the operator precedence wrong?
>
> You're right, no cookie for Eugeni. :)  This would have prevented RC6
> from ever getting enabled though, which should have the same effect as
> the patch intended, though at the cost of higher power consumption.
>

Actually, no, it got RC6p enabled - so it got to have all the power savings
of RC6 plus some additional ones in the range of 0.1W, but it also resulted
in the very same problem as before, when both RC6 and RC6p were enabled.

So, from what we've seen with
https://wiki.ubuntu.com/Kernel/PowerManagementRC6, the graphics corruptions
do only happen when RC6p is enabled (either together with RC6, or
individually, on its own). If we have only RC6, all the issues are gone so
far.

So this bad patch had its use after all - it served to finally isolate and
prove that the i915_enable_rc6-related issues are caused directly by RC6p.

-- 
Eugeni Dodonov
 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Jesse Barnes]

On Mon, 27 Feb 2012 13:33:53 -0300
Eugeni Dodonov  wrote:

> On Mon, Feb 27, 2012 at 13:09, Jesse Barnes wrote:
> 
> > On Thu, 23 Feb 2012 21:19:20 +0100
> > Torsten Kaiser  wrote:
> >
> > > On Wed, Feb 22, 2012 at 8:56 PM, Dave Airlie  wrote:
> > > > Eugeni Dodonov (4):
> > > >  drm/i915: gen7: implement rczunit workaround
> > > >  drm/i915: gen7: Implement an L3 caching workaround.
> > > >  drm/i915: gen7: work around a system hang on IVB
> > > >  drm/i915: do not enable RC6p on Sandy Bridge
> > >
> > > That last patch about RC6p looks wrong.
> > >
> > > It does:
> > >  GEN6_RC_CTL_RC6_ENABLE |
> > >   (IS_GEN7(dev_priv->dev)) ? GEN6_RC_CTL_RC6p_ENABLE
> > : 0;
> > > But I think this was meant:
> > >  GEN6_RC_CTL_RC6_ENABLE |
> > >   ((IS_GEN7(dev_priv->dev)) ?
> > GEN6_RC_CTL_RC6p_ENABLE : 0);
> > >
> > > Or did I get the operator precedence wrong?
> >
> > You're right, no cookie for Eugeni. :)  This would have prevented RC6
> > from ever getting enabled though, which should have the same effect as
> > the patch intended, though at the cost of higher power consumption.
> >
> 
> Actually, no, it got RC6p enabled - so it got to have all the power savings
> of RC6 plus some additional ones in the range of 0.1W, but it also resulted
> in the very same problem as before, when both RC6 and RC6p were enabled.
> 
> So, from what we've seen with
> https://wiki.ubuntu.com/Kernel/PowerManagementRC6, the graphics corruptions
> do only happen when RC6p is enabled (either together with RC6, or
> individually, on its own). If we have only RC6, all the issues are gone so
> far.
> 
> So this bad patch had its use after all - it served to finally isolate and
> prove that the i915_enable_rc6-related issues are caused directly by RC6p.

Oh you're right; I had the bit positions mixed up...  I thought the
higher level bit toggled all RC6 functionality, but that's kept
separate from this.

-- 
Jesse Barnes, Intel Open Source Technology Center


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Dave Airlie]

> gma500 build fix + some regression fixes for nouveau/radeon, along with
> one radeon patch that was posted a while ago and I missed and it also required
> rebasing around some other stuff.

I've added one more commit to this.

commit d936622c36273a9ecfbb4aacf26cd29405995159
Author: Michel Dänzer 
Date:   Wed Mar 28 08:52:32 2012 +0200

drm/radeon: Only warn if the intra-domain offset actually exceeds the limit.

it had 3 reports/tests.

Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Dave Airlie]

> 
> Hi Linus,

Updated this pull with one more pci id commit.

commit 79b9517a33a283c5d9db875c263670ed1e055f7e
Author: Dave Airlie 
Date:   Mon Apr 19 17:54:31 2010 +1000

drm/radeon/kms: add FireMV 2400 PCI ID.

is the new HEAD.

Dave.
> 
> Just radeon fixes, the most important one being a one char typo in the 
> rs600 setup that caused memory corruption with KMS on this particular 
> chipset. RS600s are a really rare chipset, so it took a while for Jerome 
> to track one down to reproduce. Others are mainly fixes to open bugs and a 
> regression in the smooth booting process thats caused flicker when X 
> started up. Along with some register updates to the command stream parser.
> 
> The following changes since commit 930b9d94579fa1ea9604cbf7ba56cedf99ba9b5c:
>   Dave Airlie (1):
> Merge remote branch 'nouveau/for-airlied' of ../drm-nouveau-next into 
> drm-linus
> 
> are available in the git repository at:
> 
>   ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git 
> drm-linus
> 
> Alex Deucher (6):
>   drm/radeon/kms: more atom parser fixes (v2)
>   drm/radeon/kms/atom: fix dual-link DVI on DCE3.2/4.0
>   drm/radeon/kms/evergreen: don't enable hdmi audio stuff
>   drm/radeon/kms: fix tv dac conflict resolver
>   drm/radeon/kms: adjust pll settings for tv
>   drm/radeon/kms: disable the tv encoder when tv/cv is not in use
> 
> Corbin Simpson (1):
>   drivers/gpu/radeon: Add MSPOS regs to safe list.
> 
> Dave Airlie (1):
>   drm/radeon/kms: only change mode when coherent value changes.
> 
> Jerome Glisse (2):
>   drm/radeon/kms: print GPU family and device id when loading
>   drm/radeon/kms: fix rs600 tlb flush
> 
> Marek Olšák (2):
>   drm/radeon/kms: fix calculation of mipmapped 3D texture sizes
>   drm/radeon/kms: allow R500 regs VAP_ALT_NUM_VERTICES and 
> VAP_INDEX_OFFSET
> 
>  drivers/gpu/drm/radeon/atom.c  |   10 +
>  drivers/gpu/drm/radeon/atombios_crtc.c |4 ++
>  drivers/gpu/drm/radeon/r100.c  |   21 ---
>  drivers/gpu/drm/radeon/r100_track.h|1 +
>  drivers/gpu/drm/radeon/r300.c  |   15 ++--
>  drivers/gpu/drm/radeon/r600_audio.c|2 +-
>  drivers/gpu/drm/radeon/r600_hdmi.c |9 +
>  drivers/gpu/drm/radeon/radeon_connectors.c |   13 ++-
>  drivers/gpu/drm/radeon/radeon_device.c |   53 
> +++-
>  drivers/gpu/drm/radeon/radeon_drv.c|3 +-
>  drivers/gpu/drm/radeon/radeon_encoders.c   |   12 +-
>  drivers/gpu/drm/radeon/radeon_family.h |3 +-
>  drivers/gpu/drm/radeon/reg_srcs/r300   |2 +
>  drivers/gpu/drm/radeon/reg_srcs/r420   |2 +
>  drivers/gpu/drm/radeon/reg_srcs/rs600  |2 +
>  drivers/gpu/drm/radeon/reg_srcs/rv515  |3 ++
>  drivers/gpu/drm/radeon/rs600.c |2 +-
>  17 files changed, 138 insertions(+), 19 deletions(-)___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Linus Torvalds]

On Mon, 7 Jun 2010, Dave Airlie wrote:
> 
> 3 regressions fixes, one radeon loading on IGP, one i865 loading, one and 
> an evergreen userspace interaction workaround.

This is:

 26 files changed, 372 insertions(+), 66 deletions(-)

and there are apparently several reports of known problems (the problem 
with modesetting) that isn't even addressed.

See my -rc2 announcement. I absolutely do NOT want any new code. I want 
regression fixes, fixes for security issues, and fixes for oopses. Nothing 
else. I'm going to be hardassed about this, because quite frankly, if I'm 
not, people will just continue with the same-old, same-old, and send me 
random stuff without thinking hard about it.

So please. Just make me a tree that has regression fixes _only_. I'm not 
AT ALL interested in "it is useful to report the gpu temp". If it was so 
useful, and if it was ready before the merge window, it should hav gone in 
then. That clearly wasn't the case, so it's not going in now either.

Linus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Linus Torvalds]

On Mon, 7 Jun 2010, Al Viro wrote:
> 
> Ho-hum...  Speaking of which, what about leak fixes?  There's a long-standing
> in-core inode leak in jffs2; basically, if you fail directory modification
> in symlink() et.al., you get a leaked inode and whinge at umount.  Found
> after -rc1, had been there since all the way back (similar bug in creat()
> had been fixed in 2003, mkdir()/mknod()/symlink() were not).  Fix sits in
> jffs2-fixes now...

I think a leak that is trivial easily falls under "security issue" as a 
potential DoS issue.

On the other hand, if it's not trivially fixed (say it needs big 
re-organizing of some locking or refcounting or whatever), and it's a 
really slow leak of a pretty small data structure, and is not triggered by 
normal users (say, you need to mount a filesystem or it needs some very 
specific timing), I think it falls under "we haven't seen in the previous 
five years, we might as well make sure the fix is tested in the next merge 
window".

So I think it's a judgement call.

> I can simply pull jffs2-fixes into vfs for-next (I need it in there for
> ->evict_inode() series), but I'd obviously prefer to just rebase it after
> it gets into mainline.

I seem to have a jffs2 pull request that I haven't yet processed, exactly 
because it wasn't clear. It's much bigger than I would have wished for, 
and it's not clear it's all regressions at all.

DavidW? It's

 7 files changed, 107 insertions(+), 91 deletions(-)

and while that's in the size range that I didn't just reject it like the 
drm pull, I still do want to know if that's really just true major 
bugfixes and regressions. We already had a really bad -rc2 release due to 
a tiny and innocent-looking bugfix that turned out to be anything but. I 
do _not_ want to repeat that with -rc3, since I'll be gone.

Linus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Dave Airlie]

On Tue, Jun 8, 2010 at 4:00 AM, Linus Torvalds
 wrote:
>
>
> On Mon, 7 Jun 2010, Dave Airlie wrote:
>>
>> 3 regressions fixes, one radeon loading on IGP, one i865 loading, one and
>> an evergreen userspace interaction workaround.
>
> This is:
>
>         26 files changed, 372 insertions(+), 66 deletions(-)
>
> and there are apparently several reports of known problems (the problem
> with modesetting) that isn't even addressed.

Okay, not sure what the addressed regression you are talking about, do
you want  regression fixes early like you always say or do you want to
wait until I have every regression reported fixes before I send a pull
request?

I'll rebase the tree today (which means it will be tested less than
what I originally sent you, inconsistent messages much?)..

> So please. Just make me a tree that has regression fixes _only_. I'm not
> AT ALL interested in "it is useful to report the gpu temp". If it was so
> useful, and if it was ready before the merge window, it should hav gone in
> then. That clearly wasn't the case, so it's not going in now either.

I really hope you do this, if I find one thing going into your tree
after today that isn't a regression fix I'll send revert patches if
that'll help.

Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Dave Airlie]

On Tue, Jun 8, 2010 at 6:26 AM, Dave Airlie  wrote:
> On Tue, Jun 8, 2010 at 4:00 AM, Linus Torvalds
>  wrote:
>>
>>
>> On Mon, 7 Jun 2010, Dave Airlie wrote:
>>>
>>> 3 regressions fixes, one radeon loading on IGP, one i865 loading, one and
>>> an evergreen userspace interaction workaround.
>>
>> This is:
>>
>>         26 files changed, 372 insertions(+), 66 deletions(-)
>>
>> and there are apparently several reports of known problems (the problem
>> with modesetting) that isn't even addressed.
>
> Okay, not sure what the addressed regression you are talking about, do
> you want  regression fixes early like you always say or do you want to
> wait until I have every regression reported fixes before I send a pull
> request?

Oh the one where I said to the reporter, I've reproduced this, and
will fix it tomorrow when I have proper time and access to my test
machine?

I didn't think writing a fix in the 5 mins before I left the test
machine and sending it you was acceptable, again can you maintain some
semblance of consistency across maintainers/releases?

Like I'm happy if you really enforce this no features idea, I'd be
really happy if you did it every release since it makes it a lot
easier to push back to submaintainers if you can point at Linus not
pulling features from people. However its really hard to push back on
submaintainers and one of the reasons Eric talks to you direct after
rc1, when you can be very inconsistent about what you pull and from
whom. Like I can tell someone this isn't going in this release, then
you'll pull something uglier  from someone else in -rc3 and I end up
looking like stupid because I said there was no hope of getting
anything in. Consistency is something that would make everyone's life
easier, across all releases and all maintainers.

Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Linus Torvalds]

On Tue, 8 Jun 2010, Dave Airlie wrote:

> >         26 files changed, 372 insertions(+), 66 deletions(-)
> >
> > and there are apparently several reports of known problems (the problem
> > with modesetting) that isn't even addressed.
> 
> Okay, not sure what the addressed regression you are talking about, do
> you want  regression fixes early like you always say or do you want to
> wait until I have every regression reported fixes before I send a pull
> request?

I absolutely do want regression fixes early. If they've been verified to 
fix something, I do want to merge them as soon as possible.

But EVEN MORE IMPORTANTLY - and the point of me saying no - I do _not_ 
want non-regression fixes mixed in. Which clearly was the case here. So 
"as soon as possible" does not mean that I'll take _other_ things just to 
get the fix. The regression fix should stand on its own - and be merged 
on its own.

So no, it's not an excuse to send me a tree that contains other crud, and 
then use ".. but but you wanted regression fixes" as the excuse for 
sending those other changes too.

The whole point of the merge window is to then _after_ it closes no longer 
merge new code.

> I really hope you do this, if I find one thing going into your tree
> after today that isn't a regression fix I'll send revert patches if
> that'll help.

I don't like seeing revert patches unless they revert something that is 
buggy.  So no, "revert because I shouldn't have sent that commit" is not a 
good policy. If I end pulling something, it's my bad, and I won't revert 
it just because I made a mistake - it needs to be somehow actually be 
involved in some real problem.

But I _am_ trying to be proactive about problems during this particular 
release cycle. 

The point I'm trying to make is that I am going to be strict about the 
rules (the ones we've had for several years now, but people tend to be a 
bit loose about). I _should_ probably be stricter than I usually am even 
normally, but this time I am going to be very strict for -rc3 due to 
being away for part of the release cycle.

And no, don't worry - it's not just for you. I already rejected a 
microblaze pull for all the same reasons, and asked for some extended 
clarifications for a (much smaller) jffs2 pull despite the fact that we've 
generally not had lots of problems with jffs2.

Linus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Linus Torvalds]

On Tue, 8 Jun 2010, Dave Airlie wrote:
> 
> Oh the one where I said to the reporter, I've reproduced this, and
> will fix it tomorrow when I have proper time and access to my test
> machine?
> 
> I didn't think writing a fix in the 5 mins before I left the test
> machine and sending it you was acceptable, again can you maintain some
> semblance of consistency across maintainers/releases?

No, no. I really didn't imply that you should hurry and not be careful. I 
was just unhappy about the mixing of non-regression fixes with the 
regression fixes.

> Like I'm happy if you really enforce this no features idea, I'd be
> really happy if you did it every release since it makes it a lot
> easier to push back to submaintainers if you can point at Linus not
> pulling features from people.

I already had another person state their happiness with me pushing back, 
and while I had my reasons for doing it this particular release, I do know 
that I've been letting things slide wrt the merge window a bit too much.

So let's see how the 2.6.35 release cycle ends up looking when all is said 
and done. If pushing back harder ends up actually making things easier and 
the release cycle ends up working better as a result, I'm certainly very 
open to just being hardnosed in general.

I suspect it won't even be very painful if people just get used to it. And 
if it ends up really helping sub-maintainers ("I can't do that, because 
Linus wouldn't pull the result anyway"), then that would be a really good 
reason for me to be rather stricter about the rules.

Linus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Linus Torvalds]

On Mon, 7 Jun 2010, David Woodhouse wrote:
> 
> The fix is fairly trivial. There's a "big" patch to fs/jffs2/dir.c which
> accounts for the bulk of my pull request, but if you look harder you'll
> see it's mostly just a bunch of removing 'return ret;' and adding 
> 'goto fail;' so the error cleanup happens properly.

So that's the part I'm worried about.

I'm going to be hardnosed, but I'm _not_ going to so hardnosed as to worry 
about some oneliner DocBook patch. It's not about being anal to quite that 
degree, that would be silly. But the dir.c change is what I end up 
worrying about.

It's not at all clear why it's good to change

jffs2_clear_inode(inode);

into

make_bad_inode(inode);
iput(inode);

and that changelog doesn't really explain it either ("fix leak"? Ok, I can 
see the iput() fixing the leak - but you also did that jffs2_clear_inode() 
change, and that has no explanation what-so-ever.

So is this a safe thing that definitely fixes a serious bug? I am left 
with no good way to judge.

Linus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Linus Torvalds]

On Mon, 7 Jun 2010, Al Viro wrote:

> On Mon, Jun 07, 2010 at 02:17:23PM -0700, Linus Torvalds wrote:
> > jffs2_clear_inode(inode);
> > 
> > into
> > 
> > make_bad_inode(inode);
> > iput(inode);
> > 
> > and that changelog doesn't really explain it either ("fix leak"? Ok, I can 
> > see the iput() fixing the leak - but you also did that jffs2_clear_inode() 
> > change, and that has no explanation what-so-ever.
> 
> The final iput() calls ->clear_inode() (jffs2_clear_inode in case of jffs2)
> and the inode has just been created, with no other in-core references
> existing.  Basically, that call was the only part of (required) iput() that
> _was_ done there ;-)
> 
> FWIW, what's happening around ->clear_inode()/->delete_inode()/->drop_inode()
> is a mess.  This leak got found when I'd been looking through that crap;
> results of sanitizing are in #evict_inode (vfs-2.6.git).  I'm going to shift
> that into for-next tomorrow, assuming it survives local beating.  For now
> I've just pulled jffs2-fixes in it...

Ok, a changelog like that would have been a good thing. Not that I usually 
care, but now that I'm in careful mode, I do end up looking at things like 
this, and a good changelog would have goen m uch further in convincing me 
that the "goto fail" changes really were just about fixing the leak, and 
that there wasn't some other change hidden in the same commit.

Linus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Al Viro]

On Mon, Jun 07, 2010 at 11:53:28AM -0700, Linus Torvalds wrote:
> 
> 
> On Mon, 7 Jun 2010, Al Viro wrote:
> > 
> > Ho-hum...  Speaking of which, what about leak fixes?  There's a 
> > long-standing
> > in-core inode leak in jffs2; basically, if you fail directory modification
> > in symlink() et.al., you get a leaked inode and whinge at umount.  Found
> > after -rc1, had been there since all the way back (similar bug in creat()
> > had been fixed in 2003, mkdir()/mknod()/symlink() were not).  Fix sits in
> > jffs2-fixes now...
> 
> I think a leak that is trivial easily falls under "security issue" as a 
> potential DoS issue.
> 
> On the other hand, if it's not trivially fixed (say it needs big 
> re-organizing of some locking or refcounting or whatever), and it's a 
> really slow leak of a pretty small data structure, and is not triggered by 
> normal users (say, you need to mount a filesystem or it needs some very 
> specific timing), I think it falls under "we haven't seen in the previous 
> five years, we might as well make sure the fix is tested in the next merge 
> window".

You need something like IO errors or device being full to trigger it.
As for the fix, it's basically a matter of "set i_nlink to 0 and iput()
instead of manual jffs2_clear_inode(); sure, you want to kill the on-disk
inode, but you want in-core one gone too".

Basically, that's what all local filesystems are doing to clean up after
such error and that's what jffs2 is doing for ->create().

As for the other stuff in that tree...  There's a fix for nfsd/create race
(rather narrow and not trivial to hit, but capable of fs corruption) and
there's mtd stuff I've no fscking clue about.

If not for the mtd part I'd simply pulled it in my tree.  As it is...  I
still can do that (done that for current semi-private branch), but I'd
prefer to avoid feeding mtd stuff through vfs tree, for all the obvious
reasons.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Al Viro]

On Mon, Jun 07, 2010 at 11:00:51AM -0700, Linus Torvalds wrote:
> So please. Just make me a tree that has regression fixes _only_. I'm not 
> AT ALL interested in "it is useful to report the gpu temp". If it was so 
> useful, and if it was ready before the merge window, it should hav gone in 
> then. That clearly wasn't the case, so it's not going in now either.

Ho-hum...  Speaking of which, what about leak fixes?  There's a long-standing
in-core inode leak in jffs2; basically, if you fail directory modification
in symlink() et.al., you get a leaked inode and whinge at umount.  Found
after -rc1, had been there since all the way back (similar bug in creat()
had been fixed in 2003, mkdir()/mknod()/symlink() were not).  Fix sits in
jffs2-fixes now...

I can simply pull jffs2-fixes into vfs for-next (I need it in there for
->evict_inode() series), but I'd obviously prefer to just rebase it after
it gets into mainline.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[David Woodhouse]

On Mon, 2010-06-07 at 11:53 -0700, Linus Torvalds wrote:
> 
> On Mon, 7 Jun 2010, Al Viro wrote:
> > 
> > Ho-hum...  Speaking of which, what about leak fixes?  There's a 
> > long-standing
> > in-core inode leak in jffs2; basically, if you fail directory modification
> > in symlink() et.al., you get a leaked inode and whinge at umount.  Found
> > after -rc1, had been there since all the way back (similar bug in creat()
> > had been fixed in 2003, mkdir()/mknod()/symlink() were not).  Fix sits in
> > jffs2-fixes now...
> 
> I think a leak that is trivial easily falls under "security issue" as a 
> potential DoS issue.
>
> On the other hand, if it's not trivially fixed (say it needs big 
> re-organizing of some locking or refcounting or whatever), and it's a 
> really slow leak of a pretty small data structure, and is not triggered by 
> normal users (say, you need to mount a filesystem or it needs some very 
> specific timing), I think it falls under "we haven't seen in the previous 
> five years, we might as well make sure the fix is tested in the next merge 
> window".
> 
> So I think it's a judgement call.

The fix is fairly trivial. There's a "big" patch to fs/jffs2/dir.c which
accounts for the bulk of my pull request, but if you look harder you'll
see it's mostly just a bunch of removing 'return ret;' and adding 
'goto fail;' so the error cleanup happens properly.

Al pointed out a second problem at the same time, fixed by commit
e72e6497 in the tree I asked you to pull. That involved adding an
unlock_new_inode() to the same error paths that the first patch used.

Between the two bugs, I figured it was worth pushing the fixes for
2.6.35.

The third jffs2 patch in that tree is a fix for ctime semantics which is
a two-liner. Again not a regression but worth fixing, and -stable
fodder.

Al also pointed out that I could use iget_failed(), but I figured that
cleanup could wait for 2.6.36.

> I seem to have a jffs2 pull request that I haven't yet processed, exactly 
> because it wasn't clear. It's much bigger than I would have wished for, 
> and it's not clear it's all regressions at all.
> 
> DavidW? It's
> 
>7 files changed, 107 insertions(+), 91 deletions(-)
> 
> and while that's in the size range that I didn't just reject it like the 
> drm pull, I still do want to know if that's really just true major 
> bugfixes and regressions.

 Documentation/DocBook/mtdnand.tmpl |2 +-
 drivers/mtd/mtdchar.c  |   11 +--
 drivers/mtd/nand/Kconfig   |   21 +++---
 drivers/mtd/nand/r852.c|   27 +---
 fs/jffs2/acl.c |3 +-
 fs/jffs2/dir.c |  127 +++-
 fs/jffs2/fs.c  |7 ++-
 7 files changed, 107 insertions(+), 91 deletions(-)

The patches to r852 are fixing the fact that suspend/resume wasn't
working. Not strictly a regression, as it's a new driver in 2.6.35 --
but I judged that it was best to fix it.

The Kconfig patch fixes a problem with the menu nesting, introduced with
the SmartMedia support. That one is a regression.

I'll concede that I could probably have lived without the DocBook patch,
and the patch to use memdup_user() in mtdchar.c, but they're so trivial
that it seemed pointless rebasing the tree to exclude them once I
concluded I should to try my luck at getting the other stuff into -rc2.

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Al Viro]

On Mon, Jun 07, 2010 at 08:32:45PM +0100, David Woodhouse wrote:
> The fix is fairly trivial. There's a "big" patch to fs/jffs2/dir.c which
> accounts for the bulk of my pull request, but if you look harder you'll
> see it's mostly just a bunch of removing 'return ret;' and adding 
> 'goto fail;' so the error cleanup happens properly.
> 
> Al pointed out a second problem at the same time, fixed by commit
> e72e6497 in the tree I asked you to pull. That involved adding an
> unlock_new_inode() to the same error paths that the first patch used.
> 
> Between the two bugs, I figured it was worth pushing the fixes for
> 2.6.35.
> 
> The third jffs2 patch in that tree is a fix for ctime semantics which is
> a two-liner. Again not a regression but worth fixing, and -stable
> fodder.
> 
> Al also pointed out that I could use iget_failed(), but I figured that
> cleanup could wait for 2.6.36.

BTW, if you put jffs2 stuff into a separate queue, I can just pull it
(and add iget_failed() conversion on top of that).  Not a problem...
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Al Viro]

On Mon, Jun 07, 2010 at 02:17:23PM -0700, Linus Torvalds wrote:
>   jffs2_clear_inode(inode);
> 
> into
> 
>   make_bad_inode(inode);
>   iput(inode);
> 
> and that changelog doesn't really explain it either ("fix leak"? Ok, I can 
> see the iput() fixing the leak - but you also did that jffs2_clear_inode() 
> change, and that has no explanation what-so-ever.

The final iput() calls ->clear_inode() (jffs2_clear_inode in case of jffs2)
and the inode has just been created, with no other in-core references
existing.  Basically, that call was the only part of (required) iput() that
_was_ done there ;-)

FWIW, what's happening around ->clear_inode()/->delete_inode()/->drop_inode()
is a mess.  This leak got found when I'd been looking through that crap;
results of sanitizing are in #evict_inode (vfs-2.6.git).  I'm going to shift
that into for-next tomorrow, assuming it survives local beating.  For now
I've just pulled jffs2-fixes in it...
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[David Woodhouse]

On Mon, 2010-06-07 at 14:17 -0700, Linus Torvalds wrote:
> and that changelog doesn't really explain it either ("fix leak"? Ok, I can 
> see the iput() fixing the leak - but you also did that jffs2_clear_inode() 
> change, and that has no explanation what-so-ever.

jffs2_clear_inode() is the file system's ->clear_inode method, so it
gets called from the VFS when the inode is destroyed, after iput().

I suppose that ought to have been a clue, right from the very beginning,
that we should never have been calling it directly on our error paths.

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Al Viro]

On Mon, Jun 07, 2010 at 10:39:28PM +0100, David Woodhouse wrote:
> On Mon, 2010-06-07 at 14:17 -0700, Linus Torvalds wrote:
> > and that changelog doesn't really explain it either ("fix leak"? Ok, I can 
> > see the iput() fixing the leak - but you also did that jffs2_clear_inode() 
> > change, and that has no explanation what-so-ever.
> 
> jffs2_clear_inode() is the file system's ->clear_inode method, so it
> gets called from the VFS when the inode is destroyed, after iput().
> 
> I suppose that ought to have been a clue, right from the very beginning,
> that we should never have been calling it directly on our error paths.

Yep.  The other place that directly called its ->clear_inode() also had
been bogus, BTW - logfs had been playing rather sick games with special
inodes and ended up open-coding just about everything on new_inode/iput
paths for those.  They needed that stuff evicted after all normal inodes,
but before the second call of invalidate_inodes() would scream about
surviving busy inodes.  I.e. that should've been happening in ->put_super();
no need to deal with handcrafted inodes that would sit outside of inode
list...
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Dave Airlie]

Ignore this one, picked up a problem in the ioports patch, so its gone.

new pull req sent.

Dave.

> 
> The following changes since commit 123f94f22e3d283dfe68742b269c245b0501ad82:
> 
>   Merge branch 'sched-fixes-for-linus' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip (2010-07-02 
> 09:52:58 -0700)
> 
> are available in the git repository at:
> 
>   ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git 
> drm-fixes
> 
> Alex Deucher (2):
>   drm/radeon/kms: add ioport register access
>   drm/radeon/kms: fix shared ddc handling
> 
> Francisco Jerez (1):
>   drm/ttm: Allocate the page pool manager in the heap.
> 
> Jesse Barnes (1):
>   drm: correctly update connector DPMS status in drm_fb_helper
> 
>  drivers/gpu/drm/drm_fb_helper.c|   23 -
>  drivers/gpu/drm/radeon/atom.c  |5 +-
>  drivers/gpu/drm/radeon/atom.h  |2 +
>  drivers/gpu/drm/radeon/radeon.h|   25 ++
>  drivers/gpu/drm/radeon/radeon_connectors.c |4 +-
>  drivers/gpu/drm/radeon/radeon_device.c |   34 ++
>  drivers/gpu/drm/ttm/ttm_page_alloc.c   |   68 +--
>  include/drm/ttm/ttm_page_alloc.h   |4 --
>  8 files changed, 119 insertions(+), 46 deletions(-)
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Dave Airlie]

> Hi Linus,
> 
> We had an unplanned leak/race finding week:

Updated pull request, TTM extra fix, GEM updated patch with tested by 
lines, and some urgent vmwgfx oops/fixes. (vmwgfx is in staging still, 
though I need to discuss that with vmware).

Dave.


> Had a pretty nasty race in TTM reported (scrolling certain pages in 
> firefox caused a major leak of objects), fix from Thomas in here.
> 
> A nasty slow leak in the i915 GEM code, fix from Chris here.
> A race on object deletion in the GEM code, fix from Chris.
> 
> A leak/memory corruptor when unloading drm modules after X had started due 
> to using krefs in a non-kref compatible manner, fix from me (found while 
> tracking down the firefox one).
> 
> Apart from that, just some general radeon fixes, a BKL regression fix, a 
> vmware regression fix from the ioctl cleanups.
> 
The following changes since commit 32163f4b2cef28a5aab8b226ffecfc6379a53786:

  alpha: fix usp value in multithreaded coredumps (2010-09-25 14:38:13 -0700)

are available in the git repository at:
  ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-fixes

Alex Deucher (3):
  drm/radeon/kms: fix up encoder info messages for DFP6
  drm/radeon/kms: fix potential segfault in r600_ioctl_wait_idle
  drm/radeon/kms: add quirk for MSI K9A2GM motherboard

Arnd Bergmann (1):
  drm: i810/i830: fix locked ioctl variant

Chris Wilson (2):
  drm: Prune GEM vma entries
  drm: Hold the mutex when dropping the last GEM reference (v2)

Dave Airlie (2):
  drm/radeon: fix PCI ID 5657 to be an RV410
  drm/gem: handlecount isn't really a kref so don't make it one.

Thomas Hellstrom (7):
  drm/ttm: Fix two race conditions
  drm/vmwgfx: Fix breakage introduced by commit "drm: block userspace under 
allocating buffer and having drivers overwrite it (v2)"
  drm/ttm: Fix missing return
  vmwgfx: vt-switch (master drop) fixes
  vmwgfx: Enable use of the vblank system
  vmwgfx: Remove initialisation of dev::devname
  vmwgfx: Fix fb VRAM pinning failure due to fragmentation

 drivers/gpu/drm/drm_gem.c  |   39 ++--
 drivers/gpu/drm/drm_info.c |2 +-
 drivers/gpu/drm/drm_vm.c   |   28 --
 drivers/gpu/drm/i810/i810_dma.c|2 +-
 drivers/gpu/drm/i830/i830_dma.c|2 +-
 drivers/gpu/drm/i915/i915_gem.c|6 +-
 drivers/gpu/drm/i915/intel_fb.c|4 +-
 drivers/gpu/drm/nouveau/nouveau_fbcon.c|1 +
 drivers/gpu/drm/nouveau/nouveau_gem.c  |6 +-
 drivers/gpu/drm/nouveau/nouveau_notifier.c |1 +
 drivers/gpu/drm/radeon/r600.c  |3 +-
 drivers/gpu/drm/radeon/radeon_atombios.c   |9 ++
 drivers/gpu/drm/radeon/radeon_display.c|5 +-
 drivers/gpu/drm/radeon/radeon_fb.c |   14 +--
 drivers/gpu/drm/radeon/radeon_gem.c|4 +-
 drivers/gpu/drm/ttm/ttm_bo.c   |   75 --
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c|  145 +---
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h|8 ++
 drivers/gpu/drm/vmwgfx/vmwgfx_fb.c |5 +
 drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c   |3 +
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c|   17 
 drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c|   27 --
 drivers/gpu/drm/vmwgfx/vmwgfx_resource.c   |4 +
 include/drm/drmP.h |   29 --
 include/drm/drm_pciids.h   |2 +-
 include/drm/ttm/ttm_bo_api.h   |4 +-
 26 files changed, 313 insertions(+), 132 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Dave Airlie]

> > 
> > We had an unplanned leak/race finding week:
> 
> Updated pull request, TTM extra fix, GEM updated patch with tested by 
> lines, and some urgent vmwgfx oops/fixes. (vmwgfx is in staging still, 
> though I need to discuss that with vmware).

Today is proof the phenylephrine is a poor substitute for pseudoephedrine, 
and both are a poor substitute for sleep.

I've dropped the TTM fixes until next week since Thomas keeps finding 
corner-case issues and I'd like to get to my test box in the office and 
confirm, we know the patch fixes a major leak, just a matter of having 
more confidence in it working in the corners.

Lets get the simpler patches I'm sure about in and I'll send the ttm leak 
fix on its own next week.

Dave.

The following changes since commit 32163f4b2cef28a5aab8b226ffecfc6379a53786:

  alpha: fix usp value in multithreaded coredumps (2010-09-25 14:38:13 -0700)

are available in the git repository at:
  ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-fixes

Alex Deucher (3):
  drm/radeon/kms: fix up encoder info messages for DFP6
  drm/radeon/kms: fix potential segfault in r600_ioctl_wait_idle
  drm/radeon/kms: add quirk for MSI K9A2GM motherboard

Arnd Bergmann (1):
  drm: i810/i830: fix locked ioctl variant

Chris Wilson (2):
  drm: Prune GEM vma entries
  drm: Hold the mutex when dropping the last GEM reference (v2)

Dave Airlie (2):
  drm/radeon: fix PCI ID 5657 to be an RV410
  drm/gem: handlecount isn't really a kref so don't make it one.

Thomas Hellstrom (5):
  drm/vmwgfx: Fix breakage introduced by commit "drm: block userspace under 
allocating buffer and having drivers overwrite it (v2)"
  vmwgfx: vt-switch (master drop) fixes
  vmwgfx: Enable use of the vblank system
  vmwgfx: Remove initialisation of dev::devname
  vmwgfx: Fix fb VRAM pinning failure due to fragmentation

 drivers/gpu/drm/drm_gem.c  |   39 ++--
 drivers/gpu/drm/drm_info.c |2 +-
 drivers/gpu/drm/drm_vm.c   |   28 --
 drivers/gpu/drm/i810/i810_dma.c|2 +-
 drivers/gpu/drm/i830/i830_dma.c|2 +-
 drivers/gpu/drm/i915/i915_gem.c|6 +-
 drivers/gpu/drm/i915/intel_fb.c|4 +-
 drivers/gpu/drm/nouveau/nouveau_fbcon.c|1 +
 drivers/gpu/drm/nouveau/nouveau_gem.c  |6 +-
 drivers/gpu/drm/nouveau/nouveau_notifier.c |1 +
 drivers/gpu/drm/radeon/r600.c  |3 +-
 drivers/gpu/drm/radeon/radeon_atombios.c   |9 ++
 drivers/gpu/drm/radeon/radeon_display.c|5 +-
 drivers/gpu/drm/radeon/radeon_fb.c |   14 +--
 drivers/gpu/drm/radeon/radeon_gem.c|4 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c|  145 +---
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h|8 ++
 drivers/gpu/drm/vmwgfx/vmwgfx_fb.c |5 +
 drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c   |3 +
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c|   17 
 drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c|   27 --
 drivers/gpu/drm/vmwgfx/vmwgfx_resource.c   |4 +
 include/drm/drmP.h |   29 --
 include/drm/drm_pciids.h   |2 +-
 24 files changed, 246 insertions(+), 120 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Dave Airlie]

Slight update to fix a regression in one of the memory corruption fixes, 
we have another memory corruption myself/Keith are trying to track down, 
but laptops with 1.8" disks are defeating us, but its only in a rare 
unload case and may have been around for a while so it can probably live 
in -next and go in via stable.

The following changes since commit e1d9694cae722d00a94fb58f901aa69c9c324a16:

  Merge branch 'core-fixes-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip (2010-10-05 
13:07:43 -0700)

are available in the git repository at:

  ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-fixes

Dave Airlie (1):
  drm: don't drop handle reference on unload

Thomas Hellstrom (1):
  drm/ttm: Fix two race conditions + fix busy codepaths

 drivers/gpu/drm/i915/intel_fb.c|2 +-
 drivers/gpu/drm/nouveau/nouveau_fbcon.c|1 -
 drivers/gpu/drm/nouveau/nouveau_notifier.c |1 -
 drivers/gpu/drm/radeon/radeon_fb.c |1 -
 drivers/gpu/drm/ttm/ttm_bo.c   |   83 
 include/drm/ttm/ttm_bo_api.h   |4 +-
 6 files changed, 75 insertions(+), 17 deletions(-)

 > 
> This is the nasty race condition fix from Thomas, I've been running it and 
> playing with firefox a lot and haven't seen any side effects of it, we 
> have positive feedback on it fixing the actual problem of up 1GB of memory 
> leaked in 5-10s of scrolling in the pathalogical cases.
> 
> Dave.
> 
> The following changes since commit e1d9694cae722d00a94fb58f901aa69c9c324a16:
> 
>   Merge branch 'core-fixes-for-linus' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip (2010-10-05 
> 13:07:43 -0700)
> 
> are available in the git repository at:
> 
>   ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git 
> drm-fixes
> 
> Thomas Hellstrom (1):
>   drm/ttm: Fix two race conditions + fix busy codepaths
> 
>  drivers/gpu/drm/ttm/ttm_bo.c |   83 
> --
>  include/drm/ttm/ttm_bo_api.h |4 ++-
>  2 files changed, 74 insertions(+), 13 deletions(-)
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Linus Torvalds]

On Wed, Nov 10, 2010 at 4:24 PM, Dave Airlie  wrote:
>
> I've started taking Chris's pull requests now, so all the intel drm
> changes should start coming via my tree always now, unless they are pretty
> exceptional or I'm away.

Btw, Chris - don't do this:

  commit 08deebf98783d3de553eed2c9b6b8dcc7e168567
  Author: Chris Wilson 
  Date:   Fri Nov 5 08:56:38 2010 +

drm/i915/ringbuffer: Use the HEAD auto-reporting mechanism

My Sandybridge only reports 0 for the ring buffer registers, causing it
to hang as soon as we exhaust the available ring. As a workaround, take
advantage of our huge ring buffers and use the auto-reporting mechanism
to update the status page with the HEAD location every 64 KiB.

Cherry-picked from 6aa56062eaba67adfb247cded244fd877329588d.

...

Think about what that "Cherry-picked from 6aa56062eaba.." means for a while.

It's a totally random number that is entirely pointless. That commit
doesn't exist in any trees anybody else is aware of, so it's pure and
utter noise. It has no meaning.

The only SHA1 numbers that are meaningful are numbers that are in some
history that is relevant. So a SHA1 should normally only ever point to
a commit that exists in the history of the commit that it points to
(think reverts, or "this fixes an issue introduced in xyz"). So if you
see that commit description, you're pretty much guaranteed that the
SHA1 makes sense.

The one exception is when you point to some "known external tree" - ie
the stable tree has references to the commits in the upstream kernel,
even though they are obviously not in the history of the stable commit
itself. The numbers may not make sense within the confines of just the
stable tree at the time, but at the same time, the stable tree rules
are very much that commits only get in once they are in mainline, so
there are actual rules in place basically saying that the hash makes
sense even _if_ it refers to an outside tree.

But when you cherry-pick it from some random internal tree that nobody
will necessarily ever see, and that you don't even describe what it
is, it's only pure confusion. I do

  [torva...@i5 linux]$ git show 6aa56062eaba67adfb247cded244fd877329588d
  fatal: bad object 6aa56062eaba67adfb247cded244fd877329588d

and so will everybody else. So from a documentation standpoint, you're
actually adding negative information. Please don't.

 Linus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Chris Wilson]

On Fri, 12 Nov 2010 08:24:48 -0800, Linus Torvalds 
 wrote:
> But when you cherry-pick it from some random internal tree that nobody
> will necessarily ever see, and that you don't even describe what it
> is, it's only pure confusion. I do
> 
>   [torva...@i5 linux]$ git show 6aa56062eaba67adfb247cded244fd877329588d
>   fatal: bad object 6aa56062eaba67adfb247cded244fd877329588d
> 
> and so will everybody else. So from a documentation standpoint, you're
> actually adding negative information. Please don't.

My bad, I cherry-picked it from our public drm-intel-next tree and thought
it wise to include the cross-reference to explain the duplication and
merge conflicts and to provide some additional test history into the commit.
Obviously not enough information.

Is there a right approach here? I'm trying to be strict in that what is
sent upstream in -fixes are purely known regression fixes, and to preserve
test history on both -fixes and -next. That leads to situations like the
above where we have a commit that does not appear to relevant to stable at
first, but then is later shown to be required. How best to resolve the
eventual conflict that will show up in your tree? Just cherry-pick and be
dammed?
-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 fixes

[Linus Torvalds]

On Fri, Nov 12, 2010 at 9:21 AM, Chris Wilson  wrote:
>
> My bad, I cherry-picked it from our public drm-intel-next tree and thought
> it wise to include the cross-reference to explain the duplication and
> merge conflicts and to provide some additional test history into the commit.
> Obviously not enough information.
>
> Is there a right approach here? I'm trying to be strict in that what is
> sent upstream in -fixes are purely known regression fixes, and to preserve
> test history on both -fixes and -next. That leads to situations like the
> above where we have a commit that does not appear to relevant to stable at
> first, but then is later shown to be required. How best to resolve the
> eventual conflict that will show up in your tree? Just cherry-pick and be
> dammed?

Generally "just cherry-pick and be damned". Duplicate patches happen
all the time, and it has nothing to do with cherry-picking: the same
patch gets done by two different people (or just forwarded to two
different maintainers). So duplication isn't problematic per se.

And if it happens so much that it then causes real problems elsewhere
(for example lots of merge conflicts due to other related changes
around it), that's indicative of something _else_ going on.

Maybe it's just a lack of good topic branches, so that you mix
everything up in one place, and get conflicts due to that. With well
chosen topic branches, you do fixes in one particular branch that can
be merged into both -next and -stable. But then you really have to do
topic branches based on _topic_, not just "this is a random collection
of -stable crap". Name the branch by the actual problem it fixes, and
do NOT merge it into either -next _nor_ -stable until that particular
problem has really been fixed and you're sure (otherwise you'll just
end up with lots of daily merges of random fixes, and that will be
_worse_. You may avoid the merge conflicts, but your history will look
like sh*t, and your topic branches will be meaningless).

Or you have two people who work in the same area, and your code is
just not modular enough, so when they work on the same file, they
invariably step on each others fingers. Functions too big, actions not
clearly enough abstracted out, people just adding things to the same
area even when they work on two different chips (the intel DRM code
tends to be _full_ of "common" functions that then test individual
chip ID's and do different things. Dammit, if they do that, they
aren't common functions, and you write them the wrong way around:
instead of having "common function testing if ID==sandybridge", you
should have "sandybridge function doing its thing and calling _truly_
common helper functions that do things that other chip functions will
need too")

Merge conflicts (of anything but the totally trivial kind) are almost
always a sign of something being wrong in the development.  Trivial
merge conflicts (and merges that had the same patch and got resolved
totally automatically - they were so trivial that a human never even
saw it) are normal. But if it's at the point that it causes pain,
there is some more fundamental problem, and marking commits as "this
is the same as in that other branch" is not the solution.

   Linus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Chris Wilson]

Hi Dave and Linus,

with travel I was a bit late in getting this pull request sent. It
contains a fix for Linus' machine, an i2c initialisation failure and a fix
from Keith to stop VGA flashing during polling on recent hardware. As well
as a patch that should hopefully prevent all of our indefinite GPU waits
on mode setting.

Note it also contains a couple of fluff fallout patches from the recent
drm-fixes rebase. (I thought it would be wise to include any core drm
changes in our testing before sending the request...)
-Chris

The following changes since commit 164bcb94bc821fcbac752e809b4ac7c6f15d13b5:

  drm/radeon/kms: i2c s/sprintf/snprintf/g for safety (2010-11-19 09:27:48 
+1000)

are available in the git repository at:
  git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel.git 
drm-intel-fixes

Alex Deucher (1):
  drm/radeon/kms: fix and unify tiled buffer alignment checking for r6xx/7xx

Alex Shi (1):
  drm/i915: Disable FBC on Ironlake to save 1W

Chris Wilson (4):
  drm/i915: Retire any pending operations on the old scanout when switching
  Merge remote branch 'airlied/drm-fixes' into drm-intel-fixes
  drm/i915: Do not hold mutex when faulting in user addresses
  drm/i915/crt: Introduce struct intel_crt

Jean Delvare (1):
  drm/i915: Fix I2C adapter registration

Keith Packard (1):
  drm/i915: Take advantage of auto-polling CRT hotplug detection on PCH 
hardware

Vasiliy Kulikov (1):
  drm: radeon: fix error value sign

 drivers/gpu/drm/i915/i915_drv.c  |3 +-
 drivers/gpu/drm/i915/i915_drv.h  |2 +
 drivers/gpu/drm/i915/i915_gem.c  |   77 +
 drivers/gpu/drm/i915/intel_crt.c |  159 ++---
 drivers/gpu/drm/i915/intel_display.c |   12 ++
 drivers/gpu/drm/i915/intel_i2c.c |   11 +-
 drivers/gpu/drm/radeon/r600_cs.c |  309 +-
 drivers/gpu/drm/radeon/r600d.h   |6 +
 drivers/gpu/drm/radeon/radeon_irq.c  |4 +-
 9 files changed, 358 insertions(+), 225 deletions(-)

-- 
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 fixes

[Linus Torvalds]

On Fri, Nov 19, 2010 at 2:02 AM, Chris Wilson  wrote:
>
> Note it also contains a couple of fluff fallout patches from the recent
> drm-fixes rebase. (I thought it would be wise to include any core drm
> changes in our testing before sending the request...)

F*%^ me, why does drm always have to be so messy?

You guys pull each others trees, and then rebase them. Yes, git is
smart enough that it will merge it all fine, but dammit, now that
multi-hundred-line Radeon commit exists twice in the tree. Do this:

   git show --stat 16790569eddf fba4312e223f
   git show --stat 21e2eae4daae a41c73e04673

and cry.

And yeah, it's ugly. And if that patch introduces a regression (which
is entirely possible, it's not like it's small and trivial and
obviously correct) it will just make bisection harder, and add
confusion.  And it's totally pointless. It only adds pain. And it
makes the history harder to read.

Why did the Intel drm tree merge a patch that had _nothing_
what-so-ever to do with Intel DRM? WHY?

And why did the drm tree rebase a tree that had obviously been public
and pulled from? WHY? Why did you make it public before it was ready?
And/or why was it so ugly that it needed to rebase it? Why do these
things keep happening?

What's wrong with the whole drm crowd? Even if it isn't rebasing, why
is drivers/gpu/drm always so very visible in the later -rc trees?

I'm asking "why", but what I really want you guys to do is to ask
_yourself_ why. And ask "Why is that? What am I doing wrong that this
keeps happening?"

Really. Spend some time pondering. What the hell just happened, and
why did it happen, and how can you guys stop doing it?

Chris: stop pulling in random crap in your tree. Do _your_ development
in your tree. Nothing else.

And Dave, I have no idea why those two commits were rebased. They seem
identical in the tree that Chris had pulled. They have the same base
commit. What was the point?

 Linus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Dave Airlie]

On Sat, Nov 20, 2010 at 5:04 AM, Linus Torvalds
 wrote:
> On Fri, Nov 19, 2010 at 2:02 AM, Chris Wilson  
> wrote:
>>
>> Note it also contains a couple of fluff fallout patches from the recent
>> drm-fixes rebase. (I thought it would be wise to include any core drm
>> changes in our testing before sending the request...)
>
> F*%^ me, why does drm always have to be so messy?

please just reject Chris's pull, I've asked he don't send you pulls
directly, and he seems to have missed the memo in this case, if he'd
sent this to me I'd have pushed back.

the reason the tree got rebased is that i did a pull from Ben and I
screwed up, I didn't check his history and he'd based his tree on a
branch for -next not for you, and some commits
in there were also strangely renumbered, so I pushed back when I
noticed (which was after I pushed out drm-fixes). I should have
noticed before I pushed it out but I didn't mea-culpa.

I'll talk to Chris about where he bases his trees, generally I ask
they based their trees on your tree or the last thing I sent you,
unless we have some conflicting reasons which after -rc1 should never
be the case.

> And yeah, it's ugly. And if that patch introduces a regression (which
> is entirely possible, it's not like it's small and trivial and
> obviously correct) it will just make bisection harder, and add
> confusion.  And it's totally pointless. It only adds pain. And it
> makes the history harder to read.
>
> Why did the Intel drm tree merge a patch that had _nothing_
> what-so-ever to do with Intel DRM? WHY?
>
> And why did the drm tree rebase a tree that had obviously been public
> and pulled from? WHY? Why did you make it public before it was ready?
> And/or why was it so ugly that it needed to rebase it? Why do these
> things keep happening?

I can't remember the last time we had a crazy rebase situation in the drm,
so its been a relatively while. I would have thought pushing a tree
with reverts would have made for uglier history than you just refusing
Chris's tree,
and letting me deal with it in time.

>
> What's wrong with the whole drm crowd? Even if it isn't rebasing, why
> is drivers/gpu/drm always so very visible in the later -rc trees?
>
> I'm asking "why", but what I really want you guys to do is to ask
> _yourself_ why. And ask "Why is that? What am I doing wrong that this
> keeps happening?"
>
> Really. Spend some time pondering. What the hell just happened, and
> why did it happen, and how can you guys stop doing it?
>
> Chris: stop pulling in random crap in your tree. Do _your_ development
> in your tree. Nothing else.
>
> And Dave, I have no idea why those two commits were rebased. They seem
> identical in the tree that Chris had pulled. They have the same base
> commit. What was the point?

Yeah I screwed up there, after I screwed up Ben's pull I nuked everything and
rebuilt, I should have just gone back before Ben's commit and left
those two commits intact.

As for why drm ends up with a lot of churn after rc1?

radeon 90,000 LOC (417 devices in pci table - not to mention variants
in set of encoder/connectors BIOS tables per card)
nouveau 45,148 LOC (can't tell how many devices).
intel 41,651 LOC (32 pciids, but also variants in connectors is massive)

these are just the drivers, I don't think a 1000 line modified set of
changes across 200,000 lines of code
is major, especially as its not in the core DRM, I'm guessing that
wireless is probably the only other driver
base in the same region of LOC per driver.

Like maybe we need more testing for code pre -rc1 but I think we just
end up with the same problem as when people tell you to merge less, it
just gets stacked up for the next window. People test stuff on the
hardware they have, its not really until it hits your tree or even
distros that we find it doesn't work on some other variant of the
hardware. We've had bugs in laptops with identical names and chipsets,
but slightly different panels, also people plug a wide range of
monitors into graphics cards, you'd think again these would be
standard but a small change in the EDID parser may break some monitor
or HDMI tv that has a 5c rom in it with 90% garbage. Generally merging
stuff in -rc1 means we have to fix it after that point, testing the
fixes don't regress anything is just as much pain as testing the code
in the first place.

Though I've been asking myself the same question lately why we have so
much change, it was one of the reasons I asked Chris to starting
sending things via me so I could get more visibility into what is
changing after rc1, for radeon I've been asking Alex about each fix as
it goes past and I'm generally happy they fix problems people are
actually seeing, and Chris seems to be showing a lot more constraint
than Eric used to. nouveau I'm not as pushed to constrain but I do
generally pushed back on Ben to rework stuff where it a big change
doesn't make sense.

I also wonder if its partly psychological on your part, if I sent a
number of smaller pull

Re: [git pull] drm fixes

[Linus Torvalds]

On Fri, Nov 19, 2010 at 12:24 PM, Dave Airlie  wrote:
>
> I also wonder if its partly psychological on your part, if I sent a
> number of smaller pull requests rather than queuing up things would
> you notice the line count less? If Chris sends things direct to you
> instead of me merging them and sending do you see a combined drm line
> count or do you just notice on a pull by pull basis etc.

Yes. I _love_ getting lots of separate pull requests if the subsystem
is big and the line counts start to grow.

But that only works if the separate pull requests are clearly separate
development threads. So it's not a matter of "send the pull requests
more often just make them smaller", but rather a matter of "send five
pull requests of different topic branches that are clearly separate".

I used to rave and rant at Ingo's x86 -tip tree, because I got huge
pull requests that were unmanageable. These days I don't, because I
instead get about thirty pull requests of individual topic branches,
and they don't depend on each other (well, at least most of the time)
so I can pull them in pretty much any order, and I know they've been
individually tested and each do one set of clear improvements.

And for the last year or so, not only don't I need to rant at the x86
people, it's been one of the most pleasant trees to work with.

Btw, it did end up forcing Ingo and company to change how they worked.
And it wasn't an entirely smooth transition, and it took three or four
release cycles of unpleasantness before it really started working. But
I'm pretty sure that if you ask Ingo and Thomas, they'll tell you that
it improved their flow too - it wasn't just a "make Linus happy"
thing, it's actually working really well and helped development.

And part of that is that it does require a bit of care. The patches go
into individual branches, and that's obviously more work and
forethought than just having a single "drm" branch. But then the
_advantage_ is that when things go wrong, they also go wrong in just
one small branch.  And the x86 -tip people can ask people to test just
specific branches.

And yes, it makes me much less unhappy about large pulls. The
cumulative patch may still be big, but if I get it in clearly separate
chunks, it ends up looking much cleaner and organized, so I get much
less worried.

But notice: I tend to really love that all during the *merge window*.
Post-merge-window, I'd still prefer to get clearly separate pull
requests, but at that point I really do want them to be _small_. If
they're not small at that point, there's still something wrong.

> Like I know the goal here is to create the perfect kernel for hardware
> Linus owns, but I'd like to be able to fix bugs urgently on hardware
> users have that aren't so privileged, think of it as some sort of
> outreach program.

Well, the complaint is at least partly about how it seems to be rather
much more unstable than some other (bigger) subsystems during later
-rc stages.

For example, comparing drivers/net with drivers/gpu, we find that
drivers/net has had a _lot_ more changes in this release:

  [torva...@i5 linux]$ git diff -M --stat v2.6.36.. drivers/net/ | tail -1
   838 files changed, 92549 insertions(+), 39111 deletions(-)
  [torva...@i5 linux]$ git diff -M --stat v2.6.36.. drivers/gpu/ | tail -1
   221 files changed, 19388 insertions(+), 11154 deletions(-)

so we're talking about a 4x difference here. Yet, when looking at what
happened since the merge window closed, it looks very different:

  [torva...@i5 linux]$ git diff -M --stat v2.6.37-rc1.. drivers/net/ | tail -1
   54 files changed, 455 insertions(+), 238 deletions(-)
  [torva...@i5 linux]$ git diff -M --stat v2.6.37-rc1.. drivers/gpu | tail -1
   87 files changed, 1667 insertions(+), 799 deletions(-)

now drivers/gpu (that had only a quarter of the changes overall) is
almost exactly the other way around.

Now, I realize that network drivers are simpler, and I'm sure there
are always good reasons. But still. I just get the strong feeling that
drivers/gpu isn't as well controlled, and that it's not following the
merge window nearly as well. Maybe things got pushed to me that really
weren't ready to be merged? Or, quite likely, the drivers/gpu people
don't try to control themselves as much.

And btw, don't take that too personally. I complain and push back on
the maintainers, and I really expect and hope that maintainers push
back on the developers. If people aren't honoring the merge window as
well as they should, you should try to push back on them. Don't take
"fix a bug and cleanup" kind of things. See if people can give you
just the bug-fix, and separate out the cleanup for later for the next
merge window.

Now, we're not really late in the merge window yet, but I'd really
like to think of the late merge window as a "stable" thing. If the
patch is something you'd send to stable, it should clearly go into the
late merge window. But if you wouldn't tag it with "Cc:
sta...@kernel.org" after a 

Re: [git pull] drm fixes

[Chris Wilson]

On Wed, 22 Dec 2010 17:24:36 +0100, Takashi Iwai  wrote:
> The commit 448f53a1ede54eb854d036abf54573281412d650
>   drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks
> 
> causes a regression on a SandyBridge machine here.
> The laptop display (LVDS) becomes blank.  Reverting the commit fixes
> the problem.

The question is whose BIOS is wrong? The Lenovo U160's or the
Sandybridge SDV? And why does it work for that other OS? 

It's back to the square one for one or the other platform...
-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 fixes

[Takashi Iwai]

At Tue, 21 Dec 2010 23:43:18 + (GMT),
Dave Airlie wrote:
> 
> 
> Hi,
> 
> meant to get this out earlier, but I've been off sick as well as having a 
> sick kid, also meant a few things piled up when I wasn't looking
> 
> contains a revert for reported regression in intel and also one in radeon,
> a few radeon fixes, one for a 15s resume time on certain laptops, and one 
> to fix gpu reset on some gpus,
> 
> Dave.
> 
> The following changes since commit a4851d8f7d6351a395d36ae8fdcf41745a832d76:
> 
>   Merge branch 'for_linus' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 (2010-12-15 12:41:17 
> -0800)
> 
> are available in the git repository at:
> 
>   ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git 
> drm-fixes
> 
> Alex Deucher (7):
>   drm/radeon/kms: disable ss fixed ref divide
>   drm/radeon/kms: disable the r600 cb offset checker for linear surfaces
>   drm/radeon/kms/evergreen: flush hdp cache when flushing gart tlb
>   drm/radeon/kms: fix evergreen asic reset
>   drm/radeon/kms/evergreen: reset the grbm blocks at resume and init
>   drm/radeon/kms: reorder display resume to avoid problems
>   drm/radeon/kms: fix bug in r600_gpu_is_lockup
> 
> Benjamin Herrenschmidt (1):
>   drm/radeon: Add early unregister of firmware fb's
> 
> Chris Wilson (5):
>   drm/i915/ringbuffer: Handle wrapping of the autoreported HEAD
>   drm/i915/sdvo: Only use the SDVO pin if it is in the valid range
>   agp/intel: Fix missed cached memory flags setting in i965_write_entry()
>   drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks
>   drm: Include the connector name in the output_poll_execute() debug 
> message

The commit 448f53a1ede54eb854d036abf54573281412d650
  drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks

causes a regression on a SandyBridge machine here.
The laptop display (LVDS) becomes blank.  Reverting the commit fixes
the problem.


thanks,

Takashi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Takashi Iwai]

At Wed, 22 Dec 2010 16:59:06 +,
Chris Wilson wrote:
> 
> On Wed, 22 Dec 2010 17:24:36 +0100, Takashi Iwai  wrote:
> > The commit 448f53a1ede54eb854d036abf54573281412d650
> >   drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks
> > 
> > causes a regression on a SandyBridge machine here.
> > The laptop display (LVDS) becomes blank.  Reverting the commit fixes
> > the problem.
> 
> The question is whose BIOS is wrong? The Lenovo U160's or the
> Sandybridge SDV? And why does it work for that other OS?  rhetorical question of the day here.>
> 
> It's back to the square one for one or the other platform...

Yeah, we can blame BIOS :)  And, this is likely the BIOS on my machine
here that is broken.

But this seems like an issue that you can't rely solely on VBT.  We
can never guarantee that BIOS is correct (who can?), and there is no
way to avoid this change as long as it's hard-coded.  We've hit
another regression by VBT check (e-DP  wrongly detected; kernel bug
24822), so I think judging the behavior only from BIOS is rather
dangerous.


thanks,

Takashi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Linus Torvalds]

On Wed, Dec 22, 2010 at 8:59 AM, Chris Wilson  wrote:
> On Wed, 22 Dec 2010 17:24:36 +0100, Takashi Iwai  wrote:
>> The commit 448f53a1ede54eb854d036abf54573281412d650
>>   drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks
>>
>> causes a regression on a SandyBridge machine here.
>> The laptop display (LVDS) becomes blank.  Reverting the commit fixes
>> the problem.
>
> The question is whose BIOS is wrong?

I don't think so.

> The Lenovo U160's or the
> Sandybridge SDV? And why does it work for that other OS?  rhetorical question of the day here.>

Quite frankly, I don't think the question should *ever* be "whose BIOS
is wrong?"

You should always take for granted that the BIOS is wrong. It's not a
question of "blame the BIOS", it's a question of facts of life.

It's 100% pointless to point fingers and say "the HP BIOS is wrong" or
"the Lenovo BIOS is wrong". Buggy BIOSes happen. ALWAYS. Any code that
relies on the BIOS to such a degree that it either works or not based
on it is by definition broken.

Why does that code need to figure out some LVDS clock from the BIOS?
Why can't the code look at the actual hardware state or similar, since
presumably the screen is on after boot. THAT we can rely on, since a
BIOS that doesn't initialize LVDS is not going to ever ship even as
pre-release.

Linus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Peter Stuge]

Linus Torvalds wrote:
> You should always take for granted that the BIOS is wrong.

Better yet, that there is no BIOS. Maybe one happy day, in the future.


//Peter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Dave Airlie]

On Thu, Dec 23, 2010 at 1:54 PM, Linus Torvalds
 wrote:
> On Wed, Dec 22, 2010 at 8:59 AM, Chris Wilson  
> wrote:
>> On Wed, 22 Dec 2010 17:24:36 +0100, Takashi Iwai  wrote:
>>> The commit 448f53a1ede54eb854d036abf54573281412d650
>>>   drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks
>>>
>>> causes a regression on a SandyBridge machine here.
>>> The laptop display (LVDS) becomes blank.  Reverting the commit fixes
>>> the problem.
>>
>> The question is whose BIOS is wrong?
>
> I don't think so.
>
>>                         The Lenovo U160's or the
>> Sandybridge SDV? And why does it work for that other OS? > rhetorical question of the day here.>
>
> Quite frankly, I don't think the question should *ever* be "whose BIOS
> is wrong?"
>
> You should always take for granted that the BIOS is wrong. It's not a
> question of "blame the BIOS", it's a question of facts of life.
>
> It's 100% pointless to point fingers and say "the HP BIOS is wrong" or
> "the Lenovo BIOS is wrong". Buggy BIOSes happen. ALWAYS. Any code that
> relies on the BIOS to such a degree that it either works or not based
> on it is by definition broken.
>
> Why does that code need to figure out some LVDS clock from the BIOS?
> Why can't the code look at the actual hardware state or similar, since
> presumably the screen is on after boot. THAT we can rely on, since a
> BIOS that doesn't initialize LVDS is not going to ever ship even as
> pre-release.
>

I've no idea but since this is spread-spectrum related the bios may not enable
spread-spectrum on the panel, though really the question is as always, what does
Windows do.

Dave.
>                        Linus
> ___
> 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 fixes

[Alex Riesen]

On Thu, Dec 23, 2010 at 04:54, Linus Torvalds
 wrote:
> Why does that code need to figure out some LVDS clock from the BIOS?
> Why can't the code look at the actual hardware state or similar, since
> presumably the screen is on after boot. THAT we can rely on, since a
> BIOS that doesn't initialize LVDS is not going to ever ship even as
> pre-release.

What if the system booted with it's display turned off? Like a closed
laptop lid or disconnected monitor?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Jesse Barnes]

On Wed, 22 Dec 2010 19:54:31 -0800
Linus Torvalds  wrote:
> > The Lenovo U160's or the
> > Sandybridge SDV? And why does it work for that other OS?  > rhetorical question of the day here.>
> 
> Quite frankly, I don't think the question should *ever* be "whose BIOS
> is wrong?"
> 
> You should always take for granted that the BIOS is wrong. It's not a
> question of "blame the BIOS", it's a question of facts of life.
> 
> It's 100% pointless to point fingers and say "the HP BIOS is wrong" or
> "the Lenovo BIOS is wrong". Buggy BIOSes happen. ALWAYS. Any code that
> relies on the BIOS to such a degree that it either works or not based
> on it is by definition broken.
> 
> Why does that code need to figure out some LVDS clock from the BIOS?
> Why can't the code look at the actual hardware state or similar, since
> presumably the screen is on after boot. THAT we can rely on, since a
> BIOS that doesn't initialize LVDS is not going to ever ship even as
> pre-release.

Oh I wish we could just do that.  Strictly speaking though this isn't
so much of a BIOS issue as it is a ROM issue.  Platform vendors provide
no way of getting at platform configuration details related to graphics
aside from the tables they flash into ROM along with the VBIOS.  The
tables are just like an EDID ROM on a display: they communicate data we
have no other way of getting.

In the particular case of SSC, there's a board down spread spectrum
clock reference source at a fixed frequency.  We can't automatically
determine it at runtime (asking the user "can you see this" at boot
time isn't really an option), so we need to rely on the VBT to tell
us.  The Windows driver uses this data as well, but obviously either
it's incorrect on our SDV (possible) or we're failing to parse the data
correctly (likely).  It's also possible we're failing to look at a bit
that says "use/don't use SSC on this platform" making the frequency
field meaningless.

We'll figure it out or disable SSC enabling altogether failing that
(risking interference with other components like wireless and sound).

-- 
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Linus Torvalds]

On Thu, Dec 23, 2010 at 1:32 AM, Alex Riesen  wrote:
> On Thu, Dec 23, 2010 at 04:54, Linus Torvalds
>  wrote:
>> Why does that code need to figure out some LVDS clock from the BIOS?
>> Why can't the code look at the actual hardware state or similar, since
>> presumably the screen is on after boot. THAT we can rely on, since a
>> BIOS that doesn't initialize LVDS is not going to ever ship even as
>> pre-release.
>
> What if the system booted with it's display turned off? Like a closed
> laptop lid or disconnected monitor?

So then we might have to guess and even use the BIOS state for guessing.

But what's so hard to understand about that word "guess"? That really
is what happens every single time you use some BIOS table. It's not
"look up". It's not "get the right data". It very much is all about
"guessing". The BIOS tables are invariably buggy, and have likely only
ever been tested with one particular version of Windows.

And that's _especially_ true of something like VBIOS tables. They
haven't been tested even with windows, they have only been tested with
the particular graphics driver that the vendor shipped with that
machine. It's quite possible - even likely - that the graphics driver
hard-codes something.

So think about it - if we boot with the laptop open, you have two
choices: "ask the hardware for real working state" or "guess by
probing random state from the BIOS that may or may not actually ever
be used that way by anything".

Which choice would you pick?

And if that means that some laptops have to be booted with the lid
open, that really isn't a problem.

And yes, I do realize that VGA traditionally has had lots of hardware
state that is write-only and cannot be read back. It's possible that
this case is one of those. I dunno. I hope not.

(Side note: resume is different from boot. You should test that resume
works with the lid closed, because resume state is not at all
guaranteed to be sane at all, lid or no lid. But the way to fix that
is NOT to ask the BIOS, it's to remember the state from the original
boot from before the suspend).

  Linus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Anca Emanuel]

Nouveau OpenGL regresion

Tools used: http://packages.ubuntu.com/maverick/misc/glmark2

With 2.6.38-rc5 latest git:
nv50_screen_get_param:162 -  Unknown PIPE_CAP 11
===
glmark2 10.07.1
===
OpenGL Information
GL_VENDOR: nouveau
GL_RENDERER:   Gallium 0.4 on NV92
GL_VERSION:2.1 Mesa 7.9-devel
===
Precompilation
Vertex array  FPS: 105
Vertex buffer object  FPS: 267
Texture filtering
Nearest   FPS: 295
LinearFPS: 299
Mipmapped FPS: 308
Shading
GLSL per vertex lighting  FPS: 227
GLSL per pixel lighting   FPS: 260
===
Your glmark2 Score is 727  ^_^
===


With Linux ubuntu 2.6.35-25-generic #44-Ubuntu SMP Fri Jan 21 17:40:44
UTC 2011 x86_64 GNU/Linux:

nv50_screen_get_param:162 -  Unknown PIPE_CAP 11
===
glmark2 10.07.1
===
OpenGL Information
GL_VENDOR: nouveau
GL_RENDERER:   Gallium 0.4 on NV92
GL_VERSION:2.1 Mesa 7.9-devel
===
Precompilation
Vertex array  FPS: 265
Vertex buffer object  FPS: 599
Texture filtering
Nearest   FPS: 687
LinearFPS: 683
Mipmapped FPS: 717
Shading
GLSL per vertex lighting  FPS: 480
GLSL per pixel lighting   FPS: 524
===
Your glmark2 Score is 1628  ^_^
===
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Rafał Miłecki]

2011/2/18 Anca Emanuel :
> Nouveau OpenGL regresion
>
> Tools used: http://packages.ubuntu.com/maverick/misc/glmark2
>
> With 2.6.38-rc5 latest git:
> nv50_screen_get_param:162 -  Unknown PIPE_CAP 11
> ===
>    glmark2 10.07.1
> ===
>    OpenGL Information
>    GL_VENDOR:     nouveau
>    GL_RENDERER:   Gallium 0.4 on NV92
>    GL_VERSION:    2.1 Mesa 7.9-devel
> ===
> Precompilation
>    Vertex array                  FPS: 105
>    Vertex buffer object          FPS: 267
> Texture filtering
>    Nearest                       FPS: 295
>    Linear                        FPS: 299
>    Mipmapped                     FPS: 308
> Shading
>    GLSL per vertex lighting      FPS: 227
>    GLSL per pixel lighting       FPS: 260
> ===
> Your glmark2 Score is 727  ^_^
> ===
>
>
> With Linux ubuntu 2.6.35-25-generic #44-Ubuntu SMP Fri Jan 21 17:40:44
> UTC 2011 x86_64 GNU/Linux:
>
> nv50_screen_get_param:162 -  Unknown PIPE_CAP 11
> ===
>    glmark2 10.07.1
> ===
>    OpenGL Information
>    GL_VENDOR:     nouveau
>    GL_RENDERER:   Gallium 0.4 on NV92
>    GL_VERSION:    2.1 Mesa 7.9-devel
> ===
> Precompilation
>    Vertex array                  FPS: 265
>    Vertex buffer object          FPS: 599
> Texture filtering
>    Nearest                       FPS: 687
>    Linear                        FPS: 683
>    Mipmapped                     FPS: 717
> Shading
>    GLSL per vertex lighting      FPS: 480
>    GLSL per pixel lighting       FPS: 524
> ===
> Your glmark2 Score is 1628  ^_^
> ===

You're yelling in thread about recent single drm fixes... and you
compare 2.6.35 with 2.6.38-rc5. What is possibility it's regression
introduced by one of that few commits?

Please report on bugzilla normally, perform bisecting, but do not
report such a things in unrelated places!

-- 
Rafał
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Chris Wilson]

On Wed, 23 Feb 2011 15:58:02 -0800, Linus Torvalds 
 wrote:
> On Wed, Feb 23, 2011 at 3:17 PM, Dave Airlie  wrote:
> >
> > Nothing too major,
> >
> > Two regression fixers (one revert that got fixes properly elsewhere), some
> > timestamp fixes and an agp module reload fix.
> 
> Pulled. However, what about the report from   Pavel Machek :
> 
> > >  drm/i915: Completely disable fence pipelining.
> >
> > Reverting this commit helps in v2.6.38-rc5+ when screen is not fully 
> > updated,
> > or has a corrupted picture like horizontal black or white stripes. Using a
> > compositor like compiz may help to avoid the problem.
> >
> > See bug https://bugzilla.kernel.org/show_bug.cgi?id=27572
> 
> Any update on that one?

No, reverting that will cause just another bug elsewhere. I need to
work out how the gpu is not being flushed with a non-pipelined fence
change.

> There's that whole "return -EINVAL for
> I915_PARAM_HAS_RELAXED_FENCING" patch thing?

As it turns out this is a bug in the userspace components of the stack for
gen2 hardware, with lax kernel side enforcement. Daniel has a fix for both.
-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 fixes

[Linus Torvalds]

On Wed, Feb 23, 2011 at 3:17 PM, Dave Airlie  wrote:
>
> Nothing too major,
>
> Two regression fixers (one revert that got fixes properly elsewhere), some
> timestamp fixes and an agp module reload fix.

Pulled. However, what about the report from Pavel Machek :

> >  drm/i915: Completely disable fence pipelining.
>
> Reverting this commit helps in v2.6.38-rc5+ when screen is not fully updated,
> or has a corrupted picture like horizontal black or white stripes. Using a
> compositor like compiz may help to avoid the problem.
>
> See bug https://bugzilla.kernel.org/show_bug.cgi?id=27572

Any update on that one? There's that whole "return -EINVAL for
I915_PARAM_HAS_RELAXED_FENCING" patch thing?

 Linus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Alex Riesen]

On Thu, Feb 24, 2011 at 01:13, Chris Wilson  wrote:
> On Wed, 23 Feb 2011 15:58:02 -0800, Linus Torvalds 
>  wrote:
>> >
>> > See bug https://bugzilla.kernel.org/show_bug.cgi?id=27572
>>
>> Any update on that one?
>
> No, reverting that will cause just another bug elsewhere. I need to
> work out how the gpu is not being flushed with a non-pipelined fence
> change.
>
>> There's that whole "return -EINVAL for
>> I915_PARAM_HAS_RELAXED_FENCING" patch thing?
>
> As it turns out this is a bug in the userspace components of the stack for
> gen2 hardware, with lax kernel side enforcement. Daniel has a fix for both.

Chris, could you point us at the patch? I ask because Daniel left a
comment in bug discussion that we should ignore some patch from him,
and there was no mention of anything else.

I'll gladly test a better fix.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Indan Zupancic]

On Thu, February 24, 2011 09:27, Alex Riesen wrote:
> On Thu, Feb 24, 2011 at 01:13, Chris Wilson  wrote:
>> On Wed, 23 Feb 2011 15:58:02 -0800, Linus Torvalds 
>> 
>> wrote:
>>> >
>>> > See bug https://bugzilla.kernel.org/show_bug.cgi?id=27572
>>>
>>> Any update on that one?
>>
>> No, reverting that will cause just another bug elsewhere. I need to
>> work out how the gpu is not being flushed with a non-pipelined fence
>> change.
>>
>>> There's that whole "return -EINVAL for
>>> I915_PARAM_HAS_RELAXED_FENCING" patch thing?
>>
>> As it turns out this is a bug in the userspace components of the stack for
>> gen2 hardware, with lax kernel side enforcement. Daniel has a fix for both.
>
> Chris, could you point us at the patch? I ask because Daniel left a
> comment in bug discussion that we should ignore some patch from him,
> and there was no mention of anything else.
>
> I'll gladly test a better fix.

See:

http://lists.freedesktop.org/archives/dri-devel/2011-February/008658.html
https://lkml.org/lkml/2011/2/23/34


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Alex Riesen]

On Thu, Feb 24, 2011 at 10:18, Indan Zupancic  wrote:
>>>
>>> As it turns out this is a bug in the userspace components of the stack for
>>> gen2 hardware, with lax kernel side enforcement. Daniel has a fix for both.
>>
>> Chris, could you point us at the patch? I ask because Daniel left a
>> comment in bug discussion that we should ignore some patch from him,
>> and there was no mention of anything else.
>>
>> I'll gladly test a better fix.
>
> See:
>
> http://lists.freedesktop.org/archives/dri-devel/2011-February/008658.html

This is precisely the link on which Daniel commented:

Comment #35 From Daniel Vetter 2011-02-23 10:38:25

> --- Comment #34 from Indan   2011-02-23 01:53:25 ---
> Daniel has a real fix at:
> http://lists.freedesktop.org/archives/dri-devel/2011-February/008658.html

You can safely ignore this patch. It only fixes a very special corruption due
to relaxed tiling. This kind of corruption manifests itself in garbage in the
lower-left corner of pixmaps (think ui elements) if and only if the height
rounded up to the next multiple of 8 is not a multiple of 16. Your
corruptions look different.

[lower-left corner means: at most 8 pixels high, at most half the width of
the total pixmap]

And yes, it does not help at all to fix the corruption in the ticket.

> https://lkml.org/lkml/2011/2/23/34

This is just the discussion about the problem described in the ticket.
It does not even mention the patch from the previous link, BTW.
It does have the patch which returns -EINVAL for I915_PARAM_HAS_RELAXED_FENCING,
though.

So, AFAICS, at the moment there is no better patch than this:

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 17bd766..8f8a6a3 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -764,7 +764,7 @@ static int i915_getparam(struct drm_device *dev, void *data,
break;
case I915_PARAM_HAS_RELAXED_FENCING:
value = 1;
-   break;
+   return -EINVAL;
case I915_PARAM_HAS_COHERENT_RINGS:
value = 1;
break;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Alex Riesen]

On Thu, Feb 24, 2011 at 20:04, Alex Riesen  wrote:
> So, AFAICS, at the moment there is no better patch than this:
>
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 17bd766..8f8a6a3 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -764,7 +764,7 @@ static int i915_getparam(struct drm_device *dev, void 
> *data,
>                break;
>        case I915_PARAM_HAS_RELAXED_FENCING:
>                value = 1;
> -               break;
> +               return -EINVAL;
>        case I915_PARAM_HAS_COHERENT_RINGS:
>                value = 1;
>                break;
>

Probably unrelated, but I managed to get a cursor corruption with
just this patch. So maybe, I still need that fix from Daniel: an X
cursor seem to meet that pixmap size requirements. And corruption
picture fits too: stripes and dots in lower left corner of where
a part of the cursor image should have been.

Can't reproduce, though.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Indan Zupancic]

On Thu, February 24, 2011 20:04, Alex Riesen wrote:
> On Thu, Feb 24, 2011 at 10:18, Indan Zupancic  wrote:

 As it turns out this is a bug in the userspace components of the stack for
 gen2 hardware, with lax kernel side enforcement. Daniel has a fix for both.
>>>
>>> Chris, could you point us at the patch? I ask because Daniel left a
>>> comment in bug discussion that we should ignore some patch from him,
>>> and there was no mention of anything else.
>>>
>>> I'll gladly test a better fix.
>>
>> See:
>>
>> http://lists.freedesktop.org/archives/dri-devel/2011-February/008658.html
>
> This is precisely the link on which Daniel commented:
[...]
> And yes, it does not help at all to fix the corruption in the ticket.

Because there are two (or three) corruption problems! One is fixed by
Daniels's patch, the other isn't fixed yet AFAIC.

You're grumbling that I'm giving you information about the fix for one
problem, the one Chris was talking about and you replied to, while you're
interested in the other one (or both).

>> https://lkml.org/lkml/2011/2/23/34
>
> This is just the discussion about the problem described in the ticket.
> It does not even mention the patch from the previous link, BTW.
> It does have the patch which returns -EINVAL for 
> I915_PARAM_HAS_RELAXED_FENCING,
> though.
>
> So, AFAICS, at the moment there is no better patch than this:
>
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 17bd766..8f8a6a3 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -764,7 +764,7 @@ static int i915_getparam(struct drm_device *dev, void 
> *data,
>   break;
>   case I915_PARAM_HAS_RELAXED_FENCING:
>   value = 1;
> - break;
> + return -EINVAL;
>   case I915_PARAM_HAS_COHERENT_RINGS:
>   value = 1;
>   break;

Read those above links again! Daniel's patch fixes that one corruption, the
above snippet has the same effect and works around the same bug, but neither
do fix that other corruption mentioned in the ticket.

Greetings,

Indan


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Alex Riesen]

On Fri, Feb 25, 2011 at 00:29, Indan Zupancic  wrote:
>>> https://lkml.org/lkml/2011/2/23/34
>>
>> This is just the discussion about the problem described in the ticket.
>> It does not even mention the patch from the previous link, BTW.
>> It does have the patch which returns -EINVAL for 
>> I915_PARAM_HAS_RELAXED_FENCING,
>> though.
>>
>> So, AFAICS, at the moment there is no better patch than this:
>>
>> diff --git a/drivers/gpu/drm/i915/i915_dma.c 
>> b/drivers/gpu/drm/i915/i915_dma.c
>> index 17bd766..8f8a6a3 100644
>> --- a/drivers/gpu/drm/i915/i915_dma.c
>> +++ b/drivers/gpu/drm/i915/i915_dma.c
>> @@ -764,7 +764,7 @@ static int i915_getparam(struct drm_device *dev, void 
>> *data,
>>               break;
>>       case I915_PARAM_HAS_RELAXED_FENCING:
>>               value = 1;
>> -             break;
>> +             return -EINVAL;
>>       case I915_PARAM_HAS_COHERENT_RINGS:
>>               value = 1;
>>               break;
>
> Read those above links again! Daniel's patch fixes that one corruption, the
> above snippet has the same effect and works around the same bug, but neither
> do fix that other corruption mentioned in the ticket.

Do you have any idea which patch fixes what? It's just I slowly begin to
doubt that you do. So far I found only two patches (and three changes):

This is the first:

Corruption caused by portions of the screen stopped updating (the Bug 27572).
Certainly worked around by returning -EINVAL for ..RELAXED_FENCING.

The second:

Corruption in small pixmaps, which has no bug number, and commented on by
Daniel in the Bug 27572 as being not the case there.
Fixed by his patch posted to dri-devel "fix corruptions on i8xx due to
relaxed fencing". It may be related to the Bug 27572, but it certainly
does not fix the problem.

There is also this change from the first Daniel's patch which I don't
know what to think about:

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index cf4f74c..2e6b532 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1404,6 +1404,8 @@ i915_gem_get_unfenced_gtt_alignment(struct
drm_i915_gem_object *obj)
struct drm_device *dev = obj->base.dev;
int tile_height;

+   return i915_gem_get_gtt_alignment(obj);
+
/*
 * Minimum alignment is 4k (GTT page size) for sane hw.
 */diff --git a/drivers/gpu/drm/i915/i915_dma.c
b/drivers/gpu/drm/i915/i915_dma.c

Now, may I ask you , Indan, to shut up for while and let the developers
speak? Because the matter is becoming a little bit confusing, and not without
your help.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Indan Zupancic]

On Fri, February 25, 2011 11:18, Alex Riesen wrote:
> On Fri, Feb 25, 2011 at 00:29, Indan Zupancic  wrote:
 https://lkml.org/lkml/2011/2/23/34
>>>
>>> This is just the discussion about the problem described in the ticket.
>>> It does not even mention the patch from the previous link, BTW.
>>> It does have the patch which returns -EINVAL for 
>>> I915_PARAM_HAS_RELAXED_FENCING,
>>> though.
>>>
>>> So, AFAICS, at the moment there is no better patch than this:
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_dma.c 
>>> b/drivers/gpu/drm/i915/i915_dma.c
>>> index 17bd766..8f8a6a3 100644
>>> --- a/drivers/gpu/drm/i915/i915_dma.c
>>> +++ b/drivers/gpu/drm/i915/i915_dma.c
>>> @@ -764,7 +764,7 @@ static int i915_getparam(struct drm_device *dev, void 
>>> *data,
>>>               break;
>>>       case I915_PARAM_HAS_RELAXED_FENCING:
>>>               value = 1;
>>> -             break;
>>> +             return -EINVAL;
>>>       case I915_PARAM_HAS_COHERENT_RINGS:
>>>               value = 1;
>>>               break;
>>
>> Read those above links again! Daniel's patch fixes that one corruption, the
>> above snippet has the same effect and works around the same bug, but neither
>> do fix that other corruption mentioned in the ticket.
>
> Do you have any idea which patch fixes what? It's just I slowly begin to
> doubt that you do.

There is none yet. Reverting "drm/i915: Completely disable fence pipelining."
fixes it, but causes other problems, quoting Chris:

  "No, reverting that will cause just another bug elsewhere. I need to
  work out how the gpu is not being flushed with a non-pipelined fence
  change."

> So far I found only two patches (and three changes):
>
> This is the first:
>
> Corruption caused by portions of the screen stopped updating (the Bug 27572).
> Certainly worked around by returning -EINVAL for ..RELAXED_FENCING.

This is fixed in a better way by Daniel's latest patch.

> The second:
>
> Corruption in small pixmaps, which has no bug number, and commented on by
> Daniel in the Bug 27572 as being not the case there.

This is the above mentioned issue Chris is talking about in the quoted part.

> Fixed by his patch posted to dri-devel "fix corruptions on i8xx due to
> relaxed fencing".
> It may be related to the Bug 27572, but it certainly
> does not fix the problem.

No, that didn't fix that corruption. It's confusing because Tomas
first said it did fix it and later said it didn't. I muddles that
bug report with the corruption I saw, I thought maybe it had the
same source.

> There is also this change from the first Daniel's patch which I don't
> know what to think about:
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index cf4f74c..2e6b532 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1404,6 +1404,8 @@ i915_gem_get_unfenced_gtt_alignment(struct
> drm_i915_gem_object *obj)
>   struct drm_device *dev = obj->base.dev;
>   int tile_height;
>
> + return i915_gem_get_gtt_alignment(obj);
> +
>   /*
>* Minimum alignment is 4k (GTT page size) for sane hw.
>*/diff --git a/drivers/gpu/drm/i915/i915_dma.c
> b/drivers/gpu/drm/i915/i915_dma.c

That was just a patch to try out for me to pinpoint the source of the bug.
It's irrelevant now, as that bug is fixed by Daniel's patch. And I tested
it and it didn't help anyway, so just ignore it.

> Now, may I ask you , Indan, to shut up for while and let the developers
> speak? Because the matter is becoming a little bit confusing, and not without
> your help.

That's because you're getting frustrated and not reading properly what
everyone writes. Just relax.

Chris seems to be working on it. When he has progress or patches for us to
try I'm sure he'll speak up.

My corruption problems are gone, except for the ones I have without xcompmgr,
but as I get those with old kernels too I think it's a userspace bug. Only
reason I reply to you is so others don't have to. I'm trying to clarify things,
but apparently I'm doing a bad job of it.

Good luck,

Indan


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Alex Riesen]

On Fri, Feb 25, 2011 at 12:07, Indan Zupancic  wrote:
> On Fri, February 25, 2011 11:18, Alex Riesen wrote:
>> So far I found only two patches (and three changes):
>>
>> This is the first:
>>
>> Corruption caused by portions of the screen stopped updating (the Bug 27572).
>> Certainly worked around by returning -EINVAL for ..RELAXED_FENCING.
>
> This is fixed in a better way by Daniel's latest patch.
>

Precisely which is it? Just copy the text of the patch you have
in mind here. Because I don't fscking understand what are talking
about, man!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Pavel Machek]

Hi!

> > Nothing too major,
> >
> > Two regression fixers (one revert that got fixes properly elsewhere), some
> > timestamp fixes and an agp module reload fix.
> 
> Pulled. However, what about the report from   Pavel Machek :

Are you sure it was me?

> > >  drm/i915: Completely disable fence pipelining.
> >
> > Reverting this commit helps in v2.6.38-rc5+ when screen is not fully 
> > updated,
> > or has a corrupted picture like horizontal black or white stripes. Using a
> > compositor like compiz may help to avoid the problem.
> >
> > See bug https://bugzilla.kernel.org/show_bug.cgi?id=27572

I don't see myself there, nor do I remember having that problem.

DRM_I915_KMS seems to have vesafb... but I'm afraid it always did..
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Alex Riesen]

On Fri, Feb 25, 2011 at 12:35, Alex Riesen  wrote:
> On Fri, Feb 25, 2011 at 12:07, Indan Zupancic  wrote:
>> On Fri, February 25, 2011 11:18, Alex Riesen wrote:
>>> So far I found only two patches (and three changes):
>>>
>>> This is the first:
>>>
>>> Corruption caused by portions of the screen stopped updating (the Bug 
>>> 27572).
>>> Certainly worked around by returning -EINVAL for ..RELAXED_FENCING.
>>
>> This is fixed in a better way by Daniel's latest patch.
>>
>
> Precisely which is it? Just copy the text of the patch you have
> in mind here. Because I don't fscking understand what are talking
> about, man!
>

Whatever is now in the master has fixed this corruption for me.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Dave Airlie]

(this time after scping the correct file to my mailserver).

> Hi Linus,
> 
> sent a pull for the first one already, but not sure if you pushed it out,
> 
> the second fix is very urgent, it fixes complete system hangs with certain 
> older radeon GPUs and pageflipping enabled. Nasty to track down, since 
> everything dies hard, when the gpu takes out the PCIE bus.
> 
> Dave.

The following changes since commit 9179746652faf0aba07b8b7f770dcf29892a24c6:

  Merge branch 'media_fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6 (2011-03-10 
13:22:10 -0800)

are available in the git repository at:

  ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-fixes

Dave Airlie (2):
  drm/radeon: add pageflip hooks for fusion
  drm/radeon: fix page flipping hangs on r300/r400

 drivers/gpu/drm/radeon/r100.c   |   17 -
 drivers/gpu/drm/radeon/radeon_asic.c|3 +++
 drivers/gpu/drm/radeon/radeon_legacy_crtc.c |3 ++-
 3 files changed, 5 insertions(+), 18 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Michel Dänzer]

On Mit, 2011-03-23 at 04:18 +, Dave Airlie wrote: 
> 
> One radeon, 2 core fixes, and an interface update to allow for > 2 crtcs 
> in vblank.

[...]

> Ilija Hadzic (1):
>   drm/kernel: vblank wait on crtc > 1

This patch was still being debated yesterday, are you deliberately
pushing it regardless? Once it hits mainline, it'll be pretty much set
in stone.


-- 
Earthling Michel Dänzer   |http://www.vmware.com
Libre software enthusiast |  Debian, X and DRI developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Dave Airlie]

2011/3/23 Michel Dänzer :
> On Mit, 2011-03-23 at 04:18 +, Dave Airlie wrote:
>>
>> One radeon, 2 core fixes, and an interface update to allow for > 2 crtcs
>> in vblank.
>
> [...]
>
>> Ilija Hadzic (1):
>>       drm/kernel: vblank wait on crtc > 1
>
> This patch was still being debated yesterday, are you deliberately
> pushing it regardless? Once it hits mainline, it'll be pretty much set
> in stone.

>From what I can see it was the userspace patches being debated, this
one seemed fine and the interface looked okay to me.

Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Michel Dänzer]

On Mit, 2011-03-23 at 18:16 +1000, Dave Airlie wrote: 
> 2011/3/23 Michel Dänzer :
> > On Mit, 2011-03-23 at 04:18 +, Dave Airlie wrote:
> >>
> >> One radeon, 2 core fixes, and an interface update to allow for > 2 crtcs
> >> in vblank.
> >
> > [...]
> >
> >> Ilija Hadzic (1):
> >>   drm/kernel: vblank wait on crtc > 1
> >
> > This patch was still being debated yesterday, are you deliberately
> > pushing it regardless? Once it hits mainline, it'll be pretty much set
> > in stone.
> 
> From what I can see it was the userspace patches being debated, this
> one seemed fine and the interface looked okay to me.

The author ignored my suggestions to make the patch smaller and simpler,
more maintainable and more future-proof all at once.


-- 
Earthling Michel Dänzer   |http://www.vmware.com
Libre software enthusiast |  Debian, X and DRI developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Dave Airlie]

2011/3/23 Michel Dänzer :
> On Mit, 2011-03-23 at 18:16 +1000, Dave Airlie wrote:
>> 2011/3/23 Michel Dänzer :
>> > On Mit, 2011-03-23 at 04:18 +, Dave Airlie wrote:
>> >>
>> >> One radeon, 2 core fixes, and an interface update to allow for > 2 crtcs
>> >> in vblank.
>> >
>> > [...]
>> >
>> >> Ilija Hadzic (1):
>> >>       drm/kernel: vblank wait on crtc > 1
>> >
>> > This patch was still being debated yesterday, are you deliberately
>> > pushing it regardless? Once it hits mainline, it'll be pretty much set
>> > in stone.
>>
>> From what I can see it was the userspace patches being debated, this
>> one seemed fine and the interface looked okay to me.
>
> The author ignored my suggestions to make the patch smaller and simpler,
> more maintainable and more future-proof all at once.

It was already small and I'm not sure merging the flags made it more
maintainable. Its always
being a slightly painful ioctl, and hopefully any future changes add a
new ioctl esp if we want 64-bit values.

The only comment I really thought was necessary was changing the CAP
name, but since that isn't
part of the ABI (just the number) we can quickly fix it with a follow-up.

Dave.
Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Michel Dänzer]

On Mit, 2011-03-23 at 19:06 +1000, Dave Airlie wrote: 
> 2011/3/23 Michel Dänzer :
> > On Mit, 2011-03-23 at 18:16 +1000, Dave Airlie wrote:
> >> 2011/3/23 Michel Dänzer :
> >> > On Mit, 2011-03-23 at 04:18 +, Dave Airlie wrote:
> >> >>
> >> >> One radeon, 2 core fixes, and an interface update to allow for > 2 crtcs
> >> >> in vblank.
> >> >
> >> > [...]
> >> >
> >> >> Ilija Hadzic (1):
> >> >>   drm/kernel: vblank wait on crtc > 1
> >> >
> >> > This patch was still being debated yesterday, are you deliberately
> >> > pushing it regardless? Once it hits mainline, it'll be pretty much set
> >> > in stone.
> >>
> >> From what I can see it was the userspace patches being debated, this
> >> one seemed fine and the interface looked okay to me.
> >
> > The author ignored my suggestions to make the patch smaller and simpler,
> > more maintainable and more future-proof all at once.
> 
> It was already small and I'm not sure merging the flags made it more
> maintainable.

Having two holes between _DRM_VBLANK_FLAGS_MASK,
_DRM_VBLANK_HIGH_CRTC_MASK and _DRM_VBLANK_TYPES_MASK can unnecessarily
complicate future extensions.


> Its always being a slightly painful ioctl, and hopefully any future
> changes add a new ioctl esp if we want 64-bit values.

Is there really a problem with assuming that if the 32-bit value went
backwards, the upper 32 bits have incremented by 1? 1 << 32 refreshes is
about 2 years, so I can't really see any ambiguity there. For hardware
that doesn't have 64 bit frame counters (does any have that yet?),
something like that needs to be done at some level anyway.

Anyway, that's another discussion...


-- 
Earthling Michel Dänzer   |http://www.vmware.com
Libre software enthusiast |  Debian, X and DRI developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Ilija Hadzic]

On Wed, 23 Mar 2011, Dave Airlie wrote:


2011/3/23 Michel Dänzer :

On Mit, 2011-03-23 at 18:16 +1000, Dave Airlie wrote:

2011/3/23 Michel Dänzer :

On Mit, 2011-03-23 at 04:18 +, Dave Airlie wrote:


One radeon, 2 core fixes, and an interface update to allow for > 2 crtcs
in vblank.


[...]


Ilija Hadzic (1):
      drm/kernel: vblank wait on crtc > 1


This patch was still being debated yesterday, are you deliberately
pushing it regardless? Once it hits mainline, it'll be pretty much set
in stone.


From what I can see it was the userspace patches being debated, this
one seemed fine and the interface looked okay to me.


The author ignored my suggestions to make the patch smaller and simpler,
more maintainable and more future-proof all at once.


It was already small and I'm not sure merging the flags made it more
maintainable. Its always
being a slightly painful ioctl, and hopefully any future changes add a
new ioctl esp if we want 64-bit values.

The only comment I really thought was necessary was changing the CAP
name, but since that isn't
part of the ABI (just the number) we can quickly fix it with a follow-up.

Dave.


All of the issues debated yesterday, except one, boil down to renaming a 
handful on #defines without changing the values nor interface nor behavior 
of the kernel. For those that I agreed, I'll follow up with a small patch 
shortly.


-- Ilija


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Michel Dänzer]

On Mit, 2011-03-23 at 06:40 -0500, Ilija Hadzic wrote: 
> On Wed, 23 Mar 2011, Dave Airlie wrote:
> 
> > 2011/3/23 Michel Dänzer :
> >> On Mit, 2011-03-23 at 18:16 +1000, Dave Airlie wrote:
> >>> 2011/3/23 Michel Dänzer :
>  On Mit, 2011-03-23 at 04:18 +, Dave Airlie wrote:
> >
> > One radeon, 2 core fixes, and an interface update to allow for > 2 crtcs
> > in vblank.
> 
>  [...]
> 
> > Ilija Hadzic (1):
> >   drm/kernel: vblank wait on crtc > 1
> 
>  This patch was still being debated yesterday, are you deliberately
>  pushing it regardless? Once it hits mainline, it'll be pretty much set
>  in stone.
> >>>
> >>> From what I can see it was the userspace patches being debated, this
> >>> one seemed fine and the interface looked okay to me.
> >>
> >> The author ignored my suggestions to make the patch smaller and simpler,
> >> more maintainable and more future-proof all at once.
> >
> > It was already small and I'm not sure merging the flags made it more
> > maintainable. Its always
> > being a slightly painful ioctl, and hopefully any future changes add a
> > new ioctl esp if we want 64-bit values.
> >
> > The only comment I really thought was necessary was changing the CAP
> > name, but since that isn't
> > part of the ABI (just the number) we can quickly fix it with a follow-up.
> >
> > Dave.
> 
> All of the issues debated yesterday, except one, boil down to renaming a 
> handful on #defines without changing the values nor interface nor behavior 
> of the kernel.

No, one central point is not to leave two holes between
_DRM_VBLANK_FLAGS_MASK, _DRM_VBLANK_HIGH_CRTC_MASK and
_DRM_VBLANK_TYPES_MASK .


-- 
Earthling Michel Dänzer   |http://www.vmware.com
Libre software enthusiast |  Debian, X and DRI developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Dave Airlie]

2011/3/23 Michel Dänzer :
> On Mit, 2011-03-23 at 06:40 -0500, Ilija Hadzic wrote:
>> On Wed, 23 Mar 2011, Dave Airlie wrote:
>>
>> > 2011/3/23 Michel Dänzer :
>> >> On Mit, 2011-03-23 at 18:16 +1000, Dave Airlie wrote:
>> >>> 2011/3/23 Michel Dänzer :
>>  On Mit, 2011-03-23 at 04:18 +, Dave Airlie wrote:
>> >
>> > One radeon, 2 core fixes, and an interface update to allow for > 2 
>> > crtcs
>> > in vblank.
>> 
>>  [...]
>> 
>> > Ilija Hadzic (1):
>> >       drm/kernel: vblank wait on crtc > 1
>> 
>>  This patch was still being debated yesterday, are you deliberately
>>  pushing it regardless? Once it hits mainline, it'll be pretty much set
>>  in stone.
>> >>>
>> >>> From what I can see it was the userspace patches being debated, this
>> >>> one seemed fine and the interface looked okay to me.
>> >>
>> >> The author ignored my suggestions to make the patch smaller and simpler,
>> >> more maintainable and more future-proof all at once.
>> >
>> > It was already small and I'm not sure merging the flags made it more
>> > maintainable. Its always
>> > being a slightly painful ioctl, and hopefully any future changes add a
>> > new ioctl esp if we want 64-bit values.
>> >
>> > The only comment I really thought was necessary was changing the CAP
>> > name, but since that isn't
>> > part of the ABI (just the number) we can quickly fix it with a follow-up.
>> >
>> > Dave.
>>
>> All of the issues debated yesterday, except one, boil down to renaming a
>> handful on #defines without changing the values nor interface nor behavior
>> of the kernel.
>
> No, one central point is not to leave two holes between
> _DRM_VBLANK_FLAGS_MASK, _DRM_VBLANK_HIGH_CRTC_MASK and
> _DRM_VBLANK_TYPES_MASK .

Okay I've pushed this to my tree before this discussion got on my
radar and I'm just catching up now.

I'll push the following patch to Linus to keep the biggest gap in the
32-bit word for future use, then
we can fixup the userspace patches.

Kernel interfaces aren't considered unchangeable usually on the kernel
is released.

Dave.
From 2fbd71354b13f31c6a408b6eedcefd4ee8d1d3fa Mon Sep 17 00:00:00 2001
From: Dave Airlie 
Date: Thu, 24 Mar 2011 20:54:35 +1000
Subject: [PATCH] drm/vblank: update recently added vbl interface to be more future proof.

This makes the interface a bit cleaner by leaving a single gap in the
vblank bit space instead of creating two gaps.

Suggestions from Michel on mailing list/irc.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/drm_ioctl.c |2 +-
 include/drm/drm.h   |7 ---
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 3617b4c..904d7e9 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -280,7 +280,7 @@ int drm_getcap(struct drm_device *dev, void *data, struct drm_file *file_priv)
 		if (dev->driver->dumb_create)
 			req->value = 1;
 		break;
-	case DRM_CAP_HIGH_CRTC:
+	case DRM_CAP_VBLANK_HIGH_CRTC:
 		req->value = 1;
 		break;
 	default:
diff --git a/include/drm/drm.h b/include/drm/drm.h
index 99cd074..4be33b4 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -463,14 +463,15 @@ struct drm_irq_busid {
 enum drm_vblank_seq_type {
 	_DRM_VBLANK_ABSOLUTE = 0x0,	/**< Wait for specific vblank sequence number */
 	_DRM_VBLANK_RELATIVE = 0x1,	/**< Wait for given number of vblanks */
+	/* bits 1-6 are reserved for high crtcs */
+	_DRM_VBLANK_HIGH_CRTC_MASK = 0x003e,
 	_DRM_VBLANK_EVENT = 0x400,   /**< Send event instead of blocking */
 	_DRM_VBLANK_FLIP = 0x800,   /**< Scheduled buffer swap should flip */
 	_DRM_VBLANK_NEXTONMISS = 0x1000,	/**< If missed, wait for next vblank */
 	_DRM_VBLANK_SECONDARY = 0x2000,	/**< Secondary display controller */
 	_DRM_VBLANK_SIGNAL = 0x4000	/**< Send signal instead of blocking, unsupported */
 };
-#define _DRM_VBLANK_HIGH_CRTC_SHIFT 16
-#define _DRM_VBLANK_HIGH_CRTC_MASK 0x001F
+#define _DRM_VBLANK_HIGH_CRTC_SHIFT 1
 
 #define _DRM_VBLANK_TYPES_MASK (_DRM_VBLANK_ABSOLUTE | _DRM_VBLANK_RELATIVE)
 #define _DRM_VBLANK_FLAGS_MASK (_DRM_VBLANK_EVENT | _DRM_VBLANK_SIGNAL | \
@@ -755,7 +756,7 @@ struct drm_event_vblank {
 };
 
 #define DRM_CAP_DUMB_BUFFER 0x1
-#define DRM_CAP_HIGH_CRTC 0x2
+#define DRM_CAP_VBLANK_HIGH_CRTC 0x2
 
 /* typedef area */
 #ifndef __KERNEL__
-- 
1.7.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Michel Dänzer]

On Don, 2011-03-24 at 21:06 +1000, Dave Airlie wrote: 
> 2011/3/23 Michel Dänzer :
> > On Mit, 2011-03-23 at 06:40 -0500, Ilija Hadzic wrote:
> >> On Wed, 23 Mar 2011, Dave Airlie wrote:
> >>
> >> > 2011/3/23 Michel Dänzer :
> >> >> On Mit, 2011-03-23 at 18:16 +1000, Dave Airlie wrote:
> >> >>> 2011/3/23 Michel Dänzer :
> >>  On Mit, 2011-03-23 at 04:18 +, Dave Airlie wrote:
> >> >
> >> > One radeon, 2 core fixes, and an interface update to allow for > 2 
> >> > crtcs
> >> > in vblank.
> >> 
> >>  [...]
> >> 
> >> > Ilija Hadzic (1):
> >> >   drm/kernel: vblank wait on crtc > 1
> >> 
> >>  This patch was still being debated yesterday, are you deliberately
> >>  pushing it regardless? Once it hits mainline, it'll be pretty much set
> >>  in stone.
> >> >>>
> >> >>> From what I can see it was the userspace patches being debated, this
> >> >>> one seemed fine and the interface looked okay to me.
> >> >>
> >> >> The author ignored my suggestions to make the patch smaller and simpler,
> >> >> more maintainable and more future-proof all at once.
> >> >
> >> > It was already small and I'm not sure merging the flags made it more
> >> > maintainable. Its always
> >> > being a slightly painful ioctl, and hopefully any future changes add a
> >> > new ioctl esp if we want 64-bit values.
> >> >
> >> > The only comment I really thought was necessary was changing the CAP
> >> > name, but since that isn't
> >> > part of the ABI (just the number) we can quickly fix it with a follow-up.
> >> >
> >> > Dave.
> >>
> >> All of the issues debated yesterday, except one, boil down to renaming a
> >> handful on #defines without changing the values nor interface nor behavior
> >> of the kernel.
> >
> > No, one central point is not to leave two holes between
> > _DRM_VBLANK_FLAGS_MASK, _DRM_VBLANK_HIGH_CRTC_MASK and
> > _DRM_VBLANK_TYPES_MASK .
> 
> Okay I've pushed this to my tree before this discussion got on my
> radar and I'm just catching up now.
> 
> I'll push the following patch to Linus to keep the biggest gap in the
> 32-bit word for future use, then we can fixup the userspace patches.

As we discussed on IRC, I'd personally go further, but this is
definitely an improvement and fixes the worst problems. Thanks Dave.

Reviewed-by: Michel Dänzer 


-- 
Earthling Michel Dänzer   |http://www.vmware.com
Libre software enthusiast |  Debian, X and DRI developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Ilija Hadzic]

OK, I'll update libdrm side to match this change and send the patch later 
today


-- Ilija

On Thu, 24 Mar 2011, Dave Airlie wrote:


2011/3/23 Michel D?nzer :

On Mit, 2011-03-23 at 06:40 -0500, Ilija Hadzic wrote:

On Wed, 23 Mar 2011, Dave Airlie wrote:


2011/3/23 Michel D?nzer :

On Mit, 2011-03-23 at 18:16 +1000, Dave Airlie wrote:

2011/3/23 Michel D?nzer :

On Mit, 2011-03-23 at 04:18 +, Dave Airlie wrote:


One radeon, 2 core fixes, and an interface update to allow for > 2 crtcs
in vblank.


[...]


Ilija Hadzic (1):
? ? ? drm/kernel: vblank wait on crtc > 1


This patch was still being debated yesterday, are you deliberately
pushing it regardless? Once it hits mainline, it'll be pretty much set
in stone.


From what I can see it was the userspace patches being debated, this
one seemed fine and the interface looked okay to me.


The author ignored my suggestions to make the patch smaller and simpler,
more maintainable and more future-proof all at once.


It was already small and I'm not sure merging the flags made it more
maintainable. Its always
being a slightly painful ioctl, and hopefully any future changes add a
new ioctl esp if we want 64-bit values.

The only comment I really thought was necessary was changing the CAP
name, but since that isn't
part of the ABI (just the number) we can quickly fix it with a follow-up.

Dave.


All of the issues debated yesterday, except one, boil down to renaming a
handful on #defines without changing the values nor interface nor behavior
of the kernel.


No, one central point is not to leave two holes between
_DRM_VBLANK_FLAGS_MASK, _DRM_VBLANK_HIGH_CRTC_MASK and
_DRM_VBLANK_TYPES_MASK .


Okay I've pushed this to my tree before this discussion got on my
radar and I'm just catching up now.

I'll push the following patch to Linus to keep the biggest gap in the
32-bit word for future use, then
we can fixup the userspace patches.

Kernel interfaces aren't considered unchangeable usually on the kernel
is released.

Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Linus Torvalds]

On Thu, Mar 24, 2011 at 4:31 AM, Ilija Hadzic
 wrote:
>
> OK, I'll update libdrm side to match this change and send the patch later
> today

Quite frankly, this whole discussion is a clear example of why DRM has
been problematic.

Why the hell am I getting pushed stuff that is clearly not baked? It's
the second week of the merge window, the stuff I'm getting should have
been finalized two weeks ago, not be something that is still being
discussed and that has API issues.

In other words: Why should I pull this at all?

  Linus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Ilija Hadzic]

On Thu, 24 Mar 2011, Linus Torvalds wrote:



In other words: Why should I pull this at all?



You should pull it (eventually) because it fixes a problem that is real 
and visible and does it in a way that is conservative enough to not risk 
introducing new breakage.


Whether you should pull it now or wait until you get convinced that we 
got our act together is totally your call.


Speaking as the author of the patch, what Dave pushed this morning is good 
enough for me. I spent quite a bit of time testing all the usage patterns 
(including the latest version pushed to you) and I can assert that the 
change is safe.


I can't speak for others, but I have not seen any additional complaints.

-- Ilija

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Corbin Simpson]

On Thu, Mar 24, 2011 at 8:49 AM, Ilija Hadzic
 wrote:
>
>
> On Thu, 24 Mar 2011, Linus Torvalds wrote:
>
>>
>> In other words: Why should I pull this at all?
>>
>
> You should pull it (eventually) because it fixes a problem that is real and
> visible and does it in a way that is conservative enough to not risk
> introducing new breakage.
>
> Whether you should pull it now or wait until you get convinced that we got
> our act together is totally your call.
>
> Speaking as the author of the patch, what Dave pushed this morning is good
> enough for me. I spent quite a bit of time testing all the usage patterns
> (including the latest version pushed to you) and I can assert that the
> change is safe.
>
> I can't speak for others, but I have not seen any additional complaints.

Alternatively, kick it out and wait for Ilija to see and address
Michel's complaints. It's not too late to improve this.

~ C.

-- 
When the facts change, I change my mind. What do you do, sir? ~ Keynes

Corbin Simpson

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Dave Airlie]

On Fri, Mar 25, 2011 at 12:37 AM, Linus Torvalds
 wrote:
> On Thu, Mar 24, 2011 at 4:31 AM, Ilija Hadzic
>  wrote:
>>
>> OK, I'll update libdrm side to match this change and send the patch later
>> today
>
> Quite frankly, this whole discussion is a clear example of why DRM has
> been problematic.
>
> Why the hell am I getting pushed stuff that is clearly not baked? It's
> the second week of the merge window, the stuff I'm getting should have
> been finalized two weeks ago, not be something that is still being
> discussed and that has API issues.
>
> In other words: Why should I pull this at all?

Linus,

Take a step back, it was an enhancement to a current API, had gotten
reviewed by two people when I merged it and made sense. Michel raised
his concern after that point, so no matter what it was already in a tree
I'd pushed out to public so the only answer when he raised his concern
was to revert or fix it. Its a minor problem. Like I'd have pushed this patch
post merge window, it solves a real problem that Ilija was seeing and
he stepped up
and fixed it, post-merge review is what happened here, and really this
is nothing
compared to say the fallout in the VFS after 2.6.38-rc1.

If you think this has anything to do with Intel's ability to break your hardware
on every merge then you've got your wires crossed.

Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Ilija Hadzic]

On Fri, 25 Mar 2011, Dave Airlie wrote:

Michel raised his concern after that point, so no matter what it was 
already in a tree I'd pushed out to public so the only answer when he 
raised his concern was to revert or fix it.


Just to be fair to Michel (and prevent any unnecessary "fights" on the 
list, for which I am sure people have had enough by now), the concern in 
question that triggered revision of the API was raised in time, but I 
oversaw it in the pile of other comments I was also trying to address.


I am neither the first nor the last guy to inadvertently drop a review 
comment due to limited "bandwidth", so this should not be made into a big 
deal. Especially, when no damage was done (except for a few extra E-mails 
and a little extra work).


Dave did the follow-up patch to satisfy Michel (thanks!) and I have 
already submitted the user space stuff that matches it, so hopefully

we are all aligned now.

thanks,

Ilija


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Linus Torvalds]

On Thu, Mar 24, 2011 at 1:05 PM, Dave Airlie  wrote:
>
> If you think this has anything to do with Intel's ability to break your 
> hardware
> on every merge then you've got your wires crossed.

No, it's about the fact that I expect to be pushed code that is
WRITTEN AND TESTED BEFORE THE MERGE WINDOW.

The merge window is not for writing new code. The code that gets
merged should have been written two weeks ago already. The only new
code that I want to see are actual regressions.

I have been talking about this for YEARS now. It's not a new issue. I
hate seeing patches sent to me while they are clearly still being
discussed and developed. There's something seriously wrong there when
that happens.

   Linus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Dave Airlie]

On Fri, Mar 25, 2011 at 9:48 AM, Linus Torvalds
 wrote:
> On Thu, Mar 24, 2011 at 1:05 PM, Dave Airlie  wrote:
>>
>> If you think this has anything to do with Intel's ability to break your 
>> hardware
>> on every merge then you've got your wires crossed.
>
> No, it's about the fact that I expect to be pushed code that is
> WRITTEN AND TESTED BEFORE THE MERGE WINDOW.
>
> The merge window is not for writing new code. The code that gets
> merged should have been written two weeks ago already. The only new
> code that I want to see are actual regressions.
>
> I have been talking about this for YEARS now. It's not a new issue. I
> hate seeing patches sent to me while they are clearly still being
> discussed and developed. There's something seriously wrong there when
> that happens.

Like seriously you really think VFS locking rework wasn't under
development or discussion when you merged it? I'm sure Al would have
something to say about it considering the number of times he cursed in
irc about that code after you merged it.

Here's the point you are missing. I'd quite happily have pushed this
*outside the merge window* because it solves a real problem with 0
probability of introducing any new problems, so f'ing what if it was
under discussion everything in the kernel is still being discussed and
developed. The ABI change was a minor move of the field to leave a
larger hole for future changes, it wasn't a fucking fanotify syscall.

This isn't even close to the level of the usual type of fuckups you
get in a merge window, it just happens you were cc'ed on the
discusson, otherwise I'm betting you'd never even notice. I'm betting
something much worse landed in this merge window that you should be
giving a fuck about, but this isn't the droid you are lookin for.

Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Linus Torvalds]

On Thu, Mar 24, 2011 at 5:07 PM, Dave Airlie  wrote:
>
> Like seriously you really think VFS locking rework wasn't under
> development or discussion when you merged it? I'm sure Al would have
> something to say about it considering the number of times he cursed in
> irc about that code after you merged it.

Umm. That code was basically over a year old by the time it was merged.

How old was the code we're talking about now? Seriously?

And your argument that this case is something you'd have pushed even
outside the merge window - I think that sounds like more of the same
problem. You say it fixes a problem - but does it fix a REGRESSION?

Do you see the difference? Every single commit I get "fixes a
problem". But our rules for these things are much stricter than that.

> This isn't even close to the level of the usual type of fuckups you
> get in a merge window, it just happens you were cc'ed on the
> discusson, otherwise I'm betting you'd never even notice. I'm betting
> something much worse landed in this merge window that you should be
> giving a fuck about, but this isn't the droid you are lookin for.

Maybe not. But why is it always the DRM tree that has these issues?
Why is it that the DRM tree is the one that gets relatively _huge_
patches after -rc1 is out?

I really REALLY wish that you graphics people would at some point
admit that you guys have a problem. I am hoping that the intel side is
being worked on.

Instead, I see what seems to be you being in a hurry, and arguments
why uncooked code should be merged even outside the merge window.

Do you see what I'm aiming at here?

If this was a one-time event, we wouldn't be having this discussion.
But the DRM tree is one of the BIGGEST issues after the merge window
has closed. And it's EVERY SINGLE RELEASE.

Why? Some introspection please. You don't even have to answer me. I
ask you to answer that to yourself.

Linus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Linus Torvalds]

On Thu, Mar 24, 2011 at 5:17 PM, Linus Torvalds
 wrote:
>
> If this was a one-time event, we wouldn't be having this discussion.
> But the DRM tree is one of the BIGGEST issues after the merge window
> has closed. And it's EVERY SINGLE RELEASE.

.. regardless, it's pulled now. I just hope that some day I'll be
taken by surprise, and the drm tree won't be the biggest issue after
-rc1.

Some day.

Linus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel