On 11/06/2025 14:01, Michal Wilczynski wrote:
>
> However, this leads me back to a fundamental issue with the
> consumer side implementation in the generic pvr_device.c driver. The
> current fallback code is:
>
> /*
> * If the error is -EPROBE_DEFER, it's because the
> * optional sequencer prov
On 11/06/2025 14:32, Bartosz Golaszewski wrote:
> On Wed, Jun 11, 2025 at 2:01 PM Michal Wilczynski
> wrote:
>>
>>
>>
>> On 6/5/25 10:10, Bartosz Golaszewski wrote:
>>> On Thu, Jun 5, 2025 at 9:47 AM Michal Wilczynski
>>> wrote:
On 6/4/25 14:07, Krzysztof Kozlowski wrote:
Am Donnerstag, dem 12.06.2025 um 15:31 -0700 schrieb Doug Anderson:
> Hi,
>
> On Thu, Jun 12, 2025 at 10:52 AM Doug Anderson wrote:
> >
> > Hi,
> >
> > On Thu, Jun 12, 2025 at 12:35 AM Jayesh Choudhary
> > wrote:
> > >
> > > > > If refclk is described in devicetree node, then I see that
> >
Initialize writeback connector initialising the virtual encoder
and intel connector. We also allocate memory for drm_writeback_connector
but not the drm_connector within it due to a constraint
we need all connectors to be an intel_connector.
The writeback_format arrays is used to tell the user whic
Hi Prabhakar,
> -Original Message-
> From: Prabhakar
> Sent: 30 May 2025 18:19
> Subject: [PATCH v6 4/4] drm: renesas: rz-du: mipi_dsi: Add support for
> RZ/V2H(P) SoC
>
> From: Lad Prabhakar
>
> Add DSI support for Renesas RZ/V2H(P) SoC.
>
> Co-developed-by: Fabrizio Castro
> Signe
Add some preliminary definitions like, output type and transcoder
related to the writeback functionality.
Signed-off-by: Suraj Kandpal
diff --git a/drivers/gpu/drm/i915/display/intel_display.h
b/drivers/gpu/drm/i915/display/intel_display.h
index 3b54a62c290a..ae474cbeb791 100644
--- a/drivers/g
Add writeback registers to its own file.
Signed-off-by: Suraj Kandpal
diff --git a/drivers/gpu/drm/i915/display/intel_writeback_reg.h
b/drivers/gpu/drm/i915/display/intel_writeback_reg.h
new file mode 100644
index ..dd872b6f8103
--- /dev/null
+++ b/drivers/gpu/drm/i915/display/intel
Write a function that takes a preallocated drm_connector instead of
using the one allocated inside the drm writeback connector init
function.
Signed-off-by: Suraj Kandpal
diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
index edbeab88ff2b..0d287ab9bded 100644
--- a/
This series is for review comments only and is not tested.
This series added a helper to be able to initialise writeback connector
in a way where drivers can send their own connector and encoder.
Signed-off-by: Suraj Kandpal
Suraj Kandpal (4):
drm/writeback: Add function that takes preallocate
Hi Prabhakar,
> -Original Message-
> From: Prabhakar
> Sent: 30 May 2025 18:19
.castro...@renesas.com>; Prabhakar Mahadev Lad lad...@bp.renesas.com>
> Subject: [PATCH v6 1/4] clk: renesas: rzv2h-cpg: Add support for DSI clocks
>
> From: Lad Prabhakar
>
> Add support for PLLDSI and PLL
On Thu Jun 12, 2025 at 11:49 PM JST, Benno Lossin wrote:
> On Thu Jun 12, 2025 at 3:27 PM CEST, Alexandre Courbot wrote:
>> On Thu Jun 12, 2025 at 10:17 PM JST, Alexandre Courbot wrote:
>>> On Wed Jun 4, 2025 at 4:18 PM JST, Benno Lossin wrote:
On Wed Jun 4, 2025 at 2:05 AM CEST, Alexandre Cou
From: Mingcong Bai
As this component hooks into userspace API, it should be assumed that it
will play well with non-4KiB/64KiB pages.
Use `PAGE_SIZE' as the final reference for page alignment instead.
Cc: sta...@vger.kernel.org
Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel
From: Mingcong Bai
Similar to the preceding patch for GuC (and with the same references),
Intel GPUs expects command buffers to align to 4KiB boundaries.
Current code uses `PAGE_SIZE' as an assumed alignment reference but 4KiB
kernel page sizes is by no means a guarantee. On 16KiB-paged kernels,
From: Mingcong Bai
The bo/ttm interfaces with kernel memory mapping from dedicated GPU
memory. It is not correct to assume that SZ_4K would suffice for page
alignment as there are a few hardware platforms that commonly uses non-
4KiB pages - for instance, 16KiB is the most commonly used kernel pa
Hi Lucas
在 2025/6/13 08:13, Lucas De Marchi 写道:
For some reason this patch series didn't make it to any mailing
list... it only shows the b4-sent and stable:
https://lore.kernel.org/intel-xe/20250604-upstream-xe-non-4k-v2-v2-0-
ce7905da7...@aosc.io/
Could you resend this series?
That's stra
From: Mingcong Bai
Per the "Firmware" chapter in "drm/xe Intel GFX Driver", as well as
"Volume 8: Command Stream Programming" in "Intel® Arc™ A-Series Graphics
and Intel Data Center GPU Flex Series Open-Source Programmer's Reference
Manual For the discrete GPUs code named "Alchemist" and "Arctic
This patch series attempts to enable the use of xe DRM driver on non-4KiB
kernel page platforms. This involves fixing the ttm/bo interface, as well
as parts of the userspace API to make use of kernel `PAGE_SIZE' for
alignment instead of the assumed `SZ_4K', it also fixes incorrect usage of
`PAGE_SI
From: Mingcong Bai
It appears that the xe_res_cursor also assumes 4KiB alignment.
Current implementation uses `PAGE_SIZE' as an assumed alignment reference,
but 4KiB kernel page sizes is by no means a guarantee. On 16KiB-paged
kernels, this causes driver failures during boot up:
[ 23.242757]
For some reason this patch series didn't make it to any mailing
list... it only shows the b4-sent and stable:
https://lore.kernel.org/intel-xe/20250604-upstream-xe-non-4k-v2-v2-0-ce7905da7...@aosc.io/
Could you resend this series?
thanks
Lucas De Marchi
On Wed, Jun 04, 2025 at 10:57:54AM +0800,
On Thu, Jun 12, 2025 at 09:00:34AM +0200, Christian König wrote:
> On 6/11/25 17:11, Danilo Krummrich wrote:
> Mhm, reiterating our internal discussion on the mailing list.
>
> I think it would be nicer if we could use negative values for the kernel
> submissions and positive f
On Thu, Jun 12, 2025 at 03:15:31PM +0100, Lorenzo Stoakes wrote:
> On Thu, May 29, 2025 at 04:32:04PM +1000, Alistair Popple wrote:
> > Previously dax pages were skipped by the pagewalk code as pud_special() or
> > vm_normal_page{_pmd}() would be false for DAX pages. Now that dax pages are
> > refc
Hi,
On Thu, Jun 12, 2025 at 10:52 AM Doug Anderson wrote:
>
> Hi,
>
> On Thu, Jun 12, 2025 at 12:35 AM Jayesh Choudhary wrote:
> >
> > >> If refclk is described in devicetree node, then I see that
> > >> the driver modifies it in every resume call based solely on the
> > >> clock value in dts.
>
On Thu, 12 Jun 2025 16:10:37 -0400 Yury Norov wrote:
> I don't think that that having HWORD_UPDATE() in bitfield.h is a wrong
> thing. Jakub, if you do, we can just create a new header for it.
Yes, I'd prefer to contain it. This looks very much like a CSR tooling
convention of Rockchip's ASIC deve
On 6/6/2025 10:57 AM, 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 late binding fw needs to be loaded from user mode.
Can you clarify a bit what the use-case here is? Be
On 6/12/25 10:16, Thomas Zimmermann wrote:
Fix the compile-time warning
drivers/video/fbdev/via/via-gpio.c: warning: EXPORT_SYMBOL() is not used, but
#include is present
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/via/via-gpio.c | 1 -
1 file changed, 1 deletion(-)
Revie
On 6/12/25 10:16, Thomas Zimmermann wrote:
Fix the compile-time warning
drivers/video/fbdev/mb862xx/mb862xx-i2c.c: warning: EXPORT_SYMBOL() is not used,
but #include is present
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/mb862xx/mb862xx-i2c.c | 1 -
1 file changed, 1 delet
On 6/12/25 10:16, Thomas Zimmermann wrote:
Fix the compile-time warnings
drivers/video/fbdev/via/via-core.c: warning: EXPORT_SYMBOL() is used, but #include
is missing
drivers/video/fbdev/via/via_i2c.c: warning: EXPORT_SYMBOL() is used, but #include
is missing
Signed-off-by: Thomas Zim
On 6/12/25 10:16, Thomas Zimmermann wrote:
Fix the compile-time warning
drivers/video/fbdev/sis/sis_main.c: warning: EXPORT_SYMBOL() is used, but #include
is missing
The affected symbols are not used outside of their module. Some of
the symbols are not used anywhere, so remove the function
On 6/12/25 10:16, Thomas Zimmermann wrote:
Fix the compile-time warning
drivers/video/fbdev/pxafb.c: warning: EXPORT_SYMBOL() is used, but #include
is missing
The affected symbol is not used anywhere, so remove the function
entirely.
v2:
- remove unused functions (Helge)
Signed-off-by: T
On 6/12/25 10:16, Thomas Zimmermann wrote:
Fix the compile-time warning
drivers/video/fbdev/cyber2000fb.c: warning: EXPORT_SYMBOL() is used, but #include
is missing
The affected symbols are not used anywhere, so remove the functions
entirely.
v2:
- remove unused functions (Helge)
Signed-
On 6/12/25 10:16, Thomas Zimmermann wrote:
Fix the compile-time warnings
drivers/video/fbdev/omap2/omapfb/dss/dpi.c: warning: EXPORT_SYMBOL() is not used,
but #include is present
drivers/video/fbdev/omap2/omapfb/dss/sdi.c: warning: EXPORT_SYMBOL() is not used,
but #include is present
On 6/12/25 10:16, Thomas Zimmermann wrote:
Fix the compile-time warnings
drivers/video/fbdev/omap2/omapfb/dss/apply.c: warning: EXPORT_SYMBOL() is used,
but #include is missing
drivers/video/fbdev/omap2/omapfb/dss/core.c: warning: EXPORT_SYMBOL() is used, but
#include is missing
dri
On 6/12/2025 5:32 PM, Jens Glathe wrote:
> On 6/11/25 13:15, Akhil P Oommen wrote:
>
>> Add support for X1-45 GPU found in X1P41200 chipset (8 cpu core
>> version). X1-45 is a smaller version of X1-85 with lower core count and
>> smaller memories. From UMD perspective, this is similar to "FD735"
>
On Thu, 12 Jun 2025 05:29:55 PDT (-0700), lijo.la...@amd.com wrote:
On 6/11/2025 10:30 AM, Lazar, Lijo wrote:
On 6/11/2025 2:51 AM, Palmer Dabbelt wrote:
From: Palmer Dabbelt
9KiB frames seem pretty big, but without this I'm getting some warnings
as of 6.16-rc1
CC [M] drivers/gpu/
_dp_aux_bus
> > snd_soc_lpass_tx_macro qcom_glink_smem gpucc_qcm2290 snd_soc_pm4125
> > mdt_loader snd_soc_lpass_macro_common qmi_helpers snd_soc_pm4125_sdw
> > soundwire_qcom regmap_sdw slimbus qcom_pmic_tcpm qcom_usb_vbus_regulator
> > drm_client_lib tcpm rtc_pm8xx
>> Reported-by: kernel test robot
>> Closes:
>> https://lore.kernel.org/oe-kbuild-all/202506100312.ms4xgazw-...@intel.com/
>
> As the patch wasn't merged yet, don't add these two kernel-bot-related lines.
Can such information eventually be omitted also by a final committer
(maintainer)?
Regar
On Thu, Jun 12, 2025 at 01:08:25PM -0700, John Hubbard wrote:
> On 6/12/25 1:05 PM, Boqun Feng wrote:
> > On Thu, Jun 12, 2025 at 01:00:12PM -0700, John Hubbard wrote:
> >> On 6/12/25 8:07 AM, Boqun Feng wrote:
> >>> On Thu, Jun 12, 2025 at 11:01:32PM +0900, Alexandre Courbot wrote:
> >> ...
>
On Thu, Jun 12, 2025 at 01:00:12PM -0700, John Hubbard wrote:
> On 6/12/25 8:07 AM, Boqun Feng wrote:
> > On Thu, Jun 12, 2025 at 11:01:32PM +0900, Alexandre Courbot wrote:
> ...
> >> +#[inline(always)]
> >> +pub const fn align_down(self, value: $t) -> $t {
> >
> >
On Thu, Jun 12, 2025 at 09:50:12PM +0200, Nicolas Frattaroli wrote:
> On Thursday, 12 June 2025 21:44:15 Central European Summer Time Jakub
> Kicinski wrote:
> > On Thu, 12 Jun 2025 20:56:03 +0200 Nicolas Frattaroli wrote:
> > > Hardware of various vendors, but very notably Rockchip, often uses
>
On 6/12/25 1:05 PM, Boqun Feng wrote:
> On Thu, Jun 12, 2025 at 01:00:12PM -0700, John Hubbard wrote:
>> On 6/12/25 8:07 AM, Boqun Feng wrote:
>>> On Thu, Jun 12, 2025 at 11:01:32PM +0900, Alexandre Courbot wrote:
>> ...
+#[inline(always)]
+pub const fn ali
On 6/12/25 8:07 AM, Boqun Feng wrote:
> On Thu, Jun 12, 2025 at 11:01:32PM +0900, Alexandre Courbot wrote:
...
>> +#[inline(always)]
>> +pub const fn align_down(self, value: $t) -> $t {
>
> I'm late to party, but could we instead implement:
>
> pub const fn rou
On Thu, Jun 12, 2025 at 08:56:02PM +0200, Nicolas Frattaroli wrote:
> This series was spawned by [1], where I was asked to move every instance
> of HIWORD_UPDATE et al that I could find to a common macro in the same
> series that I am introducing said common macro.
And it means, at least for patch
On Thu, Jun 12, 2025 at 02:37:28PM -0500, Bjorn Helgaas wrote:
> On Thu, Jun 12, 2025 at 08:56:18PM +0200, Nicolas Frattaroli wrote:
> > 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 Roc
On Thursday, 12 June 2025 21:44:15 Central European Summer Time Jakub Kicinski
wrote:
> On Thu, 12 Jun 2025 20:56:03 +0200 Nicolas Frattaroli wrote:
> > Hardware of various vendors, but very notably Rockchip, often uses
> > 32-bit registers where the upper 16-bit half of the register is a
> > writ
On Thu, 12 Jun 2025 20:56:03 +0200 Nicolas Frattaroli wrote:
> 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.
Please limit the spread of this weirdness to a rockchip or "
On Thu, Jun 12, 2025 at 08:56:17PM +0200, Nicolas Frattaroli wrote:
> 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 a
On Thu, Jun 12, 2025 at 08:56:19PM +0200, Nicolas Frattaroli wrote:
> 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 complica
On Thu, Jun 12, 2025 at 08:56:18PM +0200, Nicolas Frattaroli wrote:
> 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.
>
> Remov
On Thursday, 12 June 2025 21:08:20 Central European Summer Time Andrew Lunn
wrote:
> On Thu, Jun 12, 2025 at 08:56:17PM +0200, Nicolas Frattaroli wrote:
> > The era of hand-rolled HIWORD_UPDATE macros is over, at least for those
> > drivers that use constant masks.
> >
> > Like many other Rockchi
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 bitfield.h's HWORD_UPDATE.
To achieve this, some mask def
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 bitfield.h's HWORD_UPDATE
macro, which does the same thing except in a common macro that also does
compile-time error checking.
This was co
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 HWORD_UPDATE, or two new
header local macr
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
bitfield.h HWORD_UPDATE macros though.
Replace the
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 HWORD_UPDATE_CONST. The const variant is chosen here because
some of the header defines are then used in init
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 HWORD_UPDATE or
HWORD_UPDATE_CONST, depending on whether it's in an initiali
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 HWORD_UPDATE instances. To do this, a few
of the defines are being adjusted, as HWORD_UPDAT
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 HWORD_UPDATE. Since
HWORD_UPDATE shifts the value for us, we replace using the ma
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 HWORD_UPDATE from
bitfield.h. While at it, disambiguate the write GRF write to SOC_CON7 by
splitting the definition into the individual bitflags. Th
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 HWORD_UPDATE bitfield
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 HWORD_U
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 HWORD_UPDATE or HWORD_UPDATE_CONST, depending on whether
they're in an initializer. This gives us better error
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 bitfield.h's HWORD_UPDATE. This makes the
change more easily reviewable.
Signed-off-by: Nicolas Frattaroli
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 bitfield.h's HWORD_UPDATE macro, which gives us
more error checking.
For the slightly-less-trivial case o
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 bitfield.h's
new HWORD_UPDATE macro, wh
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 HWORD_UPDATE_CONST macro, which
brings with it more error checking while still being able to be used in
initializers.
All HIWORD_UPDATE instances and its
The era of hand-rolled HIWORD_UPDATE macros is over, at least for those
drivers that use constant masks.
Switch to the new HWORD_UPDATE macro in 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 with the
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-
This series was spawned by [1], where I was asked to move every instance
of HIWORD_UPDATE et al that I could find to a common macro in the same
series that I am introducing said common macro.
The first patch of the series introduces the two new macros in
bitfield.h, called HWORD_UPDATE and HWORD_U
On Thu, Jun 12, 2025 at 11:02 AM Lucas De Marchi
wrote:
>
> On Thu, Jun 12, 2025 at 05:46:52PM +0100, Tvrtko Ursulin wrote:
> >
> >On 12/06/2025 06:40, Lucas De Marchi wrote:
> >>On Wed, Jun 11, 2025 at 03:51:24PM -0700, Juston Li wrote:
> >>>Add TRACE_GPU_MEM tracepoints for tracking global and p
> -Original Message-
> From: Prabhakar
> Sent: 09 June 2025 23:56
> Subject: [PATCH v7 0/9] drm: renesas: rz-du: mipi_dsi: Prepare driver to
> support RZ/V2H(P) SoC
>
> From: Lad Prabhakar
>
> Hi All,
>
> This patch series prepares the MIPI DSI driver to support the Renesas
> RZ/V2
On Thu, Jun 12, 2025 at 05:46:52PM +0100, Tvrtko Ursulin wrote:
On 12/06/2025 06:40, Lucas De Marchi wrote:
On Wed, Jun 11, 2025 at 03:51:24PM -0700, Juston Li wrote:
Add TRACE_GPU_MEM tracepoints for tracking global and per-process GPU
memory usage.
These are required by VSR on Android 12+ f
Hi,
On Thu, Jun 12, 2025 at 12:35 AM Jayesh Choudhary wrote:
>
> >> If refclk is described in devicetree node, then I see that
> >> the driver modifies it in every resume call based solely on the
> >> clock value in dts.
> >
> > Exactly. But that is racy with what the chip itself is doing. I.e.
>
On Thu, Jun 12, 2025 at 03:54:51PM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 12.06.25 um 15:29 schrieb Imre Deak:
> > Hi,
> >
> > On Tue, Jun 10, 2025 at 06:42:04PM +0300, Imre Deak wrote:
> > > Hi Maxim, Thomas, Maarten,
> > >
> > > could you please ack merging this patchset via drm-intel?
>
On Tue, Jun 10, 2025 at 05:42:26PM +0100, Tvrtko Ursulin wrote:
Xe can free some of the data pointed to by the dma-fences it exports. Most
notably the timeline name can get freed if userspace closes the associated
submit queue. At the same time the fence could have been exported to a
third party
On Thu, Jun 12, 2025 at 05:10:23PM +, Kaustabh Chakraborty wrote:
> On 2025-06-12 15:30, Conor Dooley wrote:
> > On Thu, Jun 12, 2025 at 08:22:41PM +0530, Kaustabh Chakraborty wrote:
> >> Samsung S6E8AA5X01 is an AMOLED MIPI DSI panel controller. Document the
> >> compatible and devicetree prop
On 2025-06-12 15:30, Conor Dooley wrote:
> On Thu, Jun 12, 2025 at 08:22:41PM +0530, Kaustabh Chakraborty wrote:
>> Samsung S6E8AA5X01 is an AMOLED MIPI DSI panel controller. Document the
>> compatible and devicetree properties of this panel driver. Timings are
>> provided through the devicetree no
On 12/06/2025 06:40, Lucas De Marchi wrote:
On Wed, Jun 11, 2025 at 03:51:24PM -0700, Juston Li wrote:
Add TRACE_GPU_MEM tracepoints for tracking global and per-process GPU
memory usage.
These are required by VSR on Android 12+ for reporting GPU driver memory
allocations.
v3:
- Use now confi
Hi Dave, Simona
Two fixes for 6.16-rc2.
Thanks,
Thomas
drm-xe-fixes-2025-06-12:
Driver Changes:
- Fix regression disallowing 64K SVM migration (Maarten)
- Use a bounce buffer for WA BB (Lucas)
The following changes since commit 19272b37aa4f83ca52bdf9c16d5d81bdd1354494:
Linux 6.16-rc1 (2025-0
sdw slimbus
> qcom_pmic_tcpm qcom_usb_vbus_regulator drm_client_lib tcpm rtc_pm8xxx
> snd_soc_wcd_mbhc aux_hpd_bridge qcom_pon qcrypto soundwire_bus sha256
> qcom_stats gpi
> spi_geni_qcom i2c_qcom_geni rpmsg_ctrl libsha256_generic libsha256
> rpmsg_char qcom_rng sha256_arm64 auth
aux_hpd_bridge qcom_pon qcrypto soundwire_bus sha256 qcom_stats gpi
spi_geni_qcom i2c_qcom_geni rpmsg_ctrl libsha256_generic libsha256 rpmsg_char
qcom_rng sha256_arm64 authenc icc_bwmon phy_qcom_qmp_usbc libdes typec
phy_qcom_qusb2 display_connector i2c_gpio rmtfs_mem drm_kms_helper socinfo fuse
dr
On Thu, Jun 12, 2025 at 03:47:55PM +, Kaustabh Chakraborty wrote:
> On 2025-06-12 15:32, Conor Dooley wrote:
> > On Thu, Jun 12, 2025 at 08:09:40PM +0530, Kaustabh Chakraborty wrote:
> >> Document the driver for Synaptics TDDI (Touch/Display Integration) panels.
> >> Along with the MIPI-DSI pan
On 2025-06-12 15:32, Conor Dooley wrote:
> On Thu, Jun 12, 2025 at 08:09:40PM +0530, Kaustabh Chakraborty wrote:
>> Document the driver for Synaptics TDDI (Touch/Display Integration) panels.
>> Along with the MIPI-DSI panel, these devices also have an in-built LED
>> backlight device and a touchscr
On 03/06/2025 10:49, Ashley Smith wrote:
> The timeout logic provided by drm_sched leads to races when we try
> to suspend it while the drm_sched workqueue queues more jobs. Let's
> overhaul the timeout handling in panthor to have our own delayed work
> that's resumed/suspended when a group is resu
On 03/06/2025 10:49, Ashley Smith wrote:
> This fixes a bug where if we timeout after a suspend and the termination
> fails, due to waiting on a fence that will never be signalled for
> example, we do not resume the group correctly. The fix forces a reset
> for groups that are not terminated correc
On Thu, Jun 12, 2025 at 08:09:40PM +0530, Kaustabh Chakraborty wrote:
> Document the driver for Synaptics TDDI (Touch/Display Integration) panels.
> Along with the MIPI-DSI panel, these devices also have an in-built LED
> backlight device and a touchscreen, all packed together in a single chip.
> A
On Thu, Jun 12, 2025 at 08:22:41PM +0530, Kaustabh Chakraborty wrote:
> Samsung S6E8AA5X01 is an AMOLED MIPI DSI panel controller. Document the
> compatible and devicetree properties of this panel driver. Timings are
> provided through the devicetree node as panels are available in
> different size
On Thu, Jun 12, 2025, at 16:37, Tomi Valkeinen wrote:
> On 12/06/2025 15:40, Arnd Bergmann wrote:
> static u16 DISPC_OVL_BASE(enum omap_plane_id plane)
> {
> static const u16 bases[] = {0x0080, 0x00BC, 0x014C, 0x0300, 0x0500};
> return bases[plane];
> }
>
> In any case, I'll apply this wit
The VIDEO_MODE bit of DSIM_CONFIG is hardcoded to BIT(25), but
Exynos7870's DSIM has it in BIT(18) as per downstream kernel sources.
In order to support both, move this bit value to the driver data struct
and define it for every driver compatible. Reference the value from
there instead, in functio
Fix the kernel-doc directive after the rename
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/{r535,rm/r535/gsp}.c leading to
erros:
ERROR: Cannot find file ../drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
WARNING: No kernel-doc for file
../drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
Fixes: c472d828
On Exynos7870 devices, enabling the display requires disabling
standby by writing to the SFRCTRL register. Add the register and related
bit values. Since this behavior isn't available on other SoCs, implement
a flag in the driver data struct indicating the availability of this
feature.
Signed-off-
Add compatible string for Exynos7870 DSIM bridge controller. The
devicetree node requires four clock sources, named:
- bus_clk
- phyclk_mipidphy0_bitclkdiv8
- phyclk_mipidphy0_rxclkesc0
- sclk_mipi
Signed-off-by: Kaustabh Chakraborty
---
.../bindings/display/bridge/samsung,mipi-dsim.yaml | 26 ++
Add glue layer support for Exynos7870's DSIM IP bridge driver.
Signed-off-by: Kaustabh Chakraborty
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index
89
Add support for Exynos7870's DSIM IP block in the bridge driver.
Signed-off-by: Kaustabh Chakraborty
---
drivers/gpu/drm/bridge/samsung-dsim.c | 74 +++
include/drm/bridge/samsung-dsim.h | 1 +
2 files changed, 75 insertions(+)
diff --git a/drivers/gpu/drm/b
Currently, PLL_P offset of DSIM_PLLCTRL is configurable in the driver
data, while PLL_M and PLL_S offsets are hardcoded as 4-bit and 1-bit
offsets respectively, but Exynos7870's DSIM have them at 3-bit and 0-bit
offsets as per downstream kernel sources.
In order to support both, move both offset v
Exynos7870's DSIM requires more time to stabilize its PLL. The current
timeout value, 1000, doesn't suffice. Increase the value to 3000, which
is just about enough as observed experimentally.
Signed-off-by: Kaustabh Chakraborty
---
drivers/gpu/drm/bridge/samsung-dsim.c | 2 +-
1 file changed, 1
The PLL_STABLE bit of DSIM_DPHY_STATUS is hardcoded to BIT(31), but
Exynos7870's DSIM has it in BIT(24) as per downstream kernel sources.
In order to support both, move this bit value to the driver data struct
and define it for every driver compatible. Reference the value from
there instead, in fu
The MAIN_VSA offset of DSIM_MSYNC is hardcoded to a 22-bit offset, but
Exynos7870's DSIM has it in a 16-bit offset as per the downstream kernel
sources.
In order to support both, move this offset value to the driver data
struct and define it for every driver compatible. Reference the value
from th
DSIM_CLKCTRL bit and offset values hardcoded in the driver:
name | bit/offset value
--+-
DSIM_LANE_ESC_CLK_EN_CLK | 19
DSIM_LANE_ESC_CLK_EN_DATA | 20
DSIM_BYTE_CLKEN | 24
DSIM_ESC_CLKEN| 28
DSIM_TX_REQUEST_HSCLK
1 - 100 of 262 matches
Mail list logo
