Quoting Daniel Vetter (2021-05-20 12:58:52)
> On Wed, May 19, 2021 at 05:25:19PM -0700, Stephen Boyd wrote:
> > @@ -1306,7 +1322,8 @@ static int msm_pdev_probe(struct platform_device
> > *pdev)
> > if (ret)
> > goto fail;
> >
> > - ret = component_master_add_with_match(&pde
Hi Daniel,
Thanks for your review, I will split the patch and resend.
On 2021/5/21 23:32, Daniel Vetter wrote:
On Fri, May 21, 2021 at 09:03:06PM +0800, Zou Wei wrote:
pm_runtime_get_sync will increment pm usage counter even it failed.
Forgetting to putting operation will result in reference
Quoting Saravana Kannan (2021-05-20 13:20:45)
> On Wed, May 19, 2021 at 5:25 PM Stephen Boyd wrote:
> >
> > - master->parent = parent;
> > - master->ops = ops;
> > - master->match = match;
> > + id = ida_alloc(&aggregate_ida, GFP_KERNEL);
> > + if (id < 0) {
> > +
Hi Maxime,
Thank you for the patch.
On Thu, May 20, 2021 at 04:24:35PM +0200, Maxime Ripard wrote:
> New KMS properties come with a bunch of requirements to avoid each
> driver from running their own, inconsistent, set of properties,
> eventually leading to issues like property conflicts, inconsi
On 2021.05.22 21:19:38 +0200, Thomas Zimmermann wrote:
> Hi,
>
> after creating drm-tip today as part of [1], building drm-tip is now broken
> with the error message shown below.
>
> Some register constants appear to be missing from the GVT code. Please fix
> ASAP.
>
Thanks, Thomas. Looks DMC re
I'd like to try and summarise where I feel we are all at with respect
to the dma-buf discussions. I think I've gotten a fairly good idea of
how things stand but I'm not sure we are really getting to the how to
move things forward stage, where is probably when I need to step in.
Thanks for keeping t
Hi Christian,
On Sun, 23 May 2021 at 18:16, Christian König wrote:
> Am 22.05.21 um 22:05 schrieb Daniel Stone:
> > Anyway, the problem with syncobj is that the ioctl to wait for a
> > sync_file to materialise for a given timeline point only allows us to
> > block with a timeout; this is a non-st
Hi Thomas,
Le dim., mai 23 2021 at 21:05:30 +0200, Thomas Zimmermann
a écrit :
Hi
Am 23.05.21 um 19:04 schrieb Paul Cercueil:
V5 of my patchset which adds the option for having GEM buffers
backed by
non-coherent memory.
Changes from V4:
- [2/3]:
- Rename to drm_fb_cma_sync_non_cohere
Hi
Am 23.05.21 um 19:04 schrieb Paul Cercueil:
V5 of my patchset which adds the option for having GEM buffers backed by
non-coherent memory.
Changes from V4:
- [2/3]:
- Rename to drm_fb_cma_sync_non_coherent
- Invert loops for better cache locality
- Only sync BOs that have the
Hi Paul,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.13-rc2 next-20210521]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
h
Use list_entry() instead of container_of() to access list members.
Also drop unnecessary and misleading NULL checks on the result of
list_entry().
Signed-off-by: Guenter Roeck
---
v2: Checkpatch fixes:
- Fix alignment
- Replace comparison against NULL with !
drivers/gpu/drm/i915/gvt/dma
Hi guys,
separating that discussion out since Daniel had a rather interesting
idea here.
Am 22.05.21 um 22:05 schrieb Daniel Stone:
[SNIP]
Anyway, the problem with syncobj is that the ioctl to wait for a
sync_file to materialise for a given timeline point only allows us to
block with a timeou
This function can be used by drivers that use damage clips and have
CMA GEM objects backed by non-coherent memory. Calling this function
in a plane's .atomic_update ensures that all the data in the backing
memory have been written to RAM.
v3: - Only sync data if using GEM objects backed by non-coh
Alloc GEM buffers backed by noncoherent memory on SoCs where it is
actually faster than write-combine.
This dramatically speeds up software rendering on these SoCs, even for
tasks where write-combine memory should in theory be faster (e.g. simple
blits).
v3: The option is now selected per-SoC ins
Having GEM buffers backed by non-coherent memory is interesting in the
particular case where it is faster to render to a non-coherent buffer
then sync the data cache, than to render to a write-combine buffer, and
(by extension) much faster than using a shadow buffer. This is true for
instance on so
V5 of my patchset which adds the option for having GEM buffers backed by
non-coherent memory.
Changes from V4:
- [2/3]:
- Rename to drm_fb_cma_sync_non_coherent
- Invert loops for better cache locality
- Only sync BOs that have the non-coherent flag
- Properly sort includes
-
On Fri, May 21, 2021 at 11:10 AM Daniel Vetter wrote:
>
> No need to set it explicitly.
>
> Signed-off-by: Daniel Vetter
> Cc: Laurentiu Palcu
> Cc: Lucas Stach
> Cc: Shawn Guo
> Cc: Sascha Hauer
> Cc: Pengutronix Kernel Team
> Cc: Fabio Estevam
> Cc: NXP Linux Team
> Cc: Philipp Zabel
>
Hi
Am 22.05.21 um 12:15 schrieb Hao Fang:
s/Hisilicon/HiSilicon/.
It should use capital S, according to
https://www.hisilicon.com/en.
Signed-off-by: Hao Fang
Acked-by: Tian Tao
It's been acked already. Tian can merge it for you.
Best regards
Thomas
---
drivers/gpu/drm/hisilicon/kirin/d
s/Hisilicon/HiSilicon/.
It should use capital S, according to
https://www.hisilicon.com/en.
Signed-off-by: Hao Fang
Acked-by: Tian Tao
---
drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c| 2 +-
drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h| 2 +-
drivers/gpu/drm/hisilicon/kirin/kirin_ade_re
19 matches
Mail list logo
