On Thu, Aug 18, 2022 at 04:02:28PM -0700, Daniele Ceraolo Spurio wrote:
> Note that this series includes several mei patches that add support for
> sending the HuC loading command via mei-gsc. These patches depend on the
> GSC support for DG2 [1], which has been included squashed in a single
> patc
Hi,
On Fri, Aug 19, 2022 at 02:29:04AM +0200, Danilo Krummrich wrote:
> (Hardware) resources which are bound to the driver and device lifecycle
> must not be accessed after the device and driver are unbound.
>
> However, the DRM device isn't freed as long as the last user closed it,
> hence users
Hi,
On Fri, Aug 19, 2022 at 02:29:05AM +0200, Danilo Krummrich wrote:
> (Hardware) resources which are bound to the driver and device lifecycle
> must not be accessed after the device and driver are unbound.
>
> However, the DRM device isn't freed as long as the last user closed it,
> hence users
Currently we are assuming a one to one mapping between dmabuf and
GEM handle when releasing GEM handles.
But that is not always true, since we would create extra handles for the
GEM obj in cases like gem_open() and getfb{,2}().
A similar issue was reported at:
https://lore.kernel.org/all/20211105
Hi,
On Thu, Aug 18, 2022 at 09:36:35PM +0100, Sudip Mukherjee wrote:
> On Wed, Aug 17, 2022 at 8:10 AM Maxime Ripard wrote:
> >
> > Hi,
> >
> > On Tue, Aug 16, 2022 at 05:34:51PM +0100, Sudip Mukherjee (Codethink) wrote:
> > > Not sure if it has been reported but the mainline kernel shows a drm
Hi Christian,
I'm looking for a way to take some sort of reference across possible
VRAM accesses over the PCI bar, be it for runtime PM, workarounds or
whatever.
The ttm_mem_io_reserve/free seems like a good candidate, but is
completely unbalanced and looks racy. In particular error paths f
(It seems like the list was dropped in my reply, sorry about that.
Re-adding it now.)
On Thursday, August 18th, 2022 at 14:06, Michał Winiarski
wrote:
> On Thu, Aug 18, 2022 at 07:39:13AM +, Simon Ser wrote:
>
> > Hm, I'm a bit worried about the user-space implications of this… e.g. libdrm
Hi Olivier,
On Fri, 12 Aug 2022 at 20:01, Olivier Masse wrote:
>
> Add a new ioctl called TEE_IOC_SHM_REGISTER_FD to register a
> shared memory from a dmabuf file descriptor.
> This new ioctl will allow the Linux Kernel to register a buffer
> to be used by the Secure Data Path OPTEE OS feature.
>
Hi,
On 8/18/22 22:07, Daniel Dadap wrote:
>
> On 8/18/22 1:42 PM, Hans de Goede wrote:
>> On x86/ACPI boards the acpi_video driver will usually initialize before
>> the kms driver (except i915). This causes /sys/class/backlight/acpi_video0
>> to show up and then the kms driver registers its own n
Hi Thomas,
IIRC we intentionally dropped that approach of balancing
ttm_mem_io_reserve()/ttm_mem_io_free().
Instead the results from ttm_mem_io_reserve() are cached and that cached
information is freed by ttm_mem_io_free(). In other words every time we
need to make sure we have the cache fil
On Fri, 19 Aug 2022 08:14, "" wrote:
>Add ovl_adaptor driver for MT8195.
>Ovl_adaptor is an encapsulated module and designed for simplified
>DRM control flow. This module is composed of 8 RDMAs, 4 MERGEs and
>an ETHDR. Two RDMAs merge into one layer, so this module support 4
>layers.
>
Hi Nancy, so
On Fri, Aug 19, 2022 at 08:16:07AM +, Simon Ser wrote:
> (It seems like the list was dropped in my reply, sorry about that.
> Re-adding it now.)
>
> On Thursday, August 18th, 2022 at 14:06, Michał Winiarski
> wrote:
>
> > On Thu, Aug 18, 2022 at 07:39:13AM +, Simon Ser wrote:
> >
> > >
From: Ville Syrjälä
EDID 1.4 introduced some extra flags in the range
descriptor to support min/max h/vfreq >= 255. Consult them
to correctly parse the vfreq limits.
Cc: sta...@vger.kernel.org
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6519
Signed-off-by: Ville Syrjälä
---
drive
Hi Maxime,
On Thu, Aug 18, 2022 at 5:34 PM Maxime Ripard wrote:
> On Thu, Aug 18, 2022 at 05:20:42PM +0200, Geert Uytterhoeven wrote:
> > On Thu, Aug 18, 2022 at 4:54 PM Maxime Ripard wrote:
> > > On Wed, Aug 17, 2022 at 04:04:24PM +0200, Geert Uytterhoeven wrote:
> > > > On Wed, Aug 17, 2022 at
Hi,
On 8/18/22 21:38, Daniel Dadap wrote:
>
> On 8/18/22 1:42 PM, Hans de Goede wrote:
>> Move the WMI interface definitions to a header, so that the definitions
>> can be shared with drivers/acpi/video_detect.c .
>>
>> Suggested-by: Daniel Dadap
>> Signed-off-by: Hans de Goede
>> ---
>> MAIN
Am 19.08.22 um 11:34 schrieb 李真能:
在 2022/8/17 19:40, Christian König 写道:
Am 17.08.22 um 09:31 schrieb 李真能:
在 2022/8/15 21:12, Christian König 写道:
Am 15.08.22 um 09:34 schrieb 李真能:
在 2022/8/12 18:55, Christian König 写道:
Am 11.08.22 um 09:25 schrieb Zhenneng Li:
Although radeon card fence
se '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Nancy-Lin/Add-MediaTek-SoC-DRM-vdosys1-support-for-mt8195/20220819-142314
base: git://anongit.freedesktop.org/drm/drm-misc drm-m
On Wed, 27 Jul 2022, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> It is useful to be able to match GuC events to kernel events when
> looking at the GuC log. That requires being able to convert GuC
> timestamps to kernel time. So, when dumping error captures and/or GuC
> logs, includ
No functional modification involved.
drivers/video/fbdev/sis/sis_main.c:6165 sisfb_probe() warn: inconsistent
indenting.
drivers/video/fbdev/sis/sis_main.c:4266 sisfb_post_300_rwtest() warn:
inconsistent indenting.
drivers/video/fbdev/sis/sis_main.c:2388 SISDoSense() warn: inconsistent
indentin
No functional modification involved.
drivers/video/fbdev/aty/radeon_base.c:2107 radeon_identify_vram() warn:
inconsistent indenting.
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=1932
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
drivers/video/fbdev/aty/radeon_base.c | 46 +
Hi,
I've found a few potential issues left after the hotplug rework.
In vc4_hdmi.c we're missing two mutex_unlock() calls when the device is
unplugged.
vc4_crtc and vc4_plane seem to miss some drm_dev_enter()/drm_dev_exit() calls
to protect against resource access after the device/driver is unbo
In vc4_hdmi_encoder_{pre,post}_crtc_enable() commit cd00ed5187bf
("drm/vc4: hdmi: Protect device resources after removal") missed to
unlock the mutex before returning due to drm_dev_enter() indicating the
device being unplugged.
Fixes: cd00ed5187bf ("drm/vc4: hdmi: Protect device resources after r
(Hardware) resources which are bound to the driver and device lifecycle
must not be accessed after the device and driver are unbound.
However, the DRM device isn't freed as long as the last user closed it,
hence userspace can still call into the driver.
Therefore protect the critical sections whi
(Hardware) resources which are bound to the driver and device lifecycle
must not be accessed after the device and driver are unbound.
However, the DRM device isn't freed as long as the last user closed it,
hence userspace can still call into the driver.
Therefore protect the critical sections whi
In vc4_hvs_dump_state() potentially freed resources are protected from
being accessed with drm_dev_enter()/drm_dev_exit().
Also include drm_print_regset32() in the protected section, since
drm_print_regset32() does access memory that is typically mapped via
devm_* calls.
Fixes: 969cfae1f01d ("drm
Hi Maxime,
On 8/19/22 09:26, Maxime Ripard wrote:
Hi,
On Fri, Aug 19, 2022 at 02:29:04AM +0200, Danilo Krummrich wrote:
(Hardware) resources which are bound to the driver and device lifecycle
must not be accessed after the device and driver are unbound.
However, the DRM device isn't freed as
Hi Hamza,
On 8/18/22 13:48, Hamza Mahfooz wrote:
> Addresses the following warning:
> drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn30/display_mode_vba_30.c:3596:6:
> error: stack frame size (2092) exceeds limit (2048) in
> 'dml30_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-
On 8/17/22 17:57, Mikhail Gavrilov wrote:
> On Wed, Aug 17, 2022 at 11:43 PM Maíra Canal wrote:
>>
>> Hi Mikhail,
>>
>> Looks like 45ecaea738830b9d521c93520c8f201359dcbd95 ("drm/sched: Partial
>> revert of 'drm/sched: Keep s_fence->parent pointer'") introduced the
>> error. Try reverting it and
On 8/18/22 13:19, Michał Winiarski wrote:
> On Thu, Aug 18, 2022 at 11:15:39AM -0300, Maíra Canal wrote:
>>
>>
>> On 8/17/22 18:12, Michał Winiarski wrote:
>>> Negative tests can be expressed as a single parameterized test case,
>>> which highlights that we're following the same test logic (pass
Am 19.08.22 um 09:28 schrieb Jeffy Chen:
Currently we are assuming a one to one mapping between dmabuf and
GEM handle when releasing GEM handles.
But that is not always true, since we would create extra handles for the
GEM obj in cases like gem_open() and getfb{,2}().
A similar issue was report
On Fri, 2022-08-19 at 09:09 -0300, Maíra Canal wrote:
> Hi Jouni,
>
> On 7/15/22 10:49, Jouni Högander wrote:
> > drm_plane_state->src might be modified by the driver. This is done
> > e.g. in i915 driver when there is bigger framebuffer than the plane
> > and there is some offset within framebuff
Am 19.08.22 um 15:11 schrieb Jason Gunthorpe:
On Thu, Aug 18, 2022 at 03:37:01PM +0200, Christian König wrote:
Am 18.08.22 um 15:16 schrieb Jason Gunthorpe:
On Thu, Aug 18, 2022 at 02:58:10PM +0200, Christian König wrote:
The only thing I'm not 100% convinced of is dma_buf_try_get(), I've see
On Fri, Aug 19, 2022 at 03:33:04PM +0200, Christian König wrote:
> > > > So we could delete the try_buf and just rely on move being safe on
> > > > partially destroyed dma_buf's as part of the API design.
> > > I think that might be the more defensive approach. A comment on the
> > > dma_buf_move_
Am 19.08.22 um 15:39 schrieb Jason Gunthorpe:
On Fri, Aug 19, 2022 at 03:33:04PM +0200, Christian König wrote:
So we could delete the try_buf and just rely on move being safe on
partially destroyed dma_buf's as part of the API design.
I think that might be the more defensive approach. A commen
Drop the crtc_ prefix from mode, consistently use the plain one.
Acked-by: Sam Ravnborg
Reviewed-by: Liu Ying
Reported-by: Liu Ying
Tested-by: Martyn Welch
Fixes: 9db35bb349a0e ("drm: lcdif: Add support for i.MX8MP LCDIF variant")
Signed-off-by: Marek Vasut
Cc: Alexander Stein
Cc: Laurent Pi
Drop unneeded headers, sort rest alphabetically, no functional change.
Acked-by: Sam Ravnborg
Reviewed-by: Liu Ying
Reported-by: Liu Ying
Tested-by: Martyn Welch
Fixes: 9db35bb349a0e ("drm: lcdif: Add support for i.MX8MP LCDIF variant")
Signed-off-by: Marek Vasut
Cc: Alexander Stein
Cc: Laur
Update debug print to report bridge timings over connector ones.
Drop missed comment commit from mxsfb.
Acked-by: Sam Ravnborg
Reviewed-by: Liu Ying
Reported-by: Liu Ying
Tested-by: Martyn Welch
Fixes: 9db35bb349a0e ("drm: lcdif: Add support for i.MX8MP LCDIF variant")
Signed-off-by: Marek Vas
The function "drm_of_find_panel_or_bridge" has been deprecated in
favor of "devm_drm_of_get_bridge".
Switch to the new function and reduce boilerplate.
Acked-by: Sam Ravnborg
Reviewed-by: Liu Ying
Reported-by: Liu Ying
Tested-by: Martyn Welch
Fixes: 9db35bb349a0e ("drm: lcdif: Add support for
On Fri, Aug 19, 2022 at 12:13:23PM +0800, Nancy.Lin wrote:
> Hi Nicolas,
>
>
> On Fri, 2022-08-19 at 10:09 +0800, Nancy.Lin wrote:
> > Hi Nicolas,
> >
> > Thanks for the review.
> >
> > On Thu, 2022-08-18 at 17:47 -0400, Nícolas F. R. A. Prado wrote:
> > > Hi Nancy,
> > >
> > > On Mon, Jul 11,
.org/0day-ci/archive/20220819/202208192254.jhkstqcs-...@intel.com/config)
compiler: clang version 16.0.0 (https://github.com/llvm/llvm-project
0ac597f3cacf60479ffd36b03766fa7462dabd78)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin
On 8/19/2022 12:21 AM, Greg Kroah-Hartman wrote:
On Thu, Aug 18, 2022 at 04:02:28PM -0700, Daniele Ceraolo Spurio wrote:
Note that this series includes several mei patches that add support for
sending the HuC loading command via mei-gsc. These patches depend on the
GSC support for DG2 [1], wh
Hi,
thanks for the additional information, we are starting to have a (still partial)
overview of your team goals.
Le jeudi 18 août 2022 à 05:25 +, Cyrille Fleury a écrit :
> Hi Nicolas, all,
>
> The short reply:
> - For DRM, gstreamer, ffmeg, ... we don't use anymore NXP VPU
> proprie
Le vendredi 19 août 2022 à 02:13 +0300, Laurent Pinchart a écrit :
> On Thu, Aug 18, 2022 at 02:33:42PM +0800, Hsia-Jun Li wrote:
> > On 8/18/22 14:06, Tomasz Figa wrote:
> > > On Tue, Aug 9, 2022 at 1:28 AM Hsia-Jun Li wrote:
> > > >
> > > > From: "Hsia-Jun(Randy) Li"
> > > >
> > > > The most
On 8/19/22 23:28, Nicolas Dufresne wrote:
CAUTION: Email originated externally, do not click links or open attachments
unless you recognize the sender and know the content is safe.
Le vendredi 19 août 2022 à 02:13 +0300, Laurent Pinchart a écrit :
On Thu, Aug 18, 2022 at 02:33:42PM +0800,
Applied. Thanks!
On Wed, Aug 17, 2022 at 10:59 PM Yang Li wrote:
>
> Semicolon is not required after curly braces.
>
> Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=1918
> Reported-by: Abaci Robot
> Signed-off-by: Yang Li
> ---
> drivers/gpu/drm/amd/display/dc/clk_mgr/dcn314/dcn314_clk
Applied. Thanks!
Alex
On Thu, Aug 18, 2022 at 9:28 AM Maíra Canal wrote:
>
> The file amdgpu_dm_plane.c missed the header amdgpu_dm_plane.h, which
> resulted on the following warning:
>
> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.c:1046:5:
> warning: no previous prototype
Applied. Thanks!
Alex
On Thu, Aug 18, 2022 at 9:53 PM Magali Lemes wrote:
>
> dml_wrapper* files were removed in commit 724449e30433
> ("drm/amd/display: Remove unused code"), as they are not used anywhere.
> However, the header file wasn't removed, so remove the header as well.
>
> Signed-off-
Applied. Thanks!
Alex
On Fri, Aug 19, 2022 at 6:07 AM Christian König
wrote:
>
> Am 19.08.22 um 11:34 schrieb 李真能:
>
> 在 2022/8/17 19:40, Christian König 写道:
>
> Am 17.08.22 um 09:31 schrieb 李真能:
>
>
> 在 2022/8/15 21:12, Christian König 写道:
>
> Am 15.08.22 um 09:34 schrieb 李真能:
>
>
> 在 2022/8/1
Hi, Christian,
On 8/19/22 10:52, Christian König wrote:
Hi Thomas,
IIRC we intentionally dropped that approach of balancing
ttm_mem_io_reserve()/ttm_mem_io_free().
Instead the results from ttm_mem_io_reserve() are cached and that
cached information is freed by ttm_mem_io_free(). In other wo
Am Mittwoch, dem 22.06.2022 um 10:52 +0200 schrieb Lucas Stach:
> Hi Christian,
>
> Am Freitag, dem 03.06.2022 um 14:37 +0200 schrieb Christian Gmeiner:
> > Track the pid per submit, so we can print the name and cmdline of
> > the task which submitted the batch that caused the gpu to hang.
> >
>
Am Mittwoch, dem 06.07.2022 um 18:29 + schrieb T.J. Mercier:
> The docs explicitly say the drm_gem_object_release function already calls
> this,
> and this does not appear to be a prerequisite for the call to
> etnaviv_gem_ops.release.
>
This looks correct to me. Patch applied to etnaviv/next
Add necessary definitions in gpucc bindings to ensure gpu cx gdsc collapse
through 'reset' framework for SC7280.
Signed-off-by: Akhil P Oommen
Acked-by: Krzysztof Kozlowski
---
(no changes since v1)
include/dt-bindings/clock/qcom,gpucc-sc7280.h | 3 +++
1 file changed, 3 insertions(+)
diff -
Some clients like adreno gpu driver would like to ensure that its gdsc
is collapsed at hardware during a gpu reset sequence. This is because it
has a votable gdsc which could be ON due to a vote from another subsystem
like tz, hyp etc or due to an internal hardware signal. To allow
this, gpucc dr
Allow soc specific clk drivers to specify a custom reset operation. We
will use this in an upcoming patch to allow gpucc driver to specify a
differet reset operation for cx_gdsc.
Signed-off-by: Akhil P Oommen
---
(no changes since v3)
Changes in v3:
- Use pointer to const for "struct qcom_reset
Allow a consumer driver to poll for cx gdsc collapse through Reset
framework.
Signed-off-by: Akhil P Oommen
---
(no changes since v3)
Changes in v3:
- Convert 'struct qcom_reset_ops cx_gdsc_reset' to 'static const' (Krzysztof)
Changes in v2:
- Minor update to use the updated custom reset ops i
Add a reset op compatible function to poll for gdsc collapse.
Signed-off-by: Akhil P Oommen
---
(no changes since v2)
Changes in v2:
- Minor update to function prototype
drivers/clk/qcom/gdsc.c | 23 +++
drivers/clk/qcom/gdsc.h | 7 +++
2 files changed, 26 insertions(
Add an optional reference to GPUCC reset which can be used to ensure cx
gdsc collapse during gpu recovery.
Signed-off-by: Akhil P Oommen
---
Changes in v4:
- New patch in v4
Documentation/devicetree/bindings/display/msm/gpu.yaml | 7 +++
1 file changed, 7 insertions(+)
diff --git a/Docume
Hello,
czw., 4 sie 2022 o 10:32 Hans de Goede napisał(a):
>
> Hi,
>
> On 8/3/22 20:24, Maccraft123 wrote:
> > From: Maya Matuszczyk
> >
> > This device is another x86 gaming handheld, and as (hopefully) there is
> > only one set of DMI IDs it's using DMI_EXACT_MATCH
> >
> > Signed-off-by: Maya M
Add support for Reset using GPUCC driver for GPU. This helps to ensure
that GPU state is reset by making sure that CX head switch is collapsed.
Signed-off-by: Akhil P Oommen
---
(no changes since v1)
arch/arm64/boot/dts/qcom/sc7280.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/ar
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 8755ae45a9e8ae883fa7f4eb0162830c55aacf14 Add linux-next specific
files for 20220819
Error/Warning reports:
https://lore.kernel.org/linux-doc/202208192207.a0ram0nj-...@intel.com
Error/Warning
On 8/19/2022 11:47 AM, Krzysztof Kozlowski wrote:
On 18/08/2022 23:18, Akhil P Oommen wrote:
Add support for Reset using GPUCC driver for GPU. This helps to ensure
that GPU state is reset by making sure that CX head switch is collapsed.
Signed-off-by: Akhil P Oommen
---
(no changes since v1)
The pull request you sent on Fri, 19 Aug 2022 14:05:45 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2022-08-19
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/adb67b373a68b6ca4ea9225e248d726f0f5f0f8d
Thank you!
--
Deet-doot-dot, I am a bot.
https://k
The pull request you sent on Fri, 19 Aug 2022 14:05:45 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2022-08-19
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/adb67b373a68b6ca4ea9225e248d726f0f5f0f8d
Thank you!
--
Deet-doot-dot, I am a bot.
https://k
On Thu, Aug 18, 2022 at 2:09 PM Lukas Wunner wrote:
>
> On Tue, Aug 16, 2022 at 11:06:18AM +0300, Jani Nikula wrote:
> > On Tue, 16 Aug 2022, Kai-Heng Feng wrote:
> > > On mobile workstations like HP ZBook Fury G8, iGFX's DP-IN can switch to
> > > dGFX so external monitors are routed to dGFX, and
On 2022-08-18 15:34, Randy Dunlap wrote:
Hi--
On 8/18/22 12:15, Sudip Mukherjee wrote:
On Thu, Aug 18, 2022 at 4:10 PM Randy Dunlap wrote:
On 8/18/22 03:43, Sudip Mukherjee wrote:
On Thu, Aug 18, 2022 at 3:09 AM Randy Dunlap wrote:
On 8/17/22 19:01, Alex Deucher wrote:
On Wed, Aug 17, 2
Summary
===
This series of patches refactor some vkms components in order to introduce
new formats to the planes and writeback connector.
Now in the blend function, the plane's pixels are converted to ARGB16161616
and then blended together.
The CRC is calculated based on the ARGB1616161616 bu
Changes the name of this struct to a more meaningful name.
A name that represents better what this struct is about.
Composer is the code that do the compositing of the planes.
This struct contains information on the frame used in the output
composition. Thus, vkms_frame_info is a better name to re
Currently the blend function only accepts XRGB_ and ARGB_
as a color input.
This patch refactors all the functions related to the plane composition
to overcome this limitation.
The pixels blend is done using the new internal format. And new handlers
are being added to convert a specific f
The `map` vector at `vkms_composer` uses a hardcoded value to define its
size.
If someday the maximum number of planes increases, this hardcoded value
can be a problem.
This value is being replaced with the DRM_FORMAT_MAX_PLANES macro.
Acked-by: Thomas Zimmermann
Reviewed-by: Melissa Wen
Signe
Add a helper function to validate the connector configuration received in
the encoder atomic_check by the drivers.
So the drivers don't need to do these common validations themselves.
V2: Move the format verification to a new helper at the drm_atomic_helper.c
(Thomas Zimmermann).
V3: Format c
This will be useful to write tests that depends on these formats.
ARGB and XRGB follows the a similar implementation of the former formats.
Just adjusting for 16 bits per channel.
V3: Adapt the handlers to the new format introduced in patch 7 V3.
V5: Minor improvements
Added le16_to_cpu/cpu_t
We will remove the current assumption that the primary plane has the
same size and position as CRTC and that the primary plane is the
bottom-most in zpos order, or is even enabled. At least as far
as the blending machinery is concerned.
For that we will add CRTC dimension information to `vkms_crtc
This commit also adds new helper macros to deal with fixed-point
arithmetic.
It was done to improve the precision of the conversion to ARGB16161616
since the "conversion ratio" is not an integer.
V3: Adapt the handlers to the new format introduced in patch 7 V3.
V5: Minor improvements
V6: Minor i
Instead of coping `drm_framebuffer` - which can cause problems -
we just get the reference and add the ref count.
Signed-off-by: Igor Torrente
---
drivers/gpu/drm/vkms/vkms_composer.c | 4 ++--
drivers/gpu/drm/vkms/vkms_drv.h | 2 +-
drivers/gpu/drm/vkms/vkms_plane.c| 10 +-
3
This commit is the groundwork to introduce new formats to the planes and
writeback buffer. As part of it, a new buffer metadata field is added to
`vkms_writeback_job`, this metadata is represented by the `vkms_frame_info`
struct.
Also adds two new function pointers (`line_to_frame_func` and
`frame
Hi Xinlei,
On Fri, Aug 05, 2022 at 05:57:41PM +0800, xinlei@mediatek.com wrote:
> From: Xinlei Lee
>
> Dpi output needs to adjust the output format to dual edge for MT8186.
Could you explain a bit more why this is needed? What does this configuration
do? And why is MMSYS involved in a DPI c
Hi Xinlei,
On Fri, Aug 05, 2022 at 05:57:40PM +0800, xinlei@mediatek.com wrote:
> From: Xinlei Lee
>
> Add mmsys func to manipulate dpi output format config for MT8186.
func -> function
config -> configuration
>
> Signed-off-by: Jitao Shi
Same thing about the co-developed-by.
> Signed-
On Thu, Aug 18, 2022 at 04:41:42PM -0700, Radhakrishna Sripada wrote:
> From: Matt Roper
>
> Going forward, the hardware teams no longer consider new platforms to
> have a "generation" in the way we've defined it for past platforms.
> Instead, each IP block (graphics, media, display) will have th
Use devm helpers for regulator get and enable
NOTE: The series depends on commit
ee94aff2628b ("Devm helpers for regulator get and enable")
which currently sits in Mark's regulator/for-next
A few* drivers seem to pattern demonstrated by pseudocode:
- devm_regulator_get()
- regulator_enable()
- d
On Thu, Aug 18, 2022 at 04:41:48PM -0700, Radhakrishna Sripada wrote:
> Add tables to map the GMBUS pin pairs to GPIO registers and port to DDC.
> From spec we have registers GPIO_CTL[1-5] mapped to native display phys and
> GPIO_CTL[9-14] are mapped to TC ports.
>
> BSpec: 49306
>
> Original Aut
Simplify drivers using managed "regulator get and enable".
meson:
Use the devm_regulator_get_enable_optional(). Also drop the seemingly
unused struct member 'hdmi_supply'.
sii902x:
Simplify using devm_regulator_bulk_get_enable()
Signed-off-by: Matti Vaittinen
---
v2 => v3:
No changes
RFCv1 =>
On Thu, Aug 18, 2022 at 04:41:54PM -0700, Radhakrishna Sripada wrote:
> Watermark latency is adjusted in cases when latency is 0us for level
> greater than 1, the subsequent levels are disabled. Extract this logic
> into its own function.
>
> Suggested-by: Matt Roper
> Signed-off-by: Radhakrishna
On Thu, Aug 18, 2022 at 04:41:55PM -0700, Radhakrishna Sripada wrote:
> Since Xe LPD+, Memory latency data are in LATENCY_LPX_LPY registers
> instead of GT driver mailbox.
>
> v2: Use the extracted wm latency adjustment function(Matt)
>
> Bspec: 64608
>
> Cc: Matt Roper
> Original Author: Caz Y
On Thu, Aug 18, 2022 at 04:42:02PM -0700, Radhakrishna Sripada wrote:
> No need to update mask value/restrict because
> "Pcode only wants to use GV bandwidth value, not the mask value."
> for Display version greater than 14.
While the code changes might be correct, I can't decipher what the
commit
On Fri, Aug 19, 2022 at 02:14:54PM +0800, Nancy.Lin wrote:
> MT8195 have two mmsys. Modify drm for MT8195 multi-mmsys support.
> The two mmsys (vdosys0 and vdosys1) will bring up two drm drivers,
> only one drm driver register as the drm device.
> Each drm driver binds its own component. The last b
On Fri, Aug 19, 2022 at 02:14:55PM +0800, Nancy.Lin wrote:
> Add drm ovl_adaptor sub driver. Bring up ovl_adaptor sub driver if
> the component exists in the path.
>
> Signed-off-by: Nancy.Lin
> Reviewed-by: AngeloGioacchino Del Regno
>
> Reviewed-by: CK Hu
> Tested-by: AngeloGioacchino Del Re
It is a bit unlcear to us why that's helping, but it does and unbreaks
suspend/resume on a lot of GPUs without any known drawbacks.
Cc: sta...@vger.kernel.org # v5.15+
Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/156
Signed-off-by: Karol Herbst
---
drivers/gpu/drm/nouveau/nouveau_
On 8/19/2022 03:45, Jani Nikula wrote:
On Wed, 27 Jul 2022, john.c.harri...@intel.com wrote:
From: John Harrison
It is useful to be able to match GuC events to kernel events when
looking at the GuC log. That requires being able to convert GuC
timestamps to kernel time. So, when dumping error c
Hi,
This patch series converts the driver to use drm managed resources to prevent
potential use-after-free issues on driver unbind/rebind and to get rid of the
usage of deprecated APIs.
Danilo Krummrich (8):
drm/arm/malidp: use drmm_* to allocate driver structures
drm/arm/malidp: replace drm-
Using drm_device->dev_private is deprecated. Since we've switched to
devm_drm_dev_alloc(), struct drm_device is now embedded in struct
malidp_drm, hence we can use container_of() to get the struct drm_device
instance instead.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/arm/malidp_crtc.c
Use drm managed resources to allocate driver structures and get rid of
the deprecated drm_dev_alloc() call and replace it with
devm_drm_dev_alloc().
This also serves as preparation to get rid of drm_device->dev_private
and to fix use-after-free issues on driver unload.
Signed-off-by: Danilo Krumm
Use drmm_crtc_init_with_planes() instead of drm_crtc_init_with_planes()
to get rid of the explicit destroy hook in struct drm_plane_funcs.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/arm/malidp_crtc.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/dr
(Hardware) resources which are bound to the driver and device lifecycle
must not be accessed after the device and driver are unbound.
However, the DRM device isn't freed as long as the last user didn't
close it, hence userspace can still call into the driver.
Therefore protect the critical sectio
When the driver is unbound, there might still be users in userspace
having an open fd and are calling into the driver.
While this is fine for drm managed resources, it is not for resources
bound to the device/driver lifecycle, e.g. clocks or MMIO mappings.
To prevent use-after-free issues we need
(Hardware) resources which are bound to the driver and device lifecycle
must not be accessed after the device and driver are unbound.
However, the DRM device isn't freed as long as the last user didn't
close it, hence userspace can still call into the driver.
Therefore protect the critical sectio
On DG2, HuC loading is performed by the GSC, via a PXP command. The load
operation itself is relatively simple (just send a message to the GSC
with the physical address of the HuC in LMEM), but there are timing
changes that requires special attention. In particular, to send a PXP
command we need to
From: Tomas Winkler
GSC extend header is of variable size and data
is provided in a sgl list inside the header
and not in the data buffers, need to enable the path.
Signed-off-by: Tomas Winkler
Signed-off-by: Daniele Ceraolo Spurio
Cc: Vitaly Lubart
Cc: Greg Kroah-Hartman
---
drivers/misc/m
From: Tomas Winkler
GSC command is and extended header containing a scatter gather
list and without a data buffer. Using MEI_CL_IO_SGL flag,
the caller send the GSC command as a data and the function internally
moves it to the extended header.
Signed-off-by: Tomas Winkler
Signed-off-by: Daniele
From: Vitaly Lubart
The discrete graphics card with GSC firmware
using command streamer API hence it requires to enhance
pxp module with the new gsc_command() handler.
The handler is implemented via mei_pxp_gsc_command() which is
just just a thin wrapper around mei_cldev_send_gsc_command()
V2:
The mei_pxp module is required to send the command to load authenticate
the HuC to the GSC even if pxp is not in use for protected content
management.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Alan Previn
Reviewed-by: Alan Previn
---
drivers/gpu/drm/i915/Makefile| 10 +++---
dr
1 - 100 of 122 matches
Mail list logo
