date:20131125

[PATCH] drm/radeon: Disable writeback by default on ppc

2013-11-25 Thread Kleber Sacilotto de Souza

On 11/24/2013 09:15 PM, Benjamin Herrenschmidt wrote:
> On Fri, 2013-11-08 at 11:43 -0200, Kleber Sacilotto de Souza wrote:
>> On 11/07/2013 08:29 PM, Benjamin Herrenschmidt wrote:
>>> On Mon, 2013-06-17 at 18:57 -0400, Alex Deucher wrote:
>>>
 Weird.  I wonder if there is an issue with cache snoops on PPC.  We
 currently use the gart in cached mode (GPU snoops CPU cache) with
 cached pages.  I wonder if we need to use uncached pages on PPC.
>>> There is no such issue and no known bugs with DMA writes on those
>>> PCIe host bridges (and they do get hammered pretty bad here).
>>>
>>> This needs further investigation by the lab/hw guys to find out what's
>>> actually happening on the bus and the host bridge.
>>>
>>> Thadeu, Kleber: Jerome suggested writing a test case in userspace that
>>> continuously writes to a spare scratch register (thus triggering the
>>> corresponding writeback DMA) and checks the memory location to compare
>>> the writeback value (using a debugfs file for example, or mmap).
>>>
>> I can look into that.
> Any news ?
Only now I've got the bandwidth to actually take a look at this. I will 
start to write some code and let you guys know of the results.


Thanks,

Kleber

>
> Ben.
>
>> Thanks,
>>
>> Kleber
>>
>>> Can you guys do something like that ? Then we need the analyzer on
>>> and/or the lab guys to look at the fabric trace & PHB trace.
>>>
>>> Ben.
>>>
>>>
>>
>


-- 
Kleber Sacilotto de Souza
IBM Linux Technology Center

[RFC patch] PCI: Extend boot_vga sysfs attribute lookup to fix X on MBA+EFI

2013-11-25 Thread Bruno Prémont

On Mon, 25 November 2013 Bjorn Helgaas wrote:
> On Mon, Nov 25, 2013 at 12:54 PM, Bruno Pr?mont wrote:
> > On a MacBookAir2,1, booting to Linux with EFI though having
> > no efifb built-in Xorg refuses to start with "no devices detected"
> > because for the only VGA device available (NVidia Geforce 9400M)
> > the sysfs attribute boot_vga is zero (instead of expected 1).
> >
> > When CONFIG_FB_EFI is selected, efifb does provide its own
> > vga_default_device() to report the PCI device matching global
> > screen_info as determined during efifb setup.
> >
> > Otherwise there is just a dummy or VGA_ARB's vga_default_device()
> > that does not provide the right information.
> 
> Wouldn't it be cleaner to fix vga_default_device() so it returns the
> correct thing even when CONFIG_FB_EFI=n?

I would rather completely drop the vga_default_device() from efifb
(CONFIG_FB_EFI) and just keep vga_default_device() for
vga-arbitration/vga-switcheroo.

The fact that there are currently *two* instances of that function
doesn't make life easy for determining who is providing it and when.
  drivers/gpu/vga/vgaarb.c:135
  drivers/video/efifb.c:88
  include/linux/vgaarb.h:190 (dummy)

> > On the other hand, boot_vga_show() falls back to poking PCI
> > resources to flag a PCI device as boot_vga if vga_default_device()
> > returned no PCI device (NULL).
> >
> > To complement this PCI resource poking, this patch copies the
> > validation code used to determine which PCI device to report as
> > default VGA device by efifb into boot_vga_show().
> 
> If we do have to use logic like this, I'd like it better if it were
> factored into a single function called both here and from
> efifb_setup().

As of above, I would preferably drop that part of code from
efifb_setup() and have the logic called only in one place and each
time the same way.
Otherwise efifb versus x86_sysfb+simplefb or directly going to
native driver (nvoueau/radeon/...) behave differently without reason.

Bruno


> > Signed-off-by: Bruno Pr?mont 
> > ---
> > Would it make sense to kill the corresponding code from efifb
> > as it covers only a single case?
> >
> > The other EFI capable system I have (AMD Ilano based, Gigabyte
> > mainboard does report boot_vga=1, possibly through the resources
> > poking and there Xorg starts properly without efifb built in.
> >
> > Selecting CONFIG_X86_SYSFB (combined with CONFIG_FB_SIMPLE) does
> > not help by itself, patching that one instead of PCI's boot_vga
> > attribute directly would still not cover the case when neither
> > of them is enabled.
> >
> >
> >  drivers/pci/pci-sysfs.c | 21 +
> >  1 file changed, 21 insertions(+)
> >
> > diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
> > index 7128cfd..91cac71 100644
> > --- a/drivers/pci/pci-sysfs.c
> > +++ b/drivers/pci/pci-sysfs.c
> > @@ -28,6 +28,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include "pci.h"
> >
> > @@ -540,6 +541,26 @@ boot_vga_show(struct device *dev, struct 
> > device_attribute *attr, char *buf)
> > if (vga_dev)
> > return sprintf(buf, "%u\n", (pdev == vga_dev));
> >
> > +   if ((pdev->class >> 8) == PCI_CLASS_DISPLAY_VGA) {
> > +   resource_size_t start, end;
> > +   int i;
> > +
> > +   for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
> > +   if (!(pci_resource_flags(pdev, i) & IORESOURCE_MEM))
> > +   continue;
> > +
> > +   start = pci_resource_start(pdev, i);
> > +   end  = pci_resource_end(pdev, i);
> > +
> > +   if (!start || !end)
> > +   continue;
> > +
> > +   if (screen_info.lfb_base >= start &&
> > +   (screen_info.lfb_base + 
> > screen_info.lfb_size) < end)
> > +   return sprintf(buf, "1\n");
> > +   }
> > +   }
> > +
> > return sprintf(buf, "%u\n",
> > !!(pdev->resource[PCI_ROM_RESOURCE].flags &
> >IORESOURCE_ROM_SHADOW));

kernel BUG at drivers/gpu/drm/drm_crtc.c:3112!

2013-11-25 Thread Yuanhan Liu

sect good 7e3528c3660a2e8602abc7858b0994d611f74bc3  # 19:49 60+  
0  slab.h: remove duplicate kmalloc declaration and fix kernel-doc warnings
git bisect good a05e9dfb656cd9184443f2e807c9c53c13a3815d  # 20:03 60+  
0  Add linux-next specific files for 20131125

--yliu
-- next part --
[0.00] Linux version 3.12.0-00831-g4bd863f (kbuild at roam) (gcc 
version 4.8.1 (Debian 4.8.1-8) ) #71 SMP PREEMPT Sat Nov 23 00:19:39 CST 2013
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009fbff] usable
[0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000f-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x0fffdfff] usable
[0.00] BIOS-e820: [mem 0x0fffe000-0x0fff] reserved
[0.00] BIOS-e820: [mem 0xfeffc000-0xfeff] reserved
[0.00] BIOS-e820: [mem 0xfffc-0x] reserved
[0.00] debug: ignoring loglevel setting.
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.4 present.
[0.00] DMI: Bochs Bochs, BIOS Bochs 01/01/2011
[0.00] Hypervisor detected: KVM
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] e820: last_pfn = 0xfffe max_arch_pfn = 0x100
[0.00] Scan for SMP in [mem 0x-0x03ff]
[0.00] Scan for SMP in [mem 0x0009fc00-0x0009]
[0.00] Scan for SMP in [mem 0x000f-0x000f]
[0.00] found SMP MP-table at [mem 0x000fdac0-0x000fdacf] mapped at 
[c00fdac0]
[0.00]   mpc: fdad0-fdbec
[0.00] initial memory mapped: [mem 0x-0x02df]
[0.00] Base memory trampoline at [c009b000] 9b000 size 16384
[0.00] init_memory_mapping: [mem 0x-0x000f]
[0.00]  [mem 0x-0x000f] page 4k
[0.00] init_memory_mapping: [mem 0x0e40-0x0e5f]
[0.00]  [mem 0x0e40-0x0e5f] page 2M
[0.00] init_memory_mapping: [mem 0x0c00-0x0e3f]
[0.00]  [mem 0x0c00-0x0e3f] page 2M
[0.00] init_memory_mapping: [mem 0x0010-0x0bff]
[0.00]  [mem 0x0010-0x001f] page 4k
[0.00]  [mem 0x0020-0x0bff] page 2M
[0.00] init_memory_mapping: [mem 0x0e60-0x0fffdfff]
[0.00]  [mem 0x0e60-0x0fdf] page 2M
[0.00]  [mem 0x0fe0-0x0fffdfff] page 4k
[0.00] BRK [0x0281, 0x02810fff] PGTABLE
[0.00] cma: CMA: reserved 16 MiB at 0d40
[0.00] log_buf_len: 8388608
[0.00] early log buf free: 128628(98%)
[0.00] RAMDISK: [mem 0x0e73f000-0x0ffe]
[0.00] ACPI: RSDP 000fd930 00014 (v00 BOCHS )
[0.00] ACPI: RSDT 0fffe450 00034 (v01 BOCHS  BXPCRSDT 0001 BXPC 
0001)
[0.00] ACPI: FACP 0f80 00074 (v01 BOCHS  BXPCFACP 0001 BXPC 
0001)
[0.00] ACPI: DSDT 0fffe490 011A9 (v01   BXPC   BXDSDT 0001 INTL 
20100528)
[0.00] ACPI: FACS 0f40 00040
[0.00] ACPI: SSDT 07a0 00796 (v01 BOCHS  BXPCSSDT 0001 BXPC 
0001)
[0.00] ACPI: APIC 0680 00080 (v01 BOCHS  BXPCAPIC 0001 BXPC 
0001)
[0.00] ACPI: HPET 0640 00038 (v01 BOCHS  BXPCHPET 0001 BXPC 
0001)
[0.00] ACPI: Local APIC address 0xfee0
[0.00] mapped APIC to b000 (fee0)
[0.00] 0MB HIGHMEM available.
[0.00] 255MB LOWMEM available.
[0.00]   mapped low ram: 0 - 0fffe000
[0.00]   low ram: 0 - 0fffe000
[0.00] kvm-clock: Using msrs 4b564d01 and 4b564d00
[0.00] kvm-clock: cpu 0, msr 0:fffd001, boot clock
[0.00] BRK [0x02811000, 0x02811fff] PGTABLE
[0.00] Zone ranges:
[0.00]   DMA  [mem 0x1000-0x00ff]
[0.00]   Normal   [mem 0x0100-0x0fffdfff]
[0.00]   HighMem  empty
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x1000-0x0009efff]
[0.00]   node   0: [mem 0x0010-0x0fffdfff]
[0.00] On node 0 totalpages: 65436
[0.00]   DMA zone: 32 pages used for memmap
[0.00]   DMA zone: 0 pages reserved
[0.00]   DMA zone: 3998 pages, LIFO batch:0
[0.00]   Normal zone: 480 pages used for memmap
[0.00]   Normal zone: 61438 pages, LIFO batch:15
[0.00] Using APIC driver default
[0.00] ACPI: PM-Timer IO Port: 0xb008
[0.00] ACPI: Local APIC address 0xfee0
[0.00] mapped APIC to b000 (fee0)
[0.00] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[0.00] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
[0.00] ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1])
[0.00] ACPI

[PATCH 4/4] dri3: Enable GLX_INTEL_swap_event

2013-11-25 Thread Keith Packard

Now that we're tracking SBC values correctly, and the X server has the ability
to send the GLX swap events from a PresentPixmap request, enable this extension.

Signed-off-by: Keith Packard 
---
 src/glx/dri3_glx.c | 18 +-
 1 file changed, 1 insertion(+), 17 deletions(-)

diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index da3f08b..aa5dd21 100644
--- a/src/glx/dri3_glx.c
+++ b/src/glx/dri3_glx.c
@@ -1525,23 +1525,7 @@ dri3_bind_extensions(struct dri3_screen *psc, struct 
glx_display * priv,
__glXEnableDirectExtension(>base, "GLX_SGI_swap_control");
__glXEnableDirectExtension(>base, "GLX_MESA_swap_control");
__glXEnableDirectExtension(>base, "GLX_SGI_make_current_read");
-
-   /*
-* GLX_INTEL_swap_event is broken on the server side, where it's
-* currently unconditionally enabled. This completely breaks
-* systems running on drivers which don't support that extension.
-* There's no way to test for its presence on this side, so instead
-* of disabling it unconditionally, just disable it for drivers
-* which are known to not support it, or for DDX drivers supporting
-* only an older (pre-ScheduleSwap) version of DRI2.
-*
-* This is a hack which is required until:
-* http://lists.x.org/archives/xorg-devel/2013-February/035449.html
-* is merged and updated xserver makes it's way into distros:
-*/
-//   if (pdp->swapAvailable && strcmp(driverName, "vmwgfx") != 0) {
-//  __glXEnableDirectExtension(>base, "GLX_INTEL_swap_event");
-//   }
+   __glXEnableDirectExtension(>base, "GLX_INTEL_swap_event");

mask = psc->image_driver->getAPIMask(psc->driScreen);

-- 
1.8.4.4

[PATCH 3/4] dri3: Fix dri3_wait_for_sbc to wait for completion of requested SBC

2013-11-25 Thread Keith Packard

Eric figured out that glXWaitForSbcOML wanted to block until the requested SBC
had been completed, which means to wait until the PresentCompleteNotify event
for that SBC had been received.

This replaces the simple sleep(1) loop (which was bogus) with a loop that just
checks to see if we've seen the specified SBC value come back in a
PresentCompleteNotify event yet.

The change is a bit larger than that as I've broken out a piece of common code
to wait for and process a single Present event for the target drawable.

Signed-off-by: Keith Packard 
---
 src/glx/dri3_glx.c | 55 ++
 1 file changed, 39 insertions(+), 16 deletions(-)

diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index c0915f2..da3f08b 100644
--- a/src/glx/dri3_glx.c
+++ b/src/glx/dri3_glx.c
@@ -397,14 +397,33 @@ dri3_handle_present_event(struct dri3_drawable *priv, 
xcb_present_generic_event_
free(ge);
 }

+static bool
+dri3_wait_for_event(__GLXDRIdrawable *pdraw)
+{
+   xcb_connection_t *c = XGetXCBConnection(pdraw->psc->dpy);
+   struct dri3_drawable *priv = (struct dri3_drawable *) pdraw;
+   xcb_generic_event_t *ev;
+   xcb_present_generic_event_t *ge;
+
+   ev = xcb_wait_for_special_event(c, priv->special_event);
+   if (!ev)
+  return false;
+   ge = (void *) ev;
+   dri3_handle_present_event(priv, ge);
+   return true;
+}
+
+/** dri3_wait_for_msc
+ *
+ * Get the X server to send an event when the target msc/divisor/remainder is
+ * reached.
+ */
 static int
 dri3_wait_for_msc(__GLXDRIdrawable *pdraw, int64_t target_msc, int64_t divisor,
   int64_t remainder, int64_t *ust, int64_t *msc, int64_t *sbc)
 {
xcb_connection_t *c = XGetXCBConnection(pdraw->psc->dpy);
struct dri3_drawable *priv = (struct dri3_drawable *) pdraw;
-   xcb_generic_event_t *ev;
-   xcb_present_generic_event_t *ge;
uint32_t msc_serial;

/* Ask for the an event for the target MSC */
@@ -421,11 +440,8 @@ dri3_wait_for_msc(__GLXDRIdrawable *pdraw, int64_t 
target_msc, int64_t divisor,
/* Wait for the event */
if (priv->special_event) {
   while ((int32_t) (msc_serial - priv->recv_msc_serial) > 0) {
- ev = xcb_wait_for_special_event(c, priv->special_event);
- if (!ev)
-break;
- ge = (void *) ev;
- dri3_handle_present_event(priv, ge);
+ if (!dri3_wait_for_event(pdraw))
+return 0;
   }
}

@@ -436,6 +452,11 @@ dri3_wait_for_msc(__GLXDRIdrawable *pdraw, int64_t 
target_msc, int64_t divisor,
return 1;
 }

+/** dri3_drawable_get_msc
+ *
+ * Return the current UST/MSC/SBC triplet by asking the server
+ * for an event
+ */
 static int
 dri3_drawable_get_msc(struct glx_screen *psc, __GLXDRIdrawable *pdraw,
   int64_t *ust, int64_t *msc, int64_t *sbc)
@@ -445,12 +466,9 @@ dri3_drawable_get_msc(struct glx_screen *psc, 
__GLXDRIdrawable *pdraw,

 /** dri3_wait_for_sbc
  *
- * Wait for the swap buffer count to increase. The only way this
- * can happen is if some other thread is doing swap buffers as
- * we no longer share swap buffer counts with other processes.
- *
- * I'm not sure this is actually useful as such, and so this
- * implementation is a kludge that just polls once a second
+ * Wait for the completed swap buffer count to reach the specified
+ * target. Presumably the application knows that this will be reached with
+ * outstanding complete events, or we're going to be here awhile.
  */
 static int
 dri3_wait_for_sbc(__GLXDRIdrawable *pdraw, int64_t target_sbc, int64_t *ust,
@@ -458,10 +476,15 @@ dri3_wait_for_sbc(__GLXDRIdrawable *pdraw, int64_t 
target_sbc, int64_t *ust,
 {
struct dri3_drawable *priv = (struct dri3_drawable *) pdraw;

-   while (priv->send_sbc < target_sbc) {
-  sleep(1);
+   while (priv->recv_sbc < target_sbc) {
+  if (!dri3_wait_for_event(pdraw))
+ return 0;
}
-   return dri3_wait_for_msc(pdraw, 0, 0, 0, ust, msc, sbc);
+
+   *ust = priv->ust;
+   *msc = priv->msc;
+   *sbc = priv->recv_sbc;
+   return 1;
 }

 /**
-- 
1.8.4.4

[PATCH 2/4] dri3: Track full 64-bit SBC numbers, instead of just 32-bits

2013-11-25 Thread Keith Packard

Tracking the full 64-bit SBC values makes it clearer how those values are
being used, and simplifies the wait_msc code. The only trick is in
re-constructing the full 64-bit value from Present's 32-bit serial number that
we use to pass the SBC value from request to event.

Signed-off-by: Keith Packard 
---
 src/glx/dri3_glx.c  | 34 +-
 src/glx/dri3_priv.h | 16 +---
 2 files changed, 30 insertions(+), 20 deletions(-)

diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index 669f0bb..c0915f2 100644
--- a/src/glx/dri3_glx.c
+++ b/src/glx/dri3_glx.c
@@ -364,10 +364,17 @@ dri3_handle_present_event(struct dri3_drawable *priv, 
xcb_present_generic_event_
case XCB_PRESENT_COMPLETE_NOTIFY: {
   xcb_present_complete_notify_event_t *ce = (void *) ge;

-  if (ce->kind == XCB_PRESENT_COMPLETE_KIND_PIXMAP)
- priv->present_event_serial = ce->serial;
-  else
- priv->present_msc_event_serial = ce->serial;
+  /* Compute the processed SBC number from the received 32-bit serial 
number merged
+   * with the upper 32-bits of the sent 64-bit serial number while 
checking for
+   * wrap
+   */
+  if (ce->kind == XCB_PRESENT_COMPLETE_KIND_PIXMAP) {
+ priv->recv_sbc = (priv->send_sbc & 0xLL) | ce->serial;
+ if (priv->recv_sbc > priv->send_sbc)
+priv->recv_sbc -= 0x1;
+  } else {
+ priv->recv_msc_serial = ce->serial;
+  }
   priv->ust = ce->ust;
   priv->msc = ce->msc;
   break;
@@ -398,12 +405,13 @@ dri3_wait_for_msc(__GLXDRIdrawable *pdraw, int64_t 
target_msc, int64_t divisor,
struct dri3_drawable *priv = (struct dri3_drawable *) pdraw;
xcb_generic_event_t *ev;
xcb_present_generic_event_t *ge;
+   uint32_t msc_serial;

/* Ask for the an event for the target MSC */
-   ++priv->present_msc_request_serial;
+   msc_serial = ++priv->send_msc_serial;
xcb_present_notify_msc(c,
   priv->base.xDrawable,
-  priv->present_msc_request_serial,
+  msc_serial,
   target_msc,
   divisor,
   remainder);
@@ -412,7 +420,7 @@ dri3_wait_for_msc(__GLXDRIdrawable *pdraw, int64_t 
target_msc, int64_t divisor,

/* Wait for the event */
if (priv->special_event) {
-  while (priv->present_msc_request_serial != 
priv->present_msc_event_serial) {
+  while ((int32_t) (msc_serial - priv->recv_msc_serial) > 0) {
  ev = xcb_wait_for_special_event(c, priv->special_event);
  if (!ev)
 break;
@@ -423,7 +431,7 @@ dri3_wait_for_msc(__GLXDRIdrawable *pdraw, int64_t 
target_msc, int64_t divisor,

*ust = priv->ust;
*msc = priv->msc;
-   *sbc = priv->sbc;
+   *sbc = priv->recv_sbc;

return 1;
 }
@@ -450,7 +458,7 @@ dri3_wait_for_sbc(__GLXDRIdrawable *pdraw, int64_t 
target_sbc, int64_t *ust,
 {
struct dri3_drawable *priv = (struct dri3_drawable *) pdraw;

-   while (priv->sbc < target_sbc) {
+   while (priv->send_sbc < target_sbc) {
   sleep(1);
}
return dri3_wait_for_msc(pdraw, 0, 0, 0, ust, msc, sbc);
@@ -1282,15 +1290,15 @@ dri3_swap_buffers(__GLXDRIdrawable *pdraw, int64_t 
target_msc, int64_t divisor,
   /* Compute when we want the frame shown by taking the last known 
successful
* MSC and adding in a swap interval for each outstanding swap request
*/
-  ++priv->present_request_serial;
+  ++priv->send_sbc;
   if (target_msc == 0)
- target_msc = priv->msc + priv->swap_interval * 
(priv->present_request_serial - priv->present_event_serial);
+ target_msc = priv->msc + priv->swap_interval * (priv->send_sbc - 
priv->recv_sbc);

   priv->buffers[buf_id]->busy = 1;
   xcb_present_pixmap(c,
  priv->base.xDrawable,
  priv->buffers[buf_id]->pixmap,
- priv->present_request_serial,
+ (uint32_t) priv->send_sbc,
  0,/* valid */
  0,/* update */
  0,/* x_off */
@@ -1302,7 +1310,7 @@ dri3_swap_buffers(__GLXDRIdrawable *pdraw, int64_t 
target_msc, int64_t divisor,
  target_msc,
  divisor,
  remainder, 0, NULL);
-  ret = ++priv->sbc;
+  ret = (int64_t) priv->send_sbc;

   /* If there's a fake front, then copy the source back buffer
* to the fake front to keep it up to date. This needs
diff --git a/src/glx/dri3_priv.h b/src/glx/dri3_priv.h
index 34c67a6..f1fec3c 100644
--- a/src/glx/dri3_priv.h
+++ b/src/glx/dri3_priv.h
@@ -183,16 +183,18 @@ struct dri3_drawable {
uint8_t have_fake_front;
uint8_t is_pixmap;

-   uint32_t present_request_serial;
-

[PATCH 1/4] dri3: Clean up struct dri3_drawable

2013-11-25 Thread Keith Packard

Move the depth field up with width and height.

Remove unused previous_time and frames fields.

Signed-off-by: Keith Packard 
---
 src/glx/dri3_priv.h | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/src/glx/dri3_priv.h b/src/glx/dri3_priv.h
index 05f66cf..34c67a6 100644
--- a/src/glx/dri3_priv.h
+++ b/src/glx/dri3_priv.h
@@ -177,7 +177,7 @@ dri3_pixmap_buf_id(enum dri3_buffer_type buffer_type)
 struct dri3_drawable {
__GLXDRIdrawable base;
__DRIdrawable *driDrawable;
-   int width, height;
+   int width, height, depth;
int swap_interval;
uint8_t have_back;
uint8_t have_fake_front;
@@ -193,13 +193,9 @@ struct dri3_drawable {
/* For WaitMSC */
uint32_t present_msc_request_serial;
uint32_t present_msc_event_serial;
-   
-   uint64_t previous_time;
-   unsigned frames;

struct dri3_buffer *buffers[DRI3_NUM_BUFFERS];
int cur_back;
-   int depth;

uint32_t *stamp;

-- 
1.8.4.4

[PATCH 0/4] Clean up dri3 SBC handling, enable GLX_INTEL_swap_event

2013-11-25 Thread Keith Packard

I've split the GLX_INTEL_swap_event enabling patch into four bits -- the first
three just fix the existing code to track SBC values correctly and to fix
wait_for_sbc. The fourth is the trivial patch to actually turn on the new
extension; all of the hard work for that is actually dealt with in the X
server.

 [PATCH 1/4] dri3: Clean up struct dri3_drawable

Trivial struct member cleanup -- a couple of unused fields, and one oddly
placed field.

 [PATCH 2/4] dri3: Track full 64-bit SBC numbers, instead of just

This switches all of the internal SBC tracking to use 64-bit values. I use
uint64_t because I don't trust compilers with signed integer comparisons that
may wrap any more.

 [PATCH 3/4] dri3: Fix dri3_wait_for_sbc to wait for completion of

This one makes wait_for_sbc actually wait for the completion of the specified
swap, rather than the queuing of that value. Makes *far* more sense this way.

 [PATCH 4/4] dri3: Enable GLX_INTEL_swap_event

The trivial patch that just adds the extension to the list.

-keith

[RFC patch] PCI: Extend boot_vga sysfs attribute lookup to fix X on MBA+EFI

2013-11-25 Thread Bruno Prémont

On a MacBookAir2,1, booting to Linux with EFI though having
no efifb built-in Xorg refuses to start with "no devices detected"
because for the only VGA device available (NVidia Geforce 9400M)
the sysfs attribute boot_vga is zero (instead of expected 1).

When CONFIG_FB_EFI is selected, efifb does provide its own
vga_default_device() to report the PCI device matching global
screen_info as determined during efifb setup.

Otherwise there is just a dummy or VGA_ARB's vga_default_device()
that does not provide the right information.

On the other hand, boot_vga_show() falls back to poking PCI
resources to flag a PCI device as boot_vga if vga_default_device()
returned no PCI device (NULL).

To complement this PCI resource poking, this patch copies the
validation code used to determine which PCI device to report as
default VGA device by efifb into boot_vga_show().

Signed-off-by: Bruno Pr?mont 
---
Would it make sense to kill the corresponding code from efifb
as it covers only a single case?

The other EFI capable system I have (AMD Ilano based, Gigabyte
mainboard does report boot_vga=1, possibly through the resources
poking and there Xorg starts properly without efifb built in.

Selecting CONFIG_X86_SYSFB (combined with CONFIG_FB_SIMPLE) does
not help by itself, patching that one instead of PCI's boot_vga
attribute directly would still not cover the case when neither
of them is enabled.


 drivers/pci/pci-sysfs.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index 7128cfd..91cac71 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "pci.h"

@@ -540,6 +541,26 @@ boot_vga_show(struct device *dev, struct device_attribute 
*attr, char *buf)
if (vga_dev)
return sprintf(buf, "%u\n", (pdev == vga_dev));

+   if ((pdev->class >> 8) == PCI_CLASS_DISPLAY_VGA) {
+   resource_size_t start, end;
+   int i;
+
+   for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
+   if (!(pci_resource_flags(pdev, i) & IORESOURCE_MEM))
+   continue;
+
+   start = pci_resource_start(pdev, i);
+   end  = pci_resource_end(pdev, i);
+
+   if (!start || !end)
+   continue;
+
+   if (screen_info.lfb_base >= start &&
+   (screen_info.lfb_base + screen_info.lfb_size) < 
end)
+   return sprintf(buf, "1\n");
+   }
+   }
+
return sprintf(buf, "%u\n",
!!(pdev->resource[PCI_ROM_RESOURCE].flags &
   IORESOURCE_ROM_SHADOW));

[Bug 65811] AMD 7970M (PowerXpress) power management not functioning properly when using Xrandr to offload rendering

2013-11-25 Thread bugzilla-dae...@bugzilla.kernel.org

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

--- Comment #2 from Jack  ---
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor
Graphics Controller (rev 09)
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Wimbledon XT [Radeon HD 7970M]

Linux localhost 3.13.0-1-00085-g7e3528c-dirty #1 SMP PREEMPT Sun Nov 24
17:38:54 CST 2013 x86_64 GNU/Linux

xf86-video-ati-git 3103.d571d6a-1
xf86-video-intel-git 7529.b14228f-1

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 65811] AMD 7970M (PowerXpress) power management not functioning properly when using Xrandr to offload rendering

2013-11-25 Thread bugzilla-dae...@bugzilla.kernel.org

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

--- Comment #1 from Jack  ---
Only kernel option I have set is `radeon.runpm=1`, not sure if this is needed
in 3.13 or if it even matters that I have it.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 65811] New: AMD 7970M (PowerXpress) power management not functioning properly when using Xrandr to offload rendering

2013-11-25 Thread bugzilla-dae...@bugzilla.kernel.org

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

Bug ID: 65811
   Summary: AMD 7970M (PowerXpress) power management not
functioning properly when using Xrandr to offload
rendering
   Product: Drivers
   Version: 2.5
Kernel Version: 3.13-rc1
  Hardware: x86-64
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-dri at kernel-bugs.osdl.org
  Reporter: jack at cyphernaut.org
Regression: No

rc1 appears to have solved my issues of X not starting or crashing when
starting, which I ran into when using the DRM patches on 3.12. However I've run
into another issue:

When I start my laptop, if I do not immediately offload rendering to the
discrete Radeon card (xrandr --setprovideroffloadsink radeon Intel) the state
in vgaswitcheroo will change to 'DynOff', and xrandr --listproviders will no
longer report the radeon as a potentially offload source

Conversely, if I *do* --setprovideroffloadsink to the radeon within a few
seconds after X starts, the state in vgaswitcheroo changes to DynPwr and never
actually turns off (laptop behaves as if runpm was not enabled at all).

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 69723] GPU lockups with kernel 3.11.0 / 3.12-rc1 when dpm=1 on r600g (Cayman)

2013-11-25 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #37 from Alexandre Demers  ---
(In reply to comment #36)
> (In reply to comment #35)
> > To be noted: I was using a balanced power state this time, not a performance
> > power state. To be investigated.
> 
> On most cards there are only performance states.  Selecting balanced also
> selects performance.  You are probably using the same state in both cases.

This is also what it seems. However, it may be completly unrelated, but I only
had hangs when using the balanced setting.

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

[Bug 71975] [regression][bisected] fast hdmi audio playback

2013-11-25 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #2 from Brian Paterni  ---
(In reply to comment #1)
> Created attachment 89768 [details] [review]
> possible fix
> 
> Does this fix it?

That does, audio is fine now. Thank you very much Alex! :)

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

[Bug 71930] Kernel Bug and X fails to start when using radeon.runpm=1

2013-11-25 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #3 from Alex Deucher  ---
Does manually turning off the dGPU using switcheroo still work with
radeon.runpm=0?  If not, can you bisect?  runpm and switcheroo use the same
apci mechanism to turn off the dGPU.

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

[Bug 41375] VDPAU not working on RS880

2013-11-25 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #8 from Alex Deucher  ---
(In reply to comment #7)
> I'll test it when I get home tonight. I take it its software vdpau. Is it
> only mpeg2 that's implemented?

It's shader based decode for mpeg2.

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

[PATCH] present: Send GLX_BufferSwapComplete events from present extension

2013-11-25 Thread Keith Packard

Eric Anholt  writes:

> There's a minor behavior change that the event now gets sent to the
> drawable owner rather than the caller of DRI2SwapBuffers.

Yeah, probably not ideal, especially when the GLX drawable is created
using the window XID (as is the case for some older GLX clients). I
don't have the original client at the time the event is generated, but I
think I can go back and stick it in; will require tracking when the
client exits, of course.

> I don't expect it to matter in practice (I expect that the
> swap-requesting client using this GLX extension is also the
> drawable-creating one), and either choice seems wrong compared to "send
> the event to everyone listening for the event on this drawable".  That
> would be a separate change, anyway.

I think the original behaviour, sending the event to the client who sent
the PresentPixmap request is the only sane plan, and only a bit more
complicated than sending it to the drawable owner.

I'll cook up an alternate patch and send that along; we can then compare
the two approaches at least.

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131125/64285d3b/attachment-0001.pgp>

[Bug 69728] Radeon Redwood (5670) GPU Lockup

2013-11-25 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #10 from pablow.1422 at gmail.com ---
Actually, using adobe flash 11.2 wich is the latest usable version with firefox
didn't bring a lockup, only adobe version 11.9 (PPAPI) with google chrome did.

Still, all the issues I had described in previous post still happens, like:
Wine Games (counter strike 1.6 wich I belive is OpenGL 2.0), O AD, Xonotic
causing a total system hang, after trying to reset the GPU several times (as I
could see from the logs). To add, normal desktop usage (without counting the
adobe flash issues) like libreoffice gpu acceleration, vdpau video player, Kwin
composited, etc it's in good shape. 

I've also tried set env var R600_DEBUG=nohyperz; R600_DEBUG=nodma;
R600_DEBUG=nosb; R600_LLVM=0 with no luck.

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

[Bug 71975] [regression][bisected] fast hdmi audio playback

2013-11-25 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #1 from Alex Deucher  ---
Created attachment 89768
  --> https://bugs.freedesktop.org/attachment.cgi?id=89768=edit
possible fix

Does this fix it?

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

[Bug 69728] Radeon Redwood (5670) GPU Lockup

2013-11-25 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #9 from Alex Deucher  ---
(In reply to comment #8)
> Sorry to bump.. but this bug have became very frustating. Now watching
> videos with flash cant be done without a lockup ocurring aproximately 20% of
> times (with rendering relying on GPU, software decoding). With fglrx it's OK.

Are you using adobe's flash player?  Do you still get lockups using something
other than adobe's flash player?  It's known to be buggy.

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

[Bug 69723] GPU lockups with kernel 3.11.0 / 3.12-rc1 when dpm=1 on r600g (Cayman)

2013-11-25 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #36 from Alex Deucher  ---
(In reply to comment #35)
> To be noted: I was using a balanced power state this time, not a performance
> power state. To be investigated.

On most cards there are only performance states.  Selecting balanced also
selects performance.  You are probably using the same state in both cases.

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

[Bug 65771] Oops after starting nouveau with NVAA / NV50 (Nvidia 8200)

2013-11-25 Thread bugzilla-dae...@bugzilla.kernel.org

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

--- Comment #2 from dirk.neukirchen at student.hu-berlin.de ---
Created attachment 116001
  --> https://bugzilla.kernel.org/attachment.cgi?id=116001=edit
dmesg of successfull boot of 3.12.1

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 65771] Oops after starting nouveau with NVAA / NV50 (Nvidia 8200)

2013-11-25 Thread bugzilla-dae...@bugzilla.kernel.org

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

--- Comment #1 from dirk.neukirchen at student.hu-berlin.de ---
Created attachment 115991
  --> https://bugzilla.kernel.org/attachment.cgi?id=115991=edit
acpidump output; just in case

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 65771] New: Oops after starting nouveau with NVAA / NV50 (Nvidia 8200)

2013-11-25 Thread bugzilla-dae...@bugzilla.kernel.org

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

Bug ID: 65771
   Summary: Oops after starting nouveau with NVAA / NV50 (Nvidia
8200)
   Product: Drivers
   Version: 2.5
Kernel Version: 3.13-rc1
  Hardware: i386
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: high
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-dri at kernel-bugs.osdl.org
  Reporter: dirk.neukirchen at student.hu-berlin.de
Regression: Yes

Created attachment 115981
  --> https://bugzilla.kernel.org/attachment.cgi?id=115981=edit
3.13-rc1 debug kernel log recv. via netconsole

Desktop didn't come up after updating Kernel from 3.12.0 to 3.13-rc1.
Screen remains black.

A netconsole log showed the messages possibly responsable for the Oops:
[   11.132842] nouveau E[ CLK][:02:00.0] 17 freq unknown
[   11.132901] nouveau E[ CLK][:02:00.0] init failed, -22
[   11.132966] nouveau E[ DRM] failed to create 0x8080, -22
[   11.133734] nouveau: probe of :02:00.0 failed with error -22

System:
- Linux Mint 15 with vanilla kernel 3.13-rc1
- dual screen

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 71930] Kernel Bug and X fails to start when using radeon.runpm=1

2013-11-25 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #2 from Mike Lothian  ---
I think the same issue has been reported upstream too

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

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

[Bug 65761] HD 7970M Hybrid - hangs and errors and rmmod causes crash

2013-11-25 Thread bugzilla-dae...@bugzilla.kernel.org

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

Mike Lothian  changed:

   What|Removed |Added

 CC||mike at fireburn.co.uk

--- Comment #1 from Mike Lothian  ---
I believe this is related to https://bugs.freedesktop.org/show_bug.cgi?id=71930

I think the memory Warnings have been fixed by either:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm?id=c58f009e01c918717379c206a63baa66f56a77f9

or

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm?id=0bc254257bfd9b25f64a68b719ee70a303b6d051

As a workaround you can boot with radeon.runpm=0 but that'll leave your
discreet card powered up

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 65761] New: HD 7970M Hybrid - hangs and errors and rmmod causes crash

2013-11-25 Thread bugzilla-dae...@bugzilla.kernel.org

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

Bug ID: 65761
   Summary: HD 7970M Hybrid - hangs and errors and rmmod causes
crash
   Product: Drivers
   Version: 2.5
Kernel Version: 3.13-rc1
  Hardware: x86-64
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-dri at kernel-bugs.osdl.org
  Reporter: haagch.christoph at googlemail.com
Regression: No

Created attachment 115961
  --> https://bugzilla.kernel.org/attachment.cgi?id=115961=edit
dmesg with multiple issues

00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor
Graphics Controller (rev 09)
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Wimbledon XT [Radeon HD 7970M]
muxless, so there's no display outputs on the radeon gpu.

With 3.13 and dpm and runtime power management enabled by default this should
be getting usable.
I did not start X this time.
(when starting X on the intel gpu quickly after booting (presumably before
radeon is initialized) the display output hangs, which is yet another problem).

Dmesg seems to contain several issues.

1. While booting it already produces these before even "dpm initialized" is
logged:

[   20.120137] WARNING: CPU: 0 PID: 53 at drivers/gpu/drm/drm_mm.c:578
drm_mm_takedown+0x2e/0x30 [drm]()
[   20.120138] Memory manager not clean during takedown.

2. These are just periodically displayed in the tty:

[   79.179928] [drm:r600_ib_test] *ERROR* radeon: fence wait failed (-35).
[   79.181378] [drm:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB on
GFX ring (-35).
[   79.182790] [drm:radeon_resume_kms] *ERROR* ib ring test failed (-35).

3. After some time in a tty, I did "rmmod radeon" and got some other issues
ending with

[  192.663059] Fixing recursive fault but reboot is needed!

and then, after a little while a lot of other errors happen, but they are not
captured here in the dmesg.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Mesa-dev] [PATCH] intel: Track known prime buffers for re-use

2013-11-25 Thread Daniel Vetter

On Fri, Nov 22, 2013 at 05:35:54AM -0800, Keith Packard wrote:
> If the application sends us a file descriptor pointing at a prime
> buffer that we've already got, we have to re-use the same bo_gem
> structure or chaos will result.
> 
> Track the set of all known prime objects and look to see if the kernel
> has returned one of those for a new file descriptor.
> 
> Signed-off-by: Keith Packard 
> ---
> 
> This one took a while to find -- multiple bo_gem structs pointing at
> the same gem handle would either cause the object to be destroyed
> before we were done using it, or we'd end up sending the same
> gem_handle for multiple buffers.
> 
> This looks a lot like the named object handling stuff, as one would
> expect.

Yeah, it unfortunately took a few rounds of kernel fixes and other
haggling to get the semantics right on this one. The kernel atm promises
to userspace (minus one big in a racy corner case no one should care
about, still need to fix that one) that it'll return the same gem handle
if userspace already has one for the underlying object.

We need that to make sure userspace doesn't submit the same bo in execbuf
multiple times and then upsets the kernel - we'll reject such batches as
userspace bugs.

I guess I should have reviewed userspace when doing the relevant kernel
fixes, shame on me. Two questions below.

> 
>  intel/intel_bufmgr_gem.c | 22 +-
>  1 file changed, 21 insertions(+), 1 deletion(-)
> 
> diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
> index df6fcec..2897bb2 100644
> --- a/intel/intel_bufmgr_gem.c
> +++ b/intel/intel_bufmgr_gem.c
> @@ -112,6 +112,7 @@ typedef struct _drm_intel_bufmgr_gem {
>  
>   drmMMListHead named;
>   drmMMListHead vma_cache;
> +drmMMListHead prime;
>   int vma_count, vma_open, vma_max;
>  
>   uint64_t gtt_size;
> @@ -2451,8 +2452,25 @@ drm_intel_bo_gem_create_from_prime(drm_intel_bufmgr 
> *bufmgr, int prime_fd, int s
>   uint32_t handle;
>   drm_intel_bo_gem *bo_gem;
>   struct drm_i915_gem_get_tiling get_tiling;
> + drmMMListHead *list;
>  
>   ret = drmPrimeFDToHandle(bufmgr_gem->fd, prime_fd, );
> +
> + /*
> +  * See if the kernel has already returned this buffer to us. Just as
> +  * for named buffers, we must not create two bo's pointing at the same
> +  * kernel object
> +  */
> + for (list = bufmgr_gem->prime.next;
> +  list != _gem->prime;
> +  list = list->next) {
> + bo_gem = DRMLISTENTRY(drm_intel_bo_gem, list, name_list);
> + if (bo_gem->gem_handle == handle) {
> + drm_intel_gem_bo_reference(_gem->bo);
> + return _gem->bo;
> + }
> + }
> +
>   if (ret) {
> fprintf(stderr,"ret is %d %d\n", ret, errno);
>   return NULL;
> @@ -2487,8 +2505,8 @@ drm_intel_bo_gem_create_from_prime(drm_intel_bufmgr 
> *bufmgr, int prime_fd, int s
>   bo_gem->has_error = false;
>   bo_gem->reusable = false;
>  
> - DRMINITLISTHEAD(_gem->name_list);
>   DRMINITLISTHEAD(_gem->vma_list);
> + DRMLISTADDTAIL(_gem->name_list, _gem->prime);

Won't this result in us having fun when a buffer is both imported from a
prime buffer and then also used with legacy flink? Or is this something
the X server won't support?

The second one is about exporting: With flink names we also add the name
to the lookup list in drm_intel_gem_bo_flink. I think we should do the
same for exported prime buffers just as a precaution - the kernel will
return the (existing) gem name also for a prime buffer that has been
exported by yourself. I guess that would imply insane userspace, but
better safe than sorry.

Cheers, Daniel

>  
>   VG_CLEAR(get_tiling);
>   get_tiling.handle = bo_gem->gem_handle;
> @@ -3301,5 +3319,7 @@ drm_intel_bufmgr_gem_init(int fd, int batch_size)
>   DRMINITLISTHEAD(_gem->vma_cache);
>   bufmgr_gem->vma_max = -1; /* unlimited by default */
>  
> + DRMINITLISTHEAD(_gem->prime);
> +
>   return _gem->bufmgr;
>  }
> -- 
> 1.8.4.3
> 
> ___
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Intel-gfx] [Mesa-dev] [PATCH] dri3, i915, i965: Add __DRI_IMAGE_FOURCC_SARGB8888

2013-11-25 Thread Ville Syrjälä

On Mon, Nov 25, 2013 at 09:57:23AM +0100, Daniel Vetter wrote:
> On Fri, Nov 22, 2013 at 02:12:13PM -0800, Kristian H?gsberg wrote:
> > I don't know what else you'd propose?  Pass an X visual in the ioctl?
> > An EGL config?  This is our name space, we can add stuff as we need
> > (as Keith is doing here). include/uapi/drm/drm_fourcc.h is the
> > canonical source for these values and we should add
> > DRM_FORMAT_SARGB there to make sure we don't clash.
> 
> Well that's kinda the problem. If you don't expect the kernel to clash
> with whatever mesa is using internally then we should add it to the
> kernel, first. That's kinda what Dave's recent rant has all been about.
> 
> The other issue was that originally the idea behind fourcc was to have one
> formate namespace shared between drm, v4l and whomever else cares. If
> people are happy to drop that idea on the floor I won't shed a single
> tear.

I broke that idea alredy when I cooked up the current drm fourccs.
I didn't cross check them with any other fourcc source, so I'm 100%
sure most of them don't match anything else.

-- 
Ville Syrj?l?
Intel OTC

[RFC v2 PATCH] mipi-dsi-bus: add MIPI DSI bus support

2013-11-25 Thread Andrzej Hajda

Hi Thierry,

Thanks for the review.


On 11/22/2013 06:41 PM, Thierry Reding wrote:
> On Mon, Nov 18, 2013 at 05:25:23PM +0100, Andrzej Hajda wrote:
>> MIPI DSI bus allows to model DSI hosts
>> and DSI devices using Linux bus.
> This looks somewhat terse. Any chance you could be more verbose about
> what exactly this does? You could mention for instance that it allows
> DSI devices to be instantiated from device tree and manually. That a
> Linux bus type is provided and device drivers can use that to bind to
> DSI devices.
OK.
>
>> Signed-off-by: Andrzej Hajda 
>> Signed-off-by: Kyungmin Park 
>> ---
>> Hi,
>>
>> This is my implementation of mipi dsi bus.
>> The first time it was posted as a part of CDF infrastructure [1],
>> but if it can be merged independently I will be glad.
>>
>> I have not addressed yet Bert's comments, but I think it should
>> be easy, once we have agreement how to implement it.
>>
>> There are also working drivers which uses this bus:
>> - Exynos DSI master,
>> - s6e8aa0 panel.
>> I will post them later.
>>
>> [1] http://www.mail-archive.com/dri-devel at 
>> lists.freedesktop.org/msg45252.html
>>
>> Changes:
>> v2:
>> - set_power callback removed (its role is passed to RUNTIME_PM),
>> - changed transfer ops parameters to struct,
>> - changed source location,
>> - minor fixes
>>
>> Regards
>> Andrzej
>>
>> ---
>>  drivers/gpu/drm/Kconfig|   4 +
>>  drivers/gpu/drm/Makefile   |   2 +
>>  drivers/gpu/drm/drm_mipi_dsi.c | 344 
>> +
>>  include/drm/drm_mipi_dsi.h | 154 ++
>>  4 files changed, 504 insertions(+)
>>  create mode 100644 drivers/gpu/drm/drm_mipi_dsi.c
>>  create mode 100644 include/drm/drm_mipi_dsi.h
> This seems to be missing a device tree binding document. That could
> probably be rather small since there's not a lot there right now. I
> volunteer to draft that document if you don't have the time to do
> that.
>
>> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
>> index f864275..58a603d 100644
>> --- a/drivers/gpu/drm/Kconfig
>> +++ b/drivers/gpu/drm/Kconfig
>> @@ -20,6 +20,10 @@ menuconfig DRM
>>details.  You should also select and configure AGP
>>(/dev/agpgart) support if it is available for your platform.
>>  
>> +config DRM_MIPI_DSI
>> +tristate
>> +default y
> Shouldn't this remain off by default? And only be selected by drivers
> that actually need it. I think that DSI host drivers could select this
> symbol and DSI peripheral drivers can depend on it. That way you'll
> automatically be able to only select peripheral drivers if there's at
> least one DSI host driver enabled.
Yes, of course. I just forgot to set it back properly after last tests.
>
>> diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
> [...]
>> +/*
>> + * MIPI DSI Bus
>> + *
>> + * Copyright (C) 2012, Samsung Electronics, Co., Ltd.
> Perhaps this should now be "2012-2013"?
Yes, thanks.
>
>> + * Andrzej Hajda 
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
> Can these please be ordered alphabetically?
OK
>
>> +/* 
>> -
>> + * Bus operations
>> + */
> Nitpick: I'm not a huge fan of these separators. They have a tendency to
> get in the way when people add new functions and then all of a sudden
> they no longer fit into that category...
>
>> +int mipi_dsi_init(struct mipi_dsi_device *dev)
>> +{
> [...]
>> +}
>> +EXPORT_SYMBOL_GPL(mipi_dsi_init);
>> +
>> +int mipi_dsi_set_stream(struct mipi_dsi_device *dev, bool on)
>> +{
> [...]
>> +}
>> +EXPORT_SYMBOL_GPL(mipi_dsi_set_stream);
> These are missing documentation. It's not clear at all what they are
> supposed to do.
>
>> +int mipi_dsi_dcs_write(struct mipi_dsi_device *dev, int channel, const u8 
>> *data,
> unsigned int for channel, please. And const void * for data so that the
> same type is used consistently.
>
>> +static struct device_attribute mipi_dsi_dev_attrs[] = {
> static const?
>
> I also believe these now need to be done using attribute groups. Look at
> commit d06262e58546 (driver-core: platform: convert bus code to use
> dev_groups) for an example of how to do that.

>> +static const struct dev_pm_ops mipi_dsi_dev_pm_ops = {
>> +.runtime_suspend = pm_generic_runtime_suspend,
>> +.runtime_resume = pm_generic_runtime_resume,
>> +.suspend = pm_generic_suspend,
>> +.resume = pm_generic_resume,
>> +.freeze = pm_generic_freeze,
>> +.thaw = pm_generic_thaw,
>> +.poweroff = pm_generic_poweroff,
>> +.restore = pm_generic_restore,
>> +};
>> +
>> +static struct bus_type mipi_dsi_bus_type

[Intel-gfx] [Mesa-dev] [PATCH] dri3, i915, i965: Add __DRI_IMAGE_FOURCC_SARGB8888

2013-11-25 Thread Geert Uytterhoeven

On Sat, Nov 23, 2013 at 2:10 AM, Ville Syrj?l?
 wrote:
> On Fri, Nov 22, 2013 at 03:43:13PM -0800, Keith Packard wrote:
>> Ville Syrj?l?  writes:
>>
>> > What is this format anyway? -ENODOCS
>>
>> Same as MESA_FORMAT_SARGB8 and __DRI_IMAGE_FORMAT_SARGB8 :-)
>>
>> > If its just an srgb version of ARGB, then I wouldn't really want it
>> > in drm_fourcc.h. I expect colorspacy stuff will be handled by various
>> > crtc/plane properties in the kernel so we don't need to encode that
>> > stuff into the fb format.
>>
>> It's not any different from splitting YUV codes from RGB codes;
>
> Not really. Saying something is YUV (or rather Y'CbCr) doesn't
> actually tell you the color space. It just tells you whether the
> information is encoded as R+G+B or Y+Cb+Cr. How you convert between
> them is another matter. You need to know the gamma, color primaries,
> chroma siting for sub-sampled YCbCr formats, etc.

Yep. Fbdev has a separation of type (how pixel values are laid out in memory),
fb_bitfield structs (how tuples are formed into pixels), and visual (how to
interprete the tuples).

The fb_bitfield structs do have RGB-centric names, but you could use them
for e.g. Y, Cb, Cr, and alpha, giving a proper visual. Unfortunately the
YCbCr visuals haven't made it into mainline.

FOURCC unifies all of that in (not so) unique 32-bit IDs.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 
linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

[PATCH 2/2] drm/radeon: add radeon_vm_bo_update trace point

2013-11-25 Thread Christian König

From: Christian K?nig 

Also rename the function to better reflect what it is doing.

Signed-off-by: Christian K?nig 
---
 drivers/gpu/drm/radeon/radeon.h   |  8 
 drivers/gpu/drm/radeon/radeon_cs.c|  4 ++--
 drivers/gpu/drm/radeon/radeon_gart.c  | 14 --
 drivers/gpu/drm/radeon/radeon_trace.h | 18 ++
 4 files changed, 32 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index ecf2a39..b1f990d 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -2710,10 +2710,10 @@ void radeon_vm_fence(struct radeon_device *rdev,
 struct radeon_vm *vm,
 struct radeon_fence *fence);
 uint64_t radeon_vm_map_gart(struct radeon_device *rdev, uint64_t addr);
-int radeon_vm_bo_update_pte(struct radeon_device *rdev,
-   struct radeon_vm *vm,
-   struct radeon_bo *bo,
-   struct ttm_mem_reg *mem);
+int radeon_vm_bo_update(struct radeon_device *rdev,
+   struct radeon_vm *vm,
+   struct radeon_bo *bo,
+   struct ttm_mem_reg *mem);
 void radeon_vm_bo_invalidate(struct radeon_device *rdev,
 struct radeon_bo *bo);
 struct radeon_bo_va *radeon_vm_bo_find(struct radeon_vm *vm,
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
b/drivers/gpu/drm/radeon/radeon_cs.c
index f41594b..0b36616 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -360,13 +360,13 @@ static int radeon_bo_vm_update_pte(struct 
radeon_cs_parser *parser,
struct radeon_bo *bo;
int r;

-   r = radeon_vm_bo_update_pte(rdev, vm, rdev->ring_tmp_bo.bo, 
>ring_tmp_bo.bo->tbo.mem);
+   r = radeon_vm_bo_update(rdev, vm, rdev->ring_tmp_bo.bo, 
>ring_tmp_bo.bo->tbo.mem);
if (r) {
return r;
}
list_for_each_entry(lobj, >validated, tv.head) {
bo = lobj->bo;
-   r = radeon_vm_bo_update_pte(parser->rdev, vm, bo, >tbo.mem);
+   r = radeon_vm_bo_update(parser->rdev, vm, bo, >tbo.mem);
if (r) {
return r;
}
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c 
b/drivers/gpu/drm/radeon/radeon_gart.c
index aa8f778..96e4400 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -1118,7 +1118,7 @@ static void radeon_vm_update_ptes(struct radeon_device 
*rdev,
 }

 /**
- * radeon_vm_bo_update_pte - map a bo into the vm page table
+ * radeon_vm_bo_update - map a bo into the vm page table
  *
  * @rdev: radeon_device pointer
  * @vm: requested vm
@@ -1130,10 +1130,10 @@ static void radeon_vm_update_ptes(struct radeon_device 
*rdev,
  *
  * Object have to be reserved & global and local mutex must be locked!
  */
-int radeon_vm_bo_update_pte(struct radeon_device *rdev,
-   struct radeon_vm *vm,
-   struct radeon_bo *bo,
-   struct ttm_mem_reg *mem)
+int radeon_vm_bo_update(struct radeon_device *rdev,
+   struct radeon_vm *vm,
+   struct radeon_bo *bo,
+   struct ttm_mem_reg *mem)
 {
struct radeon_ib ib;
struct radeon_bo_va *bo_va;
@@ -1178,6 +1178,8 @@ int radeon_vm_bo_update_pte(struct radeon_device *rdev,
bo_va->valid = false;
}

+   trace_radeon_vm_bo_update(bo_va);
+
nptes = radeon_bo_ngpu_pages(bo);

/* assume two extra pdes in case the mapping overlaps the borders */
@@ -1259,7 +1261,7 @@ int radeon_vm_bo_rmv(struct radeon_device *rdev,
mutex_lock(>vm_manager.lock);
mutex_lock(_va->vm->mutex);
if (bo_va->soffset) {
-   r = radeon_vm_bo_update_pte(rdev, bo_va->vm, bo_va->bo, NULL);
+   r = radeon_vm_bo_update(rdev, bo_va->vm, bo_va->bo, NULL);
}
mutex_unlock(>vm_manager.lock);
list_del(_va->vm_list);
diff --git a/drivers/gpu/drm/radeon/radeon_trace.h 
b/drivers/gpu/drm/radeon/radeon_trace.h
index 8c13aec..ba74718 100644
--- a/drivers/gpu/drm/radeon/radeon_trace.h
+++ b/drivers/gpu/drm/radeon/radeon_trace.h
@@ -62,6 +62,24 @@ TRACE_EVENT(radeon_vm_grab_id,
TP_printk("vmid=%u, ring=%u", __entry->vmid, __entry->ring)
 );

+TRACE_EVENT(radeon_vm_bo_update,
+   TP_PROTO(struct radeon_bo_va *bo_va),
+   TP_ARGS(bo_va),
+   TP_STRUCT__entry(
+__field(u64, soffset)
+__field(u64, eoffset)
+__field(u32, flags)
+),
+
+   TP_fast_assign(
+  __entry->soffset = bo_va->soffset;
+  __entry->eoffset = bo_va->eoffset;
+  __entry->flags =

[PATCH 1/2] drm/radeon: add VMID allocation trace point

2013-11-25 Thread Christian König

From: Christian K?nig 

Signed-off-by: Christian K?nig 
---
 drivers/gpu/drm/radeon/radeon_gart.c  |  2 ++
 drivers/gpu/drm/radeon/radeon_trace.h | 15 +++
 2 files changed, 17 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon_gart.c 
b/drivers/gpu/drm/radeon/radeon_gart.c
index 3044e50..aa8f778 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -29,6 +29,7 @@
 #include 
 #include "radeon.h"
 #include "radeon_reg.h"
+#include "radeon_trace.h"

 /*
  * GART
@@ -737,6 +738,7 @@ struct radeon_fence *radeon_vm_grab_id(struct radeon_device 
*rdev,
for (i = 0; i < 2; ++i) {
if (choices[i]) {
vm->id = choices[i];
+   trace_radeon_vm_grab_id(vm->id, ring);
return rdev->vm_manager.active[choices[i]];
}
}
diff --git a/drivers/gpu/drm/radeon/radeon_trace.h 
b/drivers/gpu/drm/radeon/radeon_trace.h
index 9f0e181..8c13aec 100644
--- a/drivers/gpu/drm/radeon/radeon_trace.h
+++ b/drivers/gpu/drm/radeon/radeon_trace.h
@@ -47,6 +47,21 @@ TRACE_EVENT(radeon_cs,
  __entry->fences)
 );

+TRACE_EVENT(radeon_vm_grab_id,
+   TP_PROTO(unsigned vmid, int ring),
+   TP_ARGS(vmid, ring),
+   TP_STRUCT__entry(
+__field(u32, vmid)
+__field(u32, ring)
+),
+
+   TP_fast_assign(
+  __entry->vmid = vmid;
+  __entry->ring = ring;
+  ),
+   TP_printk("vmid=%u, ring=%u", __entry->vmid, __entry->ring)
+);
+
 TRACE_EVENT(radeon_vm_set_page,
TP_PROTO(uint64_t pe, uint64_t addr, unsigned count,
 uint32_t incr, uint32_t flags),
-- 
1.8.1.2

[Bug 71975] [regression][bisected] fast hdmi audio playback

2013-11-25 Thread bugzilla-dae...@freedesktop.org

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

Brian Paterni  changed:

   What|Removed |Added

   Assignee|xorg-driver-ati at lists.x.org |dri-devel at 
lists.freedesktop
   ||.org
 QA Contact|xorg-team at lists.x.org   |
Product|xorg|DRI
  Component|Driver/Radeon   |DRM/Radeon

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

[Bug 71983] libdrm 2.4.49 makes gpu crash (HD7770)

2013-11-25 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #5 from Dave Witbrodt  ---
Same problem here on HD 7850 (PITCAIRN 0x1002:0x6819 0x1787:0x2320).

Yesterday I was upgrading my X server to test 1.15 RC2, which requires some
libraries not available on Debian yet.  All was well when I began:

libdrm :  2.4.48
mesa   :  10.1.0-devel (commit 53f89a43 of Nov. 17)
xorg-server:  1.14.99.3
radeon DDX :  7.2.99 (commit d571d6af of Nov. 13)
glamor :  0.5.1 (commit 890a7738 of Nov. 6)
linux  :  3.12.1 (+ some DRM from 3.13rc1)

I had some build failures last time I tried to update the X server, and I saw
bigger than usual changes coming for 1.15, so I thought I should invest some
time into trying to get things working.  After getting the dependencies
satisfied and having succesfully built 1.14.99.902 (with the drivers rebuilt
against it) everything was fine.  In fact, I saw a very noticeable performance
boost.  On a roll, I decided to update Mesa and libdrm, ending up with this set
of packages:

libdrm :  2.4.49
mesa   :  10.1.0-devel (commit f56f875b of Nov. 21)
xorg-server:  1.14.99.902
radeon DDX :  7.2.99 (commit d571d6af of Nov. 13)
glamor :  0.5.1 (commit 71e7168d of Nov. 13)
linux  :  3.12.1 (+ some DRM from 3.13rc1)

That's when it all stopped working.  Even downgrading the X stack and Mesa (in
any combination) to the previous working versions still causes failures.  The
symptoms are that everything seems to be fine (kernel boots, X starts, you can
use the desktop, etc.) until you touch OpenGL.  Any attempt to try a game like
'torcs' (or even 'prboom-plus', which is much less GL intensive) causes X to
freeze.  It is sometimes possible to switch to a VT, but the screen goes black
in a few moments so there is nothing to see; if the system does not reboot on
its own, it is possible to use sysrq keys to shut it down somewhat sanely.

When changing everything back (except libdrm) to previous working versions
_also_ was not working, I began to suspect libdrm.  After downgrading to libdrm
2.4.48, everything was working again flawlessly; even upgrading Mesa and the X
stack continued to work perfectly, so I can once again enjoy the 1.15
performance improvements!

It took so many hours to identify libdrm 2.4.49 as the culprit -- I was
assuming that xorg-server, mesa, or glamor were at fault -- that I ran out of
time last night.  I only have to work 2 days this week, so I should be able to
bisect it in 2 days (if no developer can reproduce it by then).

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

[PATCH] present: Send GLX_BufferSwapComplete events from present extension

2013-11-25 Thread Eric Anholt

Keith Packard  writes:

> This allows GL to support the GLX_INTEL_swap_event extension
>
> Signed-off-by: Keith Packard 

There's a minor behavior change that the event now gets sent to the
drawable owner rather than the caller of DRI2SwapBuffers.

I don't expect it to matter in practice (I expect that the
swap-requesting client using this GLX extension is also the
drawable-creating one), and either choice seems wrong compared to "send
the event to everyone listening for the event on this drawable".  That
would be a separate change, anyway.

Reviewed-by: Eric Anholt 
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131125/a13a5579/attachment.pgp>

[PATCH] dri3: Support GLX_INTEL_swap_event

2013-11-25 Thread Keith Packard

Eric Anholt  writes:

> I'd prefer to see sbc stay with its current name, since that's its name
> in the specs we're trying to implement (GLX_OML_sync_control,
> GLX_INTEL_swap_event).  If you drop the rename from the patch,
>
> Reviewed-by: Eric Anholt 

Sounds good.

> I read that as "SBC is incremented when the PresentComplete comes in"
> not "SBC is incremented when we generate the Present request".
> Otherwise glXWaitForSbcOML doesn't make much sense. (in the "e.g." I'm
> assuming they're talking a hardware register for pageflipping that
> immediately starts scanning out the new stuff, not our fancy new
> automatically double buffered ones that you have to push hard on to get
> an immediate pageflip mode)

Oh, that's almost sensible. And nicely eliminates the silly sleep(1)
loop. New patches coming shortly.

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131125/f84f590a/attachment.pgp>

[Bug 71812] VDPAU: MPEG-4 ASP Garbling/Corruption

2013-11-25 Thread bugzilla-dae...@freedesktop.org

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

Christian K?nig  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #7 from Christian K?nig  ---
That's a known problem, but so far we didn't had any bugreport for it.

Thanks for filling one in.

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

[Bug 50618] Slow video playback with 40mbits mpeg2+vdpau

2013-11-25 Thread bugzilla-dae...@freedesktop.org

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

Christian K?nig  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Christian K?nig  ---
Since DPM is available for a while now I think we can close this bug.

Any objections?

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

[PATCH 4/4] drm: exynos: hdmi: Add dt support for hdmiphy settings

2013-11-25 Thread Shirish S

This patch adds dt support to hdmiphy config settings
as it is board specific and depends on the signal pattern
of board.

Signed-off-by: Shirish S 
---
 .../devicetree/bindings/video/exynos_hdmi.txt  |   31 
 drivers/gpu/drm/exynos/exynos_hdmi.c   |   77 +++-
 2 files changed, 104 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt 
b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
index 323983b..6eeb333 100644
--- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
+++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
@@ -13,6 +13,30 @@ Required properties:
b) pin number within the gpio controller.
c) optional flags and pull up/down.

+- hdmiphy-configs: following information about the hdmiphy config settings.
+   a) "config: config" specifies the phy configuration settings,
+   where 'N' denotes the number of configuration, since every
+   pixel clock can have its unique configuration.
+   "pixel-clock" specifies the pixel clock
+   "conifig-de-emphasis-level" provides fine control of TMDS data
+pre emphasis, below shown is example for
+   data de-emphasis register at address 0x145D0040.
+   hdmiphy at 38[16] for bits[3:0] permitted values are in
+   the range of 760 mVdiff to 1400 mVdiff at 20mVdiff
+   increments for every LSB
+   hdmiphy at 38[16] for bits[7:4] permitted values are in
+   the range of 0dB to -7.45dB at increments of -0.45dB
+   for every LSB.
+   "config-clock-level" provides fine control of TMDS data
+   amplitude for each channel,
+   for example if 0x145D005C is the address of clock level
+   register then,
+   hdmiphy at 38[23] for bits [1:0] permitted values are in
+   the range of 0 mVdiff & 60 mVdiff for each channel at
+   increments 20 mVdiff of amplitude levels for every LSB,
+   hdmiphy at 38[23] for bits [7:3] permitted values are in
+   the range of 790 and 1430 mV at 20mV increments for
+   every LSB.
 Example:

hdmi {
@@ -20,4 +44,11 @@ Example:
reg = <0x1453 0x10>;
interrupts = <0 95 0>;
hpd-gpio = < 7 1>;
+   hdmiphy-configs {
+   config0: config0 {
+   pixel-clock = <2520>;
+   config-de-emphasis-level =  /bits/ 8 <0x26>;
+   config-clock-level =  /bits/ 8 < 0x66>;
+   };
+   }
};
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 32ce9a6..5f599e3 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -197,6 +197,9 @@ struct hdmi_context {

struct hdmi_resources   res;

+   struct hdmiphy_config   *confs;
+   int nr_confs;
+
int hpd_gpio;

enum hdmi_type  type;
@@ -256,7 +259,7 @@ static const struct hdmiphy_config hdmiphy_v13_configs[] = {
},
 };

-static const struct hdmiphy_config hdmiphy_v14_configs[] = {
+static struct hdmiphy_config hdmiphy_v14_configs[] = {
{
.pixel_clock = 2520,
.conf = {
@@ -785,8 +788,8 @@ static int hdmi_find_phy_conf(struct hdmi_context *hdata, 
u32 pixel_clock)
confs = hdmiphy_v13_configs;
count = ARRAY_SIZE(hdmiphy_v13_configs);
} else if (hdata->type == HDMI_TYPE14) {
-   confs = hdmiphy_v14_configs;
-   count = ARRAY_SIZE(hdmiphy_v14_configs);
+   confs = hdata->confs;
+   count = hdata->nr_confs;
} else
return -EINVAL;

@@ -1415,7 +1418,7 @@ static void hdmiphy_conf_apply(struct hdmi_context *hdata)
if (hdata->type == HDMI_TYPE13)
hdmiphy_data = hdmiphy_v13_configs[i].conf;
else
-   hdmiphy_data = hdmiphy_v14_configs[i].conf;
+   hdmiphy_data = hdata->confs[i].conf;

memcpy(buffer, hdmiphy_data, 32);
ret = i2c_master_send(hdata->hdmiphy_port, buffer, 32);
@@ -1894,6 +1897,63 @@ fail:
return -ENODEV;
 }

+static int drm_hdmi_dt_parse_phy_conf(struct platform_device *pdev,
+   struct hdmi_context *hdata)
+{
+   struct device *dev = >dev;
+   struct device_node *dev_np = dev->of_node;
+   struct device_node *phy_conf, *cfg_np;
+   int i, pixel_clock = 0;
+
+   /* Initialize with default config */
+   hdata->confs =

[PATCH 3/4] ARM: exynos: dts: cros5250: Add hdmi phy settings

2013-11-25 Thread Shirish S

This patch moves the hdmi phy setting to arndale dts,
as its more of a per board configuration and also
shall be easier for supporting future chipsets.

Signed-off-by: Shirish S 
---
 arch/arm/boot/dts/cros5250-common.dtsi |   74 
 1 file changed, 74 insertions(+)

diff --git a/arch/arm/boot/dts/cros5250-common.dtsi 
b/arch/arm/boot/dts/cros5250-common.dtsi
index dc259e8b..77408c6 100644
--- a/arch/arm/boot/dts/cros5250-common.dtsi
+++ b/arch/arm/boot/dts/cros5250-common.dtsi
@@ -301,6 +301,80 @@

hdmi {
hpd-gpio = < 7 0>;
+   hdmiphy-configs {
+   /*
+   * Eye diagram test passed for:
+   * Data de-emphasis: -0.7dB & Data Level: 880mV
+   * i.e., 0010 0110 = 0x26
+   * and Clock level of 515mV and diff 1030mV
+   * i.e., 0x66
+   */
+   config0: config0 {
+   pixel-clock = <2520>;
+   config-de-emphasis-level =  /bits/ 8 <0x26>;
+   config-clock-level =  /bits/ 8 < 0x66>;
+   };
+   config1: config1 {
+   pixel-clock = <2700>;
+   config-de-emphasis-level =  /bits/ 8 <0x26>;
+   config-clock-level =  /bits/ 8 < 0x66>;
+   };
+   config2: config2 {
+   pixel-clock = <27027000>;
+   config-de-emphasis-level =  /bits/ 8 <0x26>;
+   config-clock-level =  /bits/ 8 < 0x66>;
+   };
+   config3: config3 {
+   pixel-clock = <3600>;
+   config-de-emphasis-level =  /bits/ 8 <0x26>;
+   config-clock-level =  /bits/ 8 < 0x66>;
+   };
+   config4: config4 {
+   pixel-clock = <4000>;
+   config-de-emphasis-level =  /bits/ 8 <0x26>;
+   config-clock-level =  /bits/ 8 < 0x66>;
+   };
+   config5: config5 {
+   pixel-clock = <6500>;
+   config-de-emphasis-level =  /bits/ 8 <0x26>;
+   config-clock-level =  /bits/ 8 < 0x66>;
+   };
+   config6: config6 {
+   pixel-clock = <74176000>;
+   config-de-emphasis-level =  /bits/ 8 <0x26>;
+   config-clock-level =  /bits/ 8 < 0x66>;
+   };
+   config7: config7 {
+   pixel-clock = <7425>;
+   config-de-emphasis-level =  /bits/ 8 <0x26>;
+   config-clock-level =  /bits/ 8 < 0x66>;
+   };
+   config8: config8 {
+   pixel-clock = <8350>;
+   config-de-emphasis-level =  /bits/ 8 <0x26>;
+   config-clock-level =  /bits/ 8 < 0x66>;
+   };
+   config9: config9 {
+   pixel-clock = <10650>;
+   config-de-emphasis-level =  /bits/ 8 <0x26>;
+   config-clock-level =  /bits/ 8 < 0x66>;
+   };
+   config10: config10 {
+   pixel-clock = <10800>;
+   config-de-emphasis-level =  /bits/ 8 <0x26>;
+   config-clock-level =  /bits/ 8 < 0x66>;
+   };
+   config11: config11 {
+   pixel-clock = <14625>;
+   config-de-emphasis-level =  /bits/ 8 <0x26>;
+   config-clock-level =  /bits/ 8 < 0x66>;
+   };
+   config12: config12 {
+   pixel-clock = <14850>;
+   config-de-emphasis-level =  /bits/ 8 <0x26>;
+   config-clock-level =  /bits/ 8 < 0x66>;
+   };
+   };
};

gpio-keys {
-- 
1.7.9.5

[PATCH 2/4] ARM: dts: arndale: Add hdmi phy settings

2013-11-25 Thread Shirish S

This patch moves the hdmi phy setting to arndale dts,
as its more of a per board configuration and also
shall be easier for supporting future chipsets.

Signed-off-by: Shirish S 
---
 arch/arm/boot/dts/exynos5250-arndale.dts |   74 ++
 1 file changed, 74 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts 
b/arch/arm/boot/dts/exynos5250-arndale.dts
index cee55fa..48b00f7 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -475,6 +475,80 @@
vdd_osc-supply = <_reg>;
vdd_pll-supply = <_reg>;
vdd-supply = <_reg>;
+   hdmiphy-configs {
+   /*
+   * Eye diagram test passed for:
+   * Data de-emphasis: -0.7dB & Data Level: 880mV
+   * i.e., 0010 0110 = 0x26
+   * and Clock level of 515mV and diff 1030mV
+   * i.e., 0x66
+   */
+   config0: config0 {
+   pixel-clock = <2520>;
+   config-de-emphasis-level =  /bits/ 8 <0x26>;
+   config-clock-level =  /bits/ 8 < 0x66>;
+   };
+   config1: config1 {
+   pixel-clock = <2700>;
+   config-de-emphasis-level =  /bits/ 8 <0x26>;
+   config-clock-level =  /bits/ 8 < 0x66>;
+   };
+   config2: config2 {
+   pixel-clock = <27027000>;
+   config-de-emphasis-level =  /bits/ 8 <0x26>;
+   config-clock-level =  /bits/ 8 < 0x66>;
+   };
+   config3: config3 {
+   pixel-clock = <3600>;
+   config-de-emphasis-level =  /bits/ 8 <0x26>;
+   config-clock-level =  /bits/ 8 < 0x66>;
+   };
+   config4: config4 {
+   pixel-clock = <4000>;
+   config-de-emphasis-level =  /bits/ 8 <0x26>;
+   config-clock-level =  /bits/ 8 < 0x66>;
+   };
+   config5: config5 {
+   pixel-clock = <6500>;
+   config-de-emphasis-level =  /bits/ 8 <0x26>;
+   config-clock-level =  /bits/ 8 < 0x66>;
+   };
+   config6: config6 {
+   pixel-clock = <74176000>;
+   config-de-emphasis-level =  /bits/ 8 <0x26>;
+   config-clock-level =  /bits/ 8 < 0x66>;
+   };
+   config7: config7 {
+   pixel-clock = <7425>;
+   config-de-emphasis-level =  /bits/ 8 <0x26>;
+   config-clock-level =  /bits/ 8 < 0x66>;
+   };
+   config8: config8 {
+   pixel-clock = <8350>;
+   config-de-emphasis-level =  /bits/ 8 <0x26>;
+   config-clock-level =  /bits/ 8 < 0x66>;
+   };
+   config9: config9 {
+   pixel-clock = <10650>;
+   config-de-emphasis-level =  /bits/ 8 <0x26>;
+   config-clock-level =  /bits/ 8 < 0x66>;
+   };
+   config10: config10 {
+   pixel-clock = <10800>;
+   config-de-emphasis-level =  /bits/ 8 <0x26>;
+   config-clock-level =  /bits/ 8 < 0x66>;
+   };
+   config11: config11 {
+   pixel-clock = <14625>;
+   config-de-emphasis-level =  /bits/ 8 <0x26>;
+   config-clock-level =  /bits/ 8 < 0x66>;
+   };
+   config12: config12 {
+   pixel-clock = <14850>;
+   config-de-emphasis-level =  /bits/ 8 <0x26>;
+   config-clock-level =  /bits/ 8 < 0x66>;
+   };
+   };
};

regulators {
-- 
1.7.9.5

[PATCH] drm: edid: enable probing and listing of non rb modes

2013-11-25 Thread Shirish S

The current solution checks for the existing RB mode,
if available in the edid block returns by adding it,
but does not populate the connector with the modes
of same resolution but which are non-rb modes.

As a result the probing and listing of non-rb modes can't
be made, in case the rb mode's pixel clock is not
supported but non-rb mode is supported.

This patch changes the drm_mode_std mode selection to
collect all the supported modes and not just one mode.

Signed-off-by: Shirish S 
---
 drivers/gpu/drm/drm_edid.c |   40 ++--
 1 file changed, 18 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index fb7cf0e..765aa96 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1587,12 +1587,12 @@ bad_std_timing(u8 a, u8 b)
  * Take the standard timing params (in this case width, aspect, and refresh)
  * and convert them into a real mode using CVT/GTF/DMT.
  */
-static struct drm_display_mode *
-drm_mode_std(struct drm_connector *connector, struct edid *edid,
+unsigned int drm_mode_std(struct drm_connector *connector, struct edid *edid,
 struct std_timing *t, int revision)
 {
struct drm_device *dev = connector->dev;
struct drm_display_mode *m, *mode = NULL;
+   unsigned int modes = 0;
int hsize, vsize;
int vrefresh_rate;
unsigned aspect_ratio = (t->vfreq_aspect & EDID_TIMING_ASPECT_MASK)
@@ -1602,7 +1602,7 @@ drm_mode_std(struct drm_connector *connector, struct edid 
*edid,
int timing_level = standard_timing_level(edid);

if (bad_std_timing(t->hsize, t->vfreq_aspect))
-   return NULL;
+   return modes;

/* According to the EDID spec, the hdisplay = hsize * 8 + 248 */
hsize = t->hsize * 8 + 248;
@@ -1638,7 +1638,7 @@ drm_mode_std(struct drm_connector *connector, struct edid 
*edid,
list_for_each_entry(m, >probed_modes, head)
if (m->hdisplay == hsize && m->vdisplay == vsize &&
drm_mode_vrefresh(m) == vrefresh_rate)
-   return NULL;
+   return modes;

/* HDTV hack, part 2 */
if (hsize == 1366 && vsize == 768 && vrefresh_rate == 60) {
@@ -1647,19 +1647,21 @@ drm_mode_std(struct drm_connector *connector, struct 
edid *edid,
mode->hdisplay = 1366;
mode->hsync_start = mode->hsync_start - 1;
mode->hsync_end = mode->hsync_end - 1;
-   return mode;
+   goto done;
}

/* check whether it can be found in default mode table */
if (drm_monitor_supports_rb(edid)) {
mode = drm_mode_find_dmt(dev, hsize, vsize, vrefresh_rate,
 true);
-   if (mode)
-   return mode;
+   if (mode) {
+   drm_mode_probed_add(connector, mode);
+   modes++;
+   }
}
mode = drm_mode_find_dmt(dev, hsize, vsize, vrefresh_rate, false);
if (mode)
-   return mode;
+   goto done;

/* okay, generate it */
switch (timing_level) {
@@ -1676,7 +1678,7 @@ drm_mode_std(struct drm_connector *connector, struct edid 
*edid,
 */
mode = drm_gtf_mode(dev, hsize, vsize, vrefresh_rate, 0, 0);
if (!mode)
-   return NULL;
+   return modes;
if (drm_mode_hsync(mode) > drm_gtf2_hbreak(edid)) {
drm_mode_destroy(dev, mode);
mode = drm_gtf_mode_complex(dev, hsize, vsize,
@@ -1692,7 +1694,11 @@ drm_mode_std(struct drm_connector *connector, struct 
edid *edid,
false);
break;
}
-   return mode;
+
+done:
+   drm_mode_probed_add(connector, mode);
+   return modes++;
+
 }

 /*
@@ -2174,15 +2180,10 @@ do_standard_modes(struct detailed_timing *timing, void 
*c)
int i;
for (i = 0; i < 6; i++) {
struct std_timing *std;
-   struct drm_display_mode *newmode;

std = >data.timings[i];
-   newmode = drm_mode_std(connector, edid, std,
+   closure->modes += drm_mode_std(connector, edid, std,
   edid->revision);
-   if (newmode) {
-   drm_mode_probed_add(connector, newmode);
-   closure->modes++;
-   }
}
}
 }
@@ -2203,15 +2204,10 @@ add_standard_modes(struct drm_connector *connector, 
struct edid *edid)
};

for (i = 0; i < EDID_STD_TIMINGS; i++) {
-   struct drm_display_mode *newmode;

-   newmode =

[PATCH 1/4] ARM: dts: smdk5250: Add hdmi phy settings

2013-11-25 Thread Shirish S

This patch moves the hdmi phy setting to smdk5250
dts,as its more of a per board configuration and
also shall be easier for supporting future chipsets.

Signed-off-by: Shirish S 
---
 arch/arm/boot/dts/exynos5250-smdk5250.dts |   74 +
 1 file changed, 74 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts 
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 2538b32..96e2cad 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -220,6 +220,80 @@

hdmi {
hpd-gpio = < 7 0>;
+   hdmiphy-configs {
+   /*
+   * Eye diagram test passed for:
+   * Data de-emphasis: -0.7dB & Data Level: 880mV
+   * i.e., 0010 0110 = 0x26
+   * and Clock level of 515mV and diff 1030mV
+   * i.e., 0x66
+   */
+   config0: config0 {
+   pixel-clock = <2520>;
+   config-de-emphasis-level =  /bits/ 8 <0x26>;
+   config-clock-level =  /bits/ 8 < 0x66>;
+   };
+   config1: config1 {
+   pixel-clock = <2700>;
+   config-de-emphasis-level =  /bits/ 8 <0x26>;
+   config-clock-level =  /bits/ 8 < 0x66>;
+   };
+   config2: config2 {
+   pixel-clock = <27027000>;
+   config-de-emphasis-level =  /bits/ 8 <0x26>;
+   config-clock-level =  /bits/ 8 < 0x66>;
+   };
+   config3: config3 {
+   pixel-clock = <3600>;
+   config-de-emphasis-level =  /bits/ 8 <0x26>;
+   config-clock-level =  /bits/ 8 < 0x66>;
+   };
+   config4: config4 {
+   pixel-clock = <4000>;
+   config-de-emphasis-level =  /bits/ 8 <0x26>;
+   config-clock-level =  /bits/ 8 < 0x66>;
+   };
+   config5: config5 {
+   pixel-clock = <6500>;
+   config-de-emphasis-level =  /bits/ 8 <0x26>;
+   config-clock-level =  /bits/ 8 < 0x66>;
+   };
+   config6: config6 {
+   pixel-clock = <74176000>;
+   config-de-emphasis-level =  /bits/ 8 <0x26>;
+   config-clock-level =  /bits/ 8 < 0x66>;
+   };
+   config7: config7 {
+   pixel-clock = <7425>;
+   config-de-emphasis-level =  /bits/ 8 <0x26>;
+   config-clock-level =  /bits/ 8 < 0x66>;
+   };
+   config8: config8 {
+   pixel-clock = <8350>;
+   config-de-emphasis-level =  /bits/ 8 <0x26>;
+   config-clock-level =  /bits/ 8 < 0x66>;
+   };
+   config9: config9 {
+   pixel-clock = <10650>;
+   config-de-emphasis-level =  /bits/ 8 <0x26>;
+   config-clock-level =  /bits/ 8 < 0x66>;
+   };
+   config10: config10 {
+   pixel-clock = <10800>;
+   config-de-emphasis-level =  /bits/ 8 <0x26>;
+   config-clock-level =  /bits/ 8 < 0x66>;
+   };
+   config11: config11 {
+   pixel-clock = <14625>;
+   config-de-emphasis-level =  /bits/ 8 <0x26>;
+   config-clock-level =  /bits/ 8 < 0x66>;
+   };
+   config12: config12 {
+   pixel-clock = <14850>;
+   config-de-emphasis-level =  /bits/ 8 <0x26>;
+   config-clock-level =  /bits/ 8 < 0x66>;
+   };
+   };
};

codec at 1100 {
-- 
1.7.9.5

[PATCH 0/4] Add dt support for exynos hdmiphy settings

2013-11-25 Thread Shirish S

For various revisions of a chipset if the signal pattern is changed for every
revision, then the phy setting need to be updated correspondingly by measuring
the signal.
For getting correct signals the clock level and data de-emphasis
levels needs to be adjusted.
Since only these 2 values matter,we can move the same to dt,
wherein we can have different dt files for every revision.

This is an initial patchset towards achieving the same
for exynos 5250 and can be later extended to future chipsets.

V2: replaced moving of entire phy config structure with only
required and justifiable conf registers.

V3: Incorporated Mark Rutland's comments.

V4: Rebased and included cros5250-common.dtsi.

V5: removed nr-configs feild and also the constraint
of having the exact number of configs in the dt file
as in the driver, the programmer can add only the pixel
clock that needs to be updated.

V6:
V7: removed nr-configs form the dtsi files.

Shirish S (4):
  ARM: dts: smdk5250: Add hdmi phy settings
  ARM: dts: arndale: Add hdmi phy settings
  ARM: exynos: dts: cros5250: Add hdmi phy settings
  drm: exynos: hdmi: Add dt support for hdmiphy settings

 .../devicetree/bindings/video/exynos_hdmi.txt  |   31 
 arch/arm/boot/dts/cros5250-common.dtsi |   74 +++
 arch/arm/boot/dts/exynos5250-arndale.dts   |   74 +++
 arch/arm/boot/dts/exynos5250-smdk5250.dts  |   74 +++
 drivers/gpu/drm/exynos/exynos_hdmi.c   |   77 +++-
 5 files changed, 326 insertions(+), 4 deletions(-)

-- 
1.7.9.5

[PATCH] drm: edid: enable probing and listing of non rb modes

2013-11-25 Thread Shirish S

The current solution checks for the existing RB mode,
if available in the edid block returns by adding it,
but does not populate the connector with the modes
of same resolution but which are non-rb modes.

As a result the probing and listing of non-rb modes can't
be made, in case the rb mode's pixel clock is not
supported but non-rb mode is supported.

This patch changes the drm_mode_std mode selection to
collect all the supported modes and not just one mode.

Signed-off-by: Shirish S 
---
 drivers/gpu/drm/drm_edid.c |   40 ++--
 1 file changed, 18 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index fb7cf0e..765aa96 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1587,12 +1587,12 @@ bad_std_timing(u8 a, u8 b)
  * Take the standard timing params (in this case width, aspect, and refresh)
  * and convert them into a real mode using CVT/GTF/DMT.
  */
-static struct drm_display_mode *
-drm_mode_std(struct drm_connector *connector, struct edid *edid,
+unsigned int drm_mode_std(struct drm_connector *connector, struct edid *edid,
 struct std_timing *t, int revision)
 {
struct drm_device *dev = connector->dev;
struct drm_display_mode *m, *mode = NULL;
+   unsigned int modes = 0;
int hsize, vsize;
int vrefresh_rate;
unsigned aspect_ratio = (t->vfreq_aspect & EDID_TIMING_ASPECT_MASK)
@@ -1602,7 +1602,7 @@ drm_mode_std(struct drm_connector *connector, struct edid 
*edid,
int timing_level = standard_timing_level(edid);

if (bad_std_timing(t->hsize, t->vfreq_aspect))
-   return NULL;
+   return modes;

/* According to the EDID spec, the hdisplay = hsize * 8 + 248 */
hsize = t->hsize * 8 + 248;
@@ -1638,7 +1638,7 @@ drm_mode_std(struct drm_connector *connector, struct edid 
*edid,
list_for_each_entry(m, >probed_modes, head)
if (m->hdisplay == hsize && m->vdisplay == vsize &&
drm_mode_vrefresh(m) == vrefresh_rate)
-   return NULL;
+   return modes;

/* HDTV hack, part 2 */
if (hsize == 1366 && vsize == 768 && vrefresh_rate == 60) {
@@ -1647,19 +1647,21 @@ drm_mode_std(struct drm_connector *connector, struct 
edid *edid,
mode->hdisplay = 1366;
mode->hsync_start = mode->hsync_start - 1;
mode->hsync_end = mode->hsync_end - 1;
-   return mode;
+   goto done;
}

/* check whether it can be found in default mode table */
if (drm_monitor_supports_rb(edid)) {
mode = drm_mode_find_dmt(dev, hsize, vsize, vrefresh_rate,
 true);
-   if (mode)
-   return mode;
+   if (mode) {
+   drm_mode_probed_add(connector, mode);
+   modes++;
+   }
}
mode = drm_mode_find_dmt(dev, hsize, vsize, vrefresh_rate, false);
if (mode)
-   return mode;
+   goto done;

/* okay, generate it */
switch (timing_level) {
@@ -1676,7 +1678,7 @@ drm_mode_std(struct drm_connector *connector, struct edid 
*edid,
 */
mode = drm_gtf_mode(dev, hsize, vsize, vrefresh_rate, 0, 0);
if (!mode)
-   return NULL;
+   return modes;
if (drm_mode_hsync(mode) > drm_gtf2_hbreak(edid)) {
drm_mode_destroy(dev, mode);
mode = drm_gtf_mode_complex(dev, hsize, vsize,
@@ -1692,7 +1694,11 @@ drm_mode_std(struct drm_connector *connector, struct 
edid *edid,
false);
break;
}
-   return mode;
+
+done:
+   drm_mode_probed_add(connector, mode);
+   return modes++;
+
 }

 /*
@@ -2174,15 +2180,10 @@ do_standard_modes(struct detailed_timing *timing, void 
*c)
int i;
for (i = 0; i < 6; i++) {
struct std_timing *std;
-   struct drm_display_mode *newmode;

std = >data.timings[i];
-   newmode = drm_mode_std(connector, edid, std,
+   closure->modes += drm_mode_std(connector, edid, std,
   edid->revision);
-   if (newmode) {
-   drm_mode_probed_add(connector, newmode);
-   closure->modes++;
-   }
}
}
 }
@@ -2203,15 +2204,10 @@ add_standard_modes(struct drm_connector *connector, 
struct edid *edid)
};

for (i = 0; i < EDID_STD_TIMINGS; i++) {
-   struct drm_display_mode *newmode;

-   newmode =

[PATCH] Enable probing of non-rb modes

2013-11-25 Thread Shirish S

With the current implementation of collecting edid modes,
in case rb mode exists for a non rb mode of same resolution and
vrefresh, the non-rb mode is never fed to display controller to be
probed, as a result we lose on using the non-rb mode, if the display
controller does not support rb mode but supports non-rb.


For instance in case of 1680x1050 at 60Hz:
with monitor whose EDID supports RB,
if connected to  display controller does not support 1680x1050 at 60Hz RB but it
supports 1680x1050 at 60Hz, with the current implementation the non-rb mode
1680x1050 at 60Hz is not listed in connectors probed modes and hence on running
xrandr is not listed.

V2: Incorporate review comments by Adam Jackson
remove suffix of 'rb'

Shirish S (1):
  drm: edid: enable probing and listing of non rb modes

 drivers/gpu/drm/drm_edid.c |   40 ++--
 1 file changed, 18 insertions(+), 22 deletions(-)

-- 
1.7.9.5

[Mesa-dev] [PATCH] dri3, i915, i965: Add __DRI_IMAGE_FOURCC_SARGB8888

2013-11-25 Thread Eric Anholt

Keith Packard  writes:

> The __DRIimage createImageFromFds function takes a fourcc code, but there was
> no fourcc code that match __DRI_IMAGE_FORMAT_SARGB8. This adds a define for
> that format, adds a translation in DRI3 from __DRI_IMAGE_FORMAT_SARGB8 to
> __DRI_IMAGE_FOURCC_SARGB and then adds translations *back* to
> __IMAGE_FORMAT_SARGB8 in both the i915 and i965 drivers.
>
> I'll refrain from comments on whether I think having two separate sets of
> format defines in dri_interface.h is a good idea or not...
>
> Signed-off-by: Keith Packard 

Reviewed-by: Eric Anholt 

I'd love to see some debug information in whatever path it was that was
silently failing, if we can.  It's so easy to miss places to add format
support.  (I see gallium doesn't use sargb images currently, but might
want this in the future, plus we're still missing an equivalent change
for 2101010 though I don't know if anybody's made it really work
anywhere on dri2 either)
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131125/cee0c182/attachment.pgp>

[Bug 71983] libdrm 2.4.49 makes gpu crash (HD7770)

2013-11-25 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #4 from Arek Ru?niak  ---
yep:) 
if i good understand word "bisect" here it is:

http://cgit.freedesktop.org/mesa/drm/commit/?id=ce8af454259279c14c44bcd32c429640ca5e1691

btw i try turn off tiling but without succes, gpu still crashes. Before this
commit it works ok.

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

[Bug 71983] libdrm 2.4.49 makes gpu crash (HD7770)

2013-11-25 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #3 from Marek Ol??k  ---
Could you bisect?

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

[PATCH] dri3: Support GLX_INTEL_swap_event

2013-11-25 Thread Eric Anholt

Keith Packard  writes:

> The easy part is turning on the extension, now that the X server has a patch
> to send the events.
>
> The only trick was making sure the Present extension reliably provided the
> right 'sbc' count back in the event, and that's done by making sure the sbc
> count is always the same as the sequence number that we send in the
> PresentPixmap requests, and that's done by using the same variable for both
> roles.

I'd prefer to see sbc stay with its current name, since that's its name
in the specs we're trying to implement (GLX_OML_sync_control,
GLX_INTEL_swap_event).  If you drop the rename from the patch,

Reviewed-by: Eric Anholt 

I think our handling of SBC for glXWaitForSbcOML() is wrong.  From the
OML_sync_control spec:

The SBC value is incremented by the graphics driver at the completion
of each buffer swap (e.g., the pixel copy has been completed or the
hardware register that swaps memory banks has been written). For pixel
formats that do not contain a back buffer, the SBC will always be
returned as 0.

I read that as "SBC is incremented when the PresentComplete comes in"
not "SBC is incremented when we generate the Present request".
Otherwise glXWaitForSbcOML doesn't make much sense. (in the "e.g." I'm
assuming they're talking a hardware register for pageflipping that
immediately starts scanning out the new stuff, not our fancy new
automatically double buffered ones that you have to push hard on to get
an immediate pageflip mode)
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131125/f253d181/attachment.pgp>

[PATCH 3.2 74/87] drm: Prevent overwriting from userspace underallocating core ioctl structs

2013-11-25 Thread Ben Hutchings

3.2.53-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Chris Wilson 

commit b062672e305ce071f21eb9e18b102c2a430e0999 upstream.

Apply the protections from

commit 1b2f1489633888d4a06028315dc19d65768a1c05
Author: Dave Airlie 
Date:   Sat Aug 14 20:20:34 2010 +1000

drm: block userspace under allocating buffer and having drivers overwrite 
it (v2)

to the core ioctl structs as well, for we found one instance where there
is a 32-/64-bit size mismatch and were guilty of writing beyond the end
of the user's buffer.

Signed-off-by: Chris Wilson 
Cc: Dave Airlie 
Reviewed-by: Ville Syrj?l? 
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Dave Airlie 
Signed-off-by: Ben Hutchings 
---
 drivers/gpu/drm/drm_drv.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -408,9 +408,16 @@ long drm_ioctl(struct file *filp,
asize = drv_size;
}
else if ((nr >= DRM_COMMAND_END) || (nr < DRM_COMMAND_BASE)) {
+   u32 drv_size;
+
ioctl = _ioctls[nr];
-   cmd = ioctl->cmd;
+
+   drv_size = _IOC_SIZE(ioctl->cmd);
usize = asize = _IOC_SIZE(cmd);
+   if (drv_size > asize)
+   asize = drv_size;
+
+   cmd = ioctl->cmd;
} else
goto err_i1;

[RFC patch] PCI: Extend boot_vga sysfs attribute lookup to fix X on MBA+EFI

2013-11-25 Thread Bjorn Helgaas

On Mon, Nov 25, 2013 at 12:54 PM, Bruno Pr?mont
 wrote:
> On a MacBookAir2,1, booting to Linux with EFI though having
> no efifb built-in Xorg refuses to start with "no devices detected"
> because for the only VGA device available (NVidia Geforce 9400M)
> the sysfs attribute boot_vga is zero (instead of expected 1).
>
> When CONFIG_FB_EFI is selected, efifb does provide its own
> vga_default_device() to report the PCI device matching global
> screen_info as determined during efifb setup.
>
> Otherwise there is just a dummy or VGA_ARB's vga_default_device()
> that does not provide the right information.

Wouldn't it be cleaner to fix vga_default_device() so it returns the
correct thing even when CONFIG_FB_EFI=n?

> On the other hand, boot_vga_show() falls back to poking PCI
> resources to flag a PCI device as boot_vga if vga_default_device()
> returned no PCI device (NULL).
>
> To complement this PCI resource poking, this patch copies the
> validation code used to determine which PCI device to report as
> default VGA device by efifb into boot_vga_show().

If we do have to use logic like this, I'd like it better if it were
factored into a single function called both here and from
efifb_setup().

> Signed-off-by: Bruno Pr?mont 
> ---
> Would it make sense to kill the corresponding code from efifb
> as it covers only a single case?
>
> The other EFI capable system I have (AMD Ilano based, Gigabyte
> mainboard does report boot_vga=1, possibly through the resources
> poking and there Xorg starts properly without efifb built in.
>
> Selecting CONFIG_X86_SYSFB (combined with CONFIG_FB_SIMPLE) does
> not help by itself, patching that one instead of PCI's boot_vga
> attribute directly would still not cover the case when neither
> of them is enabled.
>
>
>  drivers/pci/pci-sysfs.c | 21 +
>  1 file changed, 21 insertions(+)
>
> diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
> index 7128cfd..91cac71 100644
> --- a/drivers/pci/pci-sysfs.c
> +++ b/drivers/pci/pci-sysfs.c
> @@ -28,6 +28,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include "pci.h"
>
> @@ -540,6 +541,26 @@ boot_vga_show(struct device *dev, struct 
> device_attribute *attr, char *buf)
> if (vga_dev)
> return sprintf(buf, "%u\n", (pdev == vga_dev));
>
> +   if ((pdev->class >> 8) == PCI_CLASS_DISPLAY_VGA) {
> +   resource_size_t start, end;
> +   int i;
> +
> +   for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
> +   if (!(pci_resource_flags(pdev, i) & IORESOURCE_MEM))
> +   continue;
> +
> +   start = pci_resource_start(pdev, i);
> +   end  = pci_resource_end(pdev, i);
> +
> +   if (!start || !end)
> +   continue;
> +
> +   if (screen_info.lfb_base >= start &&
> +   (screen_info.lfb_base + screen_info.lfb_size) 
> < end)
> +   return sprintf(buf, "1\n");
> +   }
> +   }
> +
> return sprintf(buf, "%u\n",
> !!(pdev->resource[PCI_ROM_RESOURCE].flags &
>IORESOURCE_ROM_SHADOW));

[PATCH] intel: Track known prime buffers for re-use

2013-11-25 Thread Keith Packard

If the application sends us a file descriptor pointing at a prime
buffer that we've already got, we have to re-use the same bo_gem
structure or chaos will result.

Track the set of all known prime objects and look to see if the kernel
has returned one of those for a new file descriptor.

Also checks for prime buffers in the flink case.

Signed-off-by: Keith Packard 
---
 intel/intel_bufmgr_gem.c | 50 +---
 1 file changed, 43 insertions(+), 7 deletions(-)

diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index df6fcec..2b7fe07 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -149,6 +149,8 @@ struct _drm_intel_bo_gem {

/**
 * Kenel-assigned global name for this object
+ *
+ * List contains both flink named and prime fd'd objects
 */
unsigned int global_name;
drmMMListHead name_list;
@@ -862,10 +864,6 @@ drm_intel_bo_gem_create_from_name(drm_intel_bufmgr *bufmgr,
}
}

-   bo_gem = calloc(1, sizeof(*bo_gem));
-   if (!bo_gem)
-   return NULL;
-
VG_CLEAR(open_arg);
open_arg.name = handle;
ret = drmIoctl(bufmgr_gem->fd,
@@ -874,9 +872,26 @@ drm_intel_bo_gem_create_from_name(drm_intel_bufmgr *bufmgr,
if (ret != 0) {
DBG("Couldn't reference %s handle 0x%08x: %s\n",
name, handle, strerror(errno));
-   free(bo_gem);
return NULL;
}
+/* Now see if someone has used a prime handle to get this
+ * object from the kernel before by looking through the list
+ * again for a matching gem_handle
+ */
+   for (list = bufmgr_gem->named.next;
+list != _gem->named;
+list = list->next) {
+   bo_gem = DRMLISTENTRY(drm_intel_bo_gem, list, name_list);
+   if (bo_gem->gem_handle == open_arg.handle) {
+   drm_intel_gem_bo_reference(_gem->bo);
+   return _gem->bo;
+   }
+   }
+
+   bo_gem = calloc(1, sizeof(*bo_gem));
+   if (!bo_gem)
+   return NULL;
+
bo_gem->bo.size = open_arg.size;
bo_gem->bo.offset = 0;
bo_gem->bo.virtual = NULL;
@@ -2451,8 +2466,25 @@ drm_intel_bo_gem_create_from_prime(drm_intel_bufmgr 
*bufmgr, int prime_fd, int s
uint32_t handle;
drm_intel_bo_gem *bo_gem;
struct drm_i915_gem_get_tiling get_tiling;
+   drmMMListHead *list;

ret = drmPrimeFDToHandle(bufmgr_gem->fd, prime_fd, );
+
+   /*
+* See if the kernel has already returned this buffer to us. Just as
+* for named buffers, we must not create two bo's pointing at the same
+* kernel object
+*/
+   for (list = bufmgr_gem->named.next;
+list != _gem->named;
+list = list->next) {
+   bo_gem = DRMLISTENTRY(drm_intel_bo_gem, list, name_list);
+   if (bo_gem->gem_handle == handle) {
+   drm_intel_gem_bo_reference(_gem->bo);
+   return _gem->bo;
+   }
+   }
+
if (ret) {
  fprintf(stderr,"ret is %d %d\n", ret, errno);
return NULL;
@@ -2487,8 +2519,8 @@ drm_intel_bo_gem_create_from_prime(drm_intel_bufmgr 
*bufmgr, int prime_fd, int s
bo_gem->has_error = false;
bo_gem->reusable = false;

-   DRMINITLISTHEAD(_gem->name_list);
DRMINITLISTHEAD(_gem->vma_list);
+   DRMLISTADDTAIL(_gem->name_list, _gem->named);

VG_CLEAR(get_tiling);
get_tiling.handle = bo_gem->gem_handle;
@@ -2513,6 +2545,9 @@ drm_intel_bo_gem_export_to_prime(drm_intel_bo *bo, int 
*prime_fd)
drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *) bo->bufmgr;
drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *) bo;

+if (DRMLISTEMPTY(_gem->name_list))
+DRMLISTADDTAIL(_gem->name_list, _gem->named);
+
if (drmPrimeHandleToFD(bufmgr_gem->fd, bo_gem->gem_handle,
   DRM_CLOEXEC, prime_fd) != 0)
return -errno;
@@ -2542,7 +2577,8 @@ drm_intel_gem_bo_flink(drm_intel_bo *bo, uint32_t * name)
bo_gem->global_name = flink.name;
bo_gem->reusable = false;

-   DRMLISTADDTAIL(_gem->name_list, _gem->named);
+if (DRMLISTEMPTY(_gem->name_list))
+DRMLISTADDTAIL(_gem->name_list, _gem->named);
}

*name = bo_gem->global_name;
-- 
1.8.4.4

[Mesa-dev] [PATCH] intel: Track known prime buffers for re-use

2013-11-25 Thread Keith Packard

Daniel Vetter  writes:

> Yeah, it unfortunately took a few rounds of kernel fixes and other
> haggling to get the semantics right on this one. The kernel atm promises
> to userspace (minus one big in a racy corner case no one should care
> about, still need to fix that one) that it'll return the same gem handle
> if userspace already has one for the underlying object.

That's definitely something we want it to do -- returning different
handles to the same object would result in madness. We just need to deal with 
the
userspace consequences.

> We need that to make sure userspace doesn't submit the same bo in execbuf
> multiple times and then upsets the kernel - we'll reject such batches as
> userspace bugs.

Oh, I'm well aware of that; you can imagine the adventures I had trying
to debug this...

>> -DRMINITLISTHEAD(_gem->name_list);
>>  DRMINITLISTHEAD(_gem->vma_list);
>> +DRMLISTADDTAIL(_gem->name_list, _gem->prime);
>
> Won't this result in us having fun when a buffer is both imported from a
> prime buffer and then also used with legacy flink? Or is this something
> the X server won't support?

Well, the whole point of prime-based FD buffer passing is to *not* use
flink, of course. However, you could use both DRI2 and DRI3 on
the same pixmap (presumably through different APIs).

Ok, I just tried to create a completely separate prime list for this,
and I think that's wrong. If the question is whether the kernel might
return the same object from two calls, then we'd best actually keep a
single list and look things up for both APIs there. *and*, I think we
need to do the flink->gem handle conversion and then look in the list
again to see if that gem handle was already returned from another flink
or prime fd.

> The second one is about exporting: With flink names we also add the name
> to the lookup list in drm_intel_gem_bo_flink. I think we should do the
> same for exported prime buffers just as a precaution - the kernel will
> return the (existing) gem name also for a prime buffer that has been
> exported by yourself. I guess that would imply insane userspace, but
> better safe than sorry.

yeah, that would seem like crazy user-space behaviour, but user space
often seems insane.

Thanks for your review; replacement patch to follow shortly.

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131125/8da762d1/attachment.pgp>

[Bug 71923] Screen corruption when watching VDPAU-accelerated H264 video

2013-11-25 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #6 from Christian K?nig  ---
I can't reproduce the problem. Can you try this with mesa master branch?

Thanks in advance.

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

[Bug 71983] libdrm 2.4.49 makes gpu crash (HD7770)

2013-11-25 Thread bugzilla-dae...@freedesktop.org

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

Maarten Lankhorst  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

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

[Bug 71983] libdrm 2.4.49 makes gpu crash (HD7770)

2013-11-25 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #2 from Maarten Lankhorst  ---
Can you bisect?

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

[Bug 71983] libdrm 2.4.49 makes gpu crash (HD7770)

2013-11-25 Thread bugzilla-dae...@freedesktop.org

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

Arek Ru?niak  changed:

   What|Removed |Added

  Attachment #89740|0   |1
is obsolete||

--- Comment #1 from Arek Ru?niak  ---
Created attachment 89745
  --> https://bugs.freedesktop.org/attachment.cgi?id=89745=edit
kernel log when i run some ogl apps (unigine-*;some 3d games; even
google-chrome)

my software/hardware:
archlinux x86/x86_64
LIBDRM 2.4.49 / 2.4.48

linux 3.13rc1 / 3.12.1
mesa 10.1 git-e6a0eca
LLVM 3.5 r195632
glamor - latest from git repo
xf86-video-ati - latest form git repo
xorg-server 1.14.4

GPU HD7770 GHz Ed. Chipset: "VERDE" (ChipID = 0x683d)


I am wild and woolly today, sorry for that.

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

[PATCH 3.5 14/78] drm: Pad drm_mode_get_connector to 64-bit boundary

2013-11-25 Thread Luis Henriques

3.5.7.26 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Chris Wilson 

commit bc5bd37ce48c66e9192ad2e7231e9678880f6f8e upstream.

Pavel Roskin reported that DRM_IOCTL_MODE_GETCONNECTOR was overwritting
the 4 bytes beyond the end of its structure with a 32-bit userspace
running on a 64-bit kernel. This is due to the padding gcc inserts as
the drm_mode_get_connector struct includes a u64 and its size is not a
natural multiple of u64s.

64-bit kernel:

sizeof(drm_mode_get_connector)=80, alignof=8
sizeof(drm_mode_get_encoder)=20, alignof=4
sizeof(drm_mode_modeinfo)=68, alignof=4

32-bit userspace:

sizeof(drm_mode_get_connector)=76, alignof=4
sizeof(drm_mode_get_encoder)=20, alignof=4
sizeof(drm_mode_modeinfo)=68, alignof=4

Fortuituously we can insert explicit padding to the tail of our
structures without breaking ABI.

Reported-by: Pavel Roskin 
Signed-off-by: Chris Wilson 
Cc: Dave Airlie 
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Dave Airlie 
[ luis: backported to 3.5:
  - file rename: include/uapi/drm/drm_mode.h -> include/drm/drm_mode.h ]
Signed-off-by: Luis Henriques 
---
 include/drm/drm_mode.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index 3d6301b..f604a1a 100644
--- a/include/drm/drm_mode.h
+++ b/include/drm/drm_mode.h
@@ -223,6 +223,8 @@ struct drm_mode_get_connector {
__u32 connection;
__u32 mm_width, mm_height; /**< HxW in millimeters */
__u32 subpixel;
+
+   __u32 pad;
 };

 #define DRM_MODE_PROP_PENDING  (1<<0)
-- 
1.8.3.2

[PATCH 3.5 13/78] drm: Prevent overwriting from userspace underallocating core ioctl structs

2013-11-25 Thread Luis Henriques

3.5.7.26 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Chris Wilson 

commit b062672e305ce071f21eb9e18b102c2a430e0999 upstream.

Apply the protections from

commit 1b2f1489633888d4a06028315dc19d65768a1c05
Author: Dave Airlie 
Date:   Sat Aug 14 20:20:34 2010 +1000

drm: block userspace under allocating buffer and having drivers overwrite 
it (v2)

to the core ioctl structs as well, for we found one instance where there
is a 32-/64-bit size mismatch and were guilty of writing beyond the end
of the user's buffer.

Signed-off-by: Chris Wilson 
Cc: Dave Airlie 
Reviewed-by: Ville Syrj?l? 
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Dave Airlie 
[ luis: backported to 3.5: adjusted context ]
Signed-off-by: Luis Henriques 
---
 drivers/gpu/drm/drm_drv.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 8a9d079..df54da9 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -422,9 +422,16 @@ long drm_ioctl(struct file *filp,
asize = drv_size;
}
else if ((nr >= DRM_COMMAND_END) || (nr < DRM_COMMAND_BASE)) {
+   u32 drv_size;
+
ioctl = _ioctls[nr];
-   cmd = ioctl->cmd;
+
+   drv_size = _IOC_SIZE(ioctl->cmd);
usize = asize = _IOC_SIZE(cmd);
+   if (drv_size > asize)
+   asize = drv_size;
+
+   cmd = ioctl->cmd;
} else
goto err_i1;

-- 
1.8.3.2

[Bug 41375] VDPAU not working on RS880

2013-11-25 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #7 from Mike Lothian  ---
I'll test it when I get home tonight. I take it its software vdpau. Is it
only mpeg2 that's implemented?
On 25 Nov 2013 12:49,  wrote:

>  Christian K?nig  changed bug 
> 41375<https://bugs.freedesktop.org/show_bug.cgi?id=41375>
>  What Removed Added  Status NEW RESOLVED  Resolution --- WORKSFORME
>
>  *Comment # 6 <https://bugs.freedesktop.org/show_bug.cgi?id=41375#c6> on
> bug 41375 <https://bugs.freedesktop.org/show_bug.cgi?id=41375> from
> Christian K?nig  *
>
> I just tested in on an RS880 and it works fine.
>
> Any objections on closing this bug?
>
>  --
> You are receiving this mail because:
>
>- You are the assignee for the bug.
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>

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

[Bug 41375] VDPAU not working on RS880

2013-11-25 Thread bugzilla-dae...@freedesktop.org

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

Christian K?nig  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #6 from Christian K?nig  ---
I just tested in on an RS880 and it works fine.

Any objections on closing this bug?

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

[Mesa-dev] [PATCH 2/2] i965: Set fast color clear mcs_state on newly allocated image miptrees

2013-11-25 Thread Eric Anholt

Keith Packard  writes:

> Just copying code from the dri2 path to set up the fast color clear state.
>
> This also removes a couple of bogus intel_region_reference calls.

These two are:

Reviewed-by: Eric Anholt 
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131125/ea340f31/attachment.pgp>

[Bug 71983] New: libdrm 2.4.49 makes gpu crash (HD7770)

2013-11-25 Thread bugzilla-dae...@freedesktop.org

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

  Priority: medium
Bug ID: 71983
  Assignee: dri-devel at lists.freedesktop.org
   Summary: libdrm 2.4.49 makes gpu crash (HD7770)
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: arek.rusi at gmail.com
  Hardware: Other
Status: NEW
   Version: git
 Component: Drivers/Gallium/radeonsi
   Product: Mesa

Created attachment 89740
  --> https://bugs.freedesktop.org/attachment.cgi?id=89740=edit
kernel log when i run some ogl apps (unigine-*;some 3d games; even
google-chrome)

I've gzipped log because it has ~ 14MB. 

main part are bazillion lines like that:
<3>[  414.876442] radeon :01:00.0: GPU fault detected: 146 0x0fe32004
<3>[  414.876446] radeon :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x21FF
<3>[  414.876448] radeon :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x03020004
<4>[  414.876450] VM fault (0x04, vmid 1) at page 8703, write from CB (32)
<3>[  414.876455] radeon :01:00.0: GPU fault detected: 146 0x0fc32004
<3>[  414.876457] radeon :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x
<3>[  414.876458] radeon :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x
<4>[  414.876460] VM fault (0x00, vmid 0) at page 0, read from unknown (0)

Usually my PC doesn't respone but sometimes like for unigine-sanctuary i can
see graphics corruption for a while. When i downgrade libdrm everything works
like before.

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

[Bug 71777] R600 stuck while compiling shader for Unigine Heaven 3.0

2013-11-25 Thread bugzilla-dae...@freedesktop.org

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

Marc Dietrich  changed:

   What|Removed |Added

  Attachment #89455|0   |1
is obsolete||

--- Comment #2 from Marc Dietrich  ---
Created attachment 89739
  --> https://bugs.freedesktop.org/attachment.cgi?id=89739=edit
failing shader in Unigine Heaven 3.0

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

[PATCH] drm/radeon: Disable writeback by default on ppc

2013-11-25 Thread Benjamin Herrenschmidt

On Fri, 2013-11-08 at 11:43 -0200, Kleber Sacilotto de Souza wrote:
> On 11/07/2013 08:29 PM, Benjamin Herrenschmidt wrote:
> > On Mon, 2013-06-17 at 18:57 -0400, Alex Deucher wrote:
> >
> >> Weird.  I wonder if there is an issue with cache snoops on PPC.  We
> >> currently use the gart in cached mode (GPU snoops CPU cache) with
> >> cached pages.  I wonder if we need to use uncached pages on PPC.
> >
> > There is no such issue and no known bugs with DMA writes on those
> > PCIe host bridges (and they do get hammered pretty bad here).
> >
> > This needs further investigation by the lab/hw guys to find out what's
> > actually happening on the bus and the host bridge.
> >
> > Thadeu, Kleber: Jerome suggested writing a test case in userspace that
> > continuously writes to a spare scratch register (thus triggering the
> > corresponding writeback DMA) and checks the memory location to compare
> > the writeback value (using a debugfs file for example, or mmap).
> >
> 
> I can look into that.

Any news ?

Ben.

> 
> Thanks,
> 
> Kleber
> 
> > Can you guys do something like that ? Then we need the analyzer on
> > and/or the lab guys to look at the fabric trace & PHB trace.
> >
> > Ben.
> >
> >
> 
>

[PATCH 1/2] drm/radeon/dpm: Convert to use devm_hwmon_register_with_groups

2013-11-25 Thread Guenter Roeck

On Fri, Nov 22, 2013 at 09:52:00PM -0800, Guenter Roeck wrote:
> Simplify the code and fix race condition seen because
> attribute files were created after hwmon device registration.
> 
> Signed-off-by: Guenter Roeck 
> ---
> Compile tested only; unfortunately I don't have the the necessary hardware.
> 
Update: Tested working on actual hardware.

Guenter

Patch

2013-11-25 Thread Daniel Vetter

On Fri, Nov 22, 2013 at 06:36:48PM +0100, Levente Kurusa wrote:
> 2013-11-22 17:35, Arthur Schwalbenberg:
> > 
> > From 340fa01dfe8f699e27ece111996ea088bca6b5c4 Mon Sep 17 00:00:00 2001
> > From: Arthur Schwalbenberg 
> > Date: Thu, 21 Nov 2013 19:42:44 -0500
> > Subject: [PATCH] Staging: Fixed compilar warnings and coding style
> > issues in i915_debugfs.c
> > MIME-Version: 1.0
> > Content-Type: text/plain; charset=UTF-8
> > Content-Transfer-Encoding: 8bit
> > 
> > This is a patch fixing both a compilar warning:
> > ?val? may be used uninitialized in this function
> > and various coding style issues which include line length
> > warnings and a few errors as defined by 'checkpatch.pl' tool
> > 
> > Signed-off-by: Arthur Schwalbenberg 
> 
> Hi,
> 
> When you break 80+ lines into two lines, you should also
> indent the newly created line so that it shows that it is a part of something.
> I as well don't think it is worth splitting lines that are 84 characters long 
> into
> two lines, that just doesn't make sense.
> 
> Also, your patch seems (atleast to me) a 'bit' whitespace damaged.

Also, please don't smash different changes into the same patch. Especially
pure whitespace changes _must_ be separate from actual code changes.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Intel-gfx] [Mesa-dev] [PATCH] dri3, i915, i965: Add __DRI_IMAGE_FOURCC_SARGB8888

2013-11-25 Thread Daniel Vetter

On Fri, Nov 22, 2013 at 02:12:13PM -0800, Kristian H?gsberg wrote:
> I don't know what else you'd propose?  Pass an X visual in the ioctl?
> An EGL config?  This is our name space, we can add stuff as we need
> (as Keith is doing here). include/uapi/drm/drm_fourcc.h is the
> canonical source for these values and we should add
> DRM_FORMAT_SARGB there to make sure we don't clash.

Well that's kinda the problem. If you don't expect the kernel to clash
with whatever mesa is using internally then we should add it to the
kernel, first. That's kinda what Dave's recent rant has all been about.

The other issue was that originally the idea behind fourcc was to have one
formate namespace shared between drm, v4l and whomever else cares. If
people are happy to drop that idea on the floor I won't shed a single
tear.

In the end I'll expect that someone will make a funny collision between
all the different projects anyway, so meh.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[RFCv4 14/14] HACK: drm: allow FB's in drm_mode_object_find

2013-11-25 Thread Rob Clark

Ugg.. we do actually want to permit FB's in atomic case, since FB will
be looked up like any other object property value.

Currently we do the FB refcnt'ing dance in atomic->commit(), and would
rather not have to special case FB's or collect an FB ref when we look
up the property.  Not sure if it is better to rework the atomic FB
refcnt'ing or loosen this restriction?
---
 drivers/gpu/drm/drm_crtc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 8158250..e57b7eb 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -441,7 +441,7 @@ struct drm_mode_object *drm_mode_object_find(struct 
drm_device *dev,

/* Framebuffers are reference counted and need their own lookup
 * function.*/
-   WARN_ON(type == DRM_MODE_OBJECT_FB);
+// WARN_ON(type == DRM_MODE_OBJECT_FB);

mutex_lock(>mode_config.idr_mutex);
obj = idr_find(>mode_config.crtc_idr, id);
-- 
1.8.4.2

[RFCv4 13/14] drm/msm: add atomic support

2013-11-25 Thread Rob Clark

TODO: probably can split this up into prep patch which splits the
msm_queue_fence_cb out of gem..
---
 drivers/gpu/drm/msm/Makefile |   1 +
 drivers/gpu/drm/msm/mdp4/mdp4_crtc.c |  57 ++
 drivers/gpu/drm/msm/mdp4/mdp4_kms.c  |   6 ++
 drivers/gpu/drm/msm/mdp4/mdp4_kms.h  |   1 +
 drivers/gpu/drm/msm/msm_atomic.c | 149 +++
 drivers/gpu/drm/msm/msm_drv.c|  22 +-
 drivers/gpu/drm/msm/msm_drv.h|   8 ++
 drivers/gpu/drm/msm/msm_gem.c|  24 +-
 drivers/gpu/drm/msm/msm_gem.h|  13 +++
 9 files changed, 228 insertions(+), 53 deletions(-)
 create mode 100644 drivers/gpu/drm/msm/msm_atomic.c

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index e5fa12b..f7648d1 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -18,6 +18,7 @@ msm-y := \
mdp4/mdp4_irq.o \
mdp4/mdp4_kms.o \
mdp4/mdp4_plane.o \
+   msm_atomic.o \
msm_drv.o \
msm_fb.o \
msm_gem.o \
diff --git a/drivers/gpu/drm/msm/mdp4/mdp4_crtc.c 
b/drivers/gpu/drm/msm/mdp4/mdp4_crtc.c
index 650c147..4f6bce3 100644
--- a/drivers/gpu/drm/msm/mdp4/mdp4_crtc.c
+++ b/drivers/gpu/drm/msm/mdp4/mdp4_crtc.c
@@ -51,7 +51,6 @@ struct mdp4_crtc {

/* if there is a pending flip, these will be non-null: */
struct drm_pending_vblank_event *event;
-   struct msm_fence_cb pageflip_cb;

 #define PENDING_CURSOR 0x1
 #define PENDING_FLIP   0x2
@@ -120,12 +119,16 @@ static void complete_flip(struct drm_crtc *crtc, struct 
drm_file *file)
spin_unlock_irqrestore(>event_lock, flags);
 }

-static void crtc_flush(struct drm_crtc *crtc)
+void mdp4_crtc_flush(struct drm_crtc *crtc)
 {
+   struct msm_drm_private *priv = crtc->dev->dev_private;
struct mdp4_crtc *mdp4_crtc = to_mdp4_crtc(crtc);
struct mdp4_kms *mdp4_kms = get_kms(crtc);
uint32_t i, flush = 0;

+   if (priv->pending_crtcs & (1 << crtc->id))
+   return;
+
for (i = 0; i < ARRAY_SIZE(mdp4_crtc->planes); i++) {
struct drm_plane *plane = mdp4_crtc->planes[i];
if (plane) {
@@ -148,23 +151,6 @@ static void request_pending(struct drm_crtc *crtc, 
uint32_t pending)
mdp4_irq_register(get_kms(crtc), _crtc->vblank);
 }

-static void pageflip_cb(struct msm_fence_cb *cb)
-{
-   struct mdp4_crtc *mdp4_crtc =
-   container_of(cb, struct mdp4_crtc, pageflip_cb);
-   struct drm_crtc *crtc = _crtc->base;
-   struct drm_framebuffer *fb = crtc->fb;
-
-   if (!fb)
-   return;
-
-   mdp4_plane_set_scanout(mdp4_crtc->plane, fb);
-   crtc_flush(crtc);
-
-   /* enable vblank to complete flip: */
-   request_pending(crtc, PENDING_FLIP);
-}
-
 static void unref_fb_worker(struct drm_flip_work *work, void *val)
 {
struct mdp4_crtc *mdp4_crtc =
@@ -374,7 +360,7 @@ static void mdp4_crtc_prepare(struct drm_crtc *crtc)
 static void mdp4_crtc_commit(struct drm_crtc *crtc)
 {
mdp4_crtc_dpms(crtc, DRM_MODE_DPMS_ON);
-   crtc_flush(crtc);
+   mdp4_crtc_flush(crtc);
/* drop the ref to mdp clk's that we got in prepare: */
mdp4_disable(get_kms(crtc));
 }
@@ -405,23 +391,27 @@ static int mdp4_crtc_page_flip(struct drm_crtc *crtc,
 {
struct mdp4_crtc *mdp4_crtc = to_mdp4_crtc(crtc);
struct drm_device *dev = crtc->dev;
-   struct drm_gem_object *obj;
unsigned long flags;

+   spin_lock_irqsave(>event_lock, flags);
if (mdp4_crtc->event) {
+   spin_unlock_irqrestore(>event_lock, flags);
dev_err(dev->dev, "already pending flip!\n");
return -EBUSY;
}

-   obj = msm_framebuffer_bo(new_fb, 0);
-
-   spin_lock_irqsave(>event_lock, flags);
mdp4_crtc->event = event;
spin_unlock_irqrestore(>event_lock, flags);

update_fb(crtc, true, new_fb);

-   return msm_gem_queue_inactive_cb(obj, _crtc->pageflip_cb);
+   mdp4_plane_set_scanout(mdp4_crtc->plane, crtc->fb);
+   mdp4_crtc_flush(crtc);
+
+   /* enable vblank to complete flip: */
+   request_pending(crtc, PENDING_FLIP);
+
+   return 0;
 }

 static int mdp4_crtc_set_property(struct drm_crtc *crtc, void *state,
@@ -585,8 +575,13 @@ static void mdp4_crtc_vblank_irq(struct mdp4_irq *irq, 
uint32_t irqstatus)
pending = atomic_xchg(_crtc->pending, 0);

if (pending & PENDING_FLIP) {
-   complete_flip(crtc, NULL);
-   drm_flip_work_commit(_crtc->unref_fb_work, priv->wq);
+   if (priv->pending_crtcs & (1 << crtc->id)) {
+   /* our update hasn't been flushed yet: */
+   request_pending(crtc, PENDING_FLIP);
+   } else {
+   complete_flip(crtc, NULL);
+   drm_flip_work_commit(_crtc->unref_fb_work, 
priv->wq);
+   }
}

if

[RFCv4 12/14] drm: Atomic modeset ioctl

2013-11-25 Thread Rob Clark

From: Ville Syrj?l? 

The atomic modeset ioctl cna be used to push any number of new values
for object properties. The driver can then check the full device
configuration as single unit, and try to apply the changes atomically.

The ioctl simply takes a list of object IDs and property IDs and their
values. For setting values to blob properties, the property value
indicates the length of the data, and the actual data is passed via
another blob pointer.

The caller can demand non-blocking operation from the ioctl, and if the
driver can't satisfy that requirement an error will be returned.

The caller can also request to receive asynchronous completion events
after the operation has reached the hardware. An event is sent for each
object specified by the caller, whether or not the actual state of
that object changed. Each event also carries a framebuffer ID, which
indicates to user space that the specified object is no longer
accessing that framebuffer.

Signed-off-by: Ville Syrj?l? 
---
 drivers/gpu/drm/drm_crtc.c  | 156 
 drivers/gpu/drm/drm_drv.c   |   1 +
 include/drm/drmP.h  |   6 ++
 include/drm/drm_crtc.h  |   2 +
 include/uapi/drm/drm.h  |  12 
 include/uapi/drm/drm_mode.h |  20 ++
 6 files changed, 197 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 008b5bb..8158250 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -4581,3 +4581,159 @@ void drm_mode_config_cleanup(struct drm_device *dev)
idr_destroy(>mode_config.crtc_idr);
 }
 EXPORT_SYMBOL(drm_mode_config_cleanup);
+
+int drm_mode_atomic_ioctl(struct drm_device *dev,
+ void *data, struct drm_file *file_priv)
+{
+   struct drm_mode_atomic *arg = data;
+   uint32_t __user *objs_ptr = (uint32_t __user *)(unsigned 
long)(arg->objs_ptr);
+   uint32_t __user *count_props_ptr = (uint32_t __user *)(unsigned 
long)(arg->count_props_ptr);
+   uint32_t __user *props_ptr = (uint32_t __user *)(unsigned 
long)(arg->props_ptr);
+   uint64_t __user *prop_values_ptr = (uint64_t __user *)(unsigned 
long)(arg->prop_values_ptr);
+   uint64_t __user *blob_values_ptr = (uint64_t __user *)(unsigned 
long)(arg->blob_values_ptr);
+   unsigned int copied_objs, copied_props, copied_blobs;
+   void *state;
+   int ret = 0;
+   unsigned int i, j;
+
+   if (arg->flags & ~DRM_MODE_ATOMIC_FLAGS)
+   return -EINVAL;
+
+   /* can't test and expect an event at the same time. */
+   if ((arg->flags & DRM_MODE_ATOMIC_TEST_ONLY) &&
+   (arg->flags & DRM_MODE_PAGE_FLIP_EVENT))
+   return -EINVAL;
+
+retry:
+   copied_objs = 0;
+   copied_props = 0;
+   copied_blobs = 0;
+
+   state = dev->driver->atomic_begin(dev, arg->flags);
+   if (IS_ERR(state)) {
+   ret = PTR_ERR(state);
+   goto out;
+   }
+
+   for (i = 0; i < arg->count_objs; i++) {
+   uint32_t obj_id, count_props;
+   struct drm_mode_object *obj;
+
+   if (get_user(obj_id, objs_ptr + copied_objs)) {
+   ret = -EFAULT;
+   goto out;
+   }
+
+   obj = drm_mode_object_find(dev, obj_id, DRM_MODE_OBJECT_ANY);
+   if (!obj || !obj->properties) {
+   ret = -ENOENT;
+   goto out;
+   }
+
+   if ((obj->type == DRM_MODE_OBJECT_CRTC) &&
+   (arg->flags & DRM_MODE_PAGE_FLIP_EVENT)) {
+   struct drm_pending_vblank_event *e =
+   create_vblank_event(dev, file_priv, 
arg->user_data);
+   if (!e) {
+   ret = -ENOMEM;
+   goto out;
+   }
+   ret = dev->driver->atomic_set_event(dev, state, obj, e);
+   if (ret) {
+   destroy_vblank_event(dev, file_priv, e);
+   goto out;
+   }
+   }
+
+   if (get_user(count_props, count_props_ptr + copied_objs)) {
+   ret = -EFAULT;
+   goto out;
+   }
+
+   copied_objs++;
+
+   for (j = 0; j < count_props; j++) {
+   uint32_t prop_id;
+   uint64_t prop_value;
+   struct drm_property *prop;
+   void *blob_data = NULL;
+
+   if (get_user(prop_id, props_ptr + copied_props)) {
+   ret = -EFAULT;
+   goto out;
+   }
+
+   if (!object_has_prop(obj, prop_id)) {
+   ret = -EINVAL;
+

[RFCv4 11/14] drm: push locking down into restore_fbdev_mode

2013-11-25 Thread Rob Clark

All the call-sites save one need locking.  By pushing it down and adding
a lockless flag, we can use the new spiffy atomic ww_mutex crtc locking
and simplify all the call-sites.
---
 drivers/gpu/drm/drm_fb_cma_helper.c   |  9 ++---
 drivers/gpu/drm/drm_fb_helper.c   | 12 +++-
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |  4 +---
 drivers/gpu/drm/gma500/psb_drv.c  |  4 +---
 drivers/gpu/drm/i915/intel_fbdev.c|  6 +-
 drivers/gpu/drm/msm/msm_drv.c |  7 ++-
 drivers/gpu/drm/omapdrm/omap_drv.c|  4 +---
 drivers/gpu/drm/tegra/fb.c|  7 ++-
 include/drm/drm_fb_helper.h   |  3 ++-
 9 files changed, 19 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
b/drivers/gpu/drm/drm_fb_cma_helper.c
index 61b5a47..df3ad41 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -429,13 +429,8 @@ EXPORT_SYMBOL_GPL(drm_fbdev_cma_fini);
  */
 void drm_fbdev_cma_restore_mode(struct drm_fbdev_cma *fbdev_cma)
 {
-   if (fbdev_cma) {
-   struct drm_device *dev = fbdev_cma->fb_helper.dev;
-
-   drm_modeset_lock_all(dev);
-   drm_fb_helper_restore_fbdev_mode(_cma->fb_helper);
-   drm_modeset_unlock_all(dev);
-   }
+   if (fbdev_cma)
+   drm_fb_helper_restore_fbdev_mode(_cma->fb_helper, false);
 }
 EXPORT_SYMBOL_GPL(drm_fbdev_cma_restore_mode);

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 5773468..294fe5e 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -276,12 +276,15 @@ EXPORT_SYMBOL(drm_fb_helper_debug_leave);
 /**
  * drm_fb_helper_restore_fbdev_mode - restore fbdev configuration
  * @fb_helper: fbcon to restore
+ * @lockless: true in drm_fb_helper_force_kernel_mode() path, to avoid
+ *   blocking in panic case, everywhere else should use false
  *
  * This should be called from driver's drm ->lastclose callback
  * when implementing an fbcon on top of kms using this helper. This ensures 
that
  * the user isn't greeted with a black screen when e.g. X dies.
  */
-bool drm_fb_helper_restore_fbdev_mode(struct drm_fb_helper *fb_helper)
+bool drm_fb_helper_restore_fbdev_mode(struct drm_fb_helper *fb_helper,
+   bool lockless)
 {
struct drm_device *dev = fb_helper->dev;
struct drm_plane *plane;
@@ -289,9 +292,8 @@ bool drm_fb_helper_restore_fbdev_mode(struct drm_fb_helper 
*fb_helper)
void *state;
int i;

-   drm_warn_on_modeset_not_all_locked(dev);
-
-   state = dev->driver->atomic_begin(dev, 0);
+   state = dev->driver->atomic_begin(dev, lockless ?
+   DRM_MODE_ATOMIC_NOLOCK : 0);
if (IS_ERR(state)) {
DRM_ERROR("failed to restore fbdev mode\n");
return true;
@@ -343,7 +345,7 @@ static bool drm_fb_helper_force_kernel_mode(void)
if (helper->dev->switch_power_state == DRM_SWITCH_POWER_OFF)
continue;

-   ret = drm_fb_helper_restore_fbdev_mode(helper);
+   ret = drm_fb_helper_restore_fbdev_mode(helper, true);
if (ret)
error = true;
}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index e7c2f2d..8032021 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -354,7 +354,5 @@ void exynos_drm_fbdev_restore_mode(struct drm_device *dev)
if (!private || !private->fb_helper)
return;

-   drm_modeset_lock_all(dev);
-   drm_fb_helper_restore_fbdev_mode(private->fb_helper);
-   drm_modeset_unlock_all(dev);
+   drm_fb_helper_restore_fbdev_mode(private->fb_helper, false);
 }
diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu/drm/gma500/psb_drv.c
index 34c3116..a6545fe 100644
--- a/drivers/gpu/drm/gma500/psb_drv.c
+++ b/drivers/gpu/drm/gma500/psb_drv.c
@@ -153,11 +153,9 @@ static void psb_lastclose(struct drm_device *dev)
struct drm_psb_private *dev_priv = dev->dev_private;
struct psb_fbdev *fbdev = dev_priv->fbdev;

-   drm_modeset_lock_all(dev);
-   ret = drm_fb_helper_restore_fbdev_mode(>psb_fb_helper);
+   ret = drm_fb_helper_restore_fbdev_mode(>psb_fb_helper, false);
if (ret)
DRM_DEBUG("failed to restore crtc mode\n");
-   drm_modeset_unlock_all(dev);

return;
 }
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c 
b/drivers/gpu/drm/i915/intel_fbdev.c
index 895fcb4..4f7046d 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -313,11 +313,7 @@ void intel_fbdev_restore_mode(struct drm_device *dev)
if (INTEL_INFO(dev)->num_pipes == 0)
return;

-   drm_modeset_lock_all(dev);
-
-   ret =

[RFCv4 10/14] drm: convert crtc to properties/state

2013-11-25 Thread Rob Clark

Break the mutable state of a crtc out into a separate structure
and use atomic properties mechanism to set crtc attributes.  This
makes it easier to have some helpers for crtc->set_property()
and for checking for invalid params.  The idea is that individual
drivers can wrap the state struct in their own struct which adds
driver specific parameters, for easy build-up of state across
multiple set_property() calls and for easy atomic commit or roll-
back.
---
 drivers/gpu/drm/ast/ast_mode.c |   1 +
 drivers/gpu/drm/cirrus/cirrus_mode.c   |   1 +
 drivers/gpu/drm/drm_atomic_helper.c| 277 -
 drivers/gpu/drm/drm_crtc.c | 622 ++---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c   |   7 +-
 drivers/gpu/drm/gma500/cdv_intel_display.c |   1 +
 drivers/gpu/drm/gma500/psb_intel_display.c |   1 +
 drivers/gpu/drm/i915/intel_display.c   |   1 +
 drivers/gpu/drm/mgag200/mgag200_mode.c |   1 +
 drivers/gpu/drm/msm/mdp4/mdp4_crtc.c   |   6 +-
 drivers/gpu/drm/nouveau/dispnv04/crtc.c|   1 +
 drivers/gpu/drm/nouveau/nv50_display.c |   1 +
 drivers/gpu/drm/omapdrm/omap_crtc.c|  12 +-
 drivers/gpu/drm/omapdrm/omap_drv.c |   2 +-
 drivers/gpu/drm/qxl/qxl_display.c  |   2 +
 drivers/gpu/drm/radeon/radeon_display.c|   2 +
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c |   2 +
 drivers/gpu/drm/shmobile/shmob_drm_crtc.c  |   2 +
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c   |   1 +
 drivers/gpu/drm/udl/udl_modeset.c  |   2 +
 drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c|   1 +
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c   |   1 +
 include/drm/drm_atomic_helper.h|  39 ++
 include/drm/drm_crtc.h |  82 +++-
 24 files changed, 818 insertions(+), 250 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 7fc9f72..13f6943 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -619,6 +619,7 @@ static const struct drm_crtc_funcs ast_crtc_funcs = {
.cursor_move = ast_cursor_move,
.reset = ast_crtc_reset,
.set_config = drm_crtc_helper_set_config,
+   .set_property = drm_atomic_helper_crtc_set_property,
.gamma_set = ast_crtc_gamma_set,
.destroy = ast_crtc_destroy,
 };
diff --git a/drivers/gpu/drm/cirrus/cirrus_mode.c 
b/drivers/gpu/drm/cirrus/cirrus_mode.c
index adabc3d..9e0b713 100644
--- a/drivers/gpu/drm/cirrus/cirrus_mode.c
+++ b/drivers/gpu/drm/cirrus/cirrus_mode.c
@@ -363,6 +363,7 @@ static void cirrus_crtc_destroy(struct drm_crtc *crtc)
 static const struct drm_crtc_funcs cirrus_crtc_funcs = {
.gamma_set = cirrus_crtc_gamma_set,
.set_config = drm_crtc_helper_set_config,
+   .set_property = drm_atomic_helper_crtc_set_property,
.destroy = cirrus_crtc_destroy,
 };

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 14e0571..9b60536 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -40,11 +40,13 @@ void *drm_atomic_helper_begin(struct drm_device *dev, 
uint32_t flags)
 {
struct drm_atomic_helper_state *state;
int nplanes = dev->mode_config.num_plane;
+   int ncrtcs  = dev->mode_config.num_crtc;
int sz;
void *ptr;

sz = sizeof(*state);
sz += (sizeof(state->planes) + sizeof(state->pstates)) * nplanes;
+   sz += (sizeof(state->crtcs) + sizeof(state->cstates)) * ncrtcs;

ptr = kzalloc(sz, GFP_KERNEL);

@@ -65,6 +67,12 @@ void *drm_atomic_helper_begin(struct drm_device *dev, 
uint32_t flags)
state->pstates = ptr;
ptr = >pstates[nplanes];

+   state->crtcs = ptr;
+   ptr = >crtcs[ncrtcs];
+
+   state->cstates = ptr;
+   ptr = >cstates[ncrtcs];
+
return state;
 }
 EXPORT_SYMBOL(drm_atomic_helper_begin);
@@ -83,7 +91,18 @@ int drm_atomic_helper_set_event(struct drm_device *dev,
void *state, struct drm_mode_object *obj,
struct drm_pending_vblank_event *event)
 {
-   return -EINVAL;  /* for now */
+   switch (obj->type) {
+   case DRM_MODE_OBJECT_CRTC: {
+   struct drm_crtc_state *cstate =
+   drm_atomic_get_crtc_state(obj_to_crtc(obj), state);
+   if (IS_ERR(cstate))
+   return PTR_ERR(cstate);
+   cstate->event = event;
+   return 0;
+   }
+   default:
+   return -EINVAL;
+   }
 }
 EXPORT_SYMBOL(drm_atomic_helper_set_event);

@@ -102,6 +121,7 @@ int drm_atomic_helper_check(struct drm_device *dev, void 
*state)
 {
struct drm_atomic_helper_state *a = state;
int nplanes = dev->mode_config.num_plane;
+   int ncrtcs = dev->mode_config.num_crtc;
int i, ret = 0;

for (i = 0; i < nplanes; i++) {
@@ -112,6 +132,14 @@ int drm_atomic_helper_check(struct drm_device *dev, void 
*state)

[RFCv4 09/14] drm: convert plane to properties/state

2013-11-25 Thread Rob Clark

Break the mutable state of a plane out into a separate structure
and use atomic properties mechanism to set plane attributes.  This
makes it easier to have some helpers for plane->set_property()
and for checking for invalid params.  The idea is that individual
drivers can wrap the state struct in their own struct which adds
driver specific parameters, for easy build-up of state across
multiple set_property() calls and for easy atomic commit or roll-
back.

The same should be done for CRTC, encoder, and connector, but this
patch only includes the first part (plane).
---
 drivers/gpu/drm/drm_atomic_helper.c | 156 ++-
 drivers/gpu/drm/drm_crtc.c  | 397 +++-
 drivers/gpu/drm/drm_fb_helper.c |  17 +-
 drivers/gpu/drm/exynos/exynos_drm_crtc.c|   4 +-
 drivers/gpu/drm/exynos/exynos_drm_encoder.c |   6 +-
 drivers/gpu/drm/exynos/exynos_drm_plane.c   |  15 +-
 drivers/gpu/drm/i915/intel_sprite.c |  21 +-
 drivers/gpu/drm/msm/mdp4/mdp4_crtc.c|   2 +-
 drivers/gpu/drm/msm/mdp4/mdp4_plane.c   |  19 +-
 drivers/gpu/drm/nouveau/dispnv04/overlay.c  |   8 +-
 drivers/gpu/drm/omapdrm/omap_crtc.c |   4 +-
 drivers/gpu/drm/omapdrm/omap_drv.c  |   2 +-
 drivers/gpu/drm/omapdrm/omap_plane.c|  33 ++-
 drivers/gpu/drm/rcar-du/rcar_du_plane.c |   8 +-
 drivers/gpu/drm/shmobile/shmob_drm_crtc.c   |   2 +-
 drivers/gpu/drm/shmobile/shmob_drm_plane.c  |   6 +-
 drivers/gpu/drm/tegra/dc.c  |  16 +-
 include/drm/drm_atomic_helper.h |  39 ++-
 include/drm/drm_crtc.h  |  88 +-
 19 files changed, 654 insertions(+), 189 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 8b37cf1..14e0571 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -39,10 +39,12 @@
 void *drm_atomic_helper_begin(struct drm_device *dev, uint32_t flags)
 {
struct drm_atomic_helper_state *state;
+   int nplanes = dev->mode_config.num_plane;
int sz;
void *ptr;

sz = sizeof(*state);
+   sz += (sizeof(state->planes) + sizeof(state->pstates)) * nplanes;

ptr = kzalloc(sz, GFP_KERNEL);

@@ -57,6 +59,12 @@ void *drm_atomic_helper_begin(struct drm_device *dev, 
uint32_t flags)
state->dev = dev;
state->flags = flags;

+   state->planes = ptr;
+   ptr = >planes[nplanes];
+
+   state->pstates = ptr;
+   ptr = >pstates[nplanes];
+
return state;
 }
 EXPORT_SYMBOL(drm_atomic_helper_begin);
@@ -92,7 +100,19 @@ EXPORT_SYMBOL(drm_atomic_helper_set_event);
  */
 int drm_atomic_helper_check(struct drm_device *dev, void *state)
 {
-   return 0;  /* for now */
+   struct drm_atomic_helper_state *a = state;
+   int nplanes = dev->mode_config.num_plane;
+   int i, ret = 0;
+
+   for (i = 0; i < nplanes; i++) {
+   if (a->planes[i]) {
+   ret = drm_atomic_check_plane_state(a->planes[i], 
a->pstates[i]);
+   if (ret)
+   break;
+   }
+   }
+
+   return ret;
 }
 EXPORT_SYMBOL(drm_atomic_helper_check);

@@ -168,6 +188,18 @@ fail:
 static void commit_locks(struct drm_atomic_helper_state *a,
struct ww_acquire_ctx *ww_ctx)
 {
+   struct drm_device *dev = a->dev;
+   int nplanes = dev->mode_config.num_plane;
+   int i;
+
+   for (i = 0; i < nplanes; i++) {
+   struct drm_plane *plane = a->planes[i];
+   if (plane) {
+   plane->state->state = NULL;
+   drm_atomic_helper_destroy_plane_state(plane, 
a->pstates[i]);
+   }
+   }
+
/* and properly release them (clear in_atomic, remove from list): */
mutex_lock(>mutex);
while (!list_empty(>locked)) {
@@ -186,7 +218,17 @@ static void commit_locks(struct drm_atomic_helper_state *a,
 static int atomic_commit(struct drm_atomic_helper_state *a,
struct ww_acquire_ctx *ww_ctx)
 {
-   int ret = 0;
+   int nplanes = a->dev->mode_config.num_plane;
+   int i, ret = 0;
+
+   for (i = 0; i < nplanes; i++) {
+   struct drm_plane *plane = a->planes[i];
+   if (plane) {
+   ret = drm_atomic_commit_plane_state(plane, 
a->pstates[i]);
+   if (ret)
+   break;
+   }
+   }

commit_locks(a, ww_ctx);

@@ -263,7 +305,117 @@ void _drm_atomic_helper_state_free(struct kref *kref)
 }
 EXPORT_SYMBOL(_drm_atomic_helper_state_free);

+int drm_atomic_helper_plane_set_property(struct drm_plane *plane, void *state,
+   struct drm_property *property, uint64_t val, void *blob_data)
+{
+   struct drm_plane_state *pstate = drm_atomic_get_plane_state(plane, 
state);
+   if (IS_ERR(pstate))
+   return

[RFCv4 08/14] drm: Refactor object property check code

2013-11-25 Thread Rob Clark

From: Ville Syrj?l? 

Refactor the code to check whether an object has a specific property
to a new function.

v1: original
v2: rebase on atomic -- Rob Clark
v3: EINVAL->ENOENT

Signed-off-by: Ville Syrj?l? 
---
 drivers/gpu/drm/drm_crtc.c | 25 ++---
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 5142599..8180499 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3506,6 +3506,19 @@ static int drm_mode_set_obj_prop(struct drm_mode_object 
*obj,
return -EINVAL;
 }

+static bool object_has_prop(const struct drm_mode_object *obj, u32 prop_id)
+{
+   int i;
+
+   if (!obj->properties)
+   return false;
+
+   for (i = 0; i < obj->properties->count; i++)
+   if (obj->properties->ids[i] == prop_id)
+   return true;
+   return false;
+}
+
 /* call with mode_config mutex held */
 static int drm_mode_set_obj_prop_id(struct drm_device *dev, void *state,
uint32_t obj_id, uint32_t obj_type,
@@ -3513,20 +3526,10 @@ static int drm_mode_set_obj_prop_id(struct drm_device 
*dev, void *state,
 {
struct drm_mode_object *arg_obj;
struct drm_property *property;
-   int i;

arg_obj = drm_mode_object_find(dev, obj_id, obj_type);
-   if (!arg_obj)
+   if (!(arg_obj && object_has_prop(arg_obj, prop_id)))
return -ENOENT;
-   if (!arg_obj->properties)
-   return -EINVAL;
-
-   for (i = 0; i < arg_obj->properties->count; i++)
-   if (arg_obj->properties->ids[i] == prop_id)
-   break;
-
-   if (i == arg_obj->properties->count)
-   return -EINVAL;

property = drm_property_find(dev, prop_id);
if (!property)
-- 
1.8.4.2

[RFCv4 07/14] drm: Allow drm_mode_object_find() to look up an object of any type

2013-11-25 Thread Rob Clark

From: Ville Syrj?l? 

To avoid having to pass object types from userspace for atomic mode
setting ioctl, allow drm_mode_object_find() to look up an object of any
type. This will only work as long as the all object types share the ID
space.

Signed-off-by: Ville Syrj?l? 
---
 drivers/gpu/drm/drm_crtc.c | 3 ++-
 include/drm/drm_crtc.h | 1 +
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 68eeb2a..5142599 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -445,7 +445,8 @@ struct drm_mode_object *drm_mode_object_find(struct 
drm_device *dev,

mutex_lock(>mode_config.idr_mutex);
obj = idr_find(>mode_config.crtc_idr, id);
-   if (!obj || (obj->type != type) || (obj->id != id))
+   if (!obj || (type != DRM_MODE_OBJECT_ANY && obj->type != type) ||
+   (obj->id != id))
obj = NULL;
mutex_unlock(>mode_config.idr_mutex);

diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index ff1ecb5..40eec19 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -52,6 +52,7 @@ struct drm_object_property_values;
 #define DRM_MODE_OBJECT_BLOB 0x
 #define DRM_MODE_OBJECT_PLANE 0x
 #define DRM_MODE_OBJECT_BRIDGE 0xbdbdbdbd
+#define DRM_MODE_OBJECT_ANY 0

 struct drm_mode_object {
uint32_t id;
-- 
1.8.4.2

[RFCv4 06/14] drm: split propvals out and blob property support

2013-11-25 Thread Rob Clark

Split property values out into a different struct, so we can later
move property values into state structs.  This will allow the
property values to stay in sync w/ the state updates which are
either discarded or atomically committed.

And since we are touching all the same code, add support for mutable
blob properties, which will also be needed for atomic modeset.
---
 drivers/gpu/drm/drm_crtc.c  | 79 +
 drivers/gpu/drm/drm_fb_helper.c |  3 +-
 drivers/gpu/drm/gma500/cdv_intel_dp.c   |  3 +-
 drivers/gpu/drm/gma500/cdv_intel_hdmi.c |  3 +-
 drivers/gpu/drm/gma500/cdv_intel_lvds.c |  6 ++-
 drivers/gpu/drm/gma500/mdfld_dsi_output.c   |  8 +--
 drivers/gpu/drm/gma500/psb_intel_lvds.c |  6 ++-
 drivers/gpu/drm/gma500/psb_intel_sdvo.c | 19 +--
 drivers/gpu/drm/i2c/ch7006_drv.c|  4 +-
 drivers/gpu/drm/i915/intel_display.c|  3 +-
 drivers/gpu/drm/i915/intel_dp.c |  3 +-
 drivers/gpu/drm/i915/intel_hdmi.c   |  3 +-
 drivers/gpu/drm/i915/intel_sdvo.c   | 19 +--
 drivers/gpu/drm/i915/intel_tv.c |  6 ++-
 drivers/gpu/drm/nouveau/dispnv04/tvnv17.c   |  3 +-
 drivers/gpu/drm/nouveau/nouveau_connector.c |  4 +-
 drivers/gpu/drm/omapdrm/omap_drv.c  |  6 ++-
 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c   |  3 +-
 drivers/gpu/drm/rcar-du/rcar_du_vgacon.c|  3 +-
 drivers/gpu/drm/shmobile/shmob_drm_crtc.c   |  4 +-
 include/drm/drm_crtc.h  | 11 +++-
 21 files changed, 142 insertions(+), 57 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 622d001..68eeb2a 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -173,6 +173,14 @@ void drm_warn_on_modeset_not_all_locked(struct drm_device 
*dev)
 }
 EXPORT_SYMBOL(drm_warn_on_modeset_not_all_locked);

+static int drm_mode_set_obj_prop(struct drm_mode_object *obj,
+   void *state, struct drm_property *property,
+   uint64_t value, void *blob_data);
+static struct drm_property_blob *drm_property_create_blob(struct drm_device 
*dev,
+   int length, void *data);
+static void drm_property_destroy_blob(struct drm_device *dev,
+   struct drm_property_blob *blob);
+
 /* Avoid boilerplate.  I'm tired of typing. */
 #define DRM_ENUM_NAME_FN(fnname, list) \
const char *fnname(int val) \
@@ -727,6 +735,7 @@ int drm_crtc_init(struct drm_device *dev, struct drm_crtc 
*crtc,
goto out;

crtc->base.properties = >properties;
+   crtc->base.propvals = >propvals;

list_add_tail(>head, >mode_config.crtc_list);
dev->mode_config.num_crtc++;
@@ -818,6 +827,7 @@ int drm_connector_init(struct drm_device *dev,
goto out;

connector->base.properties = >properties;
+   connector->base.propvals = >propvals;
connector->dev = dev;
connector->funcs = funcs;
connector->connector_type = connector_type;
@@ -991,6 +1001,7 @@ int drm_plane_init(struct drm_device *dev, struct 
drm_plane *plane,
goto out;

plane->base.properties = >properties;
+   plane->base.propvals = >propvals;
plane->dev = dev;
plane->funcs = funcs;
plane->format_types = kmalloc(sizeof(uint32_t) * format_count,
@@ -1791,7 +1802,7 @@ int drm_mode_getconnector(struct drm_device *dev, void 
*data,
goto out;
}

-   if (put_user(connector->properties.values[i],
+   if (put_user(connector->propvals.values[i],
 prop_values + copied)) {
ret = -EFAULT;
goto out;
@@ -3102,19 +3113,33 @@ void drm_object_attach_property(struct drm_mode_object 
*obj,
}

obj->properties->ids[count] = property->base.id;
-   obj->properties->values[count] = init_val;
+   obj->propvals->values[count] = init_val;
obj->properties->count++;
 }
 EXPORT_SYMBOL(drm_object_attach_property);

 int drm_object_property_set_value(struct drm_mode_object *obj,
- struct drm_property *property, uint64_t val)
+ struct drm_object_property_values *propvals,
+ struct drm_property *property, uint64_t val,
+ void *blob_data)
 {
int i;

for (i = 0; i < obj->properties->count; i++) {
if (obj->properties->ids[i] == property->base.id) {
-   obj->properties->values[i] = val;
+   struct drm_device *dev = property->dev;
+   if (property->flags & DRM_MODE_PROP_BLOB) {
+   struct drm_property_blob *blob, *old_blob = 
NULL;
+   old_blob

[RFCv4 05/14] drm: helpers to find mode objects

2013-11-25 Thread Rob Clark

Add a few more useful helpers to find mode objects.
---
 drivers/gpu/drm/drm_crtc.c | 97 ++
 include/drm/drm_crtc.h | 33 
 2 files changed, 63 insertions(+), 67 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index e438e24..622d001 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1633,7 +1633,6 @@ int drm_mode_getcrtc(struct drm_device *dev,
 {
struct drm_mode_crtc *crtc_resp = data;
struct drm_crtc *crtc;
-   struct drm_mode_object *obj;
int ret = 0;

if (!drm_core_check_feature(dev, DRIVER_MODESET))
@@ -1641,13 +1640,11 @@ int drm_mode_getcrtc(struct drm_device *dev,

drm_modeset_lock_all(dev);

-   obj = drm_mode_object_find(dev, crtc_resp->crtc_id,
-  DRM_MODE_OBJECT_CRTC);
-   if (!obj) {
+   crtc = drm_crtc_find(dev, crtc_resp->crtc_id);
+   if (!crtc) {
ret = -ENOENT;
goto out;
}
-   crtc = obj_to_crtc(obj);

crtc_resp->x = crtc->x;
crtc_resp->y = crtc->y;
@@ -1701,7 +1698,6 @@ int drm_mode_getconnector(struct drm_device *dev, void 
*data,
  struct drm_file *file_priv)
 {
struct drm_mode_get_connector *out_resp = data;
-   struct drm_mode_object *obj;
struct drm_connector *connector;
struct drm_display_mode *mode;
int mode_count = 0;
@@ -1725,13 +1721,11 @@ int drm_mode_getconnector(struct drm_device *dev, void 
*data,

mutex_lock(>mode_config.mutex);

-   obj = drm_mode_object_find(dev, out_resp->connector_id,
-  DRM_MODE_OBJECT_CONNECTOR);
-   if (!obj) {
+   connector = drm_connector_find(dev, out_resp->connector_id);
+   if (!connector) {
ret = -ENOENT;
goto out;
}
-   connector = obj_to_connector(obj);

props_count = connector->properties.count;

@@ -1833,7 +1827,6 @@ int drm_mode_getencoder(struct drm_device *dev, void 
*data,
struct drm_file *file_priv)
 {
struct drm_mode_get_encoder *enc_resp = data;
-   struct drm_mode_object *obj;
struct drm_encoder *encoder;
int ret = 0;

@@ -1841,13 +1834,11 @@ int drm_mode_getencoder(struct drm_device *dev, void 
*data,
return -EINVAL;

drm_modeset_lock_all(dev);
-   obj = drm_mode_object_find(dev, enc_resp->encoder_id,
-  DRM_MODE_OBJECT_ENCODER);
-   if (!obj) {
+   encoder = drm_encoder_find(dev, enc_resp->encoder_id);
+   if (!encoder) {
ret = -ENOENT;
goto out;
}
-   encoder = obj_to_encoder(obj);

if (encoder->crtc)
enc_resp->crtc_id = encoder->crtc->base.id;
@@ -1922,7 +1913,6 @@ int drm_mode_getplane(struct drm_device *dev, void *data,
struct drm_file *file_priv)
 {
struct drm_mode_get_plane *plane_resp = data;
-   struct drm_mode_object *obj;
struct drm_plane *plane;
uint32_t __user *format_ptr;
int ret = 0;
@@ -1931,13 +1921,11 @@ int drm_mode_getplane(struct drm_device *dev, void 
*data,
return -EINVAL;

drm_modeset_lock_all(dev);
-   obj = drm_mode_object_find(dev, plane_resp->plane_id,
-  DRM_MODE_OBJECT_PLANE);
-   if (!obj) {
+   plane = drm_plane_find(dev, plane_resp->plane_id);
+   if (!plane) {
ret = -ENOENT;
goto out;
}
-   plane = obj_to_plane(obj);

if (plane->crtc)
plane_resp->crtc_id = plane->crtc->base.id;
@@ -1987,7 +1975,6 @@ int drm_mode_setplane(struct drm_device *dev, void *data,
struct drm_file *file_priv)
 {
struct drm_mode_set_plane *plane_req = data;
-   struct drm_mode_object *obj;
struct drm_plane *plane;
struct drm_crtc *crtc;
struct drm_framebuffer *fb = NULL, *old_fb = NULL;
@@ -2002,14 +1989,12 @@ int drm_mode_setplane(struct drm_device *dev, void 
*data,
 * First, find the plane, crtc, and fb objects.  If not available,
 * we don't bother to call the driver.
 */
-   obj = drm_mode_object_find(dev, plane_req->plane_id,
-  DRM_MODE_OBJECT_PLANE);
-   if (!obj) {
+   plane = drm_plane_find(dev, plane_req->plane_id);
+   if (!plane) {
DRM_DEBUG_KMS("Unknown plane ID %d\n",
  plane_req->plane_id);
return -ENOENT;
}
-   plane = obj_to_plane(obj);

/* No fb means shut it down */
if (!plane_req->fb_id) {
@@ -2022,15 +2007,13 @@ int drm_mode_setplane(struct drm_device *dev, void 
*data,
goto out;
}

-   obj = drm_mode_object_find(dev, plane_req->crtc_id,
-

[RFCv4 04/14] drm: add signed-range property type

2013-11-25 Thread Rob Clark

Like range, but values are signed.
---
 drivers/gpu/drm/drm_crtc.c  | 29 +
 include/drm/drm_crtc.h  | 12 
 include/uapi/drm/drm_mode.h |  1 +
 3 files changed, 38 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 8013204..e438e24 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3002,14 +3002,12 @@ struct drm_property *drm_property_create_bitmask(struct 
drm_device *dev,
 }
 EXPORT_SYMBOL(drm_property_create_bitmask);

-struct drm_property *drm_property_create_range(struct drm_device *dev, int 
flags,
-const char *name,
+static struct drm_property *property_create_range(struct drm_device *dev,
+int flags, const char *name,
 uint64_t min, uint64_t max)
 {
struct drm_property *property;

-   flags |= DRM_MODE_PROP_RANGE;
-
property = drm_property_create(dev, flags, name, 2);
if (!property)
return NULL;
@@ -3019,8 +3017,25 @@ struct drm_property *drm_property_create_range(struct 
drm_device *dev, int flags

return property;
 }
+
+struct drm_property *drm_property_create_range(struct drm_device *dev, int 
flags,
+const char *name,
+uint64_t min, uint64_t max)
+{
+   return property_create_range(dev, DRM_MODE_PROP_RANGE | flags,
+   name, min, max);
+}
 EXPORT_SYMBOL(drm_property_create_range);

+struct drm_property *drm_property_create_signed_range(struct drm_device *dev,
+int flags, const char *name,
+int64_t min, int64_t max)
+{
+   return property_create_range(dev, DRM_MODE_PROP_SIGNED_RANGE | flags,
+   name, I642U64(min), I642U64(max));
+}
+EXPORT_SYMBOL(drm_property_create_signed_range);
+
 struct drm_property *drm_property_create_object(struct drm_device *dev,
 int flags, const char *name, uint32_t 
type)
 {
@@ -3362,6 +3377,12 @@ static bool drm_property_change_is_valid(struct 
drm_property *property,
if (value < property->values[0] || value > property->values[1])
return false;
return true;
+   } else if (drm_property_type_is(property, DRM_MODE_PROP_SIGNED_RANGE)) {
+   int64_t svalue = U642I64(value);
+   if (svalue < U642I64(property->values[0]) ||
+   svalue > U642I64(property->values[1]))
+   return false;
+   return true;
} else if (drm_property_type_is(property, DRM_MODE_PROP_BITMASK)) {
int i;
uint64_t valid_mask = 0;
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index c05d5ba..17790a0 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -65,6 +65,15 @@ struct drm_object_properties {
uint64_t values[DRM_OBJECT_MAX_PROPERTY];
 };

+static inline int64_t U642I64(uint64_t val)
+{
+   return (int64_t)*((int64_t *));
+}
+static inline uint64_t I642U64(int64_t val)
+{
+   return (uint64_t)*((uint64_t *));
+}
+
 /*
  * Note on terminology:  here, for brevity and convenience, we refer to 
connector
  * control chips as 'CRTCs'.  They can control any type of connector, VGA, 
LVDS,
@@ -1123,6 +1132,9 @@ struct drm_property *drm_property_create_bitmask(struct 
drm_device *dev,
 struct drm_property *drm_property_create_range(struct drm_device *dev, int 
flags,
 const char *name,
 uint64_t min, uint64_t max);
+struct drm_property *drm_property_create_signed_range(struct drm_device *dev,
+int flags, const char *name,
+int64_t min, int64_t max);
 struct drm_property *drm_property_create_object(struct drm_device *dev,
 int flags, const char *name, uint32_t 
type);
 extern void drm_property_destroy(struct drm_device *dev, struct drm_property 
*property);
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 516425d..6421edc 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -264,6 +264,7 @@ struct drm_mode_get_connector {
 #define DRM_MODE_PROP_EXTENDED_TYPE0xffc0
 #define DRM_MODE_PROP_TYPE(n)  ((n) << 6)
 #define DRM_MODE_PROP_OBJECT   DRM_MODE_PROP_TYPE(1)
+#define DRM_MODE_PROP_SIGNED_RANGE DRM_MODE_PROP_TYPE(2)

 struct drm_mode_property_enum {
__u64 value;
-- 
1.8.4.2

[RFCv4 03/14] drm: add object property type

2013-11-25 Thread Rob Clark

An object property is an id (idr) for a drm mode object.  This
will allow a property to be used set/get a framebuffer, CRTC, etc.
---
 drivers/gpu/drm/drm_crtc.c  | 60 +++--
 include/drm/drm_crtc.h  | 27 
 include/uapi/drm/drm_mode.h | 14 +++
 3 files changed, 88 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index c8a4d2f..8013204 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2913,6 +2913,8 @@ struct drm_property *drm_property_create(struct 
drm_device *dev, int flags,
if (!property)
return NULL;

+   property->dev = dev;
+
if (num_values) {
property->values = kzalloc(sizeof(uint64_t)*num_values, 
GFP_KERNEL);
if (!property->values)
@@ -2933,6 +2935,9 @@ struct drm_property *drm_property_create(struct 
drm_device *dev, int flags,
}

list_add_tail(>head, >mode_config.property_list);
+
+   BUG_ON(!drm_property_type_valid(property));
+
return property;
 fail:
kfree(property->values);
@@ -3016,19 +3021,38 @@ struct drm_property *drm_property_create_range(struct 
drm_device *dev, int flags
 }
 EXPORT_SYMBOL(drm_property_create_range);

+struct drm_property *drm_property_create_object(struct drm_device *dev,
+int flags, const char *name, uint32_t 
type)
+{
+   struct drm_property *property;
+
+   flags |= DRM_MODE_PROP_OBJECT;
+
+   property = drm_property_create(dev, flags, name, 1);
+   if (!property)
+   return NULL;
+
+   property->values[0] = type;
+
+   return property;
+}
+EXPORT_SYMBOL(drm_property_create_object);
+
 int drm_property_add_enum(struct drm_property *property, int index,
  uint64_t value, const char *name)
 {
struct drm_property_enum *prop_enum;

-   if (!(property->flags & (DRM_MODE_PROP_ENUM | DRM_MODE_PROP_BITMASK)))
+   if (!(drm_property_type_is(property, DRM_MODE_PROP_ENUM) ||
+   drm_property_type_is(property, DRM_MODE_PROP_BITMASK)))
return -EINVAL;

/*
 * Bitmask enum properties have the additional constraint of values
 * from 0 to 63
 */
-   if ((property->flags & DRM_MODE_PROP_BITMASK) && (value > 63))
+   if (drm_property_type_is(property, DRM_MODE_PROP_BITMASK) &&
+   (value > 63))
return -EINVAL;

if (!list_empty(>enum_blob_list)) {
@@ -3153,10 +3177,11 @@ int drm_mode_getproperty_ioctl(struct drm_device *dev,
}
property = obj_to_property(obj);

-   if (property->flags & (DRM_MODE_PROP_ENUM | DRM_MODE_PROP_BITMASK)) {
+   if (drm_property_type_is(property, DRM_MODE_PROP_ENUM) ||
+   drm_property_type_is(property, DRM_MODE_PROP_BITMASK)) {
list_for_each_entry(prop_enum, >enum_blob_list, head)
enum_count++;
-   } else if (property->flags & DRM_MODE_PROP_BLOB) {
+   } else if (drm_property_type_is(property, DRM_MODE_PROP_BLOB)) {
list_for_each_entry(prop_blob, >enum_blob_list, head)
blob_count++;
}
@@ -3178,7 +3203,8 @@ int drm_mode_getproperty_ioctl(struct drm_device *dev,
}
out_resp->count_values = value_count;

-   if (property->flags & (DRM_MODE_PROP_ENUM | DRM_MODE_PROP_BITMASK)) {
+   if (drm_property_type_is(property, DRM_MODE_PROP_ENUM) ||
+   drm_property_type_is(property, DRM_MODE_PROP_BITMASK)) {
if ((out_resp->count_enum_blobs >= enum_count) && enum_count) {
copied = 0;
enum_ptr = (struct drm_mode_property_enum __user 
*)(unsigned long)out_resp->enum_blob_ptr;
@@ -3200,7 +3226,7 @@ int drm_mode_getproperty_ioctl(struct drm_device *dev,
out_resp->count_enum_blobs = enum_count;
}

-   if (property->flags & DRM_MODE_PROP_BLOB) {
+   if (drm_property_type_is(property, DRM_MODE_PROP_BLOB)) {
if ((out_resp->count_enum_blobs >= blob_count) && blob_count) {
copied = 0;
blob_id_ptr = (uint32_t __user *)(unsigned 
long)out_resp->enum_blob_ptr;
@@ -3331,19 +3357,25 @@ static bool drm_property_change_is_valid(struct 
drm_property *property,
 {
if (property->flags & DRM_MODE_PROP_IMMUTABLE)
return false;
-   if (property->flags & DRM_MODE_PROP_RANGE) {
+
+   if (drm_property_type_is(property, DRM_MODE_PROP_RANGE)) {
if (value < property->values[0] || value > property->values[1])
return false;
return true;
-   } else if (property->flags & DRM_MODE_PROP_BITMASK) {
+   } else if (drm_property_type_is(property, DRM_MODE_PROP_BITMASK)) {
int i;

[RFCv4 02/14] drm: convert crtc to ww_mutex

2013-11-25 Thread Rob Clark

For atomic, it will be quite convenient to not have to care so much
about locking order.  And 'state' gives us a convenient place to stash a
ww_ctx for any sort of update that needs to grab multiple crtc locks.

Because we will want to eventually make locking even more fine grained
(giving locks to planes, connectors, etc), split out drm_modeset_lock
so that the atomic state won't eventually have to keep separate lists of
locked planes/crtcs/etc.

The state keeps track of which locks it has aquired, and for the benefit
of NONBLOCK operations, supports transfering "locked" resources to
driver worker/thread to complete the asynchronous state change.
---
 drivers/gpu/drm/drm_atomic_helper.c  | 140 ++-
 drivers/gpu/drm/drm_crtc.c   | 105 +++---
 drivers/gpu/drm/i915/intel_display.c |  16 ++--
 drivers/gpu/drm/omapdrm/omap_crtc.c  |  10 +--
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c  |   8 +-
 include/drm/drmP.h   |   5 --
 include/drm/drm_atomic_helper.h  |  17 +
 include/drm/drm_crtc.h   |  75 +--
 include/uapi/drm/drm_mode.h  |   3 +
 9 files changed, 340 insertions(+), 39 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 46c67b8..8b37cf1 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -49,9 +49,14 @@ void *drm_atomic_helper_begin(struct drm_device *dev, 
uint32_t flags)
state = ptr;
ptr = [1];

+   ww_acquire_init(>ww_ctx, _ww_class);
+   INIT_LIST_HEAD(>locked);
+
+   mutex_init(>mutex);
kref_init(>refcount);
state->dev = dev;
state->flags = flags;
+
return state;
 }
 EXPORT_SYMBOL(drm_atomic_helper_begin);
@@ -91,6 +96,103 @@ int drm_atomic_helper_check(struct drm_device *dev, void 
*state)
 }
 EXPORT_SYMBOL(drm_atomic_helper_check);

+/* Note that we drop and re-acquire the locks w/ ww_mutex directly,
+ * since we keep the crtc in our list with in_atomic == true.
+ */
+
+static void drop_locks(struct drm_atomic_helper_state *a,
+   struct ww_acquire_ctx *ww_ctx)
+{
+   struct drm_modeset_lock *lock;
+
+   mutex_lock(>mutex);
+   list_for_each_entry(lock, >locked, head)
+   ww_mutex_unlock(>mutex);
+   mutex_unlock(>mutex);
+
+   ww_acquire_fini(ww_ctx);
+}
+
+static void grab_locks(struct drm_atomic_helper_state *a,
+   struct ww_acquire_ctx *ww_ctx)
+{
+   struct drm_modeset_lock *lock, *slow_locked, *contended;
+   int ret;
+
+   lock = slow_locked = contended = NULL;
+
+
+   ww_acquire_init(ww_ctx, _ww_class);
+
+   /*
+* We need to do proper rain^Hww dance.. another context
+* could sneak in a grab the lock in order to check
+* crtc->in_atomic, and we get -EDEADLK.  But the winner
+* will realize the mistake when it sees crtc->in_atomic
+* already set, and then drop lock and return -EBUSY.
+* So we just need to keep dancing until we win.
+*/
+retry:
+   ret = 0;
+   list_for_each_entry(lock, >locked, head) {
+   if (lock == slow_locked) {
+   slow_locked = NULL;
+   continue;
+   }
+   contended = lock;
+   ret = ww_mutex_lock(>mutex, ww_ctx);
+   if (ret)
+   goto fail;
+   }
+
+fail:
+   if (ret == -EDEADLK) {
+   /* we lost out in a seqno race, backoff, lock and retry.. */
+
+   list_for_each_entry(lock, >locked, head) {
+   if (lock == contended)
+   break;
+   ww_mutex_unlock(>mutex);
+   }
+
+   if (slow_locked)
+   ww_mutex_unlock(_locked->mutex);
+
+   ww_mutex_lock_slow(>mutex, ww_ctx);
+   slow_locked = contended;
+   goto retry;
+   }
+   WARN_ON(ret);   /* if we get EALREADY then something is fubar */
+}
+
+static void commit_locks(struct drm_atomic_helper_state *a,
+   struct ww_acquire_ctx *ww_ctx)
+{
+   /* and properly release them (clear in_atomic, remove from list): */
+   mutex_lock(>mutex);
+   while (!list_empty(>locked)) {
+   struct drm_modeset_lock *lock;
+
+   lock = list_first_entry(>locked,
+   struct drm_modeset_lock, head);
+
+   drm_modeset_unlock(lock);
+   }
+   mutex_unlock(>mutex);
+   ww_acquire_fini(ww_ctx);
+   a->committed = true;
+}
+
+static int atomic_commit(struct drm_atomic_helper_state *a,
+   struct ww_acquire_ctx *ww_ctx)
+{
+   int ret = 0;
+
+   commit_locks(a, ww_ctx);
+
+   return ret;
+}
+
 /**
  * drm_atomic_helper_commit - commit state
  * @dev: DRM device
@@ -104,11 +206,26 @@

[RFCv4 01/14] drm: add atomic fxns

2013-11-25 Thread Rob Clark

The 'atomic' mechanism allows for multiple properties to be updated,
checked, and commited atomically.  This will be the basis of atomic-
modeset and nuclear-pageflip.

The basic flow is:

   state = dev->atomic_begin();
   for (... one or more ...)
  obj->set_property(obj, state, prop, value);
   if (dev->atomic_check(state))
  dev->atomic_commit(state);
   dev->atomic_end(state);

The split of check and commit steps is to allow for ioctls with a
test-only flag (which would skip the commit step).
---
 drivers/gpu/drm/Makefile|   3 +-
 drivers/gpu/drm/ast/ast_drv.c   |   6 ++
 drivers/gpu/drm/ast/ast_drv.h   |   1 +
 drivers/gpu/drm/cirrus/cirrus_drv.c |   6 ++
 drivers/gpu/drm/cirrus/cirrus_drv.h |   1 +
 drivers/gpu/drm/drm_atomic_helper.c | 135 ++
 drivers/gpu/drm/drm_crtc.c  | 141 +---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c|   4 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.c |   7 ++
 drivers/gpu/drm/exynos/exynos_drm_plane.c   |   4 +-
 drivers/gpu/drm/gma500/cdv_intel_crt.c  |   4 +-
 drivers/gpu/drm/gma500/cdv_intel_dp.c   |   4 +-
 drivers/gpu/drm/gma500/cdv_intel_hdmi.c |   4 +-
 drivers/gpu/drm/gma500/cdv_intel_lvds.c |   4 +-
 drivers/gpu/drm/gma500/mdfld_dsi_output.c   |   4 +-
 drivers/gpu/drm/gma500/psb_drv.c|   7 ++
 drivers/gpu/drm/gma500/psb_drv.h|   1 +
 drivers/gpu/drm/gma500/psb_intel_drv.h  |   4 +-
 drivers/gpu/drm/gma500/psb_intel_lvds.c |   4 +-
 drivers/gpu/drm/gma500/psb_intel_sdvo.c |   4 +-
 drivers/gpu/drm/i915/i915_drv.c |   8 ++
 drivers/gpu/drm/i915/intel_crt.c|   4 +-
 drivers/gpu/drm/i915/intel_dp.c |   4 +-
 drivers/gpu/drm/i915/intel_drv.h|   1 +
 drivers/gpu/drm/i915/intel_hdmi.c   |   4 +-
 drivers/gpu/drm/i915/intel_lvds.c   |   4 +-
 drivers/gpu/drm/i915/intel_sdvo.c   |   4 +-
 drivers/gpu/drm/i915/intel_tv.c |   5 +-
 drivers/gpu/drm/mgag200/mgag200_drv.c   |   7 ++
 drivers/gpu/drm/mgag200/mgag200_drv.h   |   1 +
 drivers/gpu/drm/msm/mdp4/mdp4_crtc.c|   4 +-
 drivers/gpu/drm/msm/mdp4/mdp4_plane.c   |   4 +-
 drivers/gpu/drm/msm/msm_drv.c   |   6 ++
 drivers/gpu/drm/msm/msm_drv.h   |   1 +
 drivers/gpu/drm/nouveau/dispnv04/overlay.c  |   4 +-
 drivers/gpu/drm/nouveau/nouveau_connector.c |   3 +-
 drivers/gpu/drm/nouveau/nouveau_drm.c   |   7 ++
 drivers/gpu/drm/nouveau/nouveau_drm.h   |   1 +
 drivers/gpu/drm/omapdrm/omap_crtc.c |   7 +-
 drivers/gpu/drm/omapdrm/omap_drv.c  |   6 ++
 drivers/gpu/drm/omapdrm/omap_drv.h  |   5 +-
 drivers/gpu/drm/omapdrm/omap_plane.c|   4 +-
 drivers/gpu/drm/qxl/qxl_display.c   |   4 +-
 drivers/gpu/drm/qxl/qxl_drv.c   |   9 ++
 drivers/gpu/drm/radeon/radeon_connectors.c  |   9 +-
 drivers/gpu/drm/radeon/radeon_drv.c |   9 ++
 drivers/gpu/drm/rcar-du/rcar_du_drv.c   |   7 ++
 drivers/gpu/drm/rcar-du/rcar_du_plane.c |   4 +-
 drivers/gpu/drm/shmobile/shmob_drm_drv.c|   7 ++
 drivers/gpu/drm/tilcdc/tilcdc_drv.c |   6 ++
 drivers/gpu/drm/tilcdc/tilcdc_drv.h |   1 +
 drivers/gpu/drm/tilcdc/tilcdc_slave.c   |   3 +-
 drivers/gpu/drm/udl/udl_connector.c |   6 +-
 drivers/gpu/drm/udl/udl_drv.c   |   8 ++
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |   7 ++
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |   1 +
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |   4 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.h |   4 +-
 include/drm/drmP.h  |  77 +++
 include/drm/drm_atomic_helper.h | 100 
 include/drm/drm_crtc.h  |  14 +--
 61 files changed, 619 insertions(+), 103 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_atomic_helper.c
 create mode 100644 include/drm/drm_atomic_helper.h

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index cc08b84..4a2e320 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -13,7 +13,8 @@ drm-y   :=drm_auth.o drm_buffer.o drm_bufs.o 
drm_cache.o \
drm_crtc.o drm_modes.o drm_edid.o \
drm_info.o drm_debugfs.o drm_encoder_slave.o \
drm_trace_points.o drm_global.o drm_prime.o \
-   drm_rect.o drm_vma_manager.o drm_flip_work.o
+   drm_rect.o drm_vma_manager.o drm_flip_work.o \
+   drm_atomic_helper.o

 drm-$(CONFIG_COMPAT) += drm_ioc32.o
 drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c
index 5137f15..90ba5f1 100644
--- a/drivers/gpu/drm/ast/ast_drv.c
+++ b/drivers/gpu/drm/ast/ast_drv.c
@@ -216,6 +216,12 @@ static struct drm_driver driver = {
.dumb_map_offset =

[RFCv4 00/14] Atomic/nuclear modeset/pageflip

2013-11-25 Thread Rob Clark

Previous Revision:
http://lists.freedesktop.org/archives/dri-devel/2013-November/049363.html

Changes since previous:
+ convert new properties over to DRM_MODE_PROP_EXTENDED_TYPE, so we
  aren't consuming one new bit per property type (as suggested by, I
  think, Ville)
+ Fixed usage of ww_ctx, split things out into 'struct drm_modeset_lock'
  to make things easier when we start making locking even more fine
  grained (ie. per-plane locks, etc)
+ Handle connector_ids changes better.  In legacy setcrtc path, we
  implicitly update other CRTCs that are having their connector stolen,
  whereas in atomic ioctl there is no implicit connector stealing (ie.
  this is an error if user does not also remove the connector from it's
  current CRTC.

-

Description from original RFC (with updated links):

This patchset is the merging of Ville's atomic modeset ioctl, and
the drm_{crtc,plane}_state stuff from my original nuclear pageflip
RFC.

It is currently working on msm with an updated version of Ville's
glplane test app (removing cursor properties and atomic event):

  https://github.com/robclark/glplane

the libdrm bits can be found here:

  https://github.com/robclark/libdrm/commits/atomic

The msm part is on top of msm-next, the complete branch can be found:

  http://cgit.freedesktop.org/~robclark/linux/log/?h=global-thermonuclear-war-9

Compared to my earlier nuclear pageflip RFC, there is now a set of
drm_atomic helpers which do most of the non-hw-specific work for
the different drivers.

Unlike the crtc helpers, it is intended that the atomic helpers can
be used piecemeal by the drivers, either using all or overriding
parts as needed.

A naive driver, with no special constraints or hw support for atomic
updates may simply add the following to their driver struct:

.atomic_begin = drm_atomic_helper_begin,
.atomic_set_event = drm_atomic_helper_set_event,
.atomic_check = drm_atomic_helper_check,
.atomic_commit= drm_atomic_helper_commit,
.atomic_end   = drm_atomic_helper_end,
.atomic_helpers   = _atomic_helper_funcs,

In addition, if you're plane/crtc doesn't already have it's own
custom properties, then add to your plane/crtc_funcs:

.set_property = drm_atomic_helper_{plane,crtc}_set_property,

A driver which can have (for example) conflicting modes across
multiple crtcs (for example, bandwidth limitations or clock/pll
configuration restrictions), can wrap drm_atomic_helper_check()
with their own driver specific .atomic_check() function.

A driver which can support true atomic updates can wrap
drm_atomic_helper_commit().

A driver with custom properties should override the appropriate
get_state(), check_state(), and commit_state() functions in
.atomic_helpers if it uses the drm-atomic-helpers.  Otherwise it
is free to use _atomic_helper_funcs as-is.


Rob Clark (11):
  drm: add atomic fxns
  drm: convert crtc to ww_mutex
  drm: add object property type
  drm: add signed-range property type
  drm: helpers to find mode objects
  drm: split propvals out and blob property support
  drm: convert plane to properties/state
  drm: convert crtc to properties/state
  drm: push locking down into restore_fbdev_mode
  drm/msm: add atomic support
  HACK: drm: allow FB's in drm_mode_object_find

Ville Syrj?l? (3):
  drm: Allow drm_mode_object_find() to look up an object of any type
  drm: Refactor object property check code
  drm: Atomic modeset ioctl

 drivers/gpu/drm/Makefile|3 +-
 drivers/gpu/drm/ast/ast_drv.c   |6 +
 drivers/gpu/drm/ast/ast_drv.h   |1 +
 drivers/gpu/drm/ast/ast_mode.c  |1 +
 drivers/gpu/drm/cirrus/cirrus_drv.c |6 +
 drivers/gpu/drm/cirrus/cirrus_drv.h |1 +
 drivers/gpu/drm/cirrus/cirrus_mode.c|1 +
 drivers/gpu/drm/drm_atomic_helper.c |  696 
 drivers/gpu/drm/drm_crtc.c  | 1630 +++
 drivers/gpu/drm/drm_drv.c   |1 +
 drivers/gpu/drm/drm_fb_cma_helper.c |9 +-
 drivers/gpu/drm/drm_fb_helper.c |   28 +-
 drivers/gpu/drm/exynos/exynos_drm_crtc.c|   15 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.c |7 +
 drivers/gpu/drm/exynos/exynos_drm_encoder.c |6 +-
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c   |4 +-
 drivers/gpu/drm/exynos/exynos_drm_plane.c   |   19 +-
 drivers/gpu/drm/gma500/cdv_intel_crt.c  |4 +-
 drivers/gpu/drm/gma500/cdv_intel_display.c  |1 +
 drivers/gpu/drm/gma500/cdv_intel_dp.c   |7 +-
 drivers/gpu/drm/gma500/cdv_intel_hdmi.c |7 +-
 drivers/gpu/drm/gma500/cdv_intel_lvds.c |   10 +-
 drivers/gpu/drm/gma500/mdfld_dsi_output.c   |   12 +-
 drivers/gpu/drm/gma500/psb_drv.c|   11 +-
 drivers/gpu/drm/gma500/psb_drv.h|1 +
 drivers/gpu/drm/gma500/psb_intel_display.c  |1 +

[i915] BUG: Bad page state in process Xorg

2013-11-25 Thread Rob Clark

oh, hmm.. are you importing buffers from i915?  It looks like this part:

- if (obj->base.import_attach) {
- drm_free_large(obj->pages);
- obj->pages = NULL;
- return;
- }

should not have been removed from udl_gem_put_pages()..

BR,
-R

On Mon, Nov 25, 2013 at 8:17 AM,   wrote:
> Hi,
>
> It turns out that this seems to be a bug in udl DRM driver.
>
> I bisected the problem to this patch:
>
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/udl?id=5dc9e1e87229cb786a5bb58ddd0d60fee6eb4641
>
> With kind regards
> Thomas
>
> Am 22.11.2013 17:18 schrieb Daniel Vetter :
>>
>> On Fri, Nov 22, 2013 at 4:54 PM, Thomas Meyer  wrote:
>> >> Am 22.11.2013 um 11:55 schrieb Daniel Vetter :
>> >>
>> >> On Fri, Nov 22, 2013 at 11:36 AM, Dave Airlie  wrote:
>>  Hi,
>> >>>
>> >>> cc'ing mailing list,
>> >>>
>> >>> Daniel any ideas?
>> >>
>> >> Nope, not really :( And no ideas how to triage this further - if it
>> >> takes 9 days to hit it eventually we'll have a real hard time. Or does
>> >> this happen even after just a short X run?
>> >
>> > Seems to happen every time while stopping the x server. Also after a short 
>> > run time.
>> >
>> > The current fedora 3.11 kernel doesn't show this bug. I'm using fedora 19, 
>> > with a self compiled kernel.
>> >
>> > I did turn on config-debug-pagealloc but this didn't show any wrongness.
>>
>> In that case I think the bisect is the fastest way to insight - atm
>> I'm really at loss what could be wrong here.
>> -Daniel
>> --
>> Daniel Vetter
>> Software Engineer, Intel Corporation
>> +41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Bug 68224] [radeonsi] Serious Sam3 is segfaulting (LLVM assert)

2013-11-25 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #29 from Alexandre Demers  ---
may be related to bug 71859

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

[Bug 71859] texelFetch segfault in libLLVM-3.3.so (on Cayman)

2013-11-25 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #9 from Alexandre Demers  ---
May be related to bug 68224

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

[Bug 69723] GPU lockups with kernel 3.11.0 / 3.12-rc1 when dpm=1 on r600g (Cayman)

2013-11-25 Thread bugzilla-dae...@freedesktop.org

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

Alexandre Demers  changed:

   What|Removed |Added

Summary|GPU lockups with kernel |GPU lockups with kernel
   |3.11.0 / 3.12-rc1 (with bug |3.11.0 / 3.12-rc1 when
   |68235's patches applied)|dpm=1 on r600g (Cayman)
   |when dpm=1 on r600g |
   |(Cayman)|

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

[Bug 70391] "atombios stuck executing D1FC" when switching back from tty to X

2013-11-25 Thread bugzilla-dae...@freedesktop.org

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

Jose P.  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Jose P.  ---
It's been fixed (I'm using oibaf's PPA + 3.13-rc0. I don't know the patch that
fixed it)
Closing :)

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

90 matches

Mail list logo