Re: [pull] drm-intel-fixes

[Daniel Vetter]

On Wed, May 22, 2013 at 3:24 AM, Stéphane Marchesin
 wrote:
> 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.

Presuming the patch works as advertised it only stops publishing an
intel backlight driver which won't work. How does that break stuff?

Or do you somehow update the max blc stuff only once i915.ko is loaded?

I'm decently confused how that one blows up ...

Yours, 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 64850] Second screen black on Pitcairn PRO

[bugzilla-daemon]

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

--- Comment #3 from Jakob Nixdorf  ---
Update:

I tested the Arch Linux kernels 3.9.2 and 3.8.11 with the same result.

And, in case it is important, I noticed this line in dmesg:

[3.169540] radeon :01:00.0: Invalid ROM contents

I hope this can help further.

-- 
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/exynos: wait for the completion of pending page flip

[Tomasz Figa]

Hi Inki,

On Wednesday 22 of May 2013 15:37:14 Inki Dae wrote:
> 2013/5/22 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.g
> > it;a=commitdiff;h=2e77cd4e423967862ca01b1af82aa8b5b7429fc4;hp=aba002da
> > 4c6e5efec4d43e1ce33930a79269349a
> > 
> > 
> > http://git.chromium.org/gitweb/?p=chromiumos/third_party/kernel-next.g
> > it;a=commitdiff;h=b4ec8bfa750ef43a43c2da746c8afdbb51002882;hp=4f28b9a7
> > 5c928f229443d7c6c3163159ceb6903a> 
> > >> 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.
> 
> What is mean? does mainline kernel have the attribution? if not so, we
> don't need to consider it. And please know that I can not be aware of
> you have such patch set without any posting.
> 

at·tri·bu·tion 
n.
1. The act of attributing, especially the act of establishing a particular 
person as the creator of a work of art
[1]

So yes, mainline kernel has attribution. Actually posting something as 
work of someone that is not the author of the posted work is considered 
bad everywhere, isn't it?

However looking at those two patches linked by Stéphane, I'm not really 
sure this patch is really just a squash of them. Stéphane, are you 100% 
sure that your claims are true?

Best regards,
Tomasz

[1] http://www.thefreedictionary.com/attribution

> > > 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(&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.
> 
> Understood. Right, drm_vblank_get call before wait_event and
> drm_vblank_put call after wait_event.
> 
> Thanks,
> Inki Dae
> 
> > 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,

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

[Kyungmin Park]

On Wed, May 22, 2013 at 5:23 PM, Tomasz Figa  wrote:

> Hi Inki,
>
> On Wednesday 22 of May 2013 15:37:14 Inki Dae wrote:
> > 2013/5/22 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.g
> > > it;a=commitdiff;h=2e77cd4e423967862ca01b1af82aa8b5b7429fc4;hp=aba002da
> > > 4c6e5efec4d43e1ce33930a79269349a
> > >
> > >
> > > http://git.chromium.org/gitweb/?p=chromiumos/third_party/kernel-next.g
> > > it;a=commitdiff;h=b4ec8bfa750ef43a43c2da746c8afdbb51002882;hp=4f28b9a7
> > > 5c928f229443d7c6c3163159ceb6903a>
> > > >> 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.
>
Hi Stephane,

> > >
> > > 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.
>
First, we don't know what's going on Chrome OS. probably you think we refer
your codes. but we don't know chrome codes and doesn't refer it. it's our
finding from our use case.
Second, samsung has lots of division. some engineers are working with
Chrome OS. but ours is not their division.
now we're working on anoter platform and use exynos drm.
As you know "chinese wall". we're doing it properly.

Thank you,
Kyungmin Park

> >
> > What is mean? does mainline kernel have the attribution? if not so, we
> > don't need to consider it. And please know that I can not be aware of
> > you have such patch set without any posting.
> >
>
> at·tri·bu·tion
> n.
> 1. The act of attributing, especially the act of establishing a particular
> person as the creator of a work of art
> [1]
>
> So yes, mainline kernel has attribution. Actually posting something as
> work of someone that is not the author of the posted work is considered
> bad everywhere, isn't it?
>
> However looking at those two patches linked by Stéphane, I'm not really
> sure this patch is really just a squash of them. Stéphane, are you 100%
> sure that your claims are true?
>
> Best regards,
> Tomasz
>
> [1] http://www.thefreedictionary.com/attribution
>
> > > > 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(&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 wait

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

[Inki Dae]

2013/5/22 Tomasz Figa 

> Hi Inki,
>
> On Wednesday 22 of May 2013 15:37:14 Inki Dae wrote:
> > 2013/5/22 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.g
> > > it;a=commitdiff;h=2e77cd4e423967862ca01b1af82aa8b5b7429fc4;hp=aba002da
> > > 4c6e5efec4d43e1ce33930a79269349a
> > >
> > >
> > > http://git.chromium.org/gitweb/?p=chromiumos/third_party/kernel-next.g
> > > it;a=commitdiff;h=b4ec8bfa750ef43a43c2da746c8afdbb51002882;hp=4f28b9a7
> > > 5c928f229443d7c6c3163159ceb6903a>
> > > >> 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.
> >
> > What is mean? does mainline kernel have the attribution? if not so, we
> > don't need to consider it. And please know that I can not be aware of
> > you have such patch set without any posting.
> >
>
> at·tri·bu·tion
> n.
> 1. The act of attributing, especially the act of establishing a particular
> person as the creator of a work of art
> [1]
>
> So yes, mainline kernel has attribution. Actually posting something as
> work of someone that is not the author of the posted work is considered
> bad everywhere, isn't it?
>
>
Hahaha, understood. there was my misunderstanding. :)



> However looking at those two patches linked by Stéphane, I'm not really
> sure this patch is really just a squash of them. Stéphane, are you 100%
> sure that your claims are true?
>
>
And Stéphane, when was the first time it had happened? I haven't the
slightest intention to do so. If happened, there might be my missing
something.

Thanks,
Inki Dae


> Best regards,
> Tomasz
>
> [1] http://www.thefreedictionary.com/attribution
>
> > > > 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(&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.
> >
> > Understood. Right, drm_vblank_get call before wait_event and
> > drm_vblank_put call after wait_event.
> >
> > 

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

[Inki Dae]

2013/5/22 Kyungmin Park 

>
>
> On Wed, May 22, 2013 at 5:23 PM, Tomasz Figa wrote:
>
>> Hi Inki,
>>
>> On Wednesday 22 of May 2013 15:37:14 Inki Dae wrote:
>> > 2013/5/22 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.g
>> > > it;a=commitdiff;h=2e77cd4e423967862ca01b1af82aa8b5b7429fc4;hp=aba002da
>> > > 4c6e5efec4d43e1ce33930a79269349a
>> > >
>> > >
>> > >
>> http://git.chromium.org/gitweb/?p=chromiumos/third_party/kernel-next.g
>> > > it;a=commitdiff;h=b4ec8bfa750ef43a43c2da746c8afdbb51002882;hp=4f28b9a7
>> > > 5c928f229443d7c6c3163159ceb6903a>
>> > > >> 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.
>>
> Hi Stephane,
>
>>  > >
>> > > 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.
>>
> First, we don't know what's going on Chrome OS. probably you think we
> refer your codes. but we don't know chrome codes and doesn't refer it. it's
> our finding from our use case.
> Second, samsung has lots of division. some engineers are working with
> Chrome OS. but ours is not their division.
> now we're working on anoter platform and use exynos drm.
> As you know "chinese wall". we're doing it properly.
>


Actually, we referred to i915 codes, intel_display.c :)


>
> Thank you,
> Kyungmin Park
>
>>  >
>> > What is mean? does mainline kernel have the attribution? if not so, we
>> > don't need to consider it. And please know that I can not be aware of
>> > you have such patch set without any posting.
>> >
>>
>> at·tri·bu·tion
>> n.
>> 1. The act of attributing, especially the act of establishing a particular
>> person as the creator of a work of art
>> [1]
>>
>> So yes, mainline kernel has attribution. Actually posting something as
>> work of someone that is not the author of the posted work is considered
>> bad everywhere, isn't it?
>>
>> However looking at those two patches linked by Stéphane, I'm not really
>> sure this patch is really just a squash of them. Stéphane, are you 100%
>> sure that your claims are true?
>>
>> Best regards,
>> Tomasz
>>
>> [1] http://www.thefreedictionary.com/attribution
>>
>> > > > 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(&exynos_crtc->pending_flip)
>> > >
>> > > ==
>> > >
>> > > >> 0);
>> > > >> +   drm_vblank_off(crtc->dev, exynos_crtc->pipe);
>> > > >>
>> > > >> You should be using vblank_put/get.
>> > > >
>> > > > No, drm_vblank_put s

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

[bugzilla-daemon]

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

--- Comment #1 from Michel Dänzer  ---
Does setting the environment variable EGL_DRIVER=egl_dri2 help?

-- 
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 v3 2/3] mutex: add support for wound/wait style locks, v3

[Maarten Lankhorst]

Hey,

Op 30-04-13 21:14, Daniel Vetter schreef:
> On Sun, Apr 28, 2013 at 07:04:07PM +0200, Maarten Lankhorst wrote:
>> Changes since RFC patch v1:
>>  - Updated to use atomic_long instead of atomic, since the reservation_id 
>> was a long.
>>  - added mutex_reserve_lock_slow and mutex_reserve_lock_intr_slow
>>  - removed mutex_locked_set_reservation_id (or w/e it was called)
>> Changes since RFC patch v2:
>>  - remove use of __mutex_lock_retval_arg, add warnings when using wrong 
>> combination of
>>mutex_(,reserve_)lock/unlock.
>> Changes since v1:
>>  - Add __always_inline to __mutex_lock_common, otherwise reservation paths 
>> can be
>>triggered from normal locks, because __builtin_constant_p might evaluate 
>> to false
>>for the constant 0 in that case. Tests for this have been added in the 
>> next patch.
>>  - Updated documentation slightly.
>> Changes since v2:
>>  - Renamed everything to ww_mutex. (mlankhorst)
>>  - Added ww_acquire_ctx and ww_class. (mlankhorst)
>>  - Added a lot of checks for wrong api usage. (mlankhorst)
>>  - Documentation updates. (danvet)
> While writing the kerneldoc I've carefully check that all restrictions are
> enforced through debug checks somehow. I think that with full mutex debug
> (including lockdep) enabled, plus the slowpath injector patch I've just
> posted, _all_ interface abuse will be catched at runtime as long as all
> the single-threaded/uncontended cases are exercises sufficiently.
>
> So I think we've fully achieved level 5 on the Rusty API safety scale
> here. Higher levels seem pretty hard given that the concepts are rather
> fancy, but I think with the new (and much more consitent) naming, plus the
> explicit introduction as (more abstruct) structures for ww_class and
> ww_acquire_context the interface is about as intuitive as it gets.
>
> So all together I'm pretty happy with what the interface looks like. And
> one quick bikeshed below on the implementation.
> -Daniel
I included your fix below. I'm hoping to get this included in 3.11 through the 
drm tree, so
I can convert ttm to use it, but I haven't received any further reply on the 
patch series.

The 3.10 mutex improvement patches don't seem to cause any conflicts when 
merging
linus' tree, so I'll use drm-next as a base.

Are there any issues left? I included the patch you wrote for injecting 
-EDEADLK too
in my tree. The overwhelming silence makes me think there are either none, or
nobody cared enough to review it. :(

>> +/*
>> + * after acquiring lock with fastpath or when we lost out in contested
>> + * slowpath, set ctx and wake up any waiters so they can recheck.
>> + *
>> + * This function is never called when CONFIG_DEBUG_LOCK_ALLOC is set,
>> + * as the fastpath and opportunistic spinning are disabled in that case.
>> + */
>> +static __always_inline void
>> +ww_mutex_set_context_fastpath(struct ww_mutex *lock,
>> +   struct ww_acquire_ctx *ctx)
>> +{
>> +unsigned long flags;
>> +struct mutex_waiter *cur;
>> +
>> +ww_mutex_lock_acquired(lock, ctx, false);
>> +
>> +lock->ctx = ctx;
>> +smp_mb__after_atomic_dec();
> I think this should be
>
> + smp_mb__after_atomic_dec();
> + lock->ctx = ctx;
> + smp_mb();
>
> Also I wonder a bit how much this hurts the fastpath, and whether we
> should just shovel the ctx into the atomic field with a cmpxcht, like the
> rt mutex code does with the current pointer.
>
Fixed. I'm not sure if the second smp_mb is really needed. If there was a
smp_mb__before_atomic_read it would have been sufficient.

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

[Bug 64776] [9.1.2]"GPU fault detected" whit "eclipse juno" crash system

[bugzilla-daemon]

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

--- Comment #6 from Michel Dänzer  ---
Created attachment 79647
  --> https://bugs.freedesktop.org/attachment.cgi?id=79647&action=edit
radeonsi: Make sure disabled colour buffers are disabled in the CB state

Does this Mesa patch help?

-- 
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 v3 2/3] mutex: add support for wound/wait style locks, v3

[Peter Zijlstra]

> Are there any issues left? I included the patch you wrote for injecting 
> -EDEADLK too
> in my tree. The overwhelming silence makes me think there are either none, or
> nobody cared enough to review it. :(

It didn't manage to reach my inbox it seems,.. I can only find a debug
patch in this thread.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 2/3] mutex: add support for wound/wait style locks, v3

[Maarten Lankhorst]

Op 22-05-13 13:37, Peter Zijlstra schreef:
>> Are there any issues left? I included the patch you wrote for injecting 
>> -EDEADLK too
>> in my tree. The overwhelming silence makes me think there are either none, or
>> nobody cared enough to review it. :(
> It didn't manage to reach my inbox it seems,.. I can only find a debug
> patch in this thread.
>
Odd, maybe in your spam folder?
It arrived on all mailing lists, so I have no idea why you were left out.

http://www.spinics.net/lists/linux-arch/msg21425.html


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

Re: [PATCH v3 2/3] mutex: add support for wound/wait style locks, v3

[Peter Zijlstra]

On Wed, May 22, 2013 at 01:47:42PM +0200, Maarten Lankhorst wrote:
> Op 22-05-13 13:37, Peter Zijlstra schreef:
> >> Are there any issues left? I included the patch you wrote for injecting 
> >> -EDEADLK too
> >> in my tree. The overwhelming silence makes me think there are either none, 
> >> or
> >> nobody cared enough to review it. :(
> > It didn't manage to reach my inbox it seems,.. I can only find a debug
> > patch in this thread.
> >
> Odd, maybe in your spam folder?

Couldn't spot it there either.. weird.

> It arrived on all mailing lists,

I should both clean up my one huge lkml maildir and hack notmuch into
submission so I can read LKML again :/

> so I have no idea why you were left out.
> 
> http://www.spinics.net/lists/linux-arch/msg21425.html

Thanks, I'll go stare at it.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/4] drm/exynos: fix build warnings from ipp fimc

[Seung-Woo Kim]

Becuase of order of headers, there are build warnings and they are
fixed with this patch.

Signed-off-by: Seung-Woo Kim 
---
 drivers/gpu/drm/exynos/exynos_drm_fimc.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 754d760..75c50f5 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -12,9 +12,9 @@
  *
  */
 #include 
-#include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
-- 
1.7.4.1

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

[PATCH 3/4] drm/exynos: remove unnecessary devm_kfree

[Seung-Woo Kim]

devm_kfree does not need for fail case of probe function and for
remove function.

Signed-off-by: Seung-Woo Kim 
---
 drivers/gpu/drm/exynos/exynos_drm_gsc.c |2 --
 drivers/gpu/drm/exynos/exynos_drm_rotator.c |2 --
 2 files changed, 0 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index 487595a..98032d6 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -1748,7 +1748,6 @@ static int gsc_probe(struct platform_device *pdev)
return 0;
 
 err_ippdrv_register:
-   devm_kfree(dev, ippdrv->prop_list);
pm_runtime_disable(dev);
 err_get_irq:
free_irq(ctx->irq, ctx);
@@ -1761,7 +1760,6 @@ static int gsc_remove(struct platform_device *pdev)
struct gsc_context *ctx = get_gsc_context(dev);
struct exynos_drm_ippdrv *ippdrv = &ctx->ippdrv;
 
-   devm_kfree(dev, ippdrv->prop_list);
exynos_drm_ippdrv_unregister(ippdrv);
mutex_destroy(&ctx->lock);
 
diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c 
b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
index 947f09f..3aa502a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
@@ -709,7 +709,6 @@ static int rotator_probe(struct platform_device *pdev)
return 0;
 
 err_ippdrv_register:
-   devm_kfree(dev, ippdrv->prop_list);
pm_runtime_disable(dev);
 err_clk_get:
free_irq(rot->irq, rot);
@@ -722,7 +721,6 @@ static int rotator_remove(struct platform_device *pdev)
struct rot_context *rot = dev_get_drvdata(dev);
struct exynos_drm_ippdrv *ippdrv = &rot->ippdrv;
 
-   devm_kfree(dev, ippdrv->prop_list);
exynos_drm_ippdrv_unregister(ippdrv);
 
pm_runtime_disable(dev);
-- 
1.7.4.1

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

[PATCH 0/4] drm/exynos: code cleanups

[Seung-Woo Kim]

Build warnings of ipp fimc is fixed and device pointer usage is
simplified as directly using dev variable.

devm related fixes are also appiled: meaningless devm_kfree is
removed and request_threaded_irq is replaced to devm function.

Seung-Woo Kim (4):
  drm/exynos: cleanup device pointer usages
  drm/exynos: fix build warnings from ipp fimc
  drm/exynos: remove unnecessary devm_kfree
  drm/exynos: replace request_threaded_irq with devm function

 drivers/gpu/drm/exynos/exynos_drm_fimc.c|   12 
 drivers/gpu/drm/exynos/exynos_drm_fimd.c|   10 +-
 drivers/gpu/drm/exynos/exynos_drm_g2d.c |6 +++---
 drivers/gpu/drm/exynos/exynos_drm_gsc.c |   12 +++-
 drivers/gpu/drm/exynos/exynos_drm_hdmi.c|2 +-
 drivers/gpu/drm/exynos/exynos_drm_ipp.c |4 ++--
 drivers/gpu/drm/exynos/exynos_drm_rotator.c |   13 +++--
 drivers/gpu/drm/exynos/exynos_drm_vidi.c|4 ++--
 drivers/gpu/drm/exynos/exynos_hdmi.c|   21 -
 drivers/gpu/drm/exynos/exynos_mixer.c   |   14 +++---
 10 files changed, 38 insertions(+), 60 deletions(-)

-- 
1.7.4.1

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

[PATCH 4/4] drm/exynos: replace request_threaded_irq with devm function

[Seung-Woo Kim]

devm_request_threaded_irq is used instead of request_threaded_irq
and free_irq is removed.

Signed-off-by: Seung-Woo Kim 
---
 drivers/gpu/drm/exynos/exynos_drm_fimc.c|8 ++--
 drivers/gpu/drm/exynos/exynos_drm_gsc.c |8 ++--
 drivers/gpu/drm/exynos/exynos_drm_rotator.c |   11 +++
 drivers/gpu/drm/exynos/exynos_hdmi.c|7 +--
 4 files changed, 8 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 75c50f5..4a1616a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -1845,7 +1845,7 @@ static int fimc_probe(struct platform_device *pdev)
}
 
ctx->irq = res->start;
-   ret = request_threaded_irq(ctx->irq, NULL, fimc_irq_handler,
+   ret = devm_request_threaded_irq(dev, ctx->irq, NULL, fimc_irq_handler,
IRQF_ONESHOT, "drm_fimc", ctx);
if (ret < 0) {
dev_err(dev, "failed to request irq.\n");
@@ -1854,7 +1854,7 @@ static int fimc_probe(struct platform_device *pdev)
 
ret = fimc_setup_clocks(ctx);
if (ret < 0)
-   goto err_free_irq;
+   return ret;
 
ippdrv = &ctx->ippdrv;
ippdrv->ops[EXYNOS_DRM_OPS_SRC] = &fimc_src_ops;
@@ -1892,8 +1892,6 @@ err_pm_dis:
pm_runtime_disable(dev);
 err_put_clk:
fimc_put_clocks(ctx);
-err_free_irq:
-   free_irq(ctx->irq, ctx);
 
return ret;
 }
@@ -1911,8 +1909,6 @@ static int fimc_remove(struct platform_device *pdev)
pm_runtime_set_suspended(dev);
pm_runtime_disable(dev);
 
-   free_irq(ctx->irq, ctx);
-
return 0;
 }
 
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index 98032d6..762f40d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -1704,7 +1704,7 @@ static int gsc_probe(struct platform_device *pdev)
}
 
ctx->irq = res->start;
-   ret = request_threaded_irq(ctx->irq, NULL, gsc_irq_handler,
+   ret = devm_request_threaded_irq(dev, ctx->irq, NULL, gsc_irq_handler,
IRQF_ONESHOT, "drm_gsc", ctx);
if (ret < 0) {
dev_err(dev, "failed to request irq.\n");
@@ -1725,7 +1725,7 @@ static int gsc_probe(struct platform_device *pdev)
ret = gsc_init_prop_list(ippdrv);
if (ret < 0) {
dev_err(dev, "failed to init property list.\n");
-   goto err_get_irq;
+   return ret;
}
 
DRM_DEBUG_KMS("%s:id[%d]ippdrv[0x%x]\n", __func__, ctx->id,
@@ -1749,8 +1749,6 @@ static int gsc_probe(struct platform_device *pdev)
 
 err_ippdrv_register:
pm_runtime_disable(dev);
-err_get_irq:
-   free_irq(ctx->irq, ctx);
return ret;
 }
 
@@ -1766,8 +1764,6 @@ static int gsc_remove(struct platform_device *pdev)
pm_runtime_set_suspended(dev);
pm_runtime_disable(dev);
 
-   free_irq(ctx->irq, ctx);
-
return 0;
 }
 
diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c 
b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
index 3aa502a..9b6c709 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
@@ -666,8 +666,8 @@ static int rotator_probe(struct platform_device *pdev)
return rot->irq;
}
 
-   ret = request_threaded_irq(rot->irq, NULL, rotator_irq_handler,
-   IRQF_ONESHOT, "drm_rotator", rot);
+   ret = devm_request_threaded_irq(dev, rot->irq, NULL,
+   rotator_irq_handler, IRQF_ONESHOT, "drm_rotator", rot);
if (ret < 0) {
dev_err(dev, "failed to request irq\n");
return ret;
@@ -676,8 +676,7 @@ static int rotator_probe(struct platform_device *pdev)
rot->clock = devm_clk_get(dev, "rotator");
if (IS_ERR(rot->clock)) {
dev_err(dev, "failed to get clock\n");
-   ret = PTR_ERR(rot->clock);
-   goto err_clk_get;
+   return PTR_ERR(rot->clock);
}
 
pm_runtime_enable(dev);
@@ -710,8 +709,6 @@ static int rotator_probe(struct platform_device *pdev)
 
 err_ippdrv_register:
pm_runtime_disable(dev);
-err_clk_get:
-   free_irq(rot->irq, rot);
return ret;
 }
 
@@ -725,8 +722,6 @@ static int rotator_remove(struct platform_device *pdev)
 
pm_runtime_disable(dev);
 
-   free_irq(rot->irq, rot);
-
return 0;
 }
 
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 8d5dcd1..2f78532 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -2046,7 +2046,7 @@ static int hdmi_probe(struct platform_device *pdev)
 
hdata->hpd = gpio_get_value(hdata->hpd_gpio);
 
-   ret = request_threaded_irq(hdata->irq, NULL,
+   ret = devm_request_threaded_irq

[PATCH 1/4] drm/exynos: cleanup device pointer usages

[Seung-Woo Kim]

Struct device pointer got from platform device pointer is already
alsigned as variable, but some functions do not use device pointer.
So this patch replaces thoes usages.

Signed-off-by: Seung-Woo Kim 
---
 drivers/gpu/drm/exynos/exynos_drm_fimc.c |2 +-
 drivers/gpu/drm/exynos/exynos_drm_fimd.c |   10 +-
 drivers/gpu/drm/exynos/exynos_drm_g2d.c  |6 +++---
 drivers/gpu/drm/exynos/exynos_drm_gsc.c  |2 +-
 drivers/gpu/drm/exynos/exynos_drm_hdmi.c |2 +-
 drivers/gpu/drm/exynos/exynos_drm_ipp.c  |4 ++--
 drivers/gpu/drm/exynos/exynos_drm_vidi.c |4 ++--
 drivers/gpu/drm/exynos/exynos_hdmi.c |   14 +++---
 drivers/gpu/drm/exynos/exynos_mixer.c|   14 +++---
 9 files changed, 29 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 773f583..754d760 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -1884,7 +1884,7 @@ static int fimc_probe(struct platform_device *pdev)
goto err_pm_dis;
}
 
-   dev_info(&pdev->dev, "drm fimc registered successfully.\n");
+   dev_info(dev, "drm fimc registered successfully.\n");
 
return 0;
 
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 746b282..97c61db 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -885,7 +885,7 @@ static int fimd_probe(struct platform_device *pdev)
 
DRM_DEBUG_KMS("%s\n", __FILE__);
 
-   if (pdev->dev.of_node) {
+   if (dev->of_node) {
pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
if (!pdata) {
DRM_ERROR("memory allocation for pdata failed\n");
@@ -899,7 +899,7 @@ static int fimd_probe(struct platform_device *pdev)
return ret;
}
} else {
-   pdata = pdev->dev.platform_data;
+   pdata = dev->platform_data;
if (!pdata) {
DRM_ERROR("no platform data specified\n");
return -EINVAL;
@@ -912,7 +912,7 @@ static int fimd_probe(struct platform_device *pdev)
return -EINVAL;
}
 
-   ctx = devm_kzalloc(&pdev->dev, sizeof(*ctx), GFP_KERNEL);
+   ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
if (!ctx)
return -ENOMEM;
 
@@ -930,7 +930,7 @@ static int fimd_probe(struct platform_device *pdev)
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 
-   ctx->regs = devm_ioremap_resource(&pdev->dev, res);
+   ctx->regs = devm_ioremap_resource(dev, res);
if (IS_ERR(ctx->regs))
return PTR_ERR(ctx->regs);
 
@@ -942,7 +942,7 @@ static int fimd_probe(struct platform_device *pdev)
 
ctx->irq = res->start;
 
-   ret = devm_request_irq(&pdev->dev, ctx->irq, fimd_irq_handler,
+   ret = devm_request_irq(dev, ctx->irq, fimd_irq_handler,
0, "drm_fimd", ctx);
if (ret) {
dev_err(dev, "irq request failed.\n");
diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c 
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index 47a493c..af75434 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -1379,7 +1379,7 @@ static int g2d_probe(struct platform_device *pdev)
struct exynos_drm_subdrv *subdrv;
int ret;
 
-   g2d = devm_kzalloc(&pdev->dev, sizeof(*g2d), GFP_KERNEL);
+   g2d = devm_kzalloc(dev, sizeof(*g2d), GFP_KERNEL);
if (!g2d) {
dev_err(dev, "failed to allocate driver data\n");
return -ENOMEM;
@@ -1417,7 +1417,7 @@ static int g2d_probe(struct platform_device *pdev)
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 
-   g2d->regs = devm_ioremap_resource(&pdev->dev, res);
+   g2d->regs = devm_ioremap_resource(dev, res);
if (IS_ERR(g2d->regs)) {
ret = PTR_ERR(g2d->regs);
goto err_put_clk;
@@ -1430,7 +1430,7 @@ static int g2d_probe(struct platform_device *pdev)
goto err_put_clk;
}
 
-   ret = devm_request_irq(&pdev->dev, g2d->irq, g2d_irq_handler, 0,
+   ret = devm_request_irq(dev, g2d->irq, g2d_irq_handler, 0,
"drm_g2d", g2d);
if (ret < 0) {
dev_err(dev, "irq request failed\n");
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index 7841c3b..487595a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -1743,7 +1743,7 @@ static int gsc_probe(struct platform_device *pdev)
goto err_ippdrv_register;
}
 
-   dev_info(&pdev->dev, "drm gsc registered successful

[Bug 64850] Second screen black on Pitcairn PRO

[bugzilla-daemon]

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

--- Comment #4 from Alex Deucher  ---
Please attach your xorg log.

-- 
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 64850] Second screen black on Pitcairn PRO

[bugzilla-daemon]

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

--- Comment #5 from Alex Deucher  ---
Is it the HDMI monitor that's not working?  If so, try setting radeon.audio=0
on the kernel command line in grub.

-- 
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 64867] New: Hangs on Cayman (HD6950) when watching flash/using vdpau

[bugzilla-daemon]

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

  Priority: medium
Bug ID: 64867
  Assignee: dri-devel@lists.freedesktop.org
   Summary: Hangs on Cayman (HD6950) when watching flash/using
vdpau
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: seraf...@gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Drivers/Gallium/r600
   Product: Mesa

Created attachment 79658
  --> https://bugs.freedesktop.org/attachment.cgi?id=79658&action=edit
dmesg after X freeze

When watching a flash video (opera + flash-11.2.202.262 ) the kernel log starts
filling up with 
[ 7009.603310] radeon :01:00.0: GPU fault detected: 146 0x0e677004
[ 7009.603313] radeon :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x
[ 7009.603316] radeon :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x

to sometimes eventually hang the GPU. When this starts appearing there is
graphic corruption everywhere. I also managed to reproduce this when playing
back a video using mplayer with the vdpau backend. ( EnableLinuxHWVideoDecode=1
is commented out in /etc/adobe/mms.cfg)

I managed to get a dmesg output after the GPU hang (attached) and then tried to
save what is in /sys/kernel/debug/dri/0 but not knowing which was important,
tried to do it in a bash for cycle, and got a complete hang.

linux-3.10-rc1
mesa, libdrm, radeon ddx from git.

might be related to https://bugs.freedesktop.org/show_bug.cgi?id=62959 , but
piglit just finished fine. (fine = didn't hang in this case, still a bunch of
"radeon_gem_object_create:69 alloc size 1365Mb bigger than 256Mb limit" in the
logs).
Additional info : I have a dual screen setup.

Anything more you need, I'll be happy to provide.

-- 
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 64867] Hangs on Cayman (HD6950) when watching flash/using vdpau

[bugzilla-daemon]

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

--- Comment #1 from Martin Bednar  ---
Created attachment 79661
  --> https://bugs.freedesktop.org/attachment.cgi?id=79661&action=edit
output after hang.

The output I got when trying to cat /sys/debug/kernel/dri/0/* 
Sorry for the bad quality.

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

--- Comment #16 from Kai  ---
(In reply to comment #15)
> > 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?

The command is
gdb "~/.local/share/Steam/SteamApps/common/Anomaly 2/Anomaly2Linux" [ProcID]
but that alone isn't enough. First you need to install the debugging symbols
for Mesa and libc (the 32 bit versions!). Then you need to start Steam and
Anomaly 2 through Steam. While the intro is playing you need to tab to a
console, determine the process ID (with ps) and then replace [ProcID] in the
command above. After gdb has attached itself to Anomaly 2, you will see the gdb
prompt where you need to type c (or continue). After that, you can tab back to
the game and wait until you hit the crash. Then you should be back to your
desktop (and console windows). There you have to type in
bt full
and
info registers

You can exit gdb (and the attached Anomaly 2) by typing in q (or quit).

If you want to redirect the output of the above commands to a file, use
set logging file /path/to/log-file
set logging on
before you type c (or continue).


If you have trouble getting through all commands before the intro ends, you
might want to prepare them beforehand.

I hope this helps.

-- 
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 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 #37 from Alex Deucher  ---
Created attachment 79663
  --> https://bugs.freedesktop.org/attachment.cgi?id=79663&action=edit
don't re-post mac cards

For the non-Macs, this patch should fix the issue:
http://lists.freedesktop.org/archives/dri-devel/2013-May/038894.html

For the macs, does the attached patch help?

-- 
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: [pull] drm-intel-fixes

[Stéphane Marchesin]

On Wed, May 22, 2013 at 12:13 AM, Daniel Vetter  wrote:
> On Wed, May 22, 2013 at 3:24 AM, Stéphane Marchesin
>  wrote:
>> 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.
>
> Presuming the patch works as advertised it only stops publishing an
> intel backlight driver which won't work. How does that break stuff?
>

Well it probably works as advertised to avoid exposing some broken
backlight, but the problem is that it also stops exposing a working
backlight on Chromebooks. However it sounds like the initial patch is
specific to a broken machine, so maybe a dmi match is more
appropriate?

> Or do you somehow update the max blc stuff only once i915.ko is loaded?
>

Yup that's what used to happen.

Stéphane


> I'm decently confused how that one blows up ...
>
> Yours, 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

[PATCH 1/2] drm/radeon: fix card_posted check for newer asics

[alexdeucher]

From: Alex Deucher 

Newer asics have variable numbers of crtcs.  Use that
rather than the asic family to determine which crtcs
to check.  This avoids checking non-existent crtcs or
missing crtcs on certain asics.

Signed-off-by: Alex Deucher 
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/radeon/radeon_device.c |   19 +--
 1 files changed, 9 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index c2c59fb..89cc816 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -472,18 +472,17 @@ bool radeon_card_posted(struct radeon_device *rdev)
return false;
 
/* first check CRTCs */
-   if (ASIC_IS_DCE41(rdev)) {
+   if (ASIC_IS_DCE4(rdev)) {
reg = RREG32(EVERGREEN_CRTC_CONTROL + 
EVERGREEN_CRTC0_REGISTER_OFFSET) |
RREG32(EVERGREEN_CRTC_CONTROL + 
EVERGREEN_CRTC1_REGISTER_OFFSET);
-   if (reg & EVERGREEN_CRTC_MASTER_EN)
-   return true;
-   } else if (ASIC_IS_DCE4(rdev)) {
-   reg = RREG32(EVERGREEN_CRTC_CONTROL + 
EVERGREEN_CRTC0_REGISTER_OFFSET) |
-   RREG32(EVERGREEN_CRTC_CONTROL + 
EVERGREEN_CRTC1_REGISTER_OFFSET) |
-   RREG32(EVERGREEN_CRTC_CONTROL + 
EVERGREEN_CRTC2_REGISTER_OFFSET) |
-   RREG32(EVERGREEN_CRTC_CONTROL + 
EVERGREEN_CRTC3_REGISTER_OFFSET) |
-   RREG32(EVERGREEN_CRTC_CONTROL + 
EVERGREEN_CRTC4_REGISTER_OFFSET) |
-   RREG32(EVERGREEN_CRTC_CONTROL + 
EVERGREEN_CRTC5_REGISTER_OFFSET);
+   if (rdev->num_crtc >= 4) {
+   reg |= RREG32(EVERGREEN_CRTC_CONTROL + 
EVERGREEN_CRTC2_REGISTER_OFFSET) |
+   RREG32(EVERGREEN_CRTC_CONTROL + 
EVERGREEN_CRTC3_REGISTER_OFFSET);
+   }
+   if (rdev->num_crtc >= 6) {
+   reg |= RREG32(EVERGREEN_CRTC_CONTROL + 
EVERGREEN_CRTC4_REGISTER_OFFSET) |
+   RREG32(EVERGREEN_CRTC_CONTROL + 
EVERGREEN_CRTC5_REGISTER_OFFSET);
+   }
if (reg & EVERGREEN_CRTC_MASTER_EN)
return true;
} else if (ASIC_IS_AVIVO(rdev)) {
-- 
1.7.7.5

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

[PATCH 2/2] drm/radeon: don't check crtcs in card_posted() on cards without DCE

[alexdeucher]

From: Alex Deucher 

Skip checking crtcs in hardware without them.  Avoids checking
non-existent hardware.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/radeon_device.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index 89cc816..af82c9b 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -471,6 +471,9 @@ bool radeon_card_posted(struct radeon_device *rdev)
rdev->pdev->subsystem_vendor == PCI_VENDOR_ID_APPLE)
return false;
 
+   if (ASIC_IS_NODCE(rdev))
+   goto check_memsize;
+
/* first check CRTCs */
if (ASIC_IS_DCE4(rdev)) {
reg = RREG32(EVERGREEN_CRTC_CONTROL + 
EVERGREEN_CRTC0_REGISTER_OFFSET) |
@@ -499,6 +502,7 @@ bool radeon_card_posted(struct radeon_device *rdev)
}
}
 
+check_memsize:
/* then check MEM_SIZE, in case the crtcs are off */
if (rdev->family >= CHIP_R600)
reg = RREG32(R600_CONFIG_MEMSIZE);
-- 
1.7.7.5

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

[Bug 64738] graphics corruption with glamor

[bugzilla-daemon]

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

--- Comment #6 from Michel Dänzer  ---
> - glamor-0.5

Does current glamor Git work better? There have been some fixes which might be
relevant.

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

[PATCH 1/1] drm/exynos: Remove redundant use of of_match_ptr macro

[Sachin Kamat]

'mixer_match_types' is always compiled in. Hence of_match_ptr is not
necessary.

Signed-off-by: Sachin Kamat 
---
 drivers/gpu/drm/exynos/exynos_mixer.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index ec3e376..ec45064 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -1186,7 +1186,7 @@ static int mixer_probe(struct platform_device *pdev)
 
if (dev->of_node) {
const struct of_device_id *match;
-   match = of_match_node(of_match_ptr(mixer_match_types),
+   match = of_match_node(mixer_match_types,
  pdev->dev.of_node);
drv = (struct mixer_drv_data *)match->data;
} else {
-- 
1.7.9.5

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

Re: [PATCH 1/2] drm/radeon: fix card_posted check for newer asics

[Michel Dänzer]

On Mit, 2013-05-22 at 11:32 -0400, alexdeuc...@gmail.com wrote:
> From: Alex Deucher 
> 
> Newer asics have variable numbers of crtcs.  Use that
> rather than the asic family to determine which crtcs
> to check.  This avoids checking non-existent crtcs or
> missing crtcs on certain asics.
> 
> Signed-off-by: Alex Deucher 

Reviewed-by: Michel Dänzer 


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

Re: [pull] drm-intel-fixes

[Daniel Vetter]

On Wed, May 22, 2013 at 5:25 PM, Stéphane Marchesin
 wrote:
> On Wed, May 22, 2013 at 12:13 AM, Daniel Vetter  wrote:
>> On Wed, May 22, 2013 at 3:24 AM, Stéphane Marchesin
>>  wrote:
>>> 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.
>>
>> Presuming the patch works as advertised it only stops publishing an
>> intel backlight driver which won't work. How does that break stuff?
>>
>
> Well it probably works as advertised to avoid exposing some broken
> backlight, but the problem is that it also stops exposing a working
> backlight on Chromebooks. However it sounds like the initial patch is
> specific to a broken machine, so maybe a dmi match is more
> appropriate?

I prefer a dmi match for chromebooks since the behaviour of fixing up
the backlight after i915.ko is loaded seems rather peculiar to your
setup.

>> Or do you somehow update the max blc stuff only once i915.ko is loaded?
>>
>
> Yup that's what used to happen.

What/when exactly does that happen?
-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 #38 from Dave Witbrodt  ---
(In reply to comment #37)
> For the non-Macs, this patch should fix the issue:
> http://lists.freedesktop.org/archives/dri-devel/2013-May/038894.html

Thanks, Alex.

Christian had me test the SUMO2 fix yesterday, and I let him know that it
worked then.

Any chance I can get a "Tested-By:"?  ;)

-- 
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: [pull] drm-intel-fixes

[Stéphane Marchesin]

On Wed, May 22, 2013 at 8:51 AM, Daniel Vetter  wrote:
> On Wed, May 22, 2013 at 5:25 PM, Stéphane Marchesin
>  wrote:
>> On Wed, May 22, 2013 at 12:13 AM, Daniel Vetter  wrote:
>>> On Wed, May 22, 2013 at 3:24 AM, Stéphane Marchesin
>>>  wrote:
 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.
>>>
>>> Presuming the patch works as advertised it only stops publishing an
>>> intel backlight driver which won't work. How does that break stuff?
>>>
>>
>> Well it probably works as advertised to avoid exposing some broken
>> backlight, but the problem is that it also stops exposing a working
>> backlight on Chromebooks. However it sounds like the initial patch is
>> specific to a broken machine, so maybe a dmi match is more
>> appropriate?
>
> I prefer a dmi match for chromebooks since the behaviour of fixing up
> the backlight after i915.ko is loaded seems rather peculiar to your
> setup.

It has nothing to do with Chromebooks though, but more with the fact
that we don't run vbios. This isn't a property of the hardware.

>
>>> Or do you somehow update the max blc stuff only once i915.ko is loaded?
>>>
>>
>> Yup that's what used to happen.
>
> What/when exactly does that happen?

Before the regression, the code was:

if (max == 0) {
  i915_set_default_max_backlight

which would make it work. And now that doesn't run and therefore it breaks.

Stéphane


> -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: [i915] Backlight brighter since 3.9.0

[Joakim Plate]

Hi,

> 
> 2013/5/20 Daniel Vetter  ffwll.ch>
> 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
> 

Does this mean the system is doing RGB full range to limited range
compression on the raw RGB data it receives from an application?

Ie a video player that want to be able to handle blacker than black
properly will need to force the GPU into fullrange output to avoid
the driver internal compression of the signal and handle that itself?

/Joakim

___
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 #39 from Alex Deucher  ---
(In reply to comment #38)
> Any chance I can get a "Tested-By:"?  ;)

done!

-- 
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 v3 2/3] mutex: add support for wound/wait style locks, v3

[Peter Zijlstra]

On Wed, May 22, 2013 at 01:18:14PM +0200, Maarten Lankhorst wrote:

Lacking the actual msg atm, I'm going to paste in here...

> Subject: [PATCH v3 2/3] mutex: add support for wound/wait style locks, v3
> From: Maarten Lankhorst 
> 
> Changes since RFC patch v1:
>  - Updated to use atomic_long instead of atomic, since the reservation_id was 
> a long.
>  - added mutex_reserve_lock_slow and mutex_reserve_lock_intr_slow
>  - removed mutex_locked_set_reservation_id (or w/e it was called)
> Changes since RFC patch v2:
>  - remove use of __mutex_lock_retval_arg, add warnings when using wrong 
> combination of
>mutex_(,reserve_)lock/unlock.
> Changes since v1:
>  - Add __always_inline to __mutex_lock_common, otherwise reservation paths 
> can be
>triggered from normal locks, because __builtin_constant_p might evaluate 
> to false
>for the constant 0 in that case. Tests for this have been added in the 
> next patch.
>  - Updated documentation slightly.
> Changes since v2:
>  - Renamed everything to ww_mutex. (mlankhorst)
>  - Added ww_acquire_ctx and ww_class. (mlankhorst)
>  - Added a lot of checks for wrong api usage. (mlankhorst)
>  - Documentation updates. (danvet)
> 
> Signed-off-by: Maarten Lankhorst 
> Signed-off-by: Daniel Vetter 
> ---
>  Documentation/ww-mutex-design.txt |  322 +++
>  include/linux/mutex-debug.h   |1 
>  include/linux/mutex.h |  257 +
>  kernel/mutex.c|  445 
> -
>  lib/debug_locks.c |2 
>  5 files changed, 1010 insertions(+), 17 deletions(-)
>  create mode 100644 Documentation/ww-mutex-design.txt
> 
> diff --git a/Documentation/ww-mutex-design.txt 
> b/Documentation/ww-mutex-design.txt
> new file mode 100644
> index 000..154bae3
> --- /dev/null
> +++ b/Documentation/ww-mutex-design.txt
> @@ -0,0 +1,322 @@
> +Wait/Wound Deadlock-Proof Mutex Design
> +==
> +
> +Please read mutex-design.txt first, as it applies to wait/wound mutexes too.
> +
> +Motivation for WW-Mutexes
> +-
> +
> +GPU's do operations that commonly involve many buffers.  Those buffers
> +can be shared across contexts/processes, exist in different memory
> +domains (for example VRAM vs system memory), and so on.  And with
> +PRIME / dmabuf, they can even be shared across devices.  So there are
> +a handful of situations where the driver needs to wait for buffers to
> +become ready.  If you think about this in terms of waiting on a buffer
> +mutex for it to become available, this presents a problem because
> +there is no way to guarantee that buffers appear in a execbuf/batch in
> +the same order in all contexts.  That is directly under control of
> +userspace, and a result of the sequence of GL calls that an application
> +makes.   Which results in the potential for deadlock.  The problem gets
> +more complex when you consider that the kernel may need to migrate the
> +buffer(s) into VRAM before the GPU operates on the buffer(s), which
> +may in turn require evicting some other buffers (and you don't want to
> +evict other buffers which are already queued up to the GPU), but for a
> +simplified understanding of the problem you can ignore this.
> +
> +The algorithm that TTM came up with for dealing with this problem is quite
> +simple.  For each group of buffers (execbuf) that need to be locked, the 
> caller
> +would be assigned a unique reservation id/ticket, from a global counter.  In
> +case of deadlock while locking all the buffers associated with a execbuf, the
> +one with the lowest reservation ticket (i.e. the oldest task) wins, and the 
> one
> +with the higher reservation id (i.e. the younger task) unlocks all of the
> +buffers that it has already locked, and then tries again.
> +
> +In the RDBMS literature this deadlock handling approach is called wait/wound:
> +The older tasks waits until it can acquire the contended lock. The younger 
> tasks
> +needs to back off and drop all the locks it is currently holding, i.e. the
> +younger task is wounded.
> +
> +Concepts
> +
> +
> +Compared to normal mutexes two additional concepts/objects show up in the 
> lock
> +interface for w/w mutexes:
> +
> +Acquire context: To ensure eventual forward progress it is important the a 
> task
> +trying to acquire locks doesn't grab a new reservation id, but keeps the one 
> it
> +acquired when starting the lock acquisition. This ticket is stored in the
> +acquire context. Furthermore the acquire context keeps track of debugging 
> state
> +to catch w/w mutex interface abuse.
> +
> +W/w class: In contrast to normal mutexes the lock class needs to be explicit 
> for
> +w/w mutexes, since it is required to initialize the acquire context.
> +
> +Furthermore there are three different classe of w/w lock acquire functions:
> +- Normal lock acquisition with a context, using ww_mutex_lock
> +- Slowpath lock ac

[Bug 64850] Second screen black on Pitcairn PRO

[bugzilla-daemon]

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

--- Comment #6 from Jakob Nixdorf  ---
I will upload my xorg log as soon as possible. But I think its a DRM or KMS
issue, since it already happens before I start X (no TTY on the second screen
at boot after KMS starts).

And no, its not the HDMI screen, its the one connected via DVI.

-- 
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 64850] Second screen black on Pitcairn PRO

[bugzilla-daemon]

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

--- Comment #7 from Alex Deucher  ---
Does manually turning the problematic monitor off/on or picking a different
mode with xrandr help?

-- 
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 64850] Second screen black on Pitcairn PRO

[bugzilla-daemon]

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

--- Comment #8 from Jakob Nixdorf  ---
Created attachment 79671
  --> https://bugs.freedesktop.org/attachment.cgi?id=79671&action=edit
xorg log

-- 
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 v3 2/3] mutex: add support for wound/wait style locks, v3

[Daniel Vetter]

On Wed, May 22, 2013 at 6:18 PM, Peter Zijlstra  wrote:
> On Wed, May 22, 2013 at 01:18:14PM +0200, Maarten Lankhorst wrote:
>
> Lacking the actual msg atm, I'm going to paste in here...

Just replying to the interface/doc comments, Maarten's the guy for the
gory details ;-)

>> Subject: [PATCH v3 2/3] mutex: add support for wound/wait style locks, v3
>> From: Maarten Lankhorst 
>>
>> Changes since RFC patch v1:
>>  - Updated to use atomic_long instead of atomic, since the reservation_id 
>> was a long.
>>  - added mutex_reserve_lock_slow and mutex_reserve_lock_intr_slow
>>  - removed mutex_locked_set_reservation_id (or w/e it was called)
>> Changes since RFC patch v2:
>>  - remove use of __mutex_lock_retval_arg, add warnings when using wrong 
>> combination of
>>mutex_(,reserve_)lock/unlock.
>> Changes since v1:
>>  - Add __always_inline to __mutex_lock_common, otherwise reservation paths 
>> can be
>>triggered from normal locks, because __builtin_constant_p might evaluate 
>> to false
>>for the constant 0 in that case. Tests for this have been added in the 
>> next patch.
>>  - Updated documentation slightly.
>> Changes since v2:
>>  - Renamed everything to ww_mutex. (mlankhorst)
>>  - Added ww_acquire_ctx and ww_class. (mlankhorst)
>>  - Added a lot of checks for wrong api usage. (mlankhorst)
>>  - Documentation updates. (danvet)
>>
>> Signed-off-by: Maarten Lankhorst 
>> Signed-off-by: Daniel Vetter 
>> ---
>>  Documentation/ww-mutex-design.txt |  322 +++
>>  include/linux/mutex-debug.h   |1
>>  include/linux/mutex.h |  257 +
>>  kernel/mutex.c|  445 
>> -
>>  lib/debug_locks.c |2
>>  5 files changed, 1010 insertions(+), 17 deletions(-)
>>  create mode 100644 Documentation/ww-mutex-design.txt
>>
>> diff --git a/Documentation/ww-mutex-design.txt 
>> b/Documentation/ww-mutex-design.txt
>> new file mode 100644
>> index 000..154bae3
>> --- /dev/null
>> +++ b/Documentation/ww-mutex-design.txt
>> @@ -0,0 +1,322 @@
>> +Wait/Wound Deadlock-Proof Mutex Design
>> +==
>> +
>> +Please read mutex-design.txt first, as it applies to wait/wound mutexes too.
>> +
>> +Motivation for WW-Mutexes
>> +-
>> +
>> +GPU's do operations that commonly involve many buffers.  Those buffers
>> +can be shared across contexts/processes, exist in different memory
>> +domains (for example VRAM vs system memory), and so on.  And with
>> +PRIME / dmabuf, they can even be shared across devices.  So there are
>> +a handful of situations where the driver needs to wait for buffers to
>> +become ready.  If you think about this in terms of waiting on a buffer
>> +mutex for it to become available, this presents a problem because
>> +there is no way to guarantee that buffers appear in a execbuf/batch in
>> +the same order in all contexts.  That is directly under control of
>> +userspace, and a result of the sequence of GL calls that an application
>> +makes.   Which results in the potential for deadlock.  The problem gets
>> +more complex when you consider that the kernel may need to migrate the
>> +buffer(s) into VRAM before the GPU operates on the buffer(s), which
>> +may in turn require evicting some other buffers (and you don't want to
>> +evict other buffers which are already queued up to the GPU), but for a
>> +simplified understanding of the problem you can ignore this.
>> +
>> +The algorithm that TTM came up with for dealing with this problem is quite
>> +simple.  For each group of buffers (execbuf) that need to be locked, the 
>> caller
>> +would be assigned a unique reservation id/ticket, from a global counter.  In
>> +case of deadlock while locking all the buffers associated with a execbuf, 
>> the
>> +one with the lowest reservation ticket (i.e. the oldest task) wins, and the 
>> one
>> +with the higher reservation id (i.e. the younger task) unlocks all of the
>> +buffers that it has already locked, and then tries again.
>> +
>> +In the RDBMS literature this deadlock handling approach is called 
>> wait/wound:
>> +The older tasks waits until it can acquire the contended lock. The younger 
>> tasks
>> +needs to back off and drop all the locks it is currently holding, i.e. the
>> +younger task is wounded.
>> +
>> +Concepts
>> +
>> +
>> +Compared to normal mutexes two additional concepts/objects show up in the 
>> lock
>> +interface for w/w mutexes:
>> +
>> +Acquire context: To ensure eventual forward progress it is important the a 
>> task
>> +trying to acquire locks doesn't grab a new reservation id, but keeps the 
>> one it
>> +acquired when starting the lock acquisition. This ticket is stored in the
>> +acquire context. Furthermore the acquire context keeps track of debugging 
>> state
>> +to catch w/w mutex interface abuse.
>> +
>> +W/w class: In contrast to normal mutexes the lock class needs to be 
>> expli

Re: [i915] Backlight brighter since 3.9.0

[Daniel Vetter]

On Wed, May 22, 2013 at 6:08 PM, Joakim Plate  wrote:
>> 2013/5/20 Daniel Vetter  ffwll.ch>
>> 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
>>
>
> Does this mean the system is doing RGB full range to limited range
> compression on the raw RGB data it receives from an application?
>
> Ie a video player that want to be able to handle blacker than black
> properly will need to force the GPU into fullrange output to avoid
> the driver internal compression of the signal and handle that itself?

At least on the display I've seen limited range indeed seems to indeed
clamp and full white/black. But ofc if your media player already
outputs limited range, then you need to disable the gpu side ranger
compression.
-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 64850] Second screen black on Pitcairn PRO

[bugzilla-daemon]

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

--- Comment #9 from Jakob Nixdorf  ---
Ok, i tested a few things:

Turning the monitor off/on dosen't do anything, its still black.

Using xrandr to change the mode causes the first monitor to also turn black, I
will upload the output of "dmesg | grep drm" after the xrandr command,
Xorg.0.log doesn't say anything new.

The output of the xrandr command itself (with --verbose) is:

crtc 1: disable
screen 0: 2960x1050 780x277 mm  96.28dpi
crtc 1:1280x1024   75.0 +1680+0 "DVI-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 64850] Second screen black on Pitcairn PRO

[bugzilla-daemon]

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

--- Comment #10 from Jakob Nixdorf  ---
Created attachment 79672
  --> https://bugs.freedesktop.org/attachment.cgi?id=79672&action=edit
dmesg | grep drm after xrandr

-- 
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 64850] Second screen black on Pitcairn PRO

[bugzilla-daemon]

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

--- Comment #11 from Alex Deucher  ---
(In reply to comment #9)
> Ok, i tested a few things:
> 
> Turning the monitor off/on dosen't do anything, its still black.

sorry, I meant using xrandr; e.g., 

xrandr --output DVI-0 --off
xrandr --output DVI-0 --auto

-- 
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 64850] Second screen black on Pitcairn PRO

[bugzilla-daemon]

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

--- Comment #12 from Alex Deucher  ---
Can you also try booting with only one monitor connected?  Does the DVI monitor
work in that case?  Also try booting with one monitor connected and then add
the second one after X is started and see if both are enabled properly in that
case.

-- 
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 64850] Second screen black on Pitcairn PRO

[bugzilla-daemon]

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

--- Comment #13 from Alex Deucher  ---
Do both heads work properly if you temporarily remove your xorg.conf?

-- 
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 64850] Second screen black on Pitcairn PRO

[bugzilla-daemon]

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

--- Comment #14 from Jakob Nixdorf  ---
'xrandr --output DVI-0 --off' causes the first screen (HDMI-0) to turn black
too, and the DVI screen gets really switched off (monitor switches to standby).

Blind-typing 'xrandr --output DVI-0 --auto' turns the DVI screen back on (still
only a black screen) and the HDMI screen also stays black.

-- 
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 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 #40 from Benjamin Lee  ---
(In reply to comment #37)
> Created attachment 79663 [details] [review]
> don't re-post mac cards
> 
> For the non-Macs, this patch should fix the issue:
> http://lists.freedesktop.org/archives/dri-devel/2013-May/038894.html
> 
> For the macs, does the attached patch help?

Yes, with the attached patch UVD initializes successfully on my MacBookPro8,2. 
Thank you!

-- 
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 64850] Second screen black on Pitcairn PRO

[bugzilla-daemon]

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

--- Comment #15 from Jakob Nixdorf  ---
Nothing of the things you suggested worked.

Without xorg.conf the problem is still present.

Booting with only DVI-0 plugged in works fine.
If I plug in HDMI-0 with X11 running everything stays the same and the HDMI
monitor says "No signal", when I try to activate it via xrandr both monitors
switch to black.
If I plug in HDMI-0 in TTY the TTY is switched to the HDMI monitor and the DVI
monitor goes black.

-- 
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 v3 2/3] mutex: add support for wound/wait style locks, v3

[Maarten Lankhorst]

Hey,

Op 22-05-13 18:18, Peter Zijlstra schreef:
> On Wed, May 22, 2013 at 01:18:14PM +0200, Maarten Lankhorst wrote:
>
> Lacking the actual msg atm, I'm going to paste in here...
Thanks for taking the time to review.
>> Subject: [PATCH v3 2/3] mutex: add support for wound/wait style locks, v3
>> From: Maarten Lankhorst 
>>
>> Changes since RFC patch v1:
>>  - Updated to use atomic_long instead of atomic, since the reservation_id 
>> was a long.
>>  - added mutex_reserve_lock_slow and mutex_reserve_lock_intr_slow
>>  - removed mutex_locked_set_reservation_id (or w/e it was called)
>> Changes since RFC patch v2:
>>  - remove use of __mutex_lock_retval_arg, add warnings when using wrong 
>> combination of
>>mutex_(,reserve_)lock/unlock.
>> Changes since v1:
>>  - Add __always_inline to __mutex_lock_common, otherwise reservation paths 
>> can be
>>triggered from normal locks, because __builtin_constant_p might evaluate 
>> to false
>>for the constant 0 in that case. Tests for this have been added in the 
>> next patch.
>>  - Updated documentation slightly.
>> Changes since v2:
>>  - Renamed everything to ww_mutex. (mlankhorst)
>>  - Added ww_acquire_ctx and ww_class. (mlankhorst)
>>  - Added a lot of checks for wrong api usage. (mlankhorst)
>>  - Documentation updates. (danvet)
>>
>> Signed-off-by: Maarten Lankhorst 
>> Signed-off-by: Daniel Vetter 
>> ---
>>  Documentation/ww-mutex-design.txt |  322 +++
>>  include/linux/mutex-debug.h   |1 
>>  include/linux/mutex.h |  257 +
>>  kernel/mutex.c|  445 
>> -
>>  lib/debug_locks.c |2 
>>  5 files changed, 1010 insertions(+), 17 deletions(-)
>>  create mode 100644 Documentation/ww-mutex-design.txt
>>
>> diff --git a/Documentation/ww-mutex-design.txt 
>> b/Documentation/ww-mutex-design.txt
>> new file mode 100644
>> index 000..154bae3
>> --- /dev/null
>> +++ b/Documentation/ww-mutex-design.txt
>> @@ -0,0 +1,322 @@
>> +Wait/Wound Deadlock-Proof Mutex Design
>> +==
>> +
>> +Please read mutex-design.txt first, as it applies to wait/wound mutexes too.
>> +
>> +Motivation for WW-Mutexes
>> +-
>> +
>> +GPU's do operations that commonly involve many buffers.  Those buffers
>> +can be shared across contexts/processes, exist in different memory
>> +domains (for example VRAM vs system memory), and so on.  And with
>> +PRIME / dmabuf, they can even be shared across devices.  So there are
>> +a handful of situations where the driver needs to wait for buffers to
>> +become ready.  If you think about this in terms of waiting on a buffer
>> +mutex for it to become available, this presents a problem because
>> +there is no way to guarantee that buffers appear in a execbuf/batch in
>> +the same order in all contexts.  That is directly under control of
>> +userspace, and a result of the sequence of GL calls that an application
>> +makes.  Which results in the potential for deadlock.  The problem gets
>> +more complex when you consider that the kernel may need to migrate the
>> +buffer(s) into VRAM before the GPU operates on the buffer(s), which
>> +may in turn require evicting some other buffers (and you don't want to
>> +evict other buffers which are already queued up to the GPU), but for a
>> +simplified understanding of the problem you can ignore this.
>> +
>> +The algorithm that TTM came up with for dealing with this problem is quite
>> +simple.  For each group of buffers (execbuf) that need to be locked, the 
>> caller
>> +would be assigned a unique reservation id/ticket, from a global counter.  In
>> +case of deadlock while locking all the buffers associated with a execbuf, 
>> the
>> +one with the lowest reservation ticket (i.e. the oldest task) wins, and the 
>> one
>> +with the higher reservation id (i.e. the younger task) unlocks all of the
>> +buffers that it has already locked, and then tries again.
>> +
>> +In the RDBMS literature this deadlock handling approach is called 
>> wait/wound:
>> +The older tasks waits until it can acquire the contended lock. The younger 
>> tasks
>> +needs to back off and drop all the locks it is currently holding, i.e. the
>> +younger task is wounded.
>> +
>> +Concepts
>> +
>> +
>> +Compared to normal mutexes two additional concepts/objects show up in the 
>> lock
>> +interface for w/w mutexes:
>> +
>> +Acquire context: To ensure eventual forward progress it is important the a 
>> task
>> +trying to acquire locks doesn't grab a new reservation id, but keeps the 
>> one it
>> +acquired when starting the lock acquisition. This ticket is stored in the
>> +acquire context. Furthermore the acquire context keeps track of debugging 
>> state
>> +to catch w/w mutex interface abuse.
>> +
>> +W/w class: In contrast to normal mutexes the lock class needs to be 
>> explicit for
>> +w/w mutexes, since it is required to initializ

[PATCH] drm/radeon: revert Apple re-POST hack

[alexdeucher]

From: Alex Deucher 

This reverts:
drm/radeon: re-POST the asic on Apple hardware when booted via EFI

That patch prevents UVD from working on macs when booted in EFI
mode.  The original patch may not be required any more due to other
fixes for UEFI on non-Mac platforms, but I don't have any Macs.

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

Cc: Matthew Garrett 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/radeon_device.c |4 
 1 files changed, 0 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index af82c9b..261fe11 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -467,10 +467,6 @@ bool radeon_card_posted(struct radeon_device *rdev)
 {
uint32_t reg;
 
-   if (efi_enabled(EFI_BOOT) &&
-   rdev->pdev->subsystem_vendor == PCI_VENDOR_ID_APPLE)
-   return false;
-
if (ASIC_IS_NODCE(rdev))
goto check_memsize;
 
-- 
1.7.7.5

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

[Bug 64877] New: R600 OpenCL Regression since e917ed96ae38f

[bugzilla-daemon]

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

  Priority: medium
Bug ID: 64877
  Assignee: dri-devel@lists.freedesktop.org
   Summary: R600 OpenCL Regression since e917ed96ae38f
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: awa...@gmail.com
  Hardware: All
Status: NEW
   Version: git
 Component: Drivers/Gallium/r600
   Product: Mesa

Created attachment 79681
  --> https://bugs.freedesktop.org/attachment.cgi?id=79681&action=edit
Test case that passed before the bisected commit and fails on git head

Using the piglit
generated_tests/cl/builtin/int/builtin-int-min-1.1.generated.cl scalar test
cases (attached min.cl), results went from all passing to about half of the
test cases failing with the following commit:

Hardware:
Radeon HD 5400 series
Radeon HD 6850

e917ed96ae38fc382bac50a6536d761b829ac8cd is the first bad commit
commit e917ed96ae38fc382bac50a6536d761b829ac8cd
Author: Tom Stellard 
Date:   Fri May 3 11:15:55 2013 -0700

r600g/llvm: Don't emit CALL_FS for vertex shaders

The LLVM backend takes care of this now.


Each stage of the bisect was run using the matching LLVM revision specified in
mesa/src/gallium/drivers/radeon/LLVM_REVISION.txt

-- 
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 64877] R600 OpenCL Regression since e917ed96ae38f

[bugzilla-daemon]

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

Aaron Watry  changed:

   What|Removed |Added

   Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
   |.org|org

-- 
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 64879] New: i915 doesn't do derivatives, neither gallium nor intel driver

[bugzilla-daemon]

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

  Priority: medium
Bug ID: 64879
CC: i...@freedesktop.org
  Assignee: dri-devel@lists.freedesktop.org
   Summary: i915 doesn't do derivatives, neither gallium nor intel
driver
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: fjhmesa...@gmail.com
  Hardware: Other
Status: NEW
   Version: git
 Component: Drivers/Gallium/i915g
   Product: Mesa

Any way to support dFdx() on i915?

-- 
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 64879] i915 doesn't do derivatives, neither gallium nor intel driver

[bugzilla-daemon]

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

Eric Anholt  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #1 from Eric Anholt  ---
Other than the sw fallback, no.

-- 
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 64801] KMS/R7xx - [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!

[bugzilla-daemon]

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

--- Comment #4 from Philip Prindeville  ---
Do I need to add anything else?

-- 
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 58671] New: Nvidia drivers fail compile

[bugzilla-daemon]

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

   Summary: Nvidia drivers fail compile
   Product: Drivers
   Version: 2.5
Kernel Version: 3.10-rc*
  Platform: All
OS/Version: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
AssignedTo: drivers_video-...@kernel-bugs.osdl.org
ReportedBy: acidph...@gmail.com
Regression: No


Since 3.10-rc1 the proprietary nvidia drivers fail to build against the kernels
rc1 and rc2. Attached is the build log.

Running Gentoo x86_64 (amd64), Even though in this attempt I tried to merge the 
319.17 version I had also tried previous versions with the same result.

-- 
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 58671] Nvidia drivers fail compile

[bugzilla-daemon]

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





--- Comment #1 from Acidphase   2013-05-22 21:05:09 ---
Created an attachment (id=102271)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=102271)
Build Log from portage

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

Re: [RFC 6/8] drm/i2c: nxp-tda998x: add video and audio input configuration

[Rob Clark]

On Thu, May 16, 2013 at 3:27 PM, Russell King
 wrote:
> Signed-off-by: Russell King 
> ---
>  drivers/gpu/drm/i2c/tda998x_drv.c |  308 
> -
>  1 files changed, 301 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
> b/drivers/gpu/drm/i2c/tda998x_drv.c
> index d6afd02..8ffb844 100644
> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> @@ -23,7 +23,7 @@
>  #include 
>  #include 
>  #include 
> -
> +#include 
>
>  #define DBG(fmt, ...) DRM_DEBUG(fmt"\n", ##__VA_ARGS__)
>
> @@ -32,9 +32,11 @@ struct tda998x_priv {
> uint16_t rev;
> uint8_t current_page;
> int dpms;
> +   bool is_hdmi_sink;
> u8 vip_cntrl_0;
> u8 vip_cntrl_1;
> u8 vip_cntrl_2;
> +   struct tda998x_encoder_params params;
>  };
>
>  #define to_tda998x_priv(x)  ((struct tda998x_priv 
> *)to_encoder_slave(x)->slave_priv)
> @@ -71,10 +73,13 @@ struct tda998x_priv {
>  # define I2C_MASTER_DIS_MM(1 << 0)
>  # define I2C_MASTER_DIS_FILT  (1 << 1)
>  # define I2C_MASTER_APP_STRT_LAT  (1 << 2)
> +#define REG_FEAT_POWERDOWNREG(0x00, 0x0e) /* read/write */
> +# define FEAT_POWERDOWN_SPDIF (1 << 3)
>  #define REG_INT_FLAGS_0   REG(0x00, 0x0f) /* read/write */
>  #define REG_INT_FLAGS_1   REG(0x00, 0x10) /* read/write */
>  #define REG_INT_FLAGS_2   REG(0x00, 0x11) /* read/write */
>  # define INT_FLAGS_2_EDID_BLK_RD  (1 << 1)
> +#define REG_ENA_ACLK  REG(0x00, 0x16) /* read/write */
>  #define REG_ENA_VP_0  REG(0x00, 0x18) /* read/write */
>  #define REG_ENA_VP_1  REG(0x00, 0x19) /* read/write */
>  #define REG_ENA_VP_2  REG(0x00, 0x1a) /* read/write */
> @@ -113,6 +118,7 @@ struct tda998x_priv {
>  #define REG_VIP_CNTRL_5   REG(0x00, 0x25) /* write */
>  # define VIP_CNTRL_5_CKCASE   (1 << 0)
>  # define VIP_CNTRL_5_SP_CNT(x)(((x) & 3) << 1)
> +#define REG_MUX_APREG(0x00, 0x26) /* read/write */
>  #define REG_MUX_VP_VIP_OUTREG(0x00, 0x27) /* read/write */
>  #define REG_MAT_CONTRLREG(0x00, 0x80) /* write */
>  # define MAT_CONTRL_MAT_SC(x) (((x) & 3) << 0)
> @@ -175,6 +181,12 @@ struct tda998x_priv {
>  # define HVF_CNTRL_1_PAD(x)   (((x) & 3) << 4)
>  # define HVF_CNTRL_1_SEMI_PLANAR  (1 << 6)
>  #define REG_RPT_CNTRL REG(0x00, 0xf0) /* write */
> +#define REG_I2S_FORMATREG(0x00, 0xfc) /* read/write */
> +# define I2S_FORMAT(x)(((x) & 3) << 0)
> +#define REG_AIP_CLKSELREG(0x00, 0xfd) /* write */
> +# define AIP_CLKSEL_FS(x) (((x) & 3) << 0)
> +# define AIP_CLKSEL_CLK_POL(x)(((x) & 1) << 2)
> +# define AIP_CLKSEL_AIP(x)(((x) & 7) << 3)
>
>
>  /* Page 02h: PLL settings */
> @@ -216,6 +228,11 @@ struct tda998x_priv {
>
>
>  /* Page 10h: information frames and packets */
> +#define REG_IF1_HB0   REG(0x10, 0x20) /* read/write */
> +#define REG_IF2_HB0   REG(0x10, 0x40) /* read/write */
> +#define REG_IF3_HB0   REG(0x10, 0x60) /* read/write */
> +#define REG_IF4_HB0   REG(0x10, 0x80) /* read/write */
> +#define REG_IF5_HB0   REG(0x10, 0xa0) /* read/write */
>
>
>  /* Page 11h: audio settings and content info packets */
> @@ -225,10 +242,33 @@ struct tda998x_priv {
>  # define AIP_CNTRL_0_LAYOUT   (1 << 2)
>  # define AIP_CNTRL_0_ACR_MAN  (1 << 5)
>  # define AIP_CNTRL_0_RST_CTS  (1 << 6)
> +#define REG_CA_I2SREG(0x11, 0x01) /* read/write */
> +# define CA_I2S_CA_I2S(x) (((x) & 31) << 0)
> +# define CA_I2S_HBR_CHSTAT(1 << 6)
> +#define REG_LATENCY_RDREG(0x11, 0x04) /* read/write */
> +#define REG_ACR_CTS_0 REG(0x11, 0x05) /* read/write */
> +#define REG_ACR_CTS_1 REG(0x11, 0x06) /* read/write */
> +#define REG_ACR_CTS_2 REG(0x11, 0x07) /* read/write */
> +#define REG_ACR_N_0   REG(0x11, 0x08) /* read/write */
> +#define REG_ACR_N_1   REG(0x11, 0x09) /* read/write */
> +#define REG_ACR_N_2   REG(0x11, 0x0a) /* read/write */
> +#define REG_CTS_N REG(0x11, 0x0c) /* read/write */
> +# define CTS_N_K(x)   (((x) & 7) << 0)
> +# define CTS_N_M(x)   (((x) & 3) << 4)
>  #define REG_ENC_CNTRL REG(0x11, 0x0d) /* read/write */
>  # define ENC_CNTRL_RST_ENC(1 << 0)
>  # define ENC_CNTRL_RST_SEL(1 << 1)
>  # define ENC_CNTRL_CTL_CODE(x)(((x) & 3) << 2)
> +#define REG_DIP_FLAGS REG(0x11, 0x0e) /* read/write */
> +# define DIP_FLAGS_ACR(1 << 0)
> +# define DIP_FLAGS_GC (1 << 1)
> +#define REG_DIP_IF_FLAGS  REG(0x11, 0x0f) /* read/write */
> +# define DIP_IF_FLAGS_IF1 (1 <

[Bug 64738] graphics corruption with glamor

[bugzilla-daemon]

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

--- Comment #7 from Alexander Tsoy  ---
(In reply to comment #6)

Yes, glamor Git works good. But icons in notification area still missing.

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

[PATCH] drm: Cocci spatch "memdup.spatch"

[Thomas Meyer]

Signed-off-by: Thomas Meyer 
---

diff -u -p a/drivers/gpu/drm/drm_edid_load.c b/drivers/gpu/drm/drm_edid_load.c
--- a/drivers/gpu/drm/drm_edid_load.c
+++ b/drivers/gpu/drm/drm_edid_load.c
@@ -186,12 +186,11 @@ static u8 *edid_load(struct drm_connecto
goto relfw_out;
}
 
-   edid = kmalloc(fwsize, GFP_KERNEL);
+   edid = kmemdup(fwdata, fwsize, GFP_KERNEL);
if (edid == NULL) {
err = -ENOMEM;
goto relfw_out;
}
-   memcpy(edid, fwdata, fwsize);
 
if (!drm_edid_block_valid(edid, 0, print_bad_edid)) {
connector->bad_edid_counter++;


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

[PATCH] drm/i915: Cocci spatch "memdup.spatch"

[Thomas Meyer]

Signed-off-by: Thomas Meyer 
---

diff -u -p a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2282,11 +2282,10 @@ intel_dp_get_edid(struct drm_connector *
return NULL;
 
size = (intel_connector->edid->extensions + 1) * EDID_LENGTH;
-   edid = kmalloc(size, GFP_KERNEL);
+   edid = kmemdup(intel_connector->edid, size, GFP_KERNEL);
if (!edid)
return NULL;
 
-   memcpy(edid, intel_connector->edid, size);
return edid;
}
 


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

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

[bugzilla-daemon]

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

--- Comment #2 from Rafael Castillo  ---
yes, effectively setting this environment variable works fine it seems.

only thing is weston give this warning, not sure if important

EGL_EXT_buffer_age not supported. Performance could be affected

-- 
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 64801] KMS/R7xx - [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!

[bugzilla-daemon]

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

--- Comment #5 from Philip Prindeville  ---
And this might be unrelated, but when I swapped out DVI cables this apparently
hosed my X server and I got:


May 19 11:01:01 builder NetworkManager[587]:  error requesting auth for
org.freedesktop.NetworkManager.wifi.share.protected: (3)
GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner:
GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not get UID of
name ':1.71': no such name
May 19 11:01:01 builder NetworkManager[587]:  error requesting auth for
org.freedesktop.NetworkManager.wifi.share.open: (3)
GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner:
GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not get UID of
name ':1.71': no such name
May 19 11:01:01 builder NetworkManager[587]:  error requesting auth for
org.freedesktop.NetworkManager.wifi.share.protected: (3)
GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner:
GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not get UID of
name ':1.71': no such name
May 19 11:01:01 builder NetworkManager[587]:  error requesting auth for
org.freedesktop.NetworkManager.wifi.share.open: (3)
GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner:
GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not get UID of
name ':1.71': no such name
May 19 11:01:01 builder NetworkManager[587]:  error requesting auth for
org.freedesktop.NetworkManager.wifi.share.protected: (3)
GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner:
GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not get UID of
name ':1.71': no such name
May 19 11:01:01 builder NetworkManager[587]:  error requesting auth for
org.freedesktop.NetworkManager.wifi.share.open: (3)
GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner:
GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not get UID of
name ':1.71': no such name
May 20 11:01:01 localhost NetworkManager[527]:  error requesting auth for
org.freedesktop.NetworkManager.wifi.share.protected: (3)
GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner:
GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not get UID of
name ':1.64': no such name
May 20 11:01:01 localhost NetworkManager[527]:  error requesting auth for
org.freedesktop.NetworkManager.wifi.share.open: (3)
GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner:
GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not get UID of
name ':1.64': no such name
May 20 11:01:01 localhost NetworkManager[527]:  error requesting auth for
org.freedesktop.NetworkManager.wifi.share.protected: (3)
GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner:
GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not get UID of
name ':1.64': no such name
May 20 11:01:01 localhost NetworkManager[527]:  error requesting auth for
org.freedesktop.NetworkManager.wifi.share.open: (3)
GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner:
GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not get UID of
name ':1.64': no such name
May 20 11:01:02 localhost NetworkManager[527]:  error requesting auth for
org.freedesktop.NetworkManager.wifi.share.protected: (3)
GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner:
GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not get UID of
name ':1.64': no such name
May 20 11:01:02 localhost NetworkManager[527]:  error requesting auth for
org.freedesktop.NetworkManager.wifi.share.open: (3)
GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner:
GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not get UID of
name ':1.64': no such name
May 20 11:01:02 localhost NetworkManager[527]:  error requesting auth for
org.freedesktop.NetworkManager.wifi.share.protected: (3)
GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner:
GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not get UID of
name ':1.64': no such name
May 20 11:01:02 localhost NetworkManager[527]:  error requesting auth for
org.freedesktop.NetworkManager.wifi.share.open: (3)
GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner:
GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not get UID of
name ':1.64': no such name
May 21 11:01:01 localhost NetworkManager[527]:  error requesting auth for
org.freedesktop.NetworkManager.wifi.share.protected: (3)
GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner:
GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not get UID of
name ':1.64': no such name
May 21 11:01:01 localhost NetworkManager[527]:  error requesting auth for
org.freedesktop.NetworkManager.wifi.share.open: (3)
GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner:
GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not get UID of
name ':1.64': no such name
May 21 11:01:01 localhost NetworkManager[527]:  error requesting auth for
org.freedesktop.NetworkManager.wifi.share.protected: (3)
GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner:
GDBus.Error:org.freedesktop.DBus.Er

[Bug 64776] [9.1.2]"GPU fault detected" whit "eclipse juno" crash system

[bugzilla-daemon]

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

--- Comment #7 from mombelli.ma...@gmail.com ---
uff tryed now but i have to recompile LLVM from git as my distribution has
only 3.2.. i'll try again next time with some spare time.
Thanks anyway


2013/5/22 

>   *Comment # 6  on bug
> 64776  from Michel
> Dänzer  *
>
> Created attachment 79647 
>  [details] 
>  [review] 
> 
> radeonsi: Make sure disabled colour buffers are disabled in the CB state
>
> Does this Mesa patch help?
>
>  --
> You are receiving this mail because:
>
>- You reported the bug.
>
>

-- 
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 0/4] drm/exynos: code cleanups

[Inki Dae]

Applied.

Thanks,
Inki Dae


2013/5/22 Seung-Woo Kim 

> Build warnings of ipp fimc is fixed and device pointer usage is
> simplified as directly using dev variable.
>
> devm related fixes are also appiled: meaningless devm_kfree is
> removed and request_threaded_irq is replaced to devm function.
>
> Seung-Woo Kim (4):
>   drm/exynos: cleanup device pointer usages
>   drm/exynos: fix build warnings from ipp fimc
>   drm/exynos: remove unnecessary devm_kfree
>   drm/exynos: replace request_threaded_irq with devm function
>
>  drivers/gpu/drm/exynos/exynos_drm_fimc.c|   12 
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c|   10 +-
>  drivers/gpu/drm/exynos/exynos_drm_g2d.c |6 +++---
>  drivers/gpu/drm/exynos/exynos_drm_gsc.c |   12 +++-
>  drivers/gpu/drm/exynos/exynos_drm_hdmi.c|2 +-
>  drivers/gpu/drm/exynos/exynos_drm_ipp.c |4 ++--
>  drivers/gpu/drm/exynos/exynos_drm_rotator.c |   13 +++--
>  drivers/gpu/drm/exynos/exynos_drm_vidi.c|4 ++--
>  drivers/gpu/drm/exynos/exynos_hdmi.c|   21 -
>  drivers/gpu/drm/exynos/exynos_mixer.c   |   14 +++---
>  10 files changed, 38 insertions(+), 60 deletions(-)
>
> --
> 1.7.4.1
>
> ___
> 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] drm/i915: Cocci spatch "memdup.spatch"

[Daniel Vetter]

On Wed, May 22, 2013 at 11:07:09PM +0200, Thomas Meyer wrote:
> 
> Signed-off-by: Thomas Meyer 

Queued for -next, thanks for the patch.
-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

[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  wrote:
> From: Rob Clark 
>
> The event wouldn't be on any list at this point, so nothing to delete
> it from.
>
> Signed-off-by: Rob Clark 
> ---
>  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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[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  wrote:
> From: Rob Clark 
>
> 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 
> ---
>  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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[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  wrote:
> From: Rob Clark 
>
> Signed-off-by: Rob Clark 
> ---
>  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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[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:airlied at gmail.com]
> Sent: Wednesday, May 22, 2013 8:20 AM
> To: Inki Dae
> Cc: dri-devel at 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  wrote:
> > From: Rob Clark 
> >
> > Signed-off-by: Rob Clark 
> > ---
> >  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 at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Inki Dae]

> -Original Message-
> From: Dave Airlie [mailto:airlied at gmail.com]
> Sent: Wednesday, May 22, 2013 8:17 AM
> To: Inki Dae
> Cc: dri-devel at 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  wrote:
> > From: Rob Clark 
> >
> > The event wouldn't be on any list at this point, so nothing to delete
> > it from.
> >
> > Signed-off-by: Rob Clark 
> > ---
> >  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 at 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 

Rebased.

Signed-off-by: Rob Clark 
Signed-off-by: Inki Dae 
---
 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

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

[Inki Dae]

>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 at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130522/6b68ec17/attachment.html>

[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 
>
> Rebased.
>
> Signed-off-by: Rob Clark 
> Signed-off-by: Inki Dae 
> ---
>   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.

[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

--- Comment #15 from romulasry at 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.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130522/49ca0b8d/attachment.html>

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 Rothwellsfr at canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
-- 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/20130522/c2720507/attachment.pgp>

[Bug 64850] New: Second screen black on Pitcairn PRO

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

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

  Priority: medium
Bug ID: 64850
  Assignee: dri-devel at lists.freedesktop.org
   Summary: Second screen black on Pitcairn PRO
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: flocke at shadowice.org
  Hardware: Other
Status: NEW
   Version: XOrg CVS
 Component: DRM/Radeon
   Product: DRI

Created attachment 79637
  --> https://bugs.freedesktop.org/attachment.cgi?id=79637&action=edit
dmesg | grep drm right after boot (no X11)

I just installed my new Pitcairn PRO card (Radeon 7850) in my PC.

Every time I boot into linux (Arch Linux x86_64) my second monitor turns black
right at boot.
There are no errors and I can even start X11 with my dual-monitor configuration
and move the mouse from my first screen to the right. It is as if the screen is
there, only my monitor doesn't show it.

This happens not in X11, in fact the secend screen goes black as soon as the
kernel/kms is loaded.

I attached the output of 'dmesg | grep drm' with the drm.debug=15 kernel option
right after booting and befor starting X11 and I will attach the same commands
output after running X11.

-- 
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/20130522/8a1d5b0a/attachment.html>

[Bug 64850] Second screen black on Pitcairn PRO

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

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

--- Comment #1 from Jakob Nixdorf  ---
Created attachment 79638
  --> https://bugs.freedesktop.org/attachment.cgi?id=79638&action=edit
dmesg | grep drm after X11 start

-- 
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/20130522/24e25195/attachment.html>

[Bug 64850] Second screen black on Pitcairn PRO

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

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

--- Comment #2 from Jakob Nixdorf  ---
Forgot some information, as always ;)

I tried it with a self-build kernel 3.10-rc2 and the Arch Linux stock 3.9.3,
both with the same result. Will try some older kernels soon.

-- 
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/20130522/95491c89/attachment.html>

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

[Inki Dae]

   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 at lists.freedesktop.org
> >> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> >> ___
> >> dri-devel mailing list
> >> dri-devel at lists.freedesktop.org
> >> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> >
> ___
> 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/20130522/d2369e31/attachment-0001.html>

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

[Inki Dae]

ll be returned just.



> Thanks,
> Inki Dae
>
>
>>
>> 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);
>> >> > --
>> >> > 1.7.5.4
>> >> >
>> >> > ___
>> >> > dri-devel mailing list
>> >> > dri-devel at lists.freedesktop.org
>> >> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
>> >> ___
>> >> dri-devel mailing list
>> >> dri-devel at lists.freedesktop.org
>> >> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>> >
>> >
>> ___
>> 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/20130522/7f1f9df6/attachment.html>

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

[Inki Dae]

2013/5/22 Joonyoung Shim 

> Hi,
>
>
> On 05/22/2013 01:04 PM, Inki Dae wrote:
>
>> From: Rob Clark 
>>
>> Rebased.
>>
>> Signed-off-by: Rob Clark 
>> Signed-off-by: Inki Dae 
>> ---
>>   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.
>
>
Good point. :) Will resend it.

Thanks,
Inki Dae


> Thanks.
>
> __**_____
> dri-devel mailing list
> dri-devel at lists.freedesktop.**org 
> http://lists.freedesktop.org/**mailman/listinfo/dri-devel<http://lists.freedesktop.org/mailman/listinfo/dri-devel>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130522/cc347709/attachment.html>

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

[Inki Dae]

From: Rob Clark 

Rebased.

Signed-off-by: Rob Clark 
Signed-off-by: Inki Dae 
---
 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..c6b2dbc 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,13 +410,8 @@ 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);
+   list_del(&e->base.link);
+   drm_send_vblank_event(dev, -1, e);
drm_vblank_put(dev, crtc);
}

-- 
1.7.5.4

[pull] drm-intel-fixes

[Daniel Vetter]

On Wed, May 22, 2013 at 3:24 AM, St?phane Marchesin
 wrote:
> 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.

Presuming the patch works as advertised it only stops publishing an
intel backlight driver which won't work. How does that break stuff?

Or do you somehow update the max blc stuff only once i915.ko is loaded?

I'm decently confused how that one blows up ...

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

[Bug 64850] Second screen black on Pitcairn PRO

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

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

--- Comment #3 from Jakob Nixdorf  ---
Update:

I tested the Arch Linux kernels 3.9.2 and 3.8.11 with the same result.

And, in case it is important, I noticed this line in dmesg:

[3.169540] radeon :01:00.0: Invalid ROM contents

I hope this can help further.

-- 
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/20130522/9fc0c45c/attachment.html>

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

[Tomasz Figa]

Hi Inki,

On Wednesday 22 of May 2013 15:37:14 Inki Dae wrote:
> 2013/5/22 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.g
> > it;a=commitdiff;h=2e77cd4e423967862ca01b1af82aa8b5b7429fc4;hp=aba002da
> > 4c6e5efec4d43e1ce33930a79269349a
> > 
> > 
> > http://git.chromium.org/gitweb/?p=chromiumos/third_party/kernel-next.g
> > it;a=commitdiff;h=b4ec8bfa750ef43a43c2da746c8afdbb51002882;hp=4f28b9a7
> > 5c928f229443d7c6c3163159ceb6903a> 
> > >> 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.
> 
> What is mean? does mainline kernel have the attribution? if not so, we
> don't need to consider it. And please know that I can not be aware of
> you have such patch set without any posting.
> 

at?tri?bu?tion 
n.
1. The act of attributing, especially the act of establishing a particular 
person as the creator of a work of art
[1]

So yes, mainline kernel has attribution. Actually posting something as 
work of someone that is not the author of the posted work is considered 
bad everywhere, isn't it?

However looking at those two patches linked by St?phane, I'm not really 
sure this patch is really just a squash of them. St?phane, are you 100% 
sure that your claims are true?

Best regards,
Tomasz

[1] http://www.thefreedictionary.com/attribution

> > > 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(&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.
> 
> Understood. Right, drm_vblank_get call before wait_event and
> drm_vblank_put call after wait_event.
> 
> Thanks,
> Inki Dae
> 
> > 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,

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

[Kyungmin Park]

mic_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.
> >
> > Understood. Right, drm_vblank_get call before wait_event and
> > drm_vblank_put call after wait_event.
> >
> > Thanks,
> > Inki Dae
> >
> > > 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_w
> > > >> > ait);
> > > >> > 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 at lists.freedesktop.org
> > > >> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> > > >>
> > > >> ___
> > > >> dri-devel mailing list
> > > >> dri-devel at lists.freedesktop.org
> > > >> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> > >
> > > ___
> > > dri-devel mailing list
> > > dri-devel at lists.freedesktop.org
> > > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130522/a655581f/attachment-0001.html>

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

[Inki Dae]

tic 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.
> >
> > Understood. Right, drm_vblank_get call before wait_event and
> > drm_vblank_put call after wait_event.
> >
> > Thanks,
> > Inki Dae
> >
> > > 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_w
> > > >> > ait);
> > > >> > 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 at lists.freedesktop.org
> > > >> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> > > >>
> > > >> ___
> > > >> dri-devel mailing list
> > > >> dri-devel at lists.freedesktop.org
> > > >> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> > >
> > > ___
> > > dri-devel mailing list
> > > dri-devel at lists.freedesktop.org
> > > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130522/dd0614e5/attachment.html>

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

[Inki Dae]

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.
>> >
>> > Understood. Right, drm_vblank_get call before wait_event and
>> > drm_vblank_put call after wait_event.
>> >
>> > Thanks,
>> > Inki Dae
>> >
>> > > 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_w
>> > > >> > ait);
>> > > >> > 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 at lists.freedesktop.org
>> > > >> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
>> > > >>
>> > > >> ___
>> > > >> dri-devel mailing list
>> > > >> dri-devel at lists.freedesktop.org
>> > > >> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>> > >
>> > > ___
>> > > dri-devel mailing list
>> > > dri-devel at lists.freedesktop.org
>> > > http://lists.freedesktop.org/mailman/listinfo/dri-devel
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>
>
> ___
> 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/20130522/0a535db3/attachment-0001.html>

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

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

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

--- Comment #1 from Michel D?nzer  ---
Does setting the environment variable EGL_DRIVER=egl_dri2 help?

-- 
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/20130522/c2f7606e/attachment.html>

[PATCH v3 2/3] mutex: add support for wound/wait style locks, v3

[Maarten Lankhorst]

Hey,

Op 30-04-13 21:14, Daniel Vetter schreef:
> On Sun, Apr 28, 2013 at 07:04:07PM +0200, Maarten Lankhorst wrote:
>> Changes since RFC patch v1:
>>  - Updated to use atomic_long instead of atomic, since the reservation_id 
>> was a long.
>>  - added mutex_reserve_lock_slow and mutex_reserve_lock_intr_slow
>>  - removed mutex_locked_set_reservation_id (or w/e it was called)
>> Changes since RFC patch v2:
>>  - remove use of __mutex_lock_retval_arg, add warnings when using wrong 
>> combination of
>>mutex_(,reserve_)lock/unlock.
>> Changes since v1:
>>  - Add __always_inline to __mutex_lock_common, otherwise reservation paths 
>> can be
>>triggered from normal locks, because __builtin_constant_p might evaluate 
>> to false
>>for the constant 0 in that case. Tests for this have been added in the 
>> next patch.
>>  - Updated documentation slightly.
>> Changes since v2:
>>  - Renamed everything to ww_mutex. (mlankhorst)
>>  - Added ww_acquire_ctx and ww_class. (mlankhorst)
>>  - Added a lot of checks for wrong api usage. (mlankhorst)
>>  - Documentation updates. (danvet)
> While writing the kerneldoc I've carefully check that all restrictions are
> enforced through debug checks somehow. I think that with full mutex debug
> (including lockdep) enabled, plus the slowpath injector patch I've just
> posted, _all_ interface abuse will be catched at runtime as long as all
> the single-threaded/uncontended cases are exercises sufficiently.
>
> So I think we've fully achieved level 5 on the Rusty API safety scale
> here. Higher levels seem pretty hard given that the concepts are rather
> fancy, but I think with the new (and much more consitent) naming, plus the
> explicit introduction as (more abstruct) structures for ww_class and
> ww_acquire_context the interface is about as intuitive as it gets.
>
> So all together I'm pretty happy with what the interface looks like. And
> one quick bikeshed below on the implementation.
> -Daniel
I included your fix below. I'm hoping to get this included in 3.11 through the 
drm tree, so
I can convert ttm to use it, but I haven't received any further reply on the 
patch series.

The 3.10 mutex improvement patches don't seem to cause any conflicts when 
merging
linus' tree, so I'll use drm-next as a base.

Are there any issues left? I included the patch you wrote for injecting 
-EDEADLK too
in my tree. The overwhelming silence makes me think there are either none, or
nobody cared enough to review it. :(

>> +/*
>> + * after acquiring lock with fastpath or when we lost out in contested
>> + * slowpath, set ctx and wake up any waiters so they can recheck.
>> + *
>> + * This function is never called when CONFIG_DEBUG_LOCK_ALLOC is set,
>> + * as the fastpath and opportunistic spinning are disabled in that case.
>> + */
>> +static __always_inline void
>> +ww_mutex_set_context_fastpath(struct ww_mutex *lock,
>> +   struct ww_acquire_ctx *ctx)
>> +{
>> +unsigned long flags;
>> +struct mutex_waiter *cur;
>> +
>> +ww_mutex_lock_acquired(lock, ctx, false);
>> +
>> +lock->ctx = ctx;
>> +smp_mb__after_atomic_dec();
> I think this should be
>
> + smp_mb__after_atomic_dec();
> + lock->ctx = ctx;
> + smp_mb();
>
> Also I wonder a bit how much this hurts the fastpath, and whether we
> should just shovel the ctx into the atomic field with a cmpxcht, like the
> rt mutex code does with the current pointer.
>
Fixed. I'm not sure if the second smp_mb is really needed. If there was a
smp_mb__before_atomic_read it would have been sufficient.

~Maarten

[Bug 64776] [9.1.2]"GPU fault detected" whit "eclipse juno" crash system

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

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

--- Comment #6 from Michel D?nzer  ---
Created attachment 79647
  --> https://bugs.freedesktop.org/attachment.cgi?id=79647&action=edit
radeonsi: Make sure disabled colour buffers are disabled in the CB state

Does this Mesa patch help?

-- 
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/20130522/17ac7fc3/attachment.html>

[PATCH v3 2/3] mutex: add support for wound/wait style locks, v3

[Peter Zijlstra]

> Are there any issues left? I included the patch you wrote for injecting 
> -EDEADLK too
> in my tree. The overwhelming silence makes me think there are either none, or
> nobody cared enough to review it. :(

It didn't manage to reach my inbox it seems,.. I can only find a debug
patch in this thread.

[PATCH v3 2/3] mutex: add support for wound/wait style locks, v3

[Maarten Lankhorst]

Op 22-05-13 13:37, Peter Zijlstra schreef:
>> Are there any issues left? I included the patch you wrote for injecting 
>> -EDEADLK too
>> in my tree. The overwhelming silence makes me think there are either none, or
>> nobody cared enough to review it. :(
> It didn't manage to reach my inbox it seems,.. I can only find a debug
> patch in this thread.
>
Odd, maybe in your spam folder?
It arrived on all mailing lists, so I have no idea why you were left out.

http://www.spinics.net/lists/linux-arch/msg21425.html


~Maarten

[PATCH v3 2/3] mutex: add support for wound/wait style locks, v3

[Peter Zijlstra]

On Wed, May 22, 2013 at 01:47:42PM +0200, Maarten Lankhorst wrote:
> Op 22-05-13 13:37, Peter Zijlstra schreef:
> >> Are there any issues left? I included the patch you wrote for injecting 
> >> -EDEADLK too
> >> in my tree. The overwhelming silence makes me think there are either none, 
> >> or
> >> nobody cared enough to review it. :(
> > It didn't manage to reach my inbox it seems,.. I can only find a debug
> > patch in this thread.
> >
> Odd, maybe in your spam folder?

Couldn't spot it there either.. weird.

> It arrived on all mailing lists,

I should both clean up my one huge lkml maildir and hack notmuch into
submission so I can read LKML again :/

> so I have no idea why you were left out.
> 
> http://www.spinics.net/lists/linux-arch/msg21425.html

Thanks, I'll go stare at it.

[PATCH 2/4] drm/exynos: fix build warnings from ipp fimc

[Seung-Woo Kim]

Becuase of order of headers, there are build warnings and they are
fixed with this patch.

Signed-off-by: Seung-Woo Kim 
---
 drivers/gpu/drm/exynos/exynos_drm_fimc.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 754d760..75c50f5 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -12,9 +12,9 @@
  *
  */
 #include 
-#include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
-- 
1.7.4.1

[PATCH 3/4] drm/exynos: remove unnecessary devm_kfree

[Seung-Woo Kim]

devm_kfree does not need for fail case of probe function and for
remove function.

Signed-off-by: Seung-Woo Kim 
---
 drivers/gpu/drm/exynos/exynos_drm_gsc.c |2 --
 drivers/gpu/drm/exynos/exynos_drm_rotator.c |2 --
 2 files changed, 0 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index 487595a..98032d6 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -1748,7 +1748,6 @@ static int gsc_probe(struct platform_device *pdev)
return 0;

 err_ippdrv_register:
-   devm_kfree(dev, ippdrv->prop_list);
pm_runtime_disable(dev);
 err_get_irq:
free_irq(ctx->irq, ctx);
@@ -1761,7 +1760,6 @@ static int gsc_remove(struct platform_device *pdev)
struct gsc_context *ctx = get_gsc_context(dev);
struct exynos_drm_ippdrv *ippdrv = &ctx->ippdrv;

-   devm_kfree(dev, ippdrv->prop_list);
exynos_drm_ippdrv_unregister(ippdrv);
mutex_destroy(&ctx->lock);

diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c 
b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
index 947f09f..3aa502a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
@@ -709,7 +709,6 @@ static int rotator_probe(struct platform_device *pdev)
return 0;

 err_ippdrv_register:
-   devm_kfree(dev, ippdrv->prop_list);
pm_runtime_disable(dev);
 err_clk_get:
free_irq(rot->irq, rot);
@@ -722,7 +721,6 @@ static int rotator_remove(struct platform_device *pdev)
struct rot_context *rot = dev_get_drvdata(dev);
struct exynos_drm_ippdrv *ippdrv = &rot->ippdrv;

-   devm_kfree(dev, ippdrv->prop_list);
exynos_drm_ippdrv_unregister(ippdrv);

pm_runtime_disable(dev);
-- 
1.7.4.1

[PATCH 0/4] drm/exynos: code cleanups

[Seung-Woo Kim]

Build warnings of ipp fimc is fixed and device pointer usage is
simplified as directly using dev variable.

devm related fixes are also appiled: meaningless devm_kfree is
removed and request_threaded_irq is replaced to devm function.

Seung-Woo Kim (4):
  drm/exynos: cleanup device pointer usages
  drm/exynos: fix build warnings from ipp fimc
  drm/exynos: remove unnecessary devm_kfree
  drm/exynos: replace request_threaded_irq with devm function

 drivers/gpu/drm/exynos/exynos_drm_fimc.c|   12 
 drivers/gpu/drm/exynos/exynos_drm_fimd.c|   10 +-
 drivers/gpu/drm/exynos/exynos_drm_g2d.c |6 +++---
 drivers/gpu/drm/exynos/exynos_drm_gsc.c |   12 +++-
 drivers/gpu/drm/exynos/exynos_drm_hdmi.c|2 +-
 drivers/gpu/drm/exynos/exynos_drm_ipp.c |4 ++--
 drivers/gpu/drm/exynos/exynos_drm_rotator.c |   13 +++--
 drivers/gpu/drm/exynos/exynos_drm_vidi.c|4 ++--
 drivers/gpu/drm/exynos/exynos_hdmi.c|   21 -
 drivers/gpu/drm/exynos/exynos_mixer.c   |   14 +++---
 10 files changed, 38 insertions(+), 60 deletions(-)

-- 
1.7.4.1

[PATCH 4/4] drm/exynos: replace request_threaded_irq with devm function

[Seung-Woo Kim]

devm_request_threaded_irq is used instead of request_threaded_irq
and free_irq is removed.

Signed-off-by: Seung-Woo Kim 
---
 drivers/gpu/drm/exynos/exynos_drm_fimc.c|8 ++--
 drivers/gpu/drm/exynos/exynos_drm_gsc.c |8 ++--
 drivers/gpu/drm/exynos/exynos_drm_rotator.c |   11 +++
 drivers/gpu/drm/exynos/exynos_hdmi.c|7 +--
 4 files changed, 8 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 75c50f5..4a1616a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -1845,7 +1845,7 @@ static int fimc_probe(struct platform_device *pdev)
}

ctx->irq = res->start;
-   ret = request_threaded_irq(ctx->irq, NULL, fimc_irq_handler,
+   ret = devm_request_threaded_irq(dev, ctx->irq, NULL, fimc_irq_handler,
IRQF_ONESHOT, "drm_fimc", ctx);
if (ret < 0) {
dev_err(dev, "failed to request irq.\n");
@@ -1854,7 +1854,7 @@ static int fimc_probe(struct platform_device *pdev)

ret = fimc_setup_clocks(ctx);
if (ret < 0)
-   goto err_free_irq;
+   return ret;

ippdrv = &ctx->ippdrv;
ippdrv->ops[EXYNOS_DRM_OPS_SRC] = &fimc_src_ops;
@@ -1892,8 +1892,6 @@ err_pm_dis:
pm_runtime_disable(dev);
 err_put_clk:
fimc_put_clocks(ctx);
-err_free_irq:
-   free_irq(ctx->irq, ctx);

return ret;
 }
@@ -1911,8 +1909,6 @@ static int fimc_remove(struct platform_device *pdev)
pm_runtime_set_suspended(dev);
pm_runtime_disable(dev);

-   free_irq(ctx->irq, ctx);
-
return 0;
 }

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index 98032d6..762f40d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -1704,7 +1704,7 @@ static int gsc_probe(struct platform_device *pdev)
}

ctx->irq = res->start;
-   ret = request_threaded_irq(ctx->irq, NULL, gsc_irq_handler,
+   ret = devm_request_threaded_irq(dev, ctx->irq, NULL, gsc_irq_handler,
IRQF_ONESHOT, "drm_gsc", ctx);
if (ret < 0) {
dev_err(dev, "failed to request irq.\n");
@@ -1725,7 +1725,7 @@ static int gsc_probe(struct platform_device *pdev)
ret = gsc_init_prop_list(ippdrv);
if (ret < 0) {
dev_err(dev, "failed to init property list.\n");
-   goto err_get_irq;
+   return ret;
}

DRM_DEBUG_KMS("%s:id[%d]ippdrv[0x%x]\n", __func__, ctx->id,
@@ -1749,8 +1749,6 @@ static int gsc_probe(struct platform_device *pdev)

 err_ippdrv_register:
pm_runtime_disable(dev);
-err_get_irq:
-   free_irq(ctx->irq, ctx);
return ret;
 }

@@ -1766,8 +1764,6 @@ static int gsc_remove(struct platform_device *pdev)
pm_runtime_set_suspended(dev);
pm_runtime_disable(dev);

-   free_irq(ctx->irq, ctx);
-
return 0;
 }

diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c 
b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
index 3aa502a..9b6c709 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
@@ -666,8 +666,8 @@ static int rotator_probe(struct platform_device *pdev)
return rot->irq;
}

-   ret = request_threaded_irq(rot->irq, NULL, rotator_irq_handler,
-   IRQF_ONESHOT, "drm_rotator", rot);
+   ret = devm_request_threaded_irq(dev, rot->irq, NULL,
+   rotator_irq_handler, IRQF_ONESHOT, "drm_rotator", rot);
if (ret < 0) {
dev_err(dev, "failed to request irq\n");
return ret;
@@ -676,8 +676,7 @@ static int rotator_probe(struct platform_device *pdev)
rot->clock = devm_clk_get(dev, "rotator");
if (IS_ERR(rot->clock)) {
dev_err(dev, "failed to get clock\n");
-   ret = PTR_ERR(rot->clock);
-   goto err_clk_get;
+   return PTR_ERR(rot->clock);
}

pm_runtime_enable(dev);
@@ -710,8 +709,6 @@ static int rotator_probe(struct platform_device *pdev)

 err_ippdrv_register:
pm_runtime_disable(dev);
-err_clk_get:
-   free_irq(rot->irq, rot);
return ret;
 }

@@ -725,8 +722,6 @@ static int rotator_remove(struct platform_device *pdev)

pm_runtime_disable(dev);

-   free_irq(rot->irq, rot);
-
return 0;
 }

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 8d5dcd1..2f78532 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -2046,7 +2046,7 @@ static int hdmi_probe(struct platform_device *pdev)

hdata->hpd = gpio_get_value(hdata->hpd_gpio);

-   ret = request_threaded_irq(hdata->irq, NULL,
+   ret = devm_request_threaded_irq(dev, hdata->irq, NUL

[PATCH 1/4] drm/exynos: cleanup device pointer usages

[Seung-Woo Kim]

Struct device pointer got from platform device pointer is already
alsigned as variable, but some functions do not use device pointer.
So this patch replaces thoes usages.

Signed-off-by: Seung-Woo Kim 
---
 drivers/gpu/drm/exynos/exynos_drm_fimc.c |2 +-
 drivers/gpu/drm/exynos/exynos_drm_fimd.c |   10 +-
 drivers/gpu/drm/exynos/exynos_drm_g2d.c  |6 +++---
 drivers/gpu/drm/exynos/exynos_drm_gsc.c  |2 +-
 drivers/gpu/drm/exynos/exynos_drm_hdmi.c |2 +-
 drivers/gpu/drm/exynos/exynos_drm_ipp.c  |4 ++--
 drivers/gpu/drm/exynos/exynos_drm_vidi.c |4 ++--
 drivers/gpu/drm/exynos/exynos_hdmi.c |   14 +++---
 drivers/gpu/drm/exynos/exynos_mixer.c|   14 +++---
 9 files changed, 29 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 773f583..754d760 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -1884,7 +1884,7 @@ static int fimc_probe(struct platform_device *pdev)
goto err_pm_dis;
}

-   dev_info(&pdev->dev, "drm fimc registered successfully.\n");
+   dev_info(dev, "drm fimc registered successfully.\n");

return 0;

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 746b282..97c61db 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -885,7 +885,7 @@ static int fimd_probe(struct platform_device *pdev)

DRM_DEBUG_KMS("%s\n", __FILE__);

-   if (pdev->dev.of_node) {
+   if (dev->of_node) {
pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
if (!pdata) {
DRM_ERROR("memory allocation for pdata failed\n");
@@ -899,7 +899,7 @@ static int fimd_probe(struct platform_device *pdev)
return ret;
}
} else {
-   pdata = pdev->dev.platform_data;
+   pdata = dev->platform_data;
if (!pdata) {
DRM_ERROR("no platform data specified\n");
return -EINVAL;
@@ -912,7 +912,7 @@ static int fimd_probe(struct platform_device *pdev)
return -EINVAL;
}

-   ctx = devm_kzalloc(&pdev->dev, sizeof(*ctx), GFP_KERNEL);
+   ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
if (!ctx)
return -ENOMEM;

@@ -930,7 +930,7 @@ static int fimd_probe(struct platform_device *pdev)

res = platform_get_resource(pdev, IORESOURCE_MEM, 0);

-   ctx->regs = devm_ioremap_resource(&pdev->dev, res);
+   ctx->regs = devm_ioremap_resource(dev, res);
if (IS_ERR(ctx->regs))
return PTR_ERR(ctx->regs);

@@ -942,7 +942,7 @@ static int fimd_probe(struct platform_device *pdev)

ctx->irq = res->start;

-   ret = devm_request_irq(&pdev->dev, ctx->irq, fimd_irq_handler,
+   ret = devm_request_irq(dev, ctx->irq, fimd_irq_handler,
0, "drm_fimd", ctx);
if (ret) {
dev_err(dev, "irq request failed.\n");
diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c 
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index 47a493c..af75434 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -1379,7 +1379,7 @@ static int g2d_probe(struct platform_device *pdev)
struct exynos_drm_subdrv *subdrv;
int ret;

-   g2d = devm_kzalloc(&pdev->dev, sizeof(*g2d), GFP_KERNEL);
+   g2d = devm_kzalloc(dev, sizeof(*g2d), GFP_KERNEL);
if (!g2d) {
dev_err(dev, "failed to allocate driver data\n");
return -ENOMEM;
@@ -1417,7 +1417,7 @@ static int g2d_probe(struct platform_device *pdev)

res = platform_get_resource(pdev, IORESOURCE_MEM, 0);

-   g2d->regs = devm_ioremap_resource(&pdev->dev, res);
+   g2d->regs = devm_ioremap_resource(dev, res);
if (IS_ERR(g2d->regs)) {
ret = PTR_ERR(g2d->regs);
goto err_put_clk;
@@ -1430,7 +1430,7 @@ static int g2d_probe(struct platform_device *pdev)
goto err_put_clk;
}

-   ret = devm_request_irq(&pdev->dev, g2d->irq, g2d_irq_handler, 0,
+   ret = devm_request_irq(dev, g2d->irq, g2d_irq_handler, 0,
"drm_g2d", g2d);
if (ret < 0) {
dev_err(dev, "irq request failed\n");
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index 7841c3b..487595a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -1743,7 +1743,7 @@ static int gsc_probe(struct platform_device *pdev)
goto err_ippdrv_register;
}

-   dev_info(&pdev->dev, "drm gsc registered successfully.\n");
+