[PATCH 2/6] shm: add sealing API

[David Herrmann]

Hi

On Fri, Apr 11, 2014 at 11:36 PM, Andy Lutomirski  
wrote:
> A quick grep of the kernel tree finds exactly zero code paths
> incrementing i_mmap_writable outside of mmap and fork.
>
> Or do you mean a different kind of write ref?  What am I missing here?

Sorry, I meant i_writecount.

Thanks
David

[PATCH] drm: Provide drm_set_busid() fallback

[David Herrmann]

Hi

On Fri, Apr 11, 2014 at 7:43 PM, Daniel Vetter  wrote:
> Hm, my plan was actually to just provide a drm_dev_setunique to drivers so
> that they can set whatever their userspace wants, and then have no
> set_busid implementation here at all for !pci. Some userspace at least
> uses the unique thing to match for the driver, so we need to do the usual
> bending over backwards to keep it consistent.

What's the different between a hard-coded per-driver string and
dev_name()? I mean, doesn't the device name include the driver string?
Or do drivers require more fine-grained naming? Like chipset-specific
suffixes/prefixes in the busid?

Anyway, I'm fine with both and really like the approach of killing of
drm_bus. So all acked-by me.

Thanks
David

[PATCH 18/18] drm/: don't set driver->dev_priv_size to 0

[Daniel Vetter]

Especially not on modesetting drivers - this is used to size
the driver private structure for legacy drm buffers.

Reviewed-by: Damien Lespiau 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/ast/ast_drv.c   | 1 -
 drivers/gpu/drm/qxl/qxl_drv.c   | 1 -
 drivers/gpu/drm/radeon/radeon_drv.c | 1 -
 3 files changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c
index 5137f15dba19..2ba39ac7d222 100644
--- a/drivers/gpu/drm/ast/ast_drv.c
+++ b/drivers/gpu/drm/ast/ast_drv.c
@@ -198,7 +198,6 @@ static const struct file_operations ast_fops = {

 static struct drm_driver driver = {
.driver_features = DRIVER_MODESET | DRIVER_GEM,
-   .dev_priv_size = 0,

.load = ast_driver_load,
.unload = ast_driver_unload,
diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
index fee8748bdca5..6e936634d65c 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.c
+++ b/drivers/gpu/drm/qxl/qxl_drv.c
@@ -214,7 +214,6 @@ static struct pci_driver qxl_pci_driver = {
 static struct drm_driver qxl_driver = {
.driver_features = DRIVER_GEM | DRIVER_MODESET |
   DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED,
-   .dev_priv_size = 0,
.load = qxl_driver_load,
.unload = qxl_driver_unload,

diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
b/drivers/gpu/drm/radeon/radeon_drv.c
index d0eba48dd74e..855ad16101c6 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -535,7 +535,6 @@ static struct drm_driver kms_driver = {
DRIVER_USE_AGP |
DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM |
DRIVER_PRIME | DRIVER_RENDER,
-   .dev_priv_size = 0,
.load = radeon_driver_load_kms,
.open = radeon_driver_open_kms,
.preclose = radeon_driver_preclose_kms,
-- 
1.8.5.2

[PATCH 17/18] drm: Remove dev->kdriver

[Daniel Vetter]

With the last patch to ditch the ->get_name callbacks the last
user is now gone.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_pci.c  | 1 -
 drivers/gpu/drm/drm_platform.c | 1 -
 drivers/gpu/drm/drm_usb.c  | 1 -
 include/drm/drmP.h | 5 -
 4 files changed, 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index 262f1ca07a73..112203e7ae49 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -365,7 +365,6 @@ int drm_pci_init(struct drm_driver *driver, struct 
pci_driver *pdriver)

DRM_DEBUG("\n");

-   driver->kdriver.pci = pdriver;
driver->bus = &drm_pci_bus;

if (driver->driver_features & DRIVER_MODESET)
diff --git a/drivers/gpu/drm/drm_platform.c b/drivers/gpu/drm/drm_platform.c
index c7ec27bbe7c6..234e0bc1ae51 100644
--- a/drivers/gpu/drm/drm_platform.c
+++ b/drivers/gpu/drm/drm_platform.c
@@ -121,7 +121,6 @@ int drm_platform_init(struct drm_driver *driver, struct 
platform_device *platfor
 {
DRM_DEBUG("\n");

-   driver->kdriver.platform_device = platform_device;
driver->bus = &drm_platform_bus;
return drm_get_platform_dev(platform_device, driver);
 }
diff --git a/drivers/gpu/drm/drm_usb.c b/drivers/gpu/drm/drm_usb.c
index fae4aa4e1426..c6c7c29ad46f 100644
--- a/drivers/gpu/drm/drm_usb.c
+++ b/drivers/gpu/drm/drm_usb.c
@@ -51,7 +51,6 @@ int drm_usb_init(struct drm_driver *driver, struct usb_driver 
*udriver)
int res;
DRM_DEBUG("\n");

-   driver->kdriver.usb = udriver;
driver->bus = &drm_usb_bus;

res = usb_register(udriver);
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 2dd68ef22818..c4272acaac8f 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -963,11 +963,6 @@ struct drm_driver {
const struct drm_ioctl_desc *ioctls;
int num_ioctls;
const struct file_operations *fops;
-   union {
-   struct pci_driver *pci;
-   struct platform_device *platform_device;
-   struct usb_driver *usb;
-   } kdriver;
struct drm_bus *bus;

/* List of devices hanging off this driver with stealth attach. */
-- 
1.8.5.2

[PATCH 16/18] drm: remove drm_bus->get_name

[Daniel Vetter]

The only user is the info debugfs file, so we only need something
human readable. Now for both pci and platform devices we've used the
name of the underlying device driver, which matches the name of the
drm driver in all cases. So we can just use that instead.

The exception is usb, which used a generic "USB". Not to harmful with
just one usb driver, but better to use "udl", too.

With that converted we can rip out all the ->get_name implementations.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_info.c | 6 ++
 drivers/gpu/drm/drm_pci.c  | 7 ---
 drivers/gpu/drm/drm_platform.c | 6 --
 drivers/gpu/drm/drm_usb.c  | 6 --
 include/drm/drmP.h | 1 -
 5 files changed, 2 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/drm_info.c b/drivers/gpu/drm/drm_info.c
index 7473035dd28b..86feedd5e6f6 100644
--- a/drivers/gpu/drm/drm_info.c
+++ b/drivers/gpu/drm/drm_info.c
@@ -47,18 +47,16 @@ int drm_name_info(struct seq_file *m, void *data)
struct drm_minor *minor = node->minor;
struct drm_device *dev = minor->dev;
struct drm_master *master = minor->master;
-   const char *bus_name;
if (!master)
return 0;

-   bus_name = dev->driver->bus->get_name(dev);
if (master->unique) {
seq_printf(m, "%s %s %s\n",
-  bus_name,
+  dev->driver->name,
   dev_name(dev->dev), master->unique);
} else {
seq_printf(m, "%s %s\n",
-  bus_name, dev_name(dev->dev));
+  dev->driver->name, dev_name(dev->dev));
}
return 0;
 }
diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index da86ef8d531a..262f1ca07a73 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -137,12 +137,6 @@ static int drm_get_pci_domain(struct drm_device *dev)
return pci_domain_nr(dev->pdev->bus);
 }

-static const char *drm_pci_get_name(struct drm_device *dev)
-{
-   struct pci_driver *pdriver = dev->driver->kdriver.pci;
-   return pdriver->name;
-}
-
 static int drm_pci_set_busid(struct drm_device *dev, struct drm_master *master)
 {
int len, ret;
@@ -288,7 +282,6 @@ void drm_pci_agp_destroy(struct drm_device *dev)
 }

 static struct drm_bus drm_pci_bus = {
-   .get_name = drm_pci_get_name,
.set_busid = drm_pci_set_busid,
 };

diff --git a/drivers/gpu/drm/drm_platform.c b/drivers/gpu/drm/drm_platform.c
index b97b11ea2dc4..c7ec27bbe7c6 100644
--- a/drivers/gpu/drm/drm_platform.c
+++ b/drivers/gpu/drm/drm_platform.c
@@ -68,11 +68,6 @@ err_free:
return ret;
 }

-static const char *drm_platform_get_name(struct drm_device *dev)
-{
-   return dev->platformdev->name;
-}
-
 static int drm_platform_set_busid(struct drm_device *dev, struct drm_master 
*master)
 {
int len, ret, id;
@@ -107,7 +102,6 @@ err:
 }

 static struct drm_bus drm_platform_bus = {
-   .get_name = drm_platform_get_name,
.set_busid = drm_platform_set_busid,
 };

diff --git a/drivers/gpu/drm/drm_usb.c b/drivers/gpu/drm/drm_usb.c
index abdc265c9cc8..fae4aa4e1426 100644
--- a/drivers/gpu/drm/drm_usb.c
+++ b/drivers/gpu/drm/drm_usb.c
@@ -36,11 +36,6 @@ err_free:
 }
 EXPORT_SYMBOL(drm_get_usb_dev);

-static const char *drm_usb_get_name(struct drm_device *dev)
-{
-   return "USB";
-}
-
 static int drm_usb_set_busid(struct drm_device *dev,
   struct drm_master *master)
 {
@@ -48,7 +43,6 @@ static int drm_usb_set_busid(struct drm_device *dev,
 }

 static struct drm_bus drm_usb_bus = {
-   .get_name = drm_usb_get_name,
.set_busid = drm_usb_set_busid,
 };

diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 9d8c690732cf..2dd68ef22818 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -726,7 +726,6 @@ struct drm_master {
 #define DRM_SCANOUTPOS_ACCURATE (1 << 2)

 struct drm_bus {
-   const char *(*get_name)(struct drm_device *dev);
int (*set_busid)(struct drm_device *dev, struct drm_master *master);
 };

-- 
1.8.5.2

[PATCH 15/18] drm: rip out dev->devname

[Daniel Vetter]

This was only ever used to pretty-print the irq driver name. And on
kms systems due to set_version bonghits we never set up the prettier
name, ever. Which make this a bit pointless.

Also, we can always dig out the driver-instance/irq relationship
through other means, so this isn't that useful. So just rip it out to
simplify the set_version/set_busid insanity a bit.

Also delete the temporary busname from drm_pci_set_busid, it's now
unused.

v2: Rebase on top of the new host1x drm_bus for tegra.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_ioctl.c|  3 ---
 drivers/gpu/drm/drm_irq.c  |  8 +---
 drivers/gpu/drm/drm_pci.c  | 25 -
 drivers/gpu/drm/drm_platform.c | 11 ---
 drivers/gpu/drm/drm_stub.c |  5 -
 drivers/gpu/drm/tegra/bus.c| 10 --
 include/drm/drmP.h |  1 -
 7 files changed, 1 insertion(+), 62 deletions(-)

diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 5aea5b57ba4b..2dd3a6d8382b 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -72,9 +72,6 @@ static void
 drm_unset_busid(struct drm_device *dev,
struct drm_master *master)
 {
-   kfree(dev->devname);
-   dev->devname = NULL;
-
kfree(master->unique);
master->unique = NULL;
master->unique_len = 0;
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 1259e3db6d62..dd695f9c2b89 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -246,7 +246,6 @@ int drm_irq_install(struct drm_device *dev, int irq)
 {
int ret;
unsigned long sh_flags = 0;
-   char *irqname;

if (!drm_core_check_feature(dev, DRIVER_HAVE_IRQ))
return -EINVAL;
@@ -272,13 +271,8 @@ int drm_irq_install(struct drm_device *dev, int irq)
if (drm_core_check_feature(dev, DRIVER_IRQ_SHARED))
sh_flags = IRQF_SHARED;

-   if (dev->devname)
-   irqname = dev->devname;
-   else
-   irqname = dev->driver->name;
-
ret = request_irq(dev->irq, dev->driver->irq_handler,
- sh_flags, irqname, dev);
+ sh_flags, dev->driver->name, dev);

if (ret < 0) {
dev->irq_enabled = false;
diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index 0fa42072262b..da86ef8d531a 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -146,7 +146,6 @@ static const char *drm_pci_get_name(struct drm_device *dev)
 static int drm_pci_set_busid(struct drm_device *dev, struct drm_master *master)
 {
int len, ret;
-   struct pci_driver *pdriver = dev->driver->kdriver.pci;
master->unique_len = 40;
master->unique_size = master->unique_len;
master->unique = kmalloc(master->unique_size, GFP_KERNEL);
@@ -168,18 +167,6 @@ static int drm_pci_set_busid(struct drm_device *dev, 
struct drm_master *master)
} else
master->unique_len = len;

-   dev->devname =
-   kmalloc(strlen(pdriver->name) +
-   master->unique_len + 2, GFP_KERNEL);
-
-   if (dev->devname == NULL) {
-   ret = -ENOMEM;
-   goto err;
-   }
-
-   sprintf(dev->devname, "%s@%s", pdriver->name,
-   master->unique);
-
return 0;
 err:
return ret;
@@ -190,7 +177,6 @@ int drm_pci_set_unique(struct drm_device *dev,
   struct drm_unique *u)
 {
int domain, bus, slot, func, ret;
-   const char *bus_name;

master->unique_len = u->unique_len;
master->unique_size = u->unique_len + 1;
@@ -207,17 +193,6 @@ int drm_pci_set_unique(struct drm_device *dev,

master->unique[master->unique_len] = '\0';

-   bus_name = dev->driver->bus->get_name(dev);
-   dev->devname = kmalloc(strlen(bus_name) +
-  strlen(master->unique) + 2, GFP_KERNEL);
-   if (!dev->devname) {
-   ret = -ENOMEM;
-   goto err;
-   }
-
-   sprintf(dev->devname, "%s@%s", bus_name,
-   master->unique);
-
/* Return error if the busid submitted doesn't match the device's actual
 * busid.
 */
diff --git a/drivers/gpu/drm/drm_platform.c b/drivers/gpu/drm/drm_platform.c
index 5b918212b1c3..b97b11ea2dc4 100644
--- a/drivers/gpu/drm/drm_platform.c
+++ b/drivers/gpu/drm/drm_platform.c
@@ -101,17 +101,6 @@ static int drm_platform_set_busid(struct drm_device *dev, 
struct drm_master *mas
goto err;
}

-   dev->devname =
-   kmalloc(strlen(dev->platformdev->name) +
-   master->unique_len + 2, GFP_KERNEL);
-
-   if (dev->devname == NULL) {
-   ret = -ENOMEM;
-   goto err;
-   }
-
-   sprintf(dev->devname, "%s@%s", dev->platformdev->name,
-   master->unique);
return 0;
 err:
   

[PATCH 14/18] drm: inline drm_pci_set_unique

[Daniel Vetter]

This is only used for drm versions 1.0, and kms drivers have never
been there. So we can appropriately restrict this to legacy and hence
pci devices and inline everything.

v2: Make the dummy function actually return something, caught by Wu
Fengguang's 0-day tester.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_ioctl.c | 10 +++---
 drivers/gpu/drm/drm_pci.c   | 14 ++
 include/drm/drmP.h  |  5 +++--
 3 files changed, 20 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 93a42040bedb..5aea5b57ba4b 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -93,7 +93,8 @@ drm_unset_busid(struct drm_device *dev,
  * Copies the bus id from userspace into drm_device::unique, and verifies that
  * it matches the device this DRM is attached to (EINVAL otherwise).  
Deprecated
  * in interface version 1.1 and will return EBUSY when setversion has requested
- * version 1.1 or greater.
+ * version 1.1 or greater. Also note that KMS is all version 1.1 and later and
+ * UMS was only ever support on pci devices.
  */
 int drm_setunique(struct drm_device *dev, void *data,
  struct drm_file *file_priv)
@@ -108,10 +109,13 @@ int drm_setunique(struct drm_device *dev, void *data,
if (!u->unique_len || u->unique_len > 1024)
return -EINVAL;

-   if (!dev->driver->bus->set_unique)
+   if (drm_core_check_feature(dev, DRIVER_MODESET))
+   return 0;
+
+   if (WARN_ON(!dev->pdev))
return -EINVAL;

-   ret = dev->driver->bus->set_unique(dev, master, u);
+   ret = drm_pci_set_unique(dev, master, u);
if (ret)
goto err;

diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index 7d388d188c4c..0fa42072262b 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -185,9 +185,9 @@ err:
return ret;
 }

-static int drm_pci_set_unique(struct drm_device *dev,
- struct drm_master *master,
- struct drm_unique *u)
+int drm_pci_set_unique(struct drm_device *dev,
+  struct drm_master *master,
+  struct drm_unique *u)
 {
int domain, bus, slot, func, ret;
const char *bus_name;
@@ -315,7 +315,6 @@ void drm_pci_agp_destroy(struct drm_device *dev)
 static struct drm_bus drm_pci_bus = {
.get_name = drm_pci_get_name,
.set_busid = drm_pci_set_busid,
-   .set_unique = drm_pci_set_unique,
 };

 /**
@@ -482,6 +481,13 @@ int drm_irq_by_busid(struct drm_device *dev, void *data,
 {
return -EINVAL;
 }
+
+int drm_pci_set_unique(struct drm_device *dev,
+  struct drm_master *master,
+  struct drm_unique *u)
+{
+   return -EINVAL;
+}
 #endif

 EXPORT_SYMBOL(drm_pci_init);
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index f62891998388..5333659d4d0e 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -728,8 +728,6 @@ struct drm_master {
 struct drm_bus {
const char *(*get_name)(struct drm_device *dev);
int (*set_busid)(struct drm_device *dev, struct drm_master *master);
-   int (*set_unique)(struct drm_device *dev, struct drm_master *master,
- struct drm_unique *unique);
 };

 /**
@@ -1511,6 +1509,9 @@ extern drm_dma_handle_t *drm_pci_alloc(struct drm_device 
*dev, size_t size,
   size_t align);
 extern void __drm_pci_free(struct drm_device *dev, drm_dma_handle_t * dmah);
 extern void drm_pci_free(struct drm_device *dev, drm_dma_handle_t * dmah);
+extern int drm_pci_set_unique(struct drm_device *dev,
+ struct drm_master *master,
+ struct drm_unique *u);

   /* sysfs support (drm_sysfs.c) */
 struct drm_sysfs_class;
-- 
1.8.5.2

[PATCH 13/18] drm: remove bus->get_irq implementations

[Daniel Vetter]

Now that they're all unused we can get rid of them, including the
dummy version in drm_usb.c.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_pci.c  | 6 --
 drivers/gpu/drm/drm_platform.c | 6 --
 drivers/gpu/drm/drm_usb.c  | 6 --
 include/drm/drmP.h | 1 -
 4 files changed, 19 deletions(-)

diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index ad2fc48d0f0b..7d388d188c4c 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -137,11 +137,6 @@ static int drm_get_pci_domain(struct drm_device *dev)
return pci_domain_nr(dev->pdev->bus);
 }

-static int drm_pci_get_irq(struct drm_device *dev)
-{
-   return dev->pdev->irq;
-}
-
 static const char *drm_pci_get_name(struct drm_device *dev)
 {
struct pci_driver *pdriver = dev->driver->kdriver.pci;
@@ -318,7 +313,6 @@ void drm_pci_agp_destroy(struct drm_device *dev)
 }

 static struct drm_bus drm_pci_bus = {
-   .get_irq = drm_pci_get_irq,
.get_name = drm_pci_get_name,
.set_busid = drm_pci_set_busid,
.set_unique = drm_pci_set_unique,
diff --git a/drivers/gpu/drm/drm_platform.c b/drivers/gpu/drm/drm_platform.c
index 5cd8c695824f..5b918212b1c3 100644
--- a/drivers/gpu/drm/drm_platform.c
+++ b/drivers/gpu/drm/drm_platform.c
@@ -68,11 +68,6 @@ err_free:
return ret;
 }

-static int drm_platform_get_irq(struct drm_device *dev)
-{
-   return platform_get_irq(dev->platformdev, 0);
-}
-
 static const char *drm_platform_get_name(struct drm_device *dev)
 {
return dev->platformdev->name;
@@ -123,7 +118,6 @@ err:
 }

 static struct drm_bus drm_platform_bus = {
-   .get_irq = drm_platform_get_irq,
.get_name = drm_platform_get_name,
.set_busid = drm_platform_set_busid,
 };
diff --git a/drivers/gpu/drm/drm_usb.c b/drivers/gpu/drm/drm_usb.c
index ed60f887c805..abdc265c9cc8 100644
--- a/drivers/gpu/drm/drm_usb.c
+++ b/drivers/gpu/drm/drm_usb.c
@@ -36,11 +36,6 @@ err_free:
 }
 EXPORT_SYMBOL(drm_get_usb_dev);

-static int drm_usb_get_irq(struct drm_device *dev)
-{
-   return 0;
-}
-
 static const char *drm_usb_get_name(struct drm_device *dev)
 {
return "USB";
@@ -53,7 +48,6 @@ static int drm_usb_set_busid(struct drm_device *dev,
 }

 static struct drm_bus drm_usb_bus = {
-   .get_irq = drm_usb_get_irq,
.get_name = drm_usb_get_name,
.set_busid = drm_usb_set_busid,
 };
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index da28f49d7950..f62891998388 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -726,7 +726,6 @@ struct drm_master {
 #define DRM_SCANOUTPOS_ACCURATE (1 << 2)

 struct drm_bus {
-   int (*get_irq)(struct drm_device *dev);
const char *(*get_name)(struct drm_device *dev);
int (*set_busid)(struct drm_device *dev, struct drm_master *master);
int (*set_unique)(struct drm_device *dev, struct drm_master *master,
-- 
1.8.5.2

[PATCH 12/18] drm: pass the irq explicitly to drm_irq_install

[Daniel Vetter]

Unfortunately this requires a drm-wide change, and I didn't see a sane
way around that. Luckily it's fairly simple, we just need to inline
the respective get_irq implementation from either drm_pci.c or
drm_platform.c.

With that we can now also remove drm_dev_to_irq from drm_irq.c.

Signed-off-by: Daniel Vetter 
---
 Documentation/DocBook/drm.tmpl   | 10 +-
 drivers/gpu/drm/armada/armada_drv.c  |  2 +-
 drivers/gpu/drm/drm_irq.c| 13 +++--
 drivers/gpu/drm/gma500/psb_drv.c |  2 +-
 drivers/gpu/drm/i915/i915_dma.c  |  2 +-
 drivers/gpu/drm/i915/i915_drv.c  |  4 ++--
 drivers/gpu/drm/i915/i915_gem.c  |  2 +-
 drivers/gpu/drm/msm/msm_drv.c|  2 +-
 drivers/gpu/drm/qxl/qxl_irq.c|  2 +-
 drivers/gpu/drm/radeon/radeon_irq_kms.c  |  2 +-
 drivers/gpu/drm/shmobile/shmob_drm_drv.c |  2 +-
 drivers/gpu/drm/tilcdc/tilcdc_drv.c  |  2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c  |  2 +-
 include/drm/drmP.h   |  2 +-
 14 files changed, 17 insertions(+), 32 deletions(-)

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 702c4474919c..039ac10d7584 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -342,21 +342,13 @@ char *date;
 
   Managed IRQ Registration
   
-Both the drm_irq_install and
-   drm_irq_uninstall functions get the device IRQ 
by
-   calling drm_dev_to_irq. This inline function 
will
-   call a bus-specific operation to retrieve the IRQ number. For 
platform
-   devices, platform_get_irq(..., 0) is used to
-   retrieve the IRQ number.
-  
-  
 drm_irq_install starts by calling the
 irq_preinstall driver operation. The 
operation
 is optional and must make sure that the interrupt will not get 
fired by
 clearing all pending interrupt flags or disabling the interrupt.
   
   
-The IRQ will then be requested by a call to
+The passed-in IRQ will then be requested by a call to
 request_irq. If the DRIVER_IRQ_SHARED driver
 feature flag is set, a shared (IRQF_SHARED) IRQ handler will be
 requested.
diff --git a/drivers/gpu/drm/armada/armada_drv.c 
b/drivers/gpu/drm/armada/armada_drv.c
index 32982da82694..567cfbde0883 100644
--- a/drivers/gpu/drm/armada/armada_drv.c
+++ b/drivers/gpu/drm/armada/armada_drv.c
@@ -173,7 +173,7 @@ static int armada_drm_load(struct drm_device *dev, unsigned 
long flags)
if (ret)
goto err_kms;

-   ret = drm_irq_install(dev);
+   ret = drm_irq_install(dev, platform_get_irq(dev->platformdev, 0));
if (ret)
goto err_kms;

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index a83b037f5615..1259e3db6d62 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -233,11 +233,6 @@ static void drm_irq_vgaarb_nokms(void *cookie, bool state)
}
 }

-static inline int drm_dev_to_irq(struct drm_device *dev)
-{
-   return dev->driver->bus->get_irq(dev);
-}
-
 /**
  * Install IRQ handler.
  *
@@ -247,14 +242,12 @@ static inline int drm_dev_to_irq(struct drm_device *dev)
  * \c irq_preinstall() and \c irq_postinstall() functions
  * before and after the installation.
  */
-int drm_irq_install(struct drm_device *dev)
+int drm_irq_install(struct drm_device *dev, int irq)
 {
-   int ret, irq;
+   int ret;
unsigned long sh_flags = 0;
char *irqname;

-   irq = drm_dev_to_irq(dev);
-
if (!drm_core_check_feature(dev, DRIVER_HAVE_IRQ))
return -EINVAL;

@@ -400,7 +393,7 @@ int drm_control(struct drm_device *dev, void *data,
return -EINVAL;

mutex_lock(&dev->struct_mutex);
-   ret = drm_irq_install(dev);
+   ret = drm_irq_install(dev, irq);
mutex_unlock(&dev->struct_mutex);

return ret;
diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu/drm/gma500/psb_drv.c
index b686e56646eb..0a3101a3db19 100644
--- a/drivers/gpu/drm/gma500/psb_drv.c
+++ b/drivers/gpu/drm/gma500/psb_drv.c
@@ -354,7 +354,7 @@ static int psb_driver_load(struct drm_device *dev, unsigned 
long flags)
PSB_WVDC32(0x, PSB_INT_MASK_R);
spin_unlock_irqrestore(&dev_priv->irqmask_lock, irqflags);

-   drm_irq_install(dev);
+   drm_irq_install(dev, dev->pdev->irq);

dev->vblank_disable_allowed = true;
dev->max_vblank_count = 0xff; /* only 24 bits of frame count */
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index dcb67c6564dd..53765aa8fc4a 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1336,7 +1336,7 @@ static int i915_load_modeset_init(struct drm_device *dev)

intel_power_

[PATCH 11/18] drm/irq: Look up the pci irq directly in the drm_control ioctl

[Daniel Vetter]

It's only ever called for legacy drivers, which are all pci.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_irq.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 1c3b6229363d..a83b037f5615 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -377,7 +377,7 @@ int drm_control(struct drm_device *dev, void *data,
struct drm_file *file_priv)
 {
struct drm_control *ctl = data;
-   int ret = 0;
+   int ret = 0, irq;

/* if we haven't irq we fallback for compatibility reasons -
 * this used to be a separate function in drm_dma.h
@@ -393,8 +393,10 @@ int drm_control(struct drm_device *dev, void *data,

switch (ctl->func) {
case DRM_INST_HANDLER:
+   irq = dev->pdev->irq;
+
if (dev->if_version < DRM_IF_VERSION(1, 2) &&
-   ctl->irq != drm_dev_to_irq(dev))
+   ctl->irq != irq)
return -EINVAL;

mutex_lock(&dev->struct_mutex);
-- 
1.8.5.2

[PATCH 10/18] drm/irq: track the irq installed in drm_irq_install in dev->irq

[Daniel Vetter]

To get rid of the dev->bus->get_irq callback we need to pass in the
desired irq explicitly into drm_irq_install. To avoid having to do the
same for drm_irq_unistall just track it internally. That leaves
drivers with less room to botch things up.

v2: Add the hunk lost in an earlier patch to this one (Thierry).

Cc: Thierry Reding 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_irq.c | 18 +++---
 include/drm/drmP.h|  2 ++
 2 files changed, 13 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 330e85b19115..1c3b6229363d 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -249,14 +249,16 @@ static inline int drm_dev_to_irq(struct drm_device *dev)
  */
 int drm_irq_install(struct drm_device *dev)
 {
-   int ret;
+   int ret, irq;
unsigned long sh_flags = 0;
char *irqname;

+   irq = drm_dev_to_irq(dev);
+
if (!drm_core_check_feature(dev, DRIVER_HAVE_IRQ))
return -EINVAL;

-   if (drm_dev_to_irq(dev) == 0)
+   if (irq == 0)
return -EINVAL;

/* Driver must have been initialized */
@@ -267,7 +269,7 @@ int drm_irq_install(struct drm_device *dev)
return -EBUSY;
dev->irq_enabled = true;

-   DRM_DEBUG("irq=%d\n", drm_dev_to_irq(dev));
+   DRM_DEBUG("irq=%d\n", dev->irq);

/* Before installing handler */
if (dev->driver->irq_preinstall)
@@ -282,7 +284,7 @@ int drm_irq_install(struct drm_device *dev)
else
irqname = dev->driver->name;

-   ret = request_irq(drm_dev_to_irq(dev), dev->driver->irq_handler,
+   ret = request_irq(dev->irq, dev->driver->irq_handler,
  sh_flags, irqname, dev);

if (ret < 0) {
@@ -301,7 +303,9 @@ int drm_irq_install(struct drm_device *dev)
dev->irq_enabled = false;
if (!drm_core_check_feature(dev, DRIVER_MODESET))
vga_client_register(dev->pdev, NULL, NULL, NULL);
-   free_irq(drm_dev_to_irq(dev), dev);
+   free_irq(dev->irq, dev);
+   } else {
+   dev->irq = irq;
}

return ret;
@@ -344,7 +348,7 @@ int drm_irq_uninstall(struct drm_device *dev)
if (!irq_enabled)
return -EINVAL;

-   DRM_DEBUG("irq=%d\n", drm_dev_to_irq(dev));
+   DRM_DEBUG("irq=%d\n", dev->irq);

if (!drm_core_check_feature(dev, DRIVER_MODESET))
vga_client_register(dev->pdev, NULL, NULL, NULL);
@@ -352,7 +356,7 @@ int drm_irq_uninstall(struct drm_device *dev)
if (dev->driver->irq_uninstall)
dev->driver->irq_uninstall(dev);

-   free_irq(drm_dev_to_irq(dev), dev);
+   free_irq(dev->irq, dev);

return 0;
 }
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 8b23a34a103e..6f512cd97cd5 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1107,6 +1107,8 @@ struct drm_device {
/** \name Context support */
/*@{ */
bool irq_enabled;   /**< True if irq handler is enabled */
+   int irq;
+
__volatile__ long context_flag; /**< Context swapping flag */
int last_context;   /**< Last current context */
/*@} */
-- 
1.8.5.2

[PATCH 09/18] drm: rename dev->count_lock to dev->buf_lock

[Daniel Vetter]

Since really that's all it protects - legacy horror stories in
drm_bufs.c. Since I don't want to waste any more time on this I didn't
bother to actually look at what it protects in there, but it's at
least contained now.

v2: Move the spurious hunk to the right patch (Thierry).

Cc: Thierry Reding 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_bufs.c | 32 
 drivers/gpu/drm/drm_stub.c |  2 +-
 include/drm/drmP.h |  2 +-
 3 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index edec31fe3fed..ef7f0199a0f1 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -656,13 +656,13 @@ int drm_addbufs_agp(struct drm_device * dev, struct 
drm_buf_desc * request)
DRM_DEBUG("zone invalid\n");
return -EINVAL;
}
-   spin_lock(&dev->count_lock);
+   spin_lock(&dev->buf_lock);
if (dev->buf_use) {
-   spin_unlock(&dev->count_lock);
+   spin_unlock(&dev->buf_lock);
return -EBUSY;
}
atomic_inc(&dev->buf_alloc);
-   spin_unlock(&dev->count_lock);
+   spin_unlock(&dev->buf_lock);

mutex_lock(&dev->struct_mutex);
entry = &dma->bufs[order];
@@ -805,13 +805,13 @@ int drm_addbufs_pci(struct drm_device * dev, struct 
drm_buf_desc * request)
page_order = order - PAGE_SHIFT > 0 ? order - PAGE_SHIFT : 0;
total = PAGE_SIZE << page_order;

-   spin_lock(&dev->count_lock);
+   spin_lock(&dev->buf_lock);
if (dev->buf_use) {
-   spin_unlock(&dev->count_lock);
+   spin_unlock(&dev->buf_lock);
return -EBUSY;
}
atomic_inc(&dev->buf_alloc);
-   spin_unlock(&dev->count_lock);
+   spin_unlock(&dev->buf_lock);

mutex_lock(&dev->struct_mutex);
entry = &dma->bufs[order];
@@ -1015,13 +1015,13 @@ static int drm_addbufs_sg(struct drm_device * dev, 
struct drm_buf_desc * request
if (order < DRM_MIN_ORDER || order > DRM_MAX_ORDER)
return -EINVAL;

-   spin_lock(&dev->count_lock);
+   spin_lock(&dev->buf_lock);
if (dev->buf_use) {
-   spin_unlock(&dev->count_lock);
+   spin_unlock(&dev->buf_lock);
return -EBUSY;
}
atomic_inc(&dev->buf_alloc);
-   spin_unlock(&dev->count_lock);
+   spin_unlock(&dev->buf_lock);

mutex_lock(&dev->struct_mutex);
entry = &dma->bufs[order];
@@ -1175,7 +1175,7 @@ int drm_addbufs(struct drm_device *dev, void *data,
  * \param arg pointer to a drm_buf_info structure.
  * \return zero on success or a negative number on failure.
  *
- * Increments drm_device::buf_use while holding the drm_device::count_lock
+ * Increments drm_device::buf_use while holding the drm_device::buf_lock
  * lock, preventing of allocating more buffers after this call. Information
  * about each requested buffer is then copied into user space.
  */
@@ -1196,13 +1196,13 @@ int drm_infobufs(struct drm_device *dev, void *data,
if (!dma)
return -EINVAL;

-   spin_lock(&dev->count_lock);
+   spin_lock(&dev->buf_lock);
if (atomic_read(&dev->buf_alloc)) {
-   spin_unlock(&dev->count_lock);
+   spin_unlock(&dev->buf_lock);
return -EBUSY;
}
++dev->buf_use; /* Can't allocate more after this call */
-   spin_unlock(&dev->count_lock);
+   spin_unlock(&dev->buf_lock);

for (i = 0, count = 0; i < DRM_MAX_ORDER + 1; i++) {
if (dma->bufs[i].buf_count)
@@ -1381,13 +1381,13 @@ int drm_mapbufs(struct drm_device *dev, void *data,
if (!dma)
return -EINVAL;

-   spin_lock(&dev->count_lock);
+   spin_lock(&dev->buf_lock);
if (atomic_read(&dev->buf_alloc)) {
-   spin_unlock(&dev->count_lock);
+   spin_unlock(&dev->buf_lock);
return -EBUSY;
}
dev->buf_use++; /* Can't allocate more after this call */
-   spin_unlock(&dev->count_lock);
+   spin_unlock(&dev->buf_lock);

if (request->count >= dma->buf_count) {
if ((dev->agp && (dma->flags & _DRM_DMA_USE_AGP))
diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index 4c24c3ac1efa..5394b201c3d0 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -569,7 +569,7 @@ struct drm_device *drm_dev_alloc(struct drm_driver *driver,
INIT_LIST_HEAD(&dev->maplist);
INIT_LIST_HEAD(&dev->vblank_event_list);

-   spin_lock_init(&dev->count_lock);
+   spin_lock_init(&dev->buf_lock);
spin_lock_init(&dev->event_lock);
mutex_init(&dev->struct_mutex);
mutex_init(&dev->ctxlist_mutex);
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index bd16a4c8ece4..8b23a34a103e 100644
--- a/include/drm/drmP.h
+++ b/inc

[PATCH 08/18] drm: Rip out totally bogus vga_switcheroo->can_switch locking

[Daniel Vetter]

So I just wanted to add a new field to struct drm_device and
accidentally stumbled over something. According to comments
dev->open_count is protected by dev->count_lock, but that's totally
not the case. It's protected by drm_global_mutex.

Unfortunately the vga switcheroo callbacks took this comment at face
value. The problem is that we can't just take the drm_global_mutex
because:
- It would lead to a locking inversion with the driver load/unload
  paths.
- It wouldn't actually protect anything, for that we'd need to wrap
  the entire vga switcheroo code in the drm_global_mutex. And I'm not
  sure whether that would actually solve anything.

What we probably want is a try_to_grab_switcheroo reference kind of
thing which is used in the driver's ->open callback. Then we could
move all that ->can_switch madness into the vga switcheroo core where
it really belongs.

But since that would amount to real work take the easy way out and
just add a comment. It's definitely not going to make anything worse
since doing switcheroo state changes while restarting X just isn't
recommended. Even though the delayed switching code does exactly that.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_dma.c| 7 +--
 drivers/gpu/drm/nouveau/nouveau_vga.c  | 7 +--
 drivers/gpu/drm/radeon/radeon_device.c | 7 +--
 include/drm/drmP.h | 2 +-
 4 files changed, 16 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 4dff829c2d89..dcb67c6564dd 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1286,9 +1286,12 @@ static bool i915_switcheroo_can_switch(struct pci_dev 
*pdev)
struct drm_device *dev = pci_get_drvdata(pdev);
bool can_switch;

-   spin_lock(&dev->count_lock);
+   /*
+* FIXME: open_count is protected by drm_global_mutex but that would 
lead to
+* locking inversion with the driver load path. And the access here is
+* completely racy anyway. So don't bother with locking for now.
+*/
can_switch = (dev->open_count == 0);
-   spin_unlock(&dev->count_lock);
return can_switch;
 }

diff --git a/drivers/gpu/drm/nouveau/nouveau_vga.c 
b/drivers/gpu/drm/nouveau/nouveau_vga.c
index fb84da3cb50d..7b10c5a9196b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_vga.c
+++ b/drivers/gpu/drm/nouveau/nouveau_vga.c
@@ -66,9 +66,12 @@ nouveau_switcheroo_can_switch(struct pci_dev *pdev)
struct drm_device *dev = pci_get_drvdata(pdev);
bool can_switch;

-   spin_lock(&dev->count_lock);
+   /*
+* FIXME: open_count is protected by drm_global_mutex but that would 
lead to
+* locking inversion with the driver load path. And the access here is
+* completely racy anyway. So don't bother with locking for now.
+*/
can_switch = (dev->open_count == 0);
-   spin_unlock(&dev->count_lock);
return can_switch;
 }

diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index 835516d2d257..c9811d01a3c7 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1124,9 +1124,12 @@ static bool radeon_switcheroo_can_switch(struct pci_dev 
*pdev)
struct drm_device *dev = pci_get_drvdata(pdev);
bool can_switch;

-   spin_lock(&dev->count_lock);
+   /*
+* FIXME: open_count is protected by drm_global_mutex but that would 
lead to
+* locking inversion with the driver load path. And the access here is
+* completely racy anyway. So don't bother with locking for now.
+*/
can_switch = (dev->open_count == 0);
-   spin_unlock(&dev->count_lock);
return can_switch;
 }

diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 9f1fb8d36b67..bd16a4c8ece4 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1076,7 +1076,7 @@ struct drm_device {

/** \name Usage Counters */
/*@{ */
-   int open_count; /**< Outstanding files open */
+   int open_count; /**< Outstanding files open, protected 
by drm_global_lock. */
int buf_use;/**< Buffers in use -- cannot alloc */
atomic_t buf_alloc; /**< Buffer allocation in progress */
/*@} */
-- 
1.8.5.2

[PATCH 07/18] drm: kill drm_bus->bus_type

[Daniel Vetter]

Completely unused. Hooray, midlayer mistakes that didn't cause work to
undo!

v2: Rebase on top of the recent tegra changes which added a host1x drm
bus.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_pci.c  | 1 -
 drivers/gpu/drm/drm_platform.c | 1 -
 drivers/gpu/drm/drm_usb.c  | 1 -
 drivers/gpu/drm/tegra/bus.c| 1 -
 include/drm/drmP.h | 6 --
 5 files changed, 10 deletions(-)

diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index e8040e57cbbb..ad2fc48d0f0b 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -318,7 +318,6 @@ void drm_pci_agp_destroy(struct drm_device *dev)
 }

 static struct drm_bus drm_pci_bus = {
-   .bus_type = DRIVER_BUS_PCI,
.get_irq = drm_pci_get_irq,
.get_name = drm_pci_get_name,
.set_busid = drm_pci_set_busid,
diff --git a/drivers/gpu/drm/drm_platform.c b/drivers/gpu/drm/drm_platform.c
index 319ff5385601..5cd8c695824f 100644
--- a/drivers/gpu/drm/drm_platform.c
+++ b/drivers/gpu/drm/drm_platform.c
@@ -123,7 +123,6 @@ err:
 }

 static struct drm_bus drm_platform_bus = {
-   .bus_type = DRIVER_BUS_PLATFORM,
.get_irq = drm_platform_get_irq,
.get_name = drm_platform_get_name,
.set_busid = drm_platform_set_busid,
diff --git a/drivers/gpu/drm/drm_usb.c b/drivers/gpu/drm/drm_usb.c
index c3406aad2944..ed60f887c805 100644
--- a/drivers/gpu/drm/drm_usb.c
+++ b/drivers/gpu/drm/drm_usb.c
@@ -53,7 +53,6 @@ static int drm_usb_set_busid(struct drm_device *dev,
 }

 static struct drm_bus drm_usb_bus = {
-   .bus_type = DRIVER_BUS_USB,
.get_irq = drm_usb_get_irq,
.get_name = drm_usb_get_name,
.set_busid = drm_usb_set_busid,
diff --git a/drivers/gpu/drm/tegra/bus.c b/drivers/gpu/drm/tegra/bus.c
index 71cef5c13dc8..6916fa51cfa4 100644
--- a/drivers/gpu/drm/tegra/bus.c
+++ b/drivers/gpu/drm/tegra/bus.c
@@ -37,7 +37,6 @@ static int drm_host1x_set_busid(struct drm_device *dev,
 }

 static struct drm_bus drm_host1x_bus = {
-   .bus_type = DRIVER_BUS_HOST1X,
.set_busid = drm_host1x_set_busid,
 };

diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 41839ea0c1ee..9f1fb8d36b67 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -143,11 +143,6 @@ int drm_err(const char *func, const char *format, ...);
 #define DRIVER_PRIME   0x4000
 #define DRIVER_RENDER  0x8000

-#define DRIVER_BUS_PCI 0x1
-#define DRIVER_BUS_PLATFORM 0x2
-#define DRIVER_BUS_USB 0x3
-#define DRIVER_BUS_HOST1X 0x4
-
 /***/
 /** \name Begin the DRM... */
 /*@{*/
@@ -731,7 +726,6 @@ struct drm_master {
 #define DRM_SCANOUTPOS_ACCURATE (1 << 2)

 struct drm_bus {
-   int bus_type;
int (*get_irq)(struct drm_device *dev);
const char *(*get_name)(struct drm_device *dev);
int (*set_busid)(struct drm_device *dev, struct drm_master *master);
-- 
1.8.5.2

[PATCH 06/18] drm: remove drm_dev_to_irq from drivers

[Daniel Vetter]

Only used in some legacy pci drivers, and dereferncing the pci irq is
actually shorter ...

Since this removes all users for drm_dev_to_irq from the tree except
in drm_irq.c, move the inline helper in there. It'll disappear soon,
too.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_irq.c | 5 +
 drivers/gpu/drm/mga/mga_state.c   | 2 +-
 drivers/gpu/drm/r128/r128_state.c | 2 +-
 drivers/gpu/drm/radeon/radeon_state.c | 2 +-
 include/drm/drmP.h| 5 -
 5 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 1a6fc8fc0cd5..330e85b19115 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -233,6 +233,11 @@ static void drm_irq_vgaarb_nokms(void *cookie, bool state)
}
 }

+static inline int drm_dev_to_irq(struct drm_device *dev)
+{
+   return dev->driver->bus->get_irq(dev);
+}
+
 /**
  * Install IRQ handler.
  *
diff --git a/drivers/gpu/drm/mga/mga_state.c b/drivers/gpu/drm/mga/mga_state.c
index 314685b7f41f..3cb58df5237e 100644
--- a/drivers/gpu/drm/mga/mga_state.c
+++ b/drivers/gpu/drm/mga/mga_state.c
@@ -1020,7 +1020,7 @@ static int mga_getparam(struct drm_device *dev, void 
*data, struct drm_file *fil

switch (param->param) {
case MGA_PARAM_IRQ_NR:
-   value = drm_dev_to_irq(dev);
+   value = dev->pdev->irq;
break;
case MGA_PARAM_CARD_TYPE:
value = dev_priv->chipset;
diff --git a/drivers/gpu/drm/r128/r128_state.c 
b/drivers/gpu/drm/r128/r128_state.c
index e806dacd452f..97064dd434c2 100644
--- a/drivers/gpu/drm/r128/r128_state.c
+++ b/drivers/gpu/drm/r128/r128_state.c
@@ -1594,7 +1594,7 @@ static int r128_getparam(struct drm_device *dev, void 
*data, struct drm_file *fi

switch (param->param) {
case R128_PARAM_IRQ_NR:
-   value = drm_dev_to_irq(dev);
+   value = dev->pdev->irq;
break;
default:
return -EINVAL;
diff --git a/drivers/gpu/drm/radeon/radeon_state.c 
b/drivers/gpu/drm/radeon/radeon_state.c
index 956ab7f14e16..b576549fc783 100644
--- a/drivers/gpu/drm/radeon/radeon_state.c
+++ b/drivers/gpu/drm/radeon/radeon_state.c
@@ -3054,7 +3054,7 @@ static int radeon_cp_getparam(struct drm_device *dev, 
void *data, struct drm_fil
if ((dev_priv->flags & RADEON_FAMILY_MASK) >= CHIP_R600)
value = 0;
else
-   value = drm_dev_to_irq(dev);
+   value = dev->pdev->irq;
break;
case RADEON_PARAM_GART_BASE:
value = dev_priv->gart_vm_start;
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 6d7ca98d0143..41839ea0c1ee 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1185,11 +1185,6 @@ static __inline__ int drm_core_check_feature(struct 
drm_device *dev,
return ((dev->driver->driver_features & feature) ? 1 : 0);
 }

-static inline int drm_dev_to_irq(struct drm_device *dev)
-{
-   return dev->driver->bus->get_irq(dev);
-}
-
 static inline void drm_device_set_unplugged(struct drm_device *dev)
 {
smp_wmb();
-- 
1.8.5.2

[PATCH 05/18] drm/irq: remove cargo-culted locking from irq_install/unistall

[Daniel Vetter]

The dev->struct_mutex locking in drm_irq.c only protects
dev->irq_enabled. Which isn't really much at all and only prevents
especially nasty ums userspace from concurrently installing the
interrupt handling a few times. Or at least trying.

There are tons of unlocked readers of dev->irqs_enabled in the vblank
wait code (and by extension also in the pageflip code since that uses
the same vblank timestamp engine).

Real modesetting drivers should ensure that nothing can go haywire
with a sane setup teardown sequence. So we only really need this for
the drm_control ioctl, everywhere else this will just paper over
nastiness.

Note that drm/i915 is a bit specially due to the gem+ums combination.
So there we also need to properly protect the entervt and leavevt
ioctls. But it's definitely saner to do everything in one go than to
drop the lock in-between.

Finally there's the gpu reset code in drm/i915. That one's just race
(concurrent userspace calls to for vblank waits of pageflips could
spuriously fail). So wrap it up in with a nice comment since fixing
this is more involved.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_irq.c   | 30 +-
 drivers/gpu/drm/i915/i915_drv.c |  5 +
 drivers/gpu/drm/i915/i915_gem.c |  5 +++--
 3 files changed, 21 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 4b019646f556..1a6fc8fc0cd5 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -254,20 +254,13 @@ int drm_irq_install(struct drm_device *dev)
if (drm_dev_to_irq(dev) == 0)
return -EINVAL;

-   mutex_lock(&dev->struct_mutex);
-
/* Driver must have been initialized */
-   if (!dev->dev_private) {
-   mutex_unlock(&dev->struct_mutex);
+   if (!dev->dev_private)
return -EINVAL;
-   }

-   if (dev->irq_enabled) {
-   mutex_unlock(&dev->struct_mutex);
+   if (dev->irq_enabled)
return -EBUSY;
-   }
dev->irq_enabled = true;
-   mutex_unlock(&dev->struct_mutex);

DRM_DEBUG("irq=%d\n", drm_dev_to_irq(dev));

@@ -288,9 +281,7 @@ int drm_irq_install(struct drm_device *dev)
  sh_flags, irqname, dev);

if (ret < 0) {
-   mutex_lock(&dev->struct_mutex);
dev->irq_enabled = false;
-   mutex_unlock(&dev->struct_mutex);
return ret;
}

@@ -302,9 +293,7 @@ int drm_irq_install(struct drm_device *dev)
ret = dev->driver->irq_postinstall(dev);

if (ret < 0) {
-   mutex_lock(&dev->struct_mutex);
dev->irq_enabled = false;
-   mutex_unlock(&dev->struct_mutex);
if (!drm_core_check_feature(dev, DRIVER_MODESET))
vga_client_register(dev->pdev, NULL, NULL, NULL);
free_irq(drm_dev_to_irq(dev), dev);
@@ -330,10 +319,8 @@ int drm_irq_uninstall(struct drm_device *dev)
if (!drm_core_check_feature(dev, DRIVER_HAVE_IRQ))
return -EINVAL;

-   mutex_lock(&dev->struct_mutex);
irq_enabled = dev->irq_enabled;
dev->irq_enabled = false;
-   mutex_unlock(&dev->struct_mutex);

/*
 * Wake up any waiters so they don't hang.
@@ -381,6 +368,7 @@ int drm_control(struct drm_device *dev, void *data,
struct drm_file *file_priv)
 {
struct drm_control *ctl = data;
+   int ret = 0;

/* if we haven't irq we fallback for compatibility reasons -
 * this used to be a separate function in drm_dma.h
@@ -400,9 +388,17 @@ int drm_control(struct drm_device *dev, void *data,
ctl->irq != drm_dev_to_irq(dev))
return -EINVAL;

-   return drm_irq_install(dev);
+   mutex_lock(&dev->struct_mutex);
+   ret = drm_irq_install(dev);
+   mutex_unlock(&dev->struct_mutex);
+
+   return ret;
case DRM_UNINST_HANDLER:
-   return drm_irq_uninstall(dev);
+   mutex_lock(&dev->struct_mutex);
+   ret = drm_irq_uninstall(dev);
+   mutex_unlock(&dev->struct_mutex);
+
+   return ret;
default:
return -EINVAL;
}
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 82f4d1f47d3b..87ce105910f2 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -746,6 +746,11 @@ int i915_reset(struct drm_device *dev)
return ret;
}

+   /*
+* FIXME: This is horribly race against concurrent pageflip and
+* vblank wait ioctls since they can observe dev->irqs_disabled
+* being false when they shouldn't be able to.
+*/
drm_irq_uninstall(dev);
drm_irq_install(dev)

[PATCH 04/18] drm/irq: drm_control is a legacy ioctl, so pci devices only

[Daniel Vetter]

This just adds a correspdonding check, follow-up patches will exploit
this.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_irq.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index c02b602325cb..4b019646f556 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -386,22 +386,22 @@ int drm_control(struct drm_device *dev, void *data,
 * this used to be a separate function in drm_dma.h
 */

+   if (!drm_core_check_feature(dev, DRIVER_HAVE_IRQ))
+   return 0;
+   if (drm_core_check_feature(dev, DRIVER_MODESET))
+   return 0;
+   /* UMS was only ever support on pci devices. */
+   if (WARN_ON(!dev->pdev))
+   return -EINVAL;

switch (ctl->func) {
case DRM_INST_HANDLER:
-   if (!drm_core_check_feature(dev, DRIVER_HAVE_IRQ))
-   return 0;
-   if (drm_core_check_feature(dev, DRIVER_MODESET))
-   return 0;
if (dev->if_version < DRM_IF_VERSION(1, 2) &&
ctl->irq != drm_dev_to_irq(dev))
return -EINVAL;
+
return drm_irq_install(dev);
case DRM_UNINST_HANDLER:
-   if (!drm_core_check_feature(dev, DRIVER_HAVE_IRQ))
-   return 0;
-   if (drm_core_check_feature(dev, DRIVER_MODESET))
-   return 0;
return drm_irq_uninstall(dev);
default:
return -EINVAL;
-- 
1.8.5.2

[PATCH 03/18] drm/pci: fold in irq_by_busid support

[Daniel Vetter]

This is a ums-only ioctl, and we've only ever supported ums (at least
in upstream) on pci devices. So no point in keeping that piece of
legacy logic abstracted within the drm bus driver.

To keep things work without CONFIG_PCI also add a dummy ioctl.

v2: Block the irq_by_busid ioctl for modeset drivers.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_irq.c | 27 ---
 drivers/gpu/drm/drm_pci.c | 40 ++--
 include/drm/drmP.h|  1 -
 3 files changed, 38 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 7ef98c01c3d5..c02b602325cb 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -56,33 +56,6 @@
  */
 #define DRM_REDUNDANT_VBLIRQ_THRESH_NS 100

-/**
- * Get interrupt from bus id.
- *
- * \param inode device inode.
- * \param file_priv DRM file private.
- * \param cmd command.
- * \param arg user argument, pointing to a drm_irq_busid structure.
- * \return zero on success or a negative number on failure.
- *
- * Finds the PCI device with the specified bus id and gets its IRQ number.
- * This IOCTL is deprecated, and will now return EINVAL for any busid not equal
- * to that of the device that this DRM instance attached to.
- */
-int drm_irq_by_busid(struct drm_device *dev, void *data,
-struct drm_file *file_priv)
-{
-   struct drm_irq_busid *p = data;
-
-   if (!dev->driver->bus->irq_by_busid)
-   return -EINVAL;
-
-   if (!drm_core_check_feature(dev, DRIVER_HAVE_IRQ))
-   return -EINVAL;
-
-   return dev->driver->bus->irq_by_busid(dev, p);
-}
-
 /*
  * Clear vblank timestamp buffer for a crtc.
  */
diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index 9c696a5ad74d..e8040e57cbbb 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -247,7 +247,6 @@ err:
return ret;
 }

-
 static int drm_pci_irq_by_busid(struct drm_device *dev, struct drm_irq_busid 
*p)
 {
if ((p->busnum >> 8) != drm_get_pci_domain(dev) ||
@@ -262,6 +261,38 @@ static int drm_pci_irq_by_busid(struct drm_device *dev, 
struct drm_irq_busid *p)
return 0;
 }

+/**
+ * Get interrupt from bus id.
+ *
+ * \param inode device inode.
+ * \param file_priv DRM file private.
+ * \param cmd command.
+ * \param arg user argument, pointing to a drm_irq_busid structure.
+ * \return zero on success or a negative number on failure.
+ *
+ * Finds the PCI device with the specified bus id and gets its IRQ number.
+ * This IOCTL is deprecated, and will now return EINVAL for any busid not equal
+ * to that of the device that this DRM instance attached to.
+ */
+int drm_irq_by_busid(struct drm_device *dev, void *data,
+struct drm_file *file_priv)
+{
+   struct drm_irq_busid *p = data;
+
+   if (drm_core_check_feature(dev, DRIVER_MODESET))
+   return -EINVAL;
+
+   /* UMS was only ever support on pci devices. */
+   if (WARN_ON(!dev->pdev))
+   return -EINVAL;
+
+   if (!drm_core_check_feature(dev, DRIVER_HAVE_IRQ))
+   return -EINVAL;
+
+   return drm_pci_irq_by_busid(dev, p);
+}
+
+
 static void drm_pci_agp_init(struct drm_device *dev)
 {
if (drm_core_check_feature(dev, DRIVER_USE_AGP)) {
@@ -292,7 +323,6 @@ static struct drm_bus drm_pci_bus = {
.get_name = drm_pci_get_name,
.set_busid = drm_pci_set_busid,
.set_unique = drm_pci_set_unique,
-   .irq_by_busid = drm_pci_irq_by_busid,
 };

 /**
@@ -453,6 +483,12 @@ int drm_pci_init(struct drm_driver *driver, struct 
pci_driver *pdriver)
 }

 void drm_pci_agp_destroy(struct drm_device *dev) {}
+
+int drm_irq_by_busid(struct drm_device *dev, void *data,
+struct drm_file *file_priv)
+{
+   return -EINVAL;
+}
 #endif

 EXPORT_SYMBOL(drm_pci_init);
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index a7c2a862b4f4..6d7ca98d0143 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -737,7 +737,6 @@ struct drm_bus {
int (*set_busid)(struct drm_device *dev, struct drm_master *master);
int (*set_unique)(struct drm_device *dev, struct drm_master *master,
  struct drm_unique *unique);
-   int (*irq_by_busid)(struct drm_device *dev, struct drm_irq_busid *p);
 };

 /**
-- 
1.8.5.2

[PATCH 02/18] drm/irq: simplify irq checks in drm_wait_vblank

[Daniel Vetter]

Checking for both an irq number _and_ whether it's enabled is
redundant. Originally I've thought the drm_dev_to_irq call would break
drivers which do their own irq checking, but those shouldn't have
DRIVER_HAVE_IRQ set as Thierry Reding pointed out. But such drivers
already need to set dev->irq_enabled for other reasons, so we might as
well ditch that check, too.

v2: Also drop the HAVE_IRQ check.

Cc: Thierry Reding 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_irq.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index bd6e65fde1b9..7ef98c01c3d5 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -1160,9 +1160,8 @@ int drm_wait_vblank(struct drm_device *dev, void *data,
int ret;
unsigned int flags, seq, crtc, high_crtc;

-   if (drm_core_check_feature(dev, DRIVER_HAVE_IRQ))
-   if ((!drm_dev_to_irq(dev)) || (!dev->irq_enabled))
-   return -EINVAL;
+   if (!dev->irq_enabled)
+   return -EINVAL;

if (vblwait->request.type & _DRM_VBLANK_SIGNAL)
return -EINVAL;
-- 
1.8.5.2

[PATCH 01/18] drm/omap: fix up pdev_remove

[Daniel Vetter]

Dave accidentally merged the wrong version of the patch in

commit fd3c02531461924853db65f2664db361b53a70d3
Author: Daniel Vetter 
Date:   Wed Dec 11 11:34:26 2013 +0100

drm/omap: call drm_put_dev directly in ->remove

which did not include the fix from Rob's review: omapdrm is split into
the drm driver and the dmm driver (yeah, I've complained about that
almost-impossible-to-spot difference, too). We need to unregister the
dmm driver in the pdev_remove hook.

Cc: Dave Airlie 
Cc: Rob Clark 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/omapdrm/omap_drv.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
b/drivers/gpu/drm/omapdrm/omap_drv.c
index bf39fcc49e0f..89557989737d 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -699,6 +699,8 @@ static int pdev_remove(struct platform_device *device)
omap_disconnect_dssdevs();
omap_crtc_pre_uninit();

+   platform_driver_unregister(&omap_dmm_driver);
+
drm_put_dev(platform_get_drvdata(device));
return 0;
 }
-- 
1.8.5.2

[PATCH 00/18] drm_bus cleanups and other cruft removal

[Daniel Vetter]

Hi all,

I've chatted a bit with Thierry about how we could allow drivers to not even
required a drm_bus any more. Which is relevant when e.g. due to the new
master/component no platform device is conveniently around.

So I've brushed off my old series to remove some drm_bus functions and other
cruft and rebased it onto latest drm-next.

It gets rid of everything but drm_bus->set_busid, but Thierry has a good plan to
make that one optional too - it's only really needed for backwards compat with
some old libdrm versions on pci drm drivers.

Comments and review highly welcome.

Presuming no one screams I plan to send a pull request with these patches to
Dave fairly early for 3.16 so that Thierry can base his tegra rework on top of
it.

Cheers, Daniel

Daniel Vetter (18):
  drm/omap: fix up pdev_remove
  drm/irq: simplify irq checks in drm_wait_vblank
  drm/pci: fold in irq_by_busid support
  drm/irq: drm_control is a legacy ioctl, so pci devices only
  drm/irq: remove cargo-culted locking from irq_install/unistall
  drm: remove drm_dev_to_irq from drivers
  drm: kill drm_bus->bus_type
  drm: Rip out totally bogus vga_switcheroo->can_switch locking
  drm: rename dev->count_lock to dev->buf_lock
  drm/irq: track the irq installed in drm_irq_install in dev->irq
  drm/irq: Look up the pci irq directly in the drm_control ioctl
  drm: pass the irq explicitly to drm_irq_install
  drm: remove bus->get_irq implementations
  drm: inline drm_pci_set_unique
  drm: rip out dev->devname
  drm: remove drm_bus->get_name
  drm: Remove dev->kdriver
  drm/: don't set driver->dev_priv_size to 0

 Documentation/DocBook/drm.tmpl   |  10 +--
 drivers/gpu/drm/armada/armada_drv.c  |   2 +-
 drivers/gpu/drm/ast/ast_drv.c|   1 -
 drivers/gpu/drm/drm_bufs.c   |  32 +-
 drivers/gpu/drm/drm_info.c   |   6 +-
 drivers/gpu/drm/drm_ioctl.c  |  13 ++--
 drivers/gpu/drm/drm_irq.c| 106 +++
 drivers/gpu/drm/drm_pci.c|  94 +--
 drivers/gpu/drm/drm_platform.c   |  25 
 drivers/gpu/drm/drm_stub.c   |   7 +-
 drivers/gpu/drm/drm_usb.c|  14 
 drivers/gpu/drm/gma500/psb_drv.c |   2 +-
 drivers/gpu/drm/i915/i915_dma.c  |   9 ++-
 drivers/gpu/drm/i915/i915_drv.c  |   9 ++-
 drivers/gpu/drm/i915/i915_gem.c  |   7 +-
 drivers/gpu/drm/mga/mga_state.c  |   2 +-
 drivers/gpu/drm/msm/msm_drv.c|   2 +-
 drivers/gpu/drm/nouveau/nouveau_vga.c|   7 +-
 drivers/gpu/drm/omapdrm/omap_drv.c   |   2 +
 drivers/gpu/drm/qxl/qxl_drv.c|   1 -
 drivers/gpu/drm/qxl/qxl_irq.c|   2 +-
 drivers/gpu/drm/r128/r128_state.c|   2 +-
 drivers/gpu/drm/radeon/radeon_device.c   |   7 +-
 drivers/gpu/drm/radeon/radeon_drv.c  |   1 -
 drivers/gpu/drm/radeon/radeon_irq_kms.c  |   2 +-
 drivers/gpu/drm/radeon/radeon_state.c|   2 +-
 drivers/gpu/drm/shmobile/shmob_drm_drv.c |   2 +-
 drivers/gpu/drm/tegra/bus.c  |  11 
 drivers/gpu/drm/tilcdc/tilcdc_drv.c  |   2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c  |   2 +-
 include/drm/drmP.h   |  33 +++---
 31 files changed, 159 insertions(+), 258 deletions(-)

-- 
1.8.5.2

[PATCH 2/6] shm: add sealing API

[David Herrmann]

Hi

On Fri, Apr 11, 2014 at 3:43 PM, Tony Battersby  
wrote:
> Exactly.  For O_DIRECT, that would be the call to get_user_pages_fast()
> from dio_refill_pages() in fs/direct-io.c, which is ultimately called
> from blkdev_direct_IO().

If you drop mmap_sem after pinning a page without taking a write-ref,
you break i_mmap_writable / VM_DENYWRITE. In memfd I rely on
i_mmap_writable to work, same thing is done by exec() (and the old,
now disabled, MAP_DENYWRITE).

I don't know whether I should care. I mean, everyone pinning pages and
writing to it without holding the mmap_sem has to take a write-ref for
each page or it breaks i_mmap_writable. So this seems to be a bug in
direct-IO, not in anyone relying on it, right?

Thanks
David

[PATCH] drm: Provide drm_set_busid() fallback

[Daniel Vetter]

On Fri, Apr 11, 2014 at 8:30 PM, Thierry Reding
 wrote:
> On Fri, Apr 11, 2014 at 07:43:18PM +0200, Daniel Vetter wrote:
>> On Fri, Apr 11, 2014 at 03:28:56PM +0200, Thierry Reding wrote:
> [...]
>> > -   ret = dev->driver->bus->set_busid(dev, master);
>> > -   if (ret)
>> > -   goto err;
>> > +   if (dev->driver->bus && dev->driver->bus->set_busid) {
>> > +   ret = dev->driver->bus->set_busid(dev, master);
>> > +   if (ret)
>> > +   goto err;
>> > +   } else {
>>
>> Hm, my plan was actually to just provide a drm_dev_setunique to drivers so
>> that they can set whatever their userspace wants,
>
> So that would be going one step further and not call drm_set_busid() in
> the first place, but rather just let drivers statically assign unique at
> probe/load time? Yeah, that makes sense. It's not like the unique string
> is going to change at runtime, is it?

It's static, except for pci. There it can change depending upon the
drm version set by userspace.

>> and then have no set_busid implementation here at all for !pci.
>
> Perhaps for PCI there could simply be a common helper to initialize the
> unique string in the way it's currently generated by the PCI bus'
> implementation of .set_busid(). Even for PCI it's still a static string
> that's fixed at probe/load time, isn't it? And it isn't specific per
> device, only per drm_bus.

Well if you mean static string = something known at compile time put
into the .data section then no. At least for pci it's generated at
runtime in 2 different version. I think for everything else it's
actually static data (driver name usually).

>> Some userspace at least uses the unique thing to match for the driver,
>> so we need to do the usual bending over backwards to keep it
>> consistent.
>
> For new drivers and userspace it should be okay to just match on the
> driver name. Any differentiation on a per-device basis is probably
> better done using a GET_PARAM ioctl than by parsing a bus ID string.
>
> Or what is userspace doing with the bus ID in the first place?

libdrm expose an drmOpenByBusid, which is used by a lot of places to
match pci devices to drm drivers. And mesa/Xorg ... have big pci id
tables to match pci devices to userspace drivers. On non-pci it's all
different afaik.

>> The approach with a drm_set_unique helper would also make conversion of
>> existing platform and usb drivers easier.
>
> Yeah, I like that better than what this patch does. Is that something
> you have already queued up? If not I could take a stab at it.

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

DRM security flaws and security levels.

[Thomas Hellstrom]

On 04/11/2014 10:31 PM, David Herrmann wrote:
> Hi
>
> On Fri, Apr 11, 2014 at 2:42 PM, Thomas Hellstrom  
> wrote:
>> as was discussed a while ago, there are some serious security flaws with
>> the current drm master model, that allows a
>> user that had previous access or current access to an X server terminal
>> to access the GPU memory of the active X server, without being
>> authenticated to the X server and thereby also access other user's
>> secret information
> 1a) and 1b) are moot if you disallow primary-node access but require
> clients to use render-nodes with dma-buf. There're no gem-names on
> render-nodes so no way to access other buffers (assuming the GPU does
> command-stream checking and/or VM).

Disallowing primary node access will break older user-space drivers and
non-root
EGL clients. I'm not sure that's OK, even if the change is done from
user-space.
A simple gem fix would also do the trick.

>
> 2) There is no DRM-generic data other than buffers that is global. So
> imho this is a driver-specific issue.
>
> So I cannot see why this is a DRM issue. The only leaks I see are
> legacy interfaces and driver-specific interfaces. The first can be
> disabled via chmod() for clients, and the second is something driver
> authors should fix.

Yeah, but some driver authors can't or won't fix the drivers w r t this,
hence the security levels.

Thanks,
/Thomas


>
> Thanks
> David
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 75992] Display freezes & corruption with an r7 260x on 3.14-rc6

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

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

--- Comment #49 from Egon Ashrafinia  ---
Eventually???

But without the new Firmware, the Bug is Not really fixed is it?

We need the new Firmware to run smooth.

-- 
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/20140411/794223bb/attachment-0001.html>

DRM security flaws and security levels.

[David Herrmann]

Hi

On Fri, Apr 11, 2014 at 2:42 PM, Thomas Hellstrom  
wrote:
> as was discussed a while ago, there are some serious security flaws with
> the current drm master model, that allows a
> user that had previous access or current access to an X server terminal
> to access the GPU memory of the active X server, without being
> authenticated to the X server and thereby also access other user's
> secret information

1a) and 1b) are moot if you disallow primary-node access but require
clients to use render-nodes with dma-buf. There're no gem-names on
render-nodes so no way to access other buffers (assuming the GPU does
command-stream checking and/or VM).

2) There is no DRM-generic data other than buffers that is global. So
imho this is a driver-specific issue.

So I cannot see why this is a DRM issue. The only leaks I see are
legacy interfaces and driver-specific interfaces. The first can be
disabled via chmod() for clients, and the second is something driver
authors should fix.

Thanks
David

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

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

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

--- Comment #110 from Alex Deucher  ---
(In reply to comment #109)
> Can we expect something similar to what was proposed in bug 75992 as a
> possible fix (new ucode)? Just praying for a new proposition to test over
> here...

I already checked.  There's no new mc ucode for 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/20140411/2cb29284/attachment.html>

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

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

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

--- Comment #109 from Alexandre Demers  ---
Can we expect something similar to what was proposed in bug 75992 as a possible
fix (new ucode)? Just praying for a new proposition to test over here...

-- 
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/20140411/d7f02f81/attachment.html>

[Bug 75992] Display freezes & corruption with an r7 260x on 3.14-rc6

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

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

--- Comment #48 from Alex Deucher  ---
(In reply to comment #47)
> I saw you pushed those fixes upstream, Alex, thats good to see!
> But do you also push your new Firmware binarys upstream?

New binaries are here:
http://people.freedesktop.org/~agd5f/radeon_ucode/

They will make their way into the Linux firmware tree eventually.

-- 
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/20140411/7410d9c0/attachment.html>

[Bug 75992] Display freezes & corruption with an r7 260x on 3.14-rc6

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

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

--- Comment #47 from Egon Ashrafinia  ---
I saw you pushed those fixes upstream, Alex, thats good to see!
But do you also push your new Firmware binarys upstream?

Thats the Main fix.

Thank you for your fixes!

Greetings

-- 
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/20140411/944f0a04/attachment.html>

[PATCH 2/2] [RFC v2 with seqcount] reservation: add suppport for read-only access using rcu

[Thomas Hellstrom]

On 04/11/2014 08:09 PM, Maarten Lankhorst wrote:
> op 11-04-14 12:11, Thomas Hellstrom schreef:
>> On 04/11/2014 11:24 AM, Maarten Lankhorst wrote:
>>> op 11-04-14 10:38, Thomas Hellstrom schreef:
 Hi, Maarten.

 Here I believe we encounter a lot of locking inconsistencies.

 First, it seems you're use a number of pointers as RCU pointers
 without
 annotating them as such and use the correct rcu
 macros when assigning those pointers.

 Some pointers (like the pointers in the shared fence list) are both
 used
 as RCU pointers (in dma_buf_poll()) for example,
 or considered protected by the seqlock
 (reservation_object_get_fences_rcu()), which I believe is OK, but then
 the pointers must
 be assigned using the correct rcu macros. In the memcpy in
 reservation_object_get_fences_rcu() we might get away with an
 ugly typecast, but with a verbose comment that the pointers are
 considered protected by the seqlock at that location.

 So I've updated (attached) the headers with proper __rcu annotation
 and
 locking comments according to how they are being used in the various
 reading functions.
 I believe if we want to get rid of this we need to validate those
 pointers using the seqlock as well.
 This will generate a lot of sparse warnings in those places needing
 rcu_dereference()
 rcu_assign_pointer()
 rcu_dereference_protected()

 With this I think we can get rid of all ACCESS_ONCE macros: It's not
 needed when the rcu_x() macros are used, and
 it's never needed for the members protected by the seqlock, (provided
 that the seq is tested). The only place where I think that's
 *not* the case is at the krealloc in
 reservation_object_get_fences_rcu().

 Also I have some more comments in the
 reservation_object_get_fences_rcu() function below:
>>> I felt that the barriers needed for rcu were already provided by
>>> checking the seqcount lock.
>>> But looking at rcu_dereference makes it seem harmless to add it in
>>> more places, it handles
>>> the ACCESS_ONCE and barrier() for us.
>> And it makes the code more maintainable, and helps sparse doing a lot of
>> checking for us. I guess
>> we can tolerate a couple of extra barriers for that.
>>
>>> We could probably get away with using RCU_INIT_POINTER on the writer
>>> side,
>>> because the smp_wmb is already done by arranging seqcount updates
>>> correctly.
>> Hmm. yes, probably. At least in the replace function. I think if we do
>> it in other places, we should add comments as to where
>> the smp_wmb() is located, for future reference.
>>
>>
>> Also  I saw in a couple of places where you're checking the shared
>> pointers, you're not checking for NULL pointers, which I guess may
>> happen if shared_count and pointers are not in full sync?
>>
> No, because shared_count is protected with seqcount. I only allow
> appending to the array, so when
> shared_count is validated by seqcount it means that the
> [0...shared_count) indexes are valid and non-null.
> What could happen though is that the fence at a specific index is
> updated with another one from the same
> context, but that's harmless.
>

Hmm, doesn't attaching an exclusive fence clear all shared fence
pointers from under a reader?

/Thomas





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

[PATCH 2/2] [RFC v2 with seqcount] reservation: add suppport for read-only access using rcu

[Thomas Hellstrom]

Hi!

On 04/11/2014 08:09 PM, Maarten Lankhorst wrote:
> op 11-04-14 12:11, Thomas Hellstrom schreef:
>> On 04/11/2014 11:24 AM, Maarten Lankhorst wrote:
>>> op 11-04-14 10:38, Thomas Hellstrom schreef:
 Hi, Maarten.

 Here I believe we encounter a lot of locking inconsistencies.

 First, it seems you're use a number of pointers as RCU pointers
 without
 annotating them as such and use the correct rcu
 macros when assigning those pointers.

 Some pointers (like the pointers in the shared fence list) are both
 used
 as RCU pointers (in dma_buf_poll()) for example,
 or considered protected by the seqlock
 (reservation_object_get_fences_rcu()), which I believe is OK, but then
 the pointers must
 be assigned using the correct rcu macros. In the memcpy in
 reservation_object_get_fences_rcu() we might get away with an
 ugly typecast, but with a verbose comment that the pointers are
 considered protected by the seqlock at that location.

 So I've updated (attached) the headers with proper __rcu annotation
 and
 locking comments according to how they are being used in the various
 reading functions.
 I believe if we want to get rid of this we need to validate those
 pointers using the seqlock as well.
 This will generate a lot of sparse warnings in those places needing
 rcu_dereference()
 rcu_assign_pointer()
 rcu_dereference_protected()

 With this I think we can get rid of all ACCESS_ONCE macros: It's not
 needed when the rcu_x() macros are used, and
 it's never needed for the members protected by the seqlock, (provided
 that the seq is tested). The only place where I think that's
 *not* the case is at the krealloc in
 reservation_object_get_fences_rcu().

 Also I have some more comments in the
 reservation_object_get_fences_rcu() function below:
>>> I felt that the barriers needed for rcu were already provided by
>>> checking the seqcount lock.
>>> But looking at rcu_dereference makes it seem harmless to add it in
>>> more places, it handles
>>> the ACCESS_ONCE and barrier() for us.
>> And it makes the code more maintainable, and helps sparse doing a lot of
>> checking for us. I guess
>> we can tolerate a couple of extra barriers for that.
>>
>>> We could probably get away with using RCU_INIT_POINTER on the writer
>>> side,
>>> because the smp_wmb is already done by arranging seqcount updates
>>> correctly.
>> Hmm. yes, probably. At least in the replace function. I think if we do
>> it in other places, we should add comments as to where
>> the smp_wmb() is located, for future reference.
>>
>>
>> Also  I saw in a couple of places where you're checking the shared
>> pointers, you're not checking for NULL pointers, which I guess may
>> happen if shared_count and pointers are not in full sync?
>>
> No, because shared_count is protected with seqcount. I only allow
> appending to the array, so when
> shared_count is validated by seqcount it means that the
> [0...shared_count) indexes are valid and non-null.
> What could happen though is that the fence at a specific index is
> updated with another one from the same
> context, but that's harmless.

Hmm.
Shouldn't we have a way to clean signaled fences from reservation
objects? Perhaps when we attach a new fence, or after a wait with
ww_mutex held? Otherwise we'd have a lot of completely unused fence
objects hanging around for no reason. I don't think we need to be as
picky as TTM, but I think we should do something?

/Thomas



>
> ~Maarten

[Bug 75784] Octodad: Dadliest Catch - GPU crash on CAYMAN

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

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

--- Comment #1 from vmerlet at april.org ---
Same problem here, whith a Radeon HD 6950 too.

I've got problem with DPM too with this card but that's another topic...

At least, the work-around "R600_DEBUG=nosb" is working :-)

Cheers.

-- 
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/20140411/38420281/attachment.html>

[Bug 75127] runpm hang with PowerXpress/hybrid laptop

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

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

--- Comment #44 from Sandeep  ---
Ok, but what should the good and bad commits for the bisect be?

I had already done a bisection earlier and found that the commit adding and
enabling runtime power management was where the problems began.

-- 
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/20140411/a29bf4d3/attachment.html>

[PATCH] drm/radeon: Inline r100_mm_rreg

[Lauri Kasanen]

On Fri, 11 Apr 2014 14:32:20 +0200
Christian K?nig  wrote:

> Am 11.04.2014 11:54, schrieb Lauri Kasanen:
> > On Fri, 11 Apr 2014 10:33:08 +0200
> > Christian K?nig  wrote:
> >
>  Actually direct register access shouldn't be necessary so often. Apart
>  from page flips, write/read pointer updates and irq processing there
>  shouldn't be so many of them. Could you clarify a bit more what issue
>  you are seeing here?
> >>> Too much cpu usage for such a simple function. 2% makes it #2 in top-10
> >>> radeon.ko functions, right after evergreen_cs_parse. For reference, #3
> >>> (radeon_cs_packet_parse) is only 0.5%, one fourth of this function's
> >>> usage.
> >> I think you misunderstood me here. I do believe your numbers that it
> >> makes a noticeable difference.
> >>
> >> But I've did a couple of perf tests recently on SI and CIK while hacking
> >> on VM support, and IIRC r100_mm_rreg didn't showed up in the top 10 on
> >> those systems.
> >>
> >> So what puzzles me is who the hack is calling r100_mm_rreg so often that
> >> it makes a noticeable difference on evergreen/NI?
> > The biggest caller is cayman_cp_int_cntl_setup. Before inlining it took
> > 0.0013%, after it takes 1%.
> 
> Sounds like somebody is constantly turning interrupts on and off.

I instrumented radeon_irq_set. There's about 12 calls to that per sec,
most coming from radeon_irq_kms_sw_irq_get and
radeon_irq_kms_sw_irq_put.

So from your earlier mail I gather this amount of IRQ setting is
normal. It's just taking a lot of cpu for some reason.

- Lauri

[PATCH] drm: Provide drm_set_busid() fallback

[Thierry Reding]

On Fri, Apr 11, 2014 at 07:43:18PM +0200, Daniel Vetter wrote:
> On Fri, Apr 11, 2014 at 03:28:56PM +0200, Thierry Reding wrote:
[...]
> > -   ret = dev->driver->bus->set_busid(dev, master);
> > -   if (ret)
> > -   goto err;
> > +   if (dev->driver->bus && dev->driver->bus->set_busid) {
> > +   ret = dev->driver->bus->set_busid(dev, master);
> > +   if (ret)
> > +   goto err;
> > +   } else {
> 
> Hm, my plan was actually to just provide a drm_dev_setunique to drivers so
> that they can set whatever their userspace wants,

So that would be going one step further and not call drm_set_busid() in
the first place, but rather just let drivers statically assign unique at
probe/load time? Yeah, that makes sense. It's not like the unique string
is going to change at runtime, is it?

> and then have no set_busid implementation here at all for !pci.

Perhaps for PCI there could simply be a common helper to initialize the
unique string in the way it's currently generated by the PCI bus'
implementation of .set_busid(). Even for PCI it's still a static string
that's fixed at probe/load time, isn't it? And it isn't specific per
device, only per drm_bus.

> Some userspace at least uses the unique thing to match for the driver,
> so we need to do the usual bending over backwards to keep it
> consistent.

For new drivers and userspace it should be okay to just match on the
driver name. Any differentiation on a per-device basis is probably
better done using a GET_PARAM ioctl than by parsing a bus ID string.

Or what is userspace doing with the bus ID in the first place?

> The approach with a drm_set_unique helper would also make conversion of
> existing platform and usb drivers easier.

Yeah, I like that better than what this patch does. Is that something
you have already queued up? If not I could take a stab at it.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140411/c5eafc0d/attachment.sig>

[Bug 75127] runpm hang with PowerXpress/hybrid laptop

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

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

--- Comment #43 from Alex Deucher  ---
(In reply to comment #42)
> What exactly do I need to bisect i.e starting and ending commit ?

git bisect start
git bisect good 
git bisect bad 

At this point git will check out the commit halfway between these two.  Test it
and report back:
git bisect good //if that commit works
git bisect bad // if that commit is broken

git will checkout the next half way point.  repeat until it's done.  Once
you've found the problematic commit:

git bisect reset // resets your tree back to where you were before you started
bisecting.  E.g., if it was working in 3.12 and broke in 3.13:

git bisect start
git bisect good v3.12
git bisect bad v3.13

-- 
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/20140411/65e24f3d/attachment.html>

[PATCH 2/2] [RFC v2 with seqcount] reservation: add suppport for read-only access using rcu

[Maarten Lankhorst]

op 11-04-14 12:11, Thomas Hellstrom schreef:
> On 04/11/2014 11:24 AM, Maarten Lankhorst wrote:
>> op 11-04-14 10:38, Thomas Hellstrom schreef:
>>> Hi, Maarten.
>>>
>>> Here I believe we encounter a lot of locking inconsistencies.
>>>
>>> First, it seems you're use a number of pointers as RCU pointers without
>>> annotating them as such and use the correct rcu
>>> macros when assigning those pointers.
>>>
>>> Some pointers (like the pointers in the shared fence list) are both used
>>> as RCU pointers (in dma_buf_poll()) for example,
>>> or considered protected by the seqlock
>>> (reservation_object_get_fences_rcu()), which I believe is OK, but then
>>> the pointers must
>>> be assigned using the correct rcu macros. In the memcpy in
>>> reservation_object_get_fences_rcu() we might get away with an
>>> ugly typecast, but with a verbose comment that the pointers are
>>> considered protected by the seqlock at that location.
>>>
>>> So I've updated (attached) the headers with proper __rcu annotation and
>>> locking comments according to how they are being used in the various
>>> reading functions.
>>> I believe if we want to get rid of this we need to validate those
>>> pointers using the seqlock as well.
>>> This will generate a lot of sparse warnings in those places needing
>>> rcu_dereference()
>>> rcu_assign_pointer()
>>> rcu_dereference_protected()
>>>
>>> With this I think we can get rid of all ACCESS_ONCE macros: It's not
>>> needed when the rcu_x() macros are used, and
>>> it's never needed for the members protected by the seqlock, (provided
>>> that the seq is tested). The only place where I think that's
>>> *not* the case is at the krealloc in
>>> reservation_object_get_fences_rcu().
>>>
>>> Also I have some more comments in the
>>> reservation_object_get_fences_rcu() function below:
>> I felt that the barriers needed for rcu were already provided by
>> checking the seqcount lock.
>> But looking at rcu_dereference makes it seem harmless to add it in
>> more places, it handles
>> the ACCESS_ONCE and barrier() for us.
> And it makes the code more maintainable, and helps sparse doing a lot of
> checking for us. I guess
> we can tolerate a couple of extra barriers for that.
>
>> We could probably get away with using RCU_INIT_POINTER on the writer
>> side,
>> because the smp_wmb is already done by arranging seqcount updates
>> correctly.
> Hmm. yes, probably. At least in the replace function. I think if we do
> it in other places, we should add comments as to where
> the smp_wmb() is located, for future reference.
>
>
> Also  I saw in a couple of places where you're checking the shared
> pointers, you're not checking for NULL pointers, which I guess may
> happen if shared_count and pointers are not in full sync?
>
No, because shared_count is protected with seqcount. I only allow appending to 
the array, so when
shared_count is validated by seqcount it means that the [0...shared_count) 
indexes are valid and non-null.
What could happen though is that the fence at a specific index is updated with 
another one from the same
context, but that's harmless.

~Maarten

[Bug 75127] runpm hang with PowerXpress/hybrid laptop

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

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

--- Comment #42 from Sandeep  ---
What exactly do I need to bisect i.e starting and ending commit ?

-- 
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/20140411/065c95bc/attachment.html>

[PATCH] drm/radeon: Inline r100_mm_rreg

[Lauri Kasanen]

On Fri, 11 Apr 2014 14:32:20 +0200
Christian K?nig  wrote:

> Anyway, I would do like Ilia suggested and only put the else branch into 
> a separate, not inlined function.
> 
> BTW: It's probably a good idea to do the same for the write function as 
> well.

I tested it. The majority of the size increase stayed - the
else/spinlock part as non-inlined functions, radeon.ko was still 5%
larger instead of 7%.

- Lauri

[PATCH] drm: Provide drm_set_busid() fallback

[Daniel Vetter]

On Fri, Apr 11, 2014 at 03:28:56PM +0200, Thierry Reding wrote:
> From: Thierry Reding 
> 
> The only reason why struct drm_bus is still around is because the
> SETVERSION IOCTL calls a bus specific .set_busid() function. This commit
> provides a fallback implementation if a device either doesn't have a bus
> associated with it or if it doesn't implement .set_busid(). The bus ID
> will be set to the device's name as returned by dev_name().
> 
> This can be useful to create DRM devices directly in drivers using the
> drm_dev_alloc() and drm_dev_register() functions rather than going
> through the bus-specific implementations, with the goal of eventually
> getting rid of drm_bus entirely.
> 
> Signed-off-by: Thierry Reding 
> ---
>  drivers/gpu/drm/drm_ioctl.c | 26 +++---
>  1 file changed, 23 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index 93a42040bedb..d27134a94d69 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -122,6 +122,19 @@ err:
>   return ret;
>  }
>  
> +static int __drm_set_busid(struct drm_device *dev, struct drm_master *master)
> +{
> + const char *name = dev_name(dev->dev);
> +
> + master->unique = kstrdup(name, GFP_KERNEL);
> + if (!master->unique)
> + return -ENOMEM;
> +
> + master->unique_len = strlen(name);
> +
> + return 0;
> +}
> +
>  static int drm_set_busid(struct drm_device *dev, struct drm_file *file_priv)
>  {
>   struct drm_master *master = file_priv->master;
> @@ -130,9 +143,16 @@ static int drm_set_busid(struct drm_device *dev, struct 
> drm_file *file_priv)
>   if (master->unique != NULL)
>   drm_unset_busid(dev, master);
>  
> - ret = dev->driver->bus->set_busid(dev, master);
> - if (ret)
> - goto err;
> + if (dev->driver->bus && dev->driver->bus->set_busid) {
> + ret = dev->driver->bus->set_busid(dev, master);
> + if (ret)
> + goto err;
> + } else {

Hm, my plan was actually to just provide a drm_dev_setunique to drivers so
that they can set whatever their userspace wants, and then have no
set_busid implementation here at all for !pci. Some userspace at least
uses the unique thing to match for the driver, so we need to do the usual
bending over backwards to keep it consistent.

The approach with a drm_set_unique helper would also make conversion of
existing platform and usb drivers easier.

-Daniel

> + ret = __drm_set_busid(dev, master);
> + if (ret)
> + goto err;
> + }
> +
>   return 0;
>  err:
>   drm_unset_busid(dev, master);
> -- 
> 1.9.1
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[PATCH] [ACPI] Default to using the native backlight control on Windows 8 systems

[Aaron Lu]

On 04/11/2014 06:58 PM, Jani Nikula wrote:
> On Fri, 11 Apr 2014, Aaron Lu  wrote:
>> On 04/11/2014 04:13 AM, Matthew Garrett wrote:
>>> The list of machines in the "Use native backlight" table is getting longer
>>> and longer, which is a solid indication that we're doing something wrong.
>>> Disable the ACPI backlight interface if the system claims to be Windows 8
>>> or later.
>>
>> And has a native backlight control interface.
> 
> This. One thing we were doing wrong in i915 was unconditionally
> registering a native backlight interface even when it was not
> functional. We can't really know whether that is the case except by
> trusting the VBT, and although we've been let down in the past, trusting
> the VBT on this one is probably a better approximation of the reality
> than assuming it always works. Thus we've queued [1] and [2] for 3.15
> which should help.
> 
> [1] 
> http://cgit.freedesktop.org/drm-intel/commit/?id=39fbc9c8f6765959b55e0b127dd5c57df5a47d67
> [2] 
> http://cgit.freedesktop.org/drm-intel/commit/?id=c675949ec58ca50d5a3ae3c757892f1560f6e896

That's pretty cool :-)

Regards,
Aaron

DRM security flaws and security levels.

[Rob Clark]

On Fri, Apr 11, 2014 at 5:15 PM, Thomas Hellstrom  
wrote:
> On 04/11/2014 10:31 PM, David Herrmann wrote:
>> Hi
>>
>> On Fri, Apr 11, 2014 at 2:42 PM, Thomas Hellstrom  
>> wrote:
>>> as was discussed a while ago, there are some serious security flaws with
>>> the current drm master model, that allows a
>>> user that had previous access or current access to an X server terminal
>>> to access the GPU memory of the active X server, without being
>>> authenticated to the X server and thereby also access other user's
>>> secret information
>> 1a) and 1b) are moot if you disallow primary-node access but require
>> clients to use render-nodes with dma-buf. There're no gem-names on
>> render-nodes so no way to access other buffers (assuming the GPU does
>> command-stream checking and/or VM).
>
> Disallowing primary node access will break older user-space drivers and
> non-root
> EGL clients. I'm not sure that's OK, even if the change is done from
> user-space.
> A simple gem fix would also do the trick.
>
>>
>> 2) There is no DRM-generic data other than buffers that is global. So
>> imho this is a driver-specific issue.
>>
>> So I cannot see why this is a DRM issue. The only leaks I see are
>> legacy interfaces and driver-specific interfaces. The first can be
>> disabled via chmod() for clients, and the second is something driver
>> authors should fix.
>
> Yeah, but some driver authors can't or won't fix the drivers w r t this,
> hence the security levels.

fwiw, I do think we want security level reporting for drivers that
don't have per-process pagetables (either the hw doesn't support, or
simply just not implemented yet) to avoid giving a false sense of
security with rendernodes.  It might be useful to even be able to
request a security level.. ie. some hw might be able to support
process isolation of gpu buffers, but at a performance penalty..  Joe
Gamer might be ok with the tradeoff in return for moar fps.  Ideally
you could request on a per process basis (via some sort of egl/glx
extension) to firewall off, say, your online banking session.

note, sencario 1a is, I think, only an issue for shared buffers (ie.
ones that have an flink name).. so, ok, another process can see the
video game you were playing.  Ok, that is not quite true, since
browsers use gpu accel (but maybe they want to decide to
enable/disable that, at least for certain sites (like your online
banking) based on the max-security-level of the driver).  And gl
compositing window managers.

I doubt any of that is worse than any closed src gpu driver.  But
either way, for really classified/sensitive material you might want to
think about a computer with no gpu.  I wouldn't be surprised if the
NSA knew as much or more about these gpu's as we do.

BR,
-R

> Thanks,
> /Thomas
>
>
>>
>> Thanks
>> David
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/nouveau/bios: fix bug introduced in 457e77b2

[Ben Skeggs]

On Thu, Apr 10, 2014 at 5:33 AM, Andreas Noever
 wrote:
> 457e77b2 effectively replaces (... & 0xff00) << 8 with (... >> 8) << 8.
> Which does not do the same and breaks boot on my machine.
>
> Restore the old behaviour and remove the unnecessary cast.
>
> Signed-off-by: Andreas Noever 
Signed-off-by: Ben Skeggs 

> ---
>  drivers/gpu/drm/nouveau/core/subdev/bios/base.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c 
> b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> index e9df94f..2885b7c 100644
> --- a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> +++ b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> @@ -109,7 +109,7 @@ nouveau_bios_shadow_pramin(struct nouveau_bios *bios)
> return;
> }
>
> -   addr = (u64)(addr >> 8) << 8;
> +   addr = (addr >> 8) << 16;
> if (!addr) {
> addr  = (u64)nv_rd32(bios, 0x001700) << 16;
> addr += 0xf;
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 02/12] drm/nouveau/timer: skip calibration on GK20A

[Ben Skeggs]

On Fri, Apr 11, 2014 at 12:46 PM, Alexandre Courbot  wrote:
> On Wed, Mar 26, 2014 at 1:19 PM, Ben Skeggs  wrote:
>> On Tue, Mar 25, 2014 at 7:54 AM, Thierry Reding
>>  wrote:
>>> On Mon, Mar 24, 2014 at 05:42:24PM +0900, Alexandre Courbot wrote:
 GK20A's timer is directly attached to the system timer and cannot be
 calibrated. Skip the calibration phase on that chip since the
 corresponding registers do not exist.

 Signed-off-by: Alexandre Courbot 
 ---
  drivers/gpu/drm/nouveau/core/subdev/timer/nv04.c | 19 +--
  1 file changed, 13 insertions(+), 6 deletions(-)

 diff --git a/drivers/gpu/drm/nouveau/core/subdev/timer/nv04.c 
 b/drivers/gpu/drm/nouveau/core/subdev/timer/nv04.c
 index c0bdd10358d7..822fe0d8a871 100644
 --- a/drivers/gpu/drm/nouveau/core/subdev/timer/nv04.c
 +++ b/drivers/gpu/drm/nouveau/core/subdev/timer/nv04.c
 @@ -185,6 +185,10 @@ nv04_timer_init(struct nouveau_object *object)
   if (ret)
   return ret;

 + /* gk20a does not have the calibration registers */
 + if (device->chipset == 0xea)
 + goto skip_clk_init;
>>>
>>> I'm concerned that this won't scale in the future. Perhaps a better
>>> solution would be to add a "flags" or "features" field to struct
>>> nouveau_device along with feature bits such as HAS_CALIBRATION or
>>> similar.
>>>
>>> That way we don't have to touch this code for every new future Tegra
>>> chip. Unless perhaps if there's a reason to expect things to change in
>>> newer generations.
>> I've already handled this in a slightly different way in the tree I'd
>> previously pointed Alex at (I think!), as I needed to do the same for
>> GM107.
>>
>> Should just be able to use that implementation (so, just change the
>> probe patch) here too.
>
> I will skip this patch and use your implementation then. Btw,
> shouldn't the source file for the GK20A implementation be named nvea.c
> instead of gk20a.c?
For the Maxwell stuff I've been using "gm107" now too.  Since we're
working with you guys these days it seems better to use the same names
for things ;)

[Bug 71138] flashlight bug in L4D2

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

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

Benjamin Bellec  changed:

   What|Removed |Added

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

--- Comment #10 from Benjamin Bellec  ---
Yes I confirm this is now fixed.
I can even add the fix was:

commit: e9822f77a9cc024f528d30382fd5ad21c73a173b
title: glsl: Skip making a temporary for assignments when we don't need one.
author: Eric Anholt 
date: 2014-04-08 07:59:47 (GMT)

-- 
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/20140411/27846a73/attachment-0001.html>

[PATCH 1/3] drm/radeon: add support for newer mc ucode on SI (v2)

[Christian König]

Am 11.04.2014 17:21, schrieb Alex Deucher:
> May fix stability issues with some newer cards.
>
> v2: print out mc firmware version used and size
>
> Signed-off-by: Alex Deucher 
> Cc: stable at vger.kernel.org
All three added to my drm-fixes-3.15 queue.

Christian.

> ---
>   drivers/gpu/drm/radeon/radeon_ucode.h |  3 +++
>   drivers/gpu/drm/radeon/si.c   | 35 
> ++-
>   2 files changed, 25 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_ucode.h 
> b/drivers/gpu/drm/radeon/radeon_ucode.h
> index a77cd27..f415548 100644
> --- a/drivers/gpu/drm/radeon/radeon_ucode.h
> +++ b/drivers/gpu/drm/radeon/radeon_ucode.h
> @@ -57,6 +57,9 @@
>   #define BTC_MC_UCODE_SIZE6024
>   #define CAYMAN_MC_UCODE_SIZE 6037
>   #define SI_MC_UCODE_SIZE 7769
> +#define TAHITI_MC_UCODE_SIZE 7808
> +#define PITCAIRN_MC_UCODE_SIZE   7775
> +#define VERDE_MC_UCODE_SIZE  7875
>   #define OLAND_MC_UCODE_SIZE  7863
>   #define CIK_MC_UCODE_SIZE7866
>   #define HAWAII_MC_UCODE_SIZE 7933
> diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
> index d589475..86f8c9c 100644
> --- a/drivers/gpu/drm/radeon/si.c
> +++ b/drivers/gpu/drm/radeon/si.c
> @@ -39,30 +39,35 @@ MODULE_FIRMWARE("radeon/TAHITI_pfp.bin");
>   MODULE_FIRMWARE("radeon/TAHITI_me.bin");
>   MODULE_FIRMWARE("radeon/TAHITI_ce.bin");
>   MODULE_FIRMWARE("radeon/TAHITI_mc.bin");
> +MODULE_FIRMWARE("radeon/TAHITI_mc2.bin");
>   MODULE_FIRMWARE("radeon/TAHITI_rlc.bin");
>   MODULE_FIRMWARE("radeon/TAHITI_smc.bin");
>   MODULE_FIRMWARE("radeon/PITCAIRN_pfp.bin");
>   MODULE_FIRMWARE("radeon/PITCAIRN_me.bin");
>   MODULE_FIRMWARE("radeon/PITCAIRN_ce.bin");
>   MODULE_FIRMWARE("radeon/PITCAIRN_mc.bin");
> +MODULE_FIRMWARE("radeon/PITCAIRN_mc2.bin");
>   MODULE_FIRMWARE("radeon/PITCAIRN_rlc.bin");
>   MODULE_FIRMWARE("radeon/PITCAIRN_smc.bin");
>   MODULE_FIRMWARE("radeon/VERDE_pfp.bin");
>   MODULE_FIRMWARE("radeon/VERDE_me.bin");
>   MODULE_FIRMWARE("radeon/VERDE_ce.bin");
>   MODULE_FIRMWARE("radeon/VERDE_mc.bin");
> +MODULE_FIRMWARE("radeon/VERDE_mc2.bin");
>   MODULE_FIRMWARE("radeon/VERDE_rlc.bin");
>   MODULE_FIRMWARE("radeon/VERDE_smc.bin");
>   MODULE_FIRMWARE("radeon/OLAND_pfp.bin");
>   MODULE_FIRMWARE("radeon/OLAND_me.bin");
>   MODULE_FIRMWARE("radeon/OLAND_ce.bin");
>   MODULE_FIRMWARE("radeon/OLAND_mc.bin");
> +MODULE_FIRMWARE("radeon/OLAND_mc2.bin");
>   MODULE_FIRMWARE("radeon/OLAND_rlc.bin");
>   MODULE_FIRMWARE("radeon/OLAND_smc.bin");
>   MODULE_FIRMWARE("radeon/HAINAN_pfp.bin");
>   MODULE_FIRMWARE("radeon/HAINAN_me.bin");
>   MODULE_FIRMWARE("radeon/HAINAN_ce.bin");
>   MODULE_FIRMWARE("radeon/HAINAN_mc.bin");
> +MODULE_FIRMWARE("radeon/HAINAN_mc2.bin");
>   MODULE_FIRMWARE("radeon/HAINAN_rlc.bin");
>   MODULE_FIRMWARE("radeon/HAINAN_smc.bin");
>   
> @@ -1467,7 +1472,7 @@ int si_mc_load_microcode(struct radeon_device *rdev)
>   const __be32 *fw_data;
>   u32 running, blackout = 0;
>   u32 *io_mc_regs;
> - int i, ucode_size, regs_size;
> + int i, regs_size, ucode_size = rdev->mc_fw->size / 4;
>   
>   if (!rdev->mc_fw)
>   return -EINVAL;
> @@ -1475,28 +1480,23 @@ int si_mc_load_microcode(struct radeon_device *rdev)
>   switch (rdev->family) {
>   case CHIP_TAHITI:
>   io_mc_regs = (u32 *)&tahiti_io_mc_regs;
> - ucode_size = SI_MC_UCODE_SIZE;
>   regs_size = TAHITI_IO_MC_REGS_SIZE;
>   break;
>   case CHIP_PITCAIRN:
>   io_mc_regs = (u32 *)&pitcairn_io_mc_regs;
> - ucode_size = SI_MC_UCODE_SIZE;
>   regs_size = TAHITI_IO_MC_REGS_SIZE;
>   break;
>   case CHIP_VERDE:
>   default:
>   io_mc_regs = (u32 *)&verde_io_mc_regs;
> - ucode_size = SI_MC_UCODE_SIZE;
>   regs_size = TAHITI_IO_MC_REGS_SIZE;
>   break;
>   case CHIP_OLAND:
>   io_mc_regs = (u32 *)&oland_io_mc_regs;
> - ucode_size = OLAND_MC_UCODE_SIZE;
>   regs_size = TAHITI_IO_MC_REGS_SIZE;
>   break;
>   case CHIP_HAINAN:
>   io_mc_regs = (u32 *)&hainan_io_mc_regs;
> - ucode_size = OLAND_MC_UCODE_SIZE;
>   regs_size = TAHITI_IO_MC_REGS_SIZE;
>   break;
>   }
> @@ -1552,7 +1552,7 @@ static int si_init_microcode(struct radeon_device *rdev)
>   const char *chip_name;
>   const char *rlc_chip_name;
>   size_t pfp_req_size, me_req_size, ce_req_size, rlc_req_size, 
> mc_req_size;
> - size_t smc_req_size;
> + size_t smc_req_size, mc2_req_size;
>   char fw_name[30];
>   int err;
>   
> @@ -1567,6 +1567,7 @@ static int si_init_microcode(struct radeon_device *rdev)
>   ce_req_size = SI_CE_UCODE_SIZE * 4;
>   rlc_req_size = SI_RLC_UCODE_SIZE * 4;
>   mc_req_size = SI_MC_UCODE_SIZE * 4;
> +  

[PATCH] drm/radeon: apply more strict limits for PLL params v2

[Christian König]

From: Christian K?nig 

Letting post and refernce divider get to big is bad for signal stability.

v2: increase the limit to 210

Signed-off-by: Christian K?nig 
---
 drivers/gpu/drm/radeon/radeon_display.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
b/drivers/gpu/drm/radeon/radeon_display.c
index 386cfa4..2f42912 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -937,6 +937,9 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll,
}
post_div = post_div_best;

+   /* limit reference * post divider to a maximum */
+   ref_div_max = min(210 / post_div, ref_div_max);
+
/* get matching reference and feedback divider */
ref_div = max(den / post_div, 1u);
fb_div = nom;
-- 
1.9.1

[PATCH 1/3] drm/radeon: add support for newer mc ucode on SI

[Christian König]

Am 11.04.2014 16:52, schrieb Alex Deucher:
> May fix stability issues with some newer cards.
>
> Signed-off-by: Alex Deucher 
> Cc: stable at vger.kernel.org

Why adding *_mc2.bin for the MC firmware? To distinct if people have the 
new or the old firmware?

If that's the case I would rather print the firmware size or CRC code 
somewhere in the logs.

Christian.

> ---
>   drivers/gpu/drm/radeon/radeon_ucode.h |  3 +++
>   drivers/gpu/drm/radeon/si.c   | 34 
> +-
>   2 files changed, 24 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_ucode.h 
> b/drivers/gpu/drm/radeon/radeon_ucode.h
> index a77cd27..f415548 100644
> --- a/drivers/gpu/drm/radeon/radeon_ucode.h
> +++ b/drivers/gpu/drm/radeon/radeon_ucode.h
> @@ -57,6 +57,9 @@
>   #define BTC_MC_UCODE_SIZE6024
>   #define CAYMAN_MC_UCODE_SIZE 6037
>   #define SI_MC_UCODE_SIZE 7769
> +#define TAHITI_MC_UCODE_SIZE 7808
> +#define PITCAIRN_MC_UCODE_SIZE   7775
> +#define VERDE_MC_UCODE_SIZE  7875
>   #define OLAND_MC_UCODE_SIZE  7863
>   #define CIK_MC_UCODE_SIZE7866
>   #define HAWAII_MC_UCODE_SIZE 7933
> diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
> index d589475..7675247 100644
> --- a/drivers/gpu/drm/radeon/si.c
> +++ b/drivers/gpu/drm/radeon/si.c
> @@ -39,30 +39,35 @@ MODULE_FIRMWARE("radeon/TAHITI_pfp.bin");
>   MODULE_FIRMWARE("radeon/TAHITI_me.bin");
>   MODULE_FIRMWARE("radeon/TAHITI_ce.bin");
>   MODULE_FIRMWARE("radeon/TAHITI_mc.bin");
> +MODULE_FIRMWARE("radeon/TAHITI_mc2.bin");
>   MODULE_FIRMWARE("radeon/TAHITI_rlc.bin");
>   MODULE_FIRMWARE("radeon/TAHITI_smc.bin");
>   MODULE_FIRMWARE("radeon/PITCAIRN_pfp.bin");
>   MODULE_FIRMWARE("radeon/PITCAIRN_me.bin");
>   MODULE_FIRMWARE("radeon/PITCAIRN_ce.bin");
>   MODULE_FIRMWARE("radeon/PITCAIRN_mc.bin");
> +MODULE_FIRMWARE("radeon/PITCAIRN_mc2.bin");
>   MODULE_FIRMWARE("radeon/PITCAIRN_rlc.bin");
>   MODULE_FIRMWARE("radeon/PITCAIRN_smc.bin");
>   MODULE_FIRMWARE("radeon/VERDE_pfp.bin");
>   MODULE_FIRMWARE("radeon/VERDE_me.bin");
>   MODULE_FIRMWARE("radeon/VERDE_ce.bin");
>   MODULE_FIRMWARE("radeon/VERDE_mc.bin");
> +MODULE_FIRMWARE("radeon/VERDE_mc2.bin");
>   MODULE_FIRMWARE("radeon/VERDE_rlc.bin");
>   MODULE_FIRMWARE("radeon/VERDE_smc.bin");
>   MODULE_FIRMWARE("radeon/OLAND_pfp.bin");
>   MODULE_FIRMWARE("radeon/OLAND_me.bin");
>   MODULE_FIRMWARE("radeon/OLAND_ce.bin");
>   MODULE_FIRMWARE("radeon/OLAND_mc.bin");
> +MODULE_FIRMWARE("radeon/OLAND_mc2.bin");
>   MODULE_FIRMWARE("radeon/OLAND_rlc.bin");
>   MODULE_FIRMWARE("radeon/OLAND_smc.bin");
>   MODULE_FIRMWARE("radeon/HAINAN_pfp.bin");
>   MODULE_FIRMWARE("radeon/HAINAN_me.bin");
>   MODULE_FIRMWARE("radeon/HAINAN_ce.bin");
>   MODULE_FIRMWARE("radeon/HAINAN_mc.bin");
> +MODULE_FIRMWARE("radeon/HAINAN_mc2.bin");
>   MODULE_FIRMWARE("radeon/HAINAN_rlc.bin");
>   MODULE_FIRMWARE("radeon/HAINAN_smc.bin");
>   
> @@ -1467,7 +1472,7 @@ int si_mc_load_microcode(struct radeon_device *rdev)
>   const __be32 *fw_data;
>   u32 running, blackout = 0;
>   u32 *io_mc_regs;
> - int i, ucode_size, regs_size;
> + int i, regs_size, ucode_size = rdev->mc_fw->size / 4;
>   
>   if (!rdev->mc_fw)
>   return -EINVAL;
> @@ -1475,28 +1480,23 @@ int si_mc_load_microcode(struct radeon_device *rdev)
>   switch (rdev->family) {
>   case CHIP_TAHITI:
>   io_mc_regs = (u32 *)&tahiti_io_mc_regs;
> - ucode_size = SI_MC_UCODE_SIZE;
>   regs_size = TAHITI_IO_MC_REGS_SIZE;
>   break;
>   case CHIP_PITCAIRN:
>   io_mc_regs = (u32 *)&pitcairn_io_mc_regs;
> - ucode_size = SI_MC_UCODE_SIZE;
>   regs_size = TAHITI_IO_MC_REGS_SIZE;
>   break;
>   case CHIP_VERDE:
>   default:
>   io_mc_regs = (u32 *)&verde_io_mc_regs;
> - ucode_size = SI_MC_UCODE_SIZE;
>   regs_size = TAHITI_IO_MC_REGS_SIZE;
>   break;
>   case CHIP_OLAND:
>   io_mc_regs = (u32 *)&oland_io_mc_regs;
> - ucode_size = OLAND_MC_UCODE_SIZE;
>   regs_size = TAHITI_IO_MC_REGS_SIZE;
>   break;
>   case CHIP_HAINAN:
>   io_mc_regs = (u32 *)&hainan_io_mc_regs;
> - ucode_size = OLAND_MC_UCODE_SIZE;
>   regs_size = TAHITI_IO_MC_REGS_SIZE;
>   break;
>   }
> @@ -1552,7 +1552,7 @@ static int si_init_microcode(struct radeon_device *rdev)
>   const char *chip_name;
>   const char *rlc_chip_name;
>   size_t pfp_req_size, me_req_size, ce_req_size, rlc_req_size, 
> mc_req_size;
> - size_t smc_req_size;
> + size_t smc_req_size, mc2_req_size;
>   char fw_name[30];
>   int err;
>   
> @@ -1567,6 +1567,7 @@ static int si_init_microcode(struct radeon_device *rdev)
>   ce_req_size = SI_CE_UCODE_SIZE * 4;
>

[PATCH] drm/tegra: replace IS_ERR and PTR_ERR with PTR_ERR_OR_ZERO

[Duan Jiong]

This patch fixes coccinelle error regarding usage of IS_ERR and
PTR_ERR instead of PTR_ERR_OR_ZERO.

Signed-off-by: Duan Jiong 
---
 drivers/gpu/drm/tegra/gem.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index bcf9895..89aebe2 100644
--- a/drivers/gpu/drm/tegra/gem.c
+++ b/drivers/gpu/drm/tegra/gem.c
@@ -268,10 +268,7 @@ int tegra_bo_dumb_create(struct drm_file *file, struct 
drm_device *drm,

bo = tegra_bo_create_with_handle(file, drm, args->size, 0,
 &args->handle);
-   if (IS_ERR(bo))
-   return PTR_ERR(bo);
-
-   return 0;
+   return PTR_ERR_OR_ZERO(bo);
 }

 int tegra_bo_dumb_map_offset(struct drm_file *file, struct drm_device *drm,
-- 
1.8.3.1

[PATCH] drm/exynos: replace IS_ERR and PTR_ERR with PTR_ERR_OR_ZERO

[Duan Jiong]

This patch fixes coccinelle error regarding usage of IS_ERR and
PTR_ERR instead of PTR_ERR_OR_ZERO.

Signed-off-by: Duan Jiong 
---
 drivers/gpu/drm/exynos/exynos_dp_core.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index aed533b..fbaf289 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1185,10 +1185,7 @@ static int exynos_dp_dt_parse_phydata(struct 
exynos_dp_device *dp)
dp_phy_node = of_find_node_by_name(dp_phy_node, "dptx-phy");
if (!dp_phy_node) {
dp->phy = devm_phy_get(dp->dev, "dp");
-   if (IS_ERR(dp->phy))
-   return PTR_ERR(dp->phy);
-   else
-   return 0;
+   return PTR_ERR_OR_ZERO(dp->phy);
}

if (of_property_read_u32(dp_phy_node, "reg", &phy_base)) {
-- 
1.8.3.1

[PATCH 02/12] drm/nouveau/timer: skip calibration on GK20A

[Alexandre Courbot]

On 04/11/2014 04:31 PM, Ben Skeggs wrote:
> On Fri, Apr 11, 2014 at 12:46 PM, Alexandre Courbot  
> wrote:
>> On Wed, Mar 26, 2014 at 1:19 PM, Ben Skeggs  wrote:
>>> On Tue, Mar 25, 2014 at 7:54 AM, Thierry Reding
>>>  wrote:
 On Mon, Mar 24, 2014 at 05:42:24PM +0900, Alexandre Courbot wrote:
> GK20A's timer is directly attached to the system timer and cannot be
> calibrated. Skip the calibration phase on that chip since the
> corresponding registers do not exist.
>
> Signed-off-by: Alexandre Courbot 
> ---
>   drivers/gpu/drm/nouveau/core/subdev/timer/nv04.c | 19 
> +--
>   1 file changed, 13 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/core/subdev/timer/nv04.c 
> b/drivers/gpu/drm/nouveau/core/subdev/timer/nv04.c
> index c0bdd10358d7..822fe0d8a871 100644
> --- a/drivers/gpu/drm/nouveau/core/subdev/timer/nv04.c
> +++ b/drivers/gpu/drm/nouveau/core/subdev/timer/nv04.c
> @@ -185,6 +185,10 @@ nv04_timer_init(struct nouveau_object *object)
>if (ret)
>return ret;
>
> + /* gk20a does not have the calibration registers */
> + if (device->chipset == 0xea)
> + goto skip_clk_init;

 I'm concerned that this won't scale in the future. Perhaps a better
 solution would be to add a "flags" or "features" field to struct
 nouveau_device along with feature bits such as HAS_CALIBRATION or
 similar.

 That way we don't have to touch this code for every new future Tegra
 chip. Unless perhaps if there's a reason to expect things to change in
 newer generations.
>>> I've already handled this in a slightly different way in the tree I'd
>>> previously pointed Alex at (I think!), as I needed to do the same for
>>> GM107.
>>>
>>> Should just be able to use that implementation (so, just change the
>>> probe patch) here too.
>>
>> I will skip this patch and use your implementation then. Btw,
>> shouldn't the source file for the GK20A implementation be named nvea.c
>> instead of gk20a.c?
> For the Maxwell stuff I've been using "gm107" now too.  Since we're
> working with you guys these days it seems better to use the same names
> for things ;)

So would you like us to use the same naming scheme as well? So far all 
my patches use "nvea.c" whenever I need to add code.

[PATCH RFC 2/2] drm/exynos: initialize drm master only when all exynos drm devices are ready

[Andrzej Hajda]

The patch adds function to block/unblock drm master device initialization.
exynos_drm_dev_ready(pdev, bool) informs exynos_drm core if given device is
ready. exynos_drm master is initialized only if all devices are ready,
exynos_drm master is also removed if any device becomes not ready.
During module initialization before driver registration module scans for
devices matching given driver and marks them as not-ready. Driver during
probe/remove can inform exynos_drm core about device readiness, triggering
master drm init/remove.
The core of the patch is in exynos_drm_drv.c.
Drivers modifications is limited only to call exynos_drm_dev_ready on return
from probe and in remove callback before manager/display/subdriver
unregistration.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_dp_core.c |  35 +
 drivers/gpu/drm/exynos/exynos_drm_drv.c | 106 +++-
 drivers/gpu/drm/exynos/exynos_drm_drv.h |   2 +
 drivers/gpu/drm/exynos/exynos_drm_dsi.c |  40 ++-
 drivers/gpu/drm/exynos/exynos_drm_fimc.c|  33 +
 drivers/gpu/drm/exynos/exynos_drm_fimd.c|  36 +++---
 drivers/gpu/drm/exynos/exynos_drm_g2d.c |  15 ++--
 drivers/gpu/drm/exynos/exynos_drm_gsc.c |  28 +---
 drivers/gpu/drm/exynos/exynos_drm_ipp.c |  16 +++--
 drivers/gpu/drm/exynos/exynos_drm_rotator.c |  25 ---
 drivers/gpu/drm/exynos/exynos_drm_vidi.c|  16 +++--
 drivers/gpu/drm/exynos/exynos_hdmi.c|  51 -
 drivers/gpu/drm/exynos/exynos_mixer.c   |  12 +++-
 13 files changed, 307 insertions(+), 108 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 9385e96..b2955cc 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1240,29 +1240,32 @@ static int exynos_dp_probe(struct platform_device *pdev)
dp = devm_kzalloc(&pdev->dev, sizeof(struct exynos_dp_device),
GFP_KERNEL);
if (!dp) {
-   dev_err(&pdev->dev, "no memory for device data\n");
-   return -ENOMEM;
+   ret = -ENOMEM;
+   goto out;
}

dp->dev = &pdev->dev;
dp->dpms_mode = DRM_MODE_DPMS_OFF;

dp->video_info = exynos_dp_dt_parse_pdata(&pdev->dev);
-   if (IS_ERR(dp->video_info))
-   return PTR_ERR(dp->video_info);
+   if (IS_ERR(dp->video_info)) {
+   ret = PTR_ERR(dp->video_info);
+   goto out;
+   }

ret = exynos_dp_dt_parse_phydata(dp);
if (ret)
-   return ret;
+   goto out;

ret = exynos_dp_dt_parse_panel(dp);
if (ret)
-   return ret;
+   goto out;

dp->clock = devm_clk_get(&pdev->dev, "dp");
if (IS_ERR(dp->clock)) {
dev_err(&pdev->dev, "failed to get clock\n");
-   return PTR_ERR(dp->clock);
+   ret = PTR_ERR(dp->clock);
+   goto out;
}

clk_prepare_enable(dp->clock);
@@ -1270,13 +1273,16 @@ static int exynos_dp_probe(struct platform_device *pdev)
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);

dp->reg_base = devm_ioremap_resource(&pdev->dev, res);
-   if (IS_ERR(dp->reg_base))
-   return PTR_ERR(dp->reg_base);
+   if (IS_ERR(dp->reg_base)) {
+   ret = PTR_ERR(dp->reg_base);
+   goto out;
+   }

dp->irq = platform_get_irq(pdev, 0);
if (dp->irq == -ENXIO) {
dev_err(&pdev->dev, "failed to get irq\n");
-   return -ENODEV;
+   ret = -ENODEV;
+   goto out;
}

INIT_WORK(&dp->hotplug_work, exynos_dp_hotplug);
@@ -1289,7 +1295,7 @@ static int exynos_dp_probe(struct platform_device *pdev)
"exynos-dp", dp);
if (ret) {
dev_err(&pdev->dev, "failed to request irq\n");
-   return ret;
+   goto out;
}
disable_irq(dp->irq);

@@ -1298,13 +1304,18 @@ static int exynos_dp_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, &exynos_dp_display);
exynos_drm_display_register(&exynos_dp_display);

-   return 0;
+out:
+   exynos_drm_dev_ready(pdev, ret != -EPROBE_DEFER);
+
+   return ret;
 }

 static int exynos_dp_remove(struct platform_device *pdev)
 {
struct exynos_drm_display *display = platform_get_drvdata(pdev);

+   exynos_drm_dev_ready(pdev, false);
+
exynos_dp_dpms(display, DRM_MODE_DPMS_OFF);
exynos_drm_display_unregister(&exynos_dp_display);

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 5067b32..d63ae9e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -366,12 +366,12 @@ static int exynos_drm_platform_probe(struct 
pla

[PATCH RFC 1/2] drm/exynos: refactor drm drivers registration code

[Andrzej Hajda]

The patch removes driver registration code based on preprocessor conditionals.
Instead it uses private linker section to create array of drm drivers.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/Makefile |   2 +
 drivers/gpu/drm/exynos/exynos_dp_core.c |   2 +-
 drivers/gpu/drm/exynos/exynos_drm.lds.S |   9 ++
 drivers/gpu/drm/exynos/exynos_drm_drv.c | 203 +---
 drivers/gpu/drm/exynos/exynos_drm_drv.h |  18 ++-
 drivers/gpu/drm/exynos/exynos_drm_dsi.c |   2 +-
 drivers/gpu/drm/exynos/exynos_drm_fimc.c|   2 +-
 drivers/gpu/drm/exynos/exynos_drm_fimd.c|   2 +-
 drivers/gpu/drm/exynos/exynos_drm_g2d.c |   2 +-
 drivers/gpu/drm/exynos/exynos_drm_gsc.c |   2 +-
 drivers/gpu/drm/exynos/exynos_drm_ipp.c |   2 +-
 drivers/gpu/drm/exynos/exynos_drm_rotator.c |   2 +-
 drivers/gpu/drm/exynos/exynos_drm_vidi.c|   2 +-
 drivers/gpu/drm/exynos/exynos_hdmi.c|   2 +-
 drivers/gpu/drm/exynos/exynos_mixer.c   |   2 +-
 15 files changed, 68 insertions(+), 186 deletions(-)
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm.lds.S

diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index 33ae365..c8190c1 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -22,4 +22,6 @@ exynosdrm-$(CONFIG_DRM_EXYNOS_FIMC)   += exynos_drm_fimc.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_ROTATOR) += exynos_drm_rotator.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_GSC) += exynos_drm_gsc.o

+exynosdrm-y+= exynos_drm.lds
+
 obj-$(CONFIG_DRM_EXYNOS)   += exynosdrm.o
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index aed533b..9385e96 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1340,7 +1340,7 @@ static const struct of_device_id exynos_dp_match[] = {
{},
 };

-struct platform_driver dp_driver = {
+EXYNOS_DRM_DRV(dp_driver) = {
.probe  = exynos_dp_probe,
.remove = exynos_dp_remove,
.driver = {
diff --git a/drivers/gpu/drm/exynos/exynos_drm.lds.S 
b/drivers/gpu/drm/exynos/exynos_drm.lds.S
new file mode 100644
index 000..fd37dc1
--- /dev/null
+++ b/drivers/gpu/drm/exynos/exynos_drm.lds.S
@@ -0,0 +1,9 @@
+SECTIONS
+{
+   .data : {
+   . = ALIGN(8);
+   exynos_drm_drivers = .;
+   *(exynos_drm_drivers)
+   *(exynos_drm_drivers_last)
+   }
+}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 2d27ba2..5067b32 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -430,7 +430,7 @@ static const struct dev_pm_ops exynos_drm_pm_ops = {
exynos_drm_runtime_resume, NULL)
 };

-static struct platform_driver exynos_drm_platform_driver = {
+EXYNOS_DRM_DRV_LAST(exynos_drm_drv) = {
.probe  = exynos_drm_platform_probe,
.remove = exynos_drm_platform_remove,
.driver = {
@@ -440,197 +440,64 @@ static struct platform_driver exynos_drm_platform_driver 
= {
},
 };

-static int __init exynos_drm_init(void)
+static int exynos_platform_device_drm_register(void)
 {
-   int ret;
-
-#ifdef CONFIG_DRM_EXYNOS_DP
-   ret = platform_driver_register(&dp_driver);
-   if (ret < 0)
-   goto out_dp;
-#endif
-
-#ifdef CONFIG_DRM_EXYNOS_DSI
-   ret = platform_driver_register(&dsi_driver);
-   if (ret < 0)
-   goto out_dsi;
-#endif
-
-#ifdef CONFIG_DRM_EXYNOS_FIMD
-   ret = platform_driver_register(&fimd_driver);
-   if (ret < 0)
-   goto out_fimd;
-#endif
-
-#ifdef CONFIG_DRM_EXYNOS_HDMI
-   ret = platform_driver_register(&hdmi_driver);
-   if (ret < 0)
-   goto out_hdmi;
-   ret = platform_driver_register(&mixer_driver);
-   if (ret < 0)
-   goto out_mixer;
-#endif
-
-#ifdef CONFIG_DRM_EXYNOS_VIDI
-   ret = platform_driver_register(&vidi_driver);
-   if (ret < 0)
-   goto out_vidi;
-#endif
-
-#ifdef CONFIG_DRM_EXYNOS_G2D
-   ret = platform_driver_register(&g2d_driver);
-   if (ret < 0)
-   goto out_g2d;
-#endif
+   exynos_drm_pdev = platform_device_register_simple("exynos-drm", -1,
+ NULL, 0);
+   if (IS_ERR(exynos_drm_pdev))
+   return PTR_ERR(exynos_drm_pdev);

-#ifdef CONFIG_DRM_EXYNOS_FIMC
-   ret = platform_driver_register(&fimc_driver);
-   if (ret < 0)
-   goto out_fimc;
-#endif
+   return 0;
+}

-#ifdef CONFIG_DRM_EXYNOS_ROTATOR
-   ret = platform_driver_register(&rotator_driver);
-   if (ret < 0)
-   goto out_rotator;
-#endif
+static void exynos_platform_device_drm_unregister(void)
+{
+   platform_device_unregister(exynos_drm_pdev);
+}

[PATCH RFC 0/2] drm/exynos: refactoring drm device init/deinit

[Andrzej Hajda]

Hi Inki,

This patchset refactors drm device initialization. Details are described
in respective patches. It is an alternative to DT supernode concept.

The first patch uses linker sections to get rid of ifdef macros, it is not
essential for 2nd patch but it makes code more readable. Similar approach
is used by irqchip, clks and clk_sources.

The patchset is based on exynos-drm-next branch.

Regards
Andrzej


Andrzej Hajda (2):
  drm/exynos: refactor drm drivers registration code
  drm/exynos: initialize drm master only when all exynos drm devices are
ready

 drivers/gpu/drm/exynos/Makefile |   2 +
 drivers/gpu/drm/exynos/exynos_dp_core.c |  37 ++--
 drivers/gpu/drm/exynos/exynos_drm.lds.S |   9 +
 drivers/gpu/drm/exynos/exynos_drm_drv.c | 279 +---
 drivers/gpu/drm/exynos/exynos_drm_drv.h |  20 +-
 drivers/gpu/drm/exynos/exynos_drm_dsi.c |  42 +++--
 drivers/gpu/drm/exynos/exynos_drm_fimc.c|  35 ++--
 drivers/gpu/drm/exynos/exynos_drm_fimd.c|  38 ++--
 drivers/gpu/drm/exynos/exynos_drm_g2d.c |  17 +-
 drivers/gpu/drm/exynos/exynos_drm_gsc.c |  30 +--
 drivers/gpu/drm/exynos/exynos_drm_ipp.c |  18 +-
 drivers/gpu/drm/exynos/exynos_drm_rotator.c |  27 ++-
 drivers/gpu/drm/exynos/exynos_drm_vidi.c|  18 +-
 drivers/gpu/drm/exynos/exynos_hdmi.c|  53 --
 drivers/gpu/drm/exynos/exynos_mixer.c   |  14 +-
 15 files changed, 360 insertions(+), 279 deletions(-)
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm.lds.S

-- 
1.8.3.2

[PATCH] drm/plane_helper: don't disable plane in destroy function

[Thierry Reding]

On Fri, Apr 11, 2014 at 02:12:10PM +0200, Daniel Vetter wrote:
> By the time drm_mode_config_cleanup calls this all the hw state should
> be cleaned up already - we even have a WARN right before calling
> plane->destroy callbacks asserting that all framebuffers are gone.
> 
> So trying to disable things harder is a bit a bug. Caught by Thierry
> since it resulted in some mode_config.mutex locking backtraces.
> 
> Cc: Thierry Reding 
> Cc: Matt Roper 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_plane_helper.c | 1 -
>  1 file changed, 1 deletion(-)

Reviewed-by: Thierry Reding 
Tested-by: Thierry Reding 
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140411/27e08315/attachment.sig>

[PATCH] drm: Provide drm_set_busid() fallback

[Thierry Reding]

From: Thierry Reding 

The only reason why struct drm_bus is still around is because the
SETVERSION IOCTL calls a bus specific .set_busid() function. This commit
provides a fallback implementation if a device either doesn't have a bus
associated with it or if it doesn't implement .set_busid(). The bus ID
will be set to the device's name as returned by dev_name().

This can be useful to create DRM devices directly in drivers using the
drm_dev_alloc() and drm_dev_register() functions rather than going
through the bus-specific implementations, with the goal of eventually
getting rid of drm_bus entirely.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/drm_ioctl.c | 26 +++---
 1 file changed, 23 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 93a42040bedb..d27134a94d69 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -122,6 +122,19 @@ err:
return ret;
 }

+static int __drm_set_busid(struct drm_device *dev, struct drm_master *master)
+{
+   const char *name = dev_name(dev->dev);
+
+   master->unique = kstrdup(name, GFP_KERNEL);
+   if (!master->unique)
+   return -ENOMEM;
+
+   master->unique_len = strlen(name);
+
+   return 0;
+}
+
 static int drm_set_busid(struct drm_device *dev, struct drm_file *file_priv)
 {
struct drm_master *master = file_priv->master;
@@ -130,9 +143,16 @@ static int drm_set_busid(struct drm_device *dev, struct 
drm_file *file_priv)
if (master->unique != NULL)
drm_unset_busid(dev, master);

-   ret = dev->driver->bus->set_busid(dev, master);
-   if (ret)
-   goto err;
+   if (dev->driver->bus && dev->driver->bus->set_busid) {
+   ret = dev->driver->bus->set_busid(dev, master);
+   if (ret)
+   goto err;
+   } else {
+   ret = __drm_set_busid(dev, master);
+   if (ret)
+   goto err;
+   }
+
return 0;
 err:
drm_unset_busid(dev, master);
-- 
1.9.1

[Bug 77305] Compile error in pipe-loader files (pipe_r300.c pipe_r600.c pipe_radeonsi.c egl_pipe.c)

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

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

Tom Stellard  changed:

   What|Removed |Added

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

--- Comment #1 from Tom Stellard  ---
Committed the patch as ac3435a47c616286c5a5ee16148f829493c2127, thanks!

-- 
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/20140411/06613f01/attachment.html>

[PATCH] drm/radeon: fix runpm handling on APUs (v4)

[Christian König]

Am 11.04.2014 04:29, schrieb Alex Deucher:
> Don't try and runtime suspend the APU in PX systems.  We
> only want to power down the dGPU.
>
> v2: fix harder
> v3: fix stupid typo
> v4: consolidate runpm enablement to a single flag
>
> bugs:
> https://bugs.freedesktop.org/show_bug.cgi?id=75127
> https://bugzilla.kernel.org/show_bug.cgi?id=72701
>
> Signed-off-by: Alex Deucher 
> Cc: stable at vger.kernel.org

All three patches added to my drm-fixes-3.15 queue.

Is it correct that "[PATCH] drm/radeon: update CI DPM powertune 
settings" doesn't have a "CC: stable..." ?

Christian.

> ---
>   drivers/gpu/drm/radeon/radeon.h  |  1 +
>   drivers/gpu/drm/radeon/radeon_atpx_handler.c |  2 +-
>   drivers/gpu/drm/radeon/radeon_device.c   | 19 ++-
>   drivers/gpu/drm/radeon/radeon_drv.c  | 24 
>   drivers/gpu/drm/radeon/radeon_family.h   |  1 +
>   drivers/gpu/drm/radeon/radeon_kms.c  | 14 ++
>   6 files changed, 27 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index f0fc2c8..3d94c0d 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -2318,6 +2318,7 @@ struct radeon_device {
>   bool have_disp_power_ref;
>   };
>   
> +bool radeon_is_px(struct drm_device *dev);
>   int radeon_device_init(struct radeon_device *rdev,
>  struct drm_device *ddev,
>  struct pci_dev *pdev,
> diff --git a/drivers/gpu/drm/radeon/radeon_atpx_handler.c 
> b/drivers/gpu/drm/radeon/radeon_atpx_handler.c
> index fa9a9c0..dedea72 100644
> --- a/drivers/gpu/drm/radeon/radeon_atpx_handler.c
> +++ b/drivers/gpu/drm/radeon/radeon_atpx_handler.c
> @@ -59,7 +59,7 @@ struct atpx_mux {
>   u16 mux;
>   } __packed;
>   
> -bool radeon_is_px(void) {
> +bool radeon_has_atpx(void) {
>   return radeon_atpx_priv.atpx_detected;
>   }
>   
> diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
> b/drivers/gpu/drm/radeon/radeon_device.c
> index 2e72dcd..00b19d0 100644
> --- a/drivers/gpu/drm/radeon/radeon_device.c
> +++ b/drivers/gpu/drm/radeon/radeon_device.c
> @@ -102,11 +102,14 @@ static const char radeon_family_name[][16] = {
>   "LAST",
>   };
>   
> -#if defined(CONFIG_VGA_SWITCHEROO)
> -bool radeon_is_px(void);
> -#else
> -static inline bool radeon_is_px(void) { return false; }
> -#endif
> +bool radeon_is_px(struct drm_device *dev)
> +{
> + struct radeon_device *rdev = dev->dev_private;
> +
> + if (rdev->flags & RADEON_IS_PX)
> + return true;
> + return false;
> +}
>   
>   /**
>* radeon_program_register_sequence - program an array of registers.
> @@ -1082,7 +1085,7 @@ static void radeon_switcheroo_set_state(struct pci_dev 
> *pdev, enum vga_switchero
>   {
>   struct drm_device *dev = pci_get_drvdata(pdev);
>   
> - if (radeon_is_px() && state == VGA_SWITCHEROO_OFF)
> + if (radeon_is_px(dev) && state == VGA_SWITCHEROO_OFF)
>   return;
>   
>   if (state == VGA_SWITCHEROO_ON) {
> @@ -1301,9 +1304,7 @@ int radeon_device_init(struct radeon_device *rdev,
>* ignore it */
>   vga_client_register(rdev->pdev, rdev, NULL, radeon_vga_set_decode);
>   
> - if (radeon_runtime_pm == 1)
> - runtime = true;
> - if ((radeon_runtime_pm == -1) && radeon_is_px())
> + if (rdev->flags & RADEON_IS_PX)
>   runtime = true;
>   vga_switcheroo_register_client(rdev->pdev, &radeon_switcheroo_ops, 
> runtime);
>   if (runtime)
> diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
> b/drivers/gpu/drm/radeon/radeon_drv.c
> index 2dc2cc4..3811812 100644
> --- a/drivers/gpu/drm/radeon/radeon_drv.c
> +++ b/drivers/gpu/drm/radeon/radeon_drv.c
> @@ -114,6 +114,7 @@ extern int radeon_get_crtc_scanoutpos(struct drm_device 
> *dev, int crtc,
> unsigned int flags,
> int *vpos, int *hpos, ktime_t *stime,
> ktime_t *etime);
> +extern bool radeon_is_px(struct drm_device *dev);
>   extern const struct drm_ioctl_desc radeon_ioctls_kms[];
>   extern int radeon_max_kms_ioctl;
>   int radeon_mmap(struct file *filp, struct vm_area_struct *vma);
> @@ -143,11 +144,9 @@ void radeon_debugfs_cleanup(struct drm_minor *minor);
>   #if defined(CONFIG_VGA_SWITCHEROO)
>   void radeon_register_atpx_handler(void);
>   void radeon_unregister_atpx_handler(void);
> -bool radeon_is_px(void);
>   #else
>   static inline void radeon_register_atpx_handler(void) {}
>   static inline void radeon_unregister_atpx_handler(void) {}
> -static inline bool radeon_is_px(void) { return false; }
>   #endif
>   
>   int radeon_no_wb;
> @@ -404,12 +403,7 @@ static int radeon_pmops_runtime_suspend(struct device 
> *dev)
>   struct drm_device *drm_dev = pci_get_drvdata(pdev);
>   int ret;
>   
> - if (radeon_runtime_pm == 0) {
> - pm_runtime_forbid(de

[PATCH 2/6] shm: add sealing API

[Andy Lutomirski]

On Fri, Apr 11, 2014 at 2:42 PM, David Herrmann  
wrote:
> Hi
>
> On Fri, Apr 11, 2014 at 11:36 PM, Andy Lutomirski  
> wrote:
>> A quick grep of the kernel tree finds exactly zero code paths
>> incrementing i_mmap_writable outside of mmap and fork.
>>
>> Or do you mean a different kind of write ref?  What am I missing here?
>
> Sorry, I meant i_writecount.

I bet this is missing from lots of places.  For example, I can't find
any write_access stuff in the rdma code.

I suspect that the VM_DENYWRITE code is just generally racy.

--Andy

[PATCH 1/3] drm/radeon: add support for newer mc ucode on SI

[Deucher, Alexander]

> -Original Message-
> From: Christian K?nig [mailto:deathsimple at vodafone.de]
> Sent: Friday, April 11, 2014 11:03 AM
> To: Alex Deucher; dri-devel at lists.freedesktop.org
> Cc: Deucher, Alexander; stable at vger.kernel.org
> Subject: Re: [PATCH 1/3] drm/radeon: add support for newer mc ucode on SI
> 
> Am 11.04.2014 16:52, schrieb Alex Deucher:
> > May fix stability issues with some newer cards.
> >
> > Signed-off-by: Alex Deucher 
> > Cc: stable at vger.kernel.org
> 
> Why adding *_mc2.bin for the MC firmware? To distinct if people have the
> new or the old firmware?

To make sure I don't  break old kernels mixed with new firmware.  E.g., is a 
user updated their ucode, but not their kernel, it would fail due to the 
firmware being the wrong size.

> 
> If that's the case I would rather print the firmware size or CRC code
> somewhere in the logs.

I'll add that and respin.

Alex

> 
> Christian.
> 
> > ---
> >   drivers/gpu/drm/radeon/radeon_ucode.h |  3 +++
> >   drivers/gpu/drm/radeon/si.c   | 34 +-
> 
> >   2 files changed, 24 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/radeon/radeon_ucode.h
> b/drivers/gpu/drm/radeon/radeon_ucode.h
> > index a77cd27..f415548 100644
> > --- a/drivers/gpu/drm/radeon/radeon_ucode.h
> > +++ b/drivers/gpu/drm/radeon/radeon_ucode.h
> > @@ -57,6 +57,9 @@
> >   #define BTC_MC_UCODE_SIZE6024
> >   #define CAYMAN_MC_UCODE_SIZE 6037
> >   #define SI_MC_UCODE_SIZE 7769
> > +#define TAHITI_MC_UCODE_SIZE 7808
> > +#define PITCAIRN_MC_UCODE_SIZE   7775
> > +#define VERDE_MC_UCODE_SIZE  7875
> >   #define OLAND_MC_UCODE_SIZE  7863
> >   #define CIK_MC_UCODE_SIZE7866
> >   #define HAWAII_MC_UCODE_SIZE 7933
> > diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
> > index d589475..7675247 100644
> > --- a/drivers/gpu/drm/radeon/si.c
> > +++ b/drivers/gpu/drm/radeon/si.c
> > @@ -39,30 +39,35 @@ MODULE_FIRMWARE("radeon/TAHITI_pfp.bin");
> >   MODULE_FIRMWARE("radeon/TAHITI_me.bin");
> >   MODULE_FIRMWARE("radeon/TAHITI_ce.bin");
> >   MODULE_FIRMWARE("radeon/TAHITI_mc.bin");
> > +MODULE_FIRMWARE("radeon/TAHITI_mc2.bin");
> >   MODULE_FIRMWARE("radeon/TAHITI_rlc.bin");
> >   MODULE_FIRMWARE("radeon/TAHITI_smc.bin");
> >   MODULE_FIRMWARE("radeon/PITCAIRN_pfp.bin");
> >   MODULE_FIRMWARE("radeon/PITCAIRN_me.bin");
> >   MODULE_FIRMWARE("radeon/PITCAIRN_ce.bin");
> >   MODULE_FIRMWARE("radeon/PITCAIRN_mc.bin");
> > +MODULE_FIRMWARE("radeon/PITCAIRN_mc2.bin");
> >   MODULE_FIRMWARE("radeon/PITCAIRN_rlc.bin");
> >   MODULE_FIRMWARE("radeon/PITCAIRN_smc.bin");
> >   MODULE_FIRMWARE("radeon/VERDE_pfp.bin");
> >   MODULE_FIRMWARE("radeon/VERDE_me.bin");
> >   MODULE_FIRMWARE("radeon/VERDE_ce.bin");
> >   MODULE_FIRMWARE("radeon/VERDE_mc.bin");
> > +MODULE_FIRMWARE("radeon/VERDE_mc2.bin");
> >   MODULE_FIRMWARE("radeon/VERDE_rlc.bin");
> >   MODULE_FIRMWARE("radeon/VERDE_smc.bin");
> >   MODULE_FIRMWARE("radeon/OLAND_pfp.bin");
> >   MODULE_FIRMWARE("radeon/OLAND_me.bin");
> >   MODULE_FIRMWARE("radeon/OLAND_ce.bin");
> >   MODULE_FIRMWARE("radeon/OLAND_mc.bin");
> > +MODULE_FIRMWARE("radeon/OLAND_mc2.bin");
> >   MODULE_FIRMWARE("radeon/OLAND_rlc.bin");
> >   MODULE_FIRMWARE("radeon/OLAND_smc.bin");
> >   MODULE_FIRMWARE("radeon/HAINAN_pfp.bin");
> >   MODULE_FIRMWARE("radeon/HAINAN_me.bin");
> >   MODULE_FIRMWARE("radeon/HAINAN_ce.bin");
> >   MODULE_FIRMWARE("radeon/HAINAN_mc.bin");
> > +MODULE_FIRMWARE("radeon/HAINAN_mc2.bin");
> >   MODULE_FIRMWARE("radeon/HAINAN_rlc.bin");
> >   MODULE_FIRMWARE("radeon/HAINAN_smc.bin");
> >
> > @@ -1467,7 +1472,7 @@ int si_mc_load_microcode(struct radeon_device
> *rdev)
> > const __be32 *fw_data;
> > u32 running, blackout = 0;
> > u32 *io_mc_regs;
> > -   int i, ucode_size, regs_size;
> > +   int i, regs_size, ucode_size = rdev->mc_fw->size / 4;
> >
> > if (!rdev->mc_fw)
> > return -EINVAL;
> > @@ -1475,28 +1480,23 @@ int si_mc_load_microcode(struct
> radeon_device *rdev)
> > switch (rdev->family) {
> > case CHIP_TAHITI:
> > io_mc_regs = (u32 *)&tahiti_io_mc_regs;
> > -   ucode_size = SI_MC_UCODE_SIZE;
> > regs_size = TAHITI_IO_MC_REGS_SIZE;
> > break;
> > case CHIP_PITCAIRN:
> > io_mc_regs = (u32 *)&pitcairn_io_mc_regs;
> > -   ucode_size = SI_MC_UCODE_SIZE;
> > regs_size = TAHITI_IO_MC_REGS_SIZE;
> > break;
> > case CHIP_VERDE:
> > default:
> > io_mc_regs = (u32 *)&verde_io_mc_regs;
> > -   ucode_size = SI_MC_UCODE_SIZE;
> > regs_size = TAHITI_IO_MC_REGS_SIZE;
> > break;
> > case CHIP_OLAND:
> > io_mc_regs = (u32 *)&oland_io_mc_regs;
> > -   ucode_size = OLAND_MC_UCODE_SIZE;
> > regs_size = TAHITI_IO_MC_REGS_SIZE;
> > break;
> > case CHIP_HAINAN:
> > 

Possible fb ref count issue with drm_plane_force_disable()

[Ville Syrjälä]

On Thu, Apr 10, 2014 at 02:47:52PM +0300, Tomi Valkeinen wrote:
> Hi,
> 
> I've been debugging omapdrm issues on top of the latest drm mainline
> changes. Sometimes a drm_framebuffer ref count drops to -1 when aborting
> a drm application, or unloading the modules.
> 
> The setup is very basic, just a single crtc with the crtc's primary plane.
> 
> What seems to happen is:
> 
> - App is started
> 
> - fb is created, and taken into use by omapdrm. omapdrm takes a ref to
> the fb.
> 
> - the app is starts to shut down
> 
> - drm_framebuffer_remove is called
> 
> - fb->refcount.refcount > 1, so it goes to disable stuff
> 
> - drm_plane_force_disable is called for the primary plane
> 
> - drm_plane_force_disable does plane->disable_plane, which on omapdrm
> puts stuff on a workqueue as plane cannot be disabled immediately
> 
> - drm_plane_force_disable calls __drm_framebuffer_unreference()
> 
> - at the end of drm_framebuffer_remove(), there's
> drm_framebuffer_unreference, which causes ref count to go to zero, and
> the fb to be destroyed
> 
> - a bit later, the queued work is ran, which does
> drm_framebuffer_unreference(), and ref count goes to -1. Here omapdrm is
> removing the ref that had been taken in the beginning.
> 
> 
> So the explicit unref done by drm_plane_force_disable() seems a bit out
> of place. I can't figure out which drm_framebuffer_reference() would be
> the matching one for the unref done by drm_plane_force_disable().
> 
> Any ideas what ref is that? Or is the __drm_framebuffer_unreference()
> extra in drm_plane_force_disable()?

That's the reference that was taken by the drm_mode_setplane() when it
succesfully called the .update_plane() hook.

__drm_framebuffer_unregister() drops the "idr reference" taken in
drm_framebuffer_init().

And the last ref dropped by drm_framebuffer_remove() is the initial ref
from kref_init() which I suppose is what the 'fpriv->fbs reference'
comments are referring to.

-- 
Ville Syrj?l?
Intel OTC

DRM security flaws and security levels.

[Thomas Hellstrom]

Hi,

as was discussed a while ago, there are some serious security flaws with
the current drm master model, that allows a
user that had previous access or current access to an X server terminal
to access the GPU memory of the active X server, without being
authenticated to the X server and thereby also access other user's
secret information

Scenario 1a)
User 1 uses the X server, then locks the screen. User 2 then VT
switches, perhaps using fast user-switching, opens a DRM connection and
becomes authenticated with itself. It then starts to guess GEM names
used by the switched-away X server and open the corresponding objects.
Then mmaps those objects and dumps data.

Scenario 1b)
As in 1, but instead of mmaping the GEM objects, crafts a command buffer
that dumps all GPU memory to a local buffer and copies it out.

Scenario 2
User 1 logs in on X. Starts a daemon that authenticates with X. Then
logs out. User 2 logs in. User 1's daemon can now access data in a
similar fashion to what's done in 1a and 1b.

I don't think any driver is immune against all these scenarios. I think
all GEM drivers are vulnerable to 1a) and 2a), but that could be easily
fixed by only allowing GEM open of shared buffers from the same master.
I'm not sure about 1b) and 2b) but according to the driver developers,
radeon and noveau should be safe. vmwgfx should be safe against 1) but
not currently against 2 because the DRM fd is being kept open across X
server generations.

I think these flaws can be fixed in all modern drivers. For a) type
scenarios, refuse open of shared buffers that belong to other masters,
and on new X server generations, release the old master completely by
closing the FD or a special ioctl that releases master instead of drops
master.

For b) type scenarios, either provide a command verifier, per fd virtual
GPU memory or for simpler hardware:
throw out all GPU memory on master drop and block ioctls requiring
authentication until master becomes active again.

In any case, before enabling render nodes for drm we discussed a sysfs
attribute that stated the security level of the device, so that udev
could set up permissions accordingly. My suggestion is:

-1: The driver allows an authenticated client to craft command streams
that could access any part of system memory. These drivers should be
kept in staging until they are fixed.
0: Drivers that are vulnerable to any of the above scenarios.
1: Drivers that are immune against all above scenarios but allows any
authenticated client with *active* master to access all GPU memory. Any
enabled render nodes will be insecure, while primary nodes are secure.
2: Drivers that are immune against all above scenarios and can protect
clients from accessing eachother's gpu memory:
Render nodes will be secure.

Thoughts?

Thomas

[PATCH 2/6] shm: add sealing API

[Andy Lutomirski]

On 04/11/2014 02:31 PM, David Herrmann wrote:
> Hi
> 
> On Fri, Apr 11, 2014 at 3:43 PM, Tony Battersby  
> wrote:
>> Exactly.  For O_DIRECT, that would be the call to get_user_pages_fast()
>> from dio_refill_pages() in fs/direct-io.c, which is ultimately called
>> from blkdev_direct_IO().
> 
> If you drop mmap_sem after pinning a page without taking a write-ref,
> you break i_mmap_writable / VM_DENYWRITE. In memfd I rely on
> i_mmap_writable to work, same thing is done by exec() (and the old,
> now disabled, MAP_DENYWRITE).
> 
> I don't know whether I should care. I mean, everyone pinning pages and
> writing to it without holding the mmap_sem has to take a write-ref for
> each page or it breaks i_mmap_writable. So this seems to be a bug in
> direct-IO, not in anyone relying on it, right?

A quick grep of the kernel tree finds exactly zero code paths
incrementing i_mmap_writable outside of mmap and fork.

Or do you mean a different kind of write ref?  What am I missing here?

--Andy

[PATCH] drm/radeon: Inline r100_mm_rreg

[Christian König]

Am 11.04.2014 11:54, schrieb Lauri Kasanen:
> On Fri, 11 Apr 2014 10:33:08 +0200
> Christian K?nig  wrote:
>
 Actually direct register access shouldn't be necessary so often. Apart
 from page flips, write/read pointer updates and irq processing there
 shouldn't be so many of them. Could you clarify a bit more what issue
 you are seeing here?
>>> Too much cpu usage for such a simple function. 2% makes it #2 in top-10
>>> radeon.ko functions, right after evergreen_cs_parse. For reference, #3
>>> (radeon_cs_packet_parse) is only 0.5%, one fourth of this function's
>>> usage.
>> I think you misunderstood me here. I do believe your numbers that it
>> makes a noticeable difference.
>>
>> But I've did a couple of perf tests recently on SI and CIK while hacking
>> on VM support, and IIRC r100_mm_rreg didn't showed up in the top 10 on
>> those systems.
>>
>> So what puzzles me is who the hack is calling r100_mm_rreg so often that
>> it makes a noticeable difference on evergreen/NI?
> The biggest caller is cayman_cp_int_cntl_setup. Before inlining it took
> 0.0013%, after it takes 1%.

Sounds like somebody is constantly turning interrupts on and off.

> This is on a Richland APU, so Aruba/Cayman. Urban Terror is an ioq3
> game with a lot of cpu-side vertex submissions.

That will probably be the difference, I only tested lightsmark.

Anyway, I would do like Ilia suggested and only put the else branch into 
a separate, not inlined function.

BTW: It's probably a good idea to do the same for the write function as 
well.

Christian.

> - Lauri

[Bug 74539] [r600g] Memory leak when playing WoW with RV790

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

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

--- Comment #32 from Chris Rankin  ---
(In reply to comment #31)
> It's not a bug fix, so I doubt it would be accepted.

Perhaps not, but possibly worth asking Mr Greg KH if he'd be prepared to
consider it anyway?

-- 
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/20140411/8fbee770/attachment.html>

[PATCH] drm/plane_helper: don't disable plane in destroy function

[Daniel Vetter]

By the time drm_mode_config_cleanup calls this all the hw state should
be cleaned up already - we even have a WARN right before calling
plane->destroy callbacks asserting that all framebuffers are gone.

So trying to disable things harder is a bit a bug. Caught by Thierry
since it resulted in some mode_config.mutex locking backtraces.

Cc: Thierry Reding 
Cc: Matt Roper 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_plane_helper.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_plane_helper.c 
b/drivers/gpu/drm/drm_plane_helper.c
index e768d35ff22e..a3c9c6e11ee9 100644
--- a/drivers/gpu/drm/drm_plane_helper.c
+++ b/drivers/gpu/drm/drm_plane_helper.c
@@ -255,7 +255,6 @@ EXPORT_SYMBOL(drm_primary_helper_disable);
  */
 void drm_primary_helper_destroy(struct drm_plane *plane)
 {
-   plane->funcs->disable_plane(plane);
drm_plane_cleanup(plane);
kfree(plane);
 }
-- 
1.8.5.2

[PATCH v1 17/19] drm: sti: Add DRM driver itself

[Benjamin Gaignard]

For Z order property we have take example on exynos driver and keep
the same property name to avoid forking.

I would prefer to not hardcode Z order because we use it to do a kind
of composition between graphical planes and video planes.
It allow us to manage the Z order of some windows without using
software composition.

If you have a link to the plane properties talks we will happy to
follow/participate and fix the driver according to what will be
defined.

Benjamin

2014-04-11 12:26 GMT+02:00 Daniel Vetter :
> On Tue, Apr 08, 2014 at 02:19:24PM +0200, Benjamin Gaignard wrote:
>> Make the link between all the hardware drivers and DRM/KMS interface.
>> Create the driver itself and make it register all the sub-components.
>> Use GEM CMA helpers for buffer allocation.
>>
>> Signed-off-by: Benjamin Gaignard 
>> Signed-off-by: Vincent Abriou 
>> Signed-off-by: Fabien Dessenne 
>> ---
>>  drivers/gpu/drm/sti/Kconfig |   8 +
>>  drivers/gpu/drm/sti/Makefile|  28 +-
>>  drivers/gpu/drm/sti/sti_compositor.c|   2 +
>>  drivers/gpu/drm/sti/sti_drm_connector.c | 195 +
>>  drivers/gpu/drm/sti/sti_drm_connector.h |  16 ++
>>  drivers/gpu/drm/sti/sti_drm_crtc.c  | 440 ++
>>  drivers/gpu/drm/sti/sti_drm_crtc.h  |  21 ++
>>  drivers/gpu/drm/sti/sti_drm_drv.c   | 466 
>> 
>>  drivers/gpu/drm/sti/sti_drm_encoder.c   | 201 ++
>>  drivers/gpu/drm/sti/sti_drm_encoder.h   |  16 ++
>>  drivers/gpu/drm/sti/sti_drm_plane.c | 195 +
>>  drivers/gpu/drm/sti/sti_drm_plane.h |  16 ++
>>  drivers/gpu/drm/sti/sti_vtg_utils.h |   2 +
>>  13 files changed, 1594 insertions(+), 12 deletions(-)
>>  create mode 100644 drivers/gpu/drm/sti/sti_drm_connector.c
>>  create mode 100644 drivers/gpu/drm/sti/sti_drm_connector.h
>>  create mode 100644 drivers/gpu/drm/sti/sti_drm_crtc.c
>>  create mode 100644 drivers/gpu/drm/sti/sti_drm_crtc.h
>>  create mode 100644 drivers/gpu/drm/sti/sti_drm_drv.c
>>  create mode 100644 drivers/gpu/drm/sti/sti_drm_encoder.c
>>  create mode 100644 drivers/gpu/drm/sti/sti_drm_encoder.h
>>  create mode 100644 drivers/gpu/drm/sti/sti_drm_plane.c
>>  create mode 100644 drivers/gpu/drm/sti/sti_drm_plane.h
>>
>> diff --git a/drivers/gpu/drm/sti/Kconfig b/drivers/gpu/drm/sti/Kconfig
>> index a958398..61c8bd4 100644
>> --- a/drivers/gpu/drm/sti/Kconfig
>> +++ b/drivers/gpu/drm/sti/Kconfig
>> @@ -1,10 +1,18 @@
>>  config DRM_STI
>>   tristate "DRM Support for STMicroelectronics SoC stiH41x Series"
>>   depends on DRM && (SOC_STIH415 || SOC_STIH416 || ARCH_MULTIPLATFORM)
>> + select DRM_KMS_HELPER
>> + select DRM_GEM_CMA_HELPER
>>   select DRM_KMS_CMA_HELPER
>>   help
>> Choose this option to enable DRM on STM stiH41x chipset
>>
>> +config DRM_STI_FBDEV
>> + tristate "DRM frame buffer device for STMicroelectronics SoC stiH41x 
>> Serie"
>> + depends on DRM_STI
>> + help
>> +   Choose this option to enable FBDEV on top of DRM for STM stiH41x 
>> chipset
>> +
>>  config VTAC_STI
>>   tristate "Video Trafic Advance Communication Rx and Tx for 
>> STMicroelectronics SoC stiH41x Series"
>>   depends on DRM_STI
>> diff --git a/drivers/gpu/drm/sti/Makefile b/drivers/gpu/drm/sti/Makefile
>> index d598adc..17b4a68 100644
>> --- a/drivers/gpu/drm/sti/Makefile
>> +++ b/drivers/gpu/drm/sti/Makefile
>> @@ -1,17 +1,21 @@
>>  ccflags-y := -Iinclude/drm
>>
>> -stidrm-y := \
>> - sti_compositor.o \
>> - sti_mixer.o \
>> - sti_layer.o \
>> - sti_gdp.o \
>> - sti_vid.o \
>> - sti_tvout.o \
>> - sti_hdmi.o \
>> - sti_hdmi_tx3g0c55phy.o \
>> - sti_hdmi_tx3g4c28phy.o \
>> - sti_hda.o \
>> - sti_ddc.o
>> +stidrm-y := sti_drm_drv.o \
>> + sti_drm_crtc.o \
>> + sti_drm_plane.o \
>> + sti_drm_connector.o \
>> + sti_drm_encoder.o \
>> + sti_compositor.o \
>> + sti_mixer.o \
>> + sti_layer.o \
>> + sti_gdp.o \
>> + sti_vid.o \
>> + sti_tvout.o \
>> + sti_hdmi.o \
>> + sti_hdmi_tx3g0c55phy.o \
>> + sti_hdmi_tx3g4c28phy.o \
>> + sti_hda.o \
>> + sti_ddc.o
>>
>>  obj-$(CONFIG_DRM_STI) += stidrm.o
>>  obj-$(CONFIG_VTAC_STI) += sti_vtac_tx.o sti_vtac_rx.o
>> diff --git a/drivers/gpu/drm/sti/sti_compositor.c 
>> b/drivers/gpu/drm/sti/sti_compositor.c
>> index a163344..4d8d0958 100644
>> --- a/drivers/gpu/drm/sti/sti_compositor.c
>> +++ b/drivers/gpu/drm/sti/sti_compositor.c
>> @@ -14,6 +14,7 @@
>>
>>  #include "sti_compositor.h"
>>  #include "sti_gdp.h"
>> +#include "sti_drm_crtc.h"
>>
>>  static const struct of_device_id compositor_match_types[];
>>
>> @@ -98,6 +99,7 @@ static int sti_compositor_probe(struct platform_device 
>> *pdev)
>>   }
>>   DRM_DEBUG_DRIVER("Compositor %p\n", compo);
>>   compo->dev = dev;
>> + compo->

[Bug 77002] hdmi audio problems with 3.14

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

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

bgunteriv at gmail.com changed:

   What|Removed |Added

 Status|NEEDINFO|RESOLVED
 Resolution|--- |WORKSFORME

-- 
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/20140411/7a82263e/attachment.html>

[PATCH] [ACPI] Default to using the native backlight control on Windows 8 systems

[Jani Nikula]

On Fri, 11 Apr 2014, Aaron Lu  wrote:
> On 04/11/2014 04:13 AM, Matthew Garrett wrote:
>> The list of machines in the "Use native backlight" table is getting longer
>> and longer, which is a solid indication that we're doing something wrong.
>> Disable the ACPI backlight interface if the system claims to be Windows 8
>> or later.
>
> And has a native backlight control interface.

This. One thing we were doing wrong in i915 was unconditionally
registering a native backlight interface even when it was not
functional. We can't really know whether that is the case except by
trusting the VBT, and although we've been let down in the past, trusting
the VBT on this one is probably a better approximation of the reality
than assuming it always works. Thus we've queued [1] and [2] for 3.15
which should help.

[1] 
http://cgit.freedesktop.org/drm-intel/commit/?id=39fbc9c8f6765959b55e0b127dd5c57df5a47d67
[2] 
http://cgit.freedesktop.org/drm-intel/commit/?id=c675949ec58ca50d5a3ae3c757892f1560f6e896

>> Let's at least get this into -next for 3.16 and figure out whether the
>> drivers actually work now.
>
> I agree.

Agreed.


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH 2/2] arm: dts: trats2: add SiI9234 node

[Tomasz Stanislawski]

This patch adds configuration of SiI9234 bridge to Trats2 board.

Signed-off-by: Tomasz Stanislawski 
---
 arch/arm/boot/dts/exynos4412-trats2.dts |   43 +++
 1 file changed, 43 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 9583563d..65fd1d4 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -680,4 +680,47 @@
pulldown-ohm = <10>; /* 100K */
io-channels = <&adc 2>;  /* Battery temperature */
};
+
+   vsil: voltage-regulator-vsil {
+   compatible = "regulator-fixed";
+   regulator-name = "HDMI_5V";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   gpio = <&gpl0 4 0>;
+   enable-active-high;
+   vin-supply = <&buck7_reg>;
+   };
+
+   i2c-mhl {
+   compatible = "i2c-gpio";
+   gpios = <&gpf0 4 0 &gpf0 6 0>;
+   i2c-gpio,delay-us = <100>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   pinctrl-0 = <&i2c_mhl_bus>;
+   pinctrl-names = "default";
+   status = "okay";
+
+   sii9234: sii9234 at 39 {
+   compatible = "sil,sii9234";
+   vcc-supply = <&vsil>;
+   gpio-reset = <&gpf3 4 0>;
+   gpio-int = <&gpf3 5 0>;
+   reg = <0x39>;
+   };
+   };
+};
+
+&pinctrl_0 {
+   mhl_int: mhl-int {
+   samsung,pins = "gpf3-5";
+   samsung,pin-pud = <0>;
+   };
+   i2c_mhl_bus: i2c-mhl-bus {
+   samsung,pins = "gpf0-4", "gpf0-6";
+   samsung,pin-function = <2>;
+   samsung,pin-pud = <1>;
+   samsung,pin-drv = <0>;
+   };
 };
-- 
1.7.9.5

[PATCH 1/2] misc: add sii9234 driver

[Tomasz Stanislawski]

Add driver for HDMI bridge using MHL connection.
Contains refactored code for MHL driver developed by:

Adam Hampson 
Erik Gilling 
Shankar Bandal 
Dharam Kumar 

Signed-off-by: Tomasz Stanislawski 
Signed-off-by: Kyungmin Park 
---
 Documentation/devicetree/bindings/sii9234.txt |   22 +
 drivers/misc/Kconfig  |8 +
 drivers/misc/Makefile |1 +
 drivers/misc/sii9234.c| 1081 +
 4 files changed, 1112 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sii9234.txt
 create mode 100644 drivers/misc/sii9234.c

diff --git a/Documentation/devicetree/bindings/sii9234.txt 
b/Documentation/devicetree/bindings/sii9234.txt
new file mode 100644
index 000..4431139
--- /dev/null
+++ b/Documentation/devicetree/bindings/sii9234.txt
@@ -0,0 +1,22 @@
+SiI9234 Mobile HD Link Transmitter
+
+Required properties:
+- compatible : "sil,sii9234".
+- reg : I2C address for TPI interface, use 0x39
+- vcc-supply : regulator that supplies the chip
+- gpio-reset : GPIO connected to RESET_N pin
+- gpio-int : GPIO connected to INT pin
+
+Optional properties:
+- extcon : phandle to extcon that wakes up the chip
+
+Additional compatible properties are also allowed.
+
+Example:
+   sii9234 at 39 {
+   compatible = "sil,sii9234";
+   reg = <0x39>;
+   vcc-supply = <&vsil>;
+   gpio-reset = <&gpf3 4 0>;
+   gpio-int = <&gpf3 5 0>;
+   };
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 1cb7408..3b7f266 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -515,6 +515,14 @@ config SRAM
  the genalloc API. It is supposed to be used for small on-chip SRAM
  areas found on many SoCs.

+config SII9234
+   tristate "Silicon Image SII9234 Driver"
+   depends on I2C
+   help
+ Say Y here if you want support for the MHL interface.
+ It is an I2C driver, that detects connection of MHL bridge
+ and starts encapsulation of HDMI signal.
+
 source "drivers/misc/c2port/Kconfig"
 source "drivers/misc/eeprom/Kconfig"
 source "drivers/misc/cb710/Kconfig"
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 7eb4b69..145a47a 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -55,3 +55,4 @@ obj-$(CONFIG_SRAM)+= sram.o
 obj-y  += mic/
 obj-$(CONFIG_GENWQE)   += genwqe/
 obj-$(CONFIG_ECHO) += echo/
+obj-$(CONFIG_SII9234)  += sii9234.o
diff --git a/drivers/misc/sii9234.c b/drivers/misc/sii9234.c
new file mode 100644
index 000..60b7c66
--- /dev/null
+++ b/drivers/misc/sii9234.c
@@ -0,0 +1,1081 @@
+/*
+ * Copyright (C) 2014 Samsung Electronics
+ *
+ * Author: Tomasz Stanislawski 
+ *
+ * Based on sii9234 driver created by:
+ *Adam Hampson 
+ *Erik Gilling 
+ *Shankar Bandal 
+ *Dharam Kumar 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* MHL Tx registers and bits */
+#define MHL_TX_SRST 0x05
+#define MHL_TX_SYSSTAT_REG  0x09
+#define RSEN_STATUS (1<<2)
+#define MHL_TX_INTR1_REG0x71
+#define HPD_CHANGE_INT  (1<<6)
+#define RSEN_CHANGE_INT (1<<5)
+#define MHL_TX_INTR4_REG0x74
+#define RGND_READY_INT  (1<<6)
+#define VBUS_LOW_INT(1<<5)
+#define CBUS_LKOUT_INT  (1<<4)
+#define MHL_DISC_FAIL_INT   (1<<3)
+#define MHL_EST_INT (1<<2)
+#define MHL_TX_INTR1_ENABLE_REG 0x75
+#define HPD_CHANGE_INT_MASK (1<<6)
+#define RSEN_CHANGE_INT_MASK(1<<5)
+#define MHL_TX_INTR4_ENABLE_REG 0x78
+#define RGND_READY_MASK (1<<6)
+#define CBUS_LKOUT_MASK (1<<4)
+#define MHL_DISC_FAIL_MASK  (1<<3)
+#define MHL_EST_MASK(1<<2)
+#define MHL_TX_INT_CTRL_REG 0x79
+#define MHL_TX_TMDS_CCTRL   0x80
+#define MHL_TX_DISC_CTRL1_REG   0x90
+#define MHL_TX_DISC_CTRL2_REG   0x91
+#define SKIP_GND  

[PATCH 0/2] Add support for sii9234 chip

[Tomasz Stanislawski]

Hi everyone,
This patchset adds support for sii9234 HD Mobile Link Bridge.  The chip is used
to convert HDMI signal into MHL.  The driver enables HDMI output on Trats and
Trats2 boards.

The code is based on the driver [1] developed by:
   Adam Hampson 
   Erik Gilling 
with additional contributions from:
   Shankar Bandal 
   Dharam Kumar 

The drivers architecture was greatly simplified and transformed into a form
accepted (hopefully) by opensource community.  The main differences from
original code are:
* using single I2C client instead of 4 subclients
* remove all logic non-related to establishing HDMI link
* simplify error handling
* rewrite state machine in interrupt handler
* wakeup and discovery triggered by an extcon event
* integrate with Device Tree

For now, the driver is added to drivers/misc/ directory because it has neigher
userspace nor kernel interface.  The chip is capable of receiving and
processing CEC events, so the driver may export an input device in /dev/ in the
future.  However CEC could be also handled by HDMI driver.

I kindly ask for suggestions about the best location for this driver.

Both the chip and the driver are quite autonomic. The chip works as 'invisible
proxy' for HDMI signal, so there is no need to integrate it with HDMI drivers
by helper-subsystems like v4l2_subdev or drm_bridge.  If the driver is merged
then the driver from drivers/media/platform/s5p-tv/sii9234_drv.c could be safely
removed.

All comments are welcome.

Regards,
Tomasz Stanislawski


References:
[1] 
https://github.com/junpei0824/SC02C-linux/tree/master-jelly-cm-aokp/drivers/media/video/mhl


Tomasz Stanislawski (2):
  misc: add sii9234 driver
  arm: dts: trats2: add SiI9234 node

 Documentation/devicetree/bindings/sii9234.txt |   22 +
 arch/arm/boot/dts/exynos4412-trats2.dts   |   43 +
 drivers/misc/Kconfig  |8 +
 drivers/misc/Makefile |1 +
 drivers/misc/sii9234.c| 1081 +
 5 files changed, 1155 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sii9234.txt
 create mode 100644 drivers/misc/sii9234.c

-- 
1.7.9.5

[Bug 77009] 24P playback video signal loss with latest DRI patches

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

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

Christian K?nig  changed:

   What|Removed |Added

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

--- Comment #30 from Christian K?nig  ---
(In reply to comment #29)
> (In reply to comment #28)
> 1) Run a setup program each time a hardware change is detected. (EDID or GPU)
> 2) Test LCD/Panel at various popular refresh rates.
> a) crank up the pll with your new algo. 
>  >>  *test* if tv accepted it. (requires a knowledge of protocol to
> check display state, or have user answer ok with a timeout in case it is not
> readable)

Well, that's way to much user interaction for this topic cause there is no way
to ask a TV if the picture looks ok other than asking the user.

I'm going to supmit the patch to drm-fixes (with a bit higher limit) so it
should end up in 3.15 together with the patch that created the problem in the
first place.

-- 
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/20140411/e26a4627/attachment.html>

[PULL] drm-intel-fixes

[Jani Nikula]

Hi Dave, here's the first batch of fixes for 3.15.

BR,
Jani.


The following changes since commit c39b06951f1dc2e384650288676c5b7dcc0ec92c:

  DRM: armada: fix corruption while loading cursors (2014-04-08 10:51:03 +1000)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2014-04-11

for you to fetch changes up to 691e6415c891b8b2b082a120b896b443531c4d45:

  drm/i915: Always use kref tracking for all contexts. (2014-04-11 13:29:51 
+0300)


Chris Wilson (1):
  drm/i915: Always use kref tracking for all contexts.

Daniel Vetter (2):
  drm/mm: Don't WARN if drm_mm_reserve_node
  drm/i915: Disable self-refresh for untiled fbs on i915gm

Jani Nikula (2):
  drm/i915: check VBT for supported backlight type
  drm/i915: do not setup backlight if not available according to VBT

 drivers/gpu/drm/drm_mm.c   |2 -
 drivers/gpu/drm/i915/i915_drv.h|9 +-
 drivers/gpu/drm/i915/i915_gem.c|2 +-
 drivers/gpu/drm/i915/i915_gem_context.c|  218 +++-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |2 +-
 drivers/gpu/drm/i915/intel_bios.c  |   10 ++
 drivers/gpu/drm/i915/intel_bios.h  |3 +
 drivers/gpu/drm/i915/intel_panel.c |5 +
 drivers/gpu/drm/i915/intel_pm.c|   10 ++
 9 files changed, 122 insertions(+), 139 deletions(-)

-- 
Jani Nikula, Intel Open Source Technology Center
-- 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/20140411/54c2728e/attachment.sig>

[PATCH libdrm 0/4] Minor cleanups

[Eric Anholt]

Thierry Reding  writes:

> On Tue, Apr 08, 2014 at 02:38:22PM -0700, Eric Anholt wrote:
>> Thierry Reding  writes:
>> 
>> > From: Thierry Reding 
>> >
>> > These four patches clean up some minor issues in libdrm. Patch 1 makes
>> > gcc aware of various functions (such as drmMsg(), drm_debug_print(),
>> > etc) being printf-like and patches 2 and 3 fix up a number of warnings
>> > flagged as a result of that.
>> >
>> > Patch 4 uses drmFreeVersion() instead of drmFree() to free a drmVersion
>> > structure to prevent memory leaks.
>> 
>> These are:
>> 
>> Reviewed-by: Eric Anholt 
>
> Thanks. I don't have the necessary permissions to push this, can
> somebody else help out here?

I've given you permissions.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140411/d387c829/attachment.sig>

[PATCH] drm/radeon: fix runpm handling on APUs (v4)

[Deucher, Alexander]

> -Original Message-
> From: Christian K?nig [mailto:deathsimple at vodafone.de]
> Sent: Friday, April 11, 2014 9:10 AM
> To: Alex Deucher; dri-devel at lists.freedesktop.org
> Cc: Deucher, Alexander; stable at vger.kernel.org
> Subject: Re: [PATCH] drm/radeon: fix runpm handling on APUs (v4)
> 
> Am 11.04.2014 04:29, schrieb Alex Deucher:
> > Don't try and runtime suspend the APU in PX systems.  We
> > only want to power down the dGPU.
> >
> > v2: fix harder
> > v3: fix stupid typo
> > v4: consolidate runpm enablement to a single flag
> >
> > bugs:
> > https://bugs.freedesktop.org/show_bug.cgi?id=75127
> > https://bugzilla.kernel.org/show_bug.cgi?id=72701
> >
> > Signed-off-by: Alex Deucher 
> > Cc: stable at vger.kernel.org
> 
> All three patches added to my drm-fixes-3.15 queue.
> 
> Is it correct that "[PATCH] drm/radeon: update CI DPM powertune
> settings" doesn't have a "CC: stable..." ?

I want to let it get some wider testing before I send it back to stable.

Alex

> 
> Christian.
> 
> > ---
> >   drivers/gpu/drm/radeon/radeon.h  |  1 +
> >   drivers/gpu/drm/radeon/radeon_atpx_handler.c |  2 +-
> >   drivers/gpu/drm/radeon/radeon_device.c   | 19 ++-
> >   drivers/gpu/drm/radeon/radeon_drv.c  | 24 
> >   drivers/gpu/drm/radeon/radeon_family.h   |  1 +
> >   drivers/gpu/drm/radeon/radeon_kms.c  | 14 ++
> >   6 files changed, 27 insertions(+), 34 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/radeon/radeon.h
> b/drivers/gpu/drm/radeon/radeon.h
> > index f0fc2c8..3d94c0d 100644
> > --- a/drivers/gpu/drm/radeon/radeon.h
> > +++ b/drivers/gpu/drm/radeon/radeon.h
> > @@ -2318,6 +2318,7 @@ struct radeon_device {
> > bool have_disp_power_ref;
> >   };
> >
> > +bool radeon_is_px(struct drm_device *dev);
> >   int radeon_device_init(struct radeon_device *rdev,
> >struct drm_device *ddev,
> >struct pci_dev *pdev,
> > diff --git a/drivers/gpu/drm/radeon/radeon_atpx_handler.c
> b/drivers/gpu/drm/radeon/radeon_atpx_handler.c
> > index fa9a9c0..dedea72 100644
> > --- a/drivers/gpu/drm/radeon/radeon_atpx_handler.c
> > +++ b/drivers/gpu/drm/radeon/radeon_atpx_handler.c
> > @@ -59,7 +59,7 @@ struct atpx_mux {
> > u16 mux;
> >   } __packed;
> >
> > -bool radeon_is_px(void) {
> > +bool radeon_has_atpx(void) {
> > return radeon_atpx_priv.atpx_detected;
> >   }
> >
> > diff --git a/drivers/gpu/drm/radeon/radeon_device.c
> b/drivers/gpu/drm/radeon/radeon_device.c
> > index 2e72dcd..00b19d0 100644
> > --- a/drivers/gpu/drm/radeon/radeon_device.c
> > +++ b/drivers/gpu/drm/radeon/radeon_device.c
> > @@ -102,11 +102,14 @@ static const char radeon_family_name[][16] = {
> > "LAST",
> >   };
> >
> > -#if defined(CONFIG_VGA_SWITCHEROO)
> > -bool radeon_is_px(void);
> > -#else
> > -static inline bool radeon_is_px(void) { return false; }
> > -#endif
> > +bool radeon_is_px(struct drm_device *dev)
> > +{
> > +   struct radeon_device *rdev = dev->dev_private;
> > +
> > +   if (rdev->flags & RADEON_IS_PX)
> > +   return true;
> > +   return false;
> > +}
> >
> >   /**
> >* radeon_program_register_sequence - program an array of registers.
> > @@ -1082,7 +1085,7 @@ static void radeon_switcheroo_set_state(struct
> pci_dev *pdev, enum vga_switchero
> >   {
> > struct drm_device *dev = pci_get_drvdata(pdev);
> >
> > -   if (radeon_is_px() && state == VGA_SWITCHEROO_OFF)
> > +   if (radeon_is_px(dev) && state == VGA_SWITCHEROO_OFF)
> > return;
> >
> > if (state == VGA_SWITCHEROO_ON) {
> > @@ -1301,9 +1304,7 @@ int radeon_device_init(struct radeon_device
> *rdev,
> >  * ignore it */
> > vga_client_register(rdev->pdev, rdev, NULL,
> radeon_vga_set_decode);
> >
> > -   if (radeon_runtime_pm == 1)
> > -   runtime = true;
> > -   if ((radeon_runtime_pm == -1) && radeon_is_px())
> > +   if (rdev->flags & RADEON_IS_PX)
> > runtime = true;
> > vga_switcheroo_register_client(rdev->pdev,
> &radeon_switcheroo_ops, runtime);
> > if (runtime)
> > diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
> b/drivers/gpu/drm/radeon/radeon_drv.c
> > index 2dc2cc4..3811812 100644
> > --- a/drivers/gpu/drm/radeon/radeon_drv.c
> > +++ b/drivers/gpu/drm/radeon/radeon_drv.c
> > @@ -114,6 +114,7 @@ extern int radeon_get_crtc_scanoutpos(struct
> drm_device *dev, int crtc,
> >   unsigned int flags,
> >   int *vpos, int *hpos, ktime_t *stime,
> >   ktime_t *etime);
> > +extern bool radeon_is_px(struct drm_device *dev);
> >   extern const struct drm_ioctl_desc radeon_ioctls_kms[];
> >   extern int radeon_max_kms_ioctl;
> >   int radeon_mmap(struct file *filp, struct vm_area_struct *vma);
> > @@ -143,11 +144,9 @@ void radeon_debugfs_cleanup(struct drm_minor
> *minor);
> >   #if defined(CONFIG_VGA_SWITCHEROO)
> >   void radeon_register_atpx_handler(void);
> >   voi

[Bug 71138] flashlight bug in L4D2

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

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

--- Comment #9 from yashax at windowslive.com ---
It looks like this bug is fixed with current mesa master. Can you please verify
that on your hardware?

---
System information:
Radeon HD 4850
Ubuntu 13.10 x86_64
Linux 3.14
libdrm 2.4.53+git1404110630.504d60
xserver-xorg-video-radeon 7.3.99+git1404022026.ed0cfb
OpenGL renderer string: Gallium 0.4 on AMD RV770
OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.2.0-devel
(git-55f9bbd saucy-oibaf-ppa)
OpenGL core profile shading language version string: 3.30

-- 
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/20140411/39a5550d/attachment.html>

[Bug 77274] [drm:dce6_afmt_write_speaker_allocation] *ERROR* Couldn't read Speaker Allocation Data Block: 0

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

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

Alex Deucher  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #11 from Alex Deucher  ---


*** This bug has been marked as a duplicate of bug 77002 ***

-- 
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/20140411/9fb71e7e/attachment.html>

[Bug 77002] hdmi audio problems with 3.14

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

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

Alex Deucher  changed:

   What|Removed |Added

 CC||amnesiac2001 at gmail.com

--- Comment #36 from Alex Deucher  ---
*** Bug 77274 has been marked as a duplicate of 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/20140411/200edc27/attachment-0001.html>

[Bug 77274] [drm:dce6_afmt_write_speaker_allocation] *ERROR* Couldn't read Speaker Allocation Data Block: 0

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

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

--- Comment #10 from Alex Deucher  ---
(In reply to comment #9)
> I've compiled a new 3.14 vanilla kernel with this patch:
> 
> https://bugs.freedesktop.org/attachment.cgi?id=97049&action=edit
> 
> the result was that the audio over HDMI becomes working again but the above
> mentioned error in my dmesg is still there.

The error is harmless.  It just means your monitor does not provide a speaker
allocation block in the edid.

-- 
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/20140411/24d63132/attachment.html>

[PATCH] drm/radeon: Inline r100_mm_rreg

[Lauri Kasanen]

On Fri, 11 Apr 2014 10:33:08 +0200
Christian K?nig  wrote:

> >> Actually direct register access shouldn't be necessary so often. Apart
> >> from page flips, write/read pointer updates and irq processing there
> >> shouldn't be so many of them. Could you clarify a bit more what issue
> >> you are seeing here?
> > Too much cpu usage for such a simple function. 2% makes it #2 in top-10
> > radeon.ko functions, right after evergreen_cs_parse. For reference, #3
> > (radeon_cs_packet_parse) is only 0.5%, one fourth of this function's
> > usage.
> 
> I think you misunderstood me here. I do believe your numbers that it 
> makes a noticeable difference.
> 
> But I've did a couple of perf tests recently on SI and CIK while hacking 
> on VM support, and IIRC r100_mm_rreg didn't showed up in the top 10 on 
> those systems.
> 
> So what puzzles me is who the hack is calling r100_mm_rreg so often that 
> it makes a noticeable difference on evergreen/NI?

The biggest caller is cayman_cp_int_cntl_setup. Before inlining it took
0.0013%, after it takes 1%.

This is on a Richland APU, so Aruba/Cayman. Urban Terror is an ioq3
game with a lot of cpu-side vertex submissions.

- Lauri

[PATCH 6/6] drm/omap: protect omap_crtc's event with event_lock spinlock

[Archit Taneja]

The vblank_cb callback and the page_flip ioctl can occur together in different
CPU contexts. vblank_cb uses takes tje drm device's event_lock spinlock when
sending the vblank event and updating omap_crtc->event and omap_crtc->od_fb.

Use the same spinlock in page_flip, to make sure the above omap_crtc parameters
are configured sequentially.

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/omapdrm/omap_crtc.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index d74c72c..9c7af42 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -350,6 +350,7 @@ static int omap_crtc_page_flip_locked(struct drm_crtc *crtc,
struct drm_device *dev = crtc->dev;
struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
struct drm_gem_object *bo;
+   unsigned long flags;

DBG("%d -> %d (event=%p)", crtc->fb ? crtc->fb->base.id : -1,
fb->base.id, event);
@@ -359,9 +360,12 @@ static int omap_crtc_page_flip_locked(struct drm_crtc 
*crtc,
return -EINVAL;
}

+   spin_lock_irqsave(&dev->event_lock, flags);
+
omap_crtc->event = event;
omap_crtc->old_fb = crtc->fb = fb;

+   spin_unlock_irqrestore(&dev->event_lock, flags);
/*
 * Hold a reference temporarily until the crtc is updated
 * and takes the reference to the bo.  This avoids it
-- 
1.8.3.2

[PATCH 5/6] drm/omap: Use old_fb to synchronize between successive page flips

[Archit Taneja]

omap_crtc->old_fb is used to check whether the previous page flip has completed
or not. However, it's never initialized to anything, so it's always NULL. This
results in the check to always succeed, and the page_flip to proceed.

Initialize old_fb to the fb that we intend to flip to through page_flip, and
therefore prevent a future page flip to proceed if the last one didn't
complete.

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/omapdrm/omap_crtc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 62f28df..d74c72c 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -360,7 +360,7 @@ static int omap_crtc_page_flip_locked(struct drm_crtc *crtc,
}

omap_crtc->event = event;
-   crtc->fb = fb;
+   omap_crtc->old_fb = crtc->fb = fb;

/*
 * Hold a reference temporarily until the crtc is updated
-- 
1.8.3.2

[PATCH 4/6] drm/omap: Allow allocation of larger buffers

[Archit Taneja]

The drm ioctl DRM_IOCTL_MODE_ADDFB2 doesn't let us allocate buffers which are
greater than what is specified in the driver through dev->mode_config.

Create helpers for DISPC which return the max manager width and height supported
by the device. The maximum width for a framebuffer is set to the combined width
of the all the crtcs, assuming they are arranged horizontally.

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/omapdrm/omap_drv.c | 10 ++
 drivers/video/omap2/dss/dispc.c| 12 
 include/video/omapdss.h|  2 ++
 3 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
b/drivers/gpu/drm/omapdrm/omap_drv.c
index c8270e4..55ec575 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -306,11 +306,13 @@ static int omap_modeset_init(struct drm_device *dev)
dev->mode_config.min_width = 32;
dev->mode_config.min_height = 32;

-   /* note: eventually will need some cpu_is_omapXYZ() type stuff here
-* to fill in these limits properly on different OMAP generations..
+   /*
+* Note: the maximum width is set to the combined width of all the
+* crtcs. We could assume the same for the maximum height too, but
+* we generally don't use such a configuration.
 */
-   dev->mode_config.max_width = 2048;
-   dev->mode_config.max_height = 2048;
+   dev->mode_config.max_width = num_crtcs * dispc_mgr_max_width();
+   dev->mode_config.max_height = dispc_mgr_max_height();

dev->mode_config.funcs = &omap_mode_config_funcs;

diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 77d6221..47f9829 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -2999,6 +2999,18 @@ void dispc_mgr_set_timings(enum omap_channel channel,
 }
 EXPORT_SYMBOL(dispc_mgr_set_timings);

+u16 dispc_mgr_max_width(void)
+{
+   return dispc.feat->mgr_width_max;
+}
+EXPORT_SYMBOL(dispc_mgr_max_width);
+
+u16 dispc_mgr_max_height(void)
+{
+   return dispc.feat->mgr_height_max;
+}
+EXPORT_SYMBOL(dispc_mgr_max_height);
+
 static void dispc_mgr_set_lcd_divisor(enum omap_channel channel, u16 lck_div,
u16 pck_div)
 {
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index 3d7c51a..53637ac 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -949,6 +949,8 @@ void dispc_mgr_set_lcd_config(enum omap_channel channel,
const struct dss_lcd_mgr_config *config);
 void dispc_mgr_set_timings(enum omap_channel channel,
const struct omap_video_timings *timings);
+u16 dispc_mgr_max_width(void);
+u16 dispc_mgr_max_height(void);
 void dispc_mgr_setup(enum omap_channel channel,
const struct omap_overlay_manager_info *info);

-- 
1.8.3.2

[PATCH 3/6] drm/omap: Fix crash when using LCD3 overlay manager

[Archit Taneja]

The channel_names list didn't have a string populated for LCD3 manager, this
results in a crash when the display's output is connected to LCD3. Add an entry
for LCD3.

Reported-by: Somnath Mukherjee 
Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/omapdrm/omap_crtc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 90916ab..62f28df 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -654,6 +654,7 @@ static const char *channel_names[] = {
[OMAP_DSS_CHANNEL_LCD] = "lcd",
[OMAP_DSS_CHANNEL_DIGIT] = "tv",
[OMAP_DSS_CHANNEL_LCD2] = "lcd2",
+   [OMAP_DSS_CHANNEL_LCD3] = "lcd3",
 };

 void omap_crtc_pre_init(void)
-- 
1.8.3.2

[PATCH 2/6] drm/omap: gem sync: wait on correct events

[Archit Taneja]

A waiter of the type OMAP_GEM_READ should wait for a buffer to be completely
written, and only then proceed with reading it. A similar logic applies for
waiters with OMAP_GEM_WRITE flag.

Currently the function is_waiting() waits on the read_complete/read_target
counts in the sync object.

This should be the other way round, as a reader should wait for users who are
'writing' to this buffer, and vice versa.

Make readers of the buffer(OMAP_GEM_READ) wait on the write counters, and
writers to the buffer(OMAP_GEM_WRITE) wait on the read counters in is_waiting()

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/omapdrm/omap_gem.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c 
b/drivers/gpu/drm/omapdrm/omap_gem.c
index 3199e3f..002b89d7 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -1050,10 +1050,10 @@ static inline bool is_waiting(struct 
omap_gem_sync_waiter *waiter)
 {
struct omap_gem_object *omap_obj = waiter->omap_obj;
if ((waiter->op & OMAP_GEM_READ) &&
-   (omap_obj->sync->read_complete < waiter->read_target))
+   (omap_obj->sync->write_complete < waiter->write_target))
return true;
if ((waiter->op & OMAP_GEM_WRITE) &&
-   (omap_obj->sync->write_complete < waiter->write_target))
+   (omap_obj->sync->read_complete < waiter->read_target))
return true;
return false;
 }
-- 
1.8.3.2

[PATCH 1/6] drm/omap: Fix memory leak in omap_gem_op_async

[Archit Taneja]

From: Subhajit Paul 

In omap_gem_op_async(), if a waiter is not added to the wait list, it needs to
be free'd in the function itself.

Make sure we free the waiter for this case.

Signed-off-by: Subhajit Paul 
Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/omapdrm/omap_gem.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c 
b/drivers/gpu/drm/omapdrm/omap_gem.c
index 5aec3e8..3199e3f 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -1229,6 +1229,8 @@ int omap_gem_op_async(struct drm_gem_object *obj, enum 
omap_gem_op op,
}

spin_unlock(&sync_lock);
+
+   kfree(waiter);
}

/* no waiting.. */
-- 
1.8.3.2

[PATCH 0/6] drm/omap: Misc fixes

[Archit Taneja]

These are based over Tomi's 3.15/omapdrm-fixes branch.

Archit Taneja (5):
  drm/omap: gem sync: wait on correct events
  drm/omap: Fix crash when using LCD3 overlay manager
  drm/omap: Allow allocation of larger buffers
  drm/omap: Use old_fb to synchronize between successive page flips
  drm/omap: protect omap_crtc's event with event_lock spinlock

Subhajit Paul (1):
  drm/omap: Fix memory leak in omap_gem_op_async

 drivers/gpu/drm/omapdrm/omap_crtc.c |  7 ++-
 drivers/gpu/drm/omapdrm/omap_drv.c  | 10 ++
 drivers/gpu/drm/omapdrm/omap_gem.c  |  6 --
 drivers/video/omap2/dss/dispc.c | 12 
 include/video/omapdss.h |  2 ++
 5 files changed, 30 insertions(+), 7 deletions(-)

-- 
1.8.3.2

[Bug 50091] [BISECTED]GeForce 6150SE: system hangs on X-server start with garbled screen

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

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

--- Comment #33 from Dzianis Kahanovich  ---
Created attachment 131911
  --> https://bugzilla.kernel.org/attachment.cgi?id=131911&action=edit
patch: port from <3.7

Try this patch. I have some happy uptime (I have this Gigabyte mb on work
desktop and use 3.4 before), but this bug can be too unpredictable. This is
port of similar aligning from <3.7, just minimized. Also I don't move
"misaligned reg" warning, as nobody cares from 2012. I copy old notes in
comments, so you can find original similar places (was: if (reg & 0x1)
reg&=...) by this comments.

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

Possible fb ref count issue with drm_plane_force_disable()

[Archit Taneja]

On Friday 11 April 2014 12:10 PM, Tomi Valkeinen wrote:



>> Does drm_framebuffer_remove get called when we abort the application, or
>> unload omapdrm, or both?
>
> Both. When we abort an app, drm_framebuffer_remove gets called for the
> fb that the app created. When we unload omapdrm, it gets called for the
> main fb, used for fb console.
>
>>> - fb->refcount.refcount > 1, so it goes to disable stuff
>>>
>>> - drm_plane_force_disable is called for the primary plane
>>
>> Maybe we need to make sure that this func is called only when our driver
>> has unreferenced it. In that case, we would probably need to flush our
>> queue and disable interrupts(so that we don't queue more work).
>
> Hmm, sorry, call which func, unreferenced what? =)
>
> Do you mean we should call drm_framebuffer_remove() only if
> fb->refcount.refcount == 1. That should be possible, and would probably
> remove the issue, but it would just be going around the actual problem.

Yes, I meant our driver should call drm_framebuffer_remove() only when 
we are know that the fb reference omapdrm had taken(the one in 
update_pin), has a corresponding fb unref called(in unpin_worker).

Isn't that something omapdrm should take care of?



>> I can't get the corresponding reference for it either. But I can count 3
>> of them when you run fbcon with drm's fb helper.
>>
>> - One ref is taken in the drm_framebuffer_init called from
>> omap_fbdev_create.
>>
>> - fbcon will call fb_set_par, which calls drm_fb_helper_set_par, that
>> seems to take a refernce to the fb in the end.
>
> This one is not called for a normal app, as there's no fbdev framebuffer
> for it. Note that the funcs I mention deal with drm framebuffer, which
> is not the fbdev framebuffer (confusing =). fbdev fb is only used for
> the "root" framebuffer. And, of course, fbdev fb uses the drm fb

Yes. In the case of a normal app, we would call the ADD_FB2 ioctl to get 
a drm_framebuffer, that will internally take a fb reference. So the 
count won't seem to go beyond 2.

> functionality.
>
>> - drm_crtc_helper_set_config() calls the omadrm specific mode_set
>> drm_crtc_funcs, which eventually calls a drm_framebuffer_reference in
>> update_pin().
>
> Yep.
>
> I forgot to mention that if I comment out the unref in
> drm_plane_force_disable(), the ref counts match and all looks fine. And
> also that I didn't see this issue with 3.14.

That's strange. I guess there must be an extra unref happening somewhere 
in the newer commits. Did you try a diff of drm code between the 2 
kernels? :)

Archit

[PATCH v1 17/19] drm: sti: Add DRM driver itself

[Daniel Vetter]

On Tue, Apr 08, 2014 at 02:19:24PM +0200, Benjamin Gaignard wrote:
> Make the link between all the hardware drivers and DRM/KMS interface.
> Create the driver itself and make it register all the sub-components.
> Use GEM CMA helpers for buffer allocation.
> 
> Signed-off-by: Benjamin Gaignard 
> Signed-off-by: Vincent Abriou 
> Signed-off-by: Fabien Dessenne 
> ---
>  drivers/gpu/drm/sti/Kconfig |   8 +
>  drivers/gpu/drm/sti/Makefile|  28 +-
>  drivers/gpu/drm/sti/sti_compositor.c|   2 +
>  drivers/gpu/drm/sti/sti_drm_connector.c | 195 +
>  drivers/gpu/drm/sti/sti_drm_connector.h |  16 ++
>  drivers/gpu/drm/sti/sti_drm_crtc.c  | 440 ++
>  drivers/gpu/drm/sti/sti_drm_crtc.h  |  21 ++
>  drivers/gpu/drm/sti/sti_drm_drv.c   | 466 
> 
>  drivers/gpu/drm/sti/sti_drm_encoder.c   | 201 ++
>  drivers/gpu/drm/sti/sti_drm_encoder.h   |  16 ++
>  drivers/gpu/drm/sti/sti_drm_plane.c | 195 +
>  drivers/gpu/drm/sti/sti_drm_plane.h |  16 ++
>  drivers/gpu/drm/sti/sti_vtg_utils.h |   2 +
>  13 files changed, 1594 insertions(+), 12 deletions(-)
>  create mode 100644 drivers/gpu/drm/sti/sti_drm_connector.c
>  create mode 100644 drivers/gpu/drm/sti/sti_drm_connector.h
>  create mode 100644 drivers/gpu/drm/sti/sti_drm_crtc.c
>  create mode 100644 drivers/gpu/drm/sti/sti_drm_crtc.h
>  create mode 100644 drivers/gpu/drm/sti/sti_drm_drv.c
>  create mode 100644 drivers/gpu/drm/sti/sti_drm_encoder.c
>  create mode 100644 drivers/gpu/drm/sti/sti_drm_encoder.h
>  create mode 100644 drivers/gpu/drm/sti/sti_drm_plane.c
>  create mode 100644 drivers/gpu/drm/sti/sti_drm_plane.h
> 
> diff --git a/drivers/gpu/drm/sti/Kconfig b/drivers/gpu/drm/sti/Kconfig
> index a958398..61c8bd4 100644
> --- a/drivers/gpu/drm/sti/Kconfig
> +++ b/drivers/gpu/drm/sti/Kconfig
> @@ -1,10 +1,18 @@
>  config DRM_STI
>   tristate "DRM Support for STMicroelectronics SoC stiH41x Series"
>   depends on DRM && (SOC_STIH415 || SOC_STIH416 || ARCH_MULTIPLATFORM)
> + select DRM_KMS_HELPER
> + select DRM_GEM_CMA_HELPER
>   select DRM_KMS_CMA_HELPER
>   help
> Choose this option to enable DRM on STM stiH41x chipset
>  
> +config DRM_STI_FBDEV
> + tristate "DRM frame buffer device for STMicroelectronics SoC stiH41x 
> Serie"
> + depends on DRM_STI
> + help
> +   Choose this option to enable FBDEV on top of DRM for STM stiH41x 
> chipset
> +
>  config VTAC_STI
>   tristate "Video Trafic Advance Communication Rx and Tx for 
> STMicroelectronics SoC stiH41x Series"
>   depends on DRM_STI
> diff --git a/drivers/gpu/drm/sti/Makefile b/drivers/gpu/drm/sti/Makefile
> index d598adc..17b4a68 100644
> --- a/drivers/gpu/drm/sti/Makefile
> +++ b/drivers/gpu/drm/sti/Makefile
> @@ -1,17 +1,21 @@
>  ccflags-y := -Iinclude/drm
>  
> -stidrm-y := \
> - sti_compositor.o \
> - sti_mixer.o \
> - sti_layer.o \
> - sti_gdp.o \
> - sti_vid.o \
> - sti_tvout.o \
> - sti_hdmi.o \
> - sti_hdmi_tx3g0c55phy.o \
> - sti_hdmi_tx3g4c28phy.o \
> - sti_hda.o \
> - sti_ddc.o
> +stidrm-y := sti_drm_drv.o \
> + sti_drm_crtc.o \
> + sti_drm_plane.o \
> + sti_drm_connector.o \
> + sti_drm_encoder.o \
> + sti_compositor.o \
> + sti_mixer.o \
> + sti_layer.o \
> + sti_gdp.o \
> + sti_vid.o \
> + sti_tvout.o \
> + sti_hdmi.o \
> + sti_hdmi_tx3g0c55phy.o \
> + sti_hdmi_tx3g4c28phy.o \
> + sti_hda.o \
> + sti_ddc.o
>  
>  obj-$(CONFIG_DRM_STI) += stidrm.o
>  obj-$(CONFIG_VTAC_STI) += sti_vtac_tx.o sti_vtac_rx.o
> diff --git a/drivers/gpu/drm/sti/sti_compositor.c 
> b/drivers/gpu/drm/sti/sti_compositor.c
> index a163344..4d8d0958 100644
> --- a/drivers/gpu/drm/sti/sti_compositor.c
> +++ b/drivers/gpu/drm/sti/sti_compositor.c
> @@ -14,6 +14,7 @@
>  
>  #include "sti_compositor.h"
>  #include "sti_gdp.h"
> +#include "sti_drm_crtc.h"
>  
>  static const struct of_device_id compositor_match_types[];
>  
> @@ -98,6 +99,7 @@ static int sti_compositor_probe(struct platform_device 
> *pdev)
>   }
>   DRM_DEBUG_DRIVER("Compositor %p\n", compo);
>   compo->dev = dev;
> + compo->vtg_vblank_nb.notifier_call = sti_drm_crtc_vblank_cb;
>  
>   /* populate data structure depending on compatibility */
>   BUG_ON(!of_match_node(compositor_match_types, np)->data);
> diff --git a/drivers/gpu/drm/sti/sti_drm_connector.c 
> b/drivers/gpu/drm/sti/sti_drm_connector.c
> new file mode 100644
> index 000..b34a402
> --- /dev/null
> +++ b/drivers/gpu/drm/sti/sti_drm_connector.c
> @@ -0,0 +1,195 @@
> +/*
> + * Copyright (C) STMicroelectronics SA 2013
> + * Author: Benjamin Gaignard  for 
> STMicroelectronics.
> + * License terms:  GNU General Public License (GPL), version 2
> + */
> +
> +#include

[Bug 75992] Display freezes & corruption with an r7 260x on 3.14-rc6

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

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

--- Comment #46 from Ed Tomlinson  ---
Tests were run with hyperz disabled as per my comments above.  With hyperz
enabled, with the new firmware, I am NOT seeing the gpu faults shown above. 
Mesa 10.2 and DDX are from yesterday's git.

-- 
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/20140411/8e51c62f/attachment.html>

[PATCH 2/2] [RFC v2 with seqcount] reservation: add suppport for read-only access using rcu

[Thomas Hellstrom]

On 04/11/2014 11:24 AM, Maarten Lankhorst wrote:
> op 11-04-14 10:38, Thomas Hellstrom schreef:
>> Hi, Maarten.
>>
>> Here I believe we encounter a lot of locking inconsistencies.
>>
>> First, it seems you're use a number of pointers as RCU pointers without
>> annotating them as such and use the correct rcu
>> macros when assigning those pointers.
>>
>> Some pointers (like the pointers in the shared fence list) are both used
>> as RCU pointers (in dma_buf_poll()) for example,
>> or considered protected by the seqlock
>> (reservation_object_get_fences_rcu()), which I believe is OK, but then
>> the pointers must
>> be assigned using the correct rcu macros. In the memcpy in
>> reservation_object_get_fences_rcu() we might get away with an
>> ugly typecast, but with a verbose comment that the pointers are
>> considered protected by the seqlock at that location.
>>
>> So I've updated (attached) the headers with proper __rcu annotation and
>> locking comments according to how they are being used in the various
>> reading functions.
>> I believe if we want to get rid of this we need to validate those
>> pointers using the seqlock as well.
>> This will generate a lot of sparse warnings in those places needing
>> rcu_dereference()
>> rcu_assign_pointer()
>> rcu_dereference_protected()
>>
>> With this I think we can get rid of all ACCESS_ONCE macros: It's not
>> needed when the rcu_x() macros are used, and
>> it's never needed for the members protected by the seqlock, (provided
>> that the seq is tested). The only place where I think that's
>> *not* the case is at the krealloc in
>> reservation_object_get_fences_rcu().
>>
>> Also I have some more comments in the
>> reservation_object_get_fences_rcu() function below:
> I felt that the barriers needed for rcu were already provided by
> checking the seqcount lock.
> But looking at rcu_dereference makes it seem harmless to add it in
> more places, it handles
> the ACCESS_ONCE and barrier() for us.

And it makes the code more maintainable, and helps sparse doing a lot of
checking for us. I guess
we can tolerate a couple of extra barriers for that.

>
> We could probably get away with using RCU_INIT_POINTER on the writer
> side,
> because the smp_wmb is already done by arranging seqcount updates
> correctly.

Hmm. yes, probably. At least in the replace function. I think if we do
it in other places, we should add comments as to where
the smp_wmb() is located, for future reference.


Also  I saw in a couple of places where you're checking the shared
pointers, you're not checking for NULL pointers, which I guess may
happen if shared_count and pointers are not in full sync?

Thanks,
/Thomas


>
>> diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
>> index d89a98d2c37b..ca6ef0c4b358 100644
>> --- a/drivers/base/dma-buf.c
>> +++ b/drivers/base/dma-buf.c
>>
>> +int reservation_object_get_fences_rcu(struct reservation_object *obj,
>> +  struct fence **pfence_excl,
>> +  unsigned *pshared_count,
>> +  struct fence ***pshared)
>> +{
>> +unsigned shared_count = 0;
>> +unsigned retry = 1;
>> +struct fence **shared = NULL, *fence_excl = NULL;
>> +int ret = 0;
>> +
>> +while (retry) {
>> +struct reservation_object_list *fobj;
>> +unsigned seq, retry;
>> You're shadowing retry?
> Oops.
>>
>>> +
>>> +seq = read_seqcount_begin(&obj->seq);
>>> +
>>> +rcu_read_lock();
>>> +
>>> +fobj = ACCESS_ONCE(obj->fence);
>>> +if (fobj) {
>>> +struct fence **nshared;
>>> +
>>> +shared_count = ACCESS_ONCE(fobj->shared_count);
>>> +nshared = krealloc(shared, sizeof(*shared) *
>>> shared_count, GFP_KERNEL);
>> krealloc inside rcu_read_lock(). Better to put this first in the loop.
> Except that shared_count isn't known until the rcu_read_lock is taken.
>> Thanks,
>> Thomas
> ~Maarten

Possible fb ref count issue with drm_plane_force_disable()

[Archit Taneja]

Hi,

On Thursday 10 April 2014 05:17 PM, Tomi Valkeinen wrote:
> Hi,
>
> I've been debugging omapdrm issues on top of the latest drm mainline
> changes. Sometimes a drm_framebuffer ref count drops to -1 when aborting
> a drm application, or unloading the modules.
>
> The setup is very basic, just a single crtc with the crtc's primary plane.
>
> What seems to happen is:
>
> - App is started
>
> - fb is created, and taken into use by omapdrm. omapdrm takes a ref to
> the fb.
>
> - the app is starts to shut down
>
> - drm_framebuffer_remove is called

Does drm_framebuffer_remove get called when we abort the application, or 
unload omapdrm, or both?

>
> - fb->refcount.refcount > 1, so it goes to disable stuff
>
> - drm_plane_force_disable is called for the primary plane

Maybe we need to make sure that this func is called only when our driver 
has unreferenced it. In that case, we would probably need to flush our 
queue and disable interrupts(so that we don't queue more work).

>
> - drm_plane_force_disable does plane->disable_plane, which on omapdrm
> puts stuff on a workqueue as plane cannot be disabled immediately
>
> - drm_plane_force_disable calls __drm_framebuffer_unreference()
>
> - at the end of drm_framebuffer_remove(), there's
> drm_framebuffer_unreference, which causes ref count to go to zero, and
> the fb to be destroyed
>
> - a bit later, the queued work is ran, which does
> drm_framebuffer_unreference(), and ref count goes to -1. Here omapdrm is
> removing the ref that had been taken in the beginning.
>
>
> So the explicit unref done by drm_plane_force_disable() seems a bit out
> of place. I can't figure out which drm_framebuffer_reference() would be
> the matching one for the unref done by drm_plane_force_disable().
>
> Any ideas what ref is that? Or is the __drm_framebuffer_unreference()
> extra in drm_plane_force_disable()?


I can't get the corresponding reference for it either. But I can count 3 
of them when you run fbcon with drm's fb helper.

- One ref is taken in the drm_framebuffer_init called from 
omap_fbdev_create.

- fbcon will call fb_set_par, which calls drm_fb_helper_set_par, that 
seems to take a refernce to the fb in the end.

- drm_crtc_helper_set_config() calls the omadrm specific mode_set 
drm_crtc_funcs, which eventually calls a drm_framebuffer_reference in 
update_pin().

Archit

[Bug 75992] Display freezes & corruption with an r7 260x on 3.14-rc6

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

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

--- Comment #45 from Ed Tomlinson  ---
Good news.

I rebuilt linux-git with the newer mc ucode patch and manually replaced the
BONAIRE_mc.bin firmware file and rebuilt my initrd.

uniengine tropical completes at 33fps (fullscreen 1920x1200)
uniengine sanctuary completes at 45fps (fullscreen 1920x1200)

tropical is the test that usually killed things quickly.  It ran at about 30fps
when it worked at all on .14 and about 40fps on .15 with old firmware.  fglrx
manages about 80fps.

That being said the new firmware is not as fluid as the older.  There are times
that there are hesitations when the camera is panning which I did not notice
previously.  However my tests do run without stalling or corruption.

Would you like me to test with and without the patch on .14?

You can add my tested-by to the 'newer mc ucode patch' for linux-git

'Tested-by: Ed Tomlinson '

THANKS!

-- 
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/20140411/d2f0200e/attachment.html>

[PATCH 02/12] drm/nouveau/timer: skip calibration on GK20A

[Alexandre Courbot]

On Wed, Mar 26, 2014 at 1:19 PM, Ben Skeggs  wrote:
> On Tue, Mar 25, 2014 at 7:54 AM, Thierry Reding
>  wrote:
>> On Mon, Mar 24, 2014 at 05:42:24PM +0900, Alexandre Courbot wrote:
>>> GK20A's timer is directly attached to the system timer and cannot be
>>> calibrated. Skip the calibration phase on that chip since the
>>> corresponding registers do not exist.
>>>
>>> Signed-off-by: Alexandre Courbot 
>>> ---
>>>  drivers/gpu/drm/nouveau/core/subdev/timer/nv04.c | 19 +--
>>>  1 file changed, 13 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/nouveau/core/subdev/timer/nv04.c 
>>> b/drivers/gpu/drm/nouveau/core/subdev/timer/nv04.c
>>> index c0bdd10358d7..822fe0d8a871 100644
>>> --- a/drivers/gpu/drm/nouveau/core/subdev/timer/nv04.c
>>> +++ b/drivers/gpu/drm/nouveau/core/subdev/timer/nv04.c
>>> @@ -185,6 +185,10 @@ nv04_timer_init(struct nouveau_object *object)
>>>   if (ret)
>>>   return ret;
>>>
>>> + /* gk20a does not have the calibration registers */
>>> + if (device->chipset == 0xea)
>>> + goto skip_clk_init;
>>
>> I'm concerned that this won't scale in the future. Perhaps a better
>> solution would be to add a "flags" or "features" field to struct
>> nouveau_device along with feature bits such as HAS_CALIBRATION or
>> similar.
>>
>> That way we don't have to touch this code for every new future Tegra
>> chip. Unless perhaps if there's a reason to expect things to change in
>> newer generations.
> I've already handled this in a slightly different way in the tree I'd
> previously pointed Alex at (I think!), as I needed to do the same for
> GM107.
>
> Should just be able to use that implementation (so, just change the
> probe patch) here too.

I will skip this patch and use your implementation then. Btw,
shouldn't the source file for the GK20A implementation be named nvea.c
instead of gk20a.c?

[PATCH] drm/radeon: apply more strict limits for PLL params v2

[Alex Deucher]

On Fri, Apr 11, 2014 at 11:24 AM, Christian K?nig
 wrote:
> From: Christian K?nig 
>
> Letting post and refernce divider get to big is bad for signal stability.
>
> v2: increase the limit to 210

Maybe mention the bug number?

>
> Signed-off-by: Christian K?nig 

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/radeon/radeon_display.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
> b/drivers/gpu/drm/radeon/radeon_display.c
> index 386cfa4..2f42912 100644
> --- a/drivers/gpu/drm/radeon/radeon_display.c
> +++ b/drivers/gpu/drm/radeon/radeon_display.c
> @@ -937,6 +937,9 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll,
> }
> post_div = post_div_best;
>
> +   /* limit reference * post divider to a maximum */
> +   ref_div_max = min(210 / post_div, ref_div_max);
> +
> /* get matching reference and feedback divider */
> ref_div = max(den / post_div, 1u);
> fb_div = nom;
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] [RFC v2 with seqcount] reservation: add suppport for read-only access using rcu

[Maarten Lankhorst]

op 11-04-14 10:38, Thomas Hellstrom schreef:
> Hi, Maarten.
>
> Here I believe we encounter a lot of locking inconsistencies.
>
> First, it seems you're use a number of pointers as RCU pointers without
> annotating them as such and use the correct rcu
> macros when assigning those pointers.
>
> Some pointers (like the pointers in the shared fence list) are both used
> as RCU pointers (in dma_buf_poll()) for example,
> or considered protected by the seqlock
> (reservation_object_get_fences_rcu()), which I believe is OK, but then
> the pointers must
> be assigned using the correct rcu macros. In the memcpy in
> reservation_object_get_fences_rcu() we might get away with an
> ugly typecast, but with a verbose comment that the pointers are
> considered protected by the seqlock at that location.
>
> So I've updated (attached) the headers with proper __rcu annotation and
> locking comments according to how they are being used in the various
> reading functions.
> I believe if we want to get rid of this we need to validate those
> pointers using the seqlock as well.
> This will generate a lot of sparse warnings in those places needing
> rcu_dereference()
> rcu_assign_pointer()
> rcu_dereference_protected()
>
> With this I think we can get rid of all ACCESS_ONCE macros: It's not
> needed when the rcu_x() macros are used, and
> it's never needed for the members protected by the seqlock, (provided
> that the seq is tested). The only place where I think that's
> *not* the case is at the krealloc in reservation_object_get_fences_rcu().
>
> Also I have some more comments in the
> reservation_object_get_fences_rcu() function below:
I felt that the barriers needed for rcu were already provided by checking the 
seqcount lock.
But looking at rcu_dereference makes it seem harmless to add it in more places, 
it handles
the ACCESS_ONCE and barrier() for us.

We could probably get away with using RCU_INIT_POINTER on the writer side,
because the smp_wmb is already done by arranging seqcount updates correctly.

> diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
> index d89a98d2c37b..ca6ef0c4b358 100644
> --- a/drivers/base/dma-buf.c
> +++ b/drivers/base/dma-buf.c
>
> +int reservation_object_get_fences_rcu(struct reservation_object *obj,
> +  struct fence **pfence_excl,
> +  unsigned *pshared_count,
> +  struct fence ***pshared)
> +{
> +unsigned shared_count = 0;
> +unsigned retry = 1;
> +struct fence **shared = NULL, *fence_excl = NULL;
> +int ret = 0;
> +
> +while (retry) {
> +struct reservation_object_list *fobj;
> +unsigned seq, retry;
> You're shadowing retry?
Oops.
>
>> +
>> +seq = read_seqcount_begin(&obj->seq);
>> +
>> +rcu_read_lock();
>> +
>> +fobj = ACCESS_ONCE(obj->fence);
>> +if (fobj) {
>> +struct fence **nshared;
>> +
>> +shared_count = ACCESS_ONCE(fobj->shared_count);
>> +nshared = krealloc(shared, sizeof(*shared) *
>> shared_count, GFP_KERNEL);
> krealloc inside rcu_read_lock(). Better to put this first in the loop.
Except that shared_count isn't known until the rcu_read_lock is taken.
> Thanks,
> Thomas
~Maarten

[PATCH 3/3] drm/radeon: re-enable mclk dpm on R7 260X asics

[Alex Deucher]

If the new mc ucode is available.

Signed-off-by: Alex Deucher 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/ci_dpm.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c
index 18e91ee..10dae41 100644
--- a/drivers/gpu/drm/radeon/ci_dpm.c
+++ b/drivers/gpu/drm/radeon/ci_dpm.c
@@ -21,8 +21,10 @@
  *
  */

+#include 
 #include "drmP.h"
 #include "radeon.h"
+#include "radeon_ucode.h"
 #include "cikd.h"
 #include "r600_dpm.h"
 #include "ci_dpm.h"
@@ -5147,9 +5149,11 @@ int ci_dpm_init(struct radeon_device *rdev)
pi->mclk_dpm_key_disabled = 0;
pi->pcie_dpm_key_disabled = 0;

-   /* mclk dpm is unstable on some R7 260X cards */
-   if (rdev->pdev->device == 0x6658)
+   /* mclk dpm is unstable on some R7 260X cards with the old mc ucode */
+   if ((rdev->pdev->device == 0x6658) &&
+   (rdev->mc_fw->size == (BONAIRE_MC_UCODE_SIZE * 4))) {
pi->mclk_dpm_key_disabled = 1;
+   }

pi->caps_sclk_ds = true;

-- 
1.8.3.1