at 08:07:24AM +0200, Daniel Vetter wrote:
On Mon, Aug 08, 2016 at 05:04:03PM +0100, Brian Starkey wrote:
> Hi,
>
> On Mon, Jul 25, 2016 at 05:08:21PM +0200, Daniel Vetter wrote:
> > On Mon, Jul 25, 2016 at 01:54:06PM +0100, Brian Starkey wrote:
> > > Hi Russell,
> > &
Thanks Russell, it's most appreciated.
On Wed, Sep 21, 2016 at 05:28:03PM +0100, Russell King - ARM Linux wrote:
On Wed, Sep 21, 2016 at 09:57:38AM +0100, Brian Starkey wrote:
Hi Russell,
Are you in a position to be able to test this now?
Normally, I'd say no, because I'd no
On Thu, Sep 22, 2016 at 01:28:37PM +0200, Daniel Vetter wrote:
On Thu, Sep 22, 2016 at 1:22 PM, Sean Paul wrote:
On Thu, Sep 22, 2016 at 3:51 AM, Russell King - ARM Linux
wrote:
On Thu, Sep 22, 2016 at 11:39:18AM +0100, Brian Starkey wrote:
Actually, could you please hold off picking this
Hi Sean,
On Thu, Sep 22, 2016 at 04:22:40AM -0700, Sean Paul wrote:
On Thu, Sep 22, 2016 at 3:51 AM, Russell King - ARM Linux
wrote:
On Thu, Sep 22, 2016 at 11:39:18AM +0100, Brian Starkey wrote:
Actually, could you please hold off picking this up? We need to make
changes in mali-dp and
On Fri, Sep 23, 2016 at 12:58:46PM +0200, Daniel Vetter wrote:
On Fri, Sep 23, 2016 at 11:34 AM, Liviu Dudau wrote:
rmmod-ing the hdlcd module generates a WARN() splat as the vsync is still
enabled, but we never got the call to turn off the CRTC. Brian is still
tracking through the fbdev emulat
On Fri, Sep 23, 2016 at 03:13:15PM +0200, Daniel Vetter wrote:
On Fri, Sep 23, 2016 at 01:52:49PM +0100, Brian Starkey wrote:
On Fri, Sep 23, 2016 at 12:58:46PM +0200, Daniel Vetter wrote:
> On Fri, Sep 23, 2016 at 11:34 AM, Liviu Dudau wrote:
> > rmmod-ing the hdlcd module generat
ff-by: Wei Yongjun
---
Thanks for cleaning up after me! :-)
Acked-by: Brian Starkey
@Sean, can you pick this up on top of 3c31760e760c?
Cheers,
Brian
drivers/gpu/drm/arm/malidp_drv.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drive
On Tue, Sep 06, 2016 at 03:16:52PM -0700, Laura Abbott wrote:
On 09/05/2016 04:20 AM, Brian Starkey wrote:
Hi,
On Fri, Sep 02, 2016 at 12:36:25PM -0700, Laura Abbott wrote:
On 09/02/2016 06:41 AM, Brian Starkey wrote:
Hi Laura,
On Thu, Sep 01, 2016 at 03:40:41PM -0700, Laura Abbott wrote
Hi Mark,
On Sat, Sep 10, 2016 at 10:29:03AM +0800, Mark Yao wrote:
AFBC is arm vendor format, it's a compressed format.
The AFBC format is supported by rk3399 vop big.
We know little about AFBC layout, hope to some guys can
fixme about the afbc comment.
Signed-off-by: Mark Yao
---
include/ua
Hi Laura,
On Thu, Sep 01, 2016 at 03:40:41PM -0700, Laura Abbott wrote:
There is no advantage to having heap types be a mask. The ion client has
long since dropped the mask. Drop the notion of heap type masks as well.
I know this is the same patch you sent last time, so sorry for not
picking
Hi Nicolai,
On Tue, Aug 02, 2016 at 07:31:36PM +0200, Nicolai Stange wrote:
Nicolai Stange writes:
Liviu Dudau writes:
Add proxy function for the mmap file_operations hook under the
full_proxy_fops structure. This is useful for providing a custom
mmap routine in a driver's debugfs implement
Hi,
On Mon, Jul 25, 2016 at 05:08:21PM +0200, Daniel Vetter wrote:
On Mon, Jul 25, 2016 at 01:54:06PM +0100, Brian Starkey wrote:
Hi Russell,
On Mon, Jul 25, 2016 at 01:25:04PM +0100, Russell King - ARM Linux wrote:
> On Mon, Jul 25, 2016 at 11:55:48AM +0100, Brian Starkey wrote:
>
On Wed, Nov 01, 2017 at 02:16:25PM +, Liviu Dudau wrote:
Some clock providers (clk-vexpress-osc) trigger a WARN() when the
requested rate falls outside its capabilities, as is the case when
a CRTC gets disabled. Check if the CRTC's new state is enabled and
skip the clk_round_rate() call if it
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
which trigger when an unachievable
clock rate is passed to vexpress_osc_round_rate().
Reported-by: Vladimir Murzin
Signed-off-by: Brian Starkey
Acked-by: Sudeep Holla
---
drivers/clk/versatile/clk-vexpress-osc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/driver
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
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
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 Daniel,
On Mon, Apr 09, 2018 at 10:23:37AM +0200, Daniel Vetter wrote:
On Fri, Apr 06, 2018 at 08:02:16PM +0100, Ayan Halder wrote:
On Tue, Mar 27, 2018 at 01:09:36PM +0200, Daniel Vetter wrote:
> On Tue, Mar 27, 2018 at 11:59 AM, Ayan Halder wrote:
> > On Tue, Mar 27, 2018 at 10:29:03AM +0
On Thu, May 24, 2018 at 05:41:01PM +0100, Liviu Dudau wrote:
From: Brian Starkey
Writeback connectors represent writeback engines which can write the
CRTC output to a memory framebuffer. Add a writeback connector type and
related support functions.
Drivers should initialize a writeback
Hi Ayan,
On Fri, May 25, 2018 at 04:35:41PM +0100, Ayan Kumar Halder wrote:
If a plane supports a pixel format and the framebuffer does not pass any
modifiers, then drm_plane_check_pixel_format() should always return true
for the given format regardless of whether the plane supports any
modifier
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
Hi Liviu,
On Fri, May 18, 2018 at 09:24:21AM +0100, Liviu Dudau wrote:
Mali DP500 behaves differently from the rest of the Mali DP IP,
in that it does not have a one-shot mode and keeps writing the
content of the current frame to the provided memory area until
stopped. As a way of emulating the
Hi James,
A few minor comments.
On Mon, Dec 24, 2018 at 08:58:46AM +, james qian wang (Arm Technology
China) wrote:
> D71 consists of a number of Register Blocks, every Block controls a
> specific HW function, every block has a common block_header to represent
> its type and pipeline informa
Hi,
On Tue, Aug 18, 2020 at 05:04:12PM +0900, Hyesoo Yu wrote:
> These patch series to introduce a new dma heap, chunk heap.
> That heap is needed for special HW that requires bulk allocation of
> fixed high order pages. For example, 64MB dma-buf pages are made up
> to fixed order-4 pages * 1024.
Hi KyongHo,
On Wed, Aug 19, 2020 at 12:46:26PM +0900, Cho KyongHo wrote:
> I have seriously considered CPA in our product but we developed our own
> because of the pool in CPA.
Oh good, I'm glad you considered it :-)
> The high-order pages are required by some specific users like Netflix
> app.
Hi Peiyong,
On Mon, Nov 30, 2020 at 02:33:59PM -0800, Peiyong Lin wrote:
> On Tue, Nov 17, 2020 at 1:31 PM Peiyong Lin wrote:
> >
> > On Thu, Oct 22, 2020 at 10:34 AM Peiyong Lin wrote:
> > >
> > > Historically there is no common trace event for GPU frequency, in
> > > downstream Android each di
-by: Brian Starkey
Acked-by: Liviu Dudau
---
Only change from v1 is rewording of the commit message as suggested
by Liviu.
arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts | 13 +
arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts | 13 +
arch/arm/boot/dts/vexpress-v2p-ca5s.dts
The VExpress development platform has an external expansion bus which
can be used for additional hardware (e.g. LogicTile Express
daughterboards).
Add this bus to the VExpress CoreTile device-trees.
The bus is described for a CoreTile occupying site 1.
Signed-off-by: Brian Starkey
Acked-by
The Juno development platform has an external expansion bus which can
be used for additional hardware (e.g. LogicTile Express daughterboards).
Add this bus to the Juno base device-tree.
Signed-off-by: Brian Starkey
Acked-by: Liviu Dudau
---
arch/arm64/boot/dts/arm/juno-base.dtsi | 10
On Fri, Apr 15, 2016 at 09:55:50AM +0100, Sudeep Holla wrote:
On 14/04/16 16:39, Brian Starkey wrote:
The VExpress development platform has an external expansion bus which
can be used for additional hardware (e.g. LogicTile Express
daughterboards).
Add this bus to the VExpress CoreTile device
, Brian Starkey wrote:
When the DMA_MEMORY_MAP flag is used, memory which can be accessed
directly should be returned, so use ioremap_wc() instead of ioremap().
Also, ensure that the correct memset operation is used in
dma_alloc_from_coherent() with respect to the region's flags.
This fixe
On Fri, Dec 04, 2015 at 05:15:54PM +, Catalin Marinas wrote:
On Fri, Dec 04, 2015 at 08:59:10AM -0800, Dan Williams wrote:
On Fri, Dec 4, 2015 at 2:50 AM, Catalin Marinas wrote:
> On Fri, Nov 20, 2015 at 02:20:26PM +0000, Brian Starkey wrote:
>> When the DMA_MEMORY_MAP flag is use
-by: Brian Starkey
Reviewed-by: Catalin Marinas
---
drivers/base/dma-coherent.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/base/dma-coherent.c b/drivers/base/dma-coherent.c
index f98359a..4e4ad30 100644
--- a/drivers/base/dma-coherent.c
+++ b/drivers/base/dma
Add a flag to memremap() for writecombine mappings. Mappings satisfied
by this flag will not be cached, however writes may be delayed or
combined into more efficient bursts. This is most suitable for
buffers written sequentially by the CPU for use by other DMA devices.
Signed-off-by: Brian
When the DMA_MEMORY_MAP flag is used, memory which can be accessed
directly should be returned, so use memremap(..., MEMREMAP_WC) to
provide a writecombine mapping.
Signed-off-by: Brian Starkey
Reviewed-by: Catalin Marinas
---
drivers/base/dma-coherent.c | 20
1 file
when zeroing coherent allocations, which fixes an alignment fault on
arm64.
Best Regards,
Brian
[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/390857.html
Brian Starkey (3):
memremap: add MEMREMAP_WC flag
drivers: dma-coherent: use MEMREMAP_WC for DMA_MEMORY_MAP
04 x2 : ffc0
x1 : x0 : ff800038
Signed-off-by: Brian Starkey
Reviewed-by: Catalin Marinas
---
drivers/base/dma-coherent.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/base/dma-coherent.c b/drivers/base/dma-coher
On Tue, Feb 16, 2016 at 04:43:51PM -0800, Greg Kroah-Hartman wrote:
On Tue, Feb 16, 2016 at 11:14:26AM +, Brian Starkey wrote:
Hi Greg,
Is the documentation OK? Is there any chance of you picking up this
series?
I can rebase onto -next if that's the right place, but they still app
Hi Andrew,
Would you pick these up if I rebase onto linux-next?
How strongly do you feel about the input argument modification vs.
staying in-line with the rest of the function?
Thanks,
Brian
On Tue, Feb 09, 2016 at 10:23:00AM +, Brian Starkey wrote:
Hi Andrew,
Thanks for taking a look
Hi Thomas,
Any further thoughts on this? (some comments below)
On Thu, Jan 28, 2016 at 02:37:24PM +0100, Thomas Gleixner wrote:
In principle I agree. The issue is that it really depends on the
particular
hardware situation.
If there is an explicit requirement for one driver - expressed by a t
When the DMA_MEMORY_MAP flag is used, memory which can be accessed
directly should be returned, so use memremap(..., MEMREMAP_WC) to
provide a writecombine mapping.
Signed-off-by: Brian Starkey
Reviewed-by: Catalin Marinas
Acked-by: Michal Nazarewicz
---
drivers/base/dma-coherent.c | 20
tions, which fixes an alignment fault on
arm64.
Best Regards,
Brian
[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/390857.html
Brian Starkey (3):
memremap: add MEMREMAP_WC flag
drivers: dma-coherent: use MEMREMAP_WC for DMA_MEMORY_MAP
drivers: dma-coherent: use mems
Add a flag to memremap() for writecombine mappings. Mappings satisfied
by this flag will not be cached, however writes may be delayed or
combined into more efficient bursts. This is most suitable for
buffers written sequentially by the CPU for use by other DMA devices.
Signed-off-by: Brian
-by: Brian Starkey
Reviewed-by: Catalin Marinas
---
drivers/base/dma-coherent.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/base/dma-coherent.c b/drivers/base/dma-coherent.c
index f98359a..4e4ad30 100644
--- a/drivers/base/dma-coherent.c
+++ b/drivers/base/dma
Hi Greg,
On Mon, Feb 08, 2016 at 10:30:06AM -0800, Greg KH wrote:
On Mon, Feb 08, 2016 at 05:30:50PM +, Brian Starkey wrote:
diff --git a/include/linux/io.h b/include/linux/io.h
index 32403b5..e2c8419 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -135,6 +135,7 @@ enum
Hi Andrew,
Thanks for taking a look,
On Mon, Feb 08, 2016 at 12:03:17PM -0800, Andrew Morton wrote:
On Mon, 8 Feb 2016 17:30:50 + Brian Starkey wrote:
The patch generally looks OK to me. It generates rejects against
linux-next because of some janitorial changes in memremap.c.
Ah yeah
When the DMA_MEMORY_MAP flag is used, memory which can be accessed
directly should be returned, so use memremap(..., MEMREMAP_WC) to
provide a writecombine mapping.
Signed-off-by: Brian Starkey
Reviewed-by: Catalin Marinas
---
drivers/base/dma-coherent.c | 20
1 file
Changes since v1:
* Added preparatory patch removing flag modifications in memremap()
(Suggested by Andrew Morton)
* Rebase onto linux-next
Brian Starkey (4):
memremap: don't modify flags
memremap: add MEMREMAP_WC flag.
drivers: dma-coherent: use MEMREMAP_WC for DMA_MEMORY_MAP
dr
-by: Brian Starkey
Reviewed-by: Catalin Marinas
---
drivers/base/dma-coherent.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/base/dma-coherent.c b/drivers/base/dma-coherent.c
index 25bb398..bdf28f7 100644
--- a/drivers/base/dma-coherent.c
+++ b/drivers/base/dma
Don't modify the flags input argument to memremap(). MEMREMAP_WB is
already a special case so we can check for it directly instead of
clearing flag bits in each mapper.
Signed-off-by: Brian Starkey
---
kernel/memremap.c | 14 +++---
1 file changed, 7 insertions(+), 7 dele
Add a flag to memremap() for writecombine mappings. Mappings satisfied
by this flag will not be cached, however writes may be delayed or
combined into more efficient bursts. This is most suitable for
buffers written sequentially by the CPU for use by other DMA devices.
Signed-off-by: Brian
Brian Starkey wrote:
Hi Greg,
On Mon, Feb 08, 2016 at 10:30:06AM -0800, Greg KH wrote:
On Mon, Feb 08, 2016 at 05:30:50PM +0000, Brian Starkey wrote:
diff --git a/include/linux/io.h b/include/linux/io.h
index 32403b5..e2c8419 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -135,6 +
Hi John,
On Tue, Mar 05, 2019 at 12:54:29PM -0800, John Stultz wrote:
> From: "Andrew F. Davis"
[snip]
> +
> +#define NUM_HEAP_MINORS 128
> +static DEFINE_IDR(dma_heap_idr);
> +static DEFINE_MUTEX(minor_lock); /* Protect idr accesses */
I saw that Matthew Wilcox is trying to nuke idr:
https://
been deprecated in the common/andoid-*
> kernels, so this should be ok.
>
> I've also removed the stats accounting, since any such accounting
> should be implemented by dma-buf core or the heaps themselves.
>
> New in v9:
> * Removing needless check in cma heap (noted
Hi,
On Thu, Oct 03, 2019 at 01:05:53PM -0700, Evan Green wrote:
> On Thu, Oct 3, 2019 at 11:56 AM Stephen Boyd wrote:
> >
> > Quoting Evan Green (2019-09-18 12:37:34)
> > > On Tue, Sep 10, 2019 at 9:09 AM Stephen Boyd wrote:
> > > >
> > > > @@ -53,6 +60,9 @@ static void *try_ram_remap(resource_s
Hi James,
On Tue, Sep 24, 2019 at 02:13:27AM +, james qian wang (Arm Technology
China) wrote:
>
> Hi Brian:
>
> Since one monitor can support mutiple color-formats, this DT property
> supply a way for user to select a specific one from this supported
> color-formats.
Modifying DT is a _rea
On Fri, May 01, 2020 at 11:40:16AM -0700, John Stultz wrote:
> On Fri, May 1, 2020 at 3:42 AM Brian Starkey wrote:
> >
> > Hi,
> >
> > On Fri, May 01, 2020 at 07:39:46AM +, John Stultz wrote:
> > > This patch adds a linux,cma-heap property for CMA reserved
On Fri, May 01, 2020 at 12:01:40PM -0700, John Stultz wrote:
> On Fri, May 1, 2020 at 4:08 AM Robin Murphy wrote:
> >
> > On 2020-05-01 11:21 am, Brian Starkey wrote:
> > > Hi John,
> > >
> > > On Fri, May 01, 2020 at 07:39:48AM +, John Stultz wro
umit Semwal
> Cc: "Andrew F. Davis"
> Cc: Benjamin Gaignard
> Cc: Liam Mark
> Cc: Pratik Patel
> Cc: Laura Abbott
> Cc: Brian Starkey
> Cc: Chenbo Feng
> Cc: Alistair Strachan
> Cc: Sandeep Patil
> Cc: Hridya Valsaraju
> Cc: Christoph Hellwig
Cc: "Andrew F. Davis"
> Cc: Benjamin Gaignard
> Cc: Liam Mark
> Cc: Pratik Patel
> Cc: Laura Abbott
> Cc: Brian Starkey
> Cc: Chenbo Feng
> Cc: Alistair Strachan
> Cc: Sandeep Patil
> Cc: Hridya Valsaraju
> Cc: Christoph Hellwig
> Cc: Marek Sz
tch.
>
> Cc: Rob Herring
> Cc: Sumit Semwal
> Cc: "Andrew F. Davis"
> Cc: Benjamin Gaignard
> Cc: Liam Mark
> Cc: Pratik Patel
> Cc: Laura Abbott
> Cc: Brian Starkey
> Cc: Chenbo Feng
> Cc: Alistair Strachan
> Cc: Sandeep Patil
> Cc: Hrid
Hi Andrew,
On Wed, Oct 09, 2019 at 02:27:15PM -0400, Andrew F. Davis wrote:
> The CMA driver that registers these nodes will have to be expanded to
> export them using this framework as needed. We do something similar to
> export SRAM nodes:
>
> https://lkml.org/lkml/2019/3/21/575
>
> Unlike the
Hi,
On Wed, Oct 16, 2019 at 03:51:39PM +, Mihail Atanassov wrote:
> Hi James,
>
> On Wednesday, 9 October 2019 06:54:15 BST james qian wang (Arm Technology
> China) wrote:
> > On Fri, Oct 04, 2019 at 02:34:42PM +, Mihail Atanassov wrote:
> > > To support transmitters other than the tda99
cca Schultz Zavin, Colin Cross, Benjamin Gaignard,
> Laura Abbott, and many other contributors!
>
> Cc: Laura Abbott
> Cc: Benjamin Gaignard
> Cc: Sumit Semwal
> Cc: Liam Mark
> Cc: Pratik Patel
> Cc: Brian Starkey
> Cc: Vincent Donnefort
> Cc: Sudipto Paul
&g
Hi John,
On Thu, Feb 14, 2019 at 09:38:29AM -0800, John Stultz wrote:
>
[snip]
> Some thoughts, as this ABI break has the potential to be pretty painful.
>
> 1) Unfortunately, this ABI is exposed *through* libion via
> ion_alloc/ion_alloc_fd out to gralloc implementations. Which means it
> will
s above make ION align
> > more with the way the DMA APIs are used. Basically when the buffer is not
> > dma-mapped the CPU doesn't need to do any CMOs to access the buffer (and
> > ION ensures not CMOs are applied) but if the CPU does want to access the
> > buff
Hi :-)
On Tue, Jan 15, 2019 at 12:40:16PM -0600, Andrew F. Davis wrote:
> On 1/15/19 12:38 PM, Andrew F. Davis wrote:
> > On 1/15/19 11:45 AM, Liam Mark wrote:
> >> On Tue, 15 Jan 2019, Andrew F. Davis wrote:
> >>
> >>> On 1/14/19 11:13 AM, Liam Mark wrote:
> On Fri, 11 Jan 2019, Andrew F. Da
Hi Andrew,
On Fri, Jan 11, 2019 at 12:05:20PM -0600, Andrew F. Davis wrote:
> The heap name can be used for debugging but otherwise does not seem
> to be required and no other part of the code will fail if left NULL
> except here. We can make it required and check for it at some point,
> for now l
Hi Jani,
On Mon, Jan 14, 2019 at 02:23:46PM +0200, Jani Nikula wrote:
> On Fri, 11 Jan 2019, Liviu Dudau wrote:
> > On Thu, Jan 03, 2019 at 05:44:26PM -0300, Ezequiel Garcia wrote:
> >> Hi Liviu,
> >>
> >> On Mon, 2018-12-03 at 11:31 +0000, Ayan Hald
-by on any patches that you send, but
otherwise this is:
Reviewed-by: Brian Starkey
Thanks!
-Brian
> ---
> include/uapi/drm/drm_fourcc.h | 23 +++
> 1 file changed, 23 insertions(+)
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.
16/19 4:54 PM, Liam Mark wrote:
> >>> On Wed, 16 Jan 2019, Andrew F. Davis wrote:
> >>>
> >>>> On 1/16/19 9:19 AM, Brian Starkey wrote:
> >>>>> Hi :-)
> >>>>>
> >>>>> On Tue, Jan 15, 2019 at 12:40:16PM -0600,
Hi Liam,
On Fri, Jan 18, 2019 at 10:37:47AM -0800, Liam Mark wrote:
> Add support for configuring dma mapping attributes when mapping
> and unmapping memory through dma_buf_map_attachment and
> dma_buf_unmap_attachment.
>
> For example this will allow ION clients to skip cache maintenance, by
> u
since he has been one of the
> > core guys who shaped up dma-buf as it is today.
> >
> > On Tue, 22 Jan 2019 at 02:51, Andrew F. Davis wrote:
> >>
> >> On 1/21/19 5:22 AM, Brian Starkey wrote:
>
> [snip]
>
> >>>
> >>> A
Hi Andrew,
On Wed, Jan 23, 2019 at 01:28:35PM -0600, Andrew F. Davis wrote:
> Previously the heap to allocate from was selected by a mask of allowed
> heap types. This may have been done as a primitive form of constraint
> solving, the first heap type that matched any set bit of the heap mask
> wa
On Thu, Jan 24, 2019 at 10:04:46AM -0600, Andrew F. Davis wrote:
> On 1/23/19 11:11 AM, Brian Starkey wrote:
[snip]
>
> I'm very new to all this, so any pointers to history in this area are
> appreciated.
>
[snip]
>
> > In case you didn't come across it
On Thu, Jan 24, 2019 at 10:12:10AM -0600, Andrew F. Davis wrote:
> On 1/24/19 9:24 AM, Brian Starkey wrote:
[snip]
> >
> > What do you think about renaming ion_allocation_data.unused to heap_id
> > and adding a flag instead? It's adding cruft to a staging API, b
Hi Lowry,
Thanks for this cleanup.
On Wed, Jul 31, 2019 at 11:04:45AM +, Lowry Li (Arm Technology China) wrote:
> During it signals the completion of a writeback job, after releasing
> the out_fence, we'd clear the pointer.
>
> Check if fence left over in drm_writeback_cleanup_job(), release
Hi Liviu,
On Thu, Aug 01, 2019 at 11:42:31AM +0100, Liviu Dudau wrote:
> Komeda has support to generate per-frame CRC values in the DOU
> backend subsystem. Implement necessary hooks to expose the CRC
> "control" and "data" file over debugfs and program the DOUx_BS
> accordingly.
>
> This patch m
Hi Lowry,
Based on Daniel's input, this patch looks fine:
Reviewed-by: Brian Starkey
I think there's some opportunity for improvement around
prepare_signaling/complete_signaling, but that can be treated as
separate from fixing this bug.
Thanks,
-Brian
On Wed, Jul 31, 2019 at 11:04:
Hi Daniel,
On Fri, Jun 21, 2019 at 05:27:00PM +0200, Daniel Vetter wrote:
> On Fri, Jun 21, 2019 at 12:21 PM Raymond Smith wrote:
> >
> > Add the DRM_FORMAT_MOD_ARM_16X16_BLOCK_U_INTERLEAVED modifier to
> > denote the 16x16 block u-interleaved format used in Arm Utgard and
> > Midgard GPUs.
> >
>
f the Android ION implementation,
> and a big thanks is due to its authors/maintainers over time
> for their effort:
> Rebecca Schultz Zavin, Colin Cross, Benjamin Gaignard,
> Laura Abbott, and many other contributors!
>
> Cc: Laura Abbott
> Cc: Benjamin Gaignard
> Cc: S
implementation, so
> thanks to its original authors and maintainters:
> Rebecca Schultz Zavin, Colin Cross, Laura Abbott, and others!
>
> Cc: Laura Abbott
> Cc: Benjamin Gaignard
> Cc: Sumit Semwal
> Cc: Liam Mark
> Cc: Pratik Patel
> Cc: Brian Starkey
> Cc: Vince
On Fri, Feb 15, 2019 at 11:01:59AM -0800, John Stultz wrote:
> On Fri, Feb 15, 2019 at 2:51 AM Brian Starkey wrote:
> >
> > Hi John,
> >
> > On Thu, Feb 14, 2019 at 09:38:29AM -0800, John Stultz wrote:
> > >
> > [snip]
> >
> > > Some t
Hi Daniel,
On Fri, Apr 13, 2018 at 05:44:09PM +0200, Daniel Vetter wrote:
On Mon, Apr 09, 2018 at 05:15:08PM +0100, Brian Starkey wrote:
Hi Daniel,
On Mon, Apr 09, 2018 at 10:23:37AM +0200, Daniel Vetter wrote:
> On Fri, Apr 06, 2018 at 08:02:16PM +0100, Ayan Halder wrote:
> > On Tu
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,
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
>
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 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
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
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-&
Hi,
On Fri, Nov 18, 2016 at 01:40:43AM +0100, Thomas Gleixner wrote:
Brian,
On Thu, 17 Nov 2016, Brian Starkey wrote:
No joy with this patch :-(
I had to add an ioaddr argument because apparently that macro depends
on local context (yuck...), but it doesn't help my issue.
FWIW I don&
Hi Eric,
On Tue, Nov 22, 2016 at 06:29:33AM -0800, Eric Dumazet wrote:
On Tue, Nov 22, 2016 at 2:33 AM, Brian Starkey wrote:
Hi,
On Fri, Nov 18, 2016 at 01:40:43AM +0100, Thomas Gleixner wrote:
Brian,
On Thu, 17 Nov 2016, Brian Starkey wrote:
No joy with this patch :-(
I had to add an
Hi Eric,
On Tue, Nov 22, 2016 at 08:09:58AM -0800, Eric Dumazet wrote:
Looks like there's a few similarly named devices and drivers. Mine is
an SMSC LAN91C111 using the smc91x driver in
drivers/net/ethernet/smsc/smc91x.c, rather than smc911x.c. So the
interrupt handler is smc_interrupt()
CONFI
Explicitly state the expected CTM equations in the kerneldoc for the CTM
property, and the form of the matrix on struct drm_color_ctm.
Cc: Ville Syrjälä
Cc: Lionel Landwerlin
Cc: Daniel Vetter
Signed-off-by: Brian Starkey
---
drivers/gpu/drm/drm_color_mgmt.c | 13 +
include
Hi Jani,
On Tue, Jan 31, 2017 at 01:30:41PM +0200, Jani Nikula wrote:
On Tue, 31 Jan 2017, Brian Starkey wrote:
Explicitly state the expected CTM equations in the kerneldoc for the CTM
property, and the form of the matrix on struct drm_color_ctm.
Cc: Ville Syrjälä
Cc: Lionel Landwerlin
Cc
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
Explicitly state the expected CTM equations in the kerneldoc for the CTM
property, and the form of the matrix on struct drm_color_ctm.
Cc: Ville Syrjälä
Cc: Lionel Landwerlin
Cc: Daniel Vetter
Signed-off-by: Brian Starkey
---
drivers/gpu/drm/drm_color_mgmt.c | 13 +
include
Hi Ville,
On Tue, Jan 31, 2017 at 05:18:28PM +0200, Ville Syrjälä wrote:
On Tue, Jan 31, 2017 at 10:48:34AM +, Brian Starkey wrote:
Explicitly state the expected CTM equations in the kerneldoc for the CTM
property, and the form of the matrix on struct drm_color_ctm.
Cc: Ville Syrjälä
Cc
Hi Sergei,
I wasn't around to see v1/v2 but I've taken a quick look in the
archives.
As context for my comments below, I'm keen to push for something which
can be reused for live-sinks, so that we can hook a writeback
connector (when I land that) into a v4l2 device for video capture.
In that ca
1 - 100 of 230 matches
Mail list logo
