[Bug 25463] crash with progs/perf/copytex

[bugzilla-daemon]

http://bugs.freedesktop.org/show_bug.cgi?id=25463





--- Comment #2 from Maciej Cencora   2009-12-11 17:23:59 
PST ---
Workaround pushed to mesa_7_7_branch (commit id
8413a3aefaf4968f8b17263826b34baa99c2a907).


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm nouveau pony for Xmas.

[Stephane Marchesin]

2009/12/11 Dave Airlie :
>
> Hi Linus,
>
> Please pull the 'drm-nouveau-pony' branch from
> ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git 
> drm-nouveau-pony
>
> This contains the nouveau driver with Kconfig under staging for now, the
> code is going under drm because the upstream tree has it there, and it
> makes passing patches a lot easier at least initially.
>
> Thanks to Ben Skeggs for doing overtime on his Friday evening to get the
> ctxprogs ripped out and firmware loader support added. The firmware is
> available elsewhere via the nouveau project linux git tree, and comes with
> all the warnings mentioned about possible copyright issues.
>
> After this I also hope to merge the VMware virtual GPU kms driver early
> next week which is also TTM based and going into staging.
>
> The driver alone is ~36,000 lines of code, which is bigger than most
> subsystems we carry, so hopefully ppl realise the monumental scale of
> writing a driver for these things.
>
> Dave.
>
>  drivers/gpu/drm/Makefile                    |    2 +
>  drivers/gpu/drm/i2c/Makefile                |    4 +
>  drivers/gpu/drm/i2c/ch7006_drv.c            |  531 +++
>  drivers/gpu/drm/i2c/ch7006_mode.c           |  473 +++
>  drivers/gpu/drm/i2c/ch7006_priv.h           |  344 ++
>  drivers/gpu/drm/nouveau/Kconfig             |   44 +
>  drivers/gpu/drm/nouveau/Makefile            |   31 +
>  drivers/gpu/drm/nouveau/nouveau_acpi.c      |  125 +
>  drivers/gpu/drm/nouveau/nouveau_backlight.c |  155 +
>  drivers/gpu/drm/nouveau/nouveau_bios.c      | 6095 
> +++
>  drivers/gpu/drm/nouveau/nouveau_bios.h      |  289 ++
>  drivers/gpu/drm/nouveau/nouveau_bo.c        |  671 +++
>  drivers/gpu/drm/nouveau/nouveau_calc.c      |  478 +++
>  drivers/gpu/drm/nouveau/nouveau_channel.c   |  468 ++
>  drivers/gpu/drm/nouveau/nouveau_connector.c |  824 
>  drivers/gpu/drm/nouveau/nouveau_connector.h |   54 +
>  drivers/gpu/drm/nouveau/nouveau_crtc.h      |   95 +
>  drivers/gpu/drm/nouveau/nouveau_debugfs.c   |  155 +
>  drivers/gpu/drm/nouveau/nouveau_display.c   |  115 +
>  drivers/gpu/drm/nouveau/nouveau_dma.c       |  206 +
>  drivers/gpu/drm/nouveau/nouveau_dma.h       |  157 +
>  drivers/gpu/drm/nouveau/nouveau_dp.c        |  569 +++
>  drivers/gpu/drm/nouveau/nouveau_drv.c       |  405 ++
>  drivers/gpu/drm/nouveau/nouveau_drv.h       | 1286 ++
>  drivers/gpu/drm/nouveau/nouveau_encoder.h   |   91 +
>  drivers/gpu/drm/nouveau/nouveau_fb.h        |   47 +
>  drivers/gpu/drm/nouveau/nouveau_fbcon.c     |  380 ++
>  drivers/gpu/drm/nouveau/nouveau_fbcon.h     |   47 +
>  drivers/gpu/drm/nouveau/nouveau_fence.c     |  262 ++
>  drivers/gpu/drm/nouveau/nouveau_gem.c       |  992 +
>  drivers/gpu/drm/nouveau/nouveau_hw.c        | 1080 +
>  drivers/gpu/drm/nouveau/nouveau_hw.h        |  455 ++
>  drivers/gpu/drm/nouveau/nouveau_i2c.c       |  269 ++
>  drivers/gpu/drm/nouveau/nouveau_i2c.h       |   52 +
>  drivers/gpu/drm/nouveau/nouveau_ioc32.c     |   72 +
>  drivers/gpu/drm/nouveau/nouveau_irq.c       |  702 +++
>  drivers/gpu/drm/nouveau/nouveau_mem.c       |  568 +++
>  drivers/gpu/drm/nouveau/nouveau_notifier.c  |  196 +
>  drivers/gpu/drm/nouveau/nouveau_object.c    | 1294 ++
>  drivers/gpu/drm/nouveau/nouveau_reg.h       |  836 
>  drivers/gpu/drm/nouveau/nouveau_sgdma.c     |  321 ++
>  drivers/gpu/drm/nouveau/nouveau_state.c     |  811 
>  drivers/gpu/drm/nouveau/nouveau_ttm.c       |  131 +
>  drivers/gpu/drm/nouveau/nv04_crtc.c         | 1002 +
>  drivers/gpu/drm/nouveau/nv04_cursor.c       |   70 +
>  drivers/gpu/drm/nouveau/nv04_dac.c          |  528 +++
>  drivers/gpu/drm/nouveau/nv04_dfp.c          |  621 +++
>  drivers/gpu/drm/nouveau/nv04_display.c      |  288 ++
>  drivers/gpu/drm/nouveau/nv04_fb.c           |   21 +
>  drivers/gpu/drm/nouveau/nv04_fbcon.c        |  316 ++
>  drivers/gpu/drm/nouveau/nv04_fifo.c         |  271 ++
>  drivers/gpu/drm/nouveau/nv04_graph.c        |  579 +++
>  drivers/gpu/drm/nouveau/nv04_instmem.c      |  208 +
>  drivers/gpu/drm/nouveau/nv04_mc.c           |   20 +
>  drivers/gpu/drm/nouveau/nv04_timer.c        |   51 +
>  drivers/gpu/drm/nouveau/nv04_tv.c           |  305 ++
>  drivers/gpu/drm/nouveau/nv10_fb.c           |   24 +
>  drivers/gpu/drm/nouveau/nv10_fifo.c         |  260 ++
>  drivers/gpu/drm/nouveau/nv10_graph.c        |  892 
>  drivers/gpu/drm/nouveau/nv17_gpio.c         |   92 +
>  drivers/gpu/drm/nouveau/nv17_tv.c           |  681 +++
>  drivers/gpu/drm/nouveau/nv17_tv.h           |  156 +
>  drivers/gpu/drm/nouveau/nv17_tv_modes.c     |  583 +++
>  drivers/gpu/drm/nouveau/nv20_graph.c        |  780 
>  drivers/gpu/drm/nouveau/nv40_fb.c           |   62 +
>  drivers/gpu/drm/nouveau/nv40_fifo.c         |  314 ++
>  drivers/gpu/drm/nouveau/nv40_graph.c        |  560 +++
>  drivers/gpu/drm/nouveau/nv40_mc.c           |   38 +
>  drivers/gpu/drm/nouveau/nv50_crtc.c         |  769 
>  drivers/gpu/drm

Re: [OOPS] Radeon KMS with 2.6.32 and agp not compiled in

[Francis Whittle]

This looks like an issue I've had related to the "backdoor entry" hack for
GART_IOMMU – Basically, amd64_agp doesn't utilise module_init or module_exit
when CONFIG_GART_IOMMU is enabled, instead stating:

drivers/char/agp/amd64-ag...@774-775:
/* On AMD64 the PCI driver needs to initialize this driver early


for the IOMMU, so it has to be called via a backdoor. */

This resulted, on my system, of the agpgart not being initialised despite
the module being loaded, and ultimately leads to the crash you describe
below.  My "fix" was to remove the #ifndef surrounding the module_init and
module_exit calls, however I'm not sure if this is the best way to approach
the issue (I have no idea what this backdoor mentioned *is*, and AFAIK it
all works for other drivers).

Regards,
Francis

2009/12/11 Johannes Hirte 

