[PATCH 6/6] drm/nouveau: use MSI interrupts

[Ilia Mirkin]

On Wed, Aug 28, 2013 at 8:07 PM, Ben Skeggs  wrote:
> On Wed, Aug 28, 2013 at 11:54 PM, Ilia Mirkin  wrote:
>> On Wed, Aug 28, 2013 at 3:28 AM, Lucas Stach  wrote:
>>> Am Mittwoch, den 28.08.2013, 17:09 +1000 schrieb Ben Skeggs:
 On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach  wrote:
 > MSIs were only problematic on some old, broken chipsets. But now that we
 > already see systems where PCI legacy interrupts are somewhat flaky, it's
 > really time to move to MSIs.
 >
 > Signed-off-by: Lucas Stach 
 > ---
 >  drivers/gpu/drm/nouveau/core/include/subdev/mc.h |  1 +
 >  drivers/gpu/drm/nouveau/core/subdev/mc/base.c| 17 +
 >  2 files changed, 18 insertions(+)
 >
 > diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h 
 > b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
 > index 9d2cd20..ce6569f 100644
 > --- a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
 > +++ b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
 > @@ -12,6 +12,7 @@ struct nouveau_mc_intr {
 >  struct nouveau_mc {
 > struct nouveau_subdev base;
 > const struct nouveau_mc_intr *intr_map;
 > +   bool use_msi;
 >  };
 >
 >  static inline struct nouveau_mc *
 > diff --git a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c 
 > b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
 > index ec9cd6f..02b337e 100644
 > --- a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
 > +++ b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
 > @@ -23,6 +23,7 @@
 >   */
 >
 >  #include 
 > +#include 
 >
 >  static irqreturn_t
 >  nouveau_mc_intr(int irq, void *arg)
 > @@ -43,6 +44,9 @@ nouveau_mc_intr(int irq, void *arg)
 > map++;
 > }
 >
 > +   if (pmc->use_msi)
 > +   nv_wr08(pmc->base.base.parent, 0x00088068, 0xff);
 Register not present everywhere.

 At the very least, the enabling of MSI should be disallowed on the
 earlier chipsets where it's not supported.  Though, it's perhaps
 possible that the pci_enable_msi() call will fail in all of these
 cases anyway.. I'm not certain.

>>> MSIs are required property for everything doing PCIe. So the only cases
>>> where this should fail is plain PCI/AGP devices. I don't really have a
>>> test system for those old cards set up.
>>>
>>> But I remember Ilia having some legacy things plugged in, so maybe he
>>> could test this patch and see how it goes?
>>
>> Sure, let me know what you need -- I have nv18 PCI, nv34 PCIe (note
>> that it's not native PCIe, but some sort of bridge thing IIRC),
> Cases like the nv34 here (i think there's some nv4x that aren't native
> pcie too) are what I'm wondering about primarily.

And rightly so. With the NV18 PCI, NV34 PCIe, NV42 PCIe plugged in,
with "AutoAddGPU" disabled the NV18 and NV42 seem fine. However merely
starting X (not xinit, not startx, not [gkx]dm) on the NV34 and ^C'ing
it (with no clients connecting to said X), causes a "failed to idle
channel" message in dmesg, which apparently never rectifies itself, so
X is hung forever. FTR, there were no displays connected either, but I
tried the exact same procedure without the MSI patch and it worked
fine. Here is the init sequence with the MSI patch:

[  307.049812] nouveau  [  DEVICE][:04:00.0] BOOT0  : 0x034a00b1
[  307.049815] nouveau  [  DEVICE][:04:00.0] Chipset: NV34 (NV34)
[  307.049819] nouveau  [  DEVICE][:04:00.0] Family : NV30
[  307.050648] nouveau  [   VBIOS][:04:00.0] checking PRAMIN for image...
[  307.050652] nouveau  [   VBIOS][:04:00.0] ... signature not found
[  307.050653] nouveau  [   VBIOS][:04:00.0] checking PROM for image...
[  307.195201] nouveau  [   VBIOS][:04:00.0] ... appears to be valid
[  307.195205] nouveau  [   VBIOS][:04:00.0] using image from PROM
[  307.195209] nouveau  [   VBIOS][:04:00.0] BMP version 5.29
[  307.195429] nouveau  [   VBIOS][:04:00.0] version 04.34.20.79.00
[  307.195971] nouveau  [ DEVINIT][:04:00.0] adaptor not initialised
[  307.195979] nouveau  [   VBIOS][:04:00.0] running init tables
[  307.209253] nouveau :04:00.0: irq 47 for MSI/MSI-X
[  307.209266] nouveau  [ PMC][:04:00.0] MSI interrupts enabled
[  307.209281] nouveau W[  PTIMER][:04:00.0] unknown input clock freq
[  307.209288] nouveau  [ PFB][:04:00.0] RAM type: DDR1
[  307.209290] nouveau  [ PFB][:04:00.0] RAM size: 64 MiB
[  307.209292] nouveau  [ PFB][:04:00.0]ZCOMP: 0 tags
[  307.215653] nouveau  [ DRM] VRAM: 63 MiB
[  307.215656] nouveau  [ DRM] GART: 128 MiB
[  307.215659] nouveau  [ DRM] BMP version 5.41
[  307.215662] nouveau  [ DRM] DCB version 2.2
[  307.215666] nouveau  [ DRM] DCB outp 00: 01000300 88b8
[  307.215669] nouveau  [ DRM] DCB outp 01: 02010310 88b8
[  307.215672] nouveau  [ DRM] DCB outp 02: 

[PATCH] cirrus: initialize smem_start and smem_size fields in fb info

[Dominik Behr]

so user space drivers like fbdev can map the memory

Signed-off-by: Dominik Behr 
Reviewed-by: St?phane Marchesin 
---
 drivers/gpu/drm/cirrus/cirrus_fbdev.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/cirrus/cirrus_fbdev.c 
b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
index 6c6b4c8..39e7971 100644
--- a/drivers/gpu/drm/cirrus/cirrus_fbdev.c
+++ b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
@@ -198,6 +198,9 @@ static int cirrusfb_create(struct cirrus_fbdev *gfbdev,
info->screen_base = sysram;
info->screen_size = size;

+   info->fix.smem_start = cdev->dev->mode_config.fb_base;
+   info->fix.smem_len = size;
+
info->fix.mmio_start = 0;
info->fix.mmio_len = 0;

-- 
1.8.4

[PATCH V3] i2c: move of helpers into the core

[Grant Likely]

On Thu, 22 Aug 2013 18:00:14 +0200, Wolfram Sang  wrote:
> I2C of helpers used to live in of_i2c.c but experience (from SPI) shows
> that it is much cleaner to have this in the core. This also removes a
> circular dependency between the helpers and the core, and so we can
> finally register child nodes in the core instead of doing this manually
> in each driver. So, fix the drivers and documentation, too.
> 
> Acked-by: Rob Herring 
> Reviewed-by: Felipe Balbi 
> Acked-by: Rafael J. Wysocki 
> Tested-by: Sylwester Nawrocki 
> Signed-off-by: Wolfram Sang 

Acked-by: Grant Likely 

> ---
> 
> V2->V3: Was trying to be too smart by only fixing includes needed.
>   Took a more general approach this time, converting of_i2c.h
>   to i2c.h in case i2c.h was not already there. Otherwise
>   remove it. Improved my build scripts and no build failures,
>   no complaints from buildbot as well.
> 
> 
>  Documentation/acpi/enumeration.txt  |1 -
>  arch/powerpc/platforms/44x/warp.c   |1 -
>  drivers/gpu/drm/tilcdc/tilcdc_slave.c   |1 -
>  drivers/gpu/drm/tilcdc/tilcdc_tfp410.c  |1 -
>  drivers/gpu/host1x/drm/output.c |2 +-
>  drivers/i2c/busses/i2c-at91.c   |3 -
>  drivers/i2c/busses/i2c-cpm.c|6 --
>  drivers/i2c/busses/i2c-davinci.c|2 -
>  drivers/i2c/busses/i2c-designware-platdrv.c |2 -
>  drivers/i2c/busses/i2c-gpio.c   |3 -
>  drivers/i2c/busses/i2c-i801.c   |2 -
>  drivers/i2c/busses/i2c-ibm_iic.c|4 -
>  drivers/i2c/busses/i2c-imx.c|3 -
>  drivers/i2c/busses/i2c-mpc.c|2 -
>  drivers/i2c/busses/i2c-mv64xxx.c|3 -
>  drivers/i2c/busses/i2c-mxs.c|3 -
>  drivers/i2c/busses/i2c-nomadik.c|3 -
>  drivers/i2c/busses/i2c-ocores.c |3 -
>  drivers/i2c/busses/i2c-octeon.c |3 -
>  drivers/i2c/busses/i2c-omap.c   |3 -
>  drivers/i2c/busses/i2c-pnx.c|3 -
>  drivers/i2c/busses/i2c-powermac.c   |9 +-
>  drivers/i2c/busses/i2c-pxa.c|2 -
>  drivers/i2c/busses/i2c-s3c2410.c|2 -
>  drivers/i2c/busses/i2c-sh_mobile.c  |2 -
>  drivers/i2c/busses/i2c-sirf.c   |3 -
>  drivers/i2c/busses/i2c-stu300.c |2 -
>  drivers/i2c/busses/i2c-tegra.c  |3 -
>  drivers/i2c/busses/i2c-versatile.c  |2 -
>  drivers/i2c/busses/i2c-wmt.c|3 -
>  drivers/i2c/busses/i2c-xiic.c   |3 -
>  drivers/i2c/i2c-core.c  |  109 +-
>  drivers/i2c/i2c-mux.c   |3 -
>  drivers/i2c/muxes/i2c-arb-gpio-challenge.c  |1 -
>  drivers/i2c/muxes/i2c-mux-gpio.c|1 -
>  drivers/i2c/muxes/i2c-mux-pinctrl.c |1 -
>  drivers/media/platform/exynos4-is/fimc-is-i2c.c |4 +-
>  drivers/media/platform/exynos4-is/fimc-is.c |2 +-
>  drivers/media/platform/exynos4-is/media-dev.c   |1 -
>  drivers/of/Kconfig  |6 --
>  drivers/of/Makefile |1 -
>  drivers/of/of_i2c.c |  114 
> ---
>  drivers/staging/imx-drm/imx-tve.c   |2 +-
>  include/linux/i2c.h |   20 
>  include/linux/of_i2c.h  |   46 -
>  sound/soc/fsl/imx-sgtl5000.c|2 +-
>  sound/soc/fsl/imx-wm8962.c  |2 +-
>  47 files changed, 138 insertions(+), 262 deletions(-)
>  delete mode 100644 drivers/of/of_i2c.c
>  delete mode 100644 include/linux/of_i2c.h
> 
> diff --git a/Documentation/acpi/enumeration.txt 
> b/Documentation/acpi/enumeration.txt
> index d9be7a9..958266e 100644
> --- a/Documentation/acpi/enumeration.txt
> +++ b/Documentation/acpi/enumeration.txt
> @@ -238,7 +238,6 @@ An I2C bus (controller) driver does:
>   if (ret)
>   /* handle error */
>  
> - of_i2c_register_devices(adapter);
>   /* Enumerate the slave devices behind this bus via ACPI */
>   acpi_i2c_register_devices(adapter);
>  
> diff --git a/arch/powerpc/platforms/44x/warp.c 
> b/arch/powerpc/platforms/44x/warp.c
> index 4cfa499..534574a 100644
> --- a/arch/powerpc/platforms/44x/warp.c
> +++ b/arch/powerpc/platforms/44x/warp.c
> @@ -16,7 +16,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_slave.c 
> b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
> index dfffaf0..a19f657 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_slave.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
> @@ -16,7 +16,6 @@
>   */
>  
>  #include 

[PATCH 3/6] drm/nouveau: hook up cache sync functions

[Lucas Stach]

Am Mittwoch, den 28.08.2013, 12:43 -0400 schrieb Konrad Rzeszutek Wilk:
> On Wed, Aug 28, 2013 at 02:00:47AM +0200, Lucas Stach wrote:
> > Signed-off-by: Lucas Stach 
> > ---
> >  drivers/gpu/drm/nouveau/nouveau_bo.c  | 4 
> >  drivers/gpu/drm/nouveau/nouveau_gem.c | 5 +
> >  2 files changed, 9 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
> > b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > index af20fba..f4a2eb9 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> > +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > @@ -411,6 +411,10 @@ nouveau_bo_validate(struct nouveau_bo *nvbo, bool 
> > interruptible,
> >  {
> > int ret;
> >  
> > +   if (nvbo->bo.ttm && nvbo->bo.ttm->caching_state == tt_cached)
> 
> You don't want to do it also for tt_wc ?
> 
No the point of using writecombined memory for BOs is to explicitly
avoid the need for this cache sync. An uncached MMIO read from the
device should already flush out all writecombining buffers and this read
is always happening when submitting a pushbuf.

> > +   ttm_dma_tt_cache_sync_for_device((struct ttm_dma_tt 
> > *)nvbo->bo.ttm,
> > +   _bdev(nvbo->bo.ttm->bdev)->dev->pdev->dev);
> > +
> > ret = ttm_bo_validate(>bo, >placement,
> >   interruptible, no_wait_gpu);
> > if (ret)
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c 
> > b/drivers/gpu/drm/nouveau/nouveau_gem.c
> > index 830cb7b..f632b92 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_gem.c
> > +++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
> > @@ -901,6 +901,11 @@ nouveau_gem_ioctl_cpu_prep(struct drm_device *dev, 
> > void *data,
> > ret = ttm_bo_wait(>bo, true, true, no_wait);
> > spin_unlock(>bo.bdev->fence_lock);
> > drm_gem_object_unreference_unlocked(gem);
> > +
> > +   if (!ret && nvbo->bo.ttm && nvbo->bo.ttm->caching_state == tt_cached)
> 
> Ditto?
cpu_prep is used to make the kernel aware of a following userspace read.
Writecombined mappings are essentially uncached from the read
perspective.

>  
> > +   ttm_dma_tt_cache_sync_for_cpu((struct ttm_dma_tt *)nvbo->bo.ttm,
> > + >pdev->dev);
> > +
> > return ret;
> >  }
> >  
> > -- 
> > 1.8.3.1
> > 
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC 4/4] video: adf: add memblock helper

[Greg Hackmann]

Provides a dma-buf exporter for memblocks, mainly useful for ADF devices
to wrap their bootloader logos

Signed-off-by: Greg Hackmann 
---
 drivers/video/adf/Kconfig|   5 ++
 drivers/video/adf/Makefile   |   2 +
 drivers/video/adf/adf_memblock.c | 150 +++
 include/video/adf_memblock.h |  20 ++
 4 files changed, 177 insertions(+)
 create mode 100644 drivers/video/adf/adf_memblock.c
 create mode 100644 include/video/adf_memblock.h

diff --git a/drivers/video/adf/Kconfig b/drivers/video/adf/Kconfig
index 30b0611..ad0c0eb 100644
--- a/drivers/video/adf/Kconfig
+++ b/drivers/video/adf/Kconfig
@@ -8,3 +8,8 @@ menuconfig ADF_DISPLAY_CORE
depends on ADF
depends on DISPLAY_CORE
tristate "Helper for implementing ADF interface ops with Display Core 
devices"
+
+menuconfig ADF_MEMBLOCK
+   depends on ADF
+   depends on HAVE_MEMBLOCK
+   tristate "Helper for using memblocks as buffers in ADF drivers"
diff --git a/drivers/video/adf/Makefile b/drivers/video/adf/Makefile
index 30164ee..97f9c98 100644
--- a/drivers/video/adf/Makefile
+++ b/drivers/video/adf/Makefile
@@ -10,3 +10,5 @@ obj-$(CONFIG_ADF) += adf.o \
 obj-$(CONFIG_COMPAT) += adf_fops32.o

 obj-$(CONFIG_ADF_DISPLAY_CORE) += adf_display.o
+
+obj-$(CONFIG_ADF_MEMBLOCK) += adf_memblock.o
diff --git a/drivers/video/adf/adf_memblock.c b/drivers/video/adf/adf_memblock.c
new file mode 100644
index 000..a1b7ec6
--- /dev/null
+++ b/drivers/video/adf/adf_memblock.c
@@ -0,0 +1,150 @@
+/*
+ * Copyright (C) 2013 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+struct adf_memblock_pdata {
+   phys_addr_t base;
+};
+
+struct sg_table *adf_memblock_map(struct dma_buf_attachment *attach,
+   enum dma_data_direction direction)
+{
+   struct adf_memblock_pdata *pdata = attach->dmabuf->priv;
+   unsigned long pfn = (pdata->base >> PAGE_SHIFT);
+   struct page *page = pfn_to_page(pfn);
+   struct sg_table *table;
+   int ret;
+
+   table = kzalloc(sizeof(*table), GFP_KERNEL);
+   if (!table)
+   return ERR_PTR(-ENOMEM);
+
+   ret = sg_alloc_table(table, 1, GFP_KERNEL);
+   if (ret < 0)
+   goto err;
+
+   sg_set_page(table->sgl, page, attach->dmabuf->size, 0);
+   return table;
+
+err:
+   kfree(table);
+   return ERR_PTR(ret);
+}
+
+void adf_memblock_unmap(struct dma_buf_attachment *attach,
+   struct sg_table *table, enum dma_data_direction direction)
+{
+   sg_free_table(table);
+}
+
+static void __init_memblock adf_memblock_release(struct dma_buf *buf)
+{
+   struct adf_memblock_pdata *pdata = buf->priv;
+   int err = memblock_free(pdata->base, buf->size);
+
+   if (err < 0)
+   pr_warn("%s: freeing memblock failed: %d\n", __func__, err);
+   kfree(pdata);
+}
+
+static void *adf_memblock_do_kmap(struct dma_buf *buf, unsigned long pgoffset,
+   bool atomic)
+{
+   struct adf_memblock_pdata *pdata = buf->priv;
+   unsigned long pfn = (pdata->base >> PAGE_SHIFT) + pgoffset;
+   struct page *page = pfn_to_page(pfn);
+
+   if (atomic)
+   return kmap_atomic(page);
+   else
+   return kmap(page);
+}
+
+static void *adf_memblock_kmap_atomic(struct dma_buf *buf,
+   unsigned long pgoffset)
+{
+   return adf_memblock_do_kmap(buf, pgoffset, true);
+}
+
+static void adf_memblock_kunmap_atomic(struct dma_buf *buf,
+   unsigned long pgoffset, void *vaddr)
+{
+   kunmap_atomic(vaddr);
+}
+
+static void *adf_memblock_kmap(struct dma_buf *buf, unsigned long pgoffset)
+{
+   return adf_memblock_do_kmap(buf, pgoffset, false);
+}
+
+static void adf_memblock_kunmap(struct dma_buf *buf, unsigned long pgoffset,
+   void *vaddr)
+{
+   kunmap(vaddr);
+}
+
+static int adf_memblock_mmap(struct dma_buf *buf, struct vm_area_struct *vma)
+{
+   struct adf_memblock_pdata *pdata = buf->priv;
+   unsigned long pfn = pdata->base >> PAGE_SHIFT;
+
+   return remap_pfn_range(vma, vma->vm_start, pfn,
+   vma->vm_end - vma->vm_start, vma->vm_page_prot);
+}
+
+struct dma_buf_ops adf_memblock_ops = {
+   .map_dma_buf = adf_memblock_map,
+   .unmap_dma_buf = adf_memblock_unmap,
+   .release = adf_memblock_release,
+   .kmap_atomic = adf_memblock_kmap_atomic,
+   .kunmap_atomic = adf_memblock_kunmap_atomic,
+   .kmap = adf_memblock_kmap,
+   

[RFC 3/4] video: adf: add display core helper

[Greg Hackmann]

Optional helper which implements some ADF interface ops for displays
using the Display Core framework

Signed-off-by: Greg Hackmann 
---
 drivers/video/adf/Kconfig   |   5 ++
 drivers/video/adf/Makefile  |   2 +
 drivers/video/adf/adf.c |  28 -
 drivers/video/adf/adf.h |   1 +
 drivers/video/adf/adf_display.c | 123 
 include/video/adf_display.h |  31 ++
 6 files changed, 189 insertions(+), 1 deletion(-)
 create mode 100644 drivers/video/adf/adf_display.c
 create mode 100644 include/video/adf_display.h

diff --git a/drivers/video/adf/Kconfig b/drivers/video/adf/Kconfig
index 0b64408..30b0611 100644
--- a/drivers/video/adf/Kconfig
+++ b/drivers/video/adf/Kconfig
@@ -3,3 +3,8 @@ menuconfig ADF
depends on SW_SYNC
depends on DMA_SHARED_BUFFER
tristate "Atomic Display Framework"
+
+menuconfig ADF_DISPLAY_CORE
+   depends on ADF
+   depends on DISPLAY_CORE
+   tristate "Helper for implementing ADF interface ops with Display Core 
devices"
diff --git a/drivers/video/adf/Makefile b/drivers/video/adf/Makefile
index 2af5f79..30164ee 100644
--- a/drivers/video/adf/Makefile
+++ b/drivers/video/adf/Makefile
@@ -8,3 +8,5 @@ obj-$(CONFIG_ADF) += adf.o \
adf_sysfs.o

 obj-$(CONFIG_COMPAT) += adf_fops32.o
+
+obj-$(CONFIG_ADF_DISPLAY_CORE) += adf_display.o
diff --git a/drivers/video/adf/adf.c b/drivers/video/adf/adf.c
index 5dc04af..b3b57dd 100644
--- a/drivers/video/adf/adf.c
+++ b/drivers/video/adf/adf.c
@@ -1,6 +1,6 @@
 /*
  * Copyright (C) 2013 Google, Inc.
- * adf_modeinfo_set_name modified from drm_mode_set_name in
+ * adf_modeinfo_{set_name,set_vrefresh} modified from
  * drivers/gpu/drm/drm_modes.c
  *
  * This software is licensed under the terms of the GNU General Public
@@ -966,6 +966,32 @@ void adf_modeinfo_set_name(struct drm_mode_modeinfo *mode)
 interlaced ? "i" : "");
 }

+void adf_modeinfo_set_vrefresh(struct drm_mode_modeinfo *mode)
+{
+   int refresh = 0;
+   unsigned int calc_val;
+
+   if (mode->vrefresh > 0)
+   return;
+   else if (mode->htotal > 0 && mode->vtotal > 0) {
+   int vtotal;
+   vtotal = mode->vtotal;
+   /* work out vrefresh the value will be x1000 */
+   calc_val = (mode->clock * 1000);
+   calc_val /= mode->htotal;
+   refresh = (calc_val + vtotal / 2) / vtotal;
+
+   if (mode->flags & DRM_MODE_FLAG_INTERLACE)
+   refresh *= 2;
+   if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
+   refresh /= 2;
+   if (mode->vscan > 1)
+   refresh /= mode->vscan;
+
+   mode->vrefresh = refresh;
+   }
+}
+
 static void __exit adf_exit(void);
 static int __init adf_init(void)
 {
diff --git a/drivers/video/adf/adf.h b/drivers/video/adf/adf.h
index acad631..5f7260d 100644
--- a/drivers/video/adf/adf.h
+++ b/drivers/video/adf/adf.h
@@ -44,5 +44,6 @@ struct adf_event_refcount *adf_obj_find_refcount(struct 
adf_obj *obj,
enum adf_event_type type);

 void adf_modeinfo_set_name(struct drm_mode_modeinfo *mode);
+void adf_modeinfo_set_vrefresh(struct drm_mode_modeinfo *mode);

 #endif /* __ADF_H */
diff --git a/drivers/video/adf/adf_display.c b/drivers/video/adf/adf_display.c
new file mode 100644
index 000..c87f6a5
--- /dev/null
+++ b/drivers/video/adf/adf_display.c
@@ -0,0 +1,123 @@
+/*
+ * Copyright (C) 2013 Google, Inc.
+ * adf_modeinfo_from_videomode modified from drm_display_mode_from_videomode in
+ * drivers/gpu/drm/drm_modes.c
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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.
+ *
+ */
+
+#include 
+#include 
+#include 
+
+#include "adf.h"
+
+/**
+ * adf_display_entity_screen_size - handle the screen_size interface op
+ * by querying a display core entity
+ */
+int adf_display_entity_screen_size(struct display_entity *display,
+   u16 *width_mm, u16 *height_mm)
+{
+   unsigned int cdf_width, cdf_height;
+   int ret;
+
+   ret = display_entity_get_size(display, _width, _height);
+   if (!ret) {
+   *width_mm = cdf_width;
+   *height_mm = cdf_height;
+   }
+   return ret;
+}
+EXPORT_SYMBOL(adf_display_entity_screen_size);
+
+/**
+ * adf_display_entity_notify_connected - notify ADF of a display core entity
+ * being connected to an interface
+ *
+ * @intf: the interface
+ * @display: the display
+ *
+ * adf_display_entity_notify_connected() wraps adf_hotplug_notify_connected()
+ 

[RFC 2/4] video: add atomic display framework

[Greg Hackmann]

Signed-off-by: Greg Hackmann 
---
 drivers/video/Kconfig  |   1 +
 drivers/video/Makefile |   1 +
 drivers/video/adf/Kconfig  |   5 +
 drivers/video/adf/Makefile |  10 +
 drivers/video/adf/adf.c| 987 +
 drivers/video/adf/adf.h|  48 ++
 drivers/video/adf/adf_client.c | 853 +++
 drivers/video/adf/adf_fops.c   | 982 
 drivers/video/adf/adf_fops.h   |  37 ++
 drivers/video/adf/adf_fops32.c | 217 +
 drivers/video/adf/adf_fops32.h |  78 
 drivers/video/adf/adf_sysfs.c  | 291 
 drivers/video/adf/adf_sysfs.h  |  33 ++
 drivers/video/adf/adf_trace.h  |  93 
 include/video/adf.h| 743 +++
 include/video/adf_client.h |  61 +++
 include/video/adf_format.h | 282 
 17 files changed, 4722 insertions(+)
 create mode 100644 drivers/video/adf/Kconfig
 create mode 100644 drivers/video/adf/Makefile
 create mode 100644 drivers/video/adf/adf.c
 create mode 100644 drivers/video/adf/adf.h
 create mode 100644 drivers/video/adf/adf_client.c
 create mode 100644 drivers/video/adf/adf_fops.c
 create mode 100644 drivers/video/adf/adf_fops.h
 create mode 100644 drivers/video/adf/adf_fops32.c
 create mode 100644 drivers/video/adf/adf_fops32.h
 create mode 100644 drivers/video/adf/adf_sysfs.c
 create mode 100644 drivers/video/adf/adf_sysfs.h
 create mode 100644 drivers/video/adf/adf_trace.h
 create mode 100644 include/video/adf.h
 create mode 100644 include/video/adf_client.h
 create mode 100644 include/video/adf_format.h

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 6d9788d..a77df10 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2476,6 +2476,7 @@ source "drivers/video/exynos/Kconfig"
 source "drivers/video/mmp/Kconfig"
 source "drivers/video/backlight/Kconfig"
 source "drivers/video/display/Kconfig"
+source "drivers/video/adf/Kconfig"

 if VT
source "drivers/video/console/Kconfig"
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index d7fd4a2..aa6a247 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -12,6 +12,7 @@ fb-y  := fbmem.o fbmon.o fbcmap.o 
fbsysfs.o \
  modedb.o fbcvt.o
 fb-objs   := $(fb-y)

+obj-$(CONFIG_ADF)+= adf/
 obj-$(CONFIG_VT) += console/
 obj-$(CONFIG_LOGO)   += logo/
 obj-y+= backlight/
diff --git a/drivers/video/adf/Kconfig b/drivers/video/adf/Kconfig
new file mode 100644
index 000..0b64408
--- /dev/null
+++ b/drivers/video/adf/Kconfig
@@ -0,0 +1,5 @@
+menuconfig ADF
+   depends on SYNC
+   depends on SW_SYNC
+   depends on DMA_SHARED_BUFFER
+   tristate "Atomic Display Framework"
diff --git a/drivers/video/adf/Makefile b/drivers/video/adf/Makefile
new file mode 100644
index 000..2af5f79
--- /dev/null
+++ b/drivers/video/adf/Makefile
@@ -0,0 +1,10 @@
+ccflags-y := -Idrivers/staging/android -Idrivers/staging/android/sync
+
+CFLAGS_adf.o := -I$(src)
+
+obj-$(CONFIG_ADF) += adf.o \
+   adf_client.o \
+   adf_fops.o \
+   adf_sysfs.o
+
+obj-$(CONFIG_COMPAT) += adf_fops32.o
diff --git a/drivers/video/adf/adf.c b/drivers/video/adf/adf.c
new file mode 100644
index 000..5dc04af
--- /dev/null
+++ b/drivers/video/adf/adf.c
@@ -0,0 +1,987 @@
+/*
+ * Copyright (C) 2013 Google, Inc.
+ * adf_modeinfo_set_name modified from drm_mode_set_name in
+ * drivers/gpu/drm/drm_modes.c
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "sw_sync.h"
+#include "sync.h"
+
+#include "adf.h"
+#include "adf_fops.h"
+#include "adf_sysfs.h"
+
+#define CREATE_TRACE_POINTS
+#include "adf_trace.h"
+
+#define ADF_SHORT_FENCE_TIMEOUT (1 * MSEC_PER_SEC)
+#define ADF_LONG_FENCE_TIMEOUT (10 * MSEC_PER_SEC)
+
+static void adf_fence_wait(struct adf_device *dev, struct sync_fence *fence)
+{
+   /* sync_fence_wait() dumps debug information on timeout.  Experience
+  has shown that if the pipeline gets stuck, a short timeout followed
+  by a longer one provides useful information for debugging. */
+   int err = sync_fence_wait(fence, ADF_SHORT_FENCE_TIMEOUT);
+   if (err >= 0)
+   return;
+
+   if (err == -ETIME)
+   err = sync_fence_wait(fence, ADF_LONG_FENCE_TIMEOUT);
+
+   if (err < 0)

[RFC 1/4] video: Add generic display entity core

[Greg Hackmann]

From: Laurent Pinchart 

Signed-off-by: Laurent Pinchart 
---
 drivers/video/Kconfig|   1 +
 drivers/video/Makefile   |   1 +
 drivers/video/display/Kconfig|   4 +
 drivers/video/display/Makefile   |   1 +
 drivers/video/display/display-core.c | 362 +++
 include/video/display.h  | 150 +++
 6 files changed, 519 insertions(+)
 create mode 100644 drivers/video/display/Kconfig
 create mode 100644 drivers/video/display/Makefile
 create mode 100644 drivers/video/display/display-core.c
 create mode 100644 include/video/display.h

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 2e937bd..6d9788d 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2475,6 +2475,7 @@ source "drivers/video/omap2/Kconfig"
 source "drivers/video/exynos/Kconfig"
 source "drivers/video/mmp/Kconfig"
 source "drivers/video/backlight/Kconfig"
+source "drivers/video/display/Kconfig"

 if VT
source "drivers/video/console/Kconfig"
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index e8bae8d..d7fd4a2 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -15,6 +15,7 @@ fb-objs   := $(fb-y)
 obj-$(CONFIG_VT) += console/
 obj-$(CONFIG_LOGO)   += logo/
 obj-y+= backlight/
+obj-y+= display/

 obj-$(CONFIG_EXYNOS_VIDEO) += exynos/

diff --git a/drivers/video/display/Kconfig b/drivers/video/display/Kconfig
new file mode 100644
index 000..1d533e7
--- /dev/null
+++ b/drivers/video/display/Kconfig
@@ -0,0 +1,4 @@
+menuconfig DISPLAY_CORE
+   tristate "Display Core"
+   ---help---
+ Support common display framework for graphics devices.
diff --git a/drivers/video/display/Makefile b/drivers/video/display/Makefile
new file mode 100644
index 000..bd93496
--- /dev/null
+++ b/drivers/video/display/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_DISPLAY_CORE) += display-core.o
diff --git a/drivers/video/display/display-core.c 
b/drivers/video/display/display-core.c
new file mode 100644
index 000..d2daa15
--- /dev/null
+++ b/drivers/video/display/display-core.c
@@ -0,0 +1,362 @@
+/*
+ * Display Core
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ *
+ * Contacts: Laurent Pinchart 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+static LIST_HEAD(display_entity_list);
+static LIST_HEAD(display_entity_notifiers);
+static DEFINE_MUTEX(display_entity_mutex);
+
+/* 
-
+ * Control operations
+ */
+
+/**
+ * display_entity_set_state - Set the display entity operation state
+ * @entity: The display entity
+ * @state: Display entity operation state
+ *
+ * See  display_entity_state for information regarding the entity states.
+ *
+ * Return 0 on success or a negative error code otherwise.
+ */
+int display_entity_set_state(struct display_entity *entity,
+enum display_entity_state state)
+{
+   int ret;
+
+   if (entity->state == state)
+   return 0;
+
+   if (!entity->ops.ctrl || !entity->ops.ctrl->set_state)
+   return 0;
+
+   ret = entity->ops.ctrl->set_state(entity, state);
+   if (ret < 0)
+   return ret;
+
+   entity->state = state;
+   return 0;
+}
+EXPORT_SYMBOL_GPL(display_entity_set_state);
+
+/**
+ * display_entity_update - Update the display
+ * @entity: The display entity
+ *
+ * Make the display entity ready to receive pixel data and start frame 
transfer.
+ * This operation can only be called if the display entity is in STANDBY or ON
+ * state.
+ *
+ * The display entity will call the upstream entity in the video chain to start
+ * the video stream.
+ *
+ * Return 0 on success or a negative error code otherwise.
+ */
+int display_entity_update(struct display_entity *entity)
+{
+   if (!entity->ops.ctrl || !entity->ops.ctrl->update)
+   return 0;
+
+   return entity->ops.ctrl->update(entity);
+}
+EXPORT_SYMBOL_GPL(display_entity_update);
+
+/**
+ * display_entity_get_modes - Get video modes supported by the display entity
+ * @entity The display entity
+ * @modes: Pointer to an array of modes
+ *
+ * Fill the modes argument with a pointer to an array of video modes. The array
+ * is owned by the display entity.
+ *
+ * Return the number of supported modes on success (including 0 if no mode is
+ * supported) or a negative error code otherwise.
+ */
+int display_entity_get_modes(struct display_entity *entity,
+const struct videomode **modes)
+{
+   if (!entity->ops.ctrl || 

[RFC 0/4] Atomic Display Framework

[Greg Hackmann]

Hi,

ADF is an experimental display framework that I designed after experimenting 
with a KMS-based hardware composer for Android.  ADF started as an 
proof-of-concept implemented from scratch, so right now it's a separate 
framework rather than a patchstack on top of KMS.  If there's community 
interest, moving forward I'd like to merge its functionality into KMS rather 
than keep it as a separate thing.

I'm going to talk about ADF at the Android and Graphics session at Linux 
Plumbers.  The documentation's not done but I wanted to post these patches to 
people a heads-up about ADF.  If there's interest I can write up some more 
formal documentation ahead of Plumbers.

I designed ADF to deal with some serious issues I had working with KMS:

1.  The API is geared toward updating one object at a time.  Android's graphics 
stack needs the entire screen updated atomically to avoid tearing, and on some 
SoCs to avoid wedging the display hardware.  Rob Clark's atomic modeset 
patchset worked, but copy/update/commit design meant the driver had to keep a 
lot more internal state.

2.  Some SoCs don't map well to KMS's CRTC + planes + encoders + connector 
model.  At the time I was dealing with hardware where the blending engines 
didn't have their own framebuffer (they could only scan out constant colors or 
mix the output of other blocks), and you needed to gang several mixers together 
to drive high-res displays.

3.  KMS doesn't support custom pixel formats, which a lot of newer SoCs use 
internally to cut down on bandwidth between hardware blocks. 

4.  KMS doesn't have a way to exchange sync fences.  As a hack I managed to 
pass sync fences into the kernel as properties of the atomic pageflip, but 
there was no good way to get them back out of the kernel without a side channel.

ADF represents display devices as collections of overlay engines and 
interfaces.  Overlay engines (struct adf_overlay_engine) scan out images and 
interfaces (struct adf_interface) display those images.  Overlay engines and 
interfaces can be connected in any n-to-n configuration that the hardware 
supports.

Clients issue atomic updates to the screen by passing in a list of buffers 
(struct adf_buffer) consisting of dma-buf handles, sync fences, and basic 
metadata like format and size.  If this involves composing multiple buffers, 
clients include a block of custom data describing the actual composition 
(scaling, z-order, blending, etc.) in a driver-specific format.

Drivers provide hooks to validate these custom data blocks and commit the new 
configuration to hardware.  ADF handles importing the dma-bufs and fences, 
waiting on incoming sync fences before committing, advancing the display's sync 
timeline, and releasing dma-bufs once they're removed from the screen.

ADF represents pixel formats using DRM-style fourccs, and automatically 
sanity-checks buffer sizes when using one of the formats listed in 
drm_fourcc.h.  Drivers can support custom fourccs if they provide hooks to 
validate buffers that use them.

ADF also provides driver hooks for modesetting, managing and reporting hardware 
events like vsync, and changing DPMS state.  These are documented in struct 
adf_{obj,overlay_engine,interface,device}_ops, and are similar to the 
equivalent DRM ops.

Greg Hackmann (3):
  video: add atomic display framework
  video: adf: add display core helper
  video: adf: add memblock helper

Laurent Pinchart (1):
  video: Add generic display entity core

 drivers/video/Kconfig|2 +
 drivers/video/Makefile   |2 +
 drivers/video/adf/Kconfig|   15 +
 drivers/video/adf/Makefile   |   14 +
 drivers/video/adf/adf.c  | 1013 ++
 drivers/video/adf/adf.h  |   49 ++
 drivers/video/adf/adf_client.c   |  853 
 drivers/video/adf/adf_display.c  |  123 +
 drivers/video/adf/adf_fops.c |  982 
 drivers/video/adf/adf_fops.h |   37 ++
 drivers/video/adf/adf_fops32.c   |  217 
 drivers/video/adf/adf_fops32.h   |   78 +++
 drivers/video/adf/adf_memblock.c |  150 +
 drivers/video/adf/adf_sysfs.c|  291 ++
 drivers/video/adf/adf_sysfs.h|   33 ++
 drivers/video/adf/adf_trace.h|   93 
 drivers/video/display/Kconfig|4 +
 drivers/video/display/Makefile   |1 +
 drivers/video/display/display-core.c |  362 
 include/video/adf.h  |  743 +
 include/video/adf_client.h   |   61 ++
 include/video/adf_display.h  |   31 ++
 include/video/adf_format.h   |  282 ++
 include/video/adf_memblock.h |   20 +
 include/video/display.h  |  150 +
 25 files changed, 5606 insertions(+)
 create mode 100644 drivers/video/adf/Kconfig
 create mode 100644 drivers/video/adf/Makefile
 create mode 100644 

[PATCH v2 6/6] ARM: tegra: Add HDMI to Tegra114 Dalmore device tree

[Mikko Perttunen]

Add HDMI node to Dalmore device tree to supply Dalmore-specific
data: VDD and PLL regulators for HDMI port, DDC bus and HDMI
cable hotplug GPIO.

Signed-off-by: Mikko Perttunen 
---
 arch/arm/boot/dts/tegra114-dalmore.dts | 17 +
 1 file changed, 17 insertions(+)

diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts 
b/arch/arm/boot/dts/tegra114-dalmore.dts
index 6023028..f979e74 100644
--- a/arch/arm/boot/dts/tegra114-dalmore.dts
+++ b/arch/arm/boot/dts/tegra114-dalmore.dts
@@ -713,6 +713,19 @@
};
};

+   host1x {
+   hdmi {
+   status = "okay";
+
+   vdd-supply = <_hdmi_reg>;
+   pll-supply = <_smps3_reg>;
+
+   nvidia,ddc-i2c-bus = <_ddc>;
+   nvidia,hpd-gpio = < TEGRA_GPIO(N, 7)
+  GPIO_ACTIVE_HIGH>;
+   };
+   };
+
serial at 70006300 {
status = "okay";
};
@@ -740,6 +753,10 @@
};
};

+   hdmi_ddc: i2c at 7000c700 {
+   status = "okay";
+   };
+
i2c at 7000d000 {
status = "okay";
clock-frequency = <40>;
-- 
1.8.1.5

[PATCH v2 5/6] ARM: tegra: Add host1x, DC and HDMI to Tegra114 device tree

[Mikko Perttunen]

Add host1x, DC (display controller) and HDMI devices to Tegra114
device tree.

Signed-off-by: Mikko Perttunen 
---
 arch/arm/boot/dts/tegra114.dtsi | 42 +
 1 file changed, 42 insertions(+)

diff --git a/arch/arm/boot/dts/tegra114.dtsi b/arch/arm/boot/dts/tegra114.dtsi
index 2905145..088b594 100644
--- a/arch/arm/boot/dts/tegra114.dtsi
+++ b/arch/arm/boot/dts/tegra114.dtsi
@@ -27,6 +27,48 @@
(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
};

+   host1x {
+   compatible = "nvidia,tegra114-host1x", "simple-bus";
+   reg = <0x5000 0x00028000>;
+   interrupts = ;
+   clocks = <_car TEGRA114_CLK_HOST1X>;
+
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   ranges = <0x5400 0x5400 0x0400>;
+
+   dc at 5420 {
+   compatible = "nvidia,tegra114-dc", "nvidia,tegra30-dc";
+   reg = <0x5420 0x0004>;
+   interrupts = ;
+   clocks = <_car TEGRA114_CLK_DISP1>,
+   <_car TEGRA114_CLK_PLL_P>;
+   clock-names = "disp1", "parent";
+   };
+
+   dc at 5424 {
+   compatible = "nvidia,tegra114-dc", "nvidia,tegra30-dc";
+   reg = <0x5424 0x0004>;
+   interrupts = ;
+   clocks = <_car TEGRA114_CLK_DISP2>,
+   <_car TEGRA114_CLK_PLL_P>;
+   clock-names = "disp2", "parent";
+   };
+
+   hdmi {
+   compatible = "nvidia,tegra114-hdmi";
+   reg = <0x5428 0x0004>;
+   interrupts = ;
+   clocks = <_car TEGRA114_CLK_HDMI>,
+   <_car TEGRA114_CLK_PLL_D2_OUT0>;
+   clock-names = "hdmi", "parent";
+
+   status = "disabled";
+   };
+   };
+
timer at 60005000 {
compatible = "nvidia,tegra114-timer", "nvidia,tegra20-timer";
reg = <0x60005000 0x400>;
-- 
1.8.1.5

[PATCH v2 4/6] clk: tegra114: Initialize clocks needed for HDMI

[Mikko Perttunen]

Add host1x, disp1 and disp2 clocks to the clock initialization table.
These clocks are required for HDMI support.

Signed-off-by: Mikko Perttunen 
---
 drivers/clk/tegra/clk-tegra114.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/clk/tegra/clk-tegra114.c b/drivers/clk/tegra/clk-tegra114.c
index cd94b0c..a491dea 100644
--- a/drivers/clk/tegra/clk-tegra114.c
+++ b/drivers/clk/tegra/clk-tegra114.c
@@ -2211,6 +2211,9 @@ static struct tegra_clk_init_table init_table[] 
__initdata = {
{i2s4, pll_a_out0, 11289600, 0},
{dfll_soc, pll_p, 5100, 1},
{dfll_ref, pll_p, 5100, 1},
+   {host1x, pll_c, 15000, 0},
+   {disp1, pll_p, 6, 0},
+   {disp2, pll_p, 6, 0},
{clk_max, clk_max, 0, 0}, /* This MUST be the last entry. */
 };

-- 
1.8.1.5

[PATCH v2 3/6] host1x: hdmi: Enable Vdd earlier for hotplug/DDC

[Mikko Perttunen]

The Vdd regulator used to be enabled only at tegra_output_hdmi_enable,
which is called after a sink is detected. However, the HDMI hotplug pin
works by returning the voltage supplied by the Vdd pin, so this meant
that the hotplug pin was never asserted and the sink was not detected
unless the Vdd regulator was set to be always on.

This patch moves the enable to the tegra_hdmi_drm_init function to make
sure the regulator will get enabled.

Signed-off-by: Mikko Perttunen 
---
 drivers/gpu/host1x/drm/hdmi.c | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/host1x/drm/hdmi.c b/drivers/gpu/host1x/drm/hdmi.c
index 140339b..96a6ae1 100644
--- a/drivers/gpu/host1x/drm/hdmi.c
+++ b/drivers/gpu/host1x/drm/hdmi.c
@@ -716,12 +716,6 @@ static int tegra_output_hdmi_enable(struct tegra_output 
*output)
h_back_porch = mode->htotal - mode->hsync_end;
h_front_porch = mode->hsync_start - mode->hdisplay;

-   err = regulator_enable(hdmi->vdd);
-   if (err < 0) {
-   dev_err(hdmi->dev, "failed to enable VDD regulator: %d\n", err);
-   return err;
-   }
-
err = regulator_enable(hdmi->pll);
if (err < 0) {
dev_err(hdmi->dev, "failed to enable PLL regulator: %d\n", err);
@@ -943,7 +937,6 @@ static int tegra_output_hdmi_disable(struct tegra_output 
*output)
tegra_periph_reset_assert(hdmi->clk);
clk_disable(hdmi->clk);
regulator_disable(hdmi->pll);
-   regulator_disable(hdmi->vdd);

return 0;
 }
@@ -1240,6 +1233,12 @@ static int tegra_hdmi_drm_init(struct host1x_client 
*client,
struct tegra_hdmi *hdmi = host1x_client_to_hdmi(client);
int err;

+   err = regulator_enable(hdmi->vdd);
+   if (err < 0) {
+   dev_err(client->dev, "vdd regulator enable failed: %d\n", err);
+   return err;
+   }
+
hdmi->output.type = TEGRA_OUTPUT_HDMI;
hdmi->output.dev = client->dev;
hdmi->output.ops = _ops;
@@ -1283,6 +1282,8 @@ static int tegra_hdmi_drm_exit(struct host1x_client 
*client)
return err;
}

+   regulator_disable(hdmi->vdd);
+
return 0;
 }

-- 
1.8.1.5

[PATCH v2 2/6] host1x: hdmi: Detect whether display is connected with HDMI or DVI

[Mikko Perttunen]

Use EDID data to determine whether the display supports HDMI or just DVI.
This used to be hardcoded to be HDMI, which broke support for DVI displays
that couldn't understand the interspersed audio/other data.

If the EDID data isn't available, default to DVI, which should be a safer
choice.

Signed-off-by: Mikko Perttunen 
---
 drivers/gpu/host1x/drm/hdmi.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/host1x/drm/hdmi.c b/drivers/gpu/host1x/drm/hdmi.c
index d81fac8..140339b 100644
--- a/drivers/gpu/host1x/drm/hdmi.c
+++ b/drivers/gpu/host1x/drm/hdmi.c
@@ -702,6 +702,14 @@ static int tegra_output_hdmi_enable(struct tegra_output 
*output)
unsigned long value;
int retries = 1000;
int err;
+   struct drm_property_blob *edid_blob = output->connector.edid_blob_ptr;
+
+   if (edid_blob && edid_blob->data &&
+   drm_detect_hdmi_monitor((struct edid *)edid_blob->data)) {
+   hdmi->dvi = false;
+   } else {
+   hdmi->dvi = true;
+   }

pclk = mode->clock * 1000;
h_sync_width = mode->hsync_end - mode->hsync_start;
-- 
1.8.1.5

[PATCH v2 1/6] host1x: hdmi: Add Tegra114 support

[Mikko Perttunen]

Add Tegra114 TMDS configuration, add new peak_current field and
use new place for drive current override bit on Tegra114 platform.

Signed-off-by: Mikko Perttunen 
---
 drivers/gpu/host1x/dev.c  |   1 +
 drivers/gpu/host1x/drm/drm.c  |   1 +
 drivers/gpu/host1x/drm/hdmi.c | 102 +++-
 drivers/gpu/host1x/drm/hdmi.h | 152 ++
 4 files changed, 253 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
index 28e28a2..421d469 100644
--- a/drivers/gpu/host1x/dev.c
+++ b/drivers/gpu/host1x/dev.c
@@ -80,6 +80,7 @@ static const struct host1x_info host1x01_info = {
 };

 static struct of_device_id host1x_of_match[] = {
+   { .compatible = "nvidia,tegra114-host1x", .data = _info, },
{ .compatible = "nvidia,tegra30-host1x", .data = _info, },
{ .compatible = "nvidia,tegra20-host1x", .data = _info, },
{ },
diff --git a/drivers/gpu/host1x/drm/drm.c b/drivers/gpu/host1x/drm/drm.c
index 8c61cee..37f5166 100644
--- a/drivers/gpu/host1x/drm/drm.c
+++ b/drivers/gpu/host1x/drm/drm.c
@@ -88,6 +88,7 @@ static int host1x_parse_dt(struct host1x_drm *host1x)
"nvidia,tegra30-dc",
"nvidia,tegra30-hdmi",
"nvidia,tegra30-gr2d",
+   "nvidia,tegra114-hdmi",
};
unsigned int i;
int err;
diff --git a/drivers/gpu/host1x/drm/hdmi.c b/drivers/gpu/host1x/drm/hdmi.c
index 01097da..d81fac8 100644
--- a/drivers/gpu/host1x/drm/hdmi.c
+++ b/drivers/gpu/host1x/drm/hdmi.c
@@ -149,6 +149,7 @@ struct tmds_config {
u32 pll1;
u32 pe_current;
u32 drive_current;
+   u32 peak_current;
 };

 static const struct tmds_config tegra2_tmds_config[] = {
@@ -230,6 +231,85 @@ static const struct tmds_config tegra3_tmds_config[] = {
},
 };

+const struct tmds_config tegra114_tmds_config[] = {
+   { /* 480p/576p / 25.2MHz/27MHz modes */
+   .pclk = 2700,
+   .pll0 = SOR_PLL_ICHPMP(1) | SOR_PLL_BG_V17_S(3) |
+   SOR_PLL_VCOCAP(0) | SOR_PLL_RESISTORSEL,
+   .pll1 = SOR_PLL_LOADADJ(3) | SOR_PLL_TMDS_TERMADJ(0),
+   .pe_current = PE_CURRENT0(PE_CURRENT_0_mA_T114) |
+   PE_CURRENT1(PE_CURRENT_0_mA_T114) |
+   PE_CURRENT2(PE_CURRENT_0_mA_T114) |
+   PE_CURRENT3(PE_CURRENT_0_mA_T114),
+   .drive_current =
+   DRIVE_CURRENT_LANE0_T114(DRIVE_CURRENT_10_400_mA_T114) |
+   DRIVE_CURRENT_LANE1_T114(DRIVE_CURRENT_10_400_mA_T114) |
+   DRIVE_CURRENT_LANE2_T114(DRIVE_CURRENT_10_400_mA_T114) |
+   DRIVE_CURRENT_LANE3_T114(DRIVE_CURRENT_10_400_mA_T114),
+   .peak_current = PEAK_CURRENT_LANE0(PEAK_CURRENT_0_000_mA) |
+   PEAK_CURRENT_LANE1(PEAK_CURRENT_0_000_mA) |
+   PEAK_CURRENT_LANE2(PEAK_CURRENT_0_000_mA) |
+   PEAK_CURRENT_LANE3(PEAK_CURRENT_0_000_mA),
+   }, { /* 720p / 74.25MHz modes */
+   .pclk = 7425,
+   .pll0 = SOR_PLL_ICHPMP(1) | SOR_PLL_BG_V17_S(3) |
+   SOR_PLL_VCOCAP(1) | SOR_PLL_RESISTORSEL,
+   .pll1 = SOR_PLL_PE_EN | SOR_PLL_LOADADJ(3) |
+   SOR_PLL_TMDS_TERMADJ(0),
+   .pe_current = PE_CURRENT0(PE_CURRENT_15_mA_T114) |
+   PE_CURRENT1(PE_CURRENT_15_mA_T114) |
+   PE_CURRENT2(PE_CURRENT_15_mA_T114) |
+   PE_CURRENT3(PE_CURRENT_15_mA_T114),
+   .drive_current =
+   DRIVE_CURRENT_LANE0_T114(DRIVE_CURRENT_10_400_mA_T114) |
+   DRIVE_CURRENT_LANE1_T114(DRIVE_CURRENT_10_400_mA_T114) |
+   DRIVE_CURRENT_LANE2_T114(DRIVE_CURRENT_10_400_mA_T114) |
+   DRIVE_CURRENT_LANE3_T114(DRIVE_CURRENT_10_400_mA_T114),
+   .peak_current = PEAK_CURRENT_LANE0(PEAK_CURRENT_0_000_mA) |
+   PEAK_CURRENT_LANE1(PEAK_CURRENT_0_000_mA) |
+   PEAK_CURRENT_LANE2(PEAK_CURRENT_0_000_mA) |
+   PEAK_CURRENT_LANE3(PEAK_CURRENT_0_000_mA),
+   }, { /* 1080p / 148.5MHz modes */
+   .pclk = 14850,
+   .pll0 = SOR_PLL_ICHPMP(1) | SOR_PLL_BG_V17_S(3) |
+   SOR_PLL_VCOCAP(3) | SOR_PLL_RESISTORSEL,
+   .pll1 = SOR_PLL_PE_EN | SOR_PLL_LOADADJ(3) |
+   SOR_PLL_TMDS_TERMADJ(0),
+   .pe_current = PE_CURRENT0(PE_CURRENT_10_mA_T114) |
+   PE_CURRENT1(PE_CURRENT_10_mA_T114) |
+   PE_CURRENT2(PE_CURRENT_10_mA_T114) |
+   PE_CURRENT3(PE_CURRENT_10_mA_T114),
+   .drive_current =
+   DRIVE_CURRENT_LANE0_T114(DRIVE_CURRENT_12_400_mA_T114) |
+   

[PATCH v2 0/6] HDMI support for Tegra114 Dalmore

[Mikko Perttunen]

This patchset adds HDMI support for the Tegra114 Dalmore board.
Tested with 1080p DVI and HDMI monitors.

Mikko Perttunen (6):
  host1x: hdmi: Add Tegra114 support
  host1x: hdmi: Detect whether display is connected with HDMI or DVI
  host1x: hdmi: Enable Vdd earlier for hotplug/DDC
  clk: tegra114: Initialize clocks needed for HDMI
  ARM: tegra: Add host1x, DC and HDMI to Tegra114 device tree
  ARM: tegra: Add HDMI to Tegra114 Dalmore device tree

 arch/arm/boot/dts/tegra114-dalmore.dts |  17 
 arch/arm/boot/dts/tegra114.dtsi|  42 +
 drivers/clk/tegra/clk-tegra114.c   |   3 +
 drivers/gpu/host1x/dev.c   |   1 +
 drivers/gpu/host1x/drm/drm.c   |   1 +
 drivers/gpu/host1x/drm/hdmi.c  | 125 ---
 drivers/gpu/host1x/drm/hdmi.h  | 152 +
 7 files changed, 331 insertions(+), 10 deletions(-)

-- 
1.8.1.5

trees for secondary powerdown

[Takashi Iwai]

At Wed, 28 Aug 2013 18:25:47 +0200,
Takashi Iwai wrote:
> 
> Hi Dave,
> 
> At Wed, 28 Aug 2013 16:51:55 +1000,
> Dave Airlie wrote:
> > 
> > Hi Takashi,
> > 
> > I've put two branches in my repo,
> > 
> > http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-optimus-power-down
> > http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-optimus-power-down-snd-merge
> > 
> > git://people.freedesktop.org/~airlied/linux is the tree.
> > 
> > The second tree is just the vga switcheroo and sound patch, I've
> > changed one line from the
> > previous posted patch to reinstate the irq handler check for runtime
> > pm, but only for cards
> > with the runtime pm flag.
> > 
> > Can you see if this merges into your tree okay? if so we can both
> > merge that branch to
> > our trees and I'll build on top of it.
> 
> Yes, the latest patch looks good to me.  I think you can keep these
> branch in your tree (just put to drm-next).  There is only one patch
> affecting the sound directory and the rest are graphics, after all.
> Since the merge conflict is easy, Linus and Stephen will resolve it
> easily, I guess. 

Oh, and in case it's worth, feel free to give my ack to relevant
patches:

   Acked-by: Takashi Iwai 


Takashi

trees for secondary powerdown

[Takashi Iwai]

Hi Dave,

At Wed, 28 Aug 2013 16:51:55 +1000,
Dave Airlie wrote:
> 
> Hi Takashi,
> 
> I've put two branches in my repo,
> 
> http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-optimus-power-down
> http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-optimus-power-down-snd-merge
> 
> git://people.freedesktop.org/~airlied/linux is the tree.
> 
> The second tree is just the vga switcheroo and sound patch, I've
> changed one line from the
> previous posted patch to reinstate the irq handler check for runtime
> pm, but only for cards
> with the runtime pm flag.
> 
> Can you see if this merges into your tree okay? if so we can both
> merge that branch to
> our trees and I'll build on top of it.

Yes, the latest patch looks good to me.  I think you can keep these
branch in your tree (just put to drm-next).  There is only one patch
affecting the sound directory and the rest are graphics, after all.
Since the merge conflict is easy, Linus and Stephen will resolve it
easily, I guess. 


Thanks!

Takashi

[PATCH 0/6] Nouveau on ARM fixes

[Ben Skeggs]

On Wed, Aug 28, 2013 at 5:50 PM, Thierry Reding
 wrote:
> On Wed, Aug 28, 2013 at 02:00:44AM +0200, Lucas Stach wrote:
>> This is the first set of patches to make Nouveau work
>> on Tegra.
>
> Perhaps you should clarify that this patch series allows discrete GPUs
> to be used via Tegra's PCIe interface.
>
> People might misinterpret...
Hah!  Too late, quality journalism already hard at work ;)

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

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

[Inki Dae]

Rahul, ping~~~


2013/8/1 Rahul Sharma 

> Thanks Sylwester,
>
> On Wed, Jul 31, 2013 at 5:41 PM, Sylwester Nawrocki
>  wrote:
> > Hi Rahul,
> >
> > On 07/31/2013 01:23 PM, Rahul Sharma wrote:
> >>>> I think your hdmiphy pmu patch is good enough just if dt binding for
> pmu
> >>>> >> is in hdmiphy binding instead of hdmi binding. So I recommended to
> make
> >>>> >> pmu patch set on the top of independent hdmiphy patch set because
> with
> >>>> >> independent hdmiphy patch set hdmiphy pmu code is moved to hdmiphy
> driver.
> >>>> >>
> >>>> >> Is it possible that hdmi driver references pmu information from
> hdmiphy
> >>>> >> binding? If that, it seems one possible solution to fix current
> exynos
> >>>> >> hdmi broken.
> >>>> >>
> >>>> >> Thanks and Regards,
> >>>> >> - Seung-Woo Kim
> >>>> >>
> >>> >
> >>> > I can surely do that but, I am worried about hdmiphy control bus.
> >>> > change In 5420. It is changed to platform bus from i2c. Isolating
> >>> > hdmiphy from hdmi driver seems the only clean method to handle
> >>> > control bus change, changed phy configurations and power control
> >>> > through PMU bit.
> >>> >
> >>> > To fix broken hdmi for 5420, I can again post the "hdmiphy
> >>> > separation patches" to place hdmiphy driver in DRM. Later we can
> >>> > migrate to Generic Phy Framework.
> >>> >
> >>
> >> Hi Seung Woo, Mr. Dae, Sylwester,
> >>
> >> What you say on this? Shall I separate hdmiphy in following manner:
> >>
> >> 1) Move all phy related code to hdmiphy driver i.e. exynos_hdmiphy.c
> >> 2) hdmiphy driver exposes power_on/off and set_pixel callbacks for
> >> hdmi driver.
> >> 3) let hdmi driver behave as phy controller for hdmiphy.
> >> 4) move PMU bit control to hdmiphy driver, instead of hdmi driver.
> >>
> >> This way we will be very close to generic phy framework implementation
> >> and migration to generic phy framework will be just a cakewalk.
> >
> > This all sound good to me, it seem natural to put the HDMI PHY
> > functionality into a separate module. Hardware-wise the PHY is quite
> > separate and as experience shows different PHYs can be attached to
> > same controller. Well, we have well known that before...
> >
> > I'm not sure what the problem is with adding subsystem specific
> > classes of operations (set of callback) to the generic PHY API, until
> > that gets sorted out your approach looks good to me.
> >
> > As a side note, originally the V4L2 driver exposed the HDMI PHY
> > as struct v4l2_subdev object, have a look at drivers/media/platform/
> > s5p-tv/hdmiphy_drv.c. And in case of exynos5 we would just have
> > created a platform driver for the HDMI PHY which would expose same
> > subdev interface. So something similar as you proposed above.
> >
>
> Yea, it is very similar to s5p-tv/hdmiphy_drv.c. On top of this, I want
> to make hdmiphy platform device as Clock provider for hdmiphy clock,
> as you have done for cam_clkout*. Hdmi driver will call set_rate on this
> clock.
>
> I will post patches for the above separation and move hdmiphy to Generic
> Phy framework after we get clarity on how to add additional callbacks.
>
> Thanks for your reply.
>
> Regards,
> Rahul Sharma
>
> >
> > Regards,
> > Sylwester
> >
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130828/4166f26b/attachment-0001.html>

