Hello Jani,
On 11/4/21 20:57, Jani Nikula wrote:
> On Thu, 04 Nov 2021, Javier Martinez Canillas wrote:
>> +/**
>> + * drm_drv_enabled - Checks if a DRM driver can be enabled
>> + * @driver: DRM driver to check
>> + *
>> + * Checks whether a DRM driver can be enabled or not. This may be the case
Hi Javier,
On Thu, Nov 04, 2021 at 05:07:06PM +0100, Javier Martinez Canillas wrote:
> Some DRM drivers check the vgacon_text_force() function return value as an
> indication on whether they should be allowed to be enabled or not.
>
> This function returns true if the nomodeset kernel command
On Thu, 04 Nov 2021, Mark Yacoub wrote:
> From: Mark Yacoub
>
> [Why]
> The tests of LUT_EQUAL_CHANNELS and LUT_NON_DECREASING are currently
> unique to i915 driver.
> Freeing up the function name for the more generic LUT checks to folllow
>
> Tested on Eldrid ChromeOS (TGL).
>
> v1:
> Stuff the
From: Rob Clark
Reported-by: Douglas Anderson
Fixes: 9bc95570175a ("drm/msm: Devfreq tuning")
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gpu_devfreq.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gpu_devfreq.c
On Thu, 04 Nov 2021, Javier Martinez Canillas wrote:
> +/**
> + * drm_drv_enabled - Checks if a DRM driver can be enabled
> + * @driver: DRM driver to check
> + *
> + * Checks whether a DRM driver can be enabled or not. This may be the case
> + * if the "nomodeset" kernel command line parameter
On Thu, 04 Nov 2021, Sam Ravnborg wrote:
> Hi Javier,
>
>>
>> >>>
>> >>> -if (vgacon_text_force() && i915_modparams.modeset == -1)
>> >>> +ret = drm_drv_enabled();
>> >>
>> >> You pass the local driver variable here - which looks wrong as this is
>> >> not the same as the
From: Mark Yacoub
[Why]
drm_atomic_helper_check_crtc now verifies both legacy and non-legacy LUT
sizes. There is no need to check it within amdgpu_dm_atomic_check.
[How]
Remove the local call to verify LUT sizes and use DRM Core function
instead.
Tested on ChromeOS Zork.
v1:
Remove
From: Mark Yacoub
[Why]
1. drm_atomic_helper_check doesn't check for the LUT sizes of either Gamma
or Degamma props in the new CRTC state, allowing any invalid size to
be passed on.
2. Each driver has its own LUT size, which could also be different for
legacy users.
[How]
1. Create
From: Mark Yacoub
[Why]
The tests of LUT_EQUAL_CHANNELS and LUT_NON_DECREASING are currently
unique to i915 driver.
Freeing up the function name for the more generic LUT checks to folllow
Tested on Eldrid ChromeOS (TGL).
v2:
1. Convert the enum to #define.
2. Add INTEL_COLOR_ prefix.
v1:
When virgl is not enabled, vfpriv pointer would not be allocated.
Therefore, check for a valid value before dereferencing.
Reported-by: Christian Zigotzky
Cc: Gurchetan Singh
Cc: Gerd Hoffmann
Signed-off-by: Vivek Kasireddy
---
drivers/gpu/drm/virtio/virtgpu_drv.c | 3 ++-
1 file changed, 2
On Thu, 04 Nov 2021, Sam Ravnborg wrote:
> Hi Javier,
>
> On Thu, Nov 04, 2021 at 05:07:06PM +0100, Javier Martinez Canillas wrote:
>> Some DRM drivers check the vgacon_text_force() function return value as an
>> indication on whether they should be allowed to be enabled or not.
>>
>> This
Hello Sam,
On 11/4/21 18:57, Jani Nikula wrote:
> On Thu, 04 Nov 2021, Sam Ravnborg wrote:
>> Hi Javier,
>>
>> On Thu, Nov 04, 2021 at 05:07:06PM +0100, Javier Martinez Canillas wrote:
>>> Some DRM drivers check the vgacon_text_force() function return value as an
>>> indication on whether they
From: Sean Paul
Now that all of the HDCP 1.x logic has been migrated to the central HDCP
helpers, use it in the i915 driver.
The majority of the driver code for HDCP 1.x will live in intel_hdcp.c,
however there are a few helper hooks which are connector-specific and
need to be partially or
From: Sean Paul
This patch expands upon the HDCP helper library to manage HDCP
enable, disable, and check.
Previous to this patch, the majority of the state management and sink
interaction is tucked inside the Intel driver with the understanding
that once a new platform supported HDCP we could
From: Sean Paul
Just me with another revision of HDCP support for msm.
This v4 patch series is mostly a retread of v3 with the following
changes:
- rebased on Bjorn's displayport-controller register refactor
- another change to the dt bindings to remove the compatible string added in v3
-
From: Sean Paul
This patch moves the hdcp atomic check from i915 to drm_hdcp so other
drivers can use it. No functional changes, just cleaned up some of the
code when moving it over.
Acked-by: Jani Nikula
Acked-by: Jani Nikula
Reviewed-by: Abhinav Kumar
Signed-off-by: Sean Paul
Link:
From: Sean Paul
Instead of forcing a modeset in the hdcp atomic check, simply return
true if the content protection value is changing and let the driver
decide whether a modeset is required or not.
Acked-by: Jani Nikula
Signed-off-by: Sean Paul
Link:
From: Sean Paul
Stick all of the setup for HDCP into a dedicated function. No functional
change, but this will facilitate moving HDCP logic into helpers.
Acked-by: Jani Nikula
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20210913175747.47456-6-s...@poorly.run
From: Sean Paul
The shim functions return error codes, but they are discarded in
intel_hdcp.c. This patch plumbs the return codes through so they are
properly handled.
Acked-by: Jani Nikula
Signed-off-by: Sean Paul
Link:
From: Sean Paul
Make includes alphabetical in dpu_kms.c
Reviewed-by: Abhinav Kumar
Reviewed-by: Stephen Boyd
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20210913175747.47456-9-s...@poorly.run
#v1
Link:
From: Sean Paul
A couple more useless checks to remove in dpu_encoder.
Reviewed-by: Stephen Boyd
Reviewed-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20210913175747.47456-10-s...@poorly.run
#v1
Link:
From: Sean Paul
This patch updates the connector's property value in 2 cases which were
previously missed:
1- Content type changes. The value should revert back to DESIRED from
ENABLED in case the driver must re-authenticate the link due to the
new content type.
2- Userspace sets value
Hi, Nancy:
Nancy.Lin 於 2021年10月29日 週五 下午3:52寫道：
>
> Add plane color encoding information for color space conversion.
> It's a preparation for adding support for mt8195 ovl_adaptor mdp_rdma
> csc control.
Reviewed-by: Chun-Kuang Hu
>
> Signed-off-by: Nancy.Lin
> ---
>
Hi all,
On Thu, 28 Oct 2021 18:27:53 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the char-misc tree got a conflict in:
>
> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>
> between commit:
>
> 5740211ea442 ("drm/i915/dmabuf: fix broken build")
>
> from the drm-intel tree
The basic anx7625 driver only support MIPI DSI rx signal input.
This patch add MIPI DPI rx input configuration support, after apply
this patch, the driver can support DSI rx or DPI rx by adding
'bus-type' in DT.
Reviewed-by: Robert Foss
Signed-off-by: Xin Ji
---
Add audio HDMI codec function support, enable it through device true
flag "analogix,audio-enable".
Reviewed-by: Robert Foss
Signed-off-by: Xin Ji
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 226 ++
drivers/gpu/drm/bridge/analogix/anx7625.h | 5 +
2 files changed, 231
Add 'bus-type' and 'data-lanes' define for port0. Add DP tx lane0,
lane1 swing register setting array, and audio enable flag.
The device which cannot pass DP tx PHY CTS caused by long PCB trace or
embedded MUX, adjusting ANX7625 PHY parameters can pass the CTS test. The
adjusting type include
At some time, the original code may return non zero value, force return 0
if operation finished.
Reviewed-by: Robert Foss
Signed-off-by: Xin Ji
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
On 11/3/2021 5:34 PM, Dmitry Baryshkov wrote:
The "vdd" regulator was used by the mdp5 driver only on downstream
kernels, where the GDSC is represented as a regulator. On all current
kernels the MDSS_GDSC is implemented as the power domain, removing the
need for this regulator. Remove it from
On 11/4/21 5:28 PM, Rob Clark wrote:
From: Rob Clark
Reported-by: Douglas Anderson
Fixes: 9bc95570175a ("drm/msm: Devfreq tuning")
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gpu_devfreq.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Hi,
On Thu, Nov 4, 2021 at 3:23 PM Rob Clark wrote:
>
> From: Rob Clark
>
> Reported-by: Douglas Anderson
> Fixes: 9bc95570175a ("drm/msm: Devfreq tuning")
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/msm_gpu_devfreq.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
From: Sean Paul
This patch adds HDCP 1.x support to msm DP connectors using the new HDCP
helpers.
Cc: Stephen Boyd
Cc: Abhinav Kumar
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20210913175747.47456-15-s...@poorly.run
#v1
Link:
From: Sean Paul
encoder->commit() was being misused because there were some global
resources which needed to be tweaked in encoder->enable() which were not
accessible in dpu_encoder.c. That is no longer true and the redirect
serves no purpose any longer. So remove the indirection.
Tested-by:
From: Sean Paul
Audio is initialized last, it should be de-initialized first to match
the order in dp_init_sub_modules().
Reviewed-by: Abhinav Kumar
Reviewed-by: Stephen Boyd
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Sean Paul
Link:
From: Sean Paul
This patch adds the register ranges required for HDCP key injection and
HDCP TrustZone interaction as described in the dt-bindings for the
sc7180 dp controller. Now that these are supported, change the
compatible string to "dp-hdcp".
Signed-off-by: Sean Paul
Link:
From: Sean Paul
This patch adds the bindings for the MSM DisplayPort HDCP registers
which are required to write the HDCP key into the display controller as
well as the registers to enable HDCP authentication/key
exchange/encryption.
We'll use a new compatible string for this since the fields
On Thu, Nov 04, 2021 at 11:20:21AM +0100, Robert Foss wrote:
> Hey Xin,
>
> Applied to drm-misc-next.
>
> The way this series was submitted to the mailing list is not correct
> and is breaking a lot of tooling. It seems like you used git
> send-email, but the individual patches of the series are
Hi, Nancy:
Nancy.Lin 於 2021年10月29日 週五 下午3:52寫道：
>
> ETHDR is a part of ovl_adaptor.
> ETHDR is designed for HDR video and graphics conversion in the external
> display path. It handles multiple HDR input types and performs tone
> mapping, color space/color format conversion, and then combine
>
Hi, Nancy:
Nancy.Lin 於 2021年10月29日 週五 下午3:52寫道：
>
> 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
>
Remove legacy PWM interface (pwm_config, pwm_enable, pwm_disable) and
replace it for the atomic PWM API.
Signed-off-by: Maíra Canal
---
V1 -> V2: Initialize variable and simplify conditional loop
V2 -> V3: Fix assignment of NULL variable
V3 -> V4: Replace division for pwm_set_relative_duty_cycle
Hi Javier,
>
> >>>
> >>> - if (vgacon_text_force() && i915_modparams.modeset == -1)
> >>> + ret = drm_drv_enabled();
> >>
> >> You pass the local driver variable here - which looks wrong as this is
> >> not the same as the driver variable declared in another file.
> >
>
> Yes, Jani mentioned
On Thu, Nov 4, 2021 at 4:03 PM Mark Yacoub wrote:
>
> From: Mark Yacoub
>
> [Why]
> 1. drm_atomic_helper_check doesn't check for the LUT sizes of either Gamma
> or Degamma props in the new CRTC state, allowing any invalid size to
> be passed on.
> 2. Each driver has its own LUT size, which could
On Thu, 04 Nov 2021, Javier Martinez Canillas wrote:
> Some DRM drivers check the vgacon_text_force() function return value as an
> indication on whether they should be allowed to be enabled or not.
>
> This function returns true if the nomodeset kernel command line parameter
> was set. But there
On 2021-11-04 04:38, Pekka Paalanen wrote:
> On Wed, 3 Nov 2021 11:08:13 -0400
> Harry Wentland wrote:
>
>> On 2021-09-06 17:38, Uma Shankar wrote:
>>> Existing LUT precision structure is having only 16 bit
>>> precision. This is not enough for upcoming enhanced hardwares
>>> and advance
When using Xorg/Logind and an external monitor connected with an MST dock.
After disconnecting the external monitor, switching to VT may not work,
the (internal) monitor sill display Xorg, and you can't see what you are
typing in the VT.
This is related to commit
+Nick
It looks to be the old drm_plane_state->fb holds that reference. See
dm_plane_helper_cleanup_fb() in amdgpu_dm.c.
Harry
On 2021-11-04 08:51, Christian König wrote:
> Hi guys,
>
> adding the usual suspects which might know that of hand: When we do a KMS
> page flip, who keeps the
On 11/4/21 17:24, Jani Nikula wrote:
[snip]
>> index ab2295dd4500..45cb3e540eff 100644
>> --- a/drivers/gpu/drm/i915/i915_module.c
>> +++ b/drivers/gpu/drm/i915/i915_module.c
>> @@ -18,9 +18,12 @@
>> #include "i915_selftest.h"
>> #include "i915_vma.h"
>>
>> +static const struct drm_driver
From: Mark Yacoub
[Why]
The tests of LUT_EQUAL_CHANNELS and LUT_NON_DECREASING are currently
unique to i915 driver.
Freeing up the function name for the more generic LUT checks to folllow
Tested on Eldrid ChromeOS (TGL).
v1:
Stuff the test function from DRM to intel driver.
Signed-off-by:
From: Mark Yacoub
[Why]
1. drm_atomic_helper_check doesn't check for the LUT sizes of either Gamma
or Degamma props in the new CRTC state, allowing any invalid size to
be passed on.
2. Each driver has its own LUT size, which could also be different for
legacy users.
[How]
1. Create
From: Mark Yacoub
[Why]
drm_atomic_helper_check_crtc now verifies both legacy and non-legacy LUT
sizes. There is no need to check it within amdgpu_dm_atomic_check.
[How]
Remove the local call to verify LUT sizes and use DRM Core function
instead.
Tested on ChromeOS Zork.
v1:
Remove
https://bugzilla.kernel.org/show_bug.cgi?id=214859
--- Comment #7 from t...@siduction.org ---
With linux 5.14.17-rc1 and 5.15.1-rc1 the problem is gone.
So i think, that bug is resolved.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the
Am 03.11.21 um 20:25 schrieb Matthew Auld:
On 25/10/2021 14:00, Arunpravin wrote:
- Remove drm_mm references and replace with drm buddy functionalities
- Add res cursor support for drm buddy
Signed-off-by: Arunpravin
+ spin_lock(>lock);
+ r = drm_buddy_alloc(mm,
https://bugzilla.kernel.org/show_bug.cgi?id=214621
--- Comment #8 from Lang Yu (lang...@amd.com) ---
(In reply to Christian König from comment #7)
> Yeah, that won't work. As far as I can see the problem is not inside amdgpu,
> but rather inside the driver which is importing buffers from amdgpu.
Am 03.11.21 um 15:50 schrieb Michel Dänzer:
On 2021-07-23 10:22, Christian König wrote:
Am 23.07.21 um 10:19 schrieb Michel Dänzer:
On 2021-07-23 10:04 a.m., Christian König wrote:
Am 23.07.21 um 09:58 schrieb Michel Dänzer:
From: Michel Dänzer
This makes sure we don't hit the
On Wed, 3 Nov 2021 11:08:13 -0400
Harry Wentland wrote:
> On 2021-09-06 17:38, Uma Shankar wrote:
> > Existing LUT precision structure is having only 16 bit
> > precision. This is not enough for upcoming enhanced hardwares
> > and advance usecases like HDR processing. Hence added a new
> >
Am 04.11.21 um 09:49 schrieb Matthew Auld:
On 04/11/2021 07:34, Christian König wrote:
Am 03.11.21 um 20:25 schrieb Matthew Auld:
On 25/10/2021 14:00, Arunpravin wrote:
- Remove drm_mm references and replace with drm buddy functionalities
- Add res cursor support for drm buddy
On Wed, Nov 03, 2021 at 02:38:05PM -0300, Maíra Canal wrote:
> Remove legacy PWM interface (pwm_config, pwm_enable, pwm_disable) and
> replace it for the atomic PWM API.
>
> Signed-off-by: Maíra Canal
> ---
> V1 -> V2: Initialize variable and simplify conditional loop
> V2 -> V3: Fix assignment
Hi Ville,
On Wed, Nov 03, 2021 at 08:05:16PM +0200, Ville Syrjälä wrote:
> On Wed, Nov 03, 2021 at 01:02:11PM +0200, Ville Syrjälä wrote:
> > On Tue, Nov 02, 2021 at 03:59:32PM +0100, Maxime Ripard wrote:
> > > --- a/drivers/gpu/drm/drm_edid.c
> > > +++ b/drivers/gpu/drm/drm_edid.c
> > > @@
On 04/11/2021 07:34, Christian König wrote:
Am 03.11.21 um 20:25 schrieb Matthew Auld:
On 25/10/2021 14:00, Arunpravin wrote:
- Remove drm_mm references and replace with drm buddy functionalities
- Add res cursor support for drm buddy
Signed-off-by: Arunpravin
+
Hi,
On 11/4/21 00:16, Rajat Jain wrote:
> Hello Hans,
>
> Thanks a lot for working on this diligently and getting almost all of
> it finally merged!
>
> On Wed, Oct 13, 2021 at 2:59 PM Ville Syrjälä
> wrote:
>>
>> On Tue, Oct 05, 2021 at 10:23:22PM +0200, Hans de Goede wrote:
>>> Add support
https://bugzilla.kernel.org/show_bug.cgi?id=214621
--- Comment #7 from Christian König (christian.koe...@amd.com) ---
Yeah, that won't work. As far as I can see the problem is not inside amdgpu,
but rather inside the driver which is importing buffers from amdgpu.
--
You may reply to this email
https://bugzilla.kernel.org/show_bug.cgi?id=214029
--- Comment #27 from Christian König (christian.koe...@amd.com) ---
I've just finished up reading my mails this morning and found a crash report
for this patch when it is back ported to 5.10.
So please do NOT apply this patch to 5.10!
The
On 11/3/21 8:58 AM, Marek Vasut wrote:
>> As we see in the drm_connector_list_iter_next(), it could return
>> NULL. In order to avoid the use of the NULL pointer, it may be
>> better to check the return value.
>>
>> Fixes: c42001e ("drm: mxsfb: Use drm_panel_bridge")
>> Signed-off-by: Jiasheng
John Harrison writes:
> On 11/3/2021 14:38, Jordan Justen wrote:
>> So, i915 wants to wash it's hands completely of the format? There is
>> obviously a difference between hardware features and a blob coming from
>> closed source software. (Which i915 just happens to be passing along.)
>> The
https://bugzilla.kernel.org/show_bug.cgi?id=214029
--- Comment #26 from Christian König (christian.koe...@amd.com) ---
It most likely won't hurt to have the patch in older kernels as well, yes.
The only possibility I can see is that we then have a double free on older
kernels and that would mean
https://bugzilla.kernel.org/show_bug.cgi?id=214921
spassw...@web.de changed:
What|Removed |Added
Regression|No |Yes
--- Comment #1 from
Hi,
On 11/4/21 09:29, Lee Jones wrote:
> On Wed, 03 Nov 2021, Daniel Thompson wrote:
>
>> On Wed, Nov 03, 2021 at 06:28:15PM +0100, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 11/3/21 18:17, Daniel Thompson wrote:
On Tue, Nov 02, 2021 at 11:55:04PM +0100, Hans de Goede wrote:
> The Xiaomi
On Wed, Nov 3, 2021 at 9:58 AM Jason Baron wrote:
>
>
>
> On 10/27/21 12:36 AM, Jim Cromie wrote:
> > Use new macro to create a sysfs control bitmap knob to control
> > print-to-trace in: /sys/module/drm/parameters/trace
> >
> > todo: reconsider this api, ie a single macro expecting both debug &
Hi
Am 03.11.21 um 20:18 schrieb Igor Torrente:
Hi Thomas,
On 11/3/21 12:45 PM, Thomas Zimmermann wrote:
Hi
Am 26.10.21 um 13:34 schrieb Igor Torrente:
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
https://bugzilla.kernel.org/show_bug.cgi?id=214621
--- Comment #9 from Christian König (christian.koe...@amd.com) ---
(In reply to Lang Yu from comment #8)
> (In reply to Christian König from comment #7)
> > Yeah, that won't work. As far as I can see the problem is not inside
> amdgpu,
> > but
On Wed, 03 Nov 2021, Daniel Thompson wrote:
> On Wed, Nov 03, 2021 at 06:28:15PM +0100, Hans de Goede wrote:
> > Hi,
> >
> > On 11/3/21 18:17, Daniel Thompson wrote:
> > > On Tue, Nov 02, 2021 at 11:55:04PM +0100, Hans de Goede wrote:
> > >> The Xiaomi Mi Pad 2 tablet uses an ACPI enumerated
On Mon, 25 Oct 2021 17:28:53 +0200, Maxime Ripard wrote:
> Here is a series that enables the higher resolutions on the HDMI0 Controller
> found in the BCM2711 (RPi4).
>
> In order to work it needs a few adjustments to config.txt, most notably to
> enable the enable_hdmi_4kp60 option.
>
> Let me
Hey Xin,
Applied to drm-misc-next.
The way this series was submitted to the mailing list is not correct
and is breaking a lot of tooling. It seems like you used git
send-email, but the individual patches of the series are not connected
properly and both b4 and the patchwork tools are not able to
As it was done with other bridge drivers and to solve a warning coming
from drm_dp_aux_register(), add a backpointer to drm_device in the
drm_dp_aux that we're registering.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/bridge/parade-ps8640.c | 1 +
1 file changed, 1
If the initial fill blit or copy blit of an object fails, the old
content of the data might be exposed and read as soon as either CPU- or
GPU PTEs are set up to point at the pages.
Intercept the blit fence with an async callback that checks the
blit fence for errors and if there are errors
This patch series introduces failsafe migration blits.
The reason for this seemingly strange concept is that if the initial
clearing or readback of LMEM fails for some reason[1], and we then set up
either GPU- or CPU ptes to the allocated LMEM, we can expose old
contents from other clients.
So
We are about to introduce failsafe- and asynchronous migration and
ttm moves.
This will add complexity and code to the TTM move code so it makes sense
to split it out to a separate file to make the i915 TTM code easer to
digest.
Split the i915 TTM move code out and since we will have to change the
https://bugzilla.kernel.org/show_bug.cgi?id=214621
--- Comment #11 from Christian König (christian.koe...@amd.com) ---
Well it's really appreciated that you are looking into this.
One thing we might want to do is to move the warning in dma_buf_release():
diff --git a/drivers/dma-buf/dma-buf.c
HI Brian,
On Wed, 3 Nov 2021 at 21:52, Brian Norris wrote:
>
> Prior to commit 6c836d965bad ("drm/rockchip: Use the helpers for PSR"),
> "PSR exit" used non-blocking analogix_dp_send_psr_spd(). The refactor
> started using the blocking variant, for a variety of reasons -- quoting
> Sean Paul's
On Wed, 03 Nov 2021, Thomas Zimmermann wrote:
> Hi
>
> Am 03.11.21 um 14:41 schrieb Jani Nikula:
>> On Wed, 03 Nov 2021, Javier Martinez Canillas wrote:
>>> DRM drivers can use this to determine whether they can be enabled or not.
>>>
>>> For now it's just a wrapper around drm_modeset_disabled()
From: Jing Yao
coccicheck complains about the use of snprintf() in sysfs show
functions:
WARNING use scnprintf or sprintf
Use sysfs_emit instead of scnprintf, snprintf or sprintf makes more
sense.
Reported-by: Zeal Robot
Signed-off-by: Jing Yao
---
drivers/video/fbdev/udlfb.c | 8
https://bugzilla.kernel.org/show_bug.cgi?id=214621
--- Comment #10 from Lang Yu (lang...@amd.com) ---
(In reply to Christian König from comment #9)
> (In reply to Lang Yu from comment #8)
> > (In reply to Christian König from comment #7)
> > > Yeah, that won't work. As far as I can see the
Hello Jani,
On 11/4/21 12:10, Jani Nikula wrote:
> On Wed, 03 Nov 2021, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 03.11.21 um 14:41 schrieb Jani Nikula:
>>> On Wed, 03 Nov 2021, Javier Martinez Canillas wrote:
DRM drivers can use this to determine whether they can be enabled or not.
Hi Maksym,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm/drm-next]
[also build test ERROR on next-20211104]
[cannot apply to v5.15]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base
Hi Zhenyu and Zhi,
Can you have somebody from the GVT team to review the patches that
are fully contained in gvt/ ?
I also started discussion on patch 6 which is about defining the
interface between the modules. I remember there is prior work to shrink
the interface. Do you have links to such
Some selftests assume that nothing will attempt to grab these bitlocks
while they are held by the selftests. With GuC, for example, that is
not true because the hanging workloads may cause the GuC code to attempt
to grab them for a global reset, and that may cause it to end up
sleeping on the bit
https://bugzilla.kernel.org/show_bug.cgi?id=214621
--- Comment #14 from Erhard F. (erhar...@mailbox.org) ---
(In reply to Lang Yu from comment #12)
> The warning was just merged into mainline 5.15.0 on Tue Nov 2 16:47:49
> 2021(commit 56d33754481f). Not sure Erhard F.'s build contains this
Width and height need to 64 bytes aligned when setting the format.
Need to make sure all is 64 bytes align when use width and height to
calculate buffer size.
Signed-off-by: Yunfei Dong
Acked-by: Nicolas Dufresne
Tested-by: Steve Cho
---
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.h
mutex_acquire_nest() expects a pointer, pass the pointer.
Fixes: 12235da8c80a1 ("kernel/locking: Add context to ww_mutex_trylock()")
Signed-off-by: Sebastian Andrzej Siewior
---
Not sure why I haven't seen this earlier…
kernel/locking/ww_rt_mutex.c | 2 +-
1 file changed, 1 insertion(+), 1
Quoting Christoph Hellwig (2021-11-02 09:05:34)
> Remove the separately included Makefile and just use the relative
> reference from the main i915 Makefile as for source files in other
> subdirectories.
The thinking behind the split is to avoid any merge conflicts as the
gvt/ subdirectory is
https://bugzilla.kernel.org/show_bug.cgi?id=214621
--- Comment #13 from Christian König (christian.koe...@amd.com) ---
(In reply to Lang Yu from comment #12)
> The warning was just merged into mainline 5.15.0 on Tue Nov 2 16:47:49
> 2021(commit 56d33754481f). Not sure Erhard F.'s build contains
+ Thomas, Maarten and Matt
(Also, Zhi and Zhenyu, please see down)
Quoting Christoph Hellwig (2021-11-02 09:05:38)
> Instead of having an option to build the gvt code into the main i915
> module, just move it into the kvmgt.ko module. This only requires
> a new struct with three entries that
Hi Sam
On Sat, Oct 16, 2021 at 2:27 PM Sam Ravnborg wrote:
>
> Hi Michael,
>
> On Sat, Oct 16, 2021 at 10:22:27AM +, Michael Trimarchi wrote:
> > This patch series add support for W552946ABA panel. This panel is used
> > in px30-evb v11. All the patches can be applied on top of drm-fixes
> >
https://bugzilla.kernel.org/show_bug.cgi?id=214621
--- Comment #12 from Lang Yu (lang...@amd.com) ---
(In reply to Christian König from comment #11)
> Well it's really appreciated that you are looking into this.
>
> One thing we might want to do is to move the warning in dma_buf_release():
>
>
On Thu, Nov 04, 2021 at 02:30:20PM +0200, Joonas Lahtinen wrote:
> Quoting Christoph Hellwig (2021-11-02 09:05:34)
> > Remove the separately included Makefile and just use the relative
> > reference from the main i915 Makefile as for source files in other
> > subdirectories.
>
> The thinking
Hi guys,
adding the usual suspects which might know that of hand: When we do a
KMS page flip, who keeps the reference to the BO while it is scanned out?
We are running into warning backtraces from TTM which look more than odd.
Thanks,
Christian.
https://bugzilla.kernel.org/show_bug.cgi?id=214621
--- Comment #15 from Lang Yu (lang...@amd.com) ---
(In reply to Erhard F. from comment #14)
> (In reply to Lang Yu from comment #12)
> > The warning was just merged into mainline 5.15.0 on Tue Nov 2 16:47:49
> > 2021(commit 56d33754481f). Not
On Tue, Nov 02, 2021 at 03:59:33PM +0100, Maxime Ripard wrote:
> --- a/include/drm/drm_modes.h
> +++ b/include/drm/drm_modes.h
> @@ -424,6 +424,21 @@ static inline bool drm_mode_is_stereo(const struct
> drm_display_mode *mode)
> return mode->flags & DRM_MODE_FLAG_3D_MASK;
> }
>
> +/**
>
On Thu, Nov 04, 2021 at 09:48:41AM +0100, Maxime Ripard wrote:
> Hi Ville,
>
> On Wed, Nov 03, 2021 at 08:05:16PM +0200, Ville Syrjälä wrote:
> > On Wed, Nov 03, 2021 at 01:02:11PM +0200, Ville Syrjälä wrote:
> > > On Tue, Nov 02, 2021 at 03:59:32PM +0100, Maxime Ripard wrote:
> > > > ---
On Thu, Nov 04, 2021 at 01:58:44PM +0100, Thomas Hellström wrote:
> Some selftests assume that nothing will attempt to grab these bitlocks
> while they are held by the selftests. With GuC, for example, that is
> not true because the hanging workloads may cause the GuC code to attempt
> to grab
1 - 100 of 106 matches
Mail list logo