> When the agp driver is not compiled in but is build as module, the kernel
> oopes on modprobing radeon with modeset=1.
>
> Dec  7 22:08:53 datengrab kernel: BUG: unable to handle kernel NULL pointer
> dereference at 0074
> Dec  7 22:08:53 datengrab kernel: IP: []
> radeon_agp_init+0x18/0x23c [radeon]
> Dec  7 22:08:53 datengrab kernel: PGD 0
> Dec  7 22:08:53 datengrab kernel: Oops:  [#1] SMP
> Dec  7 22:08:53 datengrab kernel: last sysfs file:
> /sys/module/agpgart/initstate
> Dec  7 22:08:53 datengrab kernel: CPU 0
> Dec  7 22:08:53 datengrab kernel: Modules linked in: radeon(+) ttm
> drm_kms_helper drm i2c_algo_bit snd_seq_midi snd_emu10k1_synth
> snd_emux_synth snd_seq_virmidi snd_seq_midi_emul snd_seq_oss
> snd_seq_midi_event snd_seq snd_pcm_oss snd_mixer_oss aes_x86_64 aes_generic
> xts gf128mul dm_crypt snd_emu10k1 snd_rawmidi snd_ac97_codec ac97_bus
> snd_pcm snd_seq_device snd_timer snd_page_alloc snd_util_mem snd_hwdep
> ohci_hcd i2c_amd8111 uhci_hcd sg snd amd64_agp sata_sil k8temp agpgart
> i2c_amd756 sr_mod hwmon
> Dec  7 22:08:53 datengrab kernel: Pid: 2531, comm: work_for_cpu Not tainted
> 2.6.32 #2 To Be Filled By O.E.M.
> Dec  7 22:08:53 datengrab kernel: RIP: 0010:[]
>  [] radeon_agp_init+0x18/0x23c [radeon]
> Dec  7 22:08:53 datengrab kernel: RSP: 0018:8801172c3d80  EFLAGS:
> 00010282
> Dec  7 22:08:53 datengrab kernel: RAX:  RBX:
> 88011841 RCX: 88011fb97800
> Dec  7 22:08:53 datengrab kernel: RDX: c000 RSI:
>  RDI: 88011e43d800
> Dec  7 22:08:53 datengrab kernel: RBP:  R08:
> a0238201 R09: 8801172c3d90
> Dec  7 22:08:53 datengrab kernel: R10: 81589940 R11:
> 0400 R12: 88011fb97800
> Dec  7 22:08:53 datengrab kernel: R13: 0020 R14:
> a0243240 R15: 88011e43dbc0
> Dec  7 22:08:53 datengrab kernel: FS:  7f0e85a7f700()
> GS:88002820() knlGS:
> Dec  7 22:08:53 datengrab kernel: CS:  0010 DS: 0018 ES: 0018 CR0:
> 8005003b
> Dec  7 22:08:53 datengrab kernel: CR2: 0074 CR3:
> 01001000 CR4: 06f0
> Dec  7 22:08:53 datengrab kernel: DR0:  DR1:
>  DR2: 
> Dec  7 22:08:53 datengrab kernel: DR3:  DR6:
> 0ff0 DR7: 0400
> Dec  7 22:08:53 datengrab kernel: Process work_for_cpu (pid: 2531,
> threadinfo 8801172c2000, task 8801188d2280)
> Dec  7 22:08:53 datengrab kernel: Stack:
> Dec  7 22:08:53 datengrab kernel: 88011e43dbc0 813436f0
> 88010008 8801172c3df0
> Dec  7 22:08:53 datengrab kernel: <0> 8801172c3db0 0246
> 88011841 880118410144
> Dec  7 22:08:53 datengrab kernel: <0> 0282 88011841
>  88011fb97800
> Dec  7 22:08:53 datengrab kernel: Call Trace:
> Dec  7 22:08:53 datengrab kernel: [] ? printk+0x40/0x48
> Dec  7 22:08:53 datengrab kernel: [] ?
> r600_mc_init+0xf0/0x251 [radeon]
> Dec  7 22:08:53 datengrab kernel: [] ?
> r600_init+0x154/0x2b7 [radeon]
> Dec  7 22:08:53 datengrab kernel: [] ?
> radeon_device_init+0x1fe/0x276 [radeon]
> Dec  7 22:08:53 datengrab kernel: [] ?
> radeon_driver_load_kms+0xb2/0xec [radeon]
> Dec  7 22:08:53 datengrab kernel: [] ?
> drm_get_dev+0x322/0x42e [drm]
> Dec  7 22:08:53 datengrab kernel: [] ?
> do_work_for_cpu+0x0/0x1b
> Dec  7 22:08:53 datengrab kernel: [] ?
> local_pci_probe+0x12/0x16
> Dec  7 22:08:53 datengrab kernel: [] ?
> do_work_for_cpu+0xb/0x1b
> Dec  7 22:08:53 datengrab kernel: [] ? kthread+0x75/0x7d
> Dec  7 22:08:53 datengrab kernel: [] ? child_rip+0xa/0x20
> Dec  7 22:08:53 datengrab kernel: [] ? kthread+0x0/0x7d
> Dec  7 22:08:53 datengrab kernel: [] ? child_rip+0x0/0x20
> Dec  7 22:08:53 datengrab kernel: Code: 48 85 c0 74 0c 83 78 74 00 74 06 5a
> e9 c3 5e fa ff 58 c3 41 55 41 54 55 53 48 89 fb 48 83 ec 48 48 8b 7f 08 48
> 8b 87 48 03 00 00 <83> 78 74 00 75 1d e8 38 5e fa ff 

Re: [git pull] drm nouveau pony for Xmas.

[Stephane Marchesin]

2009/12/12 Dave Airlie :
> 2009/12/12 Stephane Marchesin :
> I did git log on the nouveau kernel tree nouveau dir with sort and uniq,
>
> I'm not sure where else I needed to trawl to get anymore ppl who have
> contributed to
> the KMS driver. I'm sure ppl contributed to X.org/Mesa drivers but
> this isn't the
> place for them. Also all copyright should be intact.
>

The problem is that when you moved from the drm to the linux tree, you
killed the whole history and the authors along.

> But we can add an author lists to the code subdir if you like, if
> someone compiles
> the complete list of ppl who have added code to the kernel driver.
>

That would indeed be the proper thing to do.

Stephane

--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm nouveau pony for Xmas.

[Stephane Marchesin]

On Sat, Dec 12, 2009 at 00:27, Stephane Marchesin
 wrote:
> 2009/12/12 Dave Airlie :
>> 2009/12/12 Stephane Marchesin :
>> I did git log on the nouveau kernel tree nouveau dir with sort and uniq,
>>
>> I'm not sure where else I needed to trawl to get anymore ppl who have
>> contributed to
>> the KMS driver. I'm sure ppl contributed to X.org/Mesa drivers but
>> this isn't the
>> place for them. Also all copyright should be intact.
>>
>
> The problem is that when you moved from the drm to the linux tree, you
> killed the whole history and the authors along.
>
>> But we can add an author lists to the code subdir if you like, if
>> someone compiles
>> the complete list of ppl who have added code to the kernel driver.
>>
>
> That would indeed be the proper thing to do.
>

Ok, as you requested here is a proper list of actual authors:

Arthur Huillet 
Anssi Hannula 
Ben Skeggs 
B. Rathmann 
Danny Tholen 
Dave Airlie 
Francisco Jerez 
Jeremy Kolb 
Maarten Maathuis 
Marcin Kościelnicki 
Matthew Garrett 
Matthieu Castet 
Matt Parnell 
Maurice van der Pot 
Patrice Mandin 
Pekka Paalanen 
Stephane Marchesin 
Stuart Bennett 
Xavier Chantry 

As far as I can recall, this list is complete.

Stephane

--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm nouveau pony for Xmas.

[Dave Airlie]

2009/12/12 Stephane Marchesin :
> 2009/12/11 Dave Airlie :
>>
>> Hi Linus,
>>
>> Please pull the 'drm-nouveau-pony' branch from
>> ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git 
>> drm-nouveau-pony
>>
>> This contains the nouveau driver with Kconfig under staging for now, the
>> code is going under drm because the upstream tree has it there, and it
>> makes passing patches a lot easier at least initially.
>>
>> Thanks to Ben Skeggs for doing overtime on his Friday evening to get the
>> ctxprogs ripped out and firmware loader support added. The firmware is
>> available elsewhere via the nouveau project linux git tree, and comes with
>> all the warnings mentioned about possible copyright issues.
>>
>> After this I also hope to merge the VMware virtual GPU kms driver early
>> next week which is also TTM based and going into staging.
>>
>> The driver alone is ~36,000 lines of code, which is bigger than most
>> subsystems we carry, so hopefully ppl realise the monumental scale of
>> writing a driver for these things.
>>
>> Dave.
>>
>>  drivers/gpu/drm/Makefile                    |    2 +
>>  drivers/gpu/drm/i2c/Makefile                |    4 +
>>  drivers/gpu/drm/i2c/ch7006_drv.c            |  531 +++
>>  drivers/gpu/drm/i2c/ch7006_mode.c           |  473 +++
>>  drivers/gpu/drm/i2c/ch7006_priv.h           |  344 ++
>>  drivers/gpu/drm/nouveau/Kconfig             |   44 +
>>  drivers/gpu/drm/nouveau/Makefile            |   31 +
>>  drivers/gpu/drm/nouveau/nouveau_acpi.c      |  125 +
>>  drivers/gpu/drm/nouveau/nouveau_backlight.c |  155 +
>>  drivers/gpu/drm/nouveau/nouveau_bios.c      | 6095 
>> +++
>>  drivers/gpu/drm/nouveau/nouveau_bios.h      |  289 ++
>>  drivers/gpu/drm/nouveau/nouveau_bo.c        |  671 +++
>>  drivers/gpu/drm/nouveau/nouveau_calc.c      |  478 +++
>>  drivers/gpu/drm/nouveau/nouveau_channel.c   |  468 ++
>>  drivers/gpu/drm/nouveau/nouveau_connector.c |  824 
>>  drivers/gpu/drm/nouveau/nouveau_connector.h |   54 +
>>  drivers/gpu/drm/nouveau/nouveau_crtc.h      |   95 +
>>  drivers/gpu/drm/nouveau/nouveau_debugfs.c   |  155 +
>>  drivers/gpu/drm/nouveau/nouveau_display.c   |  115 +
>>  drivers/gpu/drm/nouveau/nouveau_dma.c       |  206 +
>>  drivers/gpu/drm/nouveau/nouveau_dma.h       |  157 +
>>  drivers/gpu/drm/nouveau/nouveau_dp.c        |  569 +++
>>  drivers/gpu/drm/nouveau/nouveau_drv.c       |  405 ++
>>  drivers/gpu/drm/nouveau/nouveau_drv.h       | 1286 ++
>>  drivers/gpu/drm/nouveau/nouveau_encoder.h   |   91 +
>>  drivers/gpu/drm/nouveau/nouveau_fb.h        |   47 +
>>  drivers/gpu/drm/nouveau/nouveau_fbcon.c     |  380 ++
>>  drivers/gpu/drm/nouveau/nouveau_fbcon.h     |   47 +
>>  drivers/gpu/drm/nouveau/nouveau_fence.c     |  262 ++
>>  drivers/gpu/drm/nouveau/nouveau_gem.c       |  992 +
>>  drivers/gpu/drm/nouveau/nouveau_hw.c        | 1080 +
>>  drivers/gpu/drm/nouveau/nouveau_hw.h        |  455 ++
>>  drivers/gpu/drm/nouveau/nouveau_i2c.c       |  269 ++
>>  drivers/gpu/drm/nouveau/nouveau_i2c.h       |   52 +
>>  drivers/gpu/drm/nouveau/nouveau_ioc32.c     |   72 +
>>  drivers/gpu/drm/nouveau/nouveau_irq.c       |  702 +++
>>  drivers/gpu/drm/nouveau/nouveau_mem.c       |  568 +++
>>  drivers/gpu/drm/nouveau/nouveau_notifier.c  |  196 +
>>  drivers/gpu/drm/nouveau/nouveau_object.c    | 1294 ++
>>  drivers/gpu/drm/nouveau/nouveau_reg.h       |  836 
>>  drivers/gpu/drm/nouveau/nouveau_sgdma.c     |  321 ++
>>  drivers/gpu/drm/nouveau/nouveau_state.c     |  811 
>>  drivers/gpu/drm/nouveau/nouveau_ttm.c       |  131 +
>>  drivers/gpu/drm/nouveau/nv04_crtc.c         | 1002 +
>>  drivers/gpu/drm/nouveau/nv04_cursor.c       |   70 +
>>  drivers/gpu/drm/nouveau/nv04_dac.c          |  528 +++
>>  drivers/gpu/drm/nouveau/nv04_dfp.c          |  621 +++
>>  drivers/gpu/drm/nouveau/nv04_display.c      |  288 ++
>>  drivers/gpu/drm/nouveau/nv04_fb.c           |   21 +
>>  drivers/gpu/drm/nouveau/nv04_fbcon.c        |  316 ++
>>  drivers/gpu/drm/nouveau/nv04_fifo.c         |  271 ++
>>  drivers/gpu/drm/nouveau/nv04_graph.c        |  579 +++
>>  drivers/gpu/drm/nouveau/nv04_instmem.c      |  208 +
>>  drivers/gpu/drm/nouveau/nv04_mc.c           |   20 +
>>  drivers/gpu/drm/nouveau/nv04_timer.c        |   51 +
>>  drivers/gpu/drm/nouveau/nv04_tv.c           |  305 ++
>>  drivers/gpu/drm/nouveau/nv10_fb.c           |   24 +
>>  drivers/gpu/drm/nouveau/nv10_fifo.c         |  260 ++
>>  drivers/gpu/drm/nouveau/nv10_graph.c        |  892 
>>  drivers/gpu/drm/nouveau/nv17_gpio.c         |   92 +
>>  drivers/gpu/drm/nouveau/nv17_tv.c           |  681 +++
>>  drivers/gpu/drm/nouveau/nv17_tv.h           |  156 +
>>  drivers/gpu/drm/nouveau/nv17_tv_modes.c     |  583 +++
>>  drivers/gpu/drm/nouveau/nv20_graph.c        |  780 
>>  drivers/gpu/drm/nouveau/nv40_fb.c           |   62 +
>>  drivers/gpu/drm/nouveau/nv40_fifo.c         |  314 ++
>>  drivers/gpu/drm/nouveau/nv40_graph.c        |  560 +++
>>  dr

Re: [git pull] drm nouveau pony for Xmas.

[Linus Torvalds]

On Fri, 11 Dec 2009, Dave Airlie wrote:
> 
> Please pull the 'drm-nouveau-pony' branch from

PONIES! Yay! I lurve ponies!

And it works for me too. Needed to get the firmware from the fedora 
project, and make sure that it loads as a module rather than built in (so 
that it can find the firmware!), but other than those two gotchas (that 
are "obvious", but I needed to fail a couple of boots to hammer the point 
home) it all seems to work.

Thank you. The squeaky wheel _does_ get greased.

Linus

--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[RFC] Simplify GPU address space initialization

[Jerome Glisse]

Patch 1 is a fixed version of previous patch, lastest patch depends on it
Patch 2 is fixing up issue when we shutdown radeon modeule while not
everythings were initialized
Patch 3 does the address space code simplification, it should only change
r1xx-r5xx hw where it will put vram at pci bar address space. It
will also change behavior in front of tight pci address space.
(comment in patch describe the policy) i haven't yet done full
testing on all GPU (so far R3XX/R7XX AGP, RV515 PCIE). I post it
here so others can test too. Once i am done with more testing i
will report.


--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[PATCH 1/3] drm/radeon/kms: Check module arguments to be valid V2

[Jerome Glisse]

This patch add a function which check module argument to be
valid. On invalid argument it prints a warning and setback
the default value.

V2: Allow 0 for vram limit & agp mode which are the default
value

Signed-off-by: Jerome Glisse 
---
 drivers/gpu/drm/radeon/radeon_device.c |   73 +--
 1 files changed, 68 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index 02bcdb1..ff5a955 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -539,9 +539,72 @@ void radeon_agp_disable(struct radeon_device *rdev)
}
 }
 
