Hello there Laurent,
>We could, but I don't think it will make any difference in practice as
>the maximum pixel clock frequency supported by the SoC is 80MHz (per
>LVDS channel). That would result in a 560MHz frequency returned by this
>function, well below the 31 bits limit.
Thanks for your
On Wed, 08 Mar 2023, Helge Deller wrote:
> On 3/7/23 14:08, harperchen wrote:
>> fb_set_var would by called when user invokes ioctl with cmd
>> FBIOPUT_VSCREENINFO. User-provided data would finally reach
>> tgafb_check_var. In case var->pixclock is assigned to zero,
>> divide by zero would occur
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski :
On Tue, 7 Mar 2023 17:30:28 +0100 you wrote:
> Because H3 ES1 becomes an increasing maintenance burden and was only available
> to a development group, we decided to remove upstream support for it. Here are
> the
Hi, Christian,
Thanks for reviewing these.
Ack to merge reviewed patches through drm-misc-next?
Thanks,
Thomas
On 3/8/23 09:49, Christian König wrote:
Am 07.03.23 um 15:46 schrieb Thomas Hellström:
New code is recommended to use the BIT macro instead of the explicit
shifts. Change the
On 09/03/2023 05.14, Christian König wrote:
>> I think you mean wake_up_interruptible(). That would be
>> drm_sched_job_done(), on the fence callback when a job completes, which
>> as I keep saying is the same logic used for
>> hw_rq_count/hw_submission_limit tracking.
>
> As the documentation to
Add function to check if slice design requirements are being
met as defined in Bspec: 49259 in the section
Slice Design Requirement
--v7
-remove full bspec link [Jani]
-rename intel_dsc_check_slice_design_req to
intel_dsc_slice_dimensions_valid [Jani]
--v8
-fix condition to check if slice width
From: Swati Sharma
DSC_Output_Format_Sink_Support entry is added to i915_dsc_fec_support_show
to depict if sink supports DSC output formats (RGB/YCbCr420/YCbCr444).
Also, new debugfs entry is created to enforce output format. This is
required because of our driver policy. For ex. if a mode is
Implementation of VDSC for YCbCr420.
Add QP tables for 8,10,12 BPC from rc_tables.h in intel_qp_tables.c
(Derived from C-Model, which is given along with DSC1.2a Spec from Vesa)
intel_lookup_range_min/max_qp functons need to take into account the
output format. Based on that appropriate qp table
Now that we have laid the groundwork for YUV420 Enablement
we fill up native_420 field in vdsc_cfg and add appropriate
checks wherever required.
---v2
-adding native_422 field as 0 [Vandita]
-filling in second_line_bpg_offset, second_line_offset_adj
and nsl_bpg_offset in vds_cfg when native_420
Adding new DSC register which are introducted MTL onwards
Signed-off-by: Suraj Kandpal
Reviewed-by: Vandita Kulkarni
Reviewed-by: Uma Shankar
---
.../gpu/drm/i915/display/intel_vdsc_regs.h| 28 +++
1 file changed, 28 insertions(+)
diff --git
From: Ankit Nautiyal
Go with DSC only if the given output_format is supported.
v2: Use drm helper to get DSC format support for sink.
v3: remove drm_dp_dsc_compute_bpp.
Cc: Uma Shankar
Signed-off-by: Ankit Nautiyal
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_dp.c | 28
From: Ankit Nautiyal
Add helper to check if the DP sink supports DSC with the given
o/p format.
v2: Add documentation for the helper. (Uma Shankar)
v3: /** instead of /* (Uma Shankar)
Signed-off-by: Ankit Nautiyal
Reviewed-by: Uma Shankar
---
include/drm/display/drm_dp_helper.h | 13
This patch series aims to enable the YCbCr420 format
for DSC. Changes are mostly compute params related for
hdmi,dp and dsi along with the addition of new rc_tables
for native_420 and corresponding changes to macros used to
fetch them.
There have been discussions prior to this series in which some
https://bugzilla.kernel.org/show_bug.cgi?id=216625
--- Comment #10 from Pierre Ossman (pierre-bugzi...@ossman.eu) ---
I finally got that old version of mesa to build. Unfortunately, the hangs still
happen even with that. :/
> Mar 09 07:18:30 kernel: radeon :00:01.0: ring 3 stalled for more
On Thu, 9 Mar 2023 at 15:32, Asahi Lina wrote:
>
> On 08/03/2023 00.32, Maíra Canal wrote:
> > On 3/7/23 11:25, Asahi Lina wrote:
> >> DRM drivers need to be able to declare which driver-specific ioctls they
> >> support. This abstraction adds the required types and a helper macro to
> >>
Dear Helge,
Thank you for the kind words. My real name is Wei Chen.
Please apply this patch to fbdev git tree if it is correct.
Best,
Wei
On Thu, 9 Mar 2023 at 06:05, Helge Deller wrote:
>
> On 3/7/23 14:08, harperchen wrote:
> > fb_set_var would by called when user invokes ioctl with cmd
> >
On 08/03/2023 03.19, Björn Roy Baron wrote:
> --- Original Message ---
> On Tuesday, March 7th, 2023 at 15:25, Asahi Lina wrote:
>
>> Add the initial abstractions for DRM drivers and devices. These go
>> together in one commit since they are fairly tightly coupled types.
>>
>> A few
On 08/03/2023 02.34, Björn Roy Baron wrote:
>> +// SAFETY: This is just the ioctl argument,
>> which hopefully has the right type
>> +// (we've done our best checking the size).
>
> In the rust tree there is the ReadableFromBytes [1] trait
In order to catch issues in other drivers to ensure proper call
sequence of polling function.
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2411
Fixes: a4e771729a51("drm/probe_helper: sort out poll_running vs poll_enabled")
Reported-by: Bert Karwatzki
Suggested-by: Dmitry Baryshkov
Some amd asics having reliable hotplug support don't call
drm_kms_helper_poll_init in driver init sequence. However,
due to the unified suspend/resume path for all asics, because
the output_poll_work->func is not set for these asics, a warning
arrives when suspending.
[ 90.656049]
[
On 2023.03.03 22:07:18 +0800, Cai Huoqing wrote:
> This patch uses the already existing IDR mechanism to simplify
> and improve the dmabuf code.
>
> Using 'vgpu.object_idr' directly instead of 'dmabuf_obj_list_head'
> or 'dmabuf.list', because the dmabuf_obj can be found by 'idr_find'
> or
On 08/03/2023 00.32, Maíra Canal wrote:
> On 3/7/23 11:25, Asahi Lina wrote:
>> DRM drivers need to be able to declare which driver-specific ioctls they
>> support. This abstraction adds the required types and a helper macro to
>> generate the ioctl definition inside the DRM driver.
>>
>> Note
On 08/03/2023 22.38, Maíra Canal wrote:
> On 3/7/23 11:25, Asahi Lina wrote:
>> The DRM shmem helper includes common code useful for drivers which
>> allocate GEM objects as anonymous shmem. Add a Rust abstraction for
>> this. Drivers can choose the raw GEM implementation or the shmem layer,
>>
On Wed, 2023-03-08 at 10:10 +0100, Christian König wrote:
>
> Am 08.03.23 um 06:14 schrieb Zack Rusin:
> > On Tue, 2023-02-28 at 09:34 +0100, Christian König wrote:
> > > VMWGFX is the only remaining user of this and should probably moved over
> > > to drm_exec when it starts using GEM as well.
>
Hi Dave, Daniel,
Fixes for 6.3.
The following changes since commit 66305069eb6d17d9190cbcd196f3f7487df47ae8:
Merge tag 'drm-misc-fixes-2023-02-23' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes (2023-03-07 05:42:34
+1000)
are available in the Git repository at:
On Tue, 07 Mar 2023 22:12:49 -0800, Belgaumkar, Vinay wrote:
>
Hi Vinay,
> On 3/7/2023 9:33 PM, Ashutosh Dixit wrote:
> > Using common freq functions with sysfs in PMU (but without taking
> > forcewake) solves the following issues (a) missing support for MTL (b)
>
> For the requested_freq, we
On Wed, Mar 8, 2023 at 10:37 PM Jiapeng Chong
wrote:
>
> The assignment of the else and if branches is the same, so the if else
> here is redundant, so we remove it.
>
> ./drivers/gpu/drm/amd/amdgpu/nv.c:1048:2-4: WARNING: possible condition with
> no effect (if == else).
>
> Reported-by: Abaci
Expose intel_rps_read_actual_frequency_fw to read the actual freq without
taking forcewake for use by PMU. The code is refactored to use a common set
of functions across sysfs and PMU. Using common functions with sysfs in PMU
solves the issues of missing support for MTL and missing support for
Expose intel_rps_read_actual_frequency_fw to read the actual freq without
taking forcewake for use by PMU. The code is refactored to use a common set
of functions across sysfs and PMU. Using common functions with sysfs in PMU
solves the issues of missing support for MTL and missing support for
The fallback to requested freq does not work for SLPC because SLPC does not
use 'struct intel_rps'. Also for SLPC requested freq can only be obtained
from a hw register after acquiring forcewake which we don't want to do for
PMU. Therefore remove fallback to requested freq for SLPC. The actual
The assignment of the else and if branches is the same, so the if else
here is redundant, so we remove it.
./drivers/gpu/drm/amd/amdgpu/nv.c:1048:2-4: WARNING: possible condition with no
effect (if == else).
Reported-by: Abaci Robot
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=4454
Swap is a function interface that provides exchange function. To avoid
code duplication, we can use swap function.
./drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:359:57-58: WARNING
opportunity for swap().
Reported-by: Abaci Robot
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=4448
On Tue, Mar 7, 2023 at 4:12 PM Harry Wentland wrote:
>
> In order to IGT test colorspace we'll want to print
> the currently enabled colorspace on a stream. We add
> a new debugfs to do so, using the same scheme as
> current bpc reporting.
>
> This might also come in handy when debugging display
On Tue, Mar 7, 2023 at 4:12 PM Harry Wentland wrote:
>
> Look at connector->colorimetry to determine output colorspace.
>
> We don't want to impact current SDR behavior, so
> DRM_MODE_COLORIMETRY_DEFAULT preserves current behavior.
>
> Signed-off-by: Harry Wentland
> Cc: Pekka Paalanen
> Cc:
Relying on dc_enabled will be more simple, thanks for your suggestion. I will
send v2 to address this.
Regards,
Guchun
-Original Message-
From: amd-gfx On Behalf Of Alex Deucher
Sent: Thursday, March 9, 2023 12:29 AM
To: Chen, Guchun
Cc: amd-...@lists.freedesktop.org;
On Tue, Mar 7, 2023 at 4:12 PM Harry Wentland wrote:
>
> We an use bitfields to track the support ones for HDMI
> and DP. This allows us to print colorspaces in a consistent
> manner without needing to know whether we're dealing with
> DP or HDMI.
>
> Signed-off-by: Harry Wentland
> Cc: Pekka
On Thu, Mar 09, 2023 at 02:05:55AM +0100, Sebastian Wick wrote:
> On Wed, Mar 8, 2023 at 10:09 AM Pekka Paalanen wrote:
> >
> > On Tue, 7 Mar 2023 10:10:53 -0500
> > Harry Wentland wrote:
> >
> > > From: Joshua Ashton
> > >
> > > Userspace has no way of controlling or knowing the pixel encoding
On Thu, 2 Mar 2023 13:39:49 +0100, Gerald Loacker wrote:
> Use h/v-sync and pixel clock polarity flags for RGB output. For all other
> outputs this is already implemented.
>
>
Applied, thanks!
[1/1] drm/rockchip: vop2: add polarity flags to RGB output
commit:
On Thu, 16 Feb 2023 11:24:43 +0100, Sascha Hauer wrote:
> One small fix compared to the last version, when checking for valid
> resolutions I accidently compared the current mode width with the
> maximum allowed height which resulted in wrong resolutions being
> discarded.
>
> Changes since v5:
>
On Wed, 22 Feb 2023 17:35:33 -0800, Jacob Keller wrote:
> Use the overflow-protected struct_size() helper macro to compute the
> allocation size of the vop2 data structure.
>
>
Applied, thanks!
[1/1] drm/rockchip: use struct_size() in vop2_bind
commit:
On Wed, Mar 8, 2023 at 10:09 AM Pekka Paalanen wrote:
>
> On Tue, 7 Mar 2023 10:10:53 -0500
> Harry Wentland wrote:
>
> > From: Joshua Ashton
> >
> > Userspace has no way of controlling or knowing the pixel encoding
> > currently, so there is no way for it to ever get the right values here.
> >
On Wed, Mar 8, 2023 at 9:59 AM Pekka Paalanen wrote:
>
> On Tue, 7 Mar 2023 10:10:52 -0500
> Harry Wentland wrote:
>
> > From: Joshua Ashton
> >
> > To match the other enums, and add more information about these values.
> >
> > v2:
> > - Specify where an enum entry comes from
> > - Clarify
Hi Ville
Thanks for the comments.
On 3/8/2023 4:10 PM, Ville Syrjälä wrote:
On Wed, Mar 08, 2023 at 03:33:48PM -0800, Rob Clark wrote:
On Wed, Mar 8, 2023 at 1:23 PM Ville Syrjälä
wrote:
On Wed, Mar 08, 2023 at 12:02:42PM -0800, Abhinav Kumar wrote:
For DRM property blobs created by user
On Wed, Mar 08, 2023 at 03:33:48PM -0800, Rob Clark wrote:
> On Wed, Mar 8, 2023 at 1:23 PM Ville Syrjälä
> wrote:
> >
> > On Wed, Mar 08, 2023 at 12:02:42PM -0800, Abhinav Kumar wrote:
> > > For DRM property blobs created by user mode using
> > > drm_property_create_blob(), if the blob value
Hi Andrzej,
On Wed, Mar 08, 2023 at 04:39:05PM +0100, Andrzej Hajda wrote:
> Since nop_clear_range is visible it can be used here.
>
> Signed-off-by: Andrzej Hajda
Reviewed-by: Andi Shyti
Thanks,
Andi
Hi Andrzej,
On Wed, Mar 08, 2023 at 04:39:04PM +0100, Andrzej Hajda wrote:
> Since nop_clear_range is visible it can be used here.
>
> Signed-off-by: Andrzej Hajda
Reviewed-by: Andi Shyti
Thanks,
Andi
Hi Andrzej,
On Wed, Mar 08, 2023 at 04:39:03PM +0100, Andrzej Hajda wrote:
> Function nop_clear_range can be used instead of local implementations.
>
> Signed-off-by: Andrzej Hajda
Reviewed-by: Andi Shyti
Andi
On 12/30/2022 7:35 AM, Robert Foss wrote:
Add mdss, mdss_mdp, dsi0, dsi0_phy nodes. With these
nodes the display subsystem is configured to support
one DSI output.
Signed-off-by: Robert Foss
Reviewed-by: Jessica Zhang
Tested-by: Jessica Zhang #SM8350 (HDK)
---
On 12/30/2022 7:35 AM, Robert Foss wrote:
The sm8350-hdk ships with the LT9611 UXC DSI/HDMI bridge chip.
In order to toggle the board to enable the HDMI output,
switch #7 & #8 on the rightmost multi-switch package have
to be toggled to On.
Signed-off-by: Robert Foss
Reviewed-by: Jessica
On 12/30/2022 7:35 AM, Robert Foss wrote:
Enable the display subsystem and the dsi0 output for
the sm8350-hdk board.
Signed-off-by: Robert Foss
Reviewed-by: Jessica Zhang
Tested-by: Jessica Zhang #SM8350 (HDK)
---
arch/arm64/boot/dts/qcom/sm8350-hdk.dts | 22 ++
On 12/30/2022 7:35 AM, Robert Foss wrote:
Add GPIO line names as described by the sm8350-hdk schematic.
Signed-off-by: Robert Foss
Reviewed-by: Jessica Zhang
Tested-by: Jessica Zhang #SM8350 (HDK)
---
arch/arm64/boot/dts/qcom/sm8350-hdk.dts | 205
1 file
Hi, Justin:
Justin Green 於 2023年3月8日 週三 下午11:34寫道：
>
Describe more about what and why this patch does. The other
modification looks good to me.
Regards,
Chun-Kuang.
> Tested using "modetest -P" on an MT8195 device.
>
> Signed-off-by: Justin Green
> ---
>
Hi, Justin:
Justin Green 於 2023年3月8日 週三 下午11:34寫道：
>
> Tested using "modetest -P" on an MT8195 device.
I think you could not test this when only apply the first two patches
of this series, so move the test information to the third patch. In
this patch, you could describe more about what and why
On Wed, Mar 8, 2023 at 1:23 PM Ville Syrjälä
wrote:
>
> On Wed, Mar 08, 2023 at 12:02:42PM -0800, Abhinav Kumar wrote:
> > For DRM property blobs created by user mode using
> > drm_property_create_blob(), if the blob value needs to be updated the
> > only way is to destroy the previous blob and
From: Fei Yang
On MTL, objects allocated through i915_gem_object_create_internal() are
mapped as uncached in GPU by default because HAS_LLC is false. However
in the live_hwsp_read selftest these watcher objects are mapped as WB
on CPU side. The conseqence is that the updates done by the GPU are
Hi, Justin:
Justin Green 於 2023年3月8日 週三 下午11:34寫道：
>
> Add an DDP component interface for querying pixel format support and move list
> of supported pixel formats into DDP components instead of mtk_drm_plane.c
Reviewed-by: Chun-Kuang Hu
>
> Tested by running Chrome on an MT8195.
>
>
On Tue, Mar 07, 2023 at 04:45:24PM +, David Binderman wrote:
> Hello there,
>
> I just ran the static analyser "cppcheck" over the source code of
> linux-6.2-rc1. It said:
>
> linux-6.3-rc1/drivers/gpu/drm/bridge/fsl-ldb.c:101:3: style: int
> result is returned as long value. If the return
On 3/3/2023 4:57 AM, Dmitry Baryshkov wrote:
Typically SSPP can support rectangle with width up to 2560. However it's
possible to use multirect feature and split source to use the SSPP to
output two consecutive rectangles. This commit brings in this capability
to support wider screen
On Wednesday 08 March 2023 21:01:09 Luis Chamberlain wrote:
> On Wed, Mar 08, 2023 at 09:07:07PM +0800, Baoquan He wrote:
> > From: Arnd Bergmann
> >
> > ioremap_uc() is only meaningful on old x86-32 systems with the PAT
> > extension, and on ia64 with its slightly unconventional ioremap()
> >
On Mon, Mar 06, 2023 at 02:40:11PM +0100, Alexandre Mergnat wrote:
> The item which have the mediatek,mt8192-disp-ccorr const compatible already
> exist above. Remove duplicated fallback.
Drop 'Fixes ' at the beginning of the subject.
>
> Fixes: 137272ef1b0f ("dt-bindings: display: mediatek:
AL13N schreef op 2023-03-08 22:16:
Maxime Ripard schreef op 2023-03-08 13:35:
Hi,
On Tue, Mar 07, 2023 at 05:10:16PM +, Dave Stevenson wrote:
On Tue, 7 Mar 2023 at 16:25, AL13N wrote:
> AL13N schreef op 2023-03-06 17:34:
> > I have a RPI4B connected on 2nd HDMI port (furthest away from
On 3/7/23 14:08, harperchen wrote:
fb_set_var would by called when user invokes ioctl with cmd
FBIOPUT_VSCREENINFO. User-provided data would finally reach
tgafb_check_var. In case var->pixclock is assigned to zero,
divide by zero would occur when checking whether reciprocal
of var->pixclock is
Hi,
On 3/8/23 22:58, Hans de Goede wrote:
> Hi All,
>
> Here is version 2 of my patch series to pass the proper parent device
> to backlight_device_register().
>
> New in version 2 is delaying the registering of the backlight_dev till
> after the drm_connector is registered by doing it from
>
On 3/8/23 08:19, Lukas Bulwahn wrote:
This was triggered by the fact that the webpage:
http://www.winischhofer.net/linuxsisvga.shtml
cannot be reached anymore.
Thomas Winischhofer is still reachable at the given email address, but he
has not been active since 2005.
Mark the SIS
On Wed, 2023-03-08 at 14:02 -0800, Teres Alexis, Alan Previn wrote:
> On Thu, 2023-02-16 at 18:24 -0800, john.c.harri...@intel.com wrote:
> > From: John Harrison
> >
> > The seqno value actually written out to memory is no longer in the
> > regular HWSP. Instead, it is now in its own private
On Thu, 2023-02-16 at 18:24 -0800, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> The seqno value actually written out to memory is no longer in the
> regular HWSP. Instead, it is now in its own private timeline buffer.
> Thus, it is no longer visible in an error capture. So,
Make amdgpu_dm_register_backlight_device() take an amdgpu_dm_connector
pointer to the connector for which it should register the backlight
as its only argument.
This is a preparation patch for moving the actual backlight class device
registering to drm_connector_funcs.late_register.
The parent for the backlight device should be the drm-connector object,
not the PCI device.
Userspace relies on this to be able to detect which backlight class device
to use on hybrid gfx devices where there may be multiple native (raw)
backlight devices registered.
Specifically
Currently functions like update_connector_ext_caps() and
amdgpu_dm_connector_destroy() are iterating over dm->backlight_link[i]
to find the index of the (optional) backlight_dev associated with
the connector.
Instead make register_backlight_device() store the dm->backlight_dev[]
index used for
Rename register_backlight_device() to setup_backlight_device()
and move all backlight setup related calls from
amdgpu_dm_register_backlight_device() and from
amdgpu_dm_initialize_drm_device() there.
This leaves amdgpu_dm_register_backlight_device() dealing purely
with registering the actual
Refactor register_backlight_device():
1) Turn the connector-type + signal check into an early exit
condition to avoid the indentation level of the rest of the code
2) Add an array bounds check for the arrays indexed by dm->num_of_edps
3) register_backlight_device() always increases
backlight_device_register() returns an ERR_PTR on error, but other code
such as amdgpu_dm_connector_destroy() assumes dm->backlight_dev[i] is NULL
if no backlight is registered.
Clear dm->backlight_dev[i] on registration failure, to avoid other code
trying to deref an ERR_PTR pointer.
Hi All,
Here is version 2 of my patch series to pass the proper parent device
to backlight_device_register().
New in version 2 is delaying the registering of the backlight_dev till
after the drm_connector is registered by doing it from
drm_connector_funcs.late_register.
This involves first
On 3/8/23 22:34, Arnd Bergmann wrote:
0On Wed, Mar 8, 2023, at 21:01, Luis Chamberlain wrote:
On Wed, Mar 08, 2023 at 09:07:07PM +0800, Baoquan He wrote:
From: Arnd Bergmann
ioremap_uc() is only meaningful on old x86-32 systems with the PAT
extension, and on ia64 with its slightly
kgd_mem should be accessed with p->mutex locked, or it could have been
freed by kfd_ioctl_free_memory_of_gpu.
Signed-off-by: Chia-I Wu
---
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git
0On Wed, Mar 8, 2023, at 21:01, Luis Chamberlain wrote:
> On Wed, Mar 08, 2023 at 09:07:07PM +0800, Baoquan He wrote:
>> From: Arnd Bergmann
>>
>> ioremap_uc() is only meaningful on old x86-32 systems with the PAT
>> extension, and on ia64 with its slightly unconventional ioremap()
>> behavior,
On Wed, Mar 08, 2023 at 12:02:42PM -0800, Abhinav Kumar wrote:
> For DRM property blobs created by user mode using
> drm_property_create_blob(), if the blob value needs to be updated the
> only way is to destroy the previous blob and create a new one instead.
>
> For some of the property blobs,
Maxime Ripard schreef op 2023-03-08 13:35:
Hi,
On Tue, Mar 07, 2023 at 05:10:16PM +, Dave Stevenson wrote:
On Tue, 7 Mar 2023 at 16:25, AL13N wrote:
> AL13N schreef op 2023-03-06 17:34:
> > I have a RPI4B connected on 2nd HDMI port (furthest away from power)
> > to a 4K TV, which works
Am 08.03.23 um 20:45 schrieb Asahi Lina:
On 09/03/2023 04.12, Christian König wrote:
Am 08.03.23 um 20:05 schrieb Asahi Lina:
[SNIP]
Well it's not the better way, it's the only way that works.
I have to admit that my bet on your intentions was wrong, but even that
use case doesn't work
For DRM property blobs created by user mode using
drm_property_create_blob(), if the blob value needs to be updated the
only way is to destroy the previous blob and create a new one instead.
For some of the property blobs, if the size of the blob is more
than one page size, kvzalloc() can slow
On Wed, Mar 08, 2023 at 09:07:07PM +0800, Baoquan He wrote:
> From: Arnd Bergmann
>
> ioremap_uc() is only meaningful on old x86-32 systems with the PAT
> extension, and on ia64 with its slightly unconventional ioremap()
> behavior, everywhere else this is the same as ioremap() anyway.
>
>
On 09/03/2023 04.12, Christian König wrote:
> Am 08.03.23 um 20:05 schrieb Asahi Lina:
>> [SNIP]
>>> Well it's not the better way, it's the only way that works.
>>>
>>> I have to admit that my bet on your intentions was wrong, but even that
>>> use case doesn't work correctly.
>>>
>>> See when
On 09/03/2023 03.12, Christian König wrote:
> Am 08.03.23 um 18:32 schrieb Asahi Lina:
>> [SNIP]
>> Yes but... none of this cleans up jobs that are already submitted by the
>> scheduler and in its pending list, with registered completion callbacks,
>> which were already popped off of the entities.
Am 08.03.23 um 20:05 schrieb Asahi Lina:
[SNIP]
Well it's not the better way, it's the only way that works.
I have to admit that my bet on your intentions was wrong, but even that
use case doesn't work correctly.
See when your callback returns false it is perfectly possible that all
hw fences
On 09/03/2023 02.57, Christian König wrote:
> Am 08.03.23 um 17:44 schrieb Asahi Lina:
>> On 09/03/2023 00.30, Christian König wrote:
>>> Am 08.03.23 um 15:53 schrieb Asahi Lina:
[SNIP]
> The background is that core memory management requires that signaling a
> fence only depends on
On Tue, 28 Feb 2023 11:26:58 +0100, AngeloGioacchino Del Regno wrote:
> MT8186 has a Mali-G52 MC2 2EE GPU (two cores): add a binding with
> two power domains (one per core) for it.
>
> Signed-off-by: AngeloGioacchino Del Regno
>
> Reviewed-by: Chen-Yu Tsai
> ---
>
On Tue, Feb 28, 2023 at 11:26:55AM +0100, AngeloGioacchino Del Regno wrote:
> Commit ("dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183")
> incorrectly introduced power domain names for MT8183, causing
> validation issues.
>
> Add power-domain-names to the base schema, allowing a maximum of
>
On Tue, 28 Feb 2023 11:26:54 +0100, AngeloGioacchino Del Regno wrote:
> In preparation for adding (and fixing) power-domain-names and MediaTek
> MT8192 bindings, allow up to five items for power-domains.
>
> Signed-off-by: AngeloGioacchino Del Regno
>
> ---
>
On Tue, 28 Feb 2023 11:26:53 +0100, AngeloGioacchino Del Regno wrote:
> In preparation for adding new bindings for new MediaTek SoCs, split out
> the power-domains variation from the `else` in the current
> mediatek,mt8183-mali conditional.
>
> The sram-supply part is left in place to be
On Tue, 07 Mar 2023 14:01:47 +0100, Konrad Dybcio wrote:
> Add a compatible for the DSI on SM6115.
>
> Signed-off-by: Konrad Dybcio
> ---
> .../devicetree/bindings/display/msm/dsi-controller-main.yaml | 2 ++
> .../devicetree/bindings/display/msm/qcom,sm6115-mdss.yaml | 8
>
Am 08.03.23 um 18:39 schrieb aly...@rosenzweig.io:
You can't ask me for a list
of pending jobs (the scheduler knows this, it doesn't make any sense to
duplicate that outside)
Silly question: could you add a new exported function to drm_sched to get the
list of pending jobs, to be used by the
Am 08.03.23 um 18:32 schrieb Asahi Lina:
[SNIP]
Yes but... none of this cleans up jobs that are already submitted by the
scheduler and in its pending list, with registered completion callbacks,
which were already popped off of the entities.
*That* is the problem this patch fixes!
Ah! Yes that
On Fri, 03 Mar 2023 15:42:23 -0600, Rob Herring wrote:
> Enable yamllint to check the prefered commenting style of requiring a
> space after a comment character '#'. Fix the cases in the tree which
> have a warning with this enabled. Most cases just need a space after the
> '#'. A couple of
Am 08.03.23 um 17:44 schrieb Asahi Lina:
On 09/03/2023 00.30, Christian König wrote:
Am 08.03.23 um 15:53 schrieb Asahi Lina:
[SNIP]
The background is that core memory management requires that signaling a
fence only depends on signaling other fences and hardware progress and
nothing else.
In adv7511_probe, adv7511->hpd_work is bound with adv7511_hpd_work.
If we call adv7511_remove with a unfinished work. There may be a
race condition where bridge->hpd_mutex was destroyed by
drm_bridge_remove and used in adv7511_hpd_work in drm_bridge_hpd_notify.
Fix it by canceling the work
> You can't ask me for a list
> of pending jobs (the scheduler knows this, it doesn't make any sense to
> duplicate that outside)
Silly question: could you add a new exported function to drm_sched to get the
list of pending jobs, to be used by the Rust abstraction internally? IDK if
that makes
On 09/03/2023 02.39, aly...@rosenzweig.io wrote:
>> You can't ask me for a list
>> of pending jobs (the scheduler knows this, it doesn't make any sense to
>> duplicate that outside)
>
> Silly question: could you add a new exported function to drm_sched to get the
> list of pending jobs, to be
On 2023-03-07 19:19, Chia-I Wu wrote:
Set *q to NULL on errors, otherwise pqm_create_queue would free it
again.
Signed-off-by: Chia-I Wu
Thank you! I'm applying this patch to amd-staging-drm-next.
Reviewed-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c |
On 09/03/2023 00.42, Christian König wrote:
> Am 08.03.23 um 16:18 schrieb Asahi Lina:
>> On 08/03/2023 19.03, Christian König wrote:
>>> Am 08.03.23 um 10:57 schrieb Maarten Lankhorst:
On 2023-03-07 15:25, Asahi Lina wrote:
> drm_sched_fini() currently leaves any pending jobs dangling,
On 08/03/2023 16:56, Nathan Chancellor wrote:
Ping? This warning is now in 6.3-rc1.
Thierry is away at the moment.
David, Daniel, do you want to pick this up directly in the meantime as a
fix for 6.3? Mikko has already reviewed and FWIW ...
Reviewed-by: Jon Hunter
Thanks
Jon
On
1 - 100 of 263 matches
Mail list logo
