Linaro-mm-sig July 2026

linaro-mm-sig@lists.linaro.org

90 participants
99 discussions

Brand Awareness: Unlock the Power of Robust Wiki Profile

by cameronluka9＠gmail.com

Wikipedia Page Creations offers comprehensive content services for clients seeking professionally developed Wikipedia articles. Our company provides article writing, content editing, page updates, consultation, and ongoing support, ensuring every project is handled with care and attention to detail at https://www.wikipediapagecreations.com/. Our commitment to quality and personalized service has made them a trusted choice for clients across various industries.

4 days, 5 hours

Venting Safely: A Look at the Joyfully Destructive World of Kick the Buddy

by happy.peafowl.mbed＠hidepost.net

We all have those moments, don't we? A frustrating day at work, a challenging interaction, or simply a build-up of everyday annoyances. Sometimes, you just need a healthy outlet to release that pent-up energy without actually harming anyone or anything important. That's where games like kick the buddy step in, offering a uniquely satisfying and surprisingly cathartic experience. Far from being just mindless destruction, these digital stress-relievers provide a humorous and accessible way to blow off steam. https://kickthebuddy.lol/ For those unfamiliar, Kick the Buddy is a mobile and web-based game centered around a simple, yet endlessly entertaining premise: you get to virtually abuse a ragdoll character named Buddy in a multitude of creative and over-the-top ways. It’s the kind of game that doesn't take itself seriously, and that's precisely its charm. It's not about intricate storylines or strategic battles; it's about pure, unadulterated, and consequence-free catharsis. The Gameplay Loop: A Symphony of Destruction The core gameplay of Kick the Buddy is refreshingly straightforward. Upon starting the game, you're presented with Buddy, a perpetually cheerful (or perhaps just oblivious) ragdoll, usually standing in the center of a room. Your objective? To unleash your inner destructive tendencies upon him using a vast arsenal of weapons and gadgets. The controls are intuitive and designed for touchscreens, making it incredibly easy to pick up and play. You simply tap and drag to throw Buddy around, or tap on weapons from a side menu to deploy them. The initial weapons are usually simple – a basic pistol, a baseball bat, or perhaps some throwing knives. As you play and earn in-game currency (often through the sheer volume of damage you inflict), you unlock more outlandish and elaborate tools of destruction. And this is where the game truly shines. The variety of ways you can "punish" Buddy is genuinely impressive and often hilarious. Want to pepper him with machine gun fire? Go for it. Feel like freezing him solid and then smashing him with a sledgehammer? Absolutely. Fancy launching him into space with a rocket launcher or calling down an airstrike? All within the realm of possibility. There are even more esoteric options like black holes, elemental attacks, and bizarre, fantastical devices that defy easy categorization. Each weapon has its own unique animation and sound effect, adding to the satisfying feedback loop. Beyond simply using weapons, you can also interact with Buddy directly. Drag him, spin him, bounce him off the walls – the physics engine, while not hyper-realistic, is good enough to make these interactions feel dynamic and engaging. There are also environmental hazards that can be triggered, like spikes emerging from the floor or laser grids. The goal is to inflict as much damage as possible, which then translates into the in-game currency you use to unlock more fun ways to inflict damage. It's a self-perpetuating cycle of gleeful destruction. You can experience this stress-relieving fun for yourself by checking out the official game at Kick the Buddy. Tips for Maximizing Your Mayhem (and Your Stress Relief) While "Kick the Buddy" might seem like a game where you can just randomly tap and destroy, a few tips can enhance your experience and make your stress-relief sessions even more effective: Experiment with Your Arsenal: Don't stick to just one or two weapons. The joy of the game comes from discovering new and increasingly outlandish ways to "kick" Buddy. Try combining different attacks – freeze him, then hit him with a rocket, then electrocute him. The creative possibilities are endless. Focus on Combos: Many weapons work well in conjunction with others. For instance, weapons that pin Buddy down (like a net) can set him up perfectly for more powerful, slower-acting weapons. Similarly, explosive weapons can launch him into environmental hazards for bonus points. Embrace the Absurdity: The game is meant to be silly. Don't overthink it. The more you lean into the over-the-top nature of the destruction, the more enjoyable it becomes. Laugh at the ridiculous sound effects and Buddy's enduring resilience. Utilize the Environment: Keep an eye out for interactive elements in the background. Sometimes, there are buttons or levers that can trigger unique hazards or effects, adding another layer of destructive fun. Don't Rush: While it's tempting to just spam weapons, take a moment to appreciate the animations and the effects. Sometimes, the most satisfying moments come from a perfectly timed, powerful attack. Consider Customization: As you progress, you'll often unlock options to customize Buddy's appearance or the background. While purely cosmetic, these can add a fresh feel to your destructive escapades. Conclusion: A Digital Punching Bag for the Soul "Kick the Buddy" and similar games offer a unique and genuinely beneficial form of entertainment. They provide a safe, consequence-free space to vent frustrations, unleash a little harmless aggression, and simply de-stress. It's a reminder that sometimes, the most effective way to deal with the pressures of life is to simply embrace a little absurdity and blow off some steam, even if it's just by virtually pelting a cheerful ragdoll with a barrage of rockets and lasers. So, the next time you feel a bit overwhelmed, consider giving Buddy a friendly (or not-so-friendly) visit – your sanity might just thank you for it.

