[PATCH 2/4] drm: allow open of dynamic off devices.

[Dave Airlie]

From: Dave Airlie 

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/drm_fops.c | 2 +-
 include/drm/drmP.h | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 3a24385..d5429ee 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -257,7 +257,7 @@ static int drm_open_helper(struct inode *inode, struct file 
*filp,
return -EBUSY;  /* No exclusive opens */
if (!drm_cpu_valid())
return -EINVAL;
-   if (dev->switch_power_state != DRM_SWITCH_POWER_ON)
+   if (dev->switch_power_state != DRM_SWITCH_POWER_ON && 
dev->switch_power_state != DRM_SWITCH_POWER_DYNAMIC_OFF)
return -EINVAL;
 
DRM_DEBUG("pid = %d, minor = %d\n", task_pid_nr(current), minor_id);
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 12083dc..7f8acaf 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1223,6 +1223,7 @@ struct drm_device {
 #define DRM_SWITCH_POWER_ON 0
 #define DRM_SWITCH_POWER_OFF 1
 #define DRM_SWITCH_POWER_CHANGING 2
+#define DRM_SWITCH_POWER_DYNAMIC_OFF 3
 
 static __inline__ int drm_core_check_feature(struct drm_device *dev,
 int feature)
-- 
1.8.2.1

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

Re: linux-next: problem fetching the drm-intel-fixes tree

[Dave Airlie]

On Mon, Jul 29, 2013 at 10:26 AM, Stephen Rothwell  
wrote:
> Hi Dave,
>
> On Mon, 29 Jul 2013 10:15:50 +1000 Dave Airlie  wrote:
>>
>> > Trying to fetch the drm-intel-fixes tree
>> > (git://people.freedesktop.org/~danvet/drm-intel#drm-intel-fixes) this
>> > morning produced this error:
>>
>> There is some issue with personal fdo repos at the moment and anon git,
>>
>> I'll ask admin to look into it.
>
> Thanks.  In the mean time, I will use what I fetched on Friday.

Okay should all be back in place now.

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

Re: linux-next: problem fetching the drm-intel-fixes tree

[Stephen Rothwell]

Hi Dave,

On Mon, 29 Jul 2013 16:29:04 +1000 Dave Airlie  wrote:
>
> Okay should all be back in place now.

Excellent, thanks.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


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

Commit f5d9b7f0f9 (fix r600_enable_sclk_control()) causes kexec issues

[Markus Trippelsdorf]

On my test machine Xorg doesn't start anymore when I kexec into a
3.11.0-rc3 kernel.
On cold boot everything is fine:

[drm] Initialized drm 1.1.0 20060810
[drm] radeon kernel modesetting enabled.
[drm] initializing kernel modesetting (RS780 0x1002:0x9614 0x1043:0x834D).
[drm] register mmio base: 0xFBEE
[drm] register mmio size: 65536
ATOM BIOS: 113
radeon :01:05.0: VRAM: 128M 0xC000 - 0xC7FF (128M 
used)
radeon :01:05.0: GTT: 512M 0xA000 - 0xBFFF
[drm] Detected VRAM RAM=128M, BAR=128M
[drm] RAM width 32bits DDR
[TTM] Zone  kernel: Available graphics memory: 4082356 kiB
[TTM] Zone   dma32: Available graphics memory: 2097152 kiB
[TTM] Initializing pool allocator
[TTM] Initializing DMA pool allocator
[drm] radeon: 128M of VRAM memory ready
[drm] radeon: 512M of GTT memory ready.
[drm] GART: num cpu pages 131072, num gpu pages 131072
[drm] Loading RS780 Microcode
[drm] PCIE GART of 512M enabled (table at 0xC004).
radeon :01:05.0: WB enabled
radeon :01:05.0: fence driver on ring 0 use gpu addr 0xac00 and 
cpu addr 0x880215c45c00
radeon :01:05.0: fence driver on ring 3 use gpu addr 0xac0c and 
cpu addr 0x880215c45c0c
[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] Driver supports precise vblank timestamp query.
[drm] radeon: irq initialized.
radeon :01:05.0: setting latency timer to 64
[drm] ring test on 0 succeeded in 0 usecs
[drm] ring test on 3 succeeded in 1 usecs
[drm] ib test on ring 0 succeeded in 0 usecs
[drm] ib test on ring 3 succeeded in 0 usecs
[drm] Radeon Display Connectors
[drm] Connector 0:
[drm]   VGA-1
[drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
[drm]   Encoders:
[drm] CRT1: INTERNAL_KLDSCP_DAC1
[drm] Connector 1:
[drm]   DVI-D-1
[drm]   HPD3
[drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
[drm]   Encoders:
[drm] DFP3: INTERNAL_KLDSCP_LVTMA
== power state 0 ==
ui class: none
internal class: boot 
caps: video 
uvdvclk: 0 dclk: 0
power level 0sclk: 5 vddc_index: 2
power level 1sclk: 5 vddc_index: 2
status: c r b 
== power state 1 ==
ui class: performance
internal class: none
caps: video 
uvdvclk: 0 dclk: 0
power level 0sclk: 5 vddc_index: 1
power level 1sclk: 7 vddc_index: 2
status: 
== power state 2 ==
ui class: none
internal class: uvd 
caps: video 
uvdvclk: 53300 dclk: 4
power level 0sclk: 5 vddc_index: 1
power level 1sclk: 5 vddc_index: 1
status: 
switching from power state:
ui class: none
internal class: boot 
caps: video 
uvdvclk: 0 dclk: 0
power level 0sclk: 5 vddc_index: 2
power level 1sclk: 5 vddc_index: 2
status: c b 
switching to power state:
ui class: performance
internal class: none
caps: video 
uvdvclk: 0 dclk: 0
power level 0sclk: 5 vddc_index: 1
power level 1sclk: 7 vddc_index: 2
status: r 
[drm] radeon: dpm initialized
[drm] fb mappable at 0xF0142000
[drm] vram apper at 0xF000
[drm] size 7299072
[drm] fb depth is 24
[drm]pitch is 6912

But after I run kexec things go wrong:

[drm] Initialized drm 1.1.0 20060810
[drm] radeon kernel modesetting enabled.
[drm] initializing kernel modesetting (RS780 0x1002:0x9614 0x1043:0x834D).
[drm] register mmio base: 0xFBEE
[drm] register mmio size: 65536
ATOM BIOS: 113
radeon :01:05.0: VRAM: 128M 0xC000 - 0xC7FF (128M 
used)
radeon :01:05.0: GTT: 512M 0xA000 - 0xBFFF
[drm] Detected VRAM RAM=128M, BAR=128M
[drm] RAM width 32bits DDR
[TTM] Zone  kernel: Available graphics memory: 4082356 kiB
[TTM] Zone   dma32: Available graphics memory: 2097152 kiB
[TTM] Initializing pool allocator
[TTM] Initializing DMA pool allocator
[drm] radeon: 128M of VRAM memory ready
[drm] radeon: 512M of GTT memory ready.
[drm] GART: num cpu pages 131072, num gpu pages 131072
[drm] Loading RS780 Microcode
[drm] PCIE GART of 512M enabled (table at 0xC004).
radeon :01:05.0: WB enabled
radeon :01:05.0: fence driver on ring 0 use gpu addr 0xac00 and 
cpu addr 0x880215c45c00
radeon :01:05.0: fence driver on ring 3 use gpu addr 0xac0c and 
cpu addr 0x880215c45c0c
[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] Driver supports precise vblank timestamp query.
[drm] radeon: irq initialized.
radeon :01:05.0: setting latency timer to 64
[drm] ring test on 0 succeeded in 0 usecs
[drm:r600_dma_ring_test] *ERROR* radeon: ring 3 test failed (0xCAFEDEAD)
radeon :01:05.0: disabling GPU accelerati

[PATCH] drm/nouveau: protect vm refcount with mutex

[Maarten Lankhorst]

The refcount was not protected by the vm lock, fix this..

[ cut here ]
WARNING: CPU: 2 PID: 2008 at drivers/gpu/drm/nouveau/core/core/mm.c:242 
nouveau_mm_fini+0x4f/0x56 [nouveau]()
Modules linked in: adt7475 ebtable_nat ebtables nouveau ipt_MASQUERADE 
iptable_nat nf_nat_ipv4 nf_nat xt_CHECKSUM iptable_mangle bridge stp llc 
snd_hda_codec_hdmi kvm_intel ttm kvm drm_kms_helper drm mxm_wmi 
snd_hda_codec_realtek snd_hda_intel e1000e snd_hda_codec snd_hwdep snd_pcm ptp 
pps_core snd_page_alloc video parport_pc ppdev nfsd parport lockd nfs_acl 
auth_rpcgss sunrpc oid_registry
CPU: 2 PID: 2008 Comm: Xorg Tainted: GW3.11.0-rc1-patser+ #119
Hardware name: Acer Aspire M3985/Aspire M3985, BIOS P01-A1 03/12/2012
 00f2 8803f59b1b68 81637988 b0b0
  8803f59b1ba8 81059e1d 
  8803f9dd6c48 8803f9dd6c00 8803f688d898
Call Trace:
 [] dump_stack+0x55/0x86
 [] warn_slowpath_common+0x87/0xaf
 [] warn_slowpath_null+0x15/0x17
 [] nouveau_mm_fini+0x4f/0x56 [nouveau]
 [] nouveau_vm_ref+0x154/0x180 [nouveau]
 [] ? nouveau_mm_free+0x85/0x116 [nouveau]
 [] nouveau_vm_put+0x9a/0xb0 [nouveau]
 [] ? nouveau_gem_info+0x9d/0x9d [nouveau]
 [] nouveau_gem_object_delete+0x19/0x28 [nouveau]
 [] nouveau_fence_work+0xc9/0x102 [nouveau]
 [] nouveau_gem_object_close+0x103/0x182 [nouveau]
 [] drm_gem_handle_delete+0xcc/0x153 [drm]
 [] drm_gem_close_ioctl+0x23/0x25 [drm]
 [] drm_ioctl+0x4cc/0x612 [drm]
 [] ? __slab_free.isra.66+0x24d/0x2aa
 [] ? drm_gem_destroy+0x4c/0x4c [drm]
 [] ? avc_has_perm_flags+0xb1/0x179
 [] do_vfs_ioctl+0x8b/0x4f8
 [] ? inode_has_perm.isra.43.constprop.75+0x25/0x2b
 [] ? file_has_perm+0x8c/0x9a
 [] ? rcu_user_exit+0xe/0x10
 [] SyS_ioctl+0x8a/0x9b
 [] tracesys+0xdd/0xe2
---[ end trace f99ff0179509b495 ]---

Signed-off-by: Maarten Lankhorst 
---

diff --git a/drivers/gpu/drm/nouveau/core/subdev/vm/base.c 
b/drivers/gpu/drm/nouveau/core/subdev/vm/base.c
index 3b90b42..afc5106 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/vm/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/vm/base.c
@@ -28,6 +28,8 @@
 #include 
 #include 
 
+static void nouveau_vm_del(struct nouveau_vm *vm);
+
 void
 nouveau_vm_map_at(struct nouveau_vma *vma, u64 delta, struct nouveau_mem *node)
 {
@@ -335,10 +337,10 @@ nouveau_vm_get(struct nouveau_vm *vm, u64 size, u32 
page_shift,
return ret;
}
}
+   ++vm->refcount;
+   vma->vm = vm;
mutex_unlock(&nv_subdev(vmm)->mutex);
 
-   vma->vm = NULL;
-   nouveau_vm_ref(vm, &vma->vm, NULL);
vma->offset = (u64)vma->node->offset << 12;
 #ifdef NOUVEAU_VM_POISON
if (vm->poison)
@@ -353,7 +355,7 @@ nouveau_vm_put(struct nouveau_vma *vma)
 {
struct nouveau_vm *vm = vma->vm;
struct nouveau_vmmgr *vmm = vm->vmm;
-   u32 fpde, lpde;
+   u32 fpde, lpde, ref;
 
if (unlikely(vma->node == NULL))
return;
@@ -363,9 +365,12 @@ nouveau_vm_put(struct nouveau_vma *vma)
mutex_lock(&nv_subdev(vmm)->mutex);
nouveau_vm_unmap_pgt(vm, vma->node->type != vmm->spg_shift, fpde, lpde);
nouveau_mm_free(&vm->mm, &vma->node);
-   mutex_unlock(&nv_subdev(vmm)->mutex);
 
-   nouveau_vm_ref(NULL, &vma->vm, NULL);
+   vma->vm = NULL;
+   ref = --vm->refcount;
+   mutex_unlock(&nv_subdev(vmm)->mutex);
+   if (!ref)
+   nouveau_vm_del(vm);
 }
 
 int
@@ -429,25 +434,21 @@ nouveau_vm_link(struct nouveau_vm *vm, struct 
nouveau_gpuobj *pgd)
 
nouveau_gpuobj_ref(pgd, &vpgd->obj);
 
-   mutex_lock(&nv_subdev(vmm)->mutex);
for (i = vm->fpde; i <= vm->lpde; i++)
vmm->map_pgt(pgd, i, vm->pgt[i - vm->fpde].obj);
list_add(&vpgd->head, &vm->pgd_list);
-   mutex_unlock(&nv_subdev(vmm)->mutex);
return 0;
 }
 
 static void
 nouveau_vm_unlink(struct nouveau_vm *vm, struct nouveau_gpuobj *mpgd)
 {
-   struct nouveau_vmmgr *vmm = vm->vmm;
struct nouveau_vm_pgd *vpgd, *tmp;
struct nouveau_gpuobj *pgd = NULL;
 
if (!mpgd)
return;
 
-   mutex_lock(&nv_subdev(vmm)->mutex);
list_for_each_entry_safe(vpgd, tmp, &vm->pgd_list, head) {
if (vpgd->obj == mpgd) {
pgd = vpgd->obj;
@@ -456,7 +457,6 @@ nouveau_vm_unlink(struct nouveau_vm *vm, struct 
nouveau_gpuobj *mpgd)
break;
}
}
-   mutex_unlock(&nv_subdev(vmm)->mutex);
 
nouveau_gpuobj_ref(NULL, &pgd);
 }
@@ -489,20 +489,31 @@ nouveau_vm_ref(struct nouveau_vm *ref, struct nouveau_vm 
**ptr,
 
vm = ref;
if (vm) {
+   struct nouveau_vmmgr *vmm = vm->vmm;
+
+   mutex_lock(&nv_subdev(vmm)->mutex);
ret = nouveau_vm_link(vm, pgd);
-   if (ret)
+   if (ret) {
+   mutex_unlock(&nv_subdev(vmm)-

Re: [PATCH 4/4] snd/hda: add runtime suspend/resume on optimus support

[Takashi Iwai]

At Mon, 29 Jul 2013 16:06:59 +1000,
Dave Airlie wrote:
> 
> Add support for HDMI audio device on VGA cards that powerdown
> to D3cold using non-standard ACPI/PCI infrastructure (optimus).
> 
> This does a couple of things to make it work:
> 
> a) add a set of power ops for the hdmi domain, and enables them
> via vga_switcheroo when we are a switcheroo controlled card. This
> just replaces the runtime resume operation so that when the card
> is in D3cold the userspace pci config space access via sysfs,
> the vga switcheroon runtime resume gets called first and it calls
> the GPU resume callback before calling the sound card runtime
> resume.
> 
> b) standard ACPI/PCI stacks won't put a device into D3cold without
> an ACPI handle, but since the hdmi audio devices on gpus don't have
> an ACPI handle, we need to manually force the device into D3cold
> after suspend from the switcheroo path only.
> 
> c) don't try and do runtime s/r when the GPU is off.
> 
> d) call runtime suspend/resume during switcheroo suspend/resume
> this is to make sure the runtime stack knows to try and resume
> the hdmi audio device for pci config space access.
> 
> Signed-off-by: Dave Airlie 
> ---
>  sound/pci/hda/hda_intel.c | 40 +---
>  1 file changed, 37 insertions(+), 3 deletions(-)
> 
> diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
> index 8860dd5..4b4d05b 100644
> --- a/sound/pci/hda/hda_intel.c
> +++ b/sound/pci/hda/hda_intel.c
> @@ -555,6 +555,9 @@ struct azx {
>  #ifdef CONFIG_SND_HDA_DSP_LOADER
>   struct azx_dev saved_azx_dev;
>  #endif
> +
> + /* secondary power domain for hdmi audio under vga device */
> + struct dev_pm_domain hdmi_pm_domain;
>  };
>  
>  #define CREATE_TRACE_POINTS
> @@ -2898,7 +2901,7 @@ static int param_set_xint(const char *val, const struct 
> kernel_param *kp)
>  /*
>   * power management
>   */
> -static int azx_suspend(struct device *dev)
> +static int azx_do_suspend(struct device *dev, pci_power_t state)
>  {
>   struct pci_dev *pci = to_pci_dev(dev);
>   struct snd_card *card = dev_get_drvdata(dev);
> @@ -2920,16 +2923,30 @@ static int azx_suspend(struct device *dev)
>   free_irq(chip->irq, chip);
>   chip->irq = -1;
>   }
> +
> + /*
> +  * for vga switcheroo suspend we need to
> +  * force runtime suspend so lspci works.
> +  */
> + if (state == PCI_D3cold)
> + pm_runtime_suspend(&pci->dev);
> +
>   if (chip->msi)
>   pci_disable_msi(chip->pci);
>   pci_disable_device(pci);
>   pci_save_state(pci);
> - pci_set_power_state(pci, PCI_D3hot);
> +
> + pci_set_power_state(pci, state);
>   if (chip->driver_caps & AZX_DCAPS_I915_POWERWELL)
>   hda_display_power(false);
>   return 0;
>  }
>  
> +static int azx_suspend(struct device *dev)
> +{
> + return azx_do_suspend(dev, PCI_D3hot);
> +}
> +
>  static int azx_resume(struct device *dev)
>  {
>   struct pci_dev *pci = to_pci_dev(dev);
> @@ -2971,6 +2988,9 @@ static int azx_runtime_suspend(struct device *dev)
>   struct snd_card *card = dev_get_drvdata(dev);
>   struct azx *chip = card->private_data;
>  
> + if (chip->disabled)
> + return 0;
> +
>   azx_stop_chip(chip);
>   azx_enter_link_reset(chip);
>   azx_clear_irq_pending(chip);
> @@ -2984,6 +3004,9 @@ static int azx_runtime_resume(struct device *dev)
>   struct snd_card *card = dev_get_drvdata(dev);
>   struct azx *chip = card->private_data;
>  
> + if (chip->disabled)
> + return 0;
> +
>   if (chip->driver_caps & AZX_DCAPS_I915_POWERWELL)
>   hda_display_power(true);
>   azx_init_pci(chip);
> @@ -2996,6 +3019,9 @@ static int azx_runtime_idle(struct device *dev)
>   struct snd_card *card = dev_get_drvdata(dev);
>   struct azx *chip = card->private_data;
>  
> + if (chip->disabled)
> + return 0;
> +
>   if (!power_save_controller ||
>   !(chip->driver_caps & AZX_DCAPS_PM_RUNTIME))
>   return -EBUSY;
> @@ -3078,7 +3104,11 @@ static void azx_vs_set_state(struct pci_dev *pci,
>  "%s: %s via VGA-switcheroo\n", pci_name(chip->pci),
>  disabled ? "Disabling" : "Enabling");
>   if (disabled) {
> - azx_suspend(&pci->dev);
> + azx_do_suspend(&pci->dev, PCI_D3cold);
> + /* when we get suspended by vga switcheroo we end up in 
> D3cold,
> +  * however we have no ACPI handle, so pci/acpi can't 
> put us there,
> +  * put ourselves there */
> + pci->current_state = PCI_D3cold;
>   chip->disabled = true;
>   if (snd_hda_lock_devices(chip->bus))
>   snd_printk(KERN_WARNING SFX "%s: Cannot lock 
> devices!\n",
> @@ -3087,6 +3117,7 @@ static void azx_vs_

Re: Commit f5d9b7f0f9 (fix r600_enable_sclk_control()) causes kexec issues

[Alex Deucher]

On Mon, Jul 29, 2013 at 3:51 AM, Markus Trippelsdorf
 wrote:
> On my test machine Xorg doesn't start anymore when I kexec into a
> 3.11.0-rc3 kernel.

With kexec, dpm doesn't get torn down properly which can result in a
bad hardware state when the driver loads again.  Does the attached
patch help?  It attempts to disable dpm at startup in case it wasn't
torn down properly previously.

Alex
From 8a39fdbfd4002c79ba9ab4eeb778c751fb20e173 Mon Sep 17 00:00:00 2001
From: Alex Deucher 
Date: Mon, 29 Jul 2013 09:50:37 -0400
Subject: [PATCH] drm/radeon/dpm: disable dpm before enabling it to deal with
 kexec

Hopefully deal with kexec properly by disabling dpm prior to
enabling it in case dpm has not been torn down properly
previously.

Signed-off-by: Alex Deucher 
Cc: Markus Trippelsdorf 
---
 drivers/gpu/drm/radeon/radeon_pm.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_pm.c b/drivers/gpu/drm/radeon/radeon_pm.c
index 76ffb91..c8e697e 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -1193,6 +1193,8 @@ static int radeon_pm_init_dpm(struct radeon_device *rdev)
 	radeon_dpm_init(rdev);
 	rdev->pm.dpm.current_ps = rdev->pm.dpm.requested_ps = rdev->pm.dpm.boot_ps;
 	radeon_dpm_print_power_states(rdev);
+	/* for cases like kexec, disable dpm just in case */
+	radeon_dpm_disable(rdev);
 	radeon_dpm_setup_asic(rdev);
 	ret = radeon_dpm_enable(rdev);
 	mutex_unlock(&rdev->pm.mutex);
-- 
1.7.7.5

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

[RFC PATCH] fence: dma-buf cross-device synchronization (v12)

[Maarten Lankhorst]

A fence can be attached to a buffer which is being filled or consumed
by hw, to allow userspace to pass the buffer without waiting to another
device.  For example, userspace can call page_flip ioctl to display the
next frame of graphics after kicking the GPU but while the GPU is still
rendering.  The display device sharing the buffer with the GPU would
attach a callback to get notified when the GPU's rendering-complete IRQ
fires, to update the scan-out address of the display, without having to
wake up userspace.

A driver must allocate a fence context for each execution ring that can
run in parallel. The function for this takes an argument with how many
contexts to allocate:
  + fence_context_alloc()

A fence is transient, one-shot deal.  It is allocated and attached
to one or more dma-buf's.  When the one that attached it is done, with
the pending operation, it can signal the fence:
  + fence_signal()

To have a rough approximation whether a fence is fired, call:
  + fence_is_signaled()

The dma-buf-mgr handles tracking, and waiting on, the fences associated
with a dma-buf.

The one pending on the fence can add an async callback:
  + fence_add_callback()

The callback can optionally be cancelled with:
  + fence_remove_callback()

To wait synchronously, optionally with a timeout:
  + fence_wait()
  + fence_wait_timeout()

A default software-only implementation is provided, which can be used
by drivers attaching a fence to a buffer when they have no other means
for hw sync.  But a memory backed fence is also envisioned, because it
is common that GPU's can write to, or poll on some memory location for
synchronization.  For example:

  fence = custom_get_fence(...);
  if ((seqno_fence = to_seqno_fence(fence)) != NULL) {
dma_buf *fence_buf = fence->sync_buf;
get_dma_buf(fence_buf);

... tell the hw the memory location to wait ...
custom_wait_on(fence_buf, fence->seqno_ofs, fence->seqno);
  } else {
/* fall-back to sw sync * /
fence_add_callback(fence, my_cb);
  }

On SoC platforms, if some other hw mechanism is provided for synchronizing
between IP blocks, it could be supported as an alternate implementation
with it's own fence ops in a similar way.

enable_signaling callback is used to provide sw signaling in case a cpu
waiter is requested or no compatible hardware signaling could be used.

The intention is to provide a userspace interface (presumably via eventfd)
later, to be used in conjunction with dma-buf's mmap support for sw access
to buffers (or for userspace apps that would prefer to do their own
synchronization).

v1: Original
v2: After discussion w/ danvet and mlankhorst on #dri-devel, we decided
that dma-fence didn't need to care about the sw->hw signaling path
(it can be handled same as sw->sw case), and therefore the fence->ops
can be simplified and more handled in the core.  So remove the signal,
add_callback, cancel_callback, and wait ops, and replace with a simple
enable_signaling() op which can be used to inform a fence supporting
hw->hw signaling that one or more devices which do not support hw
signaling are waiting (and therefore it should enable an irq or do
whatever is necessary in order that the CPU is notified when the
fence is passed).
v3: Fix locking fail in attach_fence() and get_fence()
v4: Remove tie-in w/ dma-buf..  after discussion w/ danvet and mlankorst
we decided that we need to be able to attach one fence to N dma-buf's,
so using the list_head in dma-fence struct would be problematic.
v5: [ Maarten Lankhorst ] Updated for dma-bikeshed-fence and dma-buf-manager.
v6: [ Maarten Lankhorst ] I removed dma_fence_cancel_callback and some comments
about checking if fence fired or not. This is broken by design.
waitqueue_active during destruction is now fatal, since the signaller
should be holding a reference in enable_signalling until it signalled
the fence. Pass the original dma_fence_cb along, and call __remove_wait
in the dma_fence_callback handler, so that no cleanup needs to be
performed.
v7: [ Maarten Lankhorst ] Set cb->func and only enable sw signaling if
fence wasn't signaled yet, for example for hardware fences that may
choose to signal blindly.
v8: [ Maarten Lankhorst ] Tons of tiny fixes, moved __dma_fence_init to
header and fixed include mess. dma-fence.h now includes dma-buf.h
All members are now initialized, so kmalloc can be used for
allocating a dma-fence. More documentation added.
v9: Change compiler bitfields to flags, change return type of
enable_signaling to bool. Rework dma_fence_wait. Added
dma_fence_is_signaled and dma_fence_wait_timeout.
s/dma// and change exports to non GPL. Added fence_is_signaled and
fence_enable_sw_signaling calls, add ability to override default
wait operation.
v10: remove event_queue, use a custom list, export try_to_wake_up from
scheduler. Remove fence lock and use a global spinlock instead,
this s

Re: Commit f5d9b7f0f9 (fix r600_enable_sclk_control()) causes kexec issues

[Markus Trippelsdorf]

On 2013.07.29 at 09:58 -0400, Alex Deucher wrote:
> On Mon, Jul 29, 2013 at 3:51 AM, Markus Trippelsdorf
>  wrote:
> > On my test machine Xorg doesn't start anymore when I kexec into a
> > 3.11.0-rc3 kernel.
> 
> With kexec, dpm doesn't get torn down properly which can result in a
> bad hardware state when the driver loads again.  Does the attached
> patch help?  It attempts to disable dpm at startup in case it wasn't
> torn down properly previously.

dpm initialization now works, but unfortunately GPU acceleration still gets
disabled:

[drm] Initialized drm 1.1.0 20060810

[135/1104]
[drm] radeon kernel modesetting enabled.
[drm] initializing kernel modesetting (RS780 0x1002:0x9614 0x1043:0x834D).
[drm] register mmio base: 0xFBEE
[drm] register mmio size: 65536
ATOM BIOS: 113
radeon :01:05.0: VRAM: 128M 0xC000 - 0xC7FF (128M 
used)
radeon :01:05.0: GTT: 512M 0xA000 - 0xBFFF
[drm] Detected VRAM RAM=128M, BAR=128M
[drm] RAM width 32bits DDR
[TTM] Zone  kernel: Available graphics memory: 4082356 kiB
[TTM] Zone   dma32: Available graphics memory: 2097152 kiB
[TTM] Initializing pool allocator
[TTM] Initializing DMA pool allocator
[drm] radeon: 128M of VRAM memory ready
[drm] radeon: 512M of GTT memory ready.
[drm] GART: num cpu pages 131072, num gpu pages 131072
[drm] Loading RS780 Microcode
[drm] PCIE GART of 512M enabled (table at 0xC004).
radeon :01:05.0: WB enabled
radeon :01:05.0: fence driver on ring 0 use gpu addr 0xac00 and 
cpu addr 0x880215c30c00
radeon :01:05.0: fence driver on ring 3 use gpu addr 0xac0c and 
cpu addr 0x880215c30c0c
[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] Driver supports precise vblank timestamp query.
[drm] radeon: irq initialized.
radeon :01:05.0: setting latency timer to 64
[drm] ring test on 0 succeeded in 1 usecs
[drm:r600_dma_ring_test] *ERROR* radeon: ring 3 test failed (0xCAFEDEAD)
radeon :01:05.0: disabling GPU acceleration
radeon :01:05.0: 8802161cfc00 unpin not necessary
[drm] Radeon Display Connectors
[drm] Connector 0:
[drm]   VGA-1
[drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
[drm]   Encoders:
[drm] CRT1: INTERNAL_KLDSCP_DAC1
[drm] Connector 1:
[drm]   DVI-D-1
[drm]   HPD3
[drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
[drm]   Encoders:
[drm] DFP3: INTERNAL_KLDSCP_LVTMA
== power state 0 ==
ui class: none
internal class: boot 
caps: video 
uvdvclk: 0 dclk: 0
power level 0sclk: 5 vddc_index: 2
power level 1sclk: 5 vddc_index: 2
status: c r b 
== power state 1 ==
ui class: performance
internal class: none
caps: video 
uvdvclk: 0 dclk: 0
power level 0sclk: 5 vddc_index: 1
power level 1sclk: 7 vddc_index: 2
status: 
== power state 2 ==
ui class: none
internal class: uvd 
caps: video 
uvdvclk: 53300 dclk: 4
power level 0sclk: 5 vddc_index: 1
power level 1sclk: 5 vddc_index: 1
status: 
switching from power state:
ui class: none
internal class: boot 
caps: video 
uvdvclk: 0 dclk: 0
power level 0sclk: 5 vddc_index: 2
power level 1sclk: 5 vddc_index: 2
status: c b 
switching to power state:
ui class: performance
internal class: none
caps: video 
uvdvclk: 0 dclk: 0
power level 0sclk: 5 vddc_index: 1
power level 1sclk: 7 vddc_index: 2
status: r 
[drm] radeon: dpm initialized
[drm] fb mappable at 0xF0142000
[drm] vram apper at 0xF000
[drm] size 7299072
[drm] fb depth is 24
[drm]pitch is 6912
fbcon: radeondrmfb (fb0)

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

Re: Commit f5d9b7f0f9 (fix r600_enable_sclk_control()) causes kexec issues

[Alex Deucher]

On Mon, Jul 29, 2013 at 10:09 AM, Markus Trippelsdorf
 wrote:
> On 2013.07.29 at 09:58 -0400, Alex Deucher wrote:
>> On Mon, Jul 29, 2013 at 3:51 AM, Markus Trippelsdorf
>>  wrote:
>> > On my test machine Xorg doesn't start anymore when I kexec into a
>> > 3.11.0-rc3 kernel.
>>
>> With kexec, dpm doesn't get torn down properly which can result in a
>> bad hardware state when the driver loads again.  Does the attached
>> patch help?  It attempts to disable dpm at startup in case it wasn't
>> torn down properly previously.
>
> dpm initialization now works, but unfortunately GPU acceleration still gets
> disabled:

Stupid kexec complicates things.  We need to make sure dpm is torn
down before we init the rest of the GPU, but dpm needs get initialized
later in the init process since it depends on certain other state from
the driver.  I need to think about this for a bit.  I'm not sure of a
good way to handle this.

Alex

>
> [drm] Initialized drm 1.1.0 20060810  
>   
> [135/1104]
> [drm] radeon kernel modesetting enabled.
> [drm] initializing kernel modesetting (RS780 0x1002:0x9614 0x1043:0x834D).
> [drm] register mmio base: 0xFBEE
> [drm] register mmio size: 65536
> ATOM BIOS: 113
> radeon :01:05.0: VRAM: 128M 0xC000 - 0xC7FF (128M 
> used)
> radeon :01:05.0: GTT: 512M 0xA000 - 0xBFFF
> [drm] Detected VRAM RAM=128M, BAR=128M
> [drm] RAM width 32bits DDR
> [TTM] Zone  kernel: Available graphics memory: 4082356 kiB
> [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
> [TTM] Initializing pool allocator
> [TTM] Initializing DMA pool allocator
> [drm] radeon: 128M of VRAM memory ready
> [drm] radeon: 512M of GTT memory ready.
> [drm] GART: num cpu pages 131072, num gpu pages 131072
> [drm] Loading RS780 Microcode
> [drm] PCIE GART of 512M enabled (table at 0xC004).
> radeon :01:05.0: WB enabled
> radeon :01:05.0: fence driver on ring 0 use gpu addr 0xac00 
> and cpu addr 0x880215c30c00
> radeon :01:05.0: fence driver on ring 3 use gpu addr 0xac0c 
> and cpu addr 0x880215c30c0c
> [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
> [drm] Driver supports precise vblank timestamp query.
> [drm] radeon: irq initialized.
> radeon :01:05.0: setting latency timer to 64
> [drm] ring test on 0 succeeded in 1 usecs
> [drm:r600_dma_ring_test] *ERROR* radeon: ring 3 test failed (0xCAFEDEAD)
> radeon :01:05.0: disabling GPU acceleration
> radeon :01:05.0: 8802161cfc00 unpin not necessary
> [drm] Radeon Display Connectors
> [drm] Connector 0:
> [drm]   VGA-1
> [drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
> [drm]   Encoders:
> [drm] CRT1: INTERNAL_KLDSCP_DAC1
> [drm] Connector 1:
> [drm]   DVI-D-1
> [drm]   HPD3
> [drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
> [drm]   Encoders:
> [drm] DFP3: INTERNAL_KLDSCP_LVTMA
> == power state 0 ==
> ui class: none
> internal class: boot
> caps: video
> uvdvclk: 0 dclk: 0
> power level 0sclk: 5 vddc_index: 2
> power level 1sclk: 5 vddc_index: 2
> status: c r b
> == power state 1 ==
> ui class: performance
> internal class: none
> caps: video
> uvdvclk: 0 dclk: 0
> power level 0sclk: 5 vddc_index: 1
> power level 1sclk: 7 vddc_index: 2
> status:
> == power state 2 ==
> ui class: none
> internal class: uvd
> caps: video
> uvdvclk: 53300 dclk: 4
> power level 0sclk: 5 vddc_index: 1
> power level 1sclk: 5 vddc_index: 1
> status:
> switching from power state:
> ui class: none
> internal class: boot
> caps: video
> uvdvclk: 0 dclk: 0
> power level 0sclk: 5 vddc_index: 2
> power level 1sclk: 5 vddc_index: 2
> status: c b
> switching to power state:
> ui class: performance
> internal class: none
> caps: video
> uvdvclk: 0 dclk: 0
> power level 0sclk: 5 vddc_index: 1
> power level 1sclk: 7 vddc_index: 2
> status: r
> [drm] radeon: dpm initialized
> [drm] fb mappable at 0xF0142000
> [drm] vram apper at 0xF000
> [drm] size 7299072
> [drm] fb depth is 24
> [drm]pitch is 6912
> fbcon: radeondrmfb (fb0)
>
> --
> Markus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 0/1] drm/pl111: Initial drm/kms driver for pl111

[Rob Clark]

On Fri, Jul 26, 2013 at 11:58 AM, Tom Cooksey  wrote:
> Hi Rob,
>
>> >  * It abuses flags parameter of DRM_IOCTL_MODE_CREATE_DUMB to also
>> >allocate buffers for the GPU. Still not sure how to resolve this
>> >as we don't use DRM for our GPU driver.
>>
>> any thoughts/plans about a DRM GPU driver?  Ideally long term (esp.
>> once the dma-fence stuff is in place), we'd have gpu-specific drm
>> (gpu-only, no kms) driver, and SoC/display specific drm/kms driver,
>> using prime/dmabuf to share between the two.
>
> The "extra" buffers we were allocating from armsoc DDX were really
> being allocated through DRM/GEM so we could get an flink name
> for them and pass a reference to them back to our GPU driver on
> the client side. If it weren't for our need to access those
> extra off-screen buffers with the GPU we wouldn't need to
> allocate them with DRM at all. So, given they are really "GPU"
> buffers, it does absolutely make sense to allocate them in a
> different driver to the display driver.
>
> However, to avoid unnecessary memcpys & related cache
> maintenance ops, we'd also like the GPU to render into buffers
> which are scanned out by the display controller. So let's say
> we continue using DRM_IOCTL_MODE_CREATE_DUMB to allocate scan
> out buffers with the display's DRM driver but a custom ioctl
> on the GPU's DRM driver to allocate non scanout, off-screen
> buffers. Sounds great, but I don't think that really works
> with DRI2. If we used two drivers to allocate buffers, which
> of those drivers do we return in DRI2ConnectReply? Even if we
> solve that somehow, GEM flink names are name-spaced to a
> single device node (AFAIK). So when we do a DRI2GetBuffers,
> how does the EGL in the client know which DRM device owns GEM
> flink name "1234"? We'd need some pretty dirty hacks.

You would return the name of the display driver allocating the
buffers.  On the client side you can use generic ioctls to go from
flink -> handle -> dmabuf.  So the client side would end up opening
both the display drm device and the gpu, but without needing to know
too much about the display.

(Probably in (for example) mesa there needs to be a bit of work to
handle this better, but I think that would be needed as well for
sharing between, say, nouveau and udl displaylink driver.. which is
really the same scenario.)

> So then we looked at allocating _all_ buffers with the GPU's
> DRM driver. That solves the DRI2 single-device-name and single
> name-space issue. It also means the GPU would _never_ render
> into buffers allocated through DRM_IOCTL_MODE_CREATE_DUMB.

Well, I think we can differentiate between shared buffers and internal
buffers (textures, vertex upload, etc, etc).

For example, in mesa/gallium driver there are two paths to getting a
buffer...  ->resource_create() and ->resource_from_handle(), the
latter is the path you go for dri2 buffers shared w/ x11.  The former
is buffers that are just internal to gpu (if !(bind &
PIPE_BIND_SHARED)).  I guess you must have something similar in mali
driver.

> One thing I wasn't sure about is if there was an objection
> to using PRIME to export scanout buffers allocated with
> DRM_IOCTL_MODE_CREATE_DUMB and then importing them into a GPU
> driver to be rendered into? Is that a concern?

well.. it wasn't quite the original intention of the 'dumb' ioctls.
But I guess in the end if you hand the gpu a buffer with a
layout/format that it can't grok, then gpu does a staging texture plus
copy.  If you had, for example, some setup w/ gpu that could only
render to tiled format, plus a display that could scanout that format,
then your DDX driver would need to allocate the dri2 buffers with
something other than dumb ioctl.  (But at that point, you probably
need to implement your own EXA so you could hook in your own custom
upload-to/download-from screen fxns for sw fallbacks, so you're not
talking about using generic DDX anyways.)

> Anyway, that latter case also gets quite difficult. The "GPU"
> DRM driver would need to know the constraints of the display
> controller when allocating buffers intended to be scanned out.
> For example, pl111 typically isn't behind an IOMMU and so
> requires physically contiguous memory. We'd have to teach the
> GPU's DRM driver about the constraints of the display HW. Not
> exactly a clean driver model. :-(
>
> I'm still a little stuck on how to proceed, so any ideas
> would greatly appreciated! My current train of thought is
> having a kind of SoC-specific DRM driver which allocates
> buffers for both display and GPU within a single GEM
> namespace. That SoC-specific DRM driver could then know the
> constraints of both the GPU and the display HW. We could then
> use PRIME to export buffers allocated with the SoC DRM driver
> and import them into the GPU and/or display DRM driver.

Usually if the display drm driver is allocating the buffers that might
be scanned out, it just needs to have minimal knowledge of the GPU
(pitch alignment constraints). 

Re: Commit f5d9b7f0f9 (fix r600_enable_sclk_control()) causes kexec issues

[Markus Trippelsdorf]

On 2013.07.29 at 18:14 +0200, Joshua C. wrote:
> 
> This error message seems similar to mine "[drm:r600_uvd_ring_test]
> *ERROR* radeon: ring 5 test failed (0xCAFEDEAD)" Bugzilla:
> https://bugs.freedesktop.org/show_bug.cgi?id=67276 In my case I blame
> another commit for this. Are these bugs related?

I guess not, because reverting commit 9cc2e0e9f13 doesn't fix the issue
for me. 
Can you check if reverting commit f5d9b7f0f9 does fixes the problem for
you?

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

[Bug 67435] HDMI audio silent on Radeon Mobility HD4650

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=67435

--- Comment #4 from Kris Scott  ---
Bisect complete:

b1f6f47e3e33c4a74534f1301aca241ffabbb3a0 is the first bad commit
commit b1f6f47e3e33c4a74534f1301aca241ffabbb3a0
Author: Alex Deucher 
Date:   Thu Apr 18 10:50:55 2013 -0400

drm/radeon: clean up audio dto programming

Split into DCE2/3 and DCE4/5 variants. Still todo is to
calculate the DTO dividers properly.  Add proper formula
to the comments.

Reviewed-by: Christian König 
Signed-off-by: Alex Deucher 

:04 04 b60cf880f2227596705391e71a56aaa12e1eb61c
a723f4928d1a20bcd0b5759077360f9342c9eecc Mdrivers

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 67435] HDMI audio silent on Radeon Mobility HD4650

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=67435

--- Comment #5 from Rafał Miłecki  ---
As I suggested earlier, can you provide output of "avivotool regs hdmi" before
and after this patch?

This way we will sure if registers are programmed and with what values.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 67435] HDMI audio silent on Radeon Mobility HD4650

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=67435

--- Comment #6 from Kris Scott  ---
Good:

RADEON_DAC_CNTL
RADEON_DAC_EXT_CNTL
RADEON_DAC_MACRO_CNTL
RADEON_DAC_CNTL2
RADEON_TV_DAC_CNTL
RADEON_DISP_OUTPUT_CNTL
RADEON_CONFIG_MEMSIZE
RADEON_AUX_SC_CNTL804df8a8
RADEON_CRTC_EXT_CNTL
RADEON_CRTC_GEN_CNTL
RADEON_CRTC2_GEN_CNTL
RADEON_DEVICE_ID
RADEON_DISP_MISC_CNTL
RADEON_GPIO_MONID
RADEON_GPIO_MONIDB
RADEON_GPIO_CRT2_DDC
RADEON_GPIO_DVI_DDC
RADEON_GPIO_VGA_DDC
RADEON_LVDS_GEN_CNTL
RADEON_LVDS_PLL_CNTL
RADEON_FP_GEN_CNTL
RADEON_FP2_GEN_CNTL
RADEON_PPLL_CNTL
RADEON_PPLL_REF_DIV
RADEON_PPLL_DIV_3
RADEON_PIXCLKS_CNTL
RADEON_P2PLL_CNTL
RADEON_P2PLL_REF_DIV
RADEON_P2PLL_DIV_0
RADEON_VCLK_ECP_CNTL
RADEON_MEM_TIMING_CNTL
RADEON_TMDS_PLL_CNTL
RADEON_TMDS_TRANSMITTER_CNTL
RADEON_CRTC_MORE_CNTL
RADEON_FP_H_SYNC_STRT_WID
RADEON_FP_V_SYNC_STRT_WID
RADEON_FP_CRTC_H_TOTAL_DISP
RADEON_FP_CRTC_V_TOTAL_DISP
RADEON_FP_HORZ_STRETCH
RADEON_FP_VERT_STRETCH
RADEON_FP_HORZ_VERT_ACTIVE
RADEON_CRTC_H_TOTAL_DISP0004
RADEON_CRTC_H_SYNC_STRT_WID18b8bebc
RADEON_CRTC_V_TOTAL_DISPfffe0a02
RADEON_CRTC_V_SYNC_STRT_WID
RADEON_CRTC2_H_TOTAL_DISP020f
RADEON_CRTC2_H_SYNC_STRT_WID
RADEON_CRTC2_V_TOTAL_DISP0100
RADEON_CRTC2_V_SYNC_STRT_WID0002

-
Bad:

RADEON_DAC_CNTL
RADEON_DAC_EXT_CNTL
RADEON_DAC_MACRO_CNTL
RADEON_DAC_CNTL2
RADEON_TV_DAC_CNTL
RADEON_DISP_OUTPUT_CNTL
RADEON_CONFIG_MEMSIZE
RADEON_AUX_SC_CNTLc045fab8
RADEON_CRTC_EXT_CNTL
RADEON_CRTC_GEN_CNTL
RADEON_CRTC2_GEN_CNTL
RADEON_DEVICE_ID
RADEON_DISP_MISC_CNTL
RADEON_GPIO_MONID
RADEON_GPIO_MONIDB
RADEON_GPIO_CRT2_DDC
RADEON_GPIO_DVI_DDC
RADEON_GPIO_VGA_DDC
RADEON_LVDS_GEN_CNTL
RADEON_LVDS_PLL_CNTL
RADEON_FP_GEN_CNTL
RADEON_FP2_GEN_CNTL
RADEON_PPLL_CNTL
RADEON_PPLL_REF_DIV
RADEON_PPLL_DIV_3
RADEON_PIXCLKS_CNTL
RADEON_P2PLL_CNTL
RADEON_P2PLL_REF_DIV
RADEON_P2PLL_DIV_0
RADEON_VCLK_ECP_CNTL
RADEON_MEM_TIMING_CNTL
RADEON_TMDS_PLL_CNTL
RADEON_TMDS_TRANSMITTER_CNTL
RADEON_CRTC_MORE_CNTL
RADEON_FP_H_SYNC_STRT_WID
RADEON_FP_V_SYNC_STRT_WID
RADEON_FP_CRTC_H_TOTAL_DISP
RADEON_FP_CRTC_V_TOTAL_DISP
RADEON_FP_HORZ_STRETCH
RADEON_FP_VERT_STRETCH
RADEON_FP_HORZ_VERT_ACTIVE
RADEON_CRTC_H_TOTAL_DISP0004
RADEON_CRTC_H_SYNC_STRT_WID18b836bc
RADEON_CRTC_V_TOTAL_DISPfffe0a02
RADEON_CRTC_V_SYNC_STRT_WID
RADEON_CRTC2_H_TOTAL_DISP020f
RADEON_CRTC2_H_SYNC_STRT_WID
RADEON_CRTC2_V_TOTAL_DISP0100
RADEON_CRTC2_V_SYNC_STRT_WID0002

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[GIT PULL] exynos-drm-fixes

[inki . dae]

Hi Dave,
   This pull request fixes module build and g2d clock
   control issues, and includes related cleanup.

Please kindly let me know if there is any problem.

Thanks,
Inki Dae

The following changes since commit bf903e4141fce4b35072d5b8fa0ddd299aaf01ea:

  Merge tag 'drm-intel-fixes-2013-07-25' of 
git://people.freedesktop.org/~danvet/drm-intel into drm-fixes (2013-07-26 
20:38:14 +1000)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git 
exynos-drm-fixes

for you to fetch changes up to db70d16ef63dbd412a974c893c52ee5ad0777d21:

  drm/exynos: Remove module.h header inclusion (2013-07-30 02:01:54 +0900)


Inki Dae (2):
  drm/exynos: fix module build error
  drm/exynos: consider common clock framework to g2d driver.

Sachin Kamat (1):
  drm/exynos: Remove module.h header inclusion

Wei Yongjun (1):
  drm/exynos: exynos_drm_ipp: fix return value check

 drivers/gpu/drm/exynos/exynos_ddc.c |  1 -
 drivers/gpu/drm/exynos/exynos_drm_fimc.c|  1 -
 drivers/gpu/drm/exynos/exynos_drm_fimd.c|  3 ---
 drivers/gpu/drm/exynos/exynos_drm_g2d.c | 19 ++-
 drivers/gpu/drm/exynos/exynos_drm_gsc.c |  1 -
 drivers/gpu/drm/exynos/exynos_drm_hdmi.c|  1 -
 drivers/gpu/drm/exynos/exynos_drm_ipp.c | 13 ++---
 drivers/gpu/drm/exynos/exynos_drm_rotator.c |  1 -
 drivers/gpu/drm/exynos/exynos_drm_vidi.c|  1 -
 drivers/gpu/drm/exynos/exynos_hdmi.c|  1 -
 drivers/gpu/drm/exynos/exynos_hdmiphy.c |  1 -
 drivers/gpu/drm/exynos/exynos_mixer.c   |  1 -
 12 files changed, 20 insertions(+), 24 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 67435] HDMI audio silent on Radeon Mobility HD4650

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=67435

--- Comment #7 from Rafał Miłecki  ---
Err, did you call "avivotool regs hdmi" as I asked?

It should return something like:

Audio clocks:
EVERGREEN_AUDIO_PLL1_MUL
EVERGREEN_AUDIO_PLL1_DIV0001
EVERGREEN_AUDIO_PLL1_UNK0070

which is the most interesting part for us.

Of course on R6xx hardware it won't start with EVERGREEN_*

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Commit f5d9b7f0f9 (fix r600_enable_sclk_control()) causes kexec issues

[Alex Deucher]

On Mon, Jul 29, 2013 at 12:14 PM, Joshua C.  wrote:
> 2013/7/29 Alex Deucher :
>> On Mon, Jul 29, 2013 at 10:09 AM, Markus Trippelsdorf
>>  wrote:
>>> On 2013.07.29 at 09:58 -0400, Alex Deucher wrote:
 On Mon, Jul 29, 2013 at 3:51 AM, Markus Trippelsdorf
  wrote:
 > On my test machine Xorg doesn't start anymore when I kexec into a
 > 3.11.0-rc3 kernel.

 With kexec, dpm doesn't get torn down properly which can result in a
 bad hardware state when the driver loads again.  Does the attached
 patch help?  It attempts to disable dpm at startup in case it wasn't
 torn down properly previously.
>>>
>>> dpm initialization now works, but unfortunately GPU acceleration still gets
>>> disabled:
>>
>> Stupid kexec complicates things.  We need to make sure dpm is torn
>> down before we init the rest of the GPU, but dpm needs get initialized
>> later in the init process since it depends on certain other state from
>> the driver.  I need to think about this for a bit.  I'm not sure of a
>> good way to handle this.
>>
>> Alex
>>
>>>
>>> [drm] Initialized drm 1.1.0 20060810
>>> 
>>> [135/1104]
>>> [drm] radeon kernel modesetting enabled.
>>> [drm] initializing kernel modesetting (RS780 0x1002:0x9614 0x1043:0x834D).
>>> [drm] register mmio base: 0xFBEE
>>> [drm] register mmio size: 65536
>>> ATOM BIOS: 113
>>> radeon :01:05.0: VRAM: 128M 0xC000 - 0xC7FF 
>>> (128M used)
>>> radeon :01:05.0: GTT: 512M 0xA000 - 0xBFFF
>>> [drm] Detected VRAM RAM=128M, BAR=128M
>>> [drm] RAM width 32bits DDR
>>> [TTM] Zone  kernel: Available graphics memory: 4082356 kiB
>>> [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
>>> [TTM] Initializing pool allocator
>>> [TTM] Initializing DMA pool allocator
>>> [drm] radeon: 128M of VRAM memory ready
>>> [drm] radeon: 512M of GTT memory ready.
>>> [drm] GART: num cpu pages 131072, num gpu pages 131072
>>> [drm] Loading RS780 Microcode
>>> [drm] PCIE GART of 512M enabled (table at 0xC004).
>>> radeon :01:05.0: WB enabled
>>> radeon :01:05.0: fence driver on ring 0 use gpu addr 0xac00 
>>> and cpu addr 0x880215c30c00
>>> radeon :01:05.0: fence driver on ring 3 use gpu addr 0xac0c 
>>> and cpu addr 0x880215c30c0c
>>> [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
>>> [drm] Driver supports precise vblank timestamp query.
>>> [drm] radeon: irq initialized.
>>> radeon :01:05.0: setting latency timer to 64
>>> [drm] ring test on 0 succeeded in 1 usecs
>>> [drm:r600_dma_ring_test] *ERROR* radeon: ring 3 test failed (0xCAFEDEAD)
>>> radeon :01:05.0: disabling GPU acceleration
>>> radeon :01:05.0: 8802161cfc00 unpin not necessary
>>> [drm] Radeon Display Connectors
>>> [drm] Connector 0:
>>> [drm]   VGA-1
>>> [drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
>>> [drm]   Encoders:
>>> [drm] CRT1: INTERNAL_KLDSCP_DAC1
>>> [drm] Connector 1:
>>> [drm]   DVI-D-1
>>> [drm]   HPD3
>>> [drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
>>> [drm]   Encoders:
>>> [drm] DFP3: INTERNAL_KLDSCP_LVTMA
>>> == power state 0 ==
>>> ui class: none
>>> internal class: boot
>>> caps: video
>>> uvdvclk: 0 dclk: 0
>>> power level 0sclk: 5 vddc_index: 2
>>> power level 1sclk: 5 vddc_index: 2
>>> status: c r b
>>> == power state 1 ==
>>> ui class: performance
>>> internal class: none
>>> caps: video
>>> uvdvclk: 0 dclk: 0
>>> power level 0sclk: 5 vddc_index: 1
>>> power level 1sclk: 7 vddc_index: 2
>>> status:
>>> == power state 2 ==
>>> ui class: none
>>> internal class: uvd
>>> caps: video
>>> uvdvclk: 53300 dclk: 4
>>> power level 0sclk: 5 vddc_index: 1
>>> power level 1sclk: 5 vddc_index: 1
>>> status:
>>> switching from power state:
>>> ui class: none
>>> internal class: boot
>>> caps: video
>>> uvdvclk: 0 dclk: 0
>>> power level 0sclk: 5 vddc_index: 2
>>> power level 1sclk: 5 vddc_index: 2
>>> status: c b
>>> switching to power state:
>>> ui class: performance
>>> internal class: none
>>> caps: video
>>> uvdvclk: 0 dclk: 0
>>> power level 0sclk: 5 vddc_index: 1
>>> power level 1sclk: 7 vddc_index: 2
>>> status: r
>>> [drm] radeon: dpm initialized
>>> [drm] fb mappable at 0xF0142000
>>> [drm] vram apper at 0xF000
>>> [drm] size 7299072
>>> [drm] fb depth is 24
>>> [drm]pitch is 6912
>>> fbcon: radeondrmfb (f

Re: Commit f5d9b7f0f9 (fix r600_enable_sclk_control()) causes kexec issues

[Alex Deucher]

On Mon, Jul 29, 2013 at 11:50 AM, Eric W. Biederman
 wrote:
>
>
> Alex Deucher  wrote:
>>On Mon, Jul 29, 2013 at 10:09 AM, Markus Trippelsdorf
>> wrote:
>>> On 2013.07.29 at 09:58 -0400, Alex Deucher wrote:
 On Mon, Jul 29, 2013 at 3:51 AM, Markus Trippelsdorf
  wrote:
 > On my test machine Xorg doesn't start anymore when I kexec into a
 > 3.11.0-rc3 kernel.

 With kexec, dpm doesn't get torn down properly which can result in a
 bad hardware state when the driver loads again.  Does the attached
 patch help?  It attempts to disable dpm at startup in case it wasn't
 torn down properly previously.
>>>
>>> dpm initialization now works, but unfortunately GPU acceleration
>>still gets
>>> disabled:
>>
>>Stupid kexec complicates things.  We need to make sure dpm is torn
>>down before we init the rest of the GPU, but dpm needs get initialized
>>later in the init process since it depends on certain other state from
>>the driver.  I need to think about this for a bit.  I'm not sure of a
>>good way to handle this.
>
> You might just want to implement a shutdown method that cleans things up 
> properly.   At least as a first pass until you worry about things like kexec 
> on panic.
>
> Or can you not shutdown the graphics stack on reboot because of the need to 
> display the kernels shutdown progress?

Does kexec actually call this shutdown method?  The driver implements
appropriate clean-up measures if it's shutdown properly.

Alex


>
> Eric
>
>>Alex
>>
>>>
>>> [drm] Initialized drm 1.1.0 20060810
>> [135/1104]
>>> [drm] radeon kernel modesetting enabled.
>>> [drm] initializing kernel modesetting (RS780 0x1002:0x9614
>>0x1043:0x834D).
>>> [drm] register mmio base: 0xFBEE
>>> [drm] register mmio size: 65536
>>> ATOM BIOS: 113
>>> radeon :01:05.0: VRAM: 128M 0xC000 -
>>0xC7FF (128M used)
>>> radeon :01:05.0: GTT: 512M 0xA000 -
>>0xBFFF
>>> [drm] Detected VRAM RAM=128M, BAR=128M
>>> [drm] RAM width 32bits DDR
>>> [TTM] Zone  kernel: Available graphics memory: 4082356 kiB
>>> [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
>>> [TTM] Initializing pool allocator
>>> [TTM] Initializing DMA pool allocator
>>> [drm] radeon: 128M of VRAM memory ready
>>> [drm] radeon: 512M of GTT memory ready.
>>> [drm] GART: num cpu pages 131072, num gpu pages 131072
>>> [drm] Loading RS780 Microcode
>>> [drm] PCIE GART of 512M enabled (table at 0xC004).
>>> radeon :01:05.0: WB enabled
>>> radeon :01:05.0: fence driver on ring 0 use gpu addr
>>0xac00 and cpu addr 0x880215c30c00
>>> radeon :01:05.0: fence driver on ring 3 use gpu addr
>>0xac0c and cpu addr 0x880215c30c0c
>>> [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
>>> [drm] Driver supports precise vblank timestamp query.
>>> [drm] radeon: irq initialized.
>>> radeon :01:05.0: setting latency timer to 64
>>> [drm] ring test on 0 succeeded in 1 usecs
>>> [drm:r600_dma_ring_test] *ERROR* radeon: ring 3 test failed
>>(0xCAFEDEAD)
>>> radeon :01:05.0: disabling GPU acceleration
>>> radeon :01:05.0: 8802161cfc00 unpin not necessary
>>> [drm] Radeon Display Connectors
>>> [drm] Connector 0:
>>> [drm]   VGA-1
>>> [drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
>>> [drm]   Encoders:
>>> [drm] CRT1: INTERNAL_KLDSCP_DAC1
>>> [drm] Connector 1:
>>> [drm]   DVI-D-1
>>> [drm]   HPD3
>>> [drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
>>> [drm]   Encoders:
>>> [drm] DFP3: INTERNAL_KLDSCP_LVTMA
>>> == power state 0 ==
>>> ui class: none
>>> internal class: boot
>>> caps: video
>>> uvdvclk: 0 dclk: 0
>>> power level 0sclk: 5 vddc_index: 2
>>> power level 1sclk: 5 vddc_index: 2
>>> status: c r b
>>> == power state 1 ==
>>> ui class: performance
>>> internal class: none
>>> caps: video
>>> uvdvclk: 0 dclk: 0
>>> power level 0sclk: 5 vddc_index: 1
>>> power level 1sclk: 7 vddc_index: 2
>>> status:
>>> == power state 2 ==
>>> ui class: none
>>> internal class: uvd
>>> caps: video
>>> uvdvclk: 53300 dclk: 4
>>> power level 0sclk: 5 vddc_index: 1
>>> power level 1sclk: 5 vddc_index: 1
>>> status:
>>> switching from power state:
>>> ui class: none
>>> internal class: boot
>>> caps: video
>>> uvdvclk: 0 dclk: 0
>>> power level 0sclk: 5 vddc_index: 2
>>> power level 1sclk: 5 vddc_index: 2
>>> status: c b
>>> switching to power state:
>>> ui class: performance
>>> internal class: none
>>> caps: video
>>> uvdvclk: 0 

[Bug 67435] HDMI audio silent on Radeon Mobility HD4650

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=67435

--- Comment #8 from Kris Scott  ---
Oops, sorry, here you go.

Good:

Audio clocks:
R600_AUDIO_PLL1_MUL
R600_AUDIO_PLL1_DIV
R600_AUDIO_PLL2_MUL00249f00
R600_AUDIO_PLL2_DIV00714be8
R600_AUDIO_CLK_SRCSEL0001

Audio general:
R600_AUDIO_ENABLE81f0
R600_AUDIO_TIMING0170

Audio params:
R600_AUDIO_VENDOR_ID1002aa01
R600_AUDIO_REVISION_ID00100100
R600_AUDIO_ROOT_NODE_COUNT00010001
R600_AUDIO_NID1_NODE_COUNT00020002
R600_AUDIO_NID1_TYPE0001
R600_AUDIO_SUPPORTED_SIZE_RATE00020070
R600_AUDIO_SUPPORTED_CODEC0001
R600_AUDIO_SUPPORTED_POWER_STATES0009
R600_AUDIO_NID2_CAPS0201
R600_AUDIO_NID3_CAPS00400381
R600_AUDIO_NID3_PIN_CAPS0094

Audio conn list:
R600_AUDIO_CONN_LIST_LEN0001
R600_AUDIO_CONN_LIST08060402

Audio verbs:
R600_AUDIO_RATE_BPS_CHANNEL4011
R600_AUDIO_PLAYING0010
R600_AUDIO_IMPLEMENTATION_ID104d2e00
R600_AUDIO_CONFIG_DEFAULT18560010
R600_AUDIO_PIN_SENSE7fff
R600_AUDIO_PIN_WIDGET_CNTL40404040
R600_AUDIO_STATUS_BITS0001

HDMI block at 0x7400:
74000011 (17)
7404 (0)
74080010 (16)
740c0001 (65536)
7410 (0)
7414 (0)
7418 (0)
741c (0)
7420 (0)
7424 (0)
7428 (0)
742c (0)
7430 (0)
7434 (0)
7438 (0)
743c (0)
7440 (0)
7444 (0)
7448 (0)
744c (0)
7450 (0)
7454 (0)
7458 (0)
745c (0)
74600200 (33554432)
7464 (0)
7468 (0)
746c (0)
7470 (0)
7474 (0)
7478 (0)
747c (0)
7480 (0)
7484 (0)
7488 (0)
748c (0)
7490 (0)
7494 (0)
7498 (0)
749c (0)
74a0 (0)
74a4 (0)
74a8 (0)
74ac (0)
74b0 (0)
74b4 (0)
74b8 (0)
74bc (0)
74c0 (0)
74c4 (0)
74c8 (0)
74cc0170 (368)
74d0 (0)
74d41000 (268435456)
74d8 (0)
74dc (0)
74e0 (0)
74e4 (0)
74e8 (0)
74ec (0)

HDMI block at 0x7800:
78000011 (17)
78040001 (65536)
780800030010 (196624)
780c1000 (4096)
78100031 (49)
78140033 (51)
78180202 (514)
781c (0)
7820 (0)
7824 (0)
7828 (0)
782c (0)
7830 (0)
7834 (0)
7838 (0)
783c (0)
7840 (0)
7844 (0)
7848 (0)
784c (0)
7850 (0)
785400080065 (524389)
78580004 (4)
785c (0)
7860 (0)
7864 (0)
7868 (0)
786c (0)
7870 (0)
7874 (0)
7878 (0)
787c (0)
7880 (0)
7884 (0)
7888 (0)
788c (0)
7890 (0)
7894 (0)
7898 (0)
789c (0)
78a0 (0)
78a4 (0)
78a8 (0)
78ac1220a000 (304128000)
78b01000 (4096)
78b414244000 (33792)
78b81880 (6272)
78bc1220a000 (304128000)
78c01800 (6144)
78c414242000 (337911808)
78c81880 (6272)
78cc0170 (368)
78d0 (0)
78d4 (0)
78d80002 (2)
78dc1100 (4352)
78e000ff (16777215)
78e4007f (8388607)
78e80001 (1)
78ec0001 (1)


Bad:

Audio clocks:
R600_AUDIO_PLL1_MUL00249f00
R600_AUDIO_PLL1_DIV00714be8
R600_AUDIO_PLL2_MUL
R600_AUDIO_PLL2_DIV
R600_AUDIO_CLK_SRCSEL

Audio general:
R600_AUDIO_ENABLE811000f0
R600_AUDIO_TIMING0070

Audio params:
R600_AUDIO_VENDOR_ID1002aa01
R600_AUDIO_REVISION_ID00100100
R600_AUDIO_ROOT_NODE_COUNT00010001
R600_AUDIO_NID1_NODE_COUNT00020002
R600_AUDIO_NID1_TYPE0001
R600_AUDIO_SUPPORTED_SIZE_RATE00020070
R600_AUDIO_SUPPORTED_CODEC0001
R600_AUDIO_SUPPORTED_POWER_STATES0009
R600_AUDIO_NID2_CAPS0201
R600_AUDIO_NID3_CAPS00400381
R600_AUDIO_NID3_PIN_CAPS

[Bug 66067] Trine 2's fragment normal buffer is mixtextured on Radeon HD 6770 (Juniper)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=66067

Nicholas Miell  changed:

   What|Removed |Added

Summary|Trine 2 color problems on   |Trine 2's fragment normal
   |Radeon HD 6770 (Juniper)|buffer is mixtextured on
   ||Radeon HD 6770 (Juniper)

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 67107] Xorg starts and crashes with DPM enable

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=67107

--- Comment #3 from Christopher Chmielewski  ---
I just tried with rc3 and it still happens.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 67435] HDMI audio silent on Radeon Mobility HD4650

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=67435

--- Comment #9 from Rafał Miłecki  ---
@Kris: thank you for you debugging! I hope this is last debugging request.

Can you boot not working (bad) kernel, connect HDMI display and then type:

avivotool regset 0x0524 0x00249f00
avivotool regset 0x0528 0x00714be8
avivotool regset 0x0534 0x0001

I hope this will resume audio on your card, but I just want to be sure, before
asking Alex for getting more details on that.

If you could confirm that above 3 commands fix audio for you, it'd be great.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Commit f5d9b7f0f9 (fix r600_enable_sclk_control()) causes kexec issues

[Alex Deucher]

On Mon, Jul 29, 2013 at 2:10 PM, Eric W. Biederman
 wrote:
> Alex Deucher  writes:
>
>> On Mon, Jul 29, 2013 at 11:50 AM, Eric W. Biederman
>>  wrote:
>>>
>>>
>>> Alex Deucher  wrote:
On Mon, Jul 29, 2013 at 10:09 AM, Markus Trippelsdorf
 wrote:
> On 2013.07.29 at 09:58 -0400, Alex Deucher wrote:
>> On Mon, Jul 29, 2013 at 3:51 AM, Markus Trippelsdorf
>>  wrote:
>> > On my test machine Xorg doesn't start anymore when I kexec into a
>> > 3.11.0-rc3 kernel.
>>
>> With kexec, dpm doesn't get torn down properly which can result in a
>> bad hardware state when the driver loads again.  Does the attached
>> patch help?  It attempts to disable dpm at startup in case it wasn't
>> torn down properly previously.
>
> dpm initialization now works, but unfortunately GPU acceleration
still gets
> disabled:

Stupid kexec complicates things.  We need to make sure dpm is torn
down before we init the rest of the GPU, but dpm needs get initialized
later in the init process since it depends on certain other state from
the driver.  I need to think about this for a bit.  I'm not sure of a
good way to handle this.
>>>
>>> You might just want to implement a shutdown method that cleans things up 
>>> properly.   At least as a first pass until you worry about things like 
>>> kexec on panic.
>>>
>>> Or can you not shutdown the graphics stack on reboot because of the need to 
>>> display the kernels shutdown progress?
>>
>> Does kexec actually call this shutdown method?  The driver implements
>> appropriate clean-up measures if it's shutdown properly.
>
> Absoltuely.  All parts of the reboot path call ->shutdown.  Including
> kexec.
>
> You don't get a device remove/hotunplug but unless this is a kexec on
> panic ->shutdown is most definitely called.  Now I am talking about the
> device layer/pci layer shutdown method I don't know how gpu drivers are
> wired up.  GPU land was a little strange last I looked.  Hopefully it
> isn't so strange that there is a method named shutdown that is not wired
> up.

It doesn't look like the drm infrastructure has a shutdown callback.
The drm drivers register a drm_driver callback struct that includes an
unload callback which takes care of all the device teardown (if you
unload the module for example).  I don't know that it actually gets
called at kexec time however.  I don't know enough about how kexec
works.

Markus, does everything work ok after a reboot?  Is it just kexec that
is a problem?

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

Re: Commit f5d9b7f0f9 (fix r600_enable_sclk_control()) causes kexec issues

[Markus Trippelsdorf]

On 2013.07.29 at 15:53 -0400, Alex Deucher wrote:
> On Mon, Jul 29, 2013 at 2:10 PM, Eric W. Biederman
>  wrote:
> > Alex Deucher  writes:
> >
> >> On Mon, Jul 29, 2013 at 11:50 AM, Eric W. Biederman
> >>  wrote:
> >>>
> >>>
> >>> Alex Deucher  wrote:
> On Mon, Jul 29, 2013 at 10:09 AM, Markus Trippelsdorf
>  wrote:
> > On 2013.07.29 at 09:58 -0400, Alex Deucher wrote:
> >> On Mon, Jul 29, 2013 at 3:51 AM, Markus Trippelsdorf
> >>  wrote:
> >> > On my test machine Xorg doesn't start anymore when I kexec into a
> >> > 3.11.0-rc3 kernel.
> >>
> >> With kexec, dpm doesn't get torn down properly which can result in a
> >> bad hardware state when the driver loads again.  Does the attached
> >> patch help?  It attempts to disable dpm at startup in case it wasn't
> >> torn down properly previously.
> >
> > dpm initialization now works, but unfortunately GPU acceleration
> still gets
> > disabled:
> 
> Stupid kexec complicates things.  We need to make sure dpm is torn
> down before we init the rest of the GPU, but dpm needs get initialized
> later in the init process since it depends on certain other state from
> the driver.  I need to think about this for a bit.  I'm not sure of a
> good way to handle this.
> >>>
> >>> You might just want to implement a shutdown method that cleans things up 
> >>> properly.   At least as a first pass until you worry about things like 
> >>> kexec on panic.
> >>>
> >>> Or can you not shutdown the graphics stack on reboot because of the need 
> >>> to display the kernels shutdown progress?
> >>
> >> Does kexec actually call this shutdown method?  The driver implements
> >> appropriate clean-up measures if it's shutdown properly.
> >
> > Absoltuely.  All parts of the reboot path call ->shutdown.  Including
> > kexec.
> >
> > You don't get a device remove/hotunplug but unless this is a kexec on
> > panic ->shutdown is most definitely called.  Now I am talking about the
> > device layer/pci layer shutdown method I don't know how gpu drivers are
> > wired up.  GPU land was a little strange last I looked.  Hopefully it
> > isn't so strange that there is a method named shutdown that is not wired
> > up.
> 
> It doesn't look like the drm infrastructure has a shutdown callback.
> The drm drivers register a drm_driver callback struct that includes an
> unload callback which takes care of all the device teardown (if you
> unload the module for example).  I don't know that it actually gets
> called at kexec time however.  I don't know enough about how kexec
> works.
> 
> Markus, does everything work ok after a reboot?  Is it just kexec that
> is a problem?

Yes.

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

[pull] radeon drm-fixes-3.11

[alexdeucher]

From: Alex Deucher 

Hi Dave,

A few more radeon bug fixes, mostly for SI dpm.  At this point dpm is
pretty solid across the majority of asics.  I think we mostly just have
corner cases and fixing up some of the trickier features at this point.

The following changes since commit bf903e4141fce4b35072d5b8fa0ddd299aaf01ea:

  Merge tag 'drm-intel-fixes-2013-07-25' of 
git://people.freedesktop.org/~danvet/drm-intel into drm-fixes (2013-07-26 
20:38:14 +1000)

are available in the git repository at:

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

Alex Deucher (10):
  drm/radeon: fix audio dto programming on DCE4+
  drm/radeon/dpm: fix display gap programming on SI
  drm/radeon/dpm: fix si_calculate_memory_refresh_rate()
  drm/radeon/dpm: fix powertune handling for pci id 0x6835
  drm/radeon: properly handle cg on asics without UVD
  drm/radeon/atom: fix fb when fetching engine params
  drm/radeon/dpm: fix forcing performance state to low on cayman
  drm/radeon/si: disable cgcg and pg for now
  drm/radeon/dpm: disable cac setup on SI
  drm/radeon/dpm: fix and enable reclocking on SI

 drivers/gpu/drm/radeon/evergreen_hdmi.c  |2 +-
 drivers/gpu/drm/radeon/ni_dpm.c  |7 +-
 drivers/gpu/drm/radeon/radeon_atombios.c |2 +-
 drivers/gpu/drm/radeon/si.c  |   14 
 drivers/gpu/drm/radeon/si_dpm.c  |   34 ++---
 5 files changed, 24 insertions(+), 35 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 67435] HDMI audio silent on Radeon Mobility HD4650

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=67435

--- Comment #10 from Kris Scott  ---
Yes, those fixed it. Thank you very much.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 67435] HDMI audio silent on Radeon Mobility HD4650

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=67435

--- Comment #11 from Alex Deucher  ---
Can you tell be the values of 0x7340, 0x7344, 0x520, and 0x530?
avivotool regmatch 0x7340
avivotool regmatch 0x7344
avivotool regmatch 0x520
avivotool regmatch 0x530

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 67435] HDMI audio silent on Radeon Mobility HD4650

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=67435

--- Comment #12 from Kris Scott  ---
0x73400x001b0018 (1769496)
0x73440x0070 (112)
0x5200x0070 (112)
0x5300x0070 (112)

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 67435] HDMI audio silent on Radeon Mobility HD4650

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=67435

--- Comment #13 from Kris Scott  ---
That is also after I had changed the registers that Rafal asked me to change,
if it makes any difference.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 67435] HDMI audio silent on Radeon Mobility HD4650

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=67435

--- Comment #14 from Alex Deucher  ---
Can you boot back into the broken state and try this alternative fix:
avivotool regset 0x7344 0x0170

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=66963

--- Comment #23 from Alex Deucher  ---
Created attachment 83246
  --> https://bugs.freedesktop.org/attachment.cgi?id=83246&action=edit
hacks to test

That attached patch disables some options in the dpm driver.  See if it helps
at all.  Make sure you are using a kernel that contains the fixes mentioned in
comment 9 or my drm-fixes-3.11 branch.

If the patch doesn't work as is, try changing the:
#if 1
in the patch to:
#if 0
and see if that helps.

Please attach your dmesg output with the patch applied.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [3.10rc6] /proc/dri/0/vma broken on nouveau.

[Dave Jones]

On Mon, Jun 17, 2013 at 09:49:27PM -0400, David Airlie wrote:
 > 
 > > Reading /proc/dri/0/vma causes bad things to happen on a box with nouveau
 > > loaded.
 > > (Note, no X running on that box)
 > > 
 > > Trace below shows trinity, but I can reproduce it with just cat
 > > /proc/dri/0/vma
 > 
 > How about this, lets just rip it all out.

No-one objected, and this is still around in 3.11-rc3 in the same
easily oopsable state.. I vote we kill it with fire.

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

[Bug 60381] AMD Radeon 7770 Ghz edition Crash with DPM active

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=60381

--- Comment #34 from rafael castillo  ---
tested with today drm-fixes patches and its reclocking like a boss and xonotic
passed from 30 FPS to an massive 190FPS in ultimate at 1366x768. i read you
need some fixes for other part of asic for later so is up to you if you wish to
close the bug report.

again a hundred bazillions thanks this is just awesome now

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/4] gpu/vga_switcheroo: add driver control power feature. (v3)

[Hohahiu]

Hello, Dave!

I have a hybrid muxless laptop with intel+radeon:
#lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core 
processor Graphics Controller (rev 09)
01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI 
Cape Verde [Radeon HD 7700M Series]


I have some questions related to this series of patches.
When I power down discrete card by vgaswitcheroo, restart X server and 
turn on radeon card again, xrandr doesn't recognize my discrete card and 
only shows the intel one. Is this a bug or a feature of X server?

And how would this behavior change with this patch?

Also sometimes I have the following configuration:
# cat /sys/kernel/debug/vgaswitcheroo/switch
0:DIS: :Pwr::01:00.0
1:IGD:+:Pwr::00:02.0

In this case if I do
# echo OFF > /sys/kernel/debug/vgaswitcheroo/switch
the system hangs and doesn't respond (ssh, magic keys etc.).

In the meantime for a
# cat /sys/kernel/debug/vgaswitcheroo/switch
0:IGD:+:Pwr::00:02.0
1:DIS: :Pwr::01:00.0

# echo OFF > /sys/kernel/debug/vgaswitcheroo/switch
powers down discrete card successfully.

Would it be resolved with these patches?

Hohahiu

PS. Should I open bug report for these issues?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 66942] Cayman HD 6950 hangs at start when loading kernel 3.11.0-rc1 or drm-next

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=66942

--- Comment #17 from Alexandre Demers  ---
Alex, is there a chance for me to reverse some commits prior to 69e0b57 to find
which one or which feature is hanging my computer? Any approach I should try?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm/nouveau: fix vblank interrupt being called before event is setup

[Ben Skeggs]

On Tue, Jul 23, 2013 at 11:43 PM, Maarten Lankhorst
 wrote:
> Sort of fixes mmiotrace for me again, I could sear I sent a similar patch 
> before
> the rework to event interface, so I guess it got reintroduced.
I don't know how/why you think this fixes anything.  The interrupt
handler can't possibly be called until after priv->base.vblank has
been initialised...

Seriously, go look, the subdev interrupt handler pointer isn't filled
in (and can't be) until after nouveau_disp_create() has been called,
and nouveau_disp_create() initialises priv->base.vblank before it
returns...

Ben.


>
> Signed-off-by: Maarten Lankhorst 
> ---
> diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c 
> b/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c
> index 7e3875d..35e526b 100644
> --- a/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c
> +++ b/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c
> @@ -1266,13 +1266,15 @@ nv50_disp_intr(struct nouveau_subdev *subdev)
> }
>
> if (intr1 & 0x0004) {
> -   nouveau_event_trigger(priv->base.vblank, 0);
> +   if (priv->base.vblank)
> +   nouveau_event_trigger(priv->base.vblank, 0);
> nv_wr32(priv, 0x610024, 0x0004);
> intr1 &= ~0x0004;
> }
>
> if (intr1 & 0x0008) {
> -   nouveau_event_trigger(priv->base.vblank, 1);
> +   if (priv->base.vblank)
> +   nouveau_event_trigger(priv->base.vblank, 1);
> nv_wr32(priv, 0x610024, 0x0008);
> intr1 &= ~0x0008;
> }
> diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/nvd0.c 
> b/drivers/gpu/drm/nouveau/core/engine/disp/nvd0.c
> index 52dd7a1..4095f65 100644
> --- a/drivers/gpu/drm/nouveau/core/engine/disp/nvd0.c
> +++ b/drivers/gpu/drm/nouveau/core/engine/disp/nvd0.c
> @@ -941,7 +941,7 @@ nvd0_disp_intr(struct nouveau_subdev *subdev)
> u32 mask = 0x0100 << i;
> if (mask & intr) {
> u32 stat = nv_rd32(priv, 0x6100bc + (i * 0x800));
> -   if (stat & 0x0001)
> +   if ((stat & 0x0001) && priv->base.vblank)
> nouveau_event_trigger(priv->base.vblank, i);
> nv_mask(priv, 0x6100bc + (i * 0x800), 0, 0);
> nv_rd32(priv, 0x6100c0 + (i * 0x800));
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 66942] Cayman HD 6950 hangs at start when loading kernel 3.11.0-rc1 or drm-next

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=66942

--- Comment #18 from Alex Deucher  ---
(In reply to comment #17)
> Alex, is there a chance for me to reverse some commits prior to 69e0b57 to
> find which one or which feature is hanging my computer? Any approach I
> should try?

I'm not really sure what would have broken your system.  I also don't really
see how 69e0b57 could have broken anything since nothing changes with that as
long as dpm is disabled.  Do you still have the issue if you reset your tree to
the commit prior to 69e0b57?  Do you still get hangs if you disable radeon
(e.g., add radeon.modeset=0 to your kernel command line in grub)?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 66942] Cayman HD 6950 hangs at start when loading kernel 3.11.0-rc1 or drm-next

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=66942

--- Comment #19 from Alex Deucher  ---
Does booting a recent 3.11rc kernel with radeon.aspm=0 help?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=66963

--- Comment #24 from Alex Deucher  ---
Created attachment 83257
  --> https://bugs.freedesktop.org/attachment.cgi?id=83257&action=edit
disable lvtma resync

Another patch to test.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=66963

--- Comment #25 from Alex Deucher  ---
Created attachment 83258
  --> https://bugs.freedesktop.org/attachment.cgi?id=83258&action=edit
use alternate fb_div scale

Another patch to test.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 0/2] exynos5250/hdmi: replace dummy hdmiphy clock with pmu reg control

[Rahul Sharma]

On Tue, Jun 18, 2013 at 5:07 PM, Kishon Vijay Abraham I wrote:

> Hi,
>
> On Tuesday 18 June 2013 03:33 PM, Rahul Sharma wrote:
> > Thanks all,
> >
> > On Fri, Jun 14, 2013 at 11:39 AM, 김승우  wrote:
> >> Hello Kishon,
> >>
> >> On 2013년 06월 13일 21:54, Kishon Vijay Abraham I wrote:
> >>> Hi,
> >>>
> >>> On Thursday 13 June 2013 04:51 PM, Inki Dae wrote:
> 
> 
> > -Original Message-
> > From: Sylwester Nawrocki [mailto:s.nawro...@samsung.com]
> > Sent: Thursday, June 13, 2013 5:56 PM
> > To: Rahul Sharma
> > Cc: Rahul Sharma; Inki Dae; linux-samsung-...@vger.kernel.org;
> > devicetree-
> > disc...@lists.ozlabs.org; DRI mailing list; Kukjin Kim; Seung-Woo
> Kim;
> > Sean Paul; sunil joshi; Kishon Vijay Abraham I; Stephen Warren;
> > grant.lik...@linaro.org
> > Subject: Re: [RFC 0/2] exynos5250/hdmi: replace dummy hdmiphy clock
> with
> > pmu reg control
> >
> > Hi,
> >
> > On 06/13/2013 06:26 AM, Rahul Sharma wrote:
> >> Mr. Dae,
> >>
> >> Thanks for your valuable inputs.
> >>
> >> I posted it as RFC because, I also have received comments to
> register
> >> hdmiphy as a clock controller. As we always configure it for
> specific
> >> frequency, hdmi-phy looks similar to a PLL. But it really doesn't
> >> belong to that class. Secondly prior to exynos5420, it was a i2c
> >> device. I am not sure we can register a I2C device as a clock
> >> controller. I wanted to discuss and explore this option here.
> >
> > Have you considered using the generic PHY framework for those HDMI
> > PHY devices [1] ? I guess we could add a dedicated group of ops for
> > video PHYs, similarly as is is done with struct v4l2_subdev_ops. For
> > configuring things like the carrier/pixel clock frequency or anything
> > what's common across the video PHYs.
> >
> > Perhaps you could have a look and see if this framework would be
> > useful for HDMI and possibly point out anything what might be
> missing ?
> >
> > I'm not sure it it really solves the issues specific to the Exynos
> > HDMI but at least with a generic PHY driver the PHY module would be
> > separate from the PHY controller, as often same HDMI DPHY can be used
> > with various types of a HDMI controller. So this would allow to not
> > duplicate the HDMI PHY drivers in the long-term perspective.
> 
>  Yeah, at least, it seems that we could use PHY module to control PMU
>  register, HDMI_PHY_CONTROL. However, PHY module provides only
> init/on/off
>  callbacks. As you may know, HDMIPHY needs i2c interfaces to control
>  HDMIPHY
>  clock. So with PHY module, HDMIPHY driver could enable PMU more
>  generically,
>  but also has to use existing i2c stuff to control HDMIPHY clock. I
> had a
>  quick review to Generic PHY Framework[v6] but I didn't see that the
> PHY
>  module could generically support more features such as i2c stuff.
> >>>
> >>> I don't think PHY framework needs to provide i2c interfaces to program
> >>> certain configurations. Instead in one of the callbacks (init/on/off)
> >>> PHY driver can program whatever it wants using any of the interfaces it
> >>> needs. IMO PHY framework should work independent of the interfaces.
> >>
> >> In exnoys hdmi case, i2c interface is not the exact issue. In exynos
> >> hdmi, hdmiphy should send i2c configuration about video clock
> >> information as the video mode information including resolution, bit per
> >> pixel, refresh rate passed from drm subsystem. So init/on/off callbacks
> >> of phy framework are not enough for exynos hdmiphy and it should have a
> >> callback to set video mode.
> >>
> >> Do you have plan to add driver specific extend callback pointers to phy
> >> framework?
> >>
> >> Currently, hdmi directly calls phy operations, but Rahul's another patch
> >> set, mentioned by Inki, divides hdmi and hdmiphy and hdmi and hdmiphy is
> >> connected with exynos hdmi own sub driver callback operations.
> >>
> >> IMHO, if phy framework can support extend callback feature, then this
> >> own sub driver callbacks can be replaced with phy framework at long term
> >> view.
> >
> > Extended callbacks are always welcome. I can also use phy device
> > private data to pass on private ops like get_pixelclk and set_pixelclk.
>
> I would recommend creating a wrapper to the existing PHY framework
> for HDMI PHY. That way, we can have other HDMI phys added
> easily. We need to figure out all the ops that might be needed by the
> HDMI PHY to be added to the wrapper.
> IMO extended callbacks can lead to abuse of the system and should be
> used only when absolutely necessary.
>
> Thanks
> Kishon
>

Thanks Kishon,

I have started working on this wrapper layer which is customized for video
phys.
As if now, adding set_dv_timing, get_dv_timing as the only additional
callbacks.
I will post the RFC patches.

regards,
Rahul Sharma.
___

Re: [PATCH 1/4] gpu/vga_switcheroo: add driver control power feature. (v3)

[Dave Airlie]

On Tue, Jul 30, 2013 at 11:50 AM, Hohahiu  wrote:
> Hello, Dave!
>
> I have a hybrid muxless laptop with intel+radeon:
> #lspci | grep VGA
> 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor
> Graphics Controller (rev 09)
> 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Cape
> Verde [Radeon HD 7700M Series]
>
> I have some questions related to this series of patches.
> When I power down discrete card by vgaswitcheroo, restart X server and turn
> on radeon card again, xrandr doesn't recognize my discrete card and only
> shows the intel one. Is this a bug or a feature of X server?
> And how would this behavior change with this patch?

Yes this with radeon support will save you having to power down things yourself,
so would just make it all happen dynamically and you'd never see it.

However if the machine dies on power down that could be fun to solve
with these patches as well.

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

[Bug 60639] RV635: Kernel displays black screen when monitor is connect via DisplayPort

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=60639

--- Comment #2 from Alex Deucher  ---
Created attachment 107040
  --> https://bugzilla.kernel.org/attachment.cgi?id=107040&action=edit
possible fix

The attached patch should fix the issue.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Commit f5d9b7f0f9 (fix r600_enable_sclk_control()) causes kexec issues

[Joshua C.]

2013/7/29 Alex Deucher :
> On Mon, Jul 29, 2013 at 10:09 AM, Markus Trippelsdorf
>  wrote:
>> On 2013.07.29 at 09:58 -0400, Alex Deucher wrote:
>>> On Mon, Jul 29, 2013 at 3:51 AM, Markus Trippelsdorf
>>>  wrote:
>>> > On my test machine Xorg doesn't start anymore when I kexec into a
>>> > 3.11.0-rc3 kernel.
>>>
>>> With kexec, dpm doesn't get torn down properly which can result in a
>>> bad hardware state when the driver loads again.  Does the attached
>>> patch help?  It attempts to disable dpm at startup in case it wasn't
>>> torn down properly previously.
>>
>> dpm initialization now works, but unfortunately GPU acceleration still gets
>> disabled:
>
> Stupid kexec complicates things.  We need to make sure dpm is torn
> down before we init the rest of the GPU, but dpm needs get initialized
> later in the init process since it depends on certain other state from
> the driver.  I need to think about this for a bit.  I'm not sure of a
> good way to handle this.
>
> Alex
>
>>
>> [drm] Initialized drm 1.1.0 20060810 
>>  
>>   [135/1104]
>> [drm] radeon kernel modesetting enabled.
>> [drm] initializing kernel modesetting (RS780 0x1002:0x9614 0x1043:0x834D).
>> [drm] register mmio base: 0xFBEE
>> [drm] register mmio size: 65536
>> ATOM BIOS: 113
>> radeon :01:05.0: VRAM: 128M 0xC000 - 0xC7FF 
>> (128M used)
>> radeon :01:05.0: GTT: 512M 0xA000 - 0xBFFF
>> [drm] Detected VRAM RAM=128M, BAR=128M
>> [drm] RAM width 32bits DDR
>> [TTM] Zone  kernel: Available graphics memory: 4082356 kiB
>> [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
>> [TTM] Initializing pool allocator
>> [TTM] Initializing DMA pool allocator
>> [drm] radeon: 128M of VRAM memory ready
>> [drm] radeon: 512M of GTT memory ready.
>> [drm] GART: num cpu pages 131072, num gpu pages 131072
>> [drm] Loading RS780 Microcode
>> [drm] PCIE GART of 512M enabled (table at 0xC004).
>> radeon :01:05.0: WB enabled
>> radeon :01:05.0: fence driver on ring 0 use gpu addr 0xac00 
>> and cpu addr 0x880215c30c00
>> radeon :01:05.0: fence driver on ring 3 use gpu addr 0xac0c 
>> and cpu addr 0x880215c30c0c
>> [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
>> [drm] Driver supports precise vblank timestamp query.
>> [drm] radeon: irq initialized.
>> radeon :01:05.0: setting latency timer to 64
>> [drm] ring test on 0 succeeded in 1 usecs
>> [drm:r600_dma_ring_test] *ERROR* radeon: ring 3 test failed (0xCAFEDEAD)
>> radeon :01:05.0: disabling GPU acceleration
>> radeon :01:05.0: 8802161cfc00 unpin not necessary
>> [drm] Radeon Display Connectors
>> [drm] Connector 0:
>> [drm]   VGA-1
>> [drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
>> [drm]   Encoders:
>> [drm] CRT1: INTERNAL_KLDSCP_DAC1
>> [drm] Connector 1:
>> [drm]   DVI-D-1
>> [drm]   HPD3
>> [drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
>> [drm]   Encoders:
>> [drm] DFP3: INTERNAL_KLDSCP_LVTMA
>> == power state 0 ==
>> ui class: none
>> internal class: boot
>> caps: video
>> uvdvclk: 0 dclk: 0
>> power level 0sclk: 5 vddc_index: 2
>> power level 1sclk: 5 vddc_index: 2
>> status: c r b
>> == power state 1 ==
>> ui class: performance
>> internal class: none
>> caps: video
>> uvdvclk: 0 dclk: 0
>> power level 0sclk: 5 vddc_index: 1
>> power level 1sclk: 7 vddc_index: 2
>> status:
>> == power state 2 ==
>> ui class: none
>> internal class: uvd
>> caps: video
>> uvdvclk: 53300 dclk: 4
>> power level 0sclk: 5 vddc_index: 1
>> power level 1sclk: 5 vddc_index: 1
>> status:
>> switching from power state:
>> ui class: none
>> internal class: boot
>> caps: video
>> uvdvclk: 0 dclk: 0
>> power level 0sclk: 5 vddc_index: 2
>> power level 1sclk: 5 vddc_index: 2
>> status: c b
>> switching to power state:
>> ui class: performance
>> internal class: none
>> caps: video
>> uvdvclk: 0 dclk: 0
>> power level 0sclk: 5 vddc_index: 1
>> power level 1sclk: 7 vddc_index: 2
>> status: r
>> [drm] radeon: dpm initialized
>> [drm] fb mappable at 0xF0142000
>> [drm] vram apper at 0xF000
>> [drm] size 7299072
>> [drm] fb depth is 24
>> [drm]pitch is 6912
>> fbcon: radeondrmfb (fb0)
>>
>> --
>> Markus
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/li

Re: Commit f5d9b7f0f9 (fix r600_enable_sclk_control()) causes kexec issues

[Eric W. Biederman]

Alex Deucher  wrote:
>On Mon, Jul 29, 2013 at 10:09 AM, Markus Trippelsdorf
> wrote:
>> On 2013.07.29 at 09:58 -0400, Alex Deucher wrote:
>>> On Mon, Jul 29, 2013 at 3:51 AM, Markus Trippelsdorf
>>>  wrote:
>>> > On my test machine Xorg doesn't start anymore when I kexec into a
>>> > 3.11.0-rc3 kernel.
>>>
>>> With kexec, dpm doesn't get torn down properly which can result in a
>>> bad hardware state when the driver loads again.  Does the attached
>>> patch help?  It attempts to disable dpm at startup in case it wasn't
>>> torn down properly previously.
>>
>> dpm initialization now works, but unfortunately GPU acceleration
>still gets
>> disabled:
>
>Stupid kexec complicates things.  We need to make sure dpm is torn
>down before we init the rest of the GPU, but dpm needs get initialized
>later in the init process since it depends on certain other state from
>the driver.  I need to think about this for a bit.  I'm not sure of a
>good way to handle this.

You might just want to implement a shutdown method that cleans things up 
properly.   At least as a first pass until you worry about things like kexec on 
panic.

Or can you not shutdown the graphics stack on reboot because of the need to 
display the kernels shutdown progress?

Eric

>Alex
>
>>
>> [drm] Initialized drm 1.1.0 20060810 
> [135/1104]
>> [drm] radeon kernel modesetting enabled.
>> [drm] initializing kernel modesetting (RS780 0x1002:0x9614
>0x1043:0x834D).
>> [drm] register mmio base: 0xFBEE
>> [drm] register mmio size: 65536
>> ATOM BIOS: 113
>> radeon :01:05.0: VRAM: 128M 0xC000 -
>0xC7FF (128M used)
>> radeon :01:05.0: GTT: 512M 0xA000 -
>0xBFFF
>> [drm] Detected VRAM RAM=128M, BAR=128M
>> [drm] RAM width 32bits DDR
>> [TTM] Zone  kernel: Available graphics memory: 4082356 kiB
>> [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
>> [TTM] Initializing pool allocator
>> [TTM] Initializing DMA pool allocator
>> [drm] radeon: 128M of VRAM memory ready
>> [drm] radeon: 512M of GTT memory ready.
>> [drm] GART: num cpu pages 131072, num gpu pages 131072
>> [drm] Loading RS780 Microcode
>> [drm] PCIE GART of 512M enabled (table at 0xC004).
>> radeon :01:05.0: WB enabled
>> radeon :01:05.0: fence driver on ring 0 use gpu addr
>0xac00 and cpu addr 0x880215c30c00
>> radeon :01:05.0: fence driver on ring 3 use gpu addr
>0xac0c and cpu addr 0x880215c30c0c
>> [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
>> [drm] Driver supports precise vblank timestamp query.
>> [drm] radeon: irq initialized.
>> radeon :01:05.0: setting latency timer to 64
>> [drm] ring test on 0 succeeded in 1 usecs
>> [drm:r600_dma_ring_test] *ERROR* radeon: ring 3 test failed
>(0xCAFEDEAD)
>> radeon :01:05.0: disabling GPU acceleration
>> radeon :01:05.0: 8802161cfc00 unpin not necessary
>> [drm] Radeon Display Connectors
>> [drm] Connector 0:
>> [drm]   VGA-1
>> [drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
>> [drm]   Encoders:
>> [drm] CRT1: INTERNAL_KLDSCP_DAC1
>> [drm] Connector 1:
>> [drm]   DVI-D-1
>> [drm]   HPD3
>> [drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
>> [drm]   Encoders:
>> [drm] DFP3: INTERNAL_KLDSCP_LVTMA
>> == power state 0 ==
>> ui class: none
>> internal class: boot
>> caps: video
>> uvdvclk: 0 dclk: 0
>> power level 0sclk: 5 vddc_index: 2
>> power level 1sclk: 5 vddc_index: 2
>> status: c r b
>> == power state 1 ==
>> ui class: performance
>> internal class: none
>> caps: video
>> uvdvclk: 0 dclk: 0
>> power level 0sclk: 5 vddc_index: 1
>> power level 1sclk: 7 vddc_index: 2
>> status:
>> == power state 2 ==
>> ui class: none
>> internal class: uvd
>> caps: video
>> uvdvclk: 53300 dclk: 4
>> power level 0sclk: 5 vddc_index: 1
>> power level 1sclk: 5 vddc_index: 1
>> status:
>> switching from power state:
>> ui class: none
>> internal class: boot
>> caps: video
>> uvdvclk: 0 dclk: 0
>> power level 0sclk: 5 vddc_index: 2
>> power level 1sclk: 5 vddc_index: 2
>> status: c b
>> switching to power state:
>> ui class: performance
>> internal class: none
>> caps: video
>> uvdvclk: 0 dclk: 0
>> power level 0sclk: 5 vddc_index: 1
>> power level 1sclk: 7 vddc_index: 2
>> status: r
>> [drm] radeon: dpm initialized
>> [drm] fb mappable at 0xF0142000
>> [drm] vram apper at 0xF000
>> [drm] size 7299072
>> [drm] fb depth

Re: Commit f5d9b7f0f9 (fix r600_enable_sclk_control()) causes kexec issues

[Eric W. Biederman]

Alex Deucher  writes:

> On Mon, Jul 29, 2013 at 11:50 AM, Eric W. Biederman
>  wrote:
>>
>>
>> Alex Deucher  wrote:
>>>On Mon, Jul 29, 2013 at 10:09 AM, Markus Trippelsdorf
>>> wrote:
 On 2013.07.29 at 09:58 -0400, Alex Deucher wrote:
> On Mon, Jul 29, 2013 at 3:51 AM, Markus Trippelsdorf
>  wrote:
> > On my test machine Xorg doesn't start anymore when I kexec into a
> > 3.11.0-rc3 kernel.
>
> With kexec, dpm doesn't get torn down properly which can result in a
> bad hardware state when the driver loads again.  Does the attached
> patch help?  It attempts to disable dpm at startup in case it wasn't
> torn down properly previously.

 dpm initialization now works, but unfortunately GPU acceleration
>>>still gets
 disabled:
>>>
>>>Stupid kexec complicates things.  We need to make sure dpm is torn
>>>down before we init the rest of the GPU, but dpm needs get initialized
>>>later in the init process since it depends on certain other state from
>>>the driver.  I need to think about this for a bit.  I'm not sure of a
>>>good way to handle this.
>>
>> You might just want to implement a shutdown method that cleans things up 
>> properly.   At least as a first pass until you worry about things like kexec 
>> on panic.
>>
>> Or can you not shutdown the graphics stack on reboot because of the need to 
>> display the kernels shutdown progress?
>
> Does kexec actually call this shutdown method?  The driver implements
> appropriate clean-up measures if it's shutdown properly.

Absoltuely.  All parts of the reboot path call ->shutdown.  Including
kexec.

You don't get a device remove/hotunplug but unless this is a kexec on
panic ->shutdown is most definitely called.  Now I am talking about the
device layer/pci layer shutdown method I don't know how gpu drivers are
wired up.  GPU land was a little strange last I looked.  Hopefully it
isn't so strange that there is a method named shutdown that is not wired
up.

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

[PATCH] Fix #include in drm_mm.h to unbreak ia64 build

[Luck, Tony]

Linux-next build on ia64 is falling over with errors like this:

In file included from include/drm/drm_vma_manager.h:26,
 from include/drm/ttm/ttm_bo_api.h:35,
 from include/drm/ttm/ttm_bo_driver.h:33,
 from drivers/gpu/drm/ttm/ttm_agp_backend.c:35:
include/drm/drm_mm.h:67: error: expected specifier-qualifier-list before 
'spinlock_t'

I guess other architectures are pulling in spinlock.h
through some twisty #include path so are not seeing this
error.  But drm_mm.h makes use of spinlock_t - so it
should do the right thing and #include 

Signed-off-by: Tony Luck 

---

First saw this break in tag "next-20130726"

diff --git a/include/drm/drm_mm.h b/include/drm/drm_mm.h
index b87d05e..7d5fbae 100644
--- a/include/drm/drm_mm.h
+++ b/include/drm/drm_mm.h
@@ -37,6 +37,7 @@
  * Generic range manager structs
  */
 #include 
+#include 
 #ifdef CONFIG_DEBUG_FS
 #include 
 #endif
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 0/2] exynos5250/hdmi: replace dummy hdmiphy clock with pmu reg control

[Kishon Vijay Abraham I]

Hi,

On Tuesday 30 July 2013 09:12 AM, Rahul Sharma wrote:
> 
> 
> On Tue, Jun 18, 2013 at 5:07 PM, Kishon Vijay Abraham I  > wrote:
> 
> Hi,
> 
> On Tuesday 18 June 2013 03:33 PM, Rahul Sharma wrote:
> > Thanks all,
> >
> > On Fri, Jun 14, 2013 at 11:39 AM, 김승우  > wrote:
> >> Hello Kishon,
> >>
> >> On 2013년 06월 13일 21:54, Kishon Vijay Abraham I wrote:
> >>> Hi,
> >>>
> >>> On Thursday 13 June 2013 04:51 PM, Inki Dae wrote:
> 
> 
> > -Original Message-
> > From: Sylwester Nawrocki [mailto:s.nawro...@samsung.com
> ]
> > Sent: Thursday, June 13, 2013 5:56 PM
> > To: Rahul Sharma
> > Cc: Rahul Sharma; Inki Dae; linux-samsung-...@vger.kernel.org
> ;
> > devicetree-
> > disc...@lists.ozlabs.org ; DRI
> mailing list; Kukjin Kim; Seung-Woo Kim;
> > Sean Paul; sunil joshi; Kishon Vijay Abraham I; Stephen Warren;
> > grant.lik...@linaro.org 
> > Subject: Re: [RFC 0/2] exynos5250/hdmi: replace dummy hdmiphy clock 
> with
> > pmu reg control
> >
> > Hi,
> >
> > On 06/13/2013 06:26 AM, Rahul Sharma wrote:
> >> Mr. Dae,
> >>
> >> Thanks for your valuable inputs.
> >>
> >> I posted it as RFC because, I also have received comments to 
> register
> >> hdmiphy as a clock controller. As we always configure it for 
> specific
> >> frequency, hdmi-phy looks similar to a PLL. But it really doesn't
> >> belong to that class. Secondly prior to exynos5420, it was a i2c
> >> device. I am not sure we can register a I2C device as a clock
> >> controller. I wanted to discuss and explore this option here.
> >
> > Have you considered using the generic PHY framework for those HDMI
> > PHY devices [1] ? I guess we could add a dedicated group of ops for
> > video PHYs, similarly as is is done with struct v4l2_subdev_ops. For
> > configuring things like the carrier/pixel clock frequency or 
> anything
> > what's common across the video PHYs.
> >
> > Perhaps you could have a look and see if this framework would be
> > useful for HDMI and possibly point out anything what might be 
> missing ?
> >
> > I'm not sure it it really solves the issues specific to the Exynos
> > HDMI but at least with a generic PHY driver the PHY module would be
> > separate from the PHY controller, as often same HDMI DPHY can be 
> used
> > with various types of a HDMI controller. So this would allow to not
> > duplicate the HDMI PHY drivers in the long-term perspective.
> 
>  Yeah, at least, it seems that we could use PHY module to control PMU
>  register, HDMI_PHY_CONTROL. However, PHY module provides only 
> init/on/off
>  callbacks. As you may know, HDMIPHY needs i2c interfaces to control
>  HDMIPHY
>  clock. So with PHY module, HDMIPHY driver could enable PMU more
>  generically,
>  but also has to use existing i2c stuff to control HDMIPHY clock. I 
> had a
>  quick review to Generic PHY Framework[v6] but I didn't see that the 
> PHY
>  module could generically support more features such as i2c stuff.
> >>>
> >>> I don't think PHY framework needs to provide i2c interfaces to program
> >>> certain configurations. Instead in one of the callbacks (init/on/off)
> >>> PHY driver can program whatever it wants using any of the interfaces 
> it
> >>> needs. IMO PHY framework should work independent of the interfaces.
> >>
> >> In exnoys hdmi case, i2c interface is not the exact issue. In exynos
> >> hdmi, hdmiphy should send i2c configuration about video clock
> >> information as the video mode information including resolution, bit per
> >> pixel, refresh rate passed from drm subsystem. So init/on/off callbacks
> >> of phy framework are not enough for exynos hdmiphy and it should have a
> >> callback to set video mode.
> >>
> >> Do you have plan to add driver specific extend callback pointers to phy
> >> framework?
> >>
> >> Currently, hdmi directly calls phy operations, but Rahul's another 
> patch
> >> set, mentioned by Inki, divides hdmi and hdmiphy and hdmi and hdmiphy 
> is
> >> connected with exynos hdmi own sub driver callback operations.
> >>
> >> IMHO, if phy framework can support extend callback feature, then this
> >> own sub driver callbacks can be replaced with phy framework at long 
> term
> >> view.
> >
> > Extended callbacks are always welcome. I can also use phy device
> > private data t

Re: [RFC 0/2] exynos5250/hdmi: replace dummy hdmiphy clock with pmu reg control

[Rahul Sharma]

On Tue, Jul 30, 2013 at 10:37 AM, Kishon Vijay Abraham I wrote:

> Hi,
>
> On Tuesday 30 July 2013 09:12 AM, Rahul Sharma wrote:
> >
> >
> > On Tue, Jun 18, 2013 at 5:07 PM, Kishon Vijay Abraham I  > > wrote:
> >
> > Hi,
> >
> > On Tuesday 18 June 2013 03:33 PM, Rahul Sharma wrote:
> > > Thanks all,
> > >
> > > On Fri, Jun 14, 2013 at 11:39 AM, 김승우  > > wrote:
> > >> Hello Kishon,
> > >>
> > >> On 2013년 06월 13일 21:54, Kishon Vijay Abraham I wrote:
> > >>> Hi,
> > >>>
> > >>> On Thursday 13 June 2013 04:51 PM, Inki Dae wrote:
> > 
> > 
> > > -Original Message-
> > > From: Sylwester Nawrocki [mailto:s.nawro...@samsung.com
> > ]
> > > Sent: Thursday, June 13, 2013 5:56 PM
> > > To: Rahul Sharma
> > > Cc: Rahul Sharma; Inki Dae; linux-samsung-...@vger.kernel.org
> > ;
> > > devicetree-
> > > disc...@lists.ozlabs.org ;
> DRI
> > mailing list; Kukjin Kim; Seung-Woo Kim;
> > > Sean Paul; sunil joshi; Kishon Vijay Abraham I; Stephen Warren;
> > > grant.lik...@linaro.org 
> > > Subject: Re: [RFC 0/2] exynos5250/hdmi: replace dummy hdmiphy
> clock with
> > > pmu reg control
> > >
> > > Hi,
> > >
> > > On 06/13/2013 06:26 AM, Rahul Sharma wrote:
> > >> Mr. Dae,
> > >>
> > >> Thanks for your valuable inputs.
> > >>
> > >> I posted it as RFC because, I also have received comments to
> register
> > >> hdmiphy as a clock controller. As we always configure it for
> specific
> > >> frequency, hdmi-phy looks similar to a PLL. But it really
> doesn't
> > >> belong to that class. Secondly prior to exynos5420, it was a
> i2c
> > >> device. I am not sure we can register a I2C device as a clock
> > >> controller. I wanted to discuss and explore this option here.
> > >
> > > Have you considered using the generic PHY framework for those
> HDMI
> > > PHY devices [1] ? I guess we could add a dedicated group of
> ops for
> > > video PHYs, similarly as is is done with struct
> v4l2_subdev_ops. For
> > > configuring things like the carrier/pixel clock frequency or
> anything
> > > what's common across the video PHYs.
> > >
> > > Perhaps you could have a look and see if this framework would
> be
> > > useful for HDMI and possibly point out anything what might be
> missing ?
> > >
> > > I'm not sure it it really solves the issues specific to the
> Exynos
> > > HDMI but at least with a generic PHY driver the PHY module
> would be
> > > separate from the PHY controller, as often same HDMI DPHY can
> be used
> > > with various types of a HDMI controller. So this would allow
> to not
> > > duplicate the HDMI PHY drivers in the long-term perspective.
> > 
> >  Yeah, at least, it seems that we could use PHY module to
> control PMU
> >  register, HDMI_PHY_CONTROL. However, PHY module provides only
> init/on/off
> >  callbacks. As you may know, HDMIPHY needs i2c interfaces to
> control
> >  HDMIPHY
> >  clock. So with PHY module, HDMIPHY driver could enable PMU more
> >  generically,
> >  but also has to use existing i2c stuff to control HDMIPHY
> clock. I had a
> >  quick review to Generic PHY Framework[v6] but I didn't see that
> the PHY
> >  module could generically support more features such as i2c
> stuff.
> > >>>
> > >>> I don't think PHY framework needs to provide i2c interfaces to
> program
> > >>> certain configurations. Instead in one of the callbacks
> (init/on/off)
> > >>> PHY driver can program whatever it wants using any of the
> interfaces it
> > >>> needs. IMO PHY framework should work independent of the
> interfaces.
> > >>
> > >> In exnoys hdmi case, i2c interface is not the exact issue. In
> exynos
> > >> hdmi, hdmiphy should send i2c configuration about video clock
> > >> information as the video mode information including resolution,
> bit per
> > >> pixel, refresh rate passed from drm subsystem. So init/on/off
> callbacks
> > >> of phy framework are not enough for exynos hdmiphy and it should
> have a
> > >> callback to set video mode.
> > >>
> > >> Do you have plan to add driver specific extend callback pointers
> to phy
> > >> framework?
> > >>
> > >> Currently, hdmi directly calls phy operations, but Rahul's
> another patch
> > >> set, mentioned by Inki, divides hdmi and hdmiphy and hdmi and
> hdmiphy is
> > >> connected with exynos hdmi own sub driver callback operations.
> > >>

Re: [RFC 0/2] exynos5250/hdmi: replace dummy hdmiphy clock with pmu reg control

[Seung-Woo Kim]

Hi Rahul,

On 2013년 07월 30일 12:42, Rahul Sharma wrote:
> 
> 
> On Tue, Jun 18, 2013 at 5:07 PM, Kishon Vijay Abraham I  > wrote:
> 
> Hi,
> 
> On Tuesday 18 June 2013 03:33 PM, Rahul Sharma wrote:
> > Thanks all,
> >
> > On Fri, Jun 14, 2013 at 11:39 AM, 김승우  > wrote:
> >> Hello Kishon,
> >>
> >> On 2013년 06월 13일 21:54, Kishon Vijay Abraham I wrote:
> >>> Hi,
> >>>
> >>> On Thursday 13 June 2013 04:51 PM, Inki Dae wrote:
> 
> 
> > -Original Message-
> > From: Sylwester Nawrocki [mailto:s.nawro...@samsung.com
> ]
> > Sent: Thursday, June 13, 2013 5:56 PM
> > To: Rahul Sharma
> > Cc: Rahul Sharma; Inki Dae; linux-samsung-...@vger.kernel.org
> ;
> > devicetree-
> > disc...@lists.ozlabs.org ;
> DRI mailing list; Kukjin Kim; Seung-Woo Kim;
> > Sean Paul; sunil joshi; Kishon Vijay Abraham I; Stephen Warren;
> > grant.lik...@linaro.org 
> > Subject: Re: [RFC 0/2] exynos5250/hdmi: replace dummy hdmiphy
> clock with
> > pmu reg control
> >
> > Hi,
> >
> > On 06/13/2013 06:26 AM, Rahul Sharma wrote:
> >> Mr. Dae,
> >>
> >> Thanks for your valuable inputs.
> >>
> >> I posted it as RFC because, I also have received comments to
> register
> >> hdmiphy as a clock controller. As we always configure it for
> specific
> >> frequency, hdmi-phy looks similar to a PLL. But it really doesn't
> >> belong to that class. Secondly prior to exynos5420, it was a i2c
> >> device. I am not sure we can register a I2C device as a clock
> >> controller. I wanted to discuss and explore this option here.
> >
> > Have you considered using the generic PHY framework for those HDMI
> > PHY devices [1] ? I guess we could add a dedicated group of
> ops for
> > video PHYs, similarly as is is done with struct
> v4l2_subdev_ops. For
> > configuring things like the carrier/pixel clock frequency or
> anything
> > what's common across the video PHYs.
> >
> > Perhaps you could have a look and see if this framework would be
> > useful for HDMI and possibly point out anything what might be
> missing ?
> >
> > I'm not sure it it really solves the issues specific to the Exynos
> > HDMI but at least with a generic PHY driver the PHY module
> would be
> > separate from the PHY controller, as often same HDMI DPHY can
> be used
> > with various types of a HDMI controller. So this would allow
> to not
> > duplicate the HDMI PHY drivers in the long-term perspective.
> 
>  Yeah, at least, it seems that we could use PHY module to
> control PMU
>  register, HDMI_PHY_CONTROL. However, PHY module provides only
> init/on/off
>  callbacks. As you may know, HDMIPHY needs i2c interfaces to control
>  HDMIPHY
>  clock. So with PHY module, HDMIPHY driver could enable PMU more
>  generically,
>  but also has to use existing i2c stuff to control HDMIPHY
> clock. I had a
>  quick review to Generic PHY Framework[v6] but I didn't see that
> the PHY
>  module could generically support more features such as i2c stuff.
> >>>
> >>> I don't think PHY framework needs to provide i2c interfaces to
> program
> >>> certain configurations. Instead in one of the callbacks
> (init/on/off)
> >>> PHY driver can program whatever it wants using any of the
> interfaces it
> >>> needs. IMO PHY framework should work independent of the interfaces.
> >>
> >> In exnoys hdmi case, i2c interface is not the exact issue. In exynos
> >> hdmi, hdmiphy should send i2c configuration about video clock
> >> information as the video mode information including resolution,
> bit per
> >> pixel, refresh rate passed from drm subsystem. So init/on/off
> callbacks
> >> of phy framework are not enough for exynos hdmiphy and it should
> have a
> >> callback to set video mode.
> >>
> >> Do you have plan to add driver specific extend callback pointers
> to phy
> >> framework?
> >>
> >> Currently, hdmi directly calls phy operations, but Rahul's
> another patch
> >> set, mentioned by Inki, divides hdmi and hdmiphy and hdmi and
> hdmiphy is
> >> connected with exynos hdmi own sub driver callback operations.
> >>
> >> IMHO, if phy framework can support extend callback feature, then this
> >> own sub driver callbacks can be replaced with phy framework at
> long term
> >> view.
> 

Re: [PATCH 1/3] drm/nouveau: fix vblank interrupt being called before event is setup

[Maarten Lankhorst]

Op 30-07-13 04:42, Ben Skeggs schreef:
> On Tue, Jul 23, 2013 at 11:43 PM, Maarten Lankhorst
>  wrote:
>> Sort of fixes mmiotrace for me again, I could sear I sent a similar patch 
>> before
>> the rework to event interface, so I guess it got reintroduced.
> I don't know how/why you think this fixes anything.  The interrupt
> handler can't possibly be called until after priv->base.vblank has
> been initialised...
>
> Seriously, go look, the subdev interrupt handler pointer isn't filled
> in (and can't be) until after nouveau_disp_create() has been called,
> and nouveau_disp_create() initialises priv->base.vblank before it
> returns...
>
There's also a disp_dtor function right above it and without a smp_wmb
the writes could still be reordered in the constructor. O:-) A spinlock would
be needed to make sure that no interrupt is in process if you set intr to null
before destroying vblank event, though.

I can probably try to get the oops again indicating that priv->base.vblank was 
null in the interrupt handler if you want,
iirc it happened reliably during mmiotracing.

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

Re: [PATCH 1/3] drm/nouveau: fix vblank interrupt being called before event is setup

[Ben Skeggs]

On Tue, Jul 30, 2013 at 4:10 PM, Maarten Lankhorst
 wrote:
> Op 30-07-13 04:42, Ben Skeggs schreef:
>> On Tue, Jul 23, 2013 at 11:43 PM, Maarten Lankhorst
>>  wrote:
>>> Sort of fixes mmiotrace for me again, I could sear I sent a similar patch 
>>> before
>>> the rework to event interface, so I guess it got reintroduced.
>> I don't know how/why you think this fixes anything.  The interrupt
>> handler can't possibly be called until after priv->base.vblank has
>> been initialised...
>>
>> Seriously, go look, the subdev interrupt handler pointer isn't filled
>> in (and can't be) until after nouveau_disp_create() has been called,
>> and nouveau_disp_create() initialises priv->base.vblank before it
>> returns...
>>
> There's also a disp_dtor function right above it and without a smp_wmb
> the writes could still be reordered in the constructor. O:-) A spinlock would
> be needed to make sure that no interrupt is in process if you set intr to null
> before destroying vblank event, though.
>
> I can probably try to get the oops again indicating that priv->base.vblank 
> was null in the interrupt handler if you want,
> iirc it happened reliably during mmiotracing.
It would've had to have happened during a module unload in that case,
I can't see how else it could've possibly happened.

The destructor case is valid though, but not really a critical issue,
so I'd rather find a better solution than these hacked checks :)  I'll
add it to the list...

Ben.

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

Re: [PATCH 4/4] snd/hda: add runtime suspend/resume on optimus support

[Dave Airlie]

On Mon, Jul 29, 2013 at 10:46 PM, Takashi Iwai  wrote:
> At Mon, 29 Jul 2013 16:06:59 +1000,
> Dave Airlie wrote:
>>
>> Add support for HDMI audio device on VGA cards that powerdown
>> to D3cold using non-standard ACPI/PCI infrastructure (optimus).
>>
>> This does a couple of things to make it work:
>>
>> a) add a set of power ops for the hdmi domain, and enables them
>> via vga_switcheroo when we are a switcheroo controlled card. This
>> just replaces the runtime resume operation so that when the card
>> is in D3cold the userspace pci config space access via sysfs,
>> the vga switcheroon runtime resume gets called first and it calls
>> the GPU resume callback before calling the sound card runtime
>> resume.
>>
>> b) standard ACPI/PCI stacks won't put a device into D3cold without
>> an ACPI handle, but since the hdmi audio devices on gpus don't have
>> an ACPI handle, we need to manually force the device into D3cold
>> after suspend from the switcheroo path only.
>>
>> c) don't try and do runtime s/r when the GPU is off.
>>
>> d) call runtime suspend/resume during switcheroo suspend/resume
>> this is to make sure the runtime stack knows to try and resume
>> the hdmi audio device for pci config space access.
>>
>> Signed-off-by: Dave Airlie 
>> ---
>>  sound/pci/hda/hda_intel.c | 40 +---
>>  1 file changed, 37 insertions(+), 3 deletions(-)
>>
>> diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
>> index 8860dd5..4b4d05b 100644
>> --- a/sound/pci/hda/hda_intel.c
>> +++ b/sound/pci/hda/hda_intel.c
>> @@ -555,6 +555,9 @@ struct azx {
>>  #ifdef CONFIG_SND_HDA_DSP_LOADER
>>   struct azx_dev saved_azx_dev;
>>  #endif
>> +
>> + /* secondary power domain for hdmi audio under vga device */
>> + struct dev_pm_domain hdmi_pm_domain;
>>  };
>>
>>  #define CREATE_TRACE_POINTS
>> @@ -2898,7 +2901,7 @@ static int param_set_xint(const char *val, const 
>> struct kernel_param *kp)
>>  /*
>>   * power management
>>   */
>> -static int azx_suspend(struct device *dev)
>> +static int azx_do_suspend(struct device *dev, pci_power_t state)
>>  {
>>   struct pci_dev *pci = to_pci_dev(dev);
>>   struct snd_card *card = dev_get_drvdata(dev);
>> @@ -2920,16 +2923,30 @@ static int azx_suspend(struct device *dev)
>>   free_irq(chip->irq, chip);
>>   chip->irq = -1;
>>   }
>> +
>> + /*
>> +  * for vga switcheroo suspend we need to
>> +  * force runtime suspend so lspci works.
>> +  */
>> + if (state == PCI_D3cold)
>> + pm_runtime_suspend(&pci->dev);
>> +
>>   if (chip->msi)
>>   pci_disable_msi(chip->pci);
>>   pci_disable_device(pci);
>>   pci_save_state(pci);
>> - pci_set_power_state(pci, PCI_D3hot);
>> +
>> + pci_set_power_state(pci, state);
>>   if (chip->driver_caps & AZX_DCAPS_I915_POWERWELL)
>>   hda_display_power(false);
>>   return 0;
>>  }
>>
>> +static int azx_suspend(struct device *dev)
>> +{
>> + return azx_do_suspend(dev, PCI_D3hot);
>> +}
>> +
>>  static int azx_resume(struct device *dev)
>>  {
>>   struct pci_dev *pci = to_pci_dev(dev);
>> @@ -2971,6 +2988,9 @@ static int azx_runtime_suspend(struct device *dev)
>>   struct snd_card *card = dev_get_drvdata(dev);
>>   struct azx *chip = card->private_data;
>>
>> + if (chip->disabled)
>> + return 0;
>> +
>>   azx_stop_chip(chip);
>>   azx_enter_link_reset(chip);
>>   azx_clear_irq_pending(chip);
>> @@ -2984,6 +3004,9 @@ static int azx_runtime_resume(struct device *dev)
>>   struct snd_card *card = dev_get_drvdata(dev);
>>   struct azx *chip = card->private_data;
>>
>> + if (chip->disabled)
>> + return 0;
>> +
>>   if (chip->driver_caps & AZX_DCAPS_I915_POWERWELL)
>>   hda_display_power(true);
>>   azx_init_pci(chip);
>> @@ -2996,6 +3019,9 @@ static int azx_runtime_idle(struct device *dev)
>>   struct snd_card *card = dev_get_drvdata(dev);
>>   struct azx *chip = card->private_data;
>>
>> + if (chip->disabled)
>> + return 0;
>> +
>>   if (!power_save_controller ||
>>   !(chip->driver_caps & AZX_DCAPS_PM_RUNTIME))
>>   return -EBUSY;
>> @@ -3078,7 +3104,11 @@ static void azx_vs_set_state(struct pci_dev *pci,
>>  "%s: %s via VGA-switcheroo\n", pci_name(chip->pci),
>>  disabled ? "Disabling" : "Enabling");
>>   if (disabled) {
>> - azx_suspend(&pci->dev);
>> + azx_do_suspend(&pci->dev, PCI_D3cold);
>> + /* when we get suspended by vga switcheroo we end up 
>> in D3cold,
>> +  * however we have no ACPI handle, so pci/acpi can't 
>> put us there,
>> +  * put ourselves there */
>> + pci->current_state = PCI_D3cold;
>>   chip->disabled = true;
>>   if

linux-next: problem fetching the drm-intel-fixes tree

[Stephen Rothwell]

Hi all,

Trying to fetch the drm-intel-fixes tree
(git://people.freedesktop.org/~danvet/drm-intel#drm-intel-fixes) this
morning produced this error:

fatal: remote error: access denied or repository not exported: ~danvet/drm-intel
-- 
Cheers,
Stephen Rothwellsfr at canb.auug.org.au
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130729/7159b427/attachment.pgp>

linux-next: problem fetching the drm-intel-fixes tree

[Stephen Rothwell]

On Mon, 29 Jul 2013 10:08:43 +1000 Stephen Rothwell  
wrote:
>
> Hi all,
> 
> Trying to fetch the drm-intel-fixes tree
> (git://people.freedesktop.org/~danvet/drm-intel#drm-intel-fixes) this
> morning produced this error:
> 
> fatal: remote error: access denied or repository not exported: 
> ~danvet/drm-intel

The same is true for the drm and drm-intel trees
(git://people.freedesktop.org/~airlied/linux.git#drm-next and
git://people.freedesktop.org/~danvet/drm-intel#for-linux-next)

-- 
Cheers,
Stephen Rothwellsfr at canb.auug.org.au
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130729/026d726d/attachment.pgp>

linux-next: problem fetching the drm-intel-fixes tree

[Dave Airlie]

>
> Trying to fetch the drm-intel-fixes tree
> (git://people.freedesktop.org/~danvet/drm-intel#drm-intel-fixes) this
> morning produced this error:

There is some issue with personal fdo repos at the moment and anon git,

I'll ask admin to look into it.

Dave.

linux-next: problem fetching the drm-intel-fixes tree

[Stephen Rothwell]

Hi Dave,

On Mon, 29 Jul 2013 10:15:50 +1000 Dave Airlie  wrote:
>
> > Trying to fetch the drm-intel-fixes tree
> > (git://people.freedesktop.org/~danvet/drm-intel#drm-intel-fixes) this
> > morning produced this error:
> 
> There is some issue with personal fdo repos at the moment and anon git,
> 
> I'll ask admin to look into it.

Thanks.  In the mean time, I will use what I fetched on Friday.

-- 
Cheers,
Stephen Rothwellsfr at canb.auug.org.au
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130729/b210386c/attachment.pgp>

[Bug 67435] HDMI audio silent on Radeon Mobility HD4650

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=67435

--- Comment #3 from Rafa? Mi?ecki  ---
You can also compare output of
avivotool regs hdmi
when using 3.9 and 3.10. That should give some hint.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130729/926c5637/attachment.html>

[PATCH 3/4] nouveau: add runtime PM support (v0.7)

[Dave Airlie]

From: Dave Airlie 

This hooks nouveau up to the runtime PM system to enable
dynamic power management for secondary GPUs in switchable
and optimus laptops.

a) rewrite suspend/resume printks to hide them during dynamic s/r
to avoid cluttering logs
b) add runtime pm suspend to irq handler, crtc display, ioctl handler,
connector status,
c) handle hdmi audio dynamic power on/off using magic register.

v0.5:
make sure we hit D3 properly
fix fbdev_set_suspend locking interaction, we only will poweroff if we have no
active crtcs/fbcon anyways.
add reference for active crtcs.
sprinkle mark last busy for autosuspend timeout

v0.6:
allow more flexible debugging - to avoid log spam
add option to enable/disable dynpm
got to D3Cold

v0.7:
add hdmi audio support.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/nouveau/core/core/printk.c |  19 ++
 drivers/gpu/drm/nouveau/core/include/core/printk.h |  13 ++
 drivers/gpu/drm/nouveau/core/subdev/bios/init.c|   2 +-
 drivers/gpu/drm/nouveau/core/subdev/mc/base.c  |   5 +
 drivers/gpu/drm/nouveau/dispnv04/crtc.c|  49 +++-
 drivers/gpu/drm/nouveau/nouveau_acpi.c |  42 +++-
 drivers/gpu/drm/nouveau/nouveau_connector.c|  27 ++-
 drivers/gpu/drm/nouveau/nouveau_display.c  |  12 +-
 drivers/gpu/drm/nouveau/nouveau_display.h  |   2 +
 drivers/gpu/drm/nouveau/nouveau_drm.c  | 247 +++--
 drivers/gpu/drm/nouveau/nouveau_drm.h  |   9 +
 drivers/gpu/drm/nouveau/nouveau_vga.c  |  14 +-
 12 files changed, 399 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/core/core/printk.c 
b/drivers/gpu/drm/nouveau/core/core/printk.c
index 6161eaf..52fb2aa 100644
--- a/drivers/gpu/drm/nouveau/core/core/printk.c
+++ b/drivers/gpu/drm/nouveau/core/core/printk.c
@@ -27,6 +27,8 @@
 #include 
 #include 

+int nv_printk_suspend_level = NV_DBG_DEBUG;
+
 void
 nv_printk_(struct nouveau_object *object, const char *pfx, int level,
   const char *fmt, ...)
@@ -72,3 +74,20 @@ nv_printk_(struct nouveau_object *object, const char *pfx, 
int level,
vprintk(mfmt, args);
va_end(args);
 }
+
+#define CONV_LEVEL(x) case NV_DBG_##x: return NV_PRINTK_##x
+
+const char *nv_printk_level_to_pfx(int level)
+{
+   switch (level) {
+   CONV_LEVEL(FATAL);
+   CONV_LEVEL(ERROR);
+   CONV_LEVEL(WARN);
+   CONV_LEVEL(INFO);
+   CONV_LEVEL(DEBUG);
+   CONV_LEVEL(PARANOIA);
+   CONV_LEVEL(TRACE);
+   CONV_LEVEL(SPAM);
+   }
+   return NV_PRINTK_DEBUG;
+}
diff --git a/drivers/gpu/drm/nouveau/core/include/core/printk.h 
b/drivers/gpu/drm/nouveau/core/include/core/printk.h
index febed2e..d87836e 100644
--- a/drivers/gpu/drm/nouveau/core/include/core/printk.h
+++ b/drivers/gpu/drm/nouveau/core/include/core/printk.h
@@ -15,6 +15,12 @@ struct nouveau_object;
 #define NV_PRINTK_TRACEKERN_DEBUG
 #define NV_PRINTK_SPAM KERN_DEBUG

+extern int nv_printk_suspend_level;
+
+#define NV_DBG_SUSPEND (nv_printk_suspend_level)
+#define NV_PRINTK_SUSPEND  (nv_printk_level_to_pfx(nv_printk_suspend_level))
+
+const char *nv_printk_level_to_pfx(int level);
 void __printf(4, 5)
 nv_printk_(struct nouveau_object *, const char *, int, const char *, ...);

@@ -31,6 +37,13 @@ nv_printk_(struct nouveau_object *, const char *, int, const 
char *, ...);
 #define nv_trace(o,f,a...) nv_printk((o), TRACE, f, ##a)
 #define nv_spam(o,f,a...) nv_printk((o), SPAM, f, ##a)

+#define nv_suspend(o,f,a...) nv_printk((o), SUSPEND, f, ##a)
+
+static inline void nv_suspend_set_printk_level(int level)
+{
+   nv_printk_suspend_level = level;
+}
+
 #define nv_assert(f,a...) do { 
\
if (NV_DBG_FATAL <= CONFIG_NOUVEAU_DEBUG)  \
nv_printk_(NULL, NV_PRINTK_FATAL, NV_DBG_FATAL, f "\n", ##a);  \
diff --git a/drivers/gpu/drm/nouveau/core/subdev/bios/init.c 
b/drivers/gpu/drm/nouveau/core/subdev/bios/init.c
index 0687e64..2e11ea0 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/bios/init.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/bios/init.c
@@ -2165,7 +2165,7 @@ nvbios_init(struct nouveau_subdev *subdev, bool execute)
u16 data;

if (execute)
-   nv_info(bios, "running init tables\n");
+   nv_suspend(bios, "running init tables\n");
while (!ret && (data = (init_script(bios, ++i {
struct nvbios_init init = {
.subdev = subdev,
diff --git a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c 
b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
index 1c0330b..b6afd98 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
@@ -23,16 +23,20 @@
  */

 #include 
+#include 

 static irqreturn_t
 nouveau_mc_intr(int irq, void *arg)
 {
struct nouveau_mc *pmc = arg;
const struct nouveau_mc_intr *map = pmc->intr_map;
+   struct nouvea

[PATCH 1/4] gpu/vga_switcheroo: add driver control power feature. (v3)

[Dave Airlie]

From: Dave Airlie 

For optimus and powerxpress muxless we really want the GPU
driver deciding when to power up/down the GPU, not userspace.

This adds the ability for a driver to dynamically power up/down
the GPU and remove the switcheroo from controlling it, the
switcheroo reports the dynamic state to userspace also.

It also adds 2 power domains, one for machine where the power
switch is controlled outside the GPU D3 state, so the powerdown
ordering is done correctly, and the second for the hdmi audio
device to make sure it can resume for PCI config space accesses.

v1.1: fix build with switcheroo off

v2: add power domain support for radeon and v1 nvidia dsms
v2.1: fix typo in off case

v3: add audio power domain for hdmi audio + misc audio fixes

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/i915/i915_dma.c|   2 +-
 drivers/gpu/drm/nouveau/nouveau_vga.c  |   2 +-
 drivers/gpu/drm/radeon/radeon_device.c |   2 +-
 drivers/gpu/vga/vga_switcheroo.c   | 147 +++--
 include/linux/vga_switcheroo.h |  13 ++-
 5 files changed, 156 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index b152068..5f930a1 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1293,7 +1293,7 @@ static int i915_load_modeset_init(struct drm_device *dev)

intel_register_dsm_handler();

-   ret = vga_switcheroo_register_client(dev->pdev, &i915_switcheroo_ops);
+   ret = vga_switcheroo_register_client(dev->pdev, &i915_switcheroo_ops, 
false);
if (ret)
goto cleanup_vga_client;

diff --git a/drivers/gpu/drm/nouveau/nouveau_vga.c 
b/drivers/gpu/drm/nouveau/nouveau_vga.c
index 25d3495..40a09f1 100644
--- a/drivers/gpu/drm/nouveau/nouveau_vga.c
+++ b/drivers/gpu/drm/nouveau/nouveau_vga.c
@@ -79,7 +79,7 @@ nouveau_vga_init(struct nouveau_drm *drm)
 {
struct drm_device *dev = drm->dev;
vga_client_register(dev->pdev, dev, NULL, nouveau_vga_set_decode);
-   vga_switcheroo_register_client(dev->pdev, &nouveau_switcheroo_ops);
+   vga_switcheroo_register_client(dev->pdev, &nouveau_switcheroo_ops, 
false);
 }

 void
diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index 82335e3..0610ca4 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1269,7 +1269,7 @@ int radeon_device_init(struct radeon_device *rdev,
/* this will fail for cards that aren't VGA class devices, just
 * ignore it */
vga_client_register(rdev->pdev, rdev, NULL, radeon_vga_set_decode);
-   vga_switcheroo_register_client(rdev->pdev, &radeon_switcheroo_ops);
+   vga_switcheroo_register_client(rdev->pdev, &radeon_switcheroo_ops, 
false);

r = radeon_init(rdev);
if (r)
diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
index cf787e1..afb3956 100644
--- a/drivers/gpu/vga/vga_switcheroo.c
+++ b/drivers/gpu/vga/vga_switcheroo.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 

@@ -37,6 +38,7 @@ struct vga_switcheroo_client {
const struct vga_switcheroo_client_ops *ops;
int id;
bool active;
+   bool driver_power_control;
struct list_head list;
 };

@@ -132,7 +134,7 @@ EXPORT_SYMBOL(vga_switcheroo_unregister_handler);

 static int register_client(struct pci_dev *pdev,
   const struct vga_switcheroo_client_ops *ops,
-  int id, bool active)
+  int id, bool active, bool driver_power_control)
 {
struct vga_switcheroo_client *client;

@@ -145,6 +147,7 @@ static int register_client(struct pci_dev *pdev,
client->ops = ops;
client->id = id;
client->active = active;
+   client->driver_power_control = driver_power_control;

mutex_lock(&vgasr_mutex);
list_add_tail(&client->list, &vgasr_priv.clients);
@@ -160,10 +163,11 @@ static int register_client(struct pci_dev *pdev,
 }

 int vga_switcheroo_register_client(struct pci_dev *pdev,
-  const struct vga_switcheroo_client_ops *ops)
+  const struct vga_switcheroo_client_ops *ops,
+  bool driver_power_control)
 {
return register_client(pdev, ops, -1,
-  pdev == vga_default_device());
+  pdev == vga_default_device(), 
driver_power_control);
 }
 EXPORT_SYMBOL(vga_switcheroo_register_client);

@@ -171,7 +175,7 @@ int vga_switcheroo_register_audio_client(struct pci_dev 
*pdev,
 const struct vga_switcheroo_client_ops 
*ops,
 int id, bool active)
 {
-   return register_client(pdev, ops, id | ID_BIT_AUDIO, active);
+   return register_client(pdev, ops, id | ID_BIT_AUDIO

[PATCH 4/4] snd/hda: add runtime suspend/resume on optimus support

[Dave Airlie]

Add support for HDMI audio device on VGA cards that powerdown
to D3cold using non-standard ACPI/PCI infrastructure (optimus).

This does a couple of things to make it work:

a) add a set of power ops for the hdmi domain, and enables them
via vga_switcheroo when we are a switcheroo controlled card. This
just replaces the runtime resume operation so that when the card
is in D3cold the userspace pci config space access via sysfs,
the vga switcheroon runtime resume gets called first and it calls
the GPU resume callback before calling the sound card runtime
resume.

b) standard ACPI/PCI stacks won't put a device into D3cold without
an ACPI handle, but since the hdmi audio devices on gpus don't have
an ACPI handle, we need to manually force the device into D3cold
after suspend from the switcheroo path only.

c) don't try and do runtime s/r when the GPU is off.

d) call runtime suspend/resume during switcheroo suspend/resume
this is to make sure the runtime stack knows to try and resume
the hdmi audio device for pci config space access.

Signed-off-by: Dave Airlie 
---
 sound/pci/hda/hda_intel.c | 40 +---
 1 file changed, 37 insertions(+), 3 deletions(-)

diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 8860dd5..4b4d05b 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -555,6 +555,9 @@ struct azx {
 #ifdef CONFIG_SND_HDA_DSP_LOADER
struct azx_dev saved_azx_dev;
 #endif
+
+   /* secondary power domain for hdmi audio under vga device */
+   struct dev_pm_domain hdmi_pm_domain;
 };

 #define CREATE_TRACE_POINTS
@@ -2898,7 +2901,7 @@ static int param_set_xint(const char *val, const struct 
kernel_param *kp)
 /*
  * power management
  */
-static int azx_suspend(struct device *dev)
+static int azx_do_suspend(struct device *dev, pci_power_t state)
 {
struct pci_dev *pci = to_pci_dev(dev);
struct snd_card *card = dev_get_drvdata(dev);
@@ -2920,16 +2923,30 @@ static int azx_suspend(struct device *dev)
free_irq(chip->irq, chip);
chip->irq = -1;
}
+
+   /*
+* for vga switcheroo suspend we need to
+* force runtime suspend so lspci works.
+*/
+   if (state == PCI_D3cold)
+   pm_runtime_suspend(&pci->dev);
+
if (chip->msi)
pci_disable_msi(chip->pci);
pci_disable_device(pci);
pci_save_state(pci);
-   pci_set_power_state(pci, PCI_D3hot);
+
+   pci_set_power_state(pci, state);
if (chip->driver_caps & AZX_DCAPS_I915_POWERWELL)
hda_display_power(false);
return 0;
 }

+static int azx_suspend(struct device *dev)
+{
+   return azx_do_suspend(dev, PCI_D3hot);
+}
+
 static int azx_resume(struct device *dev)
 {
struct pci_dev *pci = to_pci_dev(dev);
@@ -2971,6 +2988,9 @@ static int azx_runtime_suspend(struct device *dev)
struct snd_card *card = dev_get_drvdata(dev);
struct azx *chip = card->private_data;

+   if (chip->disabled)
+   return 0;
+
azx_stop_chip(chip);
azx_enter_link_reset(chip);
azx_clear_irq_pending(chip);
@@ -2984,6 +3004,9 @@ static int azx_runtime_resume(struct device *dev)
struct snd_card *card = dev_get_drvdata(dev);
struct azx *chip = card->private_data;

+   if (chip->disabled)
+   return 0;
+
if (chip->driver_caps & AZX_DCAPS_I915_POWERWELL)
hda_display_power(true);
azx_init_pci(chip);
@@ -2996,6 +3019,9 @@ static int azx_runtime_idle(struct device *dev)
struct snd_card *card = dev_get_drvdata(dev);
struct azx *chip = card->private_data;

+   if (chip->disabled)
+   return 0;
+
if (!power_save_controller ||
!(chip->driver_caps & AZX_DCAPS_PM_RUNTIME))
return -EBUSY;
@@ -3078,7 +3104,11 @@ static void azx_vs_set_state(struct pci_dev *pci,
   "%s: %s via VGA-switcheroo\n", pci_name(chip->pci),
   disabled ? "Disabling" : "Enabling");
if (disabled) {
-   azx_suspend(&pci->dev);
+   azx_do_suspend(&pci->dev, PCI_D3cold);
+   /* when we get suspended by vga switcheroo we end up in 
D3cold,
+* however we have no ACPI handle, so pci/acpi can't 
put us there,
+* put ourselves there */
+   pci->current_state = PCI_D3cold;
chip->disabled = true;
if (snd_hda_lock_devices(chip->bus))
snd_printk(KERN_WARNING SFX "%s: Cannot lock 
devices!\n",
@@ -3087,6 +3117,7 @@ static void azx_vs_set_state(struct pci_dev *pci,
snd_hda_unlock_devices(chip->bus);
chip->disabled = false;
azx_resume(&pci->dev);
+   pm

nouveau optimus dynamic power off

[Dave Airlie]

I finally got back to debugging the HDMI audio interactions that
stopped me last time,

This adds switcheroo + nouveau + hda_intel support for turning
off the secondary GPU in optimus laptops, saving a lot of power.

The GPU should come back on for things like lspci on the devices
or for DRI_PRIME= or X starting up.

Signed-off-by: Dave Airlie 

[PATCH 2/4] drm: allow open of dynamic off devices.

[Dave Airlie]

From: Dave Airlie 

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/drm_fops.c | 2 +-
 include/drm/drmP.h | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 3a24385..d5429ee 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -257,7 +257,7 @@ static int drm_open_helper(struct inode *inode, struct file 
*filp,
return -EBUSY;  /* No exclusive opens */
if (!drm_cpu_valid())
return -EINVAL;
-   if (dev->switch_power_state != DRM_SWITCH_POWER_ON)
+   if (dev->switch_power_state != DRM_SWITCH_POWER_ON && 
dev->switch_power_state != DRM_SWITCH_POWER_DYNAMIC_OFF)
return -EINVAL;

DRM_DEBUG("pid = %d, minor = %d\n", task_pid_nr(current), minor_id);
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 12083dc..7f8acaf 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1223,6 +1223,7 @@ struct drm_device {
 #define DRM_SWITCH_POWER_ON 0
 #define DRM_SWITCH_POWER_OFF 1
 #define DRM_SWITCH_POWER_CHANGING 2
+#define DRM_SWITCH_POWER_DYNAMIC_OFF 3

 static __inline__ int drm_core_check_feature(struct drm_device *dev,
 int feature)
-- 
1.8.2.1

linux-next: problem fetching the drm-intel-fixes tree

[Dave Airlie]

On Mon, Jul 29, 2013 at 10:26 AM, Stephen Rothwell  
wrote:
> Hi Dave,
>
> On Mon, 29 Jul 2013 10:15:50 +1000 Dave Airlie  wrote:
>>
>> > Trying to fetch the drm-intel-fixes tree
>> > (git://people.freedesktop.org/~danvet/drm-intel#drm-intel-fixes) this
>> > morning produced this error:
>>
>> There is some issue with personal fdo repos at the moment and anon git,
>>
>> I'll ask admin to look into it.
>
> Thanks.  In the mean time, I will use what I fetched on Friday.

Okay should all be back in place now.

Dave.

linux-next: problem fetching the drm-intel-fixes tree

[Stephen Rothwell]

Hi Dave,

On Mon, 29 Jul 2013 16:29:04 +1000 Dave Airlie  wrote:
>
> Okay should all be back in place now.

Excellent, thanks.

-- 
Cheers,
Stephen Rothwellsfr at canb.auug.org.au
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130729/3702faca/attachment-0001.pgp>

Commit f5d9b7f0f9 (fix r600_enable_sclk_control()) causes kexec issues

[Markus Trippelsdorf]

On my test machine Xorg doesn't start anymore when I kexec into a
3.11.0-rc3 kernel.
On cold boot everything is fine:

[drm] Initialized drm 1.1.0 20060810
[drm] radeon kernel modesetting enabled.
[drm] initializing kernel modesetting (RS780 0x1002:0x9614 0x1043:0x834D).
[drm] register mmio base: 0xFBEE
[drm] register mmio size: 65536
ATOM BIOS: 113
radeon :01:05.0: VRAM: 128M 0xC000 - 0xC7FF (128M 
used)
radeon :01:05.0: GTT: 512M 0xA000 - 0xBFFF
[drm] Detected VRAM RAM=128M, BAR=128M
[drm] RAM width 32bits DDR
[TTM] Zone  kernel: Available graphics memory: 4082356 kiB
[TTM] Zone   dma32: Available graphics memory: 2097152 kiB
[TTM] Initializing pool allocator
[TTM] Initializing DMA pool allocator
[drm] radeon: 128M of VRAM memory ready
[drm] radeon: 512M of GTT memory ready.
[drm] GART: num cpu pages 131072, num gpu pages 131072
[drm] Loading RS780 Microcode
[drm] PCIE GART of 512M enabled (table at 0xC004).
radeon :01:05.0: WB enabled
radeon :01:05.0: fence driver on ring 0 use gpu addr 0xac00 and 
cpu addr 0x880215c45c00
radeon :01:05.0: fence driver on ring 3 use gpu addr 0xac0c and 
cpu addr 0x880215c45c0c
[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] Driver supports precise vblank timestamp query.
[drm] radeon: irq initialized.
radeon :01:05.0: setting latency timer to 64
[drm] ring test on 0 succeeded in 0 usecs
[drm] ring test on 3 succeeded in 1 usecs
[drm] ib test on ring 0 succeeded in 0 usecs
[drm] ib test on ring 3 succeeded in 0 usecs
[drm] Radeon Display Connectors
[drm] Connector 0:
[drm]   VGA-1
[drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
[drm]   Encoders:
[drm] CRT1: INTERNAL_KLDSCP_DAC1
[drm] Connector 1:
[drm]   DVI-D-1
[drm]   HPD3
[drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
[drm]   Encoders:
[drm] DFP3: INTERNAL_KLDSCP_LVTMA
== power state 0 ==
ui class: none
internal class: boot 
caps: video 
uvdvclk: 0 dclk: 0
power level 0sclk: 5 vddc_index: 2
power level 1sclk: 5 vddc_index: 2
status: c r b 
== power state 1 ==
ui class: performance
internal class: none
caps: video 
uvdvclk: 0 dclk: 0
power level 0sclk: 5 vddc_index: 1
power level 1sclk: 7 vddc_index: 2
status: 
== power state 2 ==
ui class: none
internal class: uvd 
caps: video 
uvdvclk: 53300 dclk: 4
power level 0sclk: 5 vddc_index: 1
power level 1sclk: 5 vddc_index: 1
status: 
switching from power state:
ui class: none
internal class: boot 
caps: video 
uvdvclk: 0 dclk: 0
power level 0sclk: 5 vddc_index: 2
power level 1sclk: 5 vddc_index: 2
status: c b 
switching to power state:
ui class: performance
internal class: none
caps: video 
uvdvclk: 0 dclk: 0
power level 0sclk: 5 vddc_index: 1
power level 1sclk: 7 vddc_index: 2
status: r 
[drm] radeon: dpm initialized
[drm] fb mappable at 0xF0142000
[drm] vram apper at 0xF000
[drm] size 7299072
[drm] fb depth is 24
[drm]pitch is 6912

But after I run kexec things go wrong:

[drm] Initialized drm 1.1.0 20060810
[drm] radeon kernel modesetting enabled.
[drm] initializing kernel modesetting (RS780 0x1002:0x9614 0x1043:0x834D).
[drm] register mmio base: 0xFBEE
[drm] register mmio size: 65536
ATOM BIOS: 113
radeon :01:05.0: VRAM: 128M 0xC000 - 0xC7FF (128M 
used)
radeon :01:05.0: GTT: 512M 0xA000 - 0xBFFF
[drm] Detected VRAM RAM=128M, BAR=128M
[drm] RAM width 32bits DDR
[TTM] Zone  kernel: Available graphics memory: 4082356 kiB
[TTM] Zone   dma32: Available graphics memory: 2097152 kiB
[TTM] Initializing pool allocator
[TTM] Initializing DMA pool allocator
[drm] radeon: 128M of VRAM memory ready
[drm] radeon: 512M of GTT memory ready.
[drm] GART: num cpu pages 131072, num gpu pages 131072
[drm] Loading RS780 Microcode
[drm] PCIE GART of 512M enabled (table at 0xC004).
radeon :01:05.0: WB enabled
radeon :01:05.0: fence driver on ring 0 use gpu addr 0xac00 and 
cpu addr 0x880215c45c00
radeon :01:05.0: fence driver on ring 3 use gpu addr 0xac0c and 
cpu addr 0x880215c45c0c
[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] Driver supports precise vblank timestamp query.
[drm] radeon: irq initialized.
radeon :01:05.0: setting latency timer to 64
[drm] ring test on 0 succeeded in 0 usecs
[drm:r600_dma_ring_test] *ERROR* radeon: ring 3 test failed (0xCAFEDEAD)
radeon :01:05.0: disabling GPU accelerati

[PATCH] drm/nouveau: protect vm refcount with mutex

[Maarten Lankhorst]

The refcount was not protected by the vm lock, fix this..

[ cut here ]
WARNING: CPU: 2 PID: 2008 at drivers/gpu/drm/nouveau/core/core/mm.c:242 
nouveau_mm_fini+0x4f/0x56 [nouveau]()
Modules linked in: adt7475 ebtable_nat ebtables nouveau ipt_MASQUERADE 
iptable_nat nf_nat_ipv4 nf_nat xt_CHECKSUM iptable_mangle bridge stp llc 
snd_hda_codec_hdmi kvm_intel ttm kvm drm_kms_helper drm mxm_wmi 
snd_hda_codec_realtek snd_hda_intel e1000e snd_hda_codec snd_hwdep snd_pcm ptp 
pps_core snd_page_alloc video parport_pc ppdev nfsd parport lockd nfs_acl 
auth_rpcgss sunrpc oid_registry
CPU: 2 PID: 2008 Comm: Xorg Tainted: GW3.11.0-rc1-patser+ #119
Hardware name: Acer Aspire M3985/Aspire M3985, BIOS P01-A1 03/12/2012
 00f2 8803f59b1b68 81637988 b0b0
  8803f59b1ba8 81059e1d 
  8803f9dd6c48 8803f9dd6c00 8803f688d898
Call Trace:
 [] dump_stack+0x55/0x86
 [] warn_slowpath_common+0x87/0xaf
 [] warn_slowpath_null+0x15/0x17
 [] nouveau_mm_fini+0x4f/0x56 [nouveau]
 [] nouveau_vm_ref+0x154/0x180 [nouveau]
 [] ? nouveau_mm_free+0x85/0x116 [nouveau]
 [] nouveau_vm_put+0x9a/0xb0 [nouveau]
 [] ? nouveau_gem_info+0x9d/0x9d [nouveau]
 [] nouveau_gem_object_delete+0x19/0x28 [nouveau]
 [] nouveau_fence_work+0xc9/0x102 [nouveau]
 [] nouveau_gem_object_close+0x103/0x182 [nouveau]
 [] drm_gem_handle_delete+0xcc/0x153 [drm]
 [] drm_gem_close_ioctl+0x23/0x25 [drm]
 [] drm_ioctl+0x4cc/0x612 [drm]
 [] ? __slab_free.isra.66+0x24d/0x2aa
 [] ? drm_gem_destroy+0x4c/0x4c [drm]
 [] ? avc_has_perm_flags+0xb1/0x179
 [] do_vfs_ioctl+0x8b/0x4f8
 [] ? inode_has_perm.isra.43.constprop.75+0x25/0x2b
 [] ? file_has_perm+0x8c/0x9a
 [] ? rcu_user_exit+0xe/0x10
 [] SyS_ioctl+0x8a/0x9b
 [] tracesys+0xdd/0xe2
---[ end trace f99ff0179509b495 ]---

Signed-off-by: Maarten Lankhorst 
---

diff --git a/drivers/gpu/drm/nouveau/core/subdev/vm/base.c 
b/drivers/gpu/drm/nouveau/core/subdev/vm/base.c
index 3b90b42..afc5106 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/vm/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/vm/base.c
@@ -28,6 +28,8 @@
 #include 
 #include 

+static void nouveau_vm_del(struct nouveau_vm *vm);
+
 void
 nouveau_vm_map_at(struct nouveau_vma *vma, u64 delta, struct nouveau_mem *node)
 {
@@ -335,10 +337,10 @@ nouveau_vm_get(struct nouveau_vm *vm, u64 size, u32 
page_shift,
return ret;
}
}
+   ++vm->refcount;
+   vma->vm = vm;
mutex_unlock(&nv_subdev(vmm)->mutex);

-   vma->vm = NULL;
-   nouveau_vm_ref(vm, &vma->vm, NULL);
vma->offset = (u64)vma->node->offset << 12;
 #ifdef NOUVEAU_VM_POISON
if (vm->poison)
@@ -353,7 +355,7 @@ nouveau_vm_put(struct nouveau_vma *vma)
 {
struct nouveau_vm *vm = vma->vm;
struct nouveau_vmmgr *vmm = vm->vmm;
-   u32 fpde, lpde;
+   u32 fpde, lpde, ref;

if (unlikely(vma->node == NULL))
return;
@@ -363,9 +365,12 @@ nouveau_vm_put(struct nouveau_vma *vma)
mutex_lock(&nv_subdev(vmm)->mutex);
nouveau_vm_unmap_pgt(vm, vma->node->type != vmm->spg_shift, fpde, lpde);
nouveau_mm_free(&vm->mm, &vma->node);
-   mutex_unlock(&nv_subdev(vmm)->mutex);

-   nouveau_vm_ref(NULL, &vma->vm, NULL);
+   vma->vm = NULL;
+   ref = --vm->refcount;
+   mutex_unlock(&nv_subdev(vmm)->mutex);
+   if (!ref)
+   nouveau_vm_del(vm);
 }

 int
@@ -429,25 +434,21 @@ nouveau_vm_link(struct nouveau_vm *vm, struct 
nouveau_gpuobj *pgd)

nouveau_gpuobj_ref(pgd, &vpgd->obj);

-   mutex_lock(&nv_subdev(vmm)->mutex);
for (i = vm->fpde; i <= vm->lpde; i++)
vmm->map_pgt(pgd, i, vm->pgt[i - vm->fpde].obj);
list_add(&vpgd->head, &vm->pgd_list);
-   mutex_unlock(&nv_subdev(vmm)->mutex);
return 0;
 }

 static void
 nouveau_vm_unlink(struct nouveau_vm *vm, struct nouveau_gpuobj *mpgd)
 {
-   struct nouveau_vmmgr *vmm = vm->vmm;
struct nouveau_vm_pgd *vpgd, *tmp;
struct nouveau_gpuobj *pgd = NULL;

if (!mpgd)
return;

-   mutex_lock(&nv_subdev(vmm)->mutex);
list_for_each_entry_safe(vpgd, tmp, &vm->pgd_list, head) {
if (vpgd->obj == mpgd) {
pgd = vpgd->obj;
@@ -456,7 +457,6 @@ nouveau_vm_unlink(struct nouveau_vm *vm, struct 
nouveau_gpuobj *mpgd)
break;
}
}
-   mutex_unlock(&nv_subdev(vmm)->mutex);

nouveau_gpuobj_ref(NULL, &pgd);
 }
@@ -489,20 +489,31 @@ nouveau_vm_ref(struct nouveau_vm *ref, struct nouveau_vm 
**ptr,

vm = ref;
if (vm) {
+   struct nouveau_vmmgr *vmm = vm->vmm;
+
+   mutex_lock(&nv_subdev(vmm)->mutex);
ret = nouveau_vm_link(vm, pgd);
-   if (ret)
+   if (ret) {
+   mutex_unlock(&nv_subdev(vmm)->mutex);
   

[PATCH 4/4] snd/hda: add runtime suspend/resume on optimus support

[Takashi Iwai]

At Mon, 29 Jul 2013 16:06:59 +1000,
Dave Airlie wrote:
> 
> Add support for HDMI audio device on VGA cards that powerdown
> to D3cold using non-standard ACPI/PCI infrastructure (optimus).
> 
> This does a couple of things to make it work:
> 
> a) add a set of power ops for the hdmi domain, and enables them
> via vga_switcheroo when we are a switcheroo controlled card. This
> just replaces the runtime resume operation so that when the card
> is in D3cold the userspace pci config space access via sysfs,
> the vga switcheroon runtime resume gets called first and it calls
> the GPU resume callback before calling the sound card runtime
> resume.
> 
> b) standard ACPI/PCI stacks won't put a device into D3cold without
> an ACPI handle, but since the hdmi audio devices on gpus don't have
> an ACPI handle, we need to manually force the device into D3cold
> after suspend from the switcheroo path only.
> 
> c) don't try and do runtime s/r when the GPU is off.
> 
> d) call runtime suspend/resume during switcheroo suspend/resume
> this is to make sure the runtime stack knows to try and resume
> the hdmi audio device for pci config space access.
> 
> Signed-off-by: Dave Airlie 
> ---
>  sound/pci/hda/hda_intel.c | 40 +---
>  1 file changed, 37 insertions(+), 3 deletions(-)
> 
> diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
> index 8860dd5..4b4d05b 100644
> --- a/sound/pci/hda/hda_intel.c
> +++ b/sound/pci/hda/hda_intel.c
> @@ -555,6 +555,9 @@ struct azx {
>  #ifdef CONFIG_SND_HDA_DSP_LOADER
>   struct azx_dev saved_azx_dev;
>  #endif
> +
> + /* secondary power domain for hdmi audio under vga device */
> + struct dev_pm_domain hdmi_pm_domain;
>  };
>  
>  #define CREATE_TRACE_POINTS
> @@ -2898,7 +2901,7 @@ static int param_set_xint(const char *val, const struct 
> kernel_param *kp)
>  /*
>   * power management
>   */
> -static int azx_suspend(struct device *dev)
> +static int azx_do_suspend(struct device *dev, pci_power_t state)
>  {
>   struct pci_dev *pci = to_pci_dev(dev);
>   struct snd_card *card = dev_get_drvdata(dev);
> @@ -2920,16 +2923,30 @@ static int azx_suspend(struct device *dev)
>   free_irq(chip->irq, chip);
>   chip->irq = -1;
>   }
> +
> + /*
> +  * for vga switcheroo suspend we need to
> +  * force runtime suspend so lspci works.
> +  */
> + if (state == PCI_D3cold)
> + pm_runtime_suspend(&pci->dev);
> +
>   if (chip->msi)
>   pci_disable_msi(chip->pci);
>   pci_disable_device(pci);
>   pci_save_state(pci);
> - pci_set_power_state(pci, PCI_D3hot);
> +
> + pci_set_power_state(pci, state);
>   if (chip->driver_caps & AZX_DCAPS_I915_POWERWELL)
>   hda_display_power(false);
>   return 0;
>  }
>  
> +static int azx_suspend(struct device *dev)
> +{
> + return azx_do_suspend(dev, PCI_D3hot);
> +}
> +
>  static int azx_resume(struct device *dev)
>  {
>   struct pci_dev *pci = to_pci_dev(dev);
> @@ -2971,6 +2988,9 @@ static int azx_runtime_suspend(struct device *dev)
>   struct snd_card *card = dev_get_drvdata(dev);
>   struct azx *chip = card->private_data;
>  
> + if (chip->disabled)
> + return 0;
> +
>   azx_stop_chip(chip);
>   azx_enter_link_reset(chip);
>   azx_clear_irq_pending(chip);
> @@ -2984,6 +3004,9 @@ static int azx_runtime_resume(struct device *dev)
>   struct snd_card *card = dev_get_drvdata(dev);
>   struct azx *chip = card->private_data;
>  
> + if (chip->disabled)
> + return 0;
> +
>   if (chip->driver_caps & AZX_DCAPS_I915_POWERWELL)
>   hda_display_power(true);
>   azx_init_pci(chip);
> @@ -2996,6 +3019,9 @@ static int azx_runtime_idle(struct device *dev)
>   struct snd_card *card = dev_get_drvdata(dev);
>   struct azx *chip = card->private_data;
>  
> + if (chip->disabled)
> + return 0;
> +
>   if (!power_save_controller ||
>   !(chip->driver_caps & AZX_DCAPS_PM_RUNTIME))
>   return -EBUSY;
> @@ -3078,7 +3104,11 @@ static void azx_vs_set_state(struct pci_dev *pci,
>  "%s: %s via VGA-switcheroo\n", pci_name(chip->pci),
>  disabled ? "Disabling" : "Enabling");
>   if (disabled) {
> - azx_suspend(&pci->dev);
> + azx_do_suspend(&pci->dev, PCI_D3cold);
> + /* when we get suspended by vga switcheroo we end up in 
> D3cold,
> +  * however we have no ACPI handle, so pci/acpi can't 
> put us there,
> +  * put ourselves there */
> + pci->current_state = PCI_D3cold;
>   chip->disabled = true;
>   if (snd_hda_lock_devices(chip->bus))
>   snd_printk(KERN_WARNING SFX "%s: Cannot lock 
> devices!\n",
> @@ -3087,6 +3117,7 @@ static void azx_vs_

Commit f5d9b7f0f9 (fix r600_enable_sclk_control()) causes kexec issues

[Alex Deucher]

On Mon, Jul 29, 2013 at 3:51 AM, Markus Trippelsdorf
 wrote:
> On my test machine Xorg doesn't start anymore when I kexec into a
> 3.11.0-rc3 kernel.

With kexec, dpm doesn't get torn down properly which can result in a
bad hardware state when the driver loads again.  Does the attached
patch help?  It attempts to disable dpm at startup in case it wasn't
torn down properly previously.

Alex
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-dpm-disable-dpm-before-enabling-it-to-dea.patch
Type: text/x-diff
Size: 1188 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130729/06e052cb/attachment.patch>

[RFC PATCH] fence: dma-buf cross-device synchronization (v12)

[Maarten Lankhorst]

A fence can be attached to a buffer which is being filled or consumed
by hw, to allow userspace to pass the buffer without waiting to another
device.  For example, userspace can call page_flip ioctl to display the
next frame of graphics after kicking the GPU but while the GPU is still
rendering.  The display device sharing the buffer with the GPU would
attach a callback to get notified when the GPU's rendering-complete IRQ
fires, to update the scan-out address of the display, without having to
wake up userspace.

A driver must allocate a fence context for each execution ring that can
run in parallel. The function for this takes an argument with how many
contexts to allocate:
  + fence_context_alloc()

A fence is transient, one-shot deal.  It is allocated and attached
to one or more dma-buf's.  When the one that attached it is done, with
the pending operation, it can signal the fence:
  + fence_signal()

To have a rough approximation whether a fence is fired, call:
  + fence_is_signaled()

The dma-buf-mgr handles tracking, and waiting on, the fences associated
with a dma-buf.

The one pending on the fence can add an async callback:
  + fence_add_callback()

The callback can optionally be cancelled with:
  + fence_remove_callback()

To wait synchronously, optionally with a timeout:
  + fence_wait()
  + fence_wait_timeout()

A default software-only implementation is provided, which can be used
by drivers attaching a fence to a buffer when they have no other means
for hw sync.  But a memory backed fence is also envisioned, because it
is common that GPU's can write to, or poll on some memory location for
synchronization.  For example:

  fence = custom_get_fence(...);
  if ((seqno_fence = to_seqno_fence(fence)) != NULL) {
dma_buf *fence_buf = fence->sync_buf;
get_dma_buf(fence_buf);

... tell the hw the memory location to wait ...
custom_wait_on(fence_buf, fence->seqno_ofs, fence->seqno);
  } else {
/* fall-back to sw sync * /
fence_add_callback(fence, my_cb);
  }

On SoC platforms, if some other hw mechanism is provided for synchronizing
between IP blocks, it could be supported as an alternate implementation
with it's own fence ops in a similar way.

enable_signaling callback is used to provide sw signaling in case a cpu
waiter is requested or no compatible hardware signaling could be used.

The intention is to provide a userspace interface (presumably via eventfd)
later, to be used in conjunction with dma-buf's mmap support for sw access
to buffers (or for userspace apps that would prefer to do their own
synchronization).

v1: Original
v2: After discussion w/ danvet and mlankhorst on #dri-devel, we decided
that dma-fence didn't need to care about the sw->hw signaling path
(it can be handled same as sw->sw case), and therefore the fence->ops
can be simplified and more handled in the core.  So remove the signal,
add_callback, cancel_callback, and wait ops, and replace with a simple
enable_signaling() op which can be used to inform a fence supporting
hw->hw signaling that one or more devices which do not support hw
signaling are waiting (and therefore it should enable an irq or do
whatever is necessary in order that the CPU is notified when the
fence is passed).
v3: Fix locking fail in attach_fence() and get_fence()
v4: Remove tie-in w/ dma-buf..  after discussion w/ danvet and mlankorst
we decided that we need to be able to attach one fence to N dma-buf's,
so using the list_head in dma-fence struct would be problematic.
v5: [ Maarten Lankhorst ] Updated for dma-bikeshed-fence and dma-buf-manager.
v6: [ Maarten Lankhorst ] I removed dma_fence_cancel_callback and some comments
about checking if fence fired or not. This is broken by design.
waitqueue_active during destruction is now fatal, since the signaller
should be holding a reference in enable_signalling until it signalled
the fence. Pass the original dma_fence_cb along, and call __remove_wait
in the dma_fence_callback handler, so that no cleanup needs to be
performed.
v7: [ Maarten Lankhorst ] Set cb->func and only enable sw signaling if
fence wasn't signaled yet, for example for hardware fences that may
choose to signal blindly.
v8: [ Maarten Lankhorst ] Tons of tiny fixes, moved __dma_fence_init to
header and fixed include mess. dma-fence.h now includes dma-buf.h
All members are now initialized, so kmalloc can be used for
allocating a dma-fence. More documentation added.
v9: Change compiler bitfields to flags, change return type of
enable_signaling to bool. Rework dma_fence_wait. Added
dma_fence_is_signaled and dma_fence_wait_timeout.
s/dma// and change exports to non GPL. Added fence_is_signaled and
fence_enable_sw_signaling calls, add ability to override default
wait operation.
v10: remove event_queue, use a custom list, export try_to_wake_up from
scheduler. Remove fence lock and use a global spinlock instead,
this s

Commit f5d9b7f0f9 (fix r600_enable_sclk_control()) causes kexec issues

[Markus Trippelsdorf]

On 2013.07.29 at 09:58 -0400, Alex Deucher wrote:
> On Mon, Jul 29, 2013 at 3:51 AM, Markus Trippelsdorf
>  wrote:
> > On my test machine Xorg doesn't start anymore when I kexec into a
> > 3.11.0-rc3 kernel.
> 
> With kexec, dpm doesn't get torn down properly which can result in a
> bad hardware state when the driver loads again.  Does the attached
> patch help?  It attempts to disable dpm at startup in case it wasn't
> torn down properly previously.

dpm initialization now works, but unfortunately GPU acceleration still gets
disabled:

[drm] Initialized drm 1.1.0 20060810

[135/1104]
[drm] radeon kernel modesetting enabled.
[drm] initializing kernel modesetting (RS780 0x1002:0x9614 0x1043:0x834D).
[drm] register mmio base: 0xFBEE
[drm] register mmio size: 65536
ATOM BIOS: 113
radeon :01:05.0: VRAM: 128M 0xC000 - 0xC7FF (128M 
used)
radeon :01:05.0: GTT: 512M 0xA000 - 0xBFFF
[drm] Detected VRAM RAM=128M, BAR=128M
[drm] RAM width 32bits DDR
[TTM] Zone  kernel: Available graphics memory: 4082356 kiB
[TTM] Zone   dma32: Available graphics memory: 2097152 kiB
[TTM] Initializing pool allocator
[TTM] Initializing DMA pool allocator
[drm] radeon: 128M of VRAM memory ready
[drm] radeon: 512M of GTT memory ready.
[drm] GART: num cpu pages 131072, num gpu pages 131072
[drm] Loading RS780 Microcode
[drm] PCIE GART of 512M enabled (table at 0xC004).
radeon :01:05.0: WB enabled
radeon :01:05.0: fence driver on ring 0 use gpu addr 0xac00 and 
cpu addr 0x880215c30c00
radeon :01:05.0: fence driver on ring 3 use gpu addr 0xac0c and 
cpu addr 0x880215c30c0c
[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] Driver supports precise vblank timestamp query.
[drm] radeon: irq initialized.
radeon :01:05.0: setting latency timer to 64
[drm] ring test on 0 succeeded in 1 usecs
[drm:r600_dma_ring_test] *ERROR* radeon: ring 3 test failed (0xCAFEDEAD)
radeon :01:05.0: disabling GPU acceleration
radeon :01:05.0: 8802161cfc00 unpin not necessary
[drm] Radeon Display Connectors
[drm] Connector 0:
[drm]   VGA-1
[drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
[drm]   Encoders:
[drm] CRT1: INTERNAL_KLDSCP_DAC1
[drm] Connector 1:
[drm]   DVI-D-1
[drm]   HPD3
[drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
[drm]   Encoders:
[drm] DFP3: INTERNAL_KLDSCP_LVTMA
== power state 0 ==
ui class: none
internal class: boot 
caps: video 
uvdvclk: 0 dclk: 0
power level 0sclk: 5 vddc_index: 2
power level 1sclk: 5 vddc_index: 2
status: c r b 
== power state 1 ==
ui class: performance
internal class: none
caps: video 
uvdvclk: 0 dclk: 0
power level 0sclk: 5 vddc_index: 1
power level 1sclk: 7 vddc_index: 2
status: 
== power state 2 ==
ui class: none
internal class: uvd 
caps: video 
uvdvclk: 53300 dclk: 4
power level 0sclk: 5 vddc_index: 1
power level 1sclk: 5 vddc_index: 1
status: 
switching from power state:
ui class: none
internal class: boot 
caps: video 
uvdvclk: 0 dclk: 0
power level 0sclk: 5 vddc_index: 2
power level 1sclk: 5 vddc_index: 2
status: c b 
switching to power state:
ui class: performance
internal class: none
caps: video 
uvdvclk: 0 dclk: 0
power level 0sclk: 5 vddc_index: 1
power level 1sclk: 7 vddc_index: 2
status: r 
[drm] radeon: dpm initialized
[drm] fb mappable at 0xF0142000
[drm] vram apper at 0xF000
[drm] size 7299072
[drm] fb depth is 24
[drm]pitch is 6912
fbcon: radeondrmfb (fb0)

-- 
Markus

Commit f5d9b7f0f9 (fix r600_enable_sclk_control()) causes kexec issues

[Alex Deucher]

On Mon, Jul 29, 2013 at 10:09 AM, Markus Trippelsdorf
 wrote:
> On 2013.07.29 at 09:58 -0400, Alex Deucher wrote:
>> On Mon, Jul 29, 2013 at 3:51 AM, Markus Trippelsdorf
>>  wrote:
>> > On my test machine Xorg doesn't start anymore when I kexec into a
>> > 3.11.0-rc3 kernel.
>>
>> With kexec, dpm doesn't get torn down properly which can result in a
>> bad hardware state when the driver loads again.  Does the attached
>> patch help?  It attempts to disable dpm at startup in case it wasn't
>> torn down properly previously.
>
> dpm initialization now works, but unfortunately GPU acceleration still gets
> disabled:

Stupid kexec complicates things.  We need to make sure dpm is torn
down before we init the rest of the GPU, but dpm needs get initialized
later in the init process since it depends on certain other state from
the driver.  I need to think about this for a bit.  I'm not sure of a
good way to handle this.

Alex

>
> [drm] Initialized drm 1.1.0 20060810  
>   
> [135/1104]
> [drm] radeon kernel modesetting enabled.
> [drm] initializing kernel modesetting (RS780 0x1002:0x9614 0x1043:0x834D).
> [drm] register mmio base: 0xFBEE
> [drm] register mmio size: 65536
> ATOM BIOS: 113
> radeon :01:05.0: VRAM: 128M 0xC000 - 0xC7FF (128M 
> used)
> radeon :01:05.0: GTT: 512M 0xA000 - 0xBFFF
> [drm] Detected VRAM RAM=128M, BAR=128M
> [drm] RAM width 32bits DDR
> [TTM] Zone  kernel: Available graphics memory: 4082356 kiB
> [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
> [TTM] Initializing pool allocator
> [TTM] Initializing DMA pool allocator
> [drm] radeon: 128M of VRAM memory ready
> [drm] radeon: 512M of GTT memory ready.
> [drm] GART: num cpu pages 131072, num gpu pages 131072
> [drm] Loading RS780 Microcode
> [drm] PCIE GART of 512M enabled (table at 0xC004).
> radeon :01:05.0: WB enabled
> radeon :01:05.0: fence driver on ring 0 use gpu addr 0xac00 
> and cpu addr 0x880215c30c00
> radeon :01:05.0: fence driver on ring 3 use gpu addr 0xac0c 
> and cpu addr 0x880215c30c0c
> [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
> [drm] Driver supports precise vblank timestamp query.
> [drm] radeon: irq initialized.
> radeon :01:05.0: setting latency timer to 64
> [drm] ring test on 0 succeeded in 1 usecs
> [drm:r600_dma_ring_test] *ERROR* radeon: ring 3 test failed (0xCAFEDEAD)
> radeon :01:05.0: disabling GPU acceleration
> radeon :01:05.0: 8802161cfc00 unpin not necessary
> [drm] Radeon Display Connectors
> [drm] Connector 0:
> [drm]   VGA-1
> [drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
> [drm]   Encoders:
> [drm] CRT1: INTERNAL_KLDSCP_DAC1
> [drm] Connector 1:
> [drm]   DVI-D-1
> [drm]   HPD3
> [drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
> [drm]   Encoders:
> [drm] DFP3: INTERNAL_KLDSCP_LVTMA
> == power state 0 ==
> ui class: none
> internal class: boot
> caps: video
> uvdvclk: 0 dclk: 0
> power level 0sclk: 5 vddc_index: 2
> power level 1sclk: 5 vddc_index: 2
> status: c r b
> == power state 1 ==
> ui class: performance
> internal class: none
> caps: video
> uvdvclk: 0 dclk: 0
> power level 0sclk: 5 vddc_index: 1
> power level 1sclk: 7 vddc_index: 2
> status:
> == power state 2 ==
> ui class: none
> internal class: uvd
> caps: video
> uvdvclk: 53300 dclk: 4
> power level 0sclk: 5 vddc_index: 1
> power level 1sclk: 5 vddc_index: 1
> status:
> switching from power state:
> ui class: none
> internal class: boot
> caps: video
> uvdvclk: 0 dclk: 0
> power level 0sclk: 5 vddc_index: 2
> power level 1sclk: 5 vddc_index: 2
> status: c b
> switching to power state:
> ui class: performance
> internal class: none
> caps: video
> uvdvclk: 0 dclk: 0
> power level 0sclk: 5 vddc_index: 1
> power level 1sclk: 7 vddc_index: 2
> status: r
> [drm] radeon: dpm initialized
> [drm] fb mappable at 0xF0142000
> [drm] vram apper at 0xF000
> [drm] size 7299072
> [drm] fb depth is 24
> [drm]pitch is 6912
> fbcon: radeondrmfb (fb0)
>
> --
> Markus

[RFC 0/1] drm/pl111: Initial drm/kms driver for pl111

[Rob Clark]

On Fri, Jul 26, 2013 at 11:58 AM, Tom Cooksey  wrote:
> Hi Rob,
>
>> >  * It abuses flags parameter of DRM_IOCTL_MODE_CREATE_DUMB to also
>> >allocate buffers for the GPU. Still not sure how to resolve this
>> >as we don't use DRM for our GPU driver.
>>
>> any thoughts/plans about a DRM GPU driver?  Ideally long term (esp.
>> once the dma-fence stuff is in place), we'd have gpu-specific drm
>> (gpu-only, no kms) driver, and SoC/display specific drm/kms driver,
>> using prime/dmabuf to share between the two.
>
> The "extra" buffers we were allocating from armsoc DDX were really
> being allocated through DRM/GEM so we could get an flink name
> for them and pass a reference to them back to our GPU driver on
> the client side. If it weren't for our need to access those
> extra off-screen buffers with the GPU we wouldn't need to
> allocate them with DRM at all. So, given they are really "GPU"
> buffers, it does absolutely make sense to allocate them in a
> different driver to the display driver.
>
> However, to avoid unnecessary memcpys & related cache
> maintenance ops, we'd also like the GPU to render into buffers
> which are scanned out by the display controller. So let's say
> we continue using DRM_IOCTL_MODE_CREATE_DUMB to allocate scan
> out buffers with the display's DRM driver but a custom ioctl
> on the GPU's DRM driver to allocate non scanout, off-screen
> buffers. Sounds great, but I don't think that really works
> with DRI2. If we used two drivers to allocate buffers, which
> of those drivers do we return in DRI2ConnectReply? Even if we
> solve that somehow, GEM flink names are name-spaced to a
> single device node (AFAIK). So when we do a DRI2GetBuffers,
> how does the EGL in the client know which DRM device owns GEM
> flink name "1234"? We'd need some pretty dirty hacks.

You would return the name of the display driver allocating the
buffers.  On the client side you can use generic ioctls to go from
flink -> handle -> dmabuf.  So the client side would end up opening
both the display drm device and the gpu, but without needing to know
too much about the display.

(Probably in (for example) mesa there needs to be a bit of work to
handle this better, but I think that would be needed as well for
sharing between, say, nouveau and udl displaylink driver.. which is
really the same scenario.)

> So then we looked at allocating _all_ buffers with the GPU's
> DRM driver. That solves the DRI2 single-device-name and single
> name-space issue. It also means the GPU would _never_ render
> into buffers allocated through DRM_IOCTL_MODE_CREATE_DUMB.

Well, I think we can differentiate between shared buffers and internal
buffers (textures, vertex upload, etc, etc).

For example, in mesa/gallium driver there are two paths to getting a
buffer...  ->resource_create() and ->resource_from_handle(), the
latter is the path you go for dri2 buffers shared w/ x11.  The former
is buffers that are just internal to gpu (if !(bind &
PIPE_BIND_SHARED)).  I guess you must have something similar in mali
driver.

> One thing I wasn't sure about is if there was an objection
> to using PRIME to export scanout buffers allocated with
> DRM_IOCTL_MODE_CREATE_DUMB and then importing them into a GPU
> driver to be rendered into? Is that a concern?

well.. it wasn't quite the original intention of the 'dumb' ioctls.
But I guess in the end if you hand the gpu a buffer with a
layout/format that it can't grok, then gpu does a staging texture plus
copy.  If you had, for example, some setup w/ gpu that could only
render to tiled format, plus a display that could scanout that format,
then your DDX driver would need to allocate the dri2 buffers with
something other than dumb ioctl.  (But at that point, you probably
need to implement your own EXA so you could hook in your own custom
upload-to/download-from screen fxns for sw fallbacks, so you're not
talking about using generic DDX anyways.)

> Anyway, that latter case also gets quite difficult. The "GPU"
> DRM driver would need to know the constraints of the display
> controller when allocating buffers intended to be scanned out.
> For example, pl111 typically isn't behind an IOMMU and so
> requires physically contiguous memory. We'd have to teach the
> GPU's DRM driver about the constraints of the display HW. Not
> exactly a clean driver model. :-(
>
> I'm still a little stuck on how to proceed, so any ideas
> would greatly appreciated! My current train of thought is
> having a kind of SoC-specific DRM driver which allocates
> buffers for both display and GPU within a single GEM
> namespace. That SoC-specific DRM driver could then know the
> constraints of both the GPU and the display HW. We could then
> use PRIME to export buffers allocated with the SoC DRM driver
> and import them into the GPU and/or display DRM driver.

Usually if the display drm driver is allocating the buffers that might
be scanned out, it just needs to have minimal knowledge of the GPU
(pitch alignment constraints). 

Commit f5d9b7f0f9 (fix r600_enable_sclk_control()) causes kexec issues

[Markus Trippelsdorf]

On 2013.07.29 at 18:14 +0200, Joshua C. wrote:
> 
> This error message seems similar to mine "[drm:r600_uvd_ring_test]
> *ERROR* radeon: ring 5 test failed (0xCAFEDEAD)" Bugzilla:
> https://bugs.freedesktop.org/show_bug.cgi?id=67276 In my case I blame
> another commit for this. Are these bugs related?

I guess not, because reverting commit 9cc2e0e9f13 doesn't fix the issue
for me. 
Can you check if reverting commit f5d9b7f0f9 does fixes the problem for
you?

-- 
Markus

[Bug 67435] HDMI audio silent on Radeon Mobility HD4650

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=67435

--- Comment #4 from Kris Scott  ---
Bisect complete:

b1f6f47e3e33c4a74534f1301aca241ffabbb3a0 is the first bad commit
commit b1f6f47e3e33c4a74534f1301aca241ffabbb3a0
Author: Alex Deucher 
Date:   Thu Apr 18 10:50:55 2013 -0400

drm/radeon: clean up audio dto programming

Split into DCE2/3 and DCE4/5 variants. Still todo is to
calculate the DTO dividers properly.  Add proper formula
to the comments.

Reviewed-by: Christian K?nig 
Signed-off-by: Alex Deucher 

:04 04 b60cf880f2227596705391e71a56aaa12e1eb61c
a723f4928d1a20bcd0b5759077360f9342c9eecc Mdrivers

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130729/e1e0c32b/attachment-0001.html>

[Bug 67435] HDMI audio silent on Radeon Mobility HD4650

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=67435

--- Comment #5 from Rafa? Mi?ecki  ---
As I suggested earlier, can you provide output of "avivotool regs hdmi" before
and after this patch?

This way we will sure if registers are programmed and with what values.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130729/fff46053/attachment.html>

[Bug 67435] HDMI audio silent on Radeon Mobility HD4650

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=67435

--- Comment #6 from Kris Scott  ---
Good:

RADEON_DAC_CNTL
RADEON_DAC_EXT_CNTL
RADEON_DAC_MACRO_CNTL
RADEON_DAC_CNTL2
RADEON_TV_DAC_CNTL
RADEON_DISP_OUTPUT_CNTL
RADEON_CONFIG_MEMSIZE
RADEON_AUX_SC_CNTL804df8a8
RADEON_CRTC_EXT_CNTL
RADEON_CRTC_GEN_CNTL
RADEON_CRTC2_GEN_CNTL
RADEON_DEVICE_ID
RADEON_DISP_MISC_CNTL
RADEON_GPIO_MONID
RADEON_GPIO_MONIDB
RADEON_GPIO_CRT2_DDC
RADEON_GPIO_DVI_DDC
RADEON_GPIO_VGA_DDC
RADEON_LVDS_GEN_CNTL
RADEON_LVDS_PLL_CNTL
RADEON_FP_GEN_CNTL
RADEON_FP2_GEN_CNTL
RADEON_PPLL_CNTL
RADEON_PPLL_REF_DIV
RADEON_PPLL_DIV_3
RADEON_PIXCLKS_CNTL
RADEON_P2PLL_CNTL
RADEON_P2PLL_REF_DIV
RADEON_P2PLL_DIV_0
RADEON_VCLK_ECP_CNTL
RADEON_MEM_TIMING_CNTL
RADEON_TMDS_PLL_CNTL
RADEON_TMDS_TRANSMITTER_CNTL
RADEON_CRTC_MORE_CNTL
RADEON_FP_H_SYNC_STRT_WID
RADEON_FP_V_SYNC_STRT_WID
RADEON_FP_CRTC_H_TOTAL_DISP
RADEON_FP_CRTC_V_TOTAL_DISP
RADEON_FP_HORZ_STRETCH
RADEON_FP_VERT_STRETCH
RADEON_FP_HORZ_VERT_ACTIVE
RADEON_CRTC_H_TOTAL_DISP0004
RADEON_CRTC_H_SYNC_STRT_WID18b8bebc
RADEON_CRTC_V_TOTAL_DISPfffe0a02
RADEON_CRTC_V_SYNC_STRT_WID
RADEON_CRTC2_H_TOTAL_DISP020f
RADEON_CRTC2_H_SYNC_STRT_WID
RADEON_CRTC2_V_TOTAL_DISP0100
RADEON_CRTC2_V_SYNC_STRT_WID0002

-
Bad:

RADEON_DAC_CNTL
RADEON_DAC_EXT_CNTL
RADEON_DAC_MACRO_CNTL
RADEON_DAC_CNTL2
RADEON_TV_DAC_CNTL
RADEON_DISP_OUTPUT_CNTL
RADEON_CONFIG_MEMSIZE
RADEON_AUX_SC_CNTLc045fab8
RADEON_CRTC_EXT_CNTL
RADEON_CRTC_GEN_CNTL
RADEON_CRTC2_GEN_CNTL
RADEON_DEVICE_ID
RADEON_DISP_MISC_CNTL
RADEON_GPIO_MONID
RADEON_GPIO_MONIDB
RADEON_GPIO_CRT2_DDC
RADEON_GPIO_DVI_DDC
RADEON_GPIO_VGA_DDC
RADEON_LVDS_GEN_CNTL
RADEON_LVDS_PLL_CNTL
RADEON_FP_GEN_CNTL
RADEON_FP2_GEN_CNTL
RADEON_PPLL_CNTL
RADEON_PPLL_REF_DIV
RADEON_PPLL_DIV_3
RADEON_PIXCLKS_CNTL
RADEON_P2PLL_CNTL
RADEON_P2PLL_REF_DIV
RADEON_P2PLL_DIV_0
RADEON_VCLK_ECP_CNTL
RADEON_MEM_TIMING_CNTL
RADEON_TMDS_PLL_CNTL
RADEON_TMDS_TRANSMITTER_CNTL
RADEON_CRTC_MORE_CNTL
RADEON_FP_H_SYNC_STRT_WID
RADEON_FP_V_SYNC_STRT_WID
RADEON_FP_CRTC_H_TOTAL_DISP
RADEON_FP_CRTC_V_TOTAL_DISP
RADEON_FP_HORZ_STRETCH
RADEON_FP_VERT_STRETCH
RADEON_FP_HORZ_VERT_ACTIVE
RADEON_CRTC_H_TOTAL_DISP0004
RADEON_CRTC_H_SYNC_STRT_WID18b836bc
RADEON_CRTC_V_TOTAL_DISPfffe0a02
RADEON_CRTC_V_SYNC_STRT_WID
RADEON_CRTC2_H_TOTAL_DISP020f
RADEON_CRTC2_H_SYNC_STRT_WID
RADEON_CRTC2_V_TOTAL_DISP0100
RADEON_CRTC2_V_SYNC_STRT_WID0002

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130729/cac4ae74/attachment.html>

[Bug 67435] HDMI audio silent on Radeon Mobility HD4650

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=67435

--- Comment #7 from Rafa? Mi?ecki  ---
Err, did you call "avivotool regs hdmi" as I asked?

It should return something like:

Audio clocks:
EVERGREEN_AUDIO_PLL1_MUL
EVERGREEN_AUDIO_PLL1_DIV0001
EVERGREEN_AUDIO_PLL1_UNK0070

which is the most interesting part for us.

Of course on R6xx hardware it won't start with EVERGREEN_*

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130729/37393ece/attachment.html>

Commit f5d9b7f0f9 (fix r600_enable_sclk_control()) causes kexec issues

[Alex Deucher]

On Mon, Jul 29, 2013 at 12:14 PM, Joshua C.  wrote:
> 2013/7/29 Alex Deucher :
>> On Mon, Jul 29, 2013 at 10:09 AM, Markus Trippelsdorf
>>  wrote:
>>> On 2013.07.29 at 09:58 -0400, Alex Deucher wrote:
 On Mon, Jul 29, 2013 at 3:51 AM, Markus Trippelsdorf
  wrote:
 > On my test machine Xorg doesn't start anymore when I kexec into a
 > 3.11.0-rc3 kernel.

 With kexec, dpm doesn't get torn down properly which can result in a
 bad hardware state when the driver loads again.  Does the attached
 patch help?  It attempts to disable dpm at startup in case it wasn't
 torn down properly previously.
>>>
>>> dpm initialization now works, but unfortunately GPU acceleration still gets
>>> disabled:
>>
>> Stupid kexec complicates things.  We need to make sure dpm is torn
>> down before we init the rest of the GPU, but dpm needs get initialized
>> later in the init process since it depends on certain other state from
>> the driver.  I need to think about this for a bit.  I'm not sure of a
>> good way to handle this.
>>
>> Alex
>>
>>>
>>> [drm] Initialized drm 1.1.0 20060810
>>> 
>>> [135/1104]
>>> [drm] radeon kernel modesetting enabled.
>>> [drm] initializing kernel modesetting (RS780 0x1002:0x9614 0x1043:0x834D).
>>> [drm] register mmio base: 0xFBEE
>>> [drm] register mmio size: 65536
>>> ATOM BIOS: 113
>>> radeon :01:05.0: VRAM: 128M 0xC000 - 0xC7FF 
>>> (128M used)
>>> radeon :01:05.0: GTT: 512M 0xA000 - 0xBFFF
>>> [drm] Detected VRAM RAM=128M, BAR=128M
>>> [drm] RAM width 32bits DDR
>>> [TTM] Zone  kernel: Available graphics memory: 4082356 kiB
>>> [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
>>> [TTM] Initializing pool allocator
>>> [TTM] Initializing DMA pool allocator
>>> [drm] radeon: 128M of VRAM memory ready
>>> [drm] radeon: 512M of GTT memory ready.
>>> [drm] GART: num cpu pages 131072, num gpu pages 131072
>>> [drm] Loading RS780 Microcode
>>> [drm] PCIE GART of 512M enabled (table at 0xC004).
>>> radeon :01:05.0: WB enabled
>>> radeon :01:05.0: fence driver on ring 0 use gpu addr 0xac00 
>>> and cpu addr 0x880215c30c00
>>> radeon :01:05.0: fence driver on ring 3 use gpu addr 0xac0c 
>>> and cpu addr 0x880215c30c0c
>>> [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
>>> [drm] Driver supports precise vblank timestamp query.
>>> [drm] radeon: irq initialized.
>>> radeon :01:05.0: setting latency timer to 64
>>> [drm] ring test on 0 succeeded in 1 usecs
>>> [drm:r600_dma_ring_test] *ERROR* radeon: ring 3 test failed (0xCAFEDEAD)
>>> radeon :01:05.0: disabling GPU acceleration
>>> radeon :01:05.0: 8802161cfc00 unpin not necessary
>>> [drm] Radeon Display Connectors
>>> [drm] Connector 0:
>>> [drm]   VGA-1
>>> [drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
>>> [drm]   Encoders:
>>> [drm] CRT1: INTERNAL_KLDSCP_DAC1
>>> [drm] Connector 1:
>>> [drm]   DVI-D-1
>>> [drm]   HPD3
>>> [drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
>>> [drm]   Encoders:
>>> [drm] DFP3: INTERNAL_KLDSCP_LVTMA
>>> == power state 0 ==
>>> ui class: none
>>> internal class: boot
>>> caps: video
>>> uvdvclk: 0 dclk: 0
>>> power level 0sclk: 5 vddc_index: 2
>>> power level 1sclk: 5 vddc_index: 2
>>> status: c r b
>>> == power state 1 ==
>>> ui class: performance
>>> internal class: none
>>> caps: video
>>> uvdvclk: 0 dclk: 0
>>> power level 0sclk: 5 vddc_index: 1
>>> power level 1sclk: 7 vddc_index: 2
>>> status:
>>> == power state 2 ==
>>> ui class: none
>>> internal class: uvd
>>> caps: video
>>> uvdvclk: 53300 dclk: 4
>>> power level 0sclk: 5 vddc_index: 1
>>> power level 1sclk: 5 vddc_index: 1
>>> status:
>>> switching from power state:
>>> ui class: none
>>> internal class: boot
>>> caps: video
>>> uvdvclk: 0 dclk: 0
>>> power level 0sclk: 5 vddc_index: 2
>>> power level 1sclk: 5 vddc_index: 2
>>> status: c b
>>> switching to power state:
>>> ui class: performance
>>> internal class: none
>>> caps: video
>>> uvdvclk: 0 dclk: 0
>>> power level 0sclk: 5 vddc_index: 1
>>> power level 1sclk: 7 vddc_index: 2
>>> status: r
>>> [drm] radeon: dpm initialized
>>> [drm] fb mappable at 0xF0142000
>>> [drm] vram apper at 0xF000
>>> [drm] size 7299072
>>> [drm] fb depth is 24
>>> [drm]pitch is 6912
>>> fbcon: radeondrmfb (f

Commit f5d9b7f0f9 (fix r600_enable_sclk_control()) causes kexec issues

[Alex Deucher]

On Mon, Jul 29, 2013 at 11:50 AM, Eric W. Biederman
 wrote:
>
>
> Alex Deucher  wrote:
>>On Mon, Jul 29, 2013 at 10:09 AM, Markus Trippelsdorf
>> wrote:
>>> On 2013.07.29 at 09:58 -0400, Alex Deucher wrote:
 On Mon, Jul 29, 2013 at 3:51 AM, Markus Trippelsdorf
  wrote:
 > On my test machine Xorg doesn't start anymore when I kexec into a
 > 3.11.0-rc3 kernel.

 With kexec, dpm doesn't get torn down properly which can result in a
 bad hardware state when the driver loads again.  Does the attached
 patch help?  It attempts to disable dpm at startup in case it wasn't
 torn down properly previously.
>>>
>>> dpm initialization now works, but unfortunately GPU acceleration
>>still gets
>>> disabled:
>>
>>Stupid kexec complicates things.  We need to make sure dpm is torn
>>down before we init the rest of the GPU, but dpm needs get initialized
>>later in the init process since it depends on certain other state from
>>the driver.  I need to think about this for a bit.  I'm not sure of a
>>good way to handle this.
>
> You might just want to implement a shutdown method that cleans things up 
> properly.   At least as a first pass until you worry about things like kexec 
> on panic.
>
> Or can you not shutdown the graphics stack on reboot because of the need to 
> display the kernels shutdown progress?

Does kexec actually call this shutdown method?  The driver implements
appropriate clean-up measures if it's shutdown properly.

Alex


>
> Eric
>
>>Alex
>>
>>>
>>> [drm] Initialized drm 1.1.0 20060810
>> [135/1104]
>>> [drm] radeon kernel modesetting enabled.
>>> [drm] initializing kernel modesetting (RS780 0x1002:0x9614
>>0x1043:0x834D).
>>> [drm] register mmio base: 0xFBEE
>>> [drm] register mmio size: 65536
>>> ATOM BIOS: 113
>>> radeon :01:05.0: VRAM: 128M 0xC000 -
>>0xC7FF (128M used)
>>> radeon :01:05.0: GTT: 512M 0xA000 -
>>0xBFFF
>>> [drm] Detected VRAM RAM=128M, BAR=128M
>>> [drm] RAM width 32bits DDR
>>> [TTM] Zone  kernel: Available graphics memory: 4082356 kiB
>>> [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
>>> [TTM] Initializing pool allocator
>>> [TTM] Initializing DMA pool allocator
>>> [drm] radeon: 128M of VRAM memory ready
>>> [drm] radeon: 512M of GTT memory ready.
>>> [drm] GART: num cpu pages 131072, num gpu pages 131072
>>> [drm] Loading RS780 Microcode
>>> [drm] PCIE GART of 512M enabled (table at 0xC004).
>>> radeon :01:05.0: WB enabled
>>> radeon :01:05.0: fence driver on ring 0 use gpu addr
>>0xac00 and cpu addr 0x880215c30c00
>>> radeon :01:05.0: fence driver on ring 3 use gpu addr
>>0xac0c and cpu addr 0x880215c30c0c
>>> [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
>>> [drm] Driver supports precise vblank timestamp query.
>>> [drm] radeon: irq initialized.
>>> radeon :01:05.0: setting latency timer to 64
>>> [drm] ring test on 0 succeeded in 1 usecs
>>> [drm:r600_dma_ring_test] *ERROR* radeon: ring 3 test failed
>>(0xCAFEDEAD)
>>> radeon :01:05.0: disabling GPU acceleration
>>> radeon :01:05.0: 8802161cfc00 unpin not necessary
>>> [drm] Radeon Display Connectors
>>> [drm] Connector 0:
>>> [drm]   VGA-1
>>> [drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
>>> [drm]   Encoders:
>>> [drm] CRT1: INTERNAL_KLDSCP_DAC1
>>> [drm] Connector 1:
>>> [drm]   DVI-D-1
>>> [drm]   HPD3
>>> [drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
>>> [drm]   Encoders:
>>> [drm] DFP3: INTERNAL_KLDSCP_LVTMA
>>> == power state 0 ==
>>> ui class: none
>>> internal class: boot
>>> caps: video
>>> uvdvclk: 0 dclk: 0
>>> power level 0sclk: 5 vddc_index: 2
>>> power level 1sclk: 5 vddc_index: 2
>>> status: c r b
>>> == power state 1 ==
>>> ui class: performance
>>> internal class: none
>>> caps: video
>>> uvdvclk: 0 dclk: 0
>>> power level 0sclk: 5 vddc_index: 1
>>> power level 1sclk: 7 vddc_index: 2
>>> status:
>>> == power state 2 ==
>>> ui class: none
>>> internal class: uvd
>>> caps: video
>>> uvdvclk: 53300 dclk: 4
>>> power level 0sclk: 5 vddc_index: 1
>>> power level 1sclk: 5 vddc_index: 1
>>> status:
>>> switching from power state:
>>> ui class: none
>>> internal class: boot
>>> caps: video
>>> uvdvclk: 0 dclk: 0
>>> power level 0sclk: 5 vddc_index: 2
>>> power level 1sclk: 5 vddc_index: 2
>>> status: c b
>>> switching to power state:
>>> ui class: performance
>>> internal class: none
>>> caps: video
>>> uvdvclk: 0 

[Bug 67435] HDMI audio silent on Radeon Mobility HD4650

[bugzilla-dae...@freedesktop.org]

0094

Audio conn list:
R600_AUDIO_CONN_LIST_LEN0001
R600_AUDIO_CONN_LIST08060402

Audio verbs:
R600_AUDIO_RATE_BPS_CHANNEL0011
R600_AUDIO_PLAYING0010
R600_AUDIO_IMPLEMENTATION_ID104d2e00
R600_AUDIO_CONFIG_DEFAULT18560010
R600_AUDIO_PIN_SENSE7fff
R600_AUDIO_PIN_WIDGET_CNTL40404040
R600_AUDIO_STATUS_BITS0001

HDMI block at 0x7400:
74000011 (17)
7404 (0)
74080010 (16)
740c0001 (65536)
7410 (0)
7414 (0)
7418 (0)
741c (0)
7420 (0)
7424 (0)
7428 (0)
742c (0)
7430 (0)
7434 (0)
7438 (0)
743c (0)
7440 (0)
7444 (0)
7448 (0)
744c (0)
7450 (0)
7454 (0)
7458 (0)
745c (0)
74600200 (33554432)
7464 (0)
7468 (0)
746c (0)
7470 (0)
7474 (0)
7478 (0)
747c (0)
7480 (0)
7484 (0)
7488 (0)
748c (0)
7490 (0)
7494 (0)
7498 (0)
749c (0)
74a0 (0)
74a4 (0)
74a8 (0)
74ac (0)
74b0 (0)
74b4 (0)
74b8 (0)
74bc (0)
74c0 (0)
74c4 (0)
74c8 (0)
74cc0170 (368)
74d0 (0)
74d41000 (268435456)
74d8 (0)
74dc (0)
74e0 (0)
74e4 (0)
74e8 (0)
74ec (0)

HDMI block at 0x7800:
78000011 (17)
78040001 (65536)
780800030010 (196624)
780c1000 (4096)
78100031 (49)
78140033 (51)
78180202 (514)
781c (0)
7820 (0)
7824 (0)
7828 (0)
782c (0)
7830 (0)
7834 (0)
7838 (0)
783c (0)
7840 (0)
7844 (0)
7848 (0)
784c (0)
7850 (0)
785400080063 (524387)
78580004 (4)
785c (0)
78600200 (33554432)
7864 (0)
7868 (0)
786c (0)
7870 (0)
7874 (0)
7878 (0)
787c (0)
7880 (0)
7884 (0)
7888 (0)
788c (0)
7890 (0)
7894 (0)
7898 (0)
789c (0)
78a0 (0)
78a4 (0)
78a8 (0)
78ac1220a000 (304128000)
78b01000 (4096)
78b414244000 (33792)
78b81880 (6272)
78bc1220a000 (304128000)
78c01800 (6144)
78c40cb19000 (212963328)
78c81800 (6144)
78cc0170 (368)
78d0 (0)
78d40200 (33554432)
78d80002 (2)
78dc1100 (4352)
78e000ff (16777215)
78e4007f (8388607)
78e80001 (1)
78ec0001 (1)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130729/f3fa47dc/attachment.html>

[Bug 66067] Trine 2's fragment normal buffer is mixtextured on Radeon HD 6770 (Juniper)

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=66067

Nicholas Miell  changed:

   What|Removed |Added

Summary|Trine 2 color problems on   |Trine 2's fragment normal
   |Radeon HD 6770 (Juniper)|buffer is mixtextured on
   ||Radeon HD 6770 (Juniper)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130729/7c7c7000/attachment-0001.html>

[Bug 67107] Xorg starts and crashes with DPM enable

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=67107

--- Comment #3 from Christopher Chmielewski  ---
I just tried with rc3 and it still happens.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130729/03a42ad8/attachment.html>

[Bug 67435] HDMI audio silent on Radeon Mobility HD4650

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=67435

--- Comment #9 from Rafa? Mi?ecki  ---
@Kris: thank you for you debugging! I hope this is last debugging request.

Can you boot not working (bad) kernel, connect HDMI display and then type:

avivotool regset 0x0524 0x00249f00
avivotool regset 0x0528 0x00714be8
avivotool regset 0x0534 0x0001

I hope this will resume audio on your card, but I just want to be sure, before
asking Alex for getting more details on that.

If you could confirm that above 3 commands fix audio for you, it'd be great.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130729/4dc88e8e/attachment.html>

Commit f5d9b7f0f9 (fix r600_enable_sclk_control()) causes kexec issues

[Alex Deucher]

On Mon, Jul 29, 2013 at 2:10 PM, Eric W. Biederman
 wrote:
> Alex Deucher  writes:
>
>> On Mon, Jul 29, 2013 at 11:50 AM, Eric W. Biederman
>>  wrote:
>>>
>>>
>>> Alex Deucher  wrote:
On Mon, Jul 29, 2013 at 10:09 AM, Markus Trippelsdorf
 wrote:
> On 2013.07.29 at 09:58 -0400, Alex Deucher wrote:
>> On Mon, Jul 29, 2013 at 3:51 AM, Markus Trippelsdorf
>>  wrote:
>> > On my test machine Xorg doesn't start anymore when I kexec into a
>> > 3.11.0-rc3 kernel.
>>
>> With kexec, dpm doesn't get torn down properly which can result in a
>> bad hardware state when the driver loads again.  Does the attached
>> patch help?  It attempts to disable dpm at startup in case it wasn't
>> torn down properly previously.
>
> dpm initialization now works, but unfortunately GPU acceleration
still gets
> disabled:

Stupid kexec complicates things.  We need to make sure dpm is torn
down before we init the rest of the GPU, but dpm needs get initialized
later in the init process since it depends on certain other state from
the driver.  I need to think about this for a bit.  I'm not sure of a
good way to handle this.
>>>
>>> You might just want to implement a shutdown method that cleans things up 
>>> properly.   At least as a first pass until you worry about things like 
>>> kexec on panic.
>>>
>>> Or can you not shutdown the graphics stack on reboot because of the need to 
>>> display the kernels shutdown progress?
>>
>> Does kexec actually call this shutdown method?  The driver implements
>> appropriate clean-up measures if it's shutdown properly.
>
> Absoltuely.  All parts of the reboot path call ->shutdown.  Including
> kexec.
>
> You don't get a device remove/hotunplug but unless this is a kexec on
> panic ->shutdown is most definitely called.  Now I am talking about the
> device layer/pci layer shutdown method I don't know how gpu drivers are
> wired up.  GPU land was a little strange last I looked.  Hopefully it
> isn't so strange that there is a method named shutdown that is not wired
> up.

It doesn't look like the drm infrastructure has a shutdown callback.
The drm drivers register a drm_driver callback struct that includes an
unload callback which takes care of all the device teardown (if you
unload the module for example).  I don't know that it actually gets
called at kexec time however.  I don't know enough about how kexec
works.

Markus, does everything work ok after a reboot?  Is it just kexec that
is a problem?

Alex

Commit f5d9b7f0f9 (fix r600_enable_sclk_control()) causes kexec issues

[Markus Trippelsdorf]

On 2013.07.29 at 15:53 -0400, Alex Deucher wrote:
> On Mon, Jul 29, 2013 at 2:10 PM, Eric W. Biederman
>  wrote:
> > Alex Deucher  writes:
> >
> >> On Mon, Jul 29, 2013 at 11:50 AM, Eric W. Biederman
> >>  wrote:
> >>>
> >>>
> >>> Alex Deucher  wrote:
> On Mon, Jul 29, 2013 at 10:09 AM, Markus Trippelsdorf
>  wrote:
> > On 2013.07.29 at 09:58 -0400, Alex Deucher wrote:
> >> On Mon, Jul 29, 2013 at 3:51 AM, Markus Trippelsdorf
> >>  wrote:
> >> > On my test machine Xorg doesn't start anymore when I kexec into a
> >> > 3.11.0-rc3 kernel.
> >>
> >> With kexec, dpm doesn't get torn down properly which can result in a
> >> bad hardware state when the driver loads again.  Does the attached
> >> patch help?  It attempts to disable dpm at startup in case it wasn't
> >> torn down properly previously.
> >
> > dpm initialization now works, but unfortunately GPU acceleration
> still gets
> > disabled:
> 
> Stupid kexec complicates things.  We need to make sure dpm is torn
> down before we init the rest of the GPU, but dpm needs get initialized
> later in the init process since it depends on certain other state from
> the driver.  I need to think about this for a bit.  I'm not sure of a
> good way to handle this.
> >>>
> >>> You might just want to implement a shutdown method that cleans things up 
> >>> properly.   At least as a first pass until you worry about things like 
> >>> kexec on panic.
> >>>
> >>> Or can you not shutdown the graphics stack on reboot because of the need 
> >>> to display the kernels shutdown progress?
> >>
> >> Does kexec actually call this shutdown method?  The driver implements
> >> appropriate clean-up measures if it's shutdown properly.
> >
> > Absoltuely.  All parts of the reboot path call ->shutdown.  Including
> > kexec.
> >
> > You don't get a device remove/hotunplug but unless this is a kexec on
> > panic ->shutdown is most definitely called.  Now I am talking about the
> > device layer/pci layer shutdown method I don't know how gpu drivers are
> > wired up.  GPU land was a little strange last I looked.  Hopefully it
> > isn't so strange that there is a method named shutdown that is not wired
> > up.
> 
> It doesn't look like the drm infrastructure has a shutdown callback.
> The drm drivers register a drm_driver callback struct that includes an
> unload callback which takes care of all the device teardown (if you
> unload the module for example).  I don't know that it actually gets
> called at kexec time however.  I don't know enough about how kexec
> works.
> 
> Markus, does everything work ok after a reboot?  Is it just kexec that
> is a problem?

Yes.

-- 
Markus

[pull] radeon drm-fixes-3.11

[alexdeuc...@gmail.com]

From: Alex Deucher 

Hi Dave,

A few more radeon bug fixes, mostly for SI dpm.  At this point dpm is
pretty solid across the majority of asics.  I think we mostly just have
corner cases and fixing up some of the trickier features at this point.

The following changes since commit bf903e4141fce4b35072d5b8fa0ddd299aaf01ea:

  Merge tag 'drm-intel-fixes-2013-07-25' of 
git://people.freedesktop.org/~danvet/drm-intel into drm-fixes (2013-07-26 
20:38:14 +1000)

are available in the git repository at:

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

Alex Deucher (10):
  drm/radeon: fix audio dto programming on DCE4+
  drm/radeon/dpm: fix display gap programming on SI
  drm/radeon/dpm: fix si_calculate_memory_refresh_rate()
  drm/radeon/dpm: fix powertune handling for pci id 0x6835
  drm/radeon: properly handle cg on asics without UVD
  drm/radeon/atom: fix fb when fetching engine params
  drm/radeon/dpm: fix forcing performance state to low on cayman
  drm/radeon/si: disable cgcg and pg for now
  drm/radeon/dpm: disable cac setup on SI
  drm/radeon/dpm: fix and enable reclocking on SI

 drivers/gpu/drm/radeon/evergreen_hdmi.c  |2 +-
 drivers/gpu/drm/radeon/ni_dpm.c  |7 +-
 drivers/gpu/drm/radeon/radeon_atombios.c |2 +-
 drivers/gpu/drm/radeon/si.c  |   14 
 drivers/gpu/drm/radeon/si_dpm.c  |   34 ++---
 5 files changed, 24 insertions(+), 35 deletions(-)

[Bug 67435] HDMI audio silent on Radeon Mobility HD4650

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=67435

--- Comment #10 from Kris Scott  ---
Yes, those fixed it. Thank you very much.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130729/ab5f7ef4/attachment.html>

[Bug 67435] HDMI audio silent on Radeon Mobility HD4650

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=67435

--- Comment #11 from Alex Deucher  ---
Can you tell be the values of 0x7340, 0x7344, 0x520, and 0x530?
avivotool regmatch 0x7340
avivotool regmatch 0x7344
avivotool regmatch 0x520
avivotool regmatch 0x530

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130729/e3448551/attachment.html>

[Bug 67435] HDMI audio silent on Radeon Mobility HD4650

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=67435

--- Comment #12 from Kris Scott  ---
0x73400x001b0018 (1769496)
0x73440x0070 (112)
0x5200x0070 (112)
0x5300x0070 (112)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130729/841847a9/attachment-0001.html>

[Bug 67435] HDMI audio silent on Radeon Mobility HD4650

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=67435

--- Comment #13 from Kris Scott  ---
That is also after I had changed the registers that Rafal asked me to change,
if it makes any difference.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130729/3dcedacf/attachment.html>

[Bug 67435] HDMI audio silent on Radeon Mobility HD4650

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=67435

--- Comment #14 from Alex Deucher  ---
Can you boot back into the broken state and try this alternative fix:
avivotool regset 0x7344 0x0170

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130729/ff0004f9/attachment.html>

[3.10rc6] /proc/dri/0/vma broken on nouveau.

[Dave Jones]

On Mon, Jun 17, 2013 at 09:49:27PM -0400, David Airlie wrote:
 > 
 > > Reading /proc/dri/0/vma causes bad things to happen on a box with nouveau
 > > loaded.
 > > (Note, no X running on that box)
 > > 
 > > Trace below shows trinity, but I can reproduce it with just cat
 > > /proc/dri/0/vma
 > 
 > How about this, lets just rip it all out.

No-one objected, and this is still around in 3.11-rc3 in the same
easily oopsable state.. I vote we kill it with fire.

Dave

[PATCH 1/4] gpu/vga_switcheroo: add driver control power feature. (v3)

[Hohahiu]

Hello, Dave!

I have a hybrid muxless laptop with intel+radeon:
#lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core 
processor Graphics Controller (rev 09)
01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI 
Cape Verde [Radeon HD 7700M Series]

I have some questions related to this series of patches.
When I power down discrete card by vgaswitcheroo, restart X server and 
turn on radeon card again, xrandr doesn't recognize my discrete card and 
only shows the intel one. Is this a bug or a feature of X server?
And how would this behavior change with this patch?

Also sometimes I have the following configuration:
# cat /sys/kernel/debug/vgaswitcheroo/switch
0:DIS: :Pwr::01:00.0
1:IGD:+:Pwr::00:02.0

In this case if I do
# echo OFF > /sys/kernel/debug/vgaswitcheroo/switch
the system hangs and doesn't respond (ssh, magic keys etc.).

In the meantime for a
# cat /sys/kernel/debug/vgaswitcheroo/switch
0:IGD:+:Pwr::00:02.0
1:DIS: :Pwr::01:00.0

# echo OFF > /sys/kernel/debug/vgaswitcheroo/switch
powers down discrete card successfully.

Would it be resolved with these patches?

Hohahiu

PS. Should I open bug report for these issues?

Commit f5d9b7f0f9 (fix r600_enable_sclk_control()) causes kexec issues

[Joshua C.]

2013/7/29 Alex Deucher :
> On Mon, Jul 29, 2013 at 10:09 AM, Markus Trippelsdorf
>  wrote:
>> On 2013.07.29 at 09:58 -0400, Alex Deucher wrote:
>>> On Mon, Jul 29, 2013 at 3:51 AM, Markus Trippelsdorf
>>>  wrote:
>>> > On my test machine Xorg doesn't start anymore when I kexec into a
>>> > 3.11.0-rc3 kernel.
>>>
>>> With kexec, dpm doesn't get torn down properly which can result in a
>>> bad hardware state when the driver loads again.  Does the attached
>>> patch help?  It attempts to disable dpm at startup in case it wasn't
>>> torn down properly previously.
>>
>> dpm initialization now works, but unfortunately GPU acceleration still gets
>> disabled:
>
> Stupid kexec complicates things.  We need to make sure dpm is torn
> down before we init the rest of the GPU, but dpm needs get initialized
> later in the init process since it depends on certain other state from
> the driver.  I need to think about this for a bit.  I'm not sure of a
> good way to handle this.
>
> Alex
>
>>
>> [drm] Initialized drm 1.1.0 20060810 
>>  
>>   [135/1104]
>> [drm] radeon kernel modesetting enabled.
>> [drm] initializing kernel modesetting (RS780 0x1002:0x9614 0x1043:0x834D).
>> [drm] register mmio base: 0xFBEE
>> [drm] register mmio size: 65536
>> ATOM BIOS: 113
>> radeon :01:05.0: VRAM: 128M 0xC000 - 0xC7FF 
>> (128M used)
>> radeon :01:05.0: GTT: 512M 0xA000 - 0xBFFF
>> [drm] Detected VRAM RAM=128M, BAR=128M
>> [drm] RAM width 32bits DDR
>> [TTM] Zone  kernel: Available graphics memory: 4082356 kiB
>> [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
>> [TTM] Initializing pool allocator
>> [TTM] Initializing DMA pool allocator
>> [drm] radeon: 128M of VRAM memory ready
>> [drm] radeon: 512M of GTT memory ready.
>> [drm] GART: num cpu pages 131072, num gpu pages 131072
>> [drm] Loading RS780 Microcode
>> [drm] PCIE GART of 512M enabled (table at 0xC004).
>> radeon :01:05.0: WB enabled
>> radeon :01:05.0: fence driver on ring 0 use gpu addr 0xac00 
>> and cpu addr 0x880215c30c00
>> radeon :01:05.0: fence driver on ring 3 use gpu addr 0xac0c 
>> and cpu addr 0x880215c30c0c
>> [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
>> [drm] Driver supports precise vblank timestamp query.
>> [drm] radeon: irq initialized.
>> radeon :01:05.0: setting latency timer to 64
>> [drm] ring test on 0 succeeded in 1 usecs
>> [drm:r600_dma_ring_test] *ERROR* radeon: ring 3 test failed (0xCAFEDEAD)
>> radeon :01:05.0: disabling GPU acceleration
>> radeon :01:05.0: 8802161cfc00 unpin not necessary
>> [drm] Radeon Display Connectors
>> [drm] Connector 0:
>> [drm]   VGA-1
>> [drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
>> [drm]   Encoders:
>> [drm] CRT1: INTERNAL_KLDSCP_DAC1
>> [drm] Connector 1:
>> [drm]   DVI-D-1
>> [drm]   HPD3
>> [drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
>> [drm]   Encoders:
>> [drm] DFP3: INTERNAL_KLDSCP_LVTMA
>> == power state 0 ==
>> ui class: none
>> internal class: boot
>> caps: video
>> uvdvclk: 0 dclk: 0
>> power level 0sclk: 5 vddc_index: 2
>> power level 1sclk: 5 vddc_index: 2
>> status: c r b
>> == power state 1 ==
>> ui class: performance
>> internal class: none
>> caps: video
>> uvdvclk: 0 dclk: 0
>> power level 0sclk: 5 vddc_index: 1
>> power level 1sclk: 7 vddc_index: 2
>> status:
>> == power state 2 ==
>> ui class: none
>> internal class: uvd
>> caps: video
>> uvdvclk: 53300 dclk: 4
>> power level 0sclk: 5 vddc_index: 1
>> power level 1sclk: 5 vddc_index: 1
>> status:
>> switching from power state:
>> ui class: none
>> internal class: boot
>> caps: video
>> uvdvclk: 0 dclk: 0
>> power level 0sclk: 5 vddc_index: 2
>> power level 1sclk: 5 vddc_index: 2
>> status: c b
>> switching to power state:
>> ui class: performance
>> internal class: none
>> caps: video
>> uvdvclk: 0 dclk: 0
>> power level 0sclk: 5 vddc_index: 1
>> power level 1sclk: 7 vddc_index: 2
>> status: r
>> [drm] radeon: dpm initialized
>> [drm] fb mappable at 0xF0142000
>> [drm] vram apper at 0xF000
>> [drm] size 7299072
>> [drm] fb depth is 24
>> [drm]pitch is 6912
>> fbcon: radeondrmfb (fb0)
>>
>> --
>> Markus
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman

Commit f5d9b7f0f9 (fix r600_enable_sclk_control()) causes kexec issues

[Eric W. Biederman]

Alex Deucher  wrote:
>On Mon, Jul 29, 2013 at 10:09 AM, Markus Trippelsdorf
> wrote:
>> On 2013.07.29 at 09:58 -0400, Alex Deucher wrote:
>>> On Mon, Jul 29, 2013 at 3:51 AM, Markus Trippelsdorf
>>>  wrote:
>>> > On my test machine Xorg doesn't start anymore when I kexec into a
>>> > 3.11.0-rc3 kernel.
>>>
>>> With kexec, dpm doesn't get torn down properly which can result in a
>>> bad hardware state when the driver loads again.  Does the attached
>>> patch help?  It attempts to disable dpm at startup in case it wasn't
>>> torn down properly previously.
>>
>> dpm initialization now works, but unfortunately GPU acceleration
>still gets
>> disabled:
>
>Stupid kexec complicates things.  We need to make sure dpm is torn
>down before we init the rest of the GPU, but dpm needs get initialized
>later in the init process since it depends on certain other state from
>the driver.  I need to think about this for a bit.  I'm not sure of a
>good way to handle this.

You might just want to implement a shutdown method that cleans things up 
properly.   At least as a first pass until you worry about things like kexec on 
panic.

Or can you not shutdown the graphics stack on reboot because of the need to 
display the kernels shutdown progress?

Eric

>Alex
>
>>
>> [drm] Initialized drm 1.1.0 20060810 
> [135/1104]
>> [drm] radeon kernel modesetting enabled.
>> [drm] initializing kernel modesetting (RS780 0x1002:0x9614
>0x1043:0x834D).
>> [drm] register mmio base: 0xFBEE
>> [drm] register mmio size: 65536
>> ATOM BIOS: 113
>> radeon :01:05.0: VRAM: 128M 0xC000 -
>0xC7FF (128M used)
>> radeon :01:05.0: GTT: 512M 0xA000 -
>0xBFFF
>> [drm] Detected VRAM RAM=128M, BAR=128M
>> [drm] RAM width 32bits DDR
>> [TTM] Zone  kernel: Available graphics memory: 4082356 kiB
>> [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
>> [TTM] Initializing pool allocator
>> [TTM] Initializing DMA pool allocator
>> [drm] radeon: 128M of VRAM memory ready
>> [drm] radeon: 512M of GTT memory ready.
>> [drm] GART: num cpu pages 131072, num gpu pages 131072
>> [drm] Loading RS780 Microcode
>> [drm] PCIE GART of 512M enabled (table at 0xC004).
>> radeon :01:05.0: WB enabled
>> radeon :01:05.0: fence driver on ring 0 use gpu addr
>0xac00 and cpu addr 0x880215c30c00
>> radeon :01:05.0: fence driver on ring 3 use gpu addr
>0xac0c and cpu addr 0x880215c30c0c
>> [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
>> [drm] Driver supports precise vblank timestamp query.
>> [drm] radeon: irq initialized.
>> radeon :01:05.0: setting latency timer to 64
>> [drm] ring test on 0 succeeded in 1 usecs
>> [drm:r600_dma_ring_test] *ERROR* radeon: ring 3 test failed
>(0xCAFEDEAD)
>> radeon :01:05.0: disabling GPU acceleration
>> radeon :01:05.0: 8802161cfc00 unpin not necessary
>> [drm] Radeon Display Connectors
>> [drm] Connector 0:
>> [drm]   VGA-1
>> [drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
>> [drm]   Encoders:
>> [drm] CRT1: INTERNAL_KLDSCP_DAC1
>> [drm] Connector 1:
>> [drm]   DVI-D-1
>> [drm]   HPD3
>> [drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
>> [drm]   Encoders:
>> [drm] DFP3: INTERNAL_KLDSCP_LVTMA
>> == power state 0 ==
>> ui class: none
>> internal class: boot
>> caps: video
>> uvdvclk: 0 dclk: 0
>> power level 0sclk: 5 vddc_index: 2
>> power level 1sclk: 5 vddc_index: 2
>> status: c r b
>> == power state 1 ==
>> ui class: performance
>> internal class: none
>> caps: video
>> uvdvclk: 0 dclk: 0
>> power level 0sclk: 5 vddc_index: 1
>> power level 1sclk: 7 vddc_index: 2
>> status:
>> == power state 2 ==
>> ui class: none
>> internal class: uvd
>> caps: video
>> uvdvclk: 53300 dclk: 4
>> power level 0sclk: 5 vddc_index: 1
>> power level 1sclk: 5 vddc_index: 1
>> status:
>> switching from power state:
>> ui class: none
>> internal class: boot
>> caps: video
>> uvdvclk: 0 dclk: 0
>> power level 0sclk: 5 vddc_index: 2
>> power level 1sclk: 5 vddc_index: 2
>> status: c b
>> switching to power state:
>> ui class: performance
>> internal class: none
>> caps: video
>> uvdvclk: 0 dclk: 0
>> power level 0sclk: 5 vddc_index: 1
>> power level 1sclk: 7 vddc_index: 2
>> status: r
>> [drm] radeon: dpm initialized
>> [drm] fb mappable at 0xF0142000
>> [drm] vram apper at 0xF000
>> [drm] size 7299072
>> [drm] fb depth

Commit f5d9b7f0f9 (fix r600_enable_sclk_control()) causes kexec issues

[Eric W. Biederman]

Alex Deucher  writes:

> On Mon, Jul 29, 2013 at 11:50 AM, Eric W. Biederman
>  wrote:
>>
>>
>> Alex Deucher  wrote:
>>>On Mon, Jul 29, 2013 at 10:09 AM, Markus Trippelsdorf
>>> wrote:
 On 2013.07.29 at 09:58 -0400, Alex Deucher wrote:
> On Mon, Jul 29, 2013 at 3:51 AM, Markus Trippelsdorf
>  wrote:
> > On my test machine Xorg doesn't start anymore when I kexec into a
> > 3.11.0-rc3 kernel.
>
> With kexec, dpm doesn't get torn down properly which can result in a
> bad hardware state when the driver loads again.  Does the attached
> patch help?  It attempts to disable dpm at startup in case it wasn't
> torn down properly previously.

 dpm initialization now works, but unfortunately GPU acceleration
>>>still gets
 disabled:
>>>
>>>Stupid kexec complicates things.  We need to make sure dpm is torn
>>>down before we init the rest of the GPU, but dpm needs get initialized
>>>later in the init process since it depends on certain other state from
>>>the driver.  I need to think about this for a bit.  I'm not sure of a
>>>good way to handle this.
>>
>> You might just want to implement a shutdown method that cleans things up 
>> properly.   At least as a first pass until you worry about things like kexec 
>> on panic.
>>
>> Or can you not shutdown the graphics stack on reboot because of the need to 
>> display the kernels shutdown progress?
>
> Does kexec actually call this shutdown method?  The driver implements
> appropriate clean-up measures if it's shutdown properly.

Absoltuely.  All parts of the reboot path call ->shutdown.  Including
kexec.

You don't get a device remove/hotunplug but unless this is a kexec on
panic ->shutdown is most definitely called.  Now I am talking about the
device layer/pci layer shutdown method I don't know how gpu drivers are
wired up.  GPU land was a little strange last I looked.  Hopefully it
isn't so strange that there is a method named shutdown that is not wired
up.

Eric

[PATCH] Fix #include in drm_mm.h to unbreak ia64 build

[Luck, Tony]

Linux-next build on ia64 is falling over with errors like this:

In file included from include/drm/drm_vma_manager.h:26,
 from include/drm/ttm/ttm_bo_api.h:35,
 from include/drm/ttm/ttm_bo_driver.h:33,
 from drivers/gpu/drm/ttm/ttm_agp_backend.c:35:
include/drm/drm_mm.h:67: error: expected specifier-qualifier-list before 
'spinlock_t'

I guess other architectures are pulling in spinlock.h
through some twisty #include path so are not seeing this
error.  But drm_mm.h makes use of spinlock_t - so it
should do the right thing and #include 

Signed-off-by: Tony Luck 

---

First saw this break in tag "next-20130726"

diff --git a/include/drm/drm_mm.h b/include/drm/drm_mm.h
index b87d05e..7d5fbae 100644
--- a/include/drm/drm_mm.h
+++ b/include/drm/drm_mm.h
@@ -37,6 +37,7 @@
  * Generic range manager structs
  */
 #include 
+#include 
 #ifdef CONFIG_DEBUG_FS
 #include 
 #endif