Hi Helen,
On 21/05/24 01:54, Helen Koike wrote:
On 17/05/2024 06:24, Vignesh Raman wrote:
Stop vendoring the testlist into the kernel. Instead, use the
testlist from the IGT build to ensure we do not miss renamed
or newly added tests.
Signed-off-by: Vignesh Raman
---
v2:
- Fix testlist
On Mon, 20 May 2024 19:24:19 +0200
Danilo Krummrich wrote:
> Add an abstraction around the kernels firmware API to request firmware
> images. The abstraction provides functions to access the firmware
> buffer and / or copy it to a new buffer allocated with a given
> allocator backend.
>
Was pla
Hi Dmitry,
On 20/05/24 16:32, Dmitry Baryshkov wrote:
On Fri, May 17, 2024 at 02:54:59PM +0530, Vignesh Raman wrote:
With latest IGT, the tests tries to load the module and it
fails. So build the virtual GPU driver for virtio as module.
Why? If the test fails on module loading (if the driver
This series implements TTM shrinker / eviction helpers and an xe bo
shrinker. It builds on two previous series, *and obsoletes these*. First
https://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg484425.html
Second the previous TTM shrinker series
https://lore.kernel.org/linux-mm/b74913
To be able to handle list unlocking while traversing the LRU
list, we want the iterators not only to point to the next
position of the list traversal, but to insert themselves as
list nodes at that point to work around the fact that the
next node might otherwise disappear from the list while
the it
Have iterators insert themselves into the list they are iterating
over using hitch list nodes. Since only the iterator owner
can remove these list nodes from the list, it's safe to unlock
the list and when continuing, use them as a starting point. Due to
the way LRU bumping works in TTM, newly adde
Rework the TTM swapping to use the LRU walker helper.
This helps fixing up the ttm_bo_swapout() interface
to be consistent about not requiring any locking.
For now mimic the current behaviour of using trylock
only. We could be using ticket-locks here but defer
that until it's deemed necessary. The
To address the problem with hitches moving when bulk move
sublists are lru-bumped, register the list cursors with the
ttm_lru_bulk_move structure when traversing its list, and
when lru-bumping the list, move the cursor hitch to the tail.
This also means it's mandatory for drivers to call
ttm_lru_bu
To make the transition to using lru hitches easier,
simplify the ttm_resource_manager_next() interface to only take
the cursor and reuse ttm_resource_manager_next() functionality
from ttm_resource_manager_first().
Cc: Christian König
Cc: Somalapuram Amaranath
Cc: Matthew Brost
Cc:
Signed-off-b
Use the LRU walker for eviction. This helps
removing a lot of code with weird locking
semantics.
The functionality is slightly changed so that
when trylocked buffer objects are exhausted, we
continue to interleave walks with ticket-locks while
there is still progress made. The list walks are
not r
Provide a helper to shrink ttm_tt page-vectors on a per-page
basis. A ttm_backup backend could then in theory get away with
allocating a single temporary page for each struct ttm_tt.
This is accomplished by splitting larger pages before trying to
back them up.
In the future we could allow ttm_bac
Rather than relying on the TTM watermark accounting add a shrinker
for xe_bos in TT or system memory.
Leverage the newly added TTM per-page shrinking and shmem backup
support.
Although xe doesn't fully support WONTNEED (purgeable) bos yet,
introduce and add shrinker support for purgeable ttm_tts.
For the drm_exec_trylock() functionality, there is a need to be able
to trylock a dma-resv object as part of a drm_exec transaction.
Therefore expose a variant of dma_resv_trylock that also takes
a struct ww_acquire_ctx parameter.
Cc: Christian König
Cc: Somalapuram Amaranath
Cc: Matthew Brost
Locking for eviction is in some way different from locking for
submission:
1) We can't lock objects that are already locked for submission,
hence DRM_EXEC_IGNORE_DUPLICATES must be unset.
2) We must be able to re-lock objects locked for eviction,
either for submission or for yet another eviction,
Buffer object initialization may be part of a drm_exec transaction.
Rather than using dma_resv_trylock, use drm_exec_trylock_obj().
RFC: This patch indicates to me that we should avoid the -ENOMEM failure
for drm_exec_trylock, Could probably use a sleeping lock here without
problems.
Cc: Christia
TTM needs to trylock dma_resv objects in a couple of places. However
this functionality is missing in drm_exec. Introduce it.
Note that in addition to the -EBUSY error returned on failure to
take the lock, the operation may return -ENOMEM if there was a
failure to allocate memory for the drm_exec
Initially intended for experimenting with different backup
solutions (shmem vs direct swap cache insertion), abstract
the backup destination using a virtual base class.
Also provide a sample implementation for shmem.
While when settling on a preferred backup solution, one could
perhaps skip the a
Snapshot the drm_exec state before validation, and perform locking
for eviction and swapping using the passed in drm_exec pointer
if any. Otherwise fall back to trylock / ticketlock.
Cc: Christian König
Cc: Somalapuram Amaranath
Cc: Matthew Brost
Cc:
Signed-off-by: Thomas Hellström
---
drive
When validating a buffer object for submission, we might need to lock
a number of object for eviction to make room for the validation.
This makes it pretty likely that validation will eventually succeed,
since eventually the validating process will hold most dma_resv locks
of the buffer objects re
Provide a generic LRU walker in TTM, in the spirit of drm_gem_lru_scan()
but building on the restartable TTM LRU functionality.
The LRU walker optionally supports locking objects as part of
a ww mutex locking transaction, to mimic to some extent the
current functionality in ttm. However any -EDEAD
If contention and backoff occurs during a drm_exec ww transaction,
the contended lock is not locked again until the next orinary
attempt to lock a dma_resv lock. However, with the introduction of
drm_exec_trylock(), that doesn't work, since the locking of the
contended lock needs to be a sleeping l
TTM faulting may include migration and swapping. Convert
helpers to support drm_exec locking and enable it
by converting the ttm_bo_vm_fault() function to include
a drm_exec loop.
Cc: Christian König
Cc: Somalapuram Amaranath
Cc: Matthew Brost
Cc:
Signed-off-by: Thomas Hellström
---
drivers/
Use fault-injection to test partial TTM swapout and interrupted swapin.
Return -EINTR for swapin to test the callers ability to handle and
restart the swapin, and on swapout perform a partial swapout to test that
the swapin and release_shrunken functionality.
Cc: Christian König
Cc: Somalapuram A
Similar to how TTM vm does this, convert the drm/xe fault
handler to use drm_exec locking.
Cc: Christian König
Cc: Somalapuram Amaranath
Cc: Matthew Brost
Cc:
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/xe/xe_bo.c | 38 +++---
1 file changed, 23 insert
Initial stab at converting xe_bo validation to drm_exec locking
where it matters most. (Low hanging fruit). For a couple of call
sites as well as for bo allocation, the passing down the call
chaing of the drm_exec object may turn out a bit tricky.
Cc: Christian König
Cc: Somalapuram Amaranath
Cc
On 21/05/2024 12:58, keith wrote:
> Verisilicon/DC8200 display controller IP has 2 display pipes and each
> pipe support a primary plane and a cursor plane .
> In addition, there are four overlay planes as two display pipes common
> resources.
>
> The first display pipe is bound to the inno HDM
On Mon, May 20, 2024 at 5:25 PM John Paul Adrian Glaubitz
wrote:
> On Mon, 2024-05-20 at 22:06 +0900, Yoshinori Sato wrote:
> > I'll be posting v8 soon.
>
> Sounds good! Maybe we can start merging the patches that contain fixes only
> and that have already been reviewed. This way, we can reduce th
Hi, all
On Tue, 2024-05-21 at 09:16 +0200, Thomas Hellström wrote:
> This series implements TTM shrinker / eviction helpers and an xe bo
> shrinker. It builds on two previous series, *and obsoletes these*.
> First
>
> https://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg484425.html
>
On 21/05/2024 12:58, keith wrote:
> JH7110 SoC display pipeline includes a display controller and hdmi.
> Dc controller IP : Vivante DC8200 Dual Display
> HDMI IP : INNOSILICON HDMI2.0
>
> As the INNO hdmi ip is also used by rockchip SoC in the driver code,
> the innosilicon,inno-hdmi.yaml schema
Hi Sato-san,
On Thu, Apr 4, 2024 at 7:15 AM Yoshinori Sato
wrote:
> Renesas SH7750 and SH7751 series CPG driver.
> This driver supported frequency control and clock gating.
>
> Signed-off-by: Yoshinori Sato
Thanks for the update!
As you plan to send a v8 soon, I'm sending you a comment from th
On 17/05/2024 17:16, Thomas Zimmermann wrote:
Hi
Am 17.05.24 um 17:09 schrieb Jocelyn Falempe:
Unfortunately, the G200 ioburst workaround doesn't work on some
servers like Dell poweredge XR11, XR5610, or HPE XL260. In this case
completely disabling WC is the only option to achieve low-latenc
From: Kuro Chung
When the system power resumes, the TTL input of IT6505 may experience
some noise before the video signal stabilizes, necessitating a video
reset. This patch is implemented to prevent a loop of video error
interrupts, which can occur when a video reset in the video FIFO error
inte
Changes in v5:
- Fixed commit [2/3], changed allOf -> anyOf to get the
intended allowance in the binding
Changes in v4:
- Fixed a typo that caused pure OF graphs pipelines multiple
concurrent outputs to not get correctly parsed (port->id);
- Added OVL_ADAPTOR support for OF graph specifi
It is impossible to add each and every possible DDP path combination
for each and every possible combination of SoC and board: right now,
this driver hardcodes configuration for 10 SoCs and this is going to
grow larger and larger, and with new hacks like the introduction of
mtk_drm_route which is a
Document OF graph on MMSYS/VDOSYS: this supports up to three DDP paths
per HW instance (so potentially up to six displays for multi-vdo SoCs).
The MMSYS or VDOSYS is always the first component in the DDP pipeline,
so it only supports an output port with multiple endpoints - where each
endpoint def
The display IPs in MediaTek SoCs support being interconnected with
different instances of DDP IPs (for example, merge0 or merge1) and/or
with different DDP IPs (for example, rdma can be connected with either
color, dpi, dsi, merge, etc), forming a full Display Data Path that
ends with an actual dis
Hi Alex,
Am Dienstag, 21. Mai 2024, 12:58:07 CEST schrieb keith:
> Verisilicon/DC8200 display controller IP has 2 display pipes and each
> pipe support a primary plane and a cursor plane .
> In addition, there are four overlay planes as two display pipes common
> resources.
>
> The first displ
On 12/05/2024 17:25, Noralf Trønnes via B4 Relay wrote:
From: Noralf Trønnes
Add support for these pixel format property values:
- r5g6b5, RGB565
- b6x2g6x2r6x2, BGR666
BGR666 is presented to userspace as RGB888. The 2 LSB in each color
are discarded by the controller. The pixel is sent on the
On Thu, May 16, 2024 at 06:40:45PM GMT, Sui Jingfeng wrote:
> Hi,
>
> On 5/16/24 16:25, Maxime Ripard wrote:
> > On Wed, May 15, 2024 at 11:19:58PM +0800, Sui Jingfeng wrote:
> > > Hi,
> > >
> > >
> > > On 5/15/24 22:58, Maxime Ripard wrote:
> > > > On Wed, May 15, 2024 at 10:53:00PM +0800, Sui
On Thu, May 16, 2024 at 08:04:59PM GMT, Sui Jingfeng wrote:
>
>
> On 5/16/24 18:40, Sui Jingfeng wrote:
> > use 'to_i2c_client(bridge->dev)' to retrieve the pointer
>
> to_i2c_client(bridge->kdev).
>
> Besides, this also means that we don't need to add the fwnode
> pointer into struct drm_bridg
On Thu, May 16, 2024 at 01:11:51PM GMT,
nicolas.dufre...@collabora.corp-partner.google.com wrote:
> Le jeudi 16 mai 2024 à 14:27 +0300, Laurent Pinchart a écrit :
> > Hi Nicolas,
> >
> > On Wed, May 15, 2024 at 01:43:58PM -0400,
> > nicolas.dufre...@collabora.corp-partner.google.com wrote:
> > >
On Thu Feb 29, 2024 at 12:55 AM EET, Helen Koike wrote:
> Dear Kernel Community,
>
> This patch introduces a `.gitlab-ci` file along with a `ci/` folder, defining
> a
> basic test pipeline triggered by code pushes to a GitLab-CI instance. This
> initial version includes static checks (checkpatch a
On 21/05/2024 12:58, keith wrote:
> Add INNO common api so that it can be used by vendor
> drivers which implement vendor specific extensions to Innosilicon HDMI.
>
> Signed-off-by: keith
> ---
> MAINTAINERS | 2 +
> +}
> +
> +static u32 inno_hdmi_i2c_func(str
On 21/05/2024 12:58, keith wrote:
> add inno hdmi driver which binds to vs display controller
> and this driver uses the commom api from the inno hdmi
>
> Signed-off-by: keith
> ---
...
> +static int starfive_hdmi_bind(struct device *dev, struct device *master,
> + voi
Hi Krzysztof:
> -Original Message-
> From: Krzysztof Kozlowski
> Sent: 2024年5月21日 15:30
> To: Keith Zhao ; andrzej.ha...@intel.com;
> neil.armstr...@linaro.org; rf...@kernel.org;
> laurent.pinch...@ideasonboard.com; jo...@kwiboo.se;
> jernej.skra...@gmail.com; maarten.lankho...@linux.inte
On Thu, 09 May 2024, nerdopolis wrote:
> Hi
>
> So I have been made aware of an apparent race condition of some drivers
> taking a bit longer to load, which could lead to a possible race condition of
> display servers/greeters using the simpledrm device, and then experiencing
> problems once th
From: Tvrtko Ursulin
Kernel test robot reports i915 can hit a warn in kvmalloc_node which has
a purpose of dissalowing crazy size kernel allocations. This was added in
7661809d493b ("mm: don't allow oversized kvmalloc() calls"):
/* Don't even allow crazy sizes */
if (WARN_ON_ONCE(s
Hi,
Here's a series that creates some extra infrastructure specifically
targeted at HDMI controllers.
The idea behind this series came from a recent discussion on IRC during
which we discussed infoframes generation of i915 vs everything else.
Infoframes generation code still requires some decent
A lot of the various HDMI drivers duplicate some logic that depends on
the HDMI spec itself and not really a particular hardware
implementation.
Output BPC or format selection, infoframe generation are good examples
of such areas.
This creates a lot of boilerplate, with a lot of variations, which
We'll need to use drm_mode_obj_find_prop_id() for kunit tests to make
sure a given property has been properly created. Let's export it for
tests only.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_mode_object.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/drm_mode_o
The next features we will need to share across drivers will need to
store some parameters for drivers to use, such as the selected output
format.
Let's create a new connector sub-state dedicated to HDMI controllers,
that will eventually store everything we need.
Reviewed-by: Dave Stevenson
Revie
We'll add automatic selection of the output BPC in a following patch,
but let's add it to the HDMI connector state already.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/display/drm_hdmi_state_helper.c | 20
drivers/gpu/drm/drm_atomic.c
We just introduced a new initialization function for our connectors, so
let's build a kunit test suite for it as well.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_connector_test.c | 123 +
1 file changed, 123 insertions(+)
A lot of HDMI drivers have some variation of the formula to calculate
the TMDS character rate from a mode, but few of them actually take all
parameters into account.
Let's create a helper to provide that rate taking all parameters into
account.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime R
Most HDMI drivers have some code to calculate the TMDS character rate,
usually to adjust an internal clock to match what the mode requires.
Since the TMDS character rates mostly depends on the resolution, whether
we need to repeat pixels or not, the bpc count and the format, we can
now derive it f
The previous patch stores in the connector state the expected TMDS
character rate matching the configuration of the HDMI connector. Let's
add a few tests to make sure it works as expected.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_hdmi_state_helper_t
Now that we're tracking the output bpc count in the connector state,
let's add a few tests to make sure it works as expected.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/Kconfig| 1 +
drivers/gpu/drm/tests/Makefile
Just like BPC, we'll add support for automatic selection of the output
format for HDMI connectors.
Let's add the needed defaults and fields for now.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/display/drm_hdmi_state_helper.c| 3 ++-
drivers/gpu/drm/drm_ato
The previous patch added an helper to compute the TMDS character rate on
an HDMI connector. Let's add a few tests to make sure it works as
expected.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_connector_test.c | 296 +
1 fil
Most of the HDMI controllers have an upper TMDS character rate limit
they can't exceed. On "embedded"-grade display controllers, it will
typically be lower than what high-grade monitors can provide these days,
so drivers will filter the TMDS character rate based on the controller
capabilities.
To
The previous commit added the infrastructure to the connector state to
track what RGB Quantization should be used in a given state for an HDMI
connector.
Let's add some kunit tests to make sure it works as expected.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/t
The previous patch added the bpc and format an HDMI connector needs to
be set up with for a given connector state.
Let's add a few tests to make sure it works as expected.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c | 509 +
drivers/gp
The previous patch added the generation of the infoframes matching an
HDMI connector state. Let's add a few tests to make sure it works as
expected.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_connector_test.c | 219 +
1 file changed, 219 insertions(+)
Now that we track the HDMI output format as part of the connector state,
let's add a few tests to make sure it works as expected.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_connector_test.c | 99 +-
drivers/gpu/drm/tests/dr
There has been some discussions recently about the infoframes sent by
drivers and if they were properly generated.
In parallel, there's been some interest in creating an infoframe-decode
tool similar to edid-decode.
Both would be much easier if we were to expose the infoframes programmed
in the h
The i915 driver has a property to force the RGB range of an HDMI output.
The vc4 driver then implemented the same property with the same
semantics. KWin has support for it, and a PR for mutter is also there to
support it.
Both drivers implementing the same property with the same semantics,
plus th
Infoframes in KMS is usually handled by a bunch of low-level helpers
that require quite some boilerplate for drivers. This leads to
discrepancies with how drivers generate them, and which are actually
sent.
Now that we have everything needed to generate them in the HDMI
connector state, we can gen
Now that we have all the infrastructure needed, we can add some code
that will, for a given connector state and mode, compute the best output
format and bpc.
The algorithm is equivalent to the one already found in i915 and vc4.
Cc: Ville Syrjälä
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm
The new HDMI connector infrastructure allows to remove some boilerplate,
especially to generate infoframes. Let's switch to it.
Reviewed-by: Jernej Skrabec
Acked-by: Sui Jingfeng
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/Kconfig | 3 ++
drivers/gpu/drm/sun4i/sun4i_hdmi_e
The new HDMI connector infrastructure allows to remove some boilerplate,
especially to generate infoframes. Let's switch to it.
Reviewed-by: Heiko Stuebner
Acked-by: Heiko Stuebner
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/Kconfig | 3 +
drivers/gpu/drm/rockchip/inno_hd
This had a bunch of kunit tests to make sure our code to handle the
Broadcast RGB property behaves properly.
This requires bringing a bit of infrastructure to create mock HDMI
connectors, with custom EDIDs.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_
Now that we have a plane create helper for kunit mocked drivers, let's
convert to it in vc4.
Reviewed-by: Maíra Canal
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/tests/vc4_mock_plane.c | 34 +++---
1 file changed, 8 insertions(+), 26 deletions(-)
diff --git a/d
The vc4_dummy_plane structure was introduced as a mean to add
mock-specific fields.
However, we never really used it and it's still strictly equivalent to
vc4_plane (which is in the same situation vs drm_plane), so we can
simply remove the vc4_dummy_plane structure and make the mock code
cleaner.
The new HDMI connector infrastructure allows us to remove a lot of
boilerplate, so let's switch to it.
Acked-by: Sui Jingfeng
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/Kconfig| 1 +
drivers/gpu/drm/vc4/vc4_hdmi.c | 644 +
drivers/gpu/
HDMI controller drivers will need to figure out the RGB range they need
to configure based on a mode and property values. Let's expose that in
the HDMI connector state so drivers can just use that value.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/display/drm_hd
The previous patch adds a new hook for HDMI connectors to filter out
configurations based on the TMDS character rate. Let's add some tests to
make sure it works as expected.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c | 65
On Fri, 10 May 2024 at 12:19, Tomi Valkeinen
wrote:
>
> Hi,
>
> On 03/05/2024 16:45, Ulf Hansson wrote:
> > + Abel, Saravanna, Stephen
> >
> > On Mon, 15 Apr 2024 at 19:17, Tomi Valkeinen
> > wrote:
> >>
> >> On 15/04/2024 19:00, Tomi Valkeinen wrote:
> >>> Add a new flag, TI_SCI_PD_KEEP_BOOT_STA
Hi Mikhail,
Thanks for the report. I will look into it this week and get back to you.
-Vasant
On 5/21/2024 3:09 PM, Mikhail Gavrilov wrote:
> Hi,
> Yesterday on the fresh kernel snapshot
> I spotted a new bug message with follow stacktrace:
> [4.307097] BUG: sleeping function called from in
The ddc-i2c-bus property should be placed in connector node,
mark the HDMI TX side property as deprecated.
Signed-off-by: Marek Vasut
---
Cc: Andrzej Hajda
Cc: Conor Dooley
Cc: Daniel Vetter
Cc: David Airlie
Cc: Fabio Estevam
Cc: Jernej Skrabec
Cc: Jonas Karlman
Cc: Krzysztof Kozlowski
Cc
Hi Nirmoy,
On Fri, May 17, 2024 at 10:13:37PM +0200, Nirmoy Das wrote:
> Hi Andi,
>
> On 5/17/2024 9:34 PM, Andi Shyti wrote:
>
> Hi Nirmoy,
>
> On Fri, May 17, 2024 at 04:00:02PM +0200, Nirmoy Das wrote:
>
> On 5/17/2024 1:25 PM, Andi Shyti wrote:
>
> If we timeou
Am 17.05.24 um 17:46 schrieb Alex Deucher:
On Fri, May 17, 2024 at 2:35 AM Christian König
wrote:
Am 16.05.24 um 19:57 schrieb Tim Van Patten:
From: Tim Van Patten
The following commit updated gmc->noretry from 0 to 1 for GC HW IP
9.3.0:
commit 5f3854f1f4e2 ("drm/amdgpu: add more case
On Mon, 20 May 2024, Maíra Canal wrote:
> On 5/12/24 19:23, Maíra Canal wrote:>
>> Maíra Canal (6):
>>drm/v3d: Add Performance Counters descriptions for V3D 4.2 and 7.1
>>drm/v3d: Different V3D versions can have different number of perfcnt
>>drm/v3d: Create a new V3D parameter for the
Hi, Thorsten here, the Linux kernel's regression tracker. Top-posting
for once, to make this easily accessible to everyone.
Hmm, from here it looks like the patch now that it was reviewed more
that a week ago is still not even in -next. Is there a reason?
I know, we are in the merge window. But a
In the meantime I have contacted everyone who could have something to do
with it:
Kernel groups
System D
Nvidia
And gues: Everyone says it's not their fault.
But we don't give up. Linux is such a beautiful and solid system. Why
would it work with Windows and not Linux?
Our analysis has now d
Am 18.05.24 um 19:47 schrieb Christophe JAILLET:
This is an effort to get rid of all multiplications from allocation
functions in order to prevent integer overflows [1][2].
The "struct dma_fence_array" can be refactored to add a flex array in order
to have the "callback structures allocated behi
In the meantime I have contacted everyone who could have something to do
with it:
Kernel groups
System D
Nvidia
And gues: Everyone says it's not their fault.
But we don't give up. Linux is such a beautiful and solid system. Why
would it work with Windows and not Linux?
Our analysis has now d
On Fri, May 17, 2024 at 10:18:50AM +0200, Philipp Zabel wrote:
> On Do, 2024-05-16 at 19:20 +0200, Lucas Stach wrote:
> > Am Freitag, dem 26.01.2024 um 17:46 +0100 schrieb Lucas Stach:
> > > The etnaviv devcoredump is created in the GPU reset path, which
> > > must make forward progress to avoid st
On Thu, May 16, 2024 at 11:12:19PM +0100, Adrián Larumbe wrote:
> Hi Daniel,
>
> On 02.05.2024 10:09, Daniel Vetter wrote:
> > On Wed, May 01, 2024 at 07:50:43PM +0100, Adrián Larumbe wrote:
> > > Up to this day, all fdinfo-based GPU profilers must traverse the entire
> > > /proc directory structu
Hi Jani,
On 5/21/24 08:07, Jani Nikula wrote:
On Mon, 20 May 2024, Maíra Canal wrote:
On 5/12/24 19:23, Maíra Canal wrote:>
Maíra Canal (6):
drm/v3d: Add Performance Counters descriptions for V3D 4.2 and 7.1
drm/v3d: Different V3D versions can have different number of perfcnt
drm/
On Mon, May 20, 2024 at 02:01:48PM +0200, Luca Ceresoli wrote:
> Hello Daniel,
>
> On Thu, 16 May 2024 15:22:01 +0200
> Daniel Vetter wrote:
>
> > Apologies for missing v1 ...
> >
> > On Fri, May 10, 2024 at 09:10:36AM +0200, Luca Ceresoli wrote:
> > > DRM hotplug bridge driver
> > > ==
On Thu, May 16, 2024 at 09:51:35AM -0700, John Stultz wrote:
> On Thu, May 16, 2024 at 3:56 AM Daniel Vetter wrote:
> > On Wed, May 15, 2024 at 11:42:58AM -0700, John Stultz wrote:
> > > But it makes me a little nervous to add a new generic allocation flag
> > > for a feature most hardware doesn't
On Thu, May 16, 2024 at 08:33:24PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Make life easier for drivers by filtering out unwanted YCbCr 4:2:0
> only modes prior to calling the connector->mode_valid() hook.
> Currently drivers will still see YCbCr 4:2:0 only modes in said
> hook, whi
On Sat, May 18, 2024 at 10:46:01AM +0200, Tomeu Vizoso wrote:
> Hi,
>
> I would like to use the chance at the next Plumbers to discuss the
> present challenges related to ML accelerators in mainline.
>
> I'm myself more oriented towards edge-oriented deployments, and don't
> know enough about how
On Mon, May 13, 2024 at 10:08:38AM +0200, José Expósito wrote:
> On Fri, May 10, 2024 at 06:19:45PM +0200, Louis Chauvet wrote:
> > Le 09/05/24 - 18:18, Jim Shargo a écrit :
> > > Sima--thanks SO MUCH for going through with everything leaving a
> > > detailed review. I am excited to go through your
Hi Marek,
Thank you for the patch.
On Tue, May 21, 2024 at 12:40:47PM +0200, Marek Vasut wrote:
> The ddc-i2c-bus property should be placed in connector node,
> mark the HDMI TX side property as deprecated.
>
> Signed-off-by: Marek Vasut
> ---
> Cc: Andrzej Hajda
> Cc: Conor Dooley
> Cc: Dani
On Mon, May 20, 2024 at 12:05:14PM +0200, Jacek Lawrynowicz wrote:
> From: "Wachowski, Karol"
>
> Lack of check for copy-on-write (COW) mapping in drm_gem_shmem_mmap
> allows users to call mmap with PROT_WRITE and MAP_PRIVATE flag
> causing a kernel panic due to BUG_ON in vmf_insert_pfn_prot:
> B
On 21/05/2024 14:29, Laurent Pinchart wrote:
Hi Marek,
Thank you for the patch.
On Tue, May 21, 2024 at 12:40:47PM +0200, Marek Vasut wrote:
The ddc-i2c-bus property should be placed in connector node,
mark the HDMI TX side property as deprecated.
Signed-off-by: Marek Vasut
---
Cc: Andrzej H
On Mon, 13 May 2024 04:16:04 +0200, Marek Vasut wrote:
> TC9595 datasheet Video Path0 Control (VPCTRL0) Register bit FRMSYNC
> description
> says "This bit should be disabled only in video mode transmission where Host
> transmits video timing together with video data and where pixel clock source
>
Hey,
Thanks for spinning another few revisions.
On Tue, May 21, 2024 at 9:51 AM kuro wrote:
>
> From: Kuro Chung
>
> When the system power resumes, the TTL input of IT6505 may experience
> some noise before the video signal stabilizes, necessitating a video
> reset. This patch is implemented to
On 2024-04-26 09:01:37 [+0200], To dri-devel@lists.freedesktop.org wrote:
> On 2024-04-04 12:25:36 [+0200], To dri-devel@lists.freedesktop.org wrote:
> > PREEMPT_RT has a different locking implementation for ww_mutex. The
> > base mutex of struct ww_mutex is declared as struct WW_MUTEX_BASE. The
>
1 - 100 of 187 matches
Mail list logo
