+ Dave as FYI
Quoting Daniel Vetter (2021-08-10 09:27:25)
> On Mon, Aug 09, 2021 at 09:19:39AM -0700, Matt Roper wrote:
> > On Mon, Aug 09, 2021 at 04:05:59PM +0200, Daniel Vetter wrote:
> > > On Fri, Aug 06, 2021 at 09:36:56AM +0300, Joonas Lahtinen wrote:
> > > > Hi Matt,
> > > >
> > > >
Quoting Laurent Pinchart (2021-06-23 17:03:02)
> To simplify interfacing with the panel, wrap it in a panel-bridge and
> let the DRM bridge helpers handle chaining of operations.
>
> This also prepares for support of DRM_BRIDGE_ATTACH_NO_CONNECTOR, which
> requires all components in the display
Blob resources without the cross device flag don't have a uuid to share
with other virtio devices. When exporting such blobs, set uuid_state to
STATE_ERR so that virtgpu_virtio_get_uuid doesn't hang.
Signed-off-by: David Stevens
---
drivers/gpu/drm/virtio/virtgpu_prime.c | 2 ++
1 file changed,
dim: db47fe727e1f ("drm/i915/step:
s/_revid_tbl/_revids"): committer Signed-off-by
missing.
I'm not sure how much pain it is to fix that up, but
commit db47fe727e1fc516cf60fc9ab8299605ef3c2d54
Author: Anusha Srivatsa
Commit: Matt Roper
drm/i915/step: s/_revid_tbl/_revids
Simplify the
On 2021-08-10 at 16:52:12 -0700, Juston Li wrote:
> On some MST docking stations, rx_info can only be read after
> RepeaterAuth_Send_ReceiverID_List and the RxStatus READY bit is set
> otherwise the read will return -EIO.
>
> This behavior causes the mst stream type1 capability test to fail to
>
On 2021-08-10 at 16:52:11 -0700, Juston Li wrote:
> When reading RepeaterAuth_Send_ReceiverID_List, RxInfo is read by itself
> once to retrieve the DEVICE_COUNT to calculate the size of the
> ReceiverID list then read a second time as a part of reading ReceiverID
> list.
>
> On some MST docking
On 2021-08-10 at 16:52:10 -0700, Juston Li wrote:
> Update cp_irq_count_cached when reading messages rather than when
> writing a message to make sure the value is up to date and not
> stale from a previously handled CP_IRQ.
>
> AKE flow doesn't always respond to a read with a ACK write msg.
>
add support for mediatek SOC MT8192
Signed-off-by: Yongqiang Niu
Signed-off-by: Hsin-Yi Wang
Reviewed-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_disp_ccorr.c | 6 +
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 20 +++
drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 6 +
This patch add component POSTMASK.
Signed-off-by: Yongqiang Niu
Signed-off-by: Hsin-Yi Wang
Reviewed-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 102
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 +
2 files changed, 73 insertions(+), 30
Add mtk mutex support for MT8192 SoC.
Signed-off-by: Yongqiang Niu
Signed-off-by: Hsin-Yi Wang
Reviewed-by: CK Hu
---
drivers/soc/mediatek/mtk-mutex.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/drivers/soc/mediatek/mtk-mutex.c
This patch add component RDMA4
Signed-off-by: Yongqiang Niu
Reviewed-by: Chun-Kuang Hu
Signed-off-by: Hsin-Yi Wang
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
Change since v8:
rebase Linux v5.14-rc1
Yongqiang Niu (5):
drm/mediatek: add component OVL_2L2
drm/mediatek: add component POSTMASK
drm/mediatek: add component RDMA4
soc: mediatek: add mtk mutex support for MT8192
drm/mediatek: add support for mediatek SOC MT8192
This patch add component OVL_2L2
Signed-off-by: Yongqiang Niu
Reviewed-by: Chun-Kuang Hu
Signed-off-by: Hsin-Yi Wang
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
Change since v3:
- remove useless condition check
Yongqiang Niu (1):
drm/mediatek: clear pending flag when cmdq packet is done.
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 47 +
1 file changed, 42 insertions(+), 5 deletions(-)
--
1.8.1.1.dirty
In cmdq mode, packet may be flushed before it is executed, so
the pending flag should be cleared after cmdq packet is done.
Signed-off-by: Yongqiang Niu
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 47 +
1 file changed, 42 insertions(+), 5 deletions(-)
diff
When unblocking a context, do not enable scheduling if the context is
banned.
Fixes: 62eaf0ae217d ("drm/i915/guc: Support request cancellation")
Signed-off-by: Matthew Brost
Cc:
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 1 +
1 file changed, 1 insertion(+)
diff --git
Flush the work queue for GuC generated G2H messages durinr a GT reset.
This is accomplished by spinning on the the list of outstanding G2H to
go empty.
Fixes: eb5e7da736f3 ("drm/i915/guc: Reset implementation for new GuC interface")
Signed-off-by: Matthew Brost
Cc:
---
Do not clear enable during a context reset if a schedule enable is in
flight. This can occur if the context reset during a request
cancellation, clears the offending request, and then enables scheduling.
Fixes: 62eaf0ae217d ("drm/i915/guc: Support request cancellation")
Signed-off-by: Matthew
GuC submission has exposed an existing memory corruption in
live_lrc_isolation. We believe that some writes to the watchdog offsets
in the LRC (0x178 & 0x17c) can result in trashing of portions of the
address space. With GuC submission there are additional objects which
can move the context
While debugging an issue with full GT resets I went down a rabbit hole
thinking the scrubbing of lost G2H wasn't working correctly. This proved
to be incorrect as this was working just fine but this chase inspired me
to write a selftest to prove that this works. This simple selftest
injects errors
When unwinding requests on a reset context, if other requests in the
context are in the priority list the requests could be resubmitted out
of seqno order. Traverse the list of active requests in reverse and
append to the head of the priority list to fix this.
Fixes: eb5e7da736f3 ("drm/i915/guc:
Resets are notoriously hard to get fully working and notoriously racey,
especially with selftests / IGTs that do all sorts of wild things that
would be near impossible to hit during normal use cases. Even though
likely impossible to hit, anything selftests / IGTs uncover needs to be
fixed. This
Prior to this patch the blocked context counter was cleared on
init_sched_state (used during registering a context & resets) which is
incorrect. This state needs to be persistent or the counter can read the
incorrect value resulting in scheduling never getting enabled again.
Fixes: 62eaf0ae217d
A small race that could result in incorrect accounting of the number
of outstanding G2H. Basically prior to this patch we did not increment
the number of outstanding G2H if we encoutered a GT reset while sending
a H2G. This was incorrect as the context state had already been updated
to anticipate
Don't drop ce->guc_active.lock when unwinding a context after reset.
At one point we had to drop this because of a lock inversion but that is
no longer the case. It is much safer to hold the lock so let's do that.
Fixes: eb5e7da736f3 ("drm/i915/guc: Reset implementation for new GuC interface")
On 2021-08-05 10:08, Dmitry Baryshkov wrote:
Unlike previous generations, 7nm PHYs are required to collaborate with
the host for conitnuos clock mode. Add changes neccessary to enable
/continuous
/necessary
continuous clock mode in the 7nm DSI PHYs.
Signed-off-by: Dmitry Baryshkov
---
On some MST docking stations, rx_info can only be read after
RepeaterAuth_Send_ReceiverID_List and the RxStatus READY bit is set
otherwise the read will return -EIO.
This behavior causes the mst stream type1 capability test to fail to
read rx_info and determine if the topology supports type1 and
When reading RepeaterAuth_Send_ReceiverID_List, RxInfo is read by itself
once to retrieve the DEVICE_COUNT to calculate the size of the
ReceiverID list then read a second time as a part of reading ReceiverID
list.
On some MST docking stations, RxInfo can only be read after the RxStatus
READY bit
Update cp_irq_count_cached when reading messages rather than when
writing a message to make sure the value is up to date and not
stale from a previously handled CP_IRQ.
AKE flow doesn't always respond to a read with a ACK write msg.
E.g. AKE_Send_Pairing_Info will "timeout" because we received
a
Fixes to get HDCP2.2 over MST working on MST docking stations with
certain behaviors that cause the current flow to fail.
Tested with Dell WD-19 and Lenovo ThinkPad USB Type-C Dock Gen 2.
These fixes should make the flow more robust to handle behaviors that as
far as I can tell are unclear in the
On Tue, Aug 10, 2021 at 7:11 PM Heiko Stübner wrote:
>
> Hi Peter,
>
> Am Mittwoch, 11. August 2021, 00:31:24 CEST schrieb Peter Geis:
> > Good Evening,
> >
> > I've been attempting to light off the feiyang fy07024di26a30d panel on
> > the rockpro64. This is the official panel from the Pine64
Hi Marijn
Thanks for reviewing and testing the latest patchset.
On 2021-08-10 15:59, Marijn Suijten wrote:
Hi Abhinav,
On 7/16/21 2:01 AM, abhin...@codeaurora.org wrote:
Hi Marijn
Sorry for the late response.
Apologies from my side as well.
[...]
+static void
Hi Peter,
Am Mittwoch, 11. August 2021, 00:31:24 CEST schrieb Peter Geis:
> Good Evening,
>
> I've been attempting to light off the feiyang fy07024di26a30d panel on
> the rockpro64. This is the official panel from the Pine64 store.
> I've confirmed it works with the downstream kernel on both the
Hi Abhinav,
On 7/22/21 4:50 AM, Abhinav Kumar wrote:
During board bringups its useful to have a DSI test pattern
generator to isolate a DPU vs a DSI issue and focus on the relevant
hardware block.
To facilitate this, add an API which triggers the DSI controller
test pattern. The expected
Hi Abhinav,
On 7/16/21 2:01 AM, abhin...@codeaurora.org wrote:
Hi Marijn
Sorry for the late response.
Apologies from my side as well.
[...]
+static void msm_dsi_host_cmd_test_pattern_setup(struct msm_dsi_host
*msm_host)
+{
+ u32 reg;
+
+ reg = dsi_read(msm_host,
Good Evening,
I've been attempting to light off the feiyang fy07024di26a30d panel on
the rockpro64. This is the official panel from the Pine64 store.
I've confirmed it works with the downstream kernel on both the rk3399
and rk3566, but on the mainline driver the display is partially
corrupted
In 69de4421bb4c ("drm/ttm: Initialize debugfs from
ttm_global_init()"), ttm_global_init was changed so that if creation
of the debugfs global root directory fails, ttm_global_init will bail
out early and return an error, leading to initialization failure of
DRM drivers. However, not every system
After trying out kernel v5.14-rc5 on my system, I no longer get any
display output. Checking dmesg, I found it's because my DRM driver
(nouveau) is failing at ttm_device_init. That is failing because of a
behavior change in ttm_global_init with respect to debugfs. debugfs is
disabled on my system,
On some MST docking stations, rx_info can only be read after
RepeaterAuth_Send_ReceiverID_List and the RxStatus READY bit is set
otherwise the read will return -EIO.
This behavior causes the mst stream type1 capability test to fail to
read rx_info and determine if the topology supports type1 and
When reading RepeaterAuth_Send_ReceiverID_List, RxInfo is read by itself
once to retrieve the DEVICE_COUNT to calculate the size of the
ReceiverID list then read a second time as a part of reading ReceiverID
list.
On some MST docking stations, RxInfo can only be read after the RxStatus
READY bit
Update cp_irq_count_cached when reading messages rather than when
writing a message to make sure the value is up to date and not
stale from a previously handled CP_IRQ.
AKE flow doesn't always respond to a read with a ACK write msg.
E.g. AKE_Send_Pairing_Info will "timeout" because we received
a
Fixes to get HDCP2.2 over MST working on MST docking stations with
certain behaviors that cause the current flow to fail.
Tested with Dell WD-19 and Lenovo ThinkPad USB Type-C Dock Gen 2.
These fixes should make the flow more robust to handle behaviors that as
far as I can tell are unclear in the
From: Juston Li
Date: Mon, 9 Aug 2021 12:55:06 -0700
Subject: [Intel-gfx] [PATCH 3/3] drm/i915/hdcp: reuse rx_info for mst stream
type1 capability check
On some MST docking stations, rx_info can only be read after
RepeaterAuth_Send_ReceiverID_List and the RxStatus READY bit is set
otherwise the
When reading RepeaterAuth_Send_ReceiverID_List, RxInfo is read by itself
once to retrieve the DEVICE_COUNT to calculate the size of the
ReceiverID list then read a second time as a part of reading ReceiverID
list.
On some MST docking stations, RxInfo can only be read after the RxStatus
READY bit
Update cp_irq_count_cached when reading messages rather than when
writing a message to make sure the value is up to date and not
stale from a previously handled CP_IRQ.
AKE flow doesn't always respond to a read with a ACK write msg.
E.g. AKE_Send_Pairing_Info will "timeout" because we received
a
Fixes to get HDCP2.2 over MST working on MST docking stations with
certain behaviors that cause the current flow to fail.
Tested with Dell WD-19 and Lenovo ThinkPad USB Type-C Dock Gen 2.
These fixes should make the flow more robust to handle behaviors that as
far as I can tell are unclear in the
Hi Paul,
[...]
Encoders:
id crtctypepossible crtcs possible clones
34 32 DPI 0x0001 0x0001
Connectors:
id encoder status namesize (mm) modes
encoders
35 34 connected HDMI-A-1340x270 17
Quoting Kuogee Hsieh (2021-08-05 13:44:49)
> add fixes to pass DP Link Layer compliance test cases
>
> Kuogee Hsieh (6):
> drm/msm/dp: use dp_ctrl_off_link_stream during PHY compliance test run
> drm/msm/dp: reduce link rate if failed at link training 1
> drm/msm/dp: reset aux controller
Quoting Kuogee Hsieh (2021-08-05 13:44:55)
> Initialize both pre-emphasis and voltage swing level to 0 before
> start link training and do not end link training until video is
> ready to reduce the period between end of link training and video
> start to meet Link Layer CTS requirement. Some
Quoting Kuogee Hsieh (2021-08-05 13:44:54)
> Response with correct edid checksum saved at connector after corrupted edid
> checksum read. This fixes Link Layer CTS cases 4.2.2.3, 4.2.2.6.
>
> Signed-off-by: Kuogee Hsieh
> ---
Reviewed-by: Stephen Boyd
Quoting Kuogee Hsieh (2021-08-05 13:44:53)
> Remove special handling of replug interrupt and instead treat replug event
> as a sequential unplug followed by a plugin event. This is needed to meet
> the requirements of DP Link Layer CTS test case 4.2.1.3.
>
> Changes in V2:
> -- add fixes statement
Quoting Kuogee Hsieh (2021-08-05 13:44:51)
> Reduce link rate and re start link training if link training 1
> failed due to loss of clock recovery done to fix Link Layer
> CTS case 4.3.1.7. Also only update voltage and pre-emphasis
> swing level after link training started to fix Link Layer CTS
>
On Tue, Aug 10, 2021 at 08:43:50AM +0200, Daniel Vetter wrote:
> On Mon, Aug 09, 2021 at 06:11:37PM +, Matthew Brost wrote:
> > On Mon, Aug 09, 2021 at 04:23:42PM +0200, Daniel Vetter wrote:
> > > On Tue, Aug 03, 2021 at 03:29:07PM -0700, Matthew Brost wrote:
> > > > Taking a PM reference to
On Tuesday, 10 August 2021 09:52:36 CEST Paul Cercueil wrote:
>
> Le mar., août 10 2021 at 01:17:20 +0200, Paul Boddie a
écrit :
> >
> > But then the reported error occurs in the DRM driver:
> >
> > ingenic-drm 1305.lcdc0: Unable to init connector
> > ingenic-drm: probe of 1305.lcdc0
On Wed, 2021-08-04 at 07:13 +, Lin, Wayne wrote:
> [Public]
>
> > -Original Message-
> > From: Lyude Paul
> > Sent: Wednesday, August 4, 2021 8:09 AM
> > To: Lin, Wayne ; dri-devel@lists.freedesktop.org
> > Cc: Kazlauskas, Nicholas ; Wentland, Harry <
> > harry.wentl...@amd.com>;
On 8/10/21 12:48 PM, Tom Lendacky wrote:
On 8/10/21 1:45 PM, Kuppuswamy, Sathyanarayanan wrote:
On 7/27/21 3:26 PM, Tom Lendacky wrote:
diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index de01903c3735..cafed6456d45 100644
--- a/arch/x86/kernel/head64.c
+++
On 8/10/21 1:45 PM, Kuppuswamy, Sathyanarayanan wrote:
>
>
> On 7/27/21 3:26 PM, Tom Lendacky wrote:
>> diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
>> index de01903c3735..cafed6456d45 100644
>> --- a/arch/x86/kernel/head64.c
>> +++ b/arch/x86/kernel/head64.c
>> @@ -19,7
On 2021-08-10 12:23, Stephen Boyd wrote:
Quoting khs...@codeaurora.org (2021-08-10 12:18:02)
On 2021-08-10 11:33, Stephen Boyd wrote:
> Quoting Kuogee Hsieh (2021-08-10 08:29:22)
>> Changes in V2:
>> -- correct Fixes text
>> -- drop commit text
>>
>> Fixes: 601f0479c583 ("drm/msm/dp: add logs
Quoting khs...@codeaurora.org (2021-08-10 12:18:02)
> On 2021-08-10 11:33, Stephen Boyd wrote:
> > Quoting Kuogee Hsieh (2021-08-10 08:29:22)
> >> Changes in V2:
> >> -- correct Fixes text
> >> -- drop commit text
> >>
> >> Fixes: 601f0479c583 ("drm/msm/dp: add logs across DP driver for ease
> >>
On 2021-08-10 11:33, Stephen Boyd wrote:
Quoting Kuogee Hsieh (2021-08-10 08:29:22)
Changes in V2:
-- correct Fixes text
-- drop commit text
Fixes: 601f0479c583 ("drm/msm/dp: add logs across DP driver for ease
of debugging")
Signed-off-by: Kuogee Hsieh
---
On 7/27/21 3:26 PM, Tom Lendacky wrote:
diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index de01903c3735..cafed6456d45 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -19,7 +19,7 @@
#include
#include
#include
-#include
+#include
#include
https://bugzilla.kernel.org/show_bug.cgi?id=214029
--- Comment #2 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 298269
--> https://bugzilla.kernel.org/attachment.cgi?id=298269=edit
kernel .config (kernel 5.14-rc5, AMD FX-8370)
--
You may reply to this email to add a comment.
https://bugzilla.kernel.org/show_bug.cgi?id=214029
--- Comment #1 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 298267
--> https://bugzilla.kernel.org/attachment.cgi?id=298267=edit
output of kmemleak (kernel 5.14-rc5, AMD FX-8370)
--
You may reply to this email to add a
https://bugzilla.kernel.org/show_bug.cgi?id=214029
Bug ID: 214029
Summary: [NAVI] Several memory leaks in amdgpu and ttm
Product: Drivers
Version: 2.5
Kernel Version: 5.14-rc5
Hardware: All
OS: Linux
Tree:
Quoting Kuogee Hsieh (2021-08-10 08:29:22)
> Changes in V2:
> -- correct Fixes text
> -- drop commit text
>
> Fixes: 601f0479c583 ("drm/msm/dp: add logs across DP driver for ease of
> debugging")
> Signed-off-by: Kuogee Hsieh
> ---
> drivers/gpu/drm/msm/dp/dp_display.c | 13 +
> 1
Quoting Kuogee Hsieh (2021-08-10 08:29:22)
> Changes in V2:
> -- correct Fixes text
> -- drop commit text
>
> Fixes: 601f0479c583 ("drm/msm/dp: add logs across DP driver for ease of
> debugging")
> Signed-off-by: Kuogee Hsieh
> ---
Reviewed-by: Stephen Boyd
From: Randy Dunlap
commit 5706cb3c910cc8283f344bc37a889a8d523a2c6d upstream.
'pm_suspend_target_state' is only available when CONFIG_PM_SLEEP
is set/enabled. OTOH, when both SUSPEND and HIBERNATION are not set,
PM_SLEEP is not set, so this variable cannot be used.
From: Randy Dunlap
[ Upstream commit a07296453bf2778952a09b6244a695bf7607babb ]
Fix modpost Section mismatch error in i915_globals_exit().
Since both an __init function and an __exit function can call
i915_globals_exit(), any function that i915_globals_exit() calls
should not be marked as
On Tue, Aug 10, 2021 at 11:27:31AM +0200, Daniel Vetter wrote:
> On Tue, Aug 10, 2021 at 11:23:39AM +0200, Daniel Vetter wrote:
> > On Mon, Aug 09, 2021 at 07:13:11PM +, Matthew Brost wrote:
> > > On Mon, Aug 09, 2021 at 06:36:44PM +0200, Daniel Vetter wrote:
> > > > On Tue, Aug 03, 2021 at
Hi all
I am on a Raspberry Pi, I want to display fullscreen video and have a
couple of overlay planes to display controls / subtitles etc. The h/w
can certainly do this. I need to be able to do this from a starting
point where X is running.
I can successfully find X's output & crtc and grab
Hi,
could you help to review this patch? This patch has been applied to our devices
which use
INX 2081101qfh032011-53g 1200x1920 video panel and it works well.
thanks.
On Tue, Aug 10, 2021 at 06:50:26PM +0300, Mikko Perttunen wrote:
> On 10.8.2021 18.43, Thierry Reding wrote:
> > On Fri, Aug 06, 2021 at 03:34:48PM +0300, Mikko Perttunen wrote:
> > > Convert the original Host1x bindings to YAML and add new bindings for
> > > NVDEC, now in a more appropriate
On Fri, Aug 06, 2021 at 03:34:50PM +0300, Mikko Perttunen wrote:
> Add support for booting and using NVDEC on Tegra210, Tegra186
> and Tegra194 to the Host1x and TegraDRM drivers. Booting in
> secure mode is not currently supported.
>
> Signed-off-by: Mikko Perttunen
> ---
> v2:
> * Use
Hi Laurent,
On Tue, Aug 10, 2021 at 5:47 PM Geert Uytterhoeven wrote:
> On Thu, May 20, 2021 at 8:51 AM Laurent Pinchart
> wrote:
> > Replace the manual panel handling with usage of the DRM panel bridge
> > helper. This simplifies the driver, and brings support for
> >
On 10.8.2021 18.43, Thierry Reding wrote:
On Fri, Aug 06, 2021 at 03:34:48PM +0300, Mikko Perttunen wrote:
Convert the original Host1x bindings to YAML and add new bindings for
NVDEC, now in a more appropriate location. The old text bindings
for Host1x and engines are still kept at
Hi Laurent,
On Thu, May 20, 2021 at 8:51 AM Laurent Pinchart
wrote:
> Replace the manual panel handling with usage of the DRM panel bridge
> helper. This simplifies the driver, and brings support for
> DRM_BRIDGE_ATTACH_NO_CONNECTOR as an added bonus.
>
> Signed-off-by: Laurent Pinchart
Thanks
On Tue, Aug 10, 2021 at 05:43:26PM +0200, Thierry Reding wrote:
> On Fri, Aug 06, 2021 at 03:34:48PM +0300, Mikko Perttunen wrote:
[...]
> > diff --git
> > a/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvdec.yaml
> >
Hello,
syzbot found the following issue on:
HEAD commit:7999516e20bd Add linux-next specific files for 20210806
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=10f15f8e30
kernel config: https://syzkaller.appspot.com/x/.config?x=2f518e910b029c31
On Fri, Aug 06, 2021 at 03:34:48PM +0300, Mikko Perttunen wrote:
> Convert the original Host1x bindings to YAML and add new bindings for
> NVDEC, now in a more appropriate location. The old text bindings
> for Host1x and engines are still kept at display/tegra/ since they
> encompass a lot more
Changes in V2:
-- correct Fixes text
-- drop commit text
Fixes: 601f0479c583 ("drm/msm/dp: add logs across DP driver for ease of
debugging")
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_display.c | 13 +
1 file changed, 13 insertions(+)
diff --git
On Tue, Aug 10, 2021 at 10:49 PM Alex Deucher wrote:
>
> On Tue, Aug 10, 2021 at 4:36 AM Imre Deak wrote:
> >
> > Hi Kai-Heng, Alex,
> >
> > could you add your ack if the fix looks ok and you're ok if I push it to
> > the i915 tree?
> >
>
> Acked-by: Alex Deucher
Acked-by: Kai-Heng Feng
>
>
We still have quite a bit more work to do with overall reworking of
the ttm-based dg1 code, but the uapi stuff is now finalized with the
latest pull. So remove that.
This also fixes kerneldoc build warnings because we've included the
same headers in two places, resulting in sphinx complaining
On Tue, Aug 10, 2021 at 05:10:56PM +0300, Pavel Skripkin wrote:
> On 8/10/21 4:47 PM, syzbot wrote:
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit:7999516e20bd Add linux-next specific files for 20210806
> > git tree: linux-next
> > console output:
On Tue, Aug 10, 2021 at 4:36 AM Imre Deak wrote:
>
> Hi Kai-Heng, Alex,
>
> could you add your ack if the fix looks ok and you're ok if I push it to
> the i915 tree?
>
Acked-by: Alex Deucher
> Thanks,
> Imre
>
> On Mon, Aug 09, 2021 at 04:31:46PM +0300, Imre Deak wrote:
> > Atm the EFI FB
Acked-by: Jason Ekstrand
On Tue, Aug 10, 2021 at 7:34 AM Daniel Vetter wrote:
>
> We still have quite a bit more work to do with overall reworking of
> the ttm-based dg1 code, but the uapi stuff is now finalized with the
> latest pull. So remove that.
>
> This also fixes kerneldoc build
From: Bing Guo
[ Upstream commit 06050a0f01dbac2ca33145ef19a72041206ea983 ]
Why:
In DCN2x, HW doesn't automatically divide MASTER_UPDATE_LOCK_DB_X
by the number of pipes ODM Combined.
How:
Set MASTER_UPDATE_LOCK_DB_X to the value that is adjusted by the
number of pipes ODM Combined.
From: Qingqing Zhuo
[ Upstream commit c4152b297d56d3696ad0a9003169bc5b98ad7b72 ]
[Why]
HPD disable and enable sequences are not mutually exclusive
on Linux. For HPDs that spans over 1s (i.e. HPD low = 1s),
part of the disable sequence (specifically, a request to SMU
to lower refclk) could come
From: Bing Guo
[ Upstream commit 06050a0f01dbac2ca33145ef19a72041206ea983 ]
Why:
In DCN2x, HW doesn't automatically divide MASTER_UPDATE_LOCK_DB_X
by the number of pipes ODM Combined.
How:
Set MASTER_UPDATE_LOCK_DB_X to the value that is adjusted by the
number of pipes ODM Combined.
From: Yifan Zhang
[ Upstream commit 1c0539a6fc8a4a4b77278e35d763073890de96b9 ]
If GC has entered CGPG, ringing doorbell > first page doesn't wakeup GC.
Enlarge CP_MEC_DOORBELL_RANGE_UPPER to workaround this issue.
Signed-off-by: Yifan Zhang
Reviewed-by: Alex Deucher
Signed-off-by: Alex
From: Qingqing Zhuo
[ Upstream commit c4152b297d56d3696ad0a9003169bc5b98ad7b72 ]
[Why]
HPD disable and enable sequences are not mutually exclusive
on Linux. For HPDs that spans over 1s (i.e. HPD low = 1s),
part of the disable sequence (specifically, a request to SMU
to lower refclk) could come
From: Bing Guo
[ Upstream commit 06050a0f01dbac2ca33145ef19a72041206ea983 ]
Why:
In DCN2x, HW doesn't automatically divide MASTER_UPDATE_LOCK_DB_X
by the number of pipes ODM Combined.
How:
Set MASTER_UPDATE_LOCK_DB_X to the value that is adjusted by the
number of pipes ODM Combined.
From: Yifan Zhang
[ Upstream commit 1c0539a6fc8a4a4b77278e35d763073890de96b9 ]
If GC has entered CGPG, ringing doorbell > first page doesn't wakeup GC.
Enlarge CP_MEC_DOORBELL_RANGE_UPPER to workaround this issue.
Signed-off-by: Yifan Zhang
Reviewed-by: Alex Deucher
Signed-off-by: Alex
On Mon, Aug 9, 2021 at 9:24 PM zhaoxiao wrote:
>
> The variable backlight is being initialized with a value that
> is never read, it is being re-assigned immediately afterwards.
I don't think this comment really matches the code. I think you can drop it.
Alex
> Clean up the code by removing
On 8/10/21 4:47 PM, syzbot wrote:
Hello,
syzbot found the following issue on:
HEAD commit:7999516e20bd Add linux-next specific files for 20210806
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=10f15f8e30
kernel config:
Thanks for your feedback. We will prepare a V2 patch according to your advice.
Best wishes,
Tuo Li
On 2021/8/10 21:38, Chen, Guchun wrote:
[Public]
Thanks for your patch.
I suggest moving the check of function pointer dc->clk_mgr->funcs->get_clock
earlier, and return early if it's NULL, as
Hi Dave & Daniel -
drm-intel-next-2021-08-10-1:
drm/i915 changes for v5.15:
Features:
- Basic DG2 platform enabling (Matt, Animesh, Gwan-gyeong, José)
- Add PSF GV point support for display bandwidth calculation (Stan)
- Add platform release id version support (Lucas)
- Add support for forcing
[Public]
Thanks for your patch.
I suggest moving the check of function pointer dc->clk_mgr->funcs->get_clock
earlier, and return early if it's NULL, as if it's NULL, it's meaningless to
continue the clock setting.
if (!dc->clk_mgr || !dc->clk_mgr->funcs->get_clock)
return
Hi Daniel,
On Tue, 10 Aug 2021 14:39:17 +0200 Daniel Vetter wrote:
>
> On Tue, Aug 10, 2021 at 1:01 PM Stephen Rothwell
> wrote:
> > Hi Daniel,
> >
> > On Tue, 10 Aug 2021 12:50:55 +0200 Daniel Vetter wrote:
> > >
> > > Uh that's not good, I missed that. I'll look into it.
> >
> > Thanks.
This essentially reverts
commit 89ff76bf9b3b0b86e6bbe344bd6378d8661303fc
Author: Chris Wilson
Date: Thu Apr 2 13:42:18 2020 +0100
drm/i915/gem: Utilize rcu iteration of context engines
Note that the other use of __context_engines_await have disappeard in
the following commits:
Hi Geert,
On Tue, 10 Aug 2021 13:56:12 +0200 Geert Uytterhoeven
wrote:
>
> On Fri, Aug 6, 2021 at 6:11 PM Mark Brown wrote:
> > Today's linux-next merge of the drm tree got a conflict in:
> >
> > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> >
> > between commit:
> >
> > e00f543d3596
1 - 100 of 167 matches
Mail list logo
