Em 17/08/2023 12:26, Shashank Sharma escreveu:
On 17/08/2023 17:17, André Almeida wrote:
Em 17/08/2023 12:04, Shashank Sharma escreveu:
On 17/08/2023 15:45, André Almeida wrote:
Hi Shashank,
Em 17/08/2023 03:41, Shashank Sharma escreveu:
Hello Andre,
On 15/08/2023 21:50, André
https://bugzilla.kernel.org/show_bug.cgi?id=217664
--- Comment #16 from Alex Deucher (alexdeuc...@gmail.com) ---
Does suspend work with gpu drivers backlisted?
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=217664
--- Comment #17 from Alex Deucher (alexdeuc...@gmail.com) ---
*blacklisted
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
On Thu, Aug 17, 2023 at 03:39:40PM +0200, Christian König wrote:
> Am 11.08.23 um 04:31 schrieb Matthew Brost:
> > Rather than call free_job and run_job in same work item have a dedicated
> > work item for each. This aligns with the design and intended use of work
> > queues.
>
> I would rather
Am 11.08.23 um 04:31 schrieb Matthew Brost:
Rather than call free_job and run_job in same work item have a dedicated
work item for each. This aligns with the design and intended use of work
queues.
I would rather say we should get completely rid of the free_job callback.
Essentially the job
Hi Dave and Daniel,
I'm covering for Tvrtko on this week's fixes flow.
These 3 patches were queued since last week, but I had hold
because I had some doubts about the CI results.
I have confirmed those issues were not related to these 3
patches, so, here they are.
drm-intel-fixes-2023-08-17:
-
Dear Linux folks,
Using the ten inch tablet Lenovo IdeaPad Duet Chromebook 2in1 with
recent ChromeOS, connecting a Dell DA200 (strange display chip inside)
or Dell DA300z the available resolutions are limited to 1280x720 and not
the supported 1920x1080. The Dell monitor is connected over
Am 17.08.23 um 14:48 schrieb Danilo Krummrich:
On 8/17/23 15:35, Christian König wrote:
Am 17.08.23 um 13:13 schrieb Danilo Krummrich:
On 8/17/23 07:33, Christian König wrote:
[SNIP]
My proposal would be to just keep the hw_submission_limit (maybe
rename it to submission_unit_limit) and add
The helper intel_dp_dsc_compute_bpp gives the maximum
pipe bpp that is allowed with DSC.
Rename the this to reflect that it returns max pipe bpp supported
with DSC.
Signed-off-by: Ankit Nautiyal
Reviewed-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/display/intel_dp.c | 8
For MST the bpc is hardcoded to 8, and pipe bpp to 24.
So avoid forcing DSC bpc for MST case.
v2: Warn and ignore the debug flag than to bail out. (Jani)
v3: Fix dbg message to mention forced bpc instead of bpp.
v4: Fix checkpatch longline warning.
Signed-off-by: Ankit Nautiyal
Reviewed-by:
Use checks for src and sink limits before computing compressed bpp for
eDP.
Signed-off-by: Ankit Nautiyal
Reviewed-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/display/intel_dp.c | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git
As per Bsepc:49259, Bigjoiner BW check puts restriction on the
compressed bpp for a given CDCLK, pixelclock in cases where
Bigjoiner + DSC are used.
Currently compressed bpp is computed first, and it is ensured that
the bpp will work at least with the max CDCLK freq.
Since the CDCLK is computed
Pull the code to get joiner constraints on maximum compressed bpp into
separate function.
Signed-off-by: Ankit Nautiyal
Reviewed-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/display/intel_dp.c | 54 ++---
1 file changed, 30 insertions(+), 24 deletions(-)
diff --git
The final link bpp used to calculate the m_n values depend on the
output_format. Though the output_format is set to RGB for MST case and
the link bpp will be same as the pipe bpp, for the sake of semantics,
lets calculate the m_n values with the link bpp, instead of pipe_bpp.
Signed-off-by: Ankit
Separate out functions for getting maximum and minimum input BPC based
on platforms, when DSC is used.
v2: Use HAS_DSC macro instead of platform check while getting min input
bpc. (Stan)
Signed-off-by: Ankit Nautiyal
Reviewed-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/display/intel_dp.c
While using DSC the compressed bpp is computed assuming RGB output
format. Consider the output_format and compute the compressed bpp
during mode valid and compute config steps.
For DP-MST we currently use RGB output format only, so continue
using RGB while computing compressed bpp for MST case.
Move the check for limiting compressed bits_per_pixel for 420,422
formats in the helper to compute bits_per_pixel.
v2: Fix typo in commit message. (Ankit)
Signed-off-by: Ankit Nautiyal
Reviewed-by: Arun R Murthy
---
drivers/gpu/drm/i915/display/intel_dp.c | 18 +-
1 file
On Wed, Aug 16, 2023 at 11:49:31PM -0700, Vivek Kasireddy wrote:
> This patch series adds support for migrating pages associated with
> a udmabuf out of the movable zone or CMA to avoid breaking features
> such as memory hotunplug.
>
> The first patch exports check_and_migrate_movable_pages()
On Thu, Aug 17, 2023 at 12:24:45PM +0200, Karol Herbst wrote:
> simply throw a
>
> printk(KERN_WARNING "nvkm_uconn_uevent %u\n", outp->info.location);
>
> inside drivers/gpu/drm/nouveau/nvkm/engine/disp/uconn.c:104 after that
> mentioned comment.
diff --git
There's an obvious copy-paste error in the description of
output_bus_cfg. Fix it.
Fixes: f32df58acc68 ("drm/bridge: Add the necessary bits to support bus format
negotiation")
Signed-off-by: Douglas Anderson
---
include/drm/drm_atomic.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
These declarations are not implemented now, remove them.
Signed-off-by: Yue Haibing
---
drivers/gpu/drm/gma500/gma_display.h | 1 -
drivers/gpu/drm/gma500/psb_intel_drv.h | 14 --
2 files changed, 15 deletions(-)
diff --git a/drivers/gpu/drm/gma500/gma_display.h
Hi
Am 15.08.23 um 21:59 schrieb Rob Clark:
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
Em 17/08/2023 12:04, Shashank Sharma escreveu:
On 17/08/2023 15:45, André Almeida wrote:
Hi Shashank,
Em 17/08/2023 03:41, Shashank Sharma escreveu:
Hello Andre,
On 15/08/2023 21:50, André Almeida wrote:
Instead of storing coredump information inside amdgpu_device struct,
move if to a
On 08/08/2023 02:49, Abhinav Kumar wrote:
On 6/4/2023 7:45 AM, Dmitry Baryshkov wrote:
The atomic_mode_set() callback only sets the phys_enc's IRQ data. As the
INTF and WB are statically allocated to each encoder/phys_enc, drop the
atomic_mode_set callback and set the IRQs during encoder
Hi,
Here's this week drm-misc-fixes PR
Maxime
drm-misc-fixes-2023-08-17:
One EPROBE_DEFER handling fix for the JDI LT070ME05000, a timing fix for
the AUO G121EAN01 panel, an integer overflow and a memory leak fixes for
the qaic accel, a use-after-free fix for nouveau and a revert for an
alleged
On 8/17/23 15:35, Christian König wrote:
Am 17.08.23 um 13:13 schrieb Danilo Krummrich:
On 8/17/23 07:33, Christian König wrote:
[SNIP]
The hardware seems to work mostly the same for all vendors, but you
somehow seem to think that filling the ring is somehow beneficial
which is really not
Enable the onboard displayport controller, connect it to QMP PHY.
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/qrb5165-rb5.dts | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
b/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
Add displayport altmode declaration to the Type-C controller node to
enable DP altmode negotiation.
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/qrb5165-rb5.dts | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
Implement DisplayPort support for the Qualcomm RB5 platform.
Note: while testing this, I had link training issues with several
dongles with DP connectors. Other DisplayPort-USB-C dongles (with HDMI
or VGA connectors) work perfectly.
Dependencies: [1]
Soft-dependencies: [2], [3]
[1]
Add the nb7vpq904m, onboard USB-C redriver / retimer.
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/qrb5165-rb5.dts | 52 +++-
1 file changed, 50 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
Declare the displayport controller present on the Qualcomm SM8250 SoC.
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/sm8250.dtsi | 89
1 file changed, 89 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi
Hey Jani,
On 8/17/23 15:05, Jani Nikula wrote:
On Thu, 17 Aug 2023, Dirk Lehmann wrote:
VESA Enhanced EDID Standard does not clearly describe how display
panel vendors should setup the Sync Signal Defintions (bit 4 & 3) in
the Detailed Timing Definition (relative offset 17, absolute offset
On 8/16/23 21:47, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20230816:
>
on risc-v 32-bit:
when
# CONFIG_MMU is not set
WARNING: unmet direct dependencies detected for DRM_TTM
Depends on [n]: HAS_IOMEM [=y] && DRM [=y] && MMU [=n]
Selected by [y]:
- DRM_TTM_KUNIT_TEST [=y]
Currently there are many places where we use output_bpp for link bpp and
compressed bpp.
Lets use consistent naming:
output_bpp : The intermediate value taking into account the
output_format chroma subsampling.
compressed_bpp : target bpp for the DSC encoder.
link_bpp : final bpp used in the link.
Currently we check if the pipe_bpp selected is >= the
min DSC bpc/bpp requirement. We do not check if it is <= the max DSC
bpc/bpp requirement.
Add checks for max DSC BPC/BPP constraints while computing the
pipe_bpp when DSC is in use.
v2: Fix the commit message.
Signed-off-by: Ankit Nautiyal
To make way for fractional bpp support, avoid left shifting the
output_bpp by 4 in helper intel_dp_dsc_get_output_bpp.
Signed-off-by: Ankit Nautiyal
Reviewed-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/display/intel_dp.c | 10 +++---
drivers/gpu/drm/i915/display/intel_dp_mst.c |
Currently for testing an output format with DSC, we just force the
output format, without checking if it can be supported.
This also creates an issue where there is a PCON which might need to
convert from forced output format to the format to sink format.
Signed-off-by: Ankit Nautiyal
Refactor code to separate functions for eDP and DP for computing
pipe_bpp/compressed bpp when DSC is involved.
This will help to optimize the link configuration for DP later.
v2: Fix checkpatch warning.
Signed-off-by: Ankit Nautiyal
Reviewed-by: Stanislav Lisovskiy
---
Currently, we take the max lane, rate and pipe bpp, to get the maximum
compressed bpp possible. We then set the output bpp to this value.
This patch provides support to have max bpp, min rate and min lanes,
that can support the min compressed bpp.
v2:
-Avoid ending up with compressed bpp, same as
This series is an attempt to address multiple issues with DSC,
scattered in separate existing series.
Patches 1-4 are DSC fixes from series to Handle BPC for HDMI2.1 PCON
https://patchwork.freedesktop.org/series/107550/
Patches 5-6 are from series DSC fixes for Bigjoiner:
DSC compressed bpp and slice counts are already getting printed at the
end of dsc compute config. Remove extra logs.
Signed-off-by: Ankit Nautiyal
Reviewed-by: Arun R Murthy
---
drivers/gpu/drm/i915/display/intel_dp.c | 3 ---
1 file changed, 3 deletions(-)
diff --git
In Bigjoiner check for DSC, bigjoiner interface bits for DP for
DISPLAY > 13 is 36 (Bspec: 49259).
v2: Corrected Display ver to 13.
v3: Follow convention for conditional statement. (Ville)
v4: Fix check for display ver. (Ville)
v5: Added note for 2 PPC. (Stan)
Signed-off-by: Ankit Nautiyal
For DSC the min BPC is 8 for ICL+ and so the min pipe_bpp is 24.
Check this condition for cases where bpc is forced by debugfs flag
dsc_force_bpc. If the check fails, then WARN and ignore the debugfs
flag.
For MST case the pipe_bpp is already computed (hardcoded to be 24),
and this check is not
Hi Manikandan,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on lee-mfd/for-mfd-next lee-leds/for-leds-next
lee-mfd/for-mfd-fixes linus/master v6.5-rc6 next-20230817]
[If your patch is applied to the wrong
Hi Manikandan,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on lee-mfd/for-mfd-next lee-leds/for-leds-next
lee-mfd/for-mfd-fixes linus/master v6.5-rc6 next-20230817]
[If your patch is applied to the wrong
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 47762f08697484cf0c2f2904b8c52375ed26c8cb Add linux-next specific
files for 20230817
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202307281049.40t8s0uv-...@intel.com
https
Simon, Laurent,
On 03/08/2023 23:46, Simon Ser wrote:
On Thursday, August 3rd, 2023 at 22:44, Laurent Pinchart
wrote:
On Thu, Aug 03, 2023 at 03:31:16PM +, Simon Ser wrote:
On Thursday, August 3rd, 2023 at 17:22, Simon Ser cont...@emersion.fr wrote:
The KMS docs describe
Am 17.08.23 um 13:13 schrieb Danilo Krummrich:
On 8/17/23 07:33, Christian König wrote:
[SNIP]
The hardware seems to work mostly the same for all vendors, but you
somehow seem to think that filling the ring is somehow beneficial
which is really not the case as far as I can see.
I think
Switch to using the new DRM_AUX_BRIDGE helper to create the
transparent DRM bridge device instead of handcoding corresponding
functionality.
Reviewed-by: Heikki Krogerus
Signed-off-by: Dmitry Baryshkov
---
drivers/usb/typec/mux/Kconfig | 2 +-
drivers/usb/typec/mux/nb7vpq904m.c | 44
Switch to using the new DRM_AUX_BRIDGE helper to create the
transparent DRM bridge device instead of handcoding corresponding
functionality.
Signed-off-by: Dmitry Baryshkov
---
drivers/phy/qualcomm/Kconfig | 2 +-
drivers/phy/qualcomm/phy-qcom-qmp-combo.c | 44
Define a helper for creating simple transparent bridges which serve the
only purpose of linking devices into the bridge chain up to the last
bridge representing the connector. This is especially useful for
DP/USB-C bridge chains, which can span across several devices, but do
not require any
Supporting DP/USB-C can result in a chain of several transparent
bridges (PHY, redrivers, mux, etc). This results in drivers having
similar boilerplate code for such bridges.
Next, these drivers are susceptible to -EPROBE_DEFER loops: the next
bridge can either be probed from the bridge->attach
On Fri, Aug 11, 2023 at 09:41:50AM -0500, Chris Morgan wrote:
> On Thu, Aug 10, 2023 at 05:24:09PM -0600, Rob Herring wrote:
> > On Wed, Aug 09, 2023 at 10:39:40AM -0500, Chris Morgan wrote:
> > > From: Chris Morgan
> > >
> > > Document the Anbernic RG351V panel, which appears to be identical to
On 17/08/2023 15:45, André Almeida wrote:
Hi Shashank,
Em 17/08/2023 03:41, Shashank Sharma escreveu:
Hello Andre,
On 15/08/2023 21:50, André Almeida wrote:
Instead of storing coredump information inside amdgpu_device struct,
move if to a proper separated struct and allocate it
Hi Dave and Daniel,
this is the PR for drm-misc-next-fixes.
Best regards
Thomas
drm-misc-next-fixes-2023-08-17:
Short summary of fixes pull:
* Add MMU dependency to TTM unit tests
* panel: Fix Innolux G156HCE-L01 LVDS clock
The following changes since commit
On 8/17/2023 3:19 PM, Jani Nikula wrote:
On Thu, 10 Aug 2023, Ankit Nautiyal wrote:
This series is an attempt to address multiple issues with DSC,
scattered in separate existing series.
I think it's a good idea to have one person manage the series, and
combine it all together, because it
https://bugzilla.kernel.org/show_bug.cgi?id=201847
--- Comment #6 from Simon Fogliato (simonfogli...@gmail.com) ---
I copied my info and created an issue here:
https://gitlab.freedesktop.org/drm/nouveau/-/issues/256
--
You may reply to this email to add a comment.
You are receiving this mail
On 17/08/2023 17:17, André Almeida wrote:
Em 17/08/2023 12:04, Shashank Sharma escreveu:
On 17/08/2023 15:45, André Almeida wrote:
Hi Shashank,
Em 17/08/2023 03:41, Shashank Sharma escreveu:
Hello Andre,
On 15/08/2023 21:50, André Almeida wrote:
Instead of storing coredump information
Hi,
On Sun, Jul 30, 2023 at 09:41:20PM +0300, David Heidelberg wrote:
> i.MX8MQ uses as secondary compatible fsl,imx6sx-lcdif, which triggers
> requirement of power-domains, thou it's not required.
>
> Fixes: f62678a77d58 ("dt-bindings: mxsfb: Document i.MX8M/i.MX6SX/i.MX6SL
> power-domains
For fractional bpp values passed to the function in a .4 fixed point
format, the fractional part is currently ignored due to scaling bpp too
early. Fix this by scaling the overhead factor instead and to avoid an
overflow multiplying bpp with the overhead factor instead of the clock
rate.
While at
Add a way for drivers to calculate the MST PBN values with FEC overhead.
This is required by 8b/10b links both for DSC and non-DSC (the latter
needed if there are both DSC and non-DSC streams on the same MST link).
Also add kunit test cases for PBN values calculated with FEC overhead.
Cc: Lyude
Factor out a helper to check the atomic state for one MST topology
manager, returning the MST port where the BW limit check has failed.
This will be used in a follow-up patch by the i915 driver to improve the
BW sharing between MST streams.
Cc: Lyude Paul
Cc: dri-devel@lists.freedesktop.org
drm_dp_mst_atomic_check_mgr() should check for BW limitation starting
from sink ports continuing towards the root port, so that drivers can
use the @failing_port returned to resolve a BW overallocation in an
ideal way. For instance from streams A,B,C in a topology A,B going
through @failing_port
Add drm_dp_mst_port_downstream_of_parent() required by the i915
driver in a follow-up patch to resolve a BW overallocation of MST
streams going through a given MST port.
Cc: Lyude Paul
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Imre Deak
---
https://bugzilla.kernel.org/show_bug.cgi?id=217664
--- Comment #15 from popus_czy_to_ty (pentelja...@o2.pl) ---
https://www.youtube.com/watch?v=8ttEvWNcMXM
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
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
---
v5: no change
v4: change kmalloc to kzalloc
---
To better organize struct amdgpu_device, keep all reset information
related fields together in a separated struct.
Signed-off-by: André Almeida
---
v5: new patch, as requested by Shashank Sharma
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 34 +
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
---
v5: no change
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 9 ---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 78
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.
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
---
v5: no change
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:
v4:
https://lore.kernel.org/dri-devel/20230815195100.294458-1-andrealm...@igalia.com/
- New patch to encapsulate all reset info in a struct
v3:
On 8/17/2023 11:50 AM, Dmitry Baryshkov wrote:
On 08/08/2023 02:49, Abhinav Kumar wrote:
On 6/4/2023 7:45 AM, Dmitry Baryshkov wrote:
The atomic_mode_set() callback only sets the phys_enc's IRQ data. As the
INTF and WB are statically allocated to each encoder/phys_enc, drop the
Hi,
This is your friendly bug reporter.
The environment is vanilla torvalds tree kernel on Ubuntu 22.04 LTS and a Ryzen
7950X box.
Please find attached the complete dmesg output from the ring buffer and lshw
output.
NOTE: The kernel reports tainted kernel, but to my knowledge there are no
On 8/17/23 14:30, Kees Cook wrote:
Prepare for the coming implementation by GCC and Clang of the __counted_by
attribute. Flexible array members annotated with __counted_by can have
their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
(for array indexing) and
On Thu, Aug 17, 2023 at 11:04 AM Pavel Begunkov wrote:
>
> On 8/14/23 02:12, David Ahern wrote:
> > On 8/9/23 7:57 PM, Mina Almasry wrote:
> >> Changes in RFC v2:
> >> --
> ...
> >> ** Test Setup
> >>
> >> Kernel: net-next with this RFC and memory provider API cherry-picked
> >>
Hi,
On 2023/8/18 06:08, Bjorn Helgaas wrote:
+ if (resource_type(res) != IORESOURCE_MEM)
+ continue;
+
+ if (!res->start || !res->end)
+ continue;
+
+ if (res->start <= fb_start && fb_end <= res->end) {
+
...
> +static struct
> +drm_plane_state *virtio_gpu_plane_duplicate_state(struct drm_plane *plane)
> +{
> + struct virtio_gpu_plane_state *new;
> +
> + if (WARN_ON(!plane->state))
> + return NULL;
When plane->state can be NULL?
> + new = kzalloc(sizeof(*new), GFP_KERNEL);
On 7/13/23 01:44, Dongwon Kim wrote:
> This helper is needed for framebuffer synchronization. Old framebuffer data
> is often displayed on the guest display without this helper.
>
> Cc: Gerd Hoffmann
> Cc: Vivek Kasireddy
> Signed-off-by: Dongwon Kim
> ---
>
From: Zack Rusin
vmw_bo_unreference sets the input buffer to null on exit, resulting in
null ptr deref's on the subsequent drm gem put calls.
This went unnoticed because only very old userspace would be exercising
those paths but it wouldn't be hard to hit on old distros with brand
new kernels.
DP DSC Receiver Capabilities are exposed via DPCD 60h-6Fh.
Fix the DSC RECEIVER CAP SIZE accordingly.
Fixes: ffddc4363c28 ("drm/dp: Add DP DSC DPCD receiver capability size define
and missing SHIFT")
Cc: Anusha Srivatsa
Cc: Manasi Navare
Cc: # v5.0+
Signed-off-by: Ankit Nautiyal
Hi Shashank,
Em 17/08/2023 03:41, Shashank Sharma escreveu:
Hello Andre,
On 15/08/2023 21:50, André Almeida wrote:
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
VESA Enhanced EDID Standard does not clearly describe how display
panel vendors should setup the Sync Signal Defintions (bit 4 & 3) in
the Detailed Timing Definition (relative offset 17, absolute offset
47h[+18]) for Digital Video Signal Interfaces (bit 7 at offset 14h).
In practice many eDP
Don't assume that only the driver would be accessing LNKCTL2. In the
case of upstream (parent), the driver does not even own the device it's
changing the registers for.
Use RMW capability accessors which do proper locking to avoid losing
concurrent updates to the register value. This change is
Don't assume that only the driver would be accessing LNKCTL2. In the
case of upstream (parent), the driver does not even own the device it's
changing the registers for.
Use RMW capability accessors which do proper locking to avoid losing
concurrent updates to the register value. This change is
From: Jani Nikula
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
On 17/08/2023 17:38, André Almeida wrote:
Em 17/08/2023 12:26, Shashank Sharma escreveu:
On 17/08/2023 17:17, André Almeida wrote:
Em 17/08/2023 12:04, Shashank Sharma escreveu:
On 17/08/2023 15:45, André Almeida wrote:
Hi Shashank,
Em 17/08/2023 03:41, Shashank Sharma escreveu:
On 08/08/2023 00:40, Jessica Zhang wrote:
On 8/2/2023 11:20 AM, Dmitry Baryshkov wrote:
On Wed, 2 Aug 2023 at 21:09, Jessica Zhang
wrote:
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
index
On 16/08/2023 10:51, neil.armstr...@linaro.org wrote:
Hi Abhinav,
On 14/08/2023 20:02, Abhinav Kumar wrote:
Hi Neil
On 8/14/2023 1:01 AM, neil.armstr...@linaro.org wrote:
Hi Abhinav,
On 10/08/2023 18:26, Abhinav Kumar wrote:
Hi Neil
On 8/3/2023 10:19 AM, Jessica Zhang wrote:
On
Prepare for the coming implementation by GCC and Clang of the __counted_by
attribute. Flexible array members annotated with __counted_by can have
their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
(for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family
On Thu, Aug 17, 2023 at 1:59 PM Fabio Estevam wrote:
>
> Hi Tim,
>
> On Thu, Aug 17, 2023 at 5:53 PM Tim Harvey wrote:
>
> > Frieder,
> >
> > Sorry for the delay. Yes this resolves the regression I ran into. I
> > tested it on top of v6.5-rc6 on a gw72xx-0x with a DFROBOT DRF0678 7in
> > 800x480
The driver depends on CONFIG_OF, it is not necessary to use
of_match_ptr() here.
Signed-off-by: Ruan Jinjie
Reviewed-by: Daniel Thompson
---
drivers/video/backlight/led_bl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/backlight/led_bl.c
https://bugzilla.kernel.org/show_bug.cgi?id=217664
popus_czy_to_ty (pentelja...@o2.pl) changed:
What|Removed |Added
Kernel Version||6.2.0-27-generic
On 17/08/2023 15:59, Dmitry Baryshkov wrote:
Add the nb7vpq904m, onboard USB-C redriver / retimer.
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/qrb5165-rb5.dts | 52 +++-
1 file changed, 50 insertions(+), 2 deletions(-)
diff --git
On Mon, 2023-08-07 at 18:59 +0300, Imre Deak wrote:
> On Mon, Aug 07, 2023 at 02:43:02AM +, Lin, Wayne wrote:
> > [AMD Official Use Only - General]
> >
> > > -Original Message-
> > > From: Imre Deak
> > > Sent: Friday, August 4, 2023 11:32 PM
> > > To: Lin, Wayne
> > > Cc:
Two small comments:
On Mon, 2023-08-07 at 10:56 +0800, Wayne Lin wrote:
> [Why]
> Today, the allocation/deallocation steps and status is a bit unclear.
>
> For instance, payload->vc_start_slot = -1 stands for "the failure of
> updating DPCD payload ID table" and can also represent as "payload is
On 8/16/2023 10:05 PM, Dmitry Osipenko wrote:
On 8/16/23 21:10, Kim, Dongwon wrote:
Hi,
On 8/14/2023 9:18 PM, Dmitry Osipenko wrote:
On 7/13/23 01:44, Dongwon Kim wrote:
virtio_gpu_fence_release is added to free virtio-gpu-fence
upon release of dma_fence.
Cc: Gerd Hoffmann
Cc: Vivek
The pull request you sent on Fri, 18 Aug 2023 07:36:16 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2023-08-18-1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/1ada9c07407d66679967fe5c2cbb7eda2e0addbf
Thank you!
--
Deet-doot-dot, I am a bot.
On 8/15/2023 5:39 PM, john.c.harri...@intel.com wrote:
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
Hi Linus,
Regular enough week, mostly the usual amdgpu and i915 fixes. Then
qaic, nouveau, qxl and a revert for an EDID patch that had some side
effects, along with a couple of panel fixes.
Dave.
drm-fixes-2023-08-18-1:
drm fixes for 6.5-rc7
edid:
- revert mode parsing fix that had side
From: Maira Canal
Hi Jim,
On 6/23/23 19:23, Jim Shargo wrote:
> This change adds the basic scaffolding for ConfigFS, including setting
> up the default directories. It does not allow for the registration of
> configfs-backed devices, which is complex and provided in a follow-up
> commit.
>
>
1 - 100 of 182 matches
Mail list logo