Hi Linus,
Regular weekly fixes, nothing too major, mostly amdgpu, then i915, xe,
msm and nouveau with some scattered bits elsewhere.
Dave.
drm-fixes-2024-02-16:
drm fixes for 6.8-rc5
crtc:
- fix uninit variable
prime:
- support > 4GB page arrays
buddy:
- fix error handling in allocations
Hi Sandor,
thanks for the update.
Am Sonntag, 4. Februar 2024, 11:21:49 CET schrieb Sandor Yu:
> Add a new DRM DisplayPort and HDMI bridge driver for Candence MHDP8501
> used in i.MX8MQ SOC. MHDP8501 could support HDMI or DisplayPort
> standards according embedded Firmware running in the uCPU.
>
Smatch warns:
drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dmub_srv.c:136
dc_dmub_srv_cmd_list_queue_execute() warn: variable dereferenced
before check 'dc_dmub_srv' (see line 131)
Fix this by moving the dereference "dc_dmub_srv->ctx" after the NULL check.
Fixes:
This adds common1 register space for AM62x SoC which is using TI's Keystone
display hardware and supporting it as described in
Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
Fixes: 8ccc1073c7bb ("arm64: dts: ti: k3-am62-main: Add node for DSS")
Signed-off-by: Devarsh Thakkar
---
TI keystone display subsystem present in AM65, AM62 and AM62A SoC support
two separate register spaces namely "common" and "common1" which can be
used by two separate hosts to program the display controller as described
in respective Technical Reference Manuals [1].
The common1 register space has
This adds common1 register space for AM65x SoC which is using TI's Keystone
display hardware and supporting it as described in
Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
Fixes: fc539b90eda2 ("arm64: dts: ti: am654: Add DSS node")
Signed-off-by: Devarsh Thakkar
---
V1->V4 :
-
This adds DSS common1 region for respective SoCs supporting it.
Changelog:
V2 : Remove do-not-merge tag and add am62a dss common1 reion
V3 : Add Fixes tag to each commit
V4 : Add Reviewed-by tag and AM62A SoC TRM Link
V5 : Split dts patch to separate patches for each SoC
Devarsh Thakkar (4):
This adds common1 register space for AM62A SoC which is using TI's Keystone
display hardware and supporting it as described in
Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
Fixes: 3618811657b3 ("arm64: dts: ti: k3-am62a-main: Add node for Display
SubSystem (DSS)")
Signed-off-by:
Hi Mario,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on drm-intel/for-linux-next-fixes drm-tip/drm-tip
linus/master v6.8-rc4 next-20240215]
[If your patch is applied to the wrong git tree, kindly drop us
It is not intel specific and the goal is to have a generic API for configuring
Sharpness, accessible to various vendors. Intel currently offers sharpness
support through the Display Engine, while other vendors seem to support
Sharpness through the GPU using GL shaders (Vulcan/Open GL based).
On Thu, 15 Feb 2024 at 20:06, Tvrtko Ursulin
wrote:
>
> Hi Dave, Daniel,
>
> First pull request for 6.9 with probably one more coming in one to two
> weeks.
>
> Nothing to interesting in this one, mostly a sprinkle of small fixes in
> GuC, HuC, Perf/OA, a tiny bit of prep work for future
Hi Mario,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm-misc/drm-misc-next]
[also build test ERROR on drm-intel/for-linux-next-fixes drm-tip/drm-tip
linus/master v6.8-rc4 next-20240215]
[If your patch is applied to the wrong git tree, kindly drop us a note
Hi Mario,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on drm-intel/for-linux-next-fixes drm-tip/drm-tip
linus/master v6.8-rc4 next-20240215]
[If your patch is applied to the wrong git tree, kindly drop us
On 2/14/24 19:52, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20240214:
>
on i386:
ld: drivers/gpu/drm/tests/drm_buddy_test.o: in function
`drm_test_buddy_alloc_contiguous':
/work/lnx/next/linux-next-20240215/X32/../drivers/gpu/drm/tests/drm_buddy_test.c:48:(.text+0x94)
On Thu, Feb 15, 2024 at 11:22 AM Adam Ford wrote:
>
> On Thu, Feb 15, 2024 at 11:10 AM Adam Ford wrote:
> >
> > On Thu, Feb 15, 2024 at 10:54 AM Geert Uytterhoeven
> > wrote:
> > >
> > > Hi Maxime,
> > >
> > > On Thu, Feb 15, 2024 at 5:18 PM Maxime Ripard wrote:
> > > > On Thu, Feb 15, 2024 at
On 2/15/2024 14:34, Andi Shyti wrote:
Hi John,
On Thu, Feb 15, 2024 at 01:23:24PM -0800, John Harrison wrote:
On 2/15/2024 05:59, Andi Shyti wrote:
Since CCS automatic load balancing is disabled, we will impose a
fixed balancing policy that involves setting all the CCS engines
to work
The variable i is being initialized with a value that is never read,
it is being re-assigned in the next for-loop statement. The
initialization is redundant and can be removed.
Cleans up clang scan build warning:
drivers/char/agp/amd64-agp.c:336:2: warning: Value stored to 'i' is
never read
The variable space is being initialized with a value that is never read,
it is being re-assigned later on. The initialization is redundant and
can be removed. Also merge two declaration lines together.
Cleans up clang scan build warning:
drivers/gpu/host1x/cdma.c:628:15: warning: Value stored to
Hi John,
On Thu, Feb 15, 2024 at 01:23:24PM -0800, John Harrison wrote:
> On 2/15/2024 05:59, Andi Shyti wrote:
> > Since CCS automatic load balancing is disabled, we will impose a
> > fixed balancing policy that involves setting all the CCS engines
> > to work together on the same load.
> >
> >
Stop calling drm_bridge_remove() for bridges allocated/managed by other
drivers in the remove paths of meson_encoder_{cvbs,dsi,hdmi}.
drm_bridge_remove() unregisters the bridge so it cannot be used
anymore. Doing so for bridges we don't own can lead to the video
pipeline not being able to come up
On 2/15/2024 05:59, Andi Shyti wrote:
Since CCS automatic load balancing is disabled, we will impose a
fixed balancing policy that involves setting all the CCS engines
to work together on the same load.
Simultaneously, the user will see only 1 CCS rather than the
actual number. As of now, this
Am Donnerstag, 15. Februar 2024, 18:06:06 CET schrieb Conor Dooley:
> On Thu, Feb 15, 2024 at 10:05:14AM +0100, Heiko Stuebner wrote:
> > From: Heiko Stuebner
> >
> > Add the compatible for the ltk101b4029w panel, that is really similar
> > to the ltk500hd1829.
>
> Please mention what makes the
Hi Mario,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on drm-intel/for-linux-next-fixes drm-tip/drm-tip
linus/master v6.8-rc4 next-20240215]
[If your patch is applied to the wrong git tree, kindly drop us
Hi Mario,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm-misc/drm-misc-next]
[also build test ERROR on drm-intel/for-linux-next-fixes drm-tip/drm-tip
linus/master v6.8-rc4 next-20240215]
[If your patch is applied to the wrong git tree, kindly drop us a note
On 2/13/2024 23:24, Daniel van Vugt wrote:
Until now, deferred console takeover only meant defer until there is
output. But that risks stepping on the toes of userspace splash screens,
as console messages may appear before the splash screen. So check the
command line for the expectation of
Hi Dave, Daniel,
Same PR as earlier today, but drop the panel power saving debugging patches
for now at Harry's request.
The following changes since commit 841c35169323cd833294798e58b9bf63fa4fa1de:
Linux 6.8-rc4 (2024-02-11 12:18:13 -0800)
are available in the Git repository at:
From: Paloma Arellano
YUV420 format is supported only in the VSC SDP packet and not through
MSA. Hence add an API which indicates the sink support which can be used
by the rest of the DP programming.
changes in v5:
- rebased on top of drm-tip
changes in v4:
- bail out early if
intel_dp_vsc_sdp_pack() can be re-used by other DRM drivers as well.
Lets move this to drm_dp_helper to achieve this.
changes in v2:
- rebased on top of drm-tip
Acked-by: Dmitry Baryshkov
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/display/drm_dp_helper.c | 78
On 2/15/2024 12:47, Ville Syrjälä wrote:
On Thu, Feb 15, 2024 at 12:20:56PM -0600, Mario Limonciello wrote:
On 2/14/2024 17:13, Ville Syrjälä wrote:
On Wed, Feb 14, 2024 at 03:57:54PM -0600, Mario Limonciello wrote:
Some manufacturers have intentionally put an EDID that differs from
the EDID
On Thu, Feb 15, 2024 at 12:20:56PM -0600, Mario Limonciello wrote:
> On 2/14/2024 17:13, Ville Syrjälä wrote:
> > On Wed, Feb 14, 2024 at 03:57:54PM -0600, Mario Limonciello wrote:
> >> Some manufacturers have intentionally put an EDID that differs from
> >> the EDID on the internal panel on
On 15/02/2024 11:02, Uwe Kleine-König wrote:
> On Mon, Feb 12, 2024 at 11:23:02AM +0100, Krzysztof Kozlowski wrote:
>> On 08/02/2024 11:43, Lee Jones wrote:
>>> On Fri, 02 Feb 2024 05:47:33 +0530, Dharma Balasubiramani wrote:
Convert the atmel,hlcdc binding to DT schema format.
On 15/02/2024 13:31, Tony Lindgren wrote:
> The tc358765 is similar to tc358775. The tc358765 just an earlier version
> of the hardware, and it's pin and register compatible with tc358775 for
> most part.
>
> From the binding point of view the only difference is that the tc358765
> does not have
On Thu, 15 Feb 2024 at 19:03, Dmitry Baryshkov
wrote:
>
> On Thu, 15 Feb 2024 at 18:39, Abhinav Kumar wrote:
> >
> >
> >
> > On 2/15/2024 12:40 AM, Dmitry Baryshkov wrote:
> > > On Wed, 14 Feb 2024 at 22:15, Abhinav Kumar
> > > wrote:
> > >>
> > >>
> > >>
> > >> On 2/14/2024 11:39 AM, Dmitry
On 2/15/2024 7:47 AM, Abhinav Kumar wrote:
On 2/15/2024 12:45 AM, Dmitry Baryshkov wrote:
On Wed, 14 Feb 2024 at 20:04, Paloma Arellano
wrote:
Adjust the encoder format programming in the case of video mode for DP
to accommodate CDM related changes.
Changes in v2:
- Move timing
On 2/14/2024 17:13, Ville Syrjälä wrote:
On Wed, Feb 14, 2024 at 03:57:54PM -0600, Mario Limonciello wrote:
Some manufacturers have intentionally put an EDID that differs from
the EDID on the internal panel on laptops. Drivers that prefer to
fetch this EDID can set a bit on the drm_connector
On 2/15/2024 11:54, Harry Wentland wrote:
On 2024-02-02 11:20, Mario Limonciello wrote:
On 2/2/2024 09:28, Hamza Mahfooz wrote:
We want programs besides the compositor to be able to enable or disable
panel power saving features. However, since they are currently only
configurable through DRM
On 2/15/2024 08:01, Jani Nikula wrote:
On Sat, 10 Feb 2024, Mario Limonciello wrote:
Some manufacturers have intentionally put an EDID that differs from
the EDID on the internal panel on laptops. Drivers that prefer to
fetch this EDID can set a bit on the drm_connector to indicate that
the
On 2024-02-02 11:20, Mario Limonciello wrote:
> On 2/2/2024 09:28, Hamza Mahfooz wrote:
>> We want programs besides the compositor to be able to enable or disable
>> panel power saving features. However, since they are currently only
>> configurable through DRM properties, that isn't possible. So,
On 15.02.2024 10:20, Neil Armstrong wrote:
> Add support for the A750 GPU found on the SM8650 platform
>
> Unlike the the very close A740 GPU on the SM8550 SoC, the A750 GPU
> doesn't have an HWCFG block but a separate register set.
>
> The A750 GPU info are added under the adreno_is_a750()
Seems like we can potentially hit underruns if the CFB offset is within
the first page of stolen. Just like i915 skip the first page.
BSpec: 50214
Reported-by: Matt Roper
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/xe/compat-i915-headers/i915_gem_stolen.h | 3 +++
1 file changed, 3
Sanity check range bias with DRM_BUDDY_RANGE_ALLOCATION.
Signed-off-by: Matthew Auld
Cc: Arunpravin Paneer Selvam
Cc: Christian König
---
drivers/gpu/drm/tests/drm_buddy_test.c | 218 +
1 file changed, 218 insertions(+)
diff --git
No need to be so aggressive here. The upper layers will already apply
the needed alignment, plus some allocations might wish to skip it. Main
issue is that we might want to have start/end bias range which doesn't
match the default alignment which is rejected by the allocator.
Signed-off-by:
Likely not a big deal for real users, but for consistency we should
respect the min_page_size here. Main issue is that bias allocations
turns into normal range allocation if the range and size matches
exactly, and in the next patch we want to add some unit tests for this
part of the api.
Doesn't seem to compile on 32b, presumably due to u64 mod/division.
Simplest is to just switch over to u32 here. Also make print modifiers
consistent with that.
Fixes: a64056bb5a32 ("drm/tests/drm_buddy: add alloc_contiguous test")
Reported-by: Geert Uytterhoeven
Signed-off-by: Matthew Auld
Cc:
There is a corner case here where start/end is after/before the block
range we are currently checking. If so we need to be sure that splitting
the block will eventually give use the block size we need. To do that we
should adjust the block range to account for the start/end, and only
continue with
On 08/02/24 06:39, Pekka Paalanen wrote:
> On Wed, 7 Feb 2024 16:49:56 +0100
> Louis Chauvet wrote:
>
>> Hello Pekka, Arthur, Maxime,
>
> Hi all
>
>>> Change the composition algorithm to iterate over pixels instead of
>>> lines.
>>> It allows a simpler management of
[Public]
> -Original Message-
> From: Ilpo Järvinen
> Sent: Thursday, February 15, 2024 8:32 AM
> To: Deucher, Alexander ; amd-
> g...@lists.freedesktop.org; Daniel Vetter ; David Airlie
> ; Dennis Dalessandro
> ; dri-
> de...@lists.freedesktop.org; Jason Gunthorpe ; Leon
> Romanovsky ;
On Mon, Feb 12, 2024 at 01:13:21PM +, Paweł Anikiel wrote:
> The Chameleon v3 uses the framebuffer IP core to take the video signal
> from different sources and directly write frames into memory.
>
> Signed-off-by: Paweł Anikiel
> ---
> .../bindings/media/google,chv3-fb.yaml| 77
Yo,
On Mon, Feb 12, 2024 at 01:13:22PM +, Paweł Anikiel wrote:
> The Intel Displayport RX IP is a part of the DisplayPort Intel FPGA IP
> Core. It implements a DisplayPort 1.4 receiver capable of HBR3 video
> capture and Multi-Stream Transport. The user guide can be found here:
>
>
On Thu, Feb 15, 2024 at 11:10 AM Adam Ford wrote:
>
> On Thu, Feb 15, 2024 at 10:54 AM Geert Uytterhoeven
> wrote:
> >
> > Hi Maxime,
> >
> > On Thu, Feb 15, 2024 at 5:18 PM Maxime Ripard wrote:
> > > On Thu, Feb 15, 2024 at 01:50:09PM +0100, Geert Uytterhoeven wrote:
> > > > Using the
On Thu, Feb 15, 2024 at 10:54 AM Geert Uytterhoeven
wrote:
>
> Hi Maxime,
>
> On Thu, Feb 15, 2024 at 5:18 PM Maxime Ripard wrote:
> > On Thu, Feb 15, 2024 at 01:50:09PM +0100, Geert Uytterhoeven wrote:
> > > Using the Imagination Technologies PowerVR Series 6 GPU requires a
> > > proprietary
On Thu, Feb 15, 2024 at 10:04:41AM +0100, Heiko Stuebner wrote:
> From: Heiko Stuebner
>
> admatec GmbH is a german supplier for industrial displays.
>
> Signed-off-by: Heiko Stuebner
There's a fair few Admatec's it seems, so a link would be good:
Link: https://www.admatec.de/
Acked-by:
Hi,
On Thu, Feb 15, 2024 at 8:53 AM Neil Armstrong
wrote:
>
> Hi Doug,
>
> On 15/02/2024 16:08, Doug Anderson wrote:
> > Hi,
> >
> > On Thu, Feb 15, 2024 at 2:24 AM Jani Nikula wrote:
> >>
> >> On Wed, 14 Feb 2024, Doug Anderson wrote:
> >>> Hi,
> >>>
> >>> On Tue, Feb 13, 2024 at 10:25 PM
On Thu, Feb 15, 2024 at 10:04:42AM +0100, Heiko Stuebner wrote:
> From: Heiko Stuebner
>
> The 9904379 is a 10.1" 1024x600 LVDS display using the standard
> lvds properties.
>
> Signed-off-by: Heiko Stuebner
Acked-by: Conor Dooley
Cheers,
Conor.
> ---
>
Hi Dave,
Another fixes pull, this time actually including the GPU fixes left
out of last week's fixes due to miss-applied label, plus addition of a
tlb invalidation fix. Description below.
The following changes since commit 8d35217149daa33358c284aca6a56d5ab92cfc6c:
drm/msm/mdss: specify cfg
On Thu, Feb 15, 2024 at 10:05:14AM +0100, Heiko Stuebner wrote:
> From: Heiko Stuebner
>
> Add the compatible for the ltk101b4029w panel, that is really similar
> to the ltk500hd1829.
Please mention what makes the devices incompatible. "really similar" is
vague and could be used for a device
On Thu, 15 Feb 2024 at 18:39, Abhinav Kumar wrote:
>
>
>
> On 2/15/2024 12:40 AM, Dmitry Baryshkov wrote:
> > On Wed, 14 Feb 2024 at 22:15, Abhinav Kumar
> > wrote:
> >>
> >>
> >>
> >> On 2/14/2024 11:39 AM, Dmitry Baryshkov wrote:
> >>> On Wed, 14 Feb 2024 at 20:04, Paloma Arellano
> >>>
On Thu, Feb 15, 2024 at 10:20:23AM +0100, Neil Armstrong wrote:
> Document the Adreno 750 GMU found on the SM8650 platform.
>
> Reviewed-by: Konrad Dybcio
> Signed-off-by: Neil Armstrong
Acked-by: Conor Dooley
Cheers,
Conor.
> ---
> Documentation/devicetree/bindings/display/msm/gmu.yaml |
On Thu, Feb 15, 2024 at 02:59:23PM +0100, Andi Shyti wrote:
> The hardware should not dynamically balance the load between CCS
> engines. Wa_16016805146 recommends disabling it across all
Is this the right workaround number? When I check the database, this
workaround was rejected on both DG2-G10
Hi Maxime,
On Thu, Feb 15, 2024 at 5:18 PM Maxime Ripard wrote:
> On Thu, Feb 15, 2024 at 01:50:09PM +0100, Geert Uytterhoeven wrote:
> > Using the Imagination Technologies PowerVR Series 6 GPU requires a
> > proprietary firmware image, which is currently only available for Texas
> > Instruments
Hi Doug,
On 15/02/2024 16:08, Doug Anderson wrote:
Hi,
On Thu, Feb 15, 2024 at 2:24 AM Jani Nikula wrote:
On Wed, 14 Feb 2024, Doug Anderson wrote:
Hi,
On Tue, Feb 13, 2024 at 10:25 PM Hsin-Yi Wang wrote:
On Wed, Feb 14, 2024 at 2:23 PM Douglas Anderson wrote:
If an eDP panel is
On Thu, Feb 15, 2024 at 11:37:54AM -0500, Harry Wentland wrote:
> Adding a couple of compositor devs as they might be interested in this.
>
> On 2024-02-14 06:24, Nemesa Garg wrote:
> > Many a times images are blurred or upscaled content is also not as
> > crisp as original rendered image.
>
> > Please drop this one.
> >
> > nore...@ellerman.id.au reported a build failure on m68k (and presumably
> > other 32-bit platforms) in next-20240215:
> >
> > ERROR: modpost: "__umoddi3" [drivers/gpu/drm/tests/drm_buddy_test.ko]
> >
On 2/15/2024 12:40 AM, Dmitry Baryshkov wrote:
On Wed, 14 Feb 2024 at 22:15, Abhinav Kumar wrote:
On 2/14/2024 11:39 AM, Dmitry Baryshkov wrote:
On Wed, 14 Feb 2024 at 20:04, Paloma Arellano wrote:
Add support to pack and send the VSC SDP packet for DP. This therefore
allows the
Adding a couple of compositor devs as they might be interested in this.
On 2024-02-14 06:24, Nemesa Garg wrote:
> Many a times images are blurred or upscaled content is also not as
> crisp as original rendered image. Traditional sharpening techniques often
> apply a uniform level of
Hi,
On Wed, Feb 14, 2024 at 1:41 PM Doug Anderson wrote:
>
> Hi,
>
> On Tue, Feb 13, 2024 at 11:24 PM Hsin-Yi Wang wrote:
> >
> > This reverts commit 70e0d5550f5cec301ad116703b840a539fe985dc.
> >
> > The overridden mode fixes the panel glitching issue on mt8186 chromebook.
> > However, it
On 2/15/2024 1:05 AM, Heiko Stuebner wrote:
From: Heiko Stuebner
The ltk101b4029w ist a 10.1 inch DSI panel and shares the same supplies
and startup timings with the existing ltk500hd1829.
So simply add it as a variant with its own init sequence and display-mode.
Signed-off-by: Heiko
On 2/15/2024 1:05 AM, Heiko Stuebner wrote:
From: Heiko Stuebner
There exist more dsi-panels from Leadtek sharing supplies and timings
with only the panel-mode and init commands differing.
So make room in the driver to also keep variants here instead of
requiring additional drivers per
Hi,
On Thu, Feb 15, 2024 at 01:50:09PM +0100, Geert Uytterhoeven wrote:
> Using the Imagination Technologies PowerVR Series 6 GPU requires a
> proprietary firmware image, which is currently only available for Texas
> Instruments K3 AM62x SoCs. Hence add a dependency on ARCH_K3, to
> prevent
(1):
> > drm/tests/drm_buddy: add alloc_contiguous test
>
> Please drop this one.
>
> nore...@ellerman.id.au reported a build failure on m68k (and presumably
> other 32-bit platforms) in next-20240215:
>
> ERROR: modpost: "__umoddi3" [drivers/gpu/drm/test
On Thu, 15 Feb 2024 14:24:15 +0100, Geert Uytterhoeven wrote:
> Fix misspellings of "hardware".
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
On 2/15/2024 12:45 AM, Dmitry Baryshkov wrote:
On Wed, 14 Feb 2024 at 20:04, Paloma Arellano wrote:
Adjust the encoder format programming in the case of video mode for DP
to accommodate CDM related changes.
Changes in v2:
- Move timing engine programming to a separate patch from
On Wed, Feb 14, 2024 at 11:34 PM Johan Hovold wrote:
>
> On Tue, Feb 13, 2024 at 09:23:40AM -0800, Rob Clark wrote:
> > From: Rob Clark
> >
> > The brute force iommu_flush_iotlb_all() was good enough for unmap, but
> > in some cases a map operation could require removing a table pte entry
> > to
To briefly summarize the issues reported by syzbot, there are two task call
stacks
as follows:
Task A Task B
--
drm_atomic_commit
Hi Dave, Sima,
Fixes for 6.8.
The following changes since commit 841c35169323cd833294798e58b9bf63fa4fa1de:
Linux 6.8-rc4 (2024-02-11 12:18:13 -0800)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
tags/amd-drm-fixes-6.8-2024-02-15
for you to fetch
On Thu, Feb 15, 2024 at 01:46:48PM +0200, Jani Nikula wrote:
> On Wed, 14 Feb 2024, Ville Syrjälä wrote:
> > On Tue, Feb 13, 2024 at 01:30:57PM +0200, Jani Nikula wrote:
> >> Rename intel_dp_can_mst() to intel_dp_mst_detect(), and move all DP MST
> >> detect debug logging there. Debug log the
Hi,
On Thu, Feb 15, 2024 at 2:24 AM Jani Nikula wrote:
>
> On Wed, 14 Feb 2024, Doug Anderson wrote:
> > Hi,
> >
> > On Tue, Feb 13, 2024 at 10:25 PM Hsin-Yi Wang wrote:
> >>
> >> On Wed, Feb 14, 2024 at 2:23 PM Douglas Anderson
> >> wrote:
> >> >
> >> > If an eDP panel is not powered on
On Thu, Feb 15, 2024 at 11:53:17AM +0100, Maxime Ripard wrote:
> On Tue, Feb 13, 2024 at 10:38:56AM +0200, Ville Syrjälä wrote:
> > On Mon, Feb 12, 2024 at 05:53:48PM +0100, Maxime Ripard wrote:
> > > On Mon, Feb 12, 2024 at 05:49:33PM +0200, Ville Syrjälä wrote:
> > > > On Mon, Feb 12, 2024 at
On Thursday, February 15, 2024 2:31:37 PM CET Linus Walleij wrote:
> On Tue, Feb 13, 2024 at 7:13 PM Duje Mihanović
wrote:
> > LEDS_EXPRESSWIRE depends on GPIOLIB, and so must anything selecting it:
> >
> > WARNING: unmet direct dependencies detected for LEDS_EXPRESSWIRE
> >
> > Depends on
On Thu, Feb 15, 2024 at 9:18 AM Christian König
wrote:
>
> Am 12.02.24 um 22:04 schrieb Alex Deucher:
> > We had a request to add shared buffer stats to fdinfo for amdgpu and
> > while implementing that, Christian mentioned that just looking at
> > the GEM handle count doesn't take into account
On Thu, 15 Feb 2024, Ville Syrjälä wrote:
> On Wed, Feb 14, 2024 at 03:57:54PM -0600, Mario Limonciello wrote:
>> +static int
>> +drm_do_probe_acpi_edid(void *data, u8 *buf, unsigned int block, size_t len)
>> +{
>> +struct drm_connector *connector = data;
>> +struct drm_device *ddev =
Am 12.02.24 um 22:04 schrieb Alex Deucher:
We had a request to add shared buffer stats to fdinfo for amdgpu and
while implementing that, Christian mentioned that just looking at
the GEM handle count doesn't take into account buffers shared with other
subsystems like V4L or RDMA. Those
On Wed, 14 Feb 2024, Mario Limonciello wrote:
> Some manufacturers have intentionally put an EDID that differs from
> the EDID on the internal panel on laptops. Drivers that prefer to
> fetch this EDID can set a bit on the drm_connector to indicate that
> the DRM EDID helpers should try to fetch
On Sat, 10 Feb 2024, Mario Limonciello wrote:
> Some manufacturers have intentionally put an EDID that differs from
> the EDID on the internal panel on laptops. Drivers that prefer to
> fetch this EDID can set a bit on the drm_connector to indicate that
> the DRM EDID helpers should try to fetch
Since CCS automatic load balancing is disabled, we will impose a
fixed balancing policy that involves setting all the CCS engines
to work together on the same load.
Simultaneously, the user will see only 1 CCS rather than the
actual number. As of now, this change affects only DG2.
Fixes:
The hardware should not dynamically balance the load between CCS
engines. Wa_16016805146 recommends disabling it across all
platforms.
Fixes: d2eae8e98d59 ("drm/i915/dg2: Drop force_probe requirement")
Signed-off-by: Andi Shyti
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Matt Roper
Cc: # v6.2+
Hi,
this series does basically two things:
1. Disables automatic load balancing as adviced by the hardware
workaround.
2. Forces the sharing of the load submitted to CCS among all the
CCS available (as of now only DG2 has more than one CCS). This
way the user, when sending a query,
On 15/02/2024 10:32, Dmitry Baryshkov wrote:
On Thu, 15 Feb 2024 at 11:29, Neil Armstrong wrote:
On 15/02/2024 10:25, Dmitry Baryshkov wrote:
On Thu, 15 Feb 2024 at 11:20, Neil Armstrong wrote:
Document the GPU SMMU found on the SM8650 platform.
Signed-off-by: Neil Armstrong
---
Convert open coded RMW accesses for LNKCTL2 to use
pcie_capability_clear_and_set_word() which makes its easier to
understand what the code tries to do.
LNKCTL2 is not really owned by any driver because it is a collection of
control bits that PCI core might need to touch. RMW accessors already
Convert open coded RMW accesses for LNKCTL2 to use
pcie_capability_clear_and_set_word() which makes its easier to
understand what the code tries to do.
LNKCTL2 is not really owned by any driver because it is a collection of
control bits that PCI core might need to touch. RMW accessors already
Convert open coded RMW accesses for LNKCTL2 to use
pcie_capability_clear_and_set_word() which makes its easier to
understand what the code tries to do.
LNKCTL2 is not really owned by any driver because it is a collection of
control bits that PCI core might need to touch. RMW accessors already
This series converts open-coded LNKCTL2 RMW accesses to use RMW
accessor. These patches used to be part of PCIe BW controller series
[1] which will require RMW ops to LNKCTL2 be properly locked.
However, since these RMW accessor patches are useful as cleanups on
their own I chose to send them now
On Tue, Feb 13, 2024 at 7:13 PM Duje Mihanović wrote:
> LEDS_EXPRESSWIRE depends on GPIOLIB, and so must anything selecting it:
>
> WARNING: unmet direct dependencies detected for LEDS_EXPRESSWIRE
> Depends on [n]: NEW_LEDS [=y] && GPIOLIB [=n]
> Selected by [m]:
> - BACKLIGHT_KTD2801 [=m]
Hi Dave, Sima,
here's the drm-misc-next PR for this week. The majority of changes
comes from Jani's update of the internal EDID callbacks, which the bridge
code now uses. There are also stability fixes for lima, improvements to
print helpers, correct parent devices for firmware framebuffers, and
To briefly summarize the issues reported by syzbot, there are two task call
stacks
as follows:
Task A Task B
--
drm_atomic_nonblocking_commit drm_atomic_commit
drm_atomic_helper_commit
Fix misspellings of "hardware".
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Neil Armstrong
Reviewed-by: Thomas Zimmermann
---
v2:
- Add Reviewed-by.
---
include/drm/drm_bridge.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_bridge.h
Using the Imagination Technologies PowerVR Series 6 GPU requires a
proprietary firmware image, which is currently only available for Texas
Instruments K3 AM62x SoCs. Hence add a dependency on ARCH_K3, to
prevent asking the user about this driver when configuring a kernel
without Texas Instruments
1 - 100 of 211 matches
Mail list logo
