still waiting for your reply
Brian
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
ation here - do you have any
thoughts on how you think it would work?
Cheers,
-Brian
Hi Frederic,
On Sat, Feb 23, 2019 at 02:18:54PM +0800, Frederic Chen wrote:
> Dear Brian,
>
> I appreciate your comments. I'm really sorry for the delay in responding
> to the comments due to some mail subscribing failed issue inside my company.
No problem.
> On Thu, 2019-
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,
> > >
> >
ten to by the VSP, it will complete at the next
> vblank regardless of whether another page flip occurs at that time.
>
This sounds the same as mali-dp, and so fits directly with the
semantics of writeback connectors.
Thanks,
-Brian
> The code is based on a merge of the media master bra
"dip_useridlist is not empty (%d)\n",
> + dip_ctx->dip_useridlist.queue_cnt);
> +
> + flush_workqueue(dip_ctx->mdpcb_workqueue);
> + destroy_workqueue(dip_ctx->mdpcb_workqueue);
> + dip_ctx->mdpcb_workqueue = NULL;
>
fence_fd field
v5: - delay fd_install to DQ_EVENT (Hans)
- if queue is fully ordered send OUT_FENCE event right away
(Brian)
- rename 'q->ordered' to 'q->ordered_in_driver'
- merge change to implement OUT_FENCE event here
v4: - return the out_fence_fd in
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
userspace.
- send the out_fence_fd back to userspace on the fence_fd field
v5: - delay fd_install to DQ_EVENT (Hans)
- if queue is fully ordered send OUT_FENCE event right away
(Brian)
- rename 'q->ordered' to 'q->ordered_in_driver'
- merge change to impl
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_
what we want.
The main difference is that in DRM, explicit fences aren't associated
with framebuffers, they're associated with the things using the
framebuffers - but practically it doesn't make a difference.
There can be per-buffer "implicit sync" via dma-buf reservation
ob
e right order (I can't
pick the patch exposing the userspace flags without first having the
patches implementing the behaviour), and userspace can never see
something inconsistent.
Cheers,
-Brian
diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c
b/drivers/media/common/videobuf2/v
y, I would stick with:
if ((b->fence_fd > 0) &&
...
0 is a valid fence_fd right? If I close stdin, and create a sync_file,
couldn't I get a fence with fd zero?
-Brian
Gustavo
--
Thanks,
Mauro
erwise the V4L2_EVENT_OUT_FENCE
event will not be sent until all in-fence(s) on the buffer (or
previously queued ones) have signalled.
Cheers,
-Brian
+
+At streamoff the out-fences will either signal normally if the drivers waits
+for the operations on the buffers to finish or signal with error if the
+driv
queue is ordered
both in VB2 and in the driver.
The fence is signaled on buffer_done(), when the job on the buffer is
finished.
v5:
- delay fd_install to DQ_EVENT (Hans)
- if queue is fully ordered send OUT_FENCE event right away
(Brian)
- rename 'q->ordere
t() below, or you should drop a reference
before returning.
-Brian
+
+ vb->out_fence = dma_fence_get(fence);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(vb2_setup_out_fence);
+
/**
* vb2_start_streaming() - Attempt to start streaming.
* @q: videobuf2 queue
diff --git a/include/medi
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
are queued from userspace can still be
different from both the order they are queued in the driver (because
the in-fences can signal in any order), and dequeued again in
userspace, so "ordered" seems a bit ambiguous.
I think it should be more clear.
Cheers
-Brian
* @fileio: file io em
ffer *b,
return -EINVAL;
}
+ if ((b->fence_fd != -1) && !(b->flags & V4L2_BUF_FLAG_IN_FENCE)) {
From what Hans was saying on Patch 2, it seems like this check needs
to be changed so as not to break old userspace which zeroes reserved2
and knows nothin
move this patch to be the last one, after all
of the implementation is done?
Cheers,
-Brian
v2: add documentation
Signed-off-by: Gustavo Padovan
---
Documentation/media/uapi/v4l/buffer.rst | 19 +++
drivers/media/usb/cpia2/cpia2_v4l.c | 2 +-
drivers/media/v4l2
uffer can never get queued in the driver until all of the buffers
which were QBUF'd before it are queued in the driver.
Cheers,
-Brian
All other changes are recorded on the patches' commit messages.
Open Questions
--
* non-ordered devices, like m2m: I've been thinking
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
rtion of v4l2_plane_pix_format.
Thanks for any thoughts,
-Brian
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ä
ow of, the process asking for the ion
allocation is not a secure process, and so we wouldn't *want* to
restrict the secure heap to be allocated from only by secure
processes.
-Brian
Benjamin
Thanks,
Laura
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
t for something useful yet?
The original comment was true - different devices do have different
alignment requirements.
Better alignment can help SMMUs use larger blocks when mapping,
reducing TLB pressure and the chance of a page table walk causing
display underruns.
-Brian
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
tible, and allows for
fully custom CSC matrices where that is supported.
We can obviously implement this as a Mali-DP driver private property,
but it would be good to come up with something to go into the core if
possible.
I'd be happy to hear any feedback,
Thanks,
Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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
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
astructure
around it. Patches 2-6 add a writeback connector for mali-dp.
Patches 7-9 add support for writeback out-fences, based on Gustavo
Padovan's v5 series [2] for adding explicit fencing.
As always, I look forward to any comments.
Thanks,
Brian
[1] http://www.mail-archive.com/lin
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
send out?
Acked-by: Brian King
Thanks,
Brian
--
Brian King
Power Linux I/O
IBM Linux Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
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
tomic_check().
If the V4L2 client goes away or sets the image size to the CRTC's
native resolution, then the DRM device is allowed to use the scaler.
I don't know if/how the DRM device should communicate to userspace
that the scaler is or isn't available for use.
Any thoughts on this
ks an of_match_table. I'll repost patch #18 once all the patches
> in this series have landed.
On a more productive note, the patches I've looked at look good to me.
The missing aliases are a problem enough that should be fixed (i.e.,
part (b)). I'll leave the SPI framework c
have attached the same patch file as submitted to ubuntu. The
change is very simple, so I hope my version doesn't inconvenience you
too much.
Best wishes,
Brian
--- au-SunshineCoast-2015-01-12-debianUnstable 2015-01-12 01:40:07.293353001
+
+++ au-SunshineCoast-2015-01-12-brian 2015-
Hi all
I have a hvr-2255 dvb tuner, but to my knowledge there is no support for
this newer hardware available on linux.
If anyone is interested, I've posted bug reports to my distribution's
BTS as well as the upstream linux kernel bug tracker. The links below
contain some additional information.
Confidential
Business.doc
Description: MS-Word document
Hi,
So, I have two different tv tuner cards that I'm trying to get
working. The kernel modules seem to be loading, no errors there. The
/dev/dvb files are showing up. Everything has the right permissions.
(Well, and I'm doing my testing as root too, just to get it working in
the first place.)
The
Thanks Mauro,
I'll know for next time. It's my first patch submission so wasn't
aware of the formatting rules.
Brian
On 29 April 2014 15:16, Mauro Carvalho Chehab wrote:
> Em Mon, 28 Apr 2014 22:40:00 +0100
> Brian Healy escreveu:
>
>> From: Brian Healy
ropriate people.
Brian.
Resubmitting modified patch. It's purpose is to add the appropriate
device/usb ids for the "Peak DVT-B usb dongle" to the rtl28xxu.c driver.
Signed-off-by: Brian Healy gmail.com>
> Brian, please use
>
> ./scripts/get_maintainer -f drivers/media
1 - 100 of 182 matches
Mail list logo