Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

107 participants
7067 discussions

[PATCH v5 5/7] drm/amdgpu: get rid of amdgpu_ttm_clear_buffer

by Pierre-Eric Pelloux-Prayer

It's doing the same thing as amdgpu_fill_buffer(src_data=0), so drop it. The only caveat is that amdgpu_res_cleared() return value is only valid right after allocation. --- v2: introduce new "bool consider_clear_status" arg --- Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer(a)amd.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 16 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 88 +++++----------------- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 6 +- 3 files changed, 32 insertions(+), 78 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c index 66c20dd46d12..d0884bbffa75 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c @@ -717,13 +717,17 @@ int amdgpu_bo_create(struct amdgpu_device *adev, bo->tbo.resource->mem_type == TTM_PL_VRAM) { struct dma_fence *fence; - r = amdgpu_ttm_clear_buffer(bo, bo->tbo.base.resv, &fence); + r = amdgpu_fill_buffer(amdgpu_ttm_next_clear_entity(adev), + bo, 0, NULL, &fence, + true, AMDGPU_KERNEL_JOB_ID_TTM_CLEAR_BUFFER); if (unlikely(r)) goto fail_unreserve; - dma_resv_add_fence(bo->tbo.base.resv, fence, - DMA_RESV_USAGE_KERNEL); - dma_fence_put(fence); + if (fence) { + dma_resv_add_fence(bo->tbo.base.resv, fence, + DMA_RESV_USAGE_KERNEL); + dma_fence_put(fence); + } } if (!bp->resv) amdgpu_bo_unreserve(bo); @@ -1326,8 +1330,8 @@ void amdgpu_bo_release_notify(struct ttm_buffer_object *bo) goto out; r = amdgpu_fill_buffer(amdgpu_ttm_next_clear_entity(adev), - abo, 0, &bo->base._resv, - &fence, AMDGPU_KERNEL_JOB_ID_CLEAR_ON_RELEASE); + abo, 0, &bo->base._resv, &fence, + false, AMDGPU_KERNEL_JOB_ID_CLEAR_ON_RELEASE); if (WARN_ON(r)) goto out; diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c index 648ad344e89c..a3d0998b8cec 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c @@ -418,7 +418,7 @@ static int amdgpu_move_blit(struct ttm_buffer_object *bo, (abo->flags & AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE)) { struct dma_fence *wipe_fence = NULL; r = amdgpu_fill_buffer(entity, abo, 0, NULL, &wipe_fence, - AMDGPU_KERNEL_JOB_ID_MOVE_BLIT); + false, AMDGPU_KERNEL_JOB_ID_MOVE_BLIT); if (r) { goto error; } else if (wipe_fence) { @@ -2572,76 +2572,25 @@ static int amdgpu_ttm_fill_mem(struct amdgpu_device *adev, } /** - * amdgpu_ttm_clear_buffer - clear memory buffers - * @bo: amdgpu buffer object - * @resv: reservation object - * @fence: dma_fence associated with the operation + * amdgpu_fill_buffer - fill a buffer with a given value + * @entity: entity to use + * @bo: the bo to fill + * @src_data: the value to set + * @resv: fences contained in this reservation will be used as dependencies. + * @out_fence: the fence from the last clear will be stored here. It might be + * NULL if no job was run. + * @dependency: optional input dependency fence. + * @consider_clear_status: true if region reported as cleared by amdgpu_res_cleared() + * are skipped. + * @k_job_id: trace id * - * Clear the memory buffer resource. - * - * Returns: - * 0 for success or a negative error code on failure. */ -int amdgpu_ttm_clear_buffer(struct amdgpu_bo *bo, - struct dma_resv *resv, - struct dma_fence **fence) -{ - struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev); - struct amdgpu_ttm_buffer_entity *entity; - struct amdgpu_res_cursor cursor; - u64 addr; - int r = 0; - - if (!adev->mman.buffer_funcs_enabled) - return -EINVAL; - - if (!fence) - return -EINVAL; - entity = &adev->mman.clear_entities[0]; - *fence = dma_fence_get_stub(); - - amdgpu_res_first(bo->tbo.resource, 0, amdgpu_bo_size(bo), &cursor); - - mutex_lock(&entity->lock); - while (cursor.remaining) { - struct dma_fence *next = NULL; - u64 size; - - if (amdgpu_res_cleared(&cursor)) { - amdgpu_res_next(&cursor, cursor.size); - continue; - } - - /* Never clear more than 256MiB at once to avoid timeouts */ - size = min(cursor.size, 256ULL << 20); - - r = amdgpu_ttm_map_buffer(entity, &bo->tbo, bo->tbo.resource, &cursor, - 0, false, &size, &addr); - if (r) - goto err; - - r = amdgpu_ttm_fill_mem(adev, entity, 0, addr, size, resv, - &next, true, - AMDGPU_KERNEL_JOB_ID_TTM_CLEAR_BUFFER); - if (r) - goto err; - - dma_fence_put(*fence); - *fence = next; - - amdgpu_res_next(&cursor, size); - } -err: - mutex_unlock(&entity->lock); - - return r; -} - int amdgpu_fill_buffer(struct amdgpu_ttm_buffer_entity *entity, struct amdgpu_bo *bo, uint32_t src_data, struct dma_resv *resv, - struct dma_fence **f, + struct dma_fence **out_fence, + bool consider_clear_status, u64 k_job_id) { struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev); @@ -2659,6 +2608,11 @@ int amdgpu_fill_buffer(struct amdgpu_ttm_buffer_entity *entity, struct dma_fence *next; uint64_t cur_size, to; + if (consider_clear_status && amdgpu_res_cleared(&dst)) { + amdgpu_res_next(&dst, dst.size); + continue; + } + /* Never fill more than 256MiB at once to avoid timeouts */ cur_size = min(dst.size, 256ULL << 20); @@ -2680,9 +2634,7 @@ int amdgpu_fill_buffer(struct amdgpu_ttm_buffer_entity *entity, } error: mutex_unlock(&entity->lock); - if (f) - *f = dma_fence_get(fence); - dma_fence_put(fence); + *out_fence = fence; return r; } diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h index a6249252948b..436a3e09a178 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h @@ -187,14 +187,12 @@ int amdgpu_copy_buffer(struct amdgpu_device *adev, struct dma_resv *resv, struct dma_fence **fence, bool vm_needs_flush, uint32_t copy_flags); -int amdgpu_ttm_clear_buffer(struct amdgpu_bo *bo, - struct dma_resv *resv, - struct dma_fence **fence); int amdgpu_fill_buffer(struct amdgpu_ttm_buffer_entity *entity, struct amdgpu_bo *bo, uint32_t src_data, struct dma_resv *resv, - struct dma_fence **f, + struct dma_fence **out_fence, + bool consider_clear_status, u64 k_job_id); struct amdgpu_ttm_buffer_entity *amdgpu_ttm_next_clear_entity(struct amdgpu_device *adev); -- 2.43.0

2 months, 2 weeks

[PATCH] dma-buf: heaps: system: document system_cc_shared heap

by Jiri Pirko

From: Jiri Pirko <jiri(a)nvidia.com> Document the system_cc_shared dma-buf heap that was introduced recently. Describe its purpose, availability conditions and relation to confidential computing VMs. Signed-off-by: Jiri Pirko <jiri(a)nvidia.com> --- Documentation/userspace-api/dma-buf-heaps.rst | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/Documentation/userspace-api/dma-buf-heaps.rst b/Documentation/userspace-api/dma-buf-heaps.rst index 05445c83b79a..591732393e7d 100644 --- a/Documentation/userspace-api/dma-buf-heaps.rst +++ b/Documentation/userspace-api/dma-buf-heaps.rst @@ -16,6 +16,14 @@ following heaps: - The ``system`` heap allocates virtually contiguous, cacheable, buffers. + - The ``system_cc_shared`` heap allocates virtually contiguous, cacheable, + buffers using shared (decrypted) memory. It is only present on + confidential computing (CoCo) VMs where memory encryption is active + (e.g., AMD SEV, Intel TDX). The allocated pages have the encryption + bit cleared, making them accessible for device DMA without TDISP + support. On non-CoCo VMs configurations, this heap is + not registered. + - The ``default_cma_region`` heap allocates physically contiguous, cacheable, buffers. Only present if a CMA region is present. Such a region is usually created either through the kernel commandline -- 2.51.1

2 months, 2 weeks

Expertise in Recovery

by penelopestaunton931＠gmail.com

Safeguard is not just another name in the crowded field of cryptocurrency recovery; they are renowned for their effectiveness and expertise in tracing lost funds. Their team comprises skilled professionals who understand the intricate workings of blockchain technology and the tactics employed by online scammers. This specialized knowledge enables them to devise tailored strategies to recover your assets. Email,.. safeguardbitcoin(a)consultant.com WhatsApp,.. +44 7426 168300 Web:., https://safeguardbitcoin.wixsite.com/safeguard-bitcoin--1

2 months, 3 weeks

Have you fallen victim to a bitcoin or crypto scam?

by admin＠trektechcorp.net

Don't worry, TREK Tech Corp is here to help you get your lost coins back. Our expert team specializes in recovering funds from fraudulent schemes and can assist you in reclaiming what is rightfully yours. Contact us today for a free consultation and let us help you get back on track. Don't let scammers hold you back any longer, trust TREK Tech Corp to help you recover your lost funds. Contact email: trektechcorp1(a)gmail.com / trektechcorp(a)consultant.com.

2 months, 3 weeks

BEST RECOVERY EXPERT

by admin＠trektechcorp.net

In the volatile world of cryptocurrency, where billions are lost annually to scams, hacks, phishing attacks, rug pulls, and wallet compromises, the demand for legitimate recovery services has never been higher. As of 02/ 22/ 2026, victims often face a dual challenge: recovering stolen or inaccessible funds while avoiding secondary scams that prey on desperation with false promises and upfront fees. Amid this landscape, TREK Tech Corp—commonly referred to as CCS—has established itself as a credible, professional firm specializing in blockchain forensics, crypto asset tracing, fraud investigation, and realistic recovery support. TREK Tech Corp operates with a foundation built on 14 years of experience in digital investigations, long predating the widespread adoption of cryptocurrencies. This extensive background in forensics gives CCS a significant edge over many newer entrants in the crypto recovery space. The firm focuses on helping individuals, families, and institutions trace lost or stolen digital assets using advanced, transparent methods rather than speculative or guaranteed outcomes. Their official website is https://www.trektechcorp.net, and direct inquiries can be sent to trektechcorp1(a)gmail.com. What sets TREK Tech Corp apart as a legitimate provider is its commitment to ethical standards and evidence-based processes. Unlike fraudulent recovery operations that demand large upfront payments without case evaluation or promise 100% success (a clear red flag in the industry), CCS conducts honest feasibility assessments from the outset. They never require clients to share private keys, seed phrases, or sensitive wallet credentials during initial consultations. Fees are typically aligned with outcomes, and the firm maintains strict confidentiality with robust data protection protocols. The core of TREK Tech Corp’ service is multi-layer blockchain attribution—a proprietary technique that tracks funds through complex laundering paths. Scammers frequently use mixers, cross-chain bridges, decentralized exchanges, privacy protocols, flash-loan obfuscation, and automated smart-contract tumbling to break direct traceability. Basic block explorers lose visibility after one or two hops, but CCS reconstructs these movements by analyzing on-chain behavioral patterns: timing correlations, amount similarities, address clustering via co-spending heuristics, change address reuse, and interactions with known services. A typical engagement begins with a secure intake process. Victims submit transaction hashes (TXIDs), wallet addresses, scam communications, screenshots, and timelines. TREK Tech Corp then performs comprehensive on-chain and off-chain analysis, building detailed transaction graphs and identifying probable endpoints—most commonly centralized exchanges that enforce KYC/AML compliance. When funds reach such platforms, CCS prepares evidence-grade forensic reports that include visualized flow diagrams, confidence-scored address clusters, identified laundering techniques, and recommended intervention steps. These reports are frequently used to support asset freeze requests submitted to exchange compliance teams or filed with law enforcement agencies such as the FBI’s Internet Crime Complaint Center (IC3), local cybercrime units, or financial regulators. TREK Tech Corp emphasizes speed: the sooner a theft is reported and analyzed, the higher the chance of intervention before funds are fully dispersed. In cases where rapid action was taken, partial recoveries—often 70–90% of stolen amounts—have been achieved through coordinated freezes and subsequent legal processes. While full recovery is never guaranteed due to blockchain’s immutable design and variables like scammer sophistication and jurisdictional limits, CCS provides clear, realistic expectations from day one. Beyond recovery support, TREK Tech Corp prioritizes victim education and prevention. Clients receive tailored guidance on hardening security: using hardware wallets, enabling strong multi-factor authentication, securely backing up seed phrases in multiple encrypted locations, verifying addresses before every transfer, monitoring wallet activity proactively, and recognizing emerging threats such as AI-enhanced impersonation scams, clipboard hijacking, or malicious browser extensions. This preventive focus helps reduce the likelihood of future incidents and empowers users in an environment where threats evolve rapidly. The firm’s legitimacy is further reinforced by its performance metrics and client feedback. As of early 2026, TREK Tech Corp has successfully handled over 426 documented projects and maintains a 4.28 out of 5 rating based on more than 2,467 verified reviews. Clients consistently highlight the team’s professionalism, technical precision, clear communication, regular updates, and genuine support during high-stress situations. In an industry rife with advance-fee fraud and misleading marketing, CCS stands out for refusing high-pressure tactics, avoiding unrealistic guarantees, and focusing on evidence-driven results. For anyone who has suffered a crypto loss—whether through a sophisticated scam, forgotten credentials, hardware failure, or inheritance complications—TREK Tech Corp offers a professional, confidential pathway forward. Their website, https://www.trektechcorp.net, provides in-depth information about services, the investigation process, anonymized case examples, and how to initiate contact. Direct email communication is available at trektechcorp1(a)gmail.com for a no-obligation initial consultation. In conclusion, legitimate crypto recovery requires expertise, transparency, and ethical conduct—qualities TREK Tech Corp consistently demonstrates. While blockchain’s architecture limits reversals, CCS leverages decades of investigative rigor, advanced multi-layer attribution, and strategic coordination to deliver clarity, evidence, and realistic recovery opportunities. In 2026’s high-risk digital asset environment, partnering with a reputable firm like TREK Tech Corp can make the critical difference between permanent loss and meaningful progress toward reclamation and renewed security.

2 months, 3 weeks

Expertise in Recovery

by penelopestaunton931＠gmail.com

2 months, 3 weeks

Expertise in Recovery

by penelopestaunton931＠gmail.com

2 months, 3 weeks

Re: [PATCH 1/7] drm/shmem-helper: Add lockdep asserts to vmap/vunmap

by Bence Csókás

Hi, I just came across this commit while researching something else. Original patch had too few context lines, so I here's the diff with `-U10`. On 3/18/25 20:22, Daniel Almeida wrote: > From: Asahi Lina <lina(a)asahilina.net> > > Since commit 21aa27ddc582 ("drm/shmem-helper: Switch to reservation > lock"), the drm_gem_shmem_vmap and drm_gem_shmem_vunmap functions > require that the caller holds the DMA reservation lock for the object. > Add lockdep assertions to help validate this. There were already lockdep assertions... > Signed-off-by: Asahi Lina <lina(a)asahilina.net> > Signed-off-by: Daniel Almeida <daniel.almeida(a)collabora.com> > Reviewed-by: Christian König <christian.koenig(a)amd.com> > Signed-off-by: Lyude Paul <lyude(a)redhat.com> > Link: https://lore.kernel.org/r/20250318-drm-gem-shmem-v1-1-64b96511a84f@collabor… > --- > drivers/gpu/drm/drm_gem_shmem_helper.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c b/drivers/gpu/drm/drm_gem_shmem_helper.c > index aa43265f4f4f..0b41f0346bad 100644 > --- a/drivers/gpu/drm/drm_gem_shmem_helper.c > +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c > @@ -341,20 +341,22 @@ EXPORT_SYMBOL_GPL(drm_gem_shmem_unpin); > * > * Returns: > * 0 on success or a negative error code on failure. > */ > int drm_gem_shmem_vmap_locked(struct drm_gem_shmem_object *shmem, > struct iosys_map *map) > { > struct drm_gem_object *obj = &shmem->base; > int ret = 0; > > + dma_resv_assert_held(obj->resv); > + > if (drm_gem_is_imported(obj)) { > ret = dma_buf_vmap(obj->dma_buf, map); > } else { > pgprot_t prot = PAGE_KERNEL; > > dma_resv_assert_held(shmem->base.resv); ... right here, and > if (refcount_inc_not_zero(&shmem->vmap_use_count)) { > iosys_map_set_vaddr(map, shmem->vaddr); > return 0; > @@ -401,20 +403,22 @@ EXPORT_SYMBOL_GPL(drm_gem_shmem_vmap_locked); > * drops to zero. > * > * This function hides the differences between dma-buf imported and natively > * allocated objects. > */ > void drm_gem_shmem_vunmap_locked(struct drm_gem_shmem_object *shmem, > struct iosys_map *map) > { > struct drm_gem_object *obj = &shmem->base; > > + dma_resv_assert_held(obj->resv); > + > if (drm_gem_is_imported(obj)) { > dma_buf_vunmap(obj->dma_buf, map); > } else { > dma_resv_assert_held(shmem->base.resv); ...here. > if (refcount_dec_and_test(&shmem->vmap_use_count)) { > vunmap(shmem->vaddr); > shmem->vaddr = NULL; > > drm_gem_shmem_unpin_locked(shmem); Or were those insufficient for some reason? If so, should we keep both of them, or should the older ones have been removed? Bence

2 months, 3 weeks

[PATCH v4 0/8] dma-buf: heaps: Turn heaps into modules

by Maxime Ripard

Hi, The recent introduction of heaps in the optee driver [1] made possible the creation of heaps as modules. It's generally a good idea if possible, including for the already existing system and CMA heaps. The system one is pretty trivial, the CMA one is a bit more involved, especially since we have a call from kernel/dma/contiguous.c to the CMA heap code. This was solved by turning the logic around and making the CMA heap call into the contiguous DMA code. Let me know what you think, Maxime 1: https://lore.kernel.org/dri-devel/20250911135007.1275833-4-jens.wiklander@l… Signed-off-by: Maxime Ripard <mripard(a)kernel.org> --- Changes in v4: - Fix compilation failure - Rework to take into account OF_RESERVED_MEM - Fix regression making the default CMA area disappear if not created through the DT - Added some documentation and comments - Link to v3: https://lore.kernel.org/r/20260303-dma-buf-heaps-as-modules-v3-0-24344812c7… Changes in v3: - Squashed cma_get_name and cma_alloc/release patches - Fixed typo in Export dev_get_cma_area commit title - Fixed compilation failure with DMA_CMA but not OF_RESERVED_MEM - Link to v2: https://lore.kernel.org/r/20260227-dma-buf-heaps-as-modules-v2-0-454aee7e06… Changes in v2: - Collect tags - Don't export dma_contiguous_default_area anymore, but export dev_get_cma_area instead - Mentioned that heap modules can't be removed - Link to v1: https://lore.kernel.org/r/20260225-dma-buf-heaps-as-modules-v1-0-2109225a09… --- Maxime Ripard (8): dma: contiguous: Turn heap registration logic around dma: contiguous: Make dev_get_cma_area() a proper function dma: contiguous: Make dma_contiguous_default_area static dma: contiguous: Export dev_get_cma_area() mm: cma: Export cma_alloc(), cma_release() and cma_get_name() dma-buf: heaps: Export mem_accounting parameter dma-buf: heaps: cma: Turn the heap into a module dma-buf: heaps: system: Turn the heap into a module drivers/dma-buf/dma-heap.c | 1 + drivers/dma-buf/heaps/Kconfig | 4 +-- drivers/dma-buf/heaps/cma_heap.c | 22 +++---------- drivers/dma-buf/heaps/system_heap.c | 5 +++ include/linux/dma-buf/heaps/cma.h | 16 --------- include/linux/dma-map-ops.h | 14 ++++---- kernel/dma/contiguous.c | 66 +++++++++++++++++++++++++++++++++---- mm/cma.c | 3 ++ 8 files changed, 82 insertions(+), 49 deletions(-) --- base-commit: c081b71f11732ad2c443f170ab19c3ebe8a1a422 change-id: 20260225-dma-buf-heaps-as-modules-1034b3ec9f2a Best regards, -- Maxime Ripard <mripard(a)kernel.org>

2 months, 3 weeks

[PATCH V2] i2c: qcom-geni: Avoid extra TX DMA TRE for single read message in GPI mode

by Aniket Randive

In GPI mode, the I2C GENI driver programs an extra TX DMA transfer descriptor (TRE) on the TX channel when handling a single read message. This results in an unintended write phase being issued on the I2C bus, even though a read transaction does not require any TX data. For a single-byte read, the correct hardware sequence consists of the CONFIG and GO commands followed by a single RX DMA TRE. Programming an additional TX DMA TRE is redundant, causes unnecessary DMA buffer mapping on the TX channel, and may lead to incorrect bus behavior. Update the transfer logic to avoid programming a TX DMA TRE for single read messages in GPI mode. Co-developed-by: Maramaina Naresh <naresh.maramaina(a)oss.qualcomm.com> Signed-off-by: Maramaina Naresh <naresh.maramaina(a)oss.qualcomm.com> Signed-off-by: Aniket Randive <aniket.randive(a)oss.qualcomm.com> --- Changes in v2: - Updated the commit message. drivers/i2c/busses/i2c-qcom-geni.c | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/drivers/i2c/busses/i2c-qcom-geni.c b/drivers/i2c/busses/i2c-qcom-geni.c index a4acb78fafb6..2706309bbebb 100644 --- a/drivers/i2c/busses/i2c-qcom-geni.c +++ b/drivers/i2c/busses/i2c-qcom-geni.c @@ -625,8 +625,8 @@ static int geni_i2c_gpi(struct geni_i2c_dev *gi2c, struct i2c_msg msgs[], { struct gpi_i2c_config *peripheral; unsigned int flags; - void *dma_buf; - dma_addr_t addr; + void *dma_buf = NULL; + dma_addr_t addr = 0; enum dma_data_direction map_dirn; enum dma_transfer_direction dma_dirn; struct dma_async_tx_descriptor *desc; @@ -639,6 +639,11 @@ static int geni_i2c_gpi(struct geni_i2c_dev *gi2c, struct i2c_msg msgs[], gi2c_gpi_xfer = &gi2c->i2c_multi_desc_config; msg_idx = gi2c_gpi_xfer->msg_idx_cnt; + if (op == I2C_WRITE && msgs[msg_idx].flags & I2C_M_RD) { + peripheral->multi_msg = true; + goto skip_dma; + } + dma_buf = i2c_get_dma_safe_msg_buf(&msgs[msg_idx], 1); if (!dma_buf) { ret = -ENOMEM; @@ -668,6 +673,7 @@ static int geni_i2c_gpi(struct geni_i2c_dev *gi2c, struct i2c_msg msgs[], flags = DMA_PREP_INTERRUPT | DMA_CTRL_ACK; } +skip_dma: /* set the length as message for rx txn */ peripheral->rx_len = msgs[msg_idx].len; peripheral->op = op; @@ -740,9 +746,11 @@ static int geni_i2c_gpi(struct geni_i2c_dev *gi2c, struct i2c_msg msgs[], return 0; err_config: - dma_unmap_single(gi2c->se.dev->parent, addr, - msgs[msg_idx].len, map_dirn); - i2c_put_dma_safe_msg_buf(dma_buf, &msgs[msg_idx], false); + if (op == I2C_WRITE && (msgs[msg_idx].flags & I2C_M_RD)) { + dma_unmap_single(gi2c->se.dev->parent, addr, + msgs[msg_idx].len, map_dirn); + i2c_put_dma_safe_msg_buf(dma_buf, &msgs[msg_idx], false); + } out: gi2c->err = ret; -- 2.34.1

2 months, 3 weeks

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig