[PATCH 06/16] drm: Protect the master management with a drm_device::master_mutex

[Daniel Vetter]

On Wed, Mar 26, 2014 at 09:40:18PM +0100, Thomas Hellstrom wrote:
> On 03/26/2014 08:08 PM, David Herrmann wrote:
> > "struct_mutex" is used to serialize all entry-points into
> > the drm-device (and thus the driver) and also, often implicitly, as
> > spin-lock for "struct drm_device" data protection.
> 
> No. DRM locking was added as an after-though, and is a horrendous mess.
> Nobody really knows what's protecting what, and that has caused a lot of
> grief in the past. Probably most so for the Intel driver that relied
> (relies?) on the struct_mutex to protect everything. The
> drm_global_mutex is used to serialize the non-lock-audited entry points
> into the drm device. The struct_mutex is used for data protection of
> most core drm structures and serializing here and there. Modern drivers
> have no locks held when entering their ioctls. Also we should not
> confuse mutexes and spinlocks in this context, as they have very
> different semantics.

As the guy who gets to live the locking mess called dev->struct_mutex I
holeheartedly welcome any efforts to split out clear subparts away from
it. I actually had this very idea of adding a master-data related mutex on
my todo. I'll try to review this later if I get around, but definitely
Acked!
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH 00/16] Atomic/nuclear modeset/pageflip

[Daniel Vetter]

On Wed, Mar 26, 2014 at 10:33 PM, Greg Hackmann  wrote:
> On Wed, Mar 26, 2014 at 3:08 AM, Daniel Vetter  wrote:
>>
>> - You have an explicit callback for vblank events (well, just the
>>   interrupt, afaics no support to get a vblank event for a specific frame
>>   in the future). Any reason not to use android syncpoint fences for this
>>   like everywhere else? Or is the idea behind all the fences hwc throws
>>   around just to synchronize read/write access from
>>   cpu/render/codec/whatever and not so much timing?
>
>
> Vsync events are used to kick off Android's rendering loop.  The upshot is
> that when SurfaceFlinger requests vsync events from the HWC HAL, it needs to
> deliver them at every vsync even if the display hasn't changed.
>
> Fences tell a consumer when the producer's done with the buffer, and aren't
> really meant for timing.  (Or probably even useful for timing, since they
> don't pass along any timestamping information about when the event
> happened.)
>
>> - If I read this correct you mandate that the fences fields gets filled
>>   out in the prepare hook, i.e. before we commit the new state to
>>   hardware. You also mandate that the fences get eventually signalled even
>>   when surfaceflinger decides to not commit the new state.
>
>
> The HWC HAL needs to fill in the release fences during set().  The mandate
> w.r.t. fences is that if SurfaceFlinger calls
>
> prepare(A)
> set(A)
> prepare(B)
> set(B)
>
> and something inside set(B) fails for some reason, the HWC HAL must ensure
> that the fences returned by set(A) eventually fire anyway.  That situation
> really shouldn't happen unless something goes horribly wrong, since the
> expectation is that prepare(B) will pick a composition that set(B) can
> display.

Ah, thanks for the clarification, I was mixing up comments for ->set()
and ->prepare when reading the interface spec. So that wording sounds
like it's just to avoid resource leaks in case of a catastrophe so
that framebuffers frome older set calls get eventually reused. Makes
sense and with that I think we still can have useful compatibility
between Maarten's fences and android syncpoints.

I still see some fun with userspace potentially being required to
signal fences or fences created before the event is committed (e.g.
when using a buffer for scanout, which means it'll get used until it's
eventually replaced by something else). Just means there needs to be
some scheduler to keep things from stalling forever.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Hiding a monitor from all apps except one

[Ilya Faenson]

Appreciate valuable pointers, Dave!

> Date: Thu, 27 Mar 2014 10:52:46 +1000
> Subject: Re: Hiding a monitor from all apps except one
> From: airlied at gmail.com
> To: ifaenson at hotmail.com
> CC: dri-devel at lists.freedesktop.org
> 
> On Thu, Mar 27, 2014 at 10:37 AM, Ilya Faenson  
> wrote:
> > I knew it was not run-of-the-mill request. :-)
> >
> > Is the work you've mentioned publicly available? If so, could you publish
> > its whereabouts?
> 
> Well its what you would call public but unloved, its also 4 years old,
> and very unlikely to cleanly rebase onto what we have now,
> 
> http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-render-nodes
> 
> I suppose you could also in theory set up an X server using ZaphodHeads,
> so that the HDMI output is on its own X server display, it wouldn't be
> impossible for someone to interfere with it then,
> 
> Dave.

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140326/9b98a32b/attachment-0001.html>

[PATCH 06/16] drm: Protect the master management with a drm_device::master_mutex

[Thomas Hellstrom]

On 03/26/2014 08:08 PM, David Herrmann wrote:
> Hi
>
> On Tue, Mar 25, 2014 at 2:18 PM, Thomas Hellstrom  
> wrote:
>> The master management was previously protected by the 
>> drm_device::struct_mutex.
>> In order to avoid locking order violations in a reworked dropped master
>> security check in the vmwgfx driver, break it out into a separate 
>> master_mutex.
> Could you elaborate on that? What exactly is "master_mutex"
> protecting? 

Its protecting drm_file::is_master and drm_minor::master, as per inline
comments. It's also a candidate for replacing
drm_global_mutex to avoid the dropmaster and setmaster ioctls racing
when the drm_global_mutex eventually goes away.

> "struct_mutex" is used to serialize all entry-points into
> the drm-device (and thus the driver) and also, often implicitly, as
> spin-lock for "struct drm_device" data protection.

No. DRM locking was added as an after-though, and is a horrendous mess.
Nobody really knows what's protecting what, and that has caused a lot of
grief in the past. Probably most so for the Intel driver that relied
(relies?) on the struct_mutex to protect everything. The
drm_global_mutex is used to serialize the non-lock-audited entry points
into the drm device. The struct_mutex is used for data protection of
most core drm structures and serializing here and there. Modern drivers
have no locks held when entering their ioctls. Also we should not
confuse mutexes and spinlocks in this context, as they have very
different semantics.


>
> Regarding master_mutex I have several questions:
>  - Can you give an example how vmwgfx dead-locks with your reworked code?

Sure. The reworked driver takes the ttm lock in non-exclusive mode
before entering an ioctl. Ioctls will then internally take the
struct_mutex. The dropmaster and setmaster ioctls would (before this
patch) take the struct_mutex and then in the driver code takes the ttm
lock in exclusive mode. We would have a lock inversion and a potential
deadlock.

>  - Why don't add a spin-lock to "drm_file" instead? Use that one to
> manage master contexts, but keep "struct_mutex" whenever calling into
> driver callbacks (set_master/drop_master)

See above. We can't have a lock in the drm_file structure since it
protects drm_minor data. Also, while it might be possible to restructure
some code to be able to use spinlocks instead of mutexes I see no reason
to. The established locking order now is master_mutex -> ttm_lock ->
struct_mutex which means master_mutex must be a mutex.

>  - why is master_mutex per device and not per-minor? I thought masters
> on minors are _entirely_ independent?

Because currently there is only one master capable minor per device, so
it would be equivalent. And even if there were more, there is no reason
to expect any contention and thus a single master_mutex would be fine.

>
> Few more comments inline.
>
>> Signed-off-by: Thomas Hellstrom 
>> Reviewed-by: Brian Paul 
>> ---
>>  drivers/gpu/drm/drm_fops.c |   23 +-
>>  drivers/gpu/drm/drm_stub.c |   38 ++--
>>  include/drm/drmP.h |   46 
>> 
>>  3 files changed, 63 insertions(+), 44 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
>> index e6cdd0f..dad571f 100644
>> --- a/drivers/gpu/drm/drm_fops.c
>> +++ b/drivers/gpu/drm/drm_fops.c
>> @@ -231,12 +231,13 @@ static int drm_open_helper(struct inode *inode, struct 
>> file *filp,
>>
>> /* if there is no current master make this fd it, but do not create
>>  * any master object for render clients */
>> -   mutex_lock(&dev->struct_mutex);
>> +   mutex_lock(&dev->master_mutex);
>> if (drm_is_legacy_client(priv) && !priv->minor->master) {
>> /* create a new master */
>> +   mutex_lock(&dev->struct_mutex);
>> priv->minor->master = drm_master_create(priv->minor);
>> +   mutex_unlock(&dev->struct_mutex);
>> if (!priv->minor->master) {
>> -   mutex_unlock(&dev->struct_mutex);
>> ret = -ENOMEM;
>> goto out_close;
>> }
>> @@ -245,28 +246,25 @@ static int drm_open_helper(struct inode *inode, struct 
>> file *filp,
>> /* take another reference for the copy in the local file 
>> priv */
>> priv->master = drm_master_get(priv->minor->master);
>>
>> +   mutex_lock(&dev->struct_mutex);
>> priv->authenticated = 1;
>>
>> mutex_unlock(&dev->struct_mutex);
> What's that struct_mutex doing here? We're in ->open(), there is
> no-one racing against us.

Well, it was held at that point before, and the purpose of this patch is
not to generally clean up struct_mutex usage.

>
>> if (dev->driver->master_create) {
>> ret = dev->driver->master_create(dev, priv->master);
>>   

[Bug 76659] Display does not return from DPMS off using ATI drivers

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

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

Alex Deucher  changed:

   What|Removed |Added

   Assignee|xorg-driver-ati at lists.x.org |dri-devel at 
lists.freedesktop
   ||.org
 QA Contact|xorg-team at lists.x.org   |
Product|xorg|DRI
Version|7.3 (2007.09)   |unspecified
  Component|Driver/Radeon   |DRM/Radeon

--- Comment #1 from Alex Deucher  ---
Please attach your dmesg output from after the display does not come back.  Is
this a regression?  If so, can you bisect the kernel?

-- 
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/20140326/27fe2547/attachment.html>

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

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

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

--- Comment #14 from Alex Deucher  ---
(In reply to comment #13)
> Do the PLL values in the log files I posted indicate a problem, or are they
> okay?

[drm:radeon_compute_pll_avivo], 14875, pll dividers - fb: 23.8 ref: 2, post 8
[drm:radeon_compute_pll_avivo], 7406, pll dividers - fb: 23.7 ref: 2, post 16

The display pll looks fine to me. The clock formula is:

pixel_clock = (reference_frequency * feedback_divider) / (reference_divider *
post_divider)

The reference frequency is 100 Mhz, so:

(100Mhz * 23.8) / (2 * 8) = 148.75Mhz

(100Mhz * 23.7) / (2 * 16) = 74.0625Mhz

> 
> How can you see the PLL values fglrx is using?

You'd need to dump the PLL registers using radeonreg
(http://cgit.freedesktop.org/~airlied/radeontool/).
PPLL1
0x400 - ref div - bits 9:0
0x404 - fb div - whole part bits 26:16, fractional part bits 3:0
0x408 - post div - bits 6:0
PPLL2
0x440 - ref div - bits 9:0
0x444 - fb div - whole part bits 26:16, fractional part bits 3:0
0x448 - post div - bits 6:0

e.g., ./radeonreg regmatch 0x400

-- 
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/20140326/c3482feb/attachment.html>

Hiding a monitor from all apps except one

[Ilya Faenson]

I knew it was not run-of-the-mill request. :-)

Is the work you've mentioned publicly available? If so, could you publish its 
whereabouts?

Many thanks!
 -Ilya

> Date: Thu, 27 Mar 2014 10:07:41 +1000
> Subject: Re: Hiding a monitor from all apps except one
> From: airlied at gmail.com
> To: ifaenson at hotmail.com
> CC: dri-devel at lists.freedesktop.org
> 
> On Thu, Mar 27, 2014 at 2:02 AM, Ilya Faenson  wrote:
> > Dear DRM Experts,
> >
> > My assignment is to make sure the more or less standard HDMI-connected
> > monitor is visible and accessible to a single (our own) OpenGL application
> > only. That monitor is part of the larger device so it does not make sense
> > for anybody else to interfere with its use. The solution should work with
> > any graphics adapter.
> >
> > I see a few virtual monitor implementations available like VirtualGL,
> > vcrtcm, various VNC flavors but we rather need to hide an existing monitor
> > rather than create a virtual one. I guess we could try creating a virtual
> > monitor, mapping it into the physical one, but the hiding it from almost
> > everybody at the upper edge of the DRM might be tricky. The background: I'm
> > a very experienced driver developer but I'm new to Linux graphics internals.
> 
> Probably asking too much :-)
> 
> Something like the multi-seat work I did to allow device nodes with different
> crtc/connectors attached to them, with an X server running on that node,
> that is independent of X server running on other nodes maybe,
> 
> Dave.

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140326/abf230bc/attachment.html>

[Bug 76320] libpciaccess requires xorg-macros when it may not be available on all target platforms (ones lacking Xorg)

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

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

Matt Turner  changed:

   What|Removed |Added

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

--- Comment #1 from Matt Turner  ---
Totally related:

man/Makefile.am:
# String replacements in MAN_SUBSTS now come from xorg-macros.m4 via configure
SUFFIXES = .$(APP_MAN_SUFFIX) .man

You do realize that xorg-macros is just a m4 file full of autoconf convenience
macros, right? Using it isn't actually relying on xorg to function.

-- 
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/20140326/f00bd2cf/attachment.html>

[PATCH 06/16] drm: Protect the master management with a drm_device::master_mutex

[David Herrmann]

Hi

On Tue, Mar 25, 2014 at 2:18 PM, Thomas Hellstrom  
wrote:
> The master management was previously protected by the 
> drm_device::struct_mutex.
> In order to avoid locking order violations in a reworked dropped master
> security check in the vmwgfx driver, break it out into a separate 
> master_mutex.

Could you elaborate on that? What exactly is "master_mutex"
protecting? "struct_mutex" is used to serialize all entry-points into
the drm-device (and thus the driver) and also, often implicitly, as
spin-lock for "struct drm_device" data protection.

Regarding master_mutex I have several questions:
 - Can you give an example how vmwgfx dead-locks with your reworked code?
 - Why don't add a spin-lock to "drm_file" instead? Use that one to
manage master contexts, but keep "struct_mutex" whenever calling into
driver callbacks (set_master/drop_master)
 - why is master_mutex per device and not per-minor? I thought masters
on minors are _entirely_ independent?

Few more comments inline.

> Signed-off-by: Thomas Hellstrom 
> Reviewed-by: Brian Paul 
> ---
>  drivers/gpu/drm/drm_fops.c |   23 +-
>  drivers/gpu/drm/drm_stub.c |   38 ++--
>  include/drm/drmP.h |   46 
> 
>  3 files changed, 63 insertions(+), 44 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
> index e6cdd0f..dad571f 100644
> --- a/drivers/gpu/drm/drm_fops.c
> +++ b/drivers/gpu/drm/drm_fops.c
> @@ -231,12 +231,13 @@ static int drm_open_helper(struct inode *inode, struct 
> file *filp,
>
> /* if there is no current master make this fd it, but do not create
>  * any master object for render clients */
> -   mutex_lock(&dev->struct_mutex);
> +   mutex_lock(&dev->master_mutex);
> if (drm_is_legacy_client(priv) && !priv->minor->master) {
> /* create a new master */
> +   mutex_lock(&dev->struct_mutex);
> priv->minor->master = drm_master_create(priv->minor);
> +   mutex_unlock(&dev->struct_mutex);
> if (!priv->minor->master) {
> -   mutex_unlock(&dev->struct_mutex);
> ret = -ENOMEM;
> goto out_close;
> }
> @@ -245,28 +246,25 @@ static int drm_open_helper(struct inode *inode, struct 
> file *filp,
> /* take another reference for the copy in the local file priv 
> */
> priv->master = drm_master_get(priv->minor->master);
>
> +   mutex_lock(&dev->struct_mutex);
> priv->authenticated = 1;
>
> mutex_unlock(&dev->struct_mutex);

What's that struct_mutex doing here? We're in ->open(), there is
no-one racing against us.

> if (dev->driver->master_create) {
> ret = dev->driver->master_create(dev, priv->master);
> if (ret) {
> -   mutex_lock(&dev->struct_mutex);
> /* drop both references if this fails */
> drm_master_put(&priv->minor->master);
> drm_master_put(&priv->master);
> -   mutex_unlock(&dev->struct_mutex);
> goto out_close;
> }
> }
> -   mutex_lock(&dev->struct_mutex);
> if (dev->driver->master_set) {
> ret = dev->driver->master_set(dev, priv, true);
> if (ret) {
> /* drop both references if this fails */
> drm_master_put(&priv->minor->master);
> drm_master_put(&priv->master);
> -   mutex_unlock(&dev->struct_mutex);
> goto out_close;
> }
> }
> @@ -274,8 +272,8 @@ static int drm_open_helper(struct inode *inode, struct 
> file *filp,
> /* get a reference to the master */
> priv->master = drm_master_get(priv->minor->master);
> }
> -   mutex_unlock(&dev->struct_mutex);
>
> +   mutex_unlock(&dev->master_mutex);
> mutex_lock(&dev->struct_mutex);
> list_add(&priv->lhead, &dev->filelist);
> mutex_unlock(&dev->struct_mutex);
> @@ -302,6 +300,7 @@ static int drm_open_helper(struct inode *inode, struct 
> file *filp,
> return 0;
>
>  out_close:
> +   mutex_unlock(&dev->master_mutex);
> if (dev->driver->postclose)
> dev->driver->postclose(dev, priv);
>  out_prime_destroy:
> @@ -489,11 +488,13 @@ int drm_release(struct inode *inode, struct file *filp)
> }
> mutex_unlock(&dev->ctxlist_mutex);
>
> -   mutex_lock(&dev->struct_mutex);
> +   mutex_lock(&dev->master_mutex);
>
> if (file_priv

[PATCH 03/16] drm: Make control nodes master-less v3

[David Herrmann]

Hi

On Tue, Mar 25, 2014 at 2:18 PM, Thomas Hellstrom  
wrote:
> Like for render-nodes, there is no point in maintaining the master concept
> for control nodes, so set the struct drm_file::master pointer to NULL.
>
> At the same time, make sure DRM_MASTER | DRM_CONTROL_ALLOW ioctls are always
> allowed when called through the control node. Previously the caller also
> needed to be master.
>
> v2: Adapt to refactoring of ioctl permission check.
> v3: Formatting of logical expression. Use drm_is_control_client() instead of
> drm_is_control().

Looks good now.

Reviewed-by: David Herrmann 

Thanks
David

> Signed-off-by: Thomas Hellstrom 
> Reviewed-by: Brian Paul 
> ---
>  drivers/gpu/drm/drm_drv.c  |7 ---
>  drivers/gpu/drm/drm_fops.c |6 --
>  include/drm/drmP.h |5 +
>  3 files changed, 13 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 05e3053..cf2dfb7 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -306,13 +306,14 @@ static int drm_ioctl_permit(u32 flags, struct drm_file 
> *file_priv)
>  !file_priv->authenticated))
> return -EACCES;
>
> -   /* MASTER is only for master */
> -   if (unlikely((flags & DRM_MASTER) && !file_priv->is_master))
> +   /* MASTER is only for master or control clients */
> +   if (unlikely((flags & DRM_MASTER) && !file_priv->is_master &&
> +!drm_is_control_client(file_priv)))
> return -EACCES;
>
> /* Control clients must be explicitly allowed */
> if (unlikely(!(flags & DRM_CONTROL_ALLOW) &&
> -file_priv->minor->type == DRM_MINOR_CONTROL))
> +drm_is_control_client(file_priv)))
> return -EACCES;
>
> /* Render clients must be explicitly allowed */
> diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
> index 9b02f12..5432a1a 100644
> --- a/drivers/gpu/drm/drm_fops.c
> +++ b/drivers/gpu/drm/drm_fops.c
> @@ -232,7 +232,8 @@ static int drm_open_helper(struct inode *inode, struct 
> file *filp,
> /* if there is no current master make this fd it, but do not create
>  * any master object for render clients */
> mutex_lock(&dev->struct_mutex);
> -   if (!priv->minor->master && !drm_is_render_client(priv)) {
> +   if (!priv->minor->master && !drm_is_render_client(priv) &&
> +   !drm_is_control_client(priv)) {
> /* create a new master */
> priv->minor->master = drm_master_create(priv->minor);
> if (!priv->minor->master) {
> @@ -270,7 +271,8 @@ static int drm_open_helper(struct inode *inode, struct 
> file *filp,
> goto out_close;
> }
> }
> -   } else if (!drm_is_render_client(priv)) {
> +   } else if (!drm_is_render_client(priv) &&
> +  !drm_is_control_client(priv)) {
> /* get a reference to the master */
> priv->master = drm_master_get(priv->minor->master);
> }
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index daac00a..f708aa19 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -1237,6 +1237,11 @@ static inline bool drm_is_render_client(struct 
> drm_file *file_priv)
> return file_priv->minor->type == DRM_MINOR_RENDER;
>  }
>
> +static inline bool drm_is_control_client(const struct drm_file *file_priv)
> +{
> +   return file_priv->minor->type == DRM_MINOR_CONTROL;
> +}
> +
>  /**/
>  /** \name Internal function definitions */
>  /*@{*/
> --
> 1.7.10.4
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 04/16] drm: Improve on minor type helpers v2

[David Herrmann]

Hi

On Tue, Mar 25, 2014 at 2:18 PM, Thomas Hellstrom  
wrote:
> Add a drm_is_legacy() helper, constify argument to drm_is_render_client(),
> and use / change helpers where appropriate.
>
> v2: s/drm_is_legacy/drm_is_legacy_client/ and adapt to new code context.

Could we avoid using "legacy" for the primary node? The node-pointer
is called ->primary and Thierry posted patches to also rename
DRM_MINOR_LEGACY to DRM_MINOR_PRIMARY. The primary node is still the
recommended node for mode-setting, so lets not attribute "legacy" to
them,

Otherwise, patch looks good.

Thanks
David

> Signed-off-by: Thomas Hellstrom 
> Reviewed-by: Brian Paul 
> ---
>  drivers/gpu/drm/drm_crtc.c |4 ++--
>  drivers/gpu/drm/drm_fops.c |6 ++
>  include/drm/drmP.h |7 ++-
>  3 files changed, 10 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 5fb02d5..bf6ef77 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -1492,7 +1492,7 @@ int drm_mode_getresources(struct drm_device *dev, void 
> *data,
> mutex_unlock(&file_priv->fbs_lock);
>
> drm_modeset_lock_all(dev);
> -   if (file_priv->minor->type != DRM_MINOR_LEGACY) {
> +   if (!drm_is_legacy_client(file_priv)) {
>
> mode_group = NULL;
> list_for_each(lh, &dev->mode_config.crtc_list)
> @@ -2848,7 +2848,7 @@ int drm_mode_getfb(struct drm_device *dev,
> r->pitch = fb->pitches[0];
> if (fb->funcs->create_handle) {
> if (file_priv->is_master || capable(CAP_SYS_ADMIN) ||
> -   file_priv->minor->type == DRM_MINOR_CONTROL) {
> +   drm_is_control_client(file_priv)) {
> ret = fb->funcs->create_handle(fb, file_priv,
>&r->handle);
> } else {
> diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
> index 5432a1a..e6cdd0f 100644
> --- a/drivers/gpu/drm/drm_fops.c
> +++ b/drivers/gpu/drm/drm_fops.c
> @@ -232,8 +232,7 @@ static int drm_open_helper(struct inode *inode, struct 
> file *filp,
> /* if there is no current master make this fd it, but do not create
>  * any master object for render clients */
> mutex_lock(&dev->struct_mutex);
> -   if (!priv->minor->master && !drm_is_render_client(priv) &&
> -   !drm_is_control_client(priv)) {
> +   if (drm_is_legacy_client(priv) && !priv->minor->master) {
> /* create a new master */
> priv->minor->master = drm_master_create(priv->minor);
> if (!priv->minor->master) {
> @@ -271,8 +270,7 @@ static int drm_open_helper(struct inode *inode, struct 
> file *filp,
> goto out_close;
> }
> }
> -   } else if (!drm_is_render_client(priv) &&
> -  !drm_is_control_client(priv)) {
> +   } else if (drm_is_legacy_client(priv)) {
> /* get a reference to the master */
> priv->master = drm_master_get(priv->minor->master);
> }
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index f708aa19..5fe3d68 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -1232,7 +1232,7 @@ static inline bool drm_modeset_is_locked(struct 
> drm_device *dev)
> return mutex_is_locked(&dev->mode_config.mutex);
>  }
>
> -static inline bool drm_is_render_client(struct drm_file *file_priv)
> +static inline bool drm_is_render_client(const struct drm_file *file_priv)
>  {
> return file_priv->minor->type == DRM_MINOR_RENDER;
>  }
> @@ -1242,6 +1242,11 @@ static inline bool drm_is_control_client(const struct 
> drm_file *file_priv)
> return file_priv->minor->type == DRM_MINOR_CONTROL;
>  }
>
> +static inline bool drm_is_legacy_client(const struct drm_file *file_priv)
> +{
> +   return file_priv->minor->type == DRM_MINOR_LEGACY;
> +}
> +
>  /**/
>  /** \name Internal function definitions */
>  /*@{*/
> --
> 1.7.10.4
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] acpi: allow non-optimus setups to load vbios from acpi

[Ilia Mirkin]

There appear to be a crop of new hardware where the vbios is not
available from PROM/PRAMIN, but there is a valid _ROM method in ACPI.
The data read from PCIROM almost invariably contains invalid
instructions (still has the x86 opcodes), which makes this a low-risk
way to try to obtain a valid vbios image.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76475
Signed-off-by: Ilia Mirkin 
Cc:  # v2.6.35+
---

Not sure if the stable CC is warranted... it's technically not a
regression. But it's a simple change that enables hardware to work.

Patrick/Claas -- please test this out (if you're applying this to a linux
tree, you'll have to do it manually, but it should be fairly obvious where
this should apply).

 drm/nouveau_acpi.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drm/nouveau_acpi.c b/drm/nouveau_acpi.c
index 83face3..2792069 100644
--- a/drm/nouveau_acpi.c
+++ b/drm/nouveau_acpi.c
@@ -389,9 +389,6 @@ bool nouveau_acpi_rom_supported(struct pci_dev *pdev)
acpi_status status;
acpi_handle dhandle, rom_handle;

-   if (!nouveau_dsm_priv.dsm_detected && 
!nouveau_dsm_priv.optimus_detected)
-   return false;
-
dhandle = ACPI_HANDLE(&pdev->dev);
if (!dhandle)
return false;
-- 
1.8.3.2

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

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

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

--- Comment #13 from jeroen  ---
Do the PLL values in the log files I posted indicate a problem, or are they
okay?

How can you see the PLL values fglrx is using?

-- 
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/20140326/23339f08/attachment.html>

[PATCH RFC v2 2/6] drm/i2c: tda998x: Move tda998x to a couple encoder/connector

[Laurent Pinchart]

Hi Jean-Fran?ois,

On Tuesday 25 March 2014 16:55:48 Jean-Francois Moine wrote:
> On Mon, 24 Mar 2014 23:39:01 +0100 Laurent Pinchart wrote:
> > On Friday 21 March 2014 09:17:32 Jean-Francois Moine wrote:
> > > The 'slave encoder' structure of the tda998x driver asks for glue
> > > between the DRM driver and the encoder/connector structures.
> > > 
> > > This patch changes the driver to a normal DRM encoder/connector
> > > thanks to the infrastructure for componentised subsystems.
> > 
> > I like the idea, but I'm not really happy with the implementation. Let me
> > try to explain why below.
> > 
> > > Signed-off-by: Jean-Francois Moine 
> > > ---
> > > 
> > >  drivers/gpu/drm/i2c/tda998x_drv.c | 323 ---
> > >  1 file changed, 188 insertions(+), 135 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
> > > b/drivers/gpu/drm/i2c/tda998x_drv.c index fd6751c..1c25e40 100644
> > > --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> > > +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> > 
> > [snip]
> > 
> > > @@ -44,10 +45,14 @@ struct tda998x_priv {
> > >   wait_queue_head_t wq_edid;
> > >   volatile int wq_edid_wait;
> > > 
> > > - struct drm_encoder *encoder;
> > > + struct drm_encoder encoder;
> > > + struct drm_connector connector;
> > > 
> > >  };
> > 
> > [snip]
> > 
> > > -static int
> > > -tda998x_probe(struct i2c_client *client, const struct i2c_device_id
> > > *id)
> > > +static int tda_bind(struct device *dev, struct device *master, void
> > > *data)
> > >  {
> > > + struct drm_device *drm = data;
> > 
> > This is the part that bothers me. You're making two assumptions here, that
> > the DRM driver will pass a struct drm_device pointer to the bind
> > operation, and that the I2C encoder driver can take control of DRM
> > encoder and connector creation. Although it could become problematic
> > later, the first assumption isn't too much of an issue for now. I'll thus
> > focus on the second one.
> > 
> > The component framework isolate the encoder and DRM master drivers as far
> > as component creation and binding is concerned, but doesn't provide a way
> > for the two drivers to communicate together (nor should it). You're
> > solving this by passing a pointer to the DRM device to the encoder bind
> > operation, making the encoder driver create a DRM encoder and connector,
> > and relying on the DRM core to orchestrate CRTCs, encoders and
> > connectors. You thus assume that the encoder hardware should be
> > represented by a DRM encoder object, and that its output is connected to
> > a connector that should be represented by a DRM connector object. While
> > this can work in your use case, that won't always hold true. Hardware
> > encoders can be chained together, while DRM encoders can't. The DRM core
> > has recently received support for bridge objects to overcome that
> > limitation. Depending on the hardware topology, a given hardware encoder
> > should be modeled as a DRM encoder or as a DRM bridge. That decision
> > shouldn't be taken by the encoder driver but by the DRM master driver.
> > The I2C encoder driver thus shouldn't create the DRM encoder and DRM
> > connector itself.
> > 
> > I believe the encoder/master communication problem should be solved
> > differently. Instead of passing a pointer to the DRM device to the encoder
> > driver and making the encoder driver control DRM encoder and connector
> > creation, the encoder driver should instead create an object not visible
> > to userspace that can be retrieved by the DRM master driver (possibly
> > through registration with the DRM core, or by going through drvdata in the
> > encoder's struct device). The DRM master could use that object to
> > communicate with the encoder, and would register the DRM encoder and DRM
> > connector itself based on hardware topology.
> > 
> > > + struct i2c_client *i2c_client = to_i2c_client(dev);
> > > + struct tda998x_priv *priv = i2c_get_clientdata(i2c_client);
> > > + struct drm_connector *connector = &priv->connector;
> > > + struct drm_encoder *encoder = &priv->encoder;
> > > + int ret;
> > > +
> > > + if (!try_module_get(THIS_MODULE)) {
> > > + dev_err(dev, "cannot get module %s\n", THIS_MODULE->name);
> > > + return -EINVAL;
> > > + }
> > > +
> > > + ret = drm_connector_init(drm, connector,
> > > + &connector_funcs,
> > > + DRM_MODE_CONNECTOR_HDMIA);
> > 
> > This is one example of the shortcomings I've explained above. An encoder
> > driver can't always know what connector type it is connected to. If I'm
> > not mistaken possible options here are DVII, DVID, HDMIA and HDMIB. It
> > should be up to the master driver to select the connector type based on
> > its overall view of the hardware, or even to a connector driver that would
> > be bound to a connector DT node (as proposed in
> > https://www.mail-archive.com/devicetree at vger.kernel.org/msg16585.html).
>   [snip]
> 
> The tda998x, as a HDMI 

[Bug 75992] Display freezes & corruption with an r7 260x on 3.14-rc6

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

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

--- Comment #7 from Ed Tomlinson  ---
The only setting I cannot revert in the patch is:

pi->mclk_dpm_key_disabled = 1;

To avoid humdreds of: radeon :01:00.0: GPU fault detected: 146 0x0aa20804
and 147 type errors I had to add: export R600_DEBUG=nohyperz in the X startup
as documented in: https://bugzilla.kernel.org/show_bug.cgi?id=66981

Also found some funny stuff to do with primary and secondary graphic cards.
booting with the primary as the builtin hd4600, with no radeon specific stuff
in the kernel command line does NOT enable the dpm on the secondary radeon card
and trying to use radeon.dpm=1 causes the X startup to stall.  Note in all
cases the a xorg.conf file selects the radeon card to be 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/20140326/8c54d5ea/attachment.html>

[Bug 75494] Kabini [Radeon HD 8240] Xorg segfault on resume from suspend with glamor and radeonsi

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

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

--- Comment #8 from Jarno Lepp?nen  ---
Works now also on linux stable 3.13.7

-- 
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/20140326/b9bee745/attachment.html>

[Bug 76320] libpciaccess requires xorg-macros when it may not be available on all target platforms (ones lacking Xorg)

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

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

Alexander von Gluck  changed:

   What|Removed |Added

Summary|libpciaccess seems to   |libpciaccess requires
   |require xorg-macros for no  |xorg-macros when it may not
   |reason  |be available on all target
   ||platforms (ones lacking
   ||Xorg)

-- 
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/20140326/5c51ba9d/attachment.html>

[PATCH 00/12] drm/nouveau: support for GK20A, cont'd

[Alexandre Courbot]

Hi Lucas,

On Mon, Mar 24, 2014 at 10:19 PM, Lucas Stach  wrote:
> Hi Alexandre,
>
> Am Montag, den 24.03.2014, 17:42 +0900 schrieb Alexandre Courbot:
>> Hi everyone,
> [...]
>>
>> A few lines of hacks (not included here) are still needed to deal with cached
>> mappings triggering external aborts and CPU/GPU memory coherency issues, but 
>> I
>> hope to understand and address these issues next.
>
> For the coherency issue part you may want to look at my Nouveau on ARM
> series. Most of it never made it upstream, as I lacked the time to work
> further on this, but it solves the coherency issue from the kernel.

Oh, thanks for pointing this out, it will probably be most useful.
Shall I assume the patches at
https://www.mail-archive.com/nouveau at lists.freedesktop.org/msg13557.html
are up-to-date? Would you mind if I include the relevant patches of
yours in the next iteration of this series?

>
> It does so by doing the necessary manual cache flushes/invalidates on
> buffer access, so costs some performance. To avoid this you really want
> to get writecombined mappings into the kernel<->userspace interface.
> Simply mapping the pushbuf as WC/US has brought a 7% performance
> increase in OpenArena when I last tested this. This test was done with
> only one PCIe lane, so the perf increase may be even better with a more
> adequate interconnect.

Interestingly if I allow writecombined mappings in the kernel I get
faults when attempting the read the mapped area:

[   78.074854] Unhandled fault: external abort on non-linefetch
(0x1008) at 0xf003e010
...
[   78.337862] [] (nouveau_bo_rd32) from []
(nouveau_fence_update+0x5c/0x80)
[   78.352536] [] (nouveau_fence_update) from []
(nouveau_fence_done+0x18/0x28)
[   78.367531] [] (nouveau_fence_done) from []
(ttm_bo_wait+0x104/0x184)
[   78.381915] [] (ttm_bo_wait) from []
(nouveau_gem_ioctl_cpu_prep+0x40/0xe8)
[   78.396849] [] (nouveau_gem_ioctl_cpu_prep) from
[] (drm_ioctl+0x404/0x4b8)
[   78.411790] [] (drm_ioctl) from []
(nouveau_drm_ioctl+0x54/0x80)
[   78.425805] [] (nouveau_drm_ioctl) from []
(do_vfs_ioctl+0x3f0/0x5bc)
[   78.440277] [] (do_vfs_ioctl) from []
(SyS_ioctl+0x34/0x5c)
[   78.453918] [] (SyS_ioctl) from []
(ret_fast_syscall+0x0/0x30)

To avoid these I need to set the VRAM default_caching to
TTM_PL_FLAG_UNCACHED. It is not clear to me why this is needed. The BO
being accessed through the BAR, they are correctly considered as IO
memory and mapped using ttm_bo_ioremap(), so it really seems to be
unhappy with the WC mapping itself.

Note that if I go ahead and force the use of pgprot_writecombine() in
ttm_io_prot() to get writecombined user-space mappings, pure DRM
programs that map a buffer and try to read it fail similarly, while
Mesa's glReadPixels() seems to be happy. I'm not sure what it does
differently here.

Cheers,
Alex.

[PATCH] drm/radeon: clear needs_reset flag if IB test fails

[Christian König]

Am 26.03.2014 14:03, schrieb Alex Deucher:
> On Wed, Mar 26, 2014 at 7:04 AM, Christian K?nig
>  wrote:
>> From: Christian K?nig 
>>
>> If the IB test fails we don't want to reset the card over
>> and over again, just accept that it isn't working.
>>
>> Signed-off-by: Christian K?nig 
>> Cc: stable at vger.kernel.org
> You might want to add the link to the bug.

Good point.

>Other than that:
>
> Reviewed-by: Alex Deucher 

Do you think there will be another drm-fixes-3.14 this patch might 
become part of or should we pull it in through drm-next-3.15?

Christian.

>
>> ---
>>   drivers/gpu/drm/radeon/radeon_ring.c | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/gpu/drm/radeon/radeon_ring.c 
>> b/drivers/gpu/drm/radeon/radeon_ring.c
>> index 15e44a7..8391fca 100644
>> --- a/drivers/gpu/drm/radeon/radeon_ring.c
>> +++ b/drivers/gpu/drm/radeon/radeon_ring.c
>> @@ -257,6 +257,7 @@ int radeon_ib_ring_tests(struct radeon_device *rdev)
>>  r = radeon_ib_test(rdev, i, ring);
>>  if (r) {
>>  ring->ready = false;
>> +   rdev->needs_reset = false;
>>
>>  if (i == RADEON_RING_TYPE_GFX_INDEX) {
>>  /* oh, oh, that's really bad */
>> --
>> 1.9.1
>>

[Nouveau] [PATCH] nouveau: safen up nouveau_device list usage against concurrent access

[Ben Skeggs]

On Thu, Mar 13, 2014 at 12:05 PM, Ilia Mirkin  wrote:
> Signed-off-by: Ilia Mirkin 
Already said on IRC, but for posterity:

Reviewed-by: Ben Skeggs 

> ---
>  nouveau/nouveau.c | 29 -
>  nouveau/private.h |  3 ++-
>  2 files changed, 30 insertions(+), 2 deletions(-)
>
> diff --git a/nouveau/nouveau.c b/nouveau/nouveau.c
> index ee7893b..72c31cf 100644
> --- a/nouveau/nouveau.c
> +++ b/nouveau/nouveau.c
> @@ -85,6 +85,12 @@ nouveau_device_wrap(int fd, int close, struct 
> nouveau_device **pdev)
>
> if (!nvdev)
> return -ENOMEM;
> +   ret = pthread_mutex_init(&nvdev->lock, NULL);
> +   if (ret) {
> +   free(nvdev);
> +   return ret;
> +   }
> +
> nvdev->base.fd = fd;
>
> ver = drmGetVersion(fd);
> @@ -161,6 +167,7 @@ nouveau_device_del(struct nouveau_device **pdev)
> if (nvdev->close)
> drmClose(nvdev->base.fd);
> free(nvdev->client);
> +   pthread_mutex_destroy(&nvdev->lock);
> free(nvdev);
> *pdev = NULL;
> }
> @@ -191,6 +198,8 @@ nouveau_client_new(struct nouveau_device *dev, struct 
> nouveau_client **pclient)
> int id = 0, i, ret = -ENOMEM;
> uint32_t *clients;
>
> +   pthread_mutex_lock(&nvdev->lock);
> +
> for (i = 0; i < nvdev->nr_client; i++) {
> id = ffs(nvdev->client[i]) - 1;
> if (id >= 0)
> @@ -199,7 +208,7 @@ nouveau_client_new(struct nouveau_device *dev, struct 
> nouveau_client **pclient)
>
> clients = realloc(nvdev->client, sizeof(uint32_t) * (i + 1));
> if (!clients)
> -   return ret;
> +   goto unlock;
> nvdev->client = clients;
> nvdev->client[i] = 0;
> nvdev->nr_client++;
> @@ -214,6 +223,9 @@ out:
> }
>
> *pclient = &pcli->base;
> +
> +unlock:
> +   pthread_mutex_unlock(&nvdev->lock);
> return ret;
>  }
>
> @@ -225,7 +237,9 @@ nouveau_client_del(struct nouveau_client **pclient)
> if (pcli) {
> int id = pcli->base.id;
> nvdev = nouveau_device(pcli->base.device);
> +   pthread_mutex_lock(&nvdev->lock);
> nvdev->client[id / 32] &= ~(1 << (id % 32));
> +   pthread_mutex_unlock(&nvdev->lock);
> free(pcli->kref);
> free(pcli);
> }
> @@ -331,9 +345,12 @@ nouveau_object_find(struct nouveau_object *obj, uint32_t 
> pclass)
>  static void
>  nouveau_bo_del(struct nouveau_bo *bo)
>  {
> +   struct nouveau_device_priv *nvdev = nouveau_device(bo->device);
> struct nouveau_bo_priv *nvbo = nouveau_bo(bo);
> struct drm_gem_close req = { bo->handle };
> +   pthread_mutex_lock(&nvdev->lock);
> DRMLISTDEL(&nvbo->head);
> +   pthread_mutex_unlock(&nvdev->lock);
> if (bo->map)
> munmap(bo->map, bo->size);
> drmIoctl(bo->device->fd, DRM_IOCTL_GEM_CLOSE, &req);
> @@ -363,7 +380,9 @@ nouveau_bo_new(struct nouveau_device *dev, uint32_t 
> flags, uint32_t align,
> return ret;
> }
>
> +   pthread_mutex_lock(&nvdev->lock);
> DRMLISTADD(&nvbo->head, &nvdev->bo_list);
> +   pthread_mutex_unlock(&nvdev->lock);
>
> *pbo = bo;
> return 0;
> @@ -378,13 +397,16 @@ nouveau_bo_wrap(struct nouveau_device *dev, uint32_t 
> handle,
> struct nouveau_bo_priv *nvbo;
> int ret;
>
> +   pthread_mutex_lock(&nvdev->lock);
> DRMLISTFOREACHENTRY(nvbo, &nvdev->bo_list, head) {
> if (nvbo->base.handle == handle) {
> +   pthread_mutex_unlock(&nvdev->lock);
> *pbo = NULL;
> nouveau_bo_ref(&nvbo->base, pbo);
> return 0;
> }
> }
> +   pthread_mutex_unlock(&nvdev->lock);
>
> ret = drmCommandWriteRead(dev->fd, DRM_NOUVEAU_GEM_INFO,
>   &req, sizeof(req));
> @@ -396,7 +418,9 @@ nouveau_bo_wrap(struct nouveau_device *dev, uint32_t 
> handle,
> atomic_set(&nvbo->refcnt, 1);
> nvbo->base.device = dev;
> abi16_bo_info(&nvbo->base, &req);
> +   pthread_mutex_lock(&nvdev->lock);
> DRMLISTADD(&nvbo->head, &nvdev->bo_list);
> +   pthread_mutex_unlock(&nvdev->lock);
> *pbo = &nvbo->base;
> return 0;
> }
> @@ -413,13 +437,16 @@ nouveau_bo_name_ref(struct nouveau_device *dev, 
> uint32_t name,
> struct drm_gem_open req = { .name = name };
> int ret;
>
> +   pthread_mutex_lock(&nvdev->lock);
> DRMLISTFOREACHENTRY(nvbo, &nvdev->bo_list, head) {
> if (nvbo->name == name) {
> +   pthread_mutex_unlock(&nvdev->lock);
> *pbo = NULL;
>  

[PATCH 00/16] Atomic/nuclear modeset/pageflip

[Greg Hackmann]

On Wed, Mar 26, 2014 at 3:08 AM, Daniel Vetter  wrote:
>
> - You have an explicit callback for vblank events (well, just the
>   interrupt, afaics no support to get a vblank event for a specific frame
>   in the future). Any reason not to use android syncpoint fences for this
>   like everywhere else? Or is the idea behind all the fences hwc throws
>   around just to synchronize read/write access from
>   cpu/render/codec/whatever and not so much timing?
>

Vsync events are used to kick off Android's rendering loop.  The upshot is
that when SurfaceFlinger requests vsync events from the HWC HAL, it needs
to deliver them at every vsync even if the display hasn't changed.

Fences tell a consumer when the producer's done with the buffer, and aren't
really meant for timing.  (Or probably even useful for timing, since they
don't pass along any timestamping information about when the event
happened.)

- If I read this correct you mandate that the fences fields gets filled
>   out in the prepare hook, i.e. before we commit the new state to
>   hardware. You also mandate that the fences get eventually signalled even
>   when surfaceflinger decides to not commit the new state.
>

The HWC HAL needs to fill in the release fences during set().  The mandate
w.r.t. fences is that if SurfaceFlinger calls

prepare(A)
set(A)
prepare(B)
set(B)

and something inside set(B) fails for some reason, the HWC HAL must ensure
that the fences returned by set(A) eventually fire anyway.  That situation
really shouldn't happen unless something goes horribly wrong, since the
expectation is that prepare(B) will pick a composition that set(B) can
display.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140326/57872928/attachment.html>

[Nouveau] [PATCH 12/12] drm/nouveau: support for probing GK20A

[Ben Skeggs]

On Mon, Mar 24, 2014 at 6:42 PM, Alexandre Courbot  
wrote:
> Set the correct subdev/engine classes when GK20A (0xea) is probed.
>
> Signed-off-by: Alexandre Courbot 
> ---
>  drivers/gpu/drm/nouveau/core/engine/device/nve0.c | 20 
>  1 file changed, 20 insertions(+)
>
> diff --git a/drivers/gpu/drm/nouveau/core/engine/device/nve0.c 
> b/drivers/gpu/drm/nouveau/core/engine/device/nve0.c
> index 987edbc30a09..8509dd57de1f 100644
> --- a/drivers/gpu/drm/nouveau/core/engine/device/nve0.c
> +++ b/drivers/gpu/drm/nouveau/core/engine/device/nve0.c
> @@ -156,6 +156,26 @@ nve0_identify(struct nouveau_device *device)
> device->oclass[NVDEV_ENGINE_PPP] = &nvc0_ppp_oclass;
> device->oclass[NVDEV_ENGINE_PERFMON] = &nve0_perfmon_oclass;
> break;
> +   case 0xea:
> +   device->cname = "GK20A";
> +   device->oclass[NVDEV_SUBDEV_MC ] =  nvc3_mc_oclass;
> +   device->oclass[NVDEV_SUBDEV_BUS] =  nvc0_bus_oclass;
> +   device->oclass[NVDEV_SUBDEV_TIMER  ] = &nv04_timer_oclass;
As per note on the PTIMER patch, can just switch this to
"gk20a_timer_oclass" on the latest code.

> +   device->oclass[NVDEV_SUBDEV_FB ] =  nvea_fb_oclass;
> +   device->oclass[NVDEV_SUBDEV_IBUS   ] = &nvea_ibus_oclass;
> +   device->oclass[NVDEV_SUBDEV_INSTMEM] = nv50_instmem_oclass;
> +   device->oclass[NVDEV_SUBDEV_VM ] = &nvc0_vmmgr_oclass;
> +   device->oclass[NVDEV_SUBDEV_BAR] = &nvc0_bar_oclass;
> +   device->oclass[NVDEV_ENGINE_DMAOBJ ] = &nvd0_dmaeng_oclass;
> +   device->oclass[NVDEV_ENGINE_FIFO   ] =  nvea_fifo_oclass;
> +   /* TODO will need an implementation for this at some point... 
> */
> +#if 0
> +   device->oclass[NVDEV_ENGINE_SW ] =  nvc0_software_oclass;
> +#endif
> +   device->oclass[NVDEV_ENGINE_GR ] =  nvea_graph_oclass;
> +   device->oclass[NVDEV_ENGINE_COPY2  ] = &nve0_copy2_oclass;
> +   device->oclass[NVDEV_ENGINE_PERFMON] = &nve0_perfmon_oclass;
> +   break;
> case 0xf0:
> device->cname = "GK110";
> device->oclass[NVDEV_SUBDEV_VBIOS  ] = &nouveau_bios_oclass;
> --
> 1.9.1
>
> ___
> Nouveau mailing list
> Nouveau at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau

[PATCH 11/12] drm/nouveau: support GK20A in nouveau_accel_init()

[Ben Skeggs]

On Tue, Mar 25, 2014 at 9:10 AM, Thierry Reding
 wrote:
> On Mon, Mar 24, 2014 at 05:42:33PM +0900, Alexandre Courbot wrote:
>> GK20A does not embed a dedicated COPY engine and thus cannot allocate
>> the copy channel that nouveau_accel_init() attempts to create. It also
>> lacks any display hardware, so the creation of a software channel does
>> not apply neither.
>
> Perhaps this should be two separate patches?
>
>> diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
>> b/drivers/gpu/drm/nouveau/nouveau_drm.c
> [...]
>> + if (device->chipset == 0xea) {
>> + /* gk20a does not have CE0/CE1 */
>
> This would be another good candidate for a feature flag.
There are ways to query this in a chipset-independent way.  However,
despite reporting it as an error if no copy engines are available, the
code should continue on without the channel happily.  Perhaps we can
just punt the relevent error messages to a debug loglevel for now?

>
>> + arg0 = NVE0_CHANNEL_IND_ENGINE_GR;
>> + arg1 = 1;
>> + } else
>>   if (device->card_type >= NV_E0) {
>
> The formatting here is somewhat weird. From a brief look I couldn't find
> any indication that nouveau deviates from the standard coding style, so
> this should be:
>
> } else if (...) {
I use the former in a few places, despite it not entirely being
"correct".. It looks nicer though :)  I don't mind either way though.

>
>> + /* Need to figure out how to handle sw for gk20a */
>> + if (device->chipset == 0xea)
>> + goto skip_sw_init;
>
> The commit message makes it sound like SW isn't needed since gk20a
> "lacks any display hardware". In that case the comment here doesn't make
> much sense.
>
> Thierry
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

[PATCH 10/12] drm/nouveau/graph: add GK20A support

[Ben Skeggs]

On Mon, Mar 24, 2014 at 6:42 PM, Alexandre Courbot  
wrote:
> Add a GR device for GK20A based on NVE4, with the correct classes
> definitions (GK20A's 3D class is 0xa297).
>
> Most of the NVE4 code can be used on GK20A, so make relevant bits of
> NVE4 available to other chips as well.
This will need a bit of a rebase on top of the tree I mentioned
earlier (also queued for drm-next now), where I've further split out
and named the various chunks of state.

Does GK104 match entirely correctly, or just happen to work?  I could
probably hunt down the GK20A netlist images and check that actually :)

>
> Signed-off-by: Alexandre Courbot 
> ---
>  drivers/gpu/drm/nouveau/Makefile   |  1 +
>  .../gpu/drm/nouveau/core/engine/graph/ctxnve4.c|  4 +-
>  drivers/gpu/drm/nouveau/core/engine/graph/nvc0.h   |  9 +++
>  drivers/gpu/drm/nouveau/core/engine/graph/nve4.c   |  2 +-
>  drivers/gpu/drm/nouveau/core/engine/graph/nvea.c   | 75 
> ++
>  .../gpu/drm/nouveau/core/include/engine/graph.h|  1 +
>  6 files changed, 89 insertions(+), 3 deletions(-)
>  create mode 100644 drivers/gpu/drm/nouveau/core/engine/graph/nvea.c
>
> diff --git a/drivers/gpu/drm/nouveau/Makefile 
> b/drivers/gpu/drm/nouveau/Makefile
> index 708d2e33835f..032a4744f843 100644
> --- a/drivers/gpu/drm/nouveau/Makefile
> +++ b/drivers/gpu/drm/nouveau/Makefile
> @@ -270,6 +270,7 @@ nouveau-y += core/engine/graph/nvc8.o
>  nouveau-y += core/engine/graph/nvd7.o
>  nouveau-y += core/engine/graph/nvd9.o
>  nouveau-y += core/engine/graph/nve4.o
> +nouveau-y += core/engine/graph/nvea.o
>  nouveau-y += core/engine/graph/nvf0.o
>  nouveau-y += core/engine/graph/nv108.o
>  nouveau-y += core/engine/mpeg/nv31.o
> diff --git a/drivers/gpu/drm/nouveau/core/engine/graph/ctxnve4.c 
> b/drivers/gpu/drm/nouveau/core/engine/graph/ctxnve4.c
> index e2de73ee5eee..3904073f860d 100644
> --- a/drivers/gpu/drm/nouveau/core/engine/graph/ctxnve4.c
> +++ b/drivers/gpu/drm/nouveau/core/engine/graph/ctxnve4.c
> @@ -804,7 +804,7 @@ nve4_grctx_init_unk[] = {
> {}
>  };
>
> -static void
> +void
>  nve4_grctx_generate_mods(struct nvc0_graph_priv *priv, struct nvc0_grctx 
> *info)
>  {
> u32 magic[GPC_MAX][2];
> @@ -962,7 +962,7 @@ nve4_grctx_generate_main(struct nvc0_graph_priv *priv, 
> struct nvc0_grctx *info)
> nv_mask(priv, 0x41be10, 0x0080, 0x0080);
>  }
>
> -static struct nvc0_graph_init *
> +struct nvc0_graph_init *
>  nve4_grctx_init_hub[] = {
> nvc0_grctx_init_base,
> nve4_grctx_init_unk40xx,
> diff --git a/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.h 
> b/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.h
> index b0ab6de270b2..904f09b540c5 100644
> --- a/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.h
> +++ b/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.h
> @@ -221,6 +221,8 @@ void nvc0_grctx_generate_r418bb8(struct nvc0_graph_priv 
> *);
>  void nve4_grctx_generate_r418bb8(struct nvc0_graph_priv *);
>  void nvc0_grctx_generate_r406800(struct nvc0_graph_priv *);
>
> +void nve4_grctx_generate_mods(struct nvc0_graph_priv *, struct nvc0_grctx *);
> +
>  extern struct nouveau_oclass *nvc0_grctx_oclass;
>  extern struct nvc0_graph_init *nvc0_grctx_init_hub[];
>  extern struct nvc0_graph_init nvc0_grctx_init_base[];
> @@ -237,12 +239,17 @@ extern struct nvc0_graph_init nvc0_grctx_init_gpc_1[];
>  extern struct nvc0_graph_init nvc0_grctx_init_tpc[];
>  extern struct nvc0_graph_init nvc0_grctx_init_icmd[];
>  extern struct nvc0_graph_init nvd9_grctx_init_icmd[]; //
> +extern struct nvc0_graph_init nve4_grctx_init_icmd[];
> +
> +extern struct nvc0_graph_init *nve4_grctx_init_hub[];
> +extern struct nvc0_graph_init *nve4_grctx_init_gpc[];
>
>  extern struct nvc0_graph_mthd nvc0_grctx_init_mthd[];
>  extern struct nvc0_graph_init nvc0_grctx_init_902d[];
>  extern struct nvc0_graph_init nvc0_grctx_init_9039[];
>  extern struct nvc0_graph_init nvc0_grctx_init_90c0[];
>  extern struct nvc0_graph_init nvc0_grctx_init_mthd_magic[];
> +extern struct nvc0_graph_init nve4_grctx_init_a097[];
>
>  void nvc1_grctx_generate_mods(struct nvc0_graph_priv *, struct nvc0_grctx *);
>  void nvc1_grctx_generate_unkn(struct nvc0_graph_priv *);
> @@ -277,6 +284,8 @@ extern struct nvc0_graph_init nvf0_grctx_init_unk60xx[];
>
>  extern struct nouveau_oclass *nv108_grctx_oclass;
>
> +extern struct nvc0_graph_init *nve4_graph_init_mmio[];
> +
>  #define mmio_data(s,a,p) do {
>   \
> info->buffer[info->buffer_nr] = round_up(info->addr, (a));
>  \
> info->addr = info->buffer[info->buffer_nr++] + (s);   
>  \
> diff --git a/drivers/gpu/drm/nouveau/core/engine/graph/nve4.c 
> b/drivers/gpu/drm/nouveau/core/engine/graph/nve4.c
> index 05ec09c88517..442857c5c120 100644
> --- a/drivers/gpu/drm/nouveau/core/engine/graph/nve4.c
> +++ b/drivers/gpu/drm/nouveau/core/engine/graph/nve4.c
> @@ -298,7 +298,7 @@ nve4_graph_init(struct nouveau_obj

[Nouveau] [PATCH 09/12] drm/nouveau/graph: pad firmware code at load time

[Ben Skeggs]

On Mon, Mar 24, 2014 at 6:42 PM, Alexandre Courbot  
wrote:
> Pad the microcode to a multiple of 0x40, otherwise firmware will fail to
> run from non-prepadded firmware files.
>
> Signed-off-by: Alexandre Courbot 
> ---
>  drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c 
> b/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c
> index f997a18f5760..367e72daf8b1 100644
> --- a/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c
> +++ b/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c
> @@ -768,6 +768,10 @@ nvc0_graph_init_fw(struct nvc0_graph_priv *priv, u32 
> fuc_base,
> nv_wr32(priv, fuc_base + 0x0188, i >> 6);
> nv_wr32(priv, fuc_base + 0x0184, code->data[i]);
> }
> +
> +   /* code must be padded to 0x40 */
> +   for (; i < (((code->size / 4) + 0x3f) & ~0x3f); i++)
"for (; i & 0x3f; i++)" would work just as well :)

> +   nv_wr32(priv, fuc_base + 0x0184, 0);
>  }
>
>  static void
> --
> 1.9.1
>
> ___
> Nouveau mailing list
> Nouveau at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau

[PATCH 08/12] drm/nouveau/graph: enable when using external firmware

[Ben Skeggs]

On Tue, Mar 25, 2014 at 8:58 AM, Thierry Reding
 wrote:
> On Mon, Mar 24, 2014 at 05:42:30PM +0900, Alexandre Courbot wrote:
> [...]
>> diff --git a/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c 
>> b/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c
>> index 6ef8bf181b2d..f997a18f5760 100644
>> --- a/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c
>> +++ b/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c
>> @@ -1133,10 +1133,14 @@ nvc0_graph_ctor(struct nouveau_object *parent, 
>> struct nouveau_object *engine,
>>   struct nvc0_graph_oclass *oclass = (void *)bclass;
>>   struct nouveau_device *device = nv_device(parent);
>>   struct nvc0_graph_priv *priv;
>> + bool use_fw;
>
> Perhaps "ext_fw" or "use_ext_fw" would be more accurate.
>
>>   int ret, i;
>>
>> + use_fw = nouveau_boolopt(device->cfgopt, "NvGrUseFW", false);
>> +
>>   ret = nouveau_graph_create(parent, engine, bclass,
>> -(oclass->fecs.ucode != NULL), &priv);
>> +(oclass->fecs.ucode != NULL) || use_fw,
>> +&priv);
>
> Or perhaps a more intuitive way would be to name the variable "enable"
> and have something like:
>
> if (!nouveau_boolopt(device->cfgopt, "NvGrUseFW", false))
> enable = oclass->fecs.ucode != NULL;
> else
> enable = true;
>
> ret = nouveau_graph_create(parent, engine, bclass, enable, &priv);
> ...
Agreed, this looks a lot nicer.

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

[PATCH 00/16] Atomic/nuclear modeset/pageflip

[Greg Hackmann]

On Thu, Mar 20, 2014 at 5:28 PM, Rob Clark  wrote:

> oh, that's right.. I'm glad you reminded me, I do remember now talk of
> a field which drivers could use to return some opaque (to drm core)
> handle/value/token/whatever..
>
> hmm, for the non-vsync'd multi-display case, does it matter much one
> ioctl per display vs one globally?
>
> If no, I'd vote for just one output field in the ioctl struct which
> can be whatever the driver wants it to.. that would be pretty simple.


If you're planning to support generic clients, you'd at least need some way
to indicate the output contains an fd that the client's responsible for
closing.  Otherwise it would leak a fence (or whatever fd-backed object
that's being returned) each time it updates the display.


> > It's up to the vendor whether their HWC HAL does fine-grained error
> handling
> > and renegotiation like you're describing.  Typically they don't, they
> just
> > push that complexity into userspace instead.  e.g. if the display
> controller
> > needs to gang together two planes for a given configuration, the HWC
> HAL's
> > prepare() op will already know to set aside that extra plane and plan
> > accordingly.
>
> Well, I suspect that this is in the HWC HAL at all is a strong
> indication that we should think about including this somehow in the
> atomic ioctl.. considering that the trend for wayland compositors is a
> fairly generic userspace just using kms+gbm directly.  I suspect the
> alternative will only be an atomic2 ioctl at some point ;-)
>

These policies are complicated enough that I'm skeptical you could push
them into the kernel without making the drivers really large and
complicated.  A typical HWC HAL will have thousands of lines of code plus
pull in other helper libraries, and the bulk of that will be for planning
the composition in the prepare() op.  Maybe you could break some of that
out into common helper code, but IME and IMO the hardware constraints are
too different from SoC to SoC for that to scale.

That said, I'd be happy to be proven wrong -- if the hypothetical atomic2
ioctl has a kernel counterpart that I'm comfortable recommending to
vendors, being able to write a single generic HWC HAL would be good for
Android too.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140326/156b99a2/attachment.html>

[Nouveau] [PATCH 03/12] drm/nouveau/bar: only ioremap BAR3 if it exists

[Ben Skeggs]

On Tue, Mar 25, 2014 at 8:13 AM, Thierry Reding
 wrote:
> On Mon, Mar 24, 2014 at 05:42:25PM +0900, Alexandre Courbot wrote:
>> Some chips that use system memory exclusively (e.g. GK20A) do not
>> expose 2 BAR regions. For them only BAR1 exists, and it should be used
>> for USERD mapping. Do not map BAR3 if its resource does not exist.
>>
>> Signed-off-by: Alexandre Courbot 
>> ---
>>  drivers/gpu/drm/nouveau/core/subdev/bar/base.c | 7 +--
>>  1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/nouveau/core/subdev/bar/base.c 
>> b/drivers/gpu/drm/nouveau/core/subdev/bar/base.c
>> index bdf594116f3f..d713eeb75b13 100644
>> --- a/drivers/gpu/drm/nouveau/core/subdev/bar/base.c
>> +++ b/drivers/gpu/drm/nouveau/core/subdev/bar/base.c
>> @@ -110,6 +110,7 @@ nouveau_bar_create_(struct nouveau_object *parent,
>>  {
>>   struct nouveau_device *device = nv_device(parent);
>>   struct nouveau_bar *bar;
>> + bool has_bar3 = nv_device_resource_len(device, 3) != 0;
>
> I don't think this variable is really necessary since you only use the
> expression once anyway, but I don't feel very strongly about it, so
> either way:
I'd also prefer it folded in, but it's not a big deal.  A couple of
other upcoming comments will require a re-spin anyway, so we may as
well :)

>
> Reviewed-by: Thierry Reding 
>
> ___
> Nouveau mailing list
> Nouveau at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau
>

[PATCH 02/12] drm/nouveau/timer: skip calibration on GK20A

[Ben Skeggs]

On Tue, Mar 25, 2014 at 7:54 AM, Thierry Reding
 wrote:
> On Mon, Mar 24, 2014 at 05:42:24PM +0900, Alexandre Courbot wrote:
>> GK20A's timer is directly attached to the system timer and cannot be
>> calibrated. Skip the calibration phase on that chip since the
>> corresponding registers do not exist.
>>
>> Signed-off-by: Alexandre Courbot 
>> ---
>>  drivers/gpu/drm/nouveau/core/subdev/timer/nv04.c | 19 +--
>>  1 file changed, 13 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/nouveau/core/subdev/timer/nv04.c 
>> b/drivers/gpu/drm/nouveau/core/subdev/timer/nv04.c
>> index c0bdd10358d7..822fe0d8a871 100644
>> --- a/drivers/gpu/drm/nouveau/core/subdev/timer/nv04.c
>> +++ b/drivers/gpu/drm/nouveau/core/subdev/timer/nv04.c
>> @@ -185,6 +185,10 @@ nv04_timer_init(struct nouveau_object *object)
>>   if (ret)
>>   return ret;
>>
>> + /* gk20a does not have the calibration registers */
>> + if (device->chipset == 0xea)
>> + goto skip_clk_init;
>
> I'm concerned that this won't scale in the future. Perhaps a better
> solution would be to add a "flags" or "features" field to struct
> nouveau_device along with feature bits such as HAS_CALIBRATION or
> similar.
>
> That way we don't have to touch this code for every new future Tegra
> chip. Unless perhaps if there's a reason to expect things to change in
> newer generations.
I've already handled this in a slightly different way in the tree I'd
previously pointed Alex at (I think!), as I needed to do the same for
GM107.

Should just be able to use that implementation (so, just change the
probe patch) here too.

Thanks,
Ben.

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

[Bug 76501] fences regression

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

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

Christian K?nig  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #13 from Christian K?nig  ---
Ah, ok. That makes sense, cause kexec and UVD are known to not work together by
design.

Closing this.

-- 
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/20140326/a35c534f/attachment.html>

[Bug 76501] fences regression

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

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

--- Comment #12 from Ortwin Gl?ck  ---
OK to closing.

The other problem has resolved itself, by the way. For convenience I had always
booted these kernels via kexec, which was the reason for the GPU lockup. After
a normal warm boot the problem went away.

-- 
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/20140326/028c7fa6/attachment-0001.html>

[PATCH] drm/nouveau: don't suspend/resume display on runtime s/r

[Dave Airlie]

From: Dave Airlie 

This should ensure we don't hit a locking problem when someone
wakes us up via a connector, we should never go into suspend
while the display is on anyways.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/nouveau/nouveau_drm.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 89c484d..d936e88 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -486,13 +486,13 @@ nouveau_drm_remove(struct pci_dev *pdev)
 }

 static int
-nouveau_do_suspend(struct drm_device *dev)
+nouveau_do_suspend(struct drm_device *dev, bool runtime)
 {
struct nouveau_drm *drm = nouveau_drm(dev);
struct nouveau_cli *cli;
int ret;

-   if (dev->mode_config.num_crtc) {
+   if (dev->mode_config.num_crtc && !runtime) {
NV_INFO(drm, "suspending display...\n");
ret = nouveau_display_suspend(dev);
if (ret)
@@ -566,7 +566,7 @@ int nouveau_pmops_suspend(struct device *dev)
if (drm_dev->mode_config.num_crtc)
nouveau_fbcon_set_suspend(drm_dev, 1);

-   ret = nouveau_do_suspend(drm_dev);
+   ret = nouveau_do_suspend(drm_dev, false);
if (ret)
return ret;

@@ -646,7 +646,7 @@ static int nouveau_pmops_freeze(struct device *dev)
if (drm_dev->mode_config.num_crtc)
nouveau_fbcon_set_suspend(drm_dev, 1);

-   ret = nouveau_do_suspend(drm_dev);
+   ret = nouveau_do_suspend(drm_dev, false);
return ret;
 }

@@ -879,7 +879,7 @@ static int nouveau_pmops_runtime_suspend(struct device *dev)
drm_kms_helper_poll_disable(drm_dev);
vga_switcheroo_set_dynamic_switch(pdev, VGA_SWITCHEROO_OFF);
nouveau_switcheroo_optimus_dsm();
-   ret = nouveau_do_suspend(drm_dev);
+   ret = nouveau_do_suspend(drm_dev, true);
pci_save_state(pdev);
pci_disable_device(pdev);
pci_set_power_state(pdev, PCI_D3cold);
@@ -905,8 +905,6 @@ static int nouveau_pmops_runtime_resume(struct device *dev)
pci_set_master(pdev);

ret = nouveau_do_resume(drm_dev);
-   if (drm_dev->mode_config.num_crtc)
-   nouveau_display_resume(drm_dev);
drm_kms_helper_poll_enable(drm_dev);
/* do magic */
nv_mask(device, 0x88488, (1 << 25), (1 << 25));
-- 
1.8.3.1

[PATCH] drm/nouveau: fail runtime pm properly.

[Dave Airlie]

From: Dave Airlie 

If we were on a non-optimus device, we'd return -EINVAL, this would
lead to the over engineered runtime pm system to go into an error
state, subsequent get_sync's would fail, so we'd never be able
to open the device again.

(like really get_sync shouldn't fail if the device isn't powered
down).

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/nouveau/nouveau_drm.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 89c484d..4ee702a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -866,13 +866,16 @@ static int nouveau_pmops_runtime_suspend(struct device 
*dev)
struct drm_device *drm_dev = pci_get_drvdata(pdev);
int ret;

-   if (nouveau_runtime_pm == 0)
-   return -EINVAL;
+   if (nouveau_runtime_pm == 0) {
+   pm_runtime_forbid(dev);
+   return -EBUSY;
+   }

/* are we optimus enabled? */
if (nouveau_runtime_pm == -1 && !nouveau_is_optimus() && 
!nouveau_is_v1_dsm()) {
DRM_DEBUG_DRIVER("failing to power off - not optimus\n");
-   return -EINVAL;
+   pm_runtime_forbid(dev);
+   return -EBUSY;
}

nv_debug_level(SILENT);
@@ -923,12 +926,15 @@ static int nouveau_pmops_runtime_idle(struct device *dev)
struct nouveau_drm *drm = nouveau_drm(drm_dev);
struct drm_crtc *crtc;

-   if (nouveau_runtime_pm == 0)
+   if (nouveau_runtime_pm == 0) {
+   pm_runtime_forbid(dev);
return -EBUSY;
+   }

/* are we optimus enabled? */
if (nouveau_runtime_pm == -1 && !nouveau_is_optimus() && 
!nouveau_is_v1_dsm()) {
DRM_DEBUG_DRIVER("failing to power off - not optimus\n");
+   pm_runtime_forbid(dev);
return -EBUSY;
}

-- 
1.8.3.1

[Bug 76501] fences regression

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

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

Christian K?nig  changed:

   What|Removed |Added

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

--- Comment #11 from Christian K?nig  ---
Perfect, thanks for the help.

Patch is on it's way upstream so any objections to closing this bug then?

-- 
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/20140326/6b086c01/attachment.html>

[PATCH] drm: Try to acquire modeset lock on panic or sysrq

[David Herrmann]

Hi

On Tue, Mar 25, 2014 at 1:25 PM, Thierry Reding
 wrote:
> From: Thierry Reding 
>
> Commit 62ff94a54921 "drm/crtc-helper: remove LOCKING from kerneldoc"
> causes drm_helper_crtc_in_use() and drm_helper_encoder_in_use() to
> complain loudly during a kernel panic or sysrq processing. This is
> caused by nobody acquiring the modeset lock in these code paths.
>
> This patch fixes this by trying to acquire the modeset lock for each
> FB helper that's forced to kernel mode. If the lock can't be acquired,
> it's likely that somebody else is performing a modeset. However, doing
> another modeset concurrently might make things even worse, so the safe
> option is to simply bail out in that case.
>
> Signed-off-by: Thierry Reding 
> ---
>  drivers/gpu/drm/drm_fb_helper.c | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 9580393628a0..afce7cbd5149 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -325,12 +325,21 @@ static bool drm_fb_helper_force_kernel_mode(void)
> return false;
>
> list_for_each_entry(helper, &kernel_fb_helper_list, kernel_fb_list) {
> -   if (helper->dev->switch_power_state == DRM_SWITCH_POWER_OFF)
> +   struct drm_device *dev = helper->dev;
> +
> +   if (dev->switch_power_state == DRM_SWITCH_POWER_OFF)
> +   continue;
> +
> +   if (!mutex_trylock(&dev->mode_config.mutex)) {
> +   error = true;

Reviewed-by: David Herrmann 

Thanks
David

> continue;
> +   }
>
> ret = drm_fb_helper_restore_fbdev_mode(helper);
> if (ret)
> error = true;
> +
> +   mutex_unlock(&dev->mode_config.mutex);
> }
> return error;
>  }
> --
> 1.9.1
>

[PATCH v2 4/4] Documentation: drm: describing plane alpha and color blending property

[David Herrmann]

Hi

On Tue, Mar 25, 2014 at 3:32 PM,   wrote:
> From: Sagar Kamble 
>
> v2: Added description for "src-color" and "constant-alpha" property.
>
> Cc: Rob Landley 
> Cc: Dave Airlie 
> Cc: Daniel Vetter 
> Cc: Laurent Pinchart 
> Cc: David Herrmann 
> Cc: Alex Deucher 
> Cc: "Ville Syrj?l?" 
> Cc: Sagar Kamble 
> Cc: "Purushothaman, Vijay A" 
> Cc: linux-doc at vger.kernel.org
> Cc: dri-devel at lists.freedesktop.org
> Signed-off-by: Sagar Kamble 
> ---
>  Documentation/DocBook/drm.tmpl | 23 ++-
>  1 file changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> index 104402a..77a45fb 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -2253,6 +2253,14 @@ void intel_crt_init(struct drm_device *dev)
>  enumerated bits defined by the property.
>  
>  
> +  DRM_MODE_PROP_32BIT_PAIR
> +  This flag restricts Bitmask properties restricts 
> all
> +   enumerated values to the 0..31 range.
> +During get operation instance values combine one or more of the
> +enumerated bits defined by the property. During get user can 
> specify
> +   {type, value} pair.

Please rewrite that, lots of typos in there. Furthermore, if you use
verbs as nouns, you should emphasize them. So in your text, please
somehow emphasize/quote 'get'.

Thanks
David

> +
> +
>DRM_MODE_PROP_BLOB
>Blob properties store a binary blob without any 
> format
>  restriction. The binary blobs are created as KMS standalone 
> objects,
> @@ -2336,7 +2344,7 @@ void intel_crt_init(struct drm_device *dev)
> 
> 
> DRM
> -   Generic
> +   Generic
> "EDID"
> BLOB | IMMUTABLE
> 0
> @@ -2351,6 +2359,19 @@ void intel_crt_init(struct drm_device *dev)
> Contains DPMS operation mode value.
> 
> 
> +   "blend"
> +   BITMASK | 32BIT_PAIR
> +   { {0, "zero"}, {1, "one"}, {2, "src-color"}, {3, 
> "one-minus-src-color"}
> +   , {4, "dst-color"}, {5, "one-minus-dst-color"}, {6, "src-alpha"}, {7, 
> "one-minus-src-alpha"}, {8, "dst-alpha"}
> +   , {9, "one-minus-dst-alpha"}, {10, "constant-color"}, {11, 
> "one-minus-constant-color"}, {12, "constant-alpha"}
> +   , {13, "one-minus-constant-alpha"}, {14, "alpha-saturate"} }
> +   Plane
> +   Contains plane alpha/color blending operation 
> values. These are modeled after glBlendFunc API
> +   in OpenGL. Currently only "src-color" and "constant-alpha" are 
> supported. "src-color" will consider supplied fb
> +   with plane's pixel format as input without any additional color/alpha 
> changes."constant-alpha" will apply constant
> +   transparency to all pixels in addition to source color.
> +   
> +   
> DVI-I
> "subconnector"
> ENUM
> --
> 1.8.5
>

[PATCH] drm/radeon: clear needs_reset flag if IB test fails

[Christian König]

From: Christian K?nig 

If the IB test fails we don't want to reset the card over
and over again, just accept that it isn't working.

Signed-off-by: Christian K?nig 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/radeon_ring.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/radeon/radeon_ring.c 
b/drivers/gpu/drm/radeon/radeon_ring.c
index 15e44a7..8391fca 100644
--- a/drivers/gpu/drm/radeon/radeon_ring.c
+++ b/drivers/gpu/drm/radeon/radeon_ring.c
@@ -257,6 +257,7 @@ int radeon_ib_ring_tests(struct radeon_device *rdev)
r = radeon_ib_test(rdev, i, ring);
if (r) {
ring->ready = false;
+   rdev->needs_reset = false;

if (i == RADEON_RING_TYPE_GFX_INDEX) {
/* oh, oh, that's really bad */
-- 
1.9.1

Hiding a monitor from all apps except one

[Ilya Faenson]

Dear DRM Experts,

My assignment is to make sure the more or less standard HDMI-connected monitor 
is visible and accessible to a single (our own) OpenGL application only. That 
monitor is part of the larger device so it does not make sense for anybody else 
to interfere with its use. The solution should work with any graphics adapter.

I see a few virtual monitor implementations available like VirtualGL, vcrtcm, 
various VNC flavors but we rather need to hide an existing monitor rather than 
create a virtual one. I guess we could try creating a virtual monitor, mapping 
it into the physical one, but the hiding it from almost everybody at the upper 
edge of the DRM might be tricky. The background: I'm a very experienced driver 
developer but I'm new to Linux graphics internals.

All ideas would be much appreciated!

Ilya Faenson
Rockville, MD USA


-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140326/ca9bc6bb/attachment.html>

[PATCH 00/12] drm/nouveau: support for GK20A, cont'd

[Lucas Stach]

Hi Alexandre,

Am Mittwoch, den 26.03.2014, 15:33 +0900 schrieb Alexandre Courbot:
> Hi Lucas,
> 
> On Mon, Mar 24, 2014 at 10:19 PM, Lucas Stach  
> wrote:
> > Hi Alexandre,
> >
> > Am Montag, den 24.03.2014, 17:42 +0900 schrieb Alexandre Courbot:
> >> Hi everyone,
> > [...]
> >>
> >> A few lines of hacks (not included here) are still needed to deal with 
> >> cached
> >> mappings triggering external aborts and CPU/GPU memory coherency issues, 
> >> but I
> >> hope to understand and address these issues next.
> >
> > For the coherency issue part you may want to look at my Nouveau on ARM
> > series. Most of it never made it upstream, as I lacked the time to work
> > further on this, but it solves the coherency issue from the kernel.
> 
> Oh, thanks for pointing this out, it will probably be most useful.
> Shall I assume the patches at
> https://www.mail-archive.com/nouveau at lists.freedesktop.org/msg13557.html
> are up-to-date? Would you mind if I include the relevant patches of
> yours in the next iteration of this series?
> 
> >
> > It does so by doing the necessary manual cache flushes/invalidates on
> > buffer access, so costs some performance. To avoid this you really want
> > to get writecombined mappings into the kernel<->userspace interface.
> > Simply mapping the pushbuf as WC/US has brought a 7% performance
> > increase in OpenArena when I last tested this. This test was done with
> > only one PCIe lane, so the perf increase may be even better with a more
> > adequate interconnect.
> 
> Interestingly if I allow writecombined mappings in the kernel I get
> faults when attempting the read the mapped area:
> 
This is most likely because your handling of those buffers produces
conflicting mappings (if my understanding of what you are doing is
right).

At first you allocate memory from CMA without changing the pgprot flags.
This yields pages which are mapped uncached or cached (when moveable
pages are purged from CMA to make space for your buffer) into the
kernels linear space.

Later you regard this memory as iomem (it isn't!) and let TTM remap
those pages into the vmalloc area with pgprot set to writecombined.

I don't know exactly why this is causing havoc, but having two
conflicting virtual mappings of the same physical memory is documented
to at least produce undefined behavior on ARMv7.

Regards,
Lucas

> [   78.074854] Unhandled fault: external abort on non-linefetch
> (0x1008) at 0xf003e010
> ...
> [   78.337862] [] (nouveau_bo_rd32) from []
> (nouveau_fence_update+0x5c/0x80)
> [   78.352536] [] (nouveau_fence_update) from []
> (nouveau_fence_done+0x18/0x28)
> [   78.367531] [] (nouveau_fence_done) from []
> (ttm_bo_wait+0x104/0x184)
> [   78.381915] [] (ttm_bo_wait) from []
> (nouveau_gem_ioctl_cpu_prep+0x40/0xe8)
> [   78.396849] [] (nouveau_gem_ioctl_cpu_prep) from
> [] (drm_ioctl+0x404/0x4b8)
> [   78.411790] [] (drm_ioctl) from []
> (nouveau_drm_ioctl+0x54/0x80)
> [   78.425805] [] (nouveau_drm_ioctl) from []
> (do_vfs_ioctl+0x3f0/0x5bc)
> [   78.440277] [] (do_vfs_ioctl) from []
> (SyS_ioctl+0x34/0x5c)
> [   78.453918] [] (SyS_ioctl) from []
> (ret_fast_syscall+0x0/0x30)
> 
> To avoid these I need to set the VRAM default_caching to
> TTM_PL_FLAG_UNCACHED. It is not clear to me why this is needed. The BO
> being accessed through the BAR, they are correctly considered as IO
> memory and mapped using ttm_bo_ioremap(), so it really seems to be
> unhappy with the WC mapping itself.
> 
> Note that if I go ahead and force the use of pgprot_writecombine() in
> ttm_io_prot() to get writecombined user-space mappings, pure DRM
> programs that map a buffer and try to read it fail similarly, while
> Mesa's glReadPixels() seems to be happy. I'm not sure what it does
> differently here.
> 
> Cheers,
> Alex.

-- 
Pengutronix e.K.   | Lucas Stach |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

[PATCH 00/16] Atomic/nuclear modeset/pageflip

[Daniel Vetter]

On Thu, Mar 20, 2014 at 03:34:19PM -0700, Greg Hackmann wrote:
> On Wed, Mar 19, 2014 at 5:23 AM, Rob Clark  wrote:
> 
> > > Hm, do you have some pointers to read up on this? I still think a more
> > > elaborate fail scheme is overkill, but maybe reading a bit of android
> > code
> > > convinces me differently ;-)
> >
> > sadly no pointers to anything to read (but ofc would be interested if
> > anyone else does)..
> >
> 
> The hardware composer HAL is probably the best reference for what Android
> needs from display.  It's defined and documented here (see struct
> hwc_composer_device_1):
> 
> *https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/hwcomposer.h
> *
> 
> (You can disregard any HWC 1.0 specific behavior in that documentation,
> that's only around for legacy reasons and we strongly encourage vendors not
> to implement HWC 1.0 anymore.)
> 
> Vendors need to ship a compliant HWC HAL implementation on their devices.
>  We don't mandate anything about their userspace/kernel interface beyond
> that.
> 
> 
> >  * I kinda would still like to add to the atomic ioctl some way to indicate
> >ok/error on a bit finer granularity than per-ioctl.  Ie. perhaps an
> >array where userspace can ask for results per KMS object (crtc/plane)?
> >Something along these lines would give the kernel a bit more flexibility
> >to deal with some of the edge cases which come up when you gang crtcs
> >for ultra high resolution displays.  In short, it would let the driver
> >"steal" some of the planes if needed from userspace.
> >
> >This would also, conveniently, be pretty similar to how (AFAIU) hw
> >compositor and ADF work on android.  Which seems like it would be useful
> >to eventually enable android devices to use an upstream display driver.
> >
> >For this we could pretty easily just throw in a placeholder that we
> >could replace later with an optional ptr to __user array.  I think
> >that would be fine for an initial version, but I just wanted to throw
> >this idea out there, because I think it will become important.
> >
> 
> SurfaceFlinger needs the HWC HAL to return a retire fence fd on each flip,
> for each display.  Per-interface return data would be a good fit for this,
> but per-CRTC or per-plane would work too (userspace could assemble a
> per-interface fence by merging finer-grained fences).
> 
> It's up to the vendor whether their HWC HAL does fine-grained error
> handling and renegotiation like you're describing.  Typically they don't,
> they just push that complexity into userspace instead.  e.g. if the display
> controller needs to gang together two planes for a given configuration, the
> HWC HAL's prepare() op will already know to set aside that extra plane and
> plan accordingly.

I've read through the hwc interface stuff and some question only
marginally related to atomic pageflips poppped up.

- You have an explicit callback for vblank events (well, just the
  interrupt, afaics no support to get a vblank event for a specific frame
  in the future). Any reason not to use android syncpoint fences for this
  like everywhere else? Or is the idea behind all the fences hwc throws
  around just to synchronize read/write access from
  cpu/render/codec/whatever and not so much timing?

- If I read this correct you mandate that the fences fields gets filled
  out in the prepare hook, i.e. before we commit the new state to
  hardware. You also mandate that the fences get eventually signalled even
  when surfaceflinger decides to not commit the new state. I see two
  consequences from that:

  - You create fences before the kernel is committed to execute the
relevant event which will trigger the fence.
  - Userspace seems to be required to trigger fences manually to unblock
things in case the hw state isn't committed.

  This seems to be squarely at odds with the hw fences Maarten Lankhorst,
  which currently have two guarantees:
  - Fences can only be created when the kernel commits to execute the
event that will trigger the fence.
  - A global ordering is imposed upon all fence updates (and so scheduled
depencies when one fences needs to wait for another).

  Together this ensures that we never schedule a deadlock in hw fences and
  that no hw fence ever depends upon userspace signalling some fences.

  How do you tackle these issues with surfaceflinger/hwc? Or if this blows
  up and the hw deadlocks it's the integrates problem to track it down (or
  just reset the gpu and everything else to get unstuck)?

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

[PATCH] drm/radeon: clear needs_reset flag if IB test fails

[Alex Deucher]

On Wed, Mar 26, 2014 at 9:50 AM, Christian K?nig
 wrote:
> Am 26.03.2014 14:03, schrieb Alex Deucher:
>
>> On Wed, Mar 26, 2014 at 7:04 AM, Christian K?nig
>>  wrote:
>>>
>>> From: Christian K?nig 
>>>
>>> If the IB test fails we don't want to reset the card over
>>> and over again, just accept that it isn't working.
>>>
>>> Signed-off-by: Christian K?nig 
>>> Cc: stable at vger.kernel.org
>>
>> You might want to add the link to the bug.
>
>
> Good point.
>
>
>>Other than that:
>>
>> Reviewed-by: Alex Deucher 
>
>
> Do you think there will be another drm-fixes-3.14 this patch might become
> part of or should we pull it in through drm-next-3.15?
>

Probably 3.15 at this point.

Alex

> Christian.
>
>
>>
>>> ---
>>>   drivers/gpu/drm/radeon/radeon_ring.c | 1 +
>>>   1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/gpu/drm/radeon/radeon_ring.c
>>> b/drivers/gpu/drm/radeon/radeon_ring.c
>>> index 15e44a7..8391fca 100644
>>> --- a/drivers/gpu/drm/radeon/radeon_ring.c
>>> +++ b/drivers/gpu/drm/radeon/radeon_ring.c
>>> @@ -257,6 +257,7 @@ int radeon_ib_ring_tests(struct radeon_device *rdev)
>>>  r = radeon_ib_test(rdev, i, ring);
>>>  if (r) {
>>>  ring->ready = false;
>>> +   rdev->needs_reset = false;
>>>
>>>  if (i == RADEON_RING_TYPE_GFX_INDEX) {
>>>  /* oh, oh, that's really bad */
>>> --
>>> 1.9.1
>>>
>

[RFC] dma-buf: Implement test module

[Thierry Reding]

On Tue, Mar 25, 2014 at 07:01:10PM +0100, Sam Ravnborg wrote:
> > 
> > There are two things that don't work too well with this. First this
> > causes the build to break if the build machine doesn't have the new
> > public header (include/uapi/linux/dma-buf.h) installed yet. So the only
> > way to make this work would be by building the kernel once with SAMPLES
> > disabled, install the headers and then build again with SAMPLES enabled.
> > Which really isn't very nice.
> > 
> > One other option that I've tried is to modify the include path so that
> > the test program would get the in-tree copy of the public header file,
> > but that didn't build properly either because the header files aren't
> > properly sanitized and therefore the compiler complains about it
> > (include/uapi/linux/types.h).
> > 
> > One other disadvantage of carrying the sample program in the tree is
> > that there's only infrastructure to build programs natively on the build
> > machine. That's somewhat unfortunate because if you want to run the test
> > program on a different architecture you have to either compile the
> > kernel natively on that architecture (which isn't very practical on many
> > embedded devices) or cross-compile manually.
> > 
> > I think a much nicer solution would be to add infrastructure to cross-
> > compile these test programs, so that they end up being built for the
> > same architecture as the kernel image (i.e. using CROSS_COMPILE).
> > 
> > Adding Michal and the linux-kbuild mailing list, perhaps this has been
> > discussed before, or maybe somebody has a better idea on how to solve
> > this.
> I actually looked into this some time ago.
> May try to dust off the patch.
> IIRC the kernel provided headers were used for building - not the one 
> installed on the machine.
> And crosscompile were supported.

That sounds exactly like what I'd want for this. If you need any help,
please let me know.

Thanks,
Thierry
-- 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/20140326/8b9d4745/attachment.sig>

[PATCH v3 2/3] drm/panel: add ld9040 driver

[Andrzej Hajda]

The patch adds LD9040 parallel RGB panel driver with SPI control interface.
The driver uses drm_panel framework.

Signed-off-by: Andrzej Hajda 
---
v2: removed useless include
v3: added SPI dependency to Kconfig
---
 drivers/gpu/drm/panel/Kconfig|   7 +
 drivers/gpu/drm/panel/Makefile   |   1 +
 drivers/gpu/drm/panel/panel-ld9040.c | 376 +++
 3 files changed, 384 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-ld9040.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 3e0f13d..f0fcb62 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -16,4 +16,11 @@ config DRM_PANEL_SIMPLE
  that it can be automatically turned off when the panel goes into a
  low power state.

+config DRM_PANEL_LD9040
+   tristate "LD9040 RGB/SPI panel"
+   depends on DRM && DRM_PANEL
+   depends on OF
+   select SPI
+   select VIDEOMODE_HELPERS
+
 endmenu
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index af9dfa2..4f7dfce 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
+obj-$(CONFIG_DRM_PANEL_LD9040) += panel-ld9040.o
diff --git a/drivers/gpu/drm/panel/panel-ld9040.c 
b/drivers/gpu/drm/panel/panel-ld9040.c
new file mode 100644
index 000..1f1f837
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-ld9040.c
@@ -0,0 +1,376 @@
+/*
+ * ld9040 AMOLED LCD drm_panel driver.
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd
+ * Derived from drivers/video/backlight/ld9040.c
+ *
+ * Andrzej Hajda 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+/* Manufacturer Command Set */
+#define MCS_MANPWR 0xb0
+#define MCS_ELVSS_ON   0xb1
+#define MCS_USER_SETTING   0xf0
+#define MCS_DISPCTL0xf2
+#define MCS_GTCON  0xf7
+#define MCS_PANEL_CONDITION0xf8
+#define MCS_GAMMA_SET1 0xf9
+#define MCS_GAMMA_CTRL 0xfb
+
+/* array of gamma tables for gamma value 2.2 */
+static u8 const ld9040_gammas[25][22] = {
+   { 0xf9, 0x00, 0x13, 0xb2, 0xba, 0xd2, 0x00, 0x30, 0x00, 0xaf, 0xc0,
+ 0xb8, 0xcd, 0x00, 0x3d, 0x00, 0xa8, 0xb8, 0xb7, 0xcd, 0x00, 0x44 },
+   { 0xf9, 0x00, 0x13, 0xb9, 0xb9, 0xd0, 0x00, 0x3c, 0x00, 0xaf, 0xbf,
+ 0xb6, 0xcb, 0x00, 0x4b, 0x00, 0xa8, 0xb9, 0xb5, 0xcc, 0x00, 0x52 },
+   { 0xf9, 0x00, 0x13, 0xba, 0xb9, 0xcd, 0x00, 0x41, 0x00, 0xb0, 0xbe,
+ 0xb5, 0xc9, 0x00, 0x51, 0x00, 0xa9, 0xb9, 0xb5, 0xca, 0x00, 0x57 },
+   { 0xf9, 0x00, 0x13, 0xb9, 0xb8, 0xcd, 0x00, 0x46, 0x00, 0xb1, 0xbc,
+ 0xb5, 0xc8, 0x00, 0x56, 0x00, 0xaa, 0xb8, 0xb4, 0xc9, 0x00, 0x5d },
+   { 0xf9, 0x00, 0x13, 0xba, 0xb8, 0xcb, 0x00, 0x4b, 0x00, 0xb3, 0xbc,
+ 0xb4, 0xc7, 0x00, 0x5c, 0x00, 0xac, 0xb8, 0xb4, 0xc8, 0x00, 0x62 },
+   { 0xf9, 0x00, 0x13, 0xbb, 0xb7, 0xca, 0x00, 0x4f, 0x00, 0xb4, 0xbb,
+ 0xb3, 0xc7, 0x00, 0x60, 0x00, 0xad, 0xb8, 0xb4, 0xc7, 0x00, 0x67 },
+   { 0xf9, 0x00, 0x47, 0xba, 0xb6, 0xca, 0x00, 0x53, 0x00, 0xb5, 0xbb,
+ 0xb3, 0xc6, 0x00, 0x65, 0x00, 0xae, 0xb8, 0xb3, 0xc7, 0x00, 0x6c },
+   { 0xf9, 0x00, 0x71, 0xbb, 0xb5, 0xc8, 0x00, 0x57, 0x00, 0xb5, 0xbb,
+ 0xb0, 0xc5, 0x00, 0x6a, 0x00, 0xae, 0xb9, 0xb1, 0xc6, 0x00, 0x70 },
+   { 0xf9, 0x00, 0x7b, 0xbb, 0xb4, 0xc8, 0x00, 0x5b, 0x00, 0xb5, 0xba,
+ 0xb1, 0xc4, 0x00, 0x6e, 0x00, 0xae, 0xb9, 0xb0, 0xc5, 0x00, 0x75 },
+   { 0xf9, 0x00, 0x82, 0xba, 0xb4, 0xc7, 0x00, 0x5f, 0x00, 0xb5, 0xba,
+ 0xb0, 0xc3, 0x00, 0x72, 0x00, 0xae, 0xb8, 0xb0, 0xc3, 0x00, 0x7a },
+   { 0xf9, 0x00, 0x89, 0xba, 0xb3, 0xc8, 0x00, 0x62, 0x00, 0xb6, 0xba,
+ 0xaf, 0xc3, 0x00, 0x76, 0x00, 0xaf, 0xb7, 0xae, 0xc4, 0x00, 0x7e },
+   { 0xf9, 0x00, 0x8b, 0xb9, 0xb3, 0xc7, 0x00, 0x65, 0x00, 0xb7, 0xb8,
+ 0xaf, 0xc3, 0x00, 0x7a, 0x00, 0x80, 0xb6, 0xae, 0xc4, 0x00, 0x81 },
+   { 0xf9, 0x00, 0x93, 0xba, 0xb3, 0xc5, 0x00, 0x69, 0x00, 0xb8, 0xb9,
+ 0xae, 0xc1, 0x00, 0x7f, 0x00, 0xb0, 0xb6, 0xae, 0xc3, 0x00, 0x85 },
+   { 0xf9, 0x00, 0x97, 0xba, 0xb2, 0xc5, 0x00, 0x6c, 0x00, 0xb8, 0xb8,
+ 0xae, 0xc1, 0x00, 0x82, 0x00, 0xb0, 0xb6, 0xae, 0xc2, 0x00, 0x89 },
+   { 0xf9, 0x00, 0x9a, 0xba, 0xb1, 0xc4, 0x00, 0x6f, 0x00, 0xb8, 0xb8,
+ 0xad, 0xc0, 0x00, 0x86, 0x00, 0xb0, 0xb7, 0xad, 0xc0, 0x00, 0x8d },
+   { 0xf9, 0x00, 0x9c, 0xb9, 0xb0, 0xc4, 0x00, 0x72, 0x00, 0xb8, 0xb8,
+ 0xac, 0xbf, 0x00, 0x8a, 0x00, 0xb0, 0xb6, 0xac, 0xc0, 0x00, 0x91 },
+   { 0xf9, 0x00, 0x9e, 0xba, 0xb0, 0xc2, 0x00, 0x75, 0x00, 0xb9, 0xb8,
+ 0xab, 0xbe, 0x00, 0x8e, 0x00, 0xb0, 0xb6, 0xac, 0xbf, 0x00, 0x9

[PATCH] drm/nouveau: fail runtime pm properly.

[Alex Deucher]

On Wed, Mar 26, 2014 at 12:09 AM, Dave Airlie  wrote:
> From: Dave Airlie 
>
> If we were on a non-optimus device, we'd return -EINVAL, this would
> lead to the over engineered runtime pm system to go into an error
> state, subsequent get_sync's would fail, so we'd never be able
> to open the device again.
>
> (like really get_sync shouldn't fail if the device isn't powered
> down).

Any chance you'd want to spin similar patches for radeon?

Reviewed-by: Alex Deucher 

>
> Signed-off-by: Dave Airlie 
> ---
>  drivers/gpu/drm/nouveau/nouveau_drm.c | 14 ++
>  1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
> b/drivers/gpu/drm/nouveau/nouveau_drm.c
> index 89c484d..4ee702a 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_drm.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
> @@ -866,13 +866,16 @@ static int nouveau_pmops_runtime_suspend(struct device 
> *dev)
> struct drm_device *drm_dev = pci_get_drvdata(pdev);
> int ret;
>
> -   if (nouveau_runtime_pm == 0)
> -   return -EINVAL;
> +   if (nouveau_runtime_pm == 0) {
> +   pm_runtime_forbid(dev);
> +   return -EBUSY;
> +   }
>
> /* are we optimus enabled? */
> if (nouveau_runtime_pm == -1 && !nouveau_is_optimus() && 
> !nouveau_is_v1_dsm()) {
> DRM_DEBUG_DRIVER("failing to power off - not optimus\n");
> -   return -EINVAL;
> +   pm_runtime_forbid(dev);
> +   return -EBUSY;
> }
>
> nv_debug_level(SILENT);
> @@ -923,12 +926,15 @@ static int nouveau_pmops_runtime_idle(struct device 
> *dev)
> struct nouveau_drm *drm = nouveau_drm(drm_dev);
> struct drm_crtc *crtc;
>
> -   if (nouveau_runtime_pm == 0)
> +   if (nouveau_runtime_pm == 0) {
> +   pm_runtime_forbid(dev);
> return -EBUSY;
> +   }
>
> /* are we optimus enabled? */
> if (nouveau_runtime_pm == -1 && !nouveau_is_optimus() && 
> !nouveau_is_v1_dsm()) {
> DRM_DEBUG_DRIVER("failing to power off - not optimus\n");
> +   pm_runtime_forbid(dev);
> return -EBUSY;
> }
>
> --
> 1.8.3.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon: clear needs_reset flag if IB test fails

[Alex Deucher]

On Wed, Mar 26, 2014 at 7:04 AM, Christian K?nig
 wrote:
> From: Christian K?nig 
>
> If the IB test fails we don't want to reset the card over
> and over again, just accept that it isn't working.
>
> Signed-off-by: Christian K?nig 
> Cc: stable at vger.kernel.org

You might want to add the link to the bug.  Other than that:

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/radeon/radeon_ring.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_ring.c 
> b/drivers/gpu/drm/radeon/radeon_ring.c
> index 15e44a7..8391fca 100644
> --- a/drivers/gpu/drm/radeon/radeon_ring.c
> +++ b/drivers/gpu/drm/radeon/radeon_ring.c
> @@ -257,6 +257,7 @@ int radeon_ib_ring_tests(struct radeon_device *rdev)
> r = radeon_ib_test(rdev, i, ring);
> if (r) {
> ring->ready = false;
> +   rdev->needs_reset = false;
>
> if (i == RADEON_RING_TYPE_GFX_INDEX) {
> /* oh, oh, that's really bad */
> --
> 1.9.1
>

3.14-rc7 crashes in drm ([PATCH] a crash in mga_driver_irq_uninstall)

[Daniel Vetter]

On Tue, Mar 25, 2014 at 06:42:13PM -0400, Mikulas Patocka wrote:
> 
> 
> On Mon, 24 Mar 2014, Daniel Vetter wrote:
> 
> > >> Like I've said the entire teardown sequence for legacy drm drivers is
> > >> terminally busted, so the only hope we have is to reapply this missing
> > >> duct-tape which made your X crash. But if that itself isn't a regression
> > >> there's no way to fix the current drm/mga driver without a complete
> > >> rewrite as a new-style kernel modesetting driver.
> > >> -Daniel
> > >
> > > If someone understands the locking issues I pointed out above, it could be
> > > easy to fix.
> > 
> > The locking issue isn't your problem, the real issue is that putting a
> > irq_uninstall into core code will break all the new (properly working)
> > drivers. And you can't really fix this in mga itself since the
> > lifetime rules of the register mappings are totally broken. It's a
> > fundamental misdesign of the legacy drm driver architecture and the
> > _only_ way to fix this bug for real is to rewrite this all. Which was
> > done for all the still used drivers like i915, radeon, nouveau, ...
> > -Daniel
> 
> When I tried Radeon AGP card with the KMS driver, it lacked the 
> possibility to set video mode with fbset and the framebuffer console was 
> very slow because it wasn't accelerated.
> 
> So, Radeon with the new driver is much less useable than Matrox.
> 
> Did I misconfigure something? Or, is console acceleration and modesetting 
> deliberately unsupported in KMS drivers?

You've missed nothing and the performances is abmysal intentionally. It
could be fixed (we've had patches for i915 to accelarate the performance)
but not worth it - fbdev emulation is just here for backwards compat.

If you want fast console on kms drivers you need to look at David
Herrmann's kmscon. That uses GL drivers on top of egl+gbm+kms and that
will be fast. The long-term plan is to switch to that and have a very
minimal shim in the kernel on top of kms as an emergency logging console
only (i.e. even less than the current fbdev stuff).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

exynos-drm HDMI PHY configuration values

[Sean Paul]

On Tue, Mar 25, 2014 at 2:52 PM, Daniel Drake  wrote:
> Hi Sean,
>
> In your commit "drm/exynos: hdmi: support extra resolutions using
> drm_display_mode timings"  you added several more HDMI PHY configs to
> exynos-drm. Thanks for that.
>
> Can you explain where these magic numbers came from?
>

Hi Daniel,
They come from Samsung. Unfortunately, I don't have any insight into
how they are generated.

Sean

> I'm interested in adding 85.5MHz for 1366x768 support.
>
> Thanks,
> Daniel

[Bug 22312] radeon 0000:01:00.0: Invalid ROM contents

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

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

--- Comment #10 from Alex Deucher  ---
If you are running a 3.13 or newer kernel, try appending radeon.runpm=0 to the
kernel command line in grub.

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

[Bug 22312] radeon 0000:01:00.0: Invalid ROM contents

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

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

--- Comment #9 from Alex Deucher  ---
(In reply to Chris Nystrom from comment #8)
> Yes. I am having this exact error message with a live Fedora 20 DVD on a
> Dell OptiPlex 780 with a PCIe ASUS Radeon R7 240 video card. The desktop
> never comes up.

Please attach your dmesg output.

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