On Tue, May 20, 2025 at 3:00 AM Maxime Ripard wrote:
>
> We've discussed a number of times of how some heap names are bad, but
> not really what makes a good heap name.
>
> Let's document what we expect the heap names to look like.
>
> Signed-off-by: Maxime Ripard
> ---
> Documentation/userspace
On Mon, Apr 28, 2025 at 7:52 AM Maxime Ripard wrote:
> On Fri, Apr 25, 2025 at 12:39:40PM -0700, John Stultz wrote:
> > To your larger point about policy, I do get the tension that you want
> > to be able to programmatically derive or evaluate heap names, so that
> > applicat
On Thu, Apr 24, 2025 at 11:58 PM Maxime Ripard wrote:
> On Thu, Apr 24, 2025 at 05:13:47PM -0700, John Stultz wrote:
> > On Thu, Apr 24, 2025 at 1:34 AM Maxime Ripard wrote:
> > > I appreciate this is kind of bikeshed-color territory, but I think "cma"
> &g
On Thu, Apr 24, 2025 at 1:34 AM Maxime Ripard wrote:
> On Tue, Apr 22, 2025 at 12:19:39PM -0700, Jared Kangas wrote:
> > @@ -22,6 +22,7 @@
> > #include
> > #include
> >
> > +#define DEFAULT_CMA_NAME "default_cma"
>
> I appreciate this is kind of bikeshed-color territory, but I think "cma"
> wo
orking out how to improve the standard naming
while keeping compatibility.
I do still hope we can get to the point where other cma regions can be
registered as heaps with unique/purpose-specific names, but I can see
having a standard name for the default region is a nice improvement.
Acked-by: John Stultz
thanks
-john
ooks good to me!
Acked-by: John Stultz
te from 2% to 4% more memory on 16KiB page size kernels.
>
> This change was tested on 4k/16k page size kernels.
>
> Signed-off-by: Juan Yescas
Seems reasonable to me.
Acked-by: John Stultz
thanks
-john
On Tue, Dec 3, 2024 at 11:04 AM Andrew Davis wrote:
> On 12/3/24 1:44 AM, Maxime Ripard wrote:
> > On Mon, Dec 02, 2024 at 11:12:23AM -0800, John Stultz wrote:
> >> Hrm. I'm not sure I see the value in enumerating things in this way,
> >> it seems like it wi
On Mon, Dec 2, 2024 at 3:58 AM Maxime Ripard wrote:
>
> Following a recent discussion at last Plumbers, John Stultz, Sumit
> Sewal, TJ Mercier and I came to an agreement that we should document
> what the dma-buf heaps names are expected to be, and what the buffers
> attributes yo
On Tue, Oct 22, 2024 at 1:38 AM Maxime Ripard wrote:
>
> I wanted to follow-up on the discussion we had at Plumbers with John and
> T.J. about (among other things) adding new heaps to the kernel.
>
> I'm still interested in merging a carve-out driver[1], since it seems to be
> in every vendor BSP
using
> octal permissions '0444'.
> + d = debugfs_create_file("bufinfo", S_IRUGO, dma_buf_debugfs_dir,
>
> total: 1 errors, 4 warnings, 1746 lines checked
>
> Signed-off-by: Pintu Kumar
Looks ok to me. Thanks for sending these cleanups!
Acked-by: John Stultz
On Thu, Sep 5, 2024 at 5:03 PM T.J. Mercier wrote:
>
> Shrink the kernel .text a bit after successful initialization of the
> heaps.
>
> Signed-off-by: T.J. Mercier
Acked-by: John Stultz
er = vma->vm_private_data;
>
> - if (vmf->pgoff > buffer->pagecount)
> + if (vmf->pgoff >= buffer->pagecount)
> return VM_FAULT_SIGBUS;
Thanks for fixing this! (And thanks to Xingyu Jin for catching it!)
Acked-by: John Stultz
thanks
-john
ferred color mode of 32. As this
> is the default if no format has been given, leave it out entirely.
>
> Signed-off-by: Thomas Zimmermann
> Cc: Xinliang Liu
> Cc: Tian Tao
> Cc: Xinwei Kong
> Cc: Sumit Semwal
> Cc: Yongqin Liu
> Cc: John Stultz
> ---
&
On Sat, Jul 20, 2024 at 8:13 AM Markus Elfring wrote:
>
> …
> > +++ b/drivers/dma-buf/dma-heap.c
> …
> > +static void dma_heap_release(struct kref *ref)
> > +{
> …
> > + mutex_lock(&heap_list_lock);
> > + list_del(&heap->list);
> > + mutex_unlock(&heap_list_lock);
> …
>
> Under which c
__u64 heap_flags;
> };
>
> But dma heaps are casting both fd_flags and heap_flags into
> unsigned long. This patch makes dma heaps - cma heap and
> system heap have consistent types with UAPI.
>
> Signed-off-by: Barry Song
Thanks for submitting this additional cleanup!
Acked-by: John Stultz
On Mon, Jun 3, 2024 at 11:30 PM Hailong Liu wrote:
> On 6/4/2024 2:06 AM, John Stultz wrote:
> > On Mon, Jun 3, 2024 at 10:21 AM Hailong Liu wrote:
> >> We now aim to improve priority dma-buf allocation. Consider android
> >> animations scene:
> >>
> >
On Mon, Jun 3, 2024 at 10:21 AM Hailong Liu wrote:
> On Mon, 03. Jun 09:01, John Stultz wrote:
> > On Mon, Jun 3, 2024 at 4:40 AM wrote:
> > >
> > > From: "Hailong.Liu"
> > >
> > > This help module use heap_flags to determine the type o
On Mon, Jun 3, 2024 at 4:40 AM wrote:
>
> From: "Hailong.Liu"
>
> This help module use heap_flags to determine the type of dma-buf,
> so that some mechanisms can be used to speed up allocation, such as
> memory_pool, to optimize the allocation time of dma-buf.
This feels like it's trying to intr
ng;
> };
So here, if I recall, the intent was to keep 64bits for potential
future heap_flags.
But your point above that we're inconsistent with types in the non
UAPI arguments is valid.
So I think your patch makes sense.
Thanks for raising this issue!
Acked-by: John Stultz
On Thu, May 16, 2024 at 5:22 AM Maxime Ripard wrote:
> On Wed, May 15, 2024 at 11:42:58AM -0700, John Stultz wrote:
> > I apologize as my worry is mostly born out of seeing vendors really
> > push opaque feature flags in their old ion heaps, so in providing a
> > flags ar
On Thu, May 16, 2024 at 3:56 AM Daniel Vetter wrote:
> On Wed, May 15, 2024 at 11:42:58AM -0700, John Stultz wrote:
> > But it makes me a little nervous to add a new generic allocation flag
> > for a feature most hardware doesn't support (yet, at least). So it's
> &g
On Wed, May 15, 2024 at 6:57 AM Maxime Ripard wrote:
> This series is the follow-up of the discussion that John and I had a few
> months ago here:
>
> https://lore.kernel.org/all/candhncqujn6bh3kxkf65bwitylvqsd9892-xtfdhhqqyrro...@mail.gmail.com/
>
> The initial problem we were discussing was that
> Cc: Yongqin Liu
> Cc: John Stultz
> Signed-off-by: Ville Syrjälä
Acked-by: John Stultz
On Mon, Apr 8, 2024 at 10:05 AM Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> BIT(32) is illegal when sizeof(long)==4. Use BIT_ULL(32)
> instead.
>
> Cc: Xinliang Liu
> Cc: Tian Tao
> Cc: Xinwei Kong
> Cc: Sumit Semwal
> Cc: Yongqin Liu
> Cc: John St
On Mon, Apr 8, 2024 at 10:05 AM Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> Use the appropriate 64bit division helpers to make the code
> build on 32bit architectures.
>
> Cc: Xinliang Liu
> Cc: Tian Tao
> Cc: Xinwei Kong
> Cc: Sumit Semwal
> Cc: Yongqin
]
>96 | writel(tmp, addr);
> | ^~
>
> Cc: Xinliang Liu
> Cc: Tian Tao
> Cc: Xinwei Kong
> Cc: Sumit Semwal
> Cc: Yongqin Liu
> Cc: John Stultz
> Signed-off-by: Ville Syrjälä
Acked-by: John Stultz
On Mon, Mar 4, 2024 at 5:46 AM Maxime Ripard wrote:
> On Wed, Feb 28, 2024 at 08:17:55PM -0800, John Stultz wrote:
> > On Wed, Feb 28, 2024 at 7:24 AM Maxime Ripard wrote:
> > >
> > > I'm currently working on a platform that seems to have togglable RAM ECC
> &g
On Wed, Feb 28, 2024 at 7:24 AM Maxime Ripard wrote:
>
> I'm currently working on a platform that seems to have togglable RAM ECC
> support. Enabling ECC reduces the memory capacity and memory bandwidth,
> so while it's a good idea to protect most of the system, it's not worth
> it for things like
resource()").
> Thus reuse existing functionality instead of keeping duplicate source code.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring
I no longer have hardware to test with this, but this looks reasonable to me.
Acked-by: John Stultz
thanks
-john
On Wed, Jan 31, 2024 at 6:15 AM Joakim Bech wrote:
> On Fri, Jan 12, 2024 at 05:23:07PM -0800, John Stultz wrote:
> > So we need some clarity in what "restricted" really means. For
> > instance, it being not cpu mappable vs other potential variations like
> >
On Fri, Jan 12, 2024 at 4:13 PM Jeffrey Kardatzke wrote:
> On Fri, Jan 12, 2024 at 3:51 PM John Stultz wrote:
> >
> > On Fri, Jan 12, 2024 at 3:27 PM Jeffrey Kardatzke
> > wrote:
> > > On Fri, Jan 12, 2024 at 2:52 PM John Stultz wrote:
> > > > I kn
On Fri, Jan 12, 2024 at 3:27 PM Jeffrey Kardatzke wrote:
> On Fri, Jan 12, 2024 at 2:52 PM John Stultz wrote:
> > On Fri, Jan 12, 2024 at 1:21 AM Yong Wu wrote:
> > > diff --git a/drivers/dma-buf/heaps/restricted_heap.h
> > > b/drivers/dma-buf/heaps/restricted_heap
On Fri, Jan 12, 2024 at 1:21 AM Yong Wu wrote:
>
> Add "struct restricted_heap_ops". For the restricted memory, totally there
> are two steps:
> a) memory_alloc: Allocate the buffer in kernel;
> b) memory_restrict: Restrict/Protect/Secure that buffer.
> The memory_alloc is mandatory while memory_r
On Mon, Sep 11, 2023 at 3:14 AM Christian König
wrote:
> Am 11.09.23 um 04:30 schrieb Yong Wu:
> > From: John Stultz
> >
> > This allows drivers who don't want to create their own
> > DMA-BUF exporter to be able to allocate DMA-BUFs directly
> > from existin
On Wed, Aug 9, 2023 at 8:04 AM Pintu Agarwal wrote:
>
> Hi,
>
> On Thu, 3 Aug 2023 at 23:04, Pintu Agarwal wrote:
> >
> > Hi,
> >
> > On Wed, 2 Aug 2023 at 15:17, Christoph Hellwig wrote:
> > >
> > > On Tue, Aug 01, 2023 at 10:39:04PM -070
On Tue, Aug 1, 2023 at 10:18 AM Christoph Hellwig wrote:
>
> On Tue, Aug 01, 2023 at 10:42:42PM +0530, Pintu Agarwal wrote:
> > > I agree that reserved is not a very useful name. Unfortuately the
> > > name of the region leaks to userspace through cma_heap.
> > >
> > > So I think we need prep pat
evious ION maintainership, as this couldn't
have gone upstream without her prior efforts. Many thanks!
Cc: Laura Abbott
Cc: T.J. Mercier
Cc: Sumit Semwal
Cc: Benjamin Gaignard
Cc: Brian Starkey
Cc: John Stultz
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.or
T.J. has been responsible for dmab-buf items on the Android team
for awhile now, so it would be great to have him on as a reviewer.
Cc: T.J. Mercier
Cc: Sumit Semwal
Cc: Benjamin Gaignard
Cc: Brian Starkey
Cc: John Stultz
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc
jamin Gaignard
> -R: Liam Mark
> R: Laura Abbott
> R: Brian Starkey
> R: John Stultz
> --
Acked-by: John Stultz
Though probably worth adding TJ as a reviewer?
-john
truct sg_table *table = &buffer->sg_table;
> int npages = PAGE_ALIGN(buffer->len) / PAGE_SIZE;
> - struct page **pages = vmalloc(sizeof(struct page *) * npages);
> + struct page **pages = vmalloc_array(npages, sizeof(struct page *));
> struct page **tmp = pages;
> struct sg_page_iter piter;
> void *vaddr;
Seems reasonable. Thanks for sending this out!
Acked-by: John Stultz
thanks
-john
oc = {vmalloc,vzalloc,kvmalloc,kvzalloc};
> @@
>
> (
> alloc(
> - (e1) * (e2)
> + array_size(e1, e2)
> ,...)
> |
> alloc(
> - (e1) * (COUNT)
> + array_size(COUNT, e1)
> ,...)
> )
> //
>
&
On Mon, Mar 6, 2023 at 8:52 AM Andrew Davis wrote:
>
> Although there is usually not such a limitation (and when there is it is
> often only because the driver forgot to change the super small default),
> it is still correct here to break scatterlist element into chunks of
> dma_max_mapping_size()
Sorry for the delay, this was almost ready to send, but then got
forgotten in my drafts folder.
On Mon, Jan 23, 2023 at 11:15 PM Christian König
wrote:
> Am 24.01.23 um 06:19 schrieb John Stultz:
> > On Mon, Jan 23, 2023 at 8:29 AM Christian König
> > wrote:
> >> Am 2
On Mon, Jan 23, 2023 at 8:29 AM Christian König
wrote:
> Am 23.01.23 um 14:55 schrieb Laurent Pinchart:
> > - I assume some drivers will be able to support multiple heaps. How do
> >you envision this being implemented ?
>
> I don't really see an use case for this.
>
> We do have some drivers w
On Mon, Jan 23, 2023 at 5:55 AM Laurent Pinchart
wrote:
>
> Hi Christian,
>
> CC'ing James as I think this is related to his work on the unix device
> memory allocator ([1]).
>
> [1]
> https://lore.kernel.org/dri-devel/8b555674-1c5b-c791-4547-2ea7c16ae...@nvidia.com/
>
> On Mon, Jan 23, 2023 at 0
On Mon, Jan 23, 2023 at 4:38 AM Christian König
wrote:
>
> This allows device drivers to specify a DMA-heap where they want their
> buffers to be allocated from. This information is then exposed as
> sysfs link between the device and the DMA-heap.
>
> Useful for userspace when in need to decide fr
c: Yongqin Liu
Cc: Sumit Semwal
Cc: kernel-t...@android.com
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz
---
MAINTAINERS | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 42fc47c6edfd..82df566e6925 100644
--- a/MAINTAI
st with, so adding YongQin and Amit.
So maybe a tentative Acked-by: John Stultz
thanks
-john
> ---
>
> Changes in v3:
> - Include io.h for readl/writel
>
> Changes in v2:
> - Use BIT_ULL
>
> drivers/gpu/drm/hisilicon/kirin/Kconfig | 2 +-
> drivers/gpu/drm/h
aoJing
Looks reasonable to me. Thanks for sending this out!
CC'ing YongQin and Sumit as they have hardware to test against.
Acked-by: John Stultz
> ---
> drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/
c: Yongqin Liu
Cc: Sumit Semwal
Cc: kernel-t...@android.com
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz
---
MAINTAINERS | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 2585e7edc335..9f26e6b74ef4 100644
--- a/MAINTAI
s work, but not a
> single line of this code is from me.
>
> Feel free to add my Acked-by, but Laura, John and others do you have any
> opinion?
No objection from me.
Thanks Dawei for submitting this improvement!
Acked-by: John Stultz
thanks
-john
On Thu, Oct 27, 2022 at 11:55 PM Mark-PK Tsai wrote:
>
> Remove duplicated 'by' from comment in cma_heap_allocate().
>
> Signed-off-by: Mark-PK Tsai
Thanks for sending this and going through a few iterations!
Acked-by: John Stultz
-john
c: Yongqin Liu
Cc: Sumit Semwal
Cc: kernel-t...@android.com
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz
---
MAINTAINERS | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index f5ca4aefd184..11027cf9b670 100644
--- a/MAINTAI
On Mon, Feb 14, 2022 at 12:19 PM Todd Kjos wrote:
> On Mon, Feb 14, 2022 at 11:29 AM Suren Baghdasaryan wrote:
> > On Mon, Feb 14, 2022 at 10:33 AM Todd Kjos wrote:
> > >
> > > Since we are creating a new gpu cgroup abstraction, couldn't this
> > > "transfer" be done in userspace by the target i
gt;= ARRAY_SIZE(dma_heap_ioctl_cmds))
> return -EINVAL;
>
> + nr = array_index_nospec(nr, ARRAY_SIZE(dma_heap_ioctl_cmds));
> /* Get the kernel ioctl cmd that matches */
> kcmd = dma_heap_ioctl_cmds[nr];
Thanks for submitting this! It looks sane to me.
Acked-by: John Stultz
thanks
-john
ot; should be less than totalram since
> system_heap
> +* memory is comes from system. Adding check here can prevent
> consuming
> +* too much time for invalid allocations.
> +*/
> + if (len >> PAGE_SHIFT > totalram_pages())
> +
On Wed, Jan 19, 2022 at 1:58 AM Guangming.Cao
wrote:
> On Fri, 2022-01-14 at 17:17 -0800, John Stultz wrote:
> > If the max value is per-heap, why not enforce that value in the
> > per-heap allocation function?
> >
> > Moving the check to the heap alloc to me seems si
On Fri, Jan 14, 2022 at 4:04 AM Guangming.Cao
wrote:
>
> On Fri, 2022-01-14 at 08:16 +0100, Christian König wrote:
> > Am 14.01.22 um 00:26 schrieb John Stultz:
> > > On Thu, Jan 13, 2022 at 5:05 AM Christian König
> > > wrote:
> > > > Am
On Thu, Jan 13, 2022 at 5:05 AM Christian König
wrote:
> Am 13.01.22 um 14:00 schrieb Ruhl, Michael J:
> >> -Original Message-
> >> From: dri-devel On Behalf Of
> >> Ruhl, Michael J
> >>> -Original Message-
> >>> From: dri-devel On Behalf Of
> >>> guangming@mediatek.com
> >>>
izhao Ouyang
Looks good to me! Thanks so much for sending this in!
Acked-by: John Stultz
thanks again
-john
On Mon, Dec 27, 2021 at 1:52 AM wrote:
>
> From: Guangming
>
Thanks for submitting this!
> Add a size check for allcation since the allocation size is
nit: "allocation" above.
> always less than the total DRAM size.
In general, it might be good to add more context to the commit message
to be
On Tue, Dec 28, 2021 at 11:09 PM Weizhao Ouyang wrote:
>
> Fix cma_heap_buffer mutex lock area to protect vmap_cnt and vaddr. And
> move struct dma_heap_attachment to dma-heap.h so that vendor dma heaps
> can use it, the same behaviour as struct dma_buf_attachment.
>
Hey!
Thanks for submitting
he previous rather common
> helper 'for_each_sg' which maybe cause memory leak) is much better.
>
> Fixes: d963ab0f15fb0 ("dma-buf: system_heap: Allocate higher order pages if
> available")
> Signed-off-by: Guangming
> Reviewed-by: Robin Murphy
> Cc: # 5.11.*
Thanks so much for catching this and sending in all the revisions!
Reviewed-by: John Stultz
On Tue, Nov 16, 2021 at 6:07 PM Peter Collingbourne wrote:
>
> It has been observed that with certain monitors such as the HP Z27n,
> the register 0x825e reads a value of 0x79 when the HDMI cable is
> connected and 0x78 when it is disconnected, i.e. bit 0 appears
> to correspond to the HDMI connec
rivers were taking evasive maneuvers to try to workaround this,
> but not all of them were following the same conventions, resulting in
> various incompatibilities between DSI hosts and devices.
>
> Now that we have a sequence agreed upon and documented, let's convert
> kirin to it.
&g
On Thu, Oct 21, 2021 at 6:49 PM Shuosheng Huang
wrote:
>
> Some built-in modules will failed to use dma-buf heap to allocate
> memory if the heap drivers are too late to be initialized.
> To fix this issue, move initialization of dma-buf heap drivers in
> subsys_initcall() which is more earlier to
a workaround for the power
> instability issues on a630.. could you give it a try?
While I hit it fairly often, I can't reliably reproduce the crash, but
in limited testing this seems ok to me.
I've not hit the crash so far, nor seen any other negative side
effects over 5.14.
So for w
On Thu, Oct 7, 2021 at 8:10 AM Arnd Bergmann wrote:
>
> From: Arnd Bergmann
>
> Now that SCM can be a loadable module, we have to add another
> dependency to avoid link failures when ipa or adreno-gpu are
> built-in:
>
> aarch64-linux-ld: drivers/net/ipa/ipa_main.o: in function `ipa_probe':
> ipa
On Wed, Sep 29, 2021 at 4:20 PM Rob Clark wrote:
> On Wed, Sep 29, 2021 at 2:51 PM John Stultz wrote:
> > On Wed, Sep 29, 2021 at 2:32 PM John Stultz wrote:
> > > On Wed, Sep 29, 2021 at 2:27 PM John Stultz
> > > wrote:
> > > > On Fri, Sep 1
On Wed, Sep 29, 2021 at 2:51 PM John Stultz wrote:
>
> On Wed, Sep 29, 2021 at 2:32 PM John Stultz wrote:
> > On Wed, Sep 29, 2021 at 2:27 PM John Stultz wrote:
> > > On Fri, Sep 10, 2021 at 3:12 AM Maxime Ripard wrote:
> > > > The best practice to avoi
On Wed, Sep 29, 2021 at 4:20 PM Rob Clark wrote:
> On Wed, Sep 29, 2021 at 2:51 PM John Stultz wrote:
> > On Wed, Sep 29, 2021 at 2:32 PM John Stultz wrote:
> > > On Wed, Sep 29, 2021 at 2:27 PM John Stultz
> > > wrote:
> > > > On Fri, Sep 1
On Wed, Sep 29, 2021 at 2:32 PM John Stultz wrote:
> On Wed, Sep 29, 2021 at 2:27 PM John Stultz wrote:
> > On Fri, Sep 10, 2021 at 3:12 AM Maxime Ripard wrote:
> > > The best practice to avoid those issues is to register its functions only
> > > after
> > &g
On Wed, Sep 29, 2021 at 2:27 PM John Stultz wrote:
>
> On Fri, Sep 10, 2021 at 3:12 AM Maxime Ripard wrote:
> >
> > We've encountered an issue with the RaspberryPi DSI panel that prevented the
> > whole display driver from probing.
> >
> > The i
On Fri, Sep 10, 2021 at 3:12 AM Maxime Ripard wrote:
>
> We've encountered an issue with the RaspberryPi DSI panel that prevented the
> whole display driver from probing.
>
> The issue is described in detail in the commit 7213246a803f ("drm/vc4: dsi:
> Only register our component once a DSI device
@lists.freedesktop.org
Signed-off-by: John Stultz
---
drivers/dma-buf/heaps/system_heap.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/dma-buf/heaps/system_heap.c
b/drivers/dma-buf/heaps/system_heap.c
index 23a7e74ef966..f57a39ddd063 100644
--- a/drivers/dma-buf
On Thu, Jul 29, 2021 at 1:49 PM Rob Clark wrote:
> On Thu, Jul 29, 2021 at 1:28 PM Caleb Connolly
> wrote:
> > On 29/07/2021 21:24, Rob Clark wrote:
> > > On Thu, Jul 29, 2021 at 1:06 PM Caleb Connolly
> > > wrote:
> > >>
> > >> Hi Rob,
> > >>
> > >> I've done some more testing! It looks like be
...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz
---
drivers/dma-buf/heaps/system_heap.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/dma-buf/heaps/system_heap.c
b/drivers/dma-buf/heaps/system_heap.c
index 23a7e74ef966..f57a39ddd063 100644
--- a
allocation limits.
Reviewed-by: John Stultz
thanks
-john
On Thu, Jul 29, 2021 at 12:24 AM Daniel Vetter wrote:
>
> On Thu, Jul 29, 2021 at 09:03:30AM +0200, Christian König wrote:
> > As we now knew controlling dma_fence synchronization from userspace is
> > extremely dangerous and can not only deadlock drivers but trivially also the
> > whole kernel me
rior to f8f934c180f629bb927a04fd90d)
>
> Reported-by: Dmitry Baryshkov
> Reported-by: Yassine Oudjana
> Fixes: 2a574cc05d38 ("drm/msm: Improve the a6xx page fault handler")
> Signed-off-by: Rob Clark
> Tested-by: John Stultz
> ---
Hey folks!
Just wanted to follow u
On Wed, Jul 7, 2021 at 12:15 AM Christoph Hellwig wrote:
>
> On Wed, Jul 07, 2021 at 09:10:26AM +0200, Christian K??nig wrote:
> > Well, the original code all this is based on already had the comment that
> > this really belong into the page allocator.
> >
> > The key point is traditionally only G
On Tue, Jul 6, 2021 at 11:38 PM Christoph Hellwig wrote:
> On Wed, Jun 30, 2021 at 01:34:17AM +0000, John Stultz wrote:
> > This adds a shrinker controlled page pool, extracted
> > out of the ttm_pool logic, and abstracted out a bit
> > so it can be used by other non-ttm
27;s helpful, I applied that and it got the db845c booting mainline
again for me (along with some reverts for a separate ext4 shrinker
crash).
Tested-by: John Stultz
thanks
-john
On Tue, Jul 6, 2021 at 2:15 PM Daniel Vetter wrote:
>
> On Tue, Jul 6, 2021 at 11:04 PM John Stultz wrote:
> > On Wed, Jun 30, 2021 at 11:52 PM Christian König
> > wrote:
> > >
> > > Am 01.07.21 um 00:24 schrieb John Stultz:
> > > > On Wed, Jun 30
On Wed, Jun 30, 2021 at 11:52 PM Christian König
wrote:
>
> Am 01.07.21 um 00:24 schrieb John Stultz:
> > On Wed, Jun 30, 2021 at 2:10 AM Christian König
> > wrote:
> >> Am 30.06.21 um 03:34 schrieb John Stultz:
> >>> +static unsigned long
On Wed, Jun 30, 2021 at 2:10 AM Christian König
wrote:
> Am 30.06.21 um 03:34 schrieb John Stultz:
> > +static unsigned long page_pool_size; /* max size of the pool */
> > +
> > +MODULE_PARM_DESC(page_pool_size, "Number of pages in the drm page pool");
> >
: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz
---
v2:
* Rework deferred-free api to use
Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz
---
v2:
* Fix sleep in atomic issue from using a
James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz
---
v7:
* Major refactoring to use drm_page_pools inside the
ttm_pool_type structure. This allows us to use container_of to
get the needed context to free a page. This also means less
: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz
---
v2:
* Fix
Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz
---
v8:
* Completely rewritten from scratch
u
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
John Stultz (5):
drm: Add a sharable drm page-pool implementation
drm: ttm
On Fri, Jun 11, 2021 at 2:01 AM Dmitry Baryshkov
wrote:
>
> Hi,
>
> On Fri, 11 Jun 2021 at 10:07, John Stultz wrote:
> >
> > On Wed, Mar 31, 2021 at 3:58 AM Dmitry Baryshkov
> > wrote:
> > >
> > > The 7nm, 10nm and 14nm drivers would store interi
On Wed, Mar 31, 2021 at 3:58 AM Dmitry Baryshkov
wrote:
>
> The 7nm, 10nm and 14nm drivers would store interim data used during
> VCO/PLL rate setting in the global dsi_pll_Nnm structure. Move this data
> structures to the onstack storage. While we are at it, drop
> unused/static 'config' data, un
On Fri, May 21, 2021 at 2:40 AM Lee Jones wrote:
> On Tue, 10 Nov 2020 at 03:49, John Stultz wrote:
>> This series reworks the system heap to use sgtables, and then
>> consolidates the pagelist method from the heap-helpers into the
>> CMA heap. After which the heap-helpers
the CRTC's
> atomic_check() should be adding the planes to the atomic update.
Thanks! This patch gets things booting again!
Tested-by: John Stultz
thanks
-john
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz
---
v2:
* Rework deferred-free api to use
: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz
---
v2:
* Fix
Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz
---
v2:
* Fix sleep in atomic issue from using a
1 - 100 of 1025 matches
Mail list logo
