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=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 t
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 adde
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(&mgr->lock);
+ r = drm_buddy_alloc(mm, (uin
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 memory
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.
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 rat
https://bugzilla.kernel.org/show_bug.cgi?id=214921
spassw...@web.de changed:
What|Removed |Added
Regression|No |Yes
--- Comment #1 from spassw...@web.
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
BUG_ON
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 LP85
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 Jia
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
> > struct
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 hard
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
> > > @@ -4966,
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
+ spin_lock(&mgr->
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 Mi
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
Signed-off-by
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 fo
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 k
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 problem
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 aft
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
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 perform
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 b/
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 insertion(+)
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 po
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
1
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.
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():
>
> d
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 del
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 handl
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 behin
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 th
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 '--bas
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.
+ 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 the
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 n
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 pat
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 warning
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 #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 sure
https://bugzilla.kernel.org/show_bug.cgi?id=214621
--- Comment #16 from Alex Deucher (alexdeuc...@gmail.com) ---
(In reply to Lang Yu from comment #15)
> Many thanks for your help! I made a test patch to find who pinned amdgpu
> dmabuf.
Did you forget to attach it?
--
You may reply to this emai
https://bugzilla.kernel.org/show_bug.cgi?id=214621
--- Comment #17 from Lang Yu (lang...@amd.com) ---
Created attachment 299441
--> https://bugzilla.kernel.org/attachment.cgi?id=299441&action=edit
test patch to find who pinned amdgpu dmabuf
dmesg may be too large, please add log_buf_len=1024M i
Hi Joonas and Christoph:
We were testing the patch series since Monday and planning to reply after we
get the test result. Mostly, we are concerned about patch 6 and how it would
affect the test result. Patch 6 changes the timing of loading GVT-g. According
to the discussion in the last email,
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:
> > > > --- a/driver
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 them
There is a lot of historical baggage on this parameter. It is defined in
the vgacon driver as nomodeset, but its set function is called text_mode()
and the value queried with a function named vgacon_text_force().
All this implies that it's about forcing text mode for VGA, yet it is not
used in nei
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 may be other conditions besides this to determine if a
driver s
The "nomodeset" kernel cmdline parameter is handled by the vgacon driver
but the exported vgacon_text_force() symbol is only used by DRM drivers.
It makes much more sense for the parameter logic to be in the subsystem
of the drivers that are making use of it.
Let's move the vgacon_text_force() fu
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 useca
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 e2809c7db818df6bbd0edf843e1beb2fbc
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 dri
+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 referen
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: Mark
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 |degamma_lut_
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 amdgpu_dm_v
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 a
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 lin
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
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 functi
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
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 sh
Hi Javier,
>
> >>>
> >>> - if (vgacon_text_force() && i915_modparams.modeset == -1)
> >>> + ret = drm_drv_enabled(&driver);
> >>
> >> 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 ment
On Thu, 04 Nov 2021, Sam Ravnborg wrote:
> Hi Javier,
>
>>
>> >>>
>> >>> -if (vgacon_text_force() && i915_modparams.modeset == -1)
>> >>> +ret = drm_drv_enabled(&driver);
>> >>
>> >> You pass the local driver variable here - which looks wrong as this is
>> >> not the same as the
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 is
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:
Stuff
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 |degamma_lut_
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 amdgpu_dm_v
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
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
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 i
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
b/drivers/gpu/drm/msm/
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
> d
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
> ---
> drivers/gpu/drm/mediatek
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(-)
Rev
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
> la
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
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
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
- update
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:
https:
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:
https://patchwork.freedesktop.org/patch/ms
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 to
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 m
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:
https://patchwork.freedesktop.org/patch/msgid/20210913175747.47456-7-s..
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 fully
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:
https://patchwork.freede
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:
https://
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: Ste
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:
https://patchwork.freedesktop.org/patch/msgid/202109131
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 are
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:
https://patch
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:
https://patchwork.freedesktop.
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
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 Pre-
1 - 100 of 105 matches
Mail list logo
