Hi Boris,
On Tue, Mar 19, 2019 at 03:52:42PM +0100, Boris Brezillon wrote:
> This is part of the multiplanar and singleplanar unification process.
> v4l2_ext_pix_format is supposed to work for both cases.
>
> We also add the concept of modifiers already employed in DRM to expose
> HW-specific for
On Thu, Feb 21, 2019 at 02:23:10PM +0200, Laurent Pinchart wrote:
> On Thu, Feb 21, 2019 at 12:19:13PM +0000, Brian Starkey wrote:
[snip]
> >
> > I used a pre-existing internal tool which does exactly that.
>
> Any hope of sharing the sources ?
>
Not in a timescal
Hi Laurent,
On Thu, Feb 21, 2019 at 12:02:57PM +0200, Laurent Pinchart wrote:
> Hi Brian,
>
> On Thu, Feb 21, 2019 at 09:50:19AM +0000, Brian Starkey wrote:
> > On Thu, Feb 21, 2019 at 10:23:17AM +0200, Laurent Pinchart wrote:
> > > On Mon, Feb 18, 2019 at 12:22:58PM +0
Hi Laurent,
On Thu, Feb 21, 2019 at 10:23:17AM +0200, Laurent Pinchart wrote:
> Hi Brian,
>
> On Mon, Feb 18, 2019 at 12:22:58PM +0000, Brian Starkey wrote:
> > On Sun, Feb 17, 2019 at 04:48:45AM +0200, Laurent Pinchart wrote:
> > > Hello,
> > >
> >
Hi Laurent,
On Sun, Feb 17, 2019 at 04:48:45AM +0200, Laurent Pinchart wrote:
> Hello,
>
> This patch series implements display writeback support for the R-Car
> Gen3 platforms in the VSP1 driver.
>
> DRM/KMS provides a writeback API through a special type of writeback
> connectors. This series
Hi Ezequiel,
Not sure if this patch series is still relevant, but I spotted a
couple more things below.
On Mon, May 21, 2018 at 01:59:43PM -0300, Ezequiel Garcia wrote:
From: Gustavo Padovan
If V4L2_BUF_FLAG_OUT_FENCE flag is present on the QBUF call we create
an out_fence and send its fd to
On Wed, May 09, 2018 at 01:03:15PM -0300, Ezequiel Garcia wrote:
On Wed, 2018-05-09 at 11:36 +0100, Brian Starkey wrote:
[..]
> @@ -203,9 +215,14 @@ static void __fill_v4l2_buffer(struct vb2_buffer *vb,
void *pb)
>b->timestamp = ns_to_timeval(vb->timestamp);
>b-&
On Wed, May 09, 2018 at 12:52:26PM -0300, Ezequiel Garcia wrote:
On Wed, 2018-05-09 at 11:33 +0100, Brian Starkey wrote:
Hi Ezequiel,
On Fri, May 04, 2018 at 05:06:07PM -0300, Ezequiel Garcia wrote:
> From: Gustavo Padovan
>
> Turn the reserved2 field into fence_fd that we will us
Hi,
On Fri, May 04, 2018 at 05:06:09PM -0300, Ezequiel Garcia wrote:
From: Gustavo Padovan
If V4L2_BUF_FLAG_OUT_FENCE flag is present on the QBUF call we create
an out_fence and send its fd to userspace in the fence_fd field as a
return arg for the QBUF call.
The fence is signaled on buffer_d
fences always keep the order userspace queues the buffers.
- Protect in_fence manipulation with a lock (Brian Starkey)
- check if fences have the same context before adding a fence array
- Fix last_fence ref unbalance in __set_in_fence() (Brian Starkey)
- Clean up fence if __set_in_
Hi,
On Tue, May 08, 2018 at 08:18:06PM -0300, Gustavo Padovan wrote:
Hi Hans,
On Mon, 2018-05-07 at 14:07 +0200, Hans Verkuil wrote:
On 04/05/18 22:06, Ezequiel Garcia wrote:
> From: Gustavo Padovan
[snip]
> diff --git a/include/media/videobuf2-core.h
> b/include/media/videobuf2-core.h
>
Hi Ezequiel,
On Fri, May 04, 2018 at 05:06:07PM -0300, Ezequiel Garcia wrote:
From: Gustavo Padovan
Turn the reserved2 field into fence_fd that we will use to send
an in-fence to the kernel or return an out-fence from the kernel to
userspace.
Two new flags were added, V4L2_BUF_FLAG_IN_FENCE,
On Fri, Nov 17, 2017 at 11:19:05AM -0200, Mauro Carvalho Chehab wrote:
Em Fri, 17 Nov 2017 11:08:01 -0200
Gustavo Padovan escreveu:
2017-11-17 Mauro Carvalho Chehab :
> Em Fri, 17 Nov 2017 15:49:23 +0900
> Alexandre Courbot escreveu:
>
> > > @@ -178,6 +179,12 @@ static int vb2_queue_or_prepa
On Fri, Oct 20, 2017 at 07:50:12PM -0200, Gustavo Padovan wrote:
From: Gustavo Padovan
Add section to VIDIOC_QBUF about it
v3:
- make the out_fence refer to the current buffer (Hans)
- Note what happens when the IN_FENCE is not set (Hans)
v2:
- mention that fences are
Hi Gustavo,
On Fri, Oct 20, 2017 at 07:50:11PM -0200, Gustavo Padovan wrote:
From: Gustavo Padovan
If V4L2_BUF_FLAG_OUT_FENCE flag is present on the QBUF call we create
an out_fence and send to userspace on the V4L2_EVENT_OUT_FENCE when
the buffer is queued to the driver, or right away if the
Hi Gustavo,
Sorry for the sporadic review... I'm struggling to get time to look at
these.
On Fri, Oct 20, 2017 at 07:50:10PM -0200, Gustavo Padovan wrote:
From: Gustavo Padovan
Add vb2_setup_out_fence() and the needed members to struct vb2_buffer.
v2: - change it to reflect fd_install at
v5: - use fence_array to keep buffers ordered in vb2 core when
needed (Brian Stark)
- keep backward compatibility on the reserved2 field (Brian Stark)
- protect fence callback removal with lock (Brian Stark)
Brian Starkey, but close ;-)
v4:
- Add a comment
Hi,
On Wed, Oct 04, 2017 at 05:08:55PM -0300, Gustavo Padovan wrote:
Hi Brian,
On Mon, 2017-10-02 at 14:41 +0100, Brian Starkey wrote:
Hi Gustavo,
On Thu, Sep 07, 2017 at 03:42:11PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Hi,
>
> Refer to the documentati
Hi,
On Thu, Sep 07, 2017 at 03:42:21PM -0300, Gustavo Padovan wrote:
From: Gustavo Padovan
For explicit synchronization (and soon for HAL3/Request API) we need
the v4l2-driver to guarantee the ordering in which the buffers were queued
by userspace. This is already true for many drivers, but we
Hi,
On Thu, Sep 07, 2017 at 03:42:15PM -0300, Gustavo Padovan wrote:
From: Gustavo Padovan
Receive in-fence from userspace and add support for waiting on them
before queueing the buffer to the driver. Buffers are only queued
to the driver once they are ready. A buffer is ready when its
in-fenc
Hi,
On Thu, Sep 07, 2017 at 03:42:13PM -0300, Gustavo Padovan wrote:
From: Gustavo Padovan
Turn the reserved2 field into fence_fd that we will use to send
an in-fence to the kernel and return an out-fence from the kernel to
userspace.
Two new flags were added, V4L2_BUF_FLAG_IN_FENCE, that sho
Hi Gustavo,
On Thu, Sep 07, 2017 at 03:42:11PM -0300, Gustavo Padovan wrote:
From: Gustavo Padovan
Hi,
Refer to the documentation on the first patch for the details. The previous
iteration is here:
https://www.mail-archive.com/linux-media@vger.kernel.org/msg118077.html
The 2nd patch propose
Hi Laurent,
On Thu, Aug 31, 2017 at 05:51:33PM +0300, Laurent Pinchart wrote:
Hi Brian,
On Wednesday, 30 August 2017 13:32:01 EEST Brian Starkey wrote:
On Wed, Aug 30, 2017 at 11:53:58AM +0200, Hans Verkuil wrote:
> On 30/08/17 11:36, Brian Starkey wrote:
>> On Wed, Aug 30, 2017 at 1
On Wed, Aug 30, 2017 at 11:53:58AM +0200, Hans Verkuil wrote:
On 30/08/17 11:36, Brian Starkey wrote:
On Wed, Aug 30, 2017 at 10:10:01AM +0200, Hans Verkuil wrote:
On 30/08/17 09:50, Daniel Vetter wrote:
On Tue, Aug 29, 2017 at 10:47:01AM +0100, Brian Starkey wrote:
The fact is, adding
On Wed, Aug 30, 2017 at 10:10:01AM +0200, Hans Verkuil wrote:
On 30/08/17 09:50, Daniel Vetter wrote:
On Tue, Aug 29, 2017 at 10:47:01AM +0100, Brian Starkey wrote:
The fact is, adding special formats for each combination is
unmanageable - we're talking dozens in the case of our hardware.
On Mon, Aug 28, 2017 at 10:49:07PM +0200, Daniel Vetter wrote:
On Mon, Aug 28, 2017 at 8:07 PM, Nicolas Dufresne wrote:
Le jeudi 24 ao??t 2017 ?? 13:26 +0100, Brian Starkey a ??crit :
> What I mean was: an application can use the modifier to give buffers from
> one device to another w
On Fri, Aug 25, 2017 at 10:14:03AM +0200, Hans Verkuil wrote:
On 24/08/17 14:26, Brian Starkey wrote:
On Thu, Aug 24, 2017 at 01:37:35PM +0200, Hans Verkuil wrote:
On 08/24/17 13:14, Brian Starkey wrote:
Hi Hans,
On Mon, Aug 21, 2017 at 06:36:29PM +0200, Hans Verkuil wrote:
On 08/21/2017 06
On Thu, Aug 24, 2017 at 01:37:35PM +0200, Hans Verkuil wrote:
On 08/24/17 13:14, Brian Starkey wrote:
Hi Hans,
On Mon, Aug 21, 2017 at 06:36:29PM +0200, Hans Verkuil wrote:
On 08/21/2017 06:01 PM, Daniel Vetter wrote:
On Mon, Aug 21, 2017 at 5:52 PM, Brian Starkey wrote:
Hi all,
I
Hi Hans,
On Mon, Aug 21, 2017 at 06:36:29PM +0200, Hans Verkuil wrote:
On 08/21/2017 06:01 PM, Daniel Vetter wrote:
On Mon, Aug 21, 2017 at 5:52 PM, Brian Starkey wrote:
Hi all,
I couldn't find this topic talked about elsewhere, but apologies if
it's a duplicate - I'll be gla
On Mon, Aug 21, 2017 at 06:01:24PM +0200, Daniel Vetter wrote:
On Mon, Aug 21, 2017 at 5:52 PM, Brian Starkey wrote:
Hi all,
I couldn't find this topic talked about elsewhere, but apologies if
it's a duplicate - I'll be glad to be steered in the direction of a
thread.
We&#x
Hi all,
I couldn't find this topic talked about elsewhere, but apologies if
it's a duplicate - I'll be glad to be steered in the direction of a
thread.
We'd like to support DRM format modifiers in v4l2 in order to share
the description of different (mostly proprietary) buffer formats
between e.g
On Wed, Apr 19, 2017 at 01:34:34PM +0200, Boris Brezillon wrote:
On Wed, 19 Apr 2017 10:51:23 +0100
Brian Starkey wrote:
[snip]
Could you expand a bit on how you think planes fit better?
Just had the impression that the writeback feature was conceptually
closer to a plane object (which is
On Tue, Apr 18, 2017 at 09:57:17PM +0200, Boris Brezillon wrote:
Hi Brian,
On Tue, 18 Apr 2017 18:34:43 +0100
Brian Starkey wrote:
>> @@ -214,6 +214,19 @@ struct drm_connector_state {
>>struct drm_encoder *best_encoder;
>>
>>struct
On Fri, Apr 14, 2017 at 11:47:00AM +0200, Boris Brezillon wrote:
On Fri, 25 Nov 2016 16:49:04 +
Brian Starkey wrote:
+static int
+malidp_mw_encoder_atomic_check(struct drm_encoder *encoder,
+ struct drm_crtc_state *crtc_state
On Fri, Apr 14, 2017 at 12:11:14PM +0200, Boris Brezillon wrote:
On Fri, 25 Nov 2016 16:49:00 +
Brian Starkey wrote:
Add the OUT_FENCE_PTR property to writeback connectors, to enable
userspace to get a fence which will signal once the writeback is
complete. It is not allowed to request an
Hi Boris,
On Fri, Apr 14, 2017 at 12:08:23PM +0200, Boris Brezillon wrote:
On Fri, 25 Nov 2016 16:48:59 +
Brian Starkey wrote:
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index b5c6a8e..6bbd93f 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b
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 +
Brian Starkey 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
Hi Ville,
On Thu, Mar 16, 2017 at 07:36:56PM +0200, Ville Syrjälä wrote:
On Thu, Mar 16, 2017 at 07:05:12PM +0200, Sharma, Shashank wrote:
On 3/16/2017 5:55 PM, Brian Starkey wrote:
> On Thu, Mar 16, 2017 at 05:14:07PM +0200, Sharma Shashank wrote:
>> On 3/16/2017 4:37 PM, Local user
On 3/16/2017 4:07 PM, Ville Syrjälä wrote:
On Tue, Jan 31, 2017 at 03:55:41PM +, Brian Starkey wrote:
On Tue, Jan 31, 2017 at 05:15:46PM +0200, Ville Syrjälä wrote:
On Tue, Jan 31, 2017 at 12:33:29PM +, Brian Starkey wrote:
Hi,
On Mon, Jan 30, 2017 at 03:35:13PM +0200, Ville Syrjälä
On Sun, Mar 12, 2017 at 02:34:14PM +0100, Benjamin Gaignard wrote:
2017-03-09 18:38 GMT+01:00 Laura Abbott :
On 03/09/2017 02:00 AM, Benjamin Gaignard wrote:
2017-03-06 17:04 GMT+01:00 Daniel Vetter :
On Mon, Mar 06, 2017 at 11:58:05AM +0100, Mark Brown wrote:
On Mon, Mar 06, 2017 at 11:40:41
On Fri, Mar 10, 2017 at 11:46:42AM +, Robin Murphy wrote:
On 10/03/17 10:31, Brian Starkey wrote:
Hi,
On Thu, Mar 09, 2017 at 09:38:49AM -0800, Laura Abbott wrote:
On 03/09/2017 02:00 AM, Benjamin Gaignard wrote:
[snip]
For me those patches are going in the right direction.
I still
Hi,
On Thu, Mar 09, 2017 at 09:38:49AM -0800, Laura Abbott wrote:
On 03/09/2017 02:00 AM, Benjamin Gaignard wrote:
[snip]
For me those patches are going in the right direction.
I still have few questions:
- since alignment management has been remove from ion-core, should it
be also removed
On Tue, Jan 31, 2017 at 05:15:46PM +0200, Ville Syrjälä wrote:
On Tue, Jan 31, 2017 at 12:33:29PM +, Brian Starkey wrote:
Hi,
On Mon, Jan 30, 2017 at 03:35:13PM +0200, Ville Syrjälä wrote:
>On Fri, Jan 27, 2017 at 05:23:24PM +0000, Brian Starkey wrote:
>> Hi,
>>
>> We
Hi,
On Mon, Jan 30, 2017 at 03:35:13PM +0200, Ville Syrjälä wrote:
On Fri, Jan 27, 2017 at 05:23:24PM +, Brian Starkey wrote:
Hi,
We're looking to enable the per-plane color management hardware in
Mali-DP with atomic properties, which has sparked some conversation
around how to h
Hi,
We're looking to enable the per-plane color management hardware in
Mali-DP with atomic properties, which has sparked some conversation
around how to handle YCbCr formats.
As it stands today, it's assumed that a driver will implicitly "do the
right thing" to display a YCbCr buffer.
YCbCr dat
Store fence in drm_writeback_job
Gustavo Padovan:
- Move out_fence_ptr out of connector_state
- Signal fence from drm_writeback_signal_completion instead of
in driver directly
Signed-off-by: Brian Starkey
---
drivers/gpu/drm/drm_atomic.c| 96 +
dr
check to allow CRTC to be set without an FB
- Add some writeback_ prefixes
- Drop PIXEL_FORMATS_SIZE property, as it was unnecessary
Gustavo Padovan:
- Add drm_writeback_job to handle writeback signalling centrally
Signed-off-by: Brian Starkey
---
Documentation/gpu/drm-kms.rst |9
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
.
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
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
tion
of drm_writeback_job) is probably up for debate.
v4 will be accompanied by igt tests.
As always, I look forward to any comments.
Thanks,
Brian
[1] http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1247574.html
[2] http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg125801
Signed-off-by: Brian Starkey
---
drivers/gpu/drm/arm/Makefile |1 +
drivers/gpu/drm/arm/malidp_crtc.c | 21 +++
drivers/gpu/drm/arm/malidp_drv.c | 25 +++-
drivers/gpu/drm/arm/malidp_drv.h |3 +
drivers/gpu/drm/arm/malidp_hw.c |7 +-
drivers/gpu/drm/arm/malidp_mw.
Hi Gustavo,
On Wed, Oct 26, 2016 at 07:40:29PM -0200, Gustavo Padovan wrote:
2016-10-26 Brian Starkey :
Add the OUT_FENCE_PTR property to writeback connectors, to enable
userspace to get a fence which will signal once the writeback is
complete.
A timeline is added to drm_connector for use by
On Wed, Oct 26, 2016 at 07:45:14PM -0200, Gustavo Padovan wrote:
%p should be kept for your internal debug only. Make sure to remove
anything that exposes kernel address when sending patches.
Gustavo
Noted, thanks!
-Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-me
On Wed, Oct 26, 2016 at 07:43:57PM -0200, Gustavo Padovan wrote:
2016-10-26 Brian Starkey :
If userspace has asked for an out-fence for the writeback, we add a
fence to malidp_mw_job, to be signaled when the writeback job has
completed.
Signed-off-by: Brian Starkey
---
drivers/gpu/drm/arm
Hi Gustavo,
It would be great if you could cast your eye over this one as-well.
My intention was to be as similar to the CRTC out-fences as possible.
Thanks,
Brian
On Wed, Oct 26, 2016 at 09:55:07AM +0100, Brian Starkey wrote:
Add the OUT_FENCE_PTR property to writeback connectors, to enable
On Wed, Oct 26, 2016 at 01:00:21PM +0200, Daniel Vetter wrote:
On Wed, Oct 26, 2016 at 09:55:00AM +0100, Brian Starkey wrote:
Writeback connectors represent writeback engines which can write the
CRTC output to a memory framebuffer. Add a writeback connector type and
related support functions
e_get() in
sync_file_create(), and then I will do the same.
Thanks,
Brian
On Wed, Oct 26, 2016 at 09:55:06AM +0100, Brian Starkey wrote:
Some parts of setting up the CRTC out-fence can be re-used for
writeback out-fences. Factor this out into a separate function.
Signed-off-by: Brian Starkey
---
drive
If userspace has asked for an out-fence for the writeback, we add a
fence to malidp_mw_job, to be signaled when the writeback job has
completed.
Signed-off-by: Brian Starkey
---
drivers/gpu/drm/arm/malidp_hw.c |5 -
drivers/gpu/drm/arm/malidp_mw.c | 18 +-
drivers/gpu
initialize writeback connector in one go
- Added core checks
- Squashed into a single commit
- Dropped the client cap
- Writeback framebuffers are no longer persistent
Signed-off-by: Brian Starkey
---
Documentation/gpu/drm-kms.rst |9 ++
drivers/gpu/drm/Makefile|2
appropriately when their writeback has
finished.
It is not allowed to request an out-fence without a framebuffer attached
to the connector.
Signed-off-by: Brian Starkey
---
drivers/gpu/drm/drm_atomic.c| 60 +++---
drivers/gpu/drm/drm_atomic_helper.c |5
Some parts of setting up the CRTC out-fence can be re-used for
writeback out-fences. Factor this out into a separate function.
Signed-off-by: Brian Starkey
---
drivers/gpu/drm/drm_atomic.c | 64 +++---
1 file changed, 42 insertions(+), 22 deletions(-)
diff
.
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
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
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
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
ommit.
To avoid this, clear CVAL before leaving config mode.
Signed-off-by: Brian Starkey
---
drivers/gpu/drm/arm/malidp_hw.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index 7f4a0bd..65e667b 100644
--- a/drivers/g
sconnected
instead
- Added drm_writeback.c for central connector initialization and
documentation
- Added support for out-fences
- Added core checks for writeback connectors, e.g. disallowing
a framebuffer with no CRTC
- Mali-DP doesn't require a full modeset to enable/disable the
Hi Archit,
On Fri, Oct 14, 2016 at 04:20:14PM +0530, Archit Taneja wrote:
Hi Brian,
On 10/11/2016 08:23 PM, 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
Hi Eric,
On Tue, Oct 11, 2016 at 12:01:14PM -0700, Eric Anholt wrote:
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
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
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
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
configuration
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
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
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
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
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
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:
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
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
.
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
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
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
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
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/d
Hi,
On Fri, Jul 15, 2016 at 10:42:01AM -0700, Eric Anholt wrote:
Ville Syrjälä writes:
On Fri, Jul 15, 2016 at 10:09:19AM +0100, Brian Starkey wrote:
Hi Daniel,
Thanks for taking a look.
(+Cc Laurent)
On Fri, Jul 15, 2016 at 09:33:34AM +0200, Daniel Vetter wrote:
>On Thu, Jul 14, 2016
Hi Daniel,
Thanks for taking a look.
(+Cc Laurent)
On Fri, Jul 15, 2016 at 09:33:34AM +0200, Daniel Vetter wrote:
On Thu, Jul 14, 2016 at 06:03:40PM +0100, Brian Starkey wrote:
Hi,
The Mali-DP display processors have a memory-writeback engine which
can write the result of the composition
Hi,
The Mali-DP display processors have a memory-writeback engine which
can write the result of the composition (CRTC output) to a memory
buffer in a variety of formats.
We're looking for feedback/suggestions on how to expose this in the
mali-dp DRM kernel driver - possibly via V4L2.
We've got
89 matches
Mail list logo
