Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1498946 > unrolled thread
| Started by | Brian Starkey <brian.starkey@arm.com> |
|---|---|
| First post | 2016-10-11 17:00 +0200 |
| Last post | 2016-10-12 09:40 +0200 |
| Articles | 4 on this page of 24 — 4 participants |
Back to article view | Back to linux.kernel
[RFC PATCH 00/11] Introduce writeback connectors Brian Starkey <brian.starkey@arm.com> - 2016-10-11 17:00 +0200
[RFC PATCH 10/11] drm: mali-dp: Add support for writeback on DP550/DP650 Brian Starkey <brian.starkey@arm.com> - 2016-10-11 17:00 +0200
[RFC PATCH 09/11] drm: mali-dp: Add RGB writeback formats for DP550/DP650 Brian Starkey <brian.starkey@arm.com> - 2016-10-11 17:00 +0200
[RFC PATCH 02/11] drm/fb-helper: Skip writeback connectors Brian Starkey <brian.starkey@arm.com> - 2016-10-11 17:00 +0200
Re: [RFC PATCH 02/11] drm/fb-helper: Skip writeback connectors Daniel Vetter <daniel@ffwll.ch> - 2016-10-11 17:50 +0200
Re: [RFC PATCH 02/11] drm/fb-helper: Skip writeback connectors Brian Starkey <brian.starkey@arm.com> - 2016-10-11 18:50 +0200
Re: [RFC PATCH 02/11] drm/fb-helper: Skip writeback connectors Daniel Vetter <daniel@ffwll.ch> - 2016-10-11 19:00 +0200
[RFC PATCH 05/11] drm: Add fb to connector state Brian Starkey <brian.starkey@arm.com> - 2016-10-11 17:00 +0200
[RFC PATCH 01/11] drm: Add writeback connector type Brian Starkey <brian.starkey@arm.com> - 2016-10-11 17:00 +0200
[RFC PATCH 04/11] drm: Add __drm_framebuffer_remove_atomic Brian Starkey <brian.starkey@arm.com> - 2016-10-11 17:00 +0200
Re: [RFC PATCH 04/11] drm: Add __drm_framebuffer_remove_atomic Daniel Vetter <daniel@ffwll.ch> - 2016-10-11 18:10 +0200
[RFC PATCH 08/11] drm: mali-dp: Rename malidp_input_format Brian Starkey <brian.starkey@arm.com> - 2016-10-11 17:00 +0200
[RFC PATCH 11/11] drm: mali-dp: Add writeback connector Brian Starkey <brian.starkey@arm.com> - 2016-10-11 17:00 +0200
Re: [RFC PATCH 00/11] Introduce writeback connectors Daniel Vetter <daniel@ffwll.ch> - 2016-10-11 17:50 +0200
Re: [RFC PATCH 00/11] Introduce writeback connectors Brian Starkey <brian.starkey@arm.com> - 2016-10-11 19:00 +0200
Re: [RFC PATCH 00/11] Introduce writeback connectors Daniel Vetter <daniel@ffwll.ch> - 2016-10-11 19:10 +0200
Re: [RFC PATCH 00/11] Introduce writeback connectors Brian Starkey <brian.starkey@arm.com> - 2016-10-11 21:50 +0200
Re: [RFC PATCH 00/11] Introduce writeback connectors Daniel Vetter <daniel@ffwll.ch> - 2016-10-11 22:10 +0200
Re: [RFC PATCH 00/11] Introduce writeback connectors Brian Starkey <brian.starkey@arm.com> - 2016-10-11 23:30 +0200
Re: [RFC PATCH 00/11] Introduce writeback connectors Daniel Vetter <daniel@ffwll.ch> - 2016-10-12 09:00 +0200
Re: [RFC PATCH 00/11] Introduce writeback connectors Daniel Vetter <daniel@ffwll.ch> - 2016-10-11 18:30 +0200
Re: [RFC PATCH 00/11] Introduce writeback connectors Ville Syrjälä <ville.syrjala@linux.intel.com> - 2016-10-11 18:30 +0200
Re: [RFC PATCH 00/11] Introduce writeback connectors Eric Anholt <eric@anholt.net> - 2016-10-11 21:10 +0200
Re: [RFC PATCH 00/11] Introduce writeback connectors Brian Starkey <brian.starkey@arm.com> - 2016-10-12 09:40 +0200
Page 2 of 2 — ← Prev page 1 [2]
| From | Daniel Vetter <daniel@ffwll.ch> |
|---|---|
| Date | 2016-10-11 18:30 +0200 |
| Message-ID | <sr86d-wM-15@gated-at.bofh.it> |
| In reply to | #1498946 |
On Tue, Oct 11, 2016 at 6:25 PM, Ville Syrjälä <ville.syrjala@linux.intel.com> 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
[toc] | [prev] | [next] | [standalone]
| From | Ville Syrjälä <ville.syrjala@linux.intel.com> |
|---|---|
| Date | 2016-10-11 18:30 +0200 |
| Message-ID | <sr86d-wM-3@gated-at.bofh.it> |
| In reply to | #1498946 |
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 | 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 -- Ville Syrjälä Intel OTC
[toc] | [prev] | [next] | [standalone]
| From | Eric Anholt <eric@anholt.net> |
|---|---|
| Date | 2016-10-11 21:10 +0200 |
| Message-ID | <sraB4-2b0-35@gated-at.bofh.it> |
| In reply to | #1498946 |
[Multipart message — attachments visible in raw view] — view raw
Brian Starkey <brian.starkey@arm.com> 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.
[toc] | [prev] | [next] | [standalone]
| From | Brian Starkey <brian.starkey@arm.com> |
|---|---|
| Date | 2016-10-12 09:40 +0200 |
| Message-ID | <srmiS-1dk-17@gated-at.bofh.it> |
| In reply to | #1499162 |
Hi Eric, On Tue, Oct 11, 2016 at 12:01:14PM -0700, Eric Anholt wrote: >Brian Starkey <brian.starkey@arm.com> 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. > Thanks, glad you like it! Hopefully you're equally agreeable with the changes Daniel has been suggesting. >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. > Agreed - we've never found a use for it. >> 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. > Is it bounded? You presumably have to finish the write-out before you can change any input buffers? >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. > I much prefer the sound of the explicit fence approach. Hopefully we can agree that a new atomic commit can't be completed whilst there's a writeback ongoing, otherwise managing the fence and framebuffer lifetime sounds really tricky - they'd need to be decoupled from the atomic_state and outlive the commit that spawned them. Cheers, -Brian >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.
[toc] | [prev] | [standalone]
Page 2 of 2 — ← Prev page 1 [2]
Back to top | Article view | linux.kernel
csiph-web