Linaro-mm-sig July 2026

linaro-mm-sig@lists.linaro.org

95 participants
105 discussions

WhatsApp(+44 7397 620325)Buy Spanish passport online,European Passport,ID Card drivers license,buy Drivers License, Residence Card, SSN, Green Card

by make.olise3＠gmail.com

Are you looking for the best online application process to apply and get your driver’s license, ID card or passport? You are in the right place! We provide our customers with an easy fast way of applying for their passport and other travel documents. Get verified identification documents, driver’s license, ID card, enhanced driver’s license and registered passports online. Apply for driving licenses in the UK We are here today to help you acquire your desire scores and help you achieve your dream diplomas such as IELTS, PTE, TOEFL, CELPIP, TOEFL,GOETHE B1, TELC B2, TRKI, CAPLE, CELPE, PMP, CISSP, USMLE, CELBAN, TOELF, GMAT, GRE, NEBOSH, ESOL, TOEIL, CELTA, etc……… WhatsApp(+44 7397 620325) WhatsApp(+44 7397 620325) {{Telegram @Frink002 }} Buy Dutch passport online Buy Norwegian passport online Buy Poland Passport online Buy Romania Passport online Buy Serbian passport online Buy Singapore Passport online Buy Hungarian passport online BUY DRIVING LICENSE , BUY BOAT LICENSE , BUY GAMBLING LICENSE, BUY PILOT LICENSE Apply for a passport online , Buy Passport Online Apply for Passport Online Fast Passport Services Renew Passport Online Get Passport in 24 Hours EU Passport Application US Passport Renewal Cotact bellow WhatsApp(+44 7397 620325) {{Telegram @Frink002 }} Email :::(Ligakvas@yahoo.com Buy Dutch passport online Buy Norwegian passport online Buy Poland Passport online Buy Romania Passport online Buy Serbian passport online Buy Singapore Passport online Buy Hungarian passport online Buy a French passport online Buy US passport online Buy Romanian passport online Buy Slovenian passport online Buy Slovak passport online Buy Spanish passport online Buy a Swiss passport online Buy Thailand passport online Buy Chile passport online Buy Croatian passport online Buy Canadian passport online WhatsApp(+44 7397 620325) WhatsApp(+44 7397 620325) {{Telegram @Frink002 }} Email :::(Ligakvas@yahoo.com Buy Costa Rica Passports online Buy Estonian passport online Buy Australia Passport online Buy Denmark driving license online Buy Portugal driving license online Buy Cyprus Driver License For Sale Buy Luxembourg driver's license online Buy Turkish driver's license online Buy Dutch driver's license online Buy Norwegian driver's license online Buy Romania driver's license online Buy Serbian driver's license online Buy Australian driver's license online Buy a German passport online German passport application BUY REAL PASSPORT ONLINE contact bellow WhatsApp(+44 7397 620325) WhatsApp(+44 7397 620325) {{Telegram @Frink002 }} Email( Ligakvas(a)yahoo.com

2 weeks, 5 days

WE SUPPLY CALUANIE OXIDIZE WORLDWIDE WhatsApp(+44 7397 620325)buy Caluanie Muelear Oxidize Parteurize russia?

by make.olise3＠gmail.com

We sale good quality Heavy water caluanie oxidize made in US. Buy Caluanie Oxidize online usa Where to buy Caluanie Oxide online usa Wholesale Caluanie Oxide online. Caluanie Muelear Oxidize For sale. Chemicals are widely used across various manufacturing industries for a wide range of purposes. Caluaine Oxidize is one of the most demanded products in the metal or chemical processing sector. Some of its core applications include: CALUANIE MUELEAR OXIDIZE Caluanie Muelear Oxidize for sale Caluanie is widely used in the chemical, paint industry as a substitute hygroscopic agent. It is widely applicable to the coatings, inks, plastics and printing inks industries. Available Packaging: 5L & bulk packaging as from 20L, 50L, 100L or as per buyer’s request. Caluanie Muelear Oxidize Parteurized (Heavy Water) Contact us now WhatsApp(+44 7397 620325) WhatsApp(+44 7397 620325) {{Telegram @Frink002 }} Email.( caluanieoxidized(a)gmail.com ) We're a Premium wholesaler & Retailer of Pure Red Mercury Online. We supply Pure Red Liquid Mercury of great quality. Our Pure Red Liquid Mercury, is highly demanded by industries world over to products a wide variety of products. It is high grade & perfectly composed Pure Red Liquid Mercury.WhatsApp(+44 7397620325) Pure Red Mercury ships worldwide with 100% guarantee of delivering your product on time. PACKAGING : 10gram of Red liquid mercury Red liquid mercury The red liquid mercury is a semi-liquid material cherry-red. The intensity of red liquid mercury is very high 20.2 g/ cm3. This Hg2 Sb207+O liquid is the Military Labs Material: Red liquid mercury Other name: Cherry Red liquid mercury Formula: Sb2O7Hg2+O Appearance: Cherry Red metal liquid Application: Mainly used in rocket, missile, military prospecting areas.WhatsApp(+44 7397620325) WhatsApp(+44 7397620325) {{Telegram @Frink002 }} Email.( caluanieoxidized(a)gmail.com )

2 weeks, 5 days

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

2 weeks, 5 days

[PATCH] dma_buf: change unsigned int and int types into size_t

by Shahyan Soltani

The num_fences, count, i, and j variables in dma_fence_dedup_array() and __dma_fence_unwrap_merge() have inconsistent integer types, mixing both unsigned int and int. Use type size_t consistently for these instead, and update the return type of dma_fence_dedup_array() accordingly. Signed-off-by: Shahyan Soltani <shahyan.soltani(a)amd.com> Suggested-by: Philipp Stanner <phasta(a)mailbox.org> --- The rest of the subsystems (dma_resv_reserve_fences, drm_exec, drm_gpuvm, xe, nouveau, etc) uses "unsigned int" for num_fences, for example the amdgpu caller in amdgpu_userq_fence.c. drivers/dma-buf/dma-fence-unwrap.c | 8 ++++---- include/linux/dma-fence-unwrap.h | 6 ++++-- 2 files changed, 8 insertions(+), 6 deletions(-) diff --git a/drivers/dma-buf/dma-fence-unwrap.c b/drivers/dma-buf/dma-fence-unwrap.c index 53bb40e70b27..65e87d263c3a 100644 --- a/drivers/dma-buf/dma-fence-unwrap.c +++ b/drivers/dma-buf/dma-fence-unwrap.c @@ -93,9 +93,9 @@ static int fence_cmp(const void *_a, const void *_b) * * Return: Number of unique fences remaining in the array. */ -int dma_fence_dedup_array(struct dma_fence **fences, int num_fences) +size_t dma_fence_dedup_array(struct dma_fence **fences, size_t num_fences) { - int i, j; + size_t i, j; sort(fences, num_fences, sizeof(*fences), fence_cmp, NULL); @@ -115,14 +115,14 @@ int dma_fence_dedup_array(struct dma_fence **fences, int num_fences) EXPORT_SYMBOL_GPL(dma_fence_dedup_array); /* Implementation for the dma_fence_merge() marco, don't use directly */ -struct dma_fence *__dma_fence_unwrap_merge(unsigned int num_fences, +struct dma_fence *__dma_fence_unwrap_merge(size_t num_fences, struct dma_fence **fences, struct dma_fence_unwrap *iter) { struct dma_fence *tmp, *unsignaled = NULL, **array; struct dma_fence_array *result; ktime_t timestamp; - int i, count; + size_t i, count; count = 0; timestamp = ns_to_ktime(0); diff --git a/include/linux/dma-fence-unwrap.h b/include/linux/dma-fence-unwrap.h index 62df222fe0f1..7bfacdf79de2 100644 --- a/include/linux/dma-fence-unwrap.h +++ b/include/linux/dma-fence-unwrap.h @@ -8,6 +8,8 @@ #ifndef __LINUX_DMA_FENCE_UNWRAP_H #define __LINUX_DMA_FENCE_UNWRAP_H +#include <linux/types.h> + struct dma_fence; /** @@ -48,11 +50,11 @@ struct dma_fence *dma_fence_unwrap_next(struct dma_fence_unwrap *cursor); for (fence = dma_fence_unwrap_first(head, cursor); fence; \ fence = dma_fence_unwrap_next(cursor)) -struct dma_fence *__dma_fence_unwrap_merge(unsigned int num_fences, +struct dma_fence *__dma_fence_unwrap_merge(size_t num_fences, struct dma_fence **fences, struct dma_fence_unwrap *cursors); -int dma_fence_dedup_array(struct dma_fence **array, int num_fences); +size_t dma_fence_dedup_array(struct dma_fence **array, size_t num_fences); /** * dma_fence_unwrap_merge - unwrap and merge fences -- 2.54.0

2 weeks, 5 days

dma_fence cleanup/rework

by Christian König

In a recent discussion with Philip and Danilo the question came up what was already tried and never finished to cleanup the dma_fence framework. So here are the different ideas I came with but never fully finished, with the patches itself modernized and rebased on top of drm-misc-next. The main goal of those changes is to make it easier to implement dma_fence backends and don't enforce unnecessary constrains on implementations. As first step the locking around the dma_fence_ops.signaled callback is made consistent by removing the dma_fence_is_signaled_locked() function. This was mostly used by backends itself, but if polling the HW is desired the backends can call their own functions for this directly without going through the dma-fence layer. XE actually seems to be the only driver which make use of that for a bit more handling. For all other cases testing the signaled flag should be enough. Then forcefully calling dma_fence_signaled() is removed from the dma-fence layer and moved into the backend implementations. This allows the backend implementations to cleanup after they have signaled the fence. Such cleanup can include removing now signaled fences from lists, dropping references, starting work etc.... Especially nouveau seems to have some really messy workaround because of that involving the DMA_FENCE_FLAG_USER_BITS and installing callbacks because the reference to the context couldn't be dropped directly after signaling. This can now be cleaned up as far as I can see. In the long term this should also allow reworking the error handling, e.g. removing dma_fence_set_error() and instead giving the error as mandatory parameter to dma_fence_signal(). Then the last piece is dropping calling enable_signaling callback with the dma_fence lock held. This makes it possible for backends to acquire locks which are semantically ordered outside of the dma_fence lock. This is necessary to allows using the dma_fence inline lock in more cases, previously backends used some common external lock for their dma_fences to for example make it possible remove fences from linked lists. Please comment and review, Christian.

2 weeks, 6 days

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig July 2026