[PATCH] drm/exynos: wait for the completion of pending page flip

[Stéphane Marchesin]

On Tue, May 21, 2013 at 9:22 PM, Inki Dae  wrote:
>
>
>
> 2013/5/22 St?phane Marchesin 
>>
>> On Tue, May 21, 2013 at 1:08 AM, Inki Dae  wrote:
>> > This patch fixes the issue that drm_vblank_get() is failed.
>> >
>> > The issus occurs when next page flip request is tried
>> > if previous page flip event wasn't completed yet and then
>> > dpms became off.
>> >
>> > So this patch make sure that page flip event is completed
>> > before dpms goes to off.
>>
>> Hi,
>>
>> This patch is a squash of the two following patches from the Chrome OS
>> tree with the KDS bits removed and the dpms off bit added:
>>
>>
>> http://git.chromium.org/gitweb/?p=chromiumos/third_party/kernel-next.git;a=commitdiff;h=2e77cd4e423967862ca01b1af82aa8b5b7429fc4;hp=aba002da4c6e5efec4d43e1ce33930a79269349a
>>
>> http://git.chromium.org/gitweb/?p=chromiumos/third_party/kernel-next.git;a=commitdiff;h=b4ec8bfa750ef43a43c2da746c8afdbb51002882;hp=4f28b9a75c928f229443d7c6c3163159ceb6903a
>>
>> Please keep proper attribution.
>>
>
> Those patches are just for Chrome OS. Please post them if you want for those
> to be considered so that they can be reviewed.

We intend to, once they are rebased onto latest kernel. But what I'm
pointing out is that you're removing proper attribution from Chrome OS
patches, and this is the second time it has happened.

> That is why we attend open
> source. One more comment, please do not abuse exynos_drm_crtc_page_flip()
>

What do you mean by abuse?

>>
>> Signed-off-by: Inki Dae 
>> Signed-off-by: Kyungmin Park 
>> ---
>>  drivers/gpu/drm/exynos/exynos_drm_crtc.c |   16 
>>  1 files changed, 16 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>> index e8894bc..69a77e9 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>> @@ -48,6 +48,8 @@ struct exynos_drm_crtc {
>> unsigned intpipe;
>> unsigned intdpms;
>> enum exynos_crtc_mode   mode;
>> +   wait_queue_head_t   pending_flip_queue;
>> +   atomic_tpending_flip;
>>  };
>>
>>  static void exynos_drm_crtc_dpms(struct drm_crtc *crtc, int mode)
>> @@ -61,6 +63,13 @@ static void exynos_drm_crtc_dpms(struct drm_crtc *crtc,
>> int mode)
>> return;
>> }
>>
>> +   if (mode > DRM_MODE_DPMS_ON) {
>> +   /* wait for the completion of page flip. */
>> +   wait_event(exynos_crtc->pending_flip_queue,
>> +   atomic_read(_crtc->pending_flip) ==
>> 0);
>> +   drm_vblank_off(crtc->dev, exynos_crtc->pipe);
>
>> You should be using vblank_put/get.
>>
>
> No, drm_vblank_put should be called by exynos_drm_crtc_finish_pageflip().
> And know that this patch makes sure that pended page flip event is completed
> before dpms goes to off.

You need to do vblank_put/get while you're waiting. Otherwise you
don't know for sure that flips will happen. This is especially bad as
you don't use a timeout.

St?phane

>
> Thanks,
> Inki Dae
>
>> St?phane
>>
>> > +   }
>> > +
>> > exynos_drm_fn_encoder(crtc, ,
>> > exynos_drm_encoder_crtc_dpms);
>> > exynos_crtc->dpms = mode;
>> >  }
>> > @@ -225,6 +234,7 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc
>> > *crtc,
>> > spin_lock_irq(>event_lock);
>> > list_add_tail(>base.link,
>> > _priv->pageflip_event_list);
>> > +   atomic_set(_crtc->pending_flip, 1);
>> > spin_unlock_irq(>event_lock);
>> >
>> > crtc->fb = fb;
>> > @@ -344,6 +354,8 @@ int exynos_drm_crtc_create(struct drm_device *dev,
>> > unsigned int nr)
>> >
>> > exynos_crtc->pipe = nr;
>> > exynos_crtc->dpms = DRM_MODE_DPMS_OFF;
>> > +   init_waitqueue_head(_crtc->pending_flip_queue);
>> > +   atomic_set(_crtc->pending_flip, 0);
>> > exynos_crtc->plane = exynos_plane_init(dev, 1 << nr, true);
>> > if (!exynos_crtc->plane) {
>> > kfree(exynos_crtc);
>> > @@ -398,6 +410,8 @@ void exynos_drm_crtc_finish_pageflip(struct
>> > drm_device *dev, int crtc)
>> >  {
>> > struct exynos_drm_private *dev_priv = dev->dev_private;
>> > struct drm_pending_vblank_event *e, *t;
>> > +   struct drm_crtc *drm_crtc = dev_priv->crtc[crtc];
>> > +   struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(drm_crtc);
>> > struct timeval now;
>> > unsigned long flags;
>> >
>> > @@ -419,6 +433,8 @@ void exynos_drm_crtc_finish_pageflip(struct
>> > drm_device *dev, int crtc)
>> > list_move_tail(>base.link,
>> > >base.file_priv->event_list);
>> > wake_up_interruptible(>base.file_priv->event_wait);
>> > drm_vblank_put(dev, crtc);
>> > +   atomic_set(_crtc->pending_flip, 0);
>> > +  

[Bug 64819] GPU fault detected flood at A8-5600K Trinity 7560D

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

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

--- Comment #4 from p00h  ---
I'll try it and make an report after

-- 
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/20130521/d5aea46b/attachment.html>

[Bug 63520] r300g regression (RV380): Strange rendering of light sources in Penumbra (bisected)

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

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

--- Comment #20 from PJBrs  ---
P.s., I did a quick glance at the difference between the first bad log and the
log with the patch (sdiff badlog  patch-test.log | less). It seems as if shader
pc8 now is truncated or something...

-- 
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/20130521/e3d7c06a/attachment.html>

[Bug 63520] r300g regression (RV380): Strange rendering of light sources in Penumbra (bisected)

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

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

--- Comment #19 from PJBrs  ---
Created attachment 79628
  --> https://bugs.freedesktop.org/attachment.cgi?id=79628=edit
Log with possible fix

Hi, thanks for the patch! Unfortunately, it does not appear to do anything that
I can see, the bug(s?) are still there. I've attached the log as per your
request. Let me know if I can help in any other way.

-- 
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/20130521/963259dc/attachment.html>

[Bug 63236] kwin crashes when some desktop effects are used

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

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

--- Comment #4 from Eugene  ---
>Did you actually verify the problem to be fixed with radeonsi?

Unfortunately I didn't check what exactly solved the problem, the only thing
for sure - I can not reproduce it now.

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

[Bug 64819] GPU fault detected flood at A8-5600K Trinity 7560D

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

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

--- Comment #3 from Alex Deucher  ---
Does mesa from git master work any better?  You might also try disabling hyperz
(set env var R600_HYPERZ=0).

-- 
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/20130521/e8232720/attachment.html>

[Bug 64819] GPU fault detected flood at A8-5600K Trinity 7560D

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

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

--- Comment #2 from p00h  ---
mesa: 9.1.2
ati-dri: 9.1.2
The kernel has this patch already.
I have several machines with the same problem, all of them shipped with
A8-5600K.

-- 
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/20130521/e0b60ce5/attachment.html>

[pull] drm-intel-fixes

[Stéphane Marchesin]

On Mon, Sep 10, 2012 at 12:28 AM, Daniel Vetter  wrote:
> Hi Dave,
>
> You're pull just reminded me that I've been sitting on a few small -fixes,
> too. Nothing really major at all:
> - fixup edp setup sequence (Dave)
> - disable sdvo hotplug for real, this is a fixup for a messed-up
>   regression fixer (Jani)
> - don't expose dysfunctional backlight driver (Jani)

Hi Daniel,

This change ("don't expose dysfunctional backlight driver") regresses
the backlight on Chromebooks, where we don't run the vbios.

St?phane


> - properly init spinlock (only used by hsw/vlv code) from Alexander
>   Shishkin
>
> Wrt regression we have a new case of rc6-no-longer-working (times time it
> breaks after resume, investigation still going on) and one of the
> infoframe patches broke a screen on ilk (Paulo is looking into this one
> already).
>
> Cheers, Daniel
>
> The following changes since commit 4cbe5a555fa58a79b6ecbb6c531b8bab0650778d:
>
>   Linux 3.6-rc4 (2012-09-01 10:39:58 -0700)
>
> are available in the git repository at:
>
>   git://people.freedesktop.org/~danvet/drm-intel drm-intel-fixes
>
> for you to fetch changes up to 99d0b1db6ccd0c0e554398e8a579ff3dd4d119ee:
>
>   drm/i915: initialize dpio_lock spin lock (2012-09-08 19:04:04 +0200)
>
> 
> Alexander Shishkin (1):
>   drm/i915: initialize dpio_lock spin lock
>
> Dave Airlie (1):
>   drm/i915/edp: get the panel delay before powering up
>
> Jani Nikula (2):
>   drm/i915: only enable sdvo hotplug irq if needed
>   drm/i915: do not expose a dysfunctional backlight interface to userspace
>
>  drivers/gpu/drm/i915/i915_dma.c|1 +
>  drivers/gpu/drm/i915/intel_dp.c|   11 +++
>  drivers/gpu/drm/i915/intel_panel.c |   31 ++-
>  drivers/gpu/drm/i915/intel_sdvo.c  |   15 ++-
>  4 files changed, 36 insertions(+), 22 deletions(-)
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

Introduce a new helper framework for buffer synchronization

[Inki Dae]

> -Original Message-
> From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Tuesday, May 21, 2013 4:45 PM
> To: Inki Dae
> Cc: 'Daniel Vetter'; 'Rob Clark'; 'linux-fbdev'; 'DRI mailing list';
> 'Kyungmin Park'; 'myungjoo.ham'; 'YoungJun Cho'; linux-arm-
> kernel at lists.infradead.org; linux-media at vger.kernel.org
> Subject: Re: Introduce a new helper framework for buffer synchronization
> 
> On Tue, May 21, 2013 at 04:03:06PM +0900, Inki Dae wrote:
> > > - Integration of fence syncing into dma_buf. Imo we should have a
> > >   per-attachment mode which decides whether map/unmap (and the new
> sync)
> > >   should wait for fences or whether the driver takes care of syncing
> > >   through the new fence framework itself (for direct hw sync).
> >
> > I think it's a good idea to have per-attachment mode for buffer sync.
> But
> > I'd like to say we make sure what is the purpose of map
> > (dma_buf_map_attachment)first. This interface is used to get a sgt;
> > containing pages to physical memory region, and map that region with
> > device's iommu table. The important thing is that this interface is
> called
> > just one time when user wants to share an allocated buffer with dma. But
> cpu
> > will try to access the buffer every time as long as it wants. Therefore,
> we
> > need cache control every time cpu and dma access the shared buffer:
> cache
> > clean when cpu goes to dma and cache invalidate when dma goes to cpu.
> That
> > is why I added new interfaces, DMA_BUF_GET_FENCE and DMA_BUF_PUT_FENCE,
> to
> > dma buf framework. Of course, Those are ugly so we need a better way: I
> just
> > wanted to show you that in such way, we can synchronize the shared
> buffer
> > between cpu and dma. By any chance, is there any way that kernel can be
> > aware of when cpu accesses the shared buffer or is there any point I
> didn't
> > catch up?
> 
> Well dma_buf_map/unmap_attachment should also flush/invalidate any caches,
> and with the current dma_buf spec those two functions are the _only_ means

I know that dma buf exporter should make sure that cache clean/invalidate
are done when dma_buf_map/unmap_attachement is called. For this, already we
do so. However, this function is called when dma buf import is requested by
user to map a dmabuf fd with dma. This means that dma_buf_map_attachement()
is called ONCE when user wants to share the dmabuf fd with dma. Actually, in
case of exynos drm, dma_map_sg_attrs(), performing cache operation
internally, is called when dmabuf import is requested by user.

> you have to do so. Which strictly means that if you interleave device dma
> and cpu acccess you need to unmap/map every time.
> 
> Which is obviously horribly inefficient, but a known gap in the dma_buf

Right, and also this has big overhead.

> interface. Hence why I proposed to add dma_buf_sync_attachment similar to
> dma_sync_single_for_device:
> 
> /**
>  * dma_buf_sync_sg_attachment - sync caches for dma access
>  * @attach: dma-buf attachment to sync
>  * @sgt: the sg table to sync (returned by dma_buf_map_attachement)
>  * @direction: dma direction to sync for
>  *
>  * This function synchronizes caches for device dma through the given
>  * dma-buf attachment when interleaving dma from different devices and the
>  * cpu. Other device dma needs to be synced also by calls to this
>  * function (or a pair of dma_buf_map/unmap_attachment calls), cpu access
>  * needs to be synced with dma_buf_begin/end_cpu_access.
>  */
> void dma_buf_sync_sg_attachment(struct dma_buf_attachment *attach,
>   struct sg_table *sgt,
>   enum dma_data_direction direction)
> 
> Note that "sync" here only means to synchronize caches, not wait for any
> outstanding fences. This is simply to be consistent with the established
> lingo of the dma api. How the dma-buf fences fit into this is imo a
> different topic, but my idea is that all the cache coherency barriers
> (i.e. dma_buf_map/unmap_attachment, dma_buf_sync_sg_attachment and
> dma_buf_begin/end_cpu_access) would automatically block for any attached
> fences (i.e. block for write fences when doing read-only access, block for
> all fences otherwise).

As I mentioned already, kernel can't aware of when cpu accesses a shared
buffer: user can access a shared buffer after mmap anytime and the shared
buffer should be synchronized between cpu and dma. Therefore, the above
cache coherency barriers should be called every time cpu and dma tries to
access a shared buffer, checking before and after of cpu and dma access. And
exactly, the proposed way do such thing. For this, you can refer to the
below link,

http://www.mail-archive.com/linux-media at vger.kernel.org/msg62124.html

My point is that how kernel can aware of when those cache coherency barriers
should be called to synchronize caches and buffer access between cpu and
dma.

> 
> Then we could do a new dma_buf_attach_flags interface 

[Bug 64649] Anomaly 2 (Steam) exits with divide by 0 in r600g

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

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

Alex Deucher  changed:

   What|Removed |Added

Summary|Anomaly 2 (Steam) exits |Anomaly 2 (Steam) exits
   |with segfault in r600g  |with divide by 0 in r600g

-- 
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/20130521/4aea5b1b/attachment.html>

[Bug 64649] Anomaly 2 (Steam) exits with segfault in r600g

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

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

Alex Deucher  changed:

   What|Removed |Added

Summary|Anomaly 2 (Steam) exits |Anomaly 2 (Steam) exits
   |with GLX_EXT_swap_control   |with segfault in r600g
   |not supported, unable to|
   |set vertical sync   |

-- 
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/20130521/b9a3ddce/attachment.html>

[Bug 64649] Anomaly 2 (Steam) exits with GLX_EXT_swap_control not supported, unable to set vertical sync

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

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

--- Comment #14 from Kai  ---
(In reply to comment #11)
> (In reply to comment #2)
> > It then closes. It won't run without that extention, switched to GLX instead
> > of a driver specific component.
> 
> The game runs for me with i965 on gen7.

Very likely (see attachment 79573). The title is wrong, GLX_EXT_swap_control is
only requested by the Steam overlay and non-critical. I can see the
GLX_EXT_swap_control with any game I launch through Steam (e.g. Oil Rush) and
the others work well. It's just Anomaly that is hitting a bug in r600g (or a
bug in Anomaly which isn't handled gracefully by r600g?). Anyway, the title
should be changed to something more accurate.

-- 
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/20130521/7d2b2f2a/attachment.html>

Genereal question regarding kernel development

[Daniel Vetter]

On Tue, May 21, 2013 at 4:30 PM, Jan Niggemann  wrote:
> Hi Daniel,
>
> you misunderstood my mail, I just wanted to know:
>
> Are patches in patchwork that correct kernel bugs in any way linked to
> bugzilla issues and if so, how?
> In other words: What bugzilla bug corresponds to
> https://patchwork.kernel.org/patch/2402211/ ?

There's no bug rebort for this issue in kernel bugzilla afaik. And
please don't drop cc's.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH] drm: fix a use-after-free when GPU acceleration disabled

[Paul Menzel]

Am Dienstag, den 21.05.2013, 14:23 +0800 schrieb Huacai Chen:
> When GPU acceleration is disabled, drm_vblank_cleanup() will free the
> vblank-related data, such as vblank_refcount, vblank_inmodeset, etc.
> But we found that drm_vblank_post_modeset() may be called after the
> cleanup, which use vblank_refcount and vblank_inmodeset. And this will
> cause a kernel panic.
> 
> Fix this by return immediately if dev->num_crtcs is zero. This is the
> same thing that drm_vblank_pre_modeset() does.
> 
> Call trace of a drm_vblank_post_modeset() after drm_vblank_cleanup():
> [   62.628906] [] drm_vblank_post_modeset+0x34/0xb4
> [   62.628906] [] atombios_crtc_dpms+0xb4/0x174
> [   62.628906] [] atombios_crtc_commit+0x18/0x38
> [   62.628906] [] drm_crtc_helper_set_mode+0x304/0x3cc
> [   62.628906] [] drm_crtc_helper_set_config+0x6d8/0x988
> [   62.628906] [] drm_fb_helper_set_par+0x94/0x104
> [   62.628906] [] fbcon_init+0x424/0x57c
> [   62.628906] [] visual_init+0xb8/0x118
> [   62.628906] [] take_over_console+0x238/0x384
> [   62.628906] [] fbcon_takeover+0x7c/0xdc
> [   62.628906] [] notifier_call_chain+0x44/0x94
> [   62.628906] [] __blocking_notifier_call_chain+0x48/0x68
> [   62.628906] [] register_framebuffer+0x228/0x260
> [   62.628906] [] drm_fb_helper_single_fb_probe+0x260/0x314
> [   62.628906] [] drm_fb_helper_initial_config+0x200/0x234
> [   62.628906] [] radeon_fbdev_init+0xd4/0xf4
> [   62.628906] [] radeon_modeset_init+0x9bc/0xa18
> [   62.628906] [] radeon_driver_load_kms+0xdc/0x12c
> [   62.628906] [] drm_get_pci_dev+0x148/0x238
> [   62.628906] [] local_pci_probe+0x5c/0xd0
> [   62.628906] [] work_for_cpu_fn+0x1c/0x30
> [   62.628906] [] process_one_work+0x274/0x3bc
> [   62.628906] [] process_scheduled_works+0x24/0x44
> [   62.628906] [] worker_thread+0x31c/0x3f4
> [   62.628906] [] kthread+0x88/0x90
> [   62.628906] [] kernel_thread_helper+0x10/0x18

Nice commit message!

> Signed-off-by: Huacai Chen 
> Signed-off-by: Binbin Zhou 
> Cc: 
> ---
>  drivers/gpu/drm/drm_irq.c |6 +-
>  1 files changed, 5 insertions(+), 1 deletions(-)

[?]

Acked-by: Paul Menzel 


Thanks,

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

[PATCH] drm/radeon: UVD block on SUMO2 is the same as on SUMO

[Christian König]

From: Christian K?nig 

The chip id for SUMO2 isn't used.

Signed-off-by: Christian K?nig 
---
 drivers/gpu/drm/radeon/rv770.c |4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
index 83f612a..3fc2985 100644
--- a/drivers/gpu/drm/radeon/rv770.c
+++ b/drivers/gpu/drm/radeon/rv770.c
@@ -862,10 +862,8 @@ int rv770_uvd_resume(struct radeon_device *rdev)
chip_id = 0x010b;
break;
case CHIP_SUMO:
-   chip_id = 0x010c;
-   break;
case CHIP_SUMO2:
-   chip_id = 0x010d;
+   chip_id = 0x010c;
break;
case CHIP_PALM:
chip_id = 0x010e;
-- 
1.7.9.5

[PATCH] drm/exynos: wait for the completion of pending page flip

[Inki Dae]

This patch fixes the issue that drm_vblank_get() is failed.

The issus occurs when next page flip request is tried
if previous page flip event wasn't completed yet and then
dpms became off.

So this patch make sure that page flip event is completed
before dpms goes to off.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c |   16 
 1 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index e8894bc..69a77e9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -48,6 +48,8 @@ struct exynos_drm_crtc {
unsigned intpipe;
unsigned intdpms;
enum exynos_crtc_mode   mode;
+   wait_queue_head_t   pending_flip_queue;
+   atomic_tpending_flip;
 };

 static void exynos_drm_crtc_dpms(struct drm_crtc *crtc, int mode)
@@ -61,6 +63,13 @@ static void exynos_drm_crtc_dpms(struct drm_crtc *crtc, int 
mode)
return;
}

+   if (mode > DRM_MODE_DPMS_ON) {
+   /* wait for the completion of page flip. */
+   wait_event(exynos_crtc->pending_flip_queue,
+   atomic_read(_crtc->pending_flip) == 0);
+   drm_vblank_off(crtc->dev, exynos_crtc->pipe);
+   }
+
exynos_drm_fn_encoder(crtc, , exynos_drm_encoder_crtc_dpms);
exynos_crtc->dpms = mode;
 }
@@ -225,6 +234,7 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc,
spin_lock_irq(>event_lock);
list_add_tail(>base.link,
_priv->pageflip_event_list);
+   atomic_set(_crtc->pending_flip, 1);
spin_unlock_irq(>event_lock);

crtc->fb = fb;
@@ -344,6 +354,8 @@ int exynos_drm_crtc_create(struct drm_device *dev, unsigned 
int nr)

exynos_crtc->pipe = nr;
exynos_crtc->dpms = DRM_MODE_DPMS_OFF;
+   init_waitqueue_head(_crtc->pending_flip_queue);
+   atomic_set(_crtc->pending_flip, 0);
exynos_crtc->plane = exynos_plane_init(dev, 1 << nr, true);
if (!exynos_crtc->plane) {
kfree(exynos_crtc);
@@ -398,6 +410,8 @@ void exynos_drm_crtc_finish_pageflip(struct drm_device 
*dev, int crtc)
 {
struct exynos_drm_private *dev_priv = dev->dev_private;
struct drm_pending_vblank_event *e, *t;
+   struct drm_crtc *drm_crtc = dev_priv->crtc[crtc];
+   struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(drm_crtc);
struct timeval now;
unsigned long flags;

@@ -419,6 +433,8 @@ void exynos_drm_crtc_finish_pageflip(struct drm_device 
*dev, int crtc)
list_move_tail(>base.link, >base.file_priv->event_list);
wake_up_interruptible(>base.file_priv->event_wait);
drm_vblank_put(dev, crtc);
+   atomic_set(_crtc->pending_flip, 0);
+   wake_up(_crtc->pending_flip_queue);
}

spin_unlock_irqrestore(>event_lock, flags);
-- 
1.7.5.4

Genereal question regarding kernel development

[Daniel Vetter]

Hi Jan,

First things first, please _always_ cc relevant mailing lists.

Second: I've submitted a proper patch to revert this behaviour change,
but it has been nacked. I've poked Dave Airlie about it again on irc.
See https://patchwork.kernel.org/patch/2402211/

Thanks, Daniel

On Tue, May 21, 2013 at 3:28 PM, Jan Niggemann  wrote:
> Hi Daniel,
>
> sorry for bothering you directly, but being a kernel dev you can probably
> answer my question:
> I read what "patchwork" is and what it's used for; I also understand that
> bugs are tracked in bugzilla and that both are separate systems.
> My question is:
> I'm affected by this: https://patchwork.kernel.org/patch/2400621/
> I expected this patch to be somehow linked to a bugzilla entry I could
> subscribe to (in order to get updates on issue)...
> But I'm unable to find a bug in bugzilla regarding "kworker irq storm" or
> similar...
>
> Are patches in patchwork that correct kernel bugs in any way linked to
> bugzilla issues and if so, how?
> Thank you for your time!
>
> Regards
> Jan



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

[Bug 63935] TURKS [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!

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

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

--- Comment #36 from Christian K?nig  ---
(In reply to comment #35)
> Would this be the same as others have done above?

Thanks for the input, but we already have enough register dumps for now.

Currently I'm analyzing them and trying to figure out what the heck is going
wrong here.

Cheers,
Christian.

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

Introduce a new helper framework for buffer synchronization

[Inki Dae]

> -Original Message-
> From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Tuesday, May 21, 2013 6:31 AM
> To: Inki Dae
> Cc: Rob Clark; linux-fbdev; DRI mailing list; Kyungmin Park; myungjoo.ham;
> YoungJun Cho; linux-arm-kernel at lists.infradead.org; linux-
> media at vger.kernel.org
> Subject: Re: Introduce a new helper framework for buffer synchronization
> 
> On Mon, May 20, 2013 at 11:13:04PM +0200, Daniel Vetter wrote:
> > On Sat, May 18, 2013 at 03:47:43PM +0900, Inki Dae wrote:
> > > 2013/5/15 Rob Clark 
> > >
> > > > On Wed, May 15, 2013 at 1:19 AM, Inki Dae 
> wrote:
> > > > >
> > > > >
> > > > >> -Original Message-
> > > > >> From: Rob Clark [mailto:robdclark at gmail.com]
> > > > >> Sent: Tuesday, May 14, 2013 10:39 PM
> > > > >> To: Inki Dae
> > > > >> Cc: linux-fbdev; DRI mailing list; Kyungmin Park; myungjoo.ham;
> YoungJun
> > > > >> Cho; linux-arm-kernel at lists.infradead.org; linux-
> media at vger.kernel.org
> > > > >> Subject: Re: Introduce a new helper framework for buffer
> synchronization
> > > > >>
> > > > >> On Mon, May 13, 2013 at 10:52 PM, Inki Dae 
> > > > wrote:
> > > > >> >> well, for cache management, I think it is a better idea.. I
> didn't
> > > > >> >> really catch that this was the motivation from the initial
> patch, but
> > > > >> >> maybe I read it too quickly.  But cache can be decoupled from
> > > > >> >> synchronization, because CPU access is not asynchronous.  For
> > > > >> >> userspace/CPU access to buffer, you should:
> > > > >> >>
> > > > >> >>   1) wait for buffer
> > > > >> >>   2) prepare-access
> > > > >> >>   3)  ... do whatever cpu access to buffer ...
> > > > >> >>   4) finish-access
> > > > >> >>   5) submit buffer for new dma-operation
> > > > >> >>
> > > > >> >
> > > > >> >
> > > > >> > For data flow from CPU to DMA device,
> > > > >> > 1) wait for buffer
> > > > >> > 2) prepare-access (dma_buf_begin_cpu_access)
> > > > >> > 3) cpu access to buffer
> > > > >> >
> > > > >> >
> > > > >> > For data flow from DMA device to CPU
> > > > >> > 1) wait for buffer
> > > > >>
> > > > >> Right, but CPU access isn't asynchronous (from the point of view
> of
> > > > >> the CPU), so there isn't really any wait step at this point.  And
> if
> > > > >> you do want the CPU to be able to signal a fence from userspace
> for
> > > > >> some reason, you probably what something file/fd based so the
> > > > >> refcnting/cleanup when process dies doesn't leave some pending
> DMA
> > > > >> action wedged.  But I don't really see the point of that
> complexity
> > > > >> when the CPU access isn't asynchronous in the first place.
> > > > >>
> > > > >
> > > > > There was my missing comments, please see the below sequence.
> > > > >
> > > > > For data flow from CPU to DMA device and then from DMA device to
> CPU,
> > > > > 1) wait for buffer <- at user side - ioctl(fd,
> DMA_BUF_GET_FENCE, ...)
> > > > > - including prepare-access (dma_buf_begin_cpu_access)
> > > > > 2) cpu access to buffer
> > > > > 3) wait for buffer <- at device driver
> > > > > - but CPU is already accessing the buffer so blocked.
> > > > > 4) signal <- at user side - ioctl(fd, DMA_BUF_PUT_FENCE, ...)
> > > > > 5) the thread, blocked at 3), is waked up by 4).
> > > > > - and then finish-access (dma_buf_end_cpu_access)
> > > >
> > > > right, I understand you can have background threads, etc, in
> > > > userspace.  But there are already plenty of synchronization
> primitives
> > > > that can be used for cpu->cpu synchronization, either within the
> same
> > > > process or between multiple processes.  For cpu access, even if it
> is
> > > > handled by background threads/processes, I think it is better to use
> > > > the traditional pthreads or unix synchronization primitives.  They
> > > > have existed forever, they are well tested, and they work.
> > > >
> > > > So while it seems nice and orthogonal/clean to couple cache and
> > > > synchronization and handle dma->cpu and cpu->cpu and cpu->dma in the
> > > > same generic way, but I think in practice we have to make things
> more
> > > > complex than they otherwise need to be to do this.  Otherwise I
> think
> > > > we'll be having problems with badly behaved or crashing userspace.
> > > >
> > > >
> > > Right, this is very important. I think it's not esay to solve this
> > > issue. Aand at least for ARM based embedded system, such feature is
> useful
> > > to us; coupling cache operation and buffer synchronization. I'd like
> to
> > > collect other opinions and advices to solve this issue.
> >
> > Maybe we have a bit a misunderstanding here. The kernel really should
> take
> > care of sync and cache coherency, and I agree that with the current
> > dma_buf code (and the proposed fences) that part is still a bit hazy.
> But
> > the kernel should not allow userspace to block access to a buffer until
> > userspace is done. It should only sync with any oustanding fences and
> > flush 

[PATCH] drm: fix a use-after-free when GPU acceleration disabled

[Huacai Chen]

When GPU acceleration is disabled, drm_vblank_cleanup() will free the
vblank-related data, such as vblank_refcount, vblank_inmodeset, etc.
But we found that drm_vblank_post_modeset() may be called after the
cleanup, which use vblank_refcount and vblank_inmodeset. And this will
cause a kernel panic.

Fix this by return immediately if dev->num_crtcs is zero. This is the
same thing that drm_vblank_pre_modeset() does.

Call trace of a drm_vblank_post_modeset() after drm_vblank_cleanup():
[   62.628906] [] drm_vblank_post_modeset+0x34/0xb4
[   62.628906] [] atombios_crtc_dpms+0xb4/0x174
[   62.628906] [] atombios_crtc_commit+0x18/0x38
[   62.628906] [] drm_crtc_helper_set_mode+0x304/0x3cc
[   62.628906] [] drm_crtc_helper_set_config+0x6d8/0x988
[   62.628906] [] drm_fb_helper_set_par+0x94/0x104
[   62.628906] [] fbcon_init+0x424/0x57c
[   62.628906] [] visual_init+0xb8/0x118
[   62.628906] [] take_over_console+0x238/0x384
[   62.628906] [] fbcon_takeover+0x7c/0xdc
[   62.628906] [] notifier_call_chain+0x44/0x94
[   62.628906] [] __blocking_notifier_call_chain+0x48/0x68
[   62.628906] [] register_framebuffer+0x228/0x260
[   62.628906] [] drm_fb_helper_single_fb_probe+0x260/0x314
[   62.628906] [] drm_fb_helper_initial_config+0x200/0x234
[   62.628906] [] radeon_fbdev_init+0xd4/0xf4
[   62.628906] [] radeon_modeset_init+0x9bc/0xa18
[   62.628906] [] radeon_driver_load_kms+0xdc/0x12c
[   62.628906] [] drm_get_pci_dev+0x148/0x238
[   62.628906] [] local_pci_probe+0x5c/0xd0
[   62.628906] [] work_for_cpu_fn+0x1c/0x30
[   62.628906] [] process_one_work+0x274/0x3bc
[   62.628906] [] process_scheduled_works+0x24/0x44
[   62.628906] [] worker_thread+0x31c/0x3f4
[   62.628906] [] kthread+0x88/0x90
[   62.628906] [] kernel_thread_helper+0x10/0x18

Signed-off-by: Huacai Chen 
Signed-off-by: Binbin Zhou 
Cc: 
---
 drivers/gpu/drm/drm_irq.c |6 +-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index c798eea..c7a1348 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -981,7 +981,7 @@ EXPORT_SYMBOL(drm_vblank_off);
  */
 void drm_vblank_pre_modeset(struct drm_device *dev, int crtc)
 {
-   /* vblank is not initialized (IRQ not installed ?) */
+   /* vblank is not initialized (IRQ not installed ?), or has been freed */
if (!dev->num_crtcs)
return;
/*
@@ -1003,6 +1003,10 @@ void drm_vblank_post_modeset(struct drm_device *dev, int 
crtc)
 {
unsigned long irqflags;

+   /* vblank is not initialized (IRQ not installed ?), or has been freed */
+   if (!dev->num_crtcs)
+   return;
+
if (dev->vblank_inmodeset[crtc]) {
spin_lock_irqsave(>vbl_lock, irqflags);
dev->vblank_disable_allowed = 1;
-- 
1.7.7.3

[PATCH] drm/radeon: fix typo in cu_per_sh on verde

[alexdeuc...@gmail.com]

From: Alex Deucher 

Should be 5 rather than 2.

Noticed by sroland and glisse on IRC.

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

diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index 113ed9f..34d431e 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -2435,7 +2435,7 @@ static void si_gpu_init(struct radeon_device *rdev)
default:
rdev->config.si.max_shader_engines = 1;
rdev->config.si.max_tile_pipes = 4;
-   rdev->config.si.max_cu_per_sh = 2;
+   rdev->config.si.max_cu_per_sh = 5;
rdev->config.si.max_sh_per_se = 2;
rdev->config.si.max_backends_per_se = 4;
rdev->config.si.max_texture_channel_caches = 4;
-- 
1.7.7.5

[PATCH] drm/radeon: UVD block on SUMO2 is the same as on SUMO

[Alex Deucher]

On Tue, May 21, 2013 at 11:14 AM, Christian K?nig
 wrote:
> From: Christian K?nig 
>
> The chip id for SUMO2 isn't used.
>
> Signed-off-by: Christian K?nig 

Applied.  thanks!

Alex

> ---
>  drivers/gpu/drm/radeon/rv770.c |4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
> index 83f612a..3fc2985 100644
> --- a/drivers/gpu/drm/radeon/rv770.c
> +++ b/drivers/gpu/drm/radeon/rv770.c
> @@ -862,10 +862,8 @@ int rv770_uvd_resume(struct radeon_device *rdev)
> chip_id = 0x010b;
> break;
> case CHIP_SUMO:
> -   chip_id = 0x010c;
> -   break;
> case CHIP_SUMO2:
> -   chip_id = 0x010d;
> +   chip_id = 0x010c;
> break;
> case CHIP_PALM:
> chip_id = 0x010e;
> --
> 1.7.9.5
>

[PATCH] drm/exynos: exynos_hdmi: Pass correct pointer to free_irq()

[Inki Dae]

2013/5/21 Lars-Peter Clausen 

> free_irq() expects the same pointer that was passed to
> request_threaded_irq(),
> otherwise the IRQ is not freed.
>
> The issue was found using the following coccinelle script:
>
> 
> @r1@
> type T;
> T devid;
> @@
> request_threaded_irq(..., devid)
>
> @r2@
> type r1.T;
> T devid;
> position p;
> @@
> free_irq at p(..., devid)
>
> @@
> position p != r2.p;
> @@
> *free_irq at p(...)
> 
>
> Signed-off-by: Lars-Peter Clausen 
> ---
>  drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index bbfc384..7e99853 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -2082,7 +2082,7 @@ static int hdmi_remove(struct platform_device *pdev)
>
> pm_runtime_disable(dev);
>
> -   free_irq(hdata->irq, hdata);
> +   free_irq(hdata->irq, ctx);
>
>
It's better to use devm_reqeust_irq instead. Anyway that was a bug. Applied.

Thanks,
Inki Dae


>
> /* hdmiphy i2c driver */
> --
> 1.8.0
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130521/b781136c/attachment.html>

[Bug 64819] GPU fault detected flood at A8-5600K Trinity 7560D

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

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

--- Comment #1 from Alex Deucher  ---
What version of mesa are you using?  This might be a duplicate of bug 62959. 
Make sure your kernel has this patch:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=466476dfdcafbb4286ffa232a3a792731b9dc852

-- 
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/20130521/b5dda591/attachment.html>

[PATCH] drm/exynos: exynos_hdmi: Pass correct pointer to free_irq()

[김승우]

Good point,

On 2013? 05? 21? 02:32, Lars-Peter Clausen wrote:
> free_irq() expects the same pointer that was passed to request_threaded_irq(),
> otherwise the IRQ is not freed.
> 
> The issue was found using the following coccinelle script:
> 
> 
> @r1@
> type T;
> T devid;
> @@
> request_threaded_irq(..., devid)
> 
> @r2@
> type r1.T;
> T devid;
> position p;
> @@
> free_irq at p(..., devid)
> 
> @@
> position p != r2.p;
> @@
> *free_irq at p(...)
> 
> 
> Signed-off-by: Lars-Peter Clausen 

Acked-by: Seung-Woo Kim 

> ---
>  drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index bbfc384..7e99853 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -2082,7 +2082,7 @@ static int hdmi_remove(struct platform_device *pdev)
>  
>   pm_runtime_disable(dev);
>  
> - free_irq(hdata->irq, hdata);
> + free_irq(hdata->irq, ctx);
>  
>  
>   /* hdmiphy i2c driver */
> 

-- 
Seung-Woo Kim
Samsung Software R Center
--

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

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/intel_dp.c between commit 657445fe8660 ("Revert
"drm/i915: revert eDP bpp clamping code changes"") from Linus' tree and
commits c6bb353815c3 ("drm/i915: move dp clock computations to
encoder->compute_config"), af13188a1a66 ("drm/i915: force bpp for eDP
panels") and 52541e30339d ("drm/i915: allow high-bpc modes on DP") from
the drm-intel tree.

I fixed it up (see below and I used the latter two commits instead of the
one from Linus' tree) and can carry the fix as necessary (no action is
required).

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

diff --cc drivers/gpu/drm/i915/intel_dp.c
index 3d704b7,2bb4009..000
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@@ -755,6 -782,10 +783,8 @@@ found
   target_clock, adjusted_mode->clock,
   _config->dp_m_n);

 -  pipe_config->pipe_bpp = bpp;
 -
+   intel_dp_set_clock(encoder, pipe_config, intel_dp->link_bw);
+ 
return true;
  }

@@@ -1379,8 -1400,15 +1399,16 @@@ static void intel_enable_dp(struct inte
ironlake_edp_panel_on(intel_dp);
ironlake_edp_panel_vdd_off(intel_dp, true);
intel_dp_complete_link_train(intel_dp);
 +  intel_dp_stop_link_train(intel_dp);
ironlake_edp_backlight_on(intel_dp);
+ 
+   if (IS_VALLEYVIEW(dev)) {
+   struct intel_digital_port *dport =
+   enc_to_dig_port(>base);
+   int channel = vlv_dport_to_channel(dport);
+ 
+   vlv_wait_port_ready(dev_priv, channel);
+   }
  }

  static void intel_pre_enable_dp(struct intel_encoder *encoder)
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130521/6de3a5b5/attachment.pgp>

[PATCH] drm/exynos: wait for the completion of pending page flip

[Stéphane Marchesin]

On Tue, May 21, 2013 at 1:08 AM, Inki Dae  wrote:
> This patch fixes the issue that drm_vblank_get() is failed.
>
> The issus occurs when next page flip request is tried
> if previous page flip event wasn't completed yet and then
> dpms became off.
>
> So this patch make sure that page flip event is completed
> before dpms goes to off.

Hi,

This patch is a squash of the two following patches from the Chrome OS
tree with the KDS bits removed and the dpms off bit added:

http://git.chromium.org/gitweb/?p=chromiumos/third_party/kernel-next.git;a=commitdiff;h=2e77cd4e423967862ca01b1af82aa8b5b7429fc4;hp=aba002da4c6e5efec4d43e1ce33930a79269349a
http://git.chromium.org/gitweb/?p=chromiumos/third_party/kernel-next.git;a=commitdiff;h=b4ec8bfa750ef43a43c2da746c8afdbb51002882;hp=4f28b9a75c928f229443d7c6c3163159ceb6903a

Please keep proper attribution.

>
> Signed-off-by: Inki Dae 
> Signed-off-by: Kyungmin Park 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_crtc.c |   16 
>  1 files changed, 16 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> index e8894bc..69a77e9 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> @@ -48,6 +48,8 @@ struct exynos_drm_crtc {
> unsigned intpipe;
> unsigned intdpms;
> enum exynos_crtc_mode   mode;
> +   wait_queue_head_t   pending_flip_queue;
> +   atomic_tpending_flip;
>  };
>
>  static void exynos_drm_crtc_dpms(struct drm_crtc *crtc, int mode)
> @@ -61,6 +63,13 @@ static void exynos_drm_crtc_dpms(struct drm_crtc *crtc, 
> int mode)
> return;
> }
>
> +   if (mode > DRM_MODE_DPMS_ON) {
> +   /* wait for the completion of page flip. */
> +   wait_event(exynos_crtc->pending_flip_queue,
> +   atomic_read(_crtc->pending_flip) == 0);
> +   drm_vblank_off(crtc->dev, exynos_crtc->pipe);

You should be using vblank_put/get.

St?phane

> +   }
> +
> exynos_drm_fn_encoder(crtc, , exynos_drm_encoder_crtc_dpms);
> exynos_crtc->dpms = mode;
>  }
> @@ -225,6 +234,7 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc 
> *crtc,
> spin_lock_irq(>event_lock);
> list_add_tail(>base.link,
> _priv->pageflip_event_list);
> +   atomic_set(_crtc->pending_flip, 1);
> spin_unlock_irq(>event_lock);
>
> crtc->fb = fb;
> @@ -344,6 +354,8 @@ int exynos_drm_crtc_create(struct drm_device *dev, 
> unsigned int nr)
>
> exynos_crtc->pipe = nr;
> exynos_crtc->dpms = DRM_MODE_DPMS_OFF;
> +   init_waitqueue_head(_crtc->pending_flip_queue);
> +   atomic_set(_crtc->pending_flip, 0);
> exynos_crtc->plane = exynos_plane_init(dev, 1 << nr, true);
> if (!exynos_crtc->plane) {
> kfree(exynos_crtc);
> @@ -398,6 +410,8 @@ void exynos_drm_crtc_finish_pageflip(struct drm_device 
> *dev, int crtc)
>  {
> struct exynos_drm_private *dev_priv = dev->dev_private;
> struct drm_pending_vblank_event *e, *t;
> +   struct drm_crtc *drm_crtc = dev_priv->crtc[crtc];
> +   struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(drm_crtc);
> struct timeval now;
> unsigned long flags;
>
> @@ -419,6 +433,8 @@ void exynos_drm_crtc_finish_pageflip(struct drm_device 
> *dev, int crtc)
> list_move_tail(>base.link, >base.file_priv->event_list);
> wake_up_interruptible(>base.file_priv->event_wait);
> drm_vblank_put(dev, crtc);
> +   atomic_set(_crtc->pending_flip, 0);
> +   wake_up(_crtc->pending_flip_queue);
> }
>
> spin_unlock_irqrestore(>event_lock, flags);
> --
> 1.7.5.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 44851] resume to black screen

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

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





