On Thu, 24 Aug 2023, Gil Dekel wrote:
> Next version of https://patchwork.freedesktop.org/series/122643/
>
> Reorganize into:
> 1) Add for final failure state for SST and MST link training fallback.
> 2) Add a DRM helper for setting downstream MST ports' link-status state.
> 3) Make handling SST
On Wed, Aug 23, 2023 at 9:39 PM Doug Anderson wrote:
> On Wed, Aug 23, 2023 at 10:10 AM Andy Shevchenko
> wrote:
> >
> > > No. Please, do not remove the I2C ID table. It had already been
> > > discussed a few years ago.
> > >
> > > > Yes, it make sense, as it saves some memory
> >
> > Okay,
https://bugzilla.kernel.org/show_bug.cgi?id=217664
--- Comment #27 from popus_czy_to_ty (pentelja...@o2.pl) ---
@alex, as i renember it was remote shell accessible from suspending (on
LLVMPIPE) [rest banned], but it didnt go deep sleep anyway as far i renember(?)
@mario
formatted 3x with
Hi Andy Shevchenko,
> Subject: Re: [PATCH] drm/bridge/analogix/anx78xx: Extend match data support
> for ID table
>
> On Wed, Aug 23, 2023 at 9:39 PM Doug Anderson
> wrote:
> > On Wed, Aug 23, 2023 at 10:10 AM Andy Shevchenko
> > wrote:
> > >
> > > > No. Please, do not remove the I2C ID table.
On Fri, 18 Aug 2023 17:06:42 -0300
André Almeida wrote:
> Create a section that specifies how to deal with DRM device resets for
> kernel and userspace drivers.
>
> Signed-off-by: André Almeida
>
> ---
>
> v7 changes:
> - s/application/graphical API contex/ in the robustness part (Michel)
>
Thanks Stan for the review.
Regards,
Ankit
On 8/24/2023 2:59 PM, Lisovskiy, Stanislav wrote:
On Wed, Aug 23, 2023 at 05:24:25PM +0530, Ankit Nautiyal wrote:
Edid specific BPC constraints are stored in limits->max_bpp. Honor these
limits while computing the input bpp for DSC.
Signed-off-by:
> -Original Message-
> From: Intel-gfx On Behalf Of Tvrtko
> Ursulin
> Sent: Friday, July 7, 2023 6:32 PM
> To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 5/5] drm/i915: Implement fdinfo memory stats
> printing
>
> From: Tvrtko
On 8/24/2023 3:14 PM, Jani Nikula wrote:
On Wed, 23 Aug 2023, Ankit Nautiyal wrote:
Edid specific BPC constraints are stored in limits->max_bpp. Honor these
limits while computing the input bpp for DSC.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_dp.c | 4 +++-
Thanks Jani for the corrections and suggestions.
I agree to them and will fix them in next version.
Now that I see the commit subject line also should have been "Assume 8
bpc support when DSC is supported", will change that too.
Regards,
Ankit
On 8/24/2023 3:15 PM, Jani Nikula wrote:
On
Am 24.08.23 um 01:12 schrieb Matthew Brost:
On Wed, Aug 23, 2023 at 01:26:09PM -0400, Rodrigo Vivi wrote:
On Wed, Aug 23, 2023 at 11:41:19AM -0400, Alex Deucher wrote:
On Wed, Aug 23, 2023 at 11:26 AM Matthew Brost wrote:
On Wed, Aug 23, 2023 at 09:10:51AM +0200, Christian König wrote:
Am
On Tue, Aug 22, 2023 at 6:55 PM Faith Ekstrand wrote:
> On Tue, Aug 22, 2023 at 4:51 AM Christian König
> wrote:
>
>> Am 21.08.23 um 21:46 schrieb Faith Ekstrand:
>>
>> On Mon, Aug 21, 2023 at 1:13 PM Christian König
>> wrote:
>>
>>> [SNIP]
>>> So as long as nobody from userspace comes and
As suggested by Christian at [0], this patchset merges all debug modules
parameters and creates a new one for disabling soft recovery:
> Maybe we can overload the amdgpu_gpu_recovery module option with this.
> Or even better merge all the developer module parameter into a
> amdgpu_debug option.
Create a module option to disable soft recoveries on amdgpu, making
every recovery go through the device reset path. This option makes
easier to force device resets for testing and debugging purposes.
Signed-off-by: André Almeida
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 +
Merge all developer debug options available as separated module
parameters in one, making it obvious that are for developers.
Signed-off-by: André Almeida
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 24
drivers/gpu/drm/amd/include/amd_shared.h | 9 +
2 files
Fix the following warning:
Documentation/gpu/automated_testing.rst:55: WARNING: Inline emphasis
start-string without end-string.
Reported-by: Stephen Rothwell
Signed-off-by: Helen Koike
---
Patch for topic/drm-ci
---
Documentation/gpu/automated_testing.rst | 2 +-
1 file changed, 1
Fix the following warning:
Documentation/gpu/automated_testing.rst:55: WARNING: Inline emphasis
start-string without end-string.
Reported-by: Stephen Rothwell
Signed-off-by: Helen Koike
---
Patch for topic/drm-ci
V2:
- Fix typo s/scape/escape
---
Documentation/gpu/automated_testing.rst |
On Wed, Aug 23, 2023 at 10:14:59AM +0200, Krzysztof Kozlowski wrote:
> The panel-common schema does not define what "ports" property is, so
> bring the definition by referencing the panel-common-dual.yaml. Panels
> can be single- or dual-link, thus require only one port@0.
>
> Signed-off-by:
On Wed, 23 Aug 2023 10:15:00 +0200, Krzysztof Kozlowski wrote:
> The panel-common schema does not define what "ports" property is, so
> bring the definition by referencing the panel-common-dual.yaml. Panels
> can be single- or dual-link, depending on the compatible, thus add
> if:then:else:
On Thu, 24 Aug 2023, Jani Nikula wrote:
> On Thu, 24 Aug 2023, Thierry Reding wrote:
> > On Thu, Aug 24, 2023 at 08:37:00AM +0100, Lee Jones wrote:
> >> When converting from int to string, we must allow for up to 10-chars
> >> (2147483647).
> >>
> >> Fixes the following W=1 kernel build
On Thu, 24 Aug 2023, Jani Nikula wrote:
> On Thu, 24 Aug 2023, Lee Jones wrote:
> > This set is part of a larger effort attempting to clean-up W=1
> > kernel builds, which are currently overwhelmingly riddled with
> > niggly little warnings.
>
> The next question is, how do we keep it W=1 clean
On Thu, 24 Aug 2023, Lee Jones wrote:
> On Thu, 24 Aug 2023, Jani Nikula wrote:
>
> > On Thu, 24 Aug 2023, Lee Jones wrote:
> > > This set is part of a larger effort attempting to clean-up W=1
> > > kernel builds, which are currently overwhelmingly riddled with
> > > niggly little warnings.
> >
On Thu, 24 Aug 2023, Maxime Ripard wrote:
> Hi,
>
> On Thu, Aug 24, 2023 at 10:59:54AM +0200, Maxime Ripard wrote:
> > On Thu, 24 Aug 2023 08:36:45 +0100, Lee Jones wrote:
> > > This set is part of a larger effort attempting to clean-up W=1
> > > kernel builds, which are currently overwhelmingly
On Thu, 24 Aug 2023, Maxime Ripard wrote:
> Hi,
>
> On Thu, Aug 24, 2023 at 08:36:58AM +0100, Lee Jones wrote:
> > Fixes the following W=1 kernel build warning(s):
> >
> > drivers/gpu/drm/tests/drm_kunit_helpers.c:172: warning: expecting
> > prototype for
On 8/24/23 08:07, Lee Jones wrote:
On Thu, 24 Aug 2023, Jani Nikula wrote:
On Thu, 24 Aug 2023, Lee Jones wrote:
This set is part of a larger effort attempting to clean-up W=1
kernel builds, which are currently overwhelmingly riddled with
niggly little warnings.
The next question is, how
Hi Lee,
On 8/24/23 09:37, Lee Jones wrote:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/drm_gpuva_mgr.c: In function ‘__drm_gpuva_sm_map’:
drivers/gpu/drm/drm_gpuva_mgr.c:1079:39: warning: variable ‘prev’ set but not
used [-Wunused-but-set-variable]
Thanks for fixing
Assume 8bpc is supported if Sink claims DSC support.
Also consider bpc constraint coming from EDID while computing
input BPC for DSC.
Rev2: Fix check for dsc support.
Rev3: Minor styling and typos fix.
Ankit Nautiyal (2):
drm/display/dp: Assume 8 bpc support when DSC is supported
As per DP v1.4, a DP DSC Sink device shall support 8bpc in DPCD 6Ah.
Apparently some panels that do support DSC, are not setting the bit for
8bpc.
So always assume 8bpc support by DSC decoder, when DSC is claimed to be
supported.
v2: Use helper to get check dsc support. (Ankit)
v3: Fix styling
Edid specific BPC constraints are stored in limits->max_bpp. Honor these
limits while computing the input bpp for DSC.
v2: Use int instead of u8 for computations. (Jani)
Add closes tag. (Ankit)
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9161
Signed-off-by: Ankit Nautiyal
On 8/24/23 05:23, Matthew Brost wrote:
On Thu, Aug 24, 2023 at 02:08:59AM +0200, Danilo Krummrich wrote:
Hi Matt,
On 8/11/23 04:31, Matthew Brost wrote:
As a prerequisite to merging the new Intel Xe DRM driver [1] [2], we
have been asked to merge our common DRM scheduler patches first.
This
Applied. Thanks!
On Thu, Aug 24, 2023 at 3:37 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/radeon/radeon_ttm.c: In function ‘radeon_bo_move’:
> drivers/gpu/drm/radeon/radeon_ttm.c:201:27: warning: variable ‘rbo’ set but
> not used
Applied. Thanks!
On Thu, Aug 24, 2023 at 3:38 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:516: warning: Function parameter
> or member 'xcc_id' not described in 'amdgpu_mm_wreg_mmio_rlc'
>
> Signed-off-by: Lee Jones
Applied. Thanks!
On Thu, Aug 24, 2023 at 3:38 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c: In function
> ‘amdgpu_ras_sysfs_create’:
> drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:1406:20: warning: ‘_err_count’
> directive
Applied. Thanks!
On Thu, Aug 24, 2023 at 3:38 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.c: In function
> ‘amdgpu_sdma_init_microcode’:
> drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.c:217:64: warning: ‘.bin’ directive
>
Applied. Thanks!
On Thu, Aug 24, 2023 at 3:38 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/imu_v11_0.c: In function
> ‘imu_v11_0_init_microcode’:
> drivers/gpu/drm/amd/amdgpu/imu_v11_0.c:52:54: warning: ‘_imu.bin’ directive
> output
Applied. Thanks!
On Thu, Aug 24, 2023 at 4:35 AM Sharma, Shashank
wrote:
>
> [AMD Official Use Only - General]
>
> Reviewed-by: : Shashank Sharma
>
> Regards
> Shashank
> -Original Message-
> From: Lee Jones
> Sent: Thursday, August 24, 2023 9:37 AM
> To: l...@kernel.org
> Cc:
The new implemented pci_boot_vga_capturer() function is also effective on
X86 and IA64, it can determine the default boot VGA device before VRAM BAR
relocations done by the PCI core. Since the fixup handler has already
identified the firmware framebuffer, there no need to look again later. So,
Currently, the vga_is_firmware_default() function only works on x86 and
ia64, it is a no-op on the rest of the architectures. This patch completes
the implementation for it, the added code tries to capture the PCI (e) VGA
device that owns the firmware framebuffer address range before the PCI
Currently, the vga_is_firmware_default() function only works on x86 and
ia64, it is a no-op on the rest of the architectures. This patch completes
the implementation for it, the added code tries to capture the PCI (e) VGA
device that owns the firmware framebuffer, since only one GPU could own
the
Add support for the monochrome light-on-dark buffer format (R1) to the
fb helper, so this format can be used for fbdev emulation and for the
text console. This avoids the overhead of using XR24 and the associated
conversions on display hardware that supports only a simple monochrome
format.
R1
The native display format is monochrome light-on-dark (R1).
Hence add support for R1, so monochrome applications not only look
better, but also avoid the overhead of back-and-forth conversions
between R1 and XR24.
Do not allocate the intermediate conversion buffer when it is not
needed, and
drm_fb_helper_single_fb_probe() first calls drm_fb_helper_find_sizes(),
followed by drm_fbdev_generic_helper_fb_probe():
- The former tries to find a suitable buffer format, taking into
account limitations of the whole display pipeline,
- The latter just calls drm_mode_legacy_fb_format()
Due to the reuse of buffers, ssd130x_clear_screen() no longers clears
the screen, but merely redraws the last image that is residing in the
intermediate buffer.
As there is no point in clearing the intermediate buffer and transposing
an all-black image, fix this by just clearing the HW format
Currently drm_client_buffer_addfb() uses the legacy drm_mode_addfb(),
which uses bpp and depth to guess the wanted buffer format.
However, drm_client_buffer_addfb() already knows the exact buffer
format, so there is no need to convert back and forth between buffer
format and bpp/depth, and the
The native display format is R1. Hence change the preferred_depth and
preferred_bpp to 1, to avoid the overhead of using XR24 and the
associated conversions when using fbdev emulation and its text console.
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Javier Martinez Canillas
Tested-by:
The .need_pwm and .need_chargepump fields in struct ssd130x_deviceinfo
are flags that can have only two possible values: 0 and 1.
Reduce kernel size by changing their types from int to bool.
Signed-off-by: Geert Uytterhoeven
---
v2:
- New.
---
drivers/gpu/drm/solomon/ssd130x.h | 4 ++--
1
Hi all,
The native display format of ssd1306 OLED displays is monochrome
light-on-dark (R1). This patch series adds support for the R1 buffer
format to both the ssd130x DRM driver and the FB helpers, so monochrome
applications (including fbdev emulation and the text console) not only
drm_mode_create_dumb() calculates the number of characters per pixel
from the number of bits per pixel by rounding up, which is not correct
as the actual value of cpp may be non-integer. While we do not need to
care here about complex formats like YUV, bpp < 8 is a valid use case.
- The
Hi Geert,
On Thu, 24 Aug 2023 at 16:09, Geert Uytterhoeven wrote:
> struct drm_client_dev *client = buffer->client;
> - struct drm_mode_fb_cmd fb_req = { };
> - const struct drm_format_info *info;
> + struct drm_mode_fb_cmd2 fb_req = { };
> int ret;
>
> -
Hi Daniel,
On Thu, Aug 24, 2023 at 5:12 PM Daniel Stone wrote:
> On Thu, 24 Aug 2023 at 16:09, Geert Uytterhoeven wrote:
> > struct drm_client_dev *client = buffer->client;
> > - struct drm_mode_fb_cmd fb_req = { };
> > - const struct drm_format_info *info;
> > +
Next version of https://patchwork.freedesktop.org/series/122643/
v3:
Still learning the ropes of upstream workflow. Apologies for mucking up v2.
This is just a re-upload.
v2:
Reorganize into:
1) Add for final failure state for SST and MST link training fallback.
2) Add a DRM helper for
Instead of silently giving up when all link-training fallback values are
exhausted, this patch modifies the fallback's failure branch to reduces
both max_link_lane_count and max_link_rate to zero (0) and continues to
emit uevents until userspace stops attempting to modeset.
By doing so, we ensure
Currently, MST link training has no fallback. This means that if an MST
base connector fails to link-train once, the training completely fails,
which makes this case significantly more common than a complete SST link
training failure.
Similar to the final failure state of SST, this patch zeros
Unlike SST, MST can support multiple displays connected to a single
connector. However, this also means that if the DisplayPort link to the
top-level MST branch device becomes unstable, then every single branch
device has an unstable link.
Since there are multiple downstream ports per connector,
Before sending a uevent to userspace in order to trigger a corrective
modeset, we change the failing connector's link-status to BAD. However,
the downstream MST branch ports are left in their original GOOD state.
This patch utilizes the drm helper function
drm_dp_set_mst_topology_link_status() to
Currently, link-training fallback is only implemented for SST, so having
modeset_retry_work in intel_connector makes sense. However, we hope to
implement link training fallback for MST in a follow-up patchset, so
moving modeset_retry_work to indel_dp will make handling both SST and
MST connectors
When a link-training attempt fails, emit a uevent to user space that
includes the trigger property, which in this case will be
link-statue=Bad.
This will allow userspace to parse the uevent property and better
understand the reason for the previous modeset failure.
Change-Id:
On Thu, 24 Aug 2023 12:59:19 +0300
Andy Shevchenko wrote:
> On Wed, Aug 23, 2023 at 9:39 PM Doug Anderson wrote:
> > On Wed, Aug 23, 2023 at 10:10 AM Andy Shevchenko
> > wrote:
> > >
> > > > No. Please, do not remove the I2C ID table. It had already been
> > > > discussed a few years ago.
Hi Adrián,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on linus/master v6.5-rc7 next-20230824]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest
Hi Brandon,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on next-20230824]
[cannot apply to linus/master v6.5-rc7]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting
On Thu, 24 Aug 2023, Hamza Mahfooz wrote:
>
> On 8/24/23 08:07, Lee Jones wrote:
> > On Thu, 24 Aug 2023, Jani Nikula wrote:
> >
> > > On Thu, 24 Aug 2023, Lee Jones wrote:
> > > > This set is part of a larger effort attempting to clean-up W=1
> > > > kernel builds, which are currently
Hi Dave and Daniel,
Here goes our next-fixes targeting 6.6-rc1.
Please notice that we have 2 drm level patches there,
one to fix the display HPD polling and one dependency
introducing a helper to reschedule the poll work.
drm-intel-next-fixes-2023-08-24:
- Fix TLB invalidation (Alan)
- Fix
Hi Dave and Daniel,
And this is our fixes targeting 6.5 (rc8?).
I'm again covering for Tvrtko at this round.
Please also notice that here we also have the drm
patches fixing the HPD polling that I had mentioned
in our next-fixes.
One is the fix itself and the other is a dependency
to add the
https://bugzilla.kernel.org/show_bug.cgi?id=201957
Priit O. (pr...@ww.ee) changed:
What|Removed |Added
CC||pr...@ww.ee
--- Comment #89
For DRM legacy gamma, AMD display manager applies implicit sRGB degamma
using a pre-defined sRGB transfer function. It works fine for DCN2
family where degamma ROM and custom curves go to the same color block.
But, on DCN3+, degamma is split into two blocks: degamma ROM for
pre-defined TFs and
On Thu, Aug 24, 2023 at 01:01:24PM +0100, Lee Jones wrote:
> On Thu, 24 Aug 2023, Jani Nikula wrote:
>
> > On Thu, 24 Aug 2023, Thierry Reding wrote:
> > > On Thu, Aug 24, 2023 at 08:37:00AM +0100, Lee Jones wrote:
> > >> When converting from int to string, we must allow for up to 10-chars
> >
Avoid accessing the raw edid directly. Pre-parse the source physical
address during normal EDID parsing and use that for CEC.
Jani Nikula (6):
drm/edid: add drm_edid_is_digital()
drm/i915/display: use drm_edid_is_digital()
drm/edid: parse source physical address
drm/cec: add
Reduce the use of struct edid and drm_edid_raw().
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_crt.c | 11 ---
drivers/gpu/drm/i915/display/intel_hdmi.c | 9 -
drivers/gpu/drm/i915/display/intel_sdvo.c | 7 ++-
3 files changed, 10 insertions(+), 17
Checking edid->input & DRM_EDID_INPUT_DIGITAL is common enough to
deserve a helper that also lets us abstract the raw EDID a bit better.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 17 +++--
include/drm/drm_edid.h | 1 +
2 files changed, 16 insertions(+), 2
Connectors have source physical address available in display
info. There's no need to parse the EDID again for this. Add
drm_dp_cec_attach() to do this.
Seems like the set_edid/unset_edid naming is a bit specific now that
there's no need to pass the EDID at all, so aim for attach/detach going
CEC needs the source physical address. Parsing it is trivial with the
existing EDID CEA DB infrastructure.
Default to CEC_PHYS_ADDR_INVALID (0x) instead of 0 to cater for
easier CEC usage.
Cc: Hans Verkuil
Cc: linux-me...@vger.kernel.org
Signed-off-by: Jani Nikula
---
Avoid parsing the EDID again for source physical address. Also gets rids
of a few remaining raw EDID usages.
Cc: Hans Verkuil
Cc: linux-me...@vger.kernel.org
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_dp.c | 7 ++-
drivers/gpu/drm/i915/display/intel_hdmi.c | 5
In the drm subsystem, the source physical address is, in most cases,
available without having to parse the EDID again. Add notes about
preferring to use the pre-parsed address instead.
Cc: Hans Verkuil
Cc: linux-me...@vger.kernel.org
Signed-off-by: Jani Nikula
---
On Tue, Aug 22, 2023 at 7:36 AM Sasha Levin wrote:
>
> From: Alex Deucher
>
> [ Upstream commit 616f92d188ee7142a95a52068efdbea82645f859 ]
>
> Use the dGPU path instead. There were a lot of platform
> issues with IOMMU in general on these chips due to windows
> not enabling IOMMU at the time.
On Tue, Aug 22, 2023 at 9:35 AM Somalapuram, Amaranath wrote:
>
>
> On 8/21/2023 6:30 PM, Shashank Sharma wrote:
> > + Amar should be able to help.
> >
> > Amar,
> >
> > Can you please check this patch (series if required) with a few IGTs
> > and probably with Xonotic as well ?
> >
> Tested patch
On Thu, Aug 24, 2023 at 01:44:41PM +0200, Christian König wrote:
> Am 24.08.23 um 01:12 schrieb Matthew Brost:
> > On Wed, Aug 23, 2023 at 01:26:09PM -0400, Rodrigo Vivi wrote:
> > > On Wed, Aug 23, 2023 at 11:41:19AM -0400, Alex Deucher wrote:
> > > > On Wed, Aug 23, 2023 at 11:26 AM Matthew
Applied. Thanks!
Alex
On Wed, Aug 23, 2023 at 5:50 AM Wang, Yang(Kevin)
wrote:
>
> [AMD Official Use Only - General]
>
> Reviewed-by: Yang Wang
>
> Best Regards,
> Kevin
>
> -Original Message-
> From: dri-devel On Behalf Of Colin
> Ian King
> Sent: Wednesday, August 23, 2023 5:03 PM
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
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
---
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
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
On Thu, 2023-08-24 at 07:31 +0900, Masahiro Yamada wrote:
> On Fri, Aug 18, 2023 at 4:35 AM Sarah Walker wrote:
> > This patch series adds the initial DRM driver for Imagination Technologies
> > PowerVR
> > GPUs, starting with those based on our Rogue architecture. It's worth
> > pointing
> >
On Thu, 2023-08-24 at 09:08 +0100, Sarah Walker wrote:
> On Thu, 2023-08-24 at 07:31 +0900, Masahiro Yamada wrote:
> > On Fri, Aug 18, 2023 at 4:35 AM Sarah Walker
> > wrote:
> > > This patch series adds the initial DRM driver for Imagination
> > > Technologies PowerVR
> > > GPUs, starting with
[AMD Official Use Only - General]
Reviewed-by: : Shashank Sharma
Regards
Shashank
-Original Message-
From: Lee Jones
Sent: Thursday, August 24, 2023 9:37 AM
To: l...@kernel.org
Cc: linux-ker...@vger.kernel.org; Deucher, Alexander
; Koenig, Christian ; Pan,
Xinhui ; David Airlie ;
Hi,
Here's this week drm-misc-fixes PR
Maxime
drm-misc-fixes-2023-08-24:
A samsung-dsim initialization fix, a devfreq fix for panfrost, a DP DSC
define fix, a recursive lock fix for dma-buf, a shader validation fix
and a reference counting fix for vmwgfx
The following changes since commit
On Thu, Aug 24, 2023 at 9:37 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:584: warning: Function
> parameter or member 'init' not described in 'init_reserved'
> drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:611:
On Thu, Aug 24, 2023 at 9:37 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c:49: warning: This comment
> starts with '/**', but isn't a kernel-doc comment. Refer
> Documentation/doc-guide/kernel-doc.rst
>
On Thu, Aug 24, 2023 at 9:37 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c:1044: warning: This comment
> starts with '/**', but isn't a kernel-doc comment. Refer
> Documentation/doc-guide/kernel-doc.rst
>
>
On Thu, Aug 24, 2023 at 9:37 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/nouveau/dispnv04/crtc.c:453: warning: This comment starts
> with '/**', but isn't a kernel-doc comment. Refer
> Documentation/doc-guide/kernel-doc.rst
>
Since Jim is busy with other work and I'm working on some things that
rely on this, I've taken up the task of doing the iterations. I've
addressed the comments as best I can (those replies are to each
individual change) and here is the patch set to go with those.
I added my own signoff to each
From: Jim Shargo
This is a small refactor to make ConfigFS support easier. Once we
support ConfigFS, there can be multiple devices instantiated by the
driver, and so moving everything into managed memory makes things much
easier.
This should be a no-op refactor.
Signed-off-by: Jim Shargo
From: Jim Shargo
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
move all of the writeback/composition data from being per-"output" to
being per-CRTC.
Since there's still only
From: Jim Shargo
This is a small refactor to make ConfigFS support easier. This should be
a no-op refactor.
Signed-off-by: Jim Shargo
Signed-off-by: Brandon Pollack
---
drivers/gpu/drm/vkms/vkms_drv.c| 14 --
drivers/gpu/drm/vkms/vkms_drv.h| 9 ++---
From: Jim Shargo
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.
This CL includes docs about using ConfigFS with VKMS, but
From: Jim Shargo
In many testing circumstances, we will want to just create a new device
and test against that. If we create a default device, it can be annoying
to have to manually select the new device instead of choosing the only
one that exists.
The param, enable_default, is defaulted to
From: Jim Shargo
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: Jim Shargo
Signed-off-by: Brandon Pollack
---
drivers/gpu/drm/vkms/vkms_configfs.c |
This change adds the ability to read or write a "1" or a "0" to the
newly added "connected" attribute of a connector in the vkms entry in
configfs.
A write will trigger a call to drm_kms_helper_hotplug_event, causing a
hotplug uevent.
With this we can write virtualized multidisplay tests that
Hi,
On Thu, Aug 24, 2023 at 08:36:58AM +0100, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/tests/drm_kunit_helpers.c:172: warning: expecting prototype
> for ddrm_kunit_helper_acquire_ctx_alloc(). Prototype was for
>
On Thu, 24 Aug 2023 08:36:45 +0100, Lee Jones wrote:
> This set is part of a larger effort attempting to clean-up W=1
> kernel builds, which are currently overwhelmingly riddled with
> niggly little warnings.
>
> Cc: Alex Deucher
> Cc: amd-...@lists.freedesktop.org
> Cc: Ben Skeggs
> Cc:
On Thu, 24 Aug 2023 08:37:01 +0100, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/drm_connector.c:2215: warning: Function parameter or member
> 'supported_colorspaces' not described in
> 'drm_mode_create_hdmi_colorspace_property'
>
1 - 100 of 175 matches
Mail list logo
