[syzbot] [fbdev?] general protection fault in soft_cursor
Hello, syzbot found the following issue on: HEAD commit:eb0f1697d729 Merge branch 'for-next/core', remote-tracking.. git tree: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-kernelci console output: https://syzkaller.appspot.com/x/log.txt?x=10e08bde28 kernel config: https://syzkaller.appspot.com/x/.config?x=8860074b9a9d6c45 dashboard link: https://syzkaller.appspot.com/bug?extid=d910bd780e6efac35869 compiler: Debian clang version 15.0.7, GNU ld (GNU Binutils for Debian) 2.35.2 userspace arch: arm64 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=103d17a928 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1151bb1928 Downloadable assets: disk image: https://storage.googleapis.com/syzbot-assets/034232da7cff/disk-eb0f1697.raw.xz vmlinux: https://storage.googleapis.com/syzbot-assets/b11411bec33e/vmlinux-eb0f1697.xz kernel image: https://storage.googleapis.com/syzbot-assets/a53c52e170dd/Image-eb0f1697.gz.xz IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+d910bd780e6efac35...@syzkaller.appspotmail.com == BUG: KASAN: null-ptr-deref in soft_cursor+0x384/0x6b4 drivers/video/fbdev/core/softcursor.c:70 Read of size 16 at addr 0200 by task kworker/u4:1/12 CPU: 0 PID: 12 Comm: kworker/u4:1 Not tainted 6.4.0-rc3-syzkaller-geb0f1697d729 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/28/2023 Workqueue: events_power_efficient fb_flashcursor Call trace: dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:233 show_stack+0x2c/0x44 arch/arm64/kernel/stacktrace.c:240 __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd0/0x124 lib/dump_stack.c:106 print_report+0xe4/0x514 mm/kasan/report.c:465 kasan_report+0xd4/0x130 mm/kasan/report.c:572 kasan_check_range+0x264/0x2a4 mm/kasan/generic.c:187 __asan_memcpy+0x3c/0x84 mm/kasan/shadow.c:105 soft_cursor+0x384/0x6b4 drivers/video/fbdev/core/softcursor.c:70 bit_cursor+0x113c/0x1a64 drivers/video/fbdev/core/bitblit.c:377 fb_flashcursor+0x35c/0x54c drivers/video/fbdev/core/fbcon.c:380 process_one_work+0x788/0x12d4 kernel/workqueue.c:2405 worker_thread+0x8e0/0xfe8 kernel/workqueue.c:2552 kthread+0x288/0x310 kernel/kthread.c:379 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:853 == --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. If the bug is already fixed, let syzbot know by replying with: #syz fix: exact-commit-title If you want syzbot to run the reproducer, reply with: #syz test: git://repo/address.git branch-or-commit-hash If you attach or paste a git patch, syzbot will apply it before testing. If you want to change bug's subsystems, reply with: #syz set subsystems: new-subsystem (See the list of subsystem names on the web dashboard) If the bug is a duplicate of another bug, reply with: #syz dup: exact-subject-of-another-report If you want to undo deduplication, reply with: #syz undup
Re: [PATCH 3/6] drm/i915/uc/gsc: extract release and security versions from the gsc binary
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_meu_headers.h
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_meu_headers.h
index d55a66202576..8bce2b8aed84 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_meu_headers.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_meu_headers.h
alan:snip
+struct intel_gsc_layout_pointers {
+ u8 rom_bypass_vector[16];
alan:snip...
+ u32 temp_pages_offset;
+ u32 temp_pages_size;
+} __packed;
alan: structure layout seems unnecessarily repetitive... why not ->
struct partition_info {
u32 offset;
u32 size;
};
struct intel_gsc_layout_pointers {
u8 rom_bypass_vector[16];
...
struct partition_info datap;
struct partition_info bootregion[5];
struct partition_info trace;
}__packed;
I've just realized that I didn't reply to this comment. The specs have
the structure defined that way, so I tried to keep a 1:1 match like we
usually do. I think switching to a partition_info structure is ok, but
I'll avoid the array because the GSC partition are 1-based, which could
cause confusion (i.e. partition boot1 would be bootregion[0]).
Daniele
Re: (subset) [PATCH 0/4] ARM: dts: qcom: apq8074-dragonboard enable DSI and remoteproc
On Sun, 7 May 2023 22:07:31 +0300, Dmitry Baryshkov wrote: > Enable GPU, DSI panel and remoteprocs on the APQ8074 dragonboard device. > > Dmitry Baryshkov (4): > ARM: dts: qcom: msm8974: add ocmem clock to GPU > ARM: dts: qcom: apq8074-dragonboard: Set DMA as remotely controlled > ARM: dts: qcom: apq8074-dragonboard: enable adsp and MSS > ARM: dts: qcom: apq8074-dragonboard: enable DSI panel > > [...] Applied, thanks! [2/4] ARM: dts: qcom: apq8074-dragonboard: Set DMA as remotely controlled commit: d184f79bd075871e2d16ce1ef739b22dedd3d928 [3/4] ARM: dts: qcom: apq8074-dragonboard: enable adsp and MSS commit: 3a0dda1a2553f97c0c8aebd181cd33e0eee5094d [4/4] ARM: dts: qcom: apq8074-dragonboard: enable DSI panel commit: ac366501f64f83e03a0f6fd21b87188f92ce0e57 Best regards, -- Bjorn Andersson
[PATCH v3 7/7] drm/i915/huc: define HuC FW version for MTL
Follow the same logic as DG2, so just a meu binary with no version number. Signed-off-by: Daniele Ceraolo Spurio Cc: Alan Previn Reviewed-by: John Harrison --- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c index b752a7f1ed99..db7fbce51f8b 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c @@ -108,6 +108,7 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw, fw_def(SKYLAKE, 0, guc_mmp(skl, 70, 1, 1)) #define INTEL_HUC_FIRMWARE_DEFS(fw_def, huc_raw, huc_mmp, huc_gsc) \ + fw_def(METEORLAKE, 0, huc_gsc(mtl)) \ fw_def(DG2, 0, huc_gsc(dg2)) \ fw_def(ALDERLAKE_P, 0, huc_raw(tgl)) \ fw_def(ALDERLAKE_P, 0, huc_mmp(tgl, 7, 9, 3)) \ -- 2.40.0
[PATCH v3 6/7] drm/i915/mtl/huc: Use the media gt for the HuC getparam
On MTL, for obvious reasons, HuC is only available on the media tile. We already disable SW support for HuC on the root gt due to the absence of VCS engines, but we also need to update the getparam to point to the HuC struct in the media GT. Signed-off-by: Daniele Ceraolo Spurio Cc: John Harrison Reviewed-by: John Harrison --- drivers/gpu/drm/i915/i915_getparam.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_getparam.c b/drivers/gpu/drm/i915/i915_getparam.c index 6f11d7eaa91a..890f2b382bee 100644 --- a/drivers/gpu/drm/i915/i915_getparam.c +++ b/drivers/gpu/drm/i915/i915_getparam.c @@ -100,7 +100,11 @@ int i915_getparam_ioctl(struct drm_device *dev, void *data, value = sseu->min_eu_in_pool; break; case I915_PARAM_HUC_STATUS: - value = intel_huc_check_status(_gt(i915)->uc.huc); + /* On platform with a media GT, the HuC is on that GT */ + if (i915->media_gt) + value = intel_huc_check_status(>media_gt->uc.huc); + else + value = intel_huc_check_status(_gt(i915)->uc.huc); if (value < 0) return value; break; -- 2.40.0
[PATCH v3 4/7] drm/i915/huc: differentiate the 2 steps of the MTL HuC auth flow
Before we add the second step of the MTL HuC auth (via GSC), we need to
have the ability to differentiate between them. To do so, the huc
authentication check is duplicated for GuC and GSC auth, with meu
binaries being considered fully authenticated only after the GSC auth
step.
To report the difference between the 2 auth steps, a new case is added
to the HuC getparam. This way, the clear media driver can start
submitting before full auth, as partial auth is enough for those
workloads.
v2: fix authentication status check for DG2
v3: add a better comment at the top of the HuC file to explain the
different approaches to load and auth (John)
Signed-off-by: Daniele Ceraolo Spurio
Cc: Alan Previn
Cc: John Harrison
Reviewed-by: Alan Previn #v2
---
drivers/gpu/drm/i915/gt/uc/intel_huc.c| 111 --
drivers/gpu/drm/i915/gt/uc/intel_huc.h| 16 +++-
drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c | 4 +-
drivers/gpu/drm/i915/i915_reg.h | 3 +
include/uapi/drm/i915_drm.h | 3 +-
5 files changed, 103 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index 37c6a8ca5c71..ab5246ae3979 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -10,6 +10,7 @@
#include "intel_huc.h"
#include "intel_huc_print.h"
#include "i915_drv.h"
+#include "i915_reg.h"
#include
#include
@@ -22,15 +23,23 @@
* capabilities by adding HuC specific commands to batch buffers.
*
* The kernel driver is only responsible for loading the HuC firmware and
- * triggering its security authentication, which is performed by the GuC on
- * older platforms and by the GSC on newer ones. For the GuC to correctly
- * perform the authentication, the HuC binary must be loaded before the GuC
one.
+ * triggering its security authentication. This is done differently depending
+ * on the platform:
+ * - older platforms (from Gen9 to most Gen12s): the load is performed via DMA
+ * and the authentication via GuC
+ * - DG2: load and authentication are both performed via GSC.
+ * - MTL and newer platforms: the load is performed via DMA (same as with
+ * not-DG2 older platforms), while the authentication is done in 2-steps,
+ * a first auth for clear-media workloads via GuC and a second one for all
+ * workloads via GSC.
+ * On platforms where the GuC does the authentication, to correctly do so the
+ * HuC binary must be loaded before the GuC one.
* Loading the HuC is optional; however, not using the HuC might negatively
* impact power usage and/or performance of media workloads, depending on the
* use-cases.
* HuC must be reloaded on events that cause the WOPCM to lose its contents
- * (S3/S4, FLR); GuC-authenticated HuC must also be reloaded on GuC/GT reset,
- * while GSC-managed HuC will survive that.
+ * (S3/S4, FLR); on older platforms the HuC must also be reloaded on GuC/GT
+ * reset, while on newer ones it will survive that.
*
* See https://github.com/intel/media-driver for the latest details on HuC
* functionality.
@@ -106,7 +115,7 @@ static enum hrtimer_restart
huc_delayed_load_timer_callback(struct hrtimer *hrti
{
struct intel_huc *huc = container_of(hrtimer, struct intel_huc,
delayed_load.timer);
- if (!intel_huc_is_authenticated(huc)) {
+ if (!intel_huc_is_authenticated(huc, INTEL_HUC_AUTH_BY_GSC)) {
if (huc->delayed_load.status == INTEL_HUC_WAITING_ON_GSC)
huc_notice(huc, "timed out waiting for MEI GSC\n");
else if (huc->delayed_load.status == INTEL_HUC_WAITING_ON_PXP)
@@ -124,7 +133,7 @@ static void huc_delayed_load_start(struct intel_huc *huc)
{
ktime_t delay;
- GEM_BUG_ON(intel_huc_is_authenticated(huc));
+ GEM_BUG_ON(intel_huc_is_authenticated(huc, INTEL_HUC_AUTH_BY_GSC));
/*
* On resume we don't have to wait for MEI-GSC to be re-probed, but we
@@ -284,13 +293,23 @@ void intel_huc_init_early(struct intel_huc *huc)
}
if (GRAPHICS_VER(i915) >= 11) {
- huc->status.reg = GEN11_HUC_KERNEL_LOAD_INFO;
- huc->status.mask = HUC_LOAD_SUCCESSFUL;
- huc->status.value = HUC_LOAD_SUCCESSFUL;
+ huc->status[INTEL_HUC_AUTH_BY_GUC].reg =
GEN11_HUC_KERNEL_LOAD_INFO;
+ huc->status[INTEL_HUC_AUTH_BY_GUC].mask = HUC_LOAD_SUCCESSFUL;
+ huc->status[INTEL_HUC_AUTH_BY_GUC].value = HUC_LOAD_SUCCESSFUL;
} else {
- huc->status.reg = HUC_STATUS2;
- huc->status.mask = HUC_FW_VERIFIED;
- huc->status.value = HUC_FW_VERIFIED;
+ huc->status[INTEL_HUC_AUTH_BY_GUC].reg = HUC_STATUS2;
+ huc->status[INTEL_HUC_AUTH_BY_GUC].mask = HUC_FW_VERIFIED;
+ huc->status[INTEL_HUC_AUTH_BY_GUC].value = HUC_FW_VERIFIED;
+ }
+
+ if (IS_DG2(i915)) {
+
[PATCH v3 3/7] drm/i915/huc: Load GSC-enabled HuC via DMA xfer if the fuse says so
In the previous patch we extracted the offset of the legacy-style HuC
binary located within the GSC-enabled blob, so now we can use that to
load the HuC via DMA if the fuse is set that way.
Note that we now need to differentiate between "GSC-enabled binary" and
"loaded by GSC", so the former case has been renamed to "has GSC headers"
for clarity, while the latter is now based on the fuse instead of the
binary format. This way, all the legacy load paths are automatically
taken (including the auth by GuC) without having to implement further
code changes.
v2: s/is_meu_binary/has_gsc_headers/, clearer logs (John)
Signed-off-by: Daniele Ceraolo Spurio
Cc: Alan Previn
Cc: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_huc.c| 29 ++-
drivers/gpu/drm/i915/gt/uc/intel_huc.h| 4 +++-
drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c | 2 +-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 12 +-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 2 +-
5 files changed, 29 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index 6d795438b3e4..37c6a8ca5c71 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -298,31 +298,38 @@ void intel_huc_init_early(struct intel_huc *huc)
static int check_huc_loading_mode(struct intel_huc *huc)
{
struct intel_gt *gt = huc_to_gt(huc);
- bool fw_needs_gsc = intel_huc_is_loaded_by_gsc(huc);
- bool hw_uses_gsc = false;
+ bool gsc_enabled = huc->fw.has_gsc_headers;
/*
* The fuse for HuC load via GSC is only valid on platforms that have
* GuC deprivilege.
*/
if (HAS_GUC_DEPRIVILEGE(gt->i915))
- hw_uses_gsc = intel_uncore_read(gt->uncore, GUC_SHIM_CONTROL2) &
- GSC_LOADS_HUC;
+ huc->loaded_via_gsc = intel_uncore_read(gt->uncore,
GUC_SHIM_CONTROL2) &
+ GSC_LOADS_HUC;
- if (fw_needs_gsc != hw_uses_gsc) {
- huc_err(huc, "mismatch between FW (%s) and HW (%s) load
modes\n",
- HUC_LOAD_MODE_STRING(fw_needs_gsc),
HUC_LOAD_MODE_STRING(hw_uses_gsc));
+ if (huc->loaded_via_gsc && !gsc_enabled) {
+ huc_err(huc, "HW requires a GSC-enabled blob, but we found a
legacy one\n");
return -ENOEXEC;
}
- /* make sure we can access the GSC via the mei driver if we need it */
+ /*
+* Newer GSC_enabled blobs contain the old FW structure inside. If we
+* found that, we can use it to load the legacy way.
+*/
+ if (!huc->loaded_via_gsc && gsc_enabled && !huc->fw.dma_start_offset) {
+ huc_err(huc,"HW in DMA mode, but we have an incompatible
GSC-enabled blob\n");
+ return -ENOEXEC;
+ }
+
+ /* make sure we can access the GSC if we need it */
if (!(IS_ENABLED(CONFIG_INTEL_MEI_PXP) &&
IS_ENABLED(CONFIG_INTEL_MEI_GSC)) &&
- fw_needs_gsc) {
- huc_info(huc, "can't load due to missing MEI modules\n");
+ !HAS_ENGINE(gt, GSC0) && huc->loaded_via_gsc) {
+ huc_info(huc, "can't load due to missing mei modules or
GSCCS\n");
return -EIO;
}
- huc_dbg(huc, "loaded by GSC = %s\n", str_yes_no(fw_needs_gsc));
+ huc_dbg(huc, "loaded by GSC = %s\n", str_yes_no(huc->loaded_via_gsc));
return 0;
}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.h
b/drivers/gpu/drm/i915/gt/uc/intel_huc.h
index 0789184d81a2..112f0dce4702 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.h
@@ -39,6 +39,8 @@ struct intel_huc {
struct notifier_block nb;
enum intel_huc_delayed_load_status status;
} delayed_load;
+
+ bool loaded_via_gsc;
};
int intel_huc_sanitize(struct intel_huc *huc);
@@ -73,7 +75,7 @@ static inline bool intel_huc_is_used(struct intel_huc *huc)
static inline bool intel_huc_is_loaded_by_gsc(const struct intel_huc *huc)
{
- return huc->fw.loaded_via_gsc;
+ return huc->loaded_via_gsc;
}
static inline bool intel_huc_wait_required(struct intel_huc *huc)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c
index 037d2ad4879d..3355dc1e2bc6 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c
@@ -50,7 +50,7 @@ int intel_huc_fw_get_binary_info(struct intel_uc_fw *huc_fw,
const void *data, s
size_t min_size = sizeof(*header);
int i;
- if (!huc_fw->loaded_via_gsc) {
+ if (!huc_fw->has_gsc_headers) {
huc_err(huc, "Invalid FW type GSC header parsing!\n");
return -EINVAL;
}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index
[PATCH v3 5/7] drm/i915/mtl/huc: auth HuC via GSC
The full authentication via the GSC requires an heci packet submission
to the GSC FW via the GSC CS. The GSC has new PXP command for this
(literally called NEW_HUC_AUTH).
The intel_huc_auth fuction is also updated to handle both authentication
types.
v2: check that the GuC auth for clear media has completed before
proceding with the full auth
Signed-off-by: Daniele Ceraolo Spurio
Cc: Alan Previn
---
drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c | 27 +-
.../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c | 2 +-
drivers/gpu/drm/i915/gt/uc/intel_huc.c| 50 +++---
drivers/gpu/drm/i915/gt/uc/intel_huc.h| 6 +-
drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c | 94 +++
drivers/gpu/drm/i915/gt/uc/intel_huc_fw.h | 1 +
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 2 +-
.../drm/i915/pxp/intel_pxp_cmd_interface_43.h | 14 ++-
drivers/gpu/drm/i915/pxp/intel_pxp_huc.c | 2 +-
9 files changed, 176 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
index b26f493f86fa..c659cc01f32f 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
@@ -29,13 +29,32 @@ static void gsc_work(struct work_struct *work)
if (actions & GSC_ACTION_FW_LOAD) {
ret = intel_gsc_uc_fw_upload(gsc);
- if (ret == -EEXIST) /* skip proxy if not a new load */
- actions &= ~GSC_ACTION_FW_LOAD;
- else if (ret)
+ if (!ret)
+ /* setup proxy on a new load */
+ actions |= GSC_ACTION_SW_PROXY;
+ else if (ret != -EEXIST)
goto out_put;
+
+ /*
+* The HuC auth can be done both before or after the proxy init;
+* if done after, a proxy request will be issued and must be
+* serviced before the authentication can complete.
+* Since this worker also handles proxy requests, we can't
+* perform an action that requires the proxy from within it and
+* then stall waiting for it, because we'd be blocking the
+* service path. Therefore, it is easier for us to load HuC
+* first and do proxy later. The GSC will ack the HuC auth and
+* then send the HuC proxy request as part of the proxy init
+* flow.
+* Note that we can only do the GSC auth if the GuC auth was
+* successful.
+*/
+ if (intel_uc_uses_huc(>uc) &&
+ intel_huc_is_authenticated(>uc.huc,
INTEL_HUC_AUTH_BY_GUC))
+ intel_huc_auth(>uc.huc, INTEL_HUC_AUTH_BY_GSC);
}
- if (actions & (GSC_ACTION_FW_LOAD | GSC_ACTION_SW_PROXY)) {
+ if (actions & GSC_ACTION_SW_PROXY) {
if (!intel_gsc_uc_fw_init_done(gsc)) {
gt_err(gt, "Proxy request received with GSC not
loaded!\n");
goto out_put;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c
index 579c0f5a1438..0ad090304ca0 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c
@@ -99,7 +99,7 @@ void intel_gsc_uc_heci_cmd_emit_mtl_header(struct
intel_gsc_mtl_header *header,
u64 host_session_id)
{
host_session_id &= ~HOST_SESSION_MASK;
- if (heci_client_id == HECI_MEADDRESS_PXP)
+ if (host_session_id && heci_client_id == HECI_MEADDRESS_PXP)
host_session_id |= HOST_SESSION_PXP_SINGLE;
header->validity_marker = GSC_HECI_VALIDITY_MARKER;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index ab5246ae3979..5a4058d39550 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -355,20 +355,34 @@ static int check_huc_loading_mode(struct intel_huc *huc)
int intel_huc_init(struct intel_huc *huc)
{
+ struct intel_gt *gt = huc_to_gt(huc);
int err;
err = check_huc_loading_mode(huc);
if (err)
goto out;
+ if (HAS_ENGINE(gt, GSC0)) {
+ struct i915_vma *vma = intel_guc_allocate_vma(>uc.guc,
SZ_8K);
+ if (IS_ERR(vma)) {
+ huc_info(huc, "Failed to allocate heci pkt\n");
+ goto out;
+ }
+
+ huc->heci_pkt = vma;
+ }
+
err = intel_uc_fw_init(>fw);
if (err)
- goto out;
+ goto out_pkt;
intel_uc_fw_change_status(>fw, INTEL_UC_FIRMWARE_LOADABLE);
return 0;
+out_pkt:
+ if (huc->heci_pkt)
+
[PATCH v3 1/7] drm/i915/uc: perma-pin firmwares
Now that each FW has its own reserved area, we can keep them always
pinned and skip the pin/unpin dance on reset. This will make things
easier for the 2-step HuC authentication, which requires the FW to be
pinned in GGTT after the xfer is completed.
Since the vma is now valid for a long time and not just for the quick
pin-load-unpin dance, the name "dummy" is no longer appropriare and has
been replaced with vma_res. All the functions have also been updated to
operate on vma_res for consistency.
Given that we pin the vma behind the allocator's back (which is ok
because we do the pinning in an area that was previously reserved for
thus purpose), we do need to explicitly re-pin on resume because the
automated helper won't cover us.
v2: better comments and commit message, s/dummy/vma_res/
Signed-off-by: Daniele Ceraolo Spurio
Cc: Alan Previn
Cc: John Harrison
---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 3 ++
drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c | 7 +++-
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 2 +-
drivers/gpu/drm/i915/gt/uc/intel_huc.c| 2 +-
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 8
drivers/gpu/drm/i915/gt/uc/intel_uc.h | 2 +
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 50 ---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 22 ++
8 files changed, 71 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 2a7942fac798..f4e8aa8246e8 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -1326,6 +1326,9 @@ void i915_ggtt_resume(struct i915_ggtt *ggtt)
ggtt->vm.scratch_range(>vm, ggtt->error_capture.start,
ggtt->error_capture.size);
+ list_for_each_entry(gt, >gt_list, ggtt_link)
+ intel_uc_resume_mappings(>uc);
+
ggtt->invalidate(ggtt);
if (flush)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
index fb0984f875f9..b26f493f86fa 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
@@ -90,7 +90,12 @@ void intel_gsc_uc_init_early(struct intel_gsc_uc *gsc)
{
struct intel_gt *gt = gsc_uc_to_gt(gsc);
- intel_uc_fw_init_early(>fw, INTEL_UC_FW_TYPE_GSC);
+ /*
+* GSC FW needs to be copied to a dedicated memory allocations for
+* loading (see gsc->local), so we don't need to GGTT map the FW image
+* itself into GGTT.
+*/
+ intel_uc_fw_init_early(>fw, INTEL_UC_FW_TYPE_GSC, false);
INIT_WORK(>work, gsc_work);
/* we can arrive here from i915_driver_early_probe for primary
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index c9f20385f6a0..2eb891b270ae 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -164,7 +164,7 @@ void intel_guc_init_early(struct intel_guc *guc)
struct intel_gt *gt = guc_to_gt(guc);
struct drm_i915_private *i915 = gt->i915;
- intel_uc_fw_init_early(>fw, INTEL_UC_FW_TYPE_GUC);
+ intel_uc_fw_init_early(>fw, INTEL_UC_FW_TYPE_GUC, true);
intel_guc_ct_init_early(>ct);
intel_guc_log_init_early(>log);
intel_guc_submission_init_early(guc);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index 04724ff56ded..268e036f8f28 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -276,7 +276,7 @@ void intel_huc_init_early(struct intel_huc *huc)
struct drm_i915_private *i915 = huc_to_gt(huc)->i915;
struct intel_gt *gt = huc_to_gt(huc);
- intel_uc_fw_init_early(>fw, INTEL_UC_FW_TYPE_HUC);
+ intel_uc_fw_init_early(>fw, INTEL_UC_FW_TYPE_HUC, true);
/*
* we always init the fence as already completed, even if HuC is not
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index c8b9cbb7ba3a..1e7f5cc9d550 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -700,6 +700,12 @@ void intel_uc_suspend(struct intel_uc *uc)
}
}
+static void __uc_resume_mappings(struct intel_uc *uc)
+{
+ intel_uc_fw_resume_mapping(>guc.fw);
+ intel_uc_fw_resume_mapping(>huc.fw);
+}
+
static int __uc_resume(struct intel_uc *uc, bool enable_communication)
{
struct intel_guc *guc = >guc;
@@ -767,4 +773,6 @@ static const struct intel_uc_ops uc_ops_on = {
.init_hw = __uc_init_hw,
.fini_hw = __uc_fini_hw,
+
+ .resume_mappings = __uc_resume_mappings,
};
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.h
b/drivers/gpu/drm/i915/gt/uc/intel_uc.h
index d585524d94de..014bb7d83689 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.h
@@ -24,6 +24,7
[PATCH v3 0/7] drm/i915: HuC loading and authentication for MTL
The HuC loading and authentication flow is once again changing and a new "clear-media only" authentication step is introduced. The flow is as follows: 1) The HuC is loaded via DMA - same as all non-GSC HuC binaries. 2) The HuC is authenticated by the GuC - this is the same step as performed for all non-GSC HuC binaries and re-uses the same code, but it is now resulting in a partial authentication that only allows clear-media workloads. 3) The HuC is fully authenticated for all workloads by the GSC - this is done via a new PXP command, submitted via the GSCCS. The advantage of this new flow is that we can start processing clear-media workloads without having to wait for the GSC to be ready, which can take several seconds. As part of this change, the HuC status getparam has been updated with a new value to indicate a partial authentication. Note tha the media driver is checking for value > 0 for clear media workloads, so no changes are required in userspace for that to work. v2: fix HuC auth status check for DG2. v3: addrss review feedback, stop using the "meu" tag for the naming of the headers, better comments Cc: Alan Previn Cc: John Harrison Acked-by: Tony Ye Daniele Ceraolo Spurio (7): drm/i915/uc: perma-pin firmwares drm/i915/huc: Parse the GSC-enabled HuC binary drm/i915/huc: Load GSC-enabled HuC via DMA xfer if the fuse says so drm/i915/huc: differentiate the 2 steps of the MTL HuC auth flow drm/i915/mtl/huc: auth HuC via GSC drm/i915/mtl/huc: Use the media gt for the HuC getparam drm/i915/huc: define HuC FW version for MTL drivers/gpu/drm/i915/gt/intel_ggtt.c | 3 + .../drm/i915/gt/uc/intel_gsc_binary_headers.h | 74 ++ drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c | 34 ++- .../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c | 2 +- drivers/gpu/drm/i915/gt/uc/intel_guc.c| 2 +- drivers/gpu/drm/i915/gt/uc/intel_huc.c| 201 ++- drivers/gpu/drm/i915/gt/uc/intel_huc.h| 26 +- drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c | 233 +- drivers/gpu/drm/i915/gt/uc/intel_huc_fw.h | 6 +- drivers/gpu/drm/i915/gt/uc/intel_huc_print.h | 21 ++ drivers/gpu/drm/i915/gt/uc/intel_uc.c | 10 +- drivers/gpu/drm/i915/gt/uc/intel_uc.h | 2 + drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 132 +- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 26 +- drivers/gpu/drm/i915/gt/uc/intel_uc_fw_abi.h | 6 - drivers/gpu/drm/i915/i915_getparam.c | 6 +- drivers/gpu/drm/i915/i915_reg.h | 3 + .../drm/i915/pxp/intel_pxp_cmd_interface_43.h | 14 +- drivers/gpu/drm/i915/pxp/intel_pxp_huc.c | 2 +- include/uapi/drm/i915_drm.h | 3 +- 20 files changed, 654 insertions(+), 152 deletions(-) create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_binary_headers.h create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_huc_print.h -- 2.40.0
[PATCH v3 2/7] drm/i915/huc: Parse the GSC-enabled HuC binary
The new binaries that support the 2-step authentication contain the
legacy-style binary, which we can use for loading the HuC via DMA. To
find out where this is located in the image, we need to parse the
manifest of the GSC-enabled HuC binary. The manifest consist of a
partition header followed by entries, one of which contains the offset
we're looking for.
Note that the DG2 GSC binary contains entries with the same names, but
it doesn't contain a full legacy binary, so we need to skip assigning
the dma offset in that case (which we can do by checking the ccs).
Also, since we're now parsing the entries, we can extract the HuC
version that way instead of using hardcoded offsets.
Note that the GSC binary uses the same structures in its binary header,
so they've been added in their own header file.
v2: fix structure names to match meu defines (s/CPT/CPD/), update commit
message, check ccs validity, drop old version location defines.
v3: drop references to the MEU tool to reduce confusion, fix log (John)
Signed-off-by: Daniele Ceraolo Spurio
Cc: Alan Previn
Cc: John Harrison
Reviewed-by: Alan Previn #v2
---
.../drm/i915/gt/uc/intel_gsc_binary_headers.h | 74 ++
drivers/gpu/drm/i915/gt/uc/intel_huc.c| 11 +-
drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c | 135 ++
drivers/gpu/drm/i915/gt/uc/intel_huc_fw.h | 5 +-
drivers/gpu/drm/i915/gt/uc/intel_huc_print.h | 21 +++
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 71 +
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 2 +
drivers/gpu/drm/i915/gt/uc/intel_uc_fw_abi.h | 6 -
8 files changed, 272 insertions(+), 53 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_binary_headers.h
create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_huc_print.h
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_binary_headers.h
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_binary_headers.h
new file mode 100644
index ..714f0c256118
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_binary_headers.h
@@ -0,0 +1,74 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2023 Intel Corporation
+ */
+
+#ifndef _INTEL_GSC_BINARY_HEADERS_H_
+#define _INTEL_GSC_BINARY_HEADERS_H_
+
+#include
+
+/* Code partition directory (CPD) structures */
+struct intel_gsc_cpd_header_v2 {
+ u32 header_marker;
+#define INTEL_GSC_CPD_HEADER_MARKER 0x44504324
+
+ u32 num_of_entries;
+ u8 header_version;
+ u8 entry_version;
+ u8 header_length; /* in bytes */
+ u8 flags;
+ u32 partition_name;
+ u32 crc32;
+} __packed;
+
+struct intel_gsc_cpd_entry {
+ u8 name[12];
+
+ /*
+* Bits 0-24: offset from the beginning of the code partition
+* Bit 25: huffman compressed
+* Bits 26-31: reserved
+*/
+ u32 offset;
+#define INTEL_GSC_CPD_ENTRY_OFFSET_MASK GENMASK(24, 0)
+#define INTEL_GSC_CPD_ENTRY_HUFFMAN_COMP BIT(25)
+
+ /*
+* Module/Item length, in bytes. For Huffman-compressed modules, this
+* refers to the uncompressed size. For software-compressed modules,
+* this refers to the compressed size.
+*/
+ u32 length;
+
+ u8 reserved[4];
+} __packed;
+
+struct intel_gsc_version {
+ u16 major;
+ u16 minor;
+ u16 hotfix;
+ u16 build;
+} __packed;
+
+struct intel_gsc_manifest_header {
+ u32 header_type; /* 0x4 for manifest type */
+ u32 header_length; /* in dwords */
+ u32 header_version;
+ u32 flags;
+ u32 vendor;
+ u32 date;
+ u32 size; /* In dwords, size of entire manifest (header + extensions) */
+ u32 header_id;
+ u32 internal_data;
+ struct intel_gsc_version fw_version;
+ u32 security_version;
+ struct intel_gsc_version meu_kit_version;
+ u32 meu_manifest_version;
+ u8 general_data[4];
+ u8 reserved3[56];
+ u32 modulus_size; /* in dwords */
+ u32 exponent_size; /* in dwords */
+} __packed;
+
+#endif
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index 268e036f8f28..6d795438b3e4 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -6,23 +6,14 @@
#include
#include "gt/intel_gt.h"
-#include "gt/intel_gt_print.h"
#include "intel_guc_reg.h"
#include "intel_huc.h"
+#include "intel_huc_print.h"
#include "i915_drv.h"
#include
#include
-#define huc_printk(_huc, _level, _fmt, ...) \
- gt_##_level(huc_to_gt(_huc), "HuC: " _fmt, ##__VA_ARGS__)
-#define huc_err(_huc, _fmt, ...) huc_printk((_huc), err, _fmt,
##__VA_ARGS__)
-#define huc_warn(_huc, _fmt, ...) huc_printk((_huc), warn, _fmt,
##__VA_ARGS__)
-#define huc_notice(_huc, _fmt, ...)huc_printk((_huc), notice, _fmt,
##__VA_ARGS__)
-#define huc_info(_huc, _fmt, ...) huc_printk((_huc), info, _fmt,
##__VA_ARGS__)
-#define huc_dbg(_huc, _fmt, ...) huc_printk((_huc),
Re: Fwd: Does not work backlight on Chromebook XE303C12 with Kernel version 6.3.4
On Fri, May 26, 2023 at 08:46:32PM +0700, Bagas Sanjaya wrote: > Hi, > > I notice a regression report on Bugzilla [1]. Quoting from it: > > > I did check it by flashlight. Even with all available backlights drivers > > compiled as modules it does not work. With Kernel version 5.15.106 > > backlight works fine. > > Kernels for Chomebook uses dtb files that have some backlight config set > > (used gpio), like exynos5250-snow-common.dtsi and dmesg of 6.3.4 gives some > > gpio warnings. Maybe cause in it. > > See bugzilla for the full thread and attached dmesg & kernel config. > > Anyway, I'm adding it to regzbot: > > #regzbot introduced: v5.15..v6.3 > https://bugzilla.kernel.org/show_bug.cgi?id=217489 > #regzbot title: Chromebook XE303C12 backlight stopped working with gpio > warnings The reporter confirms [1] that he doesn't have this regression (for now) on v6.3.x (not reproducible), so I mark it as inconclusive: #regzbot inconclusive: not a kernel regression Thanks. [1]: https://lore.kernel.org/regressions/288db372-9797-540f-e8bd-794a23648...@gmail.com/t.mbox.gz -- An old man doll... just what I always wanted! - Clara signature.asc Description: PGP signature
[PATCH 0/3] Use FAST_REQUEST mechanism for non-blocking H2G calls
From: John Harrison The GuC interface supports a mechanism for returning errors against non-blocking H2G calls. This is called FAST_REQUEST. Given that the call is asynchronous, matching the returned error up is difficult. However, getting any error at all back is better than no error. If any such errors are reported, then extra tracking support can be compiled in for manual debug. Signed-off-by: John Harrison Michal Wajdeczko (3): drm/i915/guc: Use FAST_REQUEST for non-blocking H2G calls drm/i915/guc: Update log for unsolicited CTB response drm/i915/guc: Track all sent actions to GuC drivers/gpu/drm/i915/Kconfig.debug| 1 + .../gpu/drm/i915/gt/uc/abi/guc_messages_abi.h | 30 +++ drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 79 --- drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 11 +++ 4 files changed, 112 insertions(+), 9 deletions(-) -- 2.39.1
[PATCH 3/3] drm/i915/guc: Track all sent actions to GuC
From: Michal Wajdeczko
For easier debug of any unexpected error responses from GuC that
might be related to non-blocking fast requests, track action code (and
stack if under DEBUG_GUC config) for every H2G request.
Signed-off-by: Michal Wajdeczko
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/Kconfig.debug| 1 +
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 68 ++-
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 11
3 files changed, 77 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/Kconfig.debug
b/drivers/gpu/drm/i915/Kconfig.debug
index 47e845353ffad..2d21930d55015 100644
--- a/drivers/gpu/drm/i915/Kconfig.debug
+++ b/drivers/gpu/drm/i915/Kconfig.debug
@@ -157,6 +157,7 @@ config DRM_I915_SW_FENCE_CHECK_DAG
config DRM_I915_DEBUG_GUC
bool "Enable additional driver debugging for GuC"
depends on DRM_I915
+ select STACKDEPOT
default n
help
Choose this option to turn on extra driver debugging that may affect
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 3a71bb582089e..4aa903be1317b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -376,6 +376,24 @@ void intel_guc_ct_disable(struct intel_guc_ct *ct)
}
}
+#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
+static void ct_track_lost_and_found(struct intel_guc_ct *ct, u32 fence, u32
action)
+{
+ unsigned int lost = fence % ARRAY_SIZE(ct->requests.lost_and_found);
+#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GUC)
+ unsigned long entries[SZ_32];
+ unsigned int n;
+
+ n = stack_trace_save(entries, ARRAY_SIZE(entries), 1);
+
+ /* May be called under spinlock, so avoid sleeping */
+ ct->requests.lost_and_found[lost].stack = stack_depot_save(entries, n,
GFP_NOWAIT);
+#endif
+ ct->requests.lost_and_found[lost].fence = fence;
+ ct->requests.lost_and_found[lost].action = action;
+}
+#endif
+
static u32 ct_get_next_fence(struct intel_guc_ct *ct)
{
/* For now it's trivial */
@@ -447,6 +465,11 @@ static int ct_write(struct intel_guc_ct *ct,
}
GEM_BUG_ON(tail > size);
+#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
+ ct_track_lost_and_found(ct, fence,
+ FIELD_GET(GUC_HXG_EVENT_MSG_0_ACTION,
action[0]));
+#endif
+
/*
* make sure H2G buffer update and LRC tail update (if this triggering a
* submission) are visible before updating the descriptor tail
@@ -953,6 +976,43 @@ static int ct_read(struct intel_guc_ct *ct, struct
ct_incoming_msg **msg)
return -EPIPE;
}
+#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
+static bool ct_check_lost_and_found(struct intel_guc_ct *ct, u32 fence)
+{
+ unsigned int n;
+ char *buf = NULL;
+ bool found = false;
+
+ lockdep_assert_held(>requests.lock);
+
+ for (n = 0; n < ARRAY_SIZE(ct->requests.lost_and_found); n++) {
+ if (ct->requests.lost_and_found[n].fence != fence)
+ continue;
+ found = true;
+
+#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GUC)
+ buf = kmalloc(SZ_4K, GFP_NOWAIT);
+ if (buf &&
stack_depot_snprint(ct->requests.lost_and_found[n].stack,
+ buf, SZ_4K, 0)) {
+ CT_ERROR(ct, "Fence %u was used by action %#04x sent
at\n%s",
+fence, ct->requests.lost_and_found[n].action,
buf);
+ break;
+ }
+#endif
+ CT_ERROR(ct, "Fence %u was used by action %#04x\n",
+fence, ct->requests.lost_and_found[n].action);
+ break;
+ }
+ kfree(buf);
+ return found;
+}
+#else
+static bool ct_check_lost_and_found(struct intel_guc_ct *ct, u32 fence)
+{
+ return false;
+}
+#endif
+
static int ct_handle_response(struct intel_guc_ct *ct, struct ct_incoming_msg
*response)
{
u32 len = FIELD_GET(GUC_CTB_MSG_0_NUM_DWORDS, response->msg[0]);
@@ -996,9 +1056,11 @@ static int ct_handle_response(struct intel_guc_ct *ct,
struct ct_incoming_msg *r
if (!found) {
CT_ERROR(ct, "Unsolicited response message: len %u, data %#x
(fence %u, last %u)\n",
len, hxg[0], fence, ct->requests.last_fence);
- list_for_each_entry(req, >requests.pending, link)
- CT_ERROR(ct, "request %u awaits response\n",
-req->fence);
+ if (!ct_check_lost_and_found(ct, fence)) {
+ list_for_each_entry(req, >requests.pending, link)
+ CT_ERROR(ct, "request %u awaits response\n",
+req->fence);
+ }
err = -ENOKEY;
}
spin_unlock_irqrestore(>requests.lock, flags);
diff --git
[PATCH 2/3] drm/i915/guc: Update log for unsolicited CTB response
From: Michal Wajdeczko
Instead of printing message fence twice, include HXG header of the
unexpected message and its len.
Signed-off-by: Michal Wajdeczko
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index af52ed4ffc7fb..3a71bb582089e 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -994,9 +994,8 @@ static int ct_handle_response(struct intel_guc_ct *ct,
struct ct_incoming_msg *r
break;
}
if (!found) {
- CT_ERROR(ct, "Unsolicited response (fence %u)\n", fence);
- CT_ERROR(ct, "Could not find fence=%u, last_fence=%u\n", fence,
-ct->requests.last_fence);
+ CT_ERROR(ct, "Unsolicited response message: len %u, data %#x
(fence %u, last %u)\n",
+len, hxg[0], fence, ct->requests.last_fence);
list_for_each_entry(req, >requests.pending, link)
CT_ERROR(ct, "request %u awaits response\n",
req->fence);
--
2.39.1
[PATCH 1/3] drm/i915/guc: Use FAST_REQUEST for non-blocking H2G calls
From: Michal Wajdeczko In addition to the already defined REQUEST HXG message format, which is used when sender expects some confirmation or data, HXG protocol includes definition of the FAST REQUEST message, that may be used when sender does not expect any useful data to be returned. Using this instead of GUC_HXG_TYPE_EVENT for non-blocking CTB requests will allow GuC to send back GUC_HXG_TYPE_RESPONSE_FAILURE in case of errors. Note that it is not possible to return such errors to the caller, since this is for non-blocking calls and the related fence is not stored. Instead such messages are treated as unexpected, which will give an indication of potential GuC misprogramming that warrants extra debugging effort. Signed-off-by: Michal Wajdeczko Signed-off-by: John Harrison --- .../gpu/drm/i915/gt/uc/abi/guc_messages_abi.h | 30 +++ drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 6 ++-- 2 files changed, 33 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h b/drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h index 7d5ba4d97d708..98eb4f46572b9 100644 --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h @@ -24,6 +24,7 @@ * | | 30:28 | **TYPE** - message type | * | | | - _`GUC_HXG_TYPE_REQUEST` = 0 | * | | | - _`GUC_HXG_TYPE_EVENT` = 1 | + * | | | - _`GUC_HXG_TYPE_FAST_REQUEST` = 2 | * | | | - _`GUC_HXG_TYPE_NO_RESPONSE_BUSY` = 3 | * | | | - _`GUC_HXG_TYPE_NO_RESPONSE_RETRY` = 5 | * | | | - _`GUC_HXG_TYPE_RESPONSE_FAILURE` = 6 | @@ -46,6 +47,7 @@ #define GUC_HXG_MSG_0_TYPE (0x7 << 28) #define GUC_HXG_TYPE_REQUEST 0u #define GUC_HXG_TYPE_EVENT 1u +#define GUC_HXG_TYPE_FAST_REQUEST2u #define GUC_HXG_TYPE_NO_RESPONSE_BUSY3u #define GUC_HXG_TYPE_NO_RESPONSE_RETRY 5u #define GUC_HXG_TYPE_RESPONSE_FAILURE6u @@ -89,6 +91,34 @@ #define GUC_HXG_REQUEST_MSG_0_ACTION (0x << 0) #define GUC_HXG_REQUEST_MSG_n_DATAnGUC_HXG_MSG_n_PAYLOAD +/** + * DOC: HXG Fast Request + * + * The `HXG Request`_ message should be used to initiate asynchronous activity + * for which confirmation or return data is not expected. + * + * If confirmation is required then `HXG Request`_ shall be used instead. + * + * The recipient of this message may only use `HXG Failure`_ message if it was + * unable to accept this request (like invalid data). + * + * Format of `HXG Fast Request`_ message is same as `HXG Request`_ except @TYPE. + * + * +---+---+--+ + * | | Bits | Description | + * +===+===+==+ + * | 0 |31 | ORIGIN - see `HXG Message`_ | + * | +---+--+ + * | | 30:28 | TYPE = `GUC_HXG_TYPE_FAST_REQUEST`_ | + * | +---+--+ + * | | 27:16 | DATA0 - see `HXG Request`_ | + * | +---+--+ + * | | 15:0 | ACTION - see `HXG Request`_ | + * +---+---+--+ + * |...| | DATAn - see `HXG Request`_ | + * +---+---+--+ + */ + /** * DOC: HXG Event * diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c index a22e33f37cae6..af52ed4ffc7fb 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c @@ -426,11 +426,11 @@ static int ct_write(struct intel_guc_ct *ct, FIELD_PREP(GUC_CTB_MSG_0_NUM_DWORDS, len) | FIELD_PREP(GUC_CTB_MSG_0_FENCE, fence); - type = (flags & INTEL_GUC_CT_SEND_NB) ? GUC_HXG_TYPE_EVENT : + type = (flags & INTEL_GUC_CT_SEND_NB) ? GUC_HXG_TYPE_FAST_REQUEST : GUC_HXG_TYPE_REQUEST; hxg = FIELD_PREP(GUC_HXG_MSG_0_TYPE, type) | - FIELD_PREP(GUC_HXG_EVENT_MSG_0_ACTION | - GUC_HXG_EVENT_MSG_0_DATA0, action[0]); + FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION | + GUC_HXG_REQUEST_MSG_0_DATA0, action[0]); CT_DEBUG(ct, "writing (tail %u) %*ph %*ph %*ph\n", tail, 4, , 4, ,
Re: [PATCH 6/6] drm/i915/uc/gsc: Add a gsc_info debugfs
On Fri, 2023-05-05 at 09:04 -0700, Ceraolo Spurio, Daniele wrote:
> Add a new debugfs to dump information about the GSC. This includes:
alan:snip
Actually everything looks good except for a couple of questions + asks - hope
we can close on this patch in next rev.
>
> - the FW path and SW tracking status;
> - the release, security and compatibility versions;
> - the HECI1 status registers.
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
> b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
> index 0b6dcd982b14..3014e982aab2 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
> @@ -12,36 +12,31 @@
> #include "intel_gsc_fw.h"
> #include "intel_gsc_meu_headers.h"
> #include "intel_gsc_uc_heci_cmd_submit.h"
> -
> -#define GSC_FW_STATUS_REG_MMIO(0x116C40)
> -#define GSC_FW_CURRENT_STATE REG_GENMASK(3, 0)
> -#define GSC_FW_CURRENT_STATE_RESET 0
> -#define GSC_FW_PROXY_STATE_NORMAL 5
> -#define GSC_FW_INIT_COMPLETE_BIT REG_BIT(9)
> +#include "i915_reg.h"
>
alan:snip
alan: btw, just to be consistent with other top-level "intel_foo_is..."
checking functions,
why don't we take the runtime wakeref inside the following functions and make
it easier for any callers?
(just like what we do for "intel_huc_is_authenticated"):
static bool gsc_is_in_reset(struct intel_uncore *uncore)
bool intel_gsc_uc_fw_proxy_init_done(struct intel_gsc_uc *gsc)
bool intel_gsc_uc_fw_init_done(struct intel_gsc_uc *gsc)
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
> b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
> index 2ae693b01b49..5475e95d61c6 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
> @@ -9,8 +9,9 @@
> #include "gt/intel_gt_print.h"
> #include "intel_gsc_uc.h"
alan: nit: not this patch's fault, alphabetically, intel_gsc_uc.h is after
intel_gsc_proxy.h
> #include "intel_gsc_fw.h"
> -#include "i915_drv.h"
> #include "intel_gsc_proxy.h"
> +#include "i915_drv.h"
> +#include "i915_reg.h"
>
> static void gsc_work(struct work_struct *work)
> {
> @@ -301,3 +302,46 @@ void intel_gsc_uc_load_start(struct intel_gsc_uc *gsc)
> queue_work(gsc->wq, >work);
> }
> +
alan: btw, why are we putting intel_gsc_uc_load_status in intel_gsc_uc.c if the
only caller is gsc_uc's debugfs?
why not just make it a static in there? unless u plan to call it from
"err_print_uc" - then can we add that in next rev?
> +void intel_gsc_uc_load_status(struct intel_gsc_uc *gsc, struct drm_printer
> *p)
> +{
> + struct intel_gt *gt = gsc_uc_to_gt(gsc);
> + struct intel_uncore *uncore = gt->uncore;
> + intel_wakeref_t wakeref;
> +
> + if (!intel_gsc_uc_is_supported(gsc)) {
alan: this was already checked in caller so we'll never get here. i think we
should remove the check in the caller, let below msg appear.
> + drm_printf(p, "GSC not supported\n");
> + return;
> + }
alan:snip
> + drm_printf(p, "HECI1 FWSTST%u = 0x%08x\n", i, status);
alan:nit: do you we could add those additional shim regs? (seemed useful in
recent offline debugs).
alan:snip
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_debugfs.c
> b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_debugfs.c
> new file mode 100644
> index ..da9f96b72291
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_debugfs.c
> @@ -0,0 +1,38 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright © 2020 Intel Corporation
alan:2023?
alan:snip
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_debugfs.h
> b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_debugfs.h
> new file mode 100644
> index ..c405e5574253
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_debugfs.h
> @@ -0,0 +1,14 @@
> +/* SPDX-License-Identifier: MIT */
> +/*
> + * Copyright © 2020 Intel Corporation
alan:2023?
alan:snip
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
> b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
alan:snip
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_debugfs.c
> b/drivers/gpu/drm/i915/gt/uc/intel_uc_debugfs.c
> index 2f93cc4e408a..6d541c866edb 100644
alan:snip
Re: [PATCH net-next v5 3/6] net: bcmasp: Add support for ASP2.0 Ethernet controller
On 5/25/23 8:54 PM, Jakub Kicinski wrote:
On Wed, 24 May 2023 16:01:50 -0700 Justin Chen wrote:
Add support for the Broadcom ASP 2.0 Ethernet controller which is first
introduced with 72165. This controller features two distinct Ethernet
ports that can be independently operated.
This patch supports:
- Wake-on-LAN using magic packets
- basic ethtool operations (link, counters, message level)
- MAC destination address filtering (promiscuous, ALL_MULTI, etc.)
+static netdev_tx_t bcmasp_xmit(struct sk_buff *skb, struct net_device *dev)
+{
+ struct bcmasp_intf *intf = netdev_priv(dev);
+ int spb_index, nr_frags, ret, i, j;
+ unsigned int total_bytes, size;
+ struct bcmasp_tx_cb *txcb;
+ dma_addr_t mapping, valid;
+ struct bcmasp_desc *desc;
+ bool csum_hw = false;
+ struct device *kdev;
+ skb_frag_t *frag;
+
+ kdev = >parent->pdev->dev;
+
+ spin_lock(>tx_lock);
What is the tx_lock for? netdevs already have a tx lock, unless you
declare the device as lockless.
Will remove.
+static void bcmasp_tx_timeout(struct net_device *dev, unsigned int txqueue)
+{
+ struct bcmasp_intf *intf = netdev_priv(dev);
+
+ netif_dbg(intf, tx_err, dev, "transmit timeout!\n");
+
+ netif_trans_update(dev);
+ dev->stats.tx_errors++;
+
+ netif_wake_queue(dev);
If the queue is full xmit will just put it back to sleep.
You want to try to reap completions if anything, no?
I can remove the wake. As you mentioned it won't do anything here. There
isn't anything to reap if we are in the timeout condition. If it is some
HW stall, we could flush and restart the ring, but if that is the case I
rather figure out why the HW is stalling. I think we can leave it as a
"tell the user we are stalled" and leave it as that.
+static struct net_device_stats *bcmasp_get_stats(struct net_device *dev)
+{
+ return >stats;
+}
you don't have to do this, core will use device stats if there's no ndo
+ ndev = alloc_etherdev(sizeof(struct bcmasp_intf));
+ if (!dev) {
*blink* condition is typo'ed
Oops. Good catch.
Thanks,
Justin
+ dev_warn(dev, "%s: unable to alloc ndev\n", ndev_dn->name);
+ goto err;
+ }
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [git pull] drm fixes for 6.4-rc4
The pull request you sent on Fri, 26 May 2023 16:04:02 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2023-05-26 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/b83ac44e02986e640ee954e187ba414cb94453e2 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [PATCH] arm64: dts: mediatek: mt8173-elm: remove panel model number in DT
Hi, On Fri, May 26, 2023 at 8:33 AM Icenowy Zheng wrote: > > 在 2023-05-26星期五的 07:24 -0700，Doug Anderson写道： > > Hi, > > > > On Fri, May 26, 2023 at 3:09 AM Icenowy Zheng wrote: > > > > > > Currently a specific panel number is used in the Elm DTSI, which is > > > corresponded to a 12" panel. However, according to the official > > > Chrome > > > OS devices document, Elm refers to Acer Chromebook R13, which, as > > > the > > > name specifies, uses a 13.3" panel, which comes with EDID > > > information. > > > > > > As the kernel currently prioritizes the hardcoded timing parameters > > > matched with the panel number compatible, a wrong timing will be > > > applied > > > to the 13.3" panel on Acer Chromebook R13, which leads to blank > > > display. > > > > > > Because the Elm DTSI is shared with Hana board, and Hana > > > corresponds to > > > multiple devices from 11" to 14", a certain panel model number > > > shouldn't > > > be present, and driving the panel according to its EDID information > > > is > > > necessary. > > > > > > Signed-off-by: Icenowy Zheng > > > --- > > > arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > We went through a bunch of back-and-forth here but in the end in the > > ChromeOS tree we have "edp-panel" as the "compatible" here in the > > ChromeOS 5.15 tree and this makes sense. > > I only have Elm, so I am curious that do all Hana's only rely on panel > EDID to use different displays? > > BTW The Chrome OS document say that Elm and Hana are both board based > on Oak baseboard, should the DTSI be renamed mt8173-oak.dtsi, and still > let mt8173-elm.dts include it and then set model information? I wasn't deeply involved in mt8173, so I'll let treapking@ comment. I think he's done some research here recently. > > Reviewed-by: Douglas Anderson > > > > ...in theory one would wish for a "Fixes" tag, but I think in > > previous > > discussions it was decided that it was too complicated. Hardcoding > > the > > other compatible string has always been technically wrong, but I > > guess > > it worked at some point in time. The more correct way (as you're > > doing > > here) needs the DP AUX bus support and the generic eDP panels, both > > of > > which are significantly newer than the elm dts. So I guess leaving no > > "Fixes" tag is OK, or perhaps you could do the somewhat weak: > > Well I remembered when I was developing the support for Pine64 > Pinebook, which is also an ARM64 laptop with an eDP panel (via a DPI- > eDP bridge, ANX6345). At first I didn't use any panel node in the DT, > and the kernel maintainers argued to the bridge that seems to be > connected to nothing (because DP is a discoverable port), and > fortunately 2 Pinebook SKUs (11.6" and 14") is finally reduced to one, > and it's then possible to hardcode a panel model in the Pinebook DT. > According to my memory, the need to specify the panel is to properly > handle eDP panel power up timing, because it's not a very standard > thing. (Well, in my memory, when I was testing that code, on a > (engineering sample) 14" Pinebook, the EDID timing overrided the > hardcoded 11.6" timing and it properly works, the 14" panel is 1366x768 > but the 11.6" panel is 1920x1080.) > > (BTW when I checked the DT of Olimex TERES-I, which uses the same DPI- > eDP bridge, it is still in the status of a dangling bridge, and of > course it works ;-) ) Before the generic eDP panel support, several devices worked according to the "little white lie" theory. They would pick some arbitrary panel to put in the DT because they had to, but then that panel would just be used for the power up / power down timing and everything else would be overridden. This was obviously not a great situation to be in, and so we had many discussions on the mailing list about how to do better. The end result was the generic edp-panel support. With eDP panel support, you still need to add the timings for your specific panel, but it was realized that in _most_ cases we could power up the panel enough to read the "panel ID" and then we could use that to lookup the timings. In the few cases where we needed a little extra help (if HPD is broken or not connected), the DP folks agreed to allow a few properties to specify it. :-) Hopefully today all new code uses the general panel-edp. -Doug
Re: [PATCH V8 7/7] dt-bindings: bridge: samsung-dsim: Make some flags optional
On Fri, May 26, 2023 at 02:24:21PM -0500, Adam Ford wrote: > On Fri, May 26, 2023 at 1:19 PM Conor Dooley wrote: > > On Thu, May 25, 2023 at 10:05:59PM -0500, Adam Ford wrote: > > > description: > > > - DSIM high speed burst mode frequency. > > > + DSIM high speed burst mode frequency when connected to devices > > > + that support burst mode. If absent, the driver will use the pixel > > > + clock from the attached device or bridge. > > > > I'd rather this description did not say anything about drivers. > > How about: > > If absent, the pixel clock from the attached device or bridge > > will be used instead. > > That makes sense. I can do that. > > "DSIM high speed burst mode frequency (optional). If absent, the pixel > clock from the attached device or bridge will be used instead." > > > Or perhaps "must be used"? Ditto below. > > "Must be" implies to me that the user needs to set something. Are you > ok with the proposed suggestion above? > > > > Description aside, the removal seems to be backwards compatible - but > > can every device that this binding supports work using an "attached > > device or bridge", or are these properties going to be required for > > certain compatibles? > > From what I can tell, the assumption is that the DSIM driver was > expecting it to attach to panels in the past. With the additional > patch series, the DSIM can attach to bridge parts without a hard-coded > set of clocks. I don't expect the existing Exynos devices to change, > but I also don't know what would preclude those SoC's from attaching > to a bridge should someone want to design a new product around them. Okay, that seems fair. With your revised wording, Reviewed-by: Conor Dooley > > I'll wait a couple days for more feedback and send patch V2 with just > this patch since the rest of the series has been applied to the drm > branch. Sounds good. Krzysztof will hopefully be able to take a look then too to make sure I am not making a hames of things. Thanks, Conor. signature.asc Description: PGP signature
Re: [PATCH 0/9] drm/panel and i2c-hid: Allow panels and touchscreens to power sequence together
On 23.05.2023 21:27, Douglas Anderson wrote:
>
> The big motivation for this patch series is mostly described in the patch
> ("drm/panel: Add a way for other devices to follow panel state"), but to
> quickly summarize here: for touchscreens that are connected to a panel we
> need the ability to power sequence the two device together. This is not a
> new need, but so far we've managed to get by through a combination of
> inefficiency, added costs, or perhaps just a little bit of brokenness.
> It's time to do better. This patch series allows us to do better.
Panels with integrated touchscreens have been shipping in mainstream devices
since at least 2016. Thanks a lot for looking into this!
Konrad
>
> Assuming that people think this patch series looks OK, we'll have to
> figure out the right way to land it. The panel patches and i2c-hid
> patches will go through very different trees and so either we'll need
> an Ack from one side or the other or someone to create a tag for the
> other tree to pull in. This will _probably_ require the true drm-misc
> maintainers to get involved, not a lowly committer. ;-)
>
>
> Douglas Anderson (9):
> dt-bindings: HID: i2c-hid: Add "panel" property to i2c-hid backed
> panels
> drm/panel: Check for already prepared/enabled in drm_panel
> drm/panel: Add a way for other devices to follow panel state
> HID: i2c-hid: Switch to SYSTEM_SLEEP_PM_OPS()
> HID: i2c-hid: Rearrange probe() to power things up later
> HID: i2c-hid: Make suspend and resume into helper functions
> HID: i2c-hid: Support being a panel follower
> HID: i2c-hid: Do panel follower work on the system_wq
> arm64: dts: qcom: sc7180: Link trogdor touchscreens to the panels
>
> .../bindings/input/elan,ekth6915.yaml | 6 +
> .../bindings/input/goodix,gt7375p.yaml| 6 +
> .../bindings/input/hid-over-i2c.yaml | 6 +
> .../boot/dts/qcom/sc7180-trogdor-coachz.dtsi | 1 +
> .../dts/qcom/sc7180-trogdor-homestar.dtsi | 1 +
> .../boot/dts/qcom/sc7180-trogdor-lazor.dtsi | 1 +
> .../boot/dts/qcom/sc7180-trogdor-pompom.dtsi | 1 +
> .../qcom/sc7180-trogdor-quackingstick.dtsi| 1 +
> .../dts/qcom/sc7180-trogdor-wormdingler.dtsi | 1 +
> drivers/gpu/drm/drm_panel.c | 194 +-
> drivers/hid/i2c-hid/i2c-hid-core.c| 330 +-
> include/drm/drm_panel.h | 89 +
> 12 files changed, 542 insertions(+), 95 deletions(-)
>
Re: [PATCH V8 7/7] dt-bindings: bridge: samsung-dsim: Make some flags optional
On Fri, May 26, 2023 at 1:19 PM Conor Dooley wrote: > > Adam, Neil, > > I meant to get to this earlier today, but broken CI got in the way... > > On Thu, May 25, 2023 at 10:05:59PM -0500, Adam Ford wrote: > > In the event a device is connected to the samsung-dsim > > controller that doesn't support the burst-clock, the > > driver is able to get the requested pixel clock from the > > attached device or bridge. In these instances, the > > samsung,burst-clock-frequency isn't needed, so remove > > it from the required list. > > > > The pll-clock frequency can be set by the device tree entry > > for samsung,pll-clock-frequency, but in some cases, the > > pll-clock may have the same clock rate as sclk_mipi clock. > > If they are equal, this flag is not needed since the driver > > will use the sclk_mipi rate as a fallback. > > > > Signed-off-by: Adam Ford > > --- > > .../bindings/display/bridge/samsung,mipi-dsim.yaml | 9 + > > 1 file changed, 5 insertions(+), 4 deletions(-) > > > > diff --git > > a/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml > > b/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml > > index 9f61ebdfefa8..360fea81f4b6 100644 > > --- > > a/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml > > +++ > > b/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml > > @@ -70,7 +70,9 @@ properties: > >samsung,burst-clock-frequency: > > $ref: /schemas/types.yaml#/definitions/uint32 > > description: > > - DSIM high speed burst mode frequency. > > + DSIM high speed burst mode frequency when connected to devices > > + that support burst mode. If absent, the driver will use the pixel > > + clock from the attached device or bridge. > > I'd rather this description did not say anything about drivers. > How about: > If absent, the pixel clock from the attached device or bridge > will be used instead. That makes sense. I can do that. "DSIM high speed burst mode frequency (optional). If absent, the pixel clock from the attached device or bridge will be used instead." > Or perhaps "must be used"? Ditto below. "Must be" implies to me that the user needs to set something. Are you ok with the proposed suggestion above? > > Description aside, the removal seems to be backwards compatible - but > can every device that this binding supports work using an "attached > device or bridge", or are these properties going to be required for > certain compatibles? >From what I can tell, the assumption is that the DSIM driver was expecting it to attach to panels in the past. With the additional patch series, the DSIM can attach to bridge parts without a hard-coded set of clocks. I don't expect the existing Exynos devices to change, but I also don't know what would preclude those SoC's from attaching to a bridge should someone want to design a new product around them. I'll wait a couple days for more feedback and send patch V2 with just this patch since the rest of the series has been applied to the drm branch. adam > > Thanks, > Conor. > > > > >samsung,esc-clock-frequency: > > $ref: /schemas/types.yaml#/definitions/uint32 > > @@ -80,7 +82,8 @@ properties: > >samsung,pll-clock-frequency: > > $ref: /schemas/types.yaml#/definitions/uint32 > > description: > > - DSIM oscillator clock frequency. > > + DSIM oscillator clock frequency. If absent, the driver will > > + use the clock frequency of sclk_mipi. > > > >phys: > > maxItems: 1 > > @@ -134,9 +137,7 @@ required: > >- compatible > >- interrupts > >- reg > > - - samsung,burst-clock-frequency > >- samsung,esc-clock-frequency > > - - samsung,pll-clock-frequency > > > > allOf: > >- $ref: ../dsi-controller.yaml# > > -- > > 2.39.2 > >
Re: [PATCH V8 7/7] dt-bindings: bridge: samsung-dsim: Make some flags optional
Adam, Neil, I meant to get to this earlier today, but broken CI got in the way... On Thu, May 25, 2023 at 10:05:59PM -0500, Adam Ford wrote: > In the event a device is connected to the samsung-dsim > controller that doesn't support the burst-clock, the > driver is able to get the requested pixel clock from the > attached device or bridge. In these instances, the > samsung,burst-clock-frequency isn't needed, so remove > it from the required list. > > The pll-clock frequency can be set by the device tree entry > for samsung,pll-clock-frequency, but in some cases, the > pll-clock may have the same clock rate as sclk_mipi clock. > If they are equal, this flag is not needed since the driver > will use the sclk_mipi rate as a fallback. > > Signed-off-by: Adam Ford > --- > .../bindings/display/bridge/samsung,mipi-dsim.yaml | 9 + > 1 file changed, 5 insertions(+), 4 deletions(-) > > diff --git > a/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml > b/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml > index 9f61ebdfefa8..360fea81f4b6 100644 > --- a/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml > +++ b/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml > @@ -70,7 +70,9 @@ properties: >samsung,burst-clock-frequency: > $ref: /schemas/types.yaml#/definitions/uint32 > description: > - DSIM high speed burst mode frequency. > + DSIM high speed burst mode frequency when connected to devices > + that support burst mode. If absent, the driver will use the pixel > + clock from the attached device or bridge. I'd rather this description did not say anything about drivers. How about: If absent, the pixel clock from the attached device or bridge will be used instead. Or perhaps "must be used"? Ditto below. Description aside, the removal seems to be backwards compatible - but can every device that this binding supports work using an "attached device or bridge", or are these properties going to be required for certain compatibles? Thanks, Conor. > >samsung,esc-clock-frequency: > $ref: /schemas/types.yaml#/definitions/uint32 > @@ -80,7 +82,8 @@ properties: >samsung,pll-clock-frequency: > $ref: /schemas/types.yaml#/definitions/uint32 > description: > - DSIM oscillator clock frequency. > + DSIM oscillator clock frequency. If absent, the driver will > + use the clock frequency of sclk_mipi. > >phys: > maxItems: 1 > @@ -134,9 +137,7 @@ required: >- compatible >- interrupts >- reg > - - samsung,burst-clock-frequency >- samsung,esc-clock-frequency > - - samsung,pll-clock-frequency > > allOf: >- $ref: ../dsi-controller.yaml# > -- > 2.39.2 > signature.asc Description: PGP signature
Re: [Freedreno] [PATCH v2 3/6] drm/msm/dpu: split interrupt address arrays
On 5/26/2023 1:43 AM, Dmitry Baryshkov wrote:
On Fri, 26 May 2023 at 01:42, Abhinav Kumar wrote:
On 5/25/2023 3:30 PM, Dmitry Baryshkov wrote:
On Fri, 26 May 2023 at 00:40, Jeykumar Sankaran
wrote:
On 5/22/2023 2:45 PM, Dmitry Baryshkov wrote:
There is no point in having a single enum (and a single array) for both
DPU < 7.0 and DPU >= 7.0 interrupt registers. Instead define a single
enum and two IRQ address arrays.
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_7_0_sm8350.h| 1 +
.../msm/disp/dpu1/catalog/dpu_7_2_sc7280.h| 1 +
.../msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h | 1 +
.../msm/disp/dpu1/catalog/dpu_8_1_sm8450.h| 1 +
.../msm/disp/dpu1/catalog/dpu_9_0_sm8550.h| 1 +
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 2 +
.../gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 82 +--
.../gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h | 28 ---
8 files changed, 79 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h
index 3c1b2c13398d..320cfa4be633 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h
@@ -15,6 +15,7 @@ static const struct dpu_caps sm8350_dpu_caps = {
.has_dim_layer = true,
.has_idle_pc = true,
.has_3d_merge = true,
+ .has_7xxx_intr = true,
.max_linewidth = 4096,
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
};
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
index 5d894cbb0a62..9306c7a115e9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
@@ -13,6 +13,7 @@ static const struct dpu_caps sc7280_dpu_caps = {
.qseed_type = DPU_SSPP_SCALER_QSEED4,
.has_dim_layer = true,
.has_idle_pc = true,
+ .has_7xxx_intr = true,
.max_linewidth = 2400,
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
};
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h
index c3f1ae000a21..fc1e17c495f0 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h
@@ -15,6 +15,7 @@ static const struct dpu_caps sc8280xp_dpu_caps = {
.has_dim_layer = true,
.has_idle_pc = true,
.has_3d_merge = true,
+ .has_7xxx_intr = true,
.max_linewidth = 5120,
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
};
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h
index 86c2e68ebd2c..eb72411c16db 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h
@@ -14,6 +14,7 @@ static const struct dpu_caps sm8450_dpu_caps = {
.has_src_split = true,
.has_dim_layer = true,
.has_idle_pc = true,
+ .has_7xxx_intr = true,
.has_3d_merge = true,
.max_linewidth = 5120,
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h
index 85dc34458b88..8209ca317bdc 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h
@@ -15,6 +15,7 @@ static const struct dpu_caps sm8550_dpu_caps = {
.has_dim_layer = true,
.has_idle_pc = true,
.has_3d_merge = true,
+ .has_7xxx_intr = true,
.max_linewidth = 5120,
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
};
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index 677048cc3b7d..72530ebb0ae6 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -351,6 +351,7 @@ struct dpu_rotation_cfg {
* @has_dim_layer dim layer feature status
* @has_idle_pcindicate if idle power collapse feature is supported
* @has_3d_merge indicate if 3D merge is supported
+ * @has_7xxx_intr indicate that INTF/IRQs use addressing for DPU 7.0 and
greater
I see the requirement to distinguish feature support based on the DPU
version in more than one series. Is it a good idea to bring in the DPU
version info in chipset catalog? This will relieve us from maintaining
such version flags for individual HW sub-blocks.
This would not play well with the rest of the driver. The driver
usually does not compute features by DPU revision. Instead it lists
feature flags.
So I am increasingly seeing examples such as data_compress, widebus
where it looks like version based enablement in the code will be
Re: [PATCH v6 5/6] drm: lcdif: Add multiple encoders and first bridges support
On 5/25/23 03:45, Ying Liu wrote: Hi Marek, Hi, On Thu, May 11, 2023 at 12:24 AM Marek Vasut wrote: On 5/10/23 11:24, Liu Ying wrote: The single LCDIF embedded in i.MX93 SoC may drive multiple displays simultaneously. Look at LCDIF output port's remote port parents to find all enabled first bridges. Add an encoder for each found bridge and attach the bridge to the encoder. This is a preparation for adding i.MX93 LCDIF support. Tested-by: Alexander Stein Acked-by: Alexander Stein Signed-off-by: Liu Ying --- v5->v6: * Drop MAX_DISPLAYS macro. (Marek) * Drop the encoder member in struct lcdif_drm_private. * Drop endpoint id check. It might be nice to check (based on driver data for each IP variant) the encoder count, but that can be a separate patch. Reviewed-by: Marek Vasut Thanks ! btw if this doesn't get picked by someone in like a week or two, let me know and I'll apply this via drm-misc . Thanks for your review. I don't see any more comments in two weeks. Can you please go ahead to apply this series? Done, applied to drm-misc-next , thanks ! Thanks for the reminder too .
Re: [PATCH v3 2/3] dt-bindings: display: st,stm32-dsi: Remove unnecessary fields
On 5/17/23 16:35, Raphael Gallais-Pou wrote: "#address-cells" and "#size-cells" are two properties that are not mandatory. For instance, the DSI could refer to a bridge outside the scope of the node rather than include a 'panel@0' subnode. By doing so, address and size fields become then unnecessary, creating a warning at build time. Signed-off-by: Raphael Gallais-Pou Reviewed-by: Marek Vasut
Re: [PATCH v3 1/3] ARM: dts: stm32: fix warnings on stm32f469-disco board
On 5/17/23 16:35, Raphael Gallais-Pou wrote:
Several warnings appear when building and checking stm32f429 device-tree:
arch/arm/boot/dts/stm32f469-disco.dts:182.28-184.5: Warning
(unit_address_vs_reg):
/soc/display-controller@40016800/port/endpoint@0: node has a unit name, but no
reg or ranges property
.../arch/arm/boot/dts/stm32f469-disco.dtb: dsi@40016c00: Unevaluated properties
are not allowed ('panel-dsi@0' was unexpected)
From schema:
.../Documentation/devicetree/bindings/display/st,stm32-dsi.yaml
Fix those.
Signed-off-by: Raphael Gallais-Pou
Reviewed-by: Marek Vasut
Re: [PATCH v3 3/3] ARM: dts: stm32: fix several DT warnings on stm32mp15
On 5/25/23 10:14, Raphael Gallais-Pou wrote:
Hi,
I think if you retain the stm32mp151.dtsi { port { #address-cells = <1>;
#size-cells = <0>; }; }; part, then you wouldn't be getting any warnings
regarding LTDC , and you wouldn't have to remove the unit-address from
endpoint@0 .
btw. I do use both endpoint@0/endpoint@1 in Avenger96 DTOs, but those are not
submitted yet, I have to clean them up a bit more first.
One way to do it would be to make the endpoint@0 go down in the device-tree with
its dependencies, so that both endpoints are the same level without generating
noise.
I'm afraid I really don't quite understand which warning you're referring to.
Can you please share that warning and ideally how to trigger it (the
command-line incantation) ?
Using '$ make dtbs W=1', you can observe several of the followings:
arch/arm/boot/dts/stm32mp151.dtsi:1533.9-1536.6: Warning
(avoid_unnecessary_addr_size): /soc/display-controller@5a001000/port:
unnecessary #address-cells/#size-cells without "ranges" or child "reg" property
arch/arm/boot/dts/stm32mp151.dtsi:1533.9-1536.6: Warning (graph_child_address):
/soc/display-controller@5a001000/port: graph node has single child node
'endpoint@0', #address-cells/#size-cells are not necessary
This { port { #address-cells = <1>; #size-cells = <0>; }; }; part is
actually annoying. This is because there is several device-trees that only got
one endpoint, and some other that includes two.
For instance: stm32mp15xx-dhcor-avenger96.dtsi vs stm32mp157c-dk2.dts.
I would like to remove to root part of address/size field and let only the lower
device-trees with with multiple endpoints handle their own fields. I hope this
explains a bit better my process.
After thinking about this some more, and digging through LTDC driver,
and testing on EV1, I think dropping the LTDC node endpoint@N and
reg= altogether and just using port/endpoint (singular) is fine.
You might want to split the DSI node specific changes and the LTDC node
specific changes into separate patches (LTDC specific change like you
did in 1/3).
Re: [PATCH v4 00/13] Enable Colorspace connector property in amdgpu
With the documentation about RGB and YCC variants added the drm core patches are Reviewed-by: Sebastian Wick On Fri, May 26, 2023 at 6:24 PM Sebastian Wick wrote: > > On Fri, May 26, 2023 at 3:16 PM Pekka Paalanen wrote: > > > > On Thu, 25 May 2023 15:17:56 -0400 > > Harry Wentland wrote: > > > > > This patchset is based on Joshua's previous patchset [1], as well > > > as my previous patchset [2]. > > > > > > It is > > > - enabling support for the colorspace property in amdgpu, as well as > > > - allowing drivers to specify the supported set of colorspaces, and > > > > > > Colorspace, Infoframes, and YCbCr matrix > > > --- > > > > > > Even though the initial intent of the colorspace property was to set the > > > colorspace field in the respective HDMI AVI and DP SDP infoframes that > > > is not sufficient in all scenarios. For DP the colorspace information > > > also affects the MSA (main stream attribute) packet. For YUV output the > > > colorspace affects the RGB-to-YCbCr conversion matrix. The colorspace > > > field of the infopackets also depends on the encoding used, which is > > > something that is decided by the driver and not known to userspace. > > > > Hi Harry, > > > > the "deprecation" of BT2020 RGB vs. YCC is now dropped completely. > > Should there still be a patch that adds some UAPI documentation only, > > saying that drivers are free to swap e.g. between BT2020 RGB and YCC > > based which encoding they actually chose? > > Yes please! > > > Even if just BT2020 variant specifically. > > > > I have nothing against with this series now. > > > > > > Thanks, > > pq > > > > > > > > For these reasons a driver will need to be able to select the supported > > > colorspaces at property creation. > > > > > > Note: There seems to be an understanding that the colorspace property > > > should ONLY modify the infoframe. While this is current behavior and > > > sufficient in some cases it is nowhere specified that this should be the > > > only use of this property. As outlined above this limitation is not > > > going to work in all cases. > > > > > > This patchset does not affect current behavior for the drivers that > > > implement this property: i915 and vc4. > > > > > > In the future we might want to give userspace control over the encoding > > > format on the wire, in particular to avoid use of YUV420 when image > > > fidelity is important. This work would likely go hand in hand with a > > > min_bpc property and wouldn't conflict with the work done in this > > > patchset. I would expect this future work to tag along with a drm_crtc > > > or drm_connector's Color Pipeline, similar to the one propsed for > > > drm_plane [3]. > > > > > > Colorspace on crtc or connector? > > > > > > > > > There have been suggestions of programming 'colorspace' on the drm_crtc > > > but I don't think the crtc is the right place for this property. The > > > drm_plane and drm_crtc will be used to offload color processing that > > > would normally be done via the GFX or other pipelines. The drm_connector > > > controls the signalling with the display and ensures the wire format is > > > appropriate for the encoding by programming the RGB-to-YCbCr matrix. > > > > > > [1] https://patchwork.freedesktop.org/series/113632/ > > > [2] https://patchwork.freedesktop.org/series/111865/ > > > [3] https://lists.freedesktop.org/archives/dri-devel/2023-May/403173.html
Re: [PATCH] drm/i915: Fix clang -Wimplicit-fallthrough in intel_async_flip_check_hw()
On Thu, May 25, 2023 at 1:30 PM Matthieu Baerts
wrote:
>
> Hi Nick,
>
> On 24/05/2023 20:56, Nick Desaulniers wrote:
> > On Wed, May 24, 2023 at 11:41 AM Nathan Chancellor
> > wrote:
> >>
> >> On Wed, May 24, 2023 at 11:32:32AM -0700, Nick Desaulniers wrote:
> >>> On Wed, May 24, 2023 at 8:38 AM Nathan Chancellor
> >>> wrote:
>
> Clang warns:
>
> drivers/gpu/drm/i915/display/intel_display.c:6012:3: error:
> unannotated fall-through between switch labels
> [-Werror,-Wimplicit-fallthrough]
> case I915_FORMAT_MOD_X_TILED:
> ^
> drivers/gpu/drm/i915/display/intel_display.c:6012:3: note: insert
> 'break;' to avoid fall-through
> case I915_FORMAT_MOD_X_TILED:
> ^
> break;
> 1 error generated.
>
> Clang is a little more pedantic than GCC, which does not warn when
> falling through to a case that is just break or return. Clang's version
> is more in line with the kernel's own stance in deprecated.rst, which
> states that all switch/case blocks must end in either break,
> fallthrough, continue, goto, or return. Add the missing break to silence
> the warning.
>
> Fixes: 937859485aef ("drm/i915: Support Async Flip on Linear buffers")
> Reported-by: kernel test robot
> Closes: https://lore.kernel.org/202305241902.uvhtmoxa-...@intel.com/
> Reported-by: Naresh Kamboju
> Closes:
> https://lore.kernel.org/CA+G9fYv68V3ewK0Qj-syQj7qX-hQr0H1MFL=qfnudoe_j2z...@mail.gmail.com/
> Signed-off-by: Nathan Chancellor
> >>>
> >>> Thanks for the patch! I've never seen the closes tag before, that's
> >>> new to me. Can you tell me more about it?
> >>
> >> It is new to me (at least in the context of the kernel) as well. I only
> >> used it over Link: because checkpatch.pl told me to:
> >>
> >> WARNING: Reported-by: should be immediately followed by Closes: with a URL
> >> to the report
> >> #26:
> >> Reported-by: kernel test robot
> >> Reported-by: Naresh Kamboju
> >>
> >> WARNING: Reported-by: should be immediately followed by Closes: with a URL
> >> to the report
> >> #27:
> >> Reported-by: Naresh Kamboju
> >> Signed-off-by: Nathan Chancellor
> >>
> >> It was Link: for a bit but commit 44c31888098a ("checkpatch: allow
> >> Closes tags with links") changed it to Closes:. Looks odd to me but
> >> whatever the linter says I suppose.
> >>
> >> Thanks for the review!
> >>
> >> Cheers,
> >> Nathan
> >>
> >>> A few more tags
> >>>
> >>> Reported-by: Tom Rix
> >>> Link:
> >>> https://lore.kernel.org/all/20230523125116.1669057-1-t...@redhat.com/
> >>> Reviewed-by: Nick Desaulniers
> >
> > Ah then I guess my link tag should have been
> >
> > Closes:
> > https://lore.kernel.org/all/20230523125116.1669057-1-t...@redhat.com/
> >
> > I hope the author of
> > commit 44c31888098a ("checkpatch: allow Closes tags with links")
> > has coordinated with the maintainer of b4, so that b4 recognizes Closes
> > tags.
> > b4 v0.12.2 does not pick up Closes tags.
>
> I'm sorry for the troubles caused by this series, that was not the
> intension.
>
> When looking at modifying b4 to support the Closes tag, I realised the
> Link tag from your previous message [1] was not taken as well. Was it
> just me?
oh? good find!
>
> If no, I just sent patches for b4, see [2]. I hope it will help!
appreciated! Thank you.
>
> Cheers,
> Matt
>
> [1]
> https://lore.kernel.org/all/CAKwvOd=jzjouunmd3rvc--goa0exphcf6chxua6w1kxjg2a...@mail.gmail.com/
> [2]
> https://lore.kernel.org/tools/20230525-closes-tags-v1-0-ed41b1773...@tessares.net/T/
> --
> Tessares | Belgium | Hybrid Access Solutions
> www.tessares.net
--
Thanks,
~Nick Desaulniers
Re: [PATCH v4 02/13] drm/connector: Add enum documentation to drm_colorspace
On Fri, May 26, 2023 at 6:37 PM Simon Ser wrote: > > On Friday, May 26th, 2023 at 18:27, Sebastian Wick > wrote: > > > > + * @DRM_MODE_COLORIMETRY_DEFAULT: > > > + * Driver specific behavior. > > > + * @DRM_MODE_COLORIMETRY_NO_DATA: > > > + * Driver specific behavior. > > > > TBH this is still confusing me. Is DEFAULT really just driver specific > > behavior? What's the difference to NO_DATA? Is NO_DATA actually not > > driver-specific but display-specific? I.e. the default colorimetry of > > the display? > > DEFAULT == NO_DATA == 0 > *sight* and backwards compat... Alright, not much we can do then.
Re: [PATCH v4 08/13] drm/amd/display: Register Colorspace property for DP and HDMI
On Friday, May 26th, 2023 at 18:40, Sebastian Wick wrote: > On Thu, May 25, 2023 at 9:18 PM Harry Wentland harry.wentl...@amd.com wrote: > > > We want compositors to be able to set the output > > colorspace on DP and HDMI outputs, based on the > > caps reported from the receiver via EDID. > > > This commit message seems wrong for multiple reasons. The Colorspace > property documentation explicitly says that user space has to check > the sink EDID for support: > > > The expectation from userspace is that it should parse the EDID and get > > supported colorspaces. > > The code doesn't seem to care about EDID at all. Instead it exposes > the variants it knows how to support with e.g. the appropriate YCC > transform when necessary, independent of the sink support. The commit messages explains that compositors will parse the EDID. It doesn't state that the kernel does.
Re: [PATCH v4 08/13] drm/amd/display: Register Colorspace property for DP and HDMI
On Thu, May 25, 2023 at 9:18 PM Harry Wentland wrote:
>
> We want compositors to be able to set the output
> colorspace on DP and HDMI outputs, based on the
> caps reported from the receiver via EDID.
This commit message seems wrong for multiple reasons. The Colorspace
property documentation explicitly says that user space has to check
the sink EDID for support:
> The expectation from userspace is that it should parse the EDID and get
> supported colorspaces.
The code doesn't seem to care about EDID at all. Instead it exposes
the variants it knows how to support with e.g. the appropriate YCC
transform when necessary, independent of the sink support.
> Signed-off-by: Harry Wentland
> Cc: Pekka Paalanen
> Cc: Sebastian Wick
> Cc: vitaly.pros...@amd.com
> Cc: Joshua Ashton
> Cc: Simon Ser
> Cc: Ville Syrjälä
> Cc: Melissa Wen
> Cc: dri-devel@lists.freedesktop.org
> Cc: amd-...@lists.freedesktop.org
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index ca093396d1ac..dc99a8ffac70 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -7238,6 +7238,12 @@ static int amdgpu_dm_connector_get_modes(struct
> drm_connector *connector)
> return amdgpu_dm_connector->num_modes;
> }
>
> +static const u32 supported_colorspaces =
> + BIT(DRM_MODE_COLORIMETRY_BT709_YCC) |
> + BIT(DRM_MODE_COLORIMETRY_OPRGB) |
> + BIT(DRM_MODE_COLORIMETRY_BT2020_RGB) |
> + BIT(DRM_MODE_COLORIMETRY_BT2020_YCC);
> +
> void amdgpu_dm_connector_init_helper(struct amdgpu_display_manager *dm,
> struct amdgpu_dm_connector *aconnector,
> int connector_type,
> @@ -7318,6 +7324,15 @@ void amdgpu_dm_connector_init_helper(struct
> amdgpu_display_manager *dm,
> adev->mode_info.abm_level_property, 0);
> }
>
> + if (connector_type == DRM_MODE_CONNECTOR_HDMIA) {
> + if
> (!drm_mode_create_hdmi_colorspace_property(>base,
> supported_colorspaces))
> +
> drm_connector_attach_colorspace_property(>base);
> + } else if (connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
> + connector_type == DRM_MODE_CONNECTOR_eDP) {
> + if
> (!drm_mode_create_dp_colorspace_property(>base,
> supported_colorspaces))
> +
> drm_connector_attach_colorspace_property(>base);
> + }
> +
> if (connector_type == DRM_MODE_CONNECTOR_HDMIA ||
> connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
> connector_type == DRM_MODE_CONNECTOR_eDP) {
> --
> 2.40.1
>
Re: [PATCH v4 02/13] drm/connector: Add enum documentation to drm_colorspace
On Friday, May 26th, 2023 at 18:27, Sebastian Wick wrote: > > + * @DRM_MODE_COLORIMETRY_DEFAULT: > > + * Driver specific behavior. > > + * @DRM_MODE_COLORIMETRY_NO_DATA: > > + * Driver specific behavior. > > TBH this is still confusing me. Is DEFAULT really just driver specific > behavior? What's the difference to NO_DATA? Is NO_DATA actually not > driver-specific but display-specific? I.e. the default colorimetry of > the display? DEFAULT == NO_DATA == 0
Re: [PATCH v4 02/13] drm/connector: Add enum documentation to drm_colorspace
On Thu, May 25, 2023 at 9:18 PM Harry Wentland wrote:
>
> From: Joshua Ashton
>
> To match the other enums, and add more information about these values.
>
> v2:
> - Specify where an enum entry comes from
> - Clarify DEFAULT and NO_DATA behavior
> - BT.2020 CYCC is "constant luminance"
> - correct type for BT.601
>
> v4:
> - drop DP/HDMI clarifications that might create
> more questions than answers
>
> Signed-off-by: Joshua Ashton
> Signed-off-by: Harry Wentland
> Reviewed-by: Harry Wentland
>
> Cc: Pekka Paalanen
> Cc: Sebastian Wick
> Cc: vitaly.pros...@amd.com
> Cc: Uma Shankar
> Cc: Ville Syrjälä
> Cc: Joshua Ashton
> Cc: Simon Ser
> Cc: Ville Syrjälä
> Cc: Melissa Wen
> Cc: dri-devel@lists.freedesktop.org
> Cc: amd-...@lists.freedesktop.org
> ---
> include/drm/drm_connector.h | 62 +++--
> 1 file changed, 60 insertions(+), 2 deletions(-)
>
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 77401e425341..ee597593d7e6 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -363,13 +363,71 @@ enum drm_privacy_screen_status {
> PRIVACY_SCREEN_ENABLED_LOCKED,
> };
>
> -/*
> - * This is a consolidated colorimetry list supported by HDMI and
> +/**
> + * enum drm_colorspace - color space
> + *
> + * This enum is a consolidated colorimetry list supported by HDMI and
> * DP protocol standard. The respective connectors will register
> * a property with the subset of this list (supported by that
> * respective protocol). Userspace will set the colorspace through
> * a colorspace property which will be created and exposed to
> * userspace.
> + *
> + * DP definitions come from the DP v2.0 spec
> + * HDMI definitions come from the CTA-861-H spec
> + *
> + * @DRM_MODE_COLORIMETRY_DEFAULT:
> + * Driver specific behavior.
> + * @DRM_MODE_COLORIMETRY_NO_DATA:
> + * Driver specific behavior.
TBH this is still confusing me. Is DEFAULT really just driver specific
behavior? What's the difference to NO_DATA? Is NO_DATA actually not
driver-specific but display-specific? I.e. the default colorimetry of
the display?
> + * @DRM_MODE_COLORIMETRY_SMPTE_170M_YCC:
> + * (HDMI)
> + * SMPTE ST 170M colorimetry format
> + * @DRM_MODE_COLORIMETRY_BT709_YCC:
> + * (HDMI, DP)
> + * ITU-R BT.709 colorimetry format
> + * @DRM_MODE_COLORIMETRY_XVYCC_601:
> + * (HDMI, DP)
> + * xvYCC601 colorimetry format
> + * @DRM_MODE_COLORIMETRY_XVYCC_709:
> + * (HDMI, DP)
> + * xvYCC709 colorimetry format
> + * @DRM_MODE_COLORIMETRY_SYCC_601:
> + * (HDMI, DP)
> + * sYCC601 colorimetry format
> + * @DRM_MODE_COLORIMETRY_OPYCC_601:
> + * (HDMI, DP)
> + * opYCC601 colorimetry format
> + * @DRM_MODE_COLORIMETRY_OPRGB:
> + * (HDMI, DP)
> + * opRGB colorimetry format
> + * @DRM_MODE_COLORIMETRY_BT2020_CYCC:
> + * (HDMI, DP)
> + * ITU-R BT.2020 Y'c C'bc C'rc (constant luminance) colorimetry format
> + * @DRM_MODE_COLORIMETRY_BT2020_RGB:
> + * (HDMI, DP)
> + * ITU-R BT.2020 R' G' B' colorimetry format
> + * @DRM_MODE_COLORIMETRY_BT2020_YCC:
> + * (HDMI, DP)
> + * ITU-R BT.2020 Y' C'b C'r colorimetry format
> + * @DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65:
> + * (HDMI)
> + * SMPTE ST 2113 P3D65 colorimetry format
> + * @DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER:
> + * (HDMI)
> + * SMPTE ST 2113 P3DCI colorimetry format
> + * @DRM_MODE_COLORIMETRY_RGB_WIDE_FIXED:
> + * (DP)
> + * RGB wide gamut fixed point colorimetry format
> + * @DRM_MODE_COLORIMETRY_RGB_WIDE_FLOAT:
> + * (DP)
> + * RGB wide gamut floating point
> + * (scRGB (IEC 61966-2-2)) colorimetry format
> + * @DRM_MODE_COLORIMETRY_BT601_YCC:
> + * (DP)
> + * ITU-R BT.601 colorimetry format
> + * The DP spec does not say whether this is the 525 or the 625
> + * line version.
> */
> enum drm_colorspace {
> /* For Default case, driver will set the colorspace */
> --
> 2.40.1
>
Re: [PATCH v4 00/13] Enable Colorspace connector property in amdgpu
On Fri, May 26, 2023 at 3:16 PM Pekka Paalanen wrote: > > On Thu, 25 May 2023 15:17:56 -0400 > Harry Wentland wrote: > > > This patchset is based on Joshua's previous patchset [1], as well > > as my previous patchset [2]. > > > > It is > > - enabling support for the colorspace property in amdgpu, as well as > > - allowing drivers to specify the supported set of colorspaces, and > > > > Colorspace, Infoframes, and YCbCr matrix > > --- > > > > Even though the initial intent of the colorspace property was to set the > > colorspace field in the respective HDMI AVI and DP SDP infoframes that > > is not sufficient in all scenarios. For DP the colorspace information > > also affects the MSA (main stream attribute) packet. For YUV output the > > colorspace affects the RGB-to-YCbCr conversion matrix. The colorspace > > field of the infopackets also depends on the encoding used, which is > > something that is decided by the driver and not known to userspace. > > Hi Harry, > > the "deprecation" of BT2020 RGB vs. YCC is now dropped completely. > Should there still be a patch that adds some UAPI documentation only, > saying that drivers are free to swap e.g. between BT2020 RGB and YCC > based which encoding they actually chose? Yes please! > Even if just BT2020 variant specifically. > > I have nothing against with this series now. > > > Thanks, > pq > > > > > For these reasons a driver will need to be able to select the supported > > colorspaces at property creation. > > > > Note: There seems to be an understanding that the colorspace property > > should ONLY modify the infoframe. While this is current behavior and > > sufficient in some cases it is nowhere specified that this should be the > > only use of this property. As outlined above this limitation is not > > going to work in all cases. > > > > This patchset does not affect current behavior for the drivers that > > implement this property: i915 and vc4. > > > > In the future we might want to give userspace control over the encoding > > format on the wire, in particular to avoid use of YUV420 when image > > fidelity is important. This work would likely go hand in hand with a > > min_bpc property and wouldn't conflict with the work done in this > > patchset. I would expect this future work to tag along with a drm_crtc > > or drm_connector's Color Pipeline, similar to the one propsed for > > drm_plane [3]. > > > > Colorspace on crtc or connector? > > > > > > There have been suggestions of programming 'colorspace' on the drm_crtc > > but I don't think the crtc is the right place for this property. The > > drm_plane and drm_crtc will be used to offload color processing that > > would normally be done via the GFX or other pipelines. The drm_connector > > controls the signalling with the display and ensures the wire format is > > appropriate for the encoding by programming the RGB-to-YCbCr matrix. > > > > [1] https://patchwork.freedesktop.org/series/113632/ > > [2] https://patchwork.freedesktop.org/series/111865/ > > [3] https://lists.freedesktop.org/archives/dri-devel/2023-May/403173.html
[RFC 5/5] drm/xe/RAS: send multicast event on occurrence of an error
Whenever a correctable or an uncorrectable error happens an event is sent
to the corresponding listeners of these groups.
Signed-off-by: Aravind Iddamsetty
---
drivers/gpu/drm/xe/xe_irq.c | 32
drivers/gpu/drm/xe/xe_netlink.c | 2 ++
2 files changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/xe/xe_irq.c b/drivers/gpu/drm/xe/xe_irq.c
index 226be96e341a..1b415c8585a4 100644
--- a/drivers/gpu/drm/xe/xe_irq.c
+++ b/drivers/gpu/drm/xe/xe_irq.c
@@ -1073,6 +1073,37 @@ xe_gsc_hw_error_handler(struct xe_gt *gt, const enum
hardware_error hw_err)
xe_mmio_write32(gt, GSC_HEC_CORR_UNCORR_ERR_STATUS(base, hw_err).reg,
err_status);
}
+static void generate_netlink_event(struct xe_gt *gt, const enum hardware_error
hw_err)
+{
+ struct xe_device *xe = gt->xe;
+ struct sk_buff *msg;
+ void *hdr;
+
+ if (!xe->xe_genl_family.module)
+ return;
+
+ msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_ATOMIC);
+ if (!msg) {
+ drm_dbg_driver(>drm, "couldn't allocate memory for error
multicast event\n");
+ return;
+ }
+
+ hdr = genlmsg_put(msg, 0, 0, >xe_genl_family, 0,
DRM_CMD_ERROR_EVENT);
+ if (!hdr) {
+ drm_dbg_driver(>drm, "mutlicast msg buffer is small\n");
+ nlmsg_free(msg);
+ return;
+ }
+
+ genlmsg_end(msg, hdr);
+
+ genlmsg_multicast(>xe_genl_family, msg, 0,
+ hw_err ?
+ DRM_GENL_MCAST_UNCORR_ERR
+ : DRM_GENL_MCAST_CORR_ERR,
+ GFP_ATOMIC);
+}
+
static void
xe_hw_error_source_handler(struct xe_gt *gt, const enum hardware_error hw_err)
{
@@ -1103,6 +1134,7 @@ xe_hw_error_source_handler(struct xe_gt *gt, const enum
hardware_error hw_err)
xe_mmio_write32(gt, DEV_ERR_STAT_REG(hw_err).reg, errsrc);
+ generate_netlink_event(gt, hw_err);
out_unlock:
spin_unlock_irqrestore(_to_xe(gt)->irq.lock, flags);
}
diff --git a/drivers/gpu/drm/xe/xe_netlink.c b/drivers/gpu/drm/xe/xe_netlink.c
index 2a6965f5cde9..0c1d51e1a9a5 100644
--- a/drivers/gpu/drm/xe/xe_netlink.c
+++ b/drivers/gpu/drm/xe/xe_netlink.c
@@ -490,6 +490,8 @@ static void xe_genl_family_init(struct xe_device *xe)
xe->xe_genl_family.ops = xe_genl_ops;
xe->xe_genl_family.n_ops = ARRAY_SIZE(xe_genl_ops);
xe->xe_genl_family.maxattr = DRM_ATTR_MAX;
+ xe->xe_genl_family.mcgrps = drm_event_mcgrps;
+ xe->xe_genl_family.n_mcgrps = ARRAY_SIZE(drm_event_mcgrps);
xe->xe_genl_family.module = THIS_MODULE;
}
--
2.25.1
[RFC 4/5] drm/netlink: define multicast groups
Netlink subsystem supports event notifications to userspace. we define
two multicast groups for correctable and uncorrectable errors to which
userspace can subscribe and be notified when any of those errors happen.
The group names are local to the driver's genl netlink family.
Signed-off-by: Aravind Iddamsetty
---
include/uapi/drm/drm_netlink.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/include/uapi/drm/drm_netlink.h b/include/uapi/drm/drm_netlink.h
index 28e7a334d0c7..bd3a8b293979 100644
--- a/include/uapi/drm/drm_netlink.h
+++ b/include/uapi/drm/drm_netlink.h
@@ -29,6 +29,8 @@
#include
#define DRM_GENL_VERSION 1
+#define DRM_GENL_MCAST_GROUP_NAME_CORR_ERR "drm_corr_err"
+#define DRM_GENL_MCAST_GROUP_NAME_UNCORR_ERR "drm_uncorr_err"
enum error_cmds {
DRM_CMD_UNSPEC,
@@ -38,6 +40,7 @@ enum error_cmds {
DRM_CMD_READ_ONE,
/* command to get counters of all errors */
DRM_CMD_READ_ALL,
+ DRM_CMD_ERROR_EVENT,
__DRM_CMD_MAX,
DRM_CMD_MAX = __DRM_CMD_MAX - 1,
@@ -65,4 +68,14 @@ static const struct nla_policy
drm_attr_policy_read_one[DRM_ATTR_MAX + 1] = {
[DRM_ATTR_ERROR_ID] = { .type = NLA_U64 },
};
+enum mcgrps_events {
+ DRM_GENL_MCAST_CORR_ERR,
+ DRM_GENL_MCAST_UNCORR_ERR,
+};
+
+static const struct genl_multicast_group drm_event_mcgrps[] = {
+ [DRM_GENL_MCAST_CORR_ERR] = { .name =
DRM_GENL_MCAST_GROUP_NAME_CORR_ERR, },
+ [DRM_GENL_MCAST_UNCORR_ERR] = { .name =
DRM_GENL_MCAST_GROUP_NAME_UNCORR_ERR, },
+};
+
#endif
--
2.25.1
[RFC 3/5] drm/xe/RAS: Expose the error counters
We expose the various error counters supported on a hardware via genl
subsystem through the registered commands to userspace.
The DRM_CMD_QUERY lists the error names with config id, DRM_CMD_READ_ONE
returns the counter value for the requested config id and the
DRM_CMD_READ_ALL list the counters for all errors along with their names
and config ids.
Signed-off-by: Aravind Iddamsetty
---
drivers/gpu/drm/xe/xe_netlink.c | 439 +++-
include/uapi/drm/xe_drm.h | 64 +
2 files changed, 501 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/xe/xe_netlink.c b/drivers/gpu/drm/xe/xe_netlink.c
index 63ef238ebc27..2a6965f5cde9 100644
--- a/drivers/gpu/drm/xe/xe_netlink.c
+++ b/drivers/gpu/drm/xe/xe_netlink.c
@@ -4,19 +4,451 @@
*/
#include
+#include
#include "xe_device.h"
+#define MAX_ERROR_NAME 50
+
+#define HAS_GT_ERROR_VECTORS(xe) ((xe)->info.has_gt_error_vectors)
+#define HAS_MEM_SPARING_SUPPORT(xe)((xe)->info.has_mem_sparing)
+
DEFINE_XARRAY(xe_xarray);
-static int xe_genl_list_errors(struct sk_buff *msg, struct genl_info *info)
+static const char * const xe_hw_error_events[] = {
+ [XE_GT_ERROR_CORRECTABLE_L3_SNG] = "correctable-l3-sng",
+ [XE_GT_ERROR_CORRECTABLE_GUC] = "correctable-guc",
+ [XE_GT_ERROR_CORRECTABLE_SAMPLER] = "correctable-sampler",
+ [XE_GT_ERROR_CORRECTABLE_SLM] = "correctable-slm",
+ [XE_GT_ERROR_CORRECTABLE_EU_IC] = "correctable-eu-ic",
+ [XE_GT_ERROR_CORRECTABLE_EU_GRF] = "correctable-eu-grf",
+ [XE_GT_ERROR_FATAL_ARR_BIST] = "fatal-array-bist",
+ [XE_GT_ERROR_FATAL_L3_DOUB] = "fatal-l3-double",
+ [XE_GT_ERROR_FATAL_L3_ECC_CHK] = "fatal-l3-ecc-checker",
+ [XE_GT_ERROR_FATAL_GUC] = "fatal-guc",
+ [XE_GT_ERROR_FATAL_IDI_PAR] = "fatal-idi-parity",
+ [XE_GT_ERROR_FATAL_SQIDI] = "fatal-sqidi",
+ [XE_GT_ERROR_FATAL_SAMPLER] = "fatal-sampler",
+ [XE_GT_ERROR_FATAL_SLM] = "fatal-slm",
+ [XE_GT_ERROR_FATAL_EU_IC] = "fatal-eu-ic",
+ [XE_GT_ERROR_FATAL_EU_GRF] = "fatal-eu-grf",
+ [XE_GT_ERROR_FATAL_FPU] = "fatal-fpu",
+ [XE_GT_ERROR_FATAL_TLB] = "fatal-tlb",
+ [XE_GT_ERROR_FATAL_L3_FABRIC] = "fatal-l3-fabric",
+ [XE_GT_ERROR_CORRECTABLE_SUBSLICE] = "correctable-subslice",
+ [XE_GT_ERROR_CORRECTABLE_L3BANK] = "correctable-l3bank",
+ [XE_GT_ERROR_FATAL_SUBSLICE] = "fatal-subslice",
+ [XE_GT_ERROR_FATAL_L3BANK] = "fatal-l3bank",
+ [XE_SGUNIT_ERROR_CORRECTABLE] = "sgunit-correctable",
+ [XE_SGUNIT_ERROR_NONFATAL] = "sgunit-nonfatal",
+ [XE_SGUNIT_ERROR_FATAL] = "sgunit-fatal",
+ [XE_SOC_ERROR_FATAL_PSF_CSC_0] = "soc-fatal-psf-csc-0",
+ [XE_SOC_ERROR_FATAL_PSF_CSC_1] = "soc-fatal-psf-csc-1",
+ [XE_SOC_ERROR_FATAL_PSF_CSC_2] = "soc-fatal-psf-csc-2",
+ [XE_SOC_ERROR_FATAL_PUNIT] = "soc-fatal-punit",
+ [XE_PVC_SOC_ERROR_FATAL_PSF_0] = "soc-fatal-psf-0",
+ [XE_PVC_SOC_ERROR_FATAL_PSF_1] = "soc-fatal-psf-1",
+ [XE_PVC_SOC_ERROR_FATAL_PSF_2] = "soc-fatal-psf-2",
+ [XE_PVC_SOC_ERROR_FATAL_CD0] = "soc-fatal-cd0",
+ [XE_PVC_SOC_ERROR_FATAL_CD0_MDFI] = "soc-fatal-cd0-mdfi",
+ [XE_PVC_SOC_ERROR_FATAL_MDFI_EAST] = "soc-fatal-mdfi-east",
+ [XE_PVC_SOC_ERROR_FATAL_MDFI_SOUTH] = "soc-fatal-mdfi-south",
+ [XE_PVC_SOC_ERROR_FATAL_HBM(0, 0)] = "soc-fatal-hbm-ss0-0",
+ [XE_PVC_SOC_ERROR_FATAL_HBM(0, 1)] = "soc-fatal-hbm-ss0-1",
+ [XE_PVC_SOC_ERROR_FATAL_HBM(0, 2)] = "soc-fatal-hbm-ss0-2",
+ [XE_PVC_SOC_ERROR_FATAL_HBM(0, 3)] = "soc-fatal-hbm-ss0-3",
+ [XE_PVC_SOC_ERROR_FATAL_HBM(0, 4)] = "soc-fatal-hbm-ss0-4",
+ [XE_PVC_SOC_ERROR_FATAL_HBM(0, 5)] = "soc-fatal-hbm-ss0-5",
+ [XE_PVC_SOC_ERROR_FATAL_HBM(0, 6)] = "soc-fatal-hbm-ss0-6",
+ [XE_PVC_SOC_ERROR_FATAL_HBM(0, 7)] = "soc-fatal-hbm-ss0-7",
+ [XE_PVC_SOC_ERROR_FATAL_HBM(0, 8)] = "soc-fatal-hbm-ss1-0",
+ [XE_PVC_SOC_ERROR_FATAL_HBM(0, 9)] = "soc-fatal-hbm-ss1-1",
+ [XE_PVC_SOC_ERROR_FATAL_HBM(0, 10)] = "soc-fatal-hbm-ss1-2",
+ [XE_PVC_SOC_ERROR_FATAL_HBM(0, 11)] = "soc-fatal-hbm-ss1-3",
+ [XE_PVC_SOC_ERROR_FATAL_HBM(0, 12)] = "soc-fatal-hbm-ss1-4",
+ [XE_PVC_SOC_ERROR_FATAL_HBM(0, 13)] = "soc-fatal-hbm-ss1-5",
+ [XE_PVC_SOC_ERROR_FATAL_HBM(0, 14)] = "soc-fatal-hbm-ss1-6",
+ [XE_PVC_SOC_ERROR_FATAL_HBM(0, 15)] = "soc-fatal-hbm-ss1-7",
+ [XE_PVC_SOC_ERROR_FATAL_HBM(1, 0)] = "soc-fatal-hbm-ss2-0",
+ [XE_PVC_SOC_ERROR_FATAL_HBM(1, 1)] =
[RFC 1/5] drm/netlink: Add netlink infrastructure
Define the netlink commands and attributes that can be commonly used
across by drm drivers.
Signed-off-by: Aravind Iddamsetty
---
include/uapi/drm/drm_netlink.h | 68 ++
1 file changed, 68 insertions(+)
create mode 100644 include/uapi/drm/drm_netlink.h
diff --git a/include/uapi/drm/drm_netlink.h b/include/uapi/drm/drm_netlink.h
new file mode 100644
index ..28e7a334d0c7
--- /dev/null
+++ b/include/uapi/drm/drm_netlink.h
@@ -0,0 +1,68 @@
+/*
+ * Copyright 2023 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * VA LINUX SYSTEMS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#ifndef _DRM_NETLINK_H_
+#define _DRM_NETLINK_H_
+
+#include
+#include
+#include
+
+#define DRM_GENL_VERSION 1
+
+enum error_cmds {
+ DRM_CMD_UNSPEC,
+ /* command to list all errors names with config-id */
+ DRM_CMD_QUERY,
+ /* command to get a counter for a specific error */
+ DRM_CMD_READ_ONE,
+ /* command to get counters of all errors */
+ DRM_CMD_READ_ALL,
+
+ __DRM_CMD_MAX,
+ DRM_CMD_MAX = __DRM_CMD_MAX - 1,
+};
+
+enum error_attr {
+ DRM_ATTR_UNSPEC,
+ DRM_ATTR_PAD = DRM_ATTR_UNSPEC,
+ DRM_ATTR_REQUEST, /* NLA_U8 */
+ DRM_ATTR_QUERY_REPLY, /*NLA_NESTED*/
+ DRM_ATTR_ERROR_NAME, /* NLA_NUL_STRING */
+ DRM_ATTR_ERROR_ID, /* NLA_U64 */
+ DRM_ATTR_ERROR_VALUE, /* NLA_U64 */
+
+ __DRM_ATTR_MAX,
+ DRM_ATTR_MAX = __DRM_ATTR_MAX - 1,
+};
+
+/* attribute policies */
+static const struct nla_policy drm_attr_policy_query[DRM_ATTR_MAX + 1] = {
+ [DRM_ATTR_REQUEST] = { .type = NLA_U8 },
+};
+
+static const struct nla_policy drm_attr_policy_read_one[DRM_ATTR_MAX + 1] = {
+ [DRM_ATTR_ERROR_ID] = { .type = NLA_U64 },
+};
+
+#endif
--
2.25.1
[RFC 2/5] drm/xe/RAS: Register a genl netlink family
Use the generic netlink(genl) subsystem to expose the RAS counters to
userspace. We define a family structure and operations and register to
genl subsystem and these callbacks will be invoked by genl subsystem when
userspace sends a registered command with a family identifier to genl
subsystem.
Signed-off-by: Aravind Iddamsetty
---
drivers/gpu/drm/xe/Makefile | 1 +
drivers/gpu/drm/xe/xe_device.c | 3 +
drivers/gpu/drm/xe/xe_device_types.h | 2 +
drivers/gpu/drm/xe/xe_module.c | 2 +
drivers/gpu/drm/xe/xe_netlink.c | 89
drivers/gpu/drm/xe/xe_netlink.h | 14 +
6 files changed, 111 insertions(+)
create mode 100644 drivers/gpu/drm/xe/xe_netlink.c
create mode 100644 drivers/gpu/drm/xe/xe_netlink.h
diff --git a/drivers/gpu/drm/xe/Makefile b/drivers/gpu/drm/xe/Makefile
index b84e191ba14f..2b42165bc824 100644
--- a/drivers/gpu/drm/xe/Makefile
+++ b/drivers/gpu/drm/xe/Makefile
@@ -67,6 +67,7 @@ xe-y += xe_bb.o \
xe_mmio.o \
xe_mocs.o \
xe_module.o \
+ xe_netlink.o \
xe_pat.o \
xe_pci.o \
xe_pcode.o \
diff --git a/drivers/gpu/drm/xe/xe_device.c b/drivers/gpu/drm/xe/xe_device.c
index 323356a44e7f..aa12ef12d9dc 100644
--- a/drivers/gpu/drm/xe/xe_device.c
+++ b/drivers/gpu/drm/xe/xe_device.c
@@ -24,6 +24,7 @@
#include "xe_irq.h"
#include "xe_mmio.h"
#include "xe_module.h"
+#include "xe_netlink.h"
#include "xe_pcode.h"
#include "xe_pm.h"
#include "xe_query.h"
@@ -317,6 +318,8 @@ int xe_device_probe(struct xe_device *xe)
xe_display_register(xe);
+ xe_genl_register(xe);
+
xe_debugfs_register(xe);
err = drmm_add_action_or_reset(>drm, xe_device_sanitize, xe);
diff --git a/drivers/gpu/drm/xe/xe_device_types.h
b/drivers/gpu/drm/xe/xe_device_types.h
index 682ebdd1c09e..c9612a54c48f 100644
--- a/drivers/gpu/drm/xe/xe_device_types.h
+++ b/drivers/gpu/drm/xe/xe_device_types.h
@@ -10,6 +10,7 @@
#include
#include
+#include
#include
#include "xe_gt_types.h"
@@ -347,6 +348,7 @@ struct xe_device {
u32 lvds_channel_mode;
} params;
#endif
+ struct genl_family xe_genl_family;
};
/**
diff --git a/drivers/gpu/drm/xe/xe_module.c b/drivers/gpu/drm/xe/xe_module.c
index 6860586ce7f8..1eb73eb9a9a5 100644
--- a/drivers/gpu/drm/xe/xe_module.c
+++ b/drivers/gpu/drm/xe/xe_module.c
@@ -11,6 +11,7 @@
#include "xe_drv.h"
#include "xe_hw_fence.h"
#include "xe_module.h"
+#include "xe_netlink.h"
#include "xe_pci.h"
#include "xe_sched_job.h"
@@ -67,6 +68,7 @@ static void __exit xe_exit(void)
{
int i;
+ xe_genl_cleanup();
xe_unregister_pci_driver();
for (i = ARRAY_SIZE(init_funcs) - 1; i >= 0; i--)
diff --git a/drivers/gpu/drm/xe/xe_netlink.c b/drivers/gpu/drm/xe/xe_netlink.c
new file mode 100644
index ..63ef238ebc27
--- /dev/null
+++ b/drivers/gpu/drm/xe/xe_netlink.c
@@ -0,0 +1,89 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2023 Intel Corporation
+ */
+
+#include
+
+#include "xe_device.h"
+
+DEFINE_XARRAY(xe_xarray);
+
+static int xe_genl_list_errors(struct sk_buff *msg, struct genl_info *info)
+{
+ return 0;
+}
+
+static int xe_genl_read_error(struct sk_buff *msg, struct genl_info *info)
+{
+ return 0;
+}
+
+/* operations definition */
+static const struct genl_ops xe_genl_ops[] = {
+ {
+ .cmd = DRM_CMD_QUERY,
+ .doit = xe_genl_list_errors,
+ .policy = drm_attr_policy_query,
+ },
+ {
+ .cmd = DRM_CMD_READ_ONE,
+ .doit = xe_genl_read_error,
+ .policy = drm_attr_policy_read_one,
+ },
+ {
+ .cmd = DRM_CMD_READ_ALL,
+ .doit = xe_genl_list_errors,
+ .policy = drm_attr_policy_query,
+ },
+};
+
+static void xe_genl_deregister(struct drm_device *dev, void *arg)
+{
+ struct xe_device *xe = arg;
+
+ xa_erase(_xarray, xe->xe_genl_family.id);
+
+ drm_dbg_driver(>drm, "unregistering genl family %s\n",
xe->xe_genl_family.name);
+
+ genl_unregister_family(>xe_genl_family);
+}
+
+static void xe_genl_family_init(struct xe_device *xe)
+{
+ /* Use drm primary node name eg: card0 to name the genl family */
+ snprintf(xe->xe_genl_family.name, sizeof(xe->xe_genl_family.name),
"%s", xe->drm.primary->kdev->kobj.name);
+ xe->xe_genl_family.version = DRM_GENL_VERSION;
+ xe->xe_genl_family.parallel_ops = true;
+ xe->xe_genl_family.ops = xe_genl_ops;
+ xe->xe_genl_family.n_ops = ARRAY_SIZE(xe_genl_ops);
+ xe->xe_genl_family.maxattr = DRM_ATTR_MAX;
+ xe->xe_genl_family.module = THIS_MODULE;
+}
+
+int xe_genl_register(struct xe_device *xe)
+{
+ int ret;
+
+ xe_genl_family_init(xe);
+
+ ret = genl_register_family(>xe_genl_family);
+ if (ret < 0) {
+ drm_warn(>drm, "xe genl family registration failed\n");
+
[RFC 0/5] Proposal to use netlink for RAS and Telemetry across drm subsystem
Our hardware supports RAS(Reliability, Availability, Serviceability) by exposing a set of error counters which can be used by observability tools to take corrective actions or repairs. Traditionally there were being exposed via PMU (for relative counters) and sysfs interface (for absolute value) in our internal branch. But, due to the limitations in this approach to use two interfaces and also not able to have an event based reporting or configurability, an alternative approach to try netlink was suggested by community for drm subsystem wide UAPI for RAS and telemetry as discussed in [1]. This [1] is the inspiration to this series. It uses the generic netlink(genl) family subsystem and exposes a set of commands that can be used by every drm driver, the framework provides a means to have custom commands too. Each drm driver instance in this example xe driver instance registers a family and operations to the genl subsystem through which it enumerates and reports the error counters. An event based notification is also supported to which userpace can subscribe to and be notified when any error occurs and read the error counter this avoids continuous polling on error counter. This can also be extended to threshold based notification. [1]: https://airlied.blogspot.com/2022/09/accelerators-bof-outcomes-summary.html this series is on top of https://patchwork.freedesktop.org/series/116181/ Below is an example tool drm_ras which demonstrates the use of the supported commands. The tool will be sent to ML with the subject "[RFC i-g-t 0/1] A tool to demonstrate use of netlink sockets to read RAS error counters" read single error counter: $ ./drm_ras READ_ONE --device=drm:/dev/dri/card1 --error_id=0x0005 counter value 0 read all error counters: $ ./drm_ras READ_ALL --device=drm:/dev/dri/card1 nameconfig-id counter error-gt0-correctable-guc 0x0001 0 error-gt0-correctable-slm 0x0003 0 error-gt0-correctable-eu-ic 0x0004 0 error-gt0-correctable-eu-grf0x0005 0 error-gt0-fatal-guc 0x0009 0 error-gt0-fatal-slm 0x000d 0 error-gt0-fatal-eu-grf 0x000f 0 error-gt0-fatal-fpu 0x0010 0 error-gt0-fatal-tlb 0x0011 0 error-gt0-fatal-l3-fabric 0x0012 0 error-gt0-correctable-subslice 0x0013 0 error-gt0-correctable-l3bank0x0014 0 error-gt0-fatal-subslice0x0015 0 error-gt0-fatal-l3bank 0x0016 0 error-gt0-sgunit-correctable0x0017 0 error-gt0-sgunit-nonfatal 0x0018 0 error-gt0-sgunit-fatal 0x0019 0 error-gt0-soc-fatal-psf-csc-0 0x001a 0 error-gt0-soc-fatal-psf-csc-1 0x001b 0 error-gt0-soc-fatal-psf-csc-2 0x001c 0 error-gt0-soc-fatal-punit 0x001d 0 error-gt0-soc-fatal-psf-0 0x001e 0 error-gt0-soc-fatal-psf-1 0x001f 0 error-gt0-soc-fatal-psf-2 0x0020 0 error-gt0-soc-fatal-cd0 0x0021 0 error-gt0-soc-fatal-cd0-mdfi0x0022 0 error-gt0-soc-fatal-mdfi-east 0x0023 0 error-gt0-soc-fatal-mdfi-south 0x0024 0 error-gt0-soc-fatal-hbm-ss0-0 0x0025 0 error-gt0-soc-fatal-hbm-ss0-1 0x0026 0 error-gt0-soc-fatal-hbm-ss0-2 0x0027 0 error-gt0-soc-fatal-hbm-ss0-3 0x0028 0 error-gt0-soc-fatal-hbm-ss0-4 0x0029 0 error-gt0-soc-fatal-hbm-ss0-5 0x002a 0 error-gt0-soc-fatal-hbm-ss0-6 0x002b 0 error-gt0-soc-fatal-hbm-ss0-7 0x002c 0 error-gt0-soc-fatal-hbm-ss1-0 0x002d 0 error-gt0-soc-fatal-hbm-ss1-1
Re: [PATCH 0/7] Add a DRM driver to support AI Processing Unit (APU)
On 5/24/23 12:40, Daniel Vetter wrote: On Wed, May 24, 2023 at 01:27:00PM +0300, Oded Gabbay wrote: On Wed, May 24, 2023 at 2:34 AM Kevin Hilman wrote: Jeffrey Hugo writes: On 5/17/2023 8:52 AM, Alexandre Bailon wrote: This adds a DRM driver that implements communication between the CPU and an APU. The driver target embedded device that usually run inference using some prebuilt models. The goal is to provide common infrastructure that could be re-used to support many accelerators. Both kernel, userspace and firmware tries to use standard and existing to leverage the development and maintenance effort. The series implements two platform drivers, one for simulation and another one for the mt8183 (compatible with mt8365). This looks like the 3 existing Accel drivers. Why is this in DRM? Yes, this belongs in accel. I think Alex had some issues around the infra in accel with device nodes not appearing/opening properly, but I'll let him comment there. But either way, the right approach should be to fix any issues in accel and move it there. [...] .../devicetree/bindings/gpu/mtk,apu-drm.yaml | 38 ++ drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/apu/Kconfig | 22 + drivers/gpu/drm/apu/Makefile | 10 + drivers/gpu/drm/apu/apu_drv.c | 282 + drivers/gpu/drm/apu/apu_gem.c | 230 +++ drivers/gpu/drm/apu/apu_internal.h| 205 ++ drivers/gpu/drm/apu/apu_sched.c | 592 ++ drivers/gpu/drm/apu/simu_apu.c| 313 + include/uapi/drm/apu_drm.h| 81 +++ "apu" seems too generic. We already have 3 "AI processing units" over in drivers/accel already... Indeed, it is generic, but that's kind of the point for this driver since it's targetted at generalizing the interface with "AI processing units" on a growing number of embedded SoCs (ARM, RISC-V, etc.) In addition, the generic naming is intentional because the goal is bigger than the kernel and is working towards a generic, shared "libAPU" userspace[1], but also common firmware for DSP-style inference engines (e.g. analgous Sound Open Firmware for audio DSPs.) As usual, the various SoC vendors use different names (APU, NPU, NN unit, etc.) but we'd like a generic name for the class of devices targetted by this driver. And unfortunately, it looks like the equally generic "Versatile processing unit" is already taken Intel's drivers/accel/ivpu. :) Maybe since this is more about generalizing the interface between the CPU running linux and the APU, what about the name apu_if? But I guess that applies to the other 3 drivers in drivers/accell also. Hmmm... Naming things is hard[2], so we're definitly open to other ideas. Any suggestions? Maybe model it according to the tiny driver in drm display ? You can then call it tiny_apu :-) Disclosure: It was Daniel's suggestion, he can chime in with more details on the tiny driver concept. Yeah so maybe a bit more detail on my thoughts: First this smells like a need bypass of the entire "we want open userspace for accel drivers" rule. The rule isn't quite a strict as for drm gpu drivers (not sure we ended up documenting exactly what, but iirc the consensus was that for build-time only dependencies we're ok with downstream compilers), but it's still there. What is letting you think that we want to bypass open source requirements ? Although the neural network firmware and userspace application are not yet opensource, our intention is to develop a full open source stack. Currently, we only support Mediatek APU (an Xtensa VP6) and we have to use closed source sotfware to execute inferences on the accelerator. As far I know, there software stack similar to mesa where we could add support of a new accelerator (this is also true for firmware). That is actually what we would like to do. But this will take a lot of time and we consider this driver as a first (small) step. And at least from a quick look apu.ko and libapu just look like a generic accel interface, and that's not enough. For the big training engines it's more or less "enough to run pytorch, but it can be really slow", not sure what the right standard for these inference-only drivers should be. To be honest, I don't know what would be required for training engines. We only target accelerators for embedded device that usually only run inferences. In my opinion, this is 2 different use cases and I don't think we could address them in the same way. So that's the first reason why I don't like this. The other is that I think if we do end up with a pile of tiny accel drivers, we should probably look into something like simmpledrm for the tiny display drivers. Probably still IP specific ioctls (at least most) so that IP specific job knows and all that are easy, but then just
Re: [PATCH 5/7] drm/apu: allow platform driver to implement their own mmap function
On 5/17/23 21:45, Krzysztof Kozlowski wrote: On 17/05/2023 16:52, Alexandre Bailon wrote: From: Julien Stephan By default we will call drm_gem_mmap() unless the apu driver has declared it's own mmap handler. Signed-off-by: Julien Stephan Reviewed-by: Julien Stephan One does not have to review own code. We all assume that we send good code which we do not have to review by ourselves (by the author). We also assume we make mistakes, which we cannot find, thus other person's review is important. I am sorry, I am the one who made the misstake. I squashed this patch with another one I made, lost my signedof and left the reviewed by which indeed doesn't make any sense. Best Regards, Alexandre Adding own review tag suggests you added them mechanically, so I doubt that they really happened. Anyway, your SoB is missing. Best regards, Krzysztof
Re: [PATCH v2] drm: Switch i2c drivers back to use .probe()
Hi,
On Fri, May 26, 2023 at 2:08 AM Uwe Kleine-König
wrote:
>
> After commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new()
> call-back type"), all drivers being converted to .probe_new() and then
> 03c835f498b5 ("i2c: Switch .probe() to not take an id parameter") convert
> back to (the new) .probe() to be able to eventually drop .probe_new() from
> struct i2c_driver.
>
> Signed-off-by: Uwe Kleine-König
> ---
> Hello,
>
> I didn't get feedback for (implicit) v1 that was sent with Message-Id:
> <20230427175954.666464-1-u.kleine-koe...@pengutronix.de>. This is a
> rebase on v6.4-rc1 as the former patch doesn't apply cleanly any more.
>
> I also added more people to Cc, maybe that helps to get feedback.
>
> This patch is based on v6.4-rc1, and applies fine on today's next.
> (There are also no new drivers that need adaption in next.)
>
> Thanks for considering,
> Uwe
>
> drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 2 +-
> drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 2 +-
> drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c | 2 +-
> drivers/gpu/drm/bridge/analogix/anx7625.c| 2 +-
> drivers/gpu/drm/bridge/chipone-icn6211.c | 2 +-
> drivers/gpu/drm/bridge/chrontel-ch7033.c | 2 +-
> drivers/gpu/drm/bridge/cros-ec-anx7688.c | 2 +-
> drivers/gpu/drm/bridge/ite-it6505.c | 2 +-
> drivers/gpu/drm/bridge/ite-it66121.c | 2 +-
> drivers/gpu/drm/bridge/lontium-lt8912b.c | 2 +-
> drivers/gpu/drm/bridge/lontium-lt9211.c | 2 +-
> drivers/gpu/drm/bridge/lontium-lt9611.c | 2 +-
> drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 2 +-
> drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c | 4 ++--
> drivers/gpu/drm/bridge/nxp-ptn3460.c | 2 +-
> drivers/gpu/drm/bridge/parade-ps8622.c | 2 +-
> drivers/gpu/drm/bridge/parade-ps8640.c | 2 +-
> drivers/gpu/drm/bridge/sii902x.c | 2 +-
> drivers/gpu/drm/bridge/sii9234.c | 2 +-
> drivers/gpu/drm/bridge/sil-sii8620.c | 2 +-
> drivers/gpu/drm/bridge/tc358767.c| 2 +-
> drivers/gpu/drm/bridge/tc358768.c| 2 +-
> drivers/gpu/drm/bridge/tc358775.c| 2 +-
> drivers/gpu/drm/bridge/ti-dlpc3433.c | 2 +-
> drivers/gpu/drm/bridge/ti-sn65dsi83.c| 2 +-
> drivers/gpu/drm/bridge/ti-sn65dsi86.c| 2 +-
> drivers/gpu/drm/bridge/ti-tfp410.c | 2 +-
> drivers/gpu/drm/i2c/tda9950.c| 2 +-
> drivers/gpu/drm/i2c/tda998x_drv.c| 2 +-
> drivers/gpu/drm/panel/panel-olimex-lcd-olinuxino.c | 2 +-
> drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c| 2 +-
> drivers/gpu/drm/solomon/ssd130x-i2c.c| 2 +-
> 32 files changed, 33 insertions(+), 33 deletions(-)
Reviewed-by: Douglas Anderson
This does apply to drm-misc-next and I'm happy to apply it there, but
I'm a bit iffy doing it on the Friday before a 3-day weekend (Monday
is a holiday in the US). If this is still pending next Tuesday and I'm
not swamped then, I'll plan to apply it. I'm more than happy if a
different drm commtter wants to apply it sooner. Thanks!
-Doug
[Bug 198907] Backlight control missing with /sys/class/backlight/ empty
https://bugzilla.kernel.org/show_bug.cgi?id=198907 Jani Nikula (jani.nik...@intel.com) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |OBSOLETE --- Comment #7 from Jani Nikula (jani.nik...@intel.com) --- Closing this ancient bug. Please file a new bug at https://gitlab.freedesktop.org/drm/intel/wikis/How-to-file-i915-bugs if still relevant. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH] arm64: dts: mediatek: mt8173-elm: remove panel model number in DT
Hi,
On Fri, May 26, 2023 at 3:09 AM Icenowy Zheng wrote:
>
> Currently a specific panel number is used in the Elm DTSI, which is
> corresponded to a 12" panel. However, according to the official Chrome
> OS devices document, Elm refers to Acer Chromebook R13, which, as the
> name specifies, uses a 13.3" panel, which comes with EDID information.
>
> As the kernel currently prioritizes the hardcoded timing parameters
> matched with the panel number compatible, a wrong timing will be applied
> to the 13.3" panel on Acer Chromebook R13, which leads to blank display.
>
> Because the Elm DTSI is shared with Hana board, and Hana corresponds to
> multiple devices from 11" to 14", a certain panel model number shouldn't
> be present, and driving the panel according to its EDID information is
> necessary.
>
> Signed-off-by: Icenowy Zheng
> ---
> arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
We went through a bunch of back-and-forth here but in the end in the
ChromeOS tree we have "edp-panel" as the "compatible" here in the
ChromeOS 5.15 tree and this makes sense.
Reviewed-by: Douglas Anderson
...in theory one would wish for a "Fixes" tag, but I think in previous
discussions it was decided that it was too complicated. Hardcoding the
other compatible string has always been technically wrong, but I guess
it worked at some point in time. The more correct way (as you're doing
here) needs the DP AUX bus support and the generic eDP panels, both of
which are significantly newer than the elm dts. So I guess leaving no
"Fixes" tag is OK, or perhaps you could do the somewhat weak:
Fixes: c2d94f72140a ("arm64: dts: mediatek: mt8173-elm: Move display
to ps8640 auxiliary bus")
Re: [PATCH V8 0/7] drm: bridge: samsung-dsim: Support variable clocking
On Fri, May 26, 2023 at 2:24 AM Neil Armstrong wrote: > > On 26/05/2023 09:22, Neil Armstrong wrote: > > Hi, > > > > On Thu, 25 May 2023 22:05:52 -0500, Adam Ford wrote: > >> This series fixes the blanking pack size and the PMS calculation. It then > >> adds support to allows the DSIM to dynamically DPHY clocks, and support > >> non-burst mode while allowing the removal of the hard-coded clock values > >> for the PLL for imx8m mini/nano/plus, and it allows the removal of the > >> burst-clock device tree entry when burst-mode isn't supported by connected > >> devices like an HDMI brige. In that event, the HS clock is set to the > >> value requested by the bridge chip. > >> > >> [...] > > > > Thanks, Applied to https://anongit.freedesktop.org/git/drm/drm-misc.git > > (drm-misc-next) > > > > [1/7] drm: bridge: samsung-dsim: fix blanking packet size calculation > > > > https://cgit.freedesktop.org/drm/drm-misc/commit/?id=a617b33f7e513f25becf843bc97f8f1658c16337 > > [2/7] drm: bridge: samsung-dsim: Fix PMS Calculator on imx8m[mnp] > > > > https://cgit.freedesktop.org/drm/drm-misc/commit/?id=54f1a83c72250b182fa7722b0c5f6eb5e769598d > > [3/7] drm: bridge: samsung-dsim: Fetch pll-clock-frequency automatically > > > > https://cgit.freedesktop.org/drm/drm-misc/commit/?id=33d8d14c83bf67aa0d262961a6fda9c40f3c1052 > > [4/7] drm: bridge: samsung-dsim: Select GENERIC_PHY_MIPI_DPHY > > > > https://cgit.freedesktop.org/drm/drm-misc/commit/?id=171b3b1e0f8b8c894f2388e1cf765a56f831ee5e > > [5/7] drm: bridge: samsung-dsim: Dynamically configure DPHY timing > > > > https://cgit.freedesktop.org/drm/drm-misc/commit/?id=89691775f5735fca9dc40e119edcbb52a25b9612 > > [6/7] drm: bridge: samsung-dsim: Support non-burst mode > > > > https://cgit.freedesktop.org/drm/drm-misc/commit/?id=bb0e13b9e223b218c9f242f8d340a332b4381042 > > [7/7] dt-bindings: bridge: samsung-dsim: Make some flags optional > > > > https://cgit.freedesktop.org/drm/drm-misc/commit/?id=cfaf76d349837f695c8aa6d7077847fec4231fe5 > > > > OK I made a bad manipulation, I applied patch 7 without review... I'll send a > revert patch. Sorry, I didn't mean to complicate things by adding the binding patch. I added a note in the cover letter to indicate it, but I also recognize that it contradicted my earlier email. adam > > Neil
Re: [Intel-gfx] [PATCH v2 6/7] drm/i915: No 10bit gamma on desktop gen3 parts
On Thu, May 25, 2023 at 09:25:46PM +, Shankar, Uma wrote:
>
>
> > -Original Message-
> > From: Intel-gfx On Behalf Of
> > Ville Syrjala
> > Sent: Thursday, April 13, 2023 10:19 PM
> > To: intel-...@lists.freedesktop.org
> > Cc: dri-devel@lists.freedesktop.org
> > Subject: [Intel-gfx] [PATCH v2 6/7] drm/i915: No 10bit gamma on desktop
> > gen3 parts
> >
> > From: Ville Syrjälä
> >
> > Apparently desktop gen3 parts don't support the 10bit gamma mode at all.
> > Stop
> > claiming otherwise.
> >
> > As is the case with pipe A on gen3 mobile parts, the PIPECONF gamma mode
> > bit can
> > be set but it has no effect on the output.
> >
> > PNV seems to be the only slight exception, but generally the desktop PNV
> > variant
> > looks more like a mobile part so this is not entirely surprising.
>
> Couldn't check the relevant spec to re-confirm, trusting your judgment here.
The spec isn't helpful here actually. Real world testing on every
gen3 platform was needed to be sure how this works.
> Reviewed-by: Uma Shankar
Thanks.
>
> > Fixes: 67630bacae23 ("drm/i915: Add 10bit gamma mode for gen2/3")
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/i915_pci.c | 8 +++-
> > 1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_pci.c
> > b/drivers/gpu/drm/i915/i915_pci.c index
> > cddb6e197972..305c05c3f93b 100644
> > --- a/drivers/gpu/drm/i915/i915_pci.c
> > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > @@ -250,13 +250,13 @@ static const struct intel_device_info i865g_info = {
> > .dma_mask_size = 32, \
> > I9XX_PIPE_OFFSETS, \
> > I9XX_CURSOR_OFFSETS, \
> > - I9XX_COLORS, \
> > GEN_DEFAULT_PAGE_SIZES, \
> > GEN_DEFAULT_REGIONS
> >
> > static const struct intel_device_info i915g_info = {
> > GEN3_FEATURES,
> > PLATFORM(INTEL_I915G),
> > + I845_COLORS,
> > .has_coherent_ggtt = false,
> > .display.cursor_needs_physical = 1,
> > .display.has_overlay = 1,
> > @@ -268,6 +268,7 @@ static const struct intel_device_info i915g_info = {
> > static
> > const struct intel_device_info i915gm_info = {
> > GEN3_FEATURES,
> > PLATFORM(INTEL_I915GM),
> > + I9XX_COLORS,
> > .is_mobile = 1,
> > .display.cursor_needs_physical = 1,
> > .display.has_overlay = 1,
> > @@ -281,6 +282,7 @@ static const struct intel_device_info i915gm_info = {
> > static
> > const struct intel_device_info i945g_info = {
> > GEN3_FEATURES,
> > PLATFORM(INTEL_I945G),
> > + I845_COLORS,
> > .display.has_hotplug = 1,
> > .display.cursor_needs_physical = 1,
> > .display.has_overlay = 1,
> > @@ -292,6 +294,7 @@ static const struct intel_device_info i945g_info = {
> > static
> > const struct intel_device_info i945gm_info = {
> > GEN3_FEATURES,
> > PLATFORM(INTEL_I945GM),
> > + I9XX_COLORS,
> > .is_mobile = 1,
> > .display.has_hotplug = 1,
> > .display.cursor_needs_physical = 1,
> > @@ -306,6 +309,7 @@ static const struct intel_device_info i945gm_info = {
> > static
> > const struct intel_device_info g33_info = {
> > GEN3_FEATURES,
> > PLATFORM(INTEL_G33),
> > + I845_COLORS,
> > .display.has_hotplug = 1,
> > .display.has_overlay = 1,
> > .dma_mask_size = 36,
> > @@ -314,6 +318,7 @@ static const struct intel_device_info g33_info = {
> > static
> > const struct intel_device_info pnv_g_info = {
> > GEN3_FEATURES,
> > PLATFORM(INTEL_PINEVIEW),
> > + I9XX_COLORS,
> > .display.has_hotplug = 1,
> > .display.has_overlay = 1,
> > .dma_mask_size = 36,
> > @@ -322,6 +327,7 @@ static const struct intel_device_info pnv_g_info = {
> > static
> > const struct intel_device_info pnv_m_info = {
> > GEN3_FEATURES,
> > PLATFORM(INTEL_PINEVIEW),
> > + I9XX_COLORS,
> > .is_mobile = 1,
> > .display.has_hotplug = 1,
> > .display.has_overlay = 1,
> > --
> > 2.39.2
>
--
Ville Syrjälä
Intel
Re: [PATCH v2 3/7] drm/i915: Fix CHV CGM CSC coefficient sign handling
On Thu, May 25, 2023 at 08:55:08PM +, Shankar, Uma wrote:
>
>
> > -Original Message-
> > From: dri-devel On Behalf Of
> > Ville Syrjala
> > Sent: Thursday, April 13, 2023 10:19 PM
> > To: intel-...@lists.freedesktop.org
> > Cc: dri-devel@lists.freedesktop.org
> > Subject: [PATCH v2 3/7] drm/i915: Fix CHV CGM CSC coefficient sign handling
> >
> > From: Ville Syrjälä
> >
> > The CHV CGM CSC coefficients are in s4.12 two's complement format. Fix the
> > CTM-
> > >CGM conversion to handle that correctly instead of pretending that the hw
> > coefficients are also in some sign-magnitude format.
>
> Spec is slightly confusing when it says:
> "CGM CSC : Input pixels to the CGM CSC are 14 bits. (u.14 format).
> Coefficients are 16 bits (s3.12)."
> Also here:
> "Programmable parameters :
> c0[15 :0], c1[15 :0], c2[15 :0], c3[15 :0], c4[15 :0], c5[15 :0], c6[15 :0],
> c7[15 :0], c8[15 :0] ; // signed matrix coefficients (s3.12)"
Yeah, the spec just uses a weird notation where it doesn't count the msb
in the bits.
>
> But the coefficients are 16bits, can you help understand how were you able to
> crack this
The 16bit coefficient already made me suspect they screwed up
the notation. Testing specific values on real hardware
confirmed that.
>
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/display/intel_color.c | 46 ++
> > 1 file changed, 29 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> > b/drivers/gpu/drm/i915/display/intel_color.c
> > index 4fc16cac052d..63141f4ed372 100644
> > --- a/drivers/gpu/drm/i915/display/intel_color.c
> > +++ b/drivers/gpu/drm/i915/display/intel_color.c
> > @@ -568,29 +568,41 @@ static void icl_load_csc_matrix(const struct
> > intel_crtc_state *crtc_state)
> > icl_update_output_csc(crtc, _state->output_csc); }
> >
> > +static u16 ctm_to_twos_complement(u64 coeff, int int_bits, int
> > +frac_bits) {
> > + s64 c = CTM_COEFF_ABS(coeff);
> > +
> > + /* leave an extra bit for rounding */
> > + c >>= 32 - frac_bits - 1;
> > +
> > + /* round and drop the extra bit */
> > + c = (c + 1) >> 1;
> > +
> > + if (CTM_COEFF_NEGATIVE(coeff))
> > + c = -c;
> > +
> > + c = clamp(c, -(s64)BIT(int_bits + frac_bits - 1),
> > + (s64)(BIT(int_bits + frac_bits - 1) - 1));
> > +
> > + return c & (BIT(int_bits + frac_bits) - 1); }
> > +
> > +/*
> > + * CHV Color Gamut Mapping (CGM) CSC
> > + * |r| | c0 c1 c2 | |r|
> > + * |g| = | c3 c4 c5 | x |g|
> > + * |b| | c6 c7 c8 | |b|
> > + *
> > + * Coefficients are two's complement s4.12.
> > + */
> > static void chv_cgm_csc_convert_ctm(const struct intel_crtc_state
> > *crtc_state,
> > struct intel_csc_matrix *csc)
> > {
> > const struct drm_color_ctm *ctm = crtc_state->hw.ctm->data;
> > int i;
> >
> > - for (i = 0; i < 9; i++) {
> > - u64 abs_coeff = ((1ULL << 63) - 1) & ctm->matrix[i];
> > -
> > - /* Round coefficient. */
> > - abs_coeff += 1 << (32 - 13);
> > - /* Clamp to hardware limits. */
> > - abs_coeff = clamp_val(abs_coeff, 0, CTM_COEFF_8_0 - 1);
> > -
> > - csc->coeff[i] = 0;
> > -
> > - /* Write coefficients in S3.12 format. */
> > - if (ctm->matrix[i] & (1ULL << 63))
> > - csc->coeff[i] |= 1 << 15;
> > -
> > - csc->coeff[i] |= ((abs_coeff >> 32) & 7) << 12;
> > - csc->coeff[i] |= (abs_coeff >> 20) & 0xfff;
> > - }
> > + for (i = 0; i < 9; i++)
> > + csc->coeff[i] = ctm_to_twos_complement(ctm->matrix[i], 4, 12);
> > }
> >
> > static void chv_load_cgm_csc(struct intel_crtc *crtc,
> > --
> > 2.39.2
>
--
Ville Syrjälä
Intel
Fwd: Does not work backlight on Chromebook XE303C12 with Kernel version 6.3.4
Hi, I notice a regression report on Bugzilla [1]. Quoting from it: > I did check it by flashlight. Even with all available backlights drivers > compiled as modules it does not work. With Kernel version 5.15.106 backlight > works fine. > Kernels for Chomebook uses dtb files that have some backlight config set > (used gpio), like exynos5250-snow-common.dtsi and dmesg of 6.3.4 gives some > gpio warnings. Maybe cause in it. See bugzilla for the full thread and attached dmesg & kernel config. Anyway, I'm adding it to regzbot: #regzbot introduced: v5.15..v6.3 https://bugzilla.kernel.org/show_bug.cgi?id=217489 #regzbot title: Chromebook XE303C12 backlight stopped working with gpio warnings Thanks. [1]: https://bugzilla.kernel.org/show_bug.cgi?id=217489 -- An old man doll... just what I always wanted! - Clara
Re: [PATCH v4 00/13] Enable Colorspace connector property in amdgpu
On Thu, 25 May 2023 15:17:56 -0400 Harry Wentland wrote: > This patchset is based on Joshua's previous patchset [1], as well > as my previous patchset [2]. > > It is > - enabling support for the colorspace property in amdgpu, as well as > - allowing drivers to specify the supported set of colorspaces, and > > Colorspace, Infoframes, and YCbCr matrix > --- > > Even though the initial intent of the colorspace property was to set the > colorspace field in the respective HDMI AVI and DP SDP infoframes that > is not sufficient in all scenarios. For DP the colorspace information > also affects the MSA (main stream attribute) packet. For YUV output the > colorspace affects the RGB-to-YCbCr conversion matrix. The colorspace > field of the infopackets also depends on the encoding used, which is > something that is decided by the driver and not known to userspace. Hi Harry, the "deprecation" of BT2020 RGB vs. YCC is now dropped completely. Should there still be a patch that adds some UAPI documentation only, saying that drivers are free to swap e.g. between BT2020 RGB and YCC based which encoding they actually chose? Even if just BT2020 variant specifically. I have nothing against with this series now. Thanks, pq > > For these reasons a driver will need to be able to select the supported > colorspaces at property creation. > > Note: There seems to be an understanding that the colorspace property > should ONLY modify the infoframe. While this is current behavior and > sufficient in some cases it is nowhere specified that this should be the > only use of this property. As outlined above this limitation is not > going to work in all cases. > > This patchset does not affect current behavior for the drivers that > implement this property: i915 and vc4. > > In the future we might want to give userspace control over the encoding > format on the wire, in particular to avoid use of YUV420 when image > fidelity is important. This work would likely go hand in hand with a > min_bpc property and wouldn't conflict with the work done in this > patchset. I would expect this future work to tag along with a drm_crtc > or drm_connector's Color Pipeline, similar to the one propsed for > drm_plane [3]. > > Colorspace on crtc or connector? > > > There have been suggestions of programming 'colorspace' on the drm_crtc > but I don't think the crtc is the right place for this property. The > drm_plane and drm_crtc will be used to offload color processing that > would normally be done via the GFX or other pipelines. The drm_connector > controls the signalling with the display and ensures the wire format is > appropriate for the encoding by programming the RGB-to-YCbCr matrix. > > [1] https://patchwork.freedesktop.org/series/113632/ > [2] https://patchwork.freedesktop.org/series/111865/ > [3] https://lists.freedesktop.org/archives/dri-devel/2023-May/403173.html pgp7flD4vfj_J.pgp Description: OpenPGP digital signature
Re: [PATCH v4 02/13] drm/connector: Add enum documentation to drm_colorspace
On Thu, 25 May 2023 15:17:58 -0400
Harry Wentland wrote:
> From: Joshua Ashton
>
> To match the other enums, and add more information about these values.
>
> v2:
> - Specify where an enum entry comes from
> - Clarify DEFAULT and NO_DATA behavior
> - BT.2020 CYCC is "constant luminance"
> - correct type for BT.601
>
> v4:
> - drop DP/HDMI clarifications that might create
> more questions than answers
>
> Signed-off-by: Joshua Ashton
> Signed-off-by: Harry Wentland
> Reviewed-by: Harry Wentland
>
> Cc: Pekka Paalanen
> Cc: Sebastian Wick
> Cc: vitaly.pros...@amd.com
> Cc: Uma Shankar
> Cc: Ville Syrjälä
> Cc: Joshua Ashton
> Cc: Simon Ser
> Cc: Ville Syrjälä
> Cc: Melissa Wen
> Cc: dri-devel@lists.freedesktop.org
> Cc: amd-...@lists.freedesktop.org
> ---
> include/drm/drm_connector.h | 62 +++--
> 1 file changed, 60 insertions(+), 2 deletions(-)
>
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 77401e425341..ee597593d7e6 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -363,13 +363,71 @@ enum drm_privacy_screen_status {
> PRIVACY_SCREEN_ENABLED_LOCKED,
> };
>
> -/*
> - * This is a consolidated colorimetry list supported by HDMI and
> +/**
> + * enum drm_colorspace - color space
> + *
> + * This enum is a consolidated colorimetry list supported by HDMI and
> * DP protocol standard. The respective connectors will register
> * a property with the subset of this list (supported by that
> * respective protocol). Userspace will set the colorspace through
> * a colorspace property which will be created and exposed to
> * userspace.
> + *
> + * DP definitions come from the DP v2.0 spec
> + * HDMI definitions come from the CTA-861-H spec
> + *
> + * @DRM_MODE_COLORIMETRY_DEFAULT:
> + * Driver specific behavior.
> + * @DRM_MODE_COLORIMETRY_NO_DATA:
> + * Driver specific behavior.
> + * @DRM_MODE_COLORIMETRY_SMPTE_170M_YCC:
> + * (HDMI)
> + * SMPTE ST 170M colorimetry format
> + * @DRM_MODE_COLORIMETRY_BT709_YCC:
> + * (HDMI, DP)
> + * ITU-R BT.709 colorimetry format
> + * @DRM_MODE_COLORIMETRY_XVYCC_601:
> + * (HDMI, DP)
> + * xvYCC601 colorimetry format
> + * @DRM_MODE_COLORIMETRY_XVYCC_709:
> + * (HDMI, DP)
> + * xvYCC709 colorimetry format
> + * @DRM_MODE_COLORIMETRY_SYCC_601:
> + * (HDMI, DP)
> + * sYCC601 colorimetry format
> + * @DRM_MODE_COLORIMETRY_OPYCC_601:
> + * (HDMI, DP)
> + * opYCC601 colorimetry format
> + * @DRM_MODE_COLORIMETRY_OPRGB:
> + * (HDMI, DP)
> + * opRGB colorimetry format
> + * @DRM_MODE_COLORIMETRY_BT2020_CYCC:
> + * (HDMI, DP)
> + * ITU-R BT.2020 Y'c C'bc C'rc (constant luminance) colorimetry format
> + * @DRM_MODE_COLORIMETRY_BT2020_RGB:
> + * (HDMI, DP)
> + * ITU-R BT.2020 R' G' B' colorimetry format
> + * @DRM_MODE_COLORIMETRY_BT2020_YCC:
> + * (HDMI, DP)
> + * ITU-R BT.2020 Y' C'b C'r colorimetry format
> + * @DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65:
> + * (HDMI)
> + * SMPTE ST 2113 P3D65 colorimetry format
> + * @DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER:
> + * (HDMI)
> + * SMPTE ST 2113 P3DCI colorimetry format
> + * @DRM_MODE_COLORIMETRY_RGB_WIDE_FIXED:
> + * (DP)
> + * RGB wide gamut fixed point colorimetry format
> + * @DRM_MODE_COLORIMETRY_RGB_WIDE_FLOAT:
> + * (DP)
> + * RGB wide gamut floating point
> + * (scRGB (IEC 61966-2-2)) colorimetry format
> + * @DRM_MODE_COLORIMETRY_BT601_YCC:
> + * (DP)
> + * ITU-R BT.601 colorimetry format
> + * The DP spec does not say whether this is the 525 or the 625
> + * line version.
> */
> enum drm_colorspace {
> /* For Default case, driver will set the colorspace */
This is probably as good as possible, having references to chase when
questions arise.
Acked-by: Pekka Paalanen
Thanks,
pq
pgpr9vqI0ihPJ.pgp
Description: OpenPGP digital signature
Re: [v4,12/13] drm/fbdev-generic: Implement dedicated fbdev I/O helpers
Hi
Am 24.05.23 um 22:23 schrieb Sui Jingfeng:
Tested-by: Sui Jingfeng
This version works fine, I have tested it On LoongArch with
drm/loongson(v14) as it is most handy for me.
Also because it using fbdev-generic. fbdev of IGT report no error. Then
I run fbtest from geert[1],
Before apply your patch:
Benchmarking... 10x10 squares: 468.39 Mpixels/s
Benchmarking... 20x20 squares: 985.02 Mpixels/s
Benchmarking... 50x50 squares: 2247.22 Mpixels/s
Benchmarking... 100x100 squares: 2242.30 Mpixels/s
Benchmarking... 200x200 squares: 2883.18 Mpixels/s
Benchmarking... 500x500 squares: 3642.18 Mpixels/s
Benchmarking... 1000x1000 squares: 3992.77 Mpixels/s
Benchmarking... R5 circles: 261.90 Mpixels/s
Benchmarking... R10 circles: 596.27 Mpixels/s
Benchmarking... R25 circles: 1513.96 Mpixels/s
Benchmarking... R50 circles: 1965.07 Mpixels/s
Benchmarking... R100 circles: 2470.75 Mpixels/s
Benchmarking... R250 circles: 3288.00 Mpixels/s
Benchmarking... R500 circles: 3705.66 Mpixels/s
After apply your patch:
Benchmarking... 10x10 squares: 477.04 Mpixels/s
Benchmarking... 20x20 squares: 1021.07 Mpixels/s
Benchmarking... 50x50 squares: 2315.70 Mpixels/s
Benchmarking... 100x100 squares: 2267.69 Mpixels/s
Benchmarking... 200x200 squares: 3006.28 Mpixels/s
Benchmarking... 500x500 squares: 3761.44 Mpixels/s
Benchmarking... 1000x1000 squares: 4112.49 Mpixels/s
Benchmarking... R5 circles: 269.19 Mpixels/s
Benchmarking... R10 circles: 620.77 Mpixels/s
Benchmarking... R25 circles: 1559.02 Mpixels/s
Benchmarking... R50 circles: 2027.36 Mpixels/s
Benchmarking... R100 circles: 2574.42 Mpixels/s
Benchmarking... R250 circles: 3363.28 Mpixels/s
Benchmarking... R500 circles: 3815.51 Mpixels/s
It seems that this bring a little bit performance gain.
Thanks for testing. I can't really tell why the code is now faster. All
the patch really does is to eliminate an intermediate cross-module
function call and the pointer derefs. This, apparently, already has an
impact.
Best regards
Thomas
Directly operate on video RAM is slower than have a shadow in system RAM.
I also test this patch in intel i3-8100 @ 3.6Ghz, the results show that
i915 is a bit slower.
Because it operate directly on device memory.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/geert/fbtest.git
On 2023/5/24 17:21, Thomas Zimmermann wrote:
Implement dedicated fbdev helpers for framebuffer I/O instead
of using DRM's helpers. Use an fbdev generator macro for
deferred I/O to create the callbacks. Fbdev-generic was the
only caller of the DRM helpers, so remove them from the helper
module.
v4:
* generate deferred-I/O helpers
* use initializer macros for fb_ops
v2:
* use FB_SYS_HELPERS_DEFERRED option
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/Kconfig | 6 +-
drivers/gpu/drm/drm_fb_helper.c | 107
drivers/gpu/drm/drm_fbdev_generic.c | 11 ++-
include/drm/drm_fb_helper.h | 41 ---
4 files changed, 6 insertions(+), 159 deletions(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 77fb10ddd8a2..92a782827b7b 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -95,6 +95,7 @@ config DRM_KUNIT_TEST
config DRM_KMS_HELPER
tristate
depends on DRM
+ select FB_SYS_HELPERS_DEFERRED if DRM_FBDEV_EMULATION
help
CRTC helpers for KMS drivers.
@@ -135,11 +136,6 @@ config DRM_FBDEV_EMULATION
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
- select FB_DEFERRED_IO
- select FB_SYS_FOPS
- select FB_SYS_FILLRECT
- select FB_SYS_COPYAREA
- select FB_SYS_IMAGEBLIT
select FRAMEBUFFER_CONSOLE if !EXPERT
select FRAMEBUFFER_CONSOLE_DETECT_PRIMARY if FRAMEBUFFER_CONSOLE
default y
diff --git a/drivers/gpu/drm/drm_fb_helper.c
b/drivers/gpu/drm/drm_fb_helper.c
index cb03099fd2e3..bab6b252f02a 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -736,113 +736,6 @@ void drm_fb_helper_deferred_io(struct fb_info
*info, struct list_head *pagerefli
}
EXPORT_SYMBOL(drm_fb_helper_deferred_io);
-/**
- * drm_fb_helper_sys_read - Implements struct _ops.fb_read for
system memory
- * @info: fb_info struct pointer
- * @buf: userspace buffer to read from framebuffer memory
- * @count: number of bytes to read from framebuffer memory
- * @ppos: read offset within framebuffer memory
- *
- * Returns:
- * The number of bytes read on success, or an error code otherwise.
- */
-ssize_t drm_fb_helper_sys_read(struct fb_info *info, char __user *buf,
- size_t count, loff_t *ppos)
-{
- return fb_sys_read(info, buf, count, ppos);
-}
-EXPORT_SYMBOL(drm_fb_helper_sys_read);
-
-/**
- * drm_fb_helper_sys_write - Implements struct _ops.fb_write for
system memory
- * @info: fb_info struct pointer
- * @buf: userspace buffer to write to framebuffer memory
- * @count: number of bytes to write to framebuffer memory
[PATCH] drm/i915/gt: Use the correct error value when kernel_context() fails
kernel_context() returns an error pointer. Use pointer-error
conversion functions to evaluate its return value, rather than
checking for a '0' return.
Fixes: eb5c10cbbc2f ("drm/i915: Remove I915_USER_PRIORITY_SHIFT")
Reported-by: Dan Carpenter
Signed-off-by: Andi Shyti
Cc: Chris Wilson < ch...@chris-wilson.co.uk>
Cc: # v5.13+
---
drivers/gpu/drm/i915/gt/selftest_execlists.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_execlists.c
b/drivers/gpu/drm/i915/gt/selftest_execlists.c
index 736b89a8ecf54..4202df5b8c122 100644
--- a/drivers/gpu/drm/i915/gt/selftest_execlists.c
+++ b/drivers/gpu/drm/i915/gt/selftest_execlists.c
@@ -1530,8 +1530,8 @@ static int live_busywait_preempt(void *arg)
struct drm_i915_gem_object *obj;
struct i915_vma *vma;
enum intel_engine_id id;
- int err = -ENOMEM;
u32 *map;
+ int err;
/*
* Verify that even without HAS_LOGICAL_RING_PREEMPTION, we can
@@ -1539,13 +1539,17 @@ static int live_busywait_preempt(void *arg)
*/
ctx_hi = kernel_context(gt->i915, NULL);
- if (!ctx_hi)
- return -ENOMEM;
+ if (IS_ERR(ctx_hi))
+ return PTR_ERR(ctx_hi);
+
ctx_hi->sched.priority = I915_CONTEXT_MAX_USER_PRIORITY;
ctx_lo = kernel_context(gt->i915, NULL);
- if (!ctx_lo)
+ if (IS_ERR(ctx_lo)) {
+ err = PTR_ERR(ctx_lo);
goto err_ctx_hi;
+ }
+
ctx_lo->sched.priority = I915_CONTEXT_MIN_USER_PRIORITY;
obj = i915_gem_object_create_internal(gt->i915, PAGE_SIZE);
--
2.40.1
Re: [v4,02/13] fbdev: Add initializer macros for struct fb_ops
Hi
Am 24.05.23 um 22:57 schrieb Sui Jingfeng:
Hi,
we love your patch:
On 2023/5/24 17:21, Thomas Zimmermann wrote:
For framebuffers in I/O and system memory, add macros that set
struct fb_ops to the respective callback functions.
For deferred I/O, add macros that generate callback functions with
damage handling. Add initializer macros that set struct fb_ops to
the generated callbacks.
These macros can remove a lot boilerplate code from fbdev drivers.
The drivers are supposed to use the macro that is required for its
framebuffer. Each macro is split into smaller helpers, so that
drivers with non-standard callbacks can pick and customize callbacks
as needed. There are individual helper macros for read/write, mmap
and drawing.
Signed-off-by: Thomas Zimmermann
---
include/linux/fb.h | 112 +
1 file changed, 112 insertions(+)
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 2cf8efcb9e32..731472a2bb62 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -538,9 +538,31 @@ extern ssize_t fb_io_read(struct fb_info *info,
char __user *buf,
extern ssize_t fb_io_write(struct fb_info *info, const char __user
*buf,
size_t count, loff_t *ppos);
+/*
+ * Initializes struct fb_ops for framebuffers in I/O memory.
+ */
+
+#define __FB_DEFAULT_IO_OPS_RDWR \
+ .fb_read = fb_io_read, \
+ .fb_write = fb_io_write
+
+#define __FB_DEFAULT_IO_OPS_DRAW \
+ .fb_fillrect = cfb_fillrect, \
+ .fb_copyarea = cfb_copyarea, \
+ .fb_imageblit = cfb_imageblit
Here, it seems that your text editor replace the tap with space, but
I'm OK.
I'm asking because I see other __FB__DEFAULT_* macro begin with tabs.
Yeah, these are mistakes. I'll fix that with the next version.
Best regards
Thomas
+#define __FB_DEFAULT_IO_OPS_MMAP \
+ .fb_mmap = NULL // default implementation
+
+#define FB_DEFAULT_IO_OPS \
+ __FB_DEFAULT_IO_OPS_RDWR, \
+ __FB_DEFAULT_IO_OPS_DRAW, \
+ __FB_DEFAULT_IO_OPS_MMAP
+
/*
* Drawing operations where framebuffer is in system RAM
*/
+
extern void sys_fillrect(struct fb_info *info, const struct
fb_fillrect *rect);
extern void sys_copyarea(struct fb_info *info, const struct
fb_copyarea *area);
extern void sys_imageblit(struct fb_info *info, const struct
fb_image *image);
@@ -549,6 +571,27 @@ extern ssize_t fb_sys_read(struct fb_info *info,
char __user *buf,
extern ssize_t fb_sys_write(struct fb_info *info, const char __user
*buf,
size_t count, loff_t *ppos);
+/*
+ * Initializes struct fb_ops for framebuffers in system memory.
+ */
+
+#define __FB_DEFAULT_SYS_OPS_RDWR \
+ .fb_read = fb_sys_read, \
+ .fb_write = fb_sys_write
+
+#define __FB_DEFAULT_SYS_OPS_DRAW \
+ .fb_fillrect = sys_fillrect, \
+ .fb_copyarea = sys_copyarea, \
+ .fb_imageblit = sys_imageblit
+
+#define __FB_DEFAULT_SYS_OPS_MMAP \
+ .fb_mmap = NULL // default implementation
+
+#define FB_DEFAULT_SYS_OPS \
+ __FB_DEFAULT_SYS_OPS_RDWR, \
+ __FB_DEFAULT_SYS_OPS_DRAW, \
+ __FB_DEFAULT_SYS_OPS_MMAP
+
/* drivers/video/fbmem.c */
extern int register_framebuffer(struct fb_info *fb_info);
extern void unregister_framebuffer(struct fb_info *fb_info);
@@ -604,6 +647,75 @@ extern void fb_deferred_io_cleanup(struct fb_info
*info);
extern int fb_deferred_io_fsync(struct file *file, loff_t start,
loff_t end, int datasync);
+/*
+ * Generate callbacks for deferred I/O
+ */
+
+#define __FB_GEN_DEFAULT_DEFERRED_OPS_RDWR(__prefix, __damage_range,
__mode) \
+ static ssize_t __prefix ## _defio_read(struct fb_info *info, char
__user *buf, \
+ size_t count, loff_t *ppos) \
+ { \
+ return fb_ ## __mode ## _read(info, buf, count, ppos); \
+ } \
+ static ssize_t __prefix ## _defio_write(struct fb_info *info,
const char __user *buf, \
+ size_t count, loff_t *ppos) \
+ { \
+ unsigned long offset = *ppos; \
+ ssize_t ret = fb_ ## __mode ## _write(info, buf, count, ppos); \
+ if (ret > 0) \
+ __damage_range(info, offset, ret); \
+ return ret; \
+ }
+
+#define __FB_GEN_DEFAULT_DEFERRED_OPS_DRAW(__prefix, __damage_area,
__mode) \
+ static void __prefix ## _defio_fillrect(struct fb_info *info, \
+ const struct fb_fillrect *rect) \
+ { \
+ __mode ## _fillrect(info, rect); \
+ __damage_area(info, rect->dx, rect->dy, rect->width,
rect->height); \
+ } \
+ static void __prefix ## _defio_copyarea(struct fb_info *info, \
+ const struct fb_copyarea *area) \
+ { \
+ __mode ## _copyarea(info, area); \
+ __damage_area(info, area->dx, area->dy, area->width,
area->height); \
+ } \
+ static void __prefix ## _defio_imageblit(struct fb_info *info, \
+ const struct fb_image *image) \
+ { \
+
Re: [PATCH v2] drm: Switch i2c drivers back to use .probe()
On Fri, May 26, 2023 at 2:08 AM Uwe Kleine-König
wrote:
>
> After commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new()
> call-back type"), all drivers being converted to .probe_new() and then
> 03c835f498b5 ("i2c: Switch .probe() to not take an id parameter") convert
> back to (the new) .probe() to be able to eventually drop .probe_new() from
> struct i2c_driver.
>
> Signed-off-by: Uwe Kleine-König
FWIW:
Reviewed-by: Guenter Roeck
> ---
> Hello,
>
> I didn't get feedback for (implicit) v1 that was sent with Message-Id:
> <20230427175954.666464-1-u.kleine-koe...@pengutronix.de>. This is a
> rebase on v6.4-rc1 as the former patch doesn't apply cleanly any more.
>
> I also added more people to Cc, maybe that helps to get feedback.
>
> This patch is based on v6.4-rc1, and applies fine on today's next.
> (There are also no new drivers that need adaption in next.)
>
> Thanks for considering,
> Uwe
>
> drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 2 +-
> drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 2 +-
> drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c | 2 +-
> drivers/gpu/drm/bridge/analogix/anx7625.c| 2 +-
> drivers/gpu/drm/bridge/chipone-icn6211.c | 2 +-
> drivers/gpu/drm/bridge/chrontel-ch7033.c | 2 +-
> drivers/gpu/drm/bridge/cros-ec-anx7688.c | 2 +-
> drivers/gpu/drm/bridge/ite-it6505.c | 2 +-
> drivers/gpu/drm/bridge/ite-it66121.c | 2 +-
> drivers/gpu/drm/bridge/lontium-lt8912b.c | 2 +-
> drivers/gpu/drm/bridge/lontium-lt9211.c | 2 +-
> drivers/gpu/drm/bridge/lontium-lt9611.c | 2 +-
> drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 2 +-
> drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c | 4 ++--
> drivers/gpu/drm/bridge/nxp-ptn3460.c | 2 +-
> drivers/gpu/drm/bridge/parade-ps8622.c | 2 +-
> drivers/gpu/drm/bridge/parade-ps8640.c | 2 +-
> drivers/gpu/drm/bridge/sii902x.c | 2 +-
> drivers/gpu/drm/bridge/sii9234.c | 2 +-
> drivers/gpu/drm/bridge/sil-sii8620.c | 2 +-
> drivers/gpu/drm/bridge/tc358767.c| 2 +-
> drivers/gpu/drm/bridge/tc358768.c| 2 +-
> drivers/gpu/drm/bridge/tc358775.c| 2 +-
> drivers/gpu/drm/bridge/ti-dlpc3433.c | 2 +-
> drivers/gpu/drm/bridge/ti-sn65dsi83.c| 2 +-
> drivers/gpu/drm/bridge/ti-sn65dsi86.c| 2 +-
> drivers/gpu/drm/bridge/ti-tfp410.c | 2 +-
> drivers/gpu/drm/i2c/tda9950.c| 2 +-
> drivers/gpu/drm/i2c/tda998x_drv.c| 2 +-
> drivers/gpu/drm/panel/panel-olimex-lcd-olinuxino.c | 2 +-
> drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c| 2 +-
> drivers/gpu/drm/solomon/ssd130x-i2c.c| 2 +-
> 32 files changed, 33 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> index ddceafa7b637..2254457ab5d0 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> @@ -1393,7 +1393,7 @@ static struct i2c_driver adv7511_driver = {
> .of_match_table = adv7511_of_ids,
> },
> .id_table = adv7511_i2c_ids,
> - .probe_new = adv7511_probe,
> + .probe = adv7511_probe,
> .remove = adv7511_remove,
> };
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> index 3577c532abb4..72ab2ab77081 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> @@ -815,7 +815,7 @@ static struct i2c_driver anx6345_driver = {
>.name = "anx6345",
>.of_match_table = of_match_ptr(anx6345_match_table),
> },
> - .probe_new = anx6345_i2c_probe,
> + .probe = anx6345_i2c_probe,
> .remove = anx6345_i2c_remove,
> .id_table = anx6345_id,
> };
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> index a3a38bbe2786..06a3e3243e19 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> @@ -1389,7 +1389,7 @@ static struct i2c_driver anx78xx_driver = {
>.name = "anx7814",
>.of_match_table = of_match_ptr(anx78xx_match_table),
> },
> - .probe_new = anx78xx_i2c_probe,
> + .probe = anx78xx_i2c_probe,
> .remove = anx78xx_i2c_remove,
> .id_table = anx78xx_id,
> };
> diff --git
Re: [PATCH v3 11/13] drm/fb-helper: Fix single-probe color-format selection
[TLDR: This mail in primarily relevant for Linux regression tracking. A change or fix related to the regression discussed in this thread was posted or applied, but it did not use a Link: tag to point to the report, as Linus and the documentation call for. Things happen, no worries -- but now the regression tracking bot needs to be told manually about the fix. See link in footer if these mails annoy you.] On 14.05.23 14:10, Linux regression tracking #adding (Thorsten Leemhuis) wrote: > On 12.05.23 15:20, Linus Walleij wrote: >> Sorry for late regression detection but this patch regresses >> the Integrator AB IMPD-1 graphics, I bisected down to this >> patch. > > #regzbot ^introduced 37c90d589dc > #regzbot title drm/fb-helper: downscaling apparently stopped to work > with pl110_impd1 > #regzbot ignore-activity #regzbot monitor: https://lore.kernel.org/all/20230515092943.1401558-1-linus.wall...@linaro.org/ #regzbot fix: drm/pl111: Fix FB depth on IMPD-1 framebuffer #regzbot ignore-activity Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) -- Everything you wanna know about Linux kernel regression tracking: https://linux-regtracking.leemhuis.info/about/#tldr That page also explains what to do if mails like this annoy you.
Re: [PATCH 2/2] dt-bindings: backlight: document new property default-brightness-level
On 5/19/23 22:05, Alexandru Ardelean wrote: From: Yannick Fertre Add documentation for new default-brightness-level property. Reviewed-by: Philippe CORNU Hi Alexandru, same comments as for the 1/2 patch. Many thanks Philippe :-) Signed-off-by: Yannick Fertre Signed-off-by: Alexandru Ardelean --- Link to original patch: https://github.com/STMicroelectronics/linux/commit/c4067d7bd883c6fa14ffd49892c4ce663cdafe98 .../bindings/leds/backlight/gpio-backlight.yaml | 9 + 1 file changed, 9 insertions(+) diff --git a/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml b/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml index 584030b6b0b9..b96c08cff0f0 100644 --- a/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml +++ b/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml @@ -23,6 +23,15 @@ properties: description: enable the backlight at boot. type: boolean + default-brightness-level: +description: + The default brightness level (index into the array defined by the + "brightness-levels" property). +$ref: /schemas/types.yaml#/definitions/uint32 + +dependencies: + default-brightness-level: [ "brightness-levels" ] + required: - compatible - gpios
Re: [v10] media: mediatek: vcodec: support stateless AV1 decoder
On 14/04/2023 10:30, Xiaoyong Lu wrote: > Add mediatek av1 decoder linux driver which use the stateless API in > MT8195. > > Signed-off-by: Xiaoyong Lu > Tested-by: Nicolas Dufresne > Reviewed-by: Nicolas Dufresne > Tested-by: AngeloGioacchino Del Regno > > Reviewed-by: AngeloGioacchino Del Regno > After rebasing on top of our media staging tree I get these compile errors: CC [M] drivers/media/platform/mediatek/vcodec/vdec/vdec_av1_req_lat_if.o drivers/media/platform/mediatek/vcodec/vdec/vdec_av1_req_lat_if.c: In function ‘vdec_av1_slice_lat_decode’: drivers/media/platform/mediatek/vcodec/vdec/vdec_av1_req_lat_if.c:2075:46: error: ‘struct mtk_vcodec_dev’ has no member named ‘msg_queue_core_ctx’ 2075 | vdec_msg_queue_qbuf(>dev->msg_queue_core_ctx, lat_buf); | ^~ drivers/media/platform/mediatek/vcodec/vdec/vdec_av1_req_lat_if.c:2114:46: error: ‘struct mtk_vcodec_dev’ has no member named ‘msg_queue_core_ctx’ 2114 | vdec_msg_queue_qbuf(>dev->msg_queue_core_ctx, lat_buf); | ^~ That's due to the patch "media: mediatek: vcodec: move core context from device to each instance" that has now been merged and that drops that queue. Can you rebase v10? This is now the only remaining blocked for the av1 series to be merged. Regards, Hans
Re: [PATCH 1/2] backlight: gpio_backlight: add new property default-brightness-level
On 5/19/23 22:05, Alexandru Ardelean wrote: From: Yannick Fertre Add new property to set a brightness by default at probe. Reviewed-by: Philippe CORNU Hi Alexandru, Many thanks for your patch. You have sent a patch originally pushed on the STMicroelectronics github as mentioned in your commit message (no problem with that :-). But, the "Reviewed-by" inside this github patch is linked to our gerrit STM internal server so you can not use it directly for mainlining this patch. So please, re-send your this patch without my "Reviewed-by". Many thanks Philippe :-) Signed-off-by: Yannick Fertre Signed-off-by: Alexandru Ardelean --- Link to original patch: https://github.com/STMicroelectronics/linux/commit/c4067d7bd883c6fa14ffd49892c4ce663cdafe98 drivers/video/backlight/gpio_backlight.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/video/backlight/gpio_backlight.c b/drivers/video/backlight/gpio_backlight.c index 6f78d928f054..d3fa3a8bef4d 100644 --- a/drivers/video/backlight/gpio_backlight.c +++ b/drivers/video/backlight/gpio_backlight.c @@ -53,6 +53,7 @@ static int gpio_backlight_probe(struct platform_device *pdev) struct backlight_device *bl; struct gpio_backlight *gbl; int ret, init_brightness, def_value; + u32 value; gbl = devm_kzalloc(dev, sizeof(*gbl), GFP_KERNEL); if (gbl == NULL) @@ -93,7 +94,11 @@ static int gpio_backlight_probe(struct platform_device *pdev) else bl->props.power = FB_BLANK_UNBLANK; - bl->props.brightness = 1; + ret = device_property_read_u32(dev, "default-brightness-level", ); + if (!ret && value <= props.max_brightness) + bl->props.brightness = value; + else + bl->props.brightness = 1; init_brightness = backlight_get_brightness(bl); ret = gpiod_direction_output(gbl->gpiod, init_brightness);
[bug report] vga_switcheroo: set audio client id according to bound GPU id
Hello Jim Qu,
The patch 4aaf448fa975: "vga_switcheroo: set audio client id
according to bound GPU id" from Jul 17, 2018, leads to the following
Smatch static checker warning:
drivers/gpu/vga/vga_switcheroo.c:378
vga_switcheroo_register_audio_client()
warn: impossible condition '(id < 0) => (0-u32max < 0)'
drivers/gpu/vga/vga_switcheroo.c
362 int vga_switcheroo_register_audio_client(struct pci_dev *pdev,
363 const struct vga_switcheroo_client_ops *ops,
364 struct pci_dev *vga_dev)
365 {
366 enum vga_switcheroo_client_id id = VGA_SWITCHEROO_UNKNOWN_ID;
367
368 /*
369 * if vga_switcheroo has enabled, that mean two GPU clients and
also
370 * handler are registered. Get audio client id from bound GPU
client
371 * id directly, otherwise, set it as VGA_SWITCHEROO_UNKNOWN_ID,
372 * it will set to correct id in later when
vga_switcheroo_enable()
373 * is called.
374 */
375 mutex_lock(_mutex);
376 if (vgasr_priv.active) {
377 id = vgasr_priv.handler->get_client_id(vga_dev);
378 if (id < 0) {
The vga_switcheroo_client_id enum is treated as unsigned in this context.
379 mutex_unlock(_mutex);
380 return -EINVAL;
381 }
382 /* notify if GPU has been already bound */
383 if (ops->gpu_bound)
384 ops->gpu_bound(pdev, id);
385 }
386 mutex_unlock(_mutex);
387
388 return register_client(pdev, ops, id | ID_BIT_AUDIO, vga_dev,
389 false, true);
390 }
regards,
dan carpenter
[PATCH v2] drm/msm/dpu: clean up dpu_kms_get_clk_rate() returns
Static analysis tools complain about the -EINVAL error code being
stored in an unsigned variable. Let's change this to match
the clk_get_rate() function which is type unsigned long and returns
zero on error.
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Signed-off-by: Dan Carpenter
---
v2: In v1 I change the type to int which was wrong. This is a different
approach. CC the freedreno list this time too.
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 4 ++--
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 0e7a68714e9e..25e6a15eaf9f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -979,13 +979,13 @@ static int _dpu_kms_mmu_init(struct dpu_kms *dpu_kms)
return 0;
}
-u64 dpu_kms_get_clk_rate(struct dpu_kms *dpu_kms, char *clock_name)
+unsigned long dpu_kms_get_clk_rate(struct dpu_kms *dpu_kms, char *clock_name)
{
struct clk *clk;
clk = msm_clk_bulk_get_clock(dpu_kms->clocks, dpu_kms->num_clocks,
clock_name);
if (!clk)
- return -EINVAL;
+ return 0;
return clk_get_rate(clk);
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
index aca39a4689f4..961918e5a5b3 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
@@ -201,6 +201,6 @@ void dpu_disable_vblank(struct msm_kms *kms, struct
drm_crtc *crtc);
*
* Return: current clock rate
*/
-u64 dpu_kms_get_clk_rate(struct dpu_kms *dpu_kms, char *clock_name);
+unsigned long dpu_kms_get_clk_rate(struct dpu_kms *dpu_kms, char *clock_name);
#endif /* __dpu_kms_H__ */
--
2.39.2
Re: [PATCH RESEND] drm/stm: ltdc: fix late dereference check
On 5/15/23 14:38, Raphael Gallais-Pou wrote:
In ltdc_crtc_set_crc_source(), struct drm_crtc was dereferenced in a
container_of() before the pointer check. This could cause a kernel panic.
Fix this smatch warning:
drivers/gpu/drm/stm/ltdc.c:1124 ltdc_crtc_set_crc_source() warn: variable
dereferenced before check 'crtc' (see line 1119)
Reported-by: kernel test robot
Reported-by: Dan Carpenter
Link: https://lore.kernel.org/lkml/202212241802.zelfzcxb-...@intel.com/
Signed-off-by: Raphael Gallais-Pou
---
drivers/gpu/drm/stm/ltdc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index 03c6becda795..b8be4c1db423 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -1145,7 +1145,7 @@ static void ltdc_crtc_disable_vblank(struct drm_crtc
*crtc)
static int ltdc_crtc_set_crc_source(struct drm_crtc *crtc, const char *source)
{
- struct ltdc_device *ldev = crtc_to_ltdc(crtc);
+ struct ltdc_device *ldev;
int ret;
DRM_DEBUG_DRIVER("\n");
@@ -1153,6 +1153,8 @@ static int ltdc_crtc_set_crc_source(struct drm_crtc
*crtc, const char *source)
if (!crtc)
return -ENODEV;
+ ldev = crtc_to_ltdc(crtc);
+
if (source && strcmp(source, "auto") == 0) {
ldev->crc_active = true;
ret = regmap_set_bits(ldev->regmap, LTDC_GCR, GCR_CRCEN);
Hi Raphael,
Applied on drm-misc-next.
Note & fyi, I fixed the following warning, please be sure to follow this
rule next time :-)
WARNING:BAD_REPORTED_BY_LINK: Reported-by: should be immediately
followed by Closes: with a URL to the report
Many thanks for your patch,
Philippe :-)
Re: [PATCH -next] drm/stm: dsi: Use devm_platform_ioremap_resource()
On 4/21/23 10:34, Yang Li wrote:
Convert platform_get_resource(),devm_ioremap_resource() to a single call
to devm_platform_ioremap_resource(), as this is exactly what this function
does.
Signed-off-by: Yang Li
---
drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
index 89897d5f5c72..1750b6a25e87 100644
--- a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
+++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
@@ -444,15 +444,13 @@ static int dw_mipi_dsi_stm_probe(struct platform_device
*pdev)
struct device *dev = >dev;
struct dw_mipi_dsi_stm *dsi;
struct clk *pclk;
- struct resource *res;
int ret;
dsi = devm_kzalloc(dev, sizeof(*dsi), GFP_KERNEL);
if (!dsi)
return -ENOMEM;
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- dsi->base = devm_ioremap_resource(dev, res);
+ dsi->base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(dsi->base)) {
ret = PTR_ERR(dsi->base);
DRM_ERROR("Unable to get dsi registers %d\n", ret);
Applied on drm-misc-next.
Many thanks for your patch,
Philippe :-)
Re: [RFC PATCH] dma-buf/dma-fence: Use a successful read_trylock() annotation for dma_fence_begin_signalling()
Daniel, On 4/28/23 14:52, Thomas Hellström wrote: Condsider the following call sequence: /* Upper layer */ dma_fence_begin_signalling(); lock(tainted_shared_lock); /* Driver callback */ dma_fence_begin_signalling(); ... The driver might here use a utility that is annotated as intended for the dma-fence signalling critical path. Now if the upper layer isn't correctly annotated yet for whatever reason, resulting in /* Upper layer */ lock(tainted_shared_lock); /* Driver callback */ dma_fence_begin_signalling(); We will receive a false lockdep locking order violation notification from dma_fence_begin_signalling(). However entering a dma-fence signalling critical section itself doesn't block and could not cause a deadlock. So use a successful read_trylock() annotation instead for dma_fence_begin_signalling(). That will make sure that the locking order is correctly registered in the first case, and doesn't register any locking order in the second case. The alternative is of course to make sure that the "Upper layer" is always correctly annotated. But experience shows that's not easily achievable in all cases. Signed-off-by: Thomas Hellström Resurrecting the discussion on this one. I can't see a situation where we would miss *relevant* locking order violation warnings with this patch. Ofc if we have a scheduler annotation patch that would work fine as well, but the lack of annotation in the scheduler callbacks is really starting to hurt us. Thanks, Thomas --- drivers/dma-buf/dma-fence.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c index f177c56269bb..17f632768ef9 100644 --- a/drivers/dma-buf/dma-fence.c +++ b/drivers/dma-buf/dma-fence.c @@ -308,8 +308,8 @@ bool dma_fence_begin_signalling(void) if (in_atomic()) return true; - /* ... and non-recursive readlock */ - lock_acquire(_fence_lockdep_map, 0, 0, 1, 1, NULL, _RET_IP_); + /* ... and non-recursive successful read_trylock */ + lock_acquire(_fence_lockdep_map, 0, 1, 1, 1, NULL, _RET_IP_); return false; } @@ -340,7 +340,7 @@ void __dma_fence_might_wait(void) lock_map_acquire(_fence_lockdep_map); lock_map_release(_fence_lockdep_map); if (tmp) - lock_acquire(_fence_lockdep_map, 0, 0, 1, 1, NULL, _THIS_IP_); + lock_acquire(_fence_lockdep_map, 0, 1, 1, 1, NULL, _THIS_IP_); } #endif
Re: [Intel-gfx] [PATCH v2 6/7] drm/i915: No 10bit gamma on desktop gen3 parts
On Thu, 25 May 2023, "Shankar, Uma" wrote:
>> -Original Message-
>> From: Intel-gfx On Behalf Of Ville
>> Syrjala
>> Sent: Thursday, April 13, 2023 10:19 PM
>> To: intel-...@lists.freedesktop.org
>> Cc: dri-devel@lists.freedesktop.org
>> Subject: [Intel-gfx] [PATCH v2 6/7] drm/i915: No 10bit gamma on desktop gen3
>> parts
>>
>> From: Ville Syrjälä
>>
>> Apparently desktop gen3 parts don't support the 10bit gamma mode at all. Stop
>> claiming otherwise.
>>
>> As is the case with pipe A on gen3 mobile parts, the PIPECONF gamma mode bit
>> can
>> be set but it has no effect on the output.
>>
>> PNV seems to be the only slight exception, but generally the desktop PNV
>> variant
>> looks more like a mobile part so this is not entirely surprising.
>
> Couldn't check the relevant spec to re-confirm, trusting your judgment here.
> Reviewed-by: Uma Shankar
This needs a rebase on display/intel_display_device.[ch] stuff.
BR,
Jani.
>
>> Fixes: 67630bacae23 ("drm/i915: Add 10bit gamma mode for gen2/3")
>> Signed-off-by: Ville Syrjälä
>> ---
>> drivers/gpu/drm/i915/i915_pci.c | 8 +++-
>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_pci.c
>> b/drivers/gpu/drm/i915/i915_pci.c index
>> cddb6e197972..305c05c3f93b 100644
>> --- a/drivers/gpu/drm/i915/i915_pci.c
>> +++ b/drivers/gpu/drm/i915/i915_pci.c
>> @@ -250,13 +250,13 @@ static const struct intel_device_info i865g_info = {
>> .dma_mask_size = 32, \
>> I9XX_PIPE_OFFSETS, \
>> I9XX_CURSOR_OFFSETS, \
>> -I9XX_COLORS, \
>> GEN_DEFAULT_PAGE_SIZES, \
>> GEN_DEFAULT_REGIONS
>>
>> static const struct intel_device_info i915g_info = {
>> GEN3_FEATURES,
>> PLATFORM(INTEL_I915G),
>> +I845_COLORS,
>> .has_coherent_ggtt = false,
>> .display.cursor_needs_physical = 1,
>> .display.has_overlay = 1,
>> @@ -268,6 +268,7 @@ static const struct intel_device_info i915g_info = {
>> static
>> const struct intel_device_info i915gm_info = {
>> GEN3_FEATURES,
>> PLATFORM(INTEL_I915GM),
>> +I9XX_COLORS,
>> .is_mobile = 1,
>> .display.cursor_needs_physical = 1,
>> .display.has_overlay = 1,
>> @@ -281,6 +282,7 @@ static const struct intel_device_info i915gm_info = {
>> static
>> const struct intel_device_info i945g_info = {
>> GEN3_FEATURES,
>> PLATFORM(INTEL_I945G),
>> +I845_COLORS,
>> .display.has_hotplug = 1,
>> .display.cursor_needs_physical = 1,
>> .display.has_overlay = 1,
>> @@ -292,6 +294,7 @@ static const struct intel_device_info i945g_info = {
>> static
>> const struct intel_device_info i945gm_info = {
>> GEN3_FEATURES,
>> PLATFORM(INTEL_I945GM),
>> +I9XX_COLORS,
>> .is_mobile = 1,
>> .display.has_hotplug = 1,
>> .display.cursor_needs_physical = 1,
>> @@ -306,6 +309,7 @@ static const struct intel_device_info i945gm_info = {
>> static
>> const struct intel_device_info g33_info = {
>> GEN3_FEATURES,
>> PLATFORM(INTEL_G33),
>> +I845_COLORS,
>> .display.has_hotplug = 1,
>> .display.has_overlay = 1,
>> .dma_mask_size = 36,
>> @@ -314,6 +318,7 @@ static const struct intel_device_info g33_info = {
>> static
>> const struct intel_device_info pnv_g_info = {
>> GEN3_FEATURES,
>> PLATFORM(INTEL_PINEVIEW),
>> +I9XX_COLORS,
>> .display.has_hotplug = 1,
>> .display.has_overlay = 1,
>> .dma_mask_size = 36,
>> @@ -322,6 +327,7 @@ static const struct intel_device_info pnv_g_info = {
>> static
>> const struct intel_device_info pnv_m_info = {
>> GEN3_FEATURES,
>> PLATFORM(INTEL_PINEVIEW),
>> +I9XX_COLORS,
>> .is_mobile = 1,
>> .display.has_hotplug = 1,
>> .display.has_overlay = 1,
>> --
>> 2.39.2
>
--
Jani Nikula, Intel Open Source Graphics Center
Re: [PATCH 2/4] drm/msm: add hdmi cec support
Hi Arnaud, My apologies for the long delay in replying, it's been very, very busy lately. I hope I'll be able to be more responsive going forward. On 21/04/2023 18:58, Arnaud Vrac wrote: > Le ven. 21 avr. 2023 à 15:27, Hans Verkuil a écrit > : >> >> Hi Arnaud, >> >> Some review comments below... > > Hi Hans, > > For context, I first based my work on the fbdev driver from Qualcomm a > few years ago, on our own CEC framework which does not implement any > CEC protocol logic (as android does). At the time I verified that the > messages were matching the electrical and protocol spec, using manual > tests and a QD882EA analyzer. I also passed HDMI and CEC certs. > > I simply ported this work more recently to a newer kernel and the > media-cec framework, also checking the port that Qualcomm did later > on. > >> On 4/18/23 20:10, Arnaud Vrac wrote: >>> Some Qualcomm SoCs that support HDMI also support CEC, including MSM8996 >>> and MSM8998. The hardware block can handle a single CEC logical address >>> and broadcast messages. >>> >>> Port the CEC driver from downstream msm-4.4 kernel. It has been tested >>> on MSM8998 and passes the cec-compliance tool tests. >> >> Just to verify: did you run the cec-compliance --test-adapter test? That's >> the important one to verify your own driver. > > Yes, and I also ran the cec-compliance -r 0 with a pulse8 emulating a > tv on the bus. Here's the result of cec-compliance --test-adapter: > > Find remote devices: > Polling: OK > > CEC API: > CEC_ADAP_G_CAPS: OK > Invalid ioctls: OK > CEC_DQEVENT: OK > CEC_ADAP_G/S_PHYS_ADDR: OK > CEC_ADAP_G/S_LOG_ADDRS: OK > CEC_TRANSMIT: OK > CEC_RECEIVE: OK > CEC_TRANSMIT/RECEIVE (non-blocking): OK (Presumed) > CEC_G/S_MODE: OK > warn: cec-test-adapter.cpp(1189): Too many transmits (3) > without receives > SFTs for repeating messages (>= 7): 7: 38, 8: 2 > SFTs for newly transmitted messages (>= 5): 6: 2, 7: 17 > SFTs for newly transmitted remote messages (>= 5): 6: 20 > CEC_EVENT_LOST_MSGS: OK > > Network topology: > [...] > > Total for hdmi_msm device /dev/cec0: 11, Succeeded: 11, Failed: 0, Warnings: 1 > >> >>> >>> Signed-off-by: Arnaud Vrac >>> --- >>> drivers/gpu/drm/msm/Kconfig | 8 ++ >>> drivers/gpu/drm/msm/Makefile| 1 + >>> drivers/gpu/drm/msm/hdmi/hdmi.c | 15 ++ >>> drivers/gpu/drm/msm/hdmi/hdmi.h | 18 +++ >>> drivers/gpu/drm/msm/hdmi/hdmi_cec.c | 280 >>> >>> 5 files changed, 322 insertions(+) >>> >>> diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig >>> index 85f5ab1d552c4..2a02c74207935 100644 >>> --- a/drivers/gpu/drm/msm/Kconfig >>> +++ b/drivers/gpu/drm/msm/Kconfig >>> @@ -165,3 +165,11 @@ config DRM_MSM_HDMI_HDCP >>> default y >>> help >>> Choose this option to enable HDCP state machine >>> + >>> +config DRM_MSM_HDMI_CEC >>> + bool "Enable HDMI CEC support in MSM DRM driver" >>> + depends on DRM_MSM && DRM_MSM_HDMI >>> + select CEC_CORE >>> + default y >>> + help >>> + Choose this option to enable CEC support >>> diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile >>> index 7274c41228ed9..0237a2f219ac2 100644 >>> --- a/drivers/gpu/drm/msm/Makefile >>> +++ b/drivers/gpu/drm/msm/Makefile >>> @@ -131,6 +131,7 @@ msm-$(CONFIG_DRM_MSM_DP)+= dp/dp_aux.o \ >>> >>> msm-$(CONFIG_DRM_FBDEV_EMULATION) += msm_fbdev.o >>> >>> +msm-$(CONFIG_DRM_MSM_HDMI_CEC) += hdmi/hdmi_cec.o >>> msm-$(CONFIG_DRM_MSM_HDMI_HDCP) += hdmi/hdmi_hdcp.o >>> >>> msm-$(CONFIG_DRM_MSM_DSI) += dsi/dsi.o \ >>> diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c >>> b/drivers/gpu/drm/msm/hdmi/hdmi.c >>> index 3132105a2a433..1dde3890e25c0 100644 >>> --- a/drivers/gpu/drm/msm/hdmi/hdmi.c >>> +++ b/drivers/gpu/drm/msm/hdmi/hdmi.c >>> @@ -11,6 +11,8 @@ >>> #include >>> #include >>> >>> +#include >>> + >>> #include >>> #include "hdmi.h" >>> >>> @@ -53,6 +55,9 @@ static irqreturn_t msm_hdmi_irq(int irq, void *dev_id) >>> if (hdmi->hdcp_ctrl) >>> msm_hdmi_hdcp_irq(hdmi->hdcp_ctrl); >>> >>> + /* Process CEC: */ >>> + msm_hdmi_cec_irq(hdmi); >>> + >>> /* TODO audio.. */ >>> >>> return IRQ_HANDLED; >>> @@ -66,6 +71,8 @@ static void msm_hdmi_destroy(struct hdmi *hdmi) >>>*/ >>> if (hdmi->workq) >>> destroy_workqueue(hdmi->workq); >>> + >>> + msm_hdmi_cec_exit(hdmi); >>> msm_hdmi_hdcp_destroy(hdmi); >>> >>> if (hdmi->i2c) >>> @@ -139,6 +146,8 @@ static int msm_hdmi_init(struct hdmi *hdmi) >>> hdmi->hdcp_ctrl = NULL; >>> } >>> >>> + msm_hdmi_cec_init(hdmi); >>> + >>> return 0; >>> >>> fail: >>> @@ -198,6 +207,12 @@ int msm_hdmi_modeset_init(struct hdmi *hdmi, >>> >>> drm_connector_attach_encoder(hdmi->connector, hdmi->encoder); >>> >>> +
Re: [PATCH v2 4/4] arm64: dts: adapt to LP855X bindings changes
On Fri, May 19, 2023 at 08:07:28PM +0200, Artur Weber wrote: > Change underscores in ROM node names to dashes, and remove deprecated > pwm-period property. > > Signed-off-by: Artur Weber Reviewed-by: Daniel Thompson
Re: [PATCH v2 2/4] video: backlight: lp855x: get PWM for PWM mode during probe
On Fri, May 19, 2023 at 08:07:26PM +0200, Artur Weber wrote: > Also deprecate the pwm-period DT property, as it is now redundant > (pwms property already contains period value). > > Signed-off-by: Artur Weber Reviewed-by: Daniel Thompson
Re: [PATCH v2 1/4] dt-bindings: backlight: lp855x: convert to YAML and modernize
On Fri, May 19, 2023 at 08:07:25PM +0200, Artur Weber wrote: > Notable changes: > - ROM child nodes use dashes instead of underscores; the driver > reads all child nodes regardless of their names, so this doesn't > break ABI. > - pwm-period argument is deprecated, as it effectively duplicates > the period value provided in pwms. The driver continues to accept > the property, so this should not break ABI. > > Signed-off-by: Artur Weber > Reviewed-by: Rob Herring Reviewed-by: Daniel Thompson
Re: [PATCH 1/2] backlight: gpio_backlight: add new property default-brightness-level
On Fri, May 19, 2023 at 11:05:19PM +0300, Alexandru Ardelean wrote: > From: Yannick Fertre > > Add new property to set a brightness by default at probe. > > Reviewed-by: Philippe CORNU > Signed-off-by: Yannick Fertre > Signed-off-by: Alexandru Ardelean Patch order should be reversed for v2. Nevertheless: Reviewed-by: Daniel Thompson Daniel. > struct backlight_device *bl; > struct gpio_backlight *gbl; > int ret, init_brightness, def_value; > + u32 value; > > gbl = devm_kzalloc(dev, sizeof(*gbl), GFP_KERNEL); > if (gbl == NULL) > @@ -93,7 +94,11 @@ static int gpio_backlight_probe(struct platform_device > *pdev) > else > bl->props.power = FB_BLANK_UNBLANK; > > - bl->props.brightness = 1; > + ret = device_property_read_u32(dev, "default-brightness-level", ); > + if (!ret && value <= props.max_brightness) > + bl->props.brightness = value; > + else > + bl->props.brightness = 1; > > init_brightness = backlight_get_brightness(bl); > ret = gpiod_direction_output(gbl->gpiod, init_brightness); > -- > 2.40.1 >
Re: [PATCH 2/2] dt-bindings: backlight: document new property default-brightness-level
On Fri, May 19, 2023 at 11:05:20PM +0300, Alexandru Ardelean wrote: > From: Yannick Fertre > > Add documentation for new default-brightness-level property. > > Reviewed-by: Philippe CORNU > Signed-off-by: Yannick Fertre > Signed-off-by: Alexandru Ardelean > --- > > Link to original patch: > > https://github.com/STMicroelectronics/linux/commit/c4067d7bd883c6fa14ffd49892c4ce663cdafe98 > > .../bindings/leds/backlight/gpio-backlight.yaml | 9 + > 1 file changed, 9 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml > b/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml > index 584030b6b0b9..b96c08cff0f0 100644 > --- a/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml > +++ b/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml > @@ -23,6 +23,15 @@ properties: > description: enable the backlight at boot. > type: boolean > > + default-brightness-level: > +description: > + The default brightness level (index into the array defined by the > + "brightness-levels" property). gpio-backlight does not have a brightness-levels array property! I think it is also necessary to improve the docs of both properties to distinguish between the meaning of default-on and default-brightness-level. The result of setting default-on and default-brightness level to zero is that the GPIO will be off (this is correct behaviour but hard to figure out from the current text). default-on is a control that can "enable" the backlight at boot when it is not linked to a display in the DT (e.g. it is mostly for legacy cases). When the backlight is linked to a display then the backlight enable state will be automatically linked to the display enable state instead. default-brightness-level is useful for handling displays that are still readable with the backlight off (e-ink, reflective/ transflexive LCD, etc), otherwise is should be absent or set to 1. > +$ref: /schemas/types.yaml#/definitions/uint32 > + > +dependencies: > + default-brightness-level: [ "brightness-levels" ] As above, depending on brightness-levels doesn't make any sense here. Daniel.
Re: [PATCH RESEND] drm/stm: ltdc: fix late dereference check
On 5/15/23 14:38, Raphael Gallais-Pou wrote:
In ltdc_crtc_set_crc_source(), struct drm_crtc was dereferenced in a
container_of() before the pointer check. This could cause a kernel panic.
Fix this smatch warning:
drivers/gpu/drm/stm/ltdc.c:1124 ltdc_crtc_set_crc_source() warn: variable
dereferenced before check 'crtc' (see line 1119)
Reported-by: kernel test robot
Reported-by: Dan Carpenter
Link: https://lore.kernel.org/lkml/202212241802.zelfzcxb-...@intel.com/
Signed-off-by: Raphael Gallais-Pou
---
drivers/gpu/drm/stm/ltdc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index 03c6becda795..b8be4c1db423 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -1145,7 +1145,7 @@ static void ltdc_crtc_disable_vblank(struct drm_crtc
*crtc)
static int ltdc_crtc_set_crc_source(struct drm_crtc *crtc, const char *source)
{
- struct ltdc_device *ldev = crtc_to_ltdc(crtc);
+ struct ltdc_device *ldev;
int ret;
DRM_DEBUG_DRIVER("\n");
@@ -1153,6 +1153,8 @@ static int ltdc_crtc_set_crc_source(struct drm_crtc
*crtc, const char *source)
if (!crtc)
return -ENODEV;
+ ldev = crtc_to_ltdc(crtc);
+
if (source && strcmp(source, "auto") == 0) {
ldev->crc_active = true;
ret = regmap_set_bits(ldev->regmap, LTDC_GCR, GCR_CRCEN);
Hi Raphael,
and many thanks for your patch.
Acked-by: Philippe Cornu
Philippe :-)
Re: [PATCH] drm/stm: Fix resolution bitmasks
On 5/26/23 11:05, Marek Vasut wrote: On 5/15/23 18:02, Philippe CORNU wrote: Hi, The genmask of regsiter SSCR, BPCR & others were setted accordly to the chipset stm32f4. So that means: F4 -> 2048x2048 framebuffer H7/MP1 -> 4096x4096 framebuffer ? Worse F4 is 2048x2048 F7 is 4096x2048 MP1 is 4096x4096 and there is no IDR register on F4/F7 like on MP1, or is there ? How else can we tell those LTDC versions apart ? Dear Marek, Many thanks for your patch (and sorry for this late reply). Your patch is good and fixes this ltdc driver source code vs. the related reference manual. imho, it will not be an issue for F4 & F7 series if these bit-fields are "bigger" as I am pretty sure stm32 MCUs are not really using such high resolutions. Yannick already replied with his reviewed-by. I add my Acked-by: Philippe Cornu If you agree, I will merge your patch really soon. I would say there is no rush, so let's get this done right . Dear Yannick, You may add to your todo list to double check if there is a need to detect stm32 MCUs vs. these bit-field sizes... Can we use a compatible string , or I think there is some ID register ? [...] btw I only received this email now, odd, I wonder whether it was stuck in some SMTP server. Sorry for the delayed reply, it was out of my control. Hi Marek, Thank you for your feedback, I agree it is better to fix this properly. Note: After a quick check, I'm 99% sure that the smtp problem was on my end (although I don't understand why I know we've had some issues with the mailing lists over the past few weeks), so all my apologies for that :-) Hi Yannick, May I ask you please to prepare this clean up (taking into account all ltdc versions). Many thanks Philippe :-)
Re: [PATCH v2] drm: Switch i2c drivers back to use .probe()
Kieran Bingham writes:
Hello Uwe,
> Quoting Uwe Kleine-König (2023-05-26 10:07:09)
>> After commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new()
>> call-back type"), all drivers being converted to .probe_new() and then
>> 03c835f498b5 ("i2c: Switch .probe() to not take an id parameter") convert
>> back to (the new) .probe() to be able to eventually drop .probe_new() from
>> struct i2c_driver.
>>
>> Signed-off-by: Uwe Kleine-König
>> ---
>> Hello,
>>
>> I didn't get feedback for (implicit) v1 that was sent with Message-Id:
>> <20230427175954.666464-1-u.kleine-koe...@pengutronix.de>. This is a
>> rebase on v6.4-rc1 as the former patch doesn't apply cleanly any more.
>>
>> I also added more people to Cc, maybe that helps to get feedback.
>
> Having been invovled in b8a1a4cd5a98 ("i2c: Provide a temporary
> .probe_new() call-back type") and definitley expected 'temporary' to
> mean less than 7 years, I very much approve of this patchset.
>
> Thank you for all your efforts Uwe.
>
> Reviewed-by: Kieran Bingham
>
I strongly second what Kieran just said. I was also involved in the commit
mentioned and it is so great to see your efforts to finish that change.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Re: [PATCH v2] drm: Switch i2c drivers back to use .probe()
On 26/05/2023 10:07, Uwe Kleine-König wrote:
After commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new()
call-back type"), all drivers being converted to .probe_new() and then
03c835f498b5 ("i2c: Switch .probe() to not take an id parameter") convert
back to (the new) .probe() to be able to eventually drop .probe_new() from
struct i2c_driver.
Signed-off-by: Uwe Kleine-König
FWIW:
Reviewed-by: Martyn Welch
---
Hello,
I didn't get feedback for (implicit) v1 that was sent with Message-Id:
<20230427175954.666464-1-u.kleine-koe...@pengutronix.de>. This is a
rebase on v6.4-rc1 as the former patch doesn't apply cleanly any more.
I also added more people to Cc, maybe that helps to get feedback.
This patch is based on v6.4-rc1, and applies fine on today's next.
(There are also no new drivers that need adaption in next.)
Thanks for considering,
Uwe
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 2 +-
drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 2 +-
drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c | 2 +-
drivers/gpu/drm/bridge/analogix/anx7625.c| 2 +-
drivers/gpu/drm/bridge/chipone-icn6211.c | 2 +-
drivers/gpu/drm/bridge/chrontel-ch7033.c | 2 +-
drivers/gpu/drm/bridge/cros-ec-anx7688.c | 2 +-
drivers/gpu/drm/bridge/ite-it6505.c | 2 +-
drivers/gpu/drm/bridge/ite-it66121.c | 2 +-
drivers/gpu/drm/bridge/lontium-lt8912b.c | 2 +-
drivers/gpu/drm/bridge/lontium-lt9211.c | 2 +-
drivers/gpu/drm/bridge/lontium-lt9611.c | 2 +-
drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 2 +-
drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c | 4 ++--
drivers/gpu/drm/bridge/nxp-ptn3460.c | 2 +-
drivers/gpu/drm/bridge/parade-ps8622.c | 2 +-
drivers/gpu/drm/bridge/parade-ps8640.c | 2 +-
drivers/gpu/drm/bridge/sii902x.c | 2 +-
drivers/gpu/drm/bridge/sii9234.c | 2 +-
drivers/gpu/drm/bridge/sil-sii8620.c | 2 +-
drivers/gpu/drm/bridge/tc358767.c| 2 +-
drivers/gpu/drm/bridge/tc358768.c| 2 +-
drivers/gpu/drm/bridge/tc358775.c| 2 +-
drivers/gpu/drm/bridge/ti-dlpc3433.c | 2 +-
drivers/gpu/drm/bridge/ti-sn65dsi83.c| 2 +-
drivers/gpu/drm/bridge/ti-sn65dsi86.c| 2 +-
drivers/gpu/drm/bridge/ti-tfp410.c | 2 +-
drivers/gpu/drm/i2c/tda9950.c| 2 +-
drivers/gpu/drm/i2c/tda998x_drv.c| 2 +-
drivers/gpu/drm/panel/panel-olimex-lcd-olinuxino.c | 2 +-
drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c| 2 +-
drivers/gpu/drm/solomon/ssd130x-i2c.c| 2 +-
32 files changed, 33 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index ddceafa7b637..2254457ab5d0 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -1393,7 +1393,7 @@ static struct i2c_driver adv7511_driver = {
.of_match_table = adv7511_of_ids,
},
.id_table = adv7511_i2c_ids,
- .probe_new = adv7511_probe,
+ .probe = adv7511_probe,
.remove = adv7511_remove,
};
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
index 3577c532abb4..72ab2ab77081 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
@@ -815,7 +815,7 @@ static struct i2c_driver anx6345_driver = {
.name = "anx6345",
.of_match_table = of_match_ptr(anx6345_match_table),
},
- .probe_new = anx6345_i2c_probe,
+ .probe = anx6345_i2c_probe,
.remove = anx6345_i2c_remove,
.id_table = anx6345_id,
};
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
index a3a38bbe2786..06a3e3243e19 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
@@ -1389,7 +1389,7 @@ static struct i2c_driver anx78xx_driver = {
.name = "anx7814",
.of_match_table = of_match_ptr(anx78xx_match_table),
},
- .probe_new = anx78xx_i2c_probe,
+ .probe = anx78xx_i2c_probe,
.remove = anx78xx_i2c_remove,
.id_table = anx78xx_id,
};
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
b/drivers/gpu/drm/bridge/analogix/anx7625.c
index 6846199a2ee1..0a97364ba8ea 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.c
+++
Re: [PATCH v2] drm: Switch i2c drivers back to use .probe()
Quoting Uwe Kleine-König (2023-05-26 10:07:09)
> After commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new()
> call-back type"), all drivers being converted to .probe_new() and then
> 03c835f498b5 ("i2c: Switch .probe() to not take an id parameter") convert
> back to (the new) .probe() to be able to eventually drop .probe_new() from
> struct i2c_driver.
>
> Signed-off-by: Uwe Kleine-König
> ---
> Hello,
>
> I didn't get feedback for (implicit) v1 that was sent with Message-Id:
> <20230427175954.666464-1-u.kleine-koe...@pengutronix.de>. This is a
> rebase on v6.4-rc1 as the former patch doesn't apply cleanly any more.
>
> I also added more people to Cc, maybe that helps to get feedback.
Having been invovled in b8a1a4cd5a98 ("i2c: Provide a temporary
.probe_new() call-back type") and definitley expected 'temporary' to
mean less than 7 years, I very much approve of this patchset.
Thank you for all your efforts Uwe.
Reviewed-by: Kieran Bingham
> This patch is based on v6.4-rc1, and applies fine on today's next.
> (There are also no new drivers that need adaption in next.)
>
> Thanks for considering,
> Uwe
>
> drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 2 +-
> drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 2 +-
> drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c | 2 +-
> drivers/gpu/drm/bridge/analogix/anx7625.c| 2 +-
> drivers/gpu/drm/bridge/chipone-icn6211.c | 2 +-
> drivers/gpu/drm/bridge/chrontel-ch7033.c | 2 +-
> drivers/gpu/drm/bridge/cros-ec-anx7688.c | 2 +-
> drivers/gpu/drm/bridge/ite-it6505.c | 2 +-
> drivers/gpu/drm/bridge/ite-it66121.c | 2 +-
> drivers/gpu/drm/bridge/lontium-lt8912b.c | 2 +-
> drivers/gpu/drm/bridge/lontium-lt9211.c | 2 +-
> drivers/gpu/drm/bridge/lontium-lt9611.c | 2 +-
> drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 2 +-
> drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c | 4 ++--
> drivers/gpu/drm/bridge/nxp-ptn3460.c | 2 +-
> drivers/gpu/drm/bridge/parade-ps8622.c | 2 +-
> drivers/gpu/drm/bridge/parade-ps8640.c | 2 +-
> drivers/gpu/drm/bridge/sii902x.c | 2 +-
> drivers/gpu/drm/bridge/sii9234.c | 2 +-
> drivers/gpu/drm/bridge/sil-sii8620.c | 2 +-
> drivers/gpu/drm/bridge/tc358767.c| 2 +-
> drivers/gpu/drm/bridge/tc358768.c| 2 +-
> drivers/gpu/drm/bridge/tc358775.c| 2 +-
> drivers/gpu/drm/bridge/ti-dlpc3433.c | 2 +-
> drivers/gpu/drm/bridge/ti-sn65dsi83.c| 2 +-
> drivers/gpu/drm/bridge/ti-sn65dsi86.c| 2 +-
> drivers/gpu/drm/bridge/ti-tfp410.c | 2 +-
> drivers/gpu/drm/i2c/tda9950.c| 2 +-
> drivers/gpu/drm/i2c/tda998x_drv.c| 2 +-
> drivers/gpu/drm/panel/panel-olimex-lcd-olinuxino.c | 2 +-
> drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c| 2 +-
> drivers/gpu/drm/solomon/ssd130x-i2c.c| 2 +-
> 32 files changed, 33 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> index ddceafa7b637..2254457ab5d0 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> @@ -1393,7 +1393,7 @@ static struct i2c_driver adv7511_driver = {
> .of_match_table = adv7511_of_ids,
> },
> .id_table = adv7511_i2c_ids,
> - .probe_new = adv7511_probe,
> + .probe = adv7511_probe,
> .remove = adv7511_remove,
> };
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> index 3577c532abb4..72ab2ab77081 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> @@ -815,7 +815,7 @@ static struct i2c_driver anx6345_driver = {
>.name = "anx6345",
>.of_match_table = of_match_ptr(anx6345_match_table),
> },
> - .probe_new = anx6345_i2c_probe,
> + .probe = anx6345_i2c_probe,
> .remove = anx6345_i2c_remove,
> .id_table = anx6345_id,
> };
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> index a3a38bbe2786..06a3e3243e19 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> @@ -1389,7 +1389,7 @@ static struct i2c_driver anx78xx_driver = {
>.name = "anx7814",
>.of_match_table = of_match_ptr(anx78xx_match_table),
Re: [PATCH v6 3/8] drm/bridge: mhdp8546: Add minimal format negotiation
On 16/05/2023 17:25, Aradhya Bhatia wrote:
Hi Neil,
Thank you for reviewing the patch.
On 16-May-23 12:51, Neil Armstrong wrote:
On 15/05/2023 17:59, Aradhya Bhatia wrote:
Hi Tomi,
On 12-May-23 14:45, Tomi Valkeinen wrote:
On 09/05/2023 12:30, Aradhya Bhatia wrote:
From: Nikhil Devshatwar
With new connector model, mhdp bridge will not create the connector and
SoC driver will rely on format negotiation to setup the encoder format.
Support minimal format negotiations hooks in the drm_bridge_funcs.
Complete format negotiation can be added based on EDID data.
This patch adds the minimal required support to avoid failure
after moving to new connector model.
Signed-off-by: Nikhil Devshatwar
Reviewed-by: Tomi Valkeinen
You need to add your SoB to this and the other patches.
Okay!
---
Notes:
changes from v1:
* cosmetic fixes, commit message update.
changes from v5:
* dropped the default_bus_format variable and directly assigned
MEDIA_BUS_FMT_RGB121212_1X36 to input_fmts.
.../drm/bridge/cadence/cdns-mhdp8546-core.c | 25
+++
1 file changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
index f6822dfa3805..623e4235c94f 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
@@ -2146,6 +2146,30 @@ cdns_mhdp_bridge_atomic_reset(struct drm_bridge
*bridge)
return _mhdp_state->base;
}
+static u32 *cdns_mhdp_get_input_bus_fmts(struct drm_bridge *bridge,
+ struct drm_bridge_state *bridge_state,
+ struct drm_crtc_state *crtc_state,
+ struct drm_connector_state *conn_state,
+ u32 output_fmt,
+ unsigned int *num_input_fmts)
+{
+ u32 *input_fmts;
+
+ *num_input_fmts = 0;
+
+ if (output_fmt != MEDIA_BUS_FMT_FIXED)
+ return NULL;
The tfp410 and sii902x drivers don't have the above check. Why does mhdp
need it? Or the other way, why don't tfp410 and sii902x need it?
I had removed this condition in order to follow status quo, from the
ITE-66121 HDMI bridge driver.
The idea would have been to drop this for MHDP as well, but I guess I
overlooked this one.
However...
I guess at the moment we always do get MEDIA_BUS_FMT_FIXED as the out
fmt (in all three bridge drivers), don't we?
... I tested again to ensure that the above is indeed the case. And
ended up catching some odd behavior.
It turns out that for all the HDMI bridges (TFP410, SII902X, ITE-66121),
the format negotiation doesn't stop at output_fmt = MEDIA_BUS_FMT_FIXED.
The {bridge}_get_input_format API gets called again with the output_fmt
= MEDIA_BUS_FMT_RGB24_1X24.
This doesn't happen with the MHDP driver. Format negotiation with MHDP
bridge stops after one round, at output_fmt = MEDIA_BUS_FMT_FIXED.
This is because the bridge negociation logic will test with all possible
output formats from the chain, and won't stop at first working test.
Okay..
If your bridge only supports a single input format, it should return the
same format whatever output_fmt is tried.
So indeed remove this test on mhdp aswell, or filter out invalid output
formats.
Agreed.
I have been looking into the code deeper and trying to understand the
logic flow around the format negotiation in the framework. Here are the
2 points that I want to mention. Please let me know if I have missed
something with my understanding.
Firstly, the mhdp-8546 output connects to the display-connector (with
the compatible, "dp-connector") in the devicetree.
When the negotiation begins at 'drm_atomic_bridge_chain_select_bus_fmts'
the display-connector bridge *should* act as the 'last_bridge', and the
atomic_get_output_bus_fmts hook of the display-connector should get
called. However, for some reason I am not yet sure of, the condition
:: if (last_bridge->funcs->atomic_get_output_bus_fmts)
fails and the 'select_bus_fmt_recursive' function gets called instead,
(with MEDIA_BUS_FMT_FIXED as output_fmt), which in turn calls the
atomic_get_input_bus_fmts hook of the mhdp-8546. This entirely skips the
display-connector out of the format negotiation.
This doesn't happen when the HDMI bridges are in concern, even though,
they too are connected with display-connector (with compatible
"hdmi-connector").
I looked into the display-connector driver hoping to find if the 2 types
of connectors are being treated differently wrt format negotiation, but
I did not find any clue.
Please let me know if you have any idea about this.
The display connector is probed, but not attached to the bridge chain,
so the last bridge is the mdhp. You need to call drm_bridge_attach in
the mhdp driver to attach the next bridge. See e.g. tfp410's
tfp410_attach().
Also, I think the support in mhdp for the
!DRM_BRIDGE_ATTACH_NO_CONNECTOR case should be
Re: [Intel-gfx] [PATCH] drm/i915: simplify switch to if-elseif
On Tue, 23 May 2023, Jani Nikula wrote:
> On Tue, 23 May 2023, Tom Rix wrote:
>> clang with W=1 reports
>> drivers/gpu/drm/i915/display/intel_display.c:6012:3: error: unannotated
>> fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
>> case I915_FORMAT_MOD_X_TILED:
>> ^
>>
>> Only one case and the default does anything in this switch, so it should
>> be changed to an if-elseif.
>
> Thanks for the patch.
>
> If I wanted to fix this quickly, I'd just add the break in there.
I've just applied [1] doing this.
I'm still open to the cleanup suggested below, if you're up for it.
BR,
Jani.
[1]
https://patchwork.freedesktop.org/patch/msgid/20230524-intel_async_flip_check_hw-implicit-fallthrough-v1-1-83de89e37...@kernel.org
>
> If I wanted to fix this properly, I'd add a function
> modifier_supports_async_flips() or something, and replace the switch
> with:
>
> if (!modifier_supports_async_flips(i915,
> new_plane_state->hw.fb->modifier)) {
> drm_dbg_kms(>drm, "[PLANE:%d:%s] Modifier does not
> support async flips\n",
> plane->base.base.id, plane->base.name);
> return -EINVAL;
> }
>
> But I wouldn't just replace the switch with if-elseif. It doesn't help
> with the overall feeling that intel_async_flip_check_hw() is too long.
>
> BR,
> Jani.
>
>
>>
>> Signed-off-by: Tom Rix
>> ---
>> drivers/gpu/drm/i915/display/intel_display.c | 14 +-
>> 1 file changed, 5 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
>> b/drivers/gpu/drm/i915/display/intel_display.c
>> index 0490c6412ab5..1f852e49fc20 100644
>> --- a/drivers/gpu/drm/i915/display/intel_display.c
>> +++ b/drivers/gpu/drm/i915/display/intel_display.c
>> @@ -5994,8 +5994,7 @@ static int intel_async_flip_check_hw(struct
>> intel_atomic_state *state, struct in
>> * Need to verify this for all gen9 platforms to enable
>> * this selectively if required.
>> */
>> -switch (new_plane_state->hw.fb->modifier) {
>> -case DRM_FORMAT_MOD_LINEAR:
>> +if (new_plane_state->hw.fb->modifier == DRM_FORMAT_MOD_LINEAR) {
>> /*
>> * FIXME: Async on Linear buffer is supported on ICL as
>> * but with additional alignment and fbc restrictions
>> @@ -6008,13 +6007,10 @@ static int intel_async_flip_check_hw(struct
>> intel_atomic_state *state, struct in
>> plane->base.base.id,
>> plane->base.name);
>> return -EINVAL;
>> }
>> -
>> -case I915_FORMAT_MOD_X_TILED:
>> -case I915_FORMAT_MOD_Y_TILED:
>> -case I915_FORMAT_MOD_Yf_TILED:
>> -case I915_FORMAT_MOD_4_TILED:
>> -break;
>> -default:
>> +} else if (!(new_plane_state->hw.fb->modifier ==
>> I915_FORMAT_MOD_X_TILED ||
>> + new_plane_state->hw.fb->modifier ==
>> I915_FORMAT_MOD_Y_TILED ||
>> + new_plane_state->hw.fb->modifier ==
>> I915_FORMAT_MOD_Yf_TILED ||
>> + new_plane_state->hw.fb->modifier ==
>> I915_FORMAT_MOD_4_TILED)) {
>> drm_dbg_kms(>drm,
>> "[PLANE:%d:%s] Modifier does not support
>> async flips\n",
>> plane->base.base.id, plane->base.name);
--
Jani Nikula, Intel Open Source Graphics Center
Re: [PATCH] drm/i915: Fix clang -Wimplicit-fallthrough in intel_async_flip_check_hw()
On Wed, 24 May 2023, Nick Desaulniers wrote:
> On Wed, May 24, 2023 at 8:38 AM Nathan Chancellor wrote:
>>
>> Clang warns:
>>
>> drivers/gpu/drm/i915/display/intel_display.c:6012:3: error: unannotated
>> fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
>> case I915_FORMAT_MOD_X_TILED:
>> ^
>> drivers/gpu/drm/i915/display/intel_display.c:6012:3: note: insert 'break;'
>> to avoid fall-through
>> case I915_FORMAT_MOD_X_TILED:
>> ^
>> break;
>> 1 error generated.
>>
>> Clang is a little more pedantic than GCC, which does not warn when
>> falling through to a case that is just break or return. Clang's version
>> is more in line with the kernel's own stance in deprecated.rst, which
>> states that all switch/case blocks must end in either break,
>> fallthrough, continue, goto, or return. Add the missing break to silence
>> the warning.
>>
>> Fixes: 937859485aef ("drm/i915: Support Async Flip on Linear buffers")
>> Reported-by: kernel test robot
>> Closes: https://lore.kernel.org/202305241902.uvhtmoxa-...@intel.com/
>> Reported-by: Naresh Kamboju
>> Closes:
>> https://lore.kernel.org/CA+G9fYv68V3ewK0Qj-syQj7qX-hQr0H1MFL=qfnudoe_j2z...@mail.gmail.com/
>> Signed-off-by: Nathan Chancellor
>
> Thanks for the patch! I've never seen the closes tag before, that's
> new to me. Can you tell me more about it?
>
> A few more tags
>
> Reported-by: Tom Rix
> Link: https://lore.kernel.org/all/20230523125116.1669057-1-t...@redhat.com/
> Reviewed-by: Nick Desaulniers
Thanks for the patch and review, pushed to drm-intel-next with
s/Link/Closes/.
BR,
Jani.
>
>
>> ---
>> drivers/gpu/drm/i915/display/intel_display.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
>> b/drivers/gpu/drm/i915/display/intel_display.c
>> index 0490c6412ab5..6d49e0ab3e85 100644
>> --- a/drivers/gpu/drm/i915/display/intel_display.c
>> +++ b/drivers/gpu/drm/i915/display/intel_display.c
>> @@ -6008,6 +6008,7 @@ static int intel_async_flip_check_hw(struct
>> intel_atomic_state *state, struct in
>> plane->base.base.id,
>> plane->base.name);
>> return -EINVAL;
>> }
>> + break;
>>
>> case I915_FORMAT_MOD_X_TILED:
>> case I915_FORMAT_MOD_Y_TILED:
>>
>> ---
>> base-commit: 9a2cb1b31c040e2f1b313e2f7921f0f5e6b66d82
>> change-id:
>> 20230524-intel_async_flip_check_hw-implicit-fallthrough-c4c40b03802f
>>
>> Best regards,
>> --
>> Nathan Chancellor
>>
--
Jani Nikula, Intel Open Source Graphics Center
[PATCH v2] drm/nouveau: bring back blit subchannel for pre nv50 GPUs
1ba6113a90a0 removed a lot of the kernel GPU channel, but method 0x128
was important as otherwise the GPU spams us with `CACHE_ERROR` messages.
We use the blit subchannel inside our vblank handling, so we should keep
at least this part.
v2: Only do it for NV11+ GPUs
Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/201
Fixes: 4a16dd9d18a0 ("drm/nouveau/kms: switch to drm fbdev helpers")
Signed-off-by: Karol Herbst
---
drivers/gpu/drm/nouveau/nouveau_chan.c | 1 +
drivers/gpu/drm/nouveau/nouveau_chan.h | 1 +
drivers/gpu/drm/nouveau/nouveau_drm.c | 20 +---
3 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_chan.c
b/drivers/gpu/drm/nouveau/nouveau_chan.c
index e648ecd0c1a0..3dfbc374478e 100644
--- a/drivers/gpu/drm/nouveau/nouveau_chan.c
+++ b/drivers/gpu/drm/nouveau/nouveau_chan.c
@@ -90,6 +90,7 @@ nouveau_channel_del(struct nouveau_channel **pchan)
if (cli)
nouveau_svmm_part(chan->vmm->svmm, chan->inst);
+ nvif_object_dtor(>blit);
nvif_object_dtor(>nvsw);
nvif_object_dtor(>gart);
nvif_object_dtor(>vram);
diff --git a/drivers/gpu/drm/nouveau/nouveau_chan.h
b/drivers/gpu/drm/nouveau/nouveau_chan.h
index e06a8ffed31a..bad7466bd0d5 100644
--- a/drivers/gpu/drm/nouveau/nouveau_chan.h
+++ b/drivers/gpu/drm/nouveau/nouveau_chan.h
@@ -53,6 +53,7 @@ struct nouveau_channel {
u32 user_put;
struct nvif_object user;
+ struct nvif_object blit;
struct nvif_event kill;
atomic_t killed;
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index cc7c5b4a05fd..9512f1c2f871 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -369,15 +369,29 @@ nouveau_accel_gr_init(struct nouveau_drm *drm)
ret = nvif_object_ctor(>channel->user, "drmNvsw",
NVDRM_NVSW, nouveau_abi16_swclass(drm),
NULL, 0, >channel->nvsw);
+
+ if (ret == 0 && device->info.chipset >= 0x11) {
+ ret = nvif_object_ctor(>channel->user, "drmBlit",
+ 0x005f, 0x009f,
+ NULL, 0, >channel->blit);
+ }
+
if (ret == 0) {
struct nvif_push *push = drm->channel->chan.push;
- ret = PUSH_WAIT(push, 2);
- if (ret == 0)
+ ret = PUSH_WAIT(push, 8);
+ if (ret == 0) {
+ if (device->info.chipset >= 0x11) {
+ PUSH_NVSQ(push, NV05F, 0x,
drm->channel->blit.handle);
+ PUSH_NVSQ(push, NV09F, 0x0120, 0,
+ 0x0124, 1,
+ 0x0128, 2);
+ }
PUSH_NVSQ(push, NV_SW, 0x,
drm->channel->nvsw.handle);
+ }
}
if (ret) {
- NV_ERROR(drm, "failed to allocate sw class, %d\n", ret);
+ NV_ERROR(drm, "failed to allocate sw or blit class,
%d\n", ret);
nouveau_accel_gr_fini(drm);
return;
}
--
2.40.1
[PATCH] drm/msm/dpu: use PINGPONG_NONE to unbind INTF from PP
Currently the driver passes the PINGPONG index to
dpu_hw_intf_ops::bind_pingpong_blk() callback and uses separate boolean
flag to tell whether INTF should be bound or unbound. Simplify this by
passing PINGPONG_NONE in case of unbinding and drop the flag completely.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 4 ++--
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 4 +---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 3 +--
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h | 1 -
5 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index ebe34eda6e50..7fd3a13ac226 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -2102,8 +2102,8 @@ void dpu_encoder_helper_phys_cleanup(struct
dpu_encoder_phys *phys_enc)
for (i = 0; i < dpu_enc->num_phys_encs; i++) {
if (dpu_enc->phys_encs[i] &&
phys_enc->hw_intf->ops.bind_pingpong_blk)
phys_enc->hw_intf->ops.bind_pingpong_blk(
- dpu_enc->phys_encs[i]->hw_intf,
false,
-
dpu_enc->phys_encs[i]->hw_pp->idx);
+ dpu_enc->phys_encs[i]->hw_intf,
+ PINGPONG_NONE);
/* mark INTF flush as pending */
if (phys_enc->hw_ctl->ops.update_pending_flush_intf)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
index 1a4c20f02312..3130c86a32cc 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
@@ -66,7 +66,6 @@ static void _dpu_encoder_phys_cmd_update_intf_cfg(
if (test_bit(DPU_CTL_ACTIVE_CFG, >caps->features) &&
phys_enc->hw_intf->ops.bind_pingpong_blk)
phys_enc->hw_intf->ops.bind_pingpong_blk(
phys_enc->hw_intf,
- true,
phys_enc->hw_pp->idx);
if (phys_enc->hw_intf->ops.enable_compression)
@@ -556,8 +555,7 @@ static void dpu_encoder_phys_cmd_disable(struct
dpu_encoder_phys *phys_enc)
if (phys_enc->hw_intf->ops.bind_pingpong_blk) {
phys_enc->hw_intf->ops.bind_pingpong_blk(
phys_enc->hw_intf,
- false,
- phys_enc->hw_pp->idx);
+ PINGPONG_NONE);
ctl = phys_enc->hw_ctl;
ctl->ops.update_pending_flush_intf(ctl, phys_enc->intf_idx);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
index 3a374292f311..220020273304 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
@@ -287,7 +287,6 @@ static void dpu_encoder_phys_vid_setup_timing_engine(
if (phys_enc->hw_intf->ops.bind_pingpong_blk)
phys_enc->hw_intf->ops.bind_pingpong_blk(
phys_enc->hw_intf,
- true,
phys_enc->hw_pp->idx);
if (phys_enc->hw_pp->merge_3d)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
index a2486f99d3c2..918d154848b9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
@@ -268,7 +268,6 @@ static void dpu_hw_intf_setup_prg_fetch(
static void dpu_hw_intf_bind_pingpong_blk(
struct dpu_hw_intf *intf,
- bool enable,
const enum dpu_pingpong pp)
{
struct dpu_hw_blk_reg_map *c = >hw;
@@ -277,7 +276,7 @@ static void dpu_hw_intf_bind_pingpong_blk(
mux_cfg = DPU_REG_READ(c, INTF_MUX);
mux_cfg &= ~0xf;
- if (enable)
+ if (pp != PINGPONG_NONE)
mux_cfg |= (pp - PINGPONG_0) & 0x7;
else
mux_cfg |= 0xf;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h
index 72fe907729f1..e2d15e89880d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h
@@ -89,7 +89,6 @@ struct dpu_hw_intf_ops {
u32 (*get_line_count)(struct dpu_hw_intf *intf);
void (*bind_pingpong_blk)(struct dpu_hw_intf *intf,
- bool enable,
const enum dpu_pingpong pp);
void (*setup_misr)(struct dpu_hw_intf *intf, bool enable, u32
frame_count);
int (*collect_misr)(struct
[PATCH v2] drm: Switch i2c drivers back to use .probe()
After commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new()
call-back type"), all drivers being converted to .probe_new() and then
03c835f498b5 ("i2c: Switch .probe() to not take an id parameter") convert
back to (the new) .probe() to be able to eventually drop .probe_new() from
struct i2c_driver.
Signed-off-by: Uwe Kleine-König
---
Hello,
I didn't get feedback for (implicit) v1 that was sent with Message-Id:
<20230427175954.666464-1-u.kleine-koe...@pengutronix.de>. This is a
rebase on v6.4-rc1 as the former patch doesn't apply cleanly any more.
I also added more people to Cc, maybe that helps to get feedback.
This patch is based on v6.4-rc1, and applies fine on today's next.
(There are also no new drivers that need adaption in next.)
Thanks for considering,
Uwe
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 2 +-
drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 2 +-
drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c | 2 +-
drivers/gpu/drm/bridge/analogix/anx7625.c| 2 +-
drivers/gpu/drm/bridge/chipone-icn6211.c | 2 +-
drivers/gpu/drm/bridge/chrontel-ch7033.c | 2 +-
drivers/gpu/drm/bridge/cros-ec-anx7688.c | 2 +-
drivers/gpu/drm/bridge/ite-it6505.c | 2 +-
drivers/gpu/drm/bridge/ite-it66121.c | 2 +-
drivers/gpu/drm/bridge/lontium-lt8912b.c | 2 +-
drivers/gpu/drm/bridge/lontium-lt9211.c | 2 +-
drivers/gpu/drm/bridge/lontium-lt9611.c | 2 +-
drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 2 +-
drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c | 4 ++--
drivers/gpu/drm/bridge/nxp-ptn3460.c | 2 +-
drivers/gpu/drm/bridge/parade-ps8622.c | 2 +-
drivers/gpu/drm/bridge/parade-ps8640.c | 2 +-
drivers/gpu/drm/bridge/sii902x.c | 2 +-
drivers/gpu/drm/bridge/sii9234.c | 2 +-
drivers/gpu/drm/bridge/sil-sii8620.c | 2 +-
drivers/gpu/drm/bridge/tc358767.c| 2 +-
drivers/gpu/drm/bridge/tc358768.c| 2 +-
drivers/gpu/drm/bridge/tc358775.c| 2 +-
drivers/gpu/drm/bridge/ti-dlpc3433.c | 2 +-
drivers/gpu/drm/bridge/ti-sn65dsi83.c| 2 +-
drivers/gpu/drm/bridge/ti-sn65dsi86.c| 2 +-
drivers/gpu/drm/bridge/ti-tfp410.c | 2 +-
drivers/gpu/drm/i2c/tda9950.c| 2 +-
drivers/gpu/drm/i2c/tda998x_drv.c| 2 +-
drivers/gpu/drm/panel/panel-olimex-lcd-olinuxino.c | 2 +-
drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c| 2 +-
drivers/gpu/drm/solomon/ssd130x-i2c.c| 2 +-
32 files changed, 33 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index ddceafa7b637..2254457ab5d0 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -1393,7 +1393,7 @@ static struct i2c_driver adv7511_driver = {
.of_match_table = adv7511_of_ids,
},
.id_table = adv7511_i2c_ids,
- .probe_new = adv7511_probe,
+ .probe = adv7511_probe,
.remove = adv7511_remove,
};
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
index 3577c532abb4..72ab2ab77081 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
@@ -815,7 +815,7 @@ static struct i2c_driver anx6345_driver = {
.name = "anx6345",
.of_match_table = of_match_ptr(anx6345_match_table),
},
- .probe_new = anx6345_i2c_probe,
+ .probe = anx6345_i2c_probe,
.remove = anx6345_i2c_remove,
.id_table = anx6345_id,
};
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
index a3a38bbe2786..06a3e3243e19 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
@@ -1389,7 +1389,7 @@ static struct i2c_driver anx78xx_driver = {
.name = "anx7814",
.of_match_table = of_match_ptr(anx78xx_match_table),
},
- .probe_new = anx78xx_i2c_probe,
+ .probe = anx78xx_i2c_probe,
.remove = anx78xx_i2c_remove,
.id_table = anx78xx_id,
};
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
b/drivers/gpu/drm/bridge/analogix/anx7625.c
index 6846199a2ee1..0a97364ba8ea 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.c
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -2753,7 +2753,7 @@ static struct i2c_driver anx7625_driver = {
Re: [PATCH] drm/stm: Fix resolution bitmasks
On 5/15/23 18:02, Philippe CORNU wrote: Hi, The genmask of regsiter SSCR, BPCR & others were setted accordly to the chipset stm32f4. So that means: F4 -> 2048x2048 framebuffer H7/MP1 -> 4096x4096 framebuffer ? Worse F4 is 2048x2048 F7 is 4096x2048 MP1 is 4096x4096 and there is no IDR register on F4/F7 like on MP1, or is there ? How else can we tell those LTDC versions apart ? Dear Marek, Many thanks for your patch (and sorry for this late reply). Your patch is good and fixes this ltdc driver source code vs. the related reference manual. imho, it will not be an issue for F4 & F7 series if these bit-fields are "bigger" as I am pretty sure stm32 MCUs are not really using such high resolutions. Yannick already replied with his reviewed-by. I add my Acked-by: Philippe Cornu If you agree, I will merge your patch really soon. I would say there is no rush, so let's get this done right . Dear Yannick, You may add to your todo list to double check if there is a need to detect stm32 MCUs vs. these bit-field sizes... Can we use a compatible string , or I think there is some ID register ? [...] btw I only received this email now, odd, I wonder whether it was stuck in some SMTP server. Sorry for the delayed reply, it was out of my control.
Re: [PATCH v2 3/6] drm/msm/dpu: split interrupt address arrays
On 22/05/2023 23:45, Dmitry Baryshkov wrote:
There is no point in having a single enum (and a single array) for both
DPU < 7.0 and DPU >= 7.0 interrupt registers. Instead define a single
enum and two IRQ address arrays.
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_7_0_sm8350.h| 1 +
.../msm/disp/dpu1/catalog/dpu_7_2_sc7280.h| 1 +
.../msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h | 1 +
.../msm/disp/dpu1/catalog/dpu_8_1_sm8450.h| 1 +
.../msm/disp/dpu1/catalog/dpu_9_0_sm8550.h| 1 +
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 2 +
.../gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 82 +--
.../gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h | 28 ---
8 files changed, 79 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h
index 3c1b2c13398d..320cfa4be633 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h
@@ -15,6 +15,7 @@ static const struct dpu_caps sm8350_dpu_caps = {
.has_dim_layer = true,
.has_idle_pc = true,
.has_3d_merge = true,
+ .has_7xxx_intr = true,
.max_linewidth = 4096,
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
};
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
index 5d894cbb0a62..9306c7a115e9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
@@ -13,6 +13,7 @@ static const struct dpu_caps sc7280_dpu_caps = {
.qseed_type = DPU_SSPP_SCALER_QSEED4,
.has_dim_layer = true,
.has_idle_pc = true,
+ .has_7xxx_intr = true,
.max_linewidth = 2400,
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
};
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h
index c3f1ae000a21..fc1e17c495f0 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h
@@ -15,6 +15,7 @@ static const struct dpu_caps sc8280xp_dpu_caps = {
.has_dim_layer = true,
.has_idle_pc = true,
.has_3d_merge = true,
+ .has_7xxx_intr = true,
.max_linewidth = 5120,
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
};
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h
index 86c2e68ebd2c..eb72411c16db 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h
@@ -14,6 +14,7 @@ static const struct dpu_caps sm8450_dpu_caps = {
.has_src_split = true,
.has_dim_layer = true,
.has_idle_pc = true,
+ .has_7xxx_intr = true,
.has_3d_merge = true,
.max_linewidth = 5120,
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h
index 85dc34458b88..8209ca317bdc 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h
@@ -15,6 +15,7 @@ static const struct dpu_caps sm8550_dpu_caps = {
.has_dim_layer = true,
.has_idle_pc = true,
.has_3d_merge = true,
+ .has_7xxx_intr = true,
.max_linewidth = 5120,
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
};
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index 677048cc3b7d..72530ebb0ae6 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -351,6 +351,7 @@ struct dpu_rotation_cfg {
* @has_dim_layer dim layer feature status
* @has_idle_pcindicate if idle power collapse feature is supported
* @has_3d_merge indicate if 3D merge is supported
+ * @has_7xxx_intr indicate that INTF/IRQs use addressing for DPU 7.0 and
greater
* @max_linewidth max linewidth for sspp
* @pixel_ram_size size of latency hiding and de-tiling buffer in bytes
* @max_hdeci_exp max horizontal decimation supported (max is 2^value)
@@ -364,6 +365,7 @@ struct dpu_caps {
bool has_dim_layer;
bool has_idle_pc;
bool has_3d_merge;
+ bool has_7xxx_intr;
/* SSPP limits */
u32 max_linewidth;
u32 pixel_ram_size;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
index 0776b0f6df4f..a03d826bb9ad 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
@@ -51,11 +51,9 @@ struct dpu_intr_reg {
};
/*
- * struct dpu_intr_reg -
Re: [Freedreno] [PATCH v2 3/6] drm/msm/dpu: split interrupt address arrays
On Fri, 26 May 2023 at 01:42, Abhinav Kumar wrote:
> On 5/25/2023 3:30 PM, Dmitry Baryshkov wrote:
> > On Fri, 26 May 2023 at 00:40, Jeykumar Sankaran
> > wrote:
> >> On 5/22/2023 2:45 PM, Dmitry Baryshkov wrote:
> >>> There is no point in having a single enum (and a single array) for both
> >>> DPU < 7.0 and DPU >= 7.0 interrupt registers. Instead define a single
> >>> enum and two IRQ address arrays.
> >>>
> >>> Signed-off-by: Dmitry Baryshkov
> >>> ---
> >>>.../msm/disp/dpu1/catalog/dpu_7_0_sm8350.h| 1 +
> >>>.../msm/disp/dpu1/catalog/dpu_7_2_sc7280.h| 1 +
> >>>.../msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h | 1 +
> >>>.../msm/disp/dpu1/catalog/dpu_8_1_sm8450.h| 1 +
> >>>.../msm/disp/dpu1/catalog/dpu_9_0_sm8550.h| 1 +
> >>>.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 2 +
> >>>.../gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 82 +--
> >>>.../gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h | 28 ---
> >>>8 files changed, 79 insertions(+), 38 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h
> >>> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h
> >>> index 3c1b2c13398d..320cfa4be633 100644
> >>> --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h
> >>> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h
> >>> @@ -15,6 +15,7 @@ static const struct dpu_caps sm8350_dpu_caps = {
> >>>.has_dim_layer = true,
> >>>.has_idle_pc = true,
> >>>.has_3d_merge = true,
> >>> + .has_7xxx_intr = true,
> >>>.max_linewidth = 4096,
> >>>.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
> >>>};
> >>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
> >>> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
> >>> index 5d894cbb0a62..9306c7a115e9 100644
> >>> --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
> >>> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
> >>> @@ -13,6 +13,7 @@ static const struct dpu_caps sc7280_dpu_caps = {
> >>>.qseed_type = DPU_SSPP_SCALER_QSEED4,
> >>>.has_dim_layer = true,
> >>>.has_idle_pc = true,
> >>> + .has_7xxx_intr = true,
> >>>.max_linewidth = 2400,
> >>>.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
> >>>};
> >>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h
> >>> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h
> >>> index c3f1ae000a21..fc1e17c495f0 100644
> >>> --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h
> >>> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h
> >>> @@ -15,6 +15,7 @@ static const struct dpu_caps sc8280xp_dpu_caps = {
> >>>.has_dim_layer = true,
> >>>.has_idle_pc = true,
> >>>.has_3d_merge = true,
> >>> + .has_7xxx_intr = true,
> >>>.max_linewidth = 5120,
> >>>.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
> >>>};
> >>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h
> >>> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h
> >>> index 86c2e68ebd2c..eb72411c16db 100644
> >>> --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h
> >>> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h
> >>> @@ -14,6 +14,7 @@ static const struct dpu_caps sm8450_dpu_caps = {
> >>>.has_src_split = true,
> >>>.has_dim_layer = true,
> >>>.has_idle_pc = true,
> >>> + .has_7xxx_intr = true,
> >>>.has_3d_merge = true,
> >>>.max_linewidth = 5120,
> >>>.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
> >>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h
> >>> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h
> >>> index 85dc34458b88..8209ca317bdc 100644
> >>> --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h
> >>> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h
> >>> @@ -15,6 +15,7 @@ static const struct dpu_caps sm8550_dpu_caps = {
> >>>.has_dim_layer = true,
> >>>.has_idle_pc = true,
> >>>.has_3d_merge = true,
> >>> + .has_7xxx_intr = true,
> >>>.max_linewidth = 5120,
> >>>.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
> >>>};
> >>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> >>> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> >>> index 677048cc3b7d..72530ebb0ae6 100644
> >>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> >>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> >>> @@ -351,6 +351,7 @@ struct dpu_rotation_cfg {
> >>> * @has_dim_layer dim layer feature status
> >>> * @has_idle_pcindicate if idle power collapse feature is
> >>> supported
> >>> * @has_3d_merge indicate if 3D merge is supported
> >>> + * @has_7xxx_intr indicate that INTF/IRQs use addressing for DPU
> >>> 7.0 and greater
> >>
> >> I see the requirement to distinguish feature support based on the
Re: [PATCH] drm/stm: Fix resolution bitmasks
On 10/14/22 19:15, Marek Vasut wrote: On 10/14/22 17:55, Marek Vasut wrote: On 10/14/22 15:42, Yannick FERTRE wrote: Hi Marek, Hello Yannick, The genmask of regsiter SSCR, BPCR & others were setted accordly to the chipset stm32f4. So that means: F4 -> 2048x2048 framebuffer H7/MP1 -> 4096x4096 framebuffer ? Worse F4 is 2048x2048 F7 is 4096x2048 MP1 is 4096x4096 and there is no IDR register on F4/F7 like on MP1, or is there ? How else can we tell those LTDC versions apart ? Dear Marek, Many thanks for your patch (and sorry for this late reply). Your patch is good and fixes this ltdc driver source code vs. the related reference manual. imho, it will not be an issue for F4 & F7 series if these bit-fields are "bigger" as I am pretty sure stm32 MCUs are not really using such high resolutions. Yannick already replied with his reviewed-by. I add my Acked-by: Philippe Cornu If you agree, I will merge your patch really soon. Dear Yannick, You may add to your todo list to double check if there is a need to detect stm32 MCUs vs. these bit-field sizes... Many thanks Philippe :-)
Re: [PATCH v4 03/11] drm/mediatek: gamma: Support SoC specific LUT size
Il 26/05/23 07:20, CK Hu (胡俊光) ha scritto: Hi, Angelo: On Thu, 2023-05-18 at 12:48 +0200, AngeloGioacchino Del Regno wrote: External email : Please do not click links or open attachments until you have verified the sender or the content. Newer SoCs support a bigger Gamma LUT table: wire up a callback to retrieve the correct LUT size for each different Gamma IP. Co-developed-by: Jason-JH.Lin Signed-off-by: Jason-JH.Lin [Angelo: Rewritten commit message/description + porting] Signed-off-by: AngeloGioacchino Del Regno < angelogioacchino.delre...@collabora.com> Reviewed-by: Jason-JH.Lin --- drivers/gpu/drm/mediatek/mtk_disp_drv.h | 1 + drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 25 ++- -- drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 4 ++-- drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 1 - drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 1 + drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 9 6 files changed, 35 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h b/drivers/gpu/drm/mediatek/mtk_disp_drv.h index 75045932353e..e554b19f4830 100644 --- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h +++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h @@ -53,6 +53,7 @@ void mtk_gamma_clk_disable(struct device *dev); void mtk_gamma_config(struct device *dev, unsigned int w, unsigned int h, unsigned int vrefresh, unsigned int bpc, struct cmdq_pkt *cmdq_pkt); +unsigned int mtk_gamma_get_lut_size(struct device *dev); void mtk_gamma_set(struct device *dev, struct drm_crtc_state *state); void mtk_gamma_set_common(struct device *dev, void __iomem *regs, struct drm_crtc_state *state); void mtk_gamma_start(struct device *dev); diff --git a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c index ce6f2499b891..d194d9bc2e2b 100644 --- a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c +++ b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c @@ -25,10 +25,12 @@ #define DISP_GAMMA_LUT 0x0700 #define LUT_10BIT_MASK 0x03ff +#define LUT_SIZE_DEFAULT 512 /* for setting gamma lut from AAL */ I would like to place AAL definition in AAL driver and pass it to gamma driver. This is not only for AAL, actually; I should remove that comment as it may actually be misleading. The default LUT size (512) is relevant for both the AAL case and the older SoCs, where the LUT size is 512 and no multi-register. I'll remove that comment in the next version Regards, Angelo
Re: [PATCH v4 06/11] drm/mediatek: gamma: Use bitfield macros
Il 26/05/23 07:32, CK Hu (胡俊光) ha scritto: Hi, Angelo: On Thu, 2023-05-18 at 12:48 +0200, AngeloGioacchino Del Regno wrote: External email : Please do not click links or open attachments until you have verified the sender or the content. Make the code more robust and improve readability by using bitfield macros instead of open coding bit operations. While at it, also add a definition for LUT_BITS_DEFAULT. Signed-off-by: AngeloGioacchino Del Regno < angelogioacchino.delre...@collabora.com> Reviewed-by: Jason-JH.Lin --- drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 41 ++--- -- 1 file changed, 26 insertions(+), 15 deletions(-) diff --git a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c index 1592614b6de7..ed2aa1fb0171 100644 --- a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c +++ b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c @@ -3,6 +3,7 @@ * Copyright (c) 2021 MediaTek Inc. */ +#include #include #include #include @@ -22,9 +23,16 @@ #define GAMMA_LUT_EN BIT(1) #define GAMMA_DITHERINGBIT(2) #define DISP_GAMMA_SIZE0x0030 +#define DISP_GAMMA_SIZE_HSIZE GENMASK(28, 16) +#define DISP_GAMMA_SIZE_VSIZE GENMASK(12, 0) #define DISP_GAMMA_LUT 0x0700 +#define DISP_GAMMA_LUT_10BIT_R GENMASK(29, 20) +#define DISP_GAMMA_LUT_10BIT_G GENMASK(19, 10) +#define DISP_GAMMA_LUT_10BIT_B GENMASK(9, 0) + #define LUT_10BIT_MASK 0x03ff +#define LUT_BITS_DEFAULT 10 This is used only for AAL after patch "drm/mediatek: gamma: Support specifying number of bits per LUT component", so I would like move AAL definition to AAL driver and pass it to gamma driver. Like LUT_SIZE_DEFAULT, this definition is not only for AAL but also for the older gamma lut register layout. In any case, I'll check if there's any clean way to pass AAL's gamma size to this driver... it's a different "component", so this may get complicated. Let's see what I can come up with in v5... Thanks, Angelo
Re: [PATCH] Revert "dt-bindings: bridge: samsung-dsim: Make some flags optional"
Hi, On Fri, 26 May 2023 09:27:16 +0200, Neil Armstrong wrote: > This reverts commit cfaf76d349837f695c8aa6d7077847fec4231fe5 which was applied > without review due to a bad tool manipulation. > > Thanks, Applied to https://anongit.freedesktop.org/git/drm/drm-misc.git (drm-misc-next) [1/1] Revert "dt-bindings: bridge: samsung-dsim: Make some flags optional" https://cgit.freedesktop.org/drm/drm-misc/commit/?id=35070674f488eefaeb753a13df11199d10328ff8 -- Neil
[Bug 216119] 087451f372bf76d breaks hibernation on amdgpu Radeon R9 390
https://bugzilla.kernel.org/show_bug.cgi?id=216119 --- Comment #55 from Harald Judt (h.j...@gmx.at) --- Unfortunately with the patch applied to 6.3.4 it causes the old problem. The screen stays dark, USB keyboard offline when trying to resume. So special treatment is still required it seems. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH] Revert "dt-bindings: bridge: samsung-dsim: Make some flags optional"
On 26/05/2023 10:02, Conor Dooley wrote: On Fri, May 26, 2023 at 09:27:16AM +0200, Neil Armstrong wrote: This reverts commit cfaf76d349837f695c8aa6d7077847fec4231fe5 which was applied without review due to a bad tool manipulation. Is it a dt-binding maintainer review that you are missing on that patch? Exact For this one: Acked-by: Conor Dooley Thanks, I'll apply this revert now and wait until the original bindings patch gets properly reviewed. Thanks, Neil Thanks, Conor. Signed-off-by: Neil Armstrong --- .../devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml| 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml b/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml index 360fea81f4b6..9f61ebdfefa8 100644 --- a/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml +++ b/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml @@ -70,9 +70,7 @@ properties: samsung,burst-clock-frequency: $ref: /schemas/types.yaml#/definitions/uint32 description: - DSIM high speed burst mode frequency when connected to devices - that support burst mode. If absent, the driver will use the pixel - clock from the attached device or bridge. + DSIM high speed burst mode frequency. samsung,esc-clock-frequency: $ref: /schemas/types.yaml#/definitions/uint32 @@ -82,8 +80,7 @@ properties: samsung,pll-clock-frequency: $ref: /schemas/types.yaml#/definitions/uint32 description: - DSIM oscillator clock frequency. If absent, the driver will - use the clock frequency of sclk_mipi. + DSIM oscillator clock frequency. phys: maxItems: 1 @@ -137,7 +134,9 @@ required: - compatible - interrupts - reg + - samsung,burst-clock-frequency - samsung,esc-clock-frequency + - samsung,pll-clock-frequency allOf: - $ref: ../dsi-controller.yaml# --- base-commit: cfaf76d349837f695c8aa6d7077847fec4231fe5 change-id: 20230526-revert-bad-binding-f77a3ca96419 Best regards, -- Neil Armstrong
Re: [Freedreno] [PATCH v2 3/6] drm/msm/dpu: split interrupt address arrays
On 5/22/2023 2:45 PM, Dmitry Baryshkov wrote:
There is no point in having a single enum (and a single array) for both
DPU < 7.0 and DPU >= 7.0 interrupt registers. Instead define a single
enum and two IRQ address arrays.
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_7_0_sm8350.h| 1 +
.../msm/disp/dpu1/catalog/dpu_7_2_sc7280.h| 1 +
.../msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h | 1 +
.../msm/disp/dpu1/catalog/dpu_8_1_sm8450.h| 1 +
.../msm/disp/dpu1/catalog/dpu_9_0_sm8550.h| 1 +
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 2 +
.../gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 82 +--
.../gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h | 28 ---
8 files changed, 79 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h
index 3c1b2c13398d..320cfa4be633 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h
@@ -15,6 +15,7 @@ static const struct dpu_caps sm8350_dpu_caps = {
.has_dim_layer = true,
.has_idle_pc = true,
.has_3d_merge = true,
+ .has_7xxx_intr = true,
.max_linewidth = 4096,
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
};
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
index 5d894cbb0a62..9306c7a115e9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
@@ -13,6 +13,7 @@ static const struct dpu_caps sc7280_dpu_caps = {
.qseed_type = DPU_SSPP_SCALER_QSEED4,
.has_dim_layer = true,
.has_idle_pc = true,
+ .has_7xxx_intr = true,
.max_linewidth = 2400,
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
};
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h
index c3f1ae000a21..fc1e17c495f0 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h
@@ -15,6 +15,7 @@ static const struct dpu_caps sc8280xp_dpu_caps = {
.has_dim_layer = true,
.has_idle_pc = true,
.has_3d_merge = true,
+ .has_7xxx_intr = true,
.max_linewidth = 5120,
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
};
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h
index 86c2e68ebd2c..eb72411c16db 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h
@@ -14,6 +14,7 @@ static const struct dpu_caps sm8450_dpu_caps = {
.has_src_split = true,
.has_dim_layer = true,
.has_idle_pc = true,
+ .has_7xxx_intr = true,
.has_3d_merge = true,
.max_linewidth = 5120,
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h
index 85dc34458b88..8209ca317bdc 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h
@@ -15,6 +15,7 @@ static const struct dpu_caps sm8550_dpu_caps = {
.has_dim_layer = true,
.has_idle_pc = true,
.has_3d_merge = true,
+ .has_7xxx_intr = true,
.max_linewidth = 5120,
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
};
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index 677048cc3b7d..72530ebb0ae6 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -351,6 +351,7 @@ struct dpu_rotation_cfg {
* @has_dim_layer dim layer feature status
* @has_idle_pcindicate if idle power collapse feature is supported
* @has_3d_merge indicate if 3D merge is supported
+ * @has_7xxx_intr indicate that INTF/IRQs use addressing for DPU 7.0 and
greater
I see the requirement to distinguish feature support based on the DPU
version in more than one series. Is it a good idea to bring in the DPU
version info in chipset catalog? This will relieve us from maintaining
such version flags for individual HW sub-blocks.
Thanks and Regards,
Jeykumar S.
* @max_linewidth max linewidth for sspp
* @pixel_ram_size size of latency hiding and de-tiling buffer in bytes
* @max_hdeci_exp max horizontal decimation supported (max is 2^value)
@@ -364,6 +365,7 @@ struct dpu_caps {
bool has_dim_layer;
bool has_idle_pc;
bool has_3d_merge;
+ bool has_7xxx_intr;
/* SSPP limits */
u32 max_linewidth;
u32 pixel_ram_size;
diff --git
[PATCH] drm: Remove unnecessary (void*) conversions
Pointer variables of (void*) type do not require type cast.
Signed-off-by: Su Hui
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 2 +-
drivers/gpu/drm/amd/pm/amdgpu_pm.c| 2 +-
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_debugfs.c | 2 +-
drivers/gpu/drm/omapdrm/omap_debugfs.c| 6 +++---
drivers/gpu/drm/pl111/pl111_debugfs.c | 2 +-
drivers/gpu/drm/qxl/qxl_debugfs.c | 4 ++--
drivers/gpu/drm/tiny/arcpgu.c | 2 +-
drivers/gpu/drm/ttm/ttm_resource.c| 3 +--
drivers/gpu/drm/virtio/virtgpu_debugfs.c | 6 +++---
drivers/gpu/drm/vmwgfx/ttm_object.c | 5 ++---
drivers/gpu/drm/vmwgfx/vmwgfx_gem.c | 2 +-
12 files changed, 19 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
index 827fcb4fb3b3..8a2c39927167 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
@@ -3312,7 +3312,7 @@ static ssize_t dtn_log_write(
static int mst_topo_show(struct seq_file *m, void *unused)
{
- struct amdgpu_device *adev = (struct amdgpu_device *)m->private;
+ struct amdgpu_device *adev = m->private;
struct drm_device *dev = adev_to_drm(adev);
struct drm_connector *connector;
struct drm_connector_list_iter conn_iter;
diff --git a/drivers/gpu/drm/amd/pm/amdgpu_pm.c
b/drivers/gpu/drm/amd/pm/amdgpu_pm.c
index 58c2246918fd..e6c870bd307b 100644
--- a/drivers/gpu/drm/amd/pm/amdgpu_pm.c
+++ b/drivers/gpu/drm/amd/pm/amdgpu_pm.c
@@ -3671,7 +3671,7 @@ static void amdgpu_parse_cg_state(struct seq_file *m, u64
flags)
static int amdgpu_debugfs_pm_info_show(struct seq_file *m, void *unused)
{
- struct amdgpu_device *adev = (struct amdgpu_device *)m->private;
+ struct amdgpu_device *adev = m->private;
struct drm_device *dev = adev_to_drm(adev);
u64 flags = 0;
int r;
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index 31a7f59ccb49..dd57f7164e9a 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -198,7 +198,7 @@ static int etnaviv_ring_show(struct etnaviv_gpu *gpu,
struct seq_file *m)
static int show_unlocked(struct seq_file *m, void *arg)
{
- struct drm_info_node *node = (struct drm_info_node *) m->private;
+ struct drm_info_node *node = m->private;
struct drm_device *dev = node->minor->dev;
int (*show)(struct drm_device *dev, struct seq_file *m) =
node->info_ent->data;
@@ -208,7 +208,7 @@ static int show_unlocked(struct seq_file *m, void *arg)
static int show_each_gpu(struct seq_file *m, void *arg)
{
- struct drm_info_node *node = (struct drm_info_node *) m->private;
+ struct drm_info_node *node = m->private;
struct drm_device *dev = node->minor->dev;
struct etnaviv_drm_private *priv = dev->dev_private;
struct etnaviv_gpu *gpu;
diff --git a/drivers/gpu/drm/nouveau/nouveau_debugfs.c
b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
index 2a36d1ca8fda..96b59d5d68ed 100644
--- a/drivers/gpu/drm/nouveau/nouveau_debugfs.c
+++ b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
@@ -37,7 +37,7 @@
static int
nouveau_debugfs_vbios_image(struct seq_file *m, void *data)
{
- struct drm_info_node *node = (struct drm_info_node *) m->private;
+ struct drm_info_node *node = m->private;
struct nouveau_drm *drm = nouveau_drm(node->minor->dev);
int i;
diff --git a/drivers/gpu/drm/omapdrm/omap_debugfs.c
b/drivers/gpu/drm/omapdrm/omap_debugfs.c
index a3d470468e5b..a94ce502e152 100644
--- a/drivers/gpu/drm/omapdrm/omap_debugfs.c
+++ b/drivers/gpu/drm/omapdrm/omap_debugfs.c
@@ -19,7 +19,7 @@
static int gem_show(struct seq_file *m, void *arg)
{
- struct drm_info_node *node = (struct drm_info_node *) m->private;
+ struct drm_info_node *node = m->private;
struct drm_device *dev = node->minor->dev;
struct omap_drm_private *priv = dev->dev_private;
@@ -33,7 +33,7 @@ static int gem_show(struct seq_file *m, void *arg)
static int mm_show(struct seq_file *m, void *arg)
{
- struct drm_info_node *node = (struct drm_info_node *) m->private;
+ struct drm_info_node *node = m->private;
struct drm_device *dev = node->minor->dev;
struct drm_printer p = drm_seq_file_printer(m);
@@ -45,7 +45,7 @@ static int mm_show(struct seq_file *m, void *arg)
#ifdef CONFIG_DRM_FBDEV_EMULATION
static int fb_show(struct seq_file *m, void *arg)
{
- struct drm_info_node *node = (struct drm_info_node *) m->private;
+ struct drm_info_node *node = m->private;
Re: [PATCH] Revert "dt-bindings: bridge: samsung-dsim: Make some flags optional"
On Fri, May 26, 2023 at 09:27:16AM +0200, Neil Armstrong wrote: > This reverts commit cfaf76d349837f695c8aa6d7077847fec4231fe5 which was applied > without review due to a bad tool manipulation. Is it a dt-binding maintainer review that you are missing on that patch? For this one: Acked-by: Conor Dooley Thanks, Conor. > > Signed-off-by: Neil Armstrong > --- > .../devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml| 9 > - > 1 file changed, 4 insertions(+), 5 deletions(-) > > diff --git > a/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml > b/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml > index 360fea81f4b6..9f61ebdfefa8 100644 > --- a/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml > +++ b/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml > @@ -70,9 +70,7 @@ properties: >samsung,burst-clock-frequency: > $ref: /schemas/types.yaml#/definitions/uint32 > description: > - DSIM high speed burst mode frequency when connected to devices > - that support burst mode. If absent, the driver will use the pixel > - clock from the attached device or bridge. > + DSIM high speed burst mode frequency. > >samsung,esc-clock-frequency: > $ref: /schemas/types.yaml#/definitions/uint32 > @@ -82,8 +80,7 @@ properties: >samsung,pll-clock-frequency: > $ref: /schemas/types.yaml#/definitions/uint32 > description: > - DSIM oscillator clock frequency. If absent, the driver will > - use the clock frequency of sclk_mipi. > + DSIM oscillator clock frequency. > >phys: > maxItems: 1 > @@ -137,7 +134,9 @@ required: >- compatible >- interrupts >- reg > + - samsung,burst-clock-frequency >- samsung,esc-clock-frequency > + - samsung,pll-clock-frequency > > allOf: >- $ref: ../dsi-controller.yaml# > > --- > base-commit: cfaf76d349837f695c8aa6d7077847fec4231fe5 > change-id: 20230526-revert-bad-binding-f77a3ca96419 > > Best regards, > -- > Neil Armstrong > signature.asc Description: PGP signature
Re: [PATCH] drm/panel: simple: fix active size for Ampire AM-480272H3TMQW-T01H
Hi, On Tue, 16 May 2023 10:50:39 +0200, Dario Binacchi wrote: > The previous setting was related to the overall dimension and not to the > active display area. > In the "PHYSICAL SPECIFICATIONS" section, the datasheet shows the > following parameters: > > -- > | Item| Specifications| unit | > -- > | Display area | 98.7 (W) x 57.5 (H) | mm | > -- > | Overall dimension | 105.5(W) x 67.2(H) x 4.96(D) | mm | > -- > > [...] Thanks, Applied to https://anongit.freedesktop.org/git/drm/drm-misc.git (drm-misc-next) [1/1] drm/panel: simple: fix active size for Ampire AM-480272H3TMQW-T01H https://cgit.freedesktop.org/drm/drm-misc/commit/?id=f24b49550814fdee4a98b9552e35e243ccafd4a8 -- Neil
Re: [PATCH 0/2] drm/panel: simple: Add support for Ampire AM-800480L1TMQW-T00H
Hi, On Wed, 24 May 2023 14:32:09 +0200, Geert Uytterhoeven wrote: > Hi all, > > This patch series adds support for the Ampire AM-800480L1TMQW-T00H 5" > WVGA TFT LCD panel, which can be found on e.g. the Atmark Techno > Armadillo-800-EVA development board. > > It has been tested with a WIP DT-enhanced version of the shmob-drm > driver. > > [...] Thanks, Applied to https://anongit.freedesktop.org/git/drm/drm-misc.git (drm-misc-next) [1/2] dt-bindings: display: panel-simple: Add Ampire AM-800480L1TMQW-T00H https://cgit.freedesktop.org/drm/drm-misc/commit/?id=d3a6c2b60f07c64631b9437032d8f079341b7a16 [2/2] drm/panel: simple: Add Ampire AM-800480L1TMQW-T00H https://cgit.freedesktop.org/drm/drm-misc/commit/?id=410bb21319f69c2ec28aeafe530d00ed2f6a1c54 -- Neil
Re: [PATCH 1/2] dt-bindings: display: panel: Add Visionox R66451 AMOLED DSI panel bindings
On 22/05/2023 16:51, Marijn Suijten wrote: On 2023-05-22 11:05:38, Neil Armstrong wrote: On 21/05/2023 12:30, Marijn Suijten wrote: On 2023-05-16 13:20:30, Jessica Zhang wrote: Document the 1080x2340 Visionox R66451 AMOLED DSI panel bindings Signed-off-by: Jessica Zhang --- .../bindings/display/panel/visionox,r66451.yaml| 59 ++ 1 file changed, 59 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/visionox,r66451.yaml b/Documentation/devicetree/bindings/display/panel/visionox,r66451.yaml new file mode 100644 index ..6ba323683921 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/visionox,r66451.yaml @@ -0,0 +1,59 @@ +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/visionox,r66451.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Visionox R66451 AMOLED DSI Panel + +maintainers: + - Jessica Zhang + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: +const: visionox,r66451 + + reg: +maxItems: 1 +description: DSI virtual channel + + vddio-supply: true + vdd-supply: true + port: true + reset-gpios: true Normally for cmd-mode panels there is also a `disp-te` pin which is optionally registered in dsi_host.c as GPIOD_IN, but on **ALL** my Sony phones this breaks vsync (as in: mdp5 stops receiving the interrupt, but we can see disp-te in /proc/interrupts then). Describing it as a gpio is wrong, it should be described as a pinctrl state instead. We defined both in our DTS, what weirdness does it cause when then requested using GPIOD_IN? It'd still be beneficial to see the vsync interrupt raise in /proc/interrupts (but it's just a waste of CPU cycles OTOH, this is all handled in the MDP hardware after all, so it's not something I'd like to enable by default). Sure, but it's a sw hack, the pin has a TE function which directly goes to the DSI logic, claiming it as a GPIO will set it as GPIO function. On some platforms, PINMUX is only on output and input is always directed to all HW blocks, seems it's not the case here ! Anyway, this is what we ended up doing to "fix" the bug (only bias the pin via pinctrl, omit the disp-te DTS property). Thanks for confirming! - Marijn Neil
