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
---
drivers/gpu/drm/i915/display/intel_dp.c | 8
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
---
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
---
drivers/gpu/drm/i915/display/intel_dp.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
Currently we assume 2 Pixels Per Clock (PPC) while computing
plane cdclk and min_cdlck. In cases where DSC single engine
is used the throughput is 1 PPC.
So account for the above case, while computing cdclk.
v2: Use helper to get the adjusted pixel rate.
Signed-off-by: Ankit Nautiyal
---
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
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)
Signed-off-by: Ankit Nautiyal
Reviewed-by: Ville Syrjälä
---
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.
Move the check for limiting compressed bite_per_pixel for 420,422
formats in the helper to compute bits_per_pixel.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_dp.c | 18 +-
1 file changed, 9 insertions(+), 9 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
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.
This series is an attempt to address multiple issues with DSC,
scattered in separate existing series.
Patches 1-3 are DSC fixes from series to Handle BPC for HDMI2.1 PCON
https://patchwork.freedesktop.org/series/107550/
Patches 4-5 are from series DSC fixes for Bigjoiner:
Hi
Am 30.06.23 um 14:33 schrieb Javier Martinez Canillas:
Thomas Zimmermann writes:
Hello Thomas,
Thanks a lot for your review.
Hi Javier
Am 30.06.23 um 00:51 schrieb Javier Martinez Canillas:
This patch series splits the fbdev core support in two different Kconfig
symbols: FB and
On 30.06.2023 13:18, Christian König wrote:
Am 30.06.23 um 13:09 schrieb Karolina Stolarek:
Hi Christian,
I'm taking a second look at this, and I wonder what would be the
benefit of combining the initialization of device and ttm_device.
(drm_)device can be initialized indepedently from the
Thomas Zimmermann writes:
Hello Thomas,
Thanks a lot for your review.
> Hi Javier
>
> Am 30.06.23 um 00:51 schrieb Javier Martinez Canillas:
>> This patch series splits the fbdev core support in two different Kconfig
>> symbols: FB and FB_CORE. The motivation for this is to allow CONFIG_FB to
"Arnd Bergmann" writes:
> On Fri, Jun 30, 2023, at 12:51, Javier Martinez Canillas wrote:
>> "Arnd Bergmann" writes:
>>
@@ -59,7 +71,7 @@ config FIRMWARE_EDID
config FB_DEVICE
bool "Provide legacy /dev/fb* device"
- depends on FB
+ depends on FB_CORE
Am 02.06.23 um 09:40 schrieb Keith Zhao:
Implement plane functions for the DRM driver.
Signed-off-by: Keith Zhao
---
drivers/gpu/drm/verisilicon/Makefile | 3 +-
drivers/gpu/drm/verisilicon/vs_plane.c | 440 +
drivers/gpu/drm/verisilicon/vs_plane.h | 74 +
Some Android CTS is testing if the signaling time keeps consistent
during merges.
v2: use the current time if the fence is still in the signaling path and
the timestamp not yet available.
v3: improve comment, fix one more case to use the correct timestamp
Signed-off-by: Christian König
---
From: Christian König
This makes room for up to 128 DRM devices.
Signed-off-by: Christian König
Signed-off-by: James Zhu
---
drivers/gpu/drm/drm_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index
Hi
Am 02.06.23 um 09:40 schrieb Keith Zhao:
Add crtc driver which implements crtc related operation functions.
Signed-off-by: Keith Zhao
---
drivers/gpu/drm/verisilicon/Makefile | 1 +
drivers/gpu/drm/verisilicon/vs_crtc.c | 388 ++
On Fri, Jun 30, 2023, at 09:46, Thomas Zimmermann wrote:
> Am 29.06.23 um 15:21 schrieb Arnd Bergmann:
>> On Thu, Jun 29, 2023, at 15:01, Thomas Zimmermann wrote:
>>> Am 29.06.23 um 14:35 schrieb Arnd Bergmann:
On Thu, Jun 29, 2023, at 13:45, Thomas Zimmermann wrote:
>
>>>
>>> FIRMWARE_EDID
From: Christian König
This makes room for up to 128 DRM devices.
Signed-off-by: Christian König
Signed-off-by: James Zhu
---
drivers/gpu/drm/drm_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index
On Fri, Jun 30, 2023, at 12:51, Javier Martinez Canillas wrote:
> "Arnd Bergmann" writes:
>
>>> @@ -59,7 +71,7 @@ config FIRMWARE_EDID
>>>
>>> config FB_DEVICE
>>> bool "Provide legacy /dev/fb* device"
>>> - depends on FB
>>> + depends on FB_CORE
>>> default y
>>> help
>>>
Hi Javier
Am 30.06.23 um 00:51 schrieb Javier Martinez Canillas:
This patch series splits the fbdev core support in two different Kconfig
symbols: FB and FB_CORE. The motivation for this is to allow CONFIG_FB to
be disabled, while still having the the core fbdev support needed for the
Am 30.06.23 um 13:09 schrieb Karolina Stolarek:
Hi Christian,
I'm taking a second look at this, and I wonder what would be the
benefit of combining the initialization of device and ttm_device.
(drm_)device can be initialized indepedently from the test params, so
we can utilize .init and
Hi Christian,
I'm taking a second look at this, and I wonder what would be the benefit
of combining the initialization of device and ttm_device. (drm_)device
can be initialized indepedently from the test params, so we can utilize
.init and .exit callbacks offered by KUnit[1] to prepare and
On 6/30/23 12:58, Thomas Zimmermann wrote:
Hi Helge
Am 30.06.23 um 11:43 schrieb Helge Deller:
On 6/27/23 16:58, Thomas Zimmermann wrote:
Add MODULE_LICENSE() and MODULE_DESCRIPTION() for fbdev helpers
on sparc. Fixes the following error:
ERROR: modpost: missing MODULE_LICENSE() in
From: Sui Jingfeng
[why]
The vga_is_firmware_default() defined in drivers/pci/vgaarb.c is
arch-dependent, it's a dummy on non-x86 architectures currently.
This made VGAARB lost an important condition for the arbitration.
It could still be wrong even if we remove the #ifdef and #endif guards.
From: Sui Jingfeng
[why]
The vga_is_firmware_default() defined in drivers/pci/vgaarb.c is
arch-dependent, it's a dummy on non-x86 architectures currently.
This made VGAARB lost an important condition for the arbitration.
It could still be wrong even if we remove the #ifdef and #endif guards.
From: Sui Jingfeng
Currently, the default VGA device selection is not perfect. Potential
problems are:
1) This function is a no-op on non-x86 architectures.
2) It does not take the PCI Bar may get relocated into consideration.
3) It is not effective for the PCI device without a dedicated VRAM
From: Sui Jingfeng
Currently, the default VGA device selection is not perfect. Potential
problems are:
1) This function is a no-op on non-x86 architectures.
2) It does not take the PCI Bar may get relocated into consideration.
3) It is not effective for the PCI device without a dedicated VRAM
From: Sui Jingfeng
This patch adds the aperture_contain_firmware_fb() function to do the
determination. Unfortunately due to the fact that apertures list will be
freed dynamically, the location and size information of the firmware fb
will be lost after dedicated drivers call
Currently, the default VGA device selection is not perfect. Potential
problems are:
1) This function is a no-op on non-x86 architectures.
2) It does not take the PCI Bar may get relocated into consideration.
3) It is not effective for the PCI device without a dedicated VRAM Bar.
4) It is
Hi Helge
Am 30.06.23 um 11:43 schrieb Helge Deller:
On 6/27/23 16:58, Thomas Zimmermann wrote:
Add MODULE_LICENSE() and MODULE_DESCRIPTION() for fbdev helpers
on sparc. Fixes the following error:
ERROR: modpost: missing MODULE_LICENSE() in arch/sparc/video/fbdev.o
Reported-by: Guenter Roeck
Currently, the default VGA device selection is not perfect. Potential
problems are:
1) This function is a no-op on non-x86 architectures.
2) It does not take the PCI Bar may get relocated into consideration.
3) It is not effective for the PCI device without a dedicated VRAM Bar.
4) It is
This patch adds the aperture_contain_firmware_fb() function to do the
determination. Unfortunately due to the fact that apertures list will be
freed dynamically, the location and size information of the firmware fb
will be lost after dedicated drivers call
aperture_remove_conflicting_devices(),
"Arnd Bergmann" writes:
Hello Arnd,
Thanks for your review!
> On Fri, Jun 30, 2023, at 00:51, Javier Martinez Canillas wrote:
>> Currently the CONFIG_FB option has to be enabled even if no legacy fbdev
>> drivers are needed (e.g: only to have support for framebuffer consoles).
>>
>> The DRM
[AMD Official Use Only - General]
Hi Rafael & Andrew,
I just posted a new V5 series based on the discussions here and offline
discussions with Mario.
Please share your comments/insights there.
Thanks,
Evan
> -Original Message-
> From: Rafael J. Wysocki
> Sent: Saturday, June 24, 2023
Fulfill the SMU13.0.7 support for Wifi RFI mitigation feature.
Signed-off-by: Evan Quan
Reviewed-by: Mario Limonciello
---
.../drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c | 59 +++
1 file changed, 59 insertions(+)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c
Fulfill the SMU13.0.0 support for Wifi RFI mitigation feature.
Signed-off-by: Evan Quan
Reviewed-by: Mario Limonciello
---
drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h | 3 +
drivers/gpu/drm/amd/pm/swsmu/inc/smu_types.h | 3 +-
drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h | 3 +
To protect PMFW from being overloaded.
Signed-off-by: Evan Quan
Reviewed-by: Mario Limonciello
---
drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 30 +++
drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h | 7 +
2 files changed, 32 insertions(+), 5 deletions(-)
diff --git
With WBRF feature supported, as a driver responding to the frequencies,
amdgpu driver is able to do shadow pstate switching to mitigate possible
interference(between its (G-)DDR memory clocks and local radio module
frequency bands used by Wifi 6/6e/7).
Signed-off-by: Evan Quan
Reviewed-by: Mario
Add those data structures to support Wifi RFI mitigation feature.
Signed-off-by: Evan Quan
Reviewed-by: Mario Limonciello
---
.../pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_0.h | 14 +-
.../pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_7.h | 14 +-
To support AMD's WBRF interference mitigation mechanism, Wifi adapters
utilized in the system must register the frequencies in use(or unregister
those frequencies no longer used) via the dedicated APCI calls. So that,
other drivers responding to the frequencies can take proper actions to
mitigate
The newly added WBRF feature needs this interface for channel
width calculation.
Signed-off-by: Evan Quan
---
include/net/cfg80211.h | 8
net/wireless/chan.c| 3 ++-
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index
AMD has introduced an ACPI based mechanism to support WBRF for some
platforms with AMD dGPU + WLAN. This needs support from BIOS equipped
with necessary AML implementations and dGPU firmwares.
For those systems without the ACPI mechanism and developing solutions,
user can use the generic WBRF
Due to electrical and mechanical constraints in certain platform designs
there may be likely interference of relatively high-powered harmonics of
the (G-)DDR memory clocks with local radio module frequency bands used
by Wifi 6/6e/7.
To mitigate this, AMD has introduced a mechanism that devices
Due to electrical and mechanical constraints in certain platform designs there
may
be likely interference of relatively high-powered harmonics of the (G-)DDR
memory
clocks with local radio module frequency bands used by Wifi 6/6e/7. To mitigate
possible RFI interference producers can advertise
On 30/06/2023 03:25, Jessica Zhang wrote:
Document and add support for solid_fill property to drm_plane. In
addition, add support for setting and getting the values for solid_fill.
To enable solid fill planes, userspace must assign a property blob to
the "solid_fill" plane property containing
From: Sui Jingfeng
Per Documentation/process/license-rules.rst, the SPDX MIT identifier is
equivalent to including the entire MIT license text from
LICENSES/preferred/MIT.
Replace the MIT license text with the equivalent SPDX identifier.
Cc: David Airlie
Cc: Daniel Vetter
Cc: Maarten
From: Sui Jingfeng
VGAARB should only care about PCI VGA class devices (pdev->class == 0x0300)
since only those devices might have VGA routed to them.
PCI_CLASS_DISPLAY_3D and PCI_CLASS_DISPLAY_OTHER are used to annotate the
render-only GPU. Render-only GPUs shouldn't decode the fixed VGA
From: Sui Jingfeng
This patch replaces the leading space with a tab and removes the double
blank line, no functional change.
Cc: Bjorn Helgaas
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
Signed-off-by: Sui Jingfeng
Reviewed-by: Andi
From: Sui Jingfeng
The io_state variable in the vga_arb_write() function is declared with
unsigned int type, while the vga_str_to_iostate() function takes int *
type. To keep them consistent, replace the third argument of
vga_str_to_iostate() function with the unsigned int * type.
Cc: Bjorn
Hi Linus,
On 16/06/2023 23:07, Linus Walleij wrote:
This is two patches fixing things I would normally complain about
in reviews, but alas I missed this one, so I go in and fix it up
myself.
The serie doesn't apply cleanly on drm-misc-next.
Thanks,
Neil
Signed-off-by: Linus Walleij
---
On 6/27/23 16:58, Thomas Zimmermann wrote:
Add MODULE_LICENSE() and MODULE_DESCRIPTION() for fbdev helpers
on sparc. Fixes the following error:
ERROR: modpost: missing MODULE_LICENSE() in arch/sparc/video/fbdev.o
Reported-by: Guenter Roeck
Closes:
Hi,
On Thu, 15 Jun 2023 22:16:02 +0200, Marek Vasut wrote:
> Add missing drm_display_mode DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC
> flags. Those are used by various bridges in the pipeline to correctly
> configure its sync signals polarity.
>
>
Thanks, Applied to
On Fri, 30 Jun 2023 10:02:52 +0200
Boris Brezillon wrote:
> In practice, I don't expect things to deadlock, because the VM resv is
> not supposed to be taken outside the VM context and the locking order
> is always the same (VM lock first, and then each shared BO
> taken/released independently),
On Fri, Jun 30, 2023, at 00:51, Javier Martinez Canillas wrote:
> Currently the CONFIG_FB option has to be enabled even if no legacy fbdev
> drivers are needed (e.g: only to have support for framebuffer consoles).
>
> The DRM subsystem has a fbdev emulation layer, but depends on CONFIG_FB
> and so
On Fri, 30 Jun 2023 03:42:28 +0300
Dmitry Baryshkov wrote:
> On 30/06/2023 03:25, Jessica Zhang wrote:
> > Add support for pixel_source property to drm_plane and related
> > documentation.
> >
> > This enum property will allow user to specify a pixel source for the
> > plane. Possible pixel
On Thu, 29 Jun 2023 17:25:00 -0700
Jessica Zhang wrote:
> Document and add support for solid_fill property to drm_plane. In
> addition, add support for setting and getting the values for solid_fill.
>
> To enable solid fill planes, userspace must assign a property blob to
> the "solid_fill"
On Thu, 29 Jun 2023 17:25:06 -0700
Jessica Zhang wrote:
> Drop DPU_PLANE_COLOR_FILL_FLAG and check the DRM solid_fill property to
> determine if the plane is solid fill. In addition drop the DPU plane
> color_fill field as we can now use drm_plane_state.solid_fill instead,
> and pass in
On Fri, 30 Jun 2023 03:52:37 +0300
Dmitry Baryshkov wrote:
> On 30/06/2023 03:25, Jessica Zhang wrote:
> > Since solid fill planes allow for a NULL framebuffer in a valid commit,
> > add NULL framebuffer checks to atomic commit calls within DPU.
> >
> > Signed-off-by: Jessica Zhang
> > ---
> >
On Fri, 30 Jun 2023 10:02:52 +0200
Boris Brezillon wrote:
> Hi Danilo,
>
> On Fri, 30 Jun 2023 00:25:18 +0200
> Danilo Krummrich wrote:
>
> > + * int driver_gpuva_remap(struct drm_gpuva_op *op, void *__ctx)
> > + * {
> > + * struct driver_context *ctx = __ctx;
> > + *
> > + *
On Fri, Jun 16, 2023 at 1:45 AM Marek Vasut wrote:
>
> Wait until the command transfer FIFO is empty before loading in the next
> command. The previous behavior where the code waited until command transfer
> FIFO was not full suffered from transfer corruption, where the last command
> in the FIFO
Hi Danilo,
On Fri, 30 Jun 2023 00:25:18 +0200
Danilo Krummrich wrote:
> + * int driver_gpuva_remap(struct drm_gpuva_op *op, void *__ctx)
> + * {
> + * struct driver_context *ctx = __ctx;
> + *
> + * drm_gpuva_remap(ctx->prev_va, ctx->next_va, >remap);
> + *
> + *
Chen, Jiqian would like to recall the message, "[LINUX KERNEL PATCH v2 0/1] add
S3 support for virtgpu".
Hi
Am 29.06.23 um 15:21 schrieb Arnd Bergmann:
On Thu, Jun 29, 2023, at 15:01, Thomas Zimmermann wrote:
Am 29.06.23 um 14:35 schrieb Arnd Bergmann:
On Thu, Jun 29, 2023, at 13:45, Thomas Zimmermann wrote:
The global variable edid_info contains the firmware's EDID information
as an extension
Hi all,
V2 patch of kernel is
https://lore.kernel.org/lkml/20230630073448.842767-1-jiqian.c...@amd.com/T/#t.
On 2023/6/30 15:34, Jiqian Chen wrote:
> v2:
>
> Hi all,
>
> Thanks to Marc-André Lureau, Robert Beckett and Gerd Hoffmann for
> their advice and guidance. V2 makes below changes:
>
>
This patch solves two problem:
First, when we suspended guest VM, it called into Qemu to call
virtio_reset->__virtio_queue_reset, this cleared all virtuqueue
information of virtgpu on Qemu end. As a result, after guest
resumed, guest sended ctrl/cursor requests to Qemu through
virtqueue, but Qemu
v2:
Hi all,
Thanks to Marc-André Lureau, Robert Beckett and Gerd Hoffmann for
their advice and guidance. V2 makes below changes:
* Change VIRTIO_CPU_CMD_STATUS_FREEZING to 0x0400 (<0x1000)
* Add a new feature flag VIRTIO_GPU_F_FREEZING, so that guest and
host can negotiate whenever freezing
Hi John,
On Fri, 30 Jun 2023 at 10:22, John Stultz wrote:
>
> T.J. has been responsible for dmab-buf items on the Android team
> for awhile now, so it would be great to have him on as a reviewer.
>
> Cc: T.J. Mercier
> Cc: Sumit Semwal
> Cc: Benjamin Gaignard
> Cc: Brian Starkey
> Cc: John
101 - 170 of 170 matches
Mail list logo
