Host Turbo operates at efficient frequency when GT is not idle unless
the user or workload has forced it to a higher level. Replicate the same
behavior in SLPC by allowing the algorithm to use efficient frequency.
We had disabled it during boot due to concerns that it might break
kernel ABI for min
On 8/20/22 03:17, 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 à 23:44 +0800, Hsia-Jun Li a écrit :
On 8/19/22 23:28, Nicolas Dufresne wrote:
CAU
On Fri, Aug 19, 2022 at 10:20 PM Matti Vaittinen
wrote:
>
> 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 demon
(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
Use drm managed resource allocation (drmm_universal_plane_alloc()) in
order to get rid of the explicit destroy hook in struct drm_plane_funcs.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/arm/hdlcd_crtc.c | 20 +++-
1 file changed, 7 insertions(+), 13 deletions(-)
diff --
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
Using drm_device->dev_private is deprecated. Since we've switched to
devm_drm_dev_alloc(), struct drm_device is now embedded in struct
hdlcd_drm_private, hence we can use container_of() to get the struct
drm_device instance instead.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/arm/hdlcd_c
(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
Use drmm_crtc_init_with_planes() instead of drm_crtc_init_with_planes()
to get rid of the explicit drm_crtc_cleanup() call.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/arm/hdlcd_crtc.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/arm/hdlcd_crtc
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 (7):
drm/arm/hdlcd: use drmm_* to allocate driver structures
drm/arm/hdlcd: replace drm->d
From: Vitaly Lubart
Command to be sent via the stream interface are written to a local
memory page, whose address is then provided to the GSC.
The interface supports providing a full sg with multiple pages for both
input and output messages, but since for now we only aim to support short
and sync
The fw name is different and we need to record the fact that the blob is
gsc-loaded, so add a new macro to help.
Note: A-step DG2 G10 does not support HuC loading via GSC and would
require a separate firmware to be loaded the legacy way, but that's
not a production stepping so we're not going to b
Wait on the fence to be signalled to avoid the submissions finding HuC
not yet loaded.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Tony Ye
Reviewed-by: Alan Previn
---
drivers/gpu/drm/i915/gt/uc/intel_huc.h | 6 ++
drivers/gpu/drm/i915/i915_request.c| 24
2 file
Both are required for HuC loading.
Signed-off-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/Kconfig.debug | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/Kconfig.debug
b/drivers/gpu/drm/i915/Kconfig.debug
index e7fd3e76f8a2..a6576ffbc4dc 100644
--- a/drivers/gpu
The current HuC status getparam return values are a bit confusing in
regards to what happens in some scenarios. In particular, most of the
error cases cause the ioctl to return an error, but a couple of them,
INIT_FAIL and LOAD_FAIL, are not explicitly handled and neither is
their expected return v
Given that HuC load is delayed on DG2, this patch adds support for a fence
that can be used to wait for load completion. No waiters are added in this
patch (they're coming up in the next one), to keep the focus of the
patch on the tracking logic.
The full HuC loading flow on boot DG2 is as follows
From: Vitaly Lubart
Add mei bus API for sending gsc commands: mei_cldev_send_gsc_command()
The GSC commands are originated in the graphics stack
and are in form of SGL DMA buffers.
The GSC commands are synchronous, the response is received
in the same call on the out sg list buffers.
The functio
The GSC will perform both the load and teh authentication, so we just
need to check the auth bit after the GSC has replied.
Since we require the PXP module to load the HuC, the earliest we can
trigger the load is during the pxp_bind operation.
Note that GSC-loaded HuC survives GT reset, so we need
This is a squash of the GSC support for XeHP SDV and DG2 series, which
is being reviewed separately at:
https://patchwork.freedesktop.org/series/106638/
Signed-off-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/intel_gsc.c | 118 +---
drivers/gpu/drm/i915/gt/intel
From: Tomas Winkler
Add support for loading HuC via a pxp stream command.
Signed-off-by: Tomas Winkler
Signed-off-by: Vitaly Lubart
Signed-off-by: Daniele Ceraolo Spurio
Cc: Alan Previn
Reviewed-by: Alan Previn
---
drivers/gpu/drm/i915/Makefile | 3 +-
drivers/gpu/drm/i915
From: Tomas Winkler
With on-boards graphics card, both i915 and MEI
are in the same device hierarchy with the same parent,
while for discrete gfx card the MEI is its child device.
Adjust the match function for that scenario
by matching MEI parent device with i915.
V2:
1. More detailed commit me
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
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:
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: 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
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
(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
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
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
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
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-
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
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 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
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 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 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: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
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: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
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: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
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-
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
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
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 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
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 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
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
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
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
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
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
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
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
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 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)
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
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
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 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
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(
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
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
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
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 -
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
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.
> >
>
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
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
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 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!
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
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,
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
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
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
.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 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,
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
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
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
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
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
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: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, 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 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 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
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
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-
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
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
(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
1 - 100 of 122 matches
Mail list logo