[PATCH 0/4] drm/exynos: fimd: Add support for S3C6400/S3C6410

[Tomasz Figa]

On Sunday 19 of May 2013 13:26:57 Tomasz Figa wrote:
> Hi,
> 
> On Wednesday 01 of May 2013 21:02:25 Tomasz Figa wrote:
> > Much of the code in Exynos DRM subsystem is generic enough to use
> > it for older (non-Exynos) Samsung SoCs as well, after minor
> > modifications.
> > 
> > This series starts adding support for previous SoCs to Exynos DRM by
> > introducing S3C64xx support to exynos_drm_fimd driver.
> > 
> > Adding support for remaining SoCs between S3C64xx and Exynos4
> > (S5PC100,
> > S5P64x0 and S5PV210) should be rather straightforward, but at the
> > moment I can test only on S3C6410, so I limited my changes only to
> > this SoC.
> > 
> > On Tiny6410 (Mini6410-compatible) board based on Samsung S3C6410 SoC,
> > using my to-be-resubmitted patches for Device Tree support:
> > 
> > Tested-by: Tomasz Figa 
> > 
> > Tomasz Figa (4):
> >   drm/exynos: fimd: Hold pointer to driver data in context struct
> >   drm/exynos: fimd: Add support for FIMD versions without SHADOWCON
> >   
> > register
> >   
> >   drm/exynos: fimd: Add support for FIMD variants with clock selection
> >   drm/exynos: fimd: Add support for S3C64xx SoCs
> >  
> >  drivers/gpu/drm/exynos/exynos_drm_fimd.c | 90
> > 
> >  1 file changed, 68 insertions(+), 22
> > deletions(-)
> 
> Any comments for this series?
> 
> Best regards,
> Tomasz

Ping.

Best regards,
Tomasz

[PATCH] drm/exynos: fimd: Get signal polarities from device tree

[Tomasz Figa]

On Wednesday 01 of May 2013 21:06:09 Tomasz Figa wrote:
> This patch modifies the driver to perform two stage parsing of video
> timings from device tree, to get timing information as struct videomode,
> which contains more data than struct fb_videomode.
> 
> Thanks to this change, information about polarity of control signals
> (VSYNC, HSYNC, VDEN, VCLK) can be retrieved, in addition to standard
> video timings.
> 
> Signed-off-by: Tomasz Figa 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c | 18 --
>  1 file changed, 16 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c index a1669d4..9023efa
> 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -21,7 +21,9 @@
>  #include 
> 
>  #include 
> +#include 
>  #include 
> +#include 
>  #include 
> 
>  #include "exynos_drm_drv.h"
> @@ -928,18 +930,30 @@ static int fimd_probe(struct platform_device
> *pdev) DRM_DEBUG_KMS("%s\n", __FILE__);
> 
>   if (pdev->dev.of_node) {
> + struct videomode vm;
> +
>   pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
>   if (!pdata) {
>   DRM_ERROR("memory allocation for pdata failed\n");
>   return -ENOMEM;
>   }
> 
> - ret = of_get_fb_videomode(dev->of_node, 
>panel.timing,
> - OF_USE_NATIVE_MODE);
> + ret = of_get_videomode(dev->of_node, , 
OF_USE_NATIVE_MODE);
>   if (ret) {
>   DRM_ERROR("failed: of_get_fb_videomode() : %d\n", 
ret);
>   return ret;
>   }
> +
> + fb_videomode_from_videomode(, >panel.timing);
> +
> + if (vm.flags & DISPLAY_FLAGS_VSYNC_LOW)
> + pdata->vidcon1 |= VIDCON1_INV_VSYNC;
> + if (vm.flags & DISPLAY_FLAGS_HSYNC_LOW)
> + pdata->vidcon1 |= VIDCON1_INV_HSYNC;
> + if (vm.flags & DISPLAY_FLAGS_DE_LOW)
> + pdata->vidcon1 |= VIDCON1_INV_VDEN;
> + if (vm.flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE)
> + pdata->vidcon1 |= VIDCON1_INV_VCLK;
>   } else {
>   pdata = pdev->dev.platform_data;
>   if (!pdata) {

Ping.

Best regards,
Tomasz

[Bug 65270] CAICOS [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!

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

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

Gerben Welter  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #7 from Gerben Welter  ---
Closing as invalid because of PEBCAK error.

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

[Bug 65270] CAICOS [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!

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

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

--- Comment #6 from Gerben Welter  ---
(In reply to comment #5)
> You not only need the new one the initrd updater is complaining about, you
> also need the new RLC firmware. Otherwise the hardware would produce exactly
> the error you are describing.
> 
> Please double check that you got the right versions of the firmware files.

Ahh, I hadn't noticed the already present files had been updated. I
redownloaded all the *.bin files and updated the initrd. UVD now intializes.
Thank you for your help.

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

[Bug 65274] TURKS [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! (non-EFI laptop)

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

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

--- Comment #5 from russianneuromancer at ya.ru ---
> For TURKS you need to update BTC_rlc.bin, not SUMO_rlc.bin.
Ok, I update BTC_rlc.bin: ~$ md5sum /lib/firmware/radeon/BTC_rlc.bin
25d61fad839b30b263f52328c1f678fb  /lib/firmware/radeon/BTC_rlc.bin
But there is same error on reboot:
> [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!

Also I just understand - I probably upload UVD regs of working UVD module of
first GPU, and for UVD regs of second GPU you probably need regs from different
addresses, right?

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

[Bug 65274] TURKS [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! (non-EFI laptop)

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

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

--- Comment #4 from Christian K?nig  ---
For TURKS you need to update BTC_rlc.bin, not SUMO_rlc.bin.

Only the SUMO UVD firmware is used for both generations.

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

[Bug 65270] CAICOS [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!

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

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

--- Comment #5 from Christian K?nig  ---
(In reply to comment #4)
> (In reply to comment #1)
> > Make sure you've installed the updated rlc and uvd microcode and that it is
> > available to the driver during boot (in your initrd, etc.).  You can grab
> > the latest ucode here:
> > http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git
> > or here:
> > http://people.freedesktop.org/~agd5f/radeon_ucode/
> > You need BTC_rlc.bin and SUMO_uvd.bin for UVD on your chip.
> 
> Yeah, I grabbed those already otherwise the update of the initrd starts
> complaining they are missing.

You not only need the new one the initrd updater is complaining about, you also
need the new RLC firmware. Otherwise the hardware would produce exactly the
error you are describing.

Please double check that you got the right versions of the firmware files.

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

[PATCH] drm: Avoid forcing a detection cycle following a hotplug event

[Chris Wilson]

The typical procedure after a hotplug event is then to enumerate all the
new modes. In the existing code, this is achieved by performing a forced
detection cycle over all connectors. Ideally, we should just be able to
use the current detection status and only enumerate the modes on the
connectors that changed. This is a step in that direction by teaching
the hotplug path to only use the known detection status rather than
performing a second *forced* detection on every connector. As it
currently stands, the first thing userspace does upon receipt of a
hotplug uevent is call DRM_IOCTL_MODE_GETCONNECTOR on each connector,
which of course, performs another full detection cycle.

Signed-off-by: Chris Wilson 
Cc: dri-devel at lists.freedesktop.org
Cc: Jakob Bornecrantz 
Cc: Inki Dae 
Cc: Adam Jackson 
---
 drivers/gpu/drm/drm_crtc.c|3 ++-
 drivers/gpu/drm/drm_crtc_helper.c |8 ++--
 drivers/gpu/drm/drm_fb_helper.c   |   14 --
 drivers/gpu/drm/exynos/exynos_drm_connector.c |7 ---
 drivers/gpu/drm/i2c/ch7006_drv.c  |2 +-
 drivers/gpu/drm/nouveau/dispnv04/tvnv17.c |2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c   |3 ++-
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.h   |3 ++-
 include/drm/drm_crtc.h|2 +-
 include/drm/drm_crtc_helper.h |2 +-
 10 files changed, 28 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index e7e9242..635276c 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1537,7 +1537,8 @@ int drm_mode_getconnector(struct drm_device *dev, void 
*data,
if (out_resp->count_modes == 0) {
connector->funcs->fill_modes(connector,
 dev->mode_config.max_width,
-dev->mode_config.max_height);
+dev->mode_config.max_height,
+true);
}

/* delayed so we get modes regardless of pre-fill_modes state */
diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index ed1334e..7f2128c 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -96,6 +96,9 @@ static void drm_mode_validate_flag(struct drm_connector 
*connector,
  * @connector: connector to probe
  * @maxX: max width for modes
  * @maxY: max height for modes
+ * @force: whether to use the cached connector status or to force a
+ * fresh detection cycle, for instance after a hotplug event, we
+ * want to simply use the known status.
  *
  * LOCKING:
  * Caller must hold mode config lock.
@@ -113,7 +116,8 @@ static void drm_mode_validate_flag(struct drm_connector 
*connector,
  * Number of modes found on @connector.
  */
 int drm_helper_probe_single_connector_modes(struct drm_connector *connector,
-   uint32_t maxX, uint32_t maxY)
+   uint32_t maxX, uint32_t maxY,
+   bool force)
 {
struct drm_device *dev = connector->dev;
struct drm_display_mode *mode;
@@ -136,7 +140,7 @@ int drm_helper_probe_single_connector_modes(struct 
drm_connector *connector,
connector->status = connector_status_disconnected;
if (connector->funcs->force)
connector->funcs->force(connector);
-   } else {
+   } else if (force) {
connector->status = connector->funcs->detect(connector, true);
}

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index b78cbe7..3e0802d 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1087,8 +1087,8 @@ void drm_fb_helper_fill_var(struct fb_info *info, struct 
drm_fb_helper *fb_helpe
 EXPORT_SYMBOL(drm_fb_helper_fill_var);

 static int drm_fb_helper_probe_connector_modes(struct drm_fb_helper *fb_helper,
-  uint32_t maxX,
-  uint32_t maxY)
+  uint32_t maxX, uint32_t maxY,
+  bool force)
 {
struct drm_connector *connector;
int count = 0;
@@ -1096,7 +1096,7 @@ static int drm_fb_helper_probe_connector_modes(struct 
drm_fb_helper *fb_helper,

for (i = 0; i < fb_helper->connector_count; i++) {
connector = fb_helper->connector_info[i]->connector;
-   count += connector->funcs->fill_modes(connector, maxX, maxY);
+   count += connector->funcs->fill_modes(connector, maxX, maxY, 
force);
}

return count;
@@ -1510,7 +1510,8 @@ bool drm_fb_helper_initial_config(struct drm_fb_helper 
*fb_helper, int bpp_sel)

[PATCH 2/2] drm/exynos: Clean up logs for DRM_ERROR / DRM_DEBUG_KMS

[Seung-Woo Kim]

From: YoungJun Cho 

This patch cleans up logs for DRM_ERROR / DRM_DEBUG_KMS to avoid
logging duplicated function name because the macros already contain
 __func__.

Signed-off-by: YoungJun Cho 
Signed-off-by: Seung-Woo Kim 
---
 drivers/gpu/drm/exynos/exynos_drm_fimc.c|  113 ++---
 drivers/gpu/drm/exynos/exynos_drm_gsc.c |   90 +++-
 drivers/gpu/drm/exynos/exynos_drm_ipp.c |  149 ---
 drivers/gpu/drm/exynos/exynos_drm_rotator.c |   41 +++
 drivers/gpu/drm/exynos/exynos_hdmi.c|   10 +-
 drivers/gpu/drm/exynos/exynos_mixer.c   |   12 +-
 6 files changed, 189 insertions(+), 226 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 7b5f2e8..61b094f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -217,7 +217,7 @@ static void fimc_set_type_ctrl(struct fimc_context *ctx, 
enum fimc_wb wb)
 {
u32 cfg;

-   DRM_DEBUG_KMS("%s:wb[%d]\n", __func__, wb);
+   DRM_DEBUG_KMS("wb[%d]\n", wb);

cfg = fimc_read(EXYNOS_CIGCTRL);
cfg &= ~(EXYNOS_CIGCTRL_TESTPATTERN_MASK |
@@ -253,10 +253,10 @@ static void fimc_set_polarity(struct fimc_context *ctx,
 {
u32 cfg;

-   DRM_DEBUG_KMS("%s:inv_pclk[%d]inv_vsync[%d]\n",
-   __func__, pol->inv_pclk, pol->inv_vsync);
-   DRM_DEBUG_KMS("%s:inv_href[%d]inv_hsync[%d]\n",
-   __func__, pol->inv_href, pol->inv_hsync);
+   DRM_DEBUG_KMS("inv_pclk[%d]inv_vsync[%d]\n",
+   pol->inv_pclk, pol->inv_vsync);
+   DRM_DEBUG_KMS("inv_href[%d]inv_hsync[%d]\n",
+   pol->inv_href, pol->inv_hsync);

cfg = fimc_read(EXYNOS_CIGCTRL);
cfg &= ~(EXYNOS_CIGCTRL_INVPOLPCLK | EXYNOS_CIGCTRL_INVPOLVSYNC |
@@ -278,7 +278,7 @@ static void fimc_handle_jpeg(struct fimc_context *ctx, bool 
enable)
 {
u32 cfg;

-   DRM_DEBUG_KMS("%s:enable[%d]\n", __func__, enable);
+   DRM_DEBUG_KMS("enable[%d]\n", enable);

cfg = fimc_read(EXYNOS_CIGCTRL);
if (enable)
@@ -294,7 +294,7 @@ static void fimc_handle_irq(struct fimc_context *ctx, bool 
enable,
 {
u32 cfg;

-   DRM_DEBUG_KMS("%s:enable[%d]overflow[%d]level[%d]\n", __func__,
+   DRM_DEBUG_KMS("enable[%d]overflow[%d]level[%d]\n",
enable, overflow, level);

cfg = fimc_read(EXYNOS_CIGCTRL);
@@ -329,7 +329,7 @@ static bool fimc_check_ovf(struct fimc_context *ctx)
flag = EXYNOS_CISTATUS_OVFIY | EXYNOS_CISTATUS_OVFICB |
EXYNOS_CISTATUS_OVFICR;

-   DRM_DEBUG_KMS("%s:flag[0x%x]\n", __func__, flag);
+   DRM_DEBUG_KMS("flag[0x%x]\n", flag);

if (status & flag) {
cfg = fimc_read(EXYNOS_CIWDOFST);
@@ -358,7 +358,7 @@ static bool fimc_check_frame_end(struct fimc_context *ctx)

cfg = fimc_read(EXYNOS_CISTATUS);

-   DRM_DEBUG_KMS("%s:cfg[0x%x]\n", __func__, cfg);
+   DRM_DEBUG_KMS("cfg[0x%x]\n", cfg);

if (!(cfg & EXYNOS_CISTATUS_FRAMEEND))
return false;
@@ -380,7 +380,7 @@ static int fimc_get_buf_id(struct fimc_context *ctx)
if (frame_cnt == 0)
frame_cnt = EXYNOS_CISTATUS2_GET_FRAMECOUNT_PRESENT(cfg);

-   DRM_DEBUG_KMS("%s:present[%d]before[%d]\n", __func__,
+   DRM_DEBUG_KMS("present[%d]before[%d]\n",
EXYNOS_CISTATUS2_GET_FRAMECOUNT_PRESENT(cfg),
EXYNOS_CISTATUS2_GET_FRAMECOUNT_BEFORE(cfg));

@@ -390,7 +390,7 @@ static int fimc_get_buf_id(struct fimc_context *ctx)
}

buf_id = frame_cnt - 1;
-   DRM_DEBUG_KMS("%s:buf_id[%d]\n", __func__, buf_id);
+   DRM_DEBUG_KMS("buf_id[%d]\n", buf_id);

return buf_id;
 }
@@ -399,7 +399,7 @@ static void fimc_handle_lastend(struct fimc_context *ctx, 
bool enable)
 {
u32 cfg;

-   DRM_DEBUG_KMS("%s:enable[%d]\n", __func__, enable);
+   DRM_DEBUG_KMS("enable[%d]\n", enable);

cfg = fimc_read(EXYNOS_CIOCTRL);
if (enable)
@@ -416,7 +416,7 @@ static int fimc_src_set_fmt_order(struct fimc_context *ctx, 
u32 fmt)
struct exynos_drm_ippdrv *ippdrv = >ippdrv;
u32 cfg;

-   DRM_DEBUG_KMS("%s:fmt[0x%x]\n", __func__, fmt);
+   DRM_DEBUG_KMS("fmt[0x%x]\n", fmt);

/* RGB */
cfg = fimc_read(EXYNOS_CISCCTRL);
@@ -489,7 +489,7 @@ static int fimc_src_set_fmt(struct device *dev, u32 fmt)
struct exynos_drm_ippdrv *ippdrv = >ippdrv;
u32 cfg;

-   DRM_DEBUG_KMS("%s:fmt[0x%x]\n", __func__, fmt);
+   DRM_DEBUG_KMS("fmt[0x%x]\n", fmt);

cfg = fimc_read(EXYNOS_MSCTRL);
cfg &= ~EXYNOS_MSCTRL_INFORMAT_RGB;
@@ -549,8 +549,7 @@ static int fimc_src_set_transf(struct device *dev,
struct exynos_drm_ippdrv *ippdrv = >ippdrv;
u32 cfg1, cfg2;

-   DRM_DEBUG_KMS("%s:degree[%d]flip[0x%x]\n", __func__,
-   degree, flip);
+   

[PATCH 1/2] drm/exynos: Remove tracking log functions

[Seung-Woo Kim]

From: YoungJun Cho 

This patch removes tracking log functions which were used to debug
in the early development stage and are not so important as were.
So remove them for code clean up.

Signed-off-by: YoungJun Cho 
Signed-off-by: Seung-Woo Kim 
---
 drivers/gpu/drm/exynos/exynos_drm_buf.c   |7 ---
 drivers/gpu/drm/exynos/exynos_drm_connector.c |   17 
 drivers/gpu/drm/exynos/exynos_drm_core.c  |   12 --
 drivers/gpu/drm/exynos/exynos_drm_crtc.c  |   29 --
 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c|6 ---
 drivers/gpu/drm/exynos/exynos_drm_drv.c   |   20 -
 drivers/gpu/drm/exynos/exynos_drm_encoder.c   |   28 +-
 drivers/gpu/drm/exynos/exynos_drm_fb.c|   10 -
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |8 
 drivers/gpu/drm/exynos/exynos_drm_fimc.c  |   16 
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  |   46 +-
 drivers/gpu/drm/exynos/exynos_drm_gem.c   |   23 ---
 drivers/gpu/drm/exynos/exynos_drm_gsc.c   |   12 +-
 drivers/gpu/drm/exynos/exynos_drm_hdmi.c  |   42 
 drivers/gpu/drm/exynos/exynos_drm_ipp.c   |   52 -
 drivers/gpu/drm/exynos/exynos_drm_plane.c |   16 
 drivers/gpu/drm/exynos/exynos_drm_rotator.c   |   12 --
 drivers/gpu/drm/exynos/exynos_drm_vidi.c  |   40 +--
 drivers/gpu/drm/exynos/exynos_hdmi.c  |   32 ---
 drivers/gpu/drm/exynos/exynos_mixer.c |   20 -
 20 files changed, 4 insertions(+), 444 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_buf.c 
b/drivers/gpu/drm/exynos/exynos_drm_buf.c
index 57affae..22865ba 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_buf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_buf.c
@@ -24,8 +24,6 @@ static int lowlevel_buffer_allocate(struct drm_device *dev,
enum dma_attr attr;
unsigned int nr_pages;

-   DRM_DEBUG_KMS("%s\n", __FILE__);
-
if (buf->dma_addr) {
DRM_DEBUG_KMS("already allocated.\n");
return 0;
@@ -119,8 +117,6 @@ err_free_attrs:
 static void lowlevel_buffer_deallocate(struct drm_device *dev,
unsigned int flags, struct exynos_drm_gem_buf *buf)
 {
-   DRM_DEBUG_KMS("%s.\n", __FILE__);
-
if (!buf->dma_addr) {
DRM_DEBUG_KMS("dma_addr is invalid.\n");
return;
@@ -151,7 +147,6 @@ struct exynos_drm_gem_buf *exynos_drm_init_buf(struct 
drm_device *dev,
 {
struct exynos_drm_gem_buf *buffer;

-   DRM_DEBUG_KMS("%s.\n", __FILE__);
DRM_DEBUG_KMS("desired size = 0x%x\n", size);

buffer = kzalloc(sizeof(*buffer), GFP_KERNEL);
@@ -167,8 +162,6 @@ struct exynos_drm_gem_buf *exynos_drm_init_buf(struct 
drm_device *dev,
 void exynos_drm_fini_buf(struct drm_device *dev,
struct exynos_drm_gem_buf *buffer)
 {
-   DRM_DEBUG_KMS("%s.\n", __FILE__);
-
if (!buffer) {
DRM_DEBUG_KMS("buffer is null.\n");
return;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c 
b/drivers/gpu/drm/exynos/exynos_drm_connector.c
index 8bcc13a..5fb3c35 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_connector.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c
@@ -34,7 +34,6 @@ convert_to_display_mode(struct drm_display_mode *mode,
struct exynos_drm_panel_info *panel)
 {
struct fb_videomode *timing = >timing;
-   DRM_DEBUG_KMS("%s\n", __FILE__);

mode->clock = timing->pixclock / 1000;
mode->vrefresh = timing->refresh;
@@ -63,8 +62,6 @@ static inline void
 convert_to_video_timing(struct fb_videomode *timing,
struct drm_display_mode *mode)
 {
-   DRM_DEBUG_KMS("%s\n", __FILE__);
-
memset(timing, 0, sizeof(*timing));

timing->pixclock = mode->clock * 1000;
@@ -99,8 +96,6 @@ static int exynos_drm_connector_get_modes(struct 
drm_connector *connector)
unsigned int count = 0;
int ret;

-   DRM_DEBUG_KMS("%s\n", __FILE__);
-
if (!display_ops) {
DRM_DEBUG_KMS("display_ops is null.\n");
return 0;
@@ -171,8 +166,6 @@ static int exynos_drm_connector_mode_valid(struct 
drm_connector *connector,
struct fb_videomode timing;
int ret = MODE_BAD;

-   DRM_DEBUG_KMS("%s\n", __FILE__);
-
convert_to_video_timing(, mode);

if (display_ops && display_ops->check_timing)
@@ -190,8 +183,6 @@ struct drm_encoder *exynos_drm_best_encoder(struct 
drm_connector *connector)
struct drm_mode_object *obj;
struct drm_encoder *encoder;

-   DRM_DEBUG_KMS("%s\n", __FILE__);
-
obj = drm_mode_object_find(dev, exynos_connector->encoder_id,
   DRM_MODE_OBJECT_ENCODER);
if (!obj) {
@@ -234,8 +225,6 @@ void exynos_drm_display_power(struct 

[PATCH 0/2] drm/exynos: clean up logs for next tree

[Seung-Woo Kim]

This patch set removes tracking logs and function name duplications.
This is for the next tree and based on exynos-drm-next branch.

YoungJun Cho (2):
  drm/exynos: Remove tracking log functions
  drm/exynos: Clean up logs for DRM_ERROR / DRM_DEBUG_KMS

 drivers/gpu/drm/exynos/exynos_drm_buf.c   |7 -
 drivers/gpu/drm/exynos/exynos_drm_connector.c |   17 --
 drivers/gpu/drm/exynos/exynos_drm_core.c  |   12 --
 drivers/gpu/drm/exynos/exynos_drm_crtc.c  |   29 
 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c|6 -
 drivers/gpu/drm/exynos/exynos_drm_drv.c   |   20 ---
 drivers/gpu/drm/exynos/exynos_drm_encoder.c   |   28 +
 drivers/gpu/drm/exynos/exynos_drm_fb.c|   10 --
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |8 -
 drivers/gpu/drm/exynos/exynos_drm_fimc.c  |  129 +++--
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  |   46 +--
 drivers/gpu/drm/exynos/exynos_drm_gem.c   |   23 ---
 drivers/gpu/drm/exynos/exynos_drm_gsc.c   |  102 +
 drivers/gpu/drm/exynos/exynos_drm_hdmi.c  |   42 -
 drivers/gpu/drm/exynos/exynos_drm_ipp.c   |  201 
 drivers/gpu/drm/exynos/exynos_drm_plane.c |   16 --
 drivers/gpu/drm/exynos/exynos_drm_rotator.c   |   53 +++-
 drivers/gpu/drm/exynos/exynos_drm_vidi.c  |   40 +-
 drivers/gpu/drm/exynos/exynos_hdmi.c  |   42 +-
 drivers/gpu/drm/exynos/exynos_mixer.c |   32 +
 20 files changed, 193 insertions(+), 670 deletions(-)

-- 
1.7.4.1

[PATCH] drm/exynos: do not use mode_set_base function directly

[Inki Dae]

This patch adds exynos_drm_crtc_mode_set_commit function
to update mode data and it makes page flip call this function
instead of calling exynos_drm_crtc_mode_set_base function directly.

exynos_drm_crtc_mode_set_base function is called by drm subsystem
as a callback so we don't have to call this function directly.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c |   10 --
 1 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index c200e4d..c64e32d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -139,7 +139,7 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct 
drm_display_mode *mode,
return 0;
 }

-static int exynos_drm_crtc_mode_set_base(struct drm_crtc *crtc, int x, int y,
+static int exynos_drm_crtc_mode_set_commit(struct drm_crtc *crtc, int x, int y,
  struct drm_framebuffer *old_fb)
 {
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
@@ -169,6 +169,12 @@ static int exynos_drm_crtc_mode_set_base(struct drm_crtc 
*crtc, int x, int y,
return 0;
 }

+static int exynos_drm_crtc_mode_set_base(struct drm_crtc *crtc, int x, int y,
+ struct drm_framebuffer *old_fb)
+{
+   return exynos_drm_crtc_mode_set_commit(crtc, x, y, old_fb);
+}
+
 static void exynos_drm_crtc_load_lut(struct drm_crtc *crtc)
 {
DRM_DEBUG_KMS("%s\n", __FILE__);
@@ -237,7 +243,7 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc,
spin_unlock_irq(>event_lock);

crtc->fb = fb;
-   ret = exynos_drm_crtc_mode_set_base(crtc, crtc->x, crtc->y,
+   ret = exynos_drm_crtc_mode_set_commit(crtc, crtc->x, crtc->y,
NULL);
if (ret) {
crtc->fb = old_fb;
-- 
1.7.5.4

[PATCH] drm/exynos: remove ignoring return value warning in hdmi

[Inki Dae]

2013/6/5 Seung-Woo Kim 

> The definition of regulator_bulk_enable is fixed with __must_check
> and this causes following build warning.
> warning: ignoring return value of 'regulator_bulk_enable',
> declared with attribute warn_unused_result
> This patch fixes to check return value of the function.
>
> Signed-off-by: Seung-Woo Kim 
> ---
>  drivers/gpu/drm/exynos/exynos_hdmi.c |4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 2f78532..f807b13 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -1699,7 +1699,9 @@ static void hdmi_poweron(struct hdmi_context *hdata)
>
> mutex_unlock(>hdmi_mutex);
>
> -   regulator_bulk_enable(res->regul_count, res->regul_bulk);
> +   if (regulator_bulk_enable(res->regul_count, res->regul_bulk))
> +   DRM_ERROR("failed to enable regulator bulk\n");
>

Now it's not error case; having no return type, so just changed it into
DRM_DEBUG_KMS. However, we need to add more exception codes to this
function later.

Applied.

Thanks,
Inki Dae


> +
> clk_enable(res->hdmiphy);
> clk_enable(res->hdmi);
> clk_enable(res->sclk_hdmi);
> --
> 1.7.4.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130605/5da93aad/attachment.html>

[PATCH v2 2/2] drm: Add kernel-doc for plane functions

[ville.syrj...@linux.intel.com]

From: Ville Syrj?l? 

v2: Follow the drm_crtc documentation fixes

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

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 857acf2..4b8953c 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -796,6 +796,21 @@ void drm_encoder_cleanup(struct drm_encoder *encoder)
 }
 EXPORT_SYMBOL(drm_encoder_cleanup);

+/**
+ * drm_plane_init - Initialise a new plane object
+ * @dev: DRM device
+ * @plane: plane object to init
+ * @possible_crtcs: bitmask of possible CRTCs
+ * @funcs: callbacks for the new plane
+ * @formats: array of supported formats (%DRM_FORMAT_*)
+ * @format_count: number of elements in @formats
+ * @priv: plane is private (hidden from userspace)?
+ *
+ * Inits a new object created as base part of a driver plane object.
+ *
+ * RETURNS:
+ * Zero on success, error code on failure.
+ */
 int drm_plane_init(struct drm_device *dev, struct drm_plane *plane,
   unsigned long possible_crtcs,
   const struct drm_plane_funcs *funcs,
@@ -844,6 +859,14 @@ int drm_plane_init(struct drm_device *dev, struct 
drm_plane *plane,
 }
 EXPORT_SYMBOL(drm_plane_init);

+/**
+ * drm_plane_cleanup - Clean up the core plane usage
+ * @plane: plane to cleanup
+ *
+ * This function cleans up @plane and removes it from the DRM mode setting
+ * core. Note that the function does *not* free the plane structure itself,
+ * this is the responsibility of the caller.
+ */
 void drm_plane_cleanup(struct drm_plane *plane)
 {
struct drm_device *dev = plane->dev;
@@ -860,6 +883,15 @@ void drm_plane_cleanup(struct drm_plane *plane)
 }
 EXPORT_SYMBOL(drm_plane_cleanup);

+/**
+ * drm_plane_force_disable - Forcibly disable a plane
+ * @plane: plane to disable
+ *
+ * Forces the plane to be disabled.
+ *
+ * Used when the plane's current framebuffer is destroyed,
+ * and when restoring fbdev mode.
+ */
 void drm_plane_force_disable(struct drm_plane *plane)
 {
int ret;
-- 
1.8.1.5

[PATCH 1/2] drm: Improve drm_crtc documentation

[ville.syrj...@linux.intel.com]

From: Ville Syrj?l? 

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

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index f00ba75..857acf2 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -585,7 +585,7 @@ EXPORT_SYMBOL(drm_framebuffer_remove);
  * @crtc: CRTC object to init
  * @funcs: callbacks for the new CRTC
  *
- * Inits a new object created as base part of an driver crtc object.
+ * Inits a new object created as base part of a driver crtc object.
  *
  * RETURNS:
  * Zero on success, error code on failure.
@@ -620,11 +620,12 @@ int drm_crtc_init(struct drm_device *dev, struct drm_crtc 
*crtc,
 EXPORT_SYMBOL(drm_crtc_init);

 /**
- * drm_crtc_cleanup - Cleans up the core crtc usage.
+ * drm_crtc_cleanup - Clean up the core crtc usage
  * @crtc: CRTC to cleanup
  *
- * Cleanup @crtc. Removes from drm modesetting space
- * does NOT free object, caller does that.
+ * This function cleans up @crtc and removes it from the DRM mode setting
+ * core. Note that the function does *not* free the crtc structure itself,
+ * this is the responsibility of the caller.
  */
 void drm_crtc_cleanup(struct drm_crtc *crtc)
 {
-- 
1.8.1.5

[PATCH] drm/mgag200: Hardware cursor support

[Christopher Harvey]

G200 cards support, at best, 16 colour palleted images for the cursor
so we do a conversion in the cursor_set function, and reject cursors
with more than 16 colours, or cursors with partial transparency. Xorg
falls back gracefully to software cursors in this case.

We can't disable/enable the cursor hardware without causing momentary
corruption around the cursor. Instead, once the cursor is on we leave
it on, and simulate turning the cursor off by moving it
offscreen. This works well.

Since we can't disable -> update -> enable the cursors, we double
buffer cursor icons, then just move the base address that points to
the old cursor, to the new. This also works well, but uses an extra
page of memory.

The cursor buffers are lazily-allocated on first cursor_set. This is
to make sure they don't take priority over any framebuffers in case of
limited memory.

Here is a representation of how the bitmap for the cursor is mapped in G200 
memory :

  Each line of color cursor use 6 Slices of 8 bytes. Slices 0 to 3
  are used for the 4bpp bitmap, slice 4 for XOR mask and slice 5 for
  AND mask. Each line has the following format:

  //  Byte 0  Byte 1  Byte 2  Byte 3  Byte 4  Byte 5  Byte 6 Byte 7
  //
  // S0:  P00-01  P02-03  P04-05  P06-07  P08-09  P10-11  P12-13 P14-15
  // S1:  P16-17  P18-19  P20-21  P22-23  P24-25  P26-27  P28-29 P30-31
  // S2:  P32-33  P34-35  P36-37  P38-39  P40-41  P42-43  P44-45 P46-47
  // S3:  P48-49  P50-51  P52-53  P54-55  P56-57  P58-59  P60-61 P62-63
  // S4:  X63-56  X55-48  X47-40  X39-32  X31-24  X23-16  X15-08 X07-00
  // S5:  A63-56  A55-48  A47-40  A39-32  A31-24  A23-16  A15-08 A07-00
  //
  //   S0 to S5  = Slices 0 to 5
  //   P00 to P63= Bitmap - pixels 0 to 63
  //   X00 to X63= always 0 - pixels 0 to 63
  //   A00 to A63= transparent markers - pixels 0 to 63
  //   1 means colour, 0 means transparent

Signed-off-by: Christopher Harvey 
Signed-off-by: Mathieu Larouche 
Acked-by: Julia Lemire 
Tested-by: Julia Lemire 
---
 drivers/gpu/drm/mgag200/Makefile |   2 +-
 drivers/gpu/drm/mgag200/mgag200_cursor.c | 275 +++
 drivers/gpu/drm/mgag200/mgag200_drv.h|  21 +++
 drivers/gpu/drm/mgag200/mgag200_main.c   |  21 ++-
 drivers/gpu/drm/mgag200/mgag200_mode.c   |   2 +
 drivers/gpu/drm/mgag200/mgag200_reg.h|   6 +-
 6 files changed, 324 insertions(+), 3 deletions(-)
 create mode 100644 drivers/gpu/drm/mgag200/mgag200_cursor.c

diff --git a/drivers/gpu/drm/mgag200/Makefile b/drivers/gpu/drm/mgag200/Makefile
index 7db592e..a9a0300 100644
--- a/drivers/gpu/drm/mgag200/Makefile
+++ b/drivers/gpu/drm/mgag200/Makefile
@@ -1,5 +1,5 @@
 ccflags-y := -Iinclude/drm
-mgag200-y   := mgag200_main.o mgag200_mode.o \
+mgag200-y   := mgag200_main.o mgag200_mode.o mgag200_cursor.o \
mgag200_drv.o mgag200_fb.o mgag200_i2c.o mgag200_ttm.o

 obj-$(CONFIG_DRM_MGAG200) += mgag200.o
diff --git a/drivers/gpu/drm/mgag200/mgag200_cursor.c 
b/drivers/gpu/drm/mgag200/mgag200_cursor.c
new file mode 100644
index 000..801731a
--- /dev/null
+++ b/drivers/gpu/drm/mgag200/mgag200_cursor.c
@@ -0,0 +1,275 @@
+/*
+ * Copyright 2013 Matrox Graphics
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License version 2. See the file COPYING in the main
+ * directory of this archive for more details.
+ *
+ * Author: Christopher Harvey 
+ */
+
+#include 
+#include "mgag200_drv.h"
+
+static bool warn_transparent = true;
+static bool warn_palette = true;
+
+/*
+  Hide the cursor off screen. We can't disable the cursor hardware because it
+  takes too long to re-activate and causes momentary corruption
+*/
+static void mga_hide_cursor(struct mga_device *mdev)
+{
+   WREG8(MGA_CURPOSXL, 0);
+   WREG8(MGA_CURPOSXH, 0);
+   mgag200_bo_unpin(mdev->cursor.pixels_1);
+   mgag200_bo_unpin(mdev->cursor.pixels_2);
+}
+
+int mga_crtc_cursor_set(struct drm_crtc *crtc,
+   struct drm_file *file_priv,
+   uint32_t handle,
+   uint32_t width,
+   uint32_t height)
+{
+   struct drm_device *dev = (struct drm_device *)file_priv->minor->dev;
+   struct mga_device *mdev = (struct mga_device *)dev->dev_private;
+   struct mgag200_bo *pixels_1 = mdev->cursor.pixels_1;
+   struct mgag200_bo *pixels_2 = mdev->cursor.pixels_2;
+   struct mgag200_bo *pixels_current = mdev->cursor.pixels_current;
+   struct mgag200_bo *pixels_prev = mdev->cursor.pixels_prev;
+   struct drm_gem_object *obj;
+   struct mgag200_bo *bo = NULL;
+   int ret = 0;
+   unsigned int i, row, col;
+   uint32_t colour_set[16];
+   uint32_t *next_space = _set[0];
+   uint32_t *palette_iter;
+   uint32_t this_colour;
+   bool found = false;
+   int colour_count = 0;
+   u64 gpu_addr;
+   u8 reg_index;
+   u8 

[RFC][PATCH 1/2] dma-buf: add importer private data to attachment

[Maarten Lankhorst]

Op 31-05-13 10:54, Seung-Woo Kim schreef:
> dma-buf attachment has only exporter private data, but importer private data
> can be useful for importer especially to re-import the same dma-buf.
> To use importer private data in attachment of the device, the function to
> search attachment in the attachment list of dma-buf is also added.
>
> Signed-off-by: Seung-Woo Kim 
> ---
>  drivers/base/dma-buf.c  |   31 +++
>  include/linux/dma-buf.h |4 
>  2 files changed, 35 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
> index 08fe897..a1eaaf2 100644
> --- a/drivers/base/dma-buf.c
> +++ b/drivers/base/dma-buf.c
> @@ -259,6 +259,37 @@ err_attach:
>  EXPORT_SYMBOL_GPL(dma_buf_attach);
>  
>  /**
> + * dma_buf_get_attachment - Get attachment with the device from dma_buf's
> + * attachments list
> + * @dmabuf:  [in]buffer to find device from.
> + * @dev: [in]device to be found.
> + *
> + * Returns struct dma_buf_attachment * attaching the device; may return
> + * negative error codes.
> + *
> + */
> +struct dma_buf_attachment *dma_buf_get_attachment(struct dma_buf *dmabuf,
> +   struct device *dev)
> +{
> + struct dma_buf_attachment *attach;
> +
> + if (WARN_ON(!dmabuf || !dev))
> + return ERR_PTR(-EINVAL);
> +
> + mutex_lock(>lock);
> + list_for_each_entry(attach, >attachments, node) {
> + if (attach->dev == dev) {
> + mutex_unlock(>lock);
> + return attach;
> + }
> + }
> + mutex_unlock(>lock);
> +
> + return ERR_PTR(-ENODEV);
> +}
> +EXPORT_SYMBOL_GPL(dma_buf_get_attachment);
NAK in any form..

Spot the race condition between dma_buf_get_attachment and dma_buf_attach

~Maarten

Multiple issues with omapdrm

[Tomi Valkeinen]

On 05/06/13 14:52, Rob Clark wrote:
> On Wed, Jun 5, 2013 at 7:35 AM, Tomi Valkeinen  
> wrote:
>> On 05/06/13 13:57, Rob Clark wrote:
>>
>>> 1) drmOpen("omap") will try to modprobe "omap", not "omapdrm" so we
>>> need to rename the .ko
>>
>> Has something been changed that broke that? Or was "omapdrm" just a
>> badly chosen name from the start? If drmOpen("omapdrm") works now,
>> doesn't changing the module name break userspace compatibility?
> 
> it was broken all along, because you need to drmOpen("omap") so the
> module should have been called omap.ko from the beginning

But it wasn't, so wouldn't changing it break userspace compatibility?

Why do you "need" drmOpen("omap")? Is it just a convention to use that
kind of name, instead of "omapdrm" style name?

>> I had a quick look at libdrm. It calls server_info->load_module() but I
>> couldn't figure out where that call actually goes...
> 
> it's registered from xserver, fyi

Ah ok. So in my testing, running without X, there's actually no module
loading happening. The test tools print something like "trying to load
module omapdrm...success." but I guess that only means that the module
is already there.

>>> 2) sorting out the modprobe of panel drivers..  although with the
>>> current structure of omapdrm+omapdss I can't think of any clean way to
>>> handle this.  I suppose we could do a hack with a bunch of
>>> request_module()s
>>
>> If omapdrm and omapdss were merged, what would be the clean way be? Or
>> did you mean some other structure?
> 
> well, then we'd just build it all into one .ko

So you didn't actually mean omapdrm+omapdss, but omapdrm + omapdss +
all-the-panel-drivers? And then have some kind of forced method to probe
the panels at omapdrm start?

That would be quite a horrible solution, in my opinion =). It would also
be even worse when we get platform independent panel drivers, as all the
drm drivers using those panel drivers would include all the panel drivers.

>> I'm no expert on this, but my understanding is that udev (or such)
>> should load the modules for the devices that the board has. If it's a
>> requirement that the drm drivers are loaded only by a call to drmOpen()
>> (why is that?), then maybe udev could load only the panel drivers.
> 
> I'm not quite sure the entire history offhand.. maybe drmOpen()
> pre-dated that?  At any rate, the main issue is just ensuring the
> panel modules (if they are split out into different .ko's) are loaded
> first

I think there should be a core display facility in the kernel to which
the panel drivers register the displays in probe().

At boot time udev would go through /sys, find the panel devices somehow
(how? modalias is probably somehow involved..), and load their
respective modules.

Later, when X is started, omapdrm and omapdss are loaded, and at that
point all the panels are already there.

 Tomi


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

[PATCH 1/3] drm/gma500: Unpin framebuffer when destroying it

[Patrik Jakobsson]

On Sun, May 26, 2013 at 11:00 PM, Daniel Vetter  wrote:
> On Sun, May 26, 2013 at 10:31 PM, Patrik Jakobsson
>  wrote:
>> On Sun, May 26, 2013 at 9:07 PM, Daniel Vetter  wrote:
>>> On Sun, May 26, 2013 at 08:03:53PM +0200, Patrik Jakobsson wrote:
 A framebuffer is pinned when it's set as pipe base, so we also need to
 unpin it when it's destroyed. Some framebuffers are never used as
 scanout (no mode set on them) so if the pin count is less than one, no
 unpinning is needed.

 Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=889511
 Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=812113

 Signed-off-by: Patrik Jakobsson 
 ---
  drivers/gpu/drm/gma500/framebuffer.c | 5 +
  1 file changed, 5 insertions(+)

 diff --git a/drivers/gpu/drm/gma500/framebuffer.c 
 b/drivers/gpu/drm/gma500/framebuffer.c
 index 8b1b6d9..1a11b69 100644
 --- a/drivers/gpu/drm/gma500/framebuffer.c
 +++ b/drivers/gpu/drm/gma500/framebuffer.c
 @@ -668,6 +668,11 @@ static void psb_user_framebuffer_destroy(struct 
 drm_framebuffer *fb)

   /* Let DRM do its clean up */
   drm_framebuffer_cleanup(fb);
 +
 + /* Unpin any psb_intel_pipe_set_base() pinning */
 + if (r->in_gart > 0)
 + psb_gtt_unpin(r);
>>>
>>> The drm core /should/ have removed the user framebuffer from all active
>>> users before it calls down into your ->destroy callback. Why can't gma500
>>> just pin/unpin on demand when the buffer is actually in use?
>>
>> Thanks for the feedback
>>
>> DRM core does correctly keep track of the users but the last ref is dropped 
>> in
>> our ->destroy callback and at that point it's still pinned from 
>> pipe_set_base().
>> So if it's considered too late to unpin the framebuffer in destroy, we never 
>> had
>> it right in the first place. Not a big surprise I guess :)
>>
>>> If a pin survives the official use as seen by the drm core (e.g. to keep a
>>> buffer around until the pageflip completes) you can simply keep an
>>> additional reference around.
>>
>> As I wrote above, that additional reference is not dropped until ->destroy
>> anyways and we don't have page flipping support and to be honest I haven't 
>> even
>> looked at implementing it yet. So the logical point to release the pin would 
>> be
>> in pipe_set_base() (or am I wrong?) by doing an unpin on the old_fb. Problem 
>> is
>> that when killing X and switching back to fbdev we get no old_fb.
>>
>> I might be missing something, so any suggestions are welcome.
>
> Dumping our irc discussion for google to index here:
>
> I sounds like gma500 code is missing the crtc disabling sequence when
> X shuts down, i.e. the crtc on->off transition. Then when you switch
> to fbcon you only get a crtc off->on state transition and so don't see
> an old fb in set_base, which means that the pin refcount of the old
> framebuffer is lost. To fix this you can use the special call to
> crtc_funcs->disable (instead of the default crtc_funcs->dpms(OFF)) in
> drm_helper_disable_unused_functions.

Adding the disable callback when we have a fb != NULL solves the problem. It
also looks like we never turn of the cursor. Is this a good place for that as
well?

> Note that X could also do the vt switch first and then only do the
> framebuffer destruction, in which case I think your patch here would
> drop the pin reference twice: Once in set_base since we have an old_fb
> and once in the framebuffer destroy callback.

I had a check for that (gtt->in_gart > 0) but still, doing it in ->disable
solved that as well.

> See  intel_crtc_disable in intel_display.c in a v3.6 kernel version
> for how drm/i915 cleanup up the fb pin reference before we've reworked
> our modeset code and switched away from the crtc helpers.

Here's what it currently looks like:

---
 drivers/gpu/drm/gma500/psb_intel_display.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/gma500/psb_intel_display.c
b/drivers/gpu/drm/gma500/psb_intel_display.c
index 6e8f42b..a16b1a8 100644
--- a/drivers/gpu/drm/gma500/psb_intel_display.c
+++ b/drivers/gpu/drm/gma500/psb_intel_display.c
@@ -1150,6 +1150,18 @@ static void psb_intel_crtc_destroy(struct drm_crtc *crtc)
kfree(psb_intel_crtc);
 }

+static void psb_intel_crtc_disable(struct drm_crtc *crtc) {
+   struct gtt_range *gt;
+   struct drm_crtc_helper_funcs *crtc_funcs = crtc->helper_private;
+
+   crtc_funcs->dpms(crtc, DRM_MODE_DPMS_OFF);
+
+   if (crtc->fb) {
+   gt = to_psb_fb(crtc->fb)->gtt;
+   psb_gtt_unpin(gt);
+   }
+}
+
 const struct drm_crtc_helper_funcs psb_intel_helper_funcs = {
.dpms = psb_intel_crtc_dpms,
.mode_fixup = psb_intel_crtc_mode_fixup,
@@ -1157,6 +1169,7 @@ const struct drm_crtc_helper_funcs
psb_intel_helper_funcs = {
.mode_set_base = psb_intel_pipe_set_base,
.prepare = psb_intel_crtc_prepare,
.commit = 

[PATCH v3] drm: Renesas R-Car Display Unit DRM driver

[Ville Syrjälä]

On Wed, Jun 05, 2013 at 03:51:53AM +0200, Laurent Pinchart wrote:
> Hi Daniel,
> 
> On Tuesday 04 June 2013 20:36:20 Daniel Vetter wrote:
> > On Tue, Jun 4, 2013 at 8:03 PM, Laurent Pinchart wrote:
> > > On Tuesday 04 June 2013 16:12:36 Daniel Vetter wrote:
> > >> On Tue, Jun 04, 2013 at 04:53:40AM +0200, Laurent Pinchart wrote:
> >
> > [snip]
> > 
> > >> Should we add that to crtc helpers, instead of the current "just try to
> > >> smash the old config on top of the ill-defined hw state after a failed
> > >> modeset"?
> > > 
> > > It would probably make sense to add a rollback operation to undo the
> > > prepare operation, or maybe just a rollback/commit flag to the commit
> > > operation. We would still need to smash the old config back though, as
> > > the rollback operation shouldn't be expected to handle encoders and
> > > connectors.
> > > 
> > > While we're at it, shouldn't we make drivers report supported formats for
> > > the main frame buffer, like we do for planes ? That would allow catching
> > > format errors before calling the prepare operation.
> > 
> > Yeah, I've noticed that one, too. I guess we could tackle that as part
> > of an eventual "make the implicit primary plane a bit more explict"
> > project. For now I'm not too offended by the duplication of checks.
> 
> It would be nice to treat the primary plane as all the other planes. Several 
> embedded display engines don't make the primary plane special and just paint 
> the background with a plain color when the enabled planes don't cover the 
> entire display.

Same deal for some intel hardware (at least partially). Anyways, my
current plan is that we fix it for the atomic pageflip/modeset stuff.
Ie. I don't even want expose the CRTC scanout stuff in the new atomic
API.

-- 
Ville Syrj?l?
Intel OTC

[PATCH] radeon: correct RADEON_GEM_WAIT_IDLE use

[Jonathan Gray]

RADEON_GEM_WAIT_IDLE is declared DRM_IOW but libdrm
uses it with drmCommandWriteRead instead of drmCommandWrite
which leads to the ioctl being unmatched and returning an
error on at least OpenBSD.

Problem noticed by and patch from Mark Kettenis.

Signed-off-by: Jonathan Gray 
---
 radeon/radeon_bo_gem.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git radeon/radeon_bo_gem.c radeon/radeon_bo_gem.c
index fca0aaf..4ea405f 100644
--- radeon/radeon_bo_gem.c
+++ radeon/radeon_bo_gem.c
@@ -211,8 +211,8 @@ static int bo_wait(struct radeon_bo_int *boi)
 memset(, 0, sizeof(args));
 args.handle = boi->handle;
 do {
-ret = drmCommandWriteRead(boi->bom->fd, DRM_RADEON_GEM_WAIT_IDLE,
-  , sizeof(args));
+ret = drmCommandWrite(boi->bom->fd, DRM_RADEON_GEM_WAIT_IDLE,
+ , sizeof(args));
 } while (ret == -EBUSY);
 return ret;
 }
-- 
1.8.2.3

[PATCH] drm: Add kernel-doc for plane functions

[Ville Syrjälä]

On Wed, Jun 05, 2013 at 04:13:01AM +0200, Laurent Pinchart wrote:
> Hi Ville,
> 
> Thank you for the patch.
> 
> On Tuesday 04 June 2013 10:58:35 ville.syrjala at linux.intel.com wrote:
> > From: Ville Syrj?l? 
> > 
> > Signed-off-by: Ville Syrj?l? 
> > ---
> >  drivers/gpu/drm/drm_crtc.c | 31 +++
> >  1 file changed, 31 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > index f00ba75..f1f11e1 100644
> > --- a/drivers/gpu/drm/drm_crtc.c
> > +++ b/drivers/gpu/drm/drm_crtc.c
> > @@ -795,6 +795,21 @@ void drm_encoder_cleanup(struct drm_encoder *encoder)
> >  }
> >  EXPORT_SYMBOL(drm_encoder_cleanup);
> > 
> > +/**
> > + * drm_plane_init - Initialise a new plane object
> > + * @dev: DRM device
> > + * @plane: plane object to init
> > + * @possible_crtcs: bitmask of possible CRTCs
> > + * @funcs: callbacks for the new plane
> > + * @formats: array of supported formats (%DRM_FORMAT_*)
> > + * @format_count: number of elements in @formats
> > + * @priv: plane is private (hidden from userspace)?
> > + *
> > + * Inits a new object created as base part of an driver plane object.
> 
> s/an driver/a driver/

You can blame the guy who wrote the drm_crtc_init() docs :)

> 
> > + *
> > + * RETURNS:
> > + * Zero on success, error code on failure.
> > + */
> >  int drm_plane_init(struct drm_device *dev, struct drm_plane *plane,
> >unsigned long possible_crtcs,
> >const struct drm_plane_funcs *funcs,
> > @@ -843,6 +858,13 @@ int drm_plane_init(struct drm_device *dev, struct
> > drm_plane *plane, }
> >  EXPORT_SYMBOL(drm_plane_init);
> > 
> > +/**
> > + * drm_plane_cleanup - Cleans up the core plane usage.
> 
> Nitpicking, you could remove the full stop at the end of the line to be 
> consistent with the other two kerneldoc blocks.
> 
> And s/Cleans/Clean/

Same deal here. I'll fix up the originals as well...

> 
> > + * @plane: plane to cleanup
> > + *
> > + * Cleanup @plane. Removes from drm modesetting space
> > + * does NOT free object, caller does that.
> 
> As this is documentation, I'd use a more verbose style.
> 
> This function clean up @plane and removes it from the DRM mode setting core. 
> Note that the function does *not* free the plane structure itself, this is 
> the 
> responsibility of the caller.

Again just copy-pasted from somewhere.

> 
> > + */
> >  void drm_plane_cleanup(struct drm_plane *plane)
> >  {
> > struct drm_device *dev = plane->dev;
> > @@ -859,6 +881,15 @@ void drm_plane_cleanup(struct drm_plane *plane)
> >  }
> >  EXPORT_SYMBOL(drm_plane_cleanup);
> > 
> > +/**
> > + * drm_plane_force_disable - Forcibly disable a plane
> > + * @plane: plane to disable
> > + *
> > + * Forces the plane to be disabled.
> 
> This feels a bit unclear to me. In particular, how is "force_disable" 
> different from just disabling the plane ? Maybe the function should be 
> renamed 
> to drm_plane_disable(), and the documentation updated to mention that the 
> function just disables the plane and disassociate with from its frame buffer.

Normal disable would happen in response to the setplane ioctl w/ NULL
fb, whereas this guy is meant more for unsolicited disable.

I'm afraid if I call it drm_plane_disable() someone will send a patch
to call it from setplane, or people start to call it from drivers'
disable_plane hook.

-- 
Ville Syrj?l?
Intel OTC

Multiple issues with omapdrm

[Tomi Valkeinen]

On 05/06/13 13:57, Rob Clark wrote:

> 1) drmOpen("omap") will try to modprobe "omap", not "omapdrm" so we
> need to rename the .ko

Has something been changed that broke that? Or was "omapdrm" just a
badly chosen name from the start? If drmOpen("omapdrm") works now,
doesn't changing the module name break userspace compatibility?

I had a quick look at libdrm. It calls server_info->load_module() but I
couldn't figure out where that call actually goes...

> 2) sorting out the modprobe of panel drivers..  although with the
> current structure of omapdrm+omapdss I can't think of any clean way to
> handle this.  I suppose we could do a hack with a bunch of
> request_module()s

If omapdrm and omapdss were merged, what would be the clean way be? Or
did you mean some other structure?

I'm no expert on this, but my understanding is that udev (or such)
should load the modules for the devices that the board has. If it's a
requirement that the drm drivers are loaded only by a call to drmOpen()
(why is that?), then maybe udev could load only the panel drivers.

 Tomi


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

[PATCH] drm/exynos: remove ignoring return value warning in hdmi

[Seung-Woo Kim]

The definition of regulator_bulk_enable is fixed with __must_check
and this causes following build warning.
warning: ignoring return value of 'regulator_bulk_enable',
declared with attribute warn_unused_result
This patch fixes to check return value of the function.

Signed-off-by: Seung-Woo Kim 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 2f78532..f807b13 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1699,7 +1699,9 @@ static void hdmi_poweron(struct hdmi_context *hdata)

mutex_unlock(>hdmi_mutex);

-   regulator_bulk_enable(res->regul_count, res->regul_bulk);
+   if (regulator_bulk_enable(res->regul_count, res->regul_bulk))
+   DRM_ERROR("failed to enable regulator bulk\n");
+
clk_enable(res->hdmiphy);
clk_enable(res->hdmi);
clk_enable(res->sclk_hdmi);
-- 
1.7.4.1

Multiple issues with omapdrm

[Tomi Valkeinen]

On 05/06/13 13:43, Rob Clark wrote:
> On Wed, Jun 5, 2013 at 4:59 AM, Tomi Valkeinen  
> wrote:
>> Hi,
>>
>> I did some testing with omapdrm on v3.10-rc1. Here are some issues I 
>> encountered.
>> For most of them I don't have any idea where to even start looking for a 
>> problem,
>> so I hope that you may have some ideas.
>>
>>
>> dispc_runtime_get/put used in irq context
>> =
>>
>> dispc_runtime_get/put are used in irq context in omap_irq.c. I can hack
>> around that with if (!in_atomic()), but I have no idea yet how to fix
>> it properly.
> 
> Probably should have a flag/refcnt that is set when in the irq hander,
> since we know that things are on in irq.

Maybe.

However, I'd like more an approach where the dispc registers are only
programmed when a display is enabled. If the display in question is
disabled, no registers would be written.

I think that would also support losing DISPC register context. The DISPC
driver currently stores all its registers when the pm_runtime refcount
goes to 0, and restores them on pm_runtime_get. That's a bit heavy, and
uses the OMAP specific ctx-loss-count support, which should be removed
(and if that's removed, the register save/restore becomes even heavier).

Things would be simpler if omapdrm (and omapfb) knows how to program all
the relevant registers when a display is enabled, and keeps the
necessary state stored in memory (including irq settings).

> somewhere in the cleanup it should do a put_paddr().  Otoh, I have
> some skepticism about whether module unloading is really going to be
> that reliable in practice, so meh..

Why is that?

 Tomi


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

[Bug 65416] r300g does not eliminate unread varyings

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

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

--- Comment #2 from Alex Deucher  ---
Couldn't this be done in a device independent manner in mesa when linking
shaders?  Drop outputs if there is no matching input in the subsequent shader
stage?

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

[Bug 65416] r300g does not eliminate unread varyings

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

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

--- Comment #1 from Stefan D?singer  ---
Fwiw, I don't know if r600g is affected. The HW has enough varyings to run the
unoptimized shaders, and the applications affected by this performance wise are
CPU limited on my r600g system.

Wine has some checks to prevent writing texture coordinates in the vertex
shader when there is no input to generate them. Unfortunately 3DMark 2000 and
Unreal Tournament 2004 use a strange vertex processing setup that breaks those
checks(D3DTSS_TEXCOORDINDEX of all texture stages is 0, thus they're reading
the first texture coordinate input, which does exist).

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

[Bug 65416] New: r300g does not eliminate unread varyings

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

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

  Priority: medium
Bug ID: 65416
  Assignee: dri-devel at lists.freedesktop.org
   Summary: r300g does not eliminate unread varyings
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: stefandoesinger at gmx.at
  Hardware: Other
Status: NEW
   Version: git
 Component: Drivers/Gallium/r300
   Product: Mesa

Created attachment 80344
  --> https://bugs.freedesktop.org/attachment.cgi?id=80344=edit
Example shaders

r300g tries to interpolate varyings written by the vertex shader even if the
fragment shader does not read them. The attached program code illustrates this
with two sample shaders.

The shaders in question were generated by Wine's fixed function pipeline
replacement, generated from a fixed function setup set up by 3DMark 2000.

The visible issues caused by this are broken fog because the driver runs out of
varyings and reduced performance due to the extra shader instructions.

An argument could be made that this is Wine's bug, and it should not generate
such inefficient shaders. Doing this would be a major inconvenience though
because the vertex and fragment shader are generated independently. As far as I
can see the proprietary drivers optimize this inefficiency away.

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

[Bug 65377] Backlight control via /sys/class/backlight/radeon_bl0 not working

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

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

--- Comment #4 from Henri Verbeet  ---
I think it depends a bit on the specific model, but many Macs will only boot
EFI from USB. Refind (http://www.rodsbooks.com/refind/index.html) is
potentially a way around that, although I'm not entirely sure if that counts as
booting in EFI mode or in BIOS mode.

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

Multiple issues with omapdrm

[Tomi Valkeinen]

8)
[  241.194610] [] (SyS_delete_module+0x0/0x288) from [] 
(ret_fast_syscall+0x0/0x48)
[  241.204345]  r7:0081 r6:006d7264 r5:70616d6f r4:0001aac4
[  241.206726] 3 locks held by rmmod/894:
[  241.214416]  #0:  (&__lockdep_no_validate__){..}, at: [] 
driver_detach+0x4c/0xc0
[  241.223693]  #1:  (&__lockdep_no_validate__){..}, at: [] 
driver_detach+0x58/0xc0
[  241.232940]  #2:  (&__lockdep_no_validate__){..}, at: [] 
driver_detach+0x4c/0xc0

 Tomi

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

[RFC][PATCH 0/2] dma-buf: add importer private data for reimporting

[김승우]

On 2013? 06? 04? 21:55, Daniel Vetter wrote:
> On Tue, Jun 04, 2013 at 07:42:22PM +0900, ??? wrote:
>>
>>
>> On 2013? 06? 01? 00:29, Daniel Vetter wrote:
>>> On Fri, May 31, 2013 at 07:22:24PM +0900, ??? wrote:
 Hello Daniel,

 Thanks for your comment.

 On 2013? 05? 31? 18:14, Daniel Vetter wrote:
> On Fri, May 31, 2013 at 10:54 AM, Seung-Woo Kim  samsung.com> wrote:
>> importer private data in dma-buf attachment can be used by importer to
>> reimport same dma-buf.
>>
>> Seung-Woo Kim (2):
>>   dma-buf: add importer private data to attachment
>>   drm/prime: find gem object from the reimported dma-buf
>
> Self-import should already work (at least with the latest refcount
> fixes merged). At least the tests to check both re-import on the same
> drm fd and on a different all work as expected now.

 Currently, prime works well for all case including self-importing,
 importing, and reimporting as you describe. Just, importing dma-buf from
 other driver twice with different drm_fd, each import create its own gem
 object even two import is done for same buffer because prime_priv is in
 struct drm_file. This means mapping to the device is done also twice.
 IMHO, these duplicated creations and maps are not necessary if drm can
 find previous import in different prime_priv.
>>>
>>> Well, that's imo a bug with the other driver. If it doesn't export
>>> something really simple (e.g. contiguous memory which doesn't require any
>>> mmio resources at all) it should have a cache of exported dma_buf fds so
>>> that it hands out the same dma_buf every time.
>>
>> Hm, all existing dma-buf exporter including i915 driver implements its
>> map_dma_buf callback as allocating scatter-gather table with pages in
>> its buffer and calling dma_map_sg() with the sgt. With different
>> drm_fds, importing one dma-buf *twice*, then importer calls
>> dma_buf_attach() and dma_buf_map_attachment() twice at least in drm
>> importer because re-importing case can only checked with prime_priv in
>> drm_file as I described.
> 
> Well, but thanks to all the self-import and re-import checks, it's
> _impossible_ to import the same dma_buf twice without noticing (presuming
> both importer and exporter are drm devices).

No, it is possible. Prime function, drm_gem_prime_fd_to_handle(), checks
re-import with following code.

ret = drm_prime_lookup_buf_handle(_priv->prime,
dma_buf, handle);

Unfortunately, file_priv is allocated per each open of drm node so this
code can only find re-import within same drm open context.

And driver specific import functions, like drm_gem_prime_import(), only
check self-import like following code.

if (dma_buf->ops == _gem_prime_dmabuf_ops) {
obj = dma_buf->priv;
if (obj->dev == dev) {
/* ... */
}
}

This means some application like following can make re-import to
different gem objects.

int drm_fd1, drm_fd2, ret;
int dma_buf_fd;
struct drm_prime_handle prime1, prime2;

drm_fd1 = open(DRM_NODE, O_RDWR, 0);
drm_fd2 = open(DRM_NODE, O_RDWR, 0);

/* get some dma-buf_fd from other dma-buf exporter */
prime1.fd = dma_buf_fd;
prime2.fd = dma_buf_fd;

ret = ioctl(drm_fd1, DRM_IOCTL_PRIME_FD_TO_HANDLE, );
ret = ioctl(drm_fd2, DRM_IOCTL_PRIME_FD_TO_HANDLE, );

This will import same dma-buf twice as different GEM object because
above checking codes can not check already imported gem object from the
dma-buf.

>>
>>>
>>> Or it needs to be more clever in it's dma_buf_attachment_map functions and
>>> lookup up a pre-existing iommu mapping.
>>>
>>> But dealing with this in the importer is just broken.
>>>
> Second, the dma_buf_attachment is _definitely_ the wrong place to do
> this. If you need iommu mapping caching, that should happen at a lower
> level (i.e. in the map_attachment callback somewhere of the exporter,
> that's what the priv field in the attachment is for). Snatching away
> the attachement from some random other import is certainly not the way
> to go - attachements are _not_ refcounted!

 Yes, attachments do not have refcount, so importer should handle and drm
 case in my patch, importer private data is gem object and it has, of
 course, refcount.

 And at current, exporter can not classify map_dma_buf requests of same
 importer to same buffer with different attachment because dma_buf_attach
 always makes new attachments. To resolve this exporter should search all
 different attachment from same importer of dma-buf and it seems more
 complex than importer private data to me.

 If I misunderstood something, please let me know.
>>>
>>> Like I've said above, just fix this in the exporter. If an importer sees
>>> two different dma_bufs it can very well presume that it those two indeed
>>> point to different backing storage.
>>
>> Yes, my patch does not break this concept. I just fixed case 

[PATCH] drm/mgag200: Don't do full cleanup if mgag200_device_init fails

[Christopher Harvey]

Running mgag200_driver_unload when the driver init fails early on
causes functions like drm_mode_config_cleanup to be called. The
problem is, drm_mode_config_cleanup crashes because the corresponding
init hasn't happend yet. There really isn't anything to cleanup after
mgag200_device_init, so we can just pass the error code upwards.

Acked-by: Julia Lemire 
Signed-off-by: Christopher Harvey 
---
 drivers/gpu/drm/mgag200/mgag200_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mgag200/mgag200_main.c 
b/drivers/gpu/drm/mgag200/mgag200_main.c
index 5189675..6d6b598 100644
--- a/drivers/gpu/drm/mgag200/mgag200_main.c
+++ b/drivers/gpu/drm/mgag200/mgag200_main.c
@@ -209,7 +209,7 @@ int mgag200_driver_load(struct drm_device *dev, unsigned 
long flags)
r = mgag200_device_init(dev, flags);
if (r) {
dev_err(>pdev->dev, "Fatal error during GPU init: %d\n", 
r);
-   goto out;
+   return r;
}
r = mgag200_mm_init(mdev);
if (r)
-- 
1.8.1.5

Multiple issues with omapdrm

[Rob Clark]

On Wed, Jun 5, 2013 at 8:16 AM, Tomi Valkeinen  wrote:
> On 05/06/13 14:52, Rob Clark wrote:
>> On Wed, Jun 5, 2013 at 7:35 AM, Tomi Valkeinen  
>> wrote:
>>> On 05/06/13 13:57, Rob Clark wrote:
>>>
 1) drmOpen("omap") will try to modprobe "omap", not "omapdrm" so we
 need to rename the .ko
>>>
>>> Has something been changed that broke that? Or was "omapdrm" just a
>>> badly chosen name from the start? If drmOpen("omapdrm") works now,
>>> doesn't changing the module name break userspace compatibility?
>>
>> it was broken all along, because you need to drmOpen("omap") so the
>> module should have been called omap.ko from the beginning
>
> But it wasn't, so wouldn't changing it break userspace compatibility?

could be udev or something else was triggering the module to load?
Not 100% sure offhand.

> Why do you "need" drmOpen("omap")? Is it just a convention to use that
> kind of name, instead of "omapdrm" style name?

all of the /dev/dri/cardN get opened, and then DRM_IOCTL_VERSION ioctl
to get the driver name/version, which is compared against the name
passed in to drmOpen().  So drmOpen("omapdrm") shouldn't really work

>>> I had a quick look at libdrm. It calls server_info->load_module() but I
>>> couldn't figure out where that call actually goes...
>>
>> it's registered from xserver, fyi
>
> Ah ok. So in my testing, running without X, there's actually no module
> loading happening. The test tools print something like "trying to load
> module omapdrm...success." but I guess that only means that the module
> is already there.

right

 2) sorting out the modprobe of panel drivers..  although with the
 current structure of omapdrm+omapdss I can't think of any clean way to
 handle this.  I suppose we could do a hack with a bunch of
 request_module()s
>>>
>>> If omapdrm and omapdss were merged, what would be the clean way be? Or
>>> did you mean some other structure?
>>
>> well, then we'd just build it all into one .ko
>
> So you didn't actually mean omapdrm+omapdss, but omapdrm + omapdss +
> all-the-panel-drivers? And then have some kind of forced method to probe
> the panels at omapdrm start?

oh, yeah.  Probably whenever I say 'omapdss' I actually mean
'everything under drivers/video/omap2 except omapfb'

> That would be quite a horrible solution, in my opinion =). It would also
> be even worse when we get platform independent panel drivers, as all the
> drm drivers using those panel drivers would include all the panel drivers.

yeah, it isn't really ideal.. really we'd want them as separate
modules but some sort of dependency to ensure that the panel drivers
actually get loaded.

>>> I'm no expert on this, but my understanding is that udev (or such)
>>> should load the modules for the devices that the board has. If it's a
>>> requirement that the drm drivers are loaded only by a call to drmOpen()
>>> (why is that?), then maybe udev could load only the panel drivers.
>>
>> I'm not quite sure the entire history offhand.. maybe drmOpen()
>> pre-dated that?  At any rate, the main issue is just ensuring the
>> panel modules (if they are split out into different .ko's) are loaded
>> first
>
> I think there should be a core display facility in the kernel to which
> the panel drivers register the displays in probe().
>
> At boot time udev would go through /sys, find the panel devices somehow
> (how? modalias is probably somehow involved..), and load their
> respective modules.
>
> Later, when X is started, omapdrm and omapdss are loaded, and at that
> point all the panels are already there.

yeah, as long as we get the panels (and encoders/bridges/etc) loaded
first, I think it should be ok..

I'm not hugely fond of having it split out of drm, since I think that
just results extra layering and glue, and it makes it harder to
iteratively evolve the infrastructure for sharing panel stuff via
different trees from drm.  But that is a different discussion and is
mostly about where the code lives.

BR,
-R

>  Tomi
>
>

[PATCH v3] drm: Renesas R-Car Display Unit DRM driver

[Daniel Vetter]

On Wed, Jun 05, 2013 at 03:51:53AM +0200, Laurent Pinchart wrote:
> Hi Daniel,
> 
> On Tuesday 04 June 2013 20:36:20 Daniel Vetter wrote:
> > On Tue, Jun 4, 2013 at 8:03 PM, Laurent Pinchart wrote:
> > > On Tuesday 04 June 2013 16:12:36 Daniel Vetter wrote:
> > >> On Tue, Jun 04, 2013 at 04:53:40AM +0200, Laurent Pinchart wrote:

[snip]

> > >> > +static int rcar_du_vga_connector_get_modes(struct drm_connector
> > >> > *connector)
> > >> > +{
> > >> > +   return drm_add_modes_noedid(connector, 1280, 768);
> > >> > +}
> > >> 
> > >> This (and the dummy detect function below) looks a bit funny, since it
> > >> essentially overrides the default behaviour already provided by the crtc
> > >> helpers. Until rcar has at least proper detect support for VGA
> > > 
> > > I would add that but the DDC signals are not connected on the boards I
> > > have access to :-/
> > > 
> > >> I'd just kill this and use the connector force support (and manually
> > >> adding the right resolutions).
> > > 
> > > Looks like that's a candidate for better documentation... How does force
> > > support work ?
> > 
> > Grep for DRM_FORCE_ON, iirc it can be set on the commandline, where you can
> > also force a specific mode. The best I could find wrt docs is the kerneldoc
> > for drm_mode_parse_command_line_for_connector. With a bit more reading it
> > looks like it's intermingled with the fbdev helper code, but should be
> > fairly easy to extract and used by your driver.
> 
> It makes sense to force the connector state from command line, but I'm not 
> sure if the same mechanism is the best solution here. As the driver has no 
> way 
> to know the connector state, the best we can do is guess what modes are 
> supported. I can just return 0 in the get_modes handler, but then the core 
> will not call drm_add_modes_noedid(), and modes will need to be added 
> manually.
> 
> Is your point that for a board on which the VGA connector state can't be 
> detected, the user should always be responsible for adding all the modes 
> supported by the VGA monitor on the command line ?

My point is that we already have both an established code for
connected outputs without EDID to add fallback modes and means to force
connectors to certain states. Your code here seems to reinvent that wheel,
so I wonder what we should/need to improve in the common code to suit your
needs. A few ideas:
- Untangling the connector forcing code from the fbdev helper so that you
  can use it.
- Exposing the connector state forcing through sysfs so that it's
  runtime-adjustable.
- Adding fallback modes for connectors in the unknonw state (imo too much
  risk in breaking something else).

Thinking about this some more I'd vote for the new sysfs file to expose
connector forcing at runtime. With that it'd boil down to 1024x756 vs.
1280x768 for the default fallback mode. And that could be fixed with the
EDID quirk support. Although that looks like it would benefit from a
per-connector sysfs file, too ;-)

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

[Bug 64257] RS880 issues with r600-llvm-compiler

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

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

--- Comment #34 from Mike Lothian  ---
Out of interest has the previous two patches been applied upstream?

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

[Bug 64257] RS880 issues with r600-llvm-compiler

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

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

--- Comment #33 from Marc Dietrich  ---
looks like my chrome version (27) has a bug with coordinates, so ignore this
browser. still firefox doesn't render anything at all.

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

[PATCH v2 5/5] drm: GEM CMA: Add DRM PRIME support

[Daniel Vetter]

On Tue, Jun 04, 2013 at 11:05:36PM -0400, Rob Clark wrote:
> On Tue, Jun 4, 2013 at 9:22 PM, Laurent Pinchart
>  wrote:
> > Hi Rob,
> >
> > On Tuesday 04 June 2013 17:56:36 Rob Clark wrote:
> >> couple small comments, other than those it looks ok
> >
> > Thanks for the review.
> >
> >> On Mon, Jun 3, 2013 at 10:20 PM, Laurent Pinchart wrote:
> >> > Signed-off-by: Laurent Pinchart
> >> > 
> >> > ---
> >> >
> >> >  drivers/gpu/drm/drm_gem_cma_helper.c | 321 
> >> > +-
> >> >  include/drm/drm_gem_cma_helper.h |   9 +
> >> >  2 files changed, 327 insertions(+), 3 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
> >> > b/drivers/gpu/drm/drm_gem_cma_helper.c index 7a4db4e..1dc2157 100644
> >> > --- a/drivers/gpu/drm/drm_gem_cma_helper.c
> >> > +++ b/drivers/gpu/drm/drm_gem_cma_helper.c
> >> > @@ -21,6 +21,9 @@
> >> >  #include 
> >> >  #include 
> >> >  #include 
> >> > +#if CONFIG_DMA_SHARED_BUFFER
> >> > +#include 
> >> > +#endif
> >>
> >> I don't think we need the #if, since drm selects DMA_SHARED_BUFFER
> >>
> >> and same for other spot below
> >
> > Indeed. Will be fixed in the next version.
> >
> >> >  #include 
> >> >
> >> >  #include 
> >
> > [snip]
> >
> >> > @@ -291,3 +321,288 @@ void drm_gem_cma_describe(struct drm_gem_cma_object
> >> > *cma_obj, struct seq_file *m>
> >> >  }
> >> >  EXPORT_SYMBOL_GPL(drm_gem_cma_describe);
> >> >  #endif
> >> >
> >> > +
> >> > +/*
> >> > -
> >> >  + * DMA-BUF
> >> > + */
> >> > +
> >> > +#if CONFIG_DMA_SHARED_BUFFER
> >> > +struct drm_gem_cma_dmabuf_attachment {
> >> > +   struct sg_table sgt;
> >> > +   enum dma_data_direction dir;
> >> > +};
> >> > +
> >> > +static int drm_gem_cma_dmabuf_attach(struct dma_buf *dmabuf, struct
> >> > device *dev, +struct
> >> > dma_buf_attachment *attach) +{
> >> > +   struct drm_gem_cma_dmabuf_attachment *cma_attach;
> >> > +
> >> > +   cma_attach = kzalloc(sizeof(*cma_attach), GFP_KERNEL);
> >> > +   if (!cma_attach)
> >> > +   return -ENOMEM;
> >> > +
> >> > +   cma_attach->dir = DMA_NONE;
> >> > +   attach->priv = cma_attach;
> >> > +
> >> > +   return 0;
> >> > +}
> >> > +
> >> > +static void drm_gem_cma_dmabuf_detach(struct dma_buf *dmabuf,
> >> > + struct dma_buf_attachment *attach)
> >> > +{
> >> > +   struct drm_gem_cma_dmabuf_attachment *cma_attach = attach->priv;
> >> > +   struct sg_table *sgt;
> >> > +
> >> > +   if (cma_attach == NULL)
> >> > +   return;
> >> > +
> >> > +   sgt = _attach->sgt;
> >> > +
> >> > +   if (cma_attach->dir != DMA_NONE)
> >> > +   dma_unmap_sg(attach->dev, sgt->sgl, sgt->nents,
> >> > +   cma_attach->dir);
> >> > +
> >> > +   sg_free_table(sgt);
> >> > +   kfree(cma_attach);
> >> > +   attach->priv = NULL;
> >> > +}
> >> > +
> >> > +static struct sg_table *
> >> > +drm_gem_cma_dmabuf_map(struct dma_buf_attachment *attach,
> >> > +  enum dma_data_direction dir)
> >> > +{
> >> > +   struct drm_gem_cma_dmabuf_attachment *cma_attach = attach->priv;
> >> > +   struct drm_gem_cma_object *cma_obj = attach->dmabuf->priv;
> >> > +   struct drm_device *drm = cma_obj->base.dev;
> >> > +   struct scatterlist *rd, *wr;
> >> > +   struct sg_table *sgt;
> >> > +   unsigned int i;
> >> > +   int nents, ret;
> >> > +
> >> > +   DRM_DEBUG_PRIME("\n");
> >> > +
> >> > +   if (WARN_ON(dir == DMA_NONE))
> >> > +   return ERR_PTR(-EINVAL);
> >> > +
> >> > +   /* Return the cached mapping when possible. */
> >> > +   if (cma_attach->dir == dir)
> >> > +   return _attach->sgt;
> >> > +
> >> > +   /* Two mappings with different directions for the same attachment
> >> > are +* not allowed.
> >> > +*/
> >> > +   if (WARN_ON(cma_attach->dir != DMA_NONE))
> >> > +   return ERR_PTR(-EBUSY);
> >> > +
> >> > +   sgt = _attach->sgt;
> >> > +
> >> > +   ret = sg_alloc_table(sgt, cma_obj->sgt->orig_nents, GFP_KERNEL);
> >> > +   if (ret) {
> >> > +   DRM_ERROR("failed to alloc sgt.\n");
> >> > +   return ERR_PTR(-ENOMEM);
> >> > +   }
> >> > +
> >> > +   mutex_lock(>struct_mutex);
> >> > +
> >> > +   rd = cma_obj->sgt->sgl;
> >> > +   wr = sgt->sgl;
> >> > +   for (i = 0; i < sgt->orig_nents; ++i) {
> >> > +   sg_set_page(wr, sg_page(rd), rd->length, rd->offset);
> >> > +   rd = sg_next(rd);
> >> > +   wr = sg_next(wr);
> >> > +   }
> >> > +
> >> > +   nents = dma_map_sg(attach->dev, sgt->sgl, sgt->orig_nents, dir);
> >> > +   if (!nents) {
> >> > +   DRM_ERROR("failed to map sgl with iommu.\n");
> >> > +  

[Bug 64257] RS880 issues with r600-llvm-compiler

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

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

--- Comment #32 from Andy Furniss  ---
(In reply to comment #30)
> Can you try this branch:
> http://cgit.freedesktop.org/~tstellar/llvm/log/?h=r600-gen-fixes
> 
> I think it should fix the remaining issues.

Doesn't fix heaven or pearl boy on my rv790, though in the case of pearl boy
corruption didn't start until I dived.

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

[RFC][PATCH 0/2] dma-buf: add importer private data for reimporting

[Daniel Vetter]

On Wed, Jun 05, 2013 at 11:52:59AM +0900, ??? wrote:
> 
> 
> On 2013? 06? 04? 21:55, Daniel Vetter wrote:
> > On Tue, Jun 04, 2013 at 07:42:22PM +0900, ??? wrote:
> >>
> >>
> >> On 2013? 06? 01? 00:29, Daniel Vetter wrote:
> >>> On Fri, May 31, 2013 at 07:22:24PM +0900, ??? wrote:
>  Hello Daniel,
> 
>  Thanks for your comment.
> 
>  On 2013? 05? 31? 18:14, Daniel Vetter wrote:
> > On Fri, May 31, 2013 at 10:54 AM, Seung-Woo Kim  > samsung.com> wrote:
> >> importer private data in dma-buf attachment can be used by importer to
> >> reimport same dma-buf.
> >>
> >> Seung-Woo Kim (2):
> >>   dma-buf: add importer private data to attachment
> >>   drm/prime: find gem object from the reimported dma-buf
> >
> > Self-import should already work (at least with the latest refcount
> > fixes merged). At least the tests to check both re-import on the same
> > drm fd and on a different all work as expected now.
> 
>  Currently, prime works well for all case including self-importing,
>  importing, and reimporting as you describe. Just, importing dma-buf from
>  other driver twice with different drm_fd, each import create its own gem
>  object even two import is done for same buffer because prime_priv is in
>  struct drm_file. This means mapping to the device is done also twice.
>  IMHO, these duplicated creations and maps are not necessary if drm can
>  find previous import in different prime_priv.
> >>>
> >>> Well, that's imo a bug with the other driver. If it doesn't export
> >>> something really simple (e.g. contiguous memory which doesn't require any
> >>> mmio resources at all) it should have a cache of exported dma_buf fds so
> >>> that it hands out the same dma_buf every time.
> >>
> >> Hm, all existing dma-buf exporter including i915 driver implements its
> >> map_dma_buf callback as allocating scatter-gather table with pages in
> >> its buffer and calling dma_map_sg() with the sgt. With different
> >> drm_fds, importing one dma-buf *twice*, then importer calls
> >> dma_buf_attach() and dma_buf_map_attachment() twice at least in drm
> >> importer because re-importing case can only checked with prime_priv in
> >> drm_file as I described.
> > 
> > Well, but thanks to all the self-import and re-import checks, it's
> > _impossible_ to import the same dma_buf twice without noticing (presuming
> > both importer and exporter are drm devices).
> 
> No, it is possible. Prime function, drm_gem_prime_fd_to_handle(), checks
> re-import with following code.
> 
> ret = drm_prime_lookup_buf_handle(_priv->prime,
>   dma_buf, handle);
> 
> Unfortunately, file_priv is allocated per each open of drm node so this
> code can only find re-import within same drm open context.
> 
> And driver specific import functions, like drm_gem_prime_import(), only
> check self-import like following code.
> 
> if (dma_buf->ops == _gem_prime_dmabuf_ops) {
>   obj = dma_buf->priv;
>   if (obj->dev == dev) {
>   /* ... */
>   }
> }
> 
> This means some application like following can make re-import to
> different gem objects.
> 
> int drm_fd1, drm_fd2, ret;
> int dma_buf_fd;
> struct drm_prime_handle prime1, prime2;
> 
> drm_fd1 = open(DRM_NODE, O_RDWR, 0);
> drm_fd2 = open(DRM_NODE, O_RDWR, 0);
> 
> /* get some dma-buf_fd from other dma-buf exporter */
> prime1.fd = dma_buf_fd;
> prime2.fd = dma_buf_fd;
> 
> ret = ioctl(drm_fd1, DRM_IOCTL_PRIME_FD_TO_HANDLE, );
> ret = ioctl(drm_fd2, DRM_IOCTL_PRIME_FD_TO_HANDLE, );
> 
> This will import same dma-buf twice as different GEM object because
> above checking codes can not check already imported gem object from the
> dma-buf.

Oh right, now I understand. Somehow I've always thought we already take
care of this case, since I remember discussing it.

To fix that we need a device-global import cache similar to how we already
have one for each file_priv. I think we can reuse the same locking and
refcounting scheme, but I haven't checked. The commit messages of the past
few prime changes have fairly good explanations of the tricky stuff going
on there.

Sorry for being dense for so long, I should have checked my idea of what
the drm prime code does with reality sooner ;-)

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

[Bug 64257] RS880 issues with r600-llvm-compiler

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

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

--- Comment #31 from Marc Dietrich  ---
still the same. 

chrome still shows the triangles instead of the boy in the boat (even worse
than before) and firefox does not render the boy at all.

http://www.chromeexperiments.com/detail/pearl-boy/?f=webgl

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

[PATCH v3] drm: Renesas R-Car Display Unit DRM driver

[Alex Deucher]

On Tue, Jun 4, 2013 at 9:51 PM, Laurent Pinchart
 wrote:
> Hi Daniel,
>
> On Tuesday 04 June 2013 20:36:20 Daniel Vetter wrote:
>> On Tue, Jun 4, 2013 at 8:03 PM, Laurent Pinchart wrote:
>> > On Tuesday 04 June 2013 16:12:36 Daniel Vetter wrote:
>> >> On Tue, Jun 04, 2013 at 04:53:40AM +0200, Laurent Pinchart wrote:
>>
>> [snip]
>>
>> >> Should we add that to crtc helpers, instead of the current "just try to
>> >> smash the old config on top of the ill-defined hw state after a failed
>> >> modeset"?
>> >
>> > It would probably make sense to add a rollback operation to undo the
>> > prepare operation, or maybe just a rollback/commit flag to the commit
>> > operation. We would still need to smash the old config back though, as
>> > the rollback operation shouldn't be expected to handle encoders and
>> > connectors.
>> >
>> > While we're at it, shouldn't we make drivers report supported formats for
>> > the main frame buffer, like we do for planes ? That would allow catching
>> > format errors before calling the prepare operation.
>>
>> Yeah, I've noticed that one, too. I guess we could tackle that as part
>> of an eventual "make the implicit primary plane a bit more explict"
>> project. For now I'm not too offended by the duplication of checks.
>
> It would be nice to treat the primary plane as all the other planes. Several
> embedded display engines don't make the primary plane special and just paint
> the background with a plain color when the enabled planes don't cover the
> entire display.
>
>> >> This should use the drm_send_vblank_event helper.
>> >
>> > What bothers me about drm_send_vblank_event() is that it calls
>> > drm_vblank_count_and_time() with the events lock unnecessarily held. I can
>> > live with that for now, I'll fix the driver to use the helper.
>>
>> Most other drivers protect a bit of other state with that lock, so
>> makes sense to hold it outside already. So not sure whether we should
>> optimize this much ...
>
> Probably not :-)
>
>> >> > +   drm_vblank_put(dev, rcrtc->index);
>> >> > +}
>> >
>> > [snip]
>> >
>> >> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
>> >> > b/drivers/gpu/drm/rcar-du/rcar_du_drv.c new file mode 100644
>> >> > index 000..003b34e
>> >> > --- /dev/null
>> >> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
>> >
>> > [snip]
>> >
>> >> > +static void rcar_du_disable_vblank(struct drm_device *dev, int crtc)
>> >> > +{
>> >> > +   struct rcar_du_device *rcdu = dev->dev_private;
>> >> > +
>> >> > +   rcar_du_crtc_enable_vblank(>crtcs[crtc], false);
>> >> > +}
>> >>
>> >> Blergh, I hate our legacy vblank code which forces kms driver to jump
>> >> through int pipe -> struct drm_crtc * hoops.
>> >
>> > How would you like to fix it ? :-)
>>
>> Haven't looked at the details, but the first step I have in mind is to
>> switch all drm core -> driver and driver -> vblank helper interfaces from
>> int pipe to struct drm_crtc * pointers for kms drivers. That would allow us
>> to implement at least sane locking for the vblank wait ioctl (by grabbing
>> the crtc mutex).
>>
>> My plan was to split things by copy new kms functions and then
>> garbage-collecting all unnused features for the ums code (iirc no ums driver
>> ever supported more than 2 crtcs, vblank events or high-precision
>> timestamps).
>>
>> Once that's in place we can look into more stuff. One of the things I want
>> to play with is support for hw timestamp and vblank counters (also for
>> pageflips). Then we don't have to enable the vblank interrupt so often and
>> more important should be able to turn it of right away without loosing
>> precision due to the potential vblank irq vs. vblank irq off race.
>>
>> >> where i counts encoders to say that you can clone itself (userspace might
>> >> get confused, haven't checked how throughout the modeset ddx is). But it
>> >> sounds like rcar can clone encoders pretty freely (as long as they're
>> >> using crtc 0), so maybe you want to use something like drm/i915 does?
>> >
>> > The device has two outputs, 0 and 1. Output 0 can be driven by CRTC 0
>> > only, and output 1 can be driven by CRTC 0 or CRTC 1.
>>
>> Ah, that explains it, I've missed the context that we only have 2
>> crtc/encoder pairs ;-)
>
> It wasn't particularly explicit :-)
>
>> >> We smash all cloneable encoders into one groub with a
>> >> intel_encoder->cloneable flag and then allow cloning any cloneable
>> >> encoder to any other cloneable encoder with intel_encoder_clones in
>> >> intel_display.c
>> >>
>> >> possible_clones is a bit a ill-defined part of the kms api, but I think
>> >> we still should strive for consistency. Maybe the modesetting ddx should
>> >> also grow a warning if the possible_clones mask doesn't make too much
>> >> sense.
>> >
>> > I haven't been able to find an authoritative source of documentation
>> > regarding whether the possible_clones field should include the encoder
>> > itself. That should definitely be documented, I can fix the driver
>> > accordingly.
>>

[PATCH] nouveau: Load firmware for BSP/VP engines on NV84-NV96, NVA0

[Maarten Lankhorst]

Hey,

Op 04-06-13 20:38, Ilia Mirkin schreef:
> On Mon, Jun 3, 2013 at 5:02 AM, Ilia Mirkin  wrote:
>> These chipsets include the VP2 engine which is composed of a bitstream
>> processor (BSP) that decodes H.264 and a video processor (VP) which can
>> do iDCT/mo-comp/etc for MPEG1/2, H.264, and VC-1. Both of these are
>> driven by separate xtensa chips embedded in the hardware. This patch
>> provides the mechanism to load the kernel for the xtensa chips and
>> provide the necessary interactions to do the rest of the work.
>>
>> Signed-off-by: Ilia Mirkin 
>> ---
>>
>> This patch applies on top of nouveau/master (16a41bcc8).
>>
>> This seems to work for me. There was one boot where my userspace
>> component didn't work right, but it could just as well be a bug
>> there. Subsequent attempts seem to work fine. Note that I'm not
>> particularly familiar with any of this stuff, so if something looks
>> odd, I probably didn't know any better. I did try to faithfully
>> reproduce whatever the blob did. A few questions/thoughts:
>>
>> 1. There's a LOT of similarity between BSP and VP setup/etc. Is it
>>worth it to create a core/xtensa.c or some such, similar to
>>falcon.c? Since it's only in two places, not that much code, and
>>there _are_ differences, I decided to keep them separate.
>>
>> 2. Firmware naming. Maarten suggested to use the falcon naming style,
>>which is nv$chipset_fuc$offset. However here, all the chips share
>>the same firmware. Also the offset would be 103 vs 00f, and is a
>>little arbitrary. (And fuc doesn't apply here... xt? xtensa?) I've
>>left it the way I had it: nv84_bsp and nv84_vp.
>>
>> 3. Firmware load time. I chose to load the fw into memory in the ctor,
>>and then copy it in in init, due to some potentially bogus
>>suspend/resume concerns. Also e.g. mplayer likes to create/destroy
>>decoders at startup a few times. The downside is that ~200KB of
>>memory is gone. Let me know if I should change it to do the
>>request_firmware in init.
>>
>> There's obviously a userspace piece to this, which I'm still working
>> on. But right now I have it working within certain parameters
>> (e.g. 1280x544 videos), and I'm relatively confident it can be
>> completed without further kernel-side changes.
>>
>> There's also a hypothetical concern of "what if we create an open
>> firmware with a different user API". Ideally there'd be some way to
>> expose what kind of firmware is loaded, but I think that can be left
>> for "later".
> I also happened to notice that NV98, NVA1+ refer to these nv84 engines
> (in drivers/gpu/drm/nouveau/core/engine/device/nv50.c). I assume that
> means I should create a new nv98.c version of BSP/VP that resembles
> the old versions of nv84.c, and point device/nv50.c at those for nv98
> and nva1+?
nv98+ should really have an implementation more like nvc0, and the copy engine
is a good example on what conversion is needed to do it. :-)

If you fix that up, I'll stop being lazy and fix VP4 for nva3/a5/a8 in mesa. ;)

~Maarten

[PATCH 1/2] drm: Improve drm_crtc documentation

[Alex Deucher]

On Wed, Jun 5, 2013 at 8:39 AM,   wrote:
> From: Ville Syrj?l? 
>
> Signed-off-by: Ville Syrj?l? 

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/drm_crtc.c | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index f00ba75..857acf2 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -585,7 +585,7 @@ EXPORT_SYMBOL(drm_framebuffer_remove);
>   * @crtc: CRTC object to init
>   * @funcs: callbacks for the new CRTC
>   *
> - * Inits a new object created as base part of an driver crtc object.
> + * Inits a new object created as base part of a driver crtc object.
>   *
>   * RETURNS:
>   * Zero on success, error code on failure.
> @@ -620,11 +620,12 @@ int drm_crtc_init(struct drm_device *dev, struct 
> drm_crtc *crtc,
>  EXPORT_SYMBOL(drm_crtc_init);
>
>  /**
> - * drm_crtc_cleanup - Cleans up the core crtc usage.
> + * drm_crtc_cleanup - Clean up the core crtc usage
>   * @crtc: CRTC to cleanup
>   *
> - * Cleanup @crtc. Removes from drm modesetting space
> - * does NOT free object, caller does that.
> + * This function cleans up @crtc and removes it from the DRM mode setting
> + * core. Note that the function does *not* free the crtc structure itself,
> + * this is the responsibility of the caller.
>   */
>  void drm_crtc_cleanup(struct drm_crtc *crtc)
>  {
> --
> 1.8.1.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

Multiple issues with omapdrm

[Rob Clark]

On Wed, Jun 5, 2013 at 7:35 AM, Tomi Valkeinen  wrote:
> On 05/06/13 13:57, Rob Clark wrote:
>
>> 1) drmOpen("omap") will try to modprobe "omap", not "omapdrm" so we
>> need to rename the .ko
>
> Has something been changed that broke that? Or was "omapdrm" just a
> badly chosen name from the start? If drmOpen("omapdrm") works now,
> doesn't changing the module name break userspace compatibility?

it was broken all along, because you need to drmOpen("omap") so the
module should have been called omap.ko from the beginning

> I had a quick look at libdrm. It calls server_info->load_module() but I
> couldn't figure out where that call actually goes...

it's registered from xserver, fyi

>> 2) sorting out the modprobe of panel drivers..  although with the
>> current structure of omapdrm+omapdss I can't think of any clean way to
>> handle this.  I suppose we could do a hack with a bunch of
>> request_module()s
>
> If omapdrm and omapdss were merged, what would be the clean way be? Or
> did you mean some other structure?

well, then we'd just build it all into one .ko

> I'm no expert on this, but my understanding is that udev (or such)
> should load the modules for the devices that the board has. If it's a
> requirement that the drm drivers are loaded only by a call to drmOpen()
> (why is that?), then maybe udev could load only the panel drivers.

I'm not quite sure the entire history offhand.. maybe drmOpen()
pre-dated that?  At any rate, the main issue is just ensuring the
panel modules (if they are split out into different .ko's) are loaded
first

BR,
-R

>  Tomi
>
>

[Bug 60929] [r600-llvm] mono games with opengl are blocking on start

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

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

--- Comment #4 from Laurent carlier  ---
Yes, it's still an issue, i have to disable R600_LLVM to play mono games

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

[PATCH v2 5/5] drm: GEM CMA: Add DRM PRIME support

[Rob Clark]

On Wed, Jun 5, 2013 at 4:44 AM, Daniel Vetter  wrote:
> On Tue, Jun 04, 2013 at 11:05:36PM -0400, Rob Clark wrote:
>> On Tue, Jun 4, 2013 at 9:22 PM, Laurent Pinchart
>>  wrote:
>> > Hi Rob,
>> >
>> > On Tuesday 04 June 2013 17:56:36 Rob Clark wrote:
>> >> couple small comments, other than those it looks ok
>> >
>> > Thanks for the review.
>> >
>> >> On Mon, Jun 3, 2013 at 10:20 PM, Laurent Pinchart wrote:
>> >> > Signed-off-by: Laurent Pinchart
>> >> > 
>> >> > ---
>> >> >
>> >> >  drivers/gpu/drm/drm_gem_cma_helper.c | 321 
>> >> > +-
>> >> >  include/drm/drm_gem_cma_helper.h |   9 +
>> >> >  2 files changed, 327 insertions(+), 3 deletions(-)
>> >> >
>> >> > diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
>> >> > b/drivers/gpu/drm/drm_gem_cma_helper.c index 7a4db4e..1dc2157 100644
>> >> > --- a/drivers/gpu/drm/drm_gem_cma_helper.c
>> >> > +++ b/drivers/gpu/drm/drm_gem_cma_helper.c
>> >> > @@ -21,6 +21,9 @@
>> >> >  #include 
>> >> >  #include 
>> >> >  #include 
>> >> > +#if CONFIG_DMA_SHARED_BUFFER
>> >> > +#include 
>> >> > +#endif
>> >>
>> >> I don't think we need the #if, since drm selects DMA_SHARED_BUFFER
>> >>
>> >> and same for other spot below
>> >
>> > Indeed. Will be fixed in the next version.
>> >
>> >> >  #include 
>> >> >
>> >> >  #include 
>> >
>> > [snip]
>> >
>> >> > @@ -291,3 +321,288 @@ void drm_gem_cma_describe(struct 
>> >> > drm_gem_cma_object
>> >> > *cma_obj, struct seq_file *m>
>> >> >  }
>> >> >  EXPORT_SYMBOL_GPL(drm_gem_cma_describe);
>> >> >  #endif
>> >> >
>> >> > +
>> >> > +/*
>> >> > -
>> >> >  + * DMA-BUF
>> >> > + */
>> >> > +
>> >> > +#if CONFIG_DMA_SHARED_BUFFER
>> >> > +struct drm_gem_cma_dmabuf_attachment {
>> >> > +   struct sg_table sgt;
>> >> > +   enum dma_data_direction dir;
>> >> > +};
>> >> > +
>> >> > +static int drm_gem_cma_dmabuf_attach(struct dma_buf *dmabuf, struct
>> >> > device *dev, +struct
>> >> > dma_buf_attachment *attach) +{
>> >> > +   struct drm_gem_cma_dmabuf_attachment *cma_attach;
>> >> > +
>> >> > +   cma_attach = kzalloc(sizeof(*cma_attach), GFP_KERNEL);
>> >> > +   if (!cma_attach)
>> >> > +   return -ENOMEM;
>> >> > +
>> >> > +   cma_attach->dir = DMA_NONE;
>> >> > +   attach->priv = cma_attach;
>> >> > +
>> >> > +   return 0;
>> >> > +}
>> >> > +
>> >> > +static void drm_gem_cma_dmabuf_detach(struct dma_buf *dmabuf,
>> >> > + struct dma_buf_attachment *attach)
>> >> > +{
>> >> > +   struct drm_gem_cma_dmabuf_attachment *cma_attach = attach->priv;
>> >> > +   struct sg_table *sgt;
>> >> > +
>> >> > +   if (cma_attach == NULL)
>> >> > +   return;
>> >> > +
>> >> > +   sgt = _attach->sgt;
>> >> > +
>> >> > +   if (cma_attach->dir != DMA_NONE)
>> >> > +   dma_unmap_sg(attach->dev, sgt->sgl, sgt->nents,
>> >> > +   cma_attach->dir);
>> >> > +
>> >> > +   sg_free_table(sgt);
>> >> > +   kfree(cma_attach);
>> >> > +   attach->priv = NULL;
>> >> > +}
>> >> > +
>> >> > +static struct sg_table *
>> >> > +drm_gem_cma_dmabuf_map(struct dma_buf_attachment *attach,
>> >> > +  enum dma_data_direction dir)
>> >> > +{
>> >> > +   struct drm_gem_cma_dmabuf_attachment *cma_attach = attach->priv;
>> >> > +   struct drm_gem_cma_object *cma_obj = attach->dmabuf->priv;
>> >> > +   struct drm_device *drm = cma_obj->base.dev;
>> >> > +   struct scatterlist *rd, *wr;
>> >> > +   struct sg_table *sgt;
>> >> > +   unsigned int i;
>> >> > +   int nents, ret;
>> >> > +
>> >> > +   DRM_DEBUG_PRIME("\n");
>> >> > +
>> >> > +   if (WARN_ON(dir == DMA_NONE))
>> >> > +   return ERR_PTR(-EINVAL);
>> >> > +
>> >> > +   /* Return the cached mapping when possible. */
>> >> > +   if (cma_attach->dir == dir)
>> >> > +   return _attach->sgt;
>> >> > +
>> >> > +   /* Two mappings with different directions for the same 
>> >> > attachment
>> >> > are +* not allowed.
>> >> > +*/
>> >> > +   if (WARN_ON(cma_attach->dir != DMA_NONE))
>> >> > +   return ERR_PTR(-EBUSY);
>> >> > +
>> >> > +   sgt = _attach->sgt;
>> >> > +
>> >> > +   ret = sg_alloc_table(sgt, cma_obj->sgt->orig_nents, GFP_KERNEL);
>> >> > +   if (ret) {
>> >> > +   DRM_ERROR("failed to alloc sgt.\n");
>> >> > +   return ERR_PTR(-ENOMEM);
>> >> > +   }
>> >> > +
>> >> > +   mutex_lock(>struct_mutex);
>> >> > +
>> >> > +   rd = cma_obj->sgt->sgl;
>> >> > +   wr = sgt->sgl;
>> >> > +   for (i = 0; i < sgt->orig_nents; ++i) {
>> >> > +   sg_set_page(wr, sg_page(rd), rd->length, rd->offset);
>> >> > +   rd = sg_next(rd);
>> >> > +   wr = sg_next(wr);
>> >> > +

Multiple issues with omapdrm

[Rob Clark]

On Wed, Jun 5, 2013 at 6:43 AM, Rob Clark  wrote:
> On Wed, Jun 5, 2013 at 4:59 AM, Tomi Valkeinen  
> wrote:
>> Hi,
>>
>> I did some testing with omapdrm on v3.10-rc1. Here are some issues I 
>> encountered.
>> For most of them I don't have any idea where to even start looking for a 
>> problem,
>> so I hope that you may have some ideas.
>>
>>
>> dispc_runtime_get/put used in irq context
>> =
>>
>> dispc_runtime_get/put are used in irq context in omap_irq.c. I can hack
>> around that with if (!in_atomic()), but I have no idea yet how to fix
>> it properly.
>
> Probably should have a flag/refcnt that is set when in the irq hander,
> since we know that things are on in irq.
>
>>
>> drm_crtc warning
>> 
>>
>> I got this once when unloading the modules, but haven't happened since:
>>
>> drm_crtc.c line 3869
>>
>> WARN_ON(!list_empty(>mode_config.fb_list));
>>
>> As it only happened once, maybe some kind of race.
>>
>
> Hmm, this is new..  it is certain that there can be a fb with a
> reference still around, waiting for a vblank/framedone.  But I think
> it should already be removed from userspace perspective and no longer
> on fb_list.  I think I need to go back and have a closer look at
> 2b677e8c0 where Daniel introduced that WARN_ON().
>
>> omap_gem warning
>> 
>>
>> This happens on module unload:
>
> oh, that is easy.. it is because the omap_fbdev.c does an unbalanced
> omap_gem_get_paddr() to keep the fbcon fb from getting unmapped from
> tiler (so if we have to restore fbcon mode in an opps, we don't have
> to worry about grabbing mutexes or anything like that).  Maybe
> somewhere in the cleanup it should do a put_paddr().  Otoh, I have
> some skepticism about whether module unloading is really going to be
> that reliable in practice, so meh..
>

by which I mean: module unloading is a nice-to-have for development,
but not a real use case.. it is more important to fix the issues we
have with module loading:

1) drmOpen("omap") will try to modprobe "omap", not "omapdrm" so we
need to rename the .ko
2) sorting out the modprobe of panel drivers..  although with the
current structure of omapdrm+omapdss I can't think of any clean way to
handle this.  I suppose we could do a hack with a bunch of
request_module()s

these are issues that actually cause problems for distros which want
to build a unified kernel with all the drm drivers as modules

BR,
-R

>
> BR,
> -R
>
>>
>> [   30.167480] [ cut here ]
>> [   30.167724] WARNING: at drivers/gpu/drm/omapdrm/omap_gem.c:1318 
>> omap_gem_free_object+0x24c/0x25c [omapdrm]()
>> [   30.182952] Modules linked in: omapdrm(-) drm_kms_helper drm panel_taal 
>> panel_tfp410 panel_generic_dpi omapdss
>> [   30.183166] CPU: 0 PID: 6 Comm: kworker/u4:0 Not tainted 
>> 3.10.0-rc1-4-g8ed4760 #110
>> [   30.183166] Workqueue: omapdrm apply_worker [omapdrm]
>> [   30.207641] Backtrace:
>> [   30.210296] [] (dump_backtrace+0x0/0x10c) from [] 
>> (show_stack+0x18/0x1c)
>> [   30.219299]  r6:bf0e5988 r5:0009 r4: r3:eb872080
>> [   30.225433] [] (show_stack+0x0/0x1c) from [] 
>> (dump_stack+0x20/0x28)
>> [   30.234039] [] (dump_stack+0x0/0x28) from [] 
>> (warn_slowpath_common+0x54/0x74)
>> [   30.243530] [] (warn_slowpath_common+0x0/0x74) from 
>> [] (warn_slowpath_null+0x24/0x2c)
>> [   30.243774]  r8:ebfab99c r7:ebb41800 r6:ebb41830 r5:ebefce40 r4:ebefce40
>> r3:0009
>> [   30.262176] [] (warn_slowpath_null+0x0/0x2c) from [] 
>> (omap_gem_free_object+0x24c/0x25c [omapdrm])
>> [   30.273498] [] (omap_gem_free_object+0x0/0x25c [omapdrm]) from 
>> [] (drm_gem_object_free+0x30/0x38 [drm])
>> [   30.285675] [] (drm_gem_object_free+0x0/0x38 [drm]) from 
>> [] (omap_plane_post_apply+0x108/0x10c [omapdrm])
>> [   30.285675] [] (omap_plane_post_apply+0x0/0x10c [omapdrm]) from 
>> [] (apply_worker+0x68/0x188 [omapdrm])
>> [   30.309509]  r6:ebae5c6c r5:ebae5c5c r4:ebae5c5c
>> [   30.312042] [] (apply_worker+0x0/0x188 [omapdrm]) from 
>> [] (process_one_work+0x1b8/0x4e8)
>> [   30.325012] [] (process_one_work+0x0/0x4e8) from [] 
>> (worker_thread+0x138/0x388)
>> [   30.325378] [] (worker_thread+0x0/0x388) from [] 
>> (kthread+0xac/0xb8)
>> [   30.343292] [] (kthread+0x0/0xb8) from [] 
>> (ret_from_fork+0x14/0x2c)
>> [   30.351837]  r7: r6: r5:c0065fc4 r4:eb843d54
>> [   30.352111] ---[ end trace 78317663d3b4807c ]---
>>
>>
>> Deadlock at module unload
>> =
>> When removing the modules, there's a dealock. This is the last line printed:
>>
>> [   30.399200] [drm] Module unloaded
>>
>> Then, when the deadlock detection kicks in:
>>
>> [  240.962432] INFO: task rmmod:894 blocked for more than 120 seconds.
>> [  240.962432] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
>> this message.
>> [  240.977508] rmmod   D c0524964 0   894884 0x
>> [  240.981719] Backtrace:
>> [  240.987274] [] 

Multiple issues with omapdrm

[Rob Clark]

On Wed, Jun 5, 2013 at 4:59 AM, Tomi Valkeinen  wrote:
> Hi,
>
> I did some testing with omapdrm on v3.10-rc1. Here are some issues I 
> encountered.
> For most of them I don't have any idea where to even start looking for a 
> problem,
> so I hope that you may have some ideas.
>
>
> dispc_runtime_get/put used in irq context
> =
>
> dispc_runtime_get/put are used in irq context in omap_irq.c. I can hack
> around that with if (!in_atomic()), but I have no idea yet how to fix
> it properly.

Probably should have a flag/refcnt that is set when in the irq hander,
since we know that things are on in irq.

>
> drm_crtc warning
> 
>
> I got this once when unloading the modules, but haven't happened since:
>
> drm_crtc.c line 3869
>
> WARN_ON(!list_empty(>mode_config.fb_list));
>
> As it only happened once, maybe some kind of race.
>

Hmm, this is new..  it is certain that there can be a fb with a
reference still around, waiting for a vblank/framedone.  But I think
it should already be removed from userspace perspective and no longer
on fb_list.  I think I need to go back and have a closer look at
2b677e8c0 where Daniel introduced that WARN_ON().

> omap_gem warning
> 
>
> This happens on module unload:

oh, that is easy.. it is because the omap_fbdev.c does an unbalanced
omap_gem_get_paddr() to keep the fbcon fb from getting unmapped from
tiler (so if we have to restore fbcon mode in an opps, we don't have
to worry about grabbing mutexes or anything like that).  Maybe
somewhere in the cleanup it should do a put_paddr().  Otoh, I have
some skepticism about whether module unloading is really going to be
that reliable in practice, so meh..


BR,
-R

>
> [   30.167480] [ cut here ]
> [   30.167724] WARNING: at drivers/gpu/drm/omapdrm/omap_gem.c:1318 
> omap_gem_free_object+0x24c/0x25c [omapdrm]()
> [   30.182952] Modules linked in: omapdrm(-) drm_kms_helper drm panel_taal 
> panel_tfp410 panel_generic_dpi omapdss
> [   30.183166] CPU: 0 PID: 6 Comm: kworker/u4:0 Not tainted 
> 3.10.0-rc1-4-g8ed4760 #110
> [   30.183166] Workqueue: omapdrm apply_worker [omapdrm]
> [   30.207641] Backtrace:
> [   30.210296] [] (dump_backtrace+0x0/0x10c) from [] 
> (show_stack+0x18/0x1c)
> [   30.219299]  r6:bf0e5988 r5:0009 r4: r3:eb872080
> [   30.225433] [] (show_stack+0x0/0x1c) from [] 
> (dump_stack+0x20/0x28)
> [   30.234039] [] (dump_stack+0x0/0x28) from [] 
> (warn_slowpath_common+0x54/0x74)
> [   30.243530] [] (warn_slowpath_common+0x0/0x74) from [] 
> (warn_slowpath_null+0x24/0x2c)
> [   30.243774]  r8:ebfab99c r7:ebb41800 r6:ebb41830 r5:ebefce40 r4:ebefce40
> r3:0009
> [   30.262176] [] (warn_slowpath_null+0x0/0x2c) from [] 
> (omap_gem_free_object+0x24c/0x25c [omapdrm])
> [   30.273498] [] (omap_gem_free_object+0x0/0x25c [omapdrm]) from 
> [] (drm_gem_object_free+0x30/0x38 [drm])
> [   30.285675] [] (drm_gem_object_free+0x0/0x38 [drm]) from 
> [] (omap_plane_post_apply+0x108/0x10c [omapdrm])
> [   30.285675] [] (omap_plane_post_apply+0x0/0x10c [omapdrm]) from 
> [] (apply_worker+0x68/0x188 [omapdrm])
> [   30.309509]  r6:ebae5c6c r5:ebae5c5c r4:ebae5c5c
> [   30.312042] [] (apply_worker+0x0/0x188 [omapdrm]) from 
> [] (process_one_work+0x1b8/0x4e8)
> [   30.325012] [] (process_one_work+0x0/0x4e8) from [] 
> (worker_thread+0x138/0x388)
> [   30.325378] [] (worker_thread+0x0/0x388) from [] 
> (kthread+0xac/0xb8)
> [   30.343292] [] (kthread+0x0/0xb8) from [] 
> (ret_from_fork+0x14/0x2c)
> [   30.351837]  r7: r6: r5:c0065fc4 r4:eb843d54
> [   30.352111] ---[ end trace 78317663d3b4807c ]---
>
>
> Deadlock at module unload
> =
> When removing the modules, there's a dealock. This is the last line printed:
>
> [   30.399200] [drm] Module unloaded
>
> Then, when the deadlock detection kicks in:
>
> [  240.962432] INFO: task rmmod:894 blocked for more than 120 seconds.
> [  240.962432] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
> this message.
> [  240.977508] rmmod   D c0524964 0   894884 0x
> [  240.981719] Backtrace:
> [  240.987274] [] (__schedule+0x0/0x7e8) from [] 
> (schedule+0x38/0x78)
> [  240.995819] [] (schedule+0x0/0x78) from [] 
> (schedule_preempt_disabled+0x28/0x38)
> [  241.005706] [] (schedule_preempt_disabled+0x0/0x38) from 
> [] (mutex_lock_nested+0x1b8/0x3a8)
> [  241.016693]  r4:c07f5bf8 r3:eb978180
> [  241.020812] [] (mutex_lock_nested+0x0/0x3a8) from [] 
> (driver_detach+0x4c/0xc0)
> [  241.021026] [] (driver_detach+0x0/0xc0) from [] 
> (bus_remove_driver+0x94/0xfc)
> [  241.040100]  r6:c07f5b38 r5:bf0ec410 r4: r3:
> [  241.042633] [] (bus_remove_driver+0x0/0xfc) from [] 
> (driver_unregister+0x58/0x78)
> [  241.056060]  r6:c07c28a4 r5:bf0ec410 r4: r3:eb978180
> [  241.062164] [] (driver_unregister+0x0/0x78) from [] 
> (platform_driver_unregister+0x14/0x18)
> [  241.072875]  

[PATCH] drm: Add kernel-doc for plane functions

[Laurent Pinchart]

Hi Ville,

Thank you for the patch.

On Tuesday 04 June 2013 10:58:35 ville.syrjala at linux.intel.com wrote:
> From: Ville Syrj?l? 
> 
> Signed-off-by: Ville Syrj?l? 
> ---
>  drivers/gpu/drm/drm_crtc.c | 31 +++
>  1 file changed, 31 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index f00ba75..f1f11e1 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -795,6 +795,21 @@ void drm_encoder_cleanup(struct drm_encoder *encoder)
>  }
>  EXPORT_SYMBOL(drm_encoder_cleanup);
> 
> +/**
> + * drm_plane_init - Initialise a new plane object
> + * @dev: DRM device
> + * @plane: plane object to init
> + * @possible_crtcs: bitmask of possible CRTCs
> + * @funcs: callbacks for the new plane
> + * @formats: array of supported formats (%DRM_FORMAT_*)
> + * @format_count: number of elements in @formats
> + * @priv: plane is private (hidden from userspace)?
> + *
> + * Inits a new object created as base part of an driver plane object.

s/an driver/a driver/

> + *
> + * RETURNS:
> + * Zero on success, error code on failure.
> + */
>  int drm_plane_init(struct drm_device *dev, struct drm_plane *plane,
>  unsigned long possible_crtcs,
>  const struct drm_plane_funcs *funcs,
> @@ -843,6 +858,13 @@ int drm_plane_init(struct drm_device *dev, struct
> drm_plane *plane, }
>  EXPORT_SYMBOL(drm_plane_init);
> 
> +/**
> + * drm_plane_cleanup - Cleans up the core plane usage.

Nitpicking, you could remove the full stop at the end of the line to be 
consistent with the other two kerneldoc blocks.

And s/Cleans/Clean/

> + * @plane: plane to cleanup
> + *
> + * Cleanup @plane. Removes from drm modesetting space
> + * does NOT free object, caller does that.

As this is documentation, I'd use a more verbose style.

This function clean up @plane and removes it from the DRM mode setting core. 
Note that the function does *not* free the plane structure itself, this is the 
responsibility of the caller. 

> + */
>  void drm_plane_cleanup(struct drm_plane *plane)
>  {
>   struct drm_device *dev = plane->dev;
> @@ -859,6 +881,15 @@ void drm_plane_cleanup(struct drm_plane *plane)
>  }
>  EXPORT_SYMBOL(drm_plane_cleanup);
> 
> +/**
> + * drm_plane_force_disable - Forcibly disable a plane
> + * @plane: plane to disable
> + *
> + * Forces the plane to be disabled.

This feels a bit unclear to me. In particular, how is "force_disable" 
different from just disabling the plane ? Maybe the function should be renamed 
to drm_plane_disable(), and the documentation updated to mention that the 
function just disables the plane and disassociate with from its frame buffer.

> + *
> + * Used when the plane's current framebuffer is destroyed,
> + * and when restoring fbdev mode.
> + */
>  void drm_plane_force_disable(struct drm_plane *plane)
>  {
>   int ret;
-- 
Regards,

Laurent Pinchart

[PATCH v3] drm: Renesas R-Car Display Unit DRM driver

[Laurent Pinchart]

Hi Daniel,

On Tuesday 04 June 2013 20:36:20 Daniel Vetter wrote:
> On Tue, Jun 4, 2013 at 8:03 PM, Laurent Pinchart wrote:
> > On Tuesday 04 June 2013 16:12:36 Daniel Vetter wrote:
> >> On Tue, Jun 04, 2013 at 04:53:40AM +0200, Laurent Pinchart wrote:
>
> [snip]
> 
> >> Should we add that to crtc helpers, instead of the current "just try to
> >> smash the old config on top of the ill-defined hw state after a failed
> >> modeset"?
> > 
> > It would probably make sense to add a rollback operation to undo the
> > prepare operation, or maybe just a rollback/commit flag to the commit
> > operation. We would still need to smash the old config back though, as
> > the rollback operation shouldn't be expected to handle encoders and
> > connectors.
> > 
> > While we're at it, shouldn't we make drivers report supported formats for
> > the main frame buffer, like we do for planes ? That would allow catching
> > format errors before calling the prepare operation.
> 
> Yeah, I've noticed that one, too. I guess we could tackle that as part
> of an eventual "make the implicit primary plane a bit more explict"
> project. For now I'm not too offended by the duplication of checks.

It would be nice to treat the primary plane as all the other planes. Several 
embedded display engines don't make the primary plane special and just paint 
the background with a plain color when the enabled planes don't cover the 
entire display.

> >> This should use the drm_send_vblank_event helper.
> > 
> > What bothers me about drm_send_vblank_event() is that it calls
> > drm_vblank_count_and_time() with the events lock unnecessarily held. I can
> > live with that for now, I'll fix the driver to use the helper.
> 
> Most other drivers protect a bit of other state with that lock, so
> makes sense to hold it outside already. So not sure whether we should
> optimize this much ...

Probably not :-)

> >> > +   drm_vblank_put(dev, rcrtc->index);
> >> > +}
> > 
> > [snip]
> > 
> >> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> >> > b/drivers/gpu/drm/rcar-du/rcar_du_drv.c new file mode 100644
> >> > index 000..003b34e
> >> > --- /dev/null
> >> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> > 
> > [snip]
> > 
> >> > +static void rcar_du_disable_vblank(struct drm_device *dev, int crtc)
> >> > +{
> >> > +   struct rcar_du_device *rcdu = dev->dev_private;
> >> > +
> >> > +   rcar_du_crtc_enable_vblank(>crtcs[crtc], false);
> >> > +}
> >> 
> >> Blergh, I hate our legacy vblank code which forces kms driver to jump
> >> through int pipe -> struct drm_crtc * hoops.
> > 
> > How would you like to fix it ? :-)
> 
> Haven't looked at the details, but the first step I have in mind is to
> switch all drm core -> driver and driver -> vblank helper interfaces from
> int pipe to struct drm_crtc * pointers for kms drivers. That would allow us
> to implement at least sane locking for the vblank wait ioctl (by grabbing
> the crtc mutex).
> 
> My plan was to split things by copy new kms functions and then
> garbage-collecting all unnused features for the ums code (iirc no ums driver
> ever supported more than 2 crtcs, vblank events or high-precision
> timestamps).
> 
> Once that's in place we can look into more stuff. One of the things I want
> to play with is support for hw timestamp and vblank counters (also for
> pageflips). Then we don't have to enable the vblank interrupt so often and
> more important should be able to turn it of right away without loosing
> precision due to the potential vblank irq vs. vblank irq off race.
> 
> >> where i counts encoders to say that you can clone itself (userspace might
> >> get confused, haven't checked how throughout the modeset ddx is). But it
> >> sounds like rcar can clone encoders pretty freely (as long as they're
> >> using crtc 0), so maybe you want to use something like drm/i915 does?
> > 
> > The device has two outputs, 0 and 1. Output 0 can be driven by CRTC 0
> > only, and output 1 can be driven by CRTC 0 or CRTC 1.
> 
> Ah, that explains it, I've missed the context that we only have 2
> crtc/encoder pairs ;-)

It wasn't particularly explicit :-)

> >> We smash all cloneable encoders into one groub with a
> >> intel_encoder->cloneable flag and then allow cloning any cloneable
> >> encoder to any other cloneable encoder with intel_encoder_clones in
> >> intel_display.c
> >> 
> >> possible_clones is a bit a ill-defined part of the kms api, but I think
> >> we still should strive for consistency. Maybe the modesetting ddx should
> >> also grow a warning if the possible_clones mask doesn't make too much
> >> sense.
> > 
> > I haven't been able to find an authoritative source of documentation
> > regarding whether the possible_clones field should include the encoder
> > itself. That should definitely be documented, I can fix the driver
> > accordingly.
>
> Yeah, sounds like something worth clarifying. I'd vote for the self-clone
> bit to be set (I'm biased though, that's what i915 does). I guess we could
> 

[Bug 64257] RS880 issues with r600-llvm-compiler

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

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

--- Comment #30 from Tom Stellard  ---
Can you try this branch:
http://cgit.freedesktop.org/~tstellar/llvm/log/?h=r600-gen-fixes

I think it should fix the remaining issues.

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

[PATCH v2 5/5] drm: GEM CMA: Add DRM PRIME support

[Laurent Pinchart]

Hi Rob,

On Tuesday 04 June 2013 17:56:36 Rob Clark wrote:
> couple small comments, other than those it looks ok

Thanks for the review.

> On Mon, Jun 3, 2013 at 10:20 PM, Laurent Pinchart wrote:
> > Signed-off-by: Laurent Pinchart
> > 
> > ---
> > 
> >  drivers/gpu/drm/drm_gem_cma_helper.c | 321 +-
> >  include/drm/drm_gem_cma_helper.h |   9 +
> >  2 files changed, 327 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
> > b/drivers/gpu/drm/drm_gem_cma_helper.c index 7a4db4e..1dc2157 100644
> > --- a/drivers/gpu/drm/drm_gem_cma_helper.c
> > +++ b/drivers/gpu/drm/drm_gem_cma_helper.c
> > @@ -21,6 +21,9 @@
> >  #include 
> >  #include 
> >  #include 
> > +#if CONFIG_DMA_SHARED_BUFFER
> > +#include 
> > +#endif
> 
> I don't think we need the #if, since drm selects DMA_SHARED_BUFFER
> 
> and same for other spot below

Indeed. Will be fixed in the next version.

> >  #include 
> >  
> >  #include 

[snip]

> > @@ -291,3 +321,288 @@ void drm_gem_cma_describe(struct drm_gem_cma_object
> > *cma_obj, struct seq_file *m> 
> >  }
> >  EXPORT_SYMBOL_GPL(drm_gem_cma_describe);
> >  #endif
> > 
> > +
> > +/*
> > -
> >  + * DMA-BUF
> > + */
> > +
> > +#if CONFIG_DMA_SHARED_BUFFER
> > +struct drm_gem_cma_dmabuf_attachment {
> > +   struct sg_table sgt;
> > +   enum dma_data_direction dir;
> > +};
> > +
> > +static int drm_gem_cma_dmabuf_attach(struct dma_buf *dmabuf, struct
> > device *dev, +struct
> > dma_buf_attachment *attach) +{
> > +   struct drm_gem_cma_dmabuf_attachment *cma_attach;
> > +
> > +   cma_attach = kzalloc(sizeof(*cma_attach), GFP_KERNEL);
> > +   if (!cma_attach)
> > +   return -ENOMEM;
> > +
> > +   cma_attach->dir = DMA_NONE;
> > +   attach->priv = cma_attach;
> > +
> > +   return 0;
> > +}
> > +
> > +static void drm_gem_cma_dmabuf_detach(struct dma_buf *dmabuf,
> > + struct dma_buf_attachment *attach)
> > +{
> > +   struct drm_gem_cma_dmabuf_attachment *cma_attach = attach->priv;
> > +   struct sg_table *sgt;
> > +
> > +   if (cma_attach == NULL)
> > +   return;
> > +
> > +   sgt = _attach->sgt;
> > +
> > +   if (cma_attach->dir != DMA_NONE)
> > +   dma_unmap_sg(attach->dev, sgt->sgl, sgt->nents,
> > +   cma_attach->dir);
> > +
> > +   sg_free_table(sgt);
> > +   kfree(cma_attach);
> > +   attach->priv = NULL;
> > +}
> > +
> > +static struct sg_table *
> > +drm_gem_cma_dmabuf_map(struct dma_buf_attachment *attach,
> > +  enum dma_data_direction dir)
> > +{
> > +   struct drm_gem_cma_dmabuf_attachment *cma_attach = attach->priv;
> > +   struct drm_gem_cma_object *cma_obj = attach->dmabuf->priv;
> > +   struct drm_device *drm = cma_obj->base.dev;
> > +   struct scatterlist *rd, *wr;
> > +   struct sg_table *sgt;
> > +   unsigned int i;
> > +   int nents, ret;
> > +
> > +   DRM_DEBUG_PRIME("\n");
> > +
> > +   if (WARN_ON(dir == DMA_NONE))
> > +   return ERR_PTR(-EINVAL);
> > +
> > +   /* Return the cached mapping when possible. */
> > +   if (cma_attach->dir == dir)
> > +   return _attach->sgt;
> > +
> > +   /* Two mappings with different directions for the same attachment
> > are +* not allowed.
> > +*/
> > +   if (WARN_ON(cma_attach->dir != DMA_NONE))
> > +   return ERR_PTR(-EBUSY);
> > +
> > +   sgt = _attach->sgt;
> > +
> > +   ret = sg_alloc_table(sgt, cma_obj->sgt->orig_nents, GFP_KERNEL);
> > +   if (ret) {
> > +   DRM_ERROR("failed to alloc sgt.\n");
> > +   return ERR_PTR(-ENOMEM);
> > +   }
> > +
> > +   mutex_lock(>struct_mutex);
> > +
> > +   rd = cma_obj->sgt->sgl;
> > +   wr = sgt->sgl;
> > +   for (i = 0; i < sgt->orig_nents; ++i) {
> > +   sg_set_page(wr, sg_page(rd), rd->length, rd->offset);
> > +   rd = sg_next(rd);
> > +   wr = sg_next(wr);
> > +   }
> > +
> > +   nents = dma_map_sg(attach->dev, sgt->sgl, sgt->orig_nents, dir);
> > +   if (!nents) {
> > +   DRM_ERROR("failed to map sgl with iommu.\n");
> > +   sg_free_table(sgt);
> > +   sgt = ERR_PTR(-EIO);
> > +   goto done;
> > +   }
> > +
> > +   cma_attach->dir = dir;
> > +   attach->priv = cma_attach;
> > +
> > +   DRM_DEBUG_PRIME("buffer size = %zu\n", cma_obj->base.size);
> > +
> > +done:
> > +   mutex_unlock(>struct_mutex);
> > +   return sgt;
> > +}
> > +
> > +static void drm_gem_cma_dmabuf_unmap(struct dma_buf_attachment *attach,
> > +struct sg_table *sgt,
> > +enum 

[PATCH] nouveau: Load firmware for BSP/VP engines on NV84-NV96, NVA0

[Ilia Mirkin]

On Wed, Jun 5, 2013 at 3:05 AM, Maarten Lankhorst
 wrote:
> Hey,
>
> Op 04-06-13 20:38, Ilia Mirkin schreef:
>> On Mon, Jun 3, 2013 at 5:02 AM, Ilia Mirkin  wrote:
>>> These chipsets include the VP2 engine which is composed of a bitstream
>>> processor (BSP) that decodes H.264 and a video processor (VP) which can
>>> do iDCT/mo-comp/etc for MPEG1/2, H.264, and VC-1. Both of these are
>>> driven by separate xtensa chips embedded in the hardware. This patch
>>> provides the mechanism to load the kernel for the xtensa chips and
>>> provide the necessary interactions to do the rest of the work.
>>>
>>> Signed-off-by: Ilia Mirkin 
>>> ---
>>>
>>> This patch applies on top of nouveau/master (16a41bcc8).
>>>
>>> This seems to work for me. There was one boot where my userspace
>>> component didn't work right, but it could just as well be a bug
>>> there. Subsequent attempts seem to work fine. Note that I'm not
>>> particularly familiar with any of this stuff, so if something looks
>>> odd, I probably didn't know any better. I did try to faithfully
>>> reproduce whatever the blob did. A few questions/thoughts:
>>>
>>> 1. There's a LOT of similarity between BSP and VP setup/etc. Is it
>>>worth it to create a core/xtensa.c or some such, similar to
>>>falcon.c? Since it's only in two places, not that much code, and
>>>there _are_ differences, I decided to keep them separate.
>>>
>>> 2. Firmware naming. Maarten suggested to use the falcon naming style,
>>>which is nv$chipset_fuc$offset. However here, all the chips share
>>>the same firmware. Also the offset would be 103 vs 00f, and is a
>>>little arbitrary. (And fuc doesn't apply here... xt? xtensa?) I've
>>>left it the way I had it: nv84_bsp and nv84_vp.
>>>
>>> 3. Firmware load time. I chose to load the fw into memory in the ctor,
>>>and then copy it in in init, due to some potentially bogus
>>>suspend/resume concerns. Also e.g. mplayer likes to create/destroy
>>>decoders at startup a few times. The downside is that ~200KB of
>>>memory is gone. Let me know if I should change it to do the
>>>request_firmware in init.
>>>
>>> There's obviously a userspace piece to this, which I'm still working
>>> on. But right now I have it working within certain parameters
>>> (e.g. 1280x544 videos), and I'm relatively confident it can be
>>> completed without further kernel-side changes.
>>>
>>> There's also a hypothetical concern of "what if we create an open
>>> firmware with a different user API". Ideally there'd be some way to
>>> expose what kind of firmware is loaded, but I think that can be left
>>> for "later".
>>
>> I also happened to notice that NV98, NVA1+ refer to these nv84 engines
>> (in drivers/gpu/drm/nouveau/core/engine/device/nv50.c). I assume that
>> means I should create a new nv98.c version of BSP/VP that resembles
>> the old versions of nv84.c, and point device/nv50.c at those for nv98
>> and nva1+?
>>
> nv98+ should really have an implementation more like nvc0, and the copy engine
> is a good example on what conversion is needed to do it. :-)

That should probably be a separate patch, no? Do you mean something
more falcon-y? (It still needs firmware, right?) I think I should just
avoid changing things on those cards in this patch... (Also the only
NV card I have access to is my NV96, so I'll be more likely to keep
playing with that :) )

  -ilia

[Bug 65192] [r600g] Screensavers lock up machine (screen goes blank, keyboard unresponsive, sound loops; sysrq/ssh possible)

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

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

--- Comment #9 from Luzipher  ---
Unfortunately I couldn't confirm my thoughts. But I still am quite sure I did
not have those problems earlier - I had screensavers and youtube last year and
didn't notice regular crashes. I frequently use this linux installation, in
fact it's my main os for several years now, so I really would have noticed.
Maybe it's another package ? X, libdrm, radeon-ucode, xf86-video-ati come to
mind. Maybe mostly radeon-ucode, as I have the feeling that the problems
started at about the same time as the buzz on the uvd code drop.

Well, tests done (I could reproduce the crash on every of these with directly
started juggler3d on closing the window, mostly first or second try):

mesa-9.0.3 (forgot to get glxinfo)

mesa-9.0.1.ebuild, glxinfo:
OpenGL renderer string: Gallium 0.4 on AMD RV770
OpenGL version string: 3.0 Mesa 9.0.1
OpenGL shading language version string: 1.30

mesa-8.0.4-r1.ebuild, glxinfo:
OpenGL renderer string: Gallium 0.4 on AMD RV770
OpenGL version string: 2.1 Mesa 8.0.4
OpenGL shading language version string: 1.20
with 8.0.4, I got only garbage and a lot of these messages:
radeon: The kernel rejected CS, see dmesg for more information.
dmesg:
[ 1580.805418] radeon :02:00.0: r600_cs_track_validate_cb invalid tiling 6
for 0 (0x08110668)
[ 1580.805463] radeon :02:00.0: r600_packet3_check:1720 invalid cmd stream
573
[ 1580.805465] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !



I also tried the oldest kernel I have with 8.0.4, it's a vanilla 3.4.0-rc6.
Even there I could get the same crash after closing the window with the garbage
output.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[PATCH v2 5/5] drm: GEM CMA: Add DRM PRIME support

[Rob Clark]

On Tue, Jun 4, 2013 at 9:22 PM, Laurent Pinchart
 wrote:
> Hi Rob,
>
> On Tuesday 04 June 2013 17:56:36 Rob Clark wrote:
>> couple small comments, other than those it looks ok
>
> Thanks for the review.
>
>> On Mon, Jun 3, 2013 at 10:20 PM, Laurent Pinchart wrote:
>> > Signed-off-by: Laurent Pinchart
>> > 
>> > ---
>> >
>> >  drivers/gpu/drm/drm_gem_cma_helper.c | 321 +-
>> >  include/drm/drm_gem_cma_helper.h |   9 +
>> >  2 files changed, 327 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
>> > b/drivers/gpu/drm/drm_gem_cma_helper.c index 7a4db4e..1dc2157 100644
>> > --- a/drivers/gpu/drm/drm_gem_cma_helper.c
>> > +++ b/drivers/gpu/drm/drm_gem_cma_helper.c
>> > @@ -21,6 +21,9 @@
>> >  #include 
>> >  #include 
>> >  #include 
>> > +#if CONFIG_DMA_SHARED_BUFFER
>> > +#include 
>> > +#endif
>>
>> I don't think we need the #if, since drm selects DMA_SHARED_BUFFER
>>
>> and same for other spot below
>
> Indeed. Will be fixed in the next version.
>
>> >  #include 
>> >
>> >  #include 
>
> [snip]
>
>> > @@ -291,3 +321,288 @@ void drm_gem_cma_describe(struct drm_gem_cma_object
>> > *cma_obj, struct seq_file *m>
>> >  }
>> >  EXPORT_SYMBOL_GPL(drm_gem_cma_describe);
>> >  #endif
>> >
>> > +
>> > +/*
>> > -
>> >  + * DMA-BUF
>> > + */
>> > +
>> > +#if CONFIG_DMA_SHARED_BUFFER
>> > +struct drm_gem_cma_dmabuf_attachment {
>> > +   struct sg_table sgt;
>> > +   enum dma_data_direction dir;
>> > +};
>> > +
>> > +static int drm_gem_cma_dmabuf_attach(struct dma_buf *dmabuf, struct
>> > device *dev, +struct
>> > dma_buf_attachment *attach) +{
>> > +   struct drm_gem_cma_dmabuf_attachment *cma_attach;
>> > +
>> > +   cma_attach = kzalloc(sizeof(*cma_attach), GFP_KERNEL);
>> > +   if (!cma_attach)
>> > +   return -ENOMEM;
>> > +
>> > +   cma_attach->dir = DMA_NONE;
>> > +   attach->priv = cma_attach;
>> > +
>> > +   return 0;
>> > +}
>> > +
>> > +static void drm_gem_cma_dmabuf_detach(struct dma_buf *dmabuf,
>> > + struct dma_buf_attachment *attach)
>> > +{
>> > +   struct drm_gem_cma_dmabuf_attachment *cma_attach = attach->priv;
>> > +   struct sg_table *sgt;
>> > +
>> > +   if (cma_attach == NULL)
>> > +   return;
>> > +
>> > +   sgt = _attach->sgt;
>> > +
>> > +   if (cma_attach->dir != DMA_NONE)
>> > +   dma_unmap_sg(attach->dev, sgt->sgl, sgt->nents,
>> > +   cma_attach->dir);
>> > +
>> > +   sg_free_table(sgt);
>> > +   kfree(cma_attach);
>> > +   attach->priv = NULL;
>> > +}
>> > +
>> > +static struct sg_table *
>> > +drm_gem_cma_dmabuf_map(struct dma_buf_attachment *attach,
>> > +  enum dma_data_direction dir)
>> > +{
>> > +   struct drm_gem_cma_dmabuf_attachment *cma_attach = attach->priv;
>> > +   struct drm_gem_cma_object *cma_obj = attach->dmabuf->priv;
>> > +   struct drm_device *drm = cma_obj->base.dev;
>> > +   struct scatterlist *rd, *wr;
>> > +   struct sg_table *sgt;
>> > +   unsigned int i;
>> > +   int nents, ret;
>> > +
>> > +   DRM_DEBUG_PRIME("\n");
>> > +
>> > +   if (WARN_ON(dir == DMA_NONE))
>> > +   return ERR_PTR(-EINVAL);
>> > +
>> > +   /* Return the cached mapping when possible. */
>> > +   if (cma_attach->dir == dir)
>> > +   return _attach->sgt;
>> > +
>> > +   /* Two mappings with different directions for the same attachment
>> > are +* not allowed.
>> > +*/
>> > +   if (WARN_ON(cma_attach->dir != DMA_NONE))
>> > +   return ERR_PTR(-EBUSY);
>> > +
>> > +   sgt = _attach->sgt;
>> > +
>> > +   ret = sg_alloc_table(sgt, cma_obj->sgt->orig_nents, GFP_KERNEL);
>> > +   if (ret) {
>> > +   DRM_ERROR("failed to alloc sgt.\n");
>> > +   return ERR_PTR(-ENOMEM);
>> > +   }
>> > +
>> > +   mutex_lock(>struct_mutex);
>> > +
>> > +   rd = cma_obj->sgt->sgl;
>> > +   wr = sgt->sgl;
>> > +   for (i = 0; i < sgt->orig_nents; ++i) {
>> > +   sg_set_page(wr, sg_page(rd), rd->length, rd->offset);
>> > +   rd = sg_next(rd);
>> > +   wr = sg_next(wr);
>> > +   }
>> > +
>> > +   nents = dma_map_sg(attach->dev, sgt->sgl, sgt->orig_nents, dir);
>> > +   if (!nents) {
>> > +   DRM_ERROR("failed to map sgl with iommu.\n");
>> > +   sg_free_table(sgt);
>> > +   sgt = ERR_PTR(-EIO);
>> > +   goto done;
>> > +   }
>> > +
>> > +   cma_attach->dir = dir;
>> > +   attach->priv = cma_attach;
>> > +
>> > +   DRM_DEBUG_PRIME("buffer size = %zu\n", cma_obj->base.size);
>> > +
>> > +done:
>> > +   mutex_unlock(>struct_mutex);
>> > +   return 

Re: [PATCH] nouveau: Load firmware for BSP/VP engines on NV84-NV96, NVA0

[Maarten Lankhorst]

Hey,

Op 04-06-13 20:38, Ilia Mirkin schreef:
 On Mon, Jun 3, 2013 at 5:02 AM, Ilia Mirkin imir...@alum.mit.edu wrote:
 These chipsets include the VP2 engine which is composed of a bitstream
 processor (BSP) that decodes H.264 and a video processor (VP) which can
 do iDCT/mo-comp/etc for MPEG1/2, H.264, and VC-1. Both of these are
 driven by separate xtensa chips embedded in the hardware. This patch
 provides the mechanism to load the kernel for the xtensa chips and
 provide the necessary interactions to do the rest of the work.

 Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
 ---

 This patch applies on top of nouveau/master (16a41bcc8).

 This seems to work for me. There was one boot where my userspace
 component didn't work right, but it could just as well be a bug
 there. Subsequent attempts seem to work fine. Note that I'm not
 particularly familiar with any of this stuff, so if something looks
 odd, I probably didn't know any better. I did try to faithfully
 reproduce whatever the blob did. A few questions/thoughts:

 1. There's a LOT of similarity between BSP and VP setup/etc. Is it
worth it to create a core/xtensa.c or some such, similar to
falcon.c? Since it's only in two places, not that much code, and
there _are_ differences, I decided to keep them separate.

 2. Firmware naming. Maarten suggested to use the falcon naming style,
which is nv$chipset_fuc$offset. However here, all the chips share
the same firmware. Also the offset would be 103 vs 00f, and is a
little arbitrary. (And fuc doesn't apply here... xt? xtensa?) I've
left it the way I had it: nv84_bsp and nv84_vp.

 3. Firmware load time. I chose to load the fw into memory in the ctor,
and then copy it in in init, due to some potentially bogus
suspend/resume concerns. Also e.g. mplayer likes to create/destroy
decoders at startup a few times. The downside is that ~200KB of
memory is gone. Let me know if I should change it to do the
request_firmware in init.

 There's obviously a userspace piece to this, which I'm still working
 on. But right now I have it working within certain parameters
 (e.g. 1280x544 videos), and I'm relatively confident it can be
 completed without further kernel-side changes.

 There's also a hypothetical concern of what if we create an open
 firmware with a different user API. Ideally there'd be some way to
 expose what kind of firmware is loaded, but I think that can be left
 for later.
 I also happened to notice that NV98, NVA1+ refer to these nv84 engines
 (in drivers/gpu/drm/nouveau/core/engine/device/nv50.c). I assume that
 means I should create a new nv98.c version of BSP/VP that resembles
 the old versions of nv84.c, and point device/nv50.c at those for nv98
 and nva1+?
nv98+ should really have an implementation more like nvc0, and the copy engine
is a good example on what conversion is needed to do it. :-)

If you fix that up, I'll stop being lazy and fix VP4 for nva3/a5/a8 in mesa. ;)

~Maarten

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

Re: [PATCH] nouveau: Load firmware for BSP/VP engines on NV84-NV96, NVA0

[Ilia Mirkin]

On Wed, Jun 5, 2013 at 3:05 AM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
 Hey,

 Op 04-06-13 20:38, Ilia Mirkin schreef:
 On Mon, Jun 3, 2013 at 5:02 AM, Ilia Mirkin imir...@alum.mit.edu wrote:
 These chipsets include the VP2 engine which is composed of a bitstream
 processor (BSP) that decodes H.264 and a video processor (VP) which can
 do iDCT/mo-comp/etc for MPEG1/2, H.264, and VC-1. Both of these are
 driven by separate xtensa chips embedded in the hardware. This patch
 provides the mechanism to load the kernel for the xtensa chips and
 provide the necessary interactions to do the rest of the work.

 Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
 ---

 This patch applies on top of nouveau/master (16a41bcc8).

 This seems to work for me. There was one boot where my userspace
 component didn't work right, but it could just as well be a bug
 there. Subsequent attempts seem to work fine. Note that I'm not
 particularly familiar with any of this stuff, so if something looks
 odd, I probably didn't know any better. I did try to faithfully
 reproduce whatever the blob did. A few questions/thoughts:

 1. There's a LOT of similarity between BSP and VP setup/etc. Is it
worth it to create a core/xtensa.c or some such, similar to
falcon.c? Since it's only in two places, not that much code, and
there _are_ differences, I decided to keep them separate.

 2. Firmware naming. Maarten suggested to use the falcon naming style,
which is nv$chipset_fuc$offset. However here, all the chips share
the same firmware. Also the offset would be 103 vs 00f, and is a
little arbitrary. (And fuc doesn't apply here... xt? xtensa?) I've
left it the way I had it: nv84_bsp and nv84_vp.

 3. Firmware load time. I chose to load the fw into memory in the ctor,
and then copy it in in init, due to some potentially bogus
suspend/resume concerns. Also e.g. mplayer likes to create/destroy
decoders at startup a few times. The downside is that ~200KB of
memory is gone. Let me know if I should change it to do the
request_firmware in init.

 There's obviously a userspace piece to this, which I'm still working
 on. But right now I have it working within certain parameters
 (e.g. 1280x544 videos), and I'm relatively confident it can be
 completed without further kernel-side changes.

 There's also a hypothetical concern of what if we create an open
 firmware with a different user API. Ideally there'd be some way to
 expose what kind of firmware is loaded, but I think that can be left
 for later.

 I also happened to notice that NV98, NVA1+ refer to these nv84 engines
 (in drivers/gpu/drm/nouveau/core/engine/device/nv50.c). I assume that
 means I should create a new nv98.c version of BSP/VP that resembles
 the old versions of nv84.c, and point device/nv50.c at those for nv98
 and nva1+?

 nv98+ should really have an implementation more like nvc0, and the copy engine
 is a good example on what conversion is needed to do it. :-)

That should probably be a separate patch, no? Do you mean something
more falcon-y? (It still needs firmware, right?) I think I should just
avoid changing things on those cards in this patch... (Also the only
NV card I have access to is my NV96, so I'll be more likely to keep
playing with that :) )

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

Re: [PATCH] drm/exynos: remove ignoring return value warning in hdmi

[Inki Dae]

2013/6/5 Seung-Woo Kim sw0312@samsung.com

 The definition of regulator_bulk_enable is fixed with __must_check
 and this causes following build warning.
 warning: ignoring return value of 'regulator_bulk_enable',
 declared with attribute warn_unused_result
 This patch fixes to check return value of the function.

 Signed-off-by: Seung-Woo Kim sw0312@samsung.com
 ---
  drivers/gpu/drm/exynos/exynos_hdmi.c |4 +++-
  1 files changed, 3 insertions(+), 1 deletions(-)

 diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
 b/drivers/gpu/drm/exynos/exynos_hdmi.c
 index 2f78532..f807b13 100644
 --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
 +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
 @@ -1699,7 +1699,9 @@ static void hdmi_poweron(struct hdmi_context *hdata)

 mutex_unlock(hdata-hdmi_mutex);

 -   regulator_bulk_enable(res-regul_count, res-regul_bulk);
 +   if (regulator_bulk_enable(res-regul_count, res-regul_bulk))
 +   DRM_ERROR(failed to enable regulator bulk\n);


Now it's not error case; having no return type, so just changed it into
DRM_DEBUG_KMS. However, we need to add more exception codes to this
function later.

Applied.

Thanks,
Inki Dae


 +
 clk_enable(res-hdmiphy);
 clk_enable(res-hdmi);
 clk_enable(res-sclk_hdmi);
 --
 1.7.4.1

 ___
 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 60929] [r600-llvm] mono games with opengl are blocking on start

[bugzilla-daemon]

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

--- Comment #4 from Laurent carlier lordhea...@gmail.com ---
Yes, it's still an issue, i have to disable R600_LLVM to play mono games

-- 
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/exynos: do not use mode_set_base function directly

[Inki Dae]

This patch adds exynos_drm_crtc_mode_set_commit function
to update mode data and it makes page flip call this function
instead of calling exynos_drm_crtc_mode_set_base function directly.

exynos_drm_crtc_mode_set_base function is called by drm subsystem
as a callback so we don't have to call this function directly.

Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c |   10 --
 1 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index c200e4d..c64e32d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -139,7 +139,7 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct 
drm_display_mode *mode,
return 0;
 }
 
-static int exynos_drm_crtc_mode_set_base(struct drm_crtc *crtc, int x, int y,
+static int exynos_drm_crtc_mode_set_commit(struct drm_crtc *crtc, int x, int y,
  struct drm_framebuffer *old_fb)
 {
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
@@ -169,6 +169,12 @@ static int exynos_drm_crtc_mode_set_base(struct drm_crtc 
*crtc, int x, int y,
return 0;
 }
 
+static int exynos_drm_crtc_mode_set_base(struct drm_crtc *crtc, int x, int y,
+ struct drm_framebuffer *old_fb)
+{
+   return exynos_drm_crtc_mode_set_commit(crtc, x, y, old_fb);
+}
+
 static void exynos_drm_crtc_load_lut(struct drm_crtc *crtc)
 {
DRM_DEBUG_KMS(%s\n, __FILE__);
@@ -237,7 +243,7 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc,
spin_unlock_irq(dev-event_lock);
 
crtc-fb = fb;
-   ret = exynos_drm_crtc_mode_set_base(crtc, crtc-x, crtc-y,
+   ret = exynos_drm_crtc_mode_set_commit(crtc, crtc-x, crtc-y,
NULL);
if (ret) {
crtc-fb = old_fb;
-- 
1.7.5.4

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

[PATCH 0/2] drm/exynos: clean up logs for next tree

[Seung-Woo Kim]

This patch set removes tracking logs and function name duplications.
This is for the next tree and based on exynos-drm-next branch.

YoungJun Cho (2):
  drm/exynos: Remove tracking log functions
  drm/exynos: Clean up logs for DRM_ERROR / DRM_DEBUG_KMS

 drivers/gpu/drm/exynos/exynos_drm_buf.c   |7 -
 drivers/gpu/drm/exynos/exynos_drm_connector.c |   17 --
 drivers/gpu/drm/exynos/exynos_drm_core.c  |   12 --
 drivers/gpu/drm/exynos/exynos_drm_crtc.c  |   29 
 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c|6 -
 drivers/gpu/drm/exynos/exynos_drm_drv.c   |   20 ---
 drivers/gpu/drm/exynos/exynos_drm_encoder.c   |   28 +
 drivers/gpu/drm/exynos/exynos_drm_fb.c|   10 --
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |8 -
 drivers/gpu/drm/exynos/exynos_drm_fimc.c  |  129 +++--
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  |   46 +--
 drivers/gpu/drm/exynos/exynos_drm_gem.c   |   23 ---
 drivers/gpu/drm/exynos/exynos_drm_gsc.c   |  102 +
 drivers/gpu/drm/exynos/exynos_drm_hdmi.c  |   42 -
 drivers/gpu/drm/exynos/exynos_drm_ipp.c   |  201 
 drivers/gpu/drm/exynos/exynos_drm_plane.c |   16 --
 drivers/gpu/drm/exynos/exynos_drm_rotator.c   |   53 +++-
 drivers/gpu/drm/exynos/exynos_drm_vidi.c  |   40 +-
 drivers/gpu/drm/exynos/exynos_hdmi.c  |   42 +-
 drivers/gpu/drm/exynos/exynos_mixer.c |   32 +
 20 files changed, 193 insertions(+), 670 deletions(-)

-- 
1.7.4.1

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

[PATCH 2/2] drm/exynos: Clean up logs for DRM_ERROR / DRM_DEBUG_KMS

[Seung-Woo Kim]

From: YoungJun Cho yj44@samsung.com

This patch cleans up logs for DRM_ERROR / DRM_DEBUG_KMS to avoid
logging duplicated function name because the macros already contain
 __func__.

Signed-off-by: YoungJun Cho yj44@samsung.com
Signed-off-by: Seung-Woo Kim sw0312@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_fimc.c|  113 ++---
 drivers/gpu/drm/exynos/exynos_drm_gsc.c |   90 +++-
 drivers/gpu/drm/exynos/exynos_drm_ipp.c |  149 ---
 drivers/gpu/drm/exynos/exynos_drm_rotator.c |   41 +++
 drivers/gpu/drm/exynos/exynos_hdmi.c|   10 +-
 drivers/gpu/drm/exynos/exynos_mixer.c   |   12 +-
 6 files changed, 189 insertions(+), 226 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 7b5f2e8..61b094f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -217,7 +217,7 @@ static void fimc_set_type_ctrl(struct fimc_context *ctx, 
enum fimc_wb wb)
 {
u32 cfg;
 
-   DRM_DEBUG_KMS(%s:wb[%d]\n, __func__, wb);
+   DRM_DEBUG_KMS(wb[%d]\n, wb);
 
cfg = fimc_read(EXYNOS_CIGCTRL);
cfg = ~(EXYNOS_CIGCTRL_TESTPATTERN_MASK |
@@ -253,10 +253,10 @@ static void fimc_set_polarity(struct fimc_context *ctx,
 {
u32 cfg;
 
-   DRM_DEBUG_KMS(%s:inv_pclk[%d]inv_vsync[%d]\n,
-   __func__, pol-inv_pclk, pol-inv_vsync);
-   DRM_DEBUG_KMS(%s:inv_href[%d]inv_hsync[%d]\n,
-   __func__, pol-inv_href, pol-inv_hsync);
+   DRM_DEBUG_KMS(inv_pclk[%d]inv_vsync[%d]\n,
+   pol-inv_pclk, pol-inv_vsync);
+   DRM_DEBUG_KMS(inv_href[%d]inv_hsync[%d]\n,
+   pol-inv_href, pol-inv_hsync);
 
cfg = fimc_read(EXYNOS_CIGCTRL);
cfg = ~(EXYNOS_CIGCTRL_INVPOLPCLK | EXYNOS_CIGCTRL_INVPOLVSYNC |
@@ -278,7 +278,7 @@ static void fimc_handle_jpeg(struct fimc_context *ctx, bool 
enable)
 {
u32 cfg;
 
-   DRM_DEBUG_KMS(%s:enable[%d]\n, __func__, enable);
+   DRM_DEBUG_KMS(enable[%d]\n, enable);
 
cfg = fimc_read(EXYNOS_CIGCTRL);
if (enable)
@@ -294,7 +294,7 @@ static void fimc_handle_irq(struct fimc_context *ctx, bool 
enable,
 {
u32 cfg;
 
-   DRM_DEBUG_KMS(%s:enable[%d]overflow[%d]level[%d]\n, __func__,
+   DRM_DEBUG_KMS(enable[%d]overflow[%d]level[%d]\n,
enable, overflow, level);
 
cfg = fimc_read(EXYNOS_CIGCTRL);
@@ -329,7 +329,7 @@ static bool fimc_check_ovf(struct fimc_context *ctx)
flag = EXYNOS_CISTATUS_OVFIY | EXYNOS_CISTATUS_OVFICB |
EXYNOS_CISTATUS_OVFICR;
 
-   DRM_DEBUG_KMS(%s:flag[0x%x]\n, __func__, flag);
+   DRM_DEBUG_KMS(flag[0x%x]\n, flag);
 
if (status  flag) {
cfg = fimc_read(EXYNOS_CIWDOFST);
@@ -358,7 +358,7 @@ static bool fimc_check_frame_end(struct fimc_context *ctx)
 
cfg = fimc_read(EXYNOS_CISTATUS);
 
-   DRM_DEBUG_KMS(%s:cfg[0x%x]\n, __func__, cfg);
+   DRM_DEBUG_KMS(cfg[0x%x]\n, cfg);
 
if (!(cfg  EXYNOS_CISTATUS_FRAMEEND))
return false;
@@ -380,7 +380,7 @@ static int fimc_get_buf_id(struct fimc_context *ctx)
if (frame_cnt == 0)
frame_cnt = EXYNOS_CISTATUS2_GET_FRAMECOUNT_PRESENT(cfg);
 
-   DRM_DEBUG_KMS(%s:present[%d]before[%d]\n, __func__,
+   DRM_DEBUG_KMS(present[%d]before[%d]\n,
EXYNOS_CISTATUS2_GET_FRAMECOUNT_PRESENT(cfg),
EXYNOS_CISTATUS2_GET_FRAMECOUNT_BEFORE(cfg));
 
@@ -390,7 +390,7 @@ static int fimc_get_buf_id(struct fimc_context *ctx)
}
 
buf_id = frame_cnt - 1;
-   DRM_DEBUG_KMS(%s:buf_id[%d]\n, __func__, buf_id);
+   DRM_DEBUG_KMS(buf_id[%d]\n, buf_id);
 
return buf_id;
 }
@@ -399,7 +399,7 @@ static void fimc_handle_lastend(struct fimc_context *ctx, 
bool enable)
 {
u32 cfg;
 
-   DRM_DEBUG_KMS(%s:enable[%d]\n, __func__, enable);
+   DRM_DEBUG_KMS(enable[%d]\n, enable);
 
cfg = fimc_read(EXYNOS_CIOCTRL);
if (enable)
@@ -416,7 +416,7 @@ static int fimc_src_set_fmt_order(struct fimc_context *ctx, 
u32 fmt)
struct exynos_drm_ippdrv *ippdrv = ctx-ippdrv;
u32 cfg;
 
-   DRM_DEBUG_KMS(%s:fmt[0x%x]\n, __func__, fmt);
+   DRM_DEBUG_KMS(fmt[0x%x]\n, fmt);
 
/* RGB */
cfg = fimc_read(EXYNOS_CISCCTRL);
@@ -489,7 +489,7 @@ static int fimc_src_set_fmt(struct device *dev, u32 fmt)
struct exynos_drm_ippdrv *ippdrv = ctx-ippdrv;
u32 cfg;
 
-   DRM_DEBUG_KMS(%s:fmt[0x%x]\n, __func__, fmt);
+   DRM_DEBUG_KMS(fmt[0x%x]\n, fmt);
 
cfg = fimc_read(EXYNOS_MSCTRL);
cfg = ~EXYNOS_MSCTRL_INFORMAT_RGB;
@@ -549,8 +549,7 @@ static int fimc_src_set_transf(struct device *dev,
struct exynos_drm_ippdrv *ippdrv = ctx-ippdrv;
u32 cfg1, cfg2;
 
-   DRM_DEBUG_KMS(%s:degree[%d]flip[0x%x]\n, __func__,
-   degree, flip);
+   

Re: [RFC][PATCH 0/2] dma-buf: add importer private data for reimporting

[Daniel Vetter]

On Wed, Jun 05, 2013 at 11:52:59AM +0900, 김승우 wrote:
 
 
 On 2013년 06월 04일 21:55, Daniel Vetter wrote:
  On Tue, Jun 04, 2013 at 07:42:22PM +0900, 김승우 wrote:
 
 
  On 2013년 06월 01일 00:29, Daniel Vetter wrote:
  On Fri, May 31, 2013 at 07:22:24PM +0900, 김승우 wrote:
  Hello Daniel,
 
  Thanks for your comment.
 
  On 2013년 05월 31일 18:14, Daniel Vetter wrote:
  On Fri, May 31, 2013 at 10:54 AM, Seung-Woo Kim 
  sw0312@samsung.com wrote:
  importer private data in dma-buf attachment can be used by importer to
  reimport same dma-buf.
 
  Seung-Woo Kim (2):
dma-buf: add importer private data to attachment
drm/prime: find gem object from the reimported dma-buf
 
  Self-import should already work (at least with the latest refcount
  fixes merged). At least the tests to check both re-import on the same
  drm fd and on a different all work as expected now.
 
  Currently, prime works well for all case including self-importing,
  importing, and reimporting as you describe. Just, importing dma-buf from
  other driver twice with different drm_fd, each import create its own gem
  object even two import is done for same buffer because prime_priv is in
  struct drm_file. This means mapping to the device is done also twice.
  IMHO, these duplicated creations and maps are not necessary if drm can
  find previous import in different prime_priv.
 
  Well, that's imo a bug with the other driver. If it doesn't export
  something really simple (e.g. contiguous memory which doesn't require any
  mmio resources at all) it should have a cache of exported dma_buf fds so
  that it hands out the same dma_buf every time.
 
  Hm, all existing dma-buf exporter including i915 driver implements its
  map_dma_buf callback as allocating scatter-gather table with pages in
  its buffer and calling dma_map_sg() with the sgt. With different
  drm_fds, importing one dma-buf *twice*, then importer calls
  dma_buf_attach() and dma_buf_map_attachment() twice at least in drm
  importer because re-importing case can only checked with prime_priv in
  drm_file as I described.
  
  Well, but thanks to all the self-import and re-import checks, it's
  _impossible_ to import the same dma_buf twice without noticing (presuming
  both importer and exporter are drm devices).
 
 No, it is possible. Prime function, drm_gem_prime_fd_to_handle(), checks
 re-import with following code.
 
 ret = drm_prime_lookup_buf_handle(file_priv-prime,
   dma_buf, handle);
 
 Unfortunately, file_priv is allocated per each open of drm node so this
 code can only find re-import within same drm open context.
 
 And driver specific import functions, like drm_gem_prime_import(), only
 check self-import like following code.
 
 if (dma_buf-ops == drm_gem_prime_dmabuf_ops) {
   obj = dma_buf-priv;
   if (obj-dev == dev) {
   /* ... */
   }
 }
 
 This means some application like following can make re-import to
 different gem objects.
 
 int drm_fd1, drm_fd2, ret;
 int dma_buf_fd;
 struct drm_prime_handle prime1, prime2;
 
 drm_fd1 = open(DRM_NODE, O_RDWR, 0);
 drm_fd2 = open(DRM_NODE, O_RDWR, 0);
 
 /* get some dma-buf_fd from other dma-buf exporter */
 prime1.fd = dma_buf_fd;
 prime2.fd = dma_buf_fd;
 
 ret = ioctl(drm_fd1, DRM_IOCTL_PRIME_FD_TO_HANDLE, prime1);
 ret = ioctl(drm_fd2, DRM_IOCTL_PRIME_FD_TO_HANDLE, prime2);
 
 This will import same dma-buf twice as different GEM object because
 above checking codes can not check already imported gem object from the
 dma-buf.

Oh right, now I understand. Somehow I've always thought we already take
care of this case, since I remember discussing it.

To fix that we need a device-global import cache similar to how we already
have one for each file_priv. I think we can reuse the same locking and
refcounting scheme, but I haven't checked. The commit messages of the past
few prime changes have fairly good explanations of the tricky stuff going
on there.

Sorry for being dense for so long, I should have checked my idea of what
the drm prime code does with reality sooner ;-)

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 5/5] drm: GEM CMA: Add DRM PRIME support

[Daniel Vetter]

On Tue, Jun 04, 2013 at 11:05:36PM -0400, Rob Clark wrote:
 On Tue, Jun 4, 2013 at 9:22 PM, Laurent Pinchart
 laurent.pinch...@ideasonboard.com wrote:
  Hi Rob,
 
  On Tuesday 04 June 2013 17:56:36 Rob Clark wrote:
  couple small comments, other than those it looks ok
 
  Thanks for the review.
 
  On Mon, Jun 3, 2013 at 10:20 PM, Laurent Pinchart wrote:
   Signed-off-by: Laurent Pinchart
   laurent.pinchart+rene...@ideasonboard.com
   ---
  
drivers/gpu/drm/drm_gem_cma_helper.c | 321 
   +-
include/drm/drm_gem_cma_helper.h |   9 +
2 files changed, 327 insertions(+), 3 deletions(-)
  
   diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
   b/drivers/gpu/drm/drm_gem_cma_helper.c index 7a4db4e..1dc2157 100644
   --- a/drivers/gpu/drm/drm_gem_cma_helper.c
   +++ b/drivers/gpu/drm/drm_gem_cma_helper.c
   @@ -21,6 +21,9 @@
#include linux/slab.h
#include linux/mutex.h
#include linux/export.h
   +#if CONFIG_DMA_SHARED_BUFFER
   +#include linux/dma-buf.h
   +#endif
 
  I don't think we need the #if, since drm selects DMA_SHARED_BUFFER
 
  and same for other spot below
 
  Indeed. Will be fixed in the next version.
 
#include linux/dma-mapping.h
  
#include drm/drmP.h
 
  [snip]
 
   @@ -291,3 +321,288 @@ void drm_gem_cma_describe(struct drm_gem_cma_object
   *cma_obj, struct seq_file *m
}
EXPORT_SYMBOL_GPL(drm_gem_cma_describe);
#endif
  
   +
   +/*
   -
    + * DMA-BUF
   + */
   +
   +#if CONFIG_DMA_SHARED_BUFFER
   +struct drm_gem_cma_dmabuf_attachment {
   +   struct sg_table sgt;
   +   enum dma_data_direction dir;
   +};
   +
   +static int drm_gem_cma_dmabuf_attach(struct dma_buf *dmabuf, struct
   device *dev, +struct
   dma_buf_attachment *attach) +{
   +   struct drm_gem_cma_dmabuf_attachment *cma_attach;
   +
   +   cma_attach = kzalloc(sizeof(*cma_attach), GFP_KERNEL);
   +   if (!cma_attach)
   +   return -ENOMEM;
   +
   +   cma_attach-dir = DMA_NONE;
   +   attach-priv = cma_attach;
   +
   +   return 0;
   +}
   +
   +static void drm_gem_cma_dmabuf_detach(struct dma_buf *dmabuf,
   + struct dma_buf_attachment *attach)
   +{
   +   struct drm_gem_cma_dmabuf_attachment *cma_attach = attach-priv;
   +   struct sg_table *sgt;
   +
   +   if (cma_attach == NULL)
   +   return;
   +
   +   sgt = cma_attach-sgt;
   +
   +   if (cma_attach-dir != DMA_NONE)
   +   dma_unmap_sg(attach-dev, sgt-sgl, sgt-nents,
   +   cma_attach-dir);
   +
   +   sg_free_table(sgt);
   +   kfree(cma_attach);
   +   attach-priv = NULL;
   +}
   +
   +static struct sg_table *
   +drm_gem_cma_dmabuf_map(struct dma_buf_attachment *attach,
   +  enum dma_data_direction dir)
   +{
   +   struct drm_gem_cma_dmabuf_attachment *cma_attach = attach-priv;
   +   struct drm_gem_cma_object *cma_obj = attach-dmabuf-priv;
   +   struct drm_device *drm = cma_obj-base.dev;
   +   struct scatterlist *rd, *wr;
   +   struct sg_table *sgt;
   +   unsigned int i;
   +   int nents, ret;
   +
   +   DRM_DEBUG_PRIME(\n);
   +
   +   if (WARN_ON(dir == DMA_NONE))
   +   return ERR_PTR(-EINVAL);
   +
   +   /* Return the cached mapping when possible. */
   +   if (cma_attach-dir == dir)
   +   return cma_attach-sgt;
   +
   +   /* Two mappings with different directions for the same attachment
   are +* not allowed.
   +*/
   +   if (WARN_ON(cma_attach-dir != DMA_NONE))
   +   return ERR_PTR(-EBUSY);
   +
   +   sgt = cma_attach-sgt;
   +
   +   ret = sg_alloc_table(sgt, cma_obj-sgt-orig_nents, GFP_KERNEL);
   +   if (ret) {
   +   DRM_ERROR(failed to alloc sgt.\n);
   +   return ERR_PTR(-ENOMEM);
   +   }
   +
   +   mutex_lock(drm-struct_mutex);
   +
   +   rd = cma_obj-sgt-sgl;
   +   wr = sgt-sgl;
   +   for (i = 0; i  sgt-orig_nents; ++i) {
   +   sg_set_page(wr, sg_page(rd), rd-length, rd-offset);
   +   rd = sg_next(rd);
   +   wr = sg_next(wr);
   +   }
   +
   +   nents = dma_map_sg(attach-dev, sgt-sgl, sgt-orig_nents, dir);
   +   if (!nents) {
   +   DRM_ERROR(failed to map sgl with iommu.\n);
   +   sg_free_table(sgt);
   +   sgt = ERR_PTR(-EIO);
   +   goto done;
   +   }
   +
   +   cma_attach-dir = dir;
   +   attach-priv = cma_attach;
   +
   +   DRM_DEBUG_PRIME(buffer size = %zu\n, cma_obj-base.size);
   +
   +done:
   +   mutex_unlock(drm-struct_mutex);
   +   return sgt;
   +}
   +
   +static void drm_gem_cma_dmabuf_unmap(struct dma_buf_attachment *attach,
   +  

Re: [PATCH v3] drm: Renesas R-Car Display Unit DRM driver

[Daniel Vetter]

On Wed, Jun 05, 2013 at 03:51:53AM +0200, Laurent Pinchart wrote:
 Hi Daniel,
 
 On Tuesday 04 June 2013 20:36:20 Daniel Vetter wrote:
  On Tue, Jun 4, 2013 at 8:03 PM, Laurent Pinchart wrote:
   On Tuesday 04 June 2013 16:12:36 Daniel Vetter wrote:
   On Tue, Jun 04, 2013 at 04:53:40AM +0200, Laurent Pinchart wrote:

[snip]

+static int rcar_du_vga_connector_get_modes(struct drm_connector
*connector)
+{
+   return drm_add_modes_noedid(connector, 1280, 768);
+}
   
   This (and the dummy detect function below) looks a bit funny, since it
   essentially overrides the default behaviour already provided by the crtc
   helpers. Until rcar has at least proper detect support for VGA
   
   I would add that but the DDC signals are not connected on the boards I
   have access to :-/
   
   I'd just kill this and use the connector force support (and manually
   adding the right resolutions).
   
   Looks like that's a candidate for better documentation... How does force
   support work ?
  
  Grep for DRM_FORCE_ON, iirc it can be set on the commandline, where you can
  also force a specific mode. The best I could find wrt docs is the kerneldoc
  for drm_mode_parse_command_line_for_connector. With a bit more reading it
  looks like it's intermingled with the fbdev helper code, but should be
  fairly easy to extract and used by your driver.
 
 It makes sense to force the connector state from command line, but I'm not 
 sure if the same mechanism is the best solution here. As the driver has no 
 way 
 to know the connector state, the best we can do is guess what modes are 
 supported. I can just return 0 in the get_modes handler, but then the core 
 will not call drm_add_modes_noedid(), and modes will need to be added 
 manually.
 
 Is your point that for a board on which the VGA connector state can't be 
 detected, the user should always be responsible for adding all the modes 
 supported by the VGA monitor on the command line ?

My point is that we already have both an established code for
connected outputs without EDID to add fallback modes and means to force
connectors to certain states. Your code here seems to reinvent that wheel,
so I wonder what we should/need to improve in the common code to suit your
needs. A few ideas:
- Untangling the connector forcing code from the fbdev helper so that you
  can use it.
- Exposing the connector state forcing through sysfs so that it's
  runtime-adjustable.
- Adding fallback modes for connectors in the unknonw state (imo too much
  risk in breaking something else).

Thinking about this some more I'd vote for the new sysfs file to expose
connector forcing at runtime. With that it'd boil down to 1024x756 vs.
1280x768 for the default fallback mode. And that could be fixed with the
EDID quirk support. Although that looks like it would benefit from a
per-connector sysfs file, too ;-)

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 64257] RS880 issues with r600-llvm-compiler

[bugzilla-daemon]

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

--- Comment #31 from Marc Dietrich marvi...@gmx.de ---
still the same. 

chrome still shows the triangles instead of the boy in the boat (even worse
than before) and firefox does not render the boy at all.

http://www.chromeexperiments.com/detail/pearl-boy/?f=webgl

-- 
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 64257] RS880 issues with r600-llvm-compiler

[bugzilla-daemon]

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

--- Comment #32 from Andy Furniss adf.li...@gmail.com ---
(In reply to comment #30)
 Can you try this branch:
 http://cgit.freedesktop.org/~tstellar/llvm/log/?h=r600-gen-fixes
 
 I think it should fix the remaining issues.

Doesn't fix heaven or pearl boy on my rv790, though in the case of pearl boy
corruption didn't start until I dived.

-- 
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: Multiple issues with omapdrm

[Rob Clark]

On Wed, Jun 5, 2013 at 4:59 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
 Hi,

 I did some testing with omapdrm on v3.10-rc1. Here are some issues I 
 encountered.
 For most of them I don't have any idea where to even start looking for a 
 problem,
 so I hope that you may have some ideas.


 dispc_runtime_get/put used in irq context
 =

 dispc_runtime_get/put are used in irq context in omap_irq.c. I can hack
 around that with if (!in_atomic()), but I have no idea yet how to fix
 it properly.

Probably should have a flag/refcnt that is set when in the irq hander,
since we know that things are on in irq.


 drm_crtc warning
 

 I got this once when unloading the modules, but haven't happened since:

 drm_crtc.c line 3869

 WARN_ON(!list_empty(dev-mode_config.fb_list));

 As it only happened once, maybe some kind of race.


Hmm, this is new..  it is certain that there can be a fb with a
reference still around, waiting for a vblank/framedone.  But I think
it should already be removed from userspace perspective and no longer
on fb_list.  I think I need to go back and have a closer look at
2b677e8c0 where Daniel introduced that WARN_ON().

 omap_gem warning
 

 This happens on module unload:

oh, that is easy.. it is because the omap_fbdev.c does an unbalanced
omap_gem_get_paddr() to keep the fbcon fb from getting unmapped from
tiler (so if we have to restore fbcon mode in an opps, we don't have
to worry about grabbing mutexes or anything like that).  Maybe
somewhere in the cleanup it should do a put_paddr().  Otoh, I have
some skepticism about whether module unloading is really going to be
that reliable in practice, so meh..


BR,
-R


 [   30.167480] [ cut here ]
 [   30.167724] WARNING: at drivers/gpu/drm/omapdrm/omap_gem.c:1318 
 omap_gem_free_object+0x24c/0x25c [omapdrm]()
 [   30.182952] Modules linked in: omapdrm(-) drm_kms_helper drm panel_taal 
 panel_tfp410 panel_generic_dpi omapdss
 [   30.183166] CPU: 0 PID: 6 Comm: kworker/u4:0 Not tainted 
 3.10.0-rc1-4-g8ed4760 #110
 [   30.183166] Workqueue: omapdrm apply_worker [omapdrm]
 [   30.207641] Backtrace:
 [   30.210296] [c00189ac] (dump_backtrace+0x0/0x10c) from [c0018b48] 
 (show_stack+0x18/0x1c)
 [   30.219299]  r6:bf0e5988 r5:0009 r4: r3:eb872080
 [   30.225433] [c0018b30] (show_stack+0x0/0x1c) from [c0520c04] 
 (dump_stack+0x20/0x28)
 [   30.234039] [c0520be4] (dump_stack+0x0/0x28) from [c0041fb8] 
 (warn_slowpath_common+0x54/0x74)
 [   30.243530] [c0041f64] (warn_slowpath_common+0x0/0x74) from [c0041ffc] 
 (warn_slowpath_null+0x24/0x2c)
 [   30.243774]  r8:ebfab99c r7:ebb41800 r6:ebb41830 r5:ebefce40 r4:ebefce40
 r3:0009
 [   30.262176] [c0041fd8] (warn_slowpath_null+0x0/0x2c) from [bf0e5988] 
 (omap_gem_free_object+0x24c/0x25c [omapdrm])
 [   30.273498] [bf0e573c] (omap_gem_free_object+0x0/0x25c [omapdrm]) from 
 [bf080c0c] (drm_gem_object_free+0x30/0x38 [drm])
 [   30.285675] [bf080bdc] (drm_gem_object_free+0x0/0x38 [drm]) from 
 [bf0e196c] (omap_plane_post_apply+0x108/0x10c [omapdrm])
 [   30.285675] [bf0e1864] (omap_plane_post_apply+0x0/0x10c [omapdrm]) from 
 [bf0e100c] (apply_worker+0x68/0x188 [omapdrm])
 [   30.309509]  r6:ebae5c6c r5:ebae5c5c r4:ebae5c5c
 [   30.312042] [bf0e0fa4] (apply_worker+0x0/0x188 [omapdrm]) from 
 [c005ef10] (process_one_work+0x1b8/0x4e8)
 [   30.325012] [c005ed58] (process_one_work+0x0/0x4e8) from [c005f654] 
 (worker_thread+0x138/0x388)
 [   30.325378] [c005f51c] (worker_thread+0x0/0x388) from [c0066070] 
 (kthread+0xac/0xb8)
 [   30.343292] [c0065fc4] (kthread+0x0/0xb8) from [c00146e8] 
 (ret_from_fork+0x14/0x2c)
 [   30.351837]  r7: r6: r5:c0065fc4 r4:eb843d54
 [   30.352111] ---[ end trace 78317663d3b4807c ]---


 Deadlock at module unload
 =
 When removing the modules, there's a dealock. This is the last line printed:

 [   30.399200] [drm] Module unloaded

 Then, when the deadlock detection kicks in:

 [  240.962432] INFO: task rmmod:894 blocked for more than 120 seconds.
 [  240.962432] echo 0  /proc/sys/kernel/hung_task_timeout_secs disables 
 this message.
 [  240.977508] rmmod   D c0524964 0   894884 0x
 [  240.981719] Backtrace:
 [  240.987274] [c05245ec] (__schedule+0x0/0x7e8) from [c0524eb0] 
 (schedule+0x38/0x78)
 [  240.995819] [c0524e78] (schedule+0x0/0x78) from [c05251ac] 
 (schedule_preempt_disabled+0x28/0x38)
 [  241.005706] [c0525184] (schedule_preempt_disabled+0x0/0x38) from 
 [c05238c4] (mutex_lock_nested+0x1b8/0x3a8)
 [  241.016693]  r4:c07f5bf8 r3:eb978180
 [  241.020812] [c052370c] (mutex_lock_nested+0x0/0x3a8) from [c033c9d0] 
 (driver_detach+0x4c/0xc0)
 [  241.021026] [c033c984] (driver_detach+0x0/0xc0) from [c033bd24] 
 (bus_remove_driver+0x94/0xfc)
 [  241.040100]  r6:c07f5b38 r5:bf0ec410 r4: r3:
 [  241.042633] [c033bc90] (bus_remove_driver+0x0/0xfc) from [c033d054] 
 

[Bug 64257] RS880 issues with r600-llvm-compiler

[bugzilla-daemon]

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

--- Comment #33 from Marc Dietrich marvi...@gmx.de ---
looks like my chrome version (27) has a bug with coordinates, so ignore this
browser. still firefox doesn't render anything at all.

-- 
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 64257] RS880 issues with r600-llvm-compiler

[bugzilla-daemon]

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

--- Comment #34 from Mike Lothian m...@fireburn.co.uk ---
Out of interest has the previous two patches been applied upstream?

-- 
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: Multiple issues with omapdrm

[Rob Clark]

On Wed, Jun 5, 2013 at 6:43 AM, Rob Clark robdcl...@gmail.com wrote:
 On Wed, Jun 5, 2013 at 4:59 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
 Hi,

 I did some testing with omapdrm on v3.10-rc1. Here are some issues I 
 encountered.
 For most of them I don't have any idea where to even start looking for a 
 problem,
 so I hope that you may have some ideas.


 dispc_runtime_get/put used in irq context
 =

 dispc_runtime_get/put are used in irq context in omap_irq.c. I can hack
 around that with if (!in_atomic()), but I have no idea yet how to fix
 it properly.

 Probably should have a flag/refcnt that is set when in the irq hander,
 since we know that things are on in irq.


 drm_crtc warning
 

 I got this once when unloading the modules, but haven't happened since:

 drm_crtc.c line 3869

 WARN_ON(!list_empty(dev-mode_config.fb_list));

 As it only happened once, maybe some kind of race.


 Hmm, this is new..  it is certain that there can be a fb with a
 reference still around, waiting for a vblank/framedone.  But I think
 it should already be removed from userspace perspective and no longer
 on fb_list.  I think I need to go back and have a closer look at
 2b677e8c0 where Daniel introduced that WARN_ON().

 omap_gem warning
 

 This happens on module unload:

 oh, that is easy.. it is because the omap_fbdev.c does an unbalanced
 omap_gem_get_paddr() to keep the fbcon fb from getting unmapped from
 tiler (so if we have to restore fbcon mode in an opps, we don't have
 to worry about grabbing mutexes or anything like that).  Maybe
 somewhere in the cleanup it should do a put_paddr().  Otoh, I have
 some skepticism about whether module unloading is really going to be
 that reliable in practice, so meh..


by which I mean: module unloading is a nice-to-have for development,
but not a real use case.. it is more important to fix the issues we
have with module loading:

1) drmOpen(omap) will try to modprobe omap, not omapdrm so we
need to rename the .ko
2) sorting out the modprobe of panel drivers..  although with the
current structure of omapdrm+omapdss I can't think of any clean way to
handle this.  I suppose we could do a hack with a bunch of
request_module()s

these are issues that actually cause problems for distros which want
to build a unified kernel with all the drm drivers as modules

BR,
-R


 BR,
 -R


 [   30.167480] [ cut here ]
 [   30.167724] WARNING: at drivers/gpu/drm/omapdrm/omap_gem.c:1318 
 omap_gem_free_object+0x24c/0x25c [omapdrm]()
 [   30.182952] Modules linked in: omapdrm(-) drm_kms_helper drm panel_taal 
 panel_tfp410 panel_generic_dpi omapdss
 [   30.183166] CPU: 0 PID: 6 Comm: kworker/u4:0 Not tainted 
 3.10.0-rc1-4-g8ed4760 #110
 [   30.183166] Workqueue: omapdrm apply_worker [omapdrm]
 [   30.207641] Backtrace:
 [   30.210296] [c00189ac] (dump_backtrace+0x0/0x10c) from [c0018b48] 
 (show_stack+0x18/0x1c)
 [   30.219299]  r6:bf0e5988 r5:0009 r4: r3:eb872080
 [   30.225433] [c0018b30] (show_stack+0x0/0x1c) from [c0520c04] 
 (dump_stack+0x20/0x28)
 [   30.234039] [c0520be4] (dump_stack+0x0/0x28) from [c0041fb8] 
 (warn_slowpath_common+0x54/0x74)
 [   30.243530] [c0041f64] (warn_slowpath_common+0x0/0x74) from 
 [c0041ffc] (warn_slowpath_null+0x24/0x2c)
 [   30.243774]  r8:ebfab99c r7:ebb41800 r6:ebb41830 r5:ebefce40 r4:ebefce40
 r3:0009
 [   30.262176] [c0041fd8] (warn_slowpath_null+0x0/0x2c) from [bf0e5988] 
 (omap_gem_free_object+0x24c/0x25c [omapdrm])
 [   30.273498] [bf0e573c] (omap_gem_free_object+0x0/0x25c [omapdrm]) from 
 [bf080c0c] (drm_gem_object_free+0x30/0x38 [drm])
 [   30.285675] [bf080bdc] (drm_gem_object_free+0x0/0x38 [drm]) from 
 [bf0e196c] (omap_plane_post_apply+0x108/0x10c [omapdrm])
 [   30.285675] [bf0e1864] (omap_plane_post_apply+0x0/0x10c [omapdrm]) from 
 [bf0e100c] (apply_worker+0x68/0x188 [omapdrm])
 [   30.309509]  r6:ebae5c6c r5:ebae5c5c r4:ebae5c5c
 [   30.312042] [bf0e0fa4] (apply_worker+0x0/0x188 [omapdrm]) from 
 [c005ef10] (process_one_work+0x1b8/0x4e8)
 [   30.325012] [c005ed58] (process_one_work+0x0/0x4e8) from [c005f654] 
 (worker_thread+0x138/0x388)
 [   30.325378] [c005f51c] (worker_thread+0x0/0x388) from [c0066070] 
 (kthread+0xac/0xb8)
 [   30.343292] [c0065fc4] (kthread+0x0/0xb8) from [c00146e8] 
 (ret_from_fork+0x14/0x2c)
 [   30.351837]  r7: r6: r5:c0065fc4 r4:eb843d54
 [   30.352111] ---[ end trace 78317663d3b4807c ]---


 Deadlock at module unload
 =
 When removing the modules, there's a dealock. This is the last line printed:

 [   30.399200] [drm] Module unloaded

 Then, when the deadlock detection kicks in:

 [  240.962432] INFO: task rmmod:894 blocked for more than 120 seconds.
 [  240.962432] echo 0  /proc/sys/kernel/hung_task_timeout_secs disables 
 this message.
 [  240.977508] rmmod   D c0524964 0   894884 0x
 [  240.981719] Backtrace:
 [  

Re: [PATCH v2 5/5] drm: GEM CMA: Add DRM PRIME support

[Rob Clark]

On Wed, Jun 5, 2013 at 4:44 AM, Daniel Vetter dan...@ffwll.ch wrote:
 On Tue, Jun 04, 2013 at 11:05:36PM -0400, Rob Clark wrote:
 On Tue, Jun 4, 2013 at 9:22 PM, Laurent Pinchart
 laurent.pinch...@ideasonboard.com wrote:
  Hi Rob,
 
  On Tuesday 04 June 2013 17:56:36 Rob Clark wrote:
  couple small comments, other than those it looks ok
 
  Thanks for the review.
 
  On Mon, Jun 3, 2013 at 10:20 PM, Laurent Pinchart wrote:
   Signed-off-by: Laurent Pinchart
   laurent.pinchart+rene...@ideasonboard.com
   ---
  
drivers/gpu/drm/drm_gem_cma_helper.c | 321 
   +-
include/drm/drm_gem_cma_helper.h |   9 +
2 files changed, 327 insertions(+), 3 deletions(-)
  
   diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
   b/drivers/gpu/drm/drm_gem_cma_helper.c index 7a4db4e..1dc2157 100644
   --- a/drivers/gpu/drm/drm_gem_cma_helper.c
   +++ b/drivers/gpu/drm/drm_gem_cma_helper.c
   @@ -21,6 +21,9 @@
#include linux/slab.h
#include linux/mutex.h
#include linux/export.h
   +#if CONFIG_DMA_SHARED_BUFFER
   +#include linux/dma-buf.h
   +#endif
 
  I don't think we need the #if, since drm selects DMA_SHARED_BUFFER
 
  and same for other spot below
 
  Indeed. Will be fixed in the next version.
 
#include linux/dma-mapping.h
  
#include drm/drmP.h
 
  [snip]
 
   @@ -291,3 +321,288 @@ void drm_gem_cma_describe(struct 
   drm_gem_cma_object
   *cma_obj, struct seq_file *m
}
EXPORT_SYMBOL_GPL(drm_gem_cma_describe);
#endif
  
   +
   +/*
   -
    + * DMA-BUF
   + */
   +
   +#if CONFIG_DMA_SHARED_BUFFER
   +struct drm_gem_cma_dmabuf_attachment {
   +   struct sg_table sgt;
   +   enum dma_data_direction dir;
   +};
   +
   +static int drm_gem_cma_dmabuf_attach(struct dma_buf *dmabuf, struct
   device *dev, +struct
   dma_buf_attachment *attach) +{
   +   struct drm_gem_cma_dmabuf_attachment *cma_attach;
   +
   +   cma_attach = kzalloc(sizeof(*cma_attach), GFP_KERNEL);
   +   if (!cma_attach)
   +   return -ENOMEM;
   +
   +   cma_attach-dir = DMA_NONE;
   +   attach-priv = cma_attach;
   +
   +   return 0;
   +}
   +
   +static void drm_gem_cma_dmabuf_detach(struct dma_buf *dmabuf,
   + struct dma_buf_attachment *attach)
   +{
   +   struct drm_gem_cma_dmabuf_attachment *cma_attach = attach-priv;
   +   struct sg_table *sgt;
   +
   +   if (cma_attach == NULL)
   +   return;
   +
   +   sgt = cma_attach-sgt;
   +
   +   if (cma_attach-dir != DMA_NONE)
   +   dma_unmap_sg(attach-dev, sgt-sgl, sgt-nents,
   +   cma_attach-dir);
   +
   +   sg_free_table(sgt);
   +   kfree(cma_attach);
   +   attach-priv = NULL;
   +}
   +
   +static struct sg_table *
   +drm_gem_cma_dmabuf_map(struct dma_buf_attachment *attach,
   +  enum dma_data_direction dir)
   +{
   +   struct drm_gem_cma_dmabuf_attachment *cma_attach = attach-priv;
   +   struct drm_gem_cma_object *cma_obj = attach-dmabuf-priv;
   +   struct drm_device *drm = cma_obj-base.dev;
   +   struct scatterlist *rd, *wr;
   +   struct sg_table *sgt;
   +   unsigned int i;
   +   int nents, ret;
   +
   +   DRM_DEBUG_PRIME(\n);
   +
   +   if (WARN_ON(dir == DMA_NONE))
   +   return ERR_PTR(-EINVAL);
   +
   +   /* Return the cached mapping when possible. */
   +   if (cma_attach-dir == dir)
   +   return cma_attach-sgt;
   +
   +   /* Two mappings with different directions for the same 
   attachment
   are +* not allowed.
   +*/
   +   if (WARN_ON(cma_attach-dir != DMA_NONE))
   +   return ERR_PTR(-EBUSY);
   +
   +   sgt = cma_attach-sgt;
   +
   +   ret = sg_alloc_table(sgt, cma_obj-sgt-orig_nents, GFP_KERNEL);
   +   if (ret) {
   +   DRM_ERROR(failed to alloc sgt.\n);
   +   return ERR_PTR(-ENOMEM);
   +   }
   +
   +   mutex_lock(drm-struct_mutex);
   +
   +   rd = cma_obj-sgt-sgl;
   +   wr = sgt-sgl;
   +   for (i = 0; i  sgt-orig_nents; ++i) {
   +   sg_set_page(wr, sg_page(rd), rd-length, rd-offset);
   +   rd = sg_next(rd);
   +   wr = sg_next(wr);
   +   }
   +
   +   nents = dma_map_sg(attach-dev, sgt-sgl, sgt-orig_nents, dir);
   +   if (!nents) {
   +   DRM_ERROR(failed to map sgl with iommu.\n);
   +   sg_free_table(sgt);
   +   sgt = ERR_PTR(-EIO);
   +   goto done;
   +   }
   +
   +   cma_attach-dir = dir;
   +   attach-priv = cma_attach;
   +
   +   DRM_DEBUG_PRIME(buffer size = %zu\n, cma_obj-base.size);
   +
   +done:
   +   mutex_unlock(drm-struct_mutex);
   +   return sgt;
   +}
   +
   +static void 

Re: [PATCH] drm: Add kernel-doc for plane functions

[Ville Syrjälä]

On Wed, Jun 05, 2013 at 04:13:01AM +0200, Laurent Pinchart wrote:
 Hi Ville,
 
 Thank you for the patch.
 
 On Tuesday 04 June 2013 10:58:35 ville.syrj...@linux.intel.com wrote:
  From: Ville Syrjälä ville.syrj...@linux.intel.com
  
  Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
  ---
   drivers/gpu/drm/drm_crtc.c | 31 +++
   1 file changed, 31 insertions(+)
  
  diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
  index f00ba75..f1f11e1 100644
  --- a/drivers/gpu/drm/drm_crtc.c
  +++ b/drivers/gpu/drm/drm_crtc.c
  @@ -795,6 +795,21 @@ void drm_encoder_cleanup(struct drm_encoder *encoder)
   }
   EXPORT_SYMBOL(drm_encoder_cleanup);
  
  +/**
  + * drm_plane_init - Initialise a new plane object
  + * @dev: DRM device
  + * @plane: plane object to init
  + * @possible_crtcs: bitmask of possible CRTCs
  + * @funcs: callbacks for the new plane
  + * @formats: array of supported formats (%DRM_FORMAT_*)
  + * @format_count: number of elements in @formats
  + * @priv: plane is private (hidden from userspace)?
  + *
  + * Inits a new object created as base part of an driver plane object.
 
 s/an driver/a driver/

You can blame the guy who wrote the drm_crtc_init() docs :)

 
  + *
  + * RETURNS:
  + * Zero on success, error code on failure.
  + */
   int drm_plane_init(struct drm_device *dev, struct drm_plane *plane,
 unsigned long possible_crtcs,
 const struct drm_plane_funcs *funcs,
  @@ -843,6 +858,13 @@ int drm_plane_init(struct drm_device *dev, struct
  drm_plane *plane, }
   EXPORT_SYMBOL(drm_plane_init);
  
  +/**
  + * drm_plane_cleanup - Cleans up the core plane usage.
 
 Nitpicking, you could remove the full stop at the end of the line to be 
 consistent with the other two kerneldoc blocks.
 
 And s/Cleans/Clean/

Same deal here. I'll fix up the originals as well...

 
  + * @plane: plane to cleanup
  + *
  + * Cleanup @plane. Removes from drm modesetting space
  + * does NOT free object, caller does that.
 
 As this is documentation, I'd use a more verbose style.
 
 This function clean up @plane and removes it from the DRM mode setting core. 
 Note that the function does *not* free the plane structure itself, this is 
 the 
 responsibility of the caller.

Again just copy-pasted from somewhere.

 
  + */
   void drm_plane_cleanup(struct drm_plane *plane)
   {
  struct drm_device *dev = plane-dev;
  @@ -859,6 +881,15 @@ void drm_plane_cleanup(struct drm_plane *plane)
   }
   EXPORT_SYMBOL(drm_plane_cleanup);
  
  +/**
  + * drm_plane_force_disable - Forcibly disable a plane
  + * @plane: plane to disable
  + *
  + * Forces the plane to be disabled.
 
 This feels a bit unclear to me. In particular, how is force_disable 
 different from just disabling the plane ? Maybe the function should be 
 renamed 
 to drm_plane_disable(), and the documentation updated to mention that the 
 function just disables the plane and disassociate with from its frame buffer.

Normal disable would happen in response to the setplane ioctl w/ NULL
fb, whereas this guy is meant more for unsolicited disable.

I'm afraid if I call it drm_plane_disable() someone will send a patch
to call it from setplane, or people start to call it from drivers'
disable_plane hook.

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Multiple issues with omapdrm

[Rob Clark]

On Wed, Jun 5, 2013 at 7:35 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
 On 05/06/13 13:57, Rob Clark wrote:

 1) drmOpen(omap) will try to modprobe omap, not omapdrm so we
 need to rename the .ko

 Has something been changed that broke that? Or was omapdrm just a
 badly chosen name from the start? If drmOpen(omapdrm) works now,
 doesn't changing the module name break userspace compatibility?

it was broken all along, because you need to drmOpen(omap) so the
module should have been called omap.ko from the beginning

 I had a quick look at libdrm. It calls server_info-load_module() but I
 couldn't figure out where that call actually goes...

it's registered from xserver, fyi

 2) sorting out the modprobe of panel drivers..  although with the
 current structure of omapdrm+omapdss I can't think of any clean way to
 handle this.  I suppose we could do a hack with a bunch of
 request_module()s

 If omapdrm and omapdss were merged, what would be the clean way be? Or
 did you mean some other structure?

well, then we'd just build it all into one .ko

 I'm no expert on this, but my understanding is that udev (or such)
 should load the modules for the devices that the board has. If it's a
 requirement that the drm drivers are loaded only by a call to drmOpen()
 (why is that?), then maybe udev could load only the panel drivers.

I'm not quite sure the entire history offhand.. maybe drmOpen()
pre-dated that?  At any rate, the main issue is just ensuring the
panel modules (if they are split out into different .ko's) are loaded
first

BR,
-R

  Tomi


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

Re: [PATCH v3] drm: Renesas R-Car Display Unit DRM driver

[Ville Syrjälä]

On Wed, Jun 05, 2013 at 03:51:53AM +0200, Laurent Pinchart wrote:
 Hi Daniel,
 
 On Tuesday 04 June 2013 20:36:20 Daniel Vetter wrote:
  On Tue, Jun 4, 2013 at 8:03 PM, Laurent Pinchart wrote:
   On Tuesday 04 June 2013 16:12:36 Daniel Vetter wrote:
   On Tue, Jun 04, 2013 at 04:53:40AM +0200, Laurent Pinchart wrote:
 
  [snip]
  
   Should we add that to crtc helpers, instead of the current just try to
   smash the old config on top of the ill-defined hw state after a failed
   modeset?
   
   It would probably make sense to add a rollback operation to undo the
   prepare operation, or maybe just a rollback/commit flag to the commit
   operation. We would still need to smash the old config back though, as
   the rollback operation shouldn't be expected to handle encoders and
   connectors.
   
   While we're at it, shouldn't we make drivers report supported formats for
   the main frame buffer, like we do for planes ? That would allow catching
   format errors before calling the prepare operation.
  
  Yeah, I've noticed that one, too. I guess we could tackle that as part
  of an eventual make the implicit primary plane a bit more explict
  project. For now I'm not too offended by the duplication of checks.
 
 It would be nice to treat the primary plane as all the other planes. Several 
 embedded display engines don't make the primary plane special and just paint 
 the background with a plain color when the enabled planes don't cover the 
 entire display.

Same deal for some intel hardware (at least partially). Anyways, my
current plan is that we fix it for the atomic pageflip/modeset stuff.
Ie. I don't even want expose the CRTC scanout stuff in the new atomic
API.

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 65377] Backlight control via /sys/class/backlight/radeon_bl0 not working

[bugzilla-daemon]

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

--- Comment #4 from Henri Verbeet hverb...@gmail.com ---
I think it depends a bit on the specific model, but many Macs will only boot
EFI from USB. Refind (http://www.rodsbooks.com/refind/index.html) is
potentially a way around that, although I'm not entirely sure if that counts as
booting in EFI mode or in BIOS mode.

-- 
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 1/2] drm: Improve drm_crtc documentation

[ville . syrjala]

From: Ville Syrjälä ville.syrj...@linux.intel.com

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
 drivers/gpu/drm/drm_crtc.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index f00ba75..857acf2 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -585,7 +585,7 @@ EXPORT_SYMBOL(drm_framebuffer_remove);
  * @crtc: CRTC object to init
  * @funcs: callbacks for the new CRTC
  *
- * Inits a new object created as base part of an driver crtc object.
+ * Inits a new object created as base part of a driver crtc object.
  *
  * RETURNS:
  * Zero on success, error code on failure.
@@ -620,11 +620,12 @@ int drm_crtc_init(struct drm_device *dev, struct drm_crtc 
*crtc,
 EXPORT_SYMBOL(drm_crtc_init);
 
 /**
- * drm_crtc_cleanup - Cleans up the core crtc usage.
+ * drm_crtc_cleanup - Clean up the core crtc usage
  * @crtc: CRTC to cleanup
  *
- * Cleanup @crtc. Removes from drm modesetting space
- * does NOT free object, caller does that.
+ * This function cleans up @crtc and removes it from the DRM mode setting
+ * core. Note that the function does *not* free the crtc structure itself,
+ * this is the responsibility of the caller.
  */
 void drm_crtc_cleanup(struct drm_crtc *crtc)
 {
-- 
1.8.1.5

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

Re: [PATCH 1/2] drm: Improve drm_crtc documentation

[Alex Deucher]

On Wed, Jun 5, 2013 at 8:39 AM,  ville.syrj...@linux.intel.com wrote:
 From: Ville Syrjälä ville.syrj...@linux.intel.com

 Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com

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

 ---
  drivers/gpu/drm/drm_crtc.c | 9 +
  1 file changed, 5 insertions(+), 4 deletions(-)

 diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
 index f00ba75..857acf2 100644
 --- a/drivers/gpu/drm/drm_crtc.c
 +++ b/drivers/gpu/drm/drm_crtc.c
 @@ -585,7 +585,7 @@ EXPORT_SYMBOL(drm_framebuffer_remove);
   * @crtc: CRTC object to init
   * @funcs: callbacks for the new CRTC
   *
 - * Inits a new object created as base part of an driver crtc object.
 + * Inits a new object created as base part of a driver crtc object.
   *
   * RETURNS:
   * Zero on success, error code on failure.
 @@ -620,11 +620,12 @@ int drm_crtc_init(struct drm_device *dev, struct 
 drm_crtc *crtc,
  EXPORT_SYMBOL(drm_crtc_init);

  /**
 - * drm_crtc_cleanup - Cleans up the core crtc usage.
 + * drm_crtc_cleanup - Clean up the core crtc usage
   * @crtc: CRTC to cleanup
   *
 - * Cleanup @crtc. Removes from drm modesetting space
 - * does NOT free object, caller does that.
 + * This function cleans up @crtc and removes it from the DRM mode setting
 + * core. Note that the function does *not* free the crtc structure itself,
 + * this is the responsibility of the caller.
   */
  void drm_crtc_cleanup(struct drm_crtc *crtc)
  {
 --
 1.8.1.5

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

Re: [PATCH 1/3] drm/gma500: Unpin framebuffer when destroying it

[Patrik Jakobsson]

On Sun, May 26, 2013 at 11:00 PM, Daniel Vetter dan...@ffwll.ch wrote:
 On Sun, May 26, 2013 at 10:31 PM, Patrik Jakobsson
 patrik.r.jakobs...@gmail.com wrote:
 On Sun, May 26, 2013 at 9:07 PM, Daniel Vetter dan...@ffwll.ch wrote:
 On Sun, May 26, 2013 at 08:03:53PM +0200, Patrik Jakobsson wrote:
 A framebuffer is pinned when it's set as pipe base, so we also need to
 unpin it when it's destroyed. Some framebuffers are never used as
 scanout (no mode set on them) so if the pin count is less than one, no
 unpinning is needed.

 Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=889511
 Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=812113

 Signed-off-by: Patrik Jakobsson patrik.r.jakobs...@gmail.com
 ---
  drivers/gpu/drm/gma500/framebuffer.c | 5 +
  1 file changed, 5 insertions(+)

 diff --git a/drivers/gpu/drm/gma500/framebuffer.c 
 b/drivers/gpu/drm/gma500/framebuffer.c
 index 8b1b6d9..1a11b69 100644
 --- a/drivers/gpu/drm/gma500/framebuffer.c
 +++ b/drivers/gpu/drm/gma500/framebuffer.c
 @@ -668,6 +668,11 @@ static void psb_user_framebuffer_destroy(struct 
 drm_framebuffer *fb)

   /* Let DRM do its clean up */
   drm_framebuffer_cleanup(fb);
 +
 + /* Unpin any psb_intel_pipe_set_base() pinning */
 + if (r-in_gart  0)
 + psb_gtt_unpin(r);

 The drm core /should/ have removed the user framebuffer from all active
 users before it calls down into your -destroy callback. Why can't gma500
 just pin/unpin on demand when the buffer is actually in use?

 Thanks for the feedback

 DRM core does correctly keep track of the users but the last ref is dropped 
 in
 our -destroy callback and at that point it's still pinned from 
 pipe_set_base().
 So if it's considered too late to unpin the framebuffer in destroy, we never 
 had
 it right in the first place. Not a big surprise I guess :)

 If a pin survives the official use as seen by the drm core (e.g. to keep a
 buffer around until the pageflip completes) you can simply keep an
 additional reference around.

 As I wrote above, that additional reference is not dropped until -destroy
 anyways and we don't have page flipping support and to be honest I haven't 
 even
 looked at implementing it yet. So the logical point to release the pin would 
 be
 in pipe_set_base() (or am I wrong?) by doing an unpin on the old_fb. Problem 
 is
 that when killing X and switching back to fbdev we get no old_fb.

 I might be missing something, so any suggestions are welcome.

 Dumping our irc discussion for google to index here:

 I sounds like gma500 code is missing the crtc disabling sequence when
 X shuts down, i.e. the crtc on-off transition. Then when you switch
 to fbcon you only get a crtc off-on state transition and so don't see
 an old fb in set_base, which means that the pin refcount of the old
 framebuffer is lost. To fix this you can use the special call to
 crtc_funcs-disable (instead of the default crtc_funcs-dpms(OFF)) in
 drm_helper_disable_unused_functions.

Adding the disable callback when we have a fb != NULL solves the problem. It
also looks like we never turn of the cursor. Is this a good place for that as
well?

 Note that X could also do the vt switch first and then only do the
 framebuffer destruction, in which case I think your patch here would
 drop the pin reference twice: Once in set_base since we have an old_fb
 and once in the framebuffer destroy callback.

I had a check for that (gtt-in_gart  0) but still, doing it in -disable
solved that as well.

 See  intel_crtc_disable in intel_display.c in a v3.6 kernel version
 for how drm/i915 cleanup up the fb pin reference before we've reworked
 our modeset code and switched away from the crtc helpers.

Here's what it currently looks like:

---
 drivers/gpu/drm/gma500/psb_intel_display.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/gma500/psb_intel_display.c
b/drivers/gpu/drm/gma500/psb_intel_display.c
index 6e8f42b..a16b1a8 100644
--- a/drivers/gpu/drm/gma500/psb_intel_display.c
+++ b/drivers/gpu/drm/gma500/psb_intel_display.c
@@ -1150,6 +1150,18 @@ static void psb_intel_crtc_destroy(struct drm_crtc *crtc)
kfree(psb_intel_crtc);
 }

+static void psb_intel_crtc_disable(struct drm_crtc *crtc) {
+   struct gtt_range *gt;
+   struct drm_crtc_helper_funcs *crtc_funcs = crtc-helper_private;
+
+   crtc_funcs-dpms(crtc, DRM_MODE_DPMS_OFF);
+
+   if (crtc-fb) {
+   gt = to_psb_fb(crtc-fb)-gtt;
+   psb_gtt_unpin(gt);
+   }
+}
+
 const struct drm_crtc_helper_funcs psb_intel_helper_funcs = {
.dpms = psb_intel_crtc_dpms,
.mode_fixup = psb_intel_crtc_mode_fixup,
@@ -1157,6 +1169,7 @@ const struct drm_crtc_helper_funcs
psb_intel_helper_funcs = {
.mode_set_base = psb_intel_pipe_set_base,
.prepare = psb_intel_crtc_prepare,
.commit = psb_intel_crtc_commit,
+   .disable = psb_intel_crtc_disable,
 };

 const struct drm_crtc_funcs psb_intel_crtc_funcs = {
-- 

Re: [PATCH v3] drm: Renesas R-Car Display Unit DRM driver

[Alex Deucher]

On Tue, Jun 4, 2013 at 9:51 PM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
 Hi Daniel,

 On Tuesday 04 June 2013 20:36:20 Daniel Vetter wrote:
 On Tue, Jun 4, 2013 at 8:03 PM, Laurent Pinchart wrote:
  On Tuesday 04 June 2013 16:12:36 Daniel Vetter wrote:
  On Tue, Jun 04, 2013 at 04:53:40AM +0200, Laurent Pinchart wrote:

 [snip]

  Should we add that to crtc helpers, instead of the current just try to
  smash the old config on top of the ill-defined hw state after a failed
  modeset?
 
  It would probably make sense to add a rollback operation to undo the
  prepare operation, or maybe just a rollback/commit flag to the commit
  operation. We would still need to smash the old config back though, as
  the rollback operation shouldn't be expected to handle encoders and
  connectors.
 
  While we're at it, shouldn't we make drivers report supported formats for
  the main frame buffer, like we do for planes ? That would allow catching
  format errors before calling the prepare operation.

 Yeah, I've noticed that one, too. I guess we could tackle that as part
 of an eventual make the implicit primary plane a bit more explict
 project. For now I'm not too offended by the duplication of checks.

 It would be nice to treat the primary plane as all the other planes. Several
 embedded display engines don't make the primary plane special and just paint
 the background with a plain color when the enabled planes don't cover the
 entire display.

  This should use the drm_send_vblank_event helper.
 
  What bothers me about drm_send_vblank_event() is that it calls
  drm_vblank_count_and_time() with the events lock unnecessarily held. I can
  live with that for now, I'll fix the driver to use the helper.

 Most other drivers protect a bit of other state with that lock, so
 makes sense to hold it outside already. So not sure whether we should
 optimize this much ...

 Probably not :-)

   +   drm_vblank_put(dev, rcrtc-index);
   +}
 
  [snip]
 
   diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
   b/drivers/gpu/drm/rcar-du/rcar_du_drv.c new file mode 100644
   index 000..003b34e
   --- /dev/null
   +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
 
  [snip]
 
   +static void rcar_du_disable_vblank(struct drm_device *dev, int crtc)
   +{
   +   struct rcar_du_device *rcdu = dev-dev_private;
   +
   +   rcar_du_crtc_enable_vblank(rcdu-crtcs[crtc], false);
   +}
 
  Blergh, I hate our legacy vblank code which forces kms driver to jump
  through int pipe - struct drm_crtc * hoops.
 
  How would you like to fix it ? :-)

 Haven't looked at the details, but the first step I have in mind is to
 switch all drm core - driver and driver - vblank helper interfaces from
 int pipe to struct drm_crtc * pointers for kms drivers. That would allow us
 to implement at least sane locking for the vblank wait ioctl (by grabbing
 the crtc mutex).

 My plan was to split things by copypasting new kms functions and then
 garbage-collecting all unnused features for the ums code (iirc no ums driver
 ever supported more than 2 crtcs, vblank events or high-precision
 timestamps).

 Once that's in place we can look into more stuff. One of the things I want
 to play with is support for hw timestamp and vblank counters (also for
 pageflips). Then we don't have to enable the vblank interrupt so often and
 more important should be able to turn it of right away without loosing
 precision due to the potential vblank irq vs. vblank irq off race.

  where i counts encoders to say that you can clone itself (userspace might
  get confused, haven't checked how throughout the modeset ddx is). But it
  sounds like rcar can clone encoders pretty freely (as long as they're
  using crtc 0), so maybe you want to use something like drm/i915 does?
 
  The device has two outputs, 0 and 1. Output 0 can be driven by CRTC 0
  only, and output 1 can be driven by CRTC 0 or CRTC 1.

 Ah, that explains it, I've missed the context that we only have 2
 crtc/encoder pairs ;-)

 It wasn't particularly explicit :-)

  We smash all cloneable encoders into one groub with a
  intel_encoder-cloneable flag and then allow cloning any cloneable
  encoder to any other cloneable encoder with intel_encoder_clones in
  intel_display.c
 
  possible_clones is a bit a ill-defined part of the kms api, but I think
  we still should strive for consistency. Maybe the modesetting ddx should
  also grow a warning if the possible_clones mask doesn't make too much
  sense.
 
  I haven't been able to find an authoritative source of documentation
  regarding whether the possible_clones field should include the encoder
  itself. That should definitely be documented, I can fix the driver
  accordingly.

 Yeah, sounds like something worth clarifying. I'd vote for the self-clone
 bit to be set (I'm biased though, that's what i915 does). I guess we could
 even enforce consistency by putting this into the drm encoders.

 I don't have a strong opinion on the color of this particular bikeshed, 

Re: [RFC][PATCH 1/2] dma-buf: add importer private data to attachment

[Maarten Lankhorst]

Op 31-05-13 10:54, Seung-Woo Kim schreef:
 dma-buf attachment has only exporter private data, but importer private data
 can be useful for importer especially to re-import the same dma-buf.
 To use importer private data in attachment of the device, the function to
 search attachment in the attachment list of dma-buf is also added.

 Signed-off-by: Seung-Woo Kim sw0312@samsung.com
 ---
  drivers/base/dma-buf.c  |   31 +++
  include/linux/dma-buf.h |4 
  2 files changed, 35 insertions(+), 0 deletions(-)

 diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
 index 08fe897..a1eaaf2 100644
 --- a/drivers/base/dma-buf.c
 +++ b/drivers/base/dma-buf.c
 @@ -259,6 +259,37 @@ err_attach:
  EXPORT_SYMBOL_GPL(dma_buf_attach);
  
  /**
 + * dma_buf_get_attachment - Get attachment with the device from dma_buf's
 + * attachments list
 + * @dmabuf:  [in]buffer to find device from.
 + * @dev: [in]device to be found.
 + *
 + * Returns struct dma_buf_attachment * attaching the device; may return
 + * negative error codes.
 + *
 + */
 +struct dma_buf_attachment *dma_buf_get_attachment(struct dma_buf *dmabuf,
 +   struct device *dev)
 +{
 + struct dma_buf_attachment *attach;
 +
 + if (WARN_ON(!dmabuf || !dev))
 + return ERR_PTR(-EINVAL);
 +
 + mutex_lock(dmabuf-lock);
 + list_for_each_entry(attach, dmabuf-attachments, node) {
 + if (attach-dev == dev) {
 + mutex_unlock(dmabuf-lock);
 + return attach;
 + }
 + }
 + mutex_unlock(dmabuf-lock);
 +
 + return ERR_PTR(-ENODEV);
 +}
 +EXPORT_SYMBOL_GPL(dma_buf_get_attachment);
NAK in any form..

Spot the race condition between dma_buf_get_attachment and dma_buf_attach

~Maarten

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

[Bug 65416] New: r300g does not eliminate unread varyings

[bugzilla-daemon]

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

  Priority: medium
Bug ID: 65416
  Assignee: dri-devel@lists.freedesktop.org
   Summary: r300g does not eliminate unread varyings
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: stefandoesin...@gmx.at
  Hardware: Other
Status: NEW
   Version: git
 Component: Drivers/Gallium/r300
   Product: Mesa

Created attachment 80344
  -- https://bugs.freedesktop.org/attachment.cgi?id=80344action=edit
Example shaders

r300g tries to interpolate varyings written by the vertex shader even if the
fragment shader does not read them. The attached program code illustrates this
with two sample shaders.

The shaders in question were generated by Wine's fixed function pipeline
replacement, generated from a fixed function setup set up by 3DMark 2000.

The visible issues caused by this are broken fog because the driver runs out of
varyings and reduced performance due to the extra shader instructions.

An argument could be made that this is Wine's bug, and it should not generate
such inefficient shaders. Doing this would be a major inconvenience though
because the vertex and fragment shader are generated independently. As far as I
can see the proprietary drivers optimize this inefficiency away.

-- 
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 65416] r300g does not eliminate unread varyings

[bugzilla-daemon]

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

--- Comment #1 from Stefan Dösinger stefandoesin...@gmx.at ---
Fwiw, I don't know if r600g is affected. The HW has enough varyings to run the
unoptimized shaders, and the applications affected by this performance wise are
CPU limited on my r600g system.

Wine has some checks to prevent writing texture coordinates in the vertex
shader when there is no input to generate them. Unfortunately 3DMark 2000 and
Unreal Tournament 2004 use a strange vertex processing setup that breaks those
checks(D3DTSS_TEXCOORDINDEX of all texture stages is 0, thus they're reading
the first texture coordinate input, which does exist).

-- 
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 65416] r300g does not eliminate unread varyings

[bugzilla-daemon]

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

--- Comment #2 from Alex Deucher ag...@yahoo.com ---
Couldn't this be done in a device independent manner in mesa when linking
shaders?  Drop outputs if there is no matching input in the subsequent shader
stage?

-- 
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: Multiple issues with omapdrm

[Rob Clark]

On Wed, Jun 5, 2013 at 8:16 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
 On 05/06/13 14:52, Rob Clark wrote:
 On Wed, Jun 5, 2013 at 7:35 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
 On 05/06/13 13:57, Rob Clark wrote:

 1) drmOpen(omap) will try to modprobe omap, not omapdrm so we
 need to rename the .ko

 Has something been changed that broke that? Or was omapdrm just a
 badly chosen name from the start? If drmOpen(omapdrm) works now,
 doesn't changing the module name break userspace compatibility?

 it was broken all along, because you need to drmOpen(omap) so the
 module should have been called omap.ko from the beginning

 But it wasn't, so wouldn't changing it break userspace compatibility?

could be udev or something else was triggering the module to load?
Not 100% sure offhand.

 Why do you need drmOpen(omap)? Is it just a convention to use that
 kind of name, instead of omapdrm style name?

all of the /dev/dri/cardN get opened, and then DRM_IOCTL_VERSION ioctl
to get the driver name/version, which is compared against the name
passed in to drmOpen().  So drmOpen(omapdrm) shouldn't really work

 I had a quick look at libdrm. It calls server_info-load_module() but I
 couldn't figure out where that call actually goes...

 it's registered from xserver, fyi

 Ah ok. So in my testing, running without X, there's actually no module
 loading happening. The test tools print something like trying to load
 module omapdrm...success. but I guess that only means that the module
 is already there.

right

 2) sorting out the modprobe of panel drivers..  although with the
 current structure of omapdrm+omapdss I can't think of any clean way to
 handle this.  I suppose we could do a hack with a bunch of
 request_module()s

 If omapdrm and omapdss were merged, what would be the clean way be? Or
 did you mean some other structure?

 well, then we'd just build it all into one .ko

 So you didn't actually mean omapdrm+omapdss, but omapdrm + omapdss +
 all-the-panel-drivers? And then have some kind of forced method to probe
 the panels at omapdrm start?

oh, yeah.  Probably whenever I say 'omapdss' I actually mean
'everything under drivers/video/omap2 except omapfb'

 That would be quite a horrible solution, in my opinion =). It would also
 be even worse when we get platform independent panel drivers, as all the
 drm drivers using those panel drivers would include all the panel drivers.

yeah, it isn't really ideal.. really we'd want them as separate
modules but some sort of dependency to ensure that the panel drivers
actually get loaded.

 I'm no expert on this, but my understanding is that udev (or such)
 should load the modules for the devices that the board has. If it's a
 requirement that the drm drivers are loaded only by a call to drmOpen()
 (why is that?), then maybe udev could load only the panel drivers.

 I'm not quite sure the entire history offhand.. maybe drmOpen()
 pre-dated that?  At any rate, the main issue is just ensuring the
 panel modules (if they are split out into different .ko's) are loaded
 first

 I think there should be a core display facility in the kernel to which
 the panel drivers register the displays in probe().

 At boot time udev would go through /sys, find the panel devices somehow
 (how? modalias is probably somehow involved..), and load their
 respective modules.

 Later, when X is started, omapdrm and omapdss are loaded, and at that
 point all the panels are already there.

yeah, as long as we get the panels (and encoders/bridges/etc) loaded
first, I think it should be ok..

I'm not hugely fond of having it split out of drm, since I think that
just results extra layering and glue, and it makes it harder to
iteratively evolve the infrastructure for sharing panel stuff via
different trees from drm.  But that is a different discussion and is
mostly about where the code lives.

BR,
-R

  Tomi


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

[PATCH] drm: Avoid forcing a detection cycle following a hotplug event

[Chris Wilson]

The typical procedure after a hotplug event is then to enumerate all the
new modes. In the existing code, this is achieved by performing a forced
detection cycle over all connectors. Ideally, we should just be able to
use the current detection status and only enumerate the modes on the
connectors that changed. This is a step in that direction by teaching
the hotplug path to only use the known detection status rather than
performing a second *forced* detection on every connector. As it
currently stands, the first thing userspace does upon receipt of a
hotplug uevent is call DRM_IOCTL_MODE_GETCONNECTOR on each connector,
which of course, performs another full detection cycle.

Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: dri-devel@lists.freedesktop.org
Cc: Jakob Bornecrantz ja...@vmware.com
Cc: Inki Dae inki@samsung.com
Cc: Adam Jackson a...@redhat.com
---
 drivers/gpu/drm/drm_crtc.c|3 ++-
 drivers/gpu/drm/drm_crtc_helper.c |8 ++--
 drivers/gpu/drm/drm_fb_helper.c   |   14 --
 drivers/gpu/drm/exynos/exynos_drm_connector.c |7 ---
 drivers/gpu/drm/i2c/ch7006_drv.c  |2 +-
 drivers/gpu/drm/nouveau/dispnv04/tvnv17.c |2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c   |3 ++-
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.h   |3 ++-
 include/drm/drm_crtc.h|2 +-
 include/drm/drm_crtc_helper.h |2 +-
 10 files changed, 28 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index e7e9242..635276c 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1537,7 +1537,8 @@ int drm_mode_getconnector(struct drm_device *dev, void 
*data,
if (out_resp-count_modes == 0) {
connector-funcs-fill_modes(connector,
 dev-mode_config.max_width,
-dev-mode_config.max_height);
+dev-mode_config.max_height,
+true);
}
 
/* delayed so we get modes regardless of pre-fill_modes state */
diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index ed1334e..7f2128c 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -96,6 +96,9 @@ static void drm_mode_validate_flag(struct drm_connector 
*connector,
  * @connector: connector to probe
  * @maxX: max width for modes
  * @maxY: max height for modes
+ * @force: whether to use the cached connector status or to force a
+ * fresh detection cycle, for instance after a hotplug event, we
+ * want to simply use the known status.
  *
  * LOCKING:
  * Caller must hold mode config lock.
@@ -113,7 +116,8 @@ static void drm_mode_validate_flag(struct drm_connector 
*connector,
  * Number of modes found on @connector.
  */
 int drm_helper_probe_single_connector_modes(struct drm_connector *connector,
-   uint32_t maxX, uint32_t maxY)
+   uint32_t maxX, uint32_t maxY,
+   bool force)
 {
struct drm_device *dev = connector-dev;
struct drm_display_mode *mode;
@@ -136,7 +140,7 @@ int drm_helper_probe_single_connector_modes(struct 
drm_connector *connector,
connector-status = connector_status_disconnected;
if (connector-funcs-force)
connector-funcs-force(connector);
-   } else {
+   } else if (force) {
connector-status = connector-funcs-detect(connector, true);
}
 
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index b78cbe7..3e0802d 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1087,8 +1087,8 @@ void drm_fb_helper_fill_var(struct fb_info *info, struct 
drm_fb_helper *fb_helpe
 EXPORT_SYMBOL(drm_fb_helper_fill_var);
 
 static int drm_fb_helper_probe_connector_modes(struct drm_fb_helper *fb_helper,
-  uint32_t maxX,
-  uint32_t maxY)
+  uint32_t maxX, uint32_t maxY,
+  bool force)
 {
struct drm_connector *connector;
int count = 0;
@@ -1096,7 +1096,7 @@ static int drm_fb_helper_probe_connector_modes(struct 
drm_fb_helper *fb_helper,
 
for (i = 0; i  fb_helper-connector_count; i++) {
connector = fb_helper-connector_info[i]-connector;
-   count += connector-funcs-fill_modes(connector, maxX, maxY);
+   count += connector-funcs-fill_modes(connector, maxX, maxY, 
force);
}
 
return count;
@@ -1510,7 +1510,8 @@ bool drm_fb_helper_initial_config(struct 

Multiple issues with omapdrm

[Tomi Valkeinen]

Hi,

I did some testing with omapdrm on v3.10-rc1. Here are some issues I 
encountered.
For most of them I don't have any idea where to even start looking for a 
problem,
so I hope that you may have some ideas.


dispc_runtime_get/put used in irq context
=

dispc_runtime_get/put are used in irq context in omap_irq.c. I can hack
around that with if (!in_atomic()), but I have no idea yet how to fix
it properly.

drm_crtc warning


I got this once when unloading the modules, but haven't happened since:

drm_crtc.c line 3869

WARN_ON(!list_empty(dev-mode_config.fb_list));

As it only happened once, maybe some kind of race.


omap_gem warning


This happens on module unload:

[   30.167480] [ cut here ]
[   30.167724] WARNING: at drivers/gpu/drm/omapdrm/omap_gem.c:1318 
omap_gem_free_object+0x24c/0x25c [omapdrm]()
[   30.182952] Modules linked in: omapdrm(-) drm_kms_helper drm panel_taal 
panel_tfp410 panel_generic_dpi omapdss
[   30.183166] CPU: 0 PID: 6 Comm: kworker/u4:0 Not tainted 
3.10.0-rc1-4-g8ed4760 #110
[   30.183166] Workqueue: omapdrm apply_worker [omapdrm]
[   30.207641] Backtrace: 
[   30.210296] [c00189ac] (dump_backtrace+0x0/0x10c) from [c0018b48] 
(show_stack+0x18/0x1c)
[   30.219299]  r6:bf0e5988 r5:0009 r4: r3:eb872080
[   30.225433] [c0018b30] (show_stack+0x0/0x1c) from [c0520c04] 
(dump_stack+0x20/0x28)
[   30.234039] [c0520be4] (dump_stack+0x0/0x28) from [c0041fb8] 
(warn_slowpath_common+0x54/0x74)
[   30.243530] [c0041f64] (warn_slowpath_common+0x0/0x74) from [c0041ffc] 
(warn_slowpath_null+0x24/0x2c)
[   30.243774]  r8:ebfab99c r7:ebb41800 r6:ebb41830 r5:ebefce40 r4:ebefce40
r3:0009
[   30.262176] [c0041fd8] (warn_slowpath_null+0x0/0x2c) from [bf0e5988] 
(omap_gem_free_object+0x24c/0x25c [omapdrm])
[   30.273498] [bf0e573c] (omap_gem_free_object+0x0/0x25c [omapdrm]) from 
[bf080c0c] (drm_gem_object_free+0x30/0x38 [drm])
[   30.285675] [bf080bdc] (drm_gem_object_free+0x0/0x38 [drm]) from 
[bf0e196c] (omap_plane_post_apply+0x108/0x10c [omapdrm])
[   30.285675] [bf0e1864] (omap_plane_post_apply+0x0/0x10c [omapdrm]) from 
[bf0e100c] (apply_worker+0x68/0x188 [omapdrm])
[   30.309509]  r6:ebae5c6c r5:ebae5c5c r4:ebae5c5c
[   30.312042] [bf0e0fa4] (apply_worker+0x0/0x188 [omapdrm]) from 
[c005ef10] (process_one_work+0x1b8/0x4e8)
[   30.325012] [c005ed58] (process_one_work+0x0/0x4e8) from [c005f654] 
(worker_thread+0x138/0x388)
[   30.325378] [c005f51c] (worker_thread+0x0/0x388) from [c0066070] 
(kthread+0xac/0xb8)
[   30.343292] [c0065fc4] (kthread+0x0/0xb8) from [c00146e8] 
(ret_from_fork+0x14/0x2c)
[   30.351837]  r7: r6: r5:c0065fc4 r4:eb843d54
[   30.352111] ---[ end trace 78317663d3b4807c ]---


Deadlock at module unload
=
When removing the modules, there's a dealock. This is the last line printed:

[   30.399200] [drm] Module unloaded

Then, when the deadlock detection kicks in:

[  240.962432] INFO: task rmmod:894 blocked for more than 120 seconds.
[  240.962432] echo 0  /proc/sys/kernel/hung_task_timeout_secs disables this 
message.
[  240.977508] rmmod   D c0524964 0   894884 0x
[  240.981719] Backtrace: 
[  240.987274] [c05245ec] (__schedule+0x0/0x7e8) from [c0524eb0] 
(schedule+0x38/0x78)
[  240.995819] [c0524e78] (schedule+0x0/0x78) from [c05251ac] 
(schedule_preempt_disabled+0x28/0x38)
[  241.005706] [c0525184] (schedule_preempt_disabled+0x0/0x38) from 
[c05238c4] (mutex_lock_nested+0x1b8/0x3a8)
[  241.016693]  r4:c07f5bf8 r3:eb978180
[  241.020812] [c052370c] (mutex_lock_nested+0x0/0x3a8) from [c033c9d0] 
(driver_detach+0x4c/0xc0)
[  241.021026] [c033c984] (driver_detach+0x0/0xc0) from [c033bd24] 
(bus_remove_driver+0x94/0xfc)
[  241.040100]  r6:c07f5b38 r5:bf0ec410 r4: r3:
[  241.042633] [c033bc90] (bus_remove_driver+0x0/0xfc) from [c033d054] 
(driver_unregister+0x58/0x78)
[  241.056060]  r6:c07c28a4 r5:bf0ec410 r4: r3:eb978180
[  241.062164] [c033cffc] (driver_unregister+0x0/0x78) from [c033ddc0] 
(platform_driver_unregister+0x14/0x18)
[  241.072875]  r5:bf0ebc18 r4:c07c2860
[  241.075439] [c033ddac] (platform_driver_unregister+0x0/0x18) from 
[bf0df2c8] (pdev_remove+0x48/0x54 [omapdrm])
[  241.087921] [bf0df280] (pdev_remove+0x0/0x54 [omapdrm]) from [c033dc38] 
(platform_drv_remove+0x20/0x24)
[  241.098327]  r4:c07c2870 r3:bf0df280
[  241.100860] [c033dc18] (platform_drv_remove+0x0/0x24) from [c033bfc4] 
(__device_release_driver+0x78/0xd4)
[  241.112792] [c033bf4c] (__device_release_driver+0x0/0xd4) from 
[c033ca40] (driver_detach+0xbc/0xc0)
[  241.113159]  r5:bf0ebc18 r4:c07c2870
[  241.122833] [c033c984] (driver_detach+0x0/0xc0) from [c033bd24] 
(bus_remove_driver+0x94/0xfc)
[  241.136108]  r6:c07f5b38 r5:bf0ebc18 r4: r3:
[  241.142211] [c033bc90] (bus_remove_driver+0x0/0xfc) from [c033d054] 
(driver_unregister+0x58/0x78)
[  241.152069]  r6:0880 

Re: Multiple issues with omapdrm

[Tomi Valkeinen]

On 05/06/13 13:43, Rob Clark wrote:
 On Wed, Jun 5, 2013 at 4:59 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
 Hi,

 I did some testing with omapdrm on v3.10-rc1. Here are some issues I 
 encountered.
 For most of them I don't have any idea where to even start looking for a 
 problem,
 so I hope that you may have some ideas.


 dispc_runtime_get/put used in irq context
 =

 dispc_runtime_get/put are used in irq context in omap_irq.c. I can hack
 around that with if (!in_atomic()), but I have no idea yet how to fix
 it properly.
 
 Probably should have a flag/refcnt that is set when in the irq hander,
 since we know that things are on in irq.

Maybe.

However, I'd like more an approach where the dispc registers are only
programmed when a display is enabled. If the display in question is
disabled, no registers would be written.

I think that would also support losing DISPC register context. The DISPC
driver currently stores all its registers when the pm_runtime refcount
goes to 0, and restores them on pm_runtime_get. That's a bit heavy, and
uses the OMAP specific ctx-loss-count support, which should be removed
(and if that's removed, the register save/restore becomes even heavier).

Things would be simpler if omapdrm (and omapfb) knows how to program all
the relevant registers when a display is enabled, and keeps the
necessary state stored in memory (including irq settings).

 somewhere in the cleanup it should do a put_paddr().  Otoh, I have
 some skepticism about whether module unloading is really going to be
 that reliable in practice, so meh..

Why is that?

 Tomi




signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Multiple issues with omapdrm

[Tomi Valkeinen]

On 05/06/13 13:57, Rob Clark wrote:

 1) drmOpen(omap) will try to modprobe omap, not omapdrm so we
 need to rename the .ko

Has something been changed that broke that? Or was omapdrm just a
badly chosen name from the start? If drmOpen(omapdrm) works now,
doesn't changing the module name break userspace compatibility?

I had a quick look at libdrm. It calls server_info-load_module() but I
couldn't figure out where that call actually goes...

 2) sorting out the modprobe of panel drivers..  although with the
 current structure of omapdrm+omapdss I can't think of any clean way to
 handle this.  I suppose we could do a hack with a bunch of
 request_module()s

If omapdrm and omapdss were merged, what would be the clean way be? Or
did you mean some other structure?

I'm no expert on this, but my understanding is that udev (or such)
should load the modules for the devices that the board has. If it's a
requirement that the drm drivers are loaded only by a call to drmOpen()
(why is that?), then maybe udev could load only the panel drivers.

 Tomi




signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Multiple issues with omapdrm

[Tomi Valkeinen]

On 05/06/13 14:52, Rob Clark wrote:
 On Wed, Jun 5, 2013 at 7:35 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
 On 05/06/13 13:57, Rob Clark wrote:

 1) drmOpen(omap) will try to modprobe omap, not omapdrm so we
 need to rename the .ko

 Has something been changed that broke that? Or was omapdrm just a
 badly chosen name from the start? If drmOpen(omapdrm) works now,
 doesn't changing the module name break userspace compatibility?
 
 it was broken all along, because you need to drmOpen(omap) so the
 module should have been called omap.ko from the beginning

But it wasn't, so wouldn't changing it break userspace compatibility?

Why do you need drmOpen(omap)? Is it just a convention to use that
kind of name, instead of omapdrm style name?

 I had a quick look at libdrm. It calls server_info-load_module() but I
 couldn't figure out where that call actually goes...
 
 it's registered from xserver, fyi

Ah ok. So in my testing, running without X, there's actually no module
loading happening. The test tools print something like trying to load
module omapdrm...success. but I guess that only means that the module
is already there.

 2) sorting out the modprobe of panel drivers..  although with the
 current structure of omapdrm+omapdss I can't think of any clean way to
 handle this.  I suppose we could do a hack with a bunch of
 request_module()s

 If omapdrm and omapdss were merged, what would be the clean way be? Or
 did you mean some other structure?
 
 well, then we'd just build it all into one .ko

So you didn't actually mean omapdrm+omapdss, but omapdrm + omapdss +
all-the-panel-drivers? And then have some kind of forced method to probe
the panels at omapdrm start?

That would be quite a horrible solution, in my opinion =). It would also
be even worse when we get platform independent panel drivers, as all the
drm drivers using those panel drivers would include all the panel drivers.

 I'm no expert on this, but my understanding is that udev (or such)
 should load the modules for the devices that the board has. If it's a
 requirement that the drm drivers are loaded only by a call to drmOpen()
 (why is that?), then maybe udev could load only the panel drivers.
 
 I'm not quite sure the entire history offhand.. maybe drmOpen()
 pre-dated that?  At any rate, the main issue is just ensuring the
 panel modules (if they are split out into different .ko's) are loaded
 first

I think there should be a core display facility in the kernel to which
the panel drivers register the displays in probe().

At boot time udev would go through /sys, find the panel devices somehow
(how? modalias is probably somehow involved..), and load their
respective modules.

Later, when X is started, omapdrm and omapdss are loaded, and at that
point all the panels are already there.

 Tomi




signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 65270] CAICOS [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!

[bugzilla-daemon]

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

--- Comment #5 from Christian König deathsim...@vodafone.de ---
(In reply to comment #4)
 (In reply to comment #1)
  Make sure you've installed the updated rlc and uvd microcode and that it is
  available to the driver during boot (in your initrd, etc.).  You can grab
  the latest ucode here:
  http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git
  or here:
  http://people.freedesktop.org/~agd5f/radeon_ucode/
  You need BTC_rlc.bin and SUMO_uvd.bin for UVD on your chip.
 
 Yeah, I grabbed those already otherwise the update of the initrd starts
 complaining they are missing.

You not only need the new one the initrd updater is complaining about, you also
need the new RLC firmware. Otherwise the hardware would produce exactly the
error you are describing.

Please double check that you got the right versions of the firmware files.

-- 
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 65274] TURKS [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! (non-EFI laptop)

[bugzilla-daemon]

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

--- Comment #4 from Christian König deathsim...@vodafone.de ---
For TURKS you need to update BTC_rlc.bin, not SUMO_rlc.bin.

Only the SUMO UVD firmware is used for both generations.

-- 
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/exynos: fimd: Get signal polarities from device tree

[Tomasz Figa]

On Wednesday 01 of May 2013 21:06:09 Tomasz Figa wrote:
 This patch modifies the driver to perform two stage parsing of video
 timings from device tree, to get timing information as struct videomode,
 which contains more data than struct fb_videomode.
 
 Thanks to this change, information about polarity of control signals
 (VSYNC, HSYNC, VDEN, VCLK) can be retrieved, in addition to standard
 video timings.
 
 Signed-off-by: Tomasz Figa tomasz.f...@gmail.com
 ---
  drivers/gpu/drm/exynos/exynos_drm_fimd.c | 18 --
  1 file changed, 16 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
 b/drivers/gpu/drm/exynos/exynos_drm_fimd.c index a1669d4..9023efa
 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
 @@ -21,7 +21,9 @@
  #include linux/pm_runtime.h
 
  #include video/of_display_timing.h
 +#include video/of_videomode.h
  #include video/samsung_fimd.h
 +#include video/videomode.h
  #include drm/exynos_drm.h
 
  #include exynos_drm_drv.h
 @@ -928,18 +930,30 @@ static int fimd_probe(struct platform_device
 *pdev) DRM_DEBUG_KMS(%s\n, __FILE__);
 
   if (pdev-dev.of_node) {
 + struct videomode vm;
 +
   pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
   if (!pdata) {
   DRM_ERROR(memory allocation for pdata failed\n);
   return -ENOMEM;
   }
 
 - ret = of_get_fb_videomode(dev-of_node, pdata-
panel.timing,
 - OF_USE_NATIVE_MODE);
 + ret = of_get_videomode(dev-of_node, vm, 
OF_USE_NATIVE_MODE);
   if (ret) {
   DRM_ERROR(failed: of_get_fb_videomode() : %d\n, 
ret);
   return ret;
   }
 +
 + fb_videomode_from_videomode(vm, pdata-panel.timing);
 +
 + if (vm.flags  DISPLAY_FLAGS_VSYNC_LOW)
 + pdata-vidcon1 |= VIDCON1_INV_VSYNC;
 + if (vm.flags  DISPLAY_FLAGS_HSYNC_LOW)
 + pdata-vidcon1 |= VIDCON1_INV_HSYNC;
 + if (vm.flags  DISPLAY_FLAGS_DE_LOW)
 + pdata-vidcon1 |= VIDCON1_INV_VDEN;
 + if (vm.flags  DISPLAY_FLAGS_PIXDATA_NEGEDGE)
 + pdata-vidcon1 |= VIDCON1_INV_VCLK;
   } else {
   pdata = pdev-dev.platform_data;
   if (!pdata) {

Ping.

Best regards,
Tomasz

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

Re: [PATCH 0/4] drm/exynos: fimd: Add support for S3C6400/S3C6410

[Tomasz Figa]

On Sunday 19 of May 2013 13:26:57 Tomasz Figa wrote:
 Hi,
 
 On Wednesday 01 of May 2013 21:02:25 Tomasz Figa wrote:
  Much of the code in Exynos DRM subsystem is generic enough to use
  it for older (non-Exynos) Samsung SoCs as well, after minor
  modifications.
  
  This series starts adding support for previous SoCs to Exynos DRM by
  introducing S3C64xx support to exynos_drm_fimd driver.
  
  Adding support for remaining SoCs between S3C64xx and Exynos4
  (S5PC100,
  S5P64x0 and S5PV210) should be rather straightforward, but at the
  moment I can test only on S3C6410, so I limited my changes only to
  this SoC.
  
  On Tiny6410 (Mini6410-compatible) board based on Samsung S3C6410 SoC,
  using my to-be-resubmitted patches for Device Tree support:
  
  Tested-by: Tomasz Figa tomasz.f...@gmail.com
  
  Tomasz Figa (4):
drm/exynos: fimd: Hold pointer to driver data in context struct
drm/exynos: fimd: Add support for FIMD versions without SHADOWCON

  register

drm/exynos: fimd: Add support for FIMD variants with clock selection
drm/exynos: fimd: Add support for S3C64xx SoCs
   
   drivers/gpu/drm/exynos/exynos_drm_fimd.c | 90
  
   1 file changed, 68 insertions(+), 22
  deletions(-)
 
 Any comments for this series?
 
 Best regards,
 Tomasz

Ping.

Best regards,
Tomasz

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

[Bug 65274] TURKS [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! (non-EFI laptop)

[bugzilla-daemon]

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

--- Comment #5 from russianneuroman...@ya.ru ---
 For TURKS you need to update BTC_rlc.bin, not SUMO_rlc.bin.
Ok, I update BTC_rlc.bin: ~$ md5sum /lib/firmware/radeon/BTC_rlc.bin
25d61fad839b30b263f52328c1f678fb  /lib/firmware/radeon/BTC_rlc.bin
But there is same error on reboot:
 [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!

Also I just understand - I probably upload UVD regs of working UVD module of
first GPU, and for UVD regs of second GPU you probably need regs from different
addresses, right?

-- 
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 65270] CAICOS [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!

[bugzilla-daemon]

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

--- Comment #6 from Gerben Welter ger...@welter.nu ---
(In reply to comment #5)
 You not only need the new one the initrd updater is complaining about, you
 also need the new RLC firmware. Otherwise the hardware would produce exactly
 the error you are describing.
 
 Please double check that you got the right versions of the firmware files.

Ahh, I hadn't noticed the already present files had been updated. I
redownloaded all the *.bin files and updated the initrd. UVD now intializes.
Thank you for your help.

-- 
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 65270] CAICOS [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!

[bugzilla-daemon]

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

Gerben Welter ger...@welter.nu changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #7 from Gerben Welter ger...@welter.nu ---
Closing as invalid because of PEBCAK error.

-- 
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/mgag200: Hardware cursor support

[Christopher Harvey]

G200 cards support, at best, 16 colour palleted images for the cursor
so we do a conversion in the cursor_set function, and reject cursors
with more than 16 colours, or cursors with partial transparency. Xorg
falls back gracefully to software cursors in this case.

We can't disable/enable the cursor hardware without causing momentary
corruption around the cursor. Instead, once the cursor is on we leave
it on, and simulate turning the cursor off by moving it
offscreen. This works well.

Since we can't disable - update - enable the cursors, we double
buffer cursor icons, then just move the base address that points to
the old cursor, to the new. This also works well, but uses an extra
page of memory.

The cursor buffers are lazily-allocated on first cursor_set. This is
to make sure they don't take priority over any framebuffers in case of
limited memory.

Here is a representation of how the bitmap for the cursor is mapped in G200 
memory :

  Each line of color cursor use 6 Slices of 8 bytes. Slices 0 to 3
  are used for the 4bpp bitmap, slice 4 for XOR mask and slice 5 for
  AND mask. Each line has the following format:

  //  Byte 0  Byte 1  Byte 2  Byte 3  Byte 4  Byte 5  Byte 6 Byte 7
  //
  // S0:  P00-01  P02-03  P04-05  P06-07  P08-09  P10-11  P12-13 P14-15
  // S1:  P16-17  P18-19  P20-21  P22-23  P24-25  P26-27  P28-29 P30-31
  // S2:  P32-33  P34-35  P36-37  P38-39  P40-41  P42-43  P44-45 P46-47
  // S3:  P48-49  P50-51  P52-53  P54-55  P56-57  P58-59  P60-61 P62-63
  // S4:  X63-56  X55-48  X47-40  X39-32  X31-24  X23-16  X15-08 X07-00
  // S5:  A63-56  A55-48  A47-40  A39-32  A31-24  A23-16  A15-08 A07-00
  //
  //   S0 to S5  = Slices 0 to 5
  //   P00 to P63= Bitmap - pixels 0 to 63
  //   X00 to X63= always 0 - pixels 0 to 63
  //   A00 to A63= transparent markers - pixels 0 to 63
  //   1 means colour, 0 means transparent

Signed-off-by: Christopher Harvey char...@matrox.com
Signed-off-by: Mathieu Larouche mathieu.larou...@matrox.com
Acked-by: Julia Lemire jlem...@matrox.com
Tested-by: Julia Lemire jlem...@matrox.com
---
 drivers/gpu/drm/mgag200/Makefile |   2 +-
 drivers/gpu/drm/mgag200/mgag200_cursor.c | 275 +++
 drivers/gpu/drm/mgag200/mgag200_drv.h|  21 +++
 drivers/gpu/drm/mgag200/mgag200_main.c   |  21 ++-
 drivers/gpu/drm/mgag200/mgag200_mode.c   |   2 +
 drivers/gpu/drm/mgag200/mgag200_reg.h|   6 +-
 6 files changed, 324 insertions(+), 3 deletions(-)
 create mode 100644 drivers/gpu/drm/mgag200/mgag200_cursor.c

diff --git a/drivers/gpu/drm/mgag200/Makefile b/drivers/gpu/drm/mgag200/Makefile
index 7db592e..a9a0300 100644
--- a/drivers/gpu/drm/mgag200/Makefile
+++ b/drivers/gpu/drm/mgag200/Makefile
@@ -1,5 +1,5 @@
 ccflags-y := -Iinclude/drm
-mgag200-y   := mgag200_main.o mgag200_mode.o \
+mgag200-y   := mgag200_main.o mgag200_mode.o mgag200_cursor.o \
mgag200_drv.o mgag200_fb.o mgag200_i2c.o mgag200_ttm.o
 
 obj-$(CONFIG_DRM_MGAG200) += mgag200.o
diff --git a/drivers/gpu/drm/mgag200/mgag200_cursor.c 
b/drivers/gpu/drm/mgag200/mgag200_cursor.c
new file mode 100644
index 000..801731a
--- /dev/null
+++ b/drivers/gpu/drm/mgag200/mgag200_cursor.c
@@ -0,0 +1,275 @@
+/*
+ * Copyright 2013 Matrox Graphics
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License version 2. See the file COPYING in the main
+ * directory of this archive for more details.
+ *
+ * Author: Christopher Harvey char...@matrox.com
+ */
+
+#include drm/drmP.h
+#include mgag200_drv.h
+
+static bool warn_transparent = true;
+static bool warn_palette = true;
+
+/*
+  Hide the cursor off screen. We can't disable the cursor hardware because it
+  takes too long to re-activate and causes momentary corruption
+*/
+static void mga_hide_cursor(struct mga_device *mdev)
+{
+   WREG8(MGA_CURPOSXL, 0);
+   WREG8(MGA_CURPOSXH, 0);
+   mgag200_bo_unpin(mdev-cursor.pixels_1);
+   mgag200_bo_unpin(mdev-cursor.pixels_2);
+}
+
+int mga_crtc_cursor_set(struct drm_crtc *crtc,
+   struct drm_file *file_priv,
+   uint32_t handle,
+   uint32_t width,
+   uint32_t height)
+{
+   struct drm_device *dev = (struct drm_device *)file_priv-minor-dev;
+   struct mga_device *mdev = (struct mga_device *)dev-dev_private;
+   struct mgag200_bo *pixels_1 = mdev-cursor.pixels_1;
+   struct mgag200_bo *pixels_2 = mdev-cursor.pixels_2;
+   struct mgag200_bo *pixels_current = mdev-cursor.pixels_current;
+   struct mgag200_bo *pixels_prev = mdev-cursor.pixels_prev;
+   struct drm_gem_object *obj;
+   struct mgag200_bo *bo = NULL;
+   int ret = 0;
+   unsigned int i, row, col;
+   uint32_t colour_set[16];
+   uint32_t *next_space = colour_set[0];
+   uint32_t *palette_iter;
+   uint32_t this_colour;
+   bool 

[PATCH 1/2] drm: kms_helper: don't lose hotplug event

[Daniel Vetter]

There's a race window (small for hpd, 10s large for polled outputs)
where userspace could sneak in with an unrelated connnector probe
ioctl call and eat the hotplug event (since neither the hpd nor the
poll code see a state change).

To avoid this, check whether the connector state changes in all other
-detect calls (in the current helper code that's only probe_single)
and if that's the case, fire off a hotplug event. Note that we can't
directly call the hotplug event handler, since that expects that no
locks are held (due to reentrancy with the fb code to update the kms
console).

Also, this requires that drivers using the probe_single helper
function set up the poll work. All current drivers do that already,
and with the reworked hpd handling there'll be no downside to
unconditionally setting up the poll work any more.

Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/drm_crtc_helper.c | 32 +++-
 include/drm/drm_crtc.h|  1 +
 2 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index ed1334e..1c0c0bc 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -122,6 +122,7 @@ int drm_helper_probe_single_connector_modes(struct 
drm_connector *connector,
int count = 0;
int mode_flags = 0;
bool verbose_prune = true;
+   enum drm_connector_status old_status;
 
DRM_DEBUG_KMS([CONNECTOR:%d:%s]\n, connector-base.id,
drm_get_connector_name(connector));
@@ -137,7 +138,32 @@ int drm_helper_probe_single_connector_modes(struct 
drm_connector *connector,
if (connector-funcs-force)
connector-funcs-force(connector);
} else {
+   old_status = connector-status;
+
connector-status = connector-funcs-detect(connector, true);
+
+   /*
+* Normally either the driver's hpd code or the poll loop should
+* pick up any changes and fire the hotplug event. But if
+* userspace sneaks in a probe, we might miss a change. Hence
+* check here, and if anything changed start the hotplug code.
+*/
+   if (old_status != connector-status) {
+   DRM_DEBUG_KMS([CONNECTOR:%d:%s] status updated from %d 
to %d\n,
+ connector-base.id,
+ drm_get_connector_name(connector),
+ old_status, connector-status);
+
+   /*
+* The hotplug event code might call into the fb
+* helpers, and so expects that we do not hold any
+* locks. Fire up the poll struct instead, it will
+* disable itself again.
+*/
+   dev-mode_config.delayed_event = true;
+   
schedule_delayed_work(dev-mode_config.output_poll_work,
+ 0);
+   }
}
 
/* Re-enable polling in case the global poll config changed. */
@@ -980,7 +1006,11 @@ static void output_poll_execute(struct work_struct *work)
struct drm_device *dev = container_of(delayed_work, struct drm_device, 
mode_config.output_poll_work);
struct drm_connector *connector;
enum drm_connector_status old_status;
-   bool repoll = false, changed = false;
+   bool repoll = false, changed;
+
+   /* Pick up any changes detected by the probe functions. */
+   changed = dev-mode_config.delayed_event;
+   dev-mode_config.delayed_event = false;
 
if (!drm_kms_helper_poll)
return;
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index adb3f9b..91c8568 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -815,6 +815,7 @@ struct drm_mode_config {
/* output poll support */
bool poll_enabled;
bool poll_running;
+   bool delayed_event;
struct delayed_work output_poll_work;
 
/* pointers to standard properties */
-- 
1.7.11.7

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

[PATCH 2/2] drm/crtc-helper: clamp unknown connector status in the poll work

[Daniel Vetter]

On some chipset we try to avoid possibly invasive output detection
methods (like load detect which can cause flickering elsewhere) in the
output poll work. Drivers could hence return unknown when a previous
full -detect call returned a different state.

This change will generate a hotplug event, forcing userspace to do a
full scan. This in turn updates the connector-status field so that we
will _again_ get a state change when the hotplug work re-runs in 10
seconds.

To avoid this ping-pong loop detect this situation and clamp the
connector state to the old value.

Patch is inspired by a patch from Knut Peterson. Knut's patch
completely ignored connector state changes if either the old or new
status was unknown, which seemed to be a bit too agressive to me.

References: 
http://lists.freedesktop.org/archives/dri-devel/2012-August/025975.html
Cc: Knut Petersen knut_peter...@t-online.de
Cc: Alex Deucher alexander.deuc...@amd.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/drm_crtc_helper.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index 1c0c0bc..9985a17 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -1040,6 +1040,24 @@ static void output_poll_execute(struct work_struct *work)
if (old_status != connector-status) {
const char *old, *new;
 
+   /*
+* The poll work sets force=false when calling detect so
+* that drivers can avoid to do disruptive tests (e.g.
+* when load detect cycles could cause flickering on
+* other, running displays). This bears the risk that we
+* flip-flop between unknown here in the poll work and
+* the real state when userspace forces a full detect
+* call after receiving a hotplug event due to this
+* change.
+*
+* Hence clamp an unknown detect status to the old
+* value.
+*/
+   if (connector-status == connector_status_unknown) {
+   connector-status = old_status;
+   continue;
+   }
+
old = drm_get_connector_status_name(old_status);
new = drm_get_connector_status_name(connector-status);
 
-- 
1.7.11.7

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