r600_dma_ring_test() failed - synchronization problem with write-combining memory

[Alexander Fyodorov]

09.10.2014, 21:42, "Christian K?nig" :
> Hi Alexander,
>
> in the ring test we write the value 0xDEADBEEF and 0xCAFEDEAD into
> registers, not VRAM.
>
> And the register bar shouldn't be accessed write combined, cause that
> could lead to a couple of ordering problems. Why do you think the access
> is done write combined?

Because there is this code in r600_dma_ring_test():
  void __iomem *ptr = (void *)rdev->vram_scratch.ptr;

And vram_scratch is allocated in r600_vram_scratch_init() with domain 
RADEON_GEM_DOMAIN_VRAM which implies write-combining. I assumed that this means 
it points to the video memory.

Also when I look at page table attributes I can see that it is indeed mapped as 
write-combining. In this test only "rdev->rmmio" area was mapped as UC (the one 
where radeon_ring_commit() writes to to start the execution).

> For VRAM it is true that we have a couple of different caches between
> the CPU and the actually memory, which need to be flushed explicitly if
> you want to see a value written by the GPU.

Then maybe such a flush is what I need. How do I put it in the instruction ring 
buffer?

AMD GPU new API for new module

[Oded Gabbay]

Thanks for the input.
I do _not_ intend to fork IOCTLs for new H/W generations, if possible.
i.e, our driver now supports 2 h/w generations with the exact same set
of IOCTLs and I don't see how that would change in the future..

What I'm more worried about is supporting different sets of UMD, which
will require different IOCTLs for the same operation, e.g. CreateQueue
for HSA runtime and OpenCL runtime.

However, due to a very limited amount of UMDs, the "regular" way of
adding IOCTLs may be sufficient.

Bottom line, need to think more about it :)

Oded

On 09/10/14 18:55, Daniel Vetter wrote:
> On Thu, Oct 9, 2014 at 12:15 PM, Oded Gabbay  wrote:
>> Well, I don't expect to reach 100 ioctls anytime soon, but I can tell
>> you that for the features we have in the pipeline, I can see the IOCTL
>> number go up to 20-30, just for the current H/W generation.
> 
> So our Android folks seem to routinely run out of ioctl numbers in
> their product/downstream branches. But ime after some decent review of
> the new interfaces and not just blindly creating interfaces because
> that's easier we have rather slow ioctl number consumption in i915. So
> presuming you do decent review and dont fork your driver for every
> generation (which seems to be how every blob gfx driver team works) I
> don't think you have a problem. Of course that's a massive change in
> approach and in my experience with intel-internal discussion will
> require a lot of training.
> -Daniel
> 

[Bug 84662] Long pauses with Unreal demo Elemental on R9270X since : Always flush the HDP cache before submitting a CS to the GPU

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

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

--- Comment #36 from Jos? Su?rez  ---
(In reply to Luzipher from comment #34)
> As todays commit 7b4276d7acf2e0f77044cb50caa6ad936fa78786, "r600g,radeonsi:
> Always use GTT again for PIPE_USAGE_STREAM buffers", refers to this bug:
> The patch helps tremendously against stuttering (~0.5s pause irregularly
> about twice a minute) in Borderlands 2. Kernel is an unmodified agd5f
> 3.18-next, hardware r9 290x.
> 
> Thanks !

That mesa patch also reduced my stutter in BL2. Right now (I have just tested 5
minutes) I only get short lags when the game must load new areas/models (e.g.
making a turn or entering new map zones). I'm on 3.17 rc7 (Radeon HD 7870).

The stutter was also very noticeable in EuroTruck Simulator 2, making the game
almost unplayable. There still a few stutters in this game, so I would say the
stutter is not completely gone (even though my BL2 experience is good).

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

r600_dma_ring_test() failed - synchronization problem with write-combining memory

[Christian König]

Am 09.10.2014 um 20:15 schrieb Alexander Fyodorov:
> 09.10.2014, 21:42, "Christian K?nig" :
>> Hi Alexander,
>>
>> in the ring test we write the value 0xDEADBEEF and 0xCAFEDEAD into
>> registers, not VRAM.
>>
>> And the register bar shouldn't be accessed write combined, cause that
>> could lead to a couple of ordering problems. Why do you think the access
>> is done write combined?
> Because there is this code in r600_dma_ring_test():
>void __iomem *ptr = (void *)rdev->vram_scratch.ptr;
>
> And vram_scratch is allocated in r600_vram_scratch_init() with domain 
> RADEON_GEM_DOMAIN_VRAM which implies write-combining. I assumed that this 
> means it points to the video memory.

Ah! Sorry, you are talking about the DMA ring test, not the GFX ring 
test. Right in this case we use a bit of VRAM for the test.

> Also when I look at page table attributes I can see that it is indeed mapped 
> as write-combining. In this test only "rdev->rmmio" area was mapped as UC 
> (the one where radeon_ring_commit() writes to to start the execution).

Correct, that's the register bar.

>
>> For VRAM it is true that we have a couple of different caches between
>> the CPU and the actually memory, which need to be flushed explicitly if
>> you want to see a value written by the GPU.
> Then maybe such a flush is what I need. How do I put it in the instruction 
> ring buffer?
At least we need to flush the HDP, but what hardware generation is this 
exactly? Some R6xx don't support hardware flushes in the ring buffer.

Try to call r600_mmio_hdp_flush(rdev) from the loop which checks the 
value written.

Regards,
Christian.

[Bug 84662] Long pauses with Unreal demo Elemental on R9270X since : Always flush the HDP cache before submitting a CS to the GPU

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

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

--- Comment #35 from Chernovsky Oleg  ---
(In reply to Luzipher from comment #34)
> The patch helps tremendously against stuttering (~0.5s pause irregularly
> about twice a minute) in Borderlands 2

So are the stutters completely gone or just became smaller?

-- 
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/20141009/f01c169a/attachment.html>

[Bug 84662] Long pauses with Unreal demo Elemental on R9270X since : Always flush the HDP cache before submitting a CS to the GPU

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

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

--- Comment #34 from Luzipher  ---
As todays commit 7b4276d7acf2e0f77044cb50caa6ad936fa78786, "r600g,radeonsi:
Always use GTT again for PIPE_USAGE_STREAM buffers", refers to this bug:
The patch helps tremendously against stuttering (~0.5s pause irregularly about
twice a minute) in Borderlands 2. Kernel is an unmodified agd5f 3.18-next,
hardware r9 290x.

Thanks !

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

r600_dma_ring_test() failed - synchronization problem with write-combining memory

[Christian König]

Hi Alexander,

in the ring test we write the value 0xDEADBEEF and 0xCAFEDEAD into 
registers, not VRAM.

And the register bar shouldn't be accessed write combined, cause that 
could lead to a couple of ordering problems. Why do you think the access 
is done write combined?

For VRAM it is true that we have a couple of different caches between 
the CPU and the actually memory, which need to be flushed explicitly if 
you want to see a value written by the GPU.

Regards,
Christian.

Am 09.10.2014 um 13:39 schrieb Alexander Fyodorov:
> Hi David,
>
> I'm using 3.10.53-rt56 kernel and encounter a problem in
> r600_dma_ring_test() when vram memory is mapped as write-combining:
> no matter how long the polling is done, old value (0xCAFEDEAD) is read.
>
> Looking with hardware analyzer at what actually happens in the PCI-E bus,
> the memory is accessed with 32-byte loads (8 words at a time). That is,
> when the memory is mapped as write-combining, the processor converts
> every readl() into a 32-bytes load transaction.
>
> After doing some more experiments, it seems that Radeon has some kind of
> cache that keeps the old value (0xCAFEDEAD), and this cache is invalidated
> when:
> 1) Some other VRAM address is accessed, or
> 2) Processor issues a 4-byte load transaction.
>
> The problem is that as long as the memory is write-combining, all loads
> will be converted to be 32-bytes long by the CPU, so the test fails with
> timeout. But if I comment out this particular ring test, everything
> seems to be working fine (tested with Doom 3).
>
> Is it possible that the situation r600_dma_ring_test() checks for does
> not happen in real life, and I should be OK commenting it out?
>
> Or maybe the test is broken and some cache-flushing command must be
> written into the ring buffer?
>
> BTW this is an out-of-tree architecture, so bisecting is not possible.
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 79980] Random radeonsi crashes

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

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

--- Comment #151 from initzero at gmail.com ---
Same issues with my OLAND card here.
Archlinux, Mesa 10.3, Xorg 1.16.1 and Radeon 7.5.0.

Kernel 3.14.20 is still stable, 3.16.X and 3.17 may run for approx. 1hr and
finally crash during normal desktop usage (Gnome 3.14 + Browser + ...). Didn't
check 3.15 recently.

Sooner or later someone needs to bisect that sucker! :)

-- 
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/20141009/4be51a04/attachment.html>

[PATCH] drm/exynos: fix vblank handling during dpms off

[Alexandre Courbot]

On Thu, Oct 9, 2014 at 7:08 PM, Thierry Reding  wrote:
> On Thu, Oct 09, 2014 at 02:43:02PM +0900, Alexandre Courbot wrote:
>> On 10/02/2014 08:52 PM, Andrzej Hajda wrote:
>> >Hi,
>> >
>> >+CC possible victims
>> >
>> >On 10/02/2014 12:52 PM, Inki Dae wrote:
>> >>On 2014? 10? 02? 17:58, Joonyoung Shim wrote:
>> >>>Hi Andrzej,
>> >>>
>> >>>On 10/01/2014 05:14 PM, Andrzej Hajda wrote:
>> The patch disables vblanks during dpms off only if pagefilp has
>> not been finished. It also replaces drm_vblank_off with 
>> drm_crtc_vblank_put.
>> It fixes issue with page_flip ioctl not being able to acquire vblank 
>> counter.
>> >>>This problem isn't related with pageflip, it just causes from
>> >>>7ffd7a68511c710b84db3548a1997fd2625f580a commit (drm: Always reject
>> >>>drm_vblank_get() after drm_vblank_off()).
>> >>>
>> >>>We need to use drm_vblank_on() as a counterpart to drm_vblank_off()
>> >>>after the commit .
>> >
>> >This patch should break also other drivers, it seems at least following
>> >drms could be affected:
>> >armada, sti, tegra.
>>
>> Indeed we (tegra) have just been hit by this. The problem seems to come from
>> the fact that we have been using drm_vblank_pre_modeset,
>> drm_vblank_post_modeset and drm_vblank_off conjointly. All these functions
>> depend on the value of vblank->inmodeset, and 7ffd7a68511 increases the
>> vblank reference counter only in drm_vblank_off, which can result in the
>> acquired reference never being released.
>>
>> The following seems to fix this for Tegra, by stopping using
>> drm_vblank_pre/post_modeset and relying on drm_vblank_off/on instead:
>>
>> diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
>> index b08df07cad47..3955d81236d0 100644
>> --- a/drivers/gpu/drm/tegra/dc.c
>> +++ b/drivers/gpu/drm/tegra/dc.c
>> @@ -739,7 +739,6 @@ static const struct drm_crtc_funcs tegra_crtc_funcs = {
>>
>>  static void tegra_crtc_disable(struct drm_crtc *crtc)
>>  {
>> -   struct tegra_dc *dc = to_tegra_dc(crtc);
>> struct drm_device *drm = crtc->dev;
>> struct drm_plane *plane;
>>
>> @@ -755,7 +754,7 @@ static void tegra_crtc_disable(struct drm_crtc *crtc)
>> }
>> }
>>
>> -   drm_vblank_off(drm, dc->pipe);
>> +   drm_crtc_vblank_off(crtc);
>>  }
>>
>>  static bool tegra_crtc_mode_fixup(struct drm_crtc *crtc,
>> @@ -844,7 +843,7 @@ static int tegra_crtc_mode_set(struct drm_crtc *crtc,
>> u32 value;
>> int err;
>>
>> -   drm_vblank_pre_modeset(crtc->dev, dc->pipe);
>> +   drm_crtc_vblank_off(crtc);
>>
>> err = tegra_crtc_setup_clk(crtc, mode);
>> if (err) {
>> @@ -946,7 +945,7 @@ static void tegra_crtc_commit(struct drm_crtc *crtc)
>> value = GENERAL_ACT_REQ | WIN_A_ACT_REQ;
>> tegra_dc_writel(dc, value, DC_CMD_STATE_CONTROL);
>>
>> -   drm_vblank_post_modeset(crtc->dev, dc->pipe);
>> +   drm_crtc_vblank_on(crtc);
>>  }
>>
>>  static void tegra_crtc_load_lut(struct drm_crtc *crtc)
>>
>> Thierry, does this look ok to you?
>
> Yes, that looks like almost the same patch that I sent out yesterday.
> The difference is that I didn't replace the drm_vblank_pre_modeset()
> call with drm_vblank_off() like you did, but rather just dropped the
> former.
>
> I /think/ your version is more correct in that regard.

Feel free to take that extra line in your patch then. ;)

>
> Thierry
>
>> But there might be another issue, which is that calls to drm_vblank_get()
>> will return -EINVAL if invoked between drm_blank_off and drm_blank_on. Is
>> this really the desired behavior? Can it at least happen? If so, how are
>> drivers supposed to react to this situation?
>
> It shouldn't happen. If drm_vblank_off() and drm_vblank_on() are called
> around a modeset they should never conflict with drm_vblank_get(), at
> least on Tegra, because the modeset and page-flip IOCTLs will be
> serialized.

Ok, that's good. I was just wondering whether this case has been thought of.

Actually, and seeing how drm_vblank_pre/post_modeset() have become
useless (if not harmful), maybe it would be a good idea to come with a
fixup patch that gets rid of them altogether and make their callers
invoke drm_vblank_off/on() instead?

[PATCH 2/2] drm/radeon: Try evicting from CPU accessible to inaccessible VRAM first

[Michel Dänzer]

From: Michel D?nzer 

Signed-off-by: Michel D?nzer 
---
 drivers/gpu/drm/radeon/radeon_ttm.c | 25 -
 1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 8624979..cbe7b32 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -198,7 +198,30 @@ static void radeon_evict_flags(struct ttm_buffer_object 
*bo,
case TTM_PL_VRAM:
if (rbo->rdev->ring[RADEON_RING_TYPE_GFX_INDEX].ready == false)
radeon_ttm_placement_from_domain(rbo, 
RADEON_GEM_DOMAIN_CPU);
-   else
+   else if (rbo->rdev->mc.visible_vram_size < 
rbo->rdev->mc.real_vram_size &&
+bo->mem.start < (rbo->rdev->mc.visible_vram_size >> 
PAGE_SHIFT)) {
+   unsigned fpfn = rbo->rdev->mc.visible_vram_size >> 
PAGE_SHIFT;
+   int i;
+
+   /* Try evicting to the CPU inaccessible part of VRAM
+* first, but only set GTT as busy placement, so this
+* BO will be evicted to GTT rather than causing other
+* BOs to be evicted from VRAM
+*/
+   radeon_ttm_placement_from_domain(rbo, 
RADEON_GEM_DOMAIN_VRAM |
+RADEON_GEM_DOMAIN_GTT);
+   rbo->placement.num_busy_placement = 0;
+   for (i = 0; i < rbo->placement.num_placement; i++) {
+   if (rbo->placements[i].flags & 
TTM_PL_FLAG_VRAM) {
+   if (rbo->placements[0].fpfn < fpfn)
+   rbo->placements[0].fpfn = fpfn;
+   } else {
+   rbo->placement.busy_placement =
+   >placements[i];
+   rbo->placement.num_busy_placement = 1;
+   }
+   }
+   } else
radeon_ttm_placement_from_domain(rbo, 
RADEON_GEM_DOMAIN_GTT);
break;
case TTM_PL_TT:
-- 
2.1.1

[PATCH 1/2] drm/radeon: Try placing NO_CPU_ACCESS BOs outside of CPU accessible VRAM

[Michel Dänzer]

From: Michel D?nzer 

This avoids them getting in the way of BOs which might be accessed by
the CPU. They can still go to the CPU accessible part of VRAM though if
there's no space outside of it.

Signed-off-by: Michel D?nzer 
---
 drivers/gpu/drm/radeon/radeon_object.c | 42 --
 1 file changed, 35 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
b/drivers/gpu/drm/radeon/radeon_object.c
index 99a960a..7f3b1e1 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -99,22 +99,39 @@ void radeon_ttm_placement_from_domain(struct radeon_bo 
*rbo, u32 domain)

rbo->placement.placement = rbo->placements;
rbo->placement.busy_placement = rbo->placements;
-   if (domain & RADEON_GEM_DOMAIN_VRAM)
+   if (domain & RADEON_GEM_DOMAIN_VRAM) {
+   /* Try placing BOs which don't need CPU access outside of the
+* CPU accessible part of VRAM
+*/
+   if ((rbo->flags & RADEON_GEM_NO_CPU_ACCESS) &&
+   rbo->rdev->mc.visible_vram_size < 
rbo->rdev->mc.real_vram_size) {
+   rbo->placements[c].fpfn =
+   rbo->rdev->mc.visible_vram_size >> PAGE_SHIFT;
+   rbo->placements[c++].flags = TTM_PL_FLAG_WC |
+TTM_PL_FLAG_UNCACHED |
+TTM_PL_FLAG_VRAM;
+   }
+
+   rbo->placements[c].fpfn = 0;
rbo->placements[c++].flags = TTM_PL_FLAG_WC |
 TTM_PL_FLAG_UNCACHED |
 TTM_PL_FLAG_VRAM;
+   }

if (domain & RADEON_GEM_DOMAIN_GTT) {
if (rbo->flags & RADEON_GEM_GTT_UC) {
+   rbo->placements[c].fpfn = 0;
rbo->placements[c++].flags = TTM_PL_FLAG_UNCACHED |
TTM_PL_FLAG_TT;

} else if ((rbo->flags & RADEON_GEM_GTT_WC) ||
   (rbo->rdev->flags & RADEON_IS_AGP)) {
+   rbo->placements[c].fpfn = 0;
rbo->placements[c++].flags = TTM_PL_FLAG_WC |
TTM_PL_FLAG_UNCACHED |
TTM_PL_FLAG_TT;
} else {
+   rbo->placements[c].fpfn = 0;
rbo->placements[c++].flags = TTM_PL_FLAG_CACHED |
 TTM_PL_FLAG_TT;
}
@@ -122,30 +139,35 @@ void radeon_ttm_placement_from_domain(struct radeon_bo 
*rbo, u32 domain)

if (domain & RADEON_GEM_DOMAIN_CPU) {
if (rbo->flags & RADEON_GEM_GTT_UC) {
+   rbo->placements[c].fpfn = 0;
rbo->placements[c++].flags = TTM_PL_FLAG_UNCACHED |
TTM_PL_FLAG_SYSTEM;

} else if ((rbo->flags & RADEON_GEM_GTT_WC) ||
rbo->rdev->flags & RADEON_IS_AGP) {
+   rbo->placements[c].fpfn = 0;
rbo->placements[c++].flags = TTM_PL_FLAG_WC |
TTM_PL_FLAG_UNCACHED |
TTM_PL_FLAG_SYSTEM;
} else {
+   rbo->placements[c].fpfn = 0;
rbo->placements[c++].flags = TTM_PL_FLAG_CACHED |
 TTM_PL_FLAG_SYSTEM;
}
}
-   if (!c)
+   if (!c) {
+   rbo->placements[c].fpfn = 0;
rbo->placements[c++].flags = TTM_PL_MASK_CACHING |
 TTM_PL_FLAG_SYSTEM;
+   }

rbo->placement.num_placement = c;
rbo->placement.num_busy_placement = c;

for (i = 0; i < c; ++i) {
-   rbo->placements[i].fpfn = 0;
if ((rbo->flags & RADEON_GEM_CPU_ACCESS) &&
-   (rbo->placements[i].flags & TTM_PL_FLAG_VRAM))
+   (rbo->placements[i].flags & TTM_PL_FLAG_VRAM) &&
+   !rbo->placements[i].fpfn)
rbo->placements[i].lpfn =
rbo->rdev->mc.visible_vram_size >> PAGE_SHIFT;
else
@@ -743,8 +765,8 @@ int radeon_bo_fault_reserve_notify(struct ttm_buffer_object 
*bo)
 {
struct radeon_device *rdev;
struct radeon_bo *rbo;
-   unsigned long offset, size;
-   int r;
+   unsigned long offset, size, lpfn;
+   int i, r;

if (!radeon_ttm_bo_is_radeon_bo(bo))
return 0;
@@ -761,7 +783,13 @@ int radeon_bo_fault_reserve_notify(struct 
ttm_buffer_object *bo)

/* hurrah the memory is not visible ! */
radeon_ttm_placement_from_domain(rbo, RADEON_GEM_DOMAIN_VRAM);
-   

[PATCH] drm: tegra: Check return value of drm_vblank_get()

[Alexandre Courbot]

drm_vblank_get() can return an error, which we should propagate.

Signed-off-by: Alexandre Courbot 
---
 drivers/gpu/drm/tegra/dc.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 6553fd238685..b08df07cad47 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -699,6 +699,7 @@ static int tegra_dc_page_flip(struct drm_crtc *crtc, struct 
drm_framebuffer *fb,
 {
struct tegra_dc *dc = to_tegra_dc(crtc);
struct drm_device *drm = crtc->dev;
+   int ret;

if (dc->event)
return -EBUSY;
@@ -706,7 +707,9 @@ static int tegra_dc_page_flip(struct drm_crtc *crtc, struct 
drm_framebuffer *fb,
if (event) {
event->pipe = dc->pipe;
dc->event = event;
-   drm_vblank_get(drm, dc->pipe);
+   ret = drm_vblank_get(drm, dc->pipe);
+   if (ret < 0)
+   return ret;
}

tegra_dc_set_base(dc, 0, 0, fb);
-- 
2.1.2

AMD GPU new API for new module

[Daniel Vetter]

On Thu, Oct 9, 2014 at 12:15 PM, Oded Gabbay  wrote:
> Well, I don't expect to reach 100 ioctls anytime soon, but I can tell
> you that for the features we have in the pipeline, I can see the IOCTL
> number go up to 20-30, just for the current H/W generation.

So our Android folks seem to routinely run out of ioctl numbers in
their product/downstream branches. But ime after some decent review of
the new interfaces and not just blindly creating interfaces because
that's easier we have rather slow ioctl number consumption in i915. So
presuming you do decent review and dont fork your driver for every
generation (which seems to be how every blob gfx driver team works) I
don't think you have a problem. Of course that's a massive change in
approach and in my experience with intel-internal discussion will
require a lot of training.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH] drm: sti: remove gpio for HDMI hot plug detection

[Benjamin Gaignard]

We have test with and without gpio and we haven't seen any difference.

To be honest I prefer simplify the bindings which is already complex
and so remove gpio.

But I will in mind your advice if one day I have debounce issues.

Regards,
Benjamin

2014-10-09 14:10 GMT+02:00 Rob Clark :
> On Thu, Oct 9, 2014 at 4:42 AM, Benjamin Gaignard
>  wrote:
>> gpio used for HDMI hot plug detection is useless,
>> HDMI_STI register contains an hot plug detection status bit.
>> Fix binding documentation.
>
> Random thought, but depending on how much you trust your hw designers
> you may want to at least leave the DT entry as optional?  I've started
> out before completely trusting the hdmi block's debounced hpd signal,
> but eventually giving up and using raw gpio, or combination of gpio +
> debounced hdmi signal for reliability..
>
> BR,
> -R
>
>> Signed-off-by: Benjamin Gaignard 
>> ---
>>  Documentation/devicetree/bindings/gpu/st,stih4xx.txt |  2 --
>>  drivers/gpu/drm/sti/sti_hdmi.c   | 11 ++-
>>  drivers/gpu/drm/sti/sti_hdmi.h   |  5 +++--
>>  3 files changed, 5 insertions(+), 13 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/gpu/st,stih4xx.txt 
>> b/Documentation/devicetree/bindings/gpu/st,stih4xx.txt
>> index 8885d9e..32cfc7b 100644
>> --- a/Documentation/devicetree/bindings/gpu/st,stih4xx.txt
>> +++ b/Documentation/devicetree/bindings/gpu/st,stih4xx.txt
>> @@ -68,7 +68,6 @@ STMicroelectronics stih4xx platforms
>>  number of clocks may depend of the SoC type.
>>- clock-names: names of the clocks listed in clocks property in the same
>>  order.
>> -  - hdmi,hpd-gpio: gpio id to detect if an hdmi cable is plugged or not.
>>- ddc: phandle of an I2C controller used for DDC EDID probing
>>
>>  sti-hda:
>> @@ -174,7 +173,6 @@ Example:
>> interrupt-names = "irq";
>> clock-names = "pix", "tmds", "phy", 
>> "audio";
>> clocks  = <_c_vcc 
>> CLK_S_PIX_HDMI>, <_c_vcc CLK_S_TMDS_HDMI>, <_c_vcc 
>> CLK_S_HDMI_REJECT_PLL>, <_b1 CLK_S_PCM_0>;
>> -   hdmi,hpd-gpio   = < 5>;
>> };
>>
>> sti-hda at fe85a000 {
>> diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
>> index 7673189..09f39c5 100644
>> --- a/drivers/gpu/drm/sti/sti_hdmi.c
>> +++ b/drivers/gpu/drm/sti/sti_hdmi.c
>> @@ -130,8 +130,7 @@ static irqreturn_t hdmi_irq_thread(int irq, void *arg)
>>
>> /* Hot plug/unplug IRQ */
>> if (hdmi->irq_status & HDMI_INT_HOT_PLUG) {
>> -   /* read gpio to get the status */
>> -   hdmi->hpd = gpio_get_value(hdmi->hpd_gpio);
>> +   hdmi->hpd = readl(hdmi->regs + HDMI_STA) & HDMI_STA_HOT_PLUG;
>> if (hdmi->drm_dev)
>> drm_helper_hpd_irq_event(hdmi->drm_dev);
>> }
>> @@ -767,13 +766,7 @@ static int sti_hdmi_probe(struct platform_device *pdev)
>> return PTR_ERR(hdmi->clk_audio);
>> }
>>
>> -   hdmi->hpd_gpio = of_get_named_gpio(np, "hdmi,hpd-gpio", 0);
>> -   if (hdmi->hpd_gpio < 0) {
>> -   DRM_ERROR("Failed to get hdmi hpd-gpio\n");
>> -   return -EIO;
>> -   }
>> -
>> -   hdmi->hpd = gpio_get_value(hdmi->hpd_gpio);
>> +   hdmi->hpd = readl(hdmi->regs + HDMI_STA) & HDMI_STA_HOT_PLUG;
>>
>> init_waitqueue_head(>wait_event);
>>
>> diff --git a/drivers/gpu/drm/sti/sti_hdmi.h b/drivers/gpu/drm/sti/sti_hdmi.h
>> index d00a3e0..3d22390 100644
>> --- a/drivers/gpu/drm/sti/sti_hdmi.h
>> +++ b/drivers/gpu/drm/sti/sti_hdmi.h
>> @@ -14,6 +14,9 @@
>>  #define HDMI_STA   0x0010
>>  #define HDMI_STA_DLL_LCK   BIT(5)
>>
>> +#define HDMI_STA_HOT_PLUG_SHIFT 4
>> +#define HDMI_STA_HOT_PLUG  (1 << HDMI_STA_HOT_PLUG_SHIFT)
>> +
>>  struct sti_hdmi;
>>
>>  struct hdmi_phy_ops {
>> @@ -37,7 +40,6 @@ struct hdmi_phy_ops {
>>   * @irq_status: interrupt status register
>>   * @phy_ops: phy start/stop operations
>>   * @enabled: true if hdmi is enabled else false
>> - * @hpd_gpio: hdmi hot plug detect gpio number
>>   * @hpd: hot plug detect status
>>   * @wait_event: wait event
>>   * @event_received: wait event status
>> @@ -57,7 +59,6 @@ struct sti_hdmi {
>> u32 irq_status;
>> struct hdmi_phy_ops *phy_ops;
>> bool enabled;
>> -   int hpd_gpio;
>> bool hpd;
>> wait_queue_head_t wait_event;
>> bool event_received;
>> --
>> 1.9.1
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
Benjamin Gaignard

Graphic Working Group

Linaro.org ? Open source software for ARM SoCs

Follow Linaro: Facebook | Twitter | Blog

[Bug 82711] After update to kernel soft lockup (oops) and incomplete boot and shutdown fail

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

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

--- Comment #12 from Mike Cloaked  ---
The only way I can get the laptop to behave sensibly on shutdown is to
blacklist the nouveau module at boot using modprobe.blacklist=nouveau on the
kernel line, or to add to the file /etc/modprobe.d/blacklist.conf a single line
with "install nouveau /bin/false".

Presumably this indicates there is a bug in the nouveau module for my graphics
card and if there is a way to get some diagnostics to help pin this down so
that a code fix can be found then please let me know what to do to generate
suitable log files?

The graphics cards on this machine are:
00:02.0 VGA compatible controller: Intel Corporation 4th Gen Core Processor
Integrated Graphics Controller (rev 06)
01:00.0 VGA compatible controller: NVIDIA Corporation GK107M [GeForce GT 750M]
(rev a1)

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

[Bug 79980] Random radeonsi crashes

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

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

--- Comment #150 from darkbasic  ---
3.14 is stable with my HD 7950 but some users reported they are stable only
with 3.13 (I don't remember their card)

-- 
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/20141009/4f57558f/attachment.html>

[PATCH 0/3] drm-exynos-dp/phy-exynos-dp: Refactor to use pmu-system-controller and dp driver cleanup

[Ajay kumar]

On Thu, Oct 9, 2014 at 3:56 PM, Vivek Gautam  
wrote:
> Ajay,
>
>
> On Thu, Oct 9, 2014 at 3:48 PM, Ajay kumar  wrote:
>> Hi,
>>
>> On Mon, Sep 15, 2014 at 6:43 PM, Vivek Gautam  
>> wrote:
>>> These patches are based on 'for-next' branch of kgene's linux-samsung tree.
>>>
>>> Refactoring the exynos-dp-video phy to use pmu-system-controller handle
>>> and access the register using mfd-syscon and regmap.
>>> Simultaneously, removing the support for older dptx-phy, since it's obsolete
>>> now and noone uses it.
>>>
>>> Vivek Gautam (3):
>>>   phy: exynos-dp-video: Use syscon support to control pmu register
>>>   drm/exynos: dp: Remove support for unused dptx-phy
>>>   arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
>>>
>>>  .../devicetree/bindings/phy/samsung-phy.txt|7 +-
>>>  arch/arm/boot/dts/exynos5250.dtsi  |2 +-
>>>  arch/arm/boot/dts/exynos5420.dtsi  |4 +-
>>>  drivers/gpu/drm/exynos/exynos_dp_core.c|   58 ---
>>>  drivers/gpu/drm/exynos/exynos_dp_core.h|2 -
>>>  drivers/phy/phy-exynos-dp-video.c  |   76 
>>> ++--
>>>  6 files changed, 75 insertions(+), 74 deletions(-)
>>>
>>> --
>>> 1.7.10.4
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe 
>>> linux-samsung-soc" in
>>> the body of a message to majordomo at vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>> I have tested this patchset on exynos5800-peach-pi, and I can see DP
>> display with the above patches.
>
> we expect "Tested-by", if you have tested please give the same.
Tested-by: Ajay Kumar 

Ajay

[PATCH 0/3] drm-exynos-dp/phy-exynos-dp: Refactor to use pmu-system-controller and dp driver cleanup

[Vivek Gautam]

Ajay,


On Thu, Oct 9, 2014 at 3:48 PM, Ajay kumar  wrote:
> Hi,
>
> On Mon, Sep 15, 2014 at 6:43 PM, Vivek Gautam  
> wrote:
>> These patches are based on 'for-next' branch of kgene's linux-samsung tree.
>>
>> Refactoring the exynos-dp-video phy to use pmu-system-controller handle
>> and access the register using mfd-syscon and regmap.
>> Simultaneously, removing the support for older dptx-phy, since it's obsolete
>> now and noone uses it.
>>
>> Vivek Gautam (3):
>>   phy: exynos-dp-video: Use syscon support to control pmu register
>>   drm/exynos: dp: Remove support for unused dptx-phy
>>   arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
>>
>>  .../devicetree/bindings/phy/samsung-phy.txt|7 +-
>>  arch/arm/boot/dts/exynos5250.dtsi  |2 +-
>>  arch/arm/boot/dts/exynos5420.dtsi  |4 +-
>>  drivers/gpu/drm/exynos/exynos_dp_core.c|   58 ---
>>  drivers/gpu/drm/exynos/exynos_dp_core.h|2 -
>>  drivers/phy/phy-exynos-dp-video.c  |   76 
>> ++--
>>  6 files changed, 75 insertions(+), 74 deletions(-)
>>
>> --
>> 1.7.10.4
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
>> in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
> I have tested this patchset on exynos5800-peach-pi, and I can see DP
> display with the above patches.

we expect "Tested-by", if you have tested please give the same.


-- 
Best Regards
Vivek Gautam
Samsung R Institute, Bangalore
India

[Bug 79980] Random radeonsi crashes

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

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

--- Comment #149 from mmstickman at gmail.com ---
Perhaps you should revert to 3.14 LTS until this issue is fixed. I don't have
any issues running 3.14 with my 7950.

-- 
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/20141009/9958d0f0/attachment.html>

[PATCH 0/3] drm-exynos-dp/phy-exynos-dp: Refactor to use pmu-system-controller and dp driver cleanup

[Ajay kumar]

Hi,

On Mon, Sep 15, 2014 at 6:43 PM, Vivek Gautam  
wrote:
> These patches are based on 'for-next' branch of kgene's linux-samsung tree.
>
> Refactoring the exynos-dp-video phy to use pmu-system-controller handle
> and access the register using mfd-syscon and regmap.
> Simultaneously, removing the support for older dptx-phy, since it's obsolete
> now and noone uses it.
>
> Vivek Gautam (3):
>   phy: exynos-dp-video: Use syscon support to control pmu register
>   drm/exynos: dp: Remove support for unused dptx-phy
>   arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
>
>  .../devicetree/bindings/phy/samsung-phy.txt|7 +-
>  arch/arm/boot/dts/exynos5250.dtsi  |2 +-
>  arch/arm/boot/dts/exynos5420.dtsi  |4 +-
>  drivers/gpu/drm/exynos/exynos_dp_core.c|   58 ---
>  drivers/gpu/drm/exynos/exynos_dp_core.h|2 -
>  drivers/phy/phy-exynos-dp-video.c  |   76 
> ++--
>  6 files changed, 75 insertions(+), 74 deletions(-)
>
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

I have tested this patchset on exynos5800-peach-pi, and I can see DP
display with the above patches.

Ajay

[Bug 79980] Random radeonsi crashes

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

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

--- Comment #148 from darkbasic  ---
I just had to book my flight 3 times with HD 7950 because it loves crashing
when I use Chromium (plugins disabled).

-- 
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/20141009/993f137e/attachment.html>

[Bug 79980] Random radeonsi crashes

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

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

--- Comment #147 from mmstickman at gmail.com ---
I'm getting VM Faults within minutes of idling in i3wm now with my 7950 in
3.17. My AMD A4-5000 laptop is unaffected by these bugs, however.

-- 
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/20141009/b791cb35/attachment.html>

r600_dma_ring_test() failed - synchronization problem with write-combining memory

[Alexander Fyodorov]

Hi David,

I'm using 3.10.53-rt56 kernel and encounter a problem in
r600_dma_ring_test() when vram memory is mapped as write-combining:
no matter how long the polling is done, old value (0xCAFEDEAD) is read.

Looking with hardware analyzer at what actually happens in the PCI-E bus,
the memory is accessed with 32-byte loads (8 words at a time). That is,
when the memory is mapped as write-combining, the processor converts
every readl() into a 32-bytes load transaction.

After doing some more experiments, it seems that Radeon has some kind of
cache that keeps the old value (0xCAFEDEAD), and this cache is invalidated
when:
1) Some other VRAM address is accessed, or
2) Processor issues a 4-byte load transaction.

The problem is that as long as the memory is write-combining, all loads
will be converted to be 32-bytes long by the CPU, so the test fails with
timeout. But if I comment out this particular ring test, everything
seems to be working fine (tested with Doom 3).

Is it possible that the situation r600_dma_ring_test() checks for does
not happen in real life, and I should be OK commenting it out?

Or maybe the test is broken and some cache-flushing command must be
written into the ring buffer?

BTW this is an out-of-tree architecture, so bisecting is not possible.

[PATCH] imx-drm: currently only IPUv3 is supported, make it mandatory

[Philipp Zabel]

As long as only IPUv3 is supported in imx-drm, hide the separate
DRM_IMX_IPUV3 option and make DRM_IMX depend on IMX_IPUV3_CORE.

Reported-by: Michael Olbrich 
Signed-off-by: Philipp Zabel 
---
 drivers/staging/imx-drm/Kconfig | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/imx-drm/Kconfig b/drivers/staging/imx-drm/Kconfig
index 82fb758..ab31848 100644
--- a/drivers/staging/imx-drm/Kconfig
+++ b/drivers/staging/imx-drm/Kconfig
@@ -6,6 +6,7 @@ config DRM_IMX
select DRM_GEM_CMA_HELPER
select DRM_KMS_CMA_HELPER
depends on DRM && (ARCH_MXC || ARCH_MULTIPLATFORM)
+   depends on IMX_IPUV3_CORE
help
  enable i.MX graphics support

@@ -40,11 +41,11 @@ config DRM_IMX_LDB
  found on i.MX53 and i.MX6 processors.

 config DRM_IMX_IPUV3
-   tristate "DRM Support for i.MX IPUv3"
+   tristate
depends on DRM_IMX
depends on IMX_IPUV3_CORE
-   help
- Choose this if you have a i.MX5 or i.MX6 processor.
+   default y if DRM_IMX=y
+   default m if DRM_IMX=m

 config DRM_IMX_HDMI
tristate "Freescale i.MX DRM HDMI"
-- 
2.1.0

[PATCH] drm/ttm: Don't skip fpfn check if lpfn is 0 in ttm_bo_mem_compat

[Michel Dänzer]

From: Michel D?nzer 

Signed-off-by: Michel D?nzer 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 407fa2d..d395b0b 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1008,9 +1008,9 @@ static bool ttm_bo_mem_compat(struct ttm_placement 
*placement,

for (i = 0; i < placement->num_placement; i++) {
const struct ttm_place *heap = >placement[i];
-   if (mem->mm_node && heap->lpfn != 0 &&
+   if (mem->mm_node &&
(mem->start < heap->fpfn ||
-mem->start + mem->num_pages > heap->lpfn))
+(heap->lpfn != 0 && (mem->start + mem->num_pages) > 
heap->lpfn)))
continue;

*new_flags = heap->flags;
@@ -1021,9 +1021,9 @@ static bool ttm_bo_mem_compat(struct ttm_placement 
*placement,

for (i = 0; i < placement->num_busy_placement; i++) {
const struct ttm_place *heap = >busy_placement[i];
-   if (mem->mm_node && heap->lpfn != 0 &&
+   if (mem->mm_node &&
(mem->start < heap->fpfn ||
-mem->start + mem->num_pages > heap->lpfn))
+(heap->lpfn != 0 && (mem->start + mem->num_pages) > 
heap->lpfn)))
continue;

*new_flags = heap->flags;
-- 
2.1.1

[PATCH] drm/ttm: Don't evict BOs outside of the requested placement range

[Michel Dänzer]

From: Michel D?nzer 

The radeon driver uses placement range restrictions for several reasons,
in particular to make sure BOs in VRAM can be accessed by the CPU, e.g.
during a page fault.

Without this change, TTM could evict other BOs while trying to satisfy
the requested placement, even if the evicted BOs were outside of the
requested placement range. Doing so didn't free up any space in the
requested placement range, so the (potentially high) eviction cost was
incurred for no benefit.

Nominating for stable because radeon driver changes in 3.17 made this
much more noticeable than before.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84662
Cc: stable at vger.kernel.org
Signed-off-by: Michel D?nzer 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 20 +---
 1 file changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 8f5cec6..407fa2d 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -709,6 +709,7 @@ out:

 static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
uint32_t mem_type,
+   const struct ttm_place *place,
bool interruptible,
bool no_wait_gpu)
 {
@@ -720,8 +721,21 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
spin_lock(>lru_lock);
list_for_each_entry(bo, >lru, lru) {
ret = __ttm_bo_reserve(bo, false, true, false, NULL);
-   if (!ret)
+   if (!ret) {
+   if (place && (place->fpfn || place->lpfn)) {
+   /* Don't evict this BO if it's outside of the
+* requested placement range
+*/
+   if (place->fpfn >= (bo->mem.start + 
bo->mem.size) ||
+   (place->lpfn && place->lpfn <= 
bo->mem.start)) {
+   __ttm_bo_unreserve(bo);
+   ret = -EBUSY;
+   continue;
+   }
+   }
+
break;
+   }
}

if (ret) {
@@ -782,7 +796,7 @@ static int ttm_bo_mem_force_space(struct ttm_buffer_object 
*bo,
return ret;
if (mem->mm_node)
break;
-   ret = ttm_mem_evict_first(bdev, mem_type,
+   ret = ttm_mem_evict_first(bdev, mem_type, place,
  interruptible, no_wait_gpu);
if (unlikely(ret != 0))
return ret;
@@ -1233,7 +1247,7 @@ static int ttm_bo_force_list_clean(struct ttm_bo_device 
*bdev,
spin_lock(>lru_lock);
while (!list_empty(>lru)) {
spin_unlock(>lru_lock);
-   ret = ttm_mem_evict_first(bdev, mem_type, false, false);
+   ret = ttm_mem_evict_first(bdev, mem_type, NULL, false, false);
if (ret) {
if (allow_errors) {
return ret;
-- 
2.1.1

[PATCH] drm/exynos: fix vblank handling during dpms off

[Alexandre Courbot]

On 10/02/2014 08:52 PM, Andrzej Hajda wrote:
> Hi,
>
> +CC possible victims
>
> On 10/02/2014 12:52 PM, Inki Dae wrote:
>> On 2014? 10? 02? 17:58, Joonyoung Shim wrote:
>>> Hi Andrzej,
>>>
>>> On 10/01/2014 05:14 PM, Andrzej Hajda wrote:
 The patch disables vblanks during dpms off only if pagefilp has
 not been finished. It also replaces drm_vblank_off with 
 drm_crtc_vblank_put.
 It fixes issue with page_flip ioctl not being able to acquire vblank 
 counter.
>>> This problem isn't related with pageflip, it just causes from
>>> 7ffd7a68511c710b84db3548a1997fd2625f580a commit (drm: Always reject
>>> drm_vblank_get() after drm_vblank_off()).
>>>
>>> We need to use drm_vblank_on() as a counterpart to drm_vblank_off()
>>> after the commit .
>
> This patch should break also other drivers, it seems at least following
> drms could be affected:
> armada, sti, tegra.

Indeed we (tegra) have just been hit by this. The problem seems to come 
from the fact that we have been using drm_vblank_pre_modeset, 
drm_vblank_post_modeset and drm_vblank_off conjointly. All these 
functions depend on the value of vblank->inmodeset, and 7ffd7a68511 
increases the vblank reference counter only in drm_vblank_off, which can 
result in the acquired reference never being released.

The following seems to fix this for Tegra, by stopping using 
drm_vblank_pre/post_modeset and relying on drm_vblank_off/on instead:

diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index b08df07cad47..3955d81236d0 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -739,7 +739,6 @@ static const struct drm_crtc_funcs tegra_crtc_funcs = {

  static void tegra_crtc_disable(struct drm_crtc *crtc)
  {
-   struct tegra_dc *dc = to_tegra_dc(crtc);
 struct drm_device *drm = crtc->dev;
 struct drm_plane *plane;

@@ -755,7 +754,7 @@ static void tegra_crtc_disable(struct drm_crtc *crtc)
 }
 }

-   drm_vblank_off(drm, dc->pipe);
+   drm_crtc_vblank_off(crtc);
  }

  static bool tegra_crtc_mode_fixup(struct drm_crtc *crtc,
@@ -844,7 +843,7 @@ static int tegra_crtc_mode_set(struct drm_crtc *crtc,
 u32 value;
 int err;

-   drm_vblank_pre_modeset(crtc->dev, dc->pipe);
+   drm_crtc_vblank_off(crtc);

 err = tegra_crtc_setup_clk(crtc, mode);
 if (err) {
@@ -946,7 +945,7 @@ static void tegra_crtc_commit(struct drm_crtc *crtc)
 value = GENERAL_ACT_REQ | WIN_A_ACT_REQ;
 tegra_dc_writel(dc, value, DC_CMD_STATE_CONTROL);

-   drm_vblank_post_modeset(crtc->dev, dc->pipe);
+   drm_crtc_vblank_on(crtc);
  }

  static void tegra_crtc_load_lut(struct drm_crtc *crtc)

Thierry, does this look ok to you?

But there might be another issue, which is that calls to 
drm_vblank_get() will return -EINVAL if invoked between drm_blank_off 
and drm_blank_on. Is this really the desired behavior? Can it at least 
happen? If so, how are drivers supposed to react to this situation?

[PATCH 1/2] drm/radeon: Try placing NO_CPU_ACCESS BOs outside of CPU accessible VRAM

[Christian König]

Am 09.10.2014 um 11:55 schrieb Michel D?nzer:
> From: Michel D?nzer 
>
> This avoids them getting in the way of BOs which might be accessed by
> the CPU. They can still go to the CPU accessible part of VRAM though if
> there's no space outside of it.

That sounds to me like you want to increase the size of 
radeon_bo.placements as well, cause we can now have one more.

Christian.

>
> Signed-off-by: Michel D?nzer 
> ---
>   drivers/gpu/drm/radeon/radeon_object.c | 42 
> --
>   1 file changed, 35 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
> b/drivers/gpu/drm/radeon/radeon_object.c
> index 99a960a..7f3b1e1 100644
> --- a/drivers/gpu/drm/radeon/radeon_object.c
> +++ b/drivers/gpu/drm/radeon/radeon_object.c
> @@ -99,22 +99,39 @@ void radeon_ttm_placement_from_domain(struct radeon_bo 
> *rbo, u32 domain)
>   
>   rbo->placement.placement = rbo->placements;
>   rbo->placement.busy_placement = rbo->placements;
> - if (domain & RADEON_GEM_DOMAIN_VRAM)
> + if (domain & RADEON_GEM_DOMAIN_VRAM) {
> + /* Try placing BOs which don't need CPU access outside of the
> +  * CPU accessible part of VRAM
> +  */
> + if ((rbo->flags & RADEON_GEM_NO_CPU_ACCESS) &&
> + rbo->rdev->mc.visible_vram_size < 
> rbo->rdev->mc.real_vram_size) {
> + rbo->placements[c].fpfn =
> + rbo->rdev->mc.visible_vram_size >> PAGE_SHIFT;
> + rbo->placements[c++].flags = TTM_PL_FLAG_WC |
> +  TTM_PL_FLAG_UNCACHED |
> +  TTM_PL_FLAG_VRAM;
> + }
> +
> + rbo->placements[c].fpfn = 0;
>   rbo->placements[c++].flags = TTM_PL_FLAG_WC |
>TTM_PL_FLAG_UNCACHED |
>TTM_PL_FLAG_VRAM;
> + }
>   
>   if (domain & RADEON_GEM_DOMAIN_GTT) {
>   if (rbo->flags & RADEON_GEM_GTT_UC) {
> + rbo->placements[c].fpfn = 0;
>   rbo->placements[c++].flags = TTM_PL_FLAG_UNCACHED |
>   TTM_PL_FLAG_TT;
>   
>   } else if ((rbo->flags & RADEON_GEM_GTT_WC) ||
>  (rbo->rdev->flags & RADEON_IS_AGP)) {
> + rbo->placements[c].fpfn = 0;
>   rbo->placements[c++].flags = TTM_PL_FLAG_WC |
>   TTM_PL_FLAG_UNCACHED |
>   TTM_PL_FLAG_TT;
>   } else {
> + rbo->placements[c].fpfn = 0;
>   rbo->placements[c++].flags = TTM_PL_FLAG_CACHED |
>TTM_PL_FLAG_TT;
>   }
> @@ -122,30 +139,35 @@ void radeon_ttm_placement_from_domain(struct radeon_bo 
> *rbo, u32 domain)
>   
>   if (domain & RADEON_GEM_DOMAIN_CPU) {
>   if (rbo->flags & RADEON_GEM_GTT_UC) {
> + rbo->placements[c].fpfn = 0;
>   rbo->placements[c++].flags = TTM_PL_FLAG_UNCACHED |
>   TTM_PL_FLAG_SYSTEM;
>   
>   } else if ((rbo->flags & RADEON_GEM_GTT_WC) ||
>   rbo->rdev->flags & RADEON_IS_AGP) {
> + rbo->placements[c].fpfn = 0;
>   rbo->placements[c++].flags = TTM_PL_FLAG_WC |
>   TTM_PL_FLAG_UNCACHED |
>   TTM_PL_FLAG_SYSTEM;
>   } else {
> + rbo->placements[c].fpfn = 0;
>   rbo->placements[c++].flags = TTM_PL_FLAG_CACHED |
>TTM_PL_FLAG_SYSTEM;
>   }
>   }
> - if (!c)
> + if (!c) {
> + rbo->placements[c].fpfn = 0;
>   rbo->placements[c++].flags = TTM_PL_MASK_CACHING |
>TTM_PL_FLAG_SYSTEM;
> + }
>   
>   rbo->placement.num_placement = c;
>   rbo->placement.num_busy_placement = c;
>   
>   for (i = 0; i < c; ++i) {
> - rbo->placements[i].fpfn = 0;
>   if ((rbo->flags & RADEON_GEM_CPU_ACCESS) &&
> - (rbo->placements[i].flags & TTM_PL_FLAG_VRAM))
> + (rbo->placements[i].flags & TTM_PL_FLAG_VRAM) &&
> + !rbo->placements[i].fpfn)
>   rbo->placements[i].lpfn =
>   rbo->rdev->mc.visible_vram_size >> PAGE_SHIFT;
>   else
> @@ -743,8 +765,8 @@ int radeon_bo_fault_reserve_notify(struct 
> ttm_buffer_object *bo)
>   {
>   struct radeon_device *rdev;
>   struct radeon_bo *rbo;
> - unsigned long offset, size;
> - int r;
> + unsigned long offset, size, lpfn;
> + int i, r;
>   
>   if (!radeon_ttm_bo_is_radeon_bo(bo))
>

[Bug 79659] R9 270X lockup with unigine valley since radeonsi: enable ARB_sample_shading

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

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

--- Comment #17 from Alexander Tsoy  ---
(In reply to Andy Furniss from comment #16)

drirc was the first thing I checked. I filed a new bug 84836.

-- 
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/20141009/3f4d867c/attachment.html>

[Bug 84836] New: VERDE lockup with Unigine Valley/Heaven if ARB_sample_shading is enabled

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

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

Bug ID: 84836
   Summary: VERDE lockup with Unigine Valley/Heaven if
ARB_sample_shading is enabled
   Product: Mesa
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: alexander at tsoy.me

Created attachment 107614
  --> https://bugs.freedesktop.org/attachment.cgi?id=107614=edit
dmesg output

Unigine Valley 1.0 and Heaven 4.0 cause VERDE GPU lockup when
ARB_sample_shading is enabled. With kernel 3.14.19 I got immediate lockup.
3.14.20 allows Valley and Heaven to run for up to 1 min. GPU fails to resume
after lockup, screen becomes corrupted and I need to reboot the system.

If I disable ARB_sample_shading (via env variable
MESA_EXTENSION_OVERRIDE=-GL_ARB_sample_shading) then VERDE GPU do not hang at
all (currently valley is running on my system for more than two hours without
lockups).

I also have BONAIRE GPU and it does not hang.


Software versions:

kernel-3.14.20
mesa-10.3.0
llvm-3.5
xf86-video-ati 7.4.0
libdrm-2.4.56

-- 
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/20141009/fe45b6da/attachment-0001.html>

AMD GPU new API for new module

[Oded Gabbay]

On 09/10/14 11:02, Jerome Glisse wrote:
> On Thu, Oct 09, 2014 at 09:54:14AM +0300, Oded Gabbay wrote:
>> Hi Jerome,
>>
>> Do you think your proposed change should also be applied to amdkfd's
>> IOCTLs ?
> 
> It might make sense it really depends on the lifespan you expect for
> amdkfd, do you expect that you will need substential API evolution
> during that timespan or do you foresee that the currently propose API
> is good enough.

Well, I don't expect to reach 100 ioctls anytime soon, but I can tell
you that for the features we have in the pipeline, I can see the IOCTL
number go up to 20-30, just for the current H/W generation.
> 
> The thing i am proposing here is really to address the issue of IOCTL
> needing fixes because new generation of GPU requires new informations
> or do not care about old and now meaningless informations. The radeon
> ioctl sets is a testimony to the fact that we can not predict what kind
> of broken API we expose and have to leave with.
Understood, and its really hard for me to predict now if we would
absolutely need fixing IOCTLS for newer hardware generations. However,
better be safe than sorry.
> 
> My proposal is really about allowing to evolve each ioctl in what i
> believe to be the simplest and cleanest way to do it while still
> preserving backward compatibility ie i expect that old version of
> an ioctl will continue to live in there own functions untouch and
> unlove but still working. While new development can move to updated
> ioctl.
Yeah, and I think this is a very good forward thinking and I would like
to adopt it as well. This is the perfect time to do it as we still don't
have any history to maintain. I will run it by our internal team and
hopefully publish a new set with this fix for you to review :)
> 
> Other solution would be to just keep adding new ioctl but i fear we
> might run out of ioctl number.

> 
> Cheers,
> J?r?me
> 
>>
>>  Oded
>>
>> On 08/10/14 19:00, Jerome Glisse wrote:
>>> Hi,
>>>
>>> So if i do not start the discussion now it might be already too late. Given
>>> plan to converge open source driver and closed source driver to use a single
>>> common kernel driver and that this would be a new kernel driver. This is an
>>> opportunity to fix some of the radeon design issues (at least things that i
>>> would have done differently if only i could get some gas for my DeLorean).
>>>
>>> Among the thing that i will not do is the chunk stuff associated with cs
>>> ioctl. I find it ugly, if my memory serve me well i was trying to be future
>>> proof and allow the cs ioctl to be extended. While this original aim have
>>> been somewhat successfully, i think it was the wrong day to do it.
>>>
>>> My lastest (and what i still believe to be a good idea until proven wrong),
>>> is to change the way we do ioctl and use a little trick. This idea was also
>>> spark by the continuous additions we do to info ioctl which is getting ugly.
>>>
>>> So idea is simple, each ioctl would use some struct like :
>>>
>>> struct radeon_ioctl {
>>> u32 version;
>>> u32 size;
>>> };
>>>
>>> The version field is the key here, think of it as an index into an array of
>>> ioctl dispatch functions. So something like :
>>>
>>> struct radeon_ioctls {
>>> int (*iotcl)[MAX_IOCTL_NUM](void *data, ...);
>>> };
>>>
>>> struct radeon_ioctls rdispatch_ioctls[N];
>>>
>>> And now all ioctl go through this single entry point :
>>>
>>> int radeon_ioctl_stub(int ioctl, void *data, ...)
>>> {
>>> struct radeon_ioctl *rio = data;
>>>
>>> return rdispatch_ioctls[rio->version][ioctl](data, ...);
>>> }
>>>
>>> So this is rough idea but the point is that we can do proper ioctl 
>>> versioning
>>> and have separate functions for each new versions and avoid ioctl cruft, or
>>> at least this is the theory.
>>>
>>> The two things this gave us, is feedback from userspace as we the version 
>>> the
>>> kernel will know which version of userspace it is dealing with. The others 
>>> one
>>> is that it does allow you to introduce a completely new API either for new
>>> generation of hardware or just as an evolution. And small bonus is that it
>>> does allow to slowly phase out API that we consider broken (ioctl per 
>>> ioctl).
>>>
>>> So this is the main design change that i would do. I should probably rought
>>> up something that goes deeper for the cs ioctl.
>>>
>>> Cheers,
>>> J?r?me
>>> ___
>>> dri-devel mailing list
>>> dri-devel at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>>

[Bug 79980] Random radeonsi crashes

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

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

--- Comment #146 from Daniel Kozak  ---
I am able to reproduce, just start VLC with some video and wait. After some
secs or few minutes it happens

-- 
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/20141009/a17383b5/attachment.html>

[Bug 84662] Long pauses with Unreal demo Elemental on R9270X since : Always flush the HDP cache before submitting a CS to the GPU

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

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

--- Comment #33 from Andy Furniss  ---
(In reply to Andy Furniss from comment #29)
> (In reply to Michel D?nzer from comment #27)
> > Created attachment 107544 [details] [review] [review]
> > drm/radeon: Try placing NO_CPU_ACCESS BOs outside of CPU accessible VRAM
> > 
> > Please try current Mesa with no patches except for the two I just attached,
> > plus this kernel patch together with the previous kernel patch.
> 
> With these it's better but still a bad. There are still pauses but they are
> a bit shorter, the start time without intervention is still around 2min.
> Start time on a good is around 1 min (assuming first run or mem caches
> flushed).
> 
> Hud wise - pic to follow the vram req/used match well, but the gtt is still
> different from a good.
> 
> On the upside - Unigine Valley is the best I've ever seen it - way better
> than what I've called as good in the past.

I see the patches are on the list now, so just in case it wasn't expected -

Running patched kernel with unpatched mesa causes signal 7 when running games.

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

[Bug 53971] radeon:Soft reset GPU in StarCraft2 under Wine

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

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

Zhuravlev Uriy  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |CODE_FIX

--- Comment #1 from Zhuravlev Uriy  ---
Fix now.

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

'drop clk/voltage dependency filters for SI' breaks factory-over-clocked Cape Verde

[Michel Dänzer]

Hi Alex,


your kernel commit 186b1b2ba2a0684e3d2d3703427a993a3b35b16d 
('drm/radeon/dpm: drop clk/voltage dependency filters for SI') causes my 
factory-over-clocked Cape Verde card to lock up pretty quickly when 
running e.g. Unigine Valley or the PTS Xonotic benchmark. Everything's 
fine again after reverting that commit and the one which removed 
btc_get_max_clock_from_voltage_dependency_table.


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

[PATCH] drm/exynos: fix vblank handling during dpms off

[Thierry Reding]

On Thu, Oct 09, 2014 at 02:43:02PM +0900, Alexandre Courbot wrote:
> On 10/02/2014 08:52 PM, Andrzej Hajda wrote:
> >Hi,
> >
> >+CC possible victims
> >
> >On 10/02/2014 12:52 PM, Inki Dae wrote:
> >>On 2014? 10? 02? 17:58, Joonyoung Shim wrote:
> >>>Hi Andrzej,
> >>>
> >>>On 10/01/2014 05:14 PM, Andrzej Hajda wrote:
> >>>>The patch disables vblanks during dpms off only if pagefilp has
> >>>>not been finished. It also replaces drm_vblank_off with 
> >>>>drm_crtc_vblank_put.
> >>>>It fixes issue with page_flip ioctl not being able to acquire vblank 
> >>>>counter.
> >>>This problem isn't related with pageflip, it just causes from
> >>>7ffd7a68511c710b84db3548a1997fd2625f580a commit (drm: Always reject
> >>>drm_vblank_get() after drm_vblank_off()).
> >>>
> >>>We need to use drm_vblank_on() as a counterpart to drm_vblank_off()
> >>>after the commit .
> >
> >This patch should break also other drivers, it seems at least following
> >drms could be affected:
> >armada, sti, tegra.
> 
> Indeed we (tegra) have just been hit by this. The problem seems to come from
> the fact that we have been using drm_vblank_pre_modeset,
> drm_vblank_post_modeset and drm_vblank_off conjointly. All these functions
> depend on the value of vblank->inmodeset, and 7ffd7a68511 increases the
> vblank reference counter only in drm_vblank_off, which can result in the
> acquired reference never being released.
> 
> The following seems to fix this for Tegra, by stopping using
> drm_vblank_pre/post_modeset and relying on drm_vblank_off/on instead:
> 
> diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
> index b08df07cad47..3955d81236d0 100644
> --- a/drivers/gpu/drm/tegra/dc.c
> +++ b/drivers/gpu/drm/tegra/dc.c
> @@ -739,7 +739,6 @@ static const struct drm_crtc_funcs tegra_crtc_funcs = {
> 
>  static void tegra_crtc_disable(struct drm_crtc *crtc)
>  {
> -   struct tegra_dc *dc = to_tegra_dc(crtc);
> struct drm_device *drm = crtc->dev;
> struct drm_plane *plane;
> 
> @@ -755,7 +754,7 @@ static void tegra_crtc_disable(struct drm_crtc *crtc)
> }
> }
> 
> -   drm_vblank_off(drm, dc->pipe);
> +   drm_crtc_vblank_off(crtc);
>  }
> 
>  static bool tegra_crtc_mode_fixup(struct drm_crtc *crtc,
> @@ -844,7 +843,7 @@ static int tegra_crtc_mode_set(struct drm_crtc *crtc,
> u32 value;
> int err;
> 
> -   drm_vblank_pre_modeset(crtc->dev, dc->pipe);
> +   drm_crtc_vblank_off(crtc);
> 
> err = tegra_crtc_setup_clk(crtc, mode);
> if (err) {
> @@ -946,7 +945,7 @@ static void tegra_crtc_commit(struct drm_crtc *crtc)
> value = GENERAL_ACT_REQ | WIN_A_ACT_REQ;
> tegra_dc_writel(dc, value, DC_CMD_STATE_CONTROL);
> 
> -   drm_vblank_post_modeset(crtc->dev, dc->pipe);
> +   drm_crtc_vblank_on(crtc);
>  }
> 
>  static void tegra_crtc_load_lut(struct drm_crtc *crtc)
> 
> Thierry, does this look ok to you?

Yes, that looks like almost the same patch that I sent out yesterday.
The difference is that I didn't replace the drm_vblank_pre_modeset()
call with drm_vblank_off() like you did, but rather just dropped the
former.

I /think/ your version is more correct in that regard.

Thierry

> But there might be another issue, which is that calls to drm_vblank_get()
> will return -EINVAL if invoked between drm_blank_off and drm_blank_on. Is
> this really the desired behavior? Can it at least happen? If so, how are
> drivers supposed to react to this situation?

It shouldn't happen. If drm_vblank_off() and drm_vblank_on() are called
around a modeset they should never conflict with drm_vblank_get(), at
least on Tegra, because the modeset and page-flip IOCTLs will be
serialized.

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

[PATCH] video/hdmi: Relicense header under MIT license

[Christian König]

Am 08.10.2014 um 18:45 schrieb Thierry Reding:
> From: Thierry Reding 
>
> OpenBSD wants to reuse this file but needs the license to be more
> permissive.
>
> Acked-by: Alban Bedel 
> Acked-by: Daniel Vetter 
> Signed-off-by: Thierry Reding 

Not sure if it's necessary, but it might be that some of this is based 
on stuff I did for radeon.

Acked-by: Christian K?nig 

> ---
>   include/linux/hdmi.h | 21 ++---
>   1 file changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
> index 11c0182a153b..cbb5790a35cd 100644
> --- a/include/linux/hdmi.h
> +++ b/include/linux/hdmi.h
> @@ -1,9 +1,24 @@
>   /*
>* Copyright (C) 2012 Avionic Design GmbH
>*
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License version 2 as
> - * published by the Free Software Foundation.
> + * 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, sub license,
> + * 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 NON-INFRINGEMENT. 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.
>*/
>   
>   #ifndef __LINUX_HDMI_H_

[PATCH] drm/exynos: fix vblank handling during dpms off

[Thierry Reding]

On Thu, Oct 09, 2014 at 09:52:58AM +0100, Russell King - ARM Linux wrote:
> On Thu, Oct 09, 2014 at 02:43:02PM +0900, Alexandre Courbot wrote:
> > But there might be another issue, which is that calls to  
> > drm_vblank_get() will return -EINVAL if invoked between drm_blank_off  
> > and drm_blank_on. Is this really the desired behavior? Can it at least  
> > happen? If so, how are drivers supposed to react to this situation?
> 
> I've not yet seen the commit which causes this problem, but I hope
> that drm_wait_vblank() isn't affected by this.  In current mainline,
> drm_vblank_get() is used inside drm_wait_vblank(), which is called as
> a result of userspace calling DRM_IOCTL_WAIT_VBLANK.
> 
> So, what is the effect of this change on user applications making use
> of the vblank wait ioctl - and is that change intended?

There's no effect on user applications if the driver behaves properly.
As far as I can tell, every driver that calls drm_vblank_off() but not
drm_vblank_on() will break. You can easily test this by running libdrm
modetest -s ... -v, which instead of toggling between the test pattern
and an all-gray framebuffer will switch to the gray one once and then
hang.

I guess that was probably not intended, but according to the new rules
all these drivers have now become buggy. So before merging this patch I
think we need to fix existing drivers to avoid regressions.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141009/630135f4/attachment.sig>

[PATCH] drm/ttm: Don't skip fpfn check if lpfn is 0 in ttm_bo_mem_compat

[Christian König]

Am 09.10.2014 um 08:03 schrieb Michel D?nzer:
> From: Michel D?nzer 
>
> Signed-off-by: Michel D?nzer 

Reviewed-by: Christian K?nig 

> ---
>   drivers/gpu/drm/ttm/ttm_bo.c | 8 
>   1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 407fa2d..d395b0b 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -1008,9 +1008,9 @@ static bool ttm_bo_mem_compat(struct ttm_placement 
> *placement,
>   
>   for (i = 0; i < placement->num_placement; i++) {
>   const struct ttm_place *heap = >placement[i];
> - if (mem->mm_node && heap->lpfn != 0 &&
> + if (mem->mm_node &&
>   (mem->start < heap->fpfn ||
> -  mem->start + mem->num_pages > heap->lpfn))
> +  (heap->lpfn != 0 && (mem->start + mem->num_pages) > 
> heap->lpfn)))
>   continue;
>   
>   *new_flags = heap->flags;
> @@ -1021,9 +1021,9 @@ static bool ttm_bo_mem_compat(struct ttm_placement 
> *placement,
>   
>   for (i = 0; i < placement->num_busy_placement; i++) {
>   const struct ttm_place *heap = >busy_placement[i];
> - if (mem->mm_node && heap->lpfn != 0 &&
> + if (mem->mm_node &&
>   (mem->start < heap->fpfn ||
> -  mem->start + mem->num_pages > heap->lpfn))
> +  (heap->lpfn != 0 && (mem->start + mem->num_pages) > 
> heap->lpfn)))
>   continue;
>   
>   *new_flags = heap->flags;

[PATCH] drm/ttm: Don't evict BOs outside of the requested placement range

[Christian König]

Am 09.10.2014 um 08:02 schrieb Michel D?nzer:
> From: Michel D?nzer 
>
> The radeon driver uses placement range restrictions for several reasons,
> in particular to make sure BOs in VRAM can be accessed by the CPU, e.g.
> during a page fault.
>
> Without this change, TTM could evict other BOs while trying to satisfy
> the requested placement, even if the evicted BOs were outside of the
> requested placement range. Doing so didn't free up any space in the
> requested placement range, so the (potentially high) eviction cost was
> incurred for no benefit.
>
> Nominating for stable because radeon driver changes in 3.17 made this
> much more noticeable than before.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84662
> Cc: stable at vger.kernel.org
> Signed-off-by: Michel D?nzer 

Reviewed-by: Christian K?nig 

> ---
>   drivers/gpu/drm/ttm/ttm_bo.c | 20 +---
>   1 file changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 8f5cec6..407fa2d 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -709,6 +709,7 @@ out:
>   
>   static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
>   uint32_t mem_type,
> + const struct ttm_place *place,
>   bool interruptible,
>   bool no_wait_gpu)
>   {
> @@ -720,8 +721,21 @@ static int ttm_mem_evict_first(struct ttm_bo_device 
> *bdev,
>   spin_lock(>lru_lock);
>   list_for_each_entry(bo, >lru, lru) {
>   ret = __ttm_bo_reserve(bo, false, true, false, NULL);
> - if (!ret)
> + if (!ret) {
> + if (place && (place->fpfn || place->lpfn)) {
> + /* Don't evict this BO if it's outside of the
> +  * requested placement range
> +  */
> + if (place->fpfn >= (bo->mem.start + 
> bo->mem.size) ||
> + (place->lpfn && place->lpfn <= 
> bo->mem.start)) {
> + __ttm_bo_unreserve(bo);
> + ret = -EBUSY;
> + continue;
> + }
> + }
> +
>   break;
> + }
>   }
>   
>   if (ret) {
> @@ -782,7 +796,7 @@ static int ttm_bo_mem_force_space(struct 
> ttm_buffer_object *bo,
>   return ret;
>   if (mem->mm_node)
>   break;
> - ret = ttm_mem_evict_first(bdev, mem_type,
> + ret = ttm_mem_evict_first(bdev, mem_type, place,
> interruptible, no_wait_gpu);
>   if (unlikely(ret != 0))
>   return ret;
> @@ -1233,7 +1247,7 @@ static int ttm_bo_force_list_clean(struct ttm_bo_device 
> *bdev,
>   spin_lock(>lru_lock);
>   while (!list_empty(>lru)) {
>   spin_unlock(>lru_lock);
> - ret = ttm_mem_evict_first(bdev, mem_type, false, false);
> + ret = ttm_mem_evict_first(bdev, mem_type, NULL, false, false);
>   if (ret) {
>   if (allow_errors) {
>   return ret;

AMD GPU new API for new module

[Christian König]

Am 09.10.2014 um 09:54 schrieb Jerome Glisse:
> On Thu, Oct 09, 2014 at 03:32:26AM -0400, Rob Clark wrote:
>> On Wed, Oct 8, 2014 at 12:00 PM, Jerome Glisse  wrote:
>>> So idea is simple, each ioctl would use some struct like :
>>>
>>> struct radeon_ioctl {
>>>  u32 version;
>>>  u32 size;
>>> };
>>
>> fwiw, drm_ioctl() will do the right thing (zero-pad) for growing
>> ioctls these days..
> It's more about userspace knowing about ioctl XY and having a way
> to override/ask for special version of each ioctl. So if we screw
> ioctl XY, we can add a new version to XY and we can try to work
> around if userspace still request the old version. It is mostly
> about trying to keep the code clean and avoiding things like the
> chunk stuff of the cs ioctl.
>
> For instance if you cs ioctl with the following struct as ioctl
> parameter:
>
> struct drm_radeon_cs_ioctl_version_00 {
> u64  *cs;
> u32  size;
> u32  flags;
> };
>
> And now you have a new generation of hardware or are just adding
> a new feature :
>
> struct drm_radeon_cs_ioctl_version_01 {
> u64  *cs;
> u32  size;
> u32  flags;
> u32  newfeature fields;
> };
>
> Of course you can argue that you could use the size of user space
> paremeter to do this simple example. But with versioning you can
> also move fields around, remove fields, ... basicly it is just more
> flexible with small overhead of having one more indirection but this
> will be lost into the ioctl cost anyway (i highly doubt it would
> turns as a bottleneck).

I think we can live perfectly fine with adding new fields to the end of 
the IOCTL interface structure and if we really find a need to completely 
redesign an IOCTL just use a new IOCTL number. IIRC they are 32bit at 
least so running out of IOCTL numbers is rather unlikely.

Regards,
Christian.

>
> Cheers,
> J?r?me
>
>> BR,
>> -R
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 84835] New: GL_PRIMITIVE_RESTART_FIXED_INDEX uses glPrimitiveRestartIndex value and not fixed value

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

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

Bug ID: 84835
   Summary: GL_PRIMITIVE_RESTART_FIXED_INDEX uses
glPrimitiveRestartIndex value and not fixed value
   Product: Mesa
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: osbios at web.de

When I use glEnable(GL_PRIMITIVE_RESTART_FIXED_INDEX) it uses the value set by
glPrimitiveRestartIndex() and not the max value of the index data type: 
GL_UNSIGNED_BYTE -> 0xFF
GL_UNSIGNED_SHORT -> 0x
GL_UNSIGNED_INT -> 0x

Basicaly it just behaves like glEnable(GL_PRIMITIVE_RESTART)


glxinfo|grep OpenGL

OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD PITCAIRN
OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.4.0-devel
(git-5814185 2014-10-08 trusty-oibaf-ppa)
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 10.4.0-devel (git-5814185 2014-10-08
trusty-oibaf-ppa)
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 10.4.0-devel (git-5814185
2014-10-08 trusty-oibaf-ppa)
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.0
OpenGL ES profile extensions:

uname -a

Linux c01 3.13.0-37-generic #64-Ubuntu SMP Mon Sep 22 21:28:38 UTC 2014 x86_64
x86_64 x86_64 GNU/Linux

-- 
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/20141009/58234f0f/attachment-0001.html>

[PATCH] drm/ttm: Don't evict BOs outside of the requested placement range

[Alan Swanson]

On 2014-10-09 07:02, Michel D?nzer wrote:
> From: Michel D?nzer 
> 
> The radeon driver uses placement range restrictions for several 
> reasons,
> in particular to make sure BOs in VRAM can be accessed by the CPU, e.g.
> during a page fault.
> 
> Without this change, TTM could evict other BOs while trying to satisfy
> the requested placement, even if the evicted BOs were outside of the
> requested placement range. Doing so didn't free up any space in the
> requested placement range, so the (potentially high) eviction cost was
> incurred for no benefit.
> 
> Nominating for stable because radeon driver changes in 3.17 made this
> much more noticeable than before.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84662
> Cc: stable at vger.kernel.org
> Signed-off-by: Michel D?nzer 
> ---
>  drivers/gpu/drm/ttm/ttm_bo.c | 20 +---
>  1 file changed, 17 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c 
> b/drivers/gpu/drm/ttm/ttm_bo.c
> index 8f5cec6..407fa2d 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -709,6 +709,7 @@ out:
> 
>  static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
>   uint32_t mem_type,
> + const struct ttm_place *place,
>   bool interruptible,
>   bool no_wait_gpu)
>  {
> @@ -720,8 +721,21 @@ static int ttm_mem_evict_first(struct 
> ttm_bo_device *bdev,
>   spin_lock(>lru_lock);
>   list_for_each_entry(bo, >lru, lru) {
>   ret = __ttm_bo_reserve(bo, false, true, false, NULL);
> - if (!ret)
> + if (!ret) {
> + if (place && (place->fpfn || place->lpfn)) {
> + /* Don't evict this BO if it's outside of the
> +  * requested placement range
> +  */
> + if (place->fpfn >= (bo->mem.start + 
> bo->mem.size) ||
> + (place->lpfn && place->lpfn <= 
> bo->mem.start)) {
> + __ttm_bo_unreserve(bo);
> + ret = -EBUSY;
> + continue;
> + }
> + }
> +
>   break;
> + }
>   }
> 
>   if (ret) {
> @@ -782,7 +796,7 @@ static int ttm_bo_mem_force_space(struct
> ttm_buffer_object *bo,
>   return ret;
>   if (mem->mm_node)
>   break;
> - ret = ttm_mem_evict_first(bdev, mem_type,
> + ret = ttm_mem_evict_first(bdev, mem_type, place,
> interruptible, no_wait_gpu);
>   if (unlikely(ret != 0))
>   return ret;
> @@ -1233,7 +1247,7 @@ static int ttm_bo_force_list_clean(struct
> ttm_bo_device *bdev,
>   spin_lock(>lru_lock);
>   while (!list_empty(>lru)) {
>   spin_unlock(>lru_lock);
> - ret = ttm_mem_evict_first(bdev, mem_type, false, false);
> + ret = ttm_mem_evict_first(bdev, mem_type, NULL, false, false);
>   if (ret) {
>   if (allow_errors) {
>   return ret;

I believe you need to "s/place/placement/" over this patch.

-- 
Alan.

AMD GPU new API for new module

[Daniel Vetter]

On Wed, Oct 8, 2014 at 6:00 PM, Jerome Glisse  wrote:
>
> struct radeon_ioctl {
> u32 version;
> u32 size;
> };

How is this any different from just another ioctl multiplexer and why
can't we just add a new version if an ioctl needs to be revised? E.g.
in i915 we've just added execbuf2 and within execbuf2 there's tons of
flags to enable/disable code. I don't see what a version field buys us
on top of having flags fields and just creating a new ioctl if that
gets too fuzzy. In the end you still have to keep all the old crap
working, and imo that's easier to do long-term if you don't make it
too easy to add new interfaces.

Also, the size is encoded in the ioctl itself and like Rob said the
core takes care of properly zero-filling this.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH] drm: sti: allow to change hdmi ddc i2c adapter

[Benjamin Gaignard]

Depending of the board configuration i2c for ddc could change,
this patch allow to use a phandle to specify which i2c controller to use.

Signed-off-by: Benjamin Gaignard 
---
 .../devicetree/bindings/gpu/st,stih4xx.txt |  1 +
 drivers/gpu/drm/sti/sti_hdmi.c | 40 +++---
 drivers/gpu/drm/sti/sti_hdmi.h |  1 +
 3 files changed, 29 insertions(+), 13 deletions(-)

diff --git a/Documentation/devicetree/bindings/gpu/st,stih4xx.txt 
b/Documentation/devicetree/bindings/gpu/st,stih4xx.txt
index 2d150c3..8885d9e 100644
--- a/Documentation/devicetree/bindings/gpu/st,stih4xx.txt
+++ b/Documentation/devicetree/bindings/gpu/st,stih4xx.txt
@@ -69,6 +69,7 @@ STMicroelectronics stih4xx platforms
   - clock-names: names of the clocks listed in clocks property in the same
 order.
   - hdmi,hpd-gpio: gpio id to detect if an hdmi cable is plugged or not.
+  - ddc: phandle of an I2C controller used for DDC EDID probing

 sti-hda:
   Required properties:
diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
index ef93156..7673189 100644
--- a/drivers/gpu/drm/sti/sti_hdmi.c
+++ b/drivers/gpu/drm/sti/sti_hdmi.c
@@ -481,17 +481,15 @@ static const struct drm_bridge_funcs 
sti_hdmi_bridge_funcs = {

 static int sti_hdmi_connector_get_modes(struct drm_connector *connector)
 {
-   struct i2c_adapter *i2c_adap;
+   struct sti_hdmi_connector *hdmi_connector
+   = to_sti_hdmi_connector(connector);
+   struct sti_hdmi *hdmi = hdmi_connector->hdmi;
struct edid *edid;
int count;

DRM_DEBUG_DRIVER("\n");

-   i2c_adap = i2c_get_adapter(1);
-   if (!i2c_adap)
-   goto fail;
-
-   edid = drm_get_edid(connector, i2c_adap);
+   edid = drm_get_edid(connector, hdmi->ddc_adapt);
if (!edid)
goto fail;

@@ -604,29 +602,38 @@ static int sti_hdmi_bind(struct device *dev, struct 
device *master, void *data)
struct sti_hdmi_connector *connector;
struct drm_connector *drm_connector;
struct drm_bridge *bridge;
-   struct i2c_adapter *i2c_adap;
+   struct device_node *ddc;
int err;

-   i2c_adap = i2c_get_adapter(1);
-   if (!i2c_adap)
-   return -EPROBE_DEFER;
+   ddc = of_parse_phandle(dev->of_node, "ddc", 0);
+   if (ddc) {
+   hdmi->ddc_adapt = of_find_i2c_adapter_by_node(ddc);
+   if (!hdmi->ddc_adapt) {
+   err = -EPROBE_DEFER;
+   of_node_put(ddc);
+   return err;
+   }
+
+   of_node_put(ddc);
+   }

/* Set the drm device handle */
hdmi->drm_dev = drm_dev;

encoder = sti_hdmi_find_encoder(drm_dev);
if (!encoder)
-   return -ENOMEM;
+   goto err_adapt;

connector = devm_kzalloc(dev, sizeof(*connector), GFP_KERNEL);
if (!connector)
-   return -ENOMEM;
+   goto err_adapt;
+

connector->hdmi = hdmi;

bridge = devm_kzalloc(dev, sizeof(*bridge), GFP_KERNEL);
if (!bridge)
-   return -ENOMEM;
+   goto err_adapt;

bridge->driver_private = hdmi;
drm_bridge_init(drm_dev, bridge, _hdmi_bridge_funcs);
@@ -663,6 +670,8 @@ err_sysfs:
 err_connector:
drm_bridge_cleanup(bridge);
drm_connector_cleanup(drm_connector);
+err_adapt:
+   put_device(>ddc_adapt->dev);
return -EINVAL;
 }

@@ -789,6 +798,11 @@ static int sti_hdmi_probe(struct platform_device *pdev)

 static int sti_hdmi_remove(struct platform_device *pdev)
 {
+   struct sti_hdmi *hdmi = dev_get_drvdata(>dev);
+
+   if (hdmi->ddc_adapt)
+   put_device(>ddc_adapt->dev);
+
component_del(>dev, _hdmi_ops);
return 0;
 }
diff --git a/drivers/gpu/drm/sti/sti_hdmi.h b/drivers/gpu/drm/sti/sti_hdmi.h
index 61bec65..d00a3e0 100644
--- a/drivers/gpu/drm/sti/sti_hdmi.h
+++ b/drivers/gpu/drm/sti/sti_hdmi.h
@@ -62,6 +62,7 @@ struct sti_hdmi {
wait_queue_head_t wait_event;
bool event_received;
struct reset_control *reset;
+   struct i2c_adapter *ddc_adapt;
 };

 u32 hdmi_read(struct sti_hdmi *hdmi, int offset);
-- 
1.9.1

[PATCH] drm: sti: remove gpio for HDMI hot plug detection

[Benjamin Gaignard]

gpio used for HDMI hot plug detection is useless,
HDMI_STI register contains an hot plug detection status bit.
Fix binding documentation.

Signed-off-by: Benjamin Gaignard 
---
 Documentation/devicetree/bindings/gpu/st,stih4xx.txt |  2 --
 drivers/gpu/drm/sti/sti_hdmi.c   | 11 ++-
 drivers/gpu/drm/sti/sti_hdmi.h   |  5 +++--
 3 files changed, 5 insertions(+), 13 deletions(-)

diff --git a/Documentation/devicetree/bindings/gpu/st,stih4xx.txt 
b/Documentation/devicetree/bindings/gpu/st,stih4xx.txt
index 8885d9e..32cfc7b 100644
--- a/Documentation/devicetree/bindings/gpu/st,stih4xx.txt
+++ b/Documentation/devicetree/bindings/gpu/st,stih4xx.txt
@@ -68,7 +68,6 @@ STMicroelectronics stih4xx platforms
 number of clocks may depend of the SoC type.
   - clock-names: names of the clocks listed in clocks property in the same
 order.
-  - hdmi,hpd-gpio: gpio id to detect if an hdmi cable is plugged or not.
   - ddc: phandle of an I2C controller used for DDC EDID probing

 sti-hda:
@@ -174,7 +173,6 @@ Example:
interrupt-names = "irq";
clock-names = "pix", "tmds", "phy", "audio";
clocks  = <_c_vcc 
CLK_S_PIX_HDMI>, <_c_vcc CLK_S_TMDS_HDMI>, <_c_vcc 
CLK_S_HDMI_REJECT_PLL>, <_b1 CLK_S_PCM_0>;
-   hdmi,hpd-gpio   = < 5>;
};

sti-hda at fe85a000 {
diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
index 7673189..09f39c5 100644
--- a/drivers/gpu/drm/sti/sti_hdmi.c
+++ b/drivers/gpu/drm/sti/sti_hdmi.c
@@ -130,8 +130,7 @@ static irqreturn_t hdmi_irq_thread(int irq, void *arg)

/* Hot plug/unplug IRQ */
if (hdmi->irq_status & HDMI_INT_HOT_PLUG) {
-   /* read gpio to get the status */
-   hdmi->hpd = gpio_get_value(hdmi->hpd_gpio);
+   hdmi->hpd = readl(hdmi->regs + HDMI_STA) & HDMI_STA_HOT_PLUG;
if (hdmi->drm_dev)
drm_helper_hpd_irq_event(hdmi->drm_dev);
}
@@ -767,13 +766,7 @@ static int sti_hdmi_probe(struct platform_device *pdev)
return PTR_ERR(hdmi->clk_audio);
}

-   hdmi->hpd_gpio = of_get_named_gpio(np, "hdmi,hpd-gpio", 0);
-   if (hdmi->hpd_gpio < 0) {
-   DRM_ERROR("Failed to get hdmi hpd-gpio\n");
-   return -EIO;
-   }
-
-   hdmi->hpd = gpio_get_value(hdmi->hpd_gpio);
+   hdmi->hpd = readl(hdmi->regs + HDMI_STA) & HDMI_STA_HOT_PLUG;

init_waitqueue_head(>wait_event);

diff --git a/drivers/gpu/drm/sti/sti_hdmi.h b/drivers/gpu/drm/sti/sti_hdmi.h
index d00a3e0..3d22390 100644
--- a/drivers/gpu/drm/sti/sti_hdmi.h
+++ b/drivers/gpu/drm/sti/sti_hdmi.h
@@ -14,6 +14,9 @@
 #define HDMI_STA   0x0010
 #define HDMI_STA_DLL_LCK   BIT(5)

+#define HDMI_STA_HOT_PLUG_SHIFT 4
+#define HDMI_STA_HOT_PLUG  (1 << HDMI_STA_HOT_PLUG_SHIFT)
+
 struct sti_hdmi;

 struct hdmi_phy_ops {
@@ -37,7 +40,6 @@ struct hdmi_phy_ops {
  * @irq_status: interrupt status register
  * @phy_ops: phy start/stop operations
  * @enabled: true if hdmi is enabled else false
- * @hpd_gpio: hdmi hot plug detect gpio number
  * @hpd: hot plug detect status
  * @wait_event: wait event
  * @event_received: wait event status
@@ -57,7 +59,6 @@ struct sti_hdmi {
u32 irq_status;
struct hdmi_phy_ops *phy_ops;
bool enabled;
-   int hpd_gpio;
bool hpd;
wait_queue_head_t wait_event;
bool event_received;
-- 
1.9.1

[PATCH] drm: sti: use drm_crtc_vblank_{on/off} instead of drm_vblank_{on/off}

[Benjamin Gaignard]

Make sure that vblank is enabled when crtc commit is call.
Replace drm_vblank_off() by drm_crtc_vblank_off()

Signed-off-by: Benjamin Gaignard 
---
 drivers/gpu/drm/sti/sti_drm_crtc.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sti/sti_drm_crtc.c 
b/drivers/gpu/drm/sti/sti_drm_crtc.c
index d2ae0c0..38c4799 100644
--- a/drivers/gpu/drm/sti/sti_drm_crtc.c
+++ b/drivers/gpu/drm/sti/sti_drm_crtc.c
@@ -61,6 +61,8 @@ static void sti_drm_crtc_commit(struct drm_crtc *crtc)
/* Enable layer on mixer */
if (sti_mixer_set_layer_status(mixer, layer, true))
DRM_ERROR("Can not enable layer at mixer\n");
+
+   drm_crtc_vblank_on(crtc);
 }

 static bool sti_drm_crtc_mode_fixup(struct drm_crtc *crtc,
@@ -221,7 +223,7 @@ static void sti_drm_crtc_disable(struct drm_crtc *crtc)
/* Then disable layer itself */
sti_layer_disable(layer);

-   drm_vblank_off(crtc->dev, mixer->id);
+   drm_crtc_vblank_off(crtc);

/* Disable pixel clock and compo IP clocks */
if (mixer->id == STI_MIXER_MAIN) {
-- 
1.9.1

AMD GPU new API for new module

[Oded Gabbay]

Hi Jerome,

Do you think your proposed change should also be applied to amdkfd's
IOCTLs ?

Oded

On 08/10/14 19:00, Jerome Glisse wrote:
> Hi,
> 
> So if i do not start the discussion now it might be already too late. Given
> plan to converge open source driver and closed source driver to use a single
> common kernel driver and that this would be a new kernel driver. This is an
> opportunity to fix some of the radeon design issues (at least things that i
> would have done differently if only i could get some gas for my DeLorean).
> 
> Among the thing that i will not do is the chunk stuff associated with cs
> ioctl. I find it ugly, if my memory serve me well i was trying to be future
> proof and allow the cs ioctl to be extended. While this original aim have
> been somewhat successfully, i think it was the wrong day to do it.
> 
> My lastest (and what i still believe to be a good idea until proven wrong),
> is to change the way we do ioctl and use a little trick. This idea was also
> spark by the continuous additions we do to info ioctl which is getting ugly.
> 
> So idea is simple, each ioctl would use some struct like :
> 
> struct radeon_ioctl {
>   u32 version;
>   u32 size;
> };
> 
> The version field is the key here, think of it as an index into an array of
> ioctl dispatch functions. So something like :
> 
> struct radeon_ioctls {
>   int (*iotcl)[MAX_IOCTL_NUM](void *data, ...);
> };
> 
> struct radeon_ioctls rdispatch_ioctls[N];
> 
> And now all ioctl go through this single entry point :
> 
> int radeon_ioctl_stub(int ioctl, void *data, ...)
> {
>   struct radeon_ioctl *rio = data;
> 
>   return rdispatch_ioctls[rio->version][ioctl](data, ...);
> }
> 
> So this is rough idea but the point is that we can do proper ioctl versioning
> and have separate functions for each new versions and avoid ioctl cruft, or
> at least this is the theory.
> 
> The two things this gave us, is feedback from userspace as we the version the
> kernel will know which version of userspace it is dealing with. The others one
> is that it does allow you to introduce a completely new API either for new
> generation of hardware or just as an evolution. And small bonus is that it
> does allow to slowly phase out API that we consider broken (ioctl per ioctl).
> 
> So this is the main design change that i would do. I should probably rought
> up something that goes deeper for the cs ioctl.
> 
> Cheers,
> J?r?me
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> 

[PATCH] drm/exynos: fix vblank handling during dpms off

[Russell King - ARM Linux]

On Thu, Oct 09, 2014 at 02:43:02PM +0900, Alexandre Courbot wrote:
> But there might be another issue, which is that calls to  
> drm_vblank_get() will return -EINVAL if invoked between drm_blank_off  
> and drm_blank_on. Is this really the desired behavior? Can it at least  
> happen? If so, how are drivers supposed to react to this situation?

I've not yet seen the commit which causes this problem, but I hope
that drm_wait_vblank() isn't affected by this.  In current mainline,
drm_vblank_get() is used inside drm_wait_vblank(), which is called as
a result of userspace calling DRM_IOCTL_WAIT_VBLANK.

So, what is the effect of this change on user applications making use
of the vblank wait ioctl - and is that change intended?

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

[PATCH] video/hdmi: Relicense header under MIT license

[Daniel Vetter]

On Wed, Oct 08, 2014 at 06:45:01PM +0200, Thierry Reding wrote:
> From: Thierry Reding 
>
> OpenBSD wants to reuse this file but needs the license to be more
> permissive.
>
> Acked-by: Alban Bedel 
> Acked-by: Daniel Vetter 
Also Acked-by: Daniel Vetter  for the entire
Intel team.
-Daniel

> Signed-off-by: Thierry Reding 
> ---
>  include/linux/hdmi.h | 21 ++---
>  1 file changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
> index 11c0182a153b..cbb5790a35cd 100644
> --- a/include/linux/hdmi.h
> +++ b/include/linux/hdmi.h
> @@ -1,9 +1,24 @@
>  /*
>   * Copyright (C) 2012 Avionic Design GmbH
>   *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License version 2 as
> - * published by the Free Software Foundation.
> + * 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, sub license,
> + * 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 NON-INFRINGEMENT. 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.
>   */
>
>  #ifndef __LINUX_HDMI_H_
> --
> 2.1.0
>

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

[PATCH 02/10] drm/i915: Add counters in the drm_dp_aux struct for I2C NACKs and DEFERs

[Todd Previte]

These counters are used for Displayort complinace testing to detect error 
conditions
when executing certain compliance tests. Currently these are used in the EDID 
tests
to determine if the video mode needs to be set to the preferred mode or the 
failsafe
mode.

Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Todd Previte 
---
 drivers/gpu/drm/drm_dp_helper.c | 2 ++
 include/drm/drm_dp_helper.h | 1 +
 2 files changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 08e33b8..8353051 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -654,10 +654,12 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, 
struct drm_dp_aux_msg *msg)

case DP_AUX_I2C_REPLY_NACK:
DRM_DEBUG_KMS("I2C nack\n");
+   aux->i2c_nack_count++;
return -EREMOTEIO;

case DP_AUX_I2C_REPLY_DEFER:
DRM_DEBUG_KMS("I2C defer\n");
+   aux->i2c_defer_count++;
usleep_range(400, 500);
continue;

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 8edeed0..45f3ee8 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -551,6 +551,7 @@ struct drm_dp_aux {
struct mutex hw_mutex;
ssize_t (*transfer)(struct drm_dp_aux *aux,
struct drm_dp_aux_msg *msg);
+   uint8_t i2c_nack_count, i2c_defer_count;
 };

 ssize_t drm_dp_dpcd_read(struct drm_dp_aux *aux, unsigned int offset,
-- 
1.9.1

[PATCH 02/10] drm/i915: Add counters in the drm_dp_aux struct for I2C NACKs and DEFERs

[Todd Previte]

Sorry for the spam - Ignore the duplicates. There will be one more coming
when I post this series to intel-gfx.

-T

-Original Message-
From: Todd Previte [mailto:tprev...@gmail.com] 
Sent: Thursday, October 09, 2014 8:33 AM
To: tprevite at gmail.com
Cc: dri-devel at lists.freedesktop.org
Subject: [PATCH 02/10] drm/i915: Add counters in the drm_dp_aux struct for
I2C NACKs and DEFERs

These counters are used for Displayort complinace testing to detect error
conditions when executing certain compliance tests. Currently these are used
in the EDID tests to determine if the video mode needs to be set to the
preferred mode or the failsafe mode.

Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Todd Previte 
---
 drivers/gpu/drm/drm_dp_helper.c | 2 ++
 include/drm/drm_dp_helper.h | 1 +
 2 files changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c
b/drivers/gpu/drm/drm_dp_helper.c index 08e33b8..8353051 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -654,10 +654,12 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux,
struct drm_dp_aux_msg *msg)

case DP_AUX_I2C_REPLY_NACK:
DRM_DEBUG_KMS("I2C nack\n");
+   aux->i2c_nack_count++;
return -EREMOTEIO;

case DP_AUX_I2C_REPLY_DEFER:
DRM_DEBUG_KMS("I2C defer\n");
+   aux->i2c_defer_count++;
usleep_range(400, 500);
continue;

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index
8edeed0..45f3ee8 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -551,6 +551,7 @@ struct drm_dp_aux {
struct mutex hw_mutex;
ssize_t (*transfer)(struct drm_dp_aux *aux,
struct drm_dp_aux_msg *msg);
+   uint8_t i2c_nack_count, i2c_defer_count;
 };

 ssize_t drm_dp_dpcd_read(struct drm_dp_aux *aux, unsigned int offset,
--
1.9.1

[Bug 79659] R9 270X lockup with unigine valley since radeonsi: enable ARB_sample_shading

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

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

--- Comment #16 from Andy Furniss  ---
(In reply to Alexander Tsoy from comment #15)
> Ah.. "st/mesa,gallium: add a workaround for Unigine Heaven 4.0 and Valley
> 1.0" is also included in mesa-10.3. So both Heaven 4.0 and Valley 1.0 should
> just work. The question is why ARB_sample_shading is causing GPU lockup on
> VERDE. Should I open a separate bug for this issue?

Maybe check that the your /etc/drirc has the workaround and/or if you have a
.drirc in your home dir that it has it also, though I haven't tested if having
a .drirc under $HOME without the workaround overrides one in /etc with it.

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

[PATCH 02/10] drm/i915: Add counters in the drm_dp_aux struct for I2C NACKs and DEFERs

[Todd Previte]

These counters are used for Displayort complinace testing to detect error 
conditions
when executing certain compliance tests. Currently these are used in the EDID 
tests
to determine if the video mode needs to be set to the preferred mode or the 
failsafe
mode.

Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Todd Previte 
---
 drivers/gpu/drm/drm_dp_helper.c | 2 ++
 include/drm/drm_dp_helper.h | 1 +
 2 files changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 08e33b8..8353051 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -654,10 +654,12 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, 
struct drm_dp_aux_msg *msg)

case DP_AUX_I2C_REPLY_NACK:
DRM_DEBUG_KMS("I2C nack\n");
+   aux->i2c_nack_count++;
return -EREMOTEIO;

case DP_AUX_I2C_REPLY_DEFER:
DRM_DEBUG_KMS("I2C defer\n");
+   aux->i2c_defer_count++;
usleep_range(400, 500);
continue;

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 8edeed0..45f3ee8 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -551,6 +551,7 @@ struct drm_dp_aux {
struct mutex hw_mutex;
ssize_t (*transfer)(struct drm_dp_aux *aux,
struct drm_dp_aux_msg *msg);
+   uint8_t i2c_nack_count, i2c_defer_count;
 };

 ssize_t drm_dp_dpcd_read(struct drm_dp_aux *aux, unsigned int offset,
-- 
1.9.1

[PATCH 02/10] drm/i915: Add counters in the drm_dp_aux struct for I2C NACKs and DEFERs

[Todd Previte]

These counters are used for Displayort complinace testing to detect error 
conditions
when executing certain compliance tests. Currently these are used in the EDID 
tests
to determine if the video mode needs to be set to the preferred mode or the 
failsafe
mode.

Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Todd Previte 
---
 drivers/gpu/drm/drm_dp_helper.c | 2 ++
 include/drm/drm_dp_helper.h | 1 +
 2 files changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 08e33b8..8353051 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -654,10 +654,12 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, 
struct drm_dp_aux_msg *msg)

case DP_AUX_I2C_REPLY_NACK:
DRM_DEBUG_KMS("I2C nack\n");
+   aux->i2c_nack_count++;
return -EREMOTEIO;

case DP_AUX_I2C_REPLY_DEFER:
DRM_DEBUG_KMS("I2C defer\n");
+   aux->i2c_defer_count++;
usleep_range(400, 500);
continue;

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 8edeed0..45f3ee8 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -551,6 +551,7 @@ struct drm_dp_aux {
struct mutex hw_mutex;
ssize_t (*transfer)(struct drm_dp_aux *aux,
struct drm_dp_aux_msg *msg);
+   uint8_t i2c_nack_count, i2c_defer_count;
 };

 ssize_t drm_dp_dpcd_read(struct drm_dp_aux *aux, unsigned int offset,
-- 
1.9.1

[Bug 84232] PHINode containing itself causes segfault in LLVM when compiling Blender OpenCL kernel with R600 backend

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

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

--- Comment #6 from Vitaliy Filippov  ---
Hm, I've tried to reproduce your testcase and got another bug:

int main()
{
  int i;
  for (i = 0; i < 100; i++)
  {
if (!(i%10))
{
  i = i%50;
  if (i%2 == 0)
break;
}
  }
  return i;
}

clang-3.5 -S -emit-llvm test.c
llc-3.5 -march=r600 -mcpu=oland test.ll 

>>>>

Program received signal SIGSEGV, Segmentation fault.
llvm::BasicBlock::getTerminator (this=0x471f08) at
/var/home/vitali/setup/llvm/llvm-toolchain-3.5-3.5/lib/IR/BasicBlock.cpp:126
126   return dyn_cast(());
(gdb) bt
#0  llvm::BasicBlock::getTerminator (this=0x471f08) at
/var/home/vitali/setup/llvm/llvm-toolchain-3.5-3.5/lib/IR/BasicBlock.cpp:126
#1  0x77442c9a in (anonymous
namespace)::SIAnnotateControlFlow::handleLoopCondition
(this=this at entry=0x44c960, Cond=0x471eb0, Broken=Broken at entry=
0x486a50) at
/var/home/vitali/setup/llvm/llvm-toolchain-3.5-3.5/lib/Target/R600/SIAnnotateControlFlow.cpp:271
#2  0x77443d6c in handleLoop (Term=0x486af8, this=0x44c960)
at
/var/home/vitali/setup/llvm/llvm-toolchain-3.5-3.5/lib/Target/R600/SIAnnotateControlFlow.cpp:288
#3  (anonymous namespace)::SIAnnotateControlFlow::runOnFunction (this=0x44c960,
F=...)
at
/var/home/vitali/setup/llvm/llvm-toolchain-3.5-3.5/lib/Target/R600/SIAnnotateControlFlow.cpp:325
#4  0x7662a3d7 in llvm::FPPassManager::runOnFunction (this=0x43e930,
F=...)
at
/var/home/vitali/setup/llvm/llvm-toolchain-3.5-3.5/lib/IR/LegacyPassManager.cpp:1545
#5  0x7662a45b in llvm::FPPassManager::runOnModule (this=0x43e930,
M=...)
at
/var/home/vitali/setup/llvm/llvm-toolchain-3.5-3.5/lib/IR/LegacyPassManager.cpp:1565
#6  0x7662ce19 in runOnModule (M=..., this=0x431140) at
/var/home/vitali/setup/llvm/llvm-toolchain-3.5-3.5/lib/IR/LegacyPassManager.cpp:1623
#7  llvm::legacy::PassManagerImpl::run (this=0x430e50, M=...) at
/var/home/vitali/setup/llvm/llvm-toolchain-3.5-3.5/lib/IR/LegacyPassManager.cpp:1730
#8  0x00411a11 in ?? ()
#9  0x0040cd98 in main ()

-- 
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/20141009/3adf3ebf/attachment.html>

AMD GPU new API for new module

[Rob Clark]

On Thu, Oct 9, 2014 at 3:54 AM, Jerome Glisse  wrote:
> On Thu, Oct 09, 2014 at 03:32:26AM -0400, Rob Clark wrote:
>> On Wed, Oct 8, 2014 at 12:00 PM, Jerome Glisse  wrote:
>> >
>> > So idea is simple, each ioctl would use some struct like :
>> >
>> > struct radeon_ioctl {
>> > u32 version;
>> > u32 size;
>> > };
>>
>>
>> fwiw, drm_ioctl() will do the right thing (zero-pad) for growing
>> ioctls these days..
>
> It's more about userspace knowing about ioctl XY and having a way
> to override/ask for special version of each ioctl. So if we screw
> ioctl XY, we can add a new version to XY and we can try to work
> around if userspace still request the old version. It is mostly
> about trying to keep the code clean and avoiding things like the
> chunk stuff of the cs ioctl.
>
> For instance if you cs ioctl with the following struct as ioctl
> parameter:
>
> struct drm_radeon_cs_ioctl_version_00 {
>u64  *cs;
>u32  size;
>u32  flags;
> };
>
> And now you have a new generation of hardware or are just adding
> a new feature :
>
> struct drm_radeon_cs_ioctl_version_01 {
>u64  *cs;
>u32  size;
>u32  flags;
>u32  newfeature fields;
> };
>
> Of course you can argue that you could use the size of user space
> paremeter to do this simple example. But with versioning you can
> also move fields around, remove fields, ... basicly it is just more
> flexible with small overhead of having one more indirection but this
> will be lost into the ioctl cost anyway (i highly doubt it would
> turns as a bottleneck).

sure, explicit version is more flexible (and I don't even think you
need an extra layer of indirection for that)..  just pointing out that
we do have a way to grow ioctls now (with the constraint that zero's
is a sane backwards compat value for the new field(s))

BR,
-R


>
> Cheers,
> J?r?me
>
>>
>> BR,
>> -R

[PATCH] drm: sti: remove gpio for HDMI hot plug detection

[Rob Clark]

On Thu, Oct 9, 2014 at 4:42 AM, Benjamin Gaignard
 wrote:
> gpio used for HDMI hot plug detection is useless,
> HDMI_STI register contains an hot plug detection status bit.
> Fix binding documentation.

Random thought, but depending on how much you trust your hw designers
you may want to at least leave the DT entry as optional?  I've started
out before completely trusting the hdmi block's debounced hpd signal,
but eventually giving up and using raw gpio, or combination of gpio +
debounced hdmi signal for reliability..

BR,
-R

> Signed-off-by: Benjamin Gaignard 
> ---
>  Documentation/devicetree/bindings/gpu/st,stih4xx.txt |  2 --
>  drivers/gpu/drm/sti/sti_hdmi.c   | 11 ++-
>  drivers/gpu/drm/sti/sti_hdmi.h   |  5 +++--
>  3 files changed, 5 insertions(+), 13 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/gpu/st,stih4xx.txt 
> b/Documentation/devicetree/bindings/gpu/st,stih4xx.txt
> index 8885d9e..32cfc7b 100644
> --- a/Documentation/devicetree/bindings/gpu/st,stih4xx.txt
> +++ b/Documentation/devicetree/bindings/gpu/st,stih4xx.txt
> @@ -68,7 +68,6 @@ STMicroelectronics stih4xx platforms
>  number of clocks may depend of the SoC type.
>- clock-names: names of the clocks listed in clocks property in the same
>  order.
> -  - hdmi,hpd-gpio: gpio id to detect if an hdmi cable is plugged or not.
>- ddc: phandle of an I2C controller used for DDC EDID probing
>
>  sti-hda:
> @@ -174,7 +173,6 @@ Example:
> interrupt-names = "irq";
> clock-names = "pix", "tmds", "phy", 
> "audio";
> clocks  = <_c_vcc 
> CLK_S_PIX_HDMI>, <_c_vcc CLK_S_TMDS_HDMI>, <_c_vcc 
> CLK_S_HDMI_REJECT_PLL>, <_b1 CLK_S_PCM_0>;
> -   hdmi,hpd-gpio   = < 5>;
> };
>
> sti-hda at fe85a000 {
> diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
> index 7673189..09f39c5 100644
> --- a/drivers/gpu/drm/sti/sti_hdmi.c
> +++ b/drivers/gpu/drm/sti/sti_hdmi.c
> @@ -130,8 +130,7 @@ static irqreturn_t hdmi_irq_thread(int irq, void *arg)
>
> /* Hot plug/unplug IRQ */
> if (hdmi->irq_status & HDMI_INT_HOT_PLUG) {
> -   /* read gpio to get the status */
> -   hdmi->hpd = gpio_get_value(hdmi->hpd_gpio);
> +   hdmi->hpd = readl(hdmi->regs + HDMI_STA) & HDMI_STA_HOT_PLUG;
> if (hdmi->drm_dev)
> drm_helper_hpd_irq_event(hdmi->drm_dev);
> }
> @@ -767,13 +766,7 @@ static int sti_hdmi_probe(struct platform_device *pdev)
> return PTR_ERR(hdmi->clk_audio);
> }
>
> -   hdmi->hpd_gpio = of_get_named_gpio(np, "hdmi,hpd-gpio", 0);
> -   if (hdmi->hpd_gpio < 0) {
> -   DRM_ERROR("Failed to get hdmi hpd-gpio\n");
> -   return -EIO;
> -   }
> -
> -   hdmi->hpd = gpio_get_value(hdmi->hpd_gpio);
> +   hdmi->hpd = readl(hdmi->regs + HDMI_STA) & HDMI_STA_HOT_PLUG;
>
> init_waitqueue_head(>wait_event);
>
> diff --git a/drivers/gpu/drm/sti/sti_hdmi.h b/drivers/gpu/drm/sti/sti_hdmi.h
> index d00a3e0..3d22390 100644
> --- a/drivers/gpu/drm/sti/sti_hdmi.h
> +++ b/drivers/gpu/drm/sti/sti_hdmi.h
> @@ -14,6 +14,9 @@
>  #define HDMI_STA   0x0010
>  #define HDMI_STA_DLL_LCK   BIT(5)
>
> +#define HDMI_STA_HOT_PLUG_SHIFT 4
> +#define HDMI_STA_HOT_PLUG  (1 << HDMI_STA_HOT_PLUG_SHIFT)
> +
>  struct sti_hdmi;
>
>  struct hdmi_phy_ops {
> @@ -37,7 +40,6 @@ struct hdmi_phy_ops {
>   * @irq_status: interrupt status register
>   * @phy_ops: phy start/stop operations
>   * @enabled: true if hdmi is enabled else false
> - * @hpd_gpio: hdmi hot plug detect gpio number
>   * @hpd: hot plug detect status
>   * @wait_event: wait event
>   * @event_received: wait event status
> @@ -57,7 +59,6 @@ struct sti_hdmi {
> u32 irq_status;
> struct hdmi_phy_ops *phy_ops;
> bool enabled;
> -   int hpd_gpio;
> bool hpd;
> wait_queue_head_t wait_event;
> bool event_received;
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 84663] high cpu usage, poor performance in Borderlands 2 with radeonsi, PRIME

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

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

--- Comment #6 from Christoph Haag  ---
Created attachment 107595
  --> https://bugs.freedesktop.org/attachment.cgi?id=107595=edit
GALLIUM_HUD="fps,VRAM-usage+GTT-usage,requested-VRAM+requested-GTT,num-bytes-moved;cpu0+cpu1+cpu2+cpu3;cpu4+cpu5+cpu6+cpu7"

(In reply to Michel D?nzer from comment #5)
> I don't notice anything using obviously too much CPU in your profile. Can
> you get a screenshot with GALLIUM_HUD like in bug 84570?

For the screenshot I pinned the game to the cpus 3,7 with taskset to stop it
from polluting the graphs so much when jumping between cpus. Didn't really
decrease or increase the performance much.

I really don't know right now... When the game loses the input focus, it pauses
the game and the game rendering itself is not updated anymore I think. The cpu
usage will drop from 112-114% cpu usage to 100% cpu usage and the fps go up to
60 fps. When the game is focussed again, it unpauses, and then it's again low
performance.

-- 
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/20141009/f1bd400c/attachment.html>

[Bug 79659] R9 270X lockup with unigine valley since radeonsi: enable ARB_sample_shading

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

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

--- Comment #15 from Alexander Tsoy  ---
Ah.. "st/mesa,gallium: add a workaround for Unigine Heaven 4.0 and Valley 1.0"
is also included in mesa-10.3. So both Heaven 4.0 and Valley 1.0 should just
work. The question is why ARB_sample_shading is causing GPU lockup on VERDE.
Should I open a separate bug for this issue?

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

AMD GPU new API for new module

[Jerome Glisse]

On Thu, Oct 09, 2014 at 09:54:14AM +0300, Oded Gabbay wrote:
> Hi Jerome,
> 
> Do you think your proposed change should also be applied to amdkfd's
> IOCTLs ?

It might make sense it really depends on the lifespan you expect for
amdkfd, do you expect that you will need substential API evolution
during that timespan or do you foresee that the currently propose API
is good enough.

The thing i am proposing here is really to address the issue of IOCTL
needing fixes because new generation of GPU requires new informations
or do not care about old and now meaningless informations. The radeon
ioctl sets is a testimony to the fact that we can not predict what kind
of broken API we expose and have to leave with.

My proposal is really about allowing to evolve each ioctl in what i
believe to be the simplest and cleanest way to do it while still
preserving backward compatibility ie i expect that old version of
an ioctl will continue to live in there own functions untouch and
unlove but still working. While new development can move to updated
ioctl.

Other solution would be to just keep adding new ioctl but i fear we
might run out of ioctl number.

Cheers,
J?r?me

> 
>   Oded
> 
> On 08/10/14 19:00, Jerome Glisse wrote:
> > Hi,
> > 
> > So if i do not start the discussion now it might be already too late. Given
> > plan to converge open source driver and closed source driver to use a single
> > common kernel driver and that this would be a new kernel driver. This is an
> > opportunity to fix some of the radeon design issues (at least things that i
> > would have done differently if only i could get some gas for my DeLorean).
> > 
> > Among the thing that i will not do is the chunk stuff associated with cs
> > ioctl. I find it ugly, if my memory serve me well i was trying to be future
> > proof and allow the cs ioctl to be extended. While this original aim have
> > been somewhat successfully, i think it was the wrong day to do it.
> > 
> > My lastest (and what i still believe to be a good idea until proven wrong),
> > is to change the way we do ioctl and use a little trick. This idea was also
> > spark by the continuous additions we do to info ioctl which is getting ugly.
> > 
> > So idea is simple, each ioctl would use some struct like :
> > 
> > struct radeon_ioctl {
> > u32 version;
> > u32 size;
> > };
> > 
> > The version field is the key here, think of it as an index into an array of
> > ioctl dispatch functions. So something like :
> > 
> > struct radeon_ioctls {
> > int (*iotcl)[MAX_IOCTL_NUM](void *data, ...);
> > };
> > 
> > struct radeon_ioctls rdispatch_ioctls[N];
> > 
> > And now all ioctl go through this single entry point :
> > 
> > int radeon_ioctl_stub(int ioctl, void *data, ...)
> > {
> > struct radeon_ioctl *rio = data;
> > 
> > return rdispatch_ioctls[rio->version][ioctl](data, ...);
> > }
> > 
> > So this is rough idea but the point is that we can do proper ioctl 
> > versioning
> > and have separate functions for each new versions and avoid ioctl cruft, or
> > at least this is the theory.
> > 
> > The two things this gave us, is feedback from userspace as we the version 
> > the
> > kernel will know which version of userspace it is dealing with. The others 
> > one
> > is that it does allow you to introduce a completely new API either for new
> > generation of hardware or just as an evolution. And small bonus is that it
> > does allow to slowly phase out API that we consider broken (ioctl per 
> > ioctl).
> > 
> > So this is the main design change that i would do. I should probably rought
> > up something that goes deeper for the cs ioctl.
> > 
> > Cheers,
> > J?r?me
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> > 

AMD GPU new API for new module

[Jerome Glisse]

On Thu, Oct 09, 2014 at 03:32:26AM -0400, Rob Clark wrote:
> On Wed, Oct 8, 2014 at 12:00 PM, Jerome Glisse  wrote:
> >
> > So idea is simple, each ioctl would use some struct like :
> >
> > struct radeon_ioctl {
> > u32 version;
> > u32 size;
> > };
> 
> 
> fwiw, drm_ioctl() will do the right thing (zero-pad) for growing
> ioctls these days..

It's more about userspace knowing about ioctl XY and having a way
to override/ask for special version of each ioctl. So if we screw
ioctl XY, we can add a new version to XY and we can try to work
around if userspace still request the old version. It is mostly
about trying to keep the code clean and avoiding things like the
chunk stuff of the cs ioctl.

For instance if you cs ioctl with the following struct as ioctl
parameter:

struct drm_radeon_cs_ioctl_version_00 {
   u64  *cs;
   u32  size;
   u32  flags;
};

And now you have a new generation of hardware or are just adding
a new feature :

struct drm_radeon_cs_ioctl_version_01 {
   u64  *cs;
   u32  size;
   u32  flags;
   u32  newfeature fields;
};

Of course you can argue that you could use the size of user space
paremeter to do this simple example. But with versioning you can
also move fields around, remove fields, ... basicly it is just more
flexible with small overhead of having one more indirection but this
will be lost into the ioctl cost anyway (i highly doubt it would
turns as a bottleneck).

Cheers,
J?r?me

> 
> BR,
> -R

AMD GPU new API for new module

[Rob Clark]

On Wed, Oct 8, 2014 at 12:00 PM, Jerome Glisse  wrote:
>
> So idea is simple, each ioctl would use some struct like :
>
> struct radeon_ioctl {
> u32 version;
> u32 size;
> };


fwiw, drm_ioctl() will do the right thing (zero-pad) for growing
ioctls these days..

BR,
-R

[Bug 84140] mplayer crashes playing some files using vdpau output

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

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

--- Comment #26 from Dieter N?tzel  ---
(In reply to Christian K?nig from comment #24)
> Created attachment 107497 [details] [review]
> Possible fix

First quik test do NOT work on RV730 AGP.
Linux 3.16.3 32 bit
Mesa git-67909f2

Tomorrow I'll do some debug runs.

-- 
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/20141009/88e25212/attachment.html>

[PATCH] video/hdmi: Relicense header under MIT license

[Deucher, Alexander]

> -Original Message-
> From: Thierry Reding [mailto:thierry.reding at gmail.com]
> Sent: Wednesday, October 08, 2014 12:45 PM
> To: David Airlie
> Cc: Daniel Vetter; Deucher, Alexander; Alban Bedel; dri-
> devel at lists.freedesktop.org
> Subject: [PATCH] video/hdmi: Relicense header under MIT license
> 
> From: Thierry Reding 
> 
> OpenBSD wants to reuse this file but needs the license to be more
> permissive.
> 
> Acked-by: Alban Bedel 
> Acked-by: Daniel Vetter 
> Signed-off-by: Thierry Reding 

Acked-by: Alex Deucher 

> ---
>  include/linux/hdmi.h | 21 ++---
>  1 file changed, 18 insertions(+), 3 deletions(-)
> 
> diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
> index 11c0182a153b..cbb5790a35cd 100644
> --- a/include/linux/hdmi.h
> +++ b/include/linux/hdmi.h
> @@ -1,9 +1,24 @@
>  /*
>   * Copyright (C) 2012 Avionic Design GmbH
>   *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License version 2 as
> - * published by the Free Software Foundation.
> + * 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, sub license,
> + * 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 NON-INFRINGEMENT. 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.
>   */
> 
>  #ifndef __LINUX_HDMI_H_
> --
> 2.1.0