Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

40 participants
8085 discussions

[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

3 weeks, 4 days

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.

3 weeks, 4 days

Why Heardle Is the Ultimate Music Puzzle Game for Casual and Hardcore Fans

by felixandreaim＠gmail.com

Heardle has quickly become one of the most talked-about music puzzle games online. Designed for players of all skill levels, heardle invites you to guess songs from short audio clips while enjoying a relaxed yet competitive experience. https://heardleonline.io/ Gameplay Overview The mechanics are straightforward but clever. You begin with a brief audio clip—usually just one second long. If you can’t identify the song, you can skip or guess incorrectly to unlock longer snippets. You have a maximum of six attempts to get it right. A Unique Twist on Wordle Unlike Wordle’s text-based gameplay, Heardle focuses entirely on sound. There are no color-coded hints or letter placements—only your listening skills. This makes it both simpler and more immersive. Explore Variants and Modes One of Heardle’s strengths is its variety. Players can explore: Decade-based editions (80s, 90s, 2000s, etc.) Genre-focused versions like rock, pop, or K-pop Unlimited modes for extended gameplay Why You Should Play Heardle Heardle isn’t just a game—it’s an experience. It challenges your memory, sharpens your listening skills, and introduces you to new music. Whether you’re playing solo or sharing results with friends, it’s a great way to connect through music. If you’re searching for a fun, engaging, and easy-to-learn music guessing game, Heardle is the perfect choice. Give it a try and see how many songs you can recognize.

3 weeks, 4 days

Hole IO: You Only Have 2 Minutes to Become a Champion!

by holeonline.io＠gmail.com

https://holeonline.io If you're looking for a game that's simple, easy to play, yet still offers a thrilling competitive experience, then Hole IO is definitely a must-try. The most appealing aspect of the game is that each match lasts only 2 minutes, forcing players to utilize every second to grow their black hole as quickly as possible. At the start, you're just a tiny hole, only able to swallow small objects like lampposts, signs, or bushes. However, the more objects you swallow, the larger your hole becomes, opening up the possibility of "eating" cars, houses, skyscrapers, and even other opponents on the map. This continuous growth mechanism creates an extremely satisfying feeling and makes players want to try another match to achieve a higher score. Within that short 120-second timeframe, you must plan your moves strategically, prioritizing areas with many small objects to increase your size quickly before moving on to larger targets. At the same time, you also need to pay attention to your opponents' positions because if they are bigger, you can become "meal" at any time. Conversely, when you are strong enough, hunting down and devouring other players will help you significantly increase your score and climb to the top of the leaderboard. The fast pace, intuitive gameplay, and unexpected twists make each Hole IO match a different experience. Just one right decision in the last few seconds can completely overtake all your opponents to win the championship. With colorful graphics, simple controls, and high entertainment value, Hole IO is suitable for all ages, from those who just want to have a few minutes of fun to gamers who like to compete for high scores. So, if you believe in your reflexes, strategy, and speed, step into the Hole IO arena and prove that in just 2 minutes, you can still become a champion.

3 weeks, 4 days

Snow Rider 3D: Reflex Challenge on the Snow

by williamsdanielusa＠outlook.com

https://snowrideronline.io Snow Rider 3D is an engaging and entertaining game where players control a snowmobile traversing snow-covered paths. The gameplay is simple but requires quick reflexes to dodge trees, rocks, snowmen, and many other obstacles that appear constantly. The increasing speed makes each level more dramatic, providing a thrilling and challenging experience for players. Not only does it boast beautiful 3D graphics with vibrant winter scenery, Snow Rider 3D also offers an enjoyable entertainment experience for all ages. Players can collect rewards to unlock unique snowmobile models, adding motivation to conquer longer distances. With easy-to-learn controls but challenging high scores, the game is a great choice for training reflexes, concentration, and enjoying relaxing moments after school or work.

3 weeks, 4 days

Snow Rider 3D: Reflex Challenge on the Snow

by williamsdanielusa＠outlook.com

<a href="https://snowrideronline.io">Snow Rider 3D</a> is an engaging and entertaining game where players control a snowmobile traversing snow-covered paths. The gameplay is simple but requires quick reflexes to dodge trees, rocks, snowmen, and many other obstacles that appear constantly. The increasing speed makes each level more dramatic, providing a thrilling and challenging experience for players. Not only does it boast beautiful 3D graphics with vibrant winter scenery, Snow Rider 3D also offers an enjoyable entertainment experience for all ages. Players can collect rewards to unlock unique snowmobile models, adding motivation to conquer longer distances. With easy-to-learn controls but challenging high scores, the game is a great choice for training reflexes, concentration, and enjoying relaxing moments after school or work.

3 weeks, 4 days

[PATCH v3 00/10] Add dmabuf read/write via io_uring

by Pavel Begunkov

The patch set allows to register a dmabuf to an io_uring instance for a specified file and use it with io_uring read / write requests. The infrastructure is not tied to io_uring and there could be more users in the future. A similar idea was attempted some years ago by Keith [1], from where I borrowed a good number of changes, and later was brough up by Tushar and Vishal from Intel. It's an opt-in feature for files, and they need to implement a new file operation to use it. Only NVMe block devices are supported in this series. The user API is built on top of io_uring's "registered buffers", where a dmabuf is registered in a special way, but after it can be used as any other "registered buffer" with IORING_OP_{READ,WRITE}_FIXED requests. It's created via a new file operation and the resulted map is then passed through the I/O stack in a new iterator type. There is some additional infrastructure to bind it all, which also counts requests using a dmabuf map and managing lifetimes, which is used to implement map invalidation. It was tested for GPU <-> NVMe transfers. Also, as it maintains a long-term dma mapping, it helps with the IOMMU cost. The numbers below are for udmabuf reads previously run by Anuj for different IOMMU modes: - STRICT: before = 570 KIOPS, after = 5.01 MIOPS - LAZY: before = 1.93 MIOPS, after = 5.01 MIOPS - PASSTHROUGH: before = 5.01 MIOPS, after = 5.01 MIOPS There are some liburing tests that can serve as an example: git: https://github.com/isilence/liburing.git rw-dmabuf-tests-v3 url: https://github.com/isilence/liburing/tree/rw-dmabuf-tests-v3 [1] https://lore.kernel.org/io-uring/20220805162444.3985535-1-kbusch@fb.com/ v3: - Rework io_uring registration - Move token/map infrastructure code out of blk-mq - Simplify callbacks: remove a separate blk-mq table, which was mostly just forwarding calls (to nvme). - Don't skip dma sync depending on request direction - Fix a couple of hangs - Rename s/dma/dmabuf/ - Other small changes v2: - Don't pass raw dma addresses, wrap it into a driver specific object - Split into two objects: token and map - Implement move_notify Pavel Begunkov (10): file: add callback for creating long-term dmabuf maps iov_iter: add iterator type for dmabuf maps block: move bvec init into __bio_clone block: introduce dma map backed bio type lib: add dmabuf token infrastructure block: forward create_dmabuf_token to drivers nvme-pci: implement dma_token backed requests io_uring/rsrc: introduce buf registration structure io_uring/rsrc: extend buffer update io_uring/rsrc: add dmabuf backed registered buffers block/bio.c | 28 +++- block/blk-merge.c | 14 ++ block/blk.h | 3 +- block/fops.c | 16 ++ drivers/nvme/host/pci.c | 282 ++++++++++++++++++++++++++++++++ include/linux/bio.h | 19 ++- include/linux/blk-mq.h | 9 + include/linux/blk_types.h | 8 +- include/linux/fs.h | 2 + include/linux/io_dmabuf_token.h | 92 +++++++++++ include/linux/io_uring_types.h | 5 + include/linux/uio.h | 11 ++ include/uapi/linux/io_uring.h | 31 +++- io_uring/io_uring.c | 3 +- io_uring/rsrc.c | 266 +++++++++++++++++++++++++----- io_uring/rsrc.h | 30 +++- io_uring/rw.c | 4 +- lib/Kconfig | 4 + lib/Makefile | 2 + lib/io_dmabuf_token.c | 272 ++++++++++++++++++++++++++++++ lib/iov_iter.c | 29 +++- 21 files changed, 1071 insertions(+), 59 deletions(-) create mode 100644 include/linux/io_dmabuf_token.h create mode 100644 lib/io_dmabuf_token.c -- 2.53.0

3 weeks, 5 days

Independence for dma_fences! v6

by Christian König

Hi everyone, dma_fences have ever lived under the tyranny dictated by the module lifetime of their issuer, leading to crashes should anybody still holding a reference to a dma_fence when the module of the issuer was unloaded. The basic problem is that when buffer are shared between drivers dma_fence objects can leak into external drivers and stay there even after they are signaled. The dma_resv object for example only lazy releases dma_fences. So what happens is that when the module who originally created the dma_fence unloads the dma_fence_ops function table becomes unavailable as well and so any attempt to release the fence crashes the system. Previously various approaches have been discussed, including changing the locking semantics of the dma_fence callbacks (by me) as well as using the drm scheduler as intermediate layer (by Sima) to disconnect dma_fences from their actual users, but none of them are actually solving all problems. Tvrtko did some really nice prerequisite work by protecting the returned strings of the dma_fence_ops by RCU. This way dma_fence creators where able to just wait for an RCU grace period after fence signaling before they could be save to free those data structures. Now this patch set here goes a step further and protects the whole dma_fence_ops structure by RCU, so that after the fence signals the pointer to the dma_fence_ops is set to NULL when there is no wait nor release callback given. All functionality which use the dma_fence_ops reference are put inside an RCU critical section, except for the deprecated issuer specific wait and of course the optional release callback. Additional to the RCU changes the lock protecting the dma_fence state previously had to be allocated external. This set here now changes the functionality to make that external lock optional and allows dma_fences to use an inline lock and be self contained. v4: Rebases the whole set on upstream changes, especially the cleanup from Philip in patch "drm/amdgpu: independence for the amdkfd_fence!". Adding two patches which brings the DMA-fence self tests up to date. The first selftest changes removes the mock_wait and so actually starts testing the default behavior instead of some hacky implementation in the test. This one got upstreamed independent of this set. The second drops the mock_fence as well and tests the new RCU and inline spinlock functionality. v5: Rebase on top of drm-misc-next instead of drm-tip, leave out all driver changes for now since those should go through the driver specific paths anyway. Address a few more review comments, especially some rebase mess and typos. And finally fix one more bug found by AMDs CI system. v6: Minor style changes, re-ordered patch #1, dropped the scheduler fence change for now Please review and comment, Christian.

3 weeks, 5 days

[RFC PATCH 1/2] dma-buf/udmabuf: Introduce CONFIG_UDMABUF_SIZE_LIMIT_MBYTES

by Robert Mader

As udmabuf increasingly enjoys popularity - being used in projects like libcamera, Gstreamer, Mesa and KWin - 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 or high bit depths. While the limit can already be changed via the kernel command line, exposing it as a kernel config makes that easier and more discoverable for distros. Thus let's do that. Signed-off-by: Robert Mader <robert.mader(a)collabora.com> --- drivers/dma-buf/Kconfig | 6 ++++++ drivers/dma-buf/udmabuf.c | 4 ++++ 2 files changed, 10 insertions(+) diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig index 7efc0f0d0712..35f0779cdc80 100644 --- a/drivers/dma-buf/Kconfig +++ b/drivers/dma-buf/Kconfig @@ -40,6 +40,12 @@ config UDMABUF A driver to let userspace turn memfd regions into dma-bufs. Qemu can use this to create host dmabufs for guest framebuffers. +config UDMABUF_SIZE_LIMIT_MBYTES + int "Size limit in Mega Bytes" + default 64 + help + Maximum size of a udmabuf, in megabytes. Default is 64. + config DMABUF_DEBUG bool "DMA-BUF debug checks" depends on DMA_SHARED_BUFFER diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c index bced421c0d65..a83153326362 100644 --- a/drivers/dma-buf/udmabuf.c +++ b/drivers/dma-buf/udmabuf.c @@ -20,7 +20,11 @@ static int list_limit = 1024; module_param(list_limit, int, 0644); MODULE_PARM_DESC(list_limit, "udmabuf_create_list->count limit. Default is 1024."); +#ifdef CONFIG_UDMABUF_SIZE_LIMIT_MBYTES +static int size_limit_mb = CONFIG_UDMABUF_SIZE_LIMIT_MBYTES; +#else static int size_limit_mb = 64; +#endif module_param(size_limit_mb, int, 0644); MODULE_PARM_DESC(size_limit_mb, "Max size of a dmabuf, in megabytes. Default is 64."); -- 2.55.0

3 weeks, 5 days

Re: [RFC PATCH 10/30] vfio/pci: Export vfio dma-buf specific info for importers

by Jason Gunthorpe

On Thu, May 29, 2025 at 01:34:53PM +0800, Xu Yilun wrote: > Export vfio dma-buf specific info by attaching vfio_dma_buf_data in > struct dma_buf::priv. Provide a helper vfio_dma_buf_get_data() for > importers to fetch these data. Exporters identify VFIO dma-buf by > successfully getting these data. > > VFIO dma-buf supports disabling host access to these exported MMIO > regions when the device is converted to private. Exporters like KVM > need to identify this type of dma-buf to decide if it is good to use. > KVM only allows host unaccessible MMIO regions been mapped in private > roots. > > Export struct kvm * handler attached to the vfio device. This > allows KVM to do another sanity check. MMIO should only be assigned to > a CoCo VM if its owner device is already assigned to the same VM. This doesn't seem right, it should be encapsulated into the standard DMABUF API in some way. Jason

3 weeks, 5 days

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig