[PATCH 2/2] drm/exynos: use drm generic mmap interface

[Inki Dae]

This patch removes DRM_EXYNOS_GEM_MMAP ictrl feature specific
to Exynos drm and instead uses drm generic mmap.

We had used the interface specific to Exynos drm to do mmap directly,
not to use demand paging which maps each page with physical memory
at page fault handler. We don't need the specific mmap interface
because the drm generic mmap which uses vm offset manager stuff can
also do mmap directly.

This patch makes a userspace region to be mapped with whole physical
memory region allocated by userspace request when mmap system call is
requested.

Signed-off-by: Inki Dae 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c |   25 -
 drivers/gpu/drm/exynos/exynos_drm_drv.h |1 -
 drivers/gpu/drm/exynos/exynos_drm_gem.c |   84 ++-
 drivers/gpu/drm/exynos/exynos_drm_gem.h |   10 
 include/uapi/drm/exynos_drm.h   |   22 
 5 files changed, 14 insertions(+), 128 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 10ad3d4..a7819eb 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -149,10 +149,6 @@ static int exynos_drm_unload(struct drm_device *dev)
return 0;
 }

-static const struct file_operations exynos_drm_gem_fops = {
-   .mmap = exynos_drm_gem_mmap_buffer,
-};
-
 static int exynos_drm_suspend(struct drm_device *dev, pm_message_t state)
 {
struct drm_connector *connector;
@@ -191,7 +187,6 @@ static int exynos_drm_resume(struct drm_device *dev)
 static int exynos_drm_open(struct drm_device *dev, struct drm_file *file)
 {
struct drm_exynos_file_private *file_priv;
-   struct file *anon_filp;
int ret;

file_priv = kzalloc(sizeof(*file_priv), GFP_KERNEL);
@@ -204,21 +199,8 @@ static int exynos_drm_open(struct drm_device *dev, struct 
drm_file *file)
if (ret)
goto err_file_priv_free;

-   anon_filp = anon_inode_getfile("exynos_gem", _drm_gem_fops,
-   NULL, 0);
-   if (IS_ERR(anon_filp)) {
-   ret = PTR_ERR(anon_filp);
-   goto err_subdrv_close;
-   }
-
-   anon_filp->f_mode = FMODE_READ | FMODE_WRITE;
-   file_priv->anon_filp = anon_filp;
-
return ret;

-err_subdrv_close:
-   exynos_drm_subdrv_close(dev, file);
-
 err_file_priv_free:
kfree(file_priv);
file->driver_priv = NULL;
@@ -234,7 +216,6 @@ static void exynos_drm_preclose(struct drm_device *dev,
 static void exynos_drm_postclose(struct drm_device *dev, struct drm_file *file)
 {
struct exynos_drm_private *private = dev->dev_private;
-   struct drm_exynos_file_private *file_priv;
struct drm_pending_vblank_event *v, *vt;
struct drm_pending_event *e, *et;
unsigned long flags;
@@ -260,10 +241,6 @@ static void exynos_drm_postclose(struct drm_device *dev, 
struct drm_file *file)
}
spin_unlock_irqrestore(>event_lock, flags);

-   file_priv = file->driver_priv;
-   if (file_priv->anon_filp)
-   fput(file_priv->anon_filp);
-
kfree(file->driver_priv);
file->driver_priv = NULL;
 }
@@ -282,8 +259,6 @@ static const struct vm_operations_struct 
exynos_drm_gem_vm_ops = {
 static const struct drm_ioctl_desc exynos_ioctls[] = {
DRM_IOCTL_DEF_DRV(EXYNOS_GEM_CREATE, exynos_drm_gem_create_ioctl,
DRM_UNLOCKED | DRM_AUTH),
-   DRM_IOCTL_DEF_DRV(EXYNOS_GEM_MMAP,
-   exynos_drm_gem_mmap_ioctl, DRM_UNLOCKED | DRM_AUTH),
DRM_IOCTL_DEF_DRV(EXYNOS_GEM_GET,
exynos_drm_gem_get_ioctl, DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(EXYNOS_VIDI_CONNECTION,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 69a6fa3..d22e640 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -240,7 +240,6 @@ struct exynos_drm_g2d_private {
 struct drm_exynos_file_private {
struct exynos_drm_g2d_private   *g2d_priv;
struct device   *ipp_dev;
-   struct file *anon_filp;
 };

 /*
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 2f3665d..3cf6494 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -318,21 +318,17 @@ void exynos_drm_gem_put_dma_addr(struct drm_device *dev,
drm_gem_object_unreference_unlocked(obj);
 }

-int exynos_drm_gem_mmap_buffer(struct file *filp,
+int exynos_drm_gem_mmap_buffer(struct exynos_drm_gem_obj *exynos_gem_obj,
  struct vm_area_struct *vma)
 {
-   struct drm_gem_object *obj = filp->private_data;
-   struct exynos_drm_gem_obj *exynos_gem_obj = to_exynos_gem_obj(obj);
-   struct drm_device *drm_dev = obj->dev;
+   struct drm_device *drm_dev = 

[PATCH 1/2] drm/exynos: remove DRM_EXYNOS_GEM_MAP_OFFSET ioctl

[Inki Dae]

This interface and relevant codes aren't used anymore.

Signed-off-by: Inki Dae 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c |3 ---
 drivers/gpu/drm/exynos/exynos_drm_gem.c |   17 -
 drivers/gpu/drm/exynos/exynos_drm_gem.h |4 
 include/uapi/drm/exynos_drm.h   |   18 --
 4 files changed, 42 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 9b00e4e..10ad3d4 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -282,9 +282,6 @@ static const struct vm_operations_struct 
exynos_drm_gem_vm_ops = {
 static const struct drm_ioctl_desc exynos_ioctls[] = {
DRM_IOCTL_DEF_DRV(EXYNOS_GEM_CREATE, exynos_drm_gem_create_ioctl,
DRM_UNLOCKED | DRM_AUTH),
-   DRM_IOCTL_DEF_DRV(EXYNOS_GEM_MAP_OFFSET,
-   exynos_drm_gem_map_offset_ioctl, DRM_UNLOCKED |
-   DRM_AUTH),
DRM_IOCTL_DEF_DRV(EXYNOS_GEM_MMAP,
exynos_drm_gem_mmap_ioctl, DRM_UNLOCKED | DRM_AUTH),
DRM_IOCTL_DEF_DRV(EXYNOS_GEM_GET,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 15db801..2f3665d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -318,23 +318,6 @@ void exynos_drm_gem_put_dma_addr(struct drm_device *dev,
drm_gem_object_unreference_unlocked(obj);
 }

-int exynos_drm_gem_map_offset_ioctl(struct drm_device *dev, void *data,
-   struct drm_file *file_priv)
-{
-   struct drm_exynos_gem_map_off *args = data;
-
-   DRM_DEBUG_KMS("handle = 0x%x, offset = 0x%lx\n",
-   args->handle, (unsigned long)args->offset);
-
-   if (!(dev->driver->driver_features & DRIVER_GEM)) {
-   DRM_ERROR("does not support GEM.\n");
-   return -ENODEV;
-   }
-
-   return exynos_drm_gem_dumb_map_offset(file_priv, dev, args->handle,
-   >offset);
-}
-
 int exynos_drm_gem_mmap_buffer(struct file *filp,
  struct vm_area_struct *vma)
 {
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.h 
b/drivers/gpu/drm/exynos/exynos_drm_gem.h
index 1592c0b..8e46094 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.h
@@ -111,10 +111,6 @@ void exynos_drm_gem_put_dma_addr(struct drm_device *dev,
unsigned int gem_handle,
struct drm_file *filp);

-/* get buffer offset to map to user space. */
-int exynos_drm_gem_map_offset_ioctl(struct drm_device *dev, void *data,
-   struct drm_file *file_priv);
-
 /*
  * mmap the physically continuous memory that a gem object contains
  * to user space.
diff --git a/include/uapi/drm/exynos_drm.h b/include/uapi/drm/exynos_drm.h
index d584412..67a751c 100644
--- a/include/uapi/drm/exynos_drm.h
+++ b/include/uapi/drm/exynos_drm.h
@@ -33,20 +33,6 @@ struct drm_exynos_gem_create {
 };

 /**
- * A structure for getting buffer offset.
- *
- * @handle: a pointer to gem object created.
- * @pad: just padding to be 64-bit aligned.
- * @offset: relatived offset value of the memory region allocated.
- * - this value should be set by user.
- */
-struct drm_exynos_gem_map_off {
-   unsigned int handle;
-   unsigned int pad;
-   uint64_t offset;
-};
-
-/**
  * A structure for mapping buffer.
  *
  * @handle: a handle to gem object created.
@@ -316,7 +302,6 @@ struct drm_exynos_ipp_cmd_ctrl {
 };

 #define DRM_EXYNOS_GEM_CREATE  0x00
-#define DRM_EXYNOS_GEM_MAP_OFFSET  0x01
 #define DRM_EXYNOS_GEM_MMAP0x02
 /* Reserved 0x03 ~ 0x05 for exynos specific gem ioctl */
 #define DRM_EXYNOS_GEM_GET 0x04
@@ -336,9 +321,6 @@ struct drm_exynos_ipp_cmd_ctrl {
 #define DRM_IOCTL_EXYNOS_GEM_CREATEDRM_IOWR(DRM_COMMAND_BASE + \
DRM_EXYNOS_GEM_CREATE, struct drm_exynos_gem_create)

-#define DRM_IOCTL_EXYNOS_GEM_MAP_OFFSETDRM_IOWR(DRM_COMMAND_BASE + \
-   DRM_EXYNOS_GEM_MAP_OFFSET, struct drm_exynos_gem_map_off)
-
 #define DRM_IOCTL_EXYNOS_GEM_MMAP  DRM_IOWR(DRM_COMMAND_BASE + \
DRM_EXYNOS_GEM_MMAP, struct drm_exynos_gem_mmap)

-- 
1.7.9.5

[PATCH 0/2] drm/exynos: use drm generic mmap interface

[Inki Dae]

This patch set removes unnecessary DRM_EXYNOS_GEM_MAP_OFFSET interface
which isn't used anymore and also uses drm generic mmap interface
instead of a mmap interface specific to Exynos drm. So this patch set
removes a existing mmap interface and relevant codes specific to Exynos
drm.

Inki Dae (2):
  drm/exynos: remove DRM_EXYNOS_GEM_MAP_OFFSET ioctl
  drm/exynos: use drm generic mmap interface

 drivers/gpu/drm/exynos/exynos_drm_drv.c |   28 -
 drivers/gpu/drm/exynos/exynos_drm_drv.h |1 -
 drivers/gpu/drm/exynos/exynos_drm_gem.c |  101 +--
 drivers/gpu/drm/exynos/exynos_drm_gem.h |   14 -
 include/uapi/drm/exynos_drm.h   |   40 
 5 files changed, 14 insertions(+), 170 deletions(-)

-- 
1.7.9.5

Using a HD 4670 still possible?

[Christoph Brill]

Hi Alex, hi Michael,

I filed bug https://bugs.freedesktop.org/show_bug.cgi?id=84017 with all
requested infos attached. If you need anything else or if I should test
patches just let me know.

Best wishes,
 Christoph

2014-09-17 14:55 GMT+02:00 Alex Deucher :

> On Wed, Sep 17, 2014 at 3:30 AM, Michel D?nzer  wrote:
> > On 14.09.2014 03:13, Christoph Brill wrote:
> >>
> >> Am 08.09.2014 03:41 schrieb "Michel D?nzer"  >> <mailto:michel at daenzer.net>>:
> >>
> >>  > On 07.09.2014 01:01, Christoph Brill wrote:
> >>  >>
> >>  >>
> >>  >> I'm currently trying to get a HD 4670 aka RV730 XT to work against
> >> X.org
> >>  >> 1.16, xf86-video-ati 7.4.0 on a Linux 3.16.1.
> >>  >>
> >>  >> Can anyone tell me: Should this card be able to handle an average
> >> Gnome
> >>  >> desktop?
> >>  >
> >>  >
> >>  > Of course.
> >>  >
> >>  >
> >>  >
> >>  >> The problem was: 3D rendering did not work at all.
> >>  >>
> >>  >> Starting gdm lead to hanging Xorg. Calling glxgears on a twm session
> >>  >> just rendered a black window, which stayed even if the process was
> >>  >> killed by CTRL+C. I managed to get glxgears do do its job by setting
> >>  >> "vblank_mode=0".
> >>  >>
> >>  >> I guessed my card does not like to play along with vsync at all. So
> I
> >>  >> went ahead to disable vsyncing (tearing is still better than no
> >> display
> >>  >> at all). Setting it globally in /etc/drirc seems to get glxgears
> >> running.
> >>  >>
> >>  >> Testing Xonotic on twm showed, that the card was now able to handle
> >> 3D.
> >>  >> But: gdm still was extremely sluggish and eventually froze. Starting
> >>  >> gnome-shell directly from startx gets me to the desktop, but any
> >> action
> >>  >> freezes the process.
> >>  >>
> >>  >> Is there still hope for this card or should I get rid of it?
> >>  >
> >>  >
> >>  > It sounds like there's a problem with interrupt processing on your
> >> system. Please provide the dmesg output. You might try
> >> disabling/enabling MSI to see if that works around the problem.
> >>
> >> Thank you so much for this hint! Booting using radeon.msi=0 finally
> >> brings the system into a usable state. The dmesg of a default boot (i.e.
> >> radeon.msi=-1) is available at http://pastebin.com/gS1xHYPc
> >
> >
> > Can you file a bug report at
> > https://bugs.freedesktop.org/enter_bug.cgi?product=DRI component
> > "DRM/Radeon" and attach the dmesg output there?
> >
>
> Also mention what chipset your system uses and whether the card is AGP or
> not.
>
> Alex
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140917/0993c00f/attachment-0001.html>

[PATCH v3 1/3] phy: exynos-dp-video: Use syscon support to control pmu register

[Kishon Vijay Abraham I]

On Tuesday 16 September 2014 10:32 AM, Vivek Gautam wrote:
> Currently the DP_PHY_ENABLE register is mapped in the driver,
> and accessed to control power to the PHY.
> With mfd-syscon and regmap interface available at our disposal,
> it's wise to use that instead of using a 'reg' property for the
> controller and allocating a memory resource for that.
> 
> To facilitate this, we have added another compatible string
> for Exynso5420 SoC to acquire driver data which contains
> different DP-PHY-CONTROL register offset.
> 
> Signed-off-by: Vivek Gautam 
> Cc: Jingoo Han 
> Cc: Kishon Vijay Abraham I 

Taking this in linux-phy tree. If someone has already taken this patch, please
let me know.

Thanks
Kishon

> ---
> 
> Changes since v2:
>  - Using 'EXYNOS5_PHY_ENABLE' macro instead of 'EXYNOS_DPTX_PHY_ENABLE'
>since that's available with us in "linux/mfd/syscon/exynos5-pmu.h" file.
> 
> Changes since v1:
>  - state->regs should have been "struct regmap *" instead of
>"void __iomem *". So corrected the same.
> 
>  .../devicetree/bindings/phy/samsung-phy.txt|7 +-
>  drivers/phy/phy-exynos-dp-video.c  |   79 
> +---
>  2 files changed, 59 insertions(+), 27 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt 
> b/Documentation/devicetree/bindings/phy/samsung-phy.txt
> index 7a6feea..15e0f2c 100644
> --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
> +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
> @@ -17,8 +17,11 @@ Samsung EXYNOS SoC series Display Port PHY
>  -
>  
>  Required properties:
> -- compatible : should be "samsung,exynos5250-dp-video-phy";
> -- reg : offset and length of the Display Port PHY register set;
> +- compatible : should be one of the following supported values:
> +  - "samsung,exynos5250-dp-video-phy"
> +  - "samsung,exynos5420-dp-video-phy"
> +- samsung,pmu-syscon: phandle for PMU system controller interface, used to
> +   control pmu registers for power isolation.
>  - #phy-cells : from the generic PHY bindings, must be 0;
>  
>  Samsung S5P/EXYNOS SoC series USB PHY
> diff --git a/drivers/phy/phy-exynos-dp-video.c 
> b/drivers/phy/phy-exynos-dp-video.c
> index 8b3026e..53f44a0 100644
> --- a/drivers/phy/phy-exynos-dp-video.c
> +++ b/drivers/phy/phy-exynos-dp-video.c
> @@ -13,44 +13,55 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
>  
> -/* DPTX_PHY_CONTROL register */
> -#define EXYNOS_DPTX_PHY_ENABLE   (1 << 0)
> +struct exynos_dp_video_phy_drvdata {
> + u32 phy_ctrl_offset;
> +};
>  
>  struct exynos_dp_video_phy {
> - void __iomem *regs;
> + struct regmap *regs;
> + const struct exynos_dp_video_phy_drvdata *drvdata;
>  };
>  
> -static int __set_phy_state(struct exynos_dp_video_phy *state, unsigned int 
> on)
> +static void exynos_dp_video_phy_pwr_isol(struct exynos_dp_video_phy *state,
> + unsigned int on)
>  {
> - u32 reg;
> + unsigned int val;
> +
> + if (IS_ERR(state->regs))
> + return;
>  
> - reg = readl(state->regs);
> - if (on)
> - reg |= EXYNOS_DPTX_PHY_ENABLE;
> - else
> - reg &= ~EXYNOS_DPTX_PHY_ENABLE;
> - writel(reg, state->regs);
> + val = on ? 0 : EXYNOS5_PHY_ENABLE;
>  
> - return 0;
> + regmap_update_bits(state->regs, state->drvdata->phy_ctrl_offset,
> +EXYNOS5_PHY_ENABLE, val);
>  }
>  
>  static int exynos_dp_video_phy_power_on(struct phy *phy)
>  {
>   struct exynos_dp_video_phy *state = phy_get_drvdata(phy);
>  
> - return __set_phy_state(state, 1);
> + /* Disable power isolation on DP-PHY */
> + exynos_dp_video_phy_pwr_isol(state, 0);
> +
> + return 0;
>  }
>  
>  static int exynos_dp_video_phy_power_off(struct phy *phy)
>  {
>   struct exynos_dp_video_phy *state = phy_get_drvdata(phy);
>  
> - return __set_phy_state(state, 0);
> + /* Enable power isolation on DP-PHY */
> + exynos_dp_video_phy_pwr_isol(state, 1);
> +
> + return 0;
>  }
>  
>  static struct phy_ops exynos_dp_video_phy_ops = {
> @@ -59,11 +70,31 @@ static struct phy_ops exynos_dp_video_phy_ops = {
>   .owner  = THIS_MODULE,
>  };
>  
> +static const struct exynos_dp_video_phy_drvdata exynos5250_dp_video_phy = {
> + .phy_ctrl_offset= EXYNOS5_DPTX_PHY_CONTROL,
> +};
> +
> +static const struct exynos_dp_video_phy_drvdata exynos5420_dp_video_phy = {
> + .phy_ctrl_offset= EXYNOS5420_DPTX_PHY_CONTROL,
> +};
> +
> +static const struct of_device_id exynos_dp_video_phy_of_match[] = {
> + {
> + .compatible = "samsung,exynos5250-dp-video-phy",
> + .data = _dp_video_phy,
> + }, {
> + .compatible = "samsung,exynos5420-dp-video-phy",
> + 

[Bug 84021] New: [game][the cave] not rendered properly

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

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

  Priority: medium
Bug ID: 84021
  Assignee: dri-devel at lists.freedesktop.org
   Summary: [game][the cave] not rendered properly
  Severity: major
Classification: Unclassified
OS: Linux (All)
  Reporter: sylvain.bertrand at gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Drivers/Gallium/radeonsi
   Product: Mesa

The intro screen is mainly white and we hardly can see anything

-- 
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/20140917/014e3539/attachment.html>

[Bug 83998] Oopses on R9270X using UVD since radeon/uvd: use PIPE_USAGE_STAGING for msg buffers

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

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

--- Comment #3 from Aaron B  ---
If you use Chrom(e/ium)/Firefox, can you make sure hardware accel is enabled
and see if it crashes randomly using them? I wanna see if you have other same
symptoms I have with random crashing on my system.

-- 
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/20140917/c6626326/attachment.html>

[PATCH 0/9] drm/exynos: initialization/deinitialization fixes

[Inki Dae]

On 2014? 09? 09? 22:16, Andrzej Hajda wrote:
> This set of patches contains fixes of initialization and deinitialization
> code of exynos_drm core and components.
> It is based on exynos-drm-next branch.
> 
> Patchset has been tested on trats and universal_c210 platforms.

Applied all patches except patch #5. As of now, it seems good to merge
also patch #5 if you couldn't post next version of that patch until the
end of this week. In this case, I will have a pull request including
that patch so that we can fix it up correctly later. Give me your
opinion if there is other plan.

Thanks,
Inki Dae

> 
> Regards
> Andrzej
> 
> 
> Andrzej Hajda (9):
>   drm/exynos/ipp: traverse ipp drivers list safely
>   drm/exynos: fix drm driver de-initialization order
>   drm/exynos/fbdev: fix fbdev gem object cleanup
>   drm/exynos/fb: free exynos framebuffer on error
>   drm/exynos/crtc: fix framebuffer reference sequence
>   drm/exynos/dsi: unregister connector on removal
>   drm/exynos/dpi: unregister connector and panel on removal
>   drm/exynos/dp: unregister connector on removal
>   drm/exynos/hdmi: unregister connector on removal
> 
>  drivers/gpu/drm/exynos/exynos_dp_core.c   | 4 +++-
>  drivers/gpu/drm/exynos/exynos_drm_crtc.c  | 6 ++
>  drivers/gpu/drm/exynos/exynos_drm_dpi.c   | 6 +-
>  drivers/gpu/drm/exynos/exynos_drm_drv.c   | 8 
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c   | 9 ++---
>  drivers/gpu/drm/exynos/exynos_drm_fb.c| 1 +
>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 3 ---
>  drivers/gpu/drm/exynos/exynos_drm_ipp.c   | 4 ++--
>  drivers/gpu/drm/exynos/exynos_hdmi.c  | 4 +++-
>  9 files changed, 30 insertions(+), 15 deletions(-)
> 

[Bug 80618] [r600g] XCOM Ennemy Unknown crash (RV770)

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

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

--- Comment #4 from Jan K?mmel  ---
you didn't forget the -ldl when compiling, did you?

-- 
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/20140917/984da3f2/attachment.html>

[Bug 84017] HD 4670 only works with MSI disabled

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

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

--- Comment #3 from Alex Deucher  ---
What chipset does your motherboard use?  Can you also attach the output of
/proc/interrupts from your system?

-- 
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/20140917/08b163ad/attachment.html>

[Bug 84017] HD 4670 only works with MSI disabled

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

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

--- Comment #2 from Christoph Brill  ---
Additional note: The card is PCI-E running on a B-TX board with a Core2
(non-Duo) CPU.

-- 
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/20140917/25aa505e/attachment.html>

[Bug 84017] HD 4670 only works with MSI disabled

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

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

--- Comment #1 from Christoph Brill  ---
Created attachment 106460
  --> https://bugs.freedesktop.org/attachment.cgi?id=106460=edit
lspci -v

-- 
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/20140917/6fe38a79/attachment.html>

[Bug 84017] New: HD 4670 only works with MSI disabled

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

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

  Priority: medium
Bug ID: 84017
  Assignee: dri-devel at lists.freedesktop.org
   Summary: HD 4670 only works with MSI disabled
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: egore at gmx.de
  Hardware: Other
Status: NEW
   Version: DRI CVS
 Component: DRM/Radeon
   Product: DRI

Created attachment 106459
  --> https://bugs.freedesktop.org/attachment.cgi?id=106459=edit
dmesg of bootup using radeon.msi=-1

As mentioned on the dri-devel mailing list [1] the HD 4670 in one of my older
systems is only capable of doing any 3D when booting with "radeon.msi=0".

Find the dmesg of a and lspci output attached.

[1] http://lists.freedesktop.org/archives/dri-devel/2014-September/067758.html

-- 
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/20140917/141603ac/attachment.html>

rockchip and atmel kms drivers

[Boris BREZILLON]

Hi Yaozq,

On Wed, 17 Sep 2014 13:50:26 +0800
yaozq  wrote:

> Hi Boris & Dave,
> I will update the rockchip drm driver soon, we have many change about it.

I'll wait for the new version then, just keep me in the loop when you
send it.

Thanks,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

[Ajay kumar]

Hi Tomi,

Thanks for your comments.

On Wed, Sep 17, 2014 at 5:22 PM, Tomi Valkeinen  
wrote:
> On 27/08/14 17:39, Ajay Kumar wrote:
>> Add documentation for DT properties supported by ps8622/ps8625
>> eDP-LVDS converter.
>>
>> Signed-off-by: Ajay Kumar 
>> ---
>>  .../devicetree/bindings/video/bridge/ps8622.txt|   20 
>> 
>>  1 file changed, 20 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/video/bridge/ps8622.txt
>>
>> diff --git a/Documentation/devicetree/bindings/video/bridge/ps8622.txt 
>> b/Documentation/devicetree/bindings/video/bridge/ps8622.txt
>> new file mode 100644
>> index 000..0ec8172
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/video/bridge/ps8622.txt
>> @@ -0,0 +1,20 @@
>> +ps8622-bridge bindings
>> +
>> +Required properties:
>> + - compatible: "parade,ps8622" or "parade,ps8625"
>> + - reg: first i2c address of the bridge
>> + - sleep-gpios: OF device-tree gpio specification for PD_ pin.
>> + - reset-gpios: OF device-tree gpio specification for RST_ pin.
>> +
>> +Optional properties:
>> + - lane-count: number of DP lanes to use
>> + - use-external-pwm: backlight will be controlled by an external PWM
>
> What does this mean? That the backlight support from ps8625 is not used?
> If so, maybe "disable-pwm" or something?
"use-external-pwm" or "disable-bridge-pwm" would be better.

>> +
>> +Example:
>> + lvds-bridge at 48 {
>> + compatible = "parade,ps8622";
>> + reg = <0x48>;
>> + sleep-gpios = < 6 1 0 0>;
>> + reset-gpios = < 1 1 0 0>;
>> + lane-count = <1>;
>> + };
>>
>
> I wish all new display component bindings would use the video
> ports/endpoints to describe the connections. It will be very difficult
> to improve the display driver model later if we're missing such critical
> pieces from the DT bindings.
Why do we need a complex graph when it can be handled using a simple phandle?

Ajay

-next mostly closed, what have I missed?

[Dave Airlie]

On 17 September 2014 19:45, Laurent Pinchart
 wrote:
> Hi Dave,
>
> On Wednesday 17 September 2014 10:59:42 Dave Airlie wrote:
>> Okay so I'm pretty sure I'm close to not taking anything major for next,
>>
>> I'm not sure I've gotten an exynos tree yet, so hopefully that appears
>> before -rc6,
>>
>> Please continue to send fixes for -next pulls, and I'm kinda open to
>> new hw support depending on how intrusive it is to other code.
>>
>> Now we have a strange new time of a few weeks where maybe we should go
>> fix some regressions or something!
>>
>> any other trees I've missed?
>
> Yes, you seem to have missed "[GIT PULL FOR v3.18] Renesas DRM changes".

I had it, but you had an open question to Simon that I didn't see any
response to so I put it on hold,

I don't want to get in trouble for making DT changes via my tree :-)

But I'll pull that tree now anyways, let me know if there is any issues.

Dave.

[PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

[Tomi Valkeinen]

On 17/09/14 17:29, Ajay kumar wrote:
> Hi Tomi,
> 
> Thanks for your comments.
> 
> On Wed, Sep 17, 2014 at 5:22 PM, Tomi Valkeinen  
> wrote:
>> On 27/08/14 17:39, Ajay Kumar wrote:
>>> Add documentation for DT properties supported by ps8622/ps8625
>>> eDP-LVDS converter.
>>>
>>> Signed-off-by: Ajay Kumar 
>>> ---
>>>  .../devicetree/bindings/video/bridge/ps8622.txt|   20 
>>> 
>>>  1 file changed, 20 insertions(+)
>>>  create mode 100644 
>>> Documentation/devicetree/bindings/video/bridge/ps8622.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/video/bridge/ps8622.txt 
>>> b/Documentation/devicetree/bindings/video/bridge/ps8622.txt
>>> new file mode 100644
>>> index 000..0ec8172
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/video/bridge/ps8622.txt
>>> @@ -0,0 +1,20 @@
>>> +ps8622-bridge bindings
>>> +
>>> +Required properties:
>>> + - compatible: "parade,ps8622" or "parade,ps8625"
>>> + - reg: first i2c address of the bridge
>>> + - sleep-gpios: OF device-tree gpio specification for PD_ pin.
>>> + - reset-gpios: OF device-tree gpio specification for RST_ pin.
>>> +
>>> +Optional properties:
>>> + - lane-count: number of DP lanes to use
>>> + - use-external-pwm: backlight will be controlled by an external PWM
>>
>> What does this mean? That the backlight support from ps8625 is not used?
>> If so, maybe "disable-pwm" or something?
> "use-external-pwm" or "disable-bridge-pwm" would be better.

Well, the properties are about the bridge. "use-external-pwm" means that
the bridge uses an external PWM, which, if I understood correctly, is
not what the property is about.

"disable-bridge-pwm" is ok, but the "bridge" there is extra. The
properties are about the bridge, so it's implicit.

>>> +
>>> +Example:
>>> + lvds-bridge at 48 {
>>> + compatible = "parade,ps8622";
>>> + reg = <0x48>;
>>> + sleep-gpios = < 6 1 0 0>;
>>> + reset-gpios = < 1 1 0 0>;
>>> + lane-count = <1>;
>>> + };
>>>
>>
>> I wish all new display component bindings would use the video
>> ports/endpoints to describe the connections. It will be very difficult
>> to improve the display driver model later if we're missing such critical
>> pieces from the DT bindings.
> Why do we need a complex graph when it can be handled using a simple phandle?

Maybe in your case you can handle it with simple phandle. Can you
guarantee that it's enough for everyone, on all platforms?

The point of the ports/endpoint graph is to also support more
complicated scenarios. If you now create ps8622 bindings that do not
support those graphs, the no one else using ps8622 can use
ports/endpoint graphs either.

Btw, is there an example how the bridge with these bindings is used in a
board's .dts file? I couldn't find any example with a quick search. So
it's unclear to me what the "simple phandle" actually is.

 Tomi


-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140917/cbe71368/attachment-0001.sig>

[PATCH V6 6/8] drm/bridge: Modify drm_bridge core to support driver model

[Dave Airlie]

>>
>> Before the introduction of the component framework I would have said this is
>> the way to go. Now, I think bridges should register themselves as components,
>> and the DRM master driver should use the component framework to get a
>> reference to the bridges it needs.
> Well, I have modified the bridge framework exactly the way Thierry wanted it
> to be, I mean the same way the current panel framework is.
> And, I don't think there is a problem with that.
> What problem are you facing with current bridge implementation?
> What is the advantage of using the component framework to register bridges?

At this point I'd rather merge something that keep iterating out of
tree, if this enables current hw to work and is better than what we
have we should merge it, and if we can get interest in using the
component framework then we should look at that as a separate problem.

Dave.

-next mostly closed, what have I missed?

[Inki Dae]

Hi Dave,

On 2014? 09? 17? 09:59, Dave Airlie wrote:
> Okay so I'm pretty sure I'm close to not taking anything major for next,
> 
> I'm not sure I've gotten an exynos tree yet, so hopefully that appears
> before -rc6,

I have patch sets for enhancing Exynos drm and will have a pull with
them by the end of the week.

Thanks for notice,
Inki Dae

> 
> Please continue to send fixes for -next pulls, and I'm kinda open to
> new hw support depending on how intrusive it is to other code.
> 
> Now we have a strange new time of a few weeks where maybe we should go
> fix some regressions or something!
> 
> any other trees I've missed?
> Dave.
> 

[PATCH V6 6/8] drm/bridge: Modify drm_bridge core to support driver model

[Ajay kumar]

On Wed, Sep 17, 2014 at 2:57 PM, Laurent Pinchart
 wrote:
> Hi Ajay,
>
> On Wednesday 17 September 2014 14:37:30 Ajay kumar wrote:
>> On Mon, Sep 15, 2014 at 11:07 PM, Laurent Pinchart wrote:
>> > Hi Ajay,
>> >
>> > Thank you for the patch.
>> >
>> > I think we're moving in the right direction, but we're not there yet.
>> >
>> > On Saturday 26 July 2014 00:52:08 Ajay Kumar wrote:
>> >> This patch tries to seperate drm_bridge implementation
>> >> into 2 parts, a drm part and a non_drm part.
>> >>
>> >> A set of helper functions are defined in this patch to make
>> >> bridge driver probe independent of the drm flow.
>> >>
>> >> The bridge devices register themselves on a lookup table
>> >> when they get probed by calling "drm_bridge_add_for_lookup".
>> >>
>> >> The parent encoder driver waits till the bridge is available in the
>> >> lookup table(by calling "of_drm_find_bridge") and then continues with
>> >> its initialization.
>> >
>> > Before the introduction of the component framework I would have said this
>> > is the way to go. Now, I think bridges should register themselves as
>> > components, and the DRM master driver should use the component framework
>> > to get a reference to the bridges it needs.
>>
>> Well, I have modified the bridge framework exactly the way Thierry wanted it
>> to be, I mean the same way the current panel framework is.
>> And, I don't think there is a problem with that.
>> What problem are you facing with current bridge implementation?
>> What is the advantage of using the component framework to register bridges?
>
> There are several advantages.
>
> - The component framework has been designed with this exact problem in mind,
> piecing multiple components into a display device. This patch set introduces
> yet another framework, without any compelling reason as far as I can see.
Without this bridge registration framework, there is no way you can pass on a
drm_device pointer to the bridge driver. That is why we added a lookup
framework.

> Today DRM drivers already need to use three different frameworks (component,
> I2C slave encoder and panel), and we're adding a fourth one to make the mess
> even messier. This is really a headlong rush, we need to stop and fix the
> design mistakes.
>
> - The component framework solves the probe ordering problem. Bridges can use
> deferred probing, but when a bridge requires a resources (such as a clock for
> instance) provided by the display controller, this will break.
This is exactly the way sti drm uses bridge I think. It uses component framework
to wait till the master device initializes and then passes on a
drm_device pointer
to the component devices. But please know that it is feasible in case of sti,
because the bridge they use must be a embedded chip on the SOC, but not a
third party device.
And, the case which you mentioned(clock instance need to be passed to
bridge driver)
happens only in the case of bridges embedded on the SOC, but not a
third party device.
So, you are always allowed to use component framework for that.

But, assume the bridge chip is a third party device(ex: ptn3460 or ps8622) which
sits on an i2c bus. In that case, your approach poses the foll problems:
The way master and components are binded varies from platform to platform.
i.e the way exynos consolidates and adds the components is very much
different the way msm/sti/armada does the same!
So, when one needs to use a third party device as a bridge, they will end up
hacking up their drm layer to support this third party device.

With my approach, only the corresponding encoder driver needs to
know about the bridge, that too just the phandle to bridge node.
The platform specific drm layer can still be unaware of the bridge and stuff.

With your approach, the way we would specify the bridge node will change
from platform to platform resulting in non-uniformity. Also, the platform
specific drm layer needs to be aware of the bridge.

And, I assume these are the reasons why drm_panel doesn't use component
framework. Because all the panels are often third party and hence can be reused
across platforms, and so are ptn3460/ps8622.

>> >> The encoder driver should call "drm_bridge_attach_encoder" to pass on
>> >> the drm_device and the encoder pointers to the bridge object.
>> >>
>> >> Now that the drm_device pointer is available, the encoder then calls
>> >> "bridge->funcs->post_encoder_init" to allow the bridge to continue
>> >> registering itself with the drm core.
>> >
>> > This is what really bothers me with DRM bridge.
>> >
>> > The framework assumes that a bridge will always bridge an encoder and a
>> > connector. Beside lacking support for chained bridges, this creates an
>> > artificial split between bridges and encoders by modeling the same
>> > components using drm_encoder or drm_bridge depending on their position in
>> > the video output pipeline.
>> >
>> > I would like to see drm_bridge becoming more self-centric, removing the
>> > awareness of the upstream 

[Bug 83436] Sudden framerate drops in multiple games when compiling with -mtune=generic (as well with -mtune=pentium-mmx and older CPUs)

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

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

--- Comment #31 from smoki  ---
 As i mentioned on your Phoronix thread, after much and further testing i am
pretty sure now that generic make those random lockups on 64bit :)

 Don't use Chromium but those people from bug 81644 should try non generic
tuned build :)

-- 
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/20140917/8eece8a8/attachment.html>

[Bug 83436] Sudden framerate drops in multiple games when compiling with -mtune=generic (as well with -mtune=pentium-mmx and older CPUs)

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

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

--- Comment #30 from smoki  ---
(In reply to comment #29)
> > Oh i bisected that ine, it takes 200X more time to compile on 32bit :D , 
> > actually compile libmesa_gallium i think this is the commit:
> 
> The slow compile should be fixed with:
> http://cgit.freedesktop.org/mesa/mesa/commit/
> ?id=cfeb394224f2daeb2139cf4ec489a4dd8297a44d
> 
> 
> Is the original issue - slow performance with -mtune=generic - still an
> issue?

 I alredy assume the same yesterday that slow compile fix might fix this too,
but not - it is not fixed...

-- 
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/20140917/b81bc5f3/attachment.html>

radeon/radeon_bios.c: clean up coding style differences in radeon_get_bios()

[Wilfried Klaebe]

radeon/radeon_bios.c: clean up coding style differences in radeon_get_bios()

Signed-off-by: Wilfried Klaebe 

diff --git a/drivers/gpu/drm/radeon/radeon_bios.c 
b/drivers/gpu/drm/radeon/radeon_bios.c
index 6a03624..63ccb8f 100644
--- a/drivers/gpu/drm/radeon/radeon_bios.c
+++ b/drivers/gpu/drm/radeon/radeon_bios.c
@@ -658,12 +658,10 @@ bool radeon_get_bios(struct radeon_device *rdev)
r = igp_read_bios_from_vram(rdev);
if (r == false)
r = radeon_read_bios(rdev);
-   if (r == false) {
+   if (r == false)
r = radeon_read_disabled_bios(rdev);
-   }
-   if (r == false) {
+   if (r == false)
r = radeon_read_platform_bios(rdev);
-   }
if (r == false || rdev->bios == NULL) {
DRM_ERROR("Unable to locate a BIOS ROM\n");
rdev->bios = NULL;

[PATCH 0/2] drm/exynos: use drm generic mmap interface

[Daniel Vetter]

On Wed, Sep 17, 2014 at 10:48:44PM +0900, Inki Dae wrote:
> This patch set removes unnecessary DRM_EXYNOS_GEM_MAP_OFFSET interface
> which isn't used anymore and also uses drm generic mmap interface
> instead of a mmap interface specific to Exynos drm. So this patch set
> removes a existing mmap interface and relevant codes specific to Exynos
> drm.
> 
> Inki Dae (2):
>   drm/exynos: remove DRM_EXYNOS_GEM_MAP_OFFSET ioctl
>   drm/exynos: use drm generic mmap interface

Thanks for doing this. Acked-by: Daniel Vetter 
-Daniel

> 
>  drivers/gpu/drm/exynos/exynos_drm_drv.c |   28 -
>  drivers/gpu/drm/exynos/exynos_drm_drv.h |1 -
>  drivers/gpu/drm/exynos/exynos_drm_gem.c |  101 
> +--
>  drivers/gpu/drm/exynos/exynos_drm_gem.h |   14 -
>  include/uapi/drm/exynos_drm.h   |   40 
>  5 files changed, 14 insertions(+), 170 deletions(-)
> 
> -- 
> 1.7.9.5
> 

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

-next mostly closed, what have I missed?

[Joonyoung Shim]

Hi Dave,

On 09/17/2014 09:59 AM, Dave Airlie wrote:
> Okay so I'm pretty sure I'm close to not taking anything major for next,
> 
> I'm not sure I've gotten an exynos tree yet, so hopefully that appears
> before -rc6,
> 
> Please continue to send fixes for -next pulls, and I'm kinda open to
> new hw support depending on how intrusive it is to other code.
> 
> Now we have a strange new time of a few weeks where maybe we should go
> fix some regressions or something!
> 
> any other trees I've missed?

Ping,

http://lists.freedesktop.org/archives/dri-devel/2014-August/067049.html
http://lists.freedesktop.org/archives/dri-devel/2014-August/067084.html

Thanks.

drm/radeon: allow concurrent VM use

[Alex Deucher]

On Fri, Sep 12, 2014 at 7:52 AM, Christian K?nig
 wrote:
> Similar to the already pushed patches for allowing concurrent buffers use from
> different engines this set of patches allows concurrent VM use from different
> engines at the same time.

Other than the typos I pointed out, this series is:
Reviewed-by: Alex Deucher 

[PATCH 04/11] drm/radeon: split semaphore and sync object handling

[Alex Deucher]

On Fri, Sep 12, 2014 at 7:52 AM, Christian K?nig
 wrote:
> From: Christian K?nig 
>
> Previously we just allocated space for four hardware semaphores
> in each software semaphore object. Make software semaphore objects
> represent only one hardware semaphore address again by splitting
> the sync code into it's own object.
>
> Signed-off-by: Christian K?nig 

Minor typo noted below.

Alex

> ---
>  drivers/gpu/drm/radeon/Makefile   |   3 +-
>  drivers/gpu/drm/radeon/cik.c  |  18 ++-
>  drivers/gpu/drm/radeon/cik_sdma.c |  18 ++-
>  drivers/gpu/drm/radeon/evergreen_dma.c|  18 ++-
>  drivers/gpu/drm/radeon/r600.c |  18 ++-
>  drivers/gpu/drm/radeon/r600_dma.c |  18 ++-
>  drivers/gpu/drm/radeon/radeon.h   |  40 +++---
>  drivers/gpu/drm/radeon/radeon_cs.c|   7 +-
>  drivers/gpu/drm/radeon/radeon_ib.c|  13 +-
>  drivers/gpu/drm/radeon/radeon_semaphore.c | 139 +
>  drivers/gpu/drm/radeon/radeon_sync.c  | 198 
> ++
>  drivers/gpu/drm/radeon/radeon_vm.c|   4 +-
>  drivers/gpu/drm/radeon/rv770_dma.c|  18 ++-
>  drivers/gpu/drm/radeon/si_dma.c   |  18 ++-
>  14 files changed, 286 insertions(+), 244 deletions(-)
>  create mode 100644 drivers/gpu/drm/radeon/radeon_sync.c
>
> diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
> index 7d7aed5..8cc9f68 100644
> --- a/drivers/gpu/drm/radeon/Makefile
> +++ b/drivers/gpu/drm/radeon/Makefile
> @@ -80,7 +80,8 @@ radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \
> r600_dpm.o rs780_dpm.o rv6xx_dpm.o rv770_dpm.o rv730_dpm.o 
> rv740_dpm.o \
> rv770_smc.o cypress_dpm.o btc_dpm.o sumo_dpm.o sumo_smc.o 
> trinity_dpm.o \
> trinity_smc.o ni_dpm.o si_smc.o si_dpm.o kv_smc.o kv_dpm.o ci_smc.o \
> -   ci_dpm.o dce6_afmt.o radeon_vm.o radeon_ucode.o radeon_ib.o 
> radeon_mn.o
> +   ci_dpm.o dce6_afmt.o radeon_vm.o radeon_ucode.o radeon_ib.o 
> radeon_mn.o \
> +   radeon_sync.o
>
>  # add async DMA block
>  radeon-y += \
> diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
> index 16a861d..6dd55ea 100644
> --- a/drivers/gpu/drm/radeon/cik.c
> +++ b/drivers/gpu/drm/radeon/cik.c
> @@ -3970,31 +3970,27 @@ struct radeon_fence *cik_copy_cpdma(struct 
> radeon_device *rdev,
> unsigned num_gpu_pages,
> struct reservation_object *resv)
>  {
> -   struct radeon_semaphore *sem = NULL;
> struct radeon_fence *fence;
> +   struct radeon_sync sync;
> int ring_index = rdev->asic->copy.blit_ring_index;
> struct radeon_ring *ring = >ring[ring_index];
> u32 size_in_bytes, cur_size_in_bytes, control;
> int i, num_loops;
> int r = 0;
>
> -   r = radeon_semaphore_create(rdev, );
> -   if (r) {
> -   DRM_ERROR("radeon: moving bo (%d).\n", r);
> -   return ERR_PTR(r);
> -   }
> +   radeon_sync_create();
>
> size_in_bytes = (num_gpu_pages << RADEON_GPU_PAGE_SHIFT);
> num_loops = DIV_ROUND_UP(size_in_bytes, 0x1f);
> r = radeon_ring_lock(rdev, ring, num_loops * 7 + 18);
> if (r) {
> DRM_ERROR("radeon: moving bo (%d).\n", r);
> -   radeon_semaphore_free(rdev, , NULL);
> +   radeon_sync_free(rdev, , NULL);
> return ERR_PTR(r);
> }
>
> -   radeon_semaphore_sync_resv(sem, resv, false);
> -   radeon_semaphore_sync_rings(rdev, sem, ring->idx);
> +   radeon_sync_resv(, resv, false);
> +   radeon_sync_rings(rdev, , ring->idx);
>
> for (i = 0; i < num_loops; i++) {
> cur_size_in_bytes = size_in_bytes;
> @@ -4018,12 +4014,12 @@ struct radeon_fence *cik_copy_cpdma(struct 
> radeon_device *rdev,
> r = radeon_fence_emit(rdev, , ring->idx);
> if (r) {
> radeon_ring_unlock_undo(rdev, ring);
> -   radeon_semaphore_free(rdev, , NULL);
> +   radeon_sync_free(rdev, , NULL);
> return ERR_PTR(r);
> }
>
> radeon_ring_unlock_commit(rdev, ring, false);
> -   radeon_semaphore_free(rdev, , fence);
> +   radeon_sync_free(rdev, , fence);
>
> return fence;
>  }
> diff --git a/drivers/gpu/drm/radeon/cik_sdma.c 
> b/drivers/gpu/drm/radeon/cik_sdma.c
> index dd73246..06602e4 100644
> --- a/drivers/gpu/drm/radeon/cik_sdma.c
> +++ b/drivers/gpu/drm/radeon/cik_sdma.c
> @@ -548,31 +548,27 @@ struct radeon_fence *cik_copy_dma(struct radeon_device 
> *rdev,
>   unsigned num_gpu_pages,
>   struct reservation_object *resv)
>  {
> -   struct radeon_semaphore *sem = NULL;
> struct radeon_fence *fence;
> +   struct radeon_sync sync;
> int ring_index = rdev->asic->copy.dma_ring_index;
> struct radeon_ring *ring = 

[PATCH 05/11] drm/radeon: fence PT updates manually

[Alex Deucher]

On Fri, Sep 12, 2014 at 7:52 AM, Christian K?nig
 wrote:
> From: Christian K?nig 
>
> This allows us to add the real execution fence as shared.
>
> Signed-off-by: Christian K?nig 

Minor typo noted below.

> ---
>  drivers/gpu/drm/radeon/radeon_object.c | 19 ++
>  drivers/gpu/drm/radeon/radeon_object.h |  2 ++
>  drivers/gpu/drm/radeon/radeon_vm.c | 65 
> +-
>  3 files changed, 62 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
> b/drivers/gpu/drm/radeon/radeon_object.c
> index 8abee5f..8714baf 100644
> --- a/drivers/gpu/drm/radeon/radeon_object.c
> +++ b/drivers/gpu/drm/radeon/radeon_object.c
> @@ -790,3 +790,22 @@ int radeon_bo_wait(struct radeon_bo *bo, u32 *mem_type, 
> bool no_wait)
> ttm_bo_unreserve(>tbo);
> return r;
>  }
> +
> +/**
> + * radeon_bo_fence - add fence to buffer object
> + *
> + * @bo: buffer object in question
> + * @fence: fence to add
> + * @shared: true if fence should be added shared
> + *
> + */
> +void radeon_bo_fence(struct radeon_bo *bo, struct radeon_fence *fence,
> + bool shared)
> +{
> +   struct reservation_object *resv = bo->tbo.resv;
> +
> +   if (shared)
> +   reservation_object_add_shared_fence(resv, >base);
> +   else
> +   reservation_object_add_excl_fence(resv, >base);
> +}
> diff --git a/drivers/gpu/drm/radeon/radeon_object.h 
> b/drivers/gpu/drm/radeon/radeon_object.h
> index 98a47fd..ec80b28 100644
> --- a/drivers/gpu/drm/radeon/radeon_object.h
> +++ b/drivers/gpu/drm/radeon/radeon_object.h
> @@ -154,6 +154,8 @@ extern void radeon_bo_move_notify(struct 
> ttm_buffer_object *bo,
>   struct ttm_mem_reg *new_mem);
>  extern int radeon_bo_fault_reserve_notify(struct ttm_buffer_object *bo);
>  extern int radeon_bo_get_surface_reg(struct radeon_bo *bo);
> +extern void radeon_bo_fence(struct radeon_bo *bo, struct radeon_fence *fence,
> +   bool shared);
>
>  /*
>   * sub allocation
> diff --git a/drivers/gpu/drm/radeon/radeon_vm.c 
> b/drivers/gpu/drm/radeon/radeon_vm.c
> index 411146a..84b2735 100644
> --- a/drivers/gpu/drm/radeon/radeon_vm.c
> +++ b/drivers/gpu/drm/radeon/radeon_vm.c
> @@ -143,7 +143,7 @@ struct radeon_cs_reloc *radeon_vm_get_bos(struct 
> radeon_device *rdev,
> list[0].prefered_domains = RADEON_GEM_DOMAIN_VRAM;
> list[0].allowed_domains = RADEON_GEM_DOMAIN_VRAM;
> list[0].tv.bo = >page_directory->tbo;
> -   list[0].tv.shared = false;
> +   list[0].tv.shared = true;
> list[0].tiling_flags = 0;
> list[0].handle = 0;
> list_add([0].tv.head, head);
> @@ -157,7 +157,7 @@ struct radeon_cs_reloc *radeon_vm_get_bos(struct 
> radeon_device *rdev,
> list[idx].prefered_domains = RADEON_GEM_DOMAIN_VRAM;
> list[idx].allowed_domains = RADEON_GEM_DOMAIN_VRAM;
> list[idx].tv.bo = [idx].robj->tbo;
> -   list[idx].tv.shared = false;
> +   list[idx].tv.shared = true;
> list[idx].tiling_flags = 0;
> list[idx].handle = 0;
> list_add([idx++].tv.head, head);
> @@ -388,35 +388,25 @@ static void radeon_vm_set_pages(struct radeon_device 
> *rdev,
>  static int radeon_vm_clear_bo(struct radeon_device *rdev,
>   struct radeon_bo *bo)
>  {
> -struct ttm_validate_buffer tv;
> -struct ww_acquire_ctx ticket;
> -struct list_head head;
> struct radeon_ib ib;
> unsigned entries;
> uint64_t addr;
> int r;
>
> -memset(, 0, sizeof(tv));
> -tv.bo = >tbo;
> -   tv.shared = false;
> -
> -INIT_LIST_HEAD();
> -list_add(, );
> -
> -r = ttm_eu_reserve_buffers(, , true);
> -if (r)
> +   r = radeon_bo_reserve(bo, false);
> +   if (r)
> return r;
>
> -r = ttm_bo_validate(>tbo, >placement, true, false);
> -if (r)
> -goto error;
> +   r = ttm_bo_validate(>tbo, >placement, true, false);
> +   if (r)
> +   goto error_unreserve;
>
> addr = radeon_bo_gpu_offset(bo);
> entries = radeon_bo_size(bo) / 8;
>
> r = radeon_ib_get(rdev, R600_RING_TYPE_DMA_INDEX, , NULL, 256);
> if (r)
> -goto error;
> +   goto error_unreserve;
>
> ib.length_dw = 0;
>
> @@ -426,15 +416,15 @@ static int radeon_vm_clear_bo(struct radeon_device 
> *rdev,
>
> r = radeon_ib_schedule(rdev, , NULL, false);
> if (r)
> -goto error;
> +   goto error_free;
>
> -   ttm_eu_fence_buffer_objects(, , >base);
> -   radeon_ib_free(rdev, );
> +   radeon_bo_fence(bo, ib.fence, false);
>
> -   return 0;
> +error_free:
> +   radeon_ib_free(rdev, );
>
> -error:
> -   ttm_eu_backoff_reservation(, );
> +error_unreserve:
> +   

[PATCH] drm/exynos: fix plane-framebuffer linkage

[Joonyoung Shim]

Hi,

On 09/17/2014 03:49 PM, Inki Dae wrote:
> On 2014? 09? 17? 15:35, Andrzej Hajda wrote:
>> Hi,
>>
>> On 09/16/2014 08:35 AM, Daniel Vetter wrote:
>>> On Mon, Sep 15, 2014 at 12:52:17PM -0600, Daniel Drake wrote:
 Pageflipping currently causes some inconsistencies that lead to
 crashes. Just run an app that causes a CRTC pageflip in a raw X session
 and check that it exits cleanly and can be restarted - you'll see
 crashes like:
  Unable to handle kernel NULL pointer dereference at virtual address 
 0334
  PC is at exynos_drm_crtc_plane_commit+0x20/0x40
  LR is at exynos_drm_crtc_plane_commit+0x20/0x40
  [] (exynos_drm_crtc_plane_commit) from [] 
 (exynos_drm_crtc_commit+0x44/0x70)
  [] (exynos_drm_crtc_commit) from [] 
 (exynos_drm_crtc_mode_set_commit.isra.2+0xb4/0xc4)
  [] (exynos_drm_crtc_mode_set_commit.isra.2) from [] 
 (exynos_drm_crtc_page_flip+0x140/0x1a8)
  [] (exynos_drm_crtc_page_flip) from [] 
 (drm_mode_page_flip_ioctl+0x224/0x2dc)
  [] (drm_mode_page_flip_ioctl) from [] 
 (drm_ioctl+0x338/0x4fc)

 These crashes happen because drm_plane_force_disable has previously set
 plane->crtc to NULL.

 When drm_mode_page_flip_ioctl() is used to flip another framebuffer
 onto the primary plane, crtc->primary->fb is correctly updated (this is
 a virtual plane created by plane_helper), but plane->fb is not (this
 plane is the real one, created by exynos_drm_crtc_create).

 We then come to handle rmfb of the backbuffer, which the "real" primary
 plane is incorrectly pointing at. So drm_framebuffer_remove() decides that
 the buffer is actually active on a plane and force-disables the plane.

 Ensuring that plane->fb is kept up-to-date solves that issue, but
 exposes a reference counting problem. Now we see crashes when rmfb is
 called on the front-buffer, because the rmfb code expects to drop 3
 references here, and there are only 2.

 That can be fixed by adopting the reference management found in omapdrm:
 Framebuffer references are not taken directly in crtc mode_set context,
 but rather in the context of updating the plane, which also covers
 flips. Like omapdrm we also unreference the old framebuffer here.

 Signed-off-by: Daniel Drake 
>>> This sounds very much like exynos should switch to universal planes so
>>> that the fake primary plane created by the helpers doesn't get in the way.
>>> And for chips which already use planes for everything internally this
>>> shouldn't be a lot more than a few lines.
>>> -Daniel
>>
>> The patch proposed here of course supersedes my patch fixing fb refcounting.
>> But the best solution is to get rid of virtual plane as Daniel Vetter
>> stated.
>> Daniel (Drake of course :) ) do you want to prepare patch switching to
>> universal planes?
>> Maybe other volunteers? If not I can try to do it, as it seems quite
>> straightforward.
> 
> I think you can do it and you would be a right person to do it.
> 
> Thanks,
> Inki Dae
> 
>>
>> Regards
>> Andrzej
>>
 ---
  drivers/gpu/drm/exynos/exynos_drm_crtc.c  | 12 ++--
  drivers/gpu/drm/exynos/exynos_drm_plane.c |  8 
  2 files changed, 10 insertions(+), 10 deletions(-)

 diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
 b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
 index b68e58f..7aa9dee 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
 @@ -140,16 +140,8 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, 
 struct drm_display_mode *mode,
if (manager->ops->mode_set)
manager->ops->mode_set(manager, >mode);
  
 -  ret = exynos_plane_mode_set(plane, crtc, crtc->primary->fb, 0, 0, 
 crtc_w, crtc_h,
 -  x, y, crtc_w, crtc_h);
 -  if (ret)
 -  return ret;
 -
 -  plane->crtc = crtc;
 -  plane->fb = crtc->primary->fb;
 -  drm_framebuffer_reference(plane->fb);

It's problem to add this from commit 25c8b5c3048cb6c98d402ca8d4735ccf910f727c.
Chip specific drm driver internally doesn't have to care fb reference count if
there is no special case. We should have switched to universal plane at that
time.

Thanks.

 -
 -  return 0;
 +  return exynos_plane_mode_set(plane, crtc, crtc->primary->fb, 0, 0,
 +   crtc_w, crtc_h, x, y, crtc_w, crtc_h);
  }
  
  static int exynos_drm_crtc_mode_set_commit(struct drm_crtc *crtc, int x, 
 int y,
 diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
 b/drivers/gpu/drm/exynos/exynos_drm_plane.c
 index 8371cbd..df27e35 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
 @@ -139,6 +139,14 @@ int exynos_plane_mode_set(struct drm_plane *plane, 
 struct drm_crtc *crtc,
 

[Bug 81382] Text console blanking does not go away

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

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

--- Comment #22 from Patrick  ---
Thanks for the patch, but I'm on vacation till 26th September, so long I cannot
test it.

@Daniel
As you've got the same problem, could you test the patches?

-- 
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/20140917/150de7f7/attachment.html>

Using a HD 4670 still possible?

[Michel Dänzer]

On 14.09.2014 03:13, Christoph Brill wrote:
> Am 08.09.2014 03:41 schrieb "Michel D?nzer"  >:
>  > On 07.09.2014 01:01, Christoph Brill wrote:
>  >>
>  >>
>  >> I'm currently trying to get a HD 4670 aka RV730 XT to work against X.org
>  >> 1.16, xf86-video-ati 7.4.0 on a Linux 3.16.1.
>  >>
>  >> Can anyone tell me: Should this card be able to handle an average Gnome
>  >> desktop?
>  >
>  >
>  > Of course.
>  >
>  >
>  >
>  >> The problem was: 3D rendering did not work at all.
>  >>
>  >> Starting gdm lead to hanging Xorg. Calling glxgears on a twm session
>  >> just rendered a black window, which stayed even if the process was
>  >> killed by CTRL+C. I managed to get glxgears do do its job by setting
>  >> "vblank_mode=0".
>  >>
>  >> I guessed my card does not like to play along with vsync at all. So I
>  >> went ahead to disable vsyncing (tearing is still better than no display
>  >> at all). Setting it globally in /etc/drirc seems to get glxgears
> running.
>  >>
>  >> Testing Xonotic on twm showed, that the card was now able to handle 3D.
>  >> But: gdm still was extremely sluggish and eventually froze. Starting
>  >> gnome-shell directly from startx gets me to the desktop, but any action
>  >> freezes the process.
>  >>
>  >> Is there still hope for this card or should I get rid of it?
>  >
>  >
>  > It sounds like there's a problem with interrupt processing on your
> system. Please provide the dmesg output. You might try
> disabling/enabling MSI to see if that works around the problem.
>
> Thank you so much for this hint! Booting using radeon.msi=0 finally
> brings the system into a usable state. The dmesg of a default boot (i.e.
> radeon.msi=-1) is available at http://pastebin.com/gS1xHYPc

Can you file a bug report at 
https://bugs.freedesktop.org/enter_bug.cgi?product=DRI component 
"DRM/Radeon" and attach the dmesg output there?


-- 
Earthling Michel D?nzer|  http://www.amd.com
Libre software enthusiast  |Mesa and X developer

[PATCH] drm/radeon: Disable HDP flush before every CS again for < r600

[Michel Dänzer]

From: Michel D?nzer 

It was causing display corruption with R300 generation GPUs at least.

Reported-and-Tested-by: Mikael Pettersson 
Signed-off-by: Michel D?nzer 
---
 drivers/gpu/drm/radeon/r100.c| 28 ++--
 drivers/gpu/drm/radeon/radeon_asic.c |  2 --
 drivers/gpu/drm/radeon/radeon_asic.h |  3 +--
 drivers/gpu/drm/radeon/radeon_drv.c  |  2 +-
 4 files changed, 16 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 4c5ec44..b0098e7 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -821,6 +821,20 @@ u32 r100_get_vblank_counter(struct radeon_device *rdev, 
int crtc)
return RREG32(RADEON_CRTC2_CRNT_FRAME);
 }

+/**
+ * r100_ring_hdp_flush - flush Host Data Path via the ring buffer
+ * rdev: radeon device structure
+ * ring: ring buffer struct for emitting packets
+ */
+static void r100_ring_hdp_flush(struct radeon_device *rdev, struct radeon_ring 
*ring)
+{
+   radeon_ring_write(ring, PACKET0(RADEON_HOST_PATH_CNTL, 0));
+   radeon_ring_write(ring, rdev->config.r100.hdp_cntl |
+   RADEON_HDP_READ_BUFFER_INVALIDATE);
+   radeon_ring_write(ring, PACKET0(RADEON_HOST_PATH_CNTL, 0));
+   radeon_ring_write(ring, rdev->config.r100.hdp_cntl);
+}
+
 /* Who ever call radeon_fence_emit should call ring_lock and ask
  * for enough space (today caller are ib schedule and buffer move) */
 void r100_fence_ring_emit(struct radeon_device *rdev,
@@ -1056,20 +1070,6 @@ void r100_gfx_set_wptr(struct radeon_device *rdev,
(void)RREG32(RADEON_CP_RB_WPTR);
 }

-/**
- * r100_ring_hdp_flush - flush Host Data Path via the ring buffer
- * rdev: radeon device structure
- * ring: ring buffer struct for emitting packets
- */
-void r100_ring_hdp_flush(struct radeon_device *rdev, struct radeon_ring *ring)
-{
-   radeon_ring_write(ring, PACKET0(RADEON_HOST_PATH_CNTL, 0));
-   radeon_ring_write(ring, rdev->config.r100.hdp_cntl |
-   RADEON_HDP_READ_BUFFER_INVALIDATE);
-   radeon_ring_write(ring, PACKET0(RADEON_HOST_PATH_CNTL, 0));
-   radeon_ring_write(ring, rdev->config.r100.hdp_cntl);
-}
-
 static void r100_cp_load_microcode(struct radeon_device *rdev)
 {
const __be32 *fw_data;
diff --git a/drivers/gpu/drm/radeon/radeon_asic.c 
b/drivers/gpu/drm/radeon/radeon_asic.c
index abe..2dd5847 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -185,7 +185,6 @@ static struct radeon_asic_ring r100_gfx_ring = {
.get_rptr = _gfx_get_rptr,
.get_wptr = _gfx_get_wptr,
.set_wptr = _gfx_set_wptr,
-   .hdp_flush = _ring_hdp_flush,
 };

 static struct radeon_asic r100_asic = {
@@ -332,7 +331,6 @@ static struct radeon_asic_ring r300_gfx_ring = {
.get_rptr = _gfx_get_rptr,
.get_wptr = _gfx_get_wptr,
.set_wptr = _gfx_set_wptr,
-   .hdp_flush = _ring_hdp_flush,
 };

 static struct radeon_asic r300_asic = {
diff --git a/drivers/gpu/drm/radeon/radeon_asic.h 
b/drivers/gpu/drm/radeon/radeon_asic.h
index 275a5dc..7756bc1 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.h
+++ b/drivers/gpu/drm/radeon/radeon_asic.h
@@ -148,8 +148,7 @@ u32 r100_gfx_get_wptr(struct radeon_device *rdev,
  struct radeon_ring *ring);
 void r100_gfx_set_wptr(struct radeon_device *rdev,
   struct radeon_ring *ring);
-void r100_ring_hdp_flush(struct radeon_device *rdev,
-struct radeon_ring *ring);
+
 /*
  * r200,rv250,rs300,rv280
  */
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
b/drivers/gpu/drm/radeon/radeon_drv.c
index a773830..ef5b60a 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -83,7 +83,7 @@
  *CIK: 1D and linear tiling modes contain valid PIPE_CONFIG
  *   2.39.0 - Add INFO query for number of active CUs
  *   2.40.0 - Add RADEON_GEM_GTT_WC/UC, flush HDP cache before submitting
- *CS to GPU
+ *CS to GPU on >= r600
  */
 #define KMS_DRIVER_MAJOR   2
 #define KMS_DRIVER_MINOR   40
-- 
2.1.0

[PATCH] drm/exynos: fix plane-framebuffer linkage

[Inki Dae]

On 2014? 09? 17? 15:35, Andrzej Hajda wrote:
> Hi,
> 
> On 09/16/2014 08:35 AM, Daniel Vetter wrote:
>> On Mon, Sep 15, 2014 at 12:52:17PM -0600, Daniel Drake wrote:
>>> Pageflipping currently causes some inconsistencies that lead to
>>> crashes. Just run an app that causes a CRTC pageflip in a raw X session
>>> and check that it exits cleanly and can be restarted - you'll see
>>> crashes like:
>>>  Unable to handle kernel NULL pointer dereference at virtual address 
>>> 0334
>>>  PC is at exynos_drm_crtc_plane_commit+0x20/0x40
>>>  LR is at exynos_drm_crtc_plane_commit+0x20/0x40
>>>  [] (exynos_drm_crtc_plane_commit) from [] 
>>> (exynos_drm_crtc_commit+0x44/0x70)
>>>  [] (exynos_drm_crtc_commit) from [] 
>>> (exynos_drm_crtc_mode_set_commit.isra.2+0xb4/0xc4)
>>>  [] (exynos_drm_crtc_mode_set_commit.isra.2) from [] 
>>> (exynos_drm_crtc_page_flip+0x140/0x1a8)
>>>  [] (exynos_drm_crtc_page_flip) from [] 
>>> (drm_mode_page_flip_ioctl+0x224/0x2dc)
>>>  [] (drm_mode_page_flip_ioctl) from [] 
>>> (drm_ioctl+0x338/0x4fc)
>>>
>>> These crashes happen because drm_plane_force_disable has previously set
>>> plane->crtc to NULL.
>>>
>>> When drm_mode_page_flip_ioctl() is used to flip another framebuffer
>>> onto the primary plane, crtc->primary->fb is correctly updated (this is
>>> a virtual plane created by plane_helper), but plane->fb is not (this
>>> plane is the real one, created by exynos_drm_crtc_create).
>>>
>>> We then come to handle rmfb of the backbuffer, which the "real" primary
>>> plane is incorrectly pointing at. So drm_framebuffer_remove() decides that
>>> the buffer is actually active on a plane and force-disables the plane.
>>>
>>> Ensuring that plane->fb is kept up-to-date solves that issue, but
>>> exposes a reference counting problem. Now we see crashes when rmfb is
>>> called on the front-buffer, because the rmfb code expects to drop 3
>>> references here, and there are only 2.
>>>
>>> That can be fixed by adopting the reference management found in omapdrm:
>>> Framebuffer references are not taken directly in crtc mode_set context,
>>> but rather in the context of updating the plane, which also covers
>>> flips. Like omapdrm we also unreference the old framebuffer here.
>>>
>>> Signed-off-by: Daniel Drake 
>> This sounds very much like exynos should switch to universal planes so
>> that the fake primary plane created by the helpers doesn't get in the way.
>> And for chips which already use planes for everything internally this
>> shouldn't be a lot more than a few lines.
>> -Daniel
> 
> The patch proposed here of course supersedes my patch fixing fb refcounting.
> But the best solution is to get rid of virtual plane as Daniel Vetter
> stated.
> Daniel (Drake of course :) ) do you want to prepare patch switching to
> universal planes?
> Maybe other volunteers? If not I can try to do it, as it seems quite
> straightforward.

I think you can do it and you would be a right person to do it.

Thanks,
Inki Dae

> 
> Regards
> Andrzej
> 
>>> ---
>>>  drivers/gpu/drm/exynos/exynos_drm_crtc.c  | 12 ++--
>>>  drivers/gpu/drm/exynos/exynos_drm_plane.c |  8 
>>>  2 files changed, 10 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
>>> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>>> index b68e58f..7aa9dee 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>>> @@ -140,16 +140,8 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct 
>>> drm_display_mode *mode,
>>> if (manager->ops->mode_set)
>>> manager->ops->mode_set(manager, >mode);
>>>  
>>> -   ret = exynos_plane_mode_set(plane, crtc, crtc->primary->fb, 0, 0, 
>>> crtc_w, crtc_h,
>>> -   x, y, crtc_w, crtc_h);
>>> -   if (ret)
>>> -   return ret;
>>> -
>>> -   plane->crtc = crtc;
>>> -   plane->fb = crtc->primary->fb;
>>> -   drm_framebuffer_reference(plane->fb);
>>> -
>>> -   return 0;
>>> +   return exynos_plane_mode_set(plane, crtc, crtc->primary->fb, 0, 0,
>>> +crtc_w, crtc_h, x, y, crtc_w, crtc_h);
>>>  }
>>>  
>>>  static int exynos_drm_crtc_mode_set_commit(struct drm_crtc *crtc, int x, 
>>> int y,
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
>>> b/drivers/gpu/drm/exynos/exynos_drm_plane.c
>>> index 8371cbd..df27e35 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
>>> @@ -139,6 +139,14 @@ int exynos_plane_mode_set(struct drm_plane *plane, 
>>> struct drm_crtc *crtc,
>>> overlay->crtc_x, overlay->crtc_y,
>>> overlay->crtc_width, overlay->crtc_height);
>>>  
>>> +   if (plane->fb)
>>> +   drm_framebuffer_unreference(plane->fb);
>>> +
>>> +   drm_framebuffer_reference(fb);
>>> +
>>> +   plane->fb = fb;
>>> +   plane->crtc = crtc;
>>> +
>>> exynos_drm_crtc_plane_mode_set(crtc, overlay);
>>>  
>>> return 0;
>>> -- 

[PATCH] drm/exynos: fix plane-framebuffer linkage

[Daniel Vetter]

On Wed, Sep 17, 2014 at 2:19 PM, Daniel Drake  wrote:
>> Chip specific drm driver internally doesn't have to care fb reference count 
>> if
>> there is no special case. We should have switched to universal plane at that
>> time.
>
> To me it seems like the chip-specific DRM drivers do need to add a
> reference in the crtc_mode_set and crtc page flip paths otherwise
> framebuffer removal crashes (expecting to remove 3 references), as
> noted by my testing and also in commit 25c8b5c304.

I think fb refcounting in exynos is just plain busted. If you look at
other drivers the only place the refcount framebuffers or backing
storage objects is for pageflips to make sure the memory doesn't go
away while the hw is still scanning out the old framebuffer. If you
refcount anywhere else you either do something really crazy or your
driver is broken.

> However, I'll be happy if universal planes means the driver does not
> have to care about this any more. Andrej, please go ahead if you are
> interested, I'll be happy to test your results.

universal planes will fix up the mess with 2 drm plane objects
(primary plane + exonys internal primary). So should help to untangle
this not, but it will not magically fix the refcounting bugs itself.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support

[Ajay kumar]

Hi Laurent,

Please find the latest series here:
http://www.spinics.net/lists/dri-devel/msg66740.html

On Wed, Sep 17, 2014 at 3:23 PM, Laurent Pinchart
 wrote:
> Hi Thierry,
>
> On Wednesday 30 July 2014 11:40:54 Thierry Reding wrote:
>> On Wed, Jul 30, 2014 at 11:54:00AM +0530, Ajay kumar wrote:
>> > On Tue, Jul 29, 2014 at 5:17 PM, Thierry Reding wrote:
>> > > On Tue, Jul 29, 2014 at 01:42:09PM +0200, Andreas F?rber wrote:
>> > >> Am 29.07.2014 13:36, schrieb Thierry Reding:
>> > >> > On Tue, Jul 29, 2014 at 01:21:48PM +0200, Andreas F?rber wrote:
>> > >> >> Am 28.07.2014 08:13, schrieb Ajay kumar:
>> > >> >>> On 7/27/14, Andreas F?rber  wrote:
>> > >>  Am 25.07.2014 21:22, schrieb Ajay Kumar:
>> > >> > This series is based on exynos-drm-next branch of Inki Dae's tree
>> > >> > at:
>> > >> > git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.
>> > >> > git
>> > >> >
>> > >> > I have tested this after adding few DT changes for
>> > >> > exynos5250-snow,
>> > >> > exynos5420-peach-pit and exynos5800-peach-pi boards.
>> > >> 
>> > >>  I'm trying to test this with a modified exynos5250-spring DT
>> > >>
>> > >> [...]
>> > >>
>> > >> >> Unfortunately the most I got on Spring with attached DT was a blank
>> > >> >> screen with a white horizontal line in the middle.
>> > >> >>
>> > >> >> Do I need to specify a specific panel model for Spring?
>> > >>
>> > >> [...]
>> > >>
>> > >> >> From 9172a26a8f0d0f0d170bd27e1c150ad204d8086a Mon Sep 17 00:00:00
>> > >> >> 2001
>> > >> >> From: =?UTF-8?q?Andreas=20F=C3=A4rber?= 
>> > >> >> Date: Sun, 27 Jul 2014 21:58:06 +0200
>> > >> >> Subject: [PATCH] ARM: dts: exynos5250: Add eDP/LVDS bridge to Spring
>> > >> >> MIME-Version: 1.0
>> > >> >> Content-Type: text/plain; charset=UTF-8
>> > >> >> Content-Transfer-Encoding: 8bit
>> > >> >>
>> > >> >> Signed-off-by: Ajay Kumar 
>> > >> >> [AF: Redone for v6]
>> > >> >> Signed-off-by: Andreas F??rber 
>> > >> >> ---
>> > >> >>
>> > >> >>  arch/arm/boot/dts/exynos5250-spring.dts | 32 +-
>> > >> >>  1 file changed, 31 insertions(+), 1 deletion(-)
>> > >> >>
>> > >> >> diff --git a/arch/arm/boot/dts/exynos5250-spring.dts
>> > >> >> b/arch/arm/boot/dts/exynos5250-spring.dts index
>> > >> >> 687dfab86bc8..517b1ff2bfdf 100644
>> > >> >> --- a/arch/arm/boot/dts/exynos5250-spring.dts
>> > >> >> +++ b/arch/arm/boot/dts/exynos5250-spring.dts
>> > >> >> @@ -64,10 +64,14 @@
>> > >> >>vdd_pll-supply = <_ldo8_reg>;
>> > >> >>};
>> > >> >>
>> > >> >> +  panel: panel {
>> > >> >> +  compatible = "simple-panel";
>> > >> >> +  };
>> > >> >
>> > >> > You can't do this. "simple-panel" isn't a valid panel model. It
>> > >> > should probably be removed from the platform_of_match table in the
>> > >> > driver.
>> > >>
>> > >> Okay, that means the Snow DT is wrong, too:
>> > >> https://patchwork.kernel.org/patch/4625441/
>> > >>
>> > >> And the others specify it as fallback:
>> > >> https://patchwork.kernel.org/patch/4625461/
>> > >> https://patchwork.kernel.org/patch/4625451/
>> > >
>> > > A quick grep shows that many (all?) devices that use DRM panels provide
>> > > simple-panel as fallback. That's probably fine as long as they also do
>> > > provide the specific model. But given that simple-panel does not have a
>> > > mode or physical size, I don't think even that makes sense.
>> >
>> > On snow, the bridge chip provides the display mode instead of the panel.
>> > That is why display was working for me.
>>
>> Okay, I suppose under some circumstances that might make sense. Although
>> it's still always the panel that dictates the display timings, so the
>> panel node needs to have a panel model specific compatible value with a
>> matching entry in the panel-simple driver so that it can even be used in
>> setups without a bridge.
>>
>> One other thing: how does the bridge know which mode to drive? I suspect
>> that it can drive more than one mode? Can it freely be configured or
>> does it have a predefined set of modes? If the latter, then according to
>> what you said above there needs to be a way to configure the bridge (via
>> DT?) so that it reports the mode matching the panel. I wonder if that
>> should be handled completely in code, so that for example a bridge has a
>> panel attached it can use the panel's .get_modes() and select a matching
>> mode among the set that it supports.
>
> Yes, pretty please :-) I don't think it would be a good idea to duplicate mode
> information in the bridge DT node, as that's not a property of the bridge.
> Querying the mode at runtime is in my opinion a much better option, and would
> also allow switching between different modes at runtime when that makes sense.
>
> Now, I'm not sure whether it should be the bridge driver querying the panel
> driver directly, or the display controller driver doing it and then
> configuring the bridge accordingly. The latter seems more generic to me and
> doesn't rely on the 

[Bug 81382] Text console blanking does not go away

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

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

--- Comment #21 from Alex Deucher  ---
Created attachment 106442
  --> https://bugs.freedesktop.org/attachment.cgi?id=106442=edit
patch 2/2

-- 
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/20140917/142eccc8/attachment.html>

[Bug 81382] Text console blanking does not go away

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

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

--- Comment #20 from Alex Deucher  ---
Created attachment 106441
  --> https://bugs.freedesktop.org/attachment.cgi?id=106441=edit
patch 1/2

Do the attached patches help?  The first patch adds a backlight module
parameter to disable the gpu backlight device for testing.  The second adds a
quirk for the Amilo laptop.

-- 
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/20140917/c05ec8d6/attachment.html>

[PATCH 5/8] drm/radeon: cope with foreign fences inside display

[Christian König]

Am 17.09.2014 um 14:35 schrieb Maarten Lankhorst:
> Signed-off-by: Maarten Lankhorst 

Reviewed-by: Christian K?nig 

> ---
>   drivers/gpu/drm/radeon/radeon.h |  2 +-
>   drivers/gpu/drm/radeon/radeon_display.c | 30 +++---
>   2 files changed, 20 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index 82b0e11ade89..9aa75c1af4f4 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -710,7 +710,7 @@ struct radeon_flip_work {
>   uint64_tbase;
>   struct drm_pending_vblank_event *event;
>   struct radeon_bo*old_rbo;
> - struct radeon_fence *fence;
> + struct fence*fence;
>   };
>   
>   struct r500_irq_stat_regs {
> diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
> b/drivers/gpu/drm/radeon/radeon_display.c
> index 4eb37976f879..00ead8c2758a 100644
> --- a/drivers/gpu/drm/radeon/radeon_display.c
> +++ b/drivers/gpu/drm/radeon/radeon_display.c
> @@ -402,14 +402,21 @@ static void radeon_flip_work_func(struct work_struct 
> *__work)
>   
>   down_read(>exclusive_lock);
>   if (work->fence) {
> - r = radeon_fence_wait(work->fence, false);
> - if (r == -EDEADLK) {
> - up_read(>exclusive_lock);
> - do {
> - r = radeon_gpu_reset(rdev);
> - } while (r == -EAGAIN);
> - down_read(>exclusive_lock);
> - }
> + struct radeon_fence *fence;
> +
> + fence = to_radeon_fence(work->fence);
> + if (fence && fence->rdev == rdev) {
> + r = radeon_fence_wait(fence, false);
> + if (r == -EDEADLK) {
> + up_read(>exclusive_lock);
> + do {
> + r = radeon_gpu_reset(rdev);
> + } while (r == -EAGAIN);
> + down_read(>exclusive_lock);
> + }
> + } else
> + r = fence_wait(work->fence, false);
> +
>   if (r)
>   DRM_ERROR("failed to wait on page flip fence (%d)!\n", 
> r);
>   
> @@ -418,7 +425,8 @@ static void radeon_flip_work_func(struct work_struct 
> *__work)
>* confused about which BO the CRTC is scanning out
>*/
>   
> - radeon_fence_unref(>fence);
> + fence_put(work->fence);
> + work->fence = NULL;
>   }
>   
>   /* We borrow the event spin lock for protecting flip_status */
> @@ -494,7 +502,7 @@ static int radeon_crtc_page_flip(struct drm_crtc *crtc,
>   DRM_ERROR("failed to pin new rbo buffer before flip\n");
>   goto cleanup;
>   }
> - work->fence = (struct radeon_fence 
> *)fence_get(reservation_object_get_excl(new_rbo->tbo.resv));
> + work->fence = fence_get(reservation_object_get_excl(new_rbo->tbo.resv));
>   radeon_bo_get_tiling_flags(new_rbo, _flags, NULL);
>   radeon_bo_unreserve(new_rbo);
>   
> @@ -576,7 +584,7 @@ pflip_cleanup:
>   
>   cleanup:
>   drm_gem_object_unreference_unlocked(>old_rbo->gem_base);
> - radeon_fence_unref(>fence);
> + fence_put(work->fence);
>   kfree(work);
>   return r;
>   }

[PATCH 7/8] drm/radeon: export reservation_object from dmabuf to ttm

[Christian König]

Am 17.09.2014 um 14:35 schrieb Maarten Lankhorst:
> Adds an extra argument to ttm_bo_create, which is only used in radeon_prime.c.
>
> Signed-off-by: Maarten Lankhorst 
> ---
>   drivers/gpu/drm/radeon/cik.c  | 4 ++--
>   drivers/gpu/drm/radeon/evergreen.c| 6 +++---
>   drivers/gpu/drm/radeon/r600.c | 4 ++--
>   drivers/gpu/drm/radeon/radeon_benchmark.c | 4 ++--
>   drivers/gpu/drm/radeon/radeon_device.c| 2 +-
>   drivers/gpu/drm/radeon/radeon_gart.c  | 2 +-
>   drivers/gpu/drm/radeon/radeon_gem.c   | 2 +-
>   drivers/gpu/drm/radeon/radeon_object.c| 8 +---
>   drivers/gpu/drm/radeon/radeon_object.h| 1 +
>   drivers/gpu/drm/radeon/radeon_prime.c | 5 -
>   drivers/gpu/drm/radeon/radeon_ring.c  | 2 +-
>   drivers/gpu/drm/radeon/radeon_sa.c| 2 +-
>   drivers/gpu/drm/radeon/radeon_test.c  | 5 +++--
>   drivers/gpu/drm/radeon/radeon_ttm.c   | 2 +-
>   drivers/gpu/drm/radeon/radeon_uvd.c   | 3 ++-
>   drivers/gpu/drm/radeon/radeon_vce.c   | 3 ++-
>   drivers/gpu/drm/radeon/radeon_vm.c| 5 +++--
>   17 files changed, 35 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
> index 1440b6e9281e..1f8484284b47 100644
> --- a/drivers/gpu/drm/radeon/cik.c
> +++ b/drivers/gpu/drm/radeon/cik.c
> @@ -4690,7 +4690,7 @@ static int cik_mec_init(struct radeon_device *rdev)
>   r = radeon_bo_create(rdev,
>rdev->mec.num_mec *rdev->mec.num_pipe * 
> MEC_HPD_SIZE * 2,
>PAGE_SIZE, true,
> -  RADEON_GEM_DOMAIN_GTT, 0, NULL,
> +  RADEON_GEM_DOMAIN_GTT, 0, NULL, NULL,
>>mec.hpd_eop_obj);
>   if (r) {
>   dev_warn(rdev->dev, "(%d) create HDP EOP bo failed\n", 
> r);
> @@ -4861,7 +4861,7 @@ static int cik_cp_compute_resume(struct radeon_device 
> *rdev)
>sizeof(struct bonaire_mqd),
>PAGE_SIZE, true,
>RADEON_GEM_DOMAIN_GTT, 0, NULL,
> -  >ring[idx].mqd_obj);
> +  NULL, >ring[idx].mqd_obj);
>   if (r) {
>   dev_warn(rdev->dev, "(%d) create MQD bo 
> failed\n", r);
>   return r;
> diff --git a/drivers/gpu/drm/radeon/evergreen.c 
> b/drivers/gpu/drm/radeon/evergreen.c
> index dbca60c7d097..c6ccef6c3596 100644
> --- a/drivers/gpu/drm/radeon/evergreen.c
> +++ b/drivers/gpu/drm/radeon/evergreen.c
> @@ -4023,7 +4023,7 @@ int sumo_rlc_init(struct radeon_device *rdev)
>   if (rdev->rlc.save_restore_obj == NULL) {
>   r = radeon_bo_create(rdev, dws * 4, PAGE_SIZE, true,
>RADEON_GEM_DOMAIN_VRAM, 0, NULL,
> -  >rlc.save_restore_obj);
> +  NULL, >rlc.save_restore_obj);
>   if (r) {
>   dev_warn(rdev->dev, "(%d) create RLC sr bo 
> failed\n", r);
>   return r;
> @@ -4102,7 +4102,7 @@ int sumo_rlc_init(struct radeon_device *rdev)
>   if (rdev->rlc.clear_state_obj == NULL) {
>   r = radeon_bo_create(rdev, dws * 4, PAGE_SIZE, true,
>RADEON_GEM_DOMAIN_VRAM, 0, NULL,
> -  >rlc.clear_state_obj);
> +  NULL, >rlc.clear_state_obj);
>   if (r) {
>   dev_warn(rdev->dev, "(%d) create RLC c bo 
> failed\n", r);
>   sumo_rlc_fini(rdev);
> @@ -4179,7 +4179,7 @@ int sumo_rlc_init(struct radeon_device *rdev)
>   r = radeon_bo_create(rdev, rdev->rlc.cp_table_size,
>PAGE_SIZE, true,
>RADEON_GEM_DOMAIN_VRAM, 0, NULL,
> -  >rlc.cp_table_obj);
> +  NULL, >rlc.cp_table_obj);
>   if (r) {
>   dev_warn(rdev->dev, "(%d) create RLC cp table 
> bo failed\n", r);
>   sumo_rlc_fini(rdev);
> diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
> index 35c22ee9bc4a..a82eaa81cd07 100644
> --- a/drivers/gpu/drm/radeon/r600.c
> +++ b/drivers/gpu/drm/radeon/r600.c
> @@ -1430,7 +1430,7 @@ int r600_vram_scratch_init(struct radeon_device *rdev)
>   if (rdev->vram_scratch.robj == NULL) {
>   r = radeon_bo_create(rdev, RADEON_GPU_PAGE_SIZE,
>PAGE_SIZE, true, 

[PATCH 6/8] drm/radeon: cope with foreign fences inside the reservation object

[Christian König]

Am 17.09.2014 um 14:35 schrieb Maarten Lankhorst:
> Not the whole world is a radeon! :-)
>
> Signed-off-by: Maarten Lankhorst 
> ---
>   drivers/gpu/drm/radeon/cik.c  |  2 +-
>   drivers/gpu/drm/radeon/cik_sdma.c |  2 +-
>   drivers/gpu/drm/radeon/evergreen_dma.c|  2 +-
>   drivers/gpu/drm/radeon/r600.c |  2 +-
>   drivers/gpu/drm/radeon/r600_dma.c |  2 +-
>   drivers/gpu/drm/radeon/radeon.h   |  7 ---
>   drivers/gpu/drm/radeon/radeon_cs.c| 27 ---
>   drivers/gpu/drm/radeon/radeon_fence.c |  3 +++
>   drivers/gpu/drm/radeon/radeon_semaphore.c | 24 ++--
>   drivers/gpu/drm/radeon/radeon_vm.c|  4 ++--
>   drivers/gpu/drm/radeon/rv770_dma.c|  2 +-
>   drivers/gpu/drm/radeon/si_dma.c   |  2 +-
>   12 files changed, 54 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
> index 0d761f73a7fa..1440b6e9281e 100644
> --- a/drivers/gpu/drm/radeon/cik.c
> +++ b/drivers/gpu/drm/radeon/cik.c
> @@ -3993,7 +3993,7 @@ struct radeon_fence *cik_copy_cpdma(struct 
> radeon_device *rdev,
>   return ERR_PTR(r);
>   }
>   
> - radeon_semaphore_sync_resv(sem, resv, false);
> + radeon_semaphore_sync_resv(rdev, sem, resv, false, false);
>   radeon_semaphore_sync_rings(rdev, sem, ring->idx);
>   
>   for (i = 0; i < num_loops; i++) {
> diff --git a/drivers/gpu/drm/radeon/cik_sdma.c 
> b/drivers/gpu/drm/radeon/cik_sdma.c
> index c01a6100c318..315c595418ec 100644
> --- a/drivers/gpu/drm/radeon/cik_sdma.c
> +++ b/drivers/gpu/drm/radeon/cik_sdma.c
> @@ -571,7 +571,7 @@ struct radeon_fence *cik_copy_dma(struct radeon_device 
> *rdev,
>   return ERR_PTR(r);
>   }
>   
> - radeon_semaphore_sync_resv(sem, resv, false);
> + radeon_semaphore_sync_resv(rdev, sem, resv, false, false);
>   radeon_semaphore_sync_rings(rdev, sem, ring->idx);
>   
>   for (i = 0; i < num_loops; i++) {
> diff --git a/drivers/gpu/drm/radeon/evergreen_dma.c 
> b/drivers/gpu/drm/radeon/evergreen_dma.c
> index 946f37d0b469..5a5686792068 100644
> --- a/drivers/gpu/drm/radeon/evergreen_dma.c
> +++ b/drivers/gpu/drm/radeon/evergreen_dma.c
> @@ -133,7 +133,7 @@ struct radeon_fence *evergreen_copy_dma(struct 
> radeon_device *rdev,
>   return ERR_PTR(r);
>   }
>   
> - radeon_semaphore_sync_resv(sem, resv, false);
> + radeon_semaphore_sync_resv(rdev, sem, resv, false, false);
>   radeon_semaphore_sync_rings(rdev, sem, ring->idx);
>   
>   for (i = 0; i < num_loops; i++) {
> diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
> index 25f367ac4637..35c22ee9bc4a 100644
> --- a/drivers/gpu/drm/radeon/r600.c
> +++ b/drivers/gpu/drm/radeon/r600.c
> @@ -2912,7 +2912,7 @@ struct radeon_fence *r600_copy_cpdma(struct 
> radeon_device *rdev,
>   return ERR_PTR(r);
>   }
>   
> - radeon_semaphore_sync_resv(sem, resv, false);
> + radeon_semaphore_sync_resv(rdev, sem, resv, false, false);
>   radeon_semaphore_sync_rings(rdev, sem, ring->idx);
>   
>   radeon_ring_write(ring, PACKET3(PACKET3_SET_CONFIG_REG, 1));
> diff --git a/drivers/gpu/drm/radeon/r600_dma.c 
> b/drivers/gpu/drm/radeon/r600_dma.c
> index fc54224ce87b..674af8db7a35 100644
> --- a/drivers/gpu/drm/radeon/r600_dma.c
> +++ b/drivers/gpu/drm/radeon/r600_dma.c
> @@ -470,7 +470,7 @@ struct radeon_fence *r600_copy_dma(struct radeon_device 
> *rdev,
>   return ERR_PTR(r);
>   }
>   
> - radeon_semaphore_sync_resv(sem, resv, false);
> + radeon_semaphore_sync_resv(rdev, sem, resv, false, false);
>   radeon_semaphore_sync_rings(rdev, sem, ring->idx);
>   
>   for (i = 0; i < num_loops; i++) {
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index 9aa75c1af4f4..6cdc5e62fe12 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -587,9 +587,10 @@ bool radeon_semaphore_emit_wait(struct radeon_device 
> *rdev, int ring,
>   struct radeon_semaphore *semaphore);
>   void radeon_semaphore_sync_fence(struct radeon_semaphore *semaphore,
>struct radeon_fence *fence);
> -void radeon_semaphore_sync_resv(struct radeon_semaphore *semaphore,
> - struct reservation_object *resv,
> - bool shared);
> +int radeon_semaphore_sync_resv(struct radeon_device *rdev,
> +struct radeon_semaphore *semaphore,
> +struct reservation_object *resv,
> +bool shared, bool intr);
>   int radeon_semaphore_sync_rings(struct radeon_device *rdev,
>   struct radeon_semaphore *semaphore,
>   int waiting_ring);
> diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
> 

[PATCH V7 00/12] drm/exynos: few patches to enhance bridge chip support

[Ajay kumar]

On Tue, Sep 16, 2014 at 6:14 PM, Javier Martinez Canillas
 wrote:
> [adding Laurent Pinchart to cc who had concerns with a previous
> version of this patch-set]
>
> Hello Ajay,
>
> On Wed, Aug 27, 2014 at 4:29 PM, Ajay Kumar  
> wrote:
>> This series is based on master branch of Linus tree at:
>> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>>
>> I have tested this after adding few DT changes for exynos5250-snow and
>> exynos5420-peach-pit boards.
>>
>> The V4 series of this particular patchset was also tested by:
>> Rahul Sharma 
>> Javier Martinez Canillas 
>>
>> Changes since V2:
>> -- Address comments from Jingoo Han for ps8622 driver
>> -- Address comments from Daniel, Rob and Thierry regarding
>>bridge chaining
>> -- Address comments from Thierry regarding the names for
>>new drm_panel functions
>>
>> Changes since V3:
>> -- Remove hotplug based initialization of exynos_dp
>> -- Make exynos_dp work directly with drm_panel, remove
>>dependency on panel_binder
>> -- Minor cleanups in panel_binder and panel_lvds driver
>>
>> Changes since V4:
>> -- Use gpiod interface for panel-lvds and ps8622 drivers.
>> -- Address comments from Javier.
>> -- Fix compilation issues when PANEL_BINDER is selected as module.
>> -- Split Documentation patches from driver patches.
>> -- Rebase on top of the tree.
>>
>> Changes since V5:
>> -- Modify bridge drivers to support driver model.
>> -- Drop the concept of bridge chain(sincle there are no 2 real 
>> bridges)
>>Hence drop bridge-panel_binder layer.
>> -- Drop panel-lvds driver and accomodate the required changes in
>>panel-simple driver.
>> -- Use gpiod interface in ptn3460 driver.
>> -- Address all comments by Thierry Reding for V5 series.
>> -- Address comments from Sean Paul for exynos_dp_commit issue.
>>
>> Changes since V6:
>> -- Panel patches were seperated and they are merged already.
>> -- Fix few issues with ptn3460, before modifying the bridge core.
>> -- Modify drm_bridge as per Thierry's comments for V6 series.
>> -- Add drm_bridge changes minimally without breaking existing code.
>> -- Add new features for ptn3460, step-by-step.
>> -- Address comments from Thierry and Andreas for ptn3460 and ps8622.
>> -- Split documentation patches from driver patches.
>>
>
> I've tested your series on an Exynos5420 Peach Pit and an Exynos5250
> Snow Chromebooks and display worked for me on both machines.
Great!

> I also needed "[PATCH] drm/panel: simple: Add AUO B116XW03 panel
> support" [0] which does not apply cleanly on linux-next so you may
> want to do a re-spin for that patch.
Ok. I will take care of this in next version.

> For Snow I also had to disable CONFIG_FB_SIMPLE, otherwise I just saw
> a blink on boot and only the backlight remained turned on (no display
> output). I don't know if that is expected since IIUC it should be
> possible to do a transition from simplefb to a DRM/KMS driver. I don't
> have a serial console hooked on this machine so I couldn't debug it
> further, sorry.
I am just wondering how SIMPLE FB can affect DRM based display.
I am not even sure if both can co-exist or not. Is there anything
we can do with bootargs instead of CONFIG?

Ajay

> Also, I saw that Laurent mentioned some concerns today about the
> previous version (v6) of your series [1]. I guess he missed this v7
> although AFAIU there was no fundamental change on this one so his
> concerns remains? I was really hoping that this could make it to 3.18
> since display support is one of the last major functionalities that is
> missing on these machines.
>
> Best regards,
> Javier
>
> [0]: http://patchwork.ozlabs.org/patch/384744/
> [1]: http://www.spinics.net/lists/linux-samsung-soc/msg36791.html

[PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

[Tomi Valkeinen]

On 27/08/14 17:39, Ajay Kumar wrote:
> Add documentation for DT properties supported by ps8622/ps8625
> eDP-LVDS converter.
> 
> Signed-off-by: Ajay Kumar 
> ---
>  .../devicetree/bindings/video/bridge/ps8622.txt|   20 
> 
>  1 file changed, 20 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/video/bridge/ps8622.txt
> 
> diff --git a/Documentation/devicetree/bindings/video/bridge/ps8622.txt 
> b/Documentation/devicetree/bindings/video/bridge/ps8622.txt
> new file mode 100644
> index 000..0ec8172
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/bridge/ps8622.txt
> @@ -0,0 +1,20 @@
> +ps8622-bridge bindings
> +
> +Required properties:
> + - compatible: "parade,ps8622" or "parade,ps8625"
> + - reg: first i2c address of the bridge
> + - sleep-gpios: OF device-tree gpio specification for PD_ pin.
> + - reset-gpios: OF device-tree gpio specification for RST_ pin.
> +
> +Optional properties:
> + - lane-count: number of DP lanes to use
> + - use-external-pwm: backlight will be controlled by an external PWM

What does this mean? That the backlight support from ps8625 is not used?
If so, maybe "disable-pwm" or something?

> +
> +Example:
> + lvds-bridge at 48 {
> + compatible = "parade,ps8622";
> + reg = <0x48>;
> + sleep-gpios = < 6 1 0 0>;
> + reset-gpios = < 1 1 0 0>;
> + lane-count = <1>;
> + };
> 

I wish all new display component bindings would use the video
ports/endpoints to describe the connections. It will be very difficult
to improve the display driver model later if we're missing such critical
pieces from the DT bindings.

 Tomi


-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140917/d9fcb555/attachment.sig>

[PATCH V6 6/8] drm/bridge: Modify drm_bridge core to support driver model

[Ajay kumar]

Hi Laurent,

On Mon, Sep 15, 2014 at 11:07 PM, Laurent Pinchart
 wrote:
> Hi Ajay,
>
> Thank you for the patch.
>
> I think we're moving in the right direction, but we're not there yet.
>
> On Saturday 26 July 2014 00:52:08 Ajay Kumar wrote:
>> This patch tries to seperate drm_bridge implementation
>> into 2 parts, a drm part and a non_drm part.
>>
>> A set of helper functions are defined in this patch to make
>> bridge driver probe independent of the drm flow.
>>
>> The bridge devices register themselves on a lookup table
>> when they get probed by calling "drm_bridge_add_for_lookup".
>>
>> The parent encoder driver waits till the bridge is available in the
>> lookup table(by calling "of_drm_find_bridge") and then continues with
>> its initialization.
>
> Before the introduction of the component framework I would have said this is
> the way to go. Now, I think bridges should register themselves as components,
> and the DRM master driver should use the component framework to get a
> reference to the bridges it needs.
Well, I have modified the bridge framework exactly the way Thierry wanted it
to be, I mean the same way the current panel framework is.
And, I don't think there is a problem with that.
What problem are you facing with current bridge implementation?
What is the advantage of using the component framework to register bridges?

>> The encoder driver should call "drm_bridge_attach_encoder" to pass on
>> the drm_device and the encoder pointers to the bridge object.
>>
>> Now that the drm_device pointer is available, the encoder then calls
>> "bridge->funcs->post_encoder_init" to allow the bridge to continue
>> registering itself with the drm core.
>
> This is what really bothers me with DRM bridge.
>
> The framework assumes that a bridge will always bridge an encoder and a
> connector. Beside lacking support for chained bridges, this creates an
> artificial split between bridges and encoders by modeling the same components
> using drm_encoder or drm_bridge depending on their position in the video
> output pipeline.
>
> I would like to see drm_bridge becoming more self-centric, removing the
> awareness of the upstream encoder and downstream connector. I'll give this a
> try, but it will conflict with this patch, so I'd like to share opinions and
> coordinate efforts sooner than later if possible.
I am not really able to understand how you want "drm_bridge" to be.
As of now, there are many platforms using drm_bridge and they don't
have a problem with current implementation.
Regarding chained bridges: Can't you add this once my patchset is merged?
As an additional feature?

To be honest, I have spent quite sometime for working on this patchset.
All I started with was to add drm_panel support to drm_bridge.
When I sent the first patchset for that, Daniel, Rob and Thierry raised a
concern that current bridge framework itself is not proper and hence
they asked me to fix that first. And we have reached till here based on
their comments only.

Without this patchset, you cannot bring an X server
based display on snow and peach_pit. Also, day by day the number of
platforms using drm_bridge is increasing. And, I don't really see a problem
with the current approach(which is exactly the same way panel framework is).
And, I am no decision maker here. I would expect the top guys to comment!

Ajay

>> Also, non driver model based ptn3460 driver is removed in this patch.
>>
>> Signed-off-by: Ajay Kumar 
>> ---
>>  .../devicetree/bindings/drm/bridge/ptn3460.txt |   27 --
>>  drivers/gpu/drm/Makefile   |1 +
>>  drivers/gpu/drm/bridge/Kconfig |   12 +-
>>  drivers/gpu/drm/bridge/Makefile|2 -
>>  drivers/gpu/drm/bridge/ptn3460.c   |  343 -
>>  drivers/gpu/drm/drm_bridge.c   |   89 +
>>  drivers/gpu/drm/drm_crtc.c |9 +-
>>  drivers/gpu/drm/exynos/Kconfig |3 +-
>>  drivers/gpu/drm/exynos/exynos_dp_core.c|   57 ++--
>>  drivers/gpu/drm/exynos/exynos_dp_core.h|1 +
>>  drivers/gpu/drm/msm/hdmi/hdmi_bridge.c |3 +-
>>  include/drm/bridge/ptn3460.h   |   37 ---
>>  include/drm/drm_crtc.h |   16 +-
>>  13 files changed, 147 insertions(+), 453 deletions(-)
>>  delete mode 100644 Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
>>  delete mode 100644 drivers/gpu/drm/bridge/ptn3460.c
>>  create mode 100644 drivers/gpu/drm/drm_bridge.c
>>  delete mode 100644 include/drm/bridge/ptn3460.h
>
> --
> Regards,
>
> Laurent Pinchart
>

[Bug 83461] hdmi screen flicker/unusable

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

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

--- Comment #6 from kb at spatium.org ---
I'll have to setup the enviro, it'll take some time. But yeah, I'll do it.

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

[PATCH 8/8] drm/nouveau: export reservation_object from dmabuf to ttm

[Maarten Lankhorst]

Adds an extra argument to nouveau_bo_new, which is only used in nouveau_prime.c.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/nouveau/dispnv04/crtc.c | 2 +-
 drivers/gpu/drm/nouveau/nouveau_bo.c| 4 ++--
 drivers/gpu/drm/nouveau/nouveau_bo.h| 1 +
 drivers/gpu/drm/nouveau/nouveau_chan.c  | 2 +-
 drivers/gpu/drm/nouveau/nouveau_fence.c | 6 +-
 drivers/gpu/drm/nouveau/nouveau_gem.c   | 2 +-
 drivers/gpu/drm/nouveau/nouveau_prime.c | 5 -
 drivers/gpu/drm/nouveau/nv17_fence.c| 2 +-
 drivers/gpu/drm/nouveau/nv50_display.c  | 6 +++---
 drivers/gpu/drm/nouveau/nv50_fence.c| 2 +-
 drivers/gpu/drm/nouveau/nv84_fence.c| 4 ++--
 11 files changed, 22 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c 
b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
index b90aa5c1f90a..fca6a1f9c20c 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
@@ -1127,7 +1127,7 @@ nv04_crtc_create(struct drm_device *dev, int crtc_num)
drm_mode_crtc_set_gamma_size(_crtc->base, 256);

ret = nouveau_bo_new(dev, 64*64*4, 0x100, TTM_PL_FLAG_VRAM,
-0, 0x, NULL, _crtc->cursor.nvbo);
+0, 0x, NULL, NULL, _crtc->cursor.nvbo);
if (!ret) {
ret = nouveau_bo_pin(nv_crtc->cursor.nvbo, TTM_PL_FLAG_VRAM);
if (!ret) {
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 7034cacaa4a1..3d474ac03f88 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -181,7 +181,7 @@ nouveau_bo_fixup_align(struct nouveau_bo *nvbo, u32 flags,
 int
 nouveau_bo_new(struct drm_device *dev, int size, int align,
   uint32_t flags, uint32_t tile_mode, uint32_t tile_flags,
-  struct sg_table *sg,
+  struct sg_table *sg, struct reservation_object *robj,
   struct nouveau_bo **pnvbo)
 {
struct nouveau_drm *drm = nouveau_drm(dev);
@@ -230,7 +230,7 @@ nouveau_bo_new(struct drm_device *dev, int size, int align,
ret = ttm_bo_init(>ttm.bdev, >bo, size,
  type, >placement,
  align >> PAGE_SHIFT, false, NULL, acc_size, sg,
- NULL, nouveau_bo_del_ttm);
+ robj, nouveau_bo_del_ttm);
if (ret) {
/* ttm will call nouveau_bo_del_ttm if it fails.. */
return ret;
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.h 
b/drivers/gpu/drm/nouveau/nouveau_bo.h
index ae95b2d43b36..d20c0b5c4e31 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.h
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.h
@@ -68,6 +68,7 @@ extern struct ttm_bo_driver nouveau_bo_driver;
 void nouveau_bo_move_init(struct nouveau_drm *);
 int  nouveau_bo_new(struct drm_device *, int size, int align, u32 flags,
u32 tile_mode, u32 tile_flags, struct sg_table *sg,
+   struct reservation_object *robj,
struct nouveau_bo **);
 int  nouveau_bo_pin(struct nouveau_bo *, u32 flags);
 int  nouveau_bo_unpin(struct nouveau_bo *);
diff --git a/drivers/gpu/drm/nouveau/nouveau_chan.c 
b/drivers/gpu/drm/nouveau/nouveau_chan.c
index 9a362ddd8225..977fb8f15d97 100644
--- a/drivers/gpu/drm/nouveau/nouveau_chan.c
+++ b/drivers/gpu/drm/nouveau/nouveau_chan.c
@@ -106,7 +106,7 @@ nouveau_channel_prep(struct nouveau_drm *drm, struct 
nvif_device *device,
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, 0, NULL, NULL,
>push.buffer);
if (ret == 0) {
ret = nouveau_bo_pin(chan->push.buffer, target);
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c 
b/drivers/gpu/drm/nouveau/nouveau_fence.c
index dfd0b9ed4195..affe3944e643 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
@@ -195,8 +195,12 @@ nouveau_fence_work(struct fence *fence,

work = kmalloc(sizeof(*work), GFP_KERNEL);
if (!work) {
+   /*
+* this might not be a nouveau fence any more,
+* so force a lazy wait here
+*/
WARN_ON(nouveau_fence_wait((struct nouveau_fence *)fence,
-  false, false));
+  true, false));
goto err;
}

diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c 
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index 3f693c1f5b36..36951ee4b157 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -165,7 +165,7 @@ nouveau_gem_new(struct drm_device *dev, int size, int 
align, uint32_t domain,
flags |= TTM_PL_FLAG_SYSTEM;

ret = nouveau_bo_new(dev, 

[PATCH 7/8] drm/radeon: export reservation_object from dmabuf to ttm

[Maarten Lankhorst]

Adds an extra argument to ttm_bo_create, which is only used in radeon_prime.c.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/radeon/cik.c  | 4 ++--
 drivers/gpu/drm/radeon/evergreen.c| 6 +++---
 drivers/gpu/drm/radeon/r600.c | 4 ++--
 drivers/gpu/drm/radeon/radeon_benchmark.c | 4 ++--
 drivers/gpu/drm/radeon/radeon_device.c| 2 +-
 drivers/gpu/drm/radeon/radeon_gart.c  | 2 +-
 drivers/gpu/drm/radeon/radeon_gem.c   | 2 +-
 drivers/gpu/drm/radeon/radeon_object.c| 8 +---
 drivers/gpu/drm/radeon/radeon_object.h| 1 +
 drivers/gpu/drm/radeon/radeon_prime.c | 5 -
 drivers/gpu/drm/radeon/radeon_ring.c  | 2 +-
 drivers/gpu/drm/radeon/radeon_sa.c| 2 +-
 drivers/gpu/drm/radeon/radeon_test.c  | 5 +++--
 drivers/gpu/drm/radeon/radeon_ttm.c   | 2 +-
 drivers/gpu/drm/radeon/radeon_uvd.c   | 3 ++-
 drivers/gpu/drm/radeon/radeon_vce.c   | 3 ++-
 drivers/gpu/drm/radeon/radeon_vm.c| 5 +++--
 17 files changed, 35 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index 1440b6e9281e..1f8484284b47 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -4690,7 +4690,7 @@ static int cik_mec_init(struct radeon_device *rdev)
r = radeon_bo_create(rdev,
 rdev->mec.num_mec *rdev->mec.num_pipe * 
MEC_HPD_SIZE * 2,
 PAGE_SIZE, true,
-RADEON_GEM_DOMAIN_GTT, 0, NULL,
+RADEON_GEM_DOMAIN_GTT, 0, NULL, NULL,
 >mec.hpd_eop_obj);
if (r) {
dev_warn(rdev->dev, "(%d) create HDP EOP bo failed\n", 
r);
@@ -4861,7 +4861,7 @@ static int cik_cp_compute_resume(struct radeon_device 
*rdev)
 sizeof(struct bonaire_mqd),
 PAGE_SIZE, true,
 RADEON_GEM_DOMAIN_GTT, 0, NULL,
->ring[idx].mqd_obj);
+NULL, >ring[idx].mqd_obj);
if (r) {
dev_warn(rdev->dev, "(%d) create MQD bo 
failed\n", r);
return r;
diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index dbca60c7d097..c6ccef6c3596 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -4023,7 +4023,7 @@ int sumo_rlc_init(struct radeon_device *rdev)
if (rdev->rlc.save_restore_obj == NULL) {
r = radeon_bo_create(rdev, dws * 4, PAGE_SIZE, true,
 RADEON_GEM_DOMAIN_VRAM, 0, NULL,
->rlc.save_restore_obj);
+NULL, >rlc.save_restore_obj);
if (r) {
dev_warn(rdev->dev, "(%d) create RLC sr bo 
failed\n", r);
return r;
@@ -4102,7 +4102,7 @@ int sumo_rlc_init(struct radeon_device *rdev)
if (rdev->rlc.clear_state_obj == NULL) {
r = radeon_bo_create(rdev, dws * 4, PAGE_SIZE, true,
 RADEON_GEM_DOMAIN_VRAM, 0, NULL,
->rlc.clear_state_obj);
+NULL, >rlc.clear_state_obj);
if (r) {
dev_warn(rdev->dev, "(%d) create RLC c bo 
failed\n", r);
sumo_rlc_fini(rdev);
@@ -4179,7 +4179,7 @@ int sumo_rlc_init(struct radeon_device *rdev)
r = radeon_bo_create(rdev, rdev->rlc.cp_table_size,
 PAGE_SIZE, true,
 RADEON_GEM_DOMAIN_VRAM, 0, NULL,
->rlc.cp_table_obj);
+NULL, >rlc.cp_table_obj);
if (r) {
dev_warn(rdev->dev, "(%d) create RLC cp table 
bo failed\n", r);
sumo_rlc_fini(rdev);
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 35c22ee9bc4a..a82eaa81cd07 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -1430,7 +1430,7 @@ int r600_vram_scratch_init(struct radeon_device *rdev)
if (rdev->vram_scratch.robj == NULL) {
r = radeon_bo_create(rdev, RADEON_GPU_PAGE_SIZE,
 PAGE_SIZE, true, RADEON_GEM_DOMAIN_VRAM,
-0, NULL, >vram_scratch.robj);
+0, NULL, NULL, >vram_scratch.robj);
 

[PATCH 6/8] drm/radeon: cope with foreign fences inside the reservation object

[Maarten Lankhorst]

Not the whole world is a radeon! :-)

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/radeon/cik.c  |  2 +-
 drivers/gpu/drm/radeon/cik_sdma.c |  2 +-
 drivers/gpu/drm/radeon/evergreen_dma.c|  2 +-
 drivers/gpu/drm/radeon/r600.c |  2 +-
 drivers/gpu/drm/radeon/r600_dma.c |  2 +-
 drivers/gpu/drm/radeon/radeon.h   |  7 ---
 drivers/gpu/drm/radeon/radeon_cs.c| 27 ---
 drivers/gpu/drm/radeon/radeon_fence.c |  3 +++
 drivers/gpu/drm/radeon/radeon_semaphore.c | 24 ++--
 drivers/gpu/drm/radeon/radeon_vm.c|  4 ++--
 drivers/gpu/drm/radeon/rv770_dma.c|  2 +-
 drivers/gpu/drm/radeon/si_dma.c   |  2 +-
 12 files changed, 54 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index 0d761f73a7fa..1440b6e9281e 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -3993,7 +3993,7 @@ struct radeon_fence *cik_copy_cpdma(struct radeon_device 
*rdev,
return ERR_PTR(r);
}

-   radeon_semaphore_sync_resv(sem, resv, false);
+   radeon_semaphore_sync_resv(rdev, sem, resv, false, false);
radeon_semaphore_sync_rings(rdev, sem, ring->idx);

for (i = 0; i < num_loops; i++) {
diff --git a/drivers/gpu/drm/radeon/cik_sdma.c 
b/drivers/gpu/drm/radeon/cik_sdma.c
index c01a6100c318..315c595418ec 100644
--- a/drivers/gpu/drm/radeon/cik_sdma.c
+++ b/drivers/gpu/drm/radeon/cik_sdma.c
@@ -571,7 +571,7 @@ struct radeon_fence *cik_copy_dma(struct radeon_device 
*rdev,
return ERR_PTR(r);
}

-   radeon_semaphore_sync_resv(sem, resv, false);
+   radeon_semaphore_sync_resv(rdev, sem, resv, false, false);
radeon_semaphore_sync_rings(rdev, sem, ring->idx);

for (i = 0; i < num_loops; i++) {
diff --git a/drivers/gpu/drm/radeon/evergreen_dma.c 
b/drivers/gpu/drm/radeon/evergreen_dma.c
index 946f37d0b469..5a5686792068 100644
--- a/drivers/gpu/drm/radeon/evergreen_dma.c
+++ b/drivers/gpu/drm/radeon/evergreen_dma.c
@@ -133,7 +133,7 @@ struct radeon_fence *evergreen_copy_dma(struct 
radeon_device *rdev,
return ERR_PTR(r);
}

-   radeon_semaphore_sync_resv(sem, resv, false);
+   radeon_semaphore_sync_resv(rdev, sem, resv, false, false);
radeon_semaphore_sync_rings(rdev, sem, ring->idx);

for (i = 0; i < num_loops; i++) {
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 25f367ac4637..35c22ee9bc4a 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -2912,7 +2912,7 @@ struct radeon_fence *r600_copy_cpdma(struct radeon_device 
*rdev,
return ERR_PTR(r);
}

-   radeon_semaphore_sync_resv(sem, resv, false);
+   radeon_semaphore_sync_resv(rdev, sem, resv, false, false);
radeon_semaphore_sync_rings(rdev, sem, ring->idx);

radeon_ring_write(ring, PACKET3(PACKET3_SET_CONFIG_REG, 1));
diff --git a/drivers/gpu/drm/radeon/r600_dma.c 
b/drivers/gpu/drm/radeon/r600_dma.c
index fc54224ce87b..674af8db7a35 100644
--- a/drivers/gpu/drm/radeon/r600_dma.c
+++ b/drivers/gpu/drm/radeon/r600_dma.c
@@ -470,7 +470,7 @@ struct radeon_fence *r600_copy_dma(struct radeon_device 
*rdev,
return ERR_PTR(r);
}

-   radeon_semaphore_sync_resv(sem, resv, false);
+   radeon_semaphore_sync_resv(rdev, sem, resv, false, false);
radeon_semaphore_sync_rings(rdev, sem, ring->idx);

for (i = 0; i < num_loops; i++) {
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 9aa75c1af4f4..6cdc5e62fe12 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -587,9 +587,10 @@ bool radeon_semaphore_emit_wait(struct radeon_device 
*rdev, int ring,
struct radeon_semaphore *semaphore);
 void radeon_semaphore_sync_fence(struct radeon_semaphore *semaphore,
 struct radeon_fence *fence);
-void radeon_semaphore_sync_resv(struct radeon_semaphore *semaphore,
-   struct reservation_object *resv,
-   bool shared);
+int radeon_semaphore_sync_resv(struct radeon_device *rdev,
+  struct radeon_semaphore *semaphore,
+  struct reservation_object *resv,
+  bool shared, bool intr);
 int radeon_semaphore_sync_rings(struct radeon_device *rdev,
struct radeon_semaphore *semaphore,
int waiting_ring);
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
b/drivers/gpu/drm/radeon/radeon_cs.c
index f662de41ba49..a4a608c8b1ba 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -249,20 +249,21 @@ static int radeon_cs_get_ring(struct radeon_cs_parser *p, 
u32 ring, 

[PATCH 5/8] drm/radeon: cope with foreign fences inside display

[Maarten Lankhorst]

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/radeon/radeon.h |  2 +-
 drivers/gpu/drm/radeon/radeon_display.c | 30 +++---
 2 files changed, 20 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 82b0e11ade89..9aa75c1af4f4 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -710,7 +710,7 @@ struct radeon_flip_work {
uint64_tbase;
struct drm_pending_vblank_event *event;
struct radeon_bo*old_rbo;
-   struct radeon_fence *fence;
+   struct fence*fence;
 };

 struct r500_irq_stat_regs {
diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
b/drivers/gpu/drm/radeon/radeon_display.c
index 4eb37976f879..00ead8c2758a 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -402,14 +402,21 @@ static void radeon_flip_work_func(struct work_struct 
*__work)

 down_read(>exclusive_lock);
if (work->fence) {
-   r = radeon_fence_wait(work->fence, false);
-   if (r == -EDEADLK) {
-   up_read(>exclusive_lock);
-   do {
-   r = radeon_gpu_reset(rdev);
-   } while (r == -EAGAIN);
-   down_read(>exclusive_lock);
-   }
+   struct radeon_fence *fence;
+
+   fence = to_radeon_fence(work->fence);
+   if (fence && fence->rdev == rdev) {
+   r = radeon_fence_wait(fence, false);
+   if (r == -EDEADLK) {
+   up_read(>exclusive_lock);
+   do {
+   r = radeon_gpu_reset(rdev);
+   } while (r == -EAGAIN);
+   down_read(>exclusive_lock);
+   }
+   } else
+   r = fence_wait(work->fence, false);
+
if (r)
DRM_ERROR("failed to wait on page flip fence (%d)!\n", 
r);

@@ -418,7 +425,8 @@ static void radeon_flip_work_func(struct work_struct 
*__work)
 * confused about which BO the CRTC is scanning out
 */

-   radeon_fence_unref(>fence);
+   fence_put(work->fence);
+   work->fence = NULL;
}

/* We borrow the event spin lock for protecting flip_status */
@@ -494,7 +502,7 @@ static int radeon_crtc_page_flip(struct drm_crtc *crtc,
DRM_ERROR("failed to pin new rbo buffer before flip\n");
goto cleanup;
}
-   work->fence = (struct radeon_fence 
*)fence_get(reservation_object_get_excl(new_rbo->tbo.resv));
+   work->fence = fence_get(reservation_object_get_excl(new_rbo->tbo.resv));
radeon_bo_get_tiling_flags(new_rbo, _flags, NULL);
radeon_bo_unreserve(new_rbo);

@@ -576,7 +584,7 @@ pflip_cleanup:

 cleanup:
drm_gem_object_unreference_unlocked(>old_rbo->gem_base);
-   radeon_fence_unref(>fence);
+   fence_put(work->fence);
kfree(work);
return r;
 }
-- 
2.0.4

[PATCH 4/8] drm/ttm: add reservation_object as argument to ttm_bo_init

[Maarten Lankhorst]

This allows importing reservation objects from dma-bufs.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/ast/ast_ttm.c|  2 +-
 drivers/gpu/drm/bochs/bochs_mm.c |  2 +-
 drivers/gpu/drm/cirrus/cirrus_ttm.c  |  2 +-
 drivers/gpu/drm/mgag200/mgag200_ttm.c|  2 +-
 drivers/gpu/drm/nouveau/nouveau_bo.c |  2 +-
 drivers/gpu/drm/qxl/qxl_object.c |  2 +-
 drivers/gpu/drm/radeon/radeon_object.c   |  2 +-
 drivers/gpu/drm/ttm/ttm_bo.c | 24 ++--
 drivers/gpu/drm/vmwgfx/vmwgfx_resource.c |  2 +-
 include/drm/ttm/ttm_bo_api.h |  2 ++
 10 files changed, 28 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_ttm.c b/drivers/gpu/drm/ast/ast_ttm.c
index 5098c7dd435c..a4c13040e32d 100644
--- a/drivers/gpu/drm/ast/ast_ttm.c
+++ b/drivers/gpu/drm/ast/ast_ttm.c
@@ -339,7 +339,7 @@ int ast_bo_create(struct drm_device *dev, int size, int 
align,
ret = ttm_bo_init(>ttm.bdev, >bo, size,
  ttm_bo_type_device, >placement,
  align >> PAGE_SHIFT, false, NULL, acc_size,
- NULL, ast_bo_ttm_destroy);
+ NULL, NULL, ast_bo_ttm_destroy);
if (ret)
return ret;

diff --git a/drivers/gpu/drm/bochs/bochs_mm.c b/drivers/gpu/drm/bochs/bochs_mm.c
index 2af30e7607d7..6c50a7a44864 100644
--- a/drivers/gpu/drm/bochs/bochs_mm.c
+++ b/drivers/gpu/drm/bochs/bochs_mm.c
@@ -377,7 +377,7 @@ static int bochs_bo_create(struct drm_device *dev, int 
size, int align,
ret = ttm_bo_init(>ttm.bdev, >bo, size,
  ttm_bo_type_device, >placement,
  align >> PAGE_SHIFT, false, NULL, acc_size,
- NULL, bochs_bo_ttm_destroy);
+ NULL, NULL, bochs_bo_ttm_destroy);
if (ret)
return ret;

diff --git a/drivers/gpu/drm/cirrus/cirrus_ttm.c 
b/drivers/gpu/drm/cirrus/cirrus_ttm.c
index 3e7d758330a9..b3b3d16d1279 100644
--- a/drivers/gpu/drm/cirrus/cirrus_ttm.c
+++ b/drivers/gpu/drm/cirrus/cirrus_ttm.c
@@ -343,7 +343,7 @@ int cirrus_bo_create(struct drm_device *dev, int size, int 
align,
ret = ttm_bo_init(>ttm.bdev, >bo, size,
  ttm_bo_type_device, >placement,
  align >> PAGE_SHIFT, false, NULL, acc_size,
- NULL, cirrus_bo_ttm_destroy);
+ NULL, NULL, cirrus_bo_ttm_destroy);
if (ret)
return ret;

diff --git a/drivers/gpu/drm/mgag200/mgag200_ttm.c 
b/drivers/gpu/drm/mgag200/mgag200_ttm.c
index be883ef5a1d3..398b6fb161a6 100644
--- a/drivers/gpu/drm/mgag200/mgag200_ttm.c
+++ b/drivers/gpu/drm/mgag200/mgag200_ttm.c
@@ -339,7 +339,7 @@ int mgag200_bo_create(struct drm_device *dev, int size, int 
align,
ret = ttm_bo_init(>ttm.bdev, >bo, size,
  ttm_bo_type_device, >placement,
  align >> PAGE_SHIFT, false, NULL, acc_size,
- NULL, mgag200_bo_ttm_destroy);
+ NULL, NULL, mgag200_bo_ttm_destroy);
if (ret)
return ret;

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 049f5de90928..7034cacaa4a1 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -230,7 +230,7 @@ nouveau_bo_new(struct drm_device *dev, int size, int align,
ret = ttm_bo_init(>ttm.bdev, >bo, size,
  type, >placement,
  align >> PAGE_SHIFT, false, NULL, acc_size, sg,
- nouveau_bo_del_ttm);
+ NULL, nouveau_bo_del_ttm);
if (ret) {
/* ttm will call nouveau_bo_del_ttm if it fails.. */
return ret;
diff --git a/drivers/gpu/drm/qxl/qxl_object.c b/drivers/gpu/drm/qxl/qxl_object.c
index 69c104c3240f..cdeaf08fdc74 100644
--- a/drivers/gpu/drm/qxl/qxl_object.c
+++ b/drivers/gpu/drm/qxl/qxl_object.c
@@ -110,7 +110,7 @@ int qxl_bo_create(struct qxl_device *qdev,

r = ttm_bo_init(>mman.bdev, >tbo, size, type,
>placement, 0, !kernel, NULL, size,
-   NULL, _ttm_bo_destroy);
+   NULL, NULL, _ttm_bo_destroy);
if (unlikely(r != 0)) {
if (r != -ERESTARTSYS)
dev_err(qdev->dev,
diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
b/drivers/gpu/drm/radeon/radeon_object.c
index 8abee5fa93bd..0e82f0223fd4 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -216,7 +216,7 @@ int radeon_bo_create(struct radeon_device *rdev,
down_read(>pm.mclk_lock);
r = ttm_bo_init(>mman.bdev, >tbo, size, type,
>placement, page_align, !kernel, NULL,
-   acc_size, sg, _ttm_bo_destroy);
+   

[PATCH 3/8] drm: Pass dma-buf as argument to gem_prime_import_sg_table

[Maarten Lankhorst]

Allows importing dma_reservation_objects from a dma-buf.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/drm_gem_cma_helper.c| 5 +++--
 drivers/gpu/drm/drm_prime.c | 2 +-
 drivers/gpu/drm/msm/msm_drv.h   | 2 +-
 drivers/gpu/drm/msm/msm_gem_prime.c | 4 ++--
 drivers/gpu/drm/nouveau/nouveau_gem.h   | 2 +-
 drivers/gpu/drm/nouveau/nouveau_prime.c | 5 +++--
 drivers/gpu/drm/qxl/qxl_drv.h   | 2 +-
 drivers/gpu/drm/qxl/qxl_prime.c | 2 +-
 drivers/gpu/drm/radeon/radeon_drv.c | 2 +-
 drivers/gpu/drm/radeon/radeon_prime.c   | 5 +++--
 include/drm/drmP.h  | 3 ++-
 include/drm/drm_gem_cma_helper.h| 3 ++-
 12 files changed, 21 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c 
b/drivers/gpu/drm/drm_gem_cma_helper.c
index e467e67af6e7..08646af2ddc2 100644
--- a/drivers/gpu/drm/drm_gem_cma_helper.c
+++ b/drivers/gpu/drm/drm_gem_cma_helper.c
@@ -316,7 +316,8 @@ out:
 EXPORT_SYMBOL_GPL(drm_gem_cma_prime_get_sg_table);

 struct drm_gem_object *
-drm_gem_cma_prime_import_sg_table(struct drm_device *dev, size_t size,
+drm_gem_cma_prime_import_sg_table(struct drm_device *dev,
+ struct dma_buf_attachment *attach,
  struct sg_table *sgt)
 {
struct drm_gem_cma_object *cma_obj;
@@ -325,7 +326,7 @@ drm_gem_cma_prime_import_sg_table(struct drm_device *dev, 
size_t size,
return ERR_PTR(-EINVAL);

/* Create a CMA GEM buffer. */
-   cma_obj = __drm_gem_cma_create(dev, size);
+   cma_obj = __drm_gem_cma_create(dev, attach->dmabuf->size);
if (IS_ERR(cma_obj))
return ERR_CAST(cma_obj);

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 2807a771f505..8952dc779959 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -523,7 +523,7 @@ struct drm_gem_object *drm_gem_prime_import(struct 
drm_device *dev,
goto fail_detach;
}

-   obj = dev->driver->gem_prime_import_sg_table(dev, dma_buf->size, sgt);
+   obj = dev->driver->gem_prime_import_sg_table(dev, attach, sgt);
if (IS_ERR(obj)) {
ret = PTR_ERR(obj);
goto fail_unmap;
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index 8a2c5fd0893e..a0dc2592ffc1 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -170,7 +170,7 @@ struct sg_table *msm_gem_prime_get_sg_table(struct 
drm_gem_object *obj);
 void *msm_gem_prime_vmap(struct drm_gem_object *obj);
 void msm_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr);
 struct drm_gem_object *msm_gem_prime_import_sg_table(struct drm_device *dev,
-   size_t size, struct sg_table *sg);
+   struct dma_buf_attachment *attach, struct sg_table *sg);
 int msm_gem_prime_pin(struct drm_gem_object *obj);
 void msm_gem_prime_unpin(struct drm_gem_object *obj);
 void *msm_gem_vaddr_locked(struct drm_gem_object *obj);
diff --git a/drivers/gpu/drm/msm/msm_gem_prime.c 
b/drivers/gpu/drm/msm/msm_gem_prime.c
index d48f9fc5129b..b75f9940ee9e 100644
--- a/drivers/gpu/drm/msm/msm_gem_prime.c
+++ b/drivers/gpu/drm/msm/msm_gem_prime.c
@@ -37,9 +37,9 @@ void msm_gem_prime_vunmap(struct drm_gem_object *obj, void 
*vaddr)
 }

 struct drm_gem_object *msm_gem_prime_import_sg_table(struct drm_device *dev,
-   size_t size, struct sg_table *sg)
+   struct dma_buf_attachment *attach, struct sg_table *sg)
 {
-   return msm_gem_import(dev, size, sg);
+   return msm_gem_import(dev, attach->dmabuf->size, sg);
 }

 int msm_gem_prime_pin(struct drm_gem_object *obj)
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.h 
b/drivers/gpu/drm/nouveau/nouveau_gem.h
index ddab762d81fe..e4049faca780 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.h
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.h
@@ -39,7 +39,7 @@ struct reservation_object *nouveau_gem_prime_res_obj(struct 
drm_gem_object *);
 extern void nouveau_gem_prime_unpin(struct drm_gem_object *);
 extern struct sg_table *nouveau_gem_prime_get_sg_table(struct drm_gem_object 
*);
 extern struct drm_gem_object *nouveau_gem_prime_import_sg_table(
-   struct drm_device *, size_t size, struct sg_table *);
+   struct drm_device *, struct dma_buf_attachment *, struct sg_table *);
 extern void *nouveau_gem_prime_vmap(struct drm_gem_object *);
 extern void nouveau_gem_prime_vunmap(struct drm_gem_object *, void *);

diff --git a/drivers/gpu/drm/nouveau/nouveau_prime.c 
b/drivers/gpu/drm/nouveau/nouveau_prime.c
index 1f51008e4d26..2215cdba587d 100644
--- a/drivers/gpu/drm/nouveau/nouveau_prime.c
+++ b/drivers/gpu/drm/nouveau/nouveau_prime.c
@@ -23,6 +23,7 @@
  */

 #include 
+#include 

 #include "nouveau_drm.h"
 #include "nouveau_gem.h"
@@ -56,7 +57,7 @@ void nouveau_gem_prime_vunmap(struct drm_gem_object *obj, 
void *vaddr)
 }

 struct drm_gem_object 

[PATCH 2/8] drm/nouveau: specify if interruptible wait is desired in nouveau_fence_sync

[Maarten Lankhorst]

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/nouveau/nouveau_bo.c  |  2 +-
 drivers/gpu/drm/nouveau/nouveau_display.c |  4 ++--
 drivers/gpu/drm/nouveau/nouveau_fence.c   | 14 ++
 drivers/gpu/drm/nouveau/nouveau_fence.h   |  2 +-
 drivers/gpu/drm/nouveau/nouveau_gem.c |  2 +-
 5 files changed, 11 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index eea74b127b03..049f5de90928 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -970,7 +970,7 @@ nouveau_bo_move_m2mf(struct ttm_buffer_object *bo, int 
evict, bool intr,
}

mutex_lock_nested(>mutex, SINGLE_DEPTH_NESTING);
-   ret = nouveau_fence_sync(nouveau_bo(bo), chan, true);
+   ret = nouveau_fence_sync(nouveau_bo(bo), chan, true, intr);
if (ret == 0) {
ret = drm->ttm.move(chan, bo, >mem, new_mem);
if (ret == 0) {
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c 
b/drivers/gpu/drm/nouveau/nouveau_display.c
index 6d0a3cdc752b..334db3c6e40c 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -658,7 +658,7 @@ nouveau_page_flip_emit(struct nouveau_channel *chan,
spin_unlock_irqrestore(>event_lock, flags);

/* Synchronize with the old framebuffer */
-   ret = nouveau_fence_sync(old_bo, chan, false);
+   ret = nouveau_fence_sync(old_bo, chan, false, false);
if (ret)
goto fail;

@@ -722,7 +722,7 @@ nouveau_crtc_page_flip(struct drm_crtc *crtc, struct 
drm_framebuffer *fb,
goto fail_unpin;

/* synchronise rendering channel with the kernel's channel */
-   ret = nouveau_fence_sync(new_bo, chan, false);
+   ret = nouveau_fence_sync(new_bo, chan, false, true);
if (ret) {
ttm_bo_unreserve(_bo->bo);
goto fail_unpin;
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c 
b/drivers/gpu/drm/nouveau/nouveau_fence.c
index decfe6c4ac07..dfd0b9ed4195 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
@@ -226,12 +226,10 @@ nouveau_fence_emit(struct nouveau_fence *fence, struct 
nouveau_channel *chan)

if (priv->uevent)
fence_init(>base, _fence_ops_uevent,
-  >lock,
-  priv->context_base + chan->chid, ++fctx->sequence);
+  >lock, fctx->context, ++fctx->sequence);
else
fence_init(>base, _fence_ops_legacy,
-  >lock,
-  priv->context_base + chan->chid, ++fctx->sequence);
+  >lock, fctx->context, ++fctx->sequence);

trace_fence_emit(>base);
ret = fctx->emit(fence);
@@ -342,7 +340,7 @@ nouveau_fence_wait(struct nouveau_fence *fence, bool lazy, 
bool intr)
 }

 int
-nouveau_fence_sync(struct nouveau_bo *nvbo, struct nouveau_channel *chan, bool 
exclusive)
+nouveau_fence_sync(struct nouveau_bo *nvbo, struct nouveau_channel *chan, bool 
exclusive, bool intr)
 {
struct nouveau_fence_chan *fctx = chan->fence;
struct fence *fence;
@@ -369,7 +367,7 @@ nouveau_fence_sync(struct nouveau_bo *nvbo, struct 
nouveau_channel *chan, bool e
prev = f->channel;

if (!prev || (prev != chan && (ret = fctx->sync(f, prev, 
chan
-   ret = fence_wait(fence, true);
+   ret = fence_wait(fence, intr);

return ret;
}
@@ -387,8 +385,8 @@ nouveau_fence_sync(struct nouveau_bo *nvbo, struct 
nouveau_channel *chan, bool e
if (f)
prev = f->channel;

-   if (!prev || (ret = fctx->sync(f, prev, chan)))
-   ret = fence_wait(fence, true);
+   if (!prev || (prev != chan && (ret = fctx->sync(f, prev, 
chan
+   ret = fence_wait(fence, intr);

if (ret)
break;
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.h 
b/drivers/gpu/drm/nouveau/nouveau_fence.h
index 986c8135e564..a7dc5375c320 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.h
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.h
@@ -26,7 +26,7 @@ int  nouveau_fence_emit(struct nouveau_fence *, struct 
nouveau_channel *);
 bool nouveau_fence_done(struct nouveau_fence *);
 void nouveau_fence_work(struct fence *, void (*)(void *), void *);
 int  nouveau_fence_wait(struct nouveau_fence *, bool lazy, bool intr);
-int  nouveau_fence_sync(struct nouveau_bo *, struct nouveau_channel *, bool 
exclusive);
+int  nouveau_fence_sync(struct nouveau_bo *, struct nouveau_channel *, bool 
exclusive, bool intr);

 struct nouveau_fence_chan {
spinlock_t lock;
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c 
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index 

[PATCH 1/8] drm/nouveau: bump driver patchlevel to 1.2.1

[Maarten Lankhorst]

Allows userspace to detect shared fences are supported.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/nouveau/nouveau_drm.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.h 
b/drivers/gpu/drm/nouveau/nouveau_drm.h
index b02b02452c85..8ae36f265fb8 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.h
@@ -10,7 +10,7 @@

 #define DRIVER_MAJOR   1
 #define DRIVER_MINOR   2
-#define DRIVER_PATCHLEVEL  0
+#define DRIVER_PATCHLEVEL  1

 /*
  * 1.1.1:
@@ -26,6 +26,8 @@
  * 1.2.0:
  * - object api exposed to userspace
  * - fermi,kepler,maxwell zbc
+ * 1.2.1:
+ *  - allow concurrent access to bo's mapped read/write.
  */

 #include 
-- 
2.0.4

[PATCH 00/10] drm fence fixes and cross-dev sync.

[Maarten Lankhorst]

This has a nouveau fix for suspend (no interruptible wait during suspend) and
bumps patchlevel to abi 1.2.1 for telling shared fences are in use.

Maarten Lankhorst (8):
  drm/nouveau: bump driver patchlevel to 1.2.1
  drm/nouveau: specify if interruptible wait is desired in
nouveau_fence_sync
  drm: Pass dma-buf as argument to gem_prime_import_sg_table
  drm/ttm: add reservation_object as argument to ttm_bo_init
  drm/radeon: cope with foreign fences inside display
  drm/radeon: cope with foreign fences inside the reservation object
  drm/radeon: export reservation_object from dmabuf to ttm
  drm/nouveau: export reservation_object from dmabuf to ttm

 drivers/gpu/drm/ast/ast_ttm.c |  2 +-
 drivers/gpu/drm/bochs/bochs_mm.c  |  2 +-
 drivers/gpu/drm/cirrus/cirrus_ttm.c   |  2 +-
 drivers/gpu/drm/drm_gem_cma_helper.c  |  5 +++--
 drivers/gpu/drm/drm_prime.c   |  2 +-
 drivers/gpu/drm/mgag200/mgag200_ttm.c |  2 +-
 drivers/gpu/drm/msm/msm_drv.h |  2 +-
 drivers/gpu/drm/msm/msm_gem_prime.c   |  4 ++--
 drivers/gpu/drm/nouveau/dispnv04/crtc.c   |  2 +-
 drivers/gpu/drm/nouveau/nouveau_bo.c  |  6 +++---
 drivers/gpu/drm/nouveau/nouveau_bo.h  |  1 +
 drivers/gpu/drm/nouveau/nouveau_chan.c|  2 +-
 drivers/gpu/drm/nouveau/nouveau_display.c |  4 ++--
 drivers/gpu/drm/nouveau/nouveau_drm.h |  4 +++-
 drivers/gpu/drm/nouveau/nouveau_fence.c   | 20 +++-
 drivers/gpu/drm/nouveau/nouveau_fence.h   |  2 +-
 drivers/gpu/drm/nouveau/nouveau_gem.c |  4 ++--
 drivers/gpu/drm/nouveau/nouveau_gem.h |  2 +-
 drivers/gpu/drm/nouveau/nouveau_prime.c   | 10 +++---
 drivers/gpu/drm/nouveau/nv17_fence.c  |  2 +-
 drivers/gpu/drm/nouveau/nv50_display.c|  6 +++---
 drivers/gpu/drm/nouveau/nv50_fence.c  |  2 +-
 drivers/gpu/drm/nouveau/nv84_fence.c  |  4 ++--
 drivers/gpu/drm/qxl/qxl_drv.h |  2 +-
 drivers/gpu/drm/qxl/qxl_object.c  |  2 +-
 drivers/gpu/drm/qxl/qxl_prime.c   |  2 +-
 drivers/gpu/drm/radeon/cik.c  |  6 +++---
 drivers/gpu/drm/radeon/cik_sdma.c |  2 +-
 drivers/gpu/drm/radeon/evergreen.c|  6 +++---
 drivers/gpu/drm/radeon/evergreen_dma.c|  2 +-
 drivers/gpu/drm/radeon/r600.c |  6 +++---
 drivers/gpu/drm/radeon/r600_dma.c |  2 +-
 drivers/gpu/drm/radeon/radeon.h   |  9 +
 drivers/gpu/drm/radeon/radeon_benchmark.c |  4 ++--
 drivers/gpu/drm/radeon/radeon_cs.c| 27 ---
 drivers/gpu/drm/radeon/radeon_device.c|  2 +-
 drivers/gpu/drm/radeon/radeon_display.c   | 30 +++---
 drivers/gpu/drm/radeon/radeon_drv.c   |  2 +-
 drivers/gpu/drm/radeon/radeon_fence.c |  3 +++
 drivers/gpu/drm/radeon/radeon_gart.c  |  2 +-
 drivers/gpu/drm/radeon/radeon_gem.c   |  2 +-
 drivers/gpu/drm/radeon/radeon_object.c|  8 +---
 drivers/gpu/drm/radeon/radeon_object.h|  1 +
 drivers/gpu/drm/radeon/radeon_prime.c | 10 +++---
 drivers/gpu/drm/radeon/radeon_ring.c  |  2 +-
 drivers/gpu/drm/radeon/radeon_sa.c|  2 +-
 drivers/gpu/drm/radeon/radeon_semaphore.c | 24 ++--
 drivers/gpu/drm/radeon/radeon_test.c  |  5 +++--
 drivers/gpu/drm/radeon/radeon_ttm.c   |  2 +-
 drivers/gpu/drm/radeon/radeon_uvd.c   |  3 ++-
 drivers/gpu/drm/radeon/radeon_vce.c   |  3 ++-
 drivers/gpu/drm/radeon/radeon_vm.c|  9 +
 drivers/gpu/drm/radeon/rv770_dma.c|  2 +-
 drivers/gpu/drm/radeon/si_dma.c   |  2 +-
 drivers/gpu/drm/ttm/ttm_bo.c  | 24 ++--
 drivers/gpu/drm/vmwgfx/vmwgfx_resource.c  |  2 +-
 include/drm/drmP.h|  3 ++-
 include/drm/drm_gem_cma_helper.h  |  3 ++-
 include/drm/ttm/ttm_bo_api.h  |  2 ++
 59 files changed, 192 insertions(+), 118 deletions(-)

-- 
2.0.4

[Bug 83998] Oopses on R9270X using UVD since radeon/uvd: use PIPE_USAGE_STAGING for msg buffers

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

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

--- Comment #2 from Andy Furniss  ---
Created attachment 106434
  --> https://bugs.freedesktop.org/attachment.cgi?id=106434=edit
oom-killer uvd

-- 
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/20140917/d4db5d06/attachment.html>

[Bug 83998] Oopses on R9270X using UVD since radeon/uvd: use PIPE_USAGE_STAGING for msg buffers

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

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

--- Comment #1 from Andy Furniss  ---
Created attachment 106433
  --> https://bugs.freedesktop.org/attachment.cgi?id=106433=edit
Oops uvd

-- 
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/20140917/944b77b5/attachment.html>

[Bug 83996] [drm:r100_ring_test] *ERROR* radeon: ring test failed - since linux-3.17_rc1 on RS690/RS740 [Radeon 2100]

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

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

--- Comment #1 from Christian K?nig  ---
Created attachment 106432
  --> https://bugs.freedesktop.org/attachment.cgi?id=106432=edit
Test for reverting the patch in question.

It's unlikely that the patch you mentioned causes such problems, but the patch
directly before this one could.

The attached patch (on top of Alex drm-fixes-3.17 branch) reverts this patch
and adds a few extra debug log lines.

So please test and report back with a new dmesg log.

-- 
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/20140917/f66257ac/attachment.html>

[Bug 83998] New: Oopses on R9270X using UVD since radeon/uvd: use PIPE_USAGE_STAGING for msg buffers

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

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

  Priority: medium
Bug ID: 83998
  Assignee: dri-devel at lists.freedesktop.org
   Summary: Oopses on R9270X using UVD since radeon/uvd: use
PIPE_USAGE_STAGING for msg buffers
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: adf.lists at gmail.com
  Hardware: Other
Status: NEW
   Version: git
 Component: Drivers/Gallium/radeonsi
   Product: Mesa

R9270X Getting rareish Oopses and once oomkiller since -

commit 6327b584155d040ae089e65fd6747186bdd9666b
Author: Christian K?nig 
Date:   Thu Sep 11 09:50:00 2014 +0200

radeon/uvd: use PIPE_USAGE_STAGING for msg buffers

That better matches the actual userspace use case, the
kernel will force it to VRAM if the hardware requires it.

To trigger this I need to repeatedly start mplayer using uvd - it's takes some
time, I ended up making a script to do it for me while AFK.

I am 99% sure the above is it - I spent a day and a half trying on the commit
before (radeon/video: use the hw to initial clear the buffers) with no crash.

The Oopses don't mention radeon or uvd.

They will hit as soon as mplayer launches before it renders anything - screen
locked, no mouse cursor or vt switch but SysRq works, box is still up in some
ways for a while (one time I had music playing for 30s-1min after).

One time oomkiller put on its blindfold and ran around killing :-)

-- 
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/20140917/0d4218d7/attachment.html>

rockchip and atmel kms drivers

[yaozq]

Hi Boris & Dave,
I will update the rockchip drm driver soon, we have many change about it.

thanks.
On 2014?09?17? 13:41, Boris BREZILLON wrote:
> Hi Dave,
>
> On Wed, 17 Sep 2014 11:18:44 +1000
> Dave Airlie  wrote:
>
>> Hey,
>>
>> So I notice we have two unreviewed drivers outstanding, the atmel
>> hlcdc and the rockchips one, I'd like to suggest they you guys review
>> each others work, they should be quite close in terms of functionality
>> and you might spot some problems in your own code from reading the
>> other driver.
> Sure, I'll review the rockchip driver.
>
>> I'm also hoping regular review will happen as well, but I think more
>> cross-review is probably a good thing for new driver writers.
> One more point, as stated in my cover letter, the HLCDC driver depends
> on 2 other series ([1] and [2]), which I proposed after discussing it
> with other KMS developers (Rob, Laurent and Thierry).
>
> Could you take a look at these ones ?
>
> Best Regards,
>
> Boris
>
> [1]http://lkml.iu.edu/hypermail/linux/kernel/1407.1/04171.html
> [2]http://www.spinics.net/lists/kernel/msg1791681.html
>

[Bug 83800] 3DMark2003 crashes radeon with wine 1.7.26 + gallium nine

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

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

--- Comment #11 from darkbasic  ---
Even if I use linux apitrace and vanilla wine (not nine) it doesn't work:

apitrace trace wine Tropics.exe -video_app opengl -sound_app openal
-video_fullscreen 1 -video_mode -1 -video_width 1280 -video_height 1024
-data_path ./ -engine_config data/unigine.cfg -system_script
tropics/unigine.cpp -extern_define RELEASE

On the contrary if I use apitrace with a native app (for example apitrace trace
xonotic-sdl) it works flawlessly. Any idea?

-- 
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/20140917/36b276de/attachment.html>

[Bug 82588] X fails to start with linus-tip or drm-next

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

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

--- Comment #26 from jospezial  ---
My bug now at https://bugs.freedesktop.org/show_bug.cgi?id=83996

-- 
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/20140917/ba3149d1/attachment.html>

[Bug 83996] New: [drm:r100_ring_test] *ERROR* radeon: ring test failed - since linux-3.17_rc1 on RS690/RS740 [Radeon 2100]

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

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

  Priority: medium
Bug ID: 83996
  Assignee: dri-devel at lists.freedesktop.org
   Summary: [drm:r100_ring_test] *ERROR* radeon: ring test failed
- since linux-3.17_rc1 on RS690/RS740 [Radeon 2100]
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: jospezial at gmx.de
  Hardware: Other
Status: NEW
   Version: DRI CVS
 Component: DRM/Radeon
   Product: DRI

This bug report is a fork of https://bugs.freedesktop.org/show_bug.cgi?id=82588


This do I get on a AMD64 Gentoo linux with xf86-video-ati-7.4.0 since
linux-3.17_rc1.
X starts but GPU acceleration is disabled.

[6.787592] [drm] Initialized drm 1.1.0 20060810
[7.007890] [drm] radeon kernel modesetting enabled.
[7.008441] [drm] initializing kernel modesetting (RS740 0x1002:0x796E
0x105B:0x0E13).
[7.008456] [drm] register mmio base: 0xFEAF
[7.008457] [drm] register mmio size: 65536
[7.009087] ATOM BIOS: ATI
[7.009102] radeon :01:05.0: VRAM: 128M 0x3800 -
0x3FFF (128M used)
[7.009104] radeon :01:05.0: GTT: 512M 0x4000 -
0x5FFF
[7.009117] [drm] Detected VRAM RAM=128M, BAR=128M
[7.009118] [drm] RAM width 128bits DDR
[7.009204] [TTM] Zone  kernel: Available graphics memory: 443784 kiB
[7.009206] [TTM] Initializing pool allocator
[7.009212] [TTM] Initializing DMA pool allocator
[7.009235] [drm] radeon: 128M of VRAM memory ready
[7.009236] [drm] radeon: 512M of GTT memory ready.
[7.009251] [drm] GART: num cpu pages 131072, num gpu pages 131072
[7.025657] [drm] radeon: 1 quad pipes, 1 z pipes initialized.
[7.025670] [drm] PCIE GART of 512M enabled (table at 0x32F0).
[7.025726] radeon :01:05.0: WB enabled
[7.025730] radeon :01:05.0: fence driver on ring 0 use gpu addr
0x4000 and cpu addr 0x880032ea5000
[7.025733] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[7.025734] [drm] Driver supports precise vblank timestamp query.
[7.025744] [drm] radeon: irq initialized.
[7.025753] [drm] Loading RS690/RS740 Microcode
[7.071137] [drm] radeon: ring at 0x40001000
[7.228868] [drm:r100_ring_test] *ERROR* radeon: ring test failed
(scratch(0x15E4)=0xCAFEDEAD)
[7.228875] [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22).
[7.228883] radeon :01:05.0: failed initializing CP (-22).
[7.22] radeon :01:05.0: Disabling GPU acceleration
[7.375499] [drm:r100_cp_fini] *ERROR* Wait for CP idle timeout, shutting
down CP.
[7.521222] Failed to wait GUI idle while programming pipes. Bad things
might happen.
[7.521467] [drm] radeon: cp finalized

With linux-3.16.x it works.
lspci:
01:05.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RS740
[Radeon 2100]


some messages from Xorg.log:

[24.729] (--) RADEON(0): Chipset: "ATI RS740" (ChipID = 0x796e)
[24.729] (II) RADEON(0): GPU accel disabled or not working, using shadowfb
for KMS

[24.869] (WW) RADEON(0): Direct rendering disabled
[24.869] (II) RADEON(0): Acceleration disabled

[24.871] (WW) RADEON(0): Option "AccelMethod" is not used

[24.879] (II) AIGLX: Screen 0 is not DRI2 capable
[24.879] (EE) AIGLX: reverting to software rendering
[25.578] (II) AIGLX: Loaded and initialized swrast
[25.578] (II) GLX: Initialized DRISWRAST GL provider for screen 0



Result of bisecting between v3.16 and v3.17-rc1:

77497f2735ad6e29c55475e15e9790dbfa2c2ef8 is the first bad commit
commit 77497f2735ad6e29c55475e15e9790dbfa2c2ef8
Author: Michel D?nzer 
Date:   Thu Jul 17 19:01:07 2014 +0900

drm/radeon: Pass GART page flags to radeon_gart_set_page() explicitly

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

:04 04 7da27ed892f4ea02ef8e758eda7165ce336d19cc
369d9e0ff185b6e6c9614de87296fc60072f56b9 M  drivers
:04 04 c3203bef4546e1781ba218fa5232c12cd2a883a2
b655879d0fefad7b591333930fddfd3cc67afa8d M  include

Reverting that whole patch on v3.17-rc5 is not as easy because then compile
fails.

-- 
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/20140917/7f720f58/attachment-0001.html>

[PATCH] intel: Don't leak the test page in an has_userptr() error path

[Damien Lespiau]

When handling the error on GEM_CLOSE, we weren't freeing the allocated
page. Plug that.

Signed-off-by: Damien Lespiau 
---
 intel/intel_bufmgr_gem.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index f378e5c..ce35bd4 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -3383,9 +3383,8 @@ retry:

close_bo.handle = userptr.handle;
ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_GEM_CLOSE, _bo);
-   if (ret == 0) {
-   free(ptr);
-   } else {
+   free(ptr);
+   if (ret) {
fprintf(stderr, "Failed to release test userptr object! (%d) "
"i915 kernel driver may not be sane!\n", errno);
return false;
-- 
1.8.3.1

[PATCH] drm/radeon: fix AGP userptr handling

[Alex Deucher]

On Wed, Sep 17, 2014 at 6:00 AM, Christian K?nig
 wrote:
> From: Christian K?nig 
>
> AGP mappings are not cache coherent, so userptr support
> won't work. Additional to that the AGP implementation uses
> a different ttm_tt container structure so we run into
> problems if we cast the pointer without checking if it's
> the right type.
>
> Signed-off-by: Christian K?nig 

Applied to my 3.18 tree.  thanks!

Alex

> ---
>  drivers/gpu/drm/radeon/radeon_ttm.c | 21 ++---
>  1 file changed, 14 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
> b/drivers/gpu/drm/radeon/radeon_ttm.c
> index eca2ce6..d73ea9c 100644
> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> @@ -675,10 +675,17 @@ static struct ttm_tt *radeon_ttm_tt_create(struct 
> ttm_bo_device *bdev,
> return >ttm.ttm;
>  }
>
> +static struct radeon_ttm_tt *radeon_ttm_tt_to_gtt(struct ttm_tt *ttm)
> +{
> +   if (!ttm || ttm->func != _backend_func)
> +   return NULL;
> +   return (struct radeon_ttm_tt *)ttm;
> +}
> +
>  static int radeon_ttm_tt_populate(struct ttm_tt *ttm)
>  {
> +   struct radeon_ttm_tt *gtt = radeon_ttm_tt_to_gtt(ttm);
> struct radeon_device *rdev;
> -   struct radeon_ttm_tt *gtt = (void *)ttm;
> unsigned i;
> int r;
> bool slave = !!(ttm->page_flags & TTM_PAGE_FLAG_SG);
> @@ -686,7 +693,7 @@ static int radeon_ttm_tt_populate(struct ttm_tt *ttm)
> if (ttm->state != tt_unpopulated)
> return 0;
>
> -   if (gtt->userptr) {
> +   if (gtt && gtt->userptr) {
> ttm->sg = kcalloc(1, sizeof(struct sg_table), GFP_KERNEL);
> if (!ttm->sg)
> return -ENOMEM;
> @@ -741,11 +748,11 @@ static int radeon_ttm_tt_populate(struct ttm_tt *ttm)
>  static void radeon_ttm_tt_unpopulate(struct ttm_tt *ttm)
>  {
> struct radeon_device *rdev;
> -   struct radeon_ttm_tt *gtt = (void *)ttm;
> +   struct radeon_ttm_tt *gtt = radeon_ttm_tt_to_gtt(ttm);
> unsigned i;
> bool slave = !!(ttm->page_flags & TTM_PAGE_FLAG_SG);
>
> -   if (gtt->userptr) {
> +   if (gtt && gtt->userptr) {
> kfree(ttm->sg);
> ttm->page_flags &= ~TTM_PAGE_FLAG_SG;
> return;
> @@ -782,7 +789,7 @@ static void radeon_ttm_tt_unpopulate(struct ttm_tt *ttm)
>  int radeon_ttm_tt_set_userptr(struct ttm_tt *ttm, uint64_t addr,
>   uint32_t flags)
>  {
> -   struct radeon_ttm_tt *gtt = (void *)ttm;
> +   struct radeon_ttm_tt *gtt = radeon_ttm_tt_to_gtt(ttm);
>
> if (gtt == NULL)
> return -EINVAL;
> @@ -795,7 +802,7 @@ int radeon_ttm_tt_set_userptr(struct ttm_tt *ttm, 
> uint64_t addr,
>
>  bool radeon_ttm_tt_has_userptr(struct ttm_tt *ttm)
>  {
> -   struct radeon_ttm_tt *gtt = (void *)ttm;
> +   struct radeon_ttm_tt *gtt = radeon_ttm_tt_to_gtt(ttm);
>
> if (gtt == NULL)
> return false;
> @@ -805,7 +812,7 @@ bool radeon_ttm_tt_has_userptr(struct ttm_tt *ttm)
>
>  bool radeon_ttm_tt_is_readonly(struct ttm_tt *ttm)
>  {
> -   struct radeon_ttm_tt *gtt = (void *)ttm;
> +   struct radeon_ttm_tt *gtt = radeon_ttm_tt_to_gtt(ttm);
>
> if (gtt == NULL)
> return false;
> --
> 1.8.3.2
>

[PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support

[Laurent Pinchart]

Hi Thierry,

On Wednesday 30 July 2014 11:40:54 Thierry Reding wrote:
> On Wed, Jul 30, 2014 at 11:54:00AM +0530, Ajay kumar wrote:
> > On Tue, Jul 29, 2014 at 5:17 PM, Thierry Reding wrote:
> > > On Tue, Jul 29, 2014 at 01:42:09PM +0200, Andreas F?rber wrote:
> > >> Am 29.07.2014 13:36, schrieb Thierry Reding:
> > >> > On Tue, Jul 29, 2014 at 01:21:48PM +0200, Andreas F?rber wrote:
> > >> >> Am 28.07.2014 08:13, schrieb Ajay kumar:
> > >> >>> On 7/27/14, Andreas F?rber  wrote:
> > >>  Am 25.07.2014 21:22, schrieb Ajay Kumar:
> > >> > This series is based on exynos-drm-next branch of Inki Dae's tree
> > >> > at:
> > >> > git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.
> > >> > git
> > >> > 
> > >> > I have tested this after adding few DT changes for
> > >> > exynos5250-snow,
> > >> > exynos5420-peach-pit and exynos5800-peach-pi boards.
> > >>  
> > >>  I'm trying to test this with a modified exynos5250-spring DT
> > >> 
> > >> [...]
> > >> 
> > >> >> Unfortunately the most I got on Spring with attached DT was a blank
> > >> >> screen with a white horizontal line in the middle.
> > >> >> 
> > >> >> Do I need to specify a specific panel model for Spring?
> > >> 
> > >> [...]
> > >> 
> > >> >> From 9172a26a8f0d0f0d170bd27e1c150ad204d8086a Mon Sep 17 00:00:00
> > >> >> 2001
> > >> >> From: =?UTF-8?q?Andreas=20F=C3=A4rber?= 
> > >> >> Date: Sun, 27 Jul 2014 21:58:06 +0200
> > >> >> Subject: [PATCH] ARM: dts: exynos5250: Add eDP/LVDS bridge to Spring
> > >> >> MIME-Version: 1.0
> > >> >> Content-Type: text/plain; charset=UTF-8
> > >> >> Content-Transfer-Encoding: 8bit
> > >> >> 
> > >> >> Signed-off-by: Ajay Kumar 
> > >> >> [AF: Redone for v6]
> > >> >> Signed-off-by: Andreas F??rber 
> > >> >> ---
> > >> >> 
> > >> >>  arch/arm/boot/dts/exynos5250-spring.dts | 32 +-
> > >> >>  1 file changed, 31 insertions(+), 1 deletion(-)
> > >> >> 
> > >> >> diff --git a/arch/arm/boot/dts/exynos5250-spring.dts
> > >> >> b/arch/arm/boot/dts/exynos5250-spring.dts index
> > >> >> 687dfab86bc8..517b1ff2bfdf 100644
> > >> >> --- a/arch/arm/boot/dts/exynos5250-spring.dts
> > >> >> +++ b/arch/arm/boot/dts/exynos5250-spring.dts
> > >> >> @@ -64,10 +64,14 @@
> > >> >>vdd_pll-supply = <_ldo8_reg>;
> > >> >>};
> > >> >> 
> > >> >> +  panel: panel {
> > >> >> +  compatible = "simple-panel";
> > >> >> +  };
> > >> > 
> > >> > You can't do this. "simple-panel" isn't a valid panel model. It
> > >> > should probably be removed from the platform_of_match table in the
> > >> > driver.
> > >> 
> > >> Okay, that means the Snow DT is wrong, too:
> > >> https://patchwork.kernel.org/patch/4625441/
> > >> 
> > >> And the others specify it as fallback:
> > >> https://patchwork.kernel.org/patch/4625461/
> > >> https://patchwork.kernel.org/patch/4625451/
> > > 
> > > A quick grep shows that many (all?) devices that use DRM panels provide
> > > simple-panel as fallback. That's probably fine as long as they also do
> > > provide the specific model. But given that simple-panel does not have a
> > > mode or physical size, I don't think even that makes sense.
> > 
> > On snow, the bridge chip provides the display mode instead of the panel.
> > That is why display was working for me.
> 
> Okay, I suppose under some circumstances that might make sense. Although
> it's still always the panel that dictates the display timings, so the
> panel node needs to have a panel model specific compatible value with a
> matching entry in the panel-simple driver so that it can even be used in
> setups without a bridge.
> 
> One other thing: how does the bridge know which mode to drive? I suspect
> that it can drive more than one mode? Can it freely be configured or
> does it have a predefined set of modes? If the latter, then according to
> what you said above there needs to be a way to configure the bridge (via
> DT?) so that it reports the mode matching the panel. I wonder if that
> should be handled completely in code, so that for example a bridge has a
> panel attached it can use the panel's .get_modes() and select a matching
> mode among the set that it supports.

Yes, pretty please :-) I don't think it would be a good idea to duplicate mode 
information in the bridge DT node, as that's not a property of the bridge. 
Querying the mode at runtime is in my opinion a much better option, and would 
also allow switching between different modes at runtime when that makes sense.

Now, I'm not sure whether it should be the bridge driver querying the panel 
driver directly, or the display controller driver doing it and then 
configuring the bridge accordingly. The latter seems more generic to me and 
doesn't rely on the assumption that the bridge output will always be directly 
connected to a panel.

-- 
Regards,

Laurent Pinchart

-next mostly closed, what have I missed?

[Laurent Pinchart]

Hi Dave,

On Wednesday 17 September 2014 10:59:42 Dave Airlie wrote:
> Okay so I'm pretty sure I'm close to not taking anything major for next,
> 
> I'm not sure I've gotten an exynos tree yet, so hopefully that appears
> before -rc6,
> 
> Please continue to send fixes for -next pulls, and I'm kinda open to
> new hw support depending on how intrusive it is to other code.
> 
> Now we have a strange new time of a few weeks where maybe we should go
> fix some regressions or something!
> 
> any other trees I've missed?

Yes, you seem to have missed "[GIT PULL FOR v3.18] Renesas DRM changes".

The following changes since commit 98faa78ce7f1f986e11e7805d31b409782a6d2d4:

  Merge tag 'topic/drm-header-rework-2014-09-12' of 
git://anongit.freedesktop.org/drm-intel into drm-next (2014-09-13 07:01:49 
+1000)

are available in the git repository at:

  git://linuxtv.org/pinchartl/fbdev.git drm/next/du

for you to fetch changes up to 96c026911890ceacee238da00a0b140ad634cc43:

  drm/rcar-du: Add OF support (2014-09-15 11:55:47 +0300)

-- 
Regards,

Laurent Pinchart

[PATCH v3 4/5] ASoC: davinci: HDMI audio build for AM33XX and TDA998x

[Mark Brown]

On Tue, Sep 16, 2014 at 11:40:17PM +0300, Jyri Sarha wrote:
> Adds configuration option for HDMI audio support for AM33XX based
> boards with NXP TDA998x HDMI transmitter. The audio is connected to
> NXP TDA998x trough McASP running in i2s mode.

So, Jean-Francois is also trying to do things with the TDA998x - what's
the story with that, is this joined up at all?
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140917/8904d641/attachment.sig>

[PATCH V6 6/8] drm/bridge: Modify drm_bridge core to support driver model

[Laurent Pinchart]

Hi Ajay,

On Wednesday 17 September 2014 14:37:30 Ajay kumar wrote:
> On Mon, Sep 15, 2014 at 11:07 PM, Laurent Pinchart wrote:
> > Hi Ajay,
> > 
> > Thank you for the patch.
> > 
> > I think we're moving in the right direction, but we're not there yet.
> > 
> > On Saturday 26 July 2014 00:52:08 Ajay Kumar wrote:
> >> This patch tries to seperate drm_bridge implementation
> >> into 2 parts, a drm part and a non_drm part.
> >> 
> >> A set of helper functions are defined in this patch to make
> >> bridge driver probe independent of the drm flow.
> >> 
> >> The bridge devices register themselves on a lookup table
> >> when they get probed by calling "drm_bridge_add_for_lookup".
> >> 
> >> The parent encoder driver waits till the bridge is available in the
> >> lookup table(by calling "of_drm_find_bridge") and then continues with
> >> its initialization.
> > 
> > Before the introduction of the component framework I would have said this
> > is the way to go. Now, I think bridges should register themselves as
> > components, and the DRM master driver should use the component framework
> > to get a reference to the bridges it needs.
> 
> Well, I have modified the bridge framework exactly the way Thierry wanted it
> to be, I mean the same way the current panel framework is.
> And, I don't think there is a problem with that.
> What problem are you facing with current bridge implementation?
> What is the advantage of using the component framework to register bridges?

There are several advantages.

- The component framework has been designed with this exact problem in mind, 
piecing multiple components into a display device. This patch set introduces 
yet another framework, without any compelling reason as far as I can see. 
Today DRM drivers already need to use three different frameworks (component, 
I2C slave encoder and panel), and we're adding a fourth one to make the mess 
even messier. This is really a headlong rush, we need to stop and fix the 
design mistakes.

- The component framework solves the probe ordering problem. Bridges can use 
deferred probing, but when a bridge requires a resources (such as a clock for 
instance) provided by the display controller, this will break.

> >> The encoder driver should call "drm_bridge_attach_encoder" to pass on
> >> the drm_device and the encoder pointers to the bridge object.
> >> 
> >> Now that the drm_device pointer is available, the encoder then calls
> >> "bridge->funcs->post_encoder_init" to allow the bridge to continue
> >> registering itself with the drm core.
> > 
> > This is what really bothers me with DRM bridge.
> > 
> > The framework assumes that a bridge will always bridge an encoder and a
> > connector. Beside lacking support for chained bridges, this creates an
> > artificial split between bridges and encoders by modeling the same
> > components using drm_encoder or drm_bridge depending on their position in
> > the video output pipeline.
> > 
> > I would like to see drm_bridge becoming more self-centric, removing the
> > awareness of the upstream encoder and downstream connector. I'll give this
> > a try, but it will conflict with this patch, so I'd like to share
> > opinions and coordinate efforts sooner than later if possible.
> 
> I am not really able to understand how you want "drm_bridge" to be.
> As of now, there are many platforms using drm_bridge and they don't
> have a problem with current implementation.
> Regarding chained bridges: Can't you add this once my patchset is merged?
> As an additional feature?

Yes, as I mentioned in another e-mail this can be fixed later. I want to start 
discussing it though.

> To be honest, I have spent quite sometime for working on this patchset.
> All I started with was to add drm_panel support to drm_bridge.
> When I sent the first patchset for that, Daniel, Rob and Thierry raised a
> concern that current bridge framework itself is not proper and hence
> they asked me to fix that first. And we have reached till here based on
> their comments only.
> 
> Without this patchset, you cannot bring an X server
> based display on snow and peach_pit. Also, day by day the number of
> platforms using drm_bridge is increasing.

That's exactly why I'd like to use the component framework now, as the 
conversion will become more complex as time goes by.

> And, I don't really see a problem with the current approach(which is exactly
> the same way panel framework is). And, I am no decision maker here. I would
> expect the top guys to comment!

-- 
Regards,

Laurent Pinchart

[Intel-gfx] [PATCH] intel: Add support for userptr objects

[Damien Lespiau]

On Thu, Jun 19, 2014 at 03:52:03PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> Allow userptr objects to be created and used via libdrm_intel.
> 
> At the moment tiling and mapping to GTT aperture is not supported
> due hardware limitations across different generations and uncertainty
> about its usefulness.
> 
> v2: Improved error handling in feature detection per review comments.
> 
> Signed-off-by: Tvrtko Ursulin 
> ---

Reviewed-by: Damien Lespiau 

Pushed a slightly modified version of this patch as libdrm now has
explicit symbol visibility.

-- 
Damien

>  intel/intel_bufmgr.c  |  13 
>  intel/intel_bufmgr.h  |   5 ++
>  intel/intel_bufmgr_gem.c  | 163 
> +-
>  intel/intel_bufmgr_priv.h |  12 +++-
>  4 files changed, 191 insertions(+), 2 deletions(-)
> 
> diff --git a/intel/intel_bufmgr.c b/intel/intel_bufmgr.c
> index 905556f..7f3d795 100644
> --- a/intel/intel_bufmgr.c
> +++ b/intel/intel_bufmgr.c
> @@ -60,6 +60,19 @@ drm_intel_bo 
> *drm_intel_bo_alloc_for_render(drm_intel_bufmgr *bufmgr,
>   return bufmgr->bo_alloc_for_render(bufmgr, name, size, alignment);
>  }
>  
> +drm_intel_bo *drm_intel_bo_alloc_userptr(drm_intel_bufmgr *bufmgr,
> +   const char *name, void *addr,
> +   uint32_t tiling_mode,
> +   uint32_t stride,
> +   unsigned long size,
> +   unsigned long flags)
> +{
> + if (bufmgr->bo_alloc_userptr)
> + return bufmgr->bo_alloc_userptr(bufmgr, name, addr, tiling_mode,
> + stride, size, flags);
> + return NULL;
> +}
> +
>  drm_intel_bo *
>  drm_intel_bo_alloc_tiled(drm_intel_bufmgr *bufmgr, const char *name,
>  int x, int y, int cpp, uint32_t *tiling_mode,
> diff --git a/intel/intel_bufmgr.h b/intel/intel_bufmgr.h
> index 9383c72..be83a56 100644
> --- a/intel/intel_bufmgr.h
> +++ b/intel/intel_bufmgr.h
> @@ -113,6 +113,11 @@ drm_intel_bo 
> *drm_intel_bo_alloc_for_render(drm_intel_bufmgr *bufmgr,
>   const char *name,
>   unsigned long size,
>   unsigned int alignment);
> +drm_intel_bo *drm_intel_bo_alloc_userptr(drm_intel_bufmgr *bufmgr,
> + const char *name,
> + void *addr, uint32_t tiling_mode,
> + uint32_t stride, unsigned long size,
> + unsigned long flags);
>  drm_intel_bo *drm_intel_bo_alloc_tiled(drm_intel_bufmgr *bufmgr,
>  const char *name,
>  int x, int y, int cpp,
> diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
> index 007a6d8..6dd3986 100644
> --- a/intel/intel_bufmgr_gem.c
> +++ b/intel/intel_bufmgr_gem.c
> @@ -182,6 +182,11 @@ struct _drm_intel_bo_gem {
>   void *mem_virtual;
>   /** GTT virtual address for the buffer, saved across map/unmap cycles */
>   void *gtt_virtual;
> + /**
> +  * Virtual address of the buffer allocated by user, used for userptr
> +  * objects only.
> +  */
> + void *user_virtual;
>   int map_count;
>   drmMMListHead vma_list;
>  
> @@ -221,6 +226,11 @@ struct _drm_intel_bo_gem {
>   bool idle;
>  
>   /**
> +  * Boolean of whether this buffer was allocated with userptr
> +  */
> + bool is_userptr;
> +
> + /**
>* Size in bytes of this buffer and its relocation descendents.
>*
>* Used to avoid costly tree walking in
> @@ -847,6 +857,80 @@ drm_intel_gem_bo_alloc_tiled(drm_intel_bufmgr *bufmgr, 
> const char *name,
>  tiling, stride);
>  }
>  
> +static drm_intel_bo *
> +drm_intel_gem_bo_alloc_userptr(drm_intel_bufmgr *bufmgr,
> + const char *name,
> + void *addr,
> + uint32_t tiling_mode,
> + uint32_t stride,
> + unsigned long size,
> + unsigned long flags)
> +{
> + drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *) bufmgr;
> + drm_intel_bo_gem *bo_gem;
> + int ret;
> + struct drm_i915_gem_userptr userptr;
> +
> + /* Tiling with userptr surfaces is not supported
> +  * on all hardware so refuse it for time being.
> +  */
> + if (tiling_mode != I915_TILING_NONE)
> + return NULL;
> +
> + bo_gem = calloc(1, sizeof(*bo_gem));
> + if (!bo_gem)
> + return NULL;
> +
> + bo_gem->bo.size = size;
> +
> + VG_CLEAR(userptr);
> + userptr.user_ptr = (__u64)((unsigned long)addr);
> + 

[Bug 82828] Regression: Crash in 3Dmark2001

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

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

Fabio Pedretti  changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED

-- 
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/20140917/c61d8d2f/attachment.html>

[Bug 83436] Sudden framerate drops in multiple games when compiling with -mtune=generic (as well with -mtune=pentium-mmx and older CPUs)

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

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

Fabio Pedretti  changed:

   What|Removed |Added

Summary|Sudden framerate drops in   |Sudden framerate drops in
   |multiple games  |multiple games when
   ||compiling with
   ||-mtune=generic (as well
   ||with -mtune=pentium-mmx and
   ||older CPUs)

--- Comment #29 from Fabio Pedretti  ---
> Oh i bisected that ine, it takes 200X more time to compile on 32bit :D , 
> actually compile libmesa_gallium i think this is the commit:

The slow compile should be fixed with:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=cfeb394224f2daeb2139cf4ec489a4dd8297a44d


Is the original issue - slow performance with -mtune=generic - still an issue?

-- 
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/20140917/d220be21/attachment.html>

rockchip and atmel kms drivers

[Rob Clark]

On Wed, Sep 17, 2014 at 1:41 AM, Boris BREZILLON
 wrote:
> Hi Dave,
>
> On Wed, 17 Sep 2014 11:18:44 +1000
> Dave Airlie  wrote:
>
>> Hey,
>>
>> So I notice we have two unreviewed drivers outstanding, the atmel
>> hlcdc and the rockchips one, I'd like to suggest they you guys review
>> each others work, they should be quite close in terms of functionality
>> and you might spot some problems in your own code from reading the
>> other driver.
>
> Sure, I'll review the rockchip driver.
>
>>
>> I'm also hoping regular review will happen as well, but I think more
>> cross-review is probably a good thing for new driver writers.
>
> One more point, as stated in my cover letter, the HLCDC driver depends
> on 2 other series ([1] and [2]), which I proposed after discussing it
> with other KMS developers (Rob, Laurent and Thierry).

oh, I didn't notice that the flip-work patches hadn't landed yet.

Dave, [1] ("drm: rework flip-work framework") series has my r-b

BR,
-R


> Could you take a look at these ones ?
>
> Best Regards,
>
> Boris
>
> [1]http://lkml.iu.edu/hypermail/linux/kernel/1407.1/04171.html
> [2]http://www.spinics.net/lists/kernel/msg1791681.html
>
> --
> Boris Brezillon, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com

[PATCH 0/9 linux-next] drivers/gpu/drm: use container_of where possible

[Daniel Vetter]

On Mon, Sep 15, 2014 at 08:15:54PM +0200, Fabian Frederick wrote:
> 
> 
> > On 15 September 2014 at 01:13 One Thousand Gnomes  > lxorguk.ukuu.org.uk>
> > wrote:
> >
> >
> > On Sun, 14 Sep 2014 18:40:13 +0200
> > Fabian Frederick  wrote:
> >
> > > Small patchset using container_of instead of casting on first structure
> > > member address.
> >
> > Why. Container_of is useful for random offsets but its just convoluting
> > and confusing code which is designed with the fields intentionally at the
> > start.
> >
> > Alan
> 
> What if someone doesn't know about that intention one day and inserts
> some field in the structure at the "wrong place" ?
> This would need at least some comment in each declaration
> but once again it's hard to control.One other way is to
> commonly use container_of and get rid of every casting with
> some semantic script.
> 
> Peter has been asking for container_of in the following:
> 
> http://marc.info/?l=linux-arm-kernel=140838705729653=2
> 
> 
> struct uart_amba_port *uap = (struct uart_amba_port *)port
> 
> (port/uart_port is the first field in uart_amba_port though)

fwiw I like this and I've picked it up into my topic/core-stuff branch. So
if driver writers don't outright nack this it'll all land in Dave's
drm-next (probably still for 3.18).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

-next mostly closed, what have I missed?

[Christian König]

I have a whole bunch of patches for radeon in the pipeline, but I'm 
perfectly fine with waiting for 3.19 with them.

Fixes for 3.18 are also already starting to stash up, so Alex will 
probably have a pull with fixes for your drm-next branch by the end of 
the week.

Regards,
Christian.

Am 17.09.2014 um 02:59 schrieb Dave Airlie:
> Okay so I'm pretty sure I'm close to not taking anything major for next,
>
> I'm not sure I've gotten an exynos tree yet, so hopefully that appears
> before -rc6,
>
> Please continue to send fixes for -next pulls, and I'm kinda open to
> new hw support depending on how intrusive it is to other code.
>
> Now we have a strange new time of a few weeks where maybe we should go
> fix some regressions or something!
>
> any other trees I've missed?
> Dave.
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/9 linux-next] drivers/gpu/drm: use container_of where possible

[One Thousand Gnomes]

> What if someone doesn't know about that intention one day and inserts
> some field in the structure at the "wrong place" ?

Then we have code review. Also they are much more likely to simply change
the code elsewhere and break it. Nobody afaik ever got this wrong, while
the litany of other broken patches and bugs introduced into the same code
is lagre.

The goal of the kernel is not to be foolproof to developer incompetence -
that's a battle you can't win until you replace driver developers with
software systems.

Alan

rockchip and atmel kms drivers

[Dave Airlie]

Hey,

So I notice we have two unreviewed drivers outstanding, the atmel
hlcdc and the rockchips one, I'd like to suggest they you guys review
each others work, they should be quite close in terms of functionality
and you might spot some problems in your own code from reading the
other driver.

I'm also hoping regular review will happen as well, but I think more
cross-review is probably a good thing for new driver writers.

Dave.

[alsa-devel] [PATCH v3 0/5] Beaglebone-Black HDMI audio

[Dave Airlie]

On 17 September 2014 06:40, Jyri Sarha  wrote:
> Changes since v2:
> - Change compatible property from "ti,gpio-clock" to "ti,gpio-gate-clock"
> - Some minor cleanups
>
> The code has a functional dependency to:
> http://www.mail-archive.com/linux-omap at vger.kernel.org/msg109264.html
>
> Without the above patch the audio card does not probe.
>
> The code has been rebased on top of Linux 3.17-rc5. The patches
> bellow, the above dependency, and couple of commits to add BBB HDMI audio
> support to omap2plus_defconfig can be pulled from:
>
> https://github.com/jsarha/linux.git linux-master-bbb-hdmi-audio

How do you intend to get this merge, sending patchsets like this without
indication to maintainers on a merge strategy is kinda messy.

I'm not sure how maintained tilcdc is.

Dave.
>
> Cheers,
> Jyri
>
> Jyri Sarha (5):
>   clk: ti: add "ti,gpio-gate-clock" controlled clock
>   drm/tilcdc: Add I2S HDMI audio config for tda998x
>   ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S
> bus
>   ASoC: davinci: HDMI audio build for AM33XX and TDA998x
>   ARM: dts: am335x-boneblack: Add HDMI audio support
>
>  .../bindings/clock/ti/gpio-gate-clock.txt  |   21 ++
>  .../bindings/sound/davinci-evm-audio.txt   |6 +-
>  arch/arm/boot/dts/am335x-boneblack.dts |   52 +
>  drivers/clk/ti/Makefile|2 +-
>  drivers/clk/ti/gpio.c  |  202 
> 
>  drivers/gpu/drm/tilcdc/tilcdc_slave.c  |   24 ++-
>  sound/soc/davinci/Kconfig  |   12 ++
>  sound/soc/davinci/davinci-evm.c|   82 +++-
>  8 files changed, 395 insertions(+), 6 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/clock/ti/gpio-gate-clock.txt
>  create mode 100644 drivers/clk/ti/gpio.c
>
> --
> 1.7.9.5
>
> ___
> Alsa-devel mailing list
> Alsa-devel at alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

-next mostly closed, what have I missed?

[Dave Airlie]

Okay so I'm pretty sure I'm close to not taking anything major for next,

I'm not sure I've gotten an exynos tree yet, so hopefully that appears
before -rc6,

Please continue to send fixes for -next pulls, and I'm kinda open to
new hw support depending on how intrusive it is to other code.

Now we have a strange new time of a few weeks where maybe we should go
fix some regressions or something!

any other trees I've missed?
Dave.

[PATCH/RESEND 0/8] tilcdc-panel: Backlight and GPIO devicetree support

[Dave Airlie]

On 16 September 2014 04:51, Ezequiel Garcia
 wrote:
> On 15 Sep 05:59 PM, Dave Airlie wrote:
>> On 15 September 2014 17:50, Ezequiel Garcia
>>  wrote:
>> > Dave,
>> >
>> > On 03 Sep 08:08 AM, Johannes Pointner wrote:
>> >> 2014-09-02 14:51 GMT+02:00 Ezequiel Garcia > >> vanguardiasur.com.ar>:
>> >> > Dave,
>> >> >
>> >> > I'm resending this, hoping it can be pushed for v3.18. The patchset was
>> >> > ready for v3.17, but it got no maintainer feedback or review. Maybe it 
>> >> > fell
>> >> > through some crack?
>> >> >
>> >> > Just for reference, here goes the details about this series and why it's
>> >> > needed:
>> >> >
>> >> > This patchset adds the required changes to support an optional backlight
>> >> > and GPIO for the tilcdc panel driver.
>> >> >
>> >> > There was some code to support a backlight, but it was broken and 
>> >> > undocumented.
>> >> > I've followed the nice implementation in panel-simple and added a 
>> >> > similar
>> >> > one here.
>> >> >
>> >> > The enable GPIO is required to turn on and off devices with such 
>> >> > capability.
>> >> > Also here, I've followed panel-simple which looks correct.
>> >> >
>> >> > In addition to this there are very minor cosmetic cleanups and a larger
>> >> > fix for the error path in tilcdc's DRM driver .load error path.
>> >> >
>> >>
>> >> I tested the series with 3.16.1 (with additonal patches from Guido and
>> >> Sachin) and with 3.17-rc3 with a custom AM335x board and it worked for
>> >> me without an issue. I tried it with and without the backlight
>> >> addition in the dts file.
>> >>
>> >> For the series:
>> >> Tested-by: Johannes Pointner 
>> >>
>> >
>> > Any feedback for this series?
>> >
>> > If at all possible, it'd be great to not miss the merge this time.
>>
>> Could you stick it in a git tree somewhere? and send a pull request for it?
>>
>
> Hm.. I really don't have a git tree ready :/
>
> Do you think you can pick the patches this time? I'll setup a tree as soon
> as possible.

Okay pushed to drm-next.

Dave.

[alsa-devel] [PATCH v3 0/5] Beaglebone-Black HDMI audio

[Jyri Sarha]

On 09/17/2014 04:06 AM, Dave Airlie wrote:
> On 17 September 2014 06:40, Jyri Sarha  wrote:
>> Changes since v2:
>> - Change compatible property from "ti,gpio-clock" to "ti,gpio-gate-clock"
>> - Some minor cleanups
>>
>> The code has a functional dependency to:
>> http://www.mail-archive.com/linux-omap at vger.kernel.org/msg109264.html
>>
>> Without the above patch the audio card does not probe.
>>
>> The code has been rebased on top of Linux 3.17-rc5. The patches
>> bellow, the above dependency, and couple of commits to add BBB HDMI audio
>> support to omap2plus_defconfig can be pulled from:
>>
>> https://github.com/jsarha/linux.git linux-master-bbb-hdmi-audio
>
> How do you intend to get this merge, sending patchsets like this without
> indication to maintainers on a merge strategy is kinda messy.
>
> I'm not sure how maintained tilcdc is.
>

Well, it is used but AFAIK the people who have been working with it the 
most have left TI. I think eventually someone at TI needs to take it 
over, but I do not know anything about that.

I was hoping that because the change to tilcdc is quite minimal it could 
go in via you. I am sure I could get a reviewed-by and tested-by from 
from Darren how has bit more experience with tilcdc and maybe from Tomi 
too if that helps. (Adding Tomi to cc).

The "drm/tilcdc: Add I2S HDMI audio config for tda998x"-patch itself 
just adds the audio configuration to pda998x pdata and fills the swap, 
and mirr parameters with default values (they are usually coming in hard 
coded at the beginning of tda998x_create()).

Best regards,
Jyri

[PATCH] drm/exynos: fix plane-framebuffer linkage

[Daniel Drake]

On Wed, Sep 17, 2014 at 7:45 AM, Daniel Vetter  wrote:
> I think fb refcounting in exynos is just plain busted. If you look at
> other drivers the only place the refcount framebuffers or backing
> storage objects is for pageflips to make sure the memory doesn't go
> away while the hw is still scanning out the old framebuffer. If you
> refcount anywhere else you either do something really crazy or your
> driver is broken.

With my patch actually the behaviour is much more similar to omapdrm,
which also doesn't quite match your description of "other drivers".
See omap_plane.c.

There is a fb reference taken for "pinning" in update_pin() which
presumably is what you describe - avoid destroying the fb while it is
being scanned out. (Maybe exynos should have something equivalent too,
but thats a separate issue)

However there is *another* fb reference taken in
omap_plane_mode_set(). And my patch is modelled to do the same in
exynos-drm.

I believe this is necessary under the current model. At least, when
drm_mode_rmfb() is running for the last user of the active
framebuffer, it expects to drop 3 references from the framebuffer
before dropping the 4th causes the object to be destroyed, as follows:

1. drm_mode_rmfb explicitly drops a reference - it calls
__drm_framebuffer_unregister which then calls
__drm_framebuffer_unreference
/* Mark fb as reaped, we still have a ref from fpriv->fbs. */
__drm_framebuffer_unregister(dev, fb);

2. drm_mode_rmfb then calls drm_framebuffer_remove, which calls
drm_mode_set_config_internal() in order to turn off the CRTC, dropping
another reference in the process.
if (tmp->old_fb)
drm_framebuffer_unreference(tmp->old_fb);

3. drm_framebuffer_remove calls drm_plane_force_disable() which drops
another reference:
/* disconnect the plane from the fb and crtc: */
__drm_framebuffer_unreference(old_fb);

4. drm_framebuffer drops the final reference itself, to cause freeing
of the object:
drm_framebuffer_unreference(fb);


So ordinarily, after a fb is created by drm core (with refcnt at 1),
there would have to be 3 references added to it by the time it is the
primary fb so that when we do rmfb, it has a refcnt of 4, and gets
freed correctly.
(The second bug I was seeing with pageflips was that refcnt was 3,
which means that the final reference was dropped in (3) above, but
__drm_framebuffer_unreference doesn't like that at all - it calls
drm_framebuffer_free_bug)

Not being overly familiar with DRM internals I tried to go backwards
to find out where these 3 references would be created during normal
operation. 2 are clear:

1. drm_framebuffer_init() explicitly grabs one:
/* Grab the idr reference. */
drm_framebuffer_reference(fb)

2. drm_mode_set_config_internal() takes one:
if (tmp->primary->fb)
drm_framebuffer_reference(tmp->primary->fb);

Where should the 3rd one be created? I don't know, but looking at
previous exynos commit 25c8b5c304 and omapdrm, I assumed that the drm
driver should take one, both on crtc mode set and crtc page flip.

>> However, I'll be happy if universal planes means the driver does not
>> have to care about this any more. Andrej, please go ahead if you are
>> interested, I'll be happy to test your results.
>
> universal planes will fix up the mess with 2 drm plane objects
> (primary plane + exonys internal primary). So should help to untangle
> this not, but it will not magically fix the refcounting bugs itself.

So even when we move to universal planes (fixing 1 of the issues), its
good that we're having this refcount discussion (which we need to
understand to confidently solve the 2nd issue). Thanks for your input!

Daniel

[PATCH] drm/vmwgfx: Fix drm.h include

[Dave Airlie]

On 16 September 2014 23:43, Josh Boyer  wrote:
> On Fri, Sep 5, 2014 at 1:19 PM, Josh Boyer  
> wrote:
>> The userspace drm.h include doesn't prefix the drm directory.  This can lead
>> to compile failures as /usr/include/drm/ isn't in the standard gcc include
>> paths.  Fix it to be , which matches the rest of the driver drm
>> header files that get installed into /usr/include/drm.
>>
>> Red Hat Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1138759
>>
>> Fixes: 1d7a5cbf8f74e
>> Reported-by: Jeffrey Bastian 
>> Signed-off-by: Josh Boyer 
>
> Ping?  Did this get queued anywhere?

Yes its in drm-next.

Dave.

[PATCH] drm/radeon: Disable HDP flush before every CS again for < r600

[Alex Deucher]

On Wed, Sep 17, 2014 at 3:25 AM, Michel D?nzer  wrote:
> From: Michel D?nzer 
>
> It was causing display corruption with R300 generation GPUs at least.
>
> Reported-and-Tested-by: Mikael Pettersson 
> Signed-off-by: Michel D?nzer 


Applied to my fixes tree.

thanks!

Alex

> ---
>  drivers/gpu/drm/radeon/r100.c| 28 ++--
>  drivers/gpu/drm/radeon/radeon_asic.c |  2 --
>  drivers/gpu/drm/radeon/radeon_asic.h |  3 +--
>  drivers/gpu/drm/radeon/radeon_drv.c  |  2 +-
>  4 files changed, 16 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
> index 4c5ec44..b0098e7 100644
> --- a/drivers/gpu/drm/radeon/r100.c
> +++ b/drivers/gpu/drm/radeon/r100.c
> @@ -821,6 +821,20 @@ u32 r100_get_vblank_counter(struct radeon_device *rdev, 
> int crtc)
> return RREG32(RADEON_CRTC2_CRNT_FRAME);
>  }
>
> +/**
> + * r100_ring_hdp_flush - flush Host Data Path via the ring buffer
> + * rdev: radeon device structure
> + * ring: ring buffer struct for emitting packets
> + */
> +static void r100_ring_hdp_flush(struct radeon_device *rdev, struct 
> radeon_ring *ring)
> +{
> +   radeon_ring_write(ring, PACKET0(RADEON_HOST_PATH_CNTL, 0));
> +   radeon_ring_write(ring, rdev->config.r100.hdp_cntl |
> +   RADEON_HDP_READ_BUFFER_INVALIDATE);
> +   radeon_ring_write(ring, PACKET0(RADEON_HOST_PATH_CNTL, 0));
> +   radeon_ring_write(ring, rdev->config.r100.hdp_cntl);
> +}
> +
>  /* Who ever call radeon_fence_emit should call ring_lock and ask
>   * for enough space (today caller are ib schedule and buffer move) */
>  void r100_fence_ring_emit(struct radeon_device *rdev,
> @@ -1056,20 +1070,6 @@ void r100_gfx_set_wptr(struct radeon_device *rdev,
> (void)RREG32(RADEON_CP_RB_WPTR);
>  }
>
> -/**
> - * r100_ring_hdp_flush - flush Host Data Path via the ring buffer
> - * rdev: radeon device structure
> - * ring: ring buffer struct for emitting packets
> - */
> -void r100_ring_hdp_flush(struct radeon_device *rdev, struct radeon_ring 
> *ring)
> -{
> -   radeon_ring_write(ring, PACKET0(RADEON_HOST_PATH_CNTL, 0));
> -   radeon_ring_write(ring, rdev->config.r100.hdp_cntl |
> -   RADEON_HDP_READ_BUFFER_INVALIDATE);
> -   radeon_ring_write(ring, PACKET0(RADEON_HOST_PATH_CNTL, 0));
> -   radeon_ring_write(ring, rdev->config.r100.hdp_cntl);
> -}
> -
>  static void r100_cp_load_microcode(struct radeon_device *rdev)
>  {
> const __be32 *fw_data;
> diff --git a/drivers/gpu/drm/radeon/radeon_asic.c 
> b/drivers/gpu/drm/radeon/radeon_asic.c
> index abe..2dd5847 100644
> --- a/drivers/gpu/drm/radeon/radeon_asic.c
> +++ b/drivers/gpu/drm/radeon/radeon_asic.c
> @@ -185,7 +185,6 @@ static struct radeon_asic_ring r100_gfx_ring = {
> .get_rptr = _gfx_get_rptr,
> .get_wptr = _gfx_get_wptr,
> .set_wptr = _gfx_set_wptr,
> -   .hdp_flush = _ring_hdp_flush,
>  };
>
>  static struct radeon_asic r100_asic = {
> @@ -332,7 +331,6 @@ static struct radeon_asic_ring r300_gfx_ring = {
> .get_rptr = _gfx_get_rptr,
> .get_wptr = _gfx_get_wptr,
> .set_wptr = _gfx_set_wptr,
> -   .hdp_flush = _ring_hdp_flush,
>  };
>
>  static struct radeon_asic r300_asic = {
> diff --git a/drivers/gpu/drm/radeon/radeon_asic.h 
> b/drivers/gpu/drm/radeon/radeon_asic.h
> index 275a5dc..7756bc1 100644
> --- a/drivers/gpu/drm/radeon/radeon_asic.h
> +++ b/drivers/gpu/drm/radeon/radeon_asic.h
> @@ -148,8 +148,7 @@ u32 r100_gfx_get_wptr(struct radeon_device *rdev,
>   struct radeon_ring *ring);
>  void r100_gfx_set_wptr(struct radeon_device *rdev,
>struct radeon_ring *ring);
> -void r100_ring_hdp_flush(struct radeon_device *rdev,
> -struct radeon_ring *ring);
> +
>  /*
>   * r200,rv250,rs300,rv280
>   */
> diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
> b/drivers/gpu/drm/radeon/radeon_drv.c
> index a773830..ef5b60a 100644
> --- a/drivers/gpu/drm/radeon/radeon_drv.c
> +++ b/drivers/gpu/drm/radeon/radeon_drv.c
> @@ -83,7 +83,7 @@
>   *CIK: 1D and linear tiling modes contain valid PIPE_CONFIG
>   *   2.39.0 - Add INFO query for number of active CUs
>   *   2.40.0 - Add RADEON_GEM_GTT_WC/UC, flush HDP cache before submitting
> - *CS to GPU
> + *CS to GPU on >= r600
>   */
>  #define KMS_DRIVER_MAJOR   2
>  #define KMS_DRIVER_MINOR   40
> --
> 2.1.0
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 83748] Only black content on screen, in the Tokyo flashback of the game "The Secret World"

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

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

--- Comment #9 from John  ---
Well, I tried something else, I probably should have tried earlier:
Compressing the original trace with xz at its maximum compression level, and it
is very acceptable. (more than 5 Gb before vs less than 200Mb after).

The link:
https://mega.co.nz/#!khgwBJRC!Xzk1fsNeKZgUS5aqdQ3cqDWkGQoynGj3TPYyr0XGdGE

Locating the issues in the trace:
1- After I load my character, you can see for just a little bit some sort of
Zombie image with some text, then it switches to all black. I do not really
care about that all back, though it probably means something as well. This is
just the loading phase going all black. What I care about is right after, it is
still all black, but now you can see the FPS counter of the left side. That is
the in-game cinematic all black. If you pay careful attention, and have proper
lighting in your room, you may be able to see characters moving and such (all
black of course, you can only see them as shadows)

2- After the cinematic, you'll see a game UI but everything else is all black,
that is the second scene with issue.

Please do not worry about the original weird stuff happening in the intro, when
the trace begins, it is part of the game.

Thank you!

-- 
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/20140917/7a36e47e/attachment-0001.html>

Using a HD 4670 still possible?

[Alex Deucher]

On Wed, Sep 17, 2014 at 3:30 AM, Michel D?nzer  wrote:
> On 14.09.2014 03:13, Christoph Brill wrote:
>>
>> Am 08.09.2014 03:41 schrieb "Michel D?nzer" > >:
>>
>>  > On 07.09.2014 01:01, Christoph Brill wrote:
>>  >>
>>  >>
>>  >> I'm currently trying to get a HD 4670 aka RV730 XT to work against
>> X.org
>>  >> 1.16, xf86-video-ati 7.4.0 on a Linux 3.16.1.
>>  >>
>>  >> Can anyone tell me: Should this card be able to handle an average
>> Gnome
>>  >> desktop?
>>  >
>>  >
>>  > Of course.
>>  >
>>  >
>>  >
>>  >> The problem was: 3D rendering did not work at all.
>>  >>
>>  >> Starting gdm lead to hanging Xorg. Calling glxgears on a twm session
>>  >> just rendered a black window, which stayed even if the process was
>>  >> killed by CTRL+C. I managed to get glxgears do do its job by setting
>>  >> "vblank_mode=0".
>>  >>
>>  >> I guessed my card does not like to play along with vsync at all. So I
>>  >> went ahead to disable vsyncing (tearing is still better than no
>> display
>>  >> at all). Setting it globally in /etc/drirc seems to get glxgears
>> running.
>>  >>
>>  >> Testing Xonotic on twm showed, that the card was now able to handle
>> 3D.
>>  >> But: gdm still was extremely sluggish and eventually froze. Starting
>>  >> gnome-shell directly from startx gets me to the desktop, but any
>> action
>>  >> freezes the process.
>>  >>
>>  >> Is there still hope for this card or should I get rid of it?
>>  >
>>  >
>>  > It sounds like there's a problem with interrupt processing on your
>> system. Please provide the dmesg output. You might try
>> disabling/enabling MSI to see if that works around the problem.
>>
>> Thank you so much for this hint! Booting using radeon.msi=0 finally
>> brings the system into a usable state. The dmesg of a default boot (i.e.
>> radeon.msi=-1) is available at http://pastebin.com/gS1xHYPc
>
>
> Can you file a bug report at
> https://bugs.freedesktop.org/enter_bug.cgi?product=DRI component
> "DRM/Radeon" and attach the dmesg output there?
>

Also mention what chipset your system uses and whether the card is AGP or not.

Alex

[PATCH] drm/exynos: fix plane-framebuffer linkage

[Andrzej Hajda]

Hi,

On 09/16/2014 08:35 AM, Daniel Vetter wrote:
> On Mon, Sep 15, 2014 at 12:52:17PM -0600, Daniel Drake wrote:
>> Pageflipping currently causes some inconsistencies that lead to
>> crashes. Just run an app that causes a CRTC pageflip in a raw X session
>> and check that it exits cleanly and can be restarted - you'll see
>> crashes like:
>>  Unable to handle kernel NULL pointer dereference at virtual address 0334
>>  PC is at exynos_drm_crtc_plane_commit+0x20/0x40
>>  LR is at exynos_drm_crtc_plane_commit+0x20/0x40
>>  [] (exynos_drm_crtc_plane_commit) from [] 
>> (exynos_drm_crtc_commit+0x44/0x70)
>>  [] (exynos_drm_crtc_commit) from [] 
>> (exynos_drm_crtc_mode_set_commit.isra.2+0xb4/0xc4)
>>  [] (exynos_drm_crtc_mode_set_commit.isra.2) from [] 
>> (exynos_drm_crtc_page_flip+0x140/0x1a8)
>>  [] (exynos_drm_crtc_page_flip) from [] 
>> (drm_mode_page_flip_ioctl+0x224/0x2dc)
>>  [] (drm_mode_page_flip_ioctl) from [] 
>> (drm_ioctl+0x338/0x4fc)
>>
>> These crashes happen because drm_plane_force_disable has previously set
>> plane->crtc to NULL.
>>
>> When drm_mode_page_flip_ioctl() is used to flip another framebuffer
>> onto the primary plane, crtc->primary->fb is correctly updated (this is
>> a virtual plane created by plane_helper), but plane->fb is not (this
>> plane is the real one, created by exynos_drm_crtc_create).
>>
>> We then come to handle rmfb of the backbuffer, which the "real" primary
>> plane is incorrectly pointing at. So drm_framebuffer_remove() decides that
>> the buffer is actually active on a plane and force-disables the plane.
>>
>> Ensuring that plane->fb is kept up-to-date solves that issue, but
>> exposes a reference counting problem. Now we see crashes when rmfb is
>> called on the front-buffer, because the rmfb code expects to drop 3
>> references here, and there are only 2.
>>
>> That can be fixed by adopting the reference management found in omapdrm:
>> Framebuffer references are not taken directly in crtc mode_set context,
>> but rather in the context of updating the plane, which also covers
>> flips. Like omapdrm we also unreference the old framebuffer here.
>>
>> Signed-off-by: Daniel Drake 
> This sounds very much like exynos should switch to universal planes so
> that the fake primary plane created by the helpers doesn't get in the way.
> And for chips which already use planes for everything internally this
> shouldn't be a lot more than a few lines.
> -Daniel

The patch proposed here of course supersedes my patch fixing fb refcounting.
But the best solution is to get rid of virtual plane as Daniel Vetter
stated.
Daniel (Drake of course :) ) do you want to prepare patch switching to
universal planes?
Maybe other volunteers? If not I can try to do it, as it seems quite
straightforward.

Regards
Andrzej

>> ---
>>  drivers/gpu/drm/exynos/exynos_drm_crtc.c  | 12 ++--
>>  drivers/gpu/drm/exynos/exynos_drm_plane.c |  8 
>>  2 files changed, 10 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>> index b68e58f..7aa9dee 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>> @@ -140,16 +140,8 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct 
>> drm_display_mode *mode,
>>  if (manager->ops->mode_set)
>>  manager->ops->mode_set(manager, >mode);
>>  
>> -ret = exynos_plane_mode_set(plane, crtc, crtc->primary->fb, 0, 0, 
>> crtc_w, crtc_h,
>> -x, y, crtc_w, crtc_h);
>> -if (ret)
>> -return ret;
>> -
>> -plane->crtc = crtc;
>> -plane->fb = crtc->primary->fb;
>> -drm_framebuffer_reference(plane->fb);
>> -
>> -return 0;
>> +return exynos_plane_mode_set(plane, crtc, crtc->primary->fb, 0, 0,
>> + crtc_w, crtc_h, x, y, crtc_w, crtc_h);
>>  }
>>  
>>  static int exynos_drm_crtc_mode_set_commit(struct drm_crtc *crtc, int x, 
>> int y,
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_plane.c
>> index 8371cbd..df27e35 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
>> @@ -139,6 +139,14 @@ int exynos_plane_mode_set(struct drm_plane *plane, 
>> struct drm_crtc *crtc,
>>  overlay->crtc_x, overlay->crtc_y,
>>  overlay->crtc_width, overlay->crtc_height);
>>  
>> +if (plane->fb)
>> +drm_framebuffer_unreference(plane->fb);
>> +
>> +drm_framebuffer_reference(fb);
>> +
>> +plane->fb = fb;
>> +plane->crtc = crtc;
>> +
>>  exynos_drm_crtc_plane_mode_set(crtc, overlay);
>>  
>>  return 0;
>> -- 
>> 1.9.1
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 83505] AMD A4-5300 APU : radeon.dpm=1 get random reboots with 3.16.1 kernel.

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

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

--- Comment #6 from Rpnpif  ---
No random reboots occurred during five days of use of 3.16.2 kernel.
I am waiting some days yet until I will say that this bug is resolved.

-- 
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/20140917/430933ee/attachment.html>

[Bug 83800] 3DMark2003 crashes radeon with wine 1.7.26 + gallium nine

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

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

--- Comment #10 from Michel D?nzer  ---
Hmm, of course Linux apitrace won't work either with the nine state tracker...

-- 
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/20140917/7ab0de9f/attachment.html>

[Bug 83800] 3DMark2003 crashes radeon with wine 1.7.26 + gallium nine

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

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

--- Comment #9 from Michel D?nzer  ---
You'd have to use Linux apitrace to trace the Wine process. Even if Windows
apitrace can trace Direct3D, the resulting traces wouldn't be useful for the
purpose of this bug report.

-- 
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/20140917/b705e031/attachment.html>

rockchip and atmel kms drivers

[Boris BREZILLON]

Hi Dave,

On Wed, 17 Sep 2014 11:18:44 +1000
Dave Airlie  wrote:

> Hey,
> 
> So I notice we have two unreviewed drivers outstanding, the atmel
> hlcdc and the rockchips one, I'd like to suggest they you guys review
> each others work, they should be quite close in terms of functionality
> and you might spot some problems in your own code from reading the
> other driver.

Sure, I'll review the rockchip driver.

> 
> I'm also hoping regular review will happen as well, but I think more
> cross-review is probably a good thing for new driver writers.

One more point, as stated in my cover letter, the HLCDC driver depends
on 2 other series ([1] and [2]), which I proposed after discussing it
with other KMS developers (Rob, Laurent and Thierry).

Could you take a look at these ones ?

Best Regards,

Boris

[1]http://lkml.iu.edu/hypermail/linux/kernel/1407.1/04171.html
[2]http://www.spinics.net/lists/kernel/msg1791681.html

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Bug 83800] 3DMark2003 crashes radeon with wine 1.7.26 + gallium nine

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

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

--- Comment #8 from darkbasic  ---
I tried but I get no traces from apitrace 5 and I can't find apitrace 4
binaries anymore:
wine ~/Downloads/apitrace-msvc/x86/bin/apitrace.exe trace --api=d3d9
"C:\Program Files (x86)\Futuremark\3DMark03\3DMark03.exe" -nosysteminfo

Do you have apitrace 4 for windows?

-- 
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/20140917/9355f461/attachment.html>

[Bug 83748] Only black content on screen, in the Tokyo flashback of the game "The Secret World"

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

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

--- Comment #8 from Michel D?nzer  ---
That said, if you can include the first frame in the trimmed apitrace, that
might help.

However, this will leave some uncertainty about whether any issues demonstrated
by the other frame aren't caused by the apitrace trimming working
incorrectly...

-- 
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/20140917/c19ca3ca/attachment.html>

[Bug 83748] Only black content on screen, in the Tokyo flashback of the game "The Secret World"

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

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

--- Comment #7 from Michel D?nzer  ---
I don't have much experience with trimming apitraces, so I'm afraid I can't
help you with that.

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

[Bug 81382] Text console blanking does not go away

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

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

--- Comment #19 from Patrick  ---
Created attachment 106410
  --> https://bugs.freedesktop.org/attachment.cgi?id=106410=edit
lspci -vnn for Amilo

sure, here it is

-- 
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/20140917/345c2d61/attachment.html>

[Bug 82455] Failed to allocate virtual address for buffer

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

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

--- Comment #33 from Michel D?nzer  ---
(In reply to comment #32)
> This error is showed in the drm_ioctl function.

No, as I said in comment 31, it comes from somewhere inside radeon_cs_ioctl()
AFAICT.

-- 
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/20140917/c7e18e92/attachment-0001.html>

[Bug 75276] Implement VGPR Register Spilling

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

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

--- Comment #44 from Michel D?nzer  ---
(In reply to comment #43)
> FYI, while other games doesn't crash anymore with llvm-3.5/mesa-10.2.7
> (painkiller, the cave, serious sam), br?tal legends horribly crash's my
> system with this versions.

The Br?tal Legend issue might be unrelated to this bug report then and should
be tracked in a separate report for now.

-- 
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/20140917/0a8f83ea/attachment.html>

[Bug 83748] Only black content on screen, in the Tokyo flashback of the game "The Secret World"

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

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

--- Comment #6 from John  ---
How would I trim them less ?
Did I use a wrong command?

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/20140917/3ec4819f/attachment.html>

[Bug 83748] Only black content on screen, in the Tokyo flashback of the game "The Secret World"

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

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

--- Comment #5 from Michel D?nzer  ---
I'm afraid these traces are trimmed down too much, I can't replay them:

0 @2 glBindBufferARB(target = GL_ARRAY_BUFFER, buffer = 17)
0: warning: no current context
1 @2 glMapBufferRange(target = GL_ELEMENT_ARRAY_BUFFER, offset = 0, length =
20480, access = GL_MAP_READ_BIT | GL_MAP_WRITE_BIT | GL_MAP_FLUSH_EXPLICIT_BIT)
= 0xee18d000
1: warning: no current context
glretrace: ../retrace/retrace_swizzle.cpp:137: void retrace::addRegion(long
long unsigned int, void*, long long unsigned int): Assertion `buffer' failed.

-- 
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/20140917/6f792821/attachment.html>

[Bug 83800] 3DMark2003 crashes radeon with wine 1.7.26 + gallium nine

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

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

--- Comment #7 from Michel D?nzer  ---
Does it always happen at the same point in 3DMark2003, or randomly? If the
former, can you create an apitrace reproducing the crash?

-- 
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/20140917/9b421b29/attachment.html>

[PATCH] drm/exynos: fix plane-framebuffer linkage

[Daniel Drake]

On Wed, Sep 17, 2014 at 1:44 AM, Joonyoung Shim  
wrote:
> It's problem to add this from commit 25c8b5c3048cb6c98d402ca8d4735ccf910f727c.

My patch moves that drm_framebuffer_reference() call to the plane
function which is called from crtc_mode_set context (and also called
in crtc pageflip path), so there should be no problem here.

> Chip specific drm driver internally doesn't have to care fb reference count if
> there is no special case. We should have switched to universal plane at that
> time.

To me it seems like the chip-specific DRM drivers do need to add a
reference in the crtc_mode_set and crtc page flip paths otherwise
framebuffer removal crashes (expecting to remove 3 references), as
noted by my testing and also in commit 25c8b5c304.

However, I'll be happy if universal planes means the driver does not
have to care about this any more. Andrej, please go ahead if you are
interested, I'll be happy to test your results.

Thanks
Daniel

[Bug 83331] radeon: Laptop panel out of sync after dpms standby/suspend/off

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

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

--- Comment #8 from Klaus Kusche  ---
Created attachment 150591
  --> https://bugzilla.kernel.org/attachment.cgi?id=150591=edit
Kernel boot log with printk timings

Interesting part goes from 2.35 to 7.77

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