[PATCH 0/9] drm/nouveau: Cleanup event/handler design

[Ben Skeggs]

On Wed, Aug 28, 2013 at 6:12 AM, Peter Hurley  
wrote:
> This series was originally motivated by a deadlock, introduced in
> commit 1d7c71a3e2f77336df536855b0efd2dc5bdeb41b
> 'drm/nouveau/disp: port vblank handling to event interface',
> due to inverted lock order between nouveau_drm_vblank_enable()
> and nouveau_drm_vblank_handler() (the complete
> lockdep report is included in the patch 4/5 changelog).
Hey Peter,

Thanks for the patch series.  I've only taken a cursory glance through
the patches thus far, as they're definitely too intrusive for -fixes
at this point.  I will take a proper look through the series within
the next week or so, I have some work pending which may possibly make
some of these changes unnecessary, though from what I can tell,
there's other good bits here we'll want.

In a previous mail on the locking issue, you mentioned the drm core
doing the "wrong thing" here too, did you have any further thoughts on
correcting that issue too?

Ben.

>
> Because this series fixes the vblank event deadlock, it is
> a competing solution to Maarten Lankhorst's 'drm/nouveau:
> fix vblank deadlock'.
>
> This series fixes the vblank event deadlock by converting the
> event handler list to RCU. This solution allows the event trigger
> to be lockless, and thus avoiding the lock inversion.
>
> Typical hurdles to RCU conversion include: 1) ensuring the
> object lifetime exceeds the lockless access; 2) preventing
> premature object reuse; and 3) verifying that stale object
> use not present logical errors.
>
> Because object reuse is not safe in RCU-based operations,
> the nouveau_event_get/_put interface is migrated from
> add/remove semantics to enable/disable semantics with a separate
> install/remove step (which also serves to document the
> handler lifetime). This also corrects an unsafe interface design
> where handlers can mistakenly be reused while in use.
>
> The nouveau driver currently supports 4 events -- gpio, uevent, cevent,
> and vblank. Every event is created by and stored within its
> respective subdev/engine object -- gpio in the GPIO subdev, uevent
> and cevent in the FIFO engine, and vblank in the DISP engine.
> Thus event lifetime extends until the subdev is destructed during
> devobj teardown.
>
> Event handler lifetime varies and is detailed in the table below
> (apologies for the wide-format):
>
> Event  Handler function   Container Until
> -     ---   
> --
> gpio   nouveau_connector_hotplug  struct nouveau_connector  
> nouveau_connector_destroy
> uevent nouveau_fence_wait_uevent_handler  local stack object
> nouveau_fence_wait_uevent returns
> cevent none   n/a   n/a
> vblank nouveau_drm_vblank_handler struct nouveau_drm
> nouveau_drm_remove
> vblank nv50_software_vblsem_release   struct nouveau_software_chan  
> _nouveau_engctx_dtor
>   
> (call stack originates with
>
> nouveau_abi16_chan_free ioctl)
> vblank nvc0_software_vblsem_release   struct nouveau_software_chan  same 
> as above
>
>
> RCU lifetime considerations for handlers:
>
> Event  HandlerLifetime
> -     -
> gpio   nouveau_connector_hotplug  kfree_rcu(nv_connector)
> uevent nouveau_fence_wait_uevent_handler  explicit use of 
> nouveau_event_hander_create/_destroy
> cevent none   n/a
> vblank nouveau_drm_vblank_handler synchronize_rcu() in 
> nouveau_drm_unload
> vblank nv50_software_vblsem_release   synchronize_rcu() in container dtor
> vblank nvc0_software_vblsem_release   synchronize_rcu() in container dtor
>
> synchronize_rcu() is used for nouveau_object-based containers for which
> kfree_rcu() is not suitable/possible.
>
> Stale event handler execution is not a concern for the existing handlers
> because either: 1) the handler is responsible for disabling itself (via
> returning NVKM_EVENT_DROP), or 2) the existing handler can already be stale,
> as is the case with nouveau_connector_hotplug, which only schedules a work
> item, and nouveau_drm_vblank_handler, which the drm core expects may be stale.
>
>
> Peter Hurley (9):
>   drm/nouveau: Add priv field for event handlers
>   drm/nouveau: Move event index check from critical section
>   drm/nouveau: Allocate local event handlers
>   drm/nouveau: Allow asymmetric nouveau_event_get/_put
>   drm/nouveau: Add install/remove semantics for event handlers
>   drm/nouveau: Convert event handler list to RCU
>   drm/nouveau: Fold nouveau_event_put_locked into caller
>   drm/nouveau: Simplify event interface
>   drm/nouveau: Simplify event handler interface
>
>  

[PATCH 4/6] drm/nouveau: introduce NOUVEAU_GEM_TILE_WCUS

[Ben Skeggs]

On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach  wrote:
> This flag allows userspace to give the kernel a hint that it should use
> a non-snooped resource. To guarantee coherency at all times mappings
> into userspace are done write combined, so userspace should avoid
> reading back from those resources.
Do any other combinations of cached/uncached and snooped/non-snooped
make any sense?  If so, perhaps we want to split the flags.

>
> Signed-off-by: Lucas Stach 
> ---
> On x86 an optimized userspace can save up on snoop traffic in the
> system, on ARM the benefits are potentially much larger, as we can save
> the manual cache flush/invalidate.
> ---
>  drivers/gpu/drm/nouveau/nouveau_bo.c | 11 ++-
>  drivers/gpu/drm/nouveau/nouveau_bo.h |  1 +
>  include/uapi/drm/nouveau_drm.h   |  1 +
>  3 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index f4a2eb9..c5fcbcc 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -231,6 +231,12 @@ nouveau_bo_new(struct drm_device *dev, int size, int 
> align,
>
> nouveau_bo_fixup_align(nvbo, flags, , );
> nvbo->bo.mem.num_pages = size >> PAGE_SHIFT;
> +
> +   if (tile_flags & NOUVEAU_GEM_TILE_WCUS)
> +   nvbo->valid_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
> +   else
> +   nvbo->valid_caching = TTM_PL_MASK_CACHING;
> +
> nouveau_bo_placement_set(nvbo, flags, 0);
>
> acc_size = ttm_bo_dma_acc_size(>ttm.bdev, size,
> @@ -292,7 +298,7 @@ void
>  nouveau_bo_placement_set(struct nouveau_bo *nvbo, uint32_t type, uint32_t 
> busy)
>  {
> struct ttm_placement *pl = >placement;
> -   uint32_t flags = TTM_PL_MASK_CACHING |
> +   uint32_t flags = nvbo->valid_caching |
> (nvbo->pin_refcnt ? TTM_PL_FLAG_NO_EVICT : 0);
>
> pl->placement = nvbo->placements;
> @@ -1554,6 +1560,9 @@ nouveau_bo_vma_add(struct nouveau_bo *nvbo, struct 
> nouveau_vm *vm,
> if (nvbo->bo.mem.mem_type == TTM_PL_VRAM)
> nouveau_vm_map(vma, nvbo->bo.mem.mm_node);
> else if (nvbo->bo.mem.mem_type == TTM_PL_TT) {
> +   if (!(nvbo->valid_caching & TTM_PL_FLAG_CACHED))
> +   vma->access |= NV_MEM_ACCESS_NOSNOOP;
> +
> if (node->sg)
> nouveau_vm_map_sg_table(vma, 0, size, node);
> else
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.h 
> b/drivers/gpu/drm/nouveau/nouveau_bo.h
> index 653dbbb..2ecf8b7 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.h
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.h
> @@ -9,6 +9,7 @@ struct nouveau_bo {
> struct ttm_buffer_object bo;
> struct ttm_placement placement;
> u32 valid_domains;
> +   u32 valid_caching;
> u32 placements[3];
> u32 busy_placements[3];
> struct ttm_bo_kmap_obj kmap;
> diff --git a/include/uapi/drm/nouveau_drm.h b/include/uapi/drm/nouveau_drm.h
> index 2a5769f..4948eee2 100644
> --- a/include/uapi/drm/nouveau_drm.h
> +++ b/include/uapi/drm/nouveau_drm.h
> @@ -36,6 +36,7 @@
>  #define NOUVEAU_GEM_TILE_32BPP   0x0002
>  #define NOUVEAU_GEM_TILE_ZETA0x0004
>  #define NOUVEAU_GEM_TILE_NONCONTIG   0x0008
> +#define NOUVEAU_GEM_TILE_WCUS0x0010 /* write-combined, unsnooped 
> */
>
>  struct drm_nouveau_gem_info {
> uint32_t handle;
> --
> 1.8.3.1
>

[PATCH 6/6] drm/nouveau: use MSI interrupts

[Ben Skeggs]

On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach  wrote:
> MSIs were only problematic on some old, broken chipsets. But now that we
> already see systems where PCI legacy interrupts are somewhat flaky, it's
> really time to move to MSIs.
>
> Signed-off-by: Lucas Stach 
> ---
>  drivers/gpu/drm/nouveau/core/include/subdev/mc.h |  1 +
>  drivers/gpu/drm/nouveau/core/subdev/mc/base.c| 17 +
>  2 files changed, 18 insertions(+)
>
> diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h 
> b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
> index 9d2cd20..ce6569f 100644
> --- a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
> +++ b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
> @@ -12,6 +12,7 @@ struct nouveau_mc_intr {
>  struct nouveau_mc {
> struct nouveau_subdev base;
> const struct nouveau_mc_intr *intr_map;
> +   bool use_msi;
>  };
>
>  static inline struct nouveau_mc *
> diff --git a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c 
> b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
> index ec9cd6f..02b337e 100644
> --- a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
> +++ b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
> @@ -23,6 +23,7 @@
>   */
>
>  #include 
> +#include 
>
>  static irqreturn_t
>  nouveau_mc_intr(int irq, void *arg)
> @@ -43,6 +44,9 @@ nouveau_mc_intr(int irq, void *arg)
> map++;
> }
>
> +   if (pmc->use_msi)
> +   nv_wr08(pmc->base.base.parent, 0x00088068, 0xff);
Register not present everywhere.

At the very least, the enabling of MSI should be disallowed on the
earlier chipsets where it's not supported.  Though, it's perhaps
possible that the pci_enable_msi() call will fail in all of these
cases anyway.. I'm not certain.

> +
> if (intr) {
> nv_error(pmc, "unknown intr 0x%08x\n", stat);
> }
> @@ -75,6 +79,8 @@ _nouveau_mc_dtor(struct nouveau_object *object)
> struct nouveau_device *device = nv_device(object);
> struct nouveau_mc *pmc = (void *)object;
> free_irq(device->pdev->irq, pmc);
> +   if (pmc->use_msi)
> +   pci_disable_msi(device->pdev);
> nouveau_subdev_destroy(>base);
>  }
>
> @@ -96,6 +102,17 @@ nouveau_mc_create_(struct nouveau_object *parent, struct 
> nouveau_object *engine,
>
> pmc->intr_map = intr_map;
>
> +   pmc->use_msi = nouveau_boolopt(device->cfgopt, "NvMSI", true);
> +   if (pmc->use_msi) {
> +   ret = pci_enable_msi(device->pdev);
> +   if (ret) {
> +   pmc->use_msi = false;
> +   } else {
> +   nv_wr08(device, 0x00088068, 0xff);
> +   nv_info(pmc, "MSI interrupts enabled\n");
> +   }
> +   }
> +
> ret = request_irq(device->pdev->irq, nouveau_mc_intr,
>   IRQF_SHARED, "nouveau", pmc);
> if (ret < 0)
> --
> 1.8.3.1
>

trees for secondary powerdown

[Dave Airlie]

Hi Takashi,

I've put two branches in my repo,

http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-optimus-power-down
http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-optimus-power-down-snd-merge

git://people.freedesktop.org/~airlied/linux is the tree.

The second tree is just the vga switcheroo and sound patch, I've
changed one line from the
previous posted patch to reinstate the irq handler check for runtime
pm, but only for cards
with the runtime pm flag.

Can you see if this merges into your tree okay? if so we can both
merge that branch to
our trees and I'll build on top of it.

Dave.

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

[Dave Jones]

On Thu, Aug 29, 2013 at 06:35:22AM +1000, Dave Airlie wrote:
 > On Thu, Aug 29, 2013 at 6:30 AM, Dave Jones  wrote:
 > > On Mon, Aug 05, 2013 at 09:40:33AM +0200, Daniel Vetter wrote:
 > >  > On Mon, Jul 29, 2013 at 08:53:35PM -0400, Dave Jones wrote:
 > >  > > On Mon, Jun 17, 2013 at 09:49:27PM -0400, David Airlie wrote:
 > >  > >  >
 > >  > >  > > Reading /proc/dri/0/vma causes bad things to happen on a box 
 > > with nouveau
 > >  > >  > > loaded.
 > >  > >  > > (Note, no X running on that box)
 > >  > >  > >
 > >  > >  > > Trace below shows trinity, but I can reproduce it with just cat
 > >  > >  > > /proc/dri/0/vma
 > >  > >  >
 > >  > >  > How about this, lets just rip it all out.
 > >  > >
 > >  > > No-one objected, and this is still around in 3.11-rc3 in the same
 > >  > > easily oopsable state.. I vote we kill it with fire.
 > >  >
 > >  > Can we make it burn brighter while at it?
 > >  >
 > >  > 
 > > http://cgit.freedesktop.org/~danvet/drm/commit/?h=for-dvdhrm=151591c2828e18fde1eb8447874704f3422168b0
 > >
 > > This went kinda quiet, what's the plan here ?
 > 
 > We nuked it from orbit in drm-next.

Awesome. Looks like that missed a Cc: -stable tag btw.

Dave

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

[Dave Jones]

On Mon, Aug 05, 2013 at 09:40:33AM +0200, Daniel Vetter wrote:
 > On Mon, Jul 29, 2013 at 08:53:35PM -0400, Dave Jones wrote:
 > > On Mon, Jun 17, 2013 at 09:49:27PM -0400, David Airlie wrote:
 > >  > 
 > >  > > Reading /proc/dri/0/vma causes bad things to happen on a box with 
 > > nouveau
 > >  > > loaded.
 > >  > > (Note, no X running on that box)
 > >  > > 
 > >  > > Trace below shows trinity, but I can reproduce it with just cat
 > >  > > /proc/dri/0/vma
 > >  > 
 > >  > How about this, lets just rip it all out.
 > > 
 > > No-one objected, and this is still around in 3.11-rc3 in the same
 > > easily oopsable state.. I vote we kill it with fire.
 > 
 > Can we make it burn brighter while at it?
 > 
 > http://cgit.freedesktop.org/~danvet/drm/commit/?h=for-dvdhrm=151591c2828e18fde1eb8447874704f3422168b0

This went kinda quiet, what's the plan here ?

Dave

[PATCH 5/5] ARM: tegra: Add hdmi to Tegra114 Dalmore device tree

[Mikko Perttunen]

On 08/28/2013 03:30 PM, Thierry Reding wrote:
> * PGP Signed by an unknown key
>
> On Wed, Aug 28, 2013 at 01:40:59PM +0300, Mikko Perttunen wrote:
>> Add hdmi node to Dalmore device tree to supply Dalmore-specific
>
> s/hdmi/HDMI/

Will fix.

>
>> diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts 
>> b/arch/arm/boot/dts/tegra114-dalmore.dts
> [...]
>> +host1x {
>> +hdmi {
>> +status = "okay";
>> +
>> +vdd-supply = <_hdmi_reg>;
>> +pll-supply = <_smps3_reg>;
>> +nvidia,ddc-i2c-bus = <_ddc>;
>
> I prefer to use a blank line to separate "standard" from
> "vendor-specific" properties.

Will fix.

>
>> +nvidia,hpd-gpio = < TEGRA_GPIO(N, 7) 
>> GPIO_ACTIVE_HIGH>;
>
> Other .dts files split this so it doesn't exceed 80 characters. I'm not
> sure how useful that is as a general rule for DT source files, though.

Will fix. I guess check_patch.pl doesn't check for line length in *.dts.

>
>>  i2c at 7000d000 {
>>  status = "okay";
>>  clock-frequency = <40>;
>> @@ -1169,6 +1184,8 @@
>>  regulator-min-microvolt = <500>;
>>  regulator-max-microvolt = <500>;
>>  enable-active-high;
>> +regulator-always-on;
>> +regulator-boot-on;
>
> This warrants at least a mention in the commit message.

Hmm, yeah. Looks like the HDMI driver only enables the Vdd in 
tegra_output_hdmi_enable, which is too late at least for DDC. I guess a 
better patch would be to enable it earlier. In _probe?

>
> Thierry
>
> * Unknown Key
> * 0x7F3EB3A1
>

[PATCH 4/5] ARM: tegra: Add host1x, dc and hdmi to Tegra114 device tree

[Mikko Perttunen]

On 08/28/2013 03:25 PM, Thierry Reding wrote:
> * PGP Signed by an unknown key
>
> On Wed, Aug 28, 2013 at 01:40:58PM +0300, Mikko Perttunen wrote:
>> Add host1x, dc (display controller) and hdmi devices to Tegra114
>> device tree.
>
> "DC" and "HDMI".

Will fix.

>
>>
>> Signed-off-by: Mikko Perttunen 
>> ---
>>   arch/arm/boot/dts/tegra114.dtsi | 43 
>> +
>>   1 file changed, 43 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/tegra114.dtsi 
>> b/arch/arm/boot/dts/tegra114.dtsi
>> index 2905145..ce5a95c 100644
>> --- a/arch/arm/boot/dts/tegra114.dtsi
>> +++ b/arch/arm/boot/dts/tegra114.dtsi
>> @@ -27,6 +27,49 @@
>>  (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
>>  };
>>
>> +host1x {
>> +compatible = "nvidia,tegra114-host1x", "nvidia,tegra30-host1x",
>
> I don't think that's correct. The Tegra114 host1x is not backwards
> compatible with the Tegra30 host1x.
>
> That said, I have a local patch that is a bit more complete in that it
> adds other host1x devices as listed in the TRM as well. But I'll leave
> it up to Stephen how he prefers to handle that. It should be fine to
> defer adding nodes for additional hardware blocks when the supporting
> drivers are merged. We've done it for other devices as well.

Ok. Will need to add tegra114-host1x to the host1x driver compat 
strings, then, but I guess that's better than having it wrong in the DT.

>
>> +"simple-bus";
>> +reg = <0x5000 0x00028000>;
>> +interrupts = ,
>> +;
>
> I think this should be indented with the previous line. Also other SoC
> .dtsi files use a single entry, as in:
>
>   interrupts =  GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>;
>

Will fix.

>> +hdmi {
>> +compatible = "nvidia,tegra114-hdmi";
>> +reg = <0x5428 0x0004>;
>> +interrupts = ;
>> +clocks = <_car TEGRA114_CLK_HDMI>,
>> +<_car TEGRA114_CLK_PLL_D_OUT0>;
>
> Any reason why we can't use pll_d2_out0 here, like we do on Tegra30?

I have this set to PLL_D because I don't have panel support so disp1 
will be the HDMI DC. However, it doesn't seem to matter which one is 
specified here. I have also tested HDMI with disp2 and that works too.

>
> Thierry
>
> * Unknown Key
> * 0x7F3EB3A1
>

[PATCH 2/5] host1x: hdmi: Detect whether display is connected with HDMI or DVI

[Mikko Perttunen]

On 08/28/2013 03:07 PM, Thierry Reding wrote:
> * PGP Signed by an unknown key
>
> On Wed, Aug 28, 2013 at 01:40:56PM +0300, Mikko Perttunen wrote:
>> Use EDID data to determine whether the display supports HDMI or just DVI.
>> This used to be hardcoded to be HDMI, which broke support for DVI displays
>> that couldn't understand the interspersed audio/other data.
>>
>> If the EDID data isn't available, default to DVI, which should be a safer
>> choice.
>>
>> Signed-off-by: Mikko Perttunen 
>> ---
>>   drivers/gpu/host1x/drm/hdmi.c | 8 
>>   1 file changed, 8 insertions(+)
>>
>> diff --git a/drivers/gpu/host1x/drm/hdmi.c b/drivers/gpu/host1x/drm/hdmi.c
>> index d81fac8..140339b 100644
>> --- a/drivers/gpu/host1x/drm/hdmi.c
>> +++ b/drivers/gpu/host1x/drm/hdmi.c
>> @@ -702,6 +702,14 @@ static int tegra_output_hdmi_enable(struct tegra_output 
>> *output)
>>  unsigned long value;
>>  int retries = 1000;
>>  int err;
>> +struct drm_property_blob *edid_blob = output->connector.edid_blob_ptr;
>> +
>> +if (edid_blob && edid_blob->data &&
>> +drm_detect_hdmi_monitor((struct edid *)edid_blob->data)) {
>> +hdmi->dvi = false;
>> +} else {
>> +hdmi->dvi = true;
>> +}
>>
>>  pclk = mode->clock * 1000;
>>  h_sync_width = mode->hsync_end - mode->hsync_start;
>
> Odd, now that I see that code I remember that there was a similar patch
> a few months back, but it was never applied for some reason:
>
>   http://lists.freedesktop.org/archives/dri-devel/2013-January/033509.html
>
> That was already reviewed by me and Jon Mayo, so I'll go ahead and apply
> that one instead.
>
> Thierry
>
> * Unknown Key
> * 0x7F3EB3A1
>

That patch seems to cause a warning for me:
drivers/gpu/host1x/drm/hdmi.c: In function ?tegra_output_hdmi_enable?:
drivers/gpu/host1x/drm/hdmi.c:706:2: warning: passing argument 1 of 
?drm_detect_hdmi_monitor? discards ?const? qualifier from pointer target 
type [enabled by default]
include/drm/drm_crtc.h:1037:13: note: expected ?struct edid *? but 
argument is of type ?const struct edid *?

Looks much nicer though.

[PATCH 5/5] ARM: tegra: Add hdmi to Tegra114 Dalmore device tree

[Thierry Reding]

On Wed, Aug 28, 2013 at 03:49:45PM +0300, Mikko Perttunen wrote:
> On 08/28/2013 03:30 PM, Thierry Reding wrote:
> >On Wed, Aug 28, 2013 at 01:40:59PM +0300, Mikko Perttunen wrote:
[...]
> >>regulator-min-microvolt = <500>;
> >>regulator-max-microvolt = <500>;
> >>enable-active-high;
> >>+   regulator-always-on;
> >>+   regulator-boot-on;
> >
> >This warrants at least a mention in the commit message.
> 
> Hmm, yeah. Looks like the HDMI driver only enables the Vdd in
> tegra_output_hdmi_enable, which is too late at least for DDC. I
> guess a better patch would be to enable it earlier. In _probe?

I don't think that would be much better. That way the supply will still
always be on, independent of whether we're actually using HDMI or not.
I'm thinking that perhaps we need to allow HDMI to override get_modes()
by something custom. That should also help with the EDID problem in the
earlier patch.

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/20130828/b4ceb96f/attachment.pgp>

[PATCH 4/5] ARM: tegra: Add host1x, dc and hdmi to Tegra114 device tree

[Thierry Reding]

On Wed, Aug 28, 2013 at 03:41:35PM +0300, Mikko Perttunen wrote:
> On 08/28/2013 03:25 PM, Thierry Reding wrote:
[...]
> >>Signed-off-by: Mikko Perttunen 
> >>---
> >>  arch/arm/boot/dts/tegra114.dtsi | 43 
> >> +
> >>  1 file changed, 43 insertions(+)
> >>
> >>diff --git a/arch/arm/boot/dts/tegra114.dtsi 
> >>b/arch/arm/boot/dts/tegra114.dtsi
> >>index 2905145..ce5a95c 100644
> >>--- a/arch/arm/boot/dts/tegra114.dtsi
> >>+++ b/arch/arm/boot/dts/tegra114.dtsi
> >>@@ -27,6 +27,49 @@
> >>(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
> >>};
> >>
> >>+   host1x {
> >>+   compatible = "nvidia,tegra114-host1x", "nvidia,tegra30-host1x",
> >
> >I don't think that's correct. The Tegra114 host1x is not backwards
> >compatible with the Tegra30 host1x.
> >
> >That said, I have a local patch that is a bit more complete in that it
> >adds other host1x devices as listed in the TRM as well. But I'll leave
> >it up to Stephen how he prefers to handle that. It should be fine to
> >defer adding nodes for additional hardware blocks when the supporting
> >drivers are merged. We've done it for other devices as well.
> 
> Ok. Will need to add tegra114-host1x to the host1x driver compat
> strings, then, but I guess that's better than having it wrong in the
> DT.

I think that's not all. I have local patches that also introduce a v2 of
host1x, because the number of syncpoints is different. There may also be
other differences, but Terje might be more qualified to answer that.

> >>+   hdmi {
> >>+   compatible = "nvidia,tegra114-hdmi";
> >>+   reg = <0x5428 0x0004>;
> >>+   interrupts = ;
> >>+   clocks = <_car TEGRA114_CLK_HDMI>,
> >>+   <_car TEGRA114_CLK_PLL_D_OUT0>;
> >
> >Any reason why we can't use pll_d2_out0 here, like we do on Tegra30?
> 
> I have this set to PLL_D because I don't have panel support so disp1
> will be the HDMI DC. However, it doesn't seem to matter which one is
> specified here. I have also tested HDMI with disp2 and that works
> too.

Well eventually we'll add panel support and I think it'd be good to stay
consistent as to what clocks are used for the internal and external
displays.

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/20130828/8d034ac5/attachment.pgp>

[PATCH 2/5] host1x: hdmi: Detect whether display is connected with HDMI or DVI

[Thierry Reding]

On Wed, Aug 28, 2013 at 03:34:53PM +0300, Mikko Perttunen wrote:
> On 08/28/2013 03:07 PM, Thierry Reding wrote:
> >* PGP Signed by an unknown key
> >
> >On Wed, Aug 28, 2013 at 01:40:56PM +0300, Mikko Perttunen wrote:
> >>Use EDID data to determine whether the display supports HDMI or just DVI.
> >>This used to be hardcoded to be HDMI, which broke support for DVI displays
> >>that couldn't understand the interspersed audio/other data.
> >>
> >>If the EDID data isn't available, default to DVI, which should be a safer
> >>choice.
> >>
> >>Signed-off-by: Mikko Perttunen 
> >>---
> >>  drivers/gpu/host1x/drm/hdmi.c | 8 
> >>  1 file changed, 8 insertions(+)
> >>
> >>diff --git a/drivers/gpu/host1x/drm/hdmi.c b/drivers/gpu/host1x/drm/hdmi.c
> >>index d81fac8..140339b 100644
> >>--- a/drivers/gpu/host1x/drm/hdmi.c
> >>+++ b/drivers/gpu/host1x/drm/hdmi.c
> >>@@ -702,6 +702,14 @@ static int tegra_output_hdmi_enable(struct 
> >>tegra_output *output)
> >>unsigned long value;
> >>int retries = 1000;
> >>int err;
> >>+   struct drm_property_blob *edid_blob = output->connector.edid_blob_ptr;
> >>+
> >>+   if (edid_blob && edid_blob->data &&
> >>+   drm_detect_hdmi_monitor((struct edid *)edid_blob->data)) {
> >>+   hdmi->dvi = false;
> >>+   } else {
> >>+   hdmi->dvi = true;
> >>+   }
> >>
> >>pclk = mode->clock * 1000;
> >>h_sync_width = mode->hsync_end - mode->hsync_start;
> >
> >Odd, now that I see that code I remember that there was a similar patch
> >a few months back, but it was never applied for some reason:
> >
> > http://lists.freedesktop.org/archives/dri-devel/2013-January/033509.html
> >
> >That was already reviewed by me and Jon Mayo, so I'll go ahead and apply
> >that one instead.
> >
> >Thierry
> >
> >* Unknown Key
> >* 0x7F3EB3A1
> >
> 
> That patch seems to cause a warning for me:
> drivers/gpu/host1x/drm/hdmi.c: In function ?tegra_output_hdmi_enable?:
> drivers/gpu/host1x/drm/hdmi.c:706:2: warning: passing argument 1 of
> ?drm_detect_hdmi_monitor? discards ?const? qualifier from pointer
> target type [enabled by default]
> include/drm/drm_crtc.h:1037:13: note: expected ?struct edid *? but
> argument is of type ?const struct edid *?

Given the discussion about this back in January, I think the best way,
at least for now, is to keep a copy of the EDID data so that it can
actually be modified.

But looking at the problem more closely, I don't think the patch from
January is quite correct. The problem is that it uses the EDID stored
within the struct tegra_output. That's problematic because that field
is not updated when EDID is probed via DDC. That would make the patch
that you proposed more correct.

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/20130828/d09d9c2f/attachment-0001.pgp>

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

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

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

--- Comment #8 from Laurent carlier  ---
Same problem with Br?tal Legend (after the intro):

Buddha.bin.x86: AMDGPUInstrInfo.cpp:109: virtual void
llvm::AMDGPUInstrInfo::storeRegToStackSlot(llvm::MachineBasicBlock&,
llvm::MachineBasicBlock::iterator, unsigned int, bool, int, const
llvm::TargetRegisterClass*, const llvm::TargetRegisterInfo*) const: Assertion
`!"Not Implemented"' failed.
Stack dump:
0.  Running pass 'Function Pass Manager' on module 'tgsi'.
1.  Running pass 'Greedy Register Allocator' on function '@main'

-- 
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/20130828/eedc6910/attachment-0001.html>

[PATCH 5/5] ARM: tegra: Add hdmi to Tegra114 Dalmore device tree

[Thierry Reding]

On Wed, Aug 28, 2013 at 01:40:59PM +0300, Mikko Perttunen wrote:
> Add hdmi node to Dalmore device tree to supply Dalmore-specific

s/hdmi/HDMI/

> diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts 
> b/arch/arm/boot/dts/tegra114-dalmore.dts
[...]
> + host1x {
> + hdmi {
> + status = "okay";
> +
> + vdd-supply = <_hdmi_reg>;
> + pll-supply = <_smps3_reg>;
> + nvidia,ddc-i2c-bus = <_ddc>;

I prefer to use a blank line to separate "standard" from
"vendor-specific" properties.

> + nvidia,hpd-gpio = < TEGRA_GPIO(N, 7) 
> GPIO_ACTIVE_HIGH>;

Other .dts files split this so it doesn't exceed 80 characters. I'm not
sure how useful that is as a general rule for DT source files, though.

>   i2c at 7000d000 {
>   status = "okay";
>   clock-frequency = <40>;
> @@ -1169,6 +1184,8 @@
>   regulator-min-microvolt = <500>;
>   regulator-max-microvolt = <500>;
>   enable-active-high;
> + regulator-always-on;
> + regulator-boot-on;

This warrants at least a mention in the commit message.

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/20130828/d7c60c76/attachment.pgp>

[PATCH 4/5] ARM: tegra: Add host1x, dc and hdmi to Tegra114 device tree

[Thierry Reding]

On Wed, Aug 28, 2013 at 01:40:58PM +0300, Mikko Perttunen wrote:
> Add host1x, dc (display controller) and hdmi devices to Tegra114
> device tree.

"DC" and "HDMI".

> 
> Signed-off-by: Mikko Perttunen 
> ---
>  arch/arm/boot/dts/tegra114.dtsi | 43 
> +
>  1 file changed, 43 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/tegra114.dtsi b/arch/arm/boot/dts/tegra114.dtsi
> index 2905145..ce5a95c 100644
> --- a/arch/arm/boot/dts/tegra114.dtsi
> +++ b/arch/arm/boot/dts/tegra114.dtsi
> @@ -27,6 +27,49 @@
>   (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
>   };
>  
> + host1x {
> + compatible = "nvidia,tegra114-host1x", "nvidia,tegra30-host1x",

I don't think that's correct. The Tegra114 host1x is not backwards
compatible with the Tegra30 host1x.

That said, I have a local patch that is a bit more complete in that it
adds other host1x devices as listed in the TRM as well. But I'll leave
it up to Stephen how he prefers to handle that. It should be fine to
defer adding nodes for additional hardware blocks when the supporting
drivers are merged. We've done it for other devices as well.

> + "simple-bus";
> + reg = <0x5000 0x00028000>;
> + interrupts = ,
> + ;

I think this should be indented with the previous line. Also other SoC
.dtsi files use a single entry, as in:

interrupts = ;

> + hdmi {
> + compatible = "nvidia,tegra114-hdmi";
> + reg = <0x5428 0x0004>;
> + interrupts = ;
> + clocks = <_car TEGRA114_CLK_HDMI>,
> + <_car TEGRA114_CLK_PLL_D_OUT0>;

Any reason why we can't use pll_d2_out0 here, like we do on Tegra30?

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/20130828/9054df7a/attachment.pgp>

[PATCH 3/6] drm/nouveau: hook up cache sync functions

[Konrad Rzeszutek Wilk]

On Wed, Aug 28, 2013 at 06:58:37PM +0200, Lucas Stach wrote:
> Am Mittwoch, den 28.08.2013, 12:43 -0400 schrieb Konrad Rzeszutek Wilk:
> > On Wed, Aug 28, 2013 at 02:00:47AM +0200, Lucas Stach wrote:
> > > Signed-off-by: Lucas Stach 
> > > ---
> > >  drivers/gpu/drm/nouveau/nouveau_bo.c  | 4 
> > >  drivers/gpu/drm/nouveau/nouveau_gem.c | 5 +
> > >  2 files changed, 9 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
> > > b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > > index af20fba..f4a2eb9 100644
> > > --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> > > +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > > @@ -411,6 +411,10 @@ nouveau_bo_validate(struct nouveau_bo *nvbo, bool 
> > > interruptible,
> > >  {
> > >   int ret;
> > >  
> > > + if (nvbo->bo.ttm && nvbo->bo.ttm->caching_state == tt_cached)
> > 
> > You don't want to do it also for tt_wc ?
> > 
> No the point of using writecombined memory for BOs is to explicitly
> avoid the need for this cache sync. An uncached MMIO read from the
> device should already flush out all writecombining buffers and this read
> is always happening when submitting a pushbuf.


Could you include this explanation in the git commit description please?

> 
> > > + ttm_dma_tt_cache_sync_for_device((struct ttm_dma_tt 
> > > *)nvbo->bo.ttm,
> > > + _bdev(nvbo->bo.ttm->bdev)->dev->pdev->dev);
> > > +
> > >   ret = ttm_bo_validate(>bo, >placement,
> > > interruptible, no_wait_gpu);
> > >   if (ret)
> > > diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c 
> > > b/drivers/gpu/drm/nouveau/nouveau_gem.c
> > > index 830cb7b..f632b92 100644
> > > --- a/drivers/gpu/drm/nouveau/nouveau_gem.c
> > > +++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
> > > @@ -901,6 +901,11 @@ nouveau_gem_ioctl_cpu_prep(struct drm_device *dev, 
> > > void *data,
> > >   ret = ttm_bo_wait(>bo, true, true, no_wait);
> > >   spin_unlock(>bo.bdev->fence_lock);
> > >   drm_gem_object_unreference_unlocked(gem);
> > > +
> > > + if (!ret && nvbo->bo.ttm && nvbo->bo.ttm->caching_state == tt_cached)
> > 
> > Ditto?
> cpu_prep is used to make the kernel aware of a following userspace read.
> Writecombined mappings are essentially uncached from the read
> perspective.
> 
> >  
> > > + ttm_dma_tt_cache_sync_for_cpu((struct ttm_dma_tt *)nvbo->bo.ttm,
> > > +   >pdev->dev);
> > > +
> > >   return ret;
> > >  }
> > >  
> > > -- 
> > > 1.8.3.1
> > > 
> > > ___
> > > dri-devel mailing list
> > > dri-devel at lists.freedesktop.org
> > > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> 

[PATCH 2/5] host1x: hdmi: Detect whether display is connected with HDMI or DVI

[Thierry Reding]

On Wed, Aug 28, 2013 at 01:40:56PM +0300, Mikko Perttunen wrote:
> Use EDID data to determine whether the display supports HDMI or just DVI.
> This used to be hardcoded to be HDMI, which broke support for DVI displays
> that couldn't understand the interspersed audio/other data.
> 
> If the EDID data isn't available, default to DVI, which should be a safer
> choice.
> 
> Signed-off-by: Mikko Perttunen 
> ---
>  drivers/gpu/host1x/drm/hdmi.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/host1x/drm/hdmi.c b/drivers/gpu/host1x/drm/hdmi.c
> index d81fac8..140339b 100644
> --- a/drivers/gpu/host1x/drm/hdmi.c
> +++ b/drivers/gpu/host1x/drm/hdmi.c
> @@ -702,6 +702,14 @@ static int tegra_output_hdmi_enable(struct tegra_output 
> *output)
>   unsigned long value;
>   int retries = 1000;
>   int err;
> + struct drm_property_blob *edid_blob = output->connector.edid_blob_ptr;
> +
> + if (edid_blob && edid_blob->data &&
> + drm_detect_hdmi_monitor((struct edid *)edid_blob->data)) {
> + hdmi->dvi = false;
> + } else {
> + hdmi->dvi = true;
> + }
>  
>   pclk = mode->clock * 1000;
>   h_sync_width = mode->hsync_end - mode->hsync_start;

Odd, now that I see that code I remember that there was a similar patch
a few months back, but it was never applied for some reason:

http://lists.freedesktop.org/archives/dri-devel/2013-January/033509.html

That was already reviewed by me and Jon Mayo, so I'll go ahead and apply
that one instead.

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/20130828/2a51a5d6/attachment.pgp>

[PATCH 5/5] ARM: tegra: Add hdmi to Tegra114 Dalmore device tree

[Mikko Perttunen]

Add hdmi node to Dalmore device tree to supply Dalmore-specific
data: VDD and PLL regulators for HDMI port, DDC bus and HDMI
cable hotplug GPIO.

Signed-off-by: Mikko Perttunen 
---
 arch/arm/boot/dts/tegra114-dalmore.dts | 17 +
 1 file changed, 17 insertions(+)

diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts 
b/arch/arm/boot/dts/tegra114-dalmore.dts
index 6023028..50e6fb4 100644
--- a/arch/arm/boot/dts/tegra114-dalmore.dts
+++ b/arch/arm/boot/dts/tegra114-dalmore.dts
@@ -713,6 +713,17 @@
};
};

+   host1x {
+   hdmi {
+   status = "okay";
+
+   vdd-supply = <_hdmi_reg>;
+   pll-supply = <_smps3_reg>;
+   nvidia,ddc-i2c-bus = <_ddc>;
+   nvidia,hpd-gpio = < TEGRA_GPIO(N, 7) 
GPIO_ACTIVE_HIGH>;
+   };
+   };
+
serial at 70006300 {
status = "okay";
};
@@ -740,6 +751,10 @@
};
};

+   hdmi_ddc: i2c at 7000c700 {
+   status = "okay";
+   };
+
i2c at 7000d000 {
status = "okay";
clock-frequency = <40>;
@@ -1169,6 +1184,8 @@
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
enable-active-high;
+   regulator-always-on;
+   regulator-boot-on;
gpio = < TEGRA_GPIO(K, 1) GPIO_ACTIVE_HIGH>;
vin-supply = <_dcdc1_reg>;
};
-- 
1.8.1.5

[PATCH 4/5] ARM: tegra: Add host1x, dc and hdmi to Tegra114 device tree

[Mikko Perttunen]

Add host1x, dc (display controller) and hdmi devices to Tegra114
device tree.

Signed-off-by: Mikko Perttunen 
---
 arch/arm/boot/dts/tegra114.dtsi | 43 +
 1 file changed, 43 insertions(+)

diff --git a/arch/arm/boot/dts/tegra114.dtsi b/arch/arm/boot/dts/tegra114.dtsi
index 2905145..ce5a95c 100644
--- a/arch/arm/boot/dts/tegra114.dtsi
+++ b/arch/arm/boot/dts/tegra114.dtsi
@@ -27,6 +27,49 @@
(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
};

+   host1x {
+   compatible = "nvidia,tegra114-host1x", "nvidia,tegra30-host1x",
+   "simple-bus";
+   reg = <0x5000 0x00028000>;
+   interrupts = ,
+   ;
+   clocks = <_car TEGRA114_CLK_HOST1X>;
+
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   ranges = <0x5400 0x5400 0x0400>;
+
+   dc at 5420 {
+   compatible = "nvidia,tegra114-dc", "nvidia,tegra30-dc";
+   reg = <0x5420 0x0004>;
+   interrupts = ;
+   clocks = <_car TEGRA114_CLK_DISP1>,
+   <_car TEGRA114_CLK_PLL_P>;
+   clock-names = "disp1", "parent";
+   };
+
+   dc at 5424 {
+   compatible = "nvidia,tegra114-dc", "nvidia,tegra30-dc";
+   reg = <0x5424 0x0004>;
+   interrupts = ;
+   clocks = <_car TEGRA114_CLK_DISP2>,
+   <_car TEGRA114_CLK_PLL_P>;
+   clock-names = "disp2", "parent";
+   };
+
+   hdmi {
+   compatible = "nvidia,tegra114-hdmi";
+   reg = <0x5428 0x0004>;
+   interrupts = ;
+   clocks = <_car TEGRA114_CLK_HDMI>,
+   <_car TEGRA114_CLK_PLL_D_OUT0>;
+   clock-names = "hdmi", "parent";
+
+   status = "disabled";
+   };
+   };
+
timer at 60005000 {
compatible = "nvidia,tegra114-timer", "nvidia,tegra20-timer";
reg = <0x60005000 0x400>;
-- 
1.8.1.5

[PATCH 3/5] clk: tegra114: Initialize clocks needed for HDMI

[Mikko Perttunen]

Add host1x, disp1 and disp2 clocks to the clock initialization table.
These clocks are required for HDMI support.

Signed-off-by: Mikko Perttunen 
---
 drivers/clk/tegra/clk-tegra114.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/clk/tegra/clk-tegra114.c b/drivers/clk/tegra/clk-tegra114.c
index cd94b0c..a491dea 100644
--- a/drivers/clk/tegra/clk-tegra114.c
+++ b/drivers/clk/tegra/clk-tegra114.c
@@ -2211,6 +2211,9 @@ static struct tegra_clk_init_table init_table[] 
__initdata = {
{i2s4, pll_a_out0, 11289600, 0},
{dfll_soc, pll_p, 5100, 1},
{dfll_ref, pll_p, 5100, 1},
+   {host1x, pll_c, 15000, 0},
+   {disp1, pll_p, 6, 0},
+   {disp2, pll_p, 6, 0},
{clk_max, clk_max, 0, 0}, /* This MUST be the last entry. */
 };

-- 
1.8.1.5

[PATCH 2/5] host1x: hdmi: Detect whether display is connected with HDMI or DVI

[Mikko Perttunen]

Use EDID data to determine whether the display supports HDMI or just DVI.
This used to be hardcoded to be HDMI, which broke support for DVI displays
that couldn't understand the interspersed audio/other data.

If the EDID data isn't available, default to DVI, which should be a safer
choice.

Signed-off-by: Mikko Perttunen 
---
 drivers/gpu/host1x/drm/hdmi.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/host1x/drm/hdmi.c b/drivers/gpu/host1x/drm/hdmi.c
index d81fac8..140339b 100644
--- a/drivers/gpu/host1x/drm/hdmi.c
+++ b/drivers/gpu/host1x/drm/hdmi.c
@@ -702,6 +702,14 @@ static int tegra_output_hdmi_enable(struct tegra_output 
*output)
unsigned long value;
int retries = 1000;
int err;
+   struct drm_property_blob *edid_blob = output->connector.edid_blob_ptr;
+
+   if (edid_blob && edid_blob->data &&
+   drm_detect_hdmi_monitor((struct edid *)edid_blob->data)) {
+   hdmi->dvi = false;
+   } else {
+   hdmi->dvi = true;
+   }

pclk = mode->clock * 1000;
h_sync_width = mode->hsync_end - mode->hsync_start;
-- 
1.8.1.5

[PATCH 1/5] host1x: hdmi: Add Tegra114 support

[Mikko Perttunen]

Add Tegra114 TMDS configuration, add new peak_current field and
use new place for drive current override bit on Tegra114 platform.

Signed-off-by: Mikko Perttunen 
---
 drivers/gpu/host1x/drm/drm.c  |   1 +
 drivers/gpu/host1x/drm/hdmi.c | 102 +++-
 drivers/gpu/host1x/drm/hdmi.h | 152 ++
 3 files changed, 252 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/host1x/drm/drm.c b/drivers/gpu/host1x/drm/drm.c
index 8c61cee..37f5166 100644
--- a/drivers/gpu/host1x/drm/drm.c
+++ b/drivers/gpu/host1x/drm/drm.c
@@ -88,6 +88,7 @@ static int host1x_parse_dt(struct host1x_drm *host1x)
"nvidia,tegra30-dc",
"nvidia,tegra30-hdmi",
"nvidia,tegra30-gr2d",
+   "nvidia,tegra114-hdmi",
};
unsigned int i;
int err;
diff --git a/drivers/gpu/host1x/drm/hdmi.c b/drivers/gpu/host1x/drm/hdmi.c
index 01097da..d81fac8 100644
--- a/drivers/gpu/host1x/drm/hdmi.c
+++ b/drivers/gpu/host1x/drm/hdmi.c
@@ -149,6 +149,7 @@ struct tmds_config {
u32 pll1;
u32 pe_current;
u32 drive_current;
+   u32 peak_current;
 };

 static const struct tmds_config tegra2_tmds_config[] = {
@@ -230,6 +231,85 @@ static const struct tmds_config tegra3_tmds_config[] = {
},
 };

+const struct tmds_config tegra114_tmds_config[] = {
+   { /* 480p/576p / 25.2MHz/27MHz modes */
+   .pclk = 2700,
+   .pll0 = SOR_PLL_ICHPMP(1) | SOR_PLL_BG_V17_S(3) |
+   SOR_PLL_VCOCAP(0) | SOR_PLL_RESISTORSEL,
+   .pll1 = SOR_PLL_LOADADJ(3) | SOR_PLL_TMDS_TERMADJ(0),
+   .pe_current = PE_CURRENT0(PE_CURRENT_0_mA_T114) |
+   PE_CURRENT1(PE_CURRENT_0_mA_T114) |
+   PE_CURRENT2(PE_CURRENT_0_mA_T114) |
+   PE_CURRENT3(PE_CURRENT_0_mA_T114),
+   .drive_current =
+   DRIVE_CURRENT_LANE0_T114(DRIVE_CURRENT_10_400_mA_T114) |
+   DRIVE_CURRENT_LANE1_T114(DRIVE_CURRENT_10_400_mA_T114) |
+   DRIVE_CURRENT_LANE2_T114(DRIVE_CURRENT_10_400_mA_T114) |
+   DRIVE_CURRENT_LANE3_T114(DRIVE_CURRENT_10_400_mA_T114),
+   .peak_current = PEAK_CURRENT_LANE0(PEAK_CURRENT_0_000_mA) |
+   PEAK_CURRENT_LANE1(PEAK_CURRENT_0_000_mA) |
+   PEAK_CURRENT_LANE2(PEAK_CURRENT_0_000_mA) |
+   PEAK_CURRENT_LANE3(PEAK_CURRENT_0_000_mA),
+   }, { /* 720p / 74.25MHz modes */
+   .pclk = 7425,
+   .pll0 = SOR_PLL_ICHPMP(1) | SOR_PLL_BG_V17_S(3) |
+   SOR_PLL_VCOCAP(1) | SOR_PLL_RESISTORSEL,
+   .pll1 = SOR_PLL_PE_EN | SOR_PLL_LOADADJ(3) |
+   SOR_PLL_TMDS_TERMADJ(0),
+   .pe_current = PE_CURRENT0(PE_CURRENT_15_mA_T114) |
+   PE_CURRENT1(PE_CURRENT_15_mA_T114) |
+   PE_CURRENT2(PE_CURRENT_15_mA_T114) |
+   PE_CURRENT3(PE_CURRENT_15_mA_T114),
+   .drive_current =
+   DRIVE_CURRENT_LANE0_T114(DRIVE_CURRENT_10_400_mA_T114) |
+   DRIVE_CURRENT_LANE1_T114(DRIVE_CURRENT_10_400_mA_T114) |
+   DRIVE_CURRENT_LANE2_T114(DRIVE_CURRENT_10_400_mA_T114) |
+   DRIVE_CURRENT_LANE3_T114(DRIVE_CURRENT_10_400_mA_T114),
+   .peak_current = PEAK_CURRENT_LANE0(PEAK_CURRENT_0_000_mA) |
+   PEAK_CURRENT_LANE1(PEAK_CURRENT_0_000_mA) |
+   PEAK_CURRENT_LANE2(PEAK_CURRENT_0_000_mA) |
+   PEAK_CURRENT_LANE3(PEAK_CURRENT_0_000_mA),
+   }, { /* 1080p / 148.5MHz modes */
+   .pclk = 14850,
+   .pll0 = SOR_PLL_ICHPMP(1) | SOR_PLL_BG_V17_S(3) |
+   SOR_PLL_VCOCAP(3) | SOR_PLL_RESISTORSEL,
+   .pll1 = SOR_PLL_PE_EN | SOR_PLL_LOADADJ(3) |
+   SOR_PLL_TMDS_TERMADJ(0),
+   .pe_current = PE_CURRENT0(PE_CURRENT_10_mA_T114) |
+   PE_CURRENT1(PE_CURRENT_10_mA_T114) |
+   PE_CURRENT2(PE_CURRENT_10_mA_T114) |
+   PE_CURRENT3(PE_CURRENT_10_mA_T114),
+   .drive_current =
+   DRIVE_CURRENT_LANE0_T114(DRIVE_CURRENT_12_400_mA_T114) |
+   DRIVE_CURRENT_LANE1_T114(DRIVE_CURRENT_12_400_mA_T114) |
+   DRIVE_CURRENT_LANE2_T114(DRIVE_CURRENT_12_400_mA_T114) |
+   DRIVE_CURRENT_LANE3_T114(DRIVE_CURRENT_12_400_mA_T114),
+   .peak_current = PEAK_CURRENT_LANE0(PEAK_CURRENT_0_000_mA) |
+   PEAK_CURRENT_LANE1(PEAK_CURRENT_0_000_mA) |
+   PEAK_CURRENT_LANE2(PEAK_CURRENT_0_000_mA) |
+   PEAK_CURRENT_LANE3(PEAK_CURRENT_0_000_mA),
+   }, { /* 225/297MHz modes */
+   

[PATCH 0/5] HDMI support for Tegra114 Dalmore

[Mikko Perttunen]

This patchset adds HDMI support for the Tegra114 Dalmore board.
Tested with 1080p DVI and HDMI monitors.

Mikko Perttunen (5):
  host1x: hdmi: Add Tegra114 support
  host1x: hdmi: Detect whether display is connected with HDMI or DVI
  clk: tegra114: Initialize clocks needed for HDMI
  ARM: tegra: Add host1x, dc and hdmi to Tegra114 device tree
  ARM: tegra: Add hdmi to Tegra114 Dalmore device tree

 arch/arm/boot/dts/tegra114-dalmore.dts |  17 
 arch/arm/boot/dts/tegra114.dtsi|  43 ++
 drivers/clk/tegra/clk-tegra114.c   |   3 +
 drivers/gpu/host1x/drm/drm.c   |   1 +
 drivers/gpu/host1x/drm/hdmi.c  | 110 +++-
 drivers/gpu/host1x/drm/hdmi.h  | 152 +
 6 files changed, 323 insertions(+), 3 deletions(-)

-- 
1.8.1.5

[Bug 68451] Texture flicker in native Dota2 in mesa 9.2.0rc1

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

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

--- Comment #13 from Peter Kraus  ---
Found it:


7948ed1250cae78ae1b22dbce4ab23aceacc6159 is the first bad commit
commit 7948ed1250cae78ae1b22dbce4ab23aceacc6159
Author: Marek Ol??k 
Date:   Sun Jun 30 19:57:59 2013 +0200

r600g: only flush the caches that need to be flushed during CP DMA
operations

This should increase performance if constant uploads are done with the CP
DMA,
because only the cache that needs to be flushed is flushed.

Reviewed-by: Alex Deucher 

:04 04 69219cf4b797f08ed91c367342386a00f87b1c45
ae2f808ee6d4c10bc631f7327664da6d349b0a83 Msrc

-- 
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/20130828/f3228293/attachment.html>

[Bug 60791] Display corruption with Radeon driver during boot and on desktop

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

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

--- Comment #13 from Alex Deucher  ---
Can you revert parts of the patch to find out which element is causing the
problem.  E.g., try:

   /* reset data block */
//   ctx->data_block = 0;

and see if that helps, then:

   /* reset divmul */
//   ctx->divmul[0] = 0;
   ctx->divmul[1] = 0;

etc.

Additionally, can you dump the display registers in the working and non-working
states using radeonreg (http://cgit.freedesktop.org/~airlied/radeontool/)?

(as root)

boot with broken kernel:
./radeonreg regs dce3 > broken.regs

boot with working kernel:
./radeonreg regs dce3 > working.regs

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

[PATCH 3/6] drm/nouveau: hook up cache sync functions

[Konrad Rzeszutek Wilk]

On Wed, Aug 28, 2013 at 02:00:47AM +0200, Lucas Stach wrote:
> Signed-off-by: Lucas Stach 
> ---
>  drivers/gpu/drm/nouveau/nouveau_bo.c  | 4 
>  drivers/gpu/drm/nouveau/nouveau_gem.c | 5 +
>  2 files changed, 9 insertions(+)
> 
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index af20fba..f4a2eb9 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -411,6 +411,10 @@ nouveau_bo_validate(struct nouveau_bo *nvbo, bool 
> interruptible,
>  {
>   int ret;
>  
> + if (nvbo->bo.ttm && nvbo->bo.ttm->caching_state == tt_cached)

You don't want to do it also for tt_wc ?

> + ttm_dma_tt_cache_sync_for_device((struct ttm_dma_tt 
> *)nvbo->bo.ttm,
> + _bdev(nvbo->bo.ttm->bdev)->dev->pdev->dev);
> +
>   ret = ttm_bo_validate(>bo, >placement,
> interruptible, no_wait_gpu);
>   if (ret)
> diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c 
> b/drivers/gpu/drm/nouveau/nouveau_gem.c
> index 830cb7b..f632b92 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_gem.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
> @@ -901,6 +901,11 @@ nouveau_gem_ioctl_cpu_prep(struct drm_device *dev, void 
> *data,
>   ret = ttm_bo_wait(>bo, true, true, no_wait);
>   spin_unlock(>bo.bdev->fence_lock);
>   drm_gem_object_unreference_unlocked(gem);
> +
> + if (!ret && nvbo->bo.ttm && nvbo->bo.ttm->caching_state == tt_cached)

Ditto? 
> + ttm_dma_tt_cache_sync_for_cpu((struct ttm_dma_tt *)nvbo->bo.ttm,
> +   >pdev->dev);
> +
>   return ret;
>  }
>  
> -- 
> 1.8.3.1
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 6/6] drm/nouveau: use MSI interrupts

[Konrad Rzeszutek Wilk]

On Wed, Aug 28, 2013 at 09:28:57AM +0200, Lucas Stach wrote:
> Am Mittwoch, den 28.08.2013, 17:09 +1000 schrieb Ben Skeggs:
> > On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach  wrote:
> > > MSIs were only problematic on some old, broken chipsets. But now that we
> > > already see systems where PCI legacy interrupts are somewhat flaky, it's
> > > really time to move to MSIs.
> > >
> > > Signed-off-by: Lucas Stach 
> > > ---
> > >  drivers/gpu/drm/nouveau/core/include/subdev/mc.h |  1 +
> > >  drivers/gpu/drm/nouveau/core/subdev/mc/base.c| 17 +
> > >  2 files changed, 18 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h 
> > > b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
> > > index 9d2cd20..ce6569f 100644
> > > --- a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
> > > +++ b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
> > > @@ -12,6 +12,7 @@ struct nouveau_mc_intr {
> > >  struct nouveau_mc {
> > > struct nouveau_subdev base;
> > > const struct nouveau_mc_intr *intr_map;
> > > +   bool use_msi;
> > >  };
> > >
> > >  static inline struct nouveau_mc *
> > > diff --git a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c 
> > > b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
> > > index ec9cd6f..02b337e 100644
> > > --- a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
> > > +++ b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
> > > @@ -23,6 +23,7 @@
> > >   */
> > >
> > >  #include 
> > > +#include 
> > >
> > >  static irqreturn_t
> > >  nouveau_mc_intr(int irq, void *arg)
> > > @@ -43,6 +44,9 @@ nouveau_mc_intr(int irq, void *arg)
> > > map++;
> > > }
> > >
> > > +   if (pmc->use_msi)
> > > +   nv_wr08(pmc->base.base.parent, 0x00088068, 0xff);
> > Register not present everywhere.
> > 
> > At the very least, the enabling of MSI should be disallowed on the
> > earlier chipsets where it's not supported.  Though, it's perhaps
> > possible that the pci_enable_msi() call will fail in all of these
> > cases anyway.. I'm not certain.
> > 
> MSIs are required property for everything doing PCIe. So the only cases
> where this should fail is plain PCI/AGP devices. I don't really have a
> test system for those old cards set up.

That is not true. You can boot a machine with pci=nomsi that has PCIe and
it will work. Legacy interrupts still work on PCIe

> 
> But I remember Ilia having some legacy things plugged in, so maybe he
> could test this patch and see how it goes?
> 
> > > +
> > > if (intr) {
> > > nv_error(pmc, "unknown intr 0x%08x\n", stat);
> > > }
> > > @@ -75,6 +79,8 @@ _nouveau_mc_dtor(struct nouveau_object *object)
> > > struct nouveau_device *device = nv_device(object);
> > > struct nouveau_mc *pmc = (void *)object;
> > > free_irq(device->pdev->irq, pmc);
> > > +   if (pmc->use_msi)
> > > +   pci_disable_msi(device->pdev);
> > > nouveau_subdev_destroy(>base);
> > >  }
> > >
> > > @@ -96,6 +102,17 @@ nouveau_mc_create_(struct nouveau_object *parent, 
> > > struct nouveau_object *engine,
> > >
> > > pmc->intr_map = intr_map;
> > >
> > > +   pmc->use_msi = nouveau_boolopt(device->cfgopt, "NvMSI", true);
> > > +   if (pmc->use_msi) {
> > > +   ret = pci_enable_msi(device->pdev);
> > > +   if (ret) {
> > > +   pmc->use_msi = false;
> > > +   } else {
> > > +   nv_wr08(device, 0x00088068, 0xff);
> > > +   nv_info(pmc, "MSI interrupts enabled\n");
> > > +   }
> > > +   }
> > > +
> > > ret = request_irq(device->pdev->irq, nouveau_mc_intr,
> > >   IRQF_SHARED, "nouveau", pmc);
> > > if (ret < 0)
> > > --
> > > 1.8.3.1
> > >
> 
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/prime: Remove PRIME handles only if supported

[Thierry Reding]

Drivers that don't support PRIME will not have initialized the PRIME
specific private component of struct drm_file. If called for such
drivers, the drm_gem_remove_prime_handles() function will crash. Fix
it by checking for PRIME support prior to removing the PRIME handles.

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

diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 1ce88c3..4a23f34 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -296,7 +296,8 @@ drm_gem_handle_delete(struct drm_file *filp, u32 handle)
idr_remove(>object_idr, handle);
spin_unlock(>table_lock);

-   drm_gem_remove_prime_handles(obj, filp);
+   if (drm_core_check_feature(dev, DRIVER_PRIME))
+   drm_gem_remove_prime_handles(obj, filp);

if (dev->driver->gem_close_object)
dev->driver->gem_close_object(obj, filp);
@@ -699,7 +700,8 @@ drm_gem_object_release_handle(int id, void *ptr, void *data)
struct drm_gem_object *obj = ptr;
struct drm_device *dev = obj->dev;

-   drm_gem_remove_prime_handles(obj, file_priv);
+   if (drm_core_check_feature(dev, DRIVER_PRIME))
+   drm_gem_remove_prime_handles(obj, file_priv);

if (dev->driver->gem_close_object)
dev->driver->gem_close_object(obj, file_priv);
-- 
1.8.4

[PATCH Resend 6/6] drm/exynos: Remove non-DT support in exynos_drm_fimd

[Sachin Kamat]

Since commit 383ffda2fa ("ARM: EXYNOS: no more support non-DT
for EXYNOS SoCs"), Exynos platform is DT only. Hence remove
all the conditional macros and make the driver DT only.

Signed-off-by: Sachin Kamat 
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c |   74 +-
 1 file changed, 21 insertions(+), 53 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 130dea5..868a14d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -126,7 +126,6 @@ struct fimd_context {
struct fimd_driver_data *driver_data;
 };

-#ifdef CONFIG_OF
 static const struct of_device_id fimd_driver_dt_match[] = {
{ .compatible = "samsung,s3c6400-fimd",
  .data = _fimd_driver_data },
@@ -136,21 +135,14 @@ static const struct of_device_id fimd_driver_dt_match[] = 
{
  .data = _fimd_driver_data },
{},
 };
-#endif

 static inline struct fimd_driver_data *drm_fimd_get_driver_data(
struct platform_device *pdev)
 {
-#ifdef CONFIG_OF
const struct of_device_id *of_id =
of_match_device(fimd_driver_dt_match, >dev);

-   if (of_id)
-   return (struct fimd_driver_data *)of_id->data;
-#endif
-
-   return (struct fimd_driver_data *)
-   platform_get_device_id(pdev)->driver_data;
+   return (struct fimd_driver_data *)of_id->data;
 }

 static bool fimd_display_is_connected(struct device *dev)
@@ -894,37 +886,25 @@ static int fimd_activate(struct fimd_context *ctx, bool 
enable)

 static int fimd_get_platform_data(struct fimd_context *ctx, struct device *dev)
 {
-   if (dev->of_node) {
-   struct videomode *vm;
-   int ret;
+   struct videomode *vm;
+   int ret;

-   vm = >panel.vm;
-   ret = of_get_videomode(dev->of_node, vm, OF_USE_NATIVE_MODE);
-   if (ret) {
-   DRM_ERROR("failed: of_get_videomode() : %d\n", ret);
-   return ret;
-   }
-
-   if (vm->flags & DISPLAY_FLAGS_VSYNC_LOW)
-   ctx->vidcon1 |= VIDCON1_INV_VSYNC;
-   if (vm->flags & DISPLAY_FLAGS_HSYNC_LOW)
-   ctx->vidcon1 |= VIDCON1_INV_HSYNC;
-   if (vm->flags & DISPLAY_FLAGS_DE_LOW)
-   ctx->vidcon1 |= VIDCON1_INV_VDEN;
-   if (vm->flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE)
-   ctx->vidcon1 |= VIDCON1_INV_VCLK;
-   } else {
-   struct exynos_drm_fimd_pdata *pdata = dev->platform_data;
-   if (!pdata) {
-   DRM_ERROR("no platform data specified\n");
-   return -EINVAL;
-   }
-   ctx->vidcon0 = pdata->vidcon0;
-   ctx->vidcon1 = pdata->vidcon1;
-   ctx->default_win = pdata->default_win;
-   ctx->panel = pdata->panel;
+   vm = >panel.vm;
+   ret = of_get_videomode(dev->of_node, vm, OF_USE_NATIVE_MODE);
+   if (ret) {
+   DRM_ERROR("failed: of_get_videomode() : %d\n", ret);
+   return ret;
}

+   if (vm->flags & DISPLAY_FLAGS_VSYNC_LOW)
+   ctx->vidcon1 |= VIDCON1_INV_VSYNC;
+   if (vm->flags & DISPLAY_FLAGS_HSYNC_LOW)
+   ctx->vidcon1 |= VIDCON1_INV_HSYNC;
+   if (vm->flags & DISPLAY_FLAGS_DE_LOW)
+   ctx->vidcon1 |= VIDCON1_INV_VDEN;
+   if (vm->flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE)
+   ctx->vidcon1 |= VIDCON1_INV_VCLK;
+
return 0;
 }

@@ -937,6 +917,9 @@ static int fimd_probe(struct platform_device *pdev)
int win;
int ret = -EINVAL;

+   if (!dev->of_node)
+   return -ENODEV;
+
ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
if (!ctx)
return -ENOMEM;
@@ -1076,20 +1059,6 @@ static int fimd_runtime_resume(struct device *dev)
 }
 #endif

-static struct platform_device_id fimd_driver_ids[] = {
-   {
-   .name   = "s3c64xx-fb",
-   .driver_data= (unsigned long)_fimd_driver_data,
-   }, {
-   .name   = "exynos4-fb",
-   .driver_data= (unsigned long)_fimd_driver_data,
-   }, {
-   .name   = "exynos5-fb",
-   .driver_data= (unsigned long)_fimd_driver_data,
-   },
-   {},
-};
-
 static const struct dev_pm_ops fimd_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(fimd_suspend, fimd_resume)
SET_RUNTIME_PM_OPS(fimd_runtime_suspend, fimd_runtime_resume, NULL)
@@ -1098,11 +1067,10 @@ static const struct dev_pm_ops fimd_pm_ops = {
 struct platform_driver fimd_driver = {
.probe  = fimd_probe,
.remove = fimd_remove,
-   .id_table   = fimd_driver_ids,
.driver = {
.name   = "exynos4-fb",
.owner 

[PATCH Resend 5/6] drm/exynos: Remove non-DT support in exynos_hdmi

[Sachin Kamat]

Since commit 383ffda2fa ("ARM: EXYNOS: no more support non-DT
for EXYNOS SoCs"), Exynos platform is DT only. Hence remove
all the conditional macros and make the driver DT only.

Signed-off-by: Sachin Kamat 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c |   70 ++
 1 file changed, 12 insertions(+), 58 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 8ea07a1..a0e10ae 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1858,7 +1858,6 @@ void hdmi_attach_hdmiphy_client(struct i2c_client 
*hdmiphy)
hdmi_hdmiphy = hdmiphy;
 }

-#ifdef CONFIG_OF
 static struct s5p_hdmi_platform_data *drm_hdmi_dt_parse_pdata
(struct device *dev)
 {
@@ -1882,33 +1881,7 @@ static struct s5p_hdmi_platform_data 
*drm_hdmi_dt_parse_pdata
 err_data:
return NULL;
 }
-#else
-static struct s5p_hdmi_platform_data *drm_hdmi_dt_parse_pdata
-   (struct device *dev)
-{
-   return NULL;
-}
-#endif
-
-static struct platform_device_id hdmi_driver_types[] = {
-   {
-   .name   = "s5pv210-hdmi",
-   .driver_data= HDMI_TYPE13,
-   }, {
-   .name   = "exynos4-hdmi",
-   .driver_data= HDMI_TYPE13,
-   }, {
-   .name   = "exynos4-hdmi14",
-   .driver_data= HDMI_TYPE14,
-   }, {
-   .name   = "exynos5-hdmi",
-   .driver_data= HDMI_TYPE14,
-   }, {
-   /* end node */
-   }
-};

-#ifdef CONFIG_OF
 static struct of_device_id hdmi_match_types[] = {
{
.compatible = "samsung,exynos5-hdmi",
@@ -1920,7 +1893,6 @@ static struct of_device_id hdmi_match_types[] = {
/* end node */
}
 };
-#endif

 static int hdmi_probe(struct platform_device *pdev)
 {
@@ -1929,30 +1901,21 @@ static int hdmi_probe(struct platform_device *pdev)
struct hdmi_context *hdata;
struct s5p_hdmi_platform_data *pdata;
struct resource *res;
+   const struct of_device_id *match;
int ret;

-   if (dev->of_node) {
-   pdata = drm_hdmi_dt_parse_pdata(dev);
-   if (IS_ERR(pdata)) {
-   DRM_ERROR("failed to parse dt\n");
-   return PTR_ERR(pdata);
-   }
-   } else {
-   pdata = dev->platform_data;
-   }
+if (!dev->of_node)
+   return -ENODEV;

-   if (!pdata) {
-   DRM_ERROR("no platform data specified\n");
+   pdata = drm_hdmi_dt_parse_pdata(dev);
+   if (!pdata)
return -EINVAL;
-   }

-   drm_hdmi_ctx = devm_kzalloc(dev, sizeof(*drm_hdmi_ctx),
-   GFP_KERNEL);
+   drm_hdmi_ctx = devm_kzalloc(dev, sizeof(*drm_hdmi_ctx), GFP_KERNEL);
if (!drm_hdmi_ctx)
return -ENOMEM;

-   hdata = devm_kzalloc(dev, sizeof(struct hdmi_context),
-   GFP_KERNEL);
+   hdata = devm_kzalloc(dev, sizeof(struct hdmi_context), GFP_KERNEL);
if (!hdata)
return -ENOMEM;

@@ -1963,23 +1926,15 @@ static int hdmi_probe(struct platform_device *pdev)

platform_set_drvdata(pdev, drm_hdmi_ctx);

-   if (dev->of_node) {
-   const struct of_device_id *match;
-   match = of_match_node(of_match_ptr(hdmi_match_types),
-   dev->of_node);
-   if (match == NULL)
-   return -ENODEV;
-   hdata->type = (enum hdmi_type)match->data;
-   } else {
-   hdata->type = (enum hdmi_type)platform_get_device_id
-   (pdev)->driver_data;
-   }
+   match = of_match_node(hdmi_match_types, dev->of_node);
+   if (!match)
+   return -ENODEV;
+   hdata->type = (enum hdmi_type)match->data;

hdata->hpd_gpio = pdata->hpd_gpio;
hdata->dev = dev;

ret = hdmi_resources_init(hdata);
-
if (ret) {
DRM_ERROR("hdmi_resources_init failed\n");
return -EINVAL;
@@ -2134,11 +2089,10 @@ static const struct dev_pm_ops hdmi_pm_ops = {
 struct platform_driver hdmi_driver = {
.probe  = hdmi_probe,
.remove = hdmi_remove,
-   .id_table = hdmi_driver_types,
.driver = {
.name   = "exynos-hdmi",
.owner  = THIS_MODULE,
.pm = _pm_ops,
-   .of_match_table = of_match_ptr(hdmi_match_types),
+   .of_match_table = hdmi_match_types,
},
 };
-- 
1.7.9.5

[PATCH Resend 4/6] drm/exynos: Remove non-DT support in exynos_drm_g2d

[Sachin Kamat]

Since commit 383ffda2fa ("ARM: EXYNOS: no more support non-DT
for EXYNOS SoCs"), Exynos platform is DT only. Hence remove
all the conditional macros and make the driver DT only.

Signed-off-by: Sachin Kamat 
---
 drivers/gpu/drm/exynos/exynos_drm_g2d.c |4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c 
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index 0b8b6e4..3271fd4 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -1534,12 +1534,10 @@ static const struct dev_pm_ops g2d_pm_ops = {
SET_RUNTIME_PM_OPS(g2d_runtime_suspend, g2d_runtime_resume, NULL)
 };

-#ifdef CONFIG_OF
 static const struct of_device_id exynos_g2d_match[] = {
{ .compatible = "samsung,exynos5250-g2d" },
{},
 };
-#endif

 struct platform_driver g2d_driver = {
.probe  = g2d_probe,
@@ -1548,6 +1546,6 @@ struct platform_driver g2d_driver = {
.name   = "s5p-g2d",
.owner  = THIS_MODULE,
.pm = _pm_ops,
-   .of_match_table = of_match_ptr(exynos_g2d_match),
+   .of_match_table = exynos_g2d_match,
},
 };
-- 
1.7.9.5

[PATCH Resend 3/6] drm/exynos: Remove non-DT support in exynos_hdmiphy

[Sachin Kamat]

Since commit 383ffda2fa ("ARM: EXYNOS: no more support non-DT
for EXYNOS SoCs"), Exynos platform is DT only. Hence remove
all the conditional macros and make the driver DT only.

Signed-off-by: Sachin Kamat 
---
 drivers/gpu/drm/exynos/exynos_hdmiphy.c |   11 +--
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmiphy.c 
b/drivers/gpu/drm/exynos/exynos_hdmiphy.c
index 6021996..59abb14 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmiphy.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmiphy.c
@@ -40,13 +40,6 @@ static int hdmiphy_remove(struct i2c_client *client)
return 0;
 }

-static const struct i2c_device_id hdmiphy_id[] = {
-   { "s5p_hdmiphy", 0 },
-   { "exynos5-hdmiphy", 0 },
-   { },
-};
-
-#ifdef CONFIG_OF
 static struct of_device_id hdmiphy_match_types[] = {
{
.compatible = "samsung,exynos5-hdmiphy",
@@ -58,15 +51,13 @@ static struct of_device_id hdmiphy_match_types[] = {
/* end node */
}
 };
-#endif

 struct i2c_driver hdmiphy_driver = {
.driver = {
.name   = "exynos-hdmiphy",
.owner  = THIS_MODULE,
-   .of_match_table = of_match_ptr(hdmiphy_match_types),
+   .of_match_table = hdmiphy_match_types,
},
-   .id_table = hdmiphy_id,
.probe  = hdmiphy_probe,
.remove = hdmiphy_remove,
.command= NULL,
-- 
1.7.9.5

[PATCH Resend 2/6] drm/exynos: Remove non-DT support in exynos_ddc

[Sachin Kamat]

Since commit 383ffda2fa ("ARM: EXYNOS: no more support non-DT
for EXYNOS SoCs"), Exynos platform is DT only. Hence remove
all the conditional macros and make the driver DT only.

Signed-off-by: Sachin Kamat 
---
 drivers/gpu/drm/exynos/exynos_ddc.c |   11 +--
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_ddc.c 
b/drivers/gpu/drm/exynos/exynos_ddc.c
index d1e539b..6a8c84e 100644
--- a/drivers/gpu/drm/exynos/exynos_ddc.c
+++ b/drivers/gpu/drm/exynos/exynos_ddc.c
@@ -41,13 +41,6 @@ static int s5p_ddc_remove(struct i2c_client *client)
return 0;
 }

-static struct i2c_device_id ddc_idtable[] = {
-   {"s5p_ddc", 0},
-   {"exynos5-hdmiddc", 0},
-   { },
-};
-
-#ifdef CONFIG_OF
 static struct of_device_id hdmiddc_match_types[] = {
{
.compatible = "samsung,exynos5-hdmiddc",
@@ -57,15 +50,13 @@ static struct of_device_id hdmiddc_match_types[] = {
/* end node */
}
 };
-#endif

 struct i2c_driver ddc_driver = {
.driver = {
.name = "exynos-hdmiddc",
.owner = THIS_MODULE,
-   .of_match_table = of_match_ptr(hdmiddc_match_types),
+   .of_match_table = hdmiddc_match_types,
},
-   .id_table   = ddc_idtable,
.probe  = s5p_ddc_probe,
.remove = s5p_ddc_remove,
.command= NULL,
-- 
1.7.9.5

[PATCH Resend 1/6] drm/exynos: Make Exynos DRM drivers depend on OF

[Sachin Kamat]

Exynos is a DT-only platform. Add this info to Kconfig.

Signed-off-by: Sachin Kamat 
---
Rebased this series on the latest Inki Dae's tree.
---
 drivers/gpu/drm/exynos/Kconfig |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 772c62a..80a251a 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -1,6 +1,6 @@
 config DRM_EXYNOS
tristate "DRM Support for Samsung SoC EXYNOS Series"
-   depends on DRM && (PLAT_SAMSUNG || ARCH_MULTIPLATFORM)
+   depends on OF && DRM && (PLAT_SAMSUNG || ARCH_MULTIPLATFORM)
select DRM_KMS_HELPER
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
@@ -24,7 +24,7 @@ config DRM_EXYNOS_DMABUF

 config DRM_EXYNOS_FIMD
bool "Exynos DRM FIMD"
-   depends on OF && DRM_EXYNOS && !FB_S3C && !ARCH_MULTIPLATFORM
+   depends on DRM_EXYNOS && !FB_S3C && !ARCH_MULTIPLATFORM
select FB_MODE_HELPERS
select VIDEOMODE_HELPERS
help
-- 
1.7.9.5

[PATCH 6/6] drm/nouveau: use MSI interrupts

[Ilia Mirkin]

On Wed, Aug 28, 2013 at 3:28 AM, Lucas Stach  wrote:
> Am Mittwoch, den 28.08.2013, 17:09 +1000 schrieb Ben Skeggs:
>> On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach  wrote:
>> > MSIs were only problematic on some old, broken chipsets. But now that we
>> > already see systems where PCI legacy interrupts are somewhat flaky, it's
>> > really time to move to MSIs.
>> >
>> > Signed-off-by: Lucas Stach 
>> > ---
>> >  drivers/gpu/drm/nouveau/core/include/subdev/mc.h |  1 +
>> >  drivers/gpu/drm/nouveau/core/subdev/mc/base.c| 17 +
>> >  2 files changed, 18 insertions(+)
>> >
>> > diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h 
>> > b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
>> > index 9d2cd20..ce6569f 100644
>> > --- a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
>> > +++ b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
>> > @@ -12,6 +12,7 @@ struct nouveau_mc_intr {
>> >  struct nouveau_mc {
>> > struct nouveau_subdev base;
>> > const struct nouveau_mc_intr *intr_map;
>> > +   bool use_msi;
>> >  };
>> >
>> >  static inline struct nouveau_mc *
>> > diff --git a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c 
>> > b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
>> > index ec9cd6f..02b337e 100644
>> > --- a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
>> > +++ b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
>> > @@ -23,6 +23,7 @@
>> >   */
>> >
>> >  #include 
>> > +#include 
>> >
>> >  static irqreturn_t
>> >  nouveau_mc_intr(int irq, void *arg)
>> > @@ -43,6 +44,9 @@ nouveau_mc_intr(int irq, void *arg)
>> > map++;
>> > }
>> >
>> > +   if (pmc->use_msi)
>> > +   nv_wr08(pmc->base.base.parent, 0x00088068, 0xff);
>> Register not present everywhere.
>>
>> At the very least, the enabling of MSI should be disallowed on the
>> earlier chipsets where it's not supported.  Though, it's perhaps
>> possible that the pci_enable_msi() call will fail in all of these
>> cases anyway.. I'm not certain.
>>
> MSIs are required property for everything doing PCIe. So the only cases
> where this should fail is plain PCI/AGP devices. I don't really have a
> test system for those old cards set up.
>
> But I remember Ilia having some legacy things plugged in, so maybe he
> could test this patch and see how it goes?

Sure, let me know what you need -- I have nv18 PCI, nv34 PCIe (note
that it's not native PCIe, but some sort of bridge thing IIRC), nv42
PCIe, nv44 PCIe, nv96 PCIe.

Can I just apply this patch, or do I need to do the whole series? What
constitutes a success?

  -ilia

[PATCH 0/6] Nouveau on ARM fixes

[Thierry Reding]

On Wed, Aug 28, 2013 at 02:00:44AM +0200, Lucas Stach wrote:
> This is the first set of patches to make Nouveau work
> on Tegra.

Perhaps you should clarify that this patch series allows discrete GPUs
to be used via Tegra's PCIe interface.

People might misinterpret...

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/20130828/06f67182/attachment.pgp>

[PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap

[Maarten Lankhorst]

Op 28-08-13 08:29, Pasi K?rkk?inen schreef:
> On Fri, Aug 23, 2013 at 11:20:42PM +0300, Pasi K?rkk?inen wrote:
>> On Thu, Aug 22, 2013 at 09:12:40AM +0200, Maarten Lankhorst wrote:
>>> Op 22-08-13 02:10, Ilia Mirkin schreef:
 The code expects non-VRAM mem nodes to have a pages list. If that's not
 set, it will do a null deref down the line. Warn on that condition and
 return an error.

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

 Reported-by: Pasi K?rkk?inen 
 Tested-by: Pasi K?rkk?inen 
 Signed-off-by: Ilia Mirkin 
 Cc:  # 3.8+
 ---

 I don't exactly understand what's going on, but this is just a
 straightforward way to avoid a null deref that you see happens in the
 bug. I haven't figured out the root cause of this, but it's getting
 well into the "I have no idea how TTM works" space. However this seems
 like a bit of defensive programming -- nouveau_vm_map_sg will pass
 node->pages as a list down, which will be dereferenced by
 nvc0_vm_map_sg. Perhaps the other arguments should make that
 dereferencing not happen, but it definitely was happening here, as you
 can see in the bug.

 Ben/Maarten, I'll let you judge whether this check is appropriate,
 since like I hope I was able to convey above, I'm just not really sure :)
>>> Not it really isn't appropriate..
>>>
>>> You'd have to call call nouveau_vm_map_sg_table instead, the only place 
>>> that doesn't handle that correctly
>>> is where it's not expected to be called.
>>>
>>> Here, have a completely untested patch to fix things...
>>>
>> Maarten: I've been testing this stuff with Linux 3.10.x, so I had to modify 
>> the patch a bit to make it apply there.. 
>> I've attached the modified copy that applies to 3.10.9, hopefully I did the 
>> backport correctly.
>>
>> With Linux 3.10.9 and the patch applied the kernel doesn't crash anymore, 
>> and I get this error in dmesg:
>>
>> [   76.105643] nouveau W[ DRM] Trying to create a fb in vram with 
>> valid_domains=0004
>>
>> Does that help? 
>>
> Any comments? 
>
> Maarten's patch works for me, I get that warning instead of a kernel crash,
> but it's also a bigger change that doesn't apply to older kernels as-is. 
>
> Ilia's original patch in this thread can be applied to older kernels as-is,
> and it also prevents the kernel crash from happening.
>
> Should we get both applied, so Ilia's patch can be CC'd to stable ? 
>
You haven't understood the root cause then. You're trying to move an IMPORTED 
dma-buf into VRAM.
Doing so would seem to work, but at that point it's no longer a dma-buf so 
changes done by the exporter
would not show up in nouveau because they no longer refer to the same piece of 
memory.

Failing is the only right option here.

~Maarten

[PATCH 4/6] drm/nouveau: introduce NOUVEAU_GEM_TILE_WCUS

[Lucas Stach]

Am Mittwoch, den 28.08.2013, 17:11 +1000 schrieb Ben Skeggs:
> On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach  wrote:
> > This flag allows userspace to give the kernel a hint that it should use
> > a non-snooped resource. To guarantee coherency at all times mappings
> > into userspace are done write combined, so userspace should avoid
> > reading back from those resources.
> Do any other combinations of cached/uncached and snooped/non-snooped
> make any sense?  If so, perhaps we want to split the flags.
> 
Thought about that and I came to the conclusion that it isn't worth the
hassle. If we split it then things get more complicated on x86, were we
would have to invalidate caches manually with all the related
performance implications.

So I think it's a lot easier for userspace writers to just set the WCUS
flag on resources where the can promise no to touch the resource for
reading (AFAIR Christoph wanted this flag mostly for resources that the
driver isn't going to touch ever), or where it can happily live with
uncached reading.

> >
> > Signed-off-by: Lucas Stach 
> > ---
> > On x86 an optimized userspace can save up on snoop traffic in the
> > system, on ARM the benefits are potentially much larger, as we can save
> > the manual cache flush/invalidate.
> > ---
> >  drivers/gpu/drm/nouveau/nouveau_bo.c | 11 ++-
> >  drivers/gpu/drm/nouveau/nouveau_bo.h |  1 +
> >  include/uapi/drm/nouveau_drm.h   |  1 +
> >  3 files changed, 12 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
> > b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > index f4a2eb9..c5fcbcc 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> > +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > @@ -231,6 +231,12 @@ nouveau_bo_new(struct drm_device *dev, int size, int 
> > align,
> >
> > nouveau_bo_fixup_align(nvbo, flags, , );
> > nvbo->bo.mem.num_pages = size >> PAGE_SHIFT;
> > +
> > +   if (tile_flags & NOUVEAU_GEM_TILE_WCUS)
> > +   nvbo->valid_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
> > +   else
> > +   nvbo->valid_caching = TTM_PL_MASK_CACHING;
> > +
> > nouveau_bo_placement_set(nvbo, flags, 0);
> >
> > acc_size = ttm_bo_dma_acc_size(>ttm.bdev, size,
> > @@ -292,7 +298,7 @@ void
> >  nouveau_bo_placement_set(struct nouveau_bo *nvbo, uint32_t type, uint32_t 
> > busy)
> >  {
> > struct ttm_placement *pl = >placement;
> > -   uint32_t flags = TTM_PL_MASK_CACHING |
> > +   uint32_t flags = nvbo->valid_caching |
> > (nvbo->pin_refcnt ? TTM_PL_FLAG_NO_EVICT : 0);
> >
> > pl->placement = nvbo->placements;
> > @@ -1554,6 +1560,9 @@ nouveau_bo_vma_add(struct nouveau_bo *nvbo, struct 
> > nouveau_vm *vm,
> > if (nvbo->bo.mem.mem_type == TTM_PL_VRAM)
> > nouveau_vm_map(vma, nvbo->bo.mem.mm_node);
> > else if (nvbo->bo.mem.mem_type == TTM_PL_TT) {
> > +   if (!(nvbo->valid_caching & TTM_PL_FLAG_CACHED))
> > +   vma->access |= NV_MEM_ACCESS_NOSNOOP;
> > +
> > if (node->sg)
> > nouveau_vm_map_sg_table(vma, 0, size, node);
> > else
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.h 
> > b/drivers/gpu/drm/nouveau/nouveau_bo.h
> > index 653dbbb..2ecf8b7 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_bo.h
> > +++ b/drivers/gpu/drm/nouveau/nouveau_bo.h
> > @@ -9,6 +9,7 @@ struct nouveau_bo {
> > struct ttm_buffer_object bo;
> > struct ttm_placement placement;
> > u32 valid_domains;
> > +   u32 valid_caching;
> > u32 placements[3];
> > u32 busy_placements[3];
> > struct ttm_bo_kmap_obj kmap;
> > diff --git a/include/uapi/drm/nouveau_drm.h b/include/uapi/drm/nouveau_drm.h
> > index 2a5769f..4948eee2 100644
> > --- a/include/uapi/drm/nouveau_drm.h
> > +++ b/include/uapi/drm/nouveau_drm.h
> > @@ -36,6 +36,7 @@
> >  #define NOUVEAU_GEM_TILE_32BPP   0x0002
> >  #define NOUVEAU_GEM_TILE_ZETA0x0004
> >  #define NOUVEAU_GEM_TILE_NONCONTIG   0x0008
> > +#define NOUVEAU_GEM_TILE_WCUS0x0010 /* write-combined, 
> > unsnooped */
> >
> >  struct drm_nouveau_gem_info {
> > uint32_t handle;
> > --
> > 1.8.3.1
> >

[PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap

[Pasi Kärkkäinen]

On Fri, Aug 23, 2013 at 11:20:42PM +0300, Pasi K?rkk?inen wrote:
> On Thu, Aug 22, 2013 at 09:12:40AM +0200, Maarten Lankhorst wrote:
> > Op 22-08-13 02:10, Ilia Mirkin schreef:
> > > The code expects non-VRAM mem nodes to have a pages list. If that's not
> > > set, it will do a null deref down the line. Warn on that condition and
> > > return an error.
> > >
> > > See https://bugs.freedesktop.org/show_bug.cgi?id=64774
> > >
> > > Reported-by: Pasi K?rkk?inen 
> > > Tested-by: Pasi K?rkk?inen 
> > > Signed-off-by: Ilia Mirkin 
> > > Cc:  # 3.8+
> > > ---
> > >
> > > I don't exactly understand what's going on, but this is just a
> > > straightforward way to avoid a null deref that you see happens in the
> > > bug. I haven't figured out the root cause of this, but it's getting
> > > well into the "I have no idea how TTM works" space. However this seems
> > > like a bit of defensive programming -- nouveau_vm_map_sg will pass
> > > node->pages as a list down, which will be dereferenced by
> > > nvc0_vm_map_sg. Perhaps the other arguments should make that
> > > dereferencing not happen, but it definitely was happening here, as you
> > > can see in the bug.
> > >
> > > Ben/Maarten, I'll let you judge whether this check is appropriate,
> > > since like I hope I was able to convey above, I'm just not really sure :)
> > Not it really isn't appropriate..
> > 
> > You'd have to call call nouveau_vm_map_sg_table instead, the only place 
> > that doesn't handle that correctly
> > is where it's not expected to be called.
> > 
> > Here, have a completely untested patch to fix things...
> > 
> 
> Maarten: I've been testing this stuff with Linux 3.10.x, so I had to modify 
> the patch a bit to make it apply there.. 
> I've attached the modified copy that applies to 3.10.9, hopefully I did the 
> backport correctly.
> 
> With Linux 3.10.9 and the patch applied the kernel doesn't crash anymore, and 
> I get this error in dmesg:
> 
> [   76.105643] nouveau W[ DRM] Trying to create a fb in vram with 
> valid_domains=0004
> 
> Does that help? 
>

Any comments? 

Maarten's patch works for me, I get that warning instead of a kernel crash,
but it's also a bigger change that doesn't apply to older kernels as-is. 

Ilia's original patch in this thread can be applied to older kernels as-is,
and it also prevents the kernel crash from happening.

Should we get both applied, so Ilia's patch can be CC'd to stable ? 

-- Pasi


> --- 
> linux-3.10.9-100.fc18.x86_64/drivers/gpu/drm/nouveau/nouveau_display.c.orig   
> 2013-07-01 01:13:29.0 +0300
> +++ linux-3.10.9-100.fc18.x86_64/drivers/gpu/drm/nouveau/nouveau_display.c
> 2013-08-23 19:56:52.038234281 +0300
> @@ -137,18 +137,31 @@
>  {
>   struct nouveau_framebuffer *nouveau_fb;
>   struct drm_gem_object *gem;
> + struct nouveau_bo *nvbo;
>   int ret;
>  
>   gem = drm_gem_object_lookup(dev, file_priv, mode_cmd->handles[0]);
>   if (!gem)
>   return ERR_PTR(-ENOENT);
>  
> + nvbo = nouveau_gem_object(gem);
> + if (!(nvbo->valid_domains & NOUVEAU_GEM_DOMAIN_VRAM)) {
> + nv_warn(nouveau_drm(dev), "Trying to create a fb in vram with"
> + " valid_domains=%08x\n", nvbo->valid_domains);
> + ret = -EINVAL;
> + drm_gem_object_unreference(gem);
> + return ERR_PTR(ret);
> + }
> +
>   nouveau_fb = kzalloc(sizeof(struct nouveau_framebuffer), GFP_KERNEL);
> - if (!nouveau_fb)
> + if (!nouveau_fb) {
> + drm_gem_object_unreference(gem);
>   return ERR_PTR(-ENOMEM);
> + }
>  
> - ret = nouveau_framebuffer_init(dev, nouveau_fb, mode_cmd, 
> nouveau_gem_object(gem));
> + ret = nouveau_framebuffer_init(dev, nouveau_fb, mode_cmd, nvbo);
>   if (ret) {
> + kfree(nouveau_fb);
>   drm_gem_object_unreference(gem);
>   return ERR_PTR(ret);
>   }

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

[PATCH 6/6] drm/nouveau: use MSI interrupts

[Lucas Stach]

Am Mittwoch, den 28.08.2013, 17:09 +1000 schrieb Ben Skeggs:
> On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach  wrote:
> > MSIs were only problematic on some old, broken chipsets. But now that we
> > already see systems where PCI legacy interrupts are somewhat flaky, it's
> > really time to move to MSIs.
> >
> > Signed-off-by: Lucas Stach 
> > ---
> >  drivers/gpu/drm/nouveau/core/include/subdev/mc.h |  1 +
> >  drivers/gpu/drm/nouveau/core/subdev/mc/base.c| 17 +
> >  2 files changed, 18 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h 
> > b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
> > index 9d2cd20..ce6569f 100644
> > --- a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
> > +++ b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
> > @@ -12,6 +12,7 @@ struct nouveau_mc_intr {
> >  struct nouveau_mc {
> > struct nouveau_subdev base;
> > const struct nouveau_mc_intr *intr_map;
> > +   bool use_msi;
> >  };
> >
> >  static inline struct nouveau_mc *
> > diff --git a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c 
> > b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
> > index ec9cd6f..02b337e 100644
> > --- a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
> > +++ b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
> > @@ -23,6 +23,7 @@
> >   */
> >
> >  #include 
> > +#include 
> >
> >  static irqreturn_t
> >  nouveau_mc_intr(int irq, void *arg)
> > @@ -43,6 +44,9 @@ nouveau_mc_intr(int irq, void *arg)
> > map++;
> > }
> >
> > +   if (pmc->use_msi)
> > +   nv_wr08(pmc->base.base.parent, 0x00088068, 0xff);
> Register not present everywhere.
> 
> At the very least, the enabling of MSI should be disallowed on the
> earlier chipsets where it's not supported.  Though, it's perhaps
> possible that the pci_enable_msi() call will fail in all of these
> cases anyway.. I'm not certain.
> 
MSIs are required property for everything doing PCIe. So the only cases
where this should fail is plain PCI/AGP devices. I don't really have a
test system for those old cards set up.

But I remember Ilia having some legacy things plugged in, so maybe he
could test this patch and see how it goes?

> > +
> > if (intr) {
> > nv_error(pmc, "unknown intr 0x%08x\n", stat);
> > }
> > @@ -75,6 +79,8 @@ _nouveau_mc_dtor(struct nouveau_object *object)
> > struct nouveau_device *device = nv_device(object);
> > struct nouveau_mc *pmc = (void *)object;
> > free_irq(device->pdev->irq, pmc);
> > +   if (pmc->use_msi)
> > +   pci_disable_msi(device->pdev);
> > nouveau_subdev_destroy(>base);
> >  }
> >
> > @@ -96,6 +102,17 @@ nouveau_mc_create_(struct nouveau_object *parent, 
> > struct nouveau_object *engine,
> >
> > pmc->intr_map = intr_map;
> >
> > +   pmc->use_msi = nouveau_boolopt(device->cfgopt, "NvMSI", true);
> > +   if (pmc->use_msi) {
> > +   ret = pci_enable_msi(device->pdev);
> > +   if (ret) {
> > +   pmc->use_msi = false;
> > +   } else {
> > +   nv_wr08(device, 0x00088068, 0xff);
> > +   nv_info(pmc, "MSI interrupts enabled\n");
> > +   }
> > +   }
> > +
> > ret = request_irq(device->pdev->irq, nouveau_mc_intr,
> >   IRQF_SHARED, "nouveau", pmc);
> > if (ret < 0)
> > --
> > 1.8.3.1
> >

[Bug 64810] EGL/Gles/Weston give segfault on RADEONSI with egl_gallium.so

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

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

--- Comment #12 from Michel D?nzer  ---
(In reply to comment #11)
> fix multiple symbols bug

Thanks for the patch, but I think it's more invasive than necessary. We'd like
to retain the possibility of sharing code between radeonsi and r600g in the
future.

Can you try if Johannes' patch from comment 8 fixes the problem?

-- 
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/20130828/a644f079/attachment.html>

[Bug 52952] Ubuntu 10.04.4 LTS 32-bit and ATI Technologies Radeon Xpress 200 for Intel (RC410) ACPI S3 State Resume Failure

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

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

--- Comment #20 from Daniel T.  ---
Hi Alex,

I with the patch you have posted (commnet #19) against 3.10.9 , I have so far
been able to suspend and resume about 8 times without issue! Before the first
try would always fail. This part seems to be solved

you can add my Tested-by: Daniel Tobias dan.g.tob at gmail.com

I have however got warnings about low memory corruption caused by bios, doesnt
seem to cause any issues however

[  120.373369] Corrupted low memory at c0009ff4 (9ff4 phys) = 0cd7
[  120.375589] Corrupted low memory at c0009ff8 (9ff8 phys) = 0100
[  120.377841] [ cut here ]
[  120.380103] WARNING: at arch/x86/kernel/check.c:140
check_for_bios_corruption+0xbe/0xd0()
[  120.382386] Memory corruption detected in low memory
[  120.384616] Modules linked in:
[  120.386901] CPU: 0 PID: 190 Comm: kworker/0:3 Not tainted 3.10.9-ARCH #1
[  120.389250] Hardware name:  /D101GGC   
, BIOS GC11010N.86A.0313.2006.0915.1840 09/15/2006
[  120.391682] Workqueue: events check_corruption
[  120.394125]  f363fecc f363fecc f363fe94 c16ad588 f363febc c103af4e c1815f00
f363fee8
[  120.396693]  008c c102f48e c102f48e  c001 c1a38570 f363fed4
c103afa3
[  120.399336]  0009 f363fecc c1815f00 f363fee8 f363fefc c102f48e c180deed
008c
[  120.402004] Call Trace:
[  120.404622]  [] dump_stack+0x16/0x18
[  120.407244]  [] warn_slowpath_common+0x5e/0x80
[  120.409884]  [] ? check_for_bios_corruption+0xbe/0xd0
[  120.412562]  [] ? check_for_bios_corruption+0xbe/0xd0
[  120.415234]  [] warn_slowpath_fmt+0x33/0x40
[  120.417846]  [] check_for_bios_corruption+0xbe/0xd0
[  120.420536]  [] check_corruption+0x10/0x40
[  120.423224]  [] process_one_work+0x107/0x380
[  120.425944]  [] worker_thread+0x101/0x340
[  120.428678]  [] ? manage_workers.isra.26+0x250/0x250
[  120.431440]  [] kthread+0x94/0xa0
[  120.434116]  [] ? down_interruptible+0x20/0x50
[  120.436897]  [] ret_from_kernel_thread+0x1b/0x28
[  120.439745]  [] ? kthread_create_on_node+0xc0/0xc0
[  120.442585] ---[ end trace 81f23fa39f4c88a9 ]---

If you need any more info let me know. 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/20130828/93bf390d/attachment-0001.html>

[Bug 64810] EGL/Gles/Weston give segfault on RADEONSI with egl_gallium.so

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

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

--- Comment #11 from tux_mind  ---
Created attachment 84756
  --> https://bugs.freedesktop.org/attachment.cgi?id=84756=edit
fix multiple symbols 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/20130828/4c85dbef/attachment.html>

[PATCH 6/6] drm/nouveau: use MSI interrupts

[Lucas Stach]

MSIs were only problematic on some old, broken chipsets. But now that we
already see systems where PCI legacy interrupts are somewhat flaky, it's
really time to move to MSIs.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/nouveau/core/include/subdev/mc.h |  1 +
 drivers/gpu/drm/nouveau/core/subdev/mc/base.c| 17 +
 2 files changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h 
b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
index 9d2cd20..ce6569f 100644
--- a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
+++ b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
@@ -12,6 +12,7 @@ struct nouveau_mc_intr {
 struct nouveau_mc {
struct nouveau_subdev base;
const struct nouveau_mc_intr *intr_map;
+   bool use_msi;
 };

 static inline struct nouveau_mc *
diff --git a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c 
b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
index ec9cd6f..02b337e 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
@@ -23,6 +23,7 @@
  */

 #include 
+#include 

 static irqreturn_t
 nouveau_mc_intr(int irq, void *arg)
@@ -43,6 +44,9 @@ nouveau_mc_intr(int irq, void *arg)
map++;
}

+   if (pmc->use_msi)
+   nv_wr08(pmc->base.base.parent, 0x00088068, 0xff);
+
if (intr) {
nv_error(pmc, "unknown intr 0x%08x\n", stat);
}
@@ -75,6 +79,8 @@ _nouveau_mc_dtor(struct nouveau_object *object)
struct nouveau_device *device = nv_device(object);
struct nouveau_mc *pmc = (void *)object;
free_irq(device->pdev->irq, pmc);
+   if (pmc->use_msi)
+   pci_disable_msi(device->pdev);
nouveau_subdev_destroy(>base);
 }

@@ -96,6 +102,17 @@ nouveau_mc_create_(struct nouveau_object *parent, struct 
nouveau_object *engine,

pmc->intr_map = intr_map;

+   pmc->use_msi = nouveau_boolopt(device->cfgopt, "NvMSI", true);
+   if (pmc->use_msi) {
+   ret = pci_enable_msi(device->pdev);
+   if (ret) {
+   pmc->use_msi = false;
+   } else {
+   nv_wr08(device, 0x00088068, 0xff);
+   nv_info(pmc, "MSI interrupts enabled\n");
+   }
+   }
+
ret = request_irq(device->pdev->irq, nouveau_mc_intr,
  IRQF_SHARED, "nouveau", pmc);
if (ret < 0)
-- 
1.8.3.1

[PATCH 5/6] drm/nouveau: map IB write-combined

[Lucas Stach]

Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/nouveau/nouveau_chan.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_chan.c 
b/drivers/gpu/drm/nouveau/nouveau_chan.c
index e84f4c3..3b54e8f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_chan.c
+++ b/drivers/gpu/drm/nouveau/nouveau_chan.c
@@ -114,7 +114,8 @@ nouveau_channel_prep(struct nouveau_drm *drm, struct 
nouveau_cli *cli,
if (nouveau_vram_pushbuf)
target = TTM_PL_FLAG_VRAM;

-   ret = nouveau_bo_new(drm->dev, size, 0, target, 0, 0, NULL,
+   ret = nouveau_bo_new(drm->dev, size, 0, target, 0,
+   NOUVEAU_GEM_TILE_WCUS, NULL,
>push.buffer);
if (ret == 0) {
ret = nouveau_bo_pin(chan->push.buffer, target);
-- 
1.8.3.1

[PATCH 4/6] drm/nouveau: introduce NOUVEAU_GEM_TILE_WCUS

[Lucas Stach]

This flag allows userspace to give the kernel a hint that it should use
a non-snooped resource. To guarantee coherency at all times mappings
into userspace are done write combined, so userspace should avoid
reading back from those resources.

Signed-off-by: Lucas Stach 
---
On x86 an optimized userspace can save up on snoop traffic in the
system, on ARM the benefits are potentially much larger, as we can save
the manual cache flush/invalidate.
---
 drivers/gpu/drm/nouveau/nouveau_bo.c | 11 ++-
 drivers/gpu/drm/nouveau/nouveau_bo.h |  1 +
 include/uapi/drm/nouveau_drm.h   |  1 +
 3 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index f4a2eb9..c5fcbcc 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -231,6 +231,12 @@ nouveau_bo_new(struct drm_device *dev, int size, int align,

nouveau_bo_fixup_align(nvbo, flags, , );
nvbo->bo.mem.num_pages = size >> PAGE_SHIFT;
+
+   if (tile_flags & NOUVEAU_GEM_TILE_WCUS)
+   nvbo->valid_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
+   else
+   nvbo->valid_caching = TTM_PL_MASK_CACHING;
+
nouveau_bo_placement_set(nvbo, flags, 0);

acc_size = ttm_bo_dma_acc_size(>ttm.bdev, size,
@@ -292,7 +298,7 @@ void
 nouveau_bo_placement_set(struct nouveau_bo *nvbo, uint32_t type, uint32_t busy)
 {
struct ttm_placement *pl = >placement;
-   uint32_t flags = TTM_PL_MASK_CACHING |
+   uint32_t flags = nvbo->valid_caching |
(nvbo->pin_refcnt ? TTM_PL_FLAG_NO_EVICT : 0);

pl->placement = nvbo->placements;
@@ -1554,6 +1560,9 @@ nouveau_bo_vma_add(struct nouveau_bo *nvbo, struct 
nouveau_vm *vm,
if (nvbo->bo.mem.mem_type == TTM_PL_VRAM)
nouveau_vm_map(vma, nvbo->bo.mem.mm_node);
else if (nvbo->bo.mem.mem_type == TTM_PL_TT) {
+   if (!(nvbo->valid_caching & TTM_PL_FLAG_CACHED))
+   vma->access |= NV_MEM_ACCESS_NOSNOOP;
+
if (node->sg)
nouveau_vm_map_sg_table(vma, 0, size, node);
else
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.h 
b/drivers/gpu/drm/nouveau/nouveau_bo.h
index 653dbbb..2ecf8b7 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.h
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.h
@@ -9,6 +9,7 @@ struct nouveau_bo {
struct ttm_buffer_object bo;
struct ttm_placement placement;
u32 valid_domains;
+   u32 valid_caching;
u32 placements[3];
u32 busy_placements[3];
struct ttm_bo_kmap_obj kmap;
diff --git a/include/uapi/drm/nouveau_drm.h b/include/uapi/drm/nouveau_drm.h
index 2a5769f..4948eee2 100644
--- a/include/uapi/drm/nouveau_drm.h
+++ b/include/uapi/drm/nouveau_drm.h
@@ -36,6 +36,7 @@
 #define NOUVEAU_GEM_TILE_32BPP   0x0002
 #define NOUVEAU_GEM_TILE_ZETA0x0004
 #define NOUVEAU_GEM_TILE_NONCONTIG   0x0008
+#define NOUVEAU_GEM_TILE_WCUS0x0010 /* write-combined, unsnooped */

 struct drm_nouveau_gem_info {
uint32_t handle;
-- 
1.8.3.1

[PATCH 3/6] drm/nouveau: hook up cache sync functions

[Lucas Stach]

Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/nouveau/nouveau_bo.c  | 4 
 drivers/gpu/drm/nouveau/nouveau_gem.c | 5 +
 2 files changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index af20fba..f4a2eb9 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -411,6 +411,10 @@ nouveau_bo_validate(struct nouveau_bo *nvbo, bool 
interruptible,
 {
int ret;

+   if (nvbo->bo.ttm && nvbo->bo.ttm->caching_state == tt_cached)
+   ttm_dma_tt_cache_sync_for_device((struct ttm_dma_tt 
*)nvbo->bo.ttm,
+   _bdev(nvbo->bo.ttm->bdev)->dev->pdev->dev);
+
ret = ttm_bo_validate(>bo, >placement,
  interruptible, no_wait_gpu);
if (ret)
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c 
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index 830cb7b..f632b92 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -901,6 +901,11 @@ nouveau_gem_ioctl_cpu_prep(struct drm_device *dev, void 
*data,
ret = ttm_bo_wait(>bo, true, true, no_wait);
spin_unlock(>bo.bdev->fence_lock);
drm_gem_object_unreference_unlocked(gem);
+
+   if (!ret && nvbo->bo.ttm && nvbo->bo.ttm->caching_state == tt_cached)
+   ttm_dma_tt_cache_sync_for_cpu((struct ttm_dma_tt *)nvbo->bo.ttm,
+ >pdev->dev);
+
return ret;
 }

-- 
1.8.3.1

[PATCH 2/6] drm/ttm: introduce dma cache sync helpers

[Lucas Stach]

On arches with non-coherent PCI, we need to flush caches ourselfes at
the appropriate places. Introduce two small helpers to make things easy
for TTM based drivers.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/ttm/ttm_tt.c| 25 +
 include/drm/ttm/ttm_bo_driver.h | 28 
 2 files changed, 53 insertions(+)

diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 5e93a52..935e121 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -38,6 +38,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -249,6 +250,30 @@ void ttm_dma_tt_fini(struct ttm_dma_tt *ttm_dma)
 }
 EXPORT_SYMBOL(ttm_dma_tt_fini);

+void ttm_dma_tt_cache_sync_for_device(struct ttm_dma_tt *ttm_dma,
+ struct device *dev)
+{
+   int i;
+
+   for (i = 0; i < ttm_dma->ttm.num_pages; i++) {
+   dma_sync_single_for_device(dev, ttm_dma->dma_address[i],
+  PAGE_SIZE, DMA_TO_DEVICE);
+   }
+}
+EXPORT_SYMBOL(ttm_dma_tt_cache_sync_for_device);
+
+void ttm_dma_tt_cache_sync_for_cpu(struct ttm_dma_tt *ttm_dma,
+  struct device *dev)
+{
+   int i;
+
+   for (i = 0; i < ttm_dma->ttm.num_pages; i++) {
+   dma_sync_single_for_cpu(dev, ttm_dma->dma_address[i],
+   PAGE_SIZE, DMA_FROM_DEVICE);
+   }
+}
+EXPORT_SYMBOL(ttm_dma_tt_cache_sync_for_cpu);
+
 void ttm_tt_unbind(struct ttm_tt *ttm)
 {
int ret;
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index 984fc2d..db5f3b5 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -40,6 +40,7 @@
 #include 
 #include 
 #include 
+#include 

 struct ttm_backend_func {
/**
@@ -681,6 +682,33 @@ extern int ttm_tt_set_placement_caching(struct ttm_tt 
*ttm, uint32_t placement);
 extern int ttm_tt_swapout(struct ttm_tt *ttm,
  struct file *persistent_swap_storage);

+/**
+ * ttm_dma_tt_cache_sync_for_device:
+ *
+ * @ttm A struct ttm_tt of the type returned by ttm_dma_tt_init.
+ * @dev A struct device representing the device to which to sync.
+ *
+ * This function will flush the CPU caches on arches where snooping in the
+ * TT is not available. On fully coherent arches this will turn into an 
(almost)
+ * noop. This makes sure that data written by the CPU is visible to the device.
+ */
+extern void ttm_dma_tt_cache_sync_for_device(struct ttm_dma_tt *ttm_dma,
+struct device *dev);
+
+/**
+ * ttm_dma_tt_cache_sync_for_cpu:
+ *
+ * @ttm A struct ttm_tt of the type returned by ttm_dma_tt_init.
+ * @dev A struct device representing the device from which to sync.
+ *
+ * This function will invalidate the CPU caches on arches where snooping in the
+ * TT is not available. On fully coherent arches this will turn into an 
(almost)
+ * noop. This makes sure that the CPU does not read any stale cached or
+ * prefetched data.
+ */
+extern void ttm_dma_tt_cache_sync_for_cpu(struct ttm_dma_tt *ttm_dma,
+ struct device *dev);
+
 /*
  * ttm_bo.c
  */
-- 
1.8.3.1

[PATCH 1/6] drm/ttm: recognize ARM arch in ioprot handler

[Lucas Stach]

Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/ttm/ttm_bo_util.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 319cf41..db15687 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -487,7 +487,7 @@ pgprot_t ttm_io_prot(uint32_t caching_flags, pgprot_t tmp)
pgprot_val(tmp) |= _PAGE_GUARDED;
}
 #endif
-#if defined(__ia64__)
+#if defined(__ia64__) || defined(__arm__)
if (caching_flags & TTM_PL_FLAG_WC)
tmp = pgprot_writecombine(tmp);
else
-- 
1.8.3.1

[PATCH 0/6] Nouveau on ARM fixes

[Lucas Stach]

This is the first set of patches to make Nouveau work
on Tegra. Those are only the obvious correctness fixes,
a lot of optimization work remains to be done, but at least
it's enough to get accel working and let the machine survive
a piglit run.

A new BO flag is introduced to allow userspace to hint the
kernel about possible optimizations.

Lucas Stach (6):
  drm/ttm: recognize ARM arch in ioprot handler
  drm/ttm: introduce dma cache sync helpers
  drm/nouveau: hook up cache sync functions
  drm/nouveau: introduce NOUVEAU_GEM_TILE_WCUS
  drm/nouveau: map IB write-combined
  drm/nouveau: use MSI interrupts

 drivers/gpu/drm/nouveau/core/include/subdev/mc.h |  1 +
 drivers/gpu/drm/nouveau/core/subdev/mc/base.c| 17 ++
 drivers/gpu/drm/nouveau/nouveau_bo.c | 15 -
 drivers/gpu/drm/nouveau/nouveau_bo.h |  1 +
 drivers/gpu/drm/nouveau/nouveau_chan.c   |  3 ++-
 drivers/gpu/drm/nouveau/nouveau_gem.c|  5 +
 drivers/gpu/drm/ttm/ttm_bo_util.c|  2 +-
 drivers/gpu/drm/ttm/ttm_tt.c | 25 +
 include/drm/ttm/ttm_bo_driver.h  | 28 
 include/uapi/drm/nouveau_drm.h   |  1 +
 10 files changed, 95 insertions(+), 3 deletions(-)

-- 
1.8.3.1

[Bug 64810] EGL/Gles/Weston give segfault on RADEONSI with egl_gallium.so

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

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

--- Comment #10 from tux_mind  ---
(In reply to comment #3)
> I think the problem is that egl_gallium.so links both radeonsi and r600g,
> which have some conflicting symbols.

you're right!

http://pastebin.com/Zq3NDDeX

i'm patching mesa 9.2.0_rc1 to get this working.

-- 
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/20130828/2d2c39d6/attachment.html>

[Bug 60791] Display corruption with Radeon driver during boot and on desktop

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

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

--- Comment #12 from Brian Hall  ---
Bisect results below. According to my Xorg.0.log, my board is a 
"ATI Radeon HD 4200" (ChipID = 0x9710) and lspci calls it a RS880.

6f8bbaf568c7f2c497558bfd04654c0b9841ad57 is the first bad commit
commit 6f8bbaf568c7f2c497558bfd04654c0b9841ad57
Author: Alex Deucher 
Date:   Tue Jul 30 00:22:53 2013 -0400

drm/radeon/atom: initialize more atom interpretor elements to 0

commit 42a21826dc54583cdb79cc8477732e911ac9c376 upstream.

The ProcessAuxChannel table on some rv635 boards assumes
the divmul members are initialized to 0 otherwise we get
an invalid fb offset since it has a bad mask set when
setting the fb base.  While here initialize all the
atom interpretor elements to 0.

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

Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman 

:04 04 d2bb057047f71419a89def40e6e21dc948c5784c
7e49987ae73078e644723f0cb6c791e15e102ab0 Mdrivers

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

[Bug 52952] Ubuntu 10.04.4 LTS 32-bit and ATI Technologies Radeon Xpress 200 for Intel (RC410) ACPI S3 State Resume Failure

[bugzilla-daemon]

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

--- Comment #20 from Daniel T. dan.g@gmail.com ---
Hi Alex,

I with the patch you have posted (commnet #19) against 3.10.9 , I have so far
been able to suspend and resume about 8 times without issue! Before the first
try would always fail. This part seems to be solved

you can add my Tested-by: Daniel Tobias dan.g@gmail.com

I have however got warnings about low memory corruption caused by bios, doesnt
seem to cause any issues however

[  120.373369] Corrupted low memory at c0009ff4 (9ff4 phys) = 0cd7
[  120.375589] Corrupted low memory at c0009ff8 (9ff8 phys) = 0100
[  120.377841] [ cut here ]
[  120.380103] WARNING: at arch/x86/kernel/check.c:140
check_for_bios_corruption+0xbe/0xd0()
[  120.382386] Memory corruption detected in low memory
[  120.384616] Modules linked in:
[  120.386901] CPU: 0 PID: 190 Comm: kworker/0:3 Not tainted 3.10.9-ARCH #1
[  120.389250] Hardware name:  /D101GGC   
, BIOS GC11010N.86A.0313.2006.0915.1840 09/15/2006
[  120.391682] Workqueue: events check_corruption
[  120.394125]  f363fecc f363fecc f363fe94 c16ad588 f363febc c103af4e c1815f00
f363fee8
[  120.396693]  008c c102f48e c102f48e  c001 c1a38570 f363fed4
c103afa3
[  120.399336]  0009 f363fecc c1815f00 f363fee8 f363fefc c102f48e c180deed
008c
[  120.402004] Call Trace:
[  120.404622]  [c16ad588] dump_stack+0x16/0x18
[  120.407244]  [c103af4e] warn_slowpath_common+0x5e/0x80
[  120.409884]  [c102f48e] ? check_for_bios_corruption+0xbe/0xd0
[  120.412562]  [c102f48e] ? check_for_bios_corruption+0xbe/0xd0
[  120.415234]  [c103afa3] warn_slowpath_fmt+0x33/0x40
[  120.417846]  [c102f48e] check_for_bios_corruption+0xbe/0xd0
[  120.420536]  [c102f4b0] check_corruption+0x10/0x40
[  120.423224]  [c1055327] process_one_work+0x107/0x380
[  120.425944]  [c1055b81] worker_thread+0x101/0x340
[  120.428678]  [c1055a80] ? manage_workers.isra.26+0x250/0x250
[  120.431440]  [c105ad84] kthread+0x94/0xa0
[  120.434116]  [c106] ? down_interruptible+0x20/0x50
[  120.436897]  [c16b8e77] ret_from_kernel_thread+0x1b/0x28
[  120.439745]  [c105acf0] ? kthread_create_on_node+0xc0/0xc0
[  120.442585] ---[ end trace 81f23fa39f4c88a9 ]---

If you need any more info let me know. thanks

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

Re: [PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap

[Pasi Kärkkäinen]

On Fri, Aug 23, 2013 at 11:20:42PM +0300, Pasi Kärkkäinen wrote:
 On Thu, Aug 22, 2013 at 09:12:40AM +0200, Maarten Lankhorst wrote:
  Op 22-08-13 02:10, Ilia Mirkin schreef:
   The code expects non-VRAM mem nodes to have a pages list. If that's not
   set, it will do a null deref down the line. Warn on that condition and
   return an error.
  
   See https://bugs.freedesktop.org/show_bug.cgi?id=64774
  
   Reported-by: Pasi Kärkkäinen pa...@iki.fi
   Tested-by: Pasi Kärkkäinen pa...@iki.fi
   Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
   Cc: sta...@vger.kernel.org # 3.8+
   ---
  
   I don't exactly understand what's going on, but this is just a
   straightforward way to avoid a null deref that you see happens in the
   bug. I haven't figured out the root cause of this, but it's getting
   well into the I have no idea how TTM works space. However this seems
   like a bit of defensive programming -- nouveau_vm_map_sg will pass
   node-pages as a list down, which will be dereferenced by
   nvc0_vm_map_sg. Perhaps the other arguments should make that
   dereferencing not happen, but it definitely was happening here, as you
   can see in the bug.
  
   Ben/Maarten, I'll let you judge whether this check is appropriate,
   since like I hope I was able to convey above, I'm just not really sure :)
  Not it really isn't appropriate..
  
  You'd have to call call nouveau_vm_map_sg_table instead, the only place 
  that doesn't handle that correctly
  is where it's not expected to be called.
  
  Here, have a completely untested patch to fix things...
  
 
 Maarten: I've been testing this stuff with Linux 3.10.x, so I had to modify 
 the patch a bit to make it apply there.. 
 I've attached the modified copy that applies to 3.10.9, hopefully I did the 
 backport correctly.
 
 With Linux 3.10.9 and the patch applied the kernel doesn't crash anymore, and 
 I get this error in dmesg:
 
 [   76.105643] nouveau W[ DRM] Trying to create a fb in vram with 
 valid_domains=0004
 
 Does that help? 


Any comments? 

Maarten's patch works for me, I get that warning instead of a kernel crash,
but it's also a bigger change that doesn't apply to older kernels as-is. 

Ilia's original patch in this thread can be applied to older kernels as-is,
and it also prevents the kernel crash from happening.

Should we get both applied, so Ilia's patch can be CC'd to stable ? 
 
-- Pasi


 --- 
 linux-3.10.9-100.fc18.x86_64/drivers/gpu/drm/nouveau/nouveau_display.c.orig   
 2013-07-01 01:13:29.0 +0300
 +++ linux-3.10.9-100.fc18.x86_64/drivers/gpu/drm/nouveau/nouveau_display.c
 2013-08-23 19:56:52.038234281 +0300
 @@ -137,18 +137,31 @@
  {
   struct nouveau_framebuffer *nouveau_fb;
   struct drm_gem_object *gem;
 + struct nouveau_bo *nvbo;
   int ret;
  
   gem = drm_gem_object_lookup(dev, file_priv, mode_cmd-handles[0]);
   if (!gem)
   return ERR_PTR(-ENOENT);
  
 + nvbo = nouveau_gem_object(gem);
 + if (!(nvbo-valid_domains  NOUVEAU_GEM_DOMAIN_VRAM)) {
 + nv_warn(nouveau_drm(dev), Trying to create a fb in vram with
 +  valid_domains=%08x\n, nvbo-valid_domains);
 + ret = -EINVAL;
 + drm_gem_object_unreference(gem);
 + return ERR_PTR(ret);
 + }
 +
   nouveau_fb = kzalloc(sizeof(struct nouveau_framebuffer), GFP_KERNEL);
 - if (!nouveau_fb)
 + if (!nouveau_fb) {
 + drm_gem_object_unreference(gem);
   return ERR_PTR(-ENOMEM);
 + }
  
 - ret = nouveau_framebuffer_init(dev, nouveau_fb, mode_cmd, 
 nouveau_gem_object(gem));
 + ret = nouveau_framebuffer_init(dev, nouveau_fb, mode_cmd, nvbo);
   if (ret) {
 + kfree(nouveau_fb);
   drm_gem_object_unreference(gem);
   return ERR_PTR(ret);
   }

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

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

trees for secondary powerdown

[Dave Airlie]

Hi Takashi,

I've put two branches in my repo,

http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-optimus-power-down
http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-optimus-power-down-snd-merge

git://people.freedesktop.org/~airlied/linux is the tree.

The second tree is just the vga switcheroo and sound patch, I've
changed one line from the
previous posted patch to reinstate the irq handler check for runtime
pm, but only for cards
with the runtime pm flag.

Can you see if this merges into your tree okay? if so we can both
merge that branch to
our trees and I'll build on top of it.

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

Re: [PATCH 6/6] drm/nouveau: use MSI interrupts

[Ben Skeggs]

On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach d...@lynxeye.de wrote:
 MSIs were only problematic on some old, broken chipsets. But now that we
 already see systems where PCI legacy interrupts are somewhat flaky, it's
 really time to move to MSIs.

 Signed-off-by: Lucas Stach d...@lynxeye.de
 ---
  drivers/gpu/drm/nouveau/core/include/subdev/mc.h |  1 +
  drivers/gpu/drm/nouveau/core/subdev/mc/base.c| 17 +
  2 files changed, 18 insertions(+)

 diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h 
 b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
 index 9d2cd20..ce6569f 100644
 --- a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
 +++ b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
 @@ -12,6 +12,7 @@ struct nouveau_mc_intr {
  struct nouveau_mc {
 struct nouveau_subdev base;
 const struct nouveau_mc_intr *intr_map;
 +   bool use_msi;
  };

  static inline struct nouveau_mc *
 diff --git a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c 
 b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
 index ec9cd6f..02b337e 100644
 --- a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
 +++ b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
 @@ -23,6 +23,7 @@
   */

  #include subdev/mc.h
 +#include core/option.h

  static irqreturn_t
  nouveau_mc_intr(int irq, void *arg)
 @@ -43,6 +44,9 @@ nouveau_mc_intr(int irq, void *arg)
 map++;
 }

 +   if (pmc-use_msi)
 +   nv_wr08(pmc-base.base.parent, 0x00088068, 0xff);
Register not present everywhere.

At the very least, the enabling of MSI should be disallowed on the
earlier chipsets where it's not supported.  Though, it's perhaps
possible that the pci_enable_msi() call will fail in all of these
cases anyway.. I'm not certain.

 +
 if (intr) {
 nv_error(pmc, unknown intr 0x%08x\n, stat);
 }
 @@ -75,6 +79,8 @@ _nouveau_mc_dtor(struct nouveau_object *object)
 struct nouveau_device *device = nv_device(object);
 struct nouveau_mc *pmc = (void *)object;
 free_irq(device-pdev-irq, pmc);
 +   if (pmc-use_msi)
 +   pci_disable_msi(device-pdev);
 nouveau_subdev_destroy(pmc-base);
  }

 @@ -96,6 +102,17 @@ nouveau_mc_create_(struct nouveau_object *parent, struct 
 nouveau_object *engine,

 pmc-intr_map = intr_map;

 +   pmc-use_msi = nouveau_boolopt(device-cfgopt, NvMSI, true);
 +   if (pmc-use_msi) {
 +   ret = pci_enable_msi(device-pdev);
 +   if (ret) {
 +   pmc-use_msi = false;
 +   } else {
 +   nv_wr08(device, 0x00088068, 0xff);
 +   nv_info(pmc, MSI interrupts enabled\n);
 +   }
 +   }
 +
 ret = request_irq(device-pdev-irq, nouveau_mc_intr,
   IRQF_SHARED, nouveau, pmc);
 if (ret  0)
 --
 1.8.3.1

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

Re: [PATCH 4/6] drm/nouveau: introduce NOUVEAU_GEM_TILE_WCUS

[Ben Skeggs]

On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach d...@lynxeye.de wrote:
 This flag allows userspace to give the kernel a hint that it should use
 a non-snooped resource. To guarantee coherency at all times mappings
 into userspace are done write combined, so userspace should avoid
 reading back from those resources.
Do any other combinations of cached/uncached and snooped/non-snooped
make any sense?  If so, perhaps we want to split the flags.


 Signed-off-by: Lucas Stach d...@lynxeye.de
 ---
 On x86 an optimized userspace can save up on snoop traffic in the
 system, on ARM the benefits are potentially much larger, as we can save
 the manual cache flush/invalidate.
 ---
  drivers/gpu/drm/nouveau/nouveau_bo.c | 11 ++-
  drivers/gpu/drm/nouveau/nouveau_bo.h |  1 +
  include/uapi/drm/nouveau_drm.h   |  1 +
  3 files changed, 12 insertions(+), 1 deletion(-)

 diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
 b/drivers/gpu/drm/nouveau/nouveau_bo.c
 index f4a2eb9..c5fcbcc 100644
 --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
 +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
 @@ -231,6 +231,12 @@ nouveau_bo_new(struct drm_device *dev, int size, int 
 align,

 nouveau_bo_fixup_align(nvbo, flags, align, size);
 nvbo-bo.mem.num_pages = size  PAGE_SHIFT;
 +
 +   if (tile_flags  NOUVEAU_GEM_TILE_WCUS)
 +   nvbo-valid_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
 +   else
 +   nvbo-valid_caching = TTM_PL_MASK_CACHING;
 +
 nouveau_bo_placement_set(nvbo, flags, 0);

 acc_size = ttm_bo_dma_acc_size(drm-ttm.bdev, size,
 @@ -292,7 +298,7 @@ void
  nouveau_bo_placement_set(struct nouveau_bo *nvbo, uint32_t type, uint32_t 
 busy)
  {
 struct ttm_placement *pl = nvbo-placement;
 -   uint32_t flags = TTM_PL_MASK_CACHING |
 +   uint32_t flags = nvbo-valid_caching |
 (nvbo-pin_refcnt ? TTM_PL_FLAG_NO_EVICT : 0);

 pl-placement = nvbo-placements;
 @@ -1554,6 +1560,9 @@ nouveau_bo_vma_add(struct nouveau_bo *nvbo, struct 
 nouveau_vm *vm,
 if (nvbo-bo.mem.mem_type == TTM_PL_VRAM)
 nouveau_vm_map(vma, nvbo-bo.mem.mm_node);
 else if (nvbo-bo.mem.mem_type == TTM_PL_TT) {
 +   if (!(nvbo-valid_caching  TTM_PL_FLAG_CACHED))
 +   vma-access |= NV_MEM_ACCESS_NOSNOOP;
 +
 if (node-sg)
 nouveau_vm_map_sg_table(vma, 0, size, node);
 else
 diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.h 
 b/drivers/gpu/drm/nouveau/nouveau_bo.h
 index 653dbbb..2ecf8b7 100644
 --- a/drivers/gpu/drm/nouveau/nouveau_bo.h
 +++ b/drivers/gpu/drm/nouveau/nouveau_bo.h
 @@ -9,6 +9,7 @@ struct nouveau_bo {
 struct ttm_buffer_object bo;
 struct ttm_placement placement;
 u32 valid_domains;
 +   u32 valid_caching;
 u32 placements[3];
 u32 busy_placements[3];
 struct ttm_bo_kmap_obj kmap;
 diff --git a/include/uapi/drm/nouveau_drm.h b/include/uapi/drm/nouveau_drm.h
 index 2a5769f..4948eee2 100644
 --- a/include/uapi/drm/nouveau_drm.h
 +++ b/include/uapi/drm/nouveau_drm.h
 @@ -36,6 +36,7 @@
  #define NOUVEAU_GEM_TILE_32BPP   0x0002
  #define NOUVEAU_GEM_TILE_ZETA0x0004
  #define NOUVEAU_GEM_TILE_NONCONTIG   0x0008
 +#define NOUVEAU_GEM_TILE_WCUS0x0010 /* write-combined, unsnooped 
 */

  struct drm_nouveau_gem_info {
 uint32_t handle;
 --
 1.8.3.1

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

Re: [PATCH 0/9] drm/nouveau: Cleanup event/handler design

[Ben Skeggs]

On Wed, Aug 28, 2013 at 6:12 AM, Peter Hurley pe...@hurleysoftware.com wrote:
 This series was originally motivated by a deadlock, introduced in
 commit 1d7c71a3e2f77336df536855b0efd2dc5bdeb41b
 'drm/nouveau/disp: port vblank handling to event interface',
 due to inverted lock order between nouveau_drm_vblank_enable()
 and nouveau_drm_vblank_handler() (the complete
 lockdep report is included in the patch 4/5 changelog).
Hey Peter,

Thanks for the patch series.  I've only taken a cursory glance through
the patches thus far, as they're definitely too intrusive for -fixes
at this point.  I will take a proper look through the series within
the next week or so, I have some work pending which may possibly make
some of these changes unnecessary, though from what I can tell,
there's other good bits here we'll want.

In a previous mail on the locking issue, you mentioned the drm core
doing the wrong thing here too, did you have any further thoughts on
correcting that issue too?

Ben.


 Because this series fixes the vblank event deadlock, it is
 a competing solution to Maarten Lankhorst's 'drm/nouveau:
 fix vblank deadlock'.

 This series fixes the vblank event deadlock by converting the
 event handler list to RCU. This solution allows the event trigger
 to be lockless, and thus avoiding the lock inversion.

 Typical hurdles to RCU conversion include: 1) ensuring the
 object lifetime exceeds the lockless access; 2) preventing
 premature object reuse; and 3) verifying that stale object
 use not present logical errors.

 Because object reuse is not safe in RCU-based operations,
 the nouveau_event_get/_put interface is migrated from
 add/remove semantics to enable/disable semantics with a separate
 install/remove step (which also serves to document the
 handler lifetime). This also corrects an unsafe interface design
 where handlers can mistakenly be reused while in use.

 The nouveau driver currently supports 4 events -- gpio, uevent, cevent,
 and vblank. Every event is created by and stored within its
 respective subdev/engine object -- gpio in the GPIO subdev, uevent
 and cevent in the FIFO engine, and vblank in the DISP engine.
 Thus event lifetime extends until the subdev is destructed during
 devobj teardown.

 Event handler lifetime varies and is detailed in the table below
 (apologies for the wide-format):

 Event  Handler function   Container Until
 -     ---   
 --
 gpio   nouveau_connector_hotplug  struct nouveau_connector  
 nouveau_connector_destroy
 uevent nouveau_fence_wait_uevent_handler  local stack object
 nouveau_fence_wait_uevent returns
 cevent none   n/a   n/a
 vblank nouveau_drm_vblank_handler struct nouveau_drm
 nouveau_drm_remove
 vblank nv50_software_vblsem_release   struct nouveau_software_chan  
 _nouveau_engctx_dtor
   
 (call stack originates with

 nouveau_abi16_chan_free ioctl)
 vblank nvc0_software_vblsem_release   struct nouveau_software_chan  same 
 as above


 RCU lifetime considerations for handlers:

 Event  HandlerLifetime
 -     -
 gpio   nouveau_connector_hotplug  kfree_rcu(nv_connector)
 uevent nouveau_fence_wait_uevent_handler  explicit use of 
 nouveau_event_hander_create/_destroy
 cevent none   n/a
 vblank nouveau_drm_vblank_handler synchronize_rcu() in 
 nouveau_drm_unload
 vblank nv50_software_vblsem_release   synchronize_rcu() in container dtor
 vblank nvc0_software_vblsem_release   synchronize_rcu() in container dtor

 synchronize_rcu() is used for nouveau_object-based containers for which
 kfree_rcu() is not suitable/possible.

 Stale event handler execution is not a concern for the existing handlers
 because either: 1) the handler is responsible for disabling itself (via
 returning NVKM_EVENT_DROP), or 2) the existing handler can already be stale,
 as is the case with nouveau_connector_hotplug, which only schedules a work
 item, and nouveau_drm_vblank_handler, which the drm core expects may be stale.


 Peter Hurley (9):
   drm/nouveau: Add priv field for event handlers
   drm/nouveau: Move event index check from critical section
   drm/nouveau: Allocate local event handlers
   drm/nouveau: Allow asymmetric nouveau_event_get/_put
   drm/nouveau: Add install/remove semantics for event handlers
   drm/nouveau: Convert event handler list to RCU
   drm/nouveau: Fold nouveau_event_put_locked into caller
   drm/nouveau: Simplify event interface
   drm/nouveau: Simplify event handler interface

  drivers/gpu/drm/nouveau/core/core/event.c  | 121 
 

Re: [PATCH 6/6] drm/nouveau: use MSI interrupts

[Lucas Stach]

Am Mittwoch, den 28.08.2013, 17:09 +1000 schrieb Ben Skeggs:
 On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach d...@lynxeye.de wrote:
  MSIs were only problematic on some old, broken chipsets. But now that we
  already see systems where PCI legacy interrupts are somewhat flaky, it's
  really time to move to MSIs.
 
  Signed-off-by: Lucas Stach d...@lynxeye.de
  ---
   drivers/gpu/drm/nouveau/core/include/subdev/mc.h |  1 +
   drivers/gpu/drm/nouveau/core/subdev/mc/base.c| 17 +
   2 files changed, 18 insertions(+)
 
  diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h 
  b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
  index 9d2cd20..ce6569f 100644
  --- a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
  +++ b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
  @@ -12,6 +12,7 @@ struct nouveau_mc_intr {
   struct nouveau_mc {
  struct nouveau_subdev base;
  const struct nouveau_mc_intr *intr_map;
  +   bool use_msi;
   };
 
   static inline struct nouveau_mc *
  diff --git a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c 
  b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
  index ec9cd6f..02b337e 100644
  --- a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
  +++ b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
  @@ -23,6 +23,7 @@
*/
 
   #include subdev/mc.h
  +#include core/option.h
 
   static irqreturn_t
   nouveau_mc_intr(int irq, void *arg)
  @@ -43,6 +44,9 @@ nouveau_mc_intr(int irq, void *arg)
  map++;
  }
 
  +   if (pmc-use_msi)
  +   nv_wr08(pmc-base.base.parent, 0x00088068, 0xff);
 Register not present everywhere.
 
 At the very least, the enabling of MSI should be disallowed on the
 earlier chipsets where it's not supported.  Though, it's perhaps
 possible that the pci_enable_msi() call will fail in all of these
 cases anyway.. I'm not certain.
 
MSIs are required property for everything doing PCIe. So the only cases
where this should fail is plain PCI/AGP devices. I don't really have a
test system for those old cards set up.

But I remember Ilia having some legacy things plugged in, so maybe he
could test this patch and see how it goes?

  +
  if (intr) {
  nv_error(pmc, unknown intr 0x%08x\n, stat);
  }
  @@ -75,6 +79,8 @@ _nouveau_mc_dtor(struct nouveau_object *object)
  struct nouveau_device *device = nv_device(object);
  struct nouveau_mc *pmc = (void *)object;
  free_irq(device-pdev-irq, pmc);
  +   if (pmc-use_msi)
  +   pci_disable_msi(device-pdev);
  nouveau_subdev_destroy(pmc-base);
   }
 
  @@ -96,6 +102,17 @@ nouveau_mc_create_(struct nouveau_object *parent, 
  struct nouveau_object *engine,
 
  pmc-intr_map = intr_map;
 
  +   pmc-use_msi = nouveau_boolopt(device-cfgopt, NvMSI, true);
  +   if (pmc-use_msi) {
  +   ret = pci_enable_msi(device-pdev);
  +   if (ret) {
  +   pmc-use_msi = false;
  +   } else {
  +   nv_wr08(device, 0x00088068, 0xff);
  +   nv_info(pmc, MSI interrupts enabled\n);
  +   }
  +   }
  +
  ret = request_irq(device-pdev-irq, nouveau_mc_intr,
IRQF_SHARED, nouveau, pmc);
  if (ret  0)
  --
  1.8.3.1
 


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

Re: [PATCH 4/6] drm/nouveau: introduce NOUVEAU_GEM_TILE_WCUS

[Lucas Stach]

Am Mittwoch, den 28.08.2013, 17:11 +1000 schrieb Ben Skeggs:
 On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach d...@lynxeye.de wrote:
  This flag allows userspace to give the kernel a hint that it should use
  a non-snooped resource. To guarantee coherency at all times mappings
  into userspace are done write combined, so userspace should avoid
  reading back from those resources.
 Do any other combinations of cached/uncached and snooped/non-snooped
 make any sense?  If so, perhaps we want to split the flags.
 
Thought about that and I came to the conclusion that it isn't worth the
hassle. If we split it then things get more complicated on x86, were we
would have to invalidate caches manually with all the related
performance implications.

So I think it's a lot easier for userspace writers to just set the WCUS
flag on resources where the can promise no to touch the resource for
reading (AFAIR Christoph wanted this flag mostly for resources that the
driver isn't going to touch ever), or where it can happily live with
uncached reading.

 
  Signed-off-by: Lucas Stach d...@lynxeye.de
  ---
  On x86 an optimized userspace can save up on snoop traffic in the
  system, on ARM the benefits are potentially much larger, as we can save
  the manual cache flush/invalidate.
  ---
   drivers/gpu/drm/nouveau/nouveau_bo.c | 11 ++-
   drivers/gpu/drm/nouveau/nouveau_bo.h |  1 +
   include/uapi/drm/nouveau_drm.h   |  1 +
   3 files changed, 12 insertions(+), 1 deletion(-)
 
  diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
  b/drivers/gpu/drm/nouveau/nouveau_bo.c
  index f4a2eb9..c5fcbcc 100644
  --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
  +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
  @@ -231,6 +231,12 @@ nouveau_bo_new(struct drm_device *dev, int size, int 
  align,
 
  nouveau_bo_fixup_align(nvbo, flags, align, size);
  nvbo-bo.mem.num_pages = size  PAGE_SHIFT;
  +
  +   if (tile_flags  NOUVEAU_GEM_TILE_WCUS)
  +   nvbo-valid_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
  +   else
  +   nvbo-valid_caching = TTM_PL_MASK_CACHING;
  +
  nouveau_bo_placement_set(nvbo, flags, 0);
 
  acc_size = ttm_bo_dma_acc_size(drm-ttm.bdev, size,
  @@ -292,7 +298,7 @@ void
   nouveau_bo_placement_set(struct nouveau_bo *nvbo, uint32_t type, uint32_t 
  busy)
   {
  struct ttm_placement *pl = nvbo-placement;
  -   uint32_t flags = TTM_PL_MASK_CACHING |
  +   uint32_t flags = nvbo-valid_caching |
  (nvbo-pin_refcnt ? TTM_PL_FLAG_NO_EVICT : 0);
 
  pl-placement = nvbo-placements;
  @@ -1554,6 +1560,9 @@ nouveau_bo_vma_add(struct nouveau_bo *nvbo, struct 
  nouveau_vm *vm,
  if (nvbo-bo.mem.mem_type == TTM_PL_VRAM)
  nouveau_vm_map(vma, nvbo-bo.mem.mm_node);
  else if (nvbo-bo.mem.mem_type == TTM_PL_TT) {
  +   if (!(nvbo-valid_caching  TTM_PL_FLAG_CACHED))
  +   vma-access |= NV_MEM_ACCESS_NOSNOOP;
  +
  if (node-sg)
  nouveau_vm_map_sg_table(vma, 0, size, node);
  else
  diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.h 
  b/drivers/gpu/drm/nouveau/nouveau_bo.h
  index 653dbbb..2ecf8b7 100644
  --- a/drivers/gpu/drm/nouveau/nouveau_bo.h
  +++ b/drivers/gpu/drm/nouveau/nouveau_bo.h
  @@ -9,6 +9,7 @@ struct nouveau_bo {
  struct ttm_buffer_object bo;
  struct ttm_placement placement;
  u32 valid_domains;
  +   u32 valid_caching;
  u32 placements[3];
  u32 busy_placements[3];
  struct ttm_bo_kmap_obj kmap;
  diff --git a/include/uapi/drm/nouveau_drm.h b/include/uapi/drm/nouveau_drm.h
  index 2a5769f..4948eee2 100644
  --- a/include/uapi/drm/nouveau_drm.h
  +++ b/include/uapi/drm/nouveau_drm.h
  @@ -36,6 +36,7 @@
   #define NOUVEAU_GEM_TILE_32BPP   0x0002
   #define NOUVEAU_GEM_TILE_ZETA0x0004
   #define NOUVEAU_GEM_TILE_NONCONTIG   0x0008
  +#define NOUVEAU_GEM_TILE_WCUS0x0010 /* write-combined, 
  unsnooped */
 
   struct drm_nouveau_gem_info {
  uint32_t handle;
  --
  1.8.3.1
 


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

Re: [PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap

[Maarten Lankhorst]

Op 28-08-13 08:29, Pasi Kärkkäinen schreef:
 On Fri, Aug 23, 2013 at 11:20:42PM +0300, Pasi Kärkkäinen wrote:
 On Thu, Aug 22, 2013 at 09:12:40AM +0200, Maarten Lankhorst wrote:
 Op 22-08-13 02:10, Ilia Mirkin schreef:
 The code expects non-VRAM mem nodes to have a pages list. If that's not
 set, it will do a null deref down the line. Warn on that condition and
 return an error.

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

 Reported-by: Pasi Kärkkäinen pa...@iki.fi
 Tested-by: Pasi Kärkkäinen pa...@iki.fi
 Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
 Cc: sta...@vger.kernel.org # 3.8+
 ---

 I don't exactly understand what's going on, but this is just a
 straightforward way to avoid a null deref that you see happens in the
 bug. I haven't figured out the root cause of this, but it's getting
 well into the I have no idea how TTM works space. However this seems
 like a bit of defensive programming -- nouveau_vm_map_sg will pass
 node-pages as a list down, which will be dereferenced by
 nvc0_vm_map_sg. Perhaps the other arguments should make that
 dereferencing not happen, but it definitely was happening here, as you
 can see in the bug.

 Ben/Maarten, I'll let you judge whether this check is appropriate,
 since like I hope I was able to convey above, I'm just not really sure :)
 Not it really isn't appropriate..

 You'd have to call call nouveau_vm_map_sg_table instead, the only place 
 that doesn't handle that correctly
 is where it's not expected to be called.

 Here, have a completely untested patch to fix things...

 Maarten: I've been testing this stuff with Linux 3.10.x, so I had to modify 
 the patch a bit to make it apply there.. 
 I've attached the modified copy that applies to 3.10.9, hopefully I did the 
 backport correctly.

 With Linux 3.10.9 and the patch applied the kernel doesn't crash anymore, 
 and I get this error in dmesg:

 [   76.105643] nouveau W[ DRM] Trying to create a fb in vram with 
 valid_domains=0004

 Does that help? 

 Any comments? 

 Maarten's patch works for me, I get that warning instead of a kernel crash,
 but it's also a bigger change that doesn't apply to older kernels as-is. 

 Ilia's original patch in this thread can be applied to older kernels as-is,
 and it also prevents the kernel crash from happening.

 Should we get both applied, so Ilia's patch can be CC'd to stable ? 

You haven't understood the root cause then. You're trying to move an IMPORTED 
dma-buf into VRAM.
Doing so would seem to work, but at that point it's no longer a dma-buf so 
changes done by the exporter
would not show up in nouveau because they no longer refer to the same piece of 
memory.

Failing is the only right option here.

~Maarten

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

[Bug 64810] EGL/Gles/Weston give segfault on RADEONSI with egl_gallium.so

[bugzilla-daemon]

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

--- Comment #12 from Michel Dänzer mic...@daenzer.net ---
(In reply to comment #11)
 fix multiple symbols bug

Thanks for the patch, but I think it's more invasive than necessary. We'd like
to retain the possibility of sharing code between radeonsi and r600g in the
future.

Can you try if Johannes' patch from comment 8 fixes the problem?

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

Re: [PATCH 0/6] Nouveau on ARM fixes

[Thierry Reding]

On Wed, Aug 28, 2013 at 02:00:44AM +0200, Lucas Stach wrote:
 This is the first set of patches to make Nouveau work
 on Tegra.

Perhaps you should clarify that this patch series allows discrete GPUs
to be used via Tegra's PCIe interface.

People might misinterpret...

Thierry


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

Re: [PATCH 0/6] Nouveau on ARM fixes

[Ben Skeggs]

On Wed, Aug 28, 2013 at 5:50 PM, Thierry Reding
thierry.red...@gmail.com wrote:
 On Wed, Aug 28, 2013 at 02:00:44AM +0200, Lucas Stach wrote:
 This is the first set of patches to make Nouveau work
 on Tegra.

 Perhaps you should clarify that this patch series allows discrete GPUs
 to be used via Tegra's PCIe interface.

 People might misinterpret...
Hah!  Too late, quality journalism already hard at work ;)

Ben.

 Thierry

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

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

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

[Inki Dae]

Rahul, ping~~~


2013/8/1 Rahul Sharma r.sh.o...@gmail.com

 Thanks Sylwester,

 On Wed, Jul 31, 2013 at 5:41 PM, Sylwester Nawrocki
 s.nawro...@samsung.com wrote:
  Hi Rahul,
 
  On 07/31/2013 01:23 PM, Rahul Sharma wrote:
  I think your hdmiphy pmu patch is good enough just if dt binding for
 pmu
   is in hdmiphy binding instead of hdmi binding. So I recommended to
 make
   pmu patch set on the top of independent hdmiphy patch set because
 with
   independent hdmiphy patch set hdmiphy pmu code is moved to hdmiphy
 driver.
  
   Is it possible that hdmi driver references pmu information from
 hdmiphy
   binding? If that, it seems one possible solution to fix current
 exynos
   hdmi broken.
  
   Thanks and Regards,
   - Seung-Woo Kim
  
  
   I can surely do that but, I am worried about hdmiphy control bus.
   change In 5420. It is changed to platform bus from i2c. Isolating
   hdmiphy from hdmi driver seems the only clean method to handle
   control bus change, changed phy configurations and power control
   through PMU bit.
  
   To fix broken hdmi for 5420, I can again post the hdmiphy
   separation patches to place hdmiphy driver in DRM. Later we can
   migrate to Generic Phy Framework.
  
 
  Hi Seung Woo, Mr. Dae, Sylwester,
 
  What you say on this? Shall I separate hdmiphy in following manner:
 
  1) Move all phy related code to hdmiphy driver i.e. exynos_hdmiphy.c
  2) hdmiphy driver exposes power_on/off and set_pixel callbacks for
  hdmi driver.
  3) let hdmi driver behave as phy controller for hdmiphy.
  4) move PMU bit control to hdmiphy driver, instead of hdmi driver.
 
  This way we will be very close to generic phy framework implementation
  and migration to generic phy framework will be just a cakewalk.
 
  This all sound good to me, it seem natural to put the HDMI PHY
  functionality into a separate module. Hardware-wise the PHY is quite
  separate and as experience shows different PHYs can be attached to
  same controller. Well, we have well known that before...
 
  I'm not sure what the problem is with adding subsystem specific
  classes of operations (set of callback) to the generic PHY API, until
  that gets sorted out your approach looks good to me.
 
  As a side note, originally the V4L2 driver exposed the HDMI PHY
  as struct v4l2_subdev object, have a look at drivers/media/platform/
  s5p-tv/hdmiphy_drv.c. And in case of exynos5 we would just have
  created a platform driver for the HDMI PHY which would expose same
  subdev interface. So something similar as you proposed above.
 

 Yea, it is very similar to s5p-tv/hdmiphy_drv.c. On top of this, I want
 to make hdmiphy platform device as Clock provider for hdmiphy clock,
 as you have done for cam_clkout*. Hdmi driver will call set_rate on this
 clock.

 I will post patches for the above separation and move hdmiphy to Generic
 Phy framework after we get clarity on how to add additional callbacks.

 Thanks for your reply.

 Regards,
 Rahul Sharma

 
  Regards,
  Sylwester
 
 --
 To unsubscribe from this list: send the line unsubscribe
 linux-samsung-soc in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[PATCH] drm/prime: Remove PRIME handles only if supported

[Thierry Reding]

Drivers that don't support PRIME will not have initialized the PRIME
specific private component of struct drm_file. If called for such
drivers, the drm_gem_remove_prime_handles() function will crash. Fix
it by checking for PRIME support prior to removing the PRIME handles.

Signed-off-by: Thierry Reding tred...@nvidia.com
---
 drivers/gpu/drm/drm_gem.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 1ce88c3..4a23f34 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -296,7 +296,8 @@ drm_gem_handle_delete(struct drm_file *filp, u32 handle)
idr_remove(filp-object_idr, handle);
spin_unlock(filp-table_lock);
 
-   drm_gem_remove_prime_handles(obj, filp);
+   if (drm_core_check_feature(dev, DRIVER_PRIME))
+   drm_gem_remove_prime_handles(obj, filp);
 
if (dev-driver-gem_close_object)
dev-driver-gem_close_object(obj, filp);
@@ -699,7 +700,8 @@ drm_gem_object_release_handle(int id, void *ptr, void *data)
struct drm_gem_object *obj = ptr;
struct drm_device *dev = obj-dev;
 
-   drm_gem_remove_prime_handles(obj, file_priv);
+   if (drm_core_check_feature(dev, DRIVER_PRIME))
+   drm_gem_remove_prime_handles(obj, file_priv);
 
if (dev-driver-gem_close_object)
dev-driver-gem_close_object(obj, file_priv);
-- 
1.8.4

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

Re: [PATCH 2/5] host1x: hdmi: Detect whether display is connected with HDMI or DVI

[Thierry Reding]

On Wed, Aug 28, 2013 at 01:40:56PM +0300, Mikko Perttunen wrote:
 Use EDID data to determine whether the display supports HDMI or just DVI.
 This used to be hardcoded to be HDMI, which broke support for DVI displays
 that couldn't understand the interspersed audio/other data.
 
 If the EDID data isn't available, default to DVI, which should be a safer
 choice.
 
 Signed-off-by: Mikko Perttunen mperttu...@nvidia.com
 ---
  drivers/gpu/host1x/drm/hdmi.c | 8 
  1 file changed, 8 insertions(+)
 
 diff --git a/drivers/gpu/host1x/drm/hdmi.c b/drivers/gpu/host1x/drm/hdmi.c
 index d81fac8..140339b 100644
 --- a/drivers/gpu/host1x/drm/hdmi.c
 +++ b/drivers/gpu/host1x/drm/hdmi.c
 @@ -702,6 +702,14 @@ static int tegra_output_hdmi_enable(struct tegra_output 
 *output)
   unsigned long value;
   int retries = 1000;
   int err;
 + struct drm_property_blob *edid_blob = output-connector.edid_blob_ptr;
 +
 + if (edid_blob  edid_blob-data 
 + drm_detect_hdmi_monitor((struct edid *)edid_blob-data)) {
 + hdmi-dvi = false;
 + } else {
 + hdmi-dvi = true;
 + }
  
   pclk = mode-clock * 1000;
   h_sync_width = mode-hsync_end - mode-hsync_start;

Odd, now that I see that code I remember that there was a similar patch
a few months back, but it was never applied for some reason:

http://lists.freedesktop.org/archives/dri-devel/2013-January/033509.html

That was already reviewed by me and Jon Mayo, so I'll go ahead and apply
that one instead.

Thierry


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

Re: [PATCH 4/5] ARM: tegra: Add host1x, dc and hdmi to Tegra114 device tree

[Thierry Reding]

On Wed, Aug 28, 2013 at 01:40:58PM +0300, Mikko Perttunen wrote:
 Add host1x, dc (display controller) and hdmi devices to Tegra114
 device tree.

DC and HDMI.

 
 Signed-off-by: Mikko Perttunen mperttu...@nvidia.com
 ---
  arch/arm/boot/dts/tegra114.dtsi | 43 
 +
  1 file changed, 43 insertions(+)
 
 diff --git a/arch/arm/boot/dts/tegra114.dtsi b/arch/arm/boot/dts/tegra114.dtsi
 index 2905145..ce5a95c 100644
 --- a/arch/arm/boot/dts/tegra114.dtsi
 +++ b/arch/arm/boot/dts/tegra114.dtsi
 @@ -27,6 +27,49 @@
   (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH);
   };
  
 + host1x {
 + compatible = nvidia,tegra114-host1x, nvidia,tegra30-host1x,

I don't think that's correct. The Tegra114 host1x is not backwards
compatible with the Tegra30 host1x.

That said, I have a local patch that is a bit more complete in that it
adds other host1x devices as listed in the TRM as well. But I'll leave
it up to Stephen how he prefers to handle that. It should be fine to
defer adding nodes for additional hardware blocks when the supporting
drivers are merged. We've done it for other devices as well.

 + simple-bus;
 + reg = 0x5000 0x00028000;
 + interrupts = GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH,
 + GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH;

I think this should be indented with the previous line. Also other SoC
.dtsi files use a single entry, as in:

interrupts = GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH
  GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH;

 + hdmi {
 + compatible = nvidia,tegra114-hdmi;
 + reg = 0x5428 0x0004;
 + interrupts = GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH;
 + clocks = tegra_car TEGRA114_CLK_HDMI,
 + tegra_car TEGRA114_CLK_PLL_D_OUT0;

Any reason why we can't use pll_d2_out0 here, like we do on Tegra30?

Thierry


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

Re: [PATCH 5/5] ARM: tegra: Add hdmi to Tegra114 Dalmore device tree

[Thierry Reding]

On Wed, Aug 28, 2013 at 01:40:59PM +0300, Mikko Perttunen wrote:
 Add hdmi node to Dalmore device tree to supply Dalmore-specific

s/hdmi/HDMI/

 diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts 
 b/arch/arm/boot/dts/tegra114-dalmore.dts
[...]
 + host1x {
 + hdmi {
 + status = okay;
 +
 + vdd-supply = vdd_hdmi_reg;
 + pll-supply = palmas_smps3_reg;
 + nvidia,ddc-i2c-bus = hdmi_ddc;

I prefer to use a blank line to separate standard from
vendor-specific properties.

 + nvidia,hpd-gpio = gpio TEGRA_GPIO(N, 7) 
 GPIO_ACTIVE_HIGH;

Other .dts files split this so it doesn't exceed 80 characters. I'm not
sure how useful that is as a general rule for DT source files, though.

   i2c@7000d000 {
   status = okay;
   clock-frequency = 40;
 @@ -1169,6 +1184,8 @@
   regulator-min-microvolt = 500;
   regulator-max-microvolt = 500;
   enable-active-high;
 + regulator-always-on;
 + regulator-boot-on;

This warrants at least a mention in the commit message.

Thierry


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

[Bug 60791] Display corruption with Radeon driver during boot and on desktop

[bugzilla-daemon]

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

--- Comment #13 from Alex Deucher alexdeuc...@gmail.com ---
Can you revert parts of the patch to find out which element is causing the
problem.  E.g., try:

   /* reset data block */
//   ctx-data_block = 0;

and see if that helps, then:

   /* reset divmul */
//   ctx-divmul[0] = 0;
   ctx-divmul[1] = 0;

etc.

Additionally, can you dump the display registers in the working and non-working
states using radeonreg (http://cgit.freedesktop.org/~airlied/radeontool/)?

(as root)

boot with broken kernel:
./radeonreg regs dce3  broken.regs

boot with working kernel:
./radeonreg regs dce3  working.regs

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

Re: [PATCH 2/5] host1x: hdmi: Detect whether display is connected with HDMI or DVI

[Thierry Reding]

On Wed, Aug 28, 2013 at 03:34:53PM +0300, Mikko Perttunen wrote:
 On 08/28/2013 03:07 PM, Thierry Reding wrote:
 * PGP Signed by an unknown key
 
 On Wed, Aug 28, 2013 at 01:40:56PM +0300, Mikko Perttunen wrote:
 Use EDID data to determine whether the display supports HDMI or just DVI.
 This used to be hardcoded to be HDMI, which broke support for DVI displays
 that couldn't understand the interspersed audio/other data.
 
 If the EDID data isn't available, default to DVI, which should be a safer
 choice.
 
 Signed-off-by: Mikko Perttunen mperttu...@nvidia.com
 ---
   drivers/gpu/host1x/drm/hdmi.c | 8 
   1 file changed, 8 insertions(+)
 
 diff --git a/drivers/gpu/host1x/drm/hdmi.c b/drivers/gpu/host1x/drm/hdmi.c
 index d81fac8..140339b 100644
 --- a/drivers/gpu/host1x/drm/hdmi.c
 +++ b/drivers/gpu/host1x/drm/hdmi.c
 @@ -702,6 +702,14 @@ static int tegra_output_hdmi_enable(struct 
 tegra_output *output)
 unsigned long value;
 int retries = 1000;
 int err;
 +   struct drm_property_blob *edid_blob = output-connector.edid_blob_ptr;
 +
 +   if (edid_blob  edid_blob-data 
 +   drm_detect_hdmi_monitor((struct edid *)edid_blob-data)) {
 +   hdmi-dvi = false;
 +   } else {
 +   hdmi-dvi = true;
 +   }
 
 pclk = mode-clock * 1000;
 h_sync_width = mode-hsync_end - mode-hsync_start;
 
 Odd, now that I see that code I remember that there was a similar patch
 a few months back, but it was never applied for some reason:
 
  http://lists.freedesktop.org/archives/dri-devel/2013-January/033509.html
 
 That was already reviewed by me and Jon Mayo, so I'll go ahead and apply
 that one instead.
 
 Thierry
 
 * Unknown Key
 * 0x7F3EB3A1
 
 
 That patch seems to cause a warning for me:
 drivers/gpu/host1x/drm/hdmi.c: In function ‘tegra_output_hdmi_enable’:
 drivers/gpu/host1x/drm/hdmi.c:706:2: warning: passing argument 1 of
 ‘drm_detect_hdmi_monitor’ discards ‘const’ qualifier from pointer
 target type [enabled by default]
 include/drm/drm_crtc.h:1037:13: note: expected ‘struct edid *’ but
 argument is of type ‘const struct edid *’

Given the discussion about this back in January, I think the best way,
at least for now, is to keep a copy of the EDID data so that it can
actually be modified.

But looking at the problem more closely, I don't think the patch from
January is quite correct. The problem is that it uses the EDID stored
within the struct tegra_output. That's problematic because that field
is not updated when EDID is probed via DDC. That would make the patch
that you proposed more correct.

Thierry


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

Re: [PATCH 4/5] ARM: tegra: Add host1x, dc and hdmi to Tegra114 device tree

[Thierry Reding]

On Wed, Aug 28, 2013 at 03:41:35PM +0300, Mikko Perttunen wrote:
 On 08/28/2013 03:25 PM, Thierry Reding wrote:
[...]
 Signed-off-by: Mikko Perttunen mperttu...@nvidia.com
 ---
   arch/arm/boot/dts/tegra114.dtsi | 43 
  +
   1 file changed, 43 insertions(+)
 
 diff --git a/arch/arm/boot/dts/tegra114.dtsi 
 b/arch/arm/boot/dts/tegra114.dtsi
 index 2905145..ce5a95c 100644
 --- a/arch/arm/boot/dts/tegra114.dtsi
 +++ b/arch/arm/boot/dts/tegra114.dtsi
 @@ -27,6 +27,49 @@
 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH);
 };
 
 +   host1x {
 +   compatible = nvidia,tegra114-host1x, nvidia,tegra30-host1x,
 
 I don't think that's correct. The Tegra114 host1x is not backwards
 compatible with the Tegra30 host1x.
 
 That said, I have a local patch that is a bit more complete in that it
 adds other host1x devices as listed in the TRM as well. But I'll leave
 it up to Stephen how he prefers to handle that. It should be fine to
 defer adding nodes for additional hardware blocks when the supporting
 drivers are merged. We've done it for other devices as well.
 
 Ok. Will need to add tegra114-host1x to the host1x driver compat
 strings, then, but I guess that's better than having it wrong in the
 DT.

I think that's not all. I have local patches that also introduce a v2 of
host1x, because the number of syncpoints is different. There may also be
other differences, but Terje might be more qualified to answer that.

 +   hdmi {
 +   compatible = nvidia,tegra114-hdmi;
 +   reg = 0x5428 0x0004;
 +   interrupts = GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH;
 +   clocks = tegra_car TEGRA114_CLK_HDMI,
 +   tegra_car TEGRA114_CLK_PLL_D_OUT0;
 
 Any reason why we can't use pll_d2_out0 here, like we do on Tegra30?
 
 I have this set to PLL_D because I don't have panel support so disp1
 will be the HDMI DC. However, it doesn't seem to matter which one is
 specified here. I have also tested HDMI with disp2 and that works
 too.

Well eventually we'll add panel support and I think it'd be good to stay
consistent as to what clocks are used for the internal and external
displays.

Thierry


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

Re: [PATCH 5/5] ARM: tegra: Add hdmi to Tegra114 Dalmore device tree

[Thierry Reding]

On Wed, Aug 28, 2013 at 03:49:45PM +0300, Mikko Perttunen wrote:
 On 08/28/2013 03:30 PM, Thierry Reding wrote:
 On Wed, Aug 28, 2013 at 01:40:59PM +0300, Mikko Perttunen wrote:
[...]
 regulator-min-microvolt = 500;
 regulator-max-microvolt = 500;
 enable-active-high;
 +   regulator-always-on;
 +   regulator-boot-on;
 
 This warrants at least a mention in the commit message.
 
 Hmm, yeah. Looks like the HDMI driver only enables the Vdd in
 tegra_output_hdmi_enable, which is too late at least for DDC. I
 guess a better patch would be to enable it earlier. In _probe?

I don't think that would be much better. That way the supply will still
always be on, independent of whether we're actually using HDMI or not.
I'm thinking that perhaps we need to allow HDMI to override get_modes()
by something custom. That should also help with the EDID problem in the
earlier patch.

Thierry


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

[Bug 68451] Texture flicker in native Dota2 in mesa 9.2.0rc1

[bugzilla-daemon]

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

--- Comment #13 from Peter Kraus peter.kr...@geeksonbikes.net ---
Found it:


7948ed1250cae78ae1b22dbce4ab23aceacc6159 is the first bad commit
commit 7948ed1250cae78ae1b22dbce4ab23aceacc6159
Author: Marek Olšák mar...@gmail.com
Date:   Sun Jun 30 19:57:59 2013 +0200

r600g: only flush the caches that need to be flushed during CP DMA
operations

This should increase performance if constant uploads are done with the CP
DMA,
because only the cache that needs to be flushed is flushed.

Reviewed-by: Alex Deucher alexander.deuc...@amd.com

:04 04 69219cf4b797f08ed91c367342386a00f87b1c45
ae2f808ee6d4c10bc631f7327664da6d349b0a83 Msrc

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

Re: [PATCH 6/6] drm/nouveau: use MSI interrupts

[Ilia Mirkin]

On Wed, Aug 28, 2013 at 3:28 AM, Lucas Stach d...@lynxeye.de wrote:
 Am Mittwoch, den 28.08.2013, 17:09 +1000 schrieb Ben Skeggs:
 On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach d...@lynxeye.de wrote:
  MSIs were only problematic on some old, broken chipsets. But now that we
  already see systems where PCI legacy interrupts are somewhat flaky, it's
  really time to move to MSIs.
 
  Signed-off-by: Lucas Stach d...@lynxeye.de
  ---
   drivers/gpu/drm/nouveau/core/include/subdev/mc.h |  1 +
   drivers/gpu/drm/nouveau/core/subdev/mc/base.c| 17 +
   2 files changed, 18 insertions(+)
 
  diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h 
  b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
  index 9d2cd20..ce6569f 100644
  --- a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
  +++ b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
  @@ -12,6 +12,7 @@ struct nouveau_mc_intr {
   struct nouveau_mc {
  struct nouveau_subdev base;
  const struct nouveau_mc_intr *intr_map;
  +   bool use_msi;
   };
 
   static inline struct nouveau_mc *
  diff --git a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c 
  b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
  index ec9cd6f..02b337e 100644
  --- a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
  +++ b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
  @@ -23,6 +23,7 @@
*/
 
   #include subdev/mc.h
  +#include core/option.h
 
   static irqreturn_t
   nouveau_mc_intr(int irq, void *arg)
  @@ -43,6 +44,9 @@ nouveau_mc_intr(int irq, void *arg)
  map++;
  }
 
  +   if (pmc-use_msi)
  +   nv_wr08(pmc-base.base.parent, 0x00088068, 0xff);
 Register not present everywhere.

 At the very least, the enabling of MSI should be disallowed on the
 earlier chipsets where it's not supported.  Though, it's perhaps
 possible that the pci_enable_msi() call will fail in all of these
 cases anyway.. I'm not certain.

 MSIs are required property for everything doing PCIe. So the only cases
 where this should fail is plain PCI/AGP devices. I don't really have a
 test system for those old cards set up.

 But I remember Ilia having some legacy things plugged in, so maybe he
 could test this patch and see how it goes?

Sure, let me know what you need -- I have nv18 PCI, nv34 PCIe (note
that it's not native PCIe, but some sort of bridge thing IIRC), nv42
PCIe, nv44 PCIe, nv96 PCIe.

Can I just apply this patch, or do I need to do the whole series? What
constitutes a success?

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

[PATCH Resend 1/6] drm/exynos: Make Exynos DRM drivers depend on OF

[Sachin Kamat]

Exynos is a DT-only platform. Add this info to Kconfig.

Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
Rebased this series on the latest Inki Dae's tree.
---
 drivers/gpu/drm/exynos/Kconfig |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 772c62a..80a251a 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -1,6 +1,6 @@
 config DRM_EXYNOS
tristate DRM Support for Samsung SoC EXYNOS Series
-   depends on DRM  (PLAT_SAMSUNG || ARCH_MULTIPLATFORM)
+   depends on OF  DRM  (PLAT_SAMSUNG || ARCH_MULTIPLATFORM)
select DRM_KMS_HELPER
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
@@ -24,7 +24,7 @@ config DRM_EXYNOS_DMABUF
 
 config DRM_EXYNOS_FIMD
bool Exynos DRM FIMD
-   depends on OF  DRM_EXYNOS  !FB_S3C  !ARCH_MULTIPLATFORM
+   depends on DRM_EXYNOS  !FB_S3C  !ARCH_MULTIPLATFORM
select FB_MODE_HELPERS
select VIDEOMODE_HELPERS
help
-- 
1.7.9.5

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

[PATCH Resend 2/6] drm/exynos: Remove non-DT support in exynos_ddc

[Sachin Kamat]

Since commit 383ffda2fa (ARM: EXYNOS: no more support non-DT
for EXYNOS SoCs), Exynos platform is DT only. Hence remove
all the conditional macros and make the driver DT only.

Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
 drivers/gpu/drm/exynos/exynos_ddc.c |   11 +--
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_ddc.c 
b/drivers/gpu/drm/exynos/exynos_ddc.c
index d1e539b..6a8c84e 100644
--- a/drivers/gpu/drm/exynos/exynos_ddc.c
+++ b/drivers/gpu/drm/exynos/exynos_ddc.c
@@ -41,13 +41,6 @@ static int s5p_ddc_remove(struct i2c_client *client)
return 0;
 }
 
-static struct i2c_device_id ddc_idtable[] = {
-   {s5p_ddc, 0},
-   {exynos5-hdmiddc, 0},
-   { },
-};
-
-#ifdef CONFIG_OF
 static struct of_device_id hdmiddc_match_types[] = {
{
.compatible = samsung,exynos5-hdmiddc,
@@ -57,15 +50,13 @@ static struct of_device_id hdmiddc_match_types[] = {
/* end node */
}
 };
-#endif
 
 struct i2c_driver ddc_driver = {
.driver = {
.name = exynos-hdmiddc,
.owner = THIS_MODULE,
-   .of_match_table = of_match_ptr(hdmiddc_match_types),
+   .of_match_table = hdmiddc_match_types,
},
-   .id_table   = ddc_idtable,
.probe  = s5p_ddc_probe,
.remove = s5p_ddc_remove,
.command= NULL,
-- 
1.7.9.5

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

[PATCH Resend 4/6] drm/exynos: Remove non-DT support in exynos_drm_g2d

[Sachin Kamat]

Since commit 383ffda2fa (ARM: EXYNOS: no more support non-DT
for EXYNOS SoCs), Exynos platform is DT only. Hence remove
all the conditional macros and make the driver DT only.

Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
 drivers/gpu/drm/exynos/exynos_drm_g2d.c |4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c 
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index 0b8b6e4..3271fd4 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -1534,12 +1534,10 @@ static const struct dev_pm_ops g2d_pm_ops = {
SET_RUNTIME_PM_OPS(g2d_runtime_suspend, g2d_runtime_resume, NULL)
 };
 
-#ifdef CONFIG_OF
 static const struct of_device_id exynos_g2d_match[] = {
{ .compatible = samsung,exynos5250-g2d },
{},
 };
-#endif
 
 struct platform_driver g2d_driver = {
.probe  = g2d_probe,
@@ -1548,6 +1546,6 @@ struct platform_driver g2d_driver = {
.name   = s5p-g2d,
.owner  = THIS_MODULE,
.pm = g2d_pm_ops,
-   .of_match_table = of_match_ptr(exynos_g2d_match),
+   .of_match_table = exynos_g2d_match,
},
 };
-- 
1.7.9.5

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

[PATCH Resend 3/6] drm/exynos: Remove non-DT support in exynos_hdmiphy

[Sachin Kamat]

Since commit 383ffda2fa (ARM: EXYNOS: no more support non-DT
for EXYNOS SoCs), Exynos platform is DT only. Hence remove
all the conditional macros and make the driver DT only.

Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
 drivers/gpu/drm/exynos/exynos_hdmiphy.c |   11 +--
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmiphy.c 
b/drivers/gpu/drm/exynos/exynos_hdmiphy.c
index 6021996..59abb14 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmiphy.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmiphy.c
@@ -40,13 +40,6 @@ static int hdmiphy_remove(struct i2c_client *client)
return 0;
 }
 
-static const struct i2c_device_id hdmiphy_id[] = {
-   { s5p_hdmiphy, 0 },
-   { exynos5-hdmiphy, 0 },
-   { },
-};
-
-#ifdef CONFIG_OF
 static struct of_device_id hdmiphy_match_types[] = {
{
.compatible = samsung,exynos5-hdmiphy,
@@ -58,15 +51,13 @@ static struct of_device_id hdmiphy_match_types[] = {
/* end node */
}
 };
-#endif
 
 struct i2c_driver hdmiphy_driver = {
.driver = {
.name   = exynos-hdmiphy,
.owner  = THIS_MODULE,
-   .of_match_table = of_match_ptr(hdmiphy_match_types),
+   .of_match_table = hdmiphy_match_types,
},
-   .id_table = hdmiphy_id,
.probe  = hdmiphy_probe,
.remove = hdmiphy_remove,
.command= NULL,
-- 
1.7.9.5

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

[PATCH Resend 5/6] drm/exynos: Remove non-DT support in exynos_hdmi

[Sachin Kamat]

Since commit 383ffda2fa (ARM: EXYNOS: no more support non-DT
for EXYNOS SoCs), Exynos platform is DT only. Hence remove
all the conditional macros and make the driver DT only.

Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
 drivers/gpu/drm/exynos/exynos_hdmi.c |   70 ++
 1 file changed, 12 insertions(+), 58 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 8ea07a1..a0e10ae 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1858,7 +1858,6 @@ void hdmi_attach_hdmiphy_client(struct i2c_client 
*hdmiphy)
hdmi_hdmiphy = hdmiphy;
 }
 
-#ifdef CONFIG_OF
 static struct s5p_hdmi_platform_data *drm_hdmi_dt_parse_pdata
(struct device *dev)
 {
@@ -1882,33 +1881,7 @@ static struct s5p_hdmi_platform_data 
*drm_hdmi_dt_parse_pdata
 err_data:
return NULL;
 }
-#else
-static struct s5p_hdmi_platform_data *drm_hdmi_dt_parse_pdata
-   (struct device *dev)
-{
-   return NULL;
-}
-#endif
-
-static struct platform_device_id hdmi_driver_types[] = {
-   {
-   .name   = s5pv210-hdmi,
-   .driver_data= HDMI_TYPE13,
-   }, {
-   .name   = exynos4-hdmi,
-   .driver_data= HDMI_TYPE13,
-   }, {
-   .name   = exynos4-hdmi14,
-   .driver_data= HDMI_TYPE14,
-   }, {
-   .name   = exynos5-hdmi,
-   .driver_data= HDMI_TYPE14,
-   }, {
-   /* end node */
-   }
-};
 
-#ifdef CONFIG_OF
 static struct of_device_id hdmi_match_types[] = {
{
.compatible = samsung,exynos5-hdmi,
@@ -1920,7 +1893,6 @@ static struct of_device_id hdmi_match_types[] = {
/* end node */
}
 };
-#endif
 
 static int hdmi_probe(struct platform_device *pdev)
 {
@@ -1929,30 +1901,21 @@ static int hdmi_probe(struct platform_device *pdev)
struct hdmi_context *hdata;
struct s5p_hdmi_platform_data *pdata;
struct resource *res;
+   const struct of_device_id *match;
int ret;
 
-   if (dev-of_node) {
-   pdata = drm_hdmi_dt_parse_pdata(dev);
-   if (IS_ERR(pdata)) {
-   DRM_ERROR(failed to parse dt\n);
-   return PTR_ERR(pdata);
-   }
-   } else {
-   pdata = dev-platform_data;
-   }
+if (!dev-of_node)
+   return -ENODEV;
 
-   if (!pdata) {
-   DRM_ERROR(no platform data specified\n);
+   pdata = drm_hdmi_dt_parse_pdata(dev);
+   if (!pdata)
return -EINVAL;
-   }
 
-   drm_hdmi_ctx = devm_kzalloc(dev, sizeof(*drm_hdmi_ctx),
-   GFP_KERNEL);
+   drm_hdmi_ctx = devm_kzalloc(dev, sizeof(*drm_hdmi_ctx), GFP_KERNEL);
if (!drm_hdmi_ctx)
return -ENOMEM;
 
-   hdata = devm_kzalloc(dev, sizeof(struct hdmi_context),
-   GFP_KERNEL);
+   hdata = devm_kzalloc(dev, sizeof(struct hdmi_context), GFP_KERNEL);
if (!hdata)
return -ENOMEM;
 
@@ -1963,23 +1926,15 @@ static int hdmi_probe(struct platform_device *pdev)
 
platform_set_drvdata(pdev, drm_hdmi_ctx);
 
-   if (dev-of_node) {
-   const struct of_device_id *match;
-   match = of_match_node(of_match_ptr(hdmi_match_types),
-   dev-of_node);
-   if (match == NULL)
-   return -ENODEV;
-   hdata-type = (enum hdmi_type)match-data;
-   } else {
-   hdata-type = (enum hdmi_type)platform_get_device_id
-   (pdev)-driver_data;
-   }
+   match = of_match_node(hdmi_match_types, dev-of_node);
+   if (!match)
+   return -ENODEV;
+   hdata-type = (enum hdmi_type)match-data;
 
hdata-hpd_gpio = pdata-hpd_gpio;
hdata-dev = dev;
 
ret = hdmi_resources_init(hdata);
-
if (ret) {
DRM_ERROR(hdmi_resources_init failed\n);
return -EINVAL;
@@ -2134,11 +2089,10 @@ static const struct dev_pm_ops hdmi_pm_ops = {
 struct platform_driver hdmi_driver = {
.probe  = hdmi_probe,
.remove = hdmi_remove,
-   .id_table = hdmi_driver_types,
.driver = {
.name   = exynos-hdmi,
.owner  = THIS_MODULE,
.pm = hdmi_pm_ops,
-   .of_match_table = of_match_ptr(hdmi_match_types),
+   .of_match_table = hdmi_match_types,
},
 };
-- 
1.7.9.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org