[PATCH V4 2/2] video: drm: exynos: Add device tree support

[Kyungmin Park]

Hi,

On Thu, Sep 6, 2012 at 12:39 AM, Leela Krishna Amudala
 wrote:
> Add device tree based discovery support for DRM-FIMD driver.
>
> Signed-off-by: Leela Krishna Amudala 
> ---
>  Documentation/devicetree/bindings/fb/drm-fimd.txt |   80 +
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c  |   95 
> -
>  2 files changed, 173 insertions(+), 2 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/fb/drm-fimd.txt
>
> diff --git a/Documentation/devicetree/bindings/fb/drm-fimd.txt 
> b/Documentation/devicetree/bindings/fb/drm-fimd.txt
> new file mode 100644
> index 000..4ff1829
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/fb/drm-fimd.txt
> @@ -0,0 +1,80 @@
> +* Samsung Display Controller using DRM frame work
> +
> +The display controller is used to transfer image data from memory to an
> +external LCD driver interface. It supports various color formats such as
> +rgb and yuv.
> +
> +Required properties:
> + - compatible: Should be "samsung,exynos5-fimd" or "samsung,exynos4-fb" for
Doesn't better to use single word? fimd or fb?. I think 'fb' is used
for framebuffer historically.
but now it's used both fb and drm, so fimd is neutral and architecture
specific.

To do this, Modify arch-exynos first and update it at each drivers it properly.

Thank you,
Kyungmin Park

> +   fimd using DRM frame work.
> + - reg: physical base address of the controller and length of memory
> +   mapped region.
> + - interrupts: Three interrupts should be specified. The interrupts should be
> +   specified in the following order.
> +   - VSYNC interrupt
> +   - FIFO level interrupt
> +   - FIMD System Interrupt
> +
> + - samsung,fimd-display: This property should specify the phandle of the
> +   display device node which holds the video interface timing with the
> +   below mentioned properties.
> +
> +   - lcd-htiming: Specifies the horizontal timing for the overlay. The
> + horizontal timing includes four parameters in the following order.
> +
> + - horizontal back porch (in number of lcd clocks)
> + - horizontal front porch (in number of lcd clocks)
> + - hsync pulse width (in number of lcd clocks)
> + - Display panels X resolution.
> +
> +   - lcd-vtiming: Specifies the vertical timing for the overlay. The
> + vertical timing includes four parameters in the following order.
> +
> + - vertical back porch (in number of lcd lines)
> + - vertical front porch (in number of lcd lines)
> + - vsync pulse width (in number of lcd clocks)
> + - Display panels Y resolution.
> +
> +
> + - samsung,default-window: Specifies the default window number of the fimd 
> controller.
> +
> + - samsung,fimd-win-bpp: Specifies the bits per pixel.
> +
> +Optional properties:
> + - samsung,fimd-vidout-rgb: Video output format is RGB.
> + - samsung,fimd-inv-vclk: invert video clock polarity.
> + - samsung,fimd-frame-rate: Number of video frames per second.
> +
> +Example:
> +
> +   The following is an example for the fimd controller is split into
> +   two portions. The SoC specific portion can be specified in the SoC
> +   specific dts file. The board specific portion can be specified in the
> +   board specific dts file.
> +
> +   - SoC Specific portion
> +
> +   fimd {
> +   compatible = "samsung,exynos5-fimd";
> +   interrupt-parent = <>;
> +   reg = <0x1440 0x4>;
> +   interrupts = <18 5>, <18 4>, <18 6>;
> +   };
> +
> +   - Board Specific portion
> +
> +   lcd_fimd0: lcd_panel0 {
> +   lcd-htiming = <4 4 4 480>;
> +   lcd-vtiming = <4 4 4 320>;
> +   supports-mipi-panel;
> +   };
> +
> +   fimd {
> +   samsung,fimd-display = <_fimd0>;
> +   samsung,fimd-vidout-rgb;
> +   samsung,fimd-inv-vclk;
> +   samsung,fimd-frame-rate = <60>;
> +   samsung,default-window = <0>;
> +   samsung,fimd-win-bpp = <32>;
> +   };
> +
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 3701fbe..a4fa8e9 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -18,6 +18,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include 
>  #include 
> @@ -103,9 +104,18 @@ struct fimd_context {
> struct exynos_drm_panel_info *panel;
>  };
>
> +static const struct of_device_id fimd_dt_match[];
> +
>  static inline struct fimd_driver_data *drm_fimd_get_driver_data(
> struct platform_device *pdev)
>  {
> +#ifdef CONFIG_OF
> +   if (pdev->dev.of_node) {
> +   const struct of_device_id *match;
> +   match = of_match_ptr(fimd_dt_match);
> +   return (struct fimd_driver_data *)match->data;
> +   }
> +#endif
> return (struct fimd_driver_data *)
> 

[PATCH V4 2/2] video: drm: exynos: Add device tree support

[Leela Krishna Amudala]

Add device tree based discovery support for DRM-FIMD driver.

Signed-off-by: Leela Krishna Amudala 
---
 Documentation/devicetree/bindings/fb/drm-fimd.txt |   80 +
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  |   95 -
 2 files changed, 173 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/fb/drm-fimd.txt

diff --git a/Documentation/devicetree/bindings/fb/drm-fimd.txt 
b/Documentation/devicetree/bindings/fb/drm-fimd.txt
new file mode 100644
index 000..4ff1829
--- /dev/null
+++ b/Documentation/devicetree/bindings/fb/drm-fimd.txt
@@ -0,0 +1,80 @@
+* Samsung Display Controller using DRM frame work
+
+The display controller is used to transfer image data from memory to an
+external LCD driver interface. It supports various color formats such as
+rgb and yuv.
+
+Required properties:
+ - compatible: Should be "samsung,exynos5-fimd" or "samsung,exynos4-fb" for
+   fimd using DRM frame work.
+ - reg: physical base address of the controller and length of memory
+   mapped region.
+ - interrupts: Three interrupts should be specified. The interrupts should be
+   specified in the following order.
+   - VSYNC interrupt
+   - FIFO level interrupt
+   - FIMD System Interrupt
+
+ - samsung,fimd-display: This property should specify the phandle of the
+   display device node which holds the video interface timing with the
+   below mentioned properties.
+
+   - lcd-htiming: Specifies the horizontal timing for the overlay. The
+ horizontal timing includes four parameters in the following order.
+
+ - horizontal back porch (in number of lcd clocks)
+ - horizontal front porch (in number of lcd clocks)
+ - hsync pulse width (in number of lcd clocks)
+ - Display panels X resolution.
+
+   - lcd-vtiming: Specifies the vertical timing for the overlay. The
+ vertical timing includes four parameters in the following order.
+
+ - vertical back porch (in number of lcd lines)
+ - vertical front porch (in number of lcd lines)
+ - vsync pulse width (in number of lcd clocks)
+ - Display panels Y resolution.
+
+
+ - samsung,default-window: Specifies the default window number of the fimd 
controller.
+
+ - samsung,fimd-win-bpp: Specifies the bits per pixel.
+
+Optional properties:
+ - samsung,fimd-vidout-rgb: Video output format is RGB.
+ - samsung,fimd-inv-vclk: invert video clock polarity.
+ - samsung,fimd-frame-rate: Number of video frames per second.
+
+Example:
+
+   The following is an example for the fimd controller is split into
+   two portions. The SoC specific portion can be specified in the SoC
+   specific dts file. The board specific portion can be specified in the
+   board specific dts file.
+
+   - SoC Specific portion
+
+   fimd {
+   compatible = "samsung,exynos5-fimd";
+   interrupt-parent = <>;
+   reg = <0x1440 0x4>;
+   interrupts = <18 5>, <18 4>, <18 6>;
+   };
+
+   - Board Specific portion
+
+   lcd_fimd0: lcd_panel0 {
+   lcd-htiming = <4 4 4 480>;
+   lcd-vtiming = <4 4 4 320>;
+   supports-mipi-panel;
+   };
+
+   fimd {
+   samsung,fimd-display = <_fimd0>;
+   samsung,fimd-vidout-rgb;
+   samsung,fimd-inv-vclk;
+   samsung,fimd-frame-rate = <60>;
+   samsung,default-window = <0>;
+   samsung,fimd-win-bpp = <32>;
+   };
+
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 3701fbe..a4fa8e9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
@@ -103,9 +104,18 @@ struct fimd_context {
struct exynos_drm_panel_info *panel;
 };

+static const struct of_device_id fimd_dt_match[];
+
 static inline struct fimd_driver_data *drm_fimd_get_driver_data(
struct platform_device *pdev)
 {
+#ifdef CONFIG_OF
+   if (pdev->dev.of_node) {
+   const struct of_device_id *match;
+   match = of_match_ptr(fimd_dt_match);
+   return (struct fimd_driver_data *)match->data;
+   }
+#endif
return (struct fimd_driver_data *)
platform_get_device_id(pdev)->driver_data;
 }
@@ -809,12 +819,77 @@ static int fimd_power_on(struct fimd_context *ctx, bool 
enable)
return 0;
 }

+#ifdef CONFIG_OF
+static struct exynos_drm_fimd_pdata *drm_fimd_dt_parse_pdata(struct device 
*dev)
+{
+   struct device_node *np = dev->of_node;
+   struct device_node *disp_np;
+   struct exynos_drm_fimd_pdata *pd;
+   u32 data[4];
+
+   pd = devm_kzalloc(dev, sizeof(*pd), GFP_KERNEL);
+   if (!pd) {
+   dev_err(dev, "memory allocation for pdata failed\n");
+   return ERR_PTR(-ENOMEM);
+   }
+
+ 

[PATCH V4 1/2] drm/exynos: add platform_device_id table and driver data for drm fimd

[Leela Krishna Amudala]

The name of the exynos drm fimd device is renamed to exynos-drm-fimd
and two device ids are created for exynos4-fb and exynos5-fb.
Also, added driver data for exynos4 and exynos5 to pick the timing base address
at runtime to write data into appropriate register address.

Signed-off-by: Leela Krishna Amudala 
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c |   45 ++---
 1 files changed, 40 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 24c0bd4..3701fbe 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -57,6 +57,18 @@

 #define get_fimd_context(dev)  platform_get_drvdata(to_platform_device(dev))

+struct fimd_driver_data {
+   unsigned int timing_base;
+};
+
+struct fimd_driver_data exynos4_fimd_driver_data = {
+   .timing_base = 0x0,
+};
+
+struct fimd_driver_data exynos5_fimd_driver_data = {
+   .timing_base = 0x2,
+};
+
 struct fimd_win_data {
unsigned intoffset_x;
unsigned intoffset_y;
@@ -91,6 +103,13 @@ struct fimd_context {
struct exynos_drm_panel_info *panel;
 };

+static inline struct fimd_driver_data *drm_fimd_get_driver_data(
+   struct platform_device *pdev)
+{
+   return (struct fimd_driver_data *)
+   platform_get_device_id(pdev)->driver_data;
+}
+
 static bool fimd_display_is_connected(struct device *dev)
 {
DRM_DEBUG_KMS("%s\n", __FILE__);
@@ -194,32 +213,35 @@ static void fimd_commit(struct device *dev)
struct fimd_context *ctx = get_fimd_context(dev);
struct exynos_drm_panel_info *panel = ctx->panel;
struct fb_videomode *timing = >timing;
+   struct fimd_driver_data *driver_data;
+   struct platform_device *pdev = to_platform_device(dev);
u32 val;

+   driver_data = drm_fimd_get_driver_data(pdev);
if (ctx->suspended)
return;

DRM_DEBUG_KMS("%s\n", __FILE__);

/* setup polarity values from machine code. */
-   writel(ctx->vidcon1, ctx->regs + VIDCON1);
+   writel(ctx->vidcon1, ctx->regs + driver_data->timing_base + VIDCON1);

/* setup vertical timing values. */
val = VIDTCON0_VBPD(timing->upper_margin - 1) |
   VIDTCON0_VFPD(timing->lower_margin - 1) |
   VIDTCON0_VSPW(timing->vsync_len - 1);
-   writel(val, ctx->regs + VIDTCON0);
+   writel(val, ctx->regs + driver_data->timing_base + VIDTCON0);

/* setup horizontal timing values.  */
val = VIDTCON1_HBPD(timing->left_margin - 1) |
   VIDTCON1_HFPD(timing->right_margin - 1) |
   VIDTCON1_HSPW(timing->hsync_len - 1);
-   writel(val, ctx->regs + VIDTCON1);
+   writel(val, ctx->regs + driver_data->timing_base + VIDTCON1);

/* setup horizontal and vertical display size. */
val = VIDTCON2_LINEVAL(timing->yres - 1) |
   VIDTCON2_HOZVAL(timing->xres - 1);
-   writel(val, ctx->regs + VIDTCON2);
+   writel(val, ctx->regs + driver_data->timing_base + VIDTCON2);

/* setup clock source, clock divider, enable dma. */
val = ctx->vidcon0;
@@ -982,6 +1004,18 @@ static int fimd_runtime_resume(struct device *dev)
 }
 #endif

+static struct platform_device_id fimd_driver_ids[] = {
+   {
+   .name   = "exynos4-fb",
+   .driver_data= (unsigned long)_fimd_driver_data,
+   }, {
+   .name   = "exynos5-fb",
+   .driver_data= (unsigned long)_fimd_driver_data,
+   },
+   {},
+};
+MODULE_DEVICE_TABLE(platform, fimd_driver_ids);
+
 static const struct dev_pm_ops fimd_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(fimd_suspend, fimd_resume)
SET_RUNTIME_PM_OPS(fimd_runtime_suspend, fimd_runtime_resume, NULL)
@@ -990,8 +1024,9 @@ static const struct dev_pm_ops fimd_pm_ops = {
 struct platform_driver fimd_driver = {
.probe  = fimd_probe,
.remove = __devexit_p(fimd_remove),
+   .id_table   = fimd_driver_ids,
.driver = {
-   .name   = "exynos4-fb",
+   .name   = "exynos-drm-fimd",
.owner  = THIS_MODULE,
.pm = _pm_ops,
},
-- 
1.7.0.4

[PATCH V4 0/2] video: drm: Add Device tree support to DRM-FIMD

[Leela Krishna Amudala]

This patch set adds device tree support for DRM-FIMD for Samsung's Exynos5250.
It includes parsing platform data from dts file. Also, adds the driver data
for exynos4 and exynos5 devices.

This patchset is based and tested on top of v3.6-rc4
Also depends on below patchset
http://lists.freedesktop.org/archives/dri-devel/2012-August/026076.html

Changes since V3:
- Removed the fimd version from driver data and using timing base
  address instead
- Removed the drm_ prefixes to the structures and fucntions

Changes since V2:
- Added driver data to exynos5-drm-fimd as per Marek Szyprowski 
suggestion

Changes since V1:
- Corrected typo errors and changed compatibility string

Leela Krishna Amudala (2):
  drm/exynos: add platform_device_id table and driver data for drm fimd
  video: drm: exynos: Add device tree support

 Documentation/devicetree/bindings/fb/drm-fimd.txt |   80 
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  |  140 +++-
 2 files changed, 213 insertions(+), 7 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/fb/drm-fimd.txt

[Bug 41265] Radeon KMS does not work on thunderbolt media dock

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

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

Florian Mickler  changed:

   What|Removed |Added

 CC||florian at mickler.org

--- Comment #52 from Florian Mickler  2012-09-05 
20:41:16 UTC ---
A patch referencing this bug report has been merged in Linux v3.6-rc3:

commit c61e2775873f603148e8e998a938721b7d222d24
Author: Alex Deucher 
Date:   Thu Aug 16 15:39:09 2012 -0400

drm/radeon: split ATRM support out from the ATPX handler (v3)

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

[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot

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

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

Florian Mickler  changed:

   What|Removed |Added

 CC||florian at mickler.org

--- Comment #37 from Florian Mickler  2012-09-05 
20:39:27 UTC ---
A patch referencing this bug report has been merged in Linux v3.6-rc3:

commit 268ba0a99f89a84dc5eb312470896113d0709c74
Author: David Lamparter 
Date:   Thu Aug 16 15:45:20 2012 -0400

drm/radeon: implement ACPI VFCT vbios fetch (v3)

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

[PATCH] drm/exynos: add dummy support for dmabuf-mmap

[Inki Dae]

From: Tomasz Stanislawski 

This patch adds a stub function for DMABUF mmap.
This allows to export a DMABUF.

Signed-off-by: Tomasz Stanislawski 
Signed-off-by: Kyungmin Park 
Signed-off-by: Inki Dae 
---
 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c 
b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
index 613bf8a..ae13feb 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
@@ -163,6 +163,12 @@ static void exynos_gem_dmabuf_kunmap(struct dma_buf 
*dma_buf,
/* TODO */
 }

+static int exynos_gem_dmabuf_mmap(struct dma_buf *dma_buf,
+   struct vm_area_struct *vma)
+{
+   return -ENOTTY;
+}
+
 static struct dma_buf_ops exynos_dmabuf_ops = {
.map_dma_buf= exynos_gem_map_dma_buf,
.unmap_dma_buf  = exynos_gem_unmap_dma_buf,
@@ -170,6 +176,7 @@ static struct dma_buf_ops exynos_dmabuf_ops = {
.kmap_atomic= exynos_gem_dmabuf_kmap_atomic,
.kunmap = exynos_gem_dmabuf_kunmap,
.kunmap_atomic  = exynos_gem_dmabuf_kunmap_atomic,
+   .mmap   = exynos_gem_dmabuf_mmap,
.release= exynos_dmabuf_release,
 };

-- 
1.7.4.1

[Bug 42490] NUTMEG DP to VGA bridge not working

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

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

--- Comment #31 from Alex Deucher  2012-09-05 18:34:56 UTC 
---
Please try my 3.6 fixes tree (should show up in 3.6.0rc4+ and eventually stable
kernels).
http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-fixes-3.6

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

[Bug 42490] NUTMEG DP to VGA bridge not working

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

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

lukenshiro at ngi.it changed:

   What|Removed |Added

 CC||lukenshiro at ngi.it

--- Comment #30 from lukenshiro at ngi.it 2012-09-05 18:31:11 UTC ---
I have a similar problem: right after boot, my screen works (displays kernel
messages) until maybe drm module is loaded (I guess by udev), then it becomes
immediately blank and monitor is blinking, and then works again some time after
fbcon and radeon modules are manually loaded in boot scripts (before starting
X).
It depends on modeset=1; if I use modeset=0 this behaviour doesn't appear, bua
X cannot run without KMS.

I have an AMD A4-3300 APU and using a (vanilla) linux kernel 3.5.3 (on
Slackware64)

The real problem is that some time (a couple of minutes or so) after video
adapter is in idle mode (e.g. if I am not using the PC), monitor blinks (as in
low power mode) screen is blank and system is no longer recoverable (unless I
use e.g. ssh just to power it off).
I don't know if the two problems are really related or not. Voltage problems?

I have these messages in dmesg, too, when it happens:
"""
[ 2405.888198] [drm:radeon_atom_encoder_dpms], encoder dpms 33 to mode 0,
devices 0001, active_devices 0001
[ 2405.892352] [drm:radeon_dp_get_link_status], link status 44 44 01 00 44 44
[ 2405.892360] [drm:dp_get_adjust_train], requested signal parameters: lane 0
voltage 0.4V pre_emph 3.5dB
[ 2405.892365] [drm:dp_get_adjust_train], using signal parameters: voltage 0.4V
pre_emph 3.5dB
[ 2405.893921] [drm:radeon_dp_get_link_status], link status 44 44 01 00 48 44
[ 2405.893926] [drm:dp_get_adjust_train], requested signal parameters: lane 0
voltage 0.4V pre_emph 6dB
[ 2405.893931] [drm:dp_get_adjust_train], using signal parameters: voltage 0.4V
pre_emph 6dB
[ 2405.895508] [drm:radeon_dp_get_link_status], link status 44 44 01 00 4c 44
[ 2405.895514] [drm:dp_get_adjust_train], requested signal parameters: lane 0
voltage 0.4V pre_emph 9.5dB
[ 2405.895518] [drm:dp_get_adjust_train], using signal parameters: voltage 0.4V
pre_emph 9.5dB
[ 2405.897079] [drm:radeon_dp_get_link_status], link status 44 44 01 00 41 44
[ 2405.897085] [drm:dp_get_adjust_train], requested signal parameters: lane 0
voltage 0.6V pre_emph 0dB
[ 2405.897089] [drm:dp_get_adjust_train], using signal parameters: voltage 0.6V
pre_emph 0dB
[ 2405.898632] [drm:radeon_dp_get_link_status], link status 44 44 01 00 45 44
[ 2405.898634] [drm:dp_get_adjust_train], requested signal parameters: lane 0
voltage 0.6V pre_emph 3.5dB
[ 2405.898636] [drm:dp_get_adjust_train], using signal parameters: voltage 0.6V
pre_emph 3.5dB
[ 2405.900152] [drm:radeon_dp_get_link_status], link status 44 44 01 00 49 44
[ 2405.900155] [drm:dp_get_adjust_train], requested signal parameters: lane 0
voltage 0.6V pre_emph 6dB
[ 2405.900156] [drm:dp_get_adjust_train], using signal parameters: voltage 0.6V
pre_emph 6dB
[ 2405.901674] [drm:radeon_dp_get_link_status], link status 44 44 01 00 42 44
[ 2405.901676] [drm:dp_get_adjust_train], requested signal parameters: lane 0
voltage 0.8V pre_emph 0dB
[ 2405.901677] [drm:dp_get_adjust_train], using signal parameters: voltage 0.8V
pre_emph 0dB
[ 2405.903194] [drm:radeon_dp_get_link_status], link status 44 44 01 00 46 44
[ 2405.903196] [drm:dp_get_adjust_train], requested signal parameters: lane 0
voltage 0.8V pre_emph 3.5dB
[ 2405.903197] [drm:dp_get_adjust_train], using signal parameters: voltage 0.8V
pre_emph 3.5dB
[ 2405.904715] [drm:radeon_dp_get_link_status], link status 44 44 01 00 43 44
[ 2405.904717] [drm:dp_get_adjust_train], requested signal parameters: lane 0
voltage 1.2V pre_emph 0dB
[ 2405.904718] [drm:dp_get_adjust_train], using signal parameters: voltage 1.2V
pre_emph 0dB
[ 2405.906235] [drm:radeon_dp_get_link_status], link status 44 44 01 00 43 44
[ 2405.906238] [drm:radeon_dp_link_train_cr] *ERROR* clock recovery reached max
voltage
[ 2405.906240] [drm:radeon_dp_link_train_cr] *ERROR* clock recovery failed
"""

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

3.5-rc7: nouveau doesn't X on NVC0

[Linus Torvalds]

[ This got dropped somehow - it's in my draft folder. The bisection
may be irrelevant now: does it work with current git, since we've had
some nouveau changes? ]

On Tue, Aug 28, 2012 at 8:26 AM, Alexey Dobriyan  wrote:
> Ping!
>
> No X for me with 3.6-rc2.

Can you possibly bisect it, at least partially? Just knowing exactly
where it started might help the nouveau developers,

Linus

[Patch 0/1]drm_irq: Introducing the irq_thread support

[Daniel Vetter]

On Wed, Sep 05, 2012 at 03:12:39PM +, Shi, Yang A wrote:
> Hi Vetter:
> 
> Do you mean we can just not use drm_irq_install, and make
> request_irq in our kernel driver pre-install or post-install
> interface?

Well, you cant use the pre_install/post_install hooks the drm_irq code
provides, but yes, just do the request_irq in your driver code at the
right time, with the right parameters. Much easier than adding code to a
part of the drm core fraught with backwards-compat stuff no one really
wants to touch ... All the additional stuff besides calling request_irq
and the driver hooks that drm_irq_install does is really just to support
old dri1 userspace.

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

[Bug 52997] evergreen_cs_track_validate_cb:477 cb[0] bo too small when launching ds2 in wine

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

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

--- Comment #6 from mailbox.tec at gmail.com 2012-09-05 17:30:02 UTC ---
Created attachment 66689
  --> https://bugs.freedesktop.org/attachment.cgi?id=66689
X.org server varlog

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

[Bug 52997] evergreen_cs_track_validate_cb:477 cb[0] bo too small when launching ds2 in wine

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

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

--- Comment #5 from mailbox.tec at gmail.com 2012-09-05 17:22:26 UTC ---
Created attachment 66688
  --> https://bugs.freedesktop.org/attachment.cgi?id=66688
Messages from dmesg after running BGMain.exe in fullscreen.

Hello

I am experiencing the same issue with Wine 1.5.12 and Baldur's Gate.

The issue appears when BGMain.exe is launched fullscreen, without virtual
desktop. In virtual desktop mode, it seems to be running fine. Also, if window
switching is attempted (Ctrl+Tab) with game in fullscreen, tiny video output
appears, occupying roughly 1/4th of screen resolution (which in full is
1280x1024) in top-left corner, the rest remaining black. It's very pixelated
and shows game's main menu. With futher switching, it shows different desktop
windows (if open), but latency is very low. Regardless of video output, sound
is still played through alsa.

In my case, output from running the executable is:

radeon: The kernel rejected CS, see dmesg for more information.
fixme:win:EnumDisplayDevicesW ((null),0,0x329c48,0x), stub!
fixme:d3d_surface:wined3d_surface_flip Ignoring flags 0x1.

uname:
Linux 3.5.3-2-ck x86_64

glxinfo:
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD BARTS
OpenGL version string: 2.1 Mesa 8.0.4
OpenGL shading language version string: 1.20

libdrm_radeon version is 1.0.1

Possible duplicate: https://bugs.freedesktop.org/show_bug.cgi?id=47244

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

[PATCH] drm/omap: update for interlaced

[Rob Clark]

From: Rob Clark 

'struct omap_video_timings' was updated w/ a 'bool interlaced'.  Without
a matching update in omap_connector, this field could have undefined
values from the stack, which isn't quite ideal.

Update the fxns to convert omapdss<->drm timings structs, and zero-init
'struct omap_video_timings' when it is declared on stack to avoid issues
like this in the future.

Signed-off-by: Rob Clark 
---
 drivers/staging/omapdrm/omap_connector.c |   17 -
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/omapdrm/omap_connector.c 
b/drivers/staging/omapdrm/omap_connector.c
index 5e2856c..5f4a89b 100644
--- a/drivers/staging/omapdrm/omap_connector.c
+++ b/drivers/staging/omapdrm/omap_connector.c
@@ -48,13 +48,10 @@ static inline void copy_timings_omap_to_drm(struct 
drm_display_mode *mode,
mode->vsync_end = mode->vsync_start + timings->vsw;
mode->vtotal = mode->vsync_end + timings->vbp;

-   /* note: whether or not it is interlaced, +/- h/vsync, etc,
-* which should be set in the mode flags, is not exposed in
-* the omap_video_timings struct.. but hdmi driver tracks
-* those separately so all we have to have to set the mode
-* is the way to recover these timings values, and the
-* omap_dss_driver would do the rest.
-*/
+   mode->flags = 0;
+
+   if (timings->interlace)
+   mode->flags |= DRM_MODE_FLAG_INTERLACE;
 }

 static inline void copy_timings_drm_to_omap(struct omap_video_timings *timings,
@@ -71,6 +68,8 @@ static inline void copy_timings_drm_to_omap(struct 
omap_video_timings *timings,
timings->vfp = mode->vsync_start - mode->vdisplay;
timings->vsw = mode->vsync_end - mode->vsync_start;
timings->vbp = mode->vtotal - mode->vsync_end;
+
+   timings->interlace = !!(mode->flags & DRM_MODE_FLAG_INTERLACE);
 }

 static void omap_connector_dpms(struct drm_connector *connector, int mode)
@@ -187,7 +186,7 @@ static int omap_connector_get_modes(struct drm_connector 
*connector)
}
} else {
struct drm_display_mode *mode = drm_mode_create(dev);
-   struct omap_video_timings timings;
+   struct omap_video_timings timings = {0};

dssdrv->get_timings(dssdev, );

@@ -291,7 +290,7 @@ void omap_connector_mode_set(struct drm_connector 
*connector,
struct omap_connector *omap_connector = to_omap_connector(connector);
struct omap_dss_device *dssdev = omap_connector->dssdev;
struct omap_dss_driver *dssdrv = dssdev->driver;
-   struct omap_video_timings timings;
+   struct omap_video_timings timings = {0};

copy_timings_drm_to_omap(, mode);

-- 
1.7.9.5

[PATCH] drm: refcnt drm_framebuffer

[Rob Clark]

From: Rob Clark 

This simplifies drm fb lifetime, and if the crtc/plane needs to hold
a ref to the fb when disabling a pipe until the next vblank, this
avoids the need to make disabling an overlay synchronous.  This is a
problem that shows up when userspace is using a drm plane to
implement a hw cursor.. making overlay disable synchronous causes
a performance problem when x11 is rapidly enabling/disabling the
hw cursor.  But not making it synchronous opens up a race condition
for crashing if userspace turns around and immediately deletes the
fb.  Refcnt'ing the fb makes it possible to solve this problem.

v1: original
v2: add drm_framebuffer_remove() which is called in all paths where
fb->funcs->destroy() was directly called before.  This cleans
up the CRTCs/planes that the fb was attached to.  You should
only directly use drm_framebuffer_unreference() if you are also
using drm_framebuffer_reference() to keep a ref to the fb.
v3: add comment explaining the fb refcount
v4: remove duplicate 'list_del(>filp_head)'

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/drm_crtc.c|   79 -
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |4 +-
 drivers/gpu/drm/i915/intel_display.c  |4 +-
 drivers/staging/omapdrm/omap_fbdev.c  |4 +-
 include/drm/drm_crtc.h|   14 +
 5 files changed, 87 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 901de9a..7552675 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -294,6 +294,8 @@ int drm_framebuffer_init(struct drm_device *dev, struct 
drm_framebuffer *fb,
 {
int ret;

+   kref_init(>refcount);
+
ret = drm_mode_object_get(dev, >base, DRM_MODE_OBJECT_FB);
if (ret)
return ret;
@@ -307,6 +309,38 @@ int drm_framebuffer_init(struct drm_device *dev, struct 
drm_framebuffer *fb,
 }
 EXPORT_SYMBOL(drm_framebuffer_init);

+static void drm_framebuffer_free(struct kref *kref)
+{
+   struct drm_framebuffer *fb =
+   container_of(kref, struct drm_framebuffer, refcount);
+   fb->funcs->destroy(fb);
+}
+
+/**
+ * drm_framebuffer_unreference - unref a framebuffer
+ *
+ * LOCKING:
+ * Caller must hold mode config lock.
+ */
+void drm_framebuffer_unreference(struct drm_framebuffer *fb)
+{
+   struct drm_device *dev = fb->dev;
+   DRM_DEBUG("FB ID: %d\n", fb->base.id);
+   WARN_ON(!mutex_is_locked(>mode_config.mutex));
+   kref_put(>refcount, drm_framebuffer_free);
+}
+EXPORT_SYMBOL(drm_framebuffer_unreference);
+
+/**
+ * drm_framebuffer_reference - incr the fb refcnt
+ */
+void drm_framebuffer_reference(struct drm_framebuffer *fb)
+{
+   DRM_DEBUG("FB ID: %d\n", fb->base.id);
+   kref_get(>refcount);
+}
+EXPORT_SYMBOL(drm_framebuffer_reference);
+
 /**
  * drm_framebuffer_cleanup - remove a framebuffer object
  * @fb: framebuffer to remove
@@ -320,6 +354,32 @@ EXPORT_SYMBOL(drm_framebuffer_init);
 void drm_framebuffer_cleanup(struct drm_framebuffer *fb)
 {
struct drm_device *dev = fb->dev;
+   /*
+* This could be moved to drm_framebuffer_remove(), but for
+* debugging is nice to keep around the list of fb's that are
+* no longer associated w/ a drm_file but are not unreferenced
+* yet.  (i915 and omapdrm have debugfs files which will show
+* this.)
+*/
+   drm_mode_object_put(dev, >base);
+   list_del(>head);
+   dev->mode_config.num_fb--;
+}
+EXPORT_SYMBOL(drm_framebuffer_cleanup);
+
+/**
+ * drm_framebuffer_remove - remove and unreference a framebuffer object
+ * @fb: framebuffer to remove
+ *
+ * LOCKING:
+ * Caller must hold mode config lock.
+ *
+ * Scans all the CRTCs and planes in @dev's mode_config.  If they're
+ * using @fb, removes it, setting it to NULL.
+ */
+void drm_framebuffer_remove(struct drm_framebuffer *fb)
+{
+   struct drm_device *dev = fb->dev;
struct drm_crtc *crtc;
struct drm_plane *plane;
struct drm_mode_set set;
@@ -350,11 +410,11 @@ void drm_framebuffer_cleanup(struct drm_framebuffer *fb)
}
}

-   drm_mode_object_put(dev, >base);
-   list_del(>head);
-   dev->mode_config.num_fb--;
+   list_del(>filp_head);
+
+   drm_framebuffer_unreference(fb);
 }
-EXPORT_SYMBOL(drm_framebuffer_cleanup);
+EXPORT_SYMBOL(drm_framebuffer_remove);

 /**
  * drm_crtc_init - Initialise a new CRTC object
@@ -1032,7 +1092,7 @@ void drm_mode_config_cleanup(struct drm_device *dev)
}

list_for_each_entry_safe(fb, fbt, >mode_config.fb_list, head) {
-   fb->funcs->destroy(fb);
+   drm_framebuffer_remove(fb);
}

list_for_each_entry_safe(crtc, ct, >mode_config.crtc_list, head) {
@@ -2343,11 +2403,7 @@ int drm_mode_rmfb(struct drm_device *dev,
goto out;
}

-   /* TODO release all crtc connected 

[PATCH] drm: refcnt drm_framebuffer

[Rob Clark]

On Wed, Sep 5, 2012 at 1:17 PM, Rob Clark  wrote:
> From: Rob Clark 
>
> This simplifies drm fb lifetime, and if the crtc/plane needs to hold
> a ref to the fb when disabling a pipe until the next vblank, this
> avoids the need to make disabling an overlay synchronous.  This is a
> problem that shows up when userspace is using a drm plane to
> implement a hw cursor.. making overlay disable synchronous causes
> a performance problem when x11 is rapidly enabling/disabling the
> hw cursor.  But not making it synchronous opens up a race condition
> for crashing if userspace turns around and immediately deletes the
> fb.  Refcnt'ing the fb makes it possible to solve this problem.
>
> v1: original
> v2: add drm_framebuffer_remove() which is called in all paths where
> fb->funcs->destroy() was directly called before.  This cleans
> up the CRTCs/planes that the fb was attached to.  You should
> only directly use drm_framebuffer_unreference() if you are also
> using drm_framebuffer_reference() to keep a ref to the fb.
> v3: add comment explaining the fb refcount
>
> Signed-off-by: Rob Clark 
> Reviewed-by: Daniel Vetter 
>
> ---
>  drivers/gpu/drm/drm_crtc.c|   78 
> +
>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c |4 +-
>  drivers/gpu/drm/i915/intel_display.c  |4 +-
>  drivers/staging/omapdrm/omap_fbdev.c  |4 +-
>  include/drm/drm_crtc.h|   14 ++
>  5 files changed, 87 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 901de9a..96e236f 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -294,6 +294,8 @@ int drm_framebuffer_init(struct drm_device *dev, struct 
> drm_framebuffer *fb,
>  {
> int ret;
>
> +   kref_init(>refcount);
> +
> ret = drm_mode_object_get(dev, >base, DRM_MODE_OBJECT_FB);
> if (ret)
> return ret;
> @@ -307,6 +309,38 @@ int drm_framebuffer_init(struct drm_device *dev, struct 
> drm_framebuffer *fb,
>  }
>  EXPORT_SYMBOL(drm_framebuffer_init);
>
> +static void drm_framebuffer_free(struct kref *kref)
> +{
> +   struct drm_framebuffer *fb =
> +   container_of(kref, struct drm_framebuffer, refcount);
> +   fb->funcs->destroy(fb);
> +}
> +
> +/**
> + * drm_framebuffer_unreference - unref a framebuffer
> + *
> + * LOCKING:
> + * Caller must hold mode config lock.
> + */
> +void drm_framebuffer_unreference(struct drm_framebuffer *fb)
> +{
> +   struct drm_device *dev = fb->dev;
> +   DRM_DEBUG("FB ID: %d\n", fb->base.id);
> +   WARN_ON(!mutex_is_locked(>mode_config.mutex));
> +   kref_put(>refcount, drm_framebuffer_free);
> +}
> +EXPORT_SYMBOL(drm_framebuffer_unreference);
> +
> +/**
> + * drm_framebuffer_reference - incr the fb refcnt
> + */
> +void drm_framebuffer_reference(struct drm_framebuffer *fb)
> +{
> +   DRM_DEBUG("FB ID: %d\n", fb->base.id);
> +   kref_get(>refcount);
> +}
> +EXPORT_SYMBOL(drm_framebuffer_reference);
> +
>  /**
>   * drm_framebuffer_cleanup - remove a framebuffer object
>   * @fb: framebuffer to remove
> @@ -320,6 +354,32 @@ EXPORT_SYMBOL(drm_framebuffer_init);
>  void drm_framebuffer_cleanup(struct drm_framebuffer *fb)
>  {
> struct drm_device *dev = fb->dev;
> +   /*
> +* This could be moved to drm_framebuffer_remove(), but for
> +* debugging is nice to keep around the list of fb's that are
> +* no longer associated w/ a drm_file but are not unreferenced
> +* yet.  (i915 and omapdrm have debugfs files which will show
> +* this.)
> +*/
> +   drm_mode_object_put(dev, >base);
> +   list_del(>head);
> +   dev->mode_config.num_fb--;
> +}
> +EXPORT_SYMBOL(drm_framebuffer_cleanup);
> +
> +/**
> + * drm_framebuffer_remove - remove and unreference a framebuffer object
> + * @fb: framebuffer to remove
> + *
> + * LOCKING:
> + * Caller must hold mode config lock.
> + *
> + * Scans all the CRTCs and planes in @dev's mode_config.  If they're
> + * using @fb, removes it, setting it to NULL.
> + */
> +void drm_framebuffer_remove(struct drm_framebuffer *fb)
> +{
> +   struct drm_device *dev = fb->dev;
> struct drm_crtc *crtc;
> struct drm_plane *plane;
> struct drm_mode_set set;
> @@ -350,11 +410,11 @@ void drm_framebuffer_cleanup(struct drm_framebuffer *fb)
> }
> }
>
> -   drm_mode_object_put(dev, >base);
> -   list_del(>head);
> -   dev->mode_config.num_fb--;
> +   list_del(>filp_head);
> +
> +   drm_framebuffer_unreference(fb);
>  }
> -EXPORT_SYMBOL(drm_framebuffer_cleanup);
> +EXPORT_SYMBOL(drm_framebuffer_remove);
>
>  /**
>   * drm_crtc_init - Initialise a new CRTC object
> @@ -1032,7 +1092,7 @@ void drm_mode_config_cleanup(struct drm_device *dev)
> }
>
> list_for_each_entry_safe(fb, fbt, >mode_config.fb_list, head) {
> -   

[Bug 54527] Crash, kernel BUG ttm/ttm_bo.c:1659!, when running gnibbles

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

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

--- Comment #2 from Bryan Quigley  2012-09-05 
15:43:07 UTC ---
Just tested with 3.6-rc4.  It is indeed fixed (gnibbles still crashes but just
the program ~ I think that's it's fault)

Should I mark as fixed or wait until 3.6 releases?

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

[Patch 0/1]drm_irq: Introducing the irq_thread support

[Daniel Vetter]

On Wed, Sep 05, 2012 at 01:53:44AM +, Liu, Chuansheng wrote:
> This patch is for introducing the irq thread support in drm_irq.
> 
> Why we need irq thread in drm_irq code?
> In our GPU system, the gpu interrupt handler need some time even > 1ms to 
> finish,
> in that case, the whole system will stay in irq disable status. One case is:
> when audio is playing, it sometimes effects the audio quality.
> 
> So we have to introduce the irq thread in drm_irq, it can help us move some 
> heavy work into irq thread
> and other irq interrupts can be handled in time. Also the IRQF_ONESHOT is 
> helpful for irq thread.
> 
> Include one patch:
> [PATCH 01/1] drm_irq-Introducing-the-irq_thread-support

For a kms drm driver (and tbh, doing a non-kms driver today is not a great
idea), there's no reason to use the drm_irq_install/_unistall helpers.

So if you driver has special needs wrt irq handling that don't neatly fit
what the drm_irq stuff provides, simply don't use it - all the generic
code that's there is just to keep non-kms userspace going.

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

[Patch 0/1]drm_irq: Introducing the irq_thread support

[Shi, Yang A]

Hi Vetter:

Do you mean we can just not use drm_irq_install, and make request_irq in 
our kernel driver pre-install or post-install interface?






Best Regards.
Yang Shi

PSI,System Integration, SH
E-mail:yang.a.shi at intel.com
Tel:88215666-4239


-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Wednesday, September 05, 2012 9:27 PM
To: Liu, Chuansheng
Cc: 'linux-kernel at vger.kernel.org' (linux-kernel at vger.kernel.org); 
dri-devel at lists.freedesktop.org; alexander.deucher at amd.com; airlied at 
redhat.com; Shi, Yang A
Subject: Re: [Patch 0/1]drm_irq: Introducing the irq_thread support

On Wed, Sep 05, 2012 at 01:53:44AM +, Liu, Chuansheng wrote:
> This patch is for introducing the irq thread support in drm_irq.
> 
> Why we need irq thread in drm_irq code?
> In our GPU system, the gpu interrupt handler need some time even > 1ms 
> to finish, in that case, the whole system will stay in irq disable status. 
> One case is:
> when audio is playing, it sometimes effects the audio quality.
> 
> So we have to introduce the irq thread in drm_irq, it can help us move 
> some heavy work into irq thread and other irq interrupts can be handled in 
> time. Also the IRQF_ONESHOT is helpful for irq thread.
> 
> Include one patch:
> [PATCH 01/1] drm_irq-Introducing-the-irq_thread-support

For a kms drm driver (and tbh, doing a non-kms driver today is not a great 
idea), there's no reason to use the drm_irq_install/_unistall helpers.

So if you driver has special needs wrt irq handling that don't neatly fit what 
the drm_irq stuff provides, simply don't use it - all the generic code that's 
there is just to keep non-kms userspace going.

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

[PATCH] drm: use %*ph to dump small buffers

[Andy Shevchenko]

Signed-off-by: Andy Shevchenko 
---
 drivers/gpu/drm/nouveau/nouveau_dp.c |4 +---
 drivers/gpu/drm/radeon/atombios_dp.c |4 +---
 drivers/gpu/drm/udl/udl_main.c   |7 ++-
 3 files changed, 4 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c 
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index 7e289d2..e754aa3 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dp.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
@@ -289,9 +289,7 @@ dp_link_train_update(struct drm_device *dev, struct 
dp_state *dp, u32 delay)
if (ret)
return ret;

-   NV_DEBUG_KMS(dev, "status %02x %02x %02x %02x %02x %02x\n",
-dp->stat[0], dp->stat[1], dp->stat[2], dp->stat[3],
-dp->stat[4], dp->stat[5]);
+   NV_DEBUG_KMS(dev, "status %*ph\n", 6, dp->stat);
return 0;
 }

diff --git a/drivers/gpu/drm/radeon/atombios_dp.c 
b/drivers/gpu/drm/radeon/atombios_dp.c
index 3623b98..d48224b 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -653,9 +653,7 @@ static bool radeon_dp_get_link_status(struct 
radeon_connector *radeon_connector,
return false;
}

-   DRM_DEBUG_KMS("link status %02x %02x %02x %02x %02x %02x\n",
- link_status[0], link_status[1], link_status[2],
- link_status[3], link_status[4], link_status[5]);
+   DRM_DEBUG_KMS("link status %*ph\n", 6, link_status);
return true;
 }

diff --git a/drivers/gpu/drm/udl/udl_main.c b/drivers/gpu/drm/udl/udl_main.c
index 4c2d836..40bf468 100644
--- a/drivers/gpu/drm/udl/udl_main.c
+++ b/drivers/gpu/drm/udl/udl_main.c
@@ -41,11 +41,8 @@ static int udl_parse_vendor_descriptor(struct drm_device 
*dev,
total_len = usb_get_descriptor(usbdev, 0x5f, /* vendor specific */
0, desc, MAX_VENDOR_DESCRIPTOR_SIZE);
if (total_len > 5) {
-   DRM_INFO("vendor descriptor length:%x data:%02x %02x %02x %02x" 
\
-   "%02x %02x %02x %02x %02x %02x %02x\n",
-   total_len, desc[0],
-   desc[1], desc[2], desc[3], desc[4], desc[5], desc[6],
-   desc[7], desc[8], desc[9], desc[10]);
+   DRM_INFO("vendor descriptor length:%x data:%*ph\n",
+   total_len, 11, desc);

if ((desc[0] != total_len) || /* descriptor length */
(desc[1] != 0x5f) ||   /* vendor descriptor type */
-- 
1.7.10.4

[PATCH] drm/exynos: fix double call of drm_prime_(init/destroy)_file_private

[Mandeep Singh Baines]

The double invocations are incorrect but seem to be safe so I don't
think this will fix any bugs.

Before:

[7.639366] drm_prime_init_file ee3675d0
[7.639377] drm_prime_init_file ee3675d0
[7.639507] drm_prime_destroy_file ee3675d0
[7.639518] drm_prime_destroy_file ee3675d0
[7.639802] drm_prime_init_file ee372390
[7.639810] drm_prime_init_file ee372390
[8.473316] drm_prime_init_file ee356390
[8.473331] drm_prime_init_file ee356390

After:

[6.363842] drm_prime_init_file edc2e5d0
[6.363994] drm_prime_destroy_file edc2e5d0
[6.364260] drm_prime_init_file edc2e750
[8.004837] drm_prime_init_file ee36ded0

Signed-off-by: Mandeep Singh Baines 
CC: St?phane Marchesin 
CC: Pawel Osciak 
CC: Inki Dae 
CC: Joonyoung Shim 
CC: Seung-Woo Kim 
CC: Kyungmin Park 
CC: David Airlie 
CC: dri-devel at lists.freedesktop.org
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index ebacec6..a27b8ff 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -160,7 +160,6 @@ static int exynos_drm_open(struct drm_device *dev, struct 
drm_file *file)
if (!file_priv)
return -ENOMEM;

-   drm_prime_init_file_private(>prime);
file->driver_priv = file_priv;

return exynos_drm_subdrv_open(dev, file);
@@ -184,7 +183,6 @@ static void exynos_drm_preclose(struct drm_device *dev,
e->base.destroy(>base);
}
}
-   drm_prime_destroy_file_private(>prime);
spin_unlock_irqrestore(>event_lock, flags);

exynos_drm_subdrv_close(dev, file);
-- 
1.7.7.3

[PATCH libdrm] libkms: fix the name of the intel driver in linux_sysfs_create

[Ander Conselvan de Oliveira]

From: Ander Conselvan de Oliveira 

linux_sysfs_create() checked for a driver named "intel" while the intel
driver is called "i915". This went unnoticed because in kernels 2.6.39
and after this code path was never reached because of the dumb buffer
interface. On earlier kernels, kms_create() would fail.

Signed-off-by: Ander Conselvan de Oliveira 
---
 libkms/linux.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/libkms/linux.c b/libkms/linux.c
index fc4f205..dde74f7 100644
--- a/libkms/linux.c
+++ b/libkms/linux.c
@@ -101,7 +101,7 @@ linux_from_sysfs(int fd, struct kms_driver **out)
if (ret)
return ret;

-   if (!strcmp(name, "intel"))
+   if (!strcmp(name, "i915"))
ret = intel_create(fd, out);
 #ifdef HAVE_VMWGFX
else if (!strcmp(name, "vmwgfx"))
-- 
1.7.4.1

[Patch 0/1]drm_irq: Introducing the irq_thread support

[Alan Cox]

On Wed, 5 Sep 2012 01:53:44 +
"Liu, Chuansheng"  wrote:

> This patch is for introducing the irq thread support in drm_irq.
> 
> Why we need irq thread in drm_irq code?
> In our GPU system, the gpu interrupt handler need some time even > 1ms to 
> finish,
> in that case, the whole system will stay in irq disable status. One case is:
> when audio is playing, it sometimes effects the audio quality.

This possibly ought to be submitted in parallel with the code that uses it
so that the whole proposal can be evaluated as one thing ?

Alan

[PATCH] drm: refcnt drm_framebuffer

[Rob Clark]

From: Rob Clark 

This simplifies drm fb lifetime, and if the crtc/plane needs to hold
a ref to the fb when disabling a pipe until the next vblank, this
avoids the need to make disabling an overlay synchronous.  This is a
problem that shows up when userspace is using a drm plane to
implement a hw cursor.. making overlay disable synchronous causes
a performance problem when x11 is rapidly enabling/disabling the
hw cursor.  But not making it synchronous opens up a race condition
for crashing if userspace turns around and immediately deletes the
fb.  Refcnt'ing the fb makes it possible to solve this problem.

v1: original
v2: add drm_framebuffer_remove() which is called in all paths where
fb->funcs->destroy() was directly called before.  This cleans
up the CRTCs/planes that the fb was attached to.  You should
only directly use drm_framebuffer_unreference() if you are also
using drm_framebuffer_reference() to keep a ref to the fb.
v3: add comment explaining the fb refcount

Signed-off-by: Rob Clark 
Reviewed-by: Daniel Vetter 

---
 drivers/gpu/drm/drm_crtc.c|   78 +
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |4 +-
 drivers/gpu/drm/i915/intel_display.c  |4 +-
 drivers/staging/omapdrm/omap_fbdev.c  |4 +-
 include/drm/drm_crtc.h|   14 ++
 5 files changed, 87 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 901de9a..96e236f 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -294,6 +294,8 @@ int drm_framebuffer_init(struct drm_device *dev, struct 
drm_framebuffer *fb,
 {
int ret;

+   kref_init(>refcount);
+
ret = drm_mode_object_get(dev, >base, DRM_MODE_OBJECT_FB);
if (ret)
return ret;
@@ -307,6 +309,38 @@ int drm_framebuffer_init(struct drm_device *dev, struct 
drm_framebuffer *fb,
 }
 EXPORT_SYMBOL(drm_framebuffer_init);

+static void drm_framebuffer_free(struct kref *kref)
+{
+   struct drm_framebuffer *fb =
+   container_of(kref, struct drm_framebuffer, refcount);
+   fb->funcs->destroy(fb);
+}
+
+/**
+ * drm_framebuffer_unreference - unref a framebuffer
+ *
+ * LOCKING:
+ * Caller must hold mode config lock.
+ */
+void drm_framebuffer_unreference(struct drm_framebuffer *fb)
+{
+   struct drm_device *dev = fb->dev;
+   DRM_DEBUG("FB ID: %d\n", fb->base.id);
+   WARN_ON(!mutex_is_locked(>mode_config.mutex));
+   kref_put(>refcount, drm_framebuffer_free);
+}
+EXPORT_SYMBOL(drm_framebuffer_unreference);
+
+/**
+ * drm_framebuffer_reference - incr the fb refcnt
+ */
+void drm_framebuffer_reference(struct drm_framebuffer *fb)
+{
+   DRM_DEBUG("FB ID: %d\n", fb->base.id);
+   kref_get(>refcount);
+}
+EXPORT_SYMBOL(drm_framebuffer_reference);
+
 /**
  * drm_framebuffer_cleanup - remove a framebuffer object
  * @fb: framebuffer to remove
@@ -320,6 +354,32 @@ EXPORT_SYMBOL(drm_framebuffer_init);
 void drm_framebuffer_cleanup(struct drm_framebuffer *fb)
 {
struct drm_device *dev = fb->dev;
+   /*
+* This could be moved to drm_framebuffer_remove(), but for
+* debugging is nice to keep around the list of fb's that are
+* no longer associated w/ a drm_file but are not unreferenced
+* yet.  (i915 and omapdrm have debugfs files which will show
+* this.)
+*/
+   drm_mode_object_put(dev, >base);
+   list_del(>head);
+   dev->mode_config.num_fb--;
+}
+EXPORT_SYMBOL(drm_framebuffer_cleanup);
+
+/**
+ * drm_framebuffer_remove - remove and unreference a framebuffer object
+ * @fb: framebuffer to remove
+ *
+ * LOCKING:
+ * Caller must hold mode config lock.
+ *
+ * Scans all the CRTCs and planes in @dev's mode_config.  If they're
+ * using @fb, removes it, setting it to NULL.
+ */
+void drm_framebuffer_remove(struct drm_framebuffer *fb)
+{
+   struct drm_device *dev = fb->dev;
struct drm_crtc *crtc;
struct drm_plane *plane;
struct drm_mode_set set;
@@ -350,11 +410,11 @@ void drm_framebuffer_cleanup(struct drm_framebuffer *fb)
}
}

-   drm_mode_object_put(dev, >base);
-   list_del(>head);
-   dev->mode_config.num_fb--;
+   list_del(>filp_head);
+
+   drm_framebuffer_unreference(fb);
 }
-EXPORT_SYMBOL(drm_framebuffer_cleanup);
+EXPORT_SYMBOL(drm_framebuffer_remove);

 /**
  * drm_crtc_init - Initialise a new CRTC object
@@ -1032,7 +1092,7 @@ void drm_mode_config_cleanup(struct drm_device *dev)
}

list_for_each_entry_safe(fb, fbt, >mode_config.fb_list, head) {
-   fb->funcs->destroy(fb);
+   drm_framebuffer_remove(fb);
}

list_for_each_entry_safe(crtc, ct, >mode_config.crtc_list, head) {
@@ -2343,11 +2403,8 @@ int drm_mode_rmfb(struct drm_device *dev,
goto out;
}

-   /* TODO release all crtc connected to the 

[PATCH 1/3] drm/radeon: do not reenable crtc after moving vram start address

[Brad Campbell]

On 28/07/12 04:32, j.glisse at gmail.com wrote:
> From: Jerome Glisse 
>
> It seems we can not update the crtc scanout address. After disabling
> crtc, update to base address do not take effect after crtc being
> reenable leading to at least frame being scanout from the old crtc
> base address. Disabling crtc display request lead to same behavior.
>
> So after changing the vram address if we don't keep crtc disabled
> we will have the GPU trying to read some random system memory address
> with some iommu this will broke the crtc engine and will lead to
> broken display and iommu error message.
>
> So to avoid this, disable crtc. For flicker less boot we will need
> to avoid moving the vram start address.
>
> This patch should also fix :
>
> https://bugs.freedesktop.org/show_bug.cgi?id=42373

G'day Jerome,

I'm running a Mid 2011, iMac with three heads. Card :
01:00.0 VGA compatible controller: ATI Technologies Inc Device 6720

To make this usable (ie to not cook the machine), I must force the card 
into low power mode which I do with this patch :

diff --git a/drivers/gpu/drm/radeon/radeon_pm.c 
b/drivers/gpu/drm/radeon/radeon_pm.c
index 6fabe89..de85eda 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -102,7 +102,7 @@ static void radeon_pm_update_profile(struct 
radeon_device *rdev)
break;
case PM_PROFILE_LOW:
if (rdev->pm.active_crtc_count > 1)
-   rdev->pm.profile_index = PM_PROFILE_LOW_MH_IDX;
+   rdev->pm.profile_index = PM_PROFILE_LOW_SH_IDX;
else
rdev->pm.profile_index = PM_PROFILE_LOW_SH_IDX;
break;

The patch this mail refers to causes moving corruption (like noise) on 
about the right hand 1/3rd of the primary monitor.

Reverting either of these patches makes the corruption go away, however 
reverting my patch makes the machine unusable as it simply cooks.

I also have to revert : [PATCH] drm/radeon: fix bo creation retry path 
or the machine simply panics at X login, however I see that has already 
been queued for reversion.

Any advice you could offer to assist me in sorting this would be much 
appreciated.

Regards,
Brad.

[PATCH] drm: refcnt drm_framebuffer

[Daniel Vetter]

On Tue, Sep 04, 2012 at 06:10:04PM -0500, Rob Clark wrote:
> From: Rob Clark 
> 
> This simplifies drm fb lifetime, and if the crtc/plane needs to hold
> a ref to the fb when disabling a pipe until the next vblank, this
> avoids the need to make disabling an overlay synchronous.  This is a
> problem that shows up when userspace is using a drm plane to
> implement a hw cursor.. making overlay disable synchronous causes
> a performance problem when x11 is rapidly enabling/disabling the
> hw cursor.  But not making it synchronous opens up a race condition
> for crashing if userspace turns around and immediately deletes the
> fb.  Refcnt'ing the fb makes it possible to solve this problem.
> 
> v1: original
> v2: add drm_framebuffer_remove() which is called in all paths where
> fb->funcs->destroy() was directly called before.  This cleans
> up the CRTCs/planes that the fb was attached to.  You should
> only directly use drm_framebuffer_unreference() if you are also
> using drm_framebuffer_reference() to keep a ref to the fb.
> 
> Signed-off-by: Rob Clark 

Yeah, this could also be rather useful to move a few things to saner
places in drm/i915. The fb->refcount is a bit strange though since only
driver-internals can be reference counted, all the userspace interface
stuff in the drm core has to abide to the old api which mandates that we
remove all uses of a given fb at rmfb time. I guess we'll just have to
live with that.

Still, can you add a small comment in drm_crtc.h to the new refcount
explaining this? And maybe extend the note about the ->destroy callback to
say "call _remove or _unrefence instead"? Otherwise

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/drm_crtc.c|   78 
> +
>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c |4 +-
>  drivers/gpu/drm/i915/intel_display.c  |4 +-
>  drivers/staging/omapdrm/omap_fbdev.c  |4 +-
>  include/drm/drm_crtc.h|5 ++
>  5 files changed, 78 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 901de9a..96e236f 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -294,6 +294,8 @@ int drm_framebuffer_init(struct drm_device *dev, struct 
> drm_framebuffer *fb,
>  {
>   int ret;
>  
> + kref_init(>refcount);
> +
>   ret = drm_mode_object_get(dev, >base, DRM_MODE_OBJECT_FB);
>   if (ret)
>   return ret;
> @@ -307,6 +309,38 @@ int drm_framebuffer_init(struct drm_device *dev, struct 
> drm_framebuffer *fb,
>  }
>  EXPORT_SYMBOL(drm_framebuffer_init);
>  
> +static void drm_framebuffer_free(struct kref *kref)
> +{
> + struct drm_framebuffer *fb =
> + container_of(kref, struct drm_framebuffer, refcount);
> + fb->funcs->destroy(fb);
> +}
> +
> +/**
> + * drm_framebuffer_unreference - unref a framebuffer
> + *
> + * LOCKING:
> + * Caller must hold mode config lock.
> + */
> +void drm_framebuffer_unreference(struct drm_framebuffer *fb)
> +{
> + struct drm_device *dev = fb->dev;
> + DRM_DEBUG("FB ID: %d\n", fb->base.id);
> + WARN_ON(!mutex_is_locked(>mode_config.mutex));
> + kref_put(>refcount, drm_framebuffer_free);
> +}
> +EXPORT_SYMBOL(drm_framebuffer_unreference);
> +
> +/**
> + * drm_framebuffer_reference - incr the fb refcnt
> + */
> +void drm_framebuffer_reference(struct drm_framebuffer *fb)
> +{
> + DRM_DEBUG("FB ID: %d\n", fb->base.id);
> + kref_get(>refcount);
> +}
> +EXPORT_SYMBOL(drm_framebuffer_reference);
> +
>  /**
>   * drm_framebuffer_cleanup - remove a framebuffer object
>   * @fb: framebuffer to remove
> @@ -320,6 +354,32 @@ EXPORT_SYMBOL(drm_framebuffer_init);
>  void drm_framebuffer_cleanup(struct drm_framebuffer *fb)
>  {
>   struct drm_device *dev = fb->dev;
> + /*
> +  * This could be moved to drm_framebuffer_remove(), but for
> +  * debugging is nice to keep around the list of fb's that are
> +  * no longer associated w/ a drm_file but are not unreferenced
> +  * yet.  (i915 and omapdrm have debugfs files which will show
> +  * this.)
> +  */
> + drm_mode_object_put(dev, >base);
> + list_del(>head);
> + dev->mode_config.num_fb--;
> +}
> +EXPORT_SYMBOL(drm_framebuffer_cleanup);
> +
> +/**
> + * drm_framebuffer_remove - remove and unreference a framebuffer object
> + * @fb: framebuffer to remove
> + *
> + * LOCKING:
> + * Caller must hold mode config lock.
> + *
> + * Scans all the CRTCs and planes in @dev's mode_config.  If they're
> + * using @fb, removes it, setting it to NULL.
> + */
> +void drm_framebuffer_remove(struct drm_framebuffer *fb)
> +{
> + struct drm_device *dev = fb->dev;
>   struct drm_crtc *crtc;
>   struct drm_plane *plane;
>   struct drm_mode_set set;
> @@ -350,11 +410,11 @@ void drm_framebuffer_cleanup(struct drm_framebuffer *fb)
>   }
>   }
>  
> - drm_mode_object_put(dev, >base);
> - 

[PATCH] drm/prime: drop reference on imported dma-buf

[Daniel Vetter]

On Tue, Sep 04, 2012 at 05:32:21PM -0500, Rob Clark wrote:
> Dave, I just noticed that I still have this patch locally, but don't
> see it in drm-next..  so just checking that it didn't get forgotten

My locking fixes blew up :(
-Daniel

> 
> BR,
> -R
> 
> On Tue, Jul 24, 2012 at 3:05 AM, Daniel Vetter  wrote:
> > On Tue, Jul 24, 2012 at 1:07 AM, Rob Clark  wrote:
> >> From: Rob Clark 
> >>
> >> The GEM handle takes the reference.  If a driver is actually importing a
> >> foreign dmabuf, rather than just re-importing it's own dmabuf, it needs
> >> to do a get_dma_buf().
> >>
> >> Signed-off-by: Rob Clark 
> > [Maybe mention that this is on top of my locking fixes.]
> >
> > We've discussed this a bit on irc and concluded that every function taking
> > care of their own references to the dma buf works best in avoiding
> > potential use-after-free issues when evil userspaces sneaks in a
> > close(dma_buf_fd).
> >
> > Reviewed-by: Daniel Vetter 
> >> ---
> >>  drivers/gpu/drm/drm_prime.c|7 +++
> >>  drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |4 
> >>  drivers/gpu/drm/i915/i915_gem_dmabuf.c |4 
> >>  drivers/gpu/drm/nouveau/nouveau_prime.c|5 +
> >>  drivers/gpu/drm/radeon/radeon_prime.c  |4 
> >>  drivers/gpu/drm/udl/udl_gem.c  |4 
> >>  6 files changed, 28 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> >> index 4f80374..088e018 100644
> >> --- a/drivers/gpu/drm/drm_prime.c
> >> +++ b/drivers/gpu/drm/drm_prime.c
> >> @@ -185,6 +185,13 @@ int drm_gem_prime_fd_to_handle(struct drm_device *dev,
> >> mutex_unlock(_priv->prime.lock);
> >> drm_gem_object_unreference_unlocked(obj);
> >>
> >> +   /*
> >> +* Drop the ref we obtained w/ dma_buf_get() for the benefit of
> >> +* drivers simply re-importing their own dma-buf.. if drivers
> >> +* import a foreign dma-buf, they should get_dma_buf().
> >> +*/
> >> +   dma_buf_put(dma_buf);
> >> +
> >> return 0;
> >>
> >>  fail:
> >> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c 
> >> b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
> >> index f270790..f8ac75b 100644
> >> --- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
> >> +++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
> >> @@ -190,6 +190,9 @@ struct drm_gem_object 
> >> *exynos_dmabuf_prime_import(struct drm_device *drm_dev,
> >> }
> >> }
> >>
> >> +   /* since we are attaching, we need to hold a ref */
> >> +   get_dma_buf(dma_buf);
> >> +
> >> attach = dma_buf_attach(dma_buf, drm_dev->dev);
> >> if (IS_ERR(attach))
> >> return ERR_PTR(-EINVAL);
> >> @@ -250,6 +253,7 @@ err_unmap_attach:
> >> dma_buf_unmap_attachment(attach, sgt, DMA_BIDIRECTIONAL);
> >>  err_buf_detach:
> >> dma_buf_detach(dma_buf, attach);
> >> +   dma_buf_put(dma_buf);
> >> return ERR_PTR(ret);
> >>  }
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c 
> >> b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> >> index cf6bdec..9d2b2eb 100644
> >> --- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> >> +++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> >> @@ -189,6 +189,9 @@ struct drm_gem_object *i915_gem_prime_import(struct 
> >> drm_device *dev,
> >> }
> >> }
> >>
> >> +   /* since we are attaching, we need to hold a ref */
> >> +   get_dma_buf(dma_buf);
> >> +
> >> /* need to attach */
> >> attach = dma_buf_attach(dma_buf, dev->dev);
> >> if (IS_ERR(attach))
> >> @@ -224,5 +227,6 @@ fail_unmap:
> >> dma_buf_unmap_attachment(attach, sg, DMA_BIDIRECTIONAL);
> >>  fail_detach:
> >> dma_buf_detach(dma_buf, attach);
> >> +   dma_buf_put(dma_buf);
> >> return ERR_PTR(ret);
> >>  }
> >> diff --git a/drivers/gpu/drm/nouveau/nouveau_prime.c 
> >> b/drivers/gpu/drm/nouveau/nouveau_prime.c
> >> index 4c82801..fc30886 100644
> >> --- a/drivers/gpu/drm/nouveau/nouveau_prime.c
> >> +++ b/drivers/gpu/drm/nouveau/nouveau_prime.c
> >> @@ -200,6 +200,10 @@ struct drm_gem_object 
> >> *nouveau_gem_prime_import(struct drm_device *dev,
> >> }
> >> }
> >> }
> >> +
> >> +   /* since we are attaching, we need to hold a ref */
> >> +   get_dma_buf(dma_buf);
> >> +
> >> /* need to attach */
> >> attach = dma_buf_attach(dma_buf, dev->dev);
> >> if (IS_ERR(attach))
> >> @@ -223,6 +227,7 @@ fail_unmap:
> >> dma_buf_unmap_attachment(attach, sg, DMA_BIDIRECTIONAL);
> >>  fail_detach:
> >> dma_buf_detach(dma_buf, attach);
> >> +   dma_buf_put(dma_buf);
> >> return ERR_PTR(ret);
> >>  }
> >>
> >> diff --git a/drivers/gpu/drm/radeon/radeon_prime.c 
> >> b/drivers/gpu/drm/radeon/radeon_prime.c
> >> index 28f79ac..073a8d3 100644
> >> --- a/drivers/gpu/drm/radeon/radeon_prime.c
> >> +++ 

[Patch 0/1]drm_irq: Introducing the irq_thread support

[Rob Clark]

On Wed, Sep 5, 2012 at 8:27 AM, Daniel Vetter  wrote:
> On Wed, Sep 05, 2012 at 01:53:44AM +, Liu, Chuansheng wrote:
>> This patch is for introducing the irq thread support in drm_irq.
>>
>> Why we need irq thread in drm_irq code?
>> In our GPU system, the gpu interrupt handler need some time even > 1ms to 
>> finish,
>> in that case, the whole system will stay in irq disable status. One case is:
>> when audio is playing, it sometimes effects the audio quality.
>>
>> So we have to introduce the irq thread in drm_irq, it can help us move some 
>> heavy work into irq thread
>> and other irq interrupts can be handled in time. Also the IRQF_ONESHOT is 
>> helpful for irq thread.
>>
>> Include one patch:
>> [PATCH 01/1] drm_irq-Introducing-the-irq_thread-support
>
> For a kms drm driver (and tbh, doing a non-kms driver today is not a great
> idea), there's no reason to use the drm_irq_install/_unistall helpers.
>
> So if you driver has special needs wrt irq handling that don't neatly fit
> what the drm_irq stuff provides, simply don't use it - all the generic
> code that's there is just to keep non-kms userspace going.

perhaps an easy thing would just be to allow the driver to provide
it's own request_irq?  That might be an easier way for devices that
need to register multiple irq's, etc?

Or is it better to just bypass and dev->irq_enabled=1?  That seemed a
bit like a hack to me, but the current irq code is more framework-ish,
and less helper-ish..

BR,
-R

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

[PATCH 1/3] drm/radeon: do not reenable crtc after moving vram start address

[Jerome Glisse]

On Wed, Sep 5, 2012 at 12:39 AM, Brad Campbell  wrote:
> On 28/07/12 04:32, j.glisse at gmail.com wrote:
>>
>> From: Jerome Glisse 
>>
>> It seems we can not update the crtc scanout address. After disabling
>> crtc, update to base address do not take effect after crtc being
>> reenable leading to at least frame being scanout from the old crtc
>> base address. Disabling crtc display request lead to same behavior.
>>
>> So after changing the vram address if we don't keep crtc disabled
>> we will have the GPU trying to read some random system memory address
>> with some iommu this will broke the crtc engine and will lead to
>> broken display and iommu error message.
>>
>> So to avoid this, disable crtc. For flicker less boot we will need
>> to avoid moving the vram start address.
>>
>> This patch should also fix :
>>
>> https://bugs.freedesktop.org/show_bug.cgi?id=42373
>
>
> G'day Jerome,
>
> I'm running a Mid 2011, iMac with three heads. Card :
> 01:00.0 VGA compatible controller: ATI Technologies Inc Device 6720
>
> To make this usable (ie to not cook the machine), I must force the card into
> low power mode which I do with this patch :
>
> diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
> b/drivers/gpu/drm/radeon/radeon_pm.c
> index 6fabe89..de85eda 100644
> --- a/drivers/gpu/drm/radeon/radeon_pm.c
> +++ b/drivers/gpu/drm/radeon/radeon_pm.c
> @@ -102,7 +102,7 @@ static void radeon_pm_update_profile(struct
> radeon_device *rdev)
> break;
> case PM_PROFILE_LOW:
> if (rdev->pm.active_crtc_count > 1)
> -   rdev->pm.profile_index = PM_PROFILE_LOW_MH_IDX;
> +   rdev->pm.profile_index = PM_PROFILE_LOW_SH_IDX;
> else
> rdev->pm.profile_index = PM_PROFILE_LOW_SH_IDX;
> break;
>
> The patch this mail refers to causes moving corruption (like noise) on about
> the right hand 1/3rd of the primary monitor.
>
> Reverting either of these patches makes the corruption go away, however
> reverting my patch makes the machine unusable as it simply cooks.
>
> I also have to revert : [PATCH] drm/radeon: fix bo creation retry path or
> the machine simply panics at X login, however I see that has already been
> queued for reversion.
>
> Any advice you could offer to assist me in sorting this would be much
> appreciated.
>
> Regards,
> Brad.

Low profile is not suited to drive 2 monitors and hence is not supported.

Cheers,
Jerome

[PATCH V3 1/2] drm/exynos: add platform_device_id table and driver data for exynos5 drm fimd

[Tomasz Figa]

Hi Leela,

See my comments inline.

On Thursday 16 of August 2012 12:08:08 Leela Krishna Amudala wrote:
> +enum fimd_version_type {
> + VERSION_8, /* FIMD_VERSION8 */
> +};
> +
> +struct drm_fimd_driver_data {
> + enum fimd_version_type fimd_ver;
> +};
> +
> +struct drm_fimd_driver_data exynos5_drm_fimd_driver_data = {
> + .fimd_ver = VERSION_8,
> +};

I think that the approach with timing_base, as suggested by Joonyoung Shim, 
would be much cleaner.

> +static struct platform_device_id exynos_drm_fimd_driver_ids[] = {
> + {
> + .name   = "exynos4-fb",
> + }, {
> + .name   = "exynos5-drm-fimd",
> + .driver_data= (unsigned long)_drm_fimd_driver_data,
> + },
> + {},
> +};
> +MODULE_DEVICE_TABLE(platform, exynos_drm_fimd_driver_ids);

If I see correctly, this will crash on a null pointer dereference on 
Exynos4 without DT, because of NULL driver_data.

P.S. I think you should CC linux-arm-kernel and linux-samsung-soc lists 
when submitting patches related to ARM and Samsung SoCs.

Best regards,
-- 
Tomasz Figa
Samsung Poland R Center

[PATCH V3 1/2] drm/exynos: add platform_device_id table and driver data for exynos5 drm fimd

[Leela Krishna Amudala]

Hi Tomasz,
Please find the inline comments.
Will post the next version today.

Thanks.
Leela Krishna Amudala.
--- Original Message ---
Sender : Tomasz Figa Junior Software Engineer/SPRC-Linux 
Platform (SSD)/Samsung Electronics
Date : Sep 05, 2012 13:22 (GMT+05:30)
Title : Re: [PATCH V3 1/2] drm/exynos: add platform_device_id table and driver 
data for exynos5 drm fimd

Hi Leela,

See my comments inline.

On Thursday 16 of August 2012 12:08:08 Leela Krishna Amudala wrote:
> +enum fimd_version_type {
> + VERSION_8, /* FIMD_VERSION8 */
> +};
> +
> +struct drm_fimd_driver_data {
> + enum fimd_version_type fimd_ver;
> +};
> +
> +struct drm_fimd_driver_data exynos5_drm_fimd_driver_data = {
> + .fimd_ver = VERSION_8,
> +};

I think that the approach with timing_base, as suggested by Joonyoung Shim, 
would be much cleaner.

Leela: Okay, will go with timing_base approach only

> +static struct platform_device_id exynos_drm_fimd_driver_ids[] = {
> + {
> + .name = "exynos4-fb",
> + }, {
> + .name = "exynos5-drm-fimd",
> + .driver_data = (unsigned long)_drm_fimd_driver_data,
> + },
> + {},
> +};
> +MODULE_DEVICE_TABLE(platform, exynos_drm_fimd_driver_ids);

If I see correctly, this will crash on a null pointer dereference on 
Exynos4 without DT, because of NULL driver_data.

Leela: yes, you are right, will take care of this

P.S. I think you should CC linux-arm-kernel and linux-samsung-soc lists 
when submitting patches related to ARM and Samsung SoCs.

Leela: Okay, will do it next time.

Best regards,
-- 
Tomasz Figa
Samsung Poland R Center

[Bug 54527] Crash, kernel BUG ttm/ttm_bo.c:1659!, when running gnibbles

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

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

--- Comment #1 from Michel D?nzer  2012-09-05 08:24:39 
UTC ---
Likely fixed by
https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=676bc2e1e4f9072f7a640d5b7c99ffdf9709a6e7
, which should be on its way to the 3.5 stable tree as well.

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

[Bug 54527] Crash, kernel BUG ttm/ttm_bo.c:1659!, when running gnibbles

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

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

Michel D?nzer  changed:

   What|Removed |Added

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

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

[PATCH] drm/prime: drop reference on imported dma-buf

[Rob Clark]

On Wed, Sep 5, 2012 at 4:02 AM, Daniel Vetter  wrote:
> On Tue, Sep 04, 2012 at 05:32:21PM -0500, Rob Clark wrote:
>> Dave, I just noticed that I still have this patch locally, but don't
>> see it in drm-next..  so just checking that it didn't get forgotten
>
> My locking fixes blew up :(

oh, ok.. I guess there was a thread that I missed..

BR,
-R

> -Daniel
>
>>
>> BR,
>> -R
>>
>> On Tue, Jul 24, 2012 at 3:05 AM, Daniel Vetter  wrote:
>> > On Tue, Jul 24, 2012 at 1:07 AM, Rob Clark  wrote:
>> >> From: Rob Clark 
>> >>
>> >> The GEM handle takes the reference.  If a driver is actually importing a
>> >> foreign dmabuf, rather than just re-importing it's own dmabuf, it needs
>> >> to do a get_dma_buf().
>> >>
>> >> Signed-off-by: Rob Clark 
>> > [Maybe mention that this is on top of my locking fixes.]
>> >
>> > We've discussed this a bit on irc and concluded that every function taking
>> > care of their own references to the dma buf works best in avoiding
>> > potential use-after-free issues when evil userspaces sneaks in a
>> > close(dma_buf_fd).
>> >
>> > Reviewed-by: Daniel Vetter 
>> >> ---
>> >>  drivers/gpu/drm/drm_prime.c|7 +++
>> >>  drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |4 
>> >>  drivers/gpu/drm/i915/i915_gem_dmabuf.c |4 
>> >>  drivers/gpu/drm/nouveau/nouveau_prime.c|5 +
>> >>  drivers/gpu/drm/radeon/radeon_prime.c  |4 
>> >>  drivers/gpu/drm/udl/udl_gem.c  |4 
>> >>  6 files changed, 28 insertions(+)
>> >>
>> >> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
>> >> index 4f80374..088e018 100644
>> >> --- a/drivers/gpu/drm/drm_prime.c
>> >> +++ b/drivers/gpu/drm/drm_prime.c
>> >> @@ -185,6 +185,13 @@ int drm_gem_prime_fd_to_handle(struct drm_device 
>> >> *dev,
>> >> mutex_unlock(_priv->prime.lock);
>> >> drm_gem_object_unreference_unlocked(obj);
>> >>
>> >> +   /*
>> >> +* Drop the ref we obtained w/ dma_buf_get() for the benefit of
>> >> +* drivers simply re-importing their own dma-buf.. if drivers
>> >> +* import a foreign dma-buf, they should get_dma_buf().
>> >> +*/
>> >> +   dma_buf_put(dma_buf);
>> >> +
>> >> return 0;
>> >>
>> >>  fail:
>> >> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c 
>> >> b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
>> >> index f270790..f8ac75b 100644
>> >> --- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
>> >> +++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
>> >> @@ -190,6 +190,9 @@ struct drm_gem_object 
>> >> *exynos_dmabuf_prime_import(struct drm_device *drm_dev,
>> >> }
>> >> }
>> >>
>> >> +   /* since we are attaching, we need to hold a ref */
>> >> +   get_dma_buf(dma_buf);
>> >> +
>> >> attach = dma_buf_attach(dma_buf, drm_dev->dev);
>> >> if (IS_ERR(attach))
>> >> return ERR_PTR(-EINVAL);
>> >> @@ -250,6 +253,7 @@ err_unmap_attach:
>> >> dma_buf_unmap_attachment(attach, sgt, DMA_BIDIRECTIONAL);
>> >>  err_buf_detach:
>> >> dma_buf_detach(dma_buf, attach);
>> >> +   dma_buf_put(dma_buf);
>> >> return ERR_PTR(ret);
>> >>  }
>> >>
>> >> diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c 
>> >> b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
>> >> index cf6bdec..9d2b2eb 100644
>> >> --- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
>> >> +++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
>> >> @@ -189,6 +189,9 @@ struct drm_gem_object *i915_gem_prime_import(struct 
>> >> drm_device *dev,
>> >> }
>> >> }
>> >>
>> >> +   /* since we are attaching, we need to hold a ref */
>> >> +   get_dma_buf(dma_buf);
>> >> +
>> >> /* need to attach */
>> >> attach = dma_buf_attach(dma_buf, dev->dev);
>> >> if (IS_ERR(attach))
>> >> @@ -224,5 +227,6 @@ fail_unmap:
>> >> dma_buf_unmap_attachment(attach, sg, DMA_BIDIRECTIONAL);
>> >>  fail_detach:
>> >> dma_buf_detach(dma_buf, attach);
>> >> +   dma_buf_put(dma_buf);
>> >> return ERR_PTR(ret);
>> >>  }
>> >> diff --git a/drivers/gpu/drm/nouveau/nouveau_prime.c 
>> >> b/drivers/gpu/drm/nouveau/nouveau_prime.c
>> >> index 4c82801..fc30886 100644
>> >> --- a/drivers/gpu/drm/nouveau/nouveau_prime.c
>> >> +++ b/drivers/gpu/drm/nouveau/nouveau_prime.c
>> >> @@ -200,6 +200,10 @@ struct drm_gem_object 
>> >> *nouveau_gem_prime_import(struct drm_device *dev,
>> >> }
>> >> }
>> >> }
>> >> +
>> >> +   /* since we are attaching, we need to hold a ref */
>> >> +   get_dma_buf(dma_buf);
>> >> +
>> >> /* need to attach */
>> >> attach = dma_buf_attach(dma_buf, dev->dev);
>> >> if (IS_ERR(attach))
>> >> @@ -223,6 +227,7 @@ fail_unmap:
>> >> dma_buf_unmap_attachment(attach, sg, DMA_BIDIRECTIONAL);
>> >>  fail_detach:
>> >> dma_buf_detach(dma_buf, attach);
>> >> +   dma_buf_put(dma_buf);
>> >> 

[Bug 54527] New: Crash, kernel BUG ttm/ttm_bo.c:1659!, when running gnibbles

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

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

 Bug #: 54527
   Summary: Crash,  kernel BUG ttm/ttm_bo.c:1659!, when running
gnibbles
Classification: Unclassified
   Product: DRI
   Version: XOrg CVS
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: BryanQuigley at Ubuntu.com


Created attachment 66652
  --> https://bugs.freedesktop.org/attachment.cgi?id=66652
kern log cutout

System completely crashes to panic screen when attempting to play gnibbles.
Usually at the end of the first level.

Steps to reproduce:
1. Set options, Speed: Finger-twitching good, Human players 1, AI Players 5
2. Game -> New Game
3. Wait for about 30 seconds till crash

I have yet to be able to recreate the crash on a 3.2 kernel (although it
eventually fails to continue playing).  The crash is easily reproduced on 3.5
(from Ubuntu's xorg-edgers).

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

[Patch 1/1]drm_irq: Introducing the irq_thread support

[Liu, Chuansheng]

From: liu chuansheng 
Subject: [PATCH] drm_irq: Introducing the irq_thread support

For some GPUs, the irq handler need >1ms to handle the irq action.
And it will delay the whole system irq handler.

This patch is adding the irq thread support, it will make the drm_irq
interface more flexible.

The changes include:
1/ Change the request_irq to request_thread_irq, and add new callback
   irq_handler_t;
2/ Normally we need IRQF_ONESHOT flag support for irq thread, so add
   this option in drm_irq;

Cc: Shi Yang 
Signed-off-by: liu chuansheng 
---
 drivers/gpu/drm/drm_irq.c |8 ++--
 include/drm/drmP.h|2 ++
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 03f16f3..bc105fe 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -345,13 +345,17 @@ int drm_irq_install(struct drm_device *dev)
if (drm_core_check_feature(dev, DRIVER_IRQ_SHARED))
sh_flags = IRQF_SHARED;

+   if (drm_core_check_feature(dev, DRIVER_IRQ_ONESHOT))
+   sh_flags |= IRQF_ONESHOT;
+
if (dev->devname)
irqname = dev->devname;
else
irqname = dev->driver->name;

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

if (ret < 0) {
mutex_lock(>struct_mutex);
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index d6b67bb..b28be4b 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -152,6 +152,7 @@ int drm_err(const char *func, const char *format, ...);
 #define DRIVER_GEM 0x1000
 #define DRIVER_MODESET 0x2000
 #define DRIVER_PRIME   0x4000
+#define DRIVER_IRQ_ONESHOT 0x8000

 #define DRIVER_BUS_PCI 0x1
 #define DRIVER_BUS_PLATFORM 0x2
@@ -872,6 +873,7 @@ struct drm_driver {
/* these have to be filled in */

irqreturn_t(*irq_handler) (DRM_IRQ_ARGS);
+   irqreturn_t(*irq_handler_t) (DRM_IRQ_ARGS);
void (*irq_preinstall) (struct drm_device *dev);
int (*irq_postinstall) (struct drm_device *dev);
void (*irq_uninstall) (struct drm_device *dev);
-- 
1.7.0.4

[Patch 0/1]drm_irq: Introducing the irq_thread support

[Liu, Chuansheng]

This patch is for introducing the irq thread support in drm_irq.

Why we need irq thread in drm_irq code?
In our GPU system, the gpu interrupt handler need some time even > 1ms to 
finish,
in that case, the whole system will stay in irq disable status. One case is:
when audio is playing, it sometimes effects the audio quality.

So we have to introduce the irq thread in drm_irq, it can help us move some 
heavy work into irq thread
and other irq interrupts can be handled in time. Also the IRQF_ONESHOT is 
helpful for irq thread.

Include one patch:
[PATCH 01/1] drm_irq-Introducing-the-irq_thread-support

[GIT PULL] drm/exynos: updated exynos-drm-fixes

[InKi Dae]

Hi Dave.

please do not pull it yet. this pull request includes a wrong patch so
I will fix it soon. sorry for inconvenient.

Thanks.
Inki Dae

2012/9/3 Inki Dae :
> Hi Dave,
>
> this patch set fixes build warnings and includes minor code cleanup.
> other patches posted before will go to -next because they include big changes.
>
> Highlights:
> - fix build warnings
> - minor code cleanup
>
> if there is any problem, please let me know.
>
> Thanks.
> Inki Dae
>
> The following changes since commit 350352dfef5028225b73994d304a38a4050d894b:
>
>   Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux 
> into drm-fixes (2012-09-03 11:29:56 +0900)
>
> are available in the git repository at:
>
>   git://git.infradead.org/users/kmpark/linux-samsung exynos-drm-fixes
>
> Inki Dae (2):
>   drm/exynos: added device object to subdrv's remove callback as argument
>   drm/exynos: fixed page align bug.
>
> Sachin Kamat (9):
>   drm/exynos: Remove redundant check in exynos_hdmi.c file
>   drm/exynos: Remove redundant check in exynos_drm_fimd.c file
>   drm/exynos: Use devm_kzalloc in exynos_drm_vidi.c file
>   drm/exynos: Use devm_kzalloc in exynos_drm_hdmi.c file
>   drm/exynos: Use devm_* functions in exynos_drm_g2d.c file
>   drm/exynos: Add dependency for G2D in Kconfig
>   drm/exynos: Make g2d_pm_ops static
>   drm/exynos: Add missing braces around sizeof in exynos_hdmi.c
>   drm/exynos: Add missing braces around sizeof in exynos_mixer.c
>
> Thomas Meyer (1):
>   drm/exynos: Use ERR_CAST inlined function instead of ERR_PTR(PTR_ERR(.. 
> [1]
>
>  drivers/gpu/drm/exynos/Kconfig   |2 +-
>  drivers/gpu/drm/exynos/exynos_drm_drv.h  |2 +-
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c |7 +---
>  drivers/gpu/drm/exynos/exynos_drm_g2d.c  |   52 ++---
>  drivers/gpu/drm/exynos/exynos_drm_gem.c  |4 +-
>  drivers/gpu/drm/exynos/exynos_drm_hdmi.c |3 +-
>  drivers/gpu/drm/exynos/exynos_drm_vidi.c |6 +--
>  drivers/gpu/drm/exynos/exynos_hdmi.c |   11 ++
>  drivers/gpu/drm/exynos/exynos_mixer.c|6 ++--
>  9 files changed, 25 insertions(+), 68 deletions(-)
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Linaro-mm-sig] A few questions about the best way to implement RandR 1.4 / PRIME buffer sharing

[Daniel Vetter]

On Tue, Sep 04, 2012 at 01:57:32PM -0700, Aaron Plattner wrote:
> On 08/31/2012 08:00 PM, Dave Airlie wrote:
> >Yes for 4 some sort of fencing is being worked on by Maarten for other stuff
> >but would be a pre-req for doing this, and also some devices don't want
> >fullscreen updates, like USB, so doing flipped updates would have to be
> >optional or negoitated. It makes sense for us as well since things like
> >gnome-shell can do full screen pageflips and we have to do full screen dirty
> >updates.
> 
> Right now my implementation has two sources of tearing:
> 
> 1. The dGPU reads the vidmem primary surface asynchronously from its own
>rendering to it.
> 
> 2. The iGPU fetches the shared surface for display asynchronously from the 
> dGPU
>writing into it.
> 
> #1 I can fix within our driver.  For #2, I don't want to rely on the dGPU 
> being
> able to push complete frames over the bus during vblank in response to an iGPU
> fence trigger so I was thinking we would want double-buffering all the time.
> Also, I was hoping to set up a proper flip chain between the dGPU, the dGPU's
> DMA engine, and the Intel display engine so that for full-screen applications,
> glXSwapBuffers is stalled properly without relying on the CPU to schedule
> things.  Maybe that's overly ambitious for now?

For the frontbuffer tearing Chris Wilson added a special mode to the SNA
intel driver that uses pageflips for all buffer updates (like windowized
Xv or dri2copybuffers), mostly because vsync'ed blits are busted on snb
(and not yet proved to be fixed on ivb). So we could use that mode for an
optimus platform.

Wrt the full flip-chain, that's what Maarten Lankhorst has running in his
proof-of-concept (but only for a second or so, since nouveau is totally
bust on his machine). The only place he wakes up the cpu is to sync from
nv to intel, but even there we can kick of the intel gpu directly from the
nv irq handler (with a simple register write). intel -> nv sync uses
memory based sequence numbers. Only proof of concept for rendering though,
iirc the fence support isn't wired up with the pageflipping on the intel
side yet.
-Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

Re: Kconfig DRM_USB/DRM_UDL, and select vs. depends, and causing Tegra USB to be disabled

[Guenter Roeck]

On Tue, Sep 04, 2012 at 01:19:12PM -0600, Stephen Warren wrote:
 With respect to the following commits:
 
 df0b344 drm/usb: select USB_SUPPORT in Kconfig
 8f057d7 gpu/mfd/usb: Fix USB randconfig problems
 
 ... which end up with the following in next-20120904:
 
 config DRM_USB
 depends on DRM
 depends on USB_ARCH_HAS_HCD
 select USB
 select USB_SUPPORT
 
 config DRM_UDL
 depends on DRM  EXPERIMENTAL
 depends on USB_ARCH_HAS_HCD
 select DRM_USB
 
 Surely this is backwards; these should be dependencies, not selects? In
 other words:
 
 config DRM_USB
 depends on DRM  USB
 
 config DRM_UDL
 depends on DRM  EXPERIMENTAL  USB
 select DRM_USB
 
 or perhaps:
 
 config DRM_USB
 depends on DRM  USB
 
 config DRM_UDL
 depends on DRM  EXPERIMENTAL  DRM_USB
 
 The problem here is that currently, the dependency logic for USB:
 
 config USB
   depends on USB_ARCH_HAS_HCD
 
 ... is duplicated into each of DRM_USB and DRM_UDL, thus requiring both
 of those to be edited should the dependencies for USB ever change.
 
This should be fixed with in https://patchwork.kernel.org/patch/1373371/ (drm:
udl: usb: Fix recursive Kconfig dependency), which should make it into the next
iteration of linux-next.

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

Kconfig DRM_USB/DRM_UDL, and select vs. depends, and causing Tegra USB to be disabled

[Stephen Warren]

With respect to the following commits:

df0b344 drm/usb: select USB_SUPPORT in Kconfig
8f057d7 gpu/mfd/usb: Fix USB randconfig problems

... which end up with the following in next-20120904:

config DRM_USB
depends on DRM
depends on USB_ARCH_HAS_HCD
select USB
select USB_SUPPORT

config DRM_UDL
depends on DRM  EXPERIMENTAL
depends on USB_ARCH_HAS_HCD
select DRM_USB

Surely this is backwards; these should be dependencies, not selects? In
other words:

config DRM_USB
depends on DRM  USB

config DRM_UDL
depends on DRM  EXPERIMENTAL  USB
select DRM_USB

or perhaps:

config DRM_USB
depends on DRM  USB

config DRM_UDL
depends on DRM  EXPERIMENTAL  DRM_USB

The problem here is that currently, the dependency logic for USB:

config USB
depends on USB_ARCH_HAS_HCD

... is duplicated into each of DRM_USB and DRM_UDL, thus requiring both
of those to be edited should the dependencies for USB ever change.

The current state of the code also causes some strange problem with
ARM's tegra_defconfig, whereby running make tegra_defconfig will
result in USB support fully enabled in .config as expected, yet
subsequently running make oldconfig will cause all USB support to be
removed from .config. For some reason, the above DRM logic is causing
CONFIG_USB_ARCH_HAS_HCD not to be selected (perhaps it isn't evaluated
because USB is selected, so there's no need to evaluate USB's
dependencies?). Arguably, this is a deficiency in Tegra's Kconfig, in
that it probably should say:

select USB_ARCH_HAS_EHCI

not:

select USB_ARCH_HAS_EHCI if USB_SUPPORT

... but it has contained the latter for quite some time, and it's always
worked before somehow.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: A few questions about the best way to implement RandR 1.4 / PRIME buffer sharing

[Aaron Plattner]

On 08/31/2012 08:00 PM, Dave Airlie wrote:

object interface, so that Optimus-based laptops can use our driver to drive
the discrete GPU and display on the integrated GPU.  The good news is that
I've got a proof of concept working.


Don't suppose you'll be interested in adding the other method at some point as
well? since saving power is probably important to a lot of people


That's milestone 2.  I'm focusing on display offload to start because it's
easier to implement and lays the groundwork for the kernel pieces.  I have to
emphasize that I'm just doing a feasibility study right now and I can't promise
that we're going to officially support this stuff.


During a review of the current code, we came up with a few concerns:

1. The output source is responsible for allocating the shared memory

Right now, the X server calls CreatePixmap on the output source screen and
then expects the output sink screen to be able to display from whatever memory
the source allocates.  Right now, the source has no mechanism for asking the
sink what its requirements are for the surface.  I'm using our own internal
pitch alignment requirements and that seems to be good enough for the Intel
device to scan out, but that could be pure luck.


Well in theory it might be nice but it would have been premature since so far
the only interactions for prime are combination of intel, nvidia and AMD, and
I think everyone has fairly similar pitch alignment requirements, I'd be
interested in adding such an interface but I don't think its some I personally
would be working on.


Okay.  Hopefully that won't be too painful to add if we ever need it in the
future.


other, or is it sufficient to just define a lowest common denominator format
and if your hardware can't deal with that format, you just don't get to share
buffers?


At the moment I'm happy to just go with linear, minimum pitch alignment 64 or


256, for us.


something as a base standard, but yeah I'm happy for it to work either way,
just don't have enough evidence it's worth it yet. I've not looked at ARM
stuff, so patches welcome if people consider they need to use this stuff for
SoC devices.


We can always hack it to whatever is necessary if we see that the sink side
driver is Tegra, but I was hoping for something more general.


2. There's no fallback mechanism if sharing can't be negotiated

If RandR fails to share a pixmap with the output sink screen, the whole
modeset fails.  This means you'll end up not seeing anything on the screen and
you'll probably think your computer locked up.  Should there be some sort of
software copy fallback to ensure that something at least shows up on the
display?


Uggh, it would be fairly slow and unuseable, I'd rather they saw nothing, but
again open to suggestions on how to make this work, since it might fail for
other reasons and in that case there is still nothing a sw copy can do. What
happens if the slave intel device just fails to allocate a pixmap, but yeah
I'm willing to think about it a bit more when we have some reference
implementations.


Just rolling back the modeset operation to whatever was working before would be
a good start.

It's worse than that on my current laptop, though, since our driver sees a
phantom CRT output and we happily start driving pixels to it that end up going
nowhere.  I'll need to think about what the right behavior is there since I
don't know if we want to rely on an X client to make that configuration work.


3. How should the memory be allocated?

In the prototype I threw together, I'm allocating the shared memory using
shm_open and then exporting that as a dma-buf file descriptor using an ioctl I
added to the kernel, and then importing that memory back into our driver
through dma_buf_attach  dma_buf_map_attachment.  Does it make sense for
user-space programs to be able to export shmfs files like that?  Should that
interface go in DRM / GEM / PRIME instead?  Something else?  I'm pretty
unfamiliar with this kernel code so any suggestions would be appreciated.


Your kernel driver should in theory be doing it all, if you allocate shared
pixmaps in GTT accessible memory, then you need an ioctl to tell your kernel
driver to export the dma buf to the fd handle.  (assuming we get rid of the
_GPL, which people have mentioned they are open to doing). We have handle-fd
and fd-handle interfaces on DRM, you'd need something similiar on the nvidia
kernel driver interface.


Okay, I can do that.  We already have a mechanism for importing buffers
allocated elsewhere so reusing that for shmfs and/or dma-buf seemed like a
natural extension.  I don't think adding a separate ioctl for exporting our own
allocations will add too much extra code.


Yes for 4 some sort of fencing is being worked on by Maarten for other stuff
but would be a pre-req for doing this, and also some devices don't want
fullscreen updates, like USB, so doing flipped updates would have to be
optional or negoitated. It makes sense for us as well 

Re: Kconfig DRM_USB/DRM_UDL, and select vs. depends, and causing Tegra USB to be disabled

[Stephen Warren]

On 09/04/2012 02:00 PM, Guenter Roeck wrote:
 On Tue, Sep 04, 2012 at 01:19:12PM -0600, Stephen Warren wrote:
 With respect to the following commits:

 df0b344 drm/usb: select USB_SUPPORT in Kconfig
 8f057d7 gpu/mfd/usb: Fix USB randconfig problems

 ... which end up with the following in next-20120904:

 config DRM_USB
 depends on DRM
 depends on USB_ARCH_HAS_HCD
 select USB
 select USB_SUPPORT

 config DRM_UDL
 depends on DRM  EXPERIMENTAL
 depends on USB_ARCH_HAS_HCD
 select DRM_USB

 Surely this is backwards; these should be dependencies, not selects? In
 other words:

 config DRM_USB
 depends on DRM  USB

 config DRM_UDL
 depends on DRM  EXPERIMENTAL  USB
 select DRM_USB

 or perhaps:

 config DRM_USB
 depends on DRM  USB

 config DRM_UDL
 depends on DRM  EXPERIMENTAL  DRM_USB

 The problem here is that currently, the dependency logic for USB:

 config USB
  depends on USB_ARCH_HAS_HCD

 ... is duplicated into each of DRM_USB and DRM_UDL, thus requiring both
 of those to be edited should the dependencies for USB ever change.

 This should be fixed with in https://patchwork.kernel.org/patch/1373371/ (drm:
 udl: usb: Fix recursive Kconfig dependency), which should make it into the 
 next
 iteration of linux-next.

Yes, this does appear to solve all the problems for me. Thanks.

I still tend to believe that drivers should probably depend on things
rather than select them, but given the common precedent for select USB
that exists here, others clearly don't agree!

Sorry; accidentally sent the email too early last time:-(
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Patch 0/1]drm_irq: Introducing the irq_thread support

[Liu, Chuansheng]

This patch is for introducing the irq thread support in drm_irq.

Why we need irq thread in drm_irq code?
In our GPU system, the gpu interrupt handler need some time even  1ms to 
finish,
in that case, the whole system will stay in irq disable status. One case is:
when audio is playing, it sometimes effects the audio quality.

So we have to introduce the irq thread in drm_irq, it can help us move some 
heavy work into irq thread
and other irq interrupts can be handled in time. Also the IRQF_ONESHOT is 
helpful for irq thread.

Include one patch:
[PATCH 01/1] drm_irq-Introducing-the-irq_thread-support
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Patch 1/1]drm_irq: Introducing the irq_thread support

[Liu, Chuansheng]

From: liu chuansheng chuansheng@intel.com
Subject: [PATCH] drm_irq: Introducing the irq_thread support

For some GPUs, the irq handler need 1ms to handle the irq action.
And it will delay the whole system irq handler.

This patch is adding the irq thread support, it will make the drm_irq
interface more flexible.

The changes include:
1/ Change the request_irq to request_thread_irq, and add new callback
   irq_handler_t;
2/ Normally we need IRQF_ONESHOT flag support for irq thread, so add
   this option in drm_irq;

Cc: Shi Yang yang.a@intel.com
Signed-off-by: liu chuansheng chuansheng@intel.com
---
 drivers/gpu/drm/drm_irq.c |8 ++--
 include/drm/drmP.h|2 ++
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 03f16f3..bc105fe 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -345,13 +345,17 @@ int drm_irq_install(struct drm_device *dev)
if (drm_core_check_feature(dev, DRIVER_IRQ_SHARED))
sh_flags = IRQF_SHARED;
 
+   if (drm_core_check_feature(dev, DRIVER_IRQ_ONESHOT))
+   sh_flags |= IRQF_ONESHOT;
+
if (dev-devname)
irqname = dev-devname;
else
irqname = dev-driver-name;
 
-   ret = request_irq(drm_dev_to_irq(dev), dev-driver-irq_handler,
- sh_flags, irqname, dev);
+   ret = request_threaded_irq(drm_dev_to_irq(dev),
+   dev-driver-irq_handler, dev-driver-irq_handler_t,
+   sh_flags, irqname, dev);
 
if (ret  0) {
mutex_lock(dev-struct_mutex);
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index d6b67bb..b28be4b 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -152,6 +152,7 @@ int drm_err(const char *func, const char *format, ...);
 #define DRIVER_GEM 0x1000
 #define DRIVER_MODESET 0x2000
 #define DRIVER_PRIME   0x4000
+#define DRIVER_IRQ_ONESHOT 0x8000
 
 #define DRIVER_BUS_PCI 0x1
 #define DRIVER_BUS_PLATFORM 0x2
@@ -872,6 +873,7 @@ struct drm_driver {
/* these have to be filled in */
 
irqreturn_t(*irq_handler) (DRM_IRQ_ARGS);
+   irqreturn_t(*irq_handler_t) (DRM_IRQ_ARGS);
void (*irq_preinstall) (struct drm_device *dev);
int (*irq_postinstall) (struct drm_device *dev);
void (*irq_uninstall) (struct drm_device *dev);
-- 
1.7.0.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm/radeon: do not reenable crtc after moving vram start address

[Brad Campbell]

On 28/07/12 04:32, j.gli...@gmail.com wrote:

From: Jerome Glisse jgli...@redhat.com

It seems we can not update the crtc scanout address. After disabling
crtc, update to base address do not take effect after crtc being
reenable leading to at least frame being scanout from the old crtc
base address. Disabling crtc display request lead to same behavior.

So after changing the vram address if we don't keep crtc disabled
we will have the GPU trying to read some random system memory address
with some iommu this will broke the crtc engine and will lead to
broken display and iommu error message.

So to avoid this, disable crtc. For flicker less boot we will need
to avoid moving the vram start address.

This patch should also fix :

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


G'day Jerome,

I'm running a Mid 2011, iMac with three heads. Card :
01:00.0 VGA compatible controller: ATI Technologies Inc Device 6720

To make this usable (ie to not cook the machine), I must force the card 
into low power mode which I do with this patch :


diff --git a/drivers/gpu/drm/radeon/radeon_pm.c 
b/drivers/gpu/drm/radeon/radeon_pm.c

index 6fabe89..de85eda 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -102,7 +102,7 @@ static void radeon_pm_update_profile(struct 
radeon_device *rdev)

break;
case PM_PROFILE_LOW:
if (rdev-pm.active_crtc_count  1)
-   rdev-pm.profile_index = PM_PROFILE_LOW_MH_IDX;
+   rdev-pm.profile_index = PM_PROFILE_LOW_SH_IDX;
else
rdev-pm.profile_index = PM_PROFILE_LOW_SH_IDX;
break;

The patch this mail refers to causes moving corruption (like noise) on 
about the right hand 1/3rd of the primary monitor.


Reverting either of these patches makes the corruption go away, however 
reverting my patch makes the machine unusable as it simply cooks.


I also have to revert : [PATCH] drm/radeon: fix bo creation retry path 
or the machine simply panics at X login, however I see that has already 
been queued for reversion.


Any advice you could offer to assist me in sorting this would be much 
appreciated.


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

[Bug 54527] Crash, kernel BUG ttm/ttm_bo.c:1659!, when running gnibbles

[bugzilla-daemon]

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

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

   What|Removed |Added

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

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 54527] Crash, kernel BUG ttm/ttm_bo.c:1659!, when running gnibbles

[bugzilla-daemon]

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

--- Comment #1 from Michel Dänzer mic...@daenzer.net 2012-09-05 08:24:39 UTC 
---
Likely fixed by
https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=676bc2e1e4f9072f7a640d5b7c99ffdf9709a6e7
, which should be on its way to the 3.5 stable tree as well.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/prime: drop reference on imported dma-buf

[Daniel Vetter]

On Tue, Sep 04, 2012 at 05:32:21PM -0500, Rob Clark wrote:
 Dave, I just noticed that I still have this patch locally, but don't
 see it in drm-next..  so just checking that it didn't get forgotten

My locking fixes blew up :(
-Daniel

 
 BR,
 -R
 
 On Tue, Jul 24, 2012 at 3:05 AM, Daniel Vetter dan...@ffwll.ch wrote:
  On Tue, Jul 24, 2012 at 1:07 AM, Rob Clark rob.cl...@linaro.org wrote:
  From: Rob Clark r...@ti.com
 
  The GEM handle takes the reference.  If a driver is actually importing a
  foreign dmabuf, rather than just re-importing it's own dmabuf, it needs
  to do a get_dma_buf().
 
  Signed-off-by: Rob Clark r...@ti.com
  [Maybe mention that this is on top of my locking fixes.]
 
  We've discussed this a bit on irc and concluded that every function taking
  care of their own references to the dma buf works best in avoiding
  potential use-after-free issues when evil userspaces sneaks in a
  close(dma_buf_fd).
 
  Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
  ---
   drivers/gpu/drm/drm_prime.c|7 +++
   drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |4 
   drivers/gpu/drm/i915/i915_gem_dmabuf.c |4 
   drivers/gpu/drm/nouveau/nouveau_prime.c|5 +
   drivers/gpu/drm/radeon/radeon_prime.c  |4 
   drivers/gpu/drm/udl/udl_gem.c  |4 
   6 files changed, 28 insertions(+)
 
  diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
  index 4f80374..088e018 100644
  --- a/drivers/gpu/drm/drm_prime.c
  +++ b/drivers/gpu/drm/drm_prime.c
  @@ -185,6 +185,13 @@ int drm_gem_prime_fd_to_handle(struct drm_device *dev,
  mutex_unlock(file_priv-prime.lock);
  drm_gem_object_unreference_unlocked(obj);
 
  +   /*
  +* Drop the ref we obtained w/ dma_buf_get() for the benefit of
  +* drivers simply re-importing their own dma-buf.. if drivers
  +* import a foreign dma-buf, they should get_dma_buf().
  +*/
  +   dma_buf_put(dma_buf);
  +
  return 0;
 
   fail:
  diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c 
  b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
  index f270790..f8ac75b 100644
  --- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
  +++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
  @@ -190,6 +190,9 @@ struct drm_gem_object 
  *exynos_dmabuf_prime_import(struct drm_device *drm_dev,
  }
  }
 
  +   /* since we are attaching, we need to hold a ref */
  +   get_dma_buf(dma_buf);
  +
  attach = dma_buf_attach(dma_buf, drm_dev-dev);
  if (IS_ERR(attach))
  return ERR_PTR(-EINVAL);
  @@ -250,6 +253,7 @@ err_unmap_attach:
  dma_buf_unmap_attachment(attach, sgt, DMA_BIDIRECTIONAL);
   err_buf_detach:
  dma_buf_detach(dma_buf, attach);
  +   dma_buf_put(dma_buf);
  return ERR_PTR(ret);
   }
 
  diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c 
  b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
  index cf6bdec..9d2b2eb 100644
  --- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
  +++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
  @@ -189,6 +189,9 @@ struct drm_gem_object *i915_gem_prime_import(struct 
  drm_device *dev,
  }
  }
 
  +   /* since we are attaching, we need to hold a ref */
  +   get_dma_buf(dma_buf);
  +
  /* need to attach */
  attach = dma_buf_attach(dma_buf, dev-dev);
  if (IS_ERR(attach))
  @@ -224,5 +227,6 @@ fail_unmap:
  dma_buf_unmap_attachment(attach, sg, DMA_BIDIRECTIONAL);
   fail_detach:
  dma_buf_detach(dma_buf, attach);
  +   dma_buf_put(dma_buf);
  return ERR_PTR(ret);
   }
  diff --git a/drivers/gpu/drm/nouveau/nouveau_prime.c 
  b/drivers/gpu/drm/nouveau/nouveau_prime.c
  index 4c82801..fc30886 100644
  --- a/drivers/gpu/drm/nouveau/nouveau_prime.c
  +++ b/drivers/gpu/drm/nouveau/nouveau_prime.c
  @@ -200,6 +200,10 @@ struct drm_gem_object 
  *nouveau_gem_prime_import(struct drm_device *dev,
  }
  }
  }
  +
  +   /* since we are attaching, we need to hold a ref */
  +   get_dma_buf(dma_buf);
  +
  /* need to attach */
  attach = dma_buf_attach(dma_buf, dev-dev);
  if (IS_ERR(attach))
  @@ -223,6 +227,7 @@ fail_unmap:
  dma_buf_unmap_attachment(attach, sg, DMA_BIDIRECTIONAL);
   fail_detach:
  dma_buf_detach(dma_buf, attach);
  +   dma_buf_put(dma_buf);
  return ERR_PTR(ret);
   }
 
  diff --git a/drivers/gpu/drm/radeon/radeon_prime.c 
  b/drivers/gpu/drm/radeon/radeon_prime.c
  index 28f79ac..073a8d3 100644
  --- a/drivers/gpu/drm/radeon/radeon_prime.c
  +++ b/drivers/gpu/drm/radeon/radeon_prime.c
  @@ -195,6 +195,9 @@ struct drm_gem_object *radeon_gem_prime_import(struct 
  drm_device *dev,
  }
  }
 
  +   /* since we are attaching, we need to hold a ref */
  +   get_dma_buf(dma_buf);
  +
  /* need to attach */

Re: [PATCH] drm: refcnt drm_framebuffer

[Daniel Vetter]

On Tue, Sep 04, 2012 at 06:10:04PM -0500, Rob Clark wrote:
 From: Rob Clark r...@ti.com
 
 This simplifies drm fb lifetime, and if the crtc/plane needs to hold
 a ref to the fb when disabling a pipe until the next vblank, this
 avoids the need to make disabling an overlay synchronous.  This is a
 problem that shows up when userspace is using a drm plane to
 implement a hw cursor.. making overlay disable synchronous causes
 a performance problem when x11 is rapidly enabling/disabling the
 hw cursor.  But not making it synchronous opens up a race condition
 for crashing if userspace turns around and immediately deletes the
 fb.  Refcnt'ing the fb makes it possible to solve this problem.
 
 v1: original
 v2: add drm_framebuffer_remove() which is called in all paths where
 fb-funcs-destroy() was directly called before.  This cleans
 up the CRTCs/planes that the fb was attached to.  You should
 only directly use drm_framebuffer_unreference() if you are also
 using drm_framebuffer_reference() to keep a ref to the fb.
 
 Signed-off-by: Rob Clark r...@ti.com

Yeah, this could also be rather useful to move a few things to saner
places in drm/i915. The fb-refcount is a bit strange though since only
driver-internals can be reference counted, all the userspace interface
stuff in the drm core has to abide to the old api which mandates that we
remove all uses of a given fb at rmfb time. I guess we'll just have to
live with that.

Still, can you add a small comment in drm_crtc.h to the new refcount
explaining this? And maybe extend the note about the -destroy callback to
say call _remove or _unrefence instead? Otherwise

Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch

 ---
  drivers/gpu/drm/drm_crtc.c|   78 
 +
  drivers/gpu/drm/exynos/exynos_drm_fbdev.c |4 +-
  drivers/gpu/drm/i915/intel_display.c  |4 +-
  drivers/staging/omapdrm/omap_fbdev.c  |4 +-
  include/drm/drm_crtc.h|5 ++
  5 files changed, 78 insertions(+), 17 deletions(-)
 
 diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
 index 901de9a..96e236f 100644
 --- a/drivers/gpu/drm/drm_crtc.c
 +++ b/drivers/gpu/drm/drm_crtc.c
 @@ -294,6 +294,8 @@ int drm_framebuffer_init(struct drm_device *dev, struct 
 drm_framebuffer *fb,
  {
   int ret;
  
 + kref_init(fb-refcount);
 +
   ret = drm_mode_object_get(dev, fb-base, DRM_MODE_OBJECT_FB);
   if (ret)
   return ret;
 @@ -307,6 +309,38 @@ int drm_framebuffer_init(struct drm_device *dev, struct 
 drm_framebuffer *fb,
  }
  EXPORT_SYMBOL(drm_framebuffer_init);
  
 +static void drm_framebuffer_free(struct kref *kref)
 +{
 + struct drm_framebuffer *fb =
 + container_of(kref, struct drm_framebuffer, refcount);
 + fb-funcs-destroy(fb);
 +}
 +
 +/**
 + * drm_framebuffer_unreference - unref a framebuffer
 + *
 + * LOCKING:
 + * Caller must hold mode config lock.
 + */
 +void drm_framebuffer_unreference(struct drm_framebuffer *fb)
 +{
 + struct drm_device *dev = fb-dev;
 + DRM_DEBUG(FB ID: %d\n, fb-base.id);
 + WARN_ON(!mutex_is_locked(dev-mode_config.mutex));
 + kref_put(fb-refcount, drm_framebuffer_free);
 +}
 +EXPORT_SYMBOL(drm_framebuffer_unreference);
 +
 +/**
 + * drm_framebuffer_reference - incr the fb refcnt
 + */
 +void drm_framebuffer_reference(struct drm_framebuffer *fb)
 +{
 + DRM_DEBUG(FB ID: %d\n, fb-base.id);
 + kref_get(fb-refcount);
 +}
 +EXPORT_SYMBOL(drm_framebuffer_reference);
 +
  /**
   * drm_framebuffer_cleanup - remove a framebuffer object
   * @fb: framebuffer to remove
 @@ -320,6 +354,32 @@ EXPORT_SYMBOL(drm_framebuffer_init);
  void drm_framebuffer_cleanup(struct drm_framebuffer *fb)
  {
   struct drm_device *dev = fb-dev;
 + /*
 +  * This could be moved to drm_framebuffer_remove(), but for
 +  * debugging is nice to keep around the list of fb's that are
 +  * no longer associated w/ a drm_file but are not unreferenced
 +  * yet.  (i915 and omapdrm have debugfs files which will show
 +  * this.)
 +  */
 + drm_mode_object_put(dev, fb-base);
 + list_del(fb-head);
 + dev-mode_config.num_fb--;
 +}
 +EXPORT_SYMBOL(drm_framebuffer_cleanup);
 +
 +/**
 + * drm_framebuffer_remove - remove and unreference a framebuffer object
 + * @fb: framebuffer to remove
 + *
 + * LOCKING:
 + * Caller must hold mode config lock.
 + *
 + * Scans all the CRTCs and planes in @dev's mode_config.  If they're
 + * using @fb, removes it, setting it to NULL.
 + */
 +void drm_framebuffer_remove(struct drm_framebuffer *fb)
 +{
 + struct drm_device *dev = fb-dev;
   struct drm_crtc *crtc;
   struct drm_plane *plane;
   struct drm_mode_set set;
 @@ -350,11 +410,11 @@ void drm_framebuffer_cleanup(struct drm_framebuffer *fb)
   }
   }
  
 - drm_mode_object_put(dev, fb-base);
 - list_del(fb-head);
 - dev-mode_config.num_fb--;
 + 

[PATCH] drm/exynos: add dummy support for dmabuf-mmap

[Inki Dae]

From: Tomasz Stanislawski t.stanisl...@samsung.com

This patch adds a stub function for DMABUF mmap.
This allows to export a DMABUF.

Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Inki Dae inki@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c 
b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
index 613bf8a..ae13feb 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
@@ -163,6 +163,12 @@ static void exynos_gem_dmabuf_kunmap(struct dma_buf 
*dma_buf,
/* TODO */
 }
 
+static int exynos_gem_dmabuf_mmap(struct dma_buf *dma_buf,
+   struct vm_area_struct *vma)
+{
+   return -ENOTTY;
+}
+
 static struct dma_buf_ops exynos_dmabuf_ops = {
.map_dma_buf= exynos_gem_map_dma_buf,
.unmap_dma_buf  = exynos_gem_unmap_dma_buf,
@@ -170,6 +176,7 @@ static struct dma_buf_ops exynos_dmabuf_ops = {
.kmap_atomic= exynos_gem_dmabuf_kmap_atomic,
.kunmap = exynos_gem_dmabuf_kunmap,
.kunmap_atomic  = exynos_gem_dmabuf_kunmap_atomic,
+   .mmap   = exynos_gem_dmabuf_mmap,
.release= exynos_dmabuf_release,
 };
 
-- 
1.7.4.1

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

[PATCH libdrm] libkms: fix the name of the intel driver in linux_sysfs_create

[Ander Conselvan de Oliveira]

From: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com

linux_sysfs_create() checked for a driver named intel while the intel
driver is called i915. This went unnoticed because in kernels 2.6.39
and after this code path was never reached because of the dumb buffer
interface. On earlier kernels, kms_create() would fail.

Signed-off-by: Ander Conselvan de Oliveira 
ander.conselvan.de.olive...@intel.com
---
 libkms/linux.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/libkms/linux.c b/libkms/linux.c
index fc4f205..dde74f7 100644
--- a/libkms/linux.c
+++ b/libkms/linux.c
@@ -101,7 +101,7 @@ linux_from_sysfs(int fd, struct kms_driver **out)
if (ret)
return ret;
 
-   if (!strcmp(name, intel))
+   if (!strcmp(name, i915))
ret = intel_create(fd, out);
 #ifdef HAVE_VMWGFX
else if (!strcmp(name, vmwgfx))
-- 
1.7.4.1

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

Re: [PATCH] drm/prime: drop reference on imported dma-buf

[Rob Clark]

On Wed, Sep 5, 2012 at 4:02 AM, Daniel Vetter dan...@ffwll.ch wrote:
 On Tue, Sep 04, 2012 at 05:32:21PM -0500, Rob Clark wrote:
 Dave, I just noticed that I still have this patch locally, but don't
 see it in drm-next..  so just checking that it didn't get forgotten

 My locking fixes blew up :(

oh, ok.. I guess there was a thread that I missed..

BR,
-R

 -Daniel


 BR,
 -R

 On Tue, Jul 24, 2012 at 3:05 AM, Daniel Vetter dan...@ffwll.ch wrote:
  On Tue, Jul 24, 2012 at 1:07 AM, Rob Clark rob.cl...@linaro.org wrote:
  From: Rob Clark r...@ti.com
 
  The GEM handle takes the reference.  If a driver is actually importing a
  foreign dmabuf, rather than just re-importing it's own dmabuf, it needs
  to do a get_dma_buf().
 
  Signed-off-by: Rob Clark r...@ti.com
  [Maybe mention that this is on top of my locking fixes.]
 
  We've discussed this a bit on irc and concluded that every function taking
  care of their own references to the dma buf works best in avoiding
  potential use-after-free issues when evil userspaces sneaks in a
  close(dma_buf_fd).
 
  Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
  ---
   drivers/gpu/drm/drm_prime.c|7 +++
   drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |4 
   drivers/gpu/drm/i915/i915_gem_dmabuf.c |4 
   drivers/gpu/drm/nouveau/nouveau_prime.c|5 +
   drivers/gpu/drm/radeon/radeon_prime.c  |4 
   drivers/gpu/drm/udl/udl_gem.c  |4 
   6 files changed, 28 insertions(+)
 
  diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
  index 4f80374..088e018 100644
  --- a/drivers/gpu/drm/drm_prime.c
  +++ b/drivers/gpu/drm/drm_prime.c
  @@ -185,6 +185,13 @@ int drm_gem_prime_fd_to_handle(struct drm_device 
  *dev,
  mutex_unlock(file_priv-prime.lock);
  drm_gem_object_unreference_unlocked(obj);
 
  +   /*
  +* Drop the ref we obtained w/ dma_buf_get() for the benefit of
  +* drivers simply re-importing their own dma-buf.. if drivers
  +* import a foreign dma-buf, they should get_dma_buf().
  +*/
  +   dma_buf_put(dma_buf);
  +
  return 0;
 
   fail:
  diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c 
  b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
  index f270790..f8ac75b 100644
  --- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
  +++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
  @@ -190,6 +190,9 @@ struct drm_gem_object 
  *exynos_dmabuf_prime_import(struct drm_device *drm_dev,
  }
  }
 
  +   /* since we are attaching, we need to hold a ref */
  +   get_dma_buf(dma_buf);
  +
  attach = dma_buf_attach(dma_buf, drm_dev-dev);
  if (IS_ERR(attach))
  return ERR_PTR(-EINVAL);
  @@ -250,6 +253,7 @@ err_unmap_attach:
  dma_buf_unmap_attachment(attach, sgt, DMA_BIDIRECTIONAL);
   err_buf_detach:
  dma_buf_detach(dma_buf, attach);
  +   dma_buf_put(dma_buf);
  return ERR_PTR(ret);
   }
 
  diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c 
  b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
  index cf6bdec..9d2b2eb 100644
  --- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
  +++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
  @@ -189,6 +189,9 @@ struct drm_gem_object *i915_gem_prime_import(struct 
  drm_device *dev,
  }
  }
 
  +   /* since we are attaching, we need to hold a ref */
  +   get_dma_buf(dma_buf);
  +
  /* need to attach */
  attach = dma_buf_attach(dma_buf, dev-dev);
  if (IS_ERR(attach))
  @@ -224,5 +227,6 @@ fail_unmap:
  dma_buf_unmap_attachment(attach, sg, DMA_BIDIRECTIONAL);
   fail_detach:
  dma_buf_detach(dma_buf, attach);
  +   dma_buf_put(dma_buf);
  return ERR_PTR(ret);
   }
  diff --git a/drivers/gpu/drm/nouveau/nouveau_prime.c 
  b/drivers/gpu/drm/nouveau/nouveau_prime.c
  index 4c82801..fc30886 100644
  --- a/drivers/gpu/drm/nouveau/nouveau_prime.c
  +++ b/drivers/gpu/drm/nouveau/nouveau_prime.c
  @@ -200,6 +200,10 @@ struct drm_gem_object 
  *nouveau_gem_prime_import(struct drm_device *dev,
  }
  }
  }
  +
  +   /* since we are attaching, we need to hold a ref */
  +   get_dma_buf(dma_buf);
  +
  /* need to attach */
  attach = dma_buf_attach(dma_buf, dev-dev);
  if (IS_ERR(attach))
  @@ -223,6 +227,7 @@ fail_unmap:
  dma_buf_unmap_attachment(attach, sg, DMA_BIDIRECTIONAL);
   fail_detach:
  dma_buf_detach(dma_buf, attach);
  +   dma_buf_put(dma_buf);
  return ERR_PTR(ret);
   }
 
  diff --git a/drivers/gpu/drm/radeon/radeon_prime.c 
  b/drivers/gpu/drm/radeon/radeon_prime.c
  index 28f79ac..073a8d3 100644
  --- a/drivers/gpu/drm/radeon/radeon_prime.c
  +++ b/drivers/gpu/drm/radeon/radeon_prime.c
  @@ -195,6 +195,9 @@ struct drm_gem_object *radeon_gem_prime_import(struct 
  drm_device *dev,
  }
  }

Re: [PATCH V4 2/2] video: drm: exynos: Add device tree support

[Kyungmin Park]

Hi,

On Thu, Sep 6, 2012 at 12:39 AM, Leela Krishna Amudala
l.kris...@samsung.com wrote:
 Add device tree based discovery support for DRM-FIMD driver.

 Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
 ---
  Documentation/devicetree/bindings/fb/drm-fimd.txt |   80 +
  drivers/gpu/drm/exynos/exynos_drm_fimd.c  |   95 
 -
  2 files changed, 173 insertions(+), 2 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/fb/drm-fimd.txt

 diff --git a/Documentation/devicetree/bindings/fb/drm-fimd.txt 
 b/Documentation/devicetree/bindings/fb/drm-fimd.txt
 new file mode 100644
 index 000..4ff1829
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/fb/drm-fimd.txt
 @@ -0,0 +1,80 @@
 +* Samsung Display Controller using DRM frame work
 +
 +The display controller is used to transfer image data from memory to an
 +external LCD driver interface. It supports various color formats such as
 +rgb and yuv.
 +
 +Required properties:
 + - compatible: Should be samsung,exynos5-fimd or samsung,exynos4-fb for
Doesn't better to use single word? fimd or fb?. I think 'fb' is used
for framebuffer historically.
but now it's used both fb and drm, so fimd is neutral and architecture
specific.

To do this, Modify arch-exynos first and update it at each drivers it properly.

Thank you,
Kyungmin Park

 +   fimd using DRM frame work.
 + - reg: physical base address of the controller and length of memory
 +   mapped region.
 + - interrupts: Three interrupts should be specified. The interrupts should be
 +   specified in the following order.
 +   - VSYNC interrupt
 +   - FIFO level interrupt
 +   - FIMD System Interrupt
 +
 + - samsung,fimd-display: This property should specify the phandle of the
 +   display device node which holds the video interface timing with the
 +   below mentioned properties.
 +
 +   - lcd-htiming: Specifies the horizontal timing for the overlay. The
 + horizontal timing includes four parameters in the following order.
 +
 + - horizontal back porch (in number of lcd clocks)
 + - horizontal front porch (in number of lcd clocks)
 + - hsync pulse width (in number of lcd clocks)
 + - Display panels X resolution.
 +
 +   - lcd-vtiming: Specifies the vertical timing for the overlay. The
 + vertical timing includes four parameters in the following order.
 +
 + - vertical back porch (in number of lcd lines)
 + - vertical front porch (in number of lcd lines)
 + - vsync pulse width (in number of lcd clocks)
 + - Display panels Y resolution.
 +
 +
 + - samsung,default-window: Specifies the default window number of the fimd 
 controller.
 +
 + - samsung,fimd-win-bpp: Specifies the bits per pixel.
 +
 +Optional properties:
 + - samsung,fimd-vidout-rgb: Video output format is RGB.
 + - samsung,fimd-inv-vclk: invert video clock polarity.
 + - samsung,fimd-frame-rate: Number of video frames per second.
 +
 +Example:
 +
 +   The following is an example for the fimd controller is split into
 +   two portions. The SoC specific portion can be specified in the SoC
 +   specific dts file. The board specific portion can be specified in the
 +   board specific dts file.
 +
 +   - SoC Specific portion
 +
 +   fimd {
 +   compatible = samsung,exynos5-fimd;
 +   interrupt-parent = combiner;
 +   reg = 0x1440 0x4;
 +   interrupts = 18 5, 18 4, 18 6;
 +   };
 +
 +   - Board Specific portion
 +
 +   lcd_fimd0: lcd_panel0 {
 +   lcd-htiming = 4 4 4 480;
 +   lcd-vtiming = 4 4 4 320;
 +   supports-mipi-panel;
 +   };
 +
 +   fimd {
 +   samsung,fimd-display = lcd_fimd0;
 +   samsung,fimd-vidout-rgb;
 +   samsung,fimd-inv-vclk;
 +   samsung,fimd-frame-rate = 60;
 +   samsung,default-window = 0;
 +   samsung,fimd-win-bpp = 32;
 +   };
 +
 diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
 b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
 index 3701fbe..a4fa8e9 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
 @@ -18,6 +18,7 @@
  #include linux/platform_device.h
  #include linux/clk.h
  #include linux/pm_runtime.h
 +#include linux/of.h

  #include video/samsung_fimd.h
  #include drm/exynos_drm.h
 @@ -103,9 +104,18 @@ struct fimd_context {
 struct exynos_drm_panel_info *panel;
  };

 +static const struct of_device_id fimd_dt_match[];
 +
  static inline struct fimd_driver_data *drm_fimd_get_driver_data(
 struct platform_device *pdev)
  {
 +#ifdef CONFIG_OF
 +   if (pdev-dev.of_node) {
 +   const struct of_device_id *match;
 +   match = of_match_ptr(fimd_dt_match);
 +   return (struct fimd_driver_data *)match-data;
 +   }
 +#endif
 return (struct fimd_driver_data *)
 

Re: [Patch 0/1]drm_irq: Introducing the irq_thread support

[Alan Cox]

On Wed, 5 Sep 2012 01:53:44 +
Liu, Chuansheng chuansheng@intel.com wrote:

 This patch is for introducing the irq thread support in drm_irq.
 
 Why we need irq thread in drm_irq code?
 In our GPU system, the gpu interrupt handler need some time even  1ms to 
 finish,
 in that case, the whole system will stay in irq disable status. One case is:
 when audio is playing, it sometimes effects the audio quality.

This possibly ought to be submitted in parallel with the code that uses it
so that the whole proposal can be evaluated as one thing ?

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

Re: [Patch 0/1]drm_irq: Introducing the irq_thread support

[Daniel Vetter]

On Wed, Sep 05, 2012 at 01:53:44AM +, Liu, Chuansheng wrote:
 This patch is for introducing the irq thread support in drm_irq.
 
 Why we need irq thread in drm_irq code?
 In our GPU system, the gpu interrupt handler need some time even  1ms to 
 finish,
 in that case, the whole system will stay in irq disable status. One case is:
 when audio is playing, it sometimes effects the audio quality.
 
 So we have to introduce the irq thread in drm_irq, it can help us move some 
 heavy work into irq thread
 and other irq interrupts can be handled in time. Also the IRQF_ONESHOT is 
 helpful for irq thread.
 
 Include one patch:
 [PATCH 01/1] drm_irq-Introducing-the-irq_thread-support

For a kms drm driver (and tbh, doing a non-kms driver today is not a great
idea), there's no reason to use the drm_irq_install/_unistall helpers.

So if you driver has special needs wrt irq handling that don't neatly fit
what the drm_irq stuff provides, simply don't use it - all the generic
code that's there is just to keep non-kms userspace going.

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

Re: [PATCH 1/3] drm/radeon: do not reenable crtc after moving vram start address

[Jerome Glisse]

On Wed, Sep 5, 2012 at 12:39 AM, Brad Campbell b...@fnarfbargle.com wrote:
 On 28/07/12 04:32, j.gli...@gmail.com wrote:

 From: Jerome Glisse jgli...@redhat.com

 It seems we can not update the crtc scanout address. After disabling
 crtc, update to base address do not take effect after crtc being
 reenable leading to at least frame being scanout from the old crtc
 base address. Disabling crtc display request lead to same behavior.

 So after changing the vram address if we don't keep crtc disabled
 we will have the GPU trying to read some random system memory address
 with some iommu this will broke the crtc engine and will lead to
 broken display and iommu error message.

 So to avoid this, disable crtc. For flicker less boot we will need
 to avoid moving the vram start address.

 This patch should also fix :

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


 G'day Jerome,

 I'm running a Mid 2011, iMac with three heads. Card :
 01:00.0 VGA compatible controller: ATI Technologies Inc Device 6720

 To make this usable (ie to not cook the machine), I must force the card into
 low power mode which I do with this patch :

 diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
 b/drivers/gpu/drm/radeon/radeon_pm.c
 index 6fabe89..de85eda 100644
 --- a/drivers/gpu/drm/radeon/radeon_pm.c
 +++ b/drivers/gpu/drm/radeon/radeon_pm.c
 @@ -102,7 +102,7 @@ static void radeon_pm_update_profile(struct
 radeon_device *rdev)
 break;
 case PM_PROFILE_LOW:
 if (rdev-pm.active_crtc_count  1)
 -   rdev-pm.profile_index = PM_PROFILE_LOW_MH_IDX;
 +   rdev-pm.profile_index = PM_PROFILE_LOW_SH_IDX;
 else
 rdev-pm.profile_index = PM_PROFILE_LOW_SH_IDX;
 break;

 The patch this mail refers to causes moving corruption (like noise) on about
 the right hand 1/3rd of the primary monitor.

 Reverting either of these patches makes the corruption go away, however
 reverting my patch makes the machine unusable as it simply cooks.

 I also have to revert : [PATCH] drm/radeon: fix bo creation retry path or
 the machine simply panics at X login, however I see that has already been
 queued for reversion.

 Any advice you could offer to assist me in sorting this would be much
 appreciated.

 Regards,
 Brad.

Low profile is not suited to drive 2 monitors and hence is not supported.

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

Re: [Patch 0/1]drm_irq: Introducing the irq_thread support

[Daniel Vetter]

On Wed, Sep 05, 2012 at 03:12:39PM +, Shi, Yang A wrote:
 Hi Vetter:
 
 Do you mean we can just not use drm_irq_install, and make
 request_irq in our kernel driver pre-install or post-install
 interface?

Well, you cant use the pre_install/post_install hooks the drm_irq code
provides, but yes, just do the request_irq in your driver code at the
right time, with the right parameters. Much easier than adding code to a
part of the drm core fraught with backwards-compat stuff no one really
wants to touch ... All the additional stuff besides calling request_irq
and the driver hooks that drm_irq_install does is really just to support
old dri1 userspace.

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

[Bug 54527] Crash, kernel BUG ttm/ttm_bo.c:1659!, when running gnibbles

[bugzilla-daemon]

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

--- Comment #2 from Bryan Quigley bryanquig...@ubuntu.com 2012-09-05 15:43:07 
UTC ---
Just tested with 3.6-rc4.  It is indeed fixed (gnibbles still crashes but just
the program ~ I think that's it's fault)

Should I mark as fixed or wait until 3.6 releases?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Patch 0/1]drm_irq: Introducing the irq_thread support

[Rob Clark]

On Wed, Sep 5, 2012 at 8:27 AM, Daniel Vetter dan...@ffwll.ch wrote:
 On Wed, Sep 05, 2012 at 01:53:44AM +, Liu, Chuansheng wrote:
 This patch is for introducing the irq thread support in drm_irq.

 Why we need irq thread in drm_irq code?
 In our GPU system, the gpu interrupt handler need some time even  1ms to 
 finish,
 in that case, the whole system will stay in irq disable status. One case is:
 when audio is playing, it sometimes effects the audio quality.

 So we have to introduce the irq thread in drm_irq, it can help us move some 
 heavy work into irq thread
 and other irq interrupts can be handled in time. Also the IRQF_ONESHOT is 
 helpful for irq thread.

 Include one patch:
 [PATCH 01/1] drm_irq-Introducing-the-irq_thread-support

 For a kms drm driver (and tbh, doing a non-kms driver today is not a great
 idea), there's no reason to use the drm_irq_install/_unistall helpers.

 So if you driver has special needs wrt irq handling that don't neatly fit
 what the drm_irq stuff provides, simply don't use it - all the generic
 code that's there is just to keep non-kms userspace going.

perhaps an easy thing would just be to allow the driver to provide
it's own request_irq?  That might be an easier way for devices that
need to register multiple irq's, etc?

Or is it better to just bypass and dev-irq_enabled=1?  That seemed a
bit like a hack to me, but the current irq code is more framework-ish,
and less helper-ish..

BR,
-R

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

[Bug 52997] evergreen_cs_track_validate_cb:477 cb[0] bo too small when launching ds2 in wine

[bugzilla-daemon]

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

--- Comment #5 from mailbox@gmail.com 2012-09-05 17:22:26 UTC ---
Created attachment 66688
  -- https://bugs.freedesktop.org/attachment.cgi?id=66688
Messages from dmesg after running BGMain.exe in fullscreen.

Hello

I am experiencing the same issue with Wine 1.5.12 and Baldur's Gate.

The issue appears when BGMain.exe is launched fullscreen, without virtual
desktop. In virtual desktop mode, it seems to be running fine. Also, if window
switching is attempted (Ctrl+Tab) with game in fullscreen, tiny video output
appears, occupying roughly 1/4th of screen resolution (which in full is
1280x1024) in top-left corner, the rest remaining black. It's very pixelated
and shows game's main menu. With futher switching, it shows different desktop
windows (if open), but latency is very low. Regardless of video output, sound
is still played through alsa.

In my case, output from running the executable is:

radeon: The kernel rejected CS, see dmesg for more information.
fixme:win:EnumDisplayDevicesW ((null),0,0x329c48,0x), stub!
fixme:d3d_surface:wined3d_surface_flip Ignoring flags 0x1.

uname:
Linux 3.5.3-2-ck x86_64

glxinfo:
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD BARTS
OpenGL version string: 2.1 Mesa 8.0.4
OpenGL shading language version string: 1.20

libdrm_radeon version is 1.0.1

Possible duplicate: https://bugs.freedesktop.org/show_bug.cgi?id=47244

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 52997] evergreen_cs_track_validate_cb:477 cb[0] bo too small when launching ds2 in wine

[bugzilla-daemon]

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

--- Comment #6 from mailbox@gmail.com 2012-09-05 17:30:02 UTC ---
Created attachment 66689
  -- https://bugs.freedesktop.org/attachment.cgi?id=66689
X.org server varlog

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: refcnt drm_framebuffer

[Rob Clark]

From: Rob Clark r...@ti.com

This simplifies drm fb lifetime, and if the crtc/plane needs to hold
a ref to the fb when disabling a pipe until the next vblank, this
avoids the need to make disabling an overlay synchronous.  This is a
problem that shows up when userspace is using a drm plane to
implement a hw cursor.. making overlay disable synchronous causes
a performance problem when x11 is rapidly enabling/disabling the
hw cursor.  But not making it synchronous opens up a race condition
for crashing if userspace turns around and immediately deletes the
fb.  Refcnt'ing the fb makes it possible to solve this problem.

v1: original
v2: add drm_framebuffer_remove() which is called in all paths where
fb-funcs-destroy() was directly called before.  This cleans
up the CRTCs/planes that the fb was attached to.  You should
only directly use drm_framebuffer_unreference() if you are also
using drm_framebuffer_reference() to keep a ref to the fb.
v3: add comment explaining the fb refcount

Signed-off-by: Rob Clark r...@ti.com
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch

---
 drivers/gpu/drm/drm_crtc.c|   78 +
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |4 +-
 drivers/gpu/drm/i915/intel_display.c  |4 +-
 drivers/staging/omapdrm/omap_fbdev.c  |4 +-
 include/drm/drm_crtc.h|   14 ++
 5 files changed, 87 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 901de9a..96e236f 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -294,6 +294,8 @@ int drm_framebuffer_init(struct drm_device *dev, struct 
drm_framebuffer *fb,
 {
int ret;
 
+   kref_init(fb-refcount);
+
ret = drm_mode_object_get(dev, fb-base, DRM_MODE_OBJECT_FB);
if (ret)
return ret;
@@ -307,6 +309,38 @@ int drm_framebuffer_init(struct drm_device *dev, struct 
drm_framebuffer *fb,
 }
 EXPORT_SYMBOL(drm_framebuffer_init);
 
+static void drm_framebuffer_free(struct kref *kref)
+{
+   struct drm_framebuffer *fb =
+   container_of(kref, struct drm_framebuffer, refcount);
+   fb-funcs-destroy(fb);
+}
+
+/**
+ * drm_framebuffer_unreference - unref a framebuffer
+ *
+ * LOCKING:
+ * Caller must hold mode config lock.
+ */
+void drm_framebuffer_unreference(struct drm_framebuffer *fb)
+{
+   struct drm_device *dev = fb-dev;
+   DRM_DEBUG(FB ID: %d\n, fb-base.id);
+   WARN_ON(!mutex_is_locked(dev-mode_config.mutex));
+   kref_put(fb-refcount, drm_framebuffer_free);
+}
+EXPORT_SYMBOL(drm_framebuffer_unreference);
+
+/**
+ * drm_framebuffer_reference - incr the fb refcnt
+ */
+void drm_framebuffer_reference(struct drm_framebuffer *fb)
+{
+   DRM_DEBUG(FB ID: %d\n, fb-base.id);
+   kref_get(fb-refcount);
+}
+EXPORT_SYMBOL(drm_framebuffer_reference);
+
 /**
  * drm_framebuffer_cleanup - remove a framebuffer object
  * @fb: framebuffer to remove
@@ -320,6 +354,32 @@ EXPORT_SYMBOL(drm_framebuffer_init);
 void drm_framebuffer_cleanup(struct drm_framebuffer *fb)
 {
struct drm_device *dev = fb-dev;
+   /*
+* This could be moved to drm_framebuffer_remove(), but for
+* debugging is nice to keep around the list of fb's that are
+* no longer associated w/ a drm_file but are not unreferenced
+* yet.  (i915 and omapdrm have debugfs files which will show
+* this.)
+*/
+   drm_mode_object_put(dev, fb-base);
+   list_del(fb-head);
+   dev-mode_config.num_fb--;
+}
+EXPORT_SYMBOL(drm_framebuffer_cleanup);
+
+/**
+ * drm_framebuffer_remove - remove and unreference a framebuffer object
+ * @fb: framebuffer to remove
+ *
+ * LOCKING:
+ * Caller must hold mode config lock.
+ *
+ * Scans all the CRTCs and planes in @dev's mode_config.  If they're
+ * using @fb, removes it, setting it to NULL.
+ */
+void drm_framebuffer_remove(struct drm_framebuffer *fb)
+{
+   struct drm_device *dev = fb-dev;
struct drm_crtc *crtc;
struct drm_plane *plane;
struct drm_mode_set set;
@@ -350,11 +410,11 @@ void drm_framebuffer_cleanup(struct drm_framebuffer *fb)
}
}
 
-   drm_mode_object_put(dev, fb-base);
-   list_del(fb-head);
-   dev-mode_config.num_fb--;
+   list_del(fb-filp_head);
+
+   drm_framebuffer_unreference(fb);
 }
-EXPORT_SYMBOL(drm_framebuffer_cleanup);
+EXPORT_SYMBOL(drm_framebuffer_remove);
 
 /**
  * drm_crtc_init - Initialise a new CRTC object
@@ -1032,7 +1092,7 @@ void drm_mode_config_cleanup(struct drm_device *dev)
}
 
list_for_each_entry_safe(fb, fbt, dev-mode_config.fb_list, head) {
-   fb-funcs-destroy(fb);
+   drm_framebuffer_remove(fb);
}
 
list_for_each_entry_safe(crtc, ct, dev-mode_config.crtc_list, head) {
@@ -2343,11 +2403,8 @@ int drm_mode_rmfb(struct drm_device *dev,
goto out;
}
 
-   /* 

[Bug 42490] NUTMEG DP to VGA bridge not working

[bugzilla-daemon]

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

lukensh...@ngi.it changed:

   What|Removed |Added

 CC||lukensh...@ngi.it

--- Comment #30 from lukensh...@ngi.it 2012-09-05 18:31:11 UTC ---
I have a similar problem: right after boot, my screen works (displays kernel
messages) until maybe drm module is loaded (I guess by udev), then it becomes
immediately blank and monitor is blinking, and then works again some time after
fbcon and radeon modules are manually loaded in boot scripts (before starting
X).
It depends on modeset=1; if I use modeset=0 this behaviour doesn't appear, bua
X cannot run without KMS.

I have an AMD A4-3300 APU and using a (vanilla) linux kernel 3.5.3 (on
Slackware64)

The real problem is that some time (a couple of minutes or so) after video
adapter is in idle mode (e.g. if I am not using the PC), monitor blinks (as in
low power mode) screen is blank and system is no longer recoverable (unless I
use e.g. ssh just to power it off).
I don't know if the two problems are really related or not. Voltage problems?

I have these messages in dmesg, too, when it happens:

[ 2405.888198] [drm:radeon_atom_encoder_dpms], encoder dpms 33 to mode 0,
devices 0001, active_devices 0001
[ 2405.892352] [drm:radeon_dp_get_link_status], link status 44 44 01 00 44 44
[ 2405.892360] [drm:dp_get_adjust_train], requested signal parameters: lane 0
voltage 0.4V pre_emph 3.5dB
[ 2405.892365] [drm:dp_get_adjust_train], using signal parameters: voltage 0.4V
pre_emph 3.5dB
[ 2405.893921] [drm:radeon_dp_get_link_status], link status 44 44 01 00 48 44
[ 2405.893926] [drm:dp_get_adjust_train], requested signal parameters: lane 0
voltage 0.4V pre_emph 6dB
[ 2405.893931] [drm:dp_get_adjust_train], using signal parameters: voltage 0.4V
pre_emph 6dB
[ 2405.895508] [drm:radeon_dp_get_link_status], link status 44 44 01 00 4c 44
[ 2405.895514] [drm:dp_get_adjust_train], requested signal parameters: lane 0
voltage 0.4V pre_emph 9.5dB
[ 2405.895518] [drm:dp_get_adjust_train], using signal parameters: voltage 0.4V
pre_emph 9.5dB
[ 2405.897079] [drm:radeon_dp_get_link_status], link status 44 44 01 00 41 44
[ 2405.897085] [drm:dp_get_adjust_train], requested signal parameters: lane 0
voltage 0.6V pre_emph 0dB
[ 2405.897089] [drm:dp_get_adjust_train], using signal parameters: voltage 0.6V
pre_emph 0dB
[ 2405.898632] [drm:radeon_dp_get_link_status], link status 44 44 01 00 45 44
[ 2405.898634] [drm:dp_get_adjust_train], requested signal parameters: lane 0
voltage 0.6V pre_emph 3.5dB
[ 2405.898636] [drm:dp_get_adjust_train], using signal parameters: voltage 0.6V
pre_emph 3.5dB
[ 2405.900152] [drm:radeon_dp_get_link_status], link status 44 44 01 00 49 44
[ 2405.900155] [drm:dp_get_adjust_train], requested signal parameters: lane 0
voltage 0.6V pre_emph 6dB
[ 2405.900156] [drm:dp_get_adjust_train], using signal parameters: voltage 0.6V
pre_emph 6dB
[ 2405.901674] [drm:radeon_dp_get_link_status], link status 44 44 01 00 42 44
[ 2405.901676] [drm:dp_get_adjust_train], requested signal parameters: lane 0
voltage 0.8V pre_emph 0dB
[ 2405.901677] [drm:dp_get_adjust_train], using signal parameters: voltage 0.8V
pre_emph 0dB
[ 2405.903194] [drm:radeon_dp_get_link_status], link status 44 44 01 00 46 44
[ 2405.903196] [drm:dp_get_adjust_train], requested signal parameters: lane 0
voltage 0.8V pre_emph 3.5dB
[ 2405.903197] [drm:dp_get_adjust_train], using signal parameters: voltage 0.8V
pre_emph 3.5dB
[ 2405.904715] [drm:radeon_dp_get_link_status], link status 44 44 01 00 43 44
[ 2405.904717] [drm:dp_get_adjust_train], requested signal parameters: lane 0
voltage 1.2V pre_emph 0dB
[ 2405.904718] [drm:dp_get_adjust_train], using signal parameters: voltage 1.2V
pre_emph 0dB
[ 2405.906235] [drm:radeon_dp_get_link_status], link status 44 44 01 00 43 44
[ 2405.906238] [drm:radeon_dp_link_train_cr] *ERROR* clock recovery reached max
voltage
[ 2405.906240] [drm:radeon_dp_link_train_cr] *ERROR* clock recovery failed


-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 42490] NUTMEG DP to VGA bridge not working

[bugzilla-daemon]

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

--- Comment #31 from Alex Deucher ag...@yahoo.com 2012-09-05 18:34:56 UTC ---
Please try my 3.6 fixes tree (should show up in 3.6.0rc4+ and eventually stable
kernels).
http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-fixes-3.6

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot

[bugzilla-daemon]

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

Florian Mickler flor...@mickler.org changed:

   What|Removed |Added

 CC||flor...@mickler.org

--- Comment #37 from Florian Mickler flor...@mickler.org 2012-09-05 20:39:27 
UTC ---
A patch referencing this bug report has been merged in Linux v3.6-rc3:

commit 268ba0a99f89a84dc5eb312470896113d0709c74
Author: David Lamparter equi...@diac24.net
Date:   Thu Aug 16 15:45:20 2012 -0400

drm/radeon: implement ACPI VFCT vbios fetch (v3)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 41265] Radeon KMS does not work on thunderbolt media dock

[bugzilla-daemon]

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

Florian Mickler flor...@mickler.org changed:

   What|Removed |Added

 CC||flor...@mickler.org

--- Comment #52 from Florian Mickler flor...@mickler.org 2012-09-05 20:41:16 
UTC ---
A patch referencing this bug report has been merged in Linux v3.6-rc3:

commit c61e2775873f603148e8e998a938721b7d222d24
Author: Alex Deucher alexander.deuc...@amd.com
Date:   Thu Aug 16 15:39:09 2012 -0400

drm/radeon: split ATRM support out from the ATPX handler (v3)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: refcnt drm_framebuffer

[Rob Clark]

On Wed, Sep 5, 2012 at 1:17 PM, Rob Clark rob.cl...@linaro.org wrote:
 From: Rob Clark r...@ti.com

 This simplifies drm fb lifetime, and if the crtc/plane needs to hold
 a ref to the fb when disabling a pipe until the next vblank, this
 avoids the need to make disabling an overlay synchronous.  This is a
 problem that shows up when userspace is using a drm plane to
 implement a hw cursor.. making overlay disable synchronous causes
 a performance problem when x11 is rapidly enabling/disabling the
 hw cursor.  But not making it synchronous opens up a race condition
 for crashing if userspace turns around and immediately deletes the
 fb.  Refcnt'ing the fb makes it possible to solve this problem.

 v1: original
 v2: add drm_framebuffer_remove() which is called in all paths where
 fb-funcs-destroy() was directly called before.  This cleans
 up the CRTCs/planes that the fb was attached to.  You should
 only directly use drm_framebuffer_unreference() if you are also
 using drm_framebuffer_reference() to keep a ref to the fb.
 v3: add comment explaining the fb refcount

 Signed-off-by: Rob Clark r...@ti.com
 Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch

 ---
  drivers/gpu/drm/drm_crtc.c|   78 
 +
  drivers/gpu/drm/exynos/exynos_drm_fbdev.c |4 +-
  drivers/gpu/drm/i915/intel_display.c  |4 +-
  drivers/staging/omapdrm/omap_fbdev.c  |4 +-
  include/drm/drm_crtc.h|   14 ++
  5 files changed, 87 insertions(+), 17 deletions(-)

 diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
 index 901de9a..96e236f 100644
 --- a/drivers/gpu/drm/drm_crtc.c
 +++ b/drivers/gpu/drm/drm_crtc.c
 @@ -294,6 +294,8 @@ int drm_framebuffer_init(struct drm_device *dev, struct 
 drm_framebuffer *fb,
  {
 int ret;

 +   kref_init(fb-refcount);
 +
 ret = drm_mode_object_get(dev, fb-base, DRM_MODE_OBJECT_FB);
 if (ret)
 return ret;
 @@ -307,6 +309,38 @@ int drm_framebuffer_init(struct drm_device *dev, struct 
 drm_framebuffer *fb,
  }
  EXPORT_SYMBOL(drm_framebuffer_init);

 +static void drm_framebuffer_free(struct kref *kref)
 +{
 +   struct drm_framebuffer *fb =
 +   container_of(kref, struct drm_framebuffer, refcount);
 +   fb-funcs-destroy(fb);
 +}
 +
 +/**
 + * drm_framebuffer_unreference - unref a framebuffer
 + *
 + * LOCKING:
 + * Caller must hold mode config lock.
 + */
 +void drm_framebuffer_unreference(struct drm_framebuffer *fb)
 +{
 +   struct drm_device *dev = fb-dev;
 +   DRM_DEBUG(FB ID: %d\n, fb-base.id);
 +   WARN_ON(!mutex_is_locked(dev-mode_config.mutex));
 +   kref_put(fb-refcount, drm_framebuffer_free);
 +}
 +EXPORT_SYMBOL(drm_framebuffer_unreference);
 +
 +/**
 + * drm_framebuffer_reference - incr the fb refcnt
 + */
 +void drm_framebuffer_reference(struct drm_framebuffer *fb)
 +{
 +   DRM_DEBUG(FB ID: %d\n, fb-base.id);
 +   kref_get(fb-refcount);
 +}
 +EXPORT_SYMBOL(drm_framebuffer_reference);
 +
  /**
   * drm_framebuffer_cleanup - remove a framebuffer object
   * @fb: framebuffer to remove
 @@ -320,6 +354,32 @@ EXPORT_SYMBOL(drm_framebuffer_init);
  void drm_framebuffer_cleanup(struct drm_framebuffer *fb)
  {
 struct drm_device *dev = fb-dev;
 +   /*
 +* This could be moved to drm_framebuffer_remove(), but for
 +* debugging is nice to keep around the list of fb's that are
 +* no longer associated w/ a drm_file but are not unreferenced
 +* yet.  (i915 and omapdrm have debugfs files which will show
 +* this.)
 +*/
 +   drm_mode_object_put(dev, fb-base);
 +   list_del(fb-head);
 +   dev-mode_config.num_fb--;
 +}
 +EXPORT_SYMBOL(drm_framebuffer_cleanup);
 +
 +/**
 + * drm_framebuffer_remove - remove and unreference a framebuffer object
 + * @fb: framebuffer to remove
 + *
 + * LOCKING:
 + * Caller must hold mode config lock.
 + *
 + * Scans all the CRTCs and planes in @dev's mode_config.  If they're
 + * using @fb, removes it, setting it to NULL.
 + */
 +void drm_framebuffer_remove(struct drm_framebuffer *fb)
 +{
 +   struct drm_device *dev = fb-dev;
 struct drm_crtc *crtc;
 struct drm_plane *plane;
 struct drm_mode_set set;
 @@ -350,11 +410,11 @@ void drm_framebuffer_cleanup(struct drm_framebuffer *fb)
 }
 }

 -   drm_mode_object_put(dev, fb-base);
 -   list_del(fb-head);
 -   dev-mode_config.num_fb--;
 +   list_del(fb-filp_head);
 +
 +   drm_framebuffer_unreference(fb);
  }
 -EXPORT_SYMBOL(drm_framebuffer_cleanup);
 +EXPORT_SYMBOL(drm_framebuffer_remove);

  /**
   * drm_crtc_init - Initialise a new CRTC object
 @@ -1032,7 +1092,7 @@ void drm_mode_config_cleanup(struct drm_device *dev)
 }

 list_for_each_entry_safe(fb, fbt, dev-mode_config.fb_list, head) {
 -   fb-funcs-destroy(fb);
 +   drm_framebuffer_remove(fb);
   

[PATCH] drm/exynos: fix double call of drm_prime_(init/destroy)_file_private

[Mandeep Singh Baines]

The double invocations are incorrect but seem to be safe so I don't
think this will fix any bugs.

Before:

[7.639366] drm_prime_init_file ee3675d0
[7.639377] drm_prime_init_file ee3675d0
[7.639507] drm_prime_destroy_file ee3675d0
[7.639518] drm_prime_destroy_file ee3675d0
[7.639802] drm_prime_init_file ee372390
[7.639810] drm_prime_init_file ee372390
[8.473316] drm_prime_init_file ee356390
[8.473331] drm_prime_init_file ee356390

After:

[6.363842] drm_prime_init_file edc2e5d0
[6.363994] drm_prime_destroy_file edc2e5d0
[6.364260] drm_prime_init_file edc2e750
[8.004837] drm_prime_init_file ee36ded0

Signed-off-by: Mandeep Singh Baines m...@chromium.org
CC: Stéphane Marchesin marc...@chromium.org
CC: Pawel Osciak posc...@google.com
CC: Inki Dae inki@samsung.com
CC: Joonyoung Shim jy0922.s...@samsung.com
CC: Seung-Woo Kim sw0312@samsung.com
CC: Kyungmin Park kyungmin.p...@samsung.com
CC: David Airlie airl...@linux.ie
CC: dri-devel@lists.freedesktop.org
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index ebacec6..a27b8ff 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -160,7 +160,6 @@ static int exynos_drm_open(struct drm_device *dev, struct 
drm_file *file)
if (!file_priv)
return -ENOMEM;
 
-   drm_prime_init_file_private(file-prime);
file-driver_priv = file_priv;
 
return exynos_drm_subdrv_open(dev, file);
@@ -184,7 +183,6 @@ static void exynos_drm_preclose(struct drm_device *dev,
e-base.destroy(e-base);
}
}
-   drm_prime_destroy_file_private(file-prime);
spin_unlock_irqrestore(dev-event_lock, flags);
 
exynos_drm_subdrv_close(dev, file);
-- 
1.7.7.3

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

[PATCH] drm: refcnt drm_framebuffer

[Rob Clark]

From: Rob Clark r...@ti.com

This simplifies drm fb lifetime, and if the crtc/plane needs to hold
a ref to the fb when disabling a pipe until the next vblank, this
avoids the need to make disabling an overlay synchronous.  This is a
problem that shows up when userspace is using a drm plane to
implement a hw cursor.. making overlay disable synchronous causes
a performance problem when x11 is rapidly enabling/disabling the
hw cursor.  But not making it synchronous opens up a race condition
for crashing if userspace turns around and immediately deletes the
fb.  Refcnt'ing the fb makes it possible to solve this problem.

v1: original
v2: add drm_framebuffer_remove() which is called in all paths where
fb-funcs-destroy() was directly called before.  This cleans
up the CRTCs/planes that the fb was attached to.  You should
only directly use drm_framebuffer_unreference() if you are also
using drm_framebuffer_reference() to keep a ref to the fb.
v3: add comment explaining the fb refcount
v4: remove duplicate 'list_del(fb-filp_head)'

Signed-off-by: Rob Clark r...@ti.com
---
 drivers/gpu/drm/drm_crtc.c|   79 -
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |4 +-
 drivers/gpu/drm/i915/intel_display.c  |4 +-
 drivers/staging/omapdrm/omap_fbdev.c  |4 +-
 include/drm/drm_crtc.h|   14 +
 5 files changed, 87 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 901de9a..7552675 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -294,6 +294,8 @@ int drm_framebuffer_init(struct drm_device *dev, struct 
drm_framebuffer *fb,
 {
int ret;
 
+   kref_init(fb-refcount);
+
ret = drm_mode_object_get(dev, fb-base, DRM_MODE_OBJECT_FB);
if (ret)
return ret;
@@ -307,6 +309,38 @@ int drm_framebuffer_init(struct drm_device *dev, struct 
drm_framebuffer *fb,
 }
 EXPORT_SYMBOL(drm_framebuffer_init);
 
+static void drm_framebuffer_free(struct kref *kref)
+{
+   struct drm_framebuffer *fb =
+   container_of(kref, struct drm_framebuffer, refcount);
+   fb-funcs-destroy(fb);
+}
+
+/**
+ * drm_framebuffer_unreference - unref a framebuffer
+ *
+ * LOCKING:
+ * Caller must hold mode config lock.
+ */
+void drm_framebuffer_unreference(struct drm_framebuffer *fb)
+{
+   struct drm_device *dev = fb-dev;
+   DRM_DEBUG(FB ID: %d\n, fb-base.id);
+   WARN_ON(!mutex_is_locked(dev-mode_config.mutex));
+   kref_put(fb-refcount, drm_framebuffer_free);
+}
+EXPORT_SYMBOL(drm_framebuffer_unreference);
+
+/**
+ * drm_framebuffer_reference - incr the fb refcnt
+ */
+void drm_framebuffer_reference(struct drm_framebuffer *fb)
+{
+   DRM_DEBUG(FB ID: %d\n, fb-base.id);
+   kref_get(fb-refcount);
+}
+EXPORT_SYMBOL(drm_framebuffer_reference);
+
 /**
  * drm_framebuffer_cleanup - remove a framebuffer object
  * @fb: framebuffer to remove
@@ -320,6 +354,32 @@ EXPORT_SYMBOL(drm_framebuffer_init);
 void drm_framebuffer_cleanup(struct drm_framebuffer *fb)
 {
struct drm_device *dev = fb-dev;
+   /*
+* This could be moved to drm_framebuffer_remove(), but for
+* debugging is nice to keep around the list of fb's that are
+* no longer associated w/ a drm_file but are not unreferenced
+* yet.  (i915 and omapdrm have debugfs files which will show
+* this.)
+*/
+   drm_mode_object_put(dev, fb-base);
+   list_del(fb-head);
+   dev-mode_config.num_fb--;
+}
+EXPORT_SYMBOL(drm_framebuffer_cleanup);
+
+/**
+ * drm_framebuffer_remove - remove and unreference a framebuffer object
+ * @fb: framebuffer to remove
+ *
+ * LOCKING:
+ * Caller must hold mode config lock.
+ *
+ * Scans all the CRTCs and planes in @dev's mode_config.  If they're
+ * using @fb, removes it, setting it to NULL.
+ */
+void drm_framebuffer_remove(struct drm_framebuffer *fb)
+{
+   struct drm_device *dev = fb-dev;
struct drm_crtc *crtc;
struct drm_plane *plane;
struct drm_mode_set set;
@@ -350,11 +410,11 @@ void drm_framebuffer_cleanup(struct drm_framebuffer *fb)
}
}
 
-   drm_mode_object_put(dev, fb-base);
-   list_del(fb-head);
-   dev-mode_config.num_fb--;
+   list_del(fb-filp_head);
+
+   drm_framebuffer_unreference(fb);
 }
-EXPORT_SYMBOL(drm_framebuffer_cleanup);
+EXPORT_SYMBOL(drm_framebuffer_remove);
 
 /**
  * drm_crtc_init - Initialise a new CRTC object
@@ -1032,7 +1092,7 @@ void drm_mode_config_cleanup(struct drm_device *dev)
}
 
list_for_each_entry_safe(fb, fbt, dev-mode_config.fb_list, head) {
-   fb-funcs-destroy(fb);
+   drm_framebuffer_remove(fb);
}
 
list_for_each_entry_safe(crtc, ct, dev-mode_config.crtc_list, head) {
@@ -2343,11 +2403,7 @@ int drm_mode_rmfb(struct drm_device *dev,
goto out;
}
 
-   /* TODO 

[PATCH] drm/omap: update for interlaced

[Rob Clark]

From: Rob Clark r...@ti.com

'struct omap_video_timings' was updated w/ a 'bool interlaced'.  Without
a matching update in omap_connector, this field could have undefined
values from the stack, which isn't quite ideal.

Update the fxns to convert omapdss-drm timings structs, and zero-init
'struct omap_video_timings' when it is declared on stack to avoid issues
like this in the future.

Signed-off-by: Rob Clark r...@ti.com
---
 drivers/staging/omapdrm/omap_connector.c |   17 -
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/omapdrm/omap_connector.c 
b/drivers/staging/omapdrm/omap_connector.c
index 5e2856c..5f4a89b 100644
--- a/drivers/staging/omapdrm/omap_connector.c
+++ b/drivers/staging/omapdrm/omap_connector.c
@@ -48,13 +48,10 @@ static inline void copy_timings_omap_to_drm(struct 
drm_display_mode *mode,
mode-vsync_end = mode-vsync_start + timings-vsw;
mode-vtotal = mode-vsync_end + timings-vbp;
 
-   /* note: whether or not it is interlaced, +/- h/vsync, etc,
-* which should be set in the mode flags, is not exposed in
-* the omap_video_timings struct.. but hdmi driver tracks
-* those separately so all we have to have to set the mode
-* is the way to recover these timings values, and the
-* omap_dss_driver would do the rest.
-*/
+   mode-flags = 0;
+
+   if (timings-interlace)
+   mode-flags |= DRM_MODE_FLAG_INTERLACE;
 }
 
 static inline void copy_timings_drm_to_omap(struct omap_video_timings *timings,
@@ -71,6 +68,8 @@ static inline void copy_timings_drm_to_omap(struct 
omap_video_timings *timings,
timings-vfp = mode-vsync_start - mode-vdisplay;
timings-vsw = mode-vsync_end - mode-vsync_start;
timings-vbp = mode-vtotal - mode-vsync_end;
+
+   timings-interlace = !!(mode-flags  DRM_MODE_FLAG_INTERLACE);
 }
 
 static void omap_connector_dpms(struct drm_connector *connector, int mode)
@@ -187,7 +186,7 @@ static int omap_connector_get_modes(struct drm_connector 
*connector)
}
} else {
struct drm_display_mode *mode = drm_mode_create(dev);
-   struct omap_video_timings timings;
+   struct omap_video_timings timings = {0};
 
dssdrv-get_timings(dssdev, timings);
 
@@ -291,7 +290,7 @@ void omap_connector_mode_set(struct drm_connector 
*connector,
struct omap_connector *omap_connector = to_omap_connector(connector);
struct omap_dss_device *dssdev = omap_connector-dssdev;
struct omap_dss_driver *dssdrv = dssdev-driver;
-   struct omap_video_timings timings;
+   struct omap_video_timings timings = {0};
 
copy_timings_drm_to_omap(timings, mode);
 
-- 
1.7.9.5

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

Re: 3.5-rc7: nouveau doesn't X on NVC0

[Linus Torvalds]

[ This got dropped somehow - it's in my draft folder. The bisection
may be irrelevant now: does it work with current git, since we've had
some nouveau changes? ]

On Tue, Aug 28, 2012 at 8:26 AM, Alexey Dobriyan adobri...@gmail.com wrote:
 Ping!

 No X for me with 3.6-rc2.

Can you possibly bisect it, at least partially? Just knowing exactly
where it started might help the nouveau developers,

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

Re: 3.5-rc7: nouveau doesn't X on NVC0

[Dave Airlie]

On Thu, Sep 6, 2012 at 11:15 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
 [ This got dropped somehow - it's in my draft folder. The bisection
 may be irrelevant now: does it work with current git, since we've had
 some nouveau changes? ]

 On Tue, Aug 28, 2012 at 8:26 AM, Alexey Dobriyan adobri...@gmail.com wrote:
 Ping!

 No X for me with 3.6-rc2.

Can you try -rc4?

Ben thinks the pcopy fix should fix it.

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

Re: [PATCH] drm/exynos: fix double call of drm_prime_(init/destroy)_file_private

[김승우]

Hi Mandeep,

On 2012년 09월 06일 06:47, Mandeep Singh Baines wrote:
 The double invocations are incorrect but seem to be safe so I don't
 think this will fix any bugs.
 
 Before:
 
 [7.639366] drm_prime_init_file ee3675d0
 [7.639377] drm_prime_init_file ee3675d0
 [7.639507] drm_prime_destroy_file ee3675d0
 [7.639518] drm_prime_destroy_file ee3675d0
 [7.639802] drm_prime_init_file ee372390
 [7.639810] drm_prime_init_file ee372390
 [8.473316] drm_prime_init_file ee356390
 [8.473331] drm_prime_init_file ee356390
 
 After:
 
 [6.363842] drm_prime_init_file edc2e5d0
 [6.363994] drm_prime_destroy_file edc2e5d0
 [6.364260] drm_prime_init_file edc2e750
 [8.004837] drm_prime_init_file ee36ded0
 

You are right. prime file_priv is handled by drm_fops.c, so it can be
removed from exynos drm.

Thanks for your patch.

 Signed-off-by: Mandeep Singh Baines m...@chromium.org
 CC: Stéphane Marchesin marc...@chromium.org
 CC: Pawel Osciak posc...@google.com
 CC: Inki Dae inki@samsung.com
 CC: Joonyoung Shim jy0922.s...@samsung.com
 CC: Seung-Woo Kim sw0312@samsung.com
 CC: Kyungmin Park kyungmin.p...@samsung.com
 CC: David Airlie airl...@linux.ie
 CC: dri-devel@lists.freedesktop.org

Acked-by: Seung-Woo Kim sw0312@samsung.com

 ---
  drivers/gpu/drm/exynos/exynos_drm_drv.c |2 --
  1 files changed, 0 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
 b/drivers/gpu/drm/exynos/exynos_drm_drv.c
 index ebacec6..a27b8ff 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
 @@ -160,7 +160,6 @@ static int exynos_drm_open(struct drm_device *dev, struct 
 drm_file *file)
   if (!file_priv)
   return -ENOMEM;
  
 - drm_prime_init_file_private(file-prime);
   file-driver_priv = file_priv;
  
   return exynos_drm_subdrv_open(dev, file);
 @@ -184,7 +183,6 @@ static void exynos_drm_preclose(struct drm_device *dev,
   e-base.destroy(e-base);
   }
   }
 - drm_prime_destroy_file_private(file-prime);
   spin_unlock_irqrestore(dev-event_lock, flags);
  
   exynos_drm_subdrv_close(dev, file);
 

-- 
Seung-Woo Kim
Samsung Software RD Center
--

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