Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

97 participants
7139 discussions

Re: [PATCH] drm: docs: Remove item from TODO list

by Maxime Ripard

Hi, On Mon, Oct 23, 2023 at 10:25:50AM -0700, Doug Anderson wrote: > On Mon, Oct 23, 2023 at 9:31 AM Yuran Pereira <yuran.pereira(a)hotmail.com> wrote: > > > > Since "Clean up checks for already prepared/enabled in panels" has > > already been done and merged [1], I think there is no longer a need > > for this item to be in the gpu TODO. > > > > [1] https://patchwork.freedesktop.org/patch/551421/ > > > > Signed-off-by: Yuran Pereira <yuran.pereira(a)hotmail.com> > > --- > > Documentation/gpu/todo.rst | 25 ------------------------- > > 1 file changed, 25 deletions(-) > > It's not actually all done. It's in a bit of a limbo state right now, > unfortunately. I landed all of the "simple" cases where panels were > needlessly tracking prepare/enable, but the less simple cases are > still outstanding. > > Specifically the issue is that many panels have code to properly power > cycle themselves off at shutdown time and in order to do that they > need to keep track of the prepare/enable state. After a big, long > discussion [1] it was decided that we could get rid of all the panel > code handling shutdown if only all relevant DRM KMS drivers would > properly call drm_atomic_helper_shutdown(). > > I made an attempt to get DRM KMS drivers to call > drm_atomic_helper_shutdown() [2] [3] [4]. I was able to land the > patches that went through drm-misc, but currently many of the > non-drm-misc ones are blocked waiting for attention. > > ...so things that could be done to help out: > > a) Could review patches that haven't landed in [4]. Maybe adding a > Reviewed-by tag would help wake up maintainers? > > b) Could see if you can identify panels that are exclusively used w/ > DRM drivers that have already been converted and then we could post > patches for just those panels. I have no idea how easy this task would > be. Is it enough to look at upstream dts files by "compatible" string? I think it is, yes. Maxime

1 hour, 49 minutes

A Fun Guide to Monkey Mart

by wet.piranha.iruk＠hidepost.net

https://monkeymartfree.com If you are looking for a lighthearted way to unwind after a long day, management simulators are often the perfect prescription. Among the sea of complex strategy games, one title stands out for its charming simplicity and addictive loop: Monkey Mart. This vibrant, browser-based game puts you in the paws of an ambitious primate entrepreneur looking to build the most successful grocery empire in the jungle. Here is a guide on how to experience this delightful game and make your supermarket the talk of the animal kingdom. What is Monkey Mart? Monkey Mart is a "casual idle" management game where you control a hard-working monkey who has just opened a fresh produce market. The game combines the satisfaction of a business sim with the smooth movement of an arcade game. Unlike heavy-duty simulators that require tracking complex spreadsheets, this game focuses on the physical flow of goods—planting, harvesting, stocking, and cashing out happy customers. How to Play: The Daily Grind The gameplay loop is intuitive and satisfying. You start with a single plot of land where you grow bananas. As the player, you move your monkey around to harvest the fruit and carry it to the display stands. Once the shelves are stocked, fellow animals—from chickens to cows—will wander in to fill their baskets. As you collect money from the cash register, you can unlock new features: 1. Expansion: Use your profits to open new stalls for corn, eggs, milk, and even baked goods. 2. Hiring Staff: Eventually, the store gets too big for one monkey. You can hire assistants to restock shelves or cashiers to handle the long lines. 3. Processing: Later in the game, you aren't just selling raw fruit. You’ll invest in machines to turn flour and chocolate into delicious cookies or milk into cheese. Tips for Success To turn your small stand into a bustling mega-mart, keep these strategies in mind: Prioritize the Register: Customers will wait for items to be stocked, but they get impatient at the checkout. Always make sure the register is clear so the cash keeps flowing. Invest in Speed: In the early game, use your coins to upgrade your monkey’s movement speed and carrying capacity. The more you can carry at once, the less time you spend backtracking. Balance Your Staff: Don’t just hire everyone at once. Observe where the bottleneck is. If the shelves are empty, hire a restocker. If the line is out the door, upgrade your cashier. Keep Your Staff Awake: Your AI helpers occasionally take naps! Make sure to walk over to them to wake them up and keep the productivity high. Why It’s Worth Your Time The beauty of playing Monkey Mart lies in its visual feedback. Watching the shelves fill up and seeing the "money pop" when you finish a transaction provides a steady stream of "mini-wins" that make the experience incredibly relaxing. The art style is colorful and cute, making it a great choice for players of all ages. Conclusion Monkey Mart proves that a game doesn’t need a dark storyline or high-end graphics to be deeply engaging. It is a game about growth, efficiency, and the simple joy of building something from the ground up. Whether you have five minutes between tasks or an hour to kill on a weekend, stepping into the role of a jungle manager is a fantastic way to spend your time. Give it a try—your customers are waiting!

5 hours, 28 minutes

[PATCH v7] dma-buf: Fix silent overflow for phys vec to sgt

by David Hu

In case MMIO size is bigger than 4G and peer2peer DMA goes through host bridge, we trigger a code path that assigns the total linked IOVA (which is greater than 4G) to mapped_len. Previously, `mapped_len` was declared as 32-bit `unsigned int`. When accumulating `size_t` lengths, this leads to a silent wrap-around. This truncation causes truncated lengths to be passed to functions like `fill_sg_entry()`. Fix this by changing `mapped_len` to `size_t` (64-bit). While at it, fix similar potential overflow issues in `calc_sg_nents` by using `check_add_overflow()` for `nents` and using `unsigned int` for the loop iterator in `fill_sg_entry` to match. Fixes: 3aa31a8bb11e ("dma-buf: provide phys_vec to scatter-gather mapping routine") Cc: stable(a)vger.kernel.org Cc: iommu(a)lists.linux.dev Reviewed-by: Pranjal Shrivastava <praan(a)google.com> Reviewed-by: Kevin Tian <kevin.tian(a)intel.com> Reviewed-by: Leon Romanovsky <leon(a)kernel.org> Signed-off-by: David Hu <xuehaohu(a)google.com> --- Changes in v7: - Added a missing blank line after local variable declaration in `calc_sg_nents()` (Leon). - Collected Reviewed-by from Leon Romanovsky. Changes in v6: - Used `check_add_overflow()` in `calc_sg_nents()` for safer accumulation (Leon). - Dropped explicit `!nents` check and added a comment noting that `sg_alloc_table` handles `nents == 0` (Leon). - Collected Reviewed-by from Kevin Tian. Changes in v5: - Removed WARN_ON_ONCE from calc_sg_nents() to avoid log noise (Jason). - Added explicit check for `!nents` in dma_buf_phys_vec_to_sgt() to cleanly return -EINVAL on overflow (Jason). Changes in v4: - Added WARN_ON_ONCE() to the nents overflow check to prevent silent failures (Claude Bot). Changes in v3: - Removed leftover sentence fragment from the commit message. - Kept `nents = 0` initialization (previously stated as removed in the v2 changelog) as it is strictly required for the `+=` accumulation loop in `calc_sg_nents()`. Changes in v2: - Fixed 'IVOA' -> 'IOVA' typo and expanded commit message (Claude Bot). - Added Reverse Xmas tree formatting (Pranjal). - Folded in extra bounds checking for calc_sg_nents() (Pranjal). - Folded in type consistency fix for fill_sg_entry() (Pranjal). - Collected Reviewed-by from Pranjal Shrivastava. drivers/dma-buf/dma-buf-mapping.c | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/drivers/dma-buf/dma-buf-mapping.c b/drivers/dma-buf/dma-buf-mapping.c index 794acff2546a..80f6ab2f4809 100644 --- a/drivers/dma-buf/dma-buf-mapping.c +++ b/drivers/dma-buf/dma-buf-mapping.c @@ -5,12 +5,13 @@ */ #include <linux/dma-buf-mapping.h> #include <linux/dma-resv.h> +#include <linux/overflow.h> static struct scatterlist *fill_sg_entry(struct scatterlist *sgl, size_t length, dma_addr_t addr) { unsigned int len, nents; - int i; + unsigned int i; nents = DIV_ROUND_UP(length, UINT_MAX); for (i = 0; i < nents; i++) { @@ -40,8 +41,12 @@ static unsigned int calc_sg_nents(struct dma_iova_state *state, size_t i; if (!state || !dma_use_iova(state)) { - for (i = 0; i < nr_ranges; i++) - nents += DIV_ROUND_UP(phys_vec[i].len, UINT_MAX); + for (i = 0; i < nr_ranges; i++) { + unsigned int added = DIV_ROUND_UP(phys_vec[i].len, UINT_MAX); + + if (check_add_overflow(nents, added, &nents)) + return 0; + } } else { /* * In IOVA case, there is only one SG entry which spans @@ -95,9 +100,10 @@ struct sg_table *dma_buf_phys_vec_to_sgt(struct dma_buf_attachment *attach, size_t nr_ranges, size_t size, enum dma_data_direction dir) { - unsigned int nents, mapped_len = 0; struct dma_buf_dma *dma; struct scatterlist *sgl; + size_t mapped_len = 0; + unsigned int nents; dma_addr_t addr; size_t i; int ret; @@ -133,6 +139,8 @@ struct sg_table *dma_buf_phys_vec_to_sgt(struct dma_buf_attachment *attach, } nents = calc_sg_nents(dma->state, phys_vec, nr_ranges, size); + + /* sg_alloc_table will cleanly fail and return -EINVAL if nents == 0 */ ret = sg_alloc_table(&dma->sgt, nents, GFP_KERNEL | __GFP_ZERO); if (ret) goto err_free_state; -- 2.54.0.1064.gd145956f57-goog

8 hours, 36 minutes

Re: [PATCH v1] dma-buf/udmabuf: Disable the size limit by default

by Kasireddy, Vivek

Hi Robert, > Subject: [PATCH v1] dma-buf/udmabuf: Disable the size limit by default > > As udmabuf increasingly enjoys popularity - being used in projects like > libcamera, Gstreamer, Mesa, KWin and Weston - users more frequently > encounter cases where the current default size limit of 64MB is too low. > Examples include allocating video buffers at a 8K resolution - and even 4K > is affected when using non-subsampled video formats and high bit depths. > > In its current form the size limit for individual buffers does not seem to > provide any additional level of protection - such as limiting the amount of > memory a process can pin - as the later can just allocate multiple buffers. > If additional guardrails are desired, they would likely require some kind > accounting not limited to individual buffers. > > Therefor let's disable the size limit by default. Use the special value > of zero to do so, which prevously could be used to effectively disable the > interface. Using other means, such as file permissions, appears to be a > much better fit for that purpose. > > Signed-off-by: Robert Mader <robert.mader(a)collabora.com> > > --- > > Please let me know if changing the meaning of the parameter value of zero > is considered a breaking change / not acceptable. In that case INT_MAX > might be a better option. Yeah, I think using INT_MAX might be better. Thanks, Vivek > > See > https://lore.kernel.org/dri-devel/20260711144814.8205-1- > robert.mader(a)collabora.com/ > for a previous attempt to make the value configurable via kconfig - and > in particular > https://lore.kernel.org/dri-devel/6764ca6f-b4d8-4baa-9d27- > 2ca867ac2d41(a)amd.com/ > for the suggestion and discussion to remove the default limit. > --- > drivers/dma-buf/udmabuf.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c > index bced421c0d65..3509b690d8e2 100644 > --- a/drivers/dma-buf/udmabuf.c > +++ b/drivers/dma-buf/udmabuf.c > @@ -20,9 +20,9 @@ static int list_limit = 1024; > module_param(list_limit, int, 0644); > MODULE_PARM_DESC(list_limit, "udmabuf_create_list->count limit. > Default is 1024."); > > -static int size_limit_mb = 64; > +static int size_limit_mb = 0; > module_param(size_limit_mb, int, 0644); > -MODULE_PARM_DESC(size_limit_mb, "Max size of a dmabuf, in > megabytes. Default is 64."); > +MODULE_PARM_DESC(size_limit_mb, "Max size of a dmabuf, in > megabytes. Setting 0 disables the limit. Default is 0."); > > struct udmabuf { > pgoff_t pagecount; > @@ -373,7 +373,7 @@ static long udmabuf_create(struct miscdevice > *device, > > subpgcnt = list[i].size >> PAGE_SHIFT; > pgcnt += subpgcnt; > - if (pgcnt > pglimit) > + if (pglimit && pglimit < pgcnt) > goto err_noinit; > > max_nr_folios = max_t(unsigned long, subpgcnt, > max_nr_folios); > -- > 2.55.0