-/*
- * Radeon device.
- */
+void radeon_check_arguments(struct radeon_device *rdev)
+{
+   /* vramlimit must be a power of two */
+   switch (radeon_vram_limit) {
+   case 0:
+   case 4:
+   case 8:
+   case 16:
+   case 32:
+   case 64:
+   case 128:
+   case 256:
+   case 512:
+   case 1024:
+   case 2048:
+   case 4096:
+   break;
+   default:
+   dev_warn(rdev->dev, "vram limit (%d) must be a power of 2\n",
+   radeon_vram_limit);
+   radeon_vram_limit = 0;
+   break;
+   }
+   radeon_vram_limit = radeon_vram_limit << 20;
+   /* gtt size must be power of two and greater or equal to 32M */
+   switch (radeon_gart_size) {
+   case 4:
+   case 8:
+   case 16:
+   dev_warn(rdev->dev, "gart size (%d) too small forcing to 
512M\n",
+   radeon_gart_size);
+   radeon_gart_size = 512;
+   break;
+   case 32:
+   case 64:
+   case 128:
+   case 256:
+   case 512:
+   case 1024:
+   case 2048:
+   case 4096:
+   break;
+   default:
+   dev_warn(rdev->dev, "gart size (%d) must be a power of 2\n",
+   radeon_gart_size);
+   radeon_gart_size = 512;
+   break;
+   }
+   rdev->mc.gtt_size = radeon_gart_size * 1024 * 1024;
+   /* AGP mode can only be -1, 1, 2, 4, 8 */
+   switch (radeon_agpmode) {
+   case -1:
+   case 0:
+   case 1:
+   case 2:
+   case 4:
+   case 8:
+   break;
+   default:
+   dev_warn(rdev->dev, "invalid AGP mode %d (valid mode: "
+   "-1, 0, 1, 2, 4, 8)\n", radeon_agpmode);
+   radeon_agpmode = 0;
+   break;
+   }
+}
+
 int radeon_device_init(struct radeon_device *rdev,
   struct drm_device *ddev,
   struct pci_dev *pdev,
@@ -580,9 +643,9 @@ int radeon_device_init(struct radeon_device *rdev,
 
/* Set asic functions */
r = radeon_asic_init(rdev);
-   if (r) {
+   if (r)
return r;
-   }
+   radeon_check_arguments(rdev);
 
if (rdev->flags & RADEON_IS_AGP && radeon_agpmode == -1) {
radeon_agp_disable(rdev);
-- 
1.6.5.2


--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[PATCH 3/3] drm/radeon/kms: Simplify GPU address space initialization V2

[Jerome Glisse]

This patch simplify the GPU address space initialization,
it always try to put VRAM at same address as the VRAM PCI BAR
Sadly it seems that the memory controller of radeon got too
many bugs to safely put it at others place (especialy on IGP).

This patch also kill some duplicated value and split vram size
into 2 different value the mc_vram_size which will always be the
true VRAM size of the GPU (unless we hit the AGP corner case).
While vram_size is the amount of VRAM we will use (it can be less
than mc_vram_size if we limit the VRAM size or for matching the
aperture size).

This cleanup is done as first pass before adding support for
unmapped VRAM.

V2: Simplify things somemore, now all hw & AGP should work.

Signed-off-by: Jerome Glisse 
---
 drivers/gpu/drm/radeon/r100.c   |   71 -
 drivers/gpu/drm/radeon/r300.c   |8 +-
 drivers/gpu/drm/radeon/r420.c   |   26 +-
 drivers/gpu/drm/radeon/r520.c   |4 +-
 drivers/gpu/drm/radeon/r600.c   |   65 ++--
 drivers/gpu/drm/radeon/radeon.h |   27 --
 drivers/gpu/drm/radeon/radeon_agp.c |2 +
 drivers/gpu/drm/radeon/radeon_device.c  |  154 ---
 drivers/gpu/drm/radeon/radeon_fb.c  |6 +-
 drivers/gpu/drm/radeon/radeon_gem.c |4 +-
 drivers/gpu/drm/radeon/radeon_legacy_crtc.c |2 +-
 drivers/gpu/drm/radeon/radeon_test.c|2 +-
 drivers/gpu/drm/radeon/radeon_ttm.c |   19 ++--
 drivers/gpu/drm/radeon/rs400.c  |   16 +--
 drivers/gpu/drm/radeon/rs600.c  |   27 ++---
 drivers/gpu/drm/radeon/rs690.c  |   26 ++---
 drivers/gpu/drm/radeon/rv515.c  |4 +-
 drivers/gpu/drm/radeon/rv770.c  |   45 ++---
 18 files changed, 196 insertions(+), 312 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 824cc64..9676a7c 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -200,9 +200,8 @@ int r100_pci_gart_enable(struct radeon_device *rdev)
tmp = RREG32(RADEON_AIC_CNTL) | RADEON_DIS_OUT_OF_PCI_GART_ACCESS;
WREG32(RADEON_AIC_CNTL, tmp);
/* set address range for PCI address translate */
-   WREG32(RADEON_AIC_LO_ADDR, rdev->mc.gtt_location);
-   tmp = rdev->mc.gtt_location + rdev->mc.gtt_size - 1;
-   WREG32(RADEON_AIC_HI_ADDR, tmp);
+   WREG32(RADEON_AIC_LO_ADDR, rdev->mc.gtt_start);
+   WREG32(RADEON_AIC_HI_ADDR, rdev->mc.gtt_end);
/* set PCI GART page-table base address */
WREG32(RADEON_AIC_PT_BASE, rdev->gart.table_addr);
tmp = RREG32(RADEON_AIC_CNTL) | RADEON_PCIGART_TRANSLATE_EN;
@@ -1881,44 +1880,25 @@ void r100_vram_init_sizes(struct radeon_device *rdev)
uint32_t tom;
/* read NB_TOM to get the amount of ram stolen for the GPU */
tom = RREG32(RADEON_NB_TOM);
-   rdev->mc.real_vram_size = (((tom >> 16) - (tom & 0x) + 1) 
<< 16);
+   rdev->mc.mc_vram_size = (((tom >> 16) - (tom & 0x) + 1) << 
16);
/* for IGPs we need to keep VRAM where it was put by the BIOS */
-   rdev->mc.vram_location = (tom & 0x) << 16;
-   WREG32(RADEON_CONFIG_MEMSIZE, rdev->mc.real_vram_size);
-   rdev->mc.mc_vram_size = rdev->mc.real_vram_size;
+   rdev->mc.vram_start = (tom & 0x) << 16;
+   WREG32(RADEON_CONFIG_MEMSIZE, rdev->mc.mc_vram_size);
} else {
-   rdev->mc.real_vram_size = RREG32(RADEON_CONFIG_MEMSIZE);
+   rdev->mc.mc_vram_size = RREG32(RADEON_CONFIG_MEMSIZE);
/* Some production boards of m6 will report 0
 * if it's 8 MB
 */
-   if (rdev->mc.real_vram_size == 0) {
-   rdev->mc.real_vram_size = 8192 * 1024;
-   WREG32(RADEON_CONFIG_MEMSIZE, rdev->mc.real_vram_size);
-   }
-   /* let driver place VRAM */
-   rdev->mc.vram_location = 0xUL;
-/* Fix for RN50, M6, M7 with 8/16/32(??) MBs of VRAM - 
- * Novell bug 204882 + along with lots of ubuntu ones */
-   if (config_aper_size > rdev->mc.real_vram_size)
-   rdev->mc.mc_vram_size = config_aper_size;
-   else
-   rdev->mc.mc_vram_size = rdev->mc.real_vram_size;
+   if (rdev->mc.mc_vram_size == 0) {
+   rdev->mc.mc_vram_size = 8192 * 1024;
+   WREG32(RADEON_CONFIG_MEMSIZE, rdev->mc.mc_vram_size);
+   }
}
-
/* work out accessible VRAM */
+   /* FIXME: take advantage of second aperture when it works */
accessible = r100_get_accessible_vram(rdev);
-
rdev->mc.aper_base = drm_get_resource_start(rdev->ddev, 0);
rdev->mc.aper_size = drm_get_

[PATCH 2/3] drm/radeon/kms: Avoid crash when trying to cleanup uninitialized structure

[Jerome Glisse]

Add boolean to record if some part of the driver are initialized or
not this allow to avoid a crash when trying to cleanup uninitialized
structure members.

Signed-off-by: Jerome Glisse 
---
 drivers/gpu/drm/radeon/radeon.h   |4 +++-
 drivers/gpu/drm/radeon/radeon_fence.c |9 ++---
 drivers/gpu/drm/radeon/radeon_ttm.c   |4 
 3 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 49bea93..baec009 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -162,6 +162,7 @@ struct radeon_fence_driver {
struct list_headcreated;
struct list_heademited;
struct list_headsignaled;
+   boolinitialized;
 };
 
 struct radeon_fence {
@@ -202,8 +203,9 @@ struct radeon_surface_reg {
 struct radeon_mman {
struct ttm_bo_global_refbo_global_ref;
struct ttm_global_reference mem_global_ref;
-   boolmem_global_referenced;
struct ttm_bo_devicebdev;
+   boolmem_global_referenced;
+   boolinitialized;
 };
 
 struct radeon_bo {
diff --git a/drivers/gpu/drm/radeon/radeon_fence.c 
b/drivers/gpu/drm/radeon/radeon_fence.c
index cb4cd97..4cdd8b4 100644
--- a/drivers/gpu/drm/radeon/radeon_fence.c
+++ b/drivers/gpu/drm/radeon/radeon_fence.c
@@ -324,7 +324,7 @@ int radeon_fence_driver_init(struct radeon_device *rdev)
write_lock_irqsave(&rdev->fence_drv.lock, irq_flags);
r = radeon_scratch_get(rdev, &rdev->fence_drv.scratch_reg);
if (r) {
-   DRM_ERROR("Fence failed to get a scratch register.");
+   dev_err(rdev->dev, "fence failed to get scratch register\n");
write_unlock_irqrestore(&rdev->fence_drv.lock, irq_flags);
return r;
}
@@ -335,9 +335,10 @@ int radeon_fence_driver_init(struct radeon_device *rdev)
INIT_LIST_HEAD(&rdev->fence_drv.signaled);
rdev->fence_drv.count_timeout = 0;
init_waitqueue_head(&rdev->fence_drv.queue);
+   rdev->fence_drv.initialized = true;
write_unlock_irqrestore(&rdev->fence_drv.lock, irq_flags);
if (radeon_debugfs_fence_init(rdev)) {
-   DRM_ERROR("Failed to register debugfs file for fence !\n");
+   dev_err(rdev->dev, "fence debugfs file creation failed\n");
}
return 0;
 }
@@ -346,11 +347,13 @@ void radeon_fence_driver_fini(struct radeon_device *rdev)
 {
unsigned long irq_flags;
 
+   if (!rdev->fence_drv.initialized)
+   return;
wake_up_all(&rdev->fence_drv.queue);
write_lock_irqsave(&rdev->fence_drv.lock, irq_flags);
radeon_scratch_free(rdev, rdev->fence_drv.scratch_reg);
write_unlock_irqrestore(&rdev->fence_drv.lock, irq_flags);
-   DRM_INFO("radeon: fence finalized\n");
+   rdev->fence_drv.initialized = false;
 }
 
 
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index d2ed896..310562a 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -482,6 +482,7 @@ int radeon_ttm_init(struct radeon_device *rdev)
DRM_ERROR("failed initializing buffer object driver(%d).\n", r);
return r;
}
+   rdev->mman.initialized = true;
r = ttm_bo_init_mm(&rdev->mman.bdev, TTM_PL_VRAM,
rdev->mc.real_vram_size >> PAGE_SHIFT);
if (r) {
@@ -529,6 +530,8 @@ void radeon_ttm_fini(struct radeon_device *rdev)
 {
int r;
 
+   if (!rdev->mman.initialized)
+   return;
if (rdev->stollen_vga_memory) {
r = radeon_bo_reserve(rdev->stollen_vga_memory, false);
if (r == 0) {
@@ -542,6 +545,7 @@ void radeon_ttm_fini(struct radeon_device *rdev)
ttm_bo_device_release(&rdev->mman.bdev);
radeon_gart_fini(rdev);
radeon_ttm_global_fini(rdev);
+   rdev->mman.initialized = false;
DRM_INFO("radeon: ttm finalized\n");
 }
 
-- 
1.6.5.2


--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Bug 23545] flashing textures in some maps of sauerbraten game

[bugzilla-daemon]

http://bugs.freedesktop.org/show_bug.cgi?id=23545





--- Comment #10 from Maciej Cencora   2009-12-11 12:01:54 
PST ---
If you're experiencing the same problem on intel hw then it could be a problem
in core Mesa. Unfortunately without some simple testcase I don't think we will
be able to track down and fix the bug.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Bug 25597] SIGSEGV in _radeon_bo_unref

[bugzilla-daemon]

http://bugs.freedesktop.org/show_bug.cgi?id=25597


David Ronis  changed:

   What|Removed |Added

  Component|Drivers/DRI/r200|Drivers/DRI/Radeon




-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Bug 25597] New: SIGSEGV in _radeon_bo_unref

[bugzilla-daemon]

http://bugs.freedesktop.org/show_bug.cgi?id=25597

   Summary: SIGSEGV in _radeon_bo_unref
   Product: Mesa
   Version: git
  Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: Drivers/DRI/r200
AssignedTo: dri-devel@lists.sourceforge.net
ReportedBy: david.ro...@mcgill.ca


I occasionally crash in the sauerbrauten game (even after the fix in bug
#25355); the problem seems to be game-map related.  I'm following the
git/master.  

I see the following on the console:

*WARN_ONCE*
File radeon_dma.c function radeonReleaseDmaRegions line 340
Leaking dma buffer object!
***


>From the backtrace it's clear that radeon_bo_unref is being passed a NULL
pointer.  My bet is that the culprit is radeonReleaseDmaRegions' calculation of
bo (like in bug 25355).

Here's the backtrace:

Program terminated with signal 11, Segmentation fault.
[New process 12045]
#0  0xb641a054 in _radeon_bo_unref (bo=0x0, file=0xb664c012 "radeon_dma.c", 
func=0xb664c353 "radeonReleaseDmaRegions", line=341)
at /usr/include/drm/radeon_bo.h:137
137 bo->cref--;

Thread 1 (process 12045):
#0  0xb641a054 in _radeon_bo_unref (bo=0x0, file=0xb664c012 "radeon_dma.c", 
func=0xb664c353 "radeonReleaseDmaRegions", line=341)
at /usr/include/drm/radeon_bo.h:137
No locals.
#1  0xb641b1d0 in radeonReleaseDmaRegions (rmesa=0x843b978) at radeon_dma.c:341
dma_bo = (struct radeon_dma_bo *) 0x843b994
temp = (struct radeon_dma_bo *) 0xcdacfd0
expire_at = 371036
time = 370936
__FUNCTION__ = "radeonReleaseDmaRegions"
#2  0xb6418b37 in rcommonFlushCmdBuf (rmesa=0x843b978, 
caller=0xb664bd88 "radeonFlush") at radeon_common.c:1201
ret = 138935784
#3  0xb641879f in radeonFlush (ctx=0x8440eb0) at radeon_common.c:1104
radeon = (radeonContextPtr) 0x843b978
__FUNCTION__ = "radeonFlush"
#4  0xb6414146 in radeon_firevertices (radeon=0x843b978) at radeon_cmdbuf.h:118
No locals.
#5  0xb6414984 in radeonDestroyContext (driContextPriv=0x84395b0)
at radeon_common_context.c:308
ctx = (GLcontext *) 0x8440eb0
radeon = (radeonContextPtr) 0x843b978
current = (radeonContextPtr) 0x843b978
__PRETTY_FUNCTION__ = "radeonDestroyContext"
__FUNCTION__ = "radeonDestroyContext"
#6  0xb63e259e in r200DestroyContext (driContextPriv=0x84395b0)
at r200_context.c:509
i = 6
rmesa = (r200ContextPtr) 0x843b978
#7  0xb63d9d2d in driDestroyContext (pcp=0x84395b0) at ../common/dri_util.c:546
No locals.
#8  0xb753e09e in driDestroyContext (context=0x8439880, psc=0x8438e18, 
dpy=0x83f59d0) at dri_glx.c:495
pcp = (__GLXDRIcontextPrivate *) 0x8439880
#9  0xb7506523 in DestroyContext (dpy=0x83f59d0, gc=0x8410ef8) at glxcmds.c:556
req = (xGLXDestroyContextReq *) 0xb73afff4
xid = 65011714
opcode = 151 '\227'
imported = 0 '\0'
#10 0xb7506687 in glXDestroyContext (dpy=0x83f59d0, gc=0x8410ef8)
at glxcmds.c:592
No locals.
#11 0xb76c01b4 in X11_GL_Shutdown () from /usr/lib/libSDL-1.2.so.0
No locals.
#12 0x08410ef8 in ?? ()
No symbol table info available.
#13 0x in ?? ()
No symbol table info available.
Current language:  auto; currently c


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[PATCH] drm/radeon/kms: Avoid crash when trying to cleanup uninitialized structure

[Jerome Glisse]

Add boolean to record if some part of the driver are initialized or
not this allow to avoid a crash when trying to cleanup uninitialized
structure members.

Signed-off-by: Jerome Glisse 
---
 drivers/gpu/drm/radeon/radeon.h   |4 +++-
 drivers/gpu/drm/radeon/radeon_fence.c |9 ++---
 drivers/gpu/drm/radeon/radeon_ttm.c   |4 
 3 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 1fd562f..d4c786f 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -162,6 +162,7 @@ struct radeon_fence_driver {
struct list_headcreated;
struct list_heademited;
struct list_headsignaled;
+   boolinitialized;
 };
 
 struct radeon_fence {
@@ -202,8 +203,9 @@ struct radeon_surface_reg {
 struct radeon_mman {
struct ttm_bo_global_refbo_global_ref;
struct ttm_global_reference mem_global_ref;
-   boolmem_global_referenced;
struct ttm_bo_devicebdev;
+   boolmem_global_referenced;
+   boolinitialized;
 };
 
 struct radeon_bo {
diff --git a/drivers/gpu/drm/radeon/radeon_fence.c 
b/drivers/gpu/drm/radeon/radeon_fence.c
index cb4cd97..4cdd8b4 100644
--- a/drivers/gpu/drm/radeon/radeon_fence.c
+++ b/drivers/gpu/drm/radeon/radeon_fence.c
@@ -324,7 +324,7 @@ int radeon_fence_driver_init(struct radeon_device *rdev)
write_lock_irqsave(&rdev->fence_drv.lock, irq_flags);
r = radeon_scratch_get(rdev, &rdev->fence_drv.scratch_reg);
if (r) {
-   DRM_ERROR("Fence failed to get a scratch register.");
+   dev_err(rdev->dev, "fence failed to get scratch register\n");
write_unlock_irqrestore(&rdev->fence_drv.lock, irq_flags);
return r;
}
@@ -335,9 +335,10 @@ int radeon_fence_driver_init(struct radeon_device *rdev)
INIT_LIST_HEAD(&rdev->fence_drv.signaled);
rdev->fence_drv.count_timeout = 0;
init_waitqueue_head(&rdev->fence_drv.queue);
+   rdev->fence_drv.initialized = true;
write_unlock_irqrestore(&rdev->fence_drv.lock, irq_flags);
if (radeon_debugfs_fence_init(rdev)) {
-   DRM_ERROR("Failed to register debugfs file for fence !\n");
+   dev_err(rdev->dev, "fence debugfs file creation failed\n");
}
return 0;
 }
@@ -346,11 +347,13 @@ void radeon_fence_driver_fini(struct radeon_device *rdev)
 {
unsigned long irq_flags;
 
+   if (!rdev->fence_drv.initialized)
+   return;
wake_up_all(&rdev->fence_drv.queue);
write_lock_irqsave(&rdev->fence_drv.lock, irq_flags);
radeon_scratch_free(rdev, rdev->fence_drv.scratch_reg);
write_unlock_irqrestore(&rdev->fence_drv.lock, irq_flags);
-   DRM_INFO("radeon: fence finalized\n");
+   rdev->fence_drv.initialized = false;
 }
 
 
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index cc310cc..74a6a9f 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -482,6 +482,7 @@ int radeon_ttm_init(struct radeon_device *rdev)
DRM_ERROR("failed initializing buffer object driver(%d).\n", r);
return r;
}
+   rdev->mman.initialized = true;
r = ttm_bo_init_mm(&rdev->mman.bdev, TTM_PL_VRAM,
rdev->mc.vram_size >> PAGE_SHIFT);
if (r) {
@@ -524,6 +525,8 @@ void radeon_ttm_fini(struct radeon_device *rdev)
 {
int r;
 
+   if (!rdev->mman.initialized)
+   return;
if (rdev->stollen_vga_memory) {
r = radeon_bo_reserve(rdev->stollen_vga_memory, false);
if (r == 0) {
@@ -537,6 +540,7 @@ void radeon_ttm_fini(struct radeon_device *rdev)
ttm_bo_device_release(&rdev->mman.bdev);
radeon_gart_fini(rdev);
radeon_ttm_global_fini(rdev);
+   rdev->mman.initialized = false;
DRM_INFO("radeon: ttm finalized\n");
 }
 
-- 
1.6.5.2


--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Bug 25580] [REGRESSION] drm/radeon/kms: [drm:radeon_fence_wait] *ERROR* fence(f6608d80:0x00000007) 510ms timeout

[bugzilla-daemon]

http://bugs.freedesktop.org/show_bug.cgi?id=25580





--- Comment #4 from Thomas Hellström   2009-12-11 
10:44:45 PST ---
What you're seeing is a probable GPU lockup.

It can't possibly have anything to do with the commit stated.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm

[Jeff Garzik]

On 12/11/2009 10:28 AM, Linus Torvalds wrote:
>
>
> On Fri, 11 Dec 2009, Jeff Garzik wrote:
>>
>> F11 uses nouveau here.  It is actually a pain to get 'nv' going as an
>> alternate -- bugs have been filed.  Makes kernel dev more difficult for me.  
>> I
>> was actually told, by Fedora people, that I should be hacking on the Fedora
>> (rpm-based) kernel, rather than a 100% upstream kernel like I have been
>> hacking/booting for the past decade, as a result of this setup (needing
>> nouveau kernel support, thus needing Fedora rather than upstream kernel).
>
> Btw, for all my ranting (and maybe Alan is right, and I'm ranting at the
> wrong people - it's just that the actual driver authors aren't the ones
> that violated any rules), I do have to give kudos for the fact that the
> F12 situation seems to be much better.
>
> These days, what you can do is basically do all development (assuming it's
> not nouveau development) in the upstream kernel, and then you just have a
> separate 'nouveau' git tree (or branch) that you pull in the nouvea stuff
> into.
>
> That tree/branch will be a mess of random merges-of-the-day, but you'll
> never push it out to anybody anyway, so nobody cares. And building that
> messy merge tree will get you a working setup without any extra steps - a
> simple "make modules_install ; make install" will JustWork(tm).

At the outset, I was hoping for an even more straightforward solution: 
"if nouveau kernel mod not present, fall back to nv"  That would work 
without any kernel modifications at all.

But the answer came back as "if you run Fedora, run a Fedora kernel, 
otherwise don't expect anything to work"  My experience directly 
contradicts claims of "upstream first" policy, both in code and attitude.

I am looking into doing the git tree merge you suggest right now  I 
didn't know that was an option, given ongoing API changes.  That would 
make my life quite a bit easier.  As you note, anything graphics is 
_glacially_ slow due to vesa fallback, when using a 100% upstream kernel.

Jeff



--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Bug 25580] [REGRESSION] drm/radeon/kms: [drm:radeon_fence_wait] *ERROR* fence(f6608d80:0x00000007) 510ms timeout

[bugzilla-daemon]

http://bugs.freedesktop.org/show_bug.cgi?id=25580





--- Comment #3 from Rafał Miłecki   2009-12-11 09:49:00 PST 
---
Created an attachment (id=31990)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=31990)
git bisect log

ec42a6e7dcfc2e9a92fad1c132bc9e110fafeb3f is the first bad commit
commit ec42a6e7dcfc2e9a92fad1c132bc9e110fafeb3f
Author: Dave Airlie 
Date:   Tue Dec 8 15:58:08 2009 +1000

drm/ttm: fix memory leak noticed by kmemleak.

If we don't need the zone we need to free it.

Acked-By: Thomas Hellstrom 
Signed-off-by: Dave Airlie 

:04 04 c65430b9f69957be4d0bc67be14c8deacfac58a9
f84a05852ae0b05680ca69bae650a389ce36e598 M  drivers


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Bug 25590] commit "drm: disable all the possible outputs/crtcs before entering KMS mode" introduces EDID errors

[bugzilla-daemon]

http://bugs.freedesktop.org/show_bug.cgi?id=25590





--- Comment #1 from Florian Scandella   2009-12-11 08:34:16 
PST ---
Created an attachment (id=31989)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=31989)
dmesg without EDID errors (commit reverted)


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Bug 25590] New: commit "drm: disable all the possible outputs/crtcs before entering KMS mode" introduces EDID errors

[bugzilla-daemon]

http://bugs.freedesktop.org/show_bug.cgi?id=25590

   Summary: commit "drm: disable all the possible outputs/crtcs
before entering KMS mode" introduces EDID errors
   Product: Mesa
   Version: git
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/DRI/R600
AssignedTo: dri-devel@lists.sourceforge.net
ReportedBy: f...@chilicode.com


Created an attachment (id=31988)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=31988)
dmesg with EDID errors

as a result of this screen resolution at boot time is messed up.

reverting the commit fixes the problem.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Bug 25483] Neverwinter nights lacks ram when using the radeon driver

[bugzilla-daemon]

http://bugs.freedesktop.org/show_bug.cgi?id=25483





--- Comment #11 from Jesús Guerrero   2009-12-11 08:23:00 
PST ---
Well, I will try that way then. Suggestions on a sane way to compile a 32 bit
mesa without hosing my 64 bit system are welcome, I'll check on the Gentoo
forum about that anyway.

Thanks. I'll report back.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm

[Linus Torvalds]

On Fri, 11 Dec 2009, Jeff Garzik wrote:
> 
> F11 uses nouveau here.  It is actually a pain to get 'nv' going as an
> alternate -- bugs have been filed.  Makes kernel dev more difficult for me.  I
> was actually told, by Fedora people, that I should be hacking on the Fedora
> (rpm-based) kernel, rather than a 100% upstream kernel like I have been
> hacking/booting for the past decade, as a result of this setup (needing
> nouveau kernel support, thus needing Fedora rather than upstream kernel).

Btw, for all my ranting (and maybe Alan is right, and I'm ranting at the 
wrong people - it's just that the actual driver authors aren't the ones 
that violated any rules), I do have to give kudos for the fact that the 
F12 situation seems to be much better.

These days, what you can do is basically do all development (assuming it's 
not nouveau development) in the upstream kernel, and then you just have a 
separate 'nouveau' git tree (or branch) that you pull in the nouvea stuff 
into.

That tree/branch will be a mess of random merges-of-the-day, but you'll 
never push it out to anybody anyway, so nobody cares. And building that 
messy merge tree will get you a working setup without any extra steps - a 
simple "make modules_install ; make install" will JustWork(tm).

So it's much more straightforward than it used to be (you had that 
separate tree that you could build modules in), you can basically build 
things exactly the same way you are supposed to do things _anyway_ if you 
have experimental branches etc and want to build in a temporary merged 
tree (even if you're not actually ready to merge it all and still want to 
keep the branches separate).

Of course, it's a good thing that it's easier in F12, because in F11 if 
you forgot to build the nouveau stuff, it would just fall back on the VESA 
FB setup - you had a working system, it was just very slow X. You could 
then build the nouveau modules you forgot about, and re-start X.

That "oops, I forgot" case seems to no longer work at all in F12 - if I 
build without Nouveau on my nvidia machine, the kernel will boot, but I 
will have neither working X _nor_ a working text login. So there's no way 
to even build the modules and fix it up - you have just to re-boot back 
into an old kernel. Very annoying for bisection.

Linus

--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Bug 25580] [REGRESSION] drm/radeon/kms: [drm:radeon_fence_wait] *ERROR* fence(f6608d80:0x00000007) 510ms timeout

[bugzilla-daemon]

http://bugs.freedesktop.org/show_bug.cgi?id=25580





--- Comment #2 from Alex Deucher   2009-12-11 07:29:08 PST ---
Can you bisect the problematic commit?


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Bug 25483] Neverwinter nights lacks ram when using the radeon driver

[bugzilla-daemon]

http://bugs.freedesktop.org/show_bug.cgi?id=25483





--- Comment #10 from Michel Dänzer   2009-12-11 07:20:53 
PST ---
(In reply to comment #9)
> I don't understand either why is the game running at all without the mesa
> driver that matches its bitness, but surely there's an easy explanation for
> that.

It's indirect rendering, libGL sends GLX protocol to the X server which uses
the 64 bit driver for hardware acceleration.

> So, do you think that the missing 32 bits r600_dri.so could be the root of 
> this
> problem?

If nothing else, with direct rendering you should get better performance, and
if the leak is still there it should be in the NWN process as opposed to the X
server, which should make it easier to track it down.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: PROBLEM: radeon, kernel => 2.6.32-rc6-git5, any mode switch on MacBookPro2, 2 is delayed by 130 seconds of black screen

[Alex Deucher]

On Fri, Dec 11, 2009 at 7:58 AM, Viktor Malyarchuk  wrote:
> Hi Alex,
>
> no change. Does not matter if "radeon.new_pll=1" or "radeon.new_pll=0".
> Delay is still there.

new_pll=1 is the default and the new code.  Can you send me your vbios?
(as root):
cd /sys/bus/pci/devices/
echo 1 > rom
cat rom > /tmp/vbios.rom
echo 0 > rom

Alex

>
> Best,
> Viktor
>
> On Thursday 10 December 2009 09:44:40 am Alex Deucher wrote:
>> On Tue, Dec 8, 2009 at 11:17 PM, Viktor Malyarchuk  wrote:
>> > Hi Alex,
>> >
>> > patch did not change anything for me. Problem still there.
>>
>> Can you try Dave's drm-radeon-testing or drm-radeon-next tree?
>> Specifically this patch:
>> http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;
>> h=b27b63750d912e80d61d2120c4a1664062d0f808
>>
>> Alex
>>
>> > Best,
>> > Viktor
>> >
>> > On Tuesday 08 December 2009 04:54:35 pm Alex Deucher wrote:
>> >> On Wed, Dec 2, 2009 at 7:51 AM, Viktor Malyarchuk 
> wrote:
>> >> > Hi Alex,
>> >> >
>> >> > I bisected drm-next branch from Dave's git tree
>> >> > git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git .
>> >> >
>> >> > The result is:
>> >> >
>> >> > ebbe1cb936dfc96d809ccf4d64a9755f8ba0c0ff is the first bad commit
>> >> > commit ebbe1cb936dfc96d809ccf4d64a9755f8ba0c0ff
>> >> > Author: Alex Deucher 
>> >> > Date:   Fri Oct 16 11:15:25 2009 -0400
>> >> >
>> >> >    drm/radeon/kms/atom: add support for spread spectrum (v2)
>> >> >
>> >> >    Spread spectrum is a periodic disturbance added
>> >> >    to the feedback divider to change the pixel clock
>> >> >    periodically to reduce interference.
>> >> >
>> >> >    Only enabled on LVDS.
>> >> >
>> >> >    v2: add support for r4xx and fix DCE 3
>> >> >
>> >> >    Signed-off-by: Alex Deucher 
>> >> >    Signed-off-by: Dave Airlie 
>> >> >
>> >> > :04 04 4cd7bdabeac245accf789e26e944aeb678fe1f16
>> >> >
>> >> > 077d0d318aed2f25464f9eeaffa39f33fa652909 M      drivers
>> >>
>> >> Can you try the patch I attached to bug 25506:
>> >> http://bugs.freedesktop.org/show_bug.cgi?id=25506
>> >>
>> >> Alex
>> >>
>> >> > Best,
>> >> > Viktor
>>
>

--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Bug 25483] Neverwinter nights lacks ram when using the radeon driver

[bugzilla-daemon]

http://bugs.freedesktop.org/show_bug.cgi?id=25483





--- Comment #9 from Jesús Guerrero   2009-12-11 06:48:46 PST 
---
The game is a 32 bit x86 binary blob, yes. There's absolutely no way to get it
in another format and I completely forgot about that while testing this. I
simply assumed that if it was working and I could see the 3d scenes then
everything should be on its place (specially, since this is a single k8 cpu,
not a multicore monster).

My OS is Gentoo x86_64, and the only dri file from mesa for r600 is this one:

  $ equery f mesa|grep 600
  /usr/lib64/dri/r600_dri.so

So I guess I might really be missing the 32 bits piece here. However, is that
really the only thing or do I need something else? I don't understand either
why is the game running at all without the mesa driver that matches its
bitness, but surely there's an easy explanation for that.

So, do you think that the missing 32 bits r600_dri.so could be the root of this
problem?


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Bug 25483] Neverwinter nights lacks ram when using the radeon driver

[bugzilla-daemon]

http://bugs.freedesktop.org/show_bug.cgi?id=25483


Michel Dänzer  changed:

   What|Removed |Added

 AssignedTo|xorg-driver-...@lists.x.org |dri-
   ||de...@lists.sourceforge.net
  Component|Driver/Radeon   |Drivers/DRI/R600
Product|xorg|Mesa
  QAContact|xorg-t...@lists.x.org   |
Version|7.4 |git




