el raised. That
needs addressing.
On Thu, Dec 19, 2024 at 07:33:07PM +, Marek Olšák wrote:
> On Thu, Dec 19, 2024 at 5:32 AM Brian Starkey wrote:
>
> > On Wed, Dec 18, 2024 at 09:53:56PM +, Marek Olšák wrote:
>
> The pitch doesn't always describe the layout. In prac
On Wed, Dec 18, 2024 at 09:53:56PM +, Marek Olšák wrote:
> On Wed, Dec 18, 2024 at 5:32 AM Brian Starkey wrote:
>
> > On Wed, Dec 18, 2024 at 11:24:58AM +, Simona Vetter wrote:
> > >
> > > For that reason I think linear modifiers with explicit pitch/size
&g
On Wed, Dec 18, 2024 at 11:24:58AM +, Simona Vetter wrote:
>
> For that reason I think linear modifiers with explicit pitch/size
> alignment constraints is a sound concept and fits into how modifiers work
> overall.
> -Sima
Could we make it (more) clear that pitch alignment is a "special"
con
On Tue, Dec 17, 2024 at 11:13:05AM +, Michel Dänzer wrote:
> On 2024-12-17 10:14, Brian Starkey wrote:
> > On Sun, Dec 15, 2024 at 03:53:14PM +, Marek Olšák wrote:
> >> The comment explains the problem with DRM_FORMAT_MOD_LINEAR.
> >>
> >> Signed-off-by:
Hi,
On Sun, Dec 15, 2024 at 03:53:14PM +, Marek Olšák wrote:
> The comment explains the problem with DRM_FORMAT_MOD_LINEAR.
>
> Signed-off-by: Marek Olšák
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 78abd819fd62e..8ec4163429014 100644
> --- a/inclu
Hi,
On Mon, Jun 17, 2024 at 10:48:47PM UTC, Dmitry Baryshkov wrote:
> On Mon, Jun 17, 2024 at 05:36:34PM GMT, Hoosier, Matt wrote:
> > >> >> >> There is a discussion ongoing over in the compositor world about
> > >> >> >> the implication
> > >> Hi,
> > >>
> > >> On Mon, Jun 17, 2024 at 05:16:36P
Hi,
On Mon, Jun 17, 2024 at 05:16:36PM +0200, Daniel Vetter wrote:
>On Mon, Jun 17, 2024 at 01:41:59PM +, Hoosier, Matt wrote:
>> Hi,
>>
>> There is a discussion ongoing over in the compositor world about the
>> implication of this cautionary wording found in the documentation for the
>> DRM
On Tue, Sep 13, 2022 at 04:36:57PM +0100, Liviu Dudau wrote:
> On Tue, Sep 13, 2022 at 03:43:06PM +0100, Brian Starkey wrote:
> > These formats are not subsampled, but that means hsub and vsub should be
> > 1, not 0.
> >
> > Fixes: 94b292b27734 ("drm: drm_fourcc:
These formats are not subsampled, but that means hsub and vsub should be
1, not 0.
Fixes: 94b292b27734 ("drm: drm_fourcc: add NV15, Q410, Q401 YUV formats")
Reported-by: George Kennedy
Reported-by: butt3rflyh4ck
Signed-off-by: Brian Starkey
---
drivers/gpu/drm/drm_fourcc.c | 8 +
On Tue, Aug 16, 2022 at 11:20:50AM +, Olivier Masse wrote:
> On ven., 2022-08-12 at 17:39 +0100, Brian Starkey wrote:
> > On Mon, Aug 08, 2022 at 02:39:53PM +, Olivier Masse wrote:
> > > On ven., 2022-08-05 at 16:41 +0100, Brian Starkey wrote:
> > > > On F
Hi,
On Mon, Aug 08, 2022 at 02:39:53PM +, Olivier Masse wrote:
> Hi Brian,
>
> On ven., 2022-08-05 at 16:41 +0100, Brian Starkey wrote:
> > Caution: EXT Email
> >
> > Hi Olivier,
> >
> > Thanks, I think this is looking much better.
> >
>
+Rob and devicetree list.
I don't know if this should be "linaro" or something more generic,
and also where previous discussions got to about DMA heaps in DT.
Cheers,
-Brian
On Fri, Aug 05, 2022 at 03:53:29PM +0200, Olivier Masse wrote:
> DMABUF Reserved memory definition for OP-TEE SDP feaure.
Hi Olivier,
Thanks, I think this is looking much better.
I'd like to know how others feel about landing this heap; there's been
push-back in the past about heaps in device-tree and discussions
around how "custom" heaps should be treated (though IMO this is quite
a generic one).
On Fri, Aug 05, 2
Hi Olivier,
On Tue, Aug 02, 2022 at 11:58:40AM +0200, Olivier Masse wrote:
> From: John Stultz
>
> This patch adds a simple shrinker controlled page pool to the
> dmabuf heaps subsystem.
>
> This replaces the use of the networking page_pool, over concerns
> that the lack of a shrinker for that
Hi,
On Wed, Aug 03, 2022 at 11:07:54AM +, Olivier Masse wrote:
> Hi Brian,
>
> Thanks for your comments, please find my reply below.
>
> On mar., 2022-08-02 at 15:39 +0100, Brian Starkey wrote:
> > Caution: EXT Email
> >
> > Hi Olivier,
> >
> >
Hi Olivier,
Some comments below as I mentioned off-list.
One additional point: some devices need to know if a buffer is
protected, so that they can configure registers appropriately to make
use of that protected buffer. There was previously a discussion about
adding a flag to a dma_buf to indicat
On Thu, Jun 02, 2022 at 08:47:56AM +0200, Daniel Vetter wrote:
>
> Two expand on this:
>
> - compositor opens the drm render /dev node
> - compositor initializes the opengl or vulkan userspace driver on top of that
> - compositor asks that userspace driver to allocate some buffer, which
> can be
Hi Robin,
On Tue, Apr 05, 2022 at 03:11:18PM +0100, Robin Murphy wrote:
> iommu_get_domain_for_dev() is already perfectly happy to return NULL
> if the given device has no IOMMU. Drop the unnecessary check.
>
> Signed-off-by: Robin Murphy
LGTM, Acked-by: Brian Starkey
I'll
Hi,
On Tue, Dec 14, 2021 at 06:08:37PM +0800, Jiasheng Jiang wrote:
> The return value of kzalloc() needs to be checked.
> To avoid use of null pointer '&state->base' in case of the
> failure of alloc.
>
> Fixes: 99665d072183 ("drm: mali-dp: add malidp_crtc_state struct")
> Signed-off-by: Jiashen
t; failure of alloc.
>
> Fixes: 8cbc5caf36ef ("drm: mali-dp: Add writeback connector")
> Signed-off-by: Jiasheng Jiang
> ---
Reviewed-by: Brian Starkey
> drivers/gpu/drm/arm/malidp_mw.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/
Hi,
On Fri, Oct 29, 2021 at 09:15:28AM -0400, George Kennedy wrote:
>
> Asking if you have any input on how to deal with hsub and vsub = zero?
That's just a straight mistake on those formats - they should
be 1. My bad for not spotting it in review.
On the one hand, having formats in this table
On Fri, Aug 13, 2021 at 10:42:12AM +0530, Sharma, Shashank wrote:
> Hello Brian,
> (+Uma in cc)
>
> Thanks for your comments, Let me try to fill-in for Harry to keep the design
> discussion going. Please find my comments inline.
>
> On 8/2/2021 10:00 PM, Brian Starke
Hi,
Thanks for having a stab at this, it's a massive complex topic to
solve.
Do you have the the HTML rendered somewhere for convenience?
On Fri, Jul 30, 2021 at 04:41:29PM -0400, Harry Wentland wrote:
> Use the new DRM RFC doc section to capture the RFC previously only
> described in the cover
is in-keeping with the rest of the file, so meh :-)
> + u32 ctrl = LW_TRC | L_EN | LW_OFM;
> + u32 mask = LW_TRC | L_EN | LW_OFM | LW_TBU_EN;
If you were aiming for matching register order, this should be:
L_EN | LW_TRC | LW_OFM | LW_TBU_EN
I think it'd be nice to have
Hi Carsten, (+James for komeda)
Thanks for typing this up.
On Fri, Mar 05, 2021 at 04:38:53PM +, carsten.haitz...@foss.arm.com wrote:
> From: Carsten Haitzler
>
> When setting up a readback conenctor that writes data back to memory
s/readback conenctor/writeback connector/ (similar in the
On Wed, Feb 24, 2021 at 04:06:05PM +, Daniel Stone wrote:
> Android punted on that from the beginning and just uses
> XBGR for everything ... so it's not really a matter of dumb vs. smart
> userspace, just equally dumb userspaces which disagree with each
> other. ;)
...apart from HAL_PIXEL_FOR
On Tue, Feb 23, 2021 at 05:10:16PM +, Alyssa Rosenzweig wrote:
> > If YTR can't be turned off, then according to the AFBC spec - correct.
>
> There is no public AFBC spec, so I'm not sure how to respond to this.
>
> > If the hardware allows it to be configured to use YTR with other
> > compon
On Tue, Feb 23, 2021 at 03:29:13PM +, Daniel Stone wrote:
> On Tue, 23 Feb 2021 at 14:58, Brian Starkey wrote:
> > On Tue, Feb 23, 2021 at 02:27:11PM +, Daniel Stone wrote:
> > > Mark, or others from Rockchip, can you please:
> > > - explain if there is a wa
Hi,
On Tue, Feb 23, 2021 at 02:27:11PM +, Daniel Stone wrote:
> Mark, or others from Rockchip, can you please:
> - explain if there is a way to enable/disable the YTR transform in the
> VOP's AFBC decoder, similar to the split-block control bit?
> - ack this patch which correctly declares that
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
houldn't do this (Brian)
LGTM, thanks.
-Brian
>
> Signed-off-by: Simon Ser
> Suggested-by: Daniel Vetter
> Reviewed-by: Daniel Vetter
> Acked-by: Thomas Zimmermann
> Cc: Pekka Paalanen
> Cc: Ville Syrj�l�
> Cc: Brian Starkey
> ---
> drivers/
formatting of the table as a whole.
If Joe feels strongly about having it split, I don't think that should
hurt grep-ability much for the common cases (grep for format name, or
grep for format parameters). So either way you can add:
Reviewed-by: Brian Starkey
Thanks!
-Brian
>
On Fri, Oct 09, 2020 at 09:24:01AM +, Simon Ser wrote:
> User-space should avoid parsing EDIDs for metadata already exposed via
> other KMS interfaces and properties. For instance, user-space should not
> try to extract a list of modes from the EDID: the kernel might mutate
> the mode list (bec
+/1399519
> - Visibly improves performance over the system heap
> * AOSP Codec2 (possibly, needs more review):
> -
> https://android-review.googlesource.com/c/platform/frameworks/av/+/1360640/17/media/codec2/vndk/C2DmaBufAllocator.cpp#325
>
> Cc: Sumit Semwal
> Cc: Liam Mark
>
Hi John,
On Sat, Oct 03, 2020 at 04:02:50AM +, John Stultz wrote:
> Hey All,
...
>
> I did add to this series a reworked version of my uncached
> system heap implementation I was submitting a few weeks back.
> Since it duplicated a lot of the now reworked system heap code,
> I realized it w
Hi,
On Thu, Aug 20, 2020 at 09:07:29AM +0100, Ezequiel Garcia wrote:
> > For single-device allocations, would using the buffer allocation
> > functionality of that device's native API be better in most
> > cases? (Some other possibly relevant discussion at [1])
> >
>
> That may be true for exist
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,
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 Ezequiel,
On Sun, Aug 16, 2020 at 02:22:46PM -0300, Ezequiel Garcia wrote:
> This heap is basically a wrapper around DMA-API dma_alloc_attrs,
> which will allocate memory suitable for the given device.
>
> The implementation is mostly a port of the Contiguous Videobuf2
> memory allocator (see
ew F. Davis
> Cc: Benjamin Gaignard
> Cc: Liam Mark
> Cc: Laura Abbott
> Cc: Brian Starkey
> Cc: linux-me...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: John Stultz
> ---
> drivers/dma-buf/dma-heap.c | 31 +++
&
On Mon, Jun 29, 2020 at 10:32:41AM +0200, Daniel Vetter wrote:
> On Fri, Jun 26, 2020 at 05:48:00PM +0100, Brian Starkey wrote:
> > In cases such as DRM_FORMAT_MOD_SAMSUNG_16_16_TILE, the modifier
> > describes a generic pixel re-ordering which can be applicable to
>
expected usage of such "generic" modifiers.
Changes in v2:
- Move note about future cases to comment (Daniel)
Signed-off-by: Brian Starkey
---
include/uapi/drm/drm_fourcc.h | 25 +
1 file changed, 25 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/in
On Fri, Jun 26, 2020 at 06:15:36PM +0200, Daniel Vetter wrote:
> On Fri, Jun 26, 2020 at 5:21 PM Brian Starkey wrote:
> >
> > On Fri, Jun 26, 2020 at 05:16:53PM +0200, Daniel Vetter wrote:
> > > On Fri, Jun 26, 2020 at 4:16 PM Brian Starkey
> > >
On Fri, Jun 26, 2020 at 05:16:53PM +0200, Daniel Vetter wrote:
> On Fri, Jun 26, 2020 at 4:16 PM Brian Starkey wrote:
> >
> > Hi Daniel,
> >
> > On Fri, Jun 26, 2020 at 04:07:43PM +0200, Daniel Vetter wrote:
> > > On Fri, Jun 26, 2020 at 3:52 PM Brian Stark
Hi Daniel,
On Fri, Jun 26, 2020 at 04:07:43PM +0200, Daniel Vetter wrote:
> On Fri, Jun 26, 2020 at 3:52 PM Brian Starkey wrote:
> >
> > In cases such as DRM_FORMAT_MOD_SAMSUNG_16_16_TILE, the modifier
> > describes a generic pixel re-ordering which can be applicable to
expected usage of such "generic" modifiers.
Signed-off-by: Brian Starkey
---
This is based off a suggestion from Daniel here:
https://lore.kernel.org/dri-devel/20200529115328.GC1630358@phenom.ffwll.local/
If there are future cases where a "generic" modifier is identified
b
s between driver and higher-level programs (Brian,
> Daniel)
>
> v5: fix AFBC example (Brian, Daniel)
>
> v6: remove duplicated paragraph (Daniel)
>
> Signed-off-by: Simon Ser
> Reviewed-by: Daniel Vetter
> Cc: Daniel Stone
> Cc: Bas Nieuwenhuizen
> Cc: Dave Airlie
&
-level programs (Brian,
> Daniel)
>
> v5: fix AFBC example (Brian, Daniel)
>
> Signed-off-by: Simon Ser
> Reviewed-by: Daniel Vetter
> Cc: Daniel Stone
> Cc: Bas Nieuwenhuizen
> Cc: Dave Airlie
> Cc: Marek Olšák
> Cc: Alex Deucher
> Cc: Neil A
On Tue, Jun 23, 2020 at 10:45:51AM +0200, Daniel Vetter wrote:
> On Mon, Jun 22, 2020 at 11:20:51AM +0100, Brian Starkey wrote:
> > On Fri, Jun 19, 2020 at 06:36:17PM +0200, Daniel Vetter wrote:
> > > On Fri, Jun 19, 2020 at 01:39:34PM +0100, Brian Starkey wrote
On Fri, Jun 19, 2020 at 06:36:17PM +0200, Daniel Vetter wrote:
> On Fri, Jun 19, 2020 at 01:39:34PM +0100, Brian Starkey wrote:
> > Hi Simon,
> >
> > On Fri, Jun 19, 2020 at 11:12:25AM +, Simon Ser wrote:
> > > There have suggestions to bake pitch
higher-level programs (Brian,
> Daniel)
>
> Signed-off-by: Simon Ser
> Reviewed-by: Daniel Vetter
> Cc: Daniel Stone
> Cc: Bas Nieuwenhuizen
> Cc: Dave Airlie
> Cc: Marek Olšák
> Cc: Alex Deucher
> Cc: Neil Armstrong
> Cc: Michel Dänzer
> Cc: Brian St
, .hsub = 2,
> + .vsub = 1, .is_yuv = true },
That looks how I would expect, so:
Reviewed-by: Brian Starkey
Cheers,
-Brian
> { .format = DRM_FORMAT_Q410,.depth = 0,
> .num_planes = 3, .char_per_block = { 2, 2, 2 },
>
Sorry for commenting on the obsolete v1 - that'll teach me for reading
my backlog chronologically.
On Thu, May 28, 2020 at 02:38:36PM +, Simon Ser wrote:
> There have suggestions to bake pitch alignment, address alignement,
> contiguous memory or other placement (hidden VRAM, GTT/BAR, etc)
> c
On Wed, May 27, 2020 at 10:55:34AM +0200, Daniel Vetter wrote:
> On Wed, May 27, 2020 at 08:52:00AM +, Simon Ser wrote:
> > There have suggestions to bake pitch alignment, address alignement,
> > contiguous memory or other placement (hidden VRAM, GTT/BAR, etc)
> > constraints into modifiers. La
Hi Jonas,
On Mon, May 25, 2020 at 11:08:11AM +, Jonas Karlman wrote:
> Hi,
>
> On 2020-05-15 15:37, Brian Starkey wrote:
> > Hi Ben,
> >
> > On Wed, May 06, 2020 at 03:41:26PM +0100, Ben Davis wrote:
> >> Hi all, any feedback on this patch?
> >>
r
> > component, but only 10 bits are used and 6 are padded. 'Q' is chosen
> > as the first letter to denote 3 plane YUV444, (and is the next letter
> > along from P which is usually 2 plane).
> >
> > Signed-off-by: Ben Davis
The descriptions match my unde
On Thu, May 14, 2020 at 09:52:35AM -0500, Rob Herring wrote:
> On Wed, May 13, 2020 at 5:44 AM Brian Starkey wrote:
> >
> > Hi Rob,
> >
> > On Tue, May 12, 2020 at 11:37:14AM -0500, Rob Herring wrote:
> > > On Mon, May 04, 2020 at 10:06:28AM +0100, Brian S
Hi Rob,
On Tue, May 12, 2020 at 11:37:14AM -0500, Rob Herring wrote:
> On Mon, May 04, 2020 at 10:06:28AM +0100, Brian Starkey wrote:
> > 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:
> > > >
Hi Jason,
On Wed, May 06, 2020 at 02:18:51PM +0800, Jason Yan wrote:
> Fix the following coccicheck warning:
>
> drivers/dma-buf/heaps/heap-helpers.c:203:5-8: Unneeded variable: "ret".
> Return "0" on line 216
>
> Signed-off-by: Jason Yan
LGTM.
Revie
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
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
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
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
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
On Wed, Apr 29, 2020 at 06:31:01PM +0100, Liviu Dudau wrote:
> On Wed, Apr 29, 2020 at 09:51:19AM -0700, Peter Collingbourne wrote:
> > On Wed, Apr 29, 2020 at 9:17 AM Brian Starkey wrote:
> > >
> > > Hi Peter,
> > >
> > > On Mon, Apr 27, 2020 a
Hi Peter,
On Mon, Apr 27, 2020 at 01:05:13PM -0700, Peter Collingbourne wrote:
> Render nodes are not just useful for devices supporting GPU hardware
> acceleration. Even on devices that only support dumb frame buffers,
> they are useful in situations where composition (using software
> rasterizat
On Tue, Mar 03, 2020 at 12:37:16PM +0100, Daniel Vetter wrote:
> On Tue, Mar 3, 2020 at 11:53 AM Brian Starkey wrote:
> >
> > Hi,
> >
> > On Tue, Mar 03, 2020 at 12:10:29PM +0200, Pekka Paalanen wrote:
> > > On Fri, 21 Feb 2020 10:08:42 +0100
> > >
Hi,
On Tue, Mar 03, 2020 at 12:10:29PM +0200, Pekka Paalanen wrote:
> On Fri, 21 Feb 2020 10:08:42 +0100
> Neil Armstrong wrote:
>
> > Amlogic uses a proprietary lossless image compression protocol and format
> > for their hardware video codec accelerators, either video decoders or
> > video inp
Hi Daniel,
On Thu, Nov 07, 2019 at 08:28:08PM +0100, Daniel Vetter wrote:
> On Thu, Nov 07, 2019 at 05:49:14PM +0000, Brian Starkey wrote:
> > Hi Daniel,
> >
> > On Thu, Nov 07, 2019 at 06:32:01PM +0100, Daniel Vetter wrote:
> > > On Thu, Nov 7, 2019 at 6:20
Hi Daniel,
On Thu, Nov 07, 2019 at 06:32:01PM +0100, Daniel Vetter wrote:
> On Thu, Nov 7, 2019 at 6:20 PM Brian Starkey wrote:
> >
> > Hi Daniel,
> >
> > On Tue, Nov 05, 2019 at 11:26:36PM +, Daniel Stone wrote:
> > > Hi Andrzej,
> > > Thanks fo
Hi Daniel,
On Tue, Nov 05, 2019 at 11:26:36PM +, Daniel Stone wrote:
> Hi Andrzej,
> Thanks for taking this on! It's looking better than v1 for sure. A few
> things below:
>
> On Mon, 2019-11-04 at 23:12 +0100, Andrzej Pietrasiewicz wrote:
> > +bool drm_afbc_check_offset(struct drm_device *dev
Hi Dave,
On Tue, Nov 05, 2019 at 02:58:17AM +1000, Dave Airlie wrote:
> On Mon, 4 Nov 2019 at 20:24, Brian Starkey wrote:
> >
> > Hi John,
> >
> > On Fri, Nov 01, 2019 at 09:42:34PM +, John Stultz wrote:
> > > From: "Andrew F. Davis"
> &g
nd 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
> Cc: Andrew F. Davis
> Cc: Christoph Hellwig
> Cc: Chenbo
ons so they can be accessed by the module.
>
> Cc: Laura Abbott
> Cc: Benjamin Gaignard
> Cc: Sumit Semwal
> Cc: Liam Mark
> Cc: Pratik Patel
> Cc: Brian Starkey
> Cc: Andrew F. Davis
> Cc: Andrew Morton
> Cc: Yue Hu
> Cc: Mike Rapoport
> Cc: Chenbo Feng
On Fri, Oct 18, 2019 at 11:26:52AM -0700, John Stultz wrote:
> On Fri, Oct 18, 2019 at 4:18 AM Brian Starkey wrote:
> > On Fri, Oct 18, 2019 at 05:23:19AM +, John Stultz wrote:
> >
> > As in v3:
> >
> > * Avoid EXPORT_SYMBOL until we finalize modules (sugge
On Sat, Oct 19, 2019 at 09:41:27AM -0400, Andrew F. Davis wrote:
> On 10/18/19 2:57 PM, Ayan Halder wrote:
> > On Fri, Oct 18, 2019 at 11:49:22AM -0700, John Stultz wrote:
> >> On Fri, Oct 18, 2019 at 11:41 AM Ayan Halder wrote:
> >>> On Fri, Oct 18, 2019 at 09:55:1
On Fri, Oct 18, 2019 at 05:23:22AM +, John Stultz wrote:
> This adds a CMA heap, which allows userspace to allocate
> a dma-buf of contiguous memory out of a CMA region.
>
> This code is an evolution of the Android ION implementation, so
> thanks to its original author and maintainters:
> Be
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
On Thu, Oct 17, 2019 at 01:57:45PM -0700, John Stultz wrote:
> On Thu, Oct 17, 2019 at 12:29 PM Andrew F. Davis wrote:
> > On 10/17/19 3:14 PM, John Stultz wrote:
> > > But if the objection stands, do you have a proposal for an alternative
> > > way to enumerate a subset of CMA heaps?
> > >
> > Wh
On Fri, Oct 18, 2019 at 06:57:05AM +, james qian wang (Arm Technology
China) wrote:
>
> Hi Brian:
>
> Can this convince you to fully swap to bridge ?
Not until those patches materialise and land, no :-)
>
> Actually even there is no fix, we won't real encounter such rmmod problem,
> since
On Thu, Oct 17, 2019 at 10:21:03AM +, james qian wang (Arm Technology
China) wrote:
> On Thu, Oct 17, 2019 at 08:20:56AM +0000, Brian Starkey wrote:
> > On Thu, Oct 17, 2019 at 03:07:59AM +, james qian wang (Arm Technology
> > China) wrote:
> > > On Wed, Oct 16,
On Thu, Oct 17, 2019 at 03:07:59AM +, james qian wang (Arm Technology
China) wrote:
> On Wed, Oct 16, 2019 at 04:22:07PM +0000, Brian Starkey wrote:
> >
> > If James is strongly against merging this, maybe we just swap
> > wholesale to bridge? But for me, the pragmatic a
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
Hi Neil,
On Fri, Oct 11, 2019 at 02:07:01PM +0200, Neil Armstrong wrote:
> On 11/10/2019 12:56, Brian Starkey wrote:
> > Hi,
> >
> > On Fri, Oct 11, 2019 at 11:14:43AM +0200, Neil Armstrong wrote:
> >> Hi Brian,
> >>
> >> On 11/10/2019 10:41, Br
Hi James,
On Tue, Oct 15, 2019 at 02:10:53AM +, james qian wang (Arm Technology
China) wrote:
> This function is used to convert drm 3dlut to komeda HW required 1d curve
This is a 1D LUT, not a 3D LUT
Cheers,
-Brian
> coeffs values.
>
> Signed-off-by: james qian wang (Arm Technology China
On Fri, Oct 11, 2019 at 07:25:02PM +0200, Daniel Vetter wrote:
> On Fri, Oct 11, 2019 at 12:56 PM Brian Starkey wrote:
> >
> > Hi,
> >
> > On Fri, Oct 11, 2019 at 11:14:43AM +0200, Neil Armstrong wrote:
> > > Hi Brian,
> > >
> > > On 11/10/20
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 Fri, Oct 11, 2019 at 11:14:43AM +0200, Neil Armstrong wrote:
> Hi Brian,
>
> On 11/10/2019 10:41, Brian Starkey wrote:
> > Hi Neil,
> >
> > On Thu, Oct 10, 2019 at 03:41:15PM +0200, Neil Armstrong wrote:
> >> Hi Ayan,
> >>
> >> On 10/
Hi Neil,
On Thu, Oct 10, 2019 at 03:41:15PM +0200, Neil Armstrong wrote:
> Hi Ayan,
>
> On 10/10/2019 15:26, Ayan Halder wrote:
> > On Thu, Oct 10, 2019 at 11:25:23AM +0200, Neil Armstrong wrote:
> >> This adds all the OSD configuration plumbing to support the AFBC decoders
> >> path to display o
Hi Lowry,
On Tue, Oct 08, 2019 at 09:17:52AM +, Lowry Li (Arm Technology China) wrote:
> Set color_depth according to connector->bpc.
>
> Signed-off-by: Lowry Li (Arm Technology China)
> ---
> .../arm/display/komeda/d71/d71_component.c| 1 +
> .../gpu/drm/arm/display/komeda/komeda_crtc
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
DRM_FORMAT_MOD_ARM_16X16_BLOCK_U_INTERLEAVED \
> + DRM_FORMAT_MOD_ARM_CODE(DRM_FORMAT_MOD_ARM_TYPE_MISC, 1ULL)
> +
> +
I think you can drop this newline, there's no extra space between any
of the other definitions.
With this line dropped, and if you fix up the autho
Hi James,
On Mon, Sep 30, 2019 at 04:54:41AM +, james qian wang (Arm Technology
China) wrote:
> This function is used to convert drm_color_ctm S31.32 sign-magnitude
> value to komeda required Q2.12 2's complement
>
> Signed-off-by: james qian wang (Arm Technology China)
>
> ---
> .../arm/
On Fri, Sep 27, 2019 at 02:22:24AM +, james qian wang (Arm Technology
China) wrote:
> On Wed, Sep 25, 2019 at 09:48:11AM +0000, Brian Starkey wrote:
> > Hi James,
> >
> > On Tue, Sep 24, 2019 at 02:13:27AM +, james qian wang (Arm Technology
> > China) w
Hi,
On Tue, Sep 17, 2019 at 07:36:45PM +0200, Daniel Vetter wrote:
> On Tue, Sep 17, 2019 at 6:15 PM Neil Armstrong
> wrote:
> >
> > Hi,
> >
> > On 17/09/2019 18:07, Liviu Dudau wrote:
> > > On Tue, Sep 17, 2019 at 02:53:01PM +0200, Daniel Vetter wrote:
> > >> On Mon, Sep 09, 2019 at 01:42:53PM
Hi John,
On Thu, Sep 26, 2019 at 02:36:33PM -0700, John Stultz wrote:
> On Mon, Sep 23, 2019 at 3:12 PM Brian Starkey wrote:
> >
> > I didn't see any response about using the test harness. Did you decide
> > against it?
>
> Hey! Spent a little time looking at t
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
Hi Andrzej,
Thanks for the patch, it's nice to see another AFBC implementation
coming in.
For future versions, could you please Cc ayan.hal...@arm.com? It would
have been nice to have someone @arm.com on patches which use/impact
Arm modifiers. Sadly I don't know how to make get_maintainer.pl help
hunk of this code taken from:
> tools/testing/selftests/android/ion/ionmap_test.c
> Originally by Laura Abbott
>
> Cc: Benjamin Gaignard
> Cc: Sumit Semwal
> Cc: Liam Mark
> Cc: Pratik Patel
> Cc: Brian Starkey
> Cc: Vincent Donnefort
> Cc: Sudipto Paul
>
ution of the Android ION implementation, so
> thanks to its original author and maintainters:
> Benjamin Gaignard, Laura Abbott, and others!
>
> Cc: Laura Abbott
> Cc: Benjamin Gaignard
> Cc: Sumit Semwal
> Cc: Liam Mark
> Cc: Pratik Patel
> Cc: Brian Starkey
> Cc: V
1 - 100 of 411 matches
Mail list logo