1 day

Which Japanese estate car deserves more attention?

by abdulsamad.nobuko＠gmail.com

I've been looking into Japanese estate cars recently, and it seems that a few excellent models never get the recognition they deserve. Everyone talks about the usual choices, but there are several practical, reliable wagons that offer great value without attracting much attention. One thing I appreciate about Japanese estate cars is their balance of comfort, fuel efficiency, and long-term dependability. Whether you're carrying family, luggage, or work equipment, they often provide more space than many people expect. Some underrated options that deserve a closer look include: * Toyota Caldina for its reliability and versatile design. * Nissan Stagea, especially for drivers who enjoy a more performance-oriented estate. * Subaru Legacy Touring Wagon with its excellent all-wheel-drive capability. * Honda Accord Wagon, which combines comfort with dependable engineering. While researching different models, I also noticed that experienced **Japanese used car dealers** often recommend checking the vehicle's maintenance history, auction grade, and export documentation before making a purchase. Those factors usually matter more than simply choosing the most popular model. I came across some useful information about Japanese vehicle sourcing while browsing https://nobukojapan.com, particularly regarding the import process and how vehicles are selected before export. It helped me better understand what to look for when comparing different estate cars. I'm curious to hear from people who have actually owned one of these wagons. Which Japanese estate car do you think is the most underrated, and why? Are there any hidden gems that deserve more attention but rarely get mentioned?

1 day, 1 hour

Master the Momentum: Your Guide to Conquering the Slope Game

by teenage.wildcat.fimz＠hidepost.net

Ever found yourself yearning for a game that’s easy to pick up but surprisingly challenging to master? Look no further than the captivating world of Slope Game. This deceptively simple yet incredibly addictive game offers a thrilling experience of precision and momentum, perfect for a quick burst of fun or a longer session of skill-building. If you’re curious about diving into this downhill adventure, this guide will walk you through everything you need to know. https://slopegamefree.com/ Introduction to the Downhill Dash Slope Game is an endless runner game where your primary objective is to guide a rolling ball down an ever-descending, procedurally generated slope. The beauty of the game lies in its minimalist design: vibrant green terrain against a stark black backdrop, creating a focused and immersive environment. There are no power-ups, no enemies, just you, your ball, and the relentless pull of gravity. It's a test of reflexes, anticipation, and pure gaming zen. Tips for Conquering the Slope Game While the game is simple, achieving high scores requires a bit of practice and strategy. Here are a few tips to help you master the momentum: Look Ahead: Don't just focus on the immediate path. Try to scan the terrain ahead to anticipate upcoming turns and obstacles. This foresight will give you precious milliseconds to plan your move. Gentle Taps, Not Hard Presses: The controls are sensitive. Instead of holding down the steering keys, use short, gentle taps to make minor adjustments. Over-steering is a common mistake that can lead to an untimely demise. Embrace the Airtime: Ramps are your friend! While they might seem daunting, mastering landings after a jump can help you clear obstacles and gain speed. Aim to land smoothly on the slope to maintain your momentum. Practice Makes Perfect: Like any skill-based game, consistent practice is crucial. Don't get discouraged by early failures. Each run teaches you something new about the terrain and your own reactions. Find Your Flow: There’s a certain rhythm to Slope Game. Once you find that sweet spot between anticipating and reacting, the game becomes incredibly satisfying. Try to relax your grip and let your reflexes take over. You can experience the thrill of the chase and test your skills on Slope Game. Conclusion: An Endless Journey of Skill Slope Game is more than just a casual time-killer; it's a testament to the power of simple game design. Its addictive nature, coupled with its ever-increasing challenge, makes it a rewarding experience for players of all skill levels. Whether you're looking to unwind with a quick game or push your reflexes to their limits, Slope Game offers an engaging and endlessly replayable adventure.

1 day, 4 hours

Why Choose Cryptera Chain Signals for DeFi Hack Recovery

by luisannete22＠gmail.com

DeFi hacks are rampant in 2026, but Cryptera Chain Signals specializes in recoveries, making them a top choice. This explores why, with educational depth. Their multi chain proficiency covers exploits like flash loans. Tracing involves contract disassembly, identifying vulnerabilities post hack. Collaborations with protocols enable bounties or freezes. Educatively, they teach on insurance like Nexus Mutual. Choosing them means proven results and client centric service. For DeFi recovery, Cryptera Chain Signals intervenes with precise forensics. Visit https://www.crypterachainsignals.com/, contact info(a)crypterachainsignals.com. They stand out for DeFi victims.

1 day, 7 hours

Cryptera Chain Signals Summary – Focus On Transparency During Recovery Process

by Yulie Morgan

After experiencing a bridge exploit I worked with Cryptera Chain Signals to understand the movement of funds. Their process was transparent from day one: secure intake, detailed mapping with multi-layer attribution, and regular updates with visual explanations. They showed how cross-chain hops complicated the trail and why some paths reach natural limits. The educational discussions helped me grasp broader concepts — immutable records, pattern detection, and behavioral analysis. Rather than technical overload, the explanations focused on what each step revealed about the incident. Recovery options were limited by timing, but the clarity removed guesswork. I particularly appreciated the practical security advice that followed: hardware wallet recommendations, seed phrase protection, and checks for anomalous activity. These became part of my routine. The engagement was professional, informative, and free of pressure. It provided both a factual account of the loss and lasting insights into safer crypto practices. Cryptera Chain Signals Website: https://www.crypterachainsignals.com Email: info(a)crypterachainsignals.com

1 day, 7 hours

[PATCH net-next v5 0/3] net: devmem: allow rx-buf-size > PAGE_SIZE per binding

by Bobby Eshleman

