Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1623612 > unrolled thread

Re: [RFC PATCH v3 0/6] Introduce writeback connectors

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [RFC PATCH v3 0/6] Introduce writeback connectors Boris Brezillon <boris.brezillon@free-electrons.com> - 2017-04-14 11:40 +0200
    Re: [RFC PATCH v3 0/6] Introduce writeback connectors Brian Starkey <brian.starkey@arm.com> - 2017-04-18 19:40 +0200

#1623612 — Re: [RFC PATCH v3 0/6] Introduce writeback connectors

Hi Brian,

On Fri, 25 Nov 2016 16:48:58 +0000
Brian Starkey <brian.starkey@arm.com> wrote:

> Hi,
> 
> This is v3 of my series introducing a new connector type:
>  DRM_MODE_CONNECTOR_WRITEBACK
> See v1 and v2 here: [1] [2]
> 
> 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.
> 
> Writeback connectors are given a WRITEBACK_FB_ID property (which acts
> slightly differently to FB_ID, so gets a new name), as well as
> a PIXEL_FORMATS blob to list the supported writeback formats, and
> OUT_FENCE_PTR to be used for out-fences.
> 
> The changes since v2 are in the commit messages of each commit.
> 
> The main differences are:
>  - Subclass drm_connector as drm_writeback_connector
>  - Slight relaxation of core checks, to allow
>    (connector->crtc && !connector->fb)
>  - Dropped PIXEL_FORMATS_SIZE, which was redundant
>  - Reworked the event interface, drivers don't need to deal with the
>    fence directly
>  - Re-ordered the commits to introduce writeback out-fences up-front.
> 
> I've kept RFC on this series because the event reporting (introduction
> of drm_writeback_job) is probably up for debate.
> 
> v4 will be accompanied by igt tests.

I plan to add writeback support to the VC4 driver and wanted to know if
anything has changed since this v3 (IOW, do you have a v4 + igt tests
ready)?

> 
> As always, I look forward to any comments.

I'll try to review these patches. Keep in mind that I didn't follow the
initial discussions and might suggest things or ask questions that have
already been answered in previous versions of this series or on IRC.

Regards,

Boris

[toc] | [next] | [standalone]

#1625491

Hi Boris,

On Fri, Apr 14, 2017 at 11:35:17AM +0200, Boris Brezillon wrote:
>Hi Brian,
>
>On Fri, 25 Nov 2016 16:48:58 +0000
>Brian Starkey <brian.starkey@arm.com> wrote:
>
>> Hi,
>>
>> This is v3 of my series introducing a new connector type:
>>  DRM_MODE_CONNECTOR_WRITEBACK
>> See v1 and v2 here: [1] [2]
>>
>> 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.
>>
>> Writeback connectors are given a WRITEBACK_FB_ID property (which acts
>> slightly differently to FB_ID, so gets a new name), as well as
>> a PIXEL_FORMATS blob to list the supported writeback formats, and
>> OUT_FENCE_PTR to be used for out-fences.
>>
>> The changes since v2 are in the commit messages of each commit.
>>
>> The main differences are:
>>  - Subclass drm_connector as drm_writeback_connector
>>  - Slight relaxation of core checks, to allow
>>    (connector->crtc && !connector->fb)
>>  - Dropped PIXEL_FORMATS_SIZE, which was redundant
>>  - Reworked the event interface, drivers don't need to deal with the
>>    fence directly
>>  - Re-ordered the commits to introduce writeback out-fences up-front.
>>
>> I've kept RFC on this series because the event reporting (introduction
>> of drm_writeback_job) is probably up for debate.
>>
>> v4 will be accompanied by igt tests.
>
>I plan to add writeback support to the VC4 driver and wanted to know if
>anything has changed since this v3 (IOW, do you have a v4 + igt tests
>ready)?
>

Oh that's good to hear. I've got a v4 (just rebased for the most
part), but was holding off sending it until having some "proper"
userspace to support it. Unfortunately in the meantime we've had some
team changes which mean I'm not really able to work on it to move
things forward - Liviu might be able to pick this up.

I'll collect together what I have and send it out anyway. It includes
some functional tests in igt, but I'm not sure if that meets the "new
uapi needs userspace" bar.

>>
>> As always, I look forward to any comments.
>
>I'll try to review these patches. Keep in mind that I didn't follow the
>initial discussions and might suggest things or ask questions that have
>already been answered in previous versions of this series or on IRC.

Thanks,

-Brian

>
>Regards,
>
>Boris

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web