[Bug 88745] [RADEONSI] [LLVM] [bisected] GPU hang when running Lightsmark

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

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

--- Comment #3 from Arek Ruśniak  ---
This is very strange things Tom. This morning i tried mesa-git 2397a72 &
llvm-svn r227384 without success. 
Now i've tried mesa-git 765cfe9 & llvm-svn r227463 and there is no gpu faults
anymore. 

I'll tried latest llvm-svn ASAP. 
If you need dumps still i'll do it. But problems are gone for now.

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

[Bug 88745] [RADEONSI] [LLVM] [bisected] GPU hang when running Lightsmark

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

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

--- Comment #2 from Tom Stellard  ---
Could you set the environment variable R600_DEBUG=ps,vs,gs and post the dumps
for both good and bad behavior?

-- 
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/20150129/7f0e95cc/attachment.html>

[RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms

[Russell King - ARM Linux]

On Thu, Jan 29, 2015 at 05:18:33PM -0500, Rob Clark wrote:
> On Thu, Jan 29, 2015 at 2:26 PM, Russell King - ARM Linux
>  wrote:
> > Now, if we're going to do the "more clever" thing you mention above,
> > that rather negates the point of this two-part patch set, which is to
> > provide the union of the DMA capabilities of all users.  A union in
> > that case is no longer sane as we'd be tailoring the SG lists to each
> > user.
> 
> It doesn't really negate.. a different sg list representing the same
> physical memory cannot suddenly make the buffer physically contiguous
> (from the perspective of memory)..
> 
> (unless we are not on the same page here, so to speak)

If we are really only interested in the "physically contiguous" vs
"scattered" differentiation, why can't this be just a simple flag?

I think I know where you're coming from on that distinction - most
GPUs can cope with their buffers being discontiguous in memory, but
scanout and capture hardware tends to need contiguous buffers.

My guess is that you're looking for some way that a GPU driver could
allocate a buffer, which can then be imported into the scanout
hardware - and when it is, the underlying backing store is converted
to a contiguous buffer.  Is that the usage scenario you're thinking
of?

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

[RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms

[Sumit Semwal]

On 29 January 2015 at 21:17, Russell King - ARM Linux
 wrote:
> On Thu, Jan 29, 2015 at 09:00:11PM +0530, Sumit Semwal wrote:
>> So, short answer is, it is left to the exporter to decide. The dma-buf
>> framework should not even attempt to decide or enforce any of the
>> above.
>>
>> At each dma_buf_attach(), there's a callback to the exporter, where
>> the exporter can decide, if it intends to handle these kind of cases,
>> on the best way forward.
>>
>> The exporter might, for example, decide to migrate backing storage,
>
> That's a decision which the exporter can not take.  Think about it...
>
> If subsystem Y has mapped the buffer, it could be accessing the buffer's
> backing storage at the same time that subsystem Z tries to attach to the
> buffer.
>
Well, first up, of course the 'migration of backing storage' is an
orthogonal problem to what this patchset attempts to do - in this, I
am only try to make the relevant information available to the
exporter.

With that out of the way, some thoughts on what you mentioned:

So, IF the exporter needs to support migration of backing storage,
even when subsystem Y has mapped the buffer, the exporter knows this
(because of the map_dma_buf() dma_buf_op) - and the attach() also is
notified to / handled by the exporter. With this information, it could
either:
a) not let the subsystem Z attach (the 'simpler' approach), or
b) hold enough state-information about the Z's attach request
internally, then migrate the pages on the unmap_attachment() callback
from the subsystem Y?

(The exact details for this will need to be thought-of by exporters
actually trying to do migration of pages, or delayed allocation, or
such, though)

> Once the buffer has been exported to another user, the exporter has
> effectively lost control over mediating accesses to that buffer.
>
> All that it can do with the way the dma-buf API is today is to allocate
> a _different_ scatter list pointing at the same backing storage which
> satisfies the segment size and number of segments, etc.
>
> There's also another issue which you haven't addressed.  What if several
> attachments result in lowering max_segment_size and max_segment_count
> such that:
>
> max_segment_size * max_segment_count < dmabuf->size
>
> but individually, the attachments allow dmabuf->size to be represented
> as a scatterlist?
>
> If an exporter were to take notice of the max_segment_size and
> max_segment_count, the resulting buffer is basically unrepresentable
> as a scatterlist.

Thanks for pointing that out; I guess we'd have to disallow the
attachment which would make that happen. I can add this as another
check in calc_constraints().

>
>> > Please consider the possible sequences of use (such as the scenario
>> > above) when creating or augmenting an API.
>> >
>>
>> I tried to think of the scenarios I could think of, but If you still
>> feel this approach doesn't help with your concerns, I'll graciously
>> accept advice to improve it.
>
> See the new one above :)
>
Another thanks for making me rack my puny brain on these scenarios! :)
[though I strongly suspect I might not have done enough!]
> --
> FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
> according to speedtest.net.

BR,
~Sumit.

[Bug 91861] [Radeon RS780] Blank screen (no signal) on HDMI after boot in 3.15 & later

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

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

--- Comment #8 from Mike S.  ---
Thanks for the explanation.

Can I suggest that you delay committing this patch for a week or so - I want to
check that it is really stable. Yesterday I had one incident where the screen
froze with diagonal coloured stripes for a couple of seconds, which I have
never seen before. It recovered itself OK without having to re-boot. Could this
have been caused by the higher divider values?

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

[RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms

[Sumit Semwal]

Hi Russell!

On 29 January 2015 at 20:09, Russell King - ARM Linux
 wrote:
> On Tue, Jan 27, 2015 at 01:55:54PM +0530, Sumit Semwal wrote:
>> +/*
>> + * recalc_constraints - recalculates constraints for all attached devices;
>> + *  useful for detach() recalculation, and for dma_buf_recalc_constraints()
>> + *  helper.
>> + *  Returns recalculated constraints in recalc_cons, or error in the 
>> unlikely
>> + *  case when constraints of attached devices might have changed.
>> + */
>
Thanks for your valuable review comments!

> Please see kerneldoc documentation for the proper format of these comments.
These are static functions, and as such kerneldoc doesn't enforce
kernel-doc style comments, so in the dma-buf files, we've not followed
them for static functions.
That said, it is certainly a valuable advice, and I could create a
separate patch-set for updating the documentation for the static
functions as well.
>
>> +static int recalc_constraints(struct dma_buf *dmabuf,
>> +   struct device_dma_parameters *recalc_cons)
>> +{
>> + struct device_dma_parameters calc_cons;
>> + struct dma_buf_attachment *attach;
>> + int ret = 0;
>> +
>> + init_constraints(_cons);
>> +
>> + list_for_each_entry(attach, >attachments, node) {
>> + ret = calc_constraints(attach->dev, _cons);
>> + if (ret)
>> + return ret;
>> + }
>> + *recalc_cons = calc_cons;
>> + return 0;
>> +}
>> +
>>  /**
>>   * dma_buf_export_named - Creates a new dma_buf, and associates an anon file
>>   * with this buffer, so it can be exported.
>> @@ -313,6 +373,9 @@ struct dma_buf *dma_buf_export_named(void *priv, const 
>> struct dma_buf_ops *ops,
>>   dmabuf->ops = ops;
>>   dmabuf->size = size;
>>   dmabuf->exp_name = exp_name;
>> +
>> + init_constraints(>constraints);
>> +
>>   init_waitqueue_head(>poll);
>>   dmabuf->cb_excl.poll = dmabuf->cb_shared.poll = >poll;
>>   dmabuf->cb_excl.active = dmabuf->cb_shared.active = 0;
>> @@ -422,7 +485,7 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf 
>> *dmabuf,
>> struct device *dev)
>>  {
>>   struct dma_buf_attachment *attach;
>> - int ret;
>> + int ret = 0;
>>
>>   if (WARN_ON(!dmabuf || !dev))
>>   return ERR_PTR(-EINVAL);
>> @@ -436,6 +499,9 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf 
>> *dmabuf,
>>
>>   mutex_lock(>lock);
>>
>> + if (calc_constraints(dev, >constraints))
>> + goto err_constraints;
>> +
>>   if (dmabuf->ops->attach) {
>>   ret = dmabuf->ops->attach(dmabuf, dev, attach);
>>   if (ret)
>> @@ -448,6 +514,7 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf 
>> *dmabuf,
>>
>>  err_attach:
>>   kfree(attach);
>> +err_constraints:
>>   mutex_unlock(>lock);
>>   return ERR_PTR(ret);
>>  }
>> @@ -470,6 +537,8 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct 
>> dma_buf_attachment *attach)
>>   if (dmabuf->ops->detach)
>>   dmabuf->ops->detach(dmabuf, attach);
>>
>> + recalc_constraints(dmabuf, >constraints);
>> +
>
> To me, this whole thing seems horribly racy.
>
> What happens if subsystem X creates a dmabuf, which is passed to
> userspace. It's then passed to subsystem Y, which starts making use
> of it, calling dma_buf_map_attachment() on it.
>
> The same buffer is also passed (via unix domain sockets) to another
> program, which then passes it independently into subsystem Z, and
> subsystem Z has more restrictive DMA constraints.
>
> What happens at this point?
>
> Subsystems such as DRM cache the scatter table, and return it for
> subsequent attach calls, so DRM drivers using the default
> drm_gem_map_dma_buf() implementation would not see the restrictions
> placed upon the dmabuf.  Moreover, the returned scatterlist would not
> be modified for those restrictions either.
>
> What would other subsystems do?
>
> This needs more thought before it's merged.
>
> For example, in the above situation, should we deny the ability to
> create a new attachment when a dmabuf has already been mapped by an
> existing attachment?  Should we deny it only when the new attachment
> has more restrictive DMA constraints?
>
So, short answer is, it is left to the exporter to decide. The dma-buf
framework should not even attempt to decide or enforce any of the
above.

At each dma_buf_attach(), there's a callback to the exporter, where
the exporter can decide, if it intends to handle these kind of cases,
on the best way forward.

The exporter might, for example, decide to migrate backing storage,
should there be a need to do so, or simply deny when the new
attachment has more restrictive DMA constraints, as you mentioned as a
possibility.

These changes simply allow the exporter, should it wish to, to take
the DMA constraints into consideration while making those decisions.
For the current cases, it 

[Bug 88364] Xorg hangs after videocard switching

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

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

--- Comment #4 from Liss  ---
(In reply to Michel Dänzer from comment #3)
> (In reply to Liss from comment #2)
> > If I restart notebook and try to run something again I'll get black window
> > (Xorg will continue to work)
> 
> Note that DRI_PRIME currently requires a compositing manager for the
> contents to be visible.

I'm using Mutter as WM, so there shouldn't be any problems with compositing.

-- 
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/20150129/5055b414/attachment.html>

[PATCH 2/2] drm/exynos: solve plane on/off disharmory issue

[Joonyoung Shim]

The exynos_update_plane functions can be called from set_plane as well
as set_crtc and pageflip. Currently the plane displayed by set_plane
isn't called exynos_plane_on function and if plane is disabled, it calls
exynos_plane_off, so it causes disharmory of plane on/off.

This is caused from commit e7cd8041 ("drm/exynos: Don't touch DPMS
when updating overlay planes").

Make .update_plane function called only by set_plane and call
exynos_plane_on in it.

Signed-off-by: Joonyoung Shim 
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c  |  4 ++--
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 21 -
 drivers/gpu/drm/exynos/exynos_drm_plane.h |  2 +-
 3 files changed, 23 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index dac8f90..2765f7e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -129,7 +129,7 @@ static int exynos_drm_crtc_mode_set_base(struct drm_crtc 
*crtc, int x, int y,
crtc_w = fb->width - x;
crtc_h = fb->height - y;

-   return exynos_update_plane(crtc->primary, crtc, fb, 0, 0,
+   return exynos_plane_update(crtc->primary, crtc, fb, 0, 0,
   crtc_w, crtc_h, x, y, crtc_w, crtc_h);
 }

@@ -203,7 +203,7 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc,
crtc->primary->fb = fb;
crtc_w = fb->width - crtc->x;
crtc_h = fb->height - crtc->y;
-   ret = exynos_update_plane(crtc->primary, crtc, fb, 0, 0,
+   ret = exynos_plane_update(crtc->primary, crtc, fb, 0, 0,
  crtc_w, crtc_h, crtc->x, crtc->y,
  crtc_w, crtc_h);
if (ret) {
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index aa87d79..88674d9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -176,7 +176,7 @@ void exynos_plane_off(struct drm_plane *plane)
 }

 int
-exynos_update_plane(struct drm_plane *plane, struct drm_crtc *crtc,
+exynos_plane_update(struct drm_plane *plane, struct drm_crtc *crtc,
 struct drm_framebuffer *fb, int crtc_x, int crtc_y,
 unsigned int crtc_w, unsigned int crtc_h,
 uint32_t src_x, uint32_t src_y,
@@ -201,6 +201,25 @@ exynos_update_plane(struct drm_plane *plane, struct 
drm_crtc *crtc,
return 0;
 }

+static int
+exynos_update_plane(struct drm_plane *plane, struct drm_crtc *crtc,
+struct drm_framebuffer *fb, int crtc_x, int crtc_y,
+unsigned int crtc_w, unsigned int crtc_h,
+uint32_t src_x, uint32_t src_y,
+uint32_t src_w, uint32_t src_h)
+{
+   int ret;
+
+   ret = exynos_plane_update(plane, crtc, fb, crtc_x, crtc_y,
+ crtc_w, crtc_h, src_x, src_y, src_w, src_h);
+   if (ret < 0)
+   return ret;
+
+   exynos_plane_on(plane);
+
+   return 0;
+}
+
 static int exynos_disable_plane(struct drm_plane *plane)
 {
exynos_plane_off(plane);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.h 
b/drivers/gpu/drm/exynos/exynos_drm_plane.h
index c778295..239eff5 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.h
@@ -15,7 +15,7 @@ void exynos_plane_mode_set(struct drm_plane *plane, struct 
drm_crtc *crtc,
   unsigned int crtc_w, unsigned int crtc_h,
   uint32_t src_x, uint32_t src_y,
   uint32_t src_w, uint32_t src_h);
-int exynos_update_plane(struct drm_plane *plane, struct drm_crtc *crtc,
+int exynos_plane_update(struct drm_plane *plane, struct drm_crtc *crtc,
struct drm_framebuffer *fb, int crtc_x, int crtc_y,
unsigned int crtc_w, unsigned int crtc_h,
uint32_t src_x, uint32_t src_y,
-- 
1.9.1

[PATCH 1/2] drm/exynos: split exynos_plane_dpms function

[Joonyoung Shim]

The exynos_plane_dpms can cause misunderstanding as using dpms term
because it is irrelevant with dpms functionality of DRM. Split to
functions fit for the one purpose instead of DPMS flags.

Signed-off-by: Joonyoung Shim 
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c  |  4 ++--
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 38 +--
 drivers/gpu/drm/exynos/exynos_drm_plane.h |  3 ++-
 3 files changed, 25 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index a85c451..dac8f90 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -67,7 +67,7 @@ static void exynos_drm_crtc_commit(struct drm_crtc *crtc)
if (exynos_crtc->ops->commit)
exynos_crtc->ops->commit(exynos_crtc);

-   exynos_plane_dpms(crtc->primary, DRM_MODE_DPMS_ON);
+   exynos_plane_on(crtc->primary);
 }

 static bool
@@ -255,7 +255,7 @@ static int exynos_drm_crtc_set_property(struct drm_crtc 
*crtc,
exynos_drm_crtc_commit(crtc);
break;
case CRTC_MODE_BLANK:
-   exynos_plane_dpms(crtc->primary, DRM_MODE_DPMS_OFF);
+   exynos_plane_off(crtc->primary);
break;
default:
break;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index 358cff6..aa87d79 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -145,30 +145,34 @@ void exynos_plane_mode_set(struct drm_plane *plane, 
struct drm_crtc *crtc,
exynos_crtc->ops->win_mode_set(exynos_crtc, exynos_plane);
 }

-void exynos_plane_dpms(struct drm_plane *plane, int mode)
+void exynos_plane_on(struct drm_plane *plane)
 {
struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(plane->crtc);

-   if (mode == DRM_MODE_DPMS_ON) {
-   if (exynos_plane->enabled)
-   return;
+   if (exynos_plane->enabled)
+   return;

-   if (exynos_crtc->ops->win_enable)
-   exynos_crtc->ops->win_enable(exynos_crtc,
-exynos_plane->zpos);
+   if (exynos_crtc->ops->win_enable)
+   exynos_crtc->ops->win_enable(exynos_crtc,
+exynos_plane->zpos);

-   exynos_plane->enabled = true;
-   } else {
-   if (!exynos_plane->enabled)
-   return;
+   exynos_plane->enabled = true;
+}

-   if (exynos_crtc->ops->win_disable)
-   exynos_crtc->ops->win_disable(exynos_crtc,
- exynos_plane->zpos);
+void exynos_plane_off(struct drm_plane *plane)
+{
+   struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
+   struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(plane->crtc);

-   exynos_plane->enabled = false;
-   }
+   if (!exynos_plane->enabled)
+   return;
+
+   if (exynos_crtc->ops->win_disable)
+   exynos_crtc->ops->win_disable(exynos_crtc,
+ exynos_plane->zpos);
+
+   exynos_plane->enabled = false;
 }

 int
@@ -199,7 +203,7 @@ exynos_update_plane(struct drm_plane *plane, struct 
drm_crtc *crtc,

 static int exynos_disable_plane(struct drm_plane *plane)
 {
-   exynos_plane_dpms(plane, DRM_MODE_DPMS_OFF);
+   exynos_plane_off(plane);

return 0;
 }
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.h 
b/drivers/gpu/drm/exynos/exynos_drm_plane.h
index 59d4075..c778295 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.h
@@ -20,7 +20,8 @@ int exynos_update_plane(struct drm_plane *plane, struct 
drm_crtc *crtc,
unsigned int crtc_w, unsigned int crtc_h,
uint32_t src_x, uint32_t src_y,
uint32_t src_w, uint32_t src_h);
-void exynos_plane_dpms(struct drm_plane *plane, int mode);
+void exynos_plane_on(struct drm_plane *plane);
+void exynos_plane_off(struct drm_plane *plane);
 struct drm_plane *exynos_plane_init(struct drm_device *dev,
unsigned long possible_crtcs,
enum drm_plane_type type);
-- 
1.9.1

[PATCH V9 12/14] drm/bridge: Add i2c based driver for ps8622/ps8625 bridge

[Ajay kumar]

Hi Thierry,

I think you forgot to take this patch!
Can you check this?

Regards,
Ajay Kumar


On Tue, Jan 20, 2015 at 10:08 PM, Ajay Kumar  
wrote:
> From: Vincent Palatin 
>
> This patch adds drm_bridge driver for parade DisplayPort
> to LVDS bridge chip.
>
> Signed-off-by: Vincent Palatin 
> Signed-off-by: Andrew Bresticker 
> Signed-off-by: Sean Paul 
> Signed-off-by: Rahul Sharma 
> Signed-off-by: Ajay Kumar 
> Acked-by: Inki Dae 
> Tested-by: Rahul Sharma 
> Tested-by: Javier Martinez Canillas 
> Tested-by: Gustavo Padovan 
> Tested-by: Sjoerd Simons 
> ---
>  drivers/gpu/drm/bridge/Kconfig  |9 +
>  drivers/gpu/drm/bridge/Makefile |1 +
>  drivers/gpu/drm/bridge/ps8622.c |  684 
> +++
>  3 files changed, 694 insertions(+)
>  create mode 100644 drivers/gpu/drm/bridge/ps8622.c
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 8b426e2..d06eda3 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -6,3 +6,12 @@ config DRM_PTN3460
> select DRM_PANEL
> ---help---
>   ptn3460 eDP-LVDS bridge chip driver.
> +
> +config DRM_PS8622
> +   tristate "Parade eDP/LVDS bridge"
> +   depends on OF && I2C
> +   select DRM_PANEL
> +   select BACKLIGHT_LCD_SUPPORT
> +   select BACKLIGHT_CLASS_DEVICE
> +   ---help---
> + parade eDP-LVDS bridge chip driver.
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index b4733e1..105da3e 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -1,3 +1,4 @@
>  ccflags-y := -Iinclude/drm
>
> +obj-$(CONFIG_DRM_PS8622) += ps8622.o
>  obj-$(CONFIG_DRM_PTN3460) += ptn3460.o
> diff --git a/drivers/gpu/drm/bridge/ps8622.c b/drivers/gpu/drm/bridge/ps8622.c
> new file mode 100644
> index 000..5474a39
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/ps8622.c
> @@ -0,0 +1,684 @@
> +/*
> + * Parade PS8622 eDP/LVDS bridge driver
> + *
> + * Copyright (C) 2014 Google, Inc.
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#include "drmP.h"
> +#include "drm_crtc.h"
> +#include "drm_crtc_helper.h"
> +
> +/* Brightness scale on the Parade chip */
> +#define PS8622_MAX_BRIGHTNESS 0xff
> +
> +/* Timings taken from the version 1.7 datasheet for the PS8622/PS8625 */
> +#define PS8622_POWER_RISE_T1_MIN_US 10
> +#define PS8622_POWER_RISE_T1_MAX_US 1
> +#define PS8622_RST_HIGH_T2_MIN_US 3000
> +#define PS8622_RST_HIGH_T2_MAX_US 3
> +#define PS8622_PWMO_END_T12_MS 200
> +#define PS8622_POWER_FALL_T16_MAX_US 1
> +#define PS8622_POWER_OFF_T17_MS 500
> +
> +#if ((PS8622_RST_HIGH_T2_MIN_US + PS8622_POWER_RISE_T1_MAX_US) > \
> +   (PS8622_RST_HIGH_T2_MAX_US + PS8622_POWER_RISE_T1_MIN_US))
> +#error "T2.min + T1.max must be less than T2.max + T1.min"
> +#endif
> +
> +struct ps8622_bridge {
> +   struct drm_connector connector;
> +   struct i2c_client *client;
> +   struct drm_bridge bridge;
> +   struct drm_panel *panel;
> +   struct regulator *v12;
> +   struct backlight_device *bl;
> +
> +   struct gpio_desc *gpio_slp;
> +   struct gpio_desc *gpio_rst;
> +
> +   u32 max_lane_count;
> +   u32 lane_count;
> +
> +   bool enabled;
> +};
> +
> +static inline struct ps8622_bridge *
> +   bridge_to_ps8622(struct drm_bridge *bridge)
> +{
> +   return container_of(bridge, struct ps8622_bridge, bridge);
> +}
> +
> +static inline struct ps8622_bridge *
> +   connector_to_ps8622(struct drm_connector *connector)
> +{
> +   return container_of(connector, struct ps8622_bridge, connector);
> +}
> +
> +static int ps8622_set(struct i2c_client *client, u8 page, u8 reg, u8 val)
> +{
> +   int ret;
> +   struct i2c_adapter *adap = client->adapter;
> +   struct i2c_msg msg;
> +   u8 data[] = {reg, val};
> +
> +   msg.addr = client->addr + page;
> +   msg.flags = 0;
> +   msg.len = sizeof(data);
> +   msg.buf = data;
> +
> +   ret = i2c_transfer(adap, , 1);
> +   if (ret != 1)
> +   pr_warn("PS8622 I2C write (0x%02x,0x%02x,0x%02x) failed: 
> %d\n",
> +   client->addr + page, reg, val, ret);
> +   return !(ret == 1);
> +}
> +
> +static int ps8622_send_config(struct ps8622_bridge *ps8622)
> +{
> +   struct 

[PATCH V9 04/14] drm/bridge: ptn3460: Convert to i2c driver model

[Ajay kumar]

Hi Gustavo,

I think Thierry already fixed it. Check this.
http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/gpu/drm/bridge/Kconfig


Regards,
Ajay



On Thu, Jan 29, 2015 at 7:59 PM, Gustavo Padovan  wrote:
> Hi Ajay,
>
> 2015-01-20 Ajay Kumar :
>
>> Use drm_bridge helpers to modify the driver to support
>> i2c driver model.
>>
>> Signed-off-by: Ajay Kumar 
>> Acked-by: Inki Dae 
>> Tested-by: Rahul Sharma 
>> Tested-by: Javier Martinez Canillas 
>> Tested-by: Gustavo Padovan 
>> Tested-by: Sjoerd Simons 
>> ---
>>  drivers/gpu/drm/bridge/Kconfig  |2 +
>>  drivers/gpu/drm/bridge/ptn3460.c|  124 
>> +--
>>  drivers/gpu/drm/exynos/exynos_dp_core.c |   22 --
>>  3 files changed, 86 insertions(+), 62 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
>> index 884923f..4254c2b 100644
>> --- a/drivers/gpu/drm/bridge/Kconfig
>> +++ b/drivers/gpu/drm/bridge/Kconfig
>> @@ -1,5 +1,7 @@
>>  config DRM_PTN3460
>>   tristate "PTN3460 DP/LVDS bridge"
>>   depends on DRM
>> + depends on OF && I2C
>
> Adding I2C here is causing this circular dependency:
>
> scripts/kconfig/conf --silentoldconfig Kconfig
> drivers/video/fbdev/Kconfig:5:error: recursive dependency detected!
> drivers/video/fbdev/Kconfig:5:  symbol FB is selected by DRM_KMS_FB_HELPER
> drivers/gpu/drm/Kconfig:34: symbol DRM_KMS_FB_HELPER depends on
> DRM_KMS_HELPER
> drivers/gpu/drm/Kconfig:28: symbol DRM_KMS_HELPER is selected by
> DRM_PTN3460
> drivers/gpu/drm/bridge/Kconfig:1:   symbol DRM_PTN3460 depends on I2C
> drivers/i2c/Kconfig:7:  symbol I2C is selected by FB_DDC
> drivers/video/fbdev/Kconfig:59: symbol FB_DDC is selected by FB_CYBER2000_DDC
> drivers/video/fbdev/Kconfig:374:symbol FB_CYBER2000_DDC depends on
> FB_CYBER2000
> drivers/video/fbdev/Kconfig:362:symbol FB_CYBER2000 depends on FB
>
> To solve this we just need to remove I2C from depends as DRM already selects
> I2C. This was already fixed by:
>
>
> commit 90bde571ad194adb039cb92a11a5b346f15eb610
> Author: Arnd Bergmann 
> Date:   Tue Mar 25 12:06:46 2014 +0100
>
> drm/bridge: PTN3460 needs DRM_KMS_HELPER
>
> The recently added PTN3460 device driver uses interfaces that
> are provided by the KMS helper infrastructure, so we should
> explicitly select that to avoid this linker error:
>
> ERROR: "drm_helper_probe_single_connector_modes" 
> [drivers/gpu/drm/bridge/ptn3460.ko] undefined!
> ERROR: "drm_helper_connector_dpms" [drivers/gpu/drm/bridge/ptn3460.ko] 
> undefined!
>
> We have to drop the I2C dependency to avoid a circular dependency
> chain, but that's ok because DRM already selects I2C.
>
> Signed-off-by: Arnd Bergmann 
> Signed-off-by: Dave Airlie 
>
>
> But you may have introduced it again on a rebase. The following patch fixes 
> it:
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 990b4b2..946d1ef 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -1,7 +1,6 @@
>  config DRM_PTN3460
> tristate "PTN3460 DP/LVDS bridge"
> -   depends on DRM
> -   depends on OF && I2C
> +   depends on DRM && OF
> select DRM_KMS_HELPER
> select DRM_PANEL
> ---help---
>
>
> Gustavo

[RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms

[Russell King - ARM Linux]

On Thu, Jan 29, 2015 at 01:52:09PM -0500, Rob Clark wrote:
> Quite possibly for some of these edge some of cases, some of the
> dma-buf exporters are going to need to get more clever (ie. hand off
> different scatterlists to different clients).  Although I think by far
> the two common cases will be "I can support anything via an iommu/mmu"
> and "I need phys contig".
> 
> But that isn't an issue w/ dma-buf itself, so much as it is an issue
> w/ drivers.  I guess there would be more interest in fixing up drivers
> when actual hw comes along that needs it..

However, validating the attachments is the business of dma-buf.  This
is actual infrastructure, which should ensure some kind of sanity such
as the issues I've raised.

The whole "we can push it onto our users" is really on - what that
results in is the users ignoring most of the requirements and just doing
their own thing, which ultimately ends up with the whole thing turning
into a disgusting mess - one which becomes very difficult to fix later.

Now, if we're going to do the "more clever" thing you mention above,
that rather negates the point of this two-part patch set, which is to
provide the union of the DMA capabilities of all users.  A union in
that case is no longer sane as we'd be tailoring the SG lists to each
user.

If we aren't going to do the "more clever" thing, then yes, we need this
code to calculate that union, but we _also_ need it to do sanity checking
right from the start, and refuse conditions which ultimately break the
ability to make use of that union - in other words, when the union of
the DMA capabilities means that the dmabuf can't be represented.

Unless we do that, we'll just end up with random drivers interpreting
what they want from the DMA capabilities, and we'll have some drivers
exporting (eg) scatterlists which satisfy the maximum byte size of an
element, but ignoring the maximum number of entries or vice versa, and
that'll most probably hide the case of "too small a union".

It really doesn't make sense to do both either: that route is even more
madness, because we'll end up with two classes of drivers - those which
use the union approach, and those which don't.

The KISS principle applies here.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

[PATCH 3/6] libdrm: fix the Android 64bit build

[Emil Velikov]

On 29/01/15 19:00, Stéphane Marchesin wrote:
> On Thu, Jan 29, 2015 at 10:47 AM, Emil Velikov  
> wrote:
>> With 64bit bionic mmap now handles 64bit offset, thus we no longer
>> need the __mmap2 trick.
>>
>> Fix from Chih-Wei Huang, over at the google forums.
>>
>> Cc: Chih-Wei Huang 
>> Signed-off-by: Emil Velikov 
>> ---
>>  libdrm.h | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libdrm.h b/libdrm.h
>> index acfada5..6c3cd59 100644
>> --- a/libdrm.h
>> +++ b/libdrm.h
>> @@ -45,7 +45,7 @@
>>
>>  #include 
>>
>> -#if defined(ANDROID)
>> +#if defined(ANDROID) && !defined(__LP64__)
>>  #include  /* for EINVAL */
>>
>>  extern void *__mmap2(void *, size_t, int, int, int, size_t);
> 
> It seems like you're be better off just using mmap64 instead of __mpap2?
> 
I was thinking about that but decided against it due to:

 - For 64bit platforms - mmap64 maps directly to mmap [1].

 - For other platforms (kitkat at least) mmap64 does a costly (according
to the man page) syscall (don't recall the name).

 - Some systems may be lacking mmap64.

Quite a noobie on the topic so I might be completely wrong :)

Thanks
Emil

[1]
https://android.googlesource.com/platform/bionic.git/+/38fcbbb35a40c46e96b4df10d670d1c132910854%5E2%5E!/

[PATCH 6/6] android: remove duplicate libdrm in LOCAL_SHARED_LIBRARIES

[Emil Velikov]

From: Chih-Wei Huang 

Signed-off-by: Chih-Wei Huang 
---
 freedreno/Android.mk | 3 ---
 intel/Android.mk | 1 -
 nouveau/Android.mk   | 3 ---
 radeon/Android.mk| 3 ---
 4 files changed, 10 deletions(-)

diff --git a/freedreno/Android.mk b/freedreno/Android.mk
index 243a1e2..22520fb 100644
--- a/freedreno/Android.mk
+++ b/freedreno/Android.mk
@@ -24,7 +24,4 @@ LOCAL_CFLAGS := \
 LOCAL_COPY_HEADERS := $(LIBDRM_FREEDRENO_H_FILES)
 LOCAL_COPY_HEADERS_TO := freedreno

-LOCAL_SHARED_LIBRARIES := \
-   libdrm
-
 include $(BUILD_SHARED_LIBRARY)
diff --git a/intel/Android.mk b/intel/Android.mk
index f2f21b9..bf6e822 100644
--- a/intel/Android.mk
+++ b/intel/Android.mk
@@ -49,7 +49,6 @@ LOCAL_COPY_HEADERS := $(LIBDRM_INTEL_H_FILES)
 LOCAL_COPY_HEADERS_TO := libdrm

 LOCAL_SHARED_LIBRARIES := \
-   libdrm \
libpciaccess

 include $(BUILD_SHARED_LIBRARY)
diff --git a/nouveau/Android.mk b/nouveau/Android.mk
index 734fc21..93c9ec2 100644
--- a/nouveau/Android.mk
+++ b/nouveau/Android.mk
@@ -24,7 +24,4 @@ LOCAL_CFLAGS := \
 LOCAL_COPY_HEADERS := $(LIBDRM_NOUVEAU_H_FILES)
 LOCAL_COPY_HEADERS_TO := libdrm

-LOCAL_SHARED_LIBRARIES := \
-   libdrm
-
 include $(BUILD_SHARED_LIBRARY)
diff --git a/radeon/Android.mk b/radeon/Android.mk
index 9cba546..71c58bd 100644
--- a/radeon/Android.mk
+++ b/radeon/Android.mk
@@ -24,7 +24,4 @@ LOCAL_CFLAGS := \
 LOCAL_COPY_HEADERS := $(LIBDRM_RADEON_H_FILES)
 LOCAL_COPY_HEADERS_TO := libdrm

-LOCAL_SHARED_LIBRARIES := \
-   libdrm
-
 include $(BUILD_SHARED_LIBRARY)
-- 
2.1.3

[PATCH 5/6] drmGetStats: silence compiler warning

[Emil Velikov]

drm_stats_t::count is of type unsigned long, while i is an int. Make the
latter an unsigned int.
Spotted as -Wsign-compare warning while building under Android 5.

Signed-off-by: Emil Velikov 
---
 xf86drm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xf86drm.c b/xf86drm.c
index b41c1d8..cc79ab6 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -2213,7 +2213,7 @@ int drmGetClient(int fd, int idx, int *auth, int *pid, 
int *uid,
 int drmGetStats(int fd, drmStatsT *stats)
 {
 drm_stats_t s;
-int i;
+unsigned int i;

 if (drmIoctl(fd, DRM_IOCTL_GET_STATS, ))
return -errno;
-- 
2.1.3

[PATCH 4/6] drmOpenDevice: silence compiler warning

[Emil Velikov]

Under 64bit Android the compiler throws a -Wsign-compare warning.
Typecast the variable dev to silence the build.

Signed-off-by: Emil Velikov 
---
 xf86drm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xf86drm.c b/xf86drm.c
index 345325a..b41c1d8 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -394,7 +394,7 @@ wait_for_udev:
 /* Check if the device node is not what we expect it to be, and recreate it
  * and try again if so.
  */
-if (st.st_rdev != dev) {
+if (st.st_rdev != (dev_t)dev) {
if (!isroot)
return DRM_ERR_NOT_ROOT;
remove(buf);
-- 
2.1.3

[PATCH 3/6] libdrm: fix the Android 64bit build

[Emil Velikov]

With 64bit bionic mmap now handles 64bit offset, thus we no longer
need the __mmap2 trick.

Fix from Chih-Wei Huang, over at the google forums.

Cc: Chih-Wei Huang 
Signed-off-by: Emil Velikov 
---
 libdrm.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libdrm.h b/libdrm.h
index acfada5..6c3cd59 100644
--- a/libdrm.h
+++ b/libdrm.h
@@ -45,7 +45,7 @@

 #include 

-#if defined(ANDROID)
+#if defined(ANDROID) && !defined(__LP64__)
 #include  /* for EINVAL */

 extern void *__mmap2(void *, size_t, int, int, int, size_t);
-- 
2.1.3

[PATCH 2/6] modetest: move includes into AM_CPPFLAGS

[Emil Velikov]

Signed-off-by: Emil Velikov 
---
 tests/modetest/Makefile.am | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tests/modetest/Makefile.am b/tests/modetest/Makefile.am
index 40dad3e..a8b9a3a 100644
--- a/tests/modetest/Makefile.am
+++ b/tests/modetest/Makefile.am
@@ -1,12 +1,12 @@
 include Makefile.sources

-AM_CFLAGS = $(filter-out -Wpointer-arith, $(WARN_CFLAGS))
-
-AM_CFLAGS += \
+AM_CPPFLAGS = \
-I$(top_srcdir)/include/drm \
-I$(top_srcdir)/tests \
-I$(top_srcdir)

+AM_CFLAGS = $(filter-out -Wpointer-arith, $(WARN_CFLAGS))
+
 if HAVE_INSTALL_TESTS
 bin_PROGRAMS = \
modetest
-- 
2.1.3

[PATCH 1/6] util: add WARN_CFLAGS, rename the c*flags vars

[Emil Velikov]

Signed-off-by: Emil Velikov 
---
 tests/util/Makefile.am | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/tests/util/Makefile.am b/tests/util/Makefile.am
index f8e0b17..aaaf932 100644
--- a/tests/util/Makefile.am
+++ b/tests/util/Makefile.am
@@ -1,13 +1,14 @@
 include Makefile.sources

-noinst_LTLIBRARIES = \
-   libutil.la
-
-libutil_la_CPPFLAGS = \
+AM_CPPFLAGS = \
-I$(top_srcdir)/include/drm \
-I$(top_srcdir)

-libutil_la_CFLAGS = \
-   $(CAIRO_CFLAGS)
+AM_CFLAGS = \
+   $(CAIRO_CFLAGS) \
+   $(WARN_CFLAGS)
+
+noinst_LTLIBRARIES = \
+   libutil.la

 libutil_la_SOURCES = $(UTIL_FILES)
-- 
2.1.3

[PATH 0/6] Misc build fixes

[Emil Velikov]

Hello all,

It's time for another Android fueled round of fixes.
Mostly trivial and self explanatory patches enough to get things 
building (rather quietly) on Android 5, x86_64

The series can be found at in branch for-android at
https://github.com/evelikov/libdrm/

Cheers,
Emil

 freedreno/Android.mk   |  3 ---
 intel/Android.mk   |  1 -
 libdrm.h   |  2 +-
 nouveau/Android.mk |  3 ---
 radeon/Android.mk  |  3 ---
 tests/modetest/Makefile.am |  6 +++---
 tests/util/Makefile.am | 13 +++--
 xf86drm.c  |  4 ++--
 8 files changed, 13 insertions(+), 22 deletions(-)

Chih-Wei Huang (1):
  android: remove duplicate libdrm in LOCAL_SHARED_LIBRARIES

Emil Velikov (5):
  util: add WARN_CFLAGS, rename the c*flags vars
  modetest: move includes into AM_CPPFLAGS
  libdrm: fix the Android 64bit build
  drmOpenDevice: silence compiler warning
  drmGetStats: silence compiler warning

[RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms

[Rob Clark]

On Thu, Jan 29, 2015 at 5:31 PM, Russell King - ARM Linux
 wrote:
> On Thu, Jan 29, 2015 at 05:18:33PM -0500, Rob Clark wrote:
>> On Thu, Jan 29, 2015 at 2:26 PM, Russell King - ARM Linux
>>  wrote:
>> > Now, if we're going to do the "more clever" thing you mention above,
>> > that rather negates the point of this two-part patch set, which is to
>> > provide the union of the DMA capabilities of all users.  A union in
>> > that case is no longer sane as we'd be tailoring the SG lists to each
>> > user.
>>
>> It doesn't really negate.. a different sg list representing the same
>> physical memory cannot suddenly make the buffer physically contiguous
>> (from the perspective of memory)..
>>
>> (unless we are not on the same page here, so to speak)
>
> If we are really only interested in the "physically contiguous" vs
> "scattered" differentiation, why can't this be just a simple flag?

I'd be fine with that..  I was trying to make it a bit less of a point
solution, but maybe trying to be too generic is not worth it..

There is apparently some hw which has iommu's but small # of tlb
entries, and would prefer partially contiguous buffers.  But that
isn't a hard constraint, and maybe shouldn't be solved w/
max_segment_count.  And I'm not sure how common that is.

> I think I know where you're coming from on that distinction - most
> GPUs can cope with their buffers being discontiguous in memory, but
> scanout and capture hardware tends to need contiguous buffers.
>
> My guess is that you're looking for some way that a GPU driver could
> allocate a buffer, which can then be imported into the scanout
> hardware - and when it is, the underlying backing store is converted
> to a contiguous buffer.  Is that the usage scenario you're thinking
> of?

Pretty much..  and maybe a few slight permutations on that involving
cameras / video codecs / etc.  But the really-really common case is
gpu (with mmu/iommu) + display (without).  Just solving this problem
would be a really good first step.

BR,
-R

>
> --
> FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
> according to speedtest.net.

[Bug 88758] Low FPS in settings on Dota2

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

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

--- Comment #21 from Lorenzo Bona  ---
(In reply to smoki from comment #19)
> (In reply to Lorenzo Bona from comment #18)
> > Reverting this commit 
> > 
> > http://cgit.freedesktop.org/mesa/mesa/commit/src/gallium/drivers/radeon/
> > r600_buffer_common.c?id=7b4276d7acf2e0f77044cb50caa6ad936fa78786
> > 
> > helps a little bit.
> > 
> > But it's not as fluid as on 3.16rc6 kernel.
> 
>  That same mesa used with 3.16rc6 and drm-fixes-3.19? Does those two kernels
> have same/similar performance (without that large drop), but just
> drm-fixes-3.19 is not so fluid like when 3.16rc6 kernel is used?
> 
>  And you builded that mesa now with -mtune=native for both CFLAGS and
> CXXFLAGS?
> 
>  Asking all those because i don't have those sttuter problems with 3.19
> kernel and that reverted but that is on APU... than it seems to me like only
> dedicated cards are affected.

Yeah.
I've compiled mesa, with both -march and -mtune set to native on CFLAGS and
CXXFLAGS.

On 3.16rc6 is running like a charme (I've never seen radeonsi so fast), on 3.19
is crap, BUT this is only for 32bit program(s) (tested only Dota2).

Unigine Valley results are almost the same on both kernel.
Near 5000 points, max FPS around 40, min FPS around 7 and average near 27FPS.

So is it something related to architecture, from my poorly point of view.

(In reply to Alex Deucher from comment #20)
> For 3.19, you may be hitting:
> https://bugzilla.kernel.org/show_bug.cgi?id=90741

Mmm but with that bug people are experiencing pauses, I don't have pauses but
costant low FPS.

-- 
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/20150129/1b7d5917/attachment.html>

[PATCH] RFC: drm: add support for tiled/compressed/etc modifier in addfb2

[Daniel Vetter]

From: Rob Clark 

In DRM/KMS we are lacking a good way to deal with tiled/compressed
formats.  Especially in the case of dmabuf/prime buffer sharing, where
we cannot always rely on under-the-hood flags passed to driver specific
gem-create ioctl to pass around these extra flags.

The proposal is to add a per-plane format modifier.  This allows to, if
necessary, use different tiling patters for sub-sampled planes, etc.
The format modifiers are added at the end of the ioctl struct, so for
legacy userspace it will be zero padded.

v1: original
v1.5: increase modifier to 64b

v2: Incorporate review comments from the big thread, plus a few more.

- Add a getcap so that userspace doesn't have to jump through hoops.
- Allow modifiers only when a flag is set. That way drivers know when
  they're dealing with old userspace and need to fish out e.g. tiling
  from other information.
- After rolling out checks for ->modifier to all drivers I've decided
  that this is way too fragile and needs an explicit opt-in flag. So
  do that instead.
- Add a define (just for documentation really) for the "NONE"
  modifier. Imo we don't need to add mask #defines since drivers
  really should only do exact matches against values defined with
  fourcc_mod_code.
- Drop the Samsung tiling modifier on Rob's request since he's not yet
  sure whether that one is accurate.

v3:
- Also add a new ->modifier[] array to struct drm_framebuffer and fill
  it in drm_helper_mode_fill_fb_struct. Requested by Tvrkto Uruslin.
- Remove TODO in comment and add code comment that modifiers should be
  properly documented, requested by Rob.

Cc: Rob Clark 
Cc: Tvrtko Ursulin 
Cc: Laurent Pinchart 
Cc: Daniel Stone 
Cc: Ville Syrjälä 
Cc: Michel Dänzer 
Signed-off-by: Rob Clark  (v1.5)
Reviewed-by: Rob Clark 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_crtc.c| 14 +-
 drivers/gpu/drm/drm_crtc_helper.c |  1 +
 drivers/gpu/drm/drm_ioctl.c   |  3 +++
 include/drm/drm_crtc.h|  4 
 include/uapi/drm/drm.h|  1 +
 include/uapi/drm/drm_fourcc.h | 32 
 include/uapi/drm/drm_mode.h   |  9 +
 7 files changed, 63 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 419f9d915c78..8090e3d64f67 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3324,6 +3324,12 @@ static int framebuffer_check(const struct 
drm_mode_fb_cmd2 *r)
DRM_DEBUG_KMS("bad pitch %u for plane %d\n", 
r->pitches[i], i);
return -EINVAL;
}
+
+   if (r->modifier[i] && !(r->flags & DRM_MODE_FB_MODIFIERS)) {
+   DRM_DEBUG_KMS("bad fb modifier %llu for plane %d\n",
+ r->modifier[i], i);
+   return -EINVAL;
+   }
}

return 0;
@@ -3337,7 +3343,7 @@ static struct drm_framebuffer 
*add_framebuffer_internal(struct drm_device *dev,
struct drm_framebuffer *fb;
int ret;

-   if (r->flags & ~DRM_MODE_FB_INTERLACED) {
+   if (r->flags & ~(DRM_MODE_FB_INTERLACED | DRM_MODE_FB_MODIFIERS)) {
DRM_DEBUG_KMS("bad framebuffer flags 0x%08x\n", r->flags);
return ERR_PTR(-EINVAL);
}
@@ -3353,6 +3359,12 @@ static struct drm_framebuffer 
*add_framebuffer_internal(struct drm_device *dev,
return ERR_PTR(-EINVAL);
}

+   if (r->flags & DRM_MODE_FB_MODIFIERS &&
+   !dev->mode_config.allow_fb_modifiers) {
+   DRM_DEBUG_KMS("driver does not support fb modifiers\n");
+   return ERR_PTR(-EINVAL);
+   }
+
ret = framebuffer_check(r);
if (ret)
return ERR_PTR(ret);
diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index b1979e7bdc88..3053aab968f9 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -837,6 +837,7 @@ void drm_helper_mode_fill_fb_struct(struct drm_framebuffer 
*fb,
for (i = 0; i < 4; i++) {
fb->pitches[i] = mode_cmd->pitches[i];
fb->offsets[i] = mode_cmd->offsets[i];
+   fb->modifier[i] = mode_cmd->modifier[i];
}
drm_fb_get_bpp_depth(mode_cmd->pixel_format, >depth,
>bits_per_pixel);
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 3785d66721f2..a6d773a61c2d 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -321,6 +321,9 @@ static int drm_getcap(struct drm_device *dev, void *data, 
struct drm_file *file_
else
req->value = 64;
break;
+   case DRM_CAP_ADDFB2_MODIFIERS:
+   req->value = dev->mode_config.allow_fb_modifiers;
+   break;
default:
return -EINVAL;

[RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms

[Rob Clark]

On Thu, Jan 29, 2015 at 2:26 PM, Russell King - ARM Linux
 wrote:
> On Thu, Jan 29, 2015 at 01:52:09PM -0500, Rob Clark wrote:
>> Quite possibly for some of these edge some of cases, some of the
>> dma-buf exporters are going to need to get more clever (ie. hand off
>> different scatterlists to different clients).  Although I think by far
>> the two common cases will be "I can support anything via an iommu/mmu"
>> and "I need phys contig".
>>
>> But that isn't an issue w/ dma-buf itself, so much as it is an issue
>> w/ drivers.  I guess there would be more interest in fixing up drivers
>> when actual hw comes along that needs it..
>
> However, validating the attachments is the business of dma-buf.  This
> is actual infrastructure, which should ensure some kind of sanity such
> as the issues I've raised.
>

My initial thought is for dma-buf to not try to prevent something than
an exporter can actually do.. I think the scenario you describe could
be handled by two sg-lists, if the exporter was clever enough.

That all said, I think probably all the existing exporters cache the
sg-list.  And I can't think of any actual hw which would hit this
problem that can be solved by multiple sg-lists for the same physical
memory.  (And the constraint calculation kind of assumes the end
result will be a single sg-list.)  So it seems reasonable to me to
check that max_segment_count * max_segment_size is not smaller than
the buffer.

If it was a less theoretical problem, I think I'd more inclined for a
way that the exporter could override the checks, or something along
those lines.

otoh, if the attachment is just not possible because the buffer has
been already allocated and mapped by someone with more relaxed
constraints.. then I think the driver should be the one returning the
error since dma-buf doesn't know this.

> The whole "we can push it onto our users" is really on - what that
> results in is the users ignoring most of the requirements and just doing
> their own thing, which ultimately ends up with the whole thing turning
> into a disgusting mess - one which becomes very difficult to fix later.

Ideally at some point, dma-mapping or some helpers would support
allocations matching constraints..  I think only actual gpu drivers
want to do crazy enough things that they'd want to bypass dma-mapping.
If everyone else can use dma-mapping and/or helpers then we make it
harder for drivers to do the wrong thing than to do the right thing.

> Now, if we're going to do the "more clever" thing you mention above,
> that rather negates the point of this two-part patch set, which is to
> provide the union of the DMA capabilities of all users.  A union in
> that case is no longer sane as we'd be tailoring the SG lists to each
> user.

It doesn't really negate.. a different sg list representing the same
physical memory cannot suddenly make the buffer physically contiguous
(from the perspective of memory)..

(unless we are not on the same page here, so to speak)

BR,
-R

> If we aren't going to do the "more clever" thing, then yes, we need this
> code to calculate that union, but we _also_ need it to do sanity checking
> right from the start, and refuse conditions which ultimately break the
> ability to make use of that union - in other words, when the union of
> the DMA capabilities means that the dmabuf can't be represented.
>
> Unless we do that, we'll just end up with random drivers interpreting
> what they want from the DMA capabilities, and we'll have some drivers
> exporting (eg) scatterlists which satisfy the maximum byte size of an
> element, but ignoring the maximum number of entries or vice versa, and
> that'll most probably hide the case of "too small a union".
>
> It really doesn't make sense to do both either: that route is even more
> madness, because we'll end up with two classes of drivers - those which
> use the union approach, and those which don't.
>
> The KISS principle applies here.
>
> --
> FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
> according to speedtest.net.

[PATCH] drm: shmobile: fix Kconfig dependencies

[Arnd Bergmann]

The shmobile drm driver selects BACKLIGHT_CLASS_DEVICE
as of 0a5a5499ad88 "drm: shmobile: Add dependency on
BACKLIGHT_CLASS_DEVICE", but that option in turn depends
on BACKLIGHT_LCD_SUPPORT, so we actually have to select
both, or alternatively use 'depends on BACKLIGHT_CLASS_DEVICE'.

Further, the driver uses FB_SH_MOBILE_MERAM if that is
enabled, but this breaks if MERAM is a module while
the DRM driver is built-in. To solve this, add a dependency
on "FB_SH_MOBILE_MERAM || !FB_SH_MOBILE_MERAM", which forces
DRM_SHMOBILE to be a module if FB_SH_MOBILE_MERAM set to 'm'.

Signed-off-by: Arnd Bergmann 

diff --git a/drivers/gpu/drm/shmobile/Kconfig b/drivers/gpu/drm/shmobile/Kconfig
index a50fe0eeaa0d..8d17d00ddb4b 100644
--- a/drivers/gpu/drm/shmobile/Kconfig
+++ b/drivers/gpu/drm/shmobile/Kconfig
@@ -2,7 +2,9 @@ config DRM_SHMOBILE
tristate "DRM Support for SH Mobile"
depends on DRM && ARM
depends on ARCH_SHMOBILE || COMPILE_TEST
+   depends on FB_SH_MOBILE_MERAM || !FB_SH_MOBILE_MERAM
select BACKLIGHT_CLASS_DEVICE
+   select BACKLIGHT_LCD_SUPPORT
select DRM_KMS_HELPER
select DRM_KMS_FB_HELPER
select DRM_KMS_CMA_HELPER

[Bug 88758] Low FPS in settings on Dota2

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

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

--- Comment #20 from Alex Deucher  ---
For 3.19, you may be hitting:
https://bugzilla.kernel.org/show_bug.cgi?id=90741

-- 
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/20150129/4a1c3133/attachment.html>

[Bug 88758] Low FPS in settings on Dota2

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

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

--- Comment #19 from smoki  ---
(In reply to Lorenzo Bona from comment #18)
> Reverting this commit 
> 
> http://cgit.freedesktop.org/mesa/mesa/commit/src/gallium/drivers/radeon/
> r600_buffer_common.c?id=7b4276d7acf2e0f77044cb50caa6ad936fa78786
> 
> helps a little bit.
> 
> But it's not as fluid as on 3.16rc6 kernel.

 That same mesa used with 3.16rc6 and drm-fixes-3.19? Does those two kernels
have same/similar performance (without that large drop), but just
drm-fixes-3.19 is not so fluid like when 3.16rc6 kernel is used?

 And you builded that mesa now with -mtune=native for both CFLAGS and CXXFLAGS?

 Asking all those because i don't have those sttuter problems with 3.19 kernel
and that reverted but that is on APU... than it seems to me like only dedicated
cards are affected.

-- 
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/20150129/77021e96/attachment.html>

[Bug 88758] Low FPS in settings on Dota2

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

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

--- Comment #18 from Lorenzo Bona  ---
Reverting this commit 

http://cgit.freedesktop.org/mesa/mesa/commit/src/gallium/drivers/radeon/r600_buffer_common.c?id=7b4276d7acf2e0f77044cb50caa6ad936fa78786

helps a little bit.

But it's not as fluid as on 3.16rc6 kernel.

-- 
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/20150129/e6e89734/attachment.html>

[PATCH v3] drm/dp: Use large transactions for I2C over AUX

[Ville Syrjälä]

On Thu, Jan 29, 2015 at 02:24:09PM +, Simon Farnsworth wrote:
> On Thursday 29 January 2015 15:30:36 you wrote:
> > On Tue, Jan 27, 2015 at 03:43:49PM +, Simon Farnsworth wrote:
> --snip--
> > > diff --git a/drivers/gpu/drm/drm_dp_helper.c 
> > > b/drivers/gpu/drm/drm_dp_helper.c
> > > index 79968e3..3db116c 100644
> > > --- a/drivers/gpu/drm/drm_dp_helper.c
> > > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > > @@ -396,11 +396,13 @@ static u32 drm_dp_i2c_functionality(struct 
> > > i2c_adapter *adapter)
> > >   * retrying the transaction as appropriate.  It is assumed that the
> > >   * aux->transfer function does not modify anything in the msg other than 
> > > the
> > >   * reply field.
> > > + *
> > > + * Returns bytes transferred on success, or a negative error code on 
> > > failure.
> > >   */
> > >  static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, struct 
> > > drm_dp_aux_msg *msg)
> > >  {
> > >   unsigned int retry;
> > > - int err;
> > > + int ret;
> > >  
> > >   /*
> > >* DP1.2 sections 2.7.7.1.5.6.1 and 2.7.7.1.6.6.1: A DP Source device
> > > @@ -409,14 +411,14 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux 
> > > *aux, struct drm_dp_aux_msg *msg)
> > >*/
> > >   for (retry = 0; retry < 7; retry++) {
> > >   mutex_lock(>hw_mutex);
> > > - err = aux->transfer(aux, msg);
> > > + ret = aux->transfer(aux, msg);
> > >   mutex_unlock(>hw_mutex);
> > > - if (err < 0) {
> > > - if (err == -EBUSY)
> > > + if (ret < 0) {
> > > + if (ret == -EBUSY)
> > >   continue;
> > >  
> > > - DRM_DEBUG_KMS("transaction failed: %d\n", err);
> > > - return err;
> > > + DRM_DEBUG_KMS("transaction failed: %d\n", ret);
> > > + return ret;
> > >   }
> > >  
> > >  
> > > @@ -457,9 +459,7 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, 
> > > struct drm_dp_aux_msg *msg)
> > >* Both native ACK and I2C ACK replies received. We
> > >* can assume the transfer was successful.
> > >*/
> > > - if (err < msg->size)
> > > - return -EPROTO;
> > > - return 0;
> > > + return ret;
> > 
> > The s/err/ret/ seems a bit superfluous, but OTOH it does make sense
> > since it's no longer just an error value. At first glance it just
> > confused me a bit since I wasn't expecting that many changes to this
> > function.
> >
> 
> I'm going to hang onto that change - it makes things clearer when you read
> the function outside the context of this patch.
> 
> > >  
> > >   case DP_AUX_I2C_REPLY_NACK:
> > >   DRM_DEBUG_KMS("I2C nack\n");
> > > @@ -482,14 +482,67 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux 
> > > *aux, struct drm_dp_aux_msg *msg)
> > >   return -EREMOTEIO;
> > >  }
> > >  
> > > +/*
> > > + * Keep retrying drm_dp_i2c_do_msg until all data has been transferred.
> > > + *
> > > + * Returns an error code on failure, or a recommended transfer size on 
> > > success.
> > > + */
> > > +static int drm_dp_i2c_drain_msg(struct drm_dp_aux *aux, struct 
> > > drm_dp_aux_msg *msg)
> > > +{
> > > + int ret;
> > > + struct drm_dp_aux_msg drain_msg;
> > > + int drain_bytes;
> > > +
> > > + ret = drm_dp_i2c_do_msg(aux, msg);
> > > +
> > > + if (ret == msg->size || ret <= 0)
> > > + return ret == 0 ? -EPROTO : ret;
> > > +
> > > + /*
> > > +  * We had a partial reply. Drain out the rest of the bytes we
> > > +  * originally requested, then return the size of the partial
> > > +  * reply. In theory, this should match DP 1.2's desired behaviour
> > > +  * for I2C over AUX.
> > > +  */
> > 
> > The spec is a bit self contradictory, but there is a section which seems
> > to suggest this. It's only mentioned for reads mind you, but I don't see
> > it causing harm for writes either. Not that we actually handle
> > partial/deferred writes correctly at the moment.
> > 
> > > + DRM_DEBUG_KMS("Partial I2C reply: requested %zu bytes got %d bytes\n", 
> > > msg->size, ret);
> > > + drain_msg = *msg;
> > > + drain_msg.size -= ret;
> > > + drain_msg.buffer += ret;
> > > + while (drain_msg.size != 0) {
> > > + drain_bytes = drm_dp_i2c_do_msg(aux, _msg);
> > > + if (drain_bytes <= 0)
> > > + return drain_bytes == 0 ? -EPROTO : drain_bytes;
> > > + drain_msg.size -= drain_bytes;
> > > + drain_msg.buffer += drain_bytes;
> > > + }
> > 
> > Somehow I don't like the duplicated code end up having here. So
> > putting it all in a single loop would seem nicer to me. Maybe
> > something along these lines?
> > 
> > struct drm_dp_aux_msg msg = *orig_msg;
> > int ret = msg.size;
> > while (msg.size > 0) {
> > int err = drm_dp_i2c_do_msg(aux, );
> > if (err <= 0)
> > return err == 0 ? -EPROTO : err;
> > 
> > if (err < msg.size && err < ret) 

[PATCH] vt_buffer: drop console buffer copying optimisations

[Linus Torvalds]

On Thu, Jan 29, 2015 at 3:57 PM, Greg Kroah-Hartman
 wrote:
>
> I can take this through the tty tree, but can I put it in linux-next and
> wait for the 3.20 merge window to give people who might notice a
> slow-down a chance to object?

Yes. The problem only affects one (or a couple of) truly outrageously
bad graphics cards that are only used in servers (because they are
such crap that they wouldn't be acceptable anywhere else anyway), and
they have afaik never worked with 64-bit kernels, so it's not even a
regression.

So it's worth fixing because it's a real - albeit very rare - problem
(especially since the enhanched rep instruction model of memcpy could
easily be *worse* than the 16-bit-at-a-time manual version), but I
wouldn't consider it anywhere near high priority.

 Linus

--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
--
___
Dri-devel mailing list
Dri-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[PATCH] drm/radeon: fix PLLs on RS880 and older v2

[Christian König]

From: Christian König 

This is a workaround for RS880 and older chips which seem to have
an additional limit on the minimum PLL input frequency.

v2: fix signed/unsigned warning

Signed-off-by: Christian König 
---
 drivers/gpu/drm/radeon/radeon_display.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
b/drivers/gpu/drm/radeon/radeon_display.c
index 1021169..913fafa 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -960,6 +960,9 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll,
if (pll->flags & RADEON_PLL_USE_FRAC_FB_DIV &&
pll->flags & RADEON_PLL_USE_REF_DIV)
ref_div_max = pll->reference_div;
+   else if (pll->flags & RADEON_PLL_PREFER_MINM_OVER_MAXP)
+   /* fix for problems on RS880 */
+   ref_div_max = min(pll->max_ref_div, 7u);
else
ref_div_max = pll->max_ref_div;

-- 
1.9.1

[PATCH] drm/radeon: don't init gpuvm if accel is disabled

[Oded Gabbay]

On 01/29/2015 03:54 PM, Deucher, Alexander wrote:
>> -Original Message-
>> From: Gabbay, Oded
>> Sent: Thursday, January 29, 2015 2:46 AM
>> To: Alex Deucher; dri-devel at lists.freedesktop.org
>> Cc: Deucher, Alexander; stable at vger.kernel.org
>> Subject: Re: [PATCH] drm/radeon: don't init gpuvm if accel is disabled
>>
>>
>>
>> On 01/28/2015 09:41 PM, Alex Deucher wrote:
>>> If acceleration is disabled, it does not make sense
>>> to init gpuvm since nothing will use it.  Moreover,
>>> if radeon_vm_init() gets called it uses accel to try
>>> and clear the pde tables, etc. which results in a bug.
>>>
>>> Bug:
>>> https://bugs.freedesktop.org/show_bug.cgi?id=88786
>>>
>>> Signed-off-by: Alex Deucher
>>> Cc:stable at vger.kernel.org
>> Alex,
>> What is accel ?
>
> If the ring tests fail and for some reason the IPs (e.g., gfx or sdma) are 
> not available, the driver disables acceleration and basically falls back to 
> modesetting only.
>
>> Is there a situation where accel is disabled and HSA should work ? e.g.
>> headless
>> mode ?
>
> No.  We only disable acceleration if we can't get the IPs (gfx, sdma) 
> initialized.  Headless has nothing to do with acceleration in this context.
>
> Alex
>
OK, thanks for the explanation.

Oded

[Bug 88758] Low FPS in settings on Dota2

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

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

--- Comment #17 from Lorenzo Bona  ---
(In reply to smoki from comment #16)
>  Hm well i can't see slowdwons in dota, but anyway as a guess can you try to
> revert this mesa commit i see some slodowns with it too:
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=88658#c6

I will try. 
Can you post your build script? Could be a bad format in my build script?
I forget if I've changed something between this one and the previous one I use
back in November.

-- 
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/20150129/6a5fac0f/attachment.html>

[PATCH] vt_buffer: drop console buffer copying optimisations

[Greg Kroah-Hartman]

On Thu, Jan 29, 2015 at 03:40:33PM -0800, Linus Torvalds wrote:
> On Wed, Jan 28, 2015 at 8:11 PM, Dave Airlie  wrote:
> >
> > Linus, this came up a while back I finally got some confirmation
> > that it fixes those servers.
> 
> I'm certainly ok with this. which way should it go in? The users are:
> 
>  - drivers/tty/vt/vt.c (Greg KH, "tty layer")
> 
>  - drivers/video/console/* (fbcon people: Tomi Valkeinen and friends)
> 
> and it might make sense to have *some* indication of how much worse
> this makes fbcon performance in particular..
> 
> Greg/Tomi - the patch is removing this:
> 
>   #define scr_memcpyw(d, s, c) memcpy(d, s, c)
>   #define scr_memmovew(d, s, c) memmove(d, s, c)
>   #define VT_BUF_HAVE_MEMCPYW
>   #define VT_BUF_HAVE_MEMMOVEW
> 
> from , because some stupid graphics cards
> apparently cannot handle 64-bit accesses of regular memcpy/memmove.
> 
> And on other setups, this will be the reverse: 8-bit accesses due to
> using "rep movsb", which is the fast way to move/clear memory on
> modern Intel CPU's, but is really wrong for MMIO where it will be slow
> as hell.
> 
> So just getting rid of the memcpy/memmove is likely the right thing in
> general, since the fallbacks go this the traditional 16-bit-at-a-time
> way. And getting rid of the memcpy _may_ speed things up.
> 
> But if it slows things down, we might have to try something else. Like
> saying "all cards we've ever seen have been ok with aligned 32-bit
> accesses", and extend the open-coded scr_memcpy/memmove functions to
> do that.
> 
> Hmm?

I can take this through the tty tree, but can I put it in linux-next and
wait for the 3.20 merge window to give people who might notice a
slow-down a chance to object?

thanks,

greg k-h

--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
--
___
Dri-devel mailing list
Dri-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms

[Russell King - ARM Linux]

On Thu, Jan 29, 2015 at 09:00:11PM +0530, Sumit Semwal wrote:
> So, short answer is, it is left to the exporter to decide. The dma-buf
> framework should not even attempt to decide or enforce any of the
> above.
> 
> At each dma_buf_attach(), there's a callback to the exporter, where
> the exporter can decide, if it intends to handle these kind of cases,
> on the best way forward.
> 
> The exporter might, for example, decide to migrate backing storage,

That's a decision which the exporter can not take.  Think about it...

If subsystem Y has mapped the buffer, it could be accessing the buffer's
backing storage at the same time that subsystem Z tries to attach to the
buffer.

Once the buffer has been exported to another user, the exporter has
effectively lost control over mediating accesses to that buffer.

All that it can do with the way the dma-buf API is today is to allocate
a _different_ scatter list pointing at the same backing storage which
satisfies the segment size and number of segments, etc.

There's also another issue which you haven't addressed.  What if several
attachments result in lowering max_segment_size and max_segment_count
such that:

max_segment_size * max_segment_count < dmabuf->size

but individually, the attachments allow dmabuf->size to be represented
as a scatterlist?

If an exporter were to take notice of the max_segment_size and
max_segment_count, the resulting buffer is basically unrepresentable
as a scatterlist.

> > Please consider the possible sequences of use (such as the scenario
> > above) when creating or augmenting an API.
> >
> 
> I tried to think of the scenarios I could think of, but If you still
> feel this approach doesn't help with your concerns, I'll graciously
> accept advice to improve it.

See the new one above :)

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

[PATCH] vt_buffer: drop console buffer copying optimisations

[Linus Torvalds]

On Wed, Jan 28, 2015 at 8:11 PM, Dave Airlie  wrote:
>
> Linus, this came up a while back I finally got some confirmation
> that it fixes those servers.

I'm certainly ok with this. which way should it go in? The users are:

 - drivers/tty/vt/vt.c (Greg KH, "tty layer")

 - drivers/video/console/* (fbcon people: Tomi Valkeinen and friends)

and it might make sense to have *some* indication of how much worse
this makes fbcon performance in particular..

Greg/Tomi - the patch is removing this:

  #define scr_memcpyw(d, s, c) memcpy(d, s, c)
  #define scr_memmovew(d, s, c) memmove(d, s, c)
  #define VT_BUF_HAVE_MEMCPYW
  #define VT_BUF_HAVE_MEMMOVEW

from , because some stupid graphics cards
apparently cannot handle 64-bit accesses of regular memcpy/memmove.

And on other setups, this will be the reverse: 8-bit accesses due to
using "rep movsb", which is the fast way to move/clear memory on
modern Intel CPU's, but is really wrong for MMIO where it will be slow
as hell.

So just getting rid of the memcpy/memmove is likely the right thing in
general, since the fallbacks go this the traditional 16-bit-at-a-time
way. And getting rid of the memcpy _may_ speed things up.

But if it slows things down, we might have to try something else. Like
saying "all cards we've ever seen have been ok with aligned 32-bit
accesses", and extend the open-coded scr_memcpy/memmove functions to
do that.

Hmm?

   Linus

--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
--
___
Dri-devel mailing list
Dri-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[PATCH libdrm 00/11] Random assortment of fixes and enhancements

[Emil Velikov]

On 23/01/15 16:08, Thierry Reding wrote:
> From: Thierry Reding 
> 
> This is a stash of commits that I've been carrying for a couple months.
> Laurent really wanted to have the connector name patch for modetest so
> I thought I'd send them all out for review.
> 
Hi Thierry,

As mentioned earlier I've noticed a couple of small bits while checking
out the Android build. Hope you don't mind my somewhat pedantic nit-picking.

The whole series can be found at

https://github.com/evelikov/libdrm/tree/for-tagr

-Emil

[Bug 88786] Radeon Hawaii crash on a 32-bit kernel

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

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

Alex Deucher  changed:

   What|Removed |Added

 Attachment #112919|0   |1
is obsolete||

--- Comment #10 from Alex Deucher  ---
Created attachment 112951
  --> https://bugs.freedesktop.org/attachment.cgi?id=112951=edit
possible fix

This updated patch should take care of it.

-- 
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/20150129/a234f456/attachment.html>

[PATCH 11.1/11] SQUASH: kms-universal-planes: link against cairo

[Emil Velikov]

Signed-off-by: Emil Velikov 
---
 tests/kms/Makefile.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/kms/Makefile.am b/tests/kms/Makefile.am
index 3b37e3e..fe7dd98 100644
--- a/tests/kms/Makefile.am
+++ b/tests/kms/Makefile.am
@@ -41,4 +41,4 @@ kms_steal_crtc_SOURCES = kms-steal-crtc.c
 kms_steal_crtc_LDADD = ../util/libutil.la $(TEST_LIBS)

 kms_universal_planes_SOURCES = kms-universal-planes.c
-kms_universal_planes_LDADD = libkms-test.la
+kms_universal_planes_LDADD = $(TEST_LIBS)
-- 
2.1.3

[PATCH 10.1/11] SQUASH: kms-steal-crtc: link against cairo

[Emil Velikov]

Signed-off-by: Emil Velikov 
---
 tests/kms/Makefile.am | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/tests/kms/Makefile.am b/tests/kms/Makefile.am
index 0e1b4ef..d033934 100644
--- a/tests/kms/Makefile.am
+++ b/tests/kms/Makefile.am
@@ -29,5 +29,11 @@ noinst_PROGRAMS = \
kms-steal-crtc
 endif

+TEST_LIBS = libkms-test.la
+
+if HAVE_CAIRO
+TEST_LIBS += $(CAIRO_LIBS)
+endif
+
 kms_steal_crtc_SOURCES = kms-steal-crtc.c
-kms_steal_crtc_LDADD = libkms-test.la ../util/libutil.la
+kms_steal_crtc_LDADD = ../util/libutil.la $(TEST_LIBS)
-- 
2.1.3

[PATCH v3] drm/dp: Use large transactions for I2C over AUX

[Ville Syrjälä]

On Tue, Jan 27, 2015 at 03:43:49PM +, Simon Farnsworth wrote:
> DisplayPort to DVI-D Dual Link adapters designed by Bizlink have bugs in
> their I2C over AUX implementation. They work fine with Windows, but fail
> with Linux.
> 
> It turns out that they cannot keep an I2C transaction open unless the
> previous read was 16 bytes; shorter reads can only be followed by a zero
> byte transfer ending the I2C transaction.
> 
> Copy Windows's behaviour, and read 16 bytes at a time. If we get a short
> reply, assume that there's a hardware bottleneck, and shrink our read size
> to match. For this purpose, use the algorithm in the DisplayPort 1.2 spec,
> in the hopes that it'll be closest to what Windows does, as no sink I've
> found actually gives short replies.
> 
> Also provide a module parameter for testing smaller transfer sizes, in case
> there are sinks out there that cannot work with Windows.
> 
> Signed-off-by: Simon Farnsworth 
> ---
> 
> v3 changes, after feedback from Ville and more testing of Windows:
> 
>  * Change the short reply algorithm to match Ville's description of the
>DisplayPort 1.2 spec wording.
> 
>  * Add a module parameter to set the default transfer size for
>experiments. Requested over IRC by Ville.
> 
> No-one's been able to find a device that does short replies, but experiments
> show that bigger reads are faster on most devices. Ville got:
> 
>  DP->DVI (OUI 001cf8):  40ms -> 35ms
>  DP->VGA (OUI 0022b9):  45ms -> 38ms
>  Zotac DP->2xHDMI:  25ms ->  4ms
> 
> v2 changes, after feedback from Thierry and Ville:
> 
>  * Handle short replies. I've decided (arbitrarily) that a short reply
>results in us dropping back to the newly chosen size for the rest of this
>I2C transaction. Thus, given an attempt to read the first 16 bytes of
>EDID, and a sink that only does 4 bytes of buffering, we will see the
>following AUX transfers for the EDID read (after address is set):
> 
>
>Read 16 bytes from I2C over AUX.
>Reply with 4 bytes
>Read 4 bytes
>Reply with 4 bytes
>Read 4 bytes
>Reply with 4 bytes
>Read 4 bytes
>Reply with 4 bytes
>
> 
> Note that I've not looked at MST support - I have neither the DP 1.2 spec
> nor any MST branch devices, so I can't test anything I write or check it
> against a spec. It looks from the code, however, as if MST has the branch
> device do the split from a big request into small transactions.
> 
>  drivers/gpu/drm/drm_dp_helper.c | 91 
> -
>  include/drm/drm_dp_helper.h |  5 +++
>  2 files changed, 77 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 79968e3..3db116c 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -396,11 +396,13 @@ static u32 drm_dp_i2c_functionality(struct i2c_adapter 
> *adapter)
>   * retrying the transaction as appropriate.  It is assumed that the
>   * aux->transfer function does not modify anything in the msg other than the
>   * reply field.
> + *
> + * Returns bytes transferred on success, or a negative error code on failure.
>   */
>  static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, struct drm_dp_aux_msg 
> *msg)
>  {
>   unsigned int retry;
> - int err;
> + int ret;
>  
>   /*
>* DP1.2 sections 2.7.7.1.5.6.1 and 2.7.7.1.6.6.1: A DP Source device
> @@ -409,14 +411,14 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, 
> struct drm_dp_aux_msg *msg)
>*/
>   for (retry = 0; retry < 7; retry++) {
>   mutex_lock(>hw_mutex);
> - err = aux->transfer(aux, msg);
> + ret = aux->transfer(aux, msg);
>   mutex_unlock(>hw_mutex);
> - if (err < 0) {
> - if (err == -EBUSY)
> + if (ret < 0) {
> + if (ret == -EBUSY)
>   continue;
>  
> - DRM_DEBUG_KMS("transaction failed: %d\n", err);
> - return err;
> + DRM_DEBUG_KMS("transaction failed: %d\n", ret);
> + return ret;
>   }
>  
>  
> @@ -457,9 +459,7 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, 
> struct drm_dp_aux_msg *msg)
>* Both native ACK and I2C ACK replies received. We
>* can assume the transfer was successful.
>*/
> - if (err < msg->size)
> - return -EPROTO;
> - return 0;
> + return ret;

The s/err/ret/ seems a bit superfluous, but OTOH it does make sense
since it's no longer just an error value. At first glance it just
confused me a bit since I wasn't expecting that many changes to this
function.

>  
>   case DP_AUX_I2C_REPLY_NACK:
>   DRM_DEBUG_KMS("I2C nack\n");
> @@ -482,14 +482,67 @@ static 

[PATCH 09.1/11] SQUASH: libkms-test: add missing header to the distribution

[Emil Velikov]

Signed-off-by: Emil Velikov 
---
 tests/kms/Makefile.am | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tests/kms/Makefile.am b/tests/kms/Makefile.am
index c84bae0..764a00d 100644
--- a/tests/kms/Makefile.am
+++ b/tests/kms/Makefile.am
@@ -8,6 +8,9 @@ AM_CFLAGS = \

 noinst_LTLIBRARIES = libkms-test.la

+noinst_HEADERS = \
+   libkms-test.h
+
 libkms_test_la_SOURCES = \
libkms-test-crtc.c \
libkms-test-device.c \
-- 
2.1.3

[PATCH 05.1/11] SQUASH: util: add the kms.[ch] to makefile.sources

[Emil Velikov]

Signed-off-by: Emil Velikov 
---
 tests/util/Makefile.sources | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tests/util/Makefile.sources b/tests/util/Makefile.sources
index e91fa72..e5f8511 100644
--- a/tests/util/Makefile.sources
+++ b/tests/util/Makefile.sources
@@ -2,5 +2,7 @@ UTIL_FILES := \
common.h \
format.c \
format.h \
+   kms.c \
+   kms.h \
pattern.c \
pattern.h
-- 
2.1.3

[PATCH 04.2/11] SQUASH: util: add android build

[Emil Velikov]

Signed-off-by: Emil Velikov 
---
 Android.mk|  1 +
 CleanSpec.mk  |  1 +
 tests/modetest/Android.mk |  5 -
 tests/util/Android.mk | 13 +
 4 files changed, 19 insertions(+), 1 deletion(-)
 create mode 100644 tests/util/Android.mk

diff --git a/Android.mk b/Android.mk
index 6f76113..af5f7a9 100644
--- a/Android.mk
+++ b/Android.mk
@@ -57,6 +57,7 @@ SUBDIRS := \
nouveau \
radeon \
libkms \
+   tests/util \
tests/modetest

 mkfiles := $(patsubst %,$(LIBDRM_TOP)/%/Android.mk,$(SUBDIRS))
diff --git a/CleanSpec.mk b/CleanSpec.mk
index 8e23cd2..28a11db 100644
--- a/CleanSpec.mk
+++ b/CleanSpec.mk
@@ -1,3 +1,4 @@
 $(call add-clean-step, rm -rf $(PRODUCT_OUT)/obj/include/libdrm)
 $(call add-clean-step, rm -rf $(PRODUCT_OUT)/obj/include/freedreno)
 $(call add-clean-step, rm -rf 
$(PRODUCT_OUT)/obj/SHARED_LIBRARIES/libdrm_*intermediates)
+$(call add-clean-step, rm -rf 
$(PRODUCT_OUT)/obj/STATIC_LIBRARIES/libdrm_*intermediates)
diff --git a/tests/modetest/Android.mk b/tests/modetest/Android.mk
index aee3564..6cf10dc 100644
--- a/tests/modetest/Android.mk
+++ b/tests/modetest/Android.mk
@@ -7,8 +7,11 @@ LOCAL_SRC_FILES := $(MODETEST_FILES)

 LOCAL_MODULE := modetest

-LOCAL_C_INCLUDES += $(TARGET_OUT_HEADERS)/libdrm
+LOCAL_C_INCLUDES += \
+   $(TARGET_OUT_HEADERS)/libdrm \
+   $(LIBDRM_TOP)/tests

 LOCAL_SHARED_LIBRARIES := libdrm
+LOCAL_STATIC_LIBRARIES := libdrm_util

 include $(BUILD_EXECUTABLE)
diff --git a/tests/util/Android.mk b/tests/util/Android.mk
new file mode 100644
index 000..4dc1cce
--- /dev/null
+++ b/tests/util/Android.mk
@@ -0,0 +1,13 @@
+LOCAL_PATH := $(call my-dir)
+
+include $(CLEAR_VARS)
+include $(LOCAL_PATH)/Makefile.sources
+
+LOCAL_SRC_FILES := $(UTIL_FILES)
+
+LOCAL_MODULE := libdrm_util
+
+LOCAL_C_INCLUDES += \
+   $(TARGET_OUT_HEADERS)/libdrm
+
+include $(BUILD_STATIC_LIBRARY)
-- 
2.1.3

[PATCH 04.1/11] SQUASH: tests: misc cleanups

[Emil Velikov]

Cairo
 - Add cflags only when needed (tests/util).
 - Leave the link against cairo for the final object, not the static
library.
 - Use Makefile.sources for the sources list.
 - Drop unused includes

Signed-off-by: Emil Velikov 
---
 tests/modetest/Makefile.am  |  1 -
 tests/modetest/buffers.c|  5 -
 tests/util/Makefile.am  | 12 +++-
 tests/util/Makefile.sources |  6 ++
 4 files changed, 9 insertions(+), 15 deletions(-)
 create mode 100644 tests/util/Makefile.sources

diff --git a/tests/modetest/Makefile.am b/tests/modetest/Makefile.am
index 88fde2e..40dad3e 100644
--- a/tests/modetest/Makefile.am
+++ b/tests/modetest/Makefile.am
@@ -23,7 +23,6 @@ modetest_LDADD = \
-lpthread

 if HAVE_CAIRO
-AM_CFLAGS += $(CAIRO_CFLAGS)
 modetest_LDADD += $(CAIRO_LIBS)
 endif

diff --git a/tests/modetest/buffers.c b/tests/modetest/buffers.c
index 4db4e9a..2db538c 100644
--- a/tests/modetest/buffers.c
+++ b/tests/modetest/buffers.c
@@ -44,11 +44,6 @@

 #include "buffers.h"

-#ifdef HAVE_CAIRO
-#include 
-#include 
-#endif
-
 struct bo
 {
int fd;
diff --git a/tests/util/Makefile.am b/tests/util/Makefile.am
index 1a2519f..f8e0b17 100644
--- a/tests/util/Makefile.am
+++ b/tests/util/Makefile.am
@@ -1,3 +1,5 @@
+include Makefile.sources
+
 noinst_LTLIBRARIES = \
libutil.la

@@ -8,12 +10,4 @@ libutil_la_CPPFLAGS = \
 libutil_la_CFLAGS = \
$(CAIRO_CFLAGS)

-libutil_la_SOURCES = \
-   common.h \
-   format.c \
-   format.h \
-   pattern.c \
-   pattern.h
-
-libutil_la_LIBADD = \
-   $(CAIRO_LIBS)
+libutil_la_SOURCES = $(UTIL_FILES)
diff --git a/tests/util/Makefile.sources b/tests/util/Makefile.sources
new file mode 100644
index 000..e91fa72
--- /dev/null
+++ b/tests/util/Makefile.sources
@@ -0,0 +1,6 @@
+UTIL_FILES := \
+   common.h \
+   format.c \
+   format.h \
+   pattern.c \
+   pattern.h
-- 
2.1.3

[RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms

[Maarten Lankhorst]

Op 27-01-15 om 09:25 schreef Sumit Semwal:
> Add some helpers to share the constraints of devices while attaching
> to the dmabuf buffer.
>
> At each attach, the constraints are calculated based on the following:
> - max_segment_size, max_segment_count, segment_boundary_mask from
>device_dma_parameters.
>
> In case the attaching device's constraints don't match up, attach() fails.
>
> At detach, the constraints are recalculated based on the remaining
> attached devices.
>
> Two helpers are added:
> - dma_buf_get_constraints - which gives the current constraints as calculated
>   during each attach on the buffer till the time,
> - dma_buf_recalc_constraints - which recalculates the constraints for all
>   currently attached devices for the 'paranoid' ones amongst us.
>
> The idea of this patch is largely taken from Rob Clark's RFC at
> https://lkml.org/lkml/2012/7/19/285, and the comments received on it.
>
> Cc: Rob Clark 
> Signed-off-by: Sumit Semwal 
> ---
> v3: 
> - Thanks to Russell's comment, remove dma_mask and coherent_dma_mask from
>   constraints' calculation; has a nice side effect of letting us use
>   device_dma_parameters directly to list constraints.
> - update the debugfs output to show constraint info as well.
>   
> v2: split constraints-sharing and allocation helpers
>
>  drivers/dma-buf/dma-buf.c | 126 
> +-
>  include/linux/dma-buf.h   |   7 +++
>  2 files changed, 132 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 5be225c2ba98..f363f1440803 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -264,6 +264,66 @@ static inline int is_dma_buf_file(struct file *file)
>   return file->f_op == _buf_fops;
>  }
>  
> +static inline void init_constraints(struct device_dma_parameters *cons)
> +{
> + cons->max_segment_count = (unsigned int)-1;
> + cons->max_segment_size = (unsigned int)-1;
> + cons->segment_boundary_mask = (unsigned long)-1;
> +}
Use DMA_SEGMENTS_MAX_SEG_COUNT or UINT/ULONG_MAX here instead?

Patches look sane,
Reviewed-By: Maarten Lankhorst 
> +/*
> + * calc_constraints - calculates if the new attaching device's constraints
> + * match, with the constraints of already attached devices; if yes, returns
> + * the constraints; else return ERR_PTR(-EINVAL)
> + */
> +static int calc_constraints(struct device *dev,
> + struct device_dma_parameters *calc_cons)
> +{
> + struct device_dma_parameters cons = *calc_cons;
> +
> + cons.max_segment_count = min(cons.max_segment_count,
> + dma_get_max_seg_count(dev));
> + cons.max_segment_size = min(cons.max_segment_size,
> + dma_get_max_seg_size(dev));
> + cons.segment_boundary_mask &= dma_get_seg_boundary(dev);
> +
> + if (!cons.max_segment_count ||
> + !cons.max_segment_size ||
> + !cons.segment_boundary_mask) {
> + pr_err("Dev: %s's constraints don't match\n", dev_name(dev));
> + return -EINVAL;
> + }
> +
> + *calc_cons = cons;
> +
> + return 0;
> +}
> +
> +/*
> + * recalc_constraints - recalculates constraints for all attached devices;
> + *  useful for detach() recalculation, and for dma_buf_recalc_constraints()
> + *  helper.
> + *  Returns recalculated constraints in recalc_cons, or error in the unlikely
> + *  case when constraints of attached devices might have changed.
> + */
> +static int recalc_constraints(struct dma_buf *dmabuf,
> +   struct device_dma_parameters *recalc_cons)
> +{
> + struct device_dma_parameters calc_cons;
> + struct dma_buf_attachment *attach;
> + int ret = 0;
> +
> + init_constraints(_cons);
> +
> + list_for_each_entry(attach, >attachments, node) {
> + ret = calc_constraints(attach->dev, _cons);
> + if (ret)
> + return ret;
> + }
> + *recalc_cons = calc_cons;
> + return 0;
> +}
> +
>  /**
>   * dma_buf_export_named - Creates a new dma_buf, and associates an anon file
>   * with this buffer, so it can be exported.
> @@ -313,6 +373,9 @@ struct dma_buf *dma_buf_export_named(void *priv, const 
> struct dma_buf_ops *ops,
>   dmabuf->ops = ops;
>   dmabuf->size = size;
>   dmabuf->exp_name = exp_name;
> +
> + init_constraints(>constraints);
> +
>   init_waitqueue_head(>poll);
>   dmabuf->cb_excl.poll = dmabuf->cb_shared.poll = >poll;
>   dmabuf->cb_excl.active = dmabuf->cb_shared.active = 0;
> @@ -422,7 +485,7 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf 
> *dmabuf,
> struct device *dev)
>  {
>   struct dma_buf_attachment *attach;
> - int ret;
> + int ret = 0;
>  
>   if (WARN_ON(!dmabuf || !dev))
>   return ERR_PTR(-EINVAL);
> @@ -436,6 +499,9 @@ struct dma_buf_attachment 

[PATCH v3] drm/dp: Use large transactions for I2C over AUX

[Simon Farnsworth]

On Thursday 29 January 2015 16:36:55 Ville Syrjälä wrote:
> On Thu, Jan 29, 2015 at 02:24:09PM +, Simon Farnsworth wrote:
> > On Thursday 29 January 2015 15:30:36 you wrote:
> > > On Tue, Jan 27, 2015 at 03:43:49PM +, Simon Farnsworth wrote:
--snip--
> > > > +   DRM_DEBUG_KMS("Partial I2C reply: requested %zu bytes got %d 
> > > > bytes\n", msg->size, ret);
> > > > +   drain_msg = *msg;
> > > > +   drain_msg.size -= ret;
> > > > +   drain_msg.buffer += ret;
> > > > +   while (drain_msg.size != 0) {
> > > > +   drain_bytes = drm_dp_i2c_do_msg(aux, _msg);
> > > > +   if (drain_bytes <= 0)
> > > > +   return drain_bytes == 0 ? -EPROTO : drain_bytes;
> > > > +   drain_msg.size -= drain_bytes;
> > > > +   drain_msg.buffer += drain_bytes;
> > > > +   }
> > > 
> > > Somehow I don't like the duplicated code end up having here. So
> > > putting it all in a single loop would seem nicer to me. Maybe
> > > something along these lines?
> > > 
> > > struct drm_dp_aux_msg msg = *orig_msg;
> > > int ret = msg.size;
> > > while (msg.size > 0) {
> > >   int err = drm_dp_i2c_do_msg(aux, );
> > >   if (err <= 0)
> > >   return err == 0 ? -EPROTO : err;
> > > 
> > >   if (err < msg.size && err < ret) {
> > >   DRM_DEBUG_KMS("Partial I2C reply: requested %zu
> > >  bytes got %d bytes\n", msg.size, err);
> > >   ret = err;
> > >   }
> > > 
> > >   msg.size -= err;
> > >   msg.buffer += err;
> > > }
> > > 
> > > It would also reduce the returned preferred transfer size further if we
> > > (for whatever reason) got an even shorter reply while we're draining.
> > >
> > I'm not sure that that's the right behaviour, though. If we assume a 3 byte
> > FIFO in a device that does partial reads, we ask for 16 bytes, causing a
> > partial response that's 3 bytes long. We then drain out the remaining 13
> > bytes of the initial request (in case it's set up a 16 byte I2C transfer),
> > and the last of the reads is guaranteed to be 1 byte long.
> 
> My proposed code wouldn't reduce the transfer size in that case due to
> the err when the reply came back with less data than was requested.
>
I see, yes. So the only time it'd reduce further is if the hypothetical
device gave a 3 byte response to the 16 byte transfer, then 2 byte responses
to the remaining requests that try to drain the FIFO.

Given that this is now in the realms of "if hardware designers took pleasure
in making their hardware horrible", rather than just "HW designer takes a
short cut and lets software handle the pain", I'll take your code for v4.
> > 
> > We then shrink to 1 byte transfers, when the device would be capable of 3
> > byte transfers, and could possibly perform better with 3 byte transfers
> > rather than 1.
> > 
> > Having said that, this is all hypothetical until we find devices that do
> > partial replies - no-one's been able to find such a device so far.
> > 

-- 
Simon Farnsworth
Software Engineer
ONELAN Ltd
http://www.onelan.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150129/a4913bad/attachment.sig>

[PATCH v2] drm/tegra: Add tegra_gem_mmap2 to fix 64-bit offsets

[Rob Clark]

On Thu, Jan 29, 2015 at 2:18 PM, Sean Paul  wrote:
> On 64-bit targets, tegra_gem_mmap doesn't return the
> offset to userspace. As such, subsequent calls to mmap(2)
> fail. Add a new tegra_gem_mmap2 ioctl to fix this.
>
> Signed-off-by: Sean Paul 

Reviewed-by: Rob Clark 


> ---
>  drivers/gpu/drm/tegra/drm.c  | 21 +
>  include/uapi/drm/tegra_drm.h |  9 +
>  2 files changed, 30 insertions(+)
>
> diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
> index d4f8275..be5dbe7 100644
> --- a/drivers/gpu/drm/tegra/drm.c
> +++ b/drivers/gpu/drm/tegra/drm.c
> @@ -343,6 +343,26 @@ static int tegra_gem_create(struct drm_device *drm, void 
> *data,
> return 0;
>  }
>
> +static int tegra_gem_mmap2(struct drm_device *drm, void *data,
> + struct drm_file *file)
> +{
> +   struct drm_tegra_gem_mmap2 *args = data;
> +   struct drm_gem_object *gem;
> +   struct tegra_bo *bo;
> +
> +   gem = drm_gem_object_lookup(drm, file, args->handle);
> +   if (!gem)
> +   return -EINVAL;
> +
> +   bo = to_tegra_bo(gem);
> +
> +   args->offset = drm_vma_node_offset_addr(>gem.vma_node);
> +
> +   drm_gem_object_unreference(gem);
> +
> +   return 0;
> +}
> +
>  static int tegra_gem_mmap(struct drm_device *drm, void *data,
>   struct drm_file *file)
>  {
> @@ -677,6 +697,7 @@ static const struct drm_ioctl_desc tegra_drm_ioctls[] = {
> DRM_IOCTL_DEF_DRV(TEGRA_GEM_GET_TILING, tegra_gem_get_tiling, 
> DRM_UNLOCKED),
> DRM_IOCTL_DEF_DRV(TEGRA_GEM_SET_FLAGS, tegra_gem_set_flags, 
> DRM_UNLOCKED),
> DRM_IOCTL_DEF_DRV(TEGRA_GEM_GET_FLAGS, tegra_gem_get_flags, 
> DRM_UNLOCKED),
> +   DRM_IOCTL_DEF_DRV(TEGRA_GEM_MMAP2, tegra_gem_mmap2, DRM_UNLOCKED),
>  #endif
>  };
>
> diff --git a/include/uapi/drm/tegra_drm.h b/include/uapi/drm/tegra_drm.h
> index c15d781..9057b0f 100644
> --- a/include/uapi/drm/tegra_drm.h
> +++ b/include/uapi/drm/tegra_drm.h
> @@ -167,6 +167,13 @@ struct drm_tegra_gem_get_flags {
> __u32 flags;
>  };
>
> +struct drm_tegra_gem_mmap2 {
> +   __u32 handle;
> +   __u32 pad;
> +   __u64 offset;
> +};
> +
> +
>  #define DRM_TEGRA_GEM_CREATE   0x00
>  #define DRM_TEGRA_GEM_MMAP 0x01
>  #define DRM_TEGRA_SYNCPT_READ  0x02
> @@ -181,6 +188,7 @@ struct drm_tegra_gem_get_flags {
>  #define DRM_TEGRA_GEM_GET_TILING   0x0b
>  #define DRM_TEGRA_GEM_SET_FLAGS0x0c
>  #define DRM_TEGRA_GEM_GET_FLAGS0x0d
> +#define DRM_TEGRA_GEM_MMAP20x0e
>
>  #define DRM_IOCTL_TEGRA_GEM_CREATE DRM_IOWR(DRM_COMMAND_BASE + 
> DRM_TEGRA_GEM_CREATE, struct drm_tegra_gem_create)
>  #define DRM_IOCTL_TEGRA_GEM_MMAP DRM_IOWR(DRM_COMMAND_BASE + 
> DRM_TEGRA_GEM_MMAP, struct drm_tegra_gem_mmap)
> @@ -196,5 +204,6 @@ struct drm_tegra_gem_get_flags {
>  #define DRM_IOCTL_TEGRA_GEM_GET_TILING DRM_IOWR(DRM_COMMAND_BASE + 
> DRM_TEGRA_GEM_GET_TILING, struct drm_tegra_gem_get_tiling)
>  #define DRM_IOCTL_TEGRA_GEM_SET_FLAGS DRM_IOWR(DRM_COMMAND_BASE + 
> DRM_TEGRA_GEM_SET_FLAGS, struct drm_tegra_gem_set_flags)
>  #define DRM_IOCTL_TEGRA_GEM_GET_FLAGS DRM_IOWR(DRM_COMMAND_BASE + 
> DRM_TEGRA_GEM_GET_FLAGS, struct drm_tegra_gem_get_flags)
> +#define DRM_IOCTL_TEGRA_GEM_MMAP2 DRM_IOWR(DRM_COMMAND_BASE + 
> DRM_TEGRA_GEM_MMAP2, struct drm_tegra_gem_mmap2)
>
>  #endif
> --
> 2.2.0.rc0.207.ga3a616c
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH -v2] drm/exynos: track vblank events on a per crtc basis

[Gustavo Padovan]

From: Mandeep Singh Baines 

The goal of the change is to make sure we send the vblank event on the
current vblank. My hope is to fix any races that might be causing flicker.
After this change I only see a flicker in the transition plymouth and
X11.

Simplified the code by tracking vblank events on a per-crtc basis. This
allowed me to remove all error paths from the callback. It also allowed
me to remove the vblank wait from the callback.

Signed-off-by: Mandeep Singh Baines 
Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c | 29 +++--
 drivers/gpu/drm/exynos/exynos_drm_drv.c  | 19 ---
 drivers/gpu/drm/exynos/exynos_drm_drv.h  |  6 ++
 3 files changed, 9 insertions(+), 45 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index a85c451..91c175b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -34,9 +34,8 @@ static void exynos_drm_crtc_dpms(struct drm_crtc *crtc, int 
mode)
if (mode > DRM_MODE_DPMS_ON) {
/* wait for the completion of page flip. */
if (!wait_event_timeout(exynos_crtc->pending_flip_queue,
-   !atomic_read(_crtc->pending_flip),
-   HZ/20))
-   atomic_set(_crtc->pending_flip, 0);
+   (exynos_crtc->event == NULL), HZ/20))
+   exynos_crtc->event = NULL;
drm_crtc_vblank_off(crtc);
}

@@ -166,7 +165,6 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc,
 uint32_t page_flip_flags)
 {
struct drm_device *dev = crtc->dev;
-   struct exynos_drm_private *dev_priv = dev->dev_private;
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
struct drm_framebuffer *old_fb = crtc->primary->fb;
unsigned int crtc_w, crtc_h;
@@ -195,9 +193,7 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc,
}

spin_lock_irq(>event_lock);
-   list_add_tail(>base.link,
-   _priv->pageflip_event_list);
-   atomic_set(_crtc->pending_flip, 1);
+   exynos_crtc->event = event;
spin_unlock_irq(>event_lock);

crtc->primary->fb = fb;
@@ -209,11 +205,7 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc,
if (ret) {
crtc->primary->fb = old_fb;

-   spin_lock_irq(>event_lock);
drm_vblank_put(dev, exynos_crtc->pipe);
-   list_del(>base.link);
-   atomic_set(_crtc->pending_flip, 0);
-   spin_unlock_irq(>event_lock);

goto out;
}
@@ -315,7 +307,6 @@ struct exynos_drm_crtc *exynos_drm_crtc_create(struct 
drm_device *drm_dev,
return ERR_PTR(-ENOMEM);

init_waitqueue_head(_crtc->pending_flip_queue);
-   atomic_set(_crtc->pending_flip, 0);

exynos_crtc->dpms = DRM_MODE_DPMS_OFF;
exynos_crtc->pipe = pipe;
@@ -382,26 +373,20 @@ void exynos_drm_crtc_disable_vblank(struct drm_device 
*dev, int pipe)
 void exynos_drm_crtc_finish_pageflip(struct drm_device *dev, int pipe)
 {
struct exynos_drm_private *dev_priv = dev->dev_private;
-   struct drm_pending_vblank_event *e, *t;
struct drm_crtc *drm_crtc = dev_priv->crtc[pipe];
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(drm_crtc);
unsigned long flags;

spin_lock_irqsave(>event_lock, flags);
+   if (exynos_crtc->event) {

-   list_for_each_entry_safe(e, t, _priv->pageflip_event_list,
-   base.link) {
-   /* if event's pipe isn't same as crtc then ignore it. */
-   if (pipe != e->pipe)
-   continue;
-
-   list_del(>base.link);
-   drm_send_vblank_event(dev, -1, e);
+   drm_send_vblank_event(dev, -1, exynos_crtc->event);
drm_vblank_put(dev, pipe);
-   atomic_set(_crtc->pending_flip, 0);
wake_up(_crtc->pending_flip_queue);
+
}

+   exynos_crtc->event = NULL;
spin_unlock_irqrestore(>event_lock, flags);
 }

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index b60fd9b..731cdbc 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -61,7 +61,6 @@ static int exynos_drm_load(struct drm_device *dev, unsigned 
long flags)
if (!private)
return -ENOMEM;

-   INIT_LIST_HEAD(>pageflip_event_list);
dev_set_drvdata(dev->dev, dev);
dev->dev_private = (void *)private;

@@ -237,27 +236,9 @@ static void 

[Bug 88758] Low FPS in settings on Dota2

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

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

--- Comment #16 from smoki  ---
 Hm well i can't see slowdwons in dota, but anyway as a guess can you try to
revert this mesa commit i see some slodowns with it too:

https://bugs.freedesktop.org/show_bug.cgi?id=88658#c6

-- 
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/20150129/64a81239/attachment.html>

[PATCH] drm/bridge: sti_dvo: adapt to updated bridge API

[Ajay Kumar]

Commits 8eb17f05bc1802b50f8b536406357b87f63cf61d
("drm/bridge: do not pass drm_bridge_funcs to drm_bridge_init") and
fbc4572e9c48e45bdfeb2ee8c8f0198b3e70c030
("drm/bridge: make bridge registration independent of drm flow")
changed the bridge API without taking into account sti_dvo bridge
which caused the following build breakage on linux-next:

drivers/gpu/drm/sti/sti_dvo.c: In function ‘sti_dvo_brigde_destroy’:
drivers/gpu/drm/sti/sti_dvo.c:277:2: error: implicit declaration of function 
‘drm_bridge_cleanup’
drivers/gpu/drm/sti/sti_dvo.c: At top level:
drivers/gpu/drm/sti/sti_dvo.c:287:2: error: unknown field ‘destroy’ 
specified in initializer
drivers/gpu/drm/sti/sti_dvo.c: In function ‘sti_dvo_bind’:
drivers/gpu/drm/sti/sti_dvo.c:419:2: error: implicit declaration of function 
‘drm_bridge_init’

Make the necessary changes to sti_dvo bridge in order to fix the build breakage.

Signed-off-by: Ajay Kumar 
---
This patch contains the minimal changes needed instead of having this:
http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-next=384764c3611645d96889742a079168c86a6fc4c4

 drivers/gpu/drm/sti/sti_dvo.c |   11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_dvo.c b/drivers/gpu/drm/sti/sti_dvo.c
index 651afad..1088fc5 100644
--- a/drivers/gpu/drm/sti/sti_dvo.c
+++ b/drivers/gpu/drm/sti/sti_dvo.c
@@ -272,19 +272,12 @@ static void sti_dvo_bridge_nope(struct drm_bridge *bridge)
/* do nothing */
 }

-static void sti_dvo_brigde_destroy(struct drm_bridge *bridge)
-{
-   drm_bridge_cleanup(bridge);
-   kfree(bridge);
-}
-
 static const struct drm_bridge_funcs sti_dvo_bridge_funcs = {
.pre_enable = sti_dvo_pre_enable,
.enable = sti_dvo_bridge_nope,
.disable = sti_dvo_disable,
.post_disable = sti_dvo_bridge_nope,
.mode_set = sti_dvo_set_mode,
-   .destroy = sti_dvo_brigde_destroy,
 };

 static int sti_dvo_connector_get_modes(struct drm_connector *connector)
@@ -416,7 +409,8 @@ static int sti_dvo_bind(struct device *dev, struct device 
*master, void *data)
return -ENOMEM;

bridge->driver_private = dvo;
-   drm_bridge_init(drm_dev, bridge, _dvo_bridge_funcs);
+   bridge->funcs = _dvo_bridge_funcs;
+   drm_bridge_attach(drm_dev, bridge);

encoder->bridge = bridge;
connector->encoder = encoder;
@@ -446,7 +440,6 @@ static int sti_dvo_bind(struct device *dev, struct device 
*master, void *data)
 err_sysfs:
drm_connector_unregister(drm_connector);
 err_connector:
-   drm_bridge_cleanup(bridge);
drm_connector_cleanup(drm_connector);
return -EINVAL;
 }
-- 
1.7.9.5

[RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms

[Russell King - ARM Linux]

On Tue, Jan 27, 2015 at 01:55:54PM +0530, Sumit Semwal wrote:
> +/*
> + * recalc_constraints - recalculates constraints for all attached devices;
> + *  useful for detach() recalculation, and for dma_buf_recalc_constraints()
> + *  helper.
> + *  Returns recalculated constraints in recalc_cons, or error in the unlikely
> + *  case when constraints of attached devices might have changed.
> + */

Please see kerneldoc documentation for the proper format of these comments.

> +static int recalc_constraints(struct dma_buf *dmabuf,
> +   struct device_dma_parameters *recalc_cons)
> +{
> + struct device_dma_parameters calc_cons;
> + struct dma_buf_attachment *attach;
> + int ret = 0;
> +
> + init_constraints(_cons);
> +
> + list_for_each_entry(attach, >attachments, node) {
> + ret = calc_constraints(attach->dev, _cons);
> + if (ret)
> + return ret;
> + }
> + *recalc_cons = calc_cons;
> + return 0;
> +}
> +
>  /**
>   * dma_buf_export_named - Creates a new dma_buf, and associates an anon file
>   * with this buffer, so it can be exported.
> @@ -313,6 +373,9 @@ struct dma_buf *dma_buf_export_named(void *priv, const 
> struct dma_buf_ops *ops,
>   dmabuf->ops = ops;
>   dmabuf->size = size;
>   dmabuf->exp_name = exp_name;
> +
> + init_constraints(>constraints);
> +
>   init_waitqueue_head(>poll);
>   dmabuf->cb_excl.poll = dmabuf->cb_shared.poll = >poll;
>   dmabuf->cb_excl.active = dmabuf->cb_shared.active = 0;
> @@ -422,7 +485,7 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf 
> *dmabuf,
> struct device *dev)
>  {
>   struct dma_buf_attachment *attach;
> - int ret;
> + int ret = 0;
>  
>   if (WARN_ON(!dmabuf || !dev))
>   return ERR_PTR(-EINVAL);
> @@ -436,6 +499,9 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf 
> *dmabuf,
>  
>   mutex_lock(>lock);
>  
> + if (calc_constraints(dev, >constraints))
> + goto err_constraints;
> +
>   if (dmabuf->ops->attach) {
>   ret = dmabuf->ops->attach(dmabuf, dev, attach);
>   if (ret)
> @@ -448,6 +514,7 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf 
> *dmabuf,
>  
>  err_attach:
>   kfree(attach);
> +err_constraints:
>   mutex_unlock(>lock);
>   return ERR_PTR(ret);
>  }
> @@ -470,6 +537,8 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct 
> dma_buf_attachment *attach)
>   if (dmabuf->ops->detach)
>   dmabuf->ops->detach(dmabuf, attach);
>  
> + recalc_constraints(dmabuf, >constraints);
> +

To me, this whole thing seems horribly racy.

What happens if subsystem X creates a dmabuf, which is passed to
userspace. It's then passed to subsystem Y, which starts making use
of it, calling dma_buf_map_attachment() on it.

The same buffer is also passed (via unix domain sockets) to another
program, which then passes it independently into subsystem Z, and
subsystem Z has more restrictive DMA constraints.

What happens at this point?

Subsystems such as DRM cache the scatter table, and return it for
subsequent attach calls, so DRM drivers using the default
drm_gem_map_dma_buf() implementation would not see the restrictions
placed upon the dmabuf.  Moreover, the returned scatterlist would not
be modified for those restrictions either.

What would other subsystems do?

This needs more thought before it's merged.

For example, in the above situation, should we deny the ability to
create a new attachment when a dmabuf has already been mapped by an
existing attachment?  Should we deny it only when the new attachment
has more restrictive DMA constraints?

Please consider the possible sequences of use (such as the scenario
above) when creating or augmenting an API.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

[Bug 88758] Low FPS in settings on Dota2

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

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

--- Comment #15 from Lorenzo Bona  ---
(In reply to smoki from comment #13)
>  This looks to me like another "32bit toolchain caused stutter" like in bug
> 83436
> 
>  Lorenzo, can you try how it goes if you add in your script also '-mtune' to
> both CFLAGS and CXXFLAGS ?

Yeah, looks like it's the same issue, btw I've rebuilded mesa with 
" .. -mtune=native -march=native .." and nothing change with newer 3.19 kernel.

I get 1 FPS in menus/settings and around 30 in game.
With the 3.16rc6 I get always 60FPS (vsync 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/20150129/894ba786/attachment-0001.html>

[PATCH] RFC: drm: add support for tiled/compressed/etc modifier in addfb2 (v1.5)

[Daniel Vetter]

On Thu, Jan 29, 2015 at 12:55:48PM +, Tvrtko Ursulin wrote:
> 
> On 01/29/2015 11:57 AM, Daniel Vetter wrote:
> >On Thu, Jan 29, 2015 at 11:43:07AM +, Tvrtko Ursulin wrote:
> >>
> >>On 01/29/2015 11:30 AM, Daniel Vetter wrote:
> >>>On Wed, Jan 28, 2015 at 05:57:56PM +, Tvrtko Ursulin wrote:
> 
> On 01/28/2015 05:37 PM, Daniel Vetter wrote:
> >From: Rob Clark 
> >
> >In DRM/KMS we are lacking a good way to deal with tiled/compressed
> >formats.  Especially in the case of dmabuf/prime buffer sharing, where
> >we cannot always rely on under-the-hood flags passed to driver specific
> >gem-create ioctl to pass around these extra flags.
> >
> >The proposal is to add a per-plane format modifier.  This allows to, if
> >necessary, use different tiling patters for sub-sampled planes, etc.
> >The format modifiers are added at the end of the ioctl struct, so for
> >legacy userspace it will be zero padded.
> >
> >TODO how best to deal with assignment of modifier token values?  The
> >rough idea was to namespace things with an 8bit vendor-id, and then
> >beyond that it is treated as an opaque value.  But that was a relatively
> >arbitrary choice.  There are cases where same tiling pattern and/or
> >compression is supported by various different vendors.  So we should
> >standardize to use the vendor-id and value of the first one who
> >documents the format?
> 
> Maybe:
>   __u64 modifier[4];
>   __u64 vendor_modifier[4];
> >>>
> >>>Seems rendundant since the modifier added in this patch is already vendor
> >>>specific. Or what exactly are you trying to accomplish here?
> >>
> >>I am trying to avoid packet-in-a-packet (bitmasks) mumbo-jumbo and vendor id
> >>on the head followed by maybe standardized or maybe vendor specific tag.
> >>Feels funny. Would it not be simpler to put a struct in there?
> >
> >The u64 modifier is just an opaque thing, with 8 bit to identifier the
> >vendor (for easier number management really) and the low 56 bits can be
> >whatever we want them. On i915 I think we should just enumerate all the
> >various tiling modes we have. And if the modifiers aren't set we use the
> >tiling mode of the underlying gem bo. We already have code in place to
> >guarantee that the underlying bo's tiling can't change as long as there's
> >a kms fb around, which means all code which checks for tiling can switch
> >over to these flags.
> >
> >struct won't work since by definition this is vendor-specific, and every
> >vendor is slightly insane in a different way.
> 
> Well 8 + 56 bits is a "struct" already and not fully opaque. Are the bits
> expensive? :) That was first part of my point.
> 
> Secondly, "vendor who registers first" part of discussion is what came to my
> attention as well.
> 
> With this, a hypothetical standard format would be under a vendor id which
> looks funny to me. While you could split standard formats/modifiers and
> vendor specific modifiers.

If some standard body actually manages to pull this off we can always add
a new enum value for KHRONOS or MICROSOFT or ISO or whatever it ends up
being. The split really is just to make number assignements less
conflit-y.

> I don't care really, it was just an idea, but I don't get this arguments why
> it is, not only not better, but worse than a bitfield. :)

Just from your struct without any explanation what your idea was (namely
modifiers which are standardized across vendors it seems) it looked like
both a plain modifier and a vendor_modifier was possible. Which didn't
make a lot of sense to me, so I asked.

Going with an opaque u64 has the benefits that it matches kms property
values. So if we ever extend this and allow generic properties for
framebuffers it'll still fit. A struct is more painful. The idea of fb
properties was one of the longer-term ideas tossed around in the v1
thread.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH v3] drm/dp: Use large transactions for I2C over AUX

[Simon Farnsworth]

msg.size -= drain_bytes;
> > +   drain_msg.buffer += drain_bytes;
> > +   }
> 
> Somehow I don't like the duplicated code end up having here. So
> putting it all in a single loop would seem nicer to me. Maybe
> something along these lines?
> 
> struct drm_dp_aux_msg msg = *orig_msg;
> int ret = msg.size;
> while (msg.size > 0) {
>   int err = drm_dp_i2c_do_msg(aux, );
>   if (err <= 0)
>   return err == 0 ? -EPROTO : err;
> 
>   if (err < msg.size && err < ret) {
>   DRM_DEBUG_KMS("Partial I2C reply: requested %zu
>  bytes got %d bytes\n", msg.size, err);
>   ret = err;
>   }
> 
>   msg.size -= err;
>   msg.buffer += err;
> }
> 
> It would also reduce the returned preferred transfer size further if we
> (for whatever reason) got an even shorter reply while we're draining.
>
I'm not sure that that's the right behaviour, though. If we assume a 3 byte
FIFO in a device that does partial reads, we ask for 16 bytes, causing a
partial response that's 3 bytes long. We then drain out the remaining 13
bytes of the initial request (in case it's set up a 16 byte I2C transfer),
and the last of the reads is guaranteed to be 1 byte long.

We then shrink to 1 byte transfers, when the device would be capable of 3
byte transfers, and could possibly perform better with 3 byte transfers
rather than 1.

Having said that, this is all hypothetical until we find devices that do
partial replies - no-one's been able to find such a device so far.

I'll have a think and see if I can come up with a way to get the behaviour I
want with less code duplication - I might be able to do something by using a
sentinel value to spot first time round the loop.

> 
> > +   return ret;
> > +}
> > +
> > +/*
> > + * Bizlink designed DP->DVI-D Dual Link adapters require the I2C over AUX
> > + * packets to be as large as possible. If not, the I2C transactions never
> > + * succeed. Hence the default is maximum.
> > + */
> > +static int dp_aux_i2c_transfer_size __read_mostly = 
> > DP_AUX_MAX_PAYLOAD_BYTES;
> > +module_param_named(dp_aux_i2c_transfer_size, dp_aux_i2c_transfer_size, 
> > int, 0600);
> > +MODULE_PARM_DESC(dp_aux_i2c_transfer_size,
> > +"Number of bytes to transfer in a single I2C over DP AUX CH 
> > message, (1-16, default 16)");
> > +
> >  static int drm_dp_i2c_xfer(struct i2c_adapter *adapter, struct i2c_msg 
> > *msgs,
> >int num)
> >  {
> > struct drm_dp_aux *aux = adapter->algo_data;
> > unsigned int i, j;
> > +   int transfer_size;
> > struct drm_dp_aux_msg msg;
> > int err = 0;
> >  
> > +   if (dp_aux_i2c_transfer_size < 1 || dp_aux_i2c_transfer_size > 
> > DP_AUX_MAX_PAYLOAD_BYTES) {
> > +   DRM_ERROR("dp_aux_i2c_transfer_size invalid - changing from %d 
> > to %d\n",
> > + dp_aux_i2c_transfer_size, DP_AUX_MAX_PAYLOAD_BYTES);
> > +   dp_aux_i2c_transfer_size = DP_AUX_MAX_PAYLOAD_BYTES;
> > +   }
> 
> The invalid values could be rejected with custom struct
> kernel_param_ops, but maybe that's a bit overkill. If not that, then
> I'm not sure the error message really has that much value. So I'm thinking
> we could just 'clamp(..., 1, DP_AUX_MAX_PAYLOAD_BYTES)' here.
>
I'll remove the message for v4, as well as marking the parameter unsafe with
module_param_named_unsafe, and use clamp instead of if().

> > +
> > memset(, 0, sizeof(msg));
> >  
> > for (i = 0; i < num; i++) {
> > @@ -507,20 +560,20 @@ static int drm_dp_i2c_xfer(struct i2c_adapter 
> > *adapter, struct i2c_msg *msgs,
> > err = drm_dp_i2c_do_msg(aux, );
> > if (err < 0)
> > break;
> > -   /*
> > -* Many hardware implementations support FIFOs larger than a
> > -* single byte, but it has been empirically determined that
> > -* transferring data in larger chunks can actually lead to
> > -* decreased performance. Therefore each message is simply
> > -* transferred byte-by-byte.
> > +   /* We want each transaction to be as large as possible, but
> > +* we'll go to smaller sizes if the hardware gives us a
> > +* short reply.
> >  */
> > -   for (j = 0; j < msgs[i].len; j++) {
> > +   transfer_size = dp_aux_i2c_transfer_size;
> > +   for (j = 0; j < msgs[i].len; j += msg.size) {
> > msg.buffer = msgs[i].buf + j;
> > -   msg.size = 1;
> > +   msg.size = min((unsigned)transfer_size, msgs[i].len - 
> > j);
> 
> Could make transfer_size unsigned in the first place.
> 
> >  
> > -   err = drm_dp_i2c_do_msg(aux, );
> > -   if (err < 0)
> > +   transfer_size = drm_dp_i2c_drain_msg(aux, );
> > +   if (transfer_size < 0) {
> > +   err = transfer_size;
> > break;
> > +   }
> 
> Maybe this is a bit more straight forward?
> 
> err = drm_dp_i2c_drain_msg(aux, );
> if (err < 0)
>   break;
> transfer_size = err;
>
That and making transfer_size unsigned seems like a good combination. Will
adopt for v4.

-- 
Simon Farnsworth
Software Engineer
ONELAN Ltd
http://www.onelan.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150129/ecf4d954/attachment.sig>

[PATCH v2] drm/tegra: Add tegra_gem_mmap2 to fix 64-bit offsets

[Sean Paul]

On 64-bit targets, tegra_gem_mmap doesn't return the
offset to userspace. As such, subsequent calls to mmap(2)
fail. Add a new tegra_gem_mmap2 ioctl to fix this.

Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/tegra/drm.c  | 21 +
 include/uapi/drm/tegra_drm.h |  9 +
 2 files changed, 30 insertions(+)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index d4f8275..be5dbe7 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -343,6 +343,26 @@ static int tegra_gem_create(struct drm_device *drm, void 
*data,
return 0;
 }

+static int tegra_gem_mmap2(struct drm_device *drm, void *data,
+ struct drm_file *file)
+{
+   struct drm_tegra_gem_mmap2 *args = data;
+   struct drm_gem_object *gem;
+   struct tegra_bo *bo;
+
+   gem = drm_gem_object_lookup(drm, file, args->handle);
+   if (!gem)
+   return -EINVAL;
+
+   bo = to_tegra_bo(gem);
+
+   args->offset = drm_vma_node_offset_addr(>gem.vma_node);
+
+   drm_gem_object_unreference(gem);
+
+   return 0;
+}
+
 static int tegra_gem_mmap(struct drm_device *drm, void *data,
  struct drm_file *file)
 {
@@ -677,6 +697,7 @@ static const struct drm_ioctl_desc tegra_drm_ioctls[] = {
DRM_IOCTL_DEF_DRV(TEGRA_GEM_GET_TILING, tegra_gem_get_tiling, 
DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(TEGRA_GEM_SET_FLAGS, tegra_gem_set_flags, 
DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(TEGRA_GEM_GET_FLAGS, tegra_gem_get_flags, 
DRM_UNLOCKED),
+   DRM_IOCTL_DEF_DRV(TEGRA_GEM_MMAP2, tegra_gem_mmap2, DRM_UNLOCKED),
 #endif
 };

diff --git a/include/uapi/drm/tegra_drm.h b/include/uapi/drm/tegra_drm.h
index c15d781..9057b0f 100644
--- a/include/uapi/drm/tegra_drm.h
+++ b/include/uapi/drm/tegra_drm.h
@@ -167,6 +167,13 @@ struct drm_tegra_gem_get_flags {
__u32 flags;
 };

+struct drm_tegra_gem_mmap2 {
+   __u32 handle;
+   __u32 pad;
+   __u64 offset;
+};
+
+
 #define DRM_TEGRA_GEM_CREATE   0x00
 #define DRM_TEGRA_GEM_MMAP 0x01
 #define DRM_TEGRA_SYNCPT_READ  0x02
@@ -181,6 +188,7 @@ struct drm_tegra_gem_get_flags {
 #define DRM_TEGRA_GEM_GET_TILING   0x0b
 #define DRM_TEGRA_GEM_SET_FLAGS0x0c
 #define DRM_TEGRA_GEM_GET_FLAGS0x0d
+#define DRM_TEGRA_GEM_MMAP20x0e

 #define DRM_IOCTL_TEGRA_GEM_CREATE DRM_IOWR(DRM_COMMAND_BASE + 
DRM_TEGRA_GEM_CREATE, struct drm_tegra_gem_create)
 #define DRM_IOCTL_TEGRA_GEM_MMAP DRM_IOWR(DRM_COMMAND_BASE + 
DRM_TEGRA_GEM_MMAP, struct drm_tegra_gem_mmap)
@@ -196,5 +204,6 @@ struct drm_tegra_gem_get_flags {
 #define DRM_IOCTL_TEGRA_GEM_GET_TILING DRM_IOWR(DRM_COMMAND_BASE + 
DRM_TEGRA_GEM_GET_TILING, struct drm_tegra_gem_get_tiling)
 #define DRM_IOCTL_TEGRA_GEM_SET_FLAGS DRM_IOWR(DRM_COMMAND_BASE + 
DRM_TEGRA_GEM_SET_FLAGS, struct drm_tegra_gem_set_flags)
 #define DRM_IOCTL_TEGRA_GEM_GET_FLAGS DRM_IOWR(DRM_COMMAND_BASE + 
DRM_TEGRA_GEM_GET_FLAGS, struct drm_tegra_gem_get_flags)
+#define DRM_IOCTL_TEGRA_GEM_MMAP2 DRM_IOWR(DRM_COMMAND_BASE + 
DRM_TEGRA_GEM_MMAP2, struct drm_tegra_gem_mmap2)

 #endif
-- 
2.2.0.rc0.207.ga3a616c

[PATCH] vt_buffer: drop console buffer copying optimisations

[Dave Airlie]

These two copy to/from VGA memory, however on the Silicon
Motion SMI750 VGA card on a 64-bit system cause console corruption.

This is due to the hw being buggy and not handling a 64-bit transaction
correctly.

We could try and create a 32-bit version of these routines,
but I'm not sure the optimisation is worth much today.

Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1132826

Tested-by: Huawei engineering.
Signed-off-by: Dave Airlie 
---

Linus, this came up a while back I finally got some confirmation
that it fixes those servers.

 include/linux/vt_buffer.h | 4 
 1 file changed, 4 deletions(-)

diff --git a/include/linux/vt_buffer.h b/include/linux/vt_buffer.h
index 057db7d..f38c10b 100644
--- a/include/linux/vt_buffer.h
+++ b/include/linux/vt_buffer.h
@@ -21,10 +21,6 @@
 #ifndef VT_BUF_HAVE_RW
 #define scr_writew(val, addr) (*(addr) = (val))
 #define scr_readw(addr) (*(addr))
-#define scr_memcpyw(d, s, c) memcpy(d, s, c)
-#define scr_memmovew(d, s, c) memmove(d, s, c)
-#define VT_BUF_HAVE_MEMCPYW
-#define VT_BUF_HAVE_MEMMOVEW
 #endif

 #ifndef VT_BUF_HAVE_MEMSETW
-- 
1.9.3


--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
--
___
Dri-devel mailing list
Dri-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Bug 88758] Low FPS in settings on Dota2

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

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

--- Comment #14 from smoki  ---
(In reply to Lorenzo Bona from comment #1)
> Created attachment 112735 [details]
> mesa-build script

 I mean in this mesa build script of course to add -mtune, while using recent
kernel

-- 
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/20150129/22da7161/attachment.html>

[Bug 73338] Fan speed in idle at 40% with radeonsi and at 18% with catalyst

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

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

--- Comment #80 from Henrik Asp  ---
I'm testing commits
"add common fan control asic callbacks"
"bind fan control on SI cards to hwmon interface"
"bind fan control on CI cards to hwmon interface (v2)"
"bind fan control on CI cards to hwmon interface (v2)"
"enable smc fan control on SI"
from the repo agd5f on top of 3.19-rc6 with the fancontrol script from
lm_sensors.

I had to edit the script somewhat, since it expects a write of 1 to pwm1_enable
and a write of 255 to pwm1 to not fail (the write to pwm1 fail since the script
expects pwm1_max to be 255).

The driver should probably follow the behaviour userspace expects.

-- 
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/20150129/28a140af/attachment.html>

[PATCH] drm/tegra: Add tegra_gem_mmap2 to fix 64-bit offsets

[Rob Clark]

On Thu, Jan 29, 2015 at 1:46 PM, Sean Paul  wrote:
>
> diff --git a/include/uapi/drm/tegra_drm.h b/include/uapi/drm/tegra_drm.h
> index c15d781..9035257 100644
> --- a/include/uapi/drm/tegra_drm.h
> +++ b/include/uapi/drm/tegra_drm.h
> @@ -167,6 +167,12 @@ struct drm_tegra_gem_get_flags {
> __u32 flags;
>  };
>
> +struct drm_tegra_gem_mmap2 {
> +   __u32 handle;

__u32 pad;

> +   __u64 offset;
> +};
> +

BR,
-R

[Bug 88758] Low FPS in settings on Dota2

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

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

--- Comment #13 from smoki  ---

 This looks to me like another "32bit toolchain caused stutter" like in bug
83436

 Lorenzo, can you try how it goes if you add in your script also '-mtune' to
both CFLAGS and CXXFLAGS ?

-- 
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/20150129/1a47ca3a/attachment.html>

[PATCH] drm/radeon: don't init gpuvm if accel is disabled

[Deucher, Alexander]

> -Original Message-
> From: Gabbay, Oded
> Sent: Thursday, January 29, 2015 2:46 AM
> To: Alex Deucher; dri-devel at lists.freedesktop.org
> Cc: Deucher, Alexander; stable at vger.kernel.org
> Subject: Re: [PATCH] drm/radeon: don't init gpuvm if accel is disabled
> 
> 
> 
> On 01/28/2015 09:41 PM, Alex Deucher wrote:
> > If acceleration is disabled, it does not make sense
> > to init gpuvm since nothing will use it.  Moreover,
> > if radeon_vm_init() gets called it uses accel to try
> > and clear the pde tables, etc. which results in a bug.
> >
> > Bug:
> > https://bugs.freedesktop.org/show_bug.cgi?id=88786
> >
> > Signed-off-by: Alex Deucher
> > Cc:stable at vger.kernel.org
> Alex,
> What is accel ?

If the ring tests fail and for some reason the IPs (e.g., gfx or sdma) are not 
available, the driver disables acceleration and basically falls back to 
modesetting only.

> Is there a situation where accel is disabled and HSA should work ? e.g.
> headless
> mode ?

No.  We only disable acceleration if we can't get the IPs (gfx, sdma) 
initialized.  Headless has nothing to do with acceleration in this context.

Alex

[RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms

[Rob Clark]

On Thu, Jan 29, 2015 at 10:47 AM, Russell King - ARM Linux
 wrote:
> On Thu, Jan 29, 2015 at 09:00:11PM +0530, Sumit Semwal wrote:
>> So, short answer is, it is left to the exporter to decide. The dma-buf
>> framework should not even attempt to decide or enforce any of the
>> above.
>>
>> At each dma_buf_attach(), there's a callback to the exporter, where
>> the exporter can decide, if it intends to handle these kind of cases,
>> on the best way forward.
>>
>> The exporter might, for example, decide to migrate backing storage,
>
> That's a decision which the exporter can not take.  Think about it...
>
> If subsystem Y has mapped the buffer, it could be accessing the buffer's
> backing storage at the same time that subsystem Z tries to attach to the
> buffer.

The *theory* is that Y is map/unmap'ing the buffer around each use, so
there will be some point where things could be migrated and remapped..
in practice, I am not sure that anyone is doing this yet.

Probably it would be reasonable if a more restrictive subsystem tried
to attach after the buffer was already allocated and mapped in a way
that don't meet the new constraints, then -EBUSY.

But from a quick look it seems like there needs to be a slight fixup
to not return 0 if calc_constraints() fails..

> Once the buffer has been exported to another user, the exporter has
> effectively lost control over mediating accesses to that buffer.
>
> All that it can do with the way the dma-buf API is today is to allocate
> a _different_ scatter list pointing at the same backing storage which
> satisfies the segment size and number of segments, etc.
>
> There's also another issue which you haven't addressed.  What if several
> attachments result in lowering max_segment_size and max_segment_count
> such that:
>
> max_segment_size * max_segment_count < dmabuf->size
>
> but individually, the attachments allow dmabuf->size to be represented
> as a scatterlist?

Quite possibly for some of these edge some of cases, some of the
dma-buf exporters are going to need to get more clever (ie. hand off
different scatterlists to different clients).  Although I think by far
the two common cases will be "I can support anything via an iommu/mmu"
and "I need phys contig".

But that isn't an issue w/ dma-buf itself, so much as it is an issue
w/ drivers.  I guess there would be more interest in fixing up drivers
when actual hw comes along that needs it..

BR,
-R

> If an exporter were to take notice of the max_segment_size and
> max_segment_count, the resulting buffer is basically unrepresentable
> as a scatterlist.
>
>> > Please consider the possible sequences of use (such as the scenario
>> > above) when creating or augmenting an API.
>> >
>>
>> I tried to think of the scenarios I could think of, but If you still
>> feel this approach doesn't help with your concerns, I'll graciously
>> accept advice to improve it.
>
> See the new one above :)
>
> --
> FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
> according to speedtest.net.

[PATCH] drm/tegra: Add tegra_gem_mmap2 to fix 64-bit offsets

[Sean Paul]

On 64-bit targets, tegra_gem_mmap doesn't return the
offset to userspace. As such, subsequent calls to mmap(2)
fail. Add a new tegra_gem_mmap2 ioctl to fix this.

Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/tegra/drm.c  | 21 +
 include/uapi/drm/tegra_drm.h |  8 
 2 files changed, 29 insertions(+)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index d4f8275..be5dbe7 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -343,6 +343,26 @@ static int tegra_gem_create(struct drm_device *drm, void 
*data,
return 0;
 }

+static int tegra_gem_mmap2(struct drm_device *drm, void *data,
+ struct drm_file *file)
+{
+   struct drm_tegra_gem_mmap2 *args = data;
+   struct drm_gem_object *gem;
+   struct tegra_bo *bo;
+
+   gem = drm_gem_object_lookup(drm, file, args->handle);
+   if (!gem)
+   return -EINVAL;
+
+   bo = to_tegra_bo(gem);
+
+   args->offset = drm_vma_node_offset_addr(>gem.vma_node);
+
+   drm_gem_object_unreference(gem);
+
+   return 0;
+}
+
 static int tegra_gem_mmap(struct drm_device *drm, void *data,
  struct drm_file *file)
 {
@@ -677,6 +697,7 @@ static const struct drm_ioctl_desc tegra_drm_ioctls[] = {
DRM_IOCTL_DEF_DRV(TEGRA_GEM_GET_TILING, tegra_gem_get_tiling, 
DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(TEGRA_GEM_SET_FLAGS, tegra_gem_set_flags, 
DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(TEGRA_GEM_GET_FLAGS, tegra_gem_get_flags, 
DRM_UNLOCKED),
+   DRM_IOCTL_DEF_DRV(TEGRA_GEM_MMAP2, tegra_gem_mmap2, DRM_UNLOCKED),
 #endif
 };

diff --git a/include/uapi/drm/tegra_drm.h b/include/uapi/drm/tegra_drm.h
index c15d781..9035257 100644
--- a/include/uapi/drm/tegra_drm.h
+++ b/include/uapi/drm/tegra_drm.h
@@ -167,6 +167,12 @@ struct drm_tegra_gem_get_flags {
__u32 flags;
 };

+struct drm_tegra_gem_mmap2 {
+   __u32 handle;
+   __u64 offset;
+};
+
+
 #define DRM_TEGRA_GEM_CREATE   0x00
 #define DRM_TEGRA_GEM_MMAP 0x01
 #define DRM_TEGRA_SYNCPT_READ  0x02
@@ -181,6 +187,7 @@ struct drm_tegra_gem_get_flags {
 #define DRM_TEGRA_GEM_GET_TILING   0x0b
 #define DRM_TEGRA_GEM_SET_FLAGS0x0c
 #define DRM_TEGRA_GEM_GET_FLAGS0x0d
+#define DRM_TEGRA_GEM_MMAP20x0e

 #define DRM_IOCTL_TEGRA_GEM_CREATE DRM_IOWR(DRM_COMMAND_BASE + 
DRM_TEGRA_GEM_CREATE, struct drm_tegra_gem_create)
 #define DRM_IOCTL_TEGRA_GEM_MMAP DRM_IOWR(DRM_COMMAND_BASE + 
DRM_TEGRA_GEM_MMAP, struct drm_tegra_gem_mmap)
@@ -196,5 +203,6 @@ struct drm_tegra_gem_get_flags {
 #define DRM_IOCTL_TEGRA_GEM_GET_TILING DRM_IOWR(DRM_COMMAND_BASE + 
DRM_TEGRA_GEM_GET_TILING, struct drm_tegra_gem_get_tiling)
 #define DRM_IOCTL_TEGRA_GEM_SET_FLAGS DRM_IOWR(DRM_COMMAND_BASE + 
DRM_TEGRA_GEM_SET_FLAGS, struct drm_tegra_gem_set_flags)
 #define DRM_IOCTL_TEGRA_GEM_GET_FLAGS DRM_IOWR(DRM_COMMAND_BASE + 
DRM_TEGRA_GEM_GET_FLAGS, struct drm_tegra_gem_get_flags)
+#define DRM_IOCTL_TEGRA_GEM_MMAP2 DRM_IOWR(DRM_COMMAND_BASE + 
DRM_TEGRA_GEM_MMAP2, struct drm_tegra_gem_mmap2)

 #endif
-- 
2.2.0.rc0.207.ga3a616c

[Bug 90741] Radeon: System pauses on TAHITI

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

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

--- Comment #33 from Gustaw Smolarczyk  ---
Created attachment 165161
  --> https://bugzilla.kernel.org/attachment.cgi?id=165161=edit
dmesg after disabling radeon_fence_schedule_check()

I chose to leave the refcount printing patch as it is.

The pauses now are much much longer (~10-20s).

The 2h time difference in the messages log is due to local time not being set
correctly and ntp-client daemon fixing it after some time.

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

[Bug 90741] Radeon: System pauses on TAHITI

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

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

--- Comment #32 from Maarten Lankhorst  ---
You can keep print refcounts or remove it, it doesn't matter much either way. I
just want to have at least 'another approach' applied.

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

[Bug 91861] [Radeon RS780] Blank screen (no signal) on HDMI after boot in 3.15 & later

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

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

--- Comment #7 from Christian König  ---
(In reply to Mike S. from comment #6)
> I can confirm that the patch
> https://bugzilla.kernel.org/attachment.cgi?id=163891 to cap ref_div to 7
> fixes the problem on my RS780. I did the test on kernel 3.18.3. Note that I
> also cast the number 7 in the min() to unsigned to avoid a compiler warning.

Thanks for testing.

> I'd also like to ask a question, please. With this patch, the GPU divider
> values are now running at:
> 
> 148500 - 148490, pll dividers - fb: 580.7 ref: 7, post 8
> 
> while on 3.14 they were:
> 
> 14851, pll dividers - fb: 145.2 ref: 2, post: 7
> 
> These new values produce a marginally different dot clock rate (the old
> debug msg displayed the value 10x less than the new one), but the difference
> is tiny, and probably doesn't make any practical difference.

It does make quite a difference, that's why I've added the new code in the
first place. Some people had problems with the old one resulting in unstable
signals and audio/video desync after a while.

> Other than the dot clock, do the values of the 3 dividers affect anything
> else in the GPU? Are there any advantages or disadvantages running the FB
> and REF substantially higher (as they are now)?
When you use higher dividers in a PLL you can get closer to the desired
frequency, but at the cost of higher jitter. The trick is to stay within the
limits of the PLL. For example the VCO shouldn't get to fast otherwise the
input voltage gets to high, the feedback divider shouldn't get to high cause
otherwise the jitter is to high for the PLL to follow etc...

We most likely have an undocumented limit on the input frequency here,
otherwise limiting the reference divider won't have such an effect.

Christian.

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

[PATCH] RFC: drm: add support for tiled/compressed/etc modifier in addfb2 (v1.5)

[Daniel Vetter]

On Thu, Jan 29, 2015 at 11:43:07AM +, Tvrtko Ursulin wrote:
> 
> On 01/29/2015 11:30 AM, Daniel Vetter wrote:
> >On Wed, Jan 28, 2015 at 05:57:56PM +, Tvrtko Ursulin wrote:
> >>
> >>On 01/28/2015 05:37 PM, Daniel Vetter wrote:
> >>>From: Rob Clark 
> >>>
> >>>In DRM/KMS we are lacking a good way to deal with tiled/compressed
> >>>formats.  Especially in the case of dmabuf/prime buffer sharing, where
> >>>we cannot always rely on under-the-hood flags passed to driver specific
> >>>gem-create ioctl to pass around these extra flags.
> >>>
> >>>The proposal is to add a per-plane format modifier.  This allows to, if
> >>>necessary, use different tiling patters for sub-sampled planes, etc.
> >>>The format modifiers are added at the end of the ioctl struct, so for
> >>>legacy userspace it will be zero padded.
> >>>
> >>>TODO how best to deal with assignment of modifier token values?  The
> >>>rough idea was to namespace things with an 8bit vendor-id, and then
> >>>beyond that it is treated as an opaque value.  But that was a relatively
> >>>arbitrary choice.  There are cases where same tiling pattern and/or
> >>>compression is supported by various different vendors.  So we should
> >>>standardize to use the vendor-id and value of the first one who
> >>>documents the format?
> >>
> >>Maybe:
> >>__u64 modifier[4];
> >>__u64 vendor_modifier[4];
> >
> >Seems rendundant since the modifier added in this patch is already vendor
> >specific. Or what exactly are you trying to accomplish here?
> 
> I am trying to avoid packet-in-a-packet (bitmasks) mumbo-jumbo and vendor id
> on the head followed by maybe standardized or maybe vendor specific tag.
> Feels funny. Would it not be simpler to put a struct in there?

The u64 modifier is just an opaque thing, with 8 bit to identifier the
vendor (for easier number management really) and the low 56 bits can be
whatever we want them. On i915 I think we should just enumerate all the
various tiling modes we have. And if the modifiers aren't set we use the
tiling mode of the underlying gem bo. We already have code in place to
guarantee that the underlying bo's tiling can't change as long as there's
a kms fb around, which means all code which checks for tiling can switch
over to these flags.

struct won't work since by definition this is vendor-specific, and every
vendor is slightly insane in a different way.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH] RFC: drm: add support for tiled/compressed/etc modifier in addfb2 (v1.5)

[Tvrtko Ursulin]

On 01/29/2015 11:57 AM, Daniel Vetter wrote:
> On Thu, Jan 29, 2015 at 11:43:07AM +, Tvrtko Ursulin wrote:
>>
>> On 01/29/2015 11:30 AM, Daniel Vetter wrote:
>>> On Wed, Jan 28, 2015 at 05:57:56PM +, Tvrtko Ursulin wrote:

 On 01/28/2015 05:37 PM, Daniel Vetter wrote:
> From: Rob Clark 
>
> In DRM/KMS we are lacking a good way to deal with tiled/compressed
> formats.  Especially in the case of dmabuf/prime buffer sharing, where
> we cannot always rely on under-the-hood flags passed to driver specific
> gem-create ioctl to pass around these extra flags.
>
> The proposal is to add a per-plane format modifier.  This allows to, if
> necessary, use different tiling patters for sub-sampled planes, etc.
> The format modifiers are added at the end of the ioctl struct, so for
> legacy userspace it will be zero padded.
>
> TODO how best to deal with assignment of modifier token values?  The
> rough idea was to namespace things with an 8bit vendor-id, and then
> beyond that it is treated as an opaque value.  But that was a relatively
> arbitrary choice.  There are cases where same tiling pattern and/or
> compression is supported by various different vendors.  So we should
> standardize to use the vendor-id and value of the first one who
> documents the format?

 Maybe:
__u64 modifier[4];
__u64 vendor_modifier[4];
>>>
>>> Seems rendundant since the modifier added in this patch is already vendor
>>> specific. Or what exactly are you trying to accomplish here?
>>
>> I am trying to avoid packet-in-a-packet (bitmasks) mumbo-jumbo and vendor id
>> on the head followed by maybe standardized or maybe vendor specific tag.
>> Feels funny. Would it not be simpler to put a struct in there?
>
> The u64 modifier is just an opaque thing, with 8 bit to identifier the
> vendor (for easier number management really) and the low 56 bits can be
> whatever we want them. On i915 I think we should just enumerate all the
> various tiling modes we have. And if the modifiers aren't set we use the
> tiling mode of the underlying gem bo. We already have code in place to
> guarantee that the underlying bo's tiling can't change as long as there's
> a kms fb around, which means all code which checks for tiling can switch
> over to these flags.
>
> struct won't work since by definition this is vendor-specific, and every
> vendor is slightly insane in a different way.

Well 8 + 56 bits is a "struct" already and not fully opaque. Are the 
bits expensive? :) That was first part of my point.

Secondly, "vendor who registers first" part of discussion is what came 
to my attention as well.

With this, a hypothetical standard format would be under a vendor id 
which looks funny to me. While you could split standard 
formats/modifiers and vendor specific modifiers.

I don't care really, it was just an idea, but I don't get this arguments 
why it is, not only not better, but worse than a bitfield. :)

Regards,

Tvrtko

[PATCH] drm/irq: Don't disable vblank interrupts when already disabled

[Daniel Vetter]

On Thu, Jan 29, 2015 at 12:15:03PM +0900, Michel Dänzer wrote:
> On 29.01.2015 08:09, Laurent Pinchart wrote:
> > The .enable_vblank() operation is only called when vblank interrupts are
> > disabled, but no similar check exists when disabling vblank interrupts.
> > This leads to .disable_vblank() being called with vblank interrupts
> > already disabled and the device possibly runtime suspended. As the
> > operation is called with a spinlock held drivers can't runtime resume
> > the device there and thus must avoid touching device registers in that
> > case, requiring vblank refcounting.
> > 
> > As the DRM core tracks whether vblank interrupts are enabled just skip
> > the .disable_vblank() call when the interrupts are already disabled.
> > 
> > Signed-off-by: Laurent Pinchart 
> 
> Reviewed-by: Michel Dänzer 

Yeah makes sense, pulled into my drm misc pile.

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

[PATCH] drm: use kvfree instead of opencoding

[Dave Airlie]

From: Dave Airlie 

Al Viro added this to the mm finally, so instead
of opencoding it use kvfree instead.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/nouveau/nouveau_gem.c | 5 +
 include/drm/drm_mem_util.h| 5 +
 2 files changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c 
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index 7c077fc..7270649 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -552,10 +552,7 @@ nouveau_gem_pushbuf_validate(struct nouveau_channel *chan,
 static inline void
 u_free(void *addr)
 {
-   if (!is_vmalloc_addr(addr))
-   kfree(addr);
-   else
-   vfree(addr);
+   kvfree(addr);
 }

 static inline void *
diff --git a/include/drm/drm_mem_util.h b/include/drm/drm_mem_util.h
index 19a2404..e42495a 100644
--- a/include/drm/drm_mem_util.h
+++ b/include/drm/drm_mem_util.h
@@ -56,10 +56,7 @@ static __inline__ void *drm_malloc_ab(size_t nmemb, size_t 
size)

 static __inline void drm_free_large(void *ptr)
 {
-   if (!is_vmalloc_addr(ptr))
-   return kfree(ptr);
-
-   vfree(ptr);
+   kvfree(ptr);
 }

 #endif
-- 
1.9.3

[Bug 90741] Radeon: System pauses on TAHITI

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

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

--- Comment #31 from Gustaw Smolarczyk  ---
Do you mean on top of the latest patch?

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

[PATCH] RFC: drm: add support for tiled/compressed/etc modifier in addfb2 (v1.5)

[Daniel Vetter]

On Wed, Jan 28, 2015 at 05:57:56PM +, Tvrtko Ursulin wrote:
> 
> On 01/28/2015 05:37 PM, Daniel Vetter wrote:
> >From: Rob Clark 
> >
> >In DRM/KMS we are lacking a good way to deal with tiled/compressed
> >formats.  Especially in the case of dmabuf/prime buffer sharing, where
> >we cannot always rely on under-the-hood flags passed to driver specific
> >gem-create ioctl to pass around these extra flags.
> >
> >The proposal is to add a per-plane format modifier.  This allows to, if
> >necessary, use different tiling patters for sub-sampled planes, etc.
> >The format modifiers are added at the end of the ioctl struct, so for
> >legacy userspace it will be zero padded.
> >
> >TODO how best to deal with assignment of modifier token values?  The
> >rough idea was to namespace things with an 8bit vendor-id, and then
> >beyond that it is treated as an opaque value.  But that was a relatively
> >arbitrary choice.  There are cases where same tiling pattern and/or
> >compression is supported by various different vendors.  So we should
> >standardize to use the vendor-id and value of the first one who
> >documents the format?
> 
> Maybe:
>   __u64 modifier[4];
>   __u64 vendor_modifier[4];

Seems rendundant since the modifier added in this patch is already vendor
specific. Or what exactly are you trying to accomplish here?
-Daniel

> 
> ?
> 
> Regards,
> 
> Tvrtko

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

[PATCH] RFC: drm: add support for tiled/compressed/etc modifier in addfb2 (v1.5)

[Daniel Vetter]

On Wed, Jan 28, 2015 at 01:46:53PM -0500, Rob Clark wrote:
> On Wed, Jan 28, 2015 at 12:37 PM, Daniel Vetter  
> wrote:
> > From: Rob Clark 
> >
> > In DRM/KMS we are lacking a good way to deal with tiled/compressed
> > formats.  Especially in the case of dmabuf/prime buffer sharing, where
> > we cannot always rely on under-the-hood flags passed to driver specific
> > gem-create ioctl to pass around these extra flags.
> >
> > The proposal is to add a per-plane format modifier.  This allows to, if
> > necessary, use different tiling patters for sub-sampled planes, etc.
> > The format modifiers are added at the end of the ioctl struct, so for
> > legacy userspace it will be zero padded.
> >
> > TODO how best to deal with assignment of modifier token values?  The
> > rough idea was to namespace things with an 8bit vendor-id, and then
> > beyond that it is treated as an opaque value.  But that was a relatively
> > arbitrary choice.  There are cases where same tiling pattern and/or
> > compression is supported by various different vendors.  So we should
> > standardize to use the vendor-id and value of the first one who
> > documents the format?
> 
> iirc, I think we decided that drm_fourcc.h in drm-next is a sufficient
> authority for coordinating assignment of modifier token values, so we
> could probably drop this TODO.  Perhaps it wouldn't hurt to document
> somewhere that, as with fourcc/format values, new additions are
> expected to come with some description of the format?

Oh right forgotten to drop the TODO. I'll add a comment to the header
file.
> 
> >
> > v1: original
> > v1.5: increase modifier to 64b
> >
> > v2: Incorporate review comments from the big thread, plus a few more.
> >
> > - Add a getcap so that userspace doesn't have to jump through hoops.
> > - Allow modifiers only when a flag is set. That way drivers know when
> >   they're dealing with old userspace and need to fish out e.g. tiling
> >   from other information.
> > - After rolling out checks for ->modifier to all drivers I've decided
> >   that this is way too fragile and needs an explicit opt-in flag. So
> >   do that instead.
> > - Add a define (just for documentation really) for the "NONE"
> >   modifier. Imo we don't need to add mask #defines since drivers
> >   really should only do exact matches against values defined with
> >   fourcc_mod_code.
> > - Drop the Samsung tiling modifier on Rob's request since he's not yet
> >   sure whether that one is accurate.
> >
> > Cc: Rob Clark 
> > Cc: Tvrtko Ursulin 
> > Cc: Laurent Pinchart 
> > Cc: Daniel Stone 
> > Cc: Ville Syrjälä 
> > Cc: Michel Dänzer 
> > Signed-off-by: Rob Clark  (v1.5)
> > Signed-off-by: Daniel Vetter 
> >
> 
> you forgot to change subject line to (v2).. but other than that, looks good

Ah, I generally don't keep a patch revision in the subject and forgot to
update it ;-)

> 
> Reviewed-by: Rob Clark 
> 
> > --
> >
> > I've picked this up since we want to push out some fancy new tiling
> > modes soonish. No defines yet, but Tvrkto is working on the i915 parts
> > of this.
> >
> > I think the only part I haven't done from the discussion is exposing a
> > list of supported modifiers. Not sure that's really useful though
> > since all this is highly hw specific.
> >
> > And a note to driver writes: They need to check or the flag and in its
> > absence make a reasonable choice about the internal layet (e.g. for
> > i915 consult the tiling mode of the underlying bo).
> > -Daniel
> > ---
> >  drivers/gpu/drm/drm_crtc.c| 14 +-
> >  drivers/gpu/drm/drm_ioctl.c   |  3 +++
> >  include/drm/drm_crtc.h|  3 +++
> >  include/uapi/drm/drm.h|  1 +
> >  include/uapi/drm/drm_fourcc.h | 26 ++
> >  include/uapi/drm/drm_mode.h   |  9 +
> >  6 files changed, 55 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > index 419f9d915c78..8090e3d64f67 100644
> > --- a/drivers/gpu/drm/drm_crtc.c
> > +++ b/drivers/gpu/drm/drm_crtc.c
> > @@ -3324,6 +3324,12 @@ static int framebuffer_check(const struct 
> > drm_mode_fb_cmd2 *r)
> > DRM_DEBUG_KMS("bad pitch %u for plane %d\n", 
> > r->pitches[i], i);
> > return -EINVAL;
> > }
> > +
> > +   if (r->modifier[i] && !(r->flags & DRM_MODE_FB_MODIFIERS)) {
> > +   DRM_DEBUG_KMS("bad fb modifier %llu for plane %d\n",
> > + r->modifier[i], i);
> > +   return -EINVAL;
> > +   }
> > }
> >
> > return 0;
> > @@ -3337,7 +3343,7 @@ static struct drm_framebuffer 
> > *add_framebuffer_internal(struct drm_device *dev,
> > struct drm_framebuffer *fb;
> > int ret;
> >
> > -   if (r->flags & ~DRM_MODE_FB_INTERLACED) {
> > +   if (r->flags & ~(DRM_MODE_FB_INTERLACED | DRM_MODE_FB_MODIFIERS)) {
> > DRM_DEBUG_KMS("bad framebuffer 

[PATCH V9 04/14] drm/bridge: ptn3460: Convert to i2c driver model

[Gustavo Padovan]

Hi Ajay,

2015-01-20 Ajay Kumar :

> Use drm_bridge helpers to modify the driver to support
> i2c driver model.
> 
> Signed-off-by: Ajay Kumar 
> Acked-by: Inki Dae 
> Tested-by: Rahul Sharma 
> Tested-by: Javier Martinez Canillas 
> Tested-by: Gustavo Padovan 
> Tested-by: Sjoerd Simons 
> ---
>  drivers/gpu/drm/bridge/Kconfig  |2 +
>  drivers/gpu/drm/bridge/ptn3460.c|  124 
> +--
>  drivers/gpu/drm/exynos/exynos_dp_core.c |   22 --
>  3 files changed, 86 insertions(+), 62 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 884923f..4254c2b 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -1,5 +1,7 @@
>  config DRM_PTN3460
>   tristate "PTN3460 DP/LVDS bridge"
>   depends on DRM
> + depends on OF && I2C

Adding I2C here is causing this circular dependency:

scripts/kconfig/conf --silentoldconfig Kconfig
drivers/video/fbdev/Kconfig:5:error: recursive dependency detected!
drivers/video/fbdev/Kconfig:5:  symbol FB is selected by DRM_KMS_FB_HELPER
drivers/gpu/drm/Kconfig:34: symbol DRM_KMS_FB_HELPER depends on
DRM_KMS_HELPER
drivers/gpu/drm/Kconfig:28: symbol DRM_KMS_HELPER is selected by
DRM_PTN3460
drivers/gpu/drm/bridge/Kconfig:1:   symbol DRM_PTN3460 depends on I2C
drivers/i2c/Kconfig:7:  symbol I2C is selected by FB_DDC
drivers/video/fbdev/Kconfig:59: symbol FB_DDC is selected by FB_CYBER2000_DDC
drivers/video/fbdev/Kconfig:374:symbol FB_CYBER2000_DDC depends on
FB_CYBER2000
drivers/video/fbdev/Kconfig:362:symbol FB_CYBER2000 depends on FB

To solve this we just need to remove I2C from depends as DRM already selects
I2C. This was already fixed by:


commit 90bde571ad194adb039cb92a11a5b346f15eb610
Author: Arnd Bergmann 
Date:   Tue Mar 25 12:06:46 2014 +0100

drm/bridge: PTN3460 needs DRM_KMS_HELPER

The recently added PTN3460 device driver uses interfaces that
are provided by the KMS helper infrastructure, so we should
explicitly select that to avoid this linker error:

ERROR: "drm_helper_probe_single_connector_modes" 
[drivers/gpu/drm/bridge/ptn3460.ko] undefined!
ERROR: "drm_helper_connector_dpms" [drivers/gpu/drm/bridge/ptn3460.ko] 
undefined!

We have to drop the I2C dependency to avoid a circular dependency
chain, but that's ok because DRM already selects I2C.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Dave Airlie 


But you may have introduced it again on a rebase. The following patch fixes it:

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 990b4b2..946d1ef 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -1,7 +1,6 @@
 config DRM_PTN3460
tristate "PTN3460 DP/LVDS bridge"
-   depends on DRM
-   depends on OF && I2C
+   depends on DRM && OF
select DRM_KMS_HELPER
select DRM_PANEL
---help---


Gustavo

[Bug 90741] Radeon: System pauses on TAHITI

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

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

--- Comment #30 from Maarten Lankhorst  ---
Can you empty the contents of the radeon_fence_schedule_check function in
radeon_fence.c?

It should make the pauses worse, giving me a chance to find them in the log.
:-)

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

[PATCH] drm/bridge: dw_hdmi: Return the real error on drm_bridge_attach() failure

[Philipp Zabel]

Am Donnerstag, den 29.01.2015, 08:48 -0200 schrieb Fabio Estevam:
> From: Fabio Estevam 
> 
> drm_bridge_attach() may return different errors on failure, not just -EINVAL, 
> so
> it is better to propagate the real error instead.
> 
> Signed-off-by: Fabio Estevam 

Acked-by: Philipp Zabel 

> ---
>  drivers/gpu/drm/bridge/dw_hdmi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c 
> b/drivers/gpu/drm/bridge/dw_hdmi.c
> index cd6a706..fcae66a 100644
> --- a/drivers/gpu/drm/bridge/dw_hdmi.c
> +++ b/drivers/gpu/drm/bridge/dw_hdmi.c
> @@ -1528,7 +1528,7 @@ static int dw_hdmi_register(struct drm_device *drm, 
> struct dw_hdmi *hdmi)
>   ret = drm_bridge_attach(drm, bridge);
>   if (ret) {
>   DRM_ERROR("Failed to initialize bridge with drm\n");
> - return -EINVAL;
> + return ret;
>   }
>  
>   encoder->bridge = bridge;

[Bug 88717] [r300g] r300compiler error: Failed to translate rgb instruction - while running a game with gallium-nine

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

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

--- Comment #7 from Fabio Pedretti  ---
Created attachment 112937
  --> https://bugs.freedesktop.org/attachment.cgi?id=112937=edit
"RADEON_DEBUG=fp,vp,pstat sauerbraten -lforce" output WITH patch -> b/n
textures

-- 
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/20150129/757fad0b/attachment.html>

[PATCH] drm/irq: Don't disable vblank interrupts when already disabled

[Michel Dänzer]

On 29.01.2015 08:09, Laurent Pinchart wrote:
> The .enable_vblank() operation is only called when vblank interrupts are
> disabled, but no similar check exists when disabling vblank interrupts.
> This leads to .disable_vblank() being called with vblank interrupts
> already disabled and the device possibly runtime suspended. As the
> operation is called with a spinlock held drivers can't runtime resume
> the device there and thus must avoid touching device registers in that
> case, requiring vblank refcounting.
> 
> As the DRM core tracks whether vblank interrupts are enabled just skip
> the .disable_vblank() call when the interrupts are already disabled.
> 
> Signed-off-by: Laurent Pinchart 

Reviewed-by: Michel Dänzer 


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

[Bug 88717] [r300g] r300compiler error: Failed to translate rgb instruction - while running a game with gallium-nine

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

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

--- Comment #6 from Fabio Pedretti  ---
Created attachment 112936
  --> https://bugs.freedesktop.org/attachment.cgi?id=112936=edit
"RADEON_DEBUG=fp,vp,pstat sauerbraten -lforce" output

(In reply to Tom Stellard from comment #5)
> Can you send me before/after dumps of RADEON_DEBUG=fs,vs,ps from one of the
> regressed games?

I tried it with "RADEON_DEBUG=fp,vp,pstat" since "fs,vs,ps" apparently are not
available. I tried running "sauerbraten -lforce" which shows black/white
textures.

Note: it looks the output changes between consecutive runs, although there are
not many possibilities (an output repeat after some runs). I attach the outputs
before and after the patch that should hopefully match to the same game
combination.

-- 
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/20150129/d4b9420a/attachment.html>

[Bug 90741] Radeon: System pauses on TAHITI

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

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

--- Comment #29 from Maarten Lankhorst  ---
Thanks, that rules out 1 possibility. There is probably no bug in refcounting
irqs. :P

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

[PATCH] drm: use kvfree instead of opencoding

[Michel Dänzer]

On 29.01.2015 11:36, Dave Airlie wrote:
> From: Dave Airlie 
> 
> Al Viro added this to the mm finally, so instead
> of opencoding it use kvfree instead.
> 
> Signed-off-by: Dave Airlie 
> ---
>  drivers/gpu/drm/nouveau/nouveau_gem.c | 5 +
>  include/drm/drm_mem_util.h| 5 +
>  2 files changed, 2 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c 
> b/drivers/gpu/drm/nouveau/nouveau_gem.c
> index 7c077fc..7270649 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_gem.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
> @@ -552,10 +552,7 @@ nouveau_gem_pushbuf_validate(struct nouveau_channel 
> *chan,
>  static inline void
>  u_free(void *addr)
>  {
> - if (!is_vmalloc_addr(addr))
> - kfree(addr);
> - else
> - vfree(addr);
> + kvfree(addr);
>  }
>  
>  static inline void *
> diff --git a/include/drm/drm_mem_util.h b/include/drm/drm_mem_util.h
> index 19a2404..e42495a 100644
> --- a/include/drm/drm_mem_util.h
> +++ b/include/drm/drm_mem_util.h
> @@ -56,10 +56,7 @@ static __inline__ void *drm_malloc_ab(size_t nmemb, size_t 
> size)
>  
>  static __inline void drm_free_large(void *ptr)
>  {
> - if (!is_vmalloc_addr(ptr))
> - return kfree(ptr);
> -
> - vfree(ptr);
> + kvfree(ptr);
>  }
>  
>  #endif
> 

Any reason for keeping the u_free and drm_free_large wrappers?


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

conflicts in amdkfd between -next and -fixes

[Dave Airlie]

Hey Oded,

so I pulled -fixes into -next this morning and made amdkfd build
again, it had a few conflicts in it,

I've pushed a drm-next branch with the conflicts resolved and amdkfd
that builds, the only one I'm a bit scared on was the size calculation
fixup for the removal of the max processes.

can you please look at the drm-next and see if it breaks anything.

Dave.

[PATCH] RFC: drm: add support for tiled/compressed/etc modifier in addfb2 (v1.5)

[Tvrtko Ursulin]

On 01/29/2015 11:30 AM, Daniel Vetter wrote:
> On Wed, Jan 28, 2015 at 05:57:56PM +, Tvrtko Ursulin wrote:
>>
>> On 01/28/2015 05:37 PM, Daniel Vetter wrote:
>>> From: Rob Clark 
>>>
>>> In DRM/KMS we are lacking a good way to deal with tiled/compressed
>>> formats.  Especially in the case of dmabuf/prime buffer sharing, where
>>> we cannot always rely on under-the-hood flags passed to driver specific
>>> gem-create ioctl to pass around these extra flags.
>>>
>>> The proposal is to add a per-plane format modifier.  This allows to, if
>>> necessary, use different tiling patters for sub-sampled planes, etc.
>>> The format modifiers are added at the end of the ioctl struct, so for
>>> legacy userspace it will be zero padded.
>>>
>>> TODO how best to deal with assignment of modifier token values?  The
>>> rough idea was to namespace things with an 8bit vendor-id, and then
>>> beyond that it is treated as an opaque value.  But that was a relatively
>>> arbitrary choice.  There are cases where same tiling pattern and/or
>>> compression is supported by various different vendors.  So we should
>>> standardize to use the vendor-id and value of the first one who
>>> documents the format?
>>
>> Maybe:
>>  __u64 modifier[4];
>>  __u64 vendor_modifier[4];
>
> Seems rendundant since the modifier added in this patch is already vendor
> specific. Or what exactly are you trying to accomplish here?

I am trying to avoid packet-in-a-packet (bitmasks) mumbo-jumbo and 
vendor id on the head followed by maybe standardized or maybe vendor 
specific tag. Feels funny. Would it not be simpler to put a struct in there?

But I was not following this from the start so maybe I am missing 
something..

Regards,

Tvrtko

[PATCH] drm/radeon: don't init gpuvm if accel is disabled

[Christian König]

Am 29.01.2015 um 08:46 schrieb Oded Gabbay:
>
>
> On 01/28/2015 09:41 PM, Alex Deucher wrote:
>> If acceleration is disabled, it does not make sense
>> to init gpuvm since nothing will use it.  Moreover,
>> if radeon_vm_init() gets called it uses accel to try
>> and clear the pde tables, etc. which results in a bug.
>>
>> Bug:
>> https://bugs.freedesktop.org/show_bug.cgi?id=88786
>>
>> Signed-off-by: Alex Deucher
>> Cc:stable at vger.kernel.org

Patch is Reviewed-by: Christian König 

> Alex,
> What is accel ?
> Is there a situation where accel is disabled and HSA should work ? 
> e.g. headless mode ?

Not really.

Acceleration is disabled mostly because the user forgotten to install 
the firmware or we have a rather big bug in the driver and can't get the 
CP running.

In that case we still try to provide mode setting to get an error 
message on the screen, but everything else won't work.

Regards,
Christian.


>
> If so, we need gpuvm for local memory.
>
> Oded
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 88758] Low FPS in settings on Dota2

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

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

--- Comment #12 from Lorenzo Bona  ---
Created attachment 112935
  --> https://bugs.freedesktop.org/attachment.cgi?id=112935=edit
git_complete_bisect.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/20150129/835daf25/attachment.html>

[Bug 88758] Low FPS in settings on Dota2

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

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

--- Comment #11 from Lorenzo Bona  ---
(In reply to Michel Dänzer from comment #10)
> (In reply to Lorenzo Bona from comment #8)
> > git_bisect.log
> 
> That looks way too short to be the final result. Keep going until git bisect
> tells you which commit is the first bad one.

Sorry for the delay. Here the git bisect result:

$git bisect bad
02376d8282b88f07d0716da6155094c8760b1a13 is the first bad commit
commit 02376d8282b88f07d0716da6155094c8760b1a13
Author: Michel Dänzer 
Date:   Thu Jul 17 19:01:08 2014 +0900

drm/radeon: Allow write-combined CPU mappings of BOs in GTT (v2)

v2: fix rebase onto drm-fixes

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

:04 04 369d9e0ff185b6e6c9614de87296fc60072f56b9
d9fb7256264156abdaf238cd0e6f0925d7e54ac7 M  drivers

Attached the complete git bisect 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/20150129/b16be879/attachment.html>

[PATCH 2/2] drm/amdkfd: Preserve CP_MQD_IQ_RPTR internal state

[Oded Gabbay]

From: Jay Cornwall 

CP microcode uses undocumented bits in this register to record queue
state information. The KFD zeroes these bits in update_mqd, when invoked
through the UPDATE_QUEUE ioctl, causing incoherent state when the ioctl
is used to successively unmap and map a queue.

Since the queue type cannot be changed in this path, move the MQD write
to init_mqd.

Signed-off-by: Jay Cornwall 
Reviewed-by: Ben Goz 
Signed-off-by: Oded Gabbay 
---
 drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_cik.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_cik.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_cik.c
index a318743..a09e18a 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_cik.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_cik.c
@@ -94,6 +94,9 @@ static int init_mqd(struct mqd_manager *mm, void **mqd,
m->cp_hqd_pipe_priority = 1;
m->cp_hqd_queue_priority = 15;

+   if (q->format == KFD_QUEUE_FORMAT_AQL)
+   m->cp_hqd_iq_rptr = AQL_ENABLE;
+
*mqd = m;
if (gart_addr != NULL)
*gart_addr = addr;
@@ -187,7 +190,6 @@ static int update_mqd(struct mqd_manager *mm, void *mqd,
m->cp_hqd_vmid = q->vmid;

if (q->format == KFD_QUEUE_FORMAT_AQL) {
-   m->cp_hqd_iq_rptr = AQL_ENABLE;
m->cp_hqd_pq_control |= NO_UPDATE_RPTR;
}

-- 
1.9.1

[PATCH 1/2] drm/amdkfd: Fix dqm->queue_count tracking

[Oded Gabbay]

From: Jay Cornwall 

dqm->queue_count tracks queues in the active state only. In a few
places this count is modified unconditionally, leading to an incorrect
value when the UPDATE_QUEUE ioctl is used to make a queue inactive.

Signed-off-by: Jay Cornwall 
Reviewed-by: Ben Goz 
Signed-off-by: Oded Gabbay 
---
 drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
index ecc78ec..36b95e1 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
@@ -167,7 +167,8 @@ static int create_queue_nocpsch(struct device_queue_manager 
*dqm,
}

list_add(>list, >queues_list);
-   dqm->queue_count++;
+   if (q->properties.is_active)
+   dqm->queue_count++;

if (q->properties.type == KFD_QUEUE_TYPE_SDMA)
dqm->sdma_queue_count++;
@@ -313,7 +314,8 @@ static int destroy_queue_nocpsch(struct 
device_queue_manager *dqm,
list_del(>list);
if (list_empty(>queues_list))
deallocate_vmid(dqm, qpd, q);
-   dqm->queue_count--;
+   if (q->properties.is_active)
+   dqm->queue_count--;

/*
 * Unconditionally decrement this counter, regardless of the queue's
@@ -1018,7 +1020,8 @@ static int destroy_queue_cpsch(struct 
device_queue_manager *dqm,
dqm->sdma_queue_count--;

list_del(>list);
-   dqm->queue_count--;
+   if (q->properties.is_active)
+   dqm->queue_count--;

execute_queues_cpsch(dqm, false);

-- 
1.9.1

[PATCH 3/6] libdrm: fix the Android 64bit build

[Stéphane Marchesin]

On Thu, Jan 29, 2015 at 10:47 AM, Emil Velikov  
wrote:
> With 64bit bionic mmap now handles 64bit offset, thus we no longer
> need the __mmap2 trick.
>
> Fix from Chih-Wei Huang, over at the google forums.
>
> Cc: Chih-Wei Huang 
> Signed-off-by: Emil Velikov 
> ---
>  libdrm.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libdrm.h b/libdrm.h
> index acfada5..6c3cd59 100644
> --- a/libdrm.h
> +++ b/libdrm.h
> @@ -45,7 +45,7 @@
>
>  #include 
>
> -#if defined(ANDROID)
> +#if defined(ANDROID) && !defined(__LP64__)
>  #include  /* for EINVAL */
>
>  extern void *__mmap2(void *, size_t, int, int, int, size_t);

It seems like you're be better off just using mmap64 instead of __mpap2?

Stéphane

[PATCH 1/3] drm/amdkfd: Fix bug in accounting of queues

[Alex Deucher]

On Thu, Jan 29, 2015 at 3:35 AM, Oded Gabbay  wrote:
> Signed-off-by: Oded Gabbay 

For the series:

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c 
> b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> index 0d8694f..0fd5927 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> @@ -822,7 +822,7 @@ static void destroy_kernel_queue_cpsch(struct 
> device_queue_manager *dqm,
>  * Unconditionally decrement this counter, regardless of the queue's
>  * type.
>  */
> -   dqm->total_queue_count++;
> +   dqm->total_queue_count--;
> pr_debug("Total of %d queues are accountable so far\n",
> dqm->total_queue_count);
> mutex_unlock(>lock);
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 73378] [drm:radeon_uvd_send_upll_ctlreq] *ERROR* Timeout setting UVD clocks!

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

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

--- Comment #20 from Christian König  ---
(In reply to Chernovsky Oleg from comment #15)
> I can help with code here.
> 
> What should be implemented, roughly?

Sounds good. I assume you got a card with that problem.

First of all try if UVD works otherwise. E.g. we raise the clocks for the boot
up test (and lower them again after that), but that's actually not necessary
most of the time.

So get into radeon_uvd_send_upll_ctlreq, just comment out the error return
value and pretend everything worked fine.

Then check if the following IB test works or not.

If that doesn't work the input clocks to the PLL doesn't seem to work and we
have a clock routing problem or something like that. If that works the PLL just
doesn't likes our parameters and we need to figure out why.

Feel free to contact me by mail if you have more questions.

Thanks,
Christian.

-- 
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/20150129/88111f02/attachment.html>

[PULL] drm-intel-fixes

[Jani Nikula]

Hi Dave -

i915 fixes all around, mostly cc: stable.

Was surprised to see your pull request already on Tuesday, are you
planning on doing another one before -rc7?


BR,
Jani.

The following changes since commit 26bc420b59a38e4e6685a73345a0def461136dce:

  Linux 3.19-rc6 (2015-01-25 20:04:41 -0800)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2015-01-29

for you to fetch changes up to 6b96d705f3cf435b0b8835b12c9742513c77fed6:

  drm/i915: BDW Fix Halo PCI IDs marked as ULT. (2015-01-26 11:00:34 +0200)


Bob Paauwe (1):
  drm/i915: Only fence tiled region of object.

David Woodhouse (1):
  drm/i915: Init PPGTT before context enable

Jeremiah Mahler (1):
  drm/i915: fix inconsistent brightness after resume

Rodrigo Vivi (2):
  drm/i915: Fix and clean BDW PCH identification
  drm/i915: BDW Fix Halo PCI IDs marked as ULT.

 drivers/gpu/drm/i915/i915_drv.c| 14 --
 drivers/gpu/drm/i915/i915_drv.h|  3 +--
 drivers/gpu/drm/i915/i915_gem.c| 26 +-
 drivers/gpu/drm/i915/intel_panel.c |  2 +-
 4 files changed, 19 insertions(+), 26 deletions(-)

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH 3/3] drm/amdkfd: Don't create BUG due to incorrect user parameter

[Oded Gabbay]

This patch changes a BUG_ON() statement to pr_debug, in case the user tries to
update a non-existing queue.

Signed-off-by: Oded Gabbay 
Reviewed-by: Ben Goz 
---
 drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c
index f37cf5e..2fda1927 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c
@@ -315,7 +315,11 @@ int pqm_update_queue(struct process_queue_manager *pqm, 
unsigned int qid,
BUG_ON(!pqm);

pqn = get_queue_by_qid(pqm, qid);
-   BUG_ON(!pqn);
+   if (!pqn) {
+   pr_debug("amdkfd: No queue %d exists for update operation\n",
+   qid);
+   return -EFAULT;
+   }

pqn->q->properties.queue_address = p->queue_address;
pqn->q->properties.queue_size = p->queue_size;
-- 
1.9.1

[PATCH 2/3] drm/amdkfd: max num of queues can't be 0

[Oded Gabbay]

Signed-off-by: Oded Gabbay 
---
 drivers/gpu/drm/amd/amdkfd/kfd_module.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_module.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_module.c
index a8be6df..1c385c2 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_module.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_module.c
@@ -95,10 +95,10 @@ static int __init kfd_module_init(void)
}

/* Verify module parameters */
-   if ((max_num_of_queues_per_device < 0) ||
+   if ((max_num_of_queues_per_device < 1) ||
(max_num_of_queues_per_device >
KFD_MAX_NUM_OF_QUEUES_PER_DEVICE)) {
-   pr_err("kfd: max_num_of_queues_per_device must be between 0 to 
KFD_MAX_NUM_OF_QUEUES_PER_DEVICE\n");
+   pr_err("kfd: max_num_of_queues_per_device must be between 1 to 
KFD_MAX_NUM_OF_QUEUES_PER_DEVICE\n");
return -1;
}

-- 
1.9.1

[PATCH 1/3] drm/amdkfd: Fix bug in accounting of queues

[Oded Gabbay]

Signed-off-by: Oded Gabbay 
---
 drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
index 0d8694f..0fd5927 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
@@ -822,7 +822,7 @@ static void destroy_kernel_queue_cpsch(struct 
device_queue_manager *dqm,
 * Unconditionally decrement this counter, regardless of the queue's
 * type.
 */
-   dqm->total_queue_count++;
+   dqm->total_queue_count--;
pr_debug("Total of %d queues are accountable so far\n",
dqm->total_queue_count);
mutex_unlock(>lock);
-- 
1.9.1

[PATCH] drm/radeon: don't init gpuvm if accel is disabled (v2)

[Alex Deucher]

If acceleration is disabled, it does not make sense
to init gpuvm since nothing will use it.  Moreover,
if radeon_vm_init() gets called it uses accel to try
and clear the pde tables, etc. which results in a bug.

v2: handle vm_fini as well

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

Signed-off-by: Alex Deucher 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/radeon_kms.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
b/drivers/gpu/drm/radeon/radeon_kms.c
index 3cf9c1f..686411e 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -605,14 +605,14 @@ int radeon_driver_open_kms(struct drm_device *dev, struct 
drm_file *file_priv)
return -ENOMEM;
}

-   vm = >vm;
-   r = radeon_vm_init(rdev, vm);
-   if (r) {
-   kfree(fpriv);
-   return r;
-   }
-
if (rdev->accel_working) {
+   vm = >vm;
+   r = radeon_vm_init(rdev, vm);
+   if (r) {
+   kfree(fpriv);
+   return r;
+   }
+
r = radeon_bo_reserve(rdev->ring_tmp_bo.bo, false);
if (r) {
radeon_vm_fini(rdev, vm);
@@ -668,9 +668,9 @@ void radeon_driver_postclose_kms(struct drm_device *dev,
radeon_vm_bo_rmv(rdev, vm->ib_bo_va);
radeon_bo_unreserve(rdev->ring_tmp_bo.bo);
}
+   radeon_vm_fini(rdev, vm);
}

-   radeon_vm_fini(rdev, vm);
kfree(fpriv);
file_priv->driver_priv = NULL;
}
-- 
1.8.3.1

[PATCH] drm/radeon: fix PLLs on RS880 and older v2

[Alex Deucher]

On Thu, Jan 29, 2015 at 10:01 AM, Christian König
 wrote:
> From: Christian König 
>
> This is a workaround for RS880 and older chips which seem to have
> an additional limit on the minimum PLL input frequency.
>
> v2: fix signed/unsigned warning
>
> Signed-off-by: Christian König 

Added to my -fixes queue.

Thanks!

Alex

> ---
>  drivers/gpu/drm/radeon/radeon_display.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
> b/drivers/gpu/drm/radeon/radeon_display.c
> index 1021169..913fafa 100644
> --- a/drivers/gpu/drm/radeon/radeon_display.c
> +++ b/drivers/gpu/drm/radeon/radeon_display.c
> @@ -960,6 +960,9 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll,
> if (pll->flags & RADEON_PLL_USE_FRAC_FB_DIV &&
> pll->flags & RADEON_PLL_USE_REF_DIV)
> ref_div_max = pll->reference_div;
> +   else if (pll->flags & RADEON_PLL_PREFER_MINM_OVER_MAXP)
> +   /* fix for problems on RS880 */
> +   ref_div_max = min(pll->max_ref_div, 7u);
> else
> ref_div_max = pll->max_ref_div;
>
> --
> 1.9.1
>

conflicts in amdkfd between -next and -fixes

[Oded Gabbay]

On 01/29/2015 03:49 AM, Dave Airlie wrote:
> Hey Oded,
>
> so I pulled -fixes into -next this morning and made amdkfd build
> again, it had a few conflicts in it,
>
> I've pushed a drm-next branch with the conflicts resolved and amdkfd
> that builds, the only one I'm a bit scared on was the size calculation
> fixup for the removal of the max processes.
>
> can you please look at the drm-next and see if it breaks anything.
>
> Dave.
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

Hi Dave,
I looked at drm-next and your merge is perfect. thanks!
However, I noticed two minor bugs so this pass on the code was even more 
beneficial :)
I'll send fixes shortly.

Oded

[PATCH] RFC: drm: add support for tiled/compressed/etc modifier in addfb2 (v1.5)

[Rob Clark]

On Thu, Jan 29, 2015 at 7:55 AM, Tvrtko Ursulin
 wrote:
>
> On 01/29/2015 11:57 AM, Daniel Vetter wrote:
>>
>> On Thu, Jan 29, 2015 at 11:43:07AM +, Tvrtko Ursulin wrote:
>>>
>>>
>>> On 01/29/2015 11:30 AM, Daniel Vetter wrote:

 On Wed, Jan 28, 2015 at 05:57:56PM +, Tvrtko Ursulin wrote:
>
>
> On 01/28/2015 05:37 PM, Daniel Vetter wrote:
>>
>> From: Rob Clark 
>>
>> In DRM/KMS we are lacking a good way to deal with tiled/compressed
>> formats.  Especially in the case of dmabuf/prime buffer sharing, where
>> we cannot always rely on under-the-hood flags passed to driver
>> specific
>> gem-create ioctl to pass around these extra flags.
>>
>> The proposal is to add a per-plane format modifier.  This allows to,
>> if
>> necessary, use different tiling patters for sub-sampled planes, etc.
>> The format modifiers are added at the end of the ioctl struct, so for
>> legacy userspace it will be zero padded.
>>
>> TODO how best to deal with assignment of modifier token values?  The
>> rough idea was to namespace things with an 8bit vendor-id, and then
>> beyond that it is treated as an opaque value.  But that was a
>> relatively
>> arbitrary choice.  There are cases where same tiling pattern and/or
>> compression is supported by various different vendors.  So we should
>> standardize to use the vendor-id and value of the first one who
>> documents the format?
>
>
> Maybe:
> __u64 modifier[4];
> __u64 vendor_modifier[4];


 Seems rendundant since the modifier added in this patch is already
 vendor
 specific. Or what exactly are you trying to accomplish here?
>>>
>>>
>>> I am trying to avoid packet-in-a-packet (bitmasks) mumbo-jumbo and vendor
>>> id
>>> on the head followed by maybe standardized or maybe vendor specific tag.
>>> Feels funny. Would it not be simpler to put a struct in there?
>>
>>
>> The u64 modifier is just an opaque thing, with 8 bit to identifier the
>> vendor (for easier number management really) and the low 56 bits can be
>> whatever we want them. On i915 I think we should just enumerate all the
>> various tiling modes we have. And if the modifiers aren't set we use the
>> tiling mode of the underlying gem bo. We already have code in place to
>> guarantee that the underlying bo's tiling can't change as long as there's
>> a kms fb around, which means all code which checks for tiling can switch
>> over to these flags.
>>
>> struct won't work since by definition this is vendor-specific, and every
>> vendor is slightly insane in a different way.
>
>
> Well 8 + 56 bits is a "struct" already and not fully opaque. Are the bits
> expensive? :) That was first part of my point.

tbh, we could decide to do something different from 8+56b later if
needed..  nothing should really *depend* on the 8+56, since it is
intended to be an opaque token.  The 8+56 was just intended to make it
easier to merge values coming from different driver trees with less
conflicts.

> Secondly, "vendor who registers first" part of discussion is what came to my
> attention as well.
>
> With this, a hypothetical standard format would be under a vendor id which
> looks funny to me. While you could split standard formats/modifiers and
> vendor specific modifiers.

maybe we should s/vendor/driver/

> I don't care really, it was just an idea, but I don't get this arguments why
> it is, not only not better, but worse than a bitfield. :)

I guess it gets into bikeshed territory a bit, but I've tried to avoid
giving userspace the temptation to assume it is much more than an
opaque value.  The 8+56 thing was mainly just intended for logistical
convenience ;-)

BR,
-R


> Regards,
>
> Tvrtko