On Thu, 31 Jul 2025 at 14:59, Linus Torvalds
wrote:
>
> On Wed, 30 Jul 2025 at 21:48, Linus Torvalds
> wrote:
> >
> > Well, it's one of these:
> >
> > 3f2b24a1ef35 drm/amd/display: Monitor patch to ignore EDID audio SAB check
> > aef3af22a456 drm/amd/display: Add definitions to support DID Ty
On Wed, 30 Jul 2025 at 21:58, Linus Torvalds
wrote:
>
> d7b618bc41ee3d44c070212dff93949702ede997 is the first bad commit
> drm/amd/display: Refactor DSC cap calculations
>
> Let me go see how painful it is to just revert it from top-of-tree.
So with that reverted (didn't require a lot of fixi
On 7/31/2025 2:35 AM, Dmitry Baryshkov wrote:
> On Wed, Jul 30, 2025 at 04:53:16PM +0800, Xiangxu Yin wrote:
>> On 7/22/2025 8:41 PM, Dmitry Baryshkov wrote:
>>> On Tue, Jul 22, 2025 at 08:05:06PM +0800, Xiangxu Yin wrote:
On 7/22/2025 4:38 PM, Dmitry Baryshkov wrote:
> On Tue, Jul 22, 2
On Wed, 30 Jul 2025 at 21:48, Linus Torvalds
wrote:
>
> Well, it's one of these:
>
> 3f2b24a1ef35 drm/amd/display: Monitor patch to ignore EDID audio SAB check
> aef3af22a456 drm/amd/display: Add definitions to support DID Type5
> descriptors
> d7b618bc41ee drm/amd/display: Refactor DSC cap
On Wed, 30 Jul 2025 at 21:36, Dave Airlie wrote:
>
> https://lore.kernel.org/dri-devel/20250717204819.731936-1-mustela@erminea.space/
>
> is the only thing I can see that might not be in the merge.
Well, it's one of these:
3f2b24a1ef35 drm/amd/display: Monitor patch to ignore EDID audio SAB ch
On Thu, 31 Jul 2025 at 14:32, Dave Airlie wrote:
>
> On Thu, 31 Jul 2025 at 14:27, Linus Torvalds
> wrote:
> >
> > On Wed, 30 Jul 2025 at 21:21, Dave Airlie wrote:
> > >
> > > Okay I don't have an rx580, but I have an rx480 which is pretty close,
> > > but it is booting fine with your tree at le
On Thu, 31 Jul 2025 at 14:27, Linus Torvalds
wrote:
>
> On Wed, 30 Jul 2025 at 21:21, Dave Airlie wrote:
> >
> > Okay I don't have an rx580, but I have an rx480 which is pretty close,
> > but it is booting fine with your tree at least, DP and HDMI connected,
> > so it's not widespread AMD breakag
On Wed, 30 Jul 2025 at 21:26, Linus Torvalds
wrote:
>
> The good news is that it's bisecting without any ambiguity. So nowhere
> near as painful as last merge window.
Right now it's in the range 1b556bcc3837..63b8c9fdfb7f.
A few more bisections and I'll have it down to a dozen or fewer commits.
On Wed, 30 Jul 2025 at 21:21, Dave Airlie wrote:
>
> Okay I don't have an rx580, but I have an rx480 which is pretty close,
> but it is booting fine with your tree at least, DP and HDMI connected,
> so it's not widespread AMD breakage, anything in journalctl/dmesg?
The machine doesn't come up far
On Thu, 31 Jul 2025 at 14:03, Linus Torvalds
wrote:
>
> On Wed, 30 Jul 2025 at 20:40, Linus Torvalds
> wrote:
> >
> > I'm very unhappy with the end result, because it just results in a
> > black screen at boot for me. No signal.
>
> It's not something in the merge, and it's not something in my tr
On Wed, 30 Jul 2025 at 20:40, Linus Torvalds
wrote:
>
> I'm very unhappy with the end result, because it just results in a
> black screen at boot for me. No signal.
It's not something in the merge, and it's not something in my tree - I
see the same plain "just a black screen" if I try that commit
On Wed, 30 Jul 2025 at 20:47, Dave Airlie wrote:
>
> Is that the Polaris card still?
Same old boring Radeon RX 580.
lspci calls it "Ellesmere", don't know about the Polaris codename..
Linus
On Wed, 30 Jul 2025 at 20:39, Dave Airlie wrote:
> >
> > But I do think that the drm people are doing actively wrong things
> > with the random cherry-picks back and forth: they cause these
> > conflicts, and I *really* think you should look at maybe using stable
> > fixes branches instead.
> >
>
On Thu, 31 Jul 2025 at 13:41, Linus Torvalds
wrote:
>
> On Wed, 30 Jul 2025 at 20:05, Linus Torvalds
> wrote:
> >
> > Again: I'm not going to guarantee that I got it right. I *think* I did
> > - I'm not feeling particularly unhappy with my merge end result.
>
> I spoke too soon.
>
> I'm very unha
On Wed, 30 Jul 2025 at 20:05, Linus Torvalds
wrote:
>
> Again: I'm not going to guarantee that I got it right. I *think* I did
> - I'm not feeling particularly unhappy with my merge end result.
I spoke too soon.
I'm very unhappy with the end result, because it just results in a
black screen at b
On Thu, 31 Jul 2025 at 13:05, Linus Torvalds
wrote:
>
> ,
>
> On Tue, 29 Jul 2025 at 14:06, Dave Airlie wrote:
> >
> > I've done a pass at merging mostly taking from drm-tip:
> > https://github.com/airlied/linux/tree/drm-next-6.17-rc1-merged
>
> Hmm. My resolution is pretty different, but part of
Update driver to use the "multi" variants of MIPI functions which
facilitate improved error handling and cleaner driver code.
Remove information from a comment which was made obsolete by commit
994ea402c767 ("drm/panel: Rename Sony ACX424 to Novatek NT35560"), which
determined that this driver sup
Create mipi_dsi_dcs_read_multi(), which accepts a mipi_dsi_multi_context
struct for improved error handling and cleaner panel driver code.
Create mipi_dsi_dcs_write_var_seq_multi() and
mipi_dsi_generic_write_var_seq_multi() macros which allow MIPI panel
drivers to write non-constant data to displa
Fix bug in nt35560_set_brightness() which causes the function to
erroneously report an error. mipi_dsi_dcs_write() returns either a
negative value when an error occurred or a positive number of bytes
written when no error occurred. The buggy code reports an error under
either condition.
Fixes: 815
Fix bug in novatek-nt35560 driver's nt35560_set_brightness() which
causes the driver to incorrectly report that it "failed to disable
display backlight".
Add mipi_dsi_dcs_read_multi() to drm_mipi_dsi.c for improved error
handling in drivers which use mipi_dsi_dcs_read() multiple times in a
row. Ad
dan.j.williams@ wrote:
> Hello,
>
> Linux Plumbers 2025, to be held December 11th through the 13th in Tokyo
> [1], will host the "Device and Specific Purpose Memory Microconference".
> Topic submissions are now being accepted.
>
> Go to:
>
> https://lpc.events/event/19/abstracts/
Whoops, that's
The pull request you sent on Wed, 30 Jul 2025 07:05:51 +1000:
> https://gitlab.freedesktop.org/drm/kernel.git tags/drm-next-2025-07-30
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/260f6f4fda93c8485c8037865c941b42b9cba5d2
Thank you!
--
Deet-doot-dot, I am a bot.
ht
,
On Tue, 29 Jul 2025 at 14:06, Dave Airlie wrote:
>
> I've done a pass at merging mostly taking from drm-tip:
> https://github.com/airlied/linux/tree/drm-next-6.17-rc1-merged
Hmm. My resolution is pretty different, but part of it is that your
test-merge has a different top-of-tree than the tree
Hello Sebastian，
在 2025-07-30 20:15:44，"Andy Yan" 写道：
>
>
>Hello Sebastian，
>
>At 2025-07-30 01:09:41, "Sebastian Reichel"
>wrote:
>>Hi,
>>
>>On Mon, Jul 28, 2025 at 04:28:34PM +0800, Andy Yan wrote:
>>> From: Andy Yan
>>>
>>> Enable the Mini DisplayPort on this board.
>>> Note that ROCKCHIP
Hi Dmitry,
On 7/31/2025 3:13 AM, Dmitry Baryshkov wrote:
On Tue, Jul 29, 2025 at 05:00:27PM +0800, Chaoyi Chen wrote:
From: Chaoyi Chen
This series focuses on adding Type-C DP support for USBDP PHY and DP
driver. The USBDP PHY and DP will perceive the changes in cable status
based on the USB
The `xa_store()` function can fail due to memory allocation issues or other
internal errors. Currently, the return value of `xa_store()` is not
checked, which can lead to a memory leak if it fails to store `numa_info`.
This patch checks the return value of `xa_store()`. If an error is
detected, th
On Wed Jul 30, 2025 at 9:56 AM MDT, Doug Anderson wrote:
>> +/**
>> + * mipi_dsi_dcs_write_var_seq_multi - transmit a DCS command with non-static
>> + * payload
>
> I should have been explicit, but the above "non-static" should also be
> "non-constant". ;-)
>
> I could probably fix that when applyi
On Wed, Jul 30, 2025 at 01:58:46PM -0600, Alex Williamson wrote:
> On Wed, 23 Jul 2025 16:00:01 +0300
> Leon Romanovsky wrote:
>
> > From: Leon Romanovsky
> >
> > ---
> > Based on blk and DMA patches which will be sent duri
On Wed, Jul 30, 2025 at 07:02:46PM +0200, Louis Chauvet wrote:
> For am62 processors, we need to use the newly created clk-ctrl property to
> properly handle data edge sampling configuration. Add them in the main
> device tree.
>
> Fixes: 32a1795f57ee ("drm/tidss: New driver for TI Keystone platfo
On Wed, Jul 30, 2025 at 07:02:44PM +0200, Louis Chauvet wrote:
> The dt-bindings for the display, specifically ti,am65x-dss, need to
> include a clock property for data edge synchronization. The current
> implementation does not correctly apply the data edge sampling property.
>
> To address this,
Hi Himal,
kernel test robot noticed the following build warnings:
[auto build test WARNING on next-20250730]
[cannot apply to drm-xe/drm-xe-next linus/master v6.16 v6.16-rc7 v6.16-rc6
v6.16]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we
On Wed, Jun 18, 2025 at 10:24:19AM -0400, Jeff Layton wrote:
> [...]
> The file is given the name "class@%px", as having the unmodified address
> is helpful for debugging. This should be safe since this directory is only
> accessible by root
> [...]
> +void ref_tracker_dir_debugfs(struct ref_tracke
Hello,
Linux Plumbers 2025, to be held December 11th through the 13th in Tokyo
[1], will host the "Device and Specific Purpose Memory Microconference".
Topic submissions are now being accepted.
Go to:
https://lpc.events/event/19/abstracts/
...and use the "Submit New Abstract" button. Select "De
From: Dmitry Baryshkov
commit cbf143b282c64e59559cc8351c0b5b1ab4bbdcbe upstream
This is not a direct cherry-pick of the upstream commit. Only the helper
functions required as dependencies for "drm/i915: Fix HPD polling, reenabling
the output poll work as needed" were extracted from the original
This collects and adapts several upstream fixes to make i915 and related
DRM subsystem build and function.
The upstream fix HPD polling("drm/i915: Fix HPD polling, reenabling the output
poll work as needed")
and its dependencies could not be directly backported due to extensive code
differences.
Hello maintainers,
This series addresses a defect observed on certain hardware platforms using
Linux kernel 6.1.147 with the i915 driver. The issue concerns hot plug
detection (HPD) logic,
leading to unreliable or missed detection events on affected hardware. This is
happening on some specific
From: Dmitry Baryshkov
commit c8268795c9a9cc7be50f78d4502fad83a2a4f8df upstream
This is not a direct cherry-pick of the upstream commit.
Only the helper functions required as dependencies for
"drm/i915: Fix HPD polling, reenabling the output poll work as needed"
were extracted from the original
We encountered the following errors while compiling drm_vram_helper.ko
ERROR: modpost: "drm_gem_ttm_print_info" [drivers/gpu/drm/drm_vram_helper.ko]
undefined!
ERROR: modpost: "drm_gem_ttm_mmap" [drivers/gpu/drm/drm_vram_helper.ko]
undefined!
The functions drm_gem_ttm_mmap and drm_gem_ttm_print
From: Imre Deak
commit 50452f2f76852322620b63e62922b85e955abe94 upstream.
While this commit is not a direct cherry-pick, the critical fix(two lines)
was adapted and applied.
After the commit in the Fixes: line below, HPD polling stopped working
on i915, since after that change calling drm_kms_h
From: Imre Deak
commit fe2352fd64029918174de4b460dfe6df0c6911cd upstream
This is not a clean cherry-pick due to code divergence.
Add a helper to reschedule drm_mode_config::output_poll_work after
polling has been enabled for a connector (and needing a reschedule,
since previously polling was di
fix a minor typo for the drm-uapi Documentation.
Signed-off-by: Ayash-Bera
---
Documentation/gpu/drm-uapi.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
index 69f72e71a96e..64e002c6383c 100644
--- a/Documen
Hi,
This patch solves the performance issue very well.
best regards,
Patryk
śr., 30 lip 2025 o 09:46 Baolin Wang napisał(a):
>
>
>
> On 2025/7/30 14:54, Hugh Dickins wrote:
> > On Mon, 28 Jul 2025, Baolin Wang wrote:
> >
> >> After commit acd7ccb284b8 ("mm: shmem: add large folio support for tmpf
We encountered the following errors while compiling drm_vram_helper.ko
ERROR: modpost: "drm_gem_ttm_print_info" [drivers/gpu/drm/drm_vram_helper.ko]
undefined!
ERROR: modpost: "drm_gem_ttm_mmap" [drivers/gpu/drm/drm_vram_helper.ko]
undefined!
The functions drm_gem_ttm_mmap and drm_gem_ttm_print
I see. This compilation error was caused by the configuration option not
automatically selecting DRM_TTM_HELPER. A revised version of the PR has been
submitted.
On Fri, Jul 11, 2025 at 3:05 AM Maxime Ripard wrote:
> On Thu, Jul 10, 2025 at 01:43:10PM -0400, Brian Masney wrote:
> > -static long sun4i_dclk_round_rate(struct clk_hw *hw, unsigned long rate,
> > - unsigned long *parent_rate)
> > +static int sun4i_dclk_determine_ra
On Mon, 2025-06-16 at 22:17 -0600, Alex Hung wrote:
> From: Harry Wentland
>
> We add two 3x4 matrices into the VKMS color pipeline. The reason
> we're adding matrices is so that we can test that application
> of a matrix and its inverse yields an output equal to the input
> image.
>
> One compl
Hi,
On Wed, Jul 30, 2025 at 1:38 PM Aleksandrs Vinarskis
wrote:
>
> On Tue, 29 Jul 2025 at 17:50, Doug Anderson wrote:
> >
> > Hi,
> >
> > On Sun, Jul 27, 2025 at 9:58 AM Aleksandrs Vinarskis
> > wrote:
> > >
> > > Timings taken from NV140WUM-N41. It is found in some arm64 laptops,
> > > eg. As
On Wed, 30 Jul 2025 08:54:22 +0300, Svyatoslav Ryhel wrote:
> Solomon SSD2825 is a RGB to MIPI DSI bridge used in LG Optimus 4D P880
> and LG Optimus Vu P895
>
Applied to drm-misc-next, thanks!
[1/2] dt-bindings: display: bridge: Document Solomon SSD2825
commit: 784c99331c8d54a51d4f3e772c8
On Wed, Jul 30, 2025 at 08:54:24AM +0300, Svyatoslav Ryhel wrote:
> SSD2825 is a cost-effective MIPI Bridge Chip solution targeting mainly
> smartphones. It can convert 24bit RGB interface into 4-lane MIPI-DSI
> interface to drive display modules of up to 800 x 1366, while supporting
> AMOLED, a-si
On Wed, Jul 30, 2025 at 12:19:51PM +0530, Aravind Iddamsetty wrote:
> Our hardware supports RAS(Reliability, Availability, Serviceability) by
> reporting the errors to the host, which the KMD processes and exposes a
> set of error counters which can be used by observability tools to take
> correct
On Tue, 29 Jul 2025 at 17:50, Doug Anderson wrote:
>
> Hi,
>
> On Sun, Jul 27, 2025 at 9:58 AM Aleksandrs Vinarskis
> wrote:
> >
> > Timings taken from NV140WUM-N41. It is found in some arm64 laptops,
> > eg. Asus Zenbook A14 UX3407QA.
> >
> > The raw edid of the panel is:
> > 00 ff ff ff ff ff f
syzbot has found a reproducer for the following issue on:
HEAD commit:4b290aae788e Merge tag 'sysctl-6.17-rc1' of git://git.kern..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=10ff883458
kernel config: https://syzkaller.appspot.com/x/.config?x=eb654b6
from schema $id: http://devicetree.org/schemas/phy/qcom,edp-phy.yaml#
doc reference errors (make refcheckdocs):
See
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20250730-mdssdt_qcs8300-v5-3-bc8ea35bb...@quicinc.com
The base for the series is generally the latest rc1.
Hi Nicusor,
thanks for the report and the root causing effort. The patchset itself
has a few issues:
- commit cfd48ad8c4a9 ("drm/i915: Fix HPD polling, reenabling the output
poll work as needed") you backport fixes d33a54e3991d
("drm/probe_helper: sort out poll_running vs poll_enabled"), but
On Wed, 23 Jul 2025 16:00:01 +0300
Leon Romanovsky wrote:
> From: Leon Romanovsky
>
> ---
> Based on blk and DMA patches which will be sent during coming merge window.
> -
On Wed, Jul 30, 2025 at 08:01:10PM +0530, Nilesh Laad wrote:
> Currently edid_read has value from previous connect session
> and resulting in drm using older edid before new edid is available
> in lt9611uxc.
> Reset edid_read so that correct status is updated and correct edid
> is available for drm
On Tue, Jul 29, 2025 at 05:00:27PM +0800, Chaoyi Chen wrote:
> From: Chaoyi Chen
>
> This series focuses on adding Type-C DP support for USBDP PHY and DP
> driver. The USBDP PHY and DP will perceive the changes in cable status
> based on the USB PD and Type-C state machines provided by TCPM. Befo
On Wed, Jul 30, 2025 at 2:50 AM K Prateek Nayak wrote:
> On 7/30/2025 1:57 PM, Maarten Lankhorst wrote:
> > Hey,
> >
> > This warning is introduced in linux-next as a4f0b6fef4b0 ("locking/mutex:
> > Add p->blocked_on wrappers for correctness checks")
> > Adding relevant people from that commit.
>
On Mon, Jul 28, 2025 at 09:14:34PM +0800, Jun Nie wrote:
> Currently, SSPPs are assigned to a maximum of two pipes. However,
> quad-pipe usage scenarios require four pipes and involve configuring
> two stages. In quad-pipe case, the first two pipes share a set of
> mixer configurations and enable m
On Wed, Jul 30, 2025 at 04:53:16PM +0800, Xiangxu Yin wrote:
>
> On 7/22/2025 8:41 PM, Dmitry Baryshkov wrote:
> > On Tue, Jul 22, 2025 at 08:05:06PM +0800, Xiangxu Yin wrote:
> >> On 7/22/2025 4:38 PM, Dmitry Baryshkov wrote:
> >>> On Tue, Jul 22, 2025 at 03:22:03PM +0800, Xiangxu Yin wrote:
> >>
On Wed, Jul 30, 2025 at 05:42:27PM +0800, Yongxing Mou wrote:
> Add compatible string for the DisplayPort controller found on the
> Qualcomm QCS8300 SoC, which uses the same DPU as the SA8775P. While
> DP0 supports 4 MST streams, DP1 has been removed at the silicon level,
> so SA8775P/SM8650 cannot
In certain scenarios, it is possible for multiple cache flushes to be
requested before the previous one completes. This patch introduces the
cache_flush_lock mutex to serialize these operations and ensure that
any requested cache flushes are completed instead of dropped.
Signed-off-by: Karunika Ch
Hi,
On Wed, Jul 30, 2025 at 12:16 AM Cong Yang
wrote:
>
> Add a few generic edp panels used by mt8189 chromebooks, most of them use
> the same general timing. For CMN-N116BCA-EAK, the enable timing should be
> 200ms. For TMA-TL140VDMS03-01, the enable timing should be 80ms and the
> disable timin
For am62 processors, we need to use the newly created clk-ctrl property to
properly handle data edge sampling configuration. Add them in the main
device tree.
Fixes: 32a1795f57ee ("drm/tidss: New driver for TI Keystone platform Display
SubSystem")
Signed-off-by: Louis Chauvet
---
Cc: sta...@vge
The dt-bindings for the display, specifically ti,am65x-dss, need to
include a clock property for data edge synchronization. The current
implementation does not correctly apply the data edge sampling property.
To address this, synchronization of writes to two different registers is
required: one in
arch/arm64/boot/dts/ti/k3-am62-main.dtsi | 6 ++
drivers/gpu/drm/tidss/tidss_dispc.c| 14 ++
4 files changed, 28 insertions(+), 1 deletion(-)
---
base-commit: 85c23f28905cf20a86ceec3cfd7a0a5572c9eb13
change-id: 20250730-fix-edge-handling-91
As stated in the AM62x Technical Reference Manual (SPRUIV7B), the data
sampling edge needs to be configured in two distinct registers: one in the
TIDSS IP and another in the memory-mapped control register modules. Since
the latter is not within the same address range, a phandle to a syscon
device i
The dt-bindings for the multi-function device (mfd) syscon need to include
ti,am625-dss-clk-ctrl. On AM625 chips, the display controller (tidss) has
external registers to control certain clock properties. These registers
are located in the device configuration registers, so they need to be
declared
…
> by dereferencing the pointer only after it has been null checked. Also
> Replace minor->dev with dev.
I suggest to separate desirable changes into another patch series.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.16#
On Wed, Jul 30, 2025 at 03:49:45PM +0100, Robin Murphy wrote:
> On 2025-07-29 9:13 pm, Jason Gunthorpe wrote:
> > On Tue, Jul 29, 2025 at 08:44:21PM +0100, Robin Murphy wrote:
> >
> > > In this case with just one single
> > > contiguous mapping, it is clearly objectively worse to have to bounce in
Hi,
On Tue, Jul 29, 2025 at 11:18 PM Brigham Campbell
wrote:
>
> Create mipi_dsi_dcs_read_multi(), which accepts a mipi_dsi_multi_context
> struct for improved error handling and cleaner panel driver code.
>
> Create mipi_dsi_dcs_write_var_seq_multi() and
> mipi_dsi_generic_write_var_seq_multi()
On Tue, Jul 29, 2025 at 09:33:50PM -0300, Maíra Canal wrote:
> On 29/07/25 13:19, Maíra Canal wrote:
> > Hi Maxime,
> >
> > On 29/07/25 09:14, Maxime Ripard wrote:
> > > On Tue, Jul 29, 2025 at 08:53:51AM -0300, Maíra Canal wrote:
> > > > Hi Maxime,
> > > >
> > > > On 29/07/25 04:27, Maxime Ripar
On 17/07/2025 15:57, Svyatoslav Ryhel wrote:
HV101HD1-1E1 is a color active matrix TFT LCD module using amorphous
silicon TFT's (Thin Film Transistors) as an active switching devices. This
module has a 10.1 inch diagonally measured active area with HD resolutions
(1366 horizontal by 768 vertical
On 2025-07-29 9:13 pm, Jason Gunthorpe wrote:
On Tue, Jul 29, 2025 at 08:44:21PM +0100, Robin Murphy wrote:
In this case with just one single
contiguous mapping, it is clearly objectively worse to have to bounce in and
out of the IOMMU layer 3 separate times and store a dma_map_state,
The non
Hi Marie,
kernel test robot noticed the following build errors:
[auto build test ERROR on shuah-kselftest/kunit]
[also build test ERROR on shuah-kselftest/kunit-fixes drm-xe/drm-xe-next
linus/master v6.16 next-20250730]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And
9611uxc->bridge,
connected ?
connector_status_connected :
---
base-commit: 85c23f28905cf20a86ceec3cfd7a0a5572c9eb13
change-id: 20250730-lt9611uxc-reset-edid-cc03c5b4bc60
Best regards,
--
Nilesh Laad
Hi Christian,
Am Montag, dem 28.07.2025 um 00:28 +0200 schrieb Christian Gmeiner:
> Hi Lucas,
>
> > > > We should be comparing the last submitted sequence number with that of
> > > > the address space we may be switching to.
> > > >
> > > This isn't the relevant change here though: if we switch
Currently the pointer minor is being dereferenced before it is null
checked, leading to a potential null pointer dereference issue. Fix this
by dereferencing the pointer only after it has been null checked. Also
Replace minor->dev with dev.
Fixes: 4f89cf40d01e ("drm/msm: bail out late_init_minor()
On 30/07/2025 07:54, Svyatoslav Ryhel wrote:
SSD2825 is a cost-effective MIPI Bridge Chip solution targeting mainly
smartphones. It can convert 24bit RGB interface into 4-lane MIPI-DSI
interface to drive display modules of up to 800 x 1366, while supporting
AMOLED, a-si LCD or LTPS panel technolo
On 2025-07-30 09:55, Murthy, Arun R wrote:
> On 30-07-2025 18:44, Harry Wentland wrote:
>>
>> On 2025-07-30 06:16, Arun R Murthy wrote:
>>> Add user readable error codes for failure cases in drm_atomic_ioctl() so
>>> that user can decode the error code and take corrective measurements.
>>>
>> Th
On 7/28/2025 3:57 PM, Riana Tauro wrote:
Address the need for a recovery method (firmware flash on Firmware errors)
introduced in the later patches of Xe KMD.
Whenever XE KMD detects a firmware error, a firmware flash is required to
recover the device to normal operation.
The initial proposal
On 30-07-2025 18:44, Harry Wentland wrote:
On 2025-07-30 06:16, Arun R Murthy wrote:
Add user readable error codes for failure cases in drm_atomic_ioctl() so
that user can decode the error code and take corrective measurements.
Thanks for doing this work.
@@ -1541,6 +1548,9 @@ int drm_mode
Hi,
On Wed, 30 Jul 2025 at 14:35, Colin Ian King wrote:
> Currently pointer plane is being dereferenced on the calls to
> drm_atomic_get_old_plane_state and drm_atomic_get_new_plane_state
> when assigning old_plane_state and new_plane_state, this could
> lead to a null pointer dereference. Fix th
Hi Marie,
kernel test robot noticed the following build errors:
[auto build test ERROR on shuah-kselftest/kunit]
[also build test ERROR on shuah-kselftest/kunit-fixes drm-xe/drm-xe-next
linus/master v6.16 next-20250730]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And
On 30-07-2025 16:52, Biju Das wrote:
Hi Arun,
-Original Message-
From: dri-devel On Behalf Of Arun R
Murthy
Sent: 30 July 2025 11:17
Subject: [PATCH v2 1/4] drm: Define user readable error codes for atomic ioctl
There can be multiple reasons for a failure in atomic_ioctl. Most often
Hi Miguel, this is indeed nice!
> On 30 Jul 2025, at 10:07, Miguel Ojeda wrote:
>
> This fixes a handful of broken links and introduces a warning to
> prevent them from happening in the future.
>
> Relatedly, we could also perhaps check the other side of the links, but
> perhaps there are cases
Currently pointer plane is being dereferenced on the calls to
drm_atomic_get_old_plane_state and drm_atomic_get_new_plane_state
when assigning old_plane_state and new_plane_state, this could
lead to a null pointer dereference. Fix this by first performing
a null pointer check on plane, then assigni
On Wed, 30 Jul 2025 15:07:16 +0200
Miguel Ojeda wrote:
> `srctree/` links may point to nonexistent files, e.g. due to renames
> that missed to update the files or simply because of typos.
>
> Since they can be easily checked for validity, do so and print a
> warning in the file does not exist.
>
On 7/30/25 3:07 PM, Miguel Ojeda wrote:
These `srctree/` links pointed inside `linux/`, but they are directly
under `drm/`.
Thus fix them.
This cleans a future warning that will check our `srctree/` links.
Fixes: a98a73be9ee9 ("rust: drm: file: Add File abstraction")
Fixes: c284d3e42338 ("rust
On 2025-07-30 06:16, Arun R Murthy wrote:
> Add user readable error codes for failure cases in drm_atomic_ioctl() so
> that user can decode the error code and take corrective measurements.
>
Thanks for doing this work.
> @@ -1541,6 +1548,9 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
On Wed, Jul 30, 2025 at 02:45:13PM +0200, Konrad Dybcio wrote:
> On 7/30/25 2:39 PM, Ayushi Makhija wrote:
> > Currently, the high bitfield of certain DSI registers
> > do not align with the configuration of the SWI registers
> > description. This can lead to wrong programming these DSI
> > registe
`srctree/` links may point to nonexistent files, e.g. due to renames
that missed to update the files or simply because of typos.
Since they can be easily checked for validity, do so and print a warning
in the file does not exist.
This found the following cases already in-tree:
warning: srctr
These `srctree/` links pointed inside `linux/`, but they are directly
under `drm/`.
Thus fix them.
This cleans a future warning that will check our `srctree/` links.
Fixes: a98a73be9ee9 ("rust: drm: file: Add File abstraction")
Fixes: c284d3e42338 ("rust: drm: gem: Add GEM object abstraction")
F
This `srctree/` link pointed to a file with an underscore, but the header
used a dash instead.
Thus fix it.
This cleans a future warning that will check our `srctree/` links.
Fixes: 3253aba3408a ("rust: block: introduce `kernel::block::mq` module")
Signed-off-by: Miguel Ojeda
---
rust/kernel/b
This fixes a handful of broken links and introduces a warning to
prevent them from happening in the future.
Relatedly, we could also perhaps check the other side of the links, but
perhaps there are cases we want to customize. Alternatively, we could
also in the future introduce custom syntax for t
Hi,
The patch has been reviewed and approved.
Could someone please help to merge it?
Thank you,
Nitin
> -Original Message-
> From: Gote, Nitin R
> Sent: Thursday, July 24, 2025 10:36 AM
> To: Thomas Zimmermann
> Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Shyt
[…]
>>>
The idea of register blocks is interesting. I wonder how that would
translate in terms of access to invididual registers, i.e. does the
block end up just being a prefix into the full register name, or is it
something else? From your example declaration I picture that a
On 7/30/25 2:39 PM, Ayushi Makhija wrote:
> Currently, the high bitfield of certain DSI registers
> do not align with the configuration of the SWI registers
> description. This can lead to wrong programming these DSI
> registers, for example for 4k resloution where H_TOTAL is
> taking 13 bits but s
Currently, the high bitfield of certain DSI registers
do not align with the configuration of the SWI registers
description. This can lead to wrong programming these DSI
registers, for example for 4k resloution where H_TOTAL is
taking 13 bits but software is programming only 12 bits
because of the i
- DRM_GPUVM_SM_MAP_OPS_FLAG_SPLIT_MADVISE: This flag is used by
drm_gpuvm_sm_map_ops_create to iterate over GPUVMA's in the
user-provided range and split the existing non-GEM object VMA if the
start or end of the input range lies within it. The operations can
create up to 2 REMAPS and 2 MAPs. The
1 - 100 of 147 matches
Mail list logo