Every devmem dmabuf binding hands the page_pool PAGE_SIZE niovs today. On NICs that consume one descriptor per netmem, this caps a single RX descriptor at PAGE_SIZE and burns CPU on buffer churn. In this series, we add a bind-time netlink attribute, NETDEV_A_DMABUF_RX_BUF_SIZE, that lets userspace request a larger niov size (power of two >= PAGE_SIZE). Drivers must opt in via queue_mgmt_ops.QCFG_RX_PAGE_SIZE. Measurements: Setup: kperf devmem RX/TX cuda, 4 flows, 64 MB messages, 60s, dctcp, num-rx-queues=4, dmabuf-rx/tx-size-mb=2048, 10 runs per niov size, mlx5. niov RX dev Gbps RX flow avg Gbps app sys % ----- ---------------- ----------------- ---------------- 4K 300.63 +/- 53.21 75.16 +/- 13.30 54.15 +/- 10.23 16K 321.35 +/- 28.20 80.34 +/- 7.05 41.05 +/- 8.87 32K 347.63 +/- 2.20 86.91 +/- 0.55 44.54 +/- 3.51 64K 332.11 +/- 14.26 83.03 +/- 3.56 35.47 +/- 3.11 RX app sys % drops ~19% from 4K to 64K. kperf support (not yet merged): https://github.com/facebookexperimental/kperf/commit/8837577f920876bce6986e… Signed-off-by: Bobby Eshleman <bobbyeshleman(a)meta.com> --- Changes in v5: - removed unnecessary change from ssize_t to size_t (Mina) - removed '--------' lines in the commit message (Paolo) - removed commit msg about CONFIG_HUGETLB since that change was already merged - Link to v4: https://lore.kernel.org/r/20260701-tcpdm-large-niovs-v4-0-ca4654f37570@meta… Changes in v4: - ncdevmem: fix the possible overflow in ncdevmem (Sashiko) - drop the udmabuf patch because the fix is now already in net-next - silenced two pylint complaints in devmem_lib.py - Link to v3: https://lore.kernel.org/r/20260612-tcpdm-large-niovs-v3-0-a3b693e76fcb@meta… Changes in v3: - fix a bunch of non-reverse christmas tree declarations (Stan) - remove extra uint32 cast for getpagesize() (Stan) - remove overzealous strtoul checking (Stan) - remove value checks that the kernel already performs on rx_buf_size (Stan) - Link to v2: https://lore.kernel.org/r/20260611-tcpdm-large-niovs-v2-0-ee2bf15e7523@meta… Changes in v2: - Use NL_SET_ERR_MSG_FMT for sg alignment failure details (Stan) - Keep -E2BIG (not a direct ask, but seemed preferred, Stan) - Update udmabuf commit message and comments explaining why "one sg ent per folio" is useful (Christian) - Set/restore nr_hugepages in py harness (Stan) - Link to v1: https://lore.kernel.org/r/20260603-tcpdm-large-niovs-v1-0-f37a4ac6726c@meta… --- Bobby Eshleman (3): net: devmem: allow rx-buf-size > PAGE_SIZE per dmabuf binding selftests/net: ncdevmem: add -b option to set rx-buf-size on bind selftests/net: devmem.py: add check_rx_large_niov Documentation/netlink/specs/netdev.yaml | 8 +++ include/uapi/linux/netdev.h | 1 + net/core/devmem.c | 51 +++++++++++-------- net/core/devmem.h | 13 +++-- net/core/netdev-genl-gen.c | 5 +- net/core/netdev-genl.c | 19 ++++++- tools/include/uapi/linux/netdev.h | 1 + tools/testing/selftests/drivers/net/hw/devmem.py | 12 ++++- .../testing/selftests/drivers/net/hw/devmem_lib.py | 59 +++++++++++++++++++++- tools/testing/selftests/drivers/net/hw/ncdevmem.c | 36 +++++++++++-- .../testing/selftests/drivers/net/hw/nk_devmem.py | 11 +++- 11 files changed, 178 insertions(+), 38 deletions(-) --- base-commit: 474cff6868129755cf889edf40d7f491729fc588 change-id: 20260602-tcpdm-large-niovs-56523a3a1077 Best regards, -- Bobby Eshleman <bobbyeshleman(a)meta.com>

1 day, 12 hours

[PATCH 7.1 0056/2077] dma-fence: Fix potential tracepoint null pointer dereferences

by Greg Kroah-Hartman

7.1-stable review patch. If anyone has any objections, please let me know. ------------------ From: Tvrtko Ursulin <tvrtko.ursulin(a)igalia.com> [ Upstream commit e94b9f01543cc6a83538c2c2cc645a424d3015ca ] Trace_dma_fence_signaled, trace_dma_fence_wait_end and trace_dma_fence_destroy can all currently dereference a null fence->ops pointer after it has been reset on fence signalling. Lets use the safe string getters for most tracepoints to avoid this class of a problem, while for the signal tracepoint we move it to before ops are cleared to avoid losing the driver and timeline name information. Apart from moving it we also need to add a new tracepoint class to bypass the safe name getters since the signaled bit is already set. For dma_fence_init we also need to use the new tracepoint class since the rcu read lock is not held there, and we can do the same for the enable signaling since there we are certain the fence cannot be signaled while we are holding the lock and have even validated the fence->ops. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin(a)igalia.com> Fixes: 541c8f2468b9 ("dma-buf: detach fence ops on signal v3") Cc: Christian König <christian.koenig(a)amd.com> Cc: Philipp Stanner <phasta(a)kernel.org> Cc: Boris Brezillon <boris.brezillon(a)collabora.com> Cc: linux-media(a)vger.kernel.org Cc: linaro-mm-sig(a)lists.linaro.org Reviewed-by: Christian König <christian.koenig(a)amd.com> Signed-off-by: Tvrtko Ursulin <tursulin(a)ursulin.net> Link: https://lore.kernel.org/r/20260415083207.40513-2-tvrtko.ursulin@igalia.com Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/dma-buf/dma-fence.c | 3 ++- include/trace/events/dma_fence.h | 40 +++++++++++++++++++++++++++----- 2 files changed, 36 insertions(+), 7 deletions(-) diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c index a2aa82f4eedd49..b3bfa6943a8e13 100644 --- a/drivers/dma-buf/dma-fence.c +++ b/drivers/dma-buf/dma-fence.c @@ -363,6 +363,8 @@ void dma_fence_signal_timestamp_locked(struct dma_fence *fence, &fence->flags))) return; + trace_dma_fence_signaled(fence); + /* * When neither a release nor a wait operation is specified set the ops * pointer to NULL to allow the fence structure to become independent @@ -377,7 +379,6 @@ void dma_fence_signal_timestamp_locked(struct dma_fence *fence, fence->timestamp = timestamp; set_bit(DMA_FENCE_FLAG_TIMESTAMP_BIT, &fence->flags); - trace_dma_fence_signaled(fence); list_for_each_entry_safe(cur, tmp, &cb_list, node) { INIT_LIST_HEAD(&cur->node); diff --git a/include/trace/events/dma_fence.h b/include/trace/events/dma_fence.h index 3abba45c0601a4..5b10a9e06fb4ec 100644 --- a/include/trace/events/dma_fence.h +++ b/include/trace/events/dma_fence.h @@ -9,12 +9,40 @@ struct dma_fence; +DECLARE_EVENT_CLASS(dma_fence, + + TP_PROTO(struct dma_fence *fence), + + TP_ARGS(fence), + + TP_STRUCT__entry( + __string(driver, dma_fence_driver_name(fence)) + __string(timeline, dma_fence_timeline_name(fence)) + __field(unsigned int, context) + __field(unsigned int, seqno) + ), + + TP_fast_assign( + __assign_str(driver); + __assign_str(timeline); + __entry->context = fence->context; + __entry->seqno = fence->seqno; + ), + + TP_printk("driver=%s timeline=%s context=%u seqno=%u", + __get_str(driver), __get_str(timeline), __entry->context, + __entry->seqno) +); + /* * Safe only for call sites which are guaranteed to not race with fence - * signaling,holding the fence->lock and having checked for not signaled, or the - * signaling path itself. + * signaling, holding the fence->lock and having checked for not signaled, or + * the signaling path itself. + * + * TODO: Remove the need for this event class when drivers switch to independent + * fences. */ -DECLARE_EVENT_CLASS(dma_fence, +DECLARE_EVENT_CLASS(dma_fence_ops, TP_PROTO(struct dma_fence *fence), @@ -46,7 +74,7 @@ DEFINE_EVENT(dma_fence, dma_fence_emit, TP_ARGS(fence) ); -DEFINE_EVENT(dma_fence, dma_fence_init, +DEFINE_EVENT(dma_fence_ops, dma_fence_init, TP_PROTO(struct dma_fence *fence), @@ -60,14 +88,14 @@ DEFINE_EVENT(dma_fence, dma_fence_destroy, TP_ARGS(fence) ); -DEFINE_EVENT(dma_fence, dma_fence_enable_signal, +DEFINE_EVENT(dma_fence_ops, dma_fence_enable_signal, TP_PROTO(struct dma_fence *fence), TP_ARGS(fence) ); -DEFINE_EVENT(dma_fence, dma_fence_signaled, +DEFINE_EVENT(dma_fence_ops, dma_fence_signaled, TP_PROTO(struct dma_fence *fence), -- 2.53.0

1 day, 15 hours

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig