[PATCH libdrm 8/8] proptest: support plane properties

[Rob Clark]

On Thu, Jun 7, 2012 at 1:09 PM, Joonyoung Shim  
wrote:
> Hi, Rob.
>
>
> On 06/06/2012 03:06 AM, Rob Clark wrote:
>>
>> From: Rob Clark
>>
>> Add support to display plane properties.
>
>
> Do you not support to set property for plane?

oh, heh, I missed the fact that proptest actually lets you *set*
properties.. I won't push this particular patch until I update it to
set properties too

BR,
-R

>
>>
>> Signed-off-by: Rob Clark
>> ---
>> ?tests/proptest/proptest.c | ? 32 
>> ?1 file changed, 32 insertions(+)
>>
>> diff --git a/tests/proptest/proptest.c b/tests/proptest/proptest.c
>> index fa34a48..aac6b8f 100644
>> --- a/tests/proptest/proptest.c
>> +++ b/tests/proptest/proptest.c
>> @@ -39,6 +39,7 @@
>>
>> ?int fd;
>> ?drmModeResPtr res = NULL;
>> +drmModePlaneResPtr plane_res = NULL;
>>
>> ?const char *connector_type_str(uint32_t type)
>> ?{
>> @@ -239,10 +240,33 @@ static void listCrtcProperties(void)
>> ? ? ? ?}
>> ?}
>>
>> +static void listPlaneProperties(void)
>> +{
>> + ? ? ? int i;
>> + ? ? ? drmModePlanePtr p;
>> +
>> + ? ? ? for (i = 0; i< ?plane_res->count_planes; i++) {
>> + ? ? ? ? ? ? ? p = drmModeGetPlane(fd, plane_res->planes[i]);
>> +
>> + ? ? ? ? ? ? ? if (!p) {
>> + ? ? ? ? ? ? ? ? ? ? ? fprintf(stderr, "Could not get plane %u: %s\n",
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? plane_res->planes[i], strerror(errno));
>> + ? ? ? ? ? ? ? ? ? ? ? continue;
>> + ? ? ? ? ? ? ? }
>> +
>> + ? ? ? ? ? ? ? printf("Plane %u\n", p->plane_id);
>> +
>> + ? ? ? ? ? ? ? listObjectProperties(p->plane_id, DRM_MODE_OBJECT_PLANE);
>> +
>> + ? ? ? ? ? ? ? drmModeFreePlane(p);
>> + ? ? ? }
>> +}
>> +
>> ?static void listAllProperties(void)
>> ?{
>> ? ? ? ?listConnectorProperties();
>> ? ? ? ?listCrtcProperties();
>> + ? ? ? listPlaneProperties();
>> ?}
>>
>> ?static int setProperty(char *argv[])
>> @@ -309,6 +333,14 @@ int main(int argc, char *argv[])
>> ? ? ? ? ? ? ? ?goto done;
>> ? ? ? ?}
>>
>> + ? ? ? plane_res = drmModeGetPlaneResources(fd);
>> + ? ? ? if (!plane_res) {
>> + ? ? ? ? ? ? ? fprintf(stderr, "Failed to get plane resources: %s\n",
>> + ? ? ? ? ? ? ? ? ? ? ? strerror(errno));
>> + ? ? ? ? ? ? ? ret = 1;
>> + ? ? ? ? ? ? ? goto done;
>> + ? ? ? }
>> +
>> ? ? ? ?if (argc< ?2) {
>> ? ? ? ? ? ? ? ?listAllProperties();
>> ? ? ? ?} else if (argc == 5) {
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 50857] Invalid command stream with CAICOS when ColorTiling2D enabled

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

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

--- Comment #2 from Chris Rankin  2012-06-07 
14:16:48 PDT ---
Created attachment 62766
  --> https://bugs.freedesktop.org/attachment.cgi?id=62766
dmesg output

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

[Bug 50857] Invalid command stream with CAICOS when ColorTiling2D enabled

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

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

--- Comment #1 from Chris Rankin  2012-06-07 
14:16:13 PDT ---
Created attachment 62765
  --> https://bugs.freedesktop.org/attachment.cgi?id=62765
lspci output

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

[Bug 50857] New: Invalid command stream with CAICOS when ColorTiling2D enabled

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

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

 Bug #: 50857
   Summary: Invalid command stream with CAICOS when ColorTiling2D
enabled
Classification: Unclassified
   Product: Mesa
   Version: 8.0
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: rankincj at googlemail.com


This might also be a bug in Linux kernel or radeon_drv.so.

Just upgraded my 64 bit HD6450 machine to Fedora 17, and gnome-shell fails
immediately (login screen). Disabling ColorTiling2D in xorg.conf fixes it.
ColorTiling2D worked OK - or did nothing - in Fedora 16 with radeon_drv.so from
git and 3.3.7 kernel.

dmesg log and lspci output are attached.

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

[Bug 43353] New: nouveau will not load or boot

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

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

   Summary: nouveau will not load or boot
   Product: Drivers
   Version: 2.5
Kernel Version: 3.4
  Platform: All
OS/Version: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
AssignedTo: drivers_video-dri at kernel-bugs.osdl.org
ReportedBy: kvs at inbox.ru
Regression: Yes


Created an attachment (id=73534)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=73534)
modprobe-nouveau

Since kernel 3.4.X (also 3.5-rc) I have been seeing issues with nouveau,
machine would lock up almost immediately after grub (after nouveau load) or
just simply reboot. The following commit appears to be causing regression on my
hardware (found with bisect) - gtx560. Attached is drm.log with portion of
kern.log when attempting to insert nouveau (machine was booted with nomodeset
and drm.debug=0x04).


4f988d132d2668b4f3b42bfc70daa531115ccca1 is the first bad commit
commit 4f988d132d2668b4f3b42bfc70daa531115ccca1
Author: Sascha Hauer 
Date:   Wed Feb 1 11:38:26 2012 +0100

drm fb helper: remove unused variable crtc_id

crtc_id is set but never used, so remove it from struct
drm_fb_helper_crtc.

Signed-off-by: Sascha Hauer 
Signed-off-by: Dave Airlie 

:04 04 0a26eb080648d02fb93d75adb3e8e6b8cbabeff4
ea8fcd1ba1b8447738057e4d507eca70b4c6cd2f Mdrivers
:04 04 0ef8bbc7c102b8cf86fde3e7431259a0e79a8025
3a48417368ac82f7286f5e18e9a4137295b8cce8 Minclude


I have added added crtc_id back to drm fb helper and it seems to solve issues
on 3.4.1 so far.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[PATCH 04/12] v4l: vb2-dma-contig: add setup of sglist for MMAP buffers

[Subash Patel]

Hello Tomasz,

On 06/07/2012 06:06 AM, Laurent Pinchart wrote:
> Hi Tomasz,
>
> On Wednesday 06 June 2012 13:56:42 Tomasz Stanislawski wrote:
>> On 06/06/2012 10:06 AM, Laurent Pinchart wrote:
>>> On Wednesday 23 May 2012 15:07:27 Tomasz Stanislawski wrote:
 This patch adds the setup of sglist list for MMAP buffers.
 It is needed for buffer exporting via DMABUF mechanism.

 Signed-off-by: Tomasz Stanislawski
 Signed-off-by: Kyungmin Park
 ---

   drivers/media/video/videobuf2-dma-contig.c |   70 +-
   1 file changed, 68 insertions(+), 2 deletions(-)

 diff --git a/drivers/media/video/videobuf2-dma-contig.c
 b/drivers/media/video/videobuf2-dma-contig.c index 52b4f59..ae656be
 100644
 --- a/drivers/media/video/videobuf2-dma-contig.c
 +++ b/drivers/media/video/videobuf2-dma-contig.c
>
> [snip]
>
 +static int vb2_dc_kaddr_to_pages(unsigned long kaddr,
 +  struct page **pages, unsigned int n_pages)
 +{
 +  unsigned int i;
 +  unsigned long pfn;
 +  struct vm_area_struct vma = {
 +  .vm_flags = VM_IO | VM_PFNMAP,
 +  .vm_mm = current->mm,
 +  };
 +
 +  for (i = 0; i<  n_pages; ++i, kaddr += PAGE_SIZE) {
>>>
>>> The follow_pfn() kerneldoc mentions that it looks up a PFN for a user
>>> address. The only users I've found in the kernel sources pass a user
>>> address. Is it legal to use it for kernel addresses ?
>>
>> It is not completely legal :). As I understand the mm code, the follow_pfn
>> works only for IO/PFN mappings. This is the typical case (every case?) of
>> mappings created by dma_alloc_coherent.
>>
>> In order to make this function work for a kernel pointer, one has to create
>> an artificial VMA that has IO/PFN bits on.
>>
>> This solution is a hack-around for dma_get_pages (aka dma_get_sgtable). This
>> way the dependency on dma_get_pages was broken giving a small hope of
>> merging vb2 exporting.
>>
>> Marek prepared a patchset 'ARM: DMA-mapping: new extensions for buffer
>> sharing' that adds dma buffers with no kernel mappings and dma_get_sgtable
>> function.
>>
>> However this patchset is still in a RFC state.
>
> That's totally understood :-) I'm fine with keeping the hack for now until the
> dma_get_sgtable() gets in a usable/mergeable state, please just mention it in
> the code with something like
>
> /* HACK: This is a temporary workaround until the dma_get_sgtable() function
> becomes available. */
>
>> I have prepared a patch that removes vb2_dc_kaddr_to_pages and substitutes
>> it with dma_get_pages. It will become a part of vb2-exporter patches just
>> after dma_get_sgtable is merged (or at least acked by major maintainers).
>
The above function call (because of follow_pfn) doesn't succeed for all 
the allocated pages. Hence I created a patch(attached) which is based on 
[1] series. One can apply it for using your present patch-set in the 
meantime.

Regards,
Subash
[1] http://www.spinics.net/lists/kernel/msg1343092.html

Synchronization framework

[Maarten Lankhorst]

Hey Erik,

Op 07-06-12 19:35, Erik Gilling schreef:
> On Thu, Jun 7, 2012 at 1:55 AM, Maarten Lankhorst
>  wrote:
>> I haven't looked at intel and amd, but from a quick glance
>> it seems like they already implement fencing too, so just
>> some way to synch up the fences on shared buffers seems
>> like it could benefit all graphics drivers and the whole
>> userspace synching could be done away with entirely.
> It's important to have some level of userspace API so that GPU
> generated graphics can participate in the graphics pipeline.  Think of
> the case where you have a software video codec streaming textures into
> the GPU.  It needs to know when the GPU is done with those textures so
> it can reuse the buffer.
>
In the graphics case this problem already has to be handled without
dma-buf, so adding any extra synchronization api for userspace
that is only used when the bo is shared is a waste.

I do agree you need some way to synch userspace though, but I
think adding a new api for userspace is not the way to go.

Cheers,
Maarten

PS: re-added cc's that seem to have fallen off from your mail.

[PATCH] v4l2: vb2: use dma_get_sgtable

[Subash Patel]

This is patch to remove vb2_dc_kaddr_to_pages() function with dma_get_sgtable()
in the patch set posted by Tomasz. It was observed that the former function
fails to get the pages, as follow_pfn() can fail for remapped kernel va provided
by the dma-mapping sub-system.

As Tomasz mentioned, the later call was temporary patch until dma-mapping author
finalizes the implementation of dma_get_sgtable(). One can use this patch to use
this vb2 patch-set for his/her work in the meantime.

Signed-off-by: Subash Patel 
---
 drivers/media/video/videobuf2-dma-contig.c |   53 ++-
 1 files changed, 4 insertions(+), 49 deletions(-)

diff --git a/drivers/media/video/videobuf2-dma-contig.c 
b/drivers/media/video/videobuf2-dma-contig.c
index e8da7f1..1b9023a 100644
--- a/drivers/media/video/videobuf2-dma-contig.c
+++ b/drivers/media/video/videobuf2-dma-contig.c
@@ -143,32 +143,11 @@ static void vb2_dc_put(void *buf_priv)
kfree(buf);
 }

-static int vb2_dc_kaddr_to_pages(unsigned long kaddr,
-   struct page **pages, unsigned int n_pages)
-{
-   unsigned int i;
-   unsigned long pfn;
-   struct vm_area_struct vma = {
-   .vm_flags = VM_IO | VM_PFNMAP,
-   .vm_mm = current->mm,
-   };
-
-   for (i = 0; i < n_pages; ++i, kaddr += PAGE_SIZE) {
-   if (follow_pfn(, kaddr, ))
-   break;
-   pages[i] = pfn_to_page(pfn);
-   }
-
-   return i;
-}
-
 static void *vb2_dc_alloc(void *alloc_ctx, unsigned long size)
 {
struct device *dev = alloc_ctx;
struct vb2_dc_buf *buf;
int ret = -ENOMEM;
-   int n_pages;
-   struct page **pages = NULL;

buf = kzalloc(sizeof *buf, GFP_KERNEL);
if (!buf)
@@ -183,35 +162,14 @@ static void *vb2_dc_alloc(void *alloc_ctx, unsigned long 
size)
WARN_ON((unsigned long)buf->vaddr & ~PAGE_MASK);
WARN_ON(buf->dma_addr & ~PAGE_MASK);

-   n_pages = PAGE_ALIGN(size) >> PAGE_SHIFT;
+   ret = dma_get_sgtable(dev, >sgt_base, buf->vaddr,
+   buf->dma_addr, size, NULL);

-   pages = kmalloc(n_pages * sizeof pages[0], GFP_KERNEL);
-   if (!pages) {
-   dev_err(dev, "failed to alloc page table\n");
-   goto fail_dma;
-   }
-
-   ret = vb2_dc_kaddr_to_pages((unsigned long)buf->vaddr, pages, n_pages);
if (ret < 0) {
-   dev_err(dev, "failed to get buffer pages from DMA API\n");
-   goto fail_pages;
-   }
-   if (ret != n_pages) {
-   ret = -EFAULT;
-   dev_err(dev, "failed to get all pages from DMA API\n");
-   goto fail_pages;
-   }
-
-   ret = sg_alloc_table_from_pages(>sgt_base,
-   pages, n_pages, 0, size, GFP_KERNEL);
-   if (ret) {
-   dev_err(dev, "failed to prepare sg table\n");
-   goto fail_pages;
+   dev_err(dev, "failed to get the SGT for the allocated pages\n");
+   goto fail_dma;
}

-   /* pages are no longer needed */
-   kfree(pages);
-
buf->dev = dev;
buf->size = size;

@@ -223,9 +181,6 @@ static void *vb2_dc_alloc(void *alloc_ctx, unsigned long 
size)

return buf;

-fail_pages:
-   kfree(pages);
-
 fail_dma:
dma_free_coherent(dev, size, buf->vaddr, buf->dma_addr);

-- 
1.7.5.4


--080106050707070506020705--

[Bug 50655] ATI RV670 [Radeon HD 3870] Ioquake games causes GPU lockup (waiting for 0x00003039 last fence id 0x00003030)

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

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

--- Comment #14 from Marek Ol??k  2012-06-07 09:19:52 PDT 
---
(In reply to comment #11)
> Marek, any ideas? (bug 47116 might be related)

Sorry I've got none. All the regs were really invariant at the time I wrote the
commit. A hardware bug like Alex suggested is one possible explanation...

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

psb_gfx removal

[Alan Cox]

On Thu, 7 Jun 2012 15:53:43 +0200 (CEST)
Jan Engelhardt  wrote:

> On Tuesday 2012-06-05 18:29, Alan Cox wrote:
> >> 
> >> [Wortmann AG's terra Pad 1051, with a 8086:4102 display chip]
> >
> >0x4102 is an Oaktrail device (GMA600). The driver supports it
> >providing you have the GMA600 option set.
> 
> Thanks for the info. Setting GMA600=y works, as in, it results
> in graphical mode on tty1.
> 
> However, the gma600 driver seems to default to a backlight value of
> "0" in Linux 3.4.1; getting a dark screen after loading gma500_gfx.ko 
> is rather unexpected.

The ACPI and GMA code fall out over the backlight somewhat. I had hoped
to fix it in 3.5-rc but Linus threw out all the ACPI tree changes.

Disable ACPI video in your configuration and see if it behaves
properly. If not then it will need chasing down in more detail.

Alan

[PATCH 12/12] agp/intel-agp: remove snb+ host bridge pciids

[Daniel Vetter]

drm/i915 now takes care itself of setting up the gtt for
these chips.

Signed-off-by: Daniel Vetter 
---
 drivers/char/agp/intel-agp.c |   11 ---
 1 files changed, 0 insertions(+), 11 deletions(-)

diff --git a/drivers/char/agp/intel-agp.c b/drivers/char/agp/intel-agp.c
index c98c568..39c4a8f 100644
--- a/drivers/char/agp/intel-agp.c
+++ b/drivers/char/agp/intel-agp.c
@@ -902,17 +902,6 @@ static struct pci_device_id agp_intel_pci_table[] = {
ID(PCI_DEVICE_ID_INTEL_IRONLAKE_M_HB),
ID(PCI_DEVICE_ID_INTEL_IRONLAKE_MA_HB),
ID(PCI_DEVICE_ID_INTEL_IRONLAKE_MC2_HB),
-   ID(PCI_DEVICE_ID_INTEL_SANDYBRIDGE_HB),
-   ID(PCI_DEVICE_ID_INTEL_SANDYBRIDGE_M_HB),
-   ID(PCI_DEVICE_ID_INTEL_SANDYBRIDGE_S_HB),
-   ID(PCI_DEVICE_ID_INTEL_IVYBRIDGE_HB),
-   ID(PCI_DEVICE_ID_INTEL_IVYBRIDGE_M_HB),
-   ID(PCI_DEVICE_ID_INTEL_IVYBRIDGE_S_HB),
-   ID(PCI_DEVICE_ID_INTEL_VALLEYVIEW_HB),
-   ID(PCI_DEVICE_ID_INTEL_HASWELL_HB),
-   ID(PCI_DEVICE_ID_INTEL_HASWELL_M_HB),
-   ID(PCI_DEVICE_ID_INTEL_HASWELL_S_HB),
-   ID(PCI_DEVICE_ID_INTEL_HASWELL_E_HB),
{ }
 };

-- 
1.7.7.6

[PATCH 11/12] drm/i915: call intel_enable_gtt

[Daniel Vetter]

When drm/i915 is in control of the gtt, we need to call
the enable function at all the relevant places ourselves.

Signed-off-by: Daniel Vetter 
---
 drivers/char/agp/intel-gtt.c|3 ++-
 drivers/gpu/drm/i915/i915_gem.c |3 +++
 include/drm/intel-gtt.h |2 ++
 3 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index 440e8d4..7397001 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -777,7 +777,7 @@ static void i830_write_entry(dma_addr_t addr, unsigned int 
entry,
writel(addr | pte_flags, intel_private.gtt + entry);
 }

-static bool intel_enable_gtt(void)
+bool intel_enable_gtt(void)
 {
u8 __iomem *reg;

@@ -823,6 +823,7 @@ static bool intel_enable_gtt(void)

return true;
 }
+EXPORT_SYMBOL(intel_enable_gtt);

 static int i830_setup(void)
 {
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 108e4c2..2884b08 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3689,6 +3689,9 @@ i915_gem_init_hw(struct drm_device *dev)
drm_i915_private_t *dev_priv = dev->dev_private;
int ret;

+   if (!intel_enable_gtt())
+   return -EIO;
+
i915_gem_l3_remap(dev);

i915_gem_init_swizzling(dev);
diff --git a/include/drm/intel-gtt.h b/include/drm/intel-gtt.h
index 84ebd71..8e29d55 100644
--- a/include/drm/intel-gtt.h
+++ b/include/drm/intel-gtt.h
@@ -27,6 +27,8 @@ int intel_gmch_probe(struct pci_dev *bridge_pdev, struct 
pci_dev *gpu_pdev,
 struct agp_bridge_data *bridge);
 void intel_gmch_remove(void);

+bool intel_enable_gtt(void);
+
 void intel_gtt_chipset_flush(void);
 void intel_gtt_unmap_memory(struct scatterlist *sg_list, int num_sg);
 void intel_gtt_clear_range(unsigned int first_entry, unsigned int num_entries);
-- 
1.7.7.6

[PATCH 10/12] agp/intel-gtt: move gart base addres setup

[Daniel Vetter]

We need this thing much earlier, and it doesn't make sense
in the hw enabling function intel_enable_gtt - this does not
change over a suspend/resume cycle ...

Signed-off-by: Daniel Vetter 
---
 drivers/char/agp/intel-gtt.c |   20 ++--
 1 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index 6499290..440e8d4 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -648,6 +648,7 @@ static void intel_gtt_cleanup(void)

 static int intel_gtt_init(void)
 {
+   u32 gma_addr;
u32 gtt_map_size;
int ret;

@@ -694,6 +695,15 @@ static int intel_gtt_init(void)
return ret;
}

+   if (INTEL_GTT_GEN <= 2)
+   pci_read_config_dword(intel_private.pcidev, I810_GMADDR,
+ _addr);
+   else
+   pci_read_config_dword(intel_private.pcidev, I915_GMADDR,
+ _addr);
+
+   intel_private.base.gma_bus_addr = (gma_addr & 
PCI_BASE_ADDRESS_MEM_MASK);
+
return 0;
 }

@@ -769,18 +779,8 @@ static void i830_write_entry(dma_addr_t addr, unsigned int 
entry,

 static bool intel_enable_gtt(void)
 {
-   u32 gma_addr;
u8 __iomem *reg;

-   if (INTEL_GTT_GEN <= 2)
-   pci_read_config_dword(intel_private.pcidev, I810_GMADDR,
- _addr);
-   else
-   pci_read_config_dword(intel_private.pcidev, I915_GMADDR,
- _addr);
-
-   intel_private.base.gma_bus_addr = (gma_addr & 
PCI_BASE_ADDRESS_MEM_MASK);
-
if (INTEL_GTT_GEN >= 6)
return true;

-- 
1.7.7.6

[PATCH 09/12] drm/i915: don't check intel_agp_enabled any more

[Daniel Vetter]

We won't enabled agp unconditionally. Furthermore we do have
the right checks for agp support in place in our ->load
function.

The only thing this variable still does is enforce the module
load order we want (and I'm not even sure whether it succeeds
for that). Hence just use it in a harmless place somewhere.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_dma.c |6 +-
 drivers/gpu/drm/i915/i915_drv.c |6 --
 2 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 29aee99..e21b3ff 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1404,6 +1404,8 @@ i915_mtrr_setup(struct drm_i915_private *dev_priv, 
unsigned long base,
}
 }

+extern int intel_agp_enabled;
+
 /**
  * i915_driver_load - setup chip and create an initial config
  * @dev: DRM device
@@ -1451,7 +1453,9 @@ int i915_driver_load(struct drm_device *dev, unsigned 
long flags)
return ret;

if (!dev->agp) {
-   DRM_ERROR("Cannot initialize the agpgart module.\n");
+   DRM_ERROR("Cannot initialize the agpgart module,"
+ "intel_agp_enabled: %i.\n",
+ intel_agp_enabled);
return -EINVAL;
}
}
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 818e3c7..1bf7597 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -119,7 +119,6 @@ MODULE_PARM_DESC(i915_enable_ppgtt,
"Enable PPGTT (default: true)");

 static struct drm_driver driver;
-extern int intel_agp_enabled;

 #define INTEL_VGA_DEVICE(id, info) {   \
.class = PCI_BASE_CLASS_DISPLAY << 16,  \
@@ -1091,11 +1090,6 @@ static struct pci_driver i915_pci_driver = {

 static int __init i915_init(void)
 {
-   if (!intel_agp_enabled) {
-   DRM_ERROR("drm/i915 can't work without intel_agp module!\n");
-   return -ENODEV;
-   }
-
driver.num_ioctls = i915_max_ioctl;

/*
-- 
1.7.7.6

[PATCH 08/12] drm/i915 + agp/intel-gtt: prep work for direct setup

[Daniel Vetter]

To be able to directly set up the intel-gtt code from drm/i915 and
avoid setting up the fake-agp driver we need to prepare a few things:
- pass both the bridge and gpu pci_dev to the probe function and add
  code to handle the gpu pdev both being present (for drm/i915) and
  not present (fake agp).
- add refcounting to the remove function so that unloading drm/i915
  doesn't kill the fake agp driver

Signed-Off-by: Daniel Vetter 
---
 drivers/char/agp/intel-agp.c|5 +++--
 drivers/char/agp/intel-agp.h|3 ---
 drivers/char/agp/intel-gtt.c|   38 ++
 drivers/gpu/drm/i915/i915_dma.c |   13 +++--
 include/drm/intel-gtt.h |4 
 5 files changed, 48 insertions(+), 15 deletions(-)

diff --git a/drivers/char/agp/intel-agp.c b/drivers/char/agp/intel-agp.c
index 764f70c..c98c568 100644
--- a/drivers/char/agp/intel-agp.c
+++ b/drivers/char/agp/intel-agp.c
@@ -12,6 +12,7 @@
 #include 
 #include "agp.h"
 #include "intel-agp.h"
+#include 

 int intel_agp_enabled;
 EXPORT_SYMBOL(intel_agp_enabled);
@@ -747,7 +748,7 @@ static int __devinit agp_intel_probe(struct pci_dev *pdev,

bridge->capndx = cap_ptr;

-   if (intel_gmch_probe(pdev, bridge))
+   if (intel_gmch_probe(pdev, NULL, bridge))
goto found_gmch;

for (i = 0; intel_agp_chipsets[i].name != NULL; i++) {
@@ -824,7 +825,7 @@ static void __devexit agp_intel_remove(struct pci_dev *pdev)

agp_remove_bridge(bridge);

-   intel_gmch_remove(pdev);
+   intel_gmch_remove();

agp_put_bridge(bridge);
 }
diff --git a/drivers/char/agp/intel-agp.h b/drivers/char/agp/intel-agp.h
index c009175..cf2e764 100644
--- a/drivers/char/agp/intel-agp.h
+++ b/drivers/char/agp/intel-agp.h
@@ -250,7 +250,4 @@
 #define PCI_DEVICE_ID_INTEL_HASWELL_SDV0x0c16 /* SDV */
 #define PCI_DEVICE_ID_INTEL_HASWELL_E_HB   0x0c04

-int intel_gmch_probe(struct pci_dev *pdev,
-  struct agp_bridge_data *bridge);
-void intel_gmch_remove(struct pci_dev *pdev);
 #endif
diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index 5e6c89e..6499290 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -75,6 +75,7 @@ static struct _intel_private {
struct resource ifp_resource;
int resource_valid;
struct page *scratch_page;
+   int refcount;
 } intel_private;

 #define INTEL_GTT_GEN  intel_private.driver->gen
@@ -1522,14 +1523,32 @@ static int find_gmch(u16 device)
return 1;
 }

-int intel_gmch_probe(struct pci_dev *pdev,
- struct agp_bridge_data *bridge)
+int intel_gmch_probe(struct pci_dev *bridge_pdev, struct pci_dev *gpu_pdev,
+struct agp_bridge_data *bridge)
 {
int i, mask;
-   intel_private.driver = NULL;
+
+   /*
+* Can be called from the fake agp driver but also directly from
+* drm/i915.ko. Hence we need to check whether everything is set up
+* already.
+*/
+   if (intel_private.driver) {
+   intel_private.refcount++;
+   return 1;
+   }

for (i = 0; intel_gtt_chipsets[i].name != NULL; i++) {
-   if (find_gmch(intel_gtt_chipsets[i].gmch_chip_id)) {
+   if (gpu_pdev) {
+   if (gpu_pdev->device ==
+   intel_gtt_chipsets[i].gmch_chip_id) {
+   intel_private.pcidev = pci_dev_get(gpu_pdev);
+   intel_private.driver =
+   intel_gtt_chipsets[i].gtt_driver;
+
+   break;
+   }
+   } else if (find_gmch(intel_gtt_chipsets[i].gmch_chip_id)) {
intel_private.driver =
intel_gtt_chipsets[i].gtt_driver;
break;
@@ -1542,12 +1561,12 @@ int intel_gmch_probe(struct pci_dev *pdev,
if (bridge) {
bridge->driver = _fake_agp_driver;
bridge->dev_private_data = _private;
-   bridge->dev = pdev;
+   bridge->dev = bridge_pdev;
}

-   intel_private.bridge_dev = pci_dev_get(pdev);
+   intel_private.bridge_dev = pci_dev_get(bridge_pdev);

-   dev_info(>dev, "Intel %s Chipset\n", intel_gtt_chipsets[i].name);
+   dev_info(_pdev->dev, "Intel %s Chipset\n", 
intel_gtt_chipsets[i].name);

mask = intel_private.driver->dma_mask_size;
if (pci_set_dma_mask(intel_private.pcidev, DMA_BIT_MASK(mask)))
@@ -1577,8 +1596,11 @@ void intel_gtt_chipset_flush(void)
 }
 EXPORT_SYMBOL(intel_gtt_chipset_flush);

-void intel_gmch_remove(struct pci_dev *pdev)
+void intel_gmch_remove(void)
 {
+   if (--intel_private.refcount)
+   return;
+
if (intel_private.pcidev)
pci_dev_put(intel_private.pcidev);
if 

[PATCH 07/12] drm/i915: only enable drm agp support when required

[Daniel Vetter]

We need it for all things ums (which essentially only means up to
gen5) and to support b0rked XvMC userspace on gen3.

Signed-Off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_dma.c |   21 -
 1 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index e4203df..0ab5d3d 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1422,15 +1422,6 @@ int i915_driver_load(struct drm_device *dev, unsigned 
long flags)
int ret = 0, mmio_bar;
uint32_t aperture_size;

-   ret = drm_pci_agp_init(dev);
-   if (ret)
-   return ret;
-
-   if (!dev->agp) {
-   DRM_ERROR("Cannot initialize the agpgart module.\n");
-   return -EINVAL;
-   }
-
info = (struct intel_device_info *) flags;

/* Refuse to load on gen6+ without kms enabled. */
@@ -1453,6 +1444,18 @@ int i915_driver_load(struct drm_device *dev, unsigned 
long flags)
dev_priv->dev = dev;
dev_priv->info = info;

+   if (!drm_core_check_feature(dev, DRIVER_MODESET) ||
+   IS_GEN3(dev)) {
+   ret = drm_pci_agp_init(dev);
+   if (ret)
+   return ret;
+
+   if (!dev->agp) {
+   DRM_ERROR("Cannot initialize the agpgart module.\n");
+   return -EINVAL;
+   }
+   }
+
if (i915_get_bridge_dev(dev)) {
ret = -EIO;
goto free_priv;
-- 
1.7.7.6

[PATCH 06/12] agp/intel-gtt: don't require the agp bridge on setup

[Daniel Vetter]

We only need it to fake the agp interface and don't actually
use it in the driver anywhere. Hence conditionalize that.

This is just a prep patch to eventually disable the fake agp
driver on gen6+.

Signed-off-by: Daniel Vetter 
---
 drivers/char/agp/intel-gtt.c |8 +---
 1 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index 2aab0a0..5e6c89e 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -1539,9 +1539,11 @@ int intel_gmch_probe(struct pci_dev *pdev,
if (!intel_private.driver)
return 0;

-   bridge->driver = _fake_agp_driver;
-   bridge->dev_private_data = _private;
-   bridge->dev = pdev;
+   if (bridge) {
+   bridge->driver = _fake_agp_driver;
+   bridge->dev_private_data = _private;
+   bridge->dev = pdev;
+   }

intel_private.bridge_dev = pci_dev_get(pdev);

-- 
1.7.7.6

[PATCH 05/12] drm/i915: stop using dev->agp->base

[Daniel Vetter]

For that to work we need to export the base address of the gtt
mmio window from intel-gtt. Also replace all other uses of
dev->agp by values we already have at hand.

Signed-off-by: Daniel Vetter 
---
 drivers/char/agp/intel-gtt.c|5 ++---
 drivers/gpu/drm/i915/i915_dma.c |   21 +
 drivers/gpu/drm/i915/i915_drv.h |1 +
 drivers/gpu/drm/i915/i915_gem.c |2 +-
 drivers/gpu/drm/i915/i915_gem_debug.c   |3 ++-
 drivers/gpu/drm/i915/intel_display.c|2 +-
 drivers/gpu/drm/i915/intel_fb.c |4 +++-
 drivers/gpu/drm/i915/intel_ringbuffer.c |6 --
 include/drm/intel-gtt.h |2 ++
 9 files changed, 29 insertions(+), 17 deletions(-)

diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index 53c4c7f..2aab0a0 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -66,7 +66,6 @@ static struct _intel_private {
struct pci_dev *bridge_dev;
u8 __iomem *registers;
phys_addr_t gtt_bus_addr;
-   phys_addr_t gma_bus_addr;
u32 PGETBL_save;
u32 __iomem *gtt;   /* I915G */
bool clear_fake_agp; /* on first access via agp, fill with scratch */
@@ -779,7 +778,7 @@ static bool intel_enable_gtt(void)
pci_read_config_dword(intel_private.pcidev, I915_GMADDR,
  _addr);

-   intel_private.gma_bus_addr = (gma_addr & PCI_BASE_ADDRESS_MEM_MASK);
+   intel_private.base.gma_bus_addr = (gma_addr & 
PCI_BASE_ADDRESS_MEM_MASK);

if (INTEL_GTT_GEN >= 6)
return true;
@@ -860,7 +859,7 @@ static int intel_fake_agp_configure(void)
return -EIO;

intel_private.clear_fake_agp = true;
-   agp_bridge->gart_bus_addr = intel_private.gma_bus_addr;
+   agp_bridge->gart_bus_addr = intel_private.base.gma_bus_addr;

return 0;
 }
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 494b9cb..e4203df 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1085,8 +1085,8 @@ static int i915_set_status_page(struct drm_device *dev, 
void *data,

ring->status_page.gfx_addr = hws->addr & (0x1<<12);

-   dev_priv->dri1.gfx_hws_cpu_addr = ioremap_wc(dev->agp->base + hws->addr,
-4096);
+   dev_priv->dri1.gfx_hws_cpu_addr =
+   ioremap_wc(dev_priv->mm.gtt_base_addr + hws->addr, 4096);
if (dev_priv->dri1.gfx_hws_cpu_addr == NULL) {
i915_dma_cleanup(dev);
ring->status_page.gfx_addr = 0;
@@ -1491,15 +1491,18 @@ int i915_driver_load(struct drm_device *dev, unsigned 
long flags)
}

aperture_size = dev_priv->mm.gtt->gtt_mappable_entries << PAGE_SHIFT;
+   dev_priv->mm.gtt_base_addr = dev_priv->mm.gtt->gma_bus_addr;

dev_priv->mm.gtt_mapping =
-   io_mapping_create_wc(dev->agp->base, aperture_size);
+   io_mapping_create_wc(dev_priv->mm.gtt_base_addr,
+aperture_size);
if (dev_priv->mm.gtt_mapping == NULL) {
ret = -EIO;
goto out_rmmap;
}

-   i915_mtrr_setup(dev_priv, dev->agp->base, aperture_size);
+   i915_mtrr_setup(dev_priv, dev_priv->mm.gtt_base_addr,
+   aperture_size);

/* The i915 workqueue is primarily used for batched retirement of
 * requests (and thus managing bo) once the task has been completed
@@ -1611,8 +1614,9 @@ out_gem_unload:
destroy_workqueue(dev_priv->wq);
 out_mtrrfree:
if (dev_priv->mm.gtt_mtrr >= 0) {
-   mtrr_del(dev_priv->mm.gtt_mtrr, dev->agp->base,
-dev->agp->agp_info.aper_size * 1024 * 1024);
+   mtrr_del(dev_priv->mm.gtt_mtrr,
+dev_priv->mm.gtt_base_addr,
+aperture_size);
dev_priv->mm.gtt_mtrr = -1;
}
io_mapping_free(dev_priv->mm.gtt_mapping);
@@ -1649,8 +1653,9 @@ int i915_driver_unload(struct drm_device *dev)

io_mapping_free(dev_priv->mm.gtt_mapping);
if (dev_priv->mm.gtt_mtrr >= 0) {
-   mtrr_del(dev_priv->mm.gtt_mtrr, dev->agp->base,
-dev->agp->agp_info.aper_size * 1024 * 1024);
+   mtrr_del(dev_priv->mm.gtt_mtrr,
+dev_priv->mm.gtt_base_addr,
+dev_priv->mm.gtt->gtt_mappable_entries * PAGE_SIZE);
dev_priv->mm.gtt_mtrr = -1;
}

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ccabadd..ae4129b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -651,6 +651,7 @@ typedef struct drm_i915_private {
unsigned long gtt_end;

struct io_mapping *gtt_mapping;
+   phys_addr_t 

[PATCH 04/12] agp/intel-gtt: remove dead code

[Daniel Vetter]

This is a leftover from the conversion of the i81x fake agp driver
over to the new intel-gtt code layoute.

Signed-Off-by: Daniel Vetter 
---
 drivers/char/agp/intel-gtt.c |3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index 1237e75..53c4c7f 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -1556,9 +1556,6 @@ int intel_gmch_probe(struct pci_dev *pdev,
pci_set_consistent_dma_mask(intel_private.pcidev,
DMA_BIT_MASK(mask));

-   /*if (bridge->driver == _810_driver)
-   return 1;*/
-
if (intel_gtt_init() != 0)
return 0;

-- 
1.7.7.6

[PATCH 03/12] drm: kill USE_AGP driver flag

[Daniel Vetter]

All drivers that use agp call the agp_init function now directly from
their ->load callback. All other parts check for dev->agp anyway to
check whether agp is available.

This flag has therefore outlived its usefullness, kill it.

Signed-Off-by: Daniel Vetter 
---
 drivers/gpu/drm/i810/i810_drv.c   |2 +-
 drivers/gpu/drm/i915/i915_drv.c   |2 +-
 drivers/gpu/drm/mga/mga_drv.c |2 +-
 drivers/gpu/drm/nouveau/nouveau_drv.c |2 +-
 drivers/gpu/drm/r128/r128_drv.c   |2 +-
 drivers/gpu/drm/radeon/radeon_drv.c   |4 ++--
 drivers/gpu/drm/savage/savage_drv.c   |2 +-
 drivers/gpu/drm/sis/sis_drv.c |2 +-
 drivers/gpu/drm/via/via_drv.c |2 +-
 include/drm/drmP.h|6 +-
 10 files changed, 11 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i810/i810_drv.c b/drivers/gpu/drm/i810/i810_drv.c
index 6419182..148cb52 100644
--- a/drivers/gpu/drm/i810/i810_drv.c
+++ b/drivers/gpu/drm/i810/i810_drv.c
@@ -56,7 +56,7 @@ static const struct file_operations i810_driver_fops = {

 static struct drm_driver driver = {
.driver_features =
-   DRIVER_USE_AGP | DRIVER_USE_MTRR |
+   DRIVER_USE_MTRR |
DRIVER_HAVE_DMA | DRIVER_DMA_QUEUE,
.dev_priv_size = sizeof(drm_i810_buf_priv_t),
.load = i810_driver_load,
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index e98501d..818e3c7 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1038,7 +1038,7 @@ static struct drm_driver driver = {
 * deal with them for Intel hardware.
 */
.driver_features =
-   DRIVER_USE_AGP | /* DRIVER_USE_MTRR |*/
+   /* DRIVER_USE_MTRR |*/
DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM | DRIVER_PRIME,
.load = i915_driver_load,
.unload = i915_driver_unload,
diff --git a/drivers/gpu/drm/mga/mga_drv.c b/drivers/gpu/drm/mga/mga_drv.c
index f9a925d..866d07a 100644
--- a/drivers/gpu/drm/mga/mga_drv.c
+++ b/drivers/gpu/drm/mga/mga_drv.c
@@ -60,7 +60,7 @@ static const struct file_operations mga_driver_fops = {

 static struct drm_driver driver = {
.driver_features =
-   DRIVER_USE_AGP | DRIVER_USE_MTRR | DRIVER_PCI_DMA |
+   DRIVER_USE_MTRR | DRIVER_PCI_DMA |
DRIVER_HAVE_DMA | DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED,
.dev_priv_size = sizeof(drm_mga_buf_priv_t),
.load = mga_driver_load,
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.c 
b/drivers/gpu/drm/nouveau/nouveau_drv.c
index cad254c..b1dc91d 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.c
@@ -401,7 +401,7 @@ static const struct file_operations nouveau_driver_fops = {

 static struct drm_driver driver = {
.driver_features =
-   DRIVER_USE_AGP | DRIVER_PCI_DMA | DRIVER_SG |
+   DRIVER_PCI_DMA | DRIVER_SG |
DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM |
DRIVER_MODESET | DRIVER_PRIME,
.load = nouveau_load,
diff --git a/drivers/gpu/drm/r128/r128_drv.c b/drivers/gpu/drm/r128/r128_drv.c
index 22001ca..4146db4 100644
--- a/drivers/gpu/drm/r128/r128_drv.c
+++ b/drivers/gpu/drm/r128/r128_drv.c
@@ -58,7 +58,7 @@ static const struct file_operations r128_driver_fops = {

 static struct drm_driver driver = {
.driver_features =
-   DRIVER_USE_AGP | DRIVER_USE_MTRR | DRIVER_PCI_DMA | DRIVER_SG |
+   DRIVER_USE_MTRR | DRIVER_PCI_DMA | DRIVER_SG |
DRIVER_HAVE_DMA | DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED,
.dev_priv_size = sizeof(drm_r128_buf_priv_t),
.load = r128_driver_load,
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
b/drivers/gpu/drm/radeon/radeon_drv.c
index f0bb2b5..1cb0a02 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -239,7 +239,7 @@ static const struct file_operations radeon_driver_old_fops 
= {

 static struct drm_driver driver_old = {
.driver_features =
-   DRIVER_USE_AGP | DRIVER_USE_MTRR | DRIVER_PCI_DMA | DRIVER_SG |
+   DRIVER_USE_MTRR | DRIVER_PCI_DMA | DRIVER_SG |
DRIVER_HAVE_IRQ | DRIVER_HAVE_DMA | DRIVER_IRQ_SHARED,
.dev_priv_size = sizeof(drm_radeon_buf_priv_t),
.load = radeon_driver_load,
@@ -337,7 +337,7 @@ static const struct file_operations radeon_driver_kms_fops 
= {

 static struct drm_driver kms_driver = {
.driver_features =
-   DRIVER_USE_AGP | DRIVER_USE_MTRR | DRIVER_PCI_DMA | DRIVER_SG |
+   DRIVER_USE_MTRR | DRIVER_PCI_DMA | DRIVER_SG |
DRIVER_HAVE_IRQ | DRIVER_HAVE_DMA | DRIVER_IRQ_SHARED | DRIVER_GEM |
DRIVER_PRIME,
.dev_priv_size = 0,
diff --git a/drivers/gpu/drm/savage/savage_drv.c 
b/drivers/gpu/drm/savage/savage_drv.c
index 89afe0b..cef78aa 100644
--- a/drivers/gpu/drm/savage/savage_drv.c
+++ b/drivers/gpu/drm/savage/savage_drv.c
@@ 

[PATCH 02/12] drm: kill the REQUIRE_AGP driver flag

[Daniel Vetter]

Only i810 and i915 use this. But now that the driver's ->load function
is responsible for setting up agp, we can simply move this check in
there.

Signed-Off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_pci.c   |6 +-
 drivers/gpu/drm/i810/i810_dma.c |5 +
 drivers/gpu/drm/i810/i810_drv.c |2 +-
 drivers/gpu/drm/i915/i915_dma.c |5 +
 drivers/gpu/drm/i915/i915_drv.c |2 +-
 include/drm/drmP.h  |1 -
 6 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index 833e599..59e11e4 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -271,11 +271,7 @@ int drm_pci_agp_init(struct drm_device *dev)
if (drm_core_has_AGP(dev)) {
if (drm_pci_device_is_agp(dev))
dev->agp = drm_agp_init(dev);
-   if (drm_core_check_feature(dev, DRIVER_REQUIRE_AGP)
-   && (dev->agp == NULL)) {
-   DRM_ERROR("Cannot initialize the agpgart module.\n");
-   return -EINVAL;
-   }
+
if (drm_core_has_MTRR(dev)) {
if (dev->agp)
dev->agp->agp_mtrr =
diff --git a/drivers/gpu/drm/i810/i810_dma.c b/drivers/gpu/drm/i810/i810_dma.c
index eed1126..751d767 100644
--- a/drivers/gpu/drm/i810/i810_dma.c
+++ b/drivers/gpu/drm/i810/i810_dma.c
@@ -1204,6 +1204,11 @@ int i810_driver_load(struct drm_device *dev, unsigned 
long flags)
if (ret)
return ret;

+   if (!dev->agp) {
+   DRM_ERROR("Cannot initialize the agpgart module.\n");
+   return -EINVAL;
+   }
+
/* i810 has 4 more counters */
dev->counters += 4;
dev->types[6] = _DRM_STAT_IRQ;
diff --git a/drivers/gpu/drm/i810/i810_drv.c b/drivers/gpu/drm/i810/i810_drv.c
index ec12f7d..6419182 100644
--- a/drivers/gpu/drm/i810/i810_drv.c
+++ b/drivers/gpu/drm/i810/i810_drv.c
@@ -56,7 +56,7 @@ static const struct file_operations i810_driver_fops = {

 static struct drm_driver driver = {
.driver_features =
-   DRIVER_USE_AGP | DRIVER_REQUIRE_AGP | DRIVER_USE_MTRR |
+   DRIVER_USE_AGP | DRIVER_USE_MTRR |
DRIVER_HAVE_DMA | DRIVER_DMA_QUEUE,
.dev_priv_size = sizeof(drm_i810_buf_priv_t),
.load = i810_driver_load,
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index b97ef73..494b9cb 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1426,6 +1426,11 @@ int i915_driver_load(struct drm_device *dev, unsigned 
long flags)
if (ret)
return ret;

+   if (!dev->agp) {
+   DRM_ERROR("Cannot initialize the agpgart module.\n");
+   return -EINVAL;
+   }
+
info = (struct intel_device_info *) flags;

/* Refuse to load on gen6+ without kms enabled. */
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 238a521..e98501d 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1038,7 +1038,7 @@ static struct drm_driver driver = {
 * deal with them for Intel hardware.
 */
.driver_features =
-   DRIVER_USE_AGP | DRIVER_REQUIRE_AGP | /* DRIVER_USE_MTRR |*/
+   DRIVER_USE_AGP | /* DRIVER_USE_MTRR |*/
DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM | DRIVER_PRIME,
.load = i915_driver_load,
.unload = i915_driver_unload,
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index e3437da..9906487 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -138,7 +138,6 @@ int drm_err(const char *func, const char *format, ...);

 /* driver capabilities and requirements mask */
 #define DRIVER_USE_AGP 0x1
-#define DRIVER_REQUIRE_AGP 0x2
 #define DRIVER_USE_MTRR0x4
 #define DRIVER_PCI_DMA 0x8
 #define DRIVER_SG  0x10
-- 
1.7.7.6

[PATCH 01/12] drm: move drm_pci_agp_init into driver load functions

[Daniel Vetter]

I've done an audit of everything which is being set up between the
place where drm_pci_agp_init is called currently and where the
driver's ->load function is called. Nothing seems to depend upon
dev->agp being set up correctly.

This is one big step into squashing this giant midlayer mistaken.
Though one that drm/i915 is hurting especially: We don't need (and
want) the agp layer on many chips, but we need to decide whether we
want to enable it too early.

By moving the agp setup into the drivers control, we can do an
intelligent decision in drm/i915 whether we need agp support (for
anything ums and some horrible kms userspace on specific generations)
or whether it's not required.

Also, this allows us to rip out a bit of the agp invasion from generic
drm core code in follow-up patches.

Signed-Off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_pci.c   |2 +-
 drivers/gpu/drm/drm_stub.c  |8 
 drivers/gpu/drm/i810/i810_dma.c |6 ++
 drivers/gpu/drm/i915/i915_dma.c |4 
 drivers/gpu/drm/mga/mga_dma.c   |4 
 drivers/gpu/drm/nouveau/nouveau_state.c |4 
 drivers/gpu/drm/r128/r128_drv.c |6 ++
 drivers/gpu/drm/radeon/radeon_cp.c  |4 
 drivers/gpu/drm/radeon/radeon_kms.c |4 
 drivers/gpu/drm/savage/savage_bci.c |5 +
 drivers/gpu/drm/sis/sis_drv.c   |5 +
 drivers/gpu/drm/via/via_map.c   |4 
 include/drm/drmP.h  |5 +
 13 files changed, 48 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index 13f3d93..833e599 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -286,6 +286,7 @@ int drm_pci_agp_init(struct drm_device *dev)
}
return 0;
 }
+EXPORT_SYMBOL(drm_pci_agp_init);

 static struct drm_bus drm_pci_bus = {
.bus_type = DRIVER_BUS_PCI,
@@ -294,7 +295,6 @@ static struct drm_bus drm_pci_bus = {
.set_busid = drm_pci_set_busid,
.set_unique = drm_pci_set_unique,
.irq_by_busid = drm_pci_irq_by_busid,
-   .agp_init = drm_pci_agp_init,
 };

 /**
diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index 21bcd4a..4a4a1ed 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -289,14 +289,6 @@ int drm_fill_in_dev(struct drm_device *dev,

dev->driver = driver;

-   if (dev->driver->bus->agp_init) {
-   retcode = dev->driver->bus->agp_init(dev);
-   if (retcode)
-   goto error_out_unreg;
-   }
-
-
-
retcode = drm_ctxbitmap_init(dev);
if (retcode) {
DRM_ERROR("Cannot allocate memory for context bitmap.\n");
diff --git a/drivers/gpu/drm/i810/i810_dma.c b/drivers/gpu/drm/i810/i810_dma.c
index f920fb5..eed1126 100644
--- a/drivers/gpu/drm/i810/i810_dma.c
+++ b/drivers/gpu/drm/i810/i810_dma.c
@@ -1198,6 +1198,12 @@ static int i810_flip_bufs(struct drm_device *dev, void 
*data,

 int i810_driver_load(struct drm_device *dev, unsigned long flags)
 {
+   int ret;
+
+   ret = drm_pci_agp_init(dev);
+   if (ret)
+   return ret;
+
/* i810 has 4 more counters */
dev->counters += 4;
dev->types[6] = _DRM_STAT_IRQ;
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 97a5a58..b97ef73 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1422,6 +1422,10 @@ int i915_driver_load(struct drm_device *dev, unsigned 
long flags)
int ret = 0, mmio_bar;
uint32_t aperture_size;

+   ret = drm_pci_agp_init(dev);
+   if (ret)
+   return ret;
+
info = (struct intel_device_info *) flags;

/* Refuse to load on gen6+ without kms enabled. */
diff --git a/drivers/gpu/drm/mga/mga_dma.c b/drivers/gpu/drm/mga/mga_dma.c
index 507aa3d..549816e 100644
--- a/drivers/gpu/drm/mga/mga_dma.c
+++ b/drivers/gpu/drm/mga/mga_dma.c
@@ -394,6 +394,10 @@ int mga_driver_load(struct drm_device *dev, unsigned long 
flags)
drm_mga_private_t *dev_priv;
int ret;

+   ret = drm_pci_agp_init(dev);
+   if (ret)
+   return ret;
+
dev_priv = kzalloc(sizeof(drm_mga_private_t), GFP_KERNEL);
if (!dev_priv)
return -ENOMEM;
diff --git a/drivers/gpu/drm/nouveau/nouveau_state.c 
b/drivers/gpu/drm/nouveau/nouveau_state.c
index 19706f0..dbc881a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_state.c
+++ b/drivers/gpu/drm/nouveau/nouveau_state.c
@@ -1029,6 +1029,10 @@ int nouveau_load(struct drm_device *dev, unsigned long 
flags)
uint32_t reg0 = ~0, strap;
int ret;

+   ret = drm_pci_agp_init(dev);
+   if (ret)
+   return ret;
+
dev_priv = kzalloc(sizeof(*dev_priv), GFP_KERNEL);
if (!dev_priv) {
ret = -ENOMEM;
diff --git a/drivers/gpu/drm/r128/r128_drv.c 

[PATCH 00/12] clear up drm/agp initialization madness

[Daniel Vetter]

Hi all,

With these patches there's no more /dev/agpgart fake agp interface for drm/i915,
at least not for snb and later.

The first 3 patches rework the drm core to move agp initialization into drivers.
A nice bonus is that these remove the mid-layer stench quite a bit from drm ...

The later patches from drm/i915 and the intel agp/gtt stuff so that drm/i915 can
directly initialize the gtt support code, without the useless fake agp setup
(which at least kms/gem doesn't need at all).

Note that thanks to some horrible piece of userspace code we can't disable drm
agp support for gen3. That piece of userspace code uses the legacy drm addmap
stuff to get at it's buffers, and that requires the fake agp driver to work.

Also, we can't disable the fake agp driver on other generations before snb,
because by the time we know that we're running with kms enabled and don't
actually need it it's too late.

Obviously this is only the first part, furture patches will move the gen6+ gtt
code into drm/i915 so that we can rip out all the duplication of chipset gen
information in intel-gtt.c, too. And prepare for some neat new features ;-)

Outside of drm/i915 stuff only tested on my i815 - for some odd reason my only
agp machine left dies on 3.5-rc1, so couldn't yet beat on it with a few other
oddball drivers. But imho the first 3 patches are fairly safe (compared to some
other drm dragon slaughtering I've attempted).

Comments, flames and reviews highly welcome. If possible I'd like to get the 3
drm patches at the beginning in early for 3.6 so that we can decently test it
(and have some time to pile more stuff on top of this in drm/i915 land).

Yours, Daniel

Daniel Vetter (12):
  drm: move drm_pci_agp_init into driver load functions
  drm: kill the REQUIRE_AGP driver flag
  drm: kill USE_AGP driver flag
  agp/intel-gtt: remove dead code
  drm/i915: stop using dev->agp->base
  agp/intel-gtt: don't require the agp bridge on setup
  drm/i915: only enable drm agp support when required
  drm/i915 + agp/intel-gtt: prep work for direct setup
  drm/i915: don't check intel_agp_enabled any more
  agp/intel-gtt: move gart base addres setup
  drm/i915: call intel_enable_gtt
  agp/intel-agp: remove snb+ host bridge pciids

 drivers/char/agp/intel-agp.c|   16 +--
 drivers/char/agp/intel-agp.h|3 -
 drivers/char/agp/intel-gtt.c|   73 ---
 drivers/gpu/drm/drm_pci.c   |8 +---
 drivers/gpu/drm/drm_stub.c  |8 ---
 drivers/gpu/drm/i810/i810_dma.c |   11 +
 drivers/gpu/drm/i810/i810_drv.c |2 +-
 drivers/gpu/drm/i915/i915_dma.c |   50 +
 drivers/gpu/drm/i915/i915_drv.c |8 +---
 drivers/gpu/drm/i915/i915_drv.h |1 +
 drivers/gpu/drm/i915/i915_gem.c |5 ++-
 drivers/gpu/drm/i915/i915_gem_debug.c   |3 +-
 drivers/gpu/drm/i915/intel_display.c|2 +-
 drivers/gpu/drm/i915/intel_fb.c |4 +-
 drivers/gpu/drm/i915/intel_ringbuffer.c |6 ++-
 drivers/gpu/drm/mga/mga_dma.c   |4 ++
 drivers/gpu/drm/mga/mga_drv.c   |2 +-
 drivers/gpu/drm/nouveau/nouveau_drv.c   |2 +-
 drivers/gpu/drm/nouveau/nouveau_state.c |4 ++
 drivers/gpu/drm/r128/r128_drv.c |8 +++-
 drivers/gpu/drm/radeon/radeon_cp.c  |4 ++
 drivers/gpu/drm/radeon/radeon_drv.c |4 +-
 drivers/gpu/drm/radeon/radeon_kms.c |4 ++
 drivers/gpu/drm/savage/savage_bci.c |5 ++
 drivers/gpu/drm/savage/savage_drv.c |2 +-
 drivers/gpu/drm/sis/sis_drv.c   |7 +++-
 drivers/gpu/drm/via/via_drv.c   |2 +-
 drivers/gpu/drm/via/via_map.c   |4 ++
 include/drm/drmP.h  |   12 +
 include/drm/intel-gtt.h |8 +++
 30 files changed, 174 insertions(+), 98 deletions(-)

-- 
1.7.7.6

psb_gfx removal

[Jan Engelhardt]

On Tuesday 2012-06-05 18:29, Alan Cox wrote:
>> 
>> [Wortmann AG's terra Pad 1051, with a 8086:4102 display chip]
>
>0x4102 is an Oaktrail device (GMA600). The driver supports it providing
>you have the GMA600 option set.

Thanks for the info. Setting GMA600=y works, as in, it results
in graphical mode on tty1.

However, the gma600 driver seems to default to a backlight value of
"0" in Linux 3.4.1; getting a dark screen after loading gma500_gfx.ko 
is rather unexpected.

Furthermore, there are four entries in sysfs, and the one required to
change the panel brightness is acpi_video2 (and this one alone).
Changing any others, e.g. acpi_video0/brightness, does not have any
visible effect.

linux-kisn:/sys/class/backlight # ls -l
total 0
lrwxrwxrwx 1 root root 0 Jun  7 17:31 acpi_video0 -> 
../../devices/pci:00/:00:02.0/backlight/acpi_video0
lrwxrwxrwx 1 root root 0 Jun  7 17:31 acpi_video1 -> 
../../devices/pci:00/:00:02.0/backlight/acpi_video1
lrwxrwxrwx 1 root root 0 Jun  7 17:31 acpi_video2 -> 
../../devices/pci:00/:00:02.0/backlight/acpi_video2
lrwxrwxrwx 1 root root 0 Jun  7 17:31 oaktrail-bl -> 
../../devices/virtual/backlight/oaktrail-bl

edp backtrace spam on MacBookAir4,1

[Daniel Vetter]

On Thu, Jun 07, 2012 at 09:26:23AM +0200, Daniel Vetter wrote:
> On Thu, Jun 07, 2012 at 09:21:20AM +0200, Daniel Vetter wrote:
> > Meh, I've been totally blind. Note to self: Next time around actually look
> > at the backtrace. And I dunno how that escaped our dear QA that long ...
> 
> Even more meh, this patch might actually work a bit better.
> 
> /me doesn't have an edp panel to test this

Please disregard this patch, too, QA says it's not yet working. And after
some more reading of the various codepaths I agree.

/me goes back to the drawing board.
-Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[Bug 50655] ATI RV670 [Radeon HD 3870] Ioquake games causes GPU lockup (waiting for 0x00003039 last fence id 0x00003030)

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

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

--- Comment #13 from Alex Deucher  2012-06-07 07:20:16 PDT 
---
IIRC, the fix is to always re-emit a CB reg between draw calls if some other
state changed.

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

[Bug 50655] ATI RV670 [Radeon HD 3870] Ioquake games causes GPU lockup (waiting for 0x00003039 last fence id 0x00003030)

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

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

--- Comment #12 from Alex Deucher  2012-06-07 07:16:57 PDT 
---
I think I know what's going on here.  There's a hw bug on r6xx where you need
to re-emit a CB register if some state further up the pipeline changes even if
the CB state has not changed.  I remember fixing it in r600c, but I can't find
the commit...

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

[PATCH libdrm 8/8] proptest: support plane properties

[Joonyoung Shim]

Hi, Rob.

On 06/06/2012 03:06 AM, Rob Clark wrote:
> From: Rob Clark
>
> Add support to display plane properties.

Do you not support to set property for plane?

>
> Signed-off-by: Rob Clark
> ---
>   tests/proptest/proptest.c |   32 
>   1 file changed, 32 insertions(+)
>
> diff --git a/tests/proptest/proptest.c b/tests/proptest/proptest.c
> index fa34a48..aac6b8f 100644
> --- a/tests/proptest/proptest.c
> +++ b/tests/proptest/proptest.c
> @@ -39,6 +39,7 @@
>
>   int fd;
>   drmModeResPtr res = NULL;
> +drmModePlaneResPtr plane_res = NULL;
>
>   const char *connector_type_str(uint32_t type)
>   {
> @@ -239,10 +240,33 @@ static void listCrtcProperties(void)
>   }
>   }
>
> +static void listPlaneProperties(void)
> +{
> + int i;
> + drmModePlanePtr p;
> +
> + for (i = 0; i<  plane_res->count_planes; i++) {
> + p = drmModeGetPlane(fd, plane_res->planes[i]);
> +
> + if (!p) {
> + fprintf(stderr, "Could not get plane %u: %s\n",
> + plane_res->planes[i], strerror(errno));
> + continue;
> + }
> +
> + printf("Plane %u\n", p->plane_id);
> +
> + listObjectProperties(p->plane_id, DRM_MODE_OBJECT_PLANE);
> +
> + drmModeFreePlane(p);
> + }
> +}
> +
>   static void listAllProperties(void)
>   {
>   listConnectorProperties();
>   listCrtcProperties();
> + listPlaneProperties();
>   }
>
>   static int setProperty(char *argv[])
> @@ -309,6 +333,14 @@ int main(int argc, char *argv[])
>   goto done;
>   }
>
> + plane_res = drmModeGetPlaneResources(fd);
> + if (!plane_res) {
> + fprintf(stderr, "Failed to get plane resources: %s\n",
> + strerror(errno));
> + ret = 1;
> + goto done;
> + }
> +
>   if (argc<  2) {
>   listAllProperties();
>   } else if (argc == 5) {

[PATCH libdrm 3/8] tests: add proptest

[Joonyoung Shim]

Hi, Rob and Paulo.

On 06/06/2012 03:06 AM, Rob Clark wrote:
> From: Paulo Zanoni
>
> A small program that allows us to see and modify properties.
>
> Reviewed-by: Rob Clark
> Signed-off-by: Paulo Zanoni
> ---
>   configure.ac   |1 +
>   tests/Makefile.am  |2 +-
>   tests/proptest/Makefile.am |   11 ++
>   tests/proptest/proptest.c  |  317 
> 
>   4 files changed, 330 insertions(+), 1 deletion(-)
>   create mode 100644 tests/proptest/Makefile.am
>   create mode 100644 tests/proptest/proptest.c
>
> diff --git a/configure.ac b/configure.ac
> index e6e9a9f..73558ce 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -329,6 +329,7 @@ AC_CONFIG_FILES([
>   tests/modeprint/Makefile
>   tests/modetest/Makefile
>   tests/kmstest/Makefile
> + tests/proptest/Makefile
>   tests/radeon/Makefile
>   tests/vbltest/Makefile
>   include/Makefile
> diff --git a/tests/Makefile.am b/tests/Makefile.am
> index a3a59bd..1442854 100644
> --- a/tests/Makefile.am
> +++ b/tests/Makefile.am
> @@ -10,7 +10,7 @@ check_PROGRAMS = \
>   dristat \
>   drmstat
>
> -SUBDIRS = modeprint
> +SUBDIRS = modeprint proptest
>
>   if HAVE_LIBKMS
>   SUBDIRS += kmstest modetest
> diff --git a/tests/proptest/Makefile.am b/tests/proptest/Makefile.am
> new file mode 100644
> index 000..f81a3c0
> --- /dev/null
> +++ b/tests/proptest/Makefile.am
> @@ -0,0 +1,11 @@
> +AM_CFLAGS = \
> + -I$(top_srcdir)/include/drm \
> + -I$(top_srcdir)
> +
> +noinst_PROGRAMS = \
> + proptest
> +
> +proptest_SOURCES = \
> + proptest.c
> +proptest_LDADD = \
> + $(top_builddir)/libdrm.la
> diff --git a/tests/proptest/proptest.c b/tests/proptest/proptest.c
> new file mode 100644
> index 000..52896fe
> --- /dev/null
> +++ b/tests/proptest/proptest.c
> @@ -0,0 +1,317 @@
> +/*
> + * Copyright (c) 2012 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
> DEALINGS
> + * IN THE SOFTWARE.
> + *
> + * Authors:
> + *Paulo Zanoni
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "xf86drm.h"
> +#include "xf86drmMode.h"
> +
> +#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
> +
> +int fd;
> +drmModeResPtr res = NULL;
> +
> +const char *connector_type_str(uint32_t type)
> +{
> + switch (type) {
> + case DRM_MODE_CONNECTOR_Unknown:
> + return "Unknown";
> + case DRM_MODE_CONNECTOR_VGA:
> + return "VGA";
> + case DRM_MODE_CONNECTOR_DVII:
> + return "DVI-I";
> + case DRM_MODE_CONNECTOR_DVID:
> + return "DVI-D";
> + case DRM_MODE_CONNECTOR_DVIA:
> + return "DVI-A";
> + case DRM_MODE_CONNECTOR_Composite:
> + return "Composite";
> + case DRM_MODE_CONNECTOR_SVIDEO:
> + return "SVIDEO";
> + case DRM_MODE_CONNECTOR_LVDS:
> + return "LVDS";
> + case DRM_MODE_CONNECTOR_Component:
> + return "Component";
> + case DRM_MODE_CONNECTOR_9PinDIN:
> + return "9PinDin";
> + case DRM_MODE_CONNECTOR_DisplayPort:
> + return "DisplayPort";
> + case DRM_MODE_CONNECTOR_HDMIA:
> + return "HDMI-A";
> + case DRM_MODE_CONNECTOR_HDMIB:
> + return "HDMI-B";
> + case DRM_MODE_CONNECTOR_TV:
> + return "TV";
> + case DRM_MODE_CONNECTOR_eDP:
> + return "eDP";
> + default:
> + return "Invalid";
> + }
> +}
> +
> +/* dump_blob and dump_prop shamelessly copied from ../modetest/modetest.c */
> +static void
> +dump_blob(uint32_t blob_id)
> +{
> + uint32_t i;
> + unsigned char *blob_data;
> + drmModePropertyBlobPtr blob;
> +
> + blob = drmModeGetPropertyBlob(fd, blob_id);
> + if (!blob)
> + return;
> +
> + blob_data = blob->data;
> +
> + for (i = 

[Bug 50655] ATI RV670 [Radeon HD 3870] Ioquake games causes GPU lockup (waiting for 0x00003039 last fence id 0x00003030)

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

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

Alex Deucher  changed:

   What|Removed |Added

  Attachment #62476|application/octet-stream|text/plain
  mime type||

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

[Bug 50805] radeon gpu driver bug on suspend/resume in 3.5-rc1

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

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

--- Comment #1 from Alex Deucher  2012-06-07 06:36:10 PDT 
---
Can you attach your dmesg from boot and xorg log?  Also is this a regression? 
If so, can you bisect?

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

[Bug 50805] radeon gpu driver bug on suspend/resume in 3.5-rc1

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

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

Alex Deucher  changed:

   What|Removed |Added

  Attachment #62685|text/x-log  |text/plain
  mime type||

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

[Linaro-mm-sig] [RFC] Synchronizing access to buffers shared with dma-buf between drivers/devices

[Tom Cooksey]

> >>>?The bigger issue is the previous point about how to deal
> >>> with cases where the CPU doesn't really need to get involved as an
> >>> intermediary.
> >>>
> >>> CPU fallback access to the buffer is the only legit case where we
> >>> need a standardized API to userspace (since CPU access isn't already
> >>> associated w/ some other kernel device file where some extra ioctl
> >>> can be added)
> >>
> >> The CPU case will still need to wait on an arbitrarily backed sync
> >> primitive. ?It shouldn't need to know if it's backed by the gpu,
> >> camera, or dsp.
> >
> > Right, this is the one place we definitely need something.. some
> > userspace code would just get passed a dmabuf file descriptor and
> > want to mmap it and do something, without really knowing where it
> > came from. ?I *guess* we'll have to add some ioctl's to the dmabuf
> > fd.
> 
> I personally favor having sync primitives have their own anon inode
> vs. strictly coupling them with dma_buf.

I think this is really the crux of the matter - do we associate sync
objects with buffers or not. The approach ARM are suggesting _is_ to
associate the sync objects with the buffer and do this by adding
kds_resource* as a member of struct dma_buf. The main reason I want
to do this is because it doesn't require changes to existing
interfaces. Specifically, DRM/KMS & v4l2. These user/kernel interfaces
already allow userspace to specify the handle of a buffer the driver
should perform an operation on. What dma_buf has done is allowed those
driver-specific buffer handles to be exported from one driver and
imported into another. While new ioctls have been added to the v4l2 &
DRM interfaces for dma_buf, they have only been to allow the import &
export of driver-specific buffer objects. Once imported as a driver
specific buffer object, existing ioctls are re-used to perform
operations on those buffers (at least this is what PRIME does for DRM,
I'm not so sure about v4l2?). But my point is that no new "page flip
to this dma_buf fd" ioctl has been added to KMS, you use the existing
drm_mode_crtc_page_flip and specify an fb_id which has been imported
from a dma_buf.

If we associate sync objects with buffers, none of those device
specific ioctls which perform operations on buffer objects need to
be modified. It's just that internally, those drivers use kds or
something similar to make sure they don't tread on each other's
toes.

The alternate is to not associate sync objects with buffers and
have them be distinct entities, exposed to userspace. This gives
userpsace more power and flexibility and might allow for use-cases
which an implicit synchronization mechanism can't satisfy - I'd
be curious to know any specifics here. However, every driver which
needs to participate in the synchronization mechanism will need
to have its interface with userspace modified to allow the sync
objects to be passed to the drivers. This seemed like a lot of
work to me, which is why I prefer the implicit approach. However
I don't actually know what work is needed and think it should be
explored. I.e. How much work is it to add explicit sync object
support to the DRM & v4l2 interfaces?

E.g. I believe DRM/GEM's job dispatch API is "in-order"
in which case it might be easy to just add "wait for this fence"
and "signal this fence" ioctls. Seems like vmwgfx already has
something similar to this already? Could this work over having
to specify a list of sync objects to wait on and another list
of sync objects to signal for every operation (exec buf/page
flip)? What about for v4l2?

I guess my other thought is that implicit vs explicit is not
mutually exclusive, though I'd guess there'd be interesting
deadlocks to have to debug if both were in use _at the same
time_. :-)


Cheers,

Tom

[Linaro-mm-sig] [PATCHv6 00/13] Integration of videobuf2 with dmabuf

[Sylwester Nawrocki]

Hi,

On 06/07/2012 08:43 AM, Hans Verkuil wrote:
> On Thu June 7 2012 02:52:06 Laurent Pinchart wrote:
>> On Wednesday 06 June 2012 10:17:03 Hans Verkuil wrote:
>>> On Wed 6 June 2012 05:46:34 Laurent Pinchart wrote:
 On Monday 04 June 2012 12:34:23 Rebecca Schultz Zavin wrote:
> I have a system where the data is planar, but the kernel drivers
> expect to get one allocation with offsets for the planes.  I can't
> figure out how to do that with the current dma_buf implementation.  I
> thought I could pass the same dma_buf several times and use the
> data_offset field of the v4l2_plane struct but it looks like that's
> only for output.  Am I missing something?  Is this supported?

 data_offset is indeed for video output only at the moment, and doesn't
 seem to be used by any driver in mainline for now.
>>>
>>> Actually, data_offset may be set by capture drivers. For output buffers it
>>> is set by userspace, for capture buffers it is set by the driver. This
>>> data_offset typically contains meta data.
>>
>> Is that documented somewhere ? I wasn't aware of this use case.
> 
> It is documented in the proposal that Pawel sent, but very poorly if at all in
> the spec. That needs to be improved.
> 
 I can't really see a reason why data_offset couldn't be used for video
 capture devices as well.

 Sanity checks are currently missing. For output devices we should check
 that data_offset + bytesused<  length in the vb2 core. For input devices
 the check will have to be performed by drivers. Taking data_offset into
 account automatically would also be useful. I think most of that should
 be possible to implement in the allocators.
>>>
>>> See this proposal of how to solve this:
>>>
>>> http://www.spinics.net/lists/linux-media/msg40376.html
>>
>> This requires more discussions regarding how the app_offset and data_offset
>> fields should be used for the different memory types we support.
>>
>> For instance app_offset would not make that much sense for the USERPTR memory
>> type, as we can include the offset in the user pointer already (using
>> app_offset there would only make the code more complex without any added
>> benefit).
>>
>> For the MMAP memory type adding an app_offset would require allocating 
>> buffers
>> large enough to accomodate the offset, and would thus only be useful with
>> CREATE_BUFS. I'm also wondering whether the main use case (passing the buffer
>> to another device that requires that app_offset) wouldn't be better addressed
>> by the DMABUF memory type anyway.

I think what is needed is a more flexible support for multi-planar data 
formats. Currently each plane involves separate memory allocation, which
is not convenient in some use cases, at the least. For each plane a separate 
DMABUF object is needed. 

Single allocation for several data planes could be also useful for some still 
image capture use cases, where an image sensor device outputs multiple data 
at once, which can only be written into single memory region. There is 
currently no standard way to retrieve data offsets and sizes in such cases. 

It likely won't be trivial to cleanly integrate support for this with current 
V4L2 multi-plane API though.

> I'm not going to pursue this unless Google indicates that they need this. And
> actually I would suggest that they ask Pawel to work on this, after all he 
> made
> the proposal AND he works for Google :-)

--
Regards,
Sylwester

[PATCH 2/2] ALSA: hda - Fix uninitialized HDMI controllers with VGA-switcheroo

[Takashi Iwai]

When VGA-switcheroo is built in but unused on systems with multiple
graphics cards, the initializations of non-default graphics cards are
skipped and never enabled (because the switcheroo is activated only
when the controller supports).  The current behavior is for avoiding
the system lockup by accessing the disabled GPU, but due to the recent
change in VGA-switcheroo, it determines the state simply by checking
with the default VGA device.  This is the culprit.

Now with the new vga_switcheroo_get_client_state(), we can know the
initial state of the bound GPU, thus can determine the initial audio
client state more correctly.

Signed-off-by: Takashi Iwai 
---
 sound/pci/hda/hda_intel.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 2b6392b..5f0375f 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -2670,7 +2670,7 @@ static bool __devinit check_hdmi_disabled(struct pci_dev 
*pci)
struct pci_dev *p = get_bound_vga(pci);

if (p) {
-   if (vga_default_device() && p != vga_default_device())
+   if (vga_switcheroo_get_client_state(p) == VGA_SWITCHEROO_OFF)
vga_inactive = true;
pci_dev_put(p);
}
-- 
1.7.10.4

[PATCH 1/2] vga_switcheroo: Add a helper function to get the client state

[Takashi Iwai]

Add vga_switcheroo_get_client_state() to get the current state of the
client.  This is necessary to determine the proper initial state of
audio clients in HD-audio driver.

Signed-off-by: Takashi Iwai 
---
 drivers/gpu/vga/vga_switcheroo.c |   13 +
 include/linux/vga_switcheroo.h   |9 +
 2 files changed, 22 insertions(+)

diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
index 38f9534..eb4f64f 100644
--- a/drivers/gpu/vga/vga_switcheroo.c
+++ b/drivers/gpu/vga/vga_switcheroo.c
@@ -190,6 +190,19 @@ find_active_client(struct list_head *head)
return NULL;
 }

+int vga_switcheroo_get_client_state(struct pci_dev *pdev)
+{
+   struct vga_switcheroo_client *client;
+
+   client = find_client_from_pci(_priv.clients, pdev);
+   if (!client)
+   return VGA_SWITCHEROO_NOT_FOUND;
+   if (!vgasr_priv.active)
+   return VGA_SWITCHEROO_INIT;
+   return client->pwr_state;
+}
+EXPORT_SYMBOL(vga_switcheroo_get_client_state);
+
 void vga_switcheroo_unregister_client(struct pci_dev *pdev)
 {
struct vga_switcheroo_client *client;
diff --git a/include/linux/vga_switcheroo.h b/include/linux/vga_switcheroo.h
index b455c7c..661fb7a 100644
--- a/include/linux/vga_switcheroo.h
+++ b/include/linux/vga_switcheroo.h
@@ -12,6 +12,9 @@
 enum vga_switcheroo_state {
VGA_SWITCHEROO_OFF,
VGA_SWITCHEROO_ON,
+   /* below are referred only from vga_switcheroo_get_client_state() */
+   VGA_SWITCHEROO_INIT,
+   VGA_SWITCHEROO_NOT_FOUND,
 };

 enum vga_switcheroo_client_id {
@@ -50,6 +53,8 @@ void vga_switcheroo_unregister_handler(void);

 int vga_switcheroo_process_delayed_switch(void);

+int vga_switcheroo_get_client_state(struct pci_dev *dev);
+
 #else

 static inline void vga_switcheroo_unregister_client(struct pci_dev *dev) {}
@@ -62,5 +67,9 @@ static inline int vga_switcheroo_register_audio_client(struct 
pci_dev *pdev,
int id, bool active) { return 0; }
 static inline void vga_switcheroo_unregister_handler(void) {}
 static inline int vga_switcheroo_process_delayed_switch(void) { return 0; }
+static inline int vga_switcheroo_get_client_state(struct pci_dev *dev) {
+   return VGA_SWITCHEROO_CLIENT_ON;
+}
+

 #endif
-- 
1.7.10.4

[PATCH 0/2] HD-audio HDMI regression fixes with VGA-switcheroo

[Takashi Iwai]

Hi,

this is a series of patches to fix the regressions of HD-audio HDMI
on D-GPUs in 3.5-rc1 due to the support of VGA-switcheroo audio clients.

The first patch adds a new helper function to vga-switcheroo and the
second just uses that instead of an open code.

Dave, if the first patch is OK, I'm going to apply it though sound tree.
Let me know if any problem is found.

Joerg, could you check whether this doesn't break your setup, too?


thanks,

Takashi

[[REGRESSION]: hibernate/sleep regression w/ bisection] SOLVED?

[Andrew Watts]

Tejun/Jerome (and radeon devs):

I'd like to bring a suspend/resume radeon bug full circle (see:
http://thread.gmane.org/gmane.linux.kernel/1209587 for complete thread and
Tejun's excellent summary below).

The problem was triggered by new input serio driver code (commit
8ee294cd9def000 found through bisection). Don't ask me why, but that set it
off.

In a nutshell, X would intermittently lock up across suspend/resume cycles.

The issue remained at least through 3.1.5. I skipped 3.2.x altogether to
kernel 3.3.4 and confirm the problem seems to be gone.

What might have happened in the radeon codebase since 3.1.x that would have
addressed this either intentionally or as a side-effect? Maybe 721604a15b934f
or 9fc04b503df9a3?

Thanks.

~ Andy

- Forwarded message from Tejun Heo  -

Date: Fri, 4 Nov 2011 09:14:31 -0700
From: Tejun Heo 
Subject: Re: [REGRESSION]: hibernate/sleep regression w/ bisection
To: Andrew Watts 
Cc: Dmitry Torokhov , linux-kernel at 
vger.kernel.org,
linux-pm at lists.linux-foundation.org, David Airlie ,
dri-devel at lists.freedesktop.org

(cc'ing David Airlie and dri-devel)

Hello, the original thread can be read from

  http://thread.gmane.org/gmane.linux.kernel/1209587

Full sysrq-t output at

  http://article.gmane.org/gmane.linux.kernel/1211256

So, the problem is that after a seemingly unreated update to input
serio driver (convert to use workqueue), X seems to lock up
sporadically across suspend/resume cycles.

I went through the full sysrq-t output but couldn't spot anything
suspicious w/ anything else.  No worker is stuck and nobody is waiting
for flush to finish.

Stack trace for X follows.

> X   S f499b944  5800  1652   1651 0x00400080
>  f499b9a8 3086  f499b944 c100d4a4   f499b958
>   f499b9a8 f5173140 d7857c56 0057 f5173140 d8b69880 0057
>  0001  f499b9b4 c104dd89 000f4240   f499ba68
> Call Trace:
>  [] ttm_bo_wait_unreserved+0x5f/0x106
>  [] ttm_bo_reserve_locked+0xb7/0xe1
>  [] ttm_bo_reserve+0x26/0x95
>  [] radeon_crtc_do_set_base+0xbd/0x6d2
>  [] radeon_crtc_set_base+0x1b/0x1d
>  [] radeon_crtc_mode_set+0x24/0xdd7
>  [] drm_crtc_helper_set_mode+0x32c/0x48b
>  [] drm_helper_resume_force_mode+0x79/0x23e
>  [] radeon_gpu_reset+0x84/0x98
>  [] radeon_fence_wait+0x2d1/0x311
>  [] radeon_sync_obj_wait+0xc/0xe
>  [] ttm_bo_wait+0xa1/0x108
>  [] radeon_gem_wait_idle_ioctl+0x76/0xc4
>  [] drm_ioctl+0x1c2/0x42c
>  [] do_vfs_ioctl+0x79/0x54b
>  [] sys_ioctl+0x6b/0x70
>  [] sysenter_do_call+0x12/0x22

Do you guys have any ideas what's going on?  It seems to be waiting
for bo->reserved to go zero.  Is it possible that someone there is
forgetting to properly kick a work item after resume causing the wait
to stall?

Andrew, can you please kill the X server after the hang and see
whether that brings the system back?  I think sshd should still work
and if not you can write a script to kill the X server after 30secs
after resume (and kill that script if resume succeeds).

Thank you.

-- 
tejun

- End forwarded message -

[Bug 36602] Hierarchical Z support for R600

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

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

--- Comment #46 from Andy Furniss  2012-06-07 
04:19:52 PDT ---
(In reply to comment #45)
> Thanks Jerome

+1.

Getting +20% fps with etqw on my 4890.

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

[RFC] Documentation: DRM framework documentation

[Hans Verkuil]

Hi Laurent!

I completely missed this when you posted this a week ago, but thank you for
doing this. One suggestion: cross-post the next version to linux-media as well:
I think this is useful for V4L2 as well.

Some comments below:

On Wed 30 May 2012 15:13:29 Laurent Pinchart wrote:
> Signed-off-by: Laurent Pinchart 
> ---
>  Documentation/drm.txt | 1265 
> +
>  1 files changed, 1265 insertions(+), 0 deletions(-)
>  create mode 100644 Documentation/drm.txt
> 
> Hi everybody,
> 
> Here's the DRM kernel framework documentation I wrote while developing the
> Renesas SH Mobile DRM driver. It hopefully covers most of what's needed to
> write a simple DRM driver (although some areas are not documented, such as
> properties or the fbdev compatibility layer).
> 
> I can convert the documentation to DocBook if needed and integrate it with the
> existing "documentation stub". In that case I'm thinking of splitting the
> DocBook documentation in two parts, userspace API documentation (that someone
> would have to fill, any volunteer ? ;-)) and kernel API documentation. Would
> that be fine ?
> 
> Last but not least, now that documentation exists (albeit in an incomplete
> state), we need to make sure it won't get outdated too quickly. As nobody will
> volunteer to maintain it (feel free to prove me wrong though), I'd like to
> propose the same rule that we already follow in V4L: any patch that touches
> the API won't get merged if it doesn't update the documentation. Do you think
> this could work out ?

I strongly recommend that this policy is adopted. It is working out very well
in V4L2. Documentation can be a pain, but if you do it when you add new
functionality (and you still remember what it was you did :-) ), then it isn't
too bad.

> As usual, review will be appreciated.
> 
> diff --git a/Documentation/drm.txt b/Documentation/drm.txt
> new file mode 100644
> index 000..4d8843d
> --- /dev/null
> +++ b/Documentation/drm.txt
> @@ -0,0 +1,1265 @@
> + Architecture of a DRM driver
> +i
> +
> +Written by Laurent Pinchart 
> +Last revised: May 30, 2012
> +
> +
> +1. Driver initialization
> +



> +3. KMS initialization
> +-
> +
> +Drivers must first initialize the mode configuration core by calling
> +drm_mode_config_init() on the DRM device. The function initializes the
> +drm_device::mode_config field and never fails. Once done, mode configuration
> +must be setup by
> +
> +  - int min_width, min_height
> +  - int max_width, max_height
> +
> +  Minimum and maximum width and height of the frame buffers in pixel units.
> +
> +  - struct drm_mode_config_funcs *funcs
> +
> +  Basic mode setting functions. See the Mode Setting Operations section for
> +  details.
> +
> +
> +A KMS device is abstracted and exposed as a set of planes, CRTCs, encoders 
> and
> +connectors. KMS drivers must thus create and initialize all those objects at
> +load time.
> +
> +- CRCTs (struct drm_crtc)

typo: CRCT -> CRTC

> +
> +"A CRTC is an abstraction representing a part of the chip that contains a
> +pointer to a scanout buffer.

A definition of a 'scanout buffer' would be useful here. Also: what does CRTC
stand for?

In general, I think it would be good to explain abbreviations (DRM, GEM, KMS,
etc.) That way the terminology is easier to understand.

> Therefore, the number of CRTCs available
> +determines how many independent scanout buffers can be active at any given
> +time. The CRTC structure contains several fields to support this: a pointer 
> to
> +some video memory (abstracted as a frame buffer object), a display mode, and
> +an (x, y) offset into the video memory to support panning or configurations
> +where one piece of video memory spans multiple CRTCs."
> +
> +A KMS device must create and register at least one struct drm_crtc instance.
> +The instance is allocated and zeroed by the driver, possibly as part of a
> +larger structure, and registered with a call to drm_crtc_init() with a 
> pointer
> +to CRTC functions.
> +
> +- Planes (struct drm_plane)
> +
> +A plane represents an image source that can be blended with or overlayed on
> +top of a CRTC during the scanout process. Planes are associated with a frame
> +buffer to crop a portion of the image memory (source) and optionally scale it
> +to a destination size. The result is then blended with or overlayed on top of
> +a CRTC.
> +
> +Planes are optional. To create a plane, a KMS drivers allocates and zeroes an
> +instances of struct drm_plane (possible as part of a larger structure) and
> +registers it with a call to drm_plane_init(). The function takes a bitmask of
> +the CRTCs that can be associated with the plane, a pointer to the plane
> +functions and a list of format supported formats.
> +
> +- Encoders (struct drm_encoder)
> +
> +"An encoder takes pixel data from a CRTC and converts it to a format suitable
> +for any 

[ANNOUNCE] libdrm 2.4.35

[Alex Deucher]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Alex Deucher (3):
  radeon: add new pci ids
  radeon: fall back to 1D tiling only with broken kernels
  configure: bump version for release

Ben Widawsky (2):
  intel: sanitize i915_drm.h
  intel: wait render header updates

Inki Dae (1):
  libdrm: add exynos drm support

Michel D?nzer (1):
  radeon: Add Southern Islands PCI IDs.

git tag: libdrm-2.4.35

http://dri.freedesktop.org/www/libdrm/libdrm-2.4.35.tar.bz2
MD5:  a40f5293dc0a7b49d2a1e959d7d60194  libdrm-2.4.35.tar.bz2
SHA1: a1d8d4945f782371d7855dbd693db885bd7e3d83  libdrm-2.4.35.tar.bz2
SHA256: c390aee132f05910edb09398b70e108c6b53f9b69b21914a9ea3165eed6f1b21
 libdrm-2.4.35.tar.bz2

http://dri.freedesktop.org/www/libdrm/libdrm-2.4.35.tar.gz
MD5:  77992a226118a55e214f315bf23d4273  libdrm-2.4.35.tar.gz
SHA1: e59f1607a33488e0c7d0ec7bb230777d09bbd788  libdrm-2.4.35.tar.gz
SHA256: b5fa1e1a1abe263e1e62af4f3a5515c53c6aca35a713bfbaa173402b32f637be
 libdrm-2.4.35.tar.gz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk/QxFQACgkQm07k+YR03kBjZgCgpJGQ0GnPYUgdIgksRTBCm7yL
TxcAn3utXITwGobX6qWd0/RbpsNNTTyz
=QXk0
-END PGP SIGNATURE-

[Bug 13364] BUG: unable to handle kernel paging request at 429a4c40

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

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


Alan  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 13364] BUG: unable to handle kernel paging request at 429a4c40

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

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


Alan  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||alan at lxorguk.ukuu.org.uk
 Resolution||OBSOLETE




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

Synchronization framework

[Maarten Lankhorst]

Hey,

For intel/nouveau hybrid graphics I'm interested in this since it
would allow me to synchronize between intel and nvidia cards
without waiting for rendering to complete.

I'm worried about the api though, nouveau and intel already
have existing infrastructure to deal with fencing so exposing
additional ioctl's will complicate the implementation. Would
it be possible to never expose this interface to userspace
but keep it inside the kernel only?

nouveau_gem_ioctl_pushbuf is what's used for nouveau.
If any dmabuf synch framework could hook into that then
userspace would never have to act differently on shared bo's.

I haven't looked at intel and amd, but from a quick glance
it seems like they already implement fencing too, so just
some way to synch up the fences on shared buffers seems
like it could benefit all graphics drivers and the whole
userspace synching could be done away with entirely.

Cheers,
Maarten

radeon gpu driver bug on suspend/resume in 3.5-rc1

[Austin Lund]

Hi,

I get the attached traces with 3.5-rc1 after suspend/resume,
sometimes.  It doesn't always happen.  Usually happens at least once
in 10 suspend/resume cycles.  The first trace seems non fatal, but the
system locks up in the second one and needs to be rebooted.

===

[ 1435.785548] Restarting tasks ... done.
[ 1435.854748] usb 2-1.2: new full-speed USB device number 5 using ehci_hcd
[ 1435.856616] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -35!
[ 1435.857653] radeon :01:00.0: GPU reset succeed
[ 1435.878746] [drm] PCIE GART of 512M enabled (table at 0x0004).
[ 1435.878837] radeon :01:00.0: WB enabled
[ 1435.878839] radeon :01:00.0: fence driver on ring 0 use gpu
addr 0x4c00 and cpu addr 0x88025e8c2c00
[ 1435.895010] [drm] ring test on 0 succeeded in 2 usecs
[ 1435.895067] [drm] ib test on ring 0 succeeded in 0 usecs

===

[ 1376.089570] Restarting tasks ... done.
[ 1376.092574] radeon :01:00.0: GPU lockup CP stall for more than 17300msec
[ 1376.092615] radeon :01:00.0: GPU lockup (waiting for
0x00019986 last fence id 0x00019981)
[ 1376.093654] radeon :01:00.0: GPU softreset
[ 1376.093657] radeon :01:00.0:   GRBM_STATUS=0xA0003828
[ 1376.093659] radeon :01:00.0:   GRBM_STATUS_SE0=0x0007
[ 1376.093662] radeon :01:00.0:   GRBM_STATUS_SE1=0x0007
[ 1376.093664] radeon :01:00.0:   SRBM_STATUS=0x20C0
[ 1376.093675] radeon :01:00.0:   GRBM_SOFT_RESET=0x7F6B
[ 1376.093778] radeon :01:00.0:   GRBM_STATUS=0x3828
[ 1376.093781] radeon :01:00.0:   GRBM_STATUS_SE0=0x0007
[ 1376.093783] radeon :01:00.0:   GRBM_STATUS_SE1=0x0007
[ 1376.093785] radeon :01:00.0:   SRBM_STATUS=0x20C0
[ 1376.094781] radeon :01:00.0: GPU reset succeed
[ 1376.116071] [drm] PCIE GART of 512M enabled (table at 0x0004).
[ 1376.116165] radeon :01:00.0: WB enabled
[ 1376.116167] radeon :01:00.0: fence driver on ring 0 use gpu
addr 0x4c00 and cpu addr 0x88025e42ec00
[ 1376.132330] [drm] ring test on 0 succeeded in 2 usecs
[ 1376.132392] [drm] ib test on ring 0 succeeded in 0 usecs
[ 1376.741682] tg3 :02:00.0: irq 49 for MSI/MSI-X
[ 1376.741703] tg3 :02:00.0: irq 50 for MSI/MSI-X
[ 1376.741718] tg3 :02:00.0: irq 51 for MSI/MSI-X
[ 1376.741733] tg3 :02:00.0: irq 52 for MSI/MSI-X
[ 1376.741748] tg3 :02:00.0: irq 53 for MSI/MSI-X
[ 1377.772057] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 1377.926958] b43-phy0: Loading firmware version 666.2 (2011-02-23 01:15:07)
[ 1377.966914] b43-phy0 debug: Chip initialized
[ 1377.967124] b43-phy0 debug: 64-bit DMA initialized
[ 1377.967199] b43-phy0 debug: QoS enabled
[ 1377.968068] b43-phy0 debug: Wireless interface started
[ 1377.968140] b43-phy0 debug: Adding Interface type 2
[ 1377.969962] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 1381.080635] wlan0: authenticate with 00:12:bf:12:7a:49
[ 1381.092133] wlan0: direct probe to 00:12:bf:12:7a:49 (try 1/3)
[ 1381.295524] wlan0: direct probe to 00:12:bf:12:7a:49 (try 2/3)
[ 1381.499372] wlan0: direct probe to 00:12:bf:12:7a:49 (try 3/3)
[ 1381.703233] wlan0: authentication with 00:12:bf:12:7a:49 timed out
[ 1386.914207] radeon :01:00.0: GPU lockup CP stall for more than 1msec
[ 1386.914218] radeon :01:00.0: GPU lockup (waiting for
0x0001998b last fence id 0x00019988)
[ 1386.914225] radeon :01:00.0: 8802605ec000 pin failed
[ 1386.986828] radeon :01:00.0: couldn't schedule ib
[ 1386.986837] [drm:radeon_cs_ib_chunk] *ERROR* Failed to schedule IB !
[ 1386.986856] [ cut here ]
[ 1386.986899] WARNING: at
/home/lund/src/linux/drivers/gpu/drm/radeon/radeon_fence.c:180
radeon_fence_signaled+0x8d/0x90 [radeon]()
[ 1386.986902] Hardware name: MacBookPro8,2
[ 1386.986905] Querying an unemitted fence : 8802670045a0 !
[ 1386.986972] Modules linked in: autofs4 snd_hda_codec_hdmi rfcomm
bnep snd_hda_codec_cirrus arc4 snd_hda_intel b43 snd_hda_codec
ghash_clmulni_intel aesni_intel radeon snd_hwdep snd_pcm snd_seq_midi
cryptd binfmt_misc snd_rawmidi mac80211 aes_x86_64 ttm microcode
drm_kms_helper drm cfg80211 uvcvideo videobuf2_core ssb applesmc
videodev videobuf2_vmalloc input_polldev i2c_algo_bit btusb apple_gmux
videobuf2_memops hid_generic video bluetooth bcma snd_seq_midi_event
bcm5974 snd_seq snd_timer snd_seq_device snd soundcore snd_page_alloc
apple_bl hid_apple firewire_ohci firewire_core usbhid tg3 hid
crc_itu_t
[ 1386.986980] Pid: 1338, comm: Xorg Not tainted 3.5.0-rc1 #21
[ 1386.986983] Call Trace:
[ 1386.986998]  [] warn_slowpath_common+0x7f/0xc0
[ 1386.987006]  [] warn_slowpath_fmt+0x46/0x50
[ 1386.987034]  [] radeon_fence_signaled+0x8d/0x90 [radeon]
[ 1386.987060]  [] radeon_sync_obj_signaled+0xe/0x10 [radeon]
[ 1386.987073]  [] 

[Bug 13249] Intel 945GM: Boot option`vga=0x31a' breaks display of TTYs

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

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


Alan  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 13249] Intel 945GM: Boot option`vga=0x31a' breaks display of TTYs

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

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


Alan  changed:

   What|Removed |Added

 Status|NEEDINFO|RESOLVED
 CC||alan at lxorguk.ukuu.org.uk
 Resolution||OBSOLETE




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

edp backtrace spam on MacBookAir4,1

[Paul Menzel]

Am Donnerstag, den 07.06.2012, 09:26 +0200 schrieb Daniel Vetter:

[?]

> From 709e3d49d83fb7f1c297c7c0d9e994af6571bbdb Mon Sep 17 00:00:00 2001
> From: Daniel Vetter 
> Date: Thu, 7 Jun 2012 08:59:49 +0200
> Subject: [PATCH] drm/i915: enable edp vdd in intel_dp_detect
> 
> We need this for dp aux communication. This issue can fill the dmesg

What issue?

> with WARN spam when the panel is disable (e.g. while reconfiguring the

disable*d*

> mode or while resuming).
> 
> v2: Actually enable edp vdd early enough. I've missed one dp aux
> channel thingy ...
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50808
> Reported-by: Linus Torvalds 
> Bugreport: http://permalink.gmane.org/gmane.comp.video.dri.devel/69695
> Cc: stable at vger.kernel.org
> Signed-Off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/i915/intel_dp.c |6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)

[?]


Thanks,

Paul
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120607/dbf6ae0e/attachment.pgp>

[RFC] Documentation: DRM framework documentation

[Laurent Pinchart]

Hi Rob,

On Tuesday 05 June 2012 04:31:54 Rob Clark wrote:
> Hey, thanks Laurent, this was quite needed!
> 
> I apologize in advance for the html mail.. but reviewing this on the flight
> home from connect and can't figure out how to do plain text email w/
> google's offline mail client :-(

No worries. Thanks for the review.

> On Wednesday, May 30, 2012, Laurent Pinchart wrote:
> > Signed-off-by: Laurent Pinchart 
> > ---
> > 
> >  Documentation/drm.txt | 1265
> > 
> > +
> > 
> >  1 files changed, 1265 insertions(+), 0 deletions(-)
> >  create mode 100644 Documentation/drm.txt
> > 
> > Hi everybody,
> > 
> > Here's the DRM kernel framework documentation I wrote while developing the
> > Renesas SH Mobile DRM driver. It hopefully covers most of what's needed to
> > write a simple DRM driver (although some areas are not documented, such as
> > properties or the fbdev compatibility layer).
> > 
> > I can convert the documentation to DocBook if needed and integrate it with
> > the existing "documentation stub". In that case I'm thinking of splitting
> > the DocBook documentation in two parts, userspace API documentation (that
> > someone would have to fill, any volunteer ? ;-)) and kernel API
> > documentation. Would that be fine ?
> > 
> > Last but not least, now that documentation exists (albeit in an incomplete
> > state), we need to make sure it won't get outdated too quickly. As nobody
> > will volunteer to maintain it (feel free to prove me wrong though), I'd
> > like to propose the same rule that we already follow in V4L: any patch
> > that touches the API won't get merged if it doesn't update the
> > documentation. Do you think this could work out ?
> 
> seems like a pretty reasonable idea

Let's work together on nacking patches that don't include documentation then 
:-)

> > As usual, review will be appreciated.
> > 
> > diff --git a/Documentation/drm.txt b/Documentation/drm.txt
> > new file mode 100644
> > index 000..4d8843d
> > --- /dev/null
> > +++ b/Documentation/drm.txt
> > @@ -0,0 +1,1265 @@

[snip]

> > +  - int (*firstopen) (struct drm_device *)
> > +  - void (*lastclose) (struct drm_device *)
> > +  - int (*open) (struct drm_device *, struct drm_file *)
> > +  - void (*preclose) (struct drm_device *, struct drm_file *)
> > +  - void (*postclose) (struct drm_device *, struct drm_file *)
> > +
> > +  Open and close handlers. None of those methods are mandatory.
> > +
> > +  The .firstopen() method is called by the DRM core when an application
> > opens
> > +  a device that has no other opened file handle. Similarly the
> > .lastclose()
> > +  method is called when the last application holding a file handle opened
> > on
> > +  the device closes it. Both methods are mostly used for UMS (User Mode
> > +  Setting) drivers to acquire and release device resources which should
> > be
> > +  done in the .load() and .unload() methods for KMS drivers.
> > +
> > +  Note that the .lastclose() method is also called at module unload time
> > or,
> > +  for hot-pluggable devices, when the device is unplugged. The
> > .firstopen()
> > +  and .lastclose() calls can thus be unbalanced.
> > +
> 
> AFAIK lastclose() should also be drm_fb_helper_restore_fbdev_mode() to
> restore fbcon mode.

Good point. I haven't documented the fbdev helper yet, I'll keep that in mind 
when updating the documentation.

> I'm also restoring crtc and plane properties to default values here, so a
> subsequent open of the device isn't inheriting some state from the previous
> user.

That's very unlike V4L2, where we explicitly require state to be kept across 
opens. Is restoring properties a DRM standard behaviour, implemented by other 
drivers as well ?

> (maybe some of this could be handled instead in core, rather than each
> driver.. could be an idea for a cleanup?)
> 
> > +  The .open() method is called every time the device is opened by an
> > +  application. Drivers can allocate per-file private data in this method
> > and
> > +  store them in the struct drm_file::driver_priv field. Note that the
> > .open()
> > +  method is called before .firstopen().
> > +
> > +  The close operation is split into .preclose() and .postclose() methods.
> > +  Drivers must stop and cleanup all per-file operations in the
> > .preclose()
> > +  method. For instance pending vertical blanking and page flip events
> > must be
> > +  cancelled. No per-file operation is allowed on the file handle after
> > +  returning from the .preclose() method.
> 
> oh, heh, I completely missed that in omapdrm, so looks like I need to do
> some cleanup around here..  I wonder if there is any sane way to make this
> simpler for the driver writer, since basically all drivers would need to do
> the same thing here..  Ie. keep track of pending page_flip events, sort of
> analogous to how the core keeps track of pending vblank events..
>
> Are there any drivers that can queue up more than one page flip per crtc at
> a 

edp backtrace spam on MacBookAir4,1

[Daniel Vetter]

On Wed, May 30, 2012 at 08:39:13AM -0700, Linus Torvalds wrote:
> On Wed, May 30, 2012 at 1:27 AM, Daniel Vetter  wrote:
> >
> > Ok, Chris couldn't reproduce this on his mba. Can you please boot with
> > drm.debug=0xe, reproduce the noise and then attach the full dmesg?
> 
> Hmm. Now *I* can't reproduce it either.
> 
> I have updated my system in the meantime, so maybe this is related to
> that. However, I suspect it's more likely that it's some race
> condition, because when I got it, I got a *lot* of it, but they were
> all very tightly bunched together:
> 
>  [ 1588.996413] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> intel_dp_check_edp+0x5d/0xb0()
>  [ 1588.996650] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> intel_dp_check_edp+0x5d/0xb0()
>  [ 1589.000983] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> intel_dp_check_edp+0x5d/0xb0()
>  [ 1589.001225] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> intel_dp_check_edp+0x5d/0xb0()
>  [ 1589.005975] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> intel_dp_check_edp+0x5d/0xb0()
>  [ 1589.006218] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> intel_dp_check_edp+0x5d/0xb0()
>  [ 1589.010980] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> intel_dp_check_edp+0x5d/0xb0()
>  [ 1589.011224] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> intel_dp_check_edp+0x5d/0xb0()
>  [ 1589.015976] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> intel_dp_check_edp+0x5d/0xb0()
>  [ 1589.016211] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> intel_dp_check_edp+0x5d/0xb0()
>  [ 1589.020986] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> intel_dp_check_edp+0x5d/0xb0()
>  [ 1589.021232] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> intel_dp_check_edp+0x5d/0xb0()
> 
> ie that's 12 of those warnings (each of them with that huge backtrace
> etc), but they are all within 0.03 seconds of each other. So I suspect
> it needs to hit some particular timing window, and I was just
> (un)lucky.
> 
> Because when I try it now with DRM debugging, I can't hit it. And just
> to make sure, I re-did the test without debugging too (in case the
> debugging would have changed timing), but can't reproduce it that way
> either.

Meh, I've been totally blind. Note to self: Next time around actually look
at the backtrace. And I dunno how that escaped our dear QA that long ...

Below patch should shut this up (and might even fix an edp panel not
getting up again after having been switched off).

Yours, Daniel
---

[Mesa-dev] [PATCH 00/25] i915 HW context support

[Ben Widawsky]

On Tue, 05 Jun 2012 16:37:20 -0700
Kenneth Graunke  wrote:

> On 06/04/2012 02:42 PM, Ben Widawsky wrote:
> > Setting myself up for a late night crying session once again. Most of the
> > people reading this probably know the history and reasons for the patches. 
> > If
> > not, you can search the intel-gfx mailing list to try to learn more. I won't
> > recap the whole thing here, and instead let the patches speak for 
> > themselves.
> > 
> > Instead a brief review of what's here, and what's happened. Mostly,
> > these badly need testing and review. I've carried these around for so
> > long now, and seen so many different failures, I'm quite paranoid they
> > still aren't perfect. Also, I've spent almost all of the time working on
> > this in the kernel, so there is bound to be simple errors in the other
> > stuff.
> > 
> > I've run these on various workloads and saw nothing worth mentioning.
> > 
> > 
> > 0-16: kernel patches
> 
> > 17-21: libdrm patches (wait render patch is temporary)
> 
> Patches 17-21 look fine.
> Reviewed-by: Kenneth Graunke 
> 
> > 22-24: intel-gpu-tools
> > 25: mesa
> 
> Patch 25 looks fine too.  Feel free to apply some combination of:
> Reviewed-by: Kenneth Graunke 
> Signed-off-by: Kenneth Graunke 
> 
> I do like Paul's comment updates, so I suggest merging those.

Ken, would you do these for me on patch 25? It's really your patch
anyhow, I just made ever so slight modifications :-)

> 
> > kernel
> > git://people.freedesktop.org/~bwidawsk/drm-intel context_support_rev2
> > 
> > libdrm
> > git://people.freedesktop.org/~bwidawsk/drm context_support_rev2
> > 
> > i-g-t
> > git://people.freedesktop.org/~bwidawsk/intel-gpu-tools context_support



-- 
Ben Widawsky, Intel Open Source Technology Center

[PATCH v5] intel: wait render timeout implementation

[Ben Widawsky]

int drm_intel_gem_bo_wait(drm_intel_bo *bo, uint64_t timeout_ns)

This should bump the libdrm version. We're waiting for context support
so we can do both features in one bump.

v2: don't return remaining timeout amount
use get param and fallback for older kernels

v3: only doing getparam at init
prototypes now have a signed input value

v4: update comments
fall back to correct polling behavior with new userspace and old kernel

v5: since the drmIoctl patch was not well received, return appropriate
values in this function instead. As Daniel pointed out, the polling
case (timeout == 0) should also return -ETIME.

Cc: Eric Anholt 
Cc: Daniel Vetter 
Signed-off-by: Ben Widawsky 
---
 intel/intel_bufmgr.h |1 +
 intel/intel_bufmgr_gem.c |   57 ++
 2 files changed, 58 insertions(+)

diff --git a/intel/intel_bufmgr.h b/intel/intel_bufmgr.h
index c197abc..fa6c4dd 100644
--- a/intel/intel_bufmgr.h
+++ b/intel/intel_bufmgr.h
@@ -184,6 +184,7 @@ int drm_intel_get_pipe_from_crtc_id(drm_intel_bufmgr 
*bufmgr, int crtc_id);

 int drm_intel_get_aperture_sizes(int fd, size_t *mappable, size_t *total);
 int drm_intel_bufmgr_gem_get_devid(drm_intel_bufmgr *bufmgr);
+int drm_intel_gem_bo_wait(drm_intel_bo *bo, int64_t timeout_ns);

 /* drm_intel_bufmgr_fake.c */
 drm_intel_bufmgr *drm_intel_bufmgr_fake_init(int fd,
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index b776d2f..e90f8bd 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -119,6 +119,7 @@ typedef struct _drm_intel_bufmgr_gem {
unsigned int has_blt : 1;
unsigned int has_relaxed_fencing : 1;
unsigned int has_llc : 1;
+   unsigned int has_wait_timeout : 1;
unsigned int bo_reuse : 1;
unsigned int no_exec : 1;
bool fenced_relocs;
@@ -1479,6 +1480,58 @@ drm_intel_gem_bo_wait_rendering(drm_intel_bo *bo)
 }

 /**
+ * Waits on a BO for the given amount of time.
+ *
+ * @bo: buffer object to wait for
+ * @timeout_ns: amount of time to wait in nanoseconds.
+ *   If value is less than 0, an infinite wait will occur.
+ *
+ * Returns 0 if the wait was successful ie. the last batch referencing the
+ * object has completed within the allotted time. Otherwise some negative 
return
+ * value describes the error. Of particular interest is -ETIME when the wait 
has
+ * failed to yield the desired result.
+ *
+ * Similar to drm_intel_gem_bo_wait_rendering except a timeout parameter allows
+ * the operation to give up after a certain amount of time. Another subtle
+ * difference is the internal locking semantics are different (this variant 
does
+ * not hold the lock for the duration of the wait). This makes the wait subject
+ * to a larger userspace race window.
+ *
+ * The implementation shall wait until the object is no longer actively
+ * referenced within a batch buffer at the time of the call. The wait will
+ * not guarantee that the buffer is re-issued via another thread, or an flinked
+ * handle. Userspace must make sure this race does not occur if such precision
+ * is important.
+ */
+int drm_intel_gem_bo_wait(drm_intel_bo *bo, int64_t timeout_ns)
+{
+   drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *) bo->bufmgr;
+   drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *) bo;
+   struct drm_i915_gem_wait wait;
+   int ret;
+
+   if (!bufmgr_gem->has_wait_timeout) {
+   DBG("%s:%d: Timed wait is not supported. Falling back to "
+   "infinite wait\n", __FILE__, __LINE__);
+   if (timeout_ns) {
+   drm_intel_gem_bo_wait_rendering(bo);
+   return 0;
+   } else {
+   return drm_intel_gem_bo_busy(bo) ? -ETIME : 0;
+   }
+   }
+
+   wait.bo_handle = bo_gem->gem_handle;
+   wait.timeout_ns = timeout_ns;
+   wait.flags = 0;
+   ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GEM_WAIT, );
+   if (ret == -1)
+   return -errno;
+
+   return ret;
+}
+
+/**
  * Sets the object to the GTT read and possibly write domain, used by the X
  * 2D driver in the absence of kernel support to do drm_intel_gem_bo_map_gtt().
  *
@@ -2898,6 +2951,10 @@ drm_intel_bufmgr_gem_init(int fd, int batch_size)
ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GETPARAM, );
bufmgr_gem->has_relaxed_fencing = ret == 0;

+   gp.param = I915_PARAM_HAS_WAIT_TIMEOUT;
+   ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GETPARAM, );
+   bufmgr_gem->has_wait_timeout = ret == 0;
+
gp.param = I915_PARAM_HAS_LLC;
ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GETPARAM, );
if (ret != 0) {
-- 
1.7.10.3

[PATCH 2/2 v4] intel: wait render timeout implementation

[Daniel Vetter]

On Wed, Jun 06, 2012 at 04:42:11PM -0700, Ben Widawsky wrote:
> int drm_intel_gem_bo_wait(drm_intel_bo *bo, uint64_t timeout_ns)
> 
> This should bump the libdrm version. We're waiting for context support
> so we can do both features in one bump.
> 
> v2: don't return remaining timeout amount
> use get param and fallback for older kernels
> 
> v3: only doing getparam at init
> prototypes now have a signed input value
> 
> v4: update comments
> fall back to correct polling behavior with new userspace and old kernel
> 
> Cc: Eric Anholt 
> Cc: Daniel Vetter 
> Signed-off-by: Ben Widawsky 
> ---
>  intel/intel_bufmgr.h |1 +
>  intel/intel_bufmgr_gem.c |   51 
> ++
>  2 files changed, 52 insertions(+)
> 
> diff --git a/intel/intel_bufmgr.h b/intel/intel_bufmgr.h
> index c197abc..fa6c4dd 100644
> --- a/intel/intel_bufmgr.h
> +++ b/intel/intel_bufmgr.h
> @@ -184,6 +184,7 @@ int drm_intel_get_pipe_from_crtc_id(drm_intel_bufmgr 
> *bufmgr, int crtc_id);
>  
>  int drm_intel_get_aperture_sizes(int fd, size_t *mappable, size_t *total);
>  int drm_intel_bufmgr_gem_get_devid(drm_intel_bufmgr *bufmgr);
> +int drm_intel_gem_bo_wait(drm_intel_bo *bo, int64_t timeout_ns);
>  
>  /* drm_intel_bufmgr_fake.c */
>  drm_intel_bufmgr *drm_intel_bufmgr_fake_init(int fd,
> diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
> index b776d2f..f8e3706 100644
> --- a/intel/intel_bufmgr_gem.c
> +++ b/intel/intel_bufmgr_gem.c
> @@ -119,6 +119,7 @@ typedef struct _drm_intel_bufmgr_gem {
>   unsigned int has_blt : 1;
>   unsigned int has_relaxed_fencing : 1;
>   unsigned int has_llc : 1;
> + unsigned int has_wait_timeout : 1;
>   unsigned int bo_reuse : 1;
>   unsigned int no_exec : 1;
>   bool fenced_relocs;
> @@ -1479,6 +1480,52 @@ drm_intel_gem_bo_wait_rendering(drm_intel_bo *bo)
>  }
>  
>  /**
> + * Waits on a BO for the given amount of time.
> + *
> + * @bo: buffer object to wait for
> + * @timeout_ns: amount of time to wait in nanoseconds.
> + *   If value is less than 0, an infinite wait will occur.
> + *
> + * Returns 0 if the wait was successful ie. the last batch referencing the
> + * object has completed within the allotted time. Otherwise some negative 
> return
> + * value describes the error.

I'm not too sure about that being correct yet. Iirc drmIoctl simply
returns -1 on error, with the (positive error number stored in errno),
and the busy function returns 1 when the thing is busy. I think we should
map both properly to the same -ETIME.
-Daniel

> + *
> + * Similar to drm_intel_gem_bo_wait_rendering except a timeout parameter 
> allows
> + * the operation to give up after a certain amount of time. Another subtle
> + * difference is the internal locking semantics are different (this variant 
> does
> + * not hold the lock for the duration of the wait). This makes the wait 
> subject
> + * to a larger userspace race window.
> + *
> + * The implementation shall wait until the object is no longer actively
> + * referenced within a batch buffer at the time of the call. The wait will
> + * not guarantee that the buffer is re-issued via another thread, or an 
> flinked
> + * handle. Userspace must make sure this race does not occur if such 
> precision
> + * is important.
> + */
> +int drm_intel_gem_bo_wait(drm_intel_bo *bo, int64_t timeout_ns)
> +{
> + drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *) bo->bufmgr;
> + drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *) bo;
> + struct drm_i915_gem_wait wait;
> +
> + if (!bufmgr_gem->has_wait_timeout) {
> + DBG("%s:%d: Timed wait is not supported. Falling back to "
> + "infinite wait\n", __FILE__, __LINE__);
> + if (timeout_ns) {
> + drm_intel_gem_bo_wait_rendering(bo);
> + return 0;
> + } else {
> + return drm_intel_gem_bo_busy(bo);
> + }
> + }
> +
> + wait.bo_handle = bo_gem->gem_handle;
> + wait.timeout_ns = timeout_ns;
> + wait.flags = 0;
> + return drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GEM_WAIT, );
> +}
> +
> +/**
>   * Sets the object to the GTT read and possibly write domain, used by the X
>   * 2D driver in the absence of kernel support to do 
> drm_intel_gem_bo_map_gtt().
>   *
> @@ -2898,6 +2945,10 @@ drm_intel_bufmgr_gem_init(int fd, int batch_size)
>   ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GETPARAM, );
>   bufmgr_gem->has_relaxed_fencing = ret == 0;
>  
> + gp.param = I915_PARAM_HAS_WAIT_TIMEOUT;
> + ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GETPARAM, );
> + bufmgr_gem->has_wait_timeout = ret == 0;
> +
>   gp.param = I915_PARAM_HAS_LLC;
>   ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GETPARAM, );
>   if (ret != 0) {
> -- 
> 1.7.10.3
> 

-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[PATCH] drm/i915: enable edp vdd in intel_dp_detect

[Daniel Vetter]

We need this for dp aux communication. This issue can fill the dmesg
with WARN spam when the panel is disable (e.g. while reconfiguring the
mode or while resuming).

v2: Actually enable edp vdd early enough. I've missed one dp aux
channel thingy ...

v3: We also enable/disable vdd in get_edid, which is called from
within ->detect if a monitor is connected. But because we do some
more dp aux transfers afterwards, vdd is actually off and we hit the
WARN again. Hence move vdd enabling/disabling out of get_edid into the
callsite.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50808
Reported-by: Linus Torvalds 
Bugreport: http://permalink.gmane.org/gmane.comp.video.dri.devel/69695
Tested-by: Yang Guang 
Cc: stable at vger.kernel.org
Signed-Off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_dp.c |   16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 296cfc2..941edbf 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2114,13 +2114,7 @@ g4x_dp_detect(struct intel_dp *intel_dp)
 static struct edid *
 intel_dp_get_edid(struct drm_connector *connector, struct i2c_adapter *adapter)
 {
-   struct intel_dp *intel_dp = intel_attached_dp(connector);
-   struct edid *edid;
-
-   ironlake_edp_panel_vdd_on(intel_dp);
-   edid = drm_get_edid(connector, adapter);
-   ironlake_edp_panel_vdd_off(intel_dp, false);
-   return edid;
+   return drm_get_edid(connector, adapter);
 }

 static int
@@ -2152,6 +2146,7 @@ intel_dp_detect(struct drm_connector *connector, bool 
force)

intel_dp->has_audio = false;

+   ironlake_edp_panel_vdd_on(intel_dp);
if (HAS_PCH_SPLIT(dev))
status = ironlake_dp_detect(intel_dp);
else
@@ -2162,8 +2157,10 @@ intel_dp_detect(struct drm_connector *connector, bool 
force)
  intel_dp->dpcd[3], intel_dp->dpcd[4], intel_dp->dpcd[5],
  intel_dp->dpcd[6], intel_dp->dpcd[7]);

-   if (status != connector_status_connected)
+   if (status != connector_status_connected) {
+   ironlake_edp_panel_vdd_off(intel_dp, false);
return status;
+   }

intel_dp_probe_oui(intel_dp);

@@ -2177,6 +2174,7 @@ intel_dp_detect(struct drm_connector *connector, bool 
force)
kfree(edid);
}
}
+   ironlake_edp_panel_vdd_off(intel_dp, false);

return connector_status_connected;
 }
@@ -2235,6 +2233,7 @@ intel_dp_detect_audio(struct drm_connector *connector)
struct edid *edid;
bool has_audio = false;

+   ironlake_edp_panel_vdd_on(intel_dp);
edid = intel_dp_get_edid(connector, _dp->adapter);
if (edid) {
has_audio = drm_detect_monitor_audio(edid);
@@ -2242,6 +2241,7 @@ intel_dp_detect_audio(struct drm_connector *connector)
connector->display_info.raw_edid = NULL;
kfree(edid);
}
+   ironlake_edp_panel_vdd_off(intel_dp, false);

return has_audio;
 }
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[PATCH] drm/i915: enable edp vdd in intel_dp_detect

[Daniel Vetter]

We need this for dp aux communication. This issue can fill the dmesg
with WARN spam when the panel is disable (e.g. while reconfiguring the
mode or while resuming).

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50808
Reported-by: Linus Torvalds 
Bugreport: http://permalink.gmane.org/gmane.comp.video.dri.devel/69695
Cc: stable at vger.kernel.org
Signed-Off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_dp.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 296cfc2..9a7edcf 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2165,6 +2165,7 @@ intel_dp_detect(struct drm_connector *connector, bool 
force)
if (status != connector_status_connected)
return status;

+   ironlake_edp_panel_vdd_on(intel_dp);
intel_dp_probe_oui(intel_dp);

if (intel_dp->force_audio != HDMI_AUDIO_AUTO) {
@@ -2177,6 +2178,7 @@ intel_dp_detect(struct drm_connector *connector, bool 
force)
kfree(edid);
}
}
+   ironlake_edp_panel_vdd_off(intel_dp, false);

return connector_status_connected;
 }
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[Linaro-mm-sig] [PATCHv6 00/13] Integration of videobuf2 with dmabuf

[Hans Verkuil]

On Thu June 7 2012 02:52:06 Laurent Pinchart wrote:
> Hi Hans,
> 
> On Wednesday 06 June 2012 10:17:03 Hans Verkuil wrote:
> > On Wed 6 June 2012 05:46:34 Laurent Pinchart wrote:
> > > On Monday 04 June 2012 12:34:23 Rebecca Schultz Zavin wrote:
> > > > I have a system where the data is planar, but the kernel drivers
> > > > expect to get one allocation with offsets for the planes.  I can't
> > > > figure out how to do that with the current dma_buf implementation.  I
> > > > thought I could pass the same dma_buf several times and use the
> > > > data_offset field of the v4l2_plane struct but it looks like that's
> > > > only for output.  Am I missing something?  Is this supported?
> > > 
> > > data_offset is indeed for video output only at the moment, and doesn't
> > > seem to be used by any driver in mainline for now.
> > 
> > Actually, data_offset may be set by capture drivers. For output buffers it
> > is set by userspace, for capture buffers it is set by the driver. This
> > data_offset typically contains meta data.
> 
> Is that documented somewhere ? I wasn't aware of this use case.

It is documented in the proposal that Pawel sent, but very poorly if at all in
the spec. That needs to be improved.

> > > I can't really see a reason why data_offset couldn't be used for video
> > > capture devices as well.
> > > 
> > > Sanity checks are currently missing. For output devices we should check
> > > that data_offset + bytesused < length in the vb2 core. For input devices
> > > the check will have to be performed by drivers. Taking data_offset into
> > > account automatically would also be useful. I think most of that should
> > > be possible to implement in the allocators.
> > 
> > See this proposal of how to solve this:
> > 
> > http://www.spinics.net/lists/linux-media/msg40376.html
> 
> This requires more discussions regarding how the app_offset and data_offset 
> fields should be used for the different memory types we support.
> 
> For instance app_offset would not make that much sense for the USERPTR memory 
> type, as we can include the offset in the user pointer already (using 
> app_offset there would only make the code more complex without any added 
> benefit).
> 
> For the MMAP memory type adding an app_offset would require allocating 
> buffers 
> large enough to accomodate the offset, and would thus only be useful with 
> CREATE_BUFS. I'm also wondering whether the main use case (passing the buffer 
> to another device that requires that app_offset) wouldn't be better addressed 
> by the DMABUF memory type anyway.

I'm not going to pursue this unless Google indicates that they need this. And
actually I would suggest that they ask Pawel to work on this, after all he made
the proposal AND he works for Google :-)

Regards,

Hans

[Bug 50655] ATI RV670 [Radeon HD 3870] Ioquake games causes GPU lockup (waiting for 0x00003039 last fence id 0x00003030)

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

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

Michel D?nzer  changed:

   What|Removed |Added

 CC||maraeo at gmail.com

--- Comment #11 from Michel D?nzer  2012-06-07 00:40:00 
PDT ---
Marek, any ideas? (bug 47116 might be related)

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

[PATCH 1/2] drm: drmIoctl return -errno on failure conditions

[Dave Airlie]

On Thu, Jun 7, 2012 at 12:41 AM, Ben Widawsky  wrote:
> Anyone aware of what this will break? It seems to be a much nicer thing
> to do for callers. If people do not like it, I will probably just create
> a #define drmIoctl2 or some such thing.
>


uggh no you going to redeine open/read/write as well?

think of it aa system call, they return -1 and set errno.

Dave.

[Bug 50655] ATI RV670 [Radeon HD 3870] Ioquake games causes GPU lockup (waiting for 0x00003039 last fence id 0x00003030)

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

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

--- Comment #10 from Bryan Quigley  2012-06-06 
21:42:42 PDT ---
Created attachment 62689
  --> https://bugs.freedesktop.org/attachment.cgi?id=62689
good+bad git bisects

Both the good and bad git bisect logs, the good one had me run warsow, padman,
and urbanterror looking for the bug.
The bad one missed some occurrences it seems.

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

[Bug 50655] ATI RV670 [Radeon HD 3870] Ioquake games causes GPU lockup (waiting for 0x00003039 last fence id 0x00003030)

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

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

--- Comment #9 from Bryan Quigley  2012-06-06 
21:39:53 PDT ---
I think I did everything right in this bisect (I didn't the first attempt).

fbebd431ec4e2e461a0cbcd5f3a04a000b8f6bbf is the first bad commit
commit fbebd431ec4e2e461a0cbcd5f3a04a000b8f6bbf
Author: Marek Ol??k 
Date:   Fri Feb 3 05:05:31 2012 +0100

r600g: move invariant register updates into start_cs for r6xx-r7xx

:04 04 dd9232a0c49e54e0cd536fa858dc131982dc2fbe
379e1d61c53d98a8706f32da5020dc22c0c0ee33 Msrc

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

[Linaro-mm-sig] [PATCHv6 00/13] Integration of videobuf2 with dmabuf

[Laurent Pinchart]

Hi Hans,

On Wednesday 06 June 2012 10:17:03 Hans Verkuil wrote:
> On Wed 6 June 2012 05:46:34 Laurent Pinchart wrote:
> > On Monday 04 June 2012 12:34:23 Rebecca Schultz Zavin wrote:
> > > I have a system where the data is planar, but the kernel drivers
> > > expect to get one allocation with offsets for the planes.  I can't
> > > figure out how to do that with the current dma_buf implementation.  I
> > > thought I could pass the same dma_buf several times and use the
> > > data_offset field of the v4l2_plane struct but it looks like that's
> > > only for output.  Am I missing something?  Is this supported?
> > 
> > data_offset is indeed for video output only at the moment, and doesn't
> > seem to be used by any driver in mainline for now.
> 
> Actually, data_offset may be set by capture drivers. For output buffers it
> is set by userspace, for capture buffers it is set by the driver. This
> data_offset typically contains meta data.

Is that documented somewhere ? I wasn't aware of this use case.

> > I can't really see a reason why data_offset couldn't be used for video
> > capture devices as well.
> > 
> > Sanity checks are currently missing. For output devices we should check
> > that data_offset + bytesused < length in the vb2 core. For input devices
> > the check will have to be performed by drivers. Taking data_offset into
> > account automatically would also be useful. I think most of that should
> > be possible to implement in the allocators.
> 
> See this proposal of how to solve this:
> 
> http://www.spinics.net/lists/linux-media/msg40376.html

This requires more discussions regarding how the app_offset and data_offset 
fields should be used for the different memory types we support.

For instance app_offset would not make that much sense for the USERPTR memory 
type, as we can include the offset in the user pointer already (using 
app_offset there would only make the code more complex without any added 
benefit).

For the MMAP memory type adding an app_offset would require allocating buffers 
large enough to accomodate the offset, and would thus only be useful with 
CREATE_BUFS. I'm also wondering whether the main use case (passing the buffer 
to another device that requires that app_offset) wouldn't be better addressed 
by the DMABUF memory type anyway.

Comments are welcome.

-- 
Regards,

Laurent Pinchart

[PATCH 04/12] v4l: vb2-dma-contig: add setup of sglist for MMAP buffers

[Laurent Pinchart]

Hi Tomasz,

On Wednesday 06 June 2012 13:56:42 Tomasz Stanislawski wrote:
> On 06/06/2012 10:06 AM, Laurent Pinchart wrote:
> > On Wednesday 23 May 2012 15:07:27 Tomasz Stanislawski wrote:
> >> This patch adds the setup of sglist list for MMAP buffers.
> >> It is needed for buffer exporting via DMABUF mechanism.
> >> 
> >> Signed-off-by: Tomasz Stanislawski 
> >> Signed-off-by: Kyungmin Park 
> >> ---
> >> 
> >>  drivers/media/video/videobuf2-dma-contig.c |   70 +-
> >>  1 file changed, 68 insertions(+), 2 deletions(-)
> >> 
> >> diff --git a/drivers/media/video/videobuf2-dma-contig.c
> >> b/drivers/media/video/videobuf2-dma-contig.c index 52b4f59..ae656be
> >> 100644
> >> --- a/drivers/media/video/videobuf2-dma-contig.c
> >> +++ b/drivers/media/video/videobuf2-dma-contig.c

[snip]

> >> +static int vb2_dc_kaddr_to_pages(unsigned long kaddr,
> >> +  struct page **pages, unsigned int n_pages)
> >> +{
> >> +  unsigned int i;
> >> +  unsigned long pfn;
> >> +  struct vm_area_struct vma = {
> >> +  .vm_flags = VM_IO | VM_PFNMAP,
> >> +  .vm_mm = current->mm,
> >> +  };
> >> +
> >> +  for (i = 0; i < n_pages; ++i, kaddr += PAGE_SIZE) {
> > 
> > The follow_pfn() kerneldoc mentions that it looks up a PFN for a user
> > address. The only users I've found in the kernel sources pass a user
> > address. Is it legal to use it for kernel addresses ?
> 
> It is not completely legal :). As I understand the mm code, the follow_pfn
> works only for IO/PFN mappings. This is the typical case (every case?) of
> mappings created by dma_alloc_coherent.
> 
> In order to make this function work for a kernel pointer, one has to create
> an artificial VMA that has IO/PFN bits on.
> 
> This solution is a hack-around for dma_get_pages (aka dma_get_sgtable). This
> way the dependency on dma_get_pages was broken giving a small hope of
> merging vb2 exporting.
> 
> Marek prepared a patchset 'ARM: DMA-mapping: new extensions for buffer
> sharing' that adds dma buffers with no kernel mappings and dma_get_sgtable
> function.
> 
> However this patchset is still in a RFC state.

That's totally understood :-) I'm fine with keeping the hack for now until the 
dma_get_sgtable() gets in a usable/mergeable state, please just mention it in 
the code with something like

/* HACK: This is a temporary workaround until the dma_get_sgtable() function 
becomes available. */

> I have prepared a patch that removes vb2_dc_kaddr_to_pages and substitutes
> it with dma_get_pages. It will become a part of vb2-exporter patches just
> after dma_get_sgtable is merged (or at least acked by major maintainers).

-- 
Regards,

Laurent Pinchart

[Bug 50805] New: radeon gpu driver bug on suspend/resume in 3.5-rc1

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

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

 Bug #: 50805
   Summary: radeon gpu driver bug on suspend/resume in 3.5-rc1
Classification: Unclassified
   Product: DRI
   Version: unspecified
  Platform: Other
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: austin.lund at gmail.com


Created attachment 62685
  --> https://bugs.freedesktop.org/attachment.cgi?id=62685
two samples of the kernel log

I get the attached traces with 3.5-rc1 after suspend/resume,
sometimes.  It doesn't always happen.  Usually happens at least once
in 10 suspend/resume cycles.  The first trace seems non fatal, but the
system locks up in the second one and needs to be rebooted.

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

[Bug 17902] [830M missing dvo driver] need support for DVO-LVDS via na2501

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

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

--- Comment #83 from thor at math.tu-berlin.de 2012-06-06 18:21:06 PDT ---
Finally, success!

I'm not quite sure why, but for reasons unclear to me the DVO chip only wants
to talk if the PLL is enabled and running and the screen resolution fits. In
addition, the system has apparently a "fake" VGA output that must be disabled
to have the system working properly. Otherwise, the KMS layer seems to want to
redirect the output to the VGA, and then drops dead, leaving an unusable screen
(and DVO!) behind. I do not know yet whether the physical VGA connector works,
but basically, here is the receipt:

1) Apply the patches I mentioned above. Especially, the bypass mode of the
scaler must be set as its function is unclear.

static void ns2501_dpms(struct intel_dvo_device *dvo, int mode)
{
  struct ns2501_priv *ns = (struct ns2501_priv *)(dvo->dev_priv);
  unsigned char ch;

  DRM_DEBUG_KMS("%s: Trying set the dpms of the DVO to
%d\n",__FUNCTION__,mode);

  if (ns->reg_8_set) {
ch = ns->reg_8_shadow;
  } else {
ch = NS2501_8_PD | NS2501_8_BPAS | NS2501_8_VEN | NS2501_8_HEN;
  }

  if (mode == DRM_MODE_DPMS_ON)
ch |= NS2501_8_PD;
  else
ch &= ~NS2501_8_PD;

  ch |= NS2501_8_BPAS;

  if (ns->reg_8_set == 0 || ns->reg_8_shadow != ch) {
ns->reg_8_set= 1;
ns->reg_8_shadow = ch;
ns2501_writeb(dvo, NS2501_REG8, ch);
  }
}

Here I added a shadow register which is likely not exactly necessary, though I
wanted to avoid the i2c communication if not necessary.


2) There is still a bug in the ns2501 source in so far as the query function
returns something unitialized if reading from the DVO fails. And it fails quite
often.

static enum drm_connector_status ns2501_detect(struct intel_dvo_device *dvo)
{
  uint8_t reg9;
  enum drm_connector_status status = connector_status_unknown;
  struct ns2501_priv *ns = (struct ns2501_priv *)(dvo->dev_priv);

  DRM_DEBUG_KMS("%s: Trying to detect the connector status\n",__FUNCTION__);


  if (ns2501_readb(dvo, NS2501_REG9, )) {
if (!(reg9 & NS2501_9_RSEN))
  status = connector_status_connected;
else
  status = connector_status_disconnected;

ns->reg_9_set= 1;
ns->reg_9_shadow = reg9;
  } else if (ns->reg_9_set) {
if (!(ns->reg_9_shadow & NS2501_9_RSEN))
  status = connector_status_connected;
else
  status = connector_status_disconnected;
  } 

  DRM_DEBUG_KMS("%s: Status is %d\n",__FUNCTION__,status);

  return status;
}

Again a shadow register was added.

3) The following kernel arguments should be added to disable the VGA output:

i915.modeset=1 video=VGA-1:1024x768d video=DVI-I-1:1024x768e

I'm not sure why the system behaives so strange otherwise, I'll try to dig a
bit deeper, but I believe that there is some limitation with the i830 and its
outputs. Probably I'll find a datasheet.

With the above modifications, you cannot, of course, scale the screen
(resolution is fixed), though 3D acceleration works nicely.

The same trick might also apply to the IBM R31, I'll check later next week - it
had similar issues.

(Is actually anyone reading this??? Is there a better way to supply patches?)

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

Circular locking (and possible deadlock), when exiting from mplayer -vo fbdev2

[Dan Carpenter]

Hi Dri devs,

Witold Baryluk  reported a lockdep splat
to the fbdev list, but apparently that was the wrong list and you
people are the right list to handle this.

Here is the lockdep splat and Witold's config:
http://marc.info/?l=linux-fbdev=133883191129462=2

I looked into the bug and it turns out there is a lock ordering
problem but I'm not sure how to fix it.
http://marc.info/?l=linux-fbdev=133890563322819=2

Cut and pasted from that URL:
---
The problem is we hold ->mmap_sem when we call fb_release() which
takes the info->lock.

We take the info->lock in do_fb_ioctl() before we call fb_set_var()
which calls drm_fb_helper_set_par() which takes the
mode_config.mutex.

In drm_mode_getresources() we take the mode_config.mutex() and call
put_user() which takes the ->mmap_sem.

So on one CPU we are holding the ->mmap_sem and want the info->lock.
On another CPU we are holding the info->lock and want the
config.mutex.  On the other CPU we hold the config.mutex and want
the ->mmap_sem.

Deadlock.
---

Could you take a look?

regards,
dan carpenter

Re: [PATCH 1/2] drm: drmIoctl return -errno on failure conditions

[Dave Airlie]

On Thu, Jun 7, 2012 at 12:41 AM, Ben Widawsky b...@bwidawsk.net wrote:
 Anyone aware of what this will break? It seems to be a much nicer thing
 to do for callers. If people do not like it, I will probably just create
 a #define drmIoctl2 or some such thing.



uggh no you going to redeine open/read/write as well?

think of it aa system call, they return -1 and set errno.

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

RE: [Linaro-mm-sig] [RFC] Synchronizing access to buffers shared with dma-buf between drivers/devices

[John Reitan]

Hi All,

I'm the original designer of the KDS system that Tom posted 
while I was on paternity leave. Find my responses inline...

 -Original Message-
 From: linaro-mm-sig-boun...@lists.linaro.org [mailto:linaro-mm-sig-
 boun...@lists.linaro.org] On Behalf Of Rob Clark
 Sent: Monday, June 04, 2012 10:31 PM
 To: Tom Cooksey
 Cc: linaro-mm-...@lists.linaro.org; Pauli; dri-
 de...@lists.freedesktop.org
 Subject: Re: [Linaro-mm-sig] [RFC] Synchronizing access to buffers
 shared with dma-buf between drivers/devices
 
 Some comments inline.. at this stage mostly superficial issues about
 how the API works, etc..  not had a chance to dig too much into the
 implementation yet (although some of my comments about the API would
 change those anyways).

It was the API we really wanted input on.
The implementation still leaves a bit to be desired. 

 Anyways, thanks for getting the ball rolling on this, and I think I
 can volunteer linaro to pick up and run w/ this if needed.
 
 On Fri, May 25, 2012 at 7:08 PM, Tom Cooksey tom.cook...@arm.com
 wrote:
  Hi All,
 
  I realise it's been a while since this was last discussed, however
 I'd like
  to bring up kernel-side synchronization again. By kernel-side
  synchronization, I mean allowing multiple drivers/devices wanting to
 access
  the same buffer to do so without bouncing up to userspace to resolve
  dependencies such as the display controller can't start scanning out
 a
  buffer until the GPU has finished rendering into it. As such, this
 is
  really just an optimization which reduces latency between E.g. The
 GPU
  finishing a rendering job and that buffer being scanned out. I
 appreciate
  this particular example is already solved on desktop graphics cards
 as the
  display controller and 3D core are both controlled by the same
 driver, so no
  generic mechanism is needed. However on ARM SoCs, the 3D core (like
 an ARM
  Mali) and display controller tend to be driven by separate drivers,
 so some
  mechanism is needed to allow both drivers to synchronize their access
 to
  buffers.
 
  There are multiple ways synchronization can be achieved, fences/sync
 objects
  is one common approach, however we're presenting a different
 approach.
  Personally, I quite like fence sync objects, however we believe it
 requires
  a lot of userspace interfaces to be changed to pass around sync
 object
  handles. Our hope is that the kds approach will require less effort
 to make
  use of as no existing userspace interfaces need to be changed. E.g.
 To use
  explicit fences, the struct drm_mode_crtc_page_flip would need a new
 members
  to pass in the handle(s) of sync object(s) which the flip depends on
 (I.e.
  don't flip until these fences fire). The additional benefit of our
 approach
  is that it prevents userspace specifying dependency loops which can
 cause a
  deadlock (see kds.txt for an explanation of what I mean here).
 
  I have waited until now to bring this up again because I am now able
 to
  share the code I was trying (and failing I think) to explain
 previously. The
  code has now been released under the GPLv2 from ARM Mali's developer
 portal,
  however I've attempted to turn that into a patch to allow it to be
 discussed
  on this list. Please find the patch inline below.
 
  While KDS defines a very generic mechanism, I am proposing that this
 code or
  at least the concepts be merged with the existing dma_buf code, so a
 the
  struct kds_resource members get moved to struct dma_buf, kds_*
 functions get
  renamed to dma_buf_* functions, etc. So I guess what I'm saying is
 please
  don't review the actual code just yet, only the concepts the code
 describes,
  where kds_resource == dma_duf.
 
 
  Cheers,
 
  Tom
 
 
 
  Author: Tom Cooksey tom.cook...@arm.com
  Date:   Fri May 25 10:45:27 2012 +0100
 
 Add new system to allow synchronizing access to resources
 
 See Documentation/kds.txt for details, however the general
 idea is that this kds framework synchronizes multiple drivers
 (clients) wanting to access the same resources, where a
 resource is typically a 2D image buffer being shared around
 using dma-buf.
 
 Note: This patch is created by extracting the sources from the
 tarball on http://www.malideveloper.com/open-source-mali-gpus-lin
 ux-kernel-device-drivers---dev-releases.php and putting them in
 roughly the right places.
 
  diff --git a/Documentation/kds.txt b/Documentation/kds.txt
 
 fwiw, I think the documentation could be made a bit more generic, but
 this and code style, etc shouldn't be too hard to fix
 
  new file mode 100644
  index 000..a96db21
  --- /dev/null
  +++ b/Documentation/kds.txt
  @@ -0,0 +1,113 @@
  +#
  +# (C) COPYRIGHT 2012 ARM Limited. All rights reserved.
  +#
  +# This program is free software and is provided to you under the
 terms of
  the GNU General Public License version 2
  +# as published by the Free Software Foundation, and any use by you
 of this
  program is 

Re: [Linaro-mm-sig] [RFC] Synchronizing access to buffers shared with dma-buf between drivers/devices

[Erik Gilling]

On Wed, Jun 6, 2012 at 6:33 AM, John Reitan john.rei...@arm.com wrote:
 But maybe instead of inventing something new, we can just use 'struct
 kthread_work' instead of 'struct kds_callback' plus the two 'void *'s?
  If the user needs some extra args they can embed 'struct
 kthread_work' in their own struct and use container_of() magic in the
 cb.

 Plus this is a natural fit if you want to dispatch callbacks instead
 on a kthread_worker, which seems like it would simplify a few things
 when it comes to deadlock avoidance.. ie., not resource deadlock
 avoidance, but dispatching callbacks when some lock is held.

 That sounds like a better approach.
 Will make a cleaner API, will look into it.

When Tom visited us for android graphics camp in the fall he argued
that there were cases where we would want to avoid an extra schedule.
Consider the case where the GPU is waiting for a render buffer that
the display controller is using.  If that render can be kicked off w/o
acquiring locks, the display's vsync IRQ handler can call release,
which in turn calls the GPU callback, which in turn kicks off the
render very quickly w/o having to leave IRQ context.

One way around the locking issue with callbacks/async wait is to have
async wait return a value to indicate that the resource has been
acquired instead of calling the callback.  This is the approach I
chose in our sync framework.

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

Re: Circular locking (and possible deadlock), when exiting from mplayer -vo fbdev2

[Dan Carpenter]

Hi Dri devs,

Witold Baryluk bary...@smp.if.uj.edu.pl reported a lockdep splat
to the fbdev list, but apparently that was the wrong list and you
people are the right list to handle this.

Here is the lockdep splat and Witold's config:
http://marc.info/?l=linux-fbdevm=133883191129462w=2

I looked into the bug and it turns out there is a lock ordering
problem but I'm not sure how to fix it.
http://marc.info/?l=linux-fbdevm=133890563322819w=2

Cut and pasted from that URL:
---
The problem is we hold -mmap_sem when we call fb_release() which
takes the info-lock.

We take the info-lock in do_fb_ioctl() before we call fb_set_var()
which calls drm_fb_helper_set_par() which takes the
mode_config.mutex.

In drm_mode_getresources() we take the mode_config.mutex() and call
put_user() which takes the -mmap_sem.

So on one CPU we are holding the -mmap_sem and want the info-lock.
On another CPU we are holding the info-lock and want the
config.mutex.  On the other CPU we hold the config.mutex and want
the -mmap_sem.

Deadlock.
---

Could you take a look?

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

Re: [Linaro-mm-sig] [PATCHv6 00/13] Integration of videobuf2 with dmabuf

[Hans Verkuil]

On Thu June 7 2012 02:52:06 Laurent Pinchart wrote:
 Hi Hans,
 
 On Wednesday 06 June 2012 10:17:03 Hans Verkuil wrote:
  On Wed 6 June 2012 05:46:34 Laurent Pinchart wrote:
   On Monday 04 June 2012 12:34:23 Rebecca Schultz Zavin wrote:
I have a system where the data is planar, but the kernel drivers
expect to get one allocation with offsets for the planes.  I can't
figure out how to do that with the current dma_buf implementation.  I
thought I could pass the same dma_buf several times and use the
data_offset field of the v4l2_plane struct but it looks like that's
only for output.  Am I missing something?  Is this supported?
   
   data_offset is indeed for video output only at the moment, and doesn't
   seem to be used by any driver in mainline for now.
  
  Actually, data_offset may be set by capture drivers. For output buffers it
  is set by userspace, for capture buffers it is set by the driver. This
  data_offset typically contains meta data.
 
 Is that documented somewhere ? I wasn't aware of this use case.

It is documented in the proposal that Pawel sent, but very poorly if at all in
the spec. That needs to be improved.

   I can't really see a reason why data_offset couldn't be used for video
   capture devices as well.
   
   Sanity checks are currently missing. For output devices we should check
   that data_offset + bytesused  length in the vb2 core. For input devices
   the check will have to be performed by drivers. Taking data_offset into
   account automatically would also be useful. I think most of that should
   be possible to implement in the allocators.
  
  See this proposal of how to solve this:
  
  http://www.spinics.net/lists/linux-media/msg40376.html
 
 This requires more discussions regarding how the app_offset and data_offset 
 fields should be used for the different memory types we support.
 
 For instance app_offset would not make that much sense for the USERPTR memory 
 type, as we can include the offset in the user pointer already (using 
 app_offset there would only make the code more complex without any added 
 benefit).
 
 For the MMAP memory type adding an app_offset would require allocating 
 buffers 
 large enough to accomodate the offset, and would thus only be useful with 
 CREATE_BUFS. I'm also wondering whether the main use case (passing the buffer 
 to another device that requires that app_offset) wouldn't be better addressed 
 by the DMABUF memory type anyway.

I'm not going to pursue this unless Google indicates that they need this. And
actually I would suggest that they ask Pawel to work on this, after all he made
the proposal AND he works for Google :-)

Regards,

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

Re: [PATCH 2/2 v4] intel: wait render timeout implementation

[Daniel Vetter]

On Wed, Jun 06, 2012 at 04:42:11PM -0700, Ben Widawsky wrote:
 int drm_intel_gem_bo_wait(drm_intel_bo *bo, uint64_t timeout_ns)
 
 This should bump the libdrm version. We're waiting for context support
 so we can do both features in one bump.
 
 v2: don't return remaining timeout amount
 use get param and fallback for older kernels
 
 v3: only doing getparam at init
 prototypes now have a signed input value
 
 v4: update comments
 fall back to correct polling behavior with new userspace and old kernel
 
 Cc: Eric Anholt e...@anholt.net
 Cc: Daniel Vetter daniel.vet...@ffwll.ch
 Signed-off-by: Ben Widawsky b...@bwidawsk.net
 ---
  intel/intel_bufmgr.h |1 +
  intel/intel_bufmgr_gem.c |   51 
 ++
  2 files changed, 52 insertions(+)
 
 diff --git a/intel/intel_bufmgr.h b/intel/intel_bufmgr.h
 index c197abc..fa6c4dd 100644
 --- a/intel/intel_bufmgr.h
 +++ b/intel/intel_bufmgr.h
 @@ -184,6 +184,7 @@ int drm_intel_get_pipe_from_crtc_id(drm_intel_bufmgr 
 *bufmgr, int crtc_id);
  
  int drm_intel_get_aperture_sizes(int fd, size_t *mappable, size_t *total);
  int drm_intel_bufmgr_gem_get_devid(drm_intel_bufmgr *bufmgr);
 +int drm_intel_gem_bo_wait(drm_intel_bo *bo, int64_t timeout_ns);
  
  /* drm_intel_bufmgr_fake.c */
  drm_intel_bufmgr *drm_intel_bufmgr_fake_init(int fd,
 diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
 index b776d2f..f8e3706 100644
 --- a/intel/intel_bufmgr_gem.c
 +++ b/intel/intel_bufmgr_gem.c
 @@ -119,6 +119,7 @@ typedef struct _drm_intel_bufmgr_gem {
   unsigned int has_blt : 1;
   unsigned int has_relaxed_fencing : 1;
   unsigned int has_llc : 1;
 + unsigned int has_wait_timeout : 1;
   unsigned int bo_reuse : 1;
   unsigned int no_exec : 1;
   bool fenced_relocs;
 @@ -1479,6 +1480,52 @@ drm_intel_gem_bo_wait_rendering(drm_intel_bo *bo)
  }
  
  /**
 + * Waits on a BO for the given amount of time.
 + *
 + * @bo: buffer object to wait for
 + * @timeout_ns: amount of time to wait in nanoseconds.
 + *   If value is less than 0, an infinite wait will occur.
 + *
 + * Returns 0 if the wait was successful ie. the last batch referencing the
 + * object has completed within the allotted time. Otherwise some negative 
 return
 + * value describes the error.

I'm not too sure about that being correct yet. Iirc drmIoctl simply
returns -1 on error, with the (positive error number stored in errno),
and the busy function returns 1 when the thing is busy. I think we should
map both properly to the same -ETIME.
-Daniel

 + *
 + * Similar to drm_intel_gem_bo_wait_rendering except a timeout parameter 
 allows
 + * the operation to give up after a certain amount of time. Another subtle
 + * difference is the internal locking semantics are different (this variant 
 does
 + * not hold the lock for the duration of the wait). This makes the wait 
 subject
 + * to a larger userspace race window.
 + *
 + * The implementation shall wait until the object is no longer actively
 + * referenced within a batch buffer at the time of the call. The wait will
 + * not guarantee that the buffer is re-issued via another thread, or an 
 flinked
 + * handle. Userspace must make sure this race does not occur if such 
 precision
 + * is important.
 + */
 +int drm_intel_gem_bo_wait(drm_intel_bo *bo, int64_t timeout_ns)
 +{
 + drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *) bo-bufmgr;
 + drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *) bo;
 + struct drm_i915_gem_wait wait;
 +
 + if (!bufmgr_gem-has_wait_timeout) {
 + DBG(%s:%d: Timed wait is not supported. Falling back to 
 + infinite wait\n, __FILE__, __LINE__);
 + if (timeout_ns) {
 + drm_intel_gem_bo_wait_rendering(bo);
 + return 0;
 + } else {
 + return drm_intel_gem_bo_busy(bo);
 + }
 + }
 +
 + wait.bo_handle = bo_gem-gem_handle;
 + wait.timeout_ns = timeout_ns;
 + wait.flags = 0;
 + return drmIoctl(bufmgr_gem-fd, DRM_IOCTL_I915_GEM_WAIT, wait);
 +}
 +
 +/**
   * Sets the object to the GTT read and possibly write domain, used by the X
   * 2D driver in the absence of kernel support to do 
 drm_intel_gem_bo_map_gtt().
   *
 @@ -2898,6 +2945,10 @@ drm_intel_bufmgr_gem_init(int fd, int batch_size)
   ret = drmIoctl(bufmgr_gem-fd, DRM_IOCTL_I915_GETPARAM, gp);
   bufmgr_gem-has_relaxed_fencing = ret == 0;
  
 + gp.param = I915_PARAM_HAS_WAIT_TIMEOUT;
 + ret = drmIoctl(bufmgr_gem-fd, DRM_IOCTL_I915_GETPARAM, gp);
 + bufmgr_gem-has_wait_timeout = ret == 0;
 +
   gp.param = I915_PARAM_HAS_LLC;
   ret = drmIoctl(bufmgr_gem-fd, DRM_IOCTL_I915_GETPARAM, gp);
   if (ret != 0) {
 -- 
 1.7.10.3
 

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

Re: edp backtrace spam on MacBookAir4,1

[Daniel Vetter]

On Wed, May 30, 2012 at 08:39:13AM -0700, Linus Torvalds wrote:
 On Wed, May 30, 2012 at 1:27 AM, Daniel Vetter dan...@ffwll.ch wrote:
 
  Ok, Chris couldn't reproduce this on his mba. Can you please boot with
  drm.debug=0xe, reproduce the noise and then attach the full dmesg?
 
 Hmm. Now *I* can't reproduce it either.
 
 I have updated my system in the meantime, so maybe this is related to
 that. However, I suspect it's more likely that it's some race
 condition, because when I got it, I got a *lot* of it, but they were
 all very tightly bunched together:
 
  [ 1588.996413] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
 intel_dp_check_edp+0x5d/0xb0()
  [ 1588.996650] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
 intel_dp_check_edp+0x5d/0xb0()
  [ 1589.000983] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
 intel_dp_check_edp+0x5d/0xb0()
  [ 1589.001225] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
 intel_dp_check_edp+0x5d/0xb0()
  [ 1589.005975] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
 intel_dp_check_edp+0x5d/0xb0()
  [ 1589.006218] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
 intel_dp_check_edp+0x5d/0xb0()
  [ 1589.010980] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
 intel_dp_check_edp+0x5d/0xb0()
  [ 1589.011224] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
 intel_dp_check_edp+0x5d/0xb0()
  [ 1589.015976] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
 intel_dp_check_edp+0x5d/0xb0()
  [ 1589.016211] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
 intel_dp_check_edp+0x5d/0xb0()
  [ 1589.020986] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
 intel_dp_check_edp+0x5d/0xb0()
  [ 1589.021232] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
 intel_dp_check_edp+0x5d/0xb0()
 
 ie that's 12 of those warnings (each of them with that huge backtrace
 etc), but they are all within 0.03 seconds of each other. So I suspect
 it needs to hit some particular timing window, and I was just
 (un)lucky.
 
 Because when I try it now with DRM debugging, I can't hit it. And just
 to make sure, I re-did the test without debugging too (in case the
 debugging would have changed timing), but can't reproduce it that way
 either.

Meh, I've been totally blind. Note to self: Next time around actually look
at the backtrace. And I dunno how that escaped our dear QA that long ...

Below patch should shut this up (and might even fix an edp panel not
getting up again after having been switched off).

Yours, Daniel
---
From c56769c92f684d708b05052ec4f4555ea25da4de Mon Sep 17 00:00:00 2001
From: Daniel Vetter daniel.vet...@ffwll.ch
Date: Thu, 7 Jun 2012 08:59:49 +0200
Subject: [PATCH] drm/i915: enable edp vdd in intel_dp_detect

We need this for dp aux communication. This issue can fill the dmesg
with WARN spam when the panel is disable (e.g. while reconfiguring the
mode or while resuming).

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50808
Reported-by: Linus Torvalds torva...@linux-foundation.org
Bugreport: http://permalink.gmane.org/gmane.comp.video.dri.devel/69695
Cc: sta...@vger.kernel.org
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/intel_dp.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 296cfc2..9a7edcf 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2165,6 +2165,7 @@ intel_dp_detect(struct drm_connector *connector, bool 
force)
if (status != connector_status_connected)
return status;
 
+   ironlake_edp_panel_vdd_on(intel_dp);
intel_dp_probe_oui(intel_dp);
 
if (intel_dp-force_audio != HDMI_AUDIO_AUTO) {
@@ -2177,6 +2178,7 @@ intel_dp_detect(struct drm_connector *connector, bool 
force)
kfree(edid);
}
}
+   ironlake_edp_panel_vdd_off(intel_dp, false);
 
return connector_status_connected;
 }
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: edp backtrace spam on MacBookAir4,1

[Daniel Vetter]

On Thu, Jun 07, 2012 at 09:21:20AM +0200, Daniel Vetter wrote:
 On Wed, May 30, 2012 at 08:39:13AM -0700, Linus Torvalds wrote:
  On Wed, May 30, 2012 at 1:27 AM, Daniel Vetter dan...@ffwll.ch wrote:
  
   Ok, Chris couldn't reproduce this on his mba. Can you please boot with
   drm.debug=0xe, reproduce the noise and then attach the full dmesg?
  
  Hmm. Now *I* can't reproduce it either.
  
  I have updated my system in the meantime, so maybe this is related to
  that. However, I suspect it's more likely that it's some race
  condition, because when I got it, I got a *lot* of it, but they were
  all very tightly bunched together:
  
   [ 1588.996413] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
  intel_dp_check_edp+0x5d/0xb0()
   [ 1588.996650] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
  intel_dp_check_edp+0x5d/0xb0()
   [ 1589.000983] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
  intel_dp_check_edp+0x5d/0xb0()
   [ 1589.001225] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
  intel_dp_check_edp+0x5d/0xb0()
   [ 1589.005975] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
  intel_dp_check_edp+0x5d/0xb0()
   [ 1589.006218] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
  intel_dp_check_edp+0x5d/0xb0()
   [ 1589.010980] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
  intel_dp_check_edp+0x5d/0xb0()
   [ 1589.011224] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
  intel_dp_check_edp+0x5d/0xb0()
   [ 1589.015976] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
  intel_dp_check_edp+0x5d/0xb0()
   [ 1589.016211] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
  intel_dp_check_edp+0x5d/0xb0()
   [ 1589.020986] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
  intel_dp_check_edp+0x5d/0xb0()
   [ 1589.021232] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
  intel_dp_check_edp+0x5d/0xb0()
  
  ie that's 12 of those warnings (each of them with that huge backtrace
  etc), but they are all within 0.03 seconds of each other. So I suspect
  it needs to hit some particular timing window, and I was just
  (un)lucky.
  
  Because when I try it now with DRM debugging, I can't hit it. And just
  to make sure, I re-did the test without debugging too (in case the
  debugging would have changed timing), but can't reproduce it that way
  either.
 
 Meh, I've been totally blind. Note to self: Next time around actually look
 at the backtrace. And I dunno how that escaped our dear QA that long ...

Even more meh, this patch might actually work a bit better.

/me doesn't have an edp panel to test this

-Daniel
---
From 709e3d49d83fb7f1c297c7c0d9e994af6571bbdb Mon Sep 17 00:00:00 2001
From: Daniel Vetter daniel.vet...@ffwll.ch
Date: Thu, 7 Jun 2012 08:59:49 +0200
Subject: [PATCH] drm/i915: enable edp vdd in intel_dp_detect

We need this for dp aux communication. This issue can fill the dmesg
with WARN spam when the panel is disable (e.g. while reconfiguring the
mode or while resuming).

v2: Actually enable edp vdd early enough. I've missed one dp aux
channel thingy ...

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50808
Reported-by: Linus Torvalds torva...@linux-foundation.org
Bugreport: http://permalink.gmane.org/gmane.comp.video.dri.devel/69695
Cc: sta...@vger.kernel.org
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/intel_dp.c |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 296cfc2..547cdc6 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2152,6 +2152,7 @@ intel_dp_detect(struct drm_connector *connector, bool 
force)
 
intel_dp-has_audio = false;
 
+   ironlake_edp_panel_vdd_on(intel_dp);
if (HAS_PCH_SPLIT(dev))
status = ironlake_dp_detect(intel_dp);
else
@@ -2162,8 +2163,10 @@ intel_dp_detect(struct drm_connector *connector, bool 
force)
  intel_dp-dpcd[3], intel_dp-dpcd[4], intel_dp-dpcd[5],
  intel_dp-dpcd[6], intel_dp-dpcd[7]);
 
-   if (status != connector_status_connected)
+   if (status != connector_status_connected) {
+   ironlake_edp_panel_vdd_off(intel_dp, false);
return status;
+   }
 
intel_dp_probe_oui(intel_dp);
 
@@ -2177,6 +2180,7 @@ intel_dp_detect(struct drm_connector *connector, bool 
force)
kfree(edid);
}
}
+   ironlake_edp_panel_vdd_off(intel_dp, false);
 
return connector_status_connected;
 }
-- 
1.7.10

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

[Bug 50655] ATI RV670 [Radeon HD 3870] Ioquake games causes GPU lockup (waiting for 0x00003039 last fence id 0x00003030)

[bugzilla-daemon]

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

Michel Dänzer mic...@daenzer.net changed:

   What|Removed |Added

 CC||mar...@gmail.com

--- Comment #11 from Michel Dänzer mic...@daenzer.net 2012-06-07 00:40:00 PDT 
---
Marek, any ideas? (bug 47116 might be related)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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] Documentation: DRM framework documentation

[Laurent Pinchart]

Hi Rob,

On Tuesday 05 June 2012 04:31:54 Rob Clark wrote:
 Hey, thanks Laurent, this was quite needed!
 
 I apologize in advance for the html mail.. but reviewing this on the flight
 home from connect and can't figure out how to do plain text email w/
 google's offline mail client :-(

No worries. Thanks for the review.

 On Wednesday, May 30, 2012, Laurent Pinchart wrote:
  Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
  ---
  
   Documentation/drm.txt | 1265
  
  +
  
   1 files changed, 1265 insertions(+), 0 deletions(-)
   create mode 100644 Documentation/drm.txt
  
  Hi everybody,
  
  Here's the DRM kernel framework documentation I wrote while developing the
  Renesas SH Mobile DRM driver. It hopefully covers most of what's needed to
  write a simple DRM driver (although some areas are not documented, such as
  properties or the fbdev compatibility layer).
  
  I can convert the documentation to DocBook if needed and integrate it with
  the existing documentation stub. In that case I'm thinking of splitting
  the DocBook documentation in two parts, userspace API documentation (that
  someone would have to fill, any volunteer ? ;-)) and kernel API
  documentation. Would that be fine ?
  
  Last but not least, now that documentation exists (albeit in an incomplete
  state), we need to make sure it won't get outdated too quickly. As nobody
  will volunteer to maintain it (feel free to prove me wrong though), I'd
  like to propose the same rule that we already follow in V4L: any patch
  that touches the API won't get merged if it doesn't update the
  documentation. Do you think this could work out ?
 
 seems like a pretty reasonable idea

Let's work together on nacking patches that don't include documentation then 
:-)

  As usual, review will be appreciated.
  
  diff --git a/Documentation/drm.txt b/Documentation/drm.txt
  new file mode 100644
  index 000..4d8843d
  --- /dev/null
  +++ b/Documentation/drm.txt
  @@ -0,0 +1,1265 @@

[snip]

  +  - int (*firstopen) (struct drm_device *)
  +  - void (*lastclose) (struct drm_device *)
  +  - int (*open) (struct drm_device *, struct drm_file *)
  +  - void (*preclose) (struct drm_device *, struct drm_file *)
  +  - void (*postclose) (struct drm_device *, struct drm_file *)
  +
  +  Open and close handlers. None of those methods are mandatory.
  +
  +  The .firstopen() method is called by the DRM core when an application
  opens
  +  a device that has no other opened file handle. Similarly the
  .lastclose()
  +  method is called when the last application holding a file handle opened
  on
  +  the device closes it. Both methods are mostly used for UMS (User Mode
  +  Setting) drivers to acquire and release device resources which should
  be
  +  done in the .load() and .unload() methods for KMS drivers.
  +
  +  Note that the .lastclose() method is also called at module unload time
  or,
  +  for hot-pluggable devices, when the device is unplugged. The
  .firstopen()
  +  and .lastclose() calls can thus be unbalanced.
  +
 
 AFAIK lastclose() should also be drm_fb_helper_restore_fbdev_mode() to
 restore fbcon mode.

Good point. I haven't documented the fbdev helper yet, I'll keep that in mind 
when updating the documentation.

 I'm also restoring crtc and plane properties to default values here, so a
 subsequent open of the device isn't inheriting some state from the previous
 user.

That's very unlike V4L2, where we explicitly require state to be kept across 
opens. Is restoring properties a DRM standard behaviour, implemented by other 
drivers as well ?

 (maybe some of this could be handled instead in core, rather than each
 driver.. could be an idea for a cleanup?)
 
  +  The .open() method is called every time the device is opened by an
  +  application. Drivers can allocate per-file private data in this method
  and
  +  store them in the struct drm_file::driver_priv field. Note that the
  .open()
  +  method is called before .firstopen().
  +
  +  The close operation is split into .preclose() and .postclose() methods.
  +  Drivers must stop and cleanup all per-file operations in the
  .preclose()
  +  method. For instance pending vertical blanking and page flip events
  must be
  +  cancelled. No per-file operation is allowed on the file handle after
  +  returning from the .preclose() method.
 
 oh, heh, I completely missed that in omapdrm, so looks like I need to do
 some cleanup around here..  I wonder if there is any sane way to make this
 simpler for the driver writer, since basically all drivers would need to do
 the same thing here..  Ie. keep track of pending page_flip events, sort of
 analogous to how the core keeps track of pending vblank events..

 Are there any drivers that can queue up more than one page flip per crtc at
 a time?  If no, we could track pending page flip event in 'struct drm_crtc'
 and then have a drm_crtc_handle_page_flip_events(crtc), similar
 to 

Re: edp backtrace spam on MacBookAir4,1

[Paul Menzel]

Am Donnerstag, den 07.06.2012, 09:26 +0200 schrieb Daniel Vetter:

[…]

 From 709e3d49d83fb7f1c297c7c0d9e994af6571bbdb Mon Sep 17 00:00:00 2001
 From: Daniel Vetter daniel.vet...@ffwll.ch
 Date: Thu, 7 Jun 2012 08:59:49 +0200
 Subject: [PATCH] drm/i915: enable edp vdd in intel_dp_detect
 
 We need this for dp aux communication. This issue can fill the dmesg

What issue?

 with WARN spam when the panel is disable (e.g. while reconfiguring the

disable*d*

 mode or while resuming).
 
 v2: Actually enable edp vdd early enough. I've missed one dp aux
 channel thingy ...
 
 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50808
 Reported-by: Linus Torvalds torva...@linux-foundation.org
 Bugreport: http://permalink.gmane.org/gmane.comp.video.dri.devel/69695
 Cc: sta...@vger.kernel.org
 Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
 ---
  drivers/gpu/drm/i915/intel_dp.c |6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

[…]


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Synchronization framework

[Maarten Lankhorst]

Hey,

For intel/nouveau hybrid graphics I'm interested in this since it
would allow me to synchronize between intel and nvidia cards
without waiting for rendering to complete.

I'm worried about the api though, nouveau and intel already
have existing infrastructure to deal with fencing so exposing
additional ioctl's will complicate the implementation. Would
it be possible to never expose this interface to userspace
but keep it inside the kernel only?

nouveau_gem_ioctl_pushbuf is what's used for nouveau.
If any dmabuf synch framework could hook into that then
userspace would never have to act differently on shared bo's.

I haven't looked at intel and amd, but from a quick glance
it seems like they already implement fencing too, so just
some way to synch up the fences on shared buffers seems
like it could benefit all graphics drivers and the whole
userspace synching could be done away with entirely.

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

Re: [RFC] Documentation: DRM framework documentation

[Hans Verkuil]

Hi Laurent!

I completely missed this when you posted this a week ago, but thank you for
doing this. One suggestion: cross-post the next version to linux-media as well:
I think this is useful for V4L2 as well.

Some comments below:

On Wed 30 May 2012 15:13:29 Laurent Pinchart wrote:
 Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
 ---
  Documentation/drm.txt | 1265 
 +
  1 files changed, 1265 insertions(+), 0 deletions(-)
  create mode 100644 Documentation/drm.txt
 
 Hi everybody,
 
 Here's the DRM kernel framework documentation I wrote while developing the
 Renesas SH Mobile DRM driver. It hopefully covers most of what's needed to
 write a simple DRM driver (although some areas are not documented, such as
 properties or the fbdev compatibility layer).
 
 I can convert the documentation to DocBook if needed and integrate it with the
 existing documentation stub. In that case I'm thinking of splitting the
 DocBook documentation in two parts, userspace API documentation (that someone
 would have to fill, any volunteer ? ;-)) and kernel API documentation. Would
 that be fine ?
 
 Last but not least, now that documentation exists (albeit in an incomplete
 state), we need to make sure it won't get outdated too quickly. As nobody will
 volunteer to maintain it (feel free to prove me wrong though), I'd like to
 propose the same rule that we already follow in V4L: any patch that touches
 the API won't get merged if it doesn't update the documentation. Do you think
 this could work out ?

I strongly recommend that this policy is adopted. It is working out very well
in V4L2. Documentation can be a pain, but if you do it when you add new
functionality (and you still remember what it was you did :-) ), then it isn't
too bad.

 As usual, review will be appreciated.
 
 diff --git a/Documentation/drm.txt b/Documentation/drm.txt
 new file mode 100644
 index 000..4d8843d
 --- /dev/null
 +++ b/Documentation/drm.txt
 @@ -0,0 +1,1265 @@
 + Architecture of a DRM driver
 +i
 +
 +Written by Laurent Pinchart laurent.pinch...@ideasonboard.com
 +Last revised: May 30, 2012
 +
 +
 +1. Driver initialization
 +

snip

 +3. KMS initialization
 +-
 +
 +Drivers must first initialize the mode configuration core by calling
 +drm_mode_config_init() on the DRM device. The function initializes the
 +drm_device::mode_config field and never fails. Once done, mode configuration
 +must be setup by
 +
 +  - int min_width, min_height
 +  - int max_width, max_height
 +
 +  Minimum and maximum width and height of the frame buffers in pixel units.
 +
 +  - struct drm_mode_config_funcs *funcs
 +
 +  Basic mode setting functions. See the Mode Setting Operations section for
 +  details.
 +
 +
 +A KMS device is abstracted and exposed as a set of planes, CRTCs, encoders 
 and
 +connectors. KMS drivers must thus create and initialize all those objects at
 +load time.
 +
 +- CRCTs (struct drm_crtc)

typo: CRCT - CRTC

 +
 +A CRTC is an abstraction representing a part of the chip that contains a
 +pointer to a scanout buffer.

A definition of a 'scanout buffer' would be useful here. Also: what does CRTC
stand for?

In general, I think it would be good to explain abbreviations (DRM, GEM, KMS,
etc.) That way the terminology is easier to understand.

 Therefore, the number of CRTCs available
 +determines how many independent scanout buffers can be active at any given
 +time. The CRTC structure contains several fields to support this: a pointer 
 to
 +some video memory (abstracted as a frame buffer object), a display mode, and
 +an (x, y) offset into the video memory to support panning or configurations
 +where one piece of video memory spans multiple CRTCs.
 +
 +A KMS device must create and register at least one struct drm_crtc instance.
 +The instance is allocated and zeroed by the driver, possibly as part of a
 +larger structure, and registered with a call to drm_crtc_init() with a 
 pointer
 +to CRTC functions.
 +
 +- Planes (struct drm_plane)
 +
 +A plane represents an image source that can be blended with or overlayed on
 +top of a CRTC during the scanout process. Planes are associated with a frame
 +buffer to crop a portion of the image memory (source) and optionally scale it
 +to a destination size. The result is then blended with or overlayed on top of
 +a CRTC.
 +
 +Planes are optional. To create a plane, a KMS drivers allocates and zeroes an
 +instances of struct drm_plane (possible as part of a larger structure) and
 +registers it with a call to drm_plane_init(). The function takes a bitmask of
 +the CRTCs that can be associated with the plane, a pointer to the plane
 +functions and a list of format supported formats.
 +
 +- Encoders (struct drm_encoder)
 +
 +An encoder takes pixel data from a CRTC and converts it to a format suitable
 +for any attached connectors. On some devices, it 

[PATCH 0/2] HD-audio HDMI regression fixes with VGA-switcheroo

[Takashi Iwai]

Hi,

this is a series of patches to fix the regressions of HD-audio HDMI
on D-GPUs in 3.5-rc1 due to the support of VGA-switcheroo audio clients.

The first patch adds a new helper function to vga-switcheroo and the
second just uses that instead of an open code.

Dave, if the first patch is OK, I'm going to apply it though sound tree.
Let me know if any problem is found.

Joerg, could you check whether this doesn't break your setup, too?


thanks,

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

[PATCH 1/2] vga_switcheroo: Add a helper function to get the client state

[Takashi Iwai]

Add vga_switcheroo_get_client_state() to get the current state of the
client.  This is necessary to determine the proper initial state of
audio clients in HD-audio driver.

Signed-off-by: Takashi Iwai ti...@suse.de
---
 drivers/gpu/vga/vga_switcheroo.c |   13 +
 include/linux/vga_switcheroo.h   |9 +
 2 files changed, 22 insertions(+)

diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
index 38f9534..eb4f64f 100644
--- a/drivers/gpu/vga/vga_switcheroo.c
+++ b/drivers/gpu/vga/vga_switcheroo.c
@@ -190,6 +190,19 @@ find_active_client(struct list_head *head)
return NULL;
 }
 
+int vga_switcheroo_get_client_state(struct pci_dev *pdev)
+{
+   struct vga_switcheroo_client *client;
+
+   client = find_client_from_pci(vgasr_priv.clients, pdev);
+   if (!client)
+   return VGA_SWITCHEROO_NOT_FOUND;
+   if (!vgasr_priv.active)
+   return VGA_SWITCHEROO_INIT;
+   return client-pwr_state;
+}
+EXPORT_SYMBOL(vga_switcheroo_get_client_state);
+
 void vga_switcheroo_unregister_client(struct pci_dev *pdev)
 {
struct vga_switcheroo_client *client;
diff --git a/include/linux/vga_switcheroo.h b/include/linux/vga_switcheroo.h
index b455c7c..661fb7a 100644
--- a/include/linux/vga_switcheroo.h
+++ b/include/linux/vga_switcheroo.h
@@ -12,6 +12,9 @@
 enum vga_switcheroo_state {
VGA_SWITCHEROO_OFF,
VGA_SWITCHEROO_ON,
+   /* below are referred only from vga_switcheroo_get_client_state() */
+   VGA_SWITCHEROO_INIT,
+   VGA_SWITCHEROO_NOT_FOUND,
 };
 
 enum vga_switcheroo_client_id {
@@ -50,6 +53,8 @@ void vga_switcheroo_unregister_handler(void);
 
 int vga_switcheroo_process_delayed_switch(void);
 
+int vga_switcheroo_get_client_state(struct pci_dev *dev);
+
 #else
 
 static inline void vga_switcheroo_unregister_client(struct pci_dev *dev) {}
@@ -62,5 +67,9 @@ static inline int vga_switcheroo_register_audio_client(struct 
pci_dev *pdev,
int id, bool active) { return 0; }
 static inline void vga_switcheroo_unregister_handler(void) {}
 static inline int vga_switcheroo_process_delayed_switch(void) { return 0; }
+static inline int vga_switcheroo_get_client_state(struct pci_dev *dev) {
+   return VGA_SWITCHEROO_CLIENT_ON;
+}
+
 
 #endif
-- 
1.7.10.4

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

[PATCH 2/2] ALSA: hda - Fix uninitialized HDMI controllers with VGA-switcheroo

[Takashi Iwai]

When VGA-switcheroo is built in but unused on systems with multiple
graphics cards, the initializations of non-default graphics cards are
skipped and never enabled (because the switcheroo is activated only
when the controller supports).  The current behavior is for avoiding
the system lockup by accessing the disabled GPU, but due to the recent
change in VGA-switcheroo, it determines the state simply by checking
with the default VGA device.  This is the culprit.

Now with the new vga_switcheroo_get_client_state(), we can know the
initial state of the bound GPU, thus can determine the initial audio
client state more correctly.

Signed-off-by: Takashi Iwai ti...@suse.de
---
 sound/pci/hda/hda_intel.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 2b6392b..5f0375f 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -2670,7 +2670,7 @@ static bool __devinit check_hdmi_disabled(struct pci_dev 
*pci)
struct pci_dev *p = get_bound_vga(pci);
 
if (p) {
-   if (vga_default_device()  p != vga_default_device())
+   if (vga_switcheroo_get_client_state(p) == VGA_SWITCHEROO_OFF)
vga_inactive = true;
pci_dev_put(p);
}
-- 
1.7.10.4

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

[Bug 13249] Intel 945GM: Boot option`vga=0x31a' breaks display of TTYs

[bugzilla-daemon]

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


Alan a...@lxorguk.ukuu.org.uk changed:

   What|Removed |Added

 Status|NEEDINFO|RESOLVED
 CC||a...@lxorguk.ukuu.org.uk
 Resolution||OBSOLETE




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- 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 13249] Intel 945GM: Boot option`vga=0x31a' breaks display of TTYs

[bugzilla-daemon]

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


Alan a...@lxorguk.ukuu.org.uk changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- 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 13364] BUG: unable to handle kernel paging request at 429a4c40

[bugzilla-daemon]

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


Alan a...@lxorguk.ukuu.org.uk changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||a...@lxorguk.ukuu.org.uk
 Resolution||OBSOLETE




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- 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

[Bug 36602] Hierarchical Z support for R600

[bugzilla-daemon]

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

--- Comment #46 from Andy Furniss li...@andyfurniss.entadsl.com 2012-06-07 
04:19:52 PDT ---
(In reply to comment #45)
 Thanks Jerome

+1.

Getting +20% fps with etqw on my 4890.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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: [Linaro-mm-sig] [RFC] Synchronizing access to buffers shared with dma-buf between drivers/devices

[Tom Cooksey]

  The bigger issue is the previous point about how to deal
  with cases where the CPU doesn't really need to get involved as an
  intermediary.
 
  CPU fallback access to the buffer is the only legit case where we
  need a standardized API to userspace (since CPU access isn't already
  associated w/ some other kernel device file where some extra ioctl
  can be added)
 
  The CPU case will still need to wait on an arbitrarily backed sync
  primitive.  It shouldn't need to know if it's backed by the gpu,
  camera, or dsp.
 
  Right, this is the one place we definitely need something.. some
  userspace code would just get passed a dmabuf file descriptor and
  want to mmap it and do something, without really knowing where it
  came from.  I *guess* we'll have to add some ioctl's to the dmabuf
  fd.
 
 I personally favor having sync primitives have their own anon inode
 vs. strictly coupling them with dma_buf.

I think this is really the crux of the matter - do we associate sync
objects with buffers or not. The approach ARM are suggesting _is_ to
associate the sync objects with the buffer and do this by adding
kds_resource* as a member of struct dma_buf. The main reason I want
to do this is because it doesn't require changes to existing
interfaces. Specifically, DRM/KMS  v4l2. These user/kernel interfaces
already allow userspace to specify the handle of a buffer the driver
should perform an operation on. What dma_buf has done is allowed those
driver-specific buffer handles to be exported from one driver and
imported into another. While new ioctls have been added to the v4l2 
DRM interfaces for dma_buf, they have only been to allow the import 
export of driver-specific buffer objects. Once imported as a driver
specific buffer object, existing ioctls are re-used to perform
operations on those buffers (at least this is what PRIME does for DRM,
I'm not so sure about v4l2?). But my point is that no new page flip
to this dma_buf fd ioctl has been added to KMS, you use the existing
drm_mode_crtc_page_flip and specify an fb_id which has been imported
from a dma_buf.

If we associate sync objects with buffers, none of those device
specific ioctls which perform operations on buffer objects need to
be modified. It's just that internally, those drivers use kds or
something similar to make sure they don't tread on each other's
toes.

The alternate is to not associate sync objects with buffers and
have them be distinct entities, exposed to userspace. This gives
userpsace more power and flexibility and might allow for use-cases
which an implicit synchronization mechanism can't satisfy - I'd
be curious to know any specifics here. However, every driver which
needs to participate in the synchronization mechanism will need
to have its interface with userspace modified to allow the sync
objects to be passed to the drivers. This seemed like a lot of
work to me, which is why I prefer the implicit approach. However
I don't actually know what work is needed and think it should be
explored. I.e. How much work is it to add explicit sync object
support to the DRM  v4l2 interfaces?

E.g. I believe DRM/GEM's job dispatch API is in-order
in which case it might be easy to just add wait for this fence
and signal this fence ioctls. Seems like vmwgfx already has
something similar to this already? Could this work over having
to specify a list of sync objects to wait on and another list
of sync objects to signal for every operation (exec buf/page
flip)? What about for v4l2?

I guess my other thought is that implicit vs explicit is not
mutually exclusive, though I'd guess there'd be interesting
deadlocks to have to debug if both were in use _at the same
time_. :-)


Cheers,

Tom




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

[Bug 50805] radeon gpu driver bug on suspend/resume in 3.5-rc1

[bugzilla-daemon]

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

Alex Deucher ag...@yahoo.com changed:

   What|Removed |Added

  Attachment #62685|text/x-log  |text/plain
  mime type||

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 50805] radeon gpu driver bug on suspend/resume in 3.5-rc1

[bugzilla-daemon]

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

--- Comment #1 from Alex Deucher ag...@yahoo.com 2012-06-07 06:36:10 PDT ---
Can you attach your dmesg from boot and xorg log?  Also is this a regression? 
If so, can you bisect?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 50655] ATI RV670 [Radeon HD 3870] Ioquake games causes GPU lockup (waiting for 0x00003039 last fence id 0x00003030)

[bugzilla-daemon]

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

Alex Deucher ag...@yahoo.com changed:

   What|Removed |Added

  Attachment #62476|application/octet-stream|text/plain
  mime type||

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 50655] ATI RV670 [Radeon HD 3870] Ioquake games causes GPU lockup (waiting for 0x00003039 last fence id 0x00003030)

[bugzilla-daemon]

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

--- Comment #12 from Alex Deucher ag...@yahoo.com 2012-06-07 07:16:57 PDT ---
I think I know what's going on here.  There's a hw bug on r6xx where you need
to re-emit a CB register if some state further up the pipeline changes even if
the CB state has not changed.  I remember fixing it in r600c, but I can't find
the commit...

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 50655] ATI RV670 [Radeon HD 3870] Ioquake games causes GPU lockup (waiting for 0x00003039 last fence id 0x00003030)

[bugzilla-daemon]

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

--- Comment #13 from Alex Deucher ag...@yahoo.com 2012-06-07 07:20:16 PDT ---
IIRC, the fix is to always re-emit a CB reg between draw calls if some other
state changed.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 libdrm 8/8] proptest: support plane properties

[Rob Clark]

On Thu, Jun 7, 2012 at 1:09 PM, Joonyoung Shim jy0922.s...@samsung.com wrote:
 Hi, Rob.


 On 06/06/2012 03:06 AM, Rob Clark wrote:

 From: Rob Clarkr...@ti.com

 Add support to display plane properties.


 Do you not support to set property for plane?

oh, heh, I missed the fact that proptest actually lets you *set*
properties.. I won't push this particular patch until I update it to
set properties too

BR,
-R



 Signed-off-by: Rob Clarkr...@ti.com
 ---
  tests/proptest/proptest.c |   32 
  1 file changed, 32 insertions(+)

 diff --git a/tests/proptest/proptest.c b/tests/proptest/proptest.c
 index fa34a48..aac6b8f 100644
 --- a/tests/proptest/proptest.c
 +++ b/tests/proptest/proptest.c
 @@ -39,6 +39,7 @@

  int fd;
  drmModeResPtr res = NULL;
 +drmModePlaneResPtr plane_res = NULL;

  const char *connector_type_str(uint32_t type)
  {
 @@ -239,10 +240,33 @@ static void listCrtcProperties(void)
        }
  }

 +static void listPlaneProperties(void)
 +{
 +       int i;
 +       drmModePlanePtr p;
 +
 +       for (i = 0; i  plane_res-count_planes; i++) {
 +               p = drmModeGetPlane(fd, plane_res-planes[i]);
 +
 +               if (!p) {
 +                       fprintf(stderr, Could not get plane %u: %s\n,
 +                               plane_res-planes[i], strerror(errno));
 +                       continue;
 +               }
 +
 +               printf(Plane %u\n, p-plane_id);
 +
 +               listObjectProperties(p-plane_id, DRM_MODE_OBJECT_PLANE);
 +
 +               drmModeFreePlane(p);
 +       }
 +}
 +
  static void listAllProperties(void)
  {
        listConnectorProperties();
        listCrtcProperties();
 +       listPlaneProperties();
  }

  static int setProperty(char *argv[])
 @@ -309,6 +333,14 @@ int main(int argc, char *argv[])
                goto done;
        }

 +       plane_res = drmModeGetPlaneResources(fd);
 +       if (!plane_res) {
 +               fprintf(stderr, Failed to get plane resources: %s\n,
 +                       strerror(errno));
 +               ret = 1;
 +               goto done;
 +       }
 +
        if (argc  2) {
                listAllProperties();
        } else if (argc == 5) {


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

Re: [PATCH 2/2 v4] intel: wait render timeout implementation

[Ben Widawsky]

On Thu, 7 Jun 2012 09:10:08 +0200
Daniel Vetter dan...@ffwll.ch wrote:

 On Wed, Jun 06, 2012 at 04:42:11PM -0700, Ben Widawsky wrote:
  int drm_intel_gem_bo_wait(drm_intel_bo *bo, uint64_t timeout_ns)
  
  This should bump the libdrm version. We're waiting for context support
  so we can do both features in one bump.
  
  v2: don't return remaining timeout amount
  use get param and fallback for older kernels
  
  v3: only doing getparam at init
  prototypes now have a signed input value
  
  v4: update comments
  fall back to correct polling behavior with new userspace and old kernel
  
  Cc: Eric Anholt e...@anholt.net
  Cc: Daniel Vetter daniel.vet...@ffwll.ch
  Signed-off-by: Ben Widawsky b...@bwidawsk.net
  ---
   intel/intel_bufmgr.h |1 +
   intel/intel_bufmgr_gem.c |   51 
  ++
   2 files changed, 52 insertions(+)
  
  diff --git a/intel/intel_bufmgr.h b/intel/intel_bufmgr.h
  index c197abc..fa6c4dd 100644
  --- a/intel/intel_bufmgr.h
  +++ b/intel/intel_bufmgr.h
  @@ -184,6 +184,7 @@ int drm_intel_get_pipe_from_crtc_id(drm_intel_bufmgr 
  *bufmgr, int crtc_id);
   
   int drm_intel_get_aperture_sizes(int fd, size_t *mappable, size_t *total);
   int drm_intel_bufmgr_gem_get_devid(drm_intel_bufmgr *bufmgr);
  +int drm_intel_gem_bo_wait(drm_intel_bo *bo, int64_t timeout_ns);
   
   /* drm_intel_bufmgr_fake.c */
   drm_intel_bufmgr *drm_intel_bufmgr_fake_init(int fd,
  diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
  index b776d2f..f8e3706 100644
  --- a/intel/intel_bufmgr_gem.c
  +++ b/intel/intel_bufmgr_gem.c
  @@ -119,6 +119,7 @@ typedef struct _drm_intel_bufmgr_gem {
  unsigned int has_blt : 1;
  unsigned int has_relaxed_fencing : 1;
  unsigned int has_llc : 1;
  +   unsigned int has_wait_timeout : 1;
  unsigned int bo_reuse : 1;
  unsigned int no_exec : 1;
  bool fenced_relocs;
  @@ -1479,6 +1480,52 @@ drm_intel_gem_bo_wait_rendering(drm_intel_bo *bo)
   }
   
   /**
  + * Waits on a BO for the given amount of time.
  + *
  + * @bo: buffer object to wait for
  + * @timeout_ns: amount of time to wait in nanoseconds.
  + *   If value is less than 0, an infinite wait will occur.
  + *
  + * Returns 0 if the wait was successful ie. the last batch referencing the
  + * object has completed within the allotted time. Otherwise some negative 
  return
  + * value describes the error.
 
 I'm not too sure about that being correct yet. Iirc drmIoctl simply
 returns -1 on error, with the (positive error number stored in errno),
 and the busy function returns 1 when the thing is busy. I think we should
 map both properly to the same -ETIME.
 -Daniel
 

This was supposed to be solved by patch 1/2 where I changed the
behavior of drmIoctl. It seems Dave didn't like the idea so much.
Unless you want to take up arms with me, there will be a v5 of this
patch.

  + *
  + * Similar to drm_intel_gem_bo_wait_rendering except a timeout parameter 
  allows
  + * the operation to give up after a certain amount of time. Another subtle
  + * difference is the internal locking semantics are different (this 
  variant does
  + * not hold the lock for the duration of the wait). This makes the wait 
  subject
  + * to a larger userspace race window.
  + *
  + * The implementation shall wait until the object is no longer actively
  + * referenced within a batch buffer at the time of the call. The wait will
  + * not guarantee that the buffer is re-issued via another thread, or an 
  flinked
  + * handle. Userspace must make sure this race does not occur if such 
  precision
  + * is important.
  + */
  +int drm_intel_gem_bo_wait(drm_intel_bo *bo, int64_t timeout_ns)
  +{
  +   drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *) bo-bufmgr;
  +   drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *) bo;
  +   struct drm_i915_gem_wait wait;
  +
  +   if (!bufmgr_gem-has_wait_timeout) {
  +   DBG(%s:%d: Timed wait is not supported. Falling back to 
  +   infinite wait\n, __FILE__, __LINE__);
  +   if (timeout_ns) {
  +   drm_intel_gem_bo_wait_rendering(bo);
  +   return 0;
  +   } else {
  +   return drm_intel_gem_bo_busy(bo);
  +   }
  +   }
  +
  +   wait.bo_handle = bo_gem-gem_handle;
  +   wait.timeout_ns = timeout_ns;
  +   wait.flags = 0;
  +   return drmIoctl(bufmgr_gem-fd, DRM_IOCTL_I915_GEM_WAIT, wait);
  +}
  +
  +/**
* Sets the object to the GTT read and possibly write domain, used by the X
* 2D driver in the absence of kernel support to do 
  drm_intel_gem_bo_map_gtt().
*
  @@ -2898,6 +2945,10 @@ drm_intel_bufmgr_gem_init(int fd, int batch_size)
  ret = drmIoctl(bufmgr_gem-fd, DRM_IOCTL_I915_GETPARAM, gp);
  bufmgr_gem-has_relaxed_fencing = ret == 0;
   
  +   gp.param = I915_PARAM_HAS_WAIT_TIMEOUT;
  +   ret = drmIoctl(bufmgr_gem-fd, DRM_IOCTL_I915_GETPARAM, gp);
  +   bufmgr_gem-has_wait_timeout = ret == 0;
  +
   

[PATCH 00/12] clear up drm/agp initialization madness

[Daniel Vetter]

Hi all,

With these patches there's no more /dev/agpgart fake agp interface for drm/i915,
at least not for snb and later.

The first 3 patches rework the drm core to move agp initialization into drivers.
A nice bonus is that these remove the mid-layer stench quite a bit from drm ...

The later patches from drm/i915 and the intel agp/gtt stuff so that drm/i915 can
directly initialize the gtt support code, without the useless fake agp setup
(which at least kms/gem doesn't need at all).

Note that thanks to some horrible piece of userspace code we can't disable drm
agp support for gen3. That piece of userspace code uses the legacy drm addmap
stuff to get at it's buffers, and that requires the fake agp driver to work.

Also, we can't disable the fake agp driver on other generations before snb,
because by the time we know that we're running with kms enabled and don't
actually need it it's too late.

Obviously this is only the first part, furture patches will move the gen6+ gtt
code into drm/i915 so that we can rip out all the duplication of chipset gen
information in intel-gtt.c, too. And prepare for some neat new features ;-)

Outside of drm/i915 stuff only tested on my i815 - for some odd reason my only
agp machine left dies on 3.5-rc1, so couldn't yet beat on it with a few other
oddball drivers. But imho the first 3 patches are fairly safe (compared to some
other drm dragon slaughtering I've attempted).

Comments, flames and reviews highly welcome. If possible I'd like to get the 3
drm patches at the beginning in early for 3.6 so that we can decently test it
(and have some time to pile more stuff on top of this in drm/i915 land).

Yours, Daniel

Daniel Vetter (12):
  drm: move drm_pci_agp_init into driver load functions
  drm: kill the REQUIRE_AGP driver flag
  drm: kill USE_AGP driver flag
  agp/intel-gtt: remove dead code
  drm/i915: stop using dev-agp-base
  agp/intel-gtt: don't require the agp bridge on setup
  drm/i915: only enable drm agp support when required
  drm/i915 + agp/intel-gtt: prep work for direct setup
  drm/i915: don't check intel_agp_enabled any more
  agp/intel-gtt: move gart base addres setup
  drm/i915: call intel_enable_gtt
  agp/intel-agp: remove snb+ host bridge pciids

 drivers/char/agp/intel-agp.c|   16 +--
 drivers/char/agp/intel-agp.h|3 -
 drivers/char/agp/intel-gtt.c|   73 ---
 drivers/gpu/drm/drm_pci.c   |8 +---
 drivers/gpu/drm/drm_stub.c  |8 ---
 drivers/gpu/drm/i810/i810_dma.c |   11 +
 drivers/gpu/drm/i810/i810_drv.c |2 +-
 drivers/gpu/drm/i915/i915_dma.c |   50 +
 drivers/gpu/drm/i915/i915_drv.c |8 +---
 drivers/gpu/drm/i915/i915_drv.h |1 +
 drivers/gpu/drm/i915/i915_gem.c |5 ++-
 drivers/gpu/drm/i915/i915_gem_debug.c   |3 +-
 drivers/gpu/drm/i915/intel_display.c|2 +-
 drivers/gpu/drm/i915/intel_fb.c |4 +-
 drivers/gpu/drm/i915/intel_ringbuffer.c |6 ++-
 drivers/gpu/drm/mga/mga_dma.c   |4 ++
 drivers/gpu/drm/mga/mga_drv.c   |2 +-
 drivers/gpu/drm/nouveau/nouveau_drv.c   |2 +-
 drivers/gpu/drm/nouveau/nouveau_state.c |4 ++
 drivers/gpu/drm/r128/r128_drv.c |8 +++-
 drivers/gpu/drm/radeon/radeon_cp.c  |4 ++
 drivers/gpu/drm/radeon/radeon_drv.c |4 +-
 drivers/gpu/drm/radeon/radeon_kms.c |4 ++
 drivers/gpu/drm/savage/savage_bci.c |5 ++
 drivers/gpu/drm/savage/savage_drv.c |2 +-
 drivers/gpu/drm/sis/sis_drv.c   |7 +++-
 drivers/gpu/drm/via/via_drv.c   |2 +-
 drivers/gpu/drm/via/via_map.c   |4 ++
 include/drm/drmP.h  |   12 +
 include/drm/intel-gtt.h |8 +++
 30 files changed, 174 insertions(+), 98 deletions(-)

-- 
1.7.7.6

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

[PATCH 01/12] drm: move drm_pci_agp_init into driver load functions

[Daniel Vetter]

I've done an audit of everything which is being set up between the
place where drm_pci_agp_init is called currently and where the
driver's -load function is called. Nothing seems to depend upon
dev-agp being set up correctly.

This is one big step into squashing this giant midlayer mistaken.
Though one that drm/i915 is hurting especially: We don't need (and
want) the agp layer on many chips, but we need to decide whether we
want to enable it too early.

By moving the agp setup into the drivers control, we can do an
intelligent decision in drm/i915 whether we need agp support (for
anything ums and some horrible kms userspace on specific generations)
or whether it's not required.

Also, this allows us to rip out a bit of the agp invasion from generic
drm core code in follow-up patches.

Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/drm_pci.c   |2 +-
 drivers/gpu/drm/drm_stub.c  |8 
 drivers/gpu/drm/i810/i810_dma.c |6 ++
 drivers/gpu/drm/i915/i915_dma.c |4 
 drivers/gpu/drm/mga/mga_dma.c   |4 
 drivers/gpu/drm/nouveau/nouveau_state.c |4 
 drivers/gpu/drm/r128/r128_drv.c |6 ++
 drivers/gpu/drm/radeon/radeon_cp.c  |4 
 drivers/gpu/drm/radeon/radeon_kms.c |4 
 drivers/gpu/drm/savage/savage_bci.c |5 +
 drivers/gpu/drm/sis/sis_drv.c   |5 +
 drivers/gpu/drm/via/via_map.c   |4 
 include/drm/drmP.h  |5 +
 13 files changed, 48 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index 13f3d93..833e599 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -286,6 +286,7 @@ int drm_pci_agp_init(struct drm_device *dev)
}
return 0;
 }
+EXPORT_SYMBOL(drm_pci_agp_init);
 
 static struct drm_bus drm_pci_bus = {
.bus_type = DRIVER_BUS_PCI,
@@ -294,7 +295,6 @@ static struct drm_bus drm_pci_bus = {
.set_busid = drm_pci_set_busid,
.set_unique = drm_pci_set_unique,
.irq_by_busid = drm_pci_irq_by_busid,
-   .agp_init = drm_pci_agp_init,
 };
 
 /**
diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index 21bcd4a..4a4a1ed 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -289,14 +289,6 @@ int drm_fill_in_dev(struct drm_device *dev,
 
dev-driver = driver;
 
-   if (dev-driver-bus-agp_init) {
-   retcode = dev-driver-bus-agp_init(dev);
-   if (retcode)
-   goto error_out_unreg;
-   }
-
-
-
retcode = drm_ctxbitmap_init(dev);
if (retcode) {
DRM_ERROR(Cannot allocate memory for context bitmap.\n);
diff --git a/drivers/gpu/drm/i810/i810_dma.c b/drivers/gpu/drm/i810/i810_dma.c
index f920fb5..eed1126 100644
--- a/drivers/gpu/drm/i810/i810_dma.c
+++ b/drivers/gpu/drm/i810/i810_dma.c
@@ -1198,6 +1198,12 @@ static int i810_flip_bufs(struct drm_device *dev, void 
*data,
 
 int i810_driver_load(struct drm_device *dev, unsigned long flags)
 {
+   int ret;
+
+   ret = drm_pci_agp_init(dev);
+   if (ret)
+   return ret;
+
/* i810 has 4 more counters */
dev-counters += 4;
dev-types[6] = _DRM_STAT_IRQ;
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 97a5a58..b97ef73 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1422,6 +1422,10 @@ int i915_driver_load(struct drm_device *dev, unsigned 
long flags)
int ret = 0, mmio_bar;
uint32_t aperture_size;
 
+   ret = drm_pci_agp_init(dev);
+   if (ret)
+   return ret;
+
info = (struct intel_device_info *) flags;
 
/* Refuse to load on gen6+ without kms enabled. */
diff --git a/drivers/gpu/drm/mga/mga_dma.c b/drivers/gpu/drm/mga/mga_dma.c
index 507aa3d..549816e 100644
--- a/drivers/gpu/drm/mga/mga_dma.c
+++ b/drivers/gpu/drm/mga/mga_dma.c
@@ -394,6 +394,10 @@ int mga_driver_load(struct drm_device *dev, unsigned long 
flags)
drm_mga_private_t *dev_priv;
int ret;
 
+   ret = drm_pci_agp_init(dev);
+   if (ret)
+   return ret;
+
dev_priv = kzalloc(sizeof(drm_mga_private_t), GFP_KERNEL);
if (!dev_priv)
return -ENOMEM;
diff --git a/drivers/gpu/drm/nouveau/nouveau_state.c 
b/drivers/gpu/drm/nouveau/nouveau_state.c
index 19706f0..dbc881a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_state.c
+++ b/drivers/gpu/drm/nouveau/nouveau_state.c
@@ -1029,6 +1029,10 @@ int nouveau_load(struct drm_device *dev, unsigned long 
flags)
uint32_t reg0 = ~0, strap;
int ret;
 
+   ret = drm_pci_agp_init(dev);
+   if (ret)
+   return ret;
+
dev_priv = kzalloc(sizeof(*dev_priv), GFP_KERNEL);
if (!dev_priv) {
ret = -ENOMEM;
diff --git 

[PATCH 02/12] drm: kill the REQUIRE_AGP driver flag

[Daniel Vetter]

Only i810 and i915 use this. But now that the driver's -load function
is responsible for setting up agp, we can simply move this check in
there.

Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/drm_pci.c   |6 +-
 drivers/gpu/drm/i810/i810_dma.c |5 +
 drivers/gpu/drm/i810/i810_drv.c |2 +-
 drivers/gpu/drm/i915/i915_dma.c |5 +
 drivers/gpu/drm/i915/i915_drv.c |2 +-
 include/drm/drmP.h  |1 -
 6 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index 833e599..59e11e4 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -271,11 +271,7 @@ int drm_pci_agp_init(struct drm_device *dev)
if (drm_core_has_AGP(dev)) {
if (drm_pci_device_is_agp(dev))
dev-agp = drm_agp_init(dev);
-   if (drm_core_check_feature(dev, DRIVER_REQUIRE_AGP)
-(dev-agp == NULL)) {
-   DRM_ERROR(Cannot initialize the agpgart module.\n);
-   return -EINVAL;
-   }
+
if (drm_core_has_MTRR(dev)) {
if (dev-agp)
dev-agp-agp_mtrr =
diff --git a/drivers/gpu/drm/i810/i810_dma.c b/drivers/gpu/drm/i810/i810_dma.c
index eed1126..751d767 100644
--- a/drivers/gpu/drm/i810/i810_dma.c
+++ b/drivers/gpu/drm/i810/i810_dma.c
@@ -1204,6 +1204,11 @@ int i810_driver_load(struct drm_device *dev, unsigned 
long flags)
if (ret)
return ret;
 
+   if (!dev-agp) {
+   DRM_ERROR(Cannot initialize the agpgart module.\n);
+   return -EINVAL;
+   }
+
/* i810 has 4 more counters */
dev-counters += 4;
dev-types[6] = _DRM_STAT_IRQ;
diff --git a/drivers/gpu/drm/i810/i810_drv.c b/drivers/gpu/drm/i810/i810_drv.c
index ec12f7d..6419182 100644
--- a/drivers/gpu/drm/i810/i810_drv.c
+++ b/drivers/gpu/drm/i810/i810_drv.c
@@ -56,7 +56,7 @@ static const struct file_operations i810_driver_fops = {
 
 static struct drm_driver driver = {
.driver_features =
-   DRIVER_USE_AGP | DRIVER_REQUIRE_AGP | DRIVER_USE_MTRR |
+   DRIVER_USE_AGP | DRIVER_USE_MTRR |
DRIVER_HAVE_DMA | DRIVER_DMA_QUEUE,
.dev_priv_size = sizeof(drm_i810_buf_priv_t),
.load = i810_driver_load,
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index b97ef73..494b9cb 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1426,6 +1426,11 @@ int i915_driver_load(struct drm_device *dev, unsigned 
long flags)
if (ret)
return ret;
 
+   if (!dev-agp) {
+   DRM_ERROR(Cannot initialize the agpgart module.\n);
+   return -EINVAL;
+   }
+
info = (struct intel_device_info *) flags;
 
/* Refuse to load on gen6+ without kms enabled. */
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 238a521..e98501d 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1038,7 +1038,7 @@ static struct drm_driver driver = {
 * deal with them for Intel hardware.
 */
.driver_features =
-   DRIVER_USE_AGP | DRIVER_REQUIRE_AGP | /* DRIVER_USE_MTRR |*/
+   DRIVER_USE_AGP | /* DRIVER_USE_MTRR |*/
DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM | DRIVER_PRIME,
.load = i915_driver_load,
.unload = i915_driver_unload,
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index e3437da..9906487 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -138,7 +138,6 @@ int drm_err(const char *func, const char *format, ...);
 
 /* driver capabilities and requirements mask */
 #define DRIVER_USE_AGP 0x1
-#define DRIVER_REQUIRE_AGP 0x2
 #define DRIVER_USE_MTRR0x4
 #define DRIVER_PCI_DMA 0x8
 #define DRIVER_SG  0x10
-- 
1.7.7.6

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

[PATCH 03/12] drm: kill USE_AGP driver flag

[Daniel Vetter]

All drivers that use agp call the agp_init function now directly from
their -load callback. All other parts check for dev-agp anyway to
check whether agp is available.

This flag has therefore outlived its usefullness, kill it.

Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i810/i810_drv.c   |2 +-
 drivers/gpu/drm/i915/i915_drv.c   |2 +-
 drivers/gpu/drm/mga/mga_drv.c |2 +-
 drivers/gpu/drm/nouveau/nouveau_drv.c |2 +-
 drivers/gpu/drm/r128/r128_drv.c   |2 +-
 drivers/gpu/drm/radeon/radeon_drv.c   |4 ++--
 drivers/gpu/drm/savage/savage_drv.c   |2 +-
 drivers/gpu/drm/sis/sis_drv.c |2 +-
 drivers/gpu/drm/via/via_drv.c |2 +-
 include/drm/drmP.h|6 +-
 10 files changed, 11 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i810/i810_drv.c b/drivers/gpu/drm/i810/i810_drv.c
index 6419182..148cb52 100644
--- a/drivers/gpu/drm/i810/i810_drv.c
+++ b/drivers/gpu/drm/i810/i810_drv.c
@@ -56,7 +56,7 @@ static const struct file_operations i810_driver_fops = {
 
 static struct drm_driver driver = {
.driver_features =
-   DRIVER_USE_AGP | DRIVER_USE_MTRR |
+   DRIVER_USE_MTRR |
DRIVER_HAVE_DMA | DRIVER_DMA_QUEUE,
.dev_priv_size = sizeof(drm_i810_buf_priv_t),
.load = i810_driver_load,
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index e98501d..818e3c7 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1038,7 +1038,7 @@ static struct drm_driver driver = {
 * deal with them for Intel hardware.
 */
.driver_features =
-   DRIVER_USE_AGP | /* DRIVER_USE_MTRR |*/
+   /* DRIVER_USE_MTRR |*/
DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM | DRIVER_PRIME,
.load = i915_driver_load,
.unload = i915_driver_unload,
diff --git a/drivers/gpu/drm/mga/mga_drv.c b/drivers/gpu/drm/mga/mga_drv.c
index f9a925d..866d07a 100644
--- a/drivers/gpu/drm/mga/mga_drv.c
+++ b/drivers/gpu/drm/mga/mga_drv.c
@@ -60,7 +60,7 @@ static const struct file_operations mga_driver_fops = {
 
 static struct drm_driver driver = {
.driver_features =
-   DRIVER_USE_AGP | DRIVER_USE_MTRR | DRIVER_PCI_DMA |
+   DRIVER_USE_MTRR | DRIVER_PCI_DMA |
DRIVER_HAVE_DMA | DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED,
.dev_priv_size = sizeof(drm_mga_buf_priv_t),
.load = mga_driver_load,
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.c 
b/drivers/gpu/drm/nouveau/nouveau_drv.c
index cad254c..b1dc91d 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.c
@@ -401,7 +401,7 @@ static const struct file_operations nouveau_driver_fops = {
 
 static struct drm_driver driver = {
.driver_features =
-   DRIVER_USE_AGP | DRIVER_PCI_DMA | DRIVER_SG |
+   DRIVER_PCI_DMA | DRIVER_SG |
DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM |
DRIVER_MODESET | DRIVER_PRIME,
.load = nouveau_load,
diff --git a/drivers/gpu/drm/r128/r128_drv.c b/drivers/gpu/drm/r128/r128_drv.c
index 22001ca..4146db4 100644
--- a/drivers/gpu/drm/r128/r128_drv.c
+++ b/drivers/gpu/drm/r128/r128_drv.c
@@ -58,7 +58,7 @@ static const struct file_operations r128_driver_fops = {
 
 static struct drm_driver driver = {
.driver_features =
-   DRIVER_USE_AGP | DRIVER_USE_MTRR | DRIVER_PCI_DMA | DRIVER_SG |
+   DRIVER_USE_MTRR | DRIVER_PCI_DMA | DRIVER_SG |
DRIVER_HAVE_DMA | DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED,
.dev_priv_size = sizeof(drm_r128_buf_priv_t),
.load = r128_driver_load,
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
b/drivers/gpu/drm/radeon/radeon_drv.c
index f0bb2b5..1cb0a02 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -239,7 +239,7 @@ static const struct file_operations radeon_driver_old_fops 
= {
 
 static struct drm_driver driver_old = {
.driver_features =
-   DRIVER_USE_AGP | DRIVER_USE_MTRR | DRIVER_PCI_DMA | DRIVER_SG |
+   DRIVER_USE_MTRR | DRIVER_PCI_DMA | DRIVER_SG |
DRIVER_HAVE_IRQ | DRIVER_HAVE_DMA | DRIVER_IRQ_SHARED,
.dev_priv_size = sizeof(drm_radeon_buf_priv_t),
.load = radeon_driver_load,
@@ -337,7 +337,7 @@ static const struct file_operations radeon_driver_kms_fops 
= {
 
 static struct drm_driver kms_driver = {
.driver_features =
-   DRIVER_USE_AGP | DRIVER_USE_MTRR | DRIVER_PCI_DMA | DRIVER_SG |
+   DRIVER_USE_MTRR | DRIVER_PCI_DMA | DRIVER_SG |
DRIVER_HAVE_IRQ | DRIVER_HAVE_DMA | DRIVER_IRQ_SHARED | DRIVER_GEM |
DRIVER_PRIME,
.dev_priv_size = 0,
diff --git a/drivers/gpu/drm/savage/savage_drv.c 
b/drivers/gpu/drm/savage/savage_drv.c
index 89afe0b..cef78aa 100644
--- a/drivers/gpu/drm/savage/savage_drv.c
+++ 

[PATCH 04/12] agp/intel-gtt: remove dead code

[Daniel Vetter]

This is a leftover from the conversion of the i81x fake agp driver
over to the new intel-gtt code layoute.

Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/char/agp/intel-gtt.c |3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index 1237e75..53c4c7f 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -1556,9 +1556,6 @@ int intel_gmch_probe(struct pci_dev *pdev,
pci_set_consistent_dma_mask(intel_private.pcidev,
DMA_BIT_MASK(mask));
 
-   /*if (bridge-driver == intel_810_driver)
-   return 1;*/
-
if (intel_gtt_init() != 0)
return 0;
 
-- 
1.7.7.6

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

[PATCH 05/12] drm/i915: stop using dev-agp-base

[Daniel Vetter]

For that to work we need to export the base address of the gtt
mmio window from intel-gtt. Also replace all other uses of
dev-agp by values we already have at hand.

Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/char/agp/intel-gtt.c|5 ++---
 drivers/gpu/drm/i915/i915_dma.c |   21 +
 drivers/gpu/drm/i915/i915_drv.h |1 +
 drivers/gpu/drm/i915/i915_gem.c |2 +-
 drivers/gpu/drm/i915/i915_gem_debug.c   |3 ++-
 drivers/gpu/drm/i915/intel_display.c|2 +-
 drivers/gpu/drm/i915/intel_fb.c |4 +++-
 drivers/gpu/drm/i915/intel_ringbuffer.c |6 --
 include/drm/intel-gtt.h |2 ++
 9 files changed, 29 insertions(+), 17 deletions(-)

diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index 53c4c7f..2aab0a0 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -66,7 +66,6 @@ static struct _intel_private {
struct pci_dev *bridge_dev;
u8 __iomem *registers;
phys_addr_t gtt_bus_addr;
-   phys_addr_t gma_bus_addr;
u32 PGETBL_save;
u32 __iomem *gtt;   /* I915G */
bool clear_fake_agp; /* on first access via agp, fill with scratch */
@@ -779,7 +778,7 @@ static bool intel_enable_gtt(void)
pci_read_config_dword(intel_private.pcidev, I915_GMADDR,
  gma_addr);
 
-   intel_private.gma_bus_addr = (gma_addr  PCI_BASE_ADDRESS_MEM_MASK);
+   intel_private.base.gma_bus_addr = (gma_addr  
PCI_BASE_ADDRESS_MEM_MASK);
 
if (INTEL_GTT_GEN = 6)
return true;
@@ -860,7 +859,7 @@ static int intel_fake_agp_configure(void)
return -EIO;
 
intel_private.clear_fake_agp = true;
-   agp_bridge-gart_bus_addr = intel_private.gma_bus_addr;
+   agp_bridge-gart_bus_addr = intel_private.base.gma_bus_addr;
 
return 0;
 }
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 494b9cb..e4203df 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1085,8 +1085,8 @@ static int i915_set_status_page(struct drm_device *dev, 
void *data,
 
ring-status_page.gfx_addr = hws-addr  (0x112);
 
-   dev_priv-dri1.gfx_hws_cpu_addr = ioremap_wc(dev-agp-base + hws-addr,
-4096);
+   dev_priv-dri1.gfx_hws_cpu_addr =
+   ioremap_wc(dev_priv-mm.gtt_base_addr + hws-addr, 4096);
if (dev_priv-dri1.gfx_hws_cpu_addr == NULL) {
i915_dma_cleanup(dev);
ring-status_page.gfx_addr = 0;
@@ -1491,15 +1491,18 @@ int i915_driver_load(struct drm_device *dev, unsigned 
long flags)
}
 
aperture_size = dev_priv-mm.gtt-gtt_mappable_entries  PAGE_SHIFT;
+   dev_priv-mm.gtt_base_addr = dev_priv-mm.gtt-gma_bus_addr;
 
dev_priv-mm.gtt_mapping =
-   io_mapping_create_wc(dev-agp-base, aperture_size);
+   io_mapping_create_wc(dev_priv-mm.gtt_base_addr,
+aperture_size);
if (dev_priv-mm.gtt_mapping == NULL) {
ret = -EIO;
goto out_rmmap;
}
 
-   i915_mtrr_setup(dev_priv, dev-agp-base, aperture_size);
+   i915_mtrr_setup(dev_priv, dev_priv-mm.gtt_base_addr,
+   aperture_size);
 
/* The i915 workqueue is primarily used for batched retirement of
 * requests (and thus managing bo) once the task has been completed
@@ -1611,8 +1614,9 @@ out_gem_unload:
destroy_workqueue(dev_priv-wq);
 out_mtrrfree:
if (dev_priv-mm.gtt_mtrr = 0) {
-   mtrr_del(dev_priv-mm.gtt_mtrr, dev-agp-base,
-dev-agp-agp_info.aper_size * 1024 * 1024);
+   mtrr_del(dev_priv-mm.gtt_mtrr,
+dev_priv-mm.gtt_base_addr,
+aperture_size);
dev_priv-mm.gtt_mtrr = -1;
}
io_mapping_free(dev_priv-mm.gtt_mapping);
@@ -1649,8 +1653,9 @@ int i915_driver_unload(struct drm_device *dev)
 
io_mapping_free(dev_priv-mm.gtt_mapping);
if (dev_priv-mm.gtt_mtrr = 0) {
-   mtrr_del(dev_priv-mm.gtt_mtrr, dev-agp-base,
-dev-agp-agp_info.aper_size * 1024 * 1024);
+   mtrr_del(dev_priv-mm.gtt_mtrr,
+dev_priv-mm.gtt_base_addr,
+dev_priv-mm.gtt-gtt_mappable_entries * PAGE_SIZE);
dev_priv-mm.gtt_mtrr = -1;
}
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ccabadd..ae4129b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -651,6 +651,7 @@ typedef struct drm_i915_private {
unsigned long gtt_end;
 
struct io_mapping *gtt_mapping;
+   phys_addr_t gtt_base_addr;

[PATCH 06/12] agp/intel-gtt: don't require the agp bridge on setup

[Daniel Vetter]

We only need it to fake the agp interface and don't actually
use it in the driver anywhere. Hence conditionalize that.

This is just a prep patch to eventually disable the fake agp
driver on gen6+.

Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/char/agp/intel-gtt.c |8 +---
 1 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index 2aab0a0..5e6c89e 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -1539,9 +1539,11 @@ int intel_gmch_probe(struct pci_dev *pdev,
if (!intel_private.driver)
return 0;
 
-   bridge-driver = intel_fake_agp_driver;
-   bridge-dev_private_data = intel_private;
-   bridge-dev = pdev;
+   if (bridge) {
+   bridge-driver = intel_fake_agp_driver;
+   bridge-dev_private_data = intel_private;
+   bridge-dev = pdev;
+   }
 
intel_private.bridge_dev = pci_dev_get(pdev);
 
-- 
1.7.7.6

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