4 days, 9 hours

[PATCH 0/5] drm/sched: Introduce the miracle of locking to entity

by Philipp Stanner

Both Tvrtko [1] and I [2] have recently proposed some improvals for drm_sched. While taking Tvrtko's feedback into account for my patch, I realized that both his and my patch can be fully replaced with a bigger and far more beautiful series. If I am not mistaken, it turns out that the entire entity->entity_idle completion is also nothing but a workaround around the grave mistake of not using the greatest helper with parallel programming that exists in computer science: Locking. This series adds locking to the last_scheduled field and all checks related to detect the idleness of the entity. As before, the job_scheduled event queue causes the periodic checks. This way, we can get rid of memory barriers, RCU, a few lines of code, make things more readable, understandable... Tested with drm-sched-unit tests. I'm a bit busy right now, but wanted to show you guys the idea. Before merging I'd test it more exhaustively with Nouveau. Greetings, Philipp [1] https://lore.kernel.org/dri-devel/20260611123423.39819-1-tvrtko.ursulin@iga… [2] https://lore.kernel.org/dri-devel/20260626081942.2122144-2-phasta@kernel.or… Philipp Stanner (5): drm/sched: Protect entity->last_scheduled with spinlock drm/sched: Lock spsc_queue in drm_sched_entity_pop_job() drm/sched: Avoid lock cycle for sched_entity drm/sched: Lock drm_sched_entity_is_idle() drm/sched: Remove entity->entity_idle drivers/gpu/drm/scheduler/sched_entity.c | 75 +++++++++++------------- drivers/gpu/drm/scheduler/sched_main.c | 2 - drivers/gpu/drm/scheduler/sched_rq.c | 5 +- include/drm/gpu_scheduler.h | 16 ++--- 4 files changed, 41 insertions(+), 57 deletions(-) base-commit: be4f10d44757211fd656fa57f37034657f26c883 -- 2.54.0

5 days

[PATCH v3 0/2] dma-buf: fix fd leak when copy_to_user() fails after fd_install()

by Baineng Shou

Several drivers call dma_buf_fd() — which internally calls fd_install() — before copy_to_user() returns the fd number to userspace. If copy_to_user() fails, the fd is already published in the caller's fd table but the ioctl returns an error, so userspace never learns the fd number. Worse, the window between fd_install() and copy_to_user() allows other threads to observe and manipulate the fd (dup, close, SCM_RIGHTS), making any "close it on the failure path" fix unsafe. The fix is to split the allocation into three steps: reserve an fd with get_unused_fd_flags() (not yet visible to other threads), do copy_to_user(), and only then publish the fd with fd_install() via the new dma_buf_fd_install() helper. On copy_to_user() failure, put_unused_fd() + dma_buf_put() cleanly unwind with no user-visible side effects. Patch 1 introduces dma_buf_fd_install() in dma-buf.c (wrapping fd_install() together with the DMA_BUF_TRACE call to preserve export tracing) and applies the fix to dma-heap. Patch 2 applies the same fix to fastrpc, which even had a comment acknowledging the problem could not be fixed before. v1: https://lore.kernel.org/dri-devel/20260703080922.1838362-1-shoubaineng@gmai… v2: https://lore.kernel.org/dri-devel/20260710105430.3059661-1-shoubaineng@gmai… Changes in v3: - Split into two patches (dma-heap + fastrpc separately) - Add dma_buf_fd_install() to preserve trace_dma_buf_fd tracepoint (spotted by T.J. Mercier and sashiko-bot on v2) - Add fastrpc fix using the new helper (suggested by T.J. Mercier) Baineng Shou (2): dma-buf: dma-heap: don't publish fd before copy_to_user() succeeds misc: fastrpc: don't publish fd before copy_to_user() succeeds drivers/dma-buf/dma-buf.c | 20 ++++++++++ drivers/dma-buf/dma-heap.c | 80 +++++++++++++++++++------------------- drivers/misc/fastrpc.c | 16 +++----- include/linux/dma-buf.h | 1 + 4 files changed, 67 insertions(+), 50 deletions(-) -- 2.34.1

5 days, 15 hours

[PATCH v5 0/5] rust / dma_buf: Add abstractions for dma_fence

by Philipp Stanner

Changes since v4: - Fix an uninitialized memory bug for FenceCbRegistration with ManuallyDrop. - Return FenceCtx as impl PinInit - Make FenceCtx return an impl PinInit<T, Error> (Danilo) - Reformat some comments - Adjust the docu for rcu_barrier(), so that it matches the C side's docu and our docu for rcu::synchronize_rcu(). Changes since v3: - Add a FIXME for an encountered Rust compiler bug. (Gary) - Add new Rust files also to DRM drivers & common infrastructure MAINTAINERS file. (Danilo) - Reposition ECANCELED error code. (Miguel) - Replace refcounted FenceCtx in DriverFenceData with a reference plus life time. (Boris) - Re-add rcu_barrier() patch, since we now can use it for dropping the fence context. (Danilo) - Add forgotten R-b from Alice, and Acks for MAINTAINERS from Christian and Sumit. Changes since v2: - Don't drop DriverFenceData as a whole, but only the members we really want to drop. Gives more robustness. (Gary). - Break apart large pin_init_from_closure(). (Danilo, Onur) - Remove rcu_barrier() and synchronize_rcu() from FenceCtx::drop(). FenceCtx might drop in atomic context, where you must not perform those operations. With the current way C dma_fence is designed, the driver must wait for a grace period manually until it unloads. - Repair the DriverFenceBorrow implementation, properly injecting a life time into it. (Danilo) - Fix memory layout bug for rcu_head. (Onur) - Drop RCU patches, since this series doesn't need them anymore. Changes since v1: - Remove unnecessary mutable references (Alice) - Split up unsafe comments where possible (Danilo) - Remove PhantomData + implement FenceCtx ops trait (Boris) - Consistently call FenceCtx generic data `T`. FenceDataType is derived from that. (Boris) - Add abstractions for call_rcu() and synchronize_rcu() (Danilo) - Add ECANCELED error code in Rust (Alice) - Remove the rcu_barrier() from FenceCtx::drop() – because we now use call_rcu(), there can be no UAF access to the FenceCtx anymore. In any case, it is illegal to use either call_rcu() or synchronize_rcu() in FenceCtx::drop(), because our new drop_driver_fence_data() can run in atomic context and might put the last fence_ctx reference. So we now only have to guard against module unload, which it seems either the driver or Rust driver-core / module unload infrastructure must solve. - Minor formatting etc. changes - Add C helpers to MAINTAINERS. (Danilo) - Ensure that `Fence::is_signaled()` is fully synchronized, i.e., all callbacks really have run. See [1] and [2]. (Myself, Christian König) Changes since the RFCs: - Include support for ForeignOwnable for ARef, so that a Fence can be stuffed into an XArray et al. (Code by Danilo) - Implement ForeignOwnable (with new borrow type) for DriverFence, so that it can be stuffed into an XArray. - Include the rcu::RcuBox data type to defer dropping data with RCU (Cody by Alice) - Port DmaFence to RcuBox to make UAF bugs through later, new dma_fence callbacks (backend_ops) impossible. - Force users to pass their fence data in an RcuBox (or have it not need drop()) through a Sealed trait. - Document the rules for the user's DriverFence::data's drop implementation very clearly (deadlock danger). - rustfmt, Clippy. - Various style suggestions, safety comments, etc. (Önur) - Add __rust_helper prefix to helper functions. (Önur) Changes in RFC v3: - Omit JobQueue patches for now - Completely redesign the memory layout: Instead of a Fence refcounting a DriverFence, both now live in the same allocation to allow for future support the dma_fence backend_ops callbacks which need to do container_of. (mostly Boris's feedback) - Allow for pre-allocating fences to avoid deadlocks when submitting jobs to a GPU. (Boris) - Simultaneously, allow for pre-preparing fence callback objects, so the driver can allocate them when it sees fit. (code largely stolen and inspired by Daniel). - Signal fences on drop, ensure synchronization. - Force users to set an error code when signalling. - Write more documentation - A ton of minor other changes. [1] https://lore.kernel.org/dri-devel/20260608142436.265820-2-phasta@kernel.org/ [2] https://lore.kernel.org/dri-devel/20260612104251.2264707-2-phasta@kernel.or… Alright, so since the last RFCs did not reveal significant design issues, I decided to transition this series to a v1 and hope that we can get it upstream. This now includes code for more common infrastructure that dma_fence needs, contributed by Danilo and Alice. --- Old cover letter for RFC: So, this is the spiritual successor of the first / second RFC [1]. v2 also contained code for drm::JobQueue, but mostly to show how the fence code would be used. JobQueue is under heavy rework right now, so I don't want to bother your eyes with it. The docstring examples should show how Rust fences are supposed to be used, though. This v3 contains a huge amount of highly valuable feedback from a variety of people, notably Boris, but also from Alice, Gary and Danilo. There are some TODOs open (a better trait for fence backend_ops and RCU support), but my hope is that this effort is now finally approaching its end. I would greatly appreciate feedback and especially more information about what might be missing to make this usable, which is obviously where Daniel's and Boris's feedback will be valuable once more. Please regard this patch just as what it's titled: an RFC, to discuss a bit more and to inform a broader community about what the current state is and where this is heading at. Many regards, Philipp [1] https://lore.kernel.org/rust-for-linux/20260203081403.68733-2-phasta@kernel… Danilo Krummrich (1): rust: types: implement ForeignOwnable for ARef<T> Philipp Stanner (4): rust: error: Add ECANCELED error code rust: sync: Add abstraction for rcu_barrier() rust: Add dma_fence abstractions MAINTAINERS: Add entry for Rust dma-buf MAINTAINERS | 5 + rust/bindings/bindings_helper.h | 1 + rust/helpers/dma_fence.c | 48 ++ rust/helpers/helpers.c | 1 + rust/kernel/dma_buf/dma_fence.rs | 894 +++++++++++++++++++++++++++++++ rust/kernel/dma_buf/mod.rs | 14 + rust/kernel/error.rs | 1 + rust/kernel/lib.rs | 1 + rust/kernel/sync/aref.rs | 40 ++ rust/kernel/sync/rcu.rs | 20 + 10 files changed, 1025 insertions(+) create mode 100644 rust/helpers/dma_fence.c create mode 100644 rust/kernel/dma_buf/dma_fence.rs create mode 100644 rust/kernel/dma_buf/mod.rs base-commit: a73a398a68ca9b9e5116a617562471f16b8310c4 -- 2.54.0

5 days, 16 hours

[PATCH V5] i2c: qcom-geni: Add dynamic transfer timeout based on transfer length and frequency

by Aniket Randive

The driver uses a static XFER_TIMEOUT of HZ (1 second) for all transfers regardless of message length or bus frequency, causing unnecessary delays on error paths. Compute the timeout dynamically from message length and bus frequency with a 10x safety margin over the theoretical wire time. Add a 300 ms floor to account for I2C clock stretching and other situations where a slave may keep SCL asserted for an extended period, including faulty devices holding the bus. This replaces the fixed 1-second timeout with a transfer-specific timeout while preserving sufficient margin for software overheads and bus-level delays. For GPI multi-descriptor transfers, use the maximum message length across all queued messages as the per-completion timeout. Signed-off-by: Aniket Randive <aniket.randive(a)oss.qualcomm.com> --- Changes in V5: - Updated the commit message as per the review comments. Changes in V4: - As per konrad suggestion used mult_frac() for bit_usec to avoid intermediate overflow on 32-bit targets. - Updated the commit message and added a driver comment explaining the rationale for the 0.3-second minimum timeout floor value. drivers/i2c/busses/i2c-qcom-geni.c | 47 +++++++++++++++++++++++------- 1 file changed, 37 insertions(+), 10 deletions(-) diff --git a/drivers/i2c/busses/i2c-qcom-geni.c b/drivers/i2c/busses/i2c-qcom-geni.c index 96dbf04138be..f011d2564cd2 100644 --- a/drivers/i2c/busses/i2c-qcom-geni.c +++ b/drivers/i2c/busses/i2c-qcom-geni.c @@ -74,9 +74,14 @@ enum geni_i2c_err_code { #define PACKING_BYTES_PW 4 #define ABORT_TIMEOUT HZ -#define XFER_TIMEOUT HZ #define RST_TIMEOUT HZ +/* 9 bits per byte (8 data + 1 ACK), 10x safety margin */ +#define I2C_TIMEOUT_SAFETY_COEFFICIENT 10 + +/* 300ms floor: budget for clock stretching; slave may hold SCL low indefinitely */ +#define I2C_TIMEOUT_MIN_USEC 300000 + struct geni_i2c_desc { bool no_dma_support; unsigned int tx_fifo_depth; @@ -204,6 +209,16 @@ static int geni_i2c_clk_map_idx(struct geni_i2c_dev *gi2c) return -EINVAL; } +static unsigned long geni_i2c_xfer_timeout(struct geni_i2c_dev *gi2c, size_t len) +{ + size_t bit_cnt = len * 9; + size_t bit_usec = mult_frac(bit_cnt, USEC_PER_SEC, gi2c->clk_freq_out); + size_t xfer_max_usec = (bit_usec * I2C_TIMEOUT_SAFETY_COEFFICIENT) + + I2C_TIMEOUT_MIN_USEC; + + return usecs_to_jiffies(xfer_max_usec); +} + static int qcom_geni_i2c_conf(struct geni_se *se, unsigned long freq) { struct geni_i2c_dev *gi2c = dev_get_drvdata(se->dev); @@ -445,7 +460,7 @@ static int geni_i2c_rx_one_msg(struct geni_i2c_dev *gi2c, struct i2c_msg *msg, u32 m_param) { dma_addr_t rx_dma = 0; - unsigned long time_left; + unsigned long time_left, timeout; void *dma_buf; struct geni_se *se = &gi2c->se; size_t len = msg->len; @@ -470,8 +485,9 @@ static int geni_i2c_rx_one_msg(struct geni_i2c_dev *gi2c, struct i2c_msg *msg, gi2c->dma_buf = dma_buf; } + timeout = geni_i2c_xfer_timeout(gi2c, len); cur = gi2c->cur; - time_left = wait_for_completion_timeout(&gi2c->done, XFER_TIMEOUT); + time_left = wait_for_completion_timeout(&gi2c->done, timeout); if (!time_left) geni_i2c_abort_xfer(gi2c); @@ -484,7 +500,7 @@ static int geni_i2c_tx_one_msg(struct geni_i2c_dev *gi2c, struct i2c_msg *msg, u32 m_param) { dma_addr_t tx_dma = 0; - unsigned long time_left; + unsigned long time_left, timeout; void *dma_buf; struct geni_se *se = &gi2c->se; size_t len = msg->len; @@ -512,8 +528,9 @@ static int geni_i2c_tx_one_msg(struct geni_i2c_dev *gi2c, struct i2c_msg *msg, if (!dma_buf) /* Get FIFO IRQ */ writel_relaxed(1, se->base + SE_GENI_TX_WATERMARK_REG); + timeout = geni_i2c_xfer_timeout(gi2c, len); cur = gi2c->cur; - time_left = wait_for_completion_timeout(&gi2c->done, XFER_TIMEOUT); + time_left = wait_for_completion_timeout(&gi2c->done, timeout); if (!time_left) geni_i2c_abort_xfer(gi2c); @@ -591,7 +608,7 @@ static void geni_i2c_gpi_multi_desc_unmap(struct geni_i2c_dev *gi2c, struct i2c_ * geni_i2c_gpi_multi_xfer_timeout_handler() - Handles multi message transfer timeout * @dev: Pointer to the corresponding dev node * @multi_xfer: Pointer to the geni_i2c_gpi_multi_desc_xfer - * @transfer_timeout_msecs: Timeout value in milliseconds + * @transfer_timeout_msecs: Per-message completion timeout in jiffies * @transfer_comp: Completion object of the transfer * * This function waits for the completion of each processed transfer messages @@ -601,7 +618,7 @@ static void geni_i2c_gpi_multi_desc_unmap(struct geni_i2c_dev *gi2c, struct i2c_ */ static int geni_i2c_gpi_multi_xfer_timeout_handler(struct device *dev, struct geni_i2c_gpi_multi_desc_xfer *multi_xfer, - u32 transfer_timeout_msecs, + unsigned long timeout_jiffies, struct completion *transfer_comp) { int i; @@ -612,7 +629,7 @@ static int geni_i2c_gpi_multi_xfer_timeout_handler(struct device *dev, if (multi_xfer->msg_idx_cnt != multi_xfer->irq_cnt) { time_left = wait_for_completion_timeout(transfer_comp, - transfer_timeout_msecs); + timeout_jiffies); if (!time_left) { dev_err(dev, "%s: Transfer timeout\n", __func__); return -ETIMEDOUT; @@ -736,8 +753,16 @@ static int geni_i2c_gpi(struct geni_i2c_dev *gi2c, struct i2c_msg msgs[], dma_async_issue_pending(gi2c->tx_c); if ((msg_idx == (gi2c->num_msgs - 1)) || flags & DMA_PREP_INTERRUPT) { + unsigned long timeout; + size_t max_len = 0; + int j; + + for (j = 0; j < gi2c->num_msgs; j++) + max_len = max_t(size_t, max_len, msgs[j].len); + + timeout = geni_i2c_xfer_timeout(gi2c, max_len); ret = geni_i2c_gpi_multi_xfer_timeout_handler(gi2c->se.dev, gi2c_gpi_xfer, - XFER_TIMEOUT, &gi2c->done); + timeout, &gi2c->done); if (ret) { dev_err(gi2c->se.dev, "I2C multi write msg transfer timeout: %d\n", @@ -851,8 +876,10 @@ static int geni_i2c_gpi_xfer(struct geni_i2c_dev *gi2c, struct i2c_msg msgs[], i } if (!gi2c->is_tx_multi_desc_xfer) { + unsigned long timeout = geni_i2c_xfer_timeout(gi2c, msgs[i].len); + dma_async_issue_pending(gi2c->tx_c); - time_left = wait_for_completion_timeout(&gi2c->done, XFER_TIMEOUT); + time_left = wait_for_completion_timeout(&gi2c->done, timeout); if (!time_left) { dev_err(gi2c->se.dev, "%s:I2C timeout\n", __func__); gi2c->err = -ETIMEDOUT; -- 2.34.1

5 days, 18 hours

[PATCH v3 00/11] dma-buf: heaps: Add support for Tegra VPR

by Thierry Reding

This series adds support for the video protection region (VPR) used on Tegra SoC devices. It's a special region of memory that is protected from accesses by the CPU and used to store DRM protected content (both decrypted stream data as well as decoded video frames). Patches 1 through 3 add DT binding documentation for the VPR and add the VPR to the list of memory-region items for display, host1x and NVDEC. New set_memory_device() and set_memory_normal() helpers are defined in patch 4 and will subsequently be used to set the memory type of the VPR to make sure it won't be accessed by the CPU once it's made part of the protected region. Patch 5 adds bitmap_allocate(), which is like bitmap_allocate_region() but works on sizes that are not a power of two. Patch 6 introduces new APIs needed by the Tegra VPR implementation that allow CMA areas to be dynamically created at runtime rather than using the fixed, system-wide list. This is used in this driver specifically because it can use an arbitrary number of these areas (though they are currently limited to 4). Patch 7 adds some infrastructure for DMA heap implementations to provide information through debugfs. The Tegra VPR implementation is added in patch 8. See its commit message for more details about the specifics of this implementation. Finally, patches 9-11 add the VPR placeholder node on Tegra234 and Tegra264 and hook it up to the host1x node so that it can make use of this region. Changes in v3: - Link to v2: https://patch.msgid.link/20260122161009.3865888-1-thierry.reding@kernel.org - introduce set_memory_device() and set_memory_normal() - rename VPR nodes to "protected" - add Tegra264 placeholder nodes Changes in v2: - Link to v1: https://patch.msgid.link/20250902154630.4032984-1-thierry.reding@gmail.com - Tegra VPR implementation is now more optimized to reduce the number of (very slow) resize operations, and allows cross-chunk allocations - dynamic CMA areas are now trackd separately from static ones, but the global number of CMA pages accounts for all areas Thierry Signed-off-by: Thierry Reding <treding(a)nvidia.com> --- Chun Ng (1): arm64/mm: Add set_memory_device() and set_memory_normal() Thierry Reding (10): dt-bindings: reserved-memory: Document Tegra VPR dt-bindings: display: tegra: Document memory regions dt-bindings: gpu: host1x: Document memory-regions for NVDEC bitmap: Add bitmap_allocate() function mm/cma: Allow dynamically creating CMA areas dma-buf: heaps: Add debugfs support dma-buf: heaps: Add support for Tegra VPR arm64: tegra: Add VPR placeholder node on Tegra234 arm64: tegra: Hook up VPR to host1x arm64: tegra: Add VPR placeholder node on Tegra264 .../display/tegra/nvidia,tegra124-vic.yaml | 8 + .../bindings/display/tegra/nvidia,tegra186-dc.yaml | 10 + .../bindings/display/tegra/nvidia,tegra20-dc.yaml | 10 +- .../display/tegra/nvidia,tegra20-host1x.yaml | 7 + .../bindings/gpu/host1x/nvidia,tegra234-nvdec.yaml | 8 + .../nvidia,tegra-video-protection-region.yaml | 76 ++ arch/arm/mm/dma-mapping.c | 2 +- arch/arm64/boot/dts/nvidia/tegra234.dtsi | 45 + arch/arm64/boot/dts/nvidia/tegra264.dtsi | 33 + arch/arm64/include/asm/set_memory.h | 2 + arch/arm64/mm/pageattr.c | 16 + arch/s390/mm/init.c | 2 +- drivers/dma-buf/dma-heap.c | 56 + drivers/dma-buf/heaps/Kconfig | 7 + drivers/dma-buf/heaps/Makefile | 1 + drivers/dma-buf/heaps/tegra-vpr.c | 1242 ++++++++++++++++++++ include/linux/bitmap.h | 25 +- include/linux/cma.h | 8 +- include/linux/dma-heap.h | 2 + include/linux/set_memory.h | 11 + include/trace/events/tegra_vpr.h | 57 + kernel/dma/contiguous.c | 2 +- mm/cma.c | 187 ++- mm/cma.h | 5 +- 24 files changed, 1775 insertions(+), 47 deletions(-) --- base-commit: 703daa6d046136affd69f2a2e08f36ac4a7d5b2c change-id: 20260507-tegra-vpr-cd4bc2509c4c Best regards, -- Thierry Reding <treding(a)nvidia.com>

5 days, 20 hours

(no subject)

by None

From Dmitry.Guzman(a)mobileye.com Wed Jul 15 14:45:58 2026 Date: Wed, 15 Jul 2026 14:45:58 +0300 From: Dmitry Guzman <Dmitry.Guzman(a)mobileye.com> To: Aniket Randive <aniket.randive(a)oss.qualcomm.com> Cc: mukesh.savaliya(a)oss.qualcomm.com, viken.dadhaniya(a)oss.qualcomm.com, andi.shyti(a)kernel.org, sumit.semwal(a)linaro.org, christian.koenig(a)amd.com, linux-i2c(a)vger.kernel.org, linux-arm-msm(a)vger.kernel.org, linux-kernel(a)vger.kernel.org, linux-media(a)vger.kernel.org, dri-devel(a)lists.freedesktop.org, linaro-mm-sig(a)lists.linaro.org, naresh.maramaina(a)oss.qualcomm.com Subject: Re: [PATCH V5] i2c: qcom-geni: Add dynamic transfer timeout based on transfer length and frequency Message-Id: <20260715144558.abf5078829bfd2a0973019a9(a)mobileye.com> In-Reply-To: <20260715101805.3615166-1-aniket.randive(a)oss.qualcomm.com> References: <20260715101805.3615166-1-aniket.randive(a)oss.qualcomm.com> Organization: MobilEye X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Sylpheed-Account-Id: 1 X-Sylpheed-Reply: #mh/Mailbox/inbox/15 X-Sylpheed-Compose-AutoWrap: FALSE X-Sylpheed-Compose-CheckSpell: FALSE X-Sylpheed-Compose-SpellLang: en X-Sylpheed-Compose-UseSigning: FALSE X-Sylpheed-Compose-UseEncryption: FALSE On Wed, 15 Jul 2026 15:48:05 +0530 Aniket Randive <aniket.randive(a)oss.qualcomm.com> wrote: > This replaces the fixed 1-second timeout with a transfer-specific > timeout while preserving sufficient margin for software overheads and > bus-level delays. > The dynamic timeout may be useful for any I2C bus controller, not only for qcom-geni. Structure i2c_adapter already has field "timeout". Isn't it worth to move the timeout calculation to i2c-core, so that the core updates the timeout field in i2c_adapter structure, and the controller driver just uses this value, instead of duplicating the calculation in every driver that will use this feature? Also, such parameters as I2C_TIMEOUT_SAFETY_COEFFICIENT and I2C_TIMEOUT_MIN_USEC may be configurable by user (for example, in device tree) for more flexibility. Best regards, -- Dmitry Guzman <Dmitry.Guzman(a)mobileye.com>

6 days

[PATCH V4] i2c: qcom-geni: Add dynamic transfer timeout based on transfer length and frequency

by Aniket Randive

The driver uses a static XFER_TIMEOUT of HZ (1 second) for all transfers regardless of message length or bus frequency, causing unnecessary delays on error paths. Compute the timeout dynamically from message length and bus frequency with a 10x safety margin over the theoretical wire time. Add a 300ms floor to budget for I2C clock stretching, where a slave may hold SCL low indefinitely during internal processing. This detects real hangs 3x faster than the old 1s static timeout. For GPI multi-descriptor transfers, use the maximum message length across all queued messages as the per-completion timeout. Signed-off-by: Aniket Randive <aniket.randive(a)oss.qualcomm.com> --- Changes in v4: - As per konrad suggestion used mult_frac() for bit_usec to avoid intermediate overflow on 32-bit targets. - Updated the commit message and added a driver comment explaining the rationale for the 0.3-second minimum timeout floor value. drivers/i2c/busses/i2c-qcom-geni.c | 46 +++++++++++++++++++++++------- 1 file changed, 36 insertions(+), 10 deletions(-) diff --git a/drivers/i2c/busses/i2c-qcom-geni.c b/drivers/i2c/busses/i2c-qcom-geni.c index 96dbf04138be..c5c3adc8ec77 100644 --- a/drivers/i2c/busses/i2c-qcom-geni.c +++ b/drivers/i2c/busses/i2c-qcom-geni.c @@ -74,9 +74,13 @@ enum geni_i2c_err_code { #define PACKING_BYTES_PW 4 #define ABORT_TIMEOUT HZ -#define XFER_TIMEOUT HZ #define RST_TIMEOUT HZ +/* 9 bits per byte (8 data + 1 ACK), 10x safety margin */ +#define I2C_TIMEOUT_SAFETY_COEFFICIENT 10 +/* 300ms floor: budget for clock stretching; slave may hold SCL low indefinitely */ +#define I2C_TIMEOUT_MIN_USEC 300000 + struct geni_i2c_desc { bool no_dma_support; unsigned int tx_fifo_depth; @@ -204,6 +208,16 @@ static int geni_i2c_clk_map_idx(struct geni_i2c_dev *gi2c) return -EINVAL; } +static unsigned long geni_i2c_xfer_timeout(struct geni_i2c_dev *gi2c, size_t len) +{ + size_t bit_cnt = len * 9; + size_t bit_usec = mult_frac(bit_cnt, USEC_PER_SEC, gi2c->clk_freq_out); + size_t xfer_max_usec = (bit_usec * I2C_TIMEOUT_SAFETY_COEFFICIENT) + + I2C_TIMEOUT_MIN_USEC; + + return usecs_to_jiffies(xfer_max_usec); +} + static int qcom_geni_i2c_conf(struct geni_se *se, unsigned long freq) { struct geni_i2c_dev *gi2c = dev_get_drvdata(se->dev); @@ -445,7 +459,7 @@ static int geni_i2c_rx_one_msg(struct geni_i2c_dev *gi2c, struct i2c_msg *msg, u32 m_param) { dma_addr_t rx_dma = 0; - unsigned long time_left; + unsigned long time_left, timeout; void *dma_buf; struct geni_se *se = &gi2c->se; size_t len = msg->len; @@ -470,8 +484,9 @@ static int geni_i2c_rx_one_msg(struct geni_i2c_dev *gi2c, struct i2c_msg *msg, gi2c->dma_buf = dma_buf; } + timeout = geni_i2c_xfer_timeout(gi2c, len); cur = gi2c->cur; - time_left = wait_for_completion_timeout(&gi2c->done, XFER_TIMEOUT); + time_left = wait_for_completion_timeout(&gi2c->done, timeout); if (!time_left) geni_i2c_abort_xfer(gi2c); @@ -484,7 +499,7 @@ static int geni_i2c_tx_one_msg(struct geni_i2c_dev *gi2c, struct i2c_msg *msg, u32 m_param) { dma_addr_t tx_dma = 0; - unsigned long time_left; + unsigned long time_left, timeout; void *dma_buf; struct geni_se *se = &gi2c->se; size_t len = msg->len; @@ -512,8 +527,9 @@ static int geni_i2c_tx_one_msg(struct geni_i2c_dev *gi2c, struct i2c_msg *msg, if (!dma_buf) /* Get FIFO IRQ */ writel_relaxed(1, se->base + SE_GENI_TX_WATERMARK_REG); + timeout = geni_i2c_xfer_timeout(gi2c, len); cur = gi2c->cur; - time_left = wait_for_completion_timeout(&gi2c->done, XFER_TIMEOUT); + time_left = wait_for_completion_timeout(&gi2c->done, timeout); if (!time_left) geni_i2c_abort_xfer(gi2c); @@ -591,7 +607,7 @@ static void geni_i2c_gpi_multi_desc_unmap(struct geni_i2c_dev *gi2c, struct i2c_ * geni_i2c_gpi_multi_xfer_timeout_handler() - Handles multi message transfer timeout * @dev: Pointer to the corresponding dev node * @multi_xfer: Pointer to the geni_i2c_gpi_multi_desc_xfer - * @transfer_timeout_msecs: Timeout value in milliseconds + * @transfer_timeout_msecs: Per-message completion timeout in jiffies * @transfer_comp: Completion object of the transfer * * This function waits for the completion of each processed transfer messages @@ -601,7 +617,7 @@ static void geni_i2c_gpi_multi_desc_unmap(struct geni_i2c_dev *gi2c, struct i2c_ */ static int geni_i2c_gpi_multi_xfer_timeout_handler(struct device *dev, struct geni_i2c_gpi_multi_desc_xfer *multi_xfer, - u32 transfer_timeout_msecs, + unsigned long timeout_jiffies, struct completion *transfer_comp) { int i; @@ -612,7 +628,7 @@ static int geni_i2c_gpi_multi_xfer_timeout_handler(struct device *dev, if (multi_xfer->msg_idx_cnt != multi_xfer->irq_cnt) { time_left = wait_for_completion_timeout(transfer_comp, - transfer_timeout_msecs); + timeout_jiffies); if (!time_left) { dev_err(dev, "%s: Transfer timeout\n", __func__); return -ETIMEDOUT; @@ -736,8 +752,16 @@ static int geni_i2c_gpi(struct geni_i2c_dev *gi2c, struct i2c_msg msgs[], dma_async_issue_pending(gi2c->tx_c); if ((msg_idx == (gi2c->num_msgs - 1)) || flags & DMA_PREP_INTERRUPT) { + unsigned long timeout; + size_t max_len = 0; + int j; + + for (j = 0; j < gi2c->num_msgs; j++) + max_len = max_t(size_t, max_len, msgs[j].len); + + timeout = geni_i2c_xfer_timeout(gi2c, max_len); ret = geni_i2c_gpi_multi_xfer_timeout_handler(gi2c->se.dev, gi2c_gpi_xfer, - XFER_TIMEOUT, &gi2c->done); + timeout, &gi2c->done); if (ret) { dev_err(gi2c->se.dev, "I2C multi write msg transfer timeout: %d\n", @@ -851,8 +875,10 @@ static int geni_i2c_gpi_xfer(struct geni_i2c_dev *gi2c, struct i2c_msg msgs[], i } if (!gi2c->is_tx_multi_desc_xfer) { + unsigned long timeout = geni_i2c_xfer_timeout(gi2c, msgs[i].len); + dma_async_issue_pending(gi2c->tx_c); - time_left = wait_for_completion_timeout(&gi2c->done, XFER_TIMEOUT); + time_left = wait_for_completion_timeout(&gi2c->done, timeout); if (!time_left) { dev_err(gi2c->se.dev, "%s:I2C timeout\n", __func__); gi2c->err = -ETIMEDOUT; -- 2.34.1

6 days, 2 hours

Slope: The Visual Aesthetic of the Neon World

by farahfionaa＠gmail.com

Slope features a very distinct neon visual style. The bright colors contrast against the dark background perfectly. This makes the path clear even when you are moving at high speeds. The aesthetic is clean and modern. It avoids unnecessary clutter that might distract you during the game. This focus on visuals helps you stay locked into the core gameplay loop. The environment feels empty yet threatening. The void below the track creates a sense of danger. You are always one wrong tilt away from falling. This creates a high-stakes atmosphere that keeps you engaged. The simplicity of the graphics is a strength. It allows the game to run smoothly on almost any device without any lag or performance issues at all. https://slope-play.com You might find the visuals hypnotic after a while. The glowing lines and moving platforms can create a flow state. This is when the game becomes truly special. You move by instinct rather than conscious thought. You react before you even see the obstacle clearly. This level of immersion is why so many players spend hours trying to beat their records.

6 days, 2 hours

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig July 2026