er parentheses in write in serialiser_on().
> - Link to v2:
> https://lore.kernel.org/r/20250623-microchip-lvds-v2-1-8ecbabc6a...@microchip.com
>
> Changes in v2:
> - Switch to atomic bridge functions
> - Drop custom connector creation
> - Use drm_atomic_get_new_connecto
https://bugzilla.kernel.org/show_bug.cgi?id=219492
--- Comment #4 from Shubhra Prakash Nandi (email2shub...@gmail.com) ---
Since the issue is still not resolved. The below bug is the better one to
track.
https://gitlab.freedesktop.org/drm/amd/-/issues/4152
--
You may reply to this email to add
在 6/24/2025 10:37 AM, Dmitry Baryshkov 写道:
> On Sun, Jun 22, 2025 at 07:08:20PM +0530, Ling Xu wrote:
>> The fastrpc driver has support for 5 types of remoteprocs. There are
>> some products which support GDSP remoteprocs. Add changes to support
>> GDSP remoteprocs.
>
> Please don't mix code refac
在 6/23/2025 6:28 PM, Konrad Dybcio 写道:
> On 6/22/25 3:38 PM, Ling Xu wrote:
>> The fastrpc driver has support for 5 types of remoteprocs. There are
>> some products which support GDSP remoteprocs. Add changes to support
>> GDSP remoteprocs.
>
> Commit messages saying "add changes to support xyz" o
Add cdns_mhdp_bridge_mode_valid() to check if specific mode is valid for
this bridge or not. In the legacy !(DBANC) usecase, we were using the hook
from drm_connector_helper_funcs but with removal of legacy code, we need
to have mode_valid() in drm_bridge_funcs.
Fixes: c932ced6b585 ("drm/tidss: Up
After adding DBANC framework, mhdp->connector is not initialised during
bridge_attach(). The connector is however required in few driver calls
like cdns_mhdp_hdcp_enable() and cdns_mhdp_modeset_retry_fn().
Use drm_connector pointer instead of structure, set it in bridge_enable()
and clear it in bri
In case if we get errors in cdns_mhdp_link_up() or cdns_mhdp_reg_read()
in atomic_enable, we will go to cdns_mhdp_modeset_retry_fn() and will hit
NULL pointer while trying to access the mutex. We need the connector to
be set before that. Unlike in legacy !(DBANC) cases, we do not have
connector ini
On Fri, Jun 20, 2025 at 11:28 AM Heiko Stuebner wrote:
>
> Am Freitag, 6. Juni 2025, 08:28:20 Mitteleuropäische Sommerzeit schrieb Tomeu
> Vizoso:
> > This series adds a new driver for the NPU that Rockchip includes in its
> > newer SoCs, developed by them on the NVDLA base.
> >
> > In its curren
> -Original Message-
> From: Murthy, Arun R
> Sent: Tuesday, June 24, 2025 10:18 AM
> To: Kandpal, Suraj ; intel...@lists.freedesktop.org;
> intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> nouv...@lists.freedesktop.org
> Subject: RE: [PATCH v3 11/13] drm/i915/backlig
Hello Doug,
On 23/06/25 21:00, Doug Anderson wrote:
Hi,
On Mon, Jun 16, 2025 at 9:24 AM Doug Anderson wrote:
Hi,
On Mon, Jun 16, 2025 at 2:32 AM Jayesh Choudhary wrote:
@@ -1220,6 +1231,27 @@ static void ti_sn65dsi86_debugfs_init(struct drm_bridge
*bridge, struct dentry *
debug
By default, HPD was disabled on SN65DSI86 bridge. When the driver was
added (commit "a095f15c00e27"), the HPD_DISABLE bit was set in pre-enable
call which was moved to other function calls subsequently.
Later on, commit "c312b0df3b13" added detect utility for DP mode. But with
HPD_DISABLE bit set,
On 6/24/25 02:47, Mario Limonciello wrote:
From: Mario Limonciello
The inline pci_is_display() helper does the same thing. Use it.
Reviewed-by: Daniel Dadap
Reviewed-by: Simona Vetter
Suggested-by: Bjorn Helgaas
Signed-off-by: Mario Limonciello
Reviewed-by: Lu Baolu
> -Original Message-
> From: Kandpal, Suraj
> Sent: Friday, June 20, 2025 12:05 PM
> To: intel...@lists.freedesktop.org; intel-...@lists.freedesktop.org; dri-
> de...@lists.freedesktop.org; nouv...@lists.freedesktop.org
> Cc: Murthy, Arun R ; Kandpal, Suraj
>
> Subject: [PATCH v3 03/13] d
From: Rob Clark
[ Upstream commit 5d319f75ccf7f0927425a7545aa1a22b3eedc189 ]
In error paths, we could unref the submit without calling
drm_sched_entity_push_job(), so msm_job_free() will never get
called. Since drm_sched_job_cleanup() will NULL out the
s_fence, we can use that to detect this ca
From: Rob Clark
[ Upstream commit 5d319f75ccf7f0927425a7545aa1a22b3eedc189 ]
In error paths, we could unref the submit without calling
drm_sched_entity_push_job(), so msm_job_free() will never get
called. Since drm_sched_job_cleanup() will NULL out the
s_fence, we can use that to detect this ca
On Tue Jun 24, 2025 at 6:01 AM JST, Danilo Krummrich wrote:
> There's one thing that would be nice to fix subsequently, which is properly
> resetting the GPU. Currently, it needs a power cycle to be able to probe
> successfully after unbinding the driver.
Yes, what I usually do is the following af
On Sun, Jun 22, 2025 at 07:08:20PM +0530, Ling Xu wrote:
> The fastrpc driver has support for 5 types of remoteprocs. There are
> some products which support GDSP remoteprocs. Add changes to support
> GDSP remoteprocs.
Please don't mix code refactoring with adding new features. Split this
patch ac
On Mon, Jun 16, 2025 at 03:07:23PM +0200, Christian König wrote:
> Unlocking the resv object was missing in the error path, additionally to
> that we should move over the resource only after the fence slot was
> reserved.
>
> Signed-off-by: Christian König
Fixes tag?
You probably can merge this
On Mon, Jun 23, 2025 at 6:54 PM Christian König
wrote:
>
> On 6/19/25 09:20, Dave Airlie wrote:
> > From: Dave Airlie
> >
> > While discussing memcg intergration with gpu memory allocations,
> > it was pointed out that there was no numa/system counters for
> > GPU memory allocations.
> >
> > With
On Fri, 20 Jun 2025 09:16:16 +0800, Chaoyi Chen wrote:
> The bridge used in drm_connector_hdmi_audio_init() does not correctly
> point to the required audio bridge, which lead to incorrect audio
> configuration input.
>
>
Applied to drm-misc-fixes, thanks!
[1/1] drm/bridge-connector: Fix bridge
On Thu, 19 Jun 2025 05:30:52 + "Kasireddy, Vivek"
wrote:
> Hi Andrew, Anshuman,
>
> > Subject: Re: [PATCH] mm/hugetlb: Don't crash when allocating a folio if
> > there
> > are no resv
> >
> > On Wed, 18 Jun 2025 12:14:49 +0530 Anshuman Khandual
> > wrote:
> >
> > > > Therefore, prevent
Hi Ian,
On Thu, Apr 03, 2025 at 01:24:35PM -0700, Ian Rogers wrote:
> DRM clients expose information through usage stats as documented in
> Documentation/gpu/drm-usage-stats.rst (available online at
> https://docs.kernel.org/gpu/drm-usage-stats.html). Add a tool like
> PMU, similar to the hwmon PM
On Mon Jun 23, 2025 at 7:11 PM CEST, Boqun Feng wrote:
> On Mon, Jun 23, 2025 at 05:14:37PM +0200, Benno Lossin wrote:
>> On Mon Jun 23, 2025 at 4:47 PM CEST, Boqun Feng wrote:
>> > On Mon, Jun 23, 2025 at 03:44:58PM +0200, Benno Lossin wrote:
>> >> I didn't have a concrete API in mind, but after h
On Mon, Jun 9, 2025 at 2:22 PM Guilherme Giacomo Simoes
wrote:
>
> Commit 38559da6afb2 ("rust: module: introduce `authors` key") introduced
> a new `authors` key to support multiple module authors, while keeping
> the old `author` key for backward compatibility.
>
> Now that all in-tree modules ha
The assignment to ts is missing on the call to ktime_to_timespec64.
Fix this by adding the missing assignment.
Fixes: db6a94b26354 ("drm/vmwgfx: Implement dma_fence_ops properly")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 2 +-
1 file changed, 1 insertion(+), 1 de
On 6/23/25 2:13 PM, Rodrigo Siqueira wrote:
> On 06/23, Werner Sembach wrote:
>> gentle bump
>>
>> Am 09.04.25 um 18:27 schrieb Werner Sembach:
>>> The display backlight on TUXEDO Polaris AMD Gen2 and Gen3 with panels
>>> BOE 2420 and BOE 2423 must be forced to pwn controlled to be able to
>>> cont
From: Mario Limonciello
The inline pci_is_display() helper does the same thing. Use it.
Reviewed-by: Daniel Dadap
Reviewed-by: Simona Vetter
Suggested-by: Bjorn Helgaas
Signed-off-by: Mario Limonciello
---
drivers/iommu/intel/iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
d
On Mon, Jun 23, 2025 at 05:14:37PM +0200, Benno Lossin wrote:
> On Mon Jun 23, 2025 at 4:47 PM CEST, Boqun Feng wrote:
> > On Mon, Jun 23, 2025 at 03:44:58PM +0200, Benno Lossin wrote:
> >> I didn't have a concrete API in mind, but after having read the
> >> abstractions more, would this make sense
0d6b..f369da5b12fb876f23eda8ea7665990919f3960c
100644
--- a/rust/kernel/drm/mod.rs
+++ b/rust/kernel/drm/mod.rs
@@ -7,6 +7,7 @@
pub mod file;
pub mod gem;
pub mod ioctl;
+pub mod mm;
pub use self::device::Device;
pub use self::driver::Driver;
---
base-commit: dc35ddcf97e99b18559d0855071030e664aae44d
change-id: 20250623-topics-tyr-drm_mm-d1d43d436311
Best regards,
--
Daniel Almeida
On 20/06/2025 04:16, Chaoyi Chen wrote:
From: Chaoyi Chen
The bridge used in drm_connector_hdmi_audio_init() does not correctly
point to the required audio bridge, which lead to incorrect audio
configuration input.
Fixes: 231adeda9f67 ("drm/bridge-connector: hook DisplayPort audio support")
Si
This struct element is no longer used.
Signed-off-by: Mel Henning
---
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/ad102.c | 4 ++--
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/gb100.c | 2 +-
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/gb202.c | 2 +-
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/gh100.c | 2 +-
This option was originally intoduced because the GSP code path was
not well tested and we wanted to leave it up to distros which code path
they shipped by default. By now though, the GSP path is probably better
tested than the old firmware eg. Fedora ships GSP by default and we
generally run CTS on
Following earlier discussion at
https://lists.freedesktop.org/archives/nouveau/2025-June/047887.html
this series removes DRM_NOUVEAU_GSP_DEFAULT.
Mel Henning (2):
drm/nouveau: Remove DRM_NOUVEAU_GSP_DEFAULT config
drm/nouveau: Remove nvkm_gsp_fwif.enable
drivers/gpu/drm/nouveau/Kconfig
On Mon, Jun 16, 2025 at 8:07 AM Christian König
wrote:
>
> That is something TTM internal which is about to get dropped.
>
> Signed-off-by: Christian König
Reviewed-by: Ian Forbes
smime.p7s
Description: S/MIME Cryptographic Signature
From: Mario Limonciello
The inline pci_is_display() helper does the same thing. Use it.
Reviewed-by: Takashi Iwai
Reviewed-by: Daniel Dadap
Reviewed-by: Simona Vetter
Suggested-by: Bjorn Helgaas
Signed-off-by: Mario Limonciello
---
sound/hda/hdac_i915.c | 2 +-
sound/pci/hda/hda_intel
6.12-stable review patch. If anyone has any objections, please let me know.
--
From: Thomas Zimmermann
commit 03bcbbb3995ba5df43af9aba45334e35f2dfe27b upstream.
Signal vt subsystem to redraw console when switching to dummycon
with deferred takeover enabled. Makes the console s
6.12-stable review patch. If anyone has any objections, please let me know.
--
From: Thomas Zimmermann
commit 2f29b5c231011b94007d2c8a6d793992f2275db1 upstream.
Apply PCI host-bridge window offsets to screen_info framebuffers. Fixes
invalid access to I/O memory.
Resources beh
On Thu, Jun 19, 2025 at 10:23:44PM +0900, Alexandre Courbot wrote:
Applied to nova-next, thanks!
> Alexandre Courbot (21):
> rust: make ETIMEDOUT error available
> rust: sizes: add constants up to SZ_2G
> gpu: nova-core: use absolute paths in register!() macro
> gpu: nova-
6.6-stable review patch. If anyone has any objections, please let me know.
--
From: Thomas Zimmermann
commit 2f29b5c231011b94007d2c8a6d793992f2275db1 upstream.
Apply PCI host-bridge window offsets to screen_info framebuffers. Fixes
invalid access to I/O memory.
Resources behi
From: Mario Limonciello
The x86 specific check for whether a framebuffer belongs to a device
works for display devices as well as VGA devices. Callers to
video_is_primary_device() can benefit from checking non-VGA display
devices.
Move the x86 specific check into x86 specific code, and adjust V
From: Mario Limonciello
The inline pci_is_display() helper does the same thing. Use it.
Acked-by: Alex Williamson
Reviewed-by: Daniel Dadap
Reviewed-by: Simona Vetter
Suggested-by: Bjorn Helgaas
Signed-off-by: Mario Limonciello
---
drivers/vfio/pci/vfio_pci_igd.c | 3 +--
1 file changed,
Applied. Thanks!
Alex
On Mon, Jun 16, 2025 at 12:09 PM Takashi Iwai wrote:
>
> When EDID is retrieved via drm_edid_raw(), it doesn't guarantee to
> return proper EDID bytes the caller wants: it may be either NULL (that
> leads to an Oops) or with too long bytes over the fixed size raw_edid
> ar
According to the report of Coverity Scan [1], "sync_file" is going to be
NULL when entering the "if" section after "out_post_unlock", so
"fput(sync_file->file)" is never going to be exected in this block.
[1]:
https://scan5.scan.coverity.com/#/project-view/10074/10063?selectedIssue=1655089
Signed
On 06/23, Werner Sembach wrote:
> gentle bump
>
> Am 09.04.25 um 18:27 schrieb Werner Sembach:
> > The display backlight on TUXEDO Polaris AMD Gen2 and Gen3 with panels
> > BOE 2420 and BOE 2423 must be forced to pwn controlled to be able to
> > control the brightness.
> >
> > This could already
From: Mario Limonciello
When compiled without CONFIG_VIDEO the architecture specific
implementations of video_is_primary_device() include prototypes and
assume that video-common.c will be linked. Guard against this so that the
fallback inline implementation that returns false will be used when
co
From: Mario Limonciello
On systems with multiple GPUs there can be uncertainty which GPU is the
primary one used to drive the display at bootup. In order to disambiguate
this add a new sysfs attribute 'boot_display' that uses the output of
video_is_primary_device() to populate whether a PCI devic
From: Mario Limonciello
Several places in the kernel do class shifting to match whether a
PCI device is display class. Introduce a helper for those places to
use.
Reviewed-by: Daniel Dadap
Reviewed-by: Simona Vetter
Signed-off-by: Mario Limonciello
---
include/linux/pci.h | 15 +
From: Mario Limonciello
The inline pci_is_display() helper does the same thing. Use it.
Reviewed-by: Daniel Dadap
Reviewed-by: Simona Vetter
Suggested-by: Bjorn Helgaas
Signed-off-by: Mario Limonciello
---
drivers/gpu/vga/vga_switcheroo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(
From: Mario Limonciello
This series started out as changes to VGA arbiter to try to handle a case
of a system with 2 GPUs that are not VGA devices [1]. This was discussed
but decided not to overload the VGA arbiter for non VGA devices.
Instead move the x86 specific detection of framebuffer reso
On 6/23/25 16:32, Bartosz Golaszewski wrote:
> On Mon, Jun 23, 2025 at 1:44 PM Michal Wilczynski
> wrote:
>>
>> Introduce the pwrseq-thead-gpu driver, a power sequencer provider for
>> the Imagination BXM-4-64 GPU on the T-HEAD TH1520 SoC. This driver
>> controls an auxiliary device instantiate
gentle bump
Am 11.04.25 um 17:55 schrieb Werner Sembach:
The display backlight on TUXEDO DX1708 and InsanityBook 15 v1 with panels
AUO 12701 and AUO 12701 must be forced to INTEL_DP_AUX_BACKLIGHT_ON to be
able to control the brightness.
This could already be archived via a module parameter, but
gentle bump
Am 09.04.25 um 18:27 schrieb Werner Sembach:
The display backlight on TUXEDO Polaris AMD Gen2 and Gen3 with panels
BOE 2420 and BOE 2423 must be forced to pwn controlled to be able to
control the brightness.
This could already be archived via a module parameter, but this patch adds
On Mon, 2025-06-23 at 14:01 +, Krzysztof Karas wrote:
> Hi Jeff,
>
> [...]
> > +static __maybe_unused int
> > +ref_tracker_dir_seq_print(struct ref_tracker_dir *dir, struct seq_file
> > *seq)
> > +{
> > + struct ostream os = { .func = pr_ostream_seq,
> > + .prefix =
On Tue, Jun 17, 2025 at 04:45:22PM +0300, Alexander Usyskin wrote:
> Add driver for access to Intel discrete graphics card
> internal NVM device.
> Expose device on auxiliary bus by i915 and Xe drivers and
> provide mtd driver to register this device with MTD framework.
>
> This is a rewrite of "d
On Thu, Jun 19, 2025 at 7:08 AM Maxime Ripard wrote:
> On Wed, Jun 18, 2025 at 04:45:31PM -0400, Anusha Srivatsa wrote:
> > On Wed, Jun 18, 2025 at 11:48 AM Anusha Srivatsa
> > wrote:
> > > On Wed, Jun 18, 2025 at 4:23 AM Maxime Ripard
> wrote:
> > >
> > >> On Wed, Jun 18, 2025 at 10:51:58AM +0
Hi Jayesh,
Thanks a lot for all your work on this patch. I tested this version on a
board with the broken HPD signal and can confirm that eDP works as
expected anyways.
Tested-by: Ernest Van Hoecke
Kind regards,
Ernest
On 6/23/2025 9:11 AM, Nilawar, Badal wrote:
On 23-06-2025 20:56, Daniele Ceraolo Spurio wrote:
On 6/18/2025 10:52 PM, Nilawar, Badal wrote:
On 19-06-2025 02:35, Daniele Ceraolo Spurio wrote:
On 6/18/2025 12:00 PM, Badal Nilawar wrote:
Reload late binding fw during runtime resume.
v2
Applied. Thanks.
Alex
On Mon, Jun 23, 2025 at 4:41 AM Colin Ian King wrote:
>
> There is a spelling mistake in a pr_info message. Fix it.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/
On Thu, May 29, 2025 at 10:40:12AM +0800, Xilin Wu wrote:
> On 2025/4/24 01:52:45, Dmitry Baryshkov wrote:
> > From: Dmitry Baryshkov
> >
> > The MSM DisplayPort driver implements several HDMI codec functions
> > in the driver, e.g. it manually manages HDMI codec device registration,
> > returnin
On Fri, Jun 20, 2025 at 09:16:16AM +0800, Chaoyi Chen wrote:
> From: Chaoyi Chen
>
> The bridge used in drm_connector_hdmi_audio_init() does not correctly
> point to the required audio bridge, which lead to incorrect audio
> configuration input.
>
> Fixes: 231adeda9f67 ("drm/bridge-connector: ho
On 23-06-2025 20:56, Daniele Ceraolo Spurio wrote:
On 6/18/2025 10:52 PM, Nilawar, Badal wrote:
On 19-06-2025 02:35, Daniele Ceraolo Spurio wrote:
On 6/18/2025 12:00 PM, Badal Nilawar wrote:
Reload late binding fw during runtime resume.
v2: Flush worker during runtime suspend
Signed-o
The era of hand-rolled HIWORD_UPDATE macros is over, at least for those
drivers that use constant masks.
The Rockchip PCIe PHY driver, used on the RK3399, has its own definition
of HIWORD_UPDATE.
Remove it, and replace instances of it with hw_bitfield.h's
FIELD_PREP_WM16. To achieve this, some ma
The sp7021 clock driver has its own shifted high word mask macro,
similar to the ones many Rockchip drivers have.
Remove it, and replace instances of it with hw_bitfield.h's
FIELD_PREP_WM16 macro, which does the same thing except in a common
macro that also does compile-time error checking.
This
The era of hand-rolled HIWORD_UPDATE macros is over, at least for those
drivers that use constant masks.
Like many other Rockchip drivers, rockchip-dfi brings with it its own
HIWORD_UPDATE macro. This variant doesn't shift the value (and like the
others, doesn't do any checking).
Remove it, and r
The era of hand-rolled HIWORD_UPDATE macros is over.
Like many other Rockchip drivers, pcie-dw-rockchip brings with it its
very own flavour of HIWORD_UPDATE. It's occasionally used without a
constant mask, which complicates matters. HIWORD_UPDATE_BIT is a
confusingly named addition, as it doesn't
The era of hand-rolled HIWORD_UPDATE macros is over, at least for those
drivers that use constant masks.
The Rockchip PCI driver, like many other Rockchip drivers, has its very
own definition of HIWORD_UPDATE.
Remove it, and replace its usage with either FIELD_PREP_WM16, or two new
header local m
The era of hand-rolled HIWORD_UPDATE macros is over, at least for those
drivers that use constant masks.
Like many other Rockchip drivers, dwmac-rk has its own HIWORD_UPDATE
macro. Its semantics allow us to redefine it as a wrapper to the shared
hw_bitfield.h FIELD_PREP_WM16 macros though.
Replac
The era of hand-rolled HIWORD_UPDATE macros is over, at least for those
drivers that use constant masks.
Replace the implementation of this driver's HIWORD_UPDATE macro with an
instance of FIELD_PREP_WM16_CONST. The const variant is chosen here
because some of the header defines are then used in i
The era of hand-rolled HIWORD_UPDATE macros is over, at least for those
drivers that use constant masks.
Remove this driver's very own HIWORD_UPDATE macro, and replace all
instances of it with equivalent instantiations of FIELD_PREP_WM16 or
FIELD_PREP_WM16_CONST, depending on whether it's in an in
The era of hand-rolled HIWORD_UPDATE macros is over, at least for those
drivers that use constant masks.
Remove this driver's HIWORD_UPDATE macro, and replace all instances of
it with (hopefully) equivalent FIELD_PREP_WM16 instances. To do this, a
few of the defines are being adjusted, as FIELD_PR
The era of hand-rolled HIWORD_UPDATE macros is over, at least for those
drivers that use constant masks.
The inno-hdmi driver's own HIWORD_UPDATE macro is instantiated only
twice. Remove it, and replace its uses with FIELD_PREP_WM16. Since
FIELD_PREP_WM16 shifts the value for us, we replace using
The era of hand-rolled HIWORD_UPDATE macros is over, at least for those
drivers that use constant masks.
Replace this driver's HIWORD_UPDATE with the FIELD_PREP_WM16 macro from
hw_bitfield.h. While at it, disambiguate the GRF write to SOC_CON7 by
splitting the definition into the individual bitfla
The era of hand-rolled HIWORD_UPDATE macros is over, at least for those
drivers that use constant masks.
phy-rockchip-samsung-dcphy is actually an exemplary example, where the
similarities to FIELD_PREP were spotted and the driver local macro has
the same semantics as the new FIELD_PREP_WM16 hw_bi
The era of hand-rolled HIWORD_UPDATE macros is over, at least for those
drivers that use constant masks.
Remove VOP2's HIWORD_UPDATE macro from the vop2 header file, and replace
all instances in rockchip_vop2_reg.c (the only user of this particular
HIWORD_UPDATE definition) with equivalent FIELD_P
The era of hand-rolled HIWORD_UPDATE macros is over, at least for those
drivers that use constant masks.
Remove this driver's HIWORD_UPDATE macro, and replace instances of it
with either FIELD_PREP_WM16 or FIELD_PREP_WM16_CONST, depending on
whether they're in an initializer. This gives us better
The era of hand-rolled HIWORD_UPDATE macros is over, at least for those
drivers that use constant masks.
Replace the implementation of the rockchip eMMC PHY driver's
HIWORD_UPDATE macro with hw_bitfield.h's FIELD_PREP_WM16. This makes the
change more easily reviewable.
Signed-off-by: Nicolas Frat
On Thu, Jun 19, 2025 at 3:24 PM Alexandre Courbot wrote:
>
> We will use this error in the nova-core driver.
>
> Reviewed-by: Benno Lossin
> Signed-off-by: Alexandre Courbot
Acked-by: Miguel Ojeda
Cheers,
Miguel
The era of hand-rolled HIWORD_UPDATE macros is over, at least for those
drivers that use constant masks.
Remove rockchip_lvds.h's own HIWORD_UPDATE macro, and replace all
instances of it with hw_bitfield.h's FIELD_PREP_WM16 macro, which gives
us more error checking.
For the slightly-less-trivial
On Thu, Jun 19, 2025 at 3:24 PM Alexandre Courbot wrote:
>
> nova-core will need to use SZ_1M, so make the remaining constants
> available.
>
> Reviewed-by: Boqun Feng
> Signed-off-by: Alexandre Courbot
Acked-by: Miguel Ojeda
Cheers,
Miguel
The era of hand-rolled HIWORD_UPDATE macros is over, at least for those
drivers that use constant masks.
Replace the UPDATE macro with bitfield.h's FIELD_PREP, to give us
additional error checking.
Also, replace the HIWORD_UPDATE macro at the same time with the new
FIELD_PREP_WM16 macro in hw_bit
The era of hand-rolled HIWORD_UPDATE macros is over, at least for those
drivers that use constant masks.
Switch the rockchip grf driver to the FIELD_PREP_WM16_CONST macro, which
brings with it more error checking while still being able to be used in
initializers.
All HIWORD_UPDATE instances and i
The era of hand-rolled HIWORD_UPDATE macros is over, at least for those
drivers that use constant masks.
Switch to the new FIELD_PREP_WM16 macro in hw_bitfield.h, which has
error checking. Instead of redefining the driver's HIWORD_UPDATE macro
in this case, replace the two only instances of it wit
Hardware of various vendors, but very notably Rockchip, often uses
32-bit registers where the upper 16-bit half of the register is a
write-enable mask for the lower half.
This type of hardware setup allows for more granular concurrent register
write access.
Over the years, many drivers have hand-
.org/all/aD8hB-qJ4Qm6IFuS@yury/ [1]
Signed-off-by: Nicolas Frattaroli
---
Changes in v2:
- rebase onto next-20250623. This involved solving two conflicts in
pcie-dw-rockchip.
- move new macros to a new hw_bitfield.h, and rename them to
FIELD_PREP_WM16*. All patches in the series have been updated
To avoid duplicating the tricky bo locking implementation,
Implement ttm_lru_walk_for_evict() using the guarded bo LRU iteration.
To facilitate this, support ticketlocking from the guarded bo LRU
iteration.
v2:
- Clean up some static function interfaces (Christian König)
- Fix Handling -EALREADY
Instead of the struct ttm_operation_ctx, Pass a struct ttm_lru_walk_arg
to enable us to easily extend the walk functionality, and to
implement ttm_lru_walk_for_evict() using the guarded LRU iteration.
Signed-off-by: Thomas Hellström
Reviewed-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_ut
Let the locking functions take the new struct ttm_lru_walk_arg
as argument in order for them to be easily used from both
types of walk.
v2:
- Whitespace fix
Signed-off-by: Thomas Hellström
Reviewed-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 24 ++--
drivers
This is a deferred task from the Xe bo shrinker addition.
TTM currently have two separate ways of doing buffer object LRU
walks, of which one is exposed to drivers. Both have their benefits
but we shouldn't be implementing the complex bo locking in
two different places. So implement the ttm_lru_wa
On Thu, Jun 19, 2025 at 10:23:47PM +0900, Alexandre Courbot wrote:
> Sometimes one may want to obtain a DMA handle starting at a given
> offset. This can be done by adding said offset to the result of
> `dma_handle()`, but doing so on the client side carries the risk that
> the operation will go ou
On Thu, Jun 19, 2025 at 10:23:46PM +0900, Alexandre Courbot wrote:
> These properties are very useful to have (and to be used by nova-core)
> and should be accessible.
>
> Signed-off-by: Alexandre Courbot
Applied to alloc-next, thanks!
[ Slightly extend the commit message. - Danilo ]
On Mon, Jun 23, 2025 at 01:37:35PM +0100, Matthew Auld wrote:
> +Matt B who is adding clear-on-free support in xe. I'm not sure if we might
> also see something like this.
>
Thanks for the heads up.
> On 23/06/2025 06:52, Arunpravin Paneer Selvam wrote:
> > - Added a handler in DRM buddy manager
On Thu, Jun 19, 2025 at 10:23:45PM +0900, Alexandre Courbot wrote:
> A word was apparently missing in this sentence.
>
> Signed-off-by: Alexandre Courbot
Applied to alloc-next, thanks!
[ Slightly expand commit subject and add 'Fixes:' tag. - Danilo ]
On 6/18/2025 11:51 PM, Nilawar, Badal wrote:
On 19-06-2025 02:49, Daniele Ceraolo Spurio wrote:
On 6/18/2025 12:00 PM, Badal Nilawar wrote:
Introduce a debug filesystem node to disable late binding fw reload
during the system or runtime resume. This is intended for situations
where the la
+ Harry, Leo
On Mon, Jun 23, 2025 at 9:38 AM Christopher Snowhill wrote:
>
> On Mon Jun 23, 2025 at 4:06 AM PDT, Christopher Snowhill wrote:
> > On Mon Jun 23, 2025 at 3:46 AM PDT, Christopher Snowhill wrote:
> >> On Fri Jun 20, 2025 at 3:10 AM PDT, Christopher Snowhill wrote:
> >>> Here's anothe
Hi,
On Mon, Jun 16, 2025 at 9:24 AM Doug Anderson wrote:
>
> Hi,
>
> On Mon, Jun 16, 2025 at 2:32 AM Jayesh Choudhary wrote:
> >
> > @@ -1220,6 +1231,27 @@ static void ti_sn65dsi86_debugfs_init(struct
> > drm_bridge *bridge, struct dentry *
> > debugfs_create_file("status", 0600, debugf
On 23/06/2025 15:55, Christian König wrote:
On 23.06.25 15:07, Tvrtko Ursulin wrote:
On 23/06/2025 11:24, Khatri, Sunil wrote:
On 6/23/2025 2:58 PM, Tvrtko Ursulin wrote:
On 18/06/2025 14:47, Sunil Khatri wrote:
add support to add a directory for each client-id
with root at the dri leve
On 6/18/2025 10:52 PM, Nilawar, Badal wrote:
On 19-06-2025 02:35, Daniele Ceraolo Spurio wrote:
On 6/18/2025 12:00 PM, Badal Nilawar wrote:
Reload late binding fw during runtime resume.
v2: Flush worker during runtime suspend
Signed-off-by: Badal Nilawar
---
drivers/gpu/drm/xe/xe_lat
Reviewed-by: Christian König for both patches.
On 19.06.25 13:26, Thomas Zimmermann wrote:
> The field import_attach of struct drm_gem_object is often only
> required by PRIME code. In other places, replace its use with
> clearer alternatives.
>
> Thomas Zimmermann (2):
> drm/tegra: Test for i
On 23.06.25 15:07, Tvrtko Ursulin wrote:
>
> On 23/06/2025 11:24, Khatri, Sunil wrote:
>>
>> On 6/23/2025 2:58 PM, Tvrtko Ursulin wrote:
>>>
>>>
>>> On 18/06/2025 14:47, Sunil Khatri wrote:
add support to add a directory for each client-id
with root at the dri level. Since the clients ar
1 - 100 of 191 matches
Mail list logo
