[PATCH RFC 1/4] DRM: Armada: implement lastclose() for fbhelper

[Russell King]

Call drm_fb_helper_restore_fbdev_mode() upon last close so that in the
event of the X server crashing, we have some kind of mode restored.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/armada/armada_drm.h   |1 +
 drivers/gpu/drm/armada/armada_drv.c   |7 ++-
 drivers/gpu/drm/armada/armada_fbdev.c |   10 ++
 3 files changed, 17 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_drm.h 
b/drivers/gpu/drm/armada/armada_drm.h
index eef09ec9a5ff..a72cae03b99b 100644
--- a/drivers/gpu/drm/armada/armada_drm.h
+++ b/drivers/gpu/drm/armada/armada_drm.h
@@ -103,6 +103,7 @@ void armada_drm_queue_unref_work(struct drm_device *,
 extern const struct drm_mode_config_funcs armada_drm_mode_config_funcs;

 int armada_fbdev_init(struct drm_device *);
+void armada_fbdev_lastclose(struct drm_device *);
 void armada_fbdev_fini(struct drm_device *);

 int armada_overlay_plane_create(struct drm_device *, unsigned long);
diff --git a/drivers/gpu/drm/armada/armada_drv.c 
b/drivers/gpu/drm/armada/armada_drv.c
index 7aede900a221..15425d23c9cc 100644
--- a/drivers/gpu/drm/armada/armada_drv.c
+++ b/drivers/gpu/drm/armada/armada_drv.c
@@ -321,6 +321,11 @@ static struct drm_ioctl_desc armada_ioctls[] = {
DRM_UNLOCKED),
 };

+static void armada_drm_lastclose(struct drm_device *dev)
+{
+   armada_fbdev_lastclose(dev);
+}
+
 static const struct file_operations armada_drm_fops = {
.owner  = THIS_MODULE,
.llseek = no_llseek,
@@ -337,7 +342,7 @@ static struct drm_driver armada_drm_driver = {
.open   = NULL,
.preclose   = NULL,
.postclose  = NULL,
-   .lastclose  = NULL,
+   .lastclose  = armada_drm_lastclose,
.unload = armada_drm_unload,
.get_vblank_counter = drm_vblank_count,
.enable_vblank  = armada_drm_enable_vblank,
diff --git a/drivers/gpu/drm/armada/armada_fbdev.c 
b/drivers/gpu/drm/armada/armada_fbdev.c
index dd5ea77dac96..743570e99f90 100644
--- a/drivers/gpu/drm/armada/armada_fbdev.c
+++ b/drivers/gpu/drm/armada/armada_fbdev.c
@@ -177,6 +177,16 @@ int armada_fbdev_init(struct drm_device *dev)
return ret;
 }

+void armada_fbdev_lastclose(struct drm_device *dev)
+{
+   struct armada_private *priv = dev->dev_private;
+
+   drm_modeset_lock_all(dev);
+   if (priv->fbdev)
+   drm_fb_helper_restore_fbdev_mode(priv->fbdev);
+   drm_modeset_unlock_all(dev);
+}
+
 void armada_fbdev_fini(struct drm_device *dev)
 {
struct armada_private *priv = dev->dev_private;
-- 
1.7.4.4

[PATCH RFC 4/4] DRM: Armada: prime refcounting bug fix

[Russell King]

Commit 011c2282c74d changed the way refcounting on imported dma_bufs
works, and this hadn't been spotted while forward-porting Armada.
Reflect the changes in that commit into the Armada driver.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/armada/armada_gem.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_gem.c 
b/drivers/gpu/drm/armada/armada_gem.c
index adc7c2da75bb..887816f43476 100644
--- a/drivers/gpu/drm/armada/armada_gem.c
+++ b/drivers/gpu/drm/armada/armada_gem.c
@@ -558,7 +558,6 @@ armada_gem_prime_import(struct drm_device *dev, struct 
dma_buf *buf)
 * refcount on the gem object itself.
 */
drm_gem_object_reference(obj);
-   dma_buf_put(buf);
return obj;
}
}
@@ -574,6 +573,7 @@ armada_gem_prime_import(struct drm_device *dev, struct 
dma_buf *buf)
}

dobj->obj.import_attach = attach;
+   get_dma_buf(buf);

/*
 * Don't call dma_buf_map_attachment() here - it maps the
-- 
1.7.4.4

[PATCH RFC 3/4] DRM: Armada: fix printing of phys_addr_t/dma_addr_t

[Russell King]

These can be 64-bit quantities, so fix them up appropriately.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/armada/armada_fbdev.c |6 +++---
 drivers/gpu/drm/armada/armada_gem.c   |5 +++--
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_fbdev.c 
b/drivers/gpu/drm/armada/armada_fbdev.c
index b348b16f81e2..948cb14c561e 100644
--- a/drivers/gpu/drm/armada/armada_fbdev.c
+++ b/drivers/gpu/drm/armada/armada_fbdev.c
@@ -105,9 +105,9 @@ static int armada_fb_create(struct drm_fb_helper *fbh,
drm_fb_helper_fill_fix(info, dfb->fb.pitches[0], dfb->fb.depth);
drm_fb_helper_fill_var(info, fbh, sizes->fb_width, sizes->fb_height);

-   DRM_DEBUG_KMS("allocated %dx%d %dbpp fb: 0x%08x\n",
-   dfb->fb.width, dfb->fb.height,
-   dfb->fb.bits_per_pixel, obj->phys_addr);
+   DRM_DEBUG_KMS("allocated %dx%d %dbpp fb: 0x%08llx\n",
+   dfb->fb.width, dfb->fb.height, dfb->fb.bits_per_pixel,
+   (unsigned long long)obj->phys_addr);

return 0;

diff --git a/drivers/gpu/drm/armada/armada_gem.c 
b/drivers/gpu/drm/armada/armada_gem.c
index 9f2356bae7fd..adc7c2da75bb 100644
--- a/drivers/gpu/drm/armada/armada_gem.c
+++ b/drivers/gpu/drm/armada/armada_gem.c
@@ -172,8 +172,9 @@ armada_gem_linear_back(struct drm_device *dev, struct 
armada_gem_object *obj)
obj->dev_addr = obj->linear->start;
}

-   DRM_DEBUG_DRIVER("obj %p phys %#x dev %#x\n",
-obj, obj->phys_addr, obj->dev_addr);
+   DRM_DEBUG_DRIVER("obj %p phys %#llx dev %#llx\n", obj,
+(unsigned long long)obj->phys_addr,
+(unsigned long long)obj->dev_addr);

return 0;
 }
-- 
1.7.4.4

[PATCH 0/4] Armada DRM: four fixes

[Russell King - ARM Linux]

Rob, David,

Here are four fixes for review for the Armada DRM driver.

 drivers/gpu/drm/armada/armada_drm.h   |1 +
 drivers/gpu/drm/armada/armada_drv.c   |7 ++-
 drivers/gpu/drm/armada/armada_fbdev.c |   20 +++-
 drivers/gpu/drm/armada/armada_gem.c   |7 ---
 4 files changed, 26 insertions(+), 9 deletions(-)

If you're happy with them, I can send a pull request.

Thanks.

[PATCH RFC 2/4] DRM: Armada: destroy framebuffer after helper

[Russell King]

Destroy the framebuffer only after the helper, since the helper may
still be referencing the framebufer at this point.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/armada/armada_fbdev.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_fbdev.c 
b/drivers/gpu/drm/armada/armada_fbdev.c
index 743570e99f90..b348b16f81e2 100644
--- a/drivers/gpu/drm/armada/armada_fbdev.c
+++ b/drivers/gpu/drm/armada/armada_fbdev.c
@@ -202,11 +202,11 @@ void armada_fbdev_fini(struct drm_device *dev)
framebuffer_release(info);
}

+   drm_fb_helper_fini(fbh);
+
if (fbh->fb)
fbh->fb->funcs->destroy(fbh->fb);

-   drm_fb_helper_fini(fbh);
-
priv->fbdev = NULL;
}
 }
-- 
1.7.4.4

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

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

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

--- Comment #57 from Alexandre Demers  ---
(In reply to comment #54)
> However if I set pi->dynamic_ss to false the lockups disappear, it also
> works with dynamic_ss set to true and pi->mclk_ss set to false.
>
So this seems to point to a spread spectrum mischief. I don't know if
dynamic_ss automatically applies to mclk but it seems to, since disabling
spread spectrum only for mclk solves your problem. We could suspect that at a
given frequency, we have a problem restoring the original message / clock (the
higher we get, the harder it is) until at some point it becomes unreliable.

I should be able to test it later tonight to confirm if this fixes the bug on
my side too.

-- 
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/20131209/e87d85ad/attachment.html>

[Bug 66761] ACPI "Firmware Bug" (IGPU, Z01I) causes trouble

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

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

Lan Tianyu  changed:

   What|Removed |Added

  Component|Config-Other|Video(DRI - non Intel)
   Assignee|acpi_config-other at kernel-bu |drivers_video-dri at 
kernel-bu
   |gs.osdl.org |gs.osdl.org
Product|ACPI|Drivers

--- Comment #7 from Lan Tianyu  ---
The warning is caused by gpu driver. Pass different arg type (integer) to _DSM
which require package type. So reassign.

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

[Bug 63132] [r600/llvm] src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c:1887:lp_emit_declaration_soa: Assertion `idx < 256' failed.

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

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

Michel D?nzer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|mesa-dev at lists.freedesktop. |dri-devel at 
lists.freedesktop
   |org |.org
  Component|Mesa core   |Drivers/Gallium/r600

--- Comment #8 from Michel D?nzer  ---
Fixed for r600g/radeonsi in Mesa Git master:

commit 797894036d1196805f02a2428fff82ece5855af7
Author: Vincent Lejeune 
Date:   Mon Dec 2 00:54:44 2013 +0100

r600/llvm: Allow arbitrary amount of temps in tgsi to llvm

-- 
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/20131209/9a00a468/attachment.html>

[Bug 72387] Tearing at one specific part of the screen on CAYMAN

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

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

Michel D?nzer  changed:

   What|Removed |Added

  Attachment #90447|text/x-log  |text/plain
  mime type||

-- 
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/20131209/b25d6108/attachment.html>

[Bug 72387] Tearing at one specific part of the screen on CAYMAN

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

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

--- Comment #8 from Michel D?nzer  ---
Does it work better with EXA instead of glamor?

-- 
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/20131209/e2336a8a/attachment.html>

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

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

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

--- Comment #58 from Alexandre Demers  ---
Disabling dynamic_ss seems also to do the trick over here.

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

[PATCH] drm/vmwgfx: Add max surface memory param

[Thomas Hellstrom]

From: Jakob Bornecrantz 

Userspace uses this to workaround overcommit issues
by flushing the command stream early.

Signed-off-by: Jakob Bornecrantz 
Reviewed-by: Thomas Hellstrom 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c |3 +++
 include/uapi/drm/vmwgfx_drm.h |1 +
 2 files changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c
index a51f48e..45d5b5a 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c
@@ -68,6 +68,9 @@ int vmw_getparam_ioctl(struct drm_device *dev, void *data,
  SVGA_FIFO_3D_HWVERSION));
break;
}
+   case DRM_VMW_PARAM_MAX_SURF_MEMORY:
+   param->value = dev_priv->memory_size;
+   break;
default:
DRM_ERROR("Illegal vmwgfx get param request: %d\n",
  param->param);
diff --git a/include/uapi/drm/vmwgfx_drm.h b/include/uapi/drm/vmwgfx_drm.h
index bcb0912..f854ca4 100644
--- a/include/uapi/drm/vmwgfx_drm.h
+++ b/include/uapi/drm/vmwgfx_drm.h
@@ -75,6 +75,7 @@
 #define DRM_VMW_PARAM_FIFO_CAPS4
 #define DRM_VMW_PARAM_MAX_FB_SIZE  5
 #define DRM_VMW_PARAM_FIFO_HW_VERSION  6
+#define DRM_VMW_PARAM_MAX_SURF_MEMORY  7

 /**
  * struct drm_vmw_getparam_arg
-- 
1.7.10.4

[git pull] drm fixes

[Dave Airlie]

Hi Linus,

this is probably a bit big, but just because I fell behind last week and 
didn't get to doing any pulls, so stuff backed up behind me, I actually 
should have sent this for -rc3 but failed to even manage that,

So this has radeon, intel, nouveau, vmware, exynos and tegra fixes in it,
and the line count isn't all the bad in the end.

Dave.

The following changes since commit 8ecffd7914484b728799dd31968f1339fae91593:

  Merge tag 'gpio-v3.13-3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio (2013-12-04 
08:59:33 -0800)

are available in the git repository at:


  git://people.freedesktop.org/~airlied/linux drm-fixes

for you to fetch changes up to 9255ce80f88ba885c38c0bbd235db7c24392e22e:

  Merge branch 'drm-fixes-3.13' of git://people.freedesktop.org/~agd5f/linux 
into drm-fixes (2013-12-05 12:18:35 +1000)



Alex Deucher (6):
  drm/radeon: fix typo in fetching mpll params
  drm/radeon: program DCE2 audio dto just like DCE3
  drm/radeon/dpm: simplify state adjust logic for NI
  drm/radeon: fixup bad vram size on SI
  drm/radeon: fix null pointer dereference in dce6+ audio code
  drm/radeon/atom: fix bus probes when hw_i2c is set (v2)

Alexandre Demers (1):
  drm/radeon: Fix a typo in Cayman and Evergreen registers

Ben Skeggs (3):
  drm/nv04-nv30/clk: provide an empty domain list
  drm/nouveau: unreference fence after syncing
  drm/nouveau/sw: fix oops if gpu has its display block disabled

Chris Wilson (3):
  drm/i915: Prefer setting PTE cache age to 3
  drm/i915: Pin relocations for the duration of constructing the execbuffer
  drm/i915: Pin pages whilst allocating for dma-buf vmap()

Christian K?nig (2):
  drm/radeon: add VMID allocation trace point
  drm/radeon: add radeon_vm_bo_update trace point

Dan Carpenter (2):
  drm/tegra: return -EFAULT if copy_from_user() fails
  drm/nv50/disp: min/max are reversed in nv50_crtc_gamma_set()

Dave Airlie (7):
  drm/radeon: fix VGT_GS_INSTANCE_CNT register
  Merge branch 'vmwgfx-fixes-3.13' of 
git://people.freedesktop.org/~thomash/linux into drm-fixes
  Merge branch 'drm-nouveau-next' of 
git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes
  Merge tag 'drm/for-3.13-rc3' of git://anongit.freedesktop.org/tegra/linux 
into drm-fixes
  Merge branch 'exynos-drm-fixes' of 
git://git.kernel.org/.../daeinki/drm-exynos into drm-fixes
  Merge tag 'drm-intel-fixes-2013-12-02' of 
git://people.freedesktop.org/~danvet/drm-intel into drm-fixes
  Merge branch 'drm-fixes-3.13' of 
git://people.freedesktop.org/~agd5f/linux into drm-fixes

Guenter Roeck (1):
  drm/radeon/dpm: Convert to use devm_hwmon_register_with_groups

Ilia Mirkin (3):
  drm/nv10/plane: fix format computation
  drm/nv10/plane: add downscaling restrictions
  drm/nv10/plane: some chipsets don't support NV12

Inki Dae (1):
  drm/exynos: release unhandled page flip events at postclose.

Jani Nikula (1):
  drm/i915/ddi: set sink to power down mode on dp disable

Jesse Barnes (2):
  drm/i915: take mode config lock around crtc disable at suspend
  drm/i915: use crtc_htotal in watermark calculations to match fastboot v2

Maarten Lankhorst (1):
  drm/nouveau/kms: send timestamp data for correct head in flip completion 
events

Olof Johansson (1):
  gpu: host1x: Silence a few warnings with LPAE=y

Paulo Zanoni (1):
  drm/i915: use the correct force_wake function at the PC8 code

Rob Clark (1):
  udl: fix issue with imported prime buffers

Roy Spliet (2):
  drm/nouveau/fifo: Hook up pause and resume for NV50 and NV84+
  drm/nouveau/clk: Add support for NVAA/NVAC

Sachin Kamat (1):
  drm/exynos: Fix trivial typo in exynos_drm_fimd.c

Thierry Reding (6):
  drm/tegra: Make CRTC upcasting safer
  drm/tegra: Tightly bind RGB output to DC
  drm/tegra: Fix address space mismatches
  drm/tegra: Make tegra_drm_driver static
  drm/tegra: Force cast to __iomem to make sparse happy
  gpu: host1x: Fix a few sparse warnings

Thomas Hellstrom (4):
  drm/vmwgfx: Correctly set the enabled state on crtcs
  drm/vmwgfx: Fix up and comment the dumb buffer implementation
  drm/vmwgfx: Fix dma buffer memory size accounting
  drm/vmwgfx: Add our connectors to sysfs

Thomas Wood (2):
  drm/edid: fix length check when adding extra 3D modes
  drm: fix the addition of the side-by-side (half) flag for extra 3D modes

Ville Syrj?l? (5):
  drm/i915: Check VBT for eDP ports on VLV
  drm/i915: Simplify DP vs. eDP detection
  drm/i915: Fix pipe CSC post offset calculation
  drm/i915: Make the DERRMR SRM target global GTT
  drm/i915: MI_PREDICATE_RESULT_2 is HSW only

 drivers/gpu/drm/drm_edid.c |   4 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.c|  35 +-
 drivers/gpu/drm/exynos/exynos_drm_fi

[PATCH v2] imx-drm: fix channel->edid memleak

[Sascha Hauer]

On Sun, Dec 08, 2013 at 10:03:57PM +0100, Peter Seiderer wrote:
> 
> Signed-off-by: Peter Seiderer 
> ---
> Changes v1 -> v2:
>   - add missing Signed-off-by line
> 
>  drivers/staging/imx-drm/imx-ldb.c | 2 ++
>  1 file changed, 2 insertions(+)

Acked-by: Sascha Hauer 

Sascha

> 
> diff --git a/drivers/staging/imx-drm/imx-ldb.c 
> b/drivers/staging/imx-drm/imx-ldb.c
> index 7e59329..448f3ce 100644
> --- a/drivers/staging/imx-drm/imx-ldb.c
> +++ b/drivers/staging/imx-drm/imx-ldb.c
> @@ -599,6 +599,8 @@ static int imx_ldb_remove(struct platform_device *pdev)
>  
>   imx_drm_remove_connector(channel->imx_drm_connector);
>   imx_drm_remove_encoder(channel->imx_drm_encoder);
> +
> + kfree(channel->edid);
>   }
>  
>   return 0;
> -- 
> 1.8.1.4
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> 

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

[Bug 66761] ACPI "Firmware Bug" (IGPU, Z01I) causes trouble

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

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

--- Comment #8 from David Runge  ---
Okay... also these lines?

ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S1_]
(20130725/hwxface-571)
ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S2_]
(20130725/hwxface-571)

And all of those saying "[...] can't evaluate _ADR (0x5)", too?

If there is any more info you need from me, please let me know!

Mainline is still not working. Dies the millisecond it tries to use nouveau.

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

[Bug 45709] r600g doesn't seem to flush when it should → visual stuck

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

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

--- Comment #6 from Johan  ---
I experience the same behavior, trying to run Dungeon Keeper 2 under wine.

Used stack:
libdrm: 2.4.50
Mesa: 10.0.0 (r600g)
Linux: 3.12.0
DDX: 7.2.0
X.org: 14.3-r2
Hardware: 1002:9710 (RS880 [Radeon HD 4200])
Wine: 1.7.4

-- 
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/20131209/dbce541d/attachment.html>

[RFC v2 PATCH] mipi-dsi-bus: add MIPI DSI bus support

[Thierry Reding]

 a generic solution, and requires one to use
> the DSI peripherals in a very controlled manner to make sure no DSI
> device is blocking the other ones for too long. I have not seen these in
> production, and while I'm just guessing, the reason may be that is so
> difficult to make them work well.
> 
> The only standard part of DSI, in my experience, is the DSI packet layer
> (maybe there's a better term for it). Anything else is often custom. For
> this reason I think the DSI peripheral driver has to be in full control
> of the device, and the DSI bus cannot really do anything by itself.

The same is true of I2C. There's no probing or standard registers across
devices. But it's still a bus that can have multiple peripherals and a
way to address them. Every peripheral has an associated device, which
drivers can use to have the I2C master send messages to the correct
peripheral.

> There's not much "bus" in DSI in my opinion. No probing, one-to-one
> links,

There are one-to-many links as well. You've in fact provided an example
of one such device above to prove another point.

> very limited "address space", all the cases I know have just one
> DSI device...

Most of that's true for I2C or SPI as well. SPI even needs sideband
signalling to address more than a single slave.

All the case that I know have only a single DSI device as well. I'm
beginning to wonder why I even bother with all this.

> So... While having a Linux DSI bus, etc. would feel elegant and nice, I
> just feel it's not easy and not worth it.

Really the only reason why I've been pushing for this is because Laurent
wanted me to represent DSI panels as children of a DSI bus in DT for the
simple-panel bindings. The only solution to do this somewhat generically
is to have a DSI bus binding and that sort of implies a DSI bus
implementation.

The particular use-case that I care about works without any of this as
well.

> What we have in omapdss is far from perfect, but it has been working
> quite nicely. DSI is considered just as a data bus, with extra
> functionality for sending control messages. A DSI device is either a
> platform device if it requires no control or the control is done via
> DSI, or it's a device of the control bus like i2c.

So in fact you do consider DSI a control *and* data bus, but you're
side-stepping the issue by hiding things within the drivers. But you
still need to hook up the DSI device to an I2C master and a DSI host
before you can use it. The reason why you can hide that is probably
because it isn't generic and you couldn't reuse the peripheral DSI
drivers on a different DSI host.

> All that said, I may be mentally stuck in the old models I've been using
> for a long time, so maybe a different approach for DSI is good. We just
> need to make sure the existing devices can be supported.

I don't see how other devices would be broken. For one you can easily
keep your existing code. We're adding new API here so there's no need at
all to migrate to it and no way for it to break existing functionality.

But it will obviously be some work to move to a generic "framework", if
you can call it that. The driver will likely need some major rewrite,
which I think will be the case anyway because this will be a DRM API and
you'll have to move to DRM to use it.

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

[Bug 66791] Radeon fails to find vbios on macbook pro 2, 1 (2007) for x1600 using kernel EFI stub

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

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

Alan  changed:

   What|Removed |Added

 CC||alan at lxorguk.ukuu.org.uk
  Component|Console/Framebuffers|Video(DRI - non Intel)
   Assignee|jsimmons at infradead.org  |drivers_video-dri at 
kernel-bu
   ||gs.osdl.org

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

[Bug 72387] Tearing at one specific part of the screen on CAYMAN

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

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

--- Comment #9 from Thomas Rohloff  ---
(In reply to comment #8)
> Does it work better with EXA instead of glamor?

No.

-- 
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/20131209/f217973c/attachment.html>

[Bug 66791] Radeon fails to find vbios on macbook pro 2, 1 (2007) for x1600 using kernel EFI stub

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

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

Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeucher at gmail.com

--- Comment #1 from Alex Deucher  ---
Apple's EFI implementation does not provide a way to fetch the vbios after the
OS takes over.  IIRC, you need a special bootloader and kernel support for
fetching the vbios before passing control to the OS.  I think Matthew Garret
had patches to support this at some point, I'm not sure what their status is. 
The other option is to boot using the legacy bios interface (not EFI).

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

[RFC v2 PATCH] mipi-dsi-bus: add MIPI DSI bus support

[Thierry Reding]

On Mon, Dec 09, 2013 at 05:05:20PM +0200, Tomi Valkeinen wrote:
> On 2013-12-09 15:10, Thierry Reding wrote:
[...]
> > But even if you have a tree of one-to-one links, you still need some way
> > to address the individual nodes in the tree. The VC ID is the only way
> > by which you can address a node. I don't see how you can possible send
> > packets to more than one node if you keep sending packets to the same
> > address. Where does the missing information magically come from?
> 
> From the DSI hub.
> 
> In the example case below, let's say the DSI panel 1 driver is told to
> send a configuration packet to the panel. The panel driver would call a
> dsi_transmit op, giving as arguments the VC number 0, and the packet data.
> 
> That call would go to the DSI hub driver. It knows how it routes the
> packets (the routing configuration is either hardcoded or passed via DT
> data), and then calls dsi_transmit op on SoC DSI, with VC number 2 and
> the packet data.

So it is the DSI hub driver that translates VC 0 to VC 2? How does it
know that VC 0 should be VC 2 but not VC 3? Does the panel 2 driver pass
in a different VC as panel 1?

> >> For the sake of discussion, let's consider a simple DSI hub setup:
> >>
> >> SoC DSI -> DSI Hub -> DSI panel 1
> >>-> DSI panel 2
> >>
> >> The hub would use, say VC0 for hub configuration, and it'd route VC2 to
> >> panel 1 and VC3 to panel2. Both panels would use VC0, so the hub would
> >> translate the VC ID accordingly.
> >>
> >> How would you represent this in Linux?
> > 
> > You keep saying that devices use various VC IDs (VC0 for hub config, VC2
> > and VC3 for panels 1 and 2 in this case). But those are exactly the
> > addresses. You've got to have some way within the kernel to store those.
> > 
> > Given the limited address space of DSI there's no way to accurately
> > represent the hierarchy of the above in the bus/device numbering. But
> > that doesn't mean you can't assign addresses (VC IDs) to the devices. In
> > fact you've given examples yourself.
> 
> Yes, but I guess the difference in our views is that I see the VC IDs as
> "link local" and routing is done by the hubs as they see fit. In other
> words, if I'm not mistaken, you'd have a Linux DSI bus with three
> devices in the bus, each having its own VC ID, whereas I'd have a DSI
> "link" between the SoC and the hub, without any general information
> about the VC IDs used, and two additional DSI links, from the DSI hub to
> each panel.

It's really the same thing. If you define VC IDs in a link local manner
you don't need them at all. What's the point in having them if you can
only reach a single device anyway.

[PATCH] imx-drm: gamma correction for imx-ldb

[Lucas Stach]

Am Sonntag, den 08.12.2013, 22:20 +0100 schrieb Peter Seiderer:
> Hello Lucas,
> 
> On Fri, Dec 06, 2013 at 11:04:39AM +0100, Lucas Stach wrote:
> > Hi Peter,
> > 
> > Am Donnerstag, den 05.12.2013, 23:45 +0100 schrieb Peter Seiderer:
> > > Signed-off-by: Peter Seiderer 
> > > ---
> > >  arch/arm/boot/dts/imx6q-sabrelite.dts   |  3 +++
> > >  drivers/staging/imx-drm/imx-drm-core.c  | 27 +++
> > >  drivers/staging/imx-drm/imx-drm.h   |  4 
> > >  drivers/staging/imx-drm/imx-ldb.c   | 18 
> > >  drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h |  2 ++
> > >  drivers/staging/imx-drm/ipu-v3/ipu-dp.c | 33 
> > > +
> > >  drivers/staging/imx-drm/ipuv3-crtc.c|  9 
> > >  7 files changed, 96 insertions(+)
> > > 
> > > diff --git a/arch/arm/boot/dts/imx6q-sabrelite.dts 
> > > b/arch/arm/boot/dts/imx6q-sabrelite.dts
> > > index fca8f220..5dabc45 100644
> > > --- a/arch/arm/boot/dts/imx6q-sabrelite.dts
> > > +++ b/arch/arm/boot/dts/imx6q-sabrelite.dts
> > > @@ -171,6 +171,9 @@
> > > lvds-channel at 0 {
> > > fsl,data-mapping = "spwg";
> > > fsl,data-width = <18>;
> > > +   /* gamma = 0.6 */
> > > +   fsl,gamma-constk = /bits/ 16 <0x000 0x000 0x000 0x000 0x1ff 
> > > 0x001 0x009 0x015 0x025 0x037 0x04d 0x064 0x07f 0x09c 0x0bb 0x0dc>;
> > > +   fsl,gamma-slopek = /bits/ 16 <0x000 0x000 0x000 0x000 0x002 
> > > 0x008 0x00c 0x010 0x012 0x016 0x017 0x01b 0x01d 0x01f 0x021 0x022>;
> > > status = "okay";
> 
> > Sorry, but I strongly oppose the addition of these values to the DT.
> > 
> > Gamma isn't a fixed hardware value, but something that should be
> > configurable from userspace via the KMS interface. Other drivers
> > historically did this through setting of the color LUT, but I see we may
> > need some other solution for imx-drm here. Still your proposed solution
> > doesn't look right.
> > 
> > Regards,
> > Lucas
> 
> My reasoning here was that for an embedded solution the gamma correction is 
> more a fixed value depending on the output device (here the lvds display and 
> no pluggable device) and should belong
> to the other lvds device specific values...
> 
> But nevertheless, do you have any more hint/suggestion where (or howto) to 
> implement this feature?
> 
Hm, seems I was confused by the reference manual talking about a
polynomial and stuff.
At a second look it seems like you can just use the KMS interface (look
at the crtc's gamma_set() callback) to let usespace pass in the gamma
ramp, from which you can then extract the Gout1..15 values and use the
formula from the reference manual to calculate the appropriate register
values.

Be aware that the DRM interface seems to expect the gamma as a 8.8 fixed
number normalized to the gamma ramp size, so you need to do some
renormalization to meet the hardware expectations and any gamma ramp
size above 256 is invalid.

Regards,
Lucas

-- 
Pengutronix e.K.   | Lucas Stach |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

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

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

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

--- Comment #59 from Alexandre Demers  ---
This morning, I tested a bit the kernel after disabling only mclk_ss and it
seems to work correctly when it is disabled. Martin may have put his finger
where the problem is.

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

TTM's role in score-based eviction

[Daniel Vetter]

On Thu, Dec 05, 2013 at 11:45:03AM -0500, Jerome Glisse wrote:
> On Thu, Dec 05, 2013 at 05:22:54PM +0100, Maarten Lankhorst wrote:
> > op 05-12-13 16:49, Jerome Glisse schreef:
> > > On Thu, Dec 05, 2013 at 11:26:46AM +0100, Thomas Hellstrom wrote:
> > >> Hi!
> > >>
> > >> On 12/05/2013 10:36 AM, Lauri Kasanen wrote:
> > >>> Hi list, Thomas,
> > >>>
> > >>> I will be investigating the use of a hotness score for each bo, to
> > >>> replace the ping-pong causing LRU eviction in radeon*.
> > >>>
> > >>> The goal is to put all bos that fit in VRAM there, in order of hotness;
> > >>> a new bo should only be placed there if its hotness score is greater
> > >>> than the lowest VRAM bo's. Then the lowest-hotness-bos in
> > >>> VRAM should be evicted until the new bo fits. This should result in a
> > >>> more stable set with less ping-pong.
> > >>>
> > >>> Jerome advised that the bo placement should be done entirely outside
> > >>> TTM. As I'm not (yet) too familiar with that side of the kernel, what is
> > >>> the opinion of TTM folks?
> > >> There are a couple of things to be considered:
> > >> 1) You need to decide where a bo to be validated should be placed.
> > >> The driver can give a list of possible placements to TTM and let
> > >> TTM decide, trying each placement in turn. A driver that thinks this
> > >> isn't sufficient can come up with its on strategy and give only a
> > >> single placement to TTM. If TTM can't satisfy that, it will give you
> > >> an error back, and the driver will need to validate with an
> > >> alternative placement. I think Radeon already does this? vmwgfx does
> > >> it to some extent.
> > >>
> > >> 2) As you say, TTM is evicting strictly on an lru basis, and is
> > >> maintaining one LRU list per memory type, and also a global swap lru
> > >> list for buffers that are backed by system pages (not VRAM). I guess
> > >> what you would want to do is to replace the VRAM lru list with a
> > >> priority queue where bos are continously sorted based on hotness.
> > >> As long as you obey the locking rules:
> > >> *) Locking order is bo::reserve -> lru-lock
> > >> *) When walking the queue with the lru-lock held, you must therefore
> > >> tryreserve if you want to reserve an object on the queue
> > >> *) bo:s need to be removed from the queue as soon as they are reserved
> > >> *) Don't remove a bo from the queue unless it is reserved
> > >> Nothing stops you from doing this in the driver, but OTOH if this
> > >> ends up being useful for other drivers I'd prefer we put it into
> > >> TTM.
> > > It will be useful to others, the point i am making is that others might
> > > not use ttm either and there is nothing about bo placement that needs
> > > to be ttm specific.
> > >
> > > To avoid bo eviction from lru list is just a matter of driver never
> > > over committing bo on a pool of memory and driver doing eviction by
> > > itself, ie deciding of a new placement for bo and moving that bo
> > > before moving in other bo, which can be done outside ttm.
> > >
> > > The only thing that will needs modification to ttm is work done to
> > > control memory fragmentation but this should be not be enforce on
> > > all ttm user and should be a runtime decision. GPU with virtual
> > > address space can scatter bo through vram by using vram pages making
> > > memory fragmentation pretty much a non issue (some GPU still needs
> > > contiguous memory for scan out buffer or other specific buffer).
> > >
> > You're correct it COULD be done like that, but that's a nasty workaround.
> > Simply assign a priority to each buffer, then modify ttm_bo_add_to_lru,
> > ttm_bo_swapout, ttm_mem_evict_first and be done with it.
> > 
> > Memory management is exactly the kind of thing that should be done in TTM,
> > so why have something 'generic' for something that's little more than a 
> > renamed priority queue?
> 
> The end score and use of the score for placement decision be done in ttm
> but the whole score computation and heuristic related to it should not.

btw another thing to look at is the eviction roaster in drm_mm. It's
completely standalone, the only thing it requires is that you have a
deterministic order to add objects to it and unroll them (but that can
always be solved by putting objects on a temporary list).

That way if you have some big objects and a highly fragmented vram you
don't end up eviction a big load of data, but just a perfectly-sized hole.
All the scanning is linar, but ime with the implementation in i915.ko
that's not a real-world issue really. The drm_mm roaster supports all the
same features as the normal block allocator, so range-restricted
allocations (and everything else) also works. See evict_something in
i915_gem_eviction.c for how it all works (yeah, no docs but writing those
for drm_mm.c is on my todo somewhere).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH 09/13] drm/msm: split out msm_kms.h

[Erik Faye-Lund]

On Sun, Dec 8, 2013 at 12:35 AM, Rob Clark  wrote:
> diff --git a/drivers/gpu/drm/msm/msm_kms.h b/drivers/gpu/drm/msm/msm_kms.h
> new file mode 100644
> index 000..e42973c
> --- /dev/null
> +++ b/drivers/gpu/drm/msm/msm_kms.h
> @@ -0,0 +1,57 @@
> +/*
> + * Copyright (C) 2013 Red Hat
> + * Author: Rob Clark 
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published 
> by
> + * the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but 
> WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If not, see .
> + */
> +
> +#ifndef __MSM_KMS_H__
> +#define __MSM_KMS_H__
> +
> +#include 
> +#include 
> +
> +#include "msm_drv.h"
> +
> +/* As there are different display controller blocks depending on the
> + * snapdragon version, the kms support is split out and the appropriate
> + * implementation is loaded at runtime.  The kms module is responsible
> + * for constructing the appropriate planes/crtcs/encoders/connectors.
> + */
> +struct msm_kms_funcs {
> +   /* hw initialization: */
> +   int (*hw_init)(struct msm_kms *kms);
> +   /* irq handling: */
> +   void (*irq_preinstall)(struct msm_kms *kms);
> +   int (*irq_postinstall)(struct msm_kms *kms);
> +   void (*irq_uninstall)(struct msm_kms *kms);
> +   irqreturn_t (*irq)(struct msm_kms *kms);
> +   int (*enable_vblank)(struct msm_kms *kms, struct drm_crtc *crtc);
> +   void (*disable_vblank)(struct msm_kms *kms, struct drm_crtc *crtc);
> +   /* misc: */
> +   const struct msm_format *(*get_format)(struct msm_kms *kms, uint32_t 
> format);
> +   long (*round_pixclk)(struct msm_kms *kms, unsigned long rate,
> +   struct drm_encoder *encoder);
> +   /* cleanup: */
> +   void (*preclose)(struct msm_kms *kms, struct drm_file *file);
> +   void (*destroy)(struct msm_kms *kms);
> +};
> +
> +struct msm_kms {
> +   const struct msm_kms_funcs *funcs;
> +};
> +
> +struct msm_kms *mdp4_kms_init(struct drm_device *dev);
> +struct msm_kms *mdp5_kms_init(struct drm_device *dev);

Shouldn't this be introduced in a follow-up patch that also adds the definition?

[PATCH 09/13] drm/msm: split out msm_kms.h

[Rob Clark]

On Mon, Dec 9, 2013 at 12:36 PM, Erik Faye-Lund  wrote:
> On Sun, Dec 8, 2013 at 12:35 AM, Rob Clark  wrote:
>> diff --git a/drivers/gpu/drm/msm/msm_kms.h b/drivers/gpu/drm/msm/msm_kms.h
>> new file mode 100644
>> index 000..e42973c
>> --- /dev/null
>> +++ b/drivers/gpu/drm/msm/msm_kms.h
>> @@ -0,0 +1,57 @@
>> +/*
>> + * Copyright (C) 2013 Red Hat
>> + * Author: Rob Clark 
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms of the GNU General Public License version 2 as published 
>> by
>> + * the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful, but 
>> WITHOUT
>> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
>> + * more details.
>> + *
>> + * You should have received a copy of the GNU General Public License along 
>> with
>> + * this program.  If not, see .
>> + */
>> +
>> +#ifndef __MSM_KMS_H__
>> +#define __MSM_KMS_H__
>> +
>> +#include 
>> +#include 
>> +
>> +#include "msm_drv.h"
>> +
>> +/* As there are different display controller blocks depending on the
>> + * snapdragon version, the kms support is split out and the appropriate
>> + * implementation is loaded at runtime.  The kms module is responsible
>> + * for constructing the appropriate planes/crtcs/encoders/connectors.
>> + */
>> +struct msm_kms_funcs {
>> +   /* hw initialization: */
>> +   int (*hw_init)(struct msm_kms *kms);
>> +   /* irq handling: */
>> +   void (*irq_preinstall)(struct msm_kms *kms);
>> +   int (*irq_postinstall)(struct msm_kms *kms);
>> +   void (*irq_uninstall)(struct msm_kms *kms);
>> +   irqreturn_t (*irq)(struct msm_kms *kms);
>> +   int (*enable_vblank)(struct msm_kms *kms, struct drm_crtc *crtc);
>> +   void (*disable_vblank)(struct msm_kms *kms, struct drm_crtc *crtc);
>> +   /* misc: */
>> +   const struct msm_format *(*get_format)(struct msm_kms *kms, uint32_t 
>> format);
>> +   long (*round_pixclk)(struct msm_kms *kms, unsigned long rate,
>> +   struct drm_encoder *encoder);
>> +   /* cleanup: */
>> +   void (*preclose)(struct msm_kms *kms, struct drm_file *file);
>> +   void (*destroy)(struct msm_kms *kms);
>> +};
>> +
>> +struct msm_kms {
>> +   const struct msm_kms_funcs *funcs;
>> +};
>> +
>> +struct msm_kms *mdp4_kms_init(struct drm_device *dev);
>> +struct msm_kms *mdp5_kms_init(struct drm_device *dev);
>
> Shouldn't this be introduced in a follow-up patch that also adds the 
> definition?

yeah, probably.. looks like I fumbled slightly when re-arranging patches..

BR,
-R

[Bug 72283] [] dce6_afmt_write_speaker_allocation+0xdb/0x140 [radeon]

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

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

--- Comment #13 from bgunteriv at gmail.com ---
Created attachment 90534
  --> https://bugs.freedesktop.org/attachment.cgi?id=90534&action=edit
dmesg

Here are new logs with the latest drm-intel kernel
(http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/current/)

-- 
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/20131209/08395355/attachment.html>

[Bug 72283] [] dce6_afmt_write_speaker_allocation+0xdb/0x140 [radeon]

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

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

--- Comment #14 from bgunteriv at gmail.com ---
Created attachment 90535
  --> https://bugs.freedesktop.org/attachment.cgi?id=90535&action=edit
X.org.0.log

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

TTM's role in score-based eviction

[Marek Olšák]

Hi Lauri,

FYI, since the userspace driver sends end-of-frame markers to the
kernel, the radeon kernel driver knows the current frame number and it
can also save the frame number of the last use of each buffer. We
should definitely use that to measure the buffer hotness, or just
prevent eviction if the buffer was used recently (the last 2 or 3
frames) and you can drop the hotness calculations entirely.

Also, MSAA buffers and depth buffers should have higher probability of
being placed in VRAM than other buffers, because their placement has
higher impact on performance. They also tend to contain auxiliary data
which significantly improve performance, like fast clear data, MSAA
fragment coverage data, and hierarchical depth and stencil data. We
can add a new ioctl which sets buffer usage flags.

One can say the same thing about colorbuffers too, but there's no easy
way to distinguish between a colorbuffer and an ordinary texture which
isn't used as a colorbuffer but is blitted from time to time.

Marek

On Thu, Dec 5, 2013 at 10:36 AM, Lauri Kasanen  wrote:
> Hi list, Thomas,
>
> I will be investigating the use of a hotness score for each bo, to
> replace the ping-pong causing LRU eviction in radeon*.
>
> The goal is to put all bos that fit in VRAM there, in order of hotness;
> a new bo should only be placed there if its hotness score is greater
> than the lowest VRAM bo's. Then the lowest-hotness-bos in
> VRAM should be evicted until the new bo fits. This should result in a
> more stable set with less ping-pong.
>
> Jerome advised that the bo placement should be done entirely outside
> TTM. As I'm not (yet) too familiar with that side of the kernel, what is
> the opinion of TTM folks?
>
> - Lauri
>
> * github.com/clbr/jamkthesis
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

TTM's role in score-based eviction

[Thomas Hellstrom]

On 12/09/2013 06:28 PM, Daniel Vetter wrote:
> On Thu, Dec 05, 2013 at 11:45:03AM -0500, Jerome Glisse wrote:
>> On Thu, Dec 05, 2013 at 05:22:54PM +0100, Maarten Lankhorst wrote:
>>> op 05-12-13 16:49, Jerome Glisse schreef:
 On Thu, Dec 05, 2013 at 11:26:46AM +0100, Thomas Hellstrom wrote:
> Hi!
>
> On 12/05/2013 10:36 AM, Lauri Kasanen wrote:
>> Hi list, Thomas,
>>
>> I will be investigating the use of a hotness score for each bo, to
>> replace the ping-pong causing LRU eviction in radeon*.
>>
>> The goal is to put all bos that fit in VRAM there, in order of hotness;
>> a new bo should only be placed there if its hotness score is greater
>> than the lowest VRAM bo's. Then the lowest-hotness-bos in
>> VRAM should be evicted until the new bo fits. This should result in a
>> more stable set with less ping-pong.
>>
>> Jerome advised that the bo placement should be done entirely outside
>> TTM. As I'm not (yet) too familiar with that side of the kernel, what is
>> the opinion of TTM folks?
> There are a couple of things to be considered:
> 1) You need to decide where a bo to be validated should be placed.
> The driver can give a list of possible placements to TTM and let
> TTM decide, trying each placement in turn. A driver that thinks this
> isn't sufficient can come up with its on strategy and give only a
> single placement to TTM. If TTM can't satisfy that, it will give you
> an error back, and the driver will need to validate with an
> alternative placement. I think Radeon already does this? vmwgfx does
> it to some extent.
>
> 2) As you say, TTM is evicting strictly on an lru basis, and is
> maintaining one LRU list per memory type, and also a global swap lru
> list for buffers that are backed by system pages (not VRAM). I guess
> what you would want to do is to replace the VRAM lru list with a
> priority queue where bos are continously sorted based on hotness.
> As long as you obey the locking rules:
> *) Locking order is bo::reserve -> lru-lock
> *) When walking the queue with the lru-lock held, you must therefore
> tryreserve if you want to reserve an object on the queue
> *) bo:s need to be removed from the queue as soon as they are reserved
> *) Don't remove a bo from the queue unless it is reserved
> Nothing stops you from doing this in the driver, but OTOH if this
> ends up being useful for other drivers I'd prefer we put it into
> TTM.
 It will be useful to others, the point i am making is that others might
 not use ttm either and there is nothing about bo placement that needs
 to be ttm specific.

 To avoid bo eviction from lru list is just a matter of driver never
 over committing bo on a pool of memory and driver doing eviction by
 itself, ie deciding of a new placement for bo and moving that bo
 before moving in other bo, which can be done outside ttm.

 The only thing that will needs modification to ttm is work done to
 control memory fragmentation but this should be not be enforce on
 all ttm user and should be a runtime decision. GPU with virtual
 address space can scatter bo through vram by using vram pages making
 memory fragmentation pretty much a non issue (some GPU still needs
 contiguous memory for scan out buffer or other specific buffer).

>>> You're correct it COULD be done like that, but that's a nasty workaround.
>>> Simply assign a priority to each buffer, then modify ttm_bo_add_to_lru,
>>> ttm_bo_swapout, ttm_mem_evict_first and be done with it.
>>>
>>> Memory management is exactly the kind of thing that should be done in TTM,
>>> so why have something 'generic' for something that's little more than a 
>>> renamed priority queue?
>> The end score and use of the score for placement decision be done in ttm
>> but the whole score computation and heuristic related to it should not.
> btw another thing to look at is the eviction roaster in drm_mm. It's
> completely standalone, the only thing it requires is that you have a
> deterministic order to add objects to it and unroll them (but that can
> always be solved by putting objects on a temporary list).
>
> That way if you have some big objects and a highly fragmented vram you
> don't end up eviction a big load of data, but just a perfectly-sized hole.
> All the scanning is linar, but ime with the implementation in i915.ko
> that's not a real-world issue really. The drm_mm roaster supports all the
> same features as the normal block allocator, so range-restricted
> allocations (and everything else) also works. See evict_something in
> i915_gem_eviction.c for how it all works (yeah, no docs but writing those
> for drm_mm.c is on my todo somewhere).
> -Daniel

The problem with combining this with TTM is that eviction by default 
doesn't take place under a mutex, so multiple threads may be traversing 
the L

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

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

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

--- Comment #60 from Martin Andersson  ---
Instead of triggering the power level switches by running GpuTest in bursts, I
put this in a bash script:

for i in {1..3600}
do
   echo low > /sys/class/drm/card0/device/power_dpm_force_performance_level
   sleep 1
   echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level
   sleep 5
done

and just let GpuTest, and piglit, run continously. I found that this also
trigger the lockups within minutes.

Then I ran the script by itself, no GpuTest or piglit, and left it running
while I was at work. When I came home the machine was still running, so it ran
for six hours without any lockup. So it seems the power level switching alone
is not sufficient to trigger the lockups, it also needs a load of some sort.

-- 
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/20131209/22fd6b4f/attachment.html>

TTM's role in score-based eviction

[Lauri Kasanen]

On Mon, 9 Dec 2013 20:28:21 +0100
Marek Ol??k  wrote:

Hi,

> FYI, since the userspace driver sends end-of-frame markers to the
> kernel, the radeon kernel driver knows the current frame number and it
> can also save the frame number of the last use of each buffer. We
> should definitely use that to measure the buffer hotness, or just
> prevent eviction if the buffer was used recently (the last 2 or 3
> frames) and you can drop the hotness calculations entirely.

I think this would result in sub-optimal behavior with one client, but
a workload larger than VRAM. If everything is needed in one frame, then
this logic would almost randomly decide what gets to stay.

> Also, MSAA buffers and depth buffers should have higher probability of
> being placed in VRAM than other buffers, because their placement has
> higher impact on performance. They also tend to contain auxiliary data
> which significantly improve performance, like fast clear data, MSAA
> fragment coverage data, and hierarchical depth and stencil data. We
> can add a new ioctl which sets buffer usage flags.

Thanks, this info will be useful.

Note that the hotness calculation will be in userspace, as only there
are the necessary counters available. So the finished hotness score
will be passed to the kernel, instead of sending all the necessary data
there. Ought to be less context switches that way.

- Lauri

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

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

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

--- Comment #61 from Alexandre Demers  ---
(In reply to comment #60)
> Instead of triggering the power level switches by running GpuTest in bursts,
> I put this in a bash script:
> 
> for i in {1..3600}
> do
>echo low > /sys/class/drm/card0/device/power_dpm_force_performance_level
>sleep 1
>echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level
>sleep 5
> done
> 
> and just let GpuTest, and piglit, run continously. I found that this also
> trigger the lockups within minutes.
> 
> Then I ran the script by itself, no GpuTest or piglit, and left it running
> while I was at work. When I came home the machine was still running, so it
> ran for six hours without any lockup. So it seems the power level switching
> alone is not sufficient to trigger the lockups, it also needs a load of some
> sort.

Do you mean while spread spectrum is still enabled?

-- 
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/20131209/b62c1622/attachment.html>

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

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

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

--- Comment #62 from Martin Andersson  ---
(In reply to comment #61)
> (In reply to comment #60)
> > Instead of triggering the power level switches by running GpuTest in bursts,
> > I put this in a bash script:
> > 
> > for i in {1..3600}
> > do
> >echo low > /sys/class/drm/card0/device/power_dpm_force_performance_level
> >sleep 1
> >echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level
> >sleep 5
> > done
> > 
> > and just let GpuTest, and piglit, run continously. I found that this also
> > trigger the lockups within minutes.
> > 
> > Then I ran the script by itself, no GpuTest or piglit, and left it running
> > while I was at work. When I came home the machine was still running, so it
> > ran for six hours without any lockup. So it seems the power level switching
> > alone is not sufficient to trigger the lockups, it also needs a load of some
> > sort.
> 
> Do you mean while spread spectrum is still enabled?

Yes

-- 
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/20131209/5fddd7c4/attachment.html>

[RFC patch v2] x86: Improve boot_vga/vga_default_device() for EFI

[Bjorn Helgaas]

On Sat, Nov 30, 2013 at 6:52 AM, Bruno Pr?mont
 wrote:
> With commit b4aa0163056b6c70029b6e8619ce07c274351f42 Matthew Garret
> introduced a efifb vga_default_device() so that EFI systems that do not
> load shadow VBIOS or setup VGA get proper value for boot_vga PCI sysfs
> attribute on the corresponding PCI device.

I like the fact that this gets back to a single vga_default_device()
implementation.  But of course Matthew could easily have done this to
begin with, so I would defer to his judgment about this.

I also like the fact that you do this in pci_fixup_video(), where
we're already doing similar stuff.  The ia64 version should be changed
the same way (or better yet, consolidated) unless there's some reason
they need to be different.  There is a little "dig" and "hpzx1" gunk
in the ia64 version that could be factored out into some sort of
__weak architecture function.

> Xorg is refusing to detect devices when boot_vga=0 which is the case
> on some EFI system (e.g. MacBookAir2,1). Xorg detects the GPU and finds
> the dri device but then bails out with "no devices detected".
>
> With introduction of sysfb/simplefb/simpledrm efifb is getting obsolete
> while having native drivers for the GPU also makes selecting sysfb/efifb
> optional.
>
> Remove the efifb implementation of vga_default_device() and initialize
> vgaarb's vga_default_device() with the PCI GPU that matches boot
> screen_info in x86's pci_fixup_video().
>
> Notes:
> - Other architectures with PCI GPU might need a similar fixup.
> - If CONFIG_VGA_ARB is unset vga_default_device() is only available
>   as a stub that returns NULL, making this adjustment insufficient.
>   Unsetting CONFIG_VGA_ARB requires CONFIG_EXPERT=y though.
>
> Signed-off-by: Bruno Pr?mont 
> ---
>  arch/x86/include/asm/vga.h |  6 --
>  arch/x86/pci/fixup.c   | 21 +
>  drivers/video/efifb.c  | 38 --
>  3 files changed, 21 insertions(+), 44 deletions(-)
>
> diff --git a/arch/x86/include/asm/vga.h b/arch/x86/include/asm/vga.h
> index 44282fb..c4b9dc2 100644
> --- a/arch/x86/include/asm/vga.h
> +++ b/arch/x86/include/asm/vga.h
> @@ -17,10 +17,4 @@
>  #define vga_readb(x) (*(x))
>  #define vga_writeb(x, y) (*(y) = (x))
>
> -#ifdef CONFIG_FB_EFI
> -#define __ARCH_HAS_VGA_DEFAULT_DEVICE
> -extern struct pci_dev *vga_default_device(void);
> -extern void vga_set_default_device(struct pci_dev *pdev);
> -#endif
> -
>  #endif /* _ASM_X86_VGA_H */
> diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
> index f5809fa..440343e 100644
> --- a/arch/x86/pci/fixup.c
> +++ b/arch/x86/pci/fixup.c
> @@ -6,6 +6,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>
> @@ -323,6 +324,26 @@ static void pci_fixup_video(struct pci_dev *pdev)
> struct pci_bus *bus;
> u16 config;
>
> +   if (!vga_default_device()) {
> +   resource_size_t start, end;
> +   int i;
> +
> +   for (i=0; i < DEVICE_COUNT_RESOURCE; i++) {
> +   if (!(pci_resource_flags(pdev, i) & IORESOURCE_MEM))
> +   continue;
> +
> +   start = pci_resource_start(pdev, i);
> +   end  = pci_resource_end(pdev, i);
> +
> +   if (!start || !end)
> +   continue;
> +
> +   if (screen_info.lfb_base >= start &&
> +   (screen_info.lfb_base + screen_info.lfb_size) 
> < end)
> +   vga_set_default_device(pdev);
> +   }
> +   }
> +
> /* Is VGA routed to us? */
> bus = pdev->bus;
> while (bus) {
> diff --git a/drivers/video/efifb.c b/drivers/video/efifb.c
> index 7f9ff75..fb3fb50 100644
> --- a/drivers/video/efifb.c
> +++ b/drivers/video/efifb.c
> @@ -19,8 +19,6 @@
>
>  static bool request_mem_succeeded = false;
>
> -static struct pci_dev *default_vga;
> -
>  static struct fb_var_screeninfo efifb_defined = {
> .activate   = FB_ACTIVATE_NOW,
> .height = -1,
> @@ -85,18 +83,6 @@ static struct fb_ops efifb_ops = {
> .fb_imageblit   = cfb_imageblit,
>  };
>
> -struct pci_dev *vga_default_device(void)
> -{
> -   return default_vga;
> -}
> -
> -EXPORT_SYMBOL_GPL(vga_default_device);
> -
> -void vga_set_default_device(struct pci_dev *pdev)
> -{
> -   default_vga = pdev;
> -}
> -
>  static int efifb_setup(char *options)
>  {
> char *this_opt;
> @@ -127,30 +113,6 @@ static int efifb_setup(char *options)
> }
> }
>
> -   for_each_pci_dev(dev) {
> -   int i;
> -
> -   if ((dev->class >> 8) != PCI_CLASS_DISPLAY_VGA)
> -   continue;
> -
> -   for (i=0; i < DEVICE_COUNT_RESOURCE; i++) {
> -   resource_size_t start, end;
> -
> -   if (!(pci_resource_flags(dev, i) & IORESOURCE_

TTM's role in score-based eviction

[Marek Olšák]

On Mon, Dec 9, 2013 at 9:30 PM, Lauri Kasanen  wrote:
> On Mon, 9 Dec 2013 20:28:21 +0100
> Marek Ol??k  wrote:
>
> Hi,
>
>> FYI, since the userspace driver sends end-of-frame markers to the
>> kernel, the radeon kernel driver knows the current frame number and it
>> can also save the frame number of the last use of each buffer. We
>> should definitely use that to measure the buffer hotness, or just
>> prevent eviction if the buffer was used recently (the last 2 or 3
>> frames) and you can drop the hotness calculations entirely.
>
> I think this would result in sub-optimal behavior with one client, but
> a workload larger than VRAM. If everything is needed in one frame, then
> this logic would almost randomly decide what gets to stay.
>
>> Also, MSAA buffers and depth buffers should have higher probability of
>> being placed in VRAM than other buffers, because their placement has
>> higher impact on performance. They also tend to contain auxiliary data
>> which significantly improve performance, like fast clear data, MSAA
>> fragment coverage data, and hierarchical depth and stencil data. We
>> can add a new ioctl which sets buffer usage flags.
>
> Thanks, this info will be useful.
>
> Note that the hotness calculation will be in userspace, as only there
> are the necessary counters available. So the finished hotness score
> will be passed to the kernel, instead of sending all the necessary data
> there. Ought to be less context switches that way.

This sounds good, but you will also need to update the DDX for
everything up to and including Cayman. Hopefully the DDX doesn't emit
IBs outside of glamor on Southern Islands and later chips.

Marek

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

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

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

--- Comment #63 from Alex Deucher  ---
Created attachment 90542
  --> https://bugs.freedesktop.org/attachment.cgi?id=90542&action=edit
possible fix

Thanks for tracking this down.  The attached patch should fix the issue.  With
this fixed, it may be worth checking to see if you can reliably use the tweaked
clocks on certain oem boards (basically disable the ni code added to fix bug
69723).

-- 
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/20131209/dd93acdb/attachment.html>

[PATCH 1/3] drm: Add LCD display clock polarity flags

[Marek Vasut]

On Tuesday, December 03, 2013 at 12:44:52 PM, Shawn Guo wrote:
> On Mon, Dec 02, 2013 at 04:39:26PM +0100, Marek Vasut wrote:
> > Add DRM flags for the LCD display clock polarity so the pixelclk-active
> > DT property can be properly handled by drivers using the DRM API.
> > 
> > Signed-off-by: Marek Vasut 
> > Cc: Dave Airlie 
> > Cc: Greg Kroah-Hartman 
> > Cc: Philipp Zabel 
> > Cc: Sascha Hauer 
> > Cc: Shawn Guo 
> > ---
> > 
> >  drivers/gpu/drm/drm_modes.c | 5 +
> >  include/uapi/drm/drm_mode.h | 3 +++
> >  2 files changed, 8 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> > index 85071a1..d1f3bfc 100644
> > --- a/drivers/gpu/drm/drm_modes.c
> > +++ b/drivers/gpu/drm/drm_modes.c
> > @@ -537,6 +537,11 @@ int drm_display_mode_from_videomode(const struct
> > videomode *vm,
> > 
> > dmode->flags |= DRM_MODE_FLAG_DBLSCAN;
> > 
> > if (vm->flags & DISPLAY_FLAGS_DOUBLECLK)
> > 
> > dmode->flags |= DRM_MODE_FLAG_DBLCLK;
> > 
> > +   if (vm->flags & DISPLAY_FLAGS_PIXDATA_POSEDGE)
> > +   dmode->flags |= DRM_MODE_FLAG_PIXELCLK_PPOL;
> > +   else if (vm->flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE)
> > +   dmode->flags |= DRM_MODE_FLAG_PIXELCLK_NPOL;
> > +
> > 
> > drm_mode_set_name(dmode);
> > 
> > return 0;
> > 
> > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > index f104c26..a6169ca 100644
> > --- a/include/uapi/drm/drm_mode.h
> > +++ b/include/uapi/drm/drm_mode.h
> > @@ -73,6 +73,9 @@
> > 
> >  #define  DRM_MODE_FLAG_3D_TOP_AND_BOTTOM   (7<<14)
> >  #define  DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF(8<<14)
> > 
> > +/* CRTC LCD clock polarity flags. */
> > +#define DRM_MODE_FLAG_PIXELCLK_PPOL(1<<19)
> > +#define DRM_MODE_FLAG_PIXELCLK_NPOL(1<<20)
> 
> Marek,
> 
> It looks that Denis (copied) is working on the same problem, so you may
> want to be aware of his effort [1][2].

He also just sent a new patchset, so I would focus on his work instead. It 
makes 
more sense as he is not breaking the userland stuff.

Thank you Shawn, Russell!

Best regards,
Marek Vasut

[RFC v2 PATCH] mipi-dsi-bus: add MIPI DSI bus support

[Tomi Valkeinen]

 things like that. But I have never seen a
DSI device that can be configured in such a way. Have you?

> In that case you still need some way to specify the VC on a per-board
> basis, either in DT or "platform data".

I'm not saying we should prevent that kind of device from working. But
if all the known devices use a fixed VC ID scheme, maybe there's not
much point in requiring to enter the VC ID manually in all the dts
files. If there's a device with configurable VC ID, it can still be
supported by custom DT properties.

>> I don't see why the DSI host driver would need to know the VC IDs, as
>> it can't really do anything independently with the peripheral anyway.
>> All the transactions should be started by the DSI peripheral driver.
> 
> There are things that are standardized in DSI. The core could for
> instance try to probe peripherals by reading the DDB.

That's not part of DSI. It's part of DCS. Not all devices support DCS,
or they may support only some parts of it. Also the devices usually need
regulator setup, resetting via gpios, or other similar setup which makes
automatic probing not an option.

> But even that aside, we'll still need some way to store a device's VC
> number somewhere. Even if the DSI host doesn't have any explicit
> knowledge about it, you still need to pass it along when you want to
> send a message to a device. So when you start a transaction from within
> a device driver, you still need to get the VC number from somewhere.

Yep.

> The proposal is to store that number in struct mipi_dsi_device. It's a
> logical choice because it is something that characterises a device. It
> is also a property of every device, so by storing it within a common
> structure gives drivers a standard way of accessing it instead of having
> each driver come up with it's own way to store it.

Yep, that sounds fine to me if mipi_dsi_device is not a linux device
(but it is in this patch).

I'll try to summarize my view on mipi dsi:

DSI is a video bus. It can be used for control, but it's main purpose is
as a video data bus. Video has rather strict timing requirements, which
means control messages have to be done in a controlled manner.

DSI devices quite often have another control bus, usually i2c. I guess
the reason to support i2c in addition to DSI is the timing restrictions
on the DSI control bus. If the DSI device is represented as a linux DSI
device on a linux DSI bus, supporting the i2c is difficult.

It is possible to have multiple DSI devices behind a single DSI
connection, but it is not a generic solution, and requires one to use
the DSI peripherals in a very controlled manner to make sure no DSI
device is blocking the other ones for too long. I have not seen these in
production, and while I'm just guessing, the reason may be that is so
difficult to make them work well.

The only standard part of DSI, in my experience, is the DSI packet layer
(maybe there's a better term for it). Anything else is often custom. For
this reason I think the DSI peripheral driver has to be in full control
of the device, and the DSI bus cannot really do anything by itself.

There's not much "bus" in DSI in my opinion. No probing, one-to-one
links, very limited "address space", all the cases I know have just one
DSI device...

So... While having a Linux DSI bus, etc. would feel elegant and nice, I
just feel it's not easy and not worth it.

What we have in omapdss is far from perfect, but it has been working
quite nicely. DSI is considered just as a data bus, with extra
functionality for sending control messages. A DSI device is either a
platform device if it requires no control or the control is done via
DSI, or it's a device of the control bus like i2c.

All that said, I may be mentally stuck in the old models I've been using
for a long time, so maybe a different approach for DSI is good. We just
need to make sure the existing devices can be supported.

 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/20131209/26b5c8a2/attachment-0001.pgp>

[RFC v2 PATCH] mipi-dsi-bus: add MIPI DSI bus support

[Tomi Valkeinen]

On 2013-12-09 15:10, Thierry Reding wrote:

>> No idea. But I have worked with a device, that used VC0 for the device's
>> configuration registers, VC1 for buffer commands (the device had a
>> framebuffer), VC2 and VC3 for panels connected to that device.
> 
> Well, VC2 and VC3 certainly sound like logically separate devices to me.
> If they are only connected to the device it sounds like they aren't part
> of the device at all.

Yes, the two panels are obviously separate devices.

> One could even argue that a device's configuration and the framebuffer
> are logically separate and therefore it wouldn't be a problem to address
> them as separate devices.

True. But one could also argue that handling them with separate linux
devices just causes unnecessary complexity.

 So I think we should consider DSI as a one-to-one link, and let the DSI
 peripheral manage the VC IDs as it wants.
>>>
>>> But doing so would prevent us from supporting setups where we have two
>>> separate peripherals with different VC numbers.
>>
>> No it wouldn't. We could still communicate with the extra peripherals
>> via the hub device. What I was trying to say is that we shouldn't think
>> or model DSI with multiple devices as multiple devices connected to the
>> same DSI bus. Instead, it should be seen as a tree of one-to-one links
>> (as it is in the HW).
> 
> But even if you have a tree of one-to-one links, you still need some way
> to address the individual nodes in the tree. The VC ID is the only way
> by which you can address a node. I don't see how you can possible send
> packets to more than one node if you keep sending packets to the same
> address. Where does the missing information magically come from?

[PATCH] drm/radeon: Disable writeback by default on ppc

[Alex Deucher]

On Fri, Dec 6, 2013 at 10:59 AM, Alex Deucher  wrote:
> On Fri, Dec 6, 2013 at 8:58 AM, Kleber Sacilotto de Souza
>  wrote:
>> On 12/05/2013 12:42 PM, Alex Deucher wrote:
>>>
>>> Well, we'd need to start swapping indirect buffers and the ring as
>>> well then which would get tricky as the CP at least does not have
>>> separate swapping controls for different things.  Probably easier to
>>> fix up as appropriate for different asic families.  We have function
>>> pointers for the rtpr and wptr fetchers now, so we can do this pretty
>>> cleanly.
>>>
>>> Alex
>>
>>
>> Alex,
>>
>> Are you going to send a patch to fix this?
>>
>> If not, I don't have the knowledge of which asic families will need this
>> fix, but if you inform me what needs to be done I can write the patch.
>
> I'll try and send a patch out in the next few days.

Patch attached.  Compile tested only at the moment.

Alex

>
> Alex
>
>>
>>
>> Thanks,
>>
>>
>> --
>> Kleber Sacilotto de Souza
>> IBM Linux Technology Center
>>
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-remove-generic-rptr-wptr-functions.patch
Type: text/x-diff
Size: 33710 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131209/8e8c8fda/attachment-0001.patch>

[PATCH] gpu: host1x: clk_round_rate() can return a zero upon error

[Paul Walmsley]

Treat both negative and zero return values from clk_round_rate() as
errors.  This is needed since subsequent patches will convert
clk_round_rate()'s return value to be an unsigned type, rather than a
signed type, since some clock sources can generate rates higher than
(2^31)-1 Hz.

Eventually, when calling clk_round_rate(), only a return value of zero
will be considered a error.  All other values will be considered valid
rates.  The comparison against values less than 0 is kept to preserve
the correct behavior in the meantime.

Signed-off-by: Paul Walmsley 
Cc: Mikko Perttunen 
Cc: Arto Merilainen 
Cc: Thierry Reding 
Cc: Terje Bergstr?m 
---
Applies on v3.13-rc3.  See also:

http://marc.info/?l=linux-arm-kernel&m=138542591313620&w=2

  drivers/gpu/drm/tegra/hdmi.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tegra/hdmi.c b/drivers/gpu/drm/tegra/hdmi.c
index 0cd9bc2056e8..8cf9d3aeb0cd 100644
--- a/drivers/gpu/drm/tegra/hdmi.c
+++ b/drivers/gpu/drm/tegra/hdmi.c
@@ -959,7 +959,7 @@ static int tegra_output_hdmi_check_mode(struct tegra_output 
*output,
parent = clk_get_parent(hdmi->clk_parent);

err = clk_round_rate(parent, pclk * 4);
-   if (err < 0)
+   if (err <= 0)
*status = MODE_NOCLOCK;
else
*status = MODE_OK;