--- Comment #11 from Peter   2013-05-21 10:15:05 ---
Still on iMac, installed fedora 18 on partition previously used by Arch (would
boot using KMS into black vts). fedora using kernel 3.6. Behaved like Arch did
previously; had to use kernel option 'nomodeset' to get any vt screens and that
stopped radeon module from being loaded by X 
(Xorg.0.log had: '[KMS] drm report modesetting isn't supported' and
this was followed by 'No screens found')

Now upgraded fedora to use kernel 3.9.2 and, as with Arch, get black vts even
if 'nomodeset' on kernel boot line.

The current kernel 3.9.2 is of no use on my system; I have no way to boot it
and run vt screens. Others who might need nomodeset may also be affected.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[PATCH] drm: fix a use-after-free when GPU acceleration disabled

[Michel Dänzer]

On Die, 2013-05-21 at 14:23 +0800, Huacai Chen wrote:
> When GPU acceleration is disabled, drm_vblank_cleanup() will free the
> vblank-related data, such as vblank_refcount, vblank_inmodeset, etc.
> But we found that drm_vblank_post_modeset() may be called after the
> cleanup, which use vblank_refcount and vblank_inmodeset. And this will
> cause a kernel panic.
> 
> Fix this by return immediately if dev->num_crtcs is zero. This is the
> same thing that drm_vblank_pre_modeset() does.
> 
> Call trace of a drm_vblank_post_modeset() after drm_vblank_cleanup():
> [   62.628906] [] drm_vblank_post_modeset+0x34/0xb4
> [   62.628906] [] atombios_crtc_dpms+0xb4/0x174
> [   62.628906] [] atombios_crtc_commit+0x18/0x38
> [   62.628906] [] drm_crtc_helper_set_mode+0x304/0x3cc
> [   62.628906] [] drm_crtc_helper_set_config+0x6d8/0x988
> [   62.628906] [] drm_fb_helper_set_par+0x94/0x104
> [   62.628906] [] fbcon_init+0x424/0x57c
> [   62.628906] [] visual_init+0xb8/0x118
> [   62.628906] [] take_over_console+0x238/0x384
> [   62.628906] [] fbcon_takeover+0x7c/0xdc
> [   62.628906] [] notifier_call_chain+0x44/0x94
> [   62.628906] [] __blocking_notifier_call_chain+0x48/0x68
> [   62.628906] [] register_framebuffer+0x228/0x260
> [   62.628906] [] drm_fb_helper_single_fb_probe+0x260/0x314
> [   62.628906] [] drm_fb_helper_initial_config+0x200/0x234
> [   62.628906] [] radeon_fbdev_init+0xd4/0xf4
> [   62.628906] [] radeon_modeset_init+0x9bc/0xa18
> [   62.628906] [] radeon_driver_load_kms+0xdc/0x12c
> [   62.628906] [] drm_get_pci_dev+0x148/0x238
> [   62.628906] [] local_pci_probe+0x5c/0xd0
> [   62.628906] [] work_for_cpu_fn+0x1c/0x30
> [   62.628906] [] process_one_work+0x274/0x3bc
> [   62.628906] [] process_scheduled_works+0x24/0x44
> [   62.628906] [] worker_thread+0x31c/0x3f4
> [   62.628906] [] kthread+0x88/0x90
> [   62.628906] [] kernel_thread_helper+0x10/0x18
> 
> Signed-off-by: Huacai Chen 
> Signed-off-by: Binbin Zhou 
> Cc: 
> ---
>  drivers/gpu/drm/drm_irq.c |6 +-
>  1 files changed, 5 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index c798eea..c7a1348 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -981,7 +981,7 @@ EXPORT_SYMBOL(drm_vblank_off);
>   */
>  void drm_vblank_pre_modeset(struct drm_device *dev, int crtc)
>  {
> -   /* vblank is not initialized (IRQ not installed ?) */
> +   /* vblank is not initialized (IRQ not installed ?), or has been freed 
> */
> if (!dev->num_crtcs)
> return;
> /*
> @@ -1003,6 +1003,10 @@ void drm_vblank_post_modeset(struct drm_device *dev, 
> int crtc)
>  {
> unsigned long irqflags;
>  
> +   /* vblank is not initialized (IRQ not installed ?), or has been freed 
> */
> +   if (!dev->num_crtcs)
> +   return;
> +
> if (dev->vblank_inmodeset[crtc]) {
> spin_lock_irqsave(>vbl_lock, irqflags);
> dev->vblank_disable_allowed = 1;

The comment changes seem superfluous to me, but either way:

Reviewed-by: Michel D?nzer 


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

Introduce a new helper framework for buffer synchronization

[Daniel Vetter]

On Tue, May 21, 2013 at 04:03:06PM +0900, Inki Dae wrote:
> > - Integration of fence syncing into dma_buf. Imo we should have a
> >   per-attachment mode which decides whether map/unmap (and the new sync)
> >   should wait for fences or whether the driver takes care of syncing
> >   through the new fence framework itself (for direct hw sync).
> 
> I think it's a good idea to have per-attachment mode for buffer sync. But
> I'd like to say we make sure what is the purpose of map
> (dma_buf_map_attachment)first. This interface is used to get a sgt;
> containing pages to physical memory region, and map that region with
> device's iommu table. The important thing is that this interface is called
> just one time when user wants to share an allocated buffer with dma. But cpu
> will try to access the buffer every time as long as it wants. Therefore, we
> need cache control every time cpu and dma access the shared buffer: cache
> clean when cpu goes to dma and cache invalidate when dma goes to cpu. That
> is why I added new interfaces, DMA_BUF_GET_FENCE and DMA_BUF_PUT_FENCE, to
> dma buf framework. Of course, Those are ugly so we need a better way: I just
> wanted to show you that in such way, we can synchronize the shared buffer
> between cpu and dma. By any chance, is there any way that kernel can be
> aware of when cpu accesses the shared buffer or is there any point I didn't
> catch up?

Well dma_buf_map/unmap_attachment should also flush/invalidate any caches,
and with the current dma_buf spec those two functions are the _only_ means
you have to do so. Which strictly means that if you interleave device dma
and cpu acccess you need to unmap/map every time.

Which is obviously horribly inefficient, but a known gap in the dma_buf
interface. Hence why I proposed to add dma_buf_sync_attachment similar to
dma_sync_single_for_device:

/**
 * dma_buf_sync_sg_attachment - sync caches for dma access
 * @attach: dma-buf attachment to sync
 * @sgt: the sg table to sync (returned by dma_buf_map_attachement)
 * @direction: dma direction to sync for
 *
 * This function synchronizes caches for device dma through the given
 * dma-buf attachment when interleaving dma from different devices and the
 * cpu. Other device dma needs to be synced also by calls to this
 * function (or a pair of dma_buf_map/unmap_attachment calls), cpu access
 * needs to be synced with dma_buf_begin/end_cpu_access.
 */
void dma_buf_sync_sg_attachment(struct dma_buf_attachment *attach,
struct sg_table *sgt,
enum dma_data_direction direction)

Note that "sync" here only means to synchronize caches, not wait for any
outstanding fences. This is simply to be consistent with the established
lingo of the dma api. How the dma-buf fences fit into this is imo a
different topic, but my idea is that all the cache coherency barriers
(i.e. dma_buf_map/unmap_attachment, dma_buf_sync_sg_attachment and
dma_buf_begin/end_cpu_access) would automatically block for any attached
fences (i.e. block for write fences when doing read-only access, block for
all fences otherwise).

Then we could do a new dma_buf_attach_flags interface for special cases
(might also be useful for other things, similar to the recently added
flags in the dma api for wc/no-kernel-mapping/...). A new flag like
DMA_BUF_ATTACH_NO_AUTOFENCE would then mean that the driver takes care of all
fencing for this attachment and the dma-buf functions should not do the
automagic fence blocking.

> In Linux kernel, especially embedded system, we had tried to implement
> generic interfaces for buffer management; how to allocate a buffer and how
> to share a buffer. As a result, now we have CMA (Contiguous Memory
> Allocator) for buffer allocation, and we have DMA-BUF for buffer sharing
> between cpu and dma. And then how to synchronize a buffer between cpu and
> dma? I think now it's best time to discuss buffer synchronization mechanism,
> and that is very natural.

I think it's important to differentiate between the two meanings of sync:
- synchronize caches (i.e. cpu cache flushing in most cases)
- and synchronize in-flight dma with fences.

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

[Bug 64819] New: GPU fault detected flood at A8-5600K Trinity 7560D

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

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

  Priority: medium
Bug ID: 64819
  Assignee: dri-devel at lists.freedesktop.org
   Summary: GPU fault detected flood at A8-5600K Trinity 7560D
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: p00hzone at gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Drivers/DRI/Radeon
   Product: Mesa

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

I have exactly similar bug as described at
https://bugs.freedesktop.org/show_bug.cgi?id=59089 with Trinity 7560D at
A8-5600K.

I'm using latest git drivers. As that bug marked as fixed should i claim that
my problem is unrelated and caused by hardware and/or other malfunctions?

My problem consists of NOT log flood only, but the whole machine usually
freezes and nothing except hard reboot can fix this. Problem detects in both
idle and high load mode. The temperature of APU is about 20-40C.

#uname -a
Linux multiseat 3.9.2-1-gpgpu

#lspci | grep VGA
00:01.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Trinity
[Radeon HD 7560D]

-- 
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/20130521/8a4e0ba5/attachment-0001.html>

[Bug 64193] LLVM RV670 regression since R600: Packetize instructions

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

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

Marc Dietrich  changed:

   What|Removed |Added

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

--- Comment #25 from Marc Dietrich  ---
As of today, http://www.ibiblio.org/e-notes/webgl/webgl.htm works again with
firefox. (Chrome has webgl init error, but maybe a chrome bug). So I guess this
was fixed otherwise.

-- 
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/20130521/8857d435/attachment.html>

[Bug 63698] Build error with libdrm in non standard prefix

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

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

Andreas Boll  changed:

   What|Removed |Added

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

--- Comment #2 from Andreas Boll  ---
Fixed by commit e2b985dc0f93a195d984aa7c88669ab67160c6c4

-- 
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/20130521/76f898fb/attachment.html>

[PATCH] drm/nouveau/nv84: Fix HDMI audio regression

[Ben Skeggs]

On Mon, 2013-05-20 at 19:14 +0200, Alexander Stein wrote:
> Code refactoring in commit 8e9e3d2deacc460fbb8a4691140318f6e85e6891
> (drm/nv84/disp: move hdmi control into core) disabled HDMI audio on my
> nv84 by removing too much old code without adding it in the new one.
> This patch adds the missing code within the new code layout resulting in
> HDMI audio working again.
> It should work on any HDMI head, but due to lacking ahrdware I could
> only test the (1st) one.
I'm surprised it ever worked at all actually.  There's additional setup
before nva3 that should've been required, but I've never got around to
reverse-engineering properly.

I'll pick up this patch though if it makes it work for you.

Thanks,
Ben.

> It also might be possible that similar code is needed for nva3, which I
> can't test.
> 
> Signed-off-by: Alexander Stein 
> ---
> This patch should also be added to stable kernels.
> 
>  drivers/gpu/drm/nouveau/core/engine/disp/hdminv84.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/hdminv84.c 
> b/drivers/gpu/drm/nouveau/core/engine/disp/hdminv84.c
> index 0d36bdc..7fdade6 100644
> --- a/drivers/gpu/drm/nouveau/core/engine/disp/hdminv84.c
> +++ b/drivers/gpu/drm/nouveau/core/engine/disp/hdminv84.c
> @@ -55,6 +55,10 @@ nv84_hdmi_ctrl(struct nv50_disp_priv *priv, int head, int 
> or, u32 data)
>   nv_wr32(priv, 0x616510 + hoff, 0x);
>   nv_mask(priv, 0x616500 + hoff, 0x0001, 0x0001);
>  
> + nv_mask(priv, 0x6165d0 + hoff, 0x00070001, 0x00010001); /* SPARE, 
> HW_CTS */
> + nv_mask(priv, 0x616568 + hoff, 0x00010101, 0x); /* ACR_CTRL, ?? 
> */
> + nv_mask(priv, 0x616578 + hoff, 0x8000, 0x8000); /* 
> ACR_0441_ENABLE */
> +
>   /* ??? */
>   nv_mask(priv, 0x61733c, 0x0010, 0x0010); /* RESETF */
>   nv_mask(priv, 0x61733c, 0x1000, 0x1000); /* LOOKUP_EN */

[RFC 0/8] rmk's Dove DRM/TDA19988 Cubox driver

[Jean-Francois Moine]

On Mon, 20 May 2013 16:23:33 -0400
Alex Deucher  wrote:

> > Note also that the generic DRM KMS code assumes cursor support at
> > 64x64, and there's no generic way for a driver at present (that I know
> > of) to inform it of anything different.  
> 
> It shouldn't be too hard to add a new cap for querying the cursor size
> to the drm cap interface.

There was already a patch request for that, but the functions were
surely useless.

Otherwise, you may do a search on "largest cursor:" (xdpyinfo output).
The results are surprising..

-- 
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

[i915] Backlight brighter since 3.9.0

[Jan Hinnerk Stosch]

2013/5/20 Daniel Vetter 

> On Sat, May 18, 2013 at 12:39:14AM +0200, Jan Hinnerk Stosch wrote:
> > Hallo,
> >
> > I hope this is the right place to ask, because I actually don't know
> > whether it is a bug or a feature that I'm experiencing since linux 3.9:
> > When I boot my system the backlight gets extremely bright compared to
> older
> > kernel versions. It is most obvious when I leave X (more a yellow than a
> > black background), but I have the impression, that the colors in X are
> > brighter than usual, too.
> > I used my spare time this afternoon to do a kernel bisect and learned
> that
> > the first "bad" commit is 55bc60db5988c8366751d3d04dd690698a53412c. As I
> > don't have insight or understanding of the code: Is this behaviour
> intended
> > and how could I change it to the old state or is it a bug and should I
> > report it somewhere?
> > My system is as follows:
> > Intel i5-3570k with Intel HD 4000
> > my monitor is connected via HDMI.
> > If you need any more information just tell me.
>
> Yeah, this is a feature. HDMI has (for oddball backwards compat with
> analog TV signals) a special mode which reduces the useable RGB value
> range by chopping off about 10% at the bottom and top end. This results in
> light colors getting brighter and dark colors getting darker.
>
> The above mentioned commit tries (to the best of our knowledge) to
> auto-set the option which most likely fits what the hdmi sink will do with
> the color data. You can either fix this up in the hdmi sink with the
> on-screen menu or by manually setting the "RBG Broadcast" property for the
> relevant hdmi connector to the setting you want.
>
> Cheers, Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
>

Ok, thank you for your detailed explanation.

Regards,
jhs
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130521/524996c3/attachment-0001.html>

[Bug 64810] New: EGL/Gles/Weston give segfault on RADEONSI

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

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

  Priority: medium
Bug ID: 64810
  Assignee: dri-devel at lists.freedesktop.org
   Summary: EGL/Gles/Weston give segfault on RADEONSI
  Severity: enhancement
Classification: Unclassified
OS: Linux (All)
  Reporter: jrch2k10 at gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Drivers/Gallium/radeonsi
   Product: Mesa

Just informing since i can't see it in the TODO[i assume they aren't ready], so
just for the info.

glx and OpenGL works good enough

Hardware
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Cape
Verde XT [Radeon HD 7770 GHz Edition]
Linux localhost 3.10.0-rc1 #1 SMP PREEMPT Sun May 12 11:20:57 VET 2013 x86_64
AMD FX(tm)-6100 Six-Core Processor AuthenticAMD GNU/Linux

Software

mesa/libdrm/glamor/ddx/llvm/wayand/weston all daily git builded

Issue

Egl is not working beyond eglinfo, eglgears and eglscreen_XX segfault
GLES is not working at all, any related command segfaults either es1_ or es2_
Wayland/Weston logically doesn't work either

GDB throws
Program received signal SIGSEGV, Segmentation fault.
0x74346cde in r600_init_query_functions () from
/usr/lib64/egl/egl_gallium.so

-- 
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/20130521/994f6ba2/attachment.html>

[Bug 63935] TURKS [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!

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

0:21:12 lund-macbookpro kernel: input: HDA Intel PCH SPDIF In as
/devices/pci:00/:00:1b.0/sound/card0/input12
May 21 10:21:12 lund-macbookpro kernel: input: HDA Intel PCH Headphone as
/devices/pci:00/:00:1b.0/sound/card0/input13
May 21 10:21:12 lund-macbookpro kernel: input: HDA Intel PCH Line as
/devices/pci:00/:00:1b.0/sound/card0/input14
May 21 10:21:12 lund-macbookpro kernel: [drm] ring test on 0 succeeded in 2
usecs
May 21 10:21:12 lund-macbookpro kernel: [drm] ring test on 3 succeeded in 1
usecs
May 21 10:21:13 lund-macbookpro kernel: [drm] Enabling RC6 states: RC6 on, RC6p
off, RC6pp off
May 21 10:21:13 lund-macbookpro kernel: [drm:r600_uvd_init] *ERROR* UVD not
responding, trying to reset the VCPU!!!
May 21 10:21:14 lund-macbookpro kernel: [drm:r600_uvd_init] *ERROR* UVD not
responding, trying to reset the VCPU!!!
May 21 10:21:16 lund-macbookpro kernel: [drm:r600_uvd_init] *ERROR* UVD not
responding, trying to reset the VCPU!!!
May 21 10:21:17 lund-macbookpro kernel: [drm:r600_uvd_init] *ERROR* UVD not
responding, trying to reset the VCPU!!!
May 21 10:21:18 lund-macbookpro kernel: [drm:r600_uvd_init] *ERROR* UVD not
responding, trying to reset the VCPU!!!
May 21 10:21:19 lund-macbookpro kernel: [drm:r600_uvd_init] *ERROR* UVD not
responding, trying to reset the VCPU!!!
May 21 10:21:20 lund-macbookpro kernel: [drm:r600_uvd_init] *ERROR* UVD not
responding, trying to reset the VCPU!!!
May 21 10:21:21 lund-macbookpro kernel: [drm:r600_uvd_init] *ERROR* UVD not
responding, trying to reset the VCPU!!!
May 21 10:21:22 lund-macbookpro kernel: [drm:r600_uvd_init] *ERROR* UVD not
responding, trying to reset the VCPU!!!
May 21 10:21:23 lund-macbookpro kernel: [drm:r600_uvd_init] *ERROR* UVD not
responding, trying to reset the VCPU!!!
May 21 10:21:23 lund-macbookpro kernel: [drm:r600_uvd_init] *ERROR* UVD not
responding, giving up!!!
May 21 10:21:23 lund-macbookpro kernel: [drm:evergreen_startup] *ERROR* radeon:
error initializing UVD (-1).
May 21 10:21:23 lund-macbookpro kernel: [drm] ib test on ring 0 succeeded in 0
usecs
May 21 10:21:23 lund-macbookpro kernel: [drm] ib test on ring 3 succeeded in 0
usecs
May 21 10:21:23 lund-macbookpro kernel: [drm] radeon atom DIG backlight
initialized

> 2)  Are you using the necessary firmware for your system to allow this new
> support to work?  (Most distributions haven't packaged it yet, so most of us
> have to download the new firmware directly; see comment 2.)

$ md5sum TURKS*
158f8e21ccf228ef063888c4f637fbf0  TURKS_mc.bin
8012e24b187c6b1ba17fa48691c3b048  TURKS_me.bin
25f26ba407a9bb13528b903c617209c8  TURKS_pfp.bin

> 3)  Is your system built around a newer EFI motherboard, or do have a
> traditional non-EFI BIOS?

Apple's EFI.  There is a BIOS compatibility mode, but I'm unable to do gpu
switching in that mode.

> 
> There may still be some question of whether us users are doings something
> wrong -- although I personally have 2 systems that initialize UVD correctly
> and only 1 (EFI) system giving me trouble -- but if you have the firmware
> which enables this new UVD support, then maybe you could offer to do some
> register dumps if Christian or one of the other developers thinks it would
> be helpful to them?

Would this be the same as others have done above?

-- 
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/20130521/aef8b6f1/attachment-0001.html>

[Bug 63935] TURKS [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!

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

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

--- Comment #34 from Dave Witbrodt  ---
(In reply to comment #33)
> As somewhat expected, v3.10-rc2 still has this.
> 
> Has anyone done a bisection to find out which commit causes the corruption?

Austin, this is new support for previously unsupported hardware present on
several generations of AMD GPUs.  My understanding is that it is an unforeseen
problem with initializing the new support on certain kinds of systems.

The developers are not really able to reproduce the problem being reported by
several us.  No (official) kernel has been released yet with this new support,
and we have at least 6 weeks to work on it before the first such kernel will be
released.

Can you tell us a bit about your system?

1)  What kind of hardware are you using -- can you show us the error messages
from you log files?

2)  Are you using the necessary firmware for your system to allow this new
support to work?  (Most distributions haven't packaged it yet, so most of us
have to download the new firmware directly; see comment 2.)

3)  Is your system built around a newer EFI motherboard, or do have a
traditional non-EFI BIOS?

There may still be some question of whether us users are doings something wrong
-- although I personally have 2 systems that initialize UVD correctly and only
1 (EFI) system giving me trouble -- but if you have the firmware which enables
this new UVD support, then maybe you could offer to do some register dumps if
Christian or one of the other developers thinks it would be helpful to them?

-- 
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/20130521/654fc237/attachment.html>

[git pull] drm new AMD radeon hw

[Dave Airlie]

Hi,

Since I know its outside the merge window, but since this is new hw I 
thought I'd try and provoke the new hw exception, it just fills in the 
blanks in the driver for the new AMD sun and hainan chipsets. The pull is 
based on the previous one with the changelog just for the new pieces.

Dave.

The following changes since commit a3f6902672c9fa3868722ef6ab8a7dd9141def6a:

  Merge branch 'drm-fixes-3.10' of git://people.freedesktop.org/~agd5f/linux 
into drm-next (2013-05-21 09:41:33 +1000)

are available in the git repository at:


  git://people.freedesktop.org/~airlied/linux.git drm-radeon-sun-hainan

for you to fetch changes up to cc3e06a57d4314ca0582fcf7d6b56dea5ca11f77:

  Merge branch 'drm-fixes-3.10-sun' of 
git://people.freedesktop.org/~agd5f/linux into drm-next (2013-05-21 09:42:55 
+1000)



Alex Deucher (9):
  drm/radeon: add chip family for Hainan
  drm/radeon: fill in GPU init for Hainan (v2)
  drm/radeon: don't touch DCE or VGA regs on Hainan (v3)
  drm/radeon: fill in ucode loading support for Hainan
  drm/radeon: radeon-asic updates for Hainan
  drm/radeon: track which asics have UVD
  drm/radeon: sun/hainan chips do not have UVD (v2)
  drm/radeon: add golden register settings for Hainan (v2)
  drm/radeon: add Hainan pci ids

Dave Airlie (1):
  Merge branch 'drm-fixes-3.10-sun' of 
git://people.freedesktop.org/~agd5f/linux into drm-next

 drivers/gpu/drm/radeon/evergreen.c |  27 ++-
 drivers/gpu/drm/radeon/radeon.h|   2 +
 drivers/gpu/drm/radeon/radeon_asic.c   |  22 +-
 drivers/gpu/drm/radeon/radeon_bios.c   |  28 +--
 drivers/gpu/drm/radeon/radeon_device.c |   1 +
 drivers/gpu/drm/radeon/radeon_family.h |   1 +
 drivers/gpu/drm/radeon/si.c| 366 ++---
 drivers/gpu/drm/radeon/sid.h   |   1 +
 include/drm/drm_pciids.h   |   6 +
 9 files changed, 362 insertions(+), 92 deletions(-)

[git pull] drm radeon and nouveau fixes

[Dave Airlie]

Hi Linus,

This is just a set of nouveau and radeon fixes, the nouveau ones fix some 
suspend/resume regressions since use of copy engines and some fixes for Z 
compression on some newer chipsets.

I've got another pull request for some new AMD radeon hw that shouldn't 
touch any existing hw support that I'll send after this, its based on this 
one, so pulling it will get this + that.

Dave.

The following changes since commit e9ced8e040ebe40e9953db90acbe7d0b58702ebb:

  drm/radeon: restore nomodeset operation (v2) (2013-05-17 11:47:07 +1000)

are available in the git repository at:

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

for you to fetch changes up to a3f6902672c9fa3868722ef6ab8a7dd9141def6a:

  Merge branch 'drm-fixes-3.10' of git://people.freedesktop.org/~agd5f/linux 
into drm-next (2013-05-21 09:41:33 +1000)



Alex Deucher (1):
  drm/radeon/dce2: use 10khz units for audio dto calculation

Ben Skeggs (9):
  drm/nouveau/bios: fix thinko in ZM_MASK_ADD opcode
  drm/nvc0/ce: disable ce1 on a number of chipsets
  drm/nvc0/ltcg: fix handling of disabled partitions
  drm/nve0/ltcg: poke the partition count into yet another register
  drm/nve0/fifo: prevent races between clients updating playlists
  drm/nvc0/fifo: prevent races between clients updating playlists
  drm/nvc0/fifo: prevent CHAN_TABLE_ERROR:CHANNEL_PENDING on fifo fini
  drm/nv50/fifo: prevent races between clients updating playlists
  drm/nouveau: ensure channels are stopped before saving fences for suspend

Dave Airlie (3):
  drm/nouveau: fix build with nv50->nvc0
  Merge branch 'drm-nouveau-fixes-3.10' of 
git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next
  Merge branch 'drm-fixes-3.10' of 
git://people.freedesktop.org/~agd5f/linux into drm-next

Niels Ole Salscheider (2):
  drm/radeon: Remove superfluous variable
  drm/radeon: Fix VRAM size calculation for VRAM >= 4GB

 drivers/gpu/drm/nouveau/core/engine/device/nvc0.c |  2 --
 drivers/gpu/drm/nouveau/core/engine/fifo/nv50.c   |  2 ++
 drivers/gpu/drm/nouveau/core/engine/fifo/nvc0.c   | 10 +
 drivers/gpu/drm/nouveau/core/engine/fifo/nve0.c   |  3 +++
 drivers/gpu/drm/nouveau/core/subdev/bios/init.c   |  4 ++--
 drivers/gpu/drm/nouveau/core/subdev/ltcg/nvc0.c   | 17 ---
 drivers/gpu/drm/nouveau/nouveau_drm.c | 25 ++-
 drivers/gpu/drm/radeon/atombios_crtc.c|  6 --
 drivers/gpu/drm/radeon/evergreen.c|  4 ++--
 drivers/gpu/drm/radeon/evergreen_hdmi.c   |  7 +++
 drivers/gpu/drm/radeon/r600_hdmi.c|  9 
 drivers/gpu/drm/radeon/radeon_legacy_crtc.c   |  4 
 drivers/gpu/drm/radeon/radeon_mode.h  |  1 -
 drivers/gpu/drm/radeon/radeon_ttm.c   |  2 +-
 drivers/gpu/drm/radeon/si.c   |  4 ++--
 15 files changed, 59 insertions(+), 41 deletions(-)

[Bug 63935] TURKS [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!

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

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

--- Comment #33 from Austin Lund  ---
As somewhat expected, v3.10-rc2 still has this.

Has anyone done a bisection to find out which commit causes the corruption?

-- 
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/20130521/8f28d9e7/attachment-0001.html>

[i915] Backlight brighter since 3.9.0

[Daniel Vetter]

On Sat, May 18, 2013 at 12:39:14AM +0200, Jan Hinnerk Stosch wrote:
> Hallo,
> 
> I hope this is the right place to ask, because I actually don't know
> whether it is a bug or a feature that I'm experiencing since linux 3.9:
> When I boot my system the backlight gets extremely bright compared to older
> kernel versions. It is most obvious when I leave X (more a yellow than a
> black background), but I have the impression, that the colors in X are
> brighter than usual, too.
> I used my spare time this afternoon to do a kernel bisect and learned that
> the first "bad" commit is 55bc60db5988c8366751d3d04dd690698a53412c. As I
> don't have insight or understanding of the code: Is this behaviour intended
> and how could I change it to the old state or is it a bug and should I
> report it somewhere?
> My system is as follows:
> Intel i5-3570k with Intel HD 4000
> my monitor is connected via HDMI.
> If you need any more information just tell me.

Yeah, this is a feature. HDMI has (for oddball backwards compat with
analog TV signals) a special mode which reduces the useable RGB value
range by chopping off about 10% at the bottom and top end. This results in
light colors getting brighter and dark colors getting darker.

The above mentioned commit tries (to the best of our knowledge) to
auto-set the option which most likely fits what the hdmi sink will do with
the color data. You can either fix this up in the hdmi sink with the
on-screen menu or by manually setting the "RBG Broadcast" property for the
relevant hdmi connector to the setting you want.

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

Introduce a new helper framework for buffer synchronization

[Daniel Vetter]

On Mon, May 20, 2013 at 11:13:04PM +0200, Daniel Vetter wrote:
> On Sat, May 18, 2013 at 03:47:43PM +0900, Inki Dae wrote:
> > 2013/5/15 Rob Clark 
> > 
> > > On Wed, May 15, 2013 at 1:19 AM, Inki Dae  wrote:
> > > >
> > > >
> > > >> -Original Message-
> > > >> From: Rob Clark [mailto:robdclark at gmail.com]
> > > >> Sent: Tuesday, May 14, 2013 10:39 PM
> > > >> To: Inki Dae
> > > >> Cc: linux-fbdev; DRI mailing list; Kyungmin Park; myungjoo.ham; 
> > > >> YoungJun
> > > >> Cho; linux-arm-kernel at lists.infradead.org; linux-media at 
> > > >> vger.kernel.org
> > > >> Subject: Re: Introduce a new helper framework for buffer 
> > > >> synchronization
> > > >>
> > > >> On Mon, May 13, 2013 at 10:52 PM, Inki Dae 
> > > wrote:
> > > >> >> well, for cache management, I think it is a better idea.. I didn't
> > > >> >> really catch that this was the motivation from the initial patch, 
> > > >> >> but
> > > >> >> maybe I read it too quickly.  But cache can be decoupled from
> > > >> >> synchronization, because CPU access is not asynchronous.  For
> > > >> >> userspace/CPU access to buffer, you should:
> > > >> >>
> > > >> >>   1) wait for buffer
> > > >> >>   2) prepare-access
> > > >> >>   3)  ... do whatever cpu access to buffer ...
> > > >> >>   4) finish-access
> > > >> >>   5) submit buffer for new dma-operation
> > > >> >>
> > > >> >
> > > >> >
> > > >> > For data flow from CPU to DMA device,
> > > >> > 1) wait for buffer
> > > >> > 2) prepare-access (dma_buf_begin_cpu_access)
> > > >> > 3) cpu access to buffer
> > > >> >
> > > >> >
> > > >> > For data flow from DMA device to CPU
> > > >> > 1) wait for buffer
> > > >>
> > > >> Right, but CPU access isn't asynchronous (from the point of view of
> > > >> the CPU), so there isn't really any wait step at this point.  And if
> > > >> you do want the CPU to be able to signal a fence from userspace for
> > > >> some reason, you probably what something file/fd based so the
> > > >> refcnting/cleanup when process dies doesn't leave some pending DMA
> > > >> action wedged.  But I don't really see the point of that complexity
> > > >> when the CPU access isn't asynchronous in the first place.
> > > >>
> > > >
> > > > There was my missing comments, please see the below sequence.
> > > >
> > > > For data flow from CPU to DMA device and then from DMA device to CPU,
> > > > 1) wait for buffer <- at user side - ioctl(fd, DMA_BUF_GET_FENCE, ...)
> > > > - including prepare-access (dma_buf_begin_cpu_access)
> > > > 2) cpu access to buffer
> > > > 3) wait for buffer <- at device driver
> > > > - but CPU is already accessing the buffer so blocked.
> > > > 4) signal <- at user side - ioctl(fd, DMA_BUF_PUT_FENCE, ...)
> > > > 5) the thread, blocked at 3), is waked up by 4).
> > > > - and then finish-access (dma_buf_end_cpu_access)
> > >
> > > right, I understand you can have background threads, etc, in
> > > userspace.  But there are already plenty of synchronization primitives
> > > that can be used for cpu->cpu synchronization, either within the same
> > > process or between multiple processes.  For cpu access, even if it is
> > > handled by background threads/processes, I think it is better to use
> > > the traditional pthreads or unix synchronization primitives.  They
> > > have existed forever, they are well tested, and they work.
> > >
> > > So while it seems nice and orthogonal/clean to couple cache and
> > > synchronization and handle dma->cpu and cpu->cpu and cpu->dma in the
> > > same generic way, but I think in practice we have to make things more
> > > complex than they otherwise need to be to do this.  Otherwise I think
> > > we'll be having problems with badly behaved or crashing userspace.
> > >
> > >
> > Right, this is very important. I think it's not esay to solve this
> > issue. Aand at least for ARM based embedded system, such feature is useful
> > to us; coupling cache operation and buffer synchronization. I'd like to
> > collect other opinions and advices to solve this issue.
> 
> Maybe we have a bit a misunderstanding here. The kernel really should take
> care of sync and cache coherency, and I agree that with the current
> dma_buf code (and the proposed fences) that part is still a bit hazy. But
> the kernel should not allow userspace to block access to a buffer until
> userspace is done. It should only sync with any oustanding fences and
> flush buffers before that userspace access happens.
> 
> Then the kernel would again flush caches on the next dma access (which
> hopefully is only started once userspace completed access). Atm this isn't
> possible in an efficient way since the dma_buf api only exposes map/unmap
> attachment and not a function to just sync an existing mapping like
> dma_sync_single_for_device. I guess we should add a
> dma_buf_sync_attachment interface for that - we already have range-based
> cpu sync support with the begin/end_cpu_access interfaces.

I think my mail here was a bit unclear, so let me try 

Introduce a new helper framework for buffer synchronization

[Daniel Vetter]

On Sat, May 18, 2013 at 03:47:43PM +0900, Inki Dae wrote:
> 2013/5/15 Rob Clark 
> 
> > On Wed, May 15, 2013 at 1:19 AM, Inki Dae  wrote:
> > >
> > >
> > >> -Original Message-
> > >> From: Rob Clark [mailto:robdclark at gmail.com]
> > >> Sent: Tuesday, May 14, 2013 10:39 PM
> > >> To: Inki Dae
> > >> Cc: linux-fbdev; DRI mailing list; Kyungmin Park; myungjoo.ham; YoungJun
> > >> Cho; linux-arm-kernel at lists.infradead.org; linux-media at 
> > >> vger.kernel.org
> > >> Subject: Re: Introduce a new helper framework for buffer synchronization
> > >>
> > >> On Mon, May 13, 2013 at 10:52 PM, Inki Dae 
> > wrote:
> > >> >> well, for cache management, I think it is a better idea.. I didn't
> > >> >> really catch that this was the motivation from the initial patch, but
> > >> >> maybe I read it too quickly.  But cache can be decoupled from
> > >> >> synchronization, because CPU access is not asynchronous.  For
> > >> >> userspace/CPU access to buffer, you should:
> > >> >>
> > >> >>   1) wait for buffer
> > >> >>   2) prepare-access
> > >> >>   3)  ... do whatever cpu access to buffer ...
> > >> >>   4) finish-access
> > >> >>   5) submit buffer for new dma-operation
> > >> >>
> > >> >
> > >> >
> > >> > For data flow from CPU to DMA device,
> > >> > 1) wait for buffer
> > >> > 2) prepare-access (dma_buf_begin_cpu_access)
> > >> > 3) cpu access to buffer
> > >> >
> > >> >
> > >> > For data flow from DMA device to CPU
> > >> > 1) wait for buffer
> > >>
> > >> Right, but CPU access isn't asynchronous (from the point of view of
> > >> the CPU), so there isn't really any wait step at this point.  And if
> > >> you do want the CPU to be able to signal a fence from userspace for
> > >> some reason, you probably what something file/fd based so the
> > >> refcnting/cleanup when process dies doesn't leave some pending DMA
> > >> action wedged.  But I don't really see the point of that complexity
> > >> when the CPU access isn't asynchronous in the first place.
> > >>
> > >
> > > There was my missing comments, please see the below sequence.
> > >
> > > For data flow from CPU to DMA device and then from DMA device to CPU,
> > > 1) wait for buffer <- at user side - ioctl(fd, DMA_BUF_GET_FENCE, ...)
> > > - including prepare-access (dma_buf_begin_cpu_access)
> > > 2) cpu access to buffer
> > > 3) wait for buffer <- at device driver
> > > - but CPU is already accessing the buffer so blocked.
> > > 4) signal <- at user side - ioctl(fd, DMA_BUF_PUT_FENCE, ...)
> > > 5) the thread, blocked at 3), is waked up by 4).
> > > - and then finish-access (dma_buf_end_cpu_access)
> >
> > right, I understand you can have background threads, etc, in
> > userspace.  But there are already plenty of synchronization primitives
> > that can be used for cpu->cpu synchronization, either within the same
> > process or between multiple processes.  For cpu access, even if it is
> > handled by background threads/processes, I think it is better to use
> > the traditional pthreads or unix synchronization primitives.  They
> > have existed forever, they are well tested, and they work.
> >
> > So while it seems nice and orthogonal/clean to couple cache and
> > synchronization and handle dma->cpu and cpu->cpu and cpu->dma in the
> > same generic way, but I think in practice we have to make things more
> > complex than they otherwise need to be to do this.  Otherwise I think
> > we'll be having problems with badly behaved or crashing userspace.
> >
> >
> Right, this is very important. I think it's not esay to solve this
> issue. Aand at least for ARM based embedded system, such feature is useful
> to us; coupling cache operation and buffer synchronization. I'd like to
> collect other opinions and advices to solve this issue.

Maybe we have a bit a misunderstanding here. The kernel really should take
care of sync and cache coherency, and I agree that with the current
dma_buf code (and the proposed fences) that part is still a bit hazy. But
the kernel should not allow userspace to block access to a buffer until
userspace is done. It should only sync with any oustanding fences and
flush buffers before that userspace access happens.

Then the kernel would again flush caches on the next dma access (which
hopefully is only started once userspace completed access). Atm this isn't
possible in an efficient way since the dma_buf api only exposes map/unmap
attachment and not a function to just sync an existing mapping like
dma_sync_single_for_device. I guess we should add a
dma_buf_sync_attachment interface for that - we already have range-based
cpu sync support with the begin/end_cpu_access interfaces.

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

[Bug 64649] Anomaly 2 (Steam) exits with GLX_EXT_swap_control not supported, unable to set vertical sync

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

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

romulasry at gmail.com changed:

   What|Removed |Added

   Assignee|mesa-dev at lists.freedesktop. |dri-devel at 
lists.freedesktop
   |org |.org
  Component|GLX |Drivers/Gallium/r600

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

[PATCH] drm: fix a use-after-free when GPU acceleration disabled

[Huacai Chen]

When GPU acceleration is disabled, drm_vblank_cleanup() will free the
vblank-related data, such as vblank_refcount, vblank_inmodeset, etc.
But we found that drm_vblank_post_modeset() may be called after the
cleanup, which use vblank_refcount and vblank_inmodeset. And this will
cause a kernel panic.

Fix this by return immediately if dev-num_crtcs is zero. This is the
same thing that drm_vblank_pre_modeset() does.

Call trace of a drm_vblank_post_modeset() after drm_vblank_cleanup():
[   62.628906] [804868d0] drm_vblank_post_modeset+0x34/0xb4
[   62.628906] [804c7008] atombios_crtc_dpms+0xb4/0x174
[   62.628906] [804c70e0] atombios_crtc_commit+0x18/0x38
[   62.628906] [8047f038] drm_crtc_helper_set_mode+0x304/0x3cc
[   62.628906] [8047f92c] drm_crtc_helper_set_config+0x6d8/0x988
[   62.628906] [8047dd40] drm_fb_helper_set_par+0x94/0x104
[   62.628906] [80439d14] fbcon_init+0x424/0x57c
[   62.628906] [8046a638] visual_init+0xb8/0x118
[   62.628906] [8046b9f8] take_over_console+0x238/0x384
[   62.628906] [80436df8] fbcon_takeover+0x7c/0xdc
[   62.628906] [8024fa20] notifier_call_chain+0x44/0x94
[   62.628906] [8024fcbc] __blocking_notifier_call_chain+0x48/0x68
[   62.628906] [8042d990] register_framebuffer+0x228/0x260
[   62.628906] [8047e010] drm_fb_helper_single_fb_probe+0x260/0x314
[   62.628906] [8047e2c4] drm_fb_helper_initial_config+0x200/0x234
[   62.628906] [804e5560] radeon_fbdev_init+0xd4/0xf4
[   62.628906] [804e0e08] radeon_modeset_init+0x9bc/0xa18
[   62.628906] [804bfc14] radeon_driver_load_kms+0xdc/0x12c
[   62.628906] [8048b548] drm_get_pci_dev+0x148/0x238
[   62.628906] [80423564] local_pci_probe+0x5c/0xd0
[   62.628906] [80241ac4] work_for_cpu_fn+0x1c/0x30
[   62.628906] [802427c8] process_one_work+0x274/0x3bc
[   62.628906] [80242934] process_scheduled_works+0x24/0x44
[   62.628906] [8024515c] worker_thread+0x31c/0x3f4
[   62.628906] [802497a8] kthread+0x88/0x90
[   62.628906] [80206794] kernel_thread_helper+0x10/0x18

Signed-off-by: Huacai Chen che...@lemote.com
Signed-off-by: Binbin Zhou zho...@lemote.com
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/drm_irq.c |6 +-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index c798eea..c7a1348 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -981,7 +981,7 @@ EXPORT_SYMBOL(drm_vblank_off);
  */
 void drm_vblank_pre_modeset(struct drm_device *dev, int crtc)
 {
-   /* vblank is not initialized (IRQ not installed ?) */
+   /* vblank is not initialized (IRQ not installed ?), or has been freed */
if (!dev-num_crtcs)
return;
/*
@@ -1003,6 +1003,10 @@ void drm_vblank_post_modeset(struct drm_device *dev, int 
crtc)
 {
unsigned long irqflags;
 
+   /* vblank is not initialized (IRQ not installed ?), or has been freed */
+   if (!dev-num_crtcs)
+   return;
+
if (dev-vblank_inmodeset[crtc]) {
spin_lock_irqsave(dev-vbl_lock, irqflags);
dev-vblank_disable_allowed = 1;
-- 
1.7.7.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [i915] Backlight brighter since 3.9.0

[Jan Hinnerk Stosch]

2013/5/20 Daniel Vetter dan...@ffwll.ch

 On Sat, May 18, 2013 at 12:39:14AM +0200, Jan Hinnerk Stosch wrote:
  Hallo,
 
  I hope this is the right place to ask, because I actually don't know
  whether it is a bug or a feature that I'm experiencing since linux 3.9:
  When I boot my system the backlight gets extremely bright compared to
 older
  kernel versions. It is most obvious when I leave X (more a yellow than a
  black background), but I have the impression, that the colors in X are
  brighter than usual, too.
  I used my spare time this afternoon to do a kernel bisect and learned
 that
  the first bad commit is 55bc60db5988c8366751d3d04dd690698a53412c. As I
  don't have insight or understanding of the code: Is this behaviour
 intended
  and how could I change it to the old state or is it a bug and should I
  report it somewhere?
  My system is as follows:
  Intel i5-3570k with Intel HD 4000
  my monitor is connected via HDMI.
  If you need any more information just tell me.

 Yeah, this is a feature. HDMI has (for oddball backwards compat with
 analog TV signals) a special mode which reduces the useable RGB value
 range by chopping off about 10% at the bottom and top end. This results in
 light colors getting brighter and dark colors getting darker.

 The above mentioned commit tries (to the best of our knowledge) to
 auto-set the option which most likely fits what the hdmi sink will do with
 the color data. You can either fix this up in the hdmi sink with the
 on-screen menu or by manually setting the RBG Broadcast property for the
 relevant hdmi connector to the setting you want.

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


Ok, thank you for your detailed explanation.

Regards,
jhs
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: Introduce a new helper framework for buffer synchronization

[Inki Dae]

 -Original Message-
 From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
 Vetter
 Sent: Tuesday, May 21, 2013 6:31 AM
 To: Inki Dae
 Cc: Rob Clark; linux-fbdev; DRI mailing list; Kyungmin Park; myungjoo.ham;
 YoungJun Cho; linux-arm-ker...@lists.infradead.org; linux-
 me...@vger.kernel.org
 Subject: Re: Introduce a new helper framework for buffer synchronization
 
 On Mon, May 20, 2013 at 11:13:04PM +0200, Daniel Vetter wrote:
  On Sat, May 18, 2013 at 03:47:43PM +0900, Inki Dae wrote:
   2013/5/15 Rob Clark robdcl...@gmail.com
  
On Wed, May 15, 2013 at 1:19 AM, Inki Dae inki@samsung.com
 wrote:


 -Original Message-
 From: Rob Clark [mailto:robdcl...@gmail.com]
 Sent: Tuesday, May 14, 2013 10:39 PM
 To: Inki Dae
 Cc: linux-fbdev; DRI mailing list; Kyungmin Park; myungjoo.ham;
 YoungJun
 Cho; linux-arm-ker...@lists.infradead.org; linux-
 me...@vger.kernel.org
 Subject: Re: Introduce a new helper framework for buffer
 synchronization

 On Mon, May 13, 2013 at 10:52 PM, Inki Dae inki@samsung.com
wrote:
  well, for cache management, I think it is a better idea.. I
 didn't
  really catch that this was the motivation from the initial
 patch, but
  maybe I read it too quickly.  But cache can be decoupled from
  synchronization, because CPU access is not asynchronous.  For
  userspace/CPU access to buffer, you should:
 
1) wait for buffer
2) prepare-access
3)  ... do whatever cpu access to buffer ...
4) finish-access
5) submit buffer for new dma-operation
 
 
 
  For data flow from CPU to DMA device,
  1) wait for buffer
  2) prepare-access (dma_buf_begin_cpu_access)
  3) cpu access to buffer
 
 
  For data flow from DMA device to CPU
  1) wait for buffer

 Right, but CPU access isn't asynchronous (from the point of view
 of
 the CPU), so there isn't really any wait step at this point.  And
 if
 you do want the CPU to be able to signal a fence from userspace
 for
 some reason, you probably what something file/fd based so the
 refcnting/cleanup when process dies doesn't leave some pending
 DMA
 action wedged.  But I don't really see the point of that
 complexity
 when the CPU access isn't asynchronous in the first place.


 There was my missing comments, please see the below sequence.

 For data flow from CPU to DMA device and then from DMA device to
 CPU,
 1) wait for buffer - at user side - ioctl(fd,
 DMA_BUF_GET_FENCE, ...)
 - including prepare-access (dma_buf_begin_cpu_access)
 2) cpu access to buffer
 3) wait for buffer - at device driver
 - but CPU is already accessing the buffer so blocked.
 4) signal - at user side - ioctl(fd, DMA_BUF_PUT_FENCE, ...)
 5) the thread, blocked at 3), is waked up by 4).
 - and then finish-access (dma_buf_end_cpu_access)
   
right, I understand you can have background threads, etc, in
userspace.  But there are already plenty of synchronization
 primitives
that can be used for cpu-cpu synchronization, either within the
 same
process or between multiple processes.  For cpu access, even if it
 is
handled by background threads/processes, I think it is better to use
the traditional pthreads or unix synchronization primitives.  They
have existed forever, they are well tested, and they work.
   
So while it seems nice and orthogonal/clean to couple cache and
synchronization and handle dma-cpu and cpu-cpu and cpu-dma in the
same generic way, but I think in practice we have to make things
 more
complex than they otherwise need to be to do this.  Otherwise I
 think
we'll be having problems with badly behaved or crashing userspace.
   
   
   Right, this is very important. I think it's not esay to solve this
   issue. Aand at least for ARM based embedded system, such feature is
 useful
   to us; coupling cache operation and buffer synchronization. I'd like
 to
   collect other opinions and advices to solve this issue.
 
  Maybe we have a bit a misunderstanding here. The kernel really should
 take
  care of sync and cache coherency, and I agree that with the current
  dma_buf code (and the proposed fences) that part is still a bit hazy.
 But
  the kernel should not allow userspace to block access to a buffer until
  userspace is done. It should only sync with any oustanding fences and
  flush buffers before that userspace access happens.
 
  Then the kernel would again flush caches on the next dma access (which
  hopefully is only started once userspace completed access). Atm this
 isn't
  possible in an efficient way since the dma_buf api only exposes
 map/unmap
  attachment and not a function to just sync an existing mapping like
  dma_sync_single_for_device. I guess we should add a
  dma_buf_sync_attachment interface for that - 

Re: Introduce a new helper framework for buffer synchronization

[Daniel Vetter]

On Tue, May 21, 2013 at 04:03:06PM +0900, Inki Dae wrote:
  - Integration of fence syncing into dma_buf. Imo we should have a
per-attachment mode which decides whether map/unmap (and the new sync)
should wait for fences or whether the driver takes care of syncing
through the new fence framework itself (for direct hw sync).
 
 I think it's a good idea to have per-attachment mode for buffer sync. But
 I'd like to say we make sure what is the purpose of map
 (dma_buf_map_attachment)first. This interface is used to get a sgt;
 containing pages to physical memory region, and map that region with
 device's iommu table. The important thing is that this interface is called
 just one time when user wants to share an allocated buffer with dma. But cpu
 will try to access the buffer every time as long as it wants. Therefore, we
 need cache control every time cpu and dma access the shared buffer: cache
 clean when cpu goes to dma and cache invalidate when dma goes to cpu. That
 is why I added new interfaces, DMA_BUF_GET_FENCE and DMA_BUF_PUT_FENCE, to
 dma buf framework. Of course, Those are ugly so we need a better way: I just
 wanted to show you that in such way, we can synchronize the shared buffer
 between cpu and dma. By any chance, is there any way that kernel can be
 aware of when cpu accesses the shared buffer or is there any point I didn't
 catch up?

Well dma_buf_map/unmap_attachment should also flush/invalidate any caches,
and with the current dma_buf spec those two functions are the _only_ means
you have to do so. Which strictly means that if you interleave device dma
and cpu acccess you need to unmap/map every time.

Which is obviously horribly inefficient, but a known gap in the dma_buf
interface. Hence why I proposed to add dma_buf_sync_attachment similar to
dma_sync_single_for_device:

/**
 * dma_buf_sync_sg_attachment - sync caches for dma access
 * @attach: dma-buf attachment to sync
 * @sgt: the sg table to sync (returned by dma_buf_map_attachement)
 * @direction: dma direction to sync for
 *
 * This function synchronizes caches for device dma through the given
 * dma-buf attachment when interleaving dma from different devices and the
 * cpu. Other device dma needs to be synced also by calls to this
 * function (or a pair of dma_buf_map/unmap_attachment calls), cpu access
 * needs to be synced with dma_buf_begin/end_cpu_access.
 */
void dma_buf_sync_sg_attachment(struct dma_buf_attachment *attach,
struct sg_table *sgt,
enum dma_data_direction direction)

Note that sync here only means to synchronize caches, not wait for any
outstanding fences. This is simply to be consistent with the established
lingo of the dma api. How the dma-buf fences fit into this is imo a
different topic, but my idea is that all the cache coherency barriers
(i.e. dma_buf_map/unmap_attachment, dma_buf_sync_sg_attachment and
dma_buf_begin/end_cpu_access) would automatically block for any attached
fences (i.e. block for write fences when doing read-only access, block for
all fences otherwise).

Then we could do a new dma_buf_attach_flags interface for special cases
(might also be useful for other things, similar to the recently added
flags in the dma api for wc/no-kernel-mapping/...). A new flag like
DMA_BUF_ATTACH_NO_AUTOFENCE would then mean that the driver takes care of all
fencing for this attachment and the dma-buf functions should not do the
automagic fence blocking.

 In Linux kernel, especially embedded system, we had tried to implement
 generic interfaces for buffer management; how to allocate a buffer and how
 to share a buffer. As a result, now we have CMA (Contiguous Memory
 Allocator) for buffer allocation, and we have DMA-BUF for buffer sharing
 between cpu and dma. And then how to synchronize a buffer between cpu and
 dma? I think now it's best time to discuss buffer synchronization mechanism,
 and that is very natural.

I think it's important to differentiate between the two meanings of sync:
- synchronize caches (i.e. cpu cache flushing in most cases)
- and synchronize in-flight dma with fences.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: fix a use-after-free when GPU acceleration disabled

[Michel Dänzer]

On Die, 2013-05-21 at 14:23 +0800, Huacai Chen wrote:
 When GPU acceleration is disabled, drm_vblank_cleanup() will free the
 vblank-related data, such as vblank_refcount, vblank_inmodeset, etc.
 But we found that drm_vblank_post_modeset() may be called after the
 cleanup, which use vblank_refcount and vblank_inmodeset. And this will
 cause a kernel panic.
 
 Fix this by return immediately if dev-num_crtcs is zero. This is the
 same thing that drm_vblank_pre_modeset() does.
 
 Call trace of a drm_vblank_post_modeset() after drm_vblank_cleanup():
 [   62.628906] [804868d0] drm_vblank_post_modeset+0x34/0xb4
 [   62.628906] [804c7008] atombios_crtc_dpms+0xb4/0x174
 [   62.628906] [804c70e0] atombios_crtc_commit+0x18/0x38
 [   62.628906] [8047f038] drm_crtc_helper_set_mode+0x304/0x3cc
 [   62.628906] [8047f92c] drm_crtc_helper_set_config+0x6d8/0x988
 [   62.628906] [8047dd40] drm_fb_helper_set_par+0x94/0x104
 [   62.628906] [80439d14] fbcon_init+0x424/0x57c
 [   62.628906] [8046a638] visual_init+0xb8/0x118
 [   62.628906] [8046b9f8] take_over_console+0x238/0x384
 [   62.628906] [80436df8] fbcon_takeover+0x7c/0xdc
 [   62.628906] [8024fa20] notifier_call_chain+0x44/0x94
 [   62.628906] [8024fcbc] __blocking_notifier_call_chain+0x48/0x68
 [   62.628906] [8042d990] register_framebuffer+0x228/0x260
 [   62.628906] [8047e010] drm_fb_helper_single_fb_probe+0x260/0x314
 [   62.628906] [8047e2c4] drm_fb_helper_initial_config+0x200/0x234
 [   62.628906] [804e5560] radeon_fbdev_init+0xd4/0xf4
 [   62.628906] [804e0e08] radeon_modeset_init+0x9bc/0xa18
 [   62.628906] [804bfc14] radeon_driver_load_kms+0xdc/0x12c
 [   62.628906] [8048b548] drm_get_pci_dev+0x148/0x238
 [   62.628906] [80423564] local_pci_probe+0x5c/0xd0
 [   62.628906] [80241ac4] work_for_cpu_fn+0x1c/0x30
 [   62.628906] [802427c8] process_one_work+0x274/0x3bc
 [   62.628906] [80242934] process_scheduled_works+0x24/0x44
 [   62.628906] [8024515c] worker_thread+0x31c/0x3f4
 [   62.628906] [802497a8] kthread+0x88/0x90
 [   62.628906] [80206794] kernel_thread_helper+0x10/0x18
 
 Signed-off-by: Huacai Chen che...@lemote.com
 Signed-off-by: Binbin Zhou zho...@lemote.com
 Cc: sta...@vger.kernel.org
 ---
  drivers/gpu/drm/drm_irq.c |6 +-
  1 files changed, 5 insertions(+), 1 deletions(-)
 
 diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
 index c798eea..c7a1348 100644
 --- a/drivers/gpu/drm/drm_irq.c
 +++ b/drivers/gpu/drm/drm_irq.c
 @@ -981,7 +981,7 @@ EXPORT_SYMBOL(drm_vblank_off);
   */
  void drm_vblank_pre_modeset(struct drm_device *dev, int crtc)
  {
 -   /* vblank is not initialized (IRQ not installed ?) */
 +   /* vblank is not initialized (IRQ not installed ?), or has been freed 
 */
 if (!dev-num_crtcs)
 return;
 /*
 @@ -1003,6 +1003,10 @@ void drm_vblank_post_modeset(struct drm_device *dev, 
 int crtc)
  {
 unsigned long irqflags;
  
 +   /* vblank is not initialized (IRQ not installed ?), or has been freed 
 */
 +   if (!dev-num_crtcs)
 +   return;
 +
 if (dev-vblank_inmodeset[crtc]) {
 spin_lock_irqsave(dev-vbl_lock, irqflags);
 dev-vblank_disable_allowed = 1;

The comment changes seem superfluous to me, but either way:

Reviewed-by: Michel Dänzer michel.daen...@amd.com


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast |  Debian, X and DRI developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/exynos: wait for the completion of pending page flip

[Inki Dae]

This patch fixes the issue that drm_vblank_get() is failed.

The issus occurs when next page flip request is tried
if previous page flip event wasn't completed yet and then
dpms became off.

So this patch make sure that page flip event is completed
before dpms goes to off.

Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c |   16 
 1 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index e8894bc..69a77e9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -48,6 +48,8 @@ struct exynos_drm_crtc {
unsigned intpipe;
unsigned intdpms;
enum exynos_crtc_mode   mode;
+   wait_queue_head_t   pending_flip_queue;
+   atomic_tpending_flip;
 };
 
 static void exynos_drm_crtc_dpms(struct drm_crtc *crtc, int mode)
@@ -61,6 +63,13 @@ static void exynos_drm_crtc_dpms(struct drm_crtc *crtc, int 
mode)
return;
}
 
+   if (mode  DRM_MODE_DPMS_ON) {
+   /* wait for the completion of page flip. */
+   wait_event(exynos_crtc-pending_flip_queue,
+   atomic_read(exynos_crtc-pending_flip) == 0);
+   drm_vblank_off(crtc-dev, exynos_crtc-pipe);
+   }
+
exynos_drm_fn_encoder(crtc, mode, exynos_drm_encoder_crtc_dpms);
exynos_crtc-dpms = mode;
 }
@@ -225,6 +234,7 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc,
spin_lock_irq(dev-event_lock);
list_add_tail(event-base.link,
dev_priv-pageflip_event_list);
+   atomic_set(exynos_crtc-pending_flip, 1);
spin_unlock_irq(dev-event_lock);
 
crtc-fb = fb;
@@ -344,6 +354,8 @@ int exynos_drm_crtc_create(struct drm_device *dev, unsigned 
int nr)
 
exynos_crtc-pipe = nr;
exynos_crtc-dpms = DRM_MODE_DPMS_OFF;
+   init_waitqueue_head(exynos_crtc-pending_flip_queue);
+   atomic_set(exynos_crtc-pending_flip, 0);
exynos_crtc-plane = exynos_plane_init(dev, 1  nr, true);
if (!exynos_crtc-plane) {
kfree(exynos_crtc);
@@ -398,6 +410,8 @@ void exynos_drm_crtc_finish_pageflip(struct drm_device 
*dev, int crtc)
 {
struct exynos_drm_private *dev_priv = dev-dev_private;
struct drm_pending_vblank_event *e, *t;
+   struct drm_crtc *drm_crtc = dev_priv-crtc[crtc];
+   struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(drm_crtc);
struct timeval now;
unsigned long flags;
 
@@ -419,6 +433,8 @@ void exynos_drm_crtc_finish_pageflip(struct drm_device 
*dev, int crtc)
list_move_tail(e-base.link, e-base.file_priv-event_list);
wake_up_interruptible(e-base.file_priv-event_wait);
drm_vblank_put(dev, crtc);
+   atomic_set(exynos_crtc-pending_flip, 0);
+   wake_up(exynos_crtc-pending_flip_queue);
}
 
spin_unlock_irqrestore(dev-event_lock, flags);
-- 
1.7.5.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 63698] Build error with libdrm in non standard prefix

[bugzilla-daemon]

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

Andreas Boll andreas.boll@gmail.com changed:

   What|Removed |Added

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

--- Comment #2 from Andreas Boll andreas.boll@gmail.com ---
Fixed by commit e2b985dc0f93a195d984aa7c88669ab67160c6c4

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 64193] LLVM RV670 regression since R600: Packetize instructions

[bugzilla-daemon]

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

Marc Dietrich marvi...@gmx.de changed:

   What|Removed |Added

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

--- Comment #25 from Marc Dietrich marvi...@gmx.de ---
As of today, http://www.ibiblio.org/e-notes/webgl/webgl.htm works again with
firefox. (Chrome has webgl init error, but maybe a chrome bug). So I guess this
was fixed otherwise.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: Introduce a new helper framework for buffer synchronization

[Inki Dae]

 -Original Message-
 From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
 Vetter
 Sent: Tuesday, May 21, 2013 4:45 PM
 To: Inki Dae
 Cc: 'Daniel Vetter'; 'Rob Clark'; 'linux-fbdev'; 'DRI mailing list';
 'Kyungmin Park'; 'myungjoo.ham'; 'YoungJun Cho'; linux-arm-
 ker...@lists.infradead.org; linux-me...@vger.kernel.org
 Subject: Re: Introduce a new helper framework for buffer synchronization
 
 On Tue, May 21, 2013 at 04:03:06PM +0900, Inki Dae wrote:
   - Integration of fence syncing into dma_buf. Imo we should have a
 per-attachment mode which decides whether map/unmap (and the new
 sync)
 should wait for fences or whether the driver takes care of syncing
 through the new fence framework itself (for direct hw sync).
 
  I think it's a good idea to have per-attachment mode for buffer sync.
 But
  I'd like to say we make sure what is the purpose of map
  (dma_buf_map_attachment)first. This interface is used to get a sgt;
  containing pages to physical memory region, and map that region with
  device's iommu table. The important thing is that this interface is
 called
  just one time when user wants to share an allocated buffer with dma. But
 cpu
  will try to access the buffer every time as long as it wants. Therefore,
 we
  need cache control every time cpu and dma access the shared buffer:
 cache
  clean when cpu goes to dma and cache invalidate when dma goes to cpu.
 That
  is why I added new interfaces, DMA_BUF_GET_FENCE and DMA_BUF_PUT_FENCE,
 to
  dma buf framework. Of course, Those are ugly so we need a better way: I
 just
  wanted to show you that in such way, we can synchronize the shared
 buffer
  between cpu and dma. By any chance, is there any way that kernel can be
  aware of when cpu accesses the shared buffer or is there any point I
 didn't
  catch up?
 
 Well dma_buf_map/unmap_attachment should also flush/invalidate any caches,
 and with the current dma_buf spec those two functions are the _only_ means

I know that dma buf exporter should make sure that cache clean/invalidate
are done when dma_buf_map/unmap_attachement is called. For this, already we
do so. However, this function is called when dma buf import is requested by
user to map a dmabuf fd with dma. This means that dma_buf_map_attachement()
is called ONCE when user wants to share the dmabuf fd with dma. Actually, in
case of exynos drm, dma_map_sg_attrs(), performing cache operation
internally, is called when dmabuf import is requested by user.

 you have to do so. Which strictly means that if you interleave device dma
 and cpu acccess you need to unmap/map every time.
 
 Which is obviously horribly inefficient, but a known gap in the dma_buf

Right, and also this has big overhead.

 interface. Hence why I proposed to add dma_buf_sync_attachment similar to
 dma_sync_single_for_device:
 
 /**
  * dma_buf_sync_sg_attachment - sync caches for dma access
  * @attach: dma-buf attachment to sync
  * @sgt: the sg table to sync (returned by dma_buf_map_attachement)
  * @direction: dma direction to sync for
  *
  * This function synchronizes caches for device dma through the given
  * dma-buf attachment when interleaving dma from different devices and the
  * cpu. Other device dma needs to be synced also by calls to this
  * function (or a pair of dma_buf_map/unmap_attachment calls), cpu access
  * needs to be synced with dma_buf_begin/end_cpu_access.
  */
 void dma_buf_sync_sg_attachment(struct dma_buf_attachment *attach,
   struct sg_table *sgt,
   enum dma_data_direction direction)
 
 Note that sync here only means to synchronize caches, not wait for any
 outstanding fences. This is simply to be consistent with the established
 lingo of the dma api. How the dma-buf fences fit into this is imo a
 different topic, but my idea is that all the cache coherency barriers
 (i.e. dma_buf_map/unmap_attachment, dma_buf_sync_sg_attachment and
 dma_buf_begin/end_cpu_access) would automatically block for any attached
 fences (i.e. block for write fences when doing read-only access, block for
 all fences otherwise).

As I mentioned already, kernel can't aware of when cpu accesses a shared
buffer: user can access a shared buffer after mmap anytime and the shared
buffer should be synchronized between cpu and dma. Therefore, the above
cache coherency barriers should be called every time cpu and dma tries to
access a shared buffer, checking before and after of cpu and dma access. And
exactly, the proposed way do such thing. For this, you can refer to the
below link,

http://www.mail-archive.com/linux-media@vger.kernel.org/msg62124.html

My point is that how kernel can aware of when those cache coherency barriers
should be called to synchronize caches and buffer access between cpu and
dma.

 
 Then we could do a new dma_buf_attach_flags interface for special cases
 (might also be useful for other things, similar to the recently added
 flags in the dma 

[Bug 64819] New: GPU fault detected flood at A8-5600K Trinity 7560D

[bugzilla-daemon]

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

  Priority: medium
Bug ID: 64819
  Assignee: dri-devel@lists.freedesktop.org
   Summary: GPU fault detected flood at A8-5600K Trinity 7560D
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: p00hz...@gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Drivers/DRI/Radeon
   Product: Mesa

Created attachment 79612
  -- https://bugs.freedesktop.org/attachment.cgi?id=79612action=edit
dmesg.log

I have exactly similar bug as described at
https://bugs.freedesktop.org/show_bug.cgi?id=59089 with Trinity 7560D at
A8-5600K.

I'm using latest git drivers. As that bug marked as fixed should i claim that
my problem is unrelated and caused by hardware and/or other malfunctions?

My problem consists of NOT log flood only, but the whole machine usually
freezes and nothing except hard reboot can fix this. Problem detects in both
idle and high load mode. The temperature of APU is about 20-40C.

#uname -a
Linux multiseat 3.9.2-1-gpgpu

#lspci | grep VGA
00:01.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Trinity
[Radeon HD 7560D]

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 44851] resume to black screen

[bugzilla-daemon]

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





--- Comment #11 from Peter energo...@gmail.com  2013-05-21 10:15:05 ---
Still on iMac, installed fedora 18 on partition previously used by Arch (would
boot using KMS into black vts). fedora using kernel 3.6. Behaved like Arch did
previously; had to use kernel option 'nomodeset' to get any vt screens and that
stopped radeon module from being loaded by X 
(Xorg.0.log had: '[KMS] drm report modesetting isn't supported' and
this was followed by 'No screens found')

Now upgraded fedora to use kernel 3.9.2 and, as with Arch, get black vts even
if 'nomodeset' on kernel boot line.

The current kernel 3.9.2 is of no use on my system; I have no way to boot it
and run vt screens. Others who might need nomodeset may also be affected.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 64819] GPU fault detected flood at A8-5600K Trinity 7560D

[bugzilla-daemon]

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

--- Comment #1 from Alex Deucher ag...@yahoo.com ---
What version of mesa are you using?  This might be a duplicate of bug 62959. 
Make sure your kernel has this patch:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=466476dfdcafbb4286ffa232a3a792731b9dc852

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Genereal question regarding kernel development

[Daniel Vetter]

Hi Jan,

First things first, please _always_ cc relevant mailing lists.

Second: I've submitted a proper patch to revert this behaviour change,
but it has been nacked. I've poked Dave Airlie about it again on irc.
See https://patchwork.kernel.org/patch/2402211/

Thanks, Daniel

On Tue, May 21, 2013 at 3:28 PM, Jan Niggemann j...@hz6.de wrote:
 Hi Daniel,

 sorry for bothering you directly, but being a kernel dev you can probably
 answer my question:
 I read what patchwork is and what it's used for; I also understand that
 bugs are tracked in bugzilla and that both are separate systems.
 My question is:
 I'm affected by this: https://patchwork.kernel.org/patch/2400621/
 I expected this patch to be somehow linked to a bugzilla entry I could
 subscribe to (in order to get updates on issue)...
 But I'm unable to find a bug in bugzilla regarding kworker irq storm or
 similar...

 Are patches in patchwork that correct kernel bugs in any way linked to
 bugzilla issues and if so, how?
 Thank you for your time!

 Regards
 Jan



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon: UVD block on SUMO2 is the same as on SUMO

[Christian König]

From: Christian König christian.koe...@amd.com

The chip id for SUMO2 isn't used.

Signed-off-by: Christian König christian.koe...@amd.com
---
 drivers/gpu/drm/radeon/rv770.c |4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
index 83f612a..3fc2985 100644
--- a/drivers/gpu/drm/radeon/rv770.c
+++ b/drivers/gpu/drm/radeon/rv770.c
@@ -862,10 +862,8 @@ int rv770_uvd_resume(struct radeon_device *rdev)
chip_id = 0x010b;
break;
case CHIP_SUMO:
-   chip_id = 0x010c;
-   break;
case CHIP_SUMO2:
-   chip_id = 0x010d;
+   chip_id = 0x010c;
break;
case CHIP_PALM:
chip_id = 0x010e;
-- 
1.7.9.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: fix a use-after-free when GPU acceleration disabled

[Paul Menzel]

Am Dienstag, den 21.05.2013, 14:23 +0800 schrieb Huacai Chen:
 When GPU acceleration is disabled, drm_vblank_cleanup() will free the
 vblank-related data, such as vblank_refcount, vblank_inmodeset, etc.
 But we found that drm_vblank_post_modeset() may be called after the
 cleanup, which use vblank_refcount and vblank_inmodeset. And this will
 cause a kernel panic.
 
 Fix this by return immediately if dev-num_crtcs is zero. This is the
 same thing that drm_vblank_pre_modeset() does.
 
 Call trace of a drm_vblank_post_modeset() after drm_vblank_cleanup():
 [   62.628906] [804868d0] drm_vblank_post_modeset+0x34/0xb4
 [   62.628906] [804c7008] atombios_crtc_dpms+0xb4/0x174
 [   62.628906] [804c70e0] atombios_crtc_commit+0x18/0x38
 [   62.628906] [8047f038] drm_crtc_helper_set_mode+0x304/0x3cc
 [   62.628906] [8047f92c] drm_crtc_helper_set_config+0x6d8/0x988
 [   62.628906] [8047dd40] drm_fb_helper_set_par+0x94/0x104
 [   62.628906] [80439d14] fbcon_init+0x424/0x57c
 [   62.628906] [8046a638] visual_init+0xb8/0x118
 [   62.628906] [8046b9f8] take_over_console+0x238/0x384
 [   62.628906] [80436df8] fbcon_takeover+0x7c/0xdc
 [   62.628906] [8024fa20] notifier_call_chain+0x44/0x94
 [   62.628906] [8024fcbc] __blocking_notifier_call_chain+0x48/0x68
 [   62.628906] [8042d990] register_framebuffer+0x228/0x260
 [   62.628906] [8047e010] drm_fb_helper_single_fb_probe+0x260/0x314
 [   62.628906] [8047e2c4] drm_fb_helper_initial_config+0x200/0x234
 [   62.628906] [804e5560] radeon_fbdev_init+0xd4/0xf4
 [   62.628906] [804e0e08] radeon_modeset_init+0x9bc/0xa18
 [   62.628906] [804bfc14] radeon_driver_load_kms+0xdc/0x12c
 [   62.628906] [8048b548] drm_get_pci_dev+0x148/0x238
 [   62.628906] [80423564] local_pci_probe+0x5c/0xd0
 [   62.628906] [80241ac4] work_for_cpu_fn+0x1c/0x30
 [   62.628906] [802427c8] process_one_work+0x274/0x3bc
 [   62.628906] [80242934] process_scheduled_works+0x24/0x44
 [   62.628906] [8024515c] worker_thread+0x31c/0x3f4
 [   62.628906] [802497a8] kthread+0x88/0x90
 [   62.628906] [80206794] kernel_thread_helper+0x10/0x18

Nice commit message!

 Signed-off-by: Huacai Chen che...@lemote.com
 Signed-off-by: Binbin Zhou zho...@lemote.com
 Cc: sta...@vger.kernel.org
 ---
  drivers/gpu/drm/drm_irq.c |6 +-
  1 files changed, 5 insertions(+), 1 deletions(-)

[…]

Acked-by: Paul Menzel paulepan...@users.sourceforge.net


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Genereal question regarding kernel development

[Daniel Vetter]

On Tue, May 21, 2013 at 4:30 PM, Jan Niggemann j...@hz6.de wrote:
 Hi Daniel,

 you misunderstood my mail, I just wanted to know:

 Are patches in patchwork that correct kernel bugs in any way linked to
 bugzilla issues and if so, how?
 In other words: What bugzilla bug corresponds to
 https://patchwork.kernel.org/patch/2402211/ ?

There's no bug rebort for this issue in kernel bugzilla afaik. And
please don't drop cc's.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 63935] TURKS [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!

[bugzilla-daemon]

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

--- Comment #36 from Christian König deathsim...@vodafone.de ---
(In reply to comment #35)
 Would this be the same as others have done above?

Thanks for the input, but we already have enough register dumps for now.

Currently I'm analyzing them and trying to figure out what the heck is going
wrong here.

Cheers,
Christian.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/radeon: UVD block on SUMO2 is the same as on SUMO

[Alex Deucher]

On Tue, May 21, 2013 at 11:14 AM, Christian König
deathsim...@vodafone.de wrote:
 From: Christian König christian.koe...@amd.com

 The chip id for SUMO2 isn't used.

 Signed-off-by: Christian König christian.koe...@amd.com

Applied.  thanks!

Alex

 ---
  drivers/gpu/drm/radeon/rv770.c |4 +---
  1 file changed, 1 insertion(+), 3 deletions(-)

 diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
 index 83f612a..3fc2985 100644
 --- a/drivers/gpu/drm/radeon/rv770.c
 +++ b/drivers/gpu/drm/radeon/rv770.c
 @@ -862,10 +862,8 @@ int rv770_uvd_resume(struct radeon_device *rdev)
 chip_id = 0x010b;
 break;
 case CHIP_SUMO:
 -   chip_id = 0x010c;
 -   break;
 case CHIP_SUMO2:
 -   chip_id = 0x010d;
 +   chip_id = 0x010c;
 break;
 case CHIP_PALM:
 chip_id = 0x010e;
 --
 1.7.9.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon: fix typo in cu_per_sh on verde

[alexdeucher]

From: Alex Deucher alexander.deuc...@amd.com

Should be 5 rather than 2.

Noticed by sroland and glisse on IRC.

Signed-off-by: Alex Deucher alexander.deuc...@amd.com
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/radeon/si.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index 113ed9f..34d431e 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -2435,7 +2435,7 @@ static void si_gpu_init(struct radeon_device *rdev)
default:
rdev-config.si.max_shader_engines = 1;
rdev-config.si.max_tile_pipes = 4;
-   rdev-config.si.max_cu_per_sh = 2;
+   rdev-config.si.max_cu_per_sh = 5;
rdev-config.si.max_sh_per_se = 2;
rdev-config.si.max_backends_per_se = 4;
rdev-config.si.max_texture_channel_caches = 4;
-- 
1.7.7.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/exynos: wait for the completion of pending page flip

[Stéphane Marchesin]

On Tue, May 21, 2013 at 1:08 AM, Inki Dae inki@samsung.com wrote:
 This patch fixes the issue that drm_vblank_get() is failed.

 The issus occurs when next page flip request is tried
 if previous page flip event wasn't completed yet and then
 dpms became off.

 So this patch make sure that page flip event is completed
 before dpms goes to off.

Hi,

This patch is a squash of the two following patches from the Chrome OS
tree with the KDS bits removed and the dpms off bit added:

http://git.chromium.org/gitweb/?p=chromiumos/third_party/kernel-next.git;a=commitdiff;h=2e77cd4e423967862ca01b1af82aa8b5b7429fc4;hp=aba002da4c6e5efec4d43e1ce33930a79269349a
http://git.chromium.org/gitweb/?p=chromiumos/third_party/kernel-next.git;a=commitdiff;h=b4ec8bfa750ef43a43c2da746c8afdbb51002882;hp=4f28b9a75c928f229443d7c6c3163159ceb6903a

Please keep proper attribution.


 Signed-off-by: Inki Dae inki@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  drivers/gpu/drm/exynos/exynos_drm_crtc.c |   16 
  1 files changed, 16 insertions(+), 0 deletions(-)

 diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
 b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
 index e8894bc..69a77e9 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
 @@ -48,6 +48,8 @@ struct exynos_drm_crtc {
 unsigned intpipe;
 unsigned intdpms;
 enum exynos_crtc_mode   mode;
 +   wait_queue_head_t   pending_flip_queue;
 +   atomic_tpending_flip;
  };

  static void exynos_drm_crtc_dpms(struct drm_crtc *crtc, int mode)
 @@ -61,6 +63,13 @@ static void exynos_drm_crtc_dpms(struct drm_crtc *crtc, 
 int mode)
 return;
 }

 +   if (mode  DRM_MODE_DPMS_ON) {
 +   /* wait for the completion of page flip. */
 +   wait_event(exynos_crtc-pending_flip_queue,
 +   atomic_read(exynos_crtc-pending_flip) == 0);
 +   drm_vblank_off(crtc-dev, exynos_crtc-pipe);

You should be using vblank_put/get.

Stéphane

 +   }
 +
 exynos_drm_fn_encoder(crtc, mode, exynos_drm_encoder_crtc_dpms);
 exynos_crtc-dpms = mode;
  }
 @@ -225,6 +234,7 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc 
 *crtc,
 spin_lock_irq(dev-event_lock);
 list_add_tail(event-base.link,
 dev_priv-pageflip_event_list);
 +   atomic_set(exynos_crtc-pending_flip, 1);
 spin_unlock_irq(dev-event_lock);

 crtc-fb = fb;
 @@ -344,6 +354,8 @@ int exynos_drm_crtc_create(struct drm_device *dev, 
 unsigned int nr)

 exynos_crtc-pipe = nr;
 exynos_crtc-dpms = DRM_MODE_DPMS_OFF;
 +   init_waitqueue_head(exynos_crtc-pending_flip_queue);
 +   atomic_set(exynos_crtc-pending_flip, 0);
 exynos_crtc-plane = exynos_plane_init(dev, 1  nr, true);
 if (!exynos_crtc-plane) {
 kfree(exynos_crtc);
 @@ -398,6 +410,8 @@ void exynos_drm_crtc_finish_pageflip(struct drm_device 
 *dev, int crtc)
  {
 struct exynos_drm_private *dev_priv = dev-dev_private;
 struct drm_pending_vblank_event *e, *t;
 +   struct drm_crtc *drm_crtc = dev_priv-crtc[crtc];
 +   struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(drm_crtc);
 struct timeval now;
 unsigned long flags;

 @@ -419,6 +433,8 @@ void exynos_drm_crtc_finish_pageflip(struct drm_device 
 *dev, int crtc)
 list_move_tail(e-base.link, e-base.file_priv-event_list);
 wake_up_interruptible(e-base.file_priv-event_wait);
 drm_vblank_put(dev, crtc);
 +   atomic_set(exynos_crtc-pending_flip, 0);
 +   wake_up(exynos_crtc-pending_flip_queue);
 }

 spin_unlock_irqrestore(dev-event_lock, flags);
 --
 1.7.5.4

 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 64649] Anomaly 2 (Steam) exits with GLX_EXT_swap_control not supported, unable to set vertical sync

[bugzilla-daemon]

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

--- Comment #14 from Kai k...@dev.carbon-project.org ---
(In reply to comment #11)
 (In reply to comment #2)
  It then closes. It won't run without that extention, switched to GLX instead
  of a driver specific component.
 
 The game runs for me with i965 on gen7.

Very likely (see attachment 79573). The title is wrong, GLX_EXT_swap_control is
only requested by the Steam overlay and non-critical. I can see the
GLX_EXT_swap_control with any game I launch through Steam (e.g. Oil Rush) and
the others work well. It's just Anomaly that is hitting a bug in r600g (or a
bug in Anomaly which isn't handled gracefully by r600g?). Anyway, the title
should be changed to something more accurate.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 64649] Anomaly 2 (Steam) exits with segfault in r600g

[bugzilla-daemon]

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

Alex Deucher ag...@yahoo.com changed:

   What|Removed |Added

Summary|Anomaly 2 (Steam) exits |Anomaly 2 (Steam) exits
   |with GLX_EXT_swap_control   |with segfault in r600g
   |not supported, unable to|
   |set vertical sync   |

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 64649] Anomaly 2 (Steam) exits with divide by 0 in r600g

[bugzilla-daemon]

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

Alex Deucher ag...@yahoo.com changed:

   What|Removed |Added

Summary|Anomaly 2 (Steam) exits |Anomaly 2 (Steam) exits
   |with segfault in r600g  |with divide by 0 in r600g

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 64819] GPU fault detected flood at A8-5600K Trinity 7560D

[bugzilla-daemon]

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

--- Comment #2 from p00h p00hz...@gmail.com ---
mesa: 9.1.2
ati-dri: 9.1.2
The kernel has this patch already.
I have several machines with the same problem, all of them shipped with
A8-5600K.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 64819] GPU fault detected flood at A8-5600K Trinity 7560D

[bugzilla-daemon]

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

--- Comment #3 from Alex Deucher ag...@yahoo.com ---
Does mesa from git master work any better?  You might also try disabling hyperz
(set env var R600_HYPERZ=0).

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 63236] kwin crashes when some desktop effects are used

[bugzilla-daemon]

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

--- Comment #4 from Eugene omegat...@gmail.com ---
Did you actually verify the problem to be fixed with radeonsi?

Unfortunately I didn't check what exactly solved the problem, the only thing
for sure - I can not reproduce it now.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 0/8] rmk's Dove DRM/TDA19988 Cubox driver

[Jean-Francois Moine]

On Mon, 20 May 2013 16:23:33 -0400
Alex Deucher alexdeuc...@gmail.com wrote:

  Note also that the generic DRM KMS code assumes cursor support at
  64x64, and there's no generic way for a driver at present (that I know
  of) to inform it of anything different.  
 
 It shouldn't be too hard to add a new cap for querying the cursor size
 to the drm cap interface.

There was already a patch request for that, but the functions were
surely useless.

Otherwise, you may do a search on largest cursor: (xdpyinfo output).
The results are surprising..

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 63520] r300g regression (RV380): Strange rendering of light sources in Penumbra (bisected)

[bugzilla-daemon]

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

--- Comment #19 from PJBrs pj...@floorenpj.xs4all.nl ---
Created attachment 79628
  -- https://bugs.freedesktop.org/attachment.cgi?id=79628action=edit
Log with possible fix

Hi, thanks for the patch! Unfortunately, it does not appear to do anything that
I can see, the bug(s?) are still there. I've attached the log as per your
request. Let me know if I can help in any other way.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 63520] r300g regression (RV380): Strange rendering of light sources in Penumbra (bisected)

[bugzilla-daemon]

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

--- Comment #20 from PJBrs pj...@floorenpj.xs4all.nl ---
P.s., I did a quick glance at the difference between the first bad log and the
log with the patch (sdiff badlog  patch-test.log | less). It seems as if shader
pc8 now is truncated or something...

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 64819] GPU fault detected flood at A8-5600K Trinity 7560D

[bugzilla-daemon]

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

--- Comment #4 from p00h p00hz...@gmail.com ---
I'll try it and make an report after

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 06/11] drm/exynos: page flip fixes

[Dave Airlie]

Hi Inki,

can you please check if this patch is still necessary, and apply it if so.

Dave.

On Tue, Oct 9, 2012 at 5:50 AM, Rob Clark rob.cl...@linaro.org wrote:
 From: Rob Clark r...@ti.com

 The event wouldn't be on any list at this point, so nothing to delete
 it from.

 Signed-off-by: Rob Clark r...@ti.com
 ---
  drivers/gpu/drm/exynos/exynos_drm_crtc.c |1 -
  1 file changed, 1 deletion(-)

 diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
 b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
 index abb1e2f..d17419c 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
 @@ -225,7 +225,6 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc 
 *crtc,
 ret = drm_vblank_get(dev, exynos_crtc-pipe);
 if (ret) {
 DRM_DEBUG(failed to acquire vblank counter\n);
 -   list_del(event-base.link);

 goto out;
 }
 --
 1.7.9.5

 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 09/11] drm/imx: page flip fixes

[Dave Airlie]

Hi Sascha,

please review and apply if still applicable, I've already applied the
imx use drm_send_vblank_event to my drm-fixes tree.

Dave.

On Tue, Oct 9, 2012 at 5:50 AM, Rob Clark rob.cl...@linaro.org wrote:
 From: Rob Clark r...@ti.com

 The 'event' could be null, so don't list_del(event-base.link)..  and
 in fact even if it wasn't null there is no reason to do this.

 Also, this looks racy with the irq handler, so throw in a spinlock for
 good measure.

 Signed-off-by: Rob Clark r...@ti.com
 ---
  drivers/staging/imx-drm/ipuv3-crtc.c |   11 +++
  1 file changed, 7 insertions(+), 4 deletions(-)

 diff --git a/drivers/staging/imx-drm/ipuv3-crtc.c 
 b/drivers/staging/imx-drm/ipuv3-crtc.c
 index 8fa0f4d..6745766 100644
 --- a/drivers/staging/imx-drm/ipuv3-crtc.c
 +++ b/drivers/staging/imx-drm/ipuv3-crtc.c
 @@ -135,23 +135,26 @@ static int ipu_page_flip(struct drm_crtc *crtc,
 struct drm_pending_vblank_event *event)
  {
 struct ipu_crtc *ipu_crtc = to_ipu_crtc(crtc);
 +   struct drm_device *drm = ipu_crtc-base.dev;
 +   unsigned long flags;
 int ret;

 if (ipu_crtc-newfb)
 return -EBUSY;

 +   spin_lock_irqsave(drm-event_lock, flags);
 ret = imx_drm_crtc_vblank_get(ipu_crtc-imx_crtc);
 if (ret) {
 dev_dbg(ipu_crtc-dev, failed to acquire vblank counter\n);
 -   list_del(event-base.link);
 -
 -   return ret;
 +   goto out;
 }

 ipu_crtc-newfb = fb;
 ipu_crtc-page_flip_event = event;

 -   return 0;
 +out:
 +   spin_unlock_irqrestore(drm-event_lock, flags);
 +   return ret;
  }

  static const struct drm_crtc_funcs ipu_crtc_funcs = {
 --
 1.7.9.5

 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 05/11] drm/exynos: use drm_send_vblank_event() helper

[Dave Airlie]

Hi Inki,

this doesn't apply cleanly anymore, and I think we want exynos to use
drm_send_vblank_event where possible,

please apply to fixes tree and send to me.

Dave.

On Tue, Oct 9, 2012 at 5:50 AM, Rob Clark rob.cl...@linaro.org wrote:
 From: Rob Clark r...@ti.com

 Signed-off-by: Rob Clark r...@ti.com
 ---
  drivers/gpu/drm/exynos/exynos_drm_fimd.c |   10 ++
  drivers/gpu/drm/exynos/exynos_drm_vidi.c |   10 ++
  drivers/gpu/drm/exynos/exynos_mixer.c|9 ++---
  3 files changed, 6 insertions(+), 23 deletions(-)

 diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
 b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
 index b19cd93..fe8fb78 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
 @@ -587,7 +587,6 @@ static void fimd_finish_pageflip(struct drm_device 
 *drm_dev, int crtc)
  {
 struct exynos_drm_private *dev_priv = drm_dev-dev_private;
 struct drm_pending_vblank_event *e, *t;
 -   struct timeval now;
 unsigned long flags;
 bool is_checked = false;

 @@ -601,13 +600,8 @@ static void fimd_finish_pageflip(struct drm_device 
 *drm_dev, int crtc)

 is_checked = true;

 -   do_gettimeofday(now);
 -   e-event.sequence = 0;
 -   e-event.tv_sec = now.tv_sec;
 -   e-event.tv_usec = now.tv_usec;
 -
 -   list_move_tail(e-base.link, e-base.file_priv-event_list);
 -   wake_up_interruptible(e-base.file_priv-event_wait);
 +   list_del(e-base.link);
 +   drm_send_vblank_event(drm_dev, -1, e);
 }

 if (is_checked) {
 diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c 
 b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
 index e364165..4549efb 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
 @@ -370,7 +370,6 @@ static void vidi_finish_pageflip(struct drm_device 
 *drm_dev, int crtc)
  {
 struct exynos_drm_private *dev_priv = drm_dev-dev_private;
 struct drm_pending_vblank_event *e, *t;
 -   struct timeval now;
 unsigned long flags;
 bool is_checked = false;

 @@ -384,13 +383,8 @@ static void vidi_finish_pageflip(struct drm_device 
 *drm_dev, int crtc)

 is_checked = true;

 -   do_gettimeofday(now);
 -   e-event.sequence = 0;
 -   e-event.tv_sec = now.tv_sec;
 -   e-event.tv_usec = now.tv_usec;
 -
 -   list_move_tail(e-base.link, e-base.file_priv-event_list);
 -   wake_up_interruptible(e-base.file_priv-event_wait);
 +   list_del(e-base.link);
 +   drm_send_vblank_event(drm_dev, -1, e);
 }

 if (is_checked) {
 diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
 b/drivers/gpu/drm/exynos/exynos_mixer.c
 index 25b97d5..325aefd 100644
 --- a/drivers/gpu/drm/exynos/exynos_mixer.c
 +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
 @@ -828,7 +828,6 @@ static void mixer_finish_pageflip(struct drm_device 
 *drm_dev, int crtc)
  {
 struct exynos_drm_private *dev_priv = drm_dev-dev_private;
 struct drm_pending_vblank_event *e, *t;
 -   struct timeval now;
 unsigned long flags;
 bool is_checked = false;

 @@ -841,13 +840,9 @@ static void mixer_finish_pageflip(struct drm_device 
 *drm_dev, int crtc)
 continue;

 is_checked = true;
 -   do_gettimeofday(now);
 -   e-event.sequence = 0;
 -   e-event.tv_sec = now.tv_sec;
 -   e-event.tv_usec = now.tv_usec;

 -   list_move_tail(e-base.link, e-base.file_priv-event_list);
 -   wake_up_interruptible(e-base.file_priv-event_wait);
 +   list_del(e-base.link);
 +   drm_send_vblank_event(drm_dev, -1, e);
 }

 if (is_checked)
 --
 1.7.9.5

 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [pull] drm-intel-fixes

[Stéphane Marchesin]

On Mon, Sep 10, 2012 at 12:28 AM, Daniel Vetter dan...@ffwll.ch wrote:
 Hi Dave,

 You're pull just reminded me that I've been sitting on a few small -fixes,
 too. Nothing really major at all:
 - fixup edp setup sequence (Dave)
 - disable sdvo hotplug for real, this is a fixup for a messed-up
   regression fixer (Jani)
 - don't expose dysfunctional backlight driver (Jani)

Hi Daniel,

This change (don't expose dysfunctional backlight driver) regresses
the backlight on Chromebooks, where we don't run the vbios.

Stéphane


 - properly init spinlock (only used by hsw/vlv code) from Alexander
   Shishkin

 Wrt regression we have a new case of rc6-no-longer-working (times time it
 breaks after resume, investigation still going on) and one of the
 infoframe patches broke a screen on ilk (Paulo is looking into this one
 already).

 Cheers, Daniel

 The following changes since commit 4cbe5a555fa58a79b6ecbb6c531b8bab0650778d:

   Linux 3.6-rc4 (2012-09-01 10:39:58 -0700)

 are available in the git repository at:

   git://people.freedesktop.org/~danvet/drm-intel drm-intel-fixes

 for you to fetch changes up to 99d0b1db6ccd0c0e554398e8a579ff3dd4d119ee:

   drm/i915: initialize dpio_lock spin lock (2012-09-08 19:04:04 +0200)

 
 Alexander Shishkin (1):
   drm/i915: initialize dpio_lock spin lock

 Dave Airlie (1):
   drm/i915/edp: get the panel delay before powering up

 Jani Nikula (2):
   drm/i915: only enable sdvo hotplug irq if needed
   drm/i915: do not expose a dysfunctional backlight interface to userspace

  drivers/gpu/drm/i915/i915_dma.c|1 +
  drivers/gpu/drm/i915/intel_dp.c|   11 +++
  drivers/gpu/drm/i915/intel_panel.c |   31 ++-
  drivers/gpu/drm/i915/intel_sdvo.c  |   15 ++-
  4 files changed, 36 insertions(+), 22 deletions(-)
 --
 Daniel Vetter
 Software Engineer, Intel Corporation
 +41 (0) 79 365 57 48 - http://blog.ffwll.ch
 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH 05/11] drm/exynos: use drm_send_vblank_event() helper

[Inki Dae]

Hi Dave,

Got it. we have to re-work this patch. Will send it soon.

Thanks,
Inki Dae

 -Original Message-
 From: Dave Airlie [mailto:airl...@gmail.com]
 Sent: Wednesday, May 22, 2013 8:20 AM
 To: Inki Dae
 Cc: dri-devel@lists.freedesktop.org
 Subject: Re: [PATCH 05/11] drm/exynos: use drm_send_vblank_event() helper
 
 Hi Inki,
 
 this doesn't apply cleanly anymore, and I think we want exynos to use
 drm_send_vblank_event where possible,
 
 please apply to fixes tree and send to me.
 
 Dave.
 
 On Tue, Oct 9, 2012 at 5:50 AM, Rob Clark rob.cl...@linaro.org wrote:
  From: Rob Clark r...@ti.com
 
  Signed-off-by: Rob Clark r...@ti.com
  ---
   drivers/gpu/drm/exynos/exynos_drm_fimd.c |   10 ++
   drivers/gpu/drm/exynos/exynos_drm_vidi.c |   10 ++
   drivers/gpu/drm/exynos/exynos_mixer.c|9 ++---
   3 files changed, 6 insertions(+), 23 deletions(-)
 
  diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
 b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
  index b19cd93..fe8fb78 100644
  --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
  +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
  @@ -587,7 +587,6 @@ static void fimd_finish_pageflip(struct drm_device
 *drm_dev, int crtc)
   {
  struct exynos_drm_private *dev_priv = drm_dev-dev_private;
  struct drm_pending_vblank_event *e, *t;
  -   struct timeval now;
  unsigned long flags;
  bool is_checked = false;
 
  @@ -601,13 +600,8 @@ static void fimd_finish_pageflip(struct drm_device
 *drm_dev, int crtc)
 
  is_checked = true;
 
  -   do_gettimeofday(now);
  -   e-event.sequence = 0;
  -   e-event.tv_sec = now.tv_sec;
  -   e-event.tv_usec = now.tv_usec;
  -
  -   list_move_tail(e-base.link, e-base.file_priv-
 event_list);
  -   wake_up_interruptible(e-base.file_priv-event_wait);
  +   list_del(e-base.link);
  +   drm_send_vblank_event(drm_dev, -1, e);
  }
 
  if (is_checked) {
  diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
 b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
  index e364165..4549efb 100644
  --- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
  +++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
  @@ -370,7 +370,6 @@ static void vidi_finish_pageflip(struct drm_device
 *drm_dev, int crtc)
   {
  struct exynos_drm_private *dev_priv = drm_dev-dev_private;
  struct drm_pending_vblank_event *e, *t;
  -   struct timeval now;
  unsigned long flags;
  bool is_checked = false;
 
  @@ -384,13 +383,8 @@ static void vidi_finish_pageflip(struct drm_device
 *drm_dev, int crtc)
 
  is_checked = true;
 
  -   do_gettimeofday(now);
  -   e-event.sequence = 0;
  -   e-event.tv_sec = now.tv_sec;
  -   e-event.tv_usec = now.tv_usec;
  -
  -   list_move_tail(e-base.link, e-base.file_priv-
 event_list);
  -   wake_up_interruptible(e-base.file_priv-event_wait);
  +   list_del(e-base.link);
  +   drm_send_vblank_event(drm_dev, -1, e);
  }
 
  if (is_checked) {
  diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
 b/drivers/gpu/drm/exynos/exynos_mixer.c
  index 25b97d5..325aefd 100644
  --- a/drivers/gpu/drm/exynos/exynos_mixer.c
  +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
  @@ -828,7 +828,6 @@ static void mixer_finish_pageflip(struct drm_device
 *drm_dev, int crtc)
   {
  struct exynos_drm_private *dev_priv = drm_dev-dev_private;
  struct drm_pending_vblank_event *e, *t;
  -   struct timeval now;
  unsigned long flags;
  bool is_checked = false;
 
  @@ -841,13 +840,9 @@ static void mixer_finish_pageflip(struct drm_device
 *drm_dev, int crtc)
  continue;
 
  is_checked = true;
  -   do_gettimeofday(now);
  -   e-event.sequence = 0;
  -   e-event.tv_sec = now.tv_sec;
  -   e-event.tv_usec = now.tv_usec;
 
  -   list_move_tail(e-base.link, e-base.file_priv-
 event_list);
  -   wake_up_interruptible(e-base.file_priv-event_wait);
  +   list_del(e-base.link);
  +   drm_send_vblank_event(drm_dev, -1, e);
  }
 
  if (is_checked)
  --
  1.7.9.5
 
  ___
  dri-devel mailing list
  dri-devel@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/dri-devel

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH 06/11] drm/exynos: page flip fixes

[Inki Dae]

 -Original Message-
 From: Dave Airlie [mailto:airl...@gmail.com]
 Sent: Wednesday, May 22, 2013 8:17 AM
 To: Inki Dae
 Cc: dri-devel@lists.freedesktop.org
 Subject: Re: [PATCH 06/11] drm/exynos: page flip fixes
 
 Hi Inki,
 
 can you please check if this patch is still necessary, and apply it if so.
 

I missed it. Applied. And exynos-drm-fixes has one patch being reviewed yet
so we will request pull after reviewed.

Thanks,
Inki Dae

 Dave.
 
 On Tue, Oct 9, 2012 at 5:50 AM, Rob Clark rob.cl...@linaro.org wrote:
  From: Rob Clark r...@ti.com
 
  The event wouldn't be on any list at this point, so nothing to delete
  it from.
 
  Signed-off-by: Rob Clark r...@ti.com
  ---
   drivers/gpu/drm/exynos/exynos_drm_crtc.c |1 -
   1 file changed, 1 deletion(-)
 
  diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
 b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
  index abb1e2f..d17419c 100644
  --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
  +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
  @@ -225,7 +225,6 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc
 *crtc,
  ret = drm_vblank_get(dev, exynos_crtc-pipe);
  if (ret) {
  DRM_DEBUG(failed to acquire vblank counter\n);
  -   list_del(event-base.link);
 
  goto out;
  }
  --
  1.7.9.5
 
  ___
  dri-devel mailing list
  dri-devel@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/dri-devel

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/exynos: use drm_send_vblank_event() helper

[Inki Dae]

From: Rob Clark r...@ti.com

Rebased.

Signed-off-by: Rob Clark r...@ti.com
Signed-off-by: Inki Dae inki@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c |   10 ++
 1 files changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index e8894bc..1e7825a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -398,7 +398,6 @@ void exynos_drm_crtc_finish_pageflip(struct drm_device 
*dev, int crtc)
 {
struct exynos_drm_private *dev_priv = dev-dev_private;
struct drm_pending_vblank_event *e, *t;
-   struct timeval now;
unsigned long flags;
 
DRM_DEBUG_KMS(%s\n, __FILE__);
@@ -411,14 +410,9 @@ void exynos_drm_crtc_finish_pageflip(struct drm_device 
*dev, int crtc)
if (crtc != e-pipe)
continue;
 
-   do_gettimeofday(now);
-   e-event.sequence = 0;
-   e-event.tv_sec = now.tv_sec;
-   e-event.tv_usec = now.tv_usec;
-
-   list_move_tail(e-base.link, e-base.file_priv-event_list);
-   wake_up_interruptible(e-base.file_priv-event_wait);
drm_vblank_put(dev, crtc);
+   list_del(e-base.link);
+   drm_send_vblank_event(dev, -1, e);
}
 
spin_unlock_irqrestore(dev-event_lock, flags);
-- 
1.7.5.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/exynos: wait for the completion of pending page flip

[Inki Dae]

2013/5/22 Stéphane Marchesin stephane.marche...@gmail.com

 On Tue, May 21, 2013 at 1:08 AM, Inki Dae inki@samsung.com wrote:
  This patch fixes the issue that drm_vblank_get() is failed.
 
  The issus occurs when next page flip request is tried
  if previous page flip event wasn't completed yet and then
  dpms became off.
 
  So this patch make sure that page flip event is completed
  before dpms goes to off.

 Hi,

 This patch is a squash of the two following patches from the Chrome OS
 tree with the KDS bits removed and the dpms off bit added:


 http://git.chromium.org/gitweb/?p=chromiumos/third_party/kernel-next.git;a=commitdiff;h=2e77cd4e423967862ca01b1af82aa8b5b7429fc4;hp=aba002da4c6e5efec4d43e1ce33930a79269349a

 http://git.chromium.org/gitweb/?p=chromiumos/third_party/kernel-next.git;a=commitdiff;h=b4ec8bfa750ef43a43c2da746c8afdbb51002882;hp=4f28b9a75c928f229443d7c6c3163159ceb6903a

 Please keep proper attribution.


Those patches are just for Chrome OS. Please post them if you want for
those to be considered so that they can be reviewed. That is why we attend
open source. One more comment, please do not abuse
exynos_drm_crtc_page_flip()


 Signed-off-by: Inki Dae inki@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  drivers/gpu/drm/exynos/exynos_drm_crtc.c |   16 
  1 files changed, 16 insertions(+), 0 deletions(-)

 diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
 index e8894bc..69a77e9 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
 @@ -48,6 +48,8 @@ struct exynos_drm_crtc {
 unsigned intpipe;
 unsigned intdpms;
 enum exynos_crtc_mode   mode;
 +   wait_queue_head_t   pending_flip_queue;
 +   atomic_tpending_flip;
  };

  static void exynos_drm_crtc_dpms(struct drm_crtc *crtc, int mode)
 @@ -61,6 +63,13 @@ static void exynos_drm_crtc_dpms(struct drm_crtc
*crtc, int mode)
 return;
 }

 +   if (mode  DRM_MODE_DPMS_ON) {
 +   /* wait for the completion of page flip. */
 +   wait_event(exynos_crtc-pending_flip_queue,
 +   atomic_read(exynos_crtc-pending_flip)
== 0);
 +   drm_vblank_off(crtc-dev, exynos_crtc-pipe);

You should be using vblank_put/get.


No, drm_vblank_put should be called by exynos_drm_crtc_finish_pageflip().
And know that this patch makes sure that pended page flip event is
completed before dpms goes to off.

Thanks,
Inki Dae

Stéphane

  +   }
  +
  exynos_drm_fn_encoder(crtc, mode, exynos_drm_encoder_crtc_dpms);
  exynos_crtc-dpms = mode;
   }
  @@ -225,6 +234,7 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc
 *crtc,
  spin_lock_irq(dev-event_lock);
  list_add_tail(event-base.link,
  dev_priv-pageflip_event_list);
  +   atomic_set(exynos_crtc-pending_flip, 1);
  spin_unlock_irq(dev-event_lock);
 
  crtc-fb = fb;
  @@ -344,6 +354,8 @@ int exynos_drm_crtc_create(struct drm_device *dev,
 unsigned int nr)
 
  exynos_crtc-pipe = nr;
  exynos_crtc-dpms = DRM_MODE_DPMS_OFF;
  +   init_waitqueue_head(exynos_crtc-pending_flip_queue);
  +   atomic_set(exynos_crtc-pending_flip, 0);
  exynos_crtc-plane = exynos_plane_init(dev, 1  nr, true);
  if (!exynos_crtc-plane) {
  kfree(exynos_crtc);
  @@ -398,6 +410,8 @@ void exynos_drm_crtc_finish_pageflip(struct
 drm_device *dev, int crtc)
   {
  struct exynos_drm_private *dev_priv = dev-dev_private;
  struct drm_pending_vblank_event *e, *t;
  +   struct drm_crtc *drm_crtc = dev_priv-crtc[crtc];
  +   struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(drm_crtc);
  struct timeval now;
  unsigned long flags;
 
  @@ -419,6 +433,8 @@ void exynos_drm_crtc_finish_pageflip(struct
 drm_device *dev, int crtc)
  list_move_tail(e-base.link,
 e-base.file_priv-event_list);
  wake_up_interruptible(e-base.file_priv-event_wait);
  drm_vblank_put(dev, crtc);
  +   atomic_set(exynos_crtc-pending_flip, 0);
  +   wake_up(exynos_crtc-pending_flip_queue);
  }
 
  spin_unlock_irqrestore(dev-event_lock, flags);
  --
  1.7.5.4
 
  ___
  dri-devel mailing list
  dri-devel@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/dri-devel
 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel

___
dri-devel mailing list
dri-devel@lists.freedesktop.org

Re: [PATCH] drm/exynos: wait for the completion of pending page flip

[Stéphane Marchesin]

On Tue, May 21, 2013 at 9:22 PM, Inki Dae inki@samsung.com wrote:



 2013/5/22 Stéphane Marchesin stephane.marche...@gmail.com

 On Tue, May 21, 2013 at 1:08 AM, Inki Dae inki@samsung.com wrote:
  This patch fixes the issue that drm_vblank_get() is failed.
 
  The issus occurs when next page flip request is tried
  if previous page flip event wasn't completed yet and then
  dpms became off.
 
  So this patch make sure that page flip event is completed
  before dpms goes to off.

 Hi,

 This patch is a squash of the two following patches from the Chrome OS
 tree with the KDS bits removed and the dpms off bit added:


 http://git.chromium.org/gitweb/?p=chromiumos/third_party/kernel-next.git;a=commitdiff;h=2e77cd4e423967862ca01b1af82aa8b5b7429fc4;hp=aba002da4c6e5efec4d43e1ce33930a79269349a

 http://git.chromium.org/gitweb/?p=chromiumos/third_party/kernel-next.git;a=commitdiff;h=b4ec8bfa750ef43a43c2da746c8afdbb51002882;hp=4f28b9a75c928f229443d7c6c3163159ceb6903a

 Please keep proper attribution.


 Those patches are just for Chrome OS. Please post them if you want for those
 to be considered so that they can be reviewed.

We intend to, once they are rebased onto latest kernel. But what I'm
pointing out is that you're removing proper attribution from Chrome OS
patches, and this is the second time it has happened.

 That is why we attend open
 source. One more comment, please do not abuse exynos_drm_crtc_page_flip()


What do you mean by abuse?


 Signed-off-by: Inki Dae inki@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  drivers/gpu/drm/exynos/exynos_drm_crtc.c |   16 
  1 files changed, 16 insertions(+), 0 deletions(-)

 diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
 b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
 index e8894bc..69a77e9 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
 @@ -48,6 +48,8 @@ struct exynos_drm_crtc {
 unsigned intpipe;
 unsigned intdpms;
 enum exynos_crtc_mode   mode;
 +   wait_queue_head_t   pending_flip_queue;
 +   atomic_tpending_flip;
  };

  static void exynos_drm_crtc_dpms(struct drm_crtc *crtc, int mode)
 @@ -61,6 +63,13 @@ static void exynos_drm_crtc_dpms(struct drm_crtc *crtc,
 int mode)
 return;
 }

 +   if (mode  DRM_MODE_DPMS_ON) {
 +   /* wait for the completion of page flip. */
 +   wait_event(exynos_crtc-pending_flip_queue,
 +   atomic_read(exynos_crtc-pending_flip) ==
 0);
 +   drm_vblank_off(crtc-dev, exynos_crtc-pipe);

 You should be using vblank_put/get.


 No, drm_vblank_put should be called by exynos_drm_crtc_finish_pageflip().
 And know that this patch makes sure that pended page flip event is completed
 before dpms goes to off.

You need to do vblank_put/get while you're waiting. Otherwise you
don't know for sure that flips will happen. This is especially bad as
you don't use a timeout.

Stéphane


 Thanks,
 Inki Dae

 Stéphane

  +   }
  +
  exynos_drm_fn_encoder(crtc, mode,
  exynos_drm_encoder_crtc_dpms);
  exynos_crtc-dpms = mode;
   }
  @@ -225,6 +234,7 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc
  *crtc,
  spin_lock_irq(dev-event_lock);
  list_add_tail(event-base.link,
  dev_priv-pageflip_event_list);
  +   atomic_set(exynos_crtc-pending_flip, 1);
  spin_unlock_irq(dev-event_lock);
 
  crtc-fb = fb;
  @@ -344,6 +354,8 @@ int exynos_drm_crtc_create(struct drm_device *dev,
  unsigned int nr)
 
  exynos_crtc-pipe = nr;
  exynos_crtc-dpms = DRM_MODE_DPMS_OFF;
  +   init_waitqueue_head(exynos_crtc-pending_flip_queue);
  +   atomic_set(exynos_crtc-pending_flip, 0);
  exynos_crtc-plane = exynos_plane_init(dev, 1  nr, true);
  if (!exynos_crtc-plane) {
  kfree(exynos_crtc);
  @@ -398,6 +410,8 @@ void exynos_drm_crtc_finish_pageflip(struct
  drm_device *dev, int crtc)
   {
  struct exynos_drm_private *dev_priv = dev-dev_private;
  struct drm_pending_vblank_event *e, *t;
  +   struct drm_crtc *drm_crtc = dev_priv-crtc[crtc];
  +   struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(drm_crtc);
  struct timeval now;
  unsigned long flags;
 
  @@ -419,6 +433,8 @@ void exynos_drm_crtc_finish_pageflip(struct
  drm_device *dev, int crtc)
  list_move_tail(e-base.link,
  e-base.file_priv-event_list);
  wake_up_interruptible(e-base.file_priv-event_wait);
  drm_vblank_put(dev, crtc);
  +   atomic_set(exynos_crtc-pending_flip, 0);
  +   wake_up(exynos_crtc-pending_flip_queue);
  }
 
  spin_unlock_irqrestore(dev-event_lock, flags);
  --
  

Re: [PATCH] drm/exynos: use drm_send_vblank_event() helper

[Joonyoung Shim]

Hi,

On 05/22/2013 01:04 PM, Inki Dae wrote:

From: Rob Clark r...@ti.com

Rebased.

Signed-off-by: Rob Clark r...@ti.com
Signed-off-by: Inki Dae inki@samsung.com
---
  drivers/gpu/drm/exynos/exynos_drm_crtc.c |   10 ++
  1 files changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index e8894bc..1e7825a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -398,7 +398,6 @@ void exynos_drm_crtc_finish_pageflip(struct drm_device 
*dev, int crtc)
  {
struct exynos_drm_private *dev_priv = dev-dev_private;
struct drm_pending_vblank_event *e, *t;
-   struct timeval now;
unsigned long flags;
  
  	DRM_DEBUG_KMS(%s\n, __FILE__);

@@ -411,14 +410,9 @@ void exynos_drm_crtc_finish_pageflip(struct drm_device 
*dev, int crtc)
if (crtc != e-pipe)
continue;
  
-		do_gettimeofday(now);

-   e-event.sequence = 0;
-   e-event.tv_sec = now.tv_sec;
-   e-event.tv_usec = now.tv_usec;
-
-   list_move_tail(e-base.link, e-base.file_priv-event_list);
-   wake_up_interruptible(e-base.file_priv-event_wait);
drm_vblank_put(dev, crtc);
+   list_del(e-base.link);
+   drm_send_vblank_event(dev, -1, e);


I think it's better to add above things before drm_vblank_put is called
in comparison with prior codes.

Thanks.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 64649] Anomaly 2 (Steam) exits with divide by 0 in r600g

[bugzilla-daemon]

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

--- Comment #15 from romula...@gmail.com ---
 Again, just to make sure you don't search for a bug that is maybe no longer
 in r600g: I don't have the latest master for Mesa/libdrm, and it'll take me
 at least a few days, before I can get around to build a new version. Hency
 you might want to confirm the backtrace with somebody who runs master.

I will the backtrace, could you give me the exact command you used?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

linux-next: build warning after merge of the final tree (drm-intel tree related)

[Stephen Rothwell]

Hi ,

After merging the final tree, today's linux-next build (i386 defconfig)
produced this warning:

drivers/gpu/drm/i915/i915_gem.c:2978:3: warning: format '%ld' expects argument 
of type 'long int', but argument 3 has type 'size_t' [-Wformat]

Introduced by commit e4341d0356bc (drm/i915: Be more informative when
reporting too large for aperture error) from the drm-intel tree.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/


pgpMu91XL2oYQ.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel