https://bugzilla.kernel.org/show_bug.cgi?id=217664
popus_czy_to_ty (pentelja...@o2.pl) changed:
What|Removed |Added
Severity|normal |high
--
You may re
https://bugzilla.kernel.org/show_bug.cgi?id=217664
popus_czy_to_ty (pentelja...@o2.pl) changed:
What|Removed |Added
Component|Video(DRI - non Intel) |Power-Sleep-Wake
Hi Jason,
> > >
> > > > No, adding HMM_PFN_REQ_WRITE still doesn't help in fixing the issue.
> > > > Although, I do not have THP enabled (or built-in), shmem does not evict
> > > > the pages after hole punch as noted in the comment in
> shmem_fallocate():
> > >
> > > This is the source of all your
Hi Oak,
yeah, I completely agree with you and Felix. The main problem here is
getting the memory pressure visible on both sides.
At the moment I have absolutely no idea how to handle that, maybe
something like the ttm_resource object shared between TTM and HMM?
Regards,
Christian.
Am 16.08
Am 15.08.23 um 19:26 schrieb Hamza Mahfooz:
fbcon requires that we implement &drm_framebuffer_funcs.dirty.
Otherwise, the framebuffer might take a while to flush (which would
manifest as noticeable lag). However, we can't enable this callback for
non-fbcon cases since it might cause too many a
Am 15.08.23 um 19:10 schrieb Hamza Mahfooz:
fbcon requires that we implement &drm_framebuffer_funcs.dirty.
Otherwise, the framebuffer might take awhile to flush (which would
manifest as noticeable lag). However, we can't enable this callback for
non-fbcon cases since it might cause too many atomi
This is to eliminate all cases of "*ERROR* LSPCON mode hasn't settled",
followed by link training errors. Intel engineers recommended increasing
this timeout and that does resolve the issue.
On some CometLake-based device designs the Parade PS175 takes more than
400ms to settle in PCON mode. 100 r
[AMD Official Use Only - General]
Sorry, for the spam. Please ignore this.
Thanks,
Lijo
-Original Message-
From: amd-gfx On Behalf Of Lijo Lazar
Sent: Wednesday, August 16, 2023 9:37 AM
To: amd-...@lists.freedesktop.org
Cc: Deucher, Alexander ; s...@canb.auug.org.au;
airl...@redhat.com
GFXOFF feature is not there for GFX 9.4.3 ASICs.
Signed-off-by: Lijo Lazar
Reviewed-by: Hawking Zhang
---
drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c
index d8d6807
7957ec80ef97 ("drm/amdgpu: Add FRU sysfs nodes only if needed") moved
the documentation for some of the sysfs nodes to amdgpu_fru_eeprom.c.
Update the documentation accordingly.
Signed-off-by: Lijo Lazar
---
Documentation/gpu/amdgpu/driver-misc.rst | 6 +++---
1 file changed, 3 insertions(+), 3
Hi Felix,
It is great to hear from you!
When I implement the HMM-based SVM for intel devices, I found this interesting
problem: HMM uses struct page based memory management scheme which is
completely different against the BO/TTM style memory management philosophy.
Writing SVM code upon the BO/
Using kmemdup() helper function rather than implementing it again
with kmalloc() + memcpy(), which improves the code readability.
Signed-off-by: Chen Jiahao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/
Hi all,
On Tue, 15 Aug 2023 21:07:47 +1000 Stephen Rothwell
wrote:
>
> After merging the amdgpu tree, today's linux-next build (htmldocs)
> produced this warning:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1: warning: 'product_name' not
> found
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 98297fc6ecafc0c7eabc5d869279fb27609fcdc1 Add linux-next specific
files for 20230815
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202308081459.us5rlyay-...@intel.com
https
./drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_replay.c:94:102-107: WARNING:
conversion to bool not needed here
./drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_replay.c:102:72-77: WARNING:
conversion to bool not needed here
Signed-off-by: Yang Li
---
drivers/gpu/drm/amd/display/amdgpu_dm/
From: John Harrison
If GuC hits an internal error (and survives long enough to report it
to the KMD), it is basically toast and will stop until a GT reset and
subsequent GuC reload is performed. Previously, the KMD just printed
an error message and then waited for the heartbeat to eventually kick
Hi Oak,
I'm not sure what you're looking for from AMD? Are we just CC'ed FYI? Or
are you looking for comments about
* Our plans for VRAM management with HMM
* Our experience with BO-based VRAM management
* Something else?
IMO, having separate memory pools for HMM and TTM is a non-starter f
Currently, the vga_is_firmware_default() function only works on x86 and
ia64, it is a no-op on ARM, ARM64, PPC, RISC-V, etc. This patch completes
the implementation for the rest of the architectures. The added code tries
to identify the PCI(e) VGA device that owns the firmware framebuffer
before PC
On Tue, 2023-08-15 at 13:29 -0700, Teres Alexis, Alan Previn wrote:
> Update the max GSC-fw response time to match updated internal
> fw specs. Because this response time is an SLA on the firmware,
> not inclusive of i915->GuC->HW handoff latency, when submitting
> requests to the GSC fw via intel_
On 8/15/23 23:34, Helge Deller wrote:
On 8/4/23 13:32, Min-Hua Chen wrote:
Mark fbcon_registered_fb, and fbcon_num_registered_fb static
to fix the following sparse warnings:
drivers/video/fbdev/core/fbcon.c:105:16: sparse: warning: symbol
'fbcon_registered_fb' was not declared. Should it be st
On 8/4/23 13:32, Min-Hua Chen wrote:
Mark fbcon_registered_fb, and fbcon_num_registered_fb static
to fix the following sparse warnings:
drivers/video/fbdev/core/fbcon.c:105:16: sparse: warning: symbol
'fbcon_registered_fb' was not declared. Should it be static?
drivers/video/fbdev/core/fbcon.c:
On 8/3/23 09:10, Zhu Wang wrote:
Since platform_get_irq() never returned zero, so it need not to check
whether it returned zero, and we use the return error code of
platform_get_irq() to replace the current return error code.
Please refer to the commit a85a6c86c25b ("driver core: platform: Clari
On 8/11/23 09:28, Ruan Jinjie wrote:
The driver depends on CONFIG_OF, it is not necessary to use
of_match_ptr() here.
Signed-off-by: Ruan Jinjie
applied.
Thanks!
Helge
---
drivers/video/fbdev/atmel_lcdfb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/vide
On 8/14/23 16:05, Yue Haibing wrote:
These declarations is never implemented since the beginning of git history.
Signed-off-by: Yue Haibing
applied.
Thanks!
Helge
---
include/video/kyro.h | 12
1 file changed, 12 deletions(-)
diff --git a/include/video/kyro.h b/include/vid
Also + Christian
Thanks,
Oak
From: Intel-xe On Behalf Of Zeng, Oak
Sent: August 14, 2023 11:38 PM
To: Thomas Hellström ; Brost, Matthew
; Vishwanathapura, Niranjana
; Welty, Brian ;
Felix Kuehling ; Philip Yang ;
intel...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
Subject: [Intel
On Meteorlake onwards, HW specs require that all user contexts that
run on render or compute engines and require PXP must enforce
run-alone bit in lrc. Add this enforcement for protected contexts.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 25 +
Update the max GSC-fw response time to match updated internal
fw specs. Because this response time is an SLA on the firmware,
not inclusive of i915->GuC->HW handoff latency, when submitting
requests to the GSC fw via intel_gsc_uc_heci_cmd_submit_nonpriv,
start the count after the request hits the G
For MTL, update the GSC-HECI packet size and the max firmware
response timeout to match internal fw specs. Enforce setting
run-alone bit in LRC for protected contexts.
Changes from prio revs:
v2: - Patch #3: fix sparse warning reported by kernel test robot.
v1: - N/A (Re-test)
Signed-off-by
Update the GSC-fw input/output HECI packet size to match
updated internal fw specs.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
b/dr
On 7/29/2023 6:19 PM, Dmitry Baryshkov wrote:
Use devm_kzalloc to create MDP TOP structure. This allows us to remove
corresponding kfree and drop dpu_hw_mdp_destroy() function.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c | 17 +++--
drivers/g
On Tue, Aug 15, 2023 at 12:23 PM Dave Airlie wrote:
>
> > > Otherwise, there should be something like a drm-ci tree, from which you
> > > can fetch the changes directly.
> >
> > I asked for a pull request so that I could also merge it to msm-next
> > so that I can do CI this cycle. (Unlike the ea
Even if there's nothing currently parsing amdgpu's coredump files, if
we eventually have such tools they will be glad to find a version field
to properly read the file.
Create a version number to be displayed on top of coredump file, to be
incremented when the file format or content get changed.
Giving that we use codedump just for device resets, move it's functions
and structs to a more semantic file, the amdgpu_reset.{c, h}.
Signed-off-by: André Almeida
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 9 ---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 78 --
driv
Instead of storing coredump information inside amdgpu_device struct,
move if to a proper separated struct and allocate it dynamically. This
will make it easier to further expand the logged information.
Signed-off-by: André Almeida
---
v4: change kmalloc to kzalloc
---
drivers/gpu/drm/amd/amdgpu/
During a GPU reset, a normal memory reclaim could block to reclaim
memory. Giving that coredump is a best effort mechanism, it shouldn't
disturb the reset path. Change its memory allocation flag to a
nonblocking one.
Signed-off-by: André Almeida
Reviewed-by: Christian König
---
drivers/gpu/drm/
Hi,
The patches of this set are a rework to alloc devcoredump dynamically and to
move it to a better source file.
Thanks,
André
Changelog:
v3:
https://lore.kernel.org/dri-devel/20230810192330.198326-1-andrealm...@igalia.com/
- Changed from kmalloc to kzalloc
- Dropped "Create a module
> > Otherwise, there should be something like a drm-ci tree, from which you
> > can fetch the changes directly.
>
> I asked for a pull request so that I could also merge it to msm-next
> so that I can do CI this cycle. (Unlike the earlier out-of-tree
> version of the drm/ci yml, this version needs
On Wed, Aug 09, 2023 at 01:42:16PM +0200, Artur Weber wrote:
> Fixes the following warning:
>
> drivers/video/backlight/lp855x_bl.c:252:7: warning: variable 'ret' is used
> uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
>
> Signed-off-by: Artur Weber
> Fixes: 5145531b
On Tue, 2023-08-15 at 09:56 -0400, Vivi, Rodrigo wrote:
> On Mon, Aug 14, 2023 at 06:12:09PM -0700, Alan Previn wrote:
> > If we are at the end of suspend or very early in resume
> > its possible an async fence signal could lead us to the
> > execution of the context destruction worker (after the
>
Thanks Rodrigo - agreed on everything below - will re-rev.
On Tue, 2023-08-15 at 09:51 -0400, Vivi, Rodrigo wrote:
> On Mon, Aug 14, 2023 at 06:12:10PM -0700, Alan Previn wrote:
> > When suspending, add a timeout when calling
> > intel_gt_pm_wait_for_idle else if we have a lost
> > G2H event that
From: Pekka Paalanen
Specify how the atomic state is maintained between userspace and
kernel, plus the special case for async flips.
Signed-off-by: Pekka Paalanen
Signed-off-by: André Almeida
---
v5: Add note that not every redundant attribute will result in no-op
v4: total rework by Pekka
---
Given that prop changes may lead to modesetting, which would defeat the
fast path of the async flip, refuse any atomic prop change for async
flips in atomic API. The only exceptions are the framebuffer ID to flip
to and the mode ID, that could be referring to an identical mode.
Signed-off-by: Andr
From: Simon Ser
amdgpu_dm_commit_planes() already sets the flip_immediate flag for
async page-flips. This flag is used to set the UNP_FLIP_CONTROL
register. Thus, no additional change is required to handle async
page-flips with the atomic uAPI.
Signed-off-by: Simon Ser
Reviewed-by: André Almeid
From: Simon Ser
This new field indicates whether the driver has the necessary logic
to support async page-flips via the atomic uAPI. This is leveraged by
the next commit to allow user-space to use this functionality.
All atomic drivers setting drm_mode_config.async_page_flip are updated
to also
From: Simon Ser
This new kernel capability indicates whether async page-flips are
supported via the atomic uAPI. DRM clients can use it to check
for support before feeding DRM_MODE_PAGE_FLIP_ASYNC to the kernel.
Make it clear that DRM_CAP_ASYNC_PAGE_FLIP is for legacy uAPI only.
Signed-off-by:
From: Simon Ser
If the driver supports it, allow user-space to supply the
DRM_MODE_PAGE_FLIP_ASYNC flag to request an async page-flip.
Set drm_crtc_state.async_flip accordingly.
Document that drivers will reject atomic commits if an async
flip isn't possible. This allows user-space to fall back
Hi,
This work from me and Simon adds support for DRM_MODE_PAGE_FLIP_ASYNC through
the atomic API. This feature is already available via the legacy API. The use
case is to be able to present a new frame immediately (or as soon as
possible), even if after missing a vblank. This might result in teari
On 8/15/2023 12:26, Hamza Mahfooz wrote:
fbcon requires that we implement &drm_framebuffer_funcs.dirty.
Otherwise, the framebuffer might take a while to flush (which would
manifest as noticeable lag). However, we can't enable this callback for
non-fbcon cases since it might cause too many atomic
If DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT is invoked with the
DRM_SYNCOBJ_WAIT_FLAGS_WAIT_AVAILABLE flag set but no fence has yet been
submitted for the given timeline point the call will fail immediately
with EINVAL. This does not match the intended behavior where the call
should wait until the fence has
https://bugzilla.kernel.org/show_bug.cgi?id=211033
Žilvinas Žaltiena (zal...@natrix.lt) changed:
What|Removed |Added
Status|NEW |RESOLVED
R
fbcon requires that we implement &drm_framebuffer_funcs.dirty.
Otherwise, the framebuffer might take a while to flush (which would
manifest as noticeable lag). However, we can't enable this callback for
non-fbcon cases since it might cause too many atomic commits to be made
at once. So, implement a
https://bugzilla.kernel.org/show_bug.cgi?id=217797
Bug ID: 217797
Summary: [amdgpu/mm?] HSA_AMD_SVM=y causes/triggers PAT issues
Product: Drivers
Version: 2.5
Hardware: AMD
OS: Linux
Status: NEW
Severity:
fbcon requires that we implement &drm_framebuffer_funcs.dirty.
Otherwise, the framebuffer might take awhile to flush (which would
manifest as noticeable lag). However, we can't enable this callback for
non-fbcon cases since it might cause too many atomic commits to be made
at once. So, implement am
On 8/2/2023 8:59 AM, Jeffrey Hugo wrote:
From: Pranjal Ramajor Asha Kanojiya
The temporary buffer storing slicing configuration data from user is only
freed on error. This is a memory leak. Free the buffer unconditionally.
Fixes: ff13be830333 ("accel/qaic: Add datapath")
Signed-off-by: Pranj
On 8/10/2023 6:23 AM, Dan Carpenter wrote:
The encode_dma() function has some validation on in_trans->size but it
would be more clear to move those checks to find_and_map_user_pages().
The encode_dma() had two checks:
if (in_trans->addr + in_trans->size < in_trans->addr || !in_trans->si
Applied. Thanks!
On Tue, Aug 15, 2023 at 3:13 AM hongao wrote:
>
> [why]
> limit visible_vram_size to real_vram_size in case
> the PCI BAR is larger than the actual amount of vram.
>
> Signed-off-by: hongao
> ---
> drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c | 2 ++
> 1 file changed, 2 insertions(+)
On Tue, Aug 15, 2023 at 7:52 AM Juerg Haefliger
wrote:
>
> On Thu, 22 Jun 2023 21:44:25 +0300
> Dmitry Baryshkov wrote:
>
> > On 20/06/2023 08:40, Juerg Haefliger wrote:
> > > The driver references some firmware files that don't have corresponding
> > > MODULE_FIRMWARE macros and thus won't be li
On Tue, Aug 15, 2023 at 5:51 AM Thomas Zimmermann wrote:
>
> Hi Daniel
>
> Am 15.08.23 um 14:35 schrieb Daniel Vetter:
> > On Tue, 15 Aug 2023 at 14:31, Thomas Zimmermann wrote:
> >>
> >> Hi,
> >>
> >> thanks for your patchset.
> >>
> >> Am 15.08.23 um 13:53 schrieb Helen Mae Koike Fornazier:
> >
Hi,
See below some minor comments:
On Fri, Jun 23, 2023 at 06:23:47PM -0400, Jim Shargo wrote:
> VKMS now supports creating and using virtual devices!
>
> In addition to the enabling logic, this commit also prevents users from
> adding new objects once a card is registered.
>
> Signed-off-by: J
On Mon, Aug 14, 2023 at 06:12:09PM -0700, Alan Previn wrote:
> If we are at the end of suspend or very early in resume
> its possible an async fence signal could lead us to the
> execution of the context destruction worker (after the
> prior worker flush).
>
> Even if checking that the CT is enabl
On Mon, Aug 14, 2023 at 06:12:08PM -0700, Alan Previn wrote:
> When suspending, flush the context-guc-id
> deregistration worker at the final stages of
> intel_gt_suspend_late when we finally call gt_sanitize
> that eventually leads down to __uc_sanitize so that
> the deregistration worker doesn't
On Mon, Aug 14, 2023 at 06:12:10PM -0700, Alan Previn wrote:
> When suspending, add a timeout when calling
> intel_gt_pm_wait_for_idle else if we have a lost
> G2H event that holds a wakeref (which would be
> indicative of a bug elsewhere in the driver),
> driver will at least complete the suspend-
From: Mina Almasry
> Sent: 10 August 2023 02:58
...
> * TL;DR:
>
> Device memory TCP (devmem TCP) is a proposal for transferring data to and/or
> from device memory efficiently, without bouncing the data to a host memory
> buffer.
Doesn't that really require peer-to-peer PCIe transfers?
IIRC thes
Add a motivation for and description of asynchronous VM_BIND operation
v2:
- Fix typos (Nirmoy Das)
- Improve the description of a memory fence (Oak Zeng)
- Add a reference to the document in the Xe RFC.
- Add pointers to sample uAPI suggestions
v3:
- Address review comments (Danilo Krummrich)
- F
Hi,
-rc6 has been tagged for a few days. This means that drm-misc-next-fixes
is now open for bug fixes, as drm-next is in feature freeze until the
next -rc1 comes out.
Some rules of thumb on where to land your patch:
* if your patch fixes a bug in upstream, please put it into
drm-misc-
Hi Daniel
Am 15.08.23 um 14:35 schrieb Daniel Vetter:
On Tue, 15 Aug 2023 at 14:31, Thomas Zimmermann wrote:
Hi,
thanks for your patchset.
Am 15.08.23 um 13:53 schrieb Helen Mae Koike Fornazier:
On Tuesday, August 15, 2023 06:12 -03, Jani Nikula
wrote:
On Mon, 14 Aug 2023, Helen Koike
On Tue, 15 Aug 2023 at 14:31, Thomas Zimmermann wrote:
>
> Hi,
>
> thanks for your patchset.
>
> Am 15.08.23 um 13:53 schrieb Helen Mae Koike Fornazier:
> > On Tuesday, August 15, 2023 06:12 -03, Jani Nikula
> > wrote:
> >
> >> On Mon, 14 Aug 2023, Helen Koike wrote:
> >>> The following changes
On Tue, 15 Aug 2023, Jani Nikula wrote:
> On Tue, 15 Aug 2023, "Helen Mae Koike Fornazier"
> wrote:
>> On Tuesday, August 15, 2023 06:12 -03, Jani Nikula
>> wrote:
>>
>>> On Mon, 14 Aug 2023, Helen Koike wrote:
>>> > The following changes since commit
>>> > f5d8f9c0d8b4bc8ad7e7b23a9f4d116e99
https://bugzilla.kernel.org/show_bug.cgi?id=201957
Timon Z. (kernel@timonz.de) changed:
What|Removed |Added
CC||kernel@timonz.de
--
On Tue, 15 Aug 2023, "Helen Mae Koike Fornazier"
wrote:
> On Tuesday, August 15, 2023 06:12 -03, Jani Nikula
> wrote:
>
>> On Mon, 14 Aug 2023, Helen Koike wrote:
>> > The following changes since commit
>> > f5d8f9c0d8b4bc8ad7e7b23a9f4d116e99202dd3:
>> >
>> > drm/panel: JDI LT070ME05000 sim
Hi,
thanks for your patchset.
Am 15.08.23 um 13:53 schrieb Helen Mae Koike Fornazier:
On Tuesday, August 15, 2023 06:12 -03, Jani Nikula
wrote:
On Mon, 14 Aug 2023, Helen Koike wrote:
The following changes since commit f5d8f9c0d8b4bc8ad7e7b23a9f4d116e99202dd3:
drm/panel: JDI LT070ME05
Hi Michel,
Thank you for the feedback (comments below).
On Tue, 2023-08-08 at 15:46 +0200, Michel Dänzer wrote:
> On 7/14/23 16:25, Sarah Walker wrote:
> > +/**
> > + * DOC: PowerVR IOCTL CREATE_BO interface
> > + */
> > +
> > +/**
> > + * DOC: Flags for CREATE_BO
> > + *
> > + * The &struct drm_
On Thu, 22 Jun 2023 21:44:25 +0300
Dmitry Baryshkov wrote:
> On 20/06/2023 08:40, Juerg Haefliger wrote:
> > The driver references some firmware files that don't have corresponding
> > MODULE_FIRMWARE macros and thus won't be listed via modinfo. Fix that.
> >
> > Signed-off-by: Juerg Haefliger
On Tuesday, August 15, 2023 06:12 -03, Jani Nikula
wrote:
> On Mon, 14 Aug 2023, Helen Koike wrote:
> > The following changes since commit f5d8f9c0d8b4bc8ad7e7b23a9f4d116e99202dd3:
> >
> > drm/panel: JDI LT070ME05000 simplify with dev_err_probe() (2023-08-14
> > 14:44:30 +0200)
> >
> > are a
Hi,
See below some comments about vkms_wb_atomic_commit().
On Fri, Jun 23, 2023 at 06:23:44PM -0400, Jim Shargo wrote:
> This change supports multiple CRTCs, encoders, connectors instead of one
> of each per device.
>
> Since ConfigFS-based devices will support multiple crtcs, it's useful to
> m
Hi Maxime
On Mon, 14 Aug 2023 at 14:56, Maxime Ripard wrote:
>
> Infoframes in KMS is usually handled by a bunch of low-level helpers
> that require quite some boilerplate for drivers. This leads to
> discrepancies with how drivers generate them, and which are actually
> sent.
>
> Now that we hav
Hello,
I'm currently trying to get the TC9595 (tc358767.c) running on my imx93
platform. For probing the EDID/DPCD information I need to put the DSI lanes
into LP-11 (stop) state.
For this I was trying to call drm_atomic_bridge_chain_pre_enable() inside
tc_connector_get_modes(), if bridge is no
This reverts commit ca62297b2085b5b3168bd891ca24862242c635a1.
Commit ca62297b2085 ("drm/edid: Fix csync detailed mode parsing") fixed
EDID detailed mode sync parsing. Unfortunately, there are quite a few
displays out there that have bogus (zero) sync field that are broken by
the change. Zero means
On Mon, 14 Aug 2023 17:06:02 +0200,
Takashi Iwai wrote:
>
> On Mon, 14 Aug 2023 16:51:08 +0200,
> Karol Herbst wrote:
> >
> > I've sent a patch out to address this memory corruption
> > https://patchwork.freedesktop.org/patch/552642/
> >
> > It might or might not fix regressions from the origina
On Thu, 20 Jul 2023 at 15:54, Imre Deak wrote:
>
> 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 disabled for all connectors and hence
> output_poll_work was not running).
>
>
On Mon, 14 Aug 2023, Maxime Ripard wrote:
> A lot of the various HDMI drivers duplicate some logic that depends on
> the HDMI spec itself and not really a particular hardware
> implementation.
>
> Output BPC or format selection, infoframe generation are good examples
> of such areas.
>
> This crea
On 2023/8/15 16:36, Muchun Song wrote:
On Aug 7, 2023, at 19:08, Qi Zheng wrote:
The following functions are only used inside the mm subsystem, so it's
better to move their declarations to the mm/internal.h file.
1. shrinker_debugfs_add()
2. shrinker_debugfs_detach()
3. shrinker_debugfs_
On Mon, 14 Aug 2023, Helen Koike wrote:
> The following changes since commit f5d8f9c0d8b4bc8ad7e7b23a9f4d116e99202dd3:
>
> drm/panel: JDI LT070ME05000 simplify with dev_err_probe() (2023-08-14
> 14:44:30 +0200)
>
> are available in the Git repository at:
>
> g...@gitlab.freedesktop.org:helen.
On Mon, 14 Aug 2023, Imre Deak wrote:
> On Sun, Aug 13, 2023 at 03:41:30PM +0200, Linux regression tracking (Thorsten
> Leemhuis) wrote:
> Hi,
>
>> On 11.08.23 20:10, Mikhail Rudenko wrote:
>> > On 2023-08-11 at 08:45 +02, Thorsten Leemhuis
>> > wrote:
>> >> On 10.08.23 21:33, Mikhail Rudenko w
On Fri, Aug 4, 2023 at 3:29 PM AngeloGioacchino Del Regno
wrote:
>
> Add support for 12-bit gamma lookup tables and introduce the first
> user for it: MT8195.
> While at it, also reorder the variables in mtk_gamma_set_common()
> and rename `lut_base` to `lut0_base` to improve readability.
>
> Sign
[why]
limit visible_vram_size to real_vram_size in case
the PCI BAR is larger than the actual amount of vram.
Signed-off-by: hongao
---
drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c
b/drivers/gpu/drm/amd/amdgpu/
Hi Brandon,
Is Jim Shargo no longer able to follow-up with these anymore? Can you
reach out to him? Maybe he's on holiday/vacation at this point?
If you decide to follow-up we need a v3 -- and possibly a few more, but
I'd just focus on getting the ConfigFS infrastructure in, addressing
current co
88 matches
Mail list logo
