[Bug 66963] Rv6xx dpm problems

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

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

--- Comment #283 from Alex Deucher  ---
(In reply to Kajzer from comment #282)
> I'm running now on kernel compiled with first method, if previous bisect was
> indeed done right I don't expect dpm freeze.
> 
> Anyway, thanks for the second method, if I understood you correctly,
> basically I can test if Michel's commit is bad or not by running :
> $ git bisect reset

You only need this if you had previously started a bisect (git bisect start).

> $ git checkout -b testing 02376d8282b88f07d0716da6155094c8760b1a13

that will create a new branch named testing.  If you already did that, you will
need to delete the existing testing branch first before you create another
branch with the same name.  So either delete the branch when you are done with
it (git branch -D testing) or create a new branch name (git branch -b testing2
02376d8282b88f07d0716da6155094c8760b1a13).

-- 
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/20150707/30fe2281/attachment.html>

[Bug 66963] Rv6xx dpm problems

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

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

--- Comment #282 from Kajzer  ---
(In reply to Alex Deucher from comment #280)
> You don't need to start the bisect again.  `git bisect reset` will clean up
> the bisect and reset your current HEAD to where it was when started the
> bisect.  At that point just run `git reset --hard
> 77497f2735ad6e29c55475e15e9790dbfa2c2ef8` or 'git checkout -b testing
> 77497f2735ad6e29c55475e15e9790dbfa2c2ef8` to checkout the specific commit
> you want to test.  The second method creates a new branch called testing
> with HEAD set to the specified commit.  The reset command resets the HEAD of
> the current tree to the specified commit.

I'm running now on kernel compiled with first method, if previous bisect was
indeed done right I don't expect dpm freeze.

Anyway, thanks for the second method, if I understood you correctly, basically
I can test if Michel's commit is bad or not by running :
$ git bisect reset
$ git checkout -b testing 02376d8282b88f07d0716da6155094c8760b1a13

Of course after I'm done with current test.
Please correct me if I'm wrong.

-- 
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/20150707/02e6be42/attachment.html>

[Bug 66963] Rv6xx dpm problems

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

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

--- Comment #281 from Kajzer  ---
Nice, I'll start compiling now and will run that image for a few days.

-- 
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/20150707/4a8b23bc/attachment.html>

[Bug 66963] Rv6xx dpm problems

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

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

--- Comment #280 from Alex Deucher  ---
(In reply to Kajzer from comment #279)
> (In reply to Rafał Miłecki from comment #277) 
> > Don't start the bisect again, just try the commit Michel told about.
> > 
> > git reset --hard 77497f2735ad6e29c55475e15e9790dbfa2c2ef8
> > 
> > Then compile the kernel, install it & test for few days.
> 
> This will work even if I no longer have git directory from that bisect ?

yes.

> I mean, I'm on a clean system, starting all over again with :
> $ git bisect start -- drivers/gpu/drm/radeon
> $ git bisect good v3.16
> $ git bisect bad v3.17
> Bisecting: 57 revisions left to test after this (roughly 6 steps)
> [03f62abd112d5150b6ce8957fa85d4f6e85e357f] drm/radeon: split PT setup in
> more functions
> $ git reset --hard 77497f2735ad6e29c55475e15e9790dbfa2c2ef8
> HEAD is now at 77497f2 drm/radeon: Pass GART page flags to
> radeon_gart_set_page() explicitly

You don't need to start the bisect again.  `git bisect reset` will clean up the
bisect and reset your current HEAD to where it was when started the bisect.  At
that point just run `git reset --hard 77497f2735ad6e29c55475e15e9790dbfa2c2ef8`
or 'git checkout -b testing 77497f2735ad6e29c55475e15e9790dbfa2c2ef8` to
checkout the specific commit you want to test.  The second method creates a new
branch called testing with HEAD set to the specified commit.  The reset command
resets the HEAD of the current tree to the specified commit.

-- 
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/20150707/056299b7/attachment.html>

[Bug 66963] Rv6xx dpm problems

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

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

--- Comment #279 from Kajzer  ---
(In reply to Rafał Miłecki from comment #277) 
> Don't start the bisect again, just try the commit Michel told about.
> 
> git reset --hard 77497f2735ad6e29c55475e15e9790dbfa2c2ef8
> 
> Then compile the kernel, install it & test for few days.

This will work even if I no longer have git directory from that bisect ?
I mean, I'm on a clean system, starting all over again with :
$ git bisect start -- drivers/gpu/drm/radeon
$ git bisect good v3.16
$ git bisect bad v3.17
Bisecting: 57 revisions left to test after this (roughly 6 steps)
[03f62abd112d5150b6ce8957fa85d4f6e85e357f] drm/radeon: split PT setup in more
functions
$ git reset --hard 77497f2735ad6e29c55475e15e9790dbfa2c2ef8
HEAD is now at 77497f2 drm/radeon: Pass GART page flags to
radeon_gart_set_page() explicitly

-- 
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/20150707/f8fdd51c/attachment.html>

[PATCH] Documentation: drm: Fix tablulation in KMS properties table

[Graham Whaley]

Commit 712a0dd91c4a ("Documentation/drm: Update rotation property")
left an extra 'rowspan' for the row omap, which pushed the following qxl
rows columns out to column 8 and broke the tabulation.
Remove the errant rowspan.

Signed-off-by: Graham Whaley 
---
 Documentation/DocBook/drm.tmpl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index e82205e..596b11d 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -3383,7 +3383,7 @@ void intel_crt_init(struct drm_device *dev)
TBD


-   omap
+   omap
Generic
“zorder”
RANGE
-- 
2.4.3

[PATCH 07/12] drm: Add structures to set/get a palette color property

[Emil Velikov]

Hi Kausal,

On 03/07/15 04:31, Kausal Malladi wrote:
> This patch adds new structures in DRM layer for Palette color correction.
> These structures will be used by user space agents to configure
> appropriate number of samples and Palette LUT for a platform.
> 
> Signed-off-by: Shashank Sharma 
> Signed-off-by: Kausal Malladi 
> ---
>  include/uapi/drm/drm.h | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> index d9562a2..04a8f2a 100644
> --- a/include/uapi/drm/drm.h
> +++ b/include/uapi/drm/drm.h
> @@ -863,6 +863,18 @@ struct drm_color_caps {
>   struct drm_cge_caps cge_caps;
>  };
>  
> +struct drm_r32g32b32 {
> + __u32 r32;
> + __u32 g32;
> + __u32 b32;
> +};
> +
I don't think this will work on a 64bit kernel with 32 bit userspace...
although I'm low on caffeine I could be imagining.


> +struct drm_palette {
> + __u32 version;
> + __u32 palette_num_samples;
> + struct drm_r32g32b32 palette_lut[0];
If memory serves me right, I've mentioned earlier that using zero sized
arrays might not be so good considering portability and using non GCC
compilers.

I believe your consern was about that using a pointer is inefficient.
Can you provide some references/hints how is that so ?

Thanks
Emil

[Intel-gfx] [PATCH v2 02/20] drm: Don't update plane properties for atomic planes if it stays the same

[Daniel Vetter]

On Tue, Jul 07, 2015 at 05:08:34PM +0200, Maarten Lankhorst wrote:
> Op 07-07-15 om 14:10 schreef Daniel Vetter:
> > On Tue, Jul 07, 2015 at 12:20:10PM +0200, Maarten Lankhorst wrote:
> >> Op 07-07-15 om 11:18 schreef Daniel Vetter:
> >>> On Tue, Jul 07, 2015 at 09:08:13AM +0200, Maarten Lankhorst wrote:
>  This allows the first atomic call during hw init to be a real modeset,
>  which is useful for forcing a recalculation.
> >>> fbcon is optional, you can't rely on anything being done in any specific
> >>> way. What exactly do you need this for, what's the implications?
> >> In the hw readout I noticed some warnings when I wasn't setting any mode 
> >> property in the readout.
> >> I want the first function to be the modeset, so we have a sane base to 
> >> commit changes on.
> >> Ideally this whole function would have a atomic counterpart which does it 
> >> in one go. :)
> > Yeah. Otoh as soon as we have atomic modeset working we can replace all
> > the legacy entry points with atomic helpers, and then even plane_disable
> > will be a full atomic modeset.
> >
> > What did fall apart with just touching properties/planes now?
> Also when i915 is fully atomic it calculates in intel_modeset_compute_config
> if a modeset is needed after the first atomic call. Right now because
> intel_modeset_compute_config is only called in set_config so this works as 
> expected.
> Otherwise drm_plane_force_disable or rotate_0 will force a modeset,
> and if the final mode is different this will introduce a double modeset.

For expensive properties (i.e. a no-op changes causes something that takes
time like modeset or vblank wait) we need to make sure we filter them out
in atomic_check. Yeah not quite there yet with pure atomic, but meanwhile
the existing legacy set_prop functions should all filter out no-op changes
themselves. If we don't do that for rotation then that's a bug.

Same for disabling planes harder, that shouldn't take time. Especially
since fbcon only force-disable non-primary plane, and for driver load
that's the exact thing we already do in the driver anyway.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[Intel-gfx] [PATCH v2 02/20] drm: Don't update plane properties for atomic planes if it stays the same

[Daniel Vetter]

On Tue, Jul 07, 2015 at 04:32:44PM +0200, Maarten Lankhorst wrote:
> Op 07-07-15 om 14:10 schreef Daniel Vetter:
> > On Tue, Jul 07, 2015 at 12:20:10PM +0200, Maarten Lankhorst wrote:
> >> Op 07-07-15 om 11:18 schreef Daniel Vetter:
> >>> On Tue, Jul 07, 2015 at 09:08:13AM +0200, Maarten Lankhorst wrote:
>  This allows the first atomic call during hw init to be a real modeset,
>  which is useful for forcing a recalculation.
> >>> fbcon is optional, you can't rely on anything being done in any specific
> >>> way. What exactly do you need this for, what's the implications?
> >> In the hw readout I noticed some warnings when I wasn't setting any mode 
> >> property in the readout.
> >> I want the first function to be the modeset, so we have a sane base to 
> >> commit changes on.
> >> Ideally this whole function would have a atomic counterpart which does it 
> >> in one go. :)
> > Yeah. Otoh as soon as we have atomic modeset working we can replace all
> > the legacy entry points with atomic helpers, and then even plane_disable
> > will be a full atomic modeset.
> >
> > What did fall apart with just touching properties/planes now?
> Setting rotation on the primary plane caused it to be disabled because
> the src and dst rectangle are not set up yet until the modeset. So the
> check function saw that the plane should be invisible and performs the
> update.

Sounds like a bug - we need to recreate more of the primary plane state.
Or maybe we need to call the atomic_check function for the primary plane
to compute all that derived state. But we really can't rely upon userspace
to do a modeset first, e.g. X at start (if there's no fbcon) loves to read
and then write back all the properties (or at least did).

We really need to handle this in the backend properly.

> It's also an extra vblank wait when the primary plane is visible.

Another bug, no-op changes with the same fb should not result in a vblank
wait. At least not when using the helpers (or if there is a case I need to
copypaste the fix again).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[Bug 91141] Lots of *ERROR* Couldn't update BO_VA (-22) since drm/radeon: stop using addr to check for BO move

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

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

--- Comment #17 from Daniel Exner <dex+fdobugzilla at dragonslave.de> ---
I can also confirm that a suspend resume cycle no longer floods my kernel log
with linus kernel + the two patches.

-- 
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/20150707/98b2e1dd/attachment-0001.html>

[Bug 66963] Rv6xx dpm problems

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

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

--- Comment #278 from Alex Deucher  ---
Be careful.  There are two issues here:
1. The general instability of dpm on r6xx (what this bug is about)
2. A potential additional dpm stability issue perhaps introduced by the
bisected commit

Solving the second one won't necessarily help the fix the first one.

-- 
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/20150707/21e9cb0d/attachment.html>

[Bug 66963] Rv6xx dpm problems

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

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

--- Comment #277 from Rafał Miłecki  ---
(In reply to Kajzer from comment #276)
> I understand, well I'm glad I'm not alone, it was starting to feel weird, so
> basically I decided to give up today. You gave me strength now to continue :)

I can assure you there are many more followers of your fight :) I wish you luck
with it!


> @Michel Dänzer, I can do a bisect one more time, but I'm 99% sure I did it
> right.
> If it's not a big problem, can you please tell me how I can either exclude
> your commit from 3.17 or add it to 3.16 ? Either way works and I can then
> definitely say if your commit was the one or not.

Don't start the bisect again, just try the commit Michel told about.

git reset --hard 77497f2735ad6e29c55475e15e9790dbfa2c2ef8

Then compile the kernel, install it & test for few days.

-- 
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/20150707/a6546393/attachment.html>

[Bug 66963] Rv6xx dpm problems

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

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

--- Comment #276 from Kajzer  ---
(In reply to Nicola Mori from comment #275)
> You are not the only one, Kajzer. I have exactly the same issue on my RV620,
> but I don't have the possibility to bisect nor I know how to do it. I
> appreciate your efforts very much and I'm closely following your
> conversation with Michel hoping that in the end this nasty bug will be
> finally squashed. I was silent because comments like "me too" are useless,
> but this does not mean that nobody is interested in this issue (I'd say
> rather the opposite given the number of CC'ers).

I understand, well I'm glad I'm not alone, it was starting to feel weird, so
basically I decided to give up today. You gave me strength now to continue :)

@Michel Dänzer, I can do a bisect one more time, but I'm 99% sure I did it
right.
If it's not a big problem, can you please tell me how I can either exclude your
commit from 3.17 or add it to 3.16 ? Either way works and I can then definitely
say if your commit was the one or not.

-- 
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/20150707/04c8a94c/attachment-0001.html>

[PATCH] drm/msm/mdp5:Add DMA pipe planes for MDP5

[Jilai Wang]

This change is to add planes which use DMA pipes for MDP5.

Signed-off-by: Jilai Wang 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 23 ---
 1 file changed, 20 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
index cbda41d..f40896d 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
@@ -316,9 +316,12 @@ static int modeset_init(struct mdp5_kms *mdp5_kms)
static const enum mdp5_pipe crtcs[] = {
SSPP_RGB0, SSPP_RGB1, SSPP_RGB2, SSPP_RGB3,
};
-   static const enum mdp5_pipe pub_planes[] = {
+   static const enum mdp5_pipe vig_planes[] = {
SSPP_VIG0, SSPP_VIG1, SSPP_VIG2, SSPP_VIG3,
};
+   static const enum mdp5_pipe dma_planes[] = {
+   SSPP_DMA0, SSPP_DMA1,
+   };
struct drm_device *dev = mdp5_kms->dev;
struct msm_drm_private *priv = dev->dev_private;
const struct mdp5_cfg_hw *hw_cfg;
@@ -361,12 +364,26 @@ static int modeset_init(struct mdp5_kms *mdp5_kms)
for (i = 0; i < hw_cfg->pipe_vig.count; i++) {
struct drm_plane *plane;

-   plane = mdp5_plane_init(dev, pub_planes[i], false,
+   plane = mdp5_plane_init(dev, vig_planes[i], false,
hw_cfg->pipe_vig.base[i], hw_cfg->pipe_vig.caps);
if (IS_ERR(plane)) {
ret = PTR_ERR(plane);
dev_err(dev->dev, "failed to construct %s plane: %d\n",
-   pipe2name(pub_planes[i]), ret);
+   pipe2name(vig_planes[i]), ret);
+   goto fail;
+   }
+   }
+
+   /* DMA planes */
+   for (i = 0; i < hw_cfg->pipe_dma.count; i++) {
+   struct drm_plane *plane;
+
+   plane = mdp5_plane_init(dev, dma_planes[i], false,
+   hw_cfg->pipe_dma.base[i], hw_cfg->pipe_dma.caps);
+   if (IS_ERR(plane)) {
+   ret = PTR_ERR(plane);
+   dev_err(dev->dev, "failed to construct %s plane: %d\n",
+   pipe2name(dma_planes[i]), ret);
goto fail;
}
}
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH] drm/msm/mdp: Add capabilities to MDP planes

[Jilai Wang]

MDP planes can be implemented using different type of HW pipes,
RGB/VIG/DMA pipes for MDP5 and RGB/VG/DMA pipes for MDP4. Each type
of pipe has different HW capabilities such as scaling, color space
conversion, decimation... Add a variable in plane data structure
to specify the difference of each plane which comes from mdp5_cfg data
and use it to differenciate the plane operation.

Signed-off-by: Jilai Wang 
---
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h   | 19 
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c |  7 ++-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c   | 26 ++-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h   | 11 +++--
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c   |  4 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h   | 24 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 73 ++-
 drivers/gpu/drm/msm/mdp/mdp_kms.h | 13 ++
 8 files changed, 114 insertions(+), 63 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h 
b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h
index c1ecb9d..83a54d0 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h
@@ -175,27 +175,24 @@ irqreturn_t mdp4_irq(struct msm_kms *kms);
 int mdp4_enable_vblank(struct msm_kms *kms, struct drm_crtc *crtc);
 void mdp4_disable_vblank(struct msm_kms *kms, struct drm_crtc *crtc);

-static inline bool pipe_supports_yuv(enum mdp4_pipe pipe)
+static inline uint32_t mdp4_pipe_caps(enum mdp4_pipe pipe)
 {
switch (pipe) {
case VG1:
case VG2:
case VG3:
case VG4:
-   return true;
+   return MDP_PIPE_CAP_HFLIP | MDP_PIPE_CAP_VFLIP |
+   MDP_PIPE_CAP_SCALE | MDP_PIPE_CAP_CSC;
+   case RGB1:
+   case RGB2:
+   case RBG2:
+   return MDP_PIPE_CAP_SCALE;
default:
-   return false;
+   return 0;
}
 }

-static inline
-uint32_t mdp4_get_formats(enum mdp4_pipe pipe_id, uint32_t *pixel_formats,
-   uint32_t max_formats)
-{
-   return mdp_get_formats(pixel_formats, max_formats,
-   !pipe_supports_yuv(pipe_id));
-}
-
 void mdp4_plane_install_properties(struct drm_plane *plane,
struct drm_mode_object *obj);
 enum mdp4_pipe mdp4_plane_pipe(struct drm_plane *plane);
diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c 
b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
index 0d1dbb7..c749489 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
@@ -26,6 +26,7 @@ struct mdp4_plane {

enum mdp4_pipe pipe;

+   uint32_t caps;
uint32_t nformats;
uint32_t formats[32];

@@ -380,9 +381,11 @@ struct drm_plane *mdp4_plane_init(struct drm_device *dev,

mdp4_plane->pipe = pipe_id;
mdp4_plane->name = pipe_names[pipe_id];
+   mdp4_plane->caps = mdp4_pipe_caps(pipe_id);

-   mdp4_plane->nformats = mdp4_get_formats(pipe_id, mdp4_plane->formats,
-   ARRAY_SIZE(mdp4_plane->formats));
+   mdp4_plane->nformats = mdp_get_formats(mdp4_plane->formats,
+   ARRAY_SIZE(mdp4_plane->formats),
+   !pipe_supports_yuv(mdp4_plane->caps));

type = private_plane ? DRM_PLANE_TYPE_PRIMARY : DRM_PLANE_TYPE_OVERLAY;
ret = drm_universal_plane_init(dev, plane, 0xff, _plane_funcs,
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
index 789b02f..ac1d58f 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
@@ -45,14 +45,20 @@ const struct mdp5_cfg_hw msm8x74_config = {
.pipe_vig = {
.count = 3,
.base = { 0x01200, 0x01600, 0x01a00 },
+   .caps = MDP_PIPE_CAP_HFLIP | MDP_PIPE_CAP_VFLIP |
+   MDP_PIPE_CAP_SCALE | MDP_PIPE_CAP_CSC |
+   MDP_PIPE_CAP_DECIMATION,
},
.pipe_rgb = {
.count = 3,
.base = { 0x01e00, 0x02200, 0x02600 },
+   .caps = MDP_PIPE_CAP_HFLIP | MDP_PIPE_CAP_VFLIP |
+   MDP_PIPE_CAP_SCALE | MDP_PIPE_CAP_DECIMATION,
},
.pipe_dma = {
.count = 2,
.base = { 0x02a00, 0x02e00 },
+   .caps = MDP_PIPE_CAP_HFLIP | MDP_PIPE_CAP_VFLIP,
},
.lm = {
.count = 5,
@@ -113,14 +119,20 @@ const struct mdp5_cfg_hw apq8084_config = {
.pipe_vig = {
.count = 4,
.base = { 0x01200, 0x01600, 0x01a00, 0x01e00 },
+   .caps = MDP_PIPE_CAP_HFLIP | MDP_PIPE_CAP_VFLIP |
+   MDP_PIPE_CAP_SCALE | MDP_PIPE_CAP_CSC |
+   MDP_PIPE_CAP_DECIMATION,
},
.pipe_rgb = {
.count = 4,
.base = { 0x02200, 0x02600, 0x02a00, 0x02e00 },
+ 

[PATCH v2] drm: add a check for x/y in drm_mode_setcrtc

[John Hunter]

From: Zhao Junwang 

legacy setcrtc ioctl does take a 32 bit value which might indeed
overflow

the checks of crtc_req->x > INT_MAX and crtc_req->y > INT_MAX aren't
needed any more with this

v2: -polish the annotation according to Daniel's comment

Cc: Daniel Vetter 
Signed-off-by: Zhao Junwang 
---
 drivers/gpu/drm/drm_crtc.c |7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index b69ed97..745fc78 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2706,8 +2706,11 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
if (!drm_core_check_feature(dev, DRIVER_MODESET))
return -EINVAL;

-   /* For some reason crtc x/y offsets are signed internally. */
-   if (crtc_req->x > INT_MAX || crtc_req->y > INT_MAX)
+   /*
+* Universal plane src offsets are only 16.16, prevent havoc for
+* drivers using universal plane code internally.
+*/
+   if (crtc_req->x & 0x || crtc_req->y & 0x)
return -ERANGE;

drm_modeset_lock_all(dev);
-- 
1.7.10.4

[Intel-gfx] [PATCH v2 02/20] drm: Don't update plane properties for atomic planes if it stays the same

[Maarten Lankhorst]

Op 07-07-15 om 14:10 schreef Daniel Vetter:
> On Tue, Jul 07, 2015 at 12:20:10PM +0200, Maarten Lankhorst wrote:
>> Op 07-07-15 om 11:18 schreef Daniel Vetter:
>>> On Tue, Jul 07, 2015 at 09:08:13AM +0200, Maarten Lankhorst wrote:
 This allows the first atomic call during hw init to be a real modeset,
 which is useful for forcing a recalculation.
>>> fbcon is optional, you can't rely on anything being done in any specific
>>> way. What exactly do you need this for, what's the implications?
>> In the hw readout I noticed some warnings when I wasn't setting any mode 
>> property in the readout.
>> I want the first function to be the modeset, so we have a sane base to 
>> commit changes on.
>> Ideally this whole function would have a atomic counterpart which does it in 
>> one go. :)
> Yeah. Otoh as soon as we have atomic modeset working we can replace all
> the legacy entry points with atomic helpers, and then even plane_disable
> will be a full atomic modeset.
>
> What did fall apart with just touching properties/planes now?
Also when i915 is fully atomic it calculates in intel_modeset_compute_config
if a modeset is needed after the first atomic call. Right now because
intel_modeset_compute_config is only called in set_config so this works as 
expected.
Otherwise drm_plane_force_disable or rotate_0 will force a modeset,
and if the final mode is different this will introduce a double modeset.

[PATCH] drm/rockchip: use drm_gem_mmap helpers

[Daniel Kurtz]

Rather than (incompletely [0]) re-implementing drm_gem_mmap() and
drm_gem_mmap_obj() helpers, call them directly from the rockchip mmap
routines.

Once the core functions return successfully, the rockchip mmap routines
can still use dma_mmap_attrs() to simply mmap the entire buffer.

[0] Previously, we were performing the mmap() without first taking a
reference on the underlying gem buffer.  This could leak ptes if the gem
object is destroyed while userspace is still holding the mapping.

Signed-off-by: Daniel Kurtz 
Reviewed-by: Daniel Vetter 
Cc: stable at vger.kernel.org

---
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 67 +++--
 1 file changed, 34 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index eb2282c..eba5f8a 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -54,55 +54,56 @@ static void rockchip_gem_free_buf(struct 
rockchip_gem_object *rk_obj)
   _obj->dma_attrs);
 }

-int rockchip_gem_mmap_buf(struct drm_gem_object *obj,
- struct vm_area_struct *vma)
+static int rockchip_drm_gem_object_mmap(struct drm_gem_object *obj,
+   struct vm_area_struct *vma)
+
 {
+   int ret;
struct rockchip_gem_object *rk_obj = to_rockchip_obj(obj);
struct drm_device *drm = obj->dev;
-   unsigned long vm_size;

-   vma->vm_flags |= VM_IO | VM_DONTEXPAND | VM_DONTDUMP;
-   vm_size = vma->vm_end - vma->vm_start;
-
-   if (vm_size > obj->size)
-   return -EINVAL;
+   /*
+* dma_alloc_attrs() allocated a struct page table for rk_obj, so clear
+* VM_PFNMAP flag that was set by drm_gem_mmap_obj()/drm_gem_mmap().
+*/
+   vma->vm_flags &= ~VM_PFNMAP;

-   return dma_mmap_attrs(drm->dev, vma, rk_obj->kvaddr, rk_obj->dma_addr,
+   ret = dma_mmap_attrs(drm->dev, vma, rk_obj->kvaddr, rk_obj->dma_addr,
 obj->size, _obj->dma_attrs);
+   if (ret)
+   drm_gem_vm_close(vma);
+
+   return ret;
 }

-/* drm driver mmap file operations */
-int rockchip_gem_mmap(struct file *filp, struct vm_area_struct *vma)
+int rockchip_gem_mmap_buf(struct drm_gem_object *obj,
+ struct vm_area_struct *vma)
 {
-   struct drm_file *priv = filp->private_data;
-   struct drm_device *dev = priv->minor->dev;
-   struct drm_gem_object *obj;
-   struct drm_vma_offset_node *node;
+   struct drm_device *drm = obj->dev;
int ret;

-   if (drm_device_is_unplugged(dev))
-   return -ENODEV;
+   mutex_lock(>struct_mutex);
+   ret = drm_gem_mmap_obj(obj, obj->size, vma);
+   mutex_unlock(>struct_mutex);
+   if (ret)
+   return ret;

-   mutex_lock(>struct_mutex);
+   return rockchip_drm_gem_object_mmap(obj, vma);
+}

-   node = drm_vma_offset_exact_lookup(dev->vma_offset_manager,
-  vma->vm_pgoff,
-  vma_pages(vma));
-   if (!node) {
-   mutex_unlock(>struct_mutex);
-   DRM_ERROR("failed to find vma node.\n");
-   return -EINVAL;
-   } else if (!drm_vma_node_is_allowed(node, filp)) {
-   mutex_unlock(>struct_mutex);
-   return -EACCES;
-   }
+/* drm driver mmap file operations */
+int rockchip_gem_mmap(struct file *filp, struct vm_area_struct *vma)
+{
+   struct drm_gem_object *obj;
+   int ret;

-   obj = container_of(node, struct drm_gem_object, vma_node);
-   ret = rockchip_gem_mmap_buf(obj, vma);
+   ret = drm_gem_mmap(filp, vma);
+   if (ret)
+   return ret;

-   mutex_unlock(>struct_mutex);
+   obj = vma->vm_private_data;

-   return ret;
+   return rockchip_drm_gem_object_mmap(obj, vma);
 }

 struct rockchip_gem_object *
-- 
2.4.3.573.g4eafbef

R200 DRM/KMS

[Steven Newbury]

On Tue, 2015-07-07 at 10:12 -0400, Alex Deucher wrote:
> On Tue, Jul 7, 2015 at 9:46 AM, Steven Newbury  > wrote:
> > 
> > I've tried an xserver-1.16, and ddx, libdrm without LTO and with
> > gcc4.9.  Exactly the same thing.  I wondered whether the unused 
> > i810
> > could be interfering but triggering a device "remove" before 
> > starting
> > X made no difference.
> > 
> > I'm a bit of a loss.  I suppose I could try writing a simple test 
> > for
> > drmSetInterfaceVersion().  At least that should determine whether 
> > the
> > xserver/ddx is in the clear.
> > 
> > Any other ideas?
> > 
> 
> Can you start a non-X runlevel and start X manually as root (assuming
> you are using a login manager now)?

I've written a simple test based on the code from radeon_kms.c

I just need to try it on the actual hw now... :-)
-- next part --
A non-text attachment was scrubbed...
Name: test-drm.c
Type: text/x-csrc
Size: 735 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150707/648c0a9f/attachment.c>
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150707/648c0a9f/attachment.sig>

[Intel-gfx] [PATCH v2 02/20] drm: Don't update plane properties for atomic planes if it stays the same

[Maarten Lankhorst]

Op 07-07-15 om 14:10 schreef Daniel Vetter:
> On Tue, Jul 07, 2015 at 12:20:10PM +0200, Maarten Lankhorst wrote:
>> Op 07-07-15 om 11:18 schreef Daniel Vetter:
>>> On Tue, Jul 07, 2015 at 09:08:13AM +0200, Maarten Lankhorst wrote:
 This allows the first atomic call during hw init to be a real modeset,
 which is useful for forcing a recalculation.
>>> fbcon is optional, you can't rely on anything being done in any specific
>>> way. What exactly do you need this for, what's the implications?
>> In the hw readout I noticed some warnings when I wasn't setting any mode 
>> property in the readout.
>> I want the first function to be the modeset, so we have a sane base to 
>> commit changes on.
>> Ideally this whole function would have a atomic counterpart which does it in 
>> one go. :)
> Yeah. Otoh as soon as we have atomic modeset working we can replace all
> the legacy entry points with atomic helpers, and then even plane_disable
> will be a full atomic modeset.
>
> What did fall apart with just touching properties/planes now?
Setting rotation on the primary plane caused it to be disabled because
the src and dst rectangle are not set up yet until the modeset. So the
check function saw that the plane should be invisible and performs the
update.

It's also an extra vblank wait when the primary plane is visible.

[PATCH 3/3] drm/radeon: Fold radeon_set_cursor() into radeon_show_cursor()

[Michel Dänzer]

From: Michel Dänzer 

Signed-off-by: Michel Dänzer 
---
 drivers/gpu/drm/radeon/radeon_cursor.c | 49 +-
 1 file changed, 19 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_cursor.c 
b/drivers/gpu/drm/radeon/radeon_cursor.c
index fa66174..afaf346 100644
--- a/drivers/gpu/drm/radeon/radeon_cursor.c
+++ b/drivers/gpu/drm/radeon/radeon_cursor.c
@@ -91,15 +91,34 @@ static void radeon_show_cursor(struct drm_crtc *crtc)
struct radeon_device *rdev = crtc->dev->dev_private;

if (ASIC_IS_DCE4(rdev)) {
+   WREG32(EVERGREEN_CUR_SURFACE_ADDRESS_HIGH + 
radeon_crtc->crtc_offset,
+  upper_32_bits(radeon_crtc->cursor_addr));
+   WREG32(EVERGREEN_CUR_SURFACE_ADDRESS + radeon_crtc->crtc_offset,
+  lower_32_bits(radeon_crtc->cursor_addr));
WREG32(RADEON_MM_INDEX, EVERGREEN_CUR_CONTROL + 
radeon_crtc->crtc_offset);
WREG32(RADEON_MM_DATA, EVERGREEN_CURSOR_EN |
   EVERGREEN_CURSOR_MODE(EVERGREEN_CURSOR_24_8_PRE_MULT) |
   
EVERGREEN_CURSOR_URGENT_CONTROL(EVERGREEN_CURSOR_URGENT_1_2));
} else if (ASIC_IS_AVIVO(rdev)) {
+   if (rdev->family >= CHIP_RV770) {
+   if (radeon_crtc->crtc_id)
+   WREG32(R700_D2CUR_SURFACE_ADDRESS_HIGH,
+  upper_32_bits(radeon_crtc->cursor_addr));
+   else
+   WREG32(R700_D1CUR_SURFACE_ADDRESS_HIGH,
+  upper_32_bits(radeon_crtc->cursor_addr));
+   }
+
+   WREG32(AVIVO_D1CUR_SURFACE_ADDRESS + radeon_crtc->crtc_offset,
+  lower_32_bits(radeon_crtc->cursor_addr));
WREG32(RADEON_MM_INDEX, AVIVO_D1CUR_CONTROL + 
radeon_crtc->crtc_offset);
WREG32(RADEON_MM_DATA, AVIVO_D1CURSOR_EN |
   (AVIVO_D1CURSOR_MODE_24BPP << 
AVIVO_D1CURSOR_MODE_SHIFT));
} else {
+   /* offset is from DISP(2)_BASE_ADDRESS */
+   WREG32(RADEON_CUR_OFFSET + radeon_crtc->crtc_offset,
+  radeon_crtc->cursor_addr - 
radeon_crtc->legacy_display_base_addr);
+
switch (radeon_crtc->crtc_id) {
case 0:
WREG32(RADEON_MM_INDEX, RADEON_CRTC_GEN_CNTL);
@@ -228,34 +247,6 @@ int radeon_crtc_cursor_move(struct drm_crtc *crtc,
return ret;
 }

-static void radeon_set_cursor(struct drm_crtc *crtc)
-{
-   struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
-   struct radeon_device *rdev = crtc->dev->dev_private;
-
-   if (ASIC_IS_DCE4(rdev)) {
-   WREG32(EVERGREEN_CUR_SURFACE_ADDRESS_HIGH + 
radeon_crtc->crtc_offset,
-  upper_32_bits(radeon_crtc->cursor_addr));
-   WREG32(EVERGREEN_CUR_SURFACE_ADDRESS + radeon_crtc->crtc_offset,
-  lower_32_bits(radeon_crtc->cursor_addr));
-   } else if (ASIC_IS_AVIVO(rdev)) {
-   if (rdev->family >= CHIP_RV770) {
-   if (radeon_crtc->crtc_id)
-   WREG32(R700_D2CUR_SURFACE_ADDRESS_HIGH,
-  upper_32_bits(radeon_crtc->cursor_addr));
-   else
-   WREG32(R700_D1CUR_SURFACE_ADDRESS_HIGH,
-  upper_32_bits(radeon_crtc->cursor_addr));
-   }
-   WREG32(AVIVO_D1CUR_SURFACE_ADDRESS + radeon_crtc->crtc_offset,
-  lower_32_bits(radeon_crtc->cursor_addr));
-   } else {
-   /* offset is from DISP(2)_BASE_ADDRESS */
-   WREG32(RADEON_CUR_OFFSET + radeon_crtc->crtc_offset,
-  radeon_crtc->cursor_addr - 
radeon_crtc->legacy_display_base_addr);
-   }
-}
-
 int radeon_crtc_cursor_set2(struct drm_crtc *crtc,
struct drm_file *file_priv,
uint32_t handle,
@@ -324,7 +315,6 @@ int radeon_crtc_cursor_set2(struct drm_crtc *crtc,
radeon_crtc->cursor_hot_y = hot_y;
}

-   radeon_set_cursor(crtc);
radeon_show_cursor(crtc);

radeon_lock_cursor(crtc, false);
@@ -362,7 +352,6 @@ void radeon_cursor_reset(struct drm_crtc *crtc)
radeon_cursor_move_locked(crtc, radeon_crtc->cursor_x,
  radeon_crtc->cursor_y);

-   radeon_set_cursor(crtc);
radeon_show_cursor(crtc);

radeon_lock_cursor(crtc, false);
-- 
2.1.4

[PATCH 2/3] drm/radeon: unpin cursor BOs on suspend and pin them again on resume

[Michel Dänzer]

From: Grigori Goronzy 

Everything is evicted from VRAM before suspend, so we need to make
sure all BOs are unpinned and re-pinned after resume. Fixes broken
mouse cursor after resume introduced by commit b9729b17.

[Michel Dänzer: Add pinning BOs on resume]

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=100541
Cc: stable at vger.kernel.org
Signed-off-by: Grigori Goronzy 
Signed-off-by: Michel Dänzer 
---
 drivers/gpu/drm/radeon/radeon_device.c | 36 ++
 1 file changed, 36 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index 12a18c8..5a075a9 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1593,6 +1593,20 @@ int radeon_suspend_kms(struct drm_device *dev, bool 
suspend, bool fbcon)
drm_helper_connector_dpms(connector, DRM_MODE_DPMS_OFF);
}

+   /* unpin cursors */
+   list_for_each_entry(crtc, >mode_config.crtc_list, head) {
+   struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
+
+   if (radeon_crtc->cursor_bo) {
+   struct radeon_bo *robj = 
gem_to_radeon_bo(radeon_crtc->cursor_bo);
+   r = radeon_bo_reserve(robj, false);
+   if (r == 0) {
+   radeon_bo_unpin(robj);
+   radeon_bo_unreserve(robj);
+   }
+   }
+   }
+
/* unpin the front buffers */
list_for_each_entry(crtc, >mode_config.crtc_list, head) {
struct radeon_framebuffer *rfb = 
to_radeon_framebuffer(crtc->primary->fb);
@@ -1660,6 +1674,7 @@ int radeon_resume_kms(struct drm_device *dev, bool 
resume, bool fbcon)
 {
struct drm_connector *connector;
struct radeon_device *rdev = dev->dev_private;
+   struct drm_crtc *crtc;
int r;

if (dev->switch_power_state == DRM_SWITCH_POWER_OFF)
@@ -1699,6 +1714,27 @@ int radeon_resume_kms(struct drm_device *dev, bool 
resume, bool fbcon)

radeon_restore_bios_scratch_regs(rdev);

+   /* pin cursors */
+   list_for_each_entry(crtc, >mode_config.crtc_list, head) {
+   struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
+
+   if (radeon_crtc->cursor_bo) {
+   struct radeon_bo *robj = 
gem_to_radeon_bo(radeon_crtc->cursor_bo);
+   r = radeon_bo_reserve(robj, false);
+   if (r == 0) {
+   /* Only 27 bit offset for legacy cursor */
+   r = radeon_bo_pin_restricted(robj,
+
RADEON_GEM_DOMAIN_VRAM,
+
ASIC_IS_AVIVO(rdev) ?
+0 : 1 << 27,
+
_crtc->cursor_addr);
+   if (r != 0)
+   DRM_ERROR("Failed to pin cursor BO 
(%d)\n", r);
+   radeon_bo_unreserve(robj);
+   }
+   }
+   }
+
/* init dig PHYs, disp eng pll */
if (rdev->is_atom_bios) {
radeon_atom_encoder_init(rdev);
-- 
2.1.4

[PATCH 1/3] drm/radeon: Clean up reference counting and pinning of the cursor BOs

[Michel Dänzer]

From: Michel Dänzer 

Take a GEM reference for and pin the new cursor BO, unpin and drop the
GEM reference for the old cursor BO in radeon_crtc_cursor_set2, and use
radeon_crtc->cursor_addr in radeon_set_cursor.

This fixes radeon_cursor_reset accidentally incrementing the cursor BO
pin count, and cleans up the code a little.

Cc: stable at vger.kernel.org
Signed-off-by: Michel Dänzer 
---
 drivers/gpu/drm/radeon/radeon_cursor.c | 84 +++---
 drivers/gpu/drm/radeon/radeon_mode.h   |  1 -
 2 files changed, 37 insertions(+), 48 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_cursor.c 
b/drivers/gpu/drm/radeon/radeon_cursor.c
index 45e5406..fa66174 100644
--- a/drivers/gpu/drm/radeon/radeon_cursor.c
+++ b/drivers/gpu/drm/radeon/radeon_cursor.c
@@ -205,8 +205,9 @@ static int radeon_cursor_move_locked(struct drm_crtc *crtc, 
int x, int y)
| (x << 16)
| y));
/* offset is from DISP(2)_BASE_ADDRESS */
-   WREG32(RADEON_CUR_OFFSET + radeon_crtc->crtc_offset, 
(radeon_crtc->legacy_cursor_offset +
- (yorigin 
* 256)));
+   WREG32(RADEON_CUR_OFFSET + radeon_crtc->crtc_offset,
+  radeon_crtc->cursor_addr - 
radeon_crtc->legacy_display_base_addr +
+  yorigin * 256);
}

radeon_crtc->cursor_x = x;
@@ -227,51 +228,32 @@ int radeon_crtc_cursor_move(struct drm_crtc *crtc,
return ret;
 }

-static int radeon_set_cursor(struct drm_crtc *crtc, struct drm_gem_object *obj)
+static void radeon_set_cursor(struct drm_crtc *crtc)
 {
struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
struct radeon_device *rdev = crtc->dev->dev_private;
-   struct radeon_bo *robj = gem_to_radeon_bo(obj);
-   uint64_t gpu_addr;
-   int ret;
-
-   ret = radeon_bo_reserve(robj, false);
-   if (unlikely(ret != 0))
-   goto fail;
-   /* Only 27 bit offset for legacy cursor */
-   ret = radeon_bo_pin_restricted(robj, RADEON_GEM_DOMAIN_VRAM,
-  ASIC_IS_AVIVO(rdev) ? 0 : 1 << 27,
-  _addr);
-   radeon_bo_unreserve(robj);
-   if (ret)
-   goto fail;

if (ASIC_IS_DCE4(rdev)) {
WREG32(EVERGREEN_CUR_SURFACE_ADDRESS_HIGH + 
radeon_crtc->crtc_offset,
-  upper_32_bits(gpu_addr));
+  upper_32_bits(radeon_crtc->cursor_addr));
WREG32(EVERGREEN_CUR_SURFACE_ADDRESS + radeon_crtc->crtc_offset,
-  gpu_addr & 0x);
+  lower_32_bits(radeon_crtc->cursor_addr));
} else if (ASIC_IS_AVIVO(rdev)) {
if (rdev->family >= CHIP_RV770) {
if (radeon_crtc->crtc_id)
-   WREG32(R700_D2CUR_SURFACE_ADDRESS_HIGH, 
upper_32_bits(gpu_addr));
+   WREG32(R700_D2CUR_SURFACE_ADDRESS_HIGH,
+  upper_32_bits(radeon_crtc->cursor_addr));
else
-   WREG32(R700_D1CUR_SURFACE_ADDRESS_HIGH, 
upper_32_bits(gpu_addr));
+   WREG32(R700_D1CUR_SURFACE_ADDRESS_HIGH,
+  upper_32_bits(radeon_crtc->cursor_addr));
}
WREG32(AVIVO_D1CUR_SURFACE_ADDRESS + radeon_crtc->crtc_offset,
-  gpu_addr & 0x);
+  lower_32_bits(radeon_crtc->cursor_addr));
} else {
-   radeon_crtc->legacy_cursor_offset = gpu_addr - 
radeon_crtc->legacy_display_base_addr;
/* offset is from DISP(2)_BASE_ADDRESS */
-   WREG32(RADEON_CUR_OFFSET + radeon_crtc->crtc_offset, 
radeon_crtc->legacy_cursor_offset);
+   WREG32(RADEON_CUR_OFFSET + radeon_crtc->crtc_offset,
+  radeon_crtc->cursor_addr - 
radeon_crtc->legacy_display_base_addr);
}
-
-   return 0;
-
-fail:
-   drm_gem_object_unreference_unlocked(obj);
-
-   return ret;
 }

 int radeon_crtc_cursor_set2(struct drm_crtc *crtc,
@@ -283,7 +265,9 @@ int radeon_crtc_cursor_set2(struct drm_crtc *crtc,
int32_t hot_y)
 {
struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
+   struct radeon_device *rdev = crtc->dev->dev_private;
struct drm_gem_object *obj;
+   struct radeon_bo *robj;
int ret;

if (!handle) {
@@ -305,6 +289,23 @@ int radeon_crtc_cursor_set2(struct drm_crtc *crtc,
return -ENOENT;
}

+   robj = gem_to_radeon_bo(obj);
+   ret = radeon_bo_reserve(robj, false);
+   if (ret != 0) {
+   drm_gem_object_unreference_unlocked(obj);
+   return ret;
+   }
+   /* Only 27 bit offset for legacy 

[PATCH 09/12] drm/i915: Add pipe level Gamma correction for CHV/BSW

[Matt Roper]

On Fri, Jul 03, 2015 at 09:01:44AM +0530, Kausal Malladi wrote:
> CHV/BSW platform supports various Gamma correction modes, which are:
> 1. Legacy 8-bit mode
> 2. 10-bit CGM (Color Gamut Mapping) mode
> 
> This patch does the following:
> 1. Adds the core function to program Gamma correction values for CHV/BSW
>platform
> 2. Adds Gamma correction macros/defines
> 
> Signed-off-by: Shashank Sharma 
> Signed-off-by: Kausal Malladi 
> ---
>  drivers/gpu/drm/i915/i915_reg.h|  10 ++
>  drivers/gpu/drm/i915/intel_atomic.c|   6 ++
>  drivers/gpu/drm/i915/intel_color_manager.c | 154 
> +
>  drivers/gpu/drm/i915/intel_color_manager.h |  12 +++
>  drivers/gpu/drm/i915/intel_drv.h   |   2 +
>  5 files changed, 184 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 313b1f9..36672e7 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7900,4 +7900,14 @@ enum skl_disp_power_wells {
>  #define _PALETTE_A (dev_priv->info.display_mmio_offset + 0xa000)
>  #define _PALETTE_B (dev_priv->info.display_mmio_offset + 0xa800)
>  
> +/* Color Management */
> +#define PIPEA_CGM_CONTROL(VLV_DISPLAY_BASE + 0x67A00)
> +#define PIPEA_CGM_GAMMA_MIN  (VLV_DISPLAY_BASE + 0x67000)
> +#define CGM_OFFSET   0x2000
> +#define GAMMA_OFFSET 0x2000
> +#define _PIPE_CGM_CONTROL(pipe) \
> + (PIPEA_CGM_CONTROL + (pipe * CGM_OFFSET))
> +#define _PIPE_GAMMA_BASE(pipe) \
> + (PIPEA_CGM_GAMMA_MIN + (pipe * GAMMA_OFFSET))
> +
>  #endif /* _I915_REG_H_ */
> diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
> b/drivers/gpu/drm/i915/intel_atomic.c
> index d2674a6..21f0ac2 100644
> --- a/drivers/gpu/drm/i915/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/intel_atomic.c
> @@ -473,6 +473,12 @@ int intel_crtc_atomic_set_property(struct drm_crtc *crtc,
>  struct drm_property *property,
>  uint64_t val)
>  {
> + struct drm_device *dev = crtc->dev;
> + struct drm_mode_config *config = >mode_config;
> +
> + if (property == config->prop_palette_after_ctm)
> + return intel_color_manager_set_gamma(dev, >base, val);
> +

I think we discussed this on a previous iteration of the patch series,
but .atomic_set_property() isn't supposed to actually update the
hardware at all itself (as you're doing here); it's only supposed to
update the 'state' parameter that was passed here.  Further down the
atomic pipeline the driver will decide whether it really wants to
program any of the state or not and then the CRTC's atomic commit
function should program the registers according to whatever value is set
in the state object.

>   DRM_DEBUG_KMS("Unknown crtc property '%s'\n", property->name);
>   return -EINVAL;
>  }
> diff --git a/drivers/gpu/drm/i915/intel_color_manager.c 
> b/drivers/gpu/drm/i915/intel_color_manager.c
> index 71b4c05..84cc3e47 100644
> --- a/drivers/gpu/drm/i915/intel_color_manager.c
> +++ b/drivers/gpu/drm/i915/intel_color_manager.c
> @@ -27,6 +27,160 @@
>  
>  #include "intel_color_manager.h"
>  
> +int chv_set_gamma(struct drm_device *dev, uint32_t blob_id,
> +   struct drm_crtc *crtc)
> +{
> + struct drm_palette *gamma_data;
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + struct drm_property_blob *blob;
> + struct drm_mode_config *config = >mode_config;
> + u32 cgm_control_reg = 0;
> + u32 cgm_gamma_reg = 0;
> + u32 reg, val;
> + enum pipe pipe;
> + u16 red, green, blue;
> + u32 count = 0;
> + struct drm_r32g32b32 *correction_values = NULL;
> + u32 num_samples;
> + u32 word;
> + u32 palette;
> + int ret = 0, length;
> +
> + blob = drm_property_lookup_blob(dev, blob_id);
> + if (!blob) {
> + DRM_ERROR("Invalid Blob ID\n");
> + return -EINVAL;
> + }
> +
> + gamma_data = (struct drm_palette *)blob->data;

Do we need to validate that the blob we receive is of the expected size
or does something in the DRM core's blob handling take care of that for
us?  We don't want userspace to be able to trigger a panic by passing a
smaller than expected blob here.


> +
> + if (gamma_data->version != CHV_GAMMA_DATA_STRUCT_VERSION) {
> + DRM_ERROR("Invalid Gamma Data struct version\n");
> + return -EINVAL;
> + }
> +
> + pipe = to_intel_crtc(crtc)->pipe;
> + num_samples = gamma_data->palette_num_samples;
> + length = num_samples * sizeof(struct drm_r32g32b32);
> +
> + if (num_samples == 0) {
> +
> + /* Disable Gamma functionality on Pipe - CGM Block */
> + cgm_control_reg = I915_READ(_PIPE_CGM_CONTROL(pipe));
> + cgm_control_reg &= ~CGM_GAMMA_EN;
> + I915_WRITE(_PIPE_CGM_CONTROL(pipe), cgm_control_reg);
> +
> + 

[PATCH 03/12] drm/i915: Attach color properties to CRTC

[Matt Roper]

On Fri, Jul 03, 2015 at 09:01:38AM +0530, Kausal Malladi wrote:
> This patch does the following:
> 1. Adds new files intel_color_manager(.c/.h)
> 2. Attaches color properties to CRTC while initialization
> 
> Signed-off-by: Shashank Sharma 
> Signed-off-by: Kausal Malladi 
> ---
>  drivers/gpu/drm/i915/Makefile  |  3 +-
>  drivers/gpu/drm/i915/intel_color_manager.c | 61 
> ++
>  drivers/gpu/drm/i915/intel_color_manager.h | 28 ++
>  drivers/gpu/drm/i915/intel_display.c   |  3 ++
>  drivers/gpu/drm/i915/intel_drv.h   |  4 ++
>  5 files changed, 98 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/i915/intel_color_manager.c
>  create mode 100644 drivers/gpu/drm/i915/intel_color_manager.h
> 
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index de21965..ad928d8 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -56,7 +56,8 @@ i915-y += intel_audio.o \
> intel_overlay.o \
> intel_psr.o \
> intel_sideband.o \
> -   intel_sprite.o
> +   intel_sprite.o \
> +   intel_color_manager.o
>  i915-$(CONFIG_ACPI)  += intel_acpi.o intel_opregion.o
>  i915-$(CONFIG_DRM_I915_FBDEV)+= intel_fbdev.o
>  
> diff --git a/drivers/gpu/drm/i915/intel_color_manager.c 
> b/drivers/gpu/drm/i915/intel_color_manager.c
> new file mode 100644
> index 000..9280ea6
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/intel_color_manager.c
> @@ -0,0 +1,61 @@
> +/*
> + * Copyright © 2015 Intel Corporation
> + *
> + * 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 (including the next
> + * paragraph) 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 AUTHORS OR COPYRIGHT HOLDERS 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.
> + *
> + * Authors:
> + * Shashank Sharma 
> + * Kausal Malladi 
> + */
> +
> +#include "intel_color_manager.h"
> +
> +void intel_color_manager_attach(struct drm_device *dev,
> + struct drm_mode_object *mode_obj)
> +{
> + struct drm_mode_config *config = >mode_config;
> +
> + if (mode_obj->type == DRM_MODE_OBJECT_CRTC) {

Is the expectation that this function will grow to include plane
properties as well?  Personally I think it would be a little easier to
read/follow if we had separate functions for attaching the crtc
properties and the (eventual) plane properties, but it's not a huge
deal.

> + if (config->prop_color_capabilities) {
> + drm_object_attach_property(mode_obj,
> + config->prop_color_capabilities, 0);
> + DRM_DEBUG_DRIVER("Attached Color Caps property to 
> CRTC\n");
> + } else
> + DRM_ERROR("Error attaching Color Capabilities property 
> to CRTC\n");
> + if (config->prop_palette_before_ctm) {
> + drm_object_attach_property(mode_obj,
> + config->prop_palette_before_ctm, 0);
> + DRM_DEBUG_DRIVER("Attached Palette (before CTM) 
> property to CRTC\n");
> + } else
> + DRM_ERROR("Error attaching Palette (before CTM) 
> property to CRTC\n");
> + if (config->prop_palette_after_ctm) {
> + drm_object_attach_property(mode_obj,
> + config->prop_palette_after_ctm, 0);
> + DRM_DEBUG_DRIVER("Attached Palette (after CTM) property 
> to CRTC\n");
> + } else
> + DRM_ERROR("Error attaching Palette (after CTM) property 
> to CRTC\n");
> + if (config->prop_ctm) {
> + drm_object_attach_property(mode_obj,
> + config->prop_ctm, 0);
> + DRM_DEBUG_DRIVER("Attached CTM property to CRTC\n");
> + } else
> + DRM_ERROR("Error attaching CTM property to CRTC\n");
> + }

I agree with Damien's note that we can probably drop 

[PATCH 02/12] drm: Create Color Management DRM properties

[Matt Roper]

On Fri, Jul 03, 2015 at 09:01:37AM +0530, Kausal Malladi wrote:
> Color Management is an extension to Kernel display framework. It allows
> abstraction of hardware color correction and enhancement capabilities by
> virtue of DRM properties.
> 
> This patch initializes color management framework by :
> 1. Introducing new pointers in DRM mode_config structure to
>carry CTM and Palette color correction properties.
> 2. Creating these DRM properties in DRM standard properties creation
>sequence.
> 
> Signed-off-by: Shashank Sharma 
> Signed-off-by: Kausal Malladi 
> ---
>  drivers/gpu/drm/drm_crtc.c | 24 
>  include/drm/drm_crtc.h |  6 ++
>  2 files changed, 30 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 2d57fc5..5d12ea9 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -1462,6 +1462,30 @@ static int drm_mode_create_standard_properties(struct 
> drm_device *dev)
>   return -ENOMEM;
>   dev->mode_config.prop_mode_id = prop;
>  
> + /* Color Management properties */
> + prop = drm_property_create(dev,
> + DRM_MODE_PROP_BLOB | DRM_MODE_PROP_IMMUTABLE,
> + "COLOR_CAPABILITIES", 0);

Is there a specific reason you don't check for NULL on this property
like you do on all the others, or is this just an oversight?


Matt

> + dev->mode_config.prop_color_capabilities = prop;
> +
> + prop = drm_property_create(dev,
> + DRM_MODE_PROP_BLOB, "PALETTE_AFTER_CTM", 0);
> + if (!prop)
> + return -ENOMEM;
> + dev->mode_config.prop_palette_after_ctm = prop;
> +
> + prop = drm_property_create(dev,
> + DRM_MODE_PROP_BLOB, "PALETTE_BEFORE_CTM", 0);
> + if (!prop)
> + return -ENOMEM;
> + dev->mode_config.prop_palette_before_ctm = prop;
> +
> + prop = drm_property_create(dev,
> + DRM_MODE_PROP_BLOB, "CTM", 0);
> + if (!prop)
> + return -ENOMEM;
> + dev->mode_config.prop_ctm = prop;
> +
>   return 0;
>  }
>  
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 57ca8cc..408d39a 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -1178,6 +1178,12 @@ struct drm_mode_config {
>   struct drm_property *suggested_x_property;
>   struct drm_property *suggested_y_property;
>  
> + /* Color Management Properties */
> + struct drm_property *prop_color_capabilities;
> + struct drm_property *prop_palette_before_ctm;
> + struct drm_property *prop_palette_after_ctm;
> + struct drm_property *prop_ctm;
> +
>   /* dumb ioctl parameters */
>   uint32_t preferred_depth, prefer_shadow;
>  
> -- 
> 2.4.5
> 

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795

[PATCH] drm: add a check for x/y in drm_mode_setcrtc

[John Hunter]

From: Zhao Junwang 

legacy setcrtc ioctl does take a 32 bit value which might indeed
overflow

the checks of crtc_req->x > INT_MAX and crtc_req->y > INT_MAX aren't
needed any more with this

Cc: Daniel Vetter 
Signed-off-by: Zhao Junwang 
---
 drivers/gpu/drm/drm_crtc.c |7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index b69ed97..c307435 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2706,8 +2706,11 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
if (!drm_core_check_feature(dev, DRIVER_MODESET))
return -EINVAL;

-   /* For some reason crtc x/y offsets are signed internally. */
-   if (crtc_req->x > INT_MAX || crtc_req->y > INT_MAX)
+   /*
+* Legacy setcrtc ioctl does take a 32 bit value which might
+* overflow
+*/
+   if (crtc_req->x & 0x || crtc_req->y & 0x)
return -ERANGE;

drm_modeset_lock_all(dev);
-- 
1.7.10.4

[Bug 66963] Rv6xx dpm problems

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

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

--- Comment #275 from Nicola Mori  ---
(In reply to Kajzer from comment #274)
> Anyway, it doesn't matter, seems like I'm the only one with this issue, or
> at least the only one reporting it.

You are not the only one, Kajzer. I have exactly the same issue on my RV620,
but I don't have the possibility to bisect nor I know how to do it. I
appreciate your efforts very much and I'm closely following your conversation
with Michel hoping that in the end this nasty bug will be finally squashed. I
was silent because comments like "me too" are useless, but this does not mean
that nobody is interested in this issue (I'd say rather the opposite given the
number of CC'ers).

-- 
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/20150707/5fc64369/attachment-0001.html>

[PATCH 2/3] drm/ttm: fix object deallocation to properly fill in the page pool.

[Michel Dänzer]

On 07.07.2015 01:10, Jerome Glisse wrote:
> On Mon, Jul 06, 2015 at 06:11:29PM +0900, Michel Dänzer wrote:
>>
>> Hi Jérôme,
>>
>> On 13.08.2014 12:52, Jérôme Glisse wrote:
>>> From: Jérôme Glisse 
>>>
>>> Current code never allowed the page pool to actualy fill in anyway. This fix
>>> it and also allow it to grow over its limit until it grow beyond the batch
>>> size for allocation and deallocation.
>>>
>>> Signed-off-by: Jérôme Glisse 
>>> Reviewed-by: Mario Kleiner 
>>> Tested-by: Michel Dänzer 
>>> Cc: Thomas Hellstrom 
>>> Cc: Konrad Rzeszutek Wilk 
>>> ---
>>>  drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 9 ++---
>>>  1 file changed, 2 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c 
>>> b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
>>> index c96db43..a076ff3 100644
>>> --- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
>>> +++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
>>> @@ -953,14 +953,9 @@ void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma, 
>>> struct device *dev)
>>> } else {
>>> pool->npages_free += count;
>>> list_splice(_dma->pages_list, >free_list);
>>> -   npages = count;
>>> -   if (pool->npages_free > _manager->options.max_size) {
>>> +   if (pool->npages_free >= (_manager->options.max_size +
>>> + NUM_PAGES_TO_ALLOC))
>>> npages = pool->npages_free - _manager->options.max_size;
>>> -   /* free at least NUM_PAGES_TO_ALLOC number of pages
>>> -* to reduce calls to set_memory_wb */
>>> -   if (npages < NUM_PAGES_TO_ALLOC)
>>> -   npages = NUM_PAGES_TO_ALLOC;
>>> -   }
>>> }
>>> spin_unlock_irqrestore(>lock, irq_flags);
>>>  
>>>
>>
>> Colleagues of mine have measured significant performance gains for some
>> workloads with this patch. Without it, a lot of CPU cycles are spent
>> changing the caching attributes of pages on allocation.
>>
>> Note that the performance effect seems to mostly disappear when applying
>> patch 1 as well, so apparently 64MB is too small for the max pool size.
>>
>> Is there any chance this patch could be applied without the
>> controversial patch 3? If not, do you have ideas for addressing the
>> concerns raised against patch 3?
> 
> Wahou, now i need to find the keys to the DeLorean to travel back in time.
> 
> This patch is a fix and should be applied without 1 or 3. Because today
> basicly the pool is always emptied and never fill up. But as Thomas pointed
> out there is already bit too much pool accross the stack. Proper solution
> would be to work something inside the mm level or the architecture (i assume
> AMD is mostly interested in x86 on that front).
> 
> Here the whole issue is really about allocating page with WC/UC cache
> properties. Changing cache properties on page is really costly on several
> level, like the kernel needs to break the huge linear mapping and populate
> lower level to remap the page with proper cache attribute inside the kernel
> mapping.
> 
> As far as i remember the kernel never goes back to huge page mapping when
> restoring page cache attribute, which meaning that little by litte with
> uptime you loose the whole huge page mapping benefit for everything and you
> waste more memory.

That sounds pretty bad, but this patch might actually help a little for
that by reducing the amount of huge page mappings that need to be broken up?


> In meantime i think we need to apply this patch as it is really a fix to
> make the code actually do what the comment and design pretends it does.

I agree.

BTW, maybe it should be split up into the actual fix (removing the
npages assignment) and the NUM_PAGES_TO_ALLOC related simplification?


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

[Bug 91253] Regression: Can't boot on 4.0.5 and later but can boot on 4.0.4 (on iMac)

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

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

--- Comment #4 from Alex Deucher  ---
There are tons of git bisect howtos.  You will need to checkout the stable
kernel git tree, build and install it.  Here are the basics:

# 1. clone the git tree
git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
cd linux-stable
# 2. copy the config from your currently running kernel
cp /boot/config-4.0.4- .config
# 3. start the bisect
git bisect start
git bisect good v4.0.4
git bisect bad v4.0.5
# 4. build and install the kernel
make
make modules_install
make install
# 5. reboot and test of the kernel is working
# 6a. if so mark the commit as good
git bisect good
# 6b. else mark it as bad
git bisect bad
# 7. repeat steps 4-6 until git has identified the problematic commit

-- 
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/20150707/f2c8f5fa/attachment.html>

[Bug 81689] Black screen in info-beamer

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

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

--- Comment #1 from Vasilis LIaskovitis  ---
This also happens with radeonsi and very recent mesa.

Link to ticket from infobeamer's bug tracker:
https://github.com/dividuum/info-beamer/issues/28

System environment:
-- system architecture: 64-bit
-- Linux distribution: Ubuntu 14.04 with ppa:oibaf/graphics-drivers
-- GPU: Pitcairn XT 
-- Model: Radeon HD 7870 GHz Edition
-- Display connector: HDMI
-- xf86-xorg-video-ati: 1:7.5.99+git1506291932.fc07c3~gd~t
-- mesa: 10.7~git1507051930.fc2726~gd~t
-- libdrm: 2.4.62+git1506301830.676c80~gd~t
-- kernel: 3.19.0-21-generic

Other drivers (i965 nd fglrx) display infobeamer 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/20150707/5f92d7f9/attachment.html>

[PATCH 1/2] drm: rockchip: Don't pass DRM fake offset to dma-api

[Daniel Kurtz]

On Sun, Apr 19, 2015 at 12:55 AM, Heiko Stübner  wrote:
>
> Am Donnerstag, 16. April 2015, 16:41:51 schrieb Ørjan Eide:
> > Set vm_pgoff to 0 after using it to look up the GEM node, before passing
> > it on rockchip_gem_mmap_buf() where the offset must be from the start of
> > the buffer.
> >
> > Passing in the fake offset currently works because the
> > dma_mmap_attrs implementation that is used for this device,
> > arm_iommu_mmap_attrs, ignores the offset completely.
> >
> > Signed-off-by: Ørjan Eide 
>
> both patches on a rk3288-veyron-pinky
>
> Tested-by: Heiko Stuebner 
>
> Through which tree do you want to take these patches? I guess the rockchip-drm
> related patch should go through the tree that will take the dma-mapping patch,
> so you'll probably need an "Ack" from Mark Yao (Cc'ed).

As far as I can tell, these two patches ([0] & [1]) were never picked up.
Russell, can you pick both of them up in your tree?

[0] https://patchwork.kernel.org/patch/6226591/
[1] https://patchwork.kernel.org/patch/6226581/

-Dan

> Heiko
>
> > ---
> >  drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 5 +
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> > b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c index 7ca8799e..69f01c3
> > 100644
> > --- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> > @@ -94,6 +94,11 @@ int rockchip_gem_mmap(struct file *filp, struct
> > vm_area_struct *vma) return -EACCES;
> >   }
> >
> > + /* Set vm_pgoff (used as a fake buffer offset by DRM) to 0 and map the
> > +  * whole buffer from the start.
> > +  */
> > + vma->vm_pgoff = 0;
> > +
> >   obj = container_of(node, struct drm_gem_object, vma_node);
> >   ret = rockchip_gem_mmap_buf(obj, vma);
>

[Bug 66963] Rv6xx dpm problems

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

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

--- Comment #274 from Kajzer  ---
(In reply to Michel Dänzer from comment #273)
> The original description of this report says: "screen becomes blank after
> grub trying to boot it". Please file your own report.

When it happens screen freeze for a few seconds, then it goes blank for a few
seconds, then it comes back with strange artifacts on the screen, system is
basically unresponsive, the only thing you can do is a hard reset.


> Please run a kernel built from commit
> 77497f2735ad6e29c55475e15e9790dbfa2c2ef8 (the commit before
> 02376d8282b88f07d0716da6155094c8760b1a13) for at least a few days to make
> sure it doesn't happen with that.

That's gonna be a problem, I don't have that image anymore.

Anyway, it doesn't matter, seems like I'm the only one with this issue, or at
least the only one reporting it. Main thing is that dpm finally works without
problems with profile set to high, except (in my case) problem happens again,
but only with kernels 3.17 and above and only when playing games. Could be mesa
related somehow in combination with something introduced in kernel 3.17.
One thing I can say for sure, with kernels 3.16 and below mesa version doesn't
matter, I tried every mesa from 10.0 to 10.6 and this problem never happened.
It's something in the kernel but I guess it's very tricky to determine which
commit exactly. There are 57 commits between 3.16 and 3.17

-- 
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/20150707/3a4a19a2/attachment-0001.html>

R200 DRM/KMS

[Steven Newbury]

gt; > some
> > > > part of the gfx stack is miscompiled, I tested it pretty 
> > > > throughly
> > > > under qemu (with qxl) before deployment, but that of course 
> > > > didn't
> > > > exercise the R200 driver.  FWIW, other than the failing DRI,
> > > > performance is surprisingly OK, not super fast obviously, but 
> > > > a 
> > > > *lot*
> > > > better than under Ubuntu! (start-up time is alot quicker, by 
> > > > an 
> > > > order
> > > > of magnitude!)
> > > > 
> > > > I'm attempting to downgrade the xserver and drivers (on the 
> > > > live
> > > > system) to see if that works, you can imagine that takes a 
> > > > little
> > > > while on a Coppermine-128!  I'll find out tomorrow. 
> > > >  Otherwise, I
> > > > guess I'm recompiling the stack with gcc-4.9 and no-LTO...
> 
Sorry about the accidental e-mail.

I've tried an xserver-1.16, and ddx, libdrm without LTO and with
gcc4.9.  Exactly the same thing.  I wondered whether the unused i810
could be interfering but triggering a device "remove" before starting 
X made no difference.

I'm a bit of a loss.  I suppose I could try writing a simple test for
drmSetInterfaceVersion().  At least that should determine whether the
xserver/ddx is in the clear.

Any other ideas?

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150707/b2112731/attachment-0001.sig>

[Bug 101131] Regression: Can't boot on 4.0.5 and later but can boot on 4.0.4 (on iMac)

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

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

--- Comment #3 from Andreas Tunek  ---
Created attachment 182091
  --> https://bugzilla.kernel.org/attachment.cgi?id=182091=edit
dmesg

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

[Bug 91253] Regression: Can't boot on 4.0.5 and later but can boot on 4.0.4 (on iMac)

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

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

--- Comment #3 from Andreas Tunek  ---
Do you know any guide on how to bisect while using Fedora?

-- 
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/20150707/0549325e/attachment.html>

[Bug 101131] Regression: Can't boot on 4.0.5 and later but can boot on 4.0.4 (on iMac)

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

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

--- Comment #2 from Andreas Tunek  ---
I can not bisect upstream Linux, maybe fedora versions...

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

[Bug 91141] Lots of *ERROR* Couldn't update BO_VA (-22) since drm/radeon: stop using addr to check for BO move

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

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

--- Comment #16 from hadack at gmx.de ---
Still working fine here, I tested all ways to trigger it and its fine. Feel
free to add the tested-by.

-- 
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/20150707/693c290d/attachment.html>

[Intel-gfx] [PATCH v2 02/20] drm: Don't update plane properties for atomic planes if it stays the same

[Daniel Vetter]

On Tue, Jul 07, 2015 at 12:20:10PM +0200, Maarten Lankhorst wrote:
> Op 07-07-15 om 11:18 schreef Daniel Vetter:
> > On Tue, Jul 07, 2015 at 09:08:13AM +0200, Maarten Lankhorst wrote:
> >> This allows the first atomic call during hw init to be a real modeset,
> >> which is useful for forcing a recalculation.
> > fbcon is optional, you can't rely on anything being done in any specific
> > way. What exactly do you need this for, what's the implications?
> In the hw readout I noticed some warnings when I wasn't setting any mode 
> property in the readout.
> I want the first function to be the modeset, so we have a sane base to commit 
> changes on.
> Ideally this whole function would have a atomic counterpart which does it in 
> one go. :)

Yeah. Otoh as soon as we have atomic modeset working we can replace all
the legacy entry points with atomic helpers, and then even plane_disable
will be a full atomic modeset.

What did fall apart with just touching properties/planes now?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH v2] drm: add a check for x/y in drm_mode_setcrtc

[Daniel Vetter]

On Tue, Jul 07, 2015 at 05:08:35PM +0800, John Hunter wrote:
> From: Zhao Junwang 
> 
> legacy setcrtc ioctl does take a 32 bit value which might indeed
> overflow
> 
> the checks of crtc_req->x > INT_MAX and crtc_req->y > INT_MAX aren't
> needed any more with this
> 
> v2: -polish the annotation according to Daniel's comment
> 
> Cc: Daniel Vetter 
> Signed-off-by: Zhao Junwang 

Applied to topic/drm-fixes with cc: stable.

Thanks, Daniel

> ---
>  drivers/gpu/drm/drm_crtc.c |7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index b69ed97..745fc78 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -2706,8 +2706,11 @@ int drm_mode_setcrtc(struct drm_device *dev, void 
> *data,
>   if (!drm_core_check_feature(dev, DRIVER_MODESET))
>   return -EINVAL;
>  
> - /* For some reason crtc x/y offsets are signed internally. */
> - if (crtc_req->x > INT_MAX || crtc_req->y > INT_MAX)
> + /*
> +  * Universal plane src offsets are only 16.16, prevent havoc for
> +  * drivers using universal plane code internally.
> +  */
> + if (crtc_req->x & 0x || crtc_req->y & 0x)
>   return -ERANGE;
>  
>   drm_modeset_lock_all(dev);
> -- 
> 1.7.10.4
> 
> 
> ___
> 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] drm/rockchip: use drm_gem_mmap helpers

[Daniel Vetter]

On Tue, Jul 07, 2015 at 05:03:36PM +0800, Daniel Kurtz wrote:
> Rather than (incompletely [0]) re-implementing drm_gem_mmap() and
> drm_gem_mmap_obj() helpers, call them directly from the rockchip mmap
> routines.
> 
> Once the core functions return successfully, the rockchip mmap routines
> can still use dma_mmap_attrs() to simply mmap the entire buffer.
> 
> [0] Previously, we were performing the mmap() without first taking a
> reference on the underlying gem buffer.  This could leak ptes if the gem
> object is destroyed while userspace is still holding the mapping.
> 
> Signed-off-by: Daniel Kurtz 
> Reviewed-by: Daniel Vetter 
> Cc: stable at vger.kernel.org

Applied to topic/drm-fixes to make sure it won't get lost, but I expect
rockchip maintainers to pick this one up.
-Daniel

> 
> ---
>  drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 67 
> +++--
>  1 file changed, 34 insertions(+), 33 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> index eb2282c..eba5f8a 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> @@ -54,55 +54,56 @@ static void rockchip_gem_free_buf(struct 
> rockchip_gem_object *rk_obj)
>  _obj->dma_attrs);
>  }
>  
> -int rockchip_gem_mmap_buf(struct drm_gem_object *obj,
> -   struct vm_area_struct *vma)
> +static int rockchip_drm_gem_object_mmap(struct drm_gem_object *obj,
> + struct vm_area_struct *vma)
> +
>  {
> + int ret;
>   struct rockchip_gem_object *rk_obj = to_rockchip_obj(obj);
>   struct drm_device *drm = obj->dev;
> - unsigned long vm_size;
>  
> - vma->vm_flags |= VM_IO | VM_DONTEXPAND | VM_DONTDUMP;
> - vm_size = vma->vm_end - vma->vm_start;
> -
> - if (vm_size > obj->size)
> - return -EINVAL;
> + /*
> +  * dma_alloc_attrs() allocated a struct page table for rk_obj, so clear
> +  * VM_PFNMAP flag that was set by drm_gem_mmap_obj()/drm_gem_mmap().
> +  */
> + vma->vm_flags &= ~VM_PFNMAP;
>  
> - return dma_mmap_attrs(drm->dev, vma, rk_obj->kvaddr, rk_obj->dma_addr,
> + ret = dma_mmap_attrs(drm->dev, vma, rk_obj->kvaddr, rk_obj->dma_addr,
>obj->size, _obj->dma_attrs);
> + if (ret)
> + drm_gem_vm_close(vma);
> +
> + return ret;
>  }
>  
> -/* drm driver mmap file operations */
> -int rockchip_gem_mmap(struct file *filp, struct vm_area_struct *vma)
> +int rockchip_gem_mmap_buf(struct drm_gem_object *obj,
> +   struct vm_area_struct *vma)
>  {
> - struct drm_file *priv = filp->private_data;
> - struct drm_device *dev = priv->minor->dev;
> - struct drm_gem_object *obj;
> - struct drm_vma_offset_node *node;
> + struct drm_device *drm = obj->dev;
>   int ret;
>  
> - if (drm_device_is_unplugged(dev))
> - return -ENODEV;
> + mutex_lock(>struct_mutex);
> + ret = drm_gem_mmap_obj(obj, obj->size, vma);
> + mutex_unlock(>struct_mutex);
> + if (ret)
> + return ret;
>  
> - mutex_lock(>struct_mutex);
> + return rockchip_drm_gem_object_mmap(obj, vma);
> +}
>  
> - node = drm_vma_offset_exact_lookup(dev->vma_offset_manager,
> -vma->vm_pgoff,
> -vma_pages(vma));
> - if (!node) {
> - mutex_unlock(>struct_mutex);
> - DRM_ERROR("failed to find vma node.\n");
> - return -EINVAL;
> - } else if (!drm_vma_node_is_allowed(node, filp)) {
> - mutex_unlock(>struct_mutex);
> - return -EACCES;
> - }
> +/* drm driver mmap file operations */
> +int rockchip_gem_mmap(struct file *filp, struct vm_area_struct *vma)
> +{
> + struct drm_gem_object *obj;
> + int ret;
>  
> - obj = container_of(node, struct drm_gem_object, vma_node);
> - ret = rockchip_gem_mmap_buf(obj, vma);
> + ret = drm_gem_mmap(filp, vma);
> + if (ret)
> + return ret;
>  
> - mutex_unlock(>struct_mutex);
> + obj = vma->vm_private_data;
>  
> - return ret;
> + return rockchip_drm_gem_object_mmap(obj, vma);
>  }
>  
>  struct rockchip_gem_object *
> -- 
> 2.4.3.573.g4eafbef
> 

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

[PATCH v2 01/20] drm/atomic: add connectors_changed to separate it from mode_changed

[Daniel Vetter]

On Tue, Jul 07, 2015 at 12:05:40PM +0200, Maarten Lankhorst wrote:
> Op 07-07-15 om 10:59 schreef Daniel Vetter:
> > On Tue, Jul 07, 2015 at 09:08:12AM +0200, Maarten Lankhorst wrote:
> >> @@ -373,7 +375,17 @@ drm_atomic_helper_check_modeset(struct drm_device 
> >> *dev,
> >>if (crtc->state->enable != crtc_state->enable) {
> >>DRM_DEBUG_ATOMIC("[CRTC:%d] enable changed\n",
> >> crtc->base.id);
> >> +
> >> +  /*
> >> +   * For clarity this assignment is done here, but
> >> +   * enable == 0 is only true when there are no
> >> +   * connectors and a NULL mode.
> >> +   *
> >> +   * The other way around is true as well. enable != 0
> >> +   * iff connectors are attached and a mode is set.
> >> +   */
> >>crtc_state->mode_changed = true;
> > I'd drop this one so that connectors_changed and mode_changed are truly
> > orthogonal. Also ->enable implies connectors changed since we do check
> > that there's only connected connectors if the crtc is on. Needs kerneldoc
> > update too ofc.
> 
> They are orthogonal, think of this case:
> 
> 1. crtc previously enabled, connector removed, mode stays same ->
>   connector_changed = true, mode_changed = false
> 
> 2. crtc previously enabled, connectors stay the same, different mode -> 
>   connectors_changed = false, mode_changed = true
> 
> The following is enforced by the checks:
> crtc disabled, implies 0 connectors, no mode.
> crtc enabled implies > 0 connectors, and a mode.
> 
> Hence the connectors_changed and mode_changed here are for documentation 
> purposes only. :)
> 
> So if someone wonders what happens when enable is changed they don't have to 
> dig through
> the entire drm_atomic_helper_check_modeset function and still not be sure if 
> it's coincidence
> or not. 
> 
> You're right about the kerneldoc, I'll fix it.

Right, I guess I should have read your comment properly and disregarded
the kerneldoc ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[Bug 101131] Regression: Can't boot on 4.0.5 and later but can boot on 4.0.4 (on iMac)

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

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

Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeucher at gmail.com

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

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

[Bug 91141] Lots of *ERROR* Couldn't update BO_VA (-22) since drm/radeon: stop using addr to check for BO move

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

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

--- Comment #15 from Dave Witbrodt  ---
(In reply to Christian König from comment #12)
> Created attachment 116973 [details]
> Possible fix part 2
> 
> Please apply this one on top of the first fix and see if the problem still
> happen.

Works good on my machine.  The programs that triggered the bug before no longer
cause any problems.

Sanity check:  I had dropped 161ab658 and b13e22ae from my list of cherry picks
before in order to have a working kernel.  After adding those back, and
applying

0001-drm-radeon-allways-add-the-VM-clear-duplicate.patch
0001-drm-radeon-check-if-BO_VA-is-set-before-adding-it-to.patch

everything works great again.  I have not yet tested suspend-to-RAM, but after
the testing I've done so far I doubt there will be problems.

HTH,
DW

-- 
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/20150707/dc550132/attachment.html>

[PATCH 2/3] drm/ttm: fix object deallocation to properly fill in the page pool.

[Jerome Glisse]

On Tue, Jul 07, 2015 at 03:39:29PM +0900, Michel Dänzer wrote:
> On 07.07.2015 01:10, Jerome Glisse wrote:
> > On Mon, Jul 06, 2015 at 06:11:29PM +0900, Michel Dänzer wrote:
> >>
> >> Hi Jérôme,
> >>
> >> On 13.08.2014 12:52, Jérôme Glisse wrote:
> >>> From: Jérôme Glisse 
> >>>
> >>> Current code never allowed the page pool to actualy fill in anyway. This 
> >>> fix
> >>> it and also allow it to grow over its limit until it grow beyond the batch
> >>> size for allocation and deallocation.
> >>>
> >>> Signed-off-by: Jérôme Glisse 
> >>> Reviewed-by: Mario Kleiner 
> >>> Tested-by: Michel Dänzer 
> >>> Cc: Thomas Hellstrom 
> >>> Cc: Konrad Rzeszutek Wilk 
> >>> ---
> >>>  drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 9 ++---
> >>>  1 file changed, 2 insertions(+), 7 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c 
> >>> b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
> >>> index c96db43..a076ff3 100644
> >>> --- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
> >>> +++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
> >>> @@ -953,14 +953,9 @@ void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma, 
> >>> struct device *dev)
> >>>   } else {
> >>>   pool->npages_free += count;
> >>>   list_splice(_dma->pages_list, >free_list);
> >>> - npages = count;
> >>> - if (pool->npages_free > _manager->options.max_size) {
> >>> + if (pool->npages_free >= (_manager->options.max_size +
> >>> +   NUM_PAGES_TO_ALLOC))
> >>>   npages = pool->npages_free - _manager->options.max_size;
> >>> - /* free at least NUM_PAGES_TO_ALLOC number of pages
> >>> -  * to reduce calls to set_memory_wb */
> >>> - if (npages < NUM_PAGES_TO_ALLOC)
> >>> - npages = NUM_PAGES_TO_ALLOC;
> >>> - }
> >>>   }
> >>>   spin_unlock_irqrestore(>lock, irq_flags);
> >>>  
> >>>
> >>
> >> Colleagues of mine have measured significant performance gains for some
> >> workloads with this patch. Without it, a lot of CPU cycles are spent
> >> changing the caching attributes of pages on allocation.
> >>
> >> Note that the performance effect seems to mostly disappear when applying
> >> patch 1 as well, so apparently 64MB is too small for the max pool size.
> >>
> >> Is there any chance this patch could be applied without the
> >> controversial patch 3? If not, do you have ideas for addressing the
> >> concerns raised against patch 3?
> > 
> > Wahou, now i need to find the keys to the DeLorean to travel back in time.
> > 
> > This patch is a fix and should be applied without 1 or 3. Because today
> > basicly the pool is always emptied and never fill up. But as Thomas pointed
> > out there is already bit too much pool accross the stack. Proper solution
> > would be to work something inside the mm level or the architecture (i assume
> > AMD is mostly interested in x86 on that front).
> > 
> > Here the whole issue is really about allocating page with WC/UC cache
> > properties. Changing cache properties on page is really costly on several
> > level, like the kernel needs to break the huge linear mapping and populate
> > lower level to remap the page with proper cache attribute inside the kernel
> > mapping.
> > 
> > As far as i remember the kernel never goes back to huge page mapping when
> > restoring page cache attribute, which meaning that little by litte with
> > uptime you loose the whole huge page mapping benefit for everything and you
> > waste more memory.
> 
> That sounds pretty bad, but this patch might actually help a little for
> that by reducing the amount of huge page mappings that need to be broken up?

Not really, for limiting huge page mapping breakage you would need to allocate
page in same physical cluster so that only 1 huge page mapping needs to be
broken. It would be a bit like DMA32 or DMA16 physical range. So this would
obviously need some work at the MM level. At ttm level this can be more or
less implemented using GFP_DMA32 flag on page allocation but at the same time
doing that you kind of put more pressure on the first 4G of memory and i
think nowadays with the whole webbrowser consuming several GB of texture you
probably do not want to do that.


> > In meantime i think we need to apply this patch as it is really a fix to
> > make the code actually do what the comment and design pretends it does.
> 
> I agree.
> 
> BTW, maybe it should be split up into the actual fix (removing the
> npages assignment) and the NUM_PAGES_TO_ALLOC related simplification?

This would make 2 really small patch, patch is small as it is :) But why
not.

Cheers,
Jérôme

[Nouveau] CUDA fixed VA allocations and sparse mappings

[Jerome Glisse]

On Tue, Jul 07, 2015 at 11:29:38AM -0400, Ilia Mirkin wrote:
> On Mon, Jul 6, 2015 at 8:42 PM, Andrew Chew  wrote:
> > Hello,
> >
> > I am currently looking into ways to support fixed virtual address 
> > allocations
> > and sparse mappings in nouveau, as a step towards supporting CUDA.
> >
> > CUDA requires that the GPU virtual address for a given buffer match the
> > CPU virtual address.  Therefore, when mapping a CUDA buffer, we have to have
> > a way of specifying a particular virtual address to map to (we would ask 
> > that
> > the CPU virtual address be used).  Currently, as I understand it, the 
> > allocator
> > implemented in nvkm/core/mm.c, used to provision virtual addresses, doesn't
> > allow for this (but it's very easy to modify the allocator slightly to allow
> > for this, which I have done locally in my experiments).
> >
> > In addition, the CUDA use case typically involves allocating a big chunk of
> > address space ahead of time as a way to reserve that chunk for future CUDA
> > use.  It then maps individual buffers into that address space as needed.
> > Currently, the virtual address allocation is done during buffer mapping, so
> > in order to support these sparse mappings, it seems to me that the virtual
> > address allocation and buffer mapping need to be decoupled into separate
> > operations.
> >
> > My current strawman proposal for supporting this is to introduce two new 
> > ioctls
> > DRM_IOCTL_NOUVEAU_AS_ALLOC and DRM_IOCTL_NOUVEAU_AS_FREE, that look roughly
> > like this:
> >
> > #define NOUVEAU_AS_ALLOC_FLAGS_FIXED_OFFSET 0x1
> > struct drm_nouveau_as_alloc {
> > uint64_t pages; /* in, pages */
> > uint32_t page_size; /* in, bytes */
> > uint32_t flags; /* in */
> > uint64_t offset;/* in/out, byte address */
> > };
> >
> > struct drm_nouveau_as_free {
> > uint64_t offset;/* in, byte address */
> > };
> >
> > These ioctls just call into the allocator to allocate a range of addresses,
> > resulting in a struct nvkm_vma that tracks that allocation (or releases the
> > struct nvkm_vma back into the virtual address pool in the case of the free
> > ioctl).  If NOUVEAU_AS_ALLOC_FLAGS_FIXED_OFFSET is set, offset specifies the
> > requested virtual address.  Otherwise, an arbitrary address will be
> > allocated.
> 
> Well, this can't just be an address space. You still need bo's, if
> this is to work with nouveau -- it has to know when to swap things in
> and out, when they're used, etc. (and/or move between VRAM and GART
> and system/swap). I suspect that your target here are the GK20A and
> GM20B chips which don't have dedicated VRAM, but the ioctl's need to
> work for everything.
> 
> Would it be sufficient to extend NOUVEAU_GEM_NEW or create a
> NOUVEAU_GEM_NEW_FIXED or something? IOW, why do have to separate the
> concept of a GEM object and a VM allocation?

Well maybe something like i did for radeon. With radeon you have 2 set of
ioctl. One to create/delete bo (GEM stuff) and one to associate a virtual
address with a bo. I wanted to let the userspace decide on virtual address
of buffer precisely for the same reason CUDA do it ie to allow to map some
buffer at same address in GPU address space as in CPU address space. So far
we never really took advantage of that on radeon side.

Also on radeon you can map same bo at different virtual address in same
process (you will need different file descriptor for each mapping and you
can only submit command stream using mapping valid for the file descriptor).
Thought this is mostly usefull when sharing same bo accross different
process.

I think my radeon virtual address ioclt are nice design but other might
disagree. If you want to look at the code :

  drivers/gpu/drm/radeon/radeon_vm.c
  drivers/gpu/drm/radeon/radeon_gem.c

Grep for _va (virtual address per bo) or _vm (virtual address manager per
file descriptor) function name and structure name.

On the command stream and bo eviction side everything is as usual on radeon.
So a bo can be evicted btw 2 command stream to make room for another one.
Either its mapping is invalidated or updated to point to system memory. So
most of the logic for everything else remain the same (just need to update
the multiple virtual address space).


> 
> >
> > In addition to this, a way to map/unmap buffers is needed.  Ordinarily, one
> > would just use DRM_IOCTL_PRIME_FD_TO_HANDLE to import and map a dmabuf into
> > gem.  However, this ioctl will try to grab the virtual address range for 
> > this
> > buffer, which will fail in the CUDA case since the virtual address range
> > has been reserved ahead of time.  So we perhaps introduce a set of ioctls
> > to map/unmap buffers on top of an already existing virtual address 
> > allocation.
> 
> My suggestion above is an alternative to this, right? I think dmabufs
> tend to be used for sharing between devices. I suspect there's more
> going on here that I don't understand though -- I assume the CUDA
> 

R200 DRM/KMS

[Steven Newbury]

On Mon Jul 6 22:26:25 2015 GMT+0100, Daniel Vetter wrote:
> On Mon, Jul 06, 2015 at 09:06:28PM +0100, Steven Newbury wrote:
> > On Mon, 2015-07-06 at 15:42 -0400, Alex Deucher wrote:
> > > On Mon, Jul 6, 2015 at 2:40 PM, Steven Newbury  > > > wrote:
> > > > On Mon, 2015-07-06 at 12:25 -0400, Alex Deucher wrote:
> > > > > On Mon, Jul 6, 2015 at 9:39 AM, Steven Newbury <
> > > > > steve at snewbury.org.uk
> > > > > > wrote:
> > > > > > Hi,
> > > > > > I've been trying to get DRM/KMS working with the current 
> > > > > > graphics
> > > > > > stack (xf86-video-ati 7.5, xserver-1.17) on a R200 series 
> > > > > > card.  I
> > > > > > assumed this should be working since KMS was implemented for 
> > > > > > it a
> > > > > > while back, and it has been working with xf86-video-ati-6.x.
> > > > > > 
> > > > > > Unfortunately, it doesn't seem to work.
> > > > > > 
> > > > > > I've narrowed it down to drmSetInterfaceVersion() failing when
> > > > > > called
> > > > > > from the ATI driver (in radeon_kms.c).  This is a bit strange
> > > > > > since,
> > > > > > /sys/class/drm/version correctly reports 1.1.0 20060810. 
> > > > > >  Presuably
> > > > > > it's getting the correct fd for the DRM master otherwise it 
> > > > > > should
> > > > > > bail earlier?
> > > > > > 
> > > > > > 
> > > > > > Googling confirms others have had the same issue, and 
> > > > > > generally the
> > > > > > resolution has been to stick with the old driver.
> > > > > > 
> > > > > > Should this be working?  Is it known to be broken?
> > > > > 
> > > > > It should be working.  Make sure the kernel driver has kms 
> > > > > enabled,
> > > > > firmware available, and that the kernel driver is loaded before
> > > > > starting X.  If the kernel driver is not loaded before X starts 
> > > > > you
> > > > > can get a version mis-match error.
> > > > 
> > > > Yes, using Gentoos 4.1.1 kernel, driver is definitely loaded, with
> > > > modeset=1, which is working, all sysfs entries are there.  gdm 
> > > > manages
> > > > to fall back to starting up an X session without using DRM swrast
> > > > -only, not something you want to experience on such a weak CPU!
> > > > 
> > > 
> > > If the kernel driver loads properly and you get a kms console you
> > > should be good to go.
> > > 
> > > > Manually starting X fails with the "[drm] failed to set drm 
> > > > interface
> > > > version." error.
> > > > 
> > > 
> > > Maybe the ddx with that old system was build without KMS support?
> > Everything is freshly compiled.  The error itself is coming from
> > radeon_kms.c:651 in the ddx.
> 
> Do you have latest libdrm? We might have accidentally broken this for very
> old versions of libdrm (although surprising this would compile with
> everything else).
> -Daniel
> > 
> > > 
> > > Alex
> > > 
> > > > It's a very old system, PCI-only(!) Coppermine-128, belonging to a
> > > > friend.  The system previously was (very slowly) running Ubuntu 10
> > > > LTS, I think.  It's not my machine so I'm not able to have 
> > > > continuous
> > > > access, but R200 DRM/KMS was working.  Apparently, Ubuntu no longer
> > > > support R200, so no further updates were possible.
> > > > 
> > > > My friend can't afford a new machine at the moment; and since I'm a
> > > > long time Gentoo dev I took it upon myself to build him a optimized
> > > > desktop with gcc-5, where possible LTO, -Os, -march=pentium3 with 
> > > > the
> > > > system L1 and L2 cache size information.  It's quite possible some
> > > > part of the gfx stack is miscompiled, I tested it pretty throughly
> > > > under qemu (with qxl) before deployment, but that of course didn't
> > > > exercise the R200 driver.  FWIW, other than the failing DRI,
> > > > performance is surprisingly OK, not super fast obviously, but a 
> > > > *lot*
> > > > better than under Ubuntu! (start-up time is alot quicker, by an 
> > > > order
> > > > of magnitude!)
> > > > 
> > > > I'm attempting to downgrade the xserver and drivers (on the live
> > > > system) to see if that works, you can imagine that takes a little
> > > > while on a Coppermine-128!  I'll find out tomorrow.  Otherwise, I
> > > > guess I'm recompiling the stack with gcc-4.9 and no-LTO...
> 
> 
> 
> > ___
> > 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
>

-- 
Sent from my Jolla

linux-4.2-rc1/drivers/gpu/drm/radeon/cik.c:1912: dead code block ?

[Alex Deucher]

On Tue, Jul 7, 2015 at 6:56 AM, David Binderman  wrote:
> Hello there,
>
> [linux-4.2-rc1/drivers/gpu/drm/radeon/cik.c:1912] -> 
> [linux-4.2-rc1/drivers/gpu/drm/radeon/cik.c:1913]: (warning) Opposite 
> conditions in nested 'if' blocks lead to a dead code block.
>
> Source code is
>
>if (running == 0) {
> if (running) {
> blackout = RREG32(MC_SHARED_BLACKOUT_CNTL);
> WREG32(MC_SHARED_BLACKOUT_CNTL, blackout | 1);
> }

It's there mainly as a reminder that we need to blackout the mc before
updating the ucode and then unblack it out at the end.  Originally
this code was divided into several functions and the checks were
necessary.

Alex

>
> Regards
>
> David Binderman
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Intel-gfx] [PATCH v2 02/20] drm: Don't update plane properties for atomic planes if it stays the same

[Maarten Lankhorst]

Op 07-07-15 om 11:18 schreef Daniel Vetter:
> On Tue, Jul 07, 2015 at 09:08:13AM +0200, Maarten Lankhorst wrote:
>> This allows the first atomic call during hw init to be a real modeset,
>> which is useful for forcing a recalculation.
> fbcon is optional, you can't rely on anything being done in any specific
> way. What exactly do you need this for, what's the implications?
In the hw readout I noticed some warnings when I wasn't setting any mode 
property in the readout.
I want the first function to be the modeset, so we have a sane base to commit 
changes on.
Ideally this whole function would have a atomic counterpart which does it in 
one go. :)

[PATCH 2/3] drm/radeon: unpin cursor BOs on suspend and pin them again on resume

[Christian König]

On 07.07.2015 09:27, Michel Dänzer wrote:
> From: Grigori Goronzy 
>
> Everything is evicted from VRAM before suspend, so we need to make
> sure all BOs are unpinned and re-pinned after resume. Fixes broken
> mouse cursor after resume introduced by commit b9729b17.
>
> [Michel Dänzer: Add pinning BOs on resume]
>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=100541
> Cc: stable at vger.kernel.org
> Signed-off-by: Grigori Goronzy 
> Signed-off-by: Michel Dänzer 
> ---
>   drivers/gpu/drm/radeon/radeon_device.c | 36 
> ++
>   1 file changed, 36 insertions(+)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
> b/drivers/gpu/drm/radeon/radeon_device.c
> index 12a18c8..5a075a9 100644
> --- a/drivers/gpu/drm/radeon/radeon_device.c
> +++ b/drivers/gpu/drm/radeon/radeon_device.c
> @@ -1593,6 +1593,20 @@ int radeon_suspend_kms(struct drm_device *dev, bool 
> suspend, bool fbcon)
>   drm_helper_connector_dpms(connector, DRM_MODE_DPMS_OFF);
>   }
>   
> + /* unpin cursors */
> + list_for_each_entry(crtc, >mode_config.crtc_list, head) {

Didn't we wanted to merge this into the other list_for_each_entry below?

Either way is fine with me and the whole series is Reviewed-by: 
Christian König  anyway.

Regards,
Christian.

> + struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
> +
> + if (radeon_crtc->cursor_bo) {
> + struct radeon_bo *robj = 
> gem_to_radeon_bo(radeon_crtc->cursor_bo);
> + r = radeon_bo_reserve(robj, false);
> + if (r == 0) {
> + radeon_bo_unpin(robj);
> + radeon_bo_unreserve(robj);
> + }
> + }
> + }
> +
>   /* unpin the front buffers */
>   list_for_each_entry(crtc, >mode_config.crtc_list, head) {
>   struct radeon_framebuffer *rfb = 
> to_radeon_framebuffer(crtc->primary->fb);
> @@ -1660,6 +1674,7 @@ int radeon_resume_kms(struct drm_device *dev, bool 
> resume, bool fbcon)
>   {
>   struct drm_connector *connector;
>   struct radeon_device *rdev = dev->dev_private;
> + struct drm_crtc *crtc;
>   int r;
>   
>   if (dev->switch_power_state == DRM_SWITCH_POWER_OFF)
> @@ -1699,6 +1714,27 @@ int radeon_resume_kms(struct drm_device *dev, bool 
> resume, bool fbcon)
>   
>   radeon_restore_bios_scratch_regs(rdev);
>   
> + /* pin cursors */
> + list_for_each_entry(crtc, >mode_config.crtc_list, head) {
> + struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
> +
> + if (radeon_crtc->cursor_bo) {
> + struct radeon_bo *robj = 
> gem_to_radeon_bo(radeon_crtc->cursor_bo);
> + r = radeon_bo_reserve(robj, false);
> + if (r == 0) {
> + /* Only 27 bit offset for legacy cursor */
> + r = radeon_bo_pin_restricted(robj,
> +  
> RADEON_GEM_DOMAIN_VRAM,
> +  
> ASIC_IS_AVIVO(rdev) ?
> +  0 : 1 << 27,
> +  
> _crtc->cursor_addr);
> + if (r != 0)
> + DRM_ERROR("Failed to pin cursor BO 
> (%d)\n", r);
> + radeon_bo_unreserve(robj);
> + }
> + }
> + }
> +
>   /* init dig PHYs, disp eng pll */
>   if (rdev->is_atom_bios) {
>   radeon_atom_encoder_init(rdev);

[PATCH v2 01/20] drm/atomic: add connectors_changed to separate it from mode_changed

[Maarten Lankhorst]

Op 07-07-15 om 10:59 schreef Daniel Vetter:
> On Tue, Jul 07, 2015 at 09:08:12AM +0200, Maarten Lankhorst wrote:
>> This can be a separate case from mode_changed, when connectors stay the
>> same but only the mode is different. Drivers may choose to implement specific
>> optimizations to prevent a full modeset for this case.
>>
>> Cc: dri-devel at lists.freedesktop.org
>> Signed-off-by: Maarten Lankhorst 
>> ---
>>  drivers/gpu/drm/drm_atomic_helper.c  | 25 +++--
>>  drivers/gpu/drm/i915/intel_display.c |  2 +-
>>  include/drm/drm_atomic.h |  3 ++-
>>  include/drm/drm_crtc.h   |  8 +---
>>  4 files changed, 27 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
>> b/drivers/gpu/drm/drm_atomic_helper.c
>> index 66e76f4f43be..b818e3111380 100644
>> --- a/drivers/gpu/drm/drm_atomic_helper.c
>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
>> @@ -124,7 +124,7 @@ steal_encoder(struct drm_atomic_state *state,
>>  if (IS_ERR(crtc_state))
>>  return PTR_ERR(crtc_state);
>>  
>> -crtc_state->mode_changed = true;
>> +crtc_state->connectors_changed = true;
>>  
>>  list_for_each_entry(connector, >connector_list, head) {
>>  if (connector->state->best_encoder != encoder)
>> @@ -174,14 +174,14 @@ update_connector_routing(struct drm_atomic_state 
>> *state, int conn_idx)
>>  idx = drm_crtc_index(connector->state->crtc);
>>  
>>  crtc_state = state->crtc_states[idx];
>> -crtc_state->mode_changed = true;
>> +crtc_state->connectors_changed = true;
>>  }
>>  
>>  if (connector_state->crtc) {
>>  idx = drm_crtc_index(connector_state->crtc);
>>  
>>  crtc_state = state->crtc_states[idx];
>> -crtc_state->mode_changed = true;
>> +crtc_state->connectors_changed = true;
>>  }
>>  }
>>  
>> @@ -233,7 +233,7 @@ update_connector_routing(struct drm_atomic_state *state, 
>> int conn_idx)
>>  idx = drm_crtc_index(connector_state->crtc);
>>  
>>  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,
>> @@ -256,7 +256,8 @@ mode_fixup(struct drm_atomic_state *state)
>>  bool ret;
>>  
>>  for_each_crtc_in_state(state, crtc, crtc_state, i) {
>> -if (!crtc_state->mode_changed)
>> +if (!crtc_state->mode_changed &&
>> +!crtc_state->connectors_changed)
>>  continue;
>>  
>>  drm_mode_copy(_state->adjusted_mode, _state->mode);
>> @@ -312,7 +313,8 @@ mode_fixup(struct drm_atomic_state *state)
>>  for_each_crtc_in_state(state, crtc, crtc_state, i) {
>>  const struct drm_crtc_helper_funcs *funcs;
>>  
>> -if (!crtc_state->mode_changed)
>> +if (!crtc_state->mode_changed &&
>> +!crtc_state->connectors_changed)
>>  continue;
>>  
>>  funcs = crtc->helper_private;
>> @@ -373,7 +375,17 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
>>  if (crtc->state->enable != crtc_state->enable) {
>>  DRM_DEBUG_ATOMIC("[CRTC:%d] enable changed\n",
>>   crtc->base.id);
>> +
>> +/*
>> + * For clarity this assignment is done here, but
>> + * enable == 0 is only true when there are no
>> + * connectors and a NULL mode.
>> + *
>> + * The other way around is true as well. enable != 0
>> + * iff connectors are attached and a mode is set.
>> + */
>>  crtc_state->mode_changed = true;
> I'd drop this one so that connectors_changed and mode_changed are truly
> orthogonal. Also ->enable implies connectors changed since we do check
> that there's only connected connectors if the crtc is on. Needs kerneldoc
> update too ofc.

They are orthogonal, think of this case:

1. crtc previously enabled, connector removed, mode stays same ->
connector_changed = true, mode_changed = false

2. crtc previously enabled, connectors stay the same, different mode -> 
connectors_changed = false, mode_changed = true

The following is enforced by the checks:
crtc disabled, implies 0 connectors, no mode.
crtc enabled implies > 0 connectors, and a mode.

Hence the connectors_changed and mode_changed here are for documentation 
purposes only. :)

So if someone wonders what happens when enable is changed they don't have to 
dig through
the entire drm_atomic_helper_check_modeset function and still not be sure if 
it's coincidence
or not. 

radeon: 4.2-rc1 warning when unplugging DVI

[Michel Dänzer]

On 07.07.2015 07:15, Vadim Girlin wrote:
> On 07/07/2015 01:07 AM, Vadim Girlin wrote:
>> On 07/06/2015 11:56 PM, Alex Deucher wrote:
>>> On Mon, Jul 6, 2015 at 3:19 PM, Dave Jones 
>>> wrote:
 I wanted to switch my LCD to a different machine momentarily.
 When I plugged the cable back in, this was on the screen..
>>>
>>> Is this readily reproducible?  Did it happen with 4.1?  If it also
>>> happens with 4.1 does reverting
>>> 39fa10f7e21574a70cecf1fed0f9b36535aa68a0 help?  If it doesn't happen
>>> with 4.1, can you bisect?
>>
>> That issue is reproducible for me with the changes after 4.1, but 4.1 is
> 
> By issue I mean the "don't has a mapping" flood, not sure if the thread
> is discussing something else already.

This thread was never discussing that AFAICT. :) See
https://bugs.freedesktop.org/show_bug.cgi?id=91141 .


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

[Nouveau] CUDA fixed VA allocations and sparse mappings

[Andrew Chew]

On Tue, Jul 07, 2015 at 11:29:38AM -0400, Ilia Mirkin wrote:
> On Mon, Jul 6, 2015 at 8:42 PM, Andrew Chew  wrote:
> > These ioctls just call into the allocator to allocate a range of addresses,
> > resulting in a struct nvkm_vma that tracks that allocation (or releases the
> > struct nvkm_vma back into the virtual address pool in the case of the free
> > ioctl).  If NOUVEAU_AS_ALLOC_FLAGS_FIXED_OFFSET is set, offset specifies the
> > requested virtual address.  Otherwise, an arbitrary address will be
> > allocated.
> 
> Well, this can't just be an address space. You still need bo's, if
> this is to work with nouveau -- it has to know when to swap things in
> and out, when they're used, etc. (and/or move between VRAM and GART
> and system/swap). I suspect that your target here are the GK20A and
> GM20B chips which don't have dedicated VRAM, but the ioctl's need to
> work for everything.
> 
> Would it be sufficient to extend NOUVEAU_GEM_NEW or create a
> NOUVEAU_GEM_NEW_FIXED or something? IOW, why do have to separate the
> concept of a GEM object and a VM allocation?

You're correct.  This is for gk20a and gm20b.

The thing these proposed ioctls are supposed to accomplish is to reserve,
ahead of time, a portion of the address space.  So at this time, there
really aren't any buffer objects yet, and there's nothing to be mapped to
the GMMU.  That part would come later.

> > In addition to this, a way to map/unmap buffers is needed.  Ordinarily, one
> > would just use DRM_IOCTL_PRIME_FD_TO_HANDLE to import and map a dmabuf into
> > gem.  However, this ioctl will try to grab the virtual address range for 
> > this
> > buffer, which will fail in the CUDA case since the virtual address range
> > has been reserved ahead of time.  So we perhaps introduce a set of ioctls
> > to map/unmap buffers on top of an already existing virtual address 
> > allocation.
> 
> My suggestion above is an alternative to this, right? I think dmabufs
> tend to be used for sharing between devices. I suspect there's more
> going on here that I don't understand though -- I assume the CUDA
> use-case is similar to the HSA use-case -- being able to build up data
> structures that point to one another on the CPU and then process them
> on the GPU? Can you detail a specific use-case perhaps, including the
> interactions with the GPU and its address space?

The whole dmabufs thing is kind of a side issue.  I'll take a look at
NOUVEAU_GEM_NEW, but that could be an alternative to this, maybe, if
extended (or we make a new NOUVEAU_GEM_NEW_FIXED, as you suggested).
Crucially, the NOUVEAU_GEM_NEW_FIXED operation shouldn't result in trying
to get a virtual address region and then failing because a previous
operation (see above) has reserved it already.

The use case is exactly as you describe.  There are data structures built
up that contain CPU pointers, and those pointers need to make sense to
the GPU as well.

[Nouveau] CUDA fixed VA allocations and sparse mappings

[Ilia Mirkin]

On Mon, Jul 6, 2015 at 8:42 PM, Andrew Chew  wrote:
> Hello,
>
> I am currently looking into ways to support fixed virtual address allocations
> and sparse mappings in nouveau, as a step towards supporting CUDA.
>
> CUDA requires that the GPU virtual address for a given buffer match the
> CPU virtual address.  Therefore, when mapping a CUDA buffer, we have to have
> a way of specifying a particular virtual address to map to (we would ask that
> the CPU virtual address be used).  Currently, as I understand it, the 
> allocator
> implemented in nvkm/core/mm.c, used to provision virtual addresses, doesn't
> allow for this (but it's very easy to modify the allocator slightly to allow
> for this, which I have done locally in my experiments).
>
> In addition, the CUDA use case typically involves allocating a big chunk of
> address space ahead of time as a way to reserve that chunk for future CUDA
> use.  It then maps individual buffers into that address space as needed.
> Currently, the virtual address allocation is done during buffer mapping, so
> in order to support these sparse mappings, it seems to me that the virtual
> address allocation and buffer mapping need to be decoupled into separate
> operations.
>
> My current strawman proposal for supporting this is to introduce two new 
> ioctls
> DRM_IOCTL_NOUVEAU_AS_ALLOC and DRM_IOCTL_NOUVEAU_AS_FREE, that look roughly
> like this:
>
> #define NOUVEAU_AS_ALLOC_FLAGS_FIXED_OFFSET 0x1
> struct drm_nouveau_as_alloc {
> uint64_t pages; /* in, pages */
> uint32_t page_size; /* in, bytes */
> uint32_t flags; /* in */
> uint64_t offset;/* in/out, byte address */
> };
>
> struct drm_nouveau_as_free {
> uint64_t offset;/* in, byte address */
> };
>
> These ioctls just call into the allocator to allocate a range of addresses,
> resulting in a struct nvkm_vma that tracks that allocation (or releases the
> struct nvkm_vma back into the virtual address pool in the case of the free
> ioctl).  If NOUVEAU_AS_ALLOC_FLAGS_FIXED_OFFSET is set, offset specifies the
> requested virtual address.  Otherwise, an arbitrary address will be
> allocated.

Well, this can't just be an address space. You still need bo's, if
this is to work with nouveau -- it has to know when to swap things in
and out, when they're used, etc. (and/or move between VRAM and GART
and system/swap). I suspect that your target here are the GK20A and
GM20B chips which don't have dedicated VRAM, but the ioctl's need to
work for everything.

Would it be sufficient to extend NOUVEAU_GEM_NEW or create a
NOUVEAU_GEM_NEW_FIXED or something? IOW, why do have to separate the
concept of a GEM object and a VM allocation?

>
> In addition to this, a way to map/unmap buffers is needed.  Ordinarily, one
> would just use DRM_IOCTL_PRIME_FD_TO_HANDLE to import and map a dmabuf into
> gem.  However, this ioctl will try to grab the virtual address range for this
> buffer, which will fail in the CUDA case since the virtual address range
> has been reserved ahead of time.  So we perhaps introduce a set of ioctls
> to map/unmap buffers on top of an already existing virtual address allocation.

My suggestion above is an alternative to this, right? I think dmabufs
tend to be used for sharing between devices. I suspect there's more
going on here that I don't understand though -- I assume the CUDA
use-case is similar to the HSA use-case -- being able to build up data
structures that point to one another on the CPU and then process them
on the GPU? Can you detail a specific use-case perhaps, including the
interactions with the GPU and its address space?

Jérôme, I believe you were doing the HSA kernel implementation.
Perhaps you'd have some feedback on this proposal?

Cheers,

  -ilia

[Bug 93701] radeon: two "empty" pixel lines on left side of screen, rest of screen gets slightly squished

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

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

--- Comment #23 from Frederik vom Hofe  ---
Created attachment 182071
  --> https://bugzilla.kernel.org/attachment.cgi?id=182071=edit
Xorg.0.log with v4.2-rc1 and 290

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

[Bug 93701] radeon: two "empty" pixel lines on left side of screen, rest of screen gets slightly squished

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

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

--- Comment #22 from Frederik vom Hofe  ---
Created attachment 182061
  --> https://bugzilla.kernel.org/attachment.cgi?id=182061=edit
dmesg with v4.2-rc1 and 290

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

[Bug 93701] radeon: two "empty" pixel lines on left side of screen, rest of screen gets slightly squished

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

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

--- Comment #21 from Frederik vom Hofe  ---
Just got a 290 that shows the same phenomena since patch revert.

2d1c18bba15daf89d75ce475ecd2068f483aa12f
Revert "drm/radeon: only mark audio as connected if the monitor supports it
(v3)"
...

Bisected v4.1-rc5 to v4.1-rc6. Sinc v4.2-rc1 still shows the lines.

Also attaching new dmesg and Xorg log, just in case.

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

[Intel-gfx] [PATCH v2 02/20] drm: Don't update plane properties for atomic planes if it stays the same

[Daniel Vetter]

On Tue, Jul 07, 2015 at 09:08:13AM +0200, Maarten Lankhorst wrote:
> This allows the first atomic call during hw init to be a real modeset,
> which is useful for forcing a recalculation.

fbcon is optional, you can't rely on anything being done in any specific
way. What exactly do you need this for, what's the implications?
-Daniel

> 
> Cc: dri-devel at lists.freedesktop.org
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/drm_fb_helper.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index cac422916c7a..33b5e4ecaf46 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -322,10 +322,12 @@ static bool restore_fbdev_mode(struct drm_fb_helper 
> *fb_helper)
>   drm_warn_on_modeset_not_all_locked(dev);
>  
>   list_for_each_entry(plane, >mode_config.plane_list, head) {
> - if (plane->type != DRM_PLANE_TYPE_PRIMARY)
> + if (plane->type != DRM_PLANE_TYPE_PRIMARY &&
> + (!plane->state || plane->state->fb))
>   drm_plane_force_disable(plane);
>  
> - if (dev->mode_config.rotation_property) {
> + if (dev->mode_config.rotation_property &&
> + (!plane->state || plane->state->rotation != 
> BIT(DRM_ROTATE_0))) {
>   drm_mode_plane_set_obj_prop(plane,
>   
> dev->mode_config.rotation_property,
>   BIT(DRM_ROTATE_0));
> -- 
> 2.1.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[PATCH v2 01/20] drm/atomic: add connectors_changed to separate it from mode_changed

[Daniel Vetter]

On Tue, Jul 07, 2015 at 09:08:12AM +0200, Maarten Lankhorst wrote:
> This can be a separate case from mode_changed, when connectors stay the
> same but only the mode is different. Drivers may choose to implement specific
> optimizations to prevent a full modeset for this case.
> 
> Cc: dri-devel at lists.freedesktop.org
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/drm_atomic_helper.c  | 25 +++--
>  drivers/gpu/drm/i915/intel_display.c |  2 +-
>  include/drm/drm_atomic.h |  3 ++-
>  include/drm/drm_crtc.h   |  8 +---
>  4 files changed, 27 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 66e76f4f43be..b818e3111380 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -124,7 +124,7 @@ steal_encoder(struct drm_atomic_state *state,
>   if (IS_ERR(crtc_state))
>   return PTR_ERR(crtc_state);
>  
> - crtc_state->mode_changed = true;
> + crtc_state->connectors_changed = true;
>  
>   list_for_each_entry(connector, >connector_list, head) {
>   if (connector->state->best_encoder != encoder)
> @@ -174,14 +174,14 @@ update_connector_routing(struct drm_atomic_state 
> *state, int conn_idx)
>   idx = drm_crtc_index(connector->state->crtc);
>  
>   crtc_state = state->crtc_states[idx];
> - crtc_state->mode_changed = true;
> + crtc_state->connectors_changed = true;
>   }
>  
>   if (connector_state->crtc) {
>   idx = drm_crtc_index(connector_state->crtc);
>  
>   crtc_state = state->crtc_states[idx];
> - crtc_state->mode_changed = true;
> + crtc_state->connectors_changed = true;
>   }
>   }
>  
> @@ -233,7 +233,7 @@ update_connector_routing(struct drm_atomic_state *state, 
> int conn_idx)
>   idx = drm_crtc_index(connector_state->crtc);
>  
>   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,
> @@ -256,7 +256,8 @@ mode_fixup(struct drm_atomic_state *state)
>   bool ret;
>  
>   for_each_crtc_in_state(state, crtc, crtc_state, i) {
> - if (!crtc_state->mode_changed)
> + if (!crtc_state->mode_changed &&
> + !crtc_state->connectors_changed)
>   continue;
>  
>   drm_mode_copy(_state->adjusted_mode, _state->mode);
> @@ -312,7 +313,8 @@ mode_fixup(struct drm_atomic_state *state)
>   for_each_crtc_in_state(state, crtc, crtc_state, i) {
>   const struct drm_crtc_helper_funcs *funcs;
>  
> - if (!crtc_state->mode_changed)
> + if (!crtc_state->mode_changed &&
> + !crtc_state->connectors_changed)
>   continue;
>  
>   funcs = crtc->helper_private;
> @@ -373,7 +375,17 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
>   if (crtc->state->enable != crtc_state->enable) {
>   DRM_DEBUG_ATOMIC("[CRTC:%d] enable changed\n",
>crtc->base.id);
> +
> + /*
> +  * For clarity this assignment is done here, but
> +  * enable == 0 is only true when there are no
> +  * connectors and a NULL mode.
> +  *
> +  * The other way around is true as well. enable != 0
> +  * iff connectors are attached and a mode is set.
> +  */
>   crtc_state->mode_changed = true;

I'd drop this one so that connectors_changed and mode_changed are truly
orthogonal. Also ->enable implies connectors changed since we do check
that there's only connected connectors if the crtc is on. Needs kerneldoc
update too ofc.

> + crtc_state->connectors_changed = true;
>   }
>   }
>  
> @@ -2072,6 +2084,7 @@ void __drm_atomic_helper_crtc_duplicate_state(struct 
> drm_crtc *crtc,
>   state->mode_changed = false;
>   state->active_changed = false;
>   state->planes_changed = false;
> + state->connectors_changed = false;
>   state->event = NULL;
>  }
>  EXPORT_SYMBOL(__drm_atomic_helper_crtc_duplicate_state);
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index e91613b1c871..6ddb462b4124 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -421,7 +421,7 @@ static const intel_limit_t intel_limits_bxt = {
>  static bool
>  needs_modeset(struct drm_crtc_state *state)
>  {
> -

linux-4.2-rc1/drivers/gpu/drm/radeon/cik.c:1912: dead code block ?

[David Binderman]

Hello there,

[linux-4.2-rc1/drivers/gpu/drm/radeon/cik.c:1912] -> 
[linux-4.2-rc1/drivers/gpu/drm/radeon/cik.c:1913]: (warning) Opposite 
conditions in nested 'if' blocks lead to a dead code block.

Source code is

   if (running == 0) {
        if (running) {
            blackout = RREG32(MC_SHARED_BLACKOUT_CNTL);
            WREG32(MC_SHARED_BLACKOUT_CNTL, blackout | 1);
        }

Regards

David Binderman

[PATCH] drm: add a check for x/y in drm_mode_setcrtc

[Daniel Vetter]

On Tue, Jul 07, 2015 at 04:21:50PM +0800, John Hunter wrote:
> From: Zhao Junwang 
> 
> legacy setcrtc ioctl does take a 32 bit value which might indeed
> overflow
> 
> the checks of crtc_req->x > INT_MAX and crtc_req->y > INT_MAX aren't
> needed any more with this
> 
> Cc: Daniel Vetter 
> Signed-off-by: Zhao Junwang 
> ---
>  drivers/gpu/drm/drm_crtc.c |7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index b69ed97..c307435 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -2706,8 +2706,11 @@ int drm_mode_setcrtc(struct drm_device *dev, void 
> *data,
>   if (!drm_core_check_feature(dev, DRIVER_MODESET))
>   return -EINVAL;
>  
> - /* For some reason crtc x/y offsets are signed internally. */
> - if (crtc_req->x > INT_MAX || crtc_req->y > INT_MAX)
> + /*
> +  * Legacy setcrtc ioctl does take a 32 bit value which might
> +  * overflow

That legacy takes 32bit is clear, the important part to mention is that
atomic only takes a 16.16 fixed point for this. And to avoid surprises in
for atomic drivers it's better to check this here. Actually this even
holds for just universal planes, no need for full-blown atomic. So what
about instead

/*
 * Universal lane src offsets are only 16.16, prevent havoc for
 * drivers using universal plane code internally.
 */
-Daniel
> +  */
> + if (crtc_req->x & 0x || crtc_req->y & 0x)
>   return -ERANGE;
>  
>   drm_modeset_lock_all(dev);
> -- 
> 1.7.10.4
> 
> 
> ___
> 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

WARNING: CPU: 0 PID: 3634 at drivers/gpu/drm/drm_irq.c:1141 drm_wait_one_vblank

[Daniel Vetter]

On Wed, Jul 01, 2015 at 03:23:39PM +0300, Jani Nikula wrote:
> 
> +intel-gfx and Matt
> 
> On Wed, 01 Jul 2015, Michal Hocko  wrote:
> > On Wed 01-07-15 10:26:39, Daniel Vetter wrote:
> >> On Tue, Jun 30, 2015 at 10:13:35PM +0200, Michal Hocko wrote:
> >> > On Tue 30-06-15 18:59:29, Daniel Vetter wrote:
> > [...]
> >> > > Also it might be time to start bisecting this if you can readily 
> >> > > reproduce it.
> >> > 
> >> > Yes, I can reproduce it just by switching to the text console. Sometimes
> >> > it is the first attempt already but sometimes it takes several attempts.
> >> > I will try to go back to 4.0 and bisect it then.
> >> 
> >> Yes please do, since this is a confusing regression I think the bisect
> >> result will be the fastest way forward.
> >
> > OK, managed to bisect to cf4c7c12258e ("drm/i915: Make all plane
> > disables use 'update_plane' (v5)") (CC people involved - the thread
> > starts here: http://marc.info/?l=dri-devel=143566543432613=2 for
> > your reference).
> >
> > I do not see the warning when I revert the commit directly on top of
> > cf4c7c12258e but I cannot cleanly revert it on top of the current Linus'
> > tree. Anything more I can give you to help to further debug the issue?

Ok still haven't grown much clue unfortunately. The bisect just points at
where we started to do that vblank_wait in the codepath that somehow
breaks for you. But we should check whether vblank will work beforehand or
not. It's also strange that it only fails sporadically. Can you please
boot with drm.debug=0xf (lots more nois in dmesg with this) and reproduce?
I only need the last few pages before the WARNING backtrace, just to
understand a bit better what's going on there.

Thanks, Daniel
> >
> > Bisect log is:
> > git bisect start
> > # bad: [c517d838eb7d07bbe9507871fab3931deccff539] Linux 4.0-rc1
> > git bisect bad c517d838eb7d07bbe9507871fab3931deccff539
> > # good: [bfa76d49576599a4b9f9b7a71f23d73d6dcff735] Linux 3.19
> > git bisect good bfa76d49576599a4b9f9b7a71f23d73d6dcff735
> > # good: [02f1f2170d2831b3233e91091c60a66622f29e82] kernel.h: remove ancient 
> > __FUNCTION__ hack
> > git bisect good 02f1f2170d2831b3233e91091c60a66622f29e82
> > # bad: [796e1c55717e9a6ff5c81b12289ffa1ffd919b6f] Merge branch 'drm-next' 
> > of git://people.freedesktop.org/~airlied/linux
> > git bisect bad 796e1c55717e9a6ff5c81b12289ffa1ffd919b6f
> > # good: [9682ec9692e5ac11c6caebd079324e727b19e7ce] Merge tag 
> > 'driver-core-3.20-rc1' of 
> > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core
> > git bisect good 9682ec9692e5ac11c6caebd079324e727b19e7ce
> > # good: [a9724125ad014decf008d782e60447c811391326] Merge tag 'tty-3.20-rc1' 
> > of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
> > git bisect good a9724125ad014decf008d782e60447c811391326
> > # bad: [f43dff0ee00a259f524ce17ba4f8030553c66590] Merge tag 
> > 'drm-amdkfd-next-fixes-2015-01-25' of 
> > git://people.freedesktop.org/~gabbayo/linux into drm-next
> > git bisect bad f43dff0ee00a259f524ce17ba4f8030553c66590
> > # good: [b942c653ae265abbd31032f3b4f5f857e5c7c723] Merge tag 
> > 'trace-sh-3.19' of 
> > git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
> > git bisect good b942c653ae265abbd31032f3b4f5f857e5c7c723
> > # good: [fcf3aac5fc307f0cae429f5844ddc25761662858] drm/i915: remove unused 
> > power_well/get_cdclk_freq api
> > git bisect good fcf3aac5fc307f0cae429f5844ddc25761662858
> > # bad: [4f4d89af78682f2ed1cf6745794804817f867bba] Merge tag 
> > 'drm-amdkfd-next-2015-01-09' of git://people.freedesktop.org/~gabbayo/linux 
> > into drm-next
> > git bisect bad 4f4d89af78682f2ed1cf6745794804817f867bba
> > # bad: [64387b613a43713d0e03d9d43bfbb1727e8475e1] drm/i915: Protect against 
> > leaks in pipe_crc_set_source
> > git bisect bad 64387b613a43713d0e03d9d43bfbb1727e8475e1
> > # good: [bfc882b4e30fbc169ecfe3508378623743806f56] drm/i915: Flatten engine 
> > init control flow
> > git bisect good bfc882b4e30fbc169ecfe3508378623743806f56
> > # good: [2b875c22fa77dfc895d3cf8287a553813d3e64c8] drm/i915: Make 
> > intel_plane_state subclass drm_plane_state
> > git bisect good 2b875c22fa77dfc895d3cf8287a553813d3e64c8
> > # bad: [15a17aae5f803551981a7acc6a4058b247a7452c] drm/i915: Check mask/bit 
> > helper functions
> > git bisect bad 15a17aae5f803551981a7acc6a4058b247a7452c
> > # bad: [146d84f0f2707bfe2c67114eeefac30da8584b3b] drm/i915: Fix up seqno -> 
> > request merge issues
> > git bisect bad 146d84f0f2707bfe2c67114eeefac30da8584b3b
> > # good: [c59cb179aaf444931cf9c547a514e383da3d2526] drm/i915: Consolidate 
> > top-level .update_plane() handlers
> > git bisect good c59cb179aaf444931cf9c547a514e383da3d2526
> > # bad: [cf4c7c12258ed9367f4fc45238f5f50d2db892c1] drm/i915: Make all plane 
> > disables use 'update_plane' (v5)
> > git bisect bad cf4c7c12258ed9367f4fc45238f5f50d2db892c1
> > # good: [e614c3c946ae5b50a679d65d2c981615d8ceccab] drm/i915: Ensure 
> > state->crtc is non-NULL for plane updates
> > git bisect good 

[Bug 91253] Regression: Can't boot on 4.0.5 and later but can boot on 4.0.4 (on iMac)

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

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

--- Comment #2 from Christian König  ---
Price question: Can you bisect?

If 4.0.5 is bad and 4.0.4 still works that should be pretty much straight
forward.

-- 
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/20150707/0f0cfe00/attachment.html>

R200 DRM/KMS

[Alex Deucher]

On Tue, Jul 7, 2015 at 9:46 AM, Steven Newbury  wrote:
>
> I've tried an xserver-1.16, and ddx, libdrm without LTO and with
> gcc4.9.  Exactly the same thing.  I wondered whether the unused i810
> could be interfering but triggering a device "remove" before starting
> X made no difference.
>
> I'm a bit of a loss.  I suppose I could try writing a simple test for
> drmSetInterfaceVersion().  At least that should determine whether the
> xserver/ddx is in the clear.
>
> Any other ideas?
>

Can you start a non-X runlevel and start X manually as root (assuming
you are using a login manager now)?

Alex

[Bug 91141] Lots of *ERROR* Couldn't update BO_VA (-22) since drm/radeon: stop using addr to check for BO move

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

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

--- Comment #14 from Christian König  ---
(In reply to hadack from comment #13)
> No problem, seems the second try was it. With both patches applied it works
> fine. Tested standard desktop usage and KSP.

Thanks for testing. Are you convinced enough that it works so that I can add an
"Test-by: hadack at gmx.de" to the patches while pushing them towards 4.2?

-- 
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/20150707/a3c9cc0d/attachment.html>

[PATCH v2 1/2] create SMAF module

[Benjamin Gaignard]

I will change the ident in the macro.

Thanks,

Benjamin

2015-07-07 9:59 GMT+02:00 Paul Bolle :

> A nit only, I'm afraid: a license mismatch.
>
> On ma, 2015-07-06 at 13:40 +0200, Benjamin Gaignard wrote:
> > --- /dev/null
> > +++ b/drivers/smaf/smaf-core.c
>
> > + * License terms:  GNU General Public License (GPL), version 2
>
> > +MODULE_LICENSE("GPL");
>
> The comment at the top of this file states, succinctly, that the license
> is GPL v2. And, according to include/linux/module.h, the
> MODULE_LICENSE() macro here states that the license is GPL v2 or later.
> So I think that either that comment or the ident used in that macro
> needs to change.
>
> Ditto for 2/2.
>
> Thanks,
>
>
> Paul Bolle
>



-- 

Benjamin Gaignard

Graphic Working Group

Linaro.org <http://www.linaro.org/> *│ *Open source software for ARM SoCs

Follow *Linaro: *Facebook <http://www.facebook.com/pages/Linaro> | Twitter
<http://twitter.com/#!/linaroorg> | Blog
<http://www.linaro.org/linaro-blog/>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150707/daaaf5e5/attachment.html>

[PATCH v2 1/2] create SMAF module

[Paul Bolle]

A nit only, I'm afraid: a license mismatch.

On ma, 2015-07-06 at 13:40 +0200, Benjamin Gaignard wrote:
> --- /dev/null
> +++ b/drivers/smaf/smaf-core.c

> + * License terms:  GNU General Public License (GPL), version 2

> +MODULE_LICENSE("GPL");

The comment at the top of this file states, succinctly, that the license
is GPL v2. And, according to include/linux/module.h, the
MODULE_LICENSE() macro here states that the license is GPL v2 or later.
So I think that either that comment or the ident used in that macro
needs to change.

Ditto for 2/2.

Thanks,


Paul Bolle

radeon: 4.2-rc1 warning when unplugging DVI

[Alex Deucher]

On Mon, Jul 6, 2015 at 6:07 PM, Vadim Girlin  wrote:
> On 07/06/2015 11:56 PM, Alex Deucher wrote:
>>
>> On Mon, Jul 6, 2015 at 3:19 PM, Dave Jones 
>> wrote:
>>>
>>> I wanted to switch my LCD to a different machine momentarily.
>>> When I plugged the cable back in, this was on the screen..
>>
>>
>> Is this readily reproducible?  Did it happen with 4.1?  If it also
>> happens with 4.1 does reverting
>> 39fa10f7e21574a70cecf1fed0f9b36535aa68a0 help?  If it doesn't happen
>> with 4.1, can you bisect?
>
>
> That issue is reproducible for me with the changes after 4.1, but 4.1 is
> stable for me, I'm using it right now for that reason, radeon is pretty much
> broken for me after 4.1, doesn't resume etc (CIK/hawaii gpu).
>
> I'll test it with that patch reverted. Please let me know what additional
> info do you need, dmesg etc...

That patch was in 4.1 so I suspect it's something else.  It would be
great if you could bisect.

Alex


>
>>
>> Alex
>>
>>>
>>> WARNING: CPU: 1 PID: 209 at kernel/locking/mutex.c:526
>>> __mutex_lock_slowpath+0x322/0x340()
>>> DEBUG_LOCKS_WARN_ON(l->magic != l)
>>> CPU: 1 PID: 209 Comm: kworker/1:3 Not tainted 4.2.0-rc1-gelk-debug+ #1
>>> Workqueue: events radeon_hotplug_work_func [radeon]
>>>   0009 8800b160bc78 9969fad4 8001
>>>   8800b160bcc8 8800b160bcb8 9907689a 86be
>>>   8800a24182b8 8800a24182c0 8800b086adc0 8800a24182b8
>>> Call Trace:
>>>   [] dump_stack+0x4f/0x7b
>>>   [] warn_slowpath_common+0x8a/0xc0
>>>   [] warn_slowpath_fmt+0x46/0x50
>>>   [] __mutex_lock_slowpath+0x322/0x340
>>>   [] mutex_lock+0x2c/0x40
>>>   [] radeon_hotplug_work_func+0x26/0x80 [radeon]
>>>   [] process_one_work+0x147/0x420
>>>   [] worker_thread+0x69/0x470
>>>   [] ? preempt_count_sub+0xa3/0xf0
>>>   [] ? rescuer_thread+0x320/0x320
>>>   [] kthread+0x107/0x120
>>>   [] ? kthread_create_on_node+0x1b0/0x1b0
>>>   [] ret_from_fork+0x3f/0x70
>>>   [] ? kthread_create_on_node+0x1b0/0x1b0
>>> ---[ end trace 859b3faf9cb20dd3 ]---
>>> Oops:  [#1] PREEMPT SMP DEBUG_PAGEALLOC
>>> CPU: 1 PID: 209 Comm: kworker/1:3 Tainted: GW
>>> 4.2.0-rc1-gelk-debug+ #1
>>> Workqueue: events radeon_hotplug_work_func [radeon]
>>> task: 8800b086adc0 ti: 8800b1608000 task.ti: 8800b1608000
>>> RIP: 0010:[]  [] __list_add+0x1f/0xc0
>>> RSP: 0018:8800b160bcf8  EFLAGS: 00010046
>>> RAX: 8800a24182d8 RBX: 8800b160bd38 RCX: 
>>> RDX: 8800a24182d8 RSI:  RDI: 8800b160bd38
>>> RBP: 8800b160bd18 R08:  R09: 0fcb
>>> R10: 0353 R11:  R12: 8800a24182d8
>>> R13:  R14:  R15: 0246
>>> FS:  () GS:8800bf70()
>>> knlGS:
>>> CS:  0010 DS:  ES:  CR0: 8005003b
>>> CR2:  CR3: a25d3000 CR4: 07e0
>>> Stack:
>>>   8800b160bd18 8800a24182b8 8800a24182c0 8800b086adc0
>>>   8800b160bd88 996a5291 8800b160bd58 8800a24182d8
>>>   8800b160bd38 8800b160bd38  8800b160bd38
>>> Call Trace:
>>>   [] __mutex_lock_slowpath+0xc1/0x340
>>>   [] mutex_lock+0x2c/0x40
>>>   [] radeon_hotplug_work_func+0x26/0x80 [radeon]
>>>   [] process_one_work+0x147/0x420
>>>   [] worker_thread+0x69/0x470
>>>   [] ? preempt_count_sub+0xa3/0xf0
>>>   [] ? rescuer_thread+0x320/0x320
>>>   [] kthread+0x107/0x120
>>>   [] ? kthread_create_on_node+0x1b0/0x1b0
>>>   [] ret_from_fork+0x3f/0x70
>>>   [] ? kthread_create_on_node+0x1b0/0x1b0
>>> Code: c3 66 2e 0f 1f 84 00 00 00 00 00 90 55 48 89 e5 41 55 49 89 f5 41
>>> 54 49 89 d4 53 48 89 fb 48 83 ec 08 4c 8b 42 08 49 39 f0 75 2e <4d> 8b 45 00
>>> 4d 39 c4 75 4e 4c 39 e3 74 6b 4c 39 eb 74 66 49 89
>>>
>>>
>>> radeon is an RV370.
>>>
>>>  Dave
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

Wayland and GLES1 (Re: R200 DRM/KMS)

[Pekka Paalanen]

On Mon, 06 Jul 2015 22:50:30 +0100
Steven Newbury  wrote:

> Would gles1 be sufficient to run a Wayland compositor, I'm
> guessing probably not..?

If you can find a Wayland compositor that is written to composite with
GLES1, that's all you need from the "Wayland side". (Yeah, this has
nothing to do with Wayland per se.) Compositing in itself without any
effects is very simple, as long as you get the textures up.

Or, if you find a Wayland compositor written to use desktop OpenGL for
compositing and does not use features your GL driver does not expose,
that's good too.

Absolutely nothing about Wayland limits your choice of the GL flavour -
even more so as the compositor is not running *on* Wayland.

Also, the question of running GL apps on Wayland is a whole another
matter. There used to be a common misconception that Wayland had
something to do with only allowing GLES.

Finally, there is the option of software rendering for composition...


Thanks,
pq

[PATCH RESEND] drm/kms-helper: disable hpd_irq handling when poll=0

[Daniel Vetter]

When inlining the actual hpd output probing in

commit 69787f7da6b2adc4054357a661aaa1701a9ca76f
Author: Daniel Vetter 
Date:   Tue Oct 23 18:23:34 2012 +

drm: run the hpd irq event code directly

the check for the drm_kms_hlper.poll module option was lost. This
regressed systems where this option is used to work-around output
probing issues (like irq storms). Restore the old behaviour.

v2: Rebased over more than 2 years of history :(

Reported-by: George Amanakis 
Cc: George Amanakis 
Cc: Dave Airlie 
Cc: stable at vger.kernel.org
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_probe_helper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_probe_helper.c 
b/drivers/gpu/drm/drm_probe_helper.c
index 04203c0d2ecb..7356f3e75e4f 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -491,7 +491,7 @@ bool drm_helper_hpd_irq_event(struct drm_device *dev)
enum drm_connector_status old_status;
bool changed = false;

-   if (!dev->mode_config.poll_enabled)
+   if (!dev->mode_config.poll_enabled || !drm_kms_helper_poll)
return false;

mutex_lock(>mode_config.mutex);
-- 
2.1.4

[PATCH v2 02/20] drm: Don't update plane properties for atomic planes if it stays the same

[Maarten Lankhorst]

This allows the first atomic call during hw init to be a real modeset,
which is useful for forcing a recalculation.

Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/drm_fb_helper.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index cac422916c7a..33b5e4ecaf46 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -322,10 +322,12 @@ static bool restore_fbdev_mode(struct drm_fb_helper 
*fb_helper)
drm_warn_on_modeset_not_all_locked(dev);

list_for_each_entry(plane, >mode_config.plane_list, head) {
-   if (plane->type != DRM_PLANE_TYPE_PRIMARY)
+   if (plane->type != DRM_PLANE_TYPE_PRIMARY &&
+   (!plane->state || plane->state->fb))
drm_plane_force_disable(plane);

-   if (dev->mode_config.rotation_property) {
+   if (dev->mode_config.rotation_property &&
+   (!plane->state || plane->state->rotation != 
BIT(DRM_ROTATE_0))) {
drm_mode_plane_set_obj_prop(plane,

dev->mode_config.rotation_property,
BIT(DRM_ROTATE_0));
-- 
2.1.0

[PATCH v2 01/20] drm/atomic: add connectors_changed to separate it from mode_changed

[Maarten Lankhorst]

This can be a separate case from mode_changed, when connectors stay the
same but only the mode is different. Drivers may choose to implement specific
optimizations to prevent a full modeset for this case.

Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/drm_atomic_helper.c  | 25 +++--
 drivers/gpu/drm/i915/intel_display.c |  2 +-
 include/drm/drm_atomic.h |  3 ++-
 include/drm/drm_crtc.h   |  8 +---
 4 files changed, 27 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 66e76f4f43be..b818e3111380 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -124,7 +124,7 @@ steal_encoder(struct drm_atomic_state *state,
if (IS_ERR(crtc_state))
return PTR_ERR(crtc_state);

-   crtc_state->mode_changed = true;
+   crtc_state->connectors_changed = true;

list_for_each_entry(connector, >connector_list, head) {
if (connector->state->best_encoder != encoder)
@@ -174,14 +174,14 @@ update_connector_routing(struct drm_atomic_state *state, 
int conn_idx)
idx = drm_crtc_index(connector->state->crtc);

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

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

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

@@ -233,7 +233,7 @@ update_connector_routing(struct drm_atomic_state *state, 
int conn_idx)
idx = drm_crtc_index(connector_state->crtc);

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,
@@ -256,7 +256,8 @@ mode_fixup(struct drm_atomic_state *state)
bool ret;

for_each_crtc_in_state(state, crtc, crtc_state, i) {
-   if (!crtc_state->mode_changed)
+   if (!crtc_state->mode_changed &&
+   !crtc_state->connectors_changed)
continue;

drm_mode_copy(_state->adjusted_mode, _state->mode);
@@ -312,7 +313,8 @@ mode_fixup(struct drm_atomic_state *state)
for_each_crtc_in_state(state, crtc, crtc_state, i) {
const struct drm_crtc_helper_funcs *funcs;

-   if (!crtc_state->mode_changed)
+   if (!crtc_state->mode_changed &&
+   !crtc_state->connectors_changed)
continue;

funcs = crtc->helper_private;
@@ -373,7 +375,17 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
if (crtc->state->enable != crtc_state->enable) {
DRM_DEBUG_ATOMIC("[CRTC:%d] enable changed\n",
 crtc->base.id);
+
+   /*
+* For clarity this assignment is done here, but
+* enable == 0 is only true when there are no
+* connectors and a NULL mode.
+*
+* The other way around is true as well. enable != 0
+* iff connectors are attached and a mode is set.
+*/
crtc_state->mode_changed = true;
+   crtc_state->connectors_changed = true;
}
}

@@ -2072,6 +2084,7 @@ void __drm_atomic_helper_crtc_duplicate_state(struct 
drm_crtc *crtc,
state->mode_changed = false;
state->active_changed = false;
state->planes_changed = false;
+   state->connectors_changed = false;
state->event = NULL;
 }
 EXPORT_SYMBOL(__drm_atomic_helper_crtc_duplicate_state);
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index e91613b1c871..6ddb462b4124 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -421,7 +421,7 @@ static const intel_limit_t intel_limits_bxt = {
 static bool
 needs_modeset(struct drm_crtc_state *state)
 {
-   return state->mode_changed || state->active_changed;
+   return drm_atomic_crtc_needs_modeset(state);
 }

 /**
diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index 8a3a913320eb..e67aeac2aee0 100644
--- a/include/drm/drm_atomic.h
+++ b/include/drm/drm_atomic.h
@@ -166,7 +166,8 @@ int __must_check drm_atomic_async_commit(struct 
drm_atomic_state *state);
 static inline bool
 

[Bug 91253] Regression: Can't boot on 4.0.5 and later but can boot on 4.0.4 (on iMac)

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

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

Michel Dänzer  changed:

   What|Removed |Added

   See Also||https://bugzilla.kernel.org
   ||/show_bug.cgi?id=101131

--- Comment #1 from Michel Dänzer  ---
Please include the relevant information here directly.

-- 
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/20150707/06e16567/attachment.html>

[PATCH 2/2] drm/atomic: Cleanup on error properly in the atomic ioctl.

[Daniel Vetter]

On Wed, Jun 24, 2015 at 08:59:25AM +0200, Maarten Lankhorst wrote:
> It's probably allowed to leave old_fb set to garbage when unlocking,
> but to prevent undefined behavior unset it just in case.
> 
> Also crtc_state->event could be NULL on memory allocation failure,
> in which case event_space is increased for no reason.
> 
> Signed-off-by: Maarten Lankhorst 

Grumpy reviewer comment: You've failed to mention that you rework a few
things just because, makes it harder to spot the actual changes. Anyway,
applied to drm-misc.
-Daniel

> ---
>  drivers/gpu/drm/drm_atomic.c | 63 
> 
>  1 file changed, 29 insertions(+), 34 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index bd7f723c708e..a89f73f1dca1 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1463,18 +1463,18 @@ retry:
>  
>   if (get_user(obj_id, objs_ptr + copied_objs)) {
>   ret = -EFAULT;
> - goto fail;
> + goto out;
>   }
>  
>   obj = drm_mode_object_find(dev, obj_id, DRM_MODE_OBJECT_ANY);
>   if (!obj || !obj->properties) {
>   ret = -ENOENT;
> - goto fail;
> + goto out;
>   }
>  
>   if (get_user(count_props, count_props_ptr + copied_objs)) {
>   ret = -EFAULT;
> - goto fail;
> + goto out;
>   }
>  
>   copied_objs++;
> @@ -1486,25 +1486,25 @@ retry:
>  
>   if (get_user(prop_id, props_ptr + copied_props)) {
>   ret = -EFAULT;
> - goto fail;
> + goto out;
>   }
>  
>   prop = drm_property_find(dev, prop_id);
>   if (!prop) {
>   ret = -ENOENT;
> - goto fail;
> + goto out;
>   }
>  
>   if (copy_from_user(_value,
>  prop_values_ptr + copied_props,
>  sizeof(prop_value))) {
>   ret = -EFAULT;
> - goto fail;
> + goto out;
>   }
>  
>   ret = atomic_set_prop(state, obj, prop, prop_value);
>   if (ret)
> - goto fail;
> + goto out;
>  
>   copied_props++;
>   }
> @@ -1523,7 +1523,7 @@ retry:
>   e = create_vblank_event(dev, file_priv, arg->user_data);
>   if (!e) {
>   ret = -ENOMEM;
> - goto fail;
> + goto out;
>   }
>  
>   crtc_state->event = e;
> @@ -1533,13 +1533,15 @@ retry:
>   if (arg->flags & DRM_MODE_ATOMIC_TEST_ONLY) {
>   ret = drm_atomic_check_only(state);
>   /* _check_only() does not free state, unlike _commit() */
> - drm_atomic_state_free(state);
> + if (!ret)
> + drm_atomic_state_free(state);
>   } else if (arg->flags & DRM_MODE_ATOMIC_NONBLOCK) {
>   ret = drm_atomic_async_commit(state);
>   } else {
>   ret = drm_atomic_commit(state);
>   }
>  
> +out:
>   /* if succeeded, fixup legacy plane crtc/fb ptrs before dropping
>* locks (ie. while it is still safe to deref plane->state).  We
>* need to do this here because the driver entry points cannot
> @@ -1552,41 +1554,34 @@ retry:
>   drm_framebuffer_reference(new_fb);
>   plane->fb = new_fb;
>   plane->crtc = plane->state->crtc;
> - } else {
> - plane->old_fb = NULL;
> - }
> - if (plane->old_fb) {
> - drm_framebuffer_unreference(plane->old_fb);
> - plane->old_fb = NULL;
> +
> + if (plane->old_fb)
> + drm_framebuffer_unreference(plane->old_fb);
>   }
> + plane->old_fb = NULL;
>   }
>  
> - drm_modeset_drop_locks();
> - drm_modeset_acquire_fini();
> -
> - return ret;
> + if (ret == -EDEADLK) {
> + drm_atomic_state_clear(state);
> + drm_modeset_backoff();
> + goto retry;
> + }
>  
> -fail:
> - if (ret == -EDEADLK)
> - goto backoff;
> + if (ret) {
> + if (arg->flags & DRM_MODE_PAGE_FLIP_EVENT) {
> + for_each_crtc_in_state(state, crtc, crtc_state, i) {
> + 

[PATCH] drm: Update plane->fb also for page_flip

[Daniel Vetter]

On Tue, Jul 07, 2015 at 08:43:03AM +0200, Daniel Vetter wrote:
> The legacy page_flip driver entry point is the only one left which
> requires drivers to update plane->fb themselves. All the other entry
> hooks will patch things up for the driver as needed since no one seems
> to reliable get this right, see e.g. drm_mode_set_config_internal or
> the plane->fb/old_fb handling in drm_mode_atomic_ioctl.
> 
> Therefore unify things, which allows us to ditch a TODO from
> drm_atomic_helper_page_flip.
> 
> This should also help the atomic transition in i915 since we keep a
> bit of legacy cruft only around because of this special behaviour in
> ->page_flip.
> 
> Cc: Maarten Lankhorst 
> Signed-off-by: Daniel Vetter 

Applied with Maarten's irc r-b to drm-misc.
-Daniel

> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 4 
>  drivers/gpu/drm/drm_crtc.c  | 8 +---
>  2 files changed, 1 insertion(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 5b59d5ad7d1c..0898afbc9e23 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1915,10 +1915,6 @@ retry:
>   if (ret != 0)
>   goto fail;
>  
> - /* TODO: ->page_flip is the only driver callback where the core
> -  * doesn't update plane->fb. For now patch it up here. */
> - plane->fb = plane->state->fb;
> -
>   /* Driver takes ownership of state on successful async commit. */
>   return 0;
>  fail:
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index d15a96fdff43..ee0b3bf166b6 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -5345,13 +5345,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
>   /* Keep the old fb, don't unref it. */
>   crtc->primary->old_fb = NULL;
>   } else {
> - /*
> -  * Warn if the driver hasn't properly updated the crtc->fb
> -  * field to reflect that the new framebuffer is now used.
> -  * Failing to do so will screw with the reference counting
> -  * on framebuffers.
> -  */
> - WARN_ON(crtc->primary->fb != fb);
> + crtc->primary->fb = fb;
>   /* Unref only the old framebuffer. */
>   fb = NULL;
>   }
> -- 
> 2.1.4
> 

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

[PATCH] drm: Update plane->fb also for page_flip

[Daniel Vetter]

The legacy page_flip driver entry point is the only one left which
requires drivers to update plane->fb themselves. All the other entry
hooks will patch things up for the driver as needed since no one seems
to reliable get this right, see e.g. drm_mode_set_config_internal or
the plane->fb/old_fb handling in drm_mode_atomic_ioctl.

Therefore unify things, which allows us to ditch a TODO from
drm_atomic_helper_page_flip.

This should also help the atomic transition in i915 since we keep a
bit of legacy cruft only around because of this special behaviour in
->page_flip.

Cc: Maarten Lankhorst 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_atomic_helper.c | 4 
 drivers/gpu/drm/drm_crtc.c  | 8 +---
 2 files changed, 1 insertion(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 5b59d5ad7d1c..0898afbc9e23 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1915,10 +1915,6 @@ retry:
if (ret != 0)
goto fail;

-   /* TODO: ->page_flip is the only driver callback where the core
-* doesn't update plane->fb. For now patch it up here. */
-   plane->fb = plane->state->fb;
-
/* Driver takes ownership of state on successful async commit. */
return 0;
 fail:
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index d15a96fdff43..ee0b3bf166b6 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -5345,13 +5345,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
/* Keep the old fb, don't unref it. */
crtc->primary->old_fb = NULL;
} else {
-   /*
-* Warn if the driver hasn't properly updated the crtc->fb
-* field to reflect that the new framebuffer is now used.
-* Failing to do so will screw with the reference counting
-* on framebuffers.
-*/
-   WARN_ON(crtc->primary->fb != fb);
+   crtc->primary->fb = fb;
/* Unref only the old framebuffer. */
fb = NULL;
}
-- 
2.1.4

[Bug 91253] Regression: Can't boot on 4.0.5 and later but can boot on 4.0.4 (on iMac)

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

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

Andreas Tunek  changed:

   What|Removed |Added

  Component|Driver/Radeon   |DRM/Radeon
   Assignee|xorg-driver-ati at lists.x.org |dri-devel at 
lists.freedesktop
   ||.org
Product|xorg|DRI
 QA Contact|xorg-team at lists.x.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/20150707/f8ea6175/attachment.html>

[Bug 101131] New: Regression: Can't boot on 4.0.5 and later but can boot on 4.0.4 (on iMac)

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

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

Bug ID: 101131
   Summary: Regression: Can't boot on 4.0.5 and later but can boot
on 4.0.4 (on iMac)
   Product: Drivers
   Version: 2.5
Kernel Version: 4.0.5
  Hardware: All
OS: Linux
  Tree: Fedora
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-dri at kernel-bugs.osdl.org
  Reporter: andreas.tunek at gmail.com
Regression: No

Using the Fedora Linux I can't boot with Linux from 4.0.5 and up. 4.0.4 still
works.

Here is a link to the fedora bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1236423   

Any more info I should add?

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

[Bug 91193] [290x] Dota2 reborn ingame rendering breaks with git-af4b9c7

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

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

Michel Dänzer  changed:

   What|Removed |Added

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

--- Comment #6 from Michel Dänzer  ---
Commit: 248b26429f52d0f19949a083aa3e0aeebcbe2138
URL:   
http://cgit.freedesktop.org/mesa/mesa/commit/?id=248b26429f52d0f19949a083aa3e0aeebcbe2138

Author: Michel Dänzer 
Date:   Mon Jul  6 17:23:07 2015 +0900

radeonsi: Use param export count from si_llvm_export_vs in si_shader_vs

-- 
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/20150707/1394c80c/attachment.html>

[Bug 85580] [RadeonSI] Bad performance in TF2.

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

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

Aaron B  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #3 from Aaron B  ---
Probably fixed eventually, never tested but going to just close assuming it's
fixed since it's the biggest linux game really.

-- 
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/20150707/61ece162/attachment.html>

[Bug 66963] Rv6xx dpm problems

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

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

--- Comment #273 from Michel Dänzer  ---
(In reply to Kajzer from comment #272)
> Problem manifest itself exactly the same as this dpm problem.

The original description of this report says: "screen becomes blank after grub
trying to boot it". Please file your own report.


> I don't know what else I can do to help with this.

Please run a kernel built from commit 77497f2735ad6e29c55475e15e9790dbfa2c2ef8
(the commit before 02376d8282b88f07d0716da6155094c8760b1a13) for at least a few
days to make sure it doesn't happen with that.

-- 
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/20150707/6a374e2a/attachment.html>

radeon: 4.2-rc1 warning when unplugging DVI

[Vadim Girlin]

On 07/07/2015 01:07 AM, Vadim Girlin wrote:
> On 07/06/2015 11:56 PM, Alex Deucher wrote:
>> On Mon, Jul 6, 2015 at 3:19 PM, Dave Jones 
>> wrote:
>>> I wanted to switch my LCD to a different machine momentarily.
>>> When I plugged the cable back in, this was on the screen..
>>
>> Is this readily reproducible?  Did it happen with 4.1?  If it also
>> happens with 4.1 does reverting
>> 39fa10f7e21574a70cecf1fed0f9b36535aa68a0 help?  If it doesn't happen
>> with 4.1, can you bisect?
>
> That issue is reproducible for me with the changes after 4.1, but 4.1 is

By issue I mean the "don't has a mapping" flood, not sure if the thread 
is discussing something else already. I usually hit it after resume, and 
I typically had to reboot, that solves it.


> stable for me, I'm using it right now for that reason, radeon is pretty
> much broken for me after 4.1, doesn't resume etc (CIK/hawaii gpu).
>
> I'll test it with that patch reverted. Please let me know what
> additional info do you need, dmesg etc...
>
>>
>> Alex
>>
>>>
>>> WARNING: CPU: 1 PID: 209 at kernel/locking/mutex.c:526
>>> __mutex_lock_slowpath+0x322/0x340()
>>> DEBUG_LOCKS_WARN_ON(l->magic != l)
>>> CPU: 1 PID: 209 Comm: kworker/1:3 Not tainted 4.2.0-rc1-gelk-debug+ #1
>>> Workqueue: events radeon_hotplug_work_func [radeon]
>>>   0009 8800b160bc78 9969fad4 8001
>>>   8800b160bcc8 8800b160bcb8 9907689a 86be
>>>   8800a24182b8 8800a24182c0 8800b086adc0 8800a24182b8
>>> Call Trace:
>>>   [] dump_stack+0x4f/0x7b
>>>   [] warn_slowpath_common+0x8a/0xc0
>>>   [] warn_slowpath_fmt+0x46/0x50
>>>   [] __mutex_lock_slowpath+0x322/0x340
>>>   [] mutex_lock+0x2c/0x40
>>>   [] radeon_hotplug_work_func+0x26/0x80 [radeon]
>>>   [] process_one_work+0x147/0x420
>>>   [] worker_thread+0x69/0x470
>>>   [] ? preempt_count_sub+0xa3/0xf0
>>>   [] ? rescuer_thread+0x320/0x320
>>>   [] kthread+0x107/0x120
>>>   [] ? kthread_create_on_node+0x1b0/0x1b0
>>>   [] ret_from_fork+0x3f/0x70
>>>   [] ? kthread_create_on_node+0x1b0/0x1b0
>>> ---[ end trace 859b3faf9cb20dd3 ]---
>>> Oops:  [#1] PREEMPT SMP DEBUG_PAGEALLOC
>>> CPU: 1 PID: 209 Comm: kworker/1:3 Tainted: GW
>>> 4.2.0-rc1-gelk-debug+ #1
>>> Workqueue: events radeon_hotplug_work_func [radeon]
>>> task: 8800b086adc0 ti: 8800b1608000 task.ti: 8800b1608000
>>> RIP: 0010:[]  []
>>> __list_add+0x1f/0xc0
>>> RSP: 0018:8800b160bcf8  EFLAGS: 00010046
>>> RAX: 8800a24182d8 RBX: 8800b160bd38 RCX: 
>>> RDX: 8800a24182d8 RSI:  RDI: 8800b160bd38
>>> RBP: 8800b160bd18 R08:  R09: 0fcb
>>> R10: 0353 R11:  R12: 8800a24182d8
>>> R13:  R14:  R15: 0246
>>> FS:  () GS:8800bf70()
>>> knlGS:
>>> CS:  0010 DS:  ES:  CR0: 8005003b
>>> CR2:  CR3: a25d3000 CR4: 07e0
>>> Stack:
>>>   8800b160bd18 8800a24182b8 8800a24182c0 8800b086adc0
>>>   8800b160bd88 996a5291 8800b160bd58 8800a24182d8
>>>   8800b160bd38 8800b160bd38  8800b160bd38
>>> Call Trace:
>>>   [] __mutex_lock_slowpath+0xc1/0x340
>>>   [] mutex_lock+0x2c/0x40
>>>   [] radeon_hotplug_work_func+0x26/0x80 [radeon]
>>>   [] process_one_work+0x147/0x420
>>>   [] worker_thread+0x69/0x470
>>>   [] ? preempt_count_sub+0xa3/0xf0
>>>   [] ? rescuer_thread+0x320/0x320
>>>   [] kthread+0x107/0x120
>>>   [] ? kthread_create_on_node+0x1b0/0x1b0
>>>   [] ret_from_fork+0x3f/0x70
>>>   [] ? kthread_create_on_node+0x1b0/0x1b0
>>> Code: c3 66 2e 0f 1f 84 00 00 00 00 00 90 55 48 89 e5 41 55 49 89 f5
>>> 41 54 49 89 d4 53 48 89 fb 48 83 ec 08 4c 8b 42 08 49 39 f0 75 2e
>>> <4d> 8b 45 00 4d 39 c4 75 4e 4c 39 e3 74 6b 4c 39 eb 74 66 49 89
>>>
>>>
>>> radeon is an RV370.
>>>
>>>  Dave
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>

radeon: 4.2-rc1 warning when unplugging DVI

[Vadim Girlin]

On 07/06/2015 11:56 PM, Alex Deucher wrote:
> On Mon, Jul 6, 2015 at 3:19 PM, Dave Jones  wrote:
>> I wanted to switch my LCD to a different machine momentarily.
>> When I plugged the cable back in, this was on the screen..
>
> Is this readily reproducible?  Did it happen with 4.1?  If it also
> happens with 4.1 does reverting
> 39fa10f7e21574a70cecf1fed0f9b36535aa68a0 help?  If it doesn't happen
> with 4.1, can you bisect?

That issue is reproducible for me with the changes after 4.1, but 4.1 is 
stable for me, I'm using it right now for that reason, radeon is pretty 
much broken for me after 4.1, doesn't resume etc (CIK/hawaii gpu).

I'll test it with that patch reverted. Please let me know what 
additional info do you need, dmesg etc...

>
> Alex
>
>>
>> WARNING: CPU: 1 PID: 209 at kernel/locking/mutex.c:526 
>> __mutex_lock_slowpath+0x322/0x340()
>> DEBUG_LOCKS_WARN_ON(l->magic != l)
>> CPU: 1 PID: 209 Comm: kworker/1:3 Not tainted 4.2.0-rc1-gelk-debug+ #1
>> Workqueue: events radeon_hotplug_work_func [radeon]
>>   0009 8800b160bc78 9969fad4 8001
>>   8800b160bcc8 8800b160bcb8 9907689a 86be
>>   8800a24182b8 8800a24182c0 8800b086adc0 8800a24182b8
>> Call Trace:
>>   [] dump_stack+0x4f/0x7b
>>   [] warn_slowpath_common+0x8a/0xc0
>>   [] warn_slowpath_fmt+0x46/0x50
>>   [] __mutex_lock_slowpath+0x322/0x340
>>   [] mutex_lock+0x2c/0x40
>>   [] radeon_hotplug_work_func+0x26/0x80 [radeon]
>>   [] process_one_work+0x147/0x420
>>   [] worker_thread+0x69/0x470
>>   [] ? preempt_count_sub+0xa3/0xf0
>>   [] ? rescuer_thread+0x320/0x320
>>   [] kthread+0x107/0x120
>>   [] ? kthread_create_on_node+0x1b0/0x1b0
>>   [] ret_from_fork+0x3f/0x70
>>   [] ? kthread_create_on_node+0x1b0/0x1b0
>> ---[ end trace 859b3faf9cb20dd3 ]---
>> Oops:  [#1] PREEMPT SMP DEBUG_PAGEALLOC
>> CPU: 1 PID: 209 Comm: kworker/1:3 Tainted: GW   
>> 4.2.0-rc1-gelk-debug+ #1
>> Workqueue: events radeon_hotplug_work_func [radeon]
>> task: 8800b086adc0 ti: 8800b1608000 task.ti: 8800b1608000
>> RIP: 0010:[]  [] __list_add+0x1f/0xc0
>> RSP: 0018:8800b160bcf8  EFLAGS: 00010046
>> RAX: 8800a24182d8 RBX: 8800b160bd38 RCX: 
>> RDX: 8800a24182d8 RSI:  RDI: 8800b160bd38
>> RBP: 8800b160bd18 R08:  R09: 0fcb
>> R10: 0353 R11:  R12: 8800a24182d8
>> R13:  R14:  R15: 0246
>> FS:  () GS:8800bf70() knlGS:
>> CS:  0010 DS:  ES:  CR0: 8005003b
>> CR2:  CR3: a25d3000 CR4: 07e0
>> Stack:
>>   8800b160bd18 8800a24182b8 8800a24182c0 8800b086adc0
>>   8800b160bd88 996a5291 8800b160bd58 8800a24182d8
>>   8800b160bd38 8800b160bd38  8800b160bd38
>> Call Trace:
>>   [] __mutex_lock_slowpath+0xc1/0x340
>>   [] mutex_lock+0x2c/0x40
>>   [] radeon_hotplug_work_func+0x26/0x80 [radeon]
>>   [] process_one_work+0x147/0x420
>>   [] worker_thread+0x69/0x470
>>   [] ? preempt_count_sub+0xa3/0xf0
>>   [] ? rescuer_thread+0x320/0x320
>>   [] kthread+0x107/0x120
>>   [] ? kthread_create_on_node+0x1b0/0x1b0
>>   [] ret_from_fork+0x3f/0x70
>>   [] ? kthread_create_on_node+0x1b0/0x1b0
>> Code: c3 66 2e 0f 1f 84 00 00 00 00 00 90 55 48 89 e5 41 55 49 89 f5 41 54 
>> 49 89 d4 53 48 89 fb 48 83 ec 08 4c 8b 42 08 49 39 f0 75 2e <4d> 8b 45 00 4d 
>> 39 c4 75 4e 4c 39 e3 74 6b 4c 39 eb 74 66 49 89
>>
>>
>> radeon is an RV370.
>>
>>  Dave
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

R200 DRM/KMS

[Daniel Vetter]

On Mon, Jul 06, 2015 at 09:06:28PM +0100, Steven Newbury wrote:
> On Mon, 2015-07-06 at 15:42 -0400, Alex Deucher wrote:
> > On Mon, Jul 6, 2015 at 2:40 PM, Steven Newbury  > > wrote:
> > > On Mon, 2015-07-06 at 12:25 -0400, Alex Deucher wrote:
> > > > On Mon, Jul 6, 2015 at 9:39 AM, Steven Newbury <
> > > > steve at snewbury.org.uk
> > > > > wrote:
> > > > > Hi,
> > > > > I've been trying to get DRM/KMS working with the current 
> > > > > graphics
> > > > > stack (xf86-video-ati 7.5, xserver-1.17) on a R200 series 
> > > > > card.  I
> > > > > assumed this should be working since KMS was implemented for 
> > > > > it a
> > > > > while back, and it has been working with xf86-video-ati-6.x.
> > > > > 
> > > > > Unfortunately, it doesn't seem to work.
> > > > > 
> > > > > I've narrowed it down to drmSetInterfaceVersion() failing when
> > > > > called
> > > > > from the ATI driver (in radeon_kms.c).  This is a bit strange
> > > > > since,
> > > > > /sys/class/drm/version correctly reports 1.1.0 20060810. 
> > > > >  Presuably
> > > > > it's getting the correct fd for the DRM master otherwise it 
> > > > > should
> > > > > bail earlier?
> > > > > 
> > > > > 
> > > > > Googling confirms others have had the same issue, and 
> > > > > generally the
> > > > > resolution has been to stick with the old driver.
> > > > > 
> > > > > Should this be working?  Is it known to be broken?
> > > > 
> > > > It should be working.  Make sure the kernel driver has kms 
> > > > enabled,
> > > > firmware available, and that the kernel driver is loaded before
> > > > starting X.  If the kernel driver is not loaded before X starts 
> > > > you
> > > > can get a version mis-match error.
> > > 
> > > Yes, using Gentoos 4.1.1 kernel, driver is definitely loaded, with
> > > modeset=1, which is working, all sysfs entries are there.  gdm 
> > > manages
> > > to fall back to starting up an X session without using DRM swrast
> > > -only, not something you want to experience on such a weak CPU!
> > > 
> > 
> > If the kernel driver loads properly and you get a kms console you
> > should be good to go.
> > 
> > > Manually starting X fails with the "[drm] failed to set drm 
> > > interface
> > > version." error.
> > > 
> > 
> > Maybe the ddx with that old system was build without KMS support?
> Everything is freshly compiled.  The error itself is coming from
> radeon_kms.c:651 in the ddx.

Do you have latest libdrm? We might have accidentally broken this for very
old versions of libdrm (although surprising this would compile with
everything else).
-Daniel
> 
> > 
> > Alex
> > 
> > > It's a very old system, PCI-only(!) Coppermine-128, belonging to a
> > > friend.  The system previously was (very slowly) running Ubuntu 10
> > > LTS, I think.  It's not my machine so I'm not able to have 
> > > continuous
> > > access, but R200 DRM/KMS was working.  Apparently, Ubuntu no longer
> > > support R200, so no further updates were possible.
> > > 
> > > My friend can't afford a new machine at the moment; and since I'm a
> > > long time Gentoo dev I took it upon myself to build him a optimized
> > > desktop with gcc-5, where possible LTO, -Os, -march=pentium3 with 
> > > the
> > > system L1 and L2 cache size information.  It's quite possible some
> > > part of the gfx stack is miscompiled, I tested it pretty throughly
> > > under qemu (with qxl) before deployment, but that of course didn't
> > > exercise the R200 driver.  FWIW, other than the failing DRI,
> > > performance is surprisingly OK, not super fast obviously, but a 
> > > *lot*
> > > better than under Ubuntu! (start-up time is alot quicker, by an 
> > > order
> > > of magnitude!)
> > > 
> > > I'm attempting to downgrade the xserver and drivers (on the live
> > > system) to see if that works, you can imagine that takes a little
> > > while on a Coppermine-128!  I'll find out tomorrow.  Otherwise, I
> > > guess I'm recompiling the stack with gcc-4.9 and no-LTO...



> ___
> 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