[RFC PATCH 00/11] Introduce writeback connectors

[Brian Starkey]

On Tue, Oct 11, 2016 at 10:02:43PM +0200, Daniel Vetter wrote:
>On Tue, Oct 11, 2016 at 9:44 PM, Brian Starkey  
>wrote:
>> Hi,
>>
>>
>> On Tue, Oct 11, 2016 at 07:01:33PM +0200, Daniel Vetter wrote:
>>>
>>> On Tue, Oct 11, 2016 at 6:43 PM, Brian Starkey 
>>> wrote:

 Hi Daniel,

 Firstly thanks very much for having a look.


 On Tue, Oct 11, 2016 at 05:43:59PM +0200, Daniel Vetter wrote:
>
>
> On Tue, Oct 11, 2016 at 03:53:57PM +0100, Brian Starkey wrote:
>>
>>
>> Hi,
>>
>> This RFC series introduces a new connector type:
>>  DRM_MODE_CONNECTOR_WRITEBACK
>> It is a follow-on from a previous discussion: [1]
>>
>> Writeback connectors are used to expose the memory writeback engines
>> found in some display controllers, which can write a CRTC's
>> composition result to a memory buffer.
>> This is useful e.g. for testing, screen-recording, screenshots,
>> wireless display, display cloning, memory-to-memory composition.
>>
>> Patches 1-7 include the core framework changes required, and patches
>> 8-11 implement a writeback connector for the Mali-DP writeback engine.
>> The Mali-DP patches depend on this other series: [2].
>>
>> The connector is given the FB_ID property for the output framebuffer,
>> and two new read-only properties: PIXEL_FORMATS and
>> PIXEL_FORMATS_SIZE, which expose the supported framebuffer pixel
>> formats of the engine.
>>
>> The EDID property is not exposed for writeback connectors.
>>
>> Writeback connector usage:
>> --
>> Due to connector routing changes being treated as "full modeset"
>> operations, any client which wishes to use a writeback connector
>> should include the connector in every modeset. The writeback will not
>> actually become active until a framebuffer is attached.
>
>
>
> Erhm, this is just the default, drivers can override this. And we could
> change the atomic helpers to not mark a modeset as a modeset if the
> connector that changed is a writeback one.
>

 Hmm, maybe. I don't think it's ideal - the driver would need to
 re-implement drm_atomic_helper_check_modeset, which is quite a chunk
 of code (along with exposing update_connector_routing, mode_fixup,
 maybe others), and even after that it would have to lie and set
 crtc_state->connectors_changed to false so that
 drm_crtc_needs_modeset returns false to drm_atomic_check_only.
>>>
>>>
>>> You only need to update the property in your encoders's ->atomic_check
>>> function. No need for more, and I think being consistent with
>>> computing when you need a modeset is really a crucial part of the
>>> atomic ioctl that we should imo try to implement correctly as much as
>>> possible.
>>>
>>
>> Sorry I really don't follow. Which property? CRTC_ID?
>>
>> Userspace changing CRTC_ID will change connector_state->crtc (before
>> we even get to a driver callback).
>>
>> After that, drm_atomic_helper_check_modeset derives connectors_changed
>> based on the ->crtc pointers.
>>
>> After that, my encoder ->atomic_check *could* clear
>> connectors_changed (or I could achieve the same thing by wrapping
>> drm_atomic_helper_check), but it seems wrong to do so, considering
>> that the connector routing *has* changed.
>>
>> If you think changing CRTC_ID shouldn't require a full modeset, I'd
>> rather give drivers a ->needs_modeset callback to override the default
>> drm_atomic_crtc_needs_modeset behaviour, instead of "tricking" it into
>> returning false.
>
>The problem with just that is that there's lots of different things
>that can feed into the overall needs_modeset variable. That's why we
>split it up into multiple booleans.
>
>So yes you're supposed to clear connectors_changed if there is some
>change that you can handle without a full modeset. If you want, think
>of connectors_changed as
>needs_modeset_due_to_change_in_connnector_state, but that's cumbersome
>to type and too long ;-)
>

All right, got it :-). This intention wasn't clear to me from the
comments in the code.

>> I can imagine some hardware will need a full modeset to changed the
>> writeback CRTC binding anyway.
>
>Yup, and then they can upgrade this again. With all these flow-control
>booleans the idea is very much that helpers give a default that works
>for 90% of all cases, and driver callbacks can then change it for the
>other 10%.
>
 I tried to keep special-casing of writeback connectors in the 
 core to
 a bare minimum, because I think it will quickly get messy and fragile
 otherwise.
>>>
>>>
>>> Please always make the disdinction between core and shared drm
>>> helpers. Special cases in core == probably not good. Special cases in
>>> helpers == perfectly fine imo.
>>>
 Honestly, I don't see modesetting the writeback connectors at
 start-of-day as a big problem.
>>>
>>>
>>> It's inconsistent. 

[RFC PATCH 00/11] Introduce writeback connectors

[Daniel Vetter]

On Tue, Oct 11, 2016 at 9:44 PM, Brian Starkey  wrote:
> Hi,
>
>
> On Tue, Oct 11, 2016 at 07:01:33PM +0200, Daniel Vetter wrote:
>>
>> On Tue, Oct 11, 2016 at 6:43 PM, Brian Starkey 
>> wrote:
>>>
>>> Hi Daniel,
>>>
>>> Firstly thanks very much for having a look.
>>>
>>>
>>> On Tue, Oct 11, 2016 at 05:43:59PM +0200, Daniel Vetter wrote:


 On Tue, Oct 11, 2016 at 03:53:57PM +0100, Brian Starkey wrote:
>
>
> Hi,
>
> This RFC series introduces a new connector type:
>  DRM_MODE_CONNECTOR_WRITEBACK
> It is a follow-on from a previous discussion: [1]
>
> Writeback connectors are used to expose the memory writeback engines
> found in some display controllers, which can write a CRTC's
> composition result to a memory buffer.
> This is useful e.g. for testing, screen-recording, screenshots,
> wireless display, display cloning, memory-to-memory composition.
>
> Patches 1-7 include the core framework changes required, and patches
> 8-11 implement a writeback connector for the Mali-DP writeback engine.
> The Mali-DP patches depend on this other series: [2].
>
> The connector is given the FB_ID property for the output framebuffer,
> and two new read-only properties: PIXEL_FORMATS and
> PIXEL_FORMATS_SIZE, which expose the supported framebuffer pixel
> formats of the engine.
>
> The EDID property is not exposed for writeback connectors.
>
> Writeback connector usage:
> --
> Due to connector routing changes being treated as "full modeset"
> operations, any client which wishes to use a writeback connector
> should include the connector in every modeset. The writeback will not
> actually become active until a framebuffer is attached.



 Erhm, this is just the default, drivers can override this. And we could
 change the atomic helpers to not mark a modeset as a modeset if the
 connector that changed is a writeback one.

>>>
>>> Hmm, maybe. I don't think it's ideal - the driver would need to
>>> re-implement drm_atomic_helper_check_modeset, which is quite a chunk
>>> of code (along with exposing update_connector_routing, mode_fixup,
>>> maybe others), and even after that it would have to lie and set
>>> crtc_state->connectors_changed to false so that
>>> drm_crtc_needs_modeset returns false to drm_atomic_check_only.
>>
>>
>> You only need to update the property in your encoders's ->atomic_check
>> function. No need for more, and I think being consistent with
>> computing when you need a modeset is really a crucial part of the
>> atomic ioctl that we should imo try to implement correctly as much as
>> possible.
>>
>
> Sorry I really don't follow. Which property? CRTC_ID?
>
> Userspace changing CRTC_ID will change connector_state->crtc (before
> we even get to a driver callback).
>
> After that, drm_atomic_helper_check_modeset derives connectors_changed
> based on the ->crtc pointers.
>
> After that, my encoder ->atomic_check *could* clear
> connectors_changed (or I could achieve the same thing by wrapping
> drm_atomic_helper_check), but it seems wrong to do so, considering
> that the connector routing *has* changed.
>
> If you think changing CRTC_ID shouldn't require a full modeset, I'd
> rather give drivers a ->needs_modeset callback to override the default
> drm_atomic_crtc_needs_modeset behaviour, instead of "tricking" it into
> returning false.

The problem with just that is that there's lots of different things
that can feed into the overall needs_modeset variable. That's why we
split it up into multiple booleans.

So yes you're supposed to clear connectors_changed if there is some
change that you can handle without a full modeset. If you want, think
of connectors_changed as
needs_modeset_due_to_change_in_connnector_state, but that's cumbersome
to type and too long ;-)

> I can imagine some hardware will need a full modeset to changed the
> writeback CRTC binding anyway.

Yup, and then they can upgrade this again. With all these flow-control
booleans the idea is very much that helpers give a default that works
for 90% of all cases, and driver callbacks can then change it for the
other 10%.

>>> I tried to keep special-casing of writeback connectors in the core to
>>> a bare minimum, because I think it will quickly get messy and fragile
>>> otherwise.
>>
>>
>> Please always make the disdinction between core and shared drm
>> helpers. Special cases in core == probably not good. Special cases in
>> helpers == perfectly fine imo.
>>
>>> Honestly, I don't see modesetting the writeback connectors at
>>> start-of-day as a big problem.
>>
>>
>> It's inconsistent. Claiming it needs a modeset when it doesn't isn't
>> great. Making that more discoverable to userspace is the entire point
>> of atomic. And there might be hw where reconfiguring for writeback
>> might need a full modeset.
>>
>
> I'm a little confused - what bit exactly is 

[RFC 0/6] Module for tracking/accounting shared memory buffers

[Rob Clark]

On Tue, Oct 11, 2016 at 7:50 PM, Ruchi Kandoi  wrote:
> This patchstack introduces a new "memtrack" module for tracking and accounting
> memory exported to userspace as shared buffers, like dma-buf fds or GEM 
> handles.

btw, I wouldn't care much about the non-dmabuf case.. dri2/flink is
kind of legacy and the sharing patterns there are not so complex that
we have found the need for any more elaborate debug infrastructure
than what we already have.

Between existing dmabuf debugfs, and /proc/*/maps (and /proc/*/fd?), I
wonder what is missing?  Maybe there is a less intrusive way to get at
the debugging info you want?

BR,
-R

> Any process holding a reference to these buffers will keep the kernel from
> reclaiming its backing pages.  mm counters don't provide a complete picture of
> these allocations, since they only account for pages that are mapped into a
> process's address space.  This problem is especially bad for systems like
> Android that use dma-buf fds to share graphics and multimedia buffers between
> processes: these allocations are often large, have complex sharing patterns,
> and are rarely mapped into every process that holds a reference to them.
>
> memtrack maintains a per-process list of shared buffer references, which is
> exported to userspace as /proc/[pid]/memtrack.  Buffers can be optionally
> "tagged" with a short string: for example, Android userspace would use this
> tag to identify whether buffers were allocated on behalf of the camera stack,
> GL, etc.  memtrack also exports the VMAs associated with these buffers so
> that pages already included in the process's mm counters aren't 
> double-counted.
>
> Shared-buffer allocators can hook into memtrack by embedding
> struct memtrack_buffer in their buffer metadata, calling
> memtrack_buffer_{init,remove} at buffer allocation and free time, and
> memtrack_buffer_{install,uninstall} when a userspace process takes or
> drops a reference to the buffer.  For fd-backed buffers like dma-bufs, hooks 
> in
> fdtable.c and fork.c automatically notify memtrack when references are added 
> or
> removed from a process's fd table.
>
> This patchstack adds memtrack hooks into dma-buf and ion.  If there's upstream
> interest in memtrack, it can be extended to other memory allocators as well,
> such as GEM implementations.
>
> Greg Hackmann (1):
>   drivers: staging: ion: add ION_IOC_TAG ioctl
>
> Ruchi Kandoi (5):
>   fs: add installed and uninstalled file_operations
>   drivers: misc: add memtrack
>   dma-buf: add memtrack support
>   memtrack: Adds the accounting to keep track of all mmaped/unmapped
> pages.
>   memtrack: Add memtrack accounting for forked processes.
>
>  drivers/android/binder.c|   4 +-
>  drivers/dma-buf/dma-buf.c   |  37 +++
>  drivers/misc/Kconfig|  16 +
>  drivers/misc/Makefile   |   1 +
>  drivers/misc/memtrack.c | 516 
> 
>  drivers/staging/android/ion/ion-ioctl.c |  17 ++
>  drivers/staging/android/ion/ion.c   |  60 +++-
>  drivers/staging/android/ion/ion_priv.h  |   2 +
>  drivers/staging/android/uapi/ion.h  |  25 ++
>  fs/file.c   |  38 ++-
>  fs/open.c   |   2 +-
>  fs/proc/base.c  |   4 +
>  include/linux/dma-buf.h |   5 +
>  include/linux/fdtable.h |   4 +-
>  include/linux/fs.h  |   2 +
>  include/linux/memtrack.h| 130 
>  include/linux/mm.h  |   3 +
>  include/linux/sched.h   |   3 +
>  kernel/fork.c   |  23 +-
>  19 files changed, 875 insertions(+), 17 deletions(-)
>  create mode 100644 drivers/misc/memtrack.c
>  create mode 100644 include/linux/memtrack.h
>
> --
> 2.8.0.rc3.226.g39d4020
>

[RFC PATCH 00/11] Introduce writeback connectors

[Brian Starkey]

Hi,

On Tue, Oct 11, 2016 at 07:01:33PM +0200, Daniel Vetter wrote:
>On Tue, Oct 11, 2016 at 6:43 PM, Brian Starkey  
>wrote:
>> Hi Daniel,
>>
>> Firstly thanks very much for having a look.
>>
>>
>> On Tue, Oct 11, 2016 at 05:43:59PM +0200, Daniel Vetter wrote:
>>>
>>> On Tue, Oct 11, 2016 at 03:53:57PM +0100, Brian Starkey wrote:

 Hi,

 This RFC series introduces a new connector type:
  DRM_MODE_CONNECTOR_WRITEBACK
 It is a follow-on from a previous discussion: [1]

 Writeback connectors are used to expose the memory writeback engines
 found in some display controllers, which can write a CRTC's
 composition result to a memory buffer.
 This is useful e.g. for testing, screen-recording, screenshots,
 wireless display, display cloning, memory-to-memory composition.

 Patches 1-7 include the core framework changes required, and patches
 8-11 implement a writeback connector for the Mali-DP writeback engine.
 The Mali-DP patches depend on this other series: [2].

 The connector is given the FB_ID property for the output framebuffer,
 and two new read-only properties: PIXEL_FORMATS and
 PIXEL_FORMATS_SIZE, which expose the supported framebuffer pixel
 formats of the engine.

 The EDID property is not exposed for writeback connectors.

 Writeback connector usage:
 --
 Due to connector routing changes being treated as "full modeset"
 operations, any client which wishes to use a writeback connector
 should include the connector in every modeset. The writeback will not
 actually become active until a framebuffer is attached.
>>>
>>>
>>> Erhm, this is just the default, drivers can override this. And we could
>>> change the atomic helpers to not mark a modeset as a modeset if the
>>> connector that changed is a writeback one.
>>>
>>
>> Hmm, maybe. I don't think it's ideal - the driver would need to
>> re-implement drm_atomic_helper_check_modeset, which is quite a chunk
>> of code (along with exposing update_connector_routing, mode_fixup,
>> maybe others), and even after that it would have to lie and set
>> crtc_state->connectors_changed to false so that
>> drm_crtc_needs_modeset returns false to drm_atomic_check_only.
>
>You only need to update the property in your encoders's ->atomic_check
>function. No need for more, and I think being consistent with
>computing when you need a modeset is really a crucial part of the
>atomic ioctl that we should imo try to implement correctly as much as
>possible.
>

Sorry I really don't follow. Which property? CRTC_ID?

Userspace changing CRTC_ID will change connector_state->crtc (before
we even get to a driver callback).

After that, drm_atomic_helper_check_modeset derives connectors_changed
based on the ->crtc pointers.

After that, my encoder ->atomic_check *could* clear
connectors_changed (or I could achieve the same thing by wrapping
drm_atomic_helper_check), but it seems wrong to do so, considering
that the connector routing *has* changed.

If you think changing CRTC_ID shouldn't require a full modeset, I'd
rather give drivers a ->needs_modeset callback to override the default
drm_atomic_crtc_needs_modeset behaviour, instead of "tricking" it into
returning false.

I can imagine some hardware will need a full modeset to changed the
writeback CRTC binding anyway.

>> I tried to keep special-casing of writeback connectors in the core 
>> to
>> a bare minimum, because I think it will quickly get messy and fragile
>> otherwise.
>
>Please always make the disdinction between core and shared drm
>helpers. Special cases in core == probably not good. Special cases in
>helpers == perfectly fine imo.
>
>> Honestly, I don't see modesetting the writeback connectors at
>> start-of-day as a big problem.
>
>It's inconsistent. Claiming it needs a modeset when it doesn't isn't
>great. Making that more discoverable to userspace is the entire point
>of atomic. And there might be hw where reconfiguring for writeback
>might need a full modeset.
>

I'm a little confused - what bit exactly is inconsistent?

My implementation here is consistent with other connectors.
Updating the writeback connector CRTC_ID property requires a full
modeset, the same as other connectors.

Changing the FB_ID does *not* require a full modeset, because our
hardware has no such restriction. This is analogous to updating the
FB_ID on our planes, and is consistent with the other instances of the
FB_ID property.

If there is hardware which does have a restriction on changing FB_ID, 
I think that driver must be responsible for handling it in the same
way as drivers which can't handle plane updates without a full
modeset.

Are you saying that because setting CRTC_ID on Mali-DP is a no-op, it
shouldn't require a full modeset? I'd rather somehow hard-code the
CRTC_ID for our writeback connector to have it always attached to
the CRTC in that case.

 The writeback itself is enabled by 

[Bug 60879] [radeonsi] Tahiti LE: GFX block is not functional, CP is okay

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

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

--- Comment #157 from madmalkav  ---
Created attachment 127226
  --> https://bugs.freedesktop.org/attachment.cgi?id=127226=edit
Xorg log with lastest 4.9-wip kernel and mesa master branch

I've tried agd5f's 4.9 wip beanch with latest Mesa. Wflinfo fails with an
"amdgpu: unkown family" error, no Gallium dump log, error on dmesg:

[  353.579289] wflinfo[1529]: segfault at 8 ip 7f8260c8dd6a sp
7ffe2f8d74f0 error 4 in radeonsi_dri.so[7f8260912000+8fc000]

If I try to start X, similar errors appears.

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

[REGRESSION v4.7] i915 / drm crash when undocking from DP monitors

[Vadim Lobanov]

Certainly, done and done. The bug is filed at:
https://bugs.freedesktop.org/show_bug.cgi?id=98211

Thanks!

On Tue, Oct 11, 2016 at 6:55 AM, Jani Nikula
 wrote:
> On Sat, 08 Oct 2016, Vadim Lobanov  wrote:
>> I'm seeing a repeatable crash on my HP EliteBook 840 G2/2216 when
>> booting it while in a docking station connected to two external
>> DisplayPort monitors, undocking, and then either logging out or
>> shutting down -- regardless of whether I've redocked it beforehand or
>> not. Both logout and shutdown work great if I do not undock the laptop
>> at all, so the badness correlates with the DP monitors going away.
>
> Please file a bug at [1] with the info in this mail, add drm.debug=14
> module parameter, and attach dmesg from boot to the problem into the
> bug.
>
> BR,
> Jani.
>
> [1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI=DRM/Intel
>
> --
> Jani Nikula, Intel Open Source Technology Center

[RFC PATCH 00/11] Introduce writeback connectors

[Ville Syrjälä]

On Tue, Oct 11, 2016 at 03:53:57PM +0100, Brian Starkey wrote:
> Hi,
> 
> This RFC series introduces a new connector type:
>  DRM_MODE_CONNECTOR_WRITEBACK
> It is a follow-on from a previous discussion: [1]
> 
> Writeback connectors are used to expose the memory writeback engines
> found in some display controllers, which can write a CRTC's
> composition result to a memory buffer.
> This is useful e.g. for testing, screen-recording, screenshots,
> wireless display, display cloning, memory-to-memory composition.
> 
> Patches 1-7 include the core framework changes required, and patches
> 8-11 implement a writeback connector for the Mali-DP writeback engine.
> The Mali-DP patches depend on this other series: [2].
> 
> The connector is given the FB_ID property for the output framebuffer,
> and two new read-only properties: PIXEL_FORMATS and
> PIXEL_FORMATS_SIZE, which expose the supported framebuffer pixel
> formats of the engine.
> 
> The EDID property is not exposed for writeback connectors.
> 
> Writeback connector usage:
> --
> Due to connector routing changes being treated as "full modeset"
> operations, any client which wishes to use a writeback connector
> should include the connector in every modeset. The writeback will not
> actually become active until a framebuffer is attached.
> 
> The writeback itself is enabled by attaching a framebuffer to the
> FB_ID property of the connector. The driver must then ensure that the
> CRTC content of that atomic commit is written into the framebuffer.
> 
> The writeback works in a one-shot mode with each atomic commit. This
> prevents the same content from being written multiple times.
> In some cases (front-buffer rendering) there might be a desire for
> continuous operation - I think a property could be added later for
> this kind of control.

I though people agreed that this sort of thing would go through v4l.
Continously writing to the same buffer isn't perhaps all that sensible
anyway, and so we'd need queueing, which is what v4l has already. Well,
I guess we might add some queueing to atomic eventually?

I guess for front buffer rendering type of thing you might have some
use for a continuous mode targeting a single fb. Though I think
peridically triggering a new write could do as well. Of course either
way would likely tear horribly, and having multiple buffers seems like
the better option.

> 
> Writeback can be disabled by setting FB_ID to zero.
> 
> Known issues:
> -
>  * I'm not sure what "DPMS" should mean for writeback connectors.
>It could be used to disable writeback (even when a framebuffer is
>attached), or it could be hidden entirely (which would break the
>legacy DPMS call for writeback connectors).
>  * With Daniel's recent re-iteration of the userspace API rules, I
>fully expect to provide some userspace code to support this. The
>question is what, and where? We want to use writeback for testing,
>so perhaps some tests in igt is suitable.
>  * Documentation. Probably some portion of this cover letter needs to
>make it into Documentation/
>  * Synchronisation. Our hardware will finish the writeback by the next
>vsync. I've not implemented fence support here, but it would be an
>obvious addition.
> 
> See Also:
> -
> [1] https://lists.freedesktop.org/archives/dri-devel/2016-July/113197.html
> [2] https://lists.freedesktop.org/archives/dri-devel/2016-October/120486.html
> 
> I welcome any comments, especially if this approach does/doesn't fit
> well with anyone else's hardware.
> 
> Thanks,
> 
> -Brian
> 
> ---
> 
> Brian Starkey (10):
>   drm: add writeback connector type
>   drm/fb-helper: skip writeback connectors
>   drm: extract CRTC/plane disable from drm_framebuffer_remove
>   drm: add __drm_framebuffer_remove_atomic
>   drm: add fb to connector state
>   drm: expose fb_id property for writeback connectors
>   drm: add writeback-connector pixel format properties
>   drm: mali-dp: rename malidp_input_format
>   drm: mali-dp: add RGB writeback formats for DP550/DP650
>   drm: mali-dp: add writeback connector
> 
> Liviu Dudau (1):
>   drm: mali-dp: Add support for writeback on DP550/DP650
> 
>  drivers/gpu/drm/arm/Makefile|1 +
>  drivers/gpu/drm/arm/malidp_crtc.c   |   10 ++
>  drivers/gpu/drm/arm/malidp_drv.c|   25 +++-
>  drivers/gpu/drm/arm/malidp_drv.h|5 +
>  drivers/gpu/drm/arm/malidp_hw.c |  104 ++
>  drivers/gpu/drm/arm/malidp_hw.h |   27 +++-
>  drivers/gpu/drm/arm/malidp_mw.c |  268 
> +++
>  drivers/gpu/drm/arm/malidp_planes.c |8 +-
>  drivers/gpu/drm/arm/malidp_regs.h   |   15 ++
>  drivers/gpu/drm/drm_atomic.c|   40 ++
>  drivers/gpu/drm/drm_atomic_helper.c |4 +
>  drivers/gpu/drm/drm_connector.c |   79 ++-
>  drivers/gpu/drm/drm_crtc.c  |   14 +-
>  drivers/gpu/drm/drm_fb_helper.c |4 +
>  drivers/gpu/drm/drm_framebuffer.c   

[RFC PATCH 00/11] Introduce writeback connectors

[Daniel Vetter]

On Tue, Oct 11, 2016 at 6:43 PM, Brian Starkey  wrote:
> Hi Daniel,
>
> Firstly thanks very much for having a look.
>
>
> On Tue, Oct 11, 2016 at 05:43:59PM +0200, Daniel Vetter wrote:
>>
>> On Tue, Oct 11, 2016 at 03:53:57PM +0100, Brian Starkey wrote:
>>>
>>> Hi,
>>>
>>> This RFC series introduces a new connector type:
>>>  DRM_MODE_CONNECTOR_WRITEBACK
>>> It is a follow-on from a previous discussion: [1]
>>>
>>> Writeback connectors are used to expose the memory writeback engines
>>> found in some display controllers, which can write a CRTC's
>>> composition result to a memory buffer.
>>> This is useful e.g. for testing, screen-recording, screenshots,
>>> wireless display, display cloning, memory-to-memory composition.
>>>
>>> Patches 1-7 include the core framework changes required, and patches
>>> 8-11 implement a writeback connector for the Mali-DP writeback engine.
>>> The Mali-DP patches depend on this other series: [2].
>>>
>>> The connector is given the FB_ID property for the output framebuffer,
>>> and two new read-only properties: PIXEL_FORMATS and
>>> PIXEL_FORMATS_SIZE, which expose the supported framebuffer pixel
>>> formats of the engine.
>>>
>>> The EDID property is not exposed for writeback connectors.
>>>
>>> Writeback connector usage:
>>> --
>>> Due to connector routing changes being treated as "full modeset"
>>> operations, any client which wishes to use a writeback connector
>>> should include the connector in every modeset. The writeback will not
>>> actually become active until a framebuffer is attached.
>>
>>
>> Erhm, this is just the default, drivers can override this. And we could
>> change the atomic helpers to not mark a modeset as a modeset if the
>> connector that changed is a writeback one.
>>
>
> Hmm, maybe. I don't think it's ideal - the driver would need to
> re-implement drm_atomic_helper_check_modeset, which is quite a chunk
> of code (along with exposing update_connector_routing, mode_fixup,
> maybe others), and even after that it would have to lie and set
> crtc_state->connectors_changed to false so that
> drm_crtc_needs_modeset returns false to drm_atomic_check_only.

You only need to update the property in your encoders's ->atomic_check
function. No need for more, and I think being consistent with
computing when you need a modeset is really a crucial part of the
atomic ioctl that we should imo try to implement correctly as much as
possible.

> I tried to keep special-casing of writeback connectors in the core to
> a bare minimum, because I think it will quickly get messy and fragile
> otherwise.

Please always make the disdinction between core and shared drm
helpers. Special cases in core == probably not good. Special cases in
helpers == perfectly fine imo.

> Honestly, I don't see modesetting the writeback connectors at
> start-of-day as a big problem.

It's inconsistent. Claiming it needs a modeset when it doesn't isn't
great. Making that more discoverable to userspace is the entire point
of atomic. And there might be hw where reconfiguring for writeback
might need a full modeset.

>>> The writeback itself is enabled by attaching a framebuffer to the
>>> FB_ID property of the connector. The driver must then ensure that the
>>> CRTC content of that atomic commit is written into the framebuffer.
>>>
>>> The writeback works in a one-shot mode with each atomic commit. This
>>> prevents the same content from being written multiple times.
>>> In some cases (front-buffer rendering) there might be a desire for
>>> continuous operation - I think a property could be added later for
>>> this kind of control.
>>>
>>> Writeback can be disabled by setting FB_ID to zero.
>>
>>
>> This seems to contradict itself: If it's one-shot, there's no need to
>> disable it - it will auto-disable.
>
>
> I should have explained one-shot more clearly. What I mean is, one
> drmModeAtomicCommit == one write to memory. This is as opposed to
> writing the same thing to memory every vsync until it is stopped
> (which our HW is capable of doing).
>
> A subsequent drmModeAtomicCommit which doesn't touch the writeback FB_ID
> will write (again - but with whatever scene updates) to the same
> framebuffer.
>
> This continues for every drmModeAtomicCommit until FB_ID is set to
> zero - to disable writing - or changed to a different framebuffer, in
> which case we write to the new one.
>
> IMO this behaviour makes sense in the context of the rest of Atomic,
> and as the FB_ID is indeed persistent across atomic commits, I think
> it should be read-able.

tbh I don't like that, I think it'd be better to make this truly
one-shot. Otherwise we'll have real fun problems with hw where the
writeback can take longer than a vblank (it happens ...). So one-shot,
with auto-clearing to NULL/0 is imo the right approach.

>> In other cases where we write a property as a one-shot thing (fences for
>> android). In that case when you read that property it's always 0 (well, -1
>> for fences since 

[RFC PATCH 02/11] drm/fb-helper: Skip writeback connectors

[Daniel Vetter]

On Tue, Oct 11, 2016 at 6:47 PM, Brian Starkey  wrote:
> On Tue, Oct 11, 2016 at 05:44:48PM +0200, Daniel Vetter wrote:
>>
>> On Tue, Oct 11, 2016 at 03:53:59PM +0100, Brian Starkey wrote:
>>>
>>> Writeback connectors aren't much use to the fbdev helpers, as they won't
>>> show anything to the user. Skip them when looking for candidate output
>>> configurations.
>>>
>>> Signed-off-by: Brian Starkey 
>>> ---
>>>  drivers/gpu/drm/drm_fb_helper.c |4 
>>>  1 file changed, 4 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/drm_fb_helper.c
>>> b/drivers/gpu/drm/drm_fb_helper.c
>>> index 03414bd..dedf6e7 100644
>>> --- a/drivers/gpu/drm/drm_fb_helper.c
>>> +++ b/drivers/gpu/drm/drm_fb_helper.c
>>> @@ -2016,6 +2016,10 @@ static int drm_pick_crtcs(struct drm_fb_helper
>>> *fb_helper,
>>> if (modes[n] == NULL)
>>> return best_score;
>>>
>>> +   /* Writeback connectors aren't much use for fbdev */
>>> +   if (connector->connector_type == DRM_MODE_CONNECTOR_WRITEBACK)
>>> +   return best_score;
>>
>>
>> I think we could handle this by always marking writeback connectors as
>> disconnected. Userspace and fbdev emulation should then avoid them,
>> always.
>> -Daniel
>>
>
> Good idea; I'll need to take a closer look at how it would interact
> with the probe helper (connector->force etc).
>
> Are you thinking instead-of or in-addition-to the client cap? I'd be
> worried about apps doing strange things and trying to use even
> disconnected connectors.

Apps shouldn't try to use disconnected connectors, at least by
default. I think we wouldn't need the cap in that case.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[RFC PATCH 00/11] Introduce writeback connectors

[Daniel Vetter]

On Tue, Oct 11, 2016 at 6:25 PM, Ville Syrjälä
 wrote:
>> Writeback connector usage:
>> --
>> Due to connector routing changes being treated as "full modeset"
>> operations, any client which wishes to use a writeback connector
>> should include the connector in every modeset. The writeback will not
>> actually become active until a framebuffer is attached.
>>
>> The writeback itself is enabled by attaching a framebuffer to the
>> FB_ID property of the connector. The driver must then ensure that the
>> CRTC content of that atomic commit is written into the framebuffer.
>>
>> The writeback works in a one-shot mode with each atomic commit. This
>> prevents the same content from being written multiple times.
>> In some cases (front-buffer rendering) there might be a desire for
>> continuous operation - I think a property could be added later for
>> this kind of control.
>
> I though people agreed that this sort of thing would go through v4l.
> Continously writing to the same buffer isn't perhaps all that sensible
> anyway, and so we'd need queueing, which is what v4l has already. Well,
> I guess we might add some queueing to atomic eventually?
>
> I guess for front buffer rendering type of thing you might have some
> use for a continuous mode targeting a single fb. Though I think
> peridically triggering a new write could do as well. Of course either
> way would likely tear horribly, and having multiple buffers seems like
> the better option

Yeah, momentarily entirely forgot about v4l. I think making FB_ID
one-shot (perhaps better to call it WRITEBACK_FB_ID to avoid
confusion) is the right thing to do, and then push everything
continuous to some form of drm/v4l integration.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[git pull] drm pull for v4.9

[Linus Torvalds]

On Tue, Oct 11, 2016 at 2:14 PM, Dave Airlie  wrote:
>
> this email is all in small letters because my gpg key expired so I couldn't
> sign the tag, and it's too early in the morning for me to go do gpg stuff.

I'm happy that you have found alternative identity management model,
but I'm not sure this "all lower key" thing is considered a
technically valid alternative to pgp signing from an identity
validation standpoint.

I will have to ask around the security people to see what they think.

But hopefully your pgp-fu makes a comeback, making this all a
non-issue for the next pull request.

  Linus

[Bug 98200] [radeon] kernel hangs during shutdown - drm-next-4.9-/+wip

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

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

Arek Ruśniak  changed:

   What|Removed |Added

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

--- Comment #4 from Arek Ruśniak  ---
Thanks,restart/shutdown works again.
It has dropped into 4.9-wip so I close it.

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

[Intel-gfx] [PATCH v5 06/11] drm/i915: Enable i915 perf stream for Haswell OA unit

[Robert Bragg]

_check_timer_cb;
> > +   init_waitqueue_head(_priv->perf.oa.poll_wq);
> > +
> > INIT_LIST_HEAD(_priv->perf.streams);
> > mutex_init(_priv->perf.lock);
> > +   spin_lock_init(_priv->perf.hook_lock);
> > +
> > +   dev_priv->perf.oa.ops.init_oa_buffer = gen7_init_oa_buffer;
> > +   dev_priv->perf.oa.ops.enable_metric_set = hsw_enable_metric_set;
> > +   dev_priv->perf.oa.ops.disable_metric_set =
> hsw_disable_metric_set;
> > +   dev_priv->perf.oa.ops.oa_enable = gen7_oa_enable;
> > +   dev_priv->perf.oa.ops.oa_disable = gen7_oa_disable;
> > +   dev_priv->perf.oa.ops.update_hw_ctx_id_locked =
> > +   gen7_update_hw_ctx_id_locked;
> > +   dev_priv->perf.oa.ops.read = gen7_oa_read;
> > +   dev_priv->perf.oa.ops.oa_buffer_is_empty =
> > +   gen7_oa_buffer_is_empty_fop_unlocked;
> > +
> > +   dev_priv->perf.oa.timestamp_frequency = 1250;
> Slightly magical.
>

Not sure how to dymistify this with a comment; it pretty much is just a
magic hardware constant detailing the fixed frequency of the HW timestamp
counter. I think it's likely not actually specified in the PRMs for < gen 9
considering that I think for all gens prior to SKL the frequency has
remained the same.

Other software that currently deals with these raw HW timestamps (such as
Mesa) actually work in terms of an integer multiplier (80) when scaling HW
timestamps to have nanosecond units, and you can derive the frequency from
that. Maybe the scalar of 80 is noted in the PRMs somewhere instead of a
frequency.

Awkwardly once we get to Skylake an integer multiple no longer works, so
it's preferable to track the platform differences in terms of a frequency
like this.

I'll consider noting some of this in a comment.


> > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > index 7a74750..22d5ff1 100644
> > --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > @@ -2043,8 +2043,14 @@ static int intel_ring_context_pin(struct
> i915_gem_context *ctx,
> > if (ret)
> > goto error;
> >
> > -   ret = i915_vma_pin(ce->state, 0, ctx->ggtt_alignment,
> > -  PIN_GLOBAL | PIN_HIGH);
> > +   if (engine->id == RCS) {
> > +   u64 vma_flags = PIN_GLOBAL | PIN_HIGH;
> Maybe move this up a level and reuse for both paths.
>

Ah yep,

>
> > +   ret = i915_gem_context_pin_legacy_
> rcs_state(engine->i915,
> > +   ctx,
> > +
>  vma_flags);
> > +   } else
> > +   ret = i915_vma_pin(ce->state, 0,
> ctx->ggtt_alignment,
> > +  PIN_GLOBAL | PIN_HIGH);
> > if (ret)
> > goto error;
> > }
>



I'm travelling this week, but will send out an updated patch when I've had
a chance to test the change for initializing the specific_ctx_id on haswell.

thanks for the feedback.

Regards,
- Robert
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161011/d862e742/attachment-0001.html>

[RFC PATCH 04/11] drm: Add __drm_framebuffer_remove_atomic

[Daniel Vetter]

On Tue, Oct 11, 2016 at 03:54:01PM +0100, Brian Starkey wrote:
> Implement the CRTC/Plane disable functionality of drm_framebuffer_remove
> using the atomic API, and use it if possible.
> 
> For atomic drivers, this removes the possibility of several commits when
> a framebuffer is in use by more than one CRTC/plane.
> 
> Additionally, this will provide a suitable place to support the removal
> of a framebuffer from a writeback connector, in the case that a
> writeback connector is still actively using a framebuffer when it is
> removed by userspace.
> 
> Signed-off-by: Brian Starkey 

Just the small comment here: Last time around I wanted toland an atomic
disable function for fb remove code it blew up. Need to check out git
history to make sure we've addressed those isses.  Caveat emperor ;-)
-Daniel

> ---
>  drivers/gpu/drm/drm_framebuffer.c |  154 
> -
>  1 file changed, 152 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_framebuffer.c 
> b/drivers/gpu/drm/drm_framebuffer.c
> index 528f75d..b02cf73 100644
> --- a/drivers/gpu/drm/drm_framebuffer.c
> +++ b/drivers/gpu/drm/drm_framebuffer.c
> @@ -22,6 +22,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -795,6 +796,148 @@ void drm_framebuffer_cleanup(struct drm_framebuffer *fb)
>  EXPORT_SYMBOL(drm_framebuffer_cleanup);
>  
>  /**
> + * __drm_framebuffer_remove_atomic - atomic version of 
> __drm_framebuffer_remove
> + * @dev: drm device
> + * @fb: framebuffer to remove
> + *
> + * If the driver implements the atomic API, we can handle the disabling of 
> all
> + * CRTCs/planes which use a framebuffer which is going away in a single 
> atomic
> + * commit.
> + *
> + * This scans all CRTCs and planes in @dev's mode_config. If they're using 
> @fb,
> + * it is removed and the CRTC/plane disabled.
> + * The legacy references are dropped and the ->fb pointers set to NULL
> + * accordingly.
> + *
> + * Returns:
> + * true if the framebuffer was successfully removed from use
> + */
> +static bool __drm_framebuffer_remove_atomic(struct drm_device *dev,
> + struct drm_framebuffer *fb)
> +{
> + struct drm_modeset_acquire_ctx ctx;
> + struct drm_atomic_state *state;
> + struct drm_connector_state *conn_state;
> + struct drm_connector *connector;
> + struct drm_plane *plane;
> + struct drm_crtc *crtc;
> + unsigned plane_mask;
> + int i, ret;
> +
> + drm_modeset_acquire_init(, 0);
> +
> + state = drm_atomic_state_alloc(dev);
> + if (!state)
> + return false;
> +
> + state->acquire_ctx = 
> +
> +retry:
> + drm_for_each_crtc(crtc, dev) {
> + struct drm_plane_state *primary_state;
> + struct drm_crtc_state *crtc_state;
> +
> + primary_state = drm_atomic_get_plane_state(state, 
> crtc->primary);
> + if (IS_ERR(primary_state)) {
> + ret = PTR_ERR(primary_state);
> + goto fail;
> + }
> +
> + if (primary_state->fb != fb)
> + continue;
> +
> + crtc_state = drm_atomic_get_crtc_state(state, crtc);
> + if (IS_ERR(crtc_state)) {
> + ret = PTR_ERR(crtc_state);
> + goto fail;
> + }
> +
> + /* Only handle the CRTC itself here, handle the plane later */
> + ret = drm_atomic_set_mode_for_crtc(crtc_state, NULL);
> + if (ret != 0)
> + goto fail;
> +
> + crtc_state->active = false;
> +
> + /* Get the connectors in order to disable them */
> + ret = drm_atomic_add_affected_connectors(state, crtc);
> + if (ret)
> + goto fail;
> + }
> +
> + plane_mask = 0;
> + drm_for_each_plane(plane, dev) {
> + struct drm_plane_state *plane_state;
> +
> + plane_state = drm_atomic_get_plane_state(state, plane);
> + if (IS_ERR(plane_state)) {
> + ret = PTR_ERR(plane_state);
> + goto fail;
> + }
> +
> + if (plane_state->fb != fb)
> + continue;
> +
> + plane->old_fb = plane->fb;
> + plane_mask |= 1 << drm_plane_index(plane);
> +
> + /*
> +  * Open-coded copy of __drm_atomic_helper_disable_plane to avoid
> +  * a dependency on atomic-helper
> +  */
> + ret = drm_atomic_set_crtc_for_plane(plane_state, NULL);
> + if (ret != 0)
> + goto fail;
> +
> + drm_atomic_set_fb_for_plane(plane_state, NULL);
> + plane_state->crtc_x = 0;
> + plane_state->crtc_y = 0;
> + plane_state->crtc_w = 0;
> + plane_state->crtc_h = 0;
> + plane_state->src_x = 0;
> + plane_state->src_y = 0;
> + 

[RFC PATCH 07/11] drm: Add writeback-connector pixel format properties

[Daniel Vetter]

On Tue, Oct 11, 2016 at 03:54:04PM +0100, Brian Starkey wrote:
> So that userspace can determine what pixel formats are supported for a
> writeback connector's framebuffer, add a pixel format list to writeback
> connectors. This is in the form of an immutable blob containing an array
> of formats, and an immutable uint holding the array size.
> 
> Signed-off-by: Brian Starkey 

I think we should have a dedicated writeback property registration
function, e.g. drm_writeback_connector_init(). That would then take the
pixel format list and everything else and make sure it's set up correctly.
For safety we might want to put a WARN_ON(type == WRITEBACK) into
drm_connector_init, to make sure no one botches this up.

Maybe even put all that into a new drm_writeback.c file, that then also
gives you a nice place to group all the documentation (including the DOC:
overview comment).

> ---
>  drivers/gpu/drm/drm_connector.c |   73 
> ++-
>  include/drm/drm_connector.h |   12 +++
>  include/drm/drm_crtc.h  |   12 +++
>  3 files changed, 96 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index fb83870..2f1f61d 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -249,9 +249,14 @@ int drm_connector_init(struct drm_device *dev,
>   drm_object_attach_property(>base, 
> config->prop_crtc_id, 0);
>   }
>  
> - if (connector_type == DRM_MODE_CONNECTOR_WRITEBACK)
> + if (connector_type == DRM_MODE_CONNECTOR_WRITEBACK) {
>   drm_object_attach_property(>base,
>  config->prop_fb_id, 0);
> + drm_object_attach_property(>base,
> +config->pixel_formats_property, 0);
> + drm_object_attach_property(>base,
> +config->pixel_formats_size_property, 
> 0);
> + }
>  
>   connector->debugfs_entry = NULL;
>  out_put_type_id:
> @@ -851,6 +856,45 @@ int drm_mode_create_suggested_offset_properties(struct 
> drm_device *dev)
>  EXPORT_SYMBOL(drm_mode_create_suggested_offset_properties);
>  
>  /**
> + * drm_mode_create_writeback_connector_properties - create writeback 
> connector properties
> + * @dev: DRM device
> + *
> + * Create the properties specific to writeback connectors. These will be 
> attached
> + * to writeback connectors by drm_connector_init. Drivers can set these
> + * properties using drm_mode_connector_set_writeback_formats().
> + *
> + *  "PIXEL_FORMATS":
> + *   Immutable blob property to store the supported pixel formats table. The
> + *   data is an array of u32 DRM_FORMAT_* fourcc values.
> + *   Userspace can use this blob to find out what pixel formats are supported
> + *   by the connector's writeback engine.
> + *
> + *  "PIXEL_FORMATS_SIZE":
> + *  Immutable unsigned range property storing the number of entries in 
> the
> + *  PIXEL_FORMATS array.
> + */
> +int drm_mode_create_writeback_connector_properties(struct drm_device *dev)
> +{
> + if (dev->mode_config.pixel_formats_property &&
> + dev->mode_config.pixel_formats_size_property)
> + return 0;
> +
> + dev->mode_config.pixel_formats_property =
> + drm_property_create(dev, DRM_MODE_PROP_BLOB | 
> DRM_MODE_PROP_IMMUTABLE,
> + "PIXEL_FORMATS", 0);
> +
> + dev->mode_config.pixel_formats_size_property =
> + drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE,
> + "PIXEL_FORMATS_SIZE", 0, UINT_MAX);
> +
> + if (dev->mode_config.pixel_formats_property == NULL ||
> + dev->mode_config.pixel_formats_size_property == NULL)
> + return -ENOMEM;
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_mode_create_writeback_connector_properties);
> +
> +/**
>   * drm_mode_connector_set_path_property - set tile property on connector
>   * @connector: connector to set property on.
>   * @path: path to use for property; must not be NULL.
> @@ -957,6 +1001,33 @@ int drm_mode_connector_update_edid_property(struct 
> drm_connector *connector,
>  }
>  EXPORT_SYMBOL(drm_mode_connector_update_edid_property);
>  
> +int drm_mode_connector_set_writeback_formats(struct drm_connector *connector,
> +  u32 *formats,
> +  unsigned int n_formats)
> +{
> + struct drm_device *dev = connector->dev;
> + size_t size = n_formats * sizeof(*formats);
> + int ret;
> +
> + if (connector->connector_type != DRM_MODE_CONNECTOR_WRITEBACK)
> + return -EINVAL;
> +
> + ret = drm_property_replace_global_blob(dev,
> +
> >pixel_formats_blob_ptr,
> +size,
> +formats,
> +

[RFC PATCH 02/11] drm/fb-helper: Skip writeback connectors

[Brian Starkey]

On Tue, Oct 11, 2016 at 05:44:48PM +0200, Daniel Vetter wrote:
>On Tue, Oct 11, 2016 at 03:53:59PM +0100, Brian Starkey wrote:
>> Writeback connectors aren't much use to the fbdev helpers, as they won't
>> show anything to the user. Skip them when looking for candidate output
>> configurations.
>>
>> Signed-off-by: Brian Starkey 
>> ---
>>  drivers/gpu/drm/drm_fb_helper.c |4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_fb_helper.c 
>> b/drivers/gpu/drm/drm_fb_helper.c
>> index 03414bd..dedf6e7 100644
>> --- a/drivers/gpu/drm/drm_fb_helper.c
>> +++ b/drivers/gpu/drm/drm_fb_helper.c
>> @@ -2016,6 +2016,10 @@ static int drm_pick_crtcs(struct drm_fb_helper 
>> *fb_helper,
>>  if (modes[n] == NULL)
>>  return best_score;
>>
>> +/* Writeback connectors aren't much use for fbdev */
>> +if (connector->connector_type == DRM_MODE_CONNECTOR_WRITEBACK)
>> +return best_score;
>
>I think we could handle this by always marking writeback connectors as
>disconnected. Userspace and fbdev emulation should then avoid them,
>always.
>-Daniel
>

Good idea; I'll need to take a closer look at how it would interact
with the probe helper (connector->force etc).

Are you thinking instead-of or in-addition-to the client cap? I'd be
worried about apps doing strange things and trying to use even
disconnected connectors.

>> +
>>  crtcs = kzalloc(fb_helper->connector_count *
>>  sizeof(struct drm_fb_helper_crtc *), GFP_KERNEL);
>>  if (!crtcs)
>> --
>> 1.7.9.5
>>
>
>-- 
>Daniel Vetter
>Software Engineer, Intel Corporation
>http://blog.ffwll.ch
>

[RFC PATCH 02/11] drm/fb-helper: Skip writeback connectors

[Daniel Vetter]

On Tue, Oct 11, 2016 at 03:53:59PM +0100, Brian Starkey wrote:
> Writeback connectors aren't much use to the fbdev helpers, as they won't
> show anything to the user. Skip them when looking for candidate output
> configurations.
> 
> Signed-off-by: Brian Starkey 
> ---
>  drivers/gpu/drm/drm_fb_helper.c |4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 03414bd..dedf6e7 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -2016,6 +2016,10 @@ static int drm_pick_crtcs(struct drm_fb_helper 
> *fb_helper,
>   if (modes[n] == NULL)
>   return best_score;
>  
> + /* Writeback connectors aren't much use for fbdev */
> + if (connector->connector_type == DRM_MODE_CONNECTOR_WRITEBACK)
> + return best_score;

I think we could handle this by always marking writeback connectors as
disconnected. Userspace and fbdev emulation should then avoid them,
always.
-Daniel

> +
>   crtcs = kzalloc(fb_helper->connector_count *
>   sizeof(struct drm_fb_helper_crtc *), GFP_KERNEL);
>   if (!crtcs)
> -- 
> 1.7.9.5
> 

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

[RFC PATCH 00/11] Introduce writeback connectors

[Daniel Vetter]

On Tue, Oct 11, 2016 at 03:53:57PM +0100, Brian Starkey wrote:
> Hi,
> 
> This RFC series introduces a new connector type:
>  DRM_MODE_CONNECTOR_WRITEBACK
> It is a follow-on from a previous discussion: [1]
> 
> Writeback connectors are used to expose the memory writeback engines
> found in some display controllers, which can write a CRTC's
> composition result to a memory buffer.
> This is useful e.g. for testing, screen-recording, screenshots,
> wireless display, display cloning, memory-to-memory composition.
> 
> Patches 1-7 include the core framework changes required, and patches
> 8-11 implement a writeback connector for the Mali-DP writeback engine.
> The Mali-DP patches depend on this other series: [2].
> 
> The connector is given the FB_ID property for the output framebuffer,
> and two new read-only properties: PIXEL_FORMATS and
> PIXEL_FORMATS_SIZE, which expose the supported framebuffer pixel
> formats of the engine.
> 
> The EDID property is not exposed for writeback connectors.
> 
> Writeback connector usage:
> --
> Due to connector routing changes being treated as "full modeset"
> operations, any client which wishes to use a writeback connector
> should include the connector in every modeset. The writeback will not
> actually become active until a framebuffer is attached.

Erhm, this is just the default, drivers can override this. And we could
change the atomic helpers to not mark a modeset as a modeset if the
connector that changed is a writeback one.

> The writeback itself is enabled by attaching a framebuffer to the
> FB_ID property of the connector. The driver must then ensure that the
> CRTC content of that atomic commit is written into the framebuffer.
> 
> The writeback works in a one-shot mode with each atomic commit. This
> prevents the same content from being written multiple times.
> In some cases (front-buffer rendering) there might be a desire for
> continuous operation - I think a property could be added later for
> this kind of control.
> 
> Writeback can be disabled by setting FB_ID to zero.

This seems to contradict itself: If it's one-shot, there's no need to
disable it - it will auto-disable.

In other cases where we write a property as a one-shot thing (fences for
android). In that case when you read that property it's always 0 (well, -1
for fences since file descriptor). That also avoids the issues when
userspace unconditionally saves/restores all properties (this is needed
for generic compositor switching).

I think a better behaviour would be to do the same trick, with FB_ID on
the connector always returning 0 as the current value. That encodes the
one-shot behaviour directly.

For one-shot vs continuous: Maybe we want to simply have a separate
writeback property for continues, e.g. FB_WRITEBACK_ONE_SHOT_ID and
FB_WRITEBACK_CONTINUOUS_ID.

> Known issues:
> -
>  * I'm not sure what "DPMS" should mean for writeback connectors.
>It could be used to disable writeback (even when a framebuffer is
>attached), or it could be hidden entirely (which would break the
>legacy DPMS call for writeback connectors).

dpms is legacy, in atomic land the only thing you have is "ACTIVE" on the
crtc. it disables everything, i.e. also writeback.

>  * With Daniel's recent re-iteration of the userspace API rules, I
>fully expect to provide some userspace code to support this. The
>question is what, and where? We want to use writeback for testing,
>so perhaps some tests in igt is suitable.

Hm, testing would be better as a debugfs interface, but I understand the
appeal of doing this with atomic (since semantics fit so well). Another
use-case of this is compositing, but if the main goal is igt and testing,
I think integration into igt crc based testcases is a perfectly fine
userspace.

>  * Documentation. Probably some portion of this cover letter needs to
>make it into Documentation/

Yeah, an overview DOC: section in a separate source file (with all the the
infrastructure work) would be great - aka needed from my pov ;-)

>  * Synchronisation. Our hardware will finish the writeback by the next
>vsync. I've not implemented fence support here, but it would be an
>obvious addition.

Probably just want an additional WRITEBACK_FENCE_ID property to signal
completion. Some hw definitely will take longer to write back than just a
vblank. But we can delay that until it's needed.
-Daniel

> 
> See Also:
> -
> [1] https://lists.freedesktop.org/archives/dri-devel/2016-July/113197.html
> [2] https://lists.freedesktop.org/archives/dri-devel/2016-October/120486.html
> 
> I welcome any comments, especially if this approach does/doesn't fit
> well with anyone else's hardware.
> 
> Thanks,
> 
> -Brian
> 
> ---
> 
> Brian Starkey (10):
>   drm: add writeback connector type
>   drm/fb-helper: skip writeback connectors
>   drm: extract CRTC/plane disable from drm_framebuffer_remove
>   drm: add __drm_framebuffer_remove_atomic
>   

[RFC PATCH 00/11] Introduce writeback connectors

[Brian Starkey]

Hi Daniel,

Firstly thanks very much for having a look.

On Tue, Oct 11, 2016 at 05:43:59PM +0200, Daniel Vetter wrote:
>On Tue, Oct 11, 2016 at 03:53:57PM +0100, Brian Starkey wrote:
>> Hi,
>>
>> This RFC series introduces a new connector type:
>>  DRM_MODE_CONNECTOR_WRITEBACK
>> It is a follow-on from a previous discussion: [1]
>>
>> Writeback connectors are used to expose the memory writeback engines
>> found in some display controllers, which can write a CRTC's
>> composition result to a memory buffer.
>> This is useful e.g. for testing, screen-recording, screenshots,
>> wireless display, display cloning, memory-to-memory composition.
>>
>> Patches 1-7 include the core framework changes required, and patches
>> 8-11 implement a writeback connector for the Mali-DP writeback engine.
>> The Mali-DP patches depend on this other series: [2].
>>
>> The connector is given the FB_ID property for the output framebuffer,
>> and two new read-only properties: PIXEL_FORMATS and
>> PIXEL_FORMATS_SIZE, which expose the supported framebuffer pixel
>> formats of the engine.
>>
>> The EDID property is not exposed for writeback connectors.
>>
>> Writeback connector usage:
>> --
>> Due to connector routing changes being treated as "full modeset"
>> operations, any client which wishes to use a writeback connector
>> should include the connector in every modeset. The writeback will not
>> actually become active until a framebuffer is attached.
>
>Erhm, this is just the default, drivers can override this. And we could
>change the atomic helpers to not mark a modeset as a modeset if the
>connector that changed is a writeback one.
>

Hmm, maybe. I don't think it's ideal - the driver would need to
re-implement drm_atomic_helper_check_modeset, which is quite a chunk
of code (along with exposing update_connector_routing, mode_fixup,
maybe others), and even after that it would have to lie and set
crtc_state->connectors_changed to false so that
drm_crtc_needs_modeset returns false to drm_atomic_check_only.

I tried to keep special-casing of writeback connectors in the core to
a bare minimum, because I think it will quickly get messy and fragile
otherwise.

Honestly, I don't see modesetting the writeback connectors at
start-of-day as a big problem.

>> The writeback itself is enabled by attaching a framebuffer to the
>> FB_ID property of the connector. The driver must then ensure that the
>> CRTC content of that atomic commit is written into the framebuffer.
>>
>> The writeback works in a one-shot mode with each atomic commit. This
>> prevents the same content from being written multiple times.
>> In some cases (front-buffer rendering) there might be a desire for
>> continuous operation - I think a property could be added later for
>> this kind of control.
>>
>> Writeback can be disabled by setting FB_ID to zero.
>
>This seems to contradict itself: If it's one-shot, there's no need to
>disable it - it will auto-disable.

I should have explained one-shot more clearly. What I mean is, one
drmModeAtomicCommit == one write to memory. This is as opposed to
writing the same thing to memory every vsync until it is stopped
(which our HW is capable of doing).

A subsequent drmModeAtomicCommit which doesn't touch the writeback 
FB_ID will write (again - but with whatever scene updates) to the same
framebuffer.

This continues for every drmModeAtomicCommit until FB_ID is set to
zero - to disable writing - or changed to a different framebuffer, in
which case we write to the new one.

IMO this behaviour makes sense in the context of the rest of Atomic,
and as the FB_ID is indeed persistent across atomic commits, I think
it should be read-able.

>
>In other cases where we write a property as a one-shot thing (fences for
>android). In that case when you read that property it's always 0 (well, -1
>for fences since file descriptor). That also avoids the issues when
>userspace unconditionally saves/restores all properties (this is needed
>for generic compositor switching).
>
>I think a better behaviour would be to do the same trick, with FB_ID on
>the connector always returning 0 as the current value. That encodes the
>one-shot behaviour directly.
>
>For one-shot vs continuous: Maybe we want to simply have a separate
>writeback property for continues, e.g. FB_WRITEBACK_ONE_SHOT_ID and
>FB_WRITEBACK_CONTINUOUS_ID.
>
>> Known issues:
>> -
>>  * I'm not sure what "DPMS" should mean for writeback connectors.
>>It could be used to disable writeback (even when a framebuffer is
>>attached), or it could be hidden entirely (which would break the
>>legacy DPMS call for writeback connectors).
>
>dpms is legacy, in atomic land the only thing you have is "ACTIVE" on the
>crtc. it disables everything, i.e. also writeback.
>

So removing the DPMS property is a viable option for writeback 
connectors in your opinion?

>>  * With Daniel's recent re-iteration of the userspace API rules, I
>>fully expect to provide 

[PATCH 2/9] drm/sun4i: tcon: Move SoC specific quirks to a DT matched data structure

[Chen-Yu Tsai]

On Fri, Oct 7, 2016 at 4:38 PM, Maxime Ripard
 wrote:
> Hi,
>
> On Fri, Oct 07, 2016 at 12:06:22AM +0800, Chen-Yu Tsai wrote:
>> +struct sun4i_tcon_quirks {
>> + boolis_sun5i;   /* sun5i has undocumented mux */
>> + boolhas_channel_1;  /* a33 does not have channel 1 */
>> + boolhas_bypass_src; /* has separate input bypassing CEU */
>> + boolhas_dma_src;/* has DMA input */
>> +};
>> +
>
> I'd really prefer to keep the has_mux quirk name. is_sun5i doesn't
> really relate to what we're doing there, is redundant with the
> compatible, and render the other quirks name useless, since we could
> just have is_sun.i quirks and deal with that (which is essentially
> what we were doing before).

Lets call it has_unknown_mux then. has_mux would be confusing with
the HDMI and MIPI DSI muxes on sun6i.

ChenYu

[PULL] drm-intel-next-fixes

[Jani Nikula]

Hi Dave -

A big bunch of i915 fixes for drm-next / v4.9 merge window, with more
than half of them also cc: stable. We also continue to have more Fixes:
annotations for our fixes, which should help the backporters and
archeologists.

There's also a fix to your v4.8-rc8 backmerge to drm-next, which brought
back a few unwanted lines. Seemed to be a tricky diff in the
conflict. The fix is 105f1a65b04a ("drm/i915: Fix conflict resolution
from backmerge of v4.8-rc8 to drm-next").

BR,
Jani.

The following changes since commit b89857852656f016328d2d7ccec5fff57445fa85:

  Merge branch 'drm-next-4.9' of git://people.freedesktop.org/~agd5f/linux into 
drm-next (2016-10-10 16:40:16 +1000)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/drm-intel-next-fixes-2016-10-11

for you to fetch changes up to 105f1a65b04a8f4f7abec11b200b1fb54f3d4b46:

  drm/i915: Fix conflict resolution from backmerge of v4.8-rc8 to drm-next 
(2016-10-10 16:12:21 +0300)


Chris Wilson (11):
  drm/i915: Restore current RPS state after reset
  drm/i915: Only shrink the unbound objects during freeze
  drm/i915: Just clear the mmiodebug before a register access
  drm/i915: Unalias obj->phys_handle and obj->userptr
  drm/i915: Use correct index for backtracking HUNG semaphores
  drm/i915/execlists: Reinitialise context image after GPU hang
  drm/i915: Distinguish last emitted request from last submitted request
  drm/i915: Force relocations via cpu if we run out of idle aperture
  drm/i915: Reset the breadcrumbs IRQ more carefully
  drm/i915/guc: Unwind GuC workqueue reservation if request construction 
fails
  drm/i915: Fix conflict resolution from backmerge of v4.8-rc8 to drm-next

Imre Deak (2):
  drm/i915: Unlock PPS registers after GPU reset
  drm/i915/bxt: Fix HDMI DPLL configuration

Jani Nikula (1):
  drm/i915/backlight: setup and cache pwm alternate increment value

Paulo Zanoni (9):
  drm/i915: don't forget to set intel_crtc->dspaddr_offset on SKL+
  drm/i915: SAGV is not SKL-only, so rename a few things
  drm/i915: introduce intel_has_sagv()
  drm/i915/kbl: KBL also needs to run the SAGV code
  drm/i915/gen9: fix the WaWmMemoryReadLatency implementation
  drm/i915/gen9: minimum scanlines for Y tile is not always 4
  drm/i915/gen9: fix plane_blocks_per_line on watermarks calculations
  drm/i915/gen9: fix the watermark res_blocks value
  drm/i915/gen9: only add the planes actually affected by ddb changes

Shawn Lee (1):
  drm/i915/backlight: setup backlight pwm alternate increment on backlight 
enable

Ville Syrjälä (3):
  drm/i915: Allow PCH DPLL sharing regardless of DPLL_SDVO_HIGH_SPEED
  drm/i915: Move long hpd handling into the hotplug work
  drm/i915: Allow DP to work w/o EDID

 drivers/gpu/drm/i915/i915_drv.c|  21 +--
 drivers/gpu/drm/i915/i915_drv.h|  35 +++--
 drivers/gpu/drm/i915/i915_gem.c|  27 +++-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |   4 +-
 drivers/gpu/drm/i915/i915_gem_request.c|   5 +-
 drivers/gpu/drm/i915/i915_guc_submission.c |  12 ++
 drivers/gpu/drm/i915/i915_irq.c|  14 +-
 drivers/gpu/drm/i915/intel_breadcrumbs.c   |  33 -
 drivers/gpu/drm/i915/intel_display.c   |  30 +++-
 drivers/gpu/drm/i915/intel_dp.c|  70 +
 drivers/gpu/drm/i915/intel_dpll_mgr.c  |  21 ++-
 drivers/gpu/drm/i915/intel_drv.h   |   7 +-
 drivers/gpu/drm/i915/intel_engine_cs.c |  15 --
 drivers/gpu/drm/i915/intel_guc.h   |   1 +
 drivers/gpu/drm/i915/intel_lrc.c   | 122 +---
 drivers/gpu/drm/i915/intel_panel.c |  32 -
 drivers/gpu/drm/i915/intel_pm.c| 218 ++---
 drivers/gpu/drm/i915/intel_ringbuffer.c|   2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.h|   3 +-
 drivers/gpu/drm/i915/intel_uncore.c|   7 +-
 20 files changed, 432 insertions(+), 247 deletions(-)

-- 
Jani Nikula, Intel Open Source Technology Center

[REGRESSION v4.7] i915 / drm crash when undocking from DP monitors

[Jani Nikula]

On Sat, 08 Oct 2016, Vadim Lobanov  wrote:
> I'm seeing a repeatable crash on my HP EliteBook 840 G2/2216 when
> booting it while in a docking station connected to two external
> DisplayPort monitors, undocking, and then either logging out or
> shutting down -- regardless of whether I've redocked it beforehand or
> not. Both logout and shutdown work great if I do not undock the laptop
> at all, so the badness correlates with the DP monitors going away.

Please file a bug at [1] with the info in this mail, add drm.debug=14
module parameter, and attach dmesg from boot to the problem into the
bug.

BR,
Jani.

[1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI=DRM/Intel

-- 
Jani Nikula, Intel Open Source Technology Center

[RFC 6/6] drivers: staging: ion: add ION_IOC_TAG ioctl

[Ruchi Kandoi]

From: Greg Hackmann 

ION_IOC_TAG provides a userspace interface for tagging buffers with
their memtrack usage after allocation.

Signed-off-by: Ruchi Kandoi 
---
 drivers/staging/android/ion/ion-ioctl.c | 17 +
 drivers/staging/android/uapi/ion.h  | 25 +
 2 files changed, 42 insertions(+)

diff --git a/drivers/staging/android/ion/ion-ioctl.c 
b/drivers/staging/android/ion/ion-ioctl.c
index 7e7431d..8745a85 100644
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -28,6 +28,7 @@ union ion_ioctl_arg {
struct ion_handle_data handle;
struct ion_custom_data custom;
struct ion_heap_query query;
+   struct ion_tag_data tag;
 };

 static int validate_ioctl_arg(unsigned int cmd, union ion_ioctl_arg *arg)
@@ -162,6 +163,22 @@ long ion_ioctl(struct file *filp, unsigned int cmd, 
unsigned long arg)
case ION_IOC_HEAP_QUERY:
ret = ion_query_heaps(client, );
break;
+   case ION_IOC_TAG:
+   {
+#ifdef CONFIG_MEMTRACK
+   struct ion_handle *handle;
+
+   handle = ion_handle_get_by_id(client, data.tag.handle);
+   if (IS_ERR(handle))
+   return PTR_ERR(handle);
+   data.tag.tag[sizeof(data.tag.tag) - 1] = 0;
+   memtrack_buffer_set_tag(>buffer->memtrack_buffer,
+   data.tag.tag);
+#else
+   ret = -ENOTTY;
+#endif
+   break;
+   }
default:
return -ENOTTY;
}
diff --git a/drivers/staging/android/uapi/ion.h 
b/drivers/staging/android/uapi/ion.h
index 14cd873..4c26196 100644
--- a/drivers/staging/android/uapi/ion.h
+++ b/drivers/staging/android/uapi/ion.h
@@ -115,6 +115,22 @@ struct ion_handle_data {
ion_user_handle_t handle;
 };

+#define ION_MAX_TAG_LEN 32
+
+/**
+ * struct ion_fd_data - metadata passed from userspace for a handle
+ * @handle:a handle
+ * @tag: a string describing the buffer
+ *
+ * For ION_IOC_TAG userspace populates the handle field with
+ * the handle returned from ion alloc and type contains the memtrack_type which
+ * accurately describes the usage for the memory.
+ */
+struct ion_tag_data {
+   ion_user_handle_t handle;
+   char tag[ION_MAX_TAG_LEN];
+};
+
 /**
  * struct ion_custom_data - metadata passed to/from userspace for a custom 
ioctl
  * @cmd:   the custom ioctl function to call
@@ -217,6 +233,15 @@ struct ion_heap_query {
 #define ION_IOC_SYNC   _IOWR(ION_IOC_MAGIC, 7, struct ion_fd_data)

 /**
+ * DOC: ION_IOC_TAG - adds a memtrack descriptor tag to memory
+ *
+ * Takes an ion_tag_data struct with the type field populated with a
+ * memtrack_type and handle populated with a valid opaque handle. The
+ * memtrack_type should accurately define the usage for the memory.
+ */
+#define ION_IOC_TAG_IOWR(ION_IOC_MAGIC, 8, struct ion_tag_data)
+
+/**
  * DOC: ION_IOC_CUSTOM - call architecture specific ion ioctl
  *
  * Takes the argument of the architecture specific ioctl to call and
-- 
2.8.0.rc3.226.g39d4020

[RFC 5/6] memtrack: Add memtrack accounting for forked processes.

[Ruchi Kandoi]

When a process is forked, all the buffers are shared with the forked
process too. Adds the functionality to add memtrack accounting for the
forked processes.

Forked process gets a copy of the mapped pages of the parent process.
This patch makes sure that the new mapped pages are attributed to the
child process instead of the parent.

Signed-off-by: Ruchi Kandoi 
---
 drivers/misc/memtrack.c   | 45 +++
 drivers/staging/android/ion/ion.c | 45 +--
 include/linux/memtrack.h  | 19 +++--
 include/linux/mm.h|  3 +++
 kernel/fork.c | 19 +++--
 5 files changed, 117 insertions(+), 14 deletions(-)

diff --git a/drivers/misc/memtrack.c b/drivers/misc/memtrack.c
index 4b2d17f..fa2601a 100644
--- a/drivers/misc/memtrack.c
+++ b/drivers/misc/memtrack.c
@@ -204,12 +204,13 @@ EXPORT_SYMBOL(memtrack_buffer_uninstall);
  * @buffer: the buffer's memtrack entry
  *
  * @vma: vma being opened
+ * @task: task which mapped the pages
  */
 void memtrack_buffer_vm_open(struct memtrack_buffer *buffer,
-   const struct vm_area_struct *vma)
+   const struct vm_area_struct *vma, struct task_struct *task)
 {
unsigned long flags;
-   struct task_struct *leader = current->group_leader;
+   struct task_struct *leader = task->group_leader;
struct memtrack_vma_list *vma_list;

vma_list = kmalloc(sizeof(*vma_list), GFP_KERNEL);
@@ -228,12 +229,13 @@ EXPORT_SYMBOL(memtrack_buffer_vm_open);
  *
  * @buffer: the buffer's memtrack entry
  * @vma: the vma being closed
+ * @task: task that mmaped the pages
  */
 void memtrack_buffer_vm_close(struct memtrack_buffer *buffer,
-   const struct vm_area_struct *vma)
+   const struct vm_area_struct *vma, struct task_struct *task)
 {
unsigned long flags;
-   struct task_struct *leader = current->group_leader;
+   struct task_struct *leader = task->group_leader;

write_lock_irqsave(>memtrack_lock, flags);
memtrack_buffer_vm_close_locked(>memtrack_rb, buffer, vma);
@@ -241,6 +243,41 @@ void memtrack_buffer_vm_close(struct memtrack_buffer 
*buffer,
 }
 EXPORT_SYMBOL(memtrack_buffer_vm_close);

+/**
+ * memtrack_buffer_install_fork - Install all parent's handles into
+ *  child.
+ *
+ * @parent: parent task
+ * @child: child task
+ */
+void memtrack_buffer_install_fork(struct task_struct *parent,
+   struct task_struct *child)
+{
+   struct task_struct *leader, *leader_child;
+   struct rb_root *root;
+   struct rb_node *node;
+   unsigned long flags;
+
+   if (!child || !parent)
+   return;
+
+   leader = parent->group_leader;
+   leader_child = child->group_leader;
+   write_lock_irqsave(>memtrack_lock, flags);
+   root = >memtrack_rb;
+   node = rb_first(root);
+   while (node) {
+   struct memtrack_handle *handle;
+
+   handle = rb_entry(node, struct memtrack_handle, node);
+   memtrack_buffer_install_locked(_child->memtrack_rb,
+   handle->buffer);
+   node = rb_next(node);
+   }
+   write_unlock_irqrestore(>memtrack_lock, flags);
+}
+EXPORT_SYMBOL(memtrack_buffer_install_fork);
+
 static int memtrack_id_alloc(struct memtrack_buffer *buffer)
 {
int ret;
diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index c32d520..451aa0f 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -906,7 +906,7 @@ static void ion_vm_open(struct vm_area_struct *vma)
list_add(_list->list, >vmas);
mutex_unlock(>lock);
pr_debug("%s: adding %p\n", __func__, vma);
-   memtrack_buffer_vm_open(>memtrack_buffer, vma);
+   memtrack_buffer_vm_open(>memtrack_buffer, vma, current);
 }

 static void ion_vm_close(struct vm_area_struct *vma)
@@ -925,13 +925,51 @@ static void ion_vm_close(struct vm_area_struct *vma)
break;
}
mutex_unlock(>lock);
-   memtrack_buffer_vm_close(>memtrack_buffer, vma);
+   memtrack_buffer_vm_close(>memtrack_buffer, vma, current);
+}
+
+void vm_track(struct vm_area_struct *vma, struct task_struct *task)
+{
+   struct ion_buffer *buffer = vma->vm_private_data;
+
+   memtrack_buffer_vm_open(>memtrack_buffer, vma, task);
+}
+
+void vm_untrack(struct vm_area_struct *vma, struct task_struct *task)
+{
+   struct ion_buffer *buffer = vma->vm_private_data;
+
+   memtrack_buffer_vm_close(>memtrack_buffer, vma, task);
 }

 static const struct vm_operations_struct ion_vma_ops = {
.open = ion_vm_open,
.close = ion_vm_close,
.fault = ion_vm_fault,
+   .track = vm_track,
+   .untrack = vm_untrack,
+};
+
+static void memtrack_vm_close(struct vm_area_struct *vma)
+{
+   struct ion_buffer *buffer = vma->vm_private_data;
+
+

[RFC 4/6] memtrack: Adds the accounting to keep track of all mmaped/unmapped pages.

[Ruchi Kandoi]

Since mmaped pages will be accounted by the PSS, memtrack needs a way
to differentiate the total memory that hasn't been accounted for.

Signed-off-by: Ruchi Kandoi 
Signed-off-by: Greg Hackmann 
---
 drivers/misc/memtrack.c   | 175 --
 drivers/staging/android/ion/ion.c |   5 +-
 include/linux/memtrack.h  |  29 +++
 3 files changed, 180 insertions(+), 29 deletions(-)

diff --git a/drivers/misc/memtrack.c b/drivers/misc/memtrack.c
index e5c7e03..4b2d17f 100644
--- a/drivers/misc/memtrack.c
+++ b/drivers/misc/memtrack.c
@@ -22,12 +22,19 @@
 #include 
 #include 
 #include 
+#include 
+
+struct memtrack_vma_list {
+   struct hlist_node node;
+   const struct vm_area_struct *vma;
+};

 struct memtrack_handle {
struct memtrack_buffer *buffer;
struct rb_node node;
struct rb_root *root;
struct kref refcount;
+   struct hlist_head vma_list;
 };

 static struct kmem_cache *memtrack_handle_cache;
@@ -40,8 +47,8 @@ static DEFINE_IDR(mem_idr);
 static DEFINE_IDA(mem_ida);
 #endif

-static void memtrack_buffer_install_locked(struct rb_root *root,
-   struct memtrack_buffer *buffer)
+static struct memtrack_handle *memtrack_handle_find_locked(struct rb_root 
*root,
+   struct memtrack_buffer *buffer, bool alloc)
 {
struct rb_node **new = >rb_node, *parent = NULL;
struct memtrack_handle *handle;
@@ -56,22 +63,38 @@ static void memtrack_buffer_install_locked(struct rb_root 
*root,
} else if (handle->buffer->id < buffer->id) {
new = >rb_right;
} else {
-   kref_get(>refcount);
-   return;
+   return handle;
}
}

-   handle = kmem_cache_alloc(memtrack_handle_cache, GFP_KERNEL);
-   if (!handle)
-   return;
+   if (alloc) {
+   handle = kmem_cache_alloc(memtrack_handle_cache, GFP_KERNEL);
+   if (!handle)
+   return NULL;

-   handle->buffer = buffer;
-   handle->root = root;
-   kref_init(>refcount);
+   handle->buffer = buffer;
+   handle->root = root;
+   kref_init(>refcount);
+   INIT_HLIST_HEAD(>vma_list);

-   rb_link_node(>node, parent, new);
-   rb_insert_color(>node, root);
-   atomic_inc(>buffer->userspace_handles);
+   rb_link_node(>node, parent, new);
+   rb_insert_color(>node, root);
+   atomic_inc(>buffer->userspace_handles);
+   }
+
+   return NULL;
+}
+
+static void memtrack_buffer_install_locked(struct rb_root *root,
+   struct memtrack_buffer *buffer)
+{
+   struct memtrack_handle *handle;
+
+   handle = memtrack_handle_find_locked(root, buffer, true);
+   if (handle) {
+   kref_get(>refcount);
+   return;
+   }
 }

 /**
@@ -112,19 +135,41 @@ static void memtrack_handle_destroy(struct kref *ref)
 static void memtrack_buffer_uninstall_locked(struct rb_root *root,
struct memtrack_buffer *buffer)
 {
-   struct rb_node *node = root->rb_node;
+   struct memtrack_handle *handle;

-   while (node) {
-   struct memtrack_handle *handle = rb_entry(node,
-   struct memtrack_handle, node);
+   handle = memtrack_handle_find_locked(root, buffer, false);

-   if (handle->buffer->id > buffer->id) {
-   node = node->rb_left;
-   } else if (handle->buffer->id < buffer->id) {
-   node = node->rb_right;
-   } else {
-   kref_put(>refcount, memtrack_handle_destroy);
-   return;
+   if (handle)
+   kref_put(>refcount, memtrack_handle_destroy);
+}
+
+static void memtrack_buffer_vm_open_locked(struct rb_root *root,
+   struct memtrack_buffer *buffer,
+   struct memtrack_vma_list *vma_list)
+{
+   struct memtrack_handle *handle;
+
+   handle = memtrack_handle_find_locked(root, buffer, false);
+   if (handle)
+   hlist_add_head(_list->node, >vma_list);
+}
+
+static void memtrack_buffer_vm_close_locked(struct rb_root *root,
+   struct memtrack_buffer *buffer,
+   const struct vm_area_struct *vma)
+{
+   struct memtrack_handle *handle;
+
+   handle = memtrack_handle_find_locked(root, buffer, false);
+   if (handle) {
+   struct memtrack_vma_list *vma_list;
+
+   hlist_for_each_entry(vma_list, >vma_list, node) {
+   if (vma_list->vma == vma) {
+   hlist_del(_list->node);
+   kfree(vma_list);
+   return;
+   }
}
}
 }
@@ -153,6 +198,49 @@ void memtrack_buffer_uninstall(struct 

[RFC 3/6] dma-buf: add memtrack support

[Ruchi Kandoi]

Signed-off-by: Greg Hackmann 
Signed-off-by: Ruchi Kandoi 
---
 drivers/dma-buf/dma-buf.c  | 37 ++
 drivers/staging/android/ion/ion.c  | 14 +
 drivers/staging/android/ion/ion_priv.h |  2 ++
 include/linux/dma-buf.h|  5 +
 4 files changed, 58 insertions(+)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index ddaee60..f632c2b 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -297,12 +297,32 @@ static long dma_buf_ioctl(struct file *file,
}
 }

+static void dma_buf_installed(struct file *file, struct task_struct *task)
+{
+   struct memtrack_buffer *memtrack =
+   dma_buf_memtrack_buffer(file->private_data);
+
+   if (memtrack)
+   memtrack_buffer_install(memtrack, task);
+}
+
+static void dma_buf_uninstalled(struct file *file, struct task_struct *task)
+{
+   struct memtrack_buffer *memtrack =
+   dma_buf_memtrack_buffer(file->private_data);
+
+   if (memtrack)
+   memtrack_buffer_uninstall(memtrack, task);
+}
+
 static const struct file_operations dma_buf_fops = {
.release= dma_buf_release,
.mmap   = dma_buf_mmap_internal,
.llseek = dma_buf_llseek,
.poll   = dma_buf_poll,
.unlocked_ioctl = dma_buf_ioctl,
+   .installed  = dma_buf_installed,
+   .uninstalled= dma_buf_uninstalled,
 };

 /*
@@ -830,6 +850,23 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
 }
 EXPORT_SYMBOL_GPL(dma_buf_vunmap);

+/**
+ * dma_buf_memtrack_buffer - returns a memtrack entry associated with dma_buf
+ *
+ * @dmabuf:[in]pointer to dma_buf
+ *
+ * Returns the struct memtrack_buffer associated with this dma_buf's
+ * backing pages.  If memtrack isn't enabled in the kernel, or the dma_buf
+ * exporter doesn't have memtrack support, returns NULL.
+ */
+struct memtrack_buffer *dma_buf_memtrack_buffer(struct dma_buf *dmabuf)
+{
+   if (!dmabuf->ops->memtrack_buffer)
+   return NULL;
+   return dmabuf->ops->memtrack_buffer(dmabuf);
+}
+EXPORT_SYMBOL_GPL(dma_buf_memtrack_buffer);
+
 #ifdef CONFIG_DEBUG_FS
 static int dma_buf_debug_show(struct seq_file *s, void *unused)
 {
diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 396ded5..1c2df54 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -196,6 +196,7 @@ void ion_buffer_destroy(struct ion_buffer *buffer)
buffer->heap->ops->unmap_kernel(buffer->heap, buffer);
buffer->heap->ops->free(buffer);
vfree(buffer->pages);
+   memtrack_buffer_remove(>memtrack_buffer);
kfree(buffer);
 }

@@ -458,6 +459,8 @@ struct ion_handle *ion_alloc(struct ion_client *client, 
size_t len,
handle = ERR_PTR(ret);
}

+   memtrack_buffer_init(>memtrack_buffer, len);
+
return handle;
 }
 EXPORT_SYMBOL(ion_alloc);
@@ -1013,6 +1016,16 @@ static int ion_dma_buf_end_cpu_access(struct dma_buf 
*dmabuf,
return 0;
 }

+static struct memtrack_buffer *ion_memtrack_buffer(struct dma_buf *buffer)
+{
+   if (IS_ENABLED(CONFIG_MEMTRACK) && buffer && buffer->priv) {
+   struct ion_buffer *ion_buffer = buffer->priv;
+
+   return _buffer->memtrack_buffer;
+   }
+   return NULL;
+}
+
 static struct dma_buf_ops dma_buf_ops = {
.map_dma_buf = ion_map_dma_buf,
.unmap_dma_buf = ion_unmap_dma_buf,
@@ -1024,6 +1037,7 @@ static struct dma_buf_ops dma_buf_ops = {
.kunmap_atomic = ion_dma_buf_kunmap,
.kmap = ion_dma_buf_kmap,
.kunmap = ion_dma_buf_kunmap,
+   .memtrack_buffer = ion_memtrack_buffer,
 };

 struct dma_buf *ion_share_dma_buf(struct ion_client *client,
diff --git a/drivers/staging/android/ion/ion_priv.h 
b/drivers/staging/android/ion/ion_priv.h
index 3c3b324..74c38eb 100644
--- a/drivers/staging/android/ion/ion_priv.h
+++ b/drivers/staging/android/ion/ion_priv.h
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 

 #include "ion.h"

@@ -78,6 +79,7 @@ struct ion_buffer {
int handle_count;
char task_comm[TASK_COMM_LEN];
pid_t pid;
+   struct memtrack_buffer memtrack_buffer;
 };
 void ion_buffer_destroy(struct ion_buffer *buffer);

diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index e0b0741..dfcc2d0 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 

 struct device;
 struct dma_buf;
@@ -70,6 +71,8 @@ struct dma_buf_attachment;
  * @vmap: [optional] creates a virtual mapping for the buffer into kernel
  *   address space. Same restrictions as for vmap and friends apply.
  * @vunmap: [optional] unmaps a vmap from the buffer
+ * @memtrack_buffer: [optional] returns the memtrack entry for this buffer's
+ *backing pages
  

[RFC 2/6] drivers: misc: add memtrack

[Ruchi Kandoi]

Shared-buffer allocators like ion or GEM traditionally call into CMA or
alloc_pages() to get backing memory, meaning these allocations will not
show up in any process's mm counters.  But since these allocations are
often used for things like graphics buffers that can be extremely large,
the user just sees a bunch of pages vanishing from the system without an
explanation.

CONFIG_MEMTRACK adds infrastructure for "blaming" these allocations back
to the processes currently holding a reference to the shared buffer.
This information is exposed to userspace through /proc/[pid]/memtrack.

To use memtrack, the shared memory allocator should:

(1) Embed a struct memtrack_buffer somewhere in the underlying buffer's
metadata, and initialize it with memtrack_buffer_init()

(3) Call memtrack_buffer_{install,uninstall} each time a task takes or
drops a reference to the shared buffer

(3) Call memtrack_buffer_remove() before destroying a tracked buffer

CONFIG_MEMTRACK_DEBUG adds a global list of all buffers tracked by
memtrack, accessible through /sys/kernel/debug/memtrack.  This involves
maintaining a global idr of buffers.  Due to the extra overhead,
CONFIG_MEMTRACK_DEBUG is intended for debugging memory leaks rather than
production use.

Signed-off-by: Greg Hackmann 
Signed-off-by: Ruchi Kandoi 
---
 drivers/misc/Kconfig |  16 +++
 drivers/misc/Makefile|   1 +
 drivers/misc/memtrack.c  | 360 +++
 fs/proc/base.c   |   4 +
 include/linux/memtrack.h |  94 +
 include/linux/sched.h|   3 +
 kernel/fork.c|   4 +
 7 files changed, 482 insertions(+)
 create mode 100644 drivers/misc/memtrack.c
 create mode 100644 include/linux/memtrack.h

diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 64971ba..7557fb1 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -766,6 +766,22 @@ config PANEL_BOOT_MESSAGE
  An empty message will only clear the display at driver init time. Any 
other
  printf()-formatted message is valid with newline and escape codes.

+config MEMTRACK
+   tristate "Per-pid memory statistics"
+   default n
+   ---help---
+ Keeps track of shared buffers allocated by the process and
+ exports them via /proc//memtrack.
+
+config MEMTRACK_DEBUG
+   tristate "Per-pid memory statistics debug option"
+   depends on MEMTRACK && DEBUG_FS
+   default n
+   ---help---
+ Keeps track of all shared buffers allocated and exports the list
+ via /sys/kernel/debug/memtrack.
+
+ source "drivers/misc/c2port/Kconfig"
 source "drivers/misc/c2port/Kconfig"
 source "drivers/misc/eeprom/Kconfig"
 source "drivers/misc/cb710/Kconfig"
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 3198336..1fbb084 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -68,3 +68,4 @@ OBJCOPYFLAGS_lkdtm_rodata_objcopy.o := \
 targets += lkdtm_rodata.o lkdtm_rodata_objcopy.o
 $(obj)/lkdtm_rodata_objcopy.o: $(obj)/lkdtm_rodata.o FORCE
$(call if_changed,objcopy)
+obj-$(CONFIG_MEMTRACK)  += memtrack.o
diff --git a/drivers/misc/memtrack.c b/drivers/misc/memtrack.c
new file mode 100644
index 000..e5c7e03
--- /dev/null
+++ b/drivers/misc/memtrack.c
@@ -0,0 +1,360 @@
+/* drivers/misc/memtrack.c
+ *
+ * Copyright (C) 2016 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct memtrack_handle {
+   struct memtrack_buffer *buffer;
+   struct rb_node node;
+   struct rb_root *root;
+   struct kref refcount;
+};
+
+static struct kmem_cache *memtrack_handle_cache;
+
+static DEFINE_MUTEX(memtrack_id_lock);
+#if IS_ENABLED(CONFIG_MEMTRACK_DEBUG)
+static struct dentry *debugfs_file;
+static DEFINE_IDR(mem_idr);
+#else
+static DEFINE_IDA(mem_ida);
+#endif
+
+static void memtrack_buffer_install_locked(struct rb_root *root,
+   struct memtrack_buffer *buffer)
+{
+   struct rb_node **new = >rb_node, *parent = NULL;
+   struct memtrack_handle *handle;
+
+   while (*new) {
+   struct rb_node *node = *new;
+
+   handle = rb_entry(node, struct memtrack_handle, node);
+   parent = node;
+   if (handle->buffer->id > buffer->id) {
+   new = >rb_left;
+   } else if (handle->buffer->id < buffer->id) {
+   new = >rb_right;
+   } else {
+   

[RFC 1/6] fs: add installed and uninstalled file_operations

[Ruchi Kandoi]

These optional file_operations notify a file implementation when it is
installed or uninstalled from a task's fd table.  This can be used for
accounting of file-backed shared resources like dma-buf.

This involves some changes to the __fd_install() and __close_fd() APIs
to actually pass along the responsible task_struct.  These are low-level
APIs with only two in-tree callers, both adjusted in this patch.

Signed-off-by: Greg Hackmann 
Signed-off-by: Ruchi Kandoi 
---
 drivers/android/binder.c |  4 ++--
 fs/file.c| 38 +-
 fs/open.c|  2 +-
 include/linux/fdtable.h  |  4 ++--
 include/linux/fs.h   |  2 ++
 5 files changed, 36 insertions(+), 14 deletions(-)

diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index 562af94..0bb174e 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -398,7 +398,7 @@ static void task_fd_install(
struct binder_proc *proc, unsigned int fd, struct file *file)
 {
if (proc->files)
-   __fd_install(proc->files, fd, file);
+   __fd_install(proc->tsk, fd, file);
 }

 /*
@@ -411,7 +411,7 @@ static long task_close_fd(struct binder_proc *proc, 
unsigned int fd)
if (proc->files == NULL)
return -ESRCH;

-   retval = __close_fd(proc->files, fd);
+   retval = __close_fd(proc->tsk, fd);
/* can't restart close syscall because file table entry was cleared */
if (unlikely(retval == -ERESTARTSYS ||
 retval == -ERESTARTNOINTR ||
diff --git a/fs/file.c b/fs/file.c
index 69d6990..19c5fad 100644
--- a/fs/file.c
+++ b/fs/file.c
@@ -282,6 +282,24 @@ static unsigned int count_open_files(struct fdtable *fdt)
return i;
 }

+static inline void fdt_install(struct fdtable *fdt, int fd, struct file *file,
+   struct task_struct *task)
+{
+   if (file->f_op->installed)
+   file->f_op->installed(file, task);
+   rcu_assign_pointer(fdt->fd[fd], file);
+}
+
+static inline void fdt_uninstall(struct fdtable *fdt, int fd,
+   struct task_struct *task)
+{
+   struct file *old_file = fdt->fd[fd];
+
+   if (old_file->f_op->uninstalled)
+   old_file->f_op->uninstalled(old_file, task);
+   rcu_assign_pointer(fdt->fd[fd], NULL);
+}
+
 /*
  * Allocate a new files structure and copy contents from the
  * passed in files structure.
@@ -543,7 +561,7 @@ int __alloc_fd(struct files_struct *files,
/* Sanity check */
if (rcu_access_pointer(fdt->fd[fd]) != NULL) {
printk(KERN_WARNING "alloc_fd: slot %d not NULL!\n", fd);
-   rcu_assign_pointer(fdt->fd[fd], NULL);
+   fdt_uninstall(fdt, fd, current);
}
 #endif

@@ -601,10 +619,11 @@ EXPORT_SYMBOL(put_unused_fd);
  * fd_install() instead.
  */

-void __fd_install(struct files_struct *files, unsigned int fd,
+void __fd_install(struct task_struct *task, unsigned int fd,
struct file *file)
 {
struct fdtable *fdt;
+   struct files_struct *files = task->files;

might_sleep();
rcu_read_lock_sched();
@@ -618,13 +637,13 @@ void __fd_install(struct files_struct *files, unsigned 
int fd,
smp_rmb();
fdt = rcu_dereference_sched(files->fdt);
BUG_ON(fdt->fd[fd] != NULL);
-   rcu_assign_pointer(fdt->fd[fd], file);
+   fdt_install(fdt, fd, file, task);
rcu_read_unlock_sched();
 }

 void fd_install(unsigned int fd, struct file *file)
 {
-   __fd_install(current->files, fd, file);
+   __fd_install(current, fd, file);
 }

 EXPORT_SYMBOL(fd_install);
@@ -632,10 +651,11 @@ EXPORT_SYMBOL(fd_install);
 /*
  * The same warnings as for __alloc_fd()/__fd_install() apply here...
  */
-int __close_fd(struct files_struct *files, unsigned fd)
+int __close_fd(struct task_struct *task, unsigned fd)
 {
struct file *file;
struct fdtable *fdt;
+   struct files_struct *files = task->files;

spin_lock(>file_lock);
fdt = files_fdtable(files);
@@ -644,7 +664,7 @@ int __close_fd(struct files_struct *files, unsigned fd)
file = fdt->fd[fd];
if (!file)
goto out_unlock;
-   rcu_assign_pointer(fdt->fd[fd], NULL);
+   fdt_uninstall(fdt, fd, task);
__clear_close_on_exec(fd, fdt);
__put_unused_fd(files, fd);
spin_unlock(>file_lock);
@@ -679,7 +699,7 @@ void do_close_on_exec(struct files_struct *files)
file = fdt->fd[fd];
if (!file)
continue;
-   rcu_assign_pointer(fdt->fd[fd], NULL);
+   fdt_uninstall(fdt, fd, current);
__put_unused_fd(files, fd);
spin_unlock(>file_lock);
filp_close(file, files);
@@ -846,7 +866,7 @@ __releases(>file_lock)
if (!tofree && fd_is_open(fd, fdt))
goto 

[RFC 0/6] Module for tracking/accounting shared memory buffers

[Ruchi Kandoi]

This patchstack introduces a new "memtrack" module for tracking and accounting
memory exported to userspace as shared buffers, like dma-buf fds or GEM handles.

Any process holding a reference to these buffers will keep the kernel from
reclaiming its backing pages.  mm counters don't provide a complete picture of
these allocations, since they only account for pages that are mapped into a
process's address space.  This problem is especially bad for systems like
Android that use dma-buf fds to share graphics and multimedia buffers between
processes: these allocations are often large, have complex sharing patterns,
and are rarely mapped into every process that holds a reference to them.

memtrack maintains a per-process list of shared buffer references, which is
exported to userspace as /proc/[pid]/memtrack.  Buffers can be optionally
"tagged" with a short string: for example, Android userspace would use this
tag to identify whether buffers were allocated on behalf of the camera stack,
GL, etc.  memtrack also exports the VMAs associated with these buffers so
that pages already included in the process's mm counters aren't double-counted.

Shared-buffer allocators can hook into memtrack by embedding
struct memtrack_buffer in their buffer metadata, calling
memtrack_buffer_{init,remove} at buffer allocation and free time, and
memtrack_buffer_{install,uninstall} when a userspace process takes or
drops a reference to the buffer.  For fd-backed buffers like dma-bufs, hooks in
fdtable.c and fork.c automatically notify memtrack when references are added or
removed from a process's fd table.

This patchstack adds memtrack hooks into dma-buf and ion.  If there's upstream
interest in memtrack, it can be extended to other memory allocators as well,
such as GEM implementations.

Greg Hackmann (1):
  drivers: staging: ion: add ION_IOC_TAG ioctl

Ruchi Kandoi (5):
  fs: add installed and uninstalled file_operations
  drivers: misc: add memtrack
  dma-buf: add memtrack support
  memtrack: Adds the accounting to keep track of all mmaped/unmapped
pages.
  memtrack: Add memtrack accounting for forked processes.

 drivers/android/binder.c|   4 +-
 drivers/dma-buf/dma-buf.c   |  37 +++
 drivers/misc/Kconfig|  16 +
 drivers/misc/Makefile   |   1 +
 drivers/misc/memtrack.c | 516 
 drivers/staging/android/ion/ion-ioctl.c |  17 ++
 drivers/staging/android/ion/ion.c   |  60 +++-
 drivers/staging/android/ion/ion_priv.h  |   2 +
 drivers/staging/android/uapi/ion.h  |  25 ++
 fs/file.c   |  38 ++-
 fs/open.c   |   2 +-
 fs/proc/base.c  |   4 +
 include/linux/dma-buf.h |   5 +
 include/linux/fdtable.h |   4 +-
 include/linux/fs.h  |   2 +
 include/linux/memtrack.h| 130 
 include/linux/mm.h  |   3 +
 include/linux/sched.h   |   3 +
 kernel/fork.c   |  23 +-
 19 files changed, 875 insertions(+), 17 deletions(-)
 create mode 100644 drivers/misc/memtrack.c
 create mode 100644 include/linux/memtrack.h

-- 
2.8.0.rc3.226.g39d4020

[Intel-gfx] [PATCH 04/10] drm/i915/gen9: Cleanup skl_pipe_wm_active_state

[Paulo Zanoni]

Em Sex, 2016-10-07 às 20:11 -0400, Lyude escreveu:
> This function is a wreck, let's help it get it's life back together
> and
> cleanup all of the copy pasta here.

s/it's/its/

Idea for your next patch series: rename skl_pipe_wm_active_state()'s
"i" parameter to something more meaningful.

Reviewed-by: Paulo Zanoni 

> 
> (adding Maarten's reviewed-by since this is just a split-up version
> of one
> of the previous patches)
> 
> Signed-off-by: Lyude 
> Reviewed-by: Maarten Lankhorst 
> Cc: Ville Syrjälä 
> Cc: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 52 +++--
> 
>  1 file changed, 14 insertions(+), 38 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c
> b/drivers/gpu/drm/i915/intel_pm.c
> index 4c2ebcd..5dbaf12 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -4267,46 +4267,22 @@ static void ilk_optimize_watermarks(struct
> intel_crtc_state *cstate)
>  static void skl_pipe_wm_active_state(uint32_t val,
>       struct skl_pipe_wm *active,
>       bool is_transwm,
> -      bool is_cursor,
>       int i,
>       int level)
>  {
> + struct skl_plane_wm *plane_wm = >planes[i];
>  bool is_enabled = (val & PLANE_WM_EN) != 0;
>  
>  if (!is_transwm) {
> - if (!is_cursor) {
> - active->planes[i].wm[level].plane_en =
> is_enabled;
> - active->planes[i].wm[level].plane_res_b =
> - val & PLANE_WM_BLOCKS_MASK;
> - active->planes[i].wm[level].plane_res_l =
> - (val >> PLANE_WM_LINES_SHIFT) &
> - PLANE_WM_LINES_MASK;
> - } else {
> - active-
> >planes[PLANE_CURSOR].wm[level].plane_en =
> - is_enabled;
> - active-
> >planes[PLANE_CURSOR].wm[level].plane_res_b =
> - val & PLANE_WM_BLOCKS_MASK;
> - active-
> >planes[PLANE_CURSOR].wm[level].plane_res_l =
> - (val >> PLANE_WM_LINES_SHIFT) &
> - PLANE_WM_LINES_MASK;
> - }
> + plane_wm->wm[level].plane_en = is_enabled;
> + plane_wm->wm[level].plane_res_b = val &
> PLANE_WM_BLOCKS_MASK;
> + plane_wm->wm[level].plane_res_l =
> + (val >> PLANE_WM_LINES_SHIFT) &
> PLANE_WM_LINES_MASK;
>  } else {
> - if (!is_cursor) {
> - active->planes[i].trans_wm.plane_en =
> is_enabled;
> - active->planes[i].trans_wm.plane_res_b =
> - val & PLANE_WM_BLOCKS_MASK;
> - active->planes[i].trans_wm.plane_res_l =
> - (val >> PLANE_WM_LINES_SHIFT) &
> - PLANE_WM_LINES_MASK;
> - } else {
> - active-
> >planes[PLANE_CURSOR].trans_wm.plane_en =
> - is_enabled;
> - active-
> >planes[PLANE_CURSOR].trans_wm.plane_res_b =
> - val & PLANE_WM_BLOCKS_MASK;
> - active-
> >planes[PLANE_CURSOR].trans_wm.plane_res_l =
> - (val >> PLANE_WM_LINES_SHIFT) &
> - PLANE_WM_LINES_MASK;
> - }
> + plane_wm->trans_wm.plane_en = is_enabled;
> + plane_wm->trans_wm.plane_res_b = val &
> PLANE_WM_BLOCKS_MASK;
> + plane_wm->trans_wm.plane_res_l =
> + (val >> PLANE_WM_LINES_SHIFT) &
> PLANE_WM_LINES_MASK;
>  }
>  }
>  
> @@ -4345,20 +4321,20 @@ static void skl_pipe_wm_get_hw_state(struct
> drm_crtc *crtc)
>  for (level = 0; level <= max_level; level++) {
>  for (i = 0; i < intel_num_planes(intel_crtc); i++) {
>  temp = hw->plane[pipe][i][level];
> - skl_pipe_wm_active_state(temp, active,
> false,
> - false, i, level);
> + skl_pipe_wm_active_state(temp, active,
> false, i, level);
>  }
>  temp = hw->plane[pipe][PLANE_CURSOR][level];
> - skl_pipe_wm_active_state(temp, active, false, true,
> i, level);
> + skl_pipe_wm_active_state(temp, active, false,
> PLANE_CURSOR,
> +  level);
>  }
>  
>  for (i = 0; i < intel_num_planes(intel_crtc); i++) {
>  temp = hw->plane_trans[pipe][i];
> - skl_pipe_wm_active_state(temp, active, true, false,
> i, 0);
> + skl_pipe_wm_active_state(temp, active, true, i, 0);
>  }
>  
>  temp = hw->plane_trans[pipe][PLANE_CURSOR];
> - 

[PATCH v2 03/10] drm/i915/gen9: Make skl_wm_level per-plane

[Paulo Zanoni]

Em Sex, 2016-10-07 às 20:11 -0400, Lyude escreveu:
> Having skl_wm_level contain all of the watermarks for each plane is
> annoying since it prevents us from having any sort of object to
> represent a single watermark level, something we take advantage of in
> the next commit to cut down on all of the copy paste code in here.
> 
> Changes since v1:
> - Style nitpicks
> - Fix accidental usage of i vs. PLANE_CURSOR
> - Split out skl_pipe_wm_active_state simplification into separate
> patch
> 
> Signed-off-by: Lyude 

Reviewed-by: Paulo Zanoni 

> Reviewed-by: Maarten Lankhorst 
> Cc: Ville Syrjälä 
> Cc: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |   6 +-
>  drivers/gpu/drm/i915/intel_drv.h |   6 +-
>  drivers/gpu/drm/i915/intel_pm.c  | 207 +++
> 
>  3 files changed, 111 insertions(+), 108 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
> index e9d035ea..0287c93 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1649,9 +1649,9 @@ struct skl_wm_values {
>  };
>  
>  struct skl_wm_level {
> - bool plane_en[I915_MAX_PLANES];
> - uint16_t plane_res_b[I915_MAX_PLANES];
> - uint8_t plane_res_l[I915_MAX_PLANES];
> + bool plane_en;
> + uint16_t plane_res_b;
> + uint8_t plane_res_l;
>  };
>  
>  /*
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 35ba282..d684f4f 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -468,9 +468,13 @@ struct intel_pipe_wm {
>  bool sprites_scaled;
>  };
>  
> -struct skl_pipe_wm {
> +struct skl_plane_wm {
>  struct skl_wm_level wm[8];
>  struct skl_wm_level trans_wm;
> +};
> +
> +struct skl_pipe_wm {
> + struct skl_plane_wm planes[I915_MAX_PLANES];
>  uint32_t linetime;
>  };
>  
> diff --git a/drivers/gpu/drm/i915/intel_pm.c
> b/drivers/gpu/drm/i915/intel_pm.c
> index cc5d5e9..4c2ebcd 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3670,67 +3670,52 @@ static int
>  skl_compute_wm_level(const struct drm_i915_private *dev_priv,
>       struct skl_ddb_allocation *ddb,
>       struct intel_crtc_state *cstate,
> +      struct intel_plane *intel_plane,
>       int level,
>       struct skl_wm_level *result)
>  {
>  struct drm_atomic_state *state = cstate->base.state;
>  struct intel_crtc *intel_crtc = to_intel_crtc(cstate-
> >base.crtc);
> - struct drm_plane *plane;
> - struct intel_plane *intel_plane;
> - struct intel_plane_state *intel_pstate;
> + struct drm_plane *plane = _plane->base;
> + struct intel_plane_state *intel_pstate = NULL;
>  uint16_t ddb_blocks;
>  enum pipe pipe = intel_crtc->pipe;
>  int ret;
> + int i = skl_wm_plane_id(intel_plane);
> +
> + if (state)
> + intel_pstate =
> + intel_atomic_get_existing_plane_state(state,
> +       intel_
> plane);
>  
>  /*
> -  * We'll only calculate watermarks for planes that are
> actually
> -  * enabled, so make sure all other planes are set as
> disabled.
> +  * Note: If we start supporting multiple pending atomic
> commits against
> +  * the same planes/CRTC's in the future, plane->state will
> no longer be
> +  * the correct pre-state to use for the calculations here
> and we'll
> +  * need to change where we get the 'unchanged' plane data
> from.
> +  *
> +  * For now this is fine because we only allow one queued
> commit against
> +  * a CRTC.  Even if the plane isn't modified by this
> transaction and we
> +  * don't have a plane lock, we still have the CRTC's lock,
> so we know
> +  * that no other transactions are racing with us to update
> it.
>   */
> - memset(result, 0, sizeof(*result));
> + if (!intel_pstate)
> + intel_pstate = to_intel_plane_state(plane->state);
>  
> - for_each_intel_plane_mask(_priv->drm,
> -   intel_plane,
> -   cstate->base.plane_mask) {
> - int i = skl_wm_plane_id(intel_plane);
> -
> - plane = _plane->base;
> - intel_pstate = NULL;
> - if (state)
> - intel_pstate =
> - intel_atomic_get_existing_plane_stat
> e(state,
> -     
>   intel_plane);
> + WARN_ON(!intel_pstate->base.fb);
>  
> - /*
> -  * Note: If we start supporting multiple pending
> atomic commits
> -  * against the same planes/CRTC's in the future,
> plane->state
> -  * will no longer be the correct 

[Intel-gfx] [PATCH v2 01/10] drm/i915/skl: Move per-pipe ddb allocations into crtc states

[Paulo Zanoni]

Em Sex, 2016-10-07 às 20:11 -0400, Lyude escreveu:
> First part of cleaning up all of the skl watermark code. This moves
> the
> structures for storing the ddb allocations of each pipe into
> intel_crtc_state, along with moving the structures for storing the
> current ddb allocations active on hardware into intel_crtc.
> 
> Changes since v1:
> - Don't replace alloc->start = alloc->end = 0;
> 
> Signed-off-by: Lyude 

Reviewed-by: Paulo Zanoni 

> Reviewed-by: Maarten Lankhorst 
> Cc: Ville Syrjälä 
> Cc: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/i915_drv.h      |  1 -
>  drivers/gpu/drm/i915/intel_display.c | 16 ---
>  drivers/gpu/drm/i915/intel_drv.h     |  8 +---
>  drivers/gpu/drm/i915/intel_pm.c      | 40 +++---
> --
>  4 files changed, 30 insertions(+), 35 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
> index a219a35..bb2de8d 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1637,7 +1637,6 @@ static inline bool skl_ddb_entry_equal(const
> struct skl_ddb_entry *e1,
>  }
>  
>  struct skl_ddb_allocation {
> - struct skl_ddb_entry pipe[I915_MAX_PIPES];
>  struct skl_ddb_entry plane[I915_MAX_PIPES][I915_MAX_PLANES];
> /* packed/uv */
>  struct skl_ddb_entry
> y_plane[I915_MAX_PIPES][I915_MAX_PLANES];
>  };
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index a366656..17733af 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14235,12 +14235,11 @@ static void skl_update_crtcs(struct
> drm_atomic_state *state,
>       unsigned int *crtc_vblank_mask)
>  {
>  struct drm_device *dev = state->dev;
> - struct drm_i915_private *dev_priv = to_i915(dev);
>  struct intel_atomic_state *intel_state =
> to_intel_atomic_state(state);
>  struct drm_crtc *crtc;
> + struct intel_crtc *intel_crtc;
>  struct drm_crtc_state *old_crtc_state;
> - struct skl_ddb_allocation *new_ddb = _state-
> >wm_results.ddb;
> - struct skl_ddb_allocation *cur_ddb = _priv-
> >wm.skl_hw.ddb;
> + struct intel_crtc_state *cstate;
>  unsigned int updated = 0;
>  bool progress;
>  enum pipe pipe;
> @@ -14258,12 +14257,14 @@ static void skl_update_crtcs(struct
> drm_atomic_state *state,
>  for_each_crtc_in_state(state, crtc, old_crtc_state,
> i) {
>  bool vbl_wait = false;
>  unsigned int cmask = drm_crtc_mask(crtc);
> - pipe = to_intel_crtc(crtc)->pipe;
> +
> + intel_crtc = to_intel_crtc(crtc);
> + cstate = to_intel_crtc_state(crtc->state);
> + pipe = intel_crtc->pipe;
>  
>  if (updated & cmask || !crtc->state->active)
>  continue;
> - if (skl_ddb_allocation_overlaps(state,
> cur_ddb, new_ddb,
> - pipe))
> + if (skl_ddb_allocation_overlaps(state,
> intel_crtc))
>  continue;
>  
>  updated |= cmask;
> @@ -14274,7 +14275,8 @@ static void skl_update_crtcs(struct
> drm_atomic_state *state,
>   * then we need to wait for a vblank to pass
> for the
>   * new ddb allocation to take effect.
>   */
> - if (!skl_ddb_allocation_equals(cur_ddb,
> new_ddb, pipe) &&
> + if (!skl_ddb_entry_equal(
> >wm.skl.ddb,
> +  _crtc-
> >hw_ddb) &&
>      !crtc->state->active_changed &&
>      intel_state->wm_results.dirty_pipes !=
> updated)
>  vbl_wait = true;
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index f48e79a..35ba282 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -496,6 +496,7 @@ struct intel_crtc_wm_state {
>  struct {
>  /* gen9+ only needs 1-step wm programming */
>  struct skl_pipe_wm optimal;
> + struct skl_ddb_entry ddb;
>  
>  /* cached plane data rate */
>  unsigned plane_data_rate[I915_MAX_PLANES];
> @@ -733,6 +734,9 @@ struct intel_crtc {
>  bool cxsr_allowed;
>  } wm;
>  
> + /* gen9+: ddb allocation currently being used */
> + struct skl_ddb_entry hw_ddb;
> +
>  int scanline_offset;
>  
>  struct {
> @@ -1755,9 +1759,7 @@ bool skl_ddb_allocation_equals(const struct
> skl_ddb_allocation *old,
>         const struct skl_ddb_allocation *new,
>      

[Bug 98200] [radeon] kernel hangs during shutdown - drm-next-4.9-/+wip

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

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

--- Comment #3 from Alex Deucher  ---
Created attachment 127220
  --> https://bugs.freedesktop.org/attachment.cgi?id=127220=edit
patch 2/2

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

[Bug 98200] [radeon] kernel hangs during shutdown - drm-next-4.9-/+wip

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

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

--- Comment #2 from Alex Deucher  ---
Created attachment 127219
  --> https://bugs.freedesktop.org/attachment.cgi?id=127219=edit
patch 1/2

The attached patches fix the issue.

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

[RFC] drm/fb-helper: reject any changes to the fbdev

[Stefan Agner]

The current fbdev emulation does not allow to push back changes in
width, height or depth to KMS, hence reject any changes with an
error. This makes sure that fbdev ioctl's fail properly and user
space does not assume that changes succeeded.

Signed-off-by: Stefan Agner 
---
This rejects reconfiguration of framebuffer like
fbset -rgba 5,6,5 -depth 16 (when in 24 bit mode by default)
fbset -xres 123

I think all users of drm_fb_helper_check_var use also the generic
drm_fb_helper_set_par (or do otherwise not support changing size/
depth). Hence, afaict, the change should be the right thing to do
for all driver...

 drivers/gpu/drm/drm_fb_helper.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 03414bd..596c056 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1211,11 +1211,14 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo 
*var,
if (var->pixclock != 0 || in_dbg_master())
return -EINVAL;

-   /* Need to resize the fb object !!! */
-   if (var->bits_per_pixel > fb->bits_per_pixel ||
-   var->xres > fb->width || var->yres > fb->height ||
-   var->xres_virtual > fb->width || var->yres_virtual > fb->height) {
-   DRM_DEBUG("fb userspace requested width/height/bpp is greater 
than current fb "
+   /*
+* Changes struct fb_var_screeninfo are currently not pushed back
+* to KMS, hence fail if different settings are requested.
+*/
+   if (var->bits_per_pixel != fb->bits_per_pixel ||
+   var->xres != fb->width || var->yres != fb->height ||
+   var->xres_virtual != fb->width || var->yres_virtual != fb->height) {
+   DRM_DEBUG("fb userspace requested width/height/bpp different 
than current fb "
  "request %dx%d-%d (virtual %dx%d) > %dx%d-%d\n",
  var->xres, var->yres, var->bits_per_pixel,
  var->xres_virtual, var->yres_virtual,
-- 
2.10.0

[Bug 155711] Aorus X5, Backlight hotkeys non-functional

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

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

--- Comment #11 from seqrteam at gmail.com ---
Just a gentle bump on this -- any ideas if it's possible to fix this issue, or
if one should be looking elsewhere for help with this (e.g. complaining to
NVidia)?  Let me know if there is any additional info I can provide.

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

[PATCH 1/8] drm: mali-dp: Set the drm->irq_enabled flag to match driver's state.

[liviu.du...@arm.com]

On Tue, Oct 11, 2016 at 03:26:02PM +0100, Brian Starkey wrote:
> From: Liviu Dudau 
> 
> Mali DP driver does not use drm_irq_{un,}install() function so the
> drm->irq_enabled flag does not get set automatically.
> drm_wait_vblank() checks the value of the flag among other functions.
> 
> Signed-off-by: Liviu Dudau 
> ---
> 
> Hi,
> 
> This series is a bunch of small driver-internal fixes and cleanup for
> Mali-DP.

For the whole series, on the patches not already Signed-off-by me or acked:

Acked-by: Liviu Dudau 

Many thanks,
Liviu

> 
> -Brian
> 
>  drivers/gpu/drm/arm/malidp_drv.c |3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c 
> b/drivers/gpu/drm/arm/malidp_drv.c
> index 9280358..7987ebd 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -377,6 +377,8 @@ static int malidp_bind(struct device *dev)
>   if (ret < 0)
>   goto irq_init_fail;
>  
> + drm->irq_enabled = true;
> +
>   ret = drm_vblank_init(drm, drm->mode_config.num_crtc);
>   if (ret < 0) {
>   DRM_ERROR("failed to initialise vblank\n");
> @@ -402,6 +404,7 @@ fbdev_fail:
>  vblank_fail:
>   malidp_se_irq_fini(drm);
>   malidp_de_irq_fini(drm);
> + drm->irq_enabled = false;
>  irq_init_fail:
>   component_unbind_all(dev, drm);
>  bind_fail:
> -- 
> 1.7.9.5
> 

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯

[PATCH] drm/amd/powerplay: don't give up if DPM is already running

[Alex Deucher]

+Rex to review this.

Alex

On Sun, Oct 9, 2016 at 3:23 PM, Grazvydas Ignotas  wrote:
> Currently the driver crashes if smu7_enable_dpm_tasks() returns early,
> which it does if DPM is already active. It seems to be better just to
> continue anyway, at least I haven't noticed any ill effects. It's also
> unclear at what state the hardware was left by the previous driver, so
> IMO it's better to always fully initialize.
>
> Way to reproduce:
> $ modprobe amdgpu
> $ rmmod amdgpu
> $ modprobe amdgpu
> ...
> DPM is already running right now, no need to enable DPM!
> ...
> failed to send message 18b ret is 0
> BUG: unable to handle kernel paging request at ed01fc9ab21f
> Call Trace:
>  smu7_set_power_state_tasks+0x499/0x1940 [amdgpu]
>  phm_set_power_state+0xcb/0x120 [amdgpu]
>  psm_adjust_power_state_dynamic+0x11e/0x1b0 [amdgpu]
>  pem_task_adjust_power_state+0xb9/0xd0 [amdgpu]
>  pem_excute_event_chain+0x7d/0xe0 [amdgpu]
>  pem_handle_event_unlocked+0x49/0x60 [amdgpu]
>  pem_handle_event+0xe/0x10 [amdgpu]
>  pp_dpm_dispatch_tasks+0xe0/0x190 [amdgpu]
>  amdgpu_pm_compute_clocks+0x10c/0xc60 [amdgpu]
>  dce_v11_0_crtc_dpms+0x7d/0x150 [amdgpu]
>  dce_v11_0_crtc_disable+0x90/0x4a0 [amdgpu]
>  drm_helper_disable_unused_functions+0x67/0x80 [drm_kms_helper]
>  amdgpu_fbdev_init+0x13e/0x170 [amdgpu]
>  amdgpu_device_init+0x1aeb/0x2490 [amdgpu]
>
> Signed-off-by: Grazvydas Ignotas 
> ---
>  drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c 
> b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
> index f6afa6a..327030b 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
> @@ -1166,8 +1166,8 @@ static int smu7_enable_dpm_tasks(struct pp_hwmgr *hwmgr)
>
> tmp_result = (!smum_is_dpm_running(hwmgr)) ? 0 : -1;
> PP_ASSERT_WITH_CODE(tmp_result == 0,
> -   "DPM is already running right now, no need to enable 
> DPM!",
> -   return 0);
> +   "DPM is already running",
> +   );
>
> if (smu7_voltage_control(hwmgr)) {
> tmp_result = smu7_enable_voltage_control(hwmgr);
> --
> 2.7.4
>
> ___
> amd-gfx mailing list
> amd-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[RFC PATCH 11/11] drm: mali-dp: Add writeback connector

[Brian Starkey]

Mali-DP has a memory writeback engine which can be used to write the
composition result to a memory buffer.
Expose this functionality as a DRM writeback connector on supported
hardware.

Signed-off-by: Brian Starkey 
---
 drivers/gpu/drm/arm/Makefile  |1 +
 drivers/gpu/drm/arm/malidp_crtc.c |   10 ++
 drivers/gpu/drm/arm/malidp_drv.c  |   25 +++-
 drivers/gpu/drm/arm/malidp_drv.h  |5 +
 drivers/gpu/drm/arm/malidp_mw.c   |  268 +
 5 files changed, 305 insertions(+), 4 deletions(-)
 create mode 100644 drivers/gpu/drm/arm/malidp_mw.c

diff --git a/drivers/gpu/drm/arm/Makefile b/drivers/gpu/drm/arm/Makefile
index bb8b158..3bf31d1 100644
--- a/drivers/gpu/drm/arm/Makefile
+++ b/drivers/gpu/drm/arm/Makefile
@@ -1,4 +1,5 @@
 hdlcd-y := hdlcd_drv.o hdlcd_crtc.o
 obj-$(CONFIG_DRM_HDLCD)+= hdlcd.o
 mali-dp-y := malidp_drv.o malidp_hw.o malidp_planes.o malidp_crtc.o
+mali-dp-y += malidp_mw.o
 obj-$(CONFIG_DRM_MALI_DISPLAY) += mali-dp.o
diff --git a/drivers/gpu/drm/arm/malidp_crtc.c 
b/drivers/gpu/drm/arm/malidp_crtc.c
index 08e6a71..98ddcea 100644
--- a/drivers/gpu/drm/arm/malidp_crtc.c
+++ b/drivers/gpu/drm/arm/malidp_crtc.c
@@ -68,6 +68,16 @@ static void malidp_crtc_enable(struct drm_crtc *crtc)
clk_set_rate(hwdev->pxlclk, crtc->state->adjusted_mode.crtc_clock * 
1000);

hwdev->modeset(hwdev, );
+   /*
+* We should always disable the memory write when leaving config mode,
+* otherwise the hardware will start writing right away - possibly with
+* a stale config, and definitely before we've had a chance to configure
+* the planes.
+* If the memory write needs to be enabled, that will get taken care
+* of later during the atomic commit
+*/
+   if (hwdev->disable_memwrite)
+   hwdev->disable_memwrite(hwdev);
hwdev->leave_config_mode(hwdev);
drm_crtc_vblank_on(crtc);
 }
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 62a29f6..e20266e 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -91,7 +91,16 @@ static void malidp_atomic_commit_tail(struct 
drm_atomic_state *state)
struct drm_device *drm = state->dev;

drm_atomic_helper_commit_modeset_disables(drm, state);
+
drm_atomic_helper_commit_modeset_enables(drm, state);
+
+   /*
+* The order here is important. We must configure memory-write after
+* the CRTC is already enabled, so that its configuration update is
+* gated on the next CVAL.
+*/
+   malidp_mw_atomic_commit(drm, state);
+
drm_atomic_helper_commit_planes(drm, state,
DRM_PLANE_COMMIT_ACTIVE_ONLY);

@@ -148,12 +157,20 @@ static int malidp_init(struct drm_device *drm)
drm->mode_config.helper_private = _mode_config_helpers;

ret = malidp_crtc_init(drm);
-   if (ret) {
-   drm_mode_config_cleanup(drm);
-   return ret;
-   }
+   if (ret)
+   goto crtc_fail;
+
+   ret = malidp_mw_connector_init(drm);
+   if (ret)
+   goto mw_fail;

return 0;
+
+mw_fail:
+   malidp_de_planes_destroy(drm);
+crtc_fail:
+   drm_mode_config_cleanup(drm);
+   return ret;
 }

 static void malidp_fini(struct drm_device *drm)
diff --git a/drivers/gpu/drm/arm/malidp_drv.h b/drivers/gpu/drm/arm/malidp_drv.h
index 9fc8a2e..905c104 100644
--- a/drivers/gpu/drm/arm/malidp_drv.h
+++ b/drivers/gpu/drm/arm/malidp_drv.h
@@ -22,6 +22,8 @@ struct malidp_drm {
struct drm_fbdev_cma *fbdev;
struct list_head event_list;
struct drm_crtc crtc;
+   struct drm_encoder mw_encoder;
+   struct drm_connector mw_connector;
wait_queue_head_t wq;
atomic_t config_valid;
 };
@@ -50,6 +52,9 @@ struct malidp_plane_state {
 int malidp_de_planes_init(struct drm_device *drm);
 void malidp_de_planes_destroy(struct drm_device *drm);
 int malidp_crtc_init(struct drm_device *drm);
+int malidp_mw_connector_init(struct drm_device *drm);
+void malidp_mw_atomic_commit(struct drm_device *drm,
+struct drm_atomic_state *old_state);

 /* often used combination of rotational bits */
 #define MALIDP_ROTATED_MASK(DRM_ROTATE_90 | DRM_ROTATE_270)
diff --git a/drivers/gpu/drm/arm/malidp_mw.c b/drivers/gpu/drm/arm/malidp_mw.c
new file mode 100644
index 000..72df3fd
--- /dev/null
+++ b/drivers/gpu/drm/arm/malidp_mw.c
@@ -0,0 +1,268 @@
+/*
+ * (C) COPYRIGHT 2016 ARM Limited. All rights reserved.
+ * Author: Brian Starkey 
+ *
+ * This program is free software and is provided to you under the terms of the
+ * GNU General Public License version 2 as published by the Free Software
+ * Foundation, and any use by you of this program is subject to the terms
+ * of such GNU licence.
+ *
+ * ARM Mali DP Writeback connector implementation
+ */
+#include 
+#include 
+#include 

[RFC PATCH 10/11] drm: mali-dp: Add support for writeback on DP550/DP650

[Brian Starkey]

From: Liviu Dudau 

Mali-DP display processors are able to write the composition result to a
memory buffer via the SE.

Add entry points in the HAL for enabling/disabling this feature, and
implement support for it on DP650 and DP550. DP500 acts differently and
so is omitted from this change.

Signed-off-by: Liviu Dudau 
Signed-off-by: Brian Starkey 
---
 drivers/gpu/drm/arm/malidp_hw.c   |   52 +++--
 drivers/gpu/drm/arm/malidp_hw.h   |   18 +
 drivers/gpu/drm/arm/malidp_regs.h |   15 +++
 3 files changed, 83 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index 5235d0b..dee7605 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -387,6 +387,48 @@ static int malidp550_rotmem_required(struct 
malidp_hw_device *hwdev, u16 w, u16
return w * bytes_per_col;
 }

+static int malidp550_enable_memwrite(struct malidp_hw_device *hwdev,
+dma_addr_t *addrs, s32 *pitches,
+int num_planes, u16 w, u16 h, u32 fmt_id)
+{
+   u32 base = MALIDP550_SE_MEMWRITE_BASE;
+   u32 de_base = malidp_get_block_base(hwdev, MALIDP_DE_BLOCK);
+
+   /* enable the scaling engine block */
+   malidp_hw_setbits(hwdev, MALIDP_SCALE_ENGINE_EN, de_base + 
MALIDP_DE_DISPLAY_FUNC);
+
+   malidp_hw_write(hwdev, fmt_id, base + MALIDP_MW_FORMAT);
+   switch (num_planes) {
+   case 2:
+   malidp_hw_write(hwdev, lower_32_bits(addrs[1]), base + 
MALIDP_MW_P2_PTR_LOW);
+   malidp_hw_write(hwdev, upper_32_bits(addrs[1]), base + 
MALIDP_MW_P2_PTR_HIGH);
+   malidp_hw_write(hwdev, pitches[1], base + MALIDP_MW_P2_STRIDE);
+   /* fall through */
+   case 1:
+   malidp_hw_write(hwdev, lower_32_bits(addrs[0]), base + 
MALIDP_MW_P1_PTR_LOW);
+   malidp_hw_write(hwdev, upper_32_bits(addrs[0]), base + 
MALIDP_MW_P1_PTR_HIGH);
+   malidp_hw_write(hwdev, pitches[0], base + MALIDP_MW_P1_STRIDE);
+   break;
+   default:
+   WARN(1, "Invalid number of planes");
+   }
+
+   malidp_hw_write(hwdev, MALIDP_DE_H_ACTIVE(w) | MALIDP_DE_V_ACTIVE(h),
+   MALIDP550_SE_MEMWRITE_OUT_SIZE);
+   malidp_hw_setbits(hwdev, MALIDP550_SE_MEMWRITE_ONESHOT | 
MALIDP_SE_MEMWRITE_EN,
+ MALIDP550_SE_CONTROL);
+
+   return 0;
+}
+
+static void malidp550_disable_memwrite(struct malidp_hw_device *hwdev)
+{
+   u32 base = malidp_get_block_base(hwdev, MALIDP_DE_BLOCK);
+   malidp_hw_clearbits(hwdev, MALIDP550_SE_MEMWRITE_ONESHOT | 
MALIDP_SE_MEMWRITE_EN,
+   MALIDP550_SE_CONTROL);
+   malidp_hw_clearbits(hwdev, MALIDP_SCALE_ENGINE_EN, base + 
MALIDP_DE_DISPLAY_FUNC);
+}
+
 static int malidp650_query_hw(struct malidp_hw_device *hwdev)
 {
u32 conf = malidp_hw_read(hwdev, MALIDP550_CONFIG_ID);
@@ -469,7 +511,8 @@ const struct malidp_hw_device 
malidp_device[MALIDP_MAX_DEVICES] = {
MALIDP550_SE_IRQ_AXI_ERR,
},
.dc_irq_map = {
-   .irq_mask = MALIDP550_DC_IRQ_CONF_VALID,
+   .irq_mask = MALIDP550_DC_IRQ_CONF_VALID |
+   MALIDP550_DC_IRQ_SE,
.vsync_irq = MALIDP550_DC_IRQ_CONF_VALID,
},
.pixel_formats = malidp550_de_formats,
@@ -483,6 +526,8 @@ const struct malidp_hw_device 
malidp_device[MALIDP_MAX_DEVICES] = {
.set_config_valid = malidp550_set_config_valid,
.modeset = malidp550_modeset,
.rotmem_required = malidp550_rotmem_required,
+   .enable_memwrite = malidp550_enable_memwrite,
+   .disable_memwrite = malidp550_disable_memwrite,
},
[MALIDP_650] = {
.map = {
@@ -503,7 +548,8 @@ const struct malidp_hw_device 
malidp_device[MALIDP_MAX_DEVICES] = {
MALIDP550_SE_IRQ_AXI_ERR,
},
.dc_irq_map = {
-   .irq_mask = MALIDP550_DC_IRQ_CONF_VALID,
+   .irq_mask = MALIDP550_DC_IRQ_CONF_VALID |
+   MALIDP550_DC_IRQ_SE,
.vsync_irq = MALIDP550_DC_IRQ_CONF_VALID,
},
.pixel_formats = malidp550_de_formats,
@@ -517,6 +563,8 @@ const struct malidp_hw_device 
malidp_device[MALIDP_MAX_DEVICES] = {
.set_config_valid = malidp550_set_config_valid,
.modeset = malidp550_modeset,
.rotmem_required = malidp550_rotmem_required,
+   .enable_memwrite = 

[RFC PATCH 09/11] drm: mali-dp: Add RGB writeback formats for DP550/DP650

[Brian Starkey]

Add a layer bit for the SE memory-write, and add it to the pixel format
matrix for DP550/DP650.

Signed-off-by: Brian Starkey 
---
 drivers/gpu/drm/arm/malidp_hw.c |   28 ++--
 drivers/gpu/drm/arm/malidp_hw.h |1 +
 2 files changed, 15 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index 44a9d10..5235d0b 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -46,20 +46,20 @@ static const struct malidp_format_id malidp500_de_formats[] 
= {

 #define MALIDP_COMMON_FORMATS \
/*fourcc,   layers supporting the format,  internal id   */ \
-   { DRM_FORMAT_ARGB2101010, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2, 
MALIDP_ID(0, 0) }, \
-   { DRM_FORMAT_ABGR2101010, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2, 
MALIDP_ID(0, 1) }, \
-   { DRM_FORMAT_RGBA1010102, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2, 
MALIDP_ID(0, 2) }, \
-   { DRM_FORMAT_BGRA1010102, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2, 
MALIDP_ID(0, 3) }, \
-   { DRM_FORMAT_ARGB, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2 | DE_SMART, 
MALIDP_ID(1, 0) }, \
-   { DRM_FORMAT_ABGR, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2 | DE_SMART, 
MALIDP_ID(1, 1) }, \
-   { DRM_FORMAT_RGBA, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2 | DE_SMART, 
MALIDP_ID(1, 2) }, \
-   { DRM_FORMAT_BGRA, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2 | DE_SMART, 
MALIDP_ID(1, 3) }, \
-   { DRM_FORMAT_XRGB, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2 | DE_SMART, 
MALIDP_ID(2, 0) }, \
-   { DRM_FORMAT_XBGR, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2 | DE_SMART, 
MALIDP_ID(2, 1) }, \
-   { DRM_FORMAT_RGBX, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2 | DE_SMART, 
MALIDP_ID(2, 2) }, \
-   { DRM_FORMAT_BGRX, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2 | DE_SMART, 
MALIDP_ID(2, 3) }, \
-   { DRM_FORMAT_RGB888, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2, MALIDP_ID(3, 
0) }, \
-   { DRM_FORMAT_BGR888, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2, MALIDP_ID(3, 
1) }, \
+   { DRM_FORMAT_ARGB2101010, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2 | 
SE_MEMWRITE, MALIDP_ID(0, 0) }, \
+   { DRM_FORMAT_ABGR2101010, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2 | 
SE_MEMWRITE, MALIDP_ID(0, 1) }, \
+   { DRM_FORMAT_RGBA1010102, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2 | 
SE_MEMWRITE, MALIDP_ID(0, 2) }, \
+   { DRM_FORMAT_BGRA1010102, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2 | 
SE_MEMWRITE, MALIDP_ID(0, 3) }, \
+   { DRM_FORMAT_ARGB, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2 | DE_SMART 
| SE_MEMWRITE, MALIDP_ID(1, 0) }, \
+   { DRM_FORMAT_ABGR, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2 | DE_SMART 
| SE_MEMWRITE, MALIDP_ID(1, 1) }, \
+   { DRM_FORMAT_RGBA, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2 | DE_SMART 
| SE_MEMWRITE, MALIDP_ID(1, 2) }, \
+   { DRM_FORMAT_BGRA, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2 | DE_SMART 
| SE_MEMWRITE, MALIDP_ID(1, 3) }, \
+   { DRM_FORMAT_XRGB, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2 | DE_SMART 
| SE_MEMWRITE, MALIDP_ID(2, 0) }, \
+   { DRM_FORMAT_XBGR, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2 | DE_SMART 
| SE_MEMWRITE, MALIDP_ID(2, 1) }, \
+   { DRM_FORMAT_RGBX, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2 | DE_SMART 
| SE_MEMWRITE, MALIDP_ID(2, 2) }, \
+   { DRM_FORMAT_BGRX, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2 | DE_SMART 
| SE_MEMWRITE, MALIDP_ID(2, 3) }, \
+   { DRM_FORMAT_RGB888, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2 | 
SE_MEMWRITE, MALIDP_ID(3, 0) }, \
+   { DRM_FORMAT_BGR888, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2 | 
SE_MEMWRITE, MALIDP_ID(3, 1) }, \
{ DRM_FORMAT_RGBA5551, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2, 
MALIDP_ID(4, 0) }, \
{ DRM_FORMAT_ABGR1555, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2, 
MALIDP_ID(4, 1) }, \
{ DRM_FORMAT_RGB565, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2, MALIDP_ID(4, 
2) }, \
diff --git a/drivers/gpu/drm/arm/malidp_hw.h b/drivers/gpu/drm/arm/malidp_hw.h
index 4f8c884..ce4ea55 100644
--- a/drivers/gpu/drm/arm/malidp_hw.h
+++ b/drivers/gpu/drm/arm/malidp_hw.h
@@ -33,6 +33,7 @@ enum {
DE_GRAPHICS2 = BIT(2), /* used only in DP500 */
DE_VIDEO2 = BIT(3),
DE_SMART = BIT(4),
+   SE_MEMWRITE = BIT(5),
 };

 struct malidp_format_id {
-- 
1.7.9.5

[RFC PATCH 08/11] drm: mali-dp: Rename malidp_input_format

[Brian Starkey]

We're going to use the same format list for output formats, so rename
everything related to input formats to avoid confusion.

Signed-off-by: Brian Starkey 
Reviewed-by: Liviu Dudau 
---
 drivers/gpu/drm/arm/malidp_hw.c |   24 
 drivers/gpu/drm/arm/malidp_hw.h |8 
 drivers/gpu/drm/arm/malidp_planes.c |8 
 3 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index 7f4a0bd..44a9d10 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -21,7 +21,7 @@
 #include "malidp_drv.h"
 #include "malidp_hw.h"

-static const struct malidp_input_format malidp500_de_formats[] = {
+static const struct malidp_format_id malidp500_de_formats[] = {
/*fourcc,   layers supporting the format, internal id  */
{ DRM_FORMAT_ARGB2101010, DE_VIDEO1 | DE_GRAPHICS1 | DE_GRAPHICS2,  0 },
{ DRM_FORMAT_ABGR2101010, DE_VIDEO1 | DE_GRAPHICS1 | DE_GRAPHICS2,  1 },
@@ -69,7 +69,7 @@ static const struct malidp_input_format 
malidp500_de_formats[] = {
{ DRM_FORMAT_NV12, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 6) },\
{ DRM_FORMAT_YUV420, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 7) }

-static const struct malidp_input_format malidp550_de_formats[] = {
+static const struct malidp_format_id malidp550_de_formats[] = {
MALIDP_COMMON_FORMATS,
 };

@@ -439,8 +439,8 @@ const struct malidp_hw_device 
malidp_device[MALIDP_MAX_DEVICES] = {
.irq_mask = MALIDP500_DE_IRQ_CONF_VALID,
.vsync_irq = MALIDP500_DE_IRQ_CONF_VALID,
},
-   .input_formats = malidp500_de_formats,
-   .n_input_formats = ARRAY_SIZE(malidp500_de_formats),
+   .pixel_formats = malidp500_de_formats,
+   .n_pixel_formats = ARRAY_SIZE(malidp500_de_formats),
.bus_align_bytes = 8,
},
.query_hw = malidp500_query_hw,
@@ -472,8 +472,8 @@ const struct malidp_hw_device 
malidp_device[MALIDP_MAX_DEVICES] = {
.irq_mask = MALIDP550_DC_IRQ_CONF_VALID,
.vsync_irq = MALIDP550_DC_IRQ_CONF_VALID,
},
-   .input_formats = malidp550_de_formats,
-   .n_input_formats = ARRAY_SIZE(malidp550_de_formats),
+   .pixel_formats = malidp550_de_formats,
+   .n_pixel_formats = ARRAY_SIZE(malidp550_de_formats),
.bus_align_bytes = 8,
},
.query_hw = malidp550_query_hw,
@@ -506,8 +506,8 @@ const struct malidp_hw_device 
malidp_device[MALIDP_MAX_DEVICES] = {
.irq_mask = MALIDP550_DC_IRQ_CONF_VALID,
.vsync_irq = MALIDP550_DC_IRQ_CONF_VALID,
},
-   .input_formats = malidp550_de_formats,
-   .n_input_formats = ARRAY_SIZE(malidp550_de_formats),
+   .pixel_formats = malidp550_de_formats,
+   .n_pixel_formats = ARRAY_SIZE(malidp550_de_formats),
.bus_align_bytes = 16,
},
.query_hw = malidp650_query_hw,
@@ -525,10 +525,10 @@ u8 malidp_hw_get_format_id(const struct malidp_hw_regmap 
*map,
 {
unsigned int i;

-   for (i = 0; i < map->n_input_formats; i++) {
-   if (((map->input_formats[i].layer & layer_id) == layer_id) &&
-   (map->input_formats[i].format == format))
-   return map->input_formats[i].id;
+   for (i = 0; i < map->n_pixel_formats; i++) {
+   if (((map->pixel_formats[i].layer & layer_id) == layer_id) &&
+   (map->pixel_formats[i].format == format))
+   return map->pixel_formats[i].id;
}

return MALIDP_INVALID_FORMAT_ID;
diff --git a/drivers/gpu/drm/arm/malidp_hw.h b/drivers/gpu/drm/arm/malidp_hw.h
index 087e1202..4f8c884 100644
--- a/drivers/gpu/drm/arm/malidp_hw.h
+++ b/drivers/gpu/drm/arm/malidp_hw.h
@@ -35,7 +35,7 @@ enum {
DE_SMART = BIT(4),
 };

-struct malidp_input_format {
+struct malidp_format_id {
u32 format; /* DRM fourcc */
u8 layer;   /* bitmask of layers supporting it */
u8 id;  /* used internally */
@@ -85,9 +85,9 @@ struct malidp_hw_regmap {
const struct malidp_irq_map se_irq_map;
const struct malidp_irq_map dc_irq_map;

-   /* list of supported input formats for each layer */
-   const struct malidp_input_format *input_formats;
-   const u8 n_input_formats;
+   /* list of supported pixel formats for each layer */
+   const struct malidp_format_id *pixel_formats;
+   const u8 n_pixel_formats;

/* 

[RFC PATCH 07/11] drm: Add writeback-connector pixel format properties

[Brian Starkey]

So that userspace can determine what pixel formats are supported for a
writeback connector's framebuffer, add a pixel format list to writeback
connectors. This is in the form of an immutable blob containing an array
of formats, and an immutable uint holding the array size.

Signed-off-by: Brian Starkey 
---
 drivers/gpu/drm/drm_connector.c |   73 ++-
 include/drm/drm_connector.h |   12 +++
 include/drm/drm_crtc.h  |   12 +++
 3 files changed, 96 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index fb83870..2f1f61d 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -249,9 +249,14 @@ int drm_connector_init(struct drm_device *dev,
drm_object_attach_property(>base, 
config->prop_crtc_id, 0);
}

-   if (connector_type == DRM_MODE_CONNECTOR_WRITEBACK)
+   if (connector_type == DRM_MODE_CONNECTOR_WRITEBACK) {
drm_object_attach_property(>base,
   config->prop_fb_id, 0);
+   drm_object_attach_property(>base,
+  config->pixel_formats_property, 0);
+   drm_object_attach_property(>base,
+  config->pixel_formats_size_property, 
0);
+   }

connector->debugfs_entry = NULL;
 out_put_type_id:
@@ -851,6 +856,45 @@ int drm_mode_create_suggested_offset_properties(struct 
drm_device *dev)
 EXPORT_SYMBOL(drm_mode_create_suggested_offset_properties);

 /**
+ * drm_mode_create_writeback_connector_properties - create writeback connector 
properties
+ * @dev: DRM device
+ *
+ * Create the properties specific to writeback connectors. These will be 
attached
+ * to writeback connectors by drm_connector_init. Drivers can set these
+ * properties using drm_mode_connector_set_writeback_formats().
+ *
+ *  "PIXEL_FORMATS":
+ * Immutable blob property to store the supported pixel formats table. The
+ * data is an array of u32 DRM_FORMAT_* fourcc values.
+ * Userspace can use this blob to find out what pixel formats are supported
+ * by the connector's writeback engine.
+ *
+ *  "PIXEL_FORMATS_SIZE":
+ *  Immutable unsigned range property storing the number of entries in the
+ *  PIXEL_FORMATS array.
+ */
+int drm_mode_create_writeback_connector_properties(struct drm_device *dev)
+{
+   if (dev->mode_config.pixel_formats_property &&
+   dev->mode_config.pixel_formats_size_property)
+   return 0;
+
+   dev->mode_config.pixel_formats_property =
+   drm_property_create(dev, DRM_MODE_PROP_BLOB | 
DRM_MODE_PROP_IMMUTABLE,
+   "PIXEL_FORMATS", 0);
+
+   dev->mode_config.pixel_formats_size_property =
+   drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE,
+   "PIXEL_FORMATS_SIZE", 0, UINT_MAX);
+
+   if (dev->mode_config.pixel_formats_property == NULL ||
+   dev->mode_config.pixel_formats_size_property == NULL)
+   return -ENOMEM;
+   return 0;
+}
+EXPORT_SYMBOL(drm_mode_create_writeback_connector_properties);
+
+/**
  * drm_mode_connector_set_path_property - set tile property on connector
  * @connector: connector to set property on.
  * @path: path to use for property; must not be NULL.
@@ -957,6 +1001,33 @@ int drm_mode_connector_update_edid_property(struct 
drm_connector *connector,
 }
 EXPORT_SYMBOL(drm_mode_connector_update_edid_property);

+int drm_mode_connector_set_writeback_formats(struct drm_connector *connector,
+u32 *formats,
+unsigned int n_formats)
+{
+   struct drm_device *dev = connector->dev;
+   size_t size = n_formats * sizeof(*formats);
+   int ret;
+
+   if (connector->connector_type != DRM_MODE_CONNECTOR_WRITEBACK)
+   return -EINVAL;
+
+   ret = drm_property_replace_global_blob(dev,
+  
>pixel_formats_blob_ptr,
+  size,
+  formats,
+  >base,
+  
dev->mode_config.pixel_formats_property);
+
+   if (!ret)
+   drm_object_property_set_value(>base,
+ 
dev->mode_config.pixel_formats_size_property,
+ n_formats);
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_mode_connector_set_writeback_formats);
+
 int drm_mode_connector_set_obj_prop(struct drm_mode_object *obj,
struct drm_property *property,
uint64_t value)
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 30a766a..e77ae5c 100644
--- 

[RFC PATCH 06/11] drm: Expose fb_id property for writeback connectors

[Brian Starkey]

Expose the framebuffer for writeback connectors to userspace by
attaching the fb_id property to them.

Signed-off-by: Brian Starkey 
---
 drivers/gpu/drm/drm_atomic.c|9 +
 drivers/gpu/drm/drm_connector.c |4 
 2 files changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index b16b4fc..82e8e3a 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -986,12 +986,19 @@ int drm_atomic_connector_set_property(struct 
drm_connector *connector,
 * now?) atomic writes to DPMS property:
 */
return -EINVAL;
+   } else if (property == config->prop_fb_id) {
+   struct drm_framebuffer *fb = drm_framebuffer_lookup(dev, val);
+   drm_atomic_set_fb_for_connector(state, fb);
+   if (fb)
+   drm_framebuffer_unreference(fb);
} else if (connector->funcs->atomic_set_property) {
return connector->funcs->atomic_set_property(connector,
state, property, val);
} else {
return -EINVAL;
}
+
+   return 0;
 }
 EXPORT_SYMBOL(drm_atomic_connector_set_property);

@@ -1022,6 +1029,8 @@ drm_atomic_connector_get_property(struct drm_connector 
*connector,
*val = (state->crtc) ? state->crtc->base.id : 0;
} else if (property == config->dpms_property) {
*val = connector->dpms;
+   } else if (property == config->prop_fb_id) {
+   *val = (state->fb) ? state->fb->base.id : 0;
} else if (connector->funcs->atomic_get_property) {
return connector->funcs->atomic_get_property(connector,
state, property, val);
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 027d7a9..fb83870 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -249,6 +249,10 @@ int drm_connector_init(struct drm_device *dev,
drm_object_attach_property(>base, 
config->prop_crtc_id, 0);
}

+   if (connector_type == DRM_MODE_CONNECTOR_WRITEBACK)
+   drm_object_attach_property(>base,
+  config->prop_fb_id, 0);
+
connector->debugfs_entry = NULL;
 out_put_type_id:
if (ret)
-- 
1.7.9.5

[RFC PATCH 05/11] drm: Add fb to connector state

[Brian Starkey]

Add a framebuffer to the connector state, for use as the output target
by writeback connectors.

If a framebuffer is in use by a writeback connector when userspace
removes it, it is handled by removing the framebuffer from the connector.

Signed-off-by: Brian Starkey 
---
 drivers/gpu/drm/drm_atomic.c|   31 +++
 drivers/gpu/drm/drm_atomic_helper.c |4 
 drivers/gpu/drm/drm_framebuffer.c   |   24 
 include/drm/drm_atomic.h|3 +++
 include/drm/drm_connector.h |3 +++
 5 files changed, 61 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 2373960..b16b4fc 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1205,6 +1205,37 @@ drm_atomic_set_crtc_for_connector(struct 
drm_connector_state *conn_state,
 EXPORT_SYMBOL(drm_atomic_set_crtc_for_connector);

 /**
+ * drm_atomic_set_fb_for_connector - set framebuffer for (writeback) connector
+ * @connector_state: atomic state object for the connector
+ * @fb: fb to use for the connector
+ *
+ * This is used to set the framebuffer for a writeback connector, which outputs
+ * to a buffer instead of an actual physical connector.
+ * Changing the assigned framebuffer requires us to grab a reference to the new
+ * fb and drop the reference to the old fb, if there is one. This function
+ * takes care of all these details besides updating the pointer in the
+ * state object itself.
+ */
+void
+drm_atomic_set_fb_for_connector(struct drm_connector_state *conn_state,
+   struct drm_framebuffer *fb)
+{
+   if (conn_state->fb)
+   drm_framebuffer_unreference(conn_state->fb);
+   if (fb)
+   drm_framebuffer_reference(fb);
+   conn_state->fb = fb;
+
+   if (fb)
+   DRM_DEBUG_ATOMIC("Set [FB:%d] for connector state %p\n",
+fb->base.id, conn_state);
+   else
+   DRM_DEBUG_ATOMIC("Set [NOFB] for connector state %p\n",
+conn_state);
+}
+EXPORT_SYMBOL(drm_atomic_set_fb_for_connector);
+
+/**
  * drm_atomic_add_affected_connectors - add connectors for crtc
  * @state: atomic state
  * @crtc: DRM crtc
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 3eecfc1..78ea735 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3234,6 +3234,8 @@ __drm_atomic_helper_connector_duplicate_state(struct 
drm_connector *connector,
memcpy(state, connector->state, sizeof(*state));
if (state->crtc)
drm_connector_reference(connector);
+   if (state->fb)
+   drm_framebuffer_reference(state->fb);
 }
 EXPORT_SYMBOL(__drm_atomic_helper_connector_duplicate_state);

@@ -3361,6 +3363,8 @@ __drm_atomic_helper_connector_destroy_state(struct 
drm_connector_state *state)
 */
if (state->crtc)
drm_connector_unreference(state->connector);
+   if (state->fb)
+   drm_framebuffer_unreference(state->fb);
 }
 EXPORT_SYMBOL(__drm_atomic_helper_connector_destroy_state);

diff --git a/drivers/gpu/drm/drm_framebuffer.c 
b/drivers/gpu/drm/drm_framebuffer.c
index b02cf73..f66908b1 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 

 #include "drm_crtc_internal.h"
@@ -808,6 +809,8 @@ EXPORT_SYMBOL(drm_framebuffer_cleanup);
  * it is removed and the CRTC/plane disabled.
  * The legacy references are dropped and the ->fb pointers set to NULL
  * accordingly.
+ * It also checks for (writeback) connectors which are using @fb, and removes
+ * it if found.
  *
  * Returns:
  * true if the framebuffer was successfully removed from use
@@ -900,7 +903,7 @@ retry:
plane_state->src_h = 0;
}

-   /* All of the connectors in state need disabling */
+   /* All of the connectors currently in state need disabling */
for_each_connector_in_state(state, connector, conn_state, i) {
ret = drm_atomic_set_crtc_for_connector(conn_state,
NULL);
@@ -908,10 +911,23 @@ retry:
goto fail;
}

-   if (WARN_ON(!plane_mask)) {
-   DRM_ERROR("Couldn't find any usage of [FB:%d]\n", fb->base.id);
-   ret = -ENOENT;
+   /* Now find any writeback connectors that need handling */
+   ret = drm_modeset_lock(>dev->mode_config.connection_mutex,
+  state->acquire_ctx);
+   if (ret)
goto fail;
+
+   drm_for_each_connector(connector, dev) {
+   conn_state = drm_atomic_get_connector_state(state, connector);
+   if (IS_ERR(conn_state)) {
+   ret = PTR_ERR(conn_state);
+ 

[RFC PATCH 04/11] drm: Add __drm_framebuffer_remove_atomic

[Brian Starkey]

Implement the CRTC/Plane disable functionality of drm_framebuffer_remove
using the atomic API, and use it if possible.

For atomic drivers, this removes the possibility of several commits when
a framebuffer is in use by more than one CRTC/plane.

Additionally, this will provide a suitable place to support the removal
of a framebuffer from a writeback connector, in the case that a
writeback connector is still actively using a framebuffer when it is
removed by userspace.

Signed-off-by: Brian Starkey 
---
 drivers/gpu/drm/drm_framebuffer.c |  154 -
 1 file changed, 152 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_framebuffer.c 
b/drivers/gpu/drm/drm_framebuffer.c
index 528f75d..b02cf73 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -22,6 +22,7 @@

 #include 
 #include 
+#include 
 #include 
 #include 

@@ -795,6 +796,148 @@ void drm_framebuffer_cleanup(struct drm_framebuffer *fb)
 EXPORT_SYMBOL(drm_framebuffer_cleanup);

 /**
+ * __drm_framebuffer_remove_atomic - atomic version of __drm_framebuffer_remove
+ * @dev: drm device
+ * @fb: framebuffer to remove
+ *
+ * If the driver implements the atomic API, we can handle the disabling of all
+ * CRTCs/planes which use a framebuffer which is going away in a single atomic
+ * commit.
+ *
+ * This scans all CRTCs and planes in @dev's mode_config. If they're using @fb,
+ * it is removed and the CRTC/plane disabled.
+ * The legacy references are dropped and the ->fb pointers set to NULL
+ * accordingly.
+ *
+ * Returns:
+ * true if the framebuffer was successfully removed from use
+ */
+static bool __drm_framebuffer_remove_atomic(struct drm_device *dev,
+   struct drm_framebuffer *fb)
+{
+   struct drm_modeset_acquire_ctx ctx;
+   struct drm_atomic_state *state;
+   struct drm_connector_state *conn_state;
+   struct drm_connector *connector;
+   struct drm_plane *plane;
+   struct drm_crtc *crtc;
+   unsigned plane_mask;
+   int i, ret;
+
+   drm_modeset_acquire_init(, 0);
+
+   state = drm_atomic_state_alloc(dev);
+   if (!state)
+   return false;
+
+   state->acquire_ctx = 
+
+retry:
+   drm_for_each_crtc(crtc, dev) {
+   struct drm_plane_state *primary_state;
+   struct drm_crtc_state *crtc_state;
+
+   primary_state = drm_atomic_get_plane_state(state, 
crtc->primary);
+   if (IS_ERR(primary_state)) {
+   ret = PTR_ERR(primary_state);
+   goto fail;
+   }
+
+   if (primary_state->fb != fb)
+   continue;
+
+   crtc_state = drm_atomic_get_crtc_state(state, crtc);
+   if (IS_ERR(crtc_state)) {
+   ret = PTR_ERR(crtc_state);
+   goto fail;
+   }
+
+   /* Only handle the CRTC itself here, handle the plane later */
+   ret = drm_atomic_set_mode_for_crtc(crtc_state, NULL);
+   if (ret != 0)
+   goto fail;
+
+   crtc_state->active = false;
+
+   /* Get the connectors in order to disable them */
+   ret = drm_atomic_add_affected_connectors(state, crtc);
+   if (ret)
+   goto fail;
+   }
+
+   plane_mask = 0;
+   drm_for_each_plane(plane, dev) {
+   struct drm_plane_state *plane_state;
+
+   plane_state = drm_atomic_get_plane_state(state, plane);
+   if (IS_ERR(plane_state)) {
+   ret = PTR_ERR(plane_state);
+   goto fail;
+   }
+
+   if (plane_state->fb != fb)
+   continue;
+
+   plane->old_fb = plane->fb;
+   plane_mask |= 1 << drm_plane_index(plane);
+
+   /*
+* Open-coded copy of __drm_atomic_helper_disable_plane to avoid
+* a dependency on atomic-helper
+*/
+   ret = drm_atomic_set_crtc_for_plane(plane_state, NULL);
+   if (ret != 0)
+   goto fail;
+
+   drm_atomic_set_fb_for_plane(plane_state, NULL);
+   plane_state->crtc_x = 0;
+   plane_state->crtc_y = 0;
+   plane_state->crtc_w = 0;
+   plane_state->crtc_h = 0;
+   plane_state->src_x = 0;
+   plane_state->src_y = 0;
+   plane_state->src_w = 0;
+   plane_state->src_h = 0;
+   }
+
+   /* All of the connectors in state need disabling */
+   for_each_connector_in_state(state, connector, conn_state, i) {
+   ret = drm_atomic_set_crtc_for_connector(conn_state,
+   NULL);
+   if (ret)
+   goto fail;
+   }
+
+   if (WARN_ON(!plane_mask)) {
+  

[RFC PATCH 03/11] drm: Extract CRTC/plane disable from drm_framebuffer_remove

[Brian Starkey]

In preparation for adding an atomic version of the disable code, extract
the actual disable operation into a separate function.

Signed-off-by: Brian Starkey 
---
 drivers/gpu/drm/drm_framebuffer.c |   87 +++--
 1 file changed, 54 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/drm_framebuffer.c 
b/drivers/gpu/drm/drm_framebuffer.c
index 398efd6..528f75d 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -795,22 +795,61 @@ void drm_framebuffer_cleanup(struct drm_framebuffer *fb)
 EXPORT_SYMBOL(drm_framebuffer_cleanup);

 /**
- * drm_framebuffer_remove - remove and unreference a framebuffer object
+ * __drm_framebuffer_remove - remove all usage of a framebuffer object
+ * @dev: drm device
  * @fb: framebuffer to remove
  *
  * Scans all the CRTCs and planes in @dev's mode_config.  If they're
- * using @fb, removes it, setting it to NULL. Then drops the reference to the
- * passed-in framebuffer. Might take the modeset locks.
+ * using @fb, removes it, setting it to NULL. Takes the modeset locks.
  *
- * Note that this function optimizes the cleanup away if the caller holds the
- * last reference to the framebuffer. It is also guaranteed to not take the
- * modeset locks in this case.
+ * Returns:
+ * true if the framebuffer was successfully removed from use
  */
-void drm_framebuffer_remove(struct drm_framebuffer *fb)
+static bool __drm_framebuffer_remove(struct drm_device *dev, struct 
drm_framebuffer *fb)
 {
-   struct drm_device *dev;
struct drm_crtc *crtc;
struct drm_plane *plane;
+   bool ret = true;
+
+   drm_modeset_lock_all(dev);
+   /* remove from any CRTC */
+   drm_for_each_crtc(crtc, dev) {
+   if (crtc->primary->fb == fb) {
+   /* should turn off the crtc */
+   if (drm_crtc_force_disable(crtc))
+   ret = false;
+   }
+   }
+
+   drm_for_each_plane(plane, dev) {
+   if (plane->fb == fb)
+   /* TODO: Propagate error here? */
+   drm_plane_force_disable(plane);
+   }
+   drm_modeset_unlock_all(dev);
+
+   return ret;
+}
+
+/**
+ * drm_framebuffer_remove - remove and unreference a framebuffer object
+ * @fb: framebuffer to remove
+ *
+ * drm ABI mandates that we remove any deleted framebuffers from active usage.
+ * This function takes care of this detail, disabling any CRTCs/Planes which
+ * are using the framebuffer being removed.
+ *
+ * Since most sane clients only remove framebuffers they no longer need, we
+ * skip the disable step if the caller holds the last reference to the
+ * framebuffer. It is also guaranteed to not take the modeset locks in
+ * this case.
+ *
+ * Before returning this function drops (what should be) the last reference
+ * on the framebuffer.
+ */
+void drm_framebuffer_remove(struct drm_framebuffer *fb)
+{
+   struct drm_device *dev;

if (!fb)
return;
@@ -820,37 +859,19 @@ void drm_framebuffer_remove(struct drm_framebuffer *fb)
WARN_ON(!list_empty(>filp_head));

/*
-* drm ABI mandates that we remove any deleted framebuffers from active
-* useage. But since most sane clients only remove framebuffers they no
-* longer need, try to optimize this away.
-*
 * Since we're holding a reference ourselves, observing a refcount of 1
-* means that we're the last holder and can skip it. Also, the refcount
-* can never increase from 1 again, so we don't need any barriers or
-* locks.
+* means that we're the last holder and can skip the disable. Also, the
+* refcount can never increase from 1 again, so we don't need any
+* barriers or locks.
 *
-* Note that userspace could try to race with use and instate a new
+* Note that userspace could try to race with us and instate a new
 * usage _after_ we've cleared all current ones. End result will be an
 * in-use fb with fb-id == 0. Userspace is allowed to shoot its own foot
 * in this manner.
 */
-   if (drm_framebuffer_read_refcount(fb) > 1) {
-   drm_modeset_lock_all(dev);
-   /* remove from any CRTC */
-   drm_for_each_crtc(crtc, dev) {
-   if (crtc->primary->fb == fb) {
-   /* should turn off the crtc */
-   if (drm_crtc_force_disable(crtc))
-   DRM_ERROR("failed to reset crtc %p when 
fb was deleted\n", crtc);
-   }
-   }
-
-   drm_for_each_plane(plane, dev) {
-   if (plane->fb == fb)
-   drm_plane_force_disable(plane);
-   }
-   drm_modeset_unlock_all(dev);
-   }
+   if 

[RFC PATCH 02/11] drm/fb-helper: Skip writeback connectors

[Brian Starkey]

Writeback connectors aren't much use to the fbdev helpers, as they won't
show anything to the user. Skip them when looking for candidate output
configurations.

Signed-off-by: Brian Starkey 
---
 drivers/gpu/drm/drm_fb_helper.c |4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 03414bd..dedf6e7 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -2016,6 +2016,10 @@ static int drm_pick_crtcs(struct drm_fb_helper 
*fb_helper,
if (modes[n] == NULL)
return best_score;

+   /* Writeback connectors aren't much use for fbdev */
+   if (connector->connector_type == DRM_MODE_CONNECTOR_WRITEBACK)
+   return best_score;
+
crtcs = kzalloc(fb_helper->connector_count *
sizeof(struct drm_fb_helper_crtc *), GFP_KERNEL);
if (!crtcs)
-- 
1.7.9.5

[RFC PATCH 01/11] drm: Add writeback connector type

[Brian Starkey]

Writeback connectors represent writeback engines which can write the
CRTC output to a memory framebuffer.

Add a writeback connector type, hidden from userspace behind a client
cap. They are hidden from non-aware clients so that they do not attempt
to use writeback connectors to provide visual output to the user.

Signed-off-by: Brian Starkey 
---
 drivers/gpu/drm/drm_connector.c |4 +++-
 drivers/gpu/drm/drm_crtc.c  |   14 +-
 drivers/gpu/drm/drm_ioctl.c |7 +++
 include/drm/drmP.h  |2 ++
 include/uapi/drm/drm.h  |   10 ++
 include/uapi/drm/drm_mode.h |1 +
 6 files changed, 36 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 26bb78c7..027d7a9 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -86,6 +86,7 @@ static struct drm_conn_prop_enum_list 
drm_connector_enum_list[] = {
{ DRM_MODE_CONNECTOR_VIRTUAL, "Virtual" },
{ DRM_MODE_CONNECTOR_DSI, "DSI" },
{ DRM_MODE_CONNECTOR_DPI, "DPI" },
+   { DRM_MODE_CONNECTOR_WRITEBACK, "Writeback" },
 };

 void drm_connector_ida_init(void)
@@ -235,7 +236,8 @@ int drm_connector_init(struct drm_device *dev,
list_add_tail(>head, >connector_list);
config->num_connector++;

-   if (connector_type != DRM_MODE_CONNECTOR_VIRTUAL)
+   if ((connector_type != DRM_MODE_CONNECTOR_VIRTUAL) &&
+   (connector_type != DRM_MODE_CONNECTOR_WRITEBACK))
drm_object_attach_property(>base,
  config->edid_property,
  0);
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 2d7bedf..33f66e2 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -422,6 +422,14 @@ static int drm_mode_create_standard_properties(struct 
drm_device *dev)
return 0;
 }

+static bool
+drm_connector_expose_to_userspace(const struct drm_connector *conn,
+ const struct drm_file *file_priv)
+{
+   return (file_priv->writeback_connectors) ||
+  (conn->connector_type != DRM_MODE_CONNECTOR_WRITEBACK);
+}
+
 /**
  * drm_mode_getresources - get graphics configuration
  * @dev: drm device for the ioctl
@@ -491,7 +499,8 @@ int drm_mode_getresources(struct drm_device *dev, void 
*data,
crtc_count++;

drm_for_each_connector(connector, dev)
-   connector_count++;
+   if (drm_connector_expose_to_userspace(connector, file_priv))
+   connector_count++;

drm_for_each_encoder(encoder, dev)
encoder_count++;
@@ -535,6 +544,9 @@ int drm_mode_getresources(struct drm_device *dev, void 
*data,
copied = 0;
connector_id = (uint32_t __user *)(unsigned 
long)card_res->connector_id_ptr;
drm_for_each_connector(connector, dev) {
+   if (!drm_connector_expose_to_userspace(connector, 
file_priv))
+   continue;
+
if (put_user(connector->base.id,
 connector_id + copied)) {
ret = -EFAULT;
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 0ad2c47..838a6e8 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -308,6 +308,13 @@ drm_setclientcap(struct drm_device *dev, void *data, 
struct drm_file *file_priv)
file_priv->atomic = req->value;
file_priv->universal_planes = req->value;
break;
+   case DRM_CLIENT_CAP_WRITEBACK_CONNECTORS:
+   if (!drm_core_check_feature(dev, DRIVER_ATOMIC))
+   return -EINVAL;
+   if (req->value > 1)
+   return -EINVAL;
+   file_priv->writeback_connectors = req->value;
+   break;
default:
return -EINVAL;
}
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 0e99669..222d5dc 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -388,6 +388,8 @@ struct drm_file {
unsigned universal_planes:1;
/* true if client understands atomic properties */
unsigned atomic:1;
+   /* true if client understands writeback connectors */
+   unsigned writeback_connectors:1;
/*
 * This client is the creator of @master.
 * Protected by struct drm_device::master_mutex.
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index b2c5284..d2b4543 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -678,6 +678,16 @@ struct drm_get_cap {
  */
 #define DRM_CLIENT_CAP_ATOMIC  3

+/**
+ * DRM_CLIENT_CAP_WRITEBACK_CONNECTORS
+ *
+ * If set to 1, the DRM core will expose writeback connectors to userspace.
+ * Writeback connectors act differently to normal 

[RFC PATCH 00/11] Introduce writeback connectors

[Brian Starkey]

Hi,

This RFC series introduces a new connector type:
 DRM_MODE_CONNECTOR_WRITEBACK
It is a follow-on from a previous discussion: [1]

Writeback connectors are used to expose the memory writeback engines
found in some display controllers, which can write a CRTC's
composition result to a memory buffer.
This is useful e.g. for testing, screen-recording, screenshots,
wireless display, display cloning, memory-to-memory composition.

Patches 1-7 include the core framework changes required, and patches
8-11 implement a writeback connector for the Mali-DP writeback engine.
The Mali-DP patches depend on this other series: [2].

The connector is given the FB_ID property for the output framebuffer,
and two new read-only properties: PIXEL_FORMATS and
PIXEL_FORMATS_SIZE, which expose the supported framebuffer pixel
formats of the engine.

The EDID property is not exposed for writeback connectors.

Writeback connector usage:
--
Due to connector routing changes being treated as "full modeset"
operations, any client which wishes to use a writeback connector
should include the connector in every modeset. The writeback will not
actually become active until a framebuffer is attached.

The writeback itself is enabled by attaching a framebuffer to the
FB_ID property of the connector. The driver must then ensure that the
CRTC content of that atomic commit is written into the framebuffer.

The writeback works in a one-shot mode with each atomic commit. This
prevents the same content from being written multiple times.
In some cases (front-buffer rendering) there might be a desire for
continuous operation - I think a property could be added later for
this kind of control.

Writeback can be disabled by setting FB_ID to zero.

Known issues:
-
 * I'm not sure what "DPMS" should mean for writeback connectors.
   It could be used to disable writeback (even when a framebuffer is
   attached), or it could be hidden entirely (which would break the
   legacy DPMS call for writeback connectors).
 * With Daniel's recent re-iteration of the userspace API rules, I
   fully expect to provide some userspace code to support this. The
   question is what, and where? We want to use writeback for testing,
   so perhaps some tests in igt is suitable.
 * Documentation. Probably some portion of this cover letter needs to
   make it into Documentation/
 * Synchronisation. Our hardware will finish the writeback by the next
   vsync. I've not implemented fence support here, but it would be an
   obvious addition.

See Also:
-
[1] https://lists.freedesktop.org/archives/dri-devel/2016-July/113197.html
[2] https://lists.freedesktop.org/archives/dri-devel/2016-October/120486.html

I welcome any comments, especially if this approach does/doesn't fit
well with anyone else's hardware.

Thanks,

-Brian

---

Brian Starkey (10):
  drm: add writeback connector type
  drm/fb-helper: skip writeback connectors
  drm: extract CRTC/plane disable from drm_framebuffer_remove
  drm: add __drm_framebuffer_remove_atomic
  drm: add fb to connector state
  drm: expose fb_id property for writeback connectors
  drm: add writeback-connector pixel format properties
  drm: mali-dp: rename malidp_input_format
  drm: mali-dp: add RGB writeback formats for DP550/DP650
  drm: mali-dp: add writeback connector

Liviu Dudau (1):
  drm: mali-dp: Add support for writeback on DP550/DP650

 drivers/gpu/drm/arm/Makefile|1 +
 drivers/gpu/drm/arm/malidp_crtc.c   |   10 ++
 drivers/gpu/drm/arm/malidp_drv.c|   25 +++-
 drivers/gpu/drm/arm/malidp_drv.h|5 +
 drivers/gpu/drm/arm/malidp_hw.c |  104 ++
 drivers/gpu/drm/arm/malidp_hw.h |   27 +++-
 drivers/gpu/drm/arm/malidp_mw.c |  268 +++
 drivers/gpu/drm/arm/malidp_planes.c |8 +-
 drivers/gpu/drm/arm/malidp_regs.h   |   15 ++
 drivers/gpu/drm/drm_atomic.c|   40 ++
 drivers/gpu/drm/drm_atomic_helper.c |4 +
 drivers/gpu/drm/drm_connector.c |   79 ++-
 drivers/gpu/drm/drm_crtc.c  |   14 +-
 drivers/gpu/drm/drm_fb_helper.c |4 +
 drivers/gpu/drm/drm_framebuffer.c   |  249 
 drivers/gpu/drm/drm_ioctl.c |7 +
 include/drm/drmP.h  |2 +
 include/drm/drm_atomic.h|3 +
 include/drm/drm_connector.h |   15 ++
 include/drm/drm_crtc.h  |   12 ++
 include/uapi/drm/drm.h  |   10 ++
 include/uapi/drm/drm_mode.h |1 +
 22 files changed, 830 insertions(+), 73 deletions(-)
 create mode 100644 drivers/gpu/drm/arm/malidp_mw.c

-- 
1.7.9.5

[PATCH 8/8] drm: mali-dp: Store internal format and n_planes in plane state

[Brian Starkey]

Save a search through the format lists at commit-time by storing the
internal format ID and number of planes in our plane state.

Signed-off-by: Brian Starkey 
---
 drivers/gpu/drm/arm/malidp_drv.h|3 +++
 drivers/gpu/drm/arm/malidp_planes.c |   27 ---
 2 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_drv.h b/drivers/gpu/drm/arm/malidp_drv.h
index 271d2fb..9fc8a2e 100644
--- a/drivers/gpu/drm/arm/malidp_drv.h
+++ b/drivers/gpu/drm/arm/malidp_drv.h
@@ -39,6 +39,9 @@ struct malidp_plane_state {

/* size of the required rotation memory if plane is rotated */
u32 rotmem_size;
+   /* internal format ID */
+   u8 format;
+   u8 n_planes;
 };

 #define to_malidp_plane(x) container_of(x, struct malidp_plane, base)
diff --git a/drivers/gpu/drm/arm/malidp_planes.c 
b/drivers/gpu/drm/arm/malidp_planes.c
index 667b9ca..80f389b 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -70,6 +70,8 @@ struct drm_plane_state *malidp_duplicate_plane_state(struct 
drm_plane *plane)
m_state = to_malidp_plane_state(plane->state);
__drm_atomic_helper_plane_duplicate_state(plane, >base);
state->rotmem_size = m_state->rotmem_size;
+   state->format = m_state->format;
+   state->n_planes = m_state->n_planes;
}

return >base;
@@ -99,8 +101,7 @@ static int malidp_de_plane_check(struct drm_plane *plane,
struct malidp_plane *mp = to_malidp_plane(plane);
struct malidp_plane_state *ms = to_malidp_plane_state(state);
struct drm_framebuffer *fb;
-   int n_planes, i;
-   u8 format_id;
+   int i;
u32 src_w, src_h;

if (!state->crtc || !state->fb)
@@ -108,13 +109,13 @@ static int malidp_de_plane_check(struct drm_plane *plane,

fb = state->fb;

-   format_id = malidp_hw_get_format_id(>hwdev->map, mp->layer->id,
+   ms->format = malidp_hw_get_format_id(>hwdev->map, mp->layer->id,
fb->pixel_format);
-   if (format_id == MALIDP_INVALID_FORMAT_ID)
+   if (ms->format == MALIDP_INVALID_FORMAT_ID)
return -EINVAL;

-   n_planes = drm_format_num_planes(fb->pixel_format);
-   for (i = 0; i < n_planes; i++) {
+   ms->n_planes = drm_format_num_planes(fb->pixel_format);
+   for (i = 0; i < ms->n_planes; i++) {
if (!malidp_hw_pitch_valid(mp->hwdev, fb->pitches[i])) {
DRM_DEBUG_KMS("Invalid pitch %u for plane %d\n",
  fb->pitches[i], i);
@@ -160,17 +161,13 @@ static void malidp_de_plane_update(struct drm_plane 
*plane,
struct drm_gem_cma_object *obj;
struct malidp_plane *mp;
const struct malidp_hw_regmap *map;
-   u8 format_id;
+   struct malidp_plane_state *ms = to_malidp_plane_state(plane->state);
u16 ptr;
-   u32 format, src_w, src_h, dest_w, dest_h, val;
-   int num_planes, i;
+   u32 src_w, src_h, dest_w, dest_h, val;
+   int i;

mp = to_malidp_plane(plane);
-
map = >hwdev->map;
-   format = plane->state->fb->pixel_format;
-   format_id = malidp_hw_get_format_id(map, mp->layer->id, format);
-   num_planes = drm_format_num_planes(format);

/* convert src values from Q16 fixed point to integer */
src_w = plane->state->src_w >> 16;
@@ -183,9 +180,9 @@ static void malidp_de_plane_update(struct drm_plane *plane,
dest_h = plane->state->crtc_h;
}

-   malidp_hw_write(mp->hwdev, format_id, mp->layer->base);
+   malidp_hw_write(mp->hwdev, ms->format, mp->layer->base);

-   for (i = 0; i < num_planes; i++) {
+   for (i = 0; i < ms->n_planes; i++) {
/* calculate the offset for the layer's plane registers */
ptr = mp->layer->ptr + (i << 4);

-- 
1.7.9.5

[PATCH 7/8] drm: mali-dp: Enable alpha blending

[Brian Starkey]

Always enable pixel-level alpha blending with the background, so that
buffers which include an alpha channel are displayed correctly.

Signed-off-by: Brian Starkey 
---
 drivers/gpu/drm/arm/malidp_planes.c |   32 ++--
 1 file changed, 26 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_planes.c 
b/drivers/gpu/drm/arm/malidp_planes.c
index a17d24b..667b9ca 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -27,6 +27,10 @@
 #define   LAYER_H_FLIP (1 << 10)
 #define   LAYER_V_FLIP (1 << 11)
 #define   LAYER_ROT_MASK   (0xf << 8)
+#define   LAYER_COMP_MASK  (0x3 << 12)
+#define   LAYER_COMP_PIXEL (0x3 << 12)
+#define   LAYER_COMP_PLANE (0x2 << 12)
+#define MALIDP_LAYER_COMPOSE   0x008
 #define MALIDP_LAYER_SIZE  0x00c
 #define   LAYER_H_VAL(x)   (((x) & 0x1fff) << 0)
 #define   LAYER_V_VAL(x)   (((x) & 0x1fff) << 16)
@@ -34,6 +38,14 @@
 #define MALIDP_LAYER_OFFSET0x014
 #define MALIDP_LAYER_STRIDE0x018

+/*
+ * This 4-entry look-up-table is used to determine the full 8-bit alpha value
+ * for formats with 1- or 2-bit alpha channels.
+ * We set it to give 100%/0% opacity for 1-bit formats and 100%/66%/33%/0%
+ * opacity for 2-bit formats.
+ */
+#define MALIDP_ALPHA_LUT 0xffaa5500
+
 static void malidp_de_plane_destroy(struct drm_plane *plane)
 {
struct malidp_plane *mp = to_malidp_plane(plane);
@@ -150,7 +162,7 @@ static void malidp_de_plane_update(struct drm_plane *plane,
const struct malidp_hw_regmap *map;
u8 format_id;
u16 ptr;
-   u32 format, src_w, src_h, dest_w, dest_h, val = 0;
+   u32 format, src_w, src_h, dest_w, dest_h, val;
int num_planes, i;

mp = to_malidp_plane(plane);
@@ -194,10 +206,9 @@ static void malidp_de_plane_update(struct drm_plane *plane,
LAYER_V_VAL(plane->state->crtc_y),
mp->layer->base + MALIDP_LAYER_OFFSET);

-   /* first clear the rotation bits in the register */
-   malidp_hw_clearbits(mp->hwdev, LAYER_ROT_MASK,
-   mp->layer->base + MALIDP_LAYER_CONTROL);
+   val = malidp_hw_read(mp->hwdev, mp->layer->base + MALIDP_LAYER_CONTROL);

+   val &= ~LAYER_ROT_MASK;
/* setup the rotation and axis flip bits */
if (plane->state->rotation & DRM_ROTATE_MASK)
val = ilog2(plane->state->rotation & DRM_ROTATE_MASK) << 
LAYER_ROT_OFFSET;
@@ -206,11 +217,18 @@ static void malidp_de_plane_update(struct drm_plane 
*plane,
if (plane->state->rotation & DRM_REFLECT_Y)
val |= LAYER_H_FLIP;

+   /*
+* always enable pixel alpha blending until we have a way to change
+* blend modes
+*/
+   val &= ~LAYER_COMP_MASK;
+   val |= LAYER_COMP_PIXEL;
+
/* set the 'enable layer' bit */
val |= LAYER_ENABLE;

-   malidp_hw_setbits(mp->hwdev, val,
- mp->layer->base + MALIDP_LAYER_CONTROL);
+   malidp_hw_write(mp->hwdev, val,
+   mp->layer->base + MALIDP_LAYER_CONTROL);
 }

 static void malidp_de_plane_disable(struct drm_plane *plane,
@@ -292,6 +310,8 @@ int malidp_de_planes_init(struct drm_device *drm)
   
drm->mode_config.rotation_property,
   DRM_ROTATE_0);

+   malidp_hw_write(malidp->dev, MALIDP_ALPHA_LUT,
+   plane->layer->base + MALIDP_LAYER_COMPOSE);
}

kfree(formats);
-- 
1.7.9.5

[PATCH 6/8] drm: mali-dp: Refactor plane initialisation

[Brian Starkey]

As we add more features, it makes sense to skip all the features not
supported by the smart layer together, instead of checking each one
individually. Achieve this by refactoring the plane init loop.

Signed-off-by: Brian Starkey 
Acked-by: Liviu Dudau 
---
 drivers/gpu/drm/arm/malidp_planes.c |   17 +++--
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_planes.c 
b/drivers/gpu/drm/arm/malidp_planes.c
index f95e02d..a17d24b 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -267,6 +267,15 @@ int malidp_de_planes_init(struct drm_device *drm)
if (ret < 0)
goto cleanup;

+   drm_plane_helper_add(>base,
+_de_plane_helper_funcs);
+   plane->hwdev = malidp->dev;
+   plane->layer = >layers[i];
+
+   /* Skip the features which the SMART layer doesn't have */
+   if (id == DE_SMART)
+   continue;
+
if (!drm->mode_config.rotation_property) {
unsigned long flags = DRM_ROTATE_0 |
  DRM_ROTATE_90 |
@@ -277,16 +286,12 @@ int malidp_de_planes_init(struct drm_device *drm)
drm->mode_config.rotation_property =
drm_mode_create_rotation_property(drm, flags);
}
-   /* SMART layer can't be rotated */
-   if (drm->mode_config.rotation_property && (id != DE_SMART))
+
+   if (drm->mode_config.rotation_property)
drm_object_attach_property(>base.base,
   
drm->mode_config.rotation_property,
   DRM_ROTATE_0);

-   drm_plane_helper_add(>base,
-_de_plane_helper_funcs);
-   plane->hwdev = malidp->dev;
-   plane->layer = >layers[i];
}

kfree(formats);
-- 
1.7.9.5

[PATCH 5/8] arm: mali-dp: Extract mode_config cleanup into malidp_fini

[Brian Starkey]

Split out malidp_fini as the opposite of malidp_init. This helps keep
the cleanup paths neat and easier to manage.

Signed-off-by: Brian Starkey 
---
 drivers/gpu/drm/arm/malidp_drv.c |   12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index f2b1923..62a29f6 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -156,6 +156,12 @@ static int malidp_init(struct drm_device *drm)
return 0;
 }

+static void malidp_fini(struct drm_device *drm)
+{
+   malidp_de_planes_destroy(drm);
+   drm_mode_config_cleanup(drm);
+}
+
 static int malidp_irq_init(struct platform_device *pdev)
 {
int irq_de, irq_se, ret = 0;
@@ -414,8 +420,7 @@ bind_fail:
 port_fail:
drm_dev_unregister(drm);
 register_fail:
-   malidp_de_planes_destroy(drm);
-   drm_mode_config_cleanup(drm);
+   malidp_fini(drm);
 init_fail:
drm->dev_private = NULL;
dev_set_drvdata(dev, NULL);
@@ -448,8 +453,7 @@ static void malidp_unbind(struct device *dev)
of_node_put(malidp->crtc.port);
malidp->crtc.port = NULL;
drm_dev_unregister(drm);
-   malidp_de_planes_destroy(drm);
-   drm_mode_config_cleanup(drm);
+   malidp_fini(drm);
drm->dev_private = NULL;
dev_set_drvdata(dev, NULL);
clk_disable_unprepare(hwdev->mclk);
-- 
1.7.9.5

[PATCH 4/8] drm: mali-dp: Add pitch alignment check for planes

[Brian Starkey]

Check that the framebuffer pitches are appropriately aligned when
checking planes.

Signed-off-by: Brian Starkey 
---
 drivers/gpu/drm/arm/malidp_planes.c |   15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/arm/malidp_planes.c 
b/drivers/gpu/drm/arm/malidp_planes.c
index 82c193e..f95e02d 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -86,17 +86,30 @@ static int malidp_de_plane_check(struct drm_plane *plane,
 {
struct malidp_plane *mp = to_malidp_plane(plane);
struct malidp_plane_state *ms = to_malidp_plane_state(state);
+   struct drm_framebuffer *fb;
+   int n_planes, i;
u8 format_id;
u32 src_w, src_h;

if (!state->crtc || !state->fb)
return 0;

+   fb = state->fb;
+
format_id = malidp_hw_get_format_id(>hwdev->map, mp->layer->id,
-   state->fb->pixel_format);
+   fb->pixel_format);
if (format_id == MALIDP_INVALID_FORMAT_ID)
return -EINVAL;

+   n_planes = drm_format_num_planes(fb->pixel_format);
+   for (i = 0; i < n_planes; i++) {
+   if (!malidp_hw_pitch_valid(mp->hwdev, fb->pitches[i])) {
+   DRM_DEBUG_KMS("Invalid pitch %u for plane %d\n",
+ fb->pitches[i], i);
+   return -EINVAL;
+   }
+   }
+
src_w = state->src_w >> 16;
src_h = state->src_h >> 16;

-- 
1.7.9.5

[PATCH 3/8] drm: mali-dp: Add pitch alignment check function

[Brian Starkey]

Different hardware versions have different requirements when it comes to
pitch alignment. Add a function which can be used to check pitch
alignment for a device.

Signed-off-by: Brian Starkey 
---
 drivers/gpu/drm/arm/malidp_hw.c |3 +++
 drivers/gpu/drm/arm/malidp_hw.h |9 +
 2 files changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index a6132f1..7f4a0bd 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -441,6 +441,7 @@ const struct malidp_hw_device 
malidp_device[MALIDP_MAX_DEVICES] = {
},
.input_formats = malidp500_de_formats,
.n_input_formats = ARRAY_SIZE(malidp500_de_formats),
+   .bus_align_bytes = 8,
},
.query_hw = malidp500_query_hw,
.enter_config_mode = malidp500_enter_config_mode,
@@ -473,6 +474,7 @@ const struct malidp_hw_device 
malidp_device[MALIDP_MAX_DEVICES] = {
},
.input_formats = malidp550_de_formats,
.n_input_formats = ARRAY_SIZE(malidp550_de_formats),
+   .bus_align_bytes = 8,
},
.query_hw = malidp550_query_hw,
.enter_config_mode = malidp550_enter_config_mode,
@@ -506,6 +508,7 @@ const struct malidp_hw_device 
malidp_device[MALIDP_MAX_DEVICES] = {
},
.input_formats = malidp550_de_formats,
.n_input_formats = ARRAY_SIZE(malidp550_de_formats),
+   .bus_align_bytes = 16,
},
.query_hw = malidp650_query_hw,
.enter_config_mode = malidp550_enter_config_mode,
diff --git a/drivers/gpu/drm/arm/malidp_hw.h b/drivers/gpu/drm/arm/malidp_hw.h
index 141743e..087e1202 100644
--- a/drivers/gpu/drm/arm/malidp_hw.h
+++ b/drivers/gpu/drm/arm/malidp_hw.h
@@ -88,6 +88,9 @@ struct malidp_hw_regmap {
/* list of supported input formats for each layer */
const struct malidp_input_format *input_formats;
const u8 n_input_formats;
+
+   /* pitch alignment requirement in bytes */
+   const u8 bus_align_bytes;
 };

 struct malidp_hw_device {
@@ -229,6 +232,12 @@ void malidp_se_irq_fini(struct drm_device *drm);
 u8 malidp_hw_get_format_id(const struct malidp_hw_regmap *map,
   u8 layer_id, u32 format);

+static inline bool malidp_hw_pitch_valid(struct malidp_hw_device *hwdev,
+unsigned int pitch)
+{
+   return !(pitch & (hwdev->map.bus_align_bytes - 1));
+}
+
 /*
  * background color components are defined as 12bits values,
  * they will be shifted right when stored on hardware that
-- 
1.7.9.5

[PATCH 2/8] drm: mali-dp: Clear the config_valid flag before using it in wait_event.

[Brian Starkey]

From: Liviu Dudau 

config_valid variable is used to signal the activation of the CVAL
request when the vsync interrupt has fired. malidp_set_and_wait_config_valid()
uses the variable in wait_event_interruptible_timeout without clearing it
first, so the wait is skipped.

Signed-off-by: Liviu Dudau 
---
 drivers/gpu/drm/arm/malidp_drv.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 7987ebd..f2b1923 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -42,6 +42,7 @@ static int malidp_set_and_wait_config_valid(struct drm_device 
*drm)
struct malidp_hw_device *hwdev = malidp->dev;
int ret;

+   atomic_set(>config_valid, 0);
hwdev->set_config_valid(hwdev);
/* don't wait for config_valid flag if we are in config mode */
if (hwdev->in_config_mode(hwdev))
-- 
1.7.9.5

[PATCH 1/8] drm: mali-dp: Set the drm->irq_enabled flag to match driver's state.

[Brian Starkey]

From: Liviu Dudau 

Mali DP driver does not use drm_irq_{un,}install() function so the
drm->irq_enabled flag does not get set automatically.
drm_wait_vblank() checks the value of the flag among other functions.

Signed-off-by: Liviu Dudau 
---

Hi,

This series is a bunch of small driver-internal fixes and cleanup for
Mali-DP.

-Brian

 drivers/gpu/drm/arm/malidp_drv.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 9280358..7987ebd 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -377,6 +377,8 @@ static int malidp_bind(struct device *dev)
if (ret < 0)
goto irq_init_fail;

+   drm->irq_enabled = true;
+
ret = drm_vblank_init(drm, drm->mode_config.num_crtc);
if (ret < 0) {
DRM_ERROR("failed to initialise vblank\n");
@@ -402,6 +404,7 @@ fbdev_fail:
 vblank_fail:
malidp_se_irq_fini(drm);
malidp_de_irq_fini(drm);
+   drm->irq_enabled = false;
 irq_init_fail:
component_unbind_all(dev, drm);
 bind_fail:
-- 
1.7.9.5

[PATCH v4] drm/panel: simple: Add support for AUO t215hvn01

[Haixia Shi]

The AUO t215hvn01 is a 21.5" FHD (1920x1080) color TFT LCD panel.

This panel is used on the Acer Chromebase 21.5-inch All-in-One (DC221HQ).

Link to spec: http://www.udmgroup.com/ftp/T215HVN01.0.pdf

v2: fix alphabetical order
v3: remove minor revision suffix ".0" and add link to spec
v4: add dt-binding documentation

Signed-off-by: Haixia Shi 
Tested-by: Haixia Shi 
Reviewed-by: Stéphane Marchesin 
Cc: Emil Velikov 
Cc: Thierry Reding 
Cc: David Airlie 
Cc: Rob Herring 
Cc: Mark Rutland 
Cc: devicetree at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
---
 .../bindings/display/panel/auo,t215hvn01.txt   |  7 +
 drivers/gpu/drm/panel/panel-simple.c   | 30 ++
 2 files changed, 37 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/auo,t215hvn01.txt

diff --git a/Documentation/devicetree/bindings/display/panel/auo,t215hvn01.txt 
b/Documentation/devicetree/bindings/display/panel/auo,t215hvn01.txt
new file mode 100644
index 000..cbd9da3
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/auo,t215hvn01.txt
@@ -0,0 +1,7 @@
+AU Optronics Corporation 21.5" FHD (1920x1080) color TFT LCD panel
+
+Required properties:
+- compatible: should be "auo,t215hvn01"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 113db3c..256c201 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -555,6 +555,33 @@ static const struct panel_desc auo_b133htn01 = {
},
 };

+static const struct drm_display_mode auo_t215hvn01_mode = {
+   .clock = 148800,
+   .hdisplay = 1920,
+   .hsync_start = 1920 + 88,
+   .hsync_end = 1920 + 88 + 44,
+   .htotal = 1920 + 88 + 44 + 148,
+   .vdisplay = 1080,
+   .vsync_start = 1080 + 4,
+   .vsync_end = 1080 + 4 + 5,
+   .vtotal = 1080 + 4 + 5 + 36,
+   .vrefresh = 60,
+};
+
+static const struct panel_desc auo_t215hvn01 = {
+   .modes = _t215hvn01_mode,
+   .num_modes = 1,
+   .bpc = 8,
+   .size = {
+   .width = 430,
+   .height = 270,
+   },
+   .delay = {
+   .disable = 5,
+   .unprepare = 1000,
+   }
+};
+
 static const struct drm_display_mode avic_tm070ddh03_mode = {
.clock = 51200,
.hdisplay = 1024,
@@ -1575,6 +1602,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "auo,b133xtn01",
.data = _b133xtn01,
}, {
+   .compatible = "auo,t215hvn01",
+   .data = _t215hvn01,
+   }, {
.compatible = "avic,tm070ddh03",
.data = _tm070ddh03,
}, {
-- 
2.8.0.rc3.226.g39d4020

[Bug 98166] [vulkan, radv] make install regenerates radv_timestamp.h and rebuilds radv_device.lo

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

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

Vedran Miletić  changed:

   What|Removed |Added

 QA Contact|dri-devel at lists.freedesktop |mesa-dev at 
lists.freedesktop.
   |.org|org
  Component|Drivers/Gallium/radeonsi|Drivers/Vulkan/radeon
   Assignee|dri-devel at lists.freedesktop |mesa-dev at 
lists.freedesktop.
   |.org|org

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

[Bug 98167] [vulkan, radv] missing libgcrypt and openssl devel results in linker error in libvulkan_common

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

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

Vedran Miletić  changed:

   What|Removed |Added

  Component|Drivers/Gallium/radeonsi|Drivers/Vulkan/radeon
   Assignee|dri-devel at lists.freedesktop |mesa-dev at 
lists.freedesktop.
   |.org|org
 QA Contact|dri-devel at lists.freedesktop |mesa-dev at 
lists.freedesktop.
   |.org|org

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

[PATCH] drm/i915: Before pageflip, also wait for shared dmabuf fences.

[Christian König]

Am 11.10.2016 um 05:58 schrieb Michel Dänzer:
> On 07/10/16 09:34 PM, Mike Lothian wrote:
>> This has discussion has gone a little quiet
>>
>> Was there any agreement about what needed doing to get this working
>> for i965/amdgpu?
> Christian, do you see anything which could prevent the solution I
> outlined from working?

I thought about that approach as well, but unfortunately it also has a 
couple of downsides. Especially keeping the exclusive fence set while we 
actually don't need it isn't really clean either.

I'm currently a bit busy with other tasks and so put Nayan on a road to 
get a bit into the kernel driver (he asked for that anyway).

Implementing the simple workaround to sync when we export the DMA-buf 
should be something like 20 lines of code and fortunately Nayan has an 
I+A system and so can actually test it.

If it turns out to be more problematic or somebody really starts to need 
it I'm going to hack on that myself a bit more.

Regards,
Christian.

[Bug 98168] [vulkan, radv] Talos rendering glitches on Ultra settings on Tonga

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

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

Vedran Miletić  changed:

   What|Removed |Added

 QA Contact|dri-devel at lists.freedesktop |mesa-dev at 
lists.freedesktop.
   |.org|org
  Component|Drivers/Gallium/radeonsi|Drivers/Vulkan/radeon
   Assignee|dri-devel at lists.freedesktop |mesa-dev at 
lists.freedesktop.
   |.org|org

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

[PATCH] drm/gma500: remove useless comment

[Jiang Biao]

Remove useless comment in framebuffer.c.

Signed-off-by: Jiang Biao 
---
 drivers/gpu/drm/gma500/framebuffer.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/gma500/framebuffer.c 
b/drivers/gpu/drm/gma500/framebuffer.c
index 0fcdce0..3c8aa55 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -299,7 +299,6 @@ static struct drm_framebuffer *psb_framebuffer_create
  * psbfb_alloc -   allocate frame buffer memory
  * @dev: the DRM device
  * @aligned_size: space needed
- * @force: fall back to GEM buffers if need be
  *
  * Allocate the frame buffer. In the usual case we get a GTT range that
  * is stolen memory backed and life is simple. If there isn't sufficient
-- 
2.1.0

drm/amd/powerplay: implement smu7 hwmgr to manager asics with smu ip version 7.

[Christian König]

Some commit messages would be nice.

You could make the subject line shorter (something like "fix some 
warning in xyz.c") and actually use the current subject line as commit 
message.

With that fixed the patches are Reviewed-by: Christian König 
.

Regards,
Christian.

Am 11.10.2016 um 13:17 schrieb Zhu, Rex:
> Thanks.
> Please review the attached patches.
>
>
> Best Regards
> Rex
>
> -Original Message-
> From: Dan Carpenter [mailto:dan.carpenter at oracle.com]
> Sent: Tuesday, October 11, 2016 3:11 PM
> To: Zhu, Rex
> Cc: dri-devel at lists.freedesktop.org
> Subject: re: drm/amd/powerplay: implement smu7 hwmgr to manager asics with 
> smu ip version 7.
>
> Hello Rex Zhu,
>
> This is a semi-automatic email about new static checker warnings.
>
> The patch 599a7e9fe1b6: "drm/amd/powerplay: implement smu7 hwmgr to manager 
> asics with smu ip version 7." from Sep 9, 2016, leads to the following Smatch 
> complaint:
>
> drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/smu7_hwmgr.c:3809 
> smu7_check_states_equal()
>warn: variable dereferenced before check 'pstate1' (see line 3805)
>
> drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/smu7_hwmgr.c
>3804   {
>3805   const struct smu7_power_state *psa = 
> cast_const_phw_smu7_power_state(pstate1);
>   
> ^^^
>3806   const struct smu7_power_state *psb = 
> cast_const_phw_smu7_power_state(pstate2);
>   
> ^^^ New dereferences.
>
>3807   int i;
>3808   
>3809   if (pstate1 == NULL || pstate2 == NULL || equal == NULL)
>  ^^
> Checked too late.
>
> Just as an aside.  People really don't review code in initializers.
> I've commented on this before, and other people have noted it as well but 
> other people are like "In that case, those people shouldn't be kernel devs!" 
> which is so ignorant.  Everyone consistently makes the same mistakes.  I've 
> spent so many hours looking at basically this same bug over and over and 
> everyone does it.
>
> That's nothing to do with your code, in particular, I just wanted to update 
> you on how my morning has been going.  (Pretty well, thanks, although I'm due 
> for a second cup of coffee).
>
>3810   return -EINVAL;
>3811   
>
> regards,
> dan carpenter
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161011/6319f749/attachment.html>

[Bug 97820] [BDW BYT SKL HSW IVB]Regression] [GPU Hang] with gem_reset_stats ban- and reset-stats- subtests

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

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

cprigent  changed:

   What|Removed |Added

 QA Contact|intel-gfx-bugs at lists.freede |
   |sktop.org   |
   Assignee|intel-gfx-bugs at lists.freede |dri-devel at 
lists.freedesktop
   |sktop.org   |.org
  Component|DRM/Intel   |IGT

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

[git pull] drm for 4.8

[Linus Torvalds]

What's the status of the 4.9 merge window pull request? The GPU side
is the main remaining pile for this merge window according to
linux-next. I'd hate to get a last-minute pull at the end of the week
...

  Linus

[PATCH] drm/i915: Before pageflip, also wait for shared dmabuf fences.

[Michel Dänzer]

On 07/10/16 09:34 PM, Mike Lothian wrote:
> 
> This has discussion has gone a little quiet
> 
> Was there any agreement about what needed doing to get this working
> for i965/amdgpu?

Christian, do you see anything which could prevent the solution I
outlined from working?


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

[PATCH]"drm: change DRM_MIPI_DSI module type from "bool" to "tristate".

[Jani Nikula]

On Tue, 11 Oct 2016, "Sun, Jing A"  wrote:
> It's needed that DRM Driver module could be removed and reloaded after
> kernel booting on the projects that I have been working on, and I hope
> such module type change could be accepted. Looks like Iwai has similar
> change request as well. Would you please review it and let us know if
> any concerns?

Looking at the Kconfig, selecting CONFIG_DRM_MIPI_DSI is against the
recommendations of Documentation/kbuild/kconfig-language.txt:

select should be used with care. select will force
a symbol to a value without visiting the dependencies.
By abusing select you are able to select a symbol FOO even
if FOO depends on BAR that is not set.
In general use select only for non-visible symbols
(no prompts anywhere) and for symbols with no dependencies.
That will limit the usefulness but on the other hand avoid
the illegal configurations all over.

Indeed, you may end up with CONFIG_DRM_MIPI_DSI=y and CONFIG_DRM=m,
which violates DRM_MIPI_DSI dependency on CONFIG_DRM. This is broken and
should be fixed. The suggested patch does *not* fix this issue.

Interestingly, I am able to reload i915 and drm. Our CI has tests for
i915 unload/reload, but does not check drm. In any case the config
problem should not impact the reloadability of i915.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH] drm/amdgpu: use .early_unregister hook to remove DP AUX i2c

[Alex Deucher]

On Sun, Oct 9, 2016 at 1:28 PM, Grazvydas Ignotas  wrote:
> When DisplayPort AUX channel i2c adapter is registered, drm_connector's
> kdev member is used as a parent, so we get sysfs structure like:
>   /drm/card1/card1-DP-2/i2c-12
> Because of that, there is a problem when drm core (and not the driver)
> calls drm_connector_unregister(), it removes parent sysfs entries
> ('card1-DP-2' in our example) while the i2c adapter is still registered.
> Later we get a WARN when we try to unregister the i2c adapter:
>
>   WARNING: CPU: 3 PID: 1374 at fs/sysfs/group.c:243 
> sysfs_remove_group+0x14c/0x150
>   sysfs group 82911e40 not found for kobject 'i2c-12'
>
> To fix it, we can use the .early_unregister hook to unregister the i2c
> adapter before drm_connector's sysfs is torn down.
>
> Signed-off-by: Grazvydas Ignotas 

Applied.  thanks!

Alex

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> index 76a7830..09b76a8 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> @@ -765,7 +765,7 @@ amdgpu_connector_lvds_detect(struct drm_connector 
> *connector, bool force)
> return ret;
>  }
>
> -static void amdgpu_connector_destroy(struct drm_connector *connector)
> +static void amdgpu_connector_unregister(struct drm_connector *connector)
>  {
> struct amdgpu_connector *amdgpu_connector = 
> to_amdgpu_connector(connector);
>
> @@ -773,6 +773,12 @@ static void amdgpu_connector_destroy(struct 
> drm_connector *connector)
> drm_dp_aux_unregister(_connector->ddc_bus->aux);
> amdgpu_connector->ddc_bus->has_aux = false;
> }
> +}
> +
> +static void amdgpu_connector_destroy(struct drm_connector *connector)
> +{
> +   struct amdgpu_connector *amdgpu_connector = 
> to_amdgpu_connector(connector);
> +
> amdgpu_connector_free_edid(connector);
> kfree(amdgpu_connector->con_priv);
> drm_connector_unregister(connector);
> @@ -826,6 +832,7 @@ static const struct drm_connector_funcs 
> amdgpu_connector_lvds_funcs = {
> .dpms = drm_helper_connector_dpms,
> .detect = amdgpu_connector_lvds_detect,
> .fill_modes = drm_helper_probe_single_connector_modes,
> +   .early_unregister = amdgpu_connector_unregister,
> .destroy = amdgpu_connector_destroy,
> .set_property = amdgpu_connector_set_lcd_property,
>  };
> @@ -936,6 +943,7 @@ static const struct drm_connector_funcs 
> amdgpu_connector_vga_funcs = {
> .dpms = drm_helper_connector_dpms,
> .detect = amdgpu_connector_vga_detect,
> .fill_modes = drm_helper_probe_single_connector_modes,
> +   .early_unregister = amdgpu_connector_unregister,
> .destroy = amdgpu_connector_destroy,
> .set_property = amdgpu_connector_set_property,
>  };
> @@ -1203,6 +1211,7 @@ static const struct drm_connector_funcs 
> amdgpu_connector_dvi_funcs = {
> .detect = amdgpu_connector_dvi_detect,
> .fill_modes = drm_helper_probe_single_connector_modes,
> .set_property = amdgpu_connector_set_property,
> +   .early_unregister = amdgpu_connector_unregister,
> .destroy = amdgpu_connector_destroy,
> .force = amdgpu_connector_dvi_force,
>  };
> @@ -1493,6 +1502,7 @@ static const struct drm_connector_funcs 
> amdgpu_connector_dp_funcs = {
> .detect = amdgpu_connector_dp_detect,
> .fill_modes = drm_helper_probe_single_connector_modes,
> .set_property = amdgpu_connector_set_property,
> +   .early_unregister = amdgpu_connector_unregister,
> .destroy = amdgpu_connector_destroy,
> .force = amdgpu_connector_dvi_force,
>  };
> @@ -1502,6 +1512,7 @@ static const struct drm_connector_funcs 
> amdgpu_connector_edp_funcs = {
> .detect = amdgpu_connector_dp_detect,
> .fill_modes = drm_helper_probe_single_connector_modes,
> .set_property = amdgpu_connector_set_lcd_property,
> +   .early_unregister = amdgpu_connector_unregister,
> .destroy = amdgpu_connector_destroy,
> .force = amdgpu_connector_dvi_force,
>  };
> --
> 2.7.4
>
> ___
> amd-gfx mailing list
> amd-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[Bug 98170] [vdpau] Error when calling vdp_output_surface_create

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

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

--- Comment #3 from Christian König  ---
Bisecting means you try to figure out what patch introduced this bug.

E.g. you know that 11.2.2 work and 12.0.1 is broken. So you checkout the source
code from git and issue "git bisect start mesa-12.0.1 mesa-11.2.2".

Now git has the list of changes between 11.2.2 and 12.0.1, so it jumps into the
middle of that list of changes.

You then compile mesa and see if this version still works.

If it works you say "git bisect good" and git will jump another quarter to the
end of the list, if it doesn't work you say "git bisect bad" and git will jump
a quarter to the beginning of the list.

This repeats until you figured out which commit caused the problem.

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

[PATCH v11 2/4] drm: Add API for capturing frame CRCs

[Benjamin Gaignard]

Hello,

I have been able to test it on my setup and, after implementing
set_crc_source function,
I have crc/data and crc/control entries for each of my crtc.

"cat /sys/kernel/debug/dri/0/crtc-0/crc/data" is blocking but I'm
really sure of my driver implementation...

Anyway you could add my ack on this patch

Regards,
Benjamin

2016-10-10 15:12 GMT+02:00 Emil Velikov :
> On 6 October 2016 at 16:21, Tomeu Vizoso  
> wrote:
>> Adds files and directories to debugfs for controlling and reading frame
>> CRCs, per CRTC:
>>
>> dri/0/crtc-0/crc
>> dri/0/crtc-0/crc/control
>> dri/0/crtc-0/crc/data
>>
>> Drivers can implement the set_crc_source callback() in drm_crtc_funcs to
>> start and stop generating frame CRCs and can add entries to the output
>> by calling drm_crtc_add_crc_entry.
>>
>> v2:
>> - Lots of good fixes suggested by Thierry.
>> - Added documentation.
>> - Changed the debugfs layout.
>> - Moved to allocate the entries circular queue once when frame
>>   generation gets enabled for the first time.
>> v3:
>> - Use the control file just to select the source, and start and stop
>>   capture when the data file is opened and closed, respectively.
>> - Make variable the number of CRC values per entry, per source.
>> - Allocate entries queue each time we start capturing as now there
>>   isn't a fixed number of CRC values per entry.
>> - Store the frame counter in the data file as a 8-digit hex number.
>> - For sources that cannot provide useful frame numbers, place
>>    in the frame field.
>>
>> v4:
>> - Build only if CONFIG_DEBUG_FS is enabled.
>> - Use memdup_user_nul.
>> - Consolidate calculation of the size of an entry in a helper.
>> - Add 0x prefix to hex numbers in the data file.
>> - Remove unnecessary snprintf and strlen usage in read callback.
>>
>> v5:
>> - Made the crcs array in drm_crtc_crc_entry fixed-size
>> - Lots of other smaller improvements suggested by Emil Velikov
>>
>> v7:
>> - Move definition of drm_debugfs_crtc_crc_add to drm_internal.h
>>
>> v8:
>> - Call debugfs_remove_recursive when we fail to create the minor
>>   device
>>
>> v9:
>> - Register the debugfs directory for a crtc from
>>   drm_crtc_register_all()
>>
>> v10:
>> - Don't let debugfs failures interrupt CRTC registration (Emil
>>   Velikov)
>>
>> v11:
>> - Remove extra brace that broke compilation. Sorry!
>>
>> Signed-off-by: Tomeu Vizoso 
>
> Reviewed-by: Emil Velikov 
>
> Emil
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
Benjamin Gaignard

Graphic Study Group

Linaro.org │ Open source software for ARM SoCs

Follow Linaro: Facebook | Twitter | Blog

[Intel-gfx] [PATCH] drm/i915: Add i915 perf infrastructure

[Robert Bragg]

On Fri, Oct 7, 2016 at 10:10 AM, Matthew Auld <
matthew.william.auld at gmail.com> wrote:

> On 14 September 2016 at 16:32, Robert Bragg  wrote:
>
> > +
> > +int i915_perf_open_ioctl_locked(struct drm_device *dev,
> > +   struct drm_i915_perf_open_param *param,
> > +   struct perf_open_properties *props,
> > +   struct drm_file *file)
> > +{
> This should be static and also let's just make it take dev_priv directly.
>

Ah, yep, done.


> > +   case DRM_I915_PERF_PROP_MAX:
> > +   BUG();
> We already handle this case above, but I guess we still need this in
> order to silence gcc...
>

right, and preferable to having a default: case, for the future compiler
warning to handle any new properties here.



> > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> > index 03725fe..77fe79b 100644
> > --- a/include/uapi/drm/i915_drm.h
> > +++ b/include/uapi/drm/i915_drm.h
> > @@ -258,6 +258,7 @@ typedef struct _drm_i915_sarea {
> >  #define DRM_I915_GEM_USERPTR   0x33
> >  #define DRM_I915_GEM_CONTEXT_GETPARAM  0x34
> >  #define DRM_I915_GEM_CONTEXT_SETPARAM  0x35
> > +#define DRM_I915_PERF_OPEN 0x36
> >
> >  #define DRM_IOCTL_I915_INITDRM_IOW( DRM_COMMAND_BASE +
> DRM_I915_INIT, drm_i915_init_t)
> >  #define DRM_IOCTL_I915_FLUSH   DRM_IO ( DRM_COMMAND_BASE +
> DRM_I915_FLUSH)
> > @@ -311,6 +312,7 @@ typedef struct _drm_i915_sarea {
> >  #define DRM_IOCTL_I915_GEM_USERPTR DRM_IOWR
> (DRM_COMMAND_BASE + DRM_I915_GEM_USERPTR, struct drm_i915_gem_userptr)
> >  #define DRM_IOCTL_I915_GEM_CONTEXT_GETPARAMDRM_IOWR
> (DRM_COMMAND_BASE + DRM_I915_GEM_CONTEXT_GETPARAM, struct
> drm_i915_gem_context_param)
> >  #define DRM_IOCTL_I915_GEM_CONTEXT_SETPARAMDRM_IOWR
> (DRM_COMMAND_BASE + DRM_I915_GEM_CONTEXT_SETPARAM, struct
> drm_i915_gem_context_param)
> > +#define DRM_IOCTL_I915_PERF_OPEN   DRM_IOR(DRM_COMMAND_BASE +
> DRM_I915_PERF_OPEN, struct drm_i915_perf_open_param)
> As you already pointed out this will need to be IOW.
>

Yeah, changed locally after I realised the mistake here, just didn't get
around to posting the patch.


Also applied the notes to not redundantly init some vars, spurious new
line, redundant include.

Thanks,
- Robert
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161011/1075dc85/attachment.html>

[RFC PATCH 00/11] Introduce writeback connectors

[Eric Anholt]

Brian Starkey  writes:

> Hi,
>
> This RFC series introduces a new connector type:
>  DRM_MODE_CONNECTOR_WRITEBACK
> It is a follow-on from a previous discussion: [1]
>
> Writeback connectors are used to expose the memory writeback engines
> found in some display controllers, which can write a CRTC's
> composition result to a memory buffer.
> This is useful e.g. for testing, screen-recording, screenshots,
> wireless display, display cloning, memory-to-memory composition.
>
> Patches 1-7 include the core framework changes required, and patches
> 8-11 implement a writeback connector for the Mali-DP writeback engine.
> The Mali-DP patches depend on this other series: [2].
>
> The connector is given the FB_ID property for the output framebuffer,
> and two new read-only properties: PIXEL_FORMATS and
> PIXEL_FORMATS_SIZE, which expose the supported framebuffer pixel
> formats of the engine.
>
> The EDID property is not exposed for writeback connectors.
>
> Writeback connector usage:
> --
> Due to connector routing changes being treated as "full modeset"
> operations, any client which wishes to use a writeback connector
> should include the connector in every modeset. The writeback will not
> actually become active until a framebuffer is attached.
>
> The writeback itself is enabled by attaching a framebuffer to the
> FB_ID property of the connector. The driver must then ensure that the
> CRTC content of that atomic commit is written into the framebuffer.
>
> The writeback works in a one-shot mode with each atomic commit. This
> prevents the same content from being written multiple times.
> In some cases (front-buffer rendering) there might be a desire for
> continuous operation - I think a property could be added later for
> this kind of control.
>
> Writeback can be disabled by setting FB_ID to zero.

I think this sounds great, and the interface is just right IMO.

I don't really see a use for continuous mode -- a sequence of one-shots
makes a lot more sense because then you can know what data has changed,
which anyone trying to use the writeback buffer would need to know.

> Known issues:
> -
>  * I'm not sure what "DPMS" should mean for writeback connectors.
>It could be used to disable writeback (even when a framebuffer is
>attached), or it could be hidden entirely (which would break the
>legacy DPMS call for writeback connectors).
>  * With Daniel's recent re-iteration of the userspace API rules, I
>fully expect to provide some userspace code to support this. The
>question is what, and where? We want to use writeback for testing,
>so perhaps some tests in igt is suitable.
>  * Documentation. Probably some portion of this cover letter needs to
>make it into Documentation/
>  * Synchronisation. Our hardware will finish the writeback by the next
>vsync. I've not implemented fence support here, but it would be an
>obvious addition.

My hardware won't necessarily finish by the next vsync -- it trickles
out at whatever rate it can find memory bandwidth to get the job done,
and fires an interrupt when it's finished.

So I would like some definition for how syncing works.  One answer would
be that these flips don't trigger their pageflip events until the
writeback is done (so I need to collect both the vsync irq and the
writeback irq before sending).  Another would be that manage an
independent fence for the writeback fb, so that you still immediately
know when framebuffers from the previous scanout-only frame are idle.

Also, tests for this in igt, please.  Writeback in igt will give us so
much more ability to cover KMS functionality on non-Intel hardware.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161011/5660dc94/attachment-0001.sig>

[PATCH]"drm: change DRM_MIPI_DSI module type from "bool" to "tristate".

[Andrzej Hajda]

On 11.10.2016 11:33, Jani Nikula wrote:
> On Tue, 11 Oct 2016, "Sun, Jing A"  wrote:
>> It's needed that DRM Driver module could be removed and reloaded after
>> kernel booting on the projects that I have been working on, and I hope
>> such module type change could be accepted. Looks like Iwai has similar
>> change request as well. Would you please review it and let us know if
>> any concerns?
> Looking at the Kconfig, selecting CONFIG_DRM_MIPI_DSI is against the
> recommendations of Documentation/kbuild/kconfig-language.txt:
>
>   select should be used with care. select will force
>   a symbol to a value without visiting the dependencies.
>   By abusing select you are able to select a symbol FOO even
>   if FOO depends on BAR that is not set.
>   In general use select only for non-visible symbols
>   (no prompts anywhere) and for symbols with no dependencies.
>   That will limit the usefulness but on the other hand avoid
>   the illegal configurations all over.

All existing drivers which selects DRM_MIPI_DSI also depends on DRM.
So the dependency is always true. I am not sure if it could not change in
the future, but in such case mipi_dsi bus should be completely detached from
DRM framework, I hope we have not such case yet :)

>
> Indeed, you may end up with CONFIG_DRM_MIPI_DSI=y and CONFIG_DRM=m,
> which violates DRM_MIPI_DSI dependency on CONFIG_DRM. This is broken and
> should be fixed. The suggested patch does *not* fix this issue.

At the moment it should not be possible.

Regards
Andrzej

[PATCH 2/9] drm/sun4i: tcon: Move SoC specific quirks to a DT matched data structure

[Maxime Ripard]

On Tue, Oct 11, 2016 at 05:16:21PM +0800, Chen-Yu Tsai wrote:
> On Fri, Oct 7, 2016 at 4:38 PM, Maxime Ripard
>  wrote:
> > Hi,
> >
> > On Fri, Oct 07, 2016 at 12:06:22AM +0800, Chen-Yu Tsai wrote:
> >> +struct sun4i_tcon_quirks {
> >> + boolis_sun5i;   /* sun5i has undocumented mux */
> >> + boolhas_channel_1;  /* a33 does not have channel 1 */
> >> + boolhas_bypass_src; /* has separate input bypassing CEU */
> >> + boolhas_dma_src;/* has DMA input */
> >> +};
> >> +
> >
> > I'd really prefer to keep the has_mux quirk name. is_sun5i doesn't
> > really relate to what we're doing there, is redundant with the
> > compatible, and render the other quirks name useless, since we could
> > just have is_sun.i quirks and deal with that (which is essentially
> > what we were doing before).
> 
> Lets call it has_unknown_mux then. has_mux would be confusing with
> the HDMI and MIPI DSI muxes on sun6i.

That works for me.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161011/c35796a0/attachment.sig>

[PATCH]"drm: change DRM_MIPI_DSI module type from "bool" to "tristate".

[Andrzej Hajda]

Hi,

This patch misses dsi bus un-registration.
However I have reviewed two patches of Takashi which solves
the same issue more completely [1]. These patches were not
accepted neither.

[1]:
https://lists.freedesktop.org/archives/dri-devel/2016-August/114870.html

Regards
Andrzej

On 11.10.2016 10:40, Sun, Jing A wrote:
> Dear Maintainers,
>
> It's needed that DRM Driver module could be removed and reloaded after kernel 
> booting on the projects that I have been working on, and I hope such module 
> type change could be accepted. Looks like Iwai has similar change request as 
> well. Would you please review it and let us know if any concerns?
>
> Regards,
> Sun, Jing
>
>
> -Original Message-
> From: Takashi Iwai [mailto:tiwai at suse.de] 
> Sent: Monday, October 10, 2016 5:57 PM
> To: Jani Nikula
> Cc: Sun, Jing A; airlied at linux.ie; Vetter, Daniel; linux-kernel at 
> vger.kernel.org; dri-devel at lists.freedesktop.org; Takashi Iwai; a.hajda at 
> samsung.com; Thierry Reding
> Subject: Re: [PATCH]"drm: change DRM_MIPI_DSI module type from "bool" to 
> "tristate".
>
> On Mon, 10 Oct 2016 10:28:31 +0200,
> Jani Nikula wrote:
>> On Mon, 10 Oct 2016, "Sun, Jing A"  wrote:
>>> Dear Maintainers,
>>>
>>> Please kindly review my patch as below. It's based on the mainline branch.
>>>
>>> From b401009f79883ac5e9d41525c9d54b800ece2e22 Mon Sep 17 00:00:00 
>>> 2001
>>> From: Jing SUN 
>>> Date: Mon, 10 Oct 2016 14:06:54 +0800
>>> Subject: [PATCH 1/1] drm: change DRM_MIPI_DSI module type from 
>>> "bool" to  "tristate".
>>>
>>> A lot of drm driver modules, which are designed to be loadable, 
>>> select DRM_MIPI_DSI, while that being "bool" prevents those from 
>>> getting reloaded.
>> You're missing some lists and people from distribution, added now.
>>
>> See the discussion starting at [1]. I don't know if anything has 
>> happened since then. Takashi?
> Unfortunately, nothing seems to have happened since my last patch due to 
> little interest.  I'd be glad if the patch is revived.
>
> (BTW, I'm traveling in these two weeks, so the further reply will be
>  delayed.)
>
>
> thanks,
>
> Takashi
>
>
>> BR,
>> Jani.
>>
>>
>> [1] http://lkml.kernel.org/r/s5hh9bhvj7j.wl-tiwai at suse.de
>>
>>
>>> Signed-off-by: Jing SUN 
>>> ---
>>>  drivers/gpu/drm/Kconfig | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 
>>> fc35731..67668a0 100644
>>> --- a/drivers/gpu/drm/Kconfig
>>> +++ b/drivers/gpu/drm/Kconfig
>>> @@ -22,7 +22,7 @@ menuconfig DRM
>>>   (/dev/agpgart) support if it is available for your platform.
>>>  
>>>  config DRM_MIPI_DSI
>>> -   bool
>>> +   tristate
>>> depends on DRM
>>>  
>>>  config DRM_DP_AUX_CHARDEV
>> --
>> Jani Nikula, Intel Open Source Technology Center
>>
>
>

drm/amd/powerplay: implement smu7 hwmgr to manager asics with smu ip version 7.

[Zhu, Rex]

Thanks. 
Please review the attached patches.


Best Regards
Rex

-Original Message-
From: Dan Carpenter [mailto:dan.carpen...@oracle.com] 
Sent: Tuesday, October 11, 2016 3:11 PM
To: Zhu, Rex
Cc: dri-devel at lists.freedesktop.org
Subject: re: drm/amd/powerplay: implement smu7 hwmgr to manager asics with smu 
ip version 7.

Hello Rex Zhu,

This is a semi-automatic email about new static checker warnings.

The patch 599a7e9fe1b6: "drm/amd/powerplay: implement smu7 hwmgr to manager 
asics with smu ip version 7." from Sep 9, 2016, leads to the following Smatch 
complaint:

drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/smu7_hwmgr.c:3809 
smu7_check_states_equal()
 warn: variable dereferenced before check 'pstate1' (see line 3805)

drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/smu7_hwmgr.c
  3804  {
  3805  const struct smu7_power_state *psa = 
cast_const_phw_smu7_power_state(pstate1);

 ^^^
  3806  const struct smu7_power_state *psb = 
cast_const_phw_smu7_power_state(pstate2);

 ^^^ New dereferences.

  3807  int i;
  3808  
  3809  if (pstate1 == NULL || pstate2 == NULL || equal == NULL)
^^
Checked too late.

Just as an aside.  People really don't review code in initializers.
I've commented on this before, and other people have noted it as well but other 
people are like "In that case, those people shouldn't be kernel devs!" which is 
so ignorant.  Everyone consistently makes the same mistakes.  I've spent so 
many hours looking at basically this same bug over and over and everyone does 
it.

That's nothing to do with your code, in particular, I just wanted to update you 
on how my morning has been going.  (Pretty well, thanks, although I'm due for a 
second cup of coffee).

  3810  return -EINVAL;
  3811  

regards,
dan carpenter
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-amd-powerplay-add-array-length-check-to-avoid-bu.patch
Type: application/octet-stream
Size: 1189 bytes
Desc: 0001-drm-amd-powerplay-add-array-length-check-to-avoid-bu.patch
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161011/4cb46a8f/attachment-0002.obj>
-- next part --
A non-text attachment was scrubbed...
Name: 0002-drm-amd-powerplay-fix-bug-variable-dereferenced-befo.patch
Type: application/octet-stream
Size: 1518 bytes
Desc: 0002-drm-amd-powerplay-fix-bug-variable-dereferenced-befo.patch
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161011/4cb46a8f/attachment-0003.obj>

[PATCH 1/1] gpu: drm: gma500: Use vma_pages()

[Patrik Jakobsson]

On Tue, Oct 11, 2016 at 10:15 AM, Daniel Vetter  wrote:
> On Mon, Oct 10, 2016 at 07:22:47AM +0530, Shyam Saini wrote:
>> On Mon, 2016-10-10 at 01:46 +0200, Patrik Jakobsson wrote:
>> > On Mon, Oct 10, 2016 at 1:07 AM, Shyam Saini 
>> > wrote:
>> > >
>> > > Replace explicit computation of vma page count by a call to
>> > > vma_pages()
>> > Hi, I already have this patch in the "queue" from:
>> > Muhammad Falak R Wani 
>> >
>> > Will include that one when I get around to sending out a PR.
>
> Since the merge window is pretty much done I've applied this one here to
> drm-misc to make sure it wont get lost.
> -Daniel
>

Thanks, I'll take them out of my queue that never got sent.

-Patrik

>> >
>> > Thanks
>> > Patrik
>> >
>> > >
>> > >
>> > > Signed-off-by: Shyam Saini 
>> > > ---
>> > >  drivers/gpu/drm/gma500/framebuffer.c | 2 +-
>> > >  1 file changed, 1 insertion(+), 1 deletion(-)
>> > >
>> > > diff --git a/drivers/gpu/drm/gma500/framebuffer.c
>> > > b/drivers/gpu/drm/gma500/framebuffer.c
>> > > index 3a44e70..0fde850 100644
>> > > --- a/drivers/gpu/drm/gma500/framebuffer.c
>> > > +++ b/drivers/gpu/drm/gma500/framebuffer.c
>> > > @@ -124,7 +124,7 @@ static int psbfb_vm_fault(struct vm_area_struct
>> > > *vma, struct vm_fault *vmf)
>> > > unsigned long phys_addr = (unsigned long)dev_priv-
>> > > >stolen_base +
>> > >   psbfb->gtt->offset;
>> > >
>> > > -   page_num = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
>> > > +   page_num = vma_pages(vma);
>> > > address = (unsigned long)vmf->virtual_address - (vmf->pgoff
>> > > << PAGE_SHIFT);
>> > >
>> > > vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
>> > > --
>> > > 2.7.4
>> > >
>>
>> No issue.
>>
>> Thanks
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

[PATCH] drm/gma500: remove useless comment

[Daniel Vetter]

On Tue, Oct 11, 2016 at 02:03:45PM +0800, Jiang Biao wrote:
> Remove useless comment in framebuffer.c.
> 
> Signed-off-by: Jiang Biao 

Applied to drm-misc.
-Daniel

> ---
>  drivers/gpu/drm/gma500/framebuffer.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/gma500/framebuffer.c 
> b/drivers/gpu/drm/gma500/framebuffer.c
> index 0fcdce0..3c8aa55 100644
> --- a/drivers/gpu/drm/gma500/framebuffer.c
> +++ b/drivers/gpu/drm/gma500/framebuffer.c
> @@ -299,7 +299,6 @@ static struct drm_framebuffer *psb_framebuffer_create
>   *   psbfb_alloc -   allocate frame buffer memory
>   *   @dev: the DRM device
>   *   @aligned_size: space needed
> - *   @force: fall back to GEM buffers if need be
>   *
>   *   Allocate the frame buffer. In the usual case we get a GTT range that
>   *   is stolen memory backed and life is simple. If there isn't sufficient
> -- 
> 2.1.0
> 

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

[PATCH 1/1] gpu: drm: gma500: Use vma_pages()

[Daniel Vetter]

On Mon, Oct 10, 2016 at 07:22:47AM +0530, Shyam Saini wrote:
> On Mon, 2016-10-10 at 01:46 +0200, Patrik Jakobsson wrote:
> > On Mon, Oct 10, 2016 at 1:07 AM, Shyam Saini 
> > wrote:
> > > 
> > > Replace explicit computation of vma page count by a call to
> > > vma_pages()
> > Hi, I already have this patch in the "queue" from:
> > Muhammad Falak R Wani 
> > 
> > Will include that one when I get around to sending out a PR.

Since the merge window is pretty much done I've applied this one here to
drm-misc to make sure it wont get lost.
-Daniel

> > 
> > Thanks
> > Patrik
> > 
> > > 
> > > 
> > > Signed-off-by: Shyam Saini 
> > > ---
> > >  drivers/gpu/drm/gma500/framebuffer.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/gma500/framebuffer.c
> > > b/drivers/gpu/drm/gma500/framebuffer.c
> > > index 3a44e70..0fde850 100644
> > > --- a/drivers/gpu/drm/gma500/framebuffer.c
> > > +++ b/drivers/gpu/drm/gma500/framebuffer.c
> > > @@ -124,7 +124,7 @@ static int psbfb_vm_fault(struct vm_area_struct
> > > *vma, struct vm_fault *vmf)
> > >         unsigned long phys_addr = (unsigned long)dev_priv-
> > > >stolen_base +
> > >                                   
> > > psbfb->gtt->offset;
> > > 
> > > -       page_num = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
> > > +       page_num = vma_pages(vma);
> > >         address = (unsigned long)vmf->virtual_address - 
> > > (vmf->pgoff 
> > > << PAGE_SHIFT);
> > > 
> > >         vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
> > > --
> > > 2.7.4
> > > 
> 
> No issue.
> 
> Thanks
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

drm/amd/powerplay: implement smu7 hwmgr to manager asics with smu ip version 7.

[Dan Carpenter]

Hello Rex Zhu,

This is a semi-automatic email about new static checker warnings.

The patch 599a7e9fe1b6: "drm/amd/powerplay: implement smu7 hwmgr to 
manager asics with smu ip version 7." from Sep 9, 2016, leads to the 
following Smatch complaint:

drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/smu7_hwmgr.c:3809 
smu7_check_states_equal()
 warn: variable dereferenced before check 'pstate1' (see line 3805)

drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/smu7_hwmgr.c
  3804  {
  3805  const struct smu7_power_state *psa = 
cast_const_phw_smu7_power_state(pstate1);

 ^^^
  3806  const struct smu7_power_state *psb = 
cast_const_phw_smu7_power_state(pstate2);

 ^^^
New dereferences.

  3807  int i;
  3808  
  3809  if (pstate1 == NULL || pstate2 == NULL || equal == NULL)
^^
Checked too late.

Just as an aside.  People really don't review code in initializers.
I've commented on this before, and other people have noted it as well
but other people are like "In that case, those people shouldn't be
kernel devs!" which is so ignorant.  Everyone consistently makes the
same mistakes.  I've spent so many hours looking at basically this same
bug over and over and everyone does it.

That's nothing to do with your code, in particular, I just wanted to
update you on how my morning has been going.  (Pretty well, thanks,
although I'm due for a second cup of coffee).

  3810  return -EINVAL;
  3811  

regards,
dan carpenter

[PULL] topic/drm-misc

[Daniel Vetter]

Hi Dave,

Just flushing out my -misc queue. Slightly important are the prime
refcount/unload fixes from Chris.

There's also the reservation stuff from Chris still pending, and Sumits
hasn't landed that yet. Might get another pull for that, but pls don't
hold up the main pull for it ;-)

Cheers, Daniel


The following changes since commit 0546d685f07cc4fc5748fd36e57d167877c2842d:

  drm/rockchip: analogix_dp: Refuse to enable PSR if panel doesn't support it 
(2016-10-04 08:23:17 +0200)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/topic/drm-misc-2016-10-11

for you to fetch changes up to a5bd451b6e6ece69be07a425381c4f3438eadba0:

  drm/crtc: constify drm_crtc_index parameter (2016-10-10 17:28:58 +0200)


Chris Wilson (3):
  drm/prime: Pass the right module owner through to dma_buf_export()
  drm/prime: Take a ref on the drm_dev when exporting a dma_buf
  drm: Fix up kerneldoc for new drm_gem_dmabuf_export()

Christophe JAILLET (2):
  drm: Release resources with a safer function
  drm: Release resources with a safer function

Grazvydas Ignotas (1):
  drm: use the right function name in documentation

Jani Nikula (1):
  drm/crtc: constify drm_crtc_index parameter

Marek Vasut (3):
  drm: simple_kms_helper: Add prepare_fb and cleanup_fb hooks
  drm/bridge: Call drm_connector_cleanup directly
  drm/bridge: Drop drm_connector_unregister and call drm_connector_cleanup 
directly

Maxime Ripard (1):
  drm/bridge: Add RGB to VGA bridge support

Stefan Christ (1):
  drm/fb-helper: fix sphinx markup for DRM_FB_HELPER_DEFAULT_OPS

 .../bindings/display/bridge/dumb-vga-dac.txt   |  48 +
 drivers/gpu/drm/armada/armada_gem.c|   2 +-
 drivers/gpu/drm/bridge/Kconfig |   7 +
 drivers/gpu/drm/bridge/Makefile|   1 +
 drivers/gpu/drm/bridge/analogix-anx78xx.c  |   7 +-
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c |   9 +-
 drivers/gpu/drm/bridge/dumb-vga-dac.c  | 223 +
 drivers/gpu/drm/bridge/dw-hdmi.c   |   8 +-
 drivers/gpu/drm/bridge/nxp-ptn3460.c   |   7 +-
 drivers/gpu/drm/bridge/parade-ps8622.c |   7 +-
 drivers/gpu/drm/bridge/tc358767.c  |   8 +-
 drivers/gpu/drm/drm_connector.c|  12 +-
 drivers/gpu/drm/drm_prime.c|  48 -
 drivers/gpu/drm/drm_simple_kms_helper.c|  26 +++
 drivers/gpu/drm/i915/i915_gem_dmabuf.c |   2 +-
 drivers/gpu/drm/tegra/gem.c|   2 +-
 drivers/gpu/drm/udl/udl_dmabuf.c   |   2 +-
 include/drm/drmP.h |   7 +-
 include/drm/drm_connector.h|   4 +-
 include/drm/drm_crtc.h |   2 +-
 include/drm/drm_fb_helper.h|   2 +-
 include/drm/drm_simple_kms_helper.h|  20 ++
 22 files changed, 391 insertions(+), 63 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
 create mode 100644 drivers/gpu/drm/bridge/dumb-vga-dac.c

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

[bug report] drm/amd/powerplay: implement fw related smu interface for iceland.

[Dan Carpenter]

Hello Rex Zhu,

The patch 18aafc59b106: "drm/amd/powerplay: implement fw related smu
interface for iceland." from Aug 23, 2016, leads to the following
static checker warning:

drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/iceland_smc.c:2462 
iceland_set_mc_special_registers()
error: buffer overflow 'table->mc_reg_address' 16 <= 16

drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/iceland_smc.c
  2441  j++;
  2442  PP_ASSERT_WITH_CODE((j < 
SMU71_DISCRETE_MC_REGISTER_ARRAY_SIZE),
 ^^
Note the < here.

  2443  "Invalid VramInfo table.", return 
-EINVAL);
  2444  
  2445  temp_reg = cgs_read_register(hwmgr->device, 
mmMC_PMG_CMD_MRS);
  2446  table->mc_reg_address[j].s1 = mmMC_PMG_CMD_MRS;
  2447  table->mc_reg_address[j].s0 = 
mmMC_SEQ_PMG_CMD_MRS_LP;
  2448  for (k = 0; k < table->num_entries; k++) {
  2449  table->mc_reg_table_entry[k].mc_data[j] 
=
  2450  (temp_reg & 0x) |
  2451  
(table->mc_reg_table_entry[k].mc_data[i] & 0x);
  2452  
  2453  if (!data->is_memory_gddr5) {
  2454  
table->mc_reg_table_entry[k].mc_data[j] |= 0x100;
  2455  }
  2456  }
  2457  j++;
  2458  PP_ASSERT_WITH_CODE((j <= 
SMU71_DISCRETE_MC_REGISTER_ARRAY_SIZE),


This should be < as well.

  2459  "Invalid VramInfo table.", return 
-EINVAL);
  2460  
  2461  if (!data->is_memory_gddr5) {
  2462  table->mc_reg_address[j].s1 = 
mmMC_PMG_AUTO_CMD;
  2463  table->mc_reg_address[j].s0 = 
mmMC_PMG_AUTO_CMD;
  2464  for (k = 0; k < table->num_entries; 
k++) {
  2465  
table->mc_reg_table_entry[k].mc_data[j] =
  2466  
(table->mc_reg_table_entry[k].mc_data[i] & 0x) >> 16;
  2467  }
  2468  j++;
  2469  PP_ASSERT_WITH_CODE((j <= 
SMU71_DISCRETE_MC_REGISTER_ARRAY_SIZE),

But I don't know about this one.

  2470  "Invalid VramInfo table.", 
return -EINVAL);
  2471  }
  2472  
  2473  break;
  2474  
  2475  case mmMC_SEQ_RESERVE_M:


regards,
dan carpenter

[Bug 98170] [vdpau] Error when calling vdp_output_surface_create

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

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

--- Comment #2 from Branko  ---
(In reply to Michel Dänzer from comment #1)
> Can you bisect?

Sorry, I don't understand what you mean.

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

[PATCH]"drm: change DRM_MIPI_DSI module type from "bool" to "tristate".

[Sun, Jing A]

Dear Maintainers,

It's needed that DRM Driver module could be removed and reloaded after kernel 
booting on the projects that I have been working on, and I hope such module 
type change could be accepted. Looks like Iwai has similar change request as 
well. Would you please review it and let us know if any concerns?

Regards,
Sun, Jing


-Original Message-
From: Takashi Iwai [mailto:ti...@suse.de] 
Sent: Monday, October 10, 2016 5:57 PM
To: Jani Nikula
Cc: Sun, Jing A; airlied at linux.ie; Vetter, Daniel; linux-kernel at 
vger.kernel.org; dri-devel at lists.freedesktop.org; Takashi Iwai; a.hajda at 
samsung.com; Thierry Reding
Subject: Re: [PATCH]"drm: change DRM_MIPI_DSI module type from "bool" to 
"tristate".

On Mon, 10 Oct 2016 10:28:31 +0200,
Jani Nikula wrote:
> 
> On Mon, 10 Oct 2016, "Sun, Jing A"  wrote:
> > Dear Maintainers,
> >
> > Please kindly review my patch as below. It's based on the mainline branch.
> >
> > From b401009f79883ac5e9d41525c9d54b800ece2e22 Mon Sep 17 00:00:00 
> > 2001
> > From: Jing SUN 
> > Date: Mon, 10 Oct 2016 14:06:54 +0800
> > Subject: [PATCH 1/1] drm: change DRM_MIPI_DSI module type from 
> > "bool" to  "tristate".
> >
> > A lot of drm driver modules, which are designed to be loadable, 
> > select DRM_MIPI_DSI, while that being "bool" prevents those from 
> > getting reloaded.
> 
> You're missing some lists and people from distribution, added now.
> 
> See the discussion starting at [1]. I don't know if anything has 
> happened since then. Takashi?

Unfortunately, nothing seems to have happened since my last patch due to little 
interest.  I'd be glad if the patch is revived.

(BTW, I'm traveling in these two weeks, so the further reply will be
 delayed.)


thanks,

Takashi


> 
> BR,
> Jani.
> 
> 
> [1] http://lkml.kernel.org/r/s5hh9bhvj7j.wl-tiwai at suse.de
> 
> 
> >
> > Signed-off-by: Jing SUN 
> > ---
> >  drivers/gpu/drm/Kconfig | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 
> > fc35731..67668a0 100644
> > --- a/drivers/gpu/drm/Kconfig
> > +++ b/drivers/gpu/drm/Kconfig
> > @@ -22,7 +22,7 @@ menuconfig DRM
> >   (/dev/agpgart) support if it is available for your platform.
> >  
> >  config DRM_MIPI_DSI
> > -   bool
> > +   tristate
> > depends on DRM
> >  
> >  config DRM_DP_AUX_CHARDEV
> 
> --
> Jani Nikula, Intel Open Source Technology Center
> 

[Bug 98146] DRI_PRIME=1 and fullscreen issues

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

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

--- Comment #12 from Michel Dänzer  ---
I suspect the intel driver only supports the

 Option "DRI" "3"

notation to enable DRI3 at runtime. If that doesn't work:

* Make sure the Section "Device" with that option is actually being used
* Make sure that DRI3 is enabled in the xf86-video-intel build; if in doubt,
try
  passing --enable-dri3 to its configure script

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

[Bug 98146] DRI_PRIME=1 and fullscreen issues

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

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

--- Comment #11 from Darek Deoniziak  ---
DRI_PRIME=1 LIBGL_DEBUG=verbose glxinfo >/dev/null:
libGL: screen 0 does not appear to be DRI3 capable
libGL: pci id for fd 4: 1002:6604, driver radeonsi
libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/tls/radeonsi_dri.so
libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
libGL: Can't open configuration file /home/darek/.drirc: No such file or
directory.
libGL: Can't open configuration file /home/darek/.drirc: No such file or
directory.

LIBGL_DEBUG=verbose glxinfo >/dev/null:
libGL: screen 0 does not appear to be DRI3 capable
libGL: pci id for fd 4: 8086:1616, driver i965
libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/tls/i965_dri.so
libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
libGL: Can't open configuration file /home/darek/.drirc: No such file or
directory.
libGL: Using DRI2 for screen 0
libGL: Can't open configuration file /home/darek/.drirc: No such file or
directory.
libGL: Can't open configuration file /home/darek/.drirc: No such file or
directory.
libGL: Can't open configuration file /home/darek/.drirc: No such file or
directory.

It seems that I'm still using DRI2, how can I change that, am I missing some
libraries?

I am also using git version of mesa drivers, could closing fullscreen freezing
stop after recent updates? I couldn't reproduce freezing (4) and hdmi issues
while pressing fn button to change display (5) for last few days.

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

[Bug 98170] [vdpau] Error when calling vdp_output_surface_create

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

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

--- Comment #1 from Michel Dänzer  ---
Can you bisect?

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

[Bug 98146] DRI_PRIME=1 and fullscreen issues

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

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

--- Comment #10 from Michel Dänzer  ---
DRI_PRIME=1 LIBGL_DEBUG=verbose glxinfo >/dev/null

prints on stderr whether it's using DRI3 or DRI2.

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

[radeon-alex:amd-staging-4.7 5/11] drivers/gpu/drm/amd/amdgpu/dce_virtual.c:662:3: warning: 'connector' may be used uninitialized in this function

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-4.7
head:   517e97f3ca3ec310723e8cfef69fdffb7774d5fc
commit: babb7eaf81f0e146b73170cfaafee5b10a5e2262 [5/11] drm/amdgpu: simplify 
encoder and connector setup
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 6.2.0
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout babb7eaf81f0e146b73170cfaafee5b10a5e2262
# save the attached .config to linux build tree
make.cross ARCH=ia64 

Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings

All warnings (new ones prefixed by >>):

   drivers/gpu/drm/amd/amdgpu/dce_virtual.c: In function 'dce_virtual_sw_init':
>> drivers/gpu/drm/amd/amdgpu/dce_virtual.c:662:3: warning: 'connector' may be 
>> used uninitialized in this function [-Wmaybe-uninitialized]
  kfree(connector);
  ^~~~
   drivers/gpu/drm/amd/amdgpu/dce_virtual.c:657:24: note: 'connector' was 
declared here
 struct drm_connector *connector;
   ^

vim +/connector +662 drivers/gpu/drm/amd/amdgpu/dce_virtual.c

   646  kfree(amdgpu_encoder);
   647  }
   648  
   649  static const struct drm_encoder_funcs dce_virtual_encoder_funcs = {
   650  .destroy = dce_virtual_encoder_destroy,
   651  };
   652  
   653  static int dce_virtual_connector_encoder_init(struct amdgpu_device 
*adev,
   654int index)
   655  {
   656  struct drm_encoder *encoder;
   657  struct drm_connector *connector;
   658  
   659  /* add a new encoder */
   660  encoder = kzalloc(sizeof(struct drm_encoder), GFP_KERNEL);
   661  if (!encoder) {
 > 662  kfree(connector);
   663  return -ENOMEM;
   664  }
   665  encoder->possible_crtcs = 1 << index;
   666  drm_encoder_init(adev->ddev, encoder, 
_virtual_encoder_funcs,
   667   DRM_MODE_ENCODER_VIRTUAL, NULL);
   668  drm_encoder_helper_add(encoder, 
_virtual_encoder_helper_funcs);
   669  
   670  connector = kzalloc(sizeof(struct drm_connector), GFP_KERNEL);

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 43764 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161011/f14c6662/attachment-0001.gz>

[Bug 94726] [Tonga] ARK: Survival Evolved crashes on savegame load. Out of Memory

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

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

Michel Dänzer  changed:

   What|Removed |Added

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

--- Comment #13 from Michel Dänzer  ---
(In reply to thomas.rinsch from comment #12)
> I kept trying to load the savegame occasionally and today it worked again.

Glad to hear that.

> Haven't tried it in a while, so I don't know if it was an application side
> change or a mesa change.

I'd say it's most likely one of Nicolai's recent Mesa changes.

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

[Bug 51381] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting, when disabled via vgaswitcheroo

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

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

--- Comment #49 from Teofilis Martisius  ---
Hi,

Ok, I got my laptop fixed and now my BIOS is v2.14 (was 2.06). Nothing changed. 

I have tested with kernel v4.8. I get same errors as in 4.8-rc4.

Please let me know what else can I do to help get this solved.

I'll try to reproduce this with v4.9 when it's closer to release.

Sincerely,
Teofilis Martisius

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

[Bug 95017] [drm:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB on GFX ring (-35).

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

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

--- Comment #14 from erhard_f at mailbox.org ---
It seems the patches to force Radeon cards into PCI-mode (or force it via
radeon.agpmode=-1) are no definitive solution. My G4 and G5 Macs hold out
longer running X but sooner or later a hard lock is unavoidable. Tested this on
a recent software stack: 4.8.1-kernel, xorg-server-1.18.4, xf86-video-ati-7.7.1
and mesa-12.0.3.

See my comment at Bug 94877.

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