Re: [PATCH] drm/prime: drop reference on imported dma-buf come from gem
fwiw, I had a similar patch:
https://patchwork.kernel.org/patch/1229161/
although it was on top of some locking fixes from Daniel (which I
think are also needed):
https://patchwork.kernel.org/patch/1227251/
although that seemed to cause/trigger some explosions which I think
still need to be debugged..
BR,
-R
On Thu, Sep 27, 2012 at 8:30 AM, Seung-Woo Kim wrote:
> Increasing ref counts of both dma-buf and gem for imported dma-buf come from
> gem
> makes memory leak. release function of dma-buf cannot be called because
> f_count
> of dma-buf increased by importing gem and gem ref count cannot be decrease
> because of exported dma-buf.
>
> So I add dma_buf_put() for imported gem come from its own gem into each
> drivers
> having prime_import and prime_export capabilities. With this, only gem ref
> count is increased if importing gem exported from gem of same driver.
>
> Signed-off-by: Seung-Woo Kim
> Signed-off-by: Kyungmin.park
> Cc: Inki Dae
> Cc: Daniel Vetter
> Cc: Rob Clark
> Cc: Alex Deucher
> ---
> drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |5 +
> drivers/gpu/drm/i915/i915_gem_dmabuf.c |5 +
> drivers/gpu/drm/nouveau/nouveau_prime.c|1 +
> drivers/gpu/drm/radeon/radeon_prime.c |1 +
> drivers/staging/omapdrm/omap_gem_dmabuf.c |5 +
> 5 files changed, 17 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
> b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
> index ae13feb..b0897c9 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
> @@ -211,7 +211,12 @@ struct drm_gem_object *exynos_dmabuf_prime_import(struct
> drm_device *drm_dev,
>
> /* is it from our device? */
> if (obj->dev == drm_dev) {
> + /*
> +* Importing dmabuf exported from out own gem
> increases
> +* refcount on gem itself instead of f_count of
> dmabuf.
> +*/
> drm_gem_object_reference(obj);
> + dma_buf_put(dma_buf);
> return obj;
> }
> }
> diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> index aa308e1..32e6287 100644
> --- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> +++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> @@ -188,7 +188,12 @@ struct drm_gem_object *i915_gem_prime_import(struct
> drm_device *dev,
> obj = dma_buf->priv;
> /* is it from our device? */
> if (obj->base.dev == dev) {
> + /*
> +* Importing dmabuf exported from out own gem
> increases
> +* refcount on gem itself instead of f_count of
> dmabuf.
> +*/
> drm_gem_object_reference(&obj->base);
> + dma_buf_put(dma_buf);
> return &obj->base;
> }
> }
> diff --git a/drivers/gpu/drm/nouveau/nouveau_prime.c
> b/drivers/gpu/drm/nouveau/nouveau_prime.c
> index a25cf2c..bb653c6 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_prime.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_prime.c
> @@ -199,6 +199,7 @@ struct drm_gem_object *nouveau_gem_prime_import(struct
> drm_device *dev,
> if (nvbo->gem) {
> if (nvbo->gem->dev == dev) {
> drm_gem_object_reference(nvbo->gem);
> + dma_buf_put(dma_buf);
> return nvbo->gem;
> }
> }
> diff --git a/drivers/gpu/drm/radeon/radeon_prime.c
> b/drivers/gpu/drm/radeon/radeon_prime.c
> index 6bef46a..d344a3be 100644
> --- a/drivers/gpu/drm/radeon/radeon_prime.c
> +++ b/drivers/gpu/drm/radeon/radeon_prime.c
> @@ -195,6 +195,7 @@ struct drm_gem_object *radeon_gem_prime_import(struct
> drm_device *dev,
> bo = dma_buf->priv;
> if (bo->gem_base.dev == dev) {
> drm_gem_object_reference(&bo->gem_base);
> + dma_buf_put(dma_buf);
> return &bo->gem_base;
> }
> }
> diff --git a/drivers/staging/omapdrm/omap_gem_dmabuf.c
> b/drivers/staging/omapdrm/omap_gem_dmabuf.c
> index 42728e0..5b50eb6 100644
> --- a/drivers/staging/omapdrm/omap_gem_dmabuf.c
> +++ b/drivers/staging/omapdrm/omap_gem_dmabuf.c
> @@ -207,7 +207,12 @@ struct drm_gem_object * omap_gem_prime_import(struct
> drm_device *dev,
> obj = buffer->priv;
> /* is it from our device? */
> if (obj->dev == dev) {
> + /*
> +* Importing dmabuf exported from out own gem
> increases
> +* refcount on gem itself instead of f_count of
> dmabuf.
> +
RE: inux-next: Tree for Sept 26 (not bootable on AMD64: thermal|acpi|drm/i915|pci related?)
On 四, 2012-09-27 at 00:11 -0600, R, Durgadoss wrote: > Hi Rui, > > > > -Original Message- > > From: Zhang, Rui > > Sent: Thursday, September 27, 2012 11:38 AM > > To: Hugh Dickins > > Cc: Sedat Dilek; Stephen Rothwell; Andrew Morton; Dan Carpenter; R, > > Durgadoss; linux-n...@vger.kernel.org; linux-ker...@vger.kernel.org; > > Rafael J. Wysocki; Dave Airlie; Daniel Vetter; Linux ACPI; linux- > > p...@vger.kernel.org; DRI; Bjorn Helgaas > > Subject: Re: inux-next: Tree for Sept 26 (not bootable on AMD64: > > thermal|acpi|drm/i915|pci related?) > > > > Hi, hugh, > > > > On 三, 2012-09-26 at 12:51 -0700, Hugh Dickins wrote: > > > On Wed, 26 Sep 2012, Sedat Dilek wrote: > > > > > > > > on my Ubuntu/precise AMD64 today's Linux-Next runs into the following > > > > call-trace (machine freezes): > > > > > > > > Sep 26 19:22:58 fambox kernel: [ 11.124739] BUG: unable to handle > > > > kernel NULL pointer dereference at 0018 > > > > Sep 26 19:22:58 fambox kernel: [ 11.124806] IP: [] > > > > thermal_cooling_device_register+0x2c8/0x3d0 > > > > Sep 26 19:22:58 fambox kernel: [ 11.124869] PGD 0 > > > > Sep 26 19:22:58 fambox kernel: [ 11.124895] Oops: [#1] SMP > > > > Sep 26 19:22:58 fambox kernel: [ 11.124919] Modules linked in: > > > > coretemp kvm_intel kvm snd_hda_intel(+) arc4 snd_hda_codec iwldvm > > > > snd_hwdep ghash_clmulni_intel snd_pcm aesni_intel uvcvideo mac80211 > > > > aes_x86_64 snd_page_alloc ablk_helper i915(+) snd_seq_midi cryptd > > > > videobuf2_vmalloc snd_seq_midi_event xts videobuf2_memops lrw > > > > snd_rawmidi videobuf2_core joydev gf128mul videodev snd_seq > > > > snd_seq_device hid_generic snd_timer drm_kms_helper iwlwifi drm snd > > > > psmouse i2c_algo_bit soundcore btusb microcode serio_raw > > > > samsung_laptop wmi cfg80211 bluetooth mei mac_hid video lpc_ich lp > > > > parport ext4 jbd2 usbhid hid r8169 > > > > Sep 26 19:22:58 fambox kernel: [ 11.125319] CPU 2 > > > > Sep 26 19:22:58 fambox kernel: [ 11.125332] Pid: 579, comm: modprobe > > > > Not tainted 3.6.0-rc7-next20120926-2-iniza-generic #1 SAMSUNG > > > > ELECTRONICS CO., LTD. > > 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH > > > > Sep 26 19:22:58 fambox kernel: [ 11.125401] RIP: > > > > 0010:[] [] > > > > thermal_cooling_device_register+0x2c8/0x3d0 > > > > Sep 26 19:22:58 fambox kernel: [ 11.125450] RSP: > > > > 0018:88010f23d838 EFLAGS: 00010246 > > > > Sep 26 19:22:58 fambox kernel: [ 11.125475] RAX: > > > > RBX: 88010bfd4c00 RCX: 0001 > > > > Sep 26 19:22:58 fambox kernel: [ 11.125507] RDX: > > > > RSI: 0282 RDI: 0282 > > > > Sep 26 19:22:58 fambox kernel: [ 11.125539] RBP: 88010f23d878 > > > > R08: R09: 0001 > > > > Sep 26 19:22:58 fambox kernel: [ 11.125570] R10: 8801054fc460 > > > > R11: R12: 88010bfd4c04 > > > > Sep 26 19:22:58 fambox kernel: [ 11.125602] R13: 88011a73e000 > > > > R14: R15: > > > > Sep 26 19:22:58 fambox kernel: [ 11.125634] FS: > > > > 7f6b8da29700() GS:88011fa8() > > > > knlGS: > > > > Sep 26 19:22:58 fambox kernel: [ 11.125670] CS: 0010 DS: ES: > > > > CR0: 80050033 > > > > Sep 26 19:22:58 fambox kernel: [ 11.125697] CR2: 0018 > > > > CR3: 000110185000 CR4: 000407e0 > > > > Sep 26 19:22:58 fambox kernel: [ 11.125729] DR0: > > > > DR1: DR2: > > > > Sep 26 19:22:58 fambox kernel: [ 11.125761] DR3: > > > > DR6: 0ff0 DR7: 0400 > > > > Sep 26 19:22:58 fambox kernel: [ 11.125793] Process modprobe (pid: > > > > 579, threadinfo 88010f23c000, task 880116648000) > > > > Sep 26 19:22:58 fambox kernel: [ 11.127133] Stack: > > > > Sep 26 19:22:58 fambox kernel: [ 11.128461] 88011a5d9098 > > > > 88010d74c300 88010f23d878 880110b06480 > > > > Sep 26 19:22:58 fambox kernel: [ 11.129755] 88010bfd1000 > > > > 88011a5d9098 88010d74c300 88011a625000 > > > > Sep 26 19:22:58 fambox kernel: [ 11.130943] 88010f23d958 > > > > a00e5868 811fa033 > > > > Sep 26 19:22:58 fambox kernel: [ 11.132749] Call Trace: > > > > Sep 26 19:22:58 fambox kernel: [ 11.133939] [] > > > > acpi_video_bus_add+0x9ba/0xce6 [video] > > > > Sep 26 19:22:58 fambox kernel: [ 11.135130] [] ? > > > > sysfs_addrm_finish+0x33/0xc0 > > > > Sep 26 19:22:58 fambox kernel: [ 11.136313] [] > > > > acpi_device_probe+0x4e/0x11c > > > > Sep 26 19:22:58 fambox kernel: [ 11.137482] [] > > > > driver_probe_device+0x7b/0x240 > > > > Sep 26 19:22:58 fambox kernel: [ 11.138642] [] > > > > __driver_attach+0xab/0xb0 > > > > Sep 26 19:22:58 fambox kernel: [ 11.139798] [] ? > > > > driver_probe_device+0x240/0x240 > > > > Sep 26 19:22:58 fambox kernel: [ 1
RE: inux-next: Tree for Sept 26 (not bootable on AMD64: thermal|acpi|drm/i915|pci related?)
Hi Rui, > -Original Message- > From: Zhang, Rui > Sent: Thursday, September 27, 2012 11:38 AM > To: Hugh Dickins > Cc: Sedat Dilek; Stephen Rothwell; Andrew Morton; Dan Carpenter; R, > Durgadoss; linux-n...@vger.kernel.org; linux-ker...@vger.kernel.org; > Rafael J. Wysocki; Dave Airlie; Daniel Vetter; Linux ACPI; linux- > p...@vger.kernel.org; DRI; Bjorn Helgaas > Subject: Re: inux-next: Tree for Sept 26 (not bootable on AMD64: > thermal|acpi|drm/i915|pci related?) > > Hi, hugh, > > On 三, 2012-09-26 at 12:51 -0700, Hugh Dickins wrote: > > On Wed, 26 Sep 2012, Sedat Dilek wrote: > > > > > > on my Ubuntu/precise AMD64 today's Linux-Next runs into the following > > > call-trace (machine freezes): > > > > > > Sep 26 19:22:58 fambox kernel: [ 11.124739] BUG: unable to handle > > > kernel NULL pointer dereference at 0018 > > > Sep 26 19:22:58 fambox kernel: [ 11.124806] IP: [] > > > thermal_cooling_device_register+0x2c8/0x3d0 > > > Sep 26 19:22:58 fambox kernel: [ 11.124869] PGD 0 > > > Sep 26 19:22:58 fambox kernel: [ 11.124895] Oops: [#1] SMP > > > Sep 26 19:22:58 fambox kernel: [ 11.124919] Modules linked in: > > > coretemp kvm_intel kvm snd_hda_intel(+) arc4 snd_hda_codec iwldvm > > > snd_hwdep ghash_clmulni_intel snd_pcm aesni_intel uvcvideo mac80211 > > > aes_x86_64 snd_page_alloc ablk_helper i915(+) snd_seq_midi cryptd > > > videobuf2_vmalloc snd_seq_midi_event xts videobuf2_memops lrw > > > snd_rawmidi videobuf2_core joydev gf128mul videodev snd_seq > > > snd_seq_device hid_generic snd_timer drm_kms_helper iwlwifi drm snd > > > psmouse i2c_algo_bit soundcore btusb microcode serio_raw > > > samsung_laptop wmi cfg80211 bluetooth mei mac_hid video lpc_ich lp > > > parport ext4 jbd2 usbhid hid r8169 > > > Sep 26 19:22:58 fambox kernel: [ 11.125319] CPU 2 > > > Sep 26 19:22:58 fambox kernel: [ 11.125332] Pid: 579, comm: modprobe > > > Not tainted 3.6.0-rc7-next20120926-2-iniza-generic #1 SAMSUNG > > > ELECTRONICS CO., LTD. > 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH > > > Sep 26 19:22:58 fambox kernel: [ 11.125401] RIP: > > > 0010:[] [] > > > thermal_cooling_device_register+0x2c8/0x3d0 > > > Sep 26 19:22:58 fambox kernel: [ 11.125450] RSP: > > > 0018:88010f23d838 EFLAGS: 00010246 > > > Sep 26 19:22:58 fambox kernel: [ 11.125475] RAX: > > > RBX: 88010bfd4c00 RCX: 0001 > > > Sep 26 19:22:58 fambox kernel: [ 11.125507] RDX: > > > RSI: 0282 RDI: 0282 > > > Sep 26 19:22:58 fambox kernel: [ 11.125539] RBP: 88010f23d878 > > > R08: R09: 0001 > > > Sep 26 19:22:58 fambox kernel: [ 11.125570] R10: 8801054fc460 > > > R11: R12: 88010bfd4c04 > > > Sep 26 19:22:58 fambox kernel: [ 11.125602] R13: 88011a73e000 > > > R14: R15: > > > Sep 26 19:22:58 fambox kernel: [ 11.125634] FS: > > > 7f6b8da29700() GS:88011fa8() > > > knlGS: > > > Sep 26 19:22:58 fambox kernel: [ 11.125670] CS: 0010 DS: ES: > > > CR0: 80050033 > > > Sep 26 19:22:58 fambox kernel: [ 11.125697] CR2: 0018 > > > CR3: 000110185000 CR4: 000407e0 > > > Sep 26 19:22:58 fambox kernel: [ 11.125729] DR0: > > > DR1: DR2: > > > Sep 26 19:22:58 fambox kernel: [ 11.125761] DR3: > > > DR6: 0ff0 DR7: 0400 > > > Sep 26 19:22:58 fambox kernel: [ 11.125793] Process modprobe (pid: > > > 579, threadinfo 88010f23c000, task 880116648000) > > > Sep 26 19:22:58 fambox kernel: [ 11.127133] Stack: > > > Sep 26 19:22:58 fambox kernel: [ 11.128461] 88011a5d9098 > > > 88010d74c300 88010f23d878 880110b06480 > > > Sep 26 19:22:58 fambox kernel: [ 11.129755] 88010bfd1000 > > > 88011a5d9098 88010d74c300 88011a625000 > > > Sep 26 19:22:58 fambox kernel: [ 11.130943] 88010f23d958 > > > a00e5868 811fa033 > > > Sep 26 19:22:58 fambox kernel: [ 11.132749] Call Trace: > > > Sep 26 19:22:58 fambox kernel: [ 11.133939] [] > > > acpi_video_bus_add+0x9ba/0xce6 [video] > > > Sep 26 19:22:58 fambox kernel: [ 11.135130] [] ? > > > sysfs_addrm_finish+0x33/0xc0 > > > Sep 26 19:22:58 fambox kernel: [ 11.136313] [] > > > acpi_device_probe+0x4e/0x11c > > > Sep 26 19:22:58 fambox kernel: [ 11.137482] [] > > > driver_probe_device+0x7b/0x240 > > > Sep 26 19:22:58 fambox kernel: [ 11.138642] [] > > > __driver_attach+0xab/0xb0 > > > Sep 26 19:22:58 fambox kernel: [ 11.139798] [] ? > > > driver_probe_device+0x240/0x240 > > > Sep 26 19:22:58 fambox kernel: [ 11.140981] [] > > > bus_for_each_dev+0x56/0x90 > > > Sep 26 19:22:58 fambox kernel: [ 11.142129] [] > > > driver_attach+0x1e/0x20 > > > Sep 26 19:22:58 fambox kernel: [ 11.143264] [] > > > bus_add_driver+0x190/0x290 > > > Sep 26 19
Re: inux-next: Tree for Sept 26 (not bootable on AMD64: thermal|acpi|drm/i915|pci related?)
Hi, hugh, On 三, 2012-09-26 at 12:51 -0700, Hugh Dickins wrote: > On Wed, 26 Sep 2012, Sedat Dilek wrote: > > > > on my Ubuntu/precise AMD64 today's Linux-Next runs into the following > > call-trace (machine freezes): > > > > Sep 26 19:22:58 fambox kernel: [ 11.124739] BUG: unable to handle > > kernel NULL pointer dereference at 0018 > > Sep 26 19:22:58 fambox kernel: [ 11.124806] IP: [] > > thermal_cooling_device_register+0x2c8/0x3d0 > > Sep 26 19:22:58 fambox kernel: [ 11.124869] PGD 0 > > Sep 26 19:22:58 fambox kernel: [ 11.124895] Oops: [#1] SMP > > Sep 26 19:22:58 fambox kernel: [ 11.124919] Modules linked in: > > coretemp kvm_intel kvm snd_hda_intel(+) arc4 snd_hda_codec iwldvm > > snd_hwdep ghash_clmulni_intel snd_pcm aesni_intel uvcvideo mac80211 > > aes_x86_64 snd_page_alloc ablk_helper i915(+) snd_seq_midi cryptd > > videobuf2_vmalloc snd_seq_midi_event xts videobuf2_memops lrw > > snd_rawmidi videobuf2_core joydev gf128mul videodev snd_seq > > snd_seq_device hid_generic snd_timer drm_kms_helper iwlwifi drm snd > > psmouse i2c_algo_bit soundcore btusb microcode serio_raw > > samsung_laptop wmi cfg80211 bluetooth mei mac_hid video lpc_ich lp > > parport ext4 jbd2 usbhid hid r8169 > > Sep 26 19:22:58 fambox kernel: [ 11.125319] CPU 2 > > Sep 26 19:22:58 fambox kernel: [ 11.125332] Pid: 579, comm: modprobe > > Not tainted 3.6.0-rc7-next20120926-2-iniza-generic #1 SAMSUNG > > ELECTRONICS CO., LTD. 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH > > Sep 26 19:22:58 fambox kernel: [ 11.125401] RIP: > > 0010:[] [] > > thermal_cooling_device_register+0x2c8/0x3d0 > > Sep 26 19:22:58 fambox kernel: [ 11.125450] RSP: > > 0018:88010f23d838 EFLAGS: 00010246 > > Sep 26 19:22:58 fambox kernel: [ 11.125475] RAX: > > RBX: 88010bfd4c00 RCX: 0001 > > Sep 26 19:22:58 fambox kernel: [ 11.125507] RDX: > > RSI: 0282 RDI: 0282 > > Sep 26 19:22:58 fambox kernel: [ 11.125539] RBP: 88010f23d878 > > R08: R09: 0001 > > Sep 26 19:22:58 fambox kernel: [ 11.125570] R10: 8801054fc460 > > R11: R12: 88010bfd4c04 > > Sep 26 19:22:58 fambox kernel: [ 11.125602] R13: 88011a73e000 > > R14: R15: > > Sep 26 19:22:58 fambox kernel: [ 11.125634] FS: > > 7f6b8da29700() GS:88011fa8() > > knlGS: > > Sep 26 19:22:58 fambox kernel: [ 11.125670] CS: 0010 DS: ES: > > CR0: 80050033 > > Sep 26 19:22:58 fambox kernel: [ 11.125697] CR2: 0018 > > CR3: 000110185000 CR4: 000407e0 > > Sep 26 19:22:58 fambox kernel: [ 11.125729] DR0: > > DR1: DR2: > > Sep 26 19:22:58 fambox kernel: [ 11.125761] DR3: > > DR6: 0ff0 DR7: 0400 > > Sep 26 19:22:58 fambox kernel: [ 11.125793] Process modprobe (pid: > > 579, threadinfo 88010f23c000, task 880116648000) > > Sep 26 19:22:58 fambox kernel: [ 11.127133] Stack: > > Sep 26 19:22:58 fambox kernel: [ 11.128461] 88011a5d9098 > > 88010d74c300 88010f23d878 880110b06480 > > Sep 26 19:22:58 fambox kernel: [ 11.129755] 88010bfd1000 > > 88011a5d9098 88010d74c300 88011a625000 > > Sep 26 19:22:58 fambox kernel: [ 11.130943] 88010f23d958 > > a00e5868 811fa033 > > Sep 26 19:22:58 fambox kernel: [ 11.132749] Call Trace: > > Sep 26 19:22:58 fambox kernel: [ 11.133939] [] > > acpi_video_bus_add+0x9ba/0xce6 [video] > > Sep 26 19:22:58 fambox kernel: [ 11.135130] [] ? > > sysfs_addrm_finish+0x33/0xc0 > > Sep 26 19:22:58 fambox kernel: [ 11.136313] [] > > acpi_device_probe+0x4e/0x11c > > Sep 26 19:22:58 fambox kernel: [ 11.137482] [] > > driver_probe_device+0x7b/0x240 > > Sep 26 19:22:58 fambox kernel: [ 11.138642] [] > > __driver_attach+0xab/0xb0 > > Sep 26 19:22:58 fambox kernel: [ 11.139798] [] ? > > driver_probe_device+0x240/0x240 > > Sep 26 19:22:58 fambox kernel: [ 11.140981] [] > > bus_for_each_dev+0x56/0x90 > > Sep 26 19:22:58 fambox kernel: [ 11.142129] [] > > driver_attach+0x1e/0x20 > > Sep 26 19:22:58 fambox kernel: [ 11.143264] [] > > bus_add_driver+0x190/0x290 > > Sep 26 19:22:58 fambox kernel: [ 11.13] [] > > driver_register+0x7a/0x160 > > Sep 26 19:22:58 fambox kernel: [ 11.145583] [] > > acpi_bus_register_driver+0x43/0x45 > > Sep 26 19:22:58 fambox kernel: [ 11.146871] [] > > acpi_video_register+0x20/0x39 [video] > > Sep 26 19:22:58 fambox kernel: [ 11.148167] [] > > i915_driver_load+0x83d/0xea0 [i915] > > Sep 26 19:22:58 fambox kernel: [ 11.149451] [] > > drm_get_pci_dev+0x191/0x2b0 [drm] > > Sep 26 19:22:58 fambox kernel: [ 11.150739] [] > > i915_pci_probe+0x4f/0x57 [i915] > > Sep 26 19:22:58 fambox kernel: [ 11.152015] [] > > local_pci_probe+0x79/0x100 > > Sep 26 19:22:58 fambox
Re: inux-next: Tree for Sept 26 (not bootable on AMD64: thermal|acpi|drm/i915|pci related?)
CC Durga. On 三, 2012-09-26 at 19:42 +0200, Sedat Dilek wrote: > On Wed, Sep 26, 2012 at 8:44 AM, Stephen Rothwell > wrote: > > Hi all, > > > > Changes since 201209025: > > > > The net-next tree lost a conflict but gained another against Linus' tree. > > > > The wireless-next tree gained a conflict against the pci tree. > > > > The md tree lost its build failure. > > > > The mfd tree lost its build failure. > > > > The battery tree lost a conflict. > > > > The pm tree lost its build failure and its conflict. > > > > The edac tree lost its conflict. > > > > The spi tree lost its conflict. > > > > The rcu tree lost its conflicts. > > > > The tty tree lost its build failure. > > > > The arm-soc tree lost a conflict but gained another against the fbdev > > tree. > > > > The signal tree lost a conflict. > > > > The akpm tree gained a build failure for which I reverted a patch. > > > > > > > > Hi, > > on my Ubuntu/precise AMD64 today's Linux-Next runs into the following > call-trace (machine freezes): > > Sep 26 19:22:58 fambox kernel: [ 11.124739] BUG: unable to handle > kernel NULL pointer dereference at 0018 > Sep 26 19:22:58 fambox kernel: [ 11.124806] IP: [] > thermal_cooling_device_register+0x2c8/0x3d0 > Sep 26 19:22:58 fambox kernel: [ 11.124869] PGD 0 > Sep 26 19:22:58 fambox kernel: [ 11.124895] Oops: [#1] SMP > Sep 26 19:22:58 fambox kernel: [ 11.124919] Modules linked in: > coretemp kvm_intel kvm snd_hda_intel(+) arc4 snd_hda_codec iwldvm > snd_hwdep ghash_clmulni_intel snd_pcm aesni_intel uvcvideo mac80211 > aes_x86_64 snd_page_alloc ablk_helper i915(+) snd_seq_midi cryptd > videobuf2_vmalloc snd_seq_midi_event xts videobuf2_memops lrw > snd_rawmidi videobuf2_core joydev gf128mul videodev snd_seq > snd_seq_device hid_generic snd_timer drm_kms_helper iwlwifi drm snd > psmouse i2c_algo_bit soundcore btusb microcode serio_raw > samsung_laptop wmi cfg80211 bluetooth mei mac_hid video lpc_ich lp > parport ext4 jbd2 usbhid hid r8169 > Sep 26 19:22:58 fambox kernel: [ 11.125319] CPU 2 > Sep 26 19:22:58 fambox kernel: [ 11.125332] Pid: 579, comm: modprobe > Not tainted 3.6.0-rc7-next20120926-2-iniza-generic #1 SAMSUNG > ELECTRONICS CO., LTD. 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH > Sep 26 19:22:58 fambox kernel: [ 11.125401] RIP: > 0010:[] [] > thermal_cooling_device_register+0x2c8/0x3d0 > Sep 26 19:22:58 fambox kernel: [ 11.125450] RSP: > 0018:88010f23d838 EFLAGS: 00010246 > Sep 26 19:22:58 fambox kernel: [ 11.125475] RAX: > RBX: 88010bfd4c00 RCX: 0001 > Sep 26 19:22:58 fambox kernel: [ 11.125507] RDX: > RSI: 0282 RDI: 0282 > Sep 26 19:22:58 fambox kernel: [ 11.125539] RBP: 88010f23d878 > R08: R09: 0001 > Sep 26 19:22:58 fambox kernel: [ 11.125570] R10: 8801054fc460 > R11: R12: 88010bfd4c04 > Sep 26 19:22:58 fambox kernel: [ 11.125602] R13: 88011a73e000 > R14: R15: > Sep 26 19:22:58 fambox kernel: [ 11.125634] FS: > 7f6b8da29700() GS:88011fa8() > knlGS: > Sep 26 19:22:58 fambox kernel: [ 11.125670] CS: 0010 DS: ES: > CR0: 80050033 > Sep 26 19:22:58 fambox kernel: [ 11.125697] CR2: 0018 > CR3: 000110185000 CR4: 000407e0 > Sep 26 19:22:58 fambox kernel: [ 11.125729] DR0: > DR1: DR2: > Sep 26 19:22:58 fambox kernel: [ 11.125761] DR3: > DR6: 0ff0 DR7: 0400 > Sep 26 19:22:58 fambox kernel: [ 11.125793] Process modprobe (pid: > 579, threadinfo 88010f23c000, task 880116648000) > Sep 26 19:22:58 fambox kernel: [ 11.127133] Stack: > Sep 26 19:22:58 fambox kernel: [ 11.128461] 88011a5d9098 > 88010d74c300 88010f23d878 880110b06480 > Sep 26 19:22:58 fambox kernel: [ 11.129755] 88010bfd1000 > 88011a5d9098 88010d74c300 88011a625000 > Sep 26 19:22:58 fambox kernel: [ 11.130943] 88010f23d958 > a00e5868 811fa033 > Sep 26 19:22:58 fambox kernel: [ 11.132749] Call Trace: > Sep 26 19:22:58 fambox kernel: [ 11.133939] [] > acpi_video_bus_add+0x9ba/0xce6 [video] > Sep 26 19:22:58 fambox kernel: [ 11.135130] [] ? > sysfs_addrm_finish+0x33/0xc0 > Sep 26 19:22:58 fambox kernel: [ 11.136313] [] > acpi_device_probe+0x4e/0x11c > Sep 26 19:22:58 fambox kernel: [ 11.137482] [] > driver_probe_device+0x7b/0x240 > Sep 26 19:22:58 fambox kernel: [ 11.138642] [] > __driver_attach+0xab/0xb0 > Sep 26 19:22:58 fambox kernel: [ 11.139798] [] ? > driver_probe_device+0x240/0x240 > Sep 26 19:22:58 fambox kernel: [ 11.140981] [] > bus_for_each_dev+0x56/0x90 > Sep 26 19:22:58 fambox kernel: [ 11.142129] [] > driver_attach+0x1e/0x20 > Sep 26 19:22:58 fa
Re: [PATCH] drm/radeon: force dma32 to fix regression rs4xx,rs6xx,rs740
On Fri, Sep 21, 2012 at 04:00:51PM -0700, Greg KH wrote: > On Fri, Sep 21, 2012 at 08:56:27AM -0400, Josh Boyer wrote: > > On Tue, Aug 28, 2012 at 4:50 PM, wrote: > > > From: Jerome Glisse > > > > > > It seems some of those IGP dislike non dma32 page despite what > > > documentation says. Fix regression since we allowed non dma32 > > > pages. It seems it only affect some revision of those IGP chips > > > as we don't know which one just force dma32 for all of them. > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=785375 > > > > > > Signed-off-by: Jerome Glisse > > > Cc: > > > > > > This is upstream commit 4a2b6662c3632176b4fdf012243dd3751367bf1f. I > > don't see it queued up in the stable-queue, so I thought I'd point it > > out in case it was missed. > > I am way behind on the drm patches for stable, I have a ton of them in > my todo-queue, but have been traveling all week at a conference and > haven't had the chance to get to them. Hopefully I'll be able to flush > them all out next week, but don't worry, it's not lost. It's now applied, thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Patch "drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222S" has been added to the 3.5-stable tree
This is a note to let you know that I've just added the patch titled
drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222S
to the 3.5-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-add-edid_quirk_force_reduced_blanking-for-asus-vw222s.patch
and it can be found in the queue-3.5 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From 6f33814bd4d9cfe76033a31b1c0c76c960cd8e4b Mon Sep 17 00:00:00 2001
From: Paul Menzel
Date: Wed, 8 Aug 2012 23:12:19 +0200
Subject: drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222S
From: Paul Menzel
commit 6f33814bd4d9cfe76033a31b1c0c76c960cd8e4b upstream.
Connecting an ASUS VW222S [1] over VGA a garbled screen is shown with
vertical stripes in the top half.
In commit bc42aabc [2]
commit bc42aabc6a01b92b0f961d65671564e0e1cd7592
Author: Adam Jackson
Date: Wed May 23 16:26:54 2012 -0400
drm/edid/quirks: ViewSonic VA2026w
Adam Jackson added the quirk `EDID_QUIRK_FORCE_REDUCED_BLANKING` which
is also needed for this ASUS monitor.
All log files and output from `xrandr` is included in the referenced
Bugzilla report #17629.
Please note that this monitor only has a VGA (D-Sub) connector [1].
[1] http://www.asus.com/Display/LCD_Monitors/VW222S/
[2]
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=bc42aabc6a01b92b0f961d65671564e0e1cd7592
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=17629
Signed-off-by: Paul Menzel
Cc:
Cc: Adam Jackson
Cc: Ian Pilcher
Signed-off-by: Dave Airlie
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/drm_edid.c |3 +++
1 file changed, 3 insertions(+)
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -87,6 +87,9 @@ static struct edid_quirk {
int product_id;
u32 quirks;
} edid_quirk_list[] = {
+ /* ASUS VW222S */
+ { "ACI", 0x22a2, EDID_QUIRK_FORCE_REDUCED_BLANKING },
+
/* Acer AL1706 */
{ "ACR", 44358, EDID_QUIRK_PREFER_LARGE_60 },
/* Acer F51 */
Patches currently in stable-queue which might be from
paulepan...@users.sourceforge.net are
queue-3.5/drm-add-edid_quirk_force_reduced_blanking-for-asus-vw222s.patch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: fence virtual address and free it once idle [3.5] v4
On Fri, Aug 17, 2012 at 09:34:46AM -0400, Alex Deucher wrote: > On Thu, Aug 16, 2012 at 7:13 PM, Greg KH wrote: > > On Mon, Aug 06, 2012 at 12:56:04PM -0400, j.gli...@gmail.com wrote: > >> From: Jerome Glisse > >> > >> Virtual address need to be fenced to know when we can safely remove it. > >> This patch also properly clear the pagetable. Previously it was > >> serouisly broken. > >> > >> v2: For to update pagetable when unbinding bo (don't bailout if > >> bo_va->valid is true). > >> v3: Fix compilation warnings > >> v4: We need a special version for 3.5 because the locking scheme > >> is different btw 3.5 and 3.6. There is no longer cs mutex in > >> 3.6 instead there is a global vm mutex. > >> > >> This version is for stable 3.5 only. > > > > Is the version that fixes this problem in the 3.6 tree, already in > > Linus's tree? If so, what is the git commit id? If not, I need to wait > > until it gets in there, so please tell me when it does so. > > Yes: > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=e43b5ec05afdc232be25aa481315035c1888d389 > > Please apply to stable. Now applied, thanks. greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: inux-next: Tree for Sept 26 (not bootable on AMD64: thermal|acpi|drm/i915|pci related?)
On Wed, Sep 26, 2012 at 9:51 PM, Hugh Dickins wrote: > On Wed, 26 Sep 2012, Sedat Dilek wrote: >> >> on my Ubuntu/precise AMD64 today's Linux-Next runs into the following >> call-trace (machine freezes): >> >> Sep 26 19:22:58 fambox kernel: [ 11.124739] BUG: unable to handle >> kernel NULL pointer dereference at 0018 >> Sep 26 19:22:58 fambox kernel: [ 11.124806] IP: [] >> thermal_cooling_device_register+0x2c8/0x3d0 >> Sep 26 19:22:58 fambox kernel: [ 11.124869] PGD 0 >> Sep 26 19:22:58 fambox kernel: [ 11.124895] Oops: [#1] SMP >> Sep 26 19:22:58 fambox kernel: [ 11.124919] Modules linked in: >> coretemp kvm_intel kvm snd_hda_intel(+) arc4 snd_hda_codec iwldvm >> snd_hwdep ghash_clmulni_intel snd_pcm aesni_intel uvcvideo mac80211 >> aes_x86_64 snd_page_alloc ablk_helper i915(+) snd_seq_midi cryptd >> videobuf2_vmalloc snd_seq_midi_event xts videobuf2_memops lrw >> snd_rawmidi videobuf2_core joydev gf128mul videodev snd_seq >> snd_seq_device hid_generic snd_timer drm_kms_helper iwlwifi drm snd >> psmouse i2c_algo_bit soundcore btusb microcode serio_raw >> samsung_laptop wmi cfg80211 bluetooth mei mac_hid video lpc_ich lp >> parport ext4 jbd2 usbhid hid r8169 >> Sep 26 19:22:58 fambox kernel: [ 11.125319] CPU 2 >> Sep 26 19:22:58 fambox kernel: [ 11.125332] Pid: 579, comm: modprobe >> Not tainted 3.6.0-rc7-next20120926-2-iniza-generic #1 SAMSUNG >> ELECTRONICS CO., LTD. 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH >> Sep 26 19:22:58 fambox kernel: [ 11.125401] RIP: >> 0010:[] [] >> thermal_cooling_device_register+0x2c8/0x3d0 >> Sep 26 19:22:58 fambox kernel: [ 11.125450] RSP: >> 0018:88010f23d838 EFLAGS: 00010246 >> Sep 26 19:22:58 fambox kernel: [ 11.125475] RAX: >> RBX: 88010bfd4c00 RCX: 0001 >> Sep 26 19:22:58 fambox kernel: [ 11.125507] RDX: >> RSI: 0282 RDI: 0282 >> Sep 26 19:22:58 fambox kernel: [ 11.125539] RBP: 88010f23d878 >> R08: R09: 0001 >> Sep 26 19:22:58 fambox kernel: [ 11.125570] R10: 8801054fc460 >> R11: R12: 88010bfd4c04 >> Sep 26 19:22:58 fambox kernel: [ 11.125602] R13: 88011a73e000 >> R14: R15: >> Sep 26 19:22:58 fambox kernel: [ 11.125634] FS: >> 7f6b8da29700() GS:88011fa8() >> knlGS: >> Sep 26 19:22:58 fambox kernel: [ 11.125670] CS: 0010 DS: ES: >> CR0: 80050033 >> Sep 26 19:22:58 fambox kernel: [ 11.125697] CR2: 0018 >> CR3: 000110185000 CR4: 000407e0 >> Sep 26 19:22:58 fambox kernel: [ 11.125729] DR0: >> DR1: DR2: >> Sep 26 19:22:58 fambox kernel: [ 11.125761] DR3: >> DR6: 0ff0 DR7: 0400 >> Sep 26 19:22:58 fambox kernel: [ 11.125793] Process modprobe (pid: >> 579, threadinfo 88010f23c000, task 880116648000) >> Sep 26 19:22:58 fambox kernel: [ 11.127133] Stack: >> Sep 26 19:22:58 fambox kernel: [ 11.128461] 88011a5d9098 >> 88010d74c300 88010f23d878 880110b06480 >> Sep 26 19:22:58 fambox kernel: [ 11.129755] 88010bfd1000 >> 88011a5d9098 88010d74c300 88011a625000 >> Sep 26 19:22:58 fambox kernel: [ 11.130943] 88010f23d958 >> a00e5868 811fa033 >> Sep 26 19:22:58 fambox kernel: [ 11.132749] Call Trace: >> Sep 26 19:22:58 fambox kernel: [ 11.133939] [] >> acpi_video_bus_add+0x9ba/0xce6 [video] >> Sep 26 19:22:58 fambox kernel: [ 11.135130] [] ? >> sysfs_addrm_finish+0x33/0xc0 >> Sep 26 19:22:58 fambox kernel: [ 11.136313] [] >> acpi_device_probe+0x4e/0x11c >> Sep 26 19:22:58 fambox kernel: [ 11.137482] [] >> driver_probe_device+0x7b/0x240 >> Sep 26 19:22:58 fambox kernel: [ 11.138642] [] >> __driver_attach+0xab/0xb0 >> Sep 26 19:22:58 fambox kernel: [ 11.139798] [] ? >> driver_probe_device+0x240/0x240 >> Sep 26 19:22:58 fambox kernel: [ 11.140981] [] >> bus_for_each_dev+0x56/0x90 >> Sep 26 19:22:58 fambox kernel: [ 11.142129] [] >> driver_attach+0x1e/0x20 >> Sep 26 19:22:58 fambox kernel: [ 11.143264] [] >> bus_add_driver+0x190/0x290 >> Sep 26 19:22:58 fambox kernel: [ 11.13] [] >> driver_register+0x7a/0x160 >> Sep 26 19:22:58 fambox kernel: [ 11.145583] [] >> acpi_bus_register_driver+0x43/0x45 >> Sep 26 19:22:58 fambox kernel: [ 11.146871] [] >> acpi_video_register+0x20/0x39 [video] >> Sep 26 19:22:58 fambox kernel: [ 11.148167] [] >> i915_driver_load+0x83d/0xea0 [i915] >> Sep 26 19:22:58 fambox kernel: [ 11.149451] [] >> drm_get_pci_dev+0x191/0x2b0 [drm] >> Sep 26 19:22:58 fambox kernel: [ 11.150739] [] >> i915_pci_probe+0x4f/0x57 [i915] >> Sep 26 19:22:58 fambox kernel: [ 11.152015] [] >> local_pci_probe+0x79/0x100 >> Sep 26 19:22:58 fambox kernel: [ 11.153287] [] >> pci_device_probe+0x109/0x130 >> Sep 26 19:22:58 fambox kernel: [ 11.15454
Re: inux-next: Tree for Sept 26 (not bootable on AMD64: thermal|acpi|drm/i915|pci related?)
On Wed, 26 Sep 2012, Sedat Dilek wrote: > > on my Ubuntu/precise AMD64 today's Linux-Next runs into the following > call-trace (machine freezes): > > Sep 26 19:22:58 fambox kernel: [ 11.124739] BUG: unable to handle > kernel NULL pointer dereference at 0018 > Sep 26 19:22:58 fambox kernel: [ 11.124806] IP: [] > thermal_cooling_device_register+0x2c8/0x3d0 > Sep 26 19:22:58 fambox kernel: [ 11.124869] PGD 0 > Sep 26 19:22:58 fambox kernel: [ 11.124895] Oops: [#1] SMP > Sep 26 19:22:58 fambox kernel: [ 11.124919] Modules linked in: > coretemp kvm_intel kvm snd_hda_intel(+) arc4 snd_hda_codec iwldvm > snd_hwdep ghash_clmulni_intel snd_pcm aesni_intel uvcvideo mac80211 > aes_x86_64 snd_page_alloc ablk_helper i915(+) snd_seq_midi cryptd > videobuf2_vmalloc snd_seq_midi_event xts videobuf2_memops lrw > snd_rawmidi videobuf2_core joydev gf128mul videodev snd_seq > snd_seq_device hid_generic snd_timer drm_kms_helper iwlwifi drm snd > psmouse i2c_algo_bit soundcore btusb microcode serio_raw > samsung_laptop wmi cfg80211 bluetooth mei mac_hid video lpc_ich lp > parport ext4 jbd2 usbhid hid r8169 > Sep 26 19:22:58 fambox kernel: [ 11.125319] CPU 2 > Sep 26 19:22:58 fambox kernel: [ 11.125332] Pid: 579, comm: modprobe > Not tainted 3.6.0-rc7-next20120926-2-iniza-generic #1 SAMSUNG > ELECTRONICS CO., LTD. 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH > Sep 26 19:22:58 fambox kernel: [ 11.125401] RIP: > 0010:[] [] > thermal_cooling_device_register+0x2c8/0x3d0 > Sep 26 19:22:58 fambox kernel: [ 11.125450] RSP: > 0018:88010f23d838 EFLAGS: 00010246 > Sep 26 19:22:58 fambox kernel: [ 11.125475] RAX: > RBX: 88010bfd4c00 RCX: 0001 > Sep 26 19:22:58 fambox kernel: [ 11.125507] RDX: > RSI: 0282 RDI: 0282 > Sep 26 19:22:58 fambox kernel: [ 11.125539] RBP: 88010f23d878 > R08: R09: 0001 > Sep 26 19:22:58 fambox kernel: [ 11.125570] R10: 8801054fc460 > R11: R12: 88010bfd4c04 > Sep 26 19:22:58 fambox kernel: [ 11.125602] R13: 88011a73e000 > R14: R15: > Sep 26 19:22:58 fambox kernel: [ 11.125634] FS: > 7f6b8da29700() GS:88011fa8() > knlGS: > Sep 26 19:22:58 fambox kernel: [ 11.125670] CS: 0010 DS: ES: > CR0: 80050033 > Sep 26 19:22:58 fambox kernel: [ 11.125697] CR2: 0018 > CR3: 000110185000 CR4: 000407e0 > Sep 26 19:22:58 fambox kernel: [ 11.125729] DR0: > DR1: DR2: > Sep 26 19:22:58 fambox kernel: [ 11.125761] DR3: > DR6: 0ff0 DR7: 0400 > Sep 26 19:22:58 fambox kernel: [ 11.125793] Process modprobe (pid: > 579, threadinfo 88010f23c000, task 880116648000) > Sep 26 19:22:58 fambox kernel: [ 11.127133] Stack: > Sep 26 19:22:58 fambox kernel: [ 11.128461] 88011a5d9098 > 88010d74c300 88010f23d878 880110b06480 > Sep 26 19:22:58 fambox kernel: [ 11.129755] 88010bfd1000 > 88011a5d9098 88010d74c300 88011a625000 > Sep 26 19:22:58 fambox kernel: [ 11.130943] 88010f23d958 > a00e5868 811fa033 > Sep 26 19:22:58 fambox kernel: [ 11.132749] Call Trace: > Sep 26 19:22:58 fambox kernel: [ 11.133939] [] > acpi_video_bus_add+0x9ba/0xce6 [video] > Sep 26 19:22:58 fambox kernel: [ 11.135130] [] ? > sysfs_addrm_finish+0x33/0xc0 > Sep 26 19:22:58 fambox kernel: [ 11.136313] [] > acpi_device_probe+0x4e/0x11c > Sep 26 19:22:58 fambox kernel: [ 11.137482] [] > driver_probe_device+0x7b/0x240 > Sep 26 19:22:58 fambox kernel: [ 11.138642] [] > __driver_attach+0xab/0xb0 > Sep 26 19:22:58 fambox kernel: [ 11.139798] [] ? > driver_probe_device+0x240/0x240 > Sep 26 19:22:58 fambox kernel: [ 11.140981] [] > bus_for_each_dev+0x56/0x90 > Sep 26 19:22:58 fambox kernel: [ 11.142129] [] > driver_attach+0x1e/0x20 > Sep 26 19:22:58 fambox kernel: [ 11.143264] [] > bus_add_driver+0x190/0x290 > Sep 26 19:22:58 fambox kernel: [ 11.13] [] > driver_register+0x7a/0x160 > Sep 26 19:22:58 fambox kernel: [ 11.145583] [] > acpi_bus_register_driver+0x43/0x45 > Sep 26 19:22:58 fambox kernel: [ 11.146871] [] > acpi_video_register+0x20/0x39 [video] > Sep 26 19:22:58 fambox kernel: [ 11.148167] [] > i915_driver_load+0x83d/0xea0 [i915] > Sep 26 19:22:58 fambox kernel: [ 11.149451] [] > drm_get_pci_dev+0x191/0x2b0 [drm] > Sep 26 19:22:58 fambox kernel: [ 11.150739] [] > i915_pci_probe+0x4f/0x57 [i915] > Sep 26 19:22:58 fambox kernel: [ 11.152015] [] > local_pci_probe+0x79/0x100 > Sep 26 19:22:58 fambox kernel: [ 11.153287] [] > pci_device_probe+0x109/0x130 > Sep 26 19:22:58 fambox kernel: [ 11.154546] [] > driver_probe_device+0x7b/0x240 > Sep 26 19:22:58 fambox kernel: [ 11.155796] [] > __driver_attach+0xab/0xb0 > Sep 26 19:22:58 fambox kern
[PATCH] drm/prime: drop reference on imported dma-buf come from gem
Increasing ref counts of both dma-buf and gem for imported dma-buf come from gem
makes memory leak. release function of dma-buf cannot be called because f_count
of dma-buf increased by importing gem and gem ref count cannot be decrease
because of exported dma-buf.
So I add dma_buf_put() for imported gem come from its own gem into each drivers
having prime_import and prime_export capabilities. With this, only gem ref
count is increased if importing gem exported from gem of same driver.
Signed-off-by: Seung-Woo Kim
Signed-off-by: Kyungmin.park
Cc: Inki Dae
Cc: Daniel Vetter
Cc: Rob Clark
Cc: Alex Deucher
---
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |5 +
drivers/gpu/drm/i915/i915_gem_dmabuf.c |5 +
drivers/gpu/drm/nouveau/nouveau_prime.c|1 +
drivers/gpu/drm/radeon/radeon_prime.c |1 +
drivers/staging/omapdrm/omap_gem_dmabuf.c |5 +
5 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
index ae13feb..b0897c9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
@@ -211,7 +211,12 @@ struct drm_gem_object *exynos_dmabuf_prime_import(struct
drm_device *drm_dev,
/* is it from our device? */
if (obj->dev == drm_dev) {
+ /*
+* Importing dmabuf exported from out own gem increases
+* refcount on gem itself instead of f_count of dmabuf.
+*/
drm_gem_object_reference(obj);
+ dma_buf_put(dma_buf);
return obj;
}
}
diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
index aa308e1..32e6287 100644
--- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
@@ -188,7 +188,12 @@ struct drm_gem_object *i915_gem_prime_import(struct
drm_device *dev,
obj = dma_buf->priv;
/* is it from our device? */
if (obj->base.dev == dev) {
+ /*
+* Importing dmabuf exported from out own gem increases
+* refcount on gem itself instead of f_count of dmabuf.
+*/
drm_gem_object_reference(&obj->base);
+ dma_buf_put(dma_buf);
return &obj->base;
}
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_prime.c
b/drivers/gpu/drm/nouveau/nouveau_prime.c
index a25cf2c..bb653c6 100644
--- a/drivers/gpu/drm/nouveau/nouveau_prime.c
+++ b/drivers/gpu/drm/nouveau/nouveau_prime.c
@@ -199,6 +199,7 @@ struct drm_gem_object *nouveau_gem_prime_import(struct
drm_device *dev,
if (nvbo->gem) {
if (nvbo->gem->dev == dev) {
drm_gem_object_reference(nvbo->gem);
+ dma_buf_put(dma_buf);
return nvbo->gem;
}
}
diff --git a/drivers/gpu/drm/radeon/radeon_prime.c
b/drivers/gpu/drm/radeon/radeon_prime.c
index 6bef46a..d344a3be 100644
--- a/drivers/gpu/drm/radeon/radeon_prime.c
+++ b/drivers/gpu/drm/radeon/radeon_prime.c
@@ -195,6 +195,7 @@ struct drm_gem_object *radeon_gem_prime_import(struct
drm_device *dev,
bo = dma_buf->priv;
if (bo->gem_base.dev == dev) {
drm_gem_object_reference(&bo->gem_base);
+ dma_buf_put(dma_buf);
return &bo->gem_base;
}
}
diff --git a/drivers/staging/omapdrm/omap_gem_dmabuf.c
b/drivers/staging/omapdrm/omap_gem_dmabuf.c
index 42728e0..5b50eb6 100644
--- a/drivers/staging/omapdrm/omap_gem_dmabuf.c
+++ b/drivers/staging/omapdrm/omap_gem_dmabuf.c
@@ -207,7 +207,12 @@ struct drm_gem_object * omap_gem_prime_import(struct
drm_device *dev,
obj = buffer->priv;
/* is it from our device? */
if (obj->dev == dev) {
+ /*
+* Importing dmabuf exported from out own gem increases
+* refcount on gem itself instead of f_count of dmabuf.
+*/
drm_gem_object_reference(obj);
+ dma_buf_put(buffer);
return obj;
}
}
--
1.7.4.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
inux-next: Tree for Sept 26 (not bootable on AMD64: thermal|acpi|drm/i915|pci related?)
On Wed, Sep 26, 2012 at 8:44 AM, Stephen Rothwell wrote: > Hi all, > > Changes since 201209025: > > The net-next tree lost a conflict but gained another against Linus' tree. > > The wireless-next tree gained a conflict against the pci tree. > > The md tree lost its build failure. > > The mfd tree lost its build failure. > > The battery tree lost a conflict. > > The pm tree lost its build failure and its conflict. > > The edac tree lost its conflict. > > The spi tree lost its conflict. > > The rcu tree lost its conflicts. > > The tty tree lost its build failure. > > The arm-soc tree lost a conflict but gained another against the fbdev > tree. > > The signal tree lost a conflict. > > The akpm tree gained a build failure for which I reverted a patch. > > > Hi, on my Ubuntu/precise AMD64 today's Linux-Next runs into the following call-trace (machine freezes): Sep 26 19:22:58 fambox kernel: [ 11.124739] BUG: unable to handle kernel NULL pointer dereference at 0018 Sep 26 19:22:58 fambox kernel: [ 11.124806] IP: [] thermal_cooling_device_register+0x2c8/0x3d0 Sep 26 19:22:58 fambox kernel: [ 11.124869] PGD 0 Sep 26 19:22:58 fambox kernel: [ 11.124895] Oops: [#1] SMP Sep 26 19:22:58 fambox kernel: [ 11.124919] Modules linked in: coretemp kvm_intel kvm snd_hda_intel(+) arc4 snd_hda_codec iwldvm snd_hwdep ghash_clmulni_intel snd_pcm aesni_intel uvcvideo mac80211 aes_x86_64 snd_page_alloc ablk_helper i915(+) snd_seq_midi cryptd videobuf2_vmalloc snd_seq_midi_event xts videobuf2_memops lrw snd_rawmidi videobuf2_core joydev gf128mul videodev snd_seq snd_seq_device hid_generic snd_timer drm_kms_helper iwlwifi drm snd psmouse i2c_algo_bit soundcore btusb microcode serio_raw samsung_laptop wmi cfg80211 bluetooth mei mac_hid video lpc_ich lp parport ext4 jbd2 usbhid hid r8169 Sep 26 19:22:58 fambox kernel: [ 11.125319] CPU 2 Sep 26 19:22:58 fambox kernel: [ 11.125332] Pid: 579, comm: modprobe Not tainted 3.6.0-rc7-next20120926-2-iniza-generic #1 SAMSUNG ELECTRONICS CO., LTD. 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH Sep 26 19:22:58 fambox kernel: [ 11.125401] RIP: 0010:[] [] thermal_cooling_device_register+0x2c8/0x3d0 Sep 26 19:22:58 fambox kernel: [ 11.125450] RSP: 0018:88010f23d838 EFLAGS: 00010246 Sep 26 19:22:58 fambox kernel: [ 11.125475] RAX: RBX: 88010bfd4c00 RCX: 0001 Sep 26 19:22:58 fambox kernel: [ 11.125507] RDX: RSI: 0282 RDI: 0282 Sep 26 19:22:58 fambox kernel: [ 11.125539] RBP: 88010f23d878 R08: R09: 0001 Sep 26 19:22:58 fambox kernel: [ 11.125570] R10: 8801054fc460 R11: R12: 88010bfd4c04 Sep 26 19:22:58 fambox kernel: [ 11.125602] R13: 88011a73e000 R14: R15: Sep 26 19:22:58 fambox kernel: [ 11.125634] FS: 7f6b8da29700() GS:88011fa8() knlGS: Sep 26 19:22:58 fambox kernel: [ 11.125670] CS: 0010 DS: ES: CR0: 80050033 Sep 26 19:22:58 fambox kernel: [ 11.125697] CR2: 0018 CR3: 000110185000 CR4: 000407e0 Sep 26 19:22:58 fambox kernel: [ 11.125729] DR0: DR1: DR2: Sep 26 19:22:58 fambox kernel: [ 11.125761] DR3: DR6: 0ff0 DR7: 0400 Sep 26 19:22:58 fambox kernel: [ 11.125793] Process modprobe (pid: 579, threadinfo 88010f23c000, task 880116648000) Sep 26 19:22:58 fambox kernel: [ 11.127133] Stack: Sep 26 19:22:58 fambox kernel: [ 11.128461] 88011a5d9098 88010d74c300 88010f23d878 880110b06480 Sep 26 19:22:58 fambox kernel: [ 11.129755] 88010bfd1000 88011a5d9098 88010d74c300 88011a625000 Sep 26 19:22:58 fambox kernel: [ 11.130943] 88010f23d958 a00e5868 811fa033 Sep 26 19:22:58 fambox kernel: [ 11.132749] Call Trace: Sep 26 19:22:58 fambox kernel: [ 11.133939] [] acpi_video_bus_add+0x9ba/0xce6 [video] Sep 26 19:22:58 fambox kernel: [ 11.135130] [] ? sysfs_addrm_finish+0x33/0xc0 Sep 26 19:22:58 fambox kernel: [ 11.136313] [] acpi_device_probe+0x4e/0x11c Sep 26 19:22:58 fambox kernel: [ 11.137482] [] driver_probe_device+0x7b/0x240 Sep 26 19:22:58 fambox kernel: [ 11.138642] [] __driver_attach+0xab/0xb0 Sep 26 19:22:58 fambox kernel: [ 11.139798] [] ? driver_probe_device+0x240/0x240 Sep 26 19:22:58 fambox kernel: [ 11.140981] [] bus_for_each_dev+0x56/0x90 Sep 26 19:22:58 fambox kernel: [ 11.142129] [] driver_attach+0x1e/0x20 Sep 26 19:22:58 fambox kernel: [ 11.143264] [] bus_add_driver+0x190/0x290 Sep 26 19:22:58 fambox kernel: [ 11.13] [] driver_register+0x7a/0x160 Sep 26 19:22:58 fambox kernel: [ 11.145583] [] acpi_bus_register_driver+0x43/0x45 Sep 26 19:22:58 fambox kernel: [ 11.146871] [] acpi_video_register+
Re: [PATCH] drm/radeon: make 64bit fences more robust v3 (3.5 stable)
On Thu, Sep 20, 2012 at 10:57:01AM -0400, alexdeuc...@gmail.com wrote: > From: Christian König > > Only increase the higher 32bits if we really detect a wrap around. > > v2: instead of increasing the higher 32bits just use the higher > 32bits from the last emitted fence. > v3: also use last emitted fence value as upper limit. > > The intention of this patch is to make fences as robust as > they where before introducing 64bit fences. This is > necessary because on older systems it looks like the fence > value gets corrupted on initialization. > > Fixes: > https://bugs.freedesktop.org/show_bug.cgi?id=51344 > > Should also fix: > https://bugs.freedesktop.org/show_bug.cgi?id=54129 > https://bugs.freedesktop.org/show_bug.cgi?id=54662 > https://bugzilla.redhat.com/show_bug.cgi?id=846505 > https://bugzilla.redhat.com/show_bug.cgi?id=845639 > > This is the 3.5 stable version of the patch: > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=f492c171a38d77fc13a8998a0721f2da50835224 > 3.4 and previous kernels do not need to be patched. > > Signed-off-by: Christian König > Signed-off-by: Alex Deucher Thanks, now applied. greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon: make 64bit fences more robust v3 (3.5 stable)
On Thu, Sep 20, 2012 at 10:57:01AM -0400, alexdeucher at gmail.com wrote: > From: Christian K?nig > > Only increase the higher 32bits if we really detect a wrap around. > > v2: instead of increasing the higher 32bits just use the higher > 32bits from the last emitted fence. > v3: also use last emitted fence value as upper limit. > > The intention of this patch is to make fences as robust as > they where before introducing 64bit fences. This is > necessary because on older systems it looks like the fence > value gets corrupted on initialization. > > Fixes: > https://bugs.freedesktop.org/show_bug.cgi?id=51344 > > Should also fix: > https://bugs.freedesktop.org/show_bug.cgi?id=54129 > https://bugs.freedesktop.org/show_bug.cgi?id=54662 > https://bugzilla.redhat.com/show_bug.cgi?id=846505 > https://bugzilla.redhat.com/show_bug.cgi?id=845639 > > This is the 3.5 stable version of the patch: > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=f492c171a38d77fc13a8998a0721f2da50835224 > 3.4 and previous kernels do not need to be patched. > > Signed-off-by: Christian K?nig > Signed-off-by: Alex Deucher Thanks, now applied. greg k-h
Problem: Internal LVDS screen alignment: the display shows a black "frame" at the bottom and is cut off at the top in 3.6-rc5+ with gma500 (REGRESSION)
On Wed, Sep 26, 2012 at 4:33 PM, Alan Cox wrote: > > > This happens _only in X_ and not on the console. My system and Xorg is > > very old. (Ubuntu 9.10). > > Make sure you have the framebuffer driver in use not the vesa one if > you are using an old X11. If you use the vesa driver then randomness > will occur. No, I'm definitely on fbdev: "Section "Device" Identifier "GMA500" Driver "fbdev" EndSection"
[PATCH] drm/radeon: force dma32 to fix regression rs4xx,rs6xx,rs740
On Fri, Sep 21, 2012 at 04:00:51PM -0700, Greg KH wrote: > On Fri, Sep 21, 2012 at 08:56:27AM -0400, Josh Boyer wrote: > > On Tue, Aug 28, 2012 at 4:50 PM, wrote: > > > From: Jerome Glisse > > > > > > It seems some of those IGP dislike non dma32 page despite what > > > documentation says. Fix regression since we allowed non dma32 > > > pages. It seems it only affect some revision of those IGP chips > > > as we don't know which one just force dma32 for all of them. > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=785375 > > > > > > Signed-off-by: Jerome Glisse > > > Cc: > > > > > > This is upstream commit 4a2b6662c3632176b4fdf012243dd3751367bf1f. I > > don't see it queued up in the stable-queue, so I thought I'd point it > > out in case it was missed. > > I am way behind on the drm patches for stable, I have a ton of them in > my todo-queue, but have been traveling all week at a conference and > haven't had the chance to get to them. Hopefully I'll be able to flush > them all out next week, but don't worry, it's not lost. It's now applied, thanks, greg k-h
Patch "drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222S" has been added to the 3.5-stable tree
This is a note to let you know that I've just added the patch titled
drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222S
to the 3.5-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-add-edid_quirk_force_reduced_blanking-for-asus-vw222s.patch
and it can be found in the queue-3.5 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From 6f33814bd4d9cfe76033a31b1c0c76c960cd8e4b Mon Sep 17 00:00:00 2001
From: Paul Menzel
Date: Wed, 8 Aug 2012 23:12:19 +0200
Subject: drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222S
From: Paul Menzel
commit 6f33814bd4d9cfe76033a31b1c0c76c960cd8e4b upstream.
Connecting an ASUS VW222S [1] over VGA a garbled screen is shown with
vertical stripes in the top half.
In commit bc42aabc [2]
commit bc42aabc6a01b92b0f961d65671564e0e1cd7592
Author: Adam Jackson
Date: Wed May 23 16:26:54 2012 -0400
drm/edid/quirks: ViewSonic VA2026w
Adam Jackson added the quirk `EDID_QUIRK_FORCE_REDUCED_BLANKING` which
is also needed for this ASUS monitor.
All log files and output from `xrandr` is included in the referenced
Bugzilla report #17629.
Please note that this monitor only has a VGA (D-Sub) connector [1].
[1] http://www.asus.com/Display/LCD_Monitors/VW222S/
[2]
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=bc42aabc6a01b92b0f961d65671564e0e1cd7592
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=17629
Signed-off-by: Paul Menzel
Cc:
Cc: Adam Jackson
Cc: Ian Pilcher
Signed-off-by: Dave Airlie
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/drm_edid.c |3 +++
1 file changed, 3 insertions(+)
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -87,6 +87,9 @@ static struct edid_quirk {
int product_id;
u32 quirks;
} edid_quirk_list[] = {
+ /* ASUS VW222S */
+ { "ACI", 0x22a2, EDID_QUIRK_FORCE_REDUCED_BLANKING },
+
/* Acer AL1706 */
{ "ACR", 44358, EDID_QUIRK_PREFER_LARGE_60 },
/* Acer F51 */
Patches currently in stable-queue which might be from paulepanter at
users.sourceforge.net are
queue-3.5/drm-add-edid_quirk_force_reduced_blanking-for-asus-vw222s.patch
Problem: Internal LVDS screen alignment: the display shows a black "frame" at the bottom and is cut off at the top in 3.6-rc5+ with gma500 (REGRESSION)
led; RCB 64 bytes Disabled- Retrain- CommClk+ ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt- ABWMgmt- SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surpise+ Slot # 0, PowerLimit 0.00; Interlock- NoCompl- SltCtl: Enable: AttnBtn+ PwrFlt- MRL- PresDet+ CmdCplt- HPIrq- LinkChg- Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock- SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock- Changed: MRL- PresDet- LinkState+ RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible- RootCap: CRSVisible- RootSta: PME ReqID , PMEStatus- PMEPending- Capabilities: [90] Subsystem: Micro-Star International Co., Ltd. Device 1002 Capabilities: [a0] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: pcieport Kernel modules: shpchp 00:1d.0 USB Controller: Intel Corporation System Controller Hub (SCH Poulsbo) USB UHCI #1 (rev 07) Subsystem: Micro-Star International Co., Ltd. Device 1002 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- Kernel driver in use: sata_sil24 Kernel modules: sata_sil24 02:00.0 Network controller: RaLink RT2860 Subsystem: Micro-Star International Co., Ltd. Device 6890 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: rt2800pci Kernel modules: rt2800pci [8.6.] SCSI information (from /proc/scsi/scsi) Attached devices: Host: scsi1 Channel: 00 Id: 00 Lun: 00 Vendor: ATA Model: SAMSUNG SSD 830 Rev: CXM0 Type: Direct-AccessANSI SCSI revision: 05 Host: scsi3 Channel: 00 Id: 00 Lun: 00 Vendor: Generic- Model: Multi-Card Rev: 1.00 Type: Direct-AccessANSI SCSI revision: 00 [8.7.] Other information that might be relevant to the problem (please look in /proc and include all information that you think to be relevant): Xorg [X.] Other notes, patches, fixes, workarounds: Thanks for fixing gma500 suspend for my system! Thanks, in general for writing this driver! -- next part -- A non-text attachment was scrubbed... Name: config-3.6.0-999-generic Type: application/octet-stream Size: 139617 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120926/b91bfdff/attachment-0001.obj>
-next trees
On 09/26/2012 12:00 PM, Adam Jackson wrote: > On Tue, 2012-09-25 at 13:47 -0500, Ian Pilcher wrote: >> >> 1. The display (LG L246WP) is confused by *any* InfoFrames. > > If this is still the case after applying: > > commit adf00b26d18e1b3570451296e03bcb20e4798cdd > Author: Paulo Zanoni > Date: Tue Sep 25 13:23:34 2012 -0300 > > drm/i915: make sure we write all the DIP data bytes > > Then I suspect I'm compelled to agree that we need a quirk to forcibly > disable InfoFrames entirely. I don't like to be difficult about this, > but the HDMI spec is quite clear that sinks _must_ accept InfoFrames > defined in either the CEA or HDMI specs, so if we're seeing that class > of failure I tend to strongly suspect our drivers first. I just tested with that patch applied, and the problem still exists, so consider yourself compelled. Unless you object, I will go ahead and create a patch series that does only: - user-defined EDID quirks - DISABLE_INFOFRAMES quirk - DISABLE_INFOFRAMES quirk for LG L246WP (I will specifically *not* address the audio issue in this series.) >> 3. drm_detect_monitor_audio is returning true for the LG L246WP, which >> definitely doesn't have any audio capabilities. This may be a bug >> in the display's EDID, or it may be a parsing error. > > The display is definitely a filthy liar then: > >Audio data block > Linear PCM, max channels 1 > Supported sample rates (kHz): 48 44.1 32 > Supported sample sizes (bits): 24 20 16 > > Hooray for hardware. Not sure what the logic should be for whether to > send HDMI audio or not, I'll re-read the appropriate scrolls. Well, if hardware didn't suck we wouldn't need quirks. If you'd like, I can generate a second patch series that adds some or all of: - NO_AUDIO quirk - drm_monitor_has_hdmi_audio() function - NO_AUDIO quirk for LG L246WP (kind of redundant if no InfoFrames are being sent anyway, but still technically accurate) Let me know if you'd like any or all of those. Thanks! -- Ian Pilcher arequipeno at gmail.com "If you're going to shift my paradigm ... at least buy me dinner first."
radeon: Regression between v3.6-rc4 and v3.6-rc6: unable to allocate a PPLL
This is fixed now? regards, dan carpenter
[PATCH] drm/radeon: fence virtual address and free it once idle [3.5] v4
On Fri, Aug 17, 2012 at 09:34:46AM -0400, Alex Deucher wrote: > On Thu, Aug 16, 2012 at 7:13 PM, Greg KH > wrote: > > On Mon, Aug 06, 2012 at 12:56:04PM -0400, j.glisse at gmail.com wrote: > >> From: Jerome Glisse > >> > >> Virtual address need to be fenced to know when we can safely remove it. > >> This patch also properly clear the pagetable. Previously it was > >> serouisly broken. > >> > >> v2: For to update pagetable when unbinding bo (don't bailout if > >> bo_va->valid is true). > >> v3: Fix compilation warnings > >> v4: We need a special version for 3.5 because the locking scheme > >> is different btw 3.5 and 3.6. There is no longer cs mutex in > >> 3.6 instead there is a global vm mutex. > >> > >> This version is for stable 3.5 only. > > > > Is the version that fixes this problem in the 3.6 tree, already in > > Linus's tree? If so, what is the git commit id? If not, I need to wait > > until it gets in there, so please tell me when it does so. > > Yes: > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=e43b5ec05afdc232be25aa481315035c1888d389 > > Please apply to stable. Now applied, thanks. greg k-h
radeon: Regression between v3.6-rc4 and v3.6-rc6: unable to allocate a PPLL
On Wednesday, September 26, 2012 03:00:09 PM Dan Carpenter wrote: > This is fixed now? Its been reverted in 2f1f4d9b60396d2df4cff829bd5376ffc8ed9a2c which is in rc6. On Monday, September 17, 2012 09:30:12 PM Deucher, Alexander wrote: Sorry, I somehow accidentally marked your email as read and thus didn't notice it. > I think I see the problem. I think it's a limitation of the current current modesetting API. The current API sets up each display independently which doesn't work so well if there are resource restrictions. There shouldn't be any contention on your board since you are only using 2 non-DP displays. It looks like X is mapping different crtcs to displays than the kernel fb. Initially the kernel set up the follow: > > [2.134901] [drm] crtc 0 using pll 0x2 > > [2.362257] [drm] crtc 1 using pll 0x1 > > [2.386709] [drm] crtc 2 using pll 0x0 > > Crtc 0 -> DCPLL -> DP > Crtc 1 -> PPLL2 -> DVI > Crtc 2 -> PPLL1 -> DVI > > When X loads, it tried to set a different crtc to display mapping: > > [ 60.679310] [drm] crtc 0 using pll 0xff > > [ 60.789183] [drm] crtc 1 using pll 0x2 > > [ 60.819594] [drm] crtc 2 using pll 0x1 > > Crtc 0 -> INVALID -> DVI 0 > Crtc 1 -> DCPLL -> DP > Crtc 2 -> PPLL2 -> DVI 1 > > Crtc 0 should have used PPLL1 or PPLL2, but they were already in use by > crtc 1 and crtc 2 from the previous modeset. Since the modeset API is > not atomic, it doesn't have the whole picture. I'm not sure of a good > solution right now prior to the new atomic modeset API that is under > discussion. I guess we can revert the patch for 3.6. For 3.7 I guess we > need to validate the actual connector to make sure we aren't trying to set > a different configuration relating to the same connector without first > tearing down the first one. In the interim, you should be able to work > around it by disabling the non-DP outputs and then bringing than back up. Thanks! That explanation makes sense. I can work around it just fine, starting X multiple times works which coincides nicely with your explanation. The code in the 3.7 branch doesn't do that extended validation yet, rigth? If you want/need you can CC for testing once thats ready. Greetings, Andres
Problem: Internal LVDS screen alignment: the display shows a black "frame" at the bottom and is cut off at the top in 3.6-rc5+ with gma500 (REGRESSION)
> This happens _only in X_ and not on the console. My system and Xorg is > very old. (Ubuntu 9.10). Make sure you have the framebuffer driver in use not the vesa one if you are using an old X11. If you use the vesa driver then randomness will occur. Alan
[PATCH 2/2] drm/dp: Make sink count DP 1.2 aware
On Thu, Sep 20, 2012 at 06:45:29PM -0300, Paulo Zanoni wrote:
> 2012/9/20 Adam Jackson :
> > Signed-off-by: Adam Jackson
>
> Reviewed-by: Paulo Zanoni
Both patches merged to dinq (again with Dave's irc-ack for the common
stuff).
Thanks, Daniel
>
> > ---
> > drivers/gpu/drm/i915/intel_dp.c |9 -
> > include/drm/drm_dp_helper.h |3 ++-
> > 2 files changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 813b771..00f99e5 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -2106,13 +2106,12 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp)
> > /* If we're HPD-aware, SINK_COUNT changes dynamically */
> > hpd = !!(intel_dp->downstream_ports[0] & DP_DS_PORT_HPD);
> > if (hpd) {
> > - uint8_t sink_count;
> > + uint8_t reg;
> > if (!intel_dp_aux_native_read_retry(intel_dp, DP_SINK_COUNT,
> > - &sink_count, 1))
> > + ®, 1))
> > return connector_status_unknown;
> > - sink_count &= DP_SINK_COUNT_MASK;
> > - return sink_count ? connector_status_connected
> > - : connector_status_disconnected;
> > + return DP_GET_SINK_COUNT(reg) ? connector_status_connected
> > + :
> > connector_status_disconnected;
> > }
> >
> > /* If no HPD, poke DDC gently */
> > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> > index 38ffcb4..fe06148 100644
> > --- a/include/drm/drm_dp_helper.h
> > +++ b/include/drm/drm_dp_helper.h
> > @@ -221,7 +221,8 @@
> > # define DP_PSR_FRAME_CAPTURE (1 << 3)
> >
> > #define DP_SINK_COUNT 0x200
> > -# define DP_SINK_COUNT_MASK(31 << 0)
> > +/* prior to 1.2 bit 7 was reserved mbz */
> > +# define DP_GET_SINK_COUNT(x) x) & 0x80) >> 1) | ((x) &
> > 0x3f))
> > # define DP_SINK_CP_READY (1 << 6)
> >
> > #define DP_DEVICE_SERVICE_IRQ_VECTOR 0x201
> > --
> > 1.7.7.6
> >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
>
> --
> Paulo Zanoni
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Intel-gfx] [PATCH 3/4] drm/i915/dp: Fetch downstream port info if needed during DPCD fetch
On Thu, Sep 20, 2012 at 03:28:45PM +0300, Jani Nikula wrote:
> On Tue, 18 Sep 2012, Adam Jackson wrote:
> > v2: Fix parenthesis mismatch, spotted by Jani Nikula
> >
> > Tested-by: Takashi Iwai
> > Signed-off-by: Adam Jackson
> > ---
> > drivers/gpu/drm/i915/intel_dp.c | 25 -
> > 1 files changed, 20 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index ace757a..098119e 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -39,6 +39,7 @@
> > #include "drm_dp_helper.h"
> >
> > #define DP_RECEIVER_CAP_SIZE 0xf
> > +#define DP_MAX_DOWNSTREAM_PORTS 0xf
>
> That should be 0x10. It doesn't matter in this series, but would be nice
> to fix it for correctness. Sorry I didn't spot this the first time
> around.
>
> Otherwise, on the series,
>
> Reviewed-by: Jani Nikula
Ok, I've merged these 4 patches, with the #define fixed and a small merge
conflict resolved. Please yell if I've botched things up ...
Thanks, Daniel
>
>
> > #define DP_LINK_STATUS_SIZE6
> > #define DP_LINK_CHECK_TIMEOUT (10 * 1000)
> >
> > @@ -56,6 +57,7 @@ struct intel_dp {
> > uint8_t link_bw;
> > uint8_t lane_count;
> > uint8_t dpcd[DP_RECEIVER_CAP_SIZE];
> > + uint8_t downstream_ports[DP_MAX_DOWNSTREAM_PORTS];
> > struct i2c_adapter adapter;
> > struct i2c_algo_dp_aux_data algo;
> > bool is_pch_edp;
> > @@ -1968,12 +1970,25 @@ static bool
> > intel_dp_get_dpcd(struct intel_dp *intel_dp)
> > {
> > if (intel_dp_aux_native_read_retry(intel_dp, 0x000, intel_dp->dpcd,
> > - sizeof(intel_dp->dpcd)) &&
> > - (intel_dp->dpcd[DP_DPCD_REV] != 0)) {
> > - return true;
> > - }
> > + sizeof(intel_dp->dpcd)) == 0)
> > + return false; /* aux transfer failed */
> >
> > - return false;
> > + if (intel_dp->dpcd[DP_DPCD_REV] == 0)
> > + return false; /* DPCD not present */
> > +
> > + if (!(intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] &
> > + DP_DWN_STRM_PORT_PRESENT))
> > + return true; /* native DP sink */
> > +
> > + if (intel_dp->dpcd[DP_DPCD_REV] == 0x10)
> > + return true; /* no per-port downstream info */
> > +
> > + if (intel_dp_aux_native_read_retry(intel_dp, DP_DOWNSTREAM_PORT_0,
> > + intel_dp->downstream_ports,
> > + DP_MAX_DOWNSTREAM_PORTS) == 0)
> > + return false; /* downstream port status fetch failed */
> > +
> > + return true;
> > }
> >
> > static void
> > --
> > 1.7.7.6
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
Re: -next trees
On 09/26/2012 12:00 PM, Adam Jackson wrote: On Tue, 2012-09-25 at 13:47 -0500, Ian Pilcher wrote: 1. The display (LG L246WP) is confused by *any* InfoFrames. If this is still the case after applying: commit adf00b26d18e1b3570451296e03bcb20e4798cdd Author: Paulo Zanoni Date: Tue Sep 25 13:23:34 2012 -0300 drm/i915: make sure we write all the DIP data bytes Then I suspect I'm compelled to agree that we need a quirk to forcibly disable InfoFrames entirely. I don't like to be difficult about this, but the HDMI spec is quite clear that sinks _must_ accept InfoFrames defined in either the CEA or HDMI specs, so if we're seeing that class of failure I tend to strongly suspect our drivers first. I just tested with that patch applied, and the problem still exists, so consider yourself compelled. Unless you object, I will go ahead and create a patch series that does only: - user-defined EDID quirks - DISABLE_INFOFRAMES quirk - DISABLE_INFOFRAMES quirk for LG L246WP (I will specifically *not* address the audio issue in this series.) 3. drm_detect_monitor_audio is returning true for the LG L246WP, which definitely doesn't have any audio capabilities. This may be a bug in the display's EDID, or it may be a parsing error. The display is definitely a filthy liar then: Audio data block Linear PCM, max channels 1 Supported sample rates (kHz): 48 44.1 32 Supported sample sizes (bits): 24 20 16 Hooray for hardware. Not sure what the logic should be for whether to send HDMI audio or not, I'll re-read the appropriate scrolls. Well, if hardware didn't suck we wouldn't need quirks. If you'd like, I can generate a second patch series that adds some or all of: - NO_AUDIO quirk - drm_monitor_has_hdmi_audio() function - NO_AUDIO quirk for LG L246WP (kind of redundant if no InfoFrames are being sent anyway, but still technically accurate) Let me know if you'd like any or all of those. Thanks! -- Ian Pilcher arequip...@gmail.com "If you're going to shift my paradigm ... at least buy me dinner first." ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
radeon: Regression between v3.6-rc4 and v3.6-rc6: unable to allocate a PPLL
> -Original Message- > From: Andres Freund [mailto:andres at anarazel.de] > Sent: Wednesday, September 26, 2012 9:41 AM > To: Dan Carpenter > Cc: Deucher, Alexander; LKML; David Airlie; dri-devel at lists.freedesktop.org > Subject: Re: radeon: Regression between v3.6-rc4 and v3.6-rc6: unable to > allocate a PPLL > > On Wednesday, September 26, 2012 03:00:09 PM Dan Carpenter wrote: > > This is fixed now? > Its been reverted in 2f1f4d9b60396d2df4cff829bd5376ffc8ed9a2c which is in > rc6. > > On Monday, September 17, 2012 09:30:12 PM Deucher, Alexander wrote: > Sorry, I somehow accidentally marked your email as read and thus didn't > notice it. > > > I think I see the problem. I think it's a limitation of the current current > modesetting API. The current API sets up each display independently which > doesn't work so well if there are resource restrictions. There shouldn't be > any contention on your board since you are only using 2 non-DP displays. It > looks like X is mapping different crtcs to displays than the kernel fb. > Initially the kernel set up the follow: > > > [2.134901] [drm] crtc 0 using pll 0x2 > > > [2.362257] [drm] crtc 1 using pll 0x1 > > > [2.386709] [drm] crtc 2 using pll 0x0 > > > > Crtc 0 -> DCPLL -> DP > > Crtc 1 -> PPLL2 -> DVI > > Crtc 2 -> PPLL1 -> DVI > > > > When X loads, it tried to set a different crtc to display mapping: > > > [ 60.679310] [drm] crtc 0 using pll 0xff > > > [ 60.789183] [drm] crtc 1 using pll 0x2 > > > [ 60.819594] [drm] crtc 2 using pll 0x1 > > > > Crtc 0 -> INVALID -> DVI 0 > > Crtc 1 -> DCPLL -> DP > > Crtc 2 -> PPLL2 -> DVI 1 > > > > Crtc 0 should have used PPLL1 or PPLL2, but they were already in use by > > crtc 1 and crtc 2 from the previous modeset. Since the modeset API is > > not atomic, it doesn't have the whole picture. I'm not sure of a good > > solution right now prior to the new atomic modeset API that is under > > discussion. I guess we can revert the patch for 3.6. For 3.7 I guess we > > need to validate the actual connector to make sure we aren't trying to set > > a different configuration relating to the same connector without first > > tearing down the first one. In the interim, you should be able to work > > around it by disabling the non-DP outputs and then bringing than back up. > Thanks! That explanation makes sense. I can work around it just fine, starting > X multiple times works which coincides nicely with your explanation. > > The code in the 3.7 branch doesn't do that extended validation yet, rigth? If > you want/need you can CC for testing once thats ready. It should handle it now. If you could test it that would be great. Alex
[PATCH V6 2/2] video: drm: exynos: Add device tree support
2012/9/26 Mark Brown : > On Wed, Sep 26, 2012 at 12:03:44AM +0900, Inki Dae wrote: >> 2012/9/25 Laurent Pinchart : > >> > Aren't DT bindings considered as an ABI, and required to be supported more >> > or >> > less forever ? If you merge this DT binding you'll have to keep supporting >> > it. >> > That's why DT bindings should not be rushed in. > >> is ABI required for DT binding? I know DT binding parses just lcd >> timing data from device tree file so ABI isn't needed. but when it >> comes to DT, I'm novice yet so there may be my missing point. could >> you tell me why DT bindings are considered as an ABI? if there is my >> missing point, will consider it again. > > It's supposed to be possible to ship a DT with a board and then boot any > OS or OS version on the board. If the meaning of the DT keeps changing > then this becomes impossible, you need to keep changing the DT when you > change the thing that parses it (rendering the whole exercise pointless). > thank you for your comments. got it. DT is built as an binary(dtb) and the dtb file should be re-used without any modifications. will keep this patch until the videomode helper will be merged to mainline so that this could be modified based on videomode helper later. > ___ > linux-arm-kernel mailing list > linux-arm-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
radeon: Regression between v3.6-rc4 and v3.6-rc6: unable to allocate a PPLL
> -Original Message- > From: Dan Carpenter [mailto:dan.carpenter at oracle.com] > Sent: Wednesday, September 26, 2012 9:00 AM > To: Deucher, Alexander > Cc: Andres Freund; LKML; David Airlie; dri-devel at lists.freedesktop.org > Subject: Re: radeon: Regression between v3.6-rc4 and v3.6-rc6: unable to > allocate a PPLL > > This is fixed now? It should be. The patch was reverted for 3.6. Alex > > regards, > dan carpenter
-next trees
On Tue, 2012-09-25 at 13:47 -0500, Ian Pilcher wrote: > In the meantime, I would like to move the ball forward on this issue. > As I see it, there 3 issues that have become conflated: > > 1. The display (LG L246WP) is confused by *any* InfoFrames. If this is still the case after applying: commit adf00b26d18e1b3570451296e03bcb20e4798cdd Author: Paulo Zanoni Date: Tue Sep 25 13:23:34 2012 -0300 drm/i915: make sure we write all the DIP data bytes Then I suspect I'm compelled to agree that we need a quirk to forcibly disable InfoFrames entirely. I don't like to be difficult about this, but the HDMI spec is quite clear that sinks _must_ accept InfoFrames defined in either the CEA or HDMI specs, so if we're seeing that class of failure I tend to strongly suspect our drivers first. > 3. drm_detect_monitor_audio is returning true for the LG L246WP, which > definitely doesn't have any audio capabilities. This may be a bug > in the display's EDID, or it may be a parsing error. The display is definitely a filthy liar then: Audio data block Linear PCM, max channels 1 Supported sample rates (kHz): 48 44.1 32 Supported sample sizes (bits): 24 20 16 Hooray for hardware. Not sure what the logic should be for whether to send HDMI audio or not, I'll re-read the appropriate scrolls. - ajax -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120926/8a4e208b/attachment.pgp>
inux-next: Tree for Sept 26 (not bootable on AMD64: thermal|acpi|drm/i915|pci related?)
On Wed, 26 Sep 2012, Sedat Dilek wrote: > > on my Ubuntu/precise AMD64 today's Linux-Next runs into the following > call-trace (machine freezes): > > Sep 26 19:22:58 fambox kernel: [ 11.124739] BUG: unable to handle > kernel NULL pointer dereference at 0018 > Sep 26 19:22:58 fambox kernel: [ 11.124806] IP: [] > thermal_cooling_device_register+0x2c8/0x3d0 > Sep 26 19:22:58 fambox kernel: [ 11.124869] PGD 0 > Sep 26 19:22:58 fambox kernel: [ 11.124895] Oops: [#1] SMP > Sep 26 19:22:58 fambox kernel: [ 11.124919] Modules linked in: > coretemp kvm_intel kvm snd_hda_intel(+) arc4 snd_hda_codec iwldvm > snd_hwdep ghash_clmulni_intel snd_pcm aesni_intel uvcvideo mac80211 > aes_x86_64 snd_page_alloc ablk_helper i915(+) snd_seq_midi cryptd > videobuf2_vmalloc snd_seq_midi_event xts videobuf2_memops lrw > snd_rawmidi videobuf2_core joydev gf128mul videodev snd_seq > snd_seq_device hid_generic snd_timer drm_kms_helper iwlwifi drm snd > psmouse i2c_algo_bit soundcore btusb microcode serio_raw > samsung_laptop wmi cfg80211 bluetooth mei mac_hid video lpc_ich lp > parport ext4 jbd2 usbhid hid r8169 > Sep 26 19:22:58 fambox kernel: [ 11.125319] CPU 2 > Sep 26 19:22:58 fambox kernel: [ 11.125332] Pid: 579, comm: modprobe > Not tainted 3.6.0-rc7-next20120926-2-iniza-generic #1 SAMSUNG > ELECTRONICS CO., LTD. 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH > Sep 26 19:22:58 fambox kernel: [ 11.125401] RIP: > 0010:[] [] > thermal_cooling_device_register+0x2c8/0x3d0 > Sep 26 19:22:58 fambox kernel: [ 11.125450] RSP: > 0018:88010f23d838 EFLAGS: 00010246 > Sep 26 19:22:58 fambox kernel: [ 11.125475] RAX: > RBX: 88010bfd4c00 RCX: 0001 > Sep 26 19:22:58 fambox kernel: [ 11.125507] RDX: > RSI: 0282 RDI: 0282 > Sep 26 19:22:58 fambox kernel: [ 11.125539] RBP: 88010f23d878 > R08: R09: 0001 > Sep 26 19:22:58 fambox kernel: [ 11.125570] R10: 8801054fc460 > R11: R12: 88010bfd4c04 > Sep 26 19:22:58 fambox kernel: [ 11.125602] R13: 88011a73e000 > R14: R15: > Sep 26 19:22:58 fambox kernel: [ 11.125634] FS: > 7f6b8da29700() GS:88011fa8() > knlGS: > Sep 26 19:22:58 fambox kernel: [ 11.125670] CS: 0010 DS: ES: > CR0: 80050033 > Sep 26 19:22:58 fambox kernel: [ 11.125697] CR2: 0018 > CR3: 000110185000 CR4: 000407e0 > Sep 26 19:22:58 fambox kernel: [ 11.125729] DR0: > DR1: DR2: > Sep 26 19:22:58 fambox kernel: [ 11.125761] DR3: > DR6: 0ff0 DR7: 0400 > Sep 26 19:22:58 fambox kernel: [ 11.125793] Process modprobe (pid: > 579, threadinfo 88010f23c000, task 880116648000) > Sep 26 19:22:58 fambox kernel: [ 11.127133] Stack: > Sep 26 19:22:58 fambox kernel: [ 11.128461] 88011a5d9098 > 88010d74c300 88010f23d878 880110b06480 > Sep 26 19:22:58 fambox kernel: [ 11.129755] 88010bfd1000 > 88011a5d9098 88010d74c300 88011a625000 > Sep 26 19:22:58 fambox kernel: [ 11.130943] 88010f23d958 > a00e5868 811fa033 > Sep 26 19:22:58 fambox kernel: [ 11.132749] Call Trace: > Sep 26 19:22:58 fambox kernel: [ 11.133939] [] > acpi_video_bus_add+0x9ba/0xce6 [video] > Sep 26 19:22:58 fambox kernel: [ 11.135130] [] ? > sysfs_addrm_finish+0x33/0xc0 > Sep 26 19:22:58 fambox kernel: [ 11.136313] [] > acpi_device_probe+0x4e/0x11c > Sep 26 19:22:58 fambox kernel: [ 11.137482] [] > driver_probe_device+0x7b/0x240 > Sep 26 19:22:58 fambox kernel: [ 11.138642] [] > __driver_attach+0xab/0xb0 > Sep 26 19:22:58 fambox kernel: [ 11.139798] [] ? > driver_probe_device+0x240/0x240 > Sep 26 19:22:58 fambox kernel: [ 11.140981] [] > bus_for_each_dev+0x56/0x90 > Sep 26 19:22:58 fambox kernel: [ 11.142129] [] > driver_attach+0x1e/0x20 > Sep 26 19:22:58 fambox kernel: [ 11.143264] [] > bus_add_driver+0x190/0x290 > Sep 26 19:22:58 fambox kernel: [ 11.13] [] > driver_register+0x7a/0x160 > Sep 26 19:22:58 fambox kernel: [ 11.145583] [] > acpi_bus_register_driver+0x43/0x45 > Sep 26 19:22:58 fambox kernel: [ 11.146871] [] > acpi_video_register+0x20/0x39 [video] > Sep 26 19:22:58 fambox kernel: [ 11.148167] [] > i915_driver_load+0x83d/0xea0 [i915] > Sep 26 19:22:58 fambox kernel: [ 11.149451] [] > drm_get_pci_dev+0x191/0x2b0 [drm] > Sep 26 19:22:58 fambox kernel: [ 11.150739] [] > i915_pci_probe+0x4f/0x57 [i915] > Sep 26 19:22:58 fambox kernel: [ 11.152015] [] > local_pci_probe+0x79/0x100 > Sep 26 19:22:58 fambox kernel: [ 11.153287] [] > pci_device_probe+0x109/0x130 > Sep 26 19:22:58 fambox kernel: [ 11.154546] [] > driver_probe_device+0x7b/0x240 > Sep 26 19:22:58 fambox kernel: [ 11.155796] [] > __driver_attach+0xab/0xb0 > Sep 26 19:22:58 fambox kern
[pull] last drm-intel-next pull for 3.7
Hi Dave, Last pile of stuff for 3.7, essentially just a bunch of bigger fixes and a few less intrusive features: - cpu freq interface in sysfs from Ben - cpu edp fixes and some related cleanups - write-combining ptes for pre-gen6 (Chris) - basic CADL support (Peter Wu), this fixes quite a few issues with backlights ... - rework of the gem backing pages handling (preps for stolen mem handling) from Chris - some more cleanup-fallout from the modeset-rework On top of that I've done a backmerge of -rc7(since the conflicts got too messy and I've pushed out broken merged trees too often). I've also included 3 fixes on top of what QA beat on: - Fix for a infoframe handling regression in 3.5 - infoframe blows up too often and 3.6 is pretty much done, so I'd like to merge that through -next and the stable process and give it more exposure before it lands in a stable tree. - ioctl cosmetics^Wspelling fix in the structs (userspace won't be affected, since all existing userspace uses private copies of the ioctl struct definitions, and the struct layout itself is abi compatible). - Bugfix for a regression introduced in this pull's testing cycle. Besides the regression in the ilk debugfs code QA reported new DP issues, but afact all old stuff, just new variations of existing bugs. I hope we can pour quite some manpower into our DP code from Intel's sides for the next cycle. Maybe even extract some shared logic, since it sounds like we'll eventually need quircks like for edid in dp-land :( Cheers, Daniel PS: Note that due to the backmerge I've manually frobbed the shortlog again to exclude anything merged through Linus' tree. The following changes since commit 3b7a89fce3e3dc96b549d6d829387b4439044d0d: drm/i915: fix OOPS in lid_notify (2012-09-18 00:59:37 +0200) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel for-airlied for you to fetch changes up to f531dcb23f9a5c6ad77e451459df965dc9a0c0c8: drm/i915: Wrap external callers to IPS state with appropriate locks (2012-09-26 09:24:54 +0200) Ben Widawsky (10): drm/i915: placeholder getparam drm/i915: variable renames drm/i915: #define gpu freq multipler drm/i915: Add current/max/min GPU freq to sysfs drm/i915: POSTING_READ the new rps value drm/i915: Error checks in gen6_set_rps drm/i915: Add setters for min/max frequency drm/i915: Show render P state thresholds in sysfs drm/i915: Fix !CONFIG_PM sysfs for real this time drm/i915: s/cacheing/caching/ Chris Wilson (11): drm/i915: Introduce drm_i915_gem_object_ops drm/i915: Pin backing pages whilst exporting through a dmabuf vmap drm/i915: Pin backing pages for pwrite drm/i915: Pin backing pages for pread drm/i915: Replace the array of pages with a scatterlist drm/i915: Drop the misleading cast to the wrong user pointer type drm/i915: Limit the ioremap of the PCI bar to the registers agp/intel: Use a write-combining map for updating PTEs drm/i915: Convert the dmabuf object to use the new i915_gem_object_ops drm/i915: Assert that the exec object lookup table is a power-of-two drm/i915: Wrap external callers to IPS state with appropriate locks Daniel Vetter (12): drm/i915: rip out early dp port write for gm45/ilk drm/i915: add encoder->pre_enable/post_disable drm/i915: clean up the cpu edp pll special case drm/i915: robustify edp_pll_on/off drm/i915: rip out dp port enabling cludges^Wchecks drm/i915: disable the cpu edp port after the cpu pipe drm/i915: rip out edp special case from dp_link_down drm/i915: rip out intel_disable_pch_ports drm/i915: don't disable fdi links harder in ilk_crtc_enable drm/i915: don't call dpms funcs after set_mode drm/i915: update dpms property in set_mode Merge tag 'v3.6-rc7' into drm-intel-next-queued Lekensteyn (1): i915: initialize CADL in opregion Paulo Zanoni (5): drm/i915: extract ironlake_set_pipeconf form ironlake_crtc_mode_set drm/i915: simplify setting DSPCNTR inside ironlake_crtc_mode_set drm/i915: extract compute_clocks from ironlake_crtc_mode_set drm/i915: BUG() on unexpected HDMI register drm/i915: make sure we write all the DIP data bytes Wang Xingchao (1): drm/i915: HDMI - Clear Audio Enable bit for Hot Plug unconditionally -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCHv8 18/26] v4l: add buffer exporting via dmabuf
Hi Hans,
Thank your for your comments.
On 09/26/2012 08:39 AM, Hans Verkuil wrote:
> On Tue September 25 2012 18:30:43 Tomasz Stanislawski wrote:
>> Hi Hans,
>> Thank you for review.
>> Please refer to the comments below.
>>
>> On 08/22/2012 01:41 PM, Hans Verkuil wrote:
>>> On Tue August 14 2012 17:34:48 Tomasz Stanislawski wrote:
This patch adds extension to V4L2 api. It allow to export a mmap buffer as
file
descriptor. New ioctl VIDIOC_EXPBUF is added. It takes a buffer offset
used by
mmap and return a file descriptor on success.
Signed-off-by: Tomasz Stanislawski
Signed-off-by: Kyungmin Park
---
drivers/media/video/v4l2-compat-ioctl32.c |1 +
drivers/media/video/v4l2-dev.c|1 +
drivers/media/video/v4l2-ioctl.c | 15 +++
include/linux/videodev2.h | 26
++
include/media/v4l2-ioctl.h|2 ++
5 files changed, 45 insertions(+)
>>
>> [snip]
>>
diff --git a/drivers/media/video/v4l2-ioctl.c
b/drivers/media/video/v4l2-ioctl.c
index dffd3c9..c4e8c7e 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -458,6 +458,14 @@ static void v4l_print_buffer(const void *arg, bool
write_only)
tc->type, tc->flags, tc->frames, *(__u32
*)tc->userbits);
}
+static void v4l_print_exportbuffer(const void *arg, bool write_only)
+{
+ const struct v4l2_exportbuffer *p = arg;
+
+ pr_cont("fd=%d, mem_offset=%lx, flags=%lx\n",
+ p->fd, (unsigned long)p->mem_offset, (unsigned long)p->flags);
>>>
>>> Why the unsigned long casts?
>>>
>>
>> It is needed to avoid compiler warnings on machines where "%lx" is not
>> compatible with u32.
>
> Why not use %x instead of %lx?
>
Ok. '%x' or '%08x' should be compatible with u32.
Hopefully, no one is using V4L2 on 16-bit machines :).
+}
+
static void v4l_print_create_buffers(const void *arg, bool write_only)
{
const struct v4l2_create_buffers *p = arg;
>>
>> [snip]
>>
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 7f918dc..b5d058b 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -688,6 +688,31 @@ struct v4l2_buffer {
#define V4L2_BUF_FLAG_NO_CACHE_INVALIDATE 0x0800
#define V4L2_BUF_FLAG_NO_CACHE_CLEAN 0x1000
+/**
+ * struct v4l2_exportbuffer - export of video buffer as DMABUF file
descriptor
+ *
+ * @fd: file descriptor associated with DMABUF (set by driver)
+ * @mem_offset: buffer memory offset as returned by VIDIOC_QUERYBUF in
struct
+ *v4l2_buffer::m.offset (for single-plane formats) or
+ *v4l2_plane::m.offset (for multi-planar formats)
+ * @flags:flags for newly created file, currently only O_CLOEXEC
is
+ *supported, refer to manual of open syscall for more
details
+ *
+ * Contains data used for exporting a video buffer as DMABUF file
descriptor.
+ * The buffer is identified by a 'cookie' returned by VIDIOC_QUERYBUF
+ * (identical to the cookie used to mmap() the buffer to userspace). All
+ * reserved fields must be set to zero. The field reserved0 is expected to
+ * become a structure 'type' allowing an alternative layout of the
structure
+ * content. Therefore this field should not be used for any other
extensions.
+ */
+struct v4l2_exportbuffer {
+ __u32 fd;
+ __u32 reserved0;
+ __u32 mem_offset;
+ __u32 flags;
+ __u32 reserved[12];
+};
>>>
>>> OK, I realized that we also need a type field here: you need the type field
>>> (same as in v4l2_buffer) to know which queue the mem_offset refers to. For
>>> M2M devices you have two queues, so you need this information.
>>
>> I do not agree with you. The mmap() does not need buffer_type.
>> So VIDIOC_EXPBUF should not need the field either.
>> Please refer to patch "[PATCHv8 26/26] v4l: s5p-mfc: support for dmabuf
>> exporting"
>> for example how to deal without buffer_type.
>>
>>>
>>> Is there any reason not to use __u32 memory instead of __u32 reserved0?
>>> I really dislike 'reserved0'. It's also very inconsistent with the other
>>> buffer ioctls which all have type+memory fields.
>>
>> The type is not needed for exporting if mem_offset is available like in
>> mmap() case.
>> The memory is not needed because exporting is available only for MMAP
>> buffers.
>
> Today, yes. Perhaps not in the future. mem_offset uniquely identifies a
> buffer,
> but only in the MMAP case. That happens to be the only one we support at the
> moment, but in the future we might want to support others as w
drm/nouveau/fence: convert to exec engine, and improve channel sync
Hello Ben Skeggs,
This is a semi-automatic email about new static checker warnings.
I'm not sure why I didn't send this when the code was first submitted.
The patch 5e120f6e4b3f: "drm/nouveau/fence: convert to exec engine,
and improve channel sync" from Apr 30, 2012, leads to the following
Smatch complaint:
drivers/gpu/drm/nouveau/nouveau_fence.c:204 nouveau_fence_new()
warn: variable dereferenced before check 'chan' (see line 196)
drivers/gpu/drm/nouveau/nouveau_fence.c
195
196 if (unlikely(!chan->engctx[NVOBJ_ENGINE_FENCE]))
New dereference.
197 return -ENODEV;
198
199 fence = kzalloc(sizeof(*fence), GFP_KERNEL);
200 if (!fence)
201 return -ENOMEM;
202 kref_init(&fence->kref);
203
204 if (chan) {
^^
Old check.
205 ret = nouveau_fence_emit(fence, chan);
206 if (ret)
regards,
dan carpenter
See also:
inux-next: Tree for Sept 26 (gpu/drm/i915)
On 09/25/2012 11:44 PM, Stephen Rothwell wrote: > Hi all, > > Changes since 201209025: > on x86_64: drivers/gpu/drm/i915/i915_sysfs.c: In function 'i915_teardown_sysfs': drivers/gpu/drm/i915/i915_sysfs.c:228:49: error: 'rc6_attr_group' undeclared (first use in this function) Full randconfig file is attached. -- ~Randy -- next part -- An embedded and charset-unspecified text was scrubbed... Name: config-r7804 URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120926/609f0f39/attachment-0001.ksh>
Re: -next trees
On Tue, 2012-09-25 at 13:47 -0500, Ian Pilcher wrote: > In the meantime, I would like to move the ball forward on this issue. > As I see it, there 3 issues that have become conflated: > > 1. The display (LG L246WP) is confused by *any* InfoFrames. If this is still the case after applying: commit adf00b26d18e1b3570451296e03bcb20e4798cdd Author: Paulo Zanoni Date: Tue Sep 25 13:23:34 2012 -0300 drm/i915: make sure we write all the DIP data bytes Then I suspect I'm compelled to agree that we need a quirk to forcibly disable InfoFrames entirely. I don't like to be difficult about this, but the HDMI spec is quite clear that sinks _must_ accept InfoFrames defined in either the CEA or HDMI specs, so if we're seeing that class of failure I tend to strongly suspect our drivers first. > 3. drm_detect_monitor_audio is returning true for the LG L246WP, which > definitely doesn't have any audio capabilities. This may be a bug > in the display's EDID, or it may be a parsing error. The display is definitely a filthy liar then: Audio data block Linear PCM, max channels 1 Supported sample rates (kHz): 48 44.1 32 Supported sample sizes (bits): 24 20 16 Hooray for hardware. Not sure what the logic should be for whether to send HDMI audio or not, I'll re-read the appropriate scrolls. - ajax signature.asc Description: This is a digitally signed message part ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv8 18/26] v4l: add buffer exporting via dmabuf
On Tue September 25 2012 18:30:43 Tomasz Stanislawski wrote:
> Hi Hans,
> Thank you for review.
> Please refer to the comments below.
>
> On 08/22/2012 01:41 PM, Hans Verkuil wrote:
> > On Tue August 14 2012 17:34:48 Tomasz Stanislawski wrote:
> >> This patch adds extension to V4L2 api. It allow to export a mmap buffer as
> >> file
> >> descriptor. New ioctl VIDIOC_EXPBUF is added. It takes a buffer offset
> >> used by
> >> mmap and return a file descriptor on success.
> >>
> >> Signed-off-by: Tomasz Stanislawski
> >> Signed-off-by: Kyungmin Park
> >> ---
> >> drivers/media/video/v4l2-compat-ioctl32.c |1 +
> >> drivers/media/video/v4l2-dev.c|1 +
> >> drivers/media/video/v4l2-ioctl.c | 15 +++
> >> include/linux/videodev2.h | 26
> >> ++
> >> include/media/v4l2-ioctl.h|2 ++
> >> 5 files changed, 45 insertions(+)
> >>
>
> [snip]
>
> >> diff --git a/drivers/media/video/v4l2-ioctl.c
> >> b/drivers/media/video/v4l2-ioctl.c
> >> index dffd3c9..c4e8c7e 100644
> >> --- a/drivers/media/video/v4l2-ioctl.c
> >> +++ b/drivers/media/video/v4l2-ioctl.c
> >> @@ -458,6 +458,14 @@ static void v4l_print_buffer(const void *arg, bool
> >> write_only)
> >>tc->type, tc->flags, tc->frames, *(__u32
> >> *)tc->userbits);
> >> }
> >>
> >> +static void v4l_print_exportbuffer(const void *arg, bool write_only)
> >> +{
> >> + const struct v4l2_exportbuffer *p = arg;
> >> +
> >> + pr_cont("fd=%d, mem_offset=%lx, flags=%lx\n",
> >> + p->fd, (unsigned long)p->mem_offset, (unsigned long)p->flags);
> >
> > Why the unsigned long casts?
> >
>
> It is needed to avoid compiler warnings on machines where "%lx" is not
> compatible with u32.
Why not use %x instead of %lx?
> >> +}
> >> +
> >> static void v4l_print_create_buffers(const void *arg, bool write_only)
> >> {
> >>const struct v4l2_create_buffers *p = arg;
>
> [snip]
>
> >> diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
> >> index 7f918dc..b5d058b 100644
> >> --- a/include/linux/videodev2.h
> >> +++ b/include/linux/videodev2.h
> >> @@ -688,6 +688,31 @@ struct v4l2_buffer {
> >> #define V4L2_BUF_FLAG_NO_CACHE_INVALIDATE 0x0800
> >> #define V4L2_BUF_FLAG_NO_CACHE_CLEAN 0x1000
> >>
> >> +/**
> >> + * struct v4l2_exportbuffer - export of video buffer as DMABUF file
> >> descriptor
> >> + *
> >> + * @fd: file descriptor associated with DMABUF (set by driver)
> >> + * @mem_offset: buffer memory offset as returned by VIDIOC_QUERYBUF in
> >> struct
> >> + *v4l2_buffer::m.offset (for single-plane formats) or
> >> + *v4l2_plane::m.offset (for multi-planar formats)
> >> + * @flags:flags for newly created file, currently only O_CLOEXEC
> >> is
> >> + *supported, refer to manual of open syscall for more
> >> details
> >> + *
> >> + * Contains data used for exporting a video buffer as DMABUF file
> >> descriptor.
> >> + * The buffer is identified by a 'cookie' returned by VIDIOC_QUERYBUF
> >> + * (identical to the cookie used to mmap() the buffer to userspace). All
> >> + * reserved fields must be set to zero. The field reserved0 is expected to
> >> + * become a structure 'type' allowing an alternative layout of the
> >> structure
> >> + * content. Therefore this field should not be used for any other
> >> extensions.
> >> + */
> >> +struct v4l2_exportbuffer {
> >> + __u32 fd;
> >> + __u32 reserved0;
> >> + __u32 mem_offset;
> >> + __u32 flags;
> >> + __u32 reserved[12];
> >> +};
> >
> > OK, I realized that we also need a type field here: you need the type field
> > (same as in v4l2_buffer) to know which queue the mem_offset refers to. For
> > M2M devices you have two queues, so you need this information.
>
> I do not agree with you. The mmap() does not need buffer_type.
> So VIDIOC_EXPBUF should not need the field either.
> Please refer to patch "[PATCHv8 26/26] v4l: s5p-mfc: support for dmabuf
> exporting"
> for example how to deal without buffer_type.
>
> >
> > Is there any reason not to use __u32 memory instead of __u32 reserved0?
> > I really dislike 'reserved0'. It's also very inconsistent with the other
> > buffer ioctls which all have type+memory fields.
>
> The type is not needed for exporting if mem_offset is available like in
> mmap() case.
> The memory is not needed because exporting is available only for MMAP buffers.
Today, yes. Perhaps not in the future. mem_offset uniquely identifies a buffer,
but only in the MMAP case. That happens to be the only one we support at the
moment, but in the future we might want to support others as well.
> I see two ways to describe a buffer for exporting:
> a) by mem_offset
> b) by (buffer_type, index, plane_index) tuple
Actually a (buffer_type, index, plane_index, memory) tuple.
>
> For know I prefer to implement on
Re: Problem: Internal LVDS screen alignment: the display shows a black "frame" at the bottom and is cut off at the top in 3.6-rc5+ with gma500 (REGRESSION)
On Wed, Sep 26, 2012 at 4:33 PM, Alan Cox wrote: > > > This happens _only in X_ and not on the console. My system and Xorg is > > very old. (Ubuntu 9.10). > > Make sure you have the framebuffer driver in use not the vesa one if > you are using an old X11. If you use the vesa driver then randomness > will occur. No, I'm definitely on fbdev: "Section "Device" Identifier "GMA500" Driver "fbdev" EndSection" ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: radeon: Regression between v3.6-rc4 and v3.6-rc6: unable to allocate a PPLL
On Wednesday, September 26, 2012 03:00:09 PM Dan Carpenter wrote: > This is fixed now? Its been reverted in 2f1f4d9b60396d2df4cff829bd5376ffc8ed9a2c which is in rc6. On Monday, September 17, 2012 09:30:12 PM Deucher, Alexander wrote: Sorry, I somehow accidentally marked your email as read and thus didn't notice it. > I think I see the problem. I think it's a limitation of the current current modesetting API. The current API sets up each display independently which doesn't work so well if there are resource restrictions. There shouldn't be any contention on your board since you are only using 2 non-DP displays. It looks like X is mapping different crtcs to displays than the kernel fb. Initially the kernel set up the follow: > > [2.134901] [drm] crtc 0 using pll 0x2 > > [2.362257] [drm] crtc 1 using pll 0x1 > > [2.386709] [drm] crtc 2 using pll 0x0 > > Crtc 0 -> DCPLL -> DP > Crtc 1 -> PPLL2 -> DVI > Crtc 2 -> PPLL1 -> DVI > > When X loads, it tried to set a different crtc to display mapping: > > [ 60.679310] [drm] crtc 0 using pll 0xff > > [ 60.789183] [drm] crtc 1 using pll 0x2 > > [ 60.819594] [drm] crtc 2 using pll 0x1 > > Crtc 0 -> INVALID -> DVI 0 > Crtc 1 -> DCPLL -> DP > Crtc 2 -> PPLL2 -> DVI 1 > > Crtc 0 should have used PPLL1 or PPLL2, but they were already in use by > crtc 1 and crtc 2 from the previous modeset. Since the modeset API is > not atomic, it doesn't have the whole picture. I'm not sure of a good > solution right now prior to the new atomic modeset API that is under > discussion. I guess we can revert the patch for 3.6. For 3.7 I guess we > need to validate the actual connector to make sure we aren't trying to set > a different configuration relating to the same connector without first > tearing down the first one. In the interim, you should be able to work > around it by disabling the non-DP outputs and then bringing than back up. Thanks! That explanation makes sense. I can work around it just fine, starting X multiple times works which coincides nicely with your explanation. The code in the 3.7 branch doesn't do that extended validation yet, rigth? If you want/need you can CC for testing once thats ready. Greetings, Andres ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: radeon: Regression between v3.6-rc4 and v3.6-rc6: unable to allocate a PPLL
This is fixed now? regards, dan carpenter ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
re: drm/nouveau/fence: convert to exec engine, and improve channel sync
Hello Ben Skeggs,
This is a semi-automatic email about new static checker warnings.
I'm not sure why I didn't send this when the code was first submitted.
The patch 5e120f6e4b3f: "drm/nouveau/fence: convert to exec engine,
and improve channel sync" from Apr 30, 2012, leads to the following
Smatch complaint:
drivers/gpu/drm/nouveau/nouveau_fence.c:204 nouveau_fence_new()
warn: variable dereferenced before check 'chan' (see line 196)
drivers/gpu/drm/nouveau/nouveau_fence.c
195
196 if (unlikely(!chan->engctx[NVOBJ_ENGINE_FENCE]))
New dereference.
197 return -ENODEV;
198
199 fence = kzalloc(sizeof(*fence), GFP_KERNEL);
200 if (!fence)
201 return -ENOMEM;
202 kref_init(&fence->kref);
203
204 if (chan) {
^^
Old check.
205 ret = nouveau_fence_emit(fence, chan);
206 if (ret)
regards,
dan carpenter
See also:
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Problem: Internal LVDS screen alignment: the display shows a black "frame" at the bottom and is cut off at the top in 3.6-rc5+ with gma500 (REGRESSION)
> This happens _only in X_ and not on the console. My system and Xorg is > very old. (Ubuntu 9.10). Make sure you have the framebuffer driver in use not the vesa one if you are using an old X11. If you use the vesa driver then randomness will occur. Alan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: radeon: Regression between v3.6-rc4 and v3.6-rc6: unable to allocate a PPLL
> -Original Message- > From: Andres Freund [mailto:and...@anarazel.de] > Sent: Wednesday, September 26, 2012 9:41 AM > To: Dan Carpenter > Cc: Deucher, Alexander; LKML; David Airlie; dri-devel@lists.freedesktop.org > Subject: Re: radeon: Regression between v3.6-rc4 and v3.6-rc6: unable to > allocate a PPLL > > On Wednesday, September 26, 2012 03:00:09 PM Dan Carpenter wrote: > > This is fixed now? > Its been reverted in 2f1f4d9b60396d2df4cff829bd5376ffc8ed9a2c which is in > rc6. > > On Monday, September 17, 2012 09:30:12 PM Deucher, Alexander wrote: > Sorry, I somehow accidentally marked your email as read and thus didn't > notice it. > > > I think I see the problem. I think it's a limitation of the current current > modesetting API. The current API sets up each display independently which > doesn't work so well if there are resource restrictions. There shouldn't be > any contention on your board since you are only using 2 non-DP displays. It > looks like X is mapping different crtcs to displays than the kernel fb. > Initially the kernel set up the follow: > > > [2.134901] [drm] crtc 0 using pll 0x2 > > > [2.362257] [drm] crtc 1 using pll 0x1 > > > [2.386709] [drm] crtc 2 using pll 0x0 > > > > Crtc 0 -> DCPLL -> DP > > Crtc 1 -> PPLL2 -> DVI > > Crtc 2 -> PPLL1 -> DVI > > > > When X loads, it tried to set a different crtc to display mapping: > > > [ 60.679310] [drm] crtc 0 using pll 0xff > > > [ 60.789183] [drm] crtc 1 using pll 0x2 > > > [ 60.819594] [drm] crtc 2 using pll 0x1 > > > > Crtc 0 -> INVALID -> DVI 0 > > Crtc 1 -> DCPLL -> DP > > Crtc 2 -> PPLL2 -> DVI 1 > > > > Crtc 0 should have used PPLL1 or PPLL2, but they were already in use by > > crtc 1 and crtc 2 from the previous modeset. Since the modeset API is > > not atomic, it doesn't have the whole picture. I'm not sure of a good > > solution right now prior to the new atomic modeset API that is under > > discussion. I guess we can revert the patch for 3.6. For 3.7 I guess we > > need to validate the actual connector to make sure we aren't trying to set > > a different configuration relating to the same connector without first > > tearing down the first one. In the interim, you should be able to work > > around it by disabling the non-DP outputs and then bringing than back up. > Thanks! That explanation makes sense. I can work around it just fine, starting > X multiple times works which coincides nicely with your explanation. > > The code in the 3.7 branch doesn't do that extended validation yet, rigth? If > you want/need you can CC for testing once thats ready. It should handle it now. If you could test it that would be great. Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: radeon: Regression between v3.6-rc4 and v3.6-rc6: unable to allocate a PPLL
> -Original Message- > From: Dan Carpenter [mailto:dan.carpen...@oracle.com] > Sent: Wednesday, September 26, 2012 9:00 AM > To: Deucher, Alexander > Cc: Andres Freund; LKML; David Airlie; dri-devel@lists.freedesktop.org > Subject: Re: radeon: Regression between v3.6-rc4 and v3.6-rc6: unable to > allocate a PPLL > > This is fixed now? It should be. The patch was reverted for 3.6. Alex > > regards, > dan carpenter ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/dp: Make sink count DP 1.2 aware
On Thu, Sep 20, 2012 at 06:45:29PM -0300, Paulo Zanoni wrote:
> 2012/9/20 Adam Jackson :
> > Signed-off-by: Adam Jackson
>
> Reviewed-by: Paulo Zanoni
Both patches merged to dinq (again with Dave's irc-ack for the common
stuff).
Thanks, Daniel
>
> > ---
> > drivers/gpu/drm/i915/intel_dp.c |9 -
> > include/drm/drm_dp_helper.h |3 ++-
> > 2 files changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 813b771..00f99e5 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -2106,13 +2106,12 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp)
> > /* If we're HPD-aware, SINK_COUNT changes dynamically */
> > hpd = !!(intel_dp->downstream_ports[0] & DP_DS_PORT_HPD);
> > if (hpd) {
> > - uint8_t sink_count;
> > + uint8_t reg;
> > if (!intel_dp_aux_native_read_retry(intel_dp, DP_SINK_COUNT,
> > - &sink_count, 1))
> > + ®, 1))
> > return connector_status_unknown;
> > - sink_count &= DP_SINK_COUNT_MASK;
> > - return sink_count ? connector_status_connected
> > - : connector_status_disconnected;
> > + return DP_GET_SINK_COUNT(reg) ? connector_status_connected
> > + :
> > connector_status_disconnected;
> > }
> >
> > /* If no HPD, poke DDC gently */
> > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> > index 38ffcb4..fe06148 100644
> > --- a/include/drm/drm_dp_helper.h
> > +++ b/include/drm/drm_dp_helper.h
> > @@ -221,7 +221,8 @@
> > # define DP_PSR_FRAME_CAPTURE (1 << 3)
> >
> > #define DP_SINK_COUNT 0x200
> > -# define DP_SINK_COUNT_MASK(31 << 0)
> > +/* prior to 1.2 bit 7 was reserved mbz */
> > +# define DP_GET_SINK_COUNT(x) x) & 0x80) >> 1) | ((x) &
> > 0x3f))
> > # define DP_SINK_CP_READY (1 << 6)
> >
> > #define DP_DEVICE_SERVICE_IRQ_VECTOR 0x201
> > --
> > 1.7.7.6
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
>
> --
> Paulo Zanoni
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 3/4] drm/i915/dp: Fetch downstream port info if needed during DPCD fetch
On Thu, Sep 20, 2012 at 03:28:45PM +0300, Jani Nikula wrote:
> On Tue, 18 Sep 2012, Adam Jackson wrote:
> > v2: Fix parenthesis mismatch, spotted by Jani Nikula
> >
> > Tested-by: Takashi Iwai
> > Signed-off-by: Adam Jackson
> > ---
> > drivers/gpu/drm/i915/intel_dp.c | 25 -
> > 1 files changed, 20 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index ace757a..098119e 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -39,6 +39,7 @@
> > #include "drm_dp_helper.h"
> >
> > #define DP_RECEIVER_CAP_SIZE 0xf
> > +#define DP_MAX_DOWNSTREAM_PORTS 0xf
>
> That should be 0x10. It doesn't matter in this series, but would be nice
> to fix it for correctness. Sorry I didn't spot this the first time
> around.
>
> Otherwise, on the series,
>
> Reviewed-by: Jani Nikula
Ok, I've merged these 4 patches, with the #define fixed and a small merge
conflict resolved. Please yell if I've botched things up ...
Thanks, Daniel
>
>
> > #define DP_LINK_STATUS_SIZE6
> > #define DP_LINK_CHECK_TIMEOUT (10 * 1000)
> >
> > @@ -56,6 +57,7 @@ struct intel_dp {
> > uint8_t link_bw;
> > uint8_t lane_count;
> > uint8_t dpcd[DP_RECEIVER_CAP_SIZE];
> > + uint8_t downstream_ports[DP_MAX_DOWNSTREAM_PORTS];
> > struct i2c_adapter adapter;
> > struct i2c_algo_dp_aux_data algo;
> > bool is_pch_edp;
> > @@ -1968,12 +1970,25 @@ static bool
> > intel_dp_get_dpcd(struct intel_dp *intel_dp)
> > {
> > if (intel_dp_aux_native_read_retry(intel_dp, 0x000, intel_dp->dpcd,
> > - sizeof(intel_dp->dpcd)) &&
> > - (intel_dp->dpcd[DP_DPCD_REV] != 0)) {
> > - return true;
> > - }
> > + sizeof(intel_dp->dpcd)) == 0)
> > + return false; /* aux transfer failed */
> >
> > - return false;
> > + if (intel_dp->dpcd[DP_DPCD_REV] == 0)
> > + return false; /* DPCD not present */
> > +
> > + if (!(intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] &
> > + DP_DWN_STRM_PORT_PRESENT))
> > + return true; /* native DP sink */
> > +
> > + if (intel_dp->dpcd[DP_DPCD_REV] == 0x10)
> > + return true; /* no per-port downstream info */
> > +
> > + if (intel_dp_aux_native_read_retry(intel_dp, DP_DOWNSTREAM_PORT_0,
> > + intel_dp->downstream_ports,
> > + DP_MAX_DOWNSTREAM_PORTS) == 0)
> > + return false; /* downstream port status fetch failed */
> > +
> > + return true;
> > }
> >
> > static void
> > --
> > 1.7.7.6
> >
> > ___
> > Intel-gfx mailing list
> > intel-...@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] last drm-intel-next pull for 3.7
Hi Dave, Last pile of stuff for 3.7, essentially just a bunch of bigger fixes and a few less intrusive features: - cpu freq interface in sysfs from Ben - cpu edp fixes and some related cleanups - write-combining ptes for pre-gen6 (Chris) - basic CADL support (Peter Wu), this fixes quite a few issues with backlights ... - rework of the gem backing pages handling (preps for stolen mem handling) from Chris - some more cleanup-fallout from the modeset-rework On top of that I've done a backmerge of -rc7(since the conflicts got too messy and I've pushed out broken merged trees too often). I've also included 3 fixes on top of what QA beat on: - Fix for a infoframe handling regression in 3.5 - infoframe blows up too often and 3.6 is pretty much done, so I'd like to merge that through -next and the stable process and give it more exposure before it lands in a stable tree. - ioctl cosmetics^Wspelling fix in the structs (userspace won't be affected, since all existing userspace uses private copies of the ioctl struct definitions, and the struct layout itself is abi compatible). - Bugfix for a regression introduced in this pull's testing cycle. Besides the regression in the ilk debugfs code QA reported new DP issues, but afact all old stuff, just new variations of existing bugs. I hope we can pour quite some manpower into our DP code from Intel's sides for the next cycle. Maybe even extract some shared logic, since it sounds like we'll eventually need quircks like for edid in dp-land :( Cheers, Daniel PS: Note that due to the backmerge I've manually frobbed the shortlog again to exclude anything merged through Linus' tree. The following changes since commit 3b7a89fce3e3dc96b549d6d829387b4439044d0d: drm/i915: fix OOPS in lid_notify (2012-09-18 00:59:37 +0200) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel for-airlied for you to fetch changes up to f531dcb23f9a5c6ad77e451459df965dc9a0c0c8: drm/i915: Wrap external callers to IPS state with appropriate locks (2012-09-26 09:24:54 +0200) Ben Widawsky (10): drm/i915: placeholder getparam drm/i915: variable renames drm/i915: #define gpu freq multipler drm/i915: Add current/max/min GPU freq to sysfs drm/i915: POSTING_READ the new rps value drm/i915: Error checks in gen6_set_rps drm/i915: Add setters for min/max frequency drm/i915: Show render P state thresholds in sysfs drm/i915: Fix !CONFIG_PM sysfs for real this time drm/i915: s/cacheing/caching/ Chris Wilson (11): drm/i915: Introduce drm_i915_gem_object_ops drm/i915: Pin backing pages whilst exporting through a dmabuf vmap drm/i915: Pin backing pages for pwrite drm/i915: Pin backing pages for pread drm/i915: Replace the array of pages with a scatterlist drm/i915: Drop the misleading cast to the wrong user pointer type drm/i915: Limit the ioremap of the PCI bar to the registers agp/intel: Use a write-combining map for updating PTEs drm/i915: Convert the dmabuf object to use the new i915_gem_object_ops drm/i915: Assert that the exec object lookup table is a power-of-two drm/i915: Wrap external callers to IPS state with appropriate locks Daniel Vetter (12): drm/i915: rip out early dp port write for gm45/ilk drm/i915: add encoder->pre_enable/post_disable drm/i915: clean up the cpu edp pll special case drm/i915: robustify edp_pll_on/off drm/i915: rip out dp port enabling cludges^Wchecks drm/i915: disable the cpu edp port after the cpu pipe drm/i915: rip out edp special case from dp_link_down drm/i915: rip out intel_disable_pch_ports drm/i915: don't disable fdi links harder in ilk_crtc_enable drm/i915: don't call dpms funcs after set_mode drm/i915: update dpms property in set_mode Merge tag 'v3.6-rc7' into drm-intel-next-queued Lekensteyn (1): i915: initialize CADL in opregion Paulo Zanoni (5): drm/i915: extract ironlake_set_pipeconf form ironlake_crtc_mode_set drm/i915: simplify setting DSPCNTR inside ironlake_crtc_mode_set drm/i915: extract compute_clocks from ironlake_crtc_mode_set drm/i915: BUG() on unexpected HDMI register drm/i915: make sure we write all the DIP data bytes Wang Xingchao (1): drm/i915: HDMI - Clear Audio Enable bit for Hot Plug unconditionally -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv8 18/26] v4l: add buffer exporting via dmabuf
Hi Hans,
Thank your for your comments.
On 09/26/2012 08:39 AM, Hans Verkuil wrote:
> On Tue September 25 2012 18:30:43 Tomasz Stanislawski wrote:
>> Hi Hans,
>> Thank you for review.
>> Please refer to the comments below.
>>
>> On 08/22/2012 01:41 PM, Hans Verkuil wrote:
>>> On Tue August 14 2012 17:34:48 Tomasz Stanislawski wrote:
This patch adds extension to V4L2 api. It allow to export a mmap buffer as
file
descriptor. New ioctl VIDIOC_EXPBUF is added. It takes a buffer offset
used by
mmap and return a file descriptor on success.
Signed-off-by: Tomasz Stanislawski
Signed-off-by: Kyungmin Park
---
drivers/media/video/v4l2-compat-ioctl32.c |1 +
drivers/media/video/v4l2-dev.c|1 +
drivers/media/video/v4l2-ioctl.c | 15 +++
include/linux/videodev2.h | 26
++
include/media/v4l2-ioctl.h|2 ++
5 files changed, 45 insertions(+)
>>
>> [snip]
>>
diff --git a/drivers/media/video/v4l2-ioctl.c
b/drivers/media/video/v4l2-ioctl.c
index dffd3c9..c4e8c7e 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -458,6 +458,14 @@ static void v4l_print_buffer(const void *arg, bool
write_only)
tc->type, tc->flags, tc->frames, *(__u32
*)tc->userbits);
}
+static void v4l_print_exportbuffer(const void *arg, bool write_only)
+{
+ const struct v4l2_exportbuffer *p = arg;
+
+ pr_cont("fd=%d, mem_offset=%lx, flags=%lx\n",
+ p->fd, (unsigned long)p->mem_offset, (unsigned long)p->flags);
>>>
>>> Why the unsigned long casts?
>>>
>>
>> It is needed to avoid compiler warnings on machines where "%lx" is not
>> compatible with u32.
>
> Why not use %x instead of %lx?
>
Ok. '%x' or '%08x' should be compatible with u32.
Hopefully, no one is using V4L2 on 16-bit machines :).
+}
+
static void v4l_print_create_buffers(const void *arg, bool write_only)
{
const struct v4l2_create_buffers *p = arg;
>>
>> [snip]
>>
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 7f918dc..b5d058b 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -688,6 +688,31 @@ struct v4l2_buffer {
#define V4L2_BUF_FLAG_NO_CACHE_INVALIDATE 0x0800
#define V4L2_BUF_FLAG_NO_CACHE_CLEAN 0x1000
+/**
+ * struct v4l2_exportbuffer - export of video buffer as DMABUF file
descriptor
+ *
+ * @fd: file descriptor associated with DMABUF (set by driver)
+ * @mem_offset: buffer memory offset as returned by VIDIOC_QUERYBUF in
struct
+ *v4l2_buffer::m.offset (for single-plane formats) or
+ *v4l2_plane::m.offset (for multi-planar formats)
+ * @flags:flags for newly created file, currently only O_CLOEXEC
is
+ *supported, refer to manual of open syscall for more
details
+ *
+ * Contains data used for exporting a video buffer as DMABUF file
descriptor.
+ * The buffer is identified by a 'cookie' returned by VIDIOC_QUERYBUF
+ * (identical to the cookie used to mmap() the buffer to userspace). All
+ * reserved fields must be set to zero. The field reserved0 is expected to
+ * become a structure 'type' allowing an alternative layout of the
structure
+ * content. Therefore this field should not be used for any other
extensions.
+ */
+struct v4l2_exportbuffer {
+ __u32 fd;
+ __u32 reserved0;
+ __u32 mem_offset;
+ __u32 flags;
+ __u32 reserved[12];
+};
>>>
>>> OK, I realized that we also need a type field here: you need the type field
>>> (same as in v4l2_buffer) to know which queue the mem_offset refers to. For
>>> M2M devices you have two queues, so you need this information.
>>
>> I do not agree with you. The mmap() does not need buffer_type.
>> So VIDIOC_EXPBUF should not need the field either.
>> Please refer to patch "[PATCHv8 26/26] v4l: s5p-mfc: support for dmabuf
>> exporting"
>> for example how to deal without buffer_type.
>>
>>>
>>> Is there any reason not to use __u32 memory instead of __u32 reserved0?
>>> I really dislike 'reserved0'. It's also very inconsistent with the other
>>> buffer ioctls which all have type+memory fields.
>>
>> The type is not needed for exporting if mem_offset is available like in
>> mmap() case.
>> The memory is not needed because exporting is available only for MMAP
>> buffers.
>
> Today, yes. Perhaps not in the future. mem_offset uniquely identifies a
> buffer,
> but only in the MMAP case. That happens to be the only one we support at the
> moment, but in the future we might want to support others as w
Re: [PATCH 2/2] drm/radeon: implement dynamic PTs allocation via SA
I've found introduced error in radeon_vm_free_pt, so will fix in next version of this patch. This one: --- a/drivers/gpu/drm/radeon/radeon_gart.c +++ b/drivers/gpu/drm/radeon/radeon_gart.c @@ -505,15 +505,6 @@ static void radeon_vm_free_pt(struct radeon_device *rdev, int driver_table_entries = (rdev->vm_manager.max_pfn >> RADEON_VM_BLOCK_SIZE); - if (vm->vm_pts->bo) + if (vm->vm_pts[i].bo) -- With best regards, Dmitry ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V6 2/2] video: drm: exynos: Add device tree support
On Wed, Sep 26, 2012 at 12:03:44AM +0900, Inki Dae wrote: > 2012/9/25 Laurent Pinchart : > > Aren't DT bindings considered as an ABI, and required to be supported more > > or > > less forever ? If you merge this DT binding you'll have to keep supporting > > it. > > That's why DT bindings should not be rushed in. > is ABI required for DT binding? I know DT binding parses just lcd > timing data from device tree file so ABI isn't needed. but when it > comes to DT, I'm novice yet so there may be my missing point. could > you tell me why DT bindings are considered as an ABI? if there is my > missing point, will consider it again. It's supposed to be possible to ship a DT with a board and then boot any OS or OS version on the board. If the meaning of the DT keeps changing then this becomes impossible, you need to keep changing the DT when you change the thing that parses it (rendering the whole exercise pointless). ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/radeon: implement dynamic PTs allocation via SA
make dynamic allocation of page tables on demand in radeon_vm_update_pte
Signed-off-by: Dmitry Cherkasov
---
drivers/gpu/drm/radeon/radeon.h | 12
drivers/gpu/drm/radeon/radeon_gart.c | 106 ++
2 files changed, 107 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index d8a61ed..f1dcdbe 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -659,6 +659,15 @@ struct radeon_ring {
/* number of entries in page table */
#define RADEON_VM_PTE_COUNT (1 << RADEON_VM_BLOCK_SIZE)
+struct radeon_pt {
+ /* BO containing the page table */
+ /* radeon_sa_bo_gpu_addr(sa_bo); */
+ struct radeon_sa_bo *bo;
+
+ /* GPU address of page table */
+ u64 gpu_addr;
+};
+
struct radeon_vm {
struct list_headlist;
struct list_headva;
@@ -671,6 +680,9 @@ struct radeon_vm {
struct radeon_fence *fence;
/* last flush or NULL if we still need to flush */
struct radeon_fence *last_flush;
+
+ /* page tables list */
+ struct radeon_pt *vm_pts;
};
struct radeon_vm_manager {
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
b/drivers/gpu/drm/radeon/radeon_gart.c
index 31d6bfa..ada8471 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -500,6 +500,19 @@ static void radeon_vm_free_pt(struct radeon_device *rdev,
struct radeon_vm *vm)
{
struct radeon_bo_va *bo_va;
+ int i;
+
+ int driver_table_entries = (rdev->vm_manager.max_pfn >>
+ RADEON_VM_BLOCK_SIZE);
+
+ if (vm->id != 0 && vm->vm_pts) {
+ for (i = 0;i < driver_table_entries; i++) {
+ if (vm->vm_pts->bo)
+ radeon_sa_bo_free(rdev, &vm->vm_pts->bo,
vm->fence);
+ }
+
+ kfree (vm->vm_pts);
+ }
if (!vm->sa_bo)
return;
@@ -563,6 +576,9 @@ int radeon_vm_alloc_pt(struct radeon_device *rdev, struct
radeon_vm *vm)
int r;
u64 *pd_addr;
int tables_size;
+ int driver_table_size = (rdev->vm_manager.max_pfn >>
+RADEON_VM_BLOCK_SIZE) *
+ sizeof(struct radeon_pt);
if (vm == NULL) {
return -EINVAL;
@@ -570,7 +586,6 @@ int radeon_vm_alloc_pt(struct radeon_device *rdev, struct
radeon_vm *vm)
/* allocate enough to cover the current VM size */
tables_size = RADEON_GPU_PAGE_ALIGN(radeon_vm_directory_size(rdev));
- tables_size += RADEON_GPU_PAGE_ALIGN(vm->last_pfn * 8);
if (vm->sa_bo != NULL) {
/* update lru */
@@ -600,6 +615,16 @@ retry:
vm->pd_gpu_addr = radeon_sa_bo_gpu_addr(vm->sa_bo);
memset(pd_addr, 0, tables_size);
+ vm->vm_pts = kmalloc(driver_table_size, GFP_KERNEL);
+
+ if (vm->vm_pts == NULL) {
+ DRM_ERROR("Cannot allocate space for driver PDE table: %d kb
\n",
+ driver_table_size / 1024);
+ return -ENOMEM;
+ }
+
+ memset(vm->vm_pts, 0, tables_size);
+
list_add_tail(&vm->list, &rdev->vm_manager.lru_vm);
return radeon_vm_bo_update_pte(rdev, vm, rdev->ring_tmp_bo.bo,
&rdev->ring_tmp_bo.bo->tbo.mem);
@@ -864,6 +889,8 @@ uint64_t radeon_vm_map_gart(struct radeon_device *rdev,
uint64_t addr)
return result;
}
+
+
/**
* radeon_vm_bo_update_pte - map a bo into the vm page table
*
@@ -886,10 +913,15 @@ int radeon_vm_bo_update_pte(struct radeon_device *rdev,
struct radeon_ring *ring = &rdev->ring[ridx];
struct radeon_semaphore *sem = NULL;
struct radeon_bo_va *bo_va;
- unsigned nptes, npdes, ndw;
+ struct radeon_pt *pt;
+ unsigned nptes, npdes, ndw, count;
uint64_t pe, addr;
uint64_t pfn;
+ uint32_t first_pde, pfns_to_pt_edge, pfns_to_end, pde_count;
+ uint64_t *addr_list;
int r;
+ uint64_t mem_pfn_offset;
+ uint64_t pfn_idx, last_pfn, pde_num, pte_num;
/* nothing to do if vm isn't bound */
if (vm->sa_bo == NULL)
@@ -947,6 +979,8 @@ int radeon_vm_bo_update_pte(struct radeon_device *rdev,
pfn = (bo_va->soffset / RADEON_GPU_PAGE_SIZE);
+ first_pde = pfn / RADEON_VM_PTE_COUNT;
+
/* handle cases where a bo spans several pdes */
npdes = (ALIGN(pfn + nptes, RADEON_VM_PTE_COUNT) -
(pfn & ~(RADEON_VM_PTE_COUNT - 1))) >> RADEON_VM_BLOCK_SIZE;
@@ -971,22 +1005,72 @@ int radeon_vm_bo_update_pte(struct radeon_device *rdev,
radeon_fence_note_sync(vm->fence, ridx);
}
- /* update page table entries */
- pe = vm->pd_gpu_addr;
- pe += radeon_vm_directory_size(rde
[PATCH 1/2] drm/radeon: interface cleanup patch v6
add addr_list array to set_page.
if it's not NULL these addresses will be put to the ring.
Signed-off-by: Dmitry Cherkasov
---
to be applied on top of drm/radeon: add 2-level VM pagetables support v9
drivers/gpu/drm/radeon/ni.c | 11 ---
drivers/gpu/drm/radeon/radeon.h |4 ++--
drivers/gpu/drm/radeon/radeon_asic.h |2 +-
drivers/gpu/drm/radeon/radeon_gart.c |4 ++--
4 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index f920a2c..9230815 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1524,13 +1524,14 @@ uint32_t cayman_vm_page_flags(struct radeon_device
*rdev, uint32_t flags)
* @addr: dst addr to write into pe
* @count: number of page entries to update
* @incr: increase next addr by incr bytes
+ * @addr_list: kmalloced array of u64 addresses to write to pe
* @flags: access flags
*
* Update the page tables using the CP (cayman-si).
*/
void cayman_vm_set_page(struct radeon_device *rdev, uint64_t pe,
uint64_t addr, unsigned count,
- uint32_t incr, uint32_t flags)
+ uint32_t incr, uint64_t *addr_list, uint32_t flags)
{
struct radeon_ring *ring = &rdev->ring[rdev->asic->vm.pt_ring_index];
uint32_t r600_flags = cayman_vm_page_flags(rdev, flags);
@@ -1547,8 +1548,12 @@ void cayman_vm_set_page(struct radeon_device *rdev,
uint64_t pe,
addr += incr;
} else if (flags & RADEON_VM_PAGE_VALID) {
- value = addr;
- addr += incr;
+ if (addr_list == NULL) {
+ value = addr;
+ addr += incr;
+ } else {
+ value = addr_list[i];
+ }
}
value |= r600_flags;
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 519d8a3..d8a61ed 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -1151,7 +1151,7 @@ struct radeon_asic {
u32 pt_ring_index;
void (*set_page)(struct radeon_device *rdev, uint64_t pe,
uint64_t addr, unsigned count,
-uint32_t incr, uint32_t flags);
+uint32_t incr, uint64_t *addr_list, uint32_t
flags);
} vm;
/* ring specific callbacks */
struct {
@@ -1765,7 +1765,7 @@ void radeon_ring_write(struct radeon_ring *ring, uint32_t
v);
#define radeon_gart_set_page(rdev, i, p) (rdev)->asic->gart.set_page((rdev),
(i), (p))
#define radeon_asic_vm_init(rdev) (rdev)->asic->vm.init((rdev))
#define radeon_asic_vm_fini(rdev) (rdev)->asic->vm.fini((rdev))
-#define radeon_asic_vm_set_page(rdev, pe, addr, count, incr, flags)
((rdev)->asic->vm.set_page((rdev), (pe), (addr), (count), (incr), (flags)))
+#define radeon_asic_vm_set_page(rdev, pe, addr, count, incr, addr_list, flags)
((rdev)->asic->vm.set_page((rdev), (pe), (addr), (count), (incr), (addr_list),
(flags)))
#define radeon_ring_start(rdev, r, cp)
(rdev)->asic->ring[(r)].ring_start((rdev), (cp))
#define radeon_ring_test(rdev, r, cp)
(rdev)->asic->ring[(r)].ring_test((rdev), (cp))
#define radeon_ib_test(rdev, r, cp) (rdev)->asic->ring[(r)].ib_test((rdev),
(cp))
diff --git a/drivers/gpu/drm/radeon/radeon_asic.h
b/drivers/gpu/drm/radeon/radeon_asic.h
index 9a71f44..6fe8e75 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.h
+++ b/drivers/gpu/drm/radeon/radeon_asic.h
@@ -446,7 +446,7 @@ void cayman_vm_flush(struct radeon_device *rdev, struct
radeon_ib *ib);
uint32_t cayman_vm_page_flags(struct radeon_device *rdev, uint32_t flags);
void cayman_vm_set_page(struct radeon_device *rdev, uint64_t pe,
uint64_t addr, unsigned count,
- uint32_t incr, uint32_t flags);
+ uint32_t incr, uint64_t *addr_list, uint32_t flags);
int evergreen_ib_parse(struct radeon_device *rdev, struct radeon_ib *ib);
/* DCE6 - SI */
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
b/drivers/gpu/drm/radeon/radeon_gart.c
index 753b7ca..31d6bfa 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -977,7 +977,7 @@ int radeon_vm_bo_update_pte(struct radeon_device *rdev,
pe += (bo_va->soffset / RADEON_GPU_PAGE_SIZE) * 8;
radeon_asic_vm_set_page(rdev, pe, addr, nptes,
- RADEON_GPU_PAGE_SIZE, bo_va->flags);
+ RADEON_GPU_PAGE_SIZE, NULL, bo_va->flags);
/* update page directory entries */
addr = pe;
@@ -986,7 +986,7 @@ int radeon_vm_bo_update_pte(struct radeon_device *rdev,
pe += ((bo_va->soffset / RADEON_GPU_PAGE_SIZE) >> RADEON_VM_BLOCK_SIZE)
* 8;
radeon_asic_vm
[PATCH] gpu/drm/ttm: use copy_highpage
Use copy_highpage() to copy from one page to another. Signed-off-by: Akinobu Mita Cc: David Airlie Cc: dri-devel@lists.freedesktop.org --- drivers/gpu/drm/ttm/ttm_tt.c | 16 ++-- 1 file changed, 2 insertions(+), 14 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c index fa09daf..11c9369 100644 --- a/drivers/gpu/drm/ttm/ttm_tt.c +++ b/drivers/gpu/drm/ttm/ttm_tt.c @@ -290,8 +290,6 @@ int ttm_tt_swapin(struct ttm_tt *ttm) struct file *swap_storage; struct page *from_page; struct page *to_page; - void *from_virtual; - void *to_virtual; int i; int ret = -ENOMEM; @@ -311,11 +309,7 @@ int ttm_tt_swapin(struct ttm_tt *ttm) goto out_err; preempt_disable(); - from_virtual = kmap_atomic(from_page); - to_virtual = kmap_atomic(to_page); - memcpy(to_virtual, from_virtual, PAGE_SIZE); - kunmap_atomic(to_virtual); - kunmap_atomic(from_virtual); + copy_highpage(to_page, from_page); preempt_enable(); page_cache_release(from_page); } @@ -336,8 +330,6 @@ int ttm_tt_swapout(struct ttm_tt *ttm, struct file *persistent_swap_storage) struct file *swap_storage; struct page *from_page; struct page *to_page; - void *from_virtual; - void *to_virtual; int i; int ret = -ENOMEM; @@ -367,11 +359,7 @@ int ttm_tt_swapout(struct ttm_tt *ttm, struct file *persistent_swap_storage) goto out_err; } preempt_disable(); - from_virtual = kmap_atomic(from_page); - to_virtual = kmap_atomic(to_page); - memcpy(to_virtual, from_virtual, PAGE_SIZE); - kunmap_atomic(to_virtual); - kunmap_atomic(from_virtual); + copy_highpage(to_page, from_page); preempt_enable(); set_page_dirty(to_page); mark_page_accessed(to_page); -- 1.7.11.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V6 2/2] video: drm: exynos: Add device tree support
2012/9/25 Laurent Pinchart : > On Monday 24 September 2012 21:35:46 Inki Dae wrote: >> 2012/9/22 Stephen Warren : >> > On 09/21/2012 01:22 AM, Inki Dae wrote: >> >> 2012/9/21 Stephen Warren : >> >>> On 09/21/2012 05:22 AM, Leela Krishna Amudala wrote: >> This patch adds device tree based discovery support for exynos DRM-FIMD >> driver which includes driver modification to handle platform data in >> both the cases with DT and non-DT, Also adds the documentation for >> bindings. >> >> diff --git a/Documentation/devicetree/bindings/drm/exynos/fimd.txt >> b/Documentation/devicetree/bindings/drm/exynos/fimd.txt>>> >> >>> ... >> >>> >> + - samsung,fimd-display: This property should specify the phandle of >> the >> + display device node which holds the video interface timing with the >> + below mentioned properties. >> + >> + - lcd-htiming: Specifies the horizontal timing for the overlay. The >> + horizontal timing includes four parameters in the following >> order. >> + >> + - horizontal back porch (in number of lcd clocks) >> + - horizontal front porch (in number of lcd clocks) >> + - hsync pulse width (in number of lcd clocks) >> + - Display panels X resolution. >> + >> + - lcd-vtiming: Specifies the vertical timing for the overlay. The >> + vertical timing includes four parameters in the following order. >> + >> + - vertical back porch (in number of lcd lines) >> + - vertical front porch (in number of lcd lines) >> + - vsync pulse width (in number of lcd clocks) >> + - Display panels Y resolution. >> >>> >> >>> Should this not use the new videomode timings that are under discussion >> >>> at: >> >>> >> >>> http://lists.freedesktop.org/archives/dri-devel/2012-July/024875.html >> >> >> >> ok, I agree with you. then the videomode helper is going to be merged >> >> to mainline(3.6)? if so, this patch should be reworked based on the >> >> videomode helper. >> > >> > I think the videomode helpers would be merged for 3.7 at the very >> > earliest; 3.6 is cooked already. Given there are still some comments on >> > the binding, perhaps it won't happen until 3.8, but it'd be best to ask >> > on that thread so that people more directly involved with the status can >> > answer. >> >> as I mentioned before, it's better to use videomode helper instead but >> for this, we should wait for that the videomode helper are merged to >> mainline so I think it's better to merge it as is and then modify it >> for videomode helper to be used later. > > Aren't DT bindings considered as an ABI, and required to be supported more or > less forever ? If you merge this DT binding you'll have to keep supporting it. > That's why DT bindings should not be rushed in. > is ABI required for DT binding? I know DT binding parses just lcd timing data from device tree file so ABI isn't needed. but when it comes to DT, I'm novice yet so there may be my missing point. could you tell me why DT bindings are considered as an ABI? if there is my missing point, will consider it again. Thanks, Inki Dae > -- > Regards, > > Laurent Pinchart > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