--- Comment #8 from Michel Dänzer   2009-12-11 06:13:40 PST 
---
AFAICT the messages are from the Mesa r600 driver. However, it's not clear how
they would result in growing memory usage of the X server - is NWN using direct
rendering? Presumably it's only available as a 32 bit binary, do you have a 32
bit r600 driver installed?


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[PATCH] drm/radeon/kms: If no placement is supplied fallback to system

[Jerome Glisse]

Do as we did before rework, if no placement is supplied at bo
creation time, fallback to allocating bo from system ram. This
will fix most of the creation failed issue report we got since
the rework get merged.

Signed-off-by: Jerome Glisse 
---
 drivers/gpu/drm/radeon/radeon_object.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
b/drivers/gpu/drm/radeon/radeon_object.c
index 544e18f..132130f 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -71,6 +71,8 @@ void radeon_ttm_placement_from_domain(struct radeon_bo *rbo, 
u32 domain)
rbo->placements[c++] = TTM_PL_MASK_CACHING | TTM_PL_FLAG_TT;
if (domain & RADEON_GEM_DOMAIN_CPU)
rbo->placements[c++] = TTM_PL_MASK_CACHING | TTM_PL_FLAG_SYSTEM;
+   if (!c)
+   rbo->placements[c++] = TTM_PL_MASK_CACHING | TTM_PL_FLAG_SYSTEM;
rbo->placement.num_placement = c;
rbo->placement.num_busy_placement = c;
 }
-- 
1.6.5.2


--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm

[Louise Hoffman]

Is the kernel really interested in code that could result in FUD?

Think of the whole SCO case, where Microsoft unquestionable funded the
law suites by buying Unix licenses at outrageous prices to harm Linux.
Microsoft would use the FUD as a weapon against Linux, if such code
got merged.

If questionable code is merged, uncertainty will not pay to the
kernels benefit as a whole.

There would be very good legal reasons for NOT using Linux, if such
code is merged.

Maybe it would be worth contacting nVidia. They might not even give a
damn about the microcode.

When open sourcing have come up, nVidia had this to say[0]:

-
- For competitive reasons on other platforms, I don't think we would
ever open source any of our cross-platform driver source code (which
is 90%+ of the Linux driver... see my earlier description of code
sharing). The Linux-specific pieces of the driver code base don't
really stand on their own, and generally need to change in sync with
the cross-platform code, so I don't believe it would be practical to
just open source the Linux-specific pieces.

- We have developed substantial IP in our graphics driver
that we do not want to expose.

- Unfortunately the vast majority of our documentation is created
solely for internal distribution. While at some point it may be
possible to release some of this information in pubic form it would be
quite a monumental effort to go through the vast amounts of internal
documents and repurpose them for external consumption.
-

So if someone could get in touch with Andy Ritger of nVidia and ask
him if this also holds for the microcode.
if: seek legal advice
else: merge



[0] http://www.phoronix.com/scan.php?page=article&item=nvidia_qa_linux&num=3

--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm

[tytso]

On Fri, Dec 11, 2009 at 08:20:57PM +1000, Dave Airlie wrote:
> 
> Well the main thing was I wasn't mean to discuss possible legal issues
> and still don't have permission, you know as well as I do once lawyers are
> involved you have to keep out of things until they deal with them.

The thing which really surprises me is that if there are legally
dubious issues, why on *earth* did Red Hat allow Fedora to ship said
code?

- Ted

--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm nouveau pony for Xmas.

[Mike Galbraith]

On Fri, 2009-12-11 at 11:57 +, Dave Airlie wrote:

> This driver is reverse engineered, and is in no way supported by nVidia.
> 
> Support for nearly the complete range of nvidia hw from nv04->g80 (nv50)
> is available, and the kms driver should support driving nearly all
> output types (displayport is under development still) along with 
> supporting
> suspend/resume.
> 
> This work is all from the upstream nouveau project found at
> nouveau.freedesktop.org.
> 
> The original authors list from nouveau git tree is:
> Anssi Hannula 
> Ben Skeggs 
> Francisco Jerez 
> Maarten Maathuis 
> Marcin Kościelnicki 
> Matthew Garrett 
> Matt Parnell 
> Patrice Mandin 
> Pekka Paalanen 
> Xavier Chantry 
> along with project founder Stephane Marchesin 
> 
> 
> Signed-off-by: Ben Skeggs 
> Signed-off-by: Dave Airlie 

Oh, so _that's_ what a noveau is.  Cool.  I've got a darn nvidia card,
and look forward to someday having eye-candy.. and being able to not
only suspend, but _resume_ too :)

-Mike


--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: PROBLEM: radeon, kernel => 2.6.32-rc6-git5, any mode switch on MacBookPro2, 2 is delayed by 130 seconds of black screen

[Viktor Malyarchuk]

Hi Alex,

no change. Does not matter if "radeon.new_pll=1" or "radeon.new_pll=0".
Delay is still there.

Best,
Viktor

On Thursday 10 December 2009 09:44:40 am Alex Deucher wrote:
> On Tue, Dec 8, 2009 at 11:17 PM, Viktor Malyarchuk  wrote:
> > Hi Alex,
> >
> > patch did not change anything for me. Problem still there.
> 
> Can you try Dave's drm-radeon-testing or drm-radeon-next tree?
> Specifically this patch:
> http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;
> h=b27b63750d912e80d61d2120c4a1664062d0f808
> 
> Alex
> 
> > Best,
> > Viktor
> >
> > On Tuesday 08 December 2009 04:54:35 pm Alex Deucher wrote:
> >> On Wed, Dec 2, 2009 at 7:51 AM, Viktor Malyarchuk  
wrote:
> >> > Hi Alex,
> >> >
> >> > I bisected drm-next branch from Dave's git tree
> >> > git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git .
> >> >
> >> > The result is:
> >> >
> >> > ebbe1cb936dfc96d809ccf4d64a9755f8ba0c0ff is the first bad commit
> >> > commit ebbe1cb936dfc96d809ccf4d64a9755f8ba0c0ff
> >> > Author: Alex Deucher 
> >> > Date:   Fri Oct 16 11:15:25 2009 -0400
> >> >
> >> >drm/radeon/kms/atom: add support for spread spectrum (v2)
> >> >
> >> >Spread spectrum is a periodic disturbance added
> >> >to the feedback divider to change the pixel clock
> >> >periodically to reduce interference.
> >> >
> >> >Only enabled on LVDS.
> >> >
> >> >v2: add support for r4xx and fix DCE 3
> >> >
> >> >Signed-off-by: Alex Deucher 
> >> >Signed-off-by: Dave Airlie 
> >> >
> >> > :04 04 4cd7bdabeac245accf789e26e944aeb678fe1f16
> >> >
> >> > 077d0d318aed2f25464f9eeaffa39f33fa652909 M  drivers
> >>
> >> Can you try the patch I attached to bug 25506:
> >> http://bugs.freedesktop.org/show_bug.cgi?id=25506
> >>
> >> Alex
> >>
> >> > Best,
> >> > Viktor
> 

--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm nouveau pony for Xmas.

[Mike Galbraith]

On Fri, 2009-12-11 at 11:57 +, Dave Airlie wrote:
> Hi Linus,
> 
> Please pull the 'drm-nouveau-pony' branch from
> ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git 
> drm-nouveau-pony
> 
> This contains the nouveau driver with Kconfig under staging for now, the 
> code is going under drm because the upstream tree has it there, and it
> makes passing patches a lot easier at least initially.
> 
> Thanks to Ben Skeggs for doing overtime on his Friday evening to get the 
> ctxprogs ripped out and firmware loader support added. The firmware is 
> available elsewhere via the nouveau project linux git tree, and comes with 
> all the warnings mentioned about possible copyright issues.
> 
> After this I also hope to merge the VMware virtual GPU kms driver early 
> next week which is also TTM based and going into staging.
> 
> The driver alone is ~36,000 lines of code, which is bigger than most 
> subsystems we carry, so hopefully ppl realise the monumental scale of
> writing a driver for these things.
> 
> Dave.
> 
>  drivers/gpu/drm/Makefile|2 +
>  drivers/gpu/drm/i2c/Makefile|4 +
>  drivers/gpu/drm/i2c/ch7006_drv.c|  531 +++
>  drivers/gpu/drm/i2c/ch7006_mode.c   |  473 +++
>  drivers/gpu/drm/i2c/ch7006_priv.h   |  344 ++
>  drivers/gpu/drm/nouveau/Kconfig |   44 +
>  drivers/gpu/drm/nouveau/Makefile|   31 +
>  drivers/gpu/drm/nouveau/nouveau_acpi.c  |  125 +
>  drivers/gpu/drm/nouveau/nouveau_backlight.c |  155 +
>  drivers/gpu/drm/nouveau/nouveau_bios.c  | 6095 
> +++
>  drivers/gpu/drm/nouveau/nouveau_bios.h  |  289 ++
>  drivers/gpu/drm/nouveau/nouveau_bo.c|  671 +++
>  drivers/gpu/drm/nouveau/nouveau_calc.c  |  478 +++
>  drivers/gpu/drm/nouveau/nouveau_channel.c   |  468 ++
>  drivers/gpu/drm/nouveau/nouveau_connector.c |  824 
>  drivers/gpu/drm/nouveau/nouveau_connector.h |   54 +
>  drivers/gpu/drm/nouveau/nouveau_crtc.h  |   95 +
>  drivers/gpu/drm/nouveau/nouveau_debugfs.c   |  155 +
>  drivers/gpu/drm/nouveau/nouveau_display.c   |  115 +
>  drivers/gpu/drm/nouveau/nouveau_dma.c   |  206 +
>  drivers/gpu/drm/nouveau/nouveau_dma.h   |  157 +
>  drivers/gpu/drm/nouveau/nouveau_dp.c|  569 +++
>  drivers/gpu/drm/nouveau/nouveau_drv.c   |  405 ++
>  drivers/gpu/drm/nouveau/nouveau_drv.h   | 1286 ++
>  drivers/gpu/drm/nouveau/nouveau_encoder.h   |   91 +
>  drivers/gpu/drm/nouveau/nouveau_fb.h|   47 +
>  drivers/gpu/drm/nouveau/nouveau_fbcon.c |  380 ++
>  drivers/gpu/drm/nouveau/nouveau_fbcon.h |   47 +
>  drivers/gpu/drm/nouveau/nouveau_fence.c |  262 ++
>  drivers/gpu/drm/nouveau/nouveau_gem.c   |  992 +
>  drivers/gpu/drm/nouveau/nouveau_hw.c| 1080 +
>  drivers/gpu/drm/nouveau/nouveau_hw.h|  455 ++
>  drivers/gpu/drm/nouveau/nouveau_i2c.c   |  269 ++
>  drivers/gpu/drm/nouveau/nouveau_i2c.h   |   52 +
>  drivers/gpu/drm/nouveau/nouveau_ioc32.c |   72 +
>  drivers/gpu/drm/nouveau/nouveau_irq.c   |  702 +++
>  drivers/gpu/drm/nouveau/nouveau_mem.c   |  568 +++
>  drivers/gpu/drm/nouveau/nouveau_notifier.c  |  196 +
>  drivers/gpu/drm/nouveau/nouveau_object.c| 1294 ++
>  drivers/gpu/drm/nouveau/nouveau_reg.h   |  836 
>  drivers/gpu/drm/nouveau/nouveau_sgdma.c |  321 ++
>  drivers/gpu/drm/nouveau/nouveau_state.c |  811 
>  drivers/gpu/drm/nouveau/nouveau_ttm.c   |  131 +
>  drivers/gpu/drm/nouveau/nv04_crtc.c | 1002 +
>  drivers/gpu/drm/nouveau/nv04_cursor.c   |   70 +
>  drivers/gpu/drm/nouveau/nv04_dac.c  |  528 +++
>  drivers/gpu/drm/nouveau/nv04_dfp.c  |  621 +++
>  drivers/gpu/drm/nouveau/nv04_display.c  |  288 ++
>  drivers/gpu/drm/nouveau/nv04_fb.c   |   21 +
>  drivers/gpu/drm/nouveau/nv04_fbcon.c|  316 ++
>  drivers/gpu/drm/nouveau/nv04_fifo.c |  271 ++
>  drivers/gpu/drm/nouveau/nv04_graph.c|  579 +++
>  drivers/gpu/drm/nouveau/nv04_instmem.c  |  208 +
>  drivers/gpu/drm/nouveau/nv04_mc.c   |   20 +
>  drivers/gpu/drm/nouveau/nv04_timer.c|   51 +
>  drivers/gpu/drm/nouveau/nv04_tv.c   |  305 ++
>  drivers/gpu/drm/nouveau/nv10_fb.c   |   24 +
>  drivers/gpu/drm/nouveau/nv10_fifo.c |  260 ++
>  drivers/gpu/drm/nouveau/nv10_graph.c|  892 
>  drivers/gpu/drm/nouveau/nv17_gpio.c |   92 +
>  drivers/gpu/drm/nouveau/nv17_tv.c   |  681 +++
>  drivers/gpu/drm/nouveau/nv17_tv.h   |  156 +
>  drivers/gpu/drm/nouveau/nv17_tv_modes.c |  583 +++
>  drivers/gpu/drm/nouveau/nv20_graph.c|  780 
>  drivers/gpu/drm/nouveau/nv40_fb.c   |   62 +
>  drivers/gpu/drm/nouveau/nv40_fifo.c |  314 ++
>  drivers/gpu/drm/nouveau/nv40_graph.c|  560 +++
>  drivers/gpu/drm/nouveau/nv40_mc.c   |   38 +
>  drivers/gpu/drm/nouveau/nv50_crtc.

Re: [git pull] drm

[Alan Cox]

On Fri, 11 Dec 2009 07:45:41 -0500
ty...@mit.edu wrote:

> On Fri, Dec 11, 2009 at 08:20:57PM +1000, Dave Airlie wrote:
> > 
> > Well the main thing was I wasn't mean to discuss possible legal issues
> > and still don't have permission, you know as well as I do once lawyers are
> > involved you have to keep out of things until they deal with them.
> 
> The thing which really surprises me is that if there are legally
> dubious issues, why on *earth* did Red Hat allow Fedora to ship said
> code?

The thing which really surprises me is that if there are legal questions
involved why on *earth* do people keep asking them on public mailing
lists when they know the lawyers views/opinions/decisions will not be
publishable there ?

Ted, you of all people know that if you want to get an answer that isn't
the way to get it.

Alan

--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[git pull] drm nouveau pony for Xmas.

[Dave Airlie]

Hi Linus,

Please pull the 'drm-nouveau-pony' branch from
ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git 
drm-nouveau-pony

This contains the nouveau driver with Kconfig under staging for now, the 
code is going under drm because the upstream tree has it there, and it
makes passing patches a lot easier at least initially.

Thanks to Ben Skeggs for doing overtime on his Friday evening to get the 
ctxprogs ripped out and firmware loader support added. The firmware is 
available elsewhere via the nouveau project linux git tree, and comes with 
all the warnings mentioned about possible copyright issues.

After this I also hope to merge the VMware virtual GPU kms driver early 
next week which is also TTM based and going into staging.

The driver alone is ~36,000 lines of code, which is bigger than most 
subsystems we carry, so hopefully ppl realise the monumental scale of
writing a driver for these things.

Dave.

 drivers/gpu/drm/Makefile|2 +
 drivers/gpu/drm/i2c/Makefile|4 +
 drivers/gpu/drm/i2c/ch7006_drv.c|  531 +++
 drivers/gpu/drm/i2c/ch7006_mode.c   |  473 +++
 drivers/gpu/drm/i2c/ch7006_priv.h   |  344 ++
 drivers/gpu/drm/nouveau/Kconfig |   44 +
 drivers/gpu/drm/nouveau/Makefile|   31 +
 drivers/gpu/drm/nouveau/nouveau_acpi.c  |  125 +
 drivers/gpu/drm/nouveau/nouveau_backlight.c |  155 +
 drivers/gpu/drm/nouveau/nouveau_bios.c  | 6095 +++
 drivers/gpu/drm/nouveau/nouveau_bios.h  |  289 ++
 drivers/gpu/drm/nouveau/nouveau_bo.c|  671 +++
 drivers/gpu/drm/nouveau/nouveau_calc.c  |  478 +++
 drivers/gpu/drm/nouveau/nouveau_channel.c   |  468 ++
 drivers/gpu/drm/nouveau/nouveau_connector.c |  824 
 drivers/gpu/drm/nouveau/nouveau_connector.h |   54 +
 drivers/gpu/drm/nouveau/nouveau_crtc.h  |   95 +
 drivers/gpu/drm/nouveau/nouveau_debugfs.c   |  155 +
 drivers/gpu/drm/nouveau/nouveau_display.c   |  115 +
 drivers/gpu/drm/nouveau/nouveau_dma.c   |  206 +
 drivers/gpu/drm/nouveau/nouveau_dma.h   |  157 +
 drivers/gpu/drm/nouveau/nouveau_dp.c|  569 +++
 drivers/gpu/drm/nouveau/nouveau_drv.c   |  405 ++
 drivers/gpu/drm/nouveau/nouveau_drv.h   | 1286 ++
 drivers/gpu/drm/nouveau/nouveau_encoder.h   |   91 +
 drivers/gpu/drm/nouveau/nouveau_fb.h|   47 +
 drivers/gpu/drm/nouveau/nouveau_fbcon.c |  380 ++
 drivers/gpu/drm/nouveau/nouveau_fbcon.h |   47 +
 drivers/gpu/drm/nouveau/nouveau_fence.c |  262 ++
 drivers/gpu/drm/nouveau/nouveau_gem.c   |  992 +
 drivers/gpu/drm/nouveau/nouveau_hw.c| 1080 +
 drivers/gpu/drm/nouveau/nouveau_hw.h|  455 ++
 drivers/gpu/drm/nouveau/nouveau_i2c.c   |  269 ++
 drivers/gpu/drm/nouveau/nouveau_i2c.h   |   52 +
 drivers/gpu/drm/nouveau/nouveau_ioc32.c |   72 +
 drivers/gpu/drm/nouveau/nouveau_irq.c   |  702 +++
 drivers/gpu/drm/nouveau/nouveau_mem.c   |  568 +++
 drivers/gpu/drm/nouveau/nouveau_notifier.c  |  196 +
 drivers/gpu/drm/nouveau/nouveau_object.c| 1294 ++
 drivers/gpu/drm/nouveau/nouveau_reg.h   |  836 
 drivers/gpu/drm/nouveau/nouveau_sgdma.c |  321 ++
 drivers/gpu/drm/nouveau/nouveau_state.c |  811 
 drivers/gpu/drm/nouveau/nouveau_ttm.c   |  131 +
 drivers/gpu/drm/nouveau/nv04_crtc.c | 1002 +
 drivers/gpu/drm/nouveau/nv04_cursor.c   |   70 +
 drivers/gpu/drm/nouveau/nv04_dac.c  |  528 +++
 drivers/gpu/drm/nouveau/nv04_dfp.c  |  621 +++
 drivers/gpu/drm/nouveau/nv04_display.c  |  288 ++
 drivers/gpu/drm/nouveau/nv04_fb.c   |   21 +
 drivers/gpu/drm/nouveau/nv04_fbcon.c|  316 ++
 drivers/gpu/drm/nouveau/nv04_fifo.c |  271 ++
 drivers/gpu/drm/nouveau/nv04_graph.c|  579 +++
 drivers/gpu/drm/nouveau/nv04_instmem.c  |  208 +
 drivers/gpu/drm/nouveau/nv04_mc.c   |   20 +
 drivers/gpu/drm/nouveau/nv04_timer.c|   51 +
 drivers/gpu/drm/nouveau/nv04_tv.c   |  305 ++
 drivers/gpu/drm/nouveau/nv10_fb.c   |   24 +
 drivers/gpu/drm/nouveau/nv10_fifo.c |  260 ++
 drivers/gpu/drm/nouveau/nv10_graph.c|  892 
 drivers/gpu/drm/nouveau/nv17_gpio.c |   92 +
 drivers/gpu/drm/nouveau/nv17_tv.c   |  681 +++
 drivers/gpu/drm/nouveau/nv17_tv.h   |  156 +
 drivers/gpu/drm/nouveau/nv17_tv_modes.c |  583 +++
 drivers/gpu/drm/nouveau/nv20_graph.c|  780 
 drivers/gpu/drm/nouveau/nv40_fb.c   |   62 +
 drivers/gpu/drm/nouveau/nv40_fifo.c |  314 ++
 drivers/gpu/drm/nouveau/nv40_graph.c|  560 +++
 drivers/gpu/drm/nouveau/nv40_mc.c   |   38 +
 drivers/gpu/drm/nouveau/nv50_crtc.c |  769 
 drivers/gpu/drm/nouveau/nv50_cursor.c   |  156 +
 drivers/gpu/drm/nouveau/nv50_dac.c  |  304 ++
 drivers/gpu/drm/nouveau/nv50_display.c  | 1015 +
 drivers/gpu/drm/nouveau/nv50_display.h  |   46 +

[git pull] drm pull - drm core prep for nouveau

[Dave Airlie]

Hi Linus,

Please pull the 'drm-linus' branch from
ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus

These are some fixups to the TTM API required to pull the nouveau and vmware
drivers into staging, along with a typo in radeon code.

Dave.

 drivers/gpu/drm/radeon/radeon_drv.c|2 +-
 drivers/gpu/drm/radeon/radeon_object.c |   39 ++---
 drivers/gpu/drm/ttm/ttm_bo.c   |  134 ++-
 include/drm/ttm/ttm_bo_api.h   |   63 +++
 4 files changed, 101 insertions(+), 137 deletions(-)

commit d1ede145cea25c5b6d2ebb19b167af14e374bb45
Author: Ben Skeggs 
Date:   Fri Dec 11 15:13:00 2009 +1000

drm/ttm: export some functions useful to drivers using ttm

These are functions required by nouveau which will be merged later.

Signed-off-by: Ben Skeggs 
Signed-off-by: Dave Airlie 

commit 9062fa6612958f35f41379425bcae9c9b4ccd68e
Author: Alex Deucher 
Date:   Wed Dec 9 19:38:58 2009 -0500

drm/radeon/kms/avivo: fix typo in new_pll module description

Signed-off-by: Alex Deucher 
Signed-off-by: Dave Airlie 

commit 1fb107fc46692a000533da3d6904ac28b6b3148d
Author: Jerome Glisse 
Date:   Thu Dec 10 17:16:28 2009 +0100

drm/radeon/kms: Convert radeon to new ttm_bo_init

Now bo init use placement structure like bo validation does.

Signed-off-by: Jerome Glisse 
Signed-off-by: Dave Airlie 

commit 09855acb1c2e3779f25317ec9a8ffe1b1784a4a8
Author: Jerome Glisse 
Date:   Thu Dec 10 17:16:27 2009 +0100

drm/ttm: Convert ttm_buffer_object_init to use ttm_placement

Convert ttm_buffer_object_init to use struct ttm_placement and
rename to ttm_bo_init for consistency with function naming. This
allow to give more complex placement at buffer creation. For
instance you ask to allocate bo into vram first but if there is
not enough vram you can give system as a second possible
placement. It also allow to create buffer in a specific range.

Also rename ttm_buffer_object_validate to ttm_bo_validate.

Signed-off-by: Jerome Glisse 
Signed-off-by: Dave Airlie 

--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm

[Andy Walls]

On Fri, 2009-12-11 at 11:02 +0100, Stephane Marchesin wrote:
> On Fri, Dec 11, 2009 at 00:58, Alan Cox  wrote:

> > It's really simple: if you want to merge it *you* pull it and sign it off.
> > If you aren't prepared to do that then ask why Fedora should, its not
> > their code either.

> So what, if someone outside RedHat is ok to sign it off, it can go
> into staging? If it's that simple I don't mind signing it off
> (including the dubious bits), I can take the blame if that helps
> things move forward.

Could not a NAK by the author stop that?

Regards,
Andy


--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm

[Andy Walls]

On Fri, 2009-12-11 at 01:34 -0800, David Miller wrote:
> From: Alan Cox 
> Date: Fri, 11 Dec 2009 09:18:43 +

> > You also
> > previously said you don't want to merge stuff when the authors don't want
> > it merged.

> However, one point remains is that we were told, by Dave Airlie, that
> they didn't want this code merged because the one person being paid to
> work on it "would be overwhelmed" if the code went upstream.
> 
> I distinctly remember this being mentioned at the kernel summit.

That reason for not merging seems to fall squarely in the "authors don't
want it merged" category.

Your point does highlight, though, that it is worth talking to the
author directly to understand the obstacles, as Alan mentioned.

Regards,
Andy


--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm

[Dave Airlie]

On Fri, Dec 11, 2009 at 8:28 PM, Jeff Garzik  wrote:
> On 12/11/2009 04:18 AM, Alan Cox wrote:
>>
>> F11 certainly shipped some bits of it for 2D support. I am not sure if
>> F10 shipped a purely userspace set up. Neither had it enabled as the
>> default driver - they used "nv" or "vesa" depending upon the card.
>
> F11 uses nouveau here.  It is actually a pain to get 'nv' going as an
> alternate -- bugs have been filed.  Makes kernel dev more difficult for me.
>  I was actually told, by Fedora people, that I should be hacking on the
> Fedora (rpm-based) kernel, rather than a 100% upstream kernel like I have
> been hacking/booting for the past decade, as a result of this setup (needing
> nouveau kernel support, thus needing Fedora rather than upstream kernel).

It wouldn't have helped the ABI was broken between F11 and now, so you'd be
in the same boat putting this code upstream via staging in no way
means you can run
it with the F11 userspace or ongoing even with the F12 one.

Dave.

>
>        Jeff
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm

[Jeff Garzik]

On 12/11/2009 04:18 AM, Alan Cox wrote:
> F11 certainly shipped some bits of it for 2D support. I am not sure if
> F10 shipped a purely userspace set up. Neither had it enabled as the
> default driver - they used "nv" or "vesa" depending upon the card.

F11 uses nouveau here.  It is actually a pain to get 'nv' going as an 
alternate -- bugs have been filed.  Makes kernel dev more difficult for 
me.  I was actually told, by Fedora people, that I should be hacking on 
the Fedora (rpm-based) kernel, rather than a 100% upstream kernel like I 
have been hacking/booting for the past decade, as a result of this setup 
(needing nouveau kernel support, thus needing Fedora rather than 
upstream kernel).

Jeff



--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm

[Dave Airlie]

On Fri, Dec 11, 2009 at 7:34 PM, David Miller  wrote:
> From: Alan Cox 
> Date: Fri, 11 Dec 2009 09:18:43 +
>
>> However the fundamental point stands. The only people who can sign it off
>> are the people who wrote it. Those are the rules. Red Hat didn't write the
>> code, Red Hat cannot sign it off however much you rant at them. You also
>> previously said you don't want to merge stuff when the authors don't want
>> it merged.
>
> I agree with a lot of what you say.
>
> However, one point remains is that we were told, by Dave Airlie, that
> they didn't want this code merged because the one person being paid to
> work on it "would be overwhelmed" if the code went upstream.
>
> I distinctly remember this being mentioned at the kernel summit.
>
> And you know what?  That kind of excuse pisses me off too :-)

Well the main thing was I wasn't mean to discuss possible legal issues
and still don't have permission, you know as well as I do once lawyers are
involved you have to keep out of things until they deal with them.

but yes it is a side effect of upstreaming this code that other
distros will start
to place time demands on people who Red Hat employ but we were
starting to see that anyways without upstreaming. It would be have
been really nice
if some of the distros would start to put their money behind what they
want to ship instead of rhetoric[1].

Dave.

[1] http://www.markshuttleworth.com/archives/95

--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm

[Stephane Marchesin]

On Fri, Dec 11, 2009 at 00:58, Alan Cox  wrote:
>> But not only is Fedora not following the rules,
>
> You changed the rules. You require a Signed-off-by:. Fedora can no more
> add a signed off by than you can. It's not their code nor Red Hat's code
> any more than they "own" the kernel because they pay someone to work on
> it.
>
>> See above. It's not you. It's Fedora. If Fedora hadn't merged Nouveau and
>> shipped it, I wouldn't care.
>
> And zillions of Nvidia users would have been worse off.
>
> It's really simple: if you want to merge it *you* pull it and sign it off.
> If you aren't prepared to do that then ask why Fedora should, its not
> their code either.
>

So what, if someone outside RedHat is ok to sign it off, it can go
into staging? If it's that simple I don't mind signing it off
(including the dubious bits), I can take the blame if that helps
things move forward.

Stephane

--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm

[David Miller]

From: Alan Cox 
Date: Fri, 11 Dec 2009 09:18:43 +

> However the fundamental point stands. The only people who can sign it off
> are the people who wrote it. Those are the rules. Red Hat didn't write the
> code, Red Hat cannot sign it off however much you rant at them. You also
> previously said you don't want to merge stuff when the authors don't want
> it merged.

I agree with a lot of what you say.

However, one point remains is that we were told, by Dave Airlie, that
they didn't want this code merged because the one person being paid to
work on it "would be overwhelmed" if the code went upstream.

I distinctly remember this being mentioned at the kernel summit.

And you know what?  That kind of excuse pisses me off too :-)

--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm

[Alan Cox]

> I realize that you have some emotional attachments to Red Hat, but ask 
> yourself (and answer honestly): what would you think if some random other 
> distro was packaging tens of thousands of lines of kernel code and not 
> apparently working at trying to get them upstream?

Like Ubuntu does for a load of stuff and did for years ? I'd like to see
stuff get upstream yes. The point you seem to be missing is you are
ranting at the wrong people. I want to see it upstream too, but if you
must shout at people do it productively at the right target.

I would be cross if they were controlling and hiding it, but its sitting
in a public repository, its maintained by a collection of people one of
whom happens to work for Red Hat and anyone can grab it. It's vastly
easier to get hold of than the userspace for some of the stuff in kernel.

However the fundamental point stands. The only people who can sign it off
are the people who wrote it. Those are the rules. Red Hat didn't write the
code, Red Hat cannot sign it off however much you rant at them. You also
previously said you don't want to merge stuff when the authors don't want
it merged. If you like I can also dig out some Torvalds quotes about not
wanting to dictate to distros.

If you want to progress this then

- Starting talking to the project *authors*
- Help them decide what to do about the firmware stuff
- If need be get the Linux Foundation, Red Hat and other relevant lawyers
  and people on a phone call with you so that legal issues can get
  discussed and you can shout at them as necessary too.

I am not privy to what the lawyers think on this one. But I'd bet that
the only way you'll get a full answer is in conjunction with lawyers
speaking to lawyers, and the only way you'll get a sign off is when the
lawyers say "yes". Anything else would be rather irresponsible.

> And it's possible that other distros are doing the same thing. I happen to 
> know that Fedora does it (and has been doing it for at least a year), 
> because I happen to have an Intel development machine that runs Fedora and 

F11 certainly shipped some bits of it for 2D support. I am not sure if
F10 shipped a purely userspace set up. Neither had it enabled as the
default driver - they used "nv" or "vesa" depending upon the card.

> was shipped by Intel with an nVidia card (and has a power supply that 
> craps out if you don't use several hundred watts of power, so I can't 
> change it to something more power-efficient - seriously).

Alan

--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [RFC] TTM change buffer_object_init to use ttm_placement rather than flag

[Jerome Glisse]

On Thu, Dec 10, 2009 at 08:51:07PM +0100, Thomas Hellstrom wrote:
> Jerome Glisse wrote:
> > Hi,
> >
> > So here is a patch which convert bo_init to use struct ttm_placement
> > rather than flag. It allow the driver to give placement preference
> > on where to create a bo. Also allow to create a bo at specific range
> > which is i believe somethings nouveau would like to see :)
> >
> > Aside from the change i renamed ttm_buffer_object_init|validate to
> > ttm_bo_init|validate this is shorter but also more consistent with
> > others functions naming. For consistency i would like to rename
> > struct ttm_buffer_object to struct ttm_bo but this lead to massive
> > regular expression abuse for everyone using ttm so before proposing
> > a patch let me know if you like or not this. I haven't strong
> > feeling on that except that this would allow to stay in the 80 line
> > lenght in some place.
> >
> > Cheers,
> > Jerome
> >
> >   
> Jerome, this looks good and consistent with previous changes.
> 
> In order to get the vmwgfx driver ready for upstream in the not too 
> distant future we need a (temporarily) stable API. Is this patch 
> targeted for 2.6.33?
> 
> /Thomas
> 

I think i will do the massive rename for 2.6.34 so i am will be
in charge of converting other driver, rather than putting any more
burden on others driver. It's not very important it's just
cleanup.

Cheers.
Jerome

--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Bug 25580] [REGRESSION] drm/radeon/kms: [drm:radeon_fence_wait] *ERROR* fence(f6608d80:0x00000007) 510ms timeout

[bugzilla-daemon]

http://bugs.freedesktop.org/show_bug.cgi?id=25580





--- Comment #1 from Rafał Miłecki   2009-12-11 00:34:49 PST 
---
Created an attachment (id=31970)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=31970)
dmesg from starting X

[   44.039173] [drm:radeon_fence_wait] *ERROR* fence(f6608d80:0x0007) 510ms
timeout going to reset GPU
[   44.039200] radeon :01:00.0: GPU softreset 
[   44.039220] radeon :01:00.0:   R_008010_GRBM_STATUS=0xA0003030
[   44.039242] radeon :01:00.0:   R_008014_GRBM_STATUS2=0x0003
[   44.039263] radeon :01:00.0:   R_000E50_SRBM_STATUS=0x20C0
[   44.039289] radeon :01:00.0:   R_008020_GRBM_SOFT_RESET=0x7FEE
[   44.039360] radeon :01:00.0: R_008020_GRBM_SOFT_RESET=0x0001
[   44.039446] radeon :01:00.0:   R_000E60_SRBM_SOFT_RESET=0x0402


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Bug 25580] New: [REGRESSION] drm/radeon/kms: [drm:radeon_fence_wait] *ERROR* fence(f6608d80:0x00000007) 510ms timeout

[bugzilla-daemon]

http://bugs.freedesktop.org/show_bug.cgi?id=25580

   Summary: [REGRESSION] drm/radeon/kms: [drm:radeon_fence_wait]
*ERROR* fence(f6608d80:0x0007) 510ms timeout
   Product: DRI
   Version: unspecified
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel@lists.sourceforge.net
ReportedBy: zaj...@gmail.com


Day after splitting branches by Dave I switched to drm-radeon-testing and was
using it successfully. Yesterday I did pull last changes and now my machine
locks up in 70% tries of starting X.

Unfortunately I did "dmegs > dmesg.log" so I didn't catch messages before
netconsole loading... Are attached messages enough?

Sony VAIO FW11S
M82 == RV620


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel