[Bug 91527] 7870 radeon crashes after kernel msg drm:radeon_mn_invalidate_range_start

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

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

--- Comment #2 from JATothrim  ---
Created attachment 117497
  --> https://bugs.freedesktop.org/attachment.cgi?id=117497=edit
dmesg log

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

[Bug 91543] [BONAIRE] ARK: Survival Evolved: corruption with certain textures inside cave (spider web)

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

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

Bug ID: 91543
   Summary: [BONAIRE] ARK: Survival Evolved: corruption with
certain textures inside cave (spider web)
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: shawn.starr at rogers.com
QA Contact: dri-devel at lists.freedesktop.org

Since I bought the game, I've had some very specific corruption inside the
caves in ARK, specifically, when the spiders shoot their web to ensnare you.
The problem is, the spider web sometimes shows up, other times, shows up as
blacked out, or random colored.

apitrace isn't allowing me to capture the frame(s) that show this corruption.

kernel: 4.2.0-0.rc4.git4.2.fc24.x86_64
Mesa: Git master 2015-08-01 build

The apitrace is here:
https://drive.google.com/open?id=0Bze7CJKD12nOdW0waTUweXctSzQ

-- 
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/20150803/89c9903a/attachment-0001.html>

[Bug 91540] slow rendering & fullscreen results in stale images

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

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

--- Comment #2 from Bas Nieuwenhuizen  ---
Created attachment 117494
  --> https://bugs.freedesktop.org/attachment.cgi?id=117494=edit
dmesg

-- 
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/20150803/b994505b/attachment.html>

[Bug 91540] slow rendering & fullscreen results in stale images

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

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

--- Comment #1 from Bas Nieuwenhuizen  ---
Created attachment 117493
  --> https://bugs.freedesktop.org/attachment.cgi?id=117493=edit
Xorg 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/20150803/677027f7/attachment.html>

[Bug 91540] slow rendering & fullscreen results in stale images

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

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

Bug ID: 91540
   Summary: slow rendering & fullscreen results in stale images
   Product: DRI
   Version: XOrg git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: bas at basnieuwenhuizen.nl

Created attachment 117492
  --> https://bugs.freedesktop.org/attachment.cgi?id=117492=edit
example application

With GL applications if the render time is > 1 frame (> 2 for more reliable
triggering) and the window is fullscreen, I have flickering betweeen old and
new frames.

Attached is an example application that if run fullscreen and sufficiently slow
exhibits the problem. The quad is supposed to rotate when you press space, but
the first moments you get some combination of the two rotated quads.

Workarounds include:
 - making the window not fullscreen.
 - use xcompmgr to enable compositing.
 - using vblank_mode=0

Hardware:
Sapphire R9 285 Dual-X OC 2 GB (TONGA)

Software
kernel from adg5f/linux drm-next-4.3-wip commit
88a7d7fa964602514496223639c4e0432fbd457b (also occurs on 4.2-rc4)
drm, mesa from agd5f/... amdgpu branches
xf86-video-amdgpu from master
Xserver 1.17.2

My window manager is XMonad, which is a tiling window manager without
compositing.

The attached Xorg.0.log contains some warnings:
(WW) AMDGPU(0): amdgpu_dri2_flip_event_handler: Pageflip completion event has
impossible msc 189694 < target_msc 189695

However, running the example application or my original application does not
(consistently) generate those warnings when run.

-- 
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/20150803/4429d487/attachment.html>

[Bug 86796] Artifacts on the screen. HD8530M

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

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

nicknnn at gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from nicknnn at gmail.com ---
Thanks, now OGL apps looks good.

-- 
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/20150803/16ed80bc/attachment.html>

[PATCH v2] drm/exynos: clear channels only when iommu is enabled

[Inki Dae]

On 2015년 07월 31일 09:32, Krzysztof Kozlowski wrote:
> On 28.07.2015 17:51, Joonyoung Shim wrote:
>> This is simplest solution about reported problem[1]. It's no problem to
>> clear channel only when iommu is enabled, if we consider that we cannot
>> recognize iommu errors when iommu is disabled and it have been valid
>> until now. But this cannot be nice solution.
>>
>> [1] https://lkml.org/lkml/2015/7/21/404
>>
>> Reported-by: Krzysztof Kozlowski 
>> Signed-off-by: Joonyoung Shim 
> 
> I tested this patch on my Odroid XU3-Lite with hardkernel u-boot and it
> fixes the booting hang. Thanks!

Thanks for the test.

This patch fixes the booting hang issue but I'm not sure of this patch
being able to resolve the issue clearly.

In relation to this, I tried to resolve the issue using sub driver
stuff, which makes a probe callback for fimd sub driver to be called
after crtc and connector binding is completed.

I guessed that with this, ACLK_200_DISP1 would be enabled by connector
driver - mipi dsi or panel driver. However, the moment that the clock is
enabled is at mode setting operation so the patch doesn't resolve the
issue because the callback I added will be called before mode setting
operation.

So the solution we could try would be to make FIMD driver to enable
relevant clock in case of Exynos5422 SoC. However, this way is also not
clear to me because it is required for additional device tree binding.

Anyway, I merged below patch so let's resolve this issue with more
generic way later.

P.s., I removed the patch which incurred the kernel hang issue from
exynos-drm-fixes, and moved it to exynos-drm-next with below patch so
now there must be no any problem with exynos-drm-fixes.

Thanks,
Inki Dae

> 
> The test was not thorough - only booting and without any display output
> (HDMI).
> 
> Best regards,
> Krzysztof
> 
> 
>> ---
>> v2: add Reported-by.
>>
>>  drivers/gpu/drm/exynos/exynos_drm_fimd.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> index 8d362b9..337af02 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> @@ -956,7 +956,8 @@ static int fimd_bind(struct device *dev, struct device 
>> *master, void *data)
>>  if (ctx->display)
>>  exynos_drm_create_enc_conn(drm_dev, ctx->display);
>>  
>> -fimd_clear_channels(ctx->crtc);
>> +if (is_drm_iommu_supported(drm_dev))
>> +fimd_clear_channels(ctx->crtc);
>>  
>>  ret = drm_iommu_attach_device(drm_dev, dev);
>>  if (ret)
>>
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

[PATCH] scripts/kernel-doc Allow struct arguments documentation in struct body

[Daniel Vetter]

On Mon, Aug 03, 2015 at 08:37:41AM -0600, Jonathan Corbet wrote:
> On Mon, 3 Aug 2015 10:23:19 +0200
> Daniel Vetter  wrote:
> 
> > > I'm wondering if we need a kernel summit session on commenting
> > > conventions, markdown-in-kerneldoc, etc?  Maybe I'll stick a proposal out
> > > there.  
> > 
> > Might be useful, but I'm not sure how many people really would actively
> > work on improving the tooling. The only comment I've seen is to maybe use
> > gtkdoc, but that would be a pain since it's slightly incompatible with
> > kerneldoc.
> 
> The idea was to get a sense for what sort of improvements would be
> useful, to begin with.  But my attempt to start a discussion on the
> kernel summit list appears to have hit the ground pretty hard; I guess
> that means I have free rein :)

Wrt feature wishlists the 3 things Danilo has worked on thus far
(hyperlinks, markdown and inline struct member kerneldoc) are really the
things I'd like to have. Of course there's room for some more
prettification, but I think that would better fit as improvements to
pandoc. One example is more flexible table handling with row/column
spanning - currently pandoc doesn't handle that in the docbook converter.

> I expect I'll apply the struct-args doc patch in the fairly near future.
> Then we'll see if others complain when patches using it start to show up,
> but the feature itself shouldn't break anything.  I'm *really* hoping to
> take a hard look at Danilo's stuff for a 4.3 merge as well.  It should be
> possible, but there's real-world obnoxiousness that is doing its best to
> get in the way.

Awesome. Missing 4.3 wouldn't be a big deal for i915 really since drm
feature freeze should happen around -rc5 anyway, so everything new I pull
in will be for 4.4 only. But getting it in early always helps, just in
case there's something unexpected.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[REGRESSION] Re: i915 driver crashes on T540p if docking station attached

[Daniel Vetter]

On Thu, Jul 30, 2015 at 11:50:29AM -0400, Theodore Ts'o wrote:
> On Thu, Jul 30, 2015 at 04:40:02PM +0200, Daniel Vetter wrote:
> > I have 4 patches in git://people.freedesktop.org/~danvet/drm fixes-stuff
> > but I couldn't test them yet since no dp mst here and I didn't find
> > anything that would ship faster than 1-2 weeks yet. I'll try to get some
> > other people here to test it meanwhile too.
> 
> I've tried pulling in your patches from fixes-stuff, onto Linus's tree
> (without Linus's fix), and the good news is that I'm no longer
> crashing on boot.
> 
> The *bad* news is that (a) it breaks the external monitor attached to
> the docking station completely (this was working with Linus's patch),
> and (b) it's triggering a LOCKDEP failure.
> 
> So even though Linus's patch wasn't supposed to work, I think I'm
> going to back to it

Ok I updated fixes-stuff with just 2 patches which seem to be enough to
fix it. Plus a patch to convert Linus' hack into something we can keep
plus a drive-by WARNING fix in mst that got in the way for me.

Seems to work here in getting rid of the Oops. If this tests out for you
too I'll send a pull to Linus.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 4/4] drm/atomic-helpers: Make encoder picking more robust

[Daniel Vetter]

We've had a few issues with atomic where subtle bugs in the encoder
picking logic lead to accidental self-stealing of the encoder,
resulting in a NULL connector_state->crtc in update_connector_routing
and subsequent.

Linus applied some duct-tape for an mst regression in

commit 27667f4744fc5a0f3e50910e78740bac5670d18b
Author: Linus Torvalds 
Date:   Wed Jul 29 22:18:16 2015 -0700

i915: temporary fix for DP MST docking station NULL pointer dereference

But that was incomplete (the code will still oops when debuggin is
enabled) and mangled the state even further. So instead WARN and bail
out as the more future-proof option.

Cc: Theodore Ts'o 
Cc: Linus Torvalds 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_atomic_helper.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 8694ca9beee3..9dcc7280e572 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -234,13 +234,14 @@ update_connector_routing(struct drm_atomic_state *state, 
int conn_idx)
}
}

+   if (WARN_ON(!connector_state->crtc))
+   return -EINVAL;
+
connector_state->best_encoder = new_encoder;
-   if (connector_state->crtc) {
-   idx = drm_crtc_index(connector_state->crtc);
+   idx = drm_crtc_index(connector_state->crtc);

-   crtc_state = state->crtc_states[idx];
-   crtc_state->mode_changed = true;
-   }
+   crtc_state = state->crtc_states[idx];
+   crtc_state->mode_changed = true;

DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] using [ENCODER:%d:%s] on 
[CRTC:%d]\n",
 connector->base.id,
-- 
2.5.0

[PATCH 3/4] drm/dp-mst: Remove debug WARN_ON

[Daniel Vetter]

Apparently been in there since forever and fairly easy to hit when
hotplugging really fast. I can do that since my mst hub has a manual
button to flick the hpd line for reprobing. The resulting WARNING spam
isn't pretty.

Cc: Dave Airlie 
Cc: stable at vger.kernel.org
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 778bbb6425b8..b0487c9f018c 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1294,7 +1294,6 @@ retry:
goto retry;
}
DRM_DEBUG_KMS("failed to dpcd write %d %d\n", tosend, 
ret);
-   WARN(1, "fail\n");

return -EIO;
}
-- 
2.5.0

[PATCH 2/4] drm/i915: Fixup dp mst encoder selection

[Daniel Vetter]

In

commit 8c7b5ccb729870e606321b3703e2c2e698c49a95
Author: Ander Conselvan de Oliveira 
Date:   Tue Apr 21 17:13:19 2015 +0300

drm/i915: Use atomic helpers for computing changed flags

we've switched over to the atomic version to compute the
crtc->encoder->connector routing from the i915 variant. That one
relies upon the ->best_encoder callback, but the i915-private version
relied upon intel_find_encoder. Which didn't matter except for dp mst,
where the encoder depends upon the selected crtc.

Fix this functional bug by implemented a correct atomic-state based
encoder selector for dp mst.

Note that we can't get rid of the legacy best_encoder callback since
the fbdev emulation uses that still. That means it's incorrect there
still, but that's been the case ever since i915 dp mst support was
merged so not a regression. Best to fix that by converting fbdev over
to atomic too.

Cc: Chris Wilson 
Cc: Linus Torvalds 
Cc: Theodore Ts'o 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_dp_mst.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
b/drivers/gpu/drm/i915/intel_dp_mst.c
index 6e4cc5334f47..600afdbef8c9 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -357,6 +357,16 @@ intel_dp_mst_mode_valid(struct drm_connector *connector,
return MODE_OK;
 }

+static struct drm_encoder *intel_mst_atomic_best_encoder(struct drm_connector 
*connector,
+struct 
drm_connector_state *state)
+{
+   struct intel_connector *intel_connector = to_intel_connector(connector);
+   struct intel_dp *intel_dp = intel_connector->mst_port;
+   struct intel_crtc *crtc = to_intel_crtc(state->crtc);
+
+   return _dp->mst_encoders[crtc->pipe]->base.base;
+}
+
 static struct drm_encoder *intel_mst_best_encoder(struct drm_connector 
*connector)
 {
struct intel_connector *intel_connector = to_intel_connector(connector);
@@ -367,6 +377,7 @@ static struct drm_encoder *intel_mst_best_encoder(struct 
drm_connector *connecto
 static const struct drm_connector_helper_funcs 
intel_dp_mst_connector_helper_funcs = {
.get_modes = intel_dp_mst_get_modes,
.mode_valid = intel_dp_mst_mode_valid,
+   .atomic_best_encoder = intel_mst_atomic_best_encoder,
.best_encoder = intel_mst_best_encoder,
 };

-- 
2.5.0

[PATCH 1/4] drm/atomic-helper: Add an atomice best_encoder callback

[Daniel Vetter]

With legacy helpers all the routing was already set up when calling
best_encoder and so could be inspected. But with atomic it's staged,
hence we need a new atomic compliant callback for drivers which need
to inspect the requested state and can't just decided the best encoder
statically.

This is needed to fix up i915 dp mst where we need to pick the right
encoder depending upon the requested CRTC for the connector.

v2: Don't forget to amend the kerneldoc

Cc: Chris Wilson 
Cc: Linus Torvalds 
Cc: Theodore Ts'o 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_atomic_helper.c | 7 ++-
 include/drm/drm_crtc_helper.h   | 3 +++
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index aac212297b49..8694ca9beee3 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -196,7 +196,12 @@ update_connector_routing(struct drm_atomic_state *state, 
int conn_idx)
}

funcs = connector->helper_private;
-   new_encoder = funcs->best_encoder(connector);
+
+   if (funcs->atomic_best_encoder)
+   new_encoder = funcs->atomic_best_encoder(connector,
+connector_state);
+   else
+   new_encoder = funcs->best_encoder(connector);

if (!new_encoder) {
DRM_DEBUG_ATOMIC("No suitable encoder found for 
[CONNECTOR:%d:%s]\n",
diff --git a/include/drm/drm_crtc_helper.h b/include/drm/drm_crtc_helper.h
index c8fc187061de..918aa68b5199 100644
--- a/include/drm/drm_crtc_helper.h
+++ b/include/drm/drm_crtc_helper.h
@@ -168,6 +168,7 @@ struct drm_encoder_helper_funcs {
  * @get_modes: get mode list for this connector
  * @mode_valid: is this mode valid on the given connector? (optional)
  * @best_encoder: return the preferred encoder for this connector
+ * @atomic_best_encoder: atomic version of @best_encoder
  *
  * The helper operations are called by the mid-layer CRTC helper.
  */
@@ -176,6 +177,8 @@ struct drm_connector_helper_funcs {
enum drm_mode_status (*mode_valid)(struct drm_connector *connector,
   struct drm_display_mode *mode);
struct drm_encoder *(*best_encoder)(struct drm_connector *connector);
+   struct drm_encoder *(*atomic_best_encoder)(struct drm_connector 
*connector,
+  struct drm_connector_state 
*connector_state);
 };

 extern void drm_helper_disable_unused_functions(struct drm_device *dev);
-- 
2.5.0

[PATCH v2] drm/i915: load driver even if debugfs fails

[Sudip Mukherjee]

On Mon, Aug 03, 2015 at 12:54:33PM +0200, Daniel Vetter wrote:
> On Mon, Aug 03, 2015 at 02:56:42PM +0530, Sudip Mukherjee wrote:
> > On Thu, Jul 23, 2015 at 07:36:12PM +0530, Sudip Mukherjee wrote:
> > > debugfs files are not necessary for the usual operation of the driver
> > > and the device. No need to check for the return values from the debugfs
> > > file creation. Even if one debugfs file fails to create we try with the
> > > next debugfs file and ultimately return success always so that the
> > > driver continues to load.
> 
> Does this even happen?
realistically - I don't think it can happen. Even if it happens then
there will be more serious problem like memory crunch or filesystem
problem and in those cases there is no point in continuing to load the
driver.

regards
sudip

[PATCH v3 1/9] drm/exynos: pass the correct pipe number

[Inki Dae]

Hi Gustavo,

For 1 through 9 merged. And I guess you have the rest we have to review
but this patch series doesn't have consistency of previous, v2.

So please, post the rest again re-basing on top of exynos-drm-next.

Thanks,
Inki Dae

On 2015년 07월 30일 05:11, Gustavo Padovan wrote:
> Hi Inki,
> 
> Any comments about this series?
> 
> Thanks,
>   
>   Gustavo
> 
> 2015-07-16 Gustavo Padovan :
> 
>> From: Gustavo Padovan 
>>
>> Instead of giving -1 to as arg to  drm_send_vblank_event() pass the
>> correct pipe number to it.
>>
>> Signed-off-by: Gustavo Padovan 
>> Reviewed-by: Joonyoung Shim 
>> ---
>>  drivers/gpu/drm/exynos/exynos_drm_crtc.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>> index 644b4b7..22b9ca0 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>> @@ -203,7 +203,7 @@ void exynos_drm_crtc_finish_pageflip(struct drm_device 
>> *dev, int pipe)
>>  spin_lock_irqsave(>event_lock, flags);
>>  if (exynos_crtc->event) {
>>  
>> -drm_send_vblank_event(dev, -1, exynos_crtc->event);
>> +drm_send_vblank_event(dev, pipe, exynos_crtc->event);
>>  drm_vblank_put(dev, pipe);
>>  wake_up(_crtc->pending_flip_queue);
>>  
>> -- 
>> 2.1.0
>>
> 

[Bug 91509] Depth render buffer corruption

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

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

--- Comment #7 from Roland Scheidegger  ---
(In reply to Michel Dänzer from comment #6)
> FWIW, the (micro-)tile size is always 8x8. With macro-tiling (called 2D
> tiling with current GPUs) enabled, the pitch (and height, for calculating
> the memory allocation size) must usually be aligned to a macro-tile
> boundary. Not sure offhand how to calculate the macro-tile size on those old
> GPUs though.

I'm not sure if micro/macro-tiling really apply to r200 depth tiled buffers,
the pattern is quite different to color tiling.

Actually the docs say for rv200:
DEPTHOFFSET: "...128 bit aligned address. When tiling the offset must be
tile-aligned (2KB)"
DEPTHPITCH:"Pitch is specified in multiples of 8 pixels. When tiling the pitch
must be tile-aligned"

And for R200:
DEPTHOFFSET: "Z Buffer Offset must be aligned to 4KB"
DEPTHPITCH: "Pitch is specified in multiples of 32 pixels"

So, in r200, depthoffset wording takes into account that it is always tiled,
however depth pitch doesn't mention it at all, making it sound like no specific
alignment due to tiling would be required. Of course I don't know how true that
really is, in particular for z16 it seems it cannot be true (because the
formula in the driver for tiling only uses (pitch >> 7) both for z16 and z32).
Even if those 128bytes there would be sufficient you're probably quite right
that we're also missing height alignment adjustment (if we'd use 128 bytes for
width and 32 alignment for height that would give us the 4KB aligned blocks
overall too).
Oh, and based on the doc wording clearly the depth pitch would be wrongly
aligned on r100 too (even though based on the formula the driver uses (pitch >>
6) it looks like it could work).

-- 
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/20150803/d15705cb/attachment.html>

[PATCH 11/11] drm/exynos: remove struct exynos_drm_encoder layer

[Gustavo Padovan]

From: Gustavo Padovan 

struct exynos_drm_encoder was justing wrapping struct drm_encoder, it had
only a drm_encoder member and the internal exynos_drm_encoders ops that
was directly mapped to the drm_encoder helper funcs.

So now exynos DRM uses struct drm_encoder directly, this removes
completely the struct exynos_drm_encoder.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/Makefile |   7 +-
 drivers/gpu/drm/exynos/exynos7_drm_decon.c  |   2 +-
 drivers/gpu/drm/exynos/exynos_dp_core.c |  68 --
 drivers/gpu/drm/exynos/exynos_dp_core.h |   2 +-
 drivers/gpu/drm/exynos/exynos_drm_core.c|   1 -
 drivers/gpu/drm/exynos/exynos_drm_crtc.c|   1 -
 drivers/gpu/drm/exynos/exynos_drm_dpi.c |  51 --
 drivers/gpu/drm/exynos/exynos_drm_drv.c |   1 -
 drivers/gpu/drm/exynos/exynos_drm_drv.h |  47 ++---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c |  80 +++--
 drivers/gpu/drm/exynos/exynos_drm_encoder.c | 105 
 drivers/gpu/drm/exynos/exynos_drm_encoder.h |  22 --
 drivers/gpu/drm/exynos/exynos_drm_fimd.c|   2 +-
 drivers/gpu/drm/exynos/exynos_drm_vidi.c|  71 ++-
 drivers/gpu/drm/exynos/exynos_hdmi.c|  85 +-
 15 files changed, 236 insertions(+), 309 deletions(-)
 delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_encoder.c
 delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_encoder.h

diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index 7de0b10..61c2906 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -3,10 +3,9 @@
 # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.

 ccflags-y := -Iinclude/drm -Idrivers/gpu/drm/exynos
-exynosdrm-y := exynos_drm_drv.o exynos_drm_encoder.o \
-   exynos_drm_crtc.o exynos_drm_fbdev.o exynos_drm_fb.o \
-   exynos_drm_buf.o exynos_drm_gem.o exynos_drm_core.o \
-   exynos_drm_plane.o exynos_drm_dmabuf.o
+exynosdrm-y := exynos_drm_drv.o exynos_drm_crtc.o exynos_drm_fbdev.o \
+   exynos_drm_fb.o exynos_drm_buf.o exynos_drm_gem.o \
+   exynos_drm_core.o exynos_drm_plane.o exynos_drm_dmabuf.o

 exynosdrm-$(CONFIG_DRM_EXYNOS_IOMMU) += exynos_drm_iommu.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_FIMD)+= exynos_drm_fimd.o
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index e1a2ce7..0792654 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -61,7 +61,7 @@ struct decon_context {
atomic_twait_vsync_event;

struct exynos_drm_panel_info panel;
-   struct exynos_drm_encoder *encoder;
+   struct drm_encoder *encoder;
 };

 static const struct of_device_id decon_driver_dt_match[] = {
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index a4a902a..19ed422 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -32,18 +32,18 @@
 #include 

 #include "exynos_dp_core.h"
-#include "exynos_drm_encoder.h"
+#include "exynos_drm_crtc.h"

 #define ctx_from_connector(c)  container_of(c, struct exynos_dp_device, \
connector)

 static inline struct exynos_drm_crtc *dp_to_crtc(struct exynos_dp_device *dp)
 {
-   return to_exynos_crtc(dp->encoder.base.crtc);
+   return to_exynos_crtc(dp->encoder.crtc);
 }

 static inline struct exynos_dp_device *encoder_to_dp(
-   struct exynos_drm_encoder *e)
+   struct drm_encoder *e)
 {
return container_of(e, struct exynos_dp_device, encoder);
 }
@@ -889,7 +889,7 @@ static void exynos_dp_hotplug(struct work_struct *work)
drm_helper_hpd_irq_event(dp->drm_dev);
 }

-static void exynos_dp_commit(struct exynos_drm_encoder *encoder)
+static void exynos_dp_commit(struct drm_encoder *encoder)
 {
struct exynos_dp_device *dp = encoder_to_dp(encoder);
int ret;
@@ -995,7 +995,7 @@ static struct drm_encoder *exynos_dp_best_encoder(
 {
struct exynos_dp_device *dp = ctx_from_connector(connector);

-   return >encoder.base;
+   return >encoder;
 }

 static struct drm_connector_helper_funcs exynos_dp_connector_helper_funcs = {
@@ -1020,10 +1020,9 @@ static int exynos_drm_attach_lcd_bridge(struct 
exynos_dp_device *dp,
return 0;
 }

-static int exynos_dp_create_connector(struct exynos_drm_encoder 
*exynos_encoder)
+static int exynos_dp_create_connector(struct drm_encoder *encoder)
 {
-   struct exynos_dp_device *dp = encoder_to_dp(exynos_encoder);
-   struct drm_encoder *encoder = _encoder->base;
+   struct exynos_dp_device *dp = encoder_to_dp(encoder);
struct drm_connector 

[PATCH 10/11] drm/exynos: fold encoder setup into exynos_drm_load()

[Gustavo Padovan]

From: Gustavo Padovan 

As we are removing the exynos encoder move the encoder setup operation
directly inside the exynos_drm_load()

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c | 12 ++--
 drivers/gpu/drm/exynos/exynos_drm_encoder.c | 13 -
 drivers/gpu/drm/exynos/exynos_drm_encoder.h |  1 -
 3 files changed, 10 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index f1d6966..105f10e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -41,7 +41,9 @@
 static int exynos_drm_load(struct drm_device *dev, unsigned long flags)
 {
struct exynos_drm_private *private;
-   int ret;
+   struct drm_encoder *encoder;
+   unsigned int clone_mask;
+   int cnt, ret;

private = kzalloc(sizeof(struct exynos_drm_private), GFP_KERNEL);
if (!private)
@@ -67,7 +69,13 @@ static int exynos_drm_load(struct drm_device *dev, unsigned 
long flags)
exynos_drm_mode_config_init(dev);

/* setup possible_clones. */
-   exynos_drm_encoder_setup(dev);
+   cnt = 0;
+   clone_mask = 0;
+   list_for_each_entry(encoder, >mode_config.encoder_list, head)
+   clone_mask |= (1 << (cnt++));
+
+   list_for_each_entry(encoder, >mode_config.encoder_list, head)
+   encoder->possible_clones = clone_mask;

platform_set_drvdata(dev->platformdev, dev);

diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c 
b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
index 4ed360b..d45a5c5 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
@@ -78,19 +78,6 @@ static struct drm_encoder_funcs exynos_encoder_funcs = {
.destroy = drm_encoder_cleanup,
 };

-void exynos_drm_encoder_setup(struct drm_device *dev)
-{
-   struct drm_encoder *encoder;
-   unsigned int clone_mask = 0;
-   int cnt = 0;
-
-   list_for_each_entry(encoder, >mode_config.encoder_list, head)
-   clone_mask |= (1 << (cnt++));
-
-   list_for_each_entry(encoder, >mode_config.encoder_list, head)
-   encoder->possible_clones = clone_mask;
-}
-
 int exynos_drm_encoder_create(struct drm_device *dev,
  struct exynos_drm_encoder *exynos_encoder,
  enum exynos_drm_output_type type)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.h 
b/drivers/gpu/drm/exynos/exynos_drm_encoder.h
index e998b82..6610dee 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_encoder.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.h
@@ -16,7 +16,6 @@

 #include "exynos_drm_drv.h"

-void exynos_drm_encoder_setup(struct drm_device *dev);
 int exynos_drm_encoder_create(struct drm_device *dev, struct exynos_drm_encoder
  *encoder, enum exynos_drm_output_type type);

-- 
2.1.0

[PATCH 09/11] drm/exynos: remove exynos_drm_create_enc_conn()

[Gustavo Padovan]

From: Gustavo Padovan 

This functions was just hiding the encoder and connector creation in
a way that was less clean than if we get rid of it. For example,
exynos_encoder ops had .create_connector() defined only because we were
handing off the encoder and connector creation to
exynos_drm_create_enc_conn(). Without this function we can directly call
the create_connector function internally in the code, without the need of
any vtable access.

It also does some refactoring in the code like creating a bind function
for dpi devices.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos7_drm_decon.c  |  3 +--
 drivers/gpu/drm/exynos/exynos_dp_core.c | 20 ---
 drivers/gpu/drm/exynos/exynos_drm_core.c| 30 -
 drivers/gpu/drm/exynos/exynos_drm_dpi.c | 26 +++--
 drivers/gpu/drm/exynos/exynos_drm_drv.h | 12 ++--
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 20 ---
 drivers/gpu/drm/exynos/exynos_drm_encoder.c | 11 +++
 drivers/gpu/drm/exynos/exynos_drm_encoder.h |  4 +++-
 drivers/gpu/drm/exynos/exynos_drm_fimd.c|  3 +--
 drivers/gpu/drm/exynos/exynos_drm_vidi.c| 20 ++-
 drivers/gpu/drm/exynos/exynos_hdmi.c| 21 +---
 11 files changed, 101 insertions(+), 69 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 1b89e94..e1a2ce7 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -682,8 +682,7 @@ static int decon_bind(struct device *dev, struct device 
*master, void *data)
}

if (ctx->encoder)
-   exynos_drm_create_enc_conn(drm_dev, ctx->encoder,
-  EXYNOS_DISPLAY_TYPE_LCD);
+   exynos_dpi_bind(drm_dev, ctx->encoder);

return 0;

diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 253f955..a4a902a 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -32,6 +32,7 @@
 #include 

 #include "exynos_dp_core.h"
+#include "exynos_drm_encoder.h"

 #define ctx_from_connector(c)  container_of(c, struct exynos_dp_device, \
connector)
@@ -1104,7 +1105,6 @@ static void exynos_dp_disable(struct exynos_drm_encoder 
*encoder)
 }

 static struct exynos_drm_encoder_ops exynos_dp_encoder_ops = {
-   .create_connector = exynos_dp_create_connector,
.enable = exynos_dp_enable,
.disable = exynos_dp_disable,
 };
@@ -1185,6 +1185,7 @@ static int exynos_dp_bind(struct device *dev, struct 
device *master, void *data)
struct exynos_dp_device *dp = dev_get_drvdata(dev);
struct platform_device *pdev = to_platform_device(dev);
struct drm_device *drm_dev = data;
+   struct exynos_drm_encoder *exynos_encoder = >encoder;
struct resource *res;
unsigned int irq_flags;
int ret = 0;
@@ -1277,8 +1278,21 @@ static int exynos_dp_bind(struct device *dev, struct 
device *master, void *data)

dp->drm_dev = drm_dev;

-   return exynos_drm_create_enc_conn(drm_dev, >encoder,
- EXYNOS_DISPLAY_TYPE_LCD);
+   ret = exynos_drm_encoder_create(drm_dev, exynos_encoder,
+   EXYNOS_DISPLAY_TYPE_LCD);
+   if (ret) {
+   DRM_ERROR("failed to create encoder\n");
+   return ret;
+   }
+
+   ret = exynos_dp_create_connector(exynos_encoder);
+   if (ret) {
+   DRM_ERROR("failed to create connector ret = %d\n", ret);
+   drm_encoder_cleanup(_encoder->base);
+   return ret;
+   }
+
+   return 0;
 }

 static void exynos_dp_unbind(struct device *dev, struct device *master,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c 
b/drivers/gpu/drm/exynos/exynos_drm_core.c
index e386452..1f38a44 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -20,36 +20,6 @@

 static LIST_HEAD(exynos_drm_subdrv_list);

-int exynos_drm_create_enc_conn(struct drm_device *dev,
-  struct exynos_drm_encoder *exynos_encoder,
-  enum exynos_drm_output_type type)
-{
-   int ret;
-   unsigned long possible_crtcs = 0;
-
-   ret = exynos_drm_crtc_get_pipe_from_type(dev, type);
-   if (ret < 0)
-   return ret;
-
-   possible_crtcs |= 1 << ret;
-
-   /* create and initialize a encoder for this sub driver. */
-   ret = exynos_drm_encoder_create(dev, exynos_encoder, possible_crtcs);
-   if (ret) {
-   DRM_ERROR("failed to create encoder\n");
-   return ret;
-   }
-
-   ret = exynos_encoder->ops->create_connector(exynos_encoder);
-   if 

[PATCH 08/11] drm/exynos: remove exynos_encoder's .commit() op

[Gustavo Padovan]

From: Gustavo Padovan 

.commit() is not used anymore, Exynos encoders now follow the
.enable()/.disable() semantics from drm atomic core, so remove this
callback.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.h | 2 --
 drivers/gpu/drm/exynos/exynos_drm_encoder.c | 3 ---
 2 files changed, 5 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 4931193..76ed6a1 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -87,7 +87,6 @@ struct exynos_drm_plane {
  *   would be called by encoder->mode_set().
  * @enable: display device on.
  * @disable: display device off.
- * @commit: apply changes to hw
  */
 struct exynos_drm_encoder;
 struct exynos_drm_encoder_ops {
@@ -100,7 +99,6 @@ struct exynos_drm_encoder_ops {
struct drm_display_mode *mode);
void (*enable)(struct exynos_drm_encoder *encoder);
void (*disable)(struct exynos_drm_encoder *encoder);
-   void (*commit)(struct exynos_drm_encoder *encoder);
 };

 /*
diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c 
b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
index b9a1c93..ce7b97e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
@@ -56,9 +56,6 @@ static void exynos_drm_encoder_enable(struct drm_encoder 
*encoder)

if (exynos_encoder->ops->enable)
exynos_encoder->ops->enable(exynos_encoder);
-
-   if (exynos_encoder->ops->commit)
-   exynos_encoder->ops->commit(exynos_encoder);
 }

 static void exynos_drm_encoder_disable(struct drm_encoder *encoder)
-- 
2.1.0

[PATCH 07/11] drm/exynos: remove extra call to exynos_dp_commit()

[Gustavo Padovan]

From: Gustavo Padovan 

exynos_dp_commit() was getting called twice by exynos encoder core, once
inside the .enable() call and another time by .commit() itself.

The remove of the second call caused the wake of a bug, the operations
orders inside exynos_dp_commit was wrong and we had to move
exynos_dp_start_video() to be the last operation in there.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_dp_core.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index dd1809b..253f955 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -795,9 +795,6 @@ static int exynos_dp_config_video(struct exynos_dp_device 
*dp)
/* Configure video slave mode */
exynos_dp_enable_video_master(dp, 0);

-   /* Enable video */
-   exynos_dp_start_video(dp);
-
timeout_loop = 0;

for (;;) {
@@ -938,6 +935,9 @@ static void exynos_dp_commit(struct exynos_drm_encoder 
*encoder)
if (drm_panel_enable(dp->panel))
DRM_ERROR("failed to enable the panel\n");
}
+
+   /* Enable video */
+   exynos_dp_start_video(dp);
 }

 static enum drm_connector_status exynos_dp_detect(
@@ -1107,7 +1107,6 @@ static struct exynos_drm_encoder_ops 
exynos_dp_encoder_ops = {
.create_connector = exynos_dp_create_connector,
.enable = exynos_dp_enable,
.disable = exynos_dp_disable,
-   .commit = exynos_dp_commit,
 };

 static struct video_info *exynos_dp_dt_parse_pdata(struct device *dev)
-- 
2.1.0

[PATCH 06/11] drm/exynos: remove extra call to hdmi_commit()

[Gustavo Padovan]

From: Gustavo Padovan 

hdmi_commit() was getting called twice by exynos encoder core, once inside
the .enable() call and another time by .commit() itself.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 13 +
 1 file changed, 1 insertion(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 1aed7ea..11bac50 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1711,16 +1711,6 @@ static void hdmi_mode_set(struct exynos_drm_encoder 
*encoder,
hdata->cea_video_id = drm_match_cea_mode(mode);
 }

-static void hdmi_commit(struct exynos_drm_encoder *encoder)
-{
-   struct hdmi_context *hdata = encoder_to_hdmi(encoder);
-
-   if (!hdata->powered)
-   return;
-
-   hdmi_conf_apply(hdata);
-}
-
 static void hdmi_enable(struct exynos_drm_encoder *encoder)
 {
struct hdmi_context *hdata = encoder_to_hdmi(encoder);
@@ -1744,7 +1734,7 @@ static void hdmi_enable(struct exynos_drm_encoder 
*encoder)
clk_prepare_enable(res->sclk_hdmi);

hdmiphy_poweron(hdata);
-   hdmi_commit(encoder);
+   hdmi_conf_apply(hdata);
 }

 static void hdmi_disable(struct exynos_drm_encoder *encoder)
@@ -1798,7 +1788,6 @@ static struct exynos_drm_encoder_ops hdmi_encoder_ops = {
.mode_set   = hdmi_mode_set,
.enable = hdmi_enable,
.disable= hdmi_disable,
-   .commit = hdmi_commit,
 };

 static void hdmi_hotplug_work_func(struct work_struct *work)
-- 
2.1.0

[PATCH 05/11] drm/exynos: remove struct exynos_drm_display

[Gustavo Padovan]

From: Gustavo Padovan 

This struct was just representing encoder information, it was a member of
struct exynos_drm_encoder, so any code trying to access encoder data would
have to go through the encoder struct, get the display struct and then get
the data it want.

During this patchset we also realized that the only data
exynos_drm_encoder needs to store is the drm_encoder parent and the
exynos_drm_encoder_ops.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos7_drm_decon.c  | 17 ---
 drivers/gpu/drm/exynos/exynos_dp_core.c | 46 +-
 drivers/gpu/drm/exynos/exynos_dp_core.h |  3 +-
 drivers/gpu/drm/exynos/exynos_drm_core.c| 23 -
 drivers/gpu/drm/exynos/exynos_drm_crtc.c|  2 +-
 drivers/gpu/drm/exynos/exynos_drm_crtc.h|  2 +-
 drivers/gpu/drm/exynos/exynos_drm_dpi.c | 41 
 drivers/gpu/drm/exynos/exynos_drm_drv.h | 47 --
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 58 +++---
 drivers/gpu/drm/exynos/exynos_drm_encoder.c | 75 -
 drivers/gpu/drm/exynos/exynos_drm_encoder.h |  6 +--
 drivers/gpu/drm/exynos/exynos_drm_fimd.c| 18 +++
 drivers/gpu/drm/exynos/exynos_drm_vidi.c| 43 +
 drivers/gpu/drm/exynos/exynos_hdmi.c| 48 +-
 14 files changed, 177 insertions(+), 252 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index cfd0b5e..1b89e94 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -61,7 +61,7 @@ struct decon_context {
atomic_twait_vsync_event;

struct exynos_drm_panel_info panel;
-   struct exynos_drm_display *display;
+   struct exynos_drm_encoder *encoder;
 };

 static const struct of_device_id decon_driver_dt_match[] = {
@@ -681,8 +681,9 @@ static int decon_bind(struct device *dev, struct device 
*master, void *data)
return PTR_ERR(ctx->crtc);
}

-   if (ctx->display)
-   exynos_drm_create_enc_conn(drm_dev, ctx->display);
+   if (ctx->encoder)
+   exynos_drm_create_enc_conn(drm_dev, ctx->encoder,
+  EXYNOS_DISPLAY_TYPE_LCD);

return 0;

@@ -695,8 +696,8 @@ static void decon_unbind(struct device *dev, struct device 
*master,

decon_disable(ctx->crtc);

-   if (ctx->display)
-   exynos_dpi_remove(ctx->display);
+   if (ctx->encoder)
+   exynos_dpi_remove(ctx->encoder);

decon_ctx_remove(ctx);
 }
@@ -781,9 +782,9 @@ static int decon_probe(struct platform_device *pdev)

platform_set_drvdata(pdev, ctx);

-   ctx->display = exynos_dpi_probe(dev);
-   if (IS_ERR(ctx->display)) {
-   ret = PTR_ERR(ctx->display);
+   ctx->encoder = exynos_dpi_probe(dev);
+   if (IS_ERR(ctx->encoder)) {
+   ret = PTR_ERR(ctx->encoder);
goto err_iounmap;
}

diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index fe38d6f..dd1809b 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -38,13 +38,13 @@

 static inline struct exynos_drm_crtc *dp_to_crtc(struct exynos_dp_device *dp)
 {
-   return to_exynos_crtc(dp->encoder->crtc);
+   return to_exynos_crtc(dp->encoder.base.crtc);
 }

-static inline struct exynos_dp_device *
-display_to_dp(struct exynos_drm_display *d)
+static inline struct exynos_dp_device *encoder_to_dp(
+   struct exynos_drm_encoder *e)
 {
-   return container_of(d, struct exynos_dp_device, display);
+   return container_of(e, struct exynos_dp_device, encoder);
 }

 struct bridge_init {
@@ -891,9 +891,9 @@ static void exynos_dp_hotplug(struct work_struct *work)
drm_helper_hpd_irq_event(dp->drm_dev);
 }

-static void exynos_dp_commit(struct exynos_drm_display *display)
+static void exynos_dp_commit(struct exynos_drm_encoder *encoder)
 {
-   struct exynos_dp_device *dp = display_to_dp(display);
+   struct exynos_dp_device *dp = encoder_to_dp(encoder);
int ret;

/* Keep the panel disabled while we configure video */
@@ -994,7 +994,7 @@ static struct drm_encoder *exynos_dp_best_encoder(
 {
struct exynos_dp_device *dp = ctx_from_connector(connector);

-   return dp->encoder;
+   return >encoder.base;
 }

 static struct drm_connector_helper_funcs exynos_dp_connector_helper_funcs = {
@@ -1019,15 +1019,13 @@ static int exynos_drm_attach_lcd_bridge(struct 
exynos_dp_device *dp,
return 0;
 }

-static int exynos_dp_create_connector(struct exynos_drm_display *display,
-   struct drm_encoder *encoder)
+static int exynos_dp_create_connector(struct exynos_drm_encoder 

[PATCH 04/11] drm/exynos: simplify calculation of possible CRTCs

[Gustavo Padovan]

From: Gustavo Padovan 

All CRTCs can only be LCD, HDMI or VIDI, so basically all CRTCs will be a
possible CRTCs. This patch removes an extra function with switch that was
only checking if the CRTC type was one of those three above.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_encoder.c | 29 +
 1 file changed, 5 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c 
b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
index 0aa4a58..7ba3a2d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
@@ -105,36 +105,17 @@ static struct drm_encoder_funcs exynos_encoder_funcs = {
.destroy = exynos_drm_encoder_destroy,
 };

-static unsigned int exynos_drm_encoder_clones(struct drm_encoder *encoder)
+void exynos_drm_encoder_setup(struct drm_device *dev)
 {
-   struct drm_encoder *clone;
-   struct drm_device *dev = encoder->dev;
-   struct exynos_drm_encoder *exynos_encoder = to_exynos_encoder(encoder);
-   struct exynos_drm_display *display = exynos_encoder->display;
+   struct drm_encoder *encoder;
unsigned int clone_mask = 0;
int cnt = 0;

-   list_for_each_entry(clone, >mode_config.encoder_list, head) {
-   switch (display->type) {
-   case EXYNOS_DISPLAY_TYPE_LCD:
-   case EXYNOS_DISPLAY_TYPE_HDMI:
-   case EXYNOS_DISPLAY_TYPE_VIDI:
-   clone_mask |= (1 << (cnt++));
-   break;
-   default:
-   continue;
-   }
-   }
-
-   return clone_mask;
-}
-
-void exynos_drm_encoder_setup(struct drm_device *dev)
-{
-   struct drm_encoder *encoder;
+   list_for_each_entry(encoder, >mode_config.encoder_list, head)
+   clone_mask |= (1 << (cnt++));

list_for_each_entry(encoder, >mode_config.encoder_list, head)
-   encoder->possible_clones = exynos_drm_encoder_clones(encoder);
+   encoder->possible_clones = clone_mask;
 }

 struct drm_encoder *
-- 
2.1.0

[PATCH 03/11] drm/exynos: remove unused .remove() and .check_mode() ops from display

[Gustavo Padovan]

From: Gustavo Padovan 

These two display_ops are not used anywhere, remove them.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.h | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 5c55606..47ea400 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -81,11 +81,9 @@ struct exynos_drm_plane {
  * - this structure is common to analog tv, digital tv and lcd panel.
  *
  * @create_connector: initialize and register a new connector
- * @remove: cleans up the display for removal
  * @mode_fixup: fix mode data comparing to hw specific display mode.
  * @mode_set: convert drm_display_mode to hw specific display mode and
  *   would be called by encoder->mode_set().
- * @check_mode: check if mode is valid or not.
  * @enable: display device on.
  * @disable: display device off.
  * @commit: apply changes to hw
@@ -94,15 +92,12 @@ struct exynos_drm_display;
 struct exynos_drm_display_ops {
int (*create_connector)(struct exynos_drm_display *display,
struct drm_encoder *encoder);
-   void (*remove)(struct exynos_drm_display *display);
void (*mode_fixup)(struct exynos_drm_display *display,
struct drm_connector *connector,
const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode);
void (*mode_set)(struct exynos_drm_display *display,
struct drm_display_mode *mode);
-   int (*check_mode)(struct exynos_drm_display *display,
-   struct drm_display_mode *mode);
void (*enable)(struct exynos_drm_display *display);
void (*disable)(struct exynos_drm_display *display);
void (*commit)(struct exynos_drm_display *display);
-- 
2.1.0

[PATCH 02/11] drm/exynos: remove wrappers for phy_power_{on,off}

[Gustavo Padovan]

From: Gustavo Padovan 

phy_power_on() and phy_power_off() already checks for NULL pointer.
This patch removes the wrappers exynos_dp_phy_init() and
exynos_dp_phy_exit() since the only think they were doing was a check for
NULL phy.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_dp_core.c | 18 +++---
 1 file changed, 3 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index f2cc8f1..fe38d6f 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1054,18 +1054,6 @@ static int exynos_dp_create_connector(struct 
exynos_drm_display *display,
return ret;
 }

-static void exynos_dp_phy_init(struct exynos_dp_device *dp)
-{
-   if (dp->phy)
-   phy_power_on(dp->phy);
-}
-
-static void exynos_dp_phy_exit(struct exynos_dp_device *dp)
-{
-   if (dp->phy)
-   phy_power_off(dp->phy);
-}
-
 static void exynos_dp_enable(struct exynos_drm_display *display)
 {
struct exynos_dp_device *dp = display_to_dp(display);
@@ -1085,7 +1073,7 @@ static void exynos_dp_enable(struct exynos_drm_display 
*display)
crtc->ops->clock_enable(dp_to_crtc(dp), true);

clk_prepare_enable(dp->clock);
-   exynos_dp_phy_init(dp);
+   phy_power_on(dp->phy);
exynos_dp_init_dp(dp);
enable_irq(dp->irq);
exynos_dp_commit(>display);
@@ -1105,7 +1093,7 @@ static void exynos_dp_disable(struct exynos_drm_display 
*display)

disable_irq(dp->irq);
flush_work(>hotplug_work);
-   exynos_dp_phy_exit(dp);
+   phy_power_off(dp->phy);
clk_disable_unprepare(dp->clock);

if (crtc->ops->clock_enable)
@@ -1278,7 +1266,7 @@ static int exynos_dp_bind(struct device *dev, struct 
device *master, void *data)

INIT_WORK(>hotplug_work, exynos_dp_hotplug);

-   exynos_dp_phy_init(dp);
+   phy_power_on(dp->phy);

exynos_dp_init_dp(dp);

-- 
2.1.0

[PATCH 01/11] drm/exynos: split display's .dpms() into .enable() and .disable()

[Gustavo Padovan]

From: Gustavo Padovan 

The DRM Core doesn't have a dpms() operation anymore, everything
now is enable() or disable().

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_dp_core.c | 37 
 drivers/gpu/drm/exynos/exynos_drm_dpi.c | 36 
 drivers/gpu/drm/exynos/exynos_drm_drv.h |  6 ++-
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 44 ++-
 drivers/gpu/drm/exynos/exynos_drm_encoder.c |  8 ++--
 drivers/gpu/drm/exynos/exynos_hdmi.c| 65 ++---
 6 files changed, 62 insertions(+), 134 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 172b800..f2cc8f1 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1066,8 +1066,9 @@ static void exynos_dp_phy_exit(struct exynos_dp_device 
*dp)
phy_power_off(dp->phy);
 }

-static void exynos_dp_poweron(struct exynos_dp_device *dp)
+static void exynos_dp_enable(struct exynos_drm_display *display)
 {
+   struct exynos_dp_device *dp = display_to_dp(display);
struct exynos_drm_crtc *crtc = dp_to_crtc(dp);

if (dp->dpms_mode == DRM_MODE_DPMS_ON)
@@ -1090,13 +1091,11 @@ static void exynos_dp_poweron(struct exynos_dp_device 
*dp)
exynos_dp_commit(>display);
 }

-static void exynos_dp_poweroff(struct exynos_dp_device *dp)
+static void exynos_dp_disable(struct exynos_drm_display *display)
 {
+   struct exynos_dp_device *dp = display_to_dp(display);
struct exynos_drm_crtc *crtc = dp_to_crtc(dp);

-   if (dp->dpms_mode != DRM_MODE_DPMS_ON)
-   return;
-
if (dp->panel) {
if (drm_panel_disable(dp->panel)) {
DRM_ERROR("failed to disable the panel\n");
@@ -1118,28 +1117,10 @@ static void exynos_dp_poweroff(struct exynos_dp_device 
*dp)
}
 }

-static void exynos_dp_dpms(struct exynos_drm_display *display, int mode)
-{
-   struct exynos_dp_device *dp = display_to_dp(display);
-
-   switch (mode) {
-   case DRM_MODE_DPMS_ON:
-   exynos_dp_poweron(dp);
-   break;
-   case DRM_MODE_DPMS_STANDBY:
-   case DRM_MODE_DPMS_SUSPEND:
-   case DRM_MODE_DPMS_OFF:
-   exynos_dp_poweroff(dp);
-   break;
-   default:
-   break;
-   }
-   dp->dpms_mode = mode;
-}
-
 static struct exynos_drm_display_ops exynos_dp_display_ops = {
.create_connector = exynos_dp_create_connector,
-   .dpms = exynos_dp_dpms,
+   .enable = exynos_dp_enable,
+   .disable = exynos_dp_disable,
.commit = exynos_dp_commit,
 };

@@ -1319,7 +1300,7 @@ static void exynos_dp_unbind(struct device *dev, struct 
device *master,
 {
struct exynos_dp_device *dp = dev_get_drvdata(dev);

-   exynos_dp_dpms(>display, DRM_MODE_DPMS_OFF);
+   exynos_dp_disable(>display);
 }

 static const struct component_ops exynos_dp_ops = {
@@ -1377,7 +1358,7 @@ static int exynos_dp_suspend(struct device *dev)
 {
struct exynos_dp_device *dp = dev_get_drvdata(dev);

-   exynos_dp_dpms(>display, DRM_MODE_DPMS_OFF);
+   exynos_dp_disable(>display);
return 0;
 }

@@ -1385,7 +1366,7 @@ static int exynos_dp_resume(struct device *dev)
 {
struct exynos_dp_device *dp = dev_get_drvdata(dev);

-   exynos_dp_dpms(>display, DRM_MODE_DPMS_ON);
+   exynos_dp_enable(>display);
return 0;
 }
 #endif
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
index 7cb6595..e042670 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
@@ -32,7 +32,6 @@ struct exynos_dpi {
struct drm_encoder *encoder;

struct videomode *vm;
-   int dpms_mode;
 };

 #define connector_to_dpi(c) container_of(c, struct exynos_dpi, connector)
@@ -133,46 +132,30 @@ static int exynos_dpi_create_connector(struct 
exynos_drm_display *display,
return 0;
 }

-static void exynos_dpi_poweron(struct exynos_dpi *ctx)
+static void exynos_dpi_enable(struct exynos_drm_display *display)
 {
+   struct exynos_dpi *ctx = display_to_dpi(display);
+
if (ctx->panel) {
drm_panel_prepare(ctx->panel);
drm_panel_enable(ctx->panel);
}
 }

-static void exynos_dpi_poweroff(struct exynos_dpi *ctx)
+static void exynos_dpi_disable(struct exynos_drm_display *display)
 {
+   struct exynos_dpi *ctx = display_to_dpi(display);
+
if (ctx->panel) {
drm_panel_disable(ctx->panel);
drm_panel_unprepare(ctx->panel);
}
 }

-static void exynos_dpi_dpms(struct exynos_drm_display *display, int mode)
-{
-   struct exynos_dpi *ctx = display_to_dpi(display);
-
-   switch (mode) {
-   case DRM_MODE_DPMS_ON:
-   if (ctx->dpms_mode != DRM_MODE_DPMS_ON)
- 

[PATCH 00/11] drm/exynos: remove exynos_drm_display and exynos_drm_encoder

[Gustavo Padovan]

From: Gustavo Padovan 

Hi,

This patchset is another important step in the exynos clean up, it removes
two exynos internal structs in favor of wider use of struct drm_encoder.

Structs exynos_drm_display and exynos_drm_encoder were doing exactly what
struct drm_encoder does so remove them makes the code cleaner, easier
to understand and less error prone.

Please review,

   Gustavo


---
Gustavo Padovan (11):
  drm/exynos: split display's .dpms() into .enable() and .disable()
  drm/exynos: remove wrappers for phy_power_{on,off}
  drm/exynos: remove unused .remove() and .check_mode() ops from display
  drm/exynos: simplify calculation of possible CRTCs
  drm/exynos: remove struct exynos_drm_display
  drm/exynos: remove extra call to hdmi_commit()
  drm/exynos: remove extra call to exynos_dp_commit()
  drm/exynos: remove exynos_encoder's .commit() op
  drm/exynos: remove exynos_drm_create_enc_conn()
  drm/exynos: fold encoder setup into exynos_drm_load()
  drm/exynos: remove struct exynos_drm_encoder layer

 drivers/gpu/drm/exynos/Makefile |   7 +-
 drivers/gpu/drm/exynos/exynos7_drm_decon.c  |  16 +--
 drivers/gpu/drm/exynos/exynos_dp_core.c | 122 +--
 drivers/gpu/drm/exynos/exynos_dp_core.h |   3 +-
 drivers/gpu/drm/exynos/exynos_drm_core.c|  36 --
 drivers/gpu/drm/exynos/exynos_drm_crtc.c|   3 +-
 drivers/gpu/drm/exynos/exynos_drm_crtc.h|   2 +-
 drivers/gpu/drm/exynos/exynos_drm_dpi.c |  96 ---
 drivers/gpu/drm/exynos/exynos_drm_drv.c |  13 ++-
 drivers/gpu/drm/exynos/exynos_drm_drv.h |  65 ++-
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 130 ++---
 drivers/gpu/drm/exynos/exynos_drm_encoder.c | 174 
 drivers/gpu/drm/exynos/exynos_drm_encoder.h |  23 
 drivers/gpu/drm/exynos/exynos_drm_fimd.c|  17 ++-
 drivers/gpu/drm/exynos/exynos_drm_vidi.c|  90 --
 drivers/gpu/drm/exynos/exynos_hdmi.c| 160 -
 16 files changed, 355 insertions(+), 602 deletions(-)
 delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_encoder.c
 delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_encoder.h

-- 
2.1.0

[Bug 91520] [radeonsi, PIGLIT, regression] spec@arb_gpu_shader_fp64@execution@fs-indirect-temp-double-{dst, src} triggers SIGSEGV

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

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

--- Comment #3 from Kai  ---
Only as reference, if others hit this too: the Debian bug report can be found
at <https://bugs.debian.org/794488>.

-- 
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/20150803/33f2ecd2/attachment.html>

[PATCH] drm/amdgpu: increment queue when iterating on this variable.

[Alex Deucher]

On Sat, Aug 1, 2015 at 9:55 AM, Nicolas Iooss
 wrote:
> gfx_v7_0_print_status contains a for loop on variable queue which does
> not update this variable between each iteration.  This is bug is
> reported by clang while building allmodconfig LLVMLinux on x86_64:
>
> drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c:5126:19: error: variable
> 'queue' used in loop condition not modified in loop body
> [-Werror,-Wloop-analysis]
> for (queue = 0; queue < 8; i++) {
> ^
>
> Fix this by incrementing variable queue instead of i in this loop.
>
> Signed-off-by: Nicolas Iooss 

Applied.  thanks!

Alex


> ---
>  drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c 
> b/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
> index 2db6ab0a543d..5c03420ca5dc 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
> @@ -5122,7 +5122,7 @@ static void gfx_v7_0_print_status(void *handle)
> dev_info(adev->dev, "  CP_HPD_EOP_CONTROL=0x%08X\n",
>  RREG32(mmCP_HPD_EOP_CONTROL));
>
> -   for (queue = 0; queue < 8; i++) {
> +   for (queue = 0; queue < 8; queue++) {
> cik_srbm_select(adev, me, pipe, queue, 0);
> dev_info(adev->dev, "  queue: %d\n", queue);
> dev_info(adev->dev, "  CP_PQ_WPTR_POLL_CNTL=0x%08X\n",
> --
> 2.5.0
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91520] [radeonsi, PIGLIT, regression] spec@arb_gpu_shader_fp64@execution@fs-indirect-temp-double-{dst, src} triggers SIGSEGV

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

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

Kai  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |NOTOURBUG

--- Comment #2 from Kai  ---
(In reply to Michel Dänzer from comment #1)
> I had the same problem with libelf1 0.163-4 (was fine with libelf1
> 0.159-4.2). I rebuilt Mesa against libelfg0-dev instead of libelf-dev, and
> the problem is gone for me.
> 
> If you can confirm this, please file a bug against libelf1.

Indeed, libelfg0 (0.8.13-5) works! Thanks for the pointer.

-- 
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/20150803/b38c527d/attachment.html>

[PATCH v2] drm/i915: load driver even if debugfs fails

[Sudip Mukherjee]

On Thu, Jul 23, 2015 at 07:36:12PM +0530, Sudip Mukherjee wrote:
> debugfs files are not necessary for the usual operation of the driver
> and the device. No need to check for the return values from the debugfs
> file creation. Even if one debugfs file fails to create we try with the
> next debugfs file and ultimately return success always so that the
> driver continues to load.
> cleanup will clean all the created debugfs files as the list of file
> that are created are maintained in minor->debugfs_list.
> 
> Cc: Chris Wilson 
> Signed-off-by: Sudip Mukherjee 
> ---
A gentle ping.

regards
sudip

[REGRESSION] Re: i915 driver crashes on T540p if docking station attached

[Theodore Ts'o]

On Mon, Aug 03, 2015 at 10:24:53AM -0700, Linus Torvalds wrote:
> On Mon, Aug 3, 2015 at 9:25 AM, Theodore Ts'o  wrote:
> >
> > I've just tried pulling in your updated fixes-stuff, and it avoids the
> > oops and allows external the monitor to work correctly.
> 
> Good. Have either of you tested the suspend/resume behavior? Is that fixed 
> too?

No, I haven't had a chance to test the suspend/resume behavior,
because that requires suspending at work, going home, and connecting
to a dock which has a different monitor attached to it, and resuming
(or vice versa of suspending at home and then resuming at work).

So it's a bit trickier for me to test.  It's also not a regression,
and the workaround of rebooting is annoying, but I've lived with it
for several releases now, but I'll try the two patches/changes that
folks had suggested hopefully later this week.

- Ted

[PATCH 4/4] drm/sti: atomic crtc/plane update

[Benjamin Gaignard]

From: Vincent Abriou 

Better fit STI hardware structure.
Planes are no more responsible of updating mixer information such
as z-order and status. It is now up to the CRTC atomic flush to
do it. Plane actions (enable or disable) are performed atomically.
Disabling of a plane is synchronize with the vsync event.

Signed-off-by: Vincent Abriou 
Reviewed-by: Benjamin Gaignard 
---
 drivers/gpu/drm/sti/sti_compositor.c |  32 +--
 drivers/gpu/drm/sti/sti_crtc.c   | 133 +++---
 drivers/gpu/drm/sti/sti_cursor.c | 211 +--
 drivers/gpu/drm/sti/sti_cursor.h |   6 +-
 drivers/gpu/drm/sti/sti_gdp.c| 493 +++
 drivers/gpu/drm/sti/sti_gdp.h|   8 +-
 drivers/gpu/drm/sti/sti_hqvdp.c  | 429 --
 drivers/gpu/drm/sti/sti_mixer.c  |  10 +-
 drivers/gpu/drm/sti/sti_mixer.h  |  11 +-
 drivers/gpu/drm/sti/sti_plane.c  | 253 ++
 drivers/gpu/drm/sti/sti_plane.h  |  66 ++---
 drivers/gpu/drm/sti/sti_vid.c|  29 ++-
 drivers/gpu/drm/sti/sti_vid.h|   5 +-
 13 files changed, 809 insertions(+), 877 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_compositor.c 
b/drivers/gpu/drm/sti/sti_compositor.c
index d62ed7f..c652627 100644
--- a/drivers/gpu/drm/sti/sti_compositor.c
+++ b/drivers/gpu/drm/sti/sti_compositor.c
@@ -61,15 +61,13 @@ static int sti_compositor_bind(struct device *dev,
 {
struct sti_compositor *compo = dev_get_drvdata(dev);
struct drm_device *drm_dev = data;
-   unsigned int i, mixer_id = 0, vid_id = 0, crtc_id = 0, plane_id = 0;
+   unsigned int i, mixer_id = 0, vid_id = 0, crtc_id = 0;
struct sti_private *dev_priv = drm_dev->dev_private;
struct drm_plane *cursor = NULL;
struct drm_plane *primary = NULL;
struct sti_compositor_subdev_descriptor *desc = compo->data.subdev_desc;
unsigned int array_size = compo->data.nb_subdev;

-   struct sti_plane *plane;
-
dev_priv->compo = compo;

/* Register mixer subdev and video subdev first */
@@ -110,27 +108,25 @@ static int sti_compositor_bind(struct device *dev,
/* Nothing to do, already done at the first round */
break;
case STI_CURSOR_SUBDEV:
-   plane = sti_cursor_create(compo->dev, desc[i].id,
- compo->regs + desc[i].offset);
-   if (!plane) {
+   cursor = sti_cursor_create(drm_dev, compo->dev,
+  desc[i].id,
+  compo->regs + desc[i].offset,
+  1);
+   if (!cursor) {
DRM_ERROR("Can't create CURSOR plane\n");
break;
}
-   cursor = sti_plane_init(drm_dev, plane, 1,
-   DRM_PLANE_TYPE_CURSOR);
-   plane_id++;
break;
case STI_GPD_SUBDEV:
-   plane = sti_gdp_create(compo->dev, desc[i].id,
-  compo->regs + desc[i].offset);
-   if (!plane) {
+   primary = sti_gdp_create(drm_dev, compo->dev,
+desc[i].id,
+compo->regs + desc[i].offset,
+(1 << mixer_id) - 1,
+plane_type);
+   if (!primary) {
DRM_ERROR("Can't create GDP plane\n");
break;
}
-   primary = sti_plane_init(drm_dev, plane,
-(1 << mixer_id) - 1,
-plane_type);
-   plane_id++;
break;
default:
DRM_ERROR("Unknown subdev compoment type\n");
@@ -151,10 +147,6 @@ static int sti_compositor_bind(struct device *dev,
/* Allow usage of vblank without having to call drm_irq_install */
drm_dev->irq_enabled = 1;

-   DRM_DEBUG_DRIVER("Initialized %d DRM CRTC(s) and %d DRM plane(s)\n",
-crtc_id, plane_id);
-   DRM_DEBUG_DRIVER("DRM plane(s) for VID/VDP not created yet\n");
-
return 0;
 }

diff --git a/drivers/gpu/drm/sti/sti_crtc.c b/drivers/gpu/drm/sti/sti_crtc.c
index 27b3ef2..23fc2db 100644
--- a/drivers/gpu/drm/sti/sti_crtc.c
+++ b/drivers/gpu/drm/sti/sti_crtc.c
@@ -17,20 +17,18 @@
 #include "sti_compositor.h"
 #include "sti_crtc.h"
 #include "sti_drv.h"
+#include "sti_vid.h"
 #include "sti_vtg.h"

[Bug 91461] gl_TessLevel* writes have no effect for all but the last TCS invocation

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

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

--- Comment #2 from Daniel Scharrer  ---
I can confirm that the patch "radeonsi: before storing tess levels, load them
from LDS instead of temporary" on the mailing list fixes the issue.

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

[Bug 91527] 7870 radeon crashes after kernel msg drm:radeon_mn_invalidate_range_start

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

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

--- Comment #1 from Alex Deucher  ---
Please attach your xorg log and dmesg output.

-- 
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/20150803/4f848e3a/attachment.html>

[PATCH 3/5] drm/i2c: adv7511: Refactor encoder slave functions

[Andrzej Hajda]

Hi,

On 07/31/2015 04:48 PM, Rob Clark wrote:
> On Fri, Jul 31, 2015 at 8:58 AM, Boris Brezillon
>  wrote:
>> Hi Rob,
>>
>> On Fri, 31 Jul 2015 08:13:59 -0400
>> Rob Clark  wrote:
>>

(...)

>>
>> Another problem I've seen with some drm bridge drivers is that they
>> directly create their own connector, which, as Archit stated, is wrong
>> if you decide to chain this bridge with another bridge. The other
> 
> I agree with Archit on this.  He took this approach w/ msm support for
> external bridges, and it seems sensible that the last bridge
> constructs the connector.  (Plus presumably that is where hpd, ddc
> probing, etc, is happing)

With this approach many bridges should construct connector conditionally,
depending if there is something behind them in pipeline (the same is true for
encoders and even crtcs). It works, but for me there is lot of unnecessary code
and all those conditional paths make things less friendly for development.
Wouldn't be better to move creation of the connector to the main drm driver,
it would require probably adding some opses/fields to drm_bridges but the
drivers would be simpler, I guess.


Regards
Andrzej

> 
>> reason why the bridge should not create the connector by its own is
>> that in some case the encoder supports different types of connectors (a
>> TDMS encoder can be used to output HDMI or DVI), and thus, selecting
>> the connector type should be left to the part responsible for creating
>> the display pipelines.
> 
> did you mean "should" instead of "should not"?  Otherwise I don't
> think I understand..
> 
> BR,
> -R
> 
>> This being said, I'm definitely not an expert in this area, so don't
>> hesitate to show me where I'm wrong.
>>
>> Best Regards,
>>
>> Boris
>>
>> --
>> Boris Brezillon, Free Electrons
>> Embedded Linux and Kernel engineering
>> http://free-electrons.com

[PATCH 11/11] drm/amdgpu: Enable the Fiji DID 0x7300 support

[Alex Deucher]

From: David Zhang 

Signed-off-by: David Zhang 
Reviewed-by: Alex Deucher 
Reviewed-by: Jammy Zhou 
Reviewed-by: Christian K?nig 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 5e890b0..984bd6b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -254,6 +254,8 @@ static struct pci_device_id pciidlist[] = {
{0x1002, 0x6930, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_TONGA},
{0x1002, 0x6938, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_TONGA},
{0x1002, 0x6939, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_TONGA},
+   /* fiji */
+   {0x1002, 0x7300, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_FIJI},
/* carrizo */
{0x1002, 0x9870, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_CARRIZO|AMD_IS_APU},
{0x1002, 0x9874, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_CARRIZO|AMD_IS_APU},
-- 
1.8.3.1

[PATCH 10/11] drm/amdgpu: add support for VCE 3.x on Fiji

[Alex Deucher]

VCE on fiji is single pipe only.

Reviewed-by: David Zhang 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c | 5 +
 drivers/gpu/drm/amd/amdgpu/vce_v3_0.c   | 7 +++
 drivers/gpu/drm/amd/amdgpu/vi.c | 7 +++
 3 files changed, 19 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
index e17467f..59acb0b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
@@ -48,6 +48,7 @@
 #endif
 #define FIRMWARE_TONGA "amdgpu/tonga_vce.bin"
 #define FIRMWARE_CARRIZO   "amdgpu/carrizo_vce.bin"
+#define FIRMWARE_FIJI  "amdgpu/fiji_vce.bin"

 #ifdef CONFIG_DRM_AMDGPU_CIK
 MODULE_FIRMWARE(FIRMWARE_BONAIRE);
@@ -58,6 +59,7 @@ MODULE_FIRMWARE(FIRMWARE_MULLINS);
 #endif
 MODULE_FIRMWARE(FIRMWARE_TONGA);
 MODULE_FIRMWARE(FIRMWARE_CARRIZO);
+MODULE_FIRMWARE(FIRMWARE_FIJI);

 static void amdgpu_vce_idle_work_handler(struct work_struct *work);

@@ -101,6 +103,9 @@ int amdgpu_vce_sw_init(struct amdgpu_device *adev, unsigned 
long size)
case CHIP_CARRIZO:
fw_name = FIRMWARE_CARRIZO;
break;
+   case CHIP_FIJI:
+   fw_name = FIRMWARE_FIJI;
+   break;

default:
return -EINVAL;
diff --git a/drivers/gpu/drm/amd/amdgpu/vce_v3_0.c 
b/drivers/gpu/drm/amd/amdgpu/vce_v3_0.c
index 5a5a40c..4349658 100644
--- a/drivers/gpu/drm/amd/amdgpu/vce_v3_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/vce_v3_0.c
@@ -205,6 +205,13 @@ static unsigned vce_v3_0_get_harvest_config(struct 
amdgpu_device *adev)
u32 tmp;
unsigned ret;

+   /* Fiji is single pipe */
+   if (adev->asic_type == CHIP_FIJI) {
+   ret = AMDGPU_VCE_HARVEST_VCE1;
+   return ret;
+   }
+
+   /* Tonga and CZ are dual or single pipe */
if (adev->flags & AMD_IS_APU)
tmp = (RREG32_SMC(ixVCE_HARVEST_FUSE_MACRO__ADDRESS) &
   VCE_HARVEST_FUSE_MACRO__MASK) >>
diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c b/drivers/gpu/drm/amd/amdgpu/vi.c
index 1f3ca63..1502383 100644
--- a/drivers/gpu/drm/amd/amdgpu/vi.c
+++ b/drivers/gpu/drm/amd/amdgpu/vi.c
@@ -1227,6 +1227,13 @@ static const struct amdgpu_ip_block_version 
fiji_ip_blocks[] =
.rev = 0,
.funcs = _v6_0_ip_funcs,
},
+   {
+   .type = AMD_IP_BLOCK_TYPE_VCE,
+   .major = 3,
+   .minor = 0,
+   .rev = 0,
+   .funcs = _v3_0_ip_funcs,
+   },
 };

 static const struct amdgpu_ip_block_version cz_ip_blocks[] =
-- 
1.8.3.1

[PATCH 09/11] drm/amdgpu: Add Fiji support to the UVD 6.0 IP module

[Alex Deucher]

From: David Zhang 

Signed-off-by: David Zhang 
Reviewed-by: Alex Deucher 
Reviewed-by: Jammy Zhou 
Reviewed-by: Christian K?nig 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 5 +
 drivers/gpu/drm/amd/amdgpu/vi.c | 7 +++
 2 files changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
index 7d20aca..ad76f5e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
@@ -52,6 +52,7 @@
 #endif
 #define FIRMWARE_TONGA "amdgpu/tonga_uvd.bin"
 #define FIRMWARE_CARRIZO   "amdgpu/carrizo_uvd.bin"
+#define FIRMWARE_FIJI  "amdgpu/fiji_uvd.bin"

 /**
  * amdgpu_uvd_cs_ctx - Command submission parser context
@@ -81,6 +82,7 @@ MODULE_FIRMWARE(FIRMWARE_MULLINS);
 #endif
 MODULE_FIRMWARE(FIRMWARE_TONGA);
 MODULE_FIRMWARE(FIRMWARE_CARRIZO);
+MODULE_FIRMWARE(FIRMWARE_FIJI);

 static void amdgpu_uvd_note_usage(struct amdgpu_device *adev);
 static void amdgpu_uvd_idle_work_handler(struct work_struct *work);
@@ -116,6 +118,9 @@ int amdgpu_uvd_sw_init(struct amdgpu_device *adev)
case CHIP_TONGA:
fw_name = FIRMWARE_TONGA;
break;
+   case CHIP_FIJI:
+   fw_name = FIRMWARE_FIJI;
+   break;
case CHIP_CARRIZO:
fw_name = FIRMWARE_CARRIZO;
break;
diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c b/drivers/gpu/drm/amd/amdgpu/vi.c
index c1b2867..1f3ca63 100644
--- a/drivers/gpu/drm/amd/amdgpu/vi.c
+++ b/drivers/gpu/drm/amd/amdgpu/vi.c
@@ -1220,6 +1220,13 @@ static const struct amdgpu_ip_block_version 
fiji_ip_blocks[] =
.rev = 0,
.funcs = _v3_0_ip_funcs,
},
+   {
+   .type = AMD_IP_BLOCK_TYPE_UVD,
+   .major = 6,
+   .minor = 0,
+   .rev = 0,
+   .funcs = _v6_0_ip_funcs,
+   },
 };

 static const struct amdgpu_ip_block_version cz_ip_blocks[] =
-- 
1.8.3.1

[PATCH 08/11] drm/amdgpu: Add Fiji support to the SDMA 3.0 IP module

[Alex Deucher]

From: David Zhang 

Signed-off-by: David Zhang 
Reviewed-by: Alex Deucher 
Reviewed-by: Jammy Zhou 
Reviewed-by: Christian K?nig 
---
 drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c | 31 +++
 drivers/gpu/drm/amd/amdgpu/vi.c|  7 +++
 2 files changed, 38 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c 
b/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
index 2b7cb33..f7d2a21 100644
--- a/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
@@ -53,6 +53,8 @@ MODULE_FIRMWARE("amdgpu/tonga_sdma.bin");
 MODULE_FIRMWARE("amdgpu/tonga_sdma1.bin");
 MODULE_FIRMWARE("amdgpu/carrizo_sdma.bin");
 MODULE_FIRMWARE("amdgpu/carrizo_sdma1.bin");
+MODULE_FIRMWARE("amdgpu/fiji_sdma.bin");
+MODULE_FIRMWARE("amdgpu/fiji_sdma1.bin");

 static const u32 sdma_offsets[SDMA_MAX_INSTANCE] =
 {
@@ -80,6 +82,24 @@ static const u32 tonga_mgcg_cgcg_init[] =
mmSDMA1_CLK_CTRL, 0xff000ff0, 0x0100
 };

+static const u32 golden_settings_fiji_a10[] =
+{
+   mmSDMA0_CHICKEN_BITS, 0xfc910007, 0x00810007,
+   mmSDMA0_GFX_IB_CNTL, 0x800f0111, 0x0100,
+   mmSDMA0_RLC0_IB_CNTL, 0x800f0111, 0x0100,
+   mmSDMA0_RLC1_IB_CNTL, 0x800f0111, 0x0100,
+   mmSDMA1_CHICKEN_BITS, 0xfc910007, 0x00810007,
+   mmSDMA1_GFX_IB_CNTL, 0x800f0111, 0x0100,
+   mmSDMA1_RLC0_IB_CNTL, 0x800f0111, 0x0100,
+   mmSDMA1_RLC1_IB_CNTL, 0x800f0111, 0x0100,
+};
+
+static const u32 fiji_mgcg_cgcg_init[] =
+{
+   mmSDMA0_CLK_CTRL, 0xff000ff0, 0x0100,
+   mmSDMA1_CLK_CTRL, 0xff000ff0, 0x0100
+};
+
 static const u32 cz_golden_settings_a11[] =
 {
mmSDMA0_CHICKEN_BITS, 0xfc910007, 0x00810007,
@@ -122,6 +142,14 @@ static const u32 cz_mgcg_cgcg_init[] =
 static void sdma_v3_0_init_golden_registers(struct amdgpu_device *adev)
 {
switch (adev->asic_type) {
+   case CHIP_FIJI:
+   amdgpu_program_register_sequence(adev,
+fiji_mgcg_cgcg_init,
+(const 
u32)ARRAY_SIZE(fiji_mgcg_cgcg_init));
+   amdgpu_program_register_sequence(adev,
+golden_settings_fiji_a10,
+(const 
u32)ARRAY_SIZE(golden_settings_fiji_a10));
+   break;
case CHIP_TONGA:
amdgpu_program_register_sequence(adev,
 tonga_mgcg_cgcg_init,
@@ -166,6 +194,9 @@ static int sdma_v3_0_init_microcode(struct amdgpu_device 
*adev)
case CHIP_TONGA:
chip_name = "tonga";
break;
+   case CHIP_FIJI:
+   chip_name = "fiji";
+   break;
case CHIP_CARRIZO:
chip_name = "carrizo";
break;
diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c b/drivers/gpu/drm/amd/amdgpu/vi.c
index a0babb4..c1b2867 100644
--- a/drivers/gpu/drm/amd/amdgpu/vi.c
+++ b/drivers/gpu/drm/amd/amdgpu/vi.c
@@ -1213,6 +1213,13 @@ static const struct amdgpu_ip_block_version 
fiji_ip_blocks[] =
.rev = 0,
.funcs = _v8_0_ip_funcs,
},
+   {
+   .type = AMD_IP_BLOCK_TYPE_SDMA,
+   .major = 3,
+   .minor = 0,
+   .rev = 0,
+   .funcs = _v3_0_ip_funcs,
+   },
 };

 static const struct amdgpu_ip_block_version cz_ip_blocks[] =
-- 
1.8.3.1

[PATCH 07/11] drm/amdgpu: Add Fiji support to the GFX 8.0 IP module (v2)

[Alex Deucher]

v2: agd5f: fix the rb setup.

Signed-off-by: David Zhang 
Reviewed-by: Alex Deucher 
Reviewed-by: Jammy Zhou 
Reviewed-by: Christian K?nig 
---
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 109 +-
 drivers/gpu/drm/amd/amdgpu/vi.c   |   7 +++
 2 files changed, 115 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
index d29dc8c..0ae4f47 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
@@ -87,6 +87,13 @@ MODULE_FIRMWARE("amdgpu/topaz_mec.bin");
 MODULE_FIRMWARE("amdgpu/topaz_mec2.bin");
 MODULE_FIRMWARE("amdgpu/topaz_rlc.bin");

+MODULE_FIRMWARE("amdgpu/fiji_ce.bin");
+MODULE_FIRMWARE("amdgpu/fiji_pfp.bin");
+MODULE_FIRMWARE("amdgpu/fiji_me.bin");
+MODULE_FIRMWARE("amdgpu/fiji_mec.bin");
+MODULE_FIRMWARE("amdgpu/fiji_mec2.bin");
+MODULE_FIRMWARE("amdgpu/fiji_rlc.bin");
+
 static const struct amdgpu_gds_reg_offset amdgpu_gds_reg_offset[] =
 {
{mmGDS_VMID0_BASE, mmGDS_VMID0_SIZE, mmGDS_GWS_VMID0, mmGDS_OA_VMID0},
@@ -217,6 +224,71 @@ static const u32 tonga_mgcg_cgcg_init[] =
mmCP_MEM_SLP_CNTL, 0x0001, 0x0001,
 };

+static const u32 fiji_golden_common_all[] =
+{
+   mmGRBM_GFX_INDEX, 0x, 0xe000,
+   mmPA_SC_RASTER_CONFIG, 0x, 0x3a00161a,
+   mmPA_SC_RASTER_CONFIG_1, 0x, 0x002e,
+   mmGB_ADDR_CONFIG, 0x, 0x12011003,
+   mmSPI_RESOURCE_RESERVE_CU_0, 0x, 0x0800,
+   mmSPI_RESOURCE_RESERVE_CU_1, 0x, 0x0800,
+   mmSPI_RESOURCE_RESERVE_EN_CU_0, 0x, 0x7FBF,
+   mmSPI_RESOURCE_RESERVE_EN_CU_1, 0x, 0x7FAF
+};
+
+static const u32 golden_settings_fiji_a10[] =
+{
+   mmCB_HW_CONTROL_3, 0x01ff, 0x0040,
+   mmDB_DEBUG2, 0xf00f, 0x0400,
+   mmPA_SC_ENHANCE, 0x, 0x2001,
+   mmPA_SC_FIFO_DEPTH_CNTL, 0x03ff, 0x0100,
+   mmPA_SC_LINE_STIPPLE_STATE, 0xff0f, 0x,
+   mmTA_CNTL_AUX, 0x000f000f, 0x000b,
+   mmTCC_CTRL, 0x0010, 0xf30fff7f,
+   mmTCP_ADDR_CONFIG, 0x03ff, 0x00ff,
+   mmTCP_CHAN_STEER_HI, 0x, 0x7d6cf5e4,
+   mmTCP_CHAN_STEER_LO, 0x, 0x3928b1a0,
+};
+
+static const u32 fiji_mgcg_cgcg_init[] =
+{
+   mmRLC_CGTT_MGCG_OVERRIDE, 0x, 0xffc0,
+   mmGRBM_GFX_INDEX, 0x, 0xe000,
+   mmCB_CGTT_SCLK_CTRL, 0x, 0x0100,
+   mmCGTT_BCI_CLK_CTRL, 0x, 0x0100,
+   mmCGTT_CP_CLK_CTRL, 0x, 0x0100,
+   mmCGTT_CPC_CLK_CTRL, 0x, 0x0100,
+   mmCGTT_CPF_CLK_CTRL, 0x, 0x4100,
+   mmCGTT_GDS_CLK_CTRL, 0x, 0x0100,
+   mmCGTT_IA_CLK_CTRL, 0x, 0x06000100,
+   mmCGTT_PA_CLK_CTRL, 0x, 0x0100,
+   mmCGTT_WD_CLK_CTRL, 0x, 0x06000100,
+   mmCGTT_PC_CLK_CTRL, 0x, 0x0100,
+   mmCGTT_RLC_CLK_CTRL, 0x, 0x0100,
+   mmCGTT_SC_CLK_CTRL, 0x, 0x0100,
+   mmCGTT_SPI_CLK_CTRL, 0x, 0x0100,
+   mmCGTT_SQ_CLK_CTRL, 0x, 0x0100,
+   mmCGTT_SQG_CLK_CTRL, 0x, 0x0100,
+   mmCGTT_SX_CLK_CTRL0, 0x, 0x0100,
+   mmCGTT_SX_CLK_CTRL1, 0x, 0x0100,
+   mmCGTT_SX_CLK_CTRL2, 0x, 0x0100,
+   mmCGTT_SX_CLK_CTRL3, 0x, 0x0100,
+   mmCGTT_SX_CLK_CTRL4, 0x, 0x0100,
+   mmCGTT_TCI_CLK_CTRL, 0x, 0x0100,
+   mmCGTT_TCP_CLK_CTRL, 0x, 0x0100,
+   mmCGTT_VGT_CLK_CTRL, 0x, 0x06000100,
+   mmDB_CGTT_CLK_CTRL_0, 0x, 0x0100,
+   mmTA_CGTT_CTRL, 0x, 0x0100,
+   mmTCA_CGTT_SCLK_CTRL, 0x, 0x0100,
+   mmTCC_CGTT_SCLK_CTRL, 0x, 0x0100,
+   mmTD_CGTT_CTRL, 0x, 0x0100,
+   mmGRBM_GFX_INDEX, 0x, 0xe000,
+   mmCGTS_SM_CTRL_REG, 0x, 0x96e00200,
+   mmCP_RB_WPTR_POLL_CNTL, 0x, 0x00900100,
+   mmRLC_CGCG_CGLS_CTRL, 0x, 0x0020003c,
+   mmCP_MEM_SLP_CNTL, 0x0001, 0x0001,
+};
+
 static const u32 golden_settings_iceland_a11[] =
 {
mmCB_HW_CONTROL_3, 0x0040, 0x0040,
@@ -439,6 +511,18 @@ static void gfx_v8_0_init_golden_registers(struct 
amdgpu_device *adev)
 iceland_golden_common_all,
 (const 
u32)ARRAY_SIZE(iceland_golden_common_all));
break;
+   case CHIP_FIJI:
+   amdgpu_program_register_sequence(adev,
+fiji_mgcg_cgcg_init,
+(const 
u32)ARRAY_SIZE(fiji_mgcg_cgcg_init));
+   amdgpu_program_register_sequence(adev,
+golden_settings_fiji_a10,
+(const 

[PATCH 06/11] drm/amdgpu: Add Fiji support to the DCE 10.0 IP module (v2)

[Alex Deucher]

From: David Zhang 

v2: agd5f: fix up XDMA golden settings

Signed-off-by: David Zhang 
Reviewed-by: Alex Deucher 
Reviewed-by: Jammy Zhou 
Reviewed-by: Christian K?nig 
---
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 23 +++
 drivers/gpu/drm/amd/amdgpu/vi.c|  7 +++
 2 files changed, 30 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
index a72254a..4b255ac 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
@@ -126,9 +126,31 @@ static const u32 tonga_mgcg_cgcg_init[] =
mmXDMA_MEM_POWER_CNTL, 0x0101, 0x,
 };

+static const u32 golden_settings_fiji_a10[] =
+{
+   mmDCI_CLK_CNTL, 0x0080, 0x,
+   mmFBC_DEBUG_COMP, 0x00f0, 0x0070,
+   mmFBC_MISC, 0x1f311fff, 0x1230,
+   mmHDMI_CONTROL, 0x31000111, 0x0011,
+};
+
+static const u32 fiji_mgcg_cgcg_init[] =
+{
+   mmXDMA_CLOCK_GATING_CNTL, 0x, 0x0100,
+   mmXDMA_MEM_POWER_CNTL, 0x0101, 0x,
+};
+
 static void dce_v10_0_init_golden_registers(struct amdgpu_device *adev)
 {
switch (adev->asic_type) {
+   case CHIP_FIJI:
+   amdgpu_program_register_sequence(adev,
+fiji_mgcg_cgcg_init,
+(const 
u32)ARRAY_SIZE(fiji_mgcg_cgcg_init));
+   amdgpu_program_register_sequence(adev,
+golden_settings_fiji_a10,
+(const 
u32)ARRAY_SIZE(golden_settings_fiji_a10));
+   break;
case CHIP_TONGA:
amdgpu_program_register_sequence(adev,
 tonga_mgcg_cgcg_init,
@@ -2888,6 +2910,7 @@ static int dce_v10_0_early_init(void *handle)
dce_v10_0_set_irq_funcs(adev);

switch (adev->asic_type) {
+   case CHIP_FIJI:
case CHIP_TONGA:
adev->mode_info.num_crtc = 6; /* XXX 7??? */
adev->mode_info.num_hpd = 6;
diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c b/drivers/gpu/drm/amd/amdgpu/vi.c
index 0788e5c..2550ecf 100644
--- a/drivers/gpu/drm/amd/amdgpu/vi.c
+++ b/drivers/gpu/drm/amd/amdgpu/vi.c
@@ -1199,6 +1199,13 @@ static const struct amdgpu_ip_block_version 
fiji_ip_blocks[] =
.rev = 0,
.funcs = _dpm_ip_funcs,
},
+   {
+   .type = AMD_IP_BLOCK_TYPE_DCE,
+   .major = 10,
+   .minor = 1,
+   .rev = 0,
+   .funcs = _v10_0_ip_funcs,
+   },
 };

 static const struct amdgpu_ip_block_version cz_ip_blocks[] =
-- 
1.8.3.1

[PATCH 05/11] drm/amdgpu: Add Fiji support to SMC and DPM (v2)

[Alex Deucher]

From: David Zhang 

v2: agd5f: prepare for release

Signed-off-by: David Zhang 
Reviewed-by: Alex Deucher 
Reviewed-by: Jammy Zhou 
Reviewed-by: Christian K?nig 
---
 drivers/gpu/drm/amd/amdgpu/Makefile  |   1 +
 drivers/gpu/drm/amd/amdgpu/fiji_dpm.c| 181 +++
 drivers/gpu/drm/amd/amdgpu/fiji_ppsmc.h  | 182 +++
 drivers/gpu/drm/amd/amdgpu/fiji_smc.c| 853 +++
 drivers/gpu/drm/amd/amdgpu/fiji_smumgr.h |  42 ++
 drivers/gpu/drm/amd/amdgpu/vi.c  |   7 +
 drivers/gpu/drm/amd/amdgpu/vi_dpm.h  |   2 +-
 7 files changed, 1267 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/amd/amdgpu/fiji_dpm.c
 create mode 100644 drivers/gpu/drm/amd/amdgpu/fiji_ppsmc.h
 create mode 100644 drivers/gpu/drm/amd/amdgpu/fiji_smc.c
 create mode 100644 drivers/gpu/drm/amd/amdgpu/fiji_smumgr.h

diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile 
b/drivers/gpu/drm/amd/amdgpu/Makefile
index ad44e11..0c2f998 100644
--- a/drivers/gpu/drm/amd/amdgpu/Makefile
+++ b/drivers/gpu/drm/amd/amdgpu/Makefile
@@ -54,6 +54,7 @@ amdgpu-y += \
amdgpu_dpm.o \
cz_smc.o cz_dpm.o \
tonga_smc.o tonga_dpm.o \
+   fiji_smc.o fiji_dpm.o \
iceland_smc.o iceland_dpm.o

 # add DCE block
diff --git a/drivers/gpu/drm/amd/amdgpu/fiji_dpm.c 
b/drivers/gpu/drm/amd/amdgpu/fiji_dpm.c
new file mode 100644
index 000..8f9845d
--- /dev/null
+++ b/drivers/gpu/drm/amd/amdgpu/fiji_dpm.c
@@ -0,0 +1,181 @@
+/*
+ * Copyright 2014 Advanced Micro Devices, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ */
+
+#include 
+#include "drmP.h"
+#include "amdgpu.h"
+#include "fiji_smumgr.h"
+
+MODULE_FIRMWARE("amdgpu/fiji_smc.bin");
+
+static void fiji_dpm_set_funcs(struct amdgpu_device *adev);
+
+static int fiji_dpm_early_init(void *handle)
+{
+   struct amdgpu_device *adev = (struct amdgpu_device *)handle;
+
+   fiji_dpm_set_funcs(adev);
+
+   return 0;
+}
+
+static int fiji_dpm_init_microcode(struct amdgpu_device *adev)
+{
+   char fw_name[30] = "amdgpu/fiji_smc.bin";
+   int err;
+
+   err = request_firmware(>pm.fw, fw_name, adev->dev);
+   if (err)
+   goto out;
+   err = amdgpu_ucode_validate(adev->pm.fw);
+
+out:
+   if (err) {
+   DRM_ERROR("Failed to load firmware \"%s\"", fw_name);
+   release_firmware(adev->pm.fw);
+   adev->pm.fw = NULL;
+   }
+   return err;
+}
+
+static int fiji_dpm_sw_init(void *handle)
+{
+   int ret;
+   struct amdgpu_device *adev = (struct amdgpu_device *)handle;
+
+   ret = fiji_dpm_init_microcode(adev);
+   if (ret)
+   return ret;
+
+   return 0;
+}
+
+static int fiji_dpm_sw_fini(void *handle)
+{
+   return 0;
+}
+
+static int fiji_dpm_hw_init(void *handle)
+{
+   int ret;
+   struct amdgpu_device *adev = (struct amdgpu_device *)handle;
+
+   mutex_lock(>pm.mutex);
+
+   ret = fiji_smu_init(adev);
+   if (ret) {
+   DRM_ERROR("SMU initialization failed\n");
+   goto fail;
+   }
+
+   ret = fiji_smu_start(adev);
+   if (ret) {
+   DRM_ERROR("SMU start failed\n");
+   goto fail;
+   }
+
+   mutex_unlock(>pm.mutex);
+   return 0;
+
+fail:
+   adev->firmware.smu_load = false;
+   mutex_unlock(>pm.mutex);
+   return -EINVAL;
+}
+
+static int fiji_dpm_hw_fini(void *handle)
+{
+   struct amdgpu_device *adev = (struct amdgpu_device *)handle;
+   mutex_lock(>pm.mutex);
+   fiji_smu_fini(adev);
+   mutex_unlock(>pm.mutex);
+   return 0;
+}
+
+static int fiji_dpm_suspend(void *handle)
+{
+   struct amdgpu_device *adev = (struct amdgpu_device *)handle;
+
+   fiji_dpm_hw_fini(adev);
+
+   return 0;
+}
+
+static int fiji_dpm_resume(void *handle)
+{
+   struct amdgpu_device *adev = (struct amdgpu_device *)handle;
+
+   

[PATCH 04/11] drm/amdgpu: Add Fiji smu 7.1.3 headers (v2)

[Alex Deucher]

From: David Zhang 

v2: agd5f: prepare for release

Signed-off-by: David Zhang 
Reviewed-by: Alex Deucher 
Reviewed-by: Jammy Zhou 
Reviewed-by: Christian K?nig 
---
 .../gpu/drm/amd/include/asic_reg/smu/smu_7_1_3_d.h | 1246 
 .../drm/amd/include/asic_reg/smu/smu_7_1_3_enum.h  | 1282 +
 .../amd/include/asic_reg/smu/smu_7_1_3_sh_mask.h   | 6080 
 3 files changed, 8608 insertions(+)
 create mode 100644 drivers/gpu/drm/amd/include/asic_reg/smu/smu_7_1_3_d.h
 create mode 100644 drivers/gpu/drm/amd/include/asic_reg/smu/smu_7_1_3_enum.h
 create mode 100644 drivers/gpu/drm/amd/include/asic_reg/smu/smu_7_1_3_sh_mask.h

diff --git a/drivers/gpu/drm/amd/include/asic_reg/smu/smu_7_1_3_d.h 
b/drivers/gpu/drm/amd/include/asic_reg/smu/smu_7_1_3_d.h
new file mode 100644
index 000..44b1855
--- /dev/null
+++ b/drivers/gpu/drm/amd/include/asic_reg/smu/smu_7_1_3_d.h
@@ -0,0 +1,1246 @@
+/*
+ * SMU_7_1_3 Register documentation
+ *
+ * Copyright (C) 2014  Advanced Micro Devices, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included
+ * in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
+ * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 
LIABILITY, WHETHER IN
+ * AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#ifndef SMU_7_1_3_D_H
+#define SMU_7_1_3_D_H
+
+#define mmGCK_SMC_IND_INDEX
 0x80
+#define mmGCK0_GCK_SMC_IND_INDEX   
 0x80
+#define mmGCK1_GCK_SMC_IND_INDEX   
 0x82
+#define mmGCK2_GCK_SMC_IND_INDEX   
 0x84
+#define mmGCK3_GCK_SMC_IND_INDEX   
 0x86
+#define mmGCK_SMC_IND_DATA 
 0x81
+#define mmGCK0_GCK_SMC_IND_DATA
 0x81
+#define mmGCK1_GCK_SMC_IND_DATA
 0x83
+#define mmGCK2_GCK_SMC_IND_DATA
 0x85
+#define mmGCK3_GCK_SMC_IND_DATA
 0x87
+#define ixGCK_MCLK_FUSES   
 0xc058
+#define ixCG_DCLK_CNTL 
 0xc050009c
+#define ixCG_DCLK_STATUS   
 0xc05000a0
+#define ixCG_VCLK_CNTL 
 0xc05000a4
+#define ixCG_VCLK_STATUS   
 0xc05000a8
+#define ixCG_ECLK_CNTL 
 0xc05000ac
+#define ixCG_ECLK_STATUS   
 0xc05000b0
+#define ixCG_ACLK_CNTL 
 0xc05000dc
+#define ixCG_MCLK_CNTL 
 0xc0500120
+#define ixCG_MCLK_STATUS   
 0xc0500124
+#define ixGCK_DFS_BYPASS_CNTL  
 0xc0500118
+#define ixCG_SPLL_FUNC_CNTL
 0xc0500140
+#define ixCG_SPLL_FUNC_CNTL_2  
 0xc0500144
+#define ixCG_SPLL_FUNC_CNTL_3  
 0xc0500148
+#define ixCG_SPLL_FUNC_CNTL_4  
 0xc050014c
+#define ixCG_SPLL_FUNC_CNTL_5  
 0xc0500150
+#define ixCG_SPLL_FUNC_CNTL_6  
 0xc0500154
+#define ixCG_SPLL_FUNC_CNTL_7  
 0xc0500158
+#define ixSPLL_CNTL_MODE   
 0xc0500160
+#define ixCG_SPLL_SPREAD_SPECTRUM  
 0xc0500164
+#define ixCG_SPLL_SPREAD_SPECTRUM_2
 0xc0500168

[PATCH 03/11] drm/amdgpu: Add Fiji support to IH module

[Alex Deucher]

From: David Zhang 

Signed-off-by: David Zhang 
Reviewed-by: Alex Deucher 
Reviewed-by: Jammy Zhou 
Reviewed-by: Christian K?nig 
---
 drivers/gpu/drm/amd/amdgpu/vi.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c b/drivers/gpu/drm/amd/amdgpu/vi.c
index b9d37d5..2677667 100644
--- a/drivers/gpu/drm/amd/amdgpu/vi.c
+++ b/drivers/gpu/drm/amd/amdgpu/vi.c
@@ -1185,6 +1185,13 @@ static const struct amdgpu_ip_block_version 
fiji_ip_blocks[] =
.rev = 0,
.funcs = _v8_0_ip_funcs,
},
+   {
+   .type = AMD_IP_BLOCK_TYPE_IH,
+   .major = 3,
+   .minor = 0,
+   .rev = 0,
+   .funcs = _ih_ip_funcs,
+   },
 };

 static const struct amdgpu_ip_block_version cz_ip_blocks[] =
-- 
1.8.3.1

[PATCH 02/11] drm/amdgpu: Add Fiji support to the GMC 8.5 IP module

[Alex Deucher]

From: David Zhang 

Signed-off-by: David Zhang 
Reviewed-by: Alex Deucher 
Reviewed-by: Jammy Zhou 
Reviewed-by: Christian K?nig 
---
 drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 25 +
 drivers/gpu/drm/amd/amdgpu/vi.c   |  9 -
 2 files changed, 33 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
index 3b54ed8..78109b7 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
@@ -44,6 +44,7 @@ static void gmc_v8_0_set_irq_funcs(struct amdgpu_device 
*adev);

 MODULE_FIRMWARE("amdgpu/topaz_mc.bin");
 MODULE_FIRMWARE("amdgpu/tonga_mc.bin");
+MODULE_FIRMWARE("amdgpu/fiji_mc.bin");

 static const u32 golden_settings_tonga_a11[] =
 {
@@ -61,6 +62,19 @@ static const u32 tonga_mgcg_cgcg_init[] =
mmMC_MEM_POWER_LS, 0x, 0x0104
 };

+static const u32 golden_settings_fiji_a10[] =
+{
+   mmVM_PRT_APERTURE0_LOW_ADDR, 0x0fff, 0x0fff,
+   mmVM_PRT_APERTURE1_LOW_ADDR, 0x0fff, 0x0fff,
+   mmVM_PRT_APERTURE2_LOW_ADDR, 0x0fff, 0x0fff,
+   mmVM_PRT_APERTURE3_LOW_ADDR, 0x0fff, 0x0fff,
+};
+
+static const u32 fiji_mgcg_cgcg_init[] =
+{
+   mmMC_MEM_POWER_LS, 0x, 0x0104
+};
+
 static const u32 golden_settings_iceland_a11[] =
 {
mmVM_PRT_APERTURE0_LOW_ADDR, 0x0fff, 0x0fff,
@@ -90,6 +104,14 @@ static void gmc_v8_0_init_golden_registers(struct 
amdgpu_device *adev)
 golden_settings_iceland_a11,
 (const 
u32)ARRAY_SIZE(golden_settings_iceland_a11));
break;
+   case CHIP_FIJI:
+   amdgpu_program_register_sequence(adev,
+fiji_mgcg_cgcg_init,
+(const 
u32)ARRAY_SIZE(fiji_mgcg_cgcg_init));
+   amdgpu_program_register_sequence(adev,
+golden_settings_fiji_a10,
+(const 
u32)ARRAY_SIZE(golden_settings_fiji_a10));
+   break;
case CHIP_TONGA:
amdgpu_program_register_sequence(adev,
 tonga_mgcg_cgcg_init,
@@ -202,6 +224,9 @@ static int gmc_v8_0_init_microcode(struct amdgpu_device 
*adev)
case CHIP_TONGA:
chip_name = "tonga";
break;
+   case CHIP_FIJI:
+   chip_name = "fiji";
+   break;
case CHIP_CARRIZO:
return 0;
default: BUG();
diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c b/drivers/gpu/drm/amd/amdgpu/vi.c
index 1a08cd0..b9d37d5 100644
--- a/drivers/gpu/drm/amd/amdgpu/vi.c
+++ b/drivers/gpu/drm/amd/amdgpu/vi.c
@@ -1177,7 +1177,14 @@ static const struct amdgpu_ip_block_version 
fiji_ip_blocks[] =
.minor = 0,
.rev = 0,
.funcs = _common_ip_funcs,
-   }
+   },
+   {
+   .type = AMD_IP_BLOCK_TYPE_GMC,
+   .major = 8,
+   .minor = 5,
+   .rev = 0,
+   .funcs = _v8_0_ip_funcs,
+   },
 };

 static const struct amdgpu_ip_block_version cz_ip_blocks[] =
-- 
1.8.3.1

[PATCH 01/11] drm/amdgpu: Add Fiji DID 0x7300 common support

[Alex Deucher]

From: David Zhang 

Signed-off-by: David Zhang 
Reviewed-by: Alex Deucher 
Reviewed-by: Jammy Zhou 
Reviewed-by: Christian K?nig 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  2 ++
 drivers/gpu/drm/amd/amdgpu/vi.c| 34 ++
 drivers/gpu/drm/amd/include/amd_shared.h   |  1 +
 3 files changed, 37 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 9538d64..3ade6c3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -55,6 +55,7 @@ static const char *amdgpu_asic_name[] = {
"MULLINS",
"TOPAZ",
"TONGA",
+   "FIJI",
"CARRIZO",
"LAST",
 };
@@ -1160,6 +1161,7 @@ static int amdgpu_early_init(struct amdgpu_device *adev)
switch (adev->asic_type) {
case CHIP_TOPAZ:
case CHIP_TONGA:
+   case CHIP_FIJI:
case CHIP_CARRIZO:
if (adev->asic_type == CHIP_CARRIZO)
adev->family = AMDGPU_FAMILY_CZ;
diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c b/drivers/gpu/drm/amd/amdgpu/vi.c
index b4bc84c..1a08cd0 100644
--- a/drivers/gpu/drm/amd/amdgpu/vi.c
+++ b/drivers/gpu/drm/amd/amdgpu/vi.c
@@ -207,6 +207,17 @@ static const u32 tonga_mgcg_cgcg_init[] =
mmHDP_XDP_CGTT_BLK_CTRL, 0xcfff, 0x0104,
 };

+static const u32 fiji_mgcg_cgcg_init[] =
+{
+   mmCGTT_DRM_CLK_CTRL0, 0x, 0x00600100,
+   mmPCIE_INDEX, 0x, 0x0140001c,
+   mmPCIE_DATA, 0x000f, 0x,
+   mmSMC_IND_INDEX_4, 0x, 0xC06C,
+   mmSMC_IND_DATA_4, 0xcfff, 0x0100,
+   mmCGTT_DRM_CLK_CTRL0, 0xff000fff, 0x0100,
+   mmHDP_XDP_CGTT_BLK_CTRL, 0xcfff, 0x0104,
+};
+
 static const u32 iceland_mgcg_cgcg_init[] =
 {
mmPCIE_INDEX, 0x, ixPCIE_CNTL2,
@@ -236,6 +247,11 @@ static void vi_init_golden_registers(struct amdgpu_device 
*adev)
 iceland_mgcg_cgcg_init,
 (const 
u32)ARRAY_SIZE(iceland_mgcg_cgcg_init));
break;
+   case CHIP_FIJI:
+   amdgpu_program_register_sequence(adev,
+fiji_mgcg_cgcg_init,
+(const 
u32)ARRAY_SIZE(fiji_mgcg_cgcg_init));
+   break;
case CHIP_TONGA:
amdgpu_program_register_sequence(adev,
 tonga_mgcg_cgcg_init,
@@ -473,6 +489,7 @@ static int vi_read_register(struct amdgpu_device *adev, u32 
se_num,
asic_register_table = tonga_allowed_read_registers;
size = ARRAY_SIZE(tonga_allowed_read_registers);
break;
+   case CHIP_FIJI:
case CHIP_TONGA:
case CHIP_CARRIZO:
asic_register_table = cz_allowed_read_registers;
@@ -1151,6 +1168,18 @@ static const struct amdgpu_ip_block_version 
tonga_ip_blocks[] =
},
 };

+static const struct amdgpu_ip_block_version fiji_ip_blocks[] =
+{
+   /* ORDER MATTERS! */
+   {
+   .type = AMD_IP_BLOCK_TYPE_COMMON,
+   .major = 2,
+   .minor = 0,
+   .rev = 0,
+   .funcs = _common_ip_funcs,
+   }
+};
+
 static const struct amdgpu_ip_block_version cz_ip_blocks[] =
 {
/* ORDER MATTERS! */
@@ -1318,6 +1347,10 @@ int vi_set_ip_blocks(struct amdgpu_device *adev)
adev->ip_blocks = topaz_ip_blocks;
adev->num_ip_blocks = ARRAY_SIZE(topaz_ip_blocks);
break;
+   case CHIP_FIJI:
+   adev->ip_blocks = fiji_ip_blocks;
+   adev->num_ip_blocks = ARRAY_SIZE(fiji_ip_blocks);
+   break;
case CHIP_TONGA:
adev->ip_blocks = tonga_ip_blocks;
adev->num_ip_blocks = ARRAY_SIZE(tonga_ip_blocks);
@@ -1405,6 +1438,7 @@ static int vi_common_early_init(void *handle)
if (amdgpu_smc_load_fw && smc_enabled)
adev->firmware.smu_load = true;
break;
+   case CHIP_FIJI:
case CHIP_TONGA:
adev->has_uvd = true;
adev->cg_flags = 0;
diff --git a/drivers/gpu/drm/amd/include/amd_shared.h 
b/drivers/gpu/drm/amd/include/amd_shared.h
index 31d194a..54bf96a 100644
--- a/drivers/gpu/drm/amd/include/amd_shared.h
+++ b/drivers/gpu/drm/amd/include/amd_shared.h
@@ -45,6 +45,7 @@ enum amd_asic_type {
CHIP_MULLINS,
CHIP_TOPAZ,
CHIP_TONGA,
+   CHIP_FIJI,
CHIP_CARRIZO,
CHIP_LAST,
 };
-- 
1.8.3.1

[PATCH 00/11] Add Fiji Support

[Alex Deucher]

This patch set adds Fiji support to the open source amdgpu
driver.  The relevant mesa and ddx changes have also been
sent out the their respective mailing lists.  Support for
Fiji is complete (GFX, SDMA, UVD, VCE, etc.) except for
power management.  Power management for dGPUs is still
in progress an will be released in the future.

Alex Deucher (2):
  drm/amdgpu: Add Fiji support to the GFX 8.0 IP module (v2)
  drm/amdgpu: add support for VCE 3.x on Fiji

David Zhang (9):
  drm/amdgpu: Add Fiji DID 0x7300 common support
  drm/amdgpu: Add Fiji support to the GMC 8.5 IP module
  drm/amdgpu: Add Fiji support to IH module
  drm/amdgpu: Add Fiji smu 7.1.3 headers (v2)
  drm/amdgpu: Add Fiji support to SMC and DPM (v2)
  drm/amdgpu: Add Fiji support to the DCE 10.0 IP module (v2)
  drm/amdgpu: Add Fiji support to the SDMA 3.0 IP module
  drm/amdgpu: Add Fiji support to the UVD 6.0 IP module
  drm/amdgpu: Enable the Fiji DID 0x7300 support

 drivers/gpu/drm/amd/amdgpu/Makefile|1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |2 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|2 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c|5 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c|5 +
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c |   23 +
 drivers/gpu/drm/amd/amdgpu/fiji_dpm.c  |  181 +
 drivers/gpu/drm/amd/amdgpu/fiji_ppsmc.h|  182 +
 drivers/gpu/drm/amd/amdgpu/fiji_smc.c  |  853 +++
 drivers/gpu/drm/amd/amdgpu/fiji_smumgr.h   |   42 +
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c  |  109 +-
 drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c  |   25 +
 drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c |   31 +
 drivers/gpu/drm/amd/amdgpu/vce_v3_0.c  |7 +
 drivers/gpu/drm/amd/amdgpu/vi.c|   90 +
 drivers/gpu/drm/amd/amdgpu/vi_dpm.h|2 +-
 drivers/gpu/drm/amd/include/amd_shared.h   |1 +
 .../gpu/drm/amd/include/asic_reg/smu/smu_7_1_3_d.h | 1246 
 .../drm/amd/include/asic_reg/smu/smu_7_1_3_enum.h  | 1282 +
 .../amd/include/asic_reg/smu/smu_7_1_3_sh_mask.h   | 6080 
 20 files changed, 10167 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/amd/amdgpu/fiji_dpm.c
 create mode 100644 drivers/gpu/drm/amd/amdgpu/fiji_ppsmc.h
 create mode 100644 drivers/gpu/drm/amd/amdgpu/fiji_smc.c
 create mode 100644 drivers/gpu/drm/amd/amdgpu/fiji_smumgr.h
 create mode 100644 drivers/gpu/drm/amd/include/asic_reg/smu/smu_7_1_3_d.h
 create mode 100644 drivers/gpu/drm/amd/include/asic_reg/smu/smu_7_1_3_enum.h
 create mode 100644 drivers/gpu/drm/amd/include/asic_reg/smu/smu_7_1_3_sh_mask.h

-- 
1.8.3.1

[PATCH] scripts/kernel-doc Allow struct arguments documentation in struct body

[Danilo Cesar Lemes de Paula]

On 08/03/2015 12:59 PM, Randy Dunlap wrote:
> On 07/31/15 14:06, Danilo Cesar Lemes de Paula wrote:
>> Describing arguments at top of a struct definition works fine
>> for small/medium size structs, but it definitely doesn't work well
>> for struct with a huge list of elements.
>>
>> Keeping the arguments list inside the struct body makes it easier
>> to maintain the documentation.
>> ie:
>> /**
>>  * struct my_struct - short description
>>  * @a: first member
>>  * @b: second member
>>  *
>>  * Longer description
>>  */
>> struct my_struct {
>> int a;
>> int b;
>> /**
>>  * @c: This is longer description of C
>>  *
>>  * You can use paragraphs to describe arguments
>>  * using this method.
>>  */
>> int c;
>> };
>>
>> This patch allows the use of this kind of syntax. Only one argument
>> per comment and user can use how many paragraphs he needs. It should
>> start with /**, which is already being used by kernel-doc. If those
>> comment doesn't follow those rules, it will be ignored.
>>
>> Signed-off-by: Danilo Cesar Lemes de Paula 
>> Cc: Randy Dunlap 
>> Cc: Daniel Vetter 
>> Cc: Laurent Pinchart 
>> Cc: Jonathan Corbet 
>> Cc: Herbert Xu 
>> Cc: Stephan Mueller 
>> Cc: Michal Marek 
>> Cc: linux-kernel at vger.kernel.org
>> Cc: linux-doc at vger.kernel.org
>> Cc: intel-gfx 
>> Cc: dri-devel 
>> ---
>>  scripts/kernel-doc | 80 
>> --
>>  1 file changed, 78 insertions(+), 2 deletions(-)
>>
>> diff --git a/scripts/kernel-doc b/scripts/kernel-doc
>> index 9922e66..9bfa8b9 100755
>> --- a/scripts/kernel-doc
>> +++ b/scripts/kernel-doc
>> @@ -133,6 +133,30 @@ use strict;
>>  #
>>  # All descriptions can be multiline, except the short function description.
>>  #
>> +# For really longs structs, you can also describe arguments inside the
>> +# body of the struct.
>> +# eg.
>> +# /**
>> +#  * struct my_struct - short description
>> +#  * @a: first member
>> +#  * @b: second member
>> +#  *
>> +#  * Longer description
>> +#  */
>> +# struct my_struct {
>> +# int a;
>> +# int b;
>> +# /**
>> +#  * @c: This is longer description of C
>> +#  *
>> +#  * You can use paragraphs to describe arguments
>> +#  * using this method.
>> +#  */
>> +# int c;
>> +# };
>> +#
>> +# This should be use for arguments only.
> 
> used
> 
> What are "arguments" in this context?  do you mean struct fields or members?

Yes. I can change the text if you want to.

> 
>> +#
>>  # You can also add additional sections. When documenting kernel functions 
>> you
>>  # should document the "Context:" of the function, e.g. whether the functions
>>  # can be called form interrupts. Unlike other sections you can end it with 
>> an
>> @@ -287,9 +311,19 @@ my $lineprefix="";
>>  # 2 - scanning field start.
>>  # 3 - scanning prototype.
>>  # 4 - documentation block
>> +# 5 - gathering documentation outside main block
>>  my $state;
>>  my $in_doc_sect;
>>  
>> +# Split Doc State
>> +# 0 - Invalid (Before start or after finish)
>> +# 1 - Is started (the /** was found inside a struct)
>> +# 2 - The @parameter header was found, start accepting multi paragraph text.
>> +# 3 - Finished (the */ was found)
>> +# 4 - Error - Comment without header was found. Spit a warning as it's not
>> +# proper kernel-doc and ignore the rest.
>> +my $split_doc_state;
>> +
>>  #declaration types: can be
>>  # 'function', 'struct', 'union', 'enum', 'typedef'
>>  my $decl_type;
>> @@ -304,6 +338,9 @@ my $doc_decl = $doc_com . '(\w+)';
>>  my $doc_sect = $doc_com . '([' . $doc_special . ']?[\w\s]+):(.*)';
>>  my $doc_content = $doc_com_body . '(.*)';
>>  my $doc_block = $doc_com . 'DOC:\s*(.*)?';
>> +my $doc_split_start = '^\s*/\*\*\s*$';
>> +my $doc_split_sect = '\s*\*\s*(@[\w\s]+):(.*)';
>> +my $doc_split_end = '^\s*\*/\s*$';
>>  
>>  my %constants;
>>  my %parameterdescs;
>> @@ -2181,6 +2218,7 @@ sub reset_state {
>>  $prototype = "";
>>  
>>  $state = 0;
>> +$split_doc_state = 0;
>>  }
>>  
>>  sub tracepoint_munge($) {
>> @@ -2453,7 +2491,6 @@ sub process_file($) {
>>  }
>>  $section = $newsection;
>>  } elsif (/$doc_end/) {
>> -
>>  if (($contents ne "") && ($contents ne "\n")) {
>>  dump_section($file, $section, xml_escape($contents));
>>  $section = $section_default;
>> @@ -2494,8 +2531,47 @@ sub process_file($) {
>>  print STDERR "Warning(${file}:$.): bad line: $_";
>>  ++$warnings;
>>  }
>> +} elsif ($state == 5) { # scanning for split parameters
>> +
>> +# First line (state 1) needs to be a @parameter
>> +if ($split_doc_state == 1 && /$doc_split_sect/o) {
>> +$section = $1;
>> +$contents = $2;
>> +if ($contents ne "") {
>> +while ((substr($contents, 0, 1) eq " ") ||
>> +substr($contents, 0, 1) eq "\t") {
>> 

[PATCH v2] drm/i915: load driver even if debugfs fails

[Daniel Vetter]

On Mon, Aug 03, 2015 at 02:56:42PM +0530, Sudip Mukherjee wrote:
> On Thu, Jul 23, 2015 at 07:36:12PM +0530, Sudip Mukherjee wrote:
> > debugfs files are not necessary for the usual operation of the driver
> > and the device. No need to check for the return values from the debugfs
> > file creation. Even if one debugfs file fails to create we try with the
> > next debugfs file and ultimately return success always so that the
> > driver continues to load.

Does this even happen? I'm reluctant to merge patches without real-world
justification.
-Daniel

> > cleanup will clean all the created debugfs files as the list of file
> > that are created are maintained in minor->debugfs_list.
> > 
> > Cc: Chris Wilson 
> > Signed-off-by: Sudip Mukherjee 
> > ---
> A gentle ping.
> 
> regards
> sudip
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[REGRESSION] Re: i915 driver crashes on T540p if docking station attached

[Theodore Ts'o]

On Mon, Aug 03, 2015 at 05:27:29PM +0200, Daniel Vetter wrote:
> 
> Ok I updated fixes-stuff with just 2 patches which seem to be enough to
> fix it. Plus a patch to convert Linus' hack into something we can keep
> plus a drive-by WARNING fix in mst that got in the way for me.
> 
> Seems to work here in getting rid of the Oops. If this tests out for you
> too I'll send a pull to Linus.

I've just tried pulling in your updated fixes-stuff, and it avoids the
oops and allows external the monitor to work correctly.  However, I'm
still seeing a large number of drm/i915 related warning messages and
other kernel kvetching.

Thanks!!

- Ted

[4.084198] [drm] Initialized drm 1.1.0 20060810
[4.129576] [drm] Memory usable by graphics device = 2048M
[4.129616] [drm] Replacing VGA console driver
[4.130315] Console: switching to colour dummy device 80x25
[4.145332] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[4.145334] [drm] Driver supports precise vblank timestamp query.
[4.146184] vgaarb: device changed decodes: 
PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[4.163778] usbcore: registered new interface driver btusb
[4.170719] [ cut here ]
[4.170749] WARNING: CPU: 0 PID: 463 at 
/usr/projects/linux/linux/drivers/gpu/drm/i915/intel_pm.c:2339 
ilk_update_wm+0x71a/0xb27 [i915]()
[4.170751] WARN_ON(!r->enable)
[4.170752] Modules linked in:
[4.170754]  btusb btrtl btbcm btintel iwlmvm(+) bluetooth mac80211 iwlwifi 
snd_hda_intel i915(+) drm_kms_helper snd_hda_codec cfg80211 drm snd_hwdep 
lpc_ich snd_hda_core intel_gtt thinkpad_acpi tpm_tis nvram tpm 
intel_smartconnect uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core 
sch_fq_codel kvm_intel kvm ecryptfs parport_pc ppdev lp parport autofs4 btrfs 
xor hid_generic usbhid hid raid6_pq microcode rtsx_pci_sdmmc ehci_pci e1000e 
rtsx_pci ehci_hcd xhci_pci ptp mfd_core pps_core xhci_hcd
[4.170805] CPU: 0 PID: 463 Comm: systemd-udevd Not tainted 
4.2.0-rc5-14194-g130583b #18
[4.170807] Hardware name: LENOVO 20BECTO1WW/20BECTO1WW, BIOS GMET59WW (2.07 
) 02/12/2014
[4.170809]  0009 880403f0f4c8 8161aaee 
0006
[4.170814]  880403f0f518 880403f0f508 8107e5f0 
0006
[4.170818]  c05ade43 8800c8b7 8800c7f16000 
880405fb48b8
[4.170823] Call Trace:
[4.170829]  [] dump_stack+0x4c/0x65
[4.170833]  [] warn_slowpath_common+0xa1/0xbb
[4.170856]  [] ? ilk_update_wm+0x71a/0xb27 [i915]
[4.170859]  [] warn_slowpath_fmt+0x46/0x48
[4.170879]  [] ? ilk_compute_wm_maximums+0x43/0xa2 [i915]
[4.170899]  [] ilk_update_wm+0x71a/0xb27 [i915]
[4.170921]  [] intel_update_watermarks+0x1e/0x20 [i915]
[4.170957]  [] haswell_crtc_disable+0x270/0x2ae [i915]
[4.170989]  [] intel_crtc_control+0xa0/0xe1 [i915]
[4.171020]  [] intel_crtc_update_dpms+0x4d/0x5d [i915]
[4.171052]  [] intel_modeset_setup_hw_state+0x7b0/0xa90 
[i915]
[4.171081]  [] ? hsw_write64+0xcd/0xcd [i915]
[4.171113]  [] ? ilk_fbc_disable+0x29/0x69 [i915]
[4.171142]  [] intel_modeset_init+0x130d/0x14e3 [i915]
[4.171179]  [] i915_driver_load+0xf05/0x1139 [i915]
[4.171183]  [] ? mark_held_locks+0x56/0x6c
[4.171186]  [] ? _raw_spin_unlock_irqrestore+0x3f/0x4d
[4.171189]  [] ? trace_hardirqs_on_caller+0x171/0x18d
[4.171204]  [] drm_dev_register+0x84/0xfd [drm]
[4.171215]  [] drm_get_pci_dev+0x102/0x1bc [drm]
[4.171237]  [] i915_pci_probe+0x4f/0x51 [i915]
[4.171240]  [] pci_device_probe+0x74/0xd6
[4.171245]  [] ? driver_probe_device+0x387/0x387
[4.171248]  [] driver_probe_device+0x15f/0x387
[4.171250]  [] ? driver_probe_device+0x387/0x387
[4.171252]  [] __driver_attach+0x53/0x74
[4.171255]  [] bus_for_each_dev+0x6f/0x89
[4.171257]  [] driver_attach+0x1e/0x20
[4.171260]  [] bus_add_driver+0x140/0x238
[4.171263]  [] driver_register+0x8f/0xcc
[4.171266]  [] __pci_register_driver+0x5e/0x62
[4.171268]  [] ? 0xc069c000
[4.171278]  [] drm_pci_init+0x58/0xda [drm]
[4.171281]  [] ? 0xc069c000
[4.171301]  [] i915_init+0xa0/0xa8 [i915]
[4.171303]  [] ? 0xc069c000
[4.171307]  [] do_one_initcall+0x19a/0x1af
[4.171310]  [] ? do_init_module+0x28/0x1e3
[4.171313]  [] ? kmem_cache_alloc_trace+0xba/0xcc
[4.171315]  [] do_init_module+0x60/0x1e3
[4.171319]  [] load_module+0x1c42/0x2059
[4.171324]  [] SyS_finit_module+0x85/0x92
[4.171327]  [] entry_SYSCALL_64_fastpath+0x16/0x73
[4.171329] ---[ end trace 7eb514b89de5fc4a ]---
[4.171331] [ cut here ]
[4.171354] WARNING: CPU: 0 PID: 463 at 
/usr/projects/linux/linux/drivers/gpu/drm/i915/intel_pm.c:2339 
ilk_update_wm+0x71a/0xb27 [i915]()
[4.171355] WARN_ON(!r->enable)
[4.171357] Modules linked in:
[4.171358]  btusb 

linux-next: manual merge of the drm-misc tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm-misc tree got a conflict in:

  drivers/gpu/drm/drm_atomic_helper.c

between commit:

  27667f4744fc ("i915: temporary fix for DP MST docking station NULL pointer 
dereference")

from Linus' tree and commit:

  fc596660dd4e ("drm/atomic: add connectors_changed to separate it from 
mode_changed, v2")

from the drm-misc tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwellsfr at canb.auug.org.au

diff --cc drivers/gpu/drm/drm_atomic_helper.c
index 90065c226fe5,0b475fae067d..
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@@ -230,12 -230,10 +230,12 @@@ update_connector_routing(struct drm_ato
}

connector_state->best_encoder = new_encoder;
 -  idx = drm_crtc_index(connector_state->crtc);
 +  if (connector_state->crtc) {
 +  idx = drm_crtc_index(connector_state->crtc);

 -  crtc_state = state->crtc_states[idx];
 -  crtc_state->connectors_changed = true;
 +  crtc_state = state->crtc_states[idx];
-   crtc_state->mode_changed = true;
++  crtc_state->connectors_changed = true;
 +  }

DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] using [ENCODER:%d:%s] on 
[CRTC:%d]\n",
 connector->base.id,

[Bug 91534] r300 blocking GLX and EGL compositing in KWin (KDE Plasma 5.x)?

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

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

--- Comment #1 from Emil Velikov  ---
Hi Aaron,

We do have some fixes in mesa 10.6.x that never made it into 10.5 series. I
would give mesa 10.6.x a spin first.

I'm not a r300 dev myself so I cannot comment on the driver, although it
doesn't show any signs of issues. Here are some bits you might find
interesting:

- Seemingly the driver already exposes NPOT + OpenGL 2.1 (albeit some hardware
limitations, which should be handled by the driver).

- GLX does not always mean you'll get OpenGL, similar to EGL and OpenGLES. One
can mix and match depending on various factors.

In your case EGL + OpenGL is attempted but I'm not sure how to force gles.
Older versions had kwin_gles, which seems to be gone with the 5 series. Might
want to look into a way of forcing gles, and getting more verbose output on
kwin side.

-- 
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/20150803/6295279e/attachment.html>

[PATCH 2/5] drm/i2c: adv7511: Initial support for adv7533

[Archit Taneja]

On 07/28/2015 08:57 AM, Bjorn Andersson wrote:
> On Sun 26 Jul 23:16 PDT 2015, Archit Taneja wrote:
>
>> From: Lars-Peter Clausen 
>>
> [..]
>> diff --git a/drivers/gpu/drm/i2c/adv7511.c b/drivers/gpu/drm/i2c/adv7511.c
>
> [..]
>
>>
>> +static const struct of_device_id adv7511_of_ids[] = {
>> +{ .compatible = "adi,adv7511", .data = (void *) ADV7511 },
>> +{ .compatible = "adi,adv7511w", .data = (void *) ADV7511 },
>> +{ .compatible = "adi,adv7513", .data = (void *) ADV7511 },
>> +{ .compatible = "adi,adv7533", .data = (void *) ADV7533 },
>> +{ }
>> +};
>> +MODULE_DEVICE_TABLE(of, adv7511_of_ids);
>
> Please leave this at the bottom.
>
>> +
>>   static int adv7511_probe(struct i2c_client *i2c, const struct 
>> i2c_device_id *id)
>>   {
>>  struct adv7511_link_config link_config;
>> @@ -871,9 +938,22 @@ static int adv7511_probe(struct i2c_client *i2c, const 
>> struct i2c_device_id *id)
>>  adv7511->powered = false;
>>  adv7511->status = connector_status_disconnected;
>>
>> -ret = adv7511_parse_dt(dev->of_node, _config);
>> -if (ret)
>> -return ret;
>> +if (dev->of_node) {
>> +const struct of_device_id *of_id;
>> +
>> +of_id = of_match_node(adv7511_of_ids, dev->of_node);
>
> If you use of_device_get_match_data() instead you don't need to move the
> of_device_id table.

Thanks, will use this in future revisions.

Archit

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH] libdrm: Add framebuffer modifiers uapi

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Sync up with new kernel features as per commits:

e3eb3250d84ef97b766312345774367b6a310db8
93b81f5102a7cd270a305c2741b17c8d44bb0629
b5ff6e1637b683d5996ae11ac29afe406c0bee90
8c4f83fb1e8bf317e894f62d17a63c32b7a6b75e
570655b09b065d2fff1b8ab9bdb8308f4c5a05a3

Signed-off-by: Tvrtko Ursulin 
Cc: dri-devel at lists.freedesktop.org
Cc: Rob Clark 
Cc: Daniel Vetter 
---
 include/drm/drm.h|  1 +
 include/drm/drm_fourcc.h | 93 
 include/drm/drm_mode.h   | 11 +-
 3 files changed, 104 insertions(+), 1 deletion(-)

diff --git a/include/drm/drm.h b/include/drm/drm.h
index 167b7b81b0d0..a950b580cd11 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -816,6 +816,7 @@ struct drm_event_vblank {
 #define DRM_CAP_PRIME 0x5
 #define DRM_CAP_TIMESTAMP_MONOTONIC 0x6
 #define DRM_CAP_ASYNC_PAGE_FLIP 0x7
+#define DRM_CAP_ADDFB2_MODIFIERS   0x10

 #define DRM_PRIME_CAP_IMPORT 0x1
 #define DRM_PRIME_CAP_EXPORT 0x2
diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index 85facb0a17cf..63a80ca5ba39 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -127,4 +127,97 @@
 #define DRM_FORMAT_YUV444  fourcc_code('Y', 'U', '2', '4') /* 
non-subsampled Cb (1) and Cr (2) planes */
 #define DRM_FORMAT_YVU444  fourcc_code('Y', 'V', '2', '4') /* 
non-subsampled Cr (1) and Cb (2) planes */

+
+/*
+ * Format Modifiers:
+ *
+ * Format modifiers describe, typically, a re-ordering or modification
+ * of the data in a plane of an FB.  This can be used to express tiled/
+ * swizzled formats, or compression, or a combination of the two.
+ *
+ * The upper 8 bits of the format modifier are a vendor-id as assigned
+ * below.  The lower 56 bits are assigned as vendor sees fit.
+ */
+
+/* Vendor Ids: */
+#define DRM_FORMAT_MOD_NONE   0
+#define DRM_FORMAT_MOD_VENDOR_INTEL   0x01
+#define DRM_FORMAT_MOD_VENDOR_AMD 0x02
+#define DRM_FORMAT_MOD_VENDOR_NV  0x03
+#define DRM_FORMAT_MOD_VENDOR_SAMSUNG 0x04
+#define DRM_FORMAT_MOD_VENDOR_QCOM0x05
+/* add more to the end as needed */
+
+#define fourcc_mod_code(vendor, val) \
+   u64)DRM_FORMAT_MOD_VENDOR_## vendor) << 56) | (val & 
0x00ffULL))
+
+/*
+ * Format Modifier tokens:
+ *
+ * When adding a new token please document the layout with a code comment,
+ * similar to the fourcc codes above. drm_fourcc.h is considered the
+ * authoritative source for all of these.
+ */
+
+/* Intel framebuffer modifiers */
+
+/*
+ * Intel X-tiling layout
+ *
+ * This is a tiled layout using 4Kb tiles (except on gen2 where the tiles 2Kb)
+ * in row-major layout. Within the tile bytes are laid out row-major, with
+ * a platform-dependent stride. On top of that the memory can apply
+ * platform-depending swizzling of some higher address bits into bit6.
+ *
+ * This format is highly platforms specific and not useful for cross-driver
+ * sharing. It exists since on a given platform it does uniquely identify the
+ * layout in a simple way for i915-specific userspace.
+ */
+#define I915_FORMAT_MOD_X_TILEDfourcc_mod_code(INTEL, 1)
+
+/*
+ * Intel Y-tiling layout
+ *
+ * This is a tiled layout using 4Kb tiles (except on gen2 where the tiles 2Kb)
+ * in row-major layout. Within the tile bytes are laid out in OWORD (16 bytes)
+ * chunks column-major, with a platform-dependent height. On top of that the
+ * memory can apply platform-depending swizzling of some higher address bits
+ * into bit6.
+ *
+ * This format is highly platforms specific and not useful for cross-driver
+ * sharing. It exists since on a given platform it does uniquely identify the
+ * layout in a simple way for i915-specific userspace.
+ */
+#define I915_FORMAT_MOD_Y_TILEDfourcc_mod_code(INTEL, 2)
+
+/*
+ * Intel Yf-tiling layout
+ *
+ * This is a tiled layout using 4Kb tiles in row-major layout.
+ * Within the tile pixels are laid out in 16 256 byte units / sub-tiles which
+ * are arranged in four groups (two wide, two high) with column-major layout.
+ * Each group therefore consits out of four 256 byte units, which are also laid
+ * out as 2x2 column-major.
+ * 256 byte units are made out of four 64 byte blocks of pixels, producing
+ * either a square block or a 2:1 unit.
+ * 64 byte blocks of pixels contain four pixel rows of 16 bytes, where the 
width
+ * in pixel depends on the pixel depth.
+ */
+#define I915_FORMAT_MOD_Yf_TILED fourcc_mod_code(INTEL, 3)
+
+/*
+ * Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks
+ *
+ * Macroblocks are laid in a Z-shape, and each pixel data is following the
+ * standard NV12 style.
+ * As for NV12, an image is the result of two frame buffers: one for Y,
+ * one for the interleaved Cb/Cr components (1/2 the height of the Y buffer).
+ * Alignment requirements are (for each buffer):
+ * - multiple of 128 pixels for the width
+ * - multiple of  32 pixels for the height
+ *
+ * For more information: see 

[REGRESSION] Re: i915 driver crashes on T540p if docking station attached

[Linus Torvalds]

On Mon, Aug 3, 2015 at 9:25 AM, Theodore Ts'o  wrote:
>
> I've just tried pulling in your updated fixes-stuff, and it avoids the
> oops and allows external the monitor to work correctly.

Good. Have either of you tested the suspend/resume behavior? Is that fixed too?

>  However, I'm
> still seeing a large number of drm/i915 related warning messages and
> other kernel kvetching.

I suspect I can live with that for now. The lockdep one looks like
it's mainly an initialization issue, so you'd never get the actual
deadlock in practice, but it's obviously annoying.  The intel_pm.c one
I'll have to defer to the i915 people for..

I'll be travelling much of this week (flying to Finland tomorrow, back
on Sunday - yay, 30h in airplanes for three days on the ground, but
it's my dad's bday), and my internet will be sporadic. But I'll have a
laptop and be able to pull stuff every once in a while.

It would be good to have this one resolved, and I just need to worry
about the remaining VM problem..

   Linus

> [4.170749] WARNING: CPU: 0 PID: 463 at 
> drivers/gpu/drm/i915/intel_pm.c:2339 ilk_update_wm+0x71a/0xb27 [i915]()
> [4.170751] WARN_ON(!r->enable)

[PATCH] scripts/kernel-doc Allow struct arguments documentation in struct body

[Daniel Vetter]

On Sat, Aug 01, 2015 at 01:22:10PM +0200, Jonathan Corbet wrote:
> On Fri, 31 Jul 2015 18:06:45 -0300
> Danilo Cesar Lemes de Paula  wrote:
> 
> > Describing arguments at top of a struct definition works fine
> > for small/medium size structs, but it definitely doesn't work well
> > for struct with a huge list of elements.
> > 
> > Keeping the arguments list inside the struct body makes it easier
> > to maintain the documentation.
> 
> Interesting approach.  I think it could make sense, but I fear pushback
> from a subset of maintainers refusing to accept this mode.  I wonder what
> it would take to get a consensus on allowing these in-struct comments?

At least in drm we have a lot of such comments (as non-kerneldoc) right
above struct members to explain some details. Common examples are:
- locks, with a description of what they protect and maybe also how they
  nest.
- vfunc ops structs, with a per-function description of what each hook
  does.
- tricky stuff which can't be described in one sentence only.

So it's not just huge structs by number of members, but huge by number of
comment lines. Trying to stuff that all into the top kerneldoc comment
means that it's much harder to jump to the right comment, and it's also
easier to ignore the comments (since it e.g. won't show up in the diff
context).

The current approach at least in drm is to duplicate comments and that
just results in inconsistency.

> I'm wondering if we need a kernel summit session on commenting
> conventions, markdown-in-kerneldoc, etc?  Maybe I'll stick a proposal out
> there.

Might be useful, but I'm not sure how many people really would actively
work on improving the tooling. The only comment I've seen is to maybe use
gtkdoc, but that would be a pain since it's slightly incompatible with
kerneldoc.

And it's the improved tooling I really need for my long-term plan to get
solid docs for drm & drm/i915. Next step is to start building a proper doc
writer team to make all the bits we already have into a consistent hole
(and nag developers to fill in the areas still undocumented). For that
I've already pulled Danilo's patches into the drm-intel integration tree
and I plan to use them for any further drm kerneldoc I write since we
really need them.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 3/5] drm/i2c: adv7511: Refactor encoder slave functions

[Rob Clark]

On Mon, Aug 3, 2015 at 8:03 AM, Andrzej Hajda  wrote:
> Hi,
>
> On 07/31/2015 04:48 PM, Rob Clark wrote:
>> On Fri, Jul 31, 2015 at 8:58 AM, Boris Brezillon
>>  wrote:
>>> Hi Rob,
>>>
>>> On Fri, 31 Jul 2015 08:13:59 -0400
>>> Rob Clark  wrote:
>>>
>
> (...)
>
>>>
>>> Another problem I've seen with some drm bridge drivers is that they
>>> directly create their own connector, which, as Archit stated, is wrong
>>> if you decide to chain this bridge with another bridge. The other
>>
>> I agree with Archit on this.  He took this approach w/ msm support for
>> external bridges, and it seems sensible that the last bridge
>> constructs the connector.  (Plus presumably that is where hpd, ddc
>> probing, etc, is happing)
>
> With this approach many bridges should construct connector conditionally,
> depending if there is something behind them in pipeline (the same is true for
> encoders and even crtcs). It works, but for me there is lot of unnecessary 
> code
> and all those conditional paths make things less friendly for development.
> Wouldn't be better to move creation of the connector to the main drm driver,
> it would require probably adding some opses/fields to drm_bridges but the
> drivers would be simpler, I guess.

six of one, half dozen of the other..   you'd still need to implement
the hpd and ddc probe bits, and that sort of thing *somewhere*.
Whether it is directly by implementing drm_connector in the bridge, or
indirectly via some extra drm_bridge op's called by a shim connector
in the main drm driver, doesn't really seem to change things..

BR,
-R

>
> Regards
> Andrzej
>
>>
>>> reason why the bridge should not create the connector by its own is
>>> that in some case the encoder supports different types of connectors (a
>>> TDMS encoder can be used to output HDMI or DVI), and thus, selecting
>>> the connector type should be left to the part responsible for creating
>>> the display pipelines.
>>
>> did you mean "should" instead of "should not"?  Otherwise I don't
>> think I understand..
>>
>> BR,
>> -R
>>
>>> This being said, I'm definitely not an expert in this area, so don't
>>> hesitate to show me where I'm wrong.
>>>
>>> Best Regards,
>>>
>>> Boris
>>>
>>> --
>>> Boris Brezillon, Free Electrons
>>> Embedded Linux and Kernel engineering
>>> http://free-electrons.com
>

[PATCH 04/15] drivers: gpu: Drop unlikely before IS_ERR(_OR_NULL)

[Daniel Vetter]

On Fri, Jul 31, 2015 at 08:53:04AM -0700, Sinclair Yeh wrote:
> This patch:  Reviewed-by: Sinclair Yeh 
> 
> On Fri, Jul 31, 2015 at 02:08:24PM +0530, Viresh Kumar wrote:
> > IS_ERR(_OR_NULL) already contain an 'unlikely' compiler flag and there
> > is no need to do that again from its callers. Drop it.
> > 
> > Signed-off-by: Viresh Kumar 

Applied to drm-misc, thanks.
-Daniel

> > ---
> >  drivers/gpu/drm/ttm/ttm_tt.c| 4 ++--
> >  drivers/gpu/drm/vmwgfx/vmwgfx_context.c | 2 +-
> >  drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +-
> >  3 files changed, 4 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
> > index bf080abc86d1..4e19d0f9cc30 100644
> > --- a/drivers/gpu/drm/ttm/ttm_tt.c
> > +++ b/drivers/gpu/drm/ttm/ttm_tt.c
> > @@ -340,7 +340,7 @@ int ttm_tt_swapout(struct ttm_tt *ttm, struct file 
> > *persistent_swap_storage)
> > swap_storage = shmem_file_setup("ttm swap",
> > ttm->num_pages << PAGE_SHIFT,
> > 0);
> > -   if (unlikely(IS_ERR(swap_storage))) {
> > +   if (IS_ERR(swap_storage)) {
> > pr_err("Failed allocating swap storage\n");
> > return PTR_ERR(swap_storage);
> > }
> > @@ -354,7 +354,7 @@ int ttm_tt_swapout(struct ttm_tt *ttm, struct file 
> > *persistent_swap_storage)
> > if (unlikely(from_page == NULL))
> > continue;
> > to_page = shmem_read_mapping_page(swap_space, i);
> > -   if (unlikely(IS_ERR(to_page))) {
> > +   if (IS_ERR(to_page)) {
> > ret = PTR_ERR(to_page);
> > goto out_err;
> > }
> > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_context.c 
> > b/drivers/gpu/drm/vmwgfx/vmwgfx_context.c
> > index 5ac92874404d..44e6ecba3de7 100644
> > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_context.c
> > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_context.c
> > @@ -159,7 +159,7 @@ static int vmw_gb_context_init(struct vmw_private 
> > *dev_priv,
> >  
> > if (dev_priv->has_mob) {
> > uctx->man = vmw_cmdbuf_res_man_create(dev_priv);
> > -   if (unlikely(IS_ERR(uctx->man))) {
> > +   if (IS_ERR(uctx->man)) {
> > ret = PTR_ERR(uctx->man);
> > uctx->man = NULL;
> > goto out_err;
> > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
> > b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> > index 620bb5cf617c..6218a36cf01a 100644
> > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> > @@ -1054,7 +1054,7 @@ static long vmw_generic_ioctl(struct file *filp, 
> > unsigned int cmd,
> > return -EINVAL;
> >  
> > vmaster = vmw_master_check(dev, file_priv, flags);
> > -   if (unlikely(IS_ERR(vmaster))) {
> > +   if (IS_ERR(vmaster)) {
> > ret = PTR_ERR(vmaster);
> >  
> > if (ret != -ERESTARTSYS)
> > -- 
> > 2.4.0
> > 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 3/5] ARM: shmobile: r8a7794: Add DU0 clock

[Geert Uytterhoeven]

On Fri, Jul 17, 2015 at 10:26 AM, Laurent Pinchart
 wrote:
> The DU0 clock is an MSTP clock, child of the CPG ZX clock.
>
> Signed-off-by: Laurent Pinchart 

Acked-by: by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 
linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

[PATCH] scripts/kernel-doc Allow struct arguments documentation in struct body

[Randy Dunlap]

On 07/31/15 14:06, Danilo Cesar Lemes de Paula wrote:
> Describing arguments at top of a struct definition works fine
> for small/medium size structs, but it definitely doesn't work well
> for struct with a huge list of elements.
> 
> Keeping the arguments list inside the struct body makes it easier
> to maintain the documentation.
> ie:
> /**
>  * struct my_struct - short description
>  * @a: first member
>  * @b: second member
>  *
>  * Longer description
>  */
> struct my_struct {
> int a;
> int b;
> /**
>  * @c: This is longer description of C
>  *
>  * You can use paragraphs to describe arguments
>  * using this method.
>  */
> int c;
> };
> 
> This patch allows the use of this kind of syntax. Only one argument
> per comment and user can use how many paragraphs he needs. It should
> start with /**, which is already being used by kernel-doc. If those
> comment doesn't follow those rules, it will be ignored.
> 
> Signed-off-by: Danilo Cesar Lemes de Paula 
> Cc: Randy Dunlap 
> Cc: Daniel Vetter 
> Cc: Laurent Pinchart 
> Cc: Jonathan Corbet 
> Cc: Herbert Xu 
> Cc: Stephan Mueller 
> Cc: Michal Marek 
> Cc: linux-kernel at vger.kernel.org
> Cc: linux-doc at vger.kernel.org
> Cc: intel-gfx 
> Cc: dri-devel 
> ---
>  scripts/kernel-doc | 80 
> --
>  1 file changed, 78 insertions(+), 2 deletions(-)
> 
> diff --git a/scripts/kernel-doc b/scripts/kernel-doc
> index 9922e66..9bfa8b9 100755
> --- a/scripts/kernel-doc
> +++ b/scripts/kernel-doc
> @@ -133,6 +133,30 @@ use strict;
>  #
>  # All descriptions can be multiline, except the short function description.
>  #
> +# For really longs structs, you can also describe arguments inside the
> +# body of the struct.
> +# eg.
> +# /**
> +#  * struct my_struct - short description
> +#  * @a: first member
> +#  * @b: second member
> +#  *
> +#  * Longer description
> +#  */
> +# struct my_struct {
> +# int a;
> +# int b;
> +# /**
> +#  * @c: This is longer description of C
> +#  *
> +#  * You can use paragraphs to describe arguments
> +#  * using this method.
> +#  */
> +# int c;
> +# };
> +#
> +# This should be use for arguments only.

used

What are "arguments" in this context?  do you mean struct fields or members?

> +#
>  # You can also add additional sections. When documenting kernel functions you
>  # should document the "Context:" of the function, e.g. whether the functions
>  # can be called form interrupts. Unlike other sections you can end it with an
> @@ -287,9 +311,19 @@ my $lineprefix="";
>  # 2 - scanning field start.
>  # 3 - scanning prototype.
>  # 4 - documentation block
> +# 5 - gathering documentation outside main block
>  my $state;
>  my $in_doc_sect;
>  
> +# Split Doc State
> +# 0 - Invalid (Before start or after finish)
> +# 1 - Is started (the /** was found inside a struct)
> +# 2 - The @parameter header was found, start accepting multi paragraph text.
> +# 3 - Finished (the */ was found)
> +# 4 - Error - Comment without header was found. Spit a warning as it's not
> +# proper kernel-doc and ignore the rest.
> +my $split_doc_state;
> +
>  #declaration types: can be
>  # 'function', 'struct', 'union', 'enum', 'typedef'
>  my $decl_type;
> @@ -304,6 +338,9 @@ my $doc_decl = $doc_com . '(\w+)';
>  my $doc_sect = $doc_com . '([' . $doc_special . ']?[\w\s]+):(.*)';
>  my $doc_content = $doc_com_body . '(.*)';
>  my $doc_block = $doc_com . 'DOC:\s*(.*)?';
> +my $doc_split_start = '^\s*/\*\*\s*$';
> +my $doc_split_sect = '\s*\*\s*(@[\w\s]+):(.*)';
> +my $doc_split_end = '^\s*\*/\s*$';
>  
>  my %constants;
>  my %parameterdescs;
> @@ -2181,6 +2218,7 @@ sub reset_state {
>  $prototype = "";
>  
>  $state = 0;
> +$split_doc_state = 0;
>  }
>  
>  sub tracepoint_munge($) {
> @@ -2453,7 +2491,6 @@ sub process_file($) {
>   }
>   $section = $newsection;
>   } elsif (/$doc_end/) {
> -
>   if (($contents ne "") && ($contents ne "\n")) {
>   dump_section($file, $section, xml_escape($contents));
>   $section = $section_default;
> @@ -2494,8 +2531,47 @@ sub process_file($) {
>   print STDERR "Warning(${file}:$.): bad line: $_";
>   ++$warnings;
>   }
> + } elsif ($state == 5) { # scanning for split parameters
> +
> + # First line (state 1) needs to be a @parameter
> + if ($split_doc_state == 1 && /$doc_split_sect/o) {
> + $section = $1;
> + $contents = $2;
> + if ($contents ne "") {
> + while ((substr($contents, 0, 1) eq " ") ||
> + substr($contents, 0, 1) eq "\t") {
> + $contents = substr($contents, 1);
> + }
> + $contents .= "\n";
> + }
> + $split_doc_state = 2;
> +
> + # End commend */

  comment

[PATCH] scripts/kernel-doc Allow struct arguments documentation in struct body

[Jonathan Corbet]

On Mon, 3 Aug 2015 10:23:19 +0200
Daniel Vetter  wrote:

> > I'm wondering if we need a kernel summit session on commenting
> > conventions, markdown-in-kerneldoc, etc?  Maybe I'll stick a proposal out
> > there.  
> 
> Might be useful, but I'm not sure how many people really would actively
> work on improving the tooling. The only comment I've seen is to maybe use
> gtkdoc, but that would be a pain since it's slightly incompatible with
> kerneldoc.

The idea was to get a sense for what sort of improvements would be
useful, to begin with.  But my attempt to start a discussion on the
kernel summit list appears to have hit the ground pretty hard; I guess
that means I have free rein :)

I expect I'll apply the struct-args doc patch in the fairly near future.
Then we'll see if others complain when patches using it start to show up,
but the feature itself shouldn't break anything.  I'm *really* hoping to
take a hard look at Danilo's stuff for a 4.3 merge as well.  It should be
possible, but there's real-world obnoxiousness that is doing its best to
get in the way.

jon

[Bug 91533] Opencl and Calapp plugins do not work with pyrit on R9 295X2

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

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

--- Comment #3 from Michel Dänzer  ---
For installing open source OpenCL support, see
https://wiki.freedesktop.org/dri/GalliumCompute/#index3h3 . Note that you'll
need to completely remove the Catalyst drivers first.

-- 
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/20150803/ece6ef9a/attachment.html>

[Bug 91533] Opencl and Calapp plugins do not work with pyrit on R9 295X2

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

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

--- Comment #2 from tmrashed at gmail.com ---
Thanks for your reply Michel.

Can you provide the steps or instructions to install the open source driver?

Also can you confirm that you are referring to the OpenGL driver?

Thanks

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

[Bug 65963] screen goes blank, Linux hangs - Radeon 7870, Gallium, Glamor

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

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

--- Comment #30 from Damian Nowak  ---
Well, I don't know! I just updated my rock-solid set of packages that has
always been super stable. Let's see if I encounter this problem again.

lib32-llvm: (3.4.1-1 => 3.6.2-1)
lib32-llvm-libs: (3.4.1-1 => 3.6.2-1)
lib32-mesa: (10.1.4-1 => 10.6.3-1)
lib32-mesa-libgl: (10.1.4-1 => 10.6.3-1)
llvm: (3.4.1-2 => 3.6.2-2)
llvm-libs: (3.4.1-2 => 3.6.2-2)
mesa: (10.1.4-1 => 10.6.3-1)
mesa-libgl: (10.1.4-1 => 10.6.3-1)
xf86-input-keyboard: (1.8.0-3 => 1.8.1-1)
xf86-input-vmmouse: (13.0.0-5 => 13.1.0-1)
xf86-input-void: (1.4.0-7 => 1.4.1-1)
xf86-video-ark: (0.7.5-5 => 0.7.5-6)
xf86-video-ati: (1:7.4.0-3 => 1:7.5.0-2)
xf86-video-dummy: (0.3.7-3 => 0.3.7-4)
xf86-video-fbdev: (0.4.4-3 => 0.4.4-4)
xf86-video-glint: (1.2.8-5 => 1.2.8-6)
xf86-video-i128: (1.3.6-5 => 1.3.6-6)
xf86-video-mach64: (6.9.4-4 => 6.9.5-1)
xf86-video-neomagic: (1.2.8-3 => 1.2.9-1)
xf86-video-nv: (2.1.20-5 => 2.1.20-6)
xf86-video-openchrome: (0.3.3-4 => 0.3.3-5)
xf86-video-r128: (6.9.2-3 => 6.10.0-1)
xf86-video-savage: (2.3.7-3 => 2.3.8-1)
xf86-video-siliconmotion: (1.7.7-5 => 1.7.8-1)
xf86-video-sis: (0.10.7-6 => 0.10.7-7)
xf86-video-tdfx: (1.4.5-5 => 1.4.5-6)
xf86-video-trident: (1.3.6-6 => 1.3.7-1)
xf86-video-vesa: (2.3.2-5 => 2.3.4-1)
xf86-video-vmware: (13.1.0-1 => 13.1.0-2)
xf86-video-voodoo: (1.2.5-5 => 1.2.5-6)
xorg-server: (1.16.4-1 => 1.17.2-4)
xorg-server-common: (1.16.4-1 => 1.17.2-4)
xorg-server-devel: (1.16.4-1 => 1.17.2-4)

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

[Bug 90774] New account request

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

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

Michel Dänzer  changed:

   What|Removed |Added

  Component|Drivers/Gallium/r600|New Accounts
   Assignee|dri-devel at lists.freedesktop |sitewranglers at 
lists.freedes
   |.org|ktop.org
Product|Mesa|freedesktop.org
 QA Contact|dri-devel at lists.freedesktop |
   |.org|

-- 
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/20150803/0b4f192a/attachment-0001.html>

[Bug 91509] Depth render buffer corruption

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

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

--- Comment #6 from Michel Dänzer  ---
FWIW, the (micro-)tile size is always 8x8. With macro-tiling (called 2D tiling
with current GPUs) enabled, the pitch (and height, for calculating the memory
allocation size) must usually be aligned to a macro-tile boundary. Not sure
offhand how to calculate the macro-tile size on those old GPUs though.

-- 
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/20150803/3db947fa/attachment.html>

[Bug 91520] [radeonsi, PIGLIT, regression] spec@arb_gpu_shader_fp64@execution@fs-indirect-temp-double-{dst, src} triggers SIGSEGV

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

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

--- Comment #1 from Michel Dänzer  ---
I had the same problem with libelf1 0.163-4 (was fine with libelf1 0.159-4.2).
I rebuilt Mesa against libelfg0-dev instead of libelf-dev, and the problem is
gone for me.

If you can confirm this, please file a bug against libelf1.

-- 
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/20150803/d3d522d5/attachment.html>

[Bug 91527] 7870 radeon crashes after kernel msg drm:radeon_mn_invalidate_range_start

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

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

Michel Dänzer  changed:

   What|Removed |Added

  Component|Drivers/Gallium/radeonsi|DRM/Radeon
Version|git |unspecified
Product|Mesa|DRI
 QA Contact|dri-devel at lists.freedesktop |
   |.org|

-- 
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/20150803/3f698895/attachment.html>

[Bug 91533] Opencl and Calapp plugins do not work with pyrit on R9 295X2

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

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

Michel Dänzer  changed:

   What|Removed |Added

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

--- Comment #1 from Michel Dänzer  ---
(In reply to tmrashed from comment #0)
> # fglrxinfo 
> display: :0.0  screen: 0
> OpenGL vendor string: Advanced Micro Devices, Inc.
> OpenGL renderer string: VESUVIUS (67B9)
> OpenGL version string: 4.4.12874 Compatibility Profile Context
> 14.10.1006.1001
> 
> Used AMD SDK 2.7 (previously tried 2.9 which didn't work either)

That's not the open source driver. Please report your problem in a Catalyst bug
tracker.

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

[PATCH] drm/nouveau/gem: tolerate a buffer specified multiple times

[Bryan O'Donoghue]

On 31/07/15 19:11, Bryan O'Donoghue wrote:
> On 31/07/15 17:43, Bryan O'Donoghue wrote:
>> On 31/07/15 17:36, Ilia Mirkin wrote:
>>> Do you have a reproducible way of achieving the multiple buffer on
>>> validation list thing?

Ilia, Peter.

I've filed a bug for you here : 
https://bugs.freedesktop.org/show_bug.cgi?id=91535

I've verified that Peter's PPA library when installed fixes the race 
condition you guys were talking about but running the test program 
tests/nouveau/threaded so, this issue we're discussing here is a 
separate one.

Cheers,
Bryan

[Bug 91534] r300 blocking GLX and EGL compositing in KWin (KDE Plasma 5.x)?

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

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

Bug ID: 91534
   Summary: r300 blocking GLX and EGL compositing in KWin (KDE
Plasma 5.x)?
   Product: Mesa
   Version: 10.5
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r300
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: aaron.d.pickett at gmail.com
QA Contact: dri-devel at lists.freedesktop.org

Created attachment 117488
  --> https://bugs.freedesktop.org/attachment.cgi?id=117488=edit
Attempt to force EGL-based OpenGL compositing

I have an old laptop with ATI RS480 graphics (Radeon Xpress 200M), and I've
been testing KDE Plasma 5.x in KUbuntu 15.04 (currently version 5.3 from the
backports PPA).  In all the versions I've tried, OpenGL compositing fails.  For
the GLX API, I assume this is because r300 *almost* supports OpenGL 2.1, but
falls short on NPOT texture support.

After some reading
(http://blog.martin-graesslin.com/blog/2011/07/running-kwin-with-opengl-es-2-0/),
I thought I might try the EGL API for OpenGL ES compositing.  The GUI wouldn't
let me select EGL, so I forced it using environment variables
(https://community.kde.org/KWin/Environment_Variables) as follows:
KWIN_OPENGL_INTERFACE=egl
KWIN_COMPOSE=O1 (I also tried O2, same result)

Unfortunately, the (truncated) result is:
kwin_core: OpenGL driver recommends XRender based compositing. Falling back to
XRender.
...
kwin_core: Failed to initialize compositing, compositing disabled

>From what I've read, the r300 should have full OpenGL ES 2.0 support, so is the
driver blocking EGL compositing unnecessarily?  

The full log of my attempt to force EGL-based compositing is attached